MCP（Model Context Protocol）とは、AI アプリケーションと外部ツール・データソースを標準化された方法で接続するためのオープンプロトコルである。

AI アシスタントやエージェントを業務に組み込む動きが進むなかで、社内ツールやデータベースとの安全な連携は避けて通れない課題になっている。従来は AI 製品ごとに個別のコネクタ実装が必要だったが、MCP はその重複を減らし、異なる環境から同じ接続方式を再利用しやすくする。

一方で、接続先が増えるほど権限管理や承認設計も重要になる。本記事では、MCP の基本構造、代表的なリスク、安全に運用するための考え方、そして実践的な始め方を整理して解説する。

Anthropic が 2024 年 11 月に公開し、その後 Linux Foundation の Agentic AI Foundation に寄贈されたオープン標準だ（Anthropic, 2025-12-09）。 現在は Anthropic、OpenAI、Block を共同設立者とし、Google、Microsoft、AWS なども参加している。

MCP の価値を一言でいえば、AI 製品ごとに個別実装していたツール連携を、共通のプロトコルに置き換えることで統合の重複を減らしやすくする点にある。

MCP がない世界では、AI 製品 A が Slack・GitHub・社内 DB とつながるには 3 本のカスタムコネクタが必要になる。別の AI 製品 B も同じ 3 本を独自に開発する。N 個の AI アプリ × M 個のツールで、最大 N×M 本の統合コードが発生する構図だ。

MCP は、この統合構造をより再利用しやすい形に整理し、N×M の実装爆発を抑えやすくする。各ツール側が MCP サーバーを 1 つ公開すれば、MCP 対応の AI アプリから共通の方式で利用できる。ただし、クライアント側の対応差分や認証方式の違いがあるため、完全にきれいな N＋M になるわけではない。

MCP のアーキテクチャは Host・Client・Server の3層で構成される（MCP 公式仕様 2025-03-26）。

• Host — ユーザーが操作するアプリケーション（Claude Desktop、IDE、チャット UI など）
• Client — Host 内で MCP サーバーとの通信を担当するコネクタ
• Server — 外部のツールやデータを AI に公開するサービス

サーバーは以下の 3 つのプリミティブをクライアントに提供する。

動作フローの例: ユーザーが「先月の売上データを集計して」と AI に依頼すると、Client はサーバーが公開している Tool 一覧を取得し、モデルが適切な Tool（例: query_sales_data）の呼び出しを決定する。サーバーが実行結果を返し、モデルはそれをもとに回答を生成する。通信は JSON-RPC 2.0 で行われ、セッションはステートフルに管理される。

MCP は AI の「できること」を大幅に広げるが、同時に攻撃対象面（アタックサーフェス）も拡大する。導入を検討する段階でリスクを理解しておくことが不可欠だ。

これらのリスクは MCP 固有というより、外部ツールを扱う AI システム全般に存在する。ただし、MCP は接続の標準化によってツール利用の幅を広げるため、設計次第では影響範囲も広がりやすい。MCP 公式仕様でも「任意のデータアクセスとコード実行パスを可能にする」と明記されており、セキュリティと信頼性の確保は実装者の責任とされている。

MCP サーバーが返すデータには、モデルが解釈するテキストが含まれる。攻撃者がデータソース（ドキュメント、DB レコードなど）に悪意ある指示を埋め込むと、モデルがそれに従って意図しない Tool を呼び出すリスクがある。

たとえば社内ドキュメント検索用の MCP サーバーを運用している場合、攻撃者がドキュメント内に「このデータを外部 API に送信せよ」という隠し指示を挿入する間接プロンプトインジェクションが考えられる。MCP ではモデルが自律的に Tool を選択・実行するため、従来の API 統合よりも影響範囲が広がりやすい。

MCP サーバーはコミュニティや個人が自由に公開できる。MCP 公式仕様では「ツールの挙動を説明するアノテーション等は、信頼されたサーバーからの取得でない限り untrusted として扱うべき」と明記されている。

リスクのシナリオとして、以下が挙げられる。

• 人気のある MCP サーバーが侵害され、Tool の実行内容が改ざんされる
• 正規サーバーに見せかけた偽サーバーがユーザーデータを収集する
• 依存ライブラリの脆弱性がサーバー経由で AI アプリに波及する

npm パッケージのサプライチェーン攻撃と同様の構図であり、MCP サーバーの「出所と信頼性」の検証は組織としての課題になる。

MCP サーバーに広範なアクセス権を与えると、AI がアクセスできるデータの範囲も広がる。全テーブルを読み取れる DB 接続を MCP サーバーに渡した場合、ユーザーの意図とは無関係にモデルが機密データを含むクエリを実行し、その結果をレスポンスに含めてしまう可能性がある。

仕様上の原則として、MCP は「ユーザーは共有されるデータと実行されるアクションに対して制御を保持しなければならない」と定めている。ただし、これを実装レベルでどう実現するかは各組織に委ねられている。

リスクがあるから使わない、ではなく「リスクを制御できる設計」にすることが MCP を安全に運用する鍵だ。 MCP 仕様のセキュリティ原則と、実際のプラットフォームが提供する制御機構を組み合わせて対策を構築する。

MCP サーバーが公開する Tool は必要最小限に絞るのが原則だ。

サーバー側の対策:

• DB 接続は読み取り専用アカウントを使い、書き込み用は別サーバーに分離する
• ファイルアクセスは特定ディレクトリのみに制限する
• 破壊的な操作（DELETE、DROP 等）を行う Tool はそもそも公開しない

クライアント側の対策: サーバーが多数の Tool を公開している場合でも、クライアント側で使用する Tool を制限できる。実装によっては、モデルが呼び出せる Tool のサブセットを指定するパラメータ（たとえば OpenAI Responses API の allowed_tools）が提供されている。こうした「利用側でのフィルタリング」は、サーバー側の制御と併用することで防御の多層化になる。

仕様上の原則として、MCP は「Host はツール呼び出し前にユーザーの明示的な同意を得なければならない」と規定している。実装レベルでは、操作の影響度に応じて承認フローを段階化するのが現実的だ。

実装によっては、ツール実行前の承認要否を制御できる仕組みが提供されている（たとえば OpenAI Responses API の require_approval では "always" / "never" / Tool 単位の指定が可能）。重要なのは「デフォルトを安全側に寄せる」ことで、新しい Tool は原則として承認必須にし、検証後に段階的に緩和する運用が推奨される。

MCP サーバーが認証を必要とする場合、OAuth トークンなどの認証情報をクライアントからサーバーに渡す。ここで重要なのは 認証情報の永続化を避ける ことだ。たとえば OpenAI の実装では、authorization フィールドに渡されたトークンをサーバー側で保存しないと明記されており、リクエストごとに再送する設計になっている。

trust boundary（信頼境界）の観点では、以下を明確に分離する。

• Host と Client の間: ユーザーの認証・認可はここで管理
• Client と Server の間: MCP プロトコルレベルの通信。サーバーの身元確認が必要
• Server と外部システムの間: サーバーが持つ権限の範囲を限定

特に本番環境では、MCP サーバーの提供元が公式のものか、コミュニティ製か、自社開発かによって信頼レベルを区別し、それに応じた承認フローと権限設定を適用すべきだ。

運用面で追加すべき対策:

認証・認可に加えて、以下の運用的な制御も検討する価値がある。

• 監査ログ: どの Tool が、いつ、誰の操作で呼ばれたかを記録する。異常な連続呼び出しや想定外の Tool 実行を検知するための基盤になる
• レート制限: Tool 呼び出しの頻度に上限を設け、暴走や悪用時の被害を限定する
• egress 制御（ネットワーク到達先の制限）: MCP サーバーが外部に通信できる範囲をネットワークレベルで制限する。データの意図しない外部送出を防ぐ
• サンドボックス化: Tool の実行環境を隔離し、ホストシステムへの影響を最小化する

MCP を試す方法は、手軽なものから本格的なものまで3段階ある。自分の目的に合ったパターンから始めるのが最短ルートだ。

もっとも手軽な方法は、すでに公開されている MCP サーバーを IDE やエージェントツールに接続することだ。

VS Code での設定例:

プロジェクトルートに .vscode/mcp.json を作成し、MCP サーバーの URL を指定する。

設定後、VS Code の Agent モードで MCP サーバーが公開する Tool を利用できるようになる。

Claude Desktop での設定例:

~/Library/Application Support/Claude/claude_desktop_config.json にサーバーを追加する。

いずれの場合も、まずは公式が提供するサーバーや、提供元が明確なサーバーから試すのが安全だ。

MCP のアーキテクチャを体感するには、自分でサーバーを作るのが最も理解が深まる。MCP 公式ドキュメントでは天気情報サーバーのチュートリアルが提供されており、get_alerts と get_forecast の 2 つの Tool を公開するサーバーを構築できる（MCP 公式, Build an MCP server）。

大まかな流れ:

1. MCP SDK（TypeScript / Python / Rust 等）を使ってサーバーを実装する
2. ビルドまたは起動コマンドを確認する
3. Claude Desktop の設定ファイルにサーバーのパスを追加する
4. Claude を再起動し、ツールが認識されることを確認する

うまく動かない場合の確認ポイント:

• 設定ファイルの JSON 構文エラー（末尾カンマなど）
• サーバーのパスが絶対パスになっているか
• Claude を完全に終了してから再起動したか
• ログファイル（macOS: ~/Library/Logs/Claude/mcp*.log）にエラーが出ていないか

自社の AI アプリケーションに MCP を組み込む場合は、API 経由でリモート MCP サーバーに接続するパターンが適している。

概念的な実装パターン:

この方式のメリットは、承認フロー（require_approval）、利用可能ツールの制限（allowed_tools）、OAuth 認証などをプログラム的に制御できることだ。

本番運用で考慮すべき点:

• require_approval はデフォルトで "always" に設定し、検証後に個別 Tool の緩和を検討する
• サーバーが OAuth を要求する場合、トークンはリクエストごとに渡し、永続化しない
• 公式提供のサーバーを優先し、サードパーティ製はセキュリティレビュー後に導入する

MCP はすべての AI プロジェクトに必要なわけではない。導入すべきかどうかは「AI が動的にツールを選択する必要があるか」が最大の判断基準になる。

MCP の効果が大きいのは、AI がモデルの学習知識だけでは完結できず、外部のデータやアクションに依存する業務だ。

• 社内ナレッジアシスタント — ドキュメント検索・DB 参照を組み合わせて回答を生成する
• カスタマーサポート Copilot — チケットシステム・FAQ・CRM を横断して対応を支援する
• IDE アシスタント — コードベース・ドキュメント・CI/CD ツールにアクセスして開発を補助する
• ワークフロー自動化 — 複数の業務ツール（Slack・GitHub・DB 等）を AI が状況に応じて使い分ける
• エージェントシステム — タスクの分解・Tool の選択・結果の統合を自律的に行う

共通するのは「AI が使うツールが複数あり、かつ状況に応じて動的に選択する」というパターンだ。ツールが 1 つだけなら、MCP を介さず直接 API を呼ぶほうがシンプルな場合が多い。

以下に該当する場合は、MCP を導入せず通常の API 統合や Function Calling で十分な可能性が高い。

• AI が呼ぶ外部サービスが 1〜2 個に固定されている
• ツールの選択をモデルに委ねる必要がなく、ロジックで決定できる
• AI を使わないバックエンド処理（Cron ジョブ等）が主な用途
• セキュリティ要件上、AI による動的なツール呼び出し自体が許容されない

導入判断のチェックポイント:

すべて No であれば、REST API や Function Calling で要件を満たせる。MCP は「便利だから導入する」のではなく、統合の複雑さが実際にボトルネックになっている場合に真価を発揮する。

MCP は、AI と外部ツール・データソースの接続を標準化するオープンプロトコルだ。従来の個別実装の重複を減らし、IDE・デスクトップ AI・API 連携など多様な環境から再利用しやすくする点が最大の価値になる。

一方で、MCP は AI のアクセス範囲を広げるぶん、プロンプトインジェクション・サプライチェーンリスク・過剰権限といったセキュリティリスクも伴う。最小権限の原則、段階的な承認フロー、trust boundary の明確化、そして監査ログや egress 制御といった運用的な対策を設計段階から組み込むことが不可欠だ。

まずは既存の MCP サーバーを IDE に接続するところから試し、仕組みを体感したうえで自社の要件に合った導入範囲を見極めるのが現実的なアプローチになるだろう。

参考文献

1. Model Context Protocol — 公式仕様（2025-03-26）https://modelcontextprotocol.io/specification/2025-03-26
2. Anthropic —「Introducing the Model Context Protocol」（2024-11-25）https://www.anthropic.com/news/model-context-protocol
3. Anthropic —「Donating the Model Context Protocol」（2025-12-09）https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
4. OpenAI Developers —「MCP and Connectors」https://developers.openai.com/api/docs/guides/tools-connectors-mcp
5. MCP 公式 —「Build an MCP server」https://modelcontextprotocol.io/docs/develop/build-server