AIの世界には、なかなか興味深い現象が存在する。
一方で、テクノロジー企業は巨大な言語モデルに「手」や「足」を付け、人間の代わりに様々なソフトウェアを操作させようと躍起になっている。しかしその一方で、真にAIを必要とする企業顧客は首をかしげているのだ。
ミュンヘン工科大学、ダルムシュタット工科大学、マサチューセッツ工科大学などの研究者グループが、最新の論文でこの現実を白日のもとに晒した。
企業におけるAI導入の問題は、モデルが賢くないことではなく、データが乱雑すぎることにあるのだ。
最先端の大規模言語モデル（LLM）エージェントが、模擬的な企業環境で悪戦苦闘し、正答率が0%にまで落ち込む中、RUBICONという名の新しいアーキテクチャが、シンプルで明快なクエリ言語を用いることで、その正答率を100%にまで引き上げた。しかも、より小型で安価なモデルを使用している。
企業データは、それぞれに独立したシステムに散在している。今日のエージェントAIは、LLMを頭脳としてすべてを理解し、操作させようとするが、その結果は混乱、高コスト、そして信頼性の欠如だ。
RUBICONは全く別の道を選んだ。操作権をユーザーに委ね、ユーザーがAQLと呼ばれるミニマルなクエリ言語を通じて、どのデータソースから何を探すべきかをシステムに明確に指示する。LLMは、正確に区切られた範囲内での作業のみを担当するのだ。
中間のステップはすべて透過的に表示され、ユーザーはいつでも介入できる。この手法は、構造化された確実性をもって、エンドツーエンドの推論が持つ確率論的な不確かさを置き換えている。
賢い頭脳は、乱雑なデータには敵わない
過去数年間、LLMをエージェント化することが主流の考え方だった。
多くの人は、LLMの推論能力が高いため、LLMを総指揮官とし、いつ、どのデータベースを検索し、どのツールを呼び出すかを自ら決定させ、最終的に回答を生成させるべきだと考えた。
このLLM中心のアーキテクチャは、一見すると素晴らしいものに思える。
しかし、現実世界の企業は、実験室にあるようなクリーンなテストセットではない。
論文は容赦なく指摘する。企業がAIで直面する困難は、そのほとんどが推論能力の不足ではなく、データ統合の問題である、と。
重要な情報は、データベース、文書システム、メールサービス、外部ウェブサイトといった全く異なるシステムに分散している。
各システムは、独自のクエリ言語、データ構造、アクセス権限を持っている。
これらのシステムは、厳格なアーキテクチャと極めて高いパフォーマンスが要求されるデータの要塞であり、一方LLMは言葉遊びの確率論的な達人だ。後者に前者を管理させるのはまるで、詩人に空母打撃群の指揮を任せるようなものである。
なぜ今日流行しているText-to-SQLは企業で機能しないのだろうか？
論文は、四つの致命的な違いを指摘している。
公開されている学術的なテストセットはデータ量が少なく、LLMにとってはごくわずかな資料に過ぎない。
しかし、企業のデータウェアハウスは膨大な量のデータを格納しており、桁が全く違う。
学術的なテストセットはクリーンな単一スキーマを追求するが、企業ではアクセスを高速化するために、冗長なビューやマテリアライズド・ビューがあちこちに存在し、同じ問題に対しても無数の検索方法がある。LLMはそれを見ただけで混乱してしまう。
企業データは内部の隠語で満ちている。ある略称が複雑なプロジェクトを表し、あるコードの背後には一連のビジネスプロセス全体が隠されている。これらをLLMの推測に頼るのは、全く現実的ではない。
実際のビジネスクエリも、テストセットよりはるかに複雑だ。
これらの違いが重なると、論文が観測したところによれば、実際の企業データウェアハウスにおけるLLMの精度は、ベンチマークテストと比較して50%以上も崖から転がり落ちるように低下する。これは、使えるレベルから、使い物にならないレベルへの転落を直接的に意味する。
何を、どこから調べるか、あなたが決める
この方法が通じないならば、RUBICONの解決策は極めて素朴だ。
もはや、機械にすべてを理解させようと躍起になるのはやめ、ハンドルを人間のドライバーに返却したのだ。
そのアーキテクチャの中核となるのは、AQL（Agentic Query Language、エージェントクエリ言語）と呼ばれるクエリ代数である。
この言語は極めてシンプルで、わずか三つの核心的命令しか持たない。FIND（何を探すか）、FROM（どこから探すか）、WHERE（条件は何か）である。
条件部分は自然言語で記述するが、それ以外の部分はユーザーが明示的に指定する。
具体例を挙げよう。あなたが、大学の中で、どの研究室の教授がチューリング賞かノーベル賞を受賞したことがあるかを知りたいとしよう。RUBICONにとって、考えられるAQL命令はこのようになる。
お分かりいただけるだろうか。ユーザーは、Wikipediaと大学のデータウェアハウスという二つの具体的なソースからデータを取得し、フィールドを指定することを、明確に伝えなければならない。
LLMの仕事は、極めて狭い範囲に圧縮されている。WHEREに続く自然言語の条件を理解し、それを各データソースが実行可能な命令に翻訳することだけを担当する。
どこにデータを探しに行くかを推測する必要はなく、どうやってデータを関連付けるかに頭を悩ませる必要もない。この翻訳作業は、異なるデータソースを接続するラッパー（Wrapper）が実行する。
各ラッパーは、一つのデータソース（それがたとえメールシステムやビデオライブラリであっても）を、標準的なリレーショナルテーブルビューに変換する役割を担う。
これにより、すべてのデータが、あたかもデータベースの行と列であるかのように見え、後続の操作が極めて明確になる。
この設計は、LLMによる不透明な連鎖的な呼び出し方を、明示的で検証可能なリレーショナル操作のパイプラインへと直接的に変換する。
RUBICONには二つの実行モードがある。
インタラクティブモードでは、ユーザーはAQL命令を一つ実行した後、スプレッドシートのような可視化された中間結果を得る。
ユーザーはそこで一旦立ち止まって結果を検査し、もし間違いを発見したらすぐに修正し、その結果を保存して次の命令に送ることができる。各ステップは確実で、追跡可能であり、再現可能だ。
もしタスクを繰り返したいのであれば、コンパイルモードが命令シーケンス全体をパッケージ化し、従来のデータベースのクエリプランのように、オプティマイザに最も効率的な実行パスを見つけさせる。そのコストは、LLMを何度も呼び出すよりもはるかに低い。
0% 対 100%
口で言うだけでは信憑性がないため、研究チームはRUBICONと現在のエージェントAIソリューションを比較する、興味深いミニマッチを企画した。
彼らは、典型的な企業の情報が乱雑に存在する環境をシミュレートした。そこには、Wikipedia、97のテーブルを持つ匿名化された大学のデータウェアハウス、大学の研究室のウェブサイト、Gmailのメールシステム、そしてLLM自身の事前学習知識ベースが含まれる。
彼らは7つの質問を注意深く設計した。各質問は、正確に2つのデータソースのみをまたいで初めて回答できるように作られており、他の3つのソースはすべて、かく乱要因である。
表1：7つのベンチマーククエリにおける、実際のデータソースの関連性。緑色は必須のデータソース（R）、黄色は任意のデータソース（O）、灰色は無関係なデータソース（-）を示す。
モデルは、OpenAIのGPT-5-mini、GoogleのGemini-3-flash-preview、そしてAnthropicのClaude-Sonnet-4.6だ。
彼らは二つのスタイルでこの挑戦に臨んだ。一つは、何のツールも持たない通常のチャットモード（Vanilla LLM）。もう一つは、データソースへの全アクセス権を装備し、現在最も流行しているReAct（推論-行動）ループを採用したLangChainエージェントである。
結果は、驚くべき完全なる勝利だった。
Vanilla LLMとLangChainエージェントのすべての設定において、正答率はすべて0%だった。一つも正解がなかったのだ。
失敗の原因は、モデルがでたらめを言ったからではなく、システム的な協調の失敗にあった。
モデルは、必要なソースのいずれかを調べるのを忘れたり、途中で調べるのをやめてしまったり、異なるソースからの結果を正しく関連付けることができなかったのだ。
先ほどの教授の受賞に関する質問を例に取ると、LangChainエージェントはしばしば、Wikipediaで受賞者リストを取得しただけで満足し、データウェアハウスでそれらの人物が本当にその大学の教授かどうかを確認するのを怠り、最終的に無関係な人物をリストアップしてしまった。
ツールを与えられたのに、モデル自身がその手を制御できなかったのだ。論文では、モデルにより大きな自律性と強力な推論設定を与えると、得られるものは、より広範な失敗パターンとより高いコストである、と表現されている。
一方、RUBICONの正答率は100%だった。これら7つの問題は、RUBICONにとっては、決められた手順通りにAQL命令を組み合わせるだけのことであり、調べ漏れや結合忘れが発生する可能性は全くなかった。
手足を縛ることで、かえってコスト削減に
効率性における対比も、同様に残酷だ。以下の表3にまとめられたコストと遅延のデータを見てほしい。
表3：全クエリの平均効率指標の概要。k̄ はクエリごとの平均ツール呼び出し回数（Vanillaモードでは0）。
Vanillaモードは非常に静かで、ツールを一切呼び出さず、入力トークン数も80未満であり、コストは極めて低い。
しかし、ひとたびReActエージェントになると、状況はすぐに制御不能に陥る。それらは、哀れな0%という正答率のために、狂ったような試行錯誤を開始するのだ。
GPTエージェントのクエリあたりの平均入力トークン数は、20,000から46,000にまで跳ね上がった。
Geminiエージェントはさらに誇張されており、自然言語モードでは27万トークン以上、AQLモードでは47万トークン近くにまで入力が膨れ上がり、ツール呼び出しは平均22.71回にも及んだ。1クエリあたりの金銭的コストは0.28ドルで、初回応答時間は4分以上も待たされる。
Claudeの状況もよく似ており、高額なトークン単位の課金体系と広範囲な探索が組み合わさり、1クエリに0.5ドル以上かかることもあった。
これらのモデルは、より多くの推論、より長いコンテキスト、より頻繁なツール呼び出しを用いて、揺るぎない0点という結果を積み重ねていたのだ。
RUBICONが使用したGPT-5-miniのコストは、極めて低い水準で安定しており、クエリごとにちょうど2回のツール呼び出しが実行された（これは必須の2つのデータソースに対応する）。迷走したり、余計なことを考えたりはしない。
RUBICONは、データをどこに探しに行くかというような重要な決定権をユーザーに返す。これにより、結果の正確性が保証されるだけでなく、エージェントAIが自ら対処するのが困難な大きな問題、すなわち「クエリプランの選択」を自然に回避している。
論文は、同じ教授の受賞に関する問題を例に挙げている。
ユーザーが目的を達成するためには、二通りの異なるAQL命令を書くことができる。
プランAは「まず受賞者を探し、次に人物を探す」。すなわち、まずWikipediaから全チューリング賞およびノーベル賞受賞者を見つけ出し（このリストは長くない）、その後、大学のデータウェアハウスで、それらの人物のうち誰が教授かどうかを照合する。
プランBは「まず人物を探し、次に受賞歴を探す」。すなわち、まず全教授のリストを引き出し（これは非常に多くなる可能性がある）、その後、一人ひとりの教授についてWikipediaのページを検索し、受賞歴があるかどうかを調べる。
これら二つのプランは、論理的にはどちらも正しいが、コストには天と地ほどの差がある。プランBでは、教授の人数分だけWikipediaの検索操作が実行されることになり、オーバーヘッドが教授の数に比例して増加する。一方プランAは、選択性の高いフィルタ条件を利用することで、後続の検索回数を大幅に削減している。
エージェントAIにおいて、これはそのまま、ツール呼び出し回数、トークン消費量、待ち時間の増減に直結する。
LLMが自らどちらの道を選ぶかには非常に強いランダム性があり、選択を誤れば、コストは爆発し、速度は受け入れがたいほど遅くなる。
RUBICONはこの選択権をユーザーに委ねるか、あるいは従来型のコストベースのクエリオプティマイザを使って、最も効率的な経路を自動的に選び出すこともできる。これらはすべて、現在のLLMエージェントには到底不可能なことだ。
研究の最後に、300以上の企業AIプロジェクトを追跡したMITの報告書が引用されている。その報告書によれば、カスタムAIプロジェクトのうち、定量化可能な投資収益率（ROI）を得られたものは5%未満だったという。
モデルはますます強力になり、自律性の幅は広がり続けているが、幻覚（ハルシネーション）や見落としによって引き起こされる失敗のパターンには、本質的な変化はない。
研究者たちは、この熱狂の渦中に、古来より伝わるソフトウェア工学の知恵を贈る。
まずデータを整理し、インターフェースを適切に管理せよ。そうしてから、知能の話を始めよう。この一見「不器用」に見えるアーキテクチャこそが、むしろ、企業が真に必要とするAIに近いのである。
参考文献：