MCPとは｜AIと外部ツールをつなぐ共通規格の仕組みと、入れる前に見る3つの場所

MCPは、AIアプリと外部のデータや道具をつなぐための、オープンソースの共通規格だ。
公式の紹介ページは、これを「AIアプリのUSB-Cポート」と例えている。
この記事では、MCPの登場人物と3つの部品、つなぎ方の2種類、そして入れる前に見ておきたい場所を、公式ドキュメントに沿って整理する。

MCPは何をつなぐ規格か

公式の説明では、MCPを使うとClaudeやChatGPTのようなAIアプリが、データ源（ローカルのファイルやデータベース）、道具（検索エンジンや計算機）、手順（用途に合わせたプロンプト）につながる。
つながると、AIは必要な情報を取りに行ったり、作業を実行したりできるようになる。

USB-Cの例えが言っているのは、つなぎ方が揃っていることの価値だ。
機器ごとに専用の端子を用意するのではなく、同じ形の口に差せば動く。
MCPも、AIアプリごと・サービスごとに専用の連携を作るのではなく、MCPに合わせて一度作れば、対応するアプリ全部で使える。
公式は、Claude、ChatGPT、Visual Studio Code、Cursorなどが対応していると書いている。

登場人物は3つ：ホスト、クライアント、サーバー

MCPはクライアントとサーバーの構成で動く。
ただし、普通のWebでいうクライアントとは少し意味が違うので、ここは公式の定義をそのまま押さえておく。

• MCPホスト … AIアプリそのもの。Claude CodeやClaude Desktopがこれにあたる
• MCPクライアント … ホストの中にいて、1つのサーバーとの接続を受け持つ部品
• MCPサーバー … 文脈（データや道具）を提供するプログラム

ホストは、つなぐサーバーの数だけクライアントを作る。
公式の例では、Visual Studio CodeがSentryのサーバーに接続すると、その接続を持つクライアントが1つできる。
続けてローカルのファイルシステムのサーバーにつなぐと、クライアントがもう1つできる。
1サーバーにつき1クライアント、という対応だ。

「MCPサーバー」という言葉は、動いている場所を指さない。
自分のPCで動くものも、相手のクラウドで動くものも、どちらもMCPサーバーと呼ぶ。

サーバーが出せるのは3種類：ツール、リソース、プロンプト

公式は、サーバーが提供できる部品（プリミティブ）を3つに分けている。

• ツール … AIが呼び出して実行できる関数。ファイル操作、APIの呼び出し、データベースへの問い合わせなど
• リソース … 文脈になるデータ。ファイルの中身、データベースの行、APIの応答など
• プロンプト … やり取りの型になる再利用できるテンプレート。システムプロンプトや例示など

公式が挙げているデータベースの例がわかりやすい。
問い合わせ用の「ツール」、スキーマ（テーブル構造）を入れた「リソース」、使い方の例を入れた「プロンプト」を、1つのサーバーが一式で出せる。

AIアプリは、まずtools/listでサーバーが持つツールの一覧を取り、それからtools/callで呼び出す。
一覧は固定ではなく動的で、サーバー側のツールが増減したときは通知で知らせる仕組みも用意されている。

つなぎ方は2種類：stdioとStreamable HTTP

サーバーとの通信路（トランスポート）は2つある。

• stdio … 同じPCの中で、標準入出力を使ってプロセス同士が直接やり取りする。ネットワークを通らない
• Streamable HTTP … HTTPのPOSTで送り、必要に応じてServer-Sent Eventsで流す。離れた場所のサーバーとつなげる。認証にはベアラートークンやAPIキーなどが使え、公式はOAuthでトークンを得ることを勧めている

公式はこの使い分けを、自分のPCで起動するものは「ローカル」、Sentryの公式サーバーのようにサービス側で動くものは「リモート」と呼んでいる。
ローカルのstdioは基本的に1つのクライアント専用で、リモートのHTTPは多くのクライアントを受け持つ。

入れる前に見ておきたい場所

ここからは、公式のセキュリティ文書を読んで、僕が「導入前に見る」と決めたい点だ。

公式は、ローカルのMCPサーバーについて、はっきりと危険を書いている。
ローカルサーバーは、ダウンロードして自分のPCで実行する実行ファイルだ。
サンドボックスや同意の仕組みが無いと、悪意ある起動コマンドが設定に紛れ込んだり、サーバー本体に悪意あるコードが入っていたりすると、そのまま任意のコマンドが実行される。
リスクとして挙がっているのは、クライアントと同じ権限での任意コード実行、何が実行されるか見えないこと、データの持ち出し、取り返しのつかないデータ消失だ。

対策として公式がクライアント側に求めているのは、起動するコマンドを省略せずに全部見せること、実行して危険な操作になりうると明示すること、ユーザーが明確に承認するまで進まないこと、の3点だ。
サーバーを作る側には、stdioを使ってクライアントだけに接続を絞ることや、HTTPなら認可トークンを要求することを挙げている。

権限についても、公式は「スコープを絞る」考え方を書いている。
広すぎる権限（files:*やadmin:*のようなもの）を最初から全部渡すと、トークンが漏れたときの被害が一気に広がる。
最初は読み取りなどの軽い権限だけにして、必要になった時点で段階的に上げるのが推奨されている。

これを読んで、僕は次のように考えている。
MCPサーバーは「AIに使わせる道具」である前に、「自分のPCで動くプログラム」であり「自分のアカウントの権限を預ける相手」だ。
だから、導入前に確かめることは3つに絞れると思う。

1. 提供元はどこか。公式やサービス運営元のものか、出どころの分からない個人のものか
2. 起動コマンドは何か。設定に書かれたコマンドを、省略せずに最後まで読む
3. 渡す権限は最小か。読み取りだけで足りるのに、書き込みや削除まで許していないか

これは公式文書の要約ではなく、僕の整理だ。
公式が書いているのは「クライアントは同意を取れ」「権限は絞れ」という、作る側・提供する側への要求で、使う側の手順表ではない。
ただ、その要求の裏返しとして、使う側もこの3点は自分の目で見ておく価値があると考えた。

MCPが決めていないこと

公式のアーキテクチャの文書には、MCPが扱う範囲についての注意書きがある。
MCPは文脈をやり取りするためのプロトコルに限られ、AIアプリがLLMをどう使うか、渡された文脈をどう管理するかまでは決めていない。

つまり、MCPに対応していることは、そのAIアプリの賢さや安全性を保証しない。
つなぐ口が揃っているだけで、つないだ先で何を許すかは、各アプリと使う人が決めることになる。

この記事のまとめ

• MCPは、AIアプリと外部のデータ・道具をつなぐオープンな共通規格。AIアプリのUSB-Cポートという例えが公式にある
• 登場人物は、ホスト（AIアプリ）・クライアント（接続を受け持つ部品）・サーバー（文脈の提供側）の3つ
• サーバーが出せるのは、ツール・リソース・プロンプトの3種類
• つなぎ方はstdio（同じPC内）とStreamable HTTP（離れた場所）の2種類
• ローカルのサーバーは自分のPCで動くプログラム。提供元・起動コマンド・渡す権限の3つを入れる前に見る（これは僕の整理）

AIに任せる範囲の考え方は、役割で分けたチームを組んだ話や、サブエージェントを25個作った結果にも書いている。

出典

• What is the Model Context Protocol (MCP)? - Model Context Protocol
• Architecture overview - Model Context Protocol
• Security Best Practices - Model Context Protocol