社内でLLM（大規模言語モデル）エージェントに外部ツールを接続する仕組みとして、MCP（Model Context Protocol、モデルとツールを繋ぐ標準プロトコル）の採用を検討している、あるいは既に一部システムで使っているという情報システム部門の方に向けた内容です。2026年7月28日に公開された新しいMCP仕様（通称「Stateless MCP」）は、プロトコル発足以来もっとも大きな変更とされています。ベンダー選定や既存システムとの統合を担当する立場から、何が変わり何を確認すべきかを整理します。
MCPは2024年11月にAnthropic社が発表した規格です。LLMエージェントに検索やDB操作などの「ツール」を呼び出させるための、共通インターフェースを定義しています。2025年にかけて注目を集めた一方で、エージェントに端末操作やcurl（HTTP通信コマンド）を直接与える「Skills」という別方式が台頭し、MCPの相対的な存在感は一時弱まっていました。
何が変わったのか：セッション管理の廃止
今回の変更点は一言でいうと「ステートレス化」です。ステートレスとは、サーバー側がクライアントごとの状態（セッション）を保持しない設計を指します。
従来のMCP（本記事では便宜上「レガシーMCP」と呼びます）は、ツールを呼び出す前に必ず初期化リクエストを送り、Mcp-Session-IdというセッションIDを受け取る必要がありました。そのあとで、そのIDを添えて改めてツール呼び出しのリクエストを送る、という2段階の通信が必須でした。
新しい2026-07-28仕様では、この初期化ステップが不要になります。MCP-Protocol-VersionやMcp-MethodといったHTTPヘッダーに必要な情報を載せ、1回のリクエストでツール呼び出しが完結する設計に変わりました。実装がシンプルになるだけでなく、サーバー側がセッションIDと紐づく状態を保持し続ける必要もなくなります。
なぜこれが技術選定の観点で重要なのか
ガバナンスやベンダー管理の視点で見ると、この変更は3つの論点に直結します。
1つ目はスケーラビリティとインフラコストです。レガシーMCPでは、同じセッションIDのリクエストを同じバックエンドサーバーにルーティングする「セッションアフィニティ」の仕組みが必要でした。これはロードバランサーの設定を複雑にし、水平スケール（サーバー台数を増やして負荷分散する方式）を難しくする要因になっていました。ステートレス化により、この制約がなくなるため、コンテナ基盤やサーバーレス環境での運用コストを下げられる可能性があります。
2つ目は監査・統制のしやすさです。エージェントに端末アクセスとインターネット接続を丸ごと許可するSkills方式は柔軟な反面、何を実行するか事前に把握しづらいというリスクがあります。MCPはツールの入出力がJSONスキーマ（データ構造を定義する仕様）で明示されるため、どのツールに何を渡せるかを事前に監査しやすい設計です。ステートレス化でリクエストの構造自体も単純になった分、ログ監視やアクセス制御の実装コストも下がると見込まれます。
3つ目は小規模モデルでの運用可否です。端末操作を伴うSkills方式は、比較的高性能なモデルでないと安定して制御しきれません。一方でMCPのツール呼び出しは構造化されているため、ノートPC上で動く程度の小さいモデルでも扱いやすいとされています。エッジ環境やコスト制約のあるプロジェクトでは、この差が採用判断を左右する材料になります。
既存システムとの統合で確認すべきポイント
自社でMCPサーバーを構築済み、またはベンダー提供のMCP対応ツールを導入している場合、まず確認すべきはプロトコルバージョンです。
サーバー実装がprotocolVersionとして2025-11-25のような旧バージョンを返している場合はレガシーMCPのままです。2026-07-28に対応しているかは、サーバーのドキュメントか初期化レスポンスのprotocolVersionフィールドで確認できます。
クライアント側の実装がSDK（開発キット）任せになっている場合、SDKのバージョンアップだけで新仕様に追随できるかはベンダーへの確認が必要です。特に自社でMCPサーバーをスクラッチ実装している場合は、初期化エンドポイントを廃止し、ヘッダーベースの単一リクエスト方式へ書き換える改修コストが発生します。
実際に動作確認をしたい場合、Pythonのuvxコマンド（インストール不要でツールを一時実行する仕組み）経由で使えるmcp-explorerという検証ツールが公開されています。
uvx mcp-explorer list https://agentic-mermaid.dev/mcpこのコマンドは、指定したMCPサーバーが公開しているツール一覧を返します。個々のツールの入出力仕様を見たい場合はinspectサブコマンド、実際に呼び出したい場合はcallサブコマンドを使います。導入検討中のベンダー製MCPサーバーに対して、実際にどんなツールが公開されているかを事前に棚卸しする用途に使えます。
移行時のリスクと段取り
後方互換性についても確認が必要です。新旧クライアント・サーバーが混在する期間、レガシーMCPしか話せないクライアントが新仕様サーバーに接続できるか、逆のパターンも成立するかは、実装ごとに差が出ます。ベンダー提供のツールを使っている場合は、移行スケジュールと後方互換の範囲をベンダーに問い合わせるのが確実です。
社内で複数チームがMCPサーバーを個別に立てている組織では、プロトコルバージョンの分散が起きやすくなります。棚卸しの際は、サーバー一覧とそれぞれのバージョン、利用しているクライアントSDKのバージョンを一覧化しておくと、後の移行計画が立てやすくなります。
まとめ
MCPの2026-07-28仕様は、セッション管理を廃止し1リクエストでツール呼び出しが完結する設計に変わった、プロトコル発足以来最大の改定です。
- 自社・ベンダーのMCPサーバーが返す
protocolVersionを確認し、旧バージョンのままかを把握する uvx mcp-explorer list <URL>で実際に稼働中のMCPサーバーのツール構成を棚卸しする- セッションアフィニティ廃止によるインフラ運用コストの変化を、既存のロードバランサー設定と照らして見積もる
- ベンダー導入ツールについては後方互換の範囲と移行スケジュールを問い合わせる
まずは社内外のMCP実装のバージョンを洗い出すところから始めると、移行判断の土台ができます。