MCP（Model Context Protocol）とは、AIモデルと外部のツールやデータを標準化された方法でつなぐオープンなプロトコルです。2024年11月にAnthropicが公開し、現在は数多くのAIクライアントとサーバーが対応しています。結論から言えば、MCPはAIアプリごとにバラバラだった連携方式を「1つの共通規格」へ置き換える仕組みであり、ツールを実際に触る開発者にとっては避けて通れない土台になりました。この記事では、仕組み・3つのプリミティブ・プロトコルの流れ・Claude Codeでの接続手順までを、正確なメソッド名とともに整理します。

この記事の要点

  • MCPはAnthropicが策定したオープンプロトコルで、AIと外部ツールの接続を「N×M」から「1対多」の共通規格へ標準化します。
  • 通信はJSON-RPC 2.0を土台にし、データ層（Tools／Resources／Prompts）とトランスポート層（stdio／Streamable HTTP）の2層で整理できます。
  • Claude Codeでは /mcp コマンドでサーバーへ接続・確認でき、公式リファレンスサーバーや国内特化サーバーもそのまま利用できます。

01 MCPとは？何ができる仕組みか

MCP（Model Context Protocol）とは、AIモデルが外部のツールやデータソースへアクセスするための共通インターフェースを定めたオープンプロトコルです。Anthropicが2024年11月に公開し、公式ドキュメントでは「AIアプリケーションのためのUSB-C端子」と表現されています。周辺機器がUSB-Cという1つの規格で多様な機器につながるように、MCPはAIアプリと外部システムを1つの規格でつなぎます。

MCPを一言でいうと？

一言でいえば、MCPは「AIに外部の道具と情報を渡すための標準の差し込み口」です。従来はAIアプリごとに独自の連携コードを書く必要がありましたが、MCPに対応すれば同じサーバーを複数のAIクライアントから使い回せます。

MCPで具体的に何ができますか？

具体的には、AIがファイルを読む、データベースへ問い合わせる、外部APIを呼び出す、社内ナレッジを検索する、といった操作を統一された手順で実行できます。編集部が公式リファレンス実装を確認したところ、ファイルシステム、Git、外部検索などのサーバーが用意されており、いずれも同じMCPの規約に沿って動作していました。

MCPは「AI」と「外部世界」の共通の差し込み口
AIアプリ
（ホスト）
MCP
共通規格
ファイル／DB
外部API
社内ナレッジ
FIG.01 MCPはAIアプリと多様な外部リソースを1つの規格で仲介する

02 なぜMCPが必要なのか？N×M問題を解く

MCPが必要とされる最大の理由は、AIモデルと外部ツールの組み合わせが爆発的に増える「N×M問題」を解決するためです。M種類のAIアプリとN種類のツールを個別につなぐと、最大でM×N本の連携コードが必要になり、保守が現実的でなくなります。

N×M問題とは何ですか？

N×M問題とは、AIアプリとツールを1対1でつなぐと接続の数が掛け算で増えてしまう課題を指します。MCPはこの間に共通規格を1枚はさむことで、各アプリと各ツールが「MCPに対応する」だけで済むようにし、接続の数を足し算（M＋N）へ減らします。

MCPなし（M×N本）
アプリA ─ ツール1
アプリA ─ ツール2
アプリB ─ ツール1
アプリB ─ ツール2
…組み合わせだけ配線
MCPあり（M＋N本）
アプリA ─┐
アプリB ─┼─ MCP ─┬─ ツール1
　　　　　└─────┴─ ツール2
…各自が規格に1本だけ
FIG.02 個別配線（左）を共通規格（右）へ置き換えて接続数を削減する

03 MCPの全体像：ホスト・クライアント・サーバー

MCPは3つの登場人物で構成されます。ユーザーが操作するAIアプリである「ホスト」、ホストの内部でサーバーと1対1で通信する「クライアント」、そして機能を提供する「サーバー」です。この役割分担を押さえると、後半の技術的な説明が読み解きやすくなります。

ホスト・クライアント・サーバーはどう違いますか？

ホストはClaude DesktopやClaude CodeのようなAIアプリ本体で、複数のクライアントを束ねます。クライアントはホストの内部にあり、1つのサーバーとだけ接続を保つ通信担当です。サーバーはファイル操作やデータ取得といった具体的な機能を外部に公開する提供者を指します。

つまり、ホストが1つのクライアントを起動し、そのクライアントが1つのサーバーへつながる、という1対1の接続がサーバーの数だけ並ぶ構造です。編集部が公式仕様を確認したところ、この分離によって各サーバーの権限や不具合を互いに切り離せる設計になっていました。

04 MCPは2層でできている：データ層とトランスポート層

MCPを正確に理解する鍵は、「何を伝えるか（データ層）」と「どうやって伝えるか（トランスポート層）」を分けて考えることです。多くの日本語解説はこの層分けが曖昧ですが、公式仕様は明確に2層で整理しています。

JSON-RPC 2.0とは？

JSON-RPC 2.0とは、JSON形式で「どのメソッドを、どの引数で呼ぶか」を表現するリモート呼び出しの規格です。MCPのデータ層はこのJSON-RPC 2.0の上に構築され、tools/list や tools/call といったメソッド名でやり取りします。リクエストとレスポンス、そして応答を求めない通知（notification）の3種類のメッセージが流れます。

stdioとStreamable HTTPはどう使い分けますか？

トランスポート層は、そのJSON-RPCメッセージを実際に運ぶ経路を担当します。ローカルで動かすサーバーには標準入出力を使う「stdio」を、ネットワーク越しのリモートサーバーには「Streamable HTTP」を使うのが基本です。以前はServer-Sent Events（SSE）を用いる方式が中心でしたが、現在の仕様ではStreamable HTTPへ整理されています。手元のツールを呼ぶならstdio、共有サービスとして公開するならHTTP、と覚えると迷いません。

データ層（何を伝えるか）
JSON-RPC 2.0 ／ Tools・Resources・Prompts ／ ライフサイクル管理
▲ この上でメッセージを定義
トランスポート層（どう伝えるか）
stdio（ローカル） ／ Streamable HTTP（リモート）
FIG.03 MCPはデータ層とトランスポート層の2層で整理できる

05 サーバー側の3プリミティブ：Tools・Resources・Prompts

MCPサーバーが提供する機能は、3つのプリミティブ（基本要素）に分類されます。AIが「実行する」Tools、「読み込む」Resources、「型として使う」Promptsです。この3つを理解すれば、どんなサーバーでも中身を把握できます。

Toolsは、AIが呼び出して副作用のある処理を実行する関数です。ファイルの書き込みやAPI呼び出しなど、モデルが能動的に使う操作を指します。Resourcesは、ファイルの中身やデータベースのレコードなど、AIが文脈として読み込む読み取り専用のデータです。Promptsは、あらかじめ用意された定型のやり取りのテンプレートで、ユーザーがスラッシュコマンドのように呼び出せます。

06 クライアント側プリミティブ：Sampling・Elicitation・Logging

ここが多くの日本語記事で手薄になる差別化ポイントです。MCPはサーバー側の3プリミティブだけでなく、クライアント側にも「Sampling」「Elicitation」「Logging」というプリミティブを持ちます。これはサーバーがホスト（AI側）へ逆に要求を出せる仕組みです。

Samplingとは何ですか？

Samplingとは、サーバーがホスト経由でLLMの推論（補完）を要求できる仕組みで、メソッド名は sampling/createMessage です。サーバー自身がAPIキーを持たなくても、ホスト側のモデルを借りて「この内容を要約して」といった生成処理を挟めます。Elicitationは elicitation/create でユーザーへの追加入力を求める仕組み、Loggingはサーバーからホストへログを送る仕組みです。これらにより、サーバーは一方的に呼ばれるだけの存在ではなく、対話に踏み込んだ振る舞いができます。

07 MCPの通信の流れ：initializeからtools/callまで

実際の通信は、接続の初期化から始まり、ツールの発見、実行、動的な更新という順序で進みます。正確なメソッド名で流れを追うと、ログを読むときに何が起きているか判断できます。

まずクライアントが initialize を送り、互いに対応機能を確認し合う「capability negotiation（能力ネゴシエーション）」を行います。合意후にクライアントは notifications/initialized を送って準備完了を通知します。次に tools/list で利用可能なツール一覧を取得し、AIが使うツールを決めたら tools/call で実行します。リソースを読むなら resources/read を使います。

ツールが実行中に増減するのはなぜですか？

MCPは通知メッセージによって、稼働中でもツール一覧を動的に更新できるからです。サーバーがツールを追加・削除すると notifications/tools/list_changed を送り、クライアントは tools/list を再取得します。これにより、状況に応じて使える道具が増減する柔軟な連携が実現します。

クライアントサーバー
1. initialize ─────────▶ 能力を交換
2. ◀───────── 対応機能を返答
3. notifications/initialized ─▶ 準備完了
4. tools/list ────────▶ 一覧を要求
5. ◀───────── ツール一覧を返す
6. tools/call ────────▶ 実行
7. ◀───── notifications/tools/list_changed（動的更新）
FIG.04 初期化から実行・動的更新までのプロトコルの流れ

08 MCPと従来のAPI・Function Callingの違い

MCPは「Function Callingを置き換えるもの」ではなく、Function Callingやツール実行を標準化して束ねる上位のプロトコルです。従来のAPI直叩きやアプリ固有のFunction Callingと比べると、標準化と再利用性で違いが際立ちます。

観点 MCP 従来のAPI直叩き Function Calling（単体）
接続の考え方 共通規格を1枚はさむ ツールごとに個別実装 アプリ内に関数を都度定義
ツールの発見 tools/listで自動発見 ドキュメントを人が読む コードに手書きで登録
実行中の増減 通知で動的に更新 基本は固定 基本は固定
再利用性 複数クライアントで共有 アプリごとに作り直し そのアプリに閉じる
クライアント側要求 Sampling等で双方向 片方向 片方向

要するに、Function CallingがAIに「関数を呼ぶ能力」を与える仕組みであるのに対し、MCPはその関数群を「どのアプリからでも同じ手順で使えるサーバー」として外部に切り出す仕組みだと整理できます。

09 MCPの活用事例・ユースケース

MCPは実際にツールを触る現場で幅広く使われています。代表的なのは、エディタやIDEとの連携、社内ナレッジ検索、監視・SRE、データ分析の4領域です。

代表的な4つのユースケース

IDE連携では、AIがコードベースやGitの履歴を読み、変更を提案します。社内ナレッジ検索では、ドキュメント基盤をResourcesとして公開し、AIが根拠つきで回答できます。監視・SREでは、メトリクスやログをToolsとして呼び出し、障害調査を支援します。データ分析では、データベースへ問い合わせるサーバーを通じて、自然言語から集計を実行できます。いずれも「AIに社内の道具と情報を安全に渡す」という一点で共通しています。

10 MCPサーバーの種類と代表例

MCPサーバーは、動く場所によってローカルサーバーとリモートサーバーに大別されます。手元のPCでstdio経由で動くものがローカル、ネットワーク越しにHTTPで提供されるものがリモートです。

公式リファレンスサーバーには何がありますか？

公式リファレンス実装として、ファイルシステム、Git、Fetch（Web取得）、Memory（永続メモリ）などが公開されており、いずれもMCPの規約に沿った動作の見本になります。まず動きを確かめたい場合は、これらのリファレンスサーバーを起点にするのが確実です。

国内サービスに特化したサーバーも登場しています。日本語圏の業務でそのまま使えるサーバーの選び方と具体例は、日本特化MCPサーバー6選で個別に整理しているので、国内ツールと連携したい方はあわせて確認してください。開発中のデバッグには、公式の検証ツールであるMCP Inspectorを使うと、tools/listの結果や実際のやり取りを手元で確認できます。

11 MCPの使い方：Claude Codeの/mcpで接続する

読者が実際に触る手順として、Claude Codeでの接続を紹介します。Claude Codeでは /mcp コマンドで、接続済みサーバーの状態を確認できます。

基本の流れは3ステップです。第一に、使いたいMCPサーバーを設定ファイルまたは claude mcp add コマンドで登録します。第二に、Claude Codeを起動し /mcp を実行すると、登録したサーバーの接続状態と、公開されているツール一覧が表示されます。第三に、通常どおりAIに依頼すると、Claude Codeが必要に応じてそのサーバーのツールを tools/call で呼び出します。接続がうまくいかないときは、まず /mcp の表示でサーバーが「connected」になっているかを確認するのが近道です。Claude Code側の詳しい設定手順は、Claude CodeのMCP設定の解説（Claude CodeのMCP設定）で扱います。

12 MCPのセキュリティと注意点

MCPはAIに強い実行権限を渡すため、セキュリティ設計は必須です。特に権限の最小化、認可（OAuth）、プロンプトインジェクションの3点に注意します。

権限の最小化と認可（OAuth）の要点

まず、サーバーには必要最小限の権限だけを与え、ファイルの書き込みや外部送信のような副作用の大きいツールは慎重に扱います。リモートサーバーへ接続する場合は、OAuthなどの認可を通じてアクセスを制御します。

プロンプトインジェクションは防げますか？

完全に防げるとは言い切れないため、多層の対策が前提になります。外部から読み込んだResourcesやツールの応答に悪意ある指示が混入する可能性があるため、信頼できないサーバーは接続しない、実行前にユーザーが承認する、といった運用が重要です。編集部が公式ドキュメントを確認したところ、ツール実行時にユーザーの明示的な承認を挟む設計が推奨されていました。

よくある質問

Q. MCPとFunction Callingは何が違いますか？

A. Function CallingはAIに関数を呼ぶ能力を与える仕組みで、通常はアプリ内に閉じています。MCPはその関数群を独立したサーバーとして切り出し、どのAIクライアントからも同じ手順で使えるよう標準化する上位のプロトコルです。両者は対立せず、MCPがFunction Callingを束ねる関係にあります。

Q. MCPサーバーは自分で作れますか？

A. 作れます。公式SDK（TypeScriptやPythonなど）が提供されており、Tools・Resources・Promptsを定義してJSON-RPCの規約に沿わせれば独自サーバーになります。公式リファレンスサーバーの実装が見本として参考になります。

Q. MCPは無料で使えますか？

A. MCPの仕様とプロトコル自体はオープンで、規格として無料で利用できます。ただし接続先のサーバーが呼び出す外部API（有料SaaSなど）の料金は、そのサービス側の課金体系に従います。

Q. MCPはClaude以外でも使えますか？

A. 使えます。MCPはAnthropicが策定したオープンプロトコルで、特定のモデルに縛られません。MCPに対応したホストであれば、Claude以外のクライアントからも同じサーバーを利用できます。

Q. stdioとHTTPトランスポートはどう使い分けますか？

A. 手元のPCで動かすローカルサーバーはstdio、ネットワーク越しに共有するリモートサーバーはStreamable HTTPを使うのが基本です。まず自分の環境で試すならstdio、チームで公開するならHTTP、と考えると迷いません。

Q. MCPのセキュリティで気をつけることは？

A. 権限の最小化、リモート接続でのOAuthなどの認可、そしてプロンプトインジェクション対策の3点です。信頼できないサーバーには接続せず、副作用の大きいツールは実行前にユーザーが承認する運用を徹底します。

出典