フリーランス向けクラウドサービス比較：Vercel / Supabase / Cloudflare の役割と選び方（2026年版）

Vercel・Supabase・Cloudflare のどれを選べばいいのか。結論から言うと、これは「どれか1つ」を選ぶ問いではありません。3つは役割が違い、たいていは組み合わせて使うものだからです。本記事では、3者の役割の違い、料金が跳ねる条件、個人・小規模事業の定石スタック、そして移行で詰まりやすい場所を、判断材料として整理します。

なお、この記事はコードを扱いません。実装の手順は別記事に譲り、ここでは「何を・いくらで・どう組むか」という意思決定に必要なところだけを書きます。料金は初出の2026年5月時点の各社公開情報に基づき、2026年7月の更新時に本文で触れる主要な仕様（Workers の既定公開・Vercel のリージョン・Hyperdrive の位置づけ）を公式ドキュメントで再確認しています。それでもクラウドの料金・仕様は頻繁に変わります。発注や設計の前に、必ず各社の公式ページで最新を確認してください。

役割の違い — 同じ「クラウド」でも層が違う

最初に誤解を解いておきます。3者は「Vercel と Supabase と Cloudflare、どれが優れているか」という横並びの比較対象ではありません。担当する層が違います。

Vercel は、Next.js を作った会社が運営するホスティング基盤です。Git に push すればビルドして世界中のエッジに配信し、プルリクエストごとにプレビューURLが生えます。フロントエンドのデプロイ体験はこの3者の中で頭ひとつ抜けています。半面、Vercel 自体はデータベースを持ちません（別サービスの寄せ集めは用意されていますが、本命ではありません）。

Supabase は、PostgreSQL を中心に、認証・ストレージ・リアルタイム・ベクトル検索・エッジ関数をひとまとめにした「オープンソースの Firebase 代替」です。Firebase の NoSQL と違い、中身は普通の Postgres なので、SQL・外部キー・行レベルセキュリティといった枯れた道具がそのまま使えます。アプリの裏側（データと認証）を一気に立てたいときの定番になります。DB選定の判断軸をひとつ足しておくと、完成形に自前の認証・アカウント機能があるかで決めると迷いません。Supabase は「認証込みの箱」として使ってこそ真価が出ます。認証が必要ないサイト・ツールなら、Neon のような「純粋な Postgres」や Cloudflare D1 のほうが身の丈に合うことが多いです（この判断は後述の移行の節で、実際に移した記録とともに書きます）。

Cloudflare は、もともと CDN・セキュリティの会社ですが、いまやエッジで動くコンピュート（Workers）、オブジェクトストレージ（R2）、SQLite ベースのデータベース（D1）、キーバリュー（KV）まで揃え、バックエンドを丸ごと載せられる土台に育っています。最大の特徴は後述する「エグレス（外向き通信）無料」です。

つまり、典型的には Cloudflare が一番外側の入口に立ち、Vercel がフロントを配信し、Supabase が裏でデータを持つ——という重なり方をします。3者は競合というより、層の異なる部品だと捉えると判断を誤りません。

データの置き場をどう設計するか自体に迷っているなら、サービス比較に入る前に小さな組織のためのデータ基盤の考え方を先に読むと、ここでの選択がぶれにくくなります。

料金とスケール — 「定額」ではなく「従量」で考える

3者に共通する重要な前提がひとつあります。いずれも基本は従量課金で、月額の数字は「入口の料金」にすぎません。ここを誤解すると、請求書を見て驚くことになります。

Vercel：無料枠の「商用禁止」と請求の跳ね

Vercel の Hobby プランは無期限で無料ですが、個人・非商用利用に限定されています。これはフリーランスにとって地味に効く制約です。クライアントワークや収益を生むサイトを Hobby で運用するのは規約違反になり、Pro 以上が必要になります。

Pro はシートあたり月20ドルで、同額20ドルの利用クレジットが付き、帯域1TB・エッジリクエスト1000万が含まれます。問題はその先です。Vercel の請求はエッジリクエスト、帯域、画像最適化、関数の実行時間（GB時間）など複数のメーターで動き、含まれる枠を超えると従量で上乗せされます。とくに注意したいのは、悪意あるトラフィックも含めて全通信が0.15ドル/GBで課金される点で、DDoS のコストがそのまま自分に乗ります。無料の Hobby は逆に上限到達でプロジェクトが翌月まで停止する仕様なので、本番運用には向きません。

料金ではなく速度の話ですが、同じくらい見落とされやすいのが関数のリージョン既定値です。Vercel のサーバーレス関数は、何も指定しないと米国東部（iad1）で実行されます（2026年7月時点・公式ドキュメントで確認）。日本のユーザー向けに、日本側のバックエンドと組み合わせて使っていても、既定のままでは毎リクエストが太平洋を往復します。「性能問題に見えて、実は設定1行」の典型で、Hobby プランでも vercel.json で東京（hnd1）に固定できます（Hobby は単一リージョンのみ・複数リージョンは Pro 以上）。もうひとつ、Hobby はプレビューURLに Vercel のログインが既定で掛かるため、社外のクライアントに検証URLをそのまま共有できないという地味な制約があります。

Supabase：「一時停止」と「コンピュートは家賃」

Supabase の無料枠は、500MBのデータベース、5万MAU（月間アクティブユーザー）、1GBファイルストレージ、2プロジェクトと十分に手厚いです。ただし致命的な制約があります。無料プロジェクトは7日間アクセスがないと自動的に一時停止されます。検証や試作には問題ありませんが、24時間動き続ける本番には使えません。

Pro はプロジェクトあたり月25ドルで、一時停止がなくなり、日次バックアップが付きます。ここで見落としがちなのが、コンピュート（DBの常時起動分）が基本料金とは別建てで課金されることです。常時起動するアプリでは、このコンピュートを「家賃」として最初から見込んでおく必要があります。実際、小〜中規模の本番アプリは利用料込みで月35〜75ドルあたりに着地することが多いです。もうひとつの罠は、課金がプロジェクト単位（最低25ドル/プロジェクト）なので、プロジェクトを増やすほど固定費が積み上がる点です。

Cloudflare：「エグレス無料」という構造的な強み

Cloudflare の料金は、3者の中で最も「個人に優しい」設計をしています。Workers の有料プランは月5ドルからで、R2 のオブジェクトストレージや D1 など各機能に無料枠が付き、外向き通信（エグレス）の料金がゼロ——これが効きます。帯域・エグレス無料は Vercel や Netlify に対する構造的なコスト優位で、画像や動画のような重いコンテンツを配信するほど差が開きます。

ただし無料枠には癖があります。Workers の無料枠は1日10万リクエスト（月次ではなく日次リセット）で、平均すると1秒あたり約1.16リクエストを超える本番には足りません。また課金の本丸はリクエスト数ではなく CPU 時間で、画像処理やPDF生成のような重い処理は枠を一気に消費します。D1 は読み取りが安く、書き込み（100万行あたり1ドル）が積み上がりやすいです。

組み合わせの定石 — 個人開発の現実解

役割が違う以上、現実には組み合わせて使います。フリーランス・個人開発で見かける定石は、おおむね次の3パターンに収れんします。

定石1：Vercel ＋ Supabase（最速で立ち上げる） フロントを Vercel、裏を Supabase に振る、いま最もありふれた構成。AI コーディングツールがこの組み合わせの足場を一番よく知っているので、立ち上がりが圧倒的に速いです。MVP やクライアントの検証案件など「とにかく早く形にする」局面の第一候補になります。弱点は、トラフィックが伸びたときに Vercel の帯域・関数コストと Supabase のコンピュートが二方向から効いてくることです。

定石2：Cloudflare に寄せる（コストと所有権を取りに行く） Pages でフロント、Workers でロジック、D1/R2 でデータと保存を担う、Cloudflare 一本の構成。エグレス無料が効くので、配信が重いほど・規模が出るほど割安になります。半面、Workers は Node.js ではなく V8 アイソレート上で動くため、fs やネイティブバイナリが使えず、Express のような前提のフレームワークは動きません。学習コストと「書き直し」が発生します。コストと長期の所有権を優先する人向けです。

定石3：Cloudflare（前段）＋ Vercel（配信）＋ Supabase（データ） 入口に Cloudflare を立てて帯域とDDoSを吸収し、Vercel でフロントを配信し、Supabase にデータを持たせる、いいとこ取りの構成。3者の役割分担を最も素直に体現する形で、私自身が本サイト系で採っているのもこの方向です。複雑さは増えますが、各層を最適なサービスに任せられます。

ちなみに、私が普段運用しているのは Next.js ＋ Cloudflare を軸に、データ層を案件の性質（認証の有無・データの育ち方）に応じて Supabase / Neon で使い分けるスタックです。Supabase をデータ基盤として実際にどう組むか（取り込み・変換・可視化まで）は、実装側の記事グロースのためのデータ基盤構築に手順を書いています。

移行の注意 — 囲い込みと出口戦略

最後に、選ぶときよりも「あとで動かすとき」に詰まる話をしておきます。これは発注・設計の段階で考えておくほど後で楽になります。

Supabase は出口が比較的開いている。 中身が標準の PostgreSQL なので、いざとなれば別の Postgres ホスティングへダンプして移せます。オープンソースとして自前でセルフホストする道も残されています。囲い込みの不安は3者の中で最も小さいです。

この「出口の開き方」は机上の話ではなく、実際に通ってみました。運用しているサイトのひとつで、2026年6月に Supabase から Neon（サーバーレスの Postgres）へデータ層を移しました。判断軸は前述のひとつだけ——完成形に自前の認証・アカウント機能があるか。「入れない」と確定した時点で、認証・ストレージ・リアルタイムを死蔵したまま全部入りの箱を維持する理由が消え、純粋な Postgres を提供する Neon（最小構成なら Cloudflare D1）で十分になりました。移行自体は、DBの利用が1テーブル・数箇所という極小フットプリントだったこともあり、接続部分の差し替えとスキーマ1本の適用で終わっています。教訓は二つ。第一に、移行の最安タイミングは「利用が小さいうち」です。依存が育つ前なら乗り換えコストはほぼゼロで、「いつか移すかも」と思いながら依存を積み増すのが一番高くつきます。第二に、Cloudflare の Hyperdrive を「Neon の代替」と誤解しないこと。Hyperdrive は DB 本体ではなく、既存の Postgres の前段に置く接続プール／キャッシュ層で、Neon と並ぶ選択肢ではなく組み合わせる部品です（小規模なら Hyperdrive なしで Neon に直結できます）。

Cloudflare は「思想」ごと乗るぶん、移行は重い。 Workers の V8 アイソレート前提や D1（SQLite）に最適化したコードは、そのまま他社へは動きません。エグレス無料という強みを取りに行くほど、コードがその前提に染まります。乗るなら片道だと思っておいたほうがいいでしょう。

Cloudflare にはもうひとつ、デプロイ初日に踏みやすい罠がある。 Workers は作成時に既定で *.workers.dev のURLが割り当てられ、初回デプロイの瞬間、本番ドメインとは別の「意図しない2つ目の公開URL」にサイトの完全な複製が公開されます。実際に運用しているサイトで、この重複コピーが公開されたままになっているのに後から気づきました。問題は二つあります。ひとつは SEO の索引事故——同じコンテンツが2つのURLに存在し、重複コンテンツとして検索評価が割れます。もうひとつは、このホスト名にアカウント名が含まれること。匿名や屋号で運営しているサイトでは、本名や個人アカウント名がURLとして露出する事故になり得て、相性は最悪です。対処は順序が肝心で、先にカスタムドメインを接続し、その後に設定（workers_dev: false）で workers.dev 側を無効化します。管理画面から切っただけでは、設定ファイル側に残っていると次のデプロイで復活する点にも注意したいです（詳細は Cloudflare の公式ドキュメントにあります）。

Vercel は「離れやすいが、寄せると効く」。 静的配信や標準的な Next.js なら他社へ移しやすい一方、ISR や画像最適化、Edge Config など Vercel 固有の機能に依存するほど移行コストが上がります。手軽さの裏で、知らないうちに固有機能に依存していた、というのがよくある躓きです。

判断軸としては、(1) データは標準技術（Postgres など）に寄せて出口を確保する、(2) 固有機能に乗るときは「それが移行コストに見合う強みか」を都度問う、(3) 料金は定額ではなく従量として、跳ねる条件を先に把握しておく——この3点を押さえておけば大きく外しません。

なお、サイトやプロダクトで課金まで扱うなら、決済プラットフォーム側にも同じ「手数料・税務・乗り換えのしやすさ」の論点があります。そもそも「一人でここまで実装して戦えるのか」という前提が気になる人は、なぜ今、マーケチーム1人でも実装で戦えるのかを先に読むと、本記事の位置づけが見えるはずです。

---

3者は競合ではなく、層の違う部品です。役割（ホスティング／DB／エッジ）で分担を理解し、料金は従量として跳ねる条件を先に押さえ、出口（移行コスト）を設計に織り込みます。この3つを最初に決めておけば、どの組み合わせを選んでも大きな後悔は避けられます。