MCPとは？AI×外部ツール連携を標準化するプロトコルの基礎と始め方

更新日:2026年4月8日作成日:2026年4月8日

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

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

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

MCPとは何か？AIと外部ツールをつなぐオープンプロトコル

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
実装量	AI 製品ごとに個別開発（N×M）	サーバー側 1 回＋クライアント側は共通方式（重複を削減）
再利用性	他の AI 製品では使えない	IDE、デスクトップ AI、API 経由で再利用しやすい
仕様の統一	各プロダクトが独自フォーマット	JSON-RPC 2.0 ベースの共通プロトコル
エコシステム	各社ごとのマーケットプレイス	MCP サーバーのオープンなレジストリが成長中

主要コンポーネントとclient-host-serverの動作フロー

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

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

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

プリミティブ	役割	具体例
Resources	データや metadata の読み取り	ドキュメント、DB スキーマ、設定情報
Prompts	テンプレートやワークフローの提供	サポート対応用プロンプト、分析手順
Tools	外部アクションの実行	DB クエリ、ファイル検索、API リクエスト

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

MCPが抱えるセキュリティリスクとは？

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 仕様のセキュリティ原則と、実際のプラットフォームが提供する制御機構を組み合わせて対策を構築する。

最小権限と実行範囲の制御

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

サーバー側の対策:

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

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

承認フローとhuman-in-the-loopの設計

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

影響度	承認方式	例
低（読み取りのみ）	自動承認	ドキュメント検索、ステータス確認
中（限定的な書き込み）	初回のみ承認	コメント投稿、ラベル変更
高（破壊的操作）	毎回承認	データ削除、設定変更、送金

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

認証・認可とtrust boundaryの管理

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

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

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

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

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

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

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

MCPを始める3つの実践パターン

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

既存サーバーをツールに接続して使う（最速）

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

VS Code での設定例:

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

json

{
  "servers": {
    "example-docs": {
      "type": "http",
      "url": "https://example.com/mcp"
    }
  }
}

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

Claude Desktop での設定例:

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

json

{
  "mcpServers": {
    "example-server": {
      "command": "/path/to/server-binary"
    }
  }
}

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

ローカルサーバーを自作して試す

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

大まかな流れ:

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

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

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

API経由でリモートサーバーを利用する

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

概念的な実装パターン:

python

response = client.responses.create(
    model="model-name",
    tools=[
        {
            "type": "mcp",
            "server_label": "internal_tools",
            "server_url": "https://your-mcp-server.example.com/sse",
            "require_approval": "always",
        },
    ],
    input="先月の売上データを集計して",
)

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

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

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

MCPが向いているケース・向かないケース

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

向いている業務と導入効果が出やすい条件

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

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

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

通常のAPI統合で十分なケースと導入判断のチェックポイント

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

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

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

チェック項目	Yes なら MCP 検討	No なら API 統合で十分
AI が接続する外部ツールは 3 つ以上か？	✓	—
状況に応じて呼ぶツールを動的に変えたいか？	✓	—
同じツール群を複数の AI アプリから利用するか？	✓	—
ツールの追加・変更が頻繁に発生するか？	✓	—

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

まとめ

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

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

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

参考文献

Model Context Protocol — 公式仕様（2025-03-26）https://modelcontextprotocol.io/specification/2025-03-26
Anthropic —「Introducing the Model Context Protocol」（2024-11-25）https://www.anthropic.com/news/model-context-protocol
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
OpenAI Developers —「MCP and Connectors」https://developers.openai.com/api/docs/guides/tools-connectors-mcp
MCP 公式 —「Build an MCP server」https://modelcontextprotocol.io/docs/develop/build-server

著者・監修者

Chi

ラオス国立大学で情報科学を専攻し、在学中は統計ソフトウェアの開発に従事。データ分析とプログラミングの基礎を実践的に培った。2021 年より Web・アプリケーション開発の道に進み、2023 年からはフロントエンドとバックエンドの両領域で本格的な開発経験を積む。当社では AI を活用した Web サービスの設計・開発を担当し、自然言語処理（NLP）、機械学習、生成 AI・大規模言語モデル（LLM）を業務システムに統合するプロジェクトに携わる。最新技術のキャッチアップに貪欲で、技術検証から本番実装までのスピード感を大切にしている。

お問い合わせはこちら