VercelとCloudflareの違い｜全面移行を検討してやめた3つの理由と社内アプリの使い分け

結論から言います。VercelとCloudflareのどちらか一方を選ぶ必要はありません。一般に公開するWebアプリはVercel、社員や特定メンバーだけが使う社内アプリはCloudflare、という分け方が、非エンジニアには一番わかりやすい線引きです。

VercelとCloudflareの違い VercelとCloudflareは、どちらもGitHubに保存したコードをインターネット上で動かすサービスです。GitHubへのpushで自動的に公開が更新される点は共通しています。分かれるのはアクセス制限の考え方で、VercelのDeployment Protectionは、無料プランの範囲では開発中のプレビュー画面を関係者だけに見せる用途が中心です。CloudflareのAccessは、アプリそのものの入口に「この会社のメールアドレスの人だけ」といった条件を置く用途に向きます。

みやっち🧑‍💻は2026年9月に、自社の構成をCloudflareへ全面移行するかどうかを本気で検討して、見送りました。この記事では、その判断の中身と、実際にどう使い分けるかを書きます。

VercelとCloudflareを4つの観点で比べる

仕様は各社の公式ドキュメントで2026年9月4日に確認したものです。料金の金額は変動が速いので、ここではプランの構造だけを書きます。

出典はVercelのgit連携、Vercel Deployment Protection、Cloudflare Accessのポリシー、Cloudflare Workers Buildsのgit連携です。

表を見て分かるとおり、GitHubにpushしたら公開される、という一番おいしい部分は両方とも同じです。だから「乗り換えないと自動デプロイができない」ということはありません。

Vercelとは

Vercelは、GitHubに保存したコードを受け取って、ホームページやアプリをインターネットに公開するサービスです。最初に一度GitHubとつなげば、以後はGitHubに保存し直すたびに公開中のサイトが自動で更新されます。Next.jsを開発している会社でもあります。

Cloudflare Workersとは

Cloudflare Workersは、Cloudflareのネットワーク上でアプリのプログラムを動かす仕組みです。サーバーを借りて管理する代わりに、コードだけを置くと世界中の拠点で実行されます。データベースやファイル置き場、AIといったCloudflareの他のサービスを、設定1行でつなげて使えるのが特徴です。

そもそもデプロイとは

デプロイとは、作ったプログラムを実際に動く場所に配置して、使える状態にすることです。GitHubに保存したコードをVercelやCloudflareが受け取り、インターネットからアクセスできるURLとして公開するまでの一連の流れを指します。

なぜいま「どこで動かすか」の話が急に増えたのか

理由は1つです。AIによって、コードを書くコストが急激に下がったからです。

これまでの開発は、次の順番で進んでいました。

アイデア → 要件定義 → エンジニアが実装 → テスト → 公開

このうち最大のボトルネックは「実装」でした。作りたいものが決まっても、書ける人がいなければ止まる。だから「誰がコードを書けるか」が価値の中心にありました。

ところがClaude CodeやCodexのようなAIエージェントを使うと、「こういうアプリを作って」と伝えるだけで、以前なら人手では簡単に用意できなかった規模のものが、対話の延長でできてしまいます。そうなると、次に詰まる場所が移ります。そのコードを、どこで安全に・すぐに・安定して動かすのかです。

コードができただけでは、誰も使えません。実際に人が使う状態にするには、この一連が必要になります。

1. 実行環境に載せる
2. URLが発行される
3. データベースやログインにつながる
4. アクセスが増えても止まらない
5. うまく動かないときにログを見られる
6. 直したらすぐ公開が更新される

ここを丸ごと引き受けるのが、VercelやCloudflareです。データベースの扱いだけは分かれていて、Cloudflareは自社のものが同じ場所に揃い、Vercelは提携先のデータベースを管理画面からつなぐ形になっています。

AIにとって理想の形は、はっきりしています。コードを書いたら、コマンド1つかGitHubへのpushだけで、URL付きで動くことです。みやっち🧑‍💻はこの2社を、単なるサーバーの貸し屋ではなく、コードを現実世界で動かすためのOSのようなものになりつつある、と捉えています。

みやっち🧑‍💻の整理では、こう置き換えられます。

• Claude Code・Codex — 手を動かす開発担当者
• GitHub — 共有の設計図と履歴
• Vercel・Cloudflare — 成果物が実際に稼働する現場

もう少し踏み込むと、実行基盤の価値が上がる理由は3つに分かれます。

1つ目は、作る本数が桁で変わることです。 AIエージェントは、LPも、社内ツールも、APIも、お客さんごとの小さなアプリも、一時的な管理画面も、自動化用の裏側も作れます。1本あたりのコストが下がると、社内で使うツールは1本ではなく数十本に増えていきます。数十本を運用する問題は、1本を運用する問題の数十倍ではありません。質が違います。「1本ごとにサーバーを設定する」前提の基盤は、この時点で選択肢から落ちます。

2つ目は、操作する主体がAIに変わると、基盤の評価軸そのものが変わることです。 これまで価値だったのは、管理画面の使いやすさでした。いまの価値は、コマンドと設定ファイルだけで最初から最後まで進めるかどうかです。管理画面でしかできない操作は、AIエージェントにとっては壁になります。

3つ目が一番本質的で、実行基盤がフィードバックの輪を閉じることです。 AIが自分で直せるのは、動かして結果を見られるときだけです。URLが立ち、ログが読め、pushで更新される。この3つが揃って初めて、人間の仕事が判断だけになります。単に置き場所を借りる話ではなく、AIに任せ切れるかどうかの前提条件だと考えています。

まとめると、AIエージェントが増えるほど、最後の「じゃあ、これをどこで動かすのか」を握っているところが強くなる、ということです。

みやっち🧑‍💻がCloudflareへの全面移行をやめた3つの理由

AI Crewの公式サイトと株式会社AI Orchestraの会社サイトは、どちらもGitHub連携のVercelで動いています。ここをCloudflareに寄せるべきか検討して、次の3点で見送りました。

1つ目は、ログイン機能の置き換え先が別に要ることです。 Cloudflare Accessは強力ですが、性格が違います。Accessは「アプリに到達できる人を、あらかじめ決めた条件で絞る」仕組みで、公式ドキュメントでも既定は全拒否と説明されています。社内向けの入口を守るには最適ですが、一般ユーザーが自分でアカウントを作って自分のデータだけを見る、という消費者向けのログインとは役割が違います。そこが必要なら、結局Supabaseのような外部サービスを組み合わせることになります。

2つ目は、自分の構成では移行の利得が出ないことです。 Cloudflareの分かりやすい強みは、データベースやファイル置き場やAIが同じ場所に揃うことと、配信量（egress）に課金がかからない設計です。これは画像や動画を大量に配信するアプリで効きます。ところが自社の2サイトは記事と案内が中心で、データベースもログインも持っていません。効く場所がないのに、動いているものを触ることになります。

3つ目が一番大きくて、教材とのズレです。 AI Crewでは、Claude Code・Codexで作り、Supabaseにデータとログインを置き、GitHubに保存し、Vercelで公開する、という手順を教えています。非エンジニアが動く業務アプリを作る記事がその手順の正本で、受講生の中にもこの構成で自分のアプリを動かしている人がいます。自分だけ乗り換えると、教えている構成と自分の構成が食い違います。

技術の優劣ではなく、自分がいま何を動かしていて、誰に何を教えているかで決めた、という話です。逆に言えば、前提が違う人は違う答えになります。

社内アプリを量産するなら、むしろCloudflareを推します

自社サイトの移行は見送りましたが、用途が変われば答えも変わります。社内で使うツールを何本も作っていくなら、みやっち🧑‍💻はCloudflareのほうを少し推します。

一人社長や個人事業主が、自分の会社だけで使うツールをAIに作らせていくと、こうなります。

• keiri.example.com — 経費精算ツール
• crm.example.com — 顧客管理画面
• training.example.com — 研修アンケートの集計ツール

このとき毎回困るのが、ログイン機能です。3つ作れば3回、アカウント登録とパスワードとログイン画面を実装することになります。自社だけで使うアプリが数十本に増える世界を想像すると、ここが丸ごとコストになります。

Cloudflare Accessを使うと、その実装をアプリ側に書かずに済みます。公式ドキュメントによれば、Accessはアプリケーションの手前に立ち、各リクエストをアプリに通す前にポリシーと照合します。「この会社のメールドメインの人だけ通す」と設定すれば、アプリのコードは認証を1行も持たないまま守られます。条件に使えるのは個人のメールアドレス、会社のメールドメイン、Google WorkspaceのようなIDプロバイダでの認証、国、デバイスの状態などです。

ここで大事なのは、社員が何のアカウントで入るかを、こちらで選べることです。Google WorkspaceをIDプロバイダとしてつなぐと、公式ドキュメントによれば社員はふだんのGoogle Workspaceの資格情報でログインでき、グループ単位のポリシーも組めます。ワンタイムPINを有効にすれば、承認したメールアドレスに届くコードで入れます。なお、何も設定しない既定の状態ではCloudflareアカウントでの認証になります。社員に新しいアカウントを作らせたくないなら、この接続を最初に済ませてください。

並べると、こういう流れになります。

Claude Code・Codex（作る） → GitHub（正本と履歴） → Cloudflare Workers（動かす） → Cloudflare Access（社員だけ通す）

置き場としての守備範囲も広がっています。Cloudflareの公式ドキュメントによれば、Workersはフルスタックのアプリケーションに対応していて、Next.js・React・Astro・Vue・SvelteKit・Nuxtなどのフレームワークで作ったものを載せられます。AIが選んだ書き方に置き場が付いてこない、という心配はかなり減りました。

Vercelにも同じ方向の機能はありますが、狙いが違います。Vercel Authenticationは入る側にVercelのアカウントが要る方式で、開発チームがプレビュー画面を関係者だけに見せるための機能です。自社のIDプロバイダで認証させるPassportもありますが、こちらはEnterpriseプラン限定です。

役割で言い分けると、こうなります。

• Vercelの保護 — 開発中の画面を、関係者だけに見せる
• Cloudflare Access — 社員が日常的に使う社内アプリの入口そのものを守る

経費精算で考えると、変わり方がはっきりします。いまは社員が紙やスプレッドシートに書いて自分に回し、自分が転記して振込データを作っているとします。これが、社員は会社のアドレスでログインして入力するだけ、自分は承認だけを見る、という形になります。IDプロバイダをつないでおけば、誰に頼めばいいか分からず止まっていた社内ツールを、自分の会社のドメインで立てて、社員が普段のアカウントで入る形にできます。 稟議も情シスへの確認もいらない一人社長や個人事業主なら、この距離が短くなります。

なお、CloudflareのZero Trustには無料プランがあり、セットアップの途中で支払い情報の入力を求められますが、無料プランを選べば料金は発生しないと公式に記載されています。無料で使える人数の上限は変わることがあるので、導入前に公式のプランページで確認してください。

GitHubは、どちらを選んでも外さない

Cloudflareはwranglerというコマンドを使って、手元から直接デプロイできます。手軽なので、GitHubを飛ばして直接公開したくなります。

みやっち🧑‍💻はそれを勧めていません。GitHubはデプロイの手段ではなく、コードの正本と履歴だからです。 ここを外すと、何をいつ変えたのかの記録が消え、おかしくなったときに戻す先がなくなります。AIに任せる量が増えるほど、この記録の価値は上がります。

しかも外す必要がありません。CloudflareにもWorkers BuildsというGitHub連携があり、pushごとの自動デプロイができます。GitHubを正本に置いたまま、公開先だけをVercelかCloudflareから選べばいい、というのが実際のところです。

AI Crewが最初からGitHubを前提に教えているのは、これが本番運用の作法だからです。ファイルの管理をGitに寄せる考え方はAI時代のファイル管理の記事にまとめています。

AWSやGoogle Cloudは、いつ必要になるのか

そもそも、なぜAWSやAzureではなくこの2社なのか。みやっち🧑‍💻の見方では、作る人と、作る物が入れ替わったからです。

AWSやAzureが選ばれてきたのには、正しい理由がありました。何万人が使うサービスを止めずに動かし、細部まで作り込む必要があったからです。その代わり、サーバーやネットワークを設定するという仕事が必ず付いてきます。専任のエンジニアがいるチームなら、払える代償です。

ところが、社内の経費精算ツールを1本作るのに、同じ代償は払えません。使うのは数人です。止まって困るのも自分たちだけです。欲しいのは、思いついた日のうちに使える状態のほうです。同じ「アプリを動かす」でも、求められていることが違います。 VercelやCloudflareが注目されているのは、性能でAWSに勝ったからではなく、後者の要件に最初から合わせて作られているからです。

厳密には、この領域はもう1社あります。Firebase App Hostingです。GitHubの対象ブランチにpushすると、Cloud Buildがコンテナを作り、Cloud Runへデプロイされ、Cloud CDNやSecret Managerもまとめて面倒を見てくれる、とGoogleの公式ドキュメントに書かれています。Next.jsは13.5以上、Angularは18.2以上が組み込みでサポートされています。すでにGoogle Cloudを使っている会社なら、有力な選択肢です。

そのうえで、順番としてはこうです。

1. まずVercelかCloudflare（すでにGoogle Cloud圏ならFirebase App Hostingも候補）
2. 特殊な要件が出てきたらAWSやGoogle Cloudを直接触る

「特殊な要件」というのは、閉じた社内ネットワークとの接続、GPUを使う処理、大規模なデータ基盤、特殊なコンテナを動かす必要、厳格な監査やエンタープライズ要件などです。ここに到達してから考えて、遅くありません。

よくある質問

Vercelは無料で使えますか

無料のHobbyプランがあります。ただし守れる範囲に違いがあり、Vercelの公式ドキュメントによると、Hobbyプランで使えるのはプレビューとデプロイメントURLを保護するStandard Protectionまでで、本番ドメインは公開されたままになります。本番ドメイン自体にアクセス制限をかけたい場合はProまたはEnterpriseプランが必要です。

Cloudflareに移行すると安くなりますか

用途によります。Cloudflareは配信量（egress）に課金しない設計で、費用はファイル置き場なら保存量と操作回数、実行環境ならリクエスト数とCPU時間が軸になります。そのため画像や動画を大量に配信するアプリでは差が出ます。一方で、記事中心のサイトや小さな社内ツールでは、どちらも無料枠や低額のプランの範囲に収まることが多く、乗り換えの手間に見合う差は出にくいです。金額は変動するため、判断する前に各社の公式の料金ページで確認してください。

途中で乗り換えられますか

GitHubにコードの正本を置いていれば、公開先を切り替えることは可能です。ただしデータベースやログインの構成まで変える場合は移行作業が発生するので、切り替えの容易さを理由に最初の選択を軽く扱わないほうが安全です。

セキュリティはこれで十分ですか

出発点にすぎません。アクセス制限をかけたからといって、あらゆるリスクがなくなるわけではありません。顧客の個人情報や決済を扱うなら、自社の規定や契約を確認し、情報システム担当や専門家に相談することを強くおすすめします（本記事は法的・技術的な助言ではありません）。AIに渡す権限の考え方はClaude Codeのセキュリティの記事も参考にしてください。

手段ではなく、動いている状態を持つ

選び方は1行に畳めます。一般に公開するアプリはVercel、社内アプリはCloudflare Access、そしてコードの正本はどちらでもGitHubです。

そのうえで、本当に欲しいのは「Cloudflareが使える自分」ではないはずです。自分の会社の言い回しと、自分の業務の流れに合ったツールが、いま実際に動いている状態のほうです。

汎用のSaaSは他社の業務に合わせて作られているので、そこには届きません。外注すれば形にはなりますが、社内ツールを1本ずつ発注していては、思いついた日のうちに使える状態には届きません。対話型のAIに聞くだけでは、使えるURLになりません。この3つが揃って初めて、自分専用の仕組みが手元に残ります。そして個人や一人社長なら、全部の権限を自分が握っているぶん、決めた翌日に試せます。

AI Crewが立っているのも、この側です。プログラマーへの転職や開発者スキルの習得を目指す講座ではありません。受講生のほぼ全員が非エンジニアで、目的は自分の事業と仕事にAIを実装することです。だから講座で教える構成も、GitHubに保存したらそのまま公開されるVercelを標準にしています。

何から作るかで迷っている方はAIで何を作るかの考え方を、非エンジニアがAIで開発を始める全体像は非エンジニアのAIコーディング入門を先に読んでください。AI Crewでは、この作り方を自分の仕事に当てはめるところまで一緒に進めています。まず無料セミナーでお会いしましょう。