AIに社内ドキュメントを検索させたい。GitHubのIssueを立てさせたい。DBから数字を引かせたい——そう考えたとき、これまでは接続先ごとに専用のコードを書く必要がありました。
MCP（Model Context Protocol）は、この「つなぎ方」を統一するための共通プロトコルです。LLM（大規模言語モデル）を利用するアプリケーションに、外部のツールやデータソースを同じ方式で接続できるようにします。ひと言でいえば、AIが道具を使うための共通の差し込み口をつくる規格です。
Anthropicが2024年11月25日に公開し、現在はオープン仕様として運用されています。
MCPが解決したい問題
AIに任せたいのは文章生成だけではありません。実務で期待されるのは、たとえば次のような作業です。
- 社内ドキュメントを検索し、出典付きで答える
- GitHubのIssueを作成・更新する
- DBから必要なレコードを引いて集計する
- カレンダーを参照して予定を調整する
問題は、こうした連携がアプリごとの個別実装になりやすいことです。Anthropicの発表も、データソースごとに独自実装が必要でスケールしない点を出発点に挙げています。
AIアプリがM個、つなぎたいツールがN個。個別に作れば、組み合わせの数だけコネクタが必要になります。認証もエラー処理も権限設計も、そのすべてに書くことになります。
MCPは、ここに共通の層を挟みます。理想化していえば、M×N の作り込みを M+N に近づけるという発想です。
ただし、これは概念モデルです。仕様がこの削減を保証するわけではなく、認証方式や独自拡張、仕様版の差によって個別実装は残ります。
MCPのイメージ（AI用のUSB-C）
MCPはUSB-Cにたとえられます。公式サイトも「AIアプリケーションのためのUSB-Cポート」という説明を使っています。
- USB-C：対応する機器・ポートであれば、同じ端子で充電器・ディスプレイ・ストレージに接続できる
- MCP：同じ方式で検索・チケット操作・ファイル操作などの機能（サーバー）に接続できる
ポイントは、規格化されるのが「つなぎ方」であって「中身」ではない点です。サーバー側が何を提供するかは自由で、共通化されるのは接続後の能力（Capability）通知、ツール一覧の取得、呼び出しの手順などです。どのサーバーがどこにあるかをホストが最初にどう知るかまでを規定するものではありません。
MCPの構成要素：Host・Client・Server の役割
- ホスト（Host）：ユーザーが触るアプリ本体（IDE、デスクトップアプリ、エージェント基盤など）。複数のクライアントを生成・管理し、接続許可やセキュリティポリシー、ユーザーの認可判断を担う
- クライアント（Client）：ホストの中でちょうど1つのサーバーと通信する役。サーバー同士のセキュリティ境界を保つ
- サーバー（Server）：ツールやデータアクセスを提供する側（社内検索、GitHub操作、DB参照など）。冒頭に挙げたような機能の実体はここにあり、MCPが提供するのはサーバーへのつなぎ方の統一です
[ユーザー]
↓
[MCP Host] ─→ [MCP Client A] ⇄ [MCP Server A] → (GitHub)
─→ [MCP Client B] ⇄ [MCP Server B] → (社内Docs)
─→ [MCP Client C] ⇄ [MCP Server C] → (DB)
ホストが複数のクライアントを持ち、1つのクライアントが1つのサーバーと1対1で対応します。この構造により、「このサーバーは参照のみ」といったポリシーをクライアント単位で適用できます。
ただし、書き込み禁止のような制御をMCPが自動で提供するわけではありません。ホスト側のポリシー、公開するツールの選択、OAuthのスコープ設計といった実装が必要です。
MCPサーバーが提供する3つの要素（Tools / Resources / Prompts）
- Tools（ツール）：関数のように実行できる操作（検索、作成、更新など）。モデルが呼び出しを判断することを想定した、副作用を伴いうる要素
- Resources（リソース）：URIで識別される読み取り専用データ（ドキュメント、ファイル、DBスキーマなど）。どれを読むかはアプリ側が決めるのが基本
- Prompts（プロンプト）：定型作業のテンプレート（レビュー手順、要約フォーマットなど）。ユーザーが明示的に選ぶもので、スラッシュコマンドなどのUIが例として挙げられている
3つの違いは「誰が起動を決めるか」で整理すると見通しが良くなります。モデル主導がTools、アプリ主導がResources、ユーザー主導がPromptsです。実務でまず押さえるのは、この3要素です。
重要なのは、AIが好き勝手に動くのではなく、ホスト側で適切に制御を実装すれば、許可された道具だけを使える形にできることです。MCPを採用しただけで自動的に安全になるわけではありません。
補足：仕様の最新動向（2026-07-28版）
仕様には、上の3要素以外の機能もあります。クライアント側の機能としてはElicitation（処理の途中でユーザーに追加入力を求める仕組み）が現行機能として定義され、ほかに進捗通知やキャンセルなどのユーティリティ、Tasksなどの公式Extensions（拡張仕様）もあります。
一方でRoots・Sampling・Loggingは2026-07-28版で非推奨となりました。非推奨機能は少なくとも12か月は仕様内に維持されたうえで、将来の改訂で削除されうる扱いです。新規に実装する場合は採用を避けてください。
Tool Use（Function Calling）との違い
混同されがちですが、両者は競合しません。レイヤーが違います。
- Tool Use / Function Calling：一般に、モデルが「この関数をこの引数で呼びたい」と出力する推論側の仕組み。ツールの定義をどう用意するかは各アプリの実装任せ
- MCP：接続したサーバーからツール一覧をどう取得し、どう呼び出し、必要に応じてどう認可するかを定める規格
典型的なLLMアプリでは、MCPサーバーが公開したツール一覧がモデルにFunction Callingの候補として渡され、モデルの呼び出し要求をクライアントがMCP経由でサーバーへ転送します。仕様が特定ベンダーのFunction Calling形式を要求しているわけではなく、モデルを介さずUIから直接ツールを呼ぶ実装も可能です。
整理すると、Tool Useはモデル側の選択と出力、MCPはサーバーとの一覧取得・通信・実行管理という分担になります。
MCPを導入すると何が変わる？
連携を後から足せる
MCP対応サーバーを追加することで接続先を増やせます。ホストが同じ仕様版・通信方式・認証方式に対応していて、コア機能の範囲で使う限り、AIアプリ側のコード変更を減らせます。独自拡張、専用UI、固有の認証やポリシー設定が絡む場合は変更が必要になります。
ツール接続の作り直しが減る
一度書いたサーバーは、互換性のある別のMCP対応アプリからも再利用できます。ただし「そのまま動く」ことが保証されるわけではありません。仕様版、通信方式、Extensions、認証、対応するコンテンツ種別などに依存します。
権限を設計する単位ができる（ログ基盤は別途必要）
「AIに何をさせてよいか」を、ツール単位・サーバー単位で表現できます。認可の仕組みも用意されており、HTTPで通信する場合はOAuth 2.1（IETFドラフト）を基盤とした認可仕様に沿って実装できます。
注意点は2つ。認可の実装は必須ではなく任意であること、そしてこの仕様の対象がHTTP通信に限られることです。ローカルのプロセス間通信（STDIO）で接続する場合は対象外で、資格情報は環境変数などから取得する形が推奨されています。
また、監査ログは自動では得られません。現行版ではMCPのLogging機能そのものが非推奨となり、OpenTelemetryなどへの移行が示されています。ログ基盤は自前で用意する前提で設計してください。
設計上の注意点
- 権限：参照だけで足りるユースケースに書き込み権限を与えない。最小権限はMCPの認可仕様でも推奨されており、実際の粒度はサーバー・ツールの切り方とスコープ設計に依存する
- プロンプトインジェクション：ツールが返した外部テキストはデータであって指示ではない。取得した文章に書かれた命令をそのまま実行しない設計は基本だが、これだけで攻撃を完全に防げるわけではない
- 信頼できないサーバー：サードパーティ製サーバーはツール定義そのものが攻撃面になりうる。仕様も、信頼済みサーバー由来でないツールの注釈は信頼しないよう求めている。ローカルのサーバーも任意コード実行のリスクを持つ
- ログ：いつ・どのツールが・どの引数で呼ばれたかを追える状態にしておく。「何の目的で」まで追う場合は、ユーザーの要求内容や承認記録をアプリ側で紐づけて保存する
導入初期は読み取り系のツール（検索・参照）から始め、書き込み系は人間の承認を挟む構成にすると、リスクを抑えられます。
まとめ
- MCPは、AIと外部ツール／データをつなぐための共通プロトコル
- 目的は接続の標準化で、理想化していえばM×N の個別実装を M+N に近づけることにある
- MCPサーバーの中核的な3要素はTools（モデル主導）・Resources（アプリ主導）・Prompts（ユーザー主導）。ほかにElicitationなどのクライアント機能やExtensionsもある
- Tool Useはモデル側の選択と出力、MCPはサーバーとの通信・実行管理。両者は置き換えではなく重なる層
次の一歩としては、読み取り系のMCPサーバーを1つだけ手元のホストにつないでみるのが分かりやすい入口です。ツール一覧がモデルに渡り、呼び出しがサーバーへ転送される流れを実際に見ておくと、この記事の構成図が具体的なイメージに変わります。