Claude Code API認証 Claude Code Cloudflare MCP MCPサーバー セットアップ トラブルシューティング

Cloudflare公式MCPサーバーをClaude Codeに接続する方法

Cloudflare MCPを接続するとできること — サーバーは用途別に分かれている

Cloudflareの公式MCPサーバーは1つではなく、用途別に複数提供されている。入口になるのはCloudflare API全体を扱う https://mcp.cloudflare.com/mcp で、DNS・キャッシュ・WAF・Workers・KV・R2など2,500以上のAPIエンドポイントをClaude Codeから操作できる。ほかに専門特化のサーバーが並ぶ。

  • bindings.mcp.cloudflare.com/mcp — Workers開発。KV・R2・D1などバインディングの管理
  • observability.mcp.cloudflare.com/mcp — Workersのログ・メトリクスの分析
  • browser.mcp.cloudflare.com/mcp — ページのレンダリング取得・スクリーンショット
  • radar.mcp.cloudflare.com/mcp — インターネットトラフィックやDNSの統計

障害調査: ダッシュボードを開かずにログを掘る

Observabilityサーバーを繋いでいれば、「昨晩からWorkerのエラーが増えている。原因をログから特定して」という頼み方ができる。AIがログを検索し、エラーの偏り（特定のURL・特定の時間帯）まで整理して返す。ダッシュボードとターミナルを往復して目でログを追う作業がなくなるのが、接続の一番分かりやすい見返りだ。

運用作業: DNSの確認やキャッシュパージを作業の流れの中で頼む

サイト移転時のDNSレコードの確認、デプロイ後のキャッシュパージ、WAFルールの棚卸しといった「ダッシュボードにログインして数クリック」の作業を、コーディング作業の流れを切らずに頼める。ECサイトの前段にCloudflareを挟んでいる構成なら、リリース手順の一部をAIへの指示に置き換えられる。ただし本番のDNSやキャッシュに触れる操作なので、許可設定は読み取り系のツールだけ通すなど絞っておくほうが安全だ。

Workers開発: 実データを見ながら実装する

Bindingsサーバーを繋ぐと、KVに実際に入っている値やR2のオブジェクト、D1のスキーマを確認しながらコードを書かせられる。「このKVの実データに合わせてパース処理を直して」のように、手元にモックを用意せず本物のデータ構造を前提にした実装ができる。

動作確認: レンダリング済みのページを取得させる

Browser Renderingサーバーは、JavaScript実行後のHTMLやスクリーンショットを返す。実装した画面の表示確認や、SPAのようにソースを見ただけでは分からないページの検証をAIに任せられる。

Cloudflare公式MCPサーバーをclaude mcp addで登録する手順

Cloudflare公式のMCPサーバーをClaude Codeに接続する手順自体は特別ではない。他のリモートMCPサーバーと同様、claude mcp addで登録するだけで、コマンドの型はNotionやSentryを追加するときと変わらない。

URLを指定してHTTPトランスポートで追加する（claude mcp add –transport http）

claude mcp add --transport http cloudflare https://mcp.cloudflare.com/mcp

用途別サーバーを使う場合も型は同じで、URLを差し替えるだけだ。なお以前は各サーバーとも/sseエンドポイント（SSEトランスポート)だったが、現在は/mcp（Streamable HTTP）が正式で、/sseは互換用に残っているにすぎない。古い記事の設定例をコピーするときは末尾を確認したい。.mcp.jsonを直接編集する場合、typeフィールドは「http」の代わりに「streamable-http」でも同義になる。MCP仕様のトランスポート名がstreamable-httpのため、Cloudflareの資料のJSONをそのままコピーしても動く。

認証が必要な場合はヘッダー指定かブラウザ認証で対応する

認証方式は二通りだ。APIトークン認証なら、追加時に–header “Authorization: Bearer <トークン>”を渡せば済む。OAuthでブラウザサインインを求めるタイプは、追加直後「！Needs authentication」と表示される。セッション内で/mcpを開き、対象サーバーを選んでAuthenticateを実行するとブラウザが立ち上がり、認証を済ませれば接続済みに変わる。

なおヘッダー指定の認証には、Streamable HTTP接続でカスタムヘッダーが送信されないという不具合報告が過去にある（Issue #48514）。ヘッダーを正しく渡しているのに401が続く場合は、CLIを最新にした上で、可能ならブラウザ認証（OAuth）に切り替えるのが早い。Cloudflare Zero Trust（Access）の背後に自前のMCPサーバーを置く構成を検討している場合も、まずは静的トークンかブラウザ認証で通る構成に寄せておくほうが安全だ。

接続直後に確認すべきステータスと、つながらないときの切り分け方

「Added」表示は接続成功を意味しない。claude mcp add実行後に出る「Added …」は設定ファイルへの書き込みを示すだけで、実際に通信できたかは別問題だ。必ずclaude mcp listで現在のステータスを確認する。

「Needs authentication」「Failed to connect」の違いから原因を絞り込む

「！Needs authentication」はサーバーに到達できているが未認証で拒否されている状態、「✗ Failed to connect」は応答そのものがない状態で、原因の層が異なる。切り分けにはcurl -I <URL>が有効だ。401や403が返れば認証待ちなので前述のヘッダー指定かブラウザ認証で解決し、404や405ならサーバー自体は生きているのでURLのパスを疑う。応答が返らないならネットワークかURLの誤りを疑う。

見落としやすいのは、認証エラーや404をClaude Codeが自動では再試行しない点だ。5xxレスポンスや接続拒否、タイムアウトなどの一時的エラーによる起動時の初期接続なら最大3回まで自動的に再試行する（v2.1.121以降）が、認証待ちや存在しないエンドポイントは設定を直さない限り何度待っても状態は変わらない。再接続を待つより、URLとヘッダーを先に見直すほうが早い。

.mcp.jsonを手書きする場合、urlはあるのにtypeを書き忘れる設定ミスがよく起きる。Claude Code 2.1.202以降なら「MCP server “<name>” has a “url” but no “type”; add “type”: “http” (or “sse” / “ws”) to this entry」という分かりやすいエラーで気づけるが、それより前のバージョンでは「command: expected string, received undefined」としか表示されず、コマンド未指定の問題に見えて原因を見誤りやすい。手元のCLIバージョンを確認してから読むとよい。