ライブラリに戻る
Standards

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

最終更新：2026年7月5日

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

モデルコンテキストプロトコル（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モジュールが独自の認証情報ライフサイクルを実装するのではなく、その複雑さを管理するための標準パターンを提供します。

既存の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週間のディスカバリー。システムインベントリ、ワークフローマップ、固定スコープが手に入ります — 私たちと構築するかどうかにかかわらず。

あなたのシステムのためにこれを構築したいですか？

ここの各ドキュメントは実際の本番作業から来ています。ターゲットシステムとワークフローがあれば、1週間でスコープを定義できます。

スコープ付き構築を依頼

1週間のディスカバリ。システムインベントリ、ワークフローマップ、固定スコープを提供します — 私たちと構築するかどうかにかかわらず。