Cloudflare公式MCPをCodexとClaudeにつないだ。Zero Trust Portalまで作って分かったこと

ノートPCからクラウドへ直接つながる経路と、複数の経路を通る遠回りを対比したMCP接続のイラスト AI
本サイトはプロモーションが含まれています

最初からMCPを使いたかったわけではありません。私がやりたかったのは、AIに作業を任せたあと、その結果を確認するために自分が毎回Cloudflareの管理画面を開き、そこで見つけた情報をまたAIへ伝える、という作業を減らすことでした。

GitHub上の変更やレビューはAIが追えるようになってきたのに、その先のCloudflareだけは私が確認する。「デプロイは成功している」「この設定になっている」と私が伝えなければ、AIは先へ進めません。それが面倒くさい。ここもAIにやってもらいたい。

そこで、「Cloudflareの状態もAI自身が直接確認できないのか」と調べ始め、MCPへたどり着きました。結論からいうと、私の用途ではかなりシンプルでした。Cloudflareが提供している公式のRemote MCPへ直接つなげばよかったのです。

ただ、私は最初からそこへたどり着けたわけではありません。途中ではCloudflare Zero TrustのMCP Portalまで作り、OAuthのrefresh tokenで詰まり…そして最後には、苦労して作ったPortalを撤去しています。

かなり遠回りしました。でも、その経験があったからこそ、Cloudflareに限らず「AIと外部サービスをつなぐとき、何から試すべきか」はかなり分かった気がします。

私はCloudflareやMCPの専門家ではありません。この記事は2026年8月22日に実際に設定した経験をもとに、同日時点のCloudflare・Anthropicの公式情報も確認しながらまとめています。

Cloudflare API MCP ServerとMCP Portalは別物

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

今回かなり混乱した理由の一つが、「Cloudflare MCP」と呼びたくなるものがいくつも出てきたことでした。

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

2026年8月22日時点の接続先は、次のURLです。https://mcp.cloudflare.com/mcp

Cloudflareは、このAPI MCP Serverから2,500を超えるAPI endpointを扱えると説明しています。つまり私が使いたいCloudflare Pages専用ではなく、CloudflareのさまざまなサービスへAIからアクセスするための入口です。

一方の Cloudflare MCP Portal は役割が違います。こちらはCloudflare Zero Trust側の機能で、複数のMCP Serverを一つの入口へまとめたり、Access Policyを使って利用者を管理したりするためのものです。

さらに、CodexにはCloudflare pluginがあり、ClaudeにはRemote MCPを登録するCustom Connectorがあります。これらはCloudflare側のMCP Serverそのものではなく、AI client側からそこへ接続するための入口です。

この違いを最初から理解していれば、私はもう少し早く整理できたと思います。

Codex Desktopでは、最初にCloudflare pluginを見ればよかった

私が一番遠回りした原因は、Codex Desktopの中にすでに用意されていた入口を最初に確認しなかったことでした。

CloudflareはCodex向けの公式setupを用意しており、Codex DesktopではCloudflare pluginを利用できます。私の環境では、そのpluginからcloudflare-apiというMCPが表示されました。

Codexのプラグイン一覧にCloudflareが表示されている設定画面

これを認証すると、CloudflareのOAuth画面が開きます。そこでCloudflareへのアクセス権限を確認して認証すれば、CodexからCloudflareの情報を取得できるようになりました。

最終的な構成は、かなり単純です。

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

これだけです。

ところが私は、最初にこのcloudflare-apiを試していませんでした。もともとCloudflareとの連携をChatGPTから試し始めたのですが、ChatGPTではCloudflareとの連携自体はできても、私がやりたかったアカウントの状態確認まではできませんでした。

ChatGPTに表示されるCloudflare↓

ChatGPTのチャット画面にCloudflareが表示されている画面

そこで「Codexでも同じなんだろう」と思い込んでしまったのが、遠回りの原因でした。

だから別のMCPを手動で登録し、その先でZero Trustまで設定することになります。大変だったのに、本当に無意味なことをしていました。

2026年8月22日時点では、同じCloudflare連携でもChatGPTとCodexでは実際にできることがかなり違ったのです。

ClaudeではCustom Connectorから直接つなげた

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

ClaudeにはRemote MCPを追加するCustom Connectorがあります。私はそこへCloudflare API MCP ServerのURLを登録し、Cloudflare側でOAuth認証しました。接続先はCodexと同じhttps://mcp.cloudflare.com/mcpです。

私の環境では、このConnectorから通常のClaudeでCloudflareの情報を確認できました。また、Claude Code Desktopからも同じCloudflare環境へアクセスできました。

Claude CodeのCLI向け手順をDesktopで試して、一度ハマった

Claude側では別のところでも少しつまずきました。

Cloudflare公式にはClaude Code向けのsetupもあり、Cloudflare Skillsをpluginとして追加する方法が紹介されています。そこで私もpluginを追加するslash commandを試しました。

ところが、返ってきたのは、

/plugin isn't available in this environment.

でした。

私が使っていたのは、その手順が想定しているCLIではなくClaude Code Desktopだったからです。

ここで、「Claude Codeに対応している」と書かれていることと、「Claude Code Desktopでも同じ操作ができる」ことは別だと気づきました。同じ製品名でも、CLI、Desktop、Webでは使える入口が違うことがあります。

AI関連の設定方法を調べるときは、「この製品で使えるか」だけでなく、自分が実際に使っている環境向けの説明なのかまで確認したほうがよさそうです。私はそこでCLI側を無理に合わせるのをやめ、Desktopから利用できるRemote Connectorの経路を使いました。結果として、それで十分でした。

OAuthでは、まず必要最小限の権限から始める

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

Cloudflare API MCP Serverへ接続すると、OAuthで許可する権限を選びます。ここは実際に使ってみて、かなり重要だと思ったところです。

AIへ「今回は見るだけにしてください」と頼むことと、Cloudflare側で本当にRead権限しか与えないことは同じではありません。

Write権限を持っていれば、AIへ変更しないよう指示していても、技術的には変更できます。プロンプトはAIへの指示ですが、OAuthのpermissionはCloudflare側で効く実際の権限境界です。

私の場合は途中でCloudflare側のデプロイ設定を変更する工程があったためWriteも許可しました。しかし、状態を確認するだけなら、今の私ならまずReadから始めます。

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

Cloudflareは2026年8月22日、Cloudflare API MCP Serverなどでoptional OAuth scopesを個別に選べるようにしたと発表しています。必要なscopeだけを許可し、あとで必要になったときに追加する、という運用がしやすくなっています。

ただし、Read-onlyなら何も気にしなくていいわけでもありません。Cloudflareの情報をAIに読ませる以上、許可した範囲のプロジェクト情報やドメイン、設定などはAI client側で扱われます。

「変更できない」と「情報を渡さない」は別です。WriteだけでなくReadについても、必要な範囲だけ許可する。そのくらいの考え方は持っておいたほうがよいと思います。

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

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

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

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

これは完全に見当違いな発想だったわけではありません。Cloudflare MCP Portalは正式な機能で、複数のMCP Serverを一つへまとめたり、Cloudflare Accessで利用者を管理したりできます。

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

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

構成はこんな形です。

Codex
    ↓
Cloudflare MCP Portal
    ↓
Cloudflare API MCP Server

そして、この経路は一度ちゃんと動きました。Cloudflareの情報を取得できましたし、そのときは「かなり大変だったけれど、これで完成したかな」と思っていました。

ところが、そのあと認証周辺で問題が起きます。

invalid_grant: Invalid refresh tokenで詰まった

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

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

invalid_grant: Invalid refresh token

再認証すると、一度は動きます。しかし、また発生しました。

ここで、何が根本原因だったかは断定できません。AI client側にも認証情報がありますし、Portal側の認証もあります。さらにPortalから上流のMCP Serverへ接続するためのOAuthも関係します。

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

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

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

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

最後にはmacOS Keychainまで調べることになった

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

対象を特定して削除すると、OAuth認証を最初からやり直せるようになりました。

ただし、これは 一般的なCloudflare MCPの設定方法ではありません。同じエラーが出たからといって、いきなりKeychainを触ることはおすすめしません。まずは通常の再認証、MCPの接続解除と再追加、アプリの再起動などから試すべきです。

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

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

なかなか疲れる展開です。

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

そして、最初からあった公式の入口へ戻った

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

改めてCodex Desktopを見ると、Cloudflare pluginから提供されたcloudflare-apiがあります。

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

これを認証してみました。CloudflareのOAuth画面が開き、権限を選んで認証します。そのあとCloudflareの情報を確認してみると、普通に取得できました。

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

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

ただ、ここから「MCP Portalは使わないほうがいい」という結論にはなりません。Portalには、複数のMCP Serverを集約したり、組織として利用者やtoolを管理したりする明確な用途があります。でも私にはそこまでの機能は不要です。

自分のAI clientからCloudflare公式MCPへ接続したかっただけなら、まずdirect接続を試せばよかったのです。

不要になったPortalやZero Trust関連の設定は、そのあと削除しました。最終的には、普段使う公式のdirect routeだけが残りました。

MCPで正常でも、実際のサイトが正常とは限らない

Cloudflare MCPを実際に使うようになって、もう一つ分かったことがあります。MCPから確認できるCloudflare側の状態と、実際にユーザーが見るWebサイトの状態は別です。

実際、MCPを実行している環境の通信制限によって、公開ページへアクセスできなかったことがありました。そのときもCloudflare側のデプロイは正常で、別のブラウザから確認するとサイトも問題なく表示されていました。

つまり、MCPからWebページを開けなかったからといって、サイトが落ちているとは限りません。逆に、Cloudflare側が正常だからといって、レイアウトや表示内容まで正常だとも限りません。

私は今、MCPではサービス側の状態を確認し、ブラウザではユーザーから見える状態を確認すると分けています。

次に別のサービスをMCPでつなぐなら

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

まず、そのAIアプリの中に公式pluginやbuilt-in connectorがないか確認します。それがなければ、サービス自身が公式Remote MCPを提供していないか調べます。

公式Remote MCPがあるなら、まずそこへ直接つなぎます。最初は必要最小限のRead権限で、本当に欲しい情報が取れるか確認します。

それで足りるなら、そこで終わりです。

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

複雑な構成のほうが本格的に見えることはあります。でも、仕組みを一つ増やせば、設定も認証情報も障害点も増えます。

それによって解決したい問題があるなら使えばいい。まだその問題を持っていないなら、先に増やす必要はありません。

Cloudflare MCPを使えるようになって変わったこと

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

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

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

FAQ

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

Wranglerとの違いは、役割で考えると分かりやすいです。

Wranglerはローカルでの開発やデプロイなど、Cloudflare開発のためのCLIとして使われます。一方、Cloudflare API MCP ServerはAIからCloudflare APIへアクセスし、サービス側の状態を調べたり操作したりする入口です。

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

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

使えます。

Cloudflare API MCP ServerはPages専用ではありません。Cloudflareは2,500を超えるAPI endpointを扱えると説明しており、Cloudflareのさまざまなサービスを対象にできます。

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

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

Cloudflare側でOAuth認証し、必要な権限を許可する方法を使いました。別の自動化用途ではAPI tokenを利用する方法もあります。

Cloudflare API MCP Serverの接続先は？

2026年8月22日時点では、次のURLです。https://mcp.cloudflare.com/mcp

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

参考にした公式情報

Cloudflare’s own MCP servers
https://developers.cloudflare.com/agents/model-context-protocol/cloudflare/servers-for-cloudflare/
2026年8月22日閲覧

Codex + Cloudflare
https://developers.cloudflare.com/agent-setup/codex/
2026年8月22日閲覧

Claude Code + Cloudflare
https://developers.cloudflare.com/agent-setup/claude-code/
2026年8月22日閲覧

MCP server portals
https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/
2026年8月22日閲覧

Code Mode MCP server patterns
https://developers.cloudflare.com/agents/model-context-protocol/codemode/
2026年8月22日閲覧

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年8月22日閲覧

Get started with custom connectors using remote MCP
https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp
2026年8月22日閲覧

スポンサーリンク

コメント