MCPとは？AIと外部ツールをつなぐ標準規格を解説

MCP（Model Context Protocol）は、AI アプリケーションを外部のシステムやデータへ接続するためのオープンな標準規格です。この記事では、MCP の仕組みと構成要素、関数呼び出しとの役割分担、2026年9月時点の最新仕様、そして導入前に確認しておきたいセキュリティの前提を解説します。

この記事が扱う MCP は Model Context Protocol です。マイクロソフトの認定資格（Microsoft Certification Program）や半導体のマルチチップパッケージも MCP と略されますが、ここでは扱いません。

MCPとは何か（Model Context Protocol）

MCP は、AI アプリケーションと外部システムをつなぐためのオープンソースの標準規格です。公式ドキュメントは MCP を「AI アプリケーションにとっての USB-C ポートのようなもの」と説明しています。USB-C が機器の接続方法を統一したように、MCP は AI アプリケーションと外部システムの接続方法を統一します。

何の略で、誰がいつ公開したのか

MCP は Model Context Protocol の略です。Anthropic が2024年11月25日にオープンソースとして公開しました。公開時点で仕様と SDK に加え、Claude Desktop のローカルサーバー対応と、いくつかのプリビルドサーバーが同時に提供されています。初期の採用企業として Block、Apollo、Zed、Replit、Codeium、Sourcegraph が名前を挙げられていました。

その後、2025年12月9日に Anthropic は MCP を Agentic AI Foundation へ寄贈しています。AAIF は Linux Foundation 傘下の directed fund で、Anthropic・Block・OpenAI が共同設立し、Google・Microsoft・AWS・Cloudflare・Bloomberg が支援に名を連ねています。ただし寄贈でガバナンスの担い手が変わったわけではありません。プロトコルの意思決定は従来どおり既存のメンテナが行い、コミュニティからの入力は SEP プロセスを通じて反映される、と発表文に明記されています。

Anthropic は同じ発表のなかで採用規模も公開しました。2025年12月時点で、公開されている稼働中の MCP サーバーは1万件以上、Python と TypeScript の SDK は月間9,700万ダウンロード超とされています。数値はいずれもこの時点のスナップショットです。

なぜ「AI 版の USB-C」と呼ばれるのか

USB-C 以前は、機器ごとに専用のケーブルとコネクタを用意する必要がありました。AI アプリケーションと外部ツールの接続も同じ状態にありました。片方が変わればもう片方の実装も直す必要があり、つなぎ先が増えるほど組み合わせが増えていきます。MCP はこの接続部分に共通の規約を置くことで、片側ずつ独立して作れるようにしています。

なぜ「M×N」の接続コストが問題になるのか

つなぎたい AI アプリケーションが M 個、つなぎたいツールが N 個あるとき、個別に実装すると M×N 通りの接続コードが必要になります。ツールを1つ足すたびに M 個のアプリケーション側を直す作業が発生し、アプリケーションを1つ足すたびに N 個のツールへの対応を書くことになります。

共通の規約を1枚挟むと、この組み合わせは M+N に減ります。ツール側は MCP サーバーを1つ用意すればよく、アプリケーション側は MCP クライアントを実装すれば、どのサーバーともつながります。

この発想は新しいものではありません。MCP の仕様は「Language Server Protocol（LSP）から着想を得ている」と公式に述べています。LSP は、エディタごと・言語ごとに書かれていた補完や定義ジャンプの実装を、共通プロトコルで M+N に整理した先例です。MCP はその構図を、AI アプリケーションと外部システムの間に持ち込んだものだと理解すると位置づけが掴みやすくなります。AI を開発プロセスへ組み込む全体像については、AI駆動開発の解説記事でも扱っています。

MCPの構成要素：ホスト・クライアント・サーバー

MCP には3つの登場人物がいます。公式のアーキテクチャ解説は、それぞれを次のように定義しています。

• MCP ホスト: 1つ以上の MCP クライアントを調整・管理する AI アプリケーション。Claude Code や Claude Desktop、Visual Studio Code などが該当します
• MCP クライアント: MCP サーバーへの接続を維持し、ホストが使うコンテキストをサーバーから取得するコンポーネント
• MCP サーバー: MCP クライアントへコンテキストを提供するプログラム

ここで押さえておきたいのが、ホストはサーバー1つにつきクライアントを1つ作るという点です。3つのサーバーにつなぐホストは、3つのクライアントを内部に持ちます。1つのクライアントが複数のサーバーを束ねる構造ではありません。

もう1つ、公式のアーキテクチャ解説は「ローカル」「リモート」という呼び分けがサーバーの実行場所の話であって、プロトコル上の区別ではないと述べています。同じサーバー実装が、手元のプロセスとしても、ネットワーク越しのサービスとしても動きます。

構造としては2つの層に分かれます。データ層は JSON-RPC 2.0 をベースにしたプロトコルそのもので、トランスポート層が通信路と認可を担当します。

サーバーが提供する3つの機能：Tools・Resources・Prompts

MCP サーバーが外に出せるものは3種類あります。名前だけ並べると似て見えますが、公式ドキュメントは「誰が制御するか」という軸で3者を区別しています。この軸を押さえると使い分けを間違えません。

Tools はモデルが「いま呼ぶべきだ」と判断して実行します。Resources はアプリケーション側が「この情報を渡す」と決めて添えます。Prompts は利用者が選んで適用します。同じ「サーバーが提供するもの」でも、起動する主体が違います。

サーバー側だけでなく、クライアント側にも機能があります。たとえば Elicitation は、サーバーが処理の途中で利用者に追加情報を尋ねるための仕組みです。

実際の通信は次のように進みます。

MCPと関数呼び出し（function calling）はどう違うのか

MCP を調べていると「関数呼び出しと何が違うのか」という疑問に行き当たります。両者は競合しません。モデルが関数を呼ぶ層は従来の関数呼び出しのままで、MCP が標準化しているのは、その関数がどこにあり、どう見つけ、どう認可するかという接続の部分です。

Claude の Messages API で MCP サーバーにつなぐ場合、MCP のツールは mcp_toolset として通常の tools 配列に載り、いつもの tool use と同じ経路で呼ばれます。公式ドキュメントによると、この機能は現時点で MCP 仕様のうちツール呼び出しのみに対応しており、サーバーは HTTP で公開されている必要があります。手元で動く STDIO のサーバーへ直接つなぐことはできません。ステータスは Beta です。

接続層が標準化されると、つなぎ先を増やすのが楽になります。ただしここに運用上のトレードオフがあります。サーバーを増やすほど、モデルのコンテキストにはツール定義が積み上がります。クライアント実装のベストプラクティスは、数百から数千のツールを抱えた状態で全定義を先読みするとトークンを浪費し、レイテンシが増え、モデルの性能も落ちると述べています。

Anthropic が示した試算では、全ツールを事前ロードすると定義だけで約15万トークンを消費するのに対し、必要になった時点で発見する方式なら約2,000トークンで済むとされています（2025年11月4日）。対策として公式が挙げているのは、メタツールで必要なツールだけを探す段階的発見と、モデルにコードを書かせてサンドボックス側でツールを呼ぶ方式の2つです。段階的発見への切り替え目安は、ツール定義がコンテキストウィンドウの1〜5%を超えたあたりとされています。

つまり MCP を入れれば接続の問題がすべて解決するわけではなく、つなぎ先が増えたときのコンテキスト設計が次の課題になります。 この領域の考え方はコンテキストエンジニアリングの記事で整理しています。

2026年時点の仕様：ステートレス化と非推奨機能

MCP の仕様はリビジョン単位で管理されています。バージョン識別子は YYYY-MM-DD 形式で、公式のバージョニング解説によると、この日付は「後方非互換な変更が最後に入った日」を指します。

現行リビジョンの 2026-07-28 は、入門記事を書き換える必要があるほどの変更を含んでいます。MCP はステートレスプロトコルになりました。 従来あった initialize ハンドシェイクによるセッション確立は廃止され、server/discover という必須 RPC に置き換わっています。呼び出し自体は任意で、いきなり目的のリクエストを送っても構いません。各リクエストは自分が使うプロトコルバージョンと機能を _meta フィールドに載せて運ぶため、サーバーはリクエストを単体で処理できます。通知もオプトイン方式になり、受け取りたい種別を明示的に指定します。

図の下段のように、どのリクエストも単体で完結するのが現行仕様です。サーバー側が会話の途中の状態を覚えておく必要がなくなるため、複数のインスタンスへ振り分ける構成が組みやすくなります。2025-11-25 以前の方式との後方互換の手順も別途定義されています。

トランスポートは stdio と Streamable HTTP の2つが標準です。ここで誤解されやすいのが SSE の扱いです。HTTP+SSE という独立したトランスポートは2025年3月26日のリビジョンで非推奨になりましたが、SSE そのものが消えたわけではありません。Streamable HTTP のなかで、レスポンスをストリーミングする手段として使われ続けています。

非推奨になった機能も整理しておきます。2026-07-28 のリビジョンで Roots、Sampling、Logging、動的クライアント登録が非推奨になりました。Sampling の移行先は LLM プロバイダー API との直接統合、Logging は stdio なら標準エラー出力、可観測性の用途なら OpenTelemetry とされています。撤去は2027年7月28日以降の最初のリビジョン以降で、現時点で撤去済みの機能はありません。

認可についても押さえておく価値があります。認可仕様は OAuth 2.1 をベースにしていますが、MCP 実装にとって認可は必須ではありません。HTTP 系のトランスポートを使う実装は仕様に準拠すべき（SHOULD）とされる一方、stdio を使う実装は従うべきではなく、環境から資格情報を取得することになっています。

公式のリファレンスサーバーも入れ替わっています。現在公式が挙げているのは Everything、Fetch、Filesystem、Git、Memory、Sequential Thinking、Time の7つです。公開当初に紹介されていた Google Drive や Slack、Postgres などのリファレンスサーバーはアーカイブに移されました。古い解説記事を読むときは、この点に注意してください。

リモートで動かすMCPと、AWSでの実装例

ここまでは手元で動かす前提で説明してきました。MCP サーバーはネットワーク越しにも置けます。組織で共通のサーバーを使いたい場合はこちらが前提になるので、何が変わるのかを整理します。

ローカルとリモート：プロトコル上の区別ではない

先に構成要素の節で触れたとおり、この呼び分けはサーバーの実行場所の話です。トランスポートの仕様は「プロトコルの意味づけはどのトランスポートでも同一である」と述べ、トランスポートを「メッセージの区切り方と届け方を定めるバインディング」と位置づけています。メッセージが何を意味するかはトランスポート側では決めません。

実務ガイドのリモートサーバーへの接続も「リモート MCP サーバーはローカルのものと同じように機能するが、手元のマシンではなくインターネット上でホストされている」と説明しています。利点として挙げられているのは、端末ごとにインストールと設定をしなくてよいことです。

違いが出るのはトランスポートの中身です。stdio はクライアントが起動した子プロセスの標準入出力を使い、Streamable HTTP は単一のエンドポイントへ HTTP POST を送ります。前の節で触れた 2026-07-28 の変更は、この HTTP 側にも及んでいます。GET によるストリームエンドポイントと、プロトコルレベルのセッションが削除されました。 旧リビジョンの Mcp-Session-Id や Last-Event-ID によるレジュームは、現行仕様には存在しません。

リモート化で増える設計：認可とネットワーク

リモートにすると、認可とネットワーク境界の設計が新たに必要になります。

認可仕様の書き方は正確に読む価値があります。認可の仕様は「認可は MCP 実装にとって OPTIONAL である」としたうえで、採用する場合は HTTP 系トランスポートならこの仕様に準拠すべき（SHOULD）、stdio なら逆に準拠すべきではなく（SHOULD NOT）環境から資格情報を取得する、と分けています。つまりローカルで stdio を使っているうちは OAuth の設計が要らず、リモート化した時点で必要になります。

MCP サーバーは OAuth 2.1 のリソースサーバーとして振る舞い、Protected Resource Metadata（RFC 9728）の実装が必須です。クライアント側は Resource Indicators（RFC 8707）の resource パラメータを認可リクエストとトークンリクエストの両方に含めることが求められます。なお動的クライアント登録（RFC 7591）は非推奨になり、Client ID Metadata Documents が推奨に変わっています。古い記事はここが更新されていないことがあります。

ネットワーク面では、Streamable HTTP の仕様が2つを明記しています。サーバーは DNS リバインディング攻撃を防ぐため、すべての受信接続で Origin ヘッダーを検証しなければなりません。またローカルで動かす場合は、すべてのネットワークインターフェースではなく localhost にだけバインドすべきとされています。

Anthropic 側の対応状況も押さえておいてください。Claude の Messages API から使う MCP connector は、公式ドキュメントによるとサーバーが HTTP で公開されていることが前提で、ローカルの STDIO サーバーへ直接つなぐことはできません。ステータスは Beta で、Claude API・Claude Platform on AWS・Microsoft Foundry で提供され、Amazon Bedrock と Google Cloud では提供対象外と記載されています。

AWSでの実装：3つの入り口

AWS 上でリモート MCP を扱う経路は、公式ドキュメントに現れる範囲で3つあります。

1つめは AWS が運用するマネージドのリモート MCP サーバーです。公式ドキュメントによると、ドキュメント検索やサービス情報の取得は認証なしで使え、API 呼び出しやスクリプト実行には既存の IAM 資格情報で認証します。すべての機能が単一のエンドポイントから提供され、CloudWatch のメトリクスと IAM によるアクセス制御、CloudTrail による監査ログが付きます。AWS Security Blog は re:Invent 2025 で AWS・EKS・ECS・SageMaker の4つをプレビューとして公開したと記載しています。

統制の観点で目を引くのが IAM のコンテキストキーです。マネージドの MCP サーバーは下流の AWS サービス呼び出しに aws:ViaAWSMCPService と aws:CalledViaAWSMCP を自動で付与します。AI 経由の操作と人手の操作を IAM ポリシーで区別できるということで、同ブログはこれをサービス層で注入するため呼び出し側からは詐称できない、と説明しています。

2つめは AgentCore Gateway です。公式ドキュメントによると、Gateway は Lambda 関数・API Gateway の REST API・OpenAPI 仕様・Smithy モデル・外部の MCP サーバーをターゲットに取り、それらをまとめた単一の仮想 MCP サーバーとしてクライアントへ見せます。クライアントから見えるツール一覧は統合された1つになります。入口の認可は OAuth（JWT）か IAM、下流の呼び出しに使う資格情報は Credential Provider、という二段構えです。

3つめは AgentCore Runtime に自作の MCP サーバーをホストする経路です。プロトコル契約は Streamable HTTP を使い、コンテナが 0.0.0.0 の 8000 番で /mcp を公開し、tools/list と tools/call に対応することを求めています。ここでも、どのリビジョンを前提にするかで実装が変わります。同ページは 2025-11-25 以前では elicitation と sampling にステートフルモードが必要だったが、2026-07-28 以降は多段ラウンドトリップの方式になりステートフルモードが不要になったと、リビジョンを明示して書き分けています。

自前でホストする構成を比較したい場合は、AWS の Prescriptive Guidance にリモート MCP サーバーのデプロイパターン集があり、AgentCore・Lambda と API Gateway の組み合わせ・ECS・EKS・EC2 の5パターンが整理されています。実際に AWS の設計・構築フローへ MCP を組み込んだ手順は、AWS Knowledge MCP・IaC MCP を使った記事で紹介しています。

MCPを導入する前に押さえるセキュリティの前提

MCP サーバーを1つ足すことは、AI アプリケーションに新しい実行経路を1つ足すことです。仕様のトップは Security and Trust & Safety として3つの原則を挙げています。利用者はすべてのデータアクセスと操作に明示的に同意し、内容を理解していること。ホストは利用者データをサーバーへ渡す前に明示的な同意を得ること。そしてツールは任意のコード実行を意味するため、相応の注意をもって扱うこと。

実装側が気をつける点として、公式ドキュメントは具体的な攻撃も名指ししています。セキュリティのベストプラクティスが挙げるもののうち、導入するかどうかの判断に関わるのは次の3つです。

• Token passthrough: MCP サーバーが、自分宛に発行されたものか検証せずにトークンを受け入れるアンチパターン。仕様は「サーバーは自分向けに明示的に発行されていないトークンを受け入れてはならない」と定めています
• Confused deputy: プロキシ型のサーバーが静的な client_id を使い、かつ動的クライアント登録を許している場合に成立しうる問題。クライアントごとの同意取得が必須とされています
• ローカルサーバーの侵害: 手元で動くサーバーは任意コード実行そのものです。ワンクリックで設定できるクライアントは、実行前に同意ダイアログを出すことが必須とされています

ここで1つ、書き方に注意が要る点があります。日本語の解説では「MCP はプロンプトインジェクションのリスクがある」と説明されることがありますが、公式ドキュメントにその語は出てきません。公式は代わりに「ツールの振る舞いの説明や注釈は、信頼できるサーバーから得たものでない限り、信頼できないものとして扱うべき」「あるサーバーのツール実行結果は、別のサーバーにとって信頼できない入力である」という形で記述しています。実務上の対処は同じですが、根拠として引くときは公式の言い回しに沿ったほうが正確です。

運用面では、ツールの仕様が「ツール呼び出しを拒否できる人間が、常に介在しているべきである」と述べている点も押さえておいてください。

MCPが向く場面と、向かない場面

MCP は接続方法を統一する仕組みなので、統一する相手が1つしかないうちは手間だけが増えます。判断の目安を整理します。

gaipack では、社内外のナレッジを扱う AI エージェント基盤 gaibot で、外部 SaaS への接続に MCP を使っています。利用者ごとの OAuth 認可でアクセスし、VS Code や Cursor といった開発ツールからも同じエージェントへ接続できる構成です。実装の様子は gaibot に MCP 連携のエージェント機能を追加した記事と、AWS の設計・構築フローに MCP を組み込んだ記事で紹介しています。

MCPに関するよくある質問

はじめて MCP に触れるときにつまずきやすい点をまとめます。

MCPとは何の略ですか

Model Context Protocol の略です。AI アプリケーションと外部システムを接続するためのオープンな標準規格を指します。同じ MCP という略語でも、マイクロソフトの認定資格や半導体のマルチチップパッケージは別のものです。

MCPとAPIの違いは何ですか

API は個々のサービスが提供するインターフェースで、仕様はサービスごとに異なります。MCP は、AI アプリケーションがそうしたインターフェースを発見して呼び出すための共通規約です。MCP サーバーの中身は多くの場合 API を呼んでいるので、置き換えの関係ではなく層の関係にあります。

MCPとRAGの違いは何ですか

RAG は外部の知識を検索して回答生成に反映する手法で、MCP は AI アプリケーションと外部システムをつなぐプロトコルです。解こうとしている問題の層が違うため、併用できます。RAG の検索基盤を MCP サーバーとして公開し、AI アプリケーションからツールとして呼ぶ構成が実際に使われています。

AIエージェントとMCPサーバーの違いは何ですか

AI エージェントは、目標を受け取ってタスクを分解し、ツールを選んで実行する主体です。MCP サーバーは、そのエージェントが使えるツールやデータを差し出す側にあります。MCP はエージェントを作るためのフレームワークではなく、エージェントがツールへアクセスするための統合レイヤーだと捉えると整理できます。

MCPは何に使うのですか

公式が挙げている例では、カレンダーやドキュメントサービスへのアクセス、デザインデータからのコード生成、複数のデータベースを横断する社内チャットボットなどがあります。共通しているのは、AI アプリケーションが自分の外側にある情報や操作を必要とする場面です。

まとめ

MCP は AI アプリケーションと外部システムの接続方法を標準化する規格で、ホスト・クライアント・サーバーの3者で構成されます。サーバーが提供する Tools・Resources・Prompts は、それぞれモデル・アプリケーション・利用者のどれが制御するかで役割が分かれます。関数呼び出しを置き換えるものではなく、その手前の発見と認可を担う層だと理解すると、既存の設計との関係が見えてきます。

導入を検討するときに確認したいのは3点です。つなぎ先が複数あって標準化の利得が出るか、ツールが増えたときのコンテキスト設計をどうするか、そしてローカルサーバーの配布と同意の取り方をどう統制するか。仕様は2026年7月28日のリビジョンでステートレス化という後方非互換の変更を経ているので、実装に入る前に現行仕様を確認しておくことをおすすめします。

既存の AI 資産を外部向けサービスとして提供する構想がある場合は、課金や API 管理といった周辺の作り込みが必要になります。gaipack では gaipack コネクトとしてこの領域を支援しています。MCP を含む AI エージェント基盤の設計でお困りのことがあれば、お気軽にご相談ください。