MCPは死んでいない。適切なエンジンが必要なだけだ

by Mike Albritton, 翻訳:古川えりか | January 22, 2026

blog MCP Isn't Dead今、MCPが大きな注目を集めています。特に先日、AnthropicがブログでMCPをスケールさせる際の2つの重大な課題を指摘してからはなおさらです。その課題とは、トークンを消費しすぎること、そしてコンテキストウィンドウがすぐにいっぱいになってしまうことです。Anthropicが推奨するアプローチは、これらの問題を解決するためにコード実行を活用し、Pythonリクエストでデータクエリを動的に生成し、MCPツールをAPIとして提示するというものです。

コード実行には確かなメリットがありますが、新たな課題も生まれます。エンタープライズ環境では特に、再現性のある決定論的な結果が求められ、ガバナンスやコンプライアンスの観点からすべてのクエリを監査できることが不可欠です。

私たちはCData Connect AIというマネージドMCPプラットフォームを構築し、これら2つの課題に戦略的に対処しています。当社のプラットフォームは、MCPのコアメリット(リアルタイムデータ接続を通じてAIツールがオンザフライでコンテキストを積極的に見つける能力)を維持しながら、トークンとコンテキストの課題をデータレイヤーで解決します。私たちの焦点はエンタープライズ規模での構築です。多くのユーザー、多くのMCP接続、多くのAIインスタンスに対して効率的に動作し、デプロイメント全体にわたって必要なセキュリティとガバナンスを備えたアーキテクチャです。

各アプローチと、それらがAnthropicが提起したコアな課題にどのように対処するかを詳しく見ていきましょう。

コード実行とスキルとは何か?

詳細に入る前に、直接的なMCPツール呼び出しの代替として注目を集めている他のアプローチを定義しましょう。

コード実行(「コードモード」とも呼ばれる)は、AIが事前定義されたツールを呼び出す代わりに、カスタムPythonコードをオンザフライで記述・実行することを可能にします。エージェントがデータをクエリしたり、結果を変換したり、複数のソースからの情報を組み合わせたりする必要がある場合、サンドボックス実行環境内でそれを行うコードを生成します。中間結果はAIのコンテキストウィンドウを通過せず、その環境内に留まります。

スキルは、AIが再現性を持って実行できる特定のコンテキストとアクションを持つ事前定義された操作です。タスクを一から解決する方法を考え出す代わりに、AIは一貫した結果を返すための所定のステップと指示に従います。

どちらのアプローチも、MCPを大規模に運用する際の実際の課題を解決するものとして注目されています。コード実行は中間データをコンテキストウィンドウの外に保持することでトークンコストを抑えます。スキルはあらかじめ決められた処理パスにより効率性を実現します。Anthropicをはじめとする各社は、複雑なデータタスクにおいてAIエージェントをより実用的にする手段として、これらのアプローチを推奨しています。

Connect AIはどのように機能するか?

Connect AIは、Anthropicが指摘したトークン使用の課題を解決しつつ、MCPのメリットを最大限に活かせるよう戦略的に設計されています。コード生成や事前定義のスキルでMCPの問題を迂回するのではなく、MCPの利点を損なうことなくプラットフォームレイヤーで根本的に解決するアプローチです。

私たちのアプローチの核心は、AI専用に設計されたセマンティックエンジンです。このエンジンはリアルタイムクエリインテリジェンスレイヤーとして機能し、AIエージェントとエンタープライズデータのやり取りを根本から変えます。AIエージェントは企業のデータソースをConnect AIに接続し、MCPを介してAIクライアントと連携します。Connect AIは、会話に必要な関連コンテキスト(データソース、テーブル、カラム、リレーションシップ)を、AIモデルが理解できる構造化メタデータとして提供します。AIはこのメタデータをもとに的確なクエリを組み立て、自然言語の意図を正確なデータリクエストに変換します。

Connect AIはこのクエリを受け取り、リアルタイムでインテリジェントに最適化します。ソースシステムへのプッシュダウン実行とAIによるインメモリ処理を適切に振り分け、各システムのネイティブAPI言語へと変換します。この処理をConnect AIが担うことで、モデルの負担(そして無駄なトークン消費)を軽減し、データの探索とクエリに特化した専用プラットフォームに処理を委ねます。

単一のMCPエンドポイントを通じて接続されたAIエージェントは、350以上のサポートされているデータソースすべてで動作する効率的なMCPツールセットを使用できます。SalesforceのAPI、Google Driveのフォルダ構造、Snowflakeのクエリ構文を個別に学習する代わりに、エージェントは一貫したインターフェースを使用します。これにより、AIは最も得意とすること、つまり与えられたタスクに最適に応答するための推論と思考連鎖の形成に集中できます。データプラットフォームは最も得意とすること、つまり完全な監査性を備えた効率的で決定論的なクエリ実行とデータ処理を担当します。

Anthropicの記事で浮き彫りになった各課題を詳しく見ていきましょう。

課題1:MCPはトークンを使いすぎる

問題:通常、各ソースシステムには独自のMCPサーバーと独自のツールセットがあります。Githubに登録されている12,000以上のMCPサーバーを見ると、1サーバーあたり平均5.7個のツールを持ち、中には217個以上を公開しているものもあります。複数のサーバーを1つのクライアントに接続すると、このようなツールの増殖によってAIは利用可能なすべてのツールを把握するだけで大量のトークンを消費してしまいます。Anthropicの分析では、ツール定義だけで1つのリクエストを処理する前に15万トークン以上を消費する可能性があると指摘されています。各データソースはページネーション、フィルタリング、認証用に数十もの専用ツールを持ち込みます。エージェントは本来の問題解決ではなく、これらのツールの探索に貴重なコンテキストを浪費してしまうのです。

コード実行は、ソース固有のツールではなく汎用的な機能をAIに与えることで、ツール定義のオーバーヘッドを削減します。すべての操作の定義をロードする代わりに、エージェントが必要な処理をカスタムコードとして記述するのです。Anthropicの記事では、処理中にPIIをトークン化する機能や、生成スクリプトで必要な機能を動的に発見する能力などが紹介されています。

このアプローチは事前のトークン消費を削減するのに効果的です。ただし、トレードオフもあります。リクエストのたびにコードを生成・検証・実行するオーバーヘッドに加え、安全なサンドボックス環境を用意するためのインフラ要件が発生します。

私たちはわずか9つの効率的なMCPツールセットでMCPプラットフォームを構築しました。これにより、AIは事前にツールコンテキストをロードしてナビゲートするのではなく、推論に集中できます。私たちのアプローチは、複数のMCPサーバーがそれぞれ独自のツールセットとデータ接続を持つことで生じる、トークンを大量消費するツール選択プロセスをスキップすることです:

  • 接続されたすべてのソースで機能する効率的な汎用MCPツールセット。9つのツールが350以上のデータソースのスキーマ検出、クエリ実行、書き込み操作を処理します。各システムごとに個別のツール定義をロードする必要はありません。

  • 多くのシステムのコンテキストへの単一のMCPエンドポイント。エージェントがSalesforceの顧客データ、Zendeskのサポートチケット、Snowflakeのテレメトリを必要とする場合、事前に3セットのツール定義をロードしません。一度データをリクエストすれば、当社のプラットフォームが残りを処理します。

  • ソース固有のMCP指示によるデータ探索の絞り込み。プラットフォームには接続先の各ソースに関するインテリジェンスが組み込まれており、必要なデータセットを見つけるためのクエリ回数を削減します。

また、特定のユースケース向けにカスタマイズできる機能も提供しており、スキルと同様のメリットを得られます:

  • 派生ビューを使用すると、データ操作の指示に数千のトークンを消費することなく、複雑なクエリを再利用可能な形で保存できます。5つのテーブルを結合する「顧客ヘルス」の計算も、一度定義すれば直接クエリできます。これはAnthropicの記事で説明されているスキルへのクエリと同等です。

  • カスタムツールでは、ユースケースに応じた独自のアクションを定義できます。これは、コード実行モデルのアクションスキルに相当します。

ベンチマークテスト:このアプローチを検証するため、同じリクエストを汎用MCPサーバーとConnect AIの両方で実行しました。リクエスト内容は「上位5社の高価値顧客について、現在のヘルスステータスを含むエグゼクティブサマリーを作成する」です。

従来のMCPサーバーは10回のツール呼び出しで96,000トークンを消費しました。Connect AIは同じタスクを14,202トークンと3回の呼び出しで完了しました。これはトークン使用量85%削減、API呼び出し70%削減です。

課題2:MCPはAIコンテキストウィンドウをいっぱいにする

問題:不要なデータ、サーバー定義、ツールのオーバーヘッドによってコンテキストウィンドウが圧迫され、会話が途中で打ち切られたり、AIが過去のコンテキストを失ったりする原因となります。MCPの設計では、中間結果がコンテキストウィンドウを経由して繰り返し受け渡されます。10,000件のレコードをクエリすると、そのすべてがコンテキストウィンドウに格納されます。複数のソースからデータを結合する場合、各中間ステップがコンテキストを消費していきます。

Anthropicの記事では、重要な点も指摘されています。「大規模なドキュメントや複雑なデータ構造を扱う場合、モデルがツール呼び出し間でデータをコピーする際にミスが発生しやすくなります。」コンテキストの飽和は、会話の長さを制限するだけでなく、応答品質の低下にもつながります。

コード実行では、中間結果をAIのコンテキストウィンドウに通すのではなく、実行環境内で保持します。データの変換や結合を行う際、結果は最終出力が準備できるまでメモリ内にとどまります。

ただし、コード実行には固有の複雑さも伴います。Anthropicもこの点を明確に認めています。「エージェントが生成したコードを実行するには、適切なサンドボックス化、リソース制限、監視機能を備えた安全な実行環境が必要です。これらのインフラ要件により、直接的なツール呼び出しでは不要な運用オーバーヘッドやセキュリティ上の考慮事項が追加されます。」これらのメリットは、実装コストとのトレードオフとして検討する必要があります。

私たちは専用のセマンティックエンジンを設計しました。このエンジンはリアルタイムのクエリインテリジェンスレイヤーとして機能し、データレイヤーでクエリロジックを実行することで、最も関連性の高いデータのみをAIのコンテキストウィンドウに取り込みます。AIはMCPを通じてConnect AIに必要なデータを要求するため、利用可能なデータをすべて取得して会話内で推論を試みる必要がありません。

CDataは、AIに接続する前にデータを事前に整理・カタログ化するという従来のアプローチとは異なり、データが収集・保存されているソースシステム内でその場でクエリを実行する新しい手法を採用しています。さらに、AIが適切なデータコンテキストを選択できるよう、プラットフォームレベルでセマンティックエンジンを提供します。これにより、AIのコンテキストウィンドウ内でデータの取り込み、ソート、解析を行う必要がなくなり、これらの操作はAI向けにデータレイヤーでオンデマンド実行されます。

  • インテリジェントクエリ処理:このエンジンは、エンタープライズ統合の妨げとなる複雑な処理を担います。並列ページフェッチによるAPIページネーションの管理、バルクエンドポイントの自動検出と活用(利用可能な場合)、スロットリングエラーを防ぐための各システムのレート制限遵守、JSON・XML・CSVなど各種形式からの応答の標準構造への変換を行います。従来であれば各ソースシステムに対して数か月のカスタム開発が必要だった処理が、自動的に実行されます。

  • プッシュダウンアーキテクチャ:当社のエンジンは、データのフィルタリング、集計、変換をソース側で処理し、モデルが処理すべき生データではなく、エージェントが必要とする結果のみを返します。このプッシュダウンアーキテクチャにより、モデルは数千行のデータを処理して必要な情報を抽出する必要がなく、クリーンで関連性の高い回答を直接受け取れるため、トークン消費を大幅に削減できます。

ベンチマークテスト:私たちは複雑なクロスシステムクエリを実行しました。「上位5社の高価値顧客について、現在のヘルスステータスと必要な即時アクションを含むエグゼクティブサマリーを作成する」というクエリで、SalesforceのアカウントおよびOpportunityデータ、Zendeskのサポートチケット、Snowflakeのテレメトリデータが必要でした。クエリプッシュダウンを使用しない場合、LLMは4つの大規模なデータセットをコンテキストウィンドウ内に取得・保持し、顧客の特定、サポート履歴の関連付け、インサイトの統合のために、コンテキスト内で数千件のレコードを処理する必要がありました。一方、インテリジェント処理とクエリプッシュダウンを使用した場合、Connect AIはまずクエリを解析し、セマンティックエンジンによって各ソースシステムがクエリのどの部分に回答できるかを判断してからクエリを実行します。関連するレコードのみを取得し、LLMのコンテキストウィンドウの外部で結果を結合しました。モデルが受け取るのは、ヘルスメトリクスが関連付けられたわずか5社の顧客に関する、クリーンで前処理済みのデータセットのみです。これにより、モデルはデータラングリングではなく、分析と推論に集中できました。私たちのテストでは、AIが推論を適用する前にデータを関連性に基づいてキュレーションすることで、コンテキストウィンドウの使用量を最大2〜5分の1に削減できることが確認されました。

MCPのセキュリティとガバナンスの提供

MCPのトークン効率に関する課題を解決するだけでなく、企業はすべてのAIデータアクセスが安全かつ監査可能であるという確信も必要としています。これは、AIがMCP、コード実行、スキルのいずれを使用しているかに関係なく求められます。コード実行アプローチには、エンタープライズセキュリティ上のリスクが新たに伴います。

  • 確率的不確実性:LLMが実行可能なコードを生成する場合、AI応答に固有のランダム性がさらに増幅されます。同じリクエストでも会話ごとに微妙に異なるPythonコードが生成され、予測不可能な結果を招く可能性があります。

  • 監査の複雑さ:コンプライアンス部門が「エージェントが先月どのデータにアクセスしたか」を確認する際、数千件の個別Pythonスクリプトをレビューすることは現実的ではありません。一方、プラットフォームに記録されたデータクエリは自己文書化されており、監査が容易です。

  • セキュリティギャップ:サンドボックスはコードの外部への流出を防ぎますが、AI外部でのデータアクセスポリシーは強制できません。AIチャットインターフェース内だけでなく、より広範なレベルで権限設定を追加する必要があります。

当社のプラットフォームはAIとデータシステムの間に位置しています。そのため、Connect AIは企業がMCPを大規模かつ安心して活用できるよう、重要なデータセキュリティとガバナンスコントロールを提供する設計となっています。

  • 組織知識の体系化:コード実行では、各会話で最適化パターンを再発見する必要があります。一方、プラットフォームアプローチでは、特定のデータシステムパターンを一度最適化すれば、そのセマンティックインテリジェンスをあらゆる場面で適用できます。コンテキスト固有のスキルは作成・共有が可能ですが、手動での開発とメンテナンスが必要であり、ソースシステムの更新やデータスキーマの変更により破綻するリスクがあります。

  • アイデンティティファーストのセキュリティ:Connect AIはクエリをパススルーして基盤システムの権限を尊重し、OAuthおよびSAMLを介してユーザー認証情報を引き継ぐため、すべてのエージェントリクエストは実行時にソースシステムのアクセス制御が適用されます。エージェントは、クエリの構成に関係なく、ユーザーがアクセス権を持たないデータにはアクセスできません。このアクセス制御はプラットフォームレベルで、データがAIモデルに到達する前に適用されるため、プロンプトインジェクション攻撃によるセキュリティのバイパスを防止し、モデル操作を通じたデータ漏洩を排除します。

  • クエリレベルの可観測性:すべてのインタラクションは、包括的な監査証跡(クエリ、ユーザー、結果セット、タイムスタンプ)を備えた単一のガバナンスレイヤーを経由します。すべての操作は、完全な帰属情報を含む人間が読めるクエリとして記録されます。生成されたコードのフォレンジック分析は不要です。

  • 一元管理:IT部門は単一のプラットフォームを通じて、すべての接続、認証、ポリシーを管理できます。ガバナンスの管理外でシャドウMCPサーバーが立ち上がることはありません。

  • ゼロデータ保持:CDataはゼロデータ保持モデルで運用しています。エージェントリクエストは通過し、結果が返された後、エンタープライズデータは保存もキャッシュもされません。組織は、集中データストレージに伴うセキュリティリスクを負うことなく、接続の一元化によるメリットを享受できます。

マネージドプラットフォームでMCPを効率的に実装する

AnthropicがMCPに関して指摘した課題は確かに存在しますが、それらはプロトコル自体の欠陥ではなく、実装上の問題です。適切なアーキテクチャアプローチを採用することで、MCPの本質的なメリットを損なうことなく、トークン消費やコンテキストウィンドウの問題を軽減できます。

 

一般的なMCPサーバー

コード実行

Connect AI

トークン使用量

数十万

数千

数千

コンテキストウィンドウ使用量

クエリロジック

MCPツールレイヤー

AI推論レイヤー

データレイヤー

決定論的

はい

いいえ

はい

監査証跡

限定的

チャット履歴経由のみ

完全

クロスソースフェデレーテッドジョイン

なし

手動

ネイティブ

セキュリティ

サーバーごと

AI内でサンドボックス化、外部は非対応

エンドツーエンドでプラットフォーム強制

私たちがConnect AIを構築したのは、AIエージェントやアシスタントに対し、与えられたクエリに最適なアプローチを自ら考え推論する柔軟性(あらかじめ決められた手順に従うスキルではなく)を提供しつつ、決定論的で監査可能な結果(会話ごとに結果が変わるコード実行ではなく)を実現するためです。

MCPの主要なメリットは維持されます。それは、AIに自律的なアクション実行とデータ理解のためのツールを提供することです。MCP接続を支える適切なデータプラットフォームがあれば、AIの能力を制限することなく、トークン使用量とコンテキストウィンドウの消費を抑えることができます。

私たちのビジョンは、AIを導入する企業が、非決定論的なコード実行や、あらかじめ決められたパスに従う事前設定されたスキルに頼ることなく、大規模かつインテリジェントなデータアクセスと自律的なアクションのためにMCPを活用することです。AIの将来において、効率性、柔軟性、ガバナンスのいずれかを選ばなければならないという状況があってはなりません。適切なプラットフォームソリューションがあれば、実績のある既存プロトコルを使用して、この3つすべてを実現できます。

Anthropicコネクタディレクトリで利用可能に

14日間の無償トライアルを開始して、Connect AIのMCPアプローチをぜひご体験ください。Connect AIは先日Anthropicの認定を受け、Claude、Claude Code、Agent SDKにおいてClaudeユーザー向けに紹介されています。詳細についてはこちらをご覧ください。今すぐClaudeでお試しいただけます。

※本記事はCData US ブログMCP Isn't Dead. It Just Needs the Right Engine の翻訳です。

今すぐCData Connect AIを体験

Connect AIがリアルタイムのインサイトを得るためにビジネスプロセスの効率化にどのように優れているかをご覧ください。

トライアルを開始