MCPとは何か：AIとツールをつなぐ仕組みを実務目線で解説

この記事で分かること

• MCPのホスト、クライアント、サーバーがそれぞれ何を担うか
• JSON-RPC、セッション、能力交渉、ツール呼び出しの関係
• stdioとHTTPを選ぶときの比較軸
• ローカルMCPサーバーを導入する前に確認すべき信頼境界

注意： MCP対応だから安全、公式一覧にあるから安全、ローカル実行だから外部へ情報が出ない、とは限りません。最初に見るべきなのは接続できるツールの数ではなく、サーバープロセスが誰の権限で何を読み書きできるかです。

先に結論

MCP（Model Context Protocol）は、AIを組み込んだアプリケーションと、外部のデータや操作機能を共通のメッセージ形式でつなぐためのプロトコルです。AIモデルそのものでも、エージェントの自律判断方式でもありません。

MCPのホストは接続、同意、会話、モデル連携を管理し、ホスト内のクライアントが各サーバーと通信します。サーバーはリソース、プロンプト、ツールなどの機能を公開します。公式アーキテクチャでは、1つのクライアントが特定の1サーバーとの接続を担当し、ホストが複数のクライアントを管理する構成です。

ホストが接続と同意を管理し、クライアントとサーバーが初期化時に利用可能な能力を確認する。

重要なのは、MCPが通信方式をそろえても、接続先の信頼性や業務上の承認まで自動的に保証するわけではないことです。ファイル削除、メール送信、顧客情報の取得といった操作は、MCPの外側も含めて最小権限、利用者の同意、監査ログ、停止方法を設計する必要があります。

MCPを4つの役割に分けて理解する

1. ホスト

ホストは、AI機能を提供するデスクトップアプリ、開発ツール、業務アプリなどです。公式仕様では、クライアントの生成とライフサイクル、接続許可、同意、セキュリティ方針、モデルとの連携、複数接続から得たコンテキストの集約を担います。

利用者にツール実行の確認画面を見せる主体も、通常はホスト側です。したがって、同じMCPサーバーでも、どのホストから使うかによって承認画面、ログ、設定できる権限が異なる可能性があります。

2. クライアント

クライアントはホスト内で動き、1つのサーバーとの通信を担当します。初期化、プロトコルバージョンと能力の交換、要求と応答の受け渡し、通知などを処理します。

利用者がクライアントを直接操作するとは限りません。画面上では単に「サーバーを追加」と表示されていても、内部ではホストが接続ごとのクライアントを作っている、と考えると整理しやすくなります。

3. サーバー

サーバーは専門機能を公開する側です。代表的なプリミティブには、参照対象を提供するリソース、再利用可能なプロンプト、処理を実行するツールがあります。サーバーはローカルプロセスにも、ネットワーク上のサービスにもなれます。

ただし「サーバー」という名前でも、必ず別のコンピューターで動くわけではありません。ローカルMCPサーバーは、利用者のPC上で通常のプログラムとして起動されます。

4. JSON-RPCメッセージ

MCPの基本メッセージはJSON-RPC 2.0を基礎にします。要求にはメソッド名、識別子、引数があり、応答には結果またはエラーが入ります。通知のように応答を求めないメッセージもあります。

概念を確認するための簡略例は次のとおりです。実際に送るフィールドや利用できるメソッドは、採用するMCP仕様バージョンを確認してください。

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "search_documents",
    "arguments": {
      "query": "出張旅費の上限"
    }
  }
}

成功時には、同じ識別子に対応する結果が返ります。ここで分かるのは通信上の成功です。検索結果が最新か、依頼者に閲覧権限があるか、回答が正しいかは別に検証します。

能力交渉とセッションは何をしているのか

接続開始時には初期化を行い、双方が対応するプロトコルバージョンと能力を交換します。サーバーがツールを提供するならツール対応を、クライアントがサンプリングなどを受け付けるなら該当能力を宣言します。能力を宣言したことは、個々の操作を利用者が承認したことと同義ではありません。

能力交渉の目的は「この接続で利用可能なプロトコル機能」を一致させることです。ツール一覧に表示されたからといって、AIが無条件に実行してよいわけではありません。業務上の許可は、ツール単位、引数、対象データ、実行時点などで別に判断します。

セッションの扱いは仕様バージョンとトランスポートで差があるため、実装文書を固定して確認します。2025-06-18版のアーキテクチャは状態を持つクライアント・サーバー間セッションとして説明し、同版のStreamable HTTPにはセッション管理の規定があります。一方、後続の公式セキュリティ文書では、より新しい仕様についてプロトコルレベルでステートレスと説明し、複数要求にまたがる状態は明示的なハンドルで扱う場合があります。「MCPには常に同じセッションIDがある」と一般化しないことが重要です。

stdioとHTTPの選び方

比較軸	stdio	Streamable HTTP
典型構成	ホストがローカルプロセスを起動	ネットワーク上のエンドポイントへ接続
メッセージ経路	標準入力・標準出力	HTTPのPOSTやストリーム
認証	OS権限、起動設定、サンドボックスが中心	認証・認可、TLS、オリジン、ネットワーク制御が必要
配布	各端末へ実行物や依存関係を配置	サーバー側で更新しやすい
主な危険	悪意ある起動コマンド、広すぎるローカル権限	誤認証、SSRF、公開範囲、トークンやリダイレクト処理

stdioでは、標準出力へMCPメッセージ以外を書かないという仕様上の制約があります。デバッグログを標準出力に混ぜると通信を壊すため、ログは標準エラーや専用ログへ分離します。

HTTPでは、単にURLへ接続できるだけでは不十分です。本番ではHTTPS、接続先の検証、認証情報の対象確認、タイムアウト、再試行、ネットワーク出口制御などを設計します。ローカルホストで待ち受けるHTTPサーバーも、DNS rebindingなどを考慮し、接続元やHostヘッダーを検証します。

MCP導入前の判断手順

1. 業務目的を1文で定義する

   「便利にする」ではなく、「承認済みの社内規程だけを検索し、回答案に出典を付ける」のように、対象と操作を限定します。

2. 実行主体を特定する

   ローカルプロセスならOS上の実行ユーザー、HTTPなら利用者・クライアント・サーバーの認証主体を確認します。管理者権限で動かす必然性がなければ付与しません。

3. 公開される能力と実処理を対応付ける

   ツール名だけで判断せず、入力引数、参照先、外部通信、作成・変更・削除の有無を確認します。read_fileという名前でも任意パスを読めるなら影響範囲は広くなります。

4. 承認ポイントを決める

   読み取りは自動、外部送信は毎回承認、削除は許可しない、というように操作の不可逆性で分けます。包括的な初回承認だけで高リスク操作を通さない設計が安全です。

5. 隔離して検証する

   テスト用アカウント、ダミーデータ、限定ディレクトリで起動し、想定外パス、過大な入力、通信失敗、権限不足を試します。本番資格情報を最初から渡さないでください。

6. 停止と撤去を試す

   接続無効化、プロセス終了、認可取り消し、ログ確認、設定削除まで実施します。停止できない接続は運用開始しません。

コピペできる信頼境界チェック表

# MCP接続審査票
- 業務目的：
- ホスト名・バージョン：
- MCP仕様バージョン：
- サーバー配布元・版・ハッシュ：
- トランスポート：stdio / HTTP / その他
- 実行ユーザーまたは認証主体：
- 読めるデータ：
- 作成・変更・送信・削除できる対象：
- 外部通信先：
- 保持する認証情報：
- 自動実行を許すツール：
- 毎回承認するツール：
- 禁止するツール：
- 監査ログの保存先と保存期間：
- タイムアウト・回数・費用上限：
- 緊急停止方法：
- 検証責任者と再確認日：

成功の目安は、各項目に具体名が入り、「不明」が残っていないことです。特に、実行ユーザー、読み書き可能範囲、外部通信先、停止方法の4点を第三者が説明できるか確認します。

よくある失敗と対処

• ツール名だけで安全と判断する：ソース、実行コマンド、引数スキーマ、実際のアクセス先を確認します。
• ローカルだから無害だと思う：ローカルサーバーはクライアントと同等のOS権限で任意コードを実行し得ます。専用ユーザー、コンテナ、許可ディレクトリで制限します。
• 能力交渉を認可と混同する：能力は技術的対応、認可は主体と対象に対する許可です。操作時の承認を別に設けます。
• 認証情報をそのまま下流へ渡す：対象サービス向けでないトークンの受け入れや単純なパススルーを避け、受信側で対象と権限を検証します。
• ログに秘密を残す：ツール名、時刻、主体、対象、結果は記録しつつ、本文、トークン、個人情報はマスキングします。
• バージョンを記録しない：仕様、SDK、ホスト、サーバーの版を固定し、更新時に能力と権限を再確認します。

採用しない条件

サーバーの配布元や更新経路を確認できない、必要以上のOS権限を要求する、外部送信先を限定できない、変更操作を承認なしで行う、監査ログを取得できない、緊急停止を試せない場合は採用を見送ります。

MCPを使わず、読み取り専用のファイル取り込みや既存の承認済み連携で要件を満たせるなら、接続面を増やさない選択も有効です。

AI活用ナビの判断

AI活用ナビの判断： MCPの価値は、異なるツールを共通方式で接続しやすくする点にあります。ただし導入判断の中心は接続数ではありません。最小権限で動かし、重要操作を人へ戻し、停止と監査を実証できる接続だけを採用するのが実務的です。

最初の導入対象には、限定した資料の検索やテスト環境の参照など、読み取り中心で結果を人が確認できる業務が向いています。送信、購入、権限変更、削除を伴う処理は、読み取り接続の運用実績とログを確認した後に分離して検討します。

確認日と公式情報

確認日：2026年7月29日。

• MCP Architecture（仕様2025-06-18版）
• MCP Transports（仕様2025-06-18版）
• MCP Lifecycle（仕様2025-06-18版）
• MCP Security Best Practices

仕様の版によってセッション、認証、トランスポートの詳細が変わり得ます。実装時は、利用するホストとサーバーが対応する同一バージョンの仕様を確認してください。

PRIMARY SOURCES

確認した一次情報

1. MCP ArchitectureModel Context Protocol · 2026年7月29日
2. MCP Security Best PracticesModel Context Protocol · 2026年7月29日

RELATED ARTICLES

次に読む記事

この記事の内容を、実践・比較・安全確認へつなげる3本です。

技術解説

「サンドボックスだから安全」はもう通用しない　AIエージェント防御の設計原則

OpenAIの評価用エージェント侵入事件が壊したのは、サンドボックスに入れれば安全という前提でした。通信、認証、監視、停止を一つの境界として設計する考え方を解説します。

記事を読む 技術解説

AIエージェントの権限設計：承認・ログ・停止条件を先に決める

AIエージェントへツール操作を任せる前に、読み取り、作成、変更、送信、削除を分け、承認ポイント、監査ログ、上限、停止条件を設計する方法を解説します。

記事を読む AI安全運用

AIエージェントのOAuth同意を安全に設計する　AWSの新機能から学ぶ代理アクセスの守り方

AIエージェントがGitHubやSlackをユーザーの代理で操作するときに必要な、OAuth同意、セッション結び付け、最小権限、トークン保管、監査、失効の設計と確認手順を解説します。

記事を読む