作成日: 2026-08-28 / シンオン株式会社
対象: つくる人(非エンジニア社員)/ 用意する人(情シス・エンジニア)/ 決める人(経営)
題材: 顧客問い合わせの受付台帳 / 日報の集計ダッシュボード
対になる資料: プランA(Codespaces)・プランB(ローカル・現行本命)・Cloudflare OS — 最後に 4 方式で横並び比較します
| あなたの立場 | 読むところ | 所要 |
|---|---|---|
| 決める人(経営・情シス) | 第 I 部(1〜5章)と 第 III 部(18〜25章) | 15 分 |
| 用意する人(エンジニア) | 第 I 部 → 第 II 部 Step 0・Step 1(7〜8章)→ 第 III 部 | 40 分 |
| つくる人(非エンジニア) | 第 II 部の Step 1 以降(8〜17章)だけで足ります。Step 0 は自分ではやりません | 30 分 |
Cloudflare が標準で出している MCP には、「Worker を作ってデプロイする」ためのツールがありません。
Workers 関連で用意されているのは workers_list / workers_get_worker / workers_get_worker_code の
読み取り 3 本だけです(4 章に全ツール一覧)。
つまり MCP は「AI に Cloudflare を見せて・触らせる」部品であって、「デプロイ装置」ではありません。 配信そのものは wrangler か Workers Builds か Cloudflare API で行います(13 章で 3 経路を比較)。
ここを取り違えると、「MCP を入れれば非エンジニアがブラウザだけで完結する」という誤った期待のまま稟議を通すことになります。
docs(正しい書き方)/ bindings(器をつくる)/ api(何でもできる本体)/ builds(配信の様子)/ observability(動いているか)。Cloudflare 公式の Claude Code プラグインは、まさにこの 5 本を登録します。Cloudflare OS = 非エンジニアが単独で完結する。関門なし。社外公開不可。
プランB + MCP = レビューという関門を残したまま、AI の失敗率だけを下げる。
この 2 つは競合しません。足すべきものが違います。
MCP(Model Context Protocol)は、AI と外部サービスをつなぐ共通の差込口です。 Cloudflare 自身が公式ドキュメントで「AI アプリケーションにとっての USB-C ポート」と表現しています。
| 用語 | 実体 | 今回でいうと |
|---|---|---|
| MCP ホスト | AI アシスタント本体 | Claude(Cowork / デスクトップ / Claude Code) |
| MCP クライアント | ホストの中でサーバーに接続する部分 | Claude の「コネクタ」機能 |
| MCP サーバー | ツールを外に出す側 | Cloudflare 公式 MCP サーバー群 |
インストールするものはありません。URL を 1 回登録して、ブラウザで「許可」を押すだけです。
難しさは「接続」ではなく、「どこまでの権限を渡すか」を決めるところにあります(7 章)。
すべて Cloudflare 公式(cloudflare/mcp-server-cloudflare および cloudflare/mcp リポジトリ)。
接続は URL を登録して OAuth するだけ。サーバー利用そのものに追加料金はありません。
| サーバー | URL | 何ができるか |
|---|---|---|
| Cloudflare API | mcp.cloudflare.com/mcp | Cloudflare API の全域(2,500 超のエンドポイント)。DNS・Workers・R2・Zero Trust など。Code Mode により、これ全部で 約 1,100 トークンしか消費しない(9 章) |
| # | サーバー | URL | 用途 | 社内サービス構築で |
|---|---|---|---|---|
| 1 | Documentation | docs.mcp.cloudflare.com/mcp | 最新の公式ドキュメントを検索 | ◎ 必須 |
| 2 | Workers Bindings | bindings.mcp.cloudflare.com/mcp | KV・D1・R2・Hyperdrive の作成と操作 | ◎ 必須 |
| 3 | Workers Builds | builds.mcp.cloudflare.com/mcp | ビルド一覧・ビルドログ | ○ 配信の確認 |
| 4 | Observability | observability.mcp.cloudflare.com/mcp | 動いているアプリのログ・メトリクス | ◎ 必須 |
| 5 | Browser Run | browser.mcp.cloudflare.com/mcp | ページ取得・Markdown 変換・スクリーンショット | ○ 出来上がりの目視確認 |
| 6 | Container | containers.mcp.cloudflare.com/mcp | サンドボックス開発環境 | △ |
| 7 | AI Gateway | ai-gateway.mcp.cloudflare.com/mcp | AI のログ・プロンプト/応答の確認 | ○ AI を使うなら |
| 8 | AI Search (AutoRAG) | autorag.mcp.cloudflare.com/mcp | 社内文書の検索基盤を操作 | △ 社内検索を作るなら |
| 9 | Audit Logs | auditlogs.mcp.cloudflare.com/mcp | 「誰が何を変えたか」の監査ログ | ◎ 統制で必須 |
| 10 | Logpush | logs.mcp.cloudflare.com/mcp | Logpush ジョブの健全性 | △ |
| 11 | GraphQL | graphql.mcp.cloudflare.com/mcp | GraphQL Analytics API | △ 集計が要るなら |
| 12 | DNS Analytics | dns-analytics.mcp.cloudflare.com/mcp | DNS の性能・障害調査 | △ |
| 13 | Radar | radar.mcp.cloudflare.com/mcp | インターネット全体の傾向・URL スキャン | × 社内用途では不要 |
| 14 | DEX | dex.mcp.cloudflare.com/mcp | 社員端末から見たアプリ品質の監視 | △ Cloudflare One 利用時 |
| 15 | Cloudflare One CASB | casb.mcp.cloudflare.com/mcp | SaaS の設定ミス検出 | △ Cloudflare One 利用時 |
| 16 | Agents SDK Docs | agents.cloudflare.com/mcp | Agents SDK のドキュメント検索 | △ 自作エージェントを作るなら |
GitHub リポジトリ側にはこのほか Blog(blog.mcp.cloudflare.com/mcp)と Demo Day(デモ用の最小サーバー)も並んでいます。数え方で「16 本」「18 本」と揺れるのはこのためです。
社内サービス構築に関係するのは、上の表で ◎ と ○ を付けた 8 本だけだと思ってください。
cloudflare-api ← 何でもできる本体(Code Mode)
cloudflare-docs ← 正しい書き方を調べる
cloudflare-bindings ← DB・ファイル置き場を作る
cloudflare-builds ← 配信の様子を見る
cloudflare-observability ← 動いているか見る
迷ったらこの 5 本+ Browser Run(見た目の確認用)だけ入れてください。
| 分類 | ツール | できること |
|---|---|---|
| KV | kv_namespaces_list / kv_namespace_create / kv_namespace_get / kv_namespace_update / kv_namespace_delete | 設定値の置き場を作れる・消せる |
| D1 | d1_databases_list / d1_database_create / d1_database_get / d1_database_query / d1_database_delete | データベースを作れる・消せる・SQL を実行できる |
| R2 | r2_buckets_list / r2_bucket_create / r2_bucket_get / r2_bucket_delete | ファイル置き場を作れる・消せる |
| Hyperdrive | hyperdrive_configs_list / hyperdrive_config_create / hyperdrive_config_get / hyperdrive_config_edit / hyperdrive_config_delete | 外部 DB への接続設定 |
| Workers | workers_list / workers_get_worker / workers_get_worker_code | 一覧を見る・詳細を見る・ソースを読む。それだけ |
Workers の 3 本はすべて「読み取り」です。作る・更新する・デプロイするツールは存在しません。
| サーバー | ツール | 備考 |
|---|---|---|
| Cloudflare API | docs / search / execute | 3 本だけ。execute が JavaScript を書いて認証付き API 呼び出しを実行する |
| Workers Builds | workers_builds_set_active_worker / workers_builds_list_builds / workers_builds_get_build / workers_builds_get_build_logs | ビルドの確認だけ。ビルドを起動するツールは無い |
| Observability | query_worker_observability / observability_keys / observability_values | ログ検索・フィールド一覧・値の候補 |
Cloudflare OS には「デプロイ工程が存在しない」ので、非エンジニアが単独で完結します。
MCP 方式にはデプロイ工程が残ります。だから、それを担う仕組み(プランA/B)が必要なままです。
| 項目 | 費用 | 備考 |
|---|---|---|
| 公式 MCP サーバーの利用 | 無償 | Cloudflare が公開。接続に追加課金なし |
| Claude のコネクタ機能 | プラン内 | Free / Pro / Max / Team / Enterprise で利用可。Free はコネクタ 1 本まで |
| Workers Paid | $5 / 月 | 既存資料と同じ結論。Free は CPU 10ms・D1 アカウント 10 個上限で社内利用に耐えない |
| Browser Rendering(Browser Run MCP) | 従量 | スクリーンショット確認に使う。無料枠あり |
| Containers(Container MCP) | 従量 | 今回は使わない前提 |
| Cloudflare One / MCP Portal | Zero Trust プラン | 統制を厚くする場合(19 章)。Logpush 書き出しは Enterprise のみ |
追加費用は実質ゼロです。MCP の導入判断は費用ではなく、「どこまでの権限を AI に渡すか」の判断です。
「一部の機能は Workers の有料プランが必要」と公式リポジトリに記載があります。どの MCP サーバーのどのツールが該当するかの明記はありません。Paid 前提で見積もってください(25 章 未確認事項 2)。
つくる人はこの章を読み飛ばして構いません。
| 方式 | 使いどころ | 権限の決まり方 |
|---|---|---|
| OAuth(推奨) | 人が対話的に使うとき | 接続時にブラウザで権限を選ぶ画面が出る |
| API トークン | CI や自動実行 | ダッシュボードで作るときに権限を選ぶ |
既存資料と同じです。Worker 単位/アカウント単位の Access を先に ON にし、all_workers + all_preview_workers を有効化しておくと、新しく作られた Worker が自動的に社内限定になります。「誰も気づかないまま公開されていた」を仕組みで防ぐ、いちばん効く 1 手です。
デプロイ手段が MCP に無いため、ここは避けられません(プランB の scripts/setup-mac.sh を流用)。
つくる人の作業はここからです。入口は 3 つあり、できることが違います。
https://docs.mcp.cloudflare.com/mcp)まず組織のオーナーが「組織設定 > コネクタ」で登録し、そのあと各メンバーが「接続」を押します。
メンバーが勝手に増やせません。これは統制上むしろ好都合です。
/plugin marketplace add cloudflare/skills
/plugin install cloudflare@cloudflare
この 2 行で、MCP サーバー 5 本と「スキル」がまとめて入ります。確認は次のコマンド。
claude mcp list
初回に Cloudflare のツールを使うと、ブラウザが開いて権限の許可を求められます。
| スキル | 内容 |
|---|---|
cloudflare | Workers・Pages・KV・D1・R2・AI・ネットワーク・セキュリティの総合 |
wrangler | デプロイと運用のコマンド(= MCP に無い部分を埋める) |
agents-sdk | 状態を持つ AI エージェントの作り方 |
durable-objects | 状態の共有・WebSocket・SQLite |
web-perf | Web Vitals の計測と改善 |
building-mcp-server-on-cloudflare | 自社 MCP サーバーの作り方 |
cloudflare-one / cloudflare-one-migrations | Zero Trust の設定と、他社製品からの移行 |
MCP = 実物に触る手段。スキル = 正しい手順の知識。この 2 つはセットです。
片方だけだと「正しい手順を知らないまま実物を触る」か「正しい手順は知っているが実物を確認できない」のどちらかになります。
Cloudflare API MCP は、2,500 を超える API を たった 3 つのツールで扱います。
| ツール | 役割 |
|---|---|
docs | 公式ドキュメントを検索する |
search | コードを書いて、API 仕様の中から目的のエンドポイントを探す |
execute | コードを書いて、認証付きの API 呼び出しを実行する |
なぜこうするのか。トークン(AI が読む文字数)の問題です。
?codemode=false を URL に付けると従来型(約 2,500 ツール)にも戻せますが、トークンが 244,000 に膨らむので通常は使いません。
ここを飛ばすと、あとの全工程がやり直しになります。既存のプランB の /service-spec スキルと同じ考え方です。MCP は関係ありません。日本語の作業です。
答えるのは 6 つだけ。
顧客からの問い合わせを記録する社内の台帳を作りたい。 使うのは営業部の 6 人。社外の人は使わない。 入れる項目:受付日・会社名・担当者名・連絡先・問い合わせ内容・ 対応状況(未対応/対応中/完了)・対応メモ・対応者。 出したいもの:一覧表示、会社名での検索、月ごとの件数、CSV 出力。 いまは Excel を共有フォルダに置いていて、同時に開くと壊れる。 個人情報:会社の担当者名と会社のメールアドレスを持つ。 まずこの内容で仕様書を作って。作る前に、不明点があれば質問して。
「個人情報を持つ」なら、そもそも MCP 方式(=プランB 相当)で正解です。Cloudflare OS ではなく、レビューのある方式を選んでください(23 章の判断フロー)。
| 器 | 何を入れるか | 今回の台帳では |
|---|---|---|
| D1 | 表形式のデータ(行と列) | 問い合わせの記録そのもの |
| R2 | ファイル(PDF・画像・CSV) | 添付ファイル |
| KV | 小さな設定値 | 選択肢のリストなど |
Cloudflare に、この台帳用の D1 データベースを作って。 名前は inquiry-log-staging。 作れたらデータベース ID を教えて。
AI は d1_database_create を呼び、実際にあなたのアカウントに作ります。返ってくる ID は、次の Step で設定ファイルに書き込むために使います。
× いらないデータベースを全部消して
d1_database_delete / r2_bucket_delete / kv_namespace_delete は本物を消します。確認ダイアログは MCP 側にはありません。
消す作業だけは、必ずエンジニアに頼んでください。Step 0 でトークンから削除権限を外しておくのが確実です(18 章)。
inquiry-log-staging ← 試用環境(壊してよい)
inquiry-log-prod ← 本番(壊してはいけない)
Workers Free では D1 はアカウントあたり 10 個までです。1 アプリで 2 個使うので、Free だと 5 アプリで枯渇します。Paid にする理由のひとつです。
Claude Code を開いて、Step 2 の仕様書を渡します。
docs/spec.md の仕様で、Cloudflare Workers 上に動く台帳アプリを作って。 条件: - データベースは D1 の inquiry-log-staging(ID: xxxxxxxx)を使う - 画面は静的アセット(Static Assets)で配信する - 入口は Cloudflare Access で社内限定にする前提で、認証は自前で作らない - wrangler.jsonc も一緒に作って 書く前に、Cloudflare のドキュメント MCP で 「D1 と Static Assets を併用する Worker の最新の書き方」を確認してから始めて。
AI が学習で覚えている Cloudflare の書き方は、必ず古くなります。Cloudflare は設定ファイルの形式(wrangler.toml → wrangler.jsonc)やバインディングの書式を実際に変えてきました。
| docs MCP なし | docs MCP あり |
|---|---|
AI「wrangler.toml に [[d1_databases]] と書きます」→ 動くこともあるが、最新の推奨形ではない → あとで詰まる。原因が分からない | AI → docs MCP →「最新はこう」→ その通りに書く → 一発で通る |
「調べてから書いて」。この 5 文字を毎回付けるだけで、失敗のかなりの割合が消えます。
~/社内サービス/inquiry-log/
├ wrangler.jsonc ← 設定(D1 の ID などが書いてある)
├ src/index.ts ← サーバ側の処理
├ public/index.html ← 画面
└ docs/spec.md ← Step 2 の仕様書
この時点ではまだ誰も使えません。あなたの Mac の中にあるだけです。
取れる道は 3 つあります。
| 経路 | やること | 非エンジニア単独 | 本番向き | 承認の関門 |
|---|---|---|---|---|
| A. wrangler | 「staging に配信して」と頼む | ○ | staging のみ | なし |
| B. Workers Builds(GitHub) | git push → 自動ビルド → 配信 | △ | ◎ | PR マージ = あり |
| C. Cloudflare API MCP | execute で Script Upload API を叩く | ○ | △ 要検証 | なし |
このアプリを staging 環境に配信して。 配信できたら URL を教えて。
Claude Code が wrangler deploy を実行します。つくる人はコマンドを覚える必要がありません。ただしターミナル(Claude Code)が必要なので、Cowork やブラウザだけでは到達できません。
GitHub リポジトリと Worker を接続しておくと、push だけで配信されます。プランB の仕組み(Deploy key + ブランチ 3 本 + PR マージ=本番承認)がそのまま使えます。
Workers Builds MCP はここで効きます。
さっきの配信、成功した?失敗していたらログを見て原因を教えて。
AI は workers_builds_list_builds → workers_builds_get_build_logs を呼び、ビルドログを読んで日本語で説明します。これまで「エンジニアに聞かないと分からなかった」ことが、自分で分かるようになります。
Cloudflare API には Worker スクリプトをアップロードするエンドポイントがあります。理屈のうえでは、Code Mode の execute から呼び出せます。ただし、静的アセット(画面の HTML/CSS/JS)を含む場合の手順は 3 段階です。
① アップロードセッションを作る → JWT(1 時間有効)が返る
② ファイルを base64 で送る → 完了 JWT(別物・1 時間有効)が返る
③ 完了 JWT を assets.jwt に入れて、スクリプトをアップロード
(multipart/form-data・認証トークンが段階ごとに変わる)
この経路が Claude + Code Mode から安定して通るかは、まだ実測していません。
通れば「ブラウザだけで本番配信」が成立し、22 章の比較表が書き換わります。25 章の未確認事項の 1 番に置きました。最初に潰すべき項目です。通らない前提で計画してください。
デプロイした「つもり」で終わらせないための工程です。MCP がいちばん効くのがここ。
https://inquiry-log-staging.xxx.workers.dev のスクリーンショットを撮って見せて。 一覧画面と、新規登録の画面の両方。
AI が実際にブラウザで開いて、画像を返します。「動いていると言われたが、開いたら真っ白だった」が、その場で分かります。
このアプリ、さっきの 10 分間でエラーは出ている? 出ていたら、いちばん多いエラーの内容を教えて。
AI は query_worker_observability を呼び、ログを検索して答えます。どんな項目で絞り込めるかは observability_keys、その値の候補は observability_values で調べます。
inquiry-log-staging の中身を見せて。何件入っている?
d1_database_query で実際に SQL を実行して答えます。
| MCP が無いとき | MCP があるとき |
|---|---|
| つくる人「動きません」 エンジニア「ログ見ますね」 … 半日待ち | つくる人「エラー出てる?」 AI「D1 のテーブルが無いというエラーが 12 件。作成 SQL を流し忘れています」 つくる人「じゃあ流して」… 3 分 |
MCP 方式の価値は開発の速さより「詰まったときに自分で抜け出せること」です。24 章の撤退基準もこれで測ります。
| ダメな頼み方 | 良い頼み方 |
|---|---|
| 「動きません。直して」 | 「登録ボタンを押すと画面が固まる。ログを見て原因を教えて」 |
| 「たぶんデータベースのせい」 | 「まず調べてから直して。推測で書き換えないで」 |
| 「全部作り直して」 | 「この 1 か所だけ直して。他は触らないで」 |
ここだけはエンジニアが関門になります(プランB と同じ)。
つくる人 エンジニア
│ │
├ docs/releases/YYYY-MM-DD-名前.md を書く
│ (何を作ったか・誰が使うか・止まると何が困るか)
│ │
├─── Chatwork で連絡 ─────────→ │
│ ├ 差分を見る(5 分)
│ ├ Access の名簿を確認
│ └ PR をマージ = 本番公開
│ │
←──── Chatwork に配信結果 ───────┤
Step 0 で all_workers を ON にしていれば自動で社内限定になりますが、本番公開の前に社外の回線から開いて「入れないこと」を目で確かめてください。ここだけは仕組みを信じきらないほうが安全です。
| やること | 使う MCP | プロンプト例 |
|---|---|---|
| 誰が何を変えたか | Audit Logs | 「先週、Cloudflare の設定を変えたのは誰?」 |
| ちゃんと使われているか | Observability | 「このアプリ、今月何回使われた?」 |
| AI の費用 | AI Gateway | 「今月のトークン消費とコストを教えて」 |
| 遅くないか | DNS Analytics / GraphQL | 「応答時間の推移を出して」 |
「6 か月以上使われていない」「作った本人しか使っていない」「月 1 回しか使わない」が揃ったら廃止。
増やすより、減らすほうが難しい。最初から捨てる基準を決めておいてください。
MCP を入れると、AI が本物の本番環境を触れるようになります。プランA/B が「GitHub の中で完結していた」のと決定的に違う点です。4 層で止めます。
| 層 | 止められる事故 | 止められない事故 |
|---|---|---|
| トークンの権限 | DNS を書き換える、課金設定を触る、Access の名簿をいじる | 渡した権限の中での削除(D1 を消す等) |
| Access | 作ったものが社外から見える | 社内の人が中身を見ること |
| 本番承認 | 未完成のまま本番に出る | staging を壊すこと(壊してよい) |
| MCP Portal | 危険なツールが個人の裁量で使われる | 設定を怠ったとき |
d1_database_delete も r2_bucket_delete も、確認なしで本物を消します。
Cloudflare の権限は Read / Edit の粒度なので、「作らせるが消させない」を厳密にやるのは難しい可能性があります。 厳密にやるなら、つくる人のトークンは Read にして作成はエンジニアが代行するか、MCP Portal でツール単位に切るかのどちらかです。25 章の未確認事項 3 番で最初に確かめてください。
Cloudflare One の MCP server portal は、複数の MCP サーバーを 1 つの入口にまとめる仕組みです。
d1_database_delete だけ無効、が可能)| 制約 | 内容 |
|---|---|
| サーバー数 | 1 ポータルあたり最大 40 本 |
| 対応方式 | リモート HTTP のみ(stdio 専用サーバーは不可) |
| 相性 | ポータル経由のクライアントを拒否するサーバーがある |
| 認証の穴 | 独立 MFA・目的の正当化・一時的な認証は、ポータル経由では強制されない |
| 転送 | Gateway 経由では SSE 非対応 |
| DNS | gateway.agents.cloudflare.com への CNAME が必要 |
| 書き出し | Logpush はエンタープライズプランのみ |
1 人目・2 人目の段階では Portal は要りません。トークンの権限を絞るだけで足ります。
部署展開(5 人以上)に入る段階で、delete 系ツールを止めるために導入する、が費用対効果の合う順番です。
Cloudflare の MCP サーバーは新仕様に対応済みです。運用側に意味があるのは 2 つ。
| 変更 | 内容 | 効いてくるところ |
|---|---|---|
| ステートレス化 | ハンドシェイクとセッション ID が不要に。1 リクエストが独立 | 接続が切れて詰まる、が減る |
Mcp-Method / Mcp-Name ヘッダ | 中身を解析せずにゲートウェイが用途を判別できる | ツール単位のレート制限と可視化ができる=統制の材料 |
| MRTR | 情報が足りないとき input_required を返し、クライアントが追加情報を付けて再送 | 長時間の接続維持が不要に |
| 認可の強化 | 動的クライアント登録は非推奨へ。事前登録と CIMD を推奨。RFC 9207 で発行者を識別 | 将来の設定変更に備える |
| 廃止の猶予 | 非推奨機能は削除まで 12 か月 | 一度組んだら 1 年は持つ |
| 観点 | プランA (Codespaces) | プランB (ローカル・現行本命) | プランB + MCP (今回) | Cloudflare OS |
|---|---|---|---|---|
| つくる人が触るもの | ブラウザ(Codespaces) | Mac の Claude Code | Mac の Claude Code | ブラウザだけ |
| GitHub アカウント | 必要 | 不要(Deploy key) | 不要(Deploy key) | 不要 |
| ターミナル | 実質不要 | 必要 | 必要 | 不要 |
| インストール作業 | なし | 端末セットアップ 30 分/人 | 30 分/人 + MCP 接続 5 分 | なし |
| デプロイ工程 | あり(Actions) | あり(Actions) | あり(wrangler / Builds) | 存在しない |
| 本番公開の関門 | PR マージ | PR マージ | PR マージ | なし(共有=即配布) |
| 差分レビュー | ○ | ○ | ○ | 実質不可 |
| AI が実物を確認できるか | × | × | ○(MCP) | ○(内蔵) |
| 詰まったとき | エンジニアに聞く | エンジニアに聞く | 自分でログを読める | AI が直す |
| 社外公開 | ○ | ○ | ○ | × |
| 独自ドメイン | ○ | ○ | ○ | × |
| データの置き場 | D1 / R2 / KV | D1 / R2 / KV | D1 / R2 / KV | DO Facet + SQLite |
| 既存 Cloudflare 資産を触れる | × | × | ○(DNS・Access・既存 Worker まで) | × |
| 事故の最大範囲 | リポジトリの中 | リポジトリ + Mac | アカウント全体(トークン次第) | ワークスペースの中 |
| 退職時の始末 | Codespace 削除 | Deploy key 削除(Mac に複製が残る) | 同左 + トークン失効 | Access 名簿から外すだけ |
| コードの持ち出し | 容易 | 容易 | 容易 | 困難 |
| 月額 | $50〜80(5 人) | $13 | $13(MCP 無償) | $5 + AI 従量 |
| 1 本目までの時間 | 数日 | 数日 | 1〜2 日 | 30 分(目標値・要実測) |
| 向く用途 | GitHub がある組織 | 基幹・個人情報・社外公開 | 同左(現行の強化) | 個人の道具・試作 |
| 成熟度 | 実装済み | 実装済み・本命 | 追加のみ(低リスク) | early-access |
Q4 の「作って試す → 作り直す」が本命の使い方である点は、Cloudflare OS 資料と同じです。MCP は、その「作り直す」側の速度と自立度を上げる部品です。
| 週 | やること | 判断ポイント |
|---|---|---|
| 1 週目 | エンジニアが自分の環境に 5 本の MCP を接続し、既存アプリ 1 本で通しで試す | 経路 C(API MCP からのデプロイ)が通るかを最初に実測 |
| 2 週目 | トークンの権限セットを確定。delete 権限を外した「つくる人用」を作る | 権限を外したまま Step 3〜7 が回るか |
| 3 週目 | プランB を使っている非エンジニア 1 名に MCP を足す | 「詰まったときに自分で原因を言えるようになったか」= 最重要判断 |
| 4 週目 | 同じ 1 名が本番公開まで | エンジニアの介在時間が減ったか(計測する) |
| 5 週目〜 | 部署展開。5 人を超えたら MCP Portal を検討 | delete 系ツールを止められているか |
execute から、静的アセット付き Worker を安定してデプロイできるか。3 段階の JWT を伴う手順を AI に安定して踏ませられるかは未実測。通れば「ブラウザだけで本番配信」が成立し、22 章の表が書き換わります。d1_database_delete などの破壊的ツールを、トークン権限だけで止められるか。Cloudflare の権限は Read / Edit 粒度。Edit を渡すと作成と削除の両方が付く可能性が高い。止められないなら、MCP Portal の導入が「任意」ではなく「必須」になります。wrangler deploy は動かない(プランB で実測済みの制約と同じ)。Step 2 までは Cowork、Step 3 以降は Claude Code、の線引きで正しいかを実機で確認。