アーキテクチャパターン集
サービスパターン（配信・SaaS・リアルタイム・AI・非同期処理など）ごとの典型構成を8つ紹介します。図の色分けは共通です。費用感は小規模スタート時の目安（1USD=150円）で、参考文献はすべて公式ドキュメントです。
静的サイト+エッジAPI
対象：コーポレートサイト、ブログ、LP、SPA+軽いAPIのサービス
流れ：画面はすべて静的アセットとして配信し（無料・無制限）、動的な部分だけ同じWorker内のAPIルート（/api/*）が処理します。1つのWorkerプロジェクトにフロントとAPIが同居するのが現在の標準構成です。
メリット
- 静的部分のリクエストは課金対象外なので、バズっても費用がほぼ増えない
- デプロイは
wrangler deploy1コマンド。プレビューURLも自動発行 - オリジンサーバーが存在しないため、落ちる場所が少ない
デメリット
- 複雑な業務データを持ち始めるとKVだけでは足りない（パターン2へ発展）
- SSRを多用するフレームワークではWorker呼び出しが増え課金対象になる
費用感：無料プランで開始可能。商用でも月額$5（約750円）でほぼ収まる規模が多い。
フルスタックSaaS最小構成
対象：業務SaaS、会員制サービス、社内ツール。少人数チームでの新規開発
流れ：1つのWorkerが画面配信・認証・APIをすべて担い、業務データはD1、ファイルはR2、セッションはKVに置きます。メール送信のような待たせたくない処理はQueuesに投げ、コンシューマWorkerが処理します。Honoなどの軽量フレームワークと組み合わせるのが定番です。
採用ポイント：「サーバー費用ゼロ円から始まり、使った分だけ増える」構成のため、リリース前後の売上ゼロ期間の固定費を最小化できます。D1は1データベース10GBまでなので、超えそうな規模になったらパターン3（テナント分割）やパターン7（外部RDB）へ発展させます。
メリット
- インフラ担当ゼロでも運用できる。スケール設定が存在しない
- ローカル開発（wrangler dev）で本番同等のバインディングを再現できる
- D1のリードレプリカが自動で世界配置され、読み取りが速い
デメリット
- SQLiteのため、複雑な分析クエリや巨大トランザクションはRDBに劣る
- ローカル環境と本番のD1に差異が出ないようマイグレーション管理の規律が必要
費用感：Workers Paid $5/月（約750円）+ R2保存分（10GB無料、以降約2.3円/GB月）。月間数百万リクエスト・数千ユーザー規模までこの価格帯で収まることが多い。
マルチテナントSaaS（テナント分離）
対象：複数企業に提供するB2B SaaS。データ分離・セキュリティ要件が強い場合
流れ：ログイン後、Workerがリクエストのテナントを特定し（サブドメインやJWTのクレームから）、テナント台帳でそのテナント専用のD1データベースを引いて接続します。D1は「DBを増やすこと」に追加固定費がかからないため、テナントごとに物理的にDBを分ける設計が現実的にとれます。
採用ポイント：共有DB+tenant_id列方式（実装が速いが漏洩リスクはアプリの規律頼み）と、テナント別DB方式（クエリの書き間違いによる他社データ混入が構造的に起きない）のトレードオフが設計面接の頻出論点です。D1の10GB制限もテナント単位なら実質問題になりにくくなります。さらに大規模なテナント数・テナントごとのカスタムコードが必要ならWorkers for Platformsを検討します。
メリット
- データ分離を構造で保証でき、B2Bのセキュリティ審査で説明しやすい
- テナント単位のバックアップ・削除・容量管理が簡単
- 1テナントの高負荷が他テナントのDBに波及しない
デメリット
- スキーマ変更を全テナントDBに配布するマイグレーション運用が必要
- テナント横断の集計はそのままではできない（集計用の仕組みを別途用意）
費用感：行数課金はDB数に依存しないため、パターン2とほぼ同じ。テナントが増えても固定費は増えない。
- D1 Limits（データベース数・容量）
- Workers for Platforms
リアルタイム協調（WebSocket）
対象：チャット、通知、共同編集、ダッシュボードのライブ更新、対戦ゲーム
流れ：WorkerがWebSocket接続を受け、ルームIDに対応するDurable Objectへ転送します。同じルームの参加者は必ず同じインスタンスにつながるため、ブロードキャストは「自分が持つ接続一覧に送る」だけで実現します。WebSocket Hibernation APIを使うと、発言のない間はインスタンスがメモリから退避し、接続を維持したまま稼働課金が止まります。
メリット
- Pub/Subサーバー（RedisやSocket.io基盤）を別途運用しなくてよい
- Hibernationにより「接続は多いが発言は少ない」アプリが非常に安価
- 1インスタンスで最大32,768接続まで受けられる
デメリット
- 1ルームの処理は単一スレッドなので、超高頻度メッセージはバッチ化の工夫が必要
- Hibernation対応の書き方（acceptWebSocket、webSocketMessageハンドラ）に慣れが必要
費用感：無料プランから利用可。Hibernation活用時はリクエスト数と行読み書きが主なコストで、小規模なら$5/月枠内に収まりやすい。
RAG/AIチャット
対象：社内ナレッジ検索、FAQボット、ドキュメントに基づいて回答するアシスタント
流れ：質問文をWorkerが受け、埋め込みモデルでベクトル化してVectorizeで関連ドキュメントを検索します。ヒットした本文を質問と一緒にLLMへ渡し、根拠付きの回答を生成します。LLM呼び出しは必ずAI Gatewayを通し、トークン使用量・コスト・エラー率を一元管理します。R2にドキュメントを置くだけで取り込み〜インデックスを自動化したい場合はAI Search（旧AutoRAG）が使えます。
メリット
- ベクトルDB・GPUサーバーの運用が不要で、RAGの試作から本番まで最短
- AI Gatewayのキャッシュで同一質問のLLM課金を削減できる
- 埋め込み生成（Workers AI）と回答生成（外部LLM）を適材適所で使い分けられる
デメリット
- チャンク分割・検索精度のチューニングはどのプラットフォームでも結局必要
- 外部LLMのAPI費用は別途発生する（AI Gatewayで可視化・制御はできる）
費用感：Cloudflare側は$5/月+Vectorize・Workers AIの従量。支配的なのは外部LLMのトークン費用になりがちで、そこの管理こそAI Gatewayの出番。
AIエージェント
対象：会話の文脈と作業状態を保持し、長時間タスクを自律的に進めるアシスタント
流れ：ユーザーごと（またはスレッドごと）にAgentインスタンスが立ち、WebSocketで画面と直結します。会話履歴と作業状態はAgent内蔵のSQLiteに保持。数分〜数日かかるタスク（調査、帳票生成、承認待ち）はWorkflowsに切り出し、ステップ単位のリトライと再開を保証します。LLM呼び出しはAI Gateway経由で行い、モデルの切り替えやコスト管理を集約します。
採用ポイント：「エージェントの状態管理をどこに置くか」が最大の設計論点です。ステートレスなLambda的環境では会話状態を毎回DBから復元する必要がありますが、この構成では状態を持つ実行単位そのもの（Durable Objects）が基盤なので、アーキテクチャが素直になります。
メリット
- 会話状態・スケジュール実行・WebSocketが1つの抽象にまとまっている
- Workflowsとの組み合わせで「途中で落ちても続きから」が標準装備
- 公式がAIコーディング用のプロンプト・テンプレートを整備しており立ち上げが速い
デメリット
- フレームワークがまだ若く、設計パターンの情報が少ない
- LLM費用・実行時間の暴走対策（上限設定、人の承認ゲート）を自分で設計する必要がある
費用感：Cloudflare側は小規模なら$5/月枠+Durable Objects従量。ここでも支配的なのはLLMトークン費用。
既存DB活用ハイブリッド（Vercel/既存資産と併用）
対象：Next.js資産やPostgres/MySQL資産があるチーム。段階的にエッジへ移行したい場合
流れ：画面はVercel上のNext.jsが担い、APIはCloudflare Workersに置きます。WorkersからはHyperdrive経由で既存のPostgres/MySQLに接続します。Hyperdriveがコネクションプールとクエリキャッシュをエッジ側で肩代わりするため、DBが1リージョンにあってもグローバルに高速な読み取りができます。DrizzleやPrismaなど既存ORMはコード変更なしで動きます。
採用ポイント：「全部Cloudflareに寄せる」か「フロントは使い慣れたVercel、バックエンドとデータ基盤はCloudflare」かはチームのスキルセット次第です。認証・課金・DBを一気に移さず、API層から段階的にエッジへ移す現実的な移行パスとして覚えておくと強い構成です。
メリット
- 既存のNext.js・ORM・SQL資産をほぼそのまま活かせる
- SQLiteでは厳しい複雑クエリ・大容量・拡張機能（PostGISなど）が使える
- 将来Workers静的アセットへフロントを寄せる選択肢も残る
デメリット
- プラットフォームが2つになり、デプロイ・監視・請求が分散する
- DB本体の費用（Neon、RDSなど）は従来どおりかかる
費用感：Workers $5/月+外部DB費用（例：マネージドPostgresの無料枠〜数千円）+Vercel費用。
非同期ジョブ・バッチ処理
対象：メール送信、帳票生成、外部連携、集計など「即時応答が不要な処理」全般
流れ：APIは受付だけしてQueuesにメッセージを投げ、すぐ200を返します。コンシューマWorkerがバッチで受け取り、失敗時は自動リトライ、規定回数を超えたらデッドレターキューへ退避して後で調査します。定期処理はCron Triggersからジョブを投入します。複数ステップにまたがる処理（生成→変換→通知など）はWorkflowsにすると、途中失敗からの再開が保証されます。
メリット
- ユーザーの体感速度と処理の信頼性を両立できる
- 外部APIの障害がユーザー操作を巻き込まない（キューが吸収）
- コンシューマの同時実行数はキューの深さに応じて自動スケール
デメリット
- 「少なくとも1回配信」のため、処理の冪等性（2回実行されても壊れない設計）が必須
- 即時に結果を返す必要がある処理には使えない
費用感：Queuesは操作数の従量課金で、小規模なら月数十円〜。Workers Paidプランが前提。
セキュリティ層の重ね方
どのパターンにも共通して手前に重ねる防御レイヤー
考え方：アプリコードに到達する前に「DDoS対策とWAF（既知パターンの遮断）→レート制限（総当たり・過剰リクエストの抑制）→Turnstile（フォームのボット判定）」を重ね、アプリ内の認証・認可は最後の砦にします。ログイン保護はTurnstileとレート制限の併用が公式の推奨です。管理画面やステージング環境にはZero Trust Accessを置き、社員のSSO+MFAを通過しないと画面自体に到達できなくします。