評価スコアをいったん脇に置いて、実際のタスクに立ち返る
このSlackメッセージが突きつけたのは、2つの可能性だ。2万トークンをかけた自分たちのシステムプロンプトがほとんど無駄だったのか、それとも自分たちのベンチマーク自体が、指示のあるエージェントと、指示のないエージェントの違いを見分けられていないだけなのか。前者だとしたら恥ずかしいだけで済むが、後者だとしたら危険だ。そしてスコアという数字だけでは、どちらなのか判断できない。van der Hoeven氏はここで、「疑いという営みそのものを疑い始めた」とチームの心境を語る。
そこでチームは、スコアをいったん脇に置き、実際のタスクに立ち返ることにした。実際に発生した本番インシデントのスナップショットを取得し、通常どおり根本原因を特定して解決したうえで、そのスナップショットを2つの異なるバージョンのAssistantに与え、同じインシデントを解決させて結果を比較する。これが「Investigation Arena」だ。すでに根本原因が分かっているタスクに対して、実際に解決できるかどうかという一点に立ち返ることで、採点や合否の議論から距離を置くことができる。
またチームは、Assistant自身がllmspecのテストスイートを実行し、失敗した箇所から学習して自らのコードベースに修正を加え、再度テストを実行して確認する「llmspec-improve」という自己改善ループにも着手した。ただしこの仕組みは今も完全には自動化されておらず、人間が起動し、結果を見届けている。信頼しきれずに手放せずにいるという事実そのものが、次の疑いへとつながっていく。
チームはさらに、可観測性に特化した初めてのベンチマーク「o11y-bench.ai」を一般公開した。ログ・メトリクス・トレース・ダッシュボード・インシデント対応にまたがる63件の実務的なタスクで構成され、誰でも結果を再現でき、コミュニティから他のモデルのスコアを募ることもできる。リーダーボードではClaude Opus系のモデルが上位を占める一方、オープンウェイトモデルのQwen 2.5 72Bも上位10位台につけているという。自分たちだけを疑い手とするのではなく、外部にもその役割を開いたのがこの試みだ。
