Google、Apigee（アピジー）hybrid 1.17.0でMCP対応AIエージェント向けツールの処理を自社のKubernetesクラスタ内で動かせる

Googleは2026年10月14日（現地）、API管理基盤Apigee（アピジー）hybridのバージョン1.17.0（9月14日リリース）でMCP（Model Context Protocol）に対応したと、Google Developers Blogで発表した。発表によると、AIエージェントが使うツールの処理（データプレーン）を、利用者自身のKubernetesクラスタ内で動かせる。ブログは、自社データセンターや他社クラウドに実行基盤を置く顧客から「実行基盤を動かさずに使えるか」と問われていたと書き、その答えとして位置づけている。

3行まとめ

1. Apigee hybrid 1.17.0（2026年9月14日リリース）でMCPが使えるようになり、MCPのデータプレーンは利用者のKubernetesクラスタ内で動く（Google発表）。
2. 既定は無効。overrides.yamlにenableMcpServer: trueを足し、apigee-operator、apigee-orgの順にHelmでアップグレードする。既定は2レプリカで、最大10まで自動で増える。
3. 有効化はMessage Processorのカナリアリリースを伴うため、メンテナンス時間帯での実施が求められている。

本記事の内容は、日本時間10月15日2時台に公式ページで確認したものです。

何ができるようになったのか

Googleの説明では、仕組みはApigee（Google管理のSaaS版）で先に出したMCP対応と同じだ。ブログは、この機能を昨年12月にApigeeでプレビュー発表したと書いている（原文は「Last December」）。

流れは次のとおり。

1. APIをOpenAPI 3.0.x仕様で記述する（クイックスタートが挙げる対応版は3.0.0〜3.0.3）。
2. その仕様から「MCP Discovery Proxy」を作る。仕様内の各操作がMCPのツールになる。
3. AIエージェントがJSON-RPCでtools/list（使えるツールの一覧取得）とtools/call（実行）を呼ぶ。プロトコルの処理と変換はApigeeが担う。

ブログは「MCPサーバーのコードを書かず、別のソフトウェアとして運用することもない」と説明している。

hybridで何が変わるのか

変わるのは処理が動く場所だ。ドキュメントの概要ページは、導入形態を2つに分けている。

ブログとドキュメントは、セキュリティ審査で聞かれる点として次の2つを挙げている。

• MCPのリクエスト通信はクラスタ内にとどまる。 ドキュメントは、MCPクライアントが既存のApigee ingressへ入り、Message Processorが同じクラスタ内のMCPデータプレーンへ中継すると説明する。「リクエスト時にGoogle Cloudへ出るMCPのリクエストやレスポンスはない」とある。
• 設定は「取りに行く」方式で、押し込まない。 MCPデータプレーンの隣のサイドカーが、仕様から作られたツール設定を取得する。Googleは、コントロールプレーンがクラスタへ接続を始めることはなく、Googleから利用者のネットワークへの受信経路は要らないと説明している。

誰が、どの条件で使えるのか

ブログは、hybridのMCPはSubscriptionおよびEvaluationの組織で使え、Data Residency（データの所在地指定）を有効にした組織も含むと書いている。

ここで、取得した2つのページの書き方に差がある。ドキュメントの概要ページとクイックスタートは、MCPがSubscription、Pay-as-you-go、Evaluationの組織で使えると書いており、そのうえで「Apigee hybrid 1.17.0以降でもMCPが使える」と続ける。hybridでPay-as-you-goの組織が対象かどうかは、ブログの記述と文面だけでは一致しない。導入前に自分の組織の種別で確認が要る。

認証と認可についても、ブログとドキュメントはこう説明している。

• OAuth 2.0／OpenID Connect、APIキーの検証、Apigeeの標準ポリシーが使える（ブログ）。
• APIプロダクトに、クライアントが呼べるツールを列挙できる。ツールごとのクォータも任意で設定できる。
• tools/listの応答には、そのクライアントのAPIプロダクトに含まれるツールだけが載る。ブログは「見えていないdelete_accountは呼べない」と例示している。

有効にする手順

ブログとドキュメントによると、MCPはhybridの任意機能で、既定では無効だ。すでに1.17.0以降で動いているクラスタに対し、Helmで有効にする。

1. overrides.yamlの最上位にenableMcpServer: trueを足す。ほかの設定は、これだけなら既定値で動く。
2. 組織ごとに1回、apigee-watcherのIDをコントロールプレーンのアクセス設定（watcher_identities）へ追加する。この権限がないと、サイドカーの設定取得が404になり、MCPのデータプレーンが準備完了にならない、とドキュメントにある。
3. apigee-operatorチャートを先に、apigee-orgチャートを後にアップグレードする。順序が逆だと、アップグレードは成功してもMCPのポッドが作られない、とブログは注意している。
4. MCPのポッドがすべて2/2 Runningになっていることと、Message ProcessorのすべてのポッドにhostAliasesの設定が入ったことを確認する。
5. 共通のクイックスタートに従って、最初のMCP Discovery Proxyをデプロイする。

既定値は、MCPのレプリカが2つ、CPU使用率70%で最大10まで自動増加、データプレーンのコンテナにCPU 500m・メモリ512Miの要求と、CPU 2000m・メモリ1Giの上限、とされている。IDは新しいサービスアカウントを作らず、既存のapigee-watcherのものを使う。ブログは「新しいGoogleサービスアカウントも、新しいIAMロールも要らない」と説明する。無効に戻すには同じ項目をfalseにし、apigee-orgチャートを1回アップグレードする。

運用で気をつける点

ドキュメントの「Apigee hybrid-specific limitations」には、導入前に知っておくべき制約が並ぶ。

このうち「呼び出し元の認証」について、ドキュメントは、本番ではMessage Processorのポッド（app=apigee-runtimeのラベル）だけがMCPのService（TCP 443）に届くよう、NetworkPolicyなどのクラスタ側の制御を併用するよう求めている。有効化の手順ページは、それ以外のクラスタ内のワークロードがTCP 443でMCPのServiceに届けば、認証の確認なしにツールを呼べてしまうと書いている。「データプレーンがクラスタ内にある」ことと「呼び出し元が認証されている」ことは別の話で、後者は利用者側の設定に残る。

監視とトレースはどうなるのか

MCPのプロキシは、エージェントがどのツールを呼んでも単一の/mcpエンドポイントで受ける。Apigeeは各リクエストにツール名を付けるため、API insightsでは「API style」と「MCP tool name」のフィルタで、エージェントの通信を通常のREST通信から切り分け、ツール単位で見られる。対象は、API performance、API error analysis、Latency analysis、Target performanceの4つのダッシュボードだ（モニタリングのページ）。

hybridの場合、モニタリングのページには2つの注記がある。

• API insightsのダッシュボードは、Message Processorの通信から計算されるため、SaaS版と同じデータが表示される。クラスタ内のMCPデータプレーン自身のアクセスログは含まれない。ほしければ、MCPのポッドから既存のログ収集の仕組みで集める。
• API insightsは、VPC-SCを使う組織、またはData Residencyを有効にした組織では使えない。

後者は、ブログの「Data Residency対応の組織でも使える」という説明と並べて読むと、MCPは使えても、観測機能の一部は使えない組み合わせがあることになる。

ブログは「次の課題」として、エンドツーエンドのトレースにも触れている。MCPクライアントはW3C Trace Contextを、JSON-RPCの_meta欄に入れて送る。Apigeeはそれを取り出し、通常のtraceparent／tracestateヘッダーとして転送する。分散トレースをOpenTelemetryで有効にしていれば、AIクライアント、Apigee、バックエンドを1つのトレースIDで追える、とブログは書く。ただし、ブログが示したCloud Traceでの一括表示は、連なる全サービス（Apigee以外も含む）が同じCloud Traceに報告するという前提つきだ。MCPコミュニティには、同じ転送を標準化するSEP-2028という提案が出ている。ブログによれば、このOpenTelemetry経由の仕組みはApigeeで今日から使える。

筆者が公式ページで見たこと

日本時間10月15日2時51分ごろ、ブログと4つのドキュメントページを取得して読んだ。4つのドキュメントページはいずれも「Last updated 2026-10-13 UTC」とあり、発表の前日に更新されていた。取得したのは英語版で、ページ上部の言語選択には「日本語」の項目があるが、日本語版の本文までは確認していない。なお、私自身はApigee hybridの環境を持たず、上の手順は公式の記述を整理したもので、実際に有効化して動かしたわけではない。

今回の取得範囲で分からないこと

• 料金。 今回取得した5ページには、hybridでMCPを使うことに対する追加料金の記載は見当たらなかった。料金ページ自体は取得していないので、有料か無料かは言えない。
• 日本での提供。 同じく取得したページには、日本の利用可否や、日本固有の制約の記載は見当たらなかった。なお、概要ページの制限事項には、MCP基盤の容量制約が出うるリージョン（europe-central2など4つ）が挙がっているが、hybrid固有の制限事項の欄とは別の、共通の制限事項に書かれたもので、hybridに当てはまるかは書かれていない。
• 性能の数字。 遅延やスループットなど、MCPデータプレーンの性能を示す数値は、取得した範囲にはない。
• ドキュメントの食い違い。 前述の対象組織の書き方に加え、認証方式の書き方も、ブログは「OAuth 2.0」、ドキュメントの概要は「OAuth 2.1」と、ページによって異なる。
• ドキュメントの注記。 概要ページには、API insightsがMCPのAPIやトラフィックを表示するのは、Apigeeのバージョン1-17-0-apigee-6が全リージョンに展開されてから、という趣旨の注記がある。これがhybridにも当てはまるかは、取得したページからは読み取れなかった。

出典と確認時刻

すべて2026年10月15日2時51分ごろ（日本時間）に取得した。

• Announcing MCP support in Apigee hybrid: agentic tools that run in your own cluster（Google Developers Blog、2026年10月14日）
• Model Context Protocol (MCP) in Apigee overview
• Enable Model Context Protocol (MCP) in Apigee hybrid
• Get started with Apigee and MCP
• Monitor and analyze MCP traffic with Apigee API hub API insights

本記事は続報があり次第更新します。