AIエージェントに社内のデータを読ませたり、業務システムを操作させたりするとき、つなぎ方を製品ごとに作り込む手間が問題になる。この接続を共通の規格にしたのがMCP（Model Context Protocol）である。2024年11月にAnthropicが公開し、2025年12月にはLinux Foundation傘下のAgentic AI Foundationへ寄贈された。
日本の行政でも動きがある。デジタル庁は2026年7月21日の「デジタル社会の実現に向けた重点計画」で、行政システムのMCP等への対応方針を令和8年度に結論づけ、マイナポータルでは令和9年度中を目途にMCP等の基盤構築を目指すとした。
- MCPは、AIアプリ（ホスト）と、データや機能を提供するMCPサーバーをつなぐ規格である。ホストは接続先ごとにクライアントを用意し、クライアントとサーバーが1対1でつながる。通信はJSON-RPC 2.0で行う
- 現行の仕様は2026-07-28版。接続開始時の
initializeによる手続きが廃止され、リクエストごとに完結する方式に変わった。古い説明のまま実装すると、新しいサーバーにつながらない組み合わせが出る - 仕様はツール実行の前に人が拒否できること、ツールの自己申告を信頼しないことを求めている。ただし仕様自身が書くとおり、プロトコルでは強制できない
- 企業での導入は、使ってよいサーバー、誰の権限で動くか、公開する操作、実行前の確認、記録の5点を先に決めると進めやすい
本記事は、仕様の公式ページ（modelcontextprotocol.io）と各社の公式ドキュメントを2026年11月5日に確認した内容で書いている。
この記事の対象読者
- AIエージェントを社内システムやSaaSにつなぐ計画があり、MCPを採用するか判断したい情報システム部門・DX推進部門
- 現場からMCPサーバーを使いたいと申請が来ているが、許可の基準を持っていないセキュリティ担当者
- 自社の製品やデータをMCPサーバーとして提供するか検討しているプロダクト責任者
MCPとは（要点3行）
- MCPは、AIアプリが外部のデータや機能を使うための共通の接続規格である。仕様の公式サイトは、AIアプリにとってのUSB-Cポートにたとえている
- 使う側（ホストとクライアント）と提供する側（サーバー）に分かれ、サーバーは「ツール」「リソース」「プロンプト」の3つを提供する
- つなぎやすくなるぶん、AIが動かせる範囲も広がる。どのサーバーを、誰の権限で、どこまで使わせるかを導入する企業が決める必要がある
MCPが必要になった理由
MCPが出る前は、AIアプリに社内システムを使わせるたびに、アプリごと・システムごとに連携を作る必要があった。AIアプリがM種類、つなぐ先がN種類あれば、連携はM×N通りになる。
MCPでは、つなぐ先のシステムがMCPサーバーを1つ用意すれば、MCPに対応したどのAIアプリからも同じ方法で使える。AIアプリの側も、MCPクライアントを1つ実装すれば多くのサーバーを使える。連携の数はM＋N通りに減る。
対応も広がっている。OpenAIはResponses APIでリモートのMCPサーバーを呼べるようにし、GoogleはGoogle Cloudのサービス向けにマネージドなMCPサーバーを提供している。AWSはAmazon Bedrock AgentCore GatewayでMCPサーバーを接続先にでき、対応するプロトコルの版に2026-07-28版を含めている。
MCPの仕組み
ホスト・クライアント・サーバーの3つの役割
仕様は役割を3つに分けている。
| 役割 | 何をするか | 例 |
|---|---|---|
| ホスト | 利用者が操作するAIアプリ。複数のクライアントを立ち上げて管理し、接続の許可、同意の取得、LLMとの連携を受け持つ | Claude、ChatGPT、社内で作ったAIエージェント |
| クライアント | ホストの中で、1つのサーバーとの接続を受け持つ部品。クライアントとサーバーは1対1 | ホストが接続先ごとに用意する |
| サーバー | データや機能をAIに提供するプログラム。PC上のプロセスでも、ネットワーク越しのサービスでもよい | ファイル検索、CRM、チケット管理、データベース |
仕様の設計原則では、サーバーに会話の全体を読ませず、ほかのサーバーの中身も見せないことを求めている。会話の履歴はホストに残り、サーバーには必要な情報だけを渡し、サーバーどうしの連携はホストが制御する。これはプロトコルが自動で守る仕組みではなく、ホストの実装で守るものである。企業の立場で言えば、どの情報をどのサーバーに渡すかを決める場所はホストである。
MCPサーバーが提供する3つの機能
| 機能 | 内容 | 企業での例 |
|---|---|---|
| ツール（Tools） | AIが実行する関数。AIが文脈に応じて自分で見つけて呼び出す | 案件の検索、チケットの起票、メールの下書き作成 |
| リソース（Resources） | AIや利用者が読むデータ | 社内規程の文書、顧客マスタの一部、設計書 |
| プロンプト（Prompts） | 利用者が選んで使う定型の指示やワークフロー | 週次報告の作成手順、問い合わせ一次回答の型 |
ツールは、権限設計で最も注意が要る機能になる。仕様はツールを「model-controlled」、つまりAIが判断して呼び出すものと定義している。読み取りだけのリソースと違い、ツールは書き込みや送信を伴うことがある。
接続方式：stdioとStreamable HTTP
標準の接続方式は2つある。
- stdio：ホストがMCPサーバーをPC上の子プロセスとして起動し、標準入出力でやり取りする。開発者のPCで動かすローカルのサーバーに使う。認可の仕様には従わず、資格情報は環境変数などから取る
- Streamable HTTP：ネットワーク越しのMCPサーバーに、HTTPのPOSTでメッセージを送る。社内システムやSaaSが提供するリモートのサーバーに使う。仕様上、認可の実装は任意（OPTIONAL）だが、実装する場合はOAuth 2.1をもとにした認可の仕様に従うことが推奨されている（SHOULD）
2024-11-05版にあったHTTP+SSE方式は、2026-07-28版で非推奨（Deprecated）に分類された。新しく作るなら選ばない。
2026-07-28版の仕様で変わったこと
MCPの仕様は日付で版を管理している。2024-11-05版、2025-03-26版、2025-06-18版、2025-11-25版と改訂され、2026年7月28日に公開された2026-07-28版が現行である。この版は後方互換のない変更を含むため、2025年までの解説記事をもとに実装すると食い違う点がある。
| 変わった点 | 2025-11-25版まで | 2026-07-28版 |
|---|---|---|
| 接続の開始 | initializeで版と機能を取り決めてから通信する | 手続きを廃止。リクエストごとに版とクライアントの機能を添えて送る |
| セッション | Mcp-Session-Idでセッションを維持する | プロトコルとしてのセッションを廃止。状態が必要ならサーバーが発行するIDをツールの引数で渡す |
| サーバーの情報の取得 | initializeの応答で知る | server/discoverで取得できる（サーバーは必ず実装する） |
| サーバーからの問い合わせ | サーバーがクライアントへ要求を送る | サーバーは「追加の入力が要る」という結果を返し、クライアントが入力を添えて元のリクエストを送り直す |
| Sampling・Roots・Logging | 仕様で定義（Sampling・Rootsはクライアント側、Loggingはサーバー側の機能） | 非推奨。新しい実装では採用しない |
非推奨の機能は、原則として12か月以上は仕様に残る（緊急時に90日へ短縮できる例外がある）。Sampling・Roots・Loggingが削除されるのは、早くても2027年7月28日以降に出る版である。HTTP+SSE方式の削除時期は別に定められている。
導入する企業が確かめるべきは、使うホストとサーバーがどの版に対応しているかである。仕様の互換性の表では、2025-11-25版までの方式にしか対応しないクライアントは、2026-07-28版の方式にしか対応しないサーバーにつながらない。
MCPとAPI連携・Function Callingの違い
| 比べる点 | 個別のAPI連携 | Function Calling | MCP |
|---|---|---|---|
| 何を決めるか | システムごとの呼び出し方 | 1つのAIアプリの中で、モデルに関数を選ばせる方法 | AIアプリと外部の機能をつなぐ共通の規格 |
| 誰が作るか | 連携ごとに開発する | AIアプリの開発者が関数を定義する | 提供する側がサーバーを1つ作り、MCP対応のアプリが共通に使う |
| 向いている場面 | 決まった処理を決まった順序で動かす | 自社アプリの中だけで使う少数の関数 | 複数のAIアプリから、同じ社内システムやSaaSを使わせる |
MCPはAPIを置き換えるものではない。多くのMCPサーバーは、内部で既存のAPIを呼んでいる。MCPが決めるのは、AIアプリから見た呼び出し方をそろえる部分である。
AIエージェントの構成全体は「AIエージェントとは？開発方法と企業導入の5ステップ」で解説している。
企業で使うときに起きやすい問題
つなぎやすさの裏返しとして、AIが触れられる範囲は広がる。仕様のSecurity Best Practicesは、実装と運用で起きうる問題を挙げている。企業の判断に関わるものを抜き出すと次のとおりである。
| 問題 | 何が起きるか | 仕様が示す対策 |
|---|---|---|
| トークンの使い回し（Token Passthrough） | MCPサーバーが、自分宛てでないトークンを受け取ってそのまま下流のAPIに渡す。下流の利用制限や監査ログをすり抜ける | サーバーは自分宛てに発行されていないトークンを受け入れてはならない（MUST NOT） |
| 混乱した代理人（Confused Deputy） | 外部のAPIに単一の固定IDでつなぐ中継サーバーで、利用者の同意を取らずに認可が通り、攻撃者に認可コードを奪われる | 中継サーバーはクライアントごとの同意を必ず取り、外部の認可に進む前に確認する |
| ローカルサーバーの乗っ取り | 設定に悪意あるコマンドが仕込まれ、PC上で任意のコードが実行される | ワンクリックの設定を提供するクライアントは、実行するコマンドを省略せずに表示し、明示的な承認を取る（MUST） |
| 過大なスコープ | 全権限のトークンを最初に取得し、漏えいしたときの被害が大きくなる | 最小のスコープで始め、必要な操作のときだけ追加で同意を取る |
| SSRF | 悪意あるサーバーが、認可の手続きを通じてクライアントに社内のアドレスへアクセスさせる | 本番ではHTTPSを使い、プライベートなIPアドレス帯への接続を止める |
加えて、ツールの説明文や「読み取り専用」などの注記（アノテーション）は、サーバーが自分で申告するものである。仕様は、信頼できるサーバー以外のアノテーションを信頼してはならない（MUST）としている。「削除はしない」と書かれたツールが実際に削除しないかは、申告では確かめられない。
承認していないMCPサーバーを社員が個人の判断でつなぐことは、シャドーAIの一種になる。検知と代替手段の考え方は「シャドーAI対策｜禁止だけで防げない理由と4つの制御点」にまとめた。
企業導入で決める5つの権限設計
仕様は、利用者がすべてのデータアクセスと操作に同意し、理解できることを原則に掲げる。同時に、MCPそのものはこの原則をプロトコルのレベルで強制できないと明記している。守らせる仕組みは、導入する企業が設計する必要がある。FDXでは次の5点を最初に決めることを勧めている。
1. 使ってよいサーバーを決める
最初に決めるのは、社内で使ってよいMCPサーバーの許可リストである。公式のMCP Registry（registry.modelcontextprotocol.io）は、公開されているサーバーの情報を集めた場所で、2026年11月5日の確認ではプレビューの段階にある。Registryは掲載する情報を意図的に評価しない方針をとり、コードの安全性の検査はnpmなどの配布元や、Registryを利用する側のマーケットプレイスに任せている。
Registryに載っていることは、安全の保証にならない。社内のサーバーはRegistryの対象外でもあるため、許可リストは自社で持つ。
- 提供元：公式のサーバーか、第三者が作ったものか
- 接続方式：ローカル（stdio）か、リモート（Streamable HTTP）か
- 扱うデータ：どの業務システムの、どの区分の情報に触れるか
- 対応する仕様の版：使うホストとつながるか
2. 誰の権限で動くかを決める
リモートのMCPサーバーで認可を実装する場合、MCPサーバーがOAuth 2.1のリソースサーバー、MCPクライアントがOAuthのクライアントになる。このとき仕様は、サーバーが認可サーバーの情報を公開する仕組み（RFC 9728）と、トークンの宛先を指定する仕組み（RFC 8707）を必須にしている。社内で使うリモートのサーバーは、認可を実装したものに限るのが前提になる。
企業の判断として重要なのは、AIが「利用者本人の権限」で動くのか、「共通のサービスアカウント」で動くのかである。利用者本人の権限で動かせば、その人が見られない情報はAIにも見えない。共通のアカウントで全社員に使わせる場合、利用者ごとのアクセス制御や記録を別に作り込まない限り、普段は閲覧できない情報にAI経由で届き、ログにも誰の操作かが残らない。
仕様も、サーバーは受け取ったトークンが自分宛てかを検証し、ほかのトークンを受け入れたり中継したりしてはならないとしている。
3. 公開する操作を絞る
1つのMCPサーバーが多くのツールを持つことがある。たとえばCRMのサーバーが「検索」「更新」「削除」「一括エクスポート」を持っていても、最初は検索だけを使わせれば足りる業務は多い。
仕様は、tools/listで返すツールを、リクエストに付いた権限に応じて変えてよいとしている。スコープを絞ったトークンには、そのスコープで使えるツールだけを見せる設計ができる。最小のスコープで始め、更新が必要になった時点で追加の同意を取る形が、仕様の推奨とも合う。
4. 実行前に人が確かめる
仕様は、ツールの呼び出しを人が拒否できる状態を常に保つべきだとし、AIに公開しているツールを画面で示すこと、実行時の表示、確認の画面を推奨している（SHOULD）。
社内の運用としては、操作を3つに分けて決めると判断しやすい。
| 区分 | 例 | 実行前の確認 |
|---|---|---|
| 読み取り | 検索、一覧、要約のための取得 | 不要としてよい。ただし対象のデータ区分は1で制限する |
| 書き込み | 起票、更新、下書きの保存 | 内容を見せて承認を取る |
| 外部への送信・削除 | メールの送信、外部への共有、削除、一括処理 | 毎回承認を取る。一括処理は件数の上限を設ける |
OpenAIのResponses APIは、MCPツールの実行に既定で承認を求める設定になっている。製品の既定に頼るだけでなく、どの区分で承認を外すかを社内で決めておく。ツールが「読み取り専用」と申告していても、その申告で確認を省かない。
5. 記録して棚卸しする
仕様はクライアントに、監査のためにツールの利用を記録することを推奨している。誰が、どのホストから、どのサーバーの、どのツールを、どの引数で呼んだかを残す。
あわせて、許可リストのサーバーを四半期ごとに見直す。使われていないサーバーを止め、提供元の更新でツールが増えていないかを確かめる。ツールの一覧は、サーバー側の更新で利用者の操作なしに変わることがある。
データ境界・権限・監査ログの設計を全社のAIガバナンスとして整理する方法は「AIガバナンスと実装セキュリティ｜6つの制御点」で解説している。
導入の進め方
| 段階 | やること | 判断の基準 |
|---|---|---|
| 1. 対象業務を決める | AIに社内システムを使わせたい業務を1つ選ぶ。読み取りだけで価値が出る業務から始める | 誰の、どの作業時間が減るかを数字で言えるか |
| 2. サーバーを選ぶ | 公式のサーバーがあればそれを使う。なければ自社で作るか、既存のAPI連携で足りるかを比べる | 許可リストの4項目を埋められるか |
| 3. 権限を設計する | 利用者本人の権限で動かす。スコープとツールを最小にする | 普段見られない情報にAIが届かないか |
| 4. 小さく試す | 部署を限って使い、承認の画面とログを確認する | 承認の手間が業務を止めていないか。ログで操作を追えるか |
| 5. 広げる | 書き込みのツールを順に足し、利用する部署を増やす | 棚卸しの担当と周期が決まっているか |
社内システムやSaaSとAIをつなぐ設計の全体像は「SaaS連携×AI実装｜定着しないSaaSを成果に変える統合設計」で扱っている。
FDXの支援
FDXはAX（AI Transformation）の実装パートナーとして、業務の分解から実装・現場定着・運用移管までを対応領域とする。MCPの導入では、接続そのものより先に、どの業務でAIに何をさせるかと、権限の境界を決めることを重視する。
- 1Day AIアセスメント：業務ごとにAIで代替できるかを判定し、データの所在とAIに渡してよい情報の区分を整理する
- 1Day FDE：FDE（Forward Deployed Engineer）が週1日常駐し、MCPサーバーの選定・権限設計・ログ設計を実装に落として現場に定着させる
どの業務からMCPでつなぐべきかを相談したい場合はお問い合わせから、まず自社の状況を確かめたい場合はAX診断からどうぞ。
よくある質問（FAQ）
Q1. MCPとは何か？
A. MCP（Model Context Protocol）は、AIアプリが外部のデータや機能を使うための共通の接続規格である。AIアプリ（ホスト）が接続先ごとにクライアントを用意し、データや機能を提供するMCPサーバーと1対1でつないで、JSON-RPC 2.0でやり取りする。2024年11月にAnthropicが公開し、2025年12月にLinux Foundation傘下のAgentic AI Foundationへ寄贈された。
Q2. MCPサーバーとは何か？
A. AIに機能やデータを提供するプログラムである。AIが実行する「ツール」、読み取る「リソース」、定型の指示である「プロンプト」の3つを提供できる。PC上で動くローカルのサーバー（stdio接続）と、社内システムやSaaSが提供するリモートのサーバー（Streamable HTTP接続）がある。
Q3. MCPとAPIは何が違うのか？
A. APIはシステムごとの呼び出し方で、MCPはAIアプリから見た呼び出し方をそろえる規格である。多くのMCPサーバーは内部で既存のAPIを呼んでいるため、MCPはAPIを置き換えるものではない。複数のAIアプリから同じ社内システムを使わせたい場合にMCPが向いている。
Q4. MCPはセキュリティ上危険なのか？
A. 規格そのものが危険なわけではないが、AIが触れられる範囲が広がるため、設計を誤ると被害も広がる。仕様はトークンの使い回しの禁止や、ツール実行前の人の確認を定めているが、プロトコルでは強制できないと明記している。使ってよいサーバー、誰の権限で動くか、公開する操作、実行前の確認、記録の5点を導入する企業が決める必要がある。
Q5. 公式のMCP Registryに載っているサーバーなら安全か？
A. 安全とは限らない。公式のMCP Registryは公開サーバーの情報を集める場所で、2026年11月5日の確認ではプレビューの段階にある。掲載情報は意図的に評価せず、コードの安全性の検査は配布元や利用する側のマーケットプレイスに任せている。社内では自社の許可リストで管理する。
Q6. 2025年に作ったMCPサーバーやクライアントはそのまま使えるか？
A. 組み合わせによる。2026-07-28版で接続開始のinitializeとセッションが廃止された。仕様の互換性の表では、古い方式にしか対応しないクライアントは、新しい方式にしか対応しないサーバーにつながらない。使うホストとサーバーが対応している版を確認し、必要なら両方の方式に対応したSDKに更新する。
次に読むべき記事
- AIエージェントとは？開発方法と企業導入の5ステップ：MCPでつなぐ先にあるエージェントの構成
- AIガバナンスと実装セキュリティ｜6つの制御点：権限・入力の信頼境界・監査ログの全社設計
- シャドーAI対策｜禁止だけで防げない理由と4つの制御点：承認していないツールの利用を減らす方法
- SaaS連携×AI実装｜定着しないSaaSを成果に変える統合設計：SaaSとAIをつなぐ3つの実装パターン
- 生成AIの事故事例2025-2026｜4類型と実務対策：実際に起きた事故の類型と責任の所在
まとめ
- MCPは、AIアプリと社内システムやSaaSをつなぐ共通の接続規格で、ホスト・クライアント・サーバーの3つの役割で構成される
- MCPサーバーはツール・リソース・プロンプトを提供する。AIが判断して呼び出すツールが権限設計の中心になる
- 現行の仕様は2026-07-28版で、
initializeとセッションが廃止された。使うホストとサーバーの対応する版を確かめる - 仕様はトークンの使い回しを禁じ、ツール実行前に人が拒否できることを求めるが、プロトコルでは強制できない
- 企業では、使ってよいサーバー、誰の権限で動くか、公開する操作、実行前の確認、記録と棚卸しの5点を先に決める
- 公式のMCP Registryへの掲載は安全の保証にならない。許可リストは自社で持つ
出典・参考文献
- Model Context Protocol「What is the Model Context Protocol (MCP)?」（USB-Cポートのたとえ。2026年11月5日確認）
- Model Context Protocol「Specification」（ホスト・クライアント・サーバーの定義、設計原則、ユーザーの同意とツールの安全性の原則、プロトコルでは強制できないとの記述。2026年11月5日確認）
- Model Context Protocol「Versioning」（現行版が2026-07-28であること、非推奨機能の扱い。2026年11月5日確認）
- Model Context Protocol「Key Changes（2026-07-28）」（セッションと
initializeの廃止、server/discover、複数回のやり取りの方式、Sampling・Roots・Logging・HTTP+SSE・Dynamic Client Registrationの非推奨化。2026年11月5日確認） - Model Context Protocol「Deprecated Features」（非推奨機能の削除時期。2026年11月5日確認）
- Model Context Protocol「Versioning（2026-07-28）」（旧方式との互換性の表。2026年11月5日確認）
- Model Context Protocol「Transports」（stdioとStreamable HTTP。2026年11月5日確認）
- Model Context Protocol「Authorization」（OAuth 2.1、RFC 9728とRFC 8707の必須化、トークンの検証と中継の禁止、stdioの資格情報。2026年11月5日確認）
- Model Context Protocol「Tools」（model-controlled、人が拒否できる状態の推奨、アノテーションを信頼しない義務、権限に応じたツール一覧、監査のための記録。2026年11月5日確認）
- Model Context Protocol「Security Best Practices」（Confused Deputy、Token Passthrough、SSRF、Local MCP Server Compromise、Scope Minimization。2026年11月5日確認）
- Model Context Protocol「The MCP Registry」（プレビューの段階であること、プライベートサーバーの非対応、掲載情報を評価しない方針、セキュリティ検査の委任。2026年11月5日確認）
- Model Context Protocol Blog「The 2026-07-28 Specification」（2026年7月28日）
- Model Context Protocol Blog「MCP joins the Agentic AI Foundation」（2025年12月9日。Linux Foundation傘下のAgentic AI Foundationへの寄贈、技術判断はメンテナーが続けること）
- Anthropic「Introducing the Model Context Protocol」（2024年11月25日）
- OpenAI「Connectors and MCP servers」（Responses APIのリモートMCPサーバー対応、既定で承認を求める設定。2026年11月5日確認）
- Google Cloud Blog「Announcing official MCP support for Google services」（2025年12月11日。マネージドなリモートMCPサーバー）
- AWS「MCP servers as targets（Amazon Bedrock AgentCore Gateway）」（対応するプロトコルの版。2026年11月5日確認）
- デジタル庁「デジタル社会の実現に向けた重点計画」（令和8年7月21日。AIエージェントによる政府・デジタル庁システムへのアクセス環境（MCP等）の整備、マイナポータルのMCP等の基盤構築。2026年11月5日確認）
※ 英語資料からの引用・要約は編集部による翻訳である。5つの権限設計、操作の区分表、導入の進め方の表は、公開情報を踏まえた編集部の設計例であり、特定の製品の機能を保証するものではない。各製品の対応状況は変わるため、導入時に公式ドキュメントで確認されたい。