AIエージェントが試験をあまりに速く解いてしまう。上位モデルがそろって90点台後半を叩き出すと、その試験はもう順位をつけられない。誰が優れているのか、どこでつまずくのか、何も見えてこない。
ここで言うエージェントとは、質問にそのまま答えるチャットボットではなく、データを掘り起こしツールを自分で動かしながら、自力で仕事をやり遂げるAIのことだ。そしてベンチマークは、その実力を測る共通の試験紙である。問題は、その試験紙が固定されていることだ。モデルは四半期ごとに良くなるのに、人が手作業で問題を作り出す速度はその進歩に追いつけない。だから試験紙はすぐに天井に達してしまう。論文はこの状態を飽和(saturation)と呼ぶ。実際、材料科学の人手製ベンチマークでは、問題を解くエージェント(以下ソルバー)たちの平均が95.7点、ほぼ満点に張り付いていた。実力差の見える余地がなかったのだ。
AutoSciBenchの発想はシンプルでありながら大胆だ。より難しい問題を人がひねり出す代わりに、エージェントが問題をどう解くのか、その解答プロセスを覗き見し、それを手がかりに問題を自ら難しく育てていく。試験紙が生徒を見て、ひとりでに進化していくわけだ。
ベンチマークの飽和はあらゆる分野の悩みの種だが、科学はとりわけ厄介だ。理由は二つの違いを重ねて見ると浮かび上がる。
第一に、LLMとエージェントは違う。LLM(大規模言語モデル)の問題は、答えに必要な情報がすでに質問の中か、あるいはモデルが覚え込んだ知識の中に収まっている。一方エージェントは、環境と直接ぶつかって必要な情報を自力で獲得しなければならない。計画を立て、ツールを動かし、出てきた結果を見て、さらに分析する。
第二に、一般エージェントと科学エージェントもまた違う。コーディングやウェブ作業では、間違えればエラーがすぐに出る。信号が即座に返ってくるから直せる。科学分析はそんな親切な正解の信号をくれない。途中で出てきた数字は「この解釈が正しい」とは言ってくれない。間接的な証拠にすぎないのだ。たとえばエージェントが遺伝子発現の測定値の生データを掘り起こし、どの操作が平均以上の効果を出したかを確認し、その結果をさらに別の証拠と重ね合わせて、ようやく結論に近づく。
二つの違いを合わせると結論は一つだ。科学エージェントをきちんと評価するには、質問をうまく作るだけではだめだ。エージェントが掘り起こすデータとツール、そして間接的な証拠をどう組み合わせて結論に至るのか、そこまで含めて設計しなければならない。生データの再検討、途中結果の検証、複数段階にわたる証拠の統合——これこそが科学課題が本当に測るべき能力だ。ところがこうした問題を一つまともに作ろうとすると、専門家の時間が大量にかかる。だからなおさらモデルの速度に追いつけないのだ。
AutoSciBenchは課題一つを二つの層に分けて作る。完璧なステーキ一皿を出すプロセスにたとえてみよう。
上の層はコンセプト(concept)だ。何を評価するかを決める段階、言うなれば「今日はステーキを焼く」とメニューを決める場面である。どんな科学分野なのか、どんなデータを扱うのか、どんな作業をさせるのか——材料と目標だけを書き、具体的な調理法は空けておく。
下の層はレシピ(recipe)だ。その料理をどんな順序で作るかを書く段階である。ここでの核心となる決定は一つ。何をあらかじめ手に握らせ、何は自分で突き止めさせるか。
論文の実例がすっきりしている。結晶構造を分類する課題なのだが、必要な材料データ(イオン半径表、分類ルール)はファイルで渡す一方、肝心の計算式と答えは渡さない。質問はたった一行、「この物質の構造を分類せよ」。エージェントはデータを取り出して自力で指標を計算し、ルールを適用しなければ答えにたどり着けない。正解は出題側が同じ計算をあらかじめ回して検証しておく。こうして二つの層を分けると、同じ分析能力を狙いつつ、質問とデータはいくらでも違う形で作り出せる。
ここまでは既存の自動生成研究と大きくは変わらない。AutoBencherやBenchMakerといった先行手法も、定めた目標や品質基準から問題を引き出す。ただし彼らは主に「質問さえうまく作ればよい」LLM評価に焦点を置く。科学エージェントは質問だけでなく環境とデータ、間接的な証拠の解釈まで設計しなければならないというのが先に見た違いであり、二層構造はまさにその要求から生まれた。
本当の差別化はその次だ。レシピをうまく組んだからといって、狙った料理が出てくる保証はない。エージェントがツール一つの出力だけをちらっと見て答えを当ててしまうことがあるからだ。料理でいえば、中は生焼けなのにソースだけかけてそれらしく仕立てた一皿だ。論文はこの浅知恵をショートカット(shortcut)と呼ぶ。
そこで味見をしながらレシピを直すプロセスを入れる。作った課題をソルバーが何度も独立に解いてみる。その解答プロセスと最終的な答えを、ジャッジ(採点を担うもう一つのモデル)が自分の目で見る。一つは「質問とデータが採点可能な明確な答えを支えているか」(検証可能性)、もう一つは「ソルバーが何度も解いてどれくらい当てるか」(解答率)だ。解答プロセスを掘り下げれば、エージェントがどの箇所でショートカットに逸れたかも見えてくる。
採点はできるが易しすぎるなら、ジャッジの指摘を根拠にレシピを手直しする。途中の出力一つでは足りず、追加の検証と解釈が必要になるように、データと質問を組み直す。それでも当初狙った推論が出てこなければ、コンセプト、つまりメニュー自体を差し替える。この直して-また解かせて-採点するというサイクルを、課題一つあたり最大十回まわす。
最後のピースは料理ノートだ。課題一つを直しながら学んだことを、その課題だけに使って捨ててしまうのはもったいない。放っておけば生成器は似た弱点を持つメニューをまた出してくる。だから精緻化しながら得た教訓を経験カードに要約して積んでおく。どんな設計が直答を許したか、どんな修正がソルバーの行動を変えたか、まだ解けていない宿題は何か。目を引くのは、失敗したレシピもノートに残すという点だ。失敗からも学ぶ構造である。
もっとも劇的な場面は材料科学だ。人手製ベンチマークで95.7点と天井に張り付いていたソルバー平均が、Claude Opus 4.8が生成したベンチマークでは70.2点に落ちた。計算生物学も79.8点から57.4点へと沈んだ。アブストラクトが掲げた22.4・25.5ポイントの下落が、まさにこのOpus 4.8基準の数値だ。生成器によって下落幅は違ったが、方向は同じだった。
落ちたことよりも重要なのは、ばらけたことだ。満点近くに固まって見分けのつかなかったスコアが、生成ベンチマークでは下方向に広く散らばった。飽和していた試験紙が、再びモデル間の実力差を選り分けはじめたのだ。「ベンチマークの飽和を解く」という主張の核心的な証拠がここにある。
この難しさが特定のペアにだけ効いた偶然ではない、という信号もある。問題を作るのに使われなかった別のモデルも、生成ベンチマークで低いスコアを取った。難度が出題者-応試者のペアを越えて、他のモデルにも転移したのだ。
品質はまた別の軸だ。生成された課題は三分野すべてで、人手製の課題より平均品質スコアを高く取った。難しいだけでなく、評価として有効だったという意味である。ただし、その品質スコアをつけたのも難度をつけたのと同じLLMジャッジだ。人間の専門家ではない——解釈する際に割り引いて考えるべき点だ。
論文は二つの仕掛けが本当に効果があるのかを一つずつ切り離して見る実験(アブレーション実験)も回した。反復精緻化はラウンドを重ねるほど難度を上げたが、その上昇が「データの再検討と解釈をより要求する」形で起きた。要求される推論の性質そのものが変わったのだ。料理ノートに当たる経験ベースの生成は、先に効果が確認された解答要求を次の課題に再利用して、より難しい問題を作り出した。
著者たちも認めている。この枠組みは一発で良い課題を作り出せない。反復精緻化を置いたこと自体がその証拠だ。その上に、三つのことを押さえておく価値がある。
第一に、自己参照のリスクだ。問題を作る生成器と、それを解くソルバーが同じモデルである。「自分が解けないものを難しいと判定する」という罠がここに潜んでいる。難度が別のモデルに転移したという点がある程度の防御壁にはなるが、生成器自身の盲点は課題にそのまま相続される。生成器がそもそも見落とす種類の科学的誤りは、問題として作られることすらない。
第二に、解答率の罠だ。日本の入試でたとえるとこうなる。複雑な思考力を要求するために正答率が低い難問と、設問文があいまいだったり誤字があったりして正答率が低い不良問題とは、まったく別の話だ。どちらも解答率は低く出る。AutoSciBenchは検証可能性を合わせて見ることで両者を分けようとするが、そのジャッジもまたLLMだという限界がある。
第三に、正解の信頼性だ。課題の正解をエージェントが自分で計算して作る。ルールが明快な計算型ならともかく、より開かれた科学分析で自動的に引き出した「正解」が専門家の目にも正解なのかは、別途確認が必要だ。
参考までに、実験は計算生物学・材料科学・臨床画像の三分野で回し、それぞれCompBioBench・MatTools・MedCTAをシードベンチマークとして用いた。ただし臨床画像の人手製ベンチマークのスコアは比較表から外された。正解を文字単位まで突き合わせる方式ではなくLLMが採点する方式であり、他の二分野と同じ物差しに載せられないからだ。だから精度の下落は計算生物学・材料科学の二分野の話である。三分野が一様に難しくなったと一括りにしてはいけない。
この論文の悩みは、ONTLEの日常とそっくり重なる。ONTLEは顧客プロジェクトごとにAI PMを付ける。人間のプロジェクトマネージャーがやっていた仕事——依頼を受け、データを分析し、結果をまとめて報告する仕事——をAIエージェントが引き受けて遂行する方式だ。そのPMを顧客に送り出す前、私たちは毎回問う。「このPMはこの顧客のデータで本当に分析をやり遂げるのか、それともそれらしい答えで済ませてしまうのか」。
問題は、いまこの検証が固定されたテストいくつかに頼っていることだ。モデルを一段階上げれば、そのテストはすぐにすべて通過されてしまう。通過率100%は「完璧だ」ではなく「もう区別がつかない」という信号なのに、私たちはしばしばそれを合格と読んでしまう。
一つの場面を最後まで追ってみよう。顧客が売上の生データをエクセルでアップロードする。ONTLEのワークスペースはすでにこのファイルを表でプレビューする。PMに「異常区間を見つけよ」と指示する。PMがツールを一度回して出てきた要約の数字一つだけを見て「3月に急減」と結論づけたら、それは中が生焼けのステーキにソースだけかけた答えだ。AutoSciBenchの発想を借りれば、まさにその地点で検証課題を書き直す。要約の数字一つでは結論が出ないように、複数のシートの証拠を突き合わせてはじめて答えが立つように、データと質問を組み直すのだ。そして私たちのPMが繰り返しはまり込むショートカットを経験カードのように積んでおけば、次の顧客の検証を組むとき、その弱点を最初から狙える。派遣前のQAが「通過/不通過」のハンコから「このPMの失敗地図」へと変わるわけだ。
ただし一つ、専門家としての提言を添えたい。先に見た自己参照のリスクを私たちの側にもそのまま持ち込まないために、検証課題を作る側と検証を受けるPMとを互いに別のモデルに分離する、クロス検証の構造を考えてみるべき地点だ。
いいえ。精緻化ループはエージェントが自動で回しますが、出発点は既存の人手製ベンチマークです。どの分野を評価するかも人が決めます。ゼロから創造するというより、既存の資産と文献を事前知識として育てていく構造に近いです。
単一の絶対的な難度を打ち出してくれるツールではない、と見るのが正しいです。信頼の根拠は、難度が生成に使っていない別のモデルにも転移したという点です。実務では、何を見分けたいのかに合わせて生成器を選び、必ず外部のモデルで難度が保たれるかをクロス確認するのが安全です。
この論文が検証した範囲は計算生物学・材料科学・臨床画像の三つの科学分野だけです。解答プロセスを見てショートカットを塞ぐという核心の発想は分野を選ばなさそうですが、その外での効果はこの論文が示した結果ではありません。持ち込んで使うには、それぞれのドメインで改めて検証する必要があります。