GKEリモートMCPサーバーをClaudeにつないでクラスタを調べる手順

Google Kubernetes Engine(GKE)には、Google Cloudが運営するリモートMCPサーバーがあります。エンドポイントはhttps://container.googleapis.com/mcpで、GKE APIを有効にすると使えます。ClaudeからはカスタムコネクタかClaude Codeで接続し、クラスタやノードプールの状態、Podのログ、リソースのYAMLを自然文で調べられます。

つまずきやすい点は3つあります。APIキーでは認証できないこと、エンドポイントが権限別に3種類あること、案内ページ同士で「読み取り専用」の説明が食い違っていることです。この記事は、この3点を軸に接続手順を組んでいます。

GKEのリモートMCPサーバーとは — 3つのエンドポイントに分かれる

リモートMCPサーバーは、サービス側のインフラで動き、HTTPのエンドポイントとして公開されるサーバーです。手元でプロセスを起動する必要はありません。GKEの場合はGoogle Cloudが管理していて、Google CloudのMCPサーバーに共通する特徴として、中央での検出、きめ細かい認可、Model Armorによる任意の検査、監査ログの一元化があります。

GKEのサーバーは、ツールを3つの束(toolset)に分けて、束ごとにURLを用意しています。

読み取り専用の15個は、list_clusters、get_cluster、list_node_pools、get_node_pool、list_operations、get_operationのようなGKE API系と、get_k8s_resource、describe_k8s_resource、get_k8s_logs、list_k8s_events、get_k8s_rollout_statusなどKubernetesのリソースを見る系です。/mcpには、これに加えてcreate_cluster、update_node_pool、apply_k8s_manifest、patch_k8s_resource、delete_k8s_resourceといった変更系が入っています。

エージェントに渡すツールが少ないほど、ツール選びの精度が上がるという説明も添えられています。調べるだけなら/mcp/read-onlyの一択に近い構成です。

ローカルのGKE MCPサーバーとの使い分け

GKEにはリモート型のほかに、GitHubで公開されているローカル型のMCPサーバーもあります。ローカル型を使う理由として、案内ページは次を挙げています。

• ローカルでの開発とテスト
• オフラインでのMCP利用
• クラスタやワークロードの作成(AI/MLワークロード向けのマニフェスト生成を含む)
• kubeconfigを使ったローカルのクライアント設定
• ログのクエリ
• GKE環境へのコストとセキュリティの推奨事項の取得

リモート型は、IAMで認可でき、監査ログが残り、Model Armorを挟める点が強みです。逆に、クラスタを作る系の作業やコスト推奨を使いたいときはローカル型が候補になります。リモートとローカルの一般的な違いはローカルMCPとリモートMCPの違いで比べています。

GKE専用ではなく、kubeconfigでどのクラスタにもつなげるOSSの実装もあります。そちらはKubernetes MCPサーバーの追加手順で扱っています。GKEのマネージドエンドポイントはGoogleアカウントのIAMで認可する点が、OSS版との大きな違いです。

接続前にGoogle Cloud側で整える3つ

Claude側の操作に入る前に、Google Cloudで次を済ませます。

ロールの付与は、案内ページではロールごとに次のコマンドを1回ずつ実行する形です。

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:USER_IDENTIFIER" \
  --role="roles/container.clusterViewer"

PROJECT_IDとUSER_IDENTIFIERは自分の値に置き換え、--roleをroles/mcp.toolUserに変えてもう一度実行します。

認証の仕様も先に押さえておきます。GKEのリモートMCPサーバーはOAuth 2.0とIAMで認証・認可し、APIキーは受け付けません。エージェント用には自分とは別のIDを作り、アクセスを個別に制御・監視することが推奨されています。Claudeに自分のユーザー認証をそのまま使わせると、操作は自分の名義で行われます。

案内ページの食い違い — 「読み取り専用」はURLで決まる

変更系ツールがあるURLに、読み取りのロールだけで接続したときの結果も、ページには書かれていません。失敗するのか、一部が通るのかを本番で確かめる必要はなく、調べるだけならURLの段階で絞れます。

• 接続先にhttps://container.googleapis.com/mcp/read-onlyを指定する
• 付けるロールはroles/container.clusterViewerまでにする
• OAuthスコープを指定できる場面ではcontainer.read-onlyにする

3つ重ねておけば、どれか1つの前提が違っていても変更系ツールには届きにくくなります。スコープの説明は、container.read-onlyが読み取り専用、containerがGKEリソースの読み書き、cloud-platformがGoogle Cloud全体の読み書きです。スコープ名はhttps://www.googleapis.com/auth/の後ろに付きます。

claude.aiのカスタムコネクタで接続する

Googleの「AIアプリケーションでMCPを設定する」ページには、Claude.ai向けの手順があります。OAuthクライアントIDとシークレットを使う方式です。

Claude側の操作は、サポート記事に沿うとプランで入口が分かれます。

名前とサーバーURLを入れて進むと、Claudeが検出した認証設定の確認画面になります。OAuthクライアントの欄は「Use Claude's published identity」「Register automatically」「Use your own OAuth client」から選ぶ形で、Googleのクライアントを使うなら最後の選択肢です。カスタムコネクタが使えるのは、Free・Pro・Max・Team・Enterpriseの各プランです。Freeは1つまでに制限されています。

Team・Enterpriseで、共有の認証情報を使うコネクタは、使う全員が同じ認証情報の権限でサービスに届きます。GKEのコネクタは個人ごとにOAuthでサインインする形なので、各メンバーはそれぞれのIAMの権限の範囲で動きます。

追加できたら、会話のツールメニューでコネクタを有効にし、最初の質問は参照系から始めます。

Claude Codeで登録する — リダイレクトURIの食い違いに注意

Googleの案内には「Claude Code」の見出しもあります。ただし中身は、リダイレクトURIにhttps://claude.ai/api/mcp/auth_callbackを登録し、「カスタムコネクタを作る手順に従う」というものです。Claude CodeにはCLIから事前登録のOAuthクライアントを渡す仕組みがあり、こちらの値はhttp://localhost:PORT/callbackの形になります。

localhostのURLをGoogleのウェブアプリ用クライアントに登録できるかは、ページに記載がありません。試して拒否されたら、前節のclaude.aiのコネクタを作ります。Claude Codeは、claude.aiアカウントでログインしていれば、そのコネクタを取り込めます。仕組みはClaude CodeのMCPサーバー設定ガイドで確認できます。

試す場合のコマンドは、Claude Codeの事前設定OAuthの書式に、GKEのURLを当てはめた形です。

claude mcp add --transport http \
  --client-id YOUR_CLIENT_ID --client-secret --callback-port 8080 \
  gke https://container.googleapis.com/mcp/read-only

--client-secretはシークレットをマスク入力で聞く指定です。シークレットは追加時にしか設定できず、変更はclaude mcp remove gkeで消して入れ直します。Googleのクライアントにはhttp://localhost:8080/callbackを登録して揃えます。

登録後は、Claude Codeのセッション内で/mcpを開いてgkeを選び、ブラウザでサインインします。シェルからならclaude mcp login gkeでも進められます。claude mcp listの表示が! Needs authenticationのうちは、サインインが済んでいません。

接続後に試す質問と、ツール一覧の確認

GKEの使い方ページに載っている利用例は、次の3つです。いずれも読み取りだけで完結します。

• 「production-clusterの詳細と、すべてのノードプールを見せて」(クラスタとノードプールの状態確認)
• 「defaultネームスペースのfrontend-deploymentのYAMLを取得して」(kubectlを使わないリソース確認)
• 「直近1時間のGKEオペレーションを一覧して」(クラスタのアップグレードなど、長く続く操作の監視)

ページの例はクラスタ名やデプロイ名を置き換えた形です。実際に返ってくる内容は、接続先のプロジェクトとロールで変わります。

どのツールが見えているかは、tools/listで調べられます。このメソッドは認証が要らないため、接続前にcurlで試せます。

curl -X POST https://container.googleapis.com/mcp/read-only \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: tools/list' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}'

使い方ページの例を短くした形で、元の例はparamsにクライアント機能の_metaも入れています。リファレンスページには、ヘッダーが少ない別形式の例(/mcp宛て)も載っています。

ヘッダーが多いのは、MCPのバージョン2026-07-28から、プロトコルが「ステートレス」に変わったためです。initializeのやり取りやMcp-Session-Idが不要になり、各リクエストが必要な情報をヘッダーか_metaに持ちます。

安全策 — IAMポリシーとModel Armor

Google Cloudは、MCPのリスクを管理する設定を任意で用意しています。責任の分担は明確で、サーバー本体とインフラはGoogleが守り、MCPクライアントの認証情報の保護、IAMポリシーの設計、エージェントの行動の監視は利用者側です。

IAMの許可ポリシーと拒否ポリシーでは、次の条件を組み合わせられます。

• 主体
• ツールの読み取り専用属性
• サービス名やツール名
• アプリケーションのOAuthクライアントID

「変更系ツールをこのOAuthクライアント経由では拒否する」といった運用ができます。書き方はGoogle CloudのMCPサーバーをIAMで権限制御するに具体例があります。

Model Armorは、プロンプトとレスポンスを検査するサービスです。プロジェクトのフロア設定でMCPのサニタイズを有効にすると、そのプロジェクトのツール呼び出しにフィルタがかかります。注意点は3つです。

• ロギングを有効にすると、ペイロード全体が記録され、機密情報がログに残りうる
• Model Armorが対応しないリージョンでMCPを使うと、データレジデンシーの要件を満たさなくなる場合がある
• フロア設定はVertex AIなど、Model Armorを使う他のサービスにも効く

MCPの通信が自然言語を運ばないなら、プロンプトインジェクションとジェイルブレイクのフィルタは有効にしない、という注意書きもあります。

つまずきやすい点

• 401や認証エラー: APIキーを渡す設計のクライアントでは通りません。OAuthのクライアントIDとシークレットで認証します
• シークレットが分からない: 作成直後にしかコピーできません。失ったら削除して作り直します
• gcloudだけで済ませたい: Claude Codeからgcloudを直接叩く構成は、gcloud MCPサーバーの追加手順にあります。Google Cloud全般を扱うならこちらも候補です
• ほかのGoogle CloudサービスのMCP: CloudのデータベースであるSpannerの接続はSpanner MCPサーバーへの接続手順で、同じ型のOAuth設定を扱っています。認証の流れそのものはリモートMCPのOAuth認証に整理があります

まとめ

GKEのリモートMCPサーバーは、調べる用途なら/mcp/read-onlyのURLに、clusterViewerのロールを組み合わせる構成が出発点です。変更系のツールが入った/mcpを選ぶのは、書き込みをClaudeに任せる設計が固まってからで足ります。案内ページの記述が揺れている以上、安全側の判断はページの文言ではなく、URL・ロール・スコープという目に見える設定に置くのが確実です。