~/ / AI記事 / MCP仕様 2026-07-28: 何が変わったか、自分のファイルで何を確認するか
MCP仕様 2026-07-28: 何が変わったか、自分のファイルで何を確認するか
Model Context Protocol(MCP)の仕様リビジョン2026-07-28では、プロトコル層のセッションがなくなり、従来のHTTP+SSEトランスポートといくつかの機能が非推奨になり、ツールのスキーマに関する規則が緩和されました。この記事は公式の変更履歴を要約し、自分で書く2つのファイル、つまりMCPの設定とツールのスキーマの確認方法を示します。
公開: · 2026-10-24に公式の仕様と照らして確認しました。この記事は仕様の要約であり、仕様の代わりにはなりません。
主な変更点
- Streamable HTTPトランスポートから、プロトコル層のセッションとMcp-Session-Idヘッダーが取り除かれました。呼び出しをまたいで状態が必要なサーバーは、自分で作った明示的なハンドルを通常のツール引数として渡します。
- MCPはステートレスになり、initializeのハンドシェイクはなくなりました。すべてのリクエストが、プロトコルのバージョンとクライアントのcapabilitiesを_metaに含め、バージョンが合わない場合はUnsupportedProtocolVersionErrorが返ります。
- サーバーは、対応するプロトコルのバージョン、capabilities、識別情報を知らせる新しいserver/discover呼び出しを実装しなければなりません。
- HTTPのGETエンドポイントとresources/subscribeは、subscriptions/listenに置き換えられました。クライアントが選んだ変更通知を、長く続く1本のレスポンスストリームで受け取ります。
- roots/list、sampling/createMessage、elicitation/createのようなサーバー起点のリクエストは、Multi Round-Trip Requestsというパターンに置き換えられました。サーバーが入力を求める結果を返し、クライアントがその答えを付けて元のリクエストをもう一度送ります。
- 試験的なtasksは、コアのプロトコルから公式の拡張に移りました。
- 再開できるSSEストリーム(Last-Event-ID)は廃止されました。レスポンスストリームが途切れると、処理中のリクエストは失われ、クライアントは新しいリクエストとして送り直す必要があります。
新たに非推奨になったもの
| 機能 | 非推奨になったリビジョン | 最も早い削除時期 | 推奨される移行先 |
|---|---|---|---|
| Roots | 2026-07-28 | 2027-07-28以降に最初に公開されるリビジョン | ツールのパラメーター、リソースURI、サーバーの設定でディレクトリやファイルを渡す |
| Sampling | 2026-07-28 | 2027-07-28以降に最初に公開されるリビジョン | LLMプロバイダーのAPIと直接連携する |
| Logging | 2026-07-28 | 2027-07-28以降に最初に公開されるリビジョン | stdioならstderrに出力する、またはOpenTelemetryを使う |
| Dynamic Client Registration | 2026-07-28 | 2027-07-28以降に最初に公開されるリビジョン | Client ID Metadata Documents |
| HTTP+SSEトランスポート | 2025-03-26 | SEP-2596がFinalになってから3か月後 | Streamable HTTP |
| includeContextの値thisServerとallServers | 2025-11-25 | Samplingに従う | このフィールドを省略するか、noneを使う |
非推奨の機能も、引き続き仕様の一部です。最も早い削除時期は、削除の対象になりうる時期を示すもので、実際に削除するかどうかはリリース準備の中で決まります。新しい機能ライフサイクルのポリシーでは、非推奨の期間を最低12か月と定めています。
MCPの設定を確認する
設定がまだHTTP+SSEトランスポートを使っているなら、それは非推奨の一覧に入っています。Claude Codeのドキュメントも、sseタイプを非推奨としており、利用できる場合はHTTPサーバーを使うよう述べています。仕様は後継のStreamable HTTPを次のように説明しています。サーバーはPOSTを受け付ける単一のエンドポイントを公開し、クライアントはJSON-RPCメッセージをそれぞれ別のHTTP POSTとして送ります。
- 各POSTには、application/jsonとtext/event-streamの両方を挙げたAcceptヘッダーを含める必要があります。
- すべてのPOSTに、値がリクエスト本文のプロトコルバージョンと一致するMCP-Protocol-Versionヘッダーを含める必要があります。
- リクエストにはMcp-Methodヘッダーを付け、tools/call、resources/read、prompts/getにはMcp-Nameヘッダーも付けます。
- サーバーは、各リクエストに対して、単一のJSONオブジェクト、またはそのリクエストに限定したSSEストリームで答えます。
お使いのクライアントがどのプロトコルリビジョンに対応しているかは、クライアントのドキュメントで確認してください。下のチェッカーは.mcp.jsonまたはclaude_desktop_config.jsonを読み込み、typeのないリモートサーバーや、まだsseを使っているエントリーなどを報告します。
試してみる: MCP Config Checker
ルールは 2026-10-23 時点のドキュメントで確認しています。
ドキュメント: Claude Code / Model Context Protocol / VS Code
確認していないもの: コマンドが存在するか、パッケージをインストールできるか、リモートサーバーが応答するか、そして他のアプリケーションが異なる扱いをする設定。
すべてブラウザ内で実行されます。設定はアップロードされません。
ツールのスキーマでJSON Schema 2020-12のすべてが使える
- inputSchemaとoutputSchemaでは、JSON Schema 2020-12のどのキーワードも使えるようになり、structuredContentには任意のJSON値を入れられます。仕様には、$refの解決に関する要件と、組み合わせ用のキーワードが使えるリソースの上限が加わりました。
- サーバーは、ツールのパラメーターにx-mcp-headerを付けて、その値をMcp-Param-{name}というHTTPヘッダーにコピーさせることができます。付けるパラメーターは、数値(number)ではなく、文字列、整数、真偽値のいずれかでなければなりません。
- 付けたプロパティは、スキーマのルートからpropertiesキーだけをたどって到達できる必要があります。途中でitems、oneOf、anyOf、allOf、not、if/then/else、$refを通ってはいけません。
- Streamable HTTPを使うクライアントは、x-mcp-headerの注釈がこれらの規則に反しているツール定義を拒否しなければなりません。つまり、そのツールはtools/listの結果から外されます。
ツールのスキーマを試すには、サンプルの引数と一緒に下のバリデーターへ貼り付けてください。Draft 2020-12の主なキーワードを確認し、確認しないキーワードがどれかも示します。
試してみる: JSON Schema Validator
対応しているキーワードについては、JSON Schema Draft 2020-12 に従っています。$ref は、同じ schema の中だけを読み取ります。
すべてブラウザの中で処理します。schema もデータもアップロードされません。
サーバー向けのセキュリティ上の要点
- サーバーは、DNSリバインディング攻撃を防ぐため、すべての受信接続でOriginヘッダーを検証しなければなりません。ヘッダーがあって無効な場合は、HTTP 403 Forbiddenで答える必要があります。
- ローカルで動かすサーバーは、すべてのネットワークインターフェース(0.0.0.0)ではなく、localhost(127.0.0.1)だけにバインドすべきです。
- サーバーは、すべての接続に対して適切な認証を実装すべきです。
- リクエスト本文を処理するサーバーは、ヘッダーが本文と一致しないリクエストを、HTTP 400とJSON-RPCエラーHeaderMismatch(コード-32020)で拒否しなければなりません。
- 認可サーバーは、認可レスポンスにissパラメーターを含めるべきです(RFC 9207)。issがある場合、クライアントは認可コードを引き換える前にそれを検証しなければなりません。
- クライアントは、保存したクライアントの認証情報を、それを発行した発行者(issuer)ごとに管理しなければならず、別の認可サーバーで再利用してはいけません。