AI・信頼性・評価

AIエージェントはなぜ長い作業で失敗する？成功率の掛け算と評価方法

2026/6/21 （更新: 2026/11/4） シリーズ「AIエージェント入門」 第4回 / 全4回

🤖 AIを使用して執筆

しかも、現実は「掛け算」より悪いことがある

1ステップの成功率をステップ数だけ掛けて全体の成功率とする計算は、Sinha らの2025年の研究も、長い実行を分析する出発点に使っている。そのために出典が置く仮定は二つある。各ステップの成否が独立で確率がずっと一定であることと、途中で自分では気づいて直さないことである。出典自身、これは見通しをよくするための近似で、実測では1ステップの精度は一定にならず、モデルが誤りを直すこともあると断っている¹。

同じ研究は、実測の成功率がこの計算より速く下がる原因を報告している。一度まちがった行動をとると、その誤りがコンテキストに残り、それを参照したモデルはさらにまちがえやすくなる。研究はこれを「自己条件付け（self-conditioning）」と呼ぶ。自己条件付けが起きるモデルでは、成功率はステップ数乗の計算よりも速く下がる。研究は、長い実行で精度が落ちる主因は推論能力の限界ではなく“実行”でのつまずきにある、とも報告している¹。

同じ論文は、自己条件付けが緩む条件も測っている。thinking 系モデルは、答える前に推論の過程を長く書き出すように訓練されたモデルを指す。最近の thinking 系モデルでは、自己条件付けが大きく緩む（抄録の語は thinking mitigates self-conditioning）。貢献節はより強く recent thinking models are not affected by prior mistakes, fixing the self-conditioning effect と書く。ただし、著者らが誤りを混ぜた対照実験にかけたのは Qwen3 の thinking 版である。思考の連鎖を書かせた Gemma3 は、誤りを混ぜた推論の履歴をプログラムで作って与えた付録の実験で、自己条件付けが緩まなかった。著者らはこの実験について、設計が手に負えないとして分析の対象から外している。別の実験では、途中で入力を挟まずに1回の応答の中で続けられる手順の数を測った。GPT-5 の thinking は2100手を超え、次点の Claude-4 Sonnet は432手である¹。

一方で著者らは、モデルを大きくするだけでは自己条件付けは緩まないとも書く¹。誤りが誤りを呼ぶ下がり方が緩んだのは、この研究が測った中では最近の thinking 系モデルである。

数字で見る「脆さ」と、本番の自律完遂の難しさ

現実的なタスクのベンチマーク（評価用の課題集合）でも、多段の業務を人手なしで最後まで終えられる割合は低い。登場直後（2023年）の数字は厳しかった。WebArena（実際のウェブ操作）では、人間が約78%こなすところ、最良のエージェントは約14%だった²。GAIA（General AI Assistants、一般的なアシスタント課題）では、人間92%に対し約15%だった。ただしこの15%は、人が問いごとにツールを選んだうえでの値で、論文自身が再現できない上振れ推定だと断っている。ツール選びまで自律化した AutoGPT-4 は約4.7%にとどまる³。

もっと現実に近い自律的な仕事の数字もある。2024年末に公開されたベンチマーク TheAgentCompany（模擬的な会社業務175課題）では、論文が試した12モデルのうち最良だった Gemini 2.5 Pro でも、自律で完全に終えられたのは30.3%だった⁴。ベンチマークは2024年末のものだが、この数字はその約3ヶ月後に公開された Gemini 2.5 Pro のものである。

原典は、この30.3%に自ら条件を付けている。まず、課題集合が自動採点の都合で実務より単純な側に寄っていることである（原文 our tasks are generally on the more straightforward side）。30.3% は、易しめに測ってこの水準である。次に、ハーネスの範囲が限られている。ハーネスは、モデルにツールをつなぎ、行動と結果の記録を管理するプログラムを指す。測ったのは OpenHands と OWL-RolePlay の二つのハーネスだけで、ほかのハーネスでは成績が違いうると原典は断っている⁴。単発のタスクはこなせても、現実の多段の業務を人手を借りずに最後まで通すのは、まだ難しい。

それでも伸びは本物で、現在地は「脆いが、速い」

成功率を50%に保てるステップ数で見ると、1ステップの成功率の差はさらに大きく表れる。各ステップの成功率が少し上がるだけで、こなせるタスクの長さは大きく伸びる。出典は Proposition 1 の直後で、この伸び方を双曲的と呼ぶ¹。$p^n = s$ を $n$ について解いた出典の式 $\ln(s) / \ln(p)$ に、全体の成功率 $s = 50\%$ を入れる（$p$ は1ステップの成功率）。すると、95%で13.5ステップ、99%で69ステップ、99.9%で693ステップになる。$p$ が1に近づくほど伸びが速くなる。$s = 50\%$ は、すぐ後で見る METR の「50%の信頼性」と同じ基準である。

実際、ベンチマークの成績はこの1〜2年で大きく伸びた。WebArena では、2025年に61.7%の報告がある。ただしこれは IBM が自社エージェントについて出した査読前のレポートで、ベンチマークの部分集合を広げながら調整を重ねた末の値である²。この値の読み方は、次の節でもう一度扱う。

より長い期間の傾向は METR が測っている。METR は「（ソフトウェア開発タスクで）50%の信頼性でこなせるタスクの長さ」を継続的に計測しており、この長さは倍々で伸びてきた。当初 METR は、2019〜2025年の通算で約7ヶ月ごとに倍になると報告した。2026年の改訂でも通算はほぼ変わらない。区間を切ると倍化の間隔は短く、改訂版では2023年以降が約4ヶ月（131日）、2024年以降が約3ヶ月（89日）である⁵。改訂前の推定でも同じ区間は165日と109日で、近年ほど倍化が速いという向きは両版に共通する。ただし当初の論文は、2024年以降に加速したかもしれないと書くにとどめ、2024年以降だけの傾向は外挿に使えるほど頑健ではないと断っている。いまのエージェントは、長い作業ではまだ失敗しやすいが、こなせる長さは速く伸びている。

この傾向を「数年で月単位の仕事を自動化」と外挿したのは METR 自身である。同じ論文は、外挿が二つの点に左右されると断っている。実務の課題へ一般化できるかどうかと、傾向そのものが今後変わりうることである⁵。傾向は測られた事実で、外挿はまだ議論の途中にある。

ただし、その数字も「測り方」しだいで動く

ここまで挙げたベンチマークの成績は、いずれも評価の条件しだいで動く。プリンストン大学の Kapoor らは “AI Agents That Matter” で、エージェント評価そのものの欠陥を指摘している⁶。

一つはコストを見ない比較である。コード生成（HumanEval）では、作り込んだエージェントが単純なベースラインを上回っておらず、精度に有意差がない。ここでいう単純なベースラインは、再試行、温度を上げながらの再試行、モデルの段階的な切り替えである。最も高価な構成は、ベースラインの50倍以上のコストがかかる。

もう一つは保留集合の不足である。保留集合は、開発中には使わず、最後の評価にだけ使う課題の集まりを指す。著者らは、多くのエージェント評価は保留集合が不十分で、時には全く置かれておらず、その結果エージェントはベンチマーク向けの近道を覚えて過適合する（著者らの語で fragile）と指摘する。結果が再現できないこと、コストを無視して精度だけを競っていることも挙げる。そのうえで著者らは、評価はコストを勘定に入れて比べ、精度とコストの二つの軸で並べるべきだとする。保留集合も、エージェントに求める汎用性の水準に応じて作り分けるべきだという⁶。高い成績が報告されたときほど、どの条件で測ったかを確かめてから受け取る必要がある。

同じ論文は、WebArena を名指しでケーススタディに取り上げている⁶。当時のリーダーボード首位 STeP の精度は35.8%で、2位に10ポイント以上の差をつけていた。だが著者らが中身を開くと、STeP は WebArena に含まれる特定の課題を解くための方策をハードコードしていた。たとえば利用者プロフィールへ移動する課題では、現在のURLに /user/user_name を足す、という具合である。著者らはこれを This is brittle（これは脆い）と書く。サイトのURL構造が変われば効かなくなるからである。

そのうえで著者らは、個々の方策が失敗する確率が小さくても、1つの課題で何十回も方策を呼ぶなら、全体の失敗確率はすぐに積み上がると述べている。これは、1ステップの成功率をステップ数だけ掛ける計算と同じ話である。

もっとも原典は、STeP の開発者の目的は事前に分かっている課題を組み合わせ可能な方策で解くことで、ベンチマークの作り手とは別だと断り、その立場では設計は理にかなうと書く。問題は、下流の開発者がそのリーダーボードを、実世界の課題での精度を知り、どのエージェントを採用するか決める材料に使いうることだという。著者らは、WebArena のリーダーボード上の精度そのもの（STeP はその一例）を、下流の開発者から見れば誤解を招きうると書く（著者らの語で misleading from the perspective of downstream developers）。上で挙げた61.7%も、同じ WebArena で報告された数字である。

2026年4月には UC Berkeley RDI が、WebArena の812課題の正答が、エージェントが動くのと同じファイルシステムに平文で置かれ、読み取りを防ぐサンドボックスも無いことを示した。これは攻略が可能だという指摘で、上の数字がそうして得られたという意味ではない²。

失敗を減らすには、各ステップの確かさと誤り回復が要る

エージェントを実用に使えるようにするには、より賢いモデルだけでは足りない。掛け算で成功率が下がるのを抑えるには、各ステップの確かさ（信頼性）を上げ、まちがえたら気づいて立て直す仕組み、つまり検証と誤り回復が要る。WebArena の著者自身も、エージェントの成績が伸びない原因を a lack of crucial capabilities such as active exploration and failure recovery と書いている²。欠けているのは能動的な探索や失敗からの立て直しといった能力だ、という推測である。このうち後者は誤り回復に当たり、ハーネスの側で支えられる部分でもある。

METR の論文も、こなせるタスクの長さが伸びた主な理由の一つに、誤りへの適応が良くなったことを挙げる⁵。著者らが失敗した実行を読み直すと、失敗した行動をそのまま繰り返していたのは GPT-4 1106 で31件中12件、o1 で32件中2件だった。ただし著者らの語は「そう見える」で、o1 の失敗の半分は途中での放棄だった⁵。

ただし「検証させればよい」と結論づけるのは、出典の主張を超えている。自己条件付けを報告した当の論文は、モデルに自己検証を促すという最も素直な手立てを実際に試している。結果は芳しくない。思考の連鎖を書かせた Gemma3 では、初期のターンでは効くが、検証の分だけトークンを使ってコンテキスト長を早く使い切り、後半でかえって急に精度が落ちる。thinking 系の Qwen3 では、ほとんど改善しない。

著者らの結論は、プロンプトによる自己修正では足りないかもしれない、である（may not be enough）。理由として、計算量が多いこと、コンテキスト長を消費すること、自己検証それ自体が誤りやすい複雑な実行タスクであることを挙げる。同じ付録で効いたのは、むしろ直近の1〜25ターンだけを残して、過去の自分の誤りをコンテキストから外すほうだった。もっとも著者らは、この手立てが課題のマルコフ性（いまの状態だけで次が決まる性質）に依ると断っている。そのうえで、コンテキストに誤りが溜まらないよう能動的に管理することを、長い実行の信頼性を上げる有望な方向だとする¹。検証と誤り回復が要ることは変わらないが、それはモデル自身に一言頼めば済む話ではない。

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