MCPとは？AIエージェント接続標準の仕組みと実装時のセキュリティ論点

MCP（Model Context Protocol）は、AIアプリケーションを外部ツールやデータソースにつなぐためのオープン標準です。公式ドキュメントでは、AIアプリケーション向けの「USB-C」にたとえられています。

標準化そのものは便利ですが、MCPを導入するとモデルはファイル、API、SaaS、社内データなどへ到達できるようになります。つまり、問題は「MCPが危険かどうか」ではなく、どのサーバーを信頼し、どこで承認し、どのデータを渡すかを設計できているかです。

この記事でわかること

1. MCPの基本構造: host / client / server がどう役割分担するか
2. MCPで発生するセキュリティ論点: 信頼境界、認証、入力検証、監査
3. MCPとA2Aの違い: ツール接続とエージェント間連携の使い分け
4. 導入チェックリスト: remote MCP server を使う前に確認すべき項目

基本情報

MCPとは何か？——AIアプリの「USB-C」

背景

MCPが解こうとしているのは、AIアプリごと・ツールごとに個別統合が増えていく問題です。モデルごとに独自の API 連携を作るより、共通のプロトコルを挟んだ方が、接続方法と権限の考え方をそろえやすくなります。

公式 docs では、MCP は AI アプリケーションがデータソース、ツール、ワークフローに接続するための標準インターフェースとして説明されています。Claude や ChatGPT のような AI アプリ側が client を持ち、外部システム側が server を公開する、という整理です。

技術アーキテクチャ

MCPの基本構造はシンプルです。

MCP server は主に次の 3 つを公開できます。

• Tools: 実行可能な操作
• Resources: 参照可能なデータ
• Prompts: 再利用できる指示テンプレート

MCPプロトコルの基本イメージ — 個別統合を共通インターフェースに寄せる

local と remote の違い

MCPは transport として stdio と HTTP 系の接続を取れます。ここが security 設計の分岐点です。

• local MCP server: 手元の PC 上で動く server と stdio で接続する
• remote MCP server: ネットワーク越しの server に接続する

local は OS 権限やローカルファイル境界が重要になり、remote は認証、トークン管理、送信データ、接続先の信頼性が重要になります。MCP を評価するときは、まず「どちらの接続形態なのか」を切り分けるべきです。

なぜ注目されているのか

MCPが注目される理由は、派手な数値よりも次の 3 点にあります。

1. 接続モデルがそろう
host / client / server の責務が整理されるので、AI アプリごとに毎回インテグレーションを作り直す負担を減らせます。

2. tools と data access を同じ枠組みで扱える
「何を実行できるか」と「何を参照できるか」を同じ protocol で扱えるため、レビュー対象をそろえやすくなります。

3. major product surfaces が MCP を前提にしたガイドを出し始めている
公式の MCP docs は Claude や ChatGPT を例に挙げており、OpenAI も remote MCP / connectors の公式ガイドを公開しています。つまり、MCP は概念説明だけでなく、実運用の導線に入り始めています。

MCPで注意すべきセキュリティ論点

MCPの risk は、単一の CVE 件数よりも、モデルにどの権限をどの UI で渡すかという trust boundary の設計に集約されます。公式仕様と公式ガイドから、実装者が押さえるべき論点を 4 つに整理します。

1. server の信頼性と user approval

MCP の tools はモデルが discovery し、文脈に応じて呼び出せる設計です。仕様では、sensitive な操作に対して human-in-the-loop を置き、user が deny できることを強く推奨しています。

実装時にまず確認したいのは次の点です。

• その server は誰が運営しているか
• どの tools を公開しているか
• host 側で実行前確認を挟めるか
• ユーザーに tool input を見せられるか

remote server を追加する行為は、単なる plugin install ではなく、モデルに新しい実行面を渡すことだと考えた方が安全です。

2. 認証・認可と token の扱い

MCP の authorization は OAuth 2.x 系の考え方で整理されており、remote server では user ごとの認証・認可が必要になる場面があります。特に、SaaS データや社内 API に触る server では、接続できるだけでなく、誰として何を実行したのかを追える状態が必要です。

確認項目は次の通りです。

• remote server で user identity をどう表現するか
• token をどこで発行し、どこに保存するか
• tool ごとの権限差分をどう制御するか
• disconnect や credential rotation をどう扱うか

「接続できる」ことより、「接続後の権限境界を説明できる」ことを優先してください。

3. 入力検証と prompt injection

MCP の仕様では、tool annotations や metadata を trusted server 由来でない限り信用すべきでないと明記されています。つまり、tool description や tool result 自体が attack surface になります。

注意点は次の通りです。

• tool description をそのまま実行ルールとして扱わない
• user input と tool input を分けて検証する
• shell 実行、ファイルパス、URL など高リスク入力は明示的に validate する
• tool result をそのまま model に返す前に、想定外のデータを含まないか確認する

MCP の prompt injection 対策は、「プロンプトを頑張って書く」より、どの入力を untrusted data と見なすかを決める方が重要です。

4. remote 接続時のデータガバナンス

OpenAI の MCP / connectors ガイドでも、remote MCP server は third-party system との接続であり、そこへデータが送られる前提で設計すべきことが示されています。社内文書、顧客情報、ソースコードを扱う場合は、server 側の retention policy や telemetry を確認しないまま接続してはいけません。

最低限、次を確認してください。

• どのデータが server 側へ送られるか
• ログや analytics に何が残るか
• データ保存期間と削除手段は何か
• 地理制約や社内ポリシー違反がないか

MCPとA2Aの違い

MCP と A2A は、置き換え関係よりも役割分担で考えると整理しやすくなります。Google の公式説明でも、A2A は agent 同士の discovery / communication / coordination を扱う protocol とされています。

単一 agent がツールを触るだけなら、まず MCP の設計を固めれば十分です。複数 agent の分業や委譲を扱う段階で、A2A のような protocol を追加検討するとよい、という順番になります。

実装者が今すぐ確認するチェックリスト

MCPセキュリティ対策の優先度イメージ

優先度1: 信頼できる server だけを接続する

✅ server の運営元と配布元を確認する
✅ 必要な tools だけを有効にする
✅ destructive な操作には approval を挟む
✅ user に tool input / output を見せる導線を持つ

優先度2: 認証・認可を説明可能にする

✅ remote server では user identity と権限境界を明確にする
✅ token の保存場所と rotation 方針を決める
✅ tool ごとの access control を実装する
✅ 共有 credential 前提の運用を避ける

優先度3: untrusted input を前提に実装する

✅ shell / file path / URL を個別に validate する
✅ tool metadata をそのまま信用しない
✅ prompt injection を想定して確認 UI を設ける
✅ tool result を model に返す前に制限する

優先度4: 監査・運用を後回しにしない

✅ tool 呼び出しログと権限変更ログを残す
✅ 依存パッケージと server 実装を定期レビューする
✅ 送信データの範囲を社内ポリシーと照合する
✅ incident response と credential revoke 手順を用意する

よくある質問（FAQ）

Q1. MCPと通常のAPI連携は何が違いますか？

通常の API 連携はアプリごとに個別実装しがちですが、MCP は AI アプリから見た接続モデルを標準化します。tools / resources / prompts を同じ枠組みで扱えるため、接続と権限の考え方をそろえやすいのが違いです。

Q2. まず local MCP と remote MCP のどちらから始めるべきですか？

検証段階では local から始める方が扱いやすいです。remote は認証、ネットワーク到達性、token、データ保持、第三者運営 server の審査が増えるため、本番導入のレビュー項目が一気に増えます。

Q3. MCP server には必ず OAuth が必要ですか？

常に必須ではありません。ですが、remote server が user ごとのデータや実行権限を扱うなら、認証・認可の設計は必須です。重要なのは方式名よりも、「誰が」「何を」「どの範囲で」実行できるかを説明できることです。

Q4. A2Aも同時に導入すべきですか？

単一 agent が外部ツールを使う段階では、まず MCP のみで十分なことが多いです。複数 agent の委譲や協調を設計し始めたら、A2A のような agent 間 protocol を追加検討してください。

Q5. 既存のMCP serverを安全に使うにはどうすればよいですか？

信頼できる配布元かを確認し、公開 tools と必要権限をレビューし、approval UI とログを有効にしてください。便利そうな server をそのまま足すのではなく、新しい実行権限を追加しているという前提で審査するべきです。

まとめ

主要ポイント

1. MCPはAIアプリと外部システムをつなぐ標準: host / client / server の責務が整理され、tools / resources / prompts を共通の枠組みで扱える
2. 論点は件数ではなく trust boundary: どの server を信頼し、どこで approval し、どのデータを渡すかが本質
3. remote MCP は security review の粒度を上げる: 認証、token、data retention、監査ログまで含めて評価する必要がある
4. A2Aは補完的な選択肢: MCP がツール接続、A2A が agent 間協調という役割分担で考えると整理しやすい

次のステップ

• 開発者: 既存 server の tool input / output と validation を点検する
• Platform / Security: remote MCP 利用時の approval、token、logging の基準を決める
• プロダクト責任者: 「どのデータを MCP 経由で外部へ出してよいか」の運用ルールを先に定義する

関連記事

参考リソース

• What is the Model Context Protocol (MCP)?
• Architecture - Model Context Protocol
• Authorization - Model Context Protocol Specification
• Tools - Model Context Protocol Specification
• Connect to remote MCP Servers
• MCP and Connectors - OpenAI API
• Anthropic Connectors Directory FAQ
• Developer's Guide to AI Agent Protocols - Google Developers Blog
• Google Cloud donates A2A to Linux Foundation

本記事はネクサフローのAIテクノロジーシリーズの一部です。