MCPは終わったのか?その議論が間違っている理由

MCPは終わっていない。問題はガードレールなしで使うことにある。

AI業界では毎週のようにルールを書き換えるようなニュースが登場します。すべての企業にOpenClaw戦略が必要だと言われたり、エージェント同士のプロトコルがツールコールを置き換えると言われたり、Anthropicがサプライチェーンリスクだと議論されたりしています。

そして最新の話題がこれです。

「MCPは終わった」

この変化のスピードは非常に速く、多くの企業が評価する前に議論が次へと移ってしまいます。

PerplexityのCTOであるDenis Yarats氏は、社内でMCPからの移行を進めていると述べています。Y CombinatorのGarry Tan氏はMCPを使わずCLIを構築しました。CloudflareはMCPのツールコールをコード生成に置き換え、トークン使用量を244倍削減しました。

彼らが直面している課題は現実のものです。2,500のAPIエンドポイントを持つ基本的なMCPでは、トークンを大量に消費し、コンテキストを圧迫します。Cloudflareの検証では、ツールの説明だけで約244,000トークンが消費され、ユーザーの入力処理前に限界に達してしまいます。

複数のMCPサーバー間での認証も設計上不安定です。15個の細分化されたツールにアクセスできる状態で注文処理を行わせると、LLMは毎回正しい順序を判断しなければなりません。しかしLLMは非決定的であり、それが推論能力の強みである一方で、業務ロジックにおいてはリスクとなります。

ただし、基本的なMCPをそのまま本番環境で使うべきではありません。これは明確です。

それは、研修も権限管理も承認フローもない状態で、インターンに全システムのアクセス権を渡すようなものです。そして問題が起きたときに鍵のせいにするのと同じです。

MCPはプロトコルであり、すべてを解決するものではない

MCPは確かに価値のある機能を提供します。エージェントに対して指示を与え、外部ツールへのアクセスを可能にし、システム横断でのアクションを実行できるようにします。標準化されたディスカバリ、共通インターフェース、そしてMCP対応クライアントが任意のMCPサーバーを呼び出せる仕組みは大きな利点です。

しかし、プロトコルはプラットフォームではありません。MCPは接続レイヤーを標準化しましたが、ガバナンス、オーケストレーション、アイデンティティ管理、観測性といった、エンタープライズでの本番運用に必要な要素はカバーしていません。

MCPから離脱している批判者たちは、誤った問題を解決しようとしています。APIやCLIに戻ることでオーバーヘッドは削減されますが、同時にMCPが解決しようとしていた課題も再び持ち込まれます。標準化されたディスカバリはなく、統一されたガバナンスもなく、監査ログも分散されます。すべての接続は再び個別に構築・管理されることになります。MCPからCLIへ移行しても、プロンプトインジェクションや権限昇格のリスクはなくなりません。変わるのはプロトコルであり、脅威モデルではありません。

本当に問うべきなのは、MCPを使うかどうかではありません。

エンタープライズスケールで機能させるために、MCPの下に何を置くかです。

3つのレイヤー:エンタープライズが取るべきAIアーキテクチャ

MCPの議論から一歩引いて、より本質的な問いを考えてみてください。変化の激しい環境の中でも破綻しないAI戦略を、企業はどのように設計すべきでしょうか。

答えは3つのレイヤーです。

最下層はシステムオブレコードです。ERP、CRM、データベース、データウェアハウス、オンプレミスシステム、SaaSなど、ビジネスの基盤となるデータです。ここは頻繁に変わるべきではなく、AIが推測や補完をしてはいけない領域です。

最上層は変化の速いAIイノベーションレイヤーです。AIモデル、エージェントフレームワーク、コパイロット体験、新しいUIプロトコルなどが該当します。GPT-5の登場、Claudeの進化、新しいツールや研究の登場など、この領域は高速に進化します。ここでは試行錯誤と選択が求められます。

中間層は安定したアクションとコントロールプレーンです。多くの企業が欠いているのがこのレイヤーであり、AIの実験が実際のビジネス価値になるか、単なる技術的負債になるかを分ける要素です。

この層にはガバナンス、ワークフロー、業務ロジック、アイデンティティ管理、アクセス制御、監査ログが含まれます。新しいモデルやフレームワークが登場するたびに変えるべきではない領域です。

「見積作成」や「返金処理」といったコンポーザブルスキルは、在庫確認、価格検証、支払い確認、承認フローといった実際の業務ロジックを内包します。これらはモデルやフレームワークが変わっても再構築する必要はありません。

このロジックを特定のエージェントや単純なMCP実装に依存させると、環境が変わるたびに作り直すことになります。

そしてその変化は、来週にも起こり得ます。

この分離を実現できる企業は、持続可能なAI基盤を構築できます。そうでない企業は、半年ごとに作り直すことになります。

コントロールプレーンが実際に担う役割

Workato Enterprise MCPは、この中間レイヤーを担います。プロトコルの価値である接続性やディスカバリは維持しつつ、基本的なMCPに欠けている3つの要素を提供します。

Context

現在の多くのMCPサーバーは、単にJSONを返すだけの薄いラッパーです。開発者にとっては十分でも、企業のエージェントにとってはノイズが多く、トークン消費と誤認識のリスクを高めます。

Enterprise MCPでは、複数システムのデータを統合・変換し、エージェントが理解できる形で提供します。生データではなく、意思決定に使える要約が返されます。

Trust

基本的なMCPはサービスアカウントで動作し、ユーザー単位の権限継承がありません。どのMCPサーバーがどこで動いているかも把握できない状況が発生します。

Enterprise MCPでは単一のゲートウェイで管理され、統一されたアイデンティティと権限モデル、監査ログが提供されます。エージェントはユーザーの権限範囲内でのみ動作します。

Accuracy

最も重要なのがここです。エージェントに複雑な業務プロセスをAPI単位で組み立てさせるのではなく、コンポーザブルスキルとして実行します。

1つのスキル呼び出しで、複数ステップのワークフロー、エラーハンドリング、承認フロー、ロールバック処理が実行されます。エージェントは意図を伝え、実行はスキルが担います。

この分離こそが、デモと本番の違いを生みます。

これはスピードを落とすのではなく、加速させる

AIコントロールプレーンに投資すべき理由はシンプルです。すべての上位レイヤーを加速させるからです。

既存の自動化が100あれば、それはそのまま100のコンポーザブルスキルになります。エージェントは即座にそれらを利用できます。ゼロから構築する必要はありません。

さらに、この構造により柔軟性も確保されます。モデルの変更やフレームワークの切り替えも容易で、再構築は不要です。

これによりAI導入の経済性も変わります。新規開発ではなく、既存投資を活用したエージェント活用へと変わります。

進化のスピードは止まらない

AIの進化は今後も続きます。新しいモデルやプロトコルは次々に登場します。現在のフレームワークの一部は1年半後には存在しないかもしれません。

「MCPは終わった」という議論も、すぐに別の議論に置き換わるでしょう。

重要なのは、その変化に耐えられるアーキテクチャを持っているかどうかです。

基本的なMCPをガードレールなしで使えば失敗します。しかし、Context、Trust、Actionを備えたWorkato Enterprise MCPは、エージェント型AIを実際のビジネス価値へとつなげる基盤となります。

より速く。より安全に。継続的な変革を。

問うべきはMCPを使うかどうかではありません。

コントロールプレーンを今構築するか、それとも本番環境で問題に気づくかです。

Workato logo

Workato Enterprise MCPは、組織のすべてのAI施策におけるコントロールとアクションの基盤です。25,000社以上に選ばれる統合・自動化プラットフォームの上に構築されています。

詳細を見る →