顕微鏡画像を数値として分析するAIエージェントたちを一堂に集めて競わせたベンチマークがある。名前はBIABench。ここでいうエージェントとは、人が指示すれば分析の複数の工程を自ら踏んで結果まで出してくれるAIプログラムのことだ。ベンチマークは、そうした複数のAIを同じ問題用紙に並べて成績をつける共通の試験台だ。この研究がもっとも力を入れて示しているのは、誰が一位かではない。その順位を信じていいのか、という問いだ。
研究陣は各エージェントを同じタスクに3回ずつ走らせた。常識的には、同じエージェントの3つの結果は互いに似通い、まったく別のエージェントどうしはもっと開くはずだ。結果は逆だった。あるエージェントを3回走らせたスコアのばらつきが、別々のエージェント間のばらつきより大きかった。
同じ料理人が同じレシピで三度煮た汁の塩加減が、まったく別の料理人たちが作った汁どうしの塩加減よりもばらついていた、という話だ。これでは一度測った順位など当てにならない。ある回で一位でも、次の回では最下位かもしれないのだから。
誤解しないでほしい。リーダーボードがまるごと無意味だという意味ではない。たった一度測ってつけた順位を信じるな、という意味だ。エージェントを並べて比べるなら、同じタスクを何度も走らせ、スコアがブレる幅まで一緒に見なければならない。この記事が最後まで手放さない考えも一つだ。一度の成功よりも「毎回同じ結果を出すか」が、そしてその結果を誰が独立に確認するかが、より重要だということ。
顕微鏡画像を数値に変える作業は思いのほか骨が折れる。細胞を数え、核と細胞質を分け、時間に沿って一つの細胞を追う。専用ソフトウェアとプログラミングが必要だが、多くの研究室にはその手がない。だから「画像と指示さえ渡せば、あとは勝手に分析して結果を報告してくれるエージェント」という絵姿は魅力的に映る。
問題は、その絵姿が実際に成り立つのかをきちんと測った場がなかったことだ。従来のベンチマークは分析の一断片しか見ていなかった。核をうまく分けられるか、細胞をうまく追えるか。だが研究室の分析は一工程では終わらない。画像を整え、断片をつなぎ、分ける(セグメンテーション — 画像から細胞一つひとつの境界を切り出す作業)。そこから特徴を抽出して統計を取って、はじめて生物学的な結論が出る。
BIABenchの設計は一行で言える。すでに公開された研究を3つに割る。元画像、生物学者が「これを測ってほしい」と書いた指示文、そして論文が報告した結果だ。前の2つだけをエージェントに渡し、正解は隠す。エージェントが出した答えを、ピアレビュー(他の専門家があらかじめ検証した手続き)を通った元の結果と突き合わせる。16本の研究がこうしてタスクになった。組織染色標本から単分子顕微鏡まで様々な種類の画像を含み、細菌からヒトまで6種の試料が入った。要するに、並のエージェントが一つ二つの芸だけでは通れないよう、意図的に組んだ手強い組み合わせだ。同じやり方で新しい論文を次々とタスクに加えられること、それがこの設計の本当の寿命だ。
エージェントにとって、特に2つが壁になる。一つ、データが大きく複雑すぎて一目では把握しきれない。高解像度の2D、3Dボリューム、時系列が混ざっているため、エージェントはコードで手探りしながら扱うしかない。二つ、正解の決まった問題ではなく、「何をどう分析するか」から自分で決めなければならないオープンな課題だ。この2つの壁は、後でまた出てくる。
競う相手は6つだ。Pythonコードを自分で書いて走らせるツール型エージェント(Biomni)、コーディング用のコマンドラインエージェント3つ、そしてFiji/ImageJのような分析プログラムの画面を直接操作するGUIエージェント2つ。すべて同じ枠組みにはめた。読み取り専用の入力フォルダと書き込み用フォルダを与え、自分で止まるか時間の予算を使い切るまで走らせ、残ったファイルで採点する。
設計で巧みなのは「ガワと頭脳」を切り分けて見た点だ。ここでいうガワはエージェントを動かす枠組みで、頭脳はその上に載るAIモデルだ。同じ頭脳でも、どのガワに載せるかで成功率はかなり変わる。そこでまずモデルを一つに固定して6つすべてを走らせ、次に枠組みを固定したまま複数のモデルを差し替えた。指示文も2種類与えた。生物学者が「これを測ってほしい」とだけ書いた簡易な指示と、専門家が推奨パイプライン(複数の分析工程を順につなげた作業フロー)までスケッチしてくれた詳細な指示。実装はエージェントに委ねた。こうして切り分けて見たおかげで、後で出てくる実験が可能になる。
エージェントが分析を最後まで走らせ、それらしい図を出したうえで誤った答えに行き着くこともある。そこで採点を2つに分けた。
一つは結果スコアだ。エージェントが出した成果物を正解と突き合わせる。細胞の形がどれだけ重なるか(Dice)、細胞をどれだけ正しく分割できたか(SEG)と時間を通して追跡できたか(TRA)、抽出した数値の分布がどれだけ近いか(KS統計量)といったものを0と1のあいだのスコアに換算する。名前は違っても原理は一つだ。「正解にどれだけ近いか」を数値にする。成果物をまったく出さなければ0点だ。
もう一つはプロセススコアだ。読み込みから前処理、セグメンテーション、計測、統計、報告まで工程を分けておき、各工程をきちんと踏んだかを見る。採点は画像を読めるAIジャッジが担う。エージェントが残したコード・ログ・図・表を見て、工程ごとに合格・不合格・判定不能をつける。ただし順位は結果スコアだけでつける。プロセススコアは「どうやったか」を見る補助指標だ。
そのジャッジは信頼できるのか。これも別途測った。複数のエージェントとタスクにまたがる実行20件を選び、細胞生物学の専門家がジャッジの判定をすべて伏せた状態で、工程ごとに採点し直した。専門家とジャッジの判定がどれだけ重なるか(Cohen's kappa、2人の採点者の一致度)を見ると、入力を理解する工程ではよく合い、ツールを選ぶ工程で最もずれた。ジャッジは専門家より合格を2点ほど甘くつけた。そこでベンチマークはジャッジを一つに固定し、この専門家との一致度をプロセススコアの横に必ず併記する。ジャッジごとに偏りが違うので、スコアの絶対値を他のベンチマークとそのまま比較するな、という意味だ。
成果はタスクの形によってすっぱり分かれた。ありふれた2次元のタスクはうまく解けた。ところがここに奥行き(3次元)や時間が加わると、成績が急激に悪くなるタスクが現れた。モデルを一つに固定して6つのエージェントを比べた実験では、奥行きや時間が加わった一部の難しいタスクは、どのエージェントも0.19(タスクごとの3回平均)を超えられなかった。
この数字を実感するには、先ほどの採点指標を思い出せばいい。多くは0と1のあいだで、1が正解に近い。0.19なら底だ。重要なのは、これが「最も出来の悪いエージェント」のスコアではないということだ。そのタスクで最も出来のよかったエージェントすら超えられなかった天井が0.19だった。
もっと厄介なのは、この壁を下げようとする試みが、最も難しいタスクではなかなか効かなかった点だ。生物学に特化したエージェントを使っても、専門家がパイプラインまで描いてくれた詳細な指示を与えても、その壁はそのままだった。モデルをより強力なものに差し替えた実験は、タスクによって結果が分かれた。3次元ゼブラフィッシュのセグメンテーションのように大きく伸びたタスクがある一方、核膜孔の定量のように依然として底のままのタスクもあった。要するに、奥行き・時間が加わったからといってすべてが崩れるのではなく、特定の難しいタスクが、3つのてこ(特化エージェント・大型モデル・詳細指示)を引いても越えがたい壁として残った、ということだ。なぜよりによって奥行きと時間なのか。先に挙げた2つの壁がここで重なる。3次元・時系列は一目では把握できずコードで手探りするしかなく、その手探りの戦略をエージェント自身が正しく組み立てなければならないからだ。
スコアが低いのはまだいい。もっと気になるのは、「低いスコア」と「エージェントが自分では大丈夫だと思い込んでいること」が食い違っている点だ。
研究陣は、提出はされたがスコアの低い実行を、最後のメッセージで「完了した」と言ったかどうかでさらに切り分けた。付録の失敗例が生々しい。あるエージェントは「分析を終えた」として細胞数を載せた表を提出した。ところがその表の数字と報告書本文の説明が食い違っていた。別のケースでは、パイプラインは一見問題なかったのに、スポット(puncta、蛍光で写る小さな点)一つを「点として数えるか」を分ける閾値が最後まで一度も補正されず、結果が丸ごと誤っていた。ある実行は締めのメッセージで「これから分析を実行する」という未来形で完了を宣言した。肝心の作業は何もしないまま。
決定的なのはこれだ。正解を知らない状態では、正しい実行と誤った実行を、プロセススコアでも所要時間でも見分けられなかった。プロセスをきれいに書いていようが、時間を長くかけていようが、それが正解かどうかには結びつかなかった。付け加えると、顕微鏡画像を分析してほしいという依頼が提供元の安全フィルターに引っかかり、そもそも拒否された実行まであった。
AIエージェントが「分析完了」の報告とともに成果物を提出する場面を想像してみよう。企業が導入した自動化された分析パイプラインであれ、社内のAIアシスタントであれ同じだ。私たちはしばしば、この一行と添付された結果ファイルを「作業が終わった」証拠として受け取る。成果物があり、エージェント自身が終わったと言ったのだから。
BIABenchは、まさにこの一行の足元を外す。いま見た失敗が語るのは一つだ。「完了」という言葉も、添付されたファイルの存在も、正解の証拠ではない。プロセスがきれいかどうか、どれだけ時間をかけたかも同じだ。ところが、AIを信じるか否かを判断するとき、私たちがつい手に取る手がかりがまさにこれらだ。自己申告、ログの整然さ、所要時間。
私たちのチーム(ONTLE)も、この観点からAI PMの完了判定の基準を組み直している。変えるべきは「完了」という言葉をなくすことではなく、その言葉が合格の根拠になる構造のほうだ。完了判定をエージェントの自己申告から切り離し、結果そのものを独立に検証する軸に掛ける。プロセスの記録は捨てない。顧客に「どうやったか」を見せる説明資料として残す。ただし「合格」の印は、結果が基準を満たしたときにだけ押す。
一つ引っかかりがある。顧客の課題には、すぐに突き合わせられる正解がないことが多い。そこで検証のタイミングを、仕事を受け取る瞬間まで前倒しする。たとえば、あるショッピングモールが「先月の注文データから返品率の高い商品を抜き出してほしい」と依頼してきたとしよう。受付の段階で、私たちは顧客とともに3つを確定させる。サンプル正解(顧客が手作業ですでに把握している上位いくつかの品目)、再現すべき数値(返品率の計算式と先月の総返品件数)、合格の最低基準(サンプル品目が結果の上位にすべて入り、集計の総件数が顧客の帳簿と一致すること)だ。AI PMが「完了」を宣言すると、システムがこの3つを自動で突き合わせたうえで、はじめて結果が顧客に渡る。さらに、同じデータを何度も走らせて、リストが毎回ほぼ同じになるかまで見る。一度合っていたという事実は、次も合うという保証ではないからだ。
著者たち自身が挙げる限界は2つ、性能の差と信頼性そのものだ。奥行き・時間のタスクで現在のエージェントは専門家に遠く及ばず、原因としてデータの複雑さ・信頼性・自己点検の不足を挙げるが、解決策はまだ未解決だと書いている。
実験の正直な残りも見ておく価値がある。オープンウェイトモデル(内部のパラメータが公開され、誰でも直接ダウンロードして動かせるモデル)2つは、あるコーディング枠組みで「空のAPI応答」が「完了したターン」として誤って記録される問題のため、評価が不可能で外された。創傷治癒タスクの一部の実行は画像サイズの制限に引っかかって除外され、有効な実行が3件そろうまで走らせ直した。こうした相性の問題が、逆説的に「枠組みがモデルと同じくらい結果を揺さぶる」というこの論文の主張を裏づけている。
私が付け加えたい限界もある。タスクの数が多くない。広い範囲を収めようとした結果、条件ごとに切り分けると標本が薄くなる。したがってこの研究の結論は「警報」としては有効だが、特定のモデルやアプローチの優劣を決める「判決」として読むにはまだ早い。また画面を操作するGUIエージェントはコードをほとんど残さないため、プロセススコアで「判定不能」に抜ける割合が大きくなる。ベンチマークはこれを分母から外し、別途、監査可能性(結果がどう導かれたかを事後にたどって確認できる度合い)の指標として書き留めているが、異なるインターフェースをプロセススコア一つで公正に並べることが容易でないことを示している。
あわせて公開します。arXiv版はCC BY 4.0です。元となった研究データもすべて公開ライセンスの資料であり、それぞれ元のライセンス条件のままベンチマークと一緒に再配布されます。
遮断していません。ただし保存された追跡ログをすべて監査した結果、ネットワークはパッケージとモデルの重み(モデルが学習で得た内部数値のまとまり)をダウンロードするため、そしてソフトウェアのドキュメントを2回閲覧するためだけに使われていました。
すべての指示文が、元の出版物や報告された数値を検索すること、そしてファイル名やメタデータからどの論文かを特定することを禁じています。一般的な方法論の文献やソフトウェアのドキュメントの閲覧は許可しています。
基準値をそのまま置いておけないNF-κB転位(細胞が刺激を受けるとNF-κBというタンパク質が核内へ移動する現象)のタスクは例外的に、提出した表が示す用量反応の特性で採点します。