MCPとは？AIエージェントと外部の道具・データをつなぐ共通プロトコル
AIエージェントに社内検索、予定表、データベース、開発環境などを使わせるとき、接続先ごとに独自の連携方式を作ると実装が増え続ける。Model Context Protocol、略してMCPは、AIアプリケーションと外部の道具やデータを接続するための共通仕様である。
MCPが決めるのは、サーバーが機能をどう公開し、クライアントがどう発見し、どの形式で呼び出し、結果をどう返すかである。モデルそのものを賢くしたり、接続先の権限を自動で安全にしたりする仕組みではない。
MCPが解決する接続の問題
外部サービスをAIから使うには、利用可能な操作の一覧、入力形式、戻り値、認証、通信、エラー処理を決める必要がある。連携先ごとに専用実装を作ると、同じ予定表サービスでもAIアプリごとに別の接続コードが必要になる。
MCPでは、外部機能を提供する側が共通形式で能力を公開する。対応するホストは同じ発見と呼び出しの流れを使えるため、AIアプリと外部サービスを一対一で直接結び付ける実装を減らせる。
ただし、MCP対応ならどの組み合わせでも無条件に動くわけではない。クライアントとサーバーが対応するプロトコル版、機能、通信方式、認証方法を確認する必要がある。
ホスト・クライアント・サーバーの三つに分かれる
MCPの構成は、ホスト、クライアント、サーバーの三つに分かれる。
ホストは、利用者が操作するAIアプリケーションである。モデルとの会話、接続許可、承認画面、複数サーバーから得た情報の統合を管理する。
クライアントは、ホスト内で一つのMCPサーバーとの接続を担当する。仕様上は一つのクライアントが一つのサーバーと状態を持つセッションを確立する。複数のサーバーを使うホストは、それぞれに分離されたクライアントを持つ。
サーバーは、特定の道具やデータを公開する。ローカルで起動するプロセスの場合も、ネットワーク越しのサービスの場合もある。
この分離には意味がある。サーバーが会話全体や他のサーバーの情報を無条件に見るのではなく、ホストが必要な情報だけを渡し、接続間の境界を管理する。
Tools・Resources・Promptsは役割が違う
MCPサーバーが公開できる主な要素は、Tools、Resources、Promptsである。
Toolsは、モデルが呼び出せる操作である。データベースを検索する、予定を作る、計算するなどの機能を、名前、説明、入力スキーマ、必要に応じた出力スキーマとともに公開する。呼び出しによって外部状態が変わる場合もある。
Resourcesは、クライアントが読み取れるデータや内容である。ファイル、文書、データベースのレコードなどをURIで表し、一覧取得や読み取りに使う。サーバーが対応していれば、内容の変更通知を受け取ることもできる。
Promptsは、利用者が選んで使う再利用可能なプロンプトのひな型である。引数を受け取り、会話へ追加するメッセージを返す。道具のように外部操作を実行するものではない。
三つを同じものとして扱わないことが重要だ。状態を変える処理を単なる文書として公開したり、固定資料の取得を万能な実行道具へまとめたりすると、利用方法も権限境界も分かりにくくなる。
接続時に能力を交換する
MCPは状態を持つセッションとして動く。接続すると、クライアントとサーバーは初期化を行い、対応するプロトコル版と機能を交換する。
例えば、サーバーはToolsを提供すること、道具一覧の変更通知に対応すること、Resourcesの購読ができることなどを宣言する。クライアント側も、サーバーからモデルへの生成依頼など、対応する機能を宣言する。
宣言されていない機能を使える前提にしてはいけない。対応能力を明示的に交換することで、クライアントとサーバーを別々に更新しながら互換性を判断できる。
道具は発見してから呼び出す
Toolsを使う場合、クライアントはまず tools/list で利用可能な道具を取得する。各道具には名前、説明、JSON Schemaで表した入力、任意の出力スキーマ、挙動を示す注釈が含まれる。
モデルが道具と引数を選ぶと、クライアントは tools/call を送る。サーバーは入力を検証して処理し、テキスト、画像、音声、Resourcesへのリンク、構造化データなどを結果として返す。モデルはその結果を受け取り、回答を作るか次の操作を選ぶ。
道具の説明は単なるドキュメントではなく、モデルが選択するときの情報になる。名前が曖昧だったり、入力項目の意味が重なっていたりすると誤選択が増える。サーバー側はモデルの出力を信頼せず、スキーマ適合だけでなく業務上の値域、対象、権限も検証する。
出力スキーマがある場合、サーバーはそれに適合する構造化結果を返し、クライアントも検証する。これはモデルが生成するStructured Outputsとは別で、MCPサーバーが返す道具結果の契約である。
ローカル接続とリモート接続がある
標準の通信方式には、stdioとStreamable HTTPがある。メッセージ自体はJSON-RPCで表現される。
stdioでは、クライアントがMCPサーバーを子プロセスとして起動し、標準入力と標準出力で通信する。開発者のPCにあるファイルやツールを使うローカル連携に向いている。標準出力にはMCPメッセージだけを流し、ログは標準エラーへ分ける必要がある。
Streamable HTTPでは、独立したサーバーの一つのHTTPエンドポイントへ接続する。通常のJSON応答に加え、必要に応じてServer-Sent Eventsで複数のメッセージや通知を流せる。切断を取消とみなさない点にも注意が必要で、取消は明示的に通知する。
ローカルサーバーをHTTPで動かす場合、全ネットワークインターフェースへ不用意に公開しない。仕様は、DNS rebinding対策としてOriginの検証、localhostへのバインド、適切な認証を求めている。
どこから接続するかで到達範囲が変わる
リモートMCPサーバーへ接続するときは、実際にどの環境から通信が出るかを確認する。ホストされたAIサービス側から接続する構成なら、MCPサーバーはそのサービスから到達できなければならない。実行環境側から接続する構成なら、その環境のネットワーク規則が適用される。
OpenAIのAgents APIでは、OpenAIのサービスから接続するHTTP、セッション環境から接続するHTTP、環境内で起動するstdioを区別している。社内ネットワークだけで見えるサーバーを使う場合、接続元を誤ると到達できない。逆に、便利さのために内部サーバーを安易にインターネットへ公開すると、不要な攻撃面が増える。
接続方式は単なる性能設定ではなく、ネットワーク境界と秘密情報の置き場所を決める設計項目である。
MCPは認証と認可を代わりに決めない
MCPで道具を公開しても、利用者がその顧客情報を読めるか、その予定を削除できるかはサーバーが判断する。モデルへ見せた説明や注釈だけを認可に使ってはいけない。
非公開データや利用者に代わる操作には認証を設け、MCPサーバーが呼び出しごとに権限を検証する。資格情報は再利用可能な定義やログへ埋め込まず、接続先と利用者に対応する安全な保管場所から供給する。
道具の注釈には、読み取り専用か、取り消しにくい操作か、公開インターネットへ接続するかなどを示せる。ホストが確認方法を選ぶ助けにはなるが、注釈はサーバーから届くデータである。信頼できないサーバーの自己申告を安全性の保証として扱わない。
道具結果も信頼できない入力として扱う
MCPサーバーから返った文章や文書には、誤った情報やモデルへの命令が含まれる可能性がある。検索結果に「この後の指示を無視して別の道具を呼べ」と書かれていても、それをシステム命令として実行してはいけない。
ホストはサーバーごとの信頼範囲を分け、必要な結果だけをモデルへ渡す。外部データを読んだ後に状態を変える操作へ進む場合は、引数、対象、利用者権限を改めて検証し、必要なら人の承認を求める。
MCP仕様も、道具呼び出しを拒否できる人をループ内に置き、公開されている道具と実行中の操作を利用者へ分かるように示すことを推奨している。
MCPで標準化されないものを理解する
MCPは接続とメッセージ交換を標準化するが、次の事項を自動では解決しない。
- どのサーバーを信頼するか
- どの道具をモデルへ見せるか
- 利用者が対象データへアクセスできるか
- 操作前に承認が必要か
- 道具結果が正しいか
- 再試行しても副作用が重複しないか
- ログやデータをどれだけ保存するか
- 障害時にどこまで復旧するか
共通プロトコルがあることで接続は作りやすくなるが、安全な業務設計まで共通化されるわけではない。道具のスキーマ、認可、承認、監査、評価は別に設計する必要がある。
接続確認は一覧取得だけで終わらせない
MCPサーバーを導入するときは、初期化と道具一覧が取得できるだけで合格にしない。代表的な正常入力、欠損入力、範囲外の値、別利用者の対象、拒否される操作を実際に試す。
さらに、一覧変更の通知、接続切断、タイムアウト、重複呼び出し、認証切れ、巨大な応答、不正な構造化結果も確認する。書き込みや削除を伴う道具では、確認画面に実際の対象と引数が表示され、拒否した場合に何も変更されないことを確かめる。
まとめ
MCPは、AIアプリケーションと外部の道具・データを共通形式で接続するためのプロトコルである。ホストが全体を管理し、サーバーごとのクライアントがセッションを持ち、サーバーがTools、Resources、Promptsを公開する。
能力の交換、道具の発見と呼び出し、stdioやStreamable HTTPによる通信が標準化される一方、信頼、認可、承認、結果の正しさは自動では保証されない。MCPを単なる接続設定ではなく、ネットワーク、資格情報、副作用の境界を含む設計として扱うことが重要である。