# Model Context Protocol ## 概要 Model Context Protocol(MCP)は、AI エージェントが外部ツール/API を動的に発見・呼び出すための**オープンな仕様**。API への自然言語インターフェースを標準化し、診断コマンドから複雑な緩和操作までをエージェントが統一的に扱えるようにする。([[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]]) [[Google]] の AI-Ops では MCP が本番アクセスの中核に置かれる: - **Production Agent**: MCP を実装するサーバ。オブザーバビリティ(時系列クエリ・ログ検索・自動分析)・インシデント管理・トラフィック制御・インフラ検査の包括的なツールを公開する。本番状態を変える操作は安全システムと [[Actus]] に統合される。 - **Antigravity CLI** が Production Agent + MCP 経由で Gemini に駆動される自然言語インターフェースとして機能する。 - 関連して **A2A(Agent2Agent / Inter-Agent Communication Protocols)** が、専門エージェントをマイクロサービス的に協調させて合成 AI-Ops システムを構成する。 ## 横断比較 - 学術ベンチマーク([[AIOpsLab]]・[[SREGym]])はエージェントにツール群(get_metrics/get_traces 等)を独自 API で与えるが、本ソースは MCP という**オープン標準**でツール接続を標準化する点が産業実装らしい。エージェントの「環境とのインターフェース」を標準化する動きとして注目される。 - **MCP は eBPF/カーネルツールをエージェントに公開する標準としても使われ始めている**: [[@2026__eunomia.dev__eBPF × AI-LLMs - The Convergence of System Observability and AI]] は MCP 経由で [[eBPF]] を操作する例を複数挙げる — Inspektor Gadget MCP Server(K8s デバッグで LLM がテレメトリを自律選択)、ebpf-mcp(シェルエスケープ無しで eBPF プログラムの load/attach/stream を構造化 JSON Schema ツールとして公開)、Ingero(GPU の CUDA/ROCm トレースを MCP で公開)、[[eunomia-bpf]] の MCPtrace。SRE の本番アクセス([[Google]] Production Agent)だけでなく、**カーネル観測・制御**もエージェントのツール面に MCP で載りつつある。 - **Amazon の産業実装は、MCP を「人間とエージェント共通のツールハンドル」として使う点を強調する**: [[@2025__SREcon25EMEA__Modernizing Incident Response with LLMs, RAG, and the MCP]] は、metrics()/logs()/tickets()/deployments()/topology()/runbook()/ownership() という共通 MCP ツール群を、人間セッションの IAM ロールとエージェントランタイムの IAM ロールという異なる権限スコープで同じインターフェースから呼び出す認証設計を示す。Google の Production Agent がエージェント側のツール公開に主眼を置くのに対し、Amazon の実装は「人間も同じコマンドを再現実行できる」ことを MCP 採用の理由として明示する点が異なる。(Source: [[@2025__SREcon25EMEA__Modernizing Incident Response with LLMs, RAG, and the MCP]]) - **MCP はサーバ側のツール公開だけでなく、ゲートウェイ/プロキシ層としても標準化対象になりつつある**: [[agentgateway]] は MCP を通常の HTTP/gRPC API と同一プロキシで前段配置する「MCP Gateway」を提供し、複数 MCP サーバのツールフェデレーション・stdio/HTTP-SSE/Streamable HTTP トランスポート対応・OpenAPI からの MCP ツール自動生成・OAuth 連携の MCP 認証仕様準拠を扱う。Google の Production Agent・Amazon の共通ツールハンドルが「エージェントに何を公開するか」という**サーバ側**の標準化であるのに対し、agentgateway は「複数の MCP サーバをどう集約・仲介・保護するか」という**インフラ層**の標準化であり、MCP エコシステムが Server 実装(サーバ側)と Gateway 実装(インフラ側)の2層で並行に成熟しつつあることを示す。(Source: [[@2026__AgentgatewayDocs__agentgateway Standalone ドキュメント概要]]) - **「ユーザーコンテキストが MCP 仕様に規定されていない」という同一のギャップを、フィールド観測の一次論文が明示的に指摘し、具体的な6段パイプラインとして形式化した**: 本 wiki は agentgateway・Amazon の実装事例から「MCP にはユーザー識別情報を伝播する標準機構がない」ことを断片的に観測してきたが、[[@2026__arXiv__Bridging Protocol and Production - Design Patterns for Deploying AI Agents with Model Context Protocol]] はこれを「MCP 仕様における最大の未解決課題」と明言し、Context-Aware Broker Protocol(CABP)として定式化する。CABP は JWT クレームを個々の JSON-RPC リクエストコンテキストへ注入する 6 段パイプライン(Token Extract→Claim Validate→ACL Resolve→Context Inject→Response Sanitize→Audit Emit)であり、[[agentgateway]] の OAuth 連携 MCP 認証仕様準拠、Amazon の「人間セッションの IAM ロールとエージェントランタイムの IAM ロールを異なる権限スコープで同じインターフェースから呼び出す」設計と同じ問題意識に立つが、**ステートレスな per-request JWT 注入**という具体的機構まで踏み込んで提示する点で一段深い。また CA-MCP(Li ほか、共有メモリストアでのコンテキスト伝播)との対比を明示し、ブローカーパターンには「共有状態型」と「ステートレスな JWT 注入型」という 2 系統がありうることも分かる。(Source: [[@2026__arXiv__Bridging Protocol and Production - Design Patterns for Deploying AI Agents with Model Context Protocol]], [[@2026__AgentgatewayDocs__agentgateway Standalone ドキュメント概要]], [[@2025__SREcon25EMEA__Modernizing Incident Response with LLMs, RAG, and the MCP]]) - **ツール記述の質がエージェントの信頼性を直接左右するという指摘は、MCP のツール発見機構(`tools/list`)の設計上の帰結として一次論文が具体例つきで裏付けた**: 「Phantom Tool」vignette(`get_usage_info` という曖昧な名前・説明のツールをエージェントが一貫してスキップし、記述を4文に拡張しただけでコード変更なしに解決した)は、MCP がツール名・説明のみに基づくランタイム発見を基本設計とすることの直接的帰結であり、`tools/list` レスポンスが「サーバとエージェント間の事実上の API 契約」であるという主張を補強する。(Source: [[@2026__arXiv__Bridging Protocol and Production - Design Patterns for Deploying AI Agents with Model Context Protocol]]) - **MCPのステートフルなセッション管理は、ゲートウェイ実装ごとに異なる状態配置戦略を生む**: [[Envoy AI Gateway]] は、セッションIDを複数呼び出しで再利用し複数アップストリームMCPサーバとの独立セッションを保持するというMCPの根本的なステートフル性に対し、Redis等の集約ステートストアではなく**アップストリームセッション情報をクライアントセッションIDへ自己完結的にエンコードする**設計(トークンエンコーディング)を採用した。これはゲートウェイレプリカ自体をステートレスに保つことで水平スケーリングと運用を簡素化するトレードオフであり、コストは鍵導出関数(KDF)によるセッション暗号化オーバーヘッド(調整可能、デフォルトで数十ミリ秒)である。agentgateway の MCP Gateway 機能(ツールフェデレーション・トランスポート対応が中心)がセッション状態配置の設計理由まで明示していないのに対し、Envoy AI Gateway は「集約化ステート管理(Redis)」を代替案として明示的に検討・却下した理由(単一障害点リスク・運用複雑化)まで公開しており、MCP ゲートウェイのステート配置には「エンコードして無ステート化」対「集約ストアで一元管理」という具体的な設計軸が存在することを示す。(Source: [[@2025__EnvoyAIGatewayBlog__MCP in Envoy AI Gateway]]) ## 関連 - ソース: [[@2026__Uber__Running a Software Factory Efficiently at Uber Scale]] / [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]] / [[@2025__SREcon25EMEA__Modernizing Incident Response with LLMs, RAG, and the MCP]] / [[@2026__AgentgatewayDocs__agentgateway Standalone ドキュメント概要]] / [[@2026__arXiv__Bridging Protocol and Production - Design Patterns for Deploying AI Agents with Model Context Protocol]] / [[@2025__EnvoyAIGatewayBlog__MCP in Envoy AI Gateway]] - 概念: [[agentic SRE]] / [[AIOps]] / [[AIゲートウェイ]] / [[エージェント運用安全性]] - エンティティ: [[Google]] / [[Actus]] / [[eunomia-bpf]] / [[GPTtrace]] / [[Amazon]] / [[Theofilos Papapanagiotou]] / [[agentgateway]] / [[Envoy AI Gateway]] - 関連 MOC: [[LLM4SRE - MOC]] ## 出典 - [[@2026__Uber__Running a Software Factory Efficiently at Uber Scale]](1,000超のMCPサーバーをゲートウェイで統合し、CLI・ツール検索・コードモードでスキーマとターンを削減) - [[@2026__GoogleSRE__AI in SRE - Engineering the Future of Reliable Operations]](Enabling Technologies for AI-Ops) - [[@2025__SREcon25EMEA__Modernizing Incident Response with LLMs, RAG, and the MCP]](人間/エージェント共通ハンドルと IAM ロール分離による認証設計) - [[@2026__AgentgatewayDocs__agentgateway Standalone ドキュメント概要]](MCP Gateway 機能) - [[@2026__arXiv__Bridging Protocol and Production - Design Patterns for Deploying AI Agents with Model Context Protocol]](Context-Aware Broker Protocol・ツール契約設計・本番運用の失敗事例) - [[@2025__EnvoyAIGatewayBlog__MCP in Envoy AI Gateway]](トークンエンコーディングによるステートフルセッションのゲートウェイ設計)