Hakuria SystemsのWebサイトでは、実行基盤としてCloudflare Workersを採用しています。

今回必要だったのは、単純な静的サイトではありません。Nuxt 4によるSSRやServer API、問い合わせフォーム、データベース、管理機能などを持つ動的なWebサイトです。

CloudflareもAWSやAzureと同じように、複数のサービスを組み合わせて利用します。

その中でCloudflareを選んだのは、Workersを中心にStatic Assets、D1、Access、Turnstileなどを組み合わせることで、今回必要だったWeb機能を比較的コンパクトに実現できたこと。そして、無料枠を活用しながら小さく始められることにも魅力を感じたからです。

Cloudflareが他のクラウドより優れているという意味ではありません。

この記事では、AWS、Azure、Google Cloudとの違いも整理しながら、なぜ今回のWebサイトではCloudflareを採用したのかを紹介します。

どんなWebサイトを作りたかったのか

Hakuria SystemsのWebサイトでは、主に次の機能が必要でした。

  • SSRによるページ表示
  • Server API
  • お問い合わせフォーム
  • 問い合わせ情報の保存・管理
  • 管理機能へのアクセス制御
  • CDN
  • WAFやBot対策
  • 独自ドメイン
  • 小規模でも運用しやすい構成

これらを実現するフロントエンドフレームワークとしてNuxt 4を採用しています。

技術選定の順番としては、次のようなイメージです。

実現したいこと
動的なWebサイト
  ↓
フロントエンド
Nuxt 4
  ↓
実行基盤
Cloudflare Workers

Nuxt 4やCloudflareを先に決めたわけではありません。

まず実現したいWebサイトを整理し、その要件に合う技術を選択しました。

Workersを中心に構成を組み立てやすかった

Cloudflareも、Workers、D1、Access、Turnstileなど、それぞれ役割の異なるサービスを組み合わせて利用します。

この点はAWS、Azure、Google Cloudと大きく変わりません。

今回魅力を感じたのは、サービスの数が少ないことではなく、Workersを中心にWebアプリに必要な機能を組み合わせやすかったことです。

Cloudflare

├─ Workers
│   ├─ Nuxt SSR
│   └─ Server API
│
├─ Static Assets
│   └─ CSS / JavaScript / 画像
│
├─ D1
│   └─ アプリケーションデータ
│
├─ Access
│   └─ 管理機能へのアクセス制御
│
├─ Turnstile
│   └─ Bot対策
│
├─ DNS
└─ WAF

SSRやServer APIはWorkers、静的ファイルはStatic Assets、データはD1、管理機能へのアクセス制御はAccessというように、それぞれ役割を分けながら構成できます。

Cloudflareを調べていて惹かれたのは、Workersを起点に構成を考えていくと、今回必要だった機能がきれいにつながったことでした。

Cloudflareの公式ドキュメントでも、WorkersとStatic Assetsを一度のデプロイでまとめて扱い、静的ファイル配信とWorkerの処理を組み合わせる構成が案内されています。

Workersのような仕組みは他クラウドにもある

Cloudflare Workersだけが、サーバーレスでコードを実行できる唯一のサービスというわけではありません。

AWSにはLambdaやLambda@Edge、CloudFront Functionsがあります。AzureにはAzure Functionsがあり、Azure Front DoorではEdge Actionsも提供されています。Google CloudにはCloud RunやCloud Run functionsがあり、Cloud CDNなどと組み合わせることができます。

そのため、**「Workersのような機能がCloudflareにしかないから採用した」**という説明は正確ではありません。

今回のポイントは、Workers単体の機能ではなく、Workersをアプリケーションの中心に置き、周辺サービスまで含めて構成を整理しやすかったことです。

参考として、各社の公式ドキュメントでは次のような選択肢が案内されています。

※Azure Front Door Edge Actionsは、2026年8月時点ではプレビュー機能です。

特に魅力を感じたWorkersとStatic Assets

Nuxt 4をビルドすると、静的ファイルとサーバー側の処理が生成されます。

Cloudflareでは、概ね次のような形で扱えます。

Nuxt 4
  ↓ build

Cloudflare

├─ Static Assets
│   └─ 静的ファイル
│
└─ Workers
    ├─ SSR
    └─ Server API

CSS、JavaScript、画像などの静的ファイルはStatic Assetsとして配信し、SSRやServer APIはWorkers上で実行します。

この構成を見たときに、**「これならWebサイトとAPIを必要以上に分けずに作れる」**と感じました。

今回の構成では、Webサーバー、APIサーバー、アプリケーションサーバーをそれぞれ個別に用意して管理する必要がありません。

もちろん、大規模なシステムでは役割を分離することに意味があります。

ただ、今回作りたいのは企業サイトを中心とした比較的小規模なWebアプリです。その規模でインフラだけが必要以上に複雑になるのは避けたいと考えていました。

WorkersとStatic Assetsの組み合わせは、その考え方に合っていました。

無料枠を活用して小さく始められる

もう一つ魅力を感じたのが、無料枠を活用して始めやすいことです。

Cloudflareでは、WorkersやD1、Turnstile、Accessなどに無料で利用を始められる範囲があります。Static Assetsについても、公式ドキュメントでは静的アセットへのリクエストは無料かつ無制限と案内されています。

2026年8月時点の公式情報では、例えば次の無料枠があります。

  • Workers Free：1日10万リクエスト
  • D1：Freeプランで利用可能
  • Turnstile Free：チャレンジ回数は無制限
  • Cloudflare Zero Trust Free：50ユーザーまで
  • Workers Static Assets：静的アセットへのリクエストは無料・無制限

料金や無料枠は変更される可能性があるため、利用時には最新の公式情報を確認する必要があります。

Webサイトの立ち上げ段階では、アクセス数やデータ量を正確に予測できるとは限りません。

そのため、まず小さく始め、実際の利用量を見ながら必要なところにコストをかけていくという進め方ができることは、今回のWebサイトと相性が良いと感じました。

もちろん、無料だからCloudflareを採用したわけではありません。

要件を満たせることが前提で、そのうえで初期コストを抑えながら検証・運用を始めやすいことも判断材料の一つになったという位置づけです。

D1は今回の用途に合っていた

お問い合わせフォームから送信された情報は、データベースにも保存しています。

この用途ではCloudflare D1を採用しました。

D1はCloudflareが提供するマネージドなサーバーレスSQLデータベースで、SQLiteのSQLセマンティクスを持ち、Workersから利用できます。

今回扱うデータ量やトランザクション特性、必要な処理を考えた結果、D1で要件を満たせると判断しました。

一方で、大量のトランザクションや複雑な業務処理、大規模なデータ処理が必要であれば、PostgreSQL、Azure SQL、Amazon Auroraなどを選択する可能性があります。

最も高機能なデータベースを選ぶのではなく、そのシステムに必要十分なものを選ぶという考え方です。

管理機能にはCloudflare Accessを利用

問い合わせ情報などを扱う管理機能には、一般公開ページとは異なるアクセス制御が必要です。

そこでCloudflare Accessを利用しています。

管理者
  ↓
Cloudflare Access
  ↓
管理機能
  ↓
Server API
  ↓
D1

Cloudflare Accessは、アプリケーションの前段でリクエストをAccess Policyに照らして評価するIdentity-Aware Proxyとして利用できます。

管理機能のためだけに独自の認証基盤を一から構築せず、アプリケーションの前段でアクセスを制御できる点は、今回の用途に合っていました。

ただし、Cloudflare Accessを使えばアプリケーション側の認可がすべて不要になるわけではありません。

アクセスできるユーザーの制御と、アプリケーション内部で何を実行できるかという認可は、別の責務として考える必要があります。

問い合わせフォームにはTurnstileを利用

お問い合わせフォームでは、Bot対策としてCloudflare Turnstileを利用しています。

TurnstileはWorkersに含まれる機能ではなく、独立したサービスです。Cloudflareの他サービスを利用していないWebサイトにも導入できます。

Cloudflareを採用したから自動的に利用されるわけではなく、問い合わせフォームに必要な対策として選択しています。

このようにCloudflareでも、必要なサービスを選びながら、Workersを中心として構成を組み立てています。

AWS・Azure・Google Cloudとどう違うのか

今回の用途を前提として、各クラウドを大きく整理すると次のようになります。

観点CloudflareAWSAzureGoogle Cloud
Webアプリ実行WorkersLambdaなどFunctions / App ServiceなどCloud Run / Cloud Run functionsなど
静的配信Static AssetsS3 + CloudFrontなどStatic Web Apps / StorageなどCloud Storage + CDNなど
CDN / WAFCloudflare CDN / WAFCloudFront / AWS WAFFront Door / WAFCloud CDN / Cloud Armor
SQLデータベースD1RDS / AuroraなどAzure SQL / PostgreSQLなどCloud SQLなど
ID・アクセス制御AccessなどCognito / IAMなどEntra IDとの統合が強いIAM / Identity Platformなど
マネージドRDBの選択肢比較的限定的豊富豊富豊富
Microsoft環境との連携限定的限定的強い限定的

大切なのは、どのクラウドでも今回のWebサイトは構築できるという点です。

Cloudflareでなければ実現できない機能があったわけではありません。また、AWS、Azure、Google Cloudにも無料枠や従量課金の仕組みがあります。

今回Cloudflareに魅力を感じたのは、単純な機能比較や価格比較ではなく、Workersを中心とした構成とスモールスタートのしやすさが、今回の要件とうまく噛み合ったことでした。

他のクラウドを選ぶ方が自然なケースもある

AWSは非常に多くのサービスを持ち、大規模化や複雑化に応じて幅広い構成を選択できます。

AzureはMicrosoft Entra ID、Microsoft 365、Azure SQLなど、Microsoft製品との統合に大きな強みがあります。

Google CloudはCloud Runに加え、BigQueryやVertex AIなど、データ分析やAI分野に強みがあります。

そのため、例えば次のようなシステムならCloudflare以外を優先する可能性があります。

  • 複雑なネットワークや多数のマネージドサービスが必要
  • 大規模なRDBや大量のトランザクションがシステムの中心
  • Microsoft環境との統合が重要
  • 大規模なデータ分析やAI基盤が中心
  • 既存のAWS、Azure、Google Cloud環境との統合が重要

Cloudflareを実際に使ったことで、Cloudflareが得意なところと、他のクラウドを選んだ方がよいところを分けて考える必要があると感じています。

なぜCloudflareを採用したのか

今回の採用理由を整理すると、大きく3つあります。

1. Workersを中心にWebアプリを構成しやすかった

Nuxt 4のSSRやServer API、Static Assetsなどを、Workersを中心とした構成で整理しやすく、今回のWebサイトの規模に合っていました。

2. 周辺サービスを同じCloudflare上で組み合わせやすかった

D1、Access、Turnstileなど、今回必要だった機能を役割ごとに選びながら追加できました。

3. 小さく始めやすかった

要件を満たしたうえで、無料枠も活用しながら初期コストを抑えて検証・運用を始められました。

現在の構成を、公開可能な範囲で簡略化すると次のようになります。

Cloudflare

├─ DNS / CDN / WAF
│
├─ Workers
│   ├─ Nuxt 4
│   ├─ SSR
│   └─ Server API
│
├─ Static Assets
│   └─ CSS / JavaScript / 画像
│
├─ D1
│   └─ アプリケーションデータ
│
├─ Access
│   └─ 管理機能へのアクセス制御
│
└─ Turnstile
    └─ Bot対策

外部サービス
└─ メール送信サービス

仕様表だけを比較して選んだというより、実際の構成を当てはめたときに、**「これなら無理なく始めて、運用していけそうだ」**と思えたことが、最終的な決め手でした。

クラウド選定に絶対的な正解はない

クラウドサービスを比較すると、「どのクラウドが一番優れているのか」という話になりがちです。

しかし、Hakuria Systemsではクラウドそのものの優劣よりも、何を実現したいのかを整理し、その要件に適したサービスを選択することが重要だと考えています。

Workersのような仕組みも、Cloudflareだけのものではありません。AWS、Azure、Google Cloudにも同じ課題を解決できるサービスがあります。

そのうえで今回のHakuria SystemsのWebサイトでは、Workersを中心とした構成、周辺サービスとの組み合わせ、スモールスタートのしやすさが、要件と規模に合っていました。

今後も「この技術を使いたい」から始めるのではなく、何を作りたいのか、その規模で何が必要なのかを考えてから技術を選ぶことを大切にしていきます。

次回は、実際に Nuxt 4 × Cloudflare Workers でサイトを構築して分かったメリットや、実装・運用時に直面した注意点について紹介します。

Hakuria Systemsでは、クラウド選定やWebサイト、API設計を含むシステム開発を支援しています。ご相談はお問い合わせフォームからご連絡ください。