エージェントが同じ失敗を繰り返すなら、まずモデルを替えるべきでしょうか？
コーディングエージェントがテスト失敗を直したのに、また元に戻してしまいます。リサーチエージェントはすでに確認した資料を再び探し、文書エージェントは前に確定した条件を長い作業の終わりには忘れてしまいます。こうした場面が繰り返されると、より強力なモデルを使うことが最も速い解決策に見えます。
しかし失敗の原因が知識や推論能力ではなく、タスク状態の喪失、完了判定の不在、失敗後の復旧ルールの抜けにあるなら、モデルを替えても同じ問題は残ります。NVIDIAのAVOの事例が興味深いのも、Claude Opus 5そのものより、モデルが長い作業を続けられるように周囲を支えるハーネスが前面に出てきたためです。
ただし、タイトルにある約30点と100点を単純な前後の成績として読んではいけません。2つの実行は、ハーネスだけを変えた統制実験ではありません。今回持ち帰るべきなのは「70パーセントポイント上昇」という数字ではなく、エージェントを評価する際にモデルと実行システムを分けて比較する方法です。
30点から100点への統制実験ではありません
AVOは新しい言語モデルではなく、長期の自律作業のためのエージェントシステムです。主エージェントが状況調査、計画、実装、評価を繰り返し、永続メモリが過去の試行と評価結果を次の実行に残します。別の監督役は、探索が停滞したり非生産的な反復に陥ったりしたときに介入します。
Claude Opus 5ベースのAVOは、ARC-AGI-3公開セットの25環境、183レベルをすべて完了し、100.00 RHAEを記録しました。環境で取った行動は6,624回でした。 RHAEはレベルを完了したかどうかと、初回試行の人間基準に対する環境行動の効率の両方を反映します。内部推論やツール呼び出しは、環境状態を変えない限り行動数には含まれません。
NVIDIAが併せて言及した約30%は、ARC Prizeによる別のClaude Opus 5評価です。AVOの実行とは推論設定、エージェントシステム、評価構成が異なっていました。NVIDIAも、この差はAVOだけの寄与を直接測るものではないと明らかにしています。したがって、「ハーネスが正確に70パーセントポイントを生んだ」あるいは「性能を3.3倍にした」と計算することはできません。
100点はAGIの達成や、実務での成功率100%を意味しません。
結果は問題が公開されたセットで得られたものです。ARC Prizeの技術報告書は、公開環境に合わせたハーネスは過学習する可能性があるため、公開セットの点数をAGI進展の有効な測定とは見なさないと説明しています。同時に、そのようなハーネス研究は業務自動化に経済的価値を持ちうると区別して述べています。
ハーネスが管理するのは回答ではなく、作業の継続性です
ハーネスの役割は、モデルに長いプロンプトを与えることにとどまりません。モデル呼び出しの間で何を記憶するか、どのツールを実行するか、誰が結果を判定するか、失敗したときに続けるか止めるかを管理します。
| 繰り返される失敗 | 先に確認するハーネス要素 | 比較する記録 |
|---|---|---|
| すでに行った調査や修正を繰り返す | 目標・確定した事実・過去の試行を残す永続状態 | 重複したツール呼び出しと反復失敗回数 |
| 誤った結果を完了として宣言する | テスト・スキーマ・静的解析などの外部判定器 | 完了宣言後の検証失敗率 |
| 失敗後も同じ戦略だけを繰り返す | 失敗記録と復旧ポリシー | 失敗後の復旧率と人の介入回数 |
| 長い実行で目標を見失う | 進捗と予算を見る監督層 | 目標逸脱、中断時点、完了1件あたりのコスト |
ほかの実験も、ハーネス設定の影響が小さくないことを示しています。OpenAIは、GPT-5.6 Solが公式ハーネスで公開セット13.3%を記録した一方、推論状態の維持とコンテキスト圧縮を併用したResponses APIハーネスでは38.3%を記録し、出力トークンは6分の1になったと報告しました。2つの設定を同時に適用しているため、それぞれの寄与は分けられませんが、同じモデルでも実行状態の扱い方によって結果とコストが変わりうる事例です。
入力表現にも唯一の正解はありませんでした。VISTAは同じClaude Opus 5に512×512のレンダリング画像と再参照できる円形の視覚メモリを用い、公開25環境で100.00を記録しました。行動数は7,542回でした。AVOは64×64のテキストグリッドで6,624回を報告しましたが、バックエンドとメモリ構造が異なるため、この差だけで優劣を判断することはできません。
今日は失敗事例を調整用と保留用に分けてみましょう
最初にすべきことは、新しいマルチエージェントシステムを作ることではありません。過去の実行ログから再現可能な失敗事例を集め、まずハーネスを修正しながら確認する調整用の束と、修正が終わるまで確認しない保留用の束に分けてください。1つの事例を何度も直した後にその事例で再び成功しても、一般化の証拠にはなりません。これは、公開・観察済み環境に合わせたハーネスが初見の環境へ移らない可能性があるというARC Prizeの警告と同じ問題です。
- 業務と判定基準が同じ事例の束を作ります。 決済バグの修正なら、回帰テストの通過、変更ファイル範囲の遵守、重複請求0件のように、すべての事例に適用する完了条件を定めます。ハーネス設計に使う調整用事例と、最終評価にのみ使う保留用事例を分け、どの事例がどちらの束かを記録します。
- 現在の構成を調整用の束でベースラインとして実行します。 モデル、推論設定、入力、ツール権限を固定してください。シードや温度のような変動を制御できるなら、同じ値にそろえます。固定できない場合は、各構成を同じ事例で複数回実行し、1回の成功や失敗が結論を左右しないようにします。
- 分母が見えるベースライン表を作ります。 「完了率60%」だけではなく、「10事例中6件完了」や「5事例を各3回実行して15回中9回完了」のように、課題数と反復回数も残してください。反復失敗、失敗後の復旧、人の介入、モデル呼び出し量、トークン、実行時間、コストも同じ実行単位で記録します。ARC-AGI-3の行動効率には内部推論とツール呼び出しの費用がすべて含まれないため、実務コストは別途測る必要があります。
- 永続状態から1つずつ追加します。 目標、確定した事実、試したアプローチ、評価結果、残った作業を次の実行に渡した後、同じ調整用の束を同一条件で再評価してください。続けて外部判定器、失敗後の復旧ポリシー、監督層を一度に1つずつ追加し、直前の構成と比較します。
- 構成を確定してから、保留用の束を初めて開きます。 調整用事例で最も良かった構成をさらに手直しせず、保留用事例に適用します。ベースラインも同じ保留用の束と実行条件で評価し、完了件数、復旧件数、コストを比較します。保留結果を見て再びハーネスを修正した場合、その事例は調整用になるため、最終確認には新しい保留用の束が必要です。
- 最後にモデルだけを交換します。 確定したハーネス、同じ事例の束、同じ権限と判定基準を維持したままモデルを替えてください。そうすれば、モデル変更の効果とハーネス変更の効果を分けて見られます。
調整用の作業状態は大げさである必要はありません。次のように、判定可能な情報とデータ分割から記録できます。
{
"task_id": "bugfix-017",
"split": "calibration",
"goal": "決済失敗後、重複請求なしで再試行できるよう修正する",
"expected_checks": [
"回帰テストに合格",
"変更ファイル範囲を遵守",
"重複請求0件"
],
"prior_attempts": [],
"budget": {"max_model_calls": 20}
}成功基準には分母と保留結果が必要です。
たとえば調整用の10事例を各3回実行したなら、完了率と復旧率を合計30回中の何回かとして記録してください。ハーネス要素を1つ追加したとき、その比率が良くなり、反復失敗・人の介入・完了1件あたりのトークン・時間・コストもともに改善したかを見ます。最後に、設計過程で確認していない保留用事例でも同じ方向の変化が現れて初めて、次の業務へ広げる根拠が得られます。事例が少ないなら、確定的な改善率の代わりに実行回数と観察結果をそのまま報告してください。
ツールをつないだからといって、長期作業が安全になるわけではありません
長期作業のエラーは、一度の誤答ではなく、蓄積した状態破損として現れることがあります。DELEGATE-52研究は、52の専門分野における長期文書編集で19のLLMを評価し、フロンティアモデルでもタスク終了時には文書内容の平均25%を破損させたと報告しました。ツール使用を追加するだけでは性能は改善せず、文書サイズ、対話の長さ、妨害ファイルが増えるほど破損は大きくなりました。
この結果をコーディングやゲームエージェントのエラー率としてそのまま当てはめることはできません。ただし、実務で確認すべき警告は明確です。ツール呼び出しの成功と業務完了を同じものとして扱ってはいけません。外部判定器が結果を確認し、失敗状態が次の段階に渡る前に復旧または中断できる必要があります。
次のエージェント評価表には、モデル名だけを書かないでください。 使用したメモリ、完了判定器、復旧ポリシー、監督条件、実行予算も併記してこそ、同じシステムを再び比較できます。NVIDIAの100点が示した最も実用的な変化は、最高のモデルの選び方ではなく、評価単位をモデルから実行システム全体へ広げたことにあります。
さらに深く知りたいなら
NVIDIA AVO Reaches 100% on ARC-AGI-3 — AVOの構造、公開セットの結果、約30%のベースラインとの比較限界を併せて確認できます。 developer.nvidia.com
ARC-AGI-3 Scoring Methodology — RHAEが完了と環境行動効率をどう計算し、何をコストに含めないかを確認できます。 docs.arcprize.org
How enabling two settings tripled our scores on the ARC-AGI-3 benchmark — 推論状態の維持とコンテキスト圧縮を併用したとき、スコアと出力トークンがどう変わったかを説明しています。 openai.com
LLMs Corrupt Your Documents When You Delegate — 長期文書作業で破損が蓄積し、ツール接続だけでは解決しない反例を確認できます。 arxiv.org
