MCPとは？AIエージェント時代の標準プロトコルを仕組みから2026年最新仕様まで解説

• MCPはAIアプリと外部のツールやデータをつなぐ共通規格で、Host、Client、Serverの3者とTools、Resources、Promptsの3機能が基本になります
• 2026-07-28版の改訂でプロトコルはステートレス化され、initializeハンドシェイクとセッションIDが廃止されました
• MRTR、Mcp-Methodヘッダ、list結果のキャッシュ、CIMD認可が加わり、Roots/Sampling/Loggingは12か月の猶予付きで廃止予定になりました

MCPとは何か

MCP（Model Context Protocol）は、AIアプリケーションと外部のツールやデータソースをつなぐためのオープンな標準規格です。Anthropicが2024年末に公開し、その後は独立した仕様として運営されています。

公式ドキュメントでは「AIアプリにとってのUSB-C端子」という説明が使われています。以前は、AIアシスタントにカレンダーを読ませたい、社内データベースを検索させたいと思うたびに、アプリごとに専用の連携コードを書く必要がありました。MCPはその接続部分を共通化し、サーバーを1回作れば対応するどのAIアプリからでも使える状態を目指しています。

実際、Claude、ChatGPT、Visual Studio Code、Cursorといった主要なクライアントがMCPに対応しており、社内データを対話で扱う用途はOpenAIがChatGPT Workに投入したData agentのような製品にも広がっています。エージェントが自律的に道具を選んで使う時代に、その道具の差し込み口を標準化するのがMCPの役割です。

MCPの登場人物と2層構造

MCPを理解する最初の一歩は、3人の登場人物を区別することです。

• MCP Host: Claude DesktopやVS Codeなど、AIアプリ本体。全体を取りまとめる
• MCP Client: Host内部でサーバー1つにつき1つ作られる接続の担当者
• MCP Server: ツールやデータを提供するプログラム。ローカルでもリモートでも動く

Hostが3つのサーバーにつなぐなら、Clientも3つ作られます。図1のように1対1の接続が並ぶ構造です。

仕様は2つの層に分かれます。JSON-RPC 2.0でメッセージの中身を定めるデータ層と、通信路を定めるトランスポート層です。トランスポートは、同じマシン上のプロセスと標準入出力でやりとりするstdioと、HTTP POSTで通信するStreamable HTTPの2種類があります。

サーバーが提供する3つの機能

サーバー側が公開できるものは3種類に整理されています。ここがMCPの中心です。

• Tools: AIが呼び出して実行する関数。ファイル操作、API呼び出し、DB検索など
• Resources: 文脈として読み込ませるデータ。ファイル内容、スキーマ定義など
• Prompts: 再利用できる指示テンプレート。few-shot例やシステムプロンプトなど

それぞれに一覧用のtools/list、実行用のtools/callといったメソッドが対応します。クライアントはまず一覧を取り、その結果をLLM（Large Language Model: 大規模言語モデル）に渡し、モデルが選んだツールを呼び出す、という流れになります。

ツール定義には名前、説明、そしてinputSchemaというJSON Schemaが含まれます。モデルはこの説明文とスキーマだけを頼りに引数を組み立てるため、説明の書き方がそのまま呼び出し精度に効いてきます。

Elicitationで対話する

クライアント側が提供する機能もあります。2026-07-28版で残っている主要なものがElicitationです。

サーバーが処理の途中で「この操作を実行してよいか」「日付の指定が足りない」と判断したとき、ユーザーに追加入力を求める仕組みです。たとえば予約ツールが、日付だけ渡されて時間帯が不明だったとき、その場でユーザーに聞き返せます。

2026年版で何が変わったか

2026年7月28日に公開された改訂は、これまでで最も踏み込んだ内容になりました。最大の変更はプロトコルのステートレス化です。

従来は接続の最初にinitializeとnotifications/initializedのハンドシェイクを行い、以降はMcp-Session-Idヘッダでセッションを識別していました。新仕様ではこれが丸ごと廃止され、必要な情報は毎回のリクエストの_metaフィールドに載せます。

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": { "location": "Tokyo", "units": "metric" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

1リクエストが自己完結するため、ロードバランサ配下のどのサーバーインスタンスに届いても処理できます。共有セッションストアを用意する必要がなくなり、リモートサーバーの運用がぐっと楽になりました。

代わりに、サーバーの対応バージョンや機能を知るためのserver/discoverが必須メソッドとして追加されています。クライアントは最初にこれを呼んでもよいですし、いきなり本題のリクエストを投げてバージョンエラーを処理しても構いません。

MRTRという新しい対話方式

ステートレス化で困るのが、サーバーから会話の途中でユーザーに質問したい場面です。これまでは開きっぱなしのストリームを使ってサーバー発のリクエストを送っていましたが、その前提が消えました。

そこで導入されたのがMRTR（Multi Round-Trip Requests: 複数往復リクエスト）です。サーバーは処理を中断し、resultType: "input_required"と必要な質問を返します。クライアントはユーザーに確認したうえで、同じリクエストに回答を添えて投げ直すという形になります。

すべての結果にresultTypeフィールドが必須になった点も押さえておきたい変更です。通常の結果は"complete"、途中経過は"input_required"となり、古い仕様のサーバーがこの欄を省いた場合は"complete"とみなす決まりです。

ヘッダルーティングとキャッシュ

Streamable HTTPのPOSTリクエストにはMcp-MethodとMcp-NameというHTTPヘッダが必須になりました。ゲートウェイやWAF、レート制限装置が、本文のJSONを解析しなくてもヘッダだけで振り分けや認可判定をできるようにするためです。

あわせて、tools/listやresources/readなどの結果にttlMsとcacheScopeが必須化されました。前者は何ミリ秒キャッシュしてよいかの目安、後者は共有中継がキャッシュしてよいか（public）自分だけか（private）の区別です。

さらに、ツール一覧は毎回同じ順序で返すことが推奨されました。順序が揺れるとLLM側のプロンプトキャッシュが外れるためで、地味ながら実運用のコストに直結する配慮といえます。

旧仕様との違いを整理

認可まわりの強化とCIMD

認可の面では、クライアント登録の方式が入れ替わりました。これまで中心だったDCR（Dynamic Client Registration: 動的クライアント登録）が非推奨となり、CIMD（Client ID Metadata Documents）が推奨方式になっています。

CIMDでは、クライアントが自分のメタデータをJSONファイルとしてHTTPSのURLに置き、そのURL自体をclient_idとして使います。認可サーバーはURLを取得して名前やリダイレクト先を確認するだけでよく、事前登録が不要になります。URLは認可サーバーが変わっても使い回せるため、再登録の手間も消えます。

ほかにRFC 9207への対応も入りました。認可サーバーは応答にissパラメータを含め、クライアントは認可コードを引き換える前に記録済みの発行者と一致するか検証します。悪意ある認可サーバーが別のサーバー宛のコードを横取りするミックスアップ攻撃への対策です。

拡張機能というしくみ

コア仕様を薄く保ちつつ機能を足せるよう、拡張機能の枠組みが正式に定義されました。代表的なものが2つあります。

Tasksは長時間かかる処理のための拡張です。実験的機能としてコアにあったものがio.modelcontextprotocol/tasksという拡張に移り、結果待ちでブロックする方式からtasks/getによるポーリング方式へ設計変更されました。クライアントから追加入力を送るtasks/updateも加わっています。

MCP Appsは、ツールの結果としてHTMLの対話的な画面を返せるようにする拡張です。チャットの中にサンドボックス化されたiframeとして描画され、地図の絞り込みやフォーム入力、ダッシュボードの監視といった、文章では扱いにくい操作をその場で行えます。会話の文脈を離れずに済む点が、別タブでWebアプリを開くのとの違いです。

廃止ポリシーと移行の目安

今回の改訂では、機能のライフサイクル管理も明文化されました。Active、Deprecated、Removedの3状態を定義し、廃止予告から削除まで最低12か月の猶予を置くという方針です。破壊的変更が続いてきたMCPにとって、移行計画を立てやすくする意味は小さくありません。

実装時のセキュリティ注意点

MCPは外部プログラムにAIの権限を委ねる仕組みなので、セキュリティの前提を理解しないまま動かすのは危険です。仕様書が挙げる代表的な論点を押さえておきましょう。

• トークンパススルー禁止。自分宛でないトークンを受け取り転送してはいけない
• ステートハンドルの所持を認証代わりにしない。必ず利用者に紐づけて検証する
• ローカルサーバーの起動コマンドは、実行前に全文をユーザーに提示して同意を取る
• 認可URLは http と https のみ許可し、javascript: などのスキームは拒否する
• OAuthメタデータ取得時は内部IPアドレス帯を遮断してSSRFを防ぐ

権限のスコープは最小から始め、必要になった時点で段階的に引き上げる設計が推奨されています。最初から広い権限を要求すると、トークンが漏れたときの被害範囲も、ユーザーが同意画面で離脱する確率も上がってしまいます。

これからMCPを学ぶ人へ

公式SDKはTypeScript、Python、Go、C#が新仕様に対応済みで、Rust版もベータとして提供されています。SDKが細かい差分を吸収してくれるため、まずはツールを1つだけ持つ小さなサーバーを書いてClaude DesktopやVS Codeにつなぐのが分かりやすい入口でしょう。

そのうえで、2024年から2025年に書かれた日本語の解説記事を読むときは注意が必要です。initializeやセッションIDを前提にした説明は現行仕様と食い違うため、実装の際は必ず2026-07-28版のドキュメントで裏を取ってください。仕様が落ち着きつつある今は、腰を据えて追いかけ直すのに向いたタイミングだといえます。

The 2026-07-28 Specification

The 2026-07-28 Model Context Protocol specification is out, bringing a stateless protocol core, Multi Round-Trip Requests, header-based routing, cacheable list results, authorization hardening, a formal extensions framework, and updated Tier 1 SDKs.

blog.modelcontextprotocol.io