MCP（Model Context Protocol）は、AIアプリケーションと外部のツール・データをつなぐためのオープンなプロトコルです。ただし、MCPを使えば自動的に安全になるわけではありません。公式仕様自身が、ユーザーの同意やデータ保護などの原則について「MCP自体はプロトコルのレベルでこれらのセキュリティ原則を強制できない」と明記しており、実装する側が認可・権限・監視の仕組みを組み込む必要があります。
本記事では、2026年11月時点で公開されている最新のMCP仕様（2026-07-28版）と公式のセキュリティベストプラクティスにもとづき、MCPの仕様が定めていることと、クライアント・サーバー・ゲートウェイ・インフラ側で追加すべき対策を分けて整理します。MCPの基本はMCPとは？、AIエージェント全体のアーキテクチャはAIエージェントのセキュリティ対策で解説しています。
MCPのアーキテクチャと構成要素
| 構成要素 | 役割 | 例 |
|---|---|---|
| ホスト | AIアプリケーション本体。接続を開始する | AIアシスタント、AIエージェント、開発ツール |
| クライアント | ホストの中で、各MCPサーバーと接続する部分 | ホストに組み込まれた接続機能 |
| サーバー | ツールやデータを提供する | CRM・ファイル・データベースへの接続 |
MCPサーバーが提供する主な機能は、ツール（AIが実行する関数）、リソース（AIや利用者が参照するデータ）、プロンプト（定型の指示）です。メッセージの形式にはJSON-RPC 2.0が使われます。
- 利用者
- ホスト（AIアプリ）MCPクライアントを内包
- MCPサーバーツール・リソースを提供
- 社内システム・外部API
なぜMCPは企業のAIエージェントにとって重要なのか
AIエージェントが業務を進めるには、CRM・チャット・ファイル・データベースなどへの接続が欠かせません。MCPは、その接続方法を共通化することで、一度作った接続を複数のAIアプリケーションから再利用しやすくするものです。
一方で、MCPサーバーはAIと業務データの境界に位置します。ここが侵害されたり、権限が広すぎたりすると、複数のシステムに影響が連鎖します。だからこそ、MCPは「便利な接続口」であると同時に、最も重点的に統制すべき場所でもあります。
MCP仕様が定めることと、定めないこと
| 項目 | 仕様が定めること | 実装側で追加が必要なこと |
|---|---|---|
| 認可 | HTTPベースの通信で認可を実装する場合の方式（OAuth 2.1をベースにした仕組み）。ただし認可の実装自体は任意（OPTIONAL） | どの利用者に、どのツール・データを許可するかの業務上のルール |
| トークン | MCPサーバーは自分宛てに発行されたトークンのみを受け入れる（オーディエンスの検証）。他のトークンをそのまま下流へ渡すこと（トークンパススルー）は禁止 | トークンの安全な保管、有効期限、失効の運用 |
| スコープ | 最小権限の考え方（必要なスコープを段階的に要求する） | 業務に合わせたスコープの設計 |
| ユーザーの同意 | ツール実行やデータ共有の前に、ホストが明示的な同意を得るべきという原則 | 承認画面・承認ルール・承認の記録 |
| ツールの説明 | 信頼できないサーバーからのツールの説明（注釈など）は信頼しないものとして扱う | サーバーの審査、許可リスト |
| 監視 | 定めていない | ログ、異常検知、停止手段 |
| ネットワーク | 定めていない（SSRF対策などはベストプラクティスとして推奨） | 送信先の制限、ゲートウェイ、ネットワーク分離 |
MCPの脅威モデル
| 脅威 | 内容 | 主な対策 |
|---|---|---|
| 信頼できないMCPサーバー | 悪意あるサーバーや、改ざんされた配布物を導入してしまう | 許可リスト、提供元の審査、バージョン固定 |
| ツールの説明を使った誘導 | ツールの説明文に紛れた指示で、AIが意図しない動作をする | 説明文を信頼しない設計、ツールの審査 |
| 外部ツール経由のプロンプトインジェクション | ツールが返したメール・文書などの内容にAIへの指示が含まれる | ツール結果をデータとして扱う、重要操作の承認 |
| トークンの不正利用 | 広いスコープのトークンが漏えいし、多くの操作に悪用される | 最小スコープ、短い有効期限、オーディエンス検証 |
| トークンパススルー | MCPサーバーが受け取ったトークンを検証せず下流APIに渡す | 仕様どおり禁止し、自サーバー宛てのトークンのみ受け入れる |
| Confused deputy（混乱した代理人） | OAuthプロキシ型のサーバーで、利用者の同意をすり抜けて認可コードが攻撃者に渡る | クライアントごとの同意、リダイレクトURIの完全一致の検証 |
| SSRF | 悪意あるサーバーが、クライアントに社内やクラウドのメタデータへアクセスさせる | HTTPSの強制、プライベートIP宛ての遮断、送信用プロキシ |
| ローカルサーバーの侵害 | ローカルで動くサーバーの起動コマンドに悪意ある処理が含まれる | 実行前の同意と確認、サンドボックス、最小権限 |
| 状態ハンドルの乗っ取り | 他の利用者の作業IDなどを推測・取得して操作する | ハンドルを利用者に紐づけ、推測困難な値にする |
| データの持ち出し | ツールの結果が別のツール経由で外部に送られる | 送信系ツールの制限、データの分類、承認 |
脅威の中でも、プロンプトインジェクションや情報漏えいの基本的な仕組みは、生成AIの情報漏えいリスクと対策で事例とともに解説しています。
認証と認可の考え方
仕様にもとづく認可（HTTPの場合）
- MCPサーバーはOAuth 2.1の「リソースサーバー」として、アクセストークンを検証する
- クライアントは、どのMCPサーバー向けのトークンかを明示する（リソースインジケーター）
- MCPサーバーは、自分宛てに発行されたトークンだけを受け入れる
- トークンはURLのクエリ文字列に含めない
実装側で決めること
- どの利用者・どの部署に、どのMCPサーバーとツールの利用を許可するか
- AIエージェントが使うトークンのスコープと有効期限
- 退職・異動時のアクセス停止の手順
ツール権限の管理マトリクス（例）
| ツールの種類 | 例 | 初期設定 | 承認 | 備考 |
|---|---|---|---|---|
| 検索・参照（公開・社内一般） | マニュアル検索 | 許可 | 不要 | 参照範囲を限定 |
| 参照（機密・個人情報を含む） | 顧客情報の参照 | 限定許可 | 不要（ただし利用者本人の権限内） | 利用者の閲覧権限を超えない |
| 下書き作成 | メール・文書の下書き | 許可 | 不要 | 送信機能と分離する |
| 書き込み | CRMの項目更新 | 限定許可 | 人の承認 | 対象件数の上限を設定 |
| 外部への送信 | メール送信、外部API呼び出し | 原則無効 | 人の承認 | 宛先の許可リスト |
| 削除・一括変更 | レコード削除、一括更新 | 無効 | 管理者の承認 | 原則としてAIには許可しない |
| 管理操作 | 権限・設定の変更 | 無効 | − | AIには許可しない |
安全な構成と危険な構成の比較
| 観点 | 危険な構成 | 安全な構成 |
|---|---|---|
| サーバーの導入 | 社員が任意のMCPサーバーを追加できる | 承認済みサーバーの許可リストのみ |
| 認証情報 | 管理者権限のAPIキーを設定ファイルに直接記載 | 用途を限定したトークン、秘密情報の管理基盤 |
| トークン | 受け取ったトークンを検証せず下流に渡す | 自サーバー宛てのトークンのみ受け入れ、下流には別のトークンを使用 |
| ツール | 「何でもできる」汎用ツールを1つ公開 | 操作ごとに機能を絞ったツールを公開 |
| 承認 | AIの判断でそのまま実行 | 送信・更新・削除はAIの外側で承認を判定 |
| ネットワーク | 社内ネットワークに自由にアクセスできる | 送信先を制限し、ゲートウェイを経由 |
| ローカル実行 | 起動コマンドを確認せず実行 | 実行前に内容を確認し、サンドボックスで実行 |
| ログ | 記録しない | ツール呼び出し・承認・結果を記録し、定期的に確認 |
- AIアプリMCPクライアント
- MCPゲートウェイ許可リスト・認可・ログ
- MCPサーバー機能を絞ったツール
- 社内API利用者権限で実行
プロンプトインジェクションへの備え
MCPのツールが返す内容（メール本文、Webページ、文書など）は、攻撃者が書いた文章を含みうるものとして扱います。
- ツールの結果を「データ」として扱い、AIへの指示として扱わない設計にする
- 外部の内容を読んだあとに、送信・更新などの操作を行う場合は人の承認を挟む
- 1回の依頼で実行できる操作の範囲と回数に上限を設ける
ログとモニタリング
| 記録する項目 | 目的 |
|---|---|
| 接続したMCPサーバーとバージョン | 不審なサーバーや変更を検知する |
| 呼び出したツール・引数・結果の概要 | 何が実行されたかを追跡する |
| 認可の成否・スコープの要求 | 権限の過剰な要求を検知する |
| 承認・拒否の記録 | 統制が機能しているかを確認する |
ログに認証情報や個人情報をそのまま残さないよう、マスキングのルールも決めておきましょう。
実装の推奨事項
- 導入するMCPサーバーを許可リストで管理する：提供元・配布元・バージョンを確認する
- 認可を有効にする（HTTPの場合）：仕様にもとづくOAuth 2.1の仕組みを実装し、トークンのオーディエンスを検証する
- スコープを最小にする：最初は参照系のみ。必要に応じて段階的に追加する
- ツールを細かく分ける：汎用的な「何でも実行」ツールを公開しない
- 重要な操作は承認制にする：承認の要否はAIの外側で判定する
- 送信先を制限する：SSRF対策として、プライベートIP宛ての通信を遮断する
- ローカル実行はサンドボックスで：起動コマンドの確認と最小権限
- ログを残し、定期的に確認する：異常時の停止手順も決めておく
導入チェックリスト
- 利用するMCPサーバーの許可リストを作成した
- サーバーの提供元・配布元・バージョンを確認した
- HTTP接続のサーバーで認可を有効にし、トークンのオーディエンスを検証している
- トークンパススルーを行っていない
- スコープを最小にし、段階的に追加する運用にした
- ツールごとに許可・承認・禁止を決めた
- 送信・更新・削除の操作に承認を設けた
- 送信先の制限（SSRF対策）を行った
- ローカルで動くサーバーはサンドボックスで実行している
- ツール呼び出しと認可のログを記録し、確認者を決めた
- 異常時にMCP接続を停止する手順を決めた
FlowStack Labsの見解：MCPサーバーは「社内APIと同じ基準」で審査する
MCPサーバーは「AI用の便利なプラグイン」と捉えられがちですが、実際には社内データやシステムに対する新しいアクセス経路です。FlowStack Labsでは、MCPサーバーを導入・開発する際に、社内APIや外部連携と同じ審査基準を適用することを推奨しています。
| 審査項目 | 確認すること |
|---|---|
| 提供元と配布元 | 公式の提供元か、改ざんされていないか、バージョンを固定できるか |
| 公開するツール | 必要な操作だけか。「何でも実行できる」汎用ツールがないか |
| 認証・認可 | HTTP接続では認可を有効にし、トークンのオーディエンスを検証しているか |
| 実行環境 | ローカル実行の場合、権限を絞った環境（サンドボックス）か |
| 記録 | ツール呼び出しと認可の結果を記録しているか |
よくある質問
QMCPに対応したサービスを使えば、セキュリティは十分ですか？
十分ではありません。MCP仕様は接続と認可の方式を定めていますが、認可の実装は任意で、どのツールを誰に許可するか、どの操作に承認が必要かといった業務上の統制は、実装する側が設ける必要があります。
Q公開されているMCPサーバーを社内で使っても大丈夫ですか？
提供元・配布元・権限の範囲を確認し、許可リストで管理したうえで利用してください。ローカルで動かす場合は、起動コマンドを確認し、サンドボックスなど権限を絞った環境で実行するのが安全です。
QOAuthを実装すれば、権限管理は完了ですか？
OAuthは「誰が、どのスコープでアクセスできるか」を扱う仕組みです。AIエージェントが実行する個々の操作に人の承認が必要かどうか、1回の依頼でどこまで実行してよいかなどは、別途ポリシーとして設計する必要があります。
QMCPゲートウェイは必須ですか？
仕様上の必須要件ではありません。ただし、複数のMCPサーバーを使う場合は、許可リスト・認可・ログを一元管理できるため、企業での運用には有効な選択肢です。
Q社内で独自のMCPサーバーを開発するときの注意点は？
自サーバー宛てのトークンのみを受け入れること、ツールの機能を絞ること、入力値を検証すること、ログを残すことが基本です。OAuthプロキシとして外部APIにつなぐ場合は、クライアントごとの同意やリダイレクトURIの検証など、公式のセキュリティベストプラクティスの要件を確認してください。
まとめ
- MCPはAIと社内ツールをつなぐ共通ルールだが、セキュリティを自動的に保証するものではない
- 仕様は認可（OAuth 2.1ベース、任意）、トークンのオーディエンス検証、パススルーの禁止などを定める
- 許可リスト・最小スコープ・承認・送信先の制限・ログは、実装側で追加する統制
- 脅威モデルと権限管理マトリクスで、導入前にリスクを洗い出す
FlowStack Labsでは、MCPを使ったAIエージェントと社内システムの連携を、認可・権限設計を含めてご支援しています。設計のレビューや導入のご相談は、無料相談からお気軽にどうぞ。
