AI をエンタープライズデータに接続するなら、プロトコルよりもアクセスパターンのほうが重要です。本記事では、その点を率直に比較します。

Model Context Protocol（MCP）は、実に優れたアイデアです。これにより、AI エージェントは実行時にツールを呼び出す標準的な方法を手に入れ、対話型 AI アプリケーションにとってはまさに最適な基本要素となります。CData は、このユースケース向けに独自の MCP サーバー「CData Connect AI」を提供しています。

しかし今、多くのチームが、MCP が本来想定していなかった仕事、すなわちデータ連携の構築と実行のために、汎用またはソースネイティブな MCP サーバーを利用しています。Salesforce の MCP と SaaS アプリの MCP を組み合わせ、それらをエージェントに扱わせます。しかしその結果、クエリの遅延、トークンコストの高騰、そして脆弱なパイプラインという、決まって生じる問題に直面することになります。

開発者が開発を進められるように AI とデータを接続することは、それとは別の仕事です。そして CData CLI は、重要な 3 つの観点でこの仕事により適しています。その理由を、テストデータが示しています。

概要

1. クエリ可能なスキーマ、JOIN、集計、サーバー側のプッシュダウン

これが最大のポイントであり、アーキテクチャに関わる問題です。

典型的な非 CData 型の MCP は、固定されたツールメニュー（ツールの数はエンドポイント数 × 操作数）を公開し、エージェントはその範囲内で動作します。この設計からは、次の 3 つの点が導かれます。

• スキーマは完全なダンプとして提供される。ソースネイティブの MCP に「何が利用できるか」をたずねると、リスト全体（すべてのオブジェクト、すべてのフィールド）が返ってきますが、サーバー側に検索を依頼する手段はありません。エージェントは、この膨大なメタデータをコンテキストに読み込み、手作業でスキャンします。

• エンティティ間の JOIN がない。ソースネイティブの MCP は単一のエンティティを中心に作られています。「商談」と「アカウント」と「明細」を関連付けるには、それぞれを個別に取得し、あるツールの結果から次のツールへ ID をコピーしながら、モデルの内部でつなぎ合わせるしかありません。

• 集計がクライアント側で行われる。プッシュダウンがないため、COUNT や GROUP BY を実行すると、ツールが行データを返し、LLM が計算を担うことになります。コンテキストウィンドウは、モデルが手作業で処理しなければならない生データで埋め尽くされます。

CData CLI は、この 3 つすべてを逆転させます。スキーマそのものがクエリの対象になるため、エージェントはダンプに溺れることなく、必要なわずかなものだけに絞り込めます。そして JOIN、WHERE、GROUP BY、集計は、すべて完全な SQL-92 です。

プッシュダウンは、絶対的ではなくインテリジェントに行われます。CData のクエリエンジンは、API が許す範囲でフィルタリングと集計をデータソースの API に委ねます。API はそれぞれ異なるため、常に 100% とはいきません。しかし、データソース側で処理できない部分は、CData Drivers がドライバー内で自ら処理し、LLM で処理されることは決してありません。いずれの場合も、モデルが受け取るのは生の行データではなく、答えそのものです。これは、API 呼び出しを単に中継し、データの削減をモデルに委ねるだけの一般的なネイティブ／サードパーティ製 MCP とは根本的に異なる結果です。コンテキストウィンドウに渡すデータを最小限に抑える真のプッシュダウンにおいて、CData は世に出回っているほとんどの MCP よりもはるかに優れています。

実証結果

意図的に最小限のケースを用意し、対照テストを実施しました。具体的には、Salesforce の Opportunities を Accounts および Product Line Items と結合し、特定の製品ラインにおける大型の新規ビジネス案件を抽出する、小さなアプリケーションです。すべてのエージェントに同じタスクを与え、変えたのはアクセスパターンだけです。

これほど小規模なケースでも、結果は次のとおりです。

• MCP スタイルのパターン（スキーマの完全ダンプ、結合なし、モデルのコンテキスト内でつなぎ合わせた単一テーブルクエリ）では、答えにたどり着くのに、SQL アプローチの2.2 倍のコンテキストトークンを要しました。

• モデルのコンテキストに取り込まれた情報の 96% は、否応なく読み込まされたスキーマダンプの行でした。クエリ可能なスキーマなら十数行で返せる数個のフィールド名を探すために、数千行ものメタデータが必要だったのです。

• 一方、CData CLI では、MCP 側で 4 つのクエリと手作業の ID コピーを要した処理がたった 1 つの SQL JOIN に置き換わりました。

データソースは同じ。質問も同じ。正解も同じです。リレーショナルな処理を LLM に押し込んだプロトコルは、トークン、レイテンシ、そしてもろさという代償を払いました。一方、それをドライバーに委ねたプロトコルは、その代償を払いませんでした。

しかも、これはまだ最低ラインに過ぎません。このテストで結合しているのは、わずか 3 つのオブジェクトです。エンティティが 1 つ増えるたび、フィルターが 1 つ増えるたび、集計が深くなるたびに、その差は広がっていきます。MCP エージェントにとっては、そのひとつひとつが手作業でつなぎ合わせるべき新たな JOIN であり、スキャンすべき新たなスキーマになるのに対し、CLI にとっては、ドライバーがプッシュダウンする SQL が増えるだけだからです。

アプリケーションが大きく複雑になるほど、汎用 MCP と CData CLI の差はさらに広がります。

2. セットアップの簡素化

MCP はクライアント・サーバー型のプロトコルであり、そのコストはデータソースが増えるごとに積み重なっていきます。

MCP 経由でデータソースを追加するには、通常、そのデータソース用の MCP サーバー（プロセスまたはコンテナ）を立ち上げ、認証情報とトランスポートを与え、クライアントの設定に登録し、稼働させ続ける必要があります。データソースが 10 個あれば、10 台のサーバーをデプロイし、セキュリティを確保し、ホスティングし、バージョン管理することになります。しかも、この仕組み全体は MCP 対応のクライアント内でしか動作しません。ホストアプリケーションへの強い依存があるのです。

CData CLI は、単一のバイナリです。

cdatacli drivers download --artifact-id      # add a source = download a driver
cdatacli drivers activate --name "" --email [email protected] --trial
cdatacli connection create --driver "" --name s --connectionstring "..."
cdatacli query sql --connection s --sql "SELECT ..."

1 つのツールで、CData ドライバーが対応する数百ものデータソースを網羅できます。データソースごとにサーバーをホストする必要も、ゲートウェイを運用する必要も、クライアントの設定を維持する必要もありません。データソースの追加は、ドライバーをダウンロードするだけです。そして、ただの CLI なので、エージェントの有無を問わず、あらゆるターミナルで実行できます。特別なクライアントも、プロトコルの配線作業も、スタックに加える新たな要素も必要ありません。

インストールするものが減り、守るものが減り、壊れるものも減ります。

3. 実行時の LLM は不要

これは企業が最も重視する点であり、MCP が逃れられない点でもあります。MCP は、ランタイムエージェントのためのプロトコルだからです。その存在意義は、まさに LLM が実行中にツールを呼び出せるようにすることにあります。データ連携を MCP の上に構築すれば、定義上、LLM は本番環境のリクエストパスに組み込まれます。それは、次のような事態を意味します。

• 呼び出しごとに発生する推論コスト。

• モデルの応答を待つレイテンシ。

• 再現可能であるべき処理に生じる非決定性。

• LLM を経由する顧客データ。

• セキュリティとコンプライアンスの審査対象となる、データプレーン上のモデルベンダー。

CData CLI は、設計時と実行時を明確に分離します。

AI エージェントが、ターミナル上での連携の構築を支援します。リリースするのは、ドライバーライブラリを呼び出すシンプルなコードだけです。実戦で鍛え抜かれた同じドライバーが、検証済みの同じ SQL を、毎回同じやり方で実行します。AI を活用して構築し、AI なしでリリースしましょう。

MCP が適切な選択となる場合

はっきりさせておくと、これは「MCP が悪い」という話ではありません。MCP が適切な選択となるのは、ランタイムそのものが AI アプリケーションである場合です。チャットボット、コパイロット、あるいは推論の過程で実際にリアルタイムのツールへアクセスする必要がある自律型エージェントなどです。そうした世界では、LLM がリクエストパスに含まれることが前提であり、MCP はまさにそのために作られています。

そして、MCP が必要な場合でも、同じ理屈が 1 段下のレベルで当てはまります。CData Connect AI は MCP サーバーを提供しており、生のデータソース API ベースの MCP サーバーには存在しない、クリーンなリレーショナルデータモデルとプッシュダウン実行エンジンを受け継いでいます。本記事で比較対象としている MCP サーバーは、たいていデータソースの API に直接組み付けられており、生の API が持つ制限をそのまま引き継いでいます。つまり、本当の意味でのスキーマ抽象化がなく、プッシュダウンもなく、結合や集計はエージェントが手作業で行うしかありません。プロトコルは同じでも、その土台ははるかに優れているのです。問われるのは、CLI か MCP かという選択だけではありません。本当に効いてくるのは、その下にどんな土台があるかです。そして CData の場合、CLI でも MCP でも、その土台となるドライバーライブラリが効いてきます。

要点は、もっと限定的で、もっと実用的です。ほとんどのエンタープライズおよび独立系ソフトウェアベンダー（ISV）の連携は、AI アプリケーションではありません。構築の段階では AI から多大な恩恵を受ける一方で、実行の段階では LLM からまったく恩恵を受けない、データ処理の仕事です。こうした一般的なケースでは、ターミナル上のクエリ可能な SQL インターフェースが、重要な点のどれをとってもツールサーバーを上回ります。

結論

AI をエンタープライズデータに接続するからといって、LLM を本番環境に投入したり、スキーマダンプに埋もれさせたり、JOIN を手作業でやらせたりする必要はありません。リレーショナルな処理はドライバーに任せ、モデルは設計時にとどめ、退屈なくらい堅実なものをリリースしましょう。

それを実現するのが、CData CLI です。

ターミナルで次の連携を構築しましょう

企業や ISV が手がける連携の多くは、AI アプリケーションではなく、データ処理の仕事です。構築する間は AI の恩恵を受けますが、実行する間は LLM から何の恩恵も受けません。CData CLI を使えば、モデルは設計時にとどまり、毎回同じように動作するクリーンなドライバーライブラリコードをリリースできます。新しいデータソースの追加は、ドライバーをダウンロードするだけの手軽さです。

CData CLI を試して、AI を活用して連携を構築し、それをプレーンなコードとして実行してみましょう。

※本記事は CData US ブログ CData CLI vs. Non-CData MCP Servers: Optimizing AI Data Integration, Token Efficiencies, and Performance の翻訳です。