データエージェント(人の代わりにデータベースや文書を調べて質問に答えるAI)がしばしば迷走する大きな理由の一つは、モデルの推論力不足ではない。本来扱うべきデータがエージェントの外側に散らばっていて、その構造も中身も事前には分からない、という点にある。論文はこのズレを agent–data gap、エージェントとデータのあいだの隔たりと呼ぶ。
EvoOntologyは、この隔たりを埋めようとする試みだ。人が手で書き置く静的なデータ辞書の代わりに、エージェントが仕事の途中で自ら問い合わせ、自分で直しながら育てていくオントロジー層(データの意味を書き留めた一種の案内地図)を置こう、というものである。結論から言えば、オントロジーなしで同じモデルを動かしたベースラインよりは確かに良くなった。ただし「セマンティックレイヤーのベースラインを一貫して上回る」というアブストラクトの表現は実験表と少し食い違っており、その点は後ほど表を一緒に見ていく。
現実のデータはエージェントの外側に散らばっている。リレーショナルDBから半構造化文書、非構造化ファイルまで、形もまちまちだ。エージェントはSQLインターフェースやファイルリーダーのような汎用ツール越しに、ようやくこのデータへ触れるにすぎない。問題は、これらデータの構造も中身も事前には分かっていないという点だ。だからエージェントはプローブクエリ(データの一部を突いて試す試験用クエリ)を何度も投げ、目当ての概念がどこにありそうかを推測し、無関係な内容をめくりながら手探りの探索をする。
エージェントがこうして手探りの探索に陥るagent–data gapを解くための既存アプローチは、大きく二つある。
一つは raw querying、エージェントがスキーマ(データ構造の設計図)を直接読み、探索クエリを投げる方式だ。小さく単純なデータにはよく効くが、広く異質なデータでは非効率な探索に閉じ込められやすい。
もう一つは セマンティックレイヤー(semantic layer)、スキーマ・エンティティ・指標といったドメインの意味情報を前もって作り、エージェントに丸ごと手渡す方式だ。しかしデータが大きいと、この説明全体をプロンプトに入れることが長さの制約上できない。しかも多くは人が手作業で管理するため、作るのも高コストで、更新するのも難しい。
論文はここで、「静的な説明」を超え、エージェントがツールで柔軟にアクセスする対話型のオントロジー層が必要だと見る。
新しいアナリストが着任したが、資料は部署ごとにキャビネット・エクセル・DBとバラバラに散らばっている、としよう。静的なセマンティックレイヤーは、誰かが昔書き置いた分厚い社内ハンドブックに似ている。丸ごと読むには長すぎ、すでに古く、このアナリストが実際にどう働くかは知らない。
EvoOntologyは、ハンドブックの代わりに「質問を受ける資料室の案内窓口」を置く側だ。必要なときに尋ねれば関連するカードだけを取り出してくれ、そのカード自体を実際に引き出しを開けて確認しながら作り、アナリストたちがどこで詰まるかを見守って直し育てていく。
では、この「案内窓口」は具体的にどう設計されたのか。論文はこれを三つの層に分けて実装する。
この三つの層を一つのMCPサーバー(モデルが外部ツールを呼んで使う標準の接続方式)で包んだのが核心だ。エージェントがメタデータを受け身で食べさせられるのではなく、能動的に尋ねて取り出して使うようにしたのである。
「顧客データから先月の売上を抜き出せ」という仕事を任されたエージェントを思い浮かべてみよう。
最初の段階は「初期の地図づくり」だ。 ビルダーエージェントは正解付きではなく、学習用の作業集合(training workload)と元データだけを見て、よく出てくる概念 — 「売上」「顧客」「期間」といったもの — を候補として絞り込む。そのうえで自らプローブクエリを投げ、「売上が本当にこのテーブルのこのカラムにあるか」「値や型が筋の通ったものか」を一つずつ確認する、一種の実査作業を経る。プローブが裏づける候補だけをカードとして残し、その根拠となった実レコードを証拠として添える。当て推量ではなく、確認されたものだけを地図に載せるのだ。
二つ目の段階は「地図の描き直し」だ。 進化エージェントは、エージェントが実際に働いたログ(トラジェクトリ)を証拠に地図を手直しする。うまくいったログはどのカードと経路が通用したかを教え、詰まったログは何が欠けていたか、あるいは紛らわしく書かれていたかを浮かび上がらせる。たとえば「売上」カードに返金処理のルールが抜けていてエージェントが繰り返し間違えたなら、そのパターンを抽出して当該カードを直す。
このとき重要な設計原則が一つある。修正は一度に一層だけ触る。 内容・ツール・スキーマのうちどこを直すかを決め、一箇所だけ変える。これは変化の原因をはっきり追跡し、一箇所を直したせいでとんでもないところで副作用が噴き出すのを防ぐための安全装置だ。
直した結果が本当に良くなったかは、ひとえに測定で判定する。バックボーン(エージェントの頭脳となるLLM)ごとに、修正案と修正前の状態を同じ検証セット・同じ条件でぶつけ合い、あらかじめ定めた差以上に良くなったときだけ採択する。落ちれば捨て、捨てたログも記録に残し、同じ無駄骨を繰り返さない。バックボーンごとに独立して育つため、採択された修正はそのバックボーンの癖を反映する。
本題に入る前に、用語を二つだけほぐしておこう。この論文のすべての実験は、同じ 推論構造(ReAct、モデルが「考えて → ツールを使い → 結果を見て」再び考える、を交互に繰り返す方式)と同じ 計算量の上限(デコーディング・インタラクション予算) のもとで行われる。比較対象どうしの条件を厳密に統制したという意味だ。そうしてはじめて、スコア差が「オントロジーを付けて生じた差」だと言える。
評価は三つのベンチマークで行われた。性格だけ押さえるとこうだ。
肝心なのはこれだ。アブストラクトは、EvoOntologyが強いベースラインとセマンティックレイヤーのベースライン(Baseline + SL)を「一貫して、かつ相当に上回る」と記した。ところが表を見ると、いつもそうとは限らない。InsightBenchでは、二つのモデルでEvoOntologyとBaseline + SL(セマンティックレイヤー)が すべての指標で同じだった。
| InsightBench (Overall) | EvoOntology | Baseline + SL |
|---|---|---|
| GPT-5.5 | 51.0 | 51.0 |
| Claude-Opus-4.8 | 53.2 | 53.2 |
この条件では圧倒ではなく、同率だ。したがって結果を総合すると、こう規定したほうが正確だ。オントロジーを付けていない同じバックボーンよりは確かに優れるが、ビルダーエージェントが生成したセマンティックレイヤーを静的プロンプトで入れた条件(Baseline + SL)とは、状況によって引き分ける「条件付きの優位」である。 一つ付け加えるべき注意。ベンチマークごとにスコア体系が異なる(精度・インサイトスコア・EX/VES)ため、別々の実験の数字を一つにまとめて読んではいけない。
実験設定についての注。 ここでのBaseline + SLは、人が構築した既存のセマンティックレイヤーではなく、ビルダーエージェントが生成したセマンティックレイヤーを静的プロンプトとして注入した条件である。したがってこの同率を「人が高コストで作った既存セマンティックレイヤー全般に対する優位/劣位」へと広げて読むと、比較の範囲を歪めてしまう。BIRDは公式のOracle Knowledge設定(質問に必要な背景知識を一緒に与える公式モード)で実行精度(EX)を主指標、有効効率スコア(VES)を補助指標として用いる。バックボーンはアブストラクトでは四つとされているが、実験設定には六つが記されている(GPT-5.5, GPT-5.6-sol, Claude-Sonnet-5, Claude-Opus-4.8, DeepSeek-V4-Flash, Qwen3.5-Flash)。上表の数値は、論文のInsightBench表から直接確認できる同率値のみを引用した。
同率が出るという事実そのものが問いを投げかける。この進化の仕掛けが実際に元を取るのは、正確にどこなのか。論文の論理どおりなら、データが広く異質なほど利得が大きくなるはずだが、その境界は表だけでは判然としない。
さらに、初期化・進化・検証はどれもタダではない — 追加の計算がかかる(付録でオントロジー層のコストを別途扱う)。バックボーンごとに別々に育つので、修正はそのバックボーンに合わせられる。論文は、あるバックボーンで育てたオントロジーを別のバックボーンへ移して使ってみたが(図5b)、移すこと自体はできるものの性能はやや落ちた。つまりバックボーンごとに育てるほうが有利だという意味であって、「モデルを変えたら必ず一から育て直さねばならない」が証明されたわけではない。
また、ビルダーは学習用の作業集合(training workload)と元データから初期化し、進化エージェントは過去のトラジェクトリを入力に地図を手直しする。公開実装では、質問や実行トラジェクトリのファイルは必須ではなく任意の入力として説明されており、実行履歴があらかじめ積み上がっていることが前提ではない。評価も特定のシナリオ(例: DDRの10-K)にまたがっており、一般化の可否は開かれた問いだ。
これは私たちONTLEが毎日現場でぶつかっている問題でもあります。私たちは顧客プロジェクトごとにデータを隔離して扱い、顧客企業のERP・ショッピングモール・社内エクセルといった外部システムをその都度つないで使います。新しい顧客を受けるたびに「この会社の『売上』はどのテーブルのどのカラムにあり、返金はどう差し引かれるのか」を人が改めて聞き回る作業が繰り返されます。この論文が言うagent–data gapが、まさにその場面です。
惹かれる点は二つだ。一つは 根拠ベースの初期化 — 人が顧客ごとにデータ辞書を手で書く代わりに、実データを突いて確認し、その証拠とともに作る方式だ。もう一つは トラジェクトリベースの進化 — 使えば使うほど、その顧客データへの理解が作業ログから自ずと良くなっていく絵だ。とりわけ「測定で良くなったときだけ修正を採択し、捨てたものも記録に残す」というゲートは注目に値する。エージェントが自らの知識を誰にも知られぬまま書き換えてしまう事態を防いでくれるからだ。
ただし、そのまま取り込む前にコストと効用を天秤にかけねばならない。データが小さく単純な顧客なら、よく整理したデータ辞書一枚で十分なこともある。進化の仕掛けが元を取るのは広く異質なスタックのときと見えるが、先に見たとおりその境界はまだ判然としない。作業に応じて複数のモデルを使い分けるプロダクトなら、オントロジーをバックボーン間で移すときの性能損失と、バックボーンごとに育てるときの利点とのあいだのトレードオフも、実戦では併せて検討する必要がある。結論を急ぐより、データが広い一つ二つの箇所で、まず根拠ベースの初期化だけを先に試してみるほうが現実的だ。