Model Context Protocol（MCP）2025年6月18日版の変更概要
はじめに
Model Context Protocol（MCP）が2025年6月18日に新しいバージョンをリリースした。なお、前回のリリースは2025年3月26日であり、約3ヶ月置いての更新となる。
Model Context Protocol（MCP）の2025年6月18日版は、AI アプリケーション開発における重要なアップデートを提供している。このリリースでは、プロトコルの機能拡張とセキュリティ強化が行われ、特に構造化ツール出力やelicitation機能の追加が注目される。
本記事では、変更内容の主だった項目を整理し、仕様の詳細部分は公式ドキュメントへのリンクを参照する形とする。
2025年3月26日版の内容は、すでに多くの解説記事が存在するため、ここでは前提として扱う。
手前味噌ながら、こちらの記事を置いておく。牛。
2025-06-18版で実装された変更項目
前回リビジョン（2025-03-26）からの変更内容を公式変更ログに基づいて整理した。
主要変更（Major changes）
| 変更項目 | 詳細 | 分類 |
|---|---|---|
| JSON-RPCバッチング削除 | batching機能のサポート廃止 | プロトコル簡素化 |
| 構造化ツール出力追加 | structured tool output機能の実装 | 機能拡張 |
| OAuth Resource Server分類 | ・MCPサーバーのOAuthリソースサーバー分類 ・Protected resource metadata追加 ・Authorization server発見機能 |
セキュリティ強化 |
| RFC 8707実装必須化 | ・Resource Indicators for OAuth 2.0の実装義務 ・悪意あるサーバーからのトークン取得防止 ・クライアント側実装要求 |
セキュリティ強化 |
| セキュリティ仕様明確化 | ・authorization spec内のセキュリティ考慮事項明確化 ・新しいセキュリティベストプラクティスページ追加 ・実装ガイドラインの詳細化 |
セキュリティ強化 |
| elicitation機能追加 | ・サーバーがユーザーからの追加情報要求を可能に ・インタラクション中の動的情報収集 ・構造化スキーマによる応答制御 |
機能拡張 |
| リソースリンク追加 | ・ツール呼び出し結果でのリソースリンクサポート ・追加コンテキスト提供 ・関連データへの参照機能 |
機能拡張 |
| プロトコルバージョンヘッダー必須化 | ・HTTP使用時のMCP-Protocol-Versionヘッダー必須 ・ネゴシエーション結果の明示 ・後続リクエストでの仕様明確化 |
プロトコル管理 |
| ライフサイクル操作厳格化 | ・Lifecycle OperationでのSHOULD→MUST変更 ・実装要件の厳格化 ・互換性保証の強化 |
プロトコル管理 |
その他のスキーマ変更（Other schema changes）
| 変更項目 | 詳細 | 目的 |
|---|---|---|
| _metaフィールド拡張 | ・追加のインターフェースタイプに_metaフィールド追加 ・適切な使用方法の明文化 ・メタデータ管理の統一 |
スキーマ拡張 |
| contextフィールド追加 | ・CompletionRequestにcontextフィールド追加 ・以前に解決された変数の含有 ・補完要求での文脈情報活用 |
機能拡張 |
| titleフィールド追加 | ・人間に分かりやすい表示名用のtitleフィールド ・nameフィールドをプログラム識別子として明確化 ・UI表示とAPI識別の分離 |
ユーザビリティ向上 |
上記項目の変更のうち、特に影響が大きいと思われる構造化ツール出力、elicitation機能、OAuth強化、リソースリンク追加の4つを取り上げる。
構造化ツール出力
従来のMCPでは、ツールの実行結果は文字列として返されるため、その内容を解析する必要があった。
新しい構造化出力機能では、データが整理された状態で提供される。以下の技術仕様がその仕組みを示している。
| 要素 | 従来の方式 | 新しい構造化方式 |
|---|---|---|
| データ形式 | テキストのみ | ・テキスト + 構造化JSON ・後方互換性維持 ・並行提供方式 |
| 処理効率 | テキスト解析必要 | ・直接的なデータアクセス ・解析オーバーヘッド削減 ・エラー率低下 |
| 検証機能 | なし | ・JSONスキーマベース検証 ・データ品質保証 ・型安全性確保 |
後方互換性を維持した二重提供フロー
構造化出力の実装では、サーバーは同じ情報を二つの形式で提供する。これにより既存のクライアントは従来通り動作し、新しいクライアントは構造化データの恩恵を受けられる。
{
"jsonrpc": "2.0",
"id": 5,
"result": {
"content": [
{
"type": "text",
"text": "{\"temperature\": 22.5, \"conditions\": \"Partly cloudy\", \"humidity\": 65}"
}
],
"structuredContent": {
"temperature": 22.5,
"conditions": "Partly cloudy",
"humidity": 65
}
}
}
この二重提供により、既存のクライアントは従来通り動作し、新しいクライアントは構造化データの恩恵を受けられる。
公式資料の詳細は以下のリンクを参照。
Elicitation機能によるインタラクティブ化
Elicitationは、MCPサーバーが実行中にユーザーから情報を動的に収集できる機能だ。これまでのツールは一方向的な処理が中心だったが、対話的な処理が可能になった。
以下の表でElicitationの技術仕様を整理した。
| 機能要素 | 技術仕様 | セキュリティ考慮事項 |
|---|---|---|
| スキーマ定義 | ・JSONスキーマによる構造化 ・プリミティブ型のみサポート ・フラットオブジェクト限定 |
・機密情報要求の禁止 ・PII収集制限 ・目的明示の義務 |
| 応答パターン | ・Accept/Reject/Cancelの三択 ・明示的承認 ・明示的拒否 ・操作中断 |
・ユーザー選択の尊重 ・強制実行の禁止 ・透明性の確保 |
| 実装制約 | ・クライアント制御下での実行 ・サーバー主導禁止 ・UI表現の自由度 |
・データ共有制御の維持 ・悪意ある情報収集の防止 ・ユーザー主権の保護 |
基本的なElicitationフロー（Accept）
Elicitationの基本的な流れは、サーバーがユーザーからの情報を要求し、クライアントがその情報を収集してサーバーに返すというものだ。
Reject/Cancelパターンの分岐フロー
Elicitationでは、ユーザーが情報提供を拒否したり、操作をキャンセルすることも可能だ。これにより、ユーザーの意図を尊重した処理が行える。
Elicitationの制約は意図的に厳しく設計されている。強力な機能ほど慎重に扱う必要があるためだ。
公式資料の詳細は以下のリンクを参照。
OAuth 2.1とRFC 8707によるセキュリティ強化
今回のアップデートでのセキュリティ変更の一つが、認証・認可システムの強化だ。従来のMCPではローカル環境での使用が前提だったが、クラウド展開やマルチテナント環境での利用を想定した設計に進化した。2025-06-18版では特にMCPサーバーをOAuthリソースサーバーとして明確に分類し、セキュリティ仕様を厳格化している。
リソースインジケータによるトークン保護
RFC 8707のリソースインジケータは、OAuth トークンに宛先情報を付ける仕組みだ。これによりトークンが間違ったサーバーに送信され、悪用されることを防ぐ。MCPクライアントは認証・トークン要求時にリソースパラメータを必ず含める必要がある。
OAuth Resource Server分類とPRMの実装義務化
2025-06-18版では、MCPサーバーが明確にOAuthリソースサーバーとして分類され、RFC 9728（OAuth 2.0 Protected Resource Metadata）の実装が必須（MUST）となった。これにより、認可サーバーの自動発見機能が標準化され、クライアントはサーバーの認証情報を動的に取得できるようになる。
Protected Resource Metadata（PRM）は以下の重要な役割を持つ。
- 認証サーバーの場所情報提供（
authorization_serversフィールド） - サーバー自身のリソース識別子の明示（
resourceフィールド） - サポートされるスコープの公開（
scopes_supportedフィールド）
MCPクライアント側も、PRM文書に基づいて認証サーバーを発見することが必須となった。
Protected Resource Metadata の自動発見フロー
MCPサーバーは/.well-known/oauth-protected-resourceエンドポイントでメタデータを公開する必要がある。これにより認証サーバーの場所やスコープ情報を自動的に伝える。
RFC 8707リソースインジケータの検証プロセス
RFC 8707の実装必須化により、MCPプロトコルにおけるトークンセキュリティが大幅に強化された。このメカニズムはOAuth 2.0におけるリソースインジケータを活用し、アクセストークンが特定の対象リソース（この場合はMCPサーバー）に厳密にバインドされることを保証する。以下のシーケンス図はトークン検証の基本フローと、リソースインジケータが悪意のあるサーバーからの攻撃をどのように防ぐかを示している。
このように、RFC 8707のリソースインジケータは、トークンが意図したサーバーでのみ使用されることを保証する重要なメカニズムだ。
公式資料の詳細は以下のリンクを参照（Webブラウザのリダイレクト処理を含めた OAuth2.1 のフローを知りたい場合は要参照）。
リソースリンクによるコンテキスト拡張
ツールの実行結果に関連リソースへのリンクを含められる新機能だ。結果の根拠や追加情報への道筋を提供する。2025-06-18版では、ツールがリソースリンクを返すことで、クライアントは必要に応じて追加コンテキストにアクセスできるようになった。
リソースリンクの構造
リソースリンクは以下の構造を持つ。
{
"type": "resource_link",
"uri": "file:///project/src/main.rs",
"name": "main.rs",
"description": "Primary application entry point",
"mimeType": "text/x-rust"
}
各フィールドの意味は以下の通り。
-
type: リソースリンクを示す -
uri: リソースの場所を示す一意の識別子 -
name: リソースの名前 -
description: 人間が読むためのリソース説明 -
mimeType: リソースの形式を示すMIMEタイプ
URIスキームの種類
MCP 2025-06-18版では、以下の主要URIスキームがサポートされている。
-
https://: Web上のリソース（クライアントが直接アクセス可能） -
file://: ファイルシステム上のリソース（物理的なファイルとは限らない） -
git://: Gitバージョン管理システム上のリソース - カスタムURIスキーム: RFC3986に準拠した実装固有のスキーム
リソースアクセス方法
クライアントはリソースリンクを受け取ると、resources/read APIを使ってリソースの内容にアクセスできる。
// リソース読み取りリクエスト
{
"jsonrpc": "2.0",
"id": 2,
"method": "resources/read",
"params": {
"uri": "file:///project/src/main.rs"
}
}
公式資料の詳細は以下のリンクを参照。
- リソースリンク: https://modelcontextprotocol.io/specification/2025-06-18/server/tools#resource-links
- リソース機能全般: https://modelcontextprotocol.io/specification/2025-06-18/server/resources
- URIスキーム: https://modelcontextprotocol.io/specification/2025-06-18/server/resources#common-uri-schemes
セキュリティベストプラクティスの拡充
2025-06-18版では、セキュリティに関する考慮事項が拡充され、新しいセキュリティベストプラクティスページが追加された。
公式資料の詳細は以下のリンクを参照。
- 認可におけるセキュリティ考慮事項：https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization#security-considerations
- セキュリティベストプラクティス：https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices
まとめ
Model Context Protocol（MCP）の2025年6月18日版は、AI アプリケーション開発における重要なアップデートを提供している。特に、構造化ツール出力やelicitation機能の追加、OAuth 2.1とRFC 8707によるセキュリティ強化が注目される。
これらの変更により、MCPはより安全で効率的なAIアプリケーション開発をサポートすることが期待される。
Discussion