Cloudflare Containers 調査・評価

本記事の前提となる Craft ERP（生成AI × 仕様駆動開発による小売業向け基幹業務システムの開発プロジェクト）の概要・目的・技術選定方針は Craft ERP Overview にまとめています。

更新履歴

2026-06-21

初版作成。「Worker 前段必須」「リージョン指定不可」「業務実績が薄い」を理由に、現時点の採用は見送りと評価した。

2026-07-14

最新の公式情報と照合し、次を反映。採用可能性を上方修正（採用見送り → 将来の移行候補・PoC 候補として前向きに評価）。

• 「リージョン指定不可」の記述を修正（placement constraints による地域・管轄制約の指定が可能になった）
• スケーリングの実態を補正（Container ID 中心のモデル。組み込み autoscaling は今後提供予定）
• Docker イメージ運用の選択肢を追記（Dockerfile ビルド / Docker Hub / Amazon ECR / Google Artifact Registry）
• Outbound handlers による Workers Bindings 連携を追記
• 永続化（fresh disk / R2 FUSE）・Egress 料金・ロールアウト時のバージョン差を追記

1. 背景

既存の評価（Cloudflare Workers・コンテナ基盤・PostgreSQLサービス比較評価）では、バックエンド実行基盤として「Cloudflare Workers + Hono」と「FastAPI + コンテナ」を比較した。このとき Workers 案には、本プロジェクトにとって次の難点があった。

• 既存の FastAPI 資産（Craft Personal などの実装知見）を直接活用できない
• TypeScript / Hono への移行・再学習が必要

その後 Cloudflare Containers が一般提供（GA）に至り、次の構成が現実的に成立しうる状況になった。

FastAPI
↓
Docker
↓
Cloudflare Containers

これは AWS ECS（Fargate）/ Google Cloud Run / AWS App Runner と同様に「Docker イメージをそのまま実行する」アプローチであり、FastAPI / Docker 資産を捨てずに Cloudflare のネットワーク・セキュリティ機能を享受できる可能性がある。本ドキュメントは、その可能性を技術・運用・コストの観点から評価する。

2. Cloudflare Containers の機能整理

実行モデル（最重要）

Cloudflare Containers は、エンドユーザーから直接 HTTP を受けない。リクエストはまず Worker に入り、Worker のコードがコンテナインスタンスへ転送する。コンテナインスタンスは Durable Object によって管理され、オンデマンドに起動される。

エンドユーザー
↓ HTTP
Cloudflare Worker（ルーティング / 認証 / WAF 前段）
↓ fetch 転送
Container インスタンス（Durable Object backing）
  └ FastAPI（ポートを listen する通常の Docker イメージ）
↓
PostgreSQL（Neon / Supabase など）

つまり「コンテナを置けば終わり」ではなく、最低限のルーティング用 Worker を必ず書く必要がある。これは ECS / Cloud Run / App Runner が「コンテナ単体で HTTP エンドポイントになる」のと大きく異なる。

Instance types（確認日 2026-06-21）

カスタム指定も可能だが、上限は vCPU 4 / メモリ 12 GiB / ディスク 20 GB。1 インスタンスあたりのスペック上限が低めである点は、重い集計・大容量バッチを単一インスタンスで処理する用途では制約になりうる。

アカウント上限・課金

• 同時実行上限: メモリ 6 TiB / vCPU 1,500 / ディスク 30 TB、イメージ総容量 50 GB
• コールドスタートは概ね 1〜3 秒（イメージサイズと初期化に依存）
• 課金はアクティブ稼働 10ms 単位（メモリ/CPU/ディスク）。$5/月 Workers Paid に無料枠が含まれる。Egress は地域ごとに単価と無料枠が異なる

スケーリング / ルーティング（確認日 2026-07-14）

• Container はオンデマンド起動でき、sleepAfter（例: 10分無アクセスで停止）で scale-to-zero 的な使い方が可能
• ただし ECS / Cloud Run のような組み込み自動スケーリングとは異なり、現時点では Container ID を指定して起動・管理するモデルが中心。Stateless 用途では getRandom により固定数の Container へランダムに振り分けられる
• 組み込みの高度な autoscaling / latency-aware routing は「今後提供予定」とされている
• 業務 API として採用する場合は、インスタンス数・起動単位・ルーティング方針・セッション設計を事前に検証する必要がある

配置（placement constraints、確認日 2026-07-14）

• デフォルトでは、事前配布済みイメージのあるリクエストに近いロケーションに配置される
• placement constraints により、地域・管轄の配置制約を指定できる（初版時の「リージョン指定不可」は現在の情報では古い）
• regions: ENAM / WNAM / EEUR / WEUR / APAC / SAM / ME / OC / AFR などの広域指定（容量の少ない ME / OC / AFR は単独指定不可）
• jurisdiction: eu（EU データレジデンシ）、fedramp などの管轄制約
• ただし日本国内固定・東京リージョン固定のような国・都市単位の指定はできない。医療・個人情報・業務データのデータレジデンシ要件がある場合は、採用前に公式仕様と契約条件を確認する必要がある

3. ECS / Cloud Run / App Runner との比較

相対比較であり、一般論として一方が優れているという意味ではない。料金はリージョン・時期で変動するため、AWS/GCP 側は「モデル」の比較として扱う。

4. FastAPI 利用可否

• 利用可能。Container は通常の Linux 環境で動くため、FastAPI を Uvicorn 等でポート listen させた Docker イメージはそのまま動作する。既存 backend/dockerfile の構成を大きく変える必要はない。
• ただし前段に ルーティング用 Worker が必須。「公開エンドポイント = Worker、実処理 = Container 内 FastAPI」という二層構成になる。
• 長時間処理・WebSocket・SSE は、Worker 経由のリクエスト寿命と sleepAfter/起動挙動を踏まえた設計が必要。
• 認証を Worker 側（Cloudflare Access / 独自認証）と FastAPI 側のどちらで持つか、二層での責務分担を決める必要がある。

5. Docker 資産の移行性

• 既存の backend/dockerfile / requirements.txt はおおむね再利用できる見込み。「ポートを listen するイメージ」という前提は ECS/Cloud Run/App Runner と同じ。
• イメージ運用の選択肢が広がっている（確認日 2026-07-14）: wrangler deploy 時に Dockerfile からビルドして Cloudflare 管理レジストリ（registry.cloudflare.com）へ push できるほか、外部レジストリとして Docker Hub / Amazon ECR / Google Artifact Registry のイメージを利用できる。
• ただし外部レジストリからの pull はキャッシュされず、Docker Hub のレート制限や AWS/GCP 側の Egress 課金に注意。
• イメージサイズはインスタンスのディスク容量以内（最大 20 GB、総容量 50 GB）。
• 差分として Worker（ルーティング層）と wrangler ベースのデプロイ設定を新規に用意する必要がある。
• CI/CD は現状 GitHub Actions → GHCR → VPS。GHCR は公式の対応レジストリに記載がないため、GHCR をそのまま使えるか、Docker Hub / ECR / Cloudflare Registry へ寄せるべきかは採用前に検証する。既存 CI/CD の流用可否は利用レジストリによって変わる。

6. 永続化 / ネットワーク / Secrets

• 永続化: ディスクはすべてエフェメラル。Container が sleep すると次回起動時のディスクは基本的に fresh disk（イメージ定義の初期状態）になる。業務データは PostgreSQL などの外部 DB、ファイルは R2 などのオブジェクトストレージに置く。R2 を FUSE でマウントする選択肢もあるが、ネイティブ SSD 同等の性能は前提にしない。Craft ERP では業務データの永続化先として Container ローカルディスクは使わない。
• ネットワーク: エンドユーザーからの非 HTTP 直アクセスは不可。アウトバウンドは既定で可能なので外部 API 連携・DB 接続は問題なし（enableInternet = false で遮断も可）。
• Outbound handlers / Workers Bindings 連携（確認日 2026-07-14）: Container からの HTTP(S) 通信を Worker Runtime 側の Outbound handlers でインターセプトできる。Container 内から Cloudflare 固有 SDK を直接使わずに KV / R2 / D1 / Durable Objects などの Bindings と連携でき、認証ヘッダーの注入や allowedHosts / deniedHosts による通信先制御にも使える。Container 内に Secret や Cloudflare 依存ロジックを過度に持たせず、Worker 側へ寄せられる可能性がある。
• Secrets: Worker/Containers のシークレット機構（wrangler secret 等）に集約する。.env 直読みではなくプラットフォーム機構に寄せる。

7. 運用（デプロイ / ロールバック / ログ / モニタリング）

• デプロイ: イメージを Cloudflare Registry に push し、wrangler でデプロイ。グローバル配布される。
• ロールアウト / ロールバック: コンテナはローリングデプロイ方式（既定では 10% → 90% の段階反映、graceful shutdown を伴う）。Worker コードは即時反映される一方、Container は段階的に反映されるため、一時的に Worker と Container のバージョン差が発生する。ロールアウト完了までは API 仕様・通信プロトコルに後方互換性を持たせる必要がある。
• ログ / モニタリング: 各コンテナでログ・メトリクス収集が自動セットアップされ、Cloudflare の Observability に集約できる。
• 運用負荷: ホスト管理は VPS/ECS より軽い。一方で「Worker + Container の二層」を運用対象として理解する必要がある。

8. PostgreSQL 接続（Neon / Supabase / Hyperdrive）

• 重要な差分: Hyperdrive は Worker 用のバインディングであり、Container 内のアプリから直接利用するものではない。
• Container 内の FastAPI からは、Neon / Supabase へ通常の PostgreSQL ドライバ（psycopg 等）で直接接続できる。Workers 案で必須だった「Hyperdrive 経由・接続プール前提」という制約が外れ、コンテナ案の素直さが活きる。
• 接続プーリングは Neon/Supabase 側のプーラ（PgBouncer 等）やアプリ側のプール設定で対応。サーバーレス DB と短命コンテナの組み合わせではコネクション数上限に注意。

9. スケーリング

• 起動モデル: Container はオンデマンド起動でき、sleepAfter によるアイドル停止で scale-to-zero 的な使い方が可能。ただし現時点では Container ID を指定して起動・管理するモデルが中心で、ECS / Cloud Run のような組み込み自動スケーリングとは異なる。
• Stateless 用途: getRandom により、事前に決めた固定数の Container へリクエストをランダムに振り分けられる（位置を考慮しないランダム選択）。
• 今後: 組み込みの autoscaling / latency-aware routing は公式に「今後提供予定」とされている。
• 起動速度 / コールドスタート: 1〜3 秒。イメージを小さく保つほど有利。
• 配置: デフォルトは最寄りの事前配布イメージから起動。placement constraints で広域リージョン・管轄の制約を指定できる（国・都市固定は不可）。
• 業務 API として採用する場合は、インスタンス数・起動単位・ルーティング方針・セッション設計の事前検証が必要。重い集計・大きめバッチは 1 インスタンス上限（4 vCPU / 12 GiB）を踏まえた分割設計が要る。

10. セキュリティ

前段が Worker のため、WAF / Zero Trust / Cloudflare Access / MFA を実行基盤と一体で適用しやすい。これは ECS/Cloud Run/App Runner（前段に別途 WAF/IdP を構成）に対する明確な利点。認証境界を Worker 層に置けるため、「公開面は Cloudflare、内部処理は Container」という多層防御が組みやすい。

11. コスト比較

• 課金モデル: Containers はアクティブ稼働分が 10ms 単位で課金される。Workers Paid（月額 $5）にメモリ・CPU・ディスクの無料枠が含まれる。Egress は地域ごとに単価と無料枠が異なるため、外部 DB・外部 API・ファイル配信が多い構成では Egress も見積もり対象にする。
• 小規模・低トラフィック: scale-to-zero と 10ms 課金が効き、Cloudflare 案が割安になりやすい。常時起動前提の ECS Fargate よりアイドルコストで有利。
• 常時稼働・安定負荷: 予測しやすさでは VPS 常駐や App Runner のプロビジョン課金が読みやすい。
• 大容量データ・重い集計・大きめバッチ: 1 インスタンス上限と Egress 課金が効く。ECS/Cloud Run の大型インスタンスに分がある場面も。
• 本プロジェクト前提（初期 50GB・年 10GB 増・最大 100 店舗）での実コストは、利用パターンが見えた段階での試算項目とする。

Cloudflare の単価は確認日 2026-06-21 時点。AWS/GCP の料金はリージョン・時期で変動するため、採用前に各公式の料金計算ツールで再試算する。

12. Craft ERP 視点での評価

Workers + Hono 案と比べた最大の利点は、FastAPI + Docker をほぼ維持したまま Cloudflare に乗れること。一方で「Worker 前段が基本」「Worker + Container + Durable Object という Cloudflare 特有の実行モデルの理解が必要」「業務システムでの実行基盤実績がまだ薄い」という点は引き続き踏まえる必要がある。

13. 採用可能性の評価（2026-07-14 上方修正）

Cloudflare Containers は、FastAPI + Docker をそのまま活かしながら Cloudflare Workers Platform 上で動かせる現実的な選択肢になっている。

• 初期評価時（2026-06）と比べると、地域・管轄の配置制約（placement constraints）、外部レジストリ対応、Outbound handlers、ログ統合などが整備され、実用性は高まっている。初期評価の見送り理由の一つだった「リージョン指定不可」は、現在の情報では古い。
• 一方で、公開エンドポイントは Worker 前段が基本であり、Worker + Container + Durable Object という Cloudflare 特有の実行モデルを理解する必要がある。
• Stateless API バックエンドとしてのスケーリング・ルーティングは ECS / Cloud Run / App Runner ほど単純ではなく、現時点では Container ID や固定数ルーティングの設計が必要になる。
• Craft ERP では、初期フェーズの最優先事項を「生成AI × 仕様駆動開発の確立」と「基本業務機能の実装」に置くため、今すぐ本番基盤として採用するのは見送る。
• ただし、リージョン制約や運用機能の改善により、将来候補としての評価は上方修正する。将来的な移行候補・PoC 候補として前向きに扱う。
• Cloudflare は当面 CDN / WAF / Access 用途での併用可能性を残す。

14. Cloudflare Containers を採用したくなる理由

今回の再調査により、Cloudflare Containers は単なる実験的なコンテナ実行環境ではなく、FastAPI + Docker 構成の移行先として十分に検討できる段階に近づいていると感じた。

特に魅力的なのは、Cloudflare Workers、R2、KV、D1、Durable Objects、WAF、CDN、Zero Trust などの Cloudflare Platform と、Docker ベースのバックエンドを同じ運用思想の中で扱える点である。

Craft ERP のような個人開発プロジェクトでは、インフラ運用の複雑さを減らし、アプリケーション開発に集中できる構成は非常に魅力的である。そのため、現時点では本番採用を急がないものの、将来的には小さな API や非同期処理、管理系ツール、検証環境などから PoC を行い、段階的に採用可能性を確認したい。

15. PoC で検証したい項目

• FastAPI アプリを Cloudflare Containers で起動できるか
• PostgreSQL / Neon / Supabase など外部 DB へ安定接続できるか
• placement constraints で APAC 指定した場合の挙動
• 起動時間、sleep 復帰時間、レスポンス遅延
• getRandom による複数 Container 振り分け
• Worker 前段での認証、ルーティング、ログ出力
• Outbound handlers による R2 / KV / Durable Objects 連携
• Egress 料金の実測
• GitHub Actions からのデプロイ経路
• GHCR をそのまま使えるか、または ECR / Docker Hub / Cloudflare Registry へ寄せるべきか
• 本番障害時のログ確認、ロールバック、再起動手順

付記

• 本資料は判断の背景・採用理由・懸念事項を含めて公開することを意図している。
• サービス仕様・料金は変動が速い。再評価時には各サービスの公式情報と確認日を必ず更新すること。
• 主な出典（初版確認日 2026-06-21）: Cloudflare Containers ドキュメント（概要 / Limits and Instance Types / Platform details / Pricing）、Containers public beta 発表（2025年6月）、Cloudflare Hyperdrive。
• 2026-07-14 更新時に確認: Placement / Scaling and Routing / Image Management / Workers Connections / Outbound Traffic / Architecture / Rollouts