MCP

概要

MCP（Model Context Protocol）は、LLMアプリケーションと外部のツール・データ源を接続するためのオープンな標準プロトコルです。Anthropicが2024年11月に公開し、その後主要なAIツール・モデル提供者が相次いで採用したことで、AI連携の事実上の共通規格になりつつあります。よく「AI連携のUSB-C」と呼ばれるのは、どのデバイスでも同じ端子で繋がるように、どのAIアプリでも同じ手順で外部システムに繋がることを目指しているからです。

具体的には、GitHubのリポジトリ、社内データベース、Slack、ファイルシステムといった外部システム側が「MCPサーバ」という小さなプログラムを用意しておけば、MCPに対応したAIアプリ（チャットUIやコーディングエージェントなど）はそれを差し込むだけで、そのシステムのデータを読んだり操作したりできるようになります。接続の約束事を標準化することで、「どのAIと、どの外部システムを組み合わせるか」を自由に選べるようにする仕組みです。

なぜ生まれたか

LLMに外部ツールを使わせる Function Calling が普及すると、今度は接続の組み合わせ爆発が問題になりました。AIアプリがM個、繋ぎたい外部システムがN個あるとき、標準がなければ各アプリが各システム向けの連携コードを個別に実装することになり、必要な実装はM×N通りに膨らみます。同じ「GitHubに繋ぐ」機能を、チャットアプリもIDEもエージェント基盤もそれぞれ独自形式で作り直す — ツール定義の書式も認証も接続方法もバラバラで、外部システム側も対応アプリごとに連携を用意する羽目になっていました。

MCPはこの間に共通のプロトコルを一枚挟むことで、問題をM+N個に変えます。AIアプリはMCPクライアントを一度実装すればあらゆるMCPサーバに繋がり、外部システムはMCPサーバを一度書けばあらゆる対応アプリから使われる。これはOSのデバイスドライバや、WebにおけるHTTPが果たしたのと同じ、「間を標準化して両側を疎結合にする」という古典的な解法をAI連携に適用したものです。

詳細

ホスト・クライアント・サーバの三層構成

MCPの登場人物は3つです。「ホスト」はユーザーが触るAIアプリケーション本体（Claude DesktopやIDE、エージェント基盤など）で、LLMとの対話を管理します。ホストは接続したい外部システムごとに「MCPクライアント」を1つ持ち、各クライアントが対応する「MCPサーバ」と1対1で繋がります。MCPサーバは外部システム（データベース、SaaS、ローカルファイルなど）の機能をMCPの語彙に翻訳して提供する変換アダプタで、通信はJSON-RPC 2.0のメッセージでやり取りされます。接続方法は、ローカルでプロセスを起動して標準入出力で繋ぐstdio方式と、ネットワーク越しにHTTPで繋ぐ方式の2系統があります。

3つのプリミティブ — リソース・ツール・プロンプト

MCPサーバがホストに提供できる機能は、大きく3つのプリミティブ（基本要素）に整理されています。「リソース」は読み取り用のデータで、ファイルの中身やデータベースのレコードなど、LLMの文脈に取り込む素材を指します。「ツール」はLLMが呼び出せる操作で、検索を実行する・Issueを作成するといった副作用を伴う行為を含みます。これは Function Calling の関数定義に相当するもので、サーバは各ツールの名前・説明・引数スキーマを公開し、クライアントの問い合わせに応じて一覧を返します。「プロンプト」は定型的な指示のテンプレートで、「このコードをレビューして」のような使い回せる依頼文をサーバ側が提供します。

接続時にはまず初期化のハンドシェイクで互いの対応機能を交換し、その後クライアントが「どんなツールがあるか」「どんなリソースがあるか」を照会して、LLMに使わせる形に整えます。ホスト側のLLMがツールを使うと決めたら、クライアントがサーバに実行を依頼し、結果を文脈に戻す — この実行ループ自体は AIエージェントの観察→思考→行動の構造そのものです。MCPはそのループの「外部との接点」を規格化した、と位置づけられます。

エコシステムと実務での使いどころ

標準化の最大の恩恵は再利用です。GitHub・Slack・PostgreSQLなど主要サービスのMCPサーバは公式・コミュニティ製が既に多数公開されており、自作する場合も各言語のSDKを使えばツール数個のサーバは短時間で書けます。社内システムをAIに繋ぎたいとき、アプリごとの個別連携ではなくMCPサーバを1つ立てれば、対応するどのAIツールからも使える — 社内APIを整備する感覚で「AI向けの窓口」を整備できるのが実務上の魅力です。リモート接続ではOAuthによる認可が仕様に組み込まれており、ユーザーの同意に基づく権限委譲という、Web APIで培われた作法をそのまま持ち込めます。

落とし穴と設計上の注意

便利さの裏で、MCPは「LLMに外部への実行力を渡す配線」でもあるため、セキュリティ上の注意が欠かせません。素性の分からないMCPサーバを繋ぐことは、未知のコードに手元のデータへのアクセスを許すことと同義です。また、ツールの説明文やリソースの中身に悪意ある指示を仕込み、LLMを誤動作させるプロンプトインジェクション攻撃の経路にもなり得ます。信頼できる提供元のサーバだけを使う、最小権限のトークンを渡す、破壊的操作には人間の承認を挟むといった基本を守ることが前提です。さらに、繋ぐサーバを増やすほどツール定義がコンテキストウィンドウを圧迫し、LLMの選択精度も落ちるため、「繋げるだけ繋ぐ」のではなくタスクに必要な接続に絞るのが実運用のコツです。