2026年6月30日、Vercel は Dockerfile.vercel を発表。プロジェクトにこのファイルを置くだけで、任意の Dockerfile を Vercel の本番環境にそのままデプロイできるようになりました（それ以前の5月29日には、開発用サンドボックス内での Docker 実行にも対応済み）。
既存の Dockerfile をほぼそのまま流用可能。条件は「HTTP サーバとして $PORT（デフォルト80）で待ち受けること」だけ。
Vercel Container Registry（VCR）にイメージが保存される。FFmpeg などシステムライブラリ依存のアプリも OK。
Fluid compute 基盤の上で動き、リクエストに応じて自動増減。本番で5分間アクセスが無いと自動でゼロにスケールダウン＝アイドル時は課金ゼロ。
| 項目 | 内容 |
|---|---|
| 課金方式 | Active CPU 課金：CPU が実際に計算している時間だけ課金。DB 応答待ちなどの I/O 待ち時間は課金されない。アイドル時はゼロ |
| 実行時間の上限 | デフォルト300秒。Pro プランで最大800秒（約13分）が正式提供。1,800秒（30分）はベータ（Node.js / Python 限定） |
| CPU / メモリ上限 | デフォルト 1vCPU / 2GB → 最大 2vCPU / 4GB（Pro） |
| 動作モデル | ステートレス（リクエストを受けて返す型）。常駐プロセス・永続 WebSocket・キュー常時監視（Celery 型）は非対応 |
| 未対応機能 | Secure Compute（専用ネットワーク分離）、固定送信元 IP |
| 補足 | Vercel Queues（キュー基盤）が2026年2月にパブリックベータ入り。将来的に Celery の代替になり得るが、まだベータ |
| 役割 | 判定 | 理由 |
|---|---|---|
| フロント Next.js ×2 | ◎ Vercel 本命（変わらず） | そもそも Docker 不要。通常の Next.js デプロイが最速・最適。東京リージョン（hnd1）指定可 |
| API（FastAPI） | ○ 新たな有力候補 | 公式に FastAPI を対応例として明記。既存 Dockerfile がほぼそのまま動き、フロントと同じ Vercel に集約できる。Cloud Run と比較検討の価値あり |
| 解析ワーカー（Celery + MediaPipe/YOLO/ffmpeg） | △ 今は不適 | Celery の「キューを常時監視する常駐型」が非対応。載せるなら HTTP 起動型への再設計＋Vercel Queues（ベータ）が必要 |
| スケジューラ（Celery beat） | △ 代替あり | 常駐プロセスは非対応だが、Vercel Cron Jobs（定時実行機能）で置き換え可能 |
スペック面では、現在の解析ワーカー（Fargate 1vCPU / 2GB）に対し Vercel は最大 2vCPU / 4GB と上回っています。ネックは①1本の解析が800秒（13分）に収まるか、②Celery からの再設計コスト、の2点。つまり「性能不足で無理」ではなく「アーキテクチャの型が合わない」が現状の結論です。
Docker 対応といっても、動くのは「Vercel Functions（サーバーレス関数）としての Docker」です。ECS のような常時起動のコンテナサーバが持てるようになったわけではありません。「リクエストが来たら起動して、返したら休む」型に合う処理（API サーバ）には最適ですが、「キューを監視し続ける」型（Celery ワーカー）はそのままでは載りません。
「Workers」単体では解析は動かせません。同じ Cloudflare の「Containers」という別製品なら技術的には動かせます。ただし Containers は現時点で日本（東京）にリージョン指定できないため、解析ワーカーの本命は Cloud Run（東京）のままという評価です。
Workers は「超軽量な JavaScript 実行環境」で、いわばコンビニのレジのような存在。1リクエストをさばくのは速いが、重い計算は担えません。
Workers の適所は「署名付き URL の発行」「キューへのジョブ投入」といった解析の前後の軽い糊付け役です。
Vercel の Docker 対応と似た「サーバーレスで Docker を動かす」サービスですが、制約が緩いのが特徴。Python も ffmpeg もそのまま動き、Vercel で問題だった800秒制限もありません。
| 項目 | Cloudflare Containers | 参考：現行ワーカー（Fargate） |
|---|---|---|
| スペック上限 | 4 vCPU / 12GB メモリ / 20GB ディスク | 1 vCPU / 2GB |
| 実行時間の上限 | なし（自分で終了を制御） | なし |
| ゼロスケール | ◎ スリープ中は課金ゼロ | ✕ 常時2台課金 |
| 料金 | 使った分だけ（vCPU秒＋メモリ秒。ざっくり 2vCPU で5分の解析1本 ≒ 2〜3円） | 常時稼働の固定費 |
位置づけとしては、「R2 + Pages + Containers で Cloudflare に全部集約する」という将来の夢筋はあるものの、東京リージョン対応が来るまでは解析ワーカーの推奨（Cloud Run 東京 or ECS オートスケール化）を変える材料にはならない、という判断です。
| 項目 | 現状 |
|---|---|
| ストレージ | AWS S3（東京リージョン ap-northeast-1、バケット swingcompass-*）、boto3 経由 |
| アップロード | フロント →（バックエンド経由）→ S3。100MB・60秒上限 |
| 配信 | 署名付きURL（1時間有効）で S3 から直接配信。CloudFront（CDN）なし |
| 解析パイプライン | Celery が動画を /tmp にダウンロードして処理(back/front 両方、フレーム抽出のたびに読み込み) |
| 生成物 | processed/ に JSON・CSV・サムネ・デバッグ動画を無期限保存 |
| 自動削除 | 未実装（溜まり続ける） |
| コード移植性 | ストレージ抽象化済み。R2 移行は環境変数の差し替えがほぼ中心で容易 |
設計上 S3 固有機能（CloudFront連携・S3イベント通知・ACL）にほぼ依存していないため、移植性は高い。
| 項目 | AWS S3（東京） | Cloudflare R2 |
|---|---|---|
| 保管料 | $0.023 / GB・月 | $0.015 / GB・月（約35%安い） |
| エグレス（DL転送量） | $0.114 / GB（月100GBまで無料、以降10TBまでこの単価） | $0（完全無料）← 最大の差 |
| 書込系リクエスト | $4.70 / 100万回 | $4.50 / 100万回 |
| 読込系リクエスト | $0.37 / 100万回 | $0.36 / 100万回 |
| 無料枠 | なし（転送の月100GBのみ） | 保管10GB・書込100万・読込1000万/月 |
| 規模 | 保管量 / 月間閲覧数 | 転送量 | S3 月額 | R2 月額 |
|---|---|---|---|---|
| 小 | 100GB / 5,000回 | 200GB | 約 $26 | 約 $2.5 |
| 中 | 500GB / 25,000回 | 1TB | 約 $128 | 約 $10 |
| 大 | 2TB / 100,000回 | 4TB | 約 $512 | 約 $40 |
※1ドル≒150円換算。閲覧サイズ・再生回数は仮置き。ポイントは絶対額より「伸び方」——S3 は事業が伸びるほどエグレスが青天井で増えるが、R2 はほぼ横ばい。成長するほど差が開く構造。
メリット
デメリット
メリット
デメリット
スウィング動画は「特定の個人が識別できる映像」で、個人情報保護法（APPI）上の個人データに該当します。S3東京は国内保管が明確。R2 は海外（Cloudflare の分散網）に保管され得るため、プライバシーポリシーで「外国にある第三者への提供／越境保管」を適切に開示できれば運用可能ですが、ここを詰める必要があります。国内保管を厳格に約束したいなら S3東京（または R2 の所在確認）が必要。
バックエンドは AWS 東京の ECS Fargate で稼働中（第2部で確認済み）。つまり解析パイプラインの S3 読み込みは現状無料です。R2 に移すとクラウド跨ぎになりますが、R2 のエグレスは無料なので追加課金は発生しません（わずかなレイテンシ増のみ）。なお将来バックエンドを AWS 外（Cloud Run / Vercel 等）に出す場合、S3 のままだと解析の読込にもエグレス課金が発生するため、R2 移行の価値はさらに上がります。
processed/ のデバッグ動画や JSON が無期限で溜まり続けています。S3 / R2 どちらでも設定できるので、移行と同時に「N日後に自動削除」ルールを入れるのがおすすめ（R2 にもライフサイクル機能あり）。これは移行の有無と無関係に必要な整理です。
| 作業 | 難易度 | 内容 |
|---|---|---|
| コード変更 | 低 | 環境変数差し替え中心（S3_ENDPOINT_URL を R2 へ、AWS_REGION=auto）。LocationConstraint と head_object のエラー処理を微調整 |
| 既存データ移行 | 低〜中 | Cloudflare の Super Slurper（一括コピー）または Sippy（アクセス分から段階移行）で S3 から無停止移行可能 |
| 配信ドメイン | 低 | R2 にカスタムドメインを割り当て、CDN 経由配信に |
| ライフサイクル | 中 | この機会に自動削除ルールを新規実装（移行と無関係に必要） |
第1部の結論：移行を前向きに進める価値が高い。動画アプリでエグレス無料は本質的に強く、保管料も安く、コード変更も小さく、CDN が標準で付く。唯一きちんと整理すべきは「個人情報の保管場所をどう扱うか」の一点のみ。
| 役割 | 中身 | 稼働 |
|---|---|---|
| フロント（ユーザー / 管理） | Next.js × 2 | Fargate 常時2タスク |
| API | FastAPI | Fargate 常時2タスク |
| 解析ワーカー | Celery（MediaPipe + YOLO + ffmpeg） | Fargate 常時2タスク（1vCPU/2GB） |
| スケジューラ | Celery beat | Fargate 常時1タスク |
| 周辺 | ALB / RDS Postgres17 / ElastiCache Redis / WAF / NAT Gateway | 常時稼働 |
ドメインは beta.swingcompass-ai.com。ML 処理は GPU 不使用の CPU ベース（＝移行先の選択肢が広い、という好材料）。
解析は「アップされた時だけ」走るバースト型なのに、誰もアップしていない深夜も2台分の Fargate 料金を払い続けている。「処理がある時だけ起動、無い時はゼロ」にできるかが最大のコスト差。
Next.js は Vercel / Cloudflare 向き。Fargate 常時起動は割高かつ過剰。Vercel（hnd1 東京）がチーム標準であり、ここはズレている。
ALB + NAT Gateway + WAF。特に NAT Gateway は使っていなくても月$30〜45 + 通信処理料が効く「見えないコスト」。
| 役割 | 本命 | 理由・補足 |
|---|---|---|
| フロント×2 | Vercel（hnd1 東京）or Cloudflare Pages | チーム標準。Fargate 2タスク削減＋世界配信＋運用ゼロ。R2 に寄せるなら Cloudflare Pages で「Cloudflare 集約」も筋が良い |
| API（FastAPI） | Cloud Run（東京）／ Vercel Docker（新登場の対抗馬）／ Fly.io（nrt） | 3つとも「使った分だけ課金＋ゼロスケール」。Vercel Docker を選ぶとフロントと運用先を1つに集約できるのが新しい魅力。固定 IP や専用ネットワークが要件になるなら Cloud Run |
| 解析ワーカー | Cloud Run（東京）or ECS のままオートスケール0〜N台 | Celery 型常駐は Vercel 非対応のためここは従来推奨のまま。Cloud Run はキュー連動でゼロスケール可。将来 Vercel Queues の GA や Cloudflare Containers の東京対応が来たら再検討の余地 |
| スケジューラ | 移行先の Cron 機能（Cloud Run Scheduler / Vercel Cron） | Celery beat の常時1タスクを削減できる |
| Redis | 現状維持（ElastiCache）or Upstash（東京・従量） | ゼロスケール構成に寄せるなら従量制の Upstash が噛み合う |
| DB | Neon（東京）に集約 | チーム標準。RDS を Neon へ寄せて VPC / NAT ごと畳めると構成が大幅に簡素化（※RDS が現役かは要確認） |
フロント＋API を Vercel Docker に、ワーカーだけ Cloud Run。運用先が実質2つ（Vercel + Cloud Run）に減り、デプロイ体験も統一される。Docker 対応で現実味が出た構成。
Cloudflare Pages/R2（配信・保管）＋ Cloud Run（API＋ワーカー）＋ Neon（DB）。固定費が小さく波に強い。R2 移行と最も相性が良い王道構成。
①フロントを Vercel へ ②ワーカーをオートスケール化 ③NAT Gateway 見直し。移行リスク最小で無駄だけ削る。DB・ドメイン・シークレットは動かさない。
方向が決まり次第、選んだパターンの月額ざっくり試算と具体的な移行手順を、第1部（R2）と同じ粒度で詰めます。