バイブコーディング（vibe coding）は、自然言語で要件を伝え、生成AIと対話しながらコードを組み立てる開発スタイルだ。画面が動いた時点で終わりではない。公開には実行環境、Gitによる版管理、ドメイン名システム（Domain Name System、DNS）、TLS証明書、監視、復旧、費用管理まで要る。AIにデプロイ先を尋ねるとCloudflareが候補に現れる場合があるが、その回数は全案件への適合性や市場順位を示さない。

Cloudflareを固定の第一候補とする推薦率は、同社や主要AI事業者の公開資料から確認できなかった。確認できるのは、Gitから本番までの手順、実行環境と周辺サービスの接続方法、AIエージェント（AI agent）が読める文書と呼び出せるツールである。そこで四社を同じ条件で比べ、AIの回答を再現可能な試験へ置き換える。

公開までの連鎖──生成コードは中間地点

制作は、要件の言語化、コード生成、ローカル試験、Gitへの反映、クラウドでのビルド、プレビュー、本番公開の順に進む。本番ではDNSと証明書を設定し、ログを監視し、問題が出た版を戻せる状態にする。静的サイトと、サーバーサイドレンダリング（Server-Side Rendering、SSR）、API、データベース、ログインを含むアプリでは必要な環境が異なる。

Cloudflare Pagesの公式文書では、GitHubかGitLabと接続するとブランチへのプッシュ（push）ごとに自動デプロイし、カスタムブランチとGitHubのプルリクエストには本番へ影響しないプレビューURLを発行する。コード、ビルド結果、確認用URLが一つの変更履歴で結ばれるため、エージェントにも作業の開始条件と成否を渡しやすい。

自然言語の要件からコード生成、ローカル試験、Gitへの反映、クラウドでのビルド、本番監視までを矢印で結んだ図

Cloudflareが候補に入ると考えられる三要素

第一はデプロイ単位のまとまりである。Cloudflare WorkersはWorkerコードとHTML、CSS、画像などの静的ファイルを一回の操作でデプロイし、同社ネットワークで配信する。小規模なフルスタック構成なら、静的配信とサーバー処理を別の手順として説明せずに済む。

第二は周辺資源との接続である。Workersのバインディング（binding）はD1、KV、R2、Queuesなどへの権限とAPIを一体で渡し、同じアカウントの資源へ接続する秘密鍵やトークンをWorkerコードに置かない設計を採る。サービスの境界と権限が設定に表れる。

第三はエージェント向けの入口である。Cloudflareは全資料のMarkdown版、製品別のllms.txt、作業別のスキル、文書検索やAPI操作、ログ照会に使うモデル・コンテキスト・プロトコル（Model Context Protocol、MCP）サーバー、OpenAPI仕様を案内している。三要素が推薦を増やすという公開統計はない。手順が短く、権限が構造化され、現行資料へ到達しやすければ、AIが実行可能な回答を組み立てやすくなるという仮説である。

四つの基盤を同じ六条件で比較

比較条件は、実行方式、フレームワーク、Gitプレビュー、周辺サービス、契約とデータ管理、費用と移行性の六つだ。「公開できるか」だけでは差が見えず、同じ最小アプリを動かす必要がある。

Vercelは自社が保守するNext.jsについてゼロ設定デプロイを掲げ、SSRや画像最適化を同社基盤へ対応させる。Git連携ではブランチへのpushごとにプレビューを作り、本番ブランチへの反映で本番デプロイを作成する。

NetlifyはGitリポジトリーとの継続デプロイ、コマンドラインインターフェース（Command-Line Interface、CLI）、API、AIエージェントからの公開経路を用意し、エージェントがファイルを変更した実行にはデプロイプレビュー（Deploy Preview）を生成する。複数の入口を同じ公開工程へつなげる構成だ。

Firebase App HostingはNext.jsとAngularを事前設定済みで支援し、GitHubの指定ブランチへのコミット（commit）を起点にCloud Buildで構築し、Cloud Runで実行し、Cloud CDNでキャッシュする。AuthenticationやCloud Firestoreとの連携も公式構成に含まれる。

確認点CloudflareVercelNetlifyFirebase App Hosting
実行方式Workerと静的配信フレームワーク連動基盤ビルドと複数の公開経路Cloud RunとCloud CDN
Git経路GitHub／GitLab主要Git事業者Git連携、CLI、APIGitHubのライブブランチ
得意条件bindingを使う周辺資源Next.js固有機能複数のデプロイ入口Firebase既存サービス
実測項目初回公開時間、手動介入、エラー復旧、権限、請求項目、他環境へ移す作業

日本のチームでは契約主体、決済通貨、税務書類、サービス地域、データとバックアップの保存先、再委託先、管理者権限、削除と障害連絡の手順も確認対象になる。技術試験の成功は、調達とデータ管理の完了を意味しない。日本のバイブコーディング利用者を対象に、AIが四社を挙げる比率を同条件で比較した公的統計は、本稿の執筆時点で確認できていない。

Cloudflare、Vercel、Netlify、Firebaseと、実行環境、プレビュー、データ管理、移行性、費用の確認項目を並べた図

検索、ツール、案件条件が回答を変える

AIが候補名を出す経路には、学習時の知識、その場の検索、接続済みのCLIやMCP、利用者が示した案件条件がある。外部からモデルの重みの内訳は確かめられず、単発の回答を採用率に読み替える根拠はない。検索や操作権限の有無でも結果は変わる。

Google Search Centralは、AI OverviewsやAI Modeが中核の検索ランキングシステムからウェブページを取得する検索拡張生成（Retrieval-Augmented Generation、RAG）を使い、表示対象には通常の検索と同じくインデックス登録とスニペット表示の適格性が必要だと説明する。同時に、llms.txtをGoogle検索の表示や順位を左右する特別な信号には使わないと明記している。Cloudflareがエージェント用索引としてllms.txtを採用する事実と、検索順位を上げる効果は分けて扱う必要がある。

サービス側は候補名の出現とタスク完了を分けて測定

新しいサービスが選択肢へ入るには、利用者がAIへ頼む一つの対象業務を定め、入力、前提、成功条件、料金が発生する条件、失敗時の処理を公開文書へ記す。次にテスト用アカウントやサンプルデータ、最小API要求を用意し、OpenAPI、非対話型CLI、MCPなどで試験済みの操作だけを開く。支払い、削除、公開、個人データの操作には人の承認と監査記録を残す。

測定は二本立てになる。候補提示の課題では、固定した要件で名称、順位、理由、制約の正確さを記録する。実行課題では、テスト予約やAPI要求、プレビュー公開の完了率、初回成功までの時間、手動介入、権限、エラーからの復旧を測る。モデルの学習済み知識、ウェブ検索、公式API、CLI、MCPを分けて試せば、改善が文書と操作手段のどちらから生じたかを追える。

公開文書、実行可能な手順、機械向けインターフェース、修復可能なエラー、権限管理、外部から確認できる根拠を順につないだ図

企業がAIモデルを精度、費用、データ、更新で比べる六つの基準は別稿で整理した。デプロイ先の試験でも、候補名より同じ条件で再実行できる記録を残す。

よくある質問

Cloudflareはバイブコーディングの固定の第一候補か
固定の第一候補と判断できる公開統計は確認できていない。フレームワーク、既存サービス、地域、予算、運用体制で短い経路は変わる。

llms.txtを置けばAIに推薦されるのか
推薦は保証されない。対応するエージェントには文書の入口を渡せるが、Google検索は特別な順位信号として扱わない。

四社は無料枠だけで比べられるか
比べられない。リクエスト、計算時間、帯域、ビルド、保存容量の数え方が異なる。同じアプリと流量で請求項目を記録する必要がある。

AIにサービス名が出れば施策は成功か
名称の出現は見つけやすさの一指標にすぎない。適用条件と価格が正しいか、対象業務が完了するか、失敗から安全に戻れるかを別に測る必要がある。