MCP 2026-07-28：ステートレスプロトコルがB2Bエージェント展開にもたらす意味

なぜこのリリースが展開の計算を変えるのか

モデルコンテキストプロトコル（MCP）は、AIエージェントを外部システムに接続するためのオープン標準です。2026年7月28日、ローンチ以来最大の改訂が出荷されます — プロトコル層をステートレスにし、ファーストクラスの拡張機能を導入し、本番環境で複雑さに見合う価値を生まなかった3つの機能を非推奨とする最終仕様です。

B2Bエージェントシステムの背後にMCPサーバーを展開するチームにとって、実際的な影響は具体的です：スティッキーセッション、共有セッションストア、セッション対応のロードバランサーはもはや不要になります。エージェントが複数のツール呼び出しをまたいで必要とする状態は、明示的なハンドルになります — モデルから見え、ログで監査可能で、中間層でキャッシュ可能です。この記事では、B2B展開にとって重要な変更点と、それらが私たちが既に出荷しているMCPモジュールパターンにどう対応するかを説明します。

ステートレスなプロトコル層

見出しとなる変更：initialize / initialized ハンドシェイクと Mcp-Session-Id ヘッダーが削除されます。リクエストは自己完結型になります。プロトコルバージョン、クライアント情報、ケーパビリティは、サーバーが記憶しなければならないネゴシエートされたセッションではなく、すべてのリクエストの _meta に載って移動します。

これがB2B展開で不要にするもの：

• スティッキーセッションのロードバランサー。 リモートMCPサーバーは、単純なラウンドロビンのロードバランサーの背後に配置できます。リクエストを解釈するためにサーバー側の状態が不要なため、どのサーバーインスタンスもどのリクエストも処理できます。
• 共有セッションストア。 今日水平スケールする場合、すべてのMCPサーバーインスタンスが同じセッション状態 — 通常はRedisやデータベース — にアクセスする必要があります。ステートレスプロトコルはその依存関係を取り除きます。
• セッションリプレイのインフラ。 ワークフローの途中でセッションが切れると、クライアントは再初期化してコンテキストを再確立しなければなりません。ステートレスプロトコルには切れるセッションがありません。すべてのリクエストが必要なものを携えています。

展開の形はよりシンプルになります：ロードバランサーの背後にステートレスなMCPサーバーインスタンスのプールがあり、それらの間に共有状態層がありません。これはあらゆるステートレスなHTTP APIと同じ形です — 実戦で鍛えられ、観測可能で、スケールが安価です。

ステートフルなワークフローのための明示的ハンドルパターン

ステートレスは状態が消えることを意味しません。複数のツール呼び出しにまたがるワークフロー — RFQの受付、見積もり交渉、在庫確保 — には依然として継続性が必要です。最終仕様は、隠れたセッション状態を 明示的ハンドルパターン に置き換えます：ツールがハンドル（order_id、quote_id、basket_id）を発行し、モデルは後続の呼び出しで通常の引数としてそれを渡し戻します。

これは3つの理由でB2B展開にとって意味のある転換です。

状態がモデルから見えます。 今日、セッション状態はLLMが決して見ることのないトランスポートのメタデータに存在します。明示的ハンドルでは、モデルはその推論の中でハンドルを保持し参照します。モデルが get_quote(quote_id="q-7f3a") を呼び出すとき、どの見積もりを操作しているかを把握しています。これにより、マルチステップのワークフローでのツール選択の精度が向上します。

状態がログで監査可能です。 すべてのリクエストは、アプリケーションロガーが取り除くヘッダーではなく、リクエストボディにハンドルを携えています。監査証跡は、リクエスト引数を読むことでワークフロー状態の全体を任意の時点で再構築できます — セッションストアのログとの突き合わせは不要です。

状態が中間層でキャッシュ可能です。 ハンドルがリクエストの一部であるため、ゲートウェイやキャッシュ層がそれをキーにできます。リストおよびリソースの結果は ttlMs と cacheScope フィールドを携えるため、安定したハンドルを持つカタログクエリは、アップストリームシステムにアクセスすることなくキャッシュから提供できます。

これがRFQワークフローにどう対応するか

5つのツール呼び出しにまたがって実行される見積もりワークフローを考えてみましょう：リクエスト作成、カタログ検索、見積もり生成、在庫確保、価格ティア適用。セッションベースのプロトコルでは、これら5つの呼び出しはサーバー側のセッションを共有します。明示的ハンドルパターンでは：

1. create_request(buyer_id, line_items) → request_id="r-1042"
2. search_catalog(request_id="r-1042", query="industrial pump 220V")
3. generate_quote(request_id="r-1042", supplier_ids=["s-12", "s-19"])
       → quote_id="q-7f3a"
4. hold_availability(quote_id="q-7f3a", hold_duration="48h")
       → hold_id="h-3391"
5. apply_pricing_tier(quote_id="q-7f3a", tier="volume-3")

すべての呼び出しが必要とするハンドルを携えています。呼び出しの間にサーバーが何かを記憶することはありません。ロードバランサーが呼び出し4を呼び出し3とは別のインスタンスにルーティングしても、依然として機能します — ハンドルがリクエストの中にあるからです。監査チームが1週間後にこのワークフローを再構築する必要がある場合、リクエスト引数の中のハンドルが全容を物語ります。

拡張機能：ファーストクラスかつ独立してバージョン管理

最終仕様は 拡張機能 をファーストクラスの概念として導入します。拡張機能はリバースDNS識別子（例：com.example.workflow）を取得し、独自の ext-* リポジトリを持ち、委任されたメンテナーを持ち、コアプロトコルとは独立してバージョン管理されます。

最初の2つの拡張機能は具体的です：

• MCP Apps — サンドボックス化されたiframeで配信されるサーバーレンダリングのHTML UI。MCPサーバーはクライアントがレンダリングするUIを出荷でき、クライアントがカスタムフロントエンドを構築することなく、human-in-the-loopの承認画面を可能にします。
• Tasks — タスクハンドルを持つ長時間実行の作業。ツールは接続を数分間開いたまま保持するのではなく、タスクハンドルを即座に返し、クライアントが完了をポーリングできます。

B2B展開において、MCP Appsは、エージェントが処理を進める前に人間がトランザクションを承認しなければならない場面 — しきい値を超える発注書、非標準の割引付き見積もり — で重要になります。承認画面は、別個のフロントエンドを必要とせずにMCPモジュールと共に出荷できます。Tasksは、単一のリクエストタイムアウトを超えるワークフロー — 生成に90秒かかるサプライヤー見積もり、数分間実行されるカタログ同期 — にとって重要です。

非推奨：Roots、Sampling、Logging

3つの機能が非推奨となります（12か月間はアノテーションのみ。削除には別個の標準化プロセスが必要）：

• Roots → ツールパラメータとリソースURIに置き換え。Rootsはクライアントがサーバーにファイルシステムの場所を伝える方法でした。同じ意図は今や、ファイルを読むツールへの引数として表現されます。
• Sampling → LLMプロバイダーAPIとの直接統合に置き換え。LLM呼び出しが必要なサーバーは、クライアントにサンプリングのラウンドトリップを実行するよう要求するのではなく、プロバイダーに直接呼び出しを行います。
• Logging → stderrとOpenTelemetryに置き換え。サーバーのロギングは、MCPのロギングチャネルではなく、標準のプロセス出力と分散トレーシングに移行します。

Loggingの非推奨は、B2B展開にとって最も関連性があります。監査ログのパターン — すべてのツール呼び出しがリクエスト、レスポンス、レイテンシ、結果をログに記録する — は、プロトコル固有のロギングチャネルではなく、OpenTelemetryと整合するようになります。これは、MCPサーバーのログがカスタムトランスポートなしで既存のオブザーバビリティパイプライン（Datadog、CloudWatch、Honeycomb）と統合されることを意味します。

ルーティング可能、キャッシュ可能、トレース可能

本番運用に影響する3つの追加：

• Mcp-Method および Mcp-Name ヘッダー は、ボディの検査なしにゲートウェイのルーティングを可能にします。ゲートウェイはメソッドとツール名でヘッダーレベルでルーティングできます — ルーティング層でのJSONパースは不要です。
• リスト/リソース結果の ttlMs と cacheScope は、中間層に標準的なキャッシュ契約を与えます。カタログのリストレスポンスは5分間のTTLを宣言でき、パス上のどのゲートウェイもそれを尊重できます。
• W3C Trace Context の伝播 は、OpenTelemetry互換性のために文書化されています。エージェントクライアントが開始したトレースは、MCPサーバーを通り抜けてアップストリームシステムの呼び出しへと伝播するため、単一のRFQワークフローが、それが触れるすべてのシステムを横断する1つのトレースとして現れます。

NetSuite、HubSpot、サプライヤーカタログのためにMCPサーバーを実行するB2B展開において、これは次のことを意味します：ゲートウェイはボディをパースせずにツール名でルーティングでき、宣言されたTTLの間カタログレスポンスをキャッシュでき、単一の見積もりリクエストをエージェントからERP、サプライヤーAPIまで1つのスパンツリーでトレースできます。

1対多の形のための認可の強化

最終仕様は、B2Bエージェントシステムが実際に使用する展開の形 — 1つのクライアント（エージェント）が多数のサーバー（NetSuite、HubSpot、BigCommerce、サプライヤーカタログ）に接続する — のために、OAuthとOpenID Connectを改善します。トークンの更新、スコープ管理、複数サーバーの認証情報処理は、各統合が独立して解決するに任せるのではなく、仕様の中で対処されます。

これが重要なのは、B2Bエージェントシステムが1つのシステムに接続するのではないからです。典型的なRFQエージェントは、ERP（NetSuite）、CRM（HubSpot）、eコマースプラットフォーム（BigCommerce）、そして2〜3のサプライヤーカタログに接続します — それぞれが独自のOAuthフロー、トークン有効期間、スコープセットを持ちます。プロトコルは今や、各MCPモジュールが独自の認証情報ライフサイクルを実装するのではなく、その複雑さを管理するための標準パターンを提供します。

Update — 2026-08-06: Terraform MCP CVE-2026-16496 (CVSS 10.0) — the stateless thesis validated in production

HashiCorp patched CVE-2026-16496 (CVSS 10.0) in Terraform MCP Server before version 1.1.0 — the first maximum-severity CVE in the MCP ecosystem. The vulnerability is an authorization bypass in the streamable-HTTP stateful transport mode: a user who obtains another user's MCP session ID can have their tool calls executed using that user's Terraform credentials. HashiCorp also patched CVE-2026-16498 (tenant isolation break) and CVE-2026-14869 (SSRF) in the same release. (The Hacker News, SentinelOne vulnerability database)

This CVE is the first production evidence that the stateful transport mode is a security liability, not just an operational complexity — and it validates the core thesis of this article. The stateless protocol layer the July 28 final specification introduced exists precisely to eliminate the server-side session state that this attack exploits. The attack vector (session-ID theft leading to credential reuse) exists only because the server holds a session state that an attacker can steal and reuse. A stateless server has no session to steal. The explicit-handle pattern this article describes — where stateful workflows mint handles that travel in the request body, not in a server-side session — is the architecture that closes this vulnerability class. The vulnerability affects only the stateful streamable-HTTP transport mode; the stateless protocol core is not affected.

For B2B deployments, the implication is direct: if your MCP servers run stateful streamable-HTTP with Mcp-Session-Id, they carry the session-hijacking attack surface that CVE-2026-16496 exploits. Migrating to the stateless protocol core (Control 1 in the MCP Security Hardening Checklist) eliminates the attack surface at the architecture level, not the patch level. The 12-month SSE deprecation window is now a security deadline, not just an operational one.

セキュリティ：3つの新しい攻撃面とディフェンスインデプスのデータポイント

ステートレス再設計は、最終仕様の公開当日に backslash.security が分析で特定した3つの新しい攻撃面を導入します：

• ハンドルハイジャック。 明示的ハンドルはサーバー側のセッション状態を置き換えますが、ハンドルは通常の引数です。ハンドル空間が予測可能か、トランスポートに整合性保護がない場合、ハンドルを観察または推測した攻撃者はそれを自分のリクエストに注入でき — ワークフロー所有者を偽装できます。解決策は、ハンドルの暗号論的生成（ランダム、予測不可能）と、リクエスト本文だけでなく認証された呼び出し元へのハンドルのバインディングです。
• ファイルシステムスコープのギャップ。 Rootsの非推奨により、クライアント側のファイルシステム境界宣言が削除されます。ファイルを読み取るツールはパスを引数として受け取りますが、Rootsの境界がないと、ツールはクライアントが意図していないファイルシステムの場所にアクセスする可能性があります。解決策は、もはや存在しないプロトコルレベルの境界への依存ではなく、ツールごとのパス検証です。
• MCP Apps HTMLレンダリング。 MCP Apps拡張機能により、サーバーはサンドボックス化されたiframeでHTML UIを配信できます。サンドボックスはセキュリティ境界ですが、HTMLコンテンツはサーバーから来ます — 侵害されたまたは悪意のあるMCPサーバーは、サンドボックスを脱出したりユーザーにフィッシングを試みるUIを配信できます。解決策は、MCP Apps HTMLを信頼できないコンテンツとして扱うこと：厳格なContent Security Policy、same-originアクセスなし、新しいサーバーからのアプリサーフェスをレンダリングする前のユーザー確認です。

ディフェンスインデプスのデータポイント：Auto Modeを有効にしたClaude Opus 5は、129のテストシナリオで0%のブラウザベースのプロンプトインジェクション攻撃成功率を達成しました — ブラウザエージェントのプロンプトインジェクションをゼロに削減できる最初の具体的データポイントです。Auto Modeは、入力層のプロンプトインジェクションプローブと出力層のアクション分類器を組み合わせます。ブラウザエージェントがMCPツールを呼び出すステートレスMCPデプロイメントでは、入力スキャン + タスクブロックのパターンは、プロトコルのステートレス設計が実施を容易にするディフェンスインデプスの具体的実装です：各リクエストは自己完結型であり、プローブと分類器は各リクエストで独立して動作し、破壊すべきセッション状態がありません。

既存のMCPモジュールにとって何が変わるか

既にMCPモジュールを出荷している場合 — 例えば、ツールが MCP_CONFIGURATION を通じて登録され、ドメインミックスインが共有GraphQLクライアント上に構成される38ツールのRFQプロセッサーパターン — ステートレスプロトコルが変えるのは展開であって、モジュールコードではありません。

モジュールのツール登録、入出力スキーマ、レート制限、監査ログは同じままです。変わるもの：

• 起動時のセッション初期化なし。 モジュールは initialize ハンドシェイクに参加しません。プロトコルバージョンとケーパビリティを携えた _meta と共にリクエストを受け取り、応答します。
• ステートフルなツールはハンドルを発行します。 ツールが今日、マルチステップのワークフローを追跡するためにサーバー側のセッションに依存している場合、明示的なハンドルを発行して返すべきです。クライアントは次の呼び出しでそれを渡し戻します。RFQプロセッサーにとって、request_id、quote_id、hold_id は既にハンドルです — このパターンはドメインにとって自然です。
• ロギングはOpenTelemetryに移行します。 モジュールがMCPのロギングチャネルを通じてログを記録している場合、stderrとOpenTelemetryのスパンに移行します。監査の内容（リクエスト、レスポンス、レイテンシ、結果）は同じままです。トランスポートが変わります。
• キャッシュは宣言的です。 リストおよびリソースのエンドポイントは、レスポンスに ttlMs と cacheScope を宣言でき、中間層が推測することなくキャッシュできます。

B2Bチームにとっての結論

ステートレスプロトコルは、MCPベースのエージェント展開が必要とするインフラを削減します。スティッキーセッションと共有セッションストアを、リクエスト引数の中の明示的ハンドルと引き換えにします — システムをスケールしやすく、監査しやすく、標準ツールでより観測可能にするトレードオフです。

チームがMCPベースのエージェント展開のスコープを定めているなら、7月28日の最終仕様が目標とすべきバージョンです。最初から明示的ハンドルを前提に設計することで、後からのセッションベースの状態からの移行を回避できます。

---

NetSuite、BigCommerce、そして3つのサプライヤーカタログを運用するディストリビューターは、メールやポータルでRFQを受け取り、カタロググラフに対して製品を解決し代替品を提示し、顧客ティアごとに価格を設定し、有効期限付きで在庫を確保し、受諾された見積もりをNetSuiteに書き戻すエージェントを得ます — すべてのステップがログに記録された状態で。そのビルドは4ステップ手法のフェーズ2〜3であり、通常5〜8週間で稼働します。

スコープを定めたビルドをリクエストしてください。 1週間のディスカバリー。システムインベントリ、ワークフローマップ、固定スコープが手に入ります — 私たちと構築するかどうかにかかわらず。