AI・信頼性・評価

AIエージェントは長い作業ほど失敗する？崩れ方と防ぎ方

2026/7/28 （更新: 2026/11/3）

🤖 AIを使用して執筆

長いほど崩れ、崩れ方は分野で偏る

1本は、「信頼性の科学」を掲げる枠組みの論文「Beyond pass@1」だ（2026年3月31日公開）¹。著者らはオープンウェイトの10モデル（対象は OpenRouter 経由で呼べるものに限る。GPT-4o や Claude 3.7 のような非公開モデルは対象外で、著者らは「本研究の対象より信頼性は高いだろう」と明記している）を 23,392エピソード・396タスクで回し、タスクの長さを、人が掛かる推定時間で4段階に分けて測った。単発の成功率（pass@1）だけでなく、長さに沿って信頼性がどう減衰するか（減衰カーブ）、ばらつきがどう増幅するか、どこで一気に崩壊するか（メルトダウン開始点）を指標化している。

著者らは、崩れ方が分野ごとに分かれたと報告する。ソフトウェア工学は最も急に崩れ、文書処理はほぼ平坦だ。部分達成も加点する信頼性指標、Graceful Degradation Score（GDS）で見ると、前者は長さとともに 0.90 から 0.44 へ下がり、後者は 0.74 から 0.71 でほぼ動かない¹。ただし著者らは、文書処理が平坦なことを、人の推定時間という長さの尺度の限界の表れだと自ら書いている。著者らの予備調査では、人なら45〜60分かかる文書処理がエージェントには4〜8回のツール呼び出しで済み、同じ人時間のソフトウェア工学は15〜25回を要した¹。

分野ごとの差は、10モデルを集計した姿である。別指標の pass@1 で見ると、長い側の2つの帯のソフトウェア工学でも上位4モデルは 74.7〜82.3% を保っている¹。一方、対象の中でも上位のモデルほど野心的な多段戦略を試み、それが外れて、最も長い帯のタスクでは最大19%が「メルトダウン」（同じツール呼び出しの繰り返しなど、筋の通らない動きへ移ること）に至った、という¹。著者らは、メルトダウンの検出を失敗の判定とは見ず、作業を打ち切る合図にもしないよう書いている¹。

もう1本は独立したグループ（Wang ら）による診断ベンチマーク「HORIZON」の論文で（2026年4月13日公開）、やはりエージェントは長いタスクで大きく劣化する傾向を分野横断で報告している²。たとえば Embodied 分野では、GPT-5 系の成功率が短い帯の 0.926 から、タスクを段階的に長くするにつれ 0.407・0.259・0.074 へ落ちたと著者らは報告する（3回走行の平均±標準偏差のうち平均）。Claude-4 系も同じ分野で 0.963 から 0.037 へ落ちた。この分野では、エージェントが手順を一度に書き出し、それをシミュレーションでそのまま実行する²。

HORIZON が測るのは順位ではなく壊れ方だ。著者らは長さを段階的に伸ばしたタスクを4分野で組み、GPT-5-mini と Claude-4-Sonnet の2モデルから3,100本超の実行軌跡を集め、どの段階でなぜ失敗したかを軌跡に紐づけて分類する。分類はモデルに行わせているが、その照合は40軌跡・注釈者1名のパイロットである（人と分類器の一致度 $\kappa = 0.84$）と著者らは報告する。この分類から著者らは、実行時に計画を検証して直す仕組みと、長い制約を保ち直す記憶の仕組みを今後の設計の重点に挙げ、より強い基盤モデルだけに頼るべきではないと書いている。ただしこれは研究課題としての提案で、その効き目は測っていない²。

別々のチームが別々のベンチマークと指標で、同じ「長くなると崩れる」を捉えたことになる。どちらも2026年前半のプレプリント（査読前）で、第三者による独立再現は確認できていない点は割り引いて読むべきだが、独立に同じ向きの結果が出た事実は、単発の主張より確度が高いと解釈できる。

より大規模で実務寄りの評価も、同じ向きの結果を出している。Agents’ Last Exam は、Berkeley を中心とする著者らが250名超の業界専門家と組んで作った実世界タスクのベンチマークである。標準ベンチでの好成績が経済的に意味のある実務への展開に結びついていない。著者らはこの差を主に「評価の問題」だと論じたうえで、最も難しいティアではまだ飽和にほど遠く、平均完全達成率は1%未満だと報告する³。著者らが最強とする構成（Codex と GPT-5.5）は Terminal-Bench で82%を出しながら、ALE では最も易しいティアでも完全達成率が38.1%にとどまった³。Terminal-Bench と同程度の規模でコマンドライン（CLI、Command-Line Interface）の課題に絞った部分集合 ALE-CLI でも、この構成の全体の達成率は23.3%（最も易しいティアで37.2%）だった³。著者らは ALE-CLI の課題を、Terminal-Bench より大幅に難しく、より長いエージェントのセッションを要すると説明する。ベンチマークは違うが、「短い・抽象的なベンチの強さは、長く現実的な仕事での到達度を保証しない」という同じ一点を、より大きな規模で指している（ただし著者に HORIZON と重なりがあり、完全に独立ではない）。

掛け算より速く落ちたのは、中の長さの帯

長いタスクで成功率が落ちるのは、手数が多いぶん各ステップの小さな誤りが積み重なるからである。1ステップの失敗率がわずかでも、独立に何十回と続けば成功率は掛け算で落ちる。Khanal らは、短い帯から中の帯への落ち方が、その単純な掛け算（各ステップが独立だと仮定した幾何級数）より速いモデルが多いと報告した（中の帯は短い帯の2倍の手数と置いた計算）。ただし同じ表の数で本稿が計算し直すと、長い帯（4倍と置く）で掛け算の予測を下回ったのは10モデル中2モデルで、10モデルの平均も、長い帯の 50.5% は予測の 33.9% より高く、最も長い帯の 52.1% は長い帯より高い¹。著者らは中の帯の速い落ち方を、誤りがステップ間で正の相関を持つためだと解釈している。一度おかしなツール呼び出しをするか誤った仮説を立てると、そこから抜け出せずに引きずる、という説明だ¹。途中で自分の誤りに気づいて直す力が弱いほど、崩壊は早いことになる。

ソフトウェア工学が最も速く崩れることも、同じ理屈で説明がつく（この説明づけは本稿の解釈である）。依存の連鎖が長く、途中の状態を検証しにくい仕事は、一度ずれると後戻りが効かない。文書処理の平坦さは、先に見たとおり著者ら自身が長さの尺度の限界に帰しているので、この説明には含めない。

測ったのは、検証を強制しない条件での信頼性

Khanal らが測ったのは、検証を強制する運用ハーネスを与えないエージェントの信頼性だ。 著者らは、一発勝負の成功率（pass@1）ではなく同じタスクを $k$ 回繰り返してすべて成功する確率（pass^k）を軸に、信頼性の減衰を測っている¹。ツールが取り上げられているわけではない。著者らはエージェントに、「考える→動かす→結果を見る」を回す標準的なループ（ReAct）と、ファイルの読み書き・コマンド実行・ウェブ検索というツール一式を与えている。著者らが与えていないのは、テスト駆動開発（TDD、Test-Driven Development）や継続的インテグレーション（CI、Continuous Integration）のように、編集のたびに検証を必ず走らせて失敗を差し戻す実運用のハーネスのほうだ。検証するかどうかはエージェント任せで、外から強制されてはいない¹。

したがって、「ソフトウェア工学が最も速く崩れる」を「モデルがダメだ」と読むのは誤りで、これはハーネスの条件の結果でもある。依存が長く途中の状態を検証しにくい仕事を、検証を強制せずに一直線に走らせた条件での崩れを、実験は測っている。研究の意義は「エージェントは使えない」ではなく、検証を強制しない条件で信頼性がどこでどう崩れるかを定量化し、ハーネスで何を埋めるべきかを示したことにある。1手ごとに検査してやり直し、やり直しで直る見込みが高ければ1手の実質の成功率が上がるので、この崩れの一部は、途中に機械的な検証・修復を挟む設計で取り戻せる余地がある。

崩れの一部を取り戻せるという見方は、本稿独自の解釈にとどまらない。Khanal ら自身も、最も有効な対策として長いタスクを短く割り境目でエージェントを起動し直すこと（タスク分解）を挙げている。ただしその改善幅は短帯と超長帯の pass@1 の差をとった算術で、原典も assuming subtask independence と断っている（Qwen3 30B で 75.8%−34.3%＝41.5ポイント）。メルトダウンの兆しを合図に途中の状態を保存して起動し直す方策も、実装と評価は著者らが今後の課題に挙げている段階にある。実際、同じ論文が試したもう一種類のハーネスはむしろ逆効果だった（後述する）。

検証と計画保持は、既にハーネスの既定にある

外側の仕組みでこの崩れを減らせるという見方には、別の研究の手がかりがある。一つは広く引かれる Reflexion だ。エージェントに自分の失敗を言語化して次の試行へ渡す反省ループを足すと成績が伸びる、と著者らは報告した（多段の逐次意思決定では、AlfWorld で12回の学習ステップを通じて素の ReAct を絶対22ポイント上回り、134題中130題を解いた。1回で関数本体を書く HumanEval でも pass@1 91% を出し、ハーネスなしの同じ GPT-4 の80%を上回る）⁶。ここで反省が挟まる境目は試行と試行の間であって、1回の試行の中のステップ間ではない。失敗した一本を最後まで走らせ、その総括を次の一本へ渡す設計である。しかも著者ら自身、探索の多様性を要する WebShop では素の ReAct を有意に上回らなかったと報告している⁶。それでも、試行の失敗を検査して反省を次の試行へ渡す仕組みが、モデルを替えずに成績を上げうることは示している。

もう一つは、長いタスクへの到達を学習の側から伸ばす最近の試みだ。Agents-A1 の著者らは、外部知識・行動・観測・検証結果をつなぐ仕組みで平均45Kトークンという長い実行軌跡を大量に作り、それを教師データとして35Bのモデルを訓練した結果、1兆パラメータ級のモデルに複数ベンチで匹敵ないし凌駕したと報告する⁷。ここで効いたのは実行時のハーネスそのものではなく、ハーネスが生んだ長い軌跡で訓練したことである点は、混同しないでおきたい。それでも Reflexion と Agents-A1 は、パラメータを増やす以外の道が長いタスクには残っているという同じ方向を指している。外側の仕組みを設計する道と、その仕組みが生んだ軌跡で訓練する道がある。Agents-A1 は、効果を見込む先を短いタスクより長いタスクに置いている。

しかもこれは研究室の話にとどまらない。実運用のコーディング・ハーネスが、「検証→やり直し」と「計画の保持」を既定動作に組み込んでいる。Aider は編集したファイルを既定でリンタにかけ、設定すればテストも編集のたびに走らせる（--auto-lint／--auto-test＋--test-cmd）。コマンドが非ゼロ終了で失敗すると、既定では修正を試みるかを利用者に確かめたうえで、その出力をモデルへ差し戻す⁴。Reflexion と違い、Aider が差し戻すのは反省文ではなくエラー出力そのものである。Reflexion の著者らは、テストの結果だけを返して自然言語の反省を省くと、HumanEval Rust の最難50題（GPT-4）でベースラインから改善しなかったと報告している（0.60 対 0.60）⁶。

Cline の Focus Chain は、タスク着手時に手順のチェックリストを生成し、一定間隔ごとにコンテキストへ貼り直す（既定は6メッセージごと）⁵。Cline はこの貼り直しを、エージェントがリストを忘れないようにするためだと説明している。リストは会話ではなくタスクごとの markdown ファイルに置かれる。Aider と Cline は、片や各ステップの検証と修復、片や計画の保持を、製品の既定に置いている。ただし、これらが長いタスクの信頼性をどれだけ戻すかは、どちらの出典も測っていない。

ただし、「ハーネスなら何でも効く」ではない。ここは Khanal ら自身が反証を出している。彼らは ReAct のループにエピソード記憶のメモ帳（気づいたことを書き留めて毎ターン読み返させる）を足したハーネスも並行して測っており、結果は明確に否定的だった。長いタスクでは10モデルすべてで素の ReAct を上回らず、著者らの分類では6モデルで悪化・4モデルで横ばい（悪化幅が 0.03 を明確に超えたのは4モデル）。素の ReAct のほうが良いハーネスであり、素朴なエピソード記憶を既定の信頼性対策として採用すべきではない、と結論している¹。著者らは悪化の理由を、メモを書き込む呼び出しと伸びていくメモの毎ターンの注入が、ステップの予算とコンテキストを食うためだと説明している¹。先の Focus Chain も手順のリストを一定間隔でコンテキストへ貼り直す仕組みで、コンテキストへ繰り返し書き戻す点で形が近い。計画を保つ仕組みが長いタスクで効くかどうかは、この否定結果からは切り分けられない。

ALE は同じベンチで、ハーネスを固定して基盤モデルを替えると（OpenClaw・12モデル）達成率の開きが16.8ポイント出た一方、基盤モデルを固定してハーネスを替えた開きは4.9ポイント（GPT-5.5・5ハーネス）と7.2ポイント（Claude Opus 4.7・3ハーネス）だったと報告する³。ここで比べているのは Claude Code・Codex・Cursor といった既存ハーネス同士で、原典も among the competitive harnesses evaluated here と条件を明示している。ハーネスのない条件は入っていない。この数字が示しているのは「どのハーネスを選ぶか」の差であって「ハーネスを足すかどうか」の差ではない。ただし原典は、支配的な要因は基盤モデル側の推論力と分野知識だと結論している。

問いに戻ると、長さで分けない全体の達成率で測った比較で大きく出たのは基盤モデルの差で、既存のハーネス同士の差はそれより小さかった。長さに沿った落ち方をハーネスごとに比べた数は、この比較には無い。一方、この2研究の結果から、検証を強制するハーネスを用いた場合の信頼性までは判断できない。この2研究が測ったのは検査とやり直しを外から強制しない側で、1手ごとの検査とやり直しを強制した側を長いタスクで測った出典は、本稿が引くなかには無い。長いタスクの評価を読むときは、1手ごとの検証が外から強制されていたかを先に確かめると、どちらの側の数かが分かる。ハーネスは自動では付いてこないうえ、中身を誤れば逆効果にもなる。崩れが速い仕事ほど、何を足すかまで含めて自分で組む必要がある。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。