MCPとは、AIアプリケーションを外部のデータソースやツールへつなぐためのオープンなプロトコルです。標準化されているのは接続の中身ではなく手順です。具体的には、JSON-RPC 2.0のメッセージ形式、ホスト/クライアント/サーバーという3役の分担、サーバーが出せる機能の種類(Resources・Prompts・Tools)、そして各リクエストがどのバージョンで話しているかの宣言方法です(MCP仕様 2026-07-28 2026-09-16閲覧)。
そして「MCPとは」を調べるときに最初に確かめるべきは、読んでいる解説がどのリビジョンの話かです。現行リビジョンは2026-07-28で(Versioning 2026-10-04確認)、この版はinitializeハンドシェイクとMcp-Session-Idを廃止し、プロトコルをステートレスに変えました(同 Key Changes 2026-09-16閲覧)。つまり「まずinitializeでセッションを張り、能力をネゴシエートする」という説明は、2025-11-25以前のリビジョンの説明です。旧リビジョンの説明が誤りになったわけではなく、使うホストやサーバーが旧リビジョンで話していれば、その接続では今もinitializeを使います。仕様はYYYY-MM-DDという識別子を使い、後方非互換な変更が最後に入った日付を示します。
この記事の日付について。 2026年9月16日に調査・執筆し、公開日の2026年10月4日に、仕様の現行リビジョン・HTTPヘッダー・MRTR・ベンチマークの指標などを一次資料で再確認して更新しました。本文と出典表の「2026-09-16」は執筆時、「2026-10-04」は公開前の再確認の日付です。筆者環境の観測値は2026年9月16日の記録です。2026年10月11日に第8節〜第10節(代表的なサーバーの例・料金・Claude Code での接続方法)と、よくある質問4項目を追記しました(「2026-10-11確認」はその日の確認です)。
この記事でわかること
- MCPを1文で説明するための定義と、何が標準化されていて何は標準化されていないのか
- ホスト・クライアント・サーバーの3役と、
tools/listからtools/callまでに流れるJSON-RPCの中身(_metaの必須フィールドとエラーコード) - 自分が読んでいる解説がどの仕様リビジョンの話かを
initializeの有無で判別する方法と、5リビジョンの対応表 - 2026-07-28でDeprecatedになった機能(Roots・Sampling・Logging)と、最短で削除される時期
- 導入前に踏むべきリスク確認の項目と、攻撃ベンチマーク論文が報告した「能力の高いモデルほど脆弱」という結果
1. MCPとは──1文の定義と、誰が出しているのか
定義は公式仕様の冒頭が短く書いています。MCPは「LLMアプリケーションと外部のデータソース・ツールとのシームレスな統合を可能にするオープンプロトコル」です(MCP仕様 2026-09-16閲覧、原文は英語)。2024年11月にAnthropicが公開し、2025年12月にLinux Foundation傘下のAgentic AI Foundationへ寄贈された仕様ですが、仕様リポジトリのLICENSEはMITからApache-2.0への移行中の複合ファイルで、前文に続けてApache-2.0とMITは全文、CC-BY-4.0は見出しと外部リンクによる参照という順で並んでいます。新規のコードと仕様の寄与にはApache-2.0が適用され、仕様を除くドキュメントの寄与はCC-BY-4.0です。MITセクションに置かれた著作権表記は「Copyright (c) 2024-2025 Model Context Protocol a Series of LF Projects, LLC.」で、リポジトリのREADMEは今も「This project is licensed under the MIT License」と記載しています(modelcontextprotocol/modelcontextprotocol LICENSE・同リポジトリREADME 2026-09-16閲覧)。単独ベンダーの仕様から、Linux Foundation系のプロジェクトへ器が移っている状態です。
仕様本文は、MCPがLanguage Server Protocol(LSP)から着想を得たと明記しています。LSPが「プログラミング言語への対応をエディタ横断で標準化した」のと同じ形で、MCPは「文脈とツールをAIアプリ横断で標準化する」という位置づけです。ここを押さえると、MCPが何をしないかも見えます。MCPはモデルの重みを変える仕組みではなく、つなぎ先のAPIの中身も決めません。
AI以外のMCPとの切り分け
「MCP」という略語は他分野にもあります。IT資格(Microsoft Certified Professional)、医療の中手指節関節(metacarpophalangeal joint)、日本の除草剤の慣用名(MCPソーダ塩。有効成分名はMCPAナトリウム塩)、電子部品の型番接頭辞(MicrochipのMCP3008など)で同じ3文字が使われます(Microsoft Learn・NCBI Bookshelf(中手指節関節)・石原バイオサイエンス 石原MCPソーダ塩・Microchip MCP3008 2026-09-16閲覧)。本記事が扱うのはAI文脈のModel Context Protocolだけです。別分野のMCPを調べている場合、この記事の内容は当てはまりません。
なぜ2024年11月に出てきたか
初出はAnthropicの2024年11月25日の発表です。同日に公開されたのは、仕様とSDK、Claude Desktopアプリでのローカルサーバー対応、サーバー実装のオープンソースリポジトリ、そしてGoogle Drive・Slack・GitHub・Git・Postgres・Puppeteer向けの既製サーバーでした。発表時点の採用例としてBlockとApolloが挙げられ、開発ツール側ではZed・Replit・Codeium・Sourcegraphの名前が並んでいます(Anthropic『Introducing the Model Context Protocol』 2026-09-16閲覧)。背景は単純です。ツール連携の実装がクライアントごとにばらばらで、同じ連携を各アプリ向けに作り直す必要があったからです。
2. API・関数呼び出し・A2Aと何が違うのか
混同されやすい4つを並べます。比較軸は「何を決めているか」です。
| 観点 | 通常のWeb API | 関数呼び出し(function calling) | MCP | A2A |
|---|---|---|---|---|
| 決めていること | エンドポイントごとの入出力 | モデルへツール定義を渡す形式と応答形式 | ツール・リソースの発見と呼び出しの共通手順 | エージェント同士の連携手順 |
| 通信の相手 | 任意のプログラム | アプリとモデルAPI | ホスト内のクライアントと外部サーバー | エージェントと別のエージェント |
| メッセージ形式 | JSON等が多い(設計・問い合わせの方式としてREST、GraphQL等) | 各モデルAPIの独自形式 | JSON-RPC 2.0 | 仕様がJSON-RPC・gRPC・HTTP+JSON/RESTの各バインディングを定義(2026-10-04確認) |
| ツール定義の出どころ | ドキュメント、OpenAPI等の機械可読な定義 | アプリの実装者が書く | サーバーがtools/listで配る | 対象外 |
| 管理主体 | 提供元ごと | モデル提供元ごと | Model Context Protocol(LF Projects) | Linux Foundation(TSCにAWS・Cisco・Google・IBM Research・Microsoft・Salesforce・SAP・ServiceNow) |
関数呼び出しとMCPは対立しません。モデルAPIのツール機能は「モデルに定義をどう渡し、呼び出し要求をどう受け取るか」を決めます。MCPは「その定義をどこから取ってくるか」を決めます。両方を同時に使うのが普通の構成で、ホストがMCPサーバーから取った定義をモデルAPI用の形に変換して渡し、モデルが要求した呼び出しの実行と結果の返送を仲介します。変換の一例としてキー名が違い、MCPはinputSchema、Claude APIはinput_schemaです。実際にはスキーマの表現差の吸収や、どのツールを許可するかの管理もホスト側の仕事になります。
A2Aは別レイヤーです。公式ドキュメントは「MCPはエージェントとツールの通信、A2Aはエージェント同士の通信」と役割を切り分け、両者は補完関係だと書いています(A2A Protocol 2026-09-16閲覧、原文は英語)。現行バージョンは1.0で、仕様はJSON-RPC・gRPC・HTTP+JSON/RESTのプロトコルバインディングを定義しています(A2A Specification 2026-10-04確認)。「MCPかA2Aか」を選ぶ場面はほとんどなく、ツールを足すならMCP、別のエージェントに仕事を渡すならA2Aという分担です。
3. 一次資料の対応表と、この記事が測っていないこと
MCP自体は推論の方式を決めず、ローカルモデルを使うホストと組み合わせることもできます。ただし本記事は推論性能を測っていないため、GPUとVRAMの数値は記載しません。代わりに主張と一次資料の対応を先に置きます。数値・仕様の記述は2026-09-16に確認したもので、確認日欄に2026-10-04を併記した項目はこの日にも一次資料を取得して確認しました。
| 主張 | 一次資料 | 種別 | 確認日 |
|---|---|---|---|
現行リビジョンは2026-07-28。識別子はYYYY-MM-DDで後方非互換変更の最終日 | MCP Versioning | 公式ドキュメント | 2026-09-16(2026-10-04再確認) |
| 3役はHosts/Clients/Servers、形式はJSON-RPC 2.0、サーバー機能はResources/Prompts/Tools | MCP仕様トップ | 公式ドキュメント | 2026-09-16 |
initializeとnotifications/initializedを削除し、_metaにバージョンと能力を載せる | Key Changes(2026-07-28) | 公式ドキュメント | 2026-09-16 |
| MCPはステートレス。接続は会話でもセッションでもない | Base Protocol | 公式ドキュメント | 2026-09-16 |
io.modelcontextprotocol/protocolVersionとclientCapabilitiesは全リクエスト必須。欠ければ-32602 | 同 _meta | 公式ドキュメント | 2026-09-16 |
非対応バージョンは-32022でsupported配列を返す | Versioning and Compatibility | 公式ドキュメント | 2026-09-16(2026-10-04再確認) |
HTTPではMCP-Protocol-Version・Mcp-Methodヘッダーが全リクエストで必須、tools/call等ではMcp-Nameも必須 | Streamable HTTP | 公式ドキュメント | 2026-10-04 |
input_requiredの結果はinputRequestsかrequestStateの少なくとも一方を含み、再試行は別のJSON-RPC IDで送る | Multi Round-Trip Requests | 公式ドキュメント | 2026-10-04 |
server/discoverはサーバー側に実装義務があり、クライアント側の呼び出しは任意 | Discovery | 公式ドキュメント | 2026-09-16 |
| Roots・Sampling・LoggingはDeprecated。最短削除は2027-07-28以降の最初のリビジョン | Deprecated Features | 公式ドキュメント | 2026-09-16 |
LATEST_PROTOCOL_VERSION = "2026-07-28"、JSONRPC_VERSION = "2.0" | schema/2026-07-28/schema.ts | GitHub | 2026-09-16 |
| LICENSEはMIT→Apache-2.0の移行中でApache-2.0とMITは全文、CC-BY-4.0は外部リンク参照。MITセクションの著作権表記はLF Projects | LICENSE | GitHub | 2026-09-16 |
| 12種の攻撃・2,000攻撃インスタンス、評価したモデルでは性能の高いものほど脆弱と報告 | arXiv:2510.15994 | 論文(v1 2025-10-14/v2 2026-03-24) | 2026-09-16 |
総合指標はNRP = PUA × (1 − ASR)、防御実験の平均値(表4) | arXiv:2510.15994v2 HTML版 | 論文(v2) | 2026-10-04 |
測っていないことも明示します。本記事の執筆セッションはシェルを持たない非対話セッションで、使えたのはファイル読み書きとWeb取得だけです。そのためclaude --versionを取得しておらず、クライアントの正確なバージョンは未確認です。JSON-RPCの通信そのものもキャプチャしていません。後述するJSONは公式仕様のサンプルとschema.tsの型定義から起こしたもので、手元で捕捉したパケットではありません。第11節で出す数字は、このセッションのツール一覧とローカルの設定キャッシュを数えた観測値です。
環境はDGX Spark(GB10・統合メモリ128GB・aarch64)、OSはLinux 6.14系、クライアントはClaude Code(非対話セッション、バージョン未確認)、モデルはClaude Opus 5、前提とする仕様リビジョンは2026-07-28、検証日は2026-09-16です。この環境情報は筆者の執筆時の記録で、端末情報やセッションログは本記事に添付していません。
4. 仕組み(1)3役とJSON-RPC 2.0の中身
役割は3つです。ホストはLLMアプリ本体で接続を開始する側、クライアントはホスト内のコネクタ、サーバーは文脈と機能を提供する側です。サーバー1本につきクライアント1つが対応します。
現行リビジョンでの流れは次のようになります。
- ホストが設定を読み、接続するサーバーごとにクライアントを用意する
- クライアントは必要なら
server/discoverを投げ、対応バージョン・capabilities・自己申告の名前を1往復で受け取る tools/listでツール定義を取得する。結果にはttlMsとcacheScopeが必須で付き、クライアント側でキャッシュできる- ホストがツール定義をモデルへ提示する
- モデルが呼び出しを要求したら、クライアントが
tools/callを投げる - サーバーは
contentを含む結果を返す。通常の結果はresultTypeが"complete" - 処理に追加入力が要る場合は
resultTypeが"input_required"になる。この結果にはinputRequestsとrequestStateの少なくとも一方が含まれる。クライアントは求められた入力に対応するinputResponsesを付け、新しいJSON-RPC IDで元の操作を再試行する。requestStateが返された場合は、中身を解釈・変更せずその値をそのまま返送する(MRTRパターン)
7番が現行リビジョンの特徴です。以前はサーバーからクライアントへsampling/createMessageやelicitation/createを送る形でしたが、2026-07-28ではサーバー起点のリクエストをやめ、「いったん結果として返して、クライアントに再送させる」形に置き換わりました(Key Changes 2026-09-16閲覧)。
公式仕様に沿うJSON-RPC本文の例は次の形です。公式のserver/discoverのサンプルがいちばん短いので、それを引きます。
{
"jsonrpc": "2.0",
"id": "discover-1",
"method": "server/discover",
"params": {
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientInfo": {
"name": "ExampleClient",
"version": "1.0.0"
},
"io.modelcontextprotocol/clientCapabilities": {}
}
}
}
_metaが現行リビジョンの要です。全リクエストで必須なのはio.modelcontextprotocol/protocolVersionとio.modelcontextprotocol/clientCapabilitiesの2つで、欠けていればサーバーは-32602(Invalid params)で拒否し、HTTPでは400を返さなければなりません。
HTTPで送る場合、この本文だけでは完全な通信例になりません。2026-07-28のStreamable HTTPでは、すべてのPOSTにMCP-Protocol-VersionヘッダーとMcp-Methodヘッダーが必要で、tools/call・resources/read・prompts/getではMcp-Nameヘッダーも必要です。ツール定義の引数にx-mcp-headerの指定がある場合は、その値をMcp-Param-{名前}ヘッダーにも写します。ヘッダーと本文の値が一致しない場合、サーバーは400と-32020のエラーで拒否します(Streamable HTTP 2026-10-04確認)。stdioで送る本文例と、HTTPでの送信要件は分けて確認してください。clientInfoは必須ではありませんが、クライアントは原則として毎リクエストに載せるべきとされています。サーバー側は結果の_metaにio.modelcontextprotocol/serverInfoを載せるべきとされ、ただし仕様はclientInfoとserverInfoの両方について「自己申告であり、プロトコルは検証しない」とし、セキュリティ判断に使うべきではない(SHOULD NOT)と注記しています。
バージョンが合わないときの応答も仕様に実物があります。
{
"jsonrpc": "2.0",
"id": 1,
"error": {
"code": -32022,
"message": "Unsupported protocol version",
"data": {
"supported": ["2026-07-28", "2025-11-25"],
"requested": "1900-01-01"
}
}
}
エラーコードは2026-07-28で整理されました。-32000〜-32019は既存実装の既得枠、-32020〜-32099が仕様専用枠です。仕様が定義しているのは-32020(HeaderMismatch)、-32021(MissingRequiredClientCapability)、-32022(UnsupportedProtocolVersion)の3つで、リソース未検出は-32002から-32602へ変わりました。古い版のサーバーが返す-32002はクライアント側で受け付けるべきとされています。
ツール定義の型はschema.tsを見れば一目です。Toolが持つのはdescription(任意)、inputSchema(必須、type: "object")、outputSchema(任意)、annotations(任意)、_meta(任意)で、name(必須)とtitle(任意)はBaseMetadataから、iconsはIconsから継承します。inputSchemaとoutputSchemaはJSON Schema 2020-12のキーワードを広く許すよう緩められました。スキーマには$schemaを書く欄もあり、2020-12は既定の扱いです。ここで重要なのは、このdescriptionがモデルに読ませる自然言語だということです。攻撃面の話は第12節に出てきます。
5. 仕組み(2)リビジョンで変わったところ──ハンドシェイク型と現行2026-07-28
仕様は5つのリビジョンを公開しています(llms.txt で確認、2026-09-16)。現行との差を、バージョン交渉とセッションの持ち方で並べます。
| リビジョン | 状態 | バージョン交渉の方式 | セッションの持ち方 |
|---|---|---|---|
| 2026-07-28 | Current(versioningページに明示) | リクエストごとに_metaで宣言、サーバーがリクエスト単位で受理/拒否 | 持たない(ステートレス。Mcp-Session-Idなし) |
| 2025-11-25 | 過去版(Finalの定義に該当。個別ページの状態表示は未確認) | initializeハンドシェイクで交渉 | initializeによる初期化。HTTPのセッションID発行はサーバーの任意 |
| 2025-06-18 | 同上 | initializeハンドシェイク | 同上 |
| 2025-03-26 | 同上 | initializeハンドシェイク | 同上 |
| 2024-11-05 | 同上 | initializeハンドシェイク | initializeによる初期化(HTTPはHTTP+SSEトランスポート) |
versioningページが状態を明示しているのは現行の2026-07-28だけです。Finalは「変更されない過去の完成した仕様」と定義されているので、残り4つはその定義に当てはまりますが、各リビジョンのページに状態表示のバナーは見当たりませんでした(2026-09-16閲覧)。
仕様は世代に名前を付けています。バージョンと身元と能力をリクエストごとのメタデータで運ぶのがModern(2026-07-28以降)、initializeでセッションを張るのがLegacy(2025-11-25以前)、両方を話せる実装がDual-eraです。互換性の結論は素直ではありません。Modernクライアントに対してLegacyサーバーは失敗し、Legacyクライアントに対してModernサーバーも失敗します。互換マトリクスで片方がDual-eraの組み合わせは「Works」とされていますが、これはDual-era側が相手の世代を判定して話し方を切り替えられる、という意味です(Versioning and Compatibility 2026-10-04確認)。実際につながるかは、双方が共通して対応するリビジョンと通信方式があり、必要な機能と認可の条件を満たすかで決まります。Legacyクライアントには前に進む手段がないため、Modernサーバーはinitializeへのエラー応答の中で対応バージョン名を出すべきとされています。
2026-07-28で入った後方非互換な変更のうち、解説記事の内容に直接効くものを5つ挙げます(出所はすべてKey Changes 2026-09-16閲覧)。
initializeとnotifications/initializedの削除。バージョンと能力は_metaで毎回運ぶ- プロトコルレベルのセッションと
Mcp-Session-Idヘッダの削除。tools/listなどの一覧が接続(セッション)に依存して変わることはなくなった。認可の主体やサーバー側の更新で一覧が変わることはある。複数リクエストにまたがる状態は、サーバーが発行したハンドルを普通のツール引数で渡す server/discoverの追加。サーバーには実装義務があり、クライアント側の呼び出しは任意- HTTPのGETエンドポイントと
resources/subscribeをsubscriptions/listenに置き換え。SSEの再送(Last-Event-ID)も廃止で、ストリームが切れた要求は新しいIDで再発行する ping、logging/setLevel、notifications/roots/list_changedの削除。ログレベルはリクエストごとに_metaで指定する
判別の手掛かりがあります。読んでいる解説がinitialize・Mcp-Session-Id・ping・サーバー起点のsampling/createMessageを現役の仕組みとして説明していれば、それは2025-11-25以前のリビジョンを前提にした説明です。公開日が2026年でも中身が古い場合があるので、この4語で検索すると見当が付きます。ただし比較や移行の説明にもこの4語は出てくるため、語が出てくるだけでリビジョンを断定せず、現役の仕組みとして書かれているかを読んで判断してください。
6. 何を出せるのか──Resources/Prompts/Tools、Elicitation、拡張
サーバーがクライアントへ出せる機能は3種類です。
- Resources: ユーザーまたはモデルが使う文脈とデータ
- Prompts: ユーザー向けの定型メッセージとワークフロー
- Tools: モデルが実行する関数
クライアントがサーバーへ出せる機能は、仕様トップの列挙ではElicitation(サーバー起点でユーザーへ追加情報を求める)だけです。2025-11-25版の同じ位置にはSamplingとRootsも並んでいました。これは消滅ではなくDeprecatedへの移動で、公式のレジストリに一覧があります。
| 機能 | 非推奨になったリビジョン | 移行先 | 最短削除 |
|---|---|---|---|
| Roots | 2026-07-28 | ディレクトリやファイルはツール引数・リソースURI・サーバー設定で渡す | 2027-07-28以降に出る最初のリビジョン |
| Sampling | 2026-07-28 | LLMプロバイダのAPIと直接統合する | 2027-07-28以降に出る最初のリビジョン |
| Logging | 2026-07-28 | stdioではstderrへ、観測性はOpenTelemetry | 2027-07-28以降に出る最初のリビジョン |
| Dynamic Client Registration | 2026-07-28 | Client ID Metadata Documents | 2027-07-28以降に出る最初のリビジョン |
includeContextの"thisServer"/"allServers" | 2025-11-25 | 省略するか"none" | Samplingの削除に連動 |
| HTTP+SSEトランスポート | 2025-03-26 | Streamable HTTP | SEP-2596がFinalになってから3か月後 |
出所はDeprecated Features(2026-07-28)(2026-09-16閲覧)です。ページは、最短削除は削除の期日ではなく「削除の対象になれる時期」であり、実際の削除はリリース準備時のCore Maintainerの判断だと注記しています。Deprecated機能は仕様の一部として動き続けるので、今日壊れるわけではありません。新規実装で採用すべきでない、という意味です。
コアの外に拡張の枠があります。仕様トップが挙げているのは、非同期実行のTasks(io.modelcontextprotocol/tasks)、エージェント向けの構造化された指示を配るSkills over MCP、会話内にUIを描くMCP Apps(io.modelcontextprotocol/ui)です。拡張は必ずオプトインで、capabilitiesのextensionsフィールドで宣言します。
{
"capabilities": {
"tools": {},
"extensions": {
"io.modelcontextprotocol/tasks": {}
}
}
}
片側だけが対応している場合は、対応側がコアの挙動へ戻るか、適切なエラーで拒否しなければなりません。
7. できること・向いている使い方
MCPが効くのは、同じ連携を複数のクライアントで使い回したいときです。1本のサーバーを書けば、共通のリビジョンと通信方式に対応し、認可などの条件を満たすホスト間で再利用できます。拡張やUIを使えるかはホストごとに異なります。逆に言えば、1つのアプリからしか使わない連携をMCP化する利点は薄いです。
具体的に向いている構成は3つです。第一に、ベンダー公式のリモートサーバーを足す形です。GitHub・Notion・Sentry・Stripeなどが自社の公式サーバーを配っており、Claude Codeのドキュメントはこれらを OAuth 2.0 認証を使う公式リモートサーバーとして挙げています(Claude Code MCP 2026-09-16閲覧)。ただし認可の方式はホスト・通信方式・提供元の設定で変わるため、使うサーバーごとに確認してください。第二に、ホスト内蔵の機能と重複しない部分を足す形です。Claude Codeのようにファイル操作やWeb取得を内蔵しているクライアントに同等のサーバーを足すと、同じ仕事のツールが二重に並ぶだけになります。第三に、ttlMsが効くような「一覧が滅多に変わらない」情報源です。現行リビジョンではtools/listの結果にキャッシュ用のttlMsとcacheScopeが必須で付きます。
できないことも同じ粒度で挙げます。
- モデルの重みは変わりません。外部の情報やツールを使えるようになることで、アプリとして対応できる仕事は増えます
- 認可を代行しません。stdioは環境から資格情報を取る前提、HTTPは別枠の認可フレームワークに従う設計です
- 相手が誰かを保証しません。
serverInfoは自己申告で、仕様はセキュリティ判断に使うべきではないとしています - 会話の状態を持ちません。複数リクエストにまたがる状態は、明示的な識別子をクライアントが毎回渡す設計です。接続はセッションではありません
- 往復が増えます。追加入力が必要な処理はMRTRで再送になり、ツール定義の取得にも往復が要ります
8. 代表的な MCP サーバーの例──Playwright、Figma、Chrome DevTools、Blender、Unity、freee、Backlog、Serena
公式サイトの紹介ページも、MCP でできることの例として「Claude Code can generate an entire web app using a Figma design」や、Blender で3Dデザインを作る例を挙げています(What is MCP 2026-10-11確認)。ここでは、よく名前の挙がるサーバーを、公開元のリポジトリで確かめた範囲で並べます。「公開元」は GitHub の所有組織と README の記載から判断しました。第12節で見るとおり、ツールの説明文と応答はそのまま攻撃の入口になります。誰が出しているかの確認が最初の一歩です。
| サーバー | 公開元 | 主に何を出すか | 一次資料 |
|---|---|---|---|
| Playwright MCP | Microsoft(microsoft 組織) | ブラウザ操作。画面画像ではなくアクセシビリティツリーで操作する | microsoft/playwright-mcp |
| Figma MCP サーバー | Figma(figma 組織の公式ガイド) | デザインファイルの変数・コンポーネント・レイアウト情報。リモート版はキャンバスへの書き込みも可 | figma/mcp-server-guide |
| Chrome DevTools MCP | ChromeDevTools 組織。Google の公式サーバー一覧にも掲載 | 実行中の Chrome の操作と検査、性能トレース、ネットワークとコンソールの確認 | ChromeDevTools/chrome-devtools-mcp |
| MCP for Blender(旧 blender-mcp) | コミュニティ(個人)。Blender 公式ではない | Blender の3Dモデリングとシーン操作 | ahujasid/mcp-for-blender |
| MCP for Unity | コミュニティ(Coplay の CoplayDev 組織)。Unity Technologies とは無関係 | Unity エディタのアセット・シーン・スクリプト・テスト | CoplayDev/unity-mcp |
| freee-mcp | freee(README に「freee 公式」と明記) | 会計・人事労務・請求書など freee の API 群 | freee/freee-mcp |
| Backlog MCP Server | nulab 組織(組織名 Nulab Inc) | プロジェクト・課題・Wiki・Git リポジトリ・通知 | nulab/backlog-mcp-server |
| Serena | oraios 組織(組織名 Oraios AI)の OSS。特定の SaaS の公式サーバーではない | シンボル単位のコード検索・編集・リファクタリング | oraios/serena |
いずれも2026-10-11確認です。表に入りきらない注意点を、サーバーごとに1〜2行で補います。
- Playwright MCP。 Microsoft 自身が README で、コーディングエージェントには CLI と Skills の組み合わせの方が向く場合があると書いています。理由は「CLI invocations are more token-efficient」で、大きなツール定義やアクセシビリティツリーをコンテキストに載せずに済むからです。MCP は、ブラウザの状態を持ち続ける探索的な自動化などに向くとしています
- Figma。 リモートサーバーの URL は
https://mcp.figma.com/mcpです。プランと席種によって呼び出し回数の上限が変わります(第9節) - Chrome DevTools MCP。 README の注意書きは、ブラウザの中身を MCP クライアントに見せて、データの検査や変更を許す仕組みだと明記しています。Google が使用統計を集めることも書かれています。Google の公式サーバー一覧(後述の FAQ)にも載っています
- Blender と Unity。 どちらも README で公式ではないと断っています。Blender 版は「Disclaimer: This is a third-party integration and not made by Blender」、Unity 版は「not affiliated with Unity Technologies」です。ライセンスはどちらも MIT です
- freee。 推奨はローカル導入不要のリモート接続(
https://mcp.freee.co.jp/mcp)で、認証は OAuth 2.0 + PKCE です。freee サイン(電子契約)は、2026-10-11時点ではリモート提供が準備中で、ローカル起動のみです - Backlog。 Docker と Backlog の API キーで動かします。HTTP で動かす場合について、README は対応プロトコルを
2026-07-28と書き、initializeが無いステートレスな動作と、2025-11-25 以前のクライアントにも同じエンドポイントで応じることを説明しています - Serena。 ライセンスは GPL-3.0-or-later です。言語サーバー(LSP)を使う構成のほかに、有料の JetBrains プラグインを使う構成があります
公式の参照実装と、一覧の探し方
MCP の運営側が配っているサーバーもあります。modelcontextprotocol/servers にある参照実装は Everything・Fetch・Filesystem・Git・Memory・Sequential Thinking・Time の7本です(2026-10-11確認)。ただし README は、これらを「reference implementations」と位置づけ、本番向けではないと明記しています。以前ここにあった GitHub や Slack などのサーバーはアーカイブ済みです。公開されたサーバーを探すときは、同じ README が案内する MCP Registry を使います。
サーバーを書くなら:FastMCP は SDK 側の選択肢
FastMCP はサーバーではなく、サーバーやクライアントを Python で書くためのフレームワークです。Prefect が開発しており、README は「FastMCP 1.0 was incorporated into the official MCP Python SDK in 2024」と書いています(PrefectHQ/fastmcp 2026-10-11確認)。関数に @mcp.tool を付けるだけでツールとして公開できます。公式 SDK は、servers リポジトリの README の時点で C#・Go・Java・Kotlin・PHP・Python・Ruby・Rust・Swift・TypeScript の10言語分があります。どれを使う場合も、2026-07-28 リビジョンへの対応状況は第13節のとおり各 SDK のドキュメントで確認してください。
9. MCP サーバーの料金──プロトコルは無料、課金は接続先のサービス側
MCP そのものに利用料はかかりません。公式サイトは MCP を「an open-source standard for connecting AI applications to external systems」と定義しています(What is MCP 2026-10-11確認)。仕様のリポジトリは MIT License から Apache License 2.0 へ移行中で、新しい仕様への貢献は Apache-2.0 で公開されると LICENSE に書かれています(modelcontextprotocol/modelcontextprotocol LICENSE 2026-10-11確認)。第8節で挙げたサーバーのうち、Figma(公式リポジトリはガイドのみ)を除く7本も、ソースが Apache-2.0・MIT・GPL-3.0-or-later のいずれかで公開されています。
お金がかかるのは、次の3か所です。
1. 接続先のサービス。 MCP サーバーは既存サービスの API への入口なので、そのサービスの契約に従います。Figma の公式ガイドは、Starter プランの利用者と、有料プランの View・Collab 席の利用者について、ツール呼び出しを月6回までとしています。Professional・Organization・Enterprise プランの Dev 席か Full 席では、REST API の Tier 1 と同じ分単位の上限です。キャンバスへの書き込みは、ベータ期間中は無料で、将来は「usage-based paid feature」になる予定と書かれています(figma/mcp-server-guide 2026-10-11確認)。freee は、サーベイ・開業・人事評価・申告の API に、対応する契約プランや利用者権限が必要としています。Backlog は「A Backlog account with API access」が前提です。Serena も JetBrains プラグインを使う構成は有料です。
2. クライアント。 MCP サーバーを呼ぶアプリの料金です。Claude Code の場合、料金ページのプラン比較表で Free プランの Claude Code 欄は「No」で、FAQ は「Claude Code is included in all paid plans」としています。サブスクリプションの代わりに、Console アカウントの API クレジットによる従量課金も選べます(Claude 料金プラン 2026-10-11確認)。
3. トークン。 ツール定義と応答はモデルのコンテキストに入ります。Claude Code は、MCP ツールの出力が10,000トークンを超えると警告を出し、既定では25,000トークンで打ち切ります。上限は MAX_MCP_OUTPUT_TOKENS で変えられます(Claude Code MCP 2026-10-11確認)。従量課金で使っていれば、この分がそのまま請求額に響きます。ツール定義の数え方はMCPサーバーの選び方の記事で扱っています。
「無料の MCP サーバー」は、ソースが無料で手に入るという意味では多数あります。ただ、つないだ先のサービスが有料なら、そちらの料金はかかります。Google などが運営するマネージド型のリモートサーバーの料金は、この記事では確認していません。使う製品の料金ページで確かめてください。
10. Claude Code と MCP──接続方法と使いどころ
Claude Code は MCP のホスト(クライアント)として動くアプリの1つです。Claude Code 自体の全体像はClaude Codeとは の記事で扱っています。ここでは公式ドキュメント(Claude Code MCP 2026-10-11確認)から、接続の手順だけを抜き出します。
サーバーは claude mcp add で足します。リモートのサーバーは HTTP 方式が推奨で、公式は「the most widely supported transport for cloud-based services」と説明しています。ローカルで動かすサーバーは stdio 方式です。stdio では -- の後ろにサーバーの起動コマンドを書きます。
# remote server over HTTP
claude mcp add --transport http figma https://mcp.figma.com/mcp
# local stdio server: everything after -- is the launch command
claude mcp add playwright -- npx @playwright/mcp@latest
claude mcp list
設定の保存先は、スコープで3つに分かれます。
| スコープ | 読み込まれる範囲 | チームと共有 | 保存先 |
|---|---|---|---|
| local(既定) | 今のプロジェクトだけ | しない | ~/.claude.json |
| project | 今のプロジェクトだけ | する(バージョン管理経由) | プロジェクト直下の .mcp.json |
| user | 自分のすべてのプロジェクト | しない | ~/.claude.json |
同じサーバーが複数の場所にあるときは、local・project・user・プラグイン・claude.ai のコネクタの順に優先されます。資格情報を含む設定は、公式の案内どおり local に置き、.mcp.json には入れないのが安全です。.mcp.json のサーバーは、対話セッションでは使う前に承認を求められます。一方、claude -p などの非対話の実行では、確認なしで読み込まれます。リポジトリを他人と共有するなら、ここは押さえておく必要があります。
他のクライアント向けに書かれた手順しかないサーバーも、そのまま足せます。公式は、URL があれば HTTP、npx などの起動コマンドがあれば stdio、mcpServers の JSON があれば claude mcp add-json を使うと案内しています。追加後の状態はセッション内の /mcp で確認できます。
使いどころとして、公式は課題管理ツールの内容から機能を実装する、監視データを分析する、データベースに問い合わせる、Figma のデザインを反映する、Gmail の下書きを作る、といった例を挙げています。第7節のとおり、Claude Code がもともと持つファイル操作や Web 取得と重なるサーバーは足しても意味が薄いです。
11. 実測:このセッションのMCP接続で観測できたこと
シェルが無いためJSONのバイト数とトークン数は測れませんでした。代わりに、このセッションで数えられた2つを出します。どちらも2026-09-16の執筆セッションについての筆者の観測記録で、当時のツール一覧と認可キャッシュの原本は本記事に添付していません。
| 観測項目 | 値 | 測り方 | 測定日 |
|---|---|---|---|
| claude.ai Notionコネクタのツール本数 | 44 | セッション開始時に提示された遅延ツール名をサーバー別に数えた | 2026-09-16 |
| claude.ai Gmailコネクタのツール本数 | 29 | 同上 | 2026-09-16 |
| claude.ai Google Driveコネクタのツール本数 | 11 | 同上 | 2026-09-16 |
| claude.ai Google Calendarコネクタのツール本数 | 9 | 同上 | 2026-09-16 |
| クライアント側のMCPリソース用ツール | 3 | 同上 | 2026-09-16 |
| 提示されたMCP関連ツールの合計 | 96 | 上記の合計(4コネクタの合計93本+クライアント側3本) | 2026-09-16 |
| 認可待ちとして記録されていたサーバー | 10エントリ | ~/.claude/mcp-needs-auth-cache.jsonのキー数 | 2026-09-16 |
読み取れることが2つあります。
第一に、ツール定義の本数は自分で設定を触らなくても動きます。同じ環境で2日前(2026-09-14)に数えたときNotionコネクタは43本で、合計は95本でした(いずれも筆者の観測記録)(MCPサーバーの選び方の記事を参照)。今日は44本・合計96本です。ホスト側が管理するコネクタは、.mcp.jsonを1行も書いていなくてもツール集合が変わります。何本まで入れるべきかという本数設計とトークンの数え方は、その記事で扱っているので本記事では再掲しません。
第二に、「つながっている」と「使える」は別です。認可キャッシュにはclaude.ai ラッコキーワードが2エントリ記録されており、タイムスタンプは1789510174861(2026-09-16 07:09 JST)と1789519051208(同日09:37 JST)です。このサーバーは設定上は存在しましたが、当時のセッションのツール一覧には1本も出ておらず、認可待ちの記録もありました。ただしキャッシュの10エントリは10の異なるサーバーを意味せず、キャッシュだけで現在の認可状態やツールが出なかった原因を断定することもできません。
なお筆者の記録では、このセッションのツール定義は名前だけ提示され、引数スキーマは必要になった時点で読み込む方式でした。したがって上の96本の定義がそのままコンテキストに載っていたわけではありません。
12. 限界・リスク・向かない場面
仕様自身がセキュリティ原則を3本立てています。ユーザーの同意と制御、データのプライバシー、そしてツールの安全性です。3つ目の書き方が重要で、仕様は「ツールは任意コード実行を表すものとして扱え」「ツールの挙動を説明する注釈は、信頼できるサーバーから得たものでなければ信頼できないものとして扱え」と明記しています(MCP仕様 2026-09-16閲覧、原文は英語)。信頼できないサーバーが自称する「これは読み取り専用です」を安全性の保証にしてはいけない、ということです。
この懸念は測られています。MCP Security Bench(MSB)は、MCP経由で実際に良性・悪性のツールを実行して耐性を測るベンチマークで、12種類の攻撃分類と2,000の攻撃インスタンスを10ドメインにわたって構成しています(arXiv:2510.15994、v1が2025-10-14投稿、v2が2026-03-24改訂、2026-09-16閲覧)。攻撃ベクトルはツール名、ツールの説明文、パラメータ、そしてツールの応答です。つまり第4節で見たdescriptionや返却値が、そのまま攻撃の入口になります。
論文が報告している主張のうち、導入判断に効くのは2点です。1つは、評価したモデルと攻撃条件の範囲で、性能の高いモデルほど攻撃に脆弱だという逆スケーリングの傾向です。論文はその理由を、ツール呼び出しと指示追従の能力の高さに求めています。すべてのモデルや実運用環境に当てはまる一般則として示されたものではありません。もう1つは、評価した検出ベースの防御を足しても総合的な改善が小さいことです。v2の表4では、防御の適用で平均の攻撃成功率(ASR)は40.35%から28.69%へ11.66ポイント下がりました。一方で攻撃下のタスク完了率(PUA)も56.50%から48.91%へ7.59ポイント下がり、総合指標NRPは33.70%から34.88%へ1.18ポイントの改善にとどまりました(arXiv:2510.15994v2 2026-10-04確認)。NRPはNRP = PUA × (1 − ASR)と定義され、PUAに「攻撃が成功しない割合」を掛けた値で、ASRとPUAの単純な積ではありません。表4の平均値で計算すると56.50%×(1−0.4035)≈33.70%、48.91%×(1−0.2869)≈34.88%で、掲載値と一致します。過剰拒否で機能が落ちる分が相殺しています。この評価は2026-07-28仕様の実装自体を検証したものではありません。
数値の扱いには留保が2つあります。arXivの概要ページのabstractは評価対象を9つのLLMエージェントと書いていますが、v2のHTML版ではabstractが10、実験設定の節も10モデルを挙げる一方、導入部には「9 popular LLM backbones」という表記が残っています(2026-10-04確認)。著者側の記載が揃っていないため、本記事は評価対象の数を一意に断定せず、モデル別の内訳も引用しません。採択状況は、absページのComments欄にある「Accepted by ICLR 2026」という記載に基づきます(arXiv:2510.15994 2026-09-16閲覧)。
仕様の範囲外のリスクも1つ挙げます。第三者製サーバーをnpxで起動する構成は、パッケージ供給側が侵害されたときにローカルで任意のコードが走る経路になります。2026年8月4日のkeyv侵害について、Datadog Security Labsの調査は、リポジトリに.claude/settings.json(SessionStartフック)と.vscode/tasks.json(フォルダを開いたときに実行)を加える挙動を報告しています。同調査によれば、[email protected]は正規のリリースワークフローでビルドされ、本物のSLSA provenance(来歴証明)が付いたまま悪意あるコードを含んでいました。provenanceは「どのソースとワークフローから作られたか」の証明で、中身の安全性を保証するものではありません。また、ほかの多くの伝播経路ではprovenanceは付いていませんでした(Datadog Security Labsの調査 2026-10-04確認、経緯はnpm keyv乗っ取りの記事)。バージョン固定とコンテナ化の手間は、ここでは見合います。ただし、それだけで安全が保証されるわけではありません。
向かない場面もはっきりしています。1回しか使わない連携、社内APIを1本叩くだけのスクリプト、往復のレイテンシが厳しい経路です。こうした場面では、直接APIを呼ぶ方が構成が単純になり、監査もしやすくなる場合があります。
13. 始め方(最小構成1本から)
クライアント本体の導入が済んでいない場合は、先にClaude Codeの使い方の記事を通してください。MCPの追加はその後です。
手順は4つです。
- すでに有効なコネクタを確認する。第11節のとおり、設定ファイルを書いていなくてもツールが数十本ある場合があります
- サーバーを1本だけ足す。ローカルで動かすならstdio、リモートのエンドポイントならHTTPです
- そのサーバーが出すツールの本数を数える。増えた分が、モデルに見せる選択肢の増分です
- ツール単位で権限を絞る。実行前の承認と、モデルに見せる前の除外は別の設定です
# add one stdio server at project scope, then list what is connected
claude mcp add --scope project --transport stdio memory \
-- npx -y @modelcontextprotocol/server-memory
claude mcp list
自分でサーバーやクライアントを書く場合は、選んだSDKの版が2026-07-28に対応しているかと、必須の_metaをどう設定するかをSDKのドキュメントで確認してください。手で組むならio.modelcontextprotocol/protocolVersionとio.modelcontextprotocol/clientCapabilitiesを毎リクエストに載せてください。落とせば-32602で弾かれます。HTTPでは前述のヘッダーも必要です。仕様を読む順序は、仕様トップ→Base Protocolの_meta→Versioning and Compatibility→Key Changesの4本が最短です。どのクライアントがMCPを扱えるかはClaude Code・Codex CLI・Gemini CLIの比較記事で扱っています。
14. よくある質問
MCPは何の略ですか
Model Context Protocolの略です。AI以外の分野にも同じ略語があり、IT資格(Microsoft Certified Professional)・医療の中手指節関節・日本の除草剤の慣用名(MCPソーダ塩)・電子部品の型番接頭辞などで使われます。AI文脈で語られるMCPは本記事のプロトコルです。
2024-11-05版のサンプルコードは今も動きますか
相手次第です。現行リビジョンだけを実装したサーバーに対してinitializeを送るクライアントは失敗します。仕様の互換マトリクスは、Legacyクライアント×Modernサーバーの組み合わせを明確に「Fails」としています。両方を話せるDual-era実装が相手なら、マトリクス上は「Works」です。ただし実際につながるかは、共通して対応するリビジョンと通信方式、必要な機能と認可の条件がそろうかで決まります。古い手順で書かれたコードを動かしたい場合は、まず接続先がどちらの世代かを確かめてください。
SamplingとRootsは使えなくなったのですか
使えます。ただし2026-07-28でDeprecatedになり、最短で2027-07-28以降に出る最初のリビジョンで削除の対象になります。新規実装では採用せず、Rootsはツール引数やリソースURIで、SamplingはLLMプロバイダのAPIとの直接統合で置き換えるのが公式の案内です。
MCPサーバーは何本まで入れていいですか
サーバー本数ではなく、モデルに同時に見えるツールの本数で考えます。1本で40本超のツールを出すサーバーがあるため、サーバー単位の議論は成立しません。具体的な上限の決め方と数え方はMCPサーバーの選び方の記事にまとめています。
入れると危なくないのですか
危険はツールの説明文と応答に入ります。仕様はツールを任意コード実行として扱い、信頼できるサーバーから得たものでない限りツール注釈を信頼しないよう求めています。注釈を安全性の保証として使わず、実際の権限と実装を確認してください。最低限の確認は、サーバーの配布元、権限をツール単位で絞れるか、起動経路(npxかコンテナか)、そして実行前の承認が働くかの4点です。
無料の MCP サーバーはありますか
あります。プロトコル自体はオープンソースの標準で、利用料はかかりません。公式の参照実装(Fetch・Filesystem・Git・Memory など)や、第8節で挙げたサーバーの多くはソースが公開されています。ただし参照実装は本番向けではないと明記されています。また、つないだ先のサービスやクライアントには料金がかかる場合があります。詳しくは第9節を参照してください。
MCP の設定方法は
使うクライアントのドキュメントに従います。MCP サーバーの設定は、クライアントごとに書き方が違うからです。Claude Code なら、リモートのサーバーは claude mcp add --transport http <名前> <URL>、ローカルのサーバーは claude mcp add <名前> -- <起動コマンド> で足します。既定の保存先は自分だけが使う local スコープで、チームで共有するなら --scope project を付けて .mcp.json に書き出します。手順の全体は第10節と第13節にまとめています。
Google の MCP 公式はありますか
あります。Google の GitHub 組織にある google/mcp は、自らを「a list of Google’s official Model Context Protocol (MCP) servers」と説明しています(2026-10-11確認)。Google が管理するリモートサーバーとして BigQuery・Cloud Run・Cloud Storage・Google Maps(Grounding Lite)などを、オープンソースのサーバーとして Google Workspace・Firebase・Google Analytics・Chrome DevTools などを挙げています。全体の一覧は、同じ README が案内する Google Cloud のサポート対象製品ページにあるとされています。なお、この google/mcp リポジトリ自体は、README で「This is not an officially supported Google product」と断っています。
「MCP 資格は廃止された」と検索されるのはなぜですか
AI の MCP とは別の話です。最初の質問で触れたとおり、Microsoft Certified Professional という IT 資格も MCP と略されます。「MCP 資格」の検索は、その資格についてのものと考えられます。資格制度の現状はこの記事では確認していないので、Microsoft の公式情報で確かめてください。
15. まとめ
- MCPとは、AIアプリを外部のデータとツールへつなぐオープンなプロトコルです。標準化されているのはJSON-RPC 2.0のメッセージ形式、3役の分担、サーバー機能の種類、バージョンの宣言方法です
- 現行リビジョンは2026-07-28で、
initializeハンドシェイクとセッションIDを廃止しステートレスになりました。バージョンと能力はリクエストごとに_metaで運び、非対応のバージョンは-32022で返ります。HTTPでは必須ヘッダーも付けます - 読んでいる解説がどの版の話かは、
initialize・Mcp-Session-Id・ping・サーバー起点のsampling/createMessageを現役の仕組みとして書いているかが手掛かりになります - RootsとSamplingとLoggingはDeprecatedで、最短削除は2027-07-28以降の最初のリビジョンです。今日動いていることと、新規実装で採用してよいことは別です
- リスクはツールの説明文と応答に入ります。仕様は信頼できるサーバー以外のツール注釈を信頼しないよう求め、MSB(arXiv記載でICLR 2026採択)は評価したモデルの範囲で性能の高いモデルほど脆弱だという傾向を報告しています。導入は1本ずつ、権限を絞って始めてください
16. 関連記事
- MCPサーバーの選び方と候補一覧──登録した本数と実際に載るツール定義を分けて数える:本記事が「MCPとは何か」を扱うのに対し、あちらは「どのサーバーを何本入れるか」と、そのトークンコストの数え方を扱っています。
- Claude Codeとは──モデルではなくモデルを動かすハーネスで、入口は5つ、実行環境の区分は3つ:第10節で MCP サーバーをつないだクライアント、Claude Code 自体の全体像です。
- Claude Code の使い方──インストールからCLAUDE.md 1本まで:MCPを足す前のクライアント側のセットアップはこちらから。
- keyv乗っ取りで
.claude/settings.jsonにフックが仕込まれた4時間:第12節で触れた、設定ファイルとnpx経由で外部コードが入る実例です。