01/ 02アーキテクチャ
Vercel中心アーキ
5slab.jp を Vercel に移したら何が変わるか — コンテナではなくソースを渡す、シリーズで一番毛色の違う机上検証
Vercel だけは『同じコンテナを持ち込む』が通じず、ソースを渡してビルドも実行の形も Vercel に任せます。代わりに PR ごとのプレビュー環境（+Neon の DB ブランチ連携）が標準で付き、固定費の主役は『席』（Pro $20/人・月）に変わります。
- 単位がコンテナからソースへ ── Dockerfile は使われない
- PR プレビュー + DB ブランチ連携が標準装備
- 固定費の主役は席 ── 商用は Pro $20/人から
GCP・Cloudflare・Azure の 3 本は「同じコンテナを持ち回る」話でした。Vercel だけはこの型が通じません ── コンテナを受け取らないからです。渡すのはソース（リポジトリ）で、ビルドも実行の形も配信も Vercel が決めます。この記事も Azure 編と同じく、実デプロイ前の机上検証です。
各ブロックや矢印をクリックすると、その仕組みの説明がここに表示されます。
焼いた箱を持ち回る — どのクラウドでも同じに動くのが強み
この図をテキストで読む
構成図「クラウドに「何を渡すか」が変わる」。ブロック6個、つながり4本。 枠: コンテナを渡す（GCP / Cloudflare / Azure）（ブロック3個）、ソースを渡す（Vercel）（ブロック3個）。 【ブロック】 - ソース + Dockerfile: レシピ込みで管理 - CI がイメージを焼く: レジストリに置く - 実行基盤が pull: Cloud Run・Containers・ACA - ソースだけ: Git に push する - Vercel がビルド: 焼き方は Vercel が決める - Vercel Functions: Fluid（サーバレス実行） 【流れ】 - コンテナを渡す（従来）: ソース + Dockerfile → CI がイメージを焼く → 実行基盤が pull - ソースを渡す（Vercel）: ソースだけ → Vercel がビルド → Vercel Functions