Cloudflare Containers 調査・評価

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
• sleepAfter（例: 10分無アクセスで停止）で scale-to-zero、max_instances で同時起動数の上限
• 配置は Region:Earth（地球規模）で、特定リージョン指定は不可
• コールドスタートは概ね 1〜3 秒（イメージサイズと初期化に依存）
• 課金はアクティブ稼働 10ms 単位（メモリ/CPU/ディスク/Egress）。$5/月 Workers Paid に無料枠が含まれる

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 と同じ。
• イメージは Cloudflare の Registry に push してグローバル配布。サイズはインスタンスのディスク容量以内（最大 20 GB、総容量 50 GB）。
• 差分として Worker（ルーティング層）と wrangler ベースのデプロイ設定を新規に用意する必要がある。
• CI/CD は現状 GitHub Actions → GHCR → VPS。Cloudflare 採用時は「イメージ push + wrangler deploy」へ組み替えが必要。

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

• 永続化: コンテナのローカルディスクは揮発前提。状態は PostgreSQL / R2 等に外出し。Craft ERP は PostgreSQL 中心設計のため親和性は高い。
• ネットワーク: エンドユーザーからの非 HTTP 直アクセスは不可。アウトバウンドは可能なので外部 API 連携・DB 接続は問題なし。
• Secrets: Worker/Containers のシークレット機構（wrangler secret 等）に集約する。.env 直読みではなくプラットフォーム機構に寄せる。

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

• デプロイ: イメージを Cloudflare Registry に push し、wrangler でデプロイ。グローバル配布される。
• ロールバック: コンテナはローリングデプロイ方式（graceful shutdown）。Worker 側はバージョン管理・即時切替が可能。
• ログ / モニタリング: 各コンテナでログ・メトリクス収集が自動セットアップされ、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. スケーリング

• 自動スケール: max_instances の範囲でオンデマンドに増減。sleepAfter でアイドル停止（scale-to-zero）。
• 起動速度 / コールドスタート: 1〜3 秒。イメージを小さく保つほど有利。
• グローバル配置: 標準でグローバル。ただしリージョン指定は不可。
• 業務システム特性（CRUD・ページング・集計）には十分機能するが、重い集計・大きめバッチは 1 インスタンス上限（4 vCPU / 12 GiB）と実行モデルを踏まえた分割設計が要る。

10. セキュリティ

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

11. コスト比較

• 小規模・低トラフィック: 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 前段必須」「リージョン指定不可」「業務システムでの実行基盤実績がまだ薄い」という制約が残る。

13. 採用可能性の評価

• 現時点の採用は見送り。7月開始予定の開発で最優先するのは生成AI × 仕様駆動開発と基本業務機能の実装であり、Worker/wrangler/Containers の新規習得を同時に抱え込みたくない。リージョン指定不可と業務実績の薄さも現段階の不確実性を増やす。
• 既存方針（FastAPI + Docker + PostgreSQL）を維持しつつ、Cloudflare Containers は ECS/Cloud Run/App Runner と並ぶ「将来の有力候補」として位置づける。Workers + Hono 案よりは FastAPI 資産を活かせる分だけ Craft ERP との距離は近い。
• Cloudflare は当面 CDN / WAF / Access 用途での併用可能性を残す。

14. 将来の再評価条件

• Worker + Containers の小さな PoC（FastAPI 1 サービス + Neon 直接接続）で起動・コールドスタート・DB 接続を実測
• 大きめ CSV 取込 / バッチ処理を Containers 上で検証（実行時間・メモリ・分割設計）
• 実運用コストの把握（同時アクセス・Egress・稼働時間が見えた段階で試算）
• 業務システムでの Containers 運用実績・事例の蓄積
• リージョン/データレジデンシ要件の確定（Region:Earth で許容できるか）

付記

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