MCPとは？AI連携の標準規格を実装と統治の両面から解説

MCPとは何で、AI活用の何を変える規格なのか？

MCPはAIモデルと外部データや業務ツールをつなぐ共通の接続規格であり、連携開発の重複を解消する。

MCP（Model Context Protocol）は、Anthropicが2024年11月25日にオープン標準として公開したプロトコルである。生成AIやLLMを業務で使う際、これまでは「どのモデルを、どの社内システムに、どうつなぐか」を案件ごとに作り込む必要があった。MCPはこの接続部分を規格化し、AIエージェントが外部の情報源や操作対象へアクセスするための共通インターフェースを提供する。

公式ドキュメントでは、MCPをしばしば「AIアプリケーションにとってのUSB-Cポート」と表現している。端子の形を揃えることで、周辺機器の側もホストの側も互いの都合を知らずに接続できる――その発想をAI連携に持ち込んだものだと理解すると分かりやすい。

MCPの定義と基本構造はどうなっているか

MCPはJSON-RPC 2.0を土台に、ホスト・クライアント・サーバーの三層で接続を標準化する。

構成要素は次の3つに整理できる。

1. ホスト（Host）：AIアプリケーション本体。Claude Desktop、各種IDE、社内で開発したエージェント基盤などが該当する。
2. クライアント（Client）：ホスト内に置かれ、1つのMCPサーバーと1対1で接続を維持するコンポーネント。
3. サーバー（Server）：データや機能を外部に公開する側。社内Wiki、データベース、チケット管理、ファイルストレージなどをラップする。

サーバーが提供する機能は、大きく3種のプリミティブに分かれる。

逆方向にクライアントが提供する機能として、サーバーがモデル推論を要求する「Sampling」、アクセス可能なディレクトリ範囲を示す「Roots」、追加入力をユーザーに求める「Elicitation」がある。Elicitationは2025年6月18日版の仕様改訂で追加されたもので、処理の途中で人に確認を返す設計がしやすくなった。

通信方式（トランスポート）は、ローカルプロセス間のstdioと、リモート接続向けのStreamable HTTPが標準である。後者は2025年3月26日版の改訂で、従来のHTTP+SSE方式を置き換える形で導入された。

なぜ2024年以降に注目が集まったのか

Anthropicが2024年11月に公開し、OpenAIやGoogleが追随したことで事実上の標準に近づいた。

公開当初は「Anthropic独自の仕様」という見方も少なくなかった。潮目が変わったのは2025年に入ってからで、OpenAIが2025年3月にAgents SDKでのMCP対応を表明し、GoogleもGeminiおよびAgent Development Kit（ADK）での対応を進めた。MicrosoftはBuild 2025（2025年5月）でWindows 11およびCopilot Studioでの対応を発表している。主要ベンダーが揃って採用したことで、MCPは「特定企業の仕様」から「業界の共通語」へと性格を変えた。

その後、プロトコルの運営はAnthropic単独から、Linux Foundation傘下の中立的なガバナンス体制へ移す方向で整備が進んでいる。規格の継続性という観点では、この中立化は企業が採用判断をするうえで無視できない材料だ。

実務の肌感覚として言えば、この1年で「MCP対応していますか？」という問いが、ツール選定のチェック項目に自然に入ってくるようになった。DXの文脈で語られてきた「システム間連携のコスト」が、AI活用の局面で再び前景化している、と捉えるのが近い。

MCPは従来のAPI連携やプラグインと何が違うのか？

MCPは接続を一対一の個別実装からM×Nを解消する共通層へ移し、再利用性と保守性を高める。

違いの核心は「機能の豊富さ」ではなく「接続の設計思想」にある。従来型の連携は、AIアプリケーションM種類と社内システムN種類をつなぐのにM×N通りの実装を要した。MCPはあいだに共通規格を挟むことで、これをM+N通りに縮める。

API連携・関数呼び出しとの比較

APIは接続先ごとの作り込みが必要だが、MCPはサーバー実装を複数のAIクライアントで共有できる。

特に効くのが「動的な発見」だ。従来はツールを追加するたびにAIアプリ側の改修が要ったが、MCPではサーバー側で公開ツールを増やせばクライアントが接続時に検出する。運用フェーズでの改修負荷が明確に下がる。

一方で、MCPは既存APIを置き換えるものではない。MCPサーバーの中身は多くの場合、社内APIやデータベースへの薄いラッパーである。「APIをやめてMCPにする」のではなく、「APIの上にAI向けの共通ファサードを1枚かぶせる」という理解が実態に近い。

プラグイン方式やRAG構成との役割の違い

RAGは知識の検索、MCPは接続の標準化を担い、両者は競合ではなく補完関係として組み合わせる。

RAG（検索拡張生成）は、社内文書をベクトル化して検索し、その結果をLLMの入力に含める手法である。対してMCPは、その検索処理そのものを「どう呼び出すか」を決める規約にすぎない。実際の構成では、RAG検索エンジンをMCPサーバーとして公開し、AIエージェントがResourcesやToolsとして参照する形が自然だ。

かつてのChatGPTプラグインのようなベンダー固有の拡張機構とも異なる。プラグインが「特定の製品を拡張する仕組み」だったのに対し、MCPは「製品をまたいで通用する規格」を目指している点が決定的な差である。

企業がMCPを導入する手順はどう進めればよいのか？

導入は対象業務の選定から始め、接続先の棚卸し、検証、統制設計、本番展開の順で段階的に進める。

技術的には数時間でMCPサーバーを立てられる。難所はそこではなく、「どの権限を、誰の判断で、AIに渡すか」を組織として決める部分にある。手順設計はこの合意形成を織り込むべきだ。

対象業務と接続先をどう選ぶか

最初は問い合わせ対応や社内検索など、失敗コストが低く反復頻度の高い業務から選ぶのが現実的だ。

選定の判断軸を4つに整理する。

1. 反復頻度：月数十回以上発生し、手順が概ね定型化している業務か。
2. 情報の分散度：複数システムを横断して情報を集める必要があるか。MCPの利点が最も出る領域である。
3. 可逆性：AIの出力が誤っていた場合に人が取り消せるか。読み取り中心の業務から始める根拠になる。
4. データの機微度：個人情報や未公開の財務情報を含まないか。含む場合は認可設計を先行させる。

接続先の棚卸しでは、既存システムのAPI有無、認証方式、監査ログの取得可否を一覧化しておく。この段階で「APIはあるが監査ログが残らない」システムが見つかることは珍しくなく、MCP以前の課題として顕在化する。

PoCから本番展開までの段階設計

PoCは読み取り専用から始め、書き込み権限の付与は監査ログと承認フローの整備後に広げていく。

第4段階の「承認済みサーバーカタログ」は軽視されがちだが、実務上の効き目が大きい。誰でも任意のMCPサーバーを追加できる状態は、後述するサプライチェーンリスクを直接持ち込むためだ。情報システム部門が審査済みのサーバーを一覧化し、利用者はそこから選ぶ――という運用に落とし込めた組織のほうが、結果的に展開が速い印象がある。

MCP導入で押さえるべきセキュリティとガバナンスの論点は？

最大の論点はツール経由の権限濫用とプロンプトインジェクションで、認可と監査の設計が要となる。

MCPは「AIに実際の操作をさせる」規格である以上、従来のチャットボット導入とはリスクの質が異なる。誤った出力が返る問題ではなく、誤った操作が実行される問題として扱う必要がある。

認証・認可とトークンの扱い

2025年6月版仕様はMCPサーバーをOAuth 2.1のリソースサーバーと位置づけ、トークン転用を禁じる。

仕様上の要点は次のとおりである。

• MCPサーバーはOAuth 2.0 Protected Resource Metadata（RFC 9728）で認可サーバーの所在を示す。
• MCPクライアントはResource Indicators（RFC 8707）を用い、トークンの対象リソースを明示する。
• 受け取ったアクセストークンをそのまま下流APIへ渡す「トークンパススルー」は明確に禁止されている。

この禁止事項は「混乱した代理人（confused deputy）」問題への対策だ。MCPサーバーが広い権限を持つトークンを保持したまま複数の利用者を代理すると、本来アクセスできないデータを引き出せてしまう。実装時は、MCPサーバー自身が発行・管理するトークンと、下流システム向けの認可を分離するのが原則になる。

加えて、AIエージェントに付与する権限は人間の権限をそのまま複製しないほうがよい。人が持つ「できるが普段やらない操作」まで、エージェントは躊躇なく実行しうるからだ。

プロンプトインジェクションとサプライチェーン

ツール説明文に悪意ある指示を仕込む攻撃が現実にあり、サーバーの出所確認と権限最小化が要る。

MCP固有の攻撃面として、以下が繰り返し指摘されている。

ガバナンスの観点では、OWASPが公開しているLLMアプリケーション向けのリスク分類や、NIST AI Risk Management Frameworkのような既存の枠組みと接続して整理すると、社内の説明がしやすい。AX推進の現場では「新しい技術だから新しいルールが要る」と身構えるより、既存のシステム利用申請・権限管理プロセスにMCPサーバーを乗せる形のほうが定着しやすいように見える。

なお、破壊的操作を伴うツールについては、人間の承認を挟む設計（human-in-the-loop）を仕様レベルでも推奨している。承認画面を出すこと自体より、「何を承認しているか利用者が理解できる粒度で提示する」ことのほうが難しく、ここは設計の作り込みどころだ。

MCPはどの業務ユースケースで効果が出るのか？

効果が出やすいのは、複数システムを横断して情報を集め、定型の更新作業を伴う業務領域である。

単一システム内で完結する作業なら、そのシステムのAI機能を使えば足りる。MCPの価値は、システムの境界をまたぐときに立ち上がる。

社内ナレッジ検索とレポーティング

分散した文書・データベース・チャット履歴を横断参照させる用途は、導入初期の成果が見えやすい。

具体的には次のような形になる。

1. 社内問い合わせ対応：人事規程、経費精算ルール、情報システムFAQをそれぞれMCPサーバーとして公開し、AIエージェントが横断検索する。RAG検索エンジンをツールとして束ねる構成が一般的だ。
2. 定例レポート作成：BIツールと案件管理システムに接続し、数値の取得から草案作成までを自動化する。数値の出所がツール呼び出しログとして残るため、確認作業が楽になる。
3. 契約・見積の照合：ファイルストレージと基幹システムを接続し、条件の突合を支援する。判断は人が行い、AIは差分の抽出に留める分担が現実的である。

いずれも読み取り中心であり、第1〜第2段階から着手できる。

開発・運用と顧客対応の自動化

コードベース・チケット・監視ログを接続する開発運用領域は、MCPサーバーの選択肢が最も充実している。

ソフトウェア開発では、Gitホスティング、課題管理、CI/CD、監視基盤へのMCPサーバーが早くから整備された。障害対応で「監視のアラート → 関連するコード変更 → 過去の類似チケット」を一連で辿る作業は、まさに境界をまたぐ典型例で、恩恵が大きい。

顧客対応では、CRMと問い合わせ管理、在庫・配送状況を接続し、一次回答の草案生成に使う形が増えている。ここは書き込み権限が絡むため、顧客への送信前に必ず人が確認するフローを崩さないことが前提になる。

注意点として、MCPサーバーを増やしすぎるとツール一覧が肥大し、モデルが適切なツールを選べなくなる現象が起きる。1つのエージェントに接続するサーバーは用途別に絞り、役割の異なるエージェントを複数用意するほうが、結果的に精度も統制も保ちやすい。この「つなぎすぎない設計」は、規格が便利になったからこそ意識したい論点である。

主な出典

• Model Context Protocol 公式ドキュメント（modelcontextprotocol.io）— アーキテクチャ、プリミティブ、トランスポート仕様
• Model Context Protocol Specification 2025-03-26／2025-06-18 — 認可仕様、Streamable HTTP、Elicitation、セキュリティ・ベストプラクティス
• Anthropic「Introducing the Model Context Protocol」（2024年11月25日）— 規格の公開発表
• OpenAI Agents SDK ドキュメント、Google Agent Development Kit ドキュメント、Microsoft Build 2025 発表 — 各社の対応状況
• RFC 8707（Resource Indicators for OAuth 2.0）、RFC 9728（OAuth 2.0 Protected Resource Metadata）
• OWASP Top 10 for LLM Applications、NIST AI Risk Management Framework — リスク整理の枠組み

本稿は実務者向けの解説であり、個別システムへの適用にあたっては自社のセキュリティポリシーおよび法務要件の確認を推奨する。

姉妹メディアの関連記事