MCPとは、AIアプリと外部システムを接続するオープン標準規格。2025年12月にLinux Foundation傘下へ移管され、業界標準となった。
- 開発元: Anthropicが2024年11月25日に公開。2025年12月にAgentic AI Foundationへ寄贈
- 規模: 月間SDKダウンロード9,700万超、稼働中のMCPサーバーは10,000超
- 最新仕様: 2026年7月28日版で標準史上最大の改訂。ステートレス化とMCP Appsを追加
対象: AI活用を検討する経営者・DX推進担当・情報システム部門
今日やること: 自社で使っているAIツールがMCPに対応しているか公式ドキュメントで確認する
この記事の目次
「MCP対応」という表記を、AIツールの発表資料で見かける機会が急増しています。
MCP（Model Context Protocol）とは、AIアプリケーションを外部システムに接続するためのオープンソース標準規格です。2024年11月にAnthropicが公開し、2025年12月にはLinux Foundation傘下の組織へ寄贈されました。現在ではChatGPT・Claude・Gemini・Microsoft Copilot・Visual Studio Codeなど、主要なAIプラットフォームが揃って対応しています。
本記事では、MCPの定義と仕組みから、業界標準になるまでの経緯、2026年7月28日に公開される最新仕様、そして企業が導入を検討する際の判断材料までを、実務の目線で整理します。技術用語はその都度説明しますので、エンジニア以外の方もそのままお読みいただけます。
MCPとは？AIアプリと外部システムをつなぐ「USB-Cポート」
MCPの定義 — AIを外部システムに接続するオープン標準
MCPの公式ドキュメントは、MCPを次のように定義しています。
MCP（Model Context Protocol）は、AIアプリケーションを外部システムに接続するためのオープンソース標準です。
そして公式は、MCPを 「AIアプリケーションにとってのUSB-Cポート」 に喩えています。USB-Cが「どのメーカーの機器でも、同じ形状のポートで接続できる」状態を作ったように、MCPは「どのAIアプリからでも、同じ作法で外部システムにつなげる」状態を作ります。
ここでいう外部システムとは、具体的には次のようなものです。
| 分類 | 具体例 |
|---|---|
| データソース | ローカルのファイル、社内データベース、ドキュメント管理システム |
| ツール | 検索エンジン、計算処理、外部サービスのAPI |
| ワークフロー | 定型業務向けに設計された専用プロンプト |
たとえばAIアシスタントがGoogleカレンダーやNotionを参照して予定を調整する、あるいはAIコーディングツールがFigmaのデザインを読み取ってWebアプリを生成する、といった連携がMCPによって実現されます。
なお、AnthropicのAIコーディングツールであるClaude CodeもMCPホストの代表例です。Claude Codeとは、ターミナル上で対話しながらコードの生成・修正・レビューを行えるツールを指します（Claude Codeの詳細はこちら →）。
MCPが解決する「M×N問題」
MCPの価値は、統合コストの構造を変える点にあります。
MCPが登場する前は、AIアプリごと・接続先ごとに個別の連携を実装する必要がありました。AIアプリがM個、つなぎたい外部システムがN個あれば、必要な実装は理論上 M×N個 です。AIアプリを1つ増やすたびに、既存のN個すべてに対する接続を作り直すことになります。
MCPはこの間に共通の規格を挟みます。各AIアプリはMCPに1回対応すればよく、各外部システムもMCPサーバーを1つ用意すればよい。必要な実装は M+N個 に減ります。
| MCP導入前 | MCP導入後 | |
|---|---|---|
| 必要な実装数 | M×N | M+N |
| AIツールを1つ追加 | N個の連携を新規実装 | MCP対応のみ |
| 接続先を1つ追加 | M個のAIアプリを個別改修 | MCPサーバーを1つ公開 |
AIツールの入れ替わりが激しい現在、この差は「一度作った連携資産を、ツールを変えても使い回せるかどうか」に直結します。
MCPが扱わない領域
誤解を避けるために、MCPの守備範囲も押さえておきます。公式ドキュメントは次のように明記しています。
MCPはコンテキスト交換のためのプロトコルのみを対象としており、AIアプリケーションがLLMをどのように使うか、提供されたコンテキストをどう管理するかは規定しない。
つまりMCPは 「つなぎ方の共通ルール」だけを決める規格です。どのAIモデルを使うか、取得したデータをどう扱うか、プロンプトをどう設計するかは、各アプリケーションの裁量に委ねられています。MCPに対応すれば自動的にAIの精度が上がる、というものではありません。
明日からできること: 自社で使っているAIツールがMCPに対応しているか、公式ドキュメントで確認してみてください。
なぜ2026年にMCPが「業界標準」になったのか
Anthropicの発表からLinux Foundation傘下へ
MCPの歩みは、公開からわずか1年で大きく変わりました。
| 時期 | 出来事 |
|---|---|
| 2024年11月25日 | Anthropicがオープンソース標準としてMCPを公開 |
| 2025年3月 | OpenAIが採用を表明。ChatGPTデスクトップアプリ等に統合 |
| 2025年4月 | Google DeepMindが対応を表明 |
| 2025年12月9日 | AnthropicがMCPをAgentic AI Foundationへ寄贈 |
| 2026年7月28日 | 標準史上最大の改訂となる新仕様が公開 |
転換点は2025年12月の寄贈です。Agentic AI Foundation（AAIF）は、Linux Foundation傘下の directed fund（特定用途の基金） として設立された組織で、Anthropic・Block・OpenAIが共同設立し、Google・Microsoft・Amazon Web Services・Cloudflare・Bloombergが支援しています。
競合するAI企業同士が同じ基盤を支える構図になったことで、MCPは「Anthropicが管理するプロトコル」からベンダー中立の業界インフラへと性格を変えました。AAIFにはMCPと並び、Blockのgoose、OpenAIのAGENTS.mdが発足プロジェクトとして参加しています。
企業がAI連携基盤を選ぶうえで、この点は重要です。特定ベンダーの製品戦略に依存する規格ではなく、中立の財団がガバナンスを担う規格である、という前提が担保されたからです。
採用状況 — 月間9,700万ダウンロード、1万超のサーバー
Anthropicの公式発表によると、寄贈時点でMCPは次の規模に達しています。
- 月間SDKダウンロード数: 9,700万超
- 稼働中のMCPサーバー: 10,000超
- ファーストクラスのクライアント対応: ChatGPT、Claude、Cursor、Gemini、Microsoft Copilot、Visual Studio Code ほか
公開から1年で、AI分野で最も急速に普及したオープンソースプロジェクトのひとつになった計算です。
主要AIプラットフォームの対応タイムライン
実務上重要なのは、主要クライアントがすでに揃って対応しているという事実です。新しくMCPサーバーを1つ用意すれば、それをChatGPTからもClaudeからもVisual Studio Codeからも呼び出せます。社内向けのAI連携を作るとき、「どのAIツールを全社標準にするか」を決め切る前に着手できる、という意味を持ちます。
AI活用の進め方でお悩みですか？
どのAIツールをどう組み合わせ、どこから社内システムと連携させるかは、事業のフェーズによって最適解が変わります。株式会社Nexaでは、技術選定から運用設計までを伴走するAI顧問サービスを提供しています。
＼ Claude Codeの導入、何から始めればいいかわかります ／
法人様のAI導入に関するご相談はこちらMCPの仕組み — ホスト・クライアント・サーバーの3者構成
3つの登場人物
MCPはクライアント・サーバー型のアーキテクチャを採用しています。登場人物は3者です。
| 参加者 | 役割 | 具体例 |
|---|---|---|
| MCPホスト | 複数のMCPクライアントを調整・管理するAIアプリケーション | Claude Code、Claude Desktop、Visual Studio Code |
| MCPクライアント | MCPサーバーとの接続を維持し、コンテキストを取得するコンポーネント | ホストが内部で生成する接続オブジェクト |
| MCPサーバー | コンテキストをクライアントに提供するプログラム | ファイルシステムサーバー、データベースサーバー、Sentry MCPサーバー |
ポイントは、ホストがサーバー1つにつきクライアントを1つ生成し、専用の接続を張るという点です。
たとえばVisual Studio CodeがSentryのMCPサーバーに接続すると、そのための MCPクライアントが1つ生成されます。続いてローカルのファイルシステムサーバーにも接続すると、さらにもう1つ別のクライアントが生成されます。接続先ごとに経路が分離されているため、どのサーバーが何をしたかを個別に追跡・制御できる構造になっています。
なお「MCPサーバー」という呼び方は、動作する場所を問いません。同じマシン上で動くものも、クラウド上で動くものも、どちらもMCPサーバーです。慣用的に前者を「ローカルMCPサーバー」、後者を「リモートMCPサーバー」と呼び分けます。
データ層とトランスポート層
MCPは2つの層で構成されています。
| 層 | 役割 |
|---|---|
| データ層 | JSON-RPC 2.0ベースの通信プロトコル。ライフサイクル管理と後述のプリミティブを定義する内側の層 |
| トランスポート層 | 実際の通信路と認証を担当。接続確立・メッセージの区切り方・セキュアな通信を扱う外側の層 |
JSON-RPC 2.0とは、JSON形式でリモートの関数を呼び出すための軽量な規格です。「どの関数を、どんな引数で呼ぶか」を決まった形式のJSONで表現します。
この2層構造により、通信路が変わってもメッセージの形式は同一に保たれます。ローカル接続でもリモート接続でも、やり取りされるJSONは同じ形式です。
サーバーが提供する3つのプリミティブ（Tools / Resources / Prompts）
プリミティブとは、MCPで「クライアントとサーバーが互いに提供できるものの種類」を指す中核概念です。サーバー側は3種類を公開できます。
| プリミティブ | 内容 | 実務での例 |
|---|---|---|
| Tools（ツール） | AIが呼び出して実行できる関数 | データベースへの問い合わせ、ファイル操作、外部APIの呼び出し |
| Resources（リソース） | AIに文脈を与えるデータ源 | ファイルの中身、データベースのレコード、APIのレスポンス |
| Prompts（プロンプト） | 対話を構造化する再利用可能なテンプレート | システムプロンプト、few-shot例 |
それぞれに、一覧を取得する */list、内容を取得する */get、実行する tools/call といったメソッドが定義されています。クライアントはまず tools/list で「このサーバーは何ができるのか」を問い合わせ、その結果をもとに tools/call で実行します。
一覧取得が動的に行われる設計のため、サーバー側でツールを追加すると、クライアントを再起動せずに反映できます。サーバーは notifications/tools/list_changed という通知を送ることで、ツール一覧の変更をクライアントへ能動的に知らせることもできます。
社内システムをMCP化する際は、この3分類が設計の出発点になります。「参照させたいデータはResources」「実行させたい操作はTools」と切り分けるだけで、設計の見通しが立ちます。
クライアントが提供するプリミティブ
逆に、クライアント側がサーバーに提供できるプリミティブもあります。
- Sampling: サーバーがクライアント側のAIアプリにLLMの推論を依頼する仕組み（
sampling/createMessage）。サーバー自身にLLMのSDKを組み込まずに済むため、モデル非依存を保てます - Elicitation: サーバーがユーザーに追加情報の入力や操作の確認を求める仕組み（
elicitation/create） - Logging: サーバーがデバッグ・監視用のログメッセージをクライアントへ送る仕組み
ただし、このうちSamplingとLoggingは後述の2026年7月28日仕様で非推奨となりました。新規に実装する場合は注意が必要です。
2つのトランスポート（stdio / Streamable HTTP）
通信路は2種類が定義されています。
| トランスポート | 用途 | 特徴 |
|---|---|---|
| stdio | 同一マシン上のローカルプロセス間通信 | 標準入出力を使う。ネットワークのオーバーヘッドがなく高速 |
| Streamable HTTP | リモートサーバーとの通信 | HTTP POSTに加え、必要に応じてServer-Sent Eventsでストリーミング。認証はBearerトークン・APIキー等に対応し、公式はOAuthの利用を推奨 |
社内データを扱うサーバーをローカルで動かすならstdio、複数の利用者で共有するサーバーを立てるならStreamable HTTPを選ぶ、という判断になります。
Claude Codeでの具体的な設定手順は、別記事で詳しく解説しています（Claude Code MCP連携ガイド →）。
明日からできること: 社内のどのデータをResourcesにし、どの操作をToolsにするかを棚卸ししてみてください。
2026年7月28日の最新仕様 — 過去最大の改訂で何が変わるか
MCPの仕様は日付をバージョン名とする形で管理されています。2026年7月28日版は、リリース候補が2026年5月21日に確定した後に正式公開されるもので、公式ブログが 「標準の歴史上で最大の改訂」 と表現しています。直前のバージョンは2025年11月25日版です。
企業として重要なのは、すでに動かしているMCPサーバー・クライアントに移行作業が発生し得るという点です。主要な変更を整理します。
ステートレス化 — セッション管理の廃止
最も大きな変更が、セッション管理の撤廃です。
- 接続開始時の
initialize/initializedハンドシェイクとMcp-Session-Idヘッダを廃止 - クライアントはスティッキーセッションなしで任意のサーバーインスタンスへルーティング可能に
- プロトコルのメタデータは、毎回のリクエストの
_metaフィールドに載せる方式へ - 従来のcapability交換は、新設された
server/discoverメソッドに置き換え
スティッキーセッションとは「同じ利用者のリクエストを、必ず同じサーバーへ送り続ける」仕組みのことです。これが不要になると、ごく一般的なHTTPのロードバランサーの背後にMCPサーバーを並べて水平スケールできるようになります。利用者数が増えたときにサーバーを増設するだけで対応できる、という運用上の意味を持ちます。
なお公式は「ステートレスなプロトコルは、ステートレスなアプリケーションを要求するものではない」と補足しています。サーバー側が basket_id のような明示的なハンドルを発行し、モデルがそれをツールの引数として渡し返す設計にすれば、状態を持つ処理も引き続き実現できます。
MCP Apps — サーバー側レンダリングUI
MCP Appsは、サーバー側でレンダリングしたユーザーインターフェースを提供する拡張です。
- サンドボックス化されたiframe内で、インタラクティブなHTMLを配信する
- ツールはUIテンプレートを事前に宣言する。これによりプリフェッチとセキュリティレビューが可能になる
- UI上の操作も、直接のツール呼び出しと同じJSON-RPCの監査経路を通る
チャットのテキスト応答だけでなく、フォームやダッシュボードのような画面をAIアプリ内に表示できるようになります。監査ログの経路が一本化されている点は、内部統制の観点で評価できる設計です。
Tasks拡張 — 長時間処理の標準化
Tasksは、時間のかかる処理の結果を後から取得するための仕組みです。実験的なコア機能から、オプトインの拡張機能へ格上げされました。
- クライアント側が
tasks/get・tasks/update・tasks/cancelで進行を制御する方式に変更 tasks/listは削除- 2025年11月25日版のTasks APIを使っているアプリケーションは移行が必要
バッチ処理や多段階のワークフローをMCPで扱っている場合、ここは確認が必要な箇所です。
認可のOAuth/OpenID Connect整合
セキュリティ面では、既存の認証基盤との整合を高める6つの変更が入りました。
- クライアントは RFC 9207に準拠して
issパラメータを検証しなければならない（mix-up攻撃の防止） - クライアントは登録時に OpenID Connect の
application_typeを宣言する - 認証情報を特定の認可サーバーに紐づける
- リフレッシュトークンとスコープ蓄積の手順を明確化
mix-up攻撃とは、複数の認可サーバーを使う環境で、攻撃者が認可レスポンスをすり替えてトークンを窃取する攻撃です。既存のOAuth/OIDC基盤を持つ企業ほど、この整合性強化の恩恵を受けやすくなります。
非推奨・破壊的変更の一覧
移行計画を立てるうえで押さえるべき点です。
| 種別 | 内容 | 対応 |
|---|---|---|
| 非推奨 | Roots | ツールの引数、またはリソースURIを使う |
| 非推奨 | Sampling | LLMプロバイダのAPIを直接利用する |
| 非推奨 | Logging | stderr、またはOpenTelemetryを使う |
| 破壊的変更 | リソース不在時のエラーコードが -32002 → -32602 に変更（JSON-RPC標準に準拠） |
-32002 をリテラルで判定しているコードは要修正 |
| インフラ | Mcp-Method / Mcp-Name ヘッダが必須化 |
ヘッダベースのルーティングが可能に |
| インフラ | レスポンスに ttlMs / cacheScope を追加 |
クライアント側キャッシュが可能に |
| インフラ | W3C Trace Contextを _meta で標準化 |
分散トレーシングに対応 |
非推奨となった3機能には、削除まで最低12ヶ月の猶予期間が設けられています。すぐに動かなくなるわけではありませんが、新規実装で採用するのは避けるべきです。
破壊的変更はエラーコードの1点のみです。ただしエラーコードを数値でハードコードしている実装は静かに壊れるため、該当箇所の確認をおすすめします。
明日からできること: 利用中のMCPサーバーが、どの仕様バージョンに対応しているかを確認してください。
＼ 業務自動化のお悩み、プロが30分で整理します ／
法人様のAI導入に関するご相談はこちら企業がMCPを導入するメリット
統合コストの構造的な削減
前述のM×N問題の解消が、そのまま費用対効果につながります。AI連携を個別実装で積み上げていくと、ツールを乗り換えるたびに作り直しが発生します。MCPを介して作った連携資産は、MCP対応のAIツールであれば横断して再利用できます。
ツール選定のロックイン回避
主要クライアントが揃って対応済みであることの実務的な意味は、AIツールの選定を後回しにできる点にあります。社内データをMCPサーバーとして公開しておけば、全社標準のAIツールが将来変わっても、接続部分の作り直しは発生しません。
AIエージェントによる並行処理と組み合わせると、業務自動化の設計自由度はさらに広がります（Claude Code Agent・サブエージェント完全ガイド →）。
監査経路の一本化
MCPでは、AIが行った操作がすべてJSON-RPCのリクエストとして流れます。MCP Appsで追加されたUI操作も同じ経路を通ります。つまり 「AIが、いつ、どのツールを、どんな引数で呼んだか」が単一の形式で記録されるということです。
内部統制上、AIの操作履歴を説明できる状態を作れるかどうかは重要な論点です。個別実装の寄せ集めでは、この記録形式を揃えること自体が難題になります。
明日からできること: AI連携で「同じような実装を何度も作っている」箇所を洗い出してみてください。
導入前に押さえるべき3つの注意点
プロンプトインジェクションと汚染ツール
2025年4月、研究者によってMCPに関するセキュリティ上の問題が指摘されています。具体的には プロンプトインジェクションと、汚染されたツール（poisoned tools）を経由して、接続された他のツールからデータが持ち出される問題です。
プロンプトインジェクションとは、AIが読み込むデータの中に指示文を紛れ込ませ、本来の指示を上書きする攻撃を指します。MCPの文脈では、サーバーが返すツールの説明文やリソースの中身が攻撃経路になり得ます。
対策の要点は、接続するMCPサーバーを提供元が信頼できるものに限定することです。公開されているサーバーが1万を超えた現在、「便利そうだから」と出所不明のサーバーを接続するのは避けるべきです。
企業利用時のセキュリティ論点は、別記事でも整理しています（Claude Code セキュリティ完全ガイド →）。
権限設計 — 最小権限の原則
MCPサーバーには、接続先システムへの認証情報を渡すことになります。ここで渡す権限が広すぎると、AIの誤動作や前述の攻撃が成立したときの被害範囲がそのまま広がります。
- 読み取りだけで足りる用途に、書き込み権限を渡さない
- 本番データベースに直接つながず、参照用のレプリカやビューを経由させる
- 部門・用途ごとに認証情報を分け、どのサーバーが何にアクセスできるかを台帳化する
2026年7月28日版でOAuth/OpenID Connectとの整合が強化されたのは、まさにこの領域の統制を既存基盤に寄せるためです。
バージョン移行の計画
仕様が日付バージョンで進む以上、移行は定期的に発生します。2026年7月28日版のように大きな改訂が入る場合、社内で動かしているサーバーとクライアントの双方に確認作業が必要です。
- 利用中のサーバー・クライアントの対応バージョンを台帳化する
- 非推奨機能（Roots / Sampling / Logging）を使っている実装を洗い出す
- エラーコードをハードコードしている箇所を点検する
明日からできること: MCPサーバーに渡している認証情報の権限範囲を点検してください。
＼ AI活用の「次の一手」を一緒に考えませんか ／
法人様のAI導入に関するご相談はこちら何から始めるか — 3ステップ
STEP 1: 既存クライアントで公式サーバーを試す
すでに社内でAIツールを使っているなら、そのツールがMCPホストとして機能する可能性が高い状態です。まずは公式が提供するリファレンス実装のサーバー（ファイルシステム等）を1つ接続し、AIが外部データを参照して回答が変わる体験を確認します。ここまでは新規開発なしで到達できます。
STEP 2: 社内データ1つをリソース化する
次に、参照頻度が高く、機密性が比較的低いデータを1つ選んでMCPサーバー化します。製品マスタ、社内規程、FAQなどが典型です。Toolsではなく Resourcesから始めるのが安全です。読み取り専用であれば、AIの誤動作による書き換えリスクがありません。
STEP 3: 権限とログの運用ルールを決める
技術的に動くことを確認したら、運用ルールを固めます。
- 接続を許可するMCPサーバーの承認プロセス
- 認証情報の権限範囲と棚卸しの頻度
- JSON-RPCのやり取りをどこに保存し、誰が確認するか
この3点を決めてから利用範囲を広げると、後戻りが発生しにくくなります。
まとめ
MCP（Model Context Protocol）とは、AIアプリケーションと外部システムをつなぐオープン標準規格です。要点を整理します。
- 定義: AIアプリと外部システムを接続するオープン標準。公式は「AIアプリにとってのUSB-Cポート」と表現する
- 経緯: 2024年11月25日にAnthropicが公開。2025年12月9日にLinux Foundation傘下のAgentic AI Foundationへ寄贈され、ベンダー中立の業界インフラになった
- 規模: 月間SDKダウンロード9,700万超、稼働中のMCPサーバー10,000超。主要AIクライアントが揃って対応済み
- 仕組み: ホスト・クライアント・サーバーの3者構成。サーバーはTools / Resources / Promptsの3プリミティブを公開する
- 最新仕様: 2026年7月28日版は標準史上最大の改訂。ステートレス化・MCP Apps・Tasks拡張・OAuth整合が主な内容で、
-32002→-32602の破壊的変更を含む - 導入の要点: 統合コストをM×NからM+Nへ構造的に削減できる一方、信頼できるサーバーへの限定と最小権限の設計が前提になる
AI活用の主戦場は、単体ツールの使いこなしから 「社内のデータや業務システムとどうつなぐか」 へ移りつつあります。MCPはその接続部分の共通言語です。まずは自社で使っているAIツールの対応状況を確認するところから始めてみてください。
AIの導入・活用にお悩みですか？
株式会社Nexaでは、最新のAIツールを活用した企業向けの導入支援・活用コンサルティングを提供しています。「何から始めればいいかわからない」という段階から、技術選定・社内システム連携・運用ルールの設計までを伴走してサポートいたします。
参考・出典
- Model Context Protocol 公式ドキュメント — What is MCP?
- Model Context Protocol 公式ドキュメント — Architecture overview
- MCP Blog — The 2026-07-28 MCP Specification Release Candidate
- MCP Blog — MCP joins the Agentic AI Foundation
- Anthropic — Donating the Model Context Protocol and establishing the Agentic AI Foundation
