Googleは、既存のAPIをAIエージェントが発見して呼び出せるツールに変える機能を、Apigeeの自己運用型環境にも提供する。自社データセンターや他のクラウドでAPIを運用するチームは、実行環境を移さずに、エージェントのリクエストを自分たちのクラスター内で処理できるようになった。
1. APIをツールに変える仕組みは維持する
今回の対応は、2026年9月14日にリリースされたApigee hybrid 1.17.0に含まれる。Googleは先に2025年12月、ApigeeのMCP対応をプレビューとして発表した。MCPは、AIエージェントが利用するツールを発見し、呼び出すための通信プロトコルだ。
開発者がOpenAPI 3.0.x仕様でAPIを記述し、MCP Discovery Proxyを作成すると、仕様内の各操作がツールになる。プロキシは、エージェントの呼び出しを既存のAPIリクエストに変換する窓口だ。専用のMCPサーバーコードを書いたり、独立したソフトウェアとして運用したりする必要はない。
エージェントはtools/listでツールを探し、tools/callで呼び出す。Apigeeが通信プロトコルの処理とリクエストの変換を担う点は、従来の方式と同じだ。
2. リクエスト処理と設定配信の経路を分ける
変わったのは実行場所だ。MCPリクエストを実際に処理する部分は、ユーザーのKubernetesクラスター内で動作する。呼び出しの受信、権限確認、バックエンドへの転送が自社インフラ内で行われ、リクエスト処理時にMCPのリクエストとレスポンスがGoogle Cloudに渡ることはない。
一方、ツールの設定は、設定を管理する領域であるGoogle Cloudのコントロールプレーンで作成される。クラスター内の補助プロセスが定期的に取得するため、Googleが内部への接続を開始できるよう受信経路を開く必要はない。リクエストが内部にとどまるという説明を、設定管理まで外部と切り離されるという意味に捉えてはならない。
3. 既存の権限ポリシーと可観測性の仕組みを再利用する
MCPエンドポイントはApigeeプロキシなので、既存の認証とポリシーが適用される。クライアントに許可するツールをAPI productという権限のまとまりに指定し、必要に応じてツールごとの呼び出し上限も設定する。ツール一覧にも、そのクライアントに許可された項目だけを表示する。
デプロイしたツールはAPI hubに自動登録され、検索できる。API insightsでは、エージェントのトラフィックを通常のAPIトラフィックと区別し、ツールごとの性能、エラー、遅延を確認する。リクエストが一つの経路に集まっても、Apigeeがツール名を付けるため、個々のツールの使用量とバックエンドの処理時間を区別して確認できる。
4. 有効化の順序と運用負担を併せて確認する
機能はデフォルトで無効になっており、1.17.0以上のクラスターが必要だ。デプロイツールのHelmで有効化する。
設定ファイルoverrides.yamlの最上位にenableMcpServer: trueを置く。
Helmのデプロイパッケージであるチャートは、apigee-operatorを先に、apigee-orgを後にアップグレードする。順序を逆にすると、アップグレードが成功してもMCPの実行単位が作成されない。
設定を取得するには、既存のapigee-watcherのIDに、組織ごとに一度コントロールプレーンへのアクセス権限を付与する必要がある。新しいGoogleサービスアカウントやIAMロールを作る必要はない。
実行レプリカはデフォルトで2個で、最大10個まで自動スケールする。
利点は、専用のMCPサーバーの運用を減らし、既存のセキュリティポリシーを再利用しながら、リクエストを内部で処理できることだ。その代わり、クラスターはレプリカと補助プロセスを収容する必要がある。有効化と無効化はいずれも実行プロセスを段階的に置き換えるため、原文は承認済みのメンテナンス時間内に作業するよう案内している。
5. 呼び出しのトレースには計装の条件を整える必要がある
分散トレーシングは、複数のサービスを通るリクエストに同じ印を付け、遅延が生じた区間を見つける方法だ。ApigeeはMCPメッセージの_metaからトレース情報を取り出し、通常のHTTPヘッダーで渡す。すでにトレースの計装が施されたバックエンドは、コードを修正せずに同じ流れに参加できる。
以下は、原文の呼び出し例でトレース情報を含む部分だ。
"_meta": {
"traceparent": "00-3ad8012d970b3971cb16cda653a1a370-df3047d1d0830dc0-01"
}原文の例は、ApigeeでOpenTelemetryベースの分散トレーシングを有効にし、呼び出し経路上のサービスが同じGoogle Cloud Traceに報告することを条件としている。したがって、クラスター内で実行するだけで、呼び出し全体のトレースまで自動的に完成するわけではない。
関連する伝達方式の標準化を進めるSEP-2028は、まだ公開提案の段階だ。
今回の対応の価値は、APIの実行場所と既存の統制の仕組みを維持したままエージェントのアクセスを可能にする点にあり、導入の判断にはクラスターのリソースと変更作業の負担も含める必要がある。
