SYNON 記事 社内サービス開発
Cloudflare 公式 MCP / 社内サービス構築ガイド

プロンプトで書いて、そのまま配信する
— 非エンジニアのための全工程

作成日: 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 を入れれば非エンジニアがブラウザだけで完結する」という誤った期待のまま稟議を通すことになります。

第 I 部 — 何を使うのか決める人向け/所要 15 分

1結論全員

  1. MCP は「AI に手と目をつける規格」です。AI が Cloudflare の最新ドキュメントを読み、実際のアカウントの中身を見て、データベースやファイル置き場を作り、動いているアプリのログを読めるようになります。推測で書いていたものが、実物を確認しながら書くものに変わります。
  2. Cloudflare は自社の MCP サーバーを公式に、無償で公開しています。本体 1 本(Cloudflare API 全体)+ 用途別 16 本。すべてリモート型で、インストールは不要、URL を Claude に登録して OAuth で許可するだけです。
  3. 社内サービス構築で実際に使うのは 5 本です。docs(正しい書き方)/ bindings(器をつくる)/ api(何でもできる本体)/ builds(配信の様子)/ observability(動いているか)。Cloudflare 公式の Claude Code プラグインは、まさにこの 5 本を登録します。
  4. ただし「非エンジニアがブラウザだけで完結」はしません。デプロイ手段が標準 MCP に無いためです。Claude Code(+ wrangler)か GitHub のどちらかが必ず要ります。完全にブラウザだけで済ませたいなら、それは MCP ではなく Cloudflare OS の役割です。
  5. したがって、MCP 方式は「第 4 の独立方式」ではなく、プランA/B を強くする部品です。現行本命のプランB に MCP を足すのが、いま取れる最も費用対効果の高い一手です(第 III 部)。
要するに

Cloudflare OS = 非エンジニアが単独で完結する。関門なし。社外公開不可。

プランB + MCP = レビューという関門を残したまま、AI の失敗率だけを下げる。

この 2 つは競合しません。足すべきものが違います。

17 本
Cloudflare 公式 MCP サーバー(本体1+用途別16)
5 本
社内サービス構築で実際に使う数
0 円
MCP 導入による追加費用
0 本
デプロイ用のツール(=ここが分かれ目)

2MCP とは何か — 3 分で全員

MCP(Model Context Protocol)は、AI と外部サービスをつなぐ共通の差込口です。 Cloudflare 自身が公式ドキュメントで「AI アプリケーションにとっての USB-C ポート」と表現しています。

MCP が無いとき あなた 「DB を作って」 AI 学習した知識から、それらしい手順を書く 古い書き方 / 実在しない設定 の可能性 確認できない MCP があるとき あなた 「DB を作って」 AI MCP 共通の差込口 Cloudflare 本物のアカウント 実際に作られた。名前と ID が返る
図 1 — MCP は「AI に実物を触らせる」ための差込口。推測で書くのをやめさせる装置

2-1. 登場人物は 3 つだけ

用語実体今回でいうと
MCP ホストAI アシスタント本体Claude(Cowork / デスクトップ / Claude Code)
MCP クライアントホストの中でサーバーに接続する部分Claude の「コネクタ」機能
MCP サーバーツールを外に出す側Cloudflare 公式 MCP サーバー群

2-2. 接続方式は 2 つ

非エンジニアにとっての意味

インストールするものはありません。URL を 1 回登録して、ブラウザで「許可」を押すだけです。

難しさは「接続」ではなく、「どこまでの権限を渡すか」を決めるところにあります(7 章)。

3Cloudflare が標準で出している MCP サーバー一覧全員

すべて Cloudflare 公式(cloudflare/mcp-server-cloudflare および cloudflare/mcp リポジトリ)。 接続は URL を登録して OAuth するだけ。サーバー利用そのものに追加料金はありません。

3-1. 本体(1 本)

サーバーURL何ができるか
Cloudflare APImcp.cloudflare.com/mcpCloudflare API の全域(2,500 超のエンドポイント)。DNS・Workers・R2・Zero Trust など。Code Mode により、これ全部で 約 1,100 トークンしか消費しない(9 章)

3-2. 用途別(16 本)

#サーバーURL用途社内サービス構築で
1Documentationdocs.mcp.cloudflare.com/mcp最新の公式ドキュメントを検索◎ 必須
2Workers Bindingsbindings.mcp.cloudflare.com/mcpKV・D1・R2・Hyperdrive の作成と操作◎ 必須
3Workers Buildsbuilds.mcp.cloudflare.com/mcpビルド一覧・ビルドログ○ 配信の確認
4Observabilityobservability.mcp.cloudflare.com/mcp動いているアプリのログ・メトリクス◎ 必須
5Browser Runbrowser.mcp.cloudflare.com/mcpページ取得・Markdown 変換・スクリーンショット○ 出来上がりの目視確認
6Containercontainers.mcp.cloudflare.com/mcpサンドボックス開発環境
7AI Gatewayai-gateway.mcp.cloudflare.com/mcpAI のログ・プロンプト/応答の確認○ AI を使うなら
8AI Search (AutoRAG)autorag.mcp.cloudflare.com/mcp社内文書の検索基盤を操作△ 社内検索を作るなら
9Audit Logsauditlogs.mcp.cloudflare.com/mcp「誰が何を変えたか」の監査ログ◎ 統制で必須
10Logpushlogs.mcp.cloudflare.com/mcpLogpush ジョブの健全性
11GraphQLgraphql.mcp.cloudflare.com/mcpGraphQL Analytics API△ 集計が要るなら
12DNS Analyticsdns-analytics.mcp.cloudflare.com/mcpDNS の性能・障害調査
13Radarradar.mcp.cloudflare.com/mcpインターネット全体の傾向・URL スキャン× 社内用途では不要
14DEXdex.mcp.cloudflare.com/mcp社員端末から見たアプリ品質の監視△ Cloudflare One 利用時
15Cloudflare One CASBcasb.mcp.cloudflare.com/mcpSaaS の設定ミス検出△ Cloudflare One 利用時
16Agents SDK Docsagents.cloudflare.com/mcpAgents SDK のドキュメント検索△ 自作エージェントを作るなら
数え方の補足

GitHub リポジトリ側にはこのほか Blogblog.mcp.cloudflare.com/mcp)と Demo Day(デモ用の最小サーバー)も並んでいます。数え方で「16 本」「18 本」と揺れるのはこのためです。

社内サービス構築に関係するのは、上の表で ◎ と ○ を付けた 8 本だけだと思ってください。

3-3. 実際に使うのは 5 本

① 調べる cloudflare-docs 最新の公式ドキュメント。 古い書き方で書かせない。 いちばん効果が確実 ② 器をつくる cloudflare-bindings D1 / KV / R2 を作る。 SQL も流せる。 ※ 削除もできる(要注意) ③ 何でもやる cloudflare-api API 全域(2,500 超)。 Code Mode で 3 ツールに圧縮。 権限の絞り込みが命 ④ 確かめる cloudflare-observability cloudflare-builds 動いているか・配信できたか。 つくる人が自分で調べられる + 任意: browser(画面のスクリーンショット)/ auditlogs(誰が何を変えたか)/ ai-gateway(AI の費用) この 3 本は「作る」ためではなく「見守る」ために足す。1 本目の開発では無くてよい 16 本すべてを入れないこと AI が選ぶ道具が増えすぎると、かえって的外れなツールを呼ぶ。使う 5 本+必要になったら足す、が正解
図 2 — Cloudflare 公式 Claude Code プラグインが登録するのも、ちょうどこの 5 本
  cloudflare-api            ← 何でもできる本体(Code Mode)
  cloudflare-docs           ← 正しい書き方を調べる
  cloudflare-bindings       ← DB・ファイル置き場を作る
  cloudflare-builds         ← 配信の様子を見る
  cloudflare-observability  ← 動いているか見る

迷ったらこの 5 本+ Browser Run(見た目の確認用)だけ入れてください。

4何ができて、何ができないか — ここが分かれ目全員

4-1. Workers Bindings MCP の全ツール(21 本)

分類ツールできること
KVkv_namespaces_list / kv_namespace_create / kv_namespace_get / kv_namespace_update / kv_namespace_delete設定値の置き場を作れる・消せる
D1d1_databases_list / d1_database_create / d1_database_get / d1_database_query / d1_database_deleteデータベースを作れる・消せる・SQL を実行できる
R2r2_buckets_list / r2_bucket_create / r2_bucket_get / r2_bucket_deleteファイル置き場を作れる・消せる
Hyperdrivehyperdrive_configs_list / hyperdrive_config_create / hyperdrive_config_get / hyperdrive_config_edit / hyperdrive_config_delete外部 DB への接続設定
Workersworkers_list / workers_get_worker / workers_get_worker_code一覧を見る・詳細を見る・ソースを読む。それだけ
ここが分かれ目

Workers の 3 本はすべて「読み取り」です。作る・更新する・デプロイするツールは存在しません。

器(うつわ)— MCP が作れる ○ D1 データベース d1_database_create R2 バケット r2_bucket_create KV kv_namespace_create SQL の実行も可(d1_database_query) 削除も可。だから危ない(18 章) 中身(コード)— MCP は読めるだけ × workers_list / get_worker / get_worker_code 作る・更新する・デプロイするツールは無い 頼む → 調べる → 器を作る → コードを書く → → 動作を見る → 直す ? docs bindings AI 本体 observability / browser ここに MCP のツールが無い = wrangler / GitHub / API が要る
図 3 — MCP は「器」を作り「動作」を見る。だが「中身を配信する」工程だけが空いている

4-2. その他のサーバーのツール

サーバーツール備考
Cloudflare APIdocs / search / execute3 本だけ。execute が JavaScript を書いて認証付き API 呼び出しを実行する
Workers Buildsworkers_builds_set_active_worker / workers_builds_list_builds / workers_builds_get_build / workers_builds_get_build_logsビルドの確認だけ。ビルドを起動するツールは無い
Observabilityquery_worker_observability / observability_keys / observability_valuesログ検索・フィールド一覧・値の候補
これが第 III 部の比較の核心

Cloudflare OS には「デプロイ工程が存在しない」ので、非エンジニアが単独で完結します。

MCP 方式にはデプロイ工程が残ります。だから、それを担う仕組み(プランA/B)が必要なままです。

5費用と前提決める人

項目費用備考
公式 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 PortalZero Trust プラン統制を厚くする場合(19 章)。Logpush 書き出しは Enterprise のみ
結論

追加費用は実質ゼロです。MCP の導入判断は費用ではなく、「どこまでの権限を AI に渡すか」の判断です。

一次情報上の注意

「一部の機能は Workers の有料プランが必要」と公式リポジトリに記載があります。どの MCP サーバーのどのツールが該当するかの明記はありません。Paid 前提で見積もってください(25 章 未確認事項 2)。

第 II 部 — 作業工程(本編)Step 0 は用意する人/Step 1 以降は つくる人

6全体像全員

用意する人(エンジニア)が 1 回だけやる 0 下ごしらえ Workers Paid / 権限を絞った API トークン / Cloudflare Access / Claude Code と wrangler の導入 ここから つくる人(非エンジニア)が一人で回す 1 つなぐ MCP を Claude に接続(5 分・1 回だけ) 2 決める 何を作るかを日本語で書き切る(いちばん大事) 3 器をつくる D1 / KV / R2 を作らせる bindings 4 つくる プロンプトでコードを書かせる docs 5 出す(デプロイ) MCP に無い工程。wrangler / Workers Builds / API builds 6 確かめる 画面を撮る・ログを読む observability / browser 7 直す ログ → 原因 → 修正 のループ 8 本番へ エンジニアが承認(PR マージ)= 唯一の関門 ずっと続く Step 9 面倒をみる — 監査ログ / 使われているかの確認 / 棚卸しと撤去
図 4 — エンジニアが出てくるのは Step 0 と Step 8 の 2 か所だけ

7Step 0 — 用意する人がやることエンジニア

つくる人はこの章を読み飛ばして構いません。

7-1. アカウントと課金

7-2. 権限を絞った API トークンを作る ← いちばん重要

方式使いどころ権限の決まり方
OAuth(推奨)人が対話的に使うとき接続時にブラウザで権限を選ぶ画面が出る
API トークンCI や自動実行ダッシュボードで作るときに権限を選ぶ
○ 渡してよい Workers Scripts : Edit Workers KV : Edit D1 : Edit R2 : Edit Workers Observability : Read Account Resources : Read ← 必須。無いと自動検出できない × 渡さない Zone : DNS : Edit サイトが落ちる Zone : SSL/TLS 証明書が壊れる Account : Billing 課金が変わる Account : Members 人が増える/消える Zero Trust : Edit 入口の名簿が変わる ※ Access の名簿を AI に触らせない — 最後の砦だから Client IP Address Filtering を有効にしたトークンは未対応(公式 README に明記)。作ると原因不明で接続できません
図 5 — MCP の安全性は 9 割がこの表で決まる。渡していない権限は、どうプロンプトしても使えない

7-3. 入口(Cloudflare Access)を先に用意する

既存資料と同じです。Worker 単位/アカウント単位の Access を先に ON にし、all_workersall_preview_workers を有効化しておくと、新しく作られた Worker が自動的に社内限定になります。「誰も気づかないまま公開されていた」を仕組みで防ぐ、いちばん効く 1 手です。

7-4. 端末に Claude Code と wrangler を入れる

デプロイ手段が MCP に無いため、ここは避けられません(プランB の scripts/setup-mac.sh を流用)。

8Step 1 — つなぐ(5 分・1 回だけ)つくる人

つくる人の作業はここからです。入口は 3 つあり、できることが違います。

MCP に接続 仕様を固める コードを書く デプロイする Cowork / claude.ai 設定画面で URL を登録するだけ × Claude デスクトップ 同上。調べもの・確認向き × Claude Code(実作業) コマンド 2 行。ここだけが完結する ← ここが 分かれ目
図 6 — 仕様づくりまでは Cowork、実際に作るところからは Claude Code。プランB と同じ線引き

8-1. Cowork / claude.ai / デスクトップの場合

  1. カスタマイズ(Customize)> コネクタ(Connectors) を開く
  2. 」→「カスタムコネクタを追加
  3. URL を貼る(例: https://docs.mcp.cloudflare.com/mcp
  4. 「追加」→ ブラウザで Cloudflare のログインと権限の許可
  5. 会話画面の「+」ボタンで、その会話で使うコネクタを ON にする
Team / Enterprise プランの場合(Synon はこちら)

まず組織のオーナーが「組織設定 > コネクタ」で登録し、そのあと各メンバーが「接続」を押します。

メンバーが勝手に増やせません。これは統制上むしろ好都合です。

8-2. Claude Code の場合(公式の手順)

/plugin marketplace add cloudflare/skills
/plugin install cloudflare@cloudflare

この 2 行で、MCP サーバー 5 本と「スキル」がまとめて入ります。確認は次のコマンド。

claude mcp list

初回に Cloudflare のツールを使うと、ブラウザが開いて権限の許可を求められます。

8-3. 一緒に入る「スキル」が地味に効く

スキル内容
cloudflareWorkers・Pages・KV・D1・R2・AI・ネットワーク・セキュリティの総合
wranglerデプロイと運用のコマンド(= MCP に無い部分を埋める)
agents-sdk状態を持つ AI エージェントの作り方
durable-objects状態の共有・WebSocket・SQLite
web-perfWeb Vitals の計測と改善
building-mcp-server-on-cloudflare自社 MCP サーバーの作り方
cloudflare-one / cloudflare-one-migrationsZero Trust の設定と、他社製品からの移行
覚えておくこと

MCP = 実物に触る手段。スキル = 正しい手順の知識。この 2 つはセットです。

片方だけだと「正しい手順を知らないまま実物を触る」か「正しい手順は知っているが実物を確認できない」のどちらかになります。

9Code Mode の仕組み読まなくても作れます

Cloudflare API MCP は、2,500 を超える API を たった 3 つのツールで扱います。

ツール役割
docs公式ドキュメントを検索する
searchコードを書いて、API 仕様の中から目的のエンドポイントを探す
executeコードを書いて、認証付きの API 呼び出しを実行する

なぜこうするのか。トークン(AI が読む文字数)の問題です。

従来のやり方(1 つの API = 1 つのツール) 244,000 トークン ※ Cloudflare のブログ試算では 1,170,000 トークン。どちらにせよ、AI の頭が API の説明で埋まる Code Mode 約 1,100 トークン = 99.9% 削減。API が増えても、この 3 ツールのまま使える 実行は V8 サンドボックスの中。 ファイルアクセスなし・外向き通信は既定で無効
図 7 — AI の「頭の中」が API の説明で埋まらないので、あなたの依頼そのものに集中できる

?codemode=false を URL に付けると従来型(約 2,500 ツール)にも戻せますが、トークンが 244,000 に膨らむので通常は使いません。

10Step 2 — 決めるつくる人

いちばん大事で、いちばん飛ばされる工程

ここを飛ばすと、あとの全工程がやり直しになります。既存のプランB の /service-spec スキルと同じ考え方です。MCP は関係ありません。日本語の作業です。

答えるのは 6 つだけ。

  1. 誰が使う?(何人・どの部署・社外の人は含むか)
  2. 何を入れる?(画面に打ち込む項目を、日本語で全部並べる)
  3. 何を出す?(一覧・検索・集計・CSV 出力・通知)
  4. 今どうやっている?(Excel・紙・メール。現物を 1 件見せられるように
  5. 失敗したらどれくらい困る?(1 日止まって平気か。金額に関わるか)
  6. 個人情報を持つ?(氏名・連絡先・給与・健康に関する情報)
顧客からの問い合わせを記録する社内の台帳を作りたい。
使うのは営業部の 6 人。社外の人は使わない。
入れる項目:受付日・会社名・担当者名・連絡先・問い合わせ内容・
対応状況(未対応/対応中/完了)・対応メモ・対応者。
出したいもの:一覧表示、会社名での検索、月ごとの件数、CSV 出力。
いまは Excel を共有フォルダに置いていて、同時に開くと壊れる。
個人情報:会社の担当者名と会社のメールアドレスを持つ。

まずこの内容で仕様書を作って。作る前に、不明点があれば質問して。
6 番の答えで方式が決まります

「個人情報を持つ」なら、そもそも MCP 方式(=プランB 相当)で正解です。Cloudflare OS ではなく、レビューのある方式を選んでください(23 章の判断フロー)。

11Step 3 — 器をつくるつくる人

何を入れるか今回の台帳では
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 章)。

11-1. 本番と試用で 2 つずつ作る

  inquiry-log-staging   ← 試用環境(壊してよい)
  inquiry-log-prod      ← 本番(壊してはいけない)

Workers Free では D1 はアカウントあたり 10 個までです。1 アプリで 2 個使うので、Free だと 5 アプリで枯渇します。Paid にする理由のひとつです。

12Step 4 — つくるつくる人

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 の最新の書き方」を確認してから始めて。

12-1. 最後の 1 行が効く理由

AI が学習で覚えている Cloudflare の書き方は、必ず古くなります。Cloudflare は設定ファイルの形式(wrangler.tomlwrangler.jsonc)やバインディングの書式を実際に変えてきました。

docs MCP なしdocs MCP あり
AI「wrangler.toml[[d1_databases]] と書きます」
→ 動くこともあるが、最新の推奨形ではない
あとで詰まる。原因が分からない
AI → docs MCP →「最新はこう」→ その通りに書く
一発で通る
非エンジニアが覚えるべき唯一のプロンプト技術

「調べてから書いて」。この 5 文字を毎回付けるだけで、失敗のかなりの割合が消えます。

12-2. できあがるもの

  ~/社内サービス/inquiry-log/
    ├ wrangler.jsonc      ← 設定(D1 の ID などが書いてある)
    ├ src/index.ts        ← サーバ側の処理
    ├ public/index.html   ← 画面
    └ docs/spec.md        ← Step 2 の仕様書

この時点ではまだ誰も使えません。あなたの Mac の中にあるだけです。

13Step 5 — 出す(デプロイ)つくる人

ここが MCP に無い工程

取れる道は 3 つあります。

コード Mac の中 A wrangler で配信 「staging に配信して」と頼むだけ。承認の関門なし B GitHub → Workers Builds push すると自動で配信。PR マージ = 本番承認 C API MCP の execute 理屈上は可能。3 段階の JWT が要る。要実測 URL みんなが使える Access 社内限定の入口 名簿に無い人は入れない
図 8 — 試用環境は A、本番は B。C が通れば「ブラウザだけで本番配信」が成立するが、まだ実測していない
経路やること非エンジニア単独本番向き承認の関門
A. wrangler「staging に配信して」と頼むstaging のみなし
B. Workers Builds(GitHub)git push → 自動ビルド → 配信PR マージ = あり
C. Cloudflare API MCPexecute で Script Upload API を叩く△ 要検証なし

13-1. 経路 A — wrangler(試用環境はこれ)

このアプリを staging 環境に配信して。
配信できたら URL を教えて。

Claude Code が wrangler deploy を実行します。つくる人はコマンドを覚える必要がありません。ただしターミナル(Claude Code)が必要なので、Cowork やブラウザだけでは到達できません。

13-2. 経路 B — Workers Builds(本番はこれ)

GitHub リポジトリと Worker を接続しておくと、push だけで配信されます。プランB の仕組み(Deploy key + ブランチ 3 本 + PR マージ=本番承認)がそのまま使えます。

Workers Builds MCP はここで効きます。

さっきの配信、成功した?失敗していたらログを見て原因を教えて。

AI は workers_builds_list_buildsworkers_builds_get_build_logs を呼び、ビルドログを読んで日本語で説明します。これまで「エンジニアに聞かないと分からなかった」ことが、自分で分かるようになります。

13-3. 経路 C — API MCP で直接デプロイ(要実測)

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 番に置きました。最初に潰すべき項目です。通らない前提で計画してください。

14Step 6 — 確かめるつくる人

デプロイした「つもり」で終わらせないための工程です。MCP がいちばん効くのがここ。

14-1. 見た目を確かめる — Browser Run MCP

https://inquiry-log-staging.xxx.workers.dev のスクリーンショットを撮って見せて。
一覧画面と、新規登録の画面の両方。

AI が実際にブラウザで開いて、画像を返します。「動いていると言われたが、開いたら真っ白だった」が、その場で分かります。

14-2. 中身を確かめる — Observability MCP

このアプリ、さっきの 10 分間でエラーは出ている?
出ていたら、いちばん多いエラーの内容を教えて。

AI は query_worker_observability を呼び、ログを検索して答えます。どんな項目で絞り込めるかは observability_keys、その値の候補は observability_values で調べます。

14-3. データを確かめる — Bindings MCP

inquiry-log-staging の中身を見せて。何件入っている?

d1_database_query実際に SQL を実行して答えます。

MCP が無いときMCP があるとき
つくる人「動きません」
エンジニア「ログ見ますね」
半日待ち
つくる人「エラー出てる?」
AI「D1 のテーブルが無いというエラーが 12 件。作成 SQL を流し忘れています」
つくる人「じゃあ流して」… 3 分
投資対効果はここに出る

MCP 方式の価値は開発の速さより「詰まったときに自分で抜け出せること」です。24 章の撤退基準もこれで測ります。

15Step 7 — 直すつくる人

症状を言う 「登録が効かない」 ログを読む query_worker_ observability 原因を聞く AI が日本語で説明 1 か所だけ直す プロンプト 再配信 wrangler browser MCP で画面を撮って、直ったことを目で確かめてから次へ このループを 2〜3 周回すのが普通。1 周で完璧にしようとしないこと
図 9 — 「調べてから直して」「1 か所だけ」。この 2 つが言えれば非エンジニアでも回る
ダメな頼み方良い頼み方
「動きません。直して」「登録ボタンを押すと画面が固まる。ログを見て原因を教えて」
「たぶんデータベースのせい」まず調べてから直して。推測で書き換えないで」
「全部作り直して」この 1 か所だけ直して。他は触らないで」

16Step 8 — 本番へエンジニア

ここだけはエンジニアが関門になります(プランB と同じ)。

 つくる人                        エンジニア
  │                               │
  ├ docs/releases/YYYY-MM-DD-名前.md を書く
  │   (何を作ったか・誰が使うか・止まると何が困るか)
  │                               │
  ├─── Chatwork で連絡 ─────────→ │
  │                               ├ 差分を見る(5 分)
  │                               ├ Access の名簿を確認
  │                               └ PR をマージ = 本番公開
  │                               │
  ←──── Chatwork に配信結果 ───────┤
公開前に必ず 1 回

Step 0 で all_workers を ON にしていれば自動で社内限定になりますが、本番公開の前に社外の回線から開いて「入れないこと」を目で確かめてください。ここだけは仕組みを信じきらないほうが安全です。

17Step 9 — 面倒をみるエンジニア

やること使う MCPプロンプト例
誰が何を変えたかAudit Logs「先週、Cloudflare の設定を変えたのは誰?」
ちゃんと使われているかObservability「このアプリ、今月何回使われた?」
AI の費用AI Gateway「今月のトークン消費とコストを教えて」
遅くないかDNS Analytics / GraphQL「応答時間の推移を出して」
棚卸しの基準(既存資料と同じ)

「6 か月以上使われていない」「作った本人しか使っていない」「月 1 回しか使わない」が揃ったら廃止

増やすより、減らすほうが難しい。最初から捨てる基準を決めておいてください。

第 III 部 — 統制と、既存プロセスとの比較決める人向け/所要 15 分

18事故を防ぐ 4 層決める人

MCP を入れると、AI が本物の本番環境を触れるようになります。プランA/B が「GitHub の中で完結していた」のと決定的に違う点です。4 層で止めます。

1 トークンの権限 渡していない権限は、どうプロンプトしても使えない。DNS・課金・Access の名簿は渡さない いちばん効く 2 Cloudflare Access 作ったものが社外に出ない。all_workers を ON にすれば新規 Worker も自動で社内限定 3 本番公開の承認 PR マージ(プランB と同じ)。未完成のまま本番に出ることを止める 4 MCP Portal(任意・5 人を超えたら) 誰がどのツールを使えるかを会社が決める。delete 系ツールを個別に無効化できる
図 10 — 上から順に効く。1 層目だけでも 1〜2 人目の段階は足りる
止められる事故止められない事故
トークンの権限DNS を書き換える、課金設定を触る、Access の名簿をいじる渡した権限の中での削除(D1 を消す等)
Access作ったものが社外から見える社内の人が中身を見ること
本番承認未完成のまま本番に出るstaging を壊すこと(壊してよい)
MCP Portal危険なツールが個人の裁量で使われる設定を怠ったとき
いちばん多い事故は「削除」です

d1_database_deleter2_bucket_delete も、確認なしで本物を消します。

Cloudflare の権限は Read / Edit の粒度なので、「作らせるが消させない」を厳密にやるのは難しい可能性があります。 厳密にやるなら、つくる人のトークンは Read にして作成はエンジニアが代行するか、MCP Portal でツール単位に切るかのどちらかです。25 章の未確認事項 3 番で最初に確かめてください。

19MCP Portal — 会社として配るならエンジニア

Cloudflare One の MCP server portal は、複数の MCP サーバーを 1 つの入口にまとめる仕組みです。

社員の Claude 接続先はポータル 1 つ MCP Portal Access で 誰が入れるか ツール単位で 有効/無効 ツールに 別名をつける Gateway で DLP 検査・ログ docs MCP(そのまま全部許可) bindings MCP delete 系のツールだけ無効にできる 自社で作った MCP(Chatwork など) 制約 1 ポータル 40 本まで リモート HTTP のみ 拒否するサーバーあり MFA が効かない Logpush は Ent のみ
図 11 — 「作らせるが消させない」を実現できる唯一の層。ただし制約も多い

19-1. できること

19-2. 制約(先に知っておくこと)

制約内容
サーバー数1 ポータルあたり最大 40 本
対応方式リモート HTTP のみ(stdio 専用サーバーは不可)
相性ポータル経由のクライアントを拒否するサーバーがある
認証の穴独立 MFA・目的の正当化・一時的な認証は、ポータル経由では強制されない
転送Gateway 経由では SSE 非対応
DNSgateway.agents.cloudflare.com への CNAME が必要
書き出しLogpush はエンタープライズプランのみ
Synon としての判断(案)

1 人目・2 人目の段階では Portal は要りません。トークンの権限を絞るだけで足ります。

部署展開(5 人以上)に入る段階で、delete 系ツールを止めるために導入する、が費用対効果の合う順番です。

20MCP 新仕様(2026-07-28)— 運用側に効く点エンジニア

Cloudflare の MCP サーバーは新仕様に対応済みです。運用側に意味があるのは 2 つ。

変更内容効いてくるところ
ステートレス化ハンドシェイクとセッション ID が不要に。1 リクエストが独立接続が切れて詰まる、が減る
Mcp-Method / Mcp-Name ヘッダ中身を解析せずにゲートウェイが用途を判別できるツール単位のレート制限と可視化ができる=統制の材料
MRTR情報が足りないとき input_required を返し、クライアントが追加情報を付けて再送長時間の接続維持が不要に
認可の強化動的クライアント登録は非推奨へ。事前登録と CIMD を推奨。RFC 9207 で発行者を識別将来の設定変更に備える
廃止の猶予非推奨機能は削除まで 12 か月一度組んだら 1 年は持つ

21そもそも層が違う決める人

非エンジニアの単独完結度 プランA Codespaces GitHub アカウント 必要 PR マージ = 関門あり 社外公開 ○ / レビュー ○ $50〜80 / 月 プランB ローカル・現行本命 ターミナル 必要 PR マージ = 関門あり 社外公開 ○ / レビュー ○ $13 / 月 プランB + MCP 今回の推奨 ターミナル 必要(変わらず) PR マージ = 関門あり 自分で調べられる ← 差分 $13 / 月(MCP 無償) Cloudflare OS Gadget ブラウザだけ 共有 = 即配布・関門なし 社外公開 × / レビュー 実質不可 $5 + AI 従量 MCP が足すもの = 左の 3 つ すべてに効く「AI の目と手」 ・古い書き方で書かない(docs) ・器を自分で作れる(bindings) ・詰まったとき自分で調べられる(observability / builds / browser) = MCP は「方式」ではなく「方式に足す部品」。Cloudflare OS には最初から内蔵されている機能に相当する
図 12 — MCP は 4 つ目の方式ではない。既存方式の失敗率を下げる部品として効く

22比較一覧表 — 4 方式決める人

観点プランA
(Codespaces)
プランB
(ローカル・現行本命)
プランB + MCP
(今回)
Cloudflare OS
つくる人が触るものブラウザ(Codespaces)Mac の Claude CodeMac の Claude Codeブラウザだけ
GitHub アカウント必要不要(Deploy key)不要(Deploy key)不要
ターミナル実質不要必要必要不要
インストール作業なし端末セットアップ 30 分/人30 分/人 + MCP 接続 5 分なし
デプロイ工程あり(Actions)あり(Actions)あり(wrangler / Builds)存在しない
本番公開の関門PR マージPR マージPR マージなし(共有=即配布)
差分レビュー実質不可
AI が実物を確認できるか××○(MCP)○(内蔵)
詰まったときエンジニアに聞くエンジニアに聞く自分でログを読めるAI が直す
社外公開×
独自ドメイン×
データの置き場D1 / R2 / KVD1 / R2 / KVD1 / R2 / KVDO 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
表から読み取るべき 3 点
  1. MCP を足しても、変わるのは 4 行だけです。「AI が実物を確認できるか」「詰まったとき」「既存資産を触れる」「事故の最大範囲」。費用も関門も工程も変わりません。だから低リスクで足せます。
  2. ただし「事故の最大範囲」だけが悪化します。アカウント全体に届くようになるためです。これを 18 章の 4 層で相殺できるかが、導入可否の唯一の争点です。
  3. Cloudflare OS の列は、他の 3 列と競合していません。関門が無く、社外公開できず、レビューもできない。用途が最初から別です。

23判断フロー全員

Q1. 社外の人が使う? はい プランB + MCP いいえ Q2. 止まると業務が止まる? はい いいえ Q3. 個人情報を持ち続ける? はい いいえ Q4. 3 か月後も部門で使っている? (= 本人にも分からないことが多い) はい まず Cloudflare OS で試作 → 定着したら プランB + MCP で作り直す いいえ / わからない Q5. 上記すべて いいえ Cloudflare OS Q4 の「作って試す → 作り直す」が本命。 プランB の最大コストは 「作ったが使われなかった」損失
図 13 — 上から順に。はい が 1 つでも出たらそこで止まる

Q4 の「作って試す → 作り直す」が本命の使い方である点は、Cloudflare OS 資料と同じです。MCP は、その「作り直す」側の速度と自立度を上げる部品です。

24導入順序と撤退基準決める人

やること判断ポイント
1 週目エンジニアが自分の環境に 5 本の MCP を接続し、既存アプリ 1 本で通しで試す経路 C(API MCP からのデプロイ)が通るかを最初に実測
2 週目トークンの権限セットを確定。delete 権限を外した「つくる人用」を作る権限を外したまま Step 3〜7 が回るか
3 週目プランB を使っている非エンジニア 1 名に MCP を足す「詰まったときに自分で原因を言えるようになったか」= 最重要判断
4 週目同じ 1 名が本番公開までエンジニアの介在時間が減ったか(計測する
5 週目〜部署展開。5 人を超えたら MCP Portal を検討delete 系ツールを止められているか
撤退基準
  • 3 週目に「エンジニアへの質問回数」が減らなければ、MCP を配る価値はありません。接続だけ残して、プロンプトの型(12 章・15 章)の教育に切り替えてください。
  • 事故が 1 件でも起きたら(本番の削除・意図しない設定変更)、即座にトークンを Read に落とす。MCP の危険は速度ではなく、権限の広さにあります。

25未確認事項決める人

この章を読まずに稟議へ回さないこと
  1. 【最優先】Cloudflare API MCP の execute から、静的アセット付き Worker を安定してデプロイできるか。3 段階の JWT を伴う手順を AI に安定して踏ませられるかは未実測。通れば「ブラウザだけで本番配信」が成立し、22 章の表が書き換わります。
  2. どの MCP サーバーのどのツールが Workers Paid を要求するか。「一部の機能は有料プランが必要」とだけ書かれており、対応表は公開されていない。
  3. 【最優先】d1_database_delete などの破壊的ツールを、トークン権限だけで止められるか。Cloudflare の権限は Read / Edit 粒度。Edit を渡すと作成と削除の両方が付く可能性が高い。止められないなら、MCP Portal の導入が「任意」ではなく「必須」になります。
  4. MCP Portal 経由で bindings MCP が正常に動くか。「ポータル経由のクライアントを拒否するサーバーがある」と公式に注意書きあり。
  5. Cowork から MCP 経由でどこまでできるか。ファイル作成はできるが wrangler deploy は動かない(プランB で実測済みの制約と同じ)。Step 2 までは Cowork、Step 3 以降は Claude Code、の線引きで正しいかを実機で確認。
  6. Team / Enterprise の組織コネクタで、メンバーごとに接続先を制限できるか。オーナーが登録し各自が接続する形までは確認済み。サーバー単位の出し分けは未確認。
  7. 監査ログに、MCP 経由の操作が「MCP 経由」と分かる形で残るか。残らない場合、事故時の追跡が難しくなります。
  8. Browser Run MCP の従量課金の実額。スクリーンショット確認を習慣にすると回数が増えます。

26参考(一次情報)