ハクソク

世界を動かす技術を、日本語で。

MCP仕様書 – 2025年6月18日の変更点

341日前原文(modelcontextprotocol.io)

概要

Model Context Protocol（MCP）仕様の最新版における主な変更点を要約。 OAuthやセキュリティ強化、ツール出力の構造化などを含む重要アップデート。 HTTP利用時のプロトコルバージョン指定や、リソースリンク機能の追加。 インターフェースやリクエストスキーマにも複数の拡張を実施。 詳細な変更履歴はGitHubにて確認可能。

Model Context Protocol 仕様の主な変更点（2025-03-26以降）

  • JSON-RPCバッチ処理 のサポート削除（PR #416）
  • ツール出力の構造化 に対応（PR #371）
  • MCPサーバー を OAuth Resource Server として分類
    • 対応する Authorization server の検出用に保護リソースメタデータを追加（PR #338）
  • MCPクライアント に Resource Indicators （RFC 8707）の実装を必須化
    • 悪意あるサーバーによるアクセストークン不正取得の防止（PR #734）
  • 認可仕様 および新設の セキュリティベストプラクティスページ でセキュリティ考慮事項を明確化
  • Elicitation機能 の追加
    • インタラクション中にサーバーがユーザーに追加情報を要求可能（PR #382）
  • ツール呼び出し結果 への リソースリンク 追加（PR #603）
  • HTTP利用時、以降のリクエストで MCP-Protocol-Versionヘッダー による交渉済みプロトコルバージョンの指定を必須化（PR #548）
  • Lifecycle Operation における SHOULD から MUST への仕様強化

その他スキーマ変更

  • 複数のインターフェース型に _metaフィールド を追加し、適切な利用方法を明記（PR #710）
  • CompletionRequest に contextフィールド を追加
    • 事前に解決済み変数を含めた補完リクエストが可能に（PR #598）
  • titleフィールド を追加し、プログラム識別子用のnameと区別
    • 人間向け表示名の指定が可能に（PR #663）

変更履歴の確認方法

  • すべての変更点の詳細は GitHub にて公開
  • 最新のプロトコル改訂以降のフルチェンジログ参照推奨

Hackerたちの意見

認可されたMCPサーバーへのシンプルな道ができたのが嬉しい！MCPコミュニティとAnthropicの皆さん、すごく感謝してます。

└

MCPサーバーって何のためにあるの？エージェントからRPCを作りたいなら、普通にRPC使えばいいじゃん。

コアの仕様がTypeScriptで書かれてるのが面白いね。OpenAPI仕様とかじゃなくてさ。まあ、納得はできるけど、やっぱり驚きだよね。

└

なんで驚くの？自分はTypeScriptをよく使うけど、こんな視点を持つなんて考えもしなかったから、言語設計の決定については見落としてる部分があるのかも。

ほとんど無駄な複雑さだけど、バッチ処理がなくなるのは寂しいな。クライアントが自分でレスポンスをバッチ処理できるとしても、「これらのことを全部やってから返事して」って言えるのはちょっと面白かったから。

└

同意だよ。JSON-RPCのバッチ処理はずっと「お、これはいいな」って思ってた機能だったから、仕様から外れるのは悲しい。でも、君が言ったように、結局は複雑さを増やすだけなんだよね。

MCPの盛り上がりに乗って学んだ一番大きな教訓は、バックエンドソフトウェアを書くならMCPを使う必要はないってこと。アーキテクチャ的に意味がないんだよね。少なくともElixirではそう。APIごとにサーバーを立てるの？バックエンドやってるならそれはちょっとクレイジーに聞こえる。500個のAPIに対して500個のマイクロサービスってことだし。20個のMCPサーバーを使った後、結局、MCPの裏側で動いてる普通の関数呼び出しで十分だって気づいたんだ。それぞれのAPIはサーバーじゃなくてモジュールにできるし、最新のMCP仕様を追いかける必要も、仕様変更で100個以上のマイクロサービスを更新する必要もない。無駄な複雑さだよ。

└

MCPは、Claudeを使うときにAPIコストをかけずに関数呼び出しを有効にするためのプラグアンドプレイの統合だと思ってた。APIを使ってて急いでないなら、必要ないよね。

└

クライアントとモデルをつなぐための標準プロトコルって感じだね。ツールコールのためのコンテナだけじゃないんだよ。

└

APIごとにサーバーが一つ？バックエンドやってるなら、実際それはクレイジーに聞こえるよ。エリクサーには詳しくないけど、以前やってたみたいに複数の異なるAPIやバックエンド、マイクロサービスを組み合わせてモノリスのMCPを作るのを禁止するものってあるの？それに、ツールコールだけでMCPを使っても、いろんなクライアントアプリケーションとの統合は得られないよ。これが私にとってのMCPの「キラーアプリ」なんだ（別のコメントでも触れられてるけど）。MCPにはまだ複雑な気持ちもあるけど、今回はMCPがちょっと勝ってるかな。

└

「各APIはサーバーじゃなくてモジュールにできる」って、これがMCPの本質だよね。MCPができる前は、みんながそれぞれのAPIに対して独自の関数呼び出しインターフェースを作ってた。今は（少しずつ）標準化されてきてる。

└

各APIはそれぞれのモジュールにできる それは言語ロックインを意味するから、あんまり望ましくないよね。

└

同意！APIごとにMCPサーバーを立てるのはスケールしないよね。https://nango.devみたいなのを使えば、400以上のAPIをカバーする単一のサーバーが手に入るし、認証や可視化も扱ってくれるし、直接ツールを呼び出すための他のインターフェースも提供してくれるよ。（ちなみに、私が創業者です）

└

もう一歩進めて言うと、LLMにJSONを出力させるのはちょっとバカげてるよね。モデルに対して、好みじゃないフォーマットを強制するために時間と労力を使ってるのがもったいない。もっと制約のあるテキストベースのDSLの方がずっと良い選択だったと思う。数年前、GPT 3.5にプロンプトの例をいくつか見せるだけで、英語っぽいDSLを安定して出力させることができたのに、今でも最新のモデルはJSONスキーマの一部を無視することがあるって注意書きがあるんだよね。四角い釘を丸い穴に押し込もうとしてるみたいで、やめてほしい。

└

クライアントが各マイクロサービスに独立して話しかける場合、何らかのゲートウェイやBFFを通らない限り、MCPをその前に置いてAPI（またはGraphQL、RPCなど）を通じて呼び出される同じ機能を公開することになると思う。だから、基本的にはLLM専用のインターフェースってことだよね。OpenAPI仕様でツールコールを使えない理由はないけど、どちらにしても、すべてのマイクロサービスがMCPを介して話すのはすごいことだと思う。

└

もし一つの入口から全部やりたいなら、プロキシサーバーを使うのは全然問題ないよ。そもそも、何百ものMCPにアクセスしてるクライアントなんて知らないし、それはちょっと的外れな意見だね。ウェブ開発とは違って、クライアントがコンポーネントやAPIコールをもっと書けばいいってわけじゃないから、AIにはコンテキストの制限があるんだ。もし500のMCPサーバーに、それぞれ2〜10のツールを接続しようとしたら、システムのプロンプトで大量のコンテキストを無駄にしちゃうよ。ツールプロキシ（他のツールにルーティングする一つのツール）を使うこともできるけど、それだと処理による遅延が増えちゃうからね。

MCP仕様の急速な改善を見れてすごく嬉しい！新しいリリースのたびに、MCP統合で足りなかった部分に気づくんだよね。

仕様の変更には合意が一つ必要って、面白いよね（笑）

引き出しが大きな勝利だね。私のお気に入りのMCPサーバーの一つは自分で作ったSSHサーバーで、基本的にサーバーのタスクの90%を自動化できるんだ。認証は設定ファイルで管理してるけど、新しいサーバーにアクセスするのはちょっと面倒なんだよね。

└

いつでも https://www.fabfile.org/ があるから、プライベートに保つべき会話にLLMを持ち込む必要はないよ。

リソースの更新・削除の承認ワークフローを持つのは理にかなってると思う。MCPサーバーが特定のステップを承認するためのOAuthリンクを持つって感じで。

└

残念ながら、まだ存在しないし、オープンな問題だね。

WWW-Authenticateチャレンジの導入は本当に歓迎されるね。これで、MCPサーバーがクライアントをリソースプロバイダーのOAuthフローに送り込むことが明確になったし、Authorization: Bearer ...を待つだけで済む。

ここ数日、MCPを使っていくつかのデータセット用のラッパーを作って遊んでた。感想はこんな感じ：1) LLMにとって一番クールなことだと思う。ツールコールやAPIでできることだけど、技術に詳しくない友達にMCPのURLを送って、数クリックで使い始めるのを見るのはすごい。2) C# SDKを使ってるけど、認証がブランチにしかないから、かなり最先端。実装にかなり苦労したよ。95%の時間を認証に費やした（ローカルで構築してない場合、claudeのMCP統合には必須）。ドキュメントがあればもっと簡単になると思うけど、かなり手間がかかる。3) それに関連して、ClaudeはAFIAK、ウェブアプリ（デスクトップじゃなくて）を通じて送信しているものや問題が何かについての開発者ログをあまり公開していない。エラーメッセージのリクエスト/レスポンスを表示する開発者モードがあればすごく助かる。認証のリフレッシュで本当に問題があって、間違ったエンドポイントをログしてたことが判明した。オペレーターエラーだけど、もっと良いMCPログがウェブUIのどこかにあれば、数分で解決できたはず。デスクトップとMCPインスペクターでは全然問題なく動いた。4) 主な質問/問題は、長時間実行されるタスクの扱い。公開しているデータセットは、実際にはPDFドキュメントの山で、claudeがPDFファイルを自分で扱えないから（方法があれば教えて！）。今やってるのは、geminiを通してテキストを取得して、それをMCP経由でユーザーに送信すること。短い/シンプルなドキュメントには問題なく機能するけど、長いドキュメント（処理に時間がかかることがある）については、処理中で後で再試行するようにメッセージを返してる。進捗APIがあるのは知ってるけど、サーバーとの接続を開いたままにしないといけない（Cloudflareでは一定時間後にタイムアウトする）から、ここは間違ってるかもしれない。予測できる時間にLLMに「x秒後に確認して」って言える方がずっと良いし、LLMはバックグラウンドで他のことをやれる（実際にそうするけど）、でもタイマーが来るまで「実行を一時停止」する感じ。今のところ（AFIAK！）は、進捗を伴うオープン接続で待たせるか、ジョブIDを返すかのどちらかだけど、その場合は半分終わった答えが返ってきて、まだ全てのコンテキストがないから誤解を招くことが多い。これが意味をなすか分からないけど、10分以上かかるタスクには本当に面倒だと思う。

└

長時間実行されるタスクはオープントピックで、MCPは将来的にこれに対処するつもりだと思う。いくつかの提案が出てるけど、問題の一つは、タスクが長時間かかるかどうかを常に把握できないことだから、長時間タスク用のAPIと「通常の」ツールコール用のAPIを分けても問題が完全には解決しない。もっと包括的に問題を解決する提案を書いたよ：https://github.com/modelcontextprotocol/modelcontextprotocol...