AIエージェントが業務システムに接続する「共通の口」として、MCP（Model Context Protocol）は事実上の標準になりつつあります。そのMCPが、発足以来最大の改訂を迎えようとしています。2026年6月29日には主要言語のベータSDKが公開され、確定仕様は 2026年7月28日 にリリース予定です（MCP公式ブログ）。
homula はエンタープライズ向けの AIエージェント・インテグレーターとして、日本企業の MCP 活用を「PoCから本番・全社へ」日々支援しています。本稿は新仕様の技術解説にとどまらず、「ステートレス化」が企業のスケール戦略と統制設計に何をもたらすか——実務の論点を整理します。便利になる一方で、これまで暗黙に成立していた「文脈を持つ層」が消えるからです。
何が変わるのか——セッションの廃止
新仕様 2026-07-28 の中核は一言でいえば「プロトコル層でのステートレス化」です。従来のMCPは、接続時に initialize / initialized のハンドシェイクを行い、Mcp-Session-Id ヘッダーでセッションを維持していました。この設計が、水平スケールと相性が悪いという問題を抱えていました。
MCPのロードマップは課題をこう指摘しています——「ステートフルなセッションはロードバランサーと衝突し、水平スケールには回避策が必要になる」。実際、あるインスタンスが initialize を処理してセッションIDを発行したのに、後続の長寿命ストリームが別インスタンスに振り分けられ、そのインスタンスはセッションを知らず 404 を返す——ネットワーク障害に見えて実は設計起因、という不具合が現場を悩ませてきました（MCP公式ブログ・RC解説）。
新仕様はこの前提を取り払います。主な変更点は次の通りです。
| 領域 | 従来 | 2026-07-28 |
|---|---|---|
| セッション | initialize ハンドシェイク＋Mcp-Session-Id でセッション維持 | ハンドシェイクとセッションIDを廃止。どのリクエストもどのインスタンスで処理可 |
| メタ情報 | 接続時に一度だけ交換 | プロトコルバージョン・クライアント識別・ケイパビリティを _meta オブジェクトで毎リクエスト搬送 |
| ルーティング | ゲートウェイがボディを解析して振り分け | Mcp-Method・Mcp-Name ヘッダーで、本文を読まずにゲートウェイ振り分け |
| サーバー→クライアント | 長寿命のSSEストリームを保持 | InputRequiredResult（inputRequests / requestState）でポーリング型に。任意のインスタンスが継続を処理 |
| キャッシュ | 明示的な指定なし | 一覧応答に ttlMs・cacheScope を付与しクライアント側キャッシュを許容 |
| 可観測性 | 標準化されていない | W3C Trace Context を正式ドキュメント化し OpenTelemetry と連携 |
結果として、これまで「スティッキーセッション＋共有セッションストア（Redis 等）＋ゲートウェイでの深いパケット検査」を必要としたリモートMCPサーバーが、素の round-robin ロードバランサーの背後で動き、水平にスケールできるようになります。
企業にとっての3つのインパクト
数字や実装詳細を割り引いても、この改訂が向かう方向は明確です。エンタープライズの視点では、影響は大きく3つに整理できます。
第一に、スケーラビリティ。セッションIDが消えることで、どのリクエストもどのインスタンスに着地してよくなります。「3台から10台へ増やすとロードバランサーが仕事を分散するだけ」——共有セッションストアという単一障害点とネットワークホップが、プロトコル状態の維持からは不要になります（Microsoft・App Serviceでのスケール解説）。本番のMCPサーバーを可用性高く運用したい企業にとって、これは待望の変更です。
第二に、認証・認可の企業対応。新仕様はMCPの認可を OAuth 2.1 / OpenID Connect に整合させ、MCPサーバーを正式に「OAuth 2.1 リソースサーバー」として定義します。複数のOAuth関連提案が、iss パラメータの検証（RFC 9207 に基づく mix-up 攻撃対策）や、動的クライアント登録での OIDC application_type 宣言などを求めます。要点は、単一の企業SSO設定で全MCPサーバーをカバーできるようになること。「独自の認証フローをセキュリティチームが承認できず、MCP展開が止まっていた」企業にとって、これは足かせを外す変更です（WorkOS の解説）。
第三に、機能の昇格と廃止。サーバー側でUIを描画する「MCP Apps」（サンドボックス化した iframe 内でサーバー生成のHTMLを表示）と、長時間タスクを扱う「Tasks」拡張が正式機能へ昇格します。一方で Roots / Sampling / Logging は非推奨となりますが、新しいライフサイクル方針により「非推奨から最短の削除までに最低12か月」を置くため、当面は既存サーバーが壊れることはありません。
見落とされがちな死角——「文脈を持つ層」が消える
ステートレス化は運用を軽くしますが、統制の観点では逆に難易度を上げる側面があります。ここが日本企業がいま最も注意すべき点です。
セッションが無くなると、「複数のリクエストにまたがる文脈」を自然に保持する上流コンポーネントが存在しなくなります。リクエストが複数のサーバーレプリカに分散するため、あるツール呼び出しの並びが不審に変化していく（ツールドリフト）ことに、どのレイヤーも気づけない——という指摘があります。同意・監査・レート制御といった「横断的な文脈」を、誰かが明示的に担う設計が必要になります。
これまでは、セッションという入れ物が暗黙に「1つの会話・1つの権限文脈」を束ねていました。ステートレスな世界では、その束ね役を**プロトコルの外側にある統制レイヤー（ゲートウェイ／制御プレーン）**が引き受けなければなりません。Mcp-Method / Mcp-Name ヘッダーや _meta は、その統制レイヤーがボディを解析せずに「誰が・どのツールを・どういう文脈で呼んだか」を判断するための材料でもあります。つまり新仕様は、統制を専用の層へ切り出すことを前提とした設計になっているのです。
これは、以前の記事で触れたMCPの「同意画面」が企業管理の認可（EMA）へ移る流れや、ツール単位で承認ゲートを設ける制御点の議論と地続きです。ステートレス化は、その「専用の制御プレーンを持つべき」という主張をプロトコル側から裏づけたと読めます。
homulaの観点——スケールと統制を同時に設計する
新仕様は「スケールしやすさ」と「統制の外部化」という2つの含意を同時に持ちます。homula が日本企業の本番導入で重視するのは、この両輪を最初から一緒に設計することです。
Agens は、MCPを活用して200以上のツールと構築ゼロで接続するエンタープライズ向け統合プラットフォームです。個々のMCPサーバーの実装差や仕様改訂を吸収し、企業が「どのツールに、どのエージェントが、どんな条件で触れるか」を一貫した口で扱えるようにします。ステートレス化で接続がスケールしやすくなるほど、この「接続の共通化」の価値は増します。
そして、消えた「文脈を持つ層」を引き受けるのが Agens Control です。承認フロー・DLP・5年分の監査ログ・RBAC を備え、リクエストが複数レプリカに分散しても「誰が起点で、どのツールを、どの権限で呼んだか」を横断的に記録・制御します。ステートレスな世界で最も失われやすい「横断的な文脈と証跡」を、プロトコルの外側で明示的に担保する——これが実務の勝ち筋です。
導入の順序としては、(1) 1業務でPoC（最短5日）→ (2) 価値が出る接続を Agens で共通化し、承認・監査の境界を Agens Control で設計 → (3) 新仕様のベータSDK（Python 2.0.0b1、TypeScript v2 ベータ、Go v1.7.0-pre.1、C# 2.0.0-preview.1）をテスト環境で検証しつつ横展開、が無理のない道筋です。AIエージェント・ブートキャンプ では、業務棚卸しとあわせて「どのMCP接続を、どの統制境界で本番化するか」を3〜5日で設計します。
まとめ
MCP 2026-07-28 仕様が示すのは、エージェント接続が「動けばよい」段階から「スケールしても統制が効く」段階へ移りつつある、という方向性です。セッションの廃止は水平スケールと企業SSOへの道を開く一方で、同意・監査・レート制御といった横断的な文脈を担う「専用の統制レイヤー」を前提に置きます。
日本企業にとっての実務的な含意は、「新仕様を急いで追う／追わない」ではなく、「接続のスケール化と統制の外部化を、同じ設計図の上で一緒に描く」こと。7月28日の確定は目前です。ベータSDKでの検証と並行して、自社の制御プレーンをどこに置くかを今から言語化しておくことが、本番・全社展開への近道になります。
MCPの改訂は、接続の速さと同じくらい「統制して任せられるか」で差がつきます。自社のどの業務から、どの接続を、どんな承認・監査の境界で本番化するか——その最初の線引きを早めに整理しておきましょう。