AI・信頼性・評価

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

2026/7/28 （更新: 2026/10/14）

🤖 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回走行の平均±標準偏差のうち平均）。HORIZON が測るのは順位ではなく壊れ方だ。著者らは長さを段階的に伸ばしたタスクを4分野で組み、GPT-5-mini と Claude-4-Sonnet の2モデルから3,100本超の実行軌跡を集め、どの段階でなぜ失敗したかを軌跡に紐づけて分類する。分類はモデルに行わせているが、その照合は40軌跡・注釈者1名のパイロットである（人と分類器の一致度 κ=0.84）と著者らは報告する。別々のチームが別々の物差しで、同じ「長くなると崩れる」を捉えたことになる。この一致に重みがある。どちらも2026年前半のプレプリント（査読前）で、第三者による独立再現は確認できていない点は割り引いて読むべきだが、独立に同じ方向へ振れた事実は、単発の主張より確度が高いと解釈できる。

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

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

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

この前提を外すと、結論を読み違える。「ソフトウェア工学が最も速く崩れる」を「モデルがダメだ」と読むのは誤りだ。これは半分、ハーネスの話でもある。依存が長く途中の状態を検証しにくい仕事を、検証を強制せずに一直線に走らせれば崩れるのは当たり前で、実験はその条件での崩れを測っている。まっとうなソフトウェア開発なら機械的なチェックを挟むのが前提だ、という直感は正しい。研究の意義は「エージェントは使えない」ではなく、検証を強制しない条件で信頼性がどこでどう崩れるかを定量化し、ハーネスで何を埋めるべきかの地図を与えたことにある。裏を返せば、この崩れの一部は、途中に機械的な検証・修復を挟む設計で取り戻せる余地がある。これは本稿の見立てにとどまらない。Khanal ら自身も、最も効く処方として長いタスクを短く割り境目でエージェントを起動し直すこと（タスク分解）を挙げている。ただしその効き幅は短帯と超長帯の pass@1 の差をとった算術で、原典も assuming subtask independence と断っている（Qwen3 30B で 75.8%−34.3%＝41.5ポイント）。メルトダウンの兆しを合図に途中の状態を保存して起動し直す方策も、実装と評価は著者らが今後の課題に挙げている段階にある。実際、同じ論文が試したもう一種類のハーネスはむしろ逆効果だった（後述する）。

誤りが引きずられ、掛け算より速く落ちる

理由は単純だ。長いタスクは手数が多く、各ステップの小さな誤りが積み重なる。1ステップの失敗率がわずかでも、独立に何十回と続けば成功率は掛け算で落ちる。しかも Khanal らの実測は、その単純な掛け算（各ステップが独立だと仮定した幾何級数）よりも速く落ちた（超線形）。著者らはこれを、誤りがステップ間で正の相関を持つためだと解釈している。一度おかしなツール呼び出しをするか誤った見立てを立てると、そこから抜け出せずに引きずる、という説明だ¹。途中で自分の誤りに気づいて直す力が弱いほど、崩壊は早いことになる。

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

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

外側の仕組みでこの崩れを押し戻せるという見方には、別の研究の手がかりがある。一つは広く引かれる Reflexion だ。エージェントに自分の失敗を言語化して次の試行へ渡す反省ループを足すと成績が伸びる、と著者らは報告した（多段の逐次意思決定では、AlfWorld で12回の学習ステップを通じて素の ReAct を絶対22ポイント上回り、134題中130題を解いた。1回で関数本体を書く HumanEval でも pass@1 91% を出し、ハーネスなしの同じ GPT-4 の80%を上回る）⁶。ここで反省が挟まる境目は試行と試行の間であって、1回の試行の中のステップ間ではない。失敗した一本を最後まで走らせ、その総括を次の一本へ渡す設計である。しかも著者ら自身、探索の多様性を要する WebShop では素の ReAct を有意に上回らなかったと報告している⁶。それでも「検証→気づき→やり直し」を外から足すこと自体が、掛け算で落ちる崩壊を押し戻しうることは示している。もう一つは、長いタスクへの到達を学習の側から伸ばす最近の試みだ。Agents-A1 の著者らは、外部知識・行動・観測・検証結果をつなぐ仕組みで平均45Kトークンという長い実行軌跡を大量に作り、それを教師データとして35Bのモデルを訓練した結果、1兆パラメータ級のモデルに複数ベンチで匹敵ないし凌駕したと報告する⁷。ここで効いたのは実行時のハーネスそのものではなく、ハーネスが生んだ長い軌跡で訓練したことである点は、混同しないでおきたい。それでも両者は、パラメータを増やす以外の道が長いタスクには残っているという同じ方向を指している。外側の仕組みを設計する道と、その仕組みが生んだ軌跡で訓練する道がある。どちらも効きどころは短いタスクより長いタスクにある。

しかもこれは研究室の話にとどまらない。実運用のコーディング・ハーネスが、「検証→やり直し」と「計画の保持」を既定動作に組み込んでいる。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 ファイルに置かれる。両者は、片や各ステップの検証と修復、片や計画の保持を、製品の既定に置いている。ただし、これらが長いタスクの信頼性をどれだけ戻すかは、どちらの出典も測っていない。

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

効き幅の上限も見ておきたい。ALE は同じベンチで、ハーネスを固定して基盤モデルを替えると達成率の開きが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研究の結果から、検証を強制するハーネスを用いた場合の信頼性までは判断できない。ハーネスは自動では付いてこないうえ、中身を誤れば逆効果にもなる。崩れが速い仕事ほど、何を足すかまで含めて自分で組む必要がある。

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