Cloudflare MCPをCodexやClaudeにつないで分かったこと。Zero Trustまで構築して、結局「公式ルート」に戻った話

そもそも、最初からMCP（Model Context Protocol）を使いたかったわけではありません。

私がやりたかったのは、「AIに作業を任せたあと、確認のために毎回自分がCloudflareの管理画面を開き、その結果をまたAIへ伝える」という面倒な往復作業を減らすことでした。

GitHub上のコード変更やレビューはAIが追えるようになってきたのに、デプロイ先のCloudflareだけは人間が確認しに行かなければならない。「デプロイは成功したよ」「いまの設定はこうなっているよ」と人間が報告しないと、AIは次の作業に進めないわけです。

「このCloudflareの状態確認も、AI自身に直接やってもらえないだろうか？」

そう調べていく中でたどり着いたのがMCPでした。

結論から言うと、私の用途、つまり個人でCloudflareの状態を確認したり作業したりするのであれば、構成はかなりシンプルでした。Cloudflareが公式に用意しているMCPやAgent向けセットアップを使えばよかったのです。

しかし、最初からそこに気づけたわけではありません。途中ではCloudflare Zero Trustの「MCP Portal」を立ち上げ、OAuthのrefresh tokenエラーで身動きが取れなくなり、最後には苦労して作ったPortalを撤去するという、かなりの大回りをしました。

ただ、その遠回りがあったからこそ、「AIと外部サービスを連携させるとき、まず何から試すべきか」という勘所が掴めた気がします。

2026年9月16日追記
混同しやすい「Cloudflare API MCP Server」と「MCP Portal」の違い
2026年9月追記。今なら「Onboard your agent to Cloudflare」から始める
- plugin利用が間違いというわけではない
Codex Desktopでは、最初から公式ルートを使えばよかった
Claudeの場合。Custom Connectorから直接つなぐ
Claude Codeでは、環境の違いで一度ハマった
状態確認なら、OAuthの権限は必要最小限のReadから始める
なぜZero TrustのMCP Portalまで作ってしまったのか
頻発する「Invalid refresh token」
macOS Keychainまで確認することになった
原点回帰。最初からあった公式ルートの快適さ
「MCPで正常」と「実際のサイトが正常」は別
今後、別のサービスをMCP連携するときの考え方
まとめ。人間が「伝書鳩」をしなくてよくなった価値
よくある質問
参考にした公式情報

2026年9月16日追記

Onboard your agent to Cloudflareが表示されているCloudflareの公式ウェブサイトのスクリーンショット

この記事を書いたあと、別の作業でCodex DesktopとCloudflareを接続し直す機会がありました。

その際、Cloudflareの管理画面に表示されていた「Onboard your agent to Cloudflare」のプロンプトをそのままCodexへ渡す方法を試しました。

私の環境では、この方法でCloudflareのSkillsや複数のMCPが設定され、OAuth後にWorkerやbuild設定までCodex自身が確認できるようになりました。

2026年9月16日時点でもCloudflare公式のCodex向けドキュメントではCloudflare pluginを使う方法が案内されているため、plugin利用が間違いというわけではありません。

ただ、今の私なら手動でMCPを追加したりCLIの設定を始めたりする前に、まずCloudflare自身が用意しているagent onboardingを最後まで試します。

この点については、本文でも詳しく紹介します。

混同しやすい「Cloudflare API MCP Server」と「MCP Portal」の違い

クラウドへ直接接続する経路と、複数の接続を一つのゲートへ集約する仕組みを左右で比較したイラスト

今回大きく混乱した原因の一つが、「CloudflareのMCP」と呼びたくなるものに複数の仕組みがあったことでした。まずはここを整理しておきます。

1. Cloudflare API MCP Server

AIからCloudflare APIを利用するために、Cloudflare自身が提供しているRemote MCP Serverです。この記事では、こちらが中心になります。

2026年9月16日時点で、Cloudflare公式ドキュメントには次の接続先が掲載されています。

https://mcp.cloudflare.com/mcp

Cloudflareの案内によると、Code Modeを使うCloudflare API MCP Serverでは2,500を超えるAPI endpointを扱えます。CloudflareのさまざまなサービスへAIからアクセスするための窓口です。

2. Cloudflare MCP Portal

こちらはCloudflare Zero Trust側の機能です。

複数のMCP Serverを1つのHTTP endpointへ集約し、Cloudflare Accessのpolicyを使って接続できる利用者を管理したり、Portal内で利用できるtoolやpromptを設定したりできます。

一人で一つのMCP Serverへ接続するためだけの仕組みというより、複数のMCPや利用者をまとめて扱いたい場合に意味のある機能です。

3. AI client側の接続手段

Codex側のCloudflare pluginやMCP設定、Claude側のCustom Connectorなどは、Cloudflare側のMCP Serverへ接続するためのAI client側の仕組みです。

この「Cloudflare APIへアクセスするためのMCP Server」と「複数のMCPをまとめて管理するMCP Portal」の違いを最初から把握していれば、あそこまで迷走することはなかったと思います。

2026年9月追記。今なら「Onboard your agent to Cloudflare」から始める

記事執筆後、別のWorkersの作業でCodex DesktopとCloudflareを再接続した際、前回とは異なる方法を試してみました。

Cloudflareの管理画面に表示されていた「Onboard your agent to Cloudflare」という導線です。

ここにはAI agent向けのセットアップ用プロンプトが用意されていたため、Codex向けに表示されたテキストをコピーし、そのままCodex Desktopへ貼り付けてみました。

するとCodex自身がCloudflareの公式セットアップ手順を確認し、必要なSkillsやMCPの設定を進めてくれました。

CloudflareのOAuth画面で権限を許可し、Codex Desktopを再起動すると、実際に使っているCloudflare Workersの情報をCodex自身が確認できるようになりました。

今回は状態確認が目的だったため、権限もRead中心にしました。

Codexからは、次のような情報を直接確認できました。

対象Workerの情報
GitHubとの連携状態
production branch
build trigger
buildの状態

前回のように「どのMCPを手動登録すべきか」「pluginなのか手動MCPなのか」「CLIで認証するのか」と自分で構成を考える必要がなく、少なくとも今回の私の環境では、公式のonboarding導線から始める方法が一番迷いませんでした。

plugin利用が間違いというわけではない

念のため補足すると、従来のCloudflare pluginを使う方法が古い、あるいは間違いというわけではありません。

2026年9月16日時点のCloudflare公式ドキュメントでも、Codex Desktop向けにはCloudflare pluginをインストールする方法が案内されています。

Cloudflareによると、このpluginによってCloudflare Skillsが追加され、CloudflareのMCP serversも登録されます。

私の中で変わったのは「ツールの正否」ではなく、「試す順番」です。

今から私が同じ環境を作るなら、まず次の順番で試します。

Cloudflare管理画面で「Onboard your agent to Cloudflare」が表示されているか確認する
Codex向けに表示されたセットアップ用プロンプトをコピーする
そのままCodex Desktopへ貼り付ける
Codexに公式セットアップを最後まで進めてもらう
状態確認だけが目的なら、まず必要最小限のRead中心の権限を許可する
Codex Desktopを再起動する
「現在のWorkerを確認して」など、読み取り操作で接続を確認する

もしこの導線が表示されない場合や、うまくいかない場合は、Cloudflare公式のCodex向けガイドを確認します。

現在の公式ガイドでは、Codex DesktopのPluginsからCloudflareをインストールする方法も案内されています。

自分でMCPの構成を考えて手動設定を始める前に、まずCloudflare自身が現在用意している公式のagent setupを確認する。今の私なら、そこから始めます。

Codex Desktopでは、最初から公式ルートを使えばよかった

私が一番遠回りした原因は、CloudflareとCodexが公式に用意している接続方法を最初に確認せず、手動設定から始めてしまったことでした。

2026年8月時点でも、Codex DesktopにはCloudflare pluginが用意されていました。

2026年8月に私が試した環境では、そのpluginからcloudflare-apiというMCPが表示されました。

私の環境では、認証するとブラウザでOAuth画面が開き、アクセス権限を許可すると接続できました。

最終的に落ち着いた構成は、驚くほどシンプルでした。

Codex Desktop
    ↓
Cloudflare plugin
    ↓
cloudflare-api（MCP Server）
    ↓
Cloudflare API

なぜこの一本道に最初から行かなかったのか。

発端はChatGPTでした。当時ChatGPTでCloudflare連携を試した際、私がやりたかったCloudflareアカウントの状態確認まではうまく動かなかったのです。

そこで「ならCodexでも同じだろう」と勝手に思い込み、手動登録やZero Trustの導入に舵を切ってしまいました。

しかし実際には、同じCloudflare連携でもAI clientによって使える接続方法や機能は異なっていました。

特定のtoolの使い方だけを覚えるより、その時点でCloudflare公式が用意している入口を先に確認することが大事だと痛感しました。

Claudeの場合。Custom Connectorから直接つなぐ

Claude側でも、Cloudflare API MCP Serverへ直接接続できました。

私はClaudeのCustom Connectorを利用し、Remote MCPとしてCloudflareを登録しました。

私が利用した接続先は次のURLです。

https://mcp.cloudflare.com/mcp

OAuth認証を通すことで、通常のClaudeからCloudflareの情報を確認できました。当時のClaude Code Desktopからも同じCloudflare環境へアクセスできています。

Claude Codeでは、環境の違いで一度ハマった

Claude側でつまずいたのは、interfaceの違いでした。

Cloudflare公式のClaude Code向け手順を参考に、/pluginでCloudflare Skillsを追加しようとしたところ、次のエラーが返ってきました。

/plugin isn't available in this environment.

少なくとも私が使っていたClaude Code Desktop環境では、その/pluginコマンドは利用できませんでした。

現在のCloudflare公式Claude Codeガイドは、Claude Codeをterminal-based coding agentとして案内し、slash commandによるpluginの追加手順を掲載しています。

同じ製品名でも、CLIやDesktopアプリなど、実際に使っている環境によって利用できる入口が同じとは限りません。

AI関連の設定を調べるときは、「その製品に対応しているか」だけでなく、「自分が実際に使っている環境向けの説明なのか」まで確認したほうがよさそうです。

私はDesktopから利用できるCustom Connectorの経路を使い、結果としてそれで十分でした。

状態確認なら、OAuthの権限は必要最小限のReadから始める

クラウドへの接続権限を閲覧と変更に分け、まず閲覧だけを選択する考え方を鍵とゲートで示したイラスト

Cloudflare API MCP Serverへ接続すると、OAuthで許可するpermissionを選択できます。

ここは実際に使ってみて、かなり重要だと感じたところです。

AIに対してプロンプトで「見るだけにしてください」と指示するのと、Cloudflare側で本当にRead中心の権限しか与えないことは同じではありません。

Write権限を持っていれば、プロンプトで変更しないよう指示していても、技術的には変更可能な状態です。

プロンプトはAIへの指示ですが、OAuthのpermissionはCloudflare側で効く実際の権限境界です。

2026年8月の作業ではデプロイ設定の変更を伴ったためWriteも許可しましたが、9月に再設定したときは状態確認が目的だったため、Read中心の権限にしました。

CloudflareのOAuth認証でPagesのReadとWrite権限を選択する画面

Cloudflareは2026年8月22日、WranglerとCloudflare API MCP Serverでoptional OAuth scopesを選択できるようにしたと発表しています。

必要なoptional permissionだけを許可し、あとから必要に応じて追加するという運用がしやすくなっています。

ただし、Read-onlyでも、許可した範囲のCloudflare情報をAI clientが取得・利用できる点は変わりません。

Writeできないことと、情報へアクセスできないことは別です。WriteだけでなくReadについても、必要な範囲だけ許可する意識は持っておいたほうがよいと思います。

なぜZero TrustのMCP Portalまで作ってしまったのか

ここからが今回の遠回りの記録です。

最初にCloudflare公式MCPへ手動で直接接続しようとした際、OAuthのcallbackがうまく成立しないことがありました。

そこで私はこう考えてしまいました。

「直接つなぐより、Cloudflare自身が用意しているMCP Portalを間に置いたほうが安定するのではないか」

Cloudflare MCP Portal自体は正式な機能です。複数のMCP Serverをまとめたり、Cloudflare Accessを使って利用者を管理したり、toolやpromptの公開範囲を設定したりできます。

そこでZero Trustを設定し、MCP Serverを登録し、Portalを作り、Access Policyも設定しました。

Cloudflare Zero TrustでMCP Server Portalの作成が完了した画面

構成はこんな形です。

Codex
    ↓
Cloudflare MCP Portal
    ↓
Cloudflare API MCP Server

最初はこれで動きました。「かなり大変だったけれど、これで完成したかな」と思っていたのですが、そのあと認証周辺で問題が起きます。

頻発する「Invalid refresh token」

ノートPCとクラウドの間に複数の認証ゲートが増え、途中で接続が止まっている複雑な経路のイラスト

Portal経由で接続していると、次のエラーが出るようになりました。

invalid_grant: Invalid refresh token

再認証すれば一度は動くものの、また発生しました。

AI client側の認証情報、Portal側の認証、さらにPortalから上流MCPへ接続するためのOAuthと関門が増えたことで、どこが根本原因なのかを特定するのが難しくなってしまいました。

CloudflareのMCP Portal公式ドキュメントでは、上流MCP ServerのOAuth credentialをrefreshできなくなるとSync Requiredとなり、再認証が必要になる仕組みが説明されています。

ただし、そこで説明されている状態と、私が遭遇したinvalid_grantが同じ原因だったとまでは確認できませんでした。

私に分かったのは、もっと単純なことです。

必要としていない中間層を増やしたことで、問題が起きたときに調べなければならない場所まで増やしてしまった、ということでした。

macOS Keychainまで確認することになった

再認証しようとしてもOAuth画面が再び出てこない状態になり、最終的にはmacOSのKeychainに残っていたCodex MCPの認証情報を確認するところまで行きました。

対象を特定して削除することでOAuth認証をやり直せるようにはなりましたが、これは一般的なCloudflare MCPの設定方法ではありません。

同じエラーが出たからといって、いきなりKeychainを触ることはおすすめしません。まずは通常の再認証、MCPの接続解除と再追加、アプリの再起動などから試したほうがよいと思います。

Keychainを直接操作する場合も、対象を明確に特定できる場合だけにしたほうが安全です。別の認証情報を削除すれば、当然ほかの接続にも影響します。

しかも私の場合、一度復旧したあとに同じようなrefresh token問題が再発しました。

「個人が開発環境からCloudflareの状態を見たいだけなのに、なぜKeychainと格闘しているんだ……？」

そう思い、この構成を普段使いするのは面倒すぎると考えるようになりました。

原点回帰。最初からあった公式ルートの快適さ

複雑な中継経路を使わず、ノートPCからクラウドへ一本の接続線で直接つないだ状態を示すイラスト

2026年8月、手動設定したMCPやPortalの設定を整理し、改めてCodex Desktopを見るとCloudflare pluginから提供されたCloudflare MCPがありました。

不要な手動MCPを削除しCloudflare APIだけを残したCodex Desktopの設定画面

これを認証してみるとOAuth画面が開き、権限を選んで認証しただけで、Cloudflareの情報を取得できるようになりました。

そこで初めて、今回の私の用途にはPortalそのものが必要なかったと分かりました。

Zero Trustを設定し、Portalを作り、Access Policyを設定し、認証エラーを調べ、Keychainまで確認したあとで、最初からあった公式の入口へ戻ってきたことになります。

もちろん、MCP Portalという機能自体を否定するわけではありません。複数のMCP Serverを集約したり、組織として利用者やtoolを管理したりする明確な用途があります。

ただ、私のように自分のAI clientからCloudflareへ接続したかっただけなら、最初から公式のシンプルな接続方法を試せば十分でした。

不要になったPortalやZero Trust関連の設定は、そのあと削除しました。

そして2026年9月に再設定したときは、Cloudflare側の「Onboard your agent to Cloudflare」から始める方法を使いました。

この経験から、私が今重視しているのは「pluginか手動MCPか」という名前ではありません。

その時点でCloudflare自身が用意している公式の接続方法を先に確認することです。

「MCPで正常」と「実際のサイトが正常」は別

MCPを実際に使うようになり、もう一つ分かったことがあります。

MCP経由で確認できるCloudflare側の状態と、実際のユーザーが見るWebサイトの状態は別だということです。

MCPを実行している環境の通信制限によって、AIが公開ページへアクセスできなかったことがありました。

しかしCloudflare側のデプロイは正常で、通常のブラウザから確認するとサイトは問題なく表示されていました。

逆に、Cloudflare側が正常だからといって、レイアウトや表示内容まで意図どおりとは限りません。

MCPではサービス側の状態を確認する
ブラウザではユーザーから見える表示状態を確認する

私は今、このように役割を分けています。実際に使ってみて大事だと感じた区別です。

今後、別のサービスをMCP連携するときの考え方

今回の経験から、外部サービスをAIへ接続するときの考え方はかなり変わりました。

以前ならまず手動設定の方法を調べていたと思いますが、今ならもっと手前から確認します。

私なら今、次の順番で考えます。

サービス側に公式のAI agent onboardingがないか確認する
AIアプリ側に公式plugin、Skills、built-in connectorがないか確認する
サービス提供元が公式Remote MCPを用意していないか確認する
接続時は、まず必要最小限のRead権限で実際に情報が取れるか確認する
必要な場合だけWrite権限を追加する

PortalやGatewayのような構成を検討するのは、「複数のMCPを束ねたい」「組織としてアクセスを管理したい」といった具体的な問題が出てきてからでよいと思います。

仕組みを1つ増やせば、設定も認証情報も障害点も増えます。

解決したい明確な課題がないなら、接続はできるだけシンプルな形から試すほうが扱いやすいと感じています。

まとめ。人間が「伝書鳩」をしなくてよくなった価値

最初にMCPを調べた理由は、Cloudflareの管理画面を毎回自分が開き、その結果をAIへ伝える作業を減らしたかったからでした。

実際に使えるようになると、AI自身がCloudflare側の状態を取りに行けるようになりました。

CodexからWorkerやbuild triggerの状態を直接確認できます。

わざわざ自分でCloudflareを開いて、結果をAIへ伝えなくてよくなった。それだけでもかなり快適です。

MCPを導入すること自体が目的だったわけではありません。

人間がAIとCloudflareの間を行ったり来たりする「伝書鳩」のような回数を減らせたことが、私にとって一番大きな効果でした。

よくある質問

今からCodex DesktopとCloudflareをつなぐなら、pluginと「Onboard your agent」のどちらを使いますか？

私なら、まずCloudflare側に「Onboard your agent to Cloudflare」が表示されているか確認します。

表示されていれば、そこで用意されたCodex向けのプロンプトを渡し、公式セットアップを最後まで試してみます。

ただし、Cloudflare pluginが間違っているという意味ではありません。

2026年9月16日時点のCloudflare公式ガイドでも、Codex DesktopのPluginsからCloudflareをインストールする方法が案内されています。「Onboard your agent」が表示されない場合などは、公式ガイドの手順を確認するのがよいと思います。

Wranglerがあるのに、なぜMCPを使うのですか？

役割が違います。

Wranglerはローカルでの開発やデプロイ、migrationなどを行うための開発者向けCLIです。

一方、Cloudflare API MCP ServerはAIからCloudflare APIへアクセスし、Cloudflare側の状態を調べたり操作したりするための窓口です。

Cloudflareの現在のCodex向けガイドでも、Skills、MCP Server、Wranglerはそれぞれ異なる役割として案内されています。

どちらか一つに絞るというより、目的によって使い分けるものだと理解しています。

Cloudflare PagesやWorkers以外にも使えますか？

使えます。

Cloudflare API MCP ServerはPagesやWorkers専用ではありません。

CloudflareはCode Mode API MCPについて2,500を超えるAPI endpointを扱えると説明しています。公式のCodex向けガイドでも、Cloudflare API MCP ServerはDNS、WAF、Zero Trustなどのplatform operationを扱うものとして紹介されています。

Cloudflare API tokenをAIへ直接渡す必要がありますか？

今回のCodexやClaudeとの対話型接続ではOAuthを利用したため、API tokenを直接AIへ渡していません。

Cloudflare側でOAuth認証し、必要なpermissionを許可する方法を使いました。

Cloudflare API MCP Serverの接続先は？

2026年9月16日時点では、Cloudflare公式ドキュメントに次の接続先が掲載されています。

https://mcp.cloudflare.com/mcp

MCP関連は変化が速いため、実際に設定するときはCloudflare公式ドキュメントでも最新のendpointを確認してください。

MCP Portalを使うべきなのはどんな場合ですか？

私のように、個人で単一のAI clientからCloudflareへ接続したいだけなら、まずPortalなしの公式接続を試すほうがシンプルでした。

一方、「複数のMCP Serverをまとめたい」「Cloudflare Accessで利用者を管理したい」「toolやpromptの公開範囲をまとめて管理したい」「利用状況をAccess logで確認したい」といった目的があるなら、MCP Portalには明確な意味があります。

Portalそのものが悪いのではなく、私の用途には大きすぎた、というのが今回の結論です。

参考にした公式情報

Cloudflare Agent setup
https://developers.cloudflare.com/agent-setup/
2026年9月16日確認

Codex + Cloudflare
https://developers.cloudflare.com/agent-setup/codex/
2026年9月16日確認

Cloudflare’s own MCP servers
https://developers.cloudflare.com/agents/model-context-protocol/cloudflare/servers-for-cloudflare/
2026年9月16日確認

Claude Code + Cloudflare
https://developers.cloudflare.com/agent-setup/claude-code/
2026年9月16日確認

MCP server portals
https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/
2026年9月16日確認

Code Mode MCP server patterns
https://developers.cloudflare.com/agents/model-context-protocol/codemode/
2026年9月16日確認

Choose OAuth scopes for Wrangler and the Cloudflare API MCP server
https://developers.cloudflare.com/changelog/post/2026-08-22-wrangler-mcp-optional-oauth-scopes/
2026年9月16日確認

Get started with custom connectors using remote MCP
https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp
2026年9月16日確認