AI ベンチマークは、仕事の成立条件まで測り始めた

by

AI の性能を比較するとき、最初に目に入るのはモデル名と得点である。あるモデルが 80 点、別のモデルが 70 点なら、同じ試験を受けた結果として前者の性能が高いと読むことはできる。ただ、その 80 点にはモデルの能力だけでなく評価条件も反映される。問題文にどこまで情報が与えられていたか、検索やコード実行などの機能を利用できたか、どの実行環境と配信経路を通ったか、無効な応答や実行失敗をどう採点したか、一つの課題へ何回まで試行できたかによって、観測される得点は変わる。

得点が成立するまでには、モデル以外にも複数の条件が介在する。たとえば、修正すべき関数まで指定されたコード生成課題と、障害の原因箇所から自分で探す課題では、同じコードを最終的に生成したとしても、その途中で要求される能力が異なる。外部ツールを利用できる評価と、モデル内部の知識だけで回答する評価では、得点が表す能力の範囲も変わる。また、最初の実行に失敗しても結果を観測して再試行できる条件では、一回だけ回答する条件とは異なり、失敗から次の判断へ進む能力まで得点へ含まれる。

条件 あらかじめ固定されている場合 AI 自身が扱う場合
仕様 達成すべき結果と必要情報が問題文として与えられる。 情報不足や曖昧さを発見し、確認すべき内容を特定する必要がある。
対象箇所 修正する関数やファイルが指定される。 リポジトリや実行結果を調査し、原因箇所を特定する必要がある。
利用機能 検索、コード実行、ツール利用などの条件が統一される。 利用可能な機能を選び、複数の操作を組み合わせて仕事を進める必要がある。
実行環境 評価側が共通の環境を用意する。 環境差や依存関係を認識し、実行可能な条件を成立させる必要がある。
反復 一回の回答または固定回数の試行で評価する。 失敗を観測し、仮説を更新し、次の試行へ進む必要がある。
評価条件 正解、テスト、採点方法が事前に決まっている。 何を検証すれば仕事の完了を確認できるかまで判断する必要がある。

この違いは、AI が一つの質問へ一つの回答を返す範囲では目立ちにくかった。質問文と正解があらかじめ決められていれば、評価側が問題設定、必要情報、実行手段、終了条件を先に用意できるからである。ところが、AI エージェントが研究、ソフトウェア開発、業務処理のような複数工程を扱うと、それまで評価側が固定していた条件そのものが作業へ入ってくる。仕様が不足していれば、何が未確定なのかを発見しなければならない。利用経路が必要な機能を提供していなければ、モデルに生成能力があっても仕事は開始または完了できない。修正箇所が与えられていなければ、対象を計測し、原因について仮説を立て、変更を試し、その結果から次の操作を決める必要がある。

モデルの性能は依然として中心的な構成要素である。モデルの出力だけを採点すると、仕様不足による失敗、提供系の制約による失敗、探索方針の誤り、評価方法による差まで一つの数字へまとめられる。その状態では、得点が低かった理由と、高かった結果を別の環境で再現する条件が混在したままになる。

AI の実務能力を測る単位は、モデル単体から、仕事が成立する系へ広げる必要がある。仕様、モデル、配信経路、実行環境、利用可能な機能、反復条件、評価方法を区別して初めて、最終的な得点がどの条件から生じたのかを追跡できる。AI の評価対象は、モデルが答えを生成する能力から、その答えへ到達するまでの条件を含めて仕事を成立させる能力へ広がりつつある。

1. AI の性能という数字は何を測っているのか

ベンチマークで複数のモデルを比較するには、モデル以外の条件をできるだけそろえる必要がある。MMLU は数学、歴史、計算機科学、法律など 57 分野の問題を用意し、同じ問題集合に対する回答から言語モデルの知識と問題解決能力を比較した[1]。Codex の評価で導入された HumanEval は、自然言語で関数の目的と入出力を示し、それを満たす Python の関数を生成させ、用意されたテストを通るかによって機能的な正しさを測った[2]。HELM は評価対象を広げ、正解率、較正、頑健性、公平性、偏り、有害性、効率など複数の評価軸を共通の枠組みで測定した[3]。

ベンチマーク 主な測定対象 評価側で固定される条件
MMLU 57 分野にまたがる知識と問題解決能力を測る。 問題文、選択肢、正解、出題分野が事前に定義される。
HumanEval 自然言語で与えられた関数仕様を満たすコード生成能力を測る。 実装対象となる関数、入出力仕様、判定用テストが事前に用意される。
HELM 正解率に加えて、較正、頑健性、公平性、偏り、有害性、効率などを測る。 評価シナリオ、指標、入力形式、測定方法が共通の枠組みとして定義される。

三つは種類の異なるベンチマークだが、比較を成立させる方法には共通点がある。MMLU では出題内容と選択肢が先に固定される。HumanEval では実装すべき関数の仕様と、それを判定するテストが先に用意される。HELM でも、どのシナリオで何を測定するかを評価側が定義する。モデルごとに問題や採点方法を変えてしまえば、得点差がモデルの違いから生じたのか、試験条件の違いから生じたのか分からなくなるためである。

この固定によって、ベンチマークは再現可能な比較を作る。同時に、評価側が固定した条件はモデル能力の測定範囲から外れる。HumanEval では「どの関数を実装すべきか」が既に決まっているため、巨大なリポジトリから修正箇所を特定する能力は評価範囲外である。テストも評価側が用意するため、必要な検証条件をモデル自身が洗い出す能力も評価範囲外になる。問題文に実装上必要な情報が不足しているかを判断する能力も、仕様充足性を評価対象に含めた場合に初めて表面化する。

固定される条件 比較可能になるもの その評価だけでは測れないもの
問題文 同じ入力に対するモデル間の回答差を比較できる。 問題文そのものに必要な情報が足りているかを診断する能力は測れない。
実装対象 指定された対象についてコード生成能力を比較できる。 どのファイルや関数を変更すべきかを調査する能力は測れない。
評価テスト 同じ成功条件に対する機能的な達成率を比較できる。 必要なテストを設計し、要求を十分に検証できるかは測れない。
実行条件 環境差を抑えてモデル間の結果を比較できる。 異なる環境や提供経路で同じ能力を再現できるかは測れない。

評価条件の固定には、比較したい変数を分離する役割がある。測定したい変数を比較するには、それ以外の条件を制御する必要がある。温度計の性能を比較するときに測定対象や周囲の条件をそろえるのと同じで、AI ベンチマークでも条件を固定するからモデル間の差を読める。注意が必要なのは、その試験で固定した条件までモデルが処理できたと解釈するときである。

たとえば HumanEval で高い得点を得たモデルについて、「与えられた関数仕様からテストを満たす実装を生成できる」と評価することには意味がある。その評価範囲は、実際のソフトウェア開発全体より狭い。実際の開発では、要求が十分に決まっているかを確認し、リポジトリから関連箇所を探し、既存仕様との互換性を判断し、必要なテストを決め、実行結果を見て修正する工程が追加される。ベンチマークが固定したこれらの工程は、その得点の評価範囲外である。

同じことは、評価方法についても成り立つ。テスト通過率を測るベンチマークから直接分かるのは、そのテスト集合が判定する条件をどの程度満たしたかである。別の入力、性能制約、セキュリティー要件、既存利用者との互換性は別の評価対象になる。評価器が観測する範囲を越えて得点を一般化すると、評価外の性質までモデルの能力として扱うことになる。

AI の得点は、問題、利用可能な情報と機能、実行条件、評価器を組み合わせた測定によって得られる値である。ベンチマークを読むときには、何点だったかと同時に、その点数を得るために何があらかじめ与えられ、何がモデル自身の仕事として残されていたかを見る必要がある。後者を確認して初めて、その数字をどの範囲の実務能力へ接続できるかが決まる。

2. ベンチマークは仕事を解きやすい形へ切り出してきた

AI の評価対象は、単発の回答生成から、より長い工程を含む仕事へ広がってきた。コード生成では、その変化が分かりやすい。関数単位の評価では、実装すべき場所と入出力仕様が最初から与えられ、モデルは指定された範囲のコードを生成すればよい。これに対して SWE-bench は、実在する GitHub の Issue と、それを解決した変更を基に 2,294 件の課題を構成し、モデルへ対象リポジトリと Issue を与えて修正させる[4]。モデルは一つの関数だけを見るのではなく、リポジトリ内を調査し、関連するファイルや既存実装を読み、どこを変更するかを判断したうえで、修正結果を実行環境で検証する必要がある。

評価対象が関数からリポジトリへ広がると、測定される能力も変わる。関数生成では「どこを実装するか」が評価側によって解決済みである。SWE-bench では、その一部がモデル側の仕事へ移る。Issue に書かれた現象から関連箇所を探し、既存コードとの関係を読み、複数ファイルにまたがる変更が必要かを判断しなければならない。つまり、従来のコード生成能力に、評価条件として固定されていたコードベースの調査能力を加えて測定している。

同じ拡張は、ソフトウェア開発以外でも進んだ。AgentBench は OS、データベース、知識グラフ、Web など複数の対話型環境を用意し、エージェントが環境の状態を観測しながら操作を選択する能力を評価する[5]。WebArena は電子商取引、掲示板、共同ソフトウェア開発、コンテンツ管理など、実際に機能する Web サイトを評価環境として構築し、一回の応答では完了しない操作列を課題に含めた[6]。GAIA は推論、Web 閲覧、複数形式の情報処理、ツール利用を組み合わせて答えへ到達する問題を扱う[7]。OSWorld は Ubuntu、Windows、macOS 上の実際のアプリケーションを操作する課題を用意し、画面の状態を読みながら複数の操作を継続する能力を評価対象へ広げた[8]。

この流れを並べると、評価対象が広がるたびに、それまで評価側が処理していた仕事の一部が AI 側へ移されていることが分かる。

評価対象 評価側が主に固定する条件 AI 側へ移された仕事 新たに観測できる能力
知識問題 問題、選択肢、正解、採点方法が事前に定義される。 与えられた問題に対する回答を選択または生成する。 固定された問題集合に対する知識と推論結果を観測できる。
関数生成 実装対象となる関数、入出力仕様、評価テストが事前に定義される。 指定された仕様を満たす局所的な実装を生成する。 自然言語で与えられた仕様からプログラムを構成する能力を観測できる。
リポジトリ修正 対象リポジトリと解決すべき Issue が与えられる。 関連ファイルを探索し、既存実装を理解し、変更範囲を判断して修正する。 コードベース調査と複数ファイルをまたぐ変更を含む開発能力を観測できる。
対話型環境 利用可能な環境、操作手段、課題の達成条件が用意される。 現在の状態を観測し、その結果に応じて次の操作を選択する。 一回の生成ではなく、観測と操作を繰り返して状態を変化させる能力を観測できる。
Web 上の長期操作 利用する Web サービスと最終的に達成すべき課題が用意される。 複数ページを移動し、途中状態を確認しながら一連の操作を完了する。 長い操作列を維持し、途中結果に応じて行動を継続する能力を観測できる。
実コンピューター操作 OS、アプリケーション、初期状態、達成条件が評価環境として構成される。 複数のアプリケーションを横断し、画面状態を読みながら操作方法を決定する。 実際のコンピューター環境で状態を認識し、作業を遂行する能力を観測できる。

表の左から右へ進むほど、評価側が事前に解決しておく事柄が減り、AI 自身が処理する工程が増えている。関数生成では実装対象が既知であるのに対し、リポジトリ修正では関連箇所を探す必要がある。静的な問題では一回の回答で評価できるのに対し、対話型環境では一つの操作によって環境状態が変わり、その新しい状態を観測して次の操作を決めなければならない。Web や OS の操作では、この観測と判断が何段階にも連続する。

この違いには、課題の難易度とは別の軸がある。難しい数学問題を一問解かせても、問題文、利用可能な情報、回答形式、正解判定がすべて事前に固定されていれば、AI が処理する仕事の境界は狭いままである。一方、比較的単純な業務であっても、複数の画面から必要な情報を探し、途中結果に応じて操作を変更し、最後に目的の状態へ到達する必要があれば、評価対象には探索、状態認識、行動選択、継続的な判断が含まれる。

ベンチマークの実務接近は、問題を複雑にすることよりも、評価側が肩代わりしていた工程を AI 側へ移すことによって進んできたと整理できる。HumanEval ではコードベースの探索を評価側が省略する。SWE-bench はリポジトリ調査を AI 側へ移す。静的な問題では途中状態の管理を評価側が省略する。AgentBench、WebArena、OSWorld は、環境を観測して次の操作を選ぶ工程を AI 側へ移す。この移動によって、最終回答だけを見ていた評価から、仕事を進める途中の能力まで測定範囲が広がる。

ただし、これらの評価でも、すべての前提が AI 側へ移されたわけではない。SWE-bench では解決すべき Issue が与えられる。WebArena や OSWorld でも、達成すべき課題そのものは評価側が定義する。利用できる環境やツールもあらかじめ構成されている。つまり、AI が「どう実行するか」を決める範囲は広がっているが、「何を実行すべきかを決めるための情報が十分にそろっているか」という一段前の条件は、なお評価側が成立させている。

実際の仕事では、この条件自体が変動する。依頼文に必要な情報が抜けていることもあれば、複数の解釈が成立して実装方法を一意に定めにくいこともある。その状態で高いコード生成能力や環境操作能力を持っていても、誤った前提を補って作業を進めれば、精度の高い実装能力がそのまま誤った成果物の生成へ使われる。評価対象を実務へ近づけるなら、与えられた仕事を実行する能力に加え、その仕事が実行可能な状態まで定義されているかを見抜く能力も測定対象になる。

3. 仕様が足りないこと自体を見つけられるか

実装に必要な情報が問題文にそろわない状況は、実務で実際に生じる。研究成果の再現では、この問題が以前から顕在化している。Gundersen と Kjensmo は AAAI と IJCAI の 400 論文を調べ、実験、データ、手法について、再現に必要な変数が十分には記録されていないことを報告した[9]。NeurIPS でも、コード提出、再現性チャレンジ、チェックリストの導入を通じて、結果と、その結果へ到達する条件を再現可能な形で記述することが研究工程の課題として扱われてきた[10]。

ここで欠ける情報は、実装上の選択を直接左右する。学習率が指定されていない、前処理方法が決まっていない、複数の実装候補のうちどれを採用するか分からないといった欠落があれば、同じ研究アイデアから複数の実装が成立する。実装者が何らかの値や方法を補えばプログラムは動かせるが、その結果が著者の意図した方法を再現しているとは限らない。仕様不足は、実装を不可能にする場合だけでなく、異なる実装をもっともらしく成立させる場合にも問題になる。

2026 年 9 月に公開された IdeaAMBIG は、意図した方法を実装するための情報が仕様に十分含まれているか、その不足を LLM が認識できるかを評価対象にした。評価集合は、再現性報告や GitHub Issue などから得た実世界の 163 件と、実装可能な仕様から一つの重要情報を意図的に除いた 497 件を合わせた 660 件で構成される[11]。

評価事例 件数 作り方 評価上の役割
実世界事例 163 件である。 実際の再現性上の問題や GitHub Issue などから、実装を妨げた仕様上の欠落を収集する。 現実の研究実装で発生する不足情報を LLM が認識できるかを測る。
人為的欠落事例 497 件である。 実装可能な仕様から、実装方法を決めるために必要な情報を一つ除去する。 不足箇所が明確に管理された条件で、検出能力を比較する。
合計 660 件である。 実世界の欠落と統制された欠落を組み合わせる。 現実性と評価条件の統制を両立させる。

IdeaAMBIG の特徴は、「仕様が悪いかどうか」を一つの得点で判定しない点にある。評価工程を三つへ分離し、どの段階で LLM が失敗するかを測る。第一段階では、提示された仕様だけで実装へ進めるかを判定する。第二段階では、実装を一意に決めるうえで不足または曖昧な箇所を自力で特定する。第三段階では、不足箇所そのものは与えたうえで、その情報を埋めるために何を質問または調査すべきかを生成させる。

評価段階 AI に与えられる情報 AI が判断すること 実世界事例での最良値
実装可能性判定 研究アイデアの仕様が与えられる。 その情報だけで意図した実装へ進めるかを判定する。 Macro-F1 は 67.5% である。
不足箇所特定 同じ仕様が与えられるが、不足箇所は示されない。 どこに実装上の不足または曖昧さがあるかを自力で特定する。 Macro DRR は 9.6% である。
確認行動生成 不足している箇所があらかじめ示される。 不足情報を埋めるために、何を質問または調査すべきかを生成する。 Macro-CAS は 80.6% である。

三つの値を比べると、失敗の位置が見える。実装可能性を大まかに判定する成績は Macro-F1 67.5% であるのに対し、何が不足しているかを自力で特定する Macro DRR は 9.6% にとどまる。不足箇所を先に示すと、何を確認すればよいかを生成する Macro-CAS は 80.6% まで上がる。つまり、確認方法を考えること自体より、その確認が必要な箇所を発見する段階で大きく性能が落ちている。

正解となる不足情報を補った場合、後続段階で実装可能と判定される割合は 14% から 98% へ上昇した。この変化は、実装能力側の制約と、実装前提となる情報不足を区別する材料になる。必要情報が追加されるだけで実装可能性が大幅に変わるなら、最初の失敗を「コード生成能力が低い」とだけ評価するのは原因の切り分けとして不十分である。

仕様不足を見落とすと、エージェントが暗黙の仮定で実装を続ける経路が生じる。値や方法が指定されていなくても、一般的な実装慣行や周辺文脈からもっともらしい選択肢を補えば、コード自体は生成できる。そのコードがテストを通る場合さえある。欠落していた情報について複数の選択肢が成立するなら、動作したという事実だけでは、意図した方法を実装したことを確認できない。

状態 AI の挙動 表面上の結果 残るリスク
仕様が十分 与えられた条件に基づいて実装する。 実装結果を仕様と照合できる。 通常の実装誤りや評価不足が残る。
仕様不足を認識 実装を確定せず、不足情報を質問または調査する。 仕様を確定してから実装へ進める。 確認結果そのものが誤っていれば、後続実装にも影響する。
仕様不足を認識できない 不足部分を暗黙の仮定で補って実装する。 コードが生成され、場合によってはテストも通る。 要求された方法とは異なる実装を、成功した成果として扱う可能性がある。

ここに、単純なコード生成ベンチマークでは見えにくかった境界がある。仕様が完全な状態でコードを書かせれば、測定できるのは主として実装能力である。仕様が不完全な状態を含めると、その前段にある仕様診断能力が別の変数として現れる。しかも後者に失敗すると、前者の能力が高いほど、もっともらしい誤実装を完成させる可能性がある。生成能力の向上だけでは解消しない問題である。

既稿では、中～大規模開発で後続作業の前提としてまだ利用できない成果を「未確定な状態」と整理した[12]。たとえば仕様の選択肢が残っている、判断根拠が不足している、検証結果が確定していない状態では、その成果を前提に後続工程を進めると、あとから前提が覆ったときの手戻りが広がる。IdeaAMBIG が扱う仕様不足も、この未確定な状態の一種として位置付けられる。

IdeaAMBIG が加えた論点は、未確定事項をどう管理するかより一段前にある。人間や別の工程が「ここが未確定である」と印を付けてくれるなら、AI はその情報を使って質問や調査へ進める。実際に、不足箇所が示された後の確認行動生成は、不足箇所そのものを発見する評価より高い値を示している。実務で AI に工程を任せるなら、未確定事項の処理能力と、未確定事項を自力で発見する能力を別に確認する必要がある。

AI の実務能力には、与えられた仕事を解く能力に加え、その仕事が一意に解ける状態まで定義されているか、その不足を AI 自身が認識する能力が含まれる。仕様が確定して初めて、実装能力の評価が意味を持つ。そして仕様が十分でも、次には別の条件が残る。同じモデル名でも、実際にその能力を利用する配信経路や実行系は提供条件によって変わり得る。

4. 同じモデル名でも実行系は異なり得る

仕様が十分に確定していても、モデルへ仕事を渡すまでには別の条件が残る。企業で利用する AI は、通常、API や配信基盤を経由し、その経路で許可された入力形式、出力上限、精度、ツール呼び出し、構造化出力などの条件の下でモデルを利用する。ベンチマークでは、要求をモデルへ変換する評価ハーネスと、返された結果を解釈する処理も介在する。利用者が実際に接するのは、モデルを含む実行系である。

2026 年 9 月に公開された IBIB は、この違いを企業向け AI システムの測定問題として扱った。著者らが 18 件の既存ベンチマークを調査したところ、結果はいずれも宣伝上のモデル識別子を単位として報告されていた[13]。しかし、同じモデル識別子が表示されていても、実際の要求が通る配信経路、利用できる機能、出力契約まで同一とは限らない。モデル名だけを記録すると、仕事が失敗したときに、モデルが課題を解けなかったのか、利用した経路が課題の実行条件を満たしていなかったのかを区別できなくなる。

IBIB が提案する評価手順は IB2 と呼ばれる。論文名の IBIB と評価手順の IB2 は別の名称である。IB2 は、課題をモデルへ送ってから結果を採点する一連の処理を、実行前、実行時、実行後の三段階に分離する。

段階 確認する内容 分離したい失敗 評価上の意味
実行前 配信経路が評価に必要な能力と入出力契約を実行できるかを確認する。 課題を解けなかった場合と、そもそも必要な機能を提供していない場合を分ける。 実行不能な契約をモデル能力の失敗として数えることを避ける。
実行時 応答失敗を除外せず、実際に要求を送った結果として得点を計算する。 成功した応答だけを集計した能力と、実利用時の信頼性を分けない。 タイムアウトや失敗応答を含め、仕事を完了できた割合として測定する。
実行後 結果に対する事後判定を、最初の得点計算から独立させる。 結果を見た後の判断が得点定義そのものを変えることを避ける。 測定結果と、その結果に対する解釈を分離する。

この三段階を分ける理由は、同じ失敗応答でも原因によって意味が異なるからである。たとえば、課題がツール呼び出しを必要としているのに、利用した配信経路がその契約を実行できなければ、最終的な課題は完了しない。この失敗を単に「モデルが不正解だった」と記録すると、モデルの推論能力と提供系の能力制約が同じ一件の失敗へまとめられる。反対に、失敗した応答を集計から除外すると、実際には仕事を完了できなかった事例が評価結果から消え、利用時に観測される信頼性より高い値になる。

IBIB の基準実装は、文書、表計算、グラフ、ツール、データベースを扱う 128 件の課題と、987 個の検証項目から構成され、11 のシステムを評価した。対象を一問一答へ限定せず、企業環境で発生する複数種類の作業を同じ評価手順へ通すことで、モデル名だけを記録した場合に失われる情報を調べている。

実験では、宣伝上のモデル識別子だけでは説明できない差が観測された。同じ重みを使用した単一経路の実行でも、後から確定した能力確認条件について異なる箇所で失敗した例があり、表示されるモデル識別子からはその制約を判別できなかった。また、同じ宣言上のモデル改訂版と精度を使った二つの構成では、得点が 77.38 から 82.54 へ変化した。

ただし、この 5.16 ポイントの差を、そのまま配信経路の効果として扱うことはできない。二つの構成では、アクセス方式だけでなく、評価ハーネス生成やツール呼び出し解析器も異なっている。観測されたのは「構成 A と構成 B で結果が異なった」という事実であり、その差のうち何ポイントが配信経路、何ポイントがハーネス、何ポイントが解析器によって生じたかまでは分離されていない。

観測できたこと そこから言えること そこからは決められないこと
同じモデル識別子でも能力確認条件への適合が異なった モデル識別子だけでは、実際の提供経路で利用できる能力を完全には表現できない。 その差がモデル内部のどの性質によって生じたかまでは決められない。
同じ宣言上のモデル改訂版と精度で 77.38 と 82.54 の差が生じた モデル名と精度が同じでも、実行構成全体が異なれば観測される得点は変わり得る。 5.16 ポイントの差を配信経路だけの因果効果として帰属することはできない。
失敗応答を分母から除外すると点数上の順序が変化した 失敗をどう集計するかによって、システム間比較の結論そのものが変わり得る。 成功した応答だけの精度から、実利用時の仕事完了率を推定することはできない。

この区別は、ベンチマークの解釈に直接影響する。同じモデル名を持つ二つの結果に差があったとき、モデル名しか記録していなければ、比較表の上では同じ対象が異なる性能を示したように見える。しかし実際には、モデルへ到達するまでの経路や、その前後で要求を変換する処理が異なる可能性がある。反対に、異なるモデルの得点差を比較する場合でも、一方だけが必要な機能を利用できなかったなら、得点差の全部をモデル能力の差として読むことはできない。

性能評価の分野では、モデルと実行系を区別する考え方自体は新しくない。MLPerf Inference は、所定のモデルや精度条件を使いながら、データセンターやエッジ向けの推論システムがどの程度の処理性能を出すかを測る[14]。MLPerf Client も、クライアント機器上で LLM を実行する際のハードウェアとソフトウェアを含むシステムを評価対象とする[15]。モデルを固定したうえで実装系の性能を比較するため、同じモデルを使っていることと、同じシステム性能が得られることを最初から分けて扱っている。

IBIB が扱うのは、この区別を処理速度から、企業向け AI が仕事を実行できるかという能力評価へ広げた場合の問題である。入力を受理できるか、必要な出力形式を返せるか、ツールを利用できるか、失敗時にどのように集計されるかまでが、最終的な仕事の成否に影響する。ここでは配信基盤も、観測される能力を成立させる条件の一部になる。

記録単位 記録される内容 比較できること 残る限界
モデル名だけ 宣言上どのモデル系列を利用したかを記録する。 同じ名称体系のモデル結果を簡潔に並べられる。 配信経路、精度、入出力契約、ツール利用、失敗応答の影響を分離できない。
実行系 モデルに加えて、配信経路や提供条件を一つの構成として記録する。 利用者が実際に使う構成単位で仕事の成功率を比較できる。 構成要素が複数異なる場合、どの要素が得点差を生んだかまでは特定できない。
実行系と評価契約 利用機能、入出力条件、失敗の扱い、採点方法まで記録する。 どの条件の下で得点が成立したかを追跡できる。 別の契約、別の利用経路、別の業務でも同じ結果になることまでは保証しない。

既稿では、AI によって現行解析やコード変換の処理速度が上がると、その後段に残る仕様選択と検証が工程上の制約として表面化すると整理した[16]。評価でも似た移動が起きる。モデルが要求された出力を高い精度で生成できるようになるほど、「その能力を実際の利用経路から呼び出せるか」「失敗をどのように数えたか」「どの構成でその数字が再現するか」という周辺条件が評価結果の解釈を左右する。

モデル名だけの比較にも明確な適用条件がある。同じ入力、同じ利用機能、同じ実行条件、同じ評価方法をそろえ、比較したい変数をモデルへ限定できるなら、モデル単位の比較には明確な意味がある。企業向け AI システムのように、それらの条件が提供経路ごとに異なる場合には、モデル名をそのまま実務能力の識別子として使うと、実際には別の構成で得られた結果を同一対象の性能として扱うことになる。

実務で仕事を実行する主体は、モデル、配信経路、入出力契約、利用可能な機能、評価ハーネスが組み合わされた実行系である。この実行系を通して初めて能力が観測される。得点を解釈するには、どのモデルだったかだけでなく、どの条件でそのモデルを利用したかまで記録する必要がある。

実行系を正確に記録した後にも、実務能力の評価には別の工程が残る。IBIB では実行する課題と評価契約があらかじめ定義されている。実際のソフトウェア開発では、利用可能な環境がそろっていても、どのファイルを調べ、どこがボトルネックで、何を変更すべきかまで与えられるとは限らない。次に評価対象へ戻るのは、実行系の中で調査、計測、仮説形成、修正を繰り返す工程である。

5. 実務では修正箇所も手順も与えられない

仕様が確定し、利用する実行系も決まった後も、実務では修正箇所の探索が必要になる。性能劣化を調べる作業では、最初に現象を再現し、どの処理が時間を消費しているかを測り、変更候補を絞る必要がある。修正後に処理時間が短くなっても、その差が変更によるものか、キャッシュ、負荷、入力条件、測定揺らぎによるものかを比較しなければならない。期待した改善が出なかった場合も、その結果を最初の仮説の妥当性を更新する観測として次の判断に使える。

この種の仕事では、最終的なコード生成だけを評価しても工程全体の能力は分からない。どこを調べるか、何を測るか、どの結果を原因候補とみなすか、どの変更を試すか、改善が再現するかをどの条件で確認するかまでが作業に含まれる。局所的な実装能力が高くても、最初の原因特定を誤れば、その後の実装能力は誤った箇所の最適化に使われる。長期作業では、各段階の判断が次の入力条件を作るため、一回の誤判断が後続工程へ伝播する。

Φ-Bench は、LLM を支える基盤ソフトウェアの工学作業を、この長い工程ごと評価するために構成された[17]。対象は 85 件で、Kernel Function Completion、Long-Horizon Implementation、End-to-End Optimization の三種類に分かれる。この分類では、難易度と、評価側があらかじめ与える情報量の両方を段階的に変え、その分だけ、調査、判断、計測、変更方針の決定をエージェント側へ移している。

Φ-Bench の課題 評価側から与えられるもの エージェント側で決めるもの 新たに必要になる工程 課題数
KFC 対象関数、インターフェース、入出力の意味が指定される。 関数内部をどのように正しく効率的に実装するかを決める。 局所的な実装と性能改善を行う。 55 件である。
LHI 実現すべき機能と大まかな変更範囲が指定される。 関連ファイル、依存関係、実装経路、具体的な変更方法を調査して決める。 複数ファイルを読み、長い実装工程を維持する。 20 件である。
E2EO 処理負荷、最適化目標、制約が指定される。 ボトルネック、変更対象、最適化戦略、複数層にまたがる変更を決める。 計測、原因仮説、変更、再計測を反復する。 10 件である。

KFC では、評価側が変更対象まで絞り込んでいる。エージェントが主に担うのは、その関数内部を正しく高速に実装する仕事である。LHI になると、実現すべき機能は示されても、どのファイルを読み、どの依存関係を変更し、どの順序で実装するかは自分で決めなければならない。E2EO ではさらに、変更すべき箇所そのものが確定していない。最適化目標に対して現状を測り、ボトルネックを推定し、修正候補を選び、その効果を再び測定する必要がある。

三種類を並べると、評価側が肩代わりする工程が減るほど、エージェントの仕事がコード生成から工学的な意思決定へ広がることが分かる。KFC では「どこを直すか」が与えられる。LHI では「どのように実装するか」を調査する。E2EO では「そもそもどこを直すべきか」から判断する。この差によって、最終成果物が同じコードであっても、そのコードへ到達するまでに要求される能力は大きく異なる。

長期工程を評価対象へ含める動きは、ほかの評価にも現れている。RE-Bench は 7 種類の開放型機械学習研究工学環境を用意し、人間の専門家と AI エージェントを異なる時間予算の下で比較した[18]。MLE-bench は Kaggle の 75 競技を基に、データ準備、モデル訓練、実験、結果改善までを含む機械学習工学を評価した[19]。SWE-Lancer は Upwork に由来する 1,400 件超の実務ソフトウェア開発課題を使い、課題を実際の報酬額と対応させた[20]。

評価軸そのものにも変化がある。長期タスク能力の研究では、人間がある仕事を完了するまでに必要な時間と、AI がその仕事を成功させる確率を対応させる「50% task-completion time horizon」が導入された[21]。一問ごとの正解率に、人間ならどれだけの時間を要する規模の仕事まで一定確率で完了できるかという時間軸を加える考え方である。TheAgentCompany は、仮想的なソフトウェア企業の中で、Web 操作、コード作成、プログラム実行、同僚との通信をまたぐ業務課題を扱い、複数の道具と環境を横断して仕事を完了する能力を評価した[22]。

評価 対象となる仕事 単発評価から追加された要素 主に見える能力
RE-Bench 開放型の機械学習研究工学を扱う。 時間予算の中で試行を継続する条件が加わる。 限られた時間内で研究工学上の成果を積み上げる能力が見える。
MLE-bench 機械学習競技を一連の工学作業として扱う。 データ準備、訓練、実験、改善を連続して行う。 複数工程を維持しながらモデル性能を改善する能力が見える。
SWE-Lancer 実務由来のソフトウェア開発課題を扱う。 実際の開発案件に近い規模と成果条件が加わる。 コード生成を実務上の仕事完了へ接続する能力が見える。
長期タスク時間軸 人間の作業時間で規模を表せるさまざまな課題を扱う。 正解率に加えて、完遂可能な仕事の時間規模を測る。 仕事が長くなるにつれて成功率がどう変化するかを見られる。
TheAgentCompany 仮想企業内の複数種類の業務を扱う。 Web、コード、実行環境、他者との通信を横断する。 異なる環境と道具をまたいで仕事を進める能力が見える。
Φ-Bench LLM 基盤ソフトウェアの実装と最適化を扱う。 局所実装からボトルネック探索までを同一領域で段階化する。 変更場所が既知の場合と未知の場合で、工学能力がどう変化するかを比較できる。

この中で Φ-Bench の特徴は、同じ基盤ソフトウェア開発という領域の中で、局所的な関数実装から変更場所そのものを探す全体最適化までを連続した課題形式として並べた点にある。対象分野を変えずに、評価側から与える情報量と、エージェント自身が判断する範囲を変えているため、局所実装能力と長期的な工学能力を同じ文脈で比較しやすい。

総合得点では、Claude Opus 5 が 36.53%、Kimi K3 が 28.12%、Qwen3.8 Max が 27.73%、GPT-5.6-Sol が 24.51% だった。この順位の解釈には評価条件も必要である。Φ-Bench では全課題に 8 CPU コア、32 GiB のメモリー、NVIDIA H20 1 基が割り当てられる。KFC は 1 回の提出で評価されるのに対し、LHI と E2EO では最大 16 回まで提出でき、その中の最良結果が得点として採用される。GPT-5.6-Sol は Codex、それ以外のモデルは Claude Code を足場として利用している。

評価条件 Φ-Bench での設定 得点を読むときの意味
計算資源 各課題に 8 CPU コア、32 GiB のメモリー、NVIDIA H20 1 基を割り当てる。 得点はこの計算環境の下で観測された結果であり、異なる資源条件で同じ性能になるとは限らない。
KFC の試行 1 回の提出で評価する。 局所実装では最初の提出結果が直接得点へ反映される。
LHI と E2EO の試行 最大 16 回まで提出でき、最良結果を採用する。 一回の生成能力だけでなく、再試行によって改善結果へ到達する能力も得点に含まれる。
足場 GPT-5.6-Sol は Codex、それ以外のモデルは Claude Code を利用する。 観測された差には、モデルだけでなくエージェント実行環境の差が含まれる可能性がある。

この条件差により、総合得点はモデル一般の能力順位というより、各評価構成で観測された到達性能を表す。とくに LHI と E2EO の最良結果は、一回目の生成結果ではなく、最大 16 回の試行から到達した最良状態である。同じ 30 点でも、一度の実装で到達した場合と、複数回の失敗を経て到達した場合では、能力の構成が異なる。また足場が統一されていないため、モデルの判断能力と、それを実行へ結び付けるエージェント環境の効果も完全には分離されていない。

長期課題では、反復そのものが評価対象になる。E2EO で求められる仕事そのものが、計測、仮説形成、変更、再計測の繰り返しだからである。一回目で最適な変更を当てる能力だけを測れば、実際の性能最適化で必要になる「観測結果に応じて判断を変える能力」が評価から消える。最大 16 回という条件は得点の解釈に必要な制約であると同時に、長期工学作業を評価対象へ含めるための実験条件でもある。

実務の性能改善では、典型的に次のような循環が生じる。最初に現象を測り、遅い箇所について仮説を立てる。次に変更を実装して再計測する。改善しなければ仮説または実装を見直し、改善した場合でも条件を変えて再現性を確認する。各段階の出力が次の段階の入力になるため、最終成果だけでは、どの判断が適切で、どこで探索が停滞したかを確認できない。

工程 判断する内容 失敗した場合 次の工程への影響
計測 どの現象をどの条件で測るかを決める。 測定対象や条件が不適切なら、原因候補を誤る。 誤った観測値を基に仮説を立てることになる。
原因仮説 観測結果からどこがボトルネックかを推定する。 原因を誤認すると、効果のない箇所を変更する。 実装能力が高くても改善につながらない。
変更 原因仮説を検証できる変更方法を選ぶ。 変更が原因へ作用しなければ、仮説を検証できない。 再計測から得られる情報量も減る。
再計測 変更前後を比較可能な条件で測定する。 キャッシュや負荷などの条件差を変更効果と誤認する。 効果のない変更を成功として固定する可能性がある。
方針更新 観測結果から継続、撤回、別案への移行を決める。 失敗結果から方針を更新できなければ、同じ探索を繰り返す。 長期工程全体の時間と試行回数を消費する。

長期工程では、失敗も能力評価の材料になる。一回の変更で改善が出なくても、その結果から最初の仮説を棄却し、別の原因候補へ移れるなら、失敗した試行が探索空間を狭めている。反対に、同じ種類の変更を根拠なく繰り返したり、計測条件の違いを改善と誤認したりすれば、最終的に動くコードを生成できる能力があっても、工学工程の安定性は低い。

ここまで評価対象を広げると、評価対象は一回の生成結果から、局所的な実装能力、関連箇所を探索する能力、測定条件を管理する能力、結果から原因仮説を更新する能力、限られた試行回数の中で方針を修正する能力へ広がる。これらが連続して仕事を構成する。Φ-Bench が測定対象へ戻したのは、最終的なコードと、そのコードへ至る途中で人間のエンジニアが通常行っている調査と判断である。

第 3 章では、実装前に仕様が十分かを発見する能力を見た。第 4 章では、同じモデル名でも実際の提供条件によって観測される能力が変わり得ることを見た。本章では、仕様と実行系が確定した後にも、変更場所の探索、計測、仮説形成、反復という工程が残ることが分かる。この三つを並べると、別々の研究が共通して、従来のベンチマークで評価側が固定していた条件を AI 側の仕事として測定対象へ戻している構造が見えてくる。

6. 三つの研究が評価対象へ戻したもの

IdeaAMBIG、IBIB、Φ-Bench は、同じ能力を測定した研究ではない。IdeaAMBIG は研究アイデアを実装するための仕様が十分か、その不足を LLM 自身が発見できるかを扱う。IBIB は企業向け AI システムについて、宣伝上のモデル識別子を越えて、実際に要求を処理する配信経路や評価契約を含む実行系を扱う。Φ-Bench は LLM 基盤ソフトウェアを対象に、局所的な関数実装から、計測してボトルネックを探し、変更を反復する全体最適化までを評価する。研究対象、課題形式、評価指標が異なるため、三論文の得点の横並びは共通尺度の総合順位にはならない。

三つを評価設計の側から見ると、共通する変化がある。従来のベンチマークでは、比較を成立させるために多くの条件を評価側があらかじめ固定してきた。実装に必要な情報は問題文に含まれている。指定したモデルは要求する機能を同じように利用できる。修正対象や達成条件は課題として与えられる。こうした前提を固定すれば、残った部分だけを比較しやすい。実務では、その固定条件自体も変動する。三研究は、それまで評価の外側に置かれていた異なる条件を、それぞれ測定対象へ戻している。

研究 主な研究対象 従来は前提になりやすかった条件 評価対象へ戻したもの 分離できる失敗
IdeaAMBIG 研究アイデアから実装へ進む際の仕様充足性を扱う。 問題仕様には、意図した実装を一意に決めるための情報が含まれている。 仕様が実装可能な状態か、不足箇所を自力で発見できるかを測る。 実装能力の不足と、仕様不足を認識できなかった失敗を分けられる。
IBIB 企業向け AI システムの実際の提供条件を扱う。 同じモデル識別子を指定すれば、同じ能力を利用しているとみなせる。 配信経路、精度、入出力契約、利用可能な機能、評価ハーネスを含む実行系を測る。 モデルの課題遂行失敗と、提供条件によって要求を実行できなかった失敗を分けて記録できる。
Φ-Bench LLM 基盤ソフトウェアの実装と性能最適化を扱う。 修正対象、ボトルネック、実装経路は課題側から十分に与えられる。 調査、計測、ボトルネック発見、仮説形成、変更、再計測、反復までを測る。 局所的な実装失敗と、探索、計測、方針更新を含む長期工程の失敗を分けて考えられる。

三研究の違いは、仕事の異なる位置に対応している。IdeaAMBIG が扱うのは、実行を始める前の段階である。何を実装するかを決めるための情報が足りているかを確認する。IBIB が扱うのは、その仕事を実際の AI システムへ渡す段階である。仕様上は実行可能でも、利用する配信経路が必要な入力、出力、ツール、精度条件を満たさなければ、仕事は同じ条件では実行されない。Φ-Bench が扱うのは、実行系の中で仕事を進める段階である。変更対象が未確定なら、環境を観測し、原因候補を絞り、変更を試し、結果から次の判断を更新しなければならない。

この三つを時系列に並べると、AI の仕事は複数の条件が順番に成立して初めて完了する工程として見えてくる。

段階 成立させる条件 対応する研究 条件が崩れた場合
仕事を定義する 目的、制約、必要情報が、実装または操作を決められる程度まで確定している。 IdeaAMBIG が仕様不足の認識を評価する。 不足情報を暗黙の仮定で補い、意図とは異なる仕事を正確に実行する可能性がある。
仕事を実行系へ渡す 利用する配信経路が、要求された入力、出力、ツール、その他の契約を処理できる。 IBIB がモデル識別子の背後にある実行系を評価する。 モデルが能力を持っていても、利用経路の制約によって仕事を実行できない。
対象を調査する 現状を観測し、変更すべき箇所や原因候補を特定する。 Φ-Bench の LHI や E2EO が探索工程を含めて評価する。 誤った箇所を選ぶと、その後の高い実装能力が改善へ結び付かない。
変更して検証する 実装結果を測定し、変更前後を比較できる。 Φ-Bench が計測と反復を評価へ含める。 測定条件を誤れば、無効な変更を改善として採用する可能性がある。
結果を判定する 評価器が、仕事で要求される性質を十分に観測している。 三研究すべての得点を解釈する前提になる。 測定していない性質まで「正しい」「実務で使える」と一般化する可能性がある。

この工程では、前段の出力が後段の入力になる。仕様不足を見落とせば、誤った前提が実行系へ渡る。配信経路が必要な機能を提供できなければ、適切に定義された仕事でも途中で失敗する。実行可能な環境がそろっていても、探索段階で原因箇所を誤れば、変更は目的へ作用しない。変更後の測定が不適切なら、改善していない結果を成功と判断することもある。最終成果だけを見ると、これらはすべて「成功した」「失敗した」という一つの結果に畳み込まれるが、必要な対処は段階ごとに異なる。

たとえば IdeaAMBIG で不足情報を発見できなかった失敗では、改善対象はコード生成性能より仕様診断にある。IBIB が扱う配信経路の能力制約には、提供系そのものへの対応が必要になる。Φ-Bench でボトルネック探索を誤っている場合には、局所的な関数生成の正解率より、変更対象を選ぶ工程が改善対象になる。評価段階を分離する意味は、能力を細かく分類することより、失敗の発生場所と改善対象を対応させられる点にある。

観測された失敗 モデル単体の得点だけで見た場合 工程を分離して見た場合 主な改善対象
不足した仕様のまま誤った実装へ進んだ 最終実装の不正解として集計される。 仕様不足を発見する段階で失敗したと切り分けられる。 不足検出、確認行動、仕様確定工程を改善する。
必要な機能を配信経路から利用できなかった モデルが課題を完了できなかったように見える。 モデル能力と提供系の能力制約を分離して記録できる。 配信経路、API 契約、利用構成を見直す。
変更対象を誤り、改善へ到達しなかった 最終成果の失敗として集計される。 実装より前の探索や原因仮説に失敗した可能性を調べられる。 観測方法、探索戦略、仮説更新を改善する。
テストは通ったが要求した性質を満たしていなかった 評価器上は成功として扱われる可能性がある。 評価器が測定した条件と、本来の要求との差として切り分けられる。 受入条件と評価方法を見直す。

既稿では、AI がテストを通したときに保証できる範囲は、そのテストが表現した要求までであると整理した[23]。テストが確認するのは、評価器に記述された条件を満たしたことであり、評価器の外側に残った性質には別の検証が必要になる。三研究を合わせると、この境界は評価器の後ろから仕事を開始する前まで、工程全体に連続して存在することが分かる。

仕様では、何を要求しているかが十分に定義されている必要がある。実行系では、その要求を実際に処理できる提供条件が必要になる。実行中には、観測結果から次の行動を決める能力が必要になる。最後に評価器が、得られた成果が要求した性質を満たしているかを観測する。このどの段階でも、暗黙の前提を評価の外側へ置けば、その前提についての能力は得点から消える。

ここから、ベンチマークの発展を別の軸で整理できる。評価の高度化には、問題数や問題自体の難しさと並んで、従来は評価側が成立させていた条件を一つずつ AI 側へ移し、その条件を自力で成立させられるかまで測るという変化がある。これによって、評価境界が仕事全体へ向かって広がっている。

評価境界 評価側が肩代わりするもの AI 側へ移すと新たに測れるもの
狭い評価 仕様、対象箇所、実行環境、利用機能、評価方法をほぼ固定する。 固定条件の下での回答生成や局所実装を精密に比較できる。
環境を含む評価 目的と利用環境を用意し、操作方法の一部を AI 側へ渡す。 探索、状態認識、複数操作の継続を測れる。
仕事の成立条件を含む評価 最終目的と最低限の制約を残し、仕様診断、提供条件、探索、反復まで評価対象へ入れる。 仕事が成立するまでの条件を AI がどこまで自力で処理できるかを測れる。

評価境界を広げるほど、最終得点には複数の能力と環境差が混ざる。IdeaAMBIG が仕様判定、不足箇所特定、確認行動を分けたこと、IBIB が実行前、実行時、実行後を分離したこと、Φ-Bench が KFC、LHI、E2EO を分けたことには同じ理由がある。仕事全体へ近づけるほど、最終成功率と、どの段階で差が生じたかを追跡できる診断情報の両方が必要になる。

実務能力の評価には、仕事全体の完遂率を測る総合評価と、仕様、提供系、探索、実装、検証を切り分ける診断的な評価の両方が必要になる。総合評価は仕事全体の成果を示し、診断評価は失敗原因を切り分ける。両者を対応させることで、各能力を組み合わせたときの完遂率と、改善すべき工程を同時に追跡できる。

IdeaAMBIG、IBIB、Φ-Bench が示す能力はそれぞれ異なる。三研究をつないで見えるのは、AI の評価単位そのものの変化である。仕様が確定していること、モデルへ必要な機能が提供されること、修正対象を見つけられること、反復によって改善へ到達できることを評価の外側の前提から測定対象へ取り込む。この変化によって、最終得点は単なるモデルの順位から、どの条件まで AI が仕事として担えたかを表す値へ近づいていく。

そのとき、評価で記録すべき単位も変わる。モデル名だけでは、仕様がどう与えられ、どの配信経路を通り、どの足場と実行環境を使い、何回の試行が許され、何を成功として採点したかが残らない。三研究から導かれる次の課題は、これらを仕事が成立する一つの系として記録しながら、それぞれの失敗を切り分けられる評価単位を設計することである。

7. AI の評価単位を仕事が成立する系へ広げる

仕事全体を一つの得点で表すことには明確な利点がある。同じ課題集合を複数のモデルやエージェントへ与えれば、どの構成が多くの仕事を完了したかを一つの尺度で比較できる。モデル更新の前後で得点を追えば、全体として改善したかどうかも確認しやすい。利用者が複数候補から選択するときにも、総合得点は最初の比較材料になる。

実務で次の行動を決めるには、総合得点に失敗診断を重ねる必要がある。あるシステムが 60% の仕事を完了し、40% で失敗したとしても、その失敗原因は一種類とは限らない。要求自体が曖昧だった可能性、利用した配信経路が必要なツール呼び出しを提供していなかった可能性、対象リポジトリの探索に失敗した可能性、実装は正しくても評価器が必要な性質を確認できていなかった可能性がある。すべてを「40% 失敗」とだけ記録すると、次に変更すべき対象が分からない。

第 3 章から第 6 章までで見てきた違いを実際の評価へ反映するなら、最終得点と同時に、その得点を成立させた条件を記録する必要がある。少なくとも、仕様、モデル、配信経路、足場、実行環境、反復条件、評価器は分離した方がよい。

構成要素 記録すべき内容 記録しない場合に混同するもの 失敗時に見直す対象
仕様 達成条件、入力、制約、許容される変更、未確定事項を記録する。 仕事を解けなかったのか、仕事自体が一意に定まっていなかったのかを区別できない。 要求定義、確認事項、仕様確定手順を見直す。
モデル モデル系列、改訂版、推論設定など、モデル能力に直接関係する条件を記録する。 異なるモデルや設定によって生じた能力差を追跡できない。 モデル選択や推論設定を見直す。
配信経路 API、精度、入出力上限、ツール契約、構造化出力などの提供条件を記録する。 モデル自身の能力と、利用経路によって課された制約を混同する。 利用 API、配信方式、利用可能な機能を見直す。
足場 エージェント実装、利用可能なツール、プロンプト構成、文脈管理方法を記録する。 モデルの差と、モデルを仕事へ接続するエージェント実装の差を混同する。 ツール構成、文脈管理、エージェント制御を見直す。
実行環境 OS、CPU、GPU、メモリー、依存ソフトウェア、外部接続条件などを記録する。 環境依存の成功や失敗をモデル固有の性質へ帰属する。 資源配分、依存関係、実行条件を見直す。
反復条件 時間予算、試行回数、再提出条件、途中で利用できる観測情報を記録する。 一回で生成する能力と、失敗から修正して最終状態へ到達する能力を同じものとして扱う。 試行回数、観測方法、方針更新、停止条件を見直す。
評価器 成功条件、失敗の扱い、テスト、性能測定方法、集計方法を記録する。 評価器が確認した性質と、実際の業務で要求している性質を混同する。 受入条件、テスト、評価指標、集計規則を見直す。

この表の目的は、同じ「失敗」という最終結果から、異なる改善行動を導けるようにすることである。仕様不足なら、より高性能なモデルへ交換する前に要求を確定する必要がある。配信経路が必要な機能を提供していないなら、プロンプトを改善しても実行可能にはならない。原因探索が停滞しているなら、コード生成の正解率より、観測方法や反復戦略を見直す方が直接的である。評価器が要求を十分に表していないなら、モデル側を変更しても測定上の問題は残る。

この意味で、総合得点と詳細な構成記録には別々の役割がある。総合得点は「仕事全体としてどれだけ完了できたか」を比較する。構成記録は「なぜその結果になったか」を調べる。両者を組み合わせることで、実務で必要な比較と原因診断をつなげられる。

評価方法 主に答えられる問い 利点 単独で使った場合の限界
総合評価 最終的にどの構成が多くの仕事を完了したかを確認する。 複数候補を同じ尺度で比較でき、全体的な改善も追跡しやすい。 どの工程や条件が成功率を下げたかを特定しにくい。
診断評価 仕様、提供系、探索、実装、検証のどこで失敗したかを確認する。 失敗原因と改善対象を対応させられる。 個別能力が高くても、組み合わせた仕事全体を完了できるとは限らない。
総合評価と診断評価の併用 どれだけ仕事を完了し、その結果がどの条件によって成立したかを確認する。 候補比較と原因分析を同じ評価結果から行える。 記録する条件が増えるため、評価設計と再現条件の管理が必要になる。

総合得点は、実利用上の比較指標として残せる。たとえば二つのエージェント構成について、同じ 100 件の仕事を与え、一方が 70 件、もう一方が 60 件を完了したなら、70% と 60% という差には利用上の意味がある。改善を進める段階では、その 10 ポイントの差がどこから生じたかを調べる必要がある。一方は仕様不足を適切に検出して停止し、もう一方は暗黙の仮定で誤実装へ進んだのかもしれない。利用できるツールが異なっていた可能性もある。許された試行回数が異なれば、長期課題では最終成功率も変化する。

ここで必要なのは、総合結果から失敗事例へ戻り、その失敗がどの条件で発生したかを追跡できる構造である。すべての構成要素について順位表を作れば、多数の数字が並ぶだけになる。評価結果が診断可能であれば、最終的な成功率を維持したまま、その原因を工程単位で調べられる。

たとえば、同じ最終的な「不正解」でも、原因と対処は次のように変わる。

観測された結果 実際の失敗原因 誤った改善 必要な改善
要求と異なるコードを生成した 必要な仕様が欠けていたが、その不足を認識できなかった。 コード生成能力だけを高める。 仕様不足の検出と確認工程を改善する。
課題を最後まで実行できなかった 配信経路が必要なツールや入出力契約を提供していなかった。 モデルへ追加の推論時間を与える。 提供経路や利用構成を変更する。
修正しても性能が改善しなかった ボトルネックの特定を誤っていた。 選択した箇所の実装品質だけをさらに高める。 計測方法と原因探索を見直す。
評価上は成功したが実務要件を満たさなかった 評価器が要求する性質を十分に測っていなかった。 成功済みのモデルや実装を変更する。 受入条件と評価器を修正する。

この違いを記録しなければ、モデル改善が必要でない問題までモデル側へ帰属することになる。逆に、モデル能力そのものが不足している場合に、周辺のツールやプロンプトだけを変更し続ける可能性もある。評価の粒度は、原因に対応する改善手段を選べる程度まで細かくする必要がある。

既稿では、モダナイゼーションの正しさについて、保存すると定めた性質には旧システムとの必要な関係を求め、変更すると定めた性質には新しい受入条件を求め、それぞれを別の証拠で検証する必要があると整理した[24]。ソースコード、アーキテクチャー、性能、認証方式がすべて異なる新旧システムでは、正しさを複数の性質と関係に分けて定義する必要がある。

AI の評価にも同じ構造がある。「このモデルは賢いか」「このエージェントは実務で使えるか」という一つの問いへ還元すると、仕様を扱う能力、生成能力、提供系の制約、長期探索、評価方法が同じ判断へ混ざる。代わりに、どの条件について何が成立したかを分ければ、「仕様は十分だった」「必要なツールは利用できた」「探索には失敗した」「実装後のテストは通った」といった証拠を別々に残せる。その組み合わせとして最終的な仕事の成功を評価できる。

ここで、仕事が成立する「系」という単位が必要になる。系の中心にはモデルがあるが、その前には仕様があり、モデルへ到達する配信経路があり、モデルを操作へ接続する足場があり、実際に処理する環境がある。作業中には反復条件が働き、最後には評価器が成果を判定する。いずれか一つを変えれば、同じモデルでも観測される結果は変わり得る。

仕事の位置 主な構成要素 成立を確認する問い
実行前 仕様 仕事を一意に決めるための情報と制約がそろっているか。
利用条件 モデル、配信経路、足場 要求した能力を、この構成から実際に利用できるか。
実行中 実行環境、反復条件 必要な観測と操作を行い、結果から次の判断へ進めるか。
実行後 評価器 要求した性質を、定義した成功条件によって確認できたか。
全体 各構成要素と最終成果 どの条件が成立した結果として仕事を完了できたかを追跡できるか。

この単位でもモデル比較は有効である。比較したい変数がモデルであるなら、仕様、配信経路、足場、環境、反復条件、評価器をそろえ、モデルだけを変えればよい。その条件下では、得点差をモデル差へ帰属しやすくなる。配信方式を比較したいならモデルを固定し、配信経路を変える。長期反復の効果を調べたいなら、モデルと環境を固定して試行条件を変える。何を固定し、何を変えた評価なのかを明示することで、得点の意味が定まる。

実務では、全構成が同時に変動する場合も多い。利用できるモデルごとに API の仕様が違い、エージェント用の足場も異なり、必要な計算資源も変わる。その場合には、「モデル A とモデル B の純粋な能力差」と無理に解釈するより、「構成 A と構成 B を実際に利用したときの仕事完了率」として測る方が正確である。そのうえで、個別の失敗を診断評価へ戻し、モデル、提供系、探索、評価器のどこに差があったかを調べる。

AI の評価単位を仕事が成立する系へ広げるとは、総合得点で最終成果を比較しながら、その数字を生んだ条件へ戻れるようにすることである。これによって、得点は「どのモデルが上か」という順位と、「どの条件をそろえれば、この能力を再現できるか」という再現条件の両方を判断する情報になる。

8. 点数より先に評価契約を読む

AI ベンチマークを見るとき、最初に確認すべきなのは、最高得点のモデル名より、その得点がどの条件の下で成立したかである。同じ 80 点でも、必要な情報、利用可能なツール、試行回数、実行環境、失敗の集計方法が異なれば、測っている能力の範囲も異なる。順位表の数字だけを比較すると、この違いが一つの尺度へ畳み込まれる。

評価契約とは、モデルやエージェントへ何を与え、何を利用可能とし、どの条件で実行させ、どの状態を成功または失敗として数えるかを定めた組み合わせである。ベンチマークの得点は、この契約を通して初めて意味を持つ。評価契約を確認せずに得点だけを別の業務へ当てはめると、実際には評価されていない能力まで、そのモデルが持っていると解釈することになる。

確認する問い 確認する内容 確認しない場合に起こる誤読
何が最初から与えられていたか 仕様、必要情報、対象リポジトリ、修正箇所、達成条件など、評価側が事前に確定した情報を確認する。 評価側が解決済みだった問題まで、AI 自身が発見または判断した能力として扱ってしまう。
何を利用できたか Web、ツール、コード実行、画像入力、外部データ、データベースなど、課題中に利用可能だった機能を確認する。 異なる道具を使った結果を、モデル内部の能力差だけとして比較してしまう。
どの実行系を使ったか モデル系列だけでなく、配信経路、精度、入出力契約、足場、実行環境を確認する。 同じモデル名なら同じ条件で能力が観測されたとみなしてしまう。
何回試せたか 一回だけ回答したのか、失敗結果を観測して複数回修正できたのか、最良結果を採用したのかを確認する。 一回で正解する能力と、反復によって最終成果へ到達する能力を同じものとして扱ってしまう。
何を失敗として数えたか 拒否、タイムアウト、形式不正、ツール失敗、途中終了を分母へ含めたかを確認する。 成功した応答だけを見た精度を、実際の仕事完了率として読んでしまう。
評価器は何を観測したか テスト合格、処理速度、最終状態、採点モデルなど、成功判定に使った観測対象を確認する。 評価器が確認していない品質、互換性、安全性、要求充足まで得点が保証していると解釈してしまう。

この確認順序は、第 3 章から第 5 章で見てきた研究と対応している。IdeaAMBIG では、最初から与えられた仕様が十分かどうか自体を評価対象へ戻した。IBIB では、モデル名だけでは見えない配信経路や入出力契約を測定対象へ戻した。Φ-Bench では、修正対象を探し、計測し、仮説を立て、変更し、再び測る長期工程を評価対象へ戻した。三研究が対象としている位置は異なるが、共通しているのは、従来なら評価側が成立させていた条件を AI 側の仕事へ移している点である。

研究 評価前には固定されやすかったもの 新たに確認すべき評価契約 得点を読むときの注意点
IdeaAMBIG 実装に必要な仕様は問題文へ十分に含まれている。 不足情報を自力で発見する必要があるか、不足箇所があらかじめ示されているかを確認する。 仕様不足の発見能力と、不足を与えられた後の実装能力を分けて読む必要がある。
IBIB モデル識別子が同じなら同じ能力を利用しているとみなせる。 どの配信経路、精度、ツール契約、評価ハーネスを使ったかを確認する。 構成全体の得点差を、モデルや配信経路の単独の因果効果へ帰属させない。
Φ-Bench 修正対象や実装経路が評価側から十分に与えられる。 どこまで探索が必要か、何回試行できるか、どの足場と計算資源を使ったかを確認する。 局所実装能力と、長期反復による到達能力を同一の尺度として読まない。

同じ得点でも、評価契約が違えば意味は変わる。たとえば、修正対象を指定された状態で一回の提出から得た 60 点と、修正対象を自分で探索し、最大 16 回の試行から最良結果を採用して得た 60 点では、評価された工程が異なる。前者では局所的な実装能力が中心となり、後者では探索、観測、方針更新、再試行まで含めた到達能力が得点へ入る。数字が一致していても、60 点が表す能力の範囲は変わる。

異なる得点でも、比較条件が異なれば、その差はモデルと評価条件の複合差になる。モデル A が 75 点、モデル B が 70 点だったとして、A だけが外部検索を利用でき、B は利用できなかったなら、5 ポイントの差にはツール条件も含まれる。A が最大 16 回まで試行でき、B が一回だけなら、反復条件も異なる。失敗応答を A では分母から除外し、B では含めていれば、得点定義そのものが異なる。

見えている数字 評価契約 読めること そのままでは読めないこと
同じ 60 点 一方は対象箇所指定、もう一方は探索から開始する。 それぞれの契約内で 60% 相当の達成結果だったことを確認できる。 同じ能力が同じ水準だったとは言えない。
75 点と 70 点 利用可能なツールや外部情報が異なる。 各構成全体では 5 ポイントの差が観測された。 5 ポイントすべてをモデル内部の能力差とはみなせない。
80 点と 72 点 一方は複数回試行の最良値、もう一方は一回だけ評価する。 それぞれの試行条件での最終到達結果を比較できる。 一回の生成能力の差として比較することはできない。
90% のテスト合格 評価器が機能テストだけを実行する。 用意された機能テストの 90% を満たしたことを確認できる。 性能、セキュリティー、互換性など未評価の性質まで 90% 満たしたとは言えない。

評価契約を読む目的は、得点が有効な範囲を明確にすることである。MMLU のように問題と正解を固定した評価なら、同じ条件で多数のモデルを比較できる。SWE-bench のように実際のリポジトリを含めれば、コード生成、リポジトリ調査、修正まで評価できる。Φ-Bench のように反復を許せば、失敗から方針を修正して最終成果へ到達する能力を含められる。評価境界をどこに置いたかによって、得点から読み取れる能力の範囲が決まる。

そのため、ベンチマークを実務へ持ち込む際には、業務側の条件と評価契約を対応させる必要がある。実際の仕事で仕様不足が頻繁に起こるなら、仕様不足を含む評価が必要になる。企業環境で特定の API やツール経路を利用するなら、その提供条件を含む評価が必要になる。数時間にわたって試行錯誤する仕事なら、長期反復を含む評価の方が近い。

実務上の条件 対応して確認すべき評価条件 一致しない場合のリスク
要求が不完全な状態から作業を始める 仕様不足や曖昧さを発見する工程が評価に含まれているかを確認する。 完全な問題文だけで得た高得点を、仕様診断能力まで含むと誤認する。
特定の企業向け API や配信経路を利用する 実際に利用する経路、入力形式、ツール契約に近い条件で評価されているかを確認する。 別の提供系で観測された能力を、自社環境でもそのまま利用できると誤認する。
複数回の調査と修正を前提とする 途中結果の観測、再試行、方針更新が許されているかを確認する。 単発の生成能力だけから、長期作業の完遂能力を推定する。
機能以外の制約も要求する 性能、互換性、安全性など必要な性質が評価器へ含まれているかを確認する。 限定されたテスト合格を、業務上の受入条件全体の充足として扱う。

AI の性能が向上するほど、こうした確認の重要性はむしろ大きくなる。単純な生成課題を多くのモデルが解けるようになれば、実務上の差は、何を作るべきかを確定できるか、必要な機能を実行系から利用できるか、長い工程で観測と修正を続けられるかといった周辺条件へ移る。生成能力が高いモデルほど、仕様不足のまま高速に誤った実装へ進むこともあり得るため、前提条件を管理する重要性も高まる。

IdeaAMBIG、IBIB、Φ-Bench の三研究は、この変化を別々の位置から捉えている。IdeaAMBIG は「何を実装すべきかが十分に決まっているか」を測った。IBIB は「その能力をどの提供条件から利用したか」を測定単位へ含めた。Φ-Bench は「実行中に何を調べ、どこを直し、どう再試行するか」を評価した。三つをつなぐと、AI の実務能力には、モデルが一回の入力から優れた出力を生成する能力に加え、仕事を成立させる前後の条件を扱う能力が含まれる。

最終的に確認すべきなのは、得点の大小と、その数字を生んだ条件の対応である。何が最初から与えられていたか。何を AI 自身が発見したか。どのモデルと配信経路を使ったか。どの道具と環境を利用できたか。何回まで失敗と修正を繰り返せたか。何を成功として評価したか。これらが明示されて初めて、その得点を別の仕事へ適用できる範囲を判断できる。

AI の実務能力を測る単位は、モデル単体から、仕事が成立する系へ広がっている。性能という数字の意味は、どの仕様、どの提供系、どの実行環境、どの反復条件、どの評価方法の下で生まれたかによって決まる。ベンチマークを読むとは、順位表と、その得点を成立させた評価契約を合わせて読むことである。

参考文献

  1. Dan Hendrycks, Collin Burns, Steven Basart, Andy Zou, Mantas Mazeika, Dawn Song, Jacob Steinhardt, Measuring Massive Multitask Language Understanding (2020). https://arxiv.org/abs/2009.03300
  2. Mark Chen et al., Evaluating Large Language Models Trained on Code (2021). https://arxiv.org/abs/2107.03374
  3. Percy Liang et al., Holistic Evaluation of Language Models (2022). https://arxiv.org/abs/2211.09110
  4. Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik Narasimhan, SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (2024). https://proceedings.iclr.cc/paper_files/paper/2024/hash/edac78c3e300629acfe6cbe9ca88fb84-Abstract-Conference.html
  5. Xiao Liu et al., AgentBench: Evaluating LLMs as Agents (2023). https://arxiv.org/abs/2308.03688
  6. Shuyan Zhou et al., WebArena: A Realistic Web Environment for Building Autonomous Agents (2023). https://arxiv.org/abs/2307.13854
  7. Grégoire Mialon, Clémentine Fourrier, Craig Swift, Thomas Wolf, Yann LeCun, Thomas Scialom, GAIA: a benchmark for General AI Assistants (2023). https://arxiv.org/abs/2311.12983
  8. Tianbao Xie et al., OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments (2024). https://arxiv.org/abs/2404.07972
  9. Odd Erik Gundersen, Sigbjørn Kjensmo, State of the Art: Reproducibility in Artificial Intelligence (2018). https://doi.org/10.1609/aaai.v32i1.11503
  10. Joelle Pineau, Philippe Vincent-Lamarre, Koustuv Sinha, Vincent Larivière, Alina Beygelzimer, Florence d’Alché-Buc, Emily Fox, Hugo Larochelle, Improving Reproducibility in Machine Learning Research (2021). https://jmlr.org/papers/v22/20-303.html
  11. Yiling Ma, Yilun Zhao, Sihong Wu, Manasi Patwardhan, Arman Cohan, IdeaAMBIG: Benchmarking Implementation-Critical Gaps in Research-Idea Specifications (2026). https://arxiv.org/abs/2609.10539v1
  12. id774, AI による大規模開発では、未確定な状態を一件ずつ閉じる（2026-08-15）. https://blog.id774.net/entry/2026/08/15/5503/
  13. Blake Stenstrom, Charangan Vasantharajan, Brian Sathianathan, IBIB: A Protocol for Measuring Enterprise AI Systems by Serving Route, Not Model Identifier (2026). https://arxiv.org/abs/2609.10494v1
  14. MLCommons, MLPerf Inference v5.0 Advances Language Model Capabilities for GenAI (2025). https://mlcommons.org/2025/04/llm-inference-v5/
  15. MLCommons, MLCommons Releases MLPerf Client v1.0: A New Standard for AI PC and Client LLM Benchmarking (2025). https://mlcommons.org/2025/07/mlperf-client-v1-0/
  16. id774, AI モダナイゼーションはなぜ仕様選択と検証で止まるのか（2026-07-29）. https://blog.id774.net/entry/2026/07/29/5158/
  17. Leilei Ding et al., Φ-Bench: Can Large Language Models Engineer the Infrastructure That Powers Them? (2026). https://arxiv.org/abs/2609.10226v1
  18. Hjalmar Wijk et al., RE-Bench: Evaluating frontier AI R&D capabilities of language model agents against human experts (2024). https://arxiv.org/abs/2411.15114
  19. Jun Shern Chan et al., MLE-bench: Evaluating Machine Learning Agents on Machine Learning Engineering (2024). https://arxiv.org/abs/2410.07095
  20. Samuel Miserendino, Michele Wang, Tejal Patwardhan, Johannes Heidecke, SWE-Lancer: Can Frontier LLMs Earn $1 Million from Real-World Freelance Software Engineering? (2025). https://proceedings.mlr.press/v267/miserendino25a.html
  21. Thomas Kwa et al., Measuring AI Ability to Complete Long Tasks (2025). https://arxiv.org/abs/2503.14499
  22. Frank F. Xu et al., TheAgentCompany: Benchmarking LLM Agents on Consequential Real World Tasks (2024). https://arxiv.org/abs/2412.14161
  23. id774, AI がテストを通しても、「正しい」とは限らない（2026-09-01）. https://blog.id774.net/entry/2026/09/01/5534/
  24. id774, モダナイゼーションの「正しい変換」をどう定義するか（2026-09-09）. https://blog.id774.net/entry/2026/09/09/5621/