MCP 2026-07-28仕様が示すAIエージェント基盤の成熟｜ステートレス化と認可設計をどう移行するか

目次

---

1. AIエージェント連携は「試作の配線」から本番インフラへ進む

AIエージェントを業務に入れるとき、最初に便利さを感じるのは外部ツール連携です。社内文書を検索する、CRMの情報を読む、チケットを作る、在庫や契約データを照会する。こうした連携が増えるほど、企業は「モデルの性能」だけではなく、エージェントと業務システムをどう安全に接続し、どうスケールさせ、どう監査するかを問われます。

Model Context Protocol、いわゆるMCPは、この接続部分を標準化するための重要なプロトコルです。MCP公式ブログは2026年7月28日、MCP 2026-07-28仕様を正式に発表しました。AWSも同日、Amazon Bedrock AgentCore Gatewayがこの新仕様をサポートすることを公式ブログで説明しています。

今回の変更は、単なる細かな仕様更新ではありません。MCPが、開発者の手元で動く便利な連携規約から、企業のHTTP基盤、APIゲートウェイ、認可、監査、長時間タスクと並べて考えられる本番インフラへ近づいたことを示しています。特にステートレス化、拡張フレームワーク、認可の強化、破壊的変更を抑えるライフサイクル方針は、AIエージェントを業務システムへ接続する企業にとって見逃せない論点です。

2. MCP 2026-07-28で何が変わったのか

MCP公式仕様では、MCPはLLMアプリケーションと外部データソース、ツールを接続するオープンプロトコルと説明されています。これまでもAIアプリケーションが社内ツールを呼び出す共通言語として注目されてきましたが、2026-07-28仕様では本番運用の前提が大きく変わりました。

最も大きい変更は、プロトコルの中心がステートレスな自己完結リクエストになったことです。AWSの公式説明によると、以前のStreamable HTTPでは、クライアントとサーバーが初期化ハンドシェイクを行い、その後のリクエストでセッションIDを持ち回る形でした。この構成では、水平スケールさせるときにスティッキーセッションや共有セッションストアを考える必要がありました。

2026-07-28仕様では、各リクエストがプロトコルバージョン、クライアント情報、クライアント能力を含みます。サーバーの対応機能を知るためのserver/discoverも使えるため、ひとつのツール呼び出しを事前セッションに依存せず処理しやすくなります。AIエージェント連携を、通常のHTTPSエンドポイントに近い運用対象として扱えるようになる点が実務上の大きな意味です。

加えて、Mcp-MethodやMcp-Nameのようなヘッダーによって、リクエストの意図をHTTP層で扱いやすくなります。ロードバランサー、APIゲートウェイ、レート制限、メトリクス収集、トレース基盤が、JSON-RPC本文を深く解釈しなくてもルーティングや計測をしやすくなるためです。

もう一つの重要な変更は、MCP Extensionsの位置づけです。公式仕様では、Tasks、Skills over MCP、MCP Appsなどが拡張として整理されています。Tasksは長時間処理を扱うための拡張で、ポーリング、途中入力、耐久的なハンドルを前提にします。これは、数秒で終わるAPI呼び出しだけでなく、調査、集計、変換、承認待ちを含む業務エージェントを設計するうえで重要です。

3. なぜステートレス化が企業導入で重要なのか

企業のAIエージェントは、PoCでは一台のサーバー、一人の開発者、一つのツールで始まります。しかし本番では、利用部門、権限、データソース、監査要件、トラフィックの波が一気に増えます。セッションを前提にした連携は、小さく始めるには分かりやすい一方で、複数リージョン、複数インスタンス、APIゲートウェイ配下の運用では負担になります。

たとえば、営業部門のエージェントが商談情報を読み、技術部門のエージェントが障害ログを検索し、管理部門のエージェントが申請ワークフローを呼び出すとします。すべての呼び出しが長く続くセッションに紐づいていると、どのサーバーへ戻すか、どこでセッションを保存するか、障害時にどう復旧するかが複雑になります。ステートレスな呼び出しなら、HTTP基盤の一般的な設計に寄せられます。

この変化は、セキュリティにも効きます。リクエストごとにプロトコルバージョンや能力を明示し、意図をヘッダーで示せると、許可、拒否、監査、レート制限の境界を作りやすくなります。AIエージェントのツール呼び出しは、通常のAPI呼び出しよりも文脈が複雑です。だからこそ、ネットワークや認証認可の既存基盤で扱える粒度に落とし込むことが重要になります。

AWSの説明では、AgentCore Gatewayは複数のMCPプロトコルバージョンを同時にサポートでき、2026-07-28の追加はUpdateGatewayによる設定変更として扱えるとされています。既存クライアントがすぐ壊れるわけではなく、クライアントはリクエストごとにバージョンを選択できます。企業にとっては、一斉移行ではなく、クライアント、ゲートウェイ、個別ツールを段階的に評価できる点が現実的です。

4. 移行時に設計すべき4つの論点

第一に、クライアントSDKとホストアプリケーションの対応状況です。AIエージェント本体、チャットUI、IDE、社内ポータル、ワークフロー基盤がどのMCPバージョンを話せるかを棚卸しする必要があります。AWSの説明でも、2026-07-28対応はクライアントがそのバージョンを要求したときに有効になるとされています。ゲートウェイだけを先に対応させても、クライアント側が古い前提のままなら新しい動作は使えません。

第二に、セッションにアプリケーション状態を載せていないかです。以前の設計で、買い物かご、調査ジョブ、ユーザー選択、ワークフローの途中状態をMCPセッションに暗黙的に依存させていた場合、ステートレス化で見直しが必要になります。状態が必要な業務は、明示的なジョブID、申請ID、会話ID、タスクハンドルとして管理し、ツール引数や自社アプリケーションの永続化層に持たせるほうが安定します。

第三に、認可と人間承認の設計です。MCP公式仕様は、外部データアクセスやコード実行につながる強い能力を扱うため、実装者がセキュリティと信頼性を慎重に設計すべきだとしています。企業では、ツール一覧を出せることと、ツールを実行できることを分ける必要があります。読み取り、作成、更新、削除、外部送信、権限変更のように操作を分類し、重要操作は人間承認や追加認証を挟むべきです。

第四に、観測性とエラー処理です。AWSの説明では、2026-07-28ではトランスポート層とアプリケーション層のエラーが整理され、未知メソッドや未対応バージョンなどがHTTPステータスとして扱いやすくなります。運用チームは、AIエージェントの失敗を「モデルが失敗した」と一括りにせず、認可エラー、入力不備、未対応バージョン、ツール内部エラー、タイムアウトに分けて監視する必要があります。

5. 導入時に見落としやすい注意点

注意すべきなのは、「ステートレスになったから状態を持たなくてよい」と考えないことです。ステートレス化は、プロトコルのセッション管理を軽くするための変更であって、業務上の状態が消えるわけではありません。長時間の調査、承認待ち、外部システムの処理、ユーザーの選択履歴は、引き続きアプリケーション側で責任を持って管理する必要があります。

また、拡張機能を一度に入れすぎるのも危険です。Tasks、MCP Apps、Skills over MCPは魅力的ですが、すべてを同時に本番投入すると、障害時にどこが原因か切り分けにくくなります。まずはツール呼び出しの基本経路を新仕様に対応させ、次に長時間タスク、最後に対話的な承認やUI連携を広げるほうが、運用チームにも利用部門にも受け入れやすくなります。

認可では、OAuthやOpenID Connectに寄せたから安全になる、という短絡も避けるべきです。標準的な認可基盤を使えることは前進ですが、どのスコープを誰に与えるか、AIエージェントがユーザー代理で何をしてよいか、監査ログに何を残すかは企業ごとの設計問題です。特に、社内文書、顧客情報、コードリポジトリ、管理者APIへ接続するMCPサーバーは、普通の業務API以上に厳しく扱う必要があります。

最後に、破壊的変更への向き合い方です。MCP 2026-07-28は大きな更新ですが、AWSの説明では、今回のような破壊的変更が今後の通常運用になるわけではなく、ライフサイクル方針や拡張フレームワークによって将来の変更を管理しやすくする狙いが示されています。企業は、仕様の成熟を歓迎しつつも、MCPサーバーを作ったら終わりではなく、バージョン管理、互換性テスト、廃止予定機能の棚卸しを継続運用に含めるべきです。

6. まとめ

MCP 2026-07-28仕様は、AIエージェント連携を本番インフラとして扱うための重要な節目です。ステートレスな自己完結リクエスト、HTTP層で扱いやすいヘッダー、拡張フレームワーク、長時間タスク、認可強化、エラー処理の整理は、企業がAIエージェントを安全に広げるための土台になります。

導入企業が今見るべきなのは、新機能の多さではありません。自社のMCPクライアントがどのバージョンに対応しているか、既存のツール連携がセッションに依存していないか、認可と監査の境界が明確か、移行を段階的に戻せるか。ここを確認することで、AIエージェントは便利な試作から、業務システムと並ぶ運用対象へ進めます。

OpenBridgeでは、AIエージェント、MCP、RAG、社内システム連携、権限管理、監査ログを含むAIシステム開発を支援しています。MCPを本番導入する際は、サーバー実装だけでなく、ゲートウェイ、認可、状態管理、監視、移行計画まで含めて設計することが、長く使えるエージェント基盤への第一歩になります。