MCP入門 - Model Context Protocolとは

MCP (Model Context Protocol) を使ってサーバーやクライアントを開発するエンジニア向けに、全体像と学習の進め方を解説します。このカテゴリは 2026-07-28 版の仕様を基準に、旧リビジョンとの差分にも触れながら構成します。

1. このドキュメントで扱うこと

• 背景と目的
• 登場人物 (Host / Client / Server)
• サーバーが提供する機能とクライアントが提供する機能
• ベースプロトコルとトランスポート
• 拡張 (Extensions)
• 仕様リビジョンの変遷
• ガバナンスとエコシステム
• このカテゴリの読み順

背景と目的

LLM アプリケーションが外部システム (Issue トラッカー、データベース、SaaS など) に接続するには、アプリとシステムの組み合わせごとに個別の連携コードが必要でした。アプリが M 個、システムが N 個あれば、統合は M×N 通りになります。

MCP はこの接続方法を共通のプロトコルにまとめ、アプリは MCP クライアントを 1 度実装すれば、MCP サーバーを公開しているあらゆるシステムに接続できるようにします。エディターと言語サーバーの組み合わせ問題を解いた Language Server Protocol (LSP) から着想を得ています。

MCP が定めるのはコンテキストをやり取りするためのプロトコルだけです。AI アプリが LLM をどう使うか、受け取ったコンテキストをどう管理するかは規定しません。

登場人物 (Host / Client / Server)

役割	説明	例
Host	MCP クライアントを束ねる AI アプリケーション	Claude Code、Claude Desktop、Visual Studio Code
Client	Host の中にあり、1 つの MCP サーバーとの接続を維持するコネクタ	Host が接続先のサーバーごとに 1 つ生成する
Server	コンテキストと機能を提供するプログラム	ファイルシステムサーバー、Sentry の MCP サーバー

Host は接続したいサーバーごとに MCP クライアントを 1 つ作り、クライアントとサーバーは 1 対 1 で接続します。

「MCP サーバー」は動作する場所を問わず、コンテキストを提供するプログラムを指します。stdio トランスポートで Host が子プロセスとして起動するものを「ローカル」、Streamable HTTP で公開されるものを「リモート」と呼びます。ローカルのサーバーは通常 1 つのクライアントだけに、リモートのサーバーは多数のクライアントに応答します。

サーバーが提供する機能とクライアントが提供する機能

サーバーは 3 種類のプリミティブを公開できます。

プリミティブ	内容	想定される制御主体
Tools	モデルが実行する関数 (ファイル操作、API 呼び出し、DB クエリなど)	モデル
Resources	コンテキストとなるデータ (ファイルの内容、DB のレコードなど)	アプリケーション
Prompts	ユーザー向けのテンプレート (システムプロンプト、few-shot 例など)	ユーザー

各プリミティブには、一覧取得 (*/list)、取得 (*/get)、実行 (tools/call) といったメソッドがあります。クライアントは */list で利用可能なものを動的に発見します。

クライアント側が提供する機能は、Elicitation (サーバーがユーザーへ追加入力や確認を求める) です。2026-07-28 版では Roots / Sampling / Logging が非推奨になりました。新規の実装では採用しません。

ベースプロトコルとトランスポート

MCP は 2 つの層で構成されます。

• データ層
  • JSON-RPC 2.0 に基づくメッセージの構造と意味を定める。機能の発見、Tools / Resources / Prompts、通知などが含まれる
• トランスポート層
  • 接続の確立、メッセージのフレーミング、認可を担う。stdio と Streamable HTTP の 2 つがある

2026-07-28 版のデータ層はステートレスです。すべてのリクエストが、プロトコルバージョンとクライアントの機能 (capabilities) を _meta に含み、サーバーはリクエスト単体で処理できます。サーバーの対応バージョンや機能を事前に知りたいクライアントは、server/discover を送れます。ただし必須ではありません。initialize のやり取りと Mcp-Session-Id ヘッダーは廃止され、任意のリクエストがラウンドロビンのロードバランサー配下のどのインスタンスにも届くようになりました。

拡張 (Extensions)

コアプロトコルの上に、オプトインで追加するモジュールとして拡張があります。たとえば次のものがあります。

• Tasks: 長時間かかるリクエストに対し、サーバーが永続的なハンドルを返し、クライアントがポーリングで状態と結果を取得する。2026-07-28 版でコアから拡張に移動した
• MCP Apps: ツールの結果として対話的な UI を返す
• Skills over MCP: Agent Skills をサーバーから発見・取得する。Resources プリミティブの上に載る

仕様リビジョンの変遷

MCP は日付ベースでバージョンを付けます。ネット上の記事には initialize やセッションを前提にしたものが多く残っているため、どのリビジョンを前提にした情報かを常に確認します。変遷は次節の表にまとめています。

ガバナンスとエコシステム

MCP は Anthropic が 2024 年 11 月に公開しました。現在はオープンな仕様として、Linux Foundation 傘下の Agentic AI Foundation の下で、Core Maintainers とワーキンググループが仕様を発展させています。

• SDK はティア制度で成熟度が示され、2026-07-28 の時点で TypeScript、Python、Go、C# の 4 つが Tier 1 です
• 公式 Registry でサーバーを公開・発見できます
• 仕様の変更は SEP (Specification Enhancement Proposal) で提案され、廃止には最低 12 か月の猶予期間を設ける方針です

このカテゴリの読み順

仕様 → 実装 → 認可 → セキュリティ → コンテキスト問題と CLI 比較 → 運用、の順に読み進めることを想定しています。詳しくは「3. 学習ロードマップ」を参照してください。

2. 仕様リビジョンの変遷

リビジョン	主なポイント
2024-11-05	初版。stdio と HTTP+SSE のトランスポート
2025-03-26	Streamable HTTP の導入、OAuth ベースの認可を追加 (HTTP+SSE は非推奨に)
2025-06-18	Elicitation の追加、認可仕様の整理 (MCP サーバーをリソースサーバーとして扱う)
2025-11-25	Tasks (実験的)、URL モード Elicitation、Client ID Metadata Documents など
2026-07-28	ステートレス化 (セッションと initialize を廃止)、Multi Round-Trip Requests、Tasks の拡張化

2026-07-28 版では上の表のほかに、次の変更が入っています。

• Streamable HTTP のリクエストに Mcp-Method と Mcp-Name ヘッダーが必須になり、ゲートウェイや WAF が JSON 本文を解析せずにルーティングや制限をかけられる
• tools/list などの結果に ttlMs と cacheScope が付き、クライアントがキャッシュ戦略を決められる
• 認可では RFC 9207 の iss 検証が必須になり、Dynamic Client Registration は非推奨となって Client ID Metadata Documents (CIMD) への移行が進む (CIMD に未対応の認可サーバーとの互換用に残り、最短の削除時期は 2027-07-28 以降に公開される最初のリビジョン)
• Roots / Sampling / Logging が非推奨になった (2026-07-28 版のリリースから少なくとも 12 か月は仕様に残る)。旧 HTTP+SSE トランスポートはこれより前から非推奨で、SEP-2596 の移行措置により、最短の削除時期は同 SEP が Final になってから 3 か月後

3. 学習ロードマップ

このカテゴリのドキュメントは、次の順に読み進めることを想定しています。

• 基礎・仕様
  • MCPプロトコル基礎 - JSON-RPCとステートレス設計
  • MCP最新仕様 2026-07-28 の変更点と移行
  • トランスポート - stdioとStreamable HTTP
• サーバー機能と拡張
  • Tools - ツールの定義と実行
  • Resources・Prompts・共通ユーティリティ
  • ElicitationとMulti Round-Trip Requests
  • MCP拡張機能 - Tasks・MCP Apps・Skills
• 実装と設計
  • MCPサーバーの実装 - SDKとGo・C#
  • MCPクライアント・ホストの実装
  • ツール設計パターンとアンチパターン
• 認可とセキュリティ
  • MCPの認可 - OAuth 2.1とメタデータ探索
  • MCPの認可拡張とエンタープライズ導入
  • MCPセキュリティベストプラクティス - 攻撃と対策
  • AIエージェント特有の脅威 - プロンプトインジェクションとツール汚染
  • ローカルMCPサーバーの安全な運用
• コンテキスト問題とCLI比較
  • コンテキスト肥大問題と対策
  • MCPとCLI・Skillsの比較と使い分け
• 品質・運用・配布
  • MCPのテストとデバッグ
  • MCPの可観測性と監査
  • MCPサーバーのデプロイと運用
  • MCP Registryとサーバーの配布

4. 開発者がつまずきやすいポイント

古い記事の initialize とセッションを前提にしない

2025-11-25 以前の資料には、initialize / initialized のハンドシェイクと Mcp-Session-Id ヘッダーを前提にしたものが多くあります。2026-07-28 版ではどちらも廃止され、各リクエストが自己完結します。サーバーを実装するときは、リクエスト間でメモリ上に状態を持つ設計を避けます。

ステートレスでもアプリケーションの状態は持てる

プロトコルがセッションを持たなくても、アプリケーションが状態を扱えなくなるわけではありません。状態が必要なら、ツールが明示的なハンドル (ID) を発行し、モデルが次の呼び出しの引数としてそれを渡す形にします。モデルからハンドルが見えるため、トランスポートに隠れたセッション状態より扱いやすくなります。

「MCP サーバー」はローカルとは限らない

MCP サーバーはローカルのプロセスでも、HTTP で公開されたリモートのサービスでもあります。「サーバーを立てる」という表現を、常に常駐プロセスの運用と受け取らないようにします。stdio のサーバーは Host が子プロセスとして起動します。

Streamable HTTP と旧 HTTP+SSE を混同しない

2024-11-05 版の HTTP+SSE トランスポートは、2025-03-26 版の Streamable HTTP に置き換えられました。旧トランスポートは非推奨で、SEP-2596 の移行措置により、削除の最短時期は同 SEP が Final になってから 3 か月後とされています (削除は Core Maintainers が決めるもので、自動ではありません)。新規に作るサーバーは Streamable HTTP を使います。

変更通知は opt-in で、確実には届かない

notifications/tools/list_changed などの通知は、クライアントが subscriptions/listen で種類を指定して購読した場合にだけ届きます。また最善努力 (best effort) であり、再接続をまたぐと欠落する可能性があります。クライアントは ttlMs に基づく再取得も併用します。

Tools / Resources / Prompts を使い分ける

何でも Tools にすると、モデルに見せる定義が増えてコンテキストを圧迫します。モデルが実行する操作は Tools、読み取り専用のデータは Resources、ユーザーが選ぶ定型の指示は Prompts、と目的で分けます。Tools の数と定義の大きさが引き起こす問題は コンテキスト肥大問題と対策 で扱います。

MCP は LLM の使い方を決めない

MCP が決めるのは、コンテキストと機能を受け渡す方法だけです。どのツールを呼ぶか、ツールの結果をどう扱うかはホストとモデルの責任であり、ツールの結果は信頼できない入力として扱う必要があります。

5. コード例

2026-07-28 版でのやり取りを JSON-RPC のメッセージで確認します。SDK はこれらのメッセージの組み立てを隠蔽するため、通常はここまで意識する必要はありませんが、デバッグ時に役立ちます。

機能の発見 (server/discover)

すべてのリクエストは _meta にプロトコルバージョンとクライアントの機能を含めます。server/discover は、サーバーの対応バージョンと機能を先に知りたいときに送る任意のリクエストです。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "server/discover",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

レスポンスには、対応バージョン (supportedVersions)、サーバーの機能 (capabilities)、キャッシュのヒント (ttlMs、cacheScope) が含まれます。

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "supportedVersions": ["2026-07-28"],
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": {}
    },
    "_meta": {
      "io.modelcontextprotocol/serverInfo": { "name": "example-server", "version": "1.0.0" }
    },
    "ttlMs": 3600000,
    "cacheScope": "public"
  }
}

ツールの一覧取得と実行 (tools/list、tools/call)

tools/list はツールの name、description、inputSchema などを返します。モデルはこの定義を見て、どのツールをどの引数で呼ぶかを決めます。

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "resultType": "complete",
    "tools": [
      {
        "name": "weather_current",
        "title": "Weather Information",
        "description": "Get current weather information for any location worldwide",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": { "type": "string", "description": "City name, address, or coordinates" },
            "units": { "type": "string", "enum": ["metric", "imperial", "kelvin"], "default": "metric" }
          },
          "required": ["location"]
        }
      }
    ],
    "ttlMs": 300000,
    "cacheScope": "public"
  }
}

実行は tools/call で、name に一覧で得た名前を、arguments に inputSchema に沿った引数を渡します。

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

Streamable HTTP では、同じリクエストが次のヘッダー付きの HTTP POST として送られます。ゲートウェイはこのヘッダーだけでルーティングや認可を判断できます。

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: weather_current

Claude Code にサーバーを接続する

Host の例として Claude Code にサーバーを追加するコマンドを示します。リモートのサーバーは HTTP、ローカルのサーバーは stdio で登録します。

# リモート (Streamable HTTP) のサーバーを追加
claude mcp add --transport http notion https://mcp.notion.com/mcp

# ローカル (stdio) のサーバーを追加。-- の後ろがサーバーの起動コマンド
claude mcp add --transport stdio airtable --env AIRTABLE_API_KEY=YOUR_KEY \
  -- npx -y airtable-mcp-server

# 登録済みのサーバーを確認
claude mcp list

チームで共有する場合は、--scope project を付けるとプロジェクトルートの .mcp.json に書き込まれます。

{
  "mcpServers": {
    "shared-server": {
      "type": "http",
      "url": "https://example.com/mcp"
    }
  }
}

6. まとめ

• MCP は LLM アプリと外部システムの M×N 統合問題を、共通のプロトコルで解決する。Host の中の Client が、Server と 1 対 1 で接続する
• サーバーは Tools / Resources / Prompts を公開し、クライアントは Elicitation を提供する。Roots / Sampling / Logging は非推奨
• 2026-07-28 版はステートレスで、initialize とセッションを廃止し、各リクエストの _meta に必要な情報を載せる。server/discover は任意
• Mcp-Method / Mcp-Name ヘッダー、ttlMs / cacheScope、iss 検証など、HTTP の運用基盤に載せやすくする変更が入った
• 資料を読むときは、どのリビジョンを前提にしているかを最初に確認する
• 以降のドキュメントは、仕様 → 実装 → 認可 → セキュリティ → コンテキスト問題と CLI 比較 → 運用の順で読み進める

参考資料

• MCP Specification (2026-07-28)
• Architecture overview
• MCP Roadmap
• MCP 2026-07-28 release announcement
• The next generation of MCP (Cloudflare Blog)