Cloudflareは作ったものを公開し続けるための土台
Cloudflareのすごさは、CDNでサイトを速くするだけではありません。
小さなWebアプリを作るときに必要になる、
- 公開する場所
- 画面の裏側で動くコード
- データベース
- 画像やファイルの保存場所
- Bot対策
- SSL、DNS、DDoS対策
を、同じ管理画面と近い考え方で組み合わせられます。
しかも、個人の小さな作品を始めるための無料枠があります。
読み終わるころには、Cloudflareの「すごい」が、公開・実行・保存・防御・観測の5つに分かれて見えてきます。最後に、Codexへ最初に頼む文面も置きます。
だから「コードはAIに書いてもらう。でも、何を作るかは自分で決めたい」という人と相性がいい。元Juice=Juiceで、現在はソロで音楽活動を続ける宮本佳林さんがCloudflareに驚いた理由も、ここにあります。
宮本佳林さんは、実際に何を作っていたのか
宮本さんの記事を読むと、突然すごいエンジニアになった話ではありません。
最初は「こんな音楽アプリがあれば、みんな笑顔になれるのに」という発想から始まり、ChatGPTに自然言語で指示しながらNode.jsで動くものを作っていました。コードを細かく直せなかったので、全文を書き直してもらう指示を出すところからのスタートです。
その後、AWSの勉強を始め、CloudFrontとS3、リレーショナル/非リレーショナルデータベース、可用性を高める構成などに興味を持ちます。
さらに、イベントで知り合ったplaygroundの担当者から、Cursor+GitHub+Vercelの構成でWebアプリ開発を教わり、最初はメモアプリ、その後は学びをまとめるノートを作りました。
記事に登場する成果物は、たとえば次のようなものです。
- 休日の過ごし方を診断する「週末生態系診断」
- リリースイベントのアンケート
- オンラインお話し会の参加者向け特典ページ
- 10時間のYouTube配信を支える配信システム
つまり、作っていたのは「練習用のコード」だけではありません。ファンが実際に触る診断、アンケート、特典、配信の仕組みです。
宮本さん自身の整理も大切です。AIがコードを書く一方で、何を作るかを決め、設計し、指示を出し、完成したものを確認するのは自分。その役割を分けて考えています。
Cloudflareを使って「なんでこんなに優しいの?」となった理由
宮本さんは、Cloudflareについて次のように書いています。
「なんかもう全部揃ってるの、なんでこんな優しいの?ってくらいの無料枠。」
これはCloudflareのすべてが無料という意味ではありません。小さなサービスを作り始めるときに、公開・防御・保存を別々の会社に分けず、まず無料枠で試せる範囲が広い、という実感です。

最初の作品は「5問のミニ診断+アンケート」でいい
いきなり大規模な配信システムを作る必要はありません。宮本さんの「休日生態系診断」やイベントアンケートに近い、5問のミニ診断から始めると、Cloudflareの役割を手で確かめられます。
1回の回答で何が起きるか
スマホで回答する。TurnstileがBotらしさを確認する。Workersが結果を計算する。D1に回答数を保存する。結果画像が必要ならR2から返す。
この1本の流れで、公開・実行・保存・防御がつながります。D1は回答を保存したいときだけ。R2は画像や音声が必要なときだけ使えば十分です。最初から全部を有効にする必要はありません。
Cloudflare入門作品の構成
- Workers Static Assets:診断画面と静的ファイル
- Workers:回答を受け取り、結果を返すAPI。画面と同じデプロイにまとめられる
- D1:質問、結果、回答数の保存
- Turnstile:Botによる大量送信の抑制
- R2:結果ページに使う画像が必要なら追加
- Pages:Git連携を中心に始めたい場合の選択肢
Codexには、最初にこう頼みます。
Cloudflareで、5問に答えると結果が表示されるミニ診断を作りたい。
目的:
- 自分のブログ読者がスマホで遊べる
- 回答後に結果を1つ表示する
- 最後に任意のアンケートを受け取る
希望構成:
- Workers Static Assets: 画面と静的ファイル
- Workers: API
- D1: 質問・結果・回答数
- Turnstile: Bot対策
- Workers Logs: エラーと利用状況の確認
まずは読み取りと設計案だけ出してください。
無料枠、料金が発生する箇所、必要なCloudflareアカウント権限、
本番公開前の確認項目も日本語で説明してください。
勝手に公開、削除、課金設定の変更はしないでください。
この頼み方なら、コードを書く前に「何を作るか」「どこにお金がかかるか」「何を許可するか」を確認できます。実装を頼む順番も、設計案、ローカル画面、テスト用データ、プレビュー公開、Logs確認の順に分けます。
Cloudflareの強みは、1つのリクエストを最後まで追えること
Cloudflareのすごさは、機能の数だけではありません。訪問者の1回のアクセスを、入口から保存、確認まで同じ流れで考えられます。
- 入口:DNS、SSL、CDN、DDoS対策でアクセスを受ける
- 画面:静的ファイルを近い場所から返す
- 処理:Workersで診断、フォーム、APIを動かす
- 保存:D1に答えや設定、R2に画像やファイルを置く
- 確認:LogsやMetricsでエラーやCPU時間を見る
別々のサービスをつないでも同じことはできます。ただ、最初からこの5段を同じ管理画面と権限の考え方で組める。ここが、初めて作る人にとっての「優しさ」です。
Cloudflareで何ができるのか
1. DNS、CDN、SSL、DDoS対策を最初から使える
CloudflareをDNSとして使い、サイトの前に置くと、訪問者のリクエストがCloudflareのネットワークを通ります。キャッシュできるページは近い場所から返し、攻撃トラフィックは手前で受け止めやすくなります。
CloudflareのFreeプランには、DNS、CDN、Universal SSL、DDoS保護などが含まれます。個人ブログや小さな作品を公開するには、まずこの入口だけでも十分に価値があります。
2. Workersでサーバーを借りずにコードを動かせる
Cloudflare Workersは、サーバーを用意してOSを更新し続ける代わりに、JavaScriptやTypeScriptなどの処理をCloudflareのネットワーク上で動かす仕組みです。
フォームを受け取る、診断結果を返す、APIを作る、定期処理を動かす、といった「画面の裏側」を担当できます。公式ガイドでは、Wranglerでプロジェクトを作り、npx wrangler deploy で公開する流れが紹介されています。
いまのWorkersは、HTML・CSS・画像などの静的ファイルと、APIのコードを同じプロジェクトにまとめて公開できます。静的ファイルはCloudflare側でキャッシュされ、/api/ のような動的なリクエストだけをWorkerで処理する構成です。画面とAPIを別サービスに分けなくても、最初の作品を1回のデプロイで出せます。
Git連携を中心に始めたいならPagesも選べます。大切なのはサービス名を先に決めることではなく、「画面」「API」「データ」の境界を先に決めることです。
3. D1でデータベースを持てる
D1は、SQLiteのSQLを使えるCloudflareのサーバーレスデータベースです。
診断の質問と結果、アンケートの回答、ユーザーが保存したメモなどを扱えます。最初から大規模なデータベースを設計しなくても、小さなアプリのデータ置き場として始めやすいのが魅力です。
4. R2で画像やファイルを保存できる
R2はオブジェクトストレージです。画像、音声、生成ファイル、アップロードデータなどを保存できます。
R2の大きな特徴は、インターネットへのデータ転送、いわゆるegressに料金がかからないことです。ただし保存容量や操作回数には料金があり、無料枠にも上限があります。「転送無料だから完全無料」とは考えないことが大切です。
5. TurnstileでBot対策を入れられる
アンケートや申し込みフォームを公開すると、Botによる大量送信が心配になります。Turnstileは、画面に難しい画像認証を出さずに人間らしさを確認する、CloudflareのCAPTCHA代替サービスです。
CloudflareのCDNを使っていないサイトにも組み込めます。無料プランでは、アカウントあたり最大20ウィジェット、認証チャレンジは無制限と案内されています。
ただし、画面にウィジェットを置くだけでは不十分です。送信前に受け取ったトークンを、サーバー側からTurnstileのSiteverify APIで検証して初めてBot対策になります。秘密鍵はブラウザやGitHubに置きません。
6. LogsとObservabilityで、公開後の動きも追える
作って公開したあとに、「誰も使っていない」のか「エラーで使えない」のかが分からないと改善できません。Workers Logsでは、呼び出し、エラー、例外を確認できます。Observabilityでは、リクエスト数、エラー率、CPU時間、実行時間などを追えます。
この確認まで同じ場所にあるため、AIに「このエラーは何か」「無料枠を超えそうか」と聞く材料を集めやすい。CloudflareのObservability用MCPサーバーを使えば、ログやメトリクスをAIから調べる道にもつながります。
CodexとCloudflareを連携すると、何ができるのか
今回の私の環境では、Codexに「Cloudflareを使いたい」と伝えたことをきっかけにCloudflareプラグインの追加が始まりました。これは、Cloudflareのアカウントを自動で作る魔法ではありません。
流れは、次のように考えるとわかりやすいです。
- Cloudflareでアカウントを作る
- CodexにCloudflare連携を追加する
- OAuthなどで、どのCloudflareアカウントを使うか許可する
- Codexが読み取り・提案・変更に使えるツールを確認する
- 実行前に、対象・料金・権限を確認する
連携後は、たとえば次のような相談ができます。
- いまのCloudflare構成を読み取り、初心者向けに説明する
- WorkersやPagesで公開する構成を提案する
- D1、R2、KVのどれを使うべきか比較する
- Workersのログやエラーを調べる
- 無料枠を超えそうな処理を見つける
- DNS、SSL、Bot対策の設定候補を整理する
- 変更前に、何が変わるのかを一覧にする
ここに挙げたのは、CloudflareのMCPサーバーやCodex側の連携が利用できる場合の例です。実際に表示される機能は、導入したプラグイン、OAuthで許可したアカウント、読み取り・変更の権限で変わります。すべてのCodexユーザーに同じ操作が見えるわけではありません。
ただし、連携したからといって何でも勝手に変更できるわけではありません。読み取りだけの操作、変更を伴う操作、削除や公開など、危険度が違います。最初は「調査だけ」「変更案だけ」と指定するのがおすすめです。
MCPとは何か。CloudflareとCodexの間にある共通の接続方式
MCPは、Model Context Protocolの略です。Cloudflareの公式説明では、AIアプリと外部サービスをつなぐUSB-Cのような共通規格と説明されています。
役割を分けると、こうなります。
| 名前 | 役割 |
|---|---|
| Cloudflare | Webサイト、コード、データ、セキュリティを動かすサービス |
| Codex | 作りたいものを聞き、コードや作業手順を考えるAI開発アシスタント |
| プラグイン | Codexに機能や接続設定を追加するパッケージ |
| MCP | AIが外部サービスのツールを呼び出すための共通ルール |
| OAuth/APIトークン | どのアカウントに、どの権限で接続するかを証明するもの |
Cloudflareは、API用、ドキュメント用、WorkersのBindings用、Builds用、Observability用などの公式MCPサーバーを案内しています。API全体を数千個のツールとして読み込ませるのではなく、検索と実行の2つの道具に絞るCode Modeで、モデルの文脈を小さく保つ設計も紹介されています。
特に驚くのは、Cloudflare API用MCPの設計です。公式ドキュメントでは、2,500以上のAPIエンドポイントを、モデルから見える2つの道具(検索と実行)にまとめています。すべてのAPIを別々の道具として読み込むと約117万トークン必要ですが、Code Modeなら約1,000トークンに抑えられる、と説明されています。
これは単に「AIにたくさん操作させる」仕組みではありません。OAuthで許可した権限を越えて実行できないようにし、生成されたコードは分離された環境で動かします。認証情報をモデルへそのまま渡さない設計です。便利さと安全性を両方考えた接続方式になっています。
ここがCloudflareのもう一つのすごさです。Cloudflare自身が「AIから使われるサービス」になるだけでなく、「AIとつながるサービスを作る場所」にもなっています。
無料で始められる。でも「無料だから無限」ではない
2026年8月4日時点の公式情報では、代表的な無料枠は次のようになっています。料金や上限は変更されるため、公開前に必ず公式ページを確認してください。
| 機能 | 無料枠の目安 | 使い道 |
|---|---|---|
| Workers Free | 動的リクエストは1アカウントあたり1日10万回。CPU時間は1回10ms。静的ファイルのリクエストは無料・無制限 | API、フォーム、診断処理、画面配信 |
| D1 | 1日500万行読み取り、10万行書き込み、保存5GB。容量ではなく「行」で数える | 質問、回答、メモ |
| R2 | Standardで保存10GB-month、Class A 100万回、Class B 1,000万回/月。egressは無料。無料枠はStandardが対象 | 画像、音声、ファイル |
| Turnstile Free | 20ウィジェット、チャレンジ無制限 | Bot対策 |
Workersの有料プランは、アカウントあたり月5ドルの最低料金から始まる別の料金体系です。CloudflareのWebサイト向けFree/Pro/Businessプランと、Workersの料金は同じものではありません。
特に気をつけたいのは、次の3つです。
- AIの利用や大量処理は、無料枠とは別に料金が発生することがある
- 保存容量、読み書き回数、リクエスト数はそれぞれ別カウント
- 課金設定をする前に、上限、通知、CPU時間、Bot対策を確認する
「安い」は本当。ただし、安さの理由は、使った量を細かく分けて管理できることです。何が無料で、何が従量課金かを確認して使うサービスです。
料金で一番つまずきやすいのはD1です。たとえば5,000行ある表をインデックスなしで全件検索すると、結果が1行でも5,000行を読んだ扱いになります。よく検索する列にインデックスを作ると、読み取り量と待ち時間を減らせます。
R2の「egress無料」も、R2からインターネットへ直接配信する場合の話です。別の有料サービスを経由すれば、そのサービス側の料金がかかることがあります。無料枠は「何でも無料」ではなく、使い方ごとに境界がある無料枠です。
課金すると何が楽になるのか
課金のメリットは、単に「高機能になる」ことではありません。無料枠の日次上限を気にせず、本番サービスを止めにくくし、処理量に合わせて余裕を買えることです。
| 使い方 | 月額の目安 | 課金で得られるもの |
|---|---|---|
| まず試す | 0ドル | Workers Free、D1 Free、R2 Standardの無料枠、Turnstile Freeで小さく検証 |
| 小さな本番 | Workers Paidはアカウントあたり月5ドルから | 月1,000万リクエストとCPU時間3,000万msを含む。日次のFree上限より余裕がある |
| 画像・音声が増える | R2は無料枠を超えた分だけ | Standardは保存1GB-monthあたり0.015ドル。R2からのegressは無料 |
Workers Paidは「月5ドルで無制限」ではありません。月1,000万リクエストとCPU時間3,000万msが含まれ、それを超えた分は従量課金です。Cloudflare公式の例では、月1,500万リクエスト、平均CPU時間7msのWorkerは、基本料金を含めて月8ドルと試算されています。D1やR2を使えば、その分の利用量も加わります。
D1もPaidにすると、日次のFree上限から月次の大きな利用枠へ変わります。公式料金表では、月間250億行の読み取り、5,000万行の書き込み、5GBの保存が含まれ、超過分が課金対象です。R2は無料枠を超えてもegress無料が残るため、画像配信が増えたときの費用を読みやすくできます。
一方、Turnstileは小さな本番サイトならFreeのままで足りるケースが多いサービスです。20ウィジェット、チャレンジ無制限があるため、課金はアクセス量だけでなく、必要な機能と運用上の余裕で判断します。
日本円の金額は為替、税、追加サービスで変わります。独自ドメイン代もCloudflareの利用料とは別です。最初は0ドルで作品を試し、日次上限やCPU時間が実際の障害になったらWorkers Paidを検討する順番が分かりやすいです。
契約・登録に必要なもの
まず試すだけなら、必要なのは多くありません。
最低限必要なもの
- Cloudflareアカウント
- メールアドレスとパスワード
- メールアドレスの確認
- 作りたいものの名前と目的
Workersを試すだけなら、独自ドメインは後回しにできます。公式の手順では、workers.dev のサブドメイン、または後から設定するカスタムドメインへ公開できます。独自ドメインを使う段階で、DNSまたはネームサーバーを変更できる権限が必要です。
有料機能を使うときに必要なもの
- 支払い情報
- 料金を負担するアカウントの確認
- 無料枠と従量課金の確認
- 必要なら請求通知の設定
WorkersのFree枠で試すことと、Workers Paidへ進むことは別です。有料プランはアカウントあたり月5ドルの最低料金から始まります。Zero Trustも別サービスで、Freeプランを選んでも初回の組織設定で支払い情報を求められる公式手順がありますが、そのFreeプラン自体では請求されません。登録画面の対象サービスを確認して進めます。
Codexから使うときに必要なもの
Codexの連携では、サービス側のOAuth認証で進む場合があります。CLIや自動デプロイでは、CloudflareのアカウントIDと、必要な権限だけを持つAPIトークンを使うことがあります。
APIトークンをチャット本文へ貼らない。GitHubにコミットしない。最初は読み取り権限から始める。この3つは必ず守ります。
宮本さんから学べる、Cloudflareより大切なこと
Cloudflareが安くて便利だから作れた、だけではありません。
宮本さんは、移動中にスマホで仕様を細かく固め、帰宅後にその.mdファイルをAIに読ませて開発する流れを繰り返していました。また、AIに再現できない人間の部分を忘れないこと、秘密のキーを貼らないこと、複数のAIにレビューさせることも大切にしています。
ここが一番参考になります。
AIに「いい感じのアプリを作って」と丸投げするのではなく、
- 自分が作りたい体験を決める
- 画面とデータを言葉にする
- Cloudflareのどの機能を使うか選ぶ
- AIに作ってもらう
- 自分と別のAIで確認する
という順番です。
Cloudflareは、作る力を増幅する土台。Codexは、考えたことをコードへ運ぶ相棒。そして最終的に責任を持つのは、作る人です。
Cloudflareのすごさは、小さく始めて広げられること
宮本佳林さんがCloudflareに感じた「初心者に優しく、圧倒的に安価」という言葉は、公式仕様そのものではなく、実際に作品を作った人の体験です。その背景には、公開・実行・保存・防御・観測を小さく組み合わせられる構造があります。
- 小さなWebアプリを無料枠で公開しやすい
- Workers、D1、R2、Turnstileを組み合わせられる
- DNS、SSL、CDN、DDoS対策も同じ場所にある
- CodexやMCPから、構成の確認や作業の相談につなげられる
- 大きく作る前に、小さな診断やアンケートで試せる
まずは「5問のミニ診断」を作る。そこで、画面、API、データベース、Bot対策、公開の流れを一度経験する。
その小さな成功体験が、元アイドルが配信システムやファン向けサービスを作れるようになった道のりに近づく、最初の一歩になると思います。
参考リンク
- 元アイドルがバイブコーディングできるようになるまで。 — 宮本佳林さんの体験談
- Cloudflare公式:Getting started
- Cloudflare公式:Workers概要
- Cloudflare公式:Workers Static Assets
- Cloudflare公式:Workers料金
- Cloudflare公式:Workersの制限
- Cloudflare公式:Workers Observability
- Cloudflare公式:D1概要
- Cloudflare公式:D1の料金と行数の数え方
- Cloudflare公式:R2料金
- Cloudflare公式:Turnstileのプラン
- Cloudflare公式:Turnstileトークンの検証
- Cloudflare公式:CloudflareのMCPサーバー
- OpenAI公式:MCP and Connectors
- OpenAI公式:Codexのプラグイン構成












