こんにちは！コンテンツチームの加藤です。

営業チームがAIエージェントに「今四半期にクローズする案件を教えて」と尋ねたのになぜか全件がそのまま返ってくる――MCP(Model Context Protocol)サーバーを導入した企業から、こうした声を頂くことがあります。AIがやりがちな間違いで、しょうがないと思う方もいるかもしれません。しかしこうした問題を放置したままAI活用を進めれば、営業チームに誤った案件リストが渡り、経営層が誤った数字を基に意思決定していまう…といったことにもつながります。あるいは、担当者が「AIって間違いばかりで使えない」と思ってしまうことでAI活用がストップしてしまうかもしれません。

では、こうしたありがちな間違いを防ぐ方法はあるのでしょうか？実は、そのカギを握るのがAIとデータの「接続層」（セマンティックレイヤーまたはコンテキストレイヤー）です。本記事ではAIエージェントの回答精度がなぜモデルの性能ではなく接続層の設計で決まるのか、378の実運用プロンプトを使った検証結果を基に見ていきます。

意外な結論：精度の差はモデルではなく「接続層」にある

MCPサーバー自体の設計品質、つまりツールの数や粒度の最適化は確かに重要です。ツール設計のベストプラクティスに沿って構成を見直せば、コンテキストの消費量を抑え、AIエージェントの応答速度や安定性を改善できます。実際、APIエンドポイントをそのままツール化してツール数が膨張するとコンテキストを圧迫して精度が落ちるという問題は、既存のAPIをそのままMCP化する設計の落とし穴として知られています。

しかし、ツール構成が最適化されていても「今四半期」という表現を実際の日付範囲に変換するロジックや、業務システム固有のスキーマを理解する仕組みがなければ精度は頭打ちになります。つまり、ツール設計とセマンティックな正確性は別の課題であり、両方が揃って初めてAIエージェントは業務データへの安全かつ正確なアクセスを実現できると考えられます。今回CDataでは、この「接続層の設計」が回答精度にどれだけ影響するかを実際に検証してみました。

検証の概要：16種類のプロンプト × 5つのMCPサーバー × 4プラットフォーム

検証では、CRM・プロジェクト管理ツール・クラウドデータウェアハウス・ERPの4プラットフォームを対象に、各プラットフォームごとに4種類・合計16種類の標準化プロンプトを用意しました。これらを複数のMCPサーバーで繰り返し実行し、合計378回のテストを行っています。プロンプトはどれも実際に業務で使われそうなものです。比較したのは、①ベンダー公式MCP、②iPaaS、③ユニファイドAPI、④MCPゲートウェイ、⑤CData Connect AIという5種類の接続アプローチです。

結果の信頼性を担保するため、モデルはGPT-5、temperatureは0.2に固定し、エージェントフレームワークもLangGraph ReActで統一しました。評価は部分点なしの二値判定です。都合よく条件を選んだ検証ではないかという疑念を先回りで払拭するため、この統制条件は明記しておきたいポイントです。

結果：CData 98.5% vs 他アプローチ 59〜75%

全体の正答率は、CData Connect AIが98.5%だったのに対し、他の4アプローチは59〜75%にとどまりました。プラットフォーム別に見ると特にERPでの差が際立っており、CDataの100%に対し他アプローチは20%程度という結果でした。差にして約80ポイントです。他のプラットフォームでも同様の傾向が見られ、詳細な数値は以下の通りです。

1ステップあたりの精度が75%だとすると、5ステップを連鎖させるマルチステップのエージェントタスクでは、正答率は24%未満まで下がります。単発の質問応答では気づきにくいこの複利的な劣化は、エージェントが複数の操作を自律的にこなす時代だからこそ、見過ごせない論点です。

なぜ他社は失敗するのか：2つの典型的な失敗パターン

検証で確認された失敗には共通のパターンがありました。ここでは特に代表的な2つを具体例とともに紹介します。

日付ロジックの解決不足

「今四半期にクローズする案件を教えて」という自然なクエリに対し、多くのアプローチは「今四半期」を実際の日付範囲に変換できず、条件を無視して全件を返してしまいました。人間なら当たり前に理解できる相対的な時間表現も、変換ロジックがなければAIエージェントにとっては解決不能な条件になるのです。

スキーママッピングの誤り

「金額順トップ10の注文」を尋ねると、誤ったテーブルを参照して見当違いの結果を返すケースもありました。コネクタレベルでのスキーマ知識を持たず、学習データから推測して回答してしまうために起きる問題です。この2つ以外にも、書き込み時の状態遷移や複数条件のフィルタ組み合わせでの失敗パターンが確認されていますが、詳細はホワイトペーパーで解説しています。

CDataの解決策：セマンティックレイヤーとは何か

BIの世界では、セマンティックレイヤーは「売上」や「アクティブユーザー」といった指標の定義を全社で統一する層として語られてきました。しかし、AIエージェントがAPIを直接呼び出す世界ではこの層はもう一段実務的な役割を担います。つまり、モデルが送ってきたクエリを各プラットフォーム固有の意味に「翻訳」する層です。

セマンティックレイヤー（最近ではコンテキストレイヤーとも呼ばれます）とは、AIエージェントが送る自然言語のクエリを各プラットフォーム固有のスキーマ・状態遷移・日付ロジックに変換し、API呼び出しの精度を安定させる層です。Connect AIでは、この層が次の3要素を軸に、API呼び出しの前段階で意味を解決します。

• スキーマ知識：どのテーブル・フィールドが実際の質問に対応するかを、コネクタレベルで正しく把握する

• 状態遷移ルール：書き込み時にどの状態への変更が業務上許可されているかを理解する

• 日付・時間解決ロジック：「今四半期」のような相対的な表現を、実際の日付範囲に変換する

このレイヤーがAPI呼び出しの手前で意味を解決するため、精度がモデルそのものの性能に左右されにくくなるという点も重要です。今回の検証はGPT-5に統一して実施していますが、意味を解決するのがモデルではなく接続層である以上、モデルを入れ替えても「接続層の設計が精度を決める」という構図は変わりません。精度はモデルの性能ではなく接続層の設計に依存する——これが今回の検証で得られた結論です。

この考え方は、実際の導入事例でも裏付けられています。300社を超えるメーカーから商品マスタを受け取り、5,100万件超のデータを扱うこちらの事例では、CData MCP ServerとClaudeを組み合わせて商品の自動カテゴライズ化を実現しました。「REST APIの仕様差異によるハルシネーションリスクを回避」できたと評価されており、APIを直接呼び出すのではなく、スキーマを解決する層を挟むことの効果を裏づけています。

この検証結果は皆さんの環境でも再現できます。CDataはGitHub上でテストハーネスを公開しており、自社データ・自社プロンプトを使って同様の検証を実行できます。検証可能な形で精度を確認できるという点も、今回の取り組みで大切にしたポイントです。

まとめ：まずはホワイトペーパーで詳細を確認する

トップのAIモデルはどれも高い性能を発揮するようになっている現在、AIエージェントの回答精度はモデルの選択ではなく、セマンティックレイヤーを含む接続層の設計で決まると言っていいでしょう。プラットフォーム別の詳細データ、残り2つの失敗パターン、検証の全方法論についてはホワイトペーパーにまとめています。エグゼクティブサマリー(7ページ)と全文レポート(28ページ)の両方をご用意しており、GitHub公開のテストハーネスも参照いただけます。まずはサマリー版から目を通してみてはいかがでしょうか。

ホワイトペーパーのダウンロードはこちらから。また、CData Connect AI の14日間無料トライアルで業務データへのAI連携をご自身の環境でお試しいただけます。

よくある質問

Q. AIエージェントの回答精度は、モデルを変えれば改善しますか？

A. 今回の検証はGPT-5に統一して実施しており、モデル同士の比較を行ったわけではありません。ただし意味の解決を担うのはモデルではなく接続層（セマンティックレイヤー）であるため、精度差の主因は接続層の設計にあると考えられます。実際、同じGPT-5を使っても接続アプローチによって正答率は59〜98.5%まで開きました。マルチステップのタスクでは精度の低下が複利的に効いてくるため、モデルを変更するだけでは根本的な解決にはなりません。

Q. セマンティックレイヤーは、BIツールの指標定義と同じものですか？

A. 概念は近いものの、役割は異なります。AIエージェントの文脈では、スキーマ知識・状態遷移ルール・日付解決ロジックという3つの要素を解決する実務的な層として機能します。

Q. この検証結果は、自社データでも再現できますか？

A. はい。CDataが公開しているGitHubのテストハーネスを使えば、自社のデータやプロンプトで同様の検証を実行し、結果を確認できます。