「MCPとは？」を本当に理解したい人へ

この記事を書いた背景

私はAI活用を推進・拡大させようと考えている多くのエンタープライズ企業の方々とお話をする機会が多くあります。技術的にはAIがMCPを使って様々なリソースにアクセスすることが可能になった一方で、「社内で安心・安全に使うためには課題がある」とおっしゃる方が多くいらっしゃいます。結果として、「AIエージェントをPoCで動かせたが、本番に移行できない」という状況が生まれています。

そこで本ブログでは、「MCPとはそもそも何か」「MCPプロトコルだけでは何が足りないのか」「乱立するMCPサーバーの本質的な違いは何か」という問いに答えていきます。

MCP（Model Context Protocol）という言葉を最近よく耳にするようになりました。AIエージェントの文脈で語られることが多く、「これからのAI活用に必須」という論調も増えています。

しかし正直なところ、「なんとなく重要そう」「APIとどう違うの？」「うちの会社でも導入すべき？」という疑問を持っている方も多いのではないでしょうか。

この記事では、MCPとは何か、なぜ今注目されているのか、そして 「MCPさえあれば企業のAI活用が解決する」という誤解 について、わかりやすく丁寧に整理していきます。

読み終えたときに、「MCPの本質と、それだけでは足りない理由」が腑に落ちたと感じてもらえれば幸いです。

1. MCPとは何か：AIと外部ツールを繋ぐ標準プロトコル

MCP（Model Context Protocol）は、Anthropicが2024年11月に公開した、AIモデルと外部ツール・データソースを接続するためのオープンプロトコルです。

一言で言えば、「AIがどうやって外部のシステムや情報にアクセスするかの作法を定めた標準仕様」です。

なぜMCPが必要だったのか

これまでAIをシステムと連携させるには、連携先ごとに個別の実装が必要でした。Slackと連携するにはSlack用のコード、Salesforceと連携するにはSalesforce用のコード……というように、接続先が増えるほど実装コストが増大します。

MCPはこの問題を解決するために設計されました。プロトコルを標準化することで、どのAIモデルも、MCPに対応したツールなら同じインターフェースで利用できるようになります。

MCPの基本的な仕組み

MCPは3つのコンポーネントで構成されています。

• MCP Host：AIアプリケーションの実行環境（ChatGPT, Claudeなど、ユーザーが直接操作するアプリケーション）
  
  
• MCP Client：MCP Host内に組み込まれ、MCPサーバーと通信する役割を担うコンポーネント
  
  
• MCP Server：外部ツールやデータソース（Googleカレンダー、Salesforceなど）への接続を提供するコンポーネント

AIが「Googleカレンダーの来週の予定を知りたい」と判断したとき、MCP ClientがGoogleカレンダーのMCP Serverに問い合わせ、結果を受け取る—というのが基本的な流れです。

2. MCPとAPIの違い：iPaaSも含めた3つの技術を比較する

MCPをより深く理解するために、「API」「iPaaS」という先行技術との関係を整理しましょう。

APIが解決しようとしたこと

APIは、異なるシステム同士がデータをやり取りするための「窓口」です。「このURLにこの形式でリクエストを送れば、このデータが返ってくる」という取り決めを、サービス提供者が定義します。

ただし、APIには大きな課題がありました。M×N問題です。

3つのアプリが5つのサービスと連携するとき、最大15の個別実装が必要になります。それぞれの仕様を調べて、認証を実装して、エラー処理を書いて……という作業が連携先の数だけ発生します。

iPaaSが解決しようとしたこと

iPaaS（Integration Platform as a Service）は、このM×N問題を解決するために登場しました。

あらかじめ数千のシステムへのコネクターを用意し、利用者はそれを選んで繋ぐだけで連携が実現します。さらに、認証管理・アクセス制御・監査ログ・エラー処理といった企業が求めるガバナンス機能もプラットフォームレベルで提供されます。

人間が「このシステムとあのシステムをこのルールで繋ぐ」と設計するワークフローを、大幅に効率化したのがiPaaSです。

MCPが解決しようとしていること

MCPは、AIが自律的にツールを判断・選択・実行する時代に対応した標準化です。

人間がフローを設計するのではなく、AIが「この目的を達するには、どのツールを使えばいいか」を自分で考えて実行します。そのためには、どんなツールがあって、どう使えるかをAIが共通の作法で理解できる必要があります。それがMCPの役割です。

三者の比較

技術の進化を見ると、「人間が全部手で繋ぐ時代（API）」→「プラットフォームが人間のワークフローを効率化する時代（iPaaS）」→「AIが自律的に判断・実行する時代（MCP）」という流れが見えてきます。

3. MCP不要論は正しいのか：現場から見た公平な評価

MCPへの注目が高まる一方で、技術者コミュニティでは「MCP不要論」という議論も活発です。この議論から逃げずに正面から向き合ってみましょう。

不要論の主な論点

不要論者が指摘するのは、主に次の3点です。

① トークン効率の問題

MCPでは接続しているツールのスキーマや説明文がすべてコンテキストに読み込まれるため、実際には使わないツールの情報がトークンを圧迫します。CLIやAPIの直接呼び出しと比べてトークン消費が大幅に増えるケースがあり、Anthropic自身のリサーチでも、複雑なタスクではMCPのスケーリング問題が指摘されています。

② CLIの方が自由度が高い

シェルスクリプトやCLIによる直接実行なら、呼び出すコマンドやエンドポイント、認証・権限の設定まで、すべて開発者が自分の思い通りに組み立てられます。「MCPは抽象化が過剰だ」という指摘は、技術的に正当です。

③ 標準化のコストとリスク

MCPに対応したサーバーを用意するにはコストがかかります。また、悪意あるMCP Serverや設定ミスによるセキュリティリスクも無視できません。

不要論が本当に問うているもの

これらの批判は、いずれも 「MCPというプロトコルそのものへの批判」です。つまり「CLIやAPIで直接実装できるのに、なぜプロトコルを挟むのか」という問いです。これは技術的に正当な議論です。

しかし、企業のAI活用という文脈で本当に問うべきは、プロトコルの優劣ではありません。

「AIが自律的に動く環境において、誰が何をどう制御するか—つまりコントロールプレーンが存在するかどうか」です。

CLIで直接実装した場合、実行内容の制御・監査・ガバナンスはすべて実装者に委ねられます。接続先が増え、AIエージェントが複数の判断を自律的に行う環境になればなるほど、「何がどこで何をしているかわからない」状態が生まれます。

MCP不要論者が指摘する問題（トークン効率・制御の複雑さ）は、MCPプロトコル自体の問題です。一方、企業が直面するのは「プロトコルの上に、安定したコントロールプレーンがあるかどうか」という別次元の問題です。

「MCPが必要かどうか」より前に、「コントロールプレーンとして何を採用するか」を問うことが、企業のAI活用の本質的な論点です。

4. MCPサーバー導入前に知るべき7つの限界

ここが、この記事の核心です。

MCPはすばらしい標準化ですが、プロトコルはあくまで「接続の作法」を定めるものです。企業でLLMを活用するために必要な課題のすべてには対応できません。

なお、「AIが業務で使えない理由」として「コンテキストの欠如・確実性の欠如・セキュリティ/ガバナンスの欠如」という3つの切り口で整理する見方もあります。以下の7つの限界はそれをより細かく分解した別の切り口であり、同じ問題構造を異なる粒度で捉えたものです。どちらの整理も補完的に参照してください。

課題1：接続できるシステムの範囲の限界

MCPプロトコルに対応したMCPサーバーが存在するシステムにしか、AIはアクセスできません。

企業内には通常、数十から数百のシステムが存在します。ERPシステム、CRM、会計ソフト、業務独自のシステム……そのすべてにMCPサーバーが用意されているわけではありません。

MCPサーバーがない = AIがアクセスできない、という状況が生まれます。

課題2：エンタープライズガバナンスの欠如

MCPプロトコル自体は「どのように通信するか」を定めていますが、「誰が何にアクセスできるか」「何が起きたかを記録するか」は、実装者に委ねられています。

企業が求める以下の機能は、プロトコルの範囲外です。

– 操作の監査ログ

– ロールベースのアクセス制御（RBAC）

– データの暗号化ポリシー

– コンプライアンス対応（SOC2、GDPRなど）

これらを個別に実装するコストと品質のばらつきは、企業にとって大きなリスクになります。

課題3：MCPサーバーの乱立と管理の複雑化

MCPの普及とともに、社内外で多数のMCPサーバーが乱立するという新たな課題が生まれています。各部門が独自にMCPサーバーを立て、AIが好き勝手にアクセスするような状況は、セキュリティとガバナンスの観点から大きなリスクになります。

この課題に対応するために注目されているのがMCPゲートウェイです。複数のMCPサーバーへのアクセスを一元的に管理し、認証・認可・監査ログを統制する役割を担います。しかしMCPゲートウェイ自体もプロトコルの定義外であり、どのような実装を選ぶかが問われます。

課題4：ビジネスプロセスの複雑さへの対応

MCPプロトコルは「AIがツールを呼び出す」ことを定義しますが、複数のシステムをまたぐ複雑なビジネスプロセスの制御は定義しません。

例えば「受注情報がSalesforceに登録されたら、在庫確認してNetSuiteに受注登録し、Slackで担当者に通知する」という一連のプロセスをAIが自律的に実行する場合、プロセスの制御・エラーハンドリング・人間への確認フローはプロトコルだけでは実現できません。

課題5：AIに渡すコンテキストの設計

AIがシステムから受け取るデータは、多すぎても少なすぎても問題です。フォーマットの違いや欠損値はAI側がある程度解釈できますが、より本質的な課題は「必要な情報を適切な粒度でAIに渡せるか」という設計の問題です。

単なるAPIのラップとしてMCPサーバーを構築すると、AIに不要な情報まで流れ込み、重要なインサイトを埋もれさせるノイズになったり、コンテキストウィンドウを圧迫する原因になります。MCPプロトコルはデータの受け渡し形式を定めますが、何をどの粒度で返すかはスコープ外です。

AIに複雑なオーケストレーションを強いるのではなく、MCPサーバー側がビジネスロジックを持ち、AIが判断に集中できる情報だけを返す設計が求められます。

課題6：エンタープライズ級の実行基盤

MCPは接続の仕様であり、実行基盤ではありません。大量のリクエストをこなすスケーラビリティ、障害時のフェイルオーバー、SLAの担保といった、企業の本番環境に求められる要件はプロトコルの外にあります。

課題7：LLMの不確実性の制御

MCPは「AIが何をできるか」を定義しますが、「何をAIに任せてはいけないか」は定義しません。

LLMは確率的な挙動をします。同じ入力でも異なる出力が返ることがあります。企業の業務プロセスでは、このゆらぎを許容できない場面が多くあります。

重要な意思決定に人間のレビューを挟む仕組み、LLMが誤った判断をした場合のフォールバック処理—これらはプロトコルではなく、上位のアーキテクチャで解決すべき問題です。

5. エンタープライズAIに必要なMCPサーバーの選び方

ここまで読んで、冒頭でお伝えした「PoCで動かせたが、本番に移行できない」という課題の正体が少し見えてきたのではないでしょうか。

原因の一つは、MCPプロトコルへの対応だけを判断基準にしてしまうことにあります。「MCPに対応している」は入場券に過ぎません。プロトコルへの対応はあくまで接続の出発点であり、それだけでは企業の業務プロセスを動かすには到底足りません。

重要なのは、MCPサーバーがプロトコルの裏側で何をしているかです。単なるAPIのラップであれば、認証・認可・エラーハンドリング・監査ログといったエンタープライズ要件は何も満たされません。AIに渡すデータの粒度やビジネスロジックの実装も、すべてMCPサーバー側の設計にかかっています。

ここで、混乱しやすい概念を一点整理しておきます。MCPは「AIと外部システムを繋ぐハブ」として説明されることがありますが、これは概念としてのハブ（通信プロトコル）の話です。実際に価値を生むのはその実装、つまりMCPサーバーです。プロトコルと実装を混同すると、「MCPを入れれば全部解決する」という誤解が生まれやすくなります。

企業での本格運用に耐えるためには、MCPプロトコルへの対応に加え、そのMCPサーバーがガバナンス・セキュリティ・オーケストレーション・可観測性をどこまで担えるかを見極める必要があります。その判断軸を整理しましょう。

これらを満たすには、iPaaSがエンタープライズ統合の世界で長年培ってきた機能・思想・資産 が必要になります。

APIの時代にM×N問題を解決し、ガバナンスを統一し、ビジネスプロセスを抽象化してきたiPaaSの歴史は、そのままMCPサーバーに求められる条件と重なります。

MCPという新しいプロトコルの上に、何が乗っているか。それが Agentic AIの実装品質を決める のです。

おわりに

MCPは間違いなく、AI活用における重要なプロトコルです。標準化によってAIとシステムの接続が劇的に簡単になり、エコシステムの拡大も加速しています。

しかし、プロトコルはあくまでも「接続の作法」を定めるものです。企業内でLLMを安心してビジネスに活用するためには、MCPプロトコルの上に、ガバナンス・ビジネスプロセス制御・データ品質・決定論的な実行基盤が必要になります。

「PoCで動いたのに、本番に移行できない」—その壁の正体は、多くの場合ここにあります。

「MCPサーバーを導入する」という意思決定をする前に、ぜひ問いかけてみてください。

「あなたの会社が検討しているMCPサーバーは、プロトコルへの対応だけでなく、これらの条件を満たしていますか？」

その問いへの答えが、企業のAI活用を「PoC止まり」にするか「本格運用」に進めるかの分岐点になります。

参考：

• Anthropic – Introducing the Model Context Protocol
  
  
• MCP公式仕様 (2025-03-26)
  
  
• MCP (Model Context Protocol)とは？～単なる標準プロトコル以上の意義と注意点 – Workato Japan note
  
  
• MCPはなぜCLIに負けたのか — 経緯と構造を整理する – Zenn
  
  
• ソフトウェアは誰のために作られるのか─「MCPはCLIに負けた」論から見える本当の構造変化 – note
  
  
• MCP不要論への回答 — バイブコーディングの限界とMCPの本質的価値 – Qiita