データレイヤーが安全に正解まで導いてくれるなら、そのデータを使うのは本当にフロンティアモデルである必要があるのでしょうか。もっと安いモデルでも、同じ仕事をこなせるのではないでしょうか。

AIエージェントに社内データを任せるかどうかを検討する際には、コストより先に「回答の正確性はどうか」「安全に任せられるのか」を問われることが多いはずです。そこで今回は、22モデル・1,034回の試行で正解率とコストに加えて書き込みの安全性まで実測しました。対象はCRM（顧客管理システム）・クラウドDWH（データウェアハウス）・ITSM（ITサービス管理）の実データです。業務ロジックをデータレイヤーに移すと、複合条件の読み取りタスクで22モデル中17モデルがまったく同じ正解にたどり着きました。

この17モデルの正解1件あたりのコストは$0.00088〜$0.15712で、同じ結果に対して178倍の開きがありました。

このコスト差がどこから生まれ、正解率がどこで決まっているのかを、順に見ていきましょう。

検証手法の詳細と全実行データは、技術レポート（英語）で公開しています。

公開ベンチマークのスコアは実務でも通用する？

そのまま通用するとは限りません。公開ベンチマークは答えのわかっているきれいなプロンプトで採点するもので、モデルが初めて見る社内のスキーマや、モデル自身が推測するしかない業務ロジックは測っていないからです。

AIエージェントの研究でも、精度だけを追って調整したエージェントは、同程度の性能を持つコスト重視の構成より4.4〜10.8倍のコストがかかると報告されています。公開ベンチマークの順位表（リーダーボード）では、この差は見えてきません。順位表のスコアが高いことは、自社のデータで実証できたことの代わりにはならないのです。トークンそのものの使用量を絞り込む観点からの検証は、Claudeのトークン使用量を最大97.6%削減したMCPアーキテクチャで詳しく扱っています。

今回のベンチマークで測ったのは、データレイヤーが業務ロジックを肩代わりしたときに、フロンティアモデルの割高な料金のうちどれだけが意味を持ち続けるのかです。測定にはベンチマークではなく実データを使いました。

検証はどう設計した？

同じCData Connect AIの接続経路を2つのモードで使い分け、3つのタスクを実行しました。プロンプトは両モードでそろえ、変えたのはモデルが呼び出す経路だけです。

題材は、複数のシステムにまたがるアカウント健全性のトリアージです。アカウント情報はCRMに、利用状況のテレメトリはクラウドDWHに、サポートインシデントはITSMにあります。3つともConnect AI経由でリアルタイムに接続し、データのコピーや事前の加工は一切していません。

各タスクの正解セット（golden answer set）は、モデルを動かす前にオフラインで確定させています。

読み取りタスクはSet F1で採点しました。集合として正しい行を返せたかを、適合率と再現率の調和平均で見る指標で、多く返しすぎても少なすぎても同じだけ減点されます。書き込みタスクは、対象テーブルの最終状態で採点しています。確認にはモデルのツールではなく、検証環境（ハーネス）自身の認証情報 (クレデンシャル) を使いました。

baseline（素のアクセス）では、モデルは3つのデータソースに対してスキーマを問わない探索的なクエリを自由に発行できます。スキーマ全体が見え、データソースをまたぐSQLも書けますが、手前に整えられたツールはありません。健全性スコアの計算式やレビュー対象の条件といった業務ロジックは、すべてモデル自身が導く必要があります。

optimized（最適化）では、同じ業務ロジックがモデルではなくデータレイヤーに置かれています。健全性スコアの計算式・対象条件・スコープに入るアカウントと操作を、次の4つのConnect AIの機能が受け持ちました。

読み取りタスクで正解率とコストはどう変わった？

業務ロジックをデータレイヤーに持たせると、正解率はモデルの規模によらずほぼ横並びになりました。一方で、同じ正解を出すためのコストはR2で178倍、R1で約501倍の開きがあります。

まずbaselineです。複合条件の読み取り（R2）でSet F1が0.45を超えたモデルはなく、22モデル中18モデルは0.00でした。

しかも、これはレビュー担当者が見れば気づくような「惜しい間違い」ではありません。見た目は整然としていて自信満々に見えるのに、中身は間違っているアカウント一覧です。複合条件のロジックを取り違えたことを示す手がかりは、出力のどこにもありませんでした。間違いに見えない間違いは、ガバナンスの観点で最も扱いにくい種類の誤りではないでしょうか。

Custom Tools経由に切り替えると、22モデル中17モデルがR2でSet F1 1.00に到達し、さらに2モデルが0.97以上を記録しました。エコノミー層のモデルがフロンティア層に並び、Set F1はモデルの規模と連動しなくなっています。同じ設計思想の効果は別の検証でも裏付けられており、MCPサーバーの設計差でAI精度が98.5%と59%に分かれた実証比較でも、精度を決めるのはモデルではなくサーバー側のセマンティックレイヤーだと報告されています。

図1. R2のモデル別Set F1。素の探索的アクセスとCustom Toolsの比較。どの層のモデルも、ほぼ0からほぼ満点まで引き上げられています。

横並びにならなかったのは、正解1件あたりのコストです。

表1. optimized条件でのR2の正解率と正解1件あたりのコスト（コスト順）。Set F1の列はほぼ一定ですが、コストの列は178倍に広がっています。

図2. optimized条件でのR2の正解1件あたりのコスト（対数目盛）。表示したモデルはすべて同じ44件のアカウントを返しているため、この軸は純粋に価格の差を表しています。

別の読み取りタスクであるR1でも、同じ傾向が再現しました。Set F1は高い水準にまとまる一方、正解1件あたりのコストは$0.000873〜$0.437169と約501倍に広がっています。R1でSet F1 1.00に届いたのは6モデルで、その中で最も安いQwen 3.7 Maxは$0.031、最も高いOpus 4.8は$0.437でした。同じ正解率を、ごく一部の費用で得られたことになります。

書き込みタスクで安全だったモデルは？

素のテーブルアクセスでは、全実行を通して安全だったモデルは22モデル中1つもありませんでした。無許可の書き込みを全モデルで0件に抑えられたのは、Custom Toolの中でサーバーサイドの検証を行った場合だけです。

書き込みは読み取りより重い意味を持ちます。間違った読み取り結果は捨てれば済みますが、間違った書き込みはデータに残り続けるからです。

素のテーブルアクセスでは、14モデルが少なくとも1回は安全でない実行をしました。最悪の1回では、21行だけが書き込まれるはずのテーブルに、無許可の行が628行挿入されています。違反したモデルにはフロンティア層も多く含まれ、Opus 4.8とSonnet 5はいずれも中央値で185行の無許可の行を書き込みました。

素のアクセスは、費用のかかる経路でもありました。baselineの書き込みは1回で最大$6.90かかり、タスクを正しく完了したガード付きの実行の20倍を超えています。

図3. A1の条件別の無許可書き込み行数。素のアクセスで数百行を書き込んだモデルも含め、ガード付きの実行ではすべてのモデルが0行にとどまっています。

スコープを絞るだけでは足りませんでした。モデルが触れるテーブルと列だけを制限し、書き込む中身を検証しないツールでは、全実行でクリーンだったのは22モデル中15モデルです。残りのモデルは、ツールのスコープ内ではあってもタスクの意図から外れた書き込みをするか、書き込みが足りずに対象のアカウントを積み残しました。

決め手になったのは、サーバーサイドの検証です。対象条件をCustom Toolの中で強制すると、無許可の行は検証したすべてのモデルで0件になりました。1回あたりのコストは$0.001〜$0.32です。こうした書き込み保護をエージェントの構成に落とし込む具体的な設計は、Production-readyなAIエージェントのリファレンスアーキテクチャで解説しています。

今回のデータを見る限り、安全性を分けたのは呼び出すモデルではなく、データレイヤーの設計です。

タスクを通して一貫していたことは？

1つの読み取りや1つの書き込みに限らず、検証したすべての種類のタスクで次の3つの結果が成り立ちました。

• ガード付きの書き込みは、検証したすべてのモデルで無許可の行が0件でした。図3がそれを示しています。

• 業務ロジックをデータレイヤーに移した時点で、Set F1は高い水準に狭くまとまりました。2つの読み取りタスクのどちらでも、モデルの規模・層・提供元に関係なく成り立っています。

• フロンティア層であることは、安全性の目安になりませんでした。Opus 4.8とSonnet 5は、素のアクセスでのすべての試行で安全でない実行をしており、その割合は100%です。同じ条件のほかのモデルには、エコノミー層を含めて、ピーク時にさらに多くの無許可の行を書き込んだものもありました。

「高いモデルなら安全だろう」という前提でセキュリティ審査を通そうとしているなら、3つ目の結果は見直しのきっかけになるはずです。

AI予算の考え方はどう変わる？

変わるのは3点です。モデル選定は価格の判断になり、ガバナンスはツールキットの設計そのものに組み込まれ、探索と本番は同じデータレイヤーで扱えるようになります。

モデル選定は、価格の判断になります。Derived ViewsとCustom ToolsでSet F1がそろえば、精度の基準を満たす最も安いモデルが正しい選択です。価格は数週間ごとに動くので、最適なモデルも入れ替わるでしょう。

ただ、判断の形は変わりません。業務ロジックに手を入れずに、何度でも選び直せます。

ガバナンスは、事前のレビュー工程からツールキットの設計そのものに組み込まれます。すべてのモデルの無許可の書き込みを0件に抑えた検証は、導入前に回すチェックリストではありませんでした。Custom Toolのロジックとして、Toolkitそのものに組み込まれていたのです。

この検証は呼び出したすべてのモデルに効き、ルールを書いた時点ではまだ存在しなかったモデルにも効きました。社内審査で「どのモデルを使うのか」を問われたとき、答えをモデルではなくデータレイヤーの設計に置けるということです。Custom Toolsの検証ロジックを組む初期コストは一度で済み、そのあとモデルを切り替えるコストはほぼゼロになります。こうしたガバナンスをどこまで制度化すべきかは、エンタープライズMCPガバナンス完全ガイドも参考になります。

探索と本番は、1つのデータレイヤーで扱えるようになります。探索は、新しい問いに答えられるかどうかを確かめる場です。Custom Toolは、確かめた答えを本番でも無理なく使い回すための場です。この2つの間を移すときも、新しく連携を組み直す必要はなく、ツールの定義を1つ用意するだけで済みます。

結果を踏まえてモデルはどう選ぶ？

今回の結果から導ける選び方は、次の4つに整理できます。

モデル選定チェックリスト

• ガバナンス済みのツール上で、精度の基準を満たす最も安い層から始めます。上の層に移るのは、その層で失敗したときだけにします。

• ツールの中でサーバーサイドの検証を行わない限り、書き込み権限は与えません。モデルが届くテーブルと列を絞るだけでは足りません。

• 価格は定期的に見直します。Set F1がそろった後の「正解できる最安モデル」は、一度決めて終わりではなく動き続ける目標です。

• 能力より先に、ツール呼び出しの互換性を確かめます。Model Context Protocol (MCP) を安定して扱えないモデルは、ほかの評価がどれだけ高くてもタスクに失敗します。

よくある質問

安全性を先に固めてからモデルを選ぶ

CData Connect AIは、数百の業務システムへのリアルタイムなアクセスをガバナンスを効かせたまま提供し、上にどのモデルを載せても同じ定義と同じガードレールを通します。業務ロジックはDerived Viewsに、書き込みの検証はCustom Toolsに持たせられるため、モデルを乗り換えるたびにルールを作り直す必要はありません。

パススルー権限によるアイデンティティファーストのセキュリティを備えているので、セキュリティ審査で問われる「AIがどこまで触れるのか」にも、データレイヤーの設定として答えられます。専門商社の導入事例では、MCP経由でデータレイヤーをSQLとして抽象化することで、LLMのハルシネーションリスクを避けながら大量データの自動分類を実現しています。残る判断は、どのモデルが一番安く正解できるかだけです。

Connect AIの無料トライアルで手元のデータソースから試すか、技術レポート（英語）で全モデルの結果と検証手法を確認してみてください。

関連する実測データ

• Claudeのトークン使用量を最大97.6%削減したMCPアーキテクチャ

• MCPサーバーの設計差でAI精度が98.5%と59%に分かれた実証比較

• kintone環境でのMCP比較検証