最近、AIエージェント界隈でMCPという3文字をよく見かけるようになりました。ChatGPTやClaudeの設定画面、開発者向けのニュースレター、あるいはSaaSの新機能案内などで目にした方も多いはずです。
MCPとはModel Context Protocolの略で、AIモデルが手元のデータや外部のツールへ安全にアクセスするための、共通の「つなぎ方」を定めた規格です。よく使われる比喩がUSB-Cで、パソコンの周辺機器がメーカーを問わず同じ差し込み口でつながるように、AIエージェントと外部システムを同じ手順でつなげるようにする、という発想です。
技術者だけの話に思えるかもしれませんが、実際には自社のプロダクトが持つデータを、顧客が使うAIエージェントにどう渡すかという設計判断そのものでもあります。この記事では、MCPがなぜ生まれたのか、実際にはどういう仕組みで動いているのか、そしてプロダクトマネージャーやRevOpsチームがなぜ今のうちに知っておくべきなのかを、実装の細部ではなくプロダクト視点で整理します。
なぜMCPが必要になったのか
バラバラだった接続方法
MCPが登場する前、AIアシスタントを社内のデータベースやSaaSツールにつなぐ作業は、組み合わせの数だけ個別対応が必要でした。ChatGPT用の連携コードとClaude用の連携コードは別物で、同じSalesforceのデータを読むだけのために似たようなコードを何度も書く羽目になっていたのです。
これは開発者だけの手間の問題ではありません。ツール提供側から見ても、対応するAIサービスが増えるたびに専用の連携を作り続けることになり、保守コストが積み上がっていきます。
新しいAIサービスが登場するたびに、既存の連携をすべて作り直すような負担が発生していたわけです。
N×M問題という壁
この状況はN×M問題と呼ばれます。AIモデルの数をN、つなぎたいツールやデータソースの数をMとすると、組み合わせの数がN×Mで増えていくという意味です。
数値で考えるとイメージしやすくなります。あくまで説明用の仮定ですが、AIモデルが3つ、社内で使うツールが10個あるとすると、理屈のうえでは最大30通りの個別連携が必要になる計算です。
ここにAIモデルが1つ増えるだけで、連携の数は10ずつ増えていきます。
MCPは、AIモデル側とツール側がそれぞれ共通規格にだけ対応すればよい形に整理することで、この掛け算をN+Mの足し算に近づけます。先ほどの例で言えば、3つのAIモデルと10個のツールがそれぞれMCPに対応するだけで済み、必要な対応は13で足りる計算になります。
Anthropicは2024年11月にMCPをオープンソースの規格として公開し、誰でも実装できる仕様として提供しました。
MCPの仕組み——ホスト・クライアント・サーバー
MCPの登場人物は大きく3つに分けられます。AIアシスタントを動かすホスト（ChatGPTやClaudeのようなアプリケーション）、ホストの中でサーバーと通信するクライアント、そしてデータやツールを提供するサーバーです。
JSON-RPCでやり取りする
ホストとサーバーのあいだは、JSON-RPCという軽量なメッセージ形式でやり取りされます。通信経路には、同じマシン上のプロセス間でやり取りするstdioと、ネットワーク越しにやり取りするStreamable HTTPの2種類が主に使われています。
この違いは実務上も意味を持ちます。手元のパソコンで動くファイル整理ツールのようにローカル完結でよいものはstdioで十分ですが、SaaSが自社のデータをAIエージェントに公開したい場合は、ネットワーク越しに使えるStreamable HTTPでリモートのMCPサーバーとして立てる必要があります。
たとえば「今日の売上データを見せて」という依頼に対して、AIエージェントが裏側で送るリクエストとサーバーからの返答は、簡略化すると次のような形になります（実際の仕様はもっと詳細ですが、説明のための一例です）。
リクエスト: {"method": "tools/call", "params": {"name": "get_sales", "arguments": {"date": "2026-08-26"}}}
レスポンス: {"result": {"content": [{"type": "text", "text": "本日の売上は124件でした"}]}}
このように、AIエージェント側は「get_salesというツールを、この引数で呼び出す」という共通の作法さえ知っていれば、裏側のデータベースがどんな構成であっても同じやり方でアクセスできます。
ツール・リソース・プロンプトという3つの窓口
MCPサーバーがホスト側に提供できるものは、大きく3種類に整理されています。それぞれの役割を簡単な表にまとめます。
| 種類 | 役割 | 具体例 |
|---|---|---|
| ツール | AIが呼び出して実行できる処理 | 売上データの取得、チケットの作成 |
| リソース | AIが参照できるデータそのもの | ドキュメント、設定ファイル、ログ |
| プロンプト | よく使う指示のテンプレート | 週次レポートの雛形 |
サーバーを作る側は、この3つの窓口のどれを、どこまで公開するかを自分で設計できます。裏を返せば、公開しないと決めた情報や操作はAIエージェントから一切見えないということでもあり、これが後述するアクセス設計の話につながってきます。
どこまで広がっているのか
OpenAIやGoogleも追随
MCPはAnthropic発の規格として始まりましたが、単独の企業が抱え込む仕様には留まりませんでした。OpenAIは自社のAgents SDKにMCP対応を組み込み、Googleも自社のAI連携ドキュメントの中でMCPに触れるなど、主要なプレイヤーが相次いで対応を進めています。
開発者コミュニティの広がりも急速です。MCPのリファレンス実装を集めた公式サーバー集のリポジトリには、数万件規模のスターが付いています。
GitHubやGoogle Drive、Slackなど、さまざまなサービス向けのサーバー実装がすでに公開されており、表にすると次のような広がり方です。
| 時期 | 出来事 |
|---|---|
| 2024年11月 | Anthropicが仕様を公開、オープンソース化 |
| 2025年 | OpenAIのAgents SDKなど主要プレイヤーが対応を追加 |
| 2025年12月 | Linux Foundation傘下のAgentic AI Foundationへ移管 |
中立的なガバナンスへ
2025年12月には、Anthropicが単独で管理していたMCPの仕様が、Linux Foundation傘下に新設されたAgentic AI Foundationへと移管されました。この動きにはAnthropicに加えてOpenAIやBlockも共同で参加しており、公式ブログの発表によれば、月間のSDKダウンロード数は9700万件を超え、稼働中のサーバーは1万件規模に達しているとされています。
一社の都合で仕様が変わってしまう不安が薄れたことで、企業がMCPを前提に長期の投資判断をしやすくなったという意味でも、この移管は実務上の節目だと言えます。裏を返せば、それだけ多くの企業がすでにMCPを前提にした投資を始めているということでもあります。
プロダクト視点で見るMCPの意味
ここまでの話は開発者向けの技術トピックに見えるかもしれませんが、プロダクトマネージャーやRevOpsチームにとっても無関係ではありません。自社のプロダクトが持つデータを、ユーザーが使うAIエージェントからどう扱われるかという設計判断そのものだからです。
自社のデータをAIに安全に開放する
たとえば自社のSaaSにMCPサーバーを用意すれば、顧客はClaudeやChatGPTに「先月の解約率はどう推移していますか」と自然文で尋ねるだけで、ダッシュボードを開かなくても数字を受け取れるようになります。これは新しいUIをひとつ作るというより、既存の分析機能にもうひとつの入口を足す発想に近いものです。
一方で、何をツールとして公開し、何を公開しないかという線引きは、セキュリティとプロダクト設計の両方に関わる重要な意思決定です。GTMデータ基盤｜AIが正しく動くための土台づくりで触れたように、AIエージェントが正しく動くための土台は、結局のところ人間が丁寧に設計したデータ構造とアクセス範囲に支えられています。
MonaLensでの例
一例として、MonaLensはMCPに対応しており、ファネルの転換率やN1分析の結果を、ClaudeなどのAIから自然言語の問いかけで取得できるようにしています。個人情報を含む問い合わせフォームの回答はこの窓口から除外するなど、MCP経由で何を渡すかというアクセス設計は、機能追加そのものと同じくらい重視すべき部分です。
こうした設計は、セマンティックレイヤー｜AIエージェントの土台として指標定義を一箇所にで扱った、指標の定義を一箇所にそろえておく発想とも重なります。MCPは配管の規格を決めるものであって、その配管の先で何を流すかは、各プロダクトが自分たちで決める必要があるからです。
導入を検討するときの視点
MCP対応を自社プロダクトの機能として検討する場合、いきなり作り込む前に立ち止まって考えたい論点が2つあります。
自作するか、既存の実装を使うか
GitHubやSlack、Google Driveのような主要サービスは、すでにリファレンス実装が公開されています。自社が求める機能がそれらでカバーできるなら、ゼロから作るより既存実装を土台にするほうが、検証にかける時間を短縮できます。
独自のデータ構造や、他社にはない分析ロジックを公開したい場合にだけ、自前のサーバー実装を検討するという順序が現実的です。
何を成功指標にするか
MCP対応そのものは目的ではなく手段です。導入後に、AIエージェント経由の問い合わせがどれだけ実際の意思決定に使われたか、逆に想定外のツール呼び出しが発生していないかといった利用状況を、通常の機能と同じようにログで確認できる設計にしておくことが欠かせません。
作って終わりにせず、後から振り返れる状態にしておくべきだという点は、他のどんな機能追加とも変わりません。
注意しておきたいこと——セキュリティの論点
MCPが便利な半面、AIエージェントに新しい実行権限を与える仕組みである以上、新しい種類のリスクも一緒に持ち込まれます。ここは楽観的な機能紹介だけで終わらせるべきではない部分です。
ツールの説明文に潜むリスク
MCPサーバーが公開するツールには、AIに向けた説明文が付いています。この説明文に悪意のある指示を紛れ込ませ、AIエージェントに意図しない操作をさせようとする手口が、セキュリティ業界ではツールポイズニングと呼ばれ注意喚起されています。
実際にMCPの公式リポジトリでも、セキュリティ上の脆弱性が発見・修正された事例が公開されており、規格自体が発展途上であることが分かります。
信頼できるかどうかわからないMCPサーバーを、動作確認もそこそこにつないでしまうと、こうしたリスクをそのまま自社のAIエージェントに持ち込むことになりかねません。出どころの分からないサーバーはまずつながないというのは、当たり前のようでいて見落とされがちな最初の防衛線です。
権限設計とガードレールの必要性
信頼できないMCPサーバーを不用意につなぐと、AIエージェントがそのまま危険な操作の実行者になりかねません。GTMにAIエージェントを入れる｜人間承認とガードレールの設計で述べたように、金額の大きい操作や不可逆な操作には人間の承認を挟む、読み取り専用の範囲から始めるといった設計上のガードレールが、規格の新しさに関係なく必要になります。
MCPそのものは通信の作法を決めているだけで、何をどこまで許可するかという権限設計までは面倒を見てくれません。ここを甘く見ると、エージェント時代のCRM｜「Agent Parity」が来る前に積むべきもので触れたような、AIに任せる範囲を広げていく流れの中で、思わぬ事故の入り口になってしまいます。
まとめ——標準規格は土台であって戦略ではない
MCPは、AIエージェントと外部のデータ・ツールをつなぐための配管を統一しようという、地味だが実務的な意味の大きい規格です。N×M問題を解消し、OpenAIやGoogleも巻き込みながら中立的なガバナンスの下で育ち始めています。
ただし、規格が普及したからといって、自社のデータをどこまで、どんな形でAIエージェントに開放するかという判断まで自動的に正解が出るわけではありません。その線引きは、プロダクトを預かる側が自分たちの言葉で決める必要があります。
MCPというキーワードを見かけたときは、技術トレンドの一つとして眺めるだけでなく、自社のデータとAIエージェントの間にどんな窓口を用意し、どこに承認のステップを置くかを考える良い機会だと捉えてみてください。