AIと外部ツールをつなぐ共通規格「MCP」が過去最大のアップデート、セッション廃止で何が変わったのか? – GIGAZINE

2026年07月29日 12時37分
AI


Linux Foundation傘下のAgentic AI Foundationで開発されている「Model Context Protocol(MCP)」の新仕様「2026-07-28」が、2026年7月28日に公開されました。MCPをセッションに依存しない「ステートレス」な設計へ移行させたほか、長時間処理、ユーザーへの確認、キャッシュ、認証などの仕組みが刷新されており、MCPの登場以来最大規模のアップデートと位置付けられています。

The 2026-07-28 Specification | Model Context Protocol Blog
https://blog.modelcontextprotocol.io/posts/2026-07-28/

MCP 2026-07-28 spec: stateless core, coming to Claude | Claude by Anthropic
https://claude.com/blog/bringing-mcp-2026-07-28-to-claude

GitHub MCP Server supports the next MCP specification – GitHub Changelog
https://github.blog/changelog/2026-07-23-github-mcp-server-supports-the-next-mcp-specification/

MCPは、AIエージェントや大規模言語モデルを利用するアプリと、外部のデータやツール、ウェブサービスなどを接続するためのオープンな共通規格です。Anthropicが2024年11月に公開したもので、AIサービスごとに異なる接続方法を開発するのではなく、MCPに対応することでさまざまなAIから同じツールを利用できるようにすることを目的としています。

既存アプリとAIシステム間でデータを橋渡しするためのユニバーサルプロトコル「Model Context Protocol」をAnthropicが提唱しオープンソースで公開 – GIGAZINE


MCPはその後、多数のAIサービスや開発ツールで採用され、記事作成時点ではAgentic AI Foundationのプロジェクトとして開発されています。今回公開された「2026-07-28」では、実験的なAI連携規格として設計された初期の仕組みを見直し、大規模なサービスでも運用しやすい構成へ改められました。

従来の仕様とMCP 2026-07-28の主な違いをまとめると、以下の通り。

 旧仕様MCP 2026-07-28接続開始

initializeによる初期化が必要

初期化は不要セッション

Mcp-Session-Idを維持

プロトコルレベルのセッションを廃止サーバー

同じサーバーへの振り分けが必要

任意のサーバーで処理可能ユーザーへの確認

接続を維持してサーバーから要求

MRTRで回答を付けて再送長時間処理

接続中の処理として扱う

Tasks拡張で識別子を発行


◆ステートレス化
今回のアップデートにおける最大の変更点は、MCPの通信方式が「ステートフル」から「ステートレス」へ移行したことです。従来のMCPでは、クライアントとサーバーが最初に「initialize」と「initialized」と呼ばれるやり取りを行い、その後は「Mcp-Session-Id」を使って同じ接続状態を維持していました。

しかし、この方式で多数のMCPサーバーを運用する場合、同じユーザーからの通信を同じサーバーに送り続ける「スティッキーセッション」や、複数のサーバー間でセッション情報を共有するデータベースが必要になります。サーバーを増減させたり、障害が発生したサーバーから別のサーバーへ処理を移したりすることが難しく、大規模運用の妨げとなっていました。

新仕様では、initializeによる初期化処理とMcp-Session-Idが廃止され、各リクエストがプロトコルのバージョン、クライアント情報、利用可能な機能などを個別に伝えるようになりました。サーバーが提供する機能を事前に確認したい場合は、新設された「server/discover」を利用できますが、この処理は必須ではありません。

各リクエストが単独で完結するため、通信を同じサーバーへ送り続ける必要はなくなり、一般的なロードバランサーを使って空いているサーバーへ処理を振り分けられます。これにより、MCPサーバーを一般的なHTTPサービスと同じようにKubernetes、サーバーレス環境、エッジ環境などへ展開し、アクセス数に応じて増減させやすくなります。

Before, running a remote MCP server meant managing session state, which limited where you could run it.

Now that MCP is stateless, you can deploy on serverless and edge infrastructure, or scale horizontally behind any load balancer. pic.twitter.com/2Rfs2kdgb8

— ClaudeDevs (@ClaudeDevs) July 28, 2026


◆アプリの状態は識別子として管理
ステートレス化によって、買い物かごの内容やブラウザの操作状況など、アプリが持つ状態そのものを保存できなくなるわけではありません。複数の呼び出しにまたがって情報を維持する必要がある場合、サーバーは状態を示す識別子を発行し、AIエージェントが次のツール呼び出しで明示的に渡します。

従来は通信セッションの内部に隠されていた情報が、ツールの引数として明示的に扱われることになります。これにより、どの状態を使って処理しているのかをAIエージェントや開発者が把握しやすくなり、サーバー側でも特定の接続を維持する必要がなくなります。

◆ユーザーへの確認を複数回行える「MRTR」
ステートレス化に伴い、処理の途中でユーザーから追加情報を受け取るための「Multi Round-Trip Requests(MRTR)」も導入されました。例えば、AIエージェントがデータを削除しようとした際に確認が必要な場合、サーバーは「input_required」という結果と質問内容を返します。

クライアントはユーザーから回答を受け取り、その情報を追加して元のリクエストを再送します。サーバー側から接続中のクライアントへ質問を送り返す必要がなくなり、ユーザーへの確認や不足項目の入力をステートレスな通信で処理できます。


◆HTTPヘッダーとキャッシュも刷新
通信の振り分けや監視を容易にするため、HTTPヘッダーには呼び出す機能を示す「Mcp-Method」と、ツール名などを示す「Mcp-Name」を含めることが義務付けられました。ゲートウェイ、レート制限システム、ウェブアプリケーションファイアウォールなどは、リクエスト本文のJSONを解析しなくても、ヘッダーだけを見て通信を振り分けたりアクセスを制御したりできます。

利用可能なツール、プロンプト、リソースなどの一覧には、有効期間を示す「ttlMs」と、キャッシュの範囲を示す「cacheScope」も追加されました。クライアントは変更されていないツール一覧を毎回取得する必要がなくなり、サーバーへの通信量を削減できます。

ツール一覧の並び順も一定になるため、AIへ渡すプロンプトの内容が接続のたびに変化し、キャッシュが無効になる問題を抑えられます。MCPサーバーが多数のツールを提供する場合や、多数のユーザーが同時に接続する場合に、特に効果が期待されます。

◆長時間処理や画面表示は拡張機能へ
新機能をMCP本体から切り離して追加できる、正式な拡張機能の仕組みも導入されました。すべての機能を中核仕様に組み込むのではなく、必要なクライアントやサーバーだけが拡張機能を選択して対応できます。

長時間処理を扱う「MCP Tasks」は、実験的な機能から正式な拡張機能へ移行しました。サーバーは処理を続けながらタスクの識別子を返し、クライアントはその識別子を使って進捗や結果を後から取得できます。

チャット内にフォーム、表、ダッシュボードなどの操作可能な画面を表示する「MCP Apps」も、この拡張機能の仕組みで提供されます。MCPは単にAIから外部ツールを呼び出すだけでなく、ユーザーが操作する画面を含むAIアプリの基盤としても拡張されつつあります。


◆OAuth認証の安全性を強化
認証については、OAuth 2.0やOpenID Connectを企業システムで利用する方法に合わせた強化が行われました。認証サーバーを示す「iss」情報の検証が必須となり、クライアントの認証情報は発行元の認証サーバーと明確にひも付けられます。

これにより、ある認証サーバー向けに発行された情報が、別の認証サーバーで誤って使われることを防ぎやすくなります。クライアントをその場で登録するDynamic Client Registrationは非推奨となり、クライアント情報を文書として公開するClient ID Metadata Documentsへの移行も進められます。

◆廃止される機能には12カ月の移行期間
仕様変更によって既存の実装が突然利用できなくなることを防ぐため、正式な廃止方針も定められました。機能が非推奨とされてから削除されるまで、最低12カ月の移行期間が設けられます。

今回の更新では、Roots、Sampling、Loggingと、従来のHTTPとServer-Sent Eventsを組み合わせた通信方式が非推奨となりました。ただし、これらの機能はすぐに削除されるわけではなく、少なくとも今後12カ月は利用できます。


◆ClaudeやGitHubも新仕様に対応
TypeScript、Python、Go、C#の主要SDKは、新仕様の公開と同時に「2026-07-28」への対応を完了しており、Rust版SDKもベータ版として対応しています。主要SDKは旧仕様との後方互換性を維持しているため、既存のMCP接続を使い続けるだけであれば、直ちに移行する必要はありません。

GitHub MCP Serverは正式公開に先駆けて新仕様へ対応し、セッション情報を保存していたRedisへの読み書きや、リクエスト本文から処理内容を判別する仕組みを削除しました。ステートレス化によってサーバーの構成が簡素になり、一般的なクラウドインフラ上で運用しやすくなったとGitHubは説明しています。

AnthropicもClaudeの各製品に新仕様への対応を順次導入すると発表しています。Claudeのコネクターディレクトリには950件を超えるMCPサーバーが登録されており、新仕様によって運用負担を抑えながらMCPサーバーを大規模に展開できるようになるとしています。

今回の更新にはセッション廃止などの互換性を壊す変更が含まれるため、セッションIDに依存するMCPサーバーやクライアントでは移行作業が必要です。一方で、MCPを一般的なHTTPインフラ上で安全かつ大規模に運用するための仕組みが整い、企業の本番環境でも導入しやすい設計となっています。