AIエージェントの成功率には半減期があるのか？

2025年6月18日原文(tobyord.com)

概要

Kwa et al. (2025) の研究に基づくAIエージェントの長時間タスク性能分析
成功率は タスク長 に対して指数関数的に減少し、 半減期 で特徴付け可能
METR によるAIタスク完了時間の指数的成長の観察
一定ハザード率モデル による成功率とタスク長の関係説明
人間とAIエージェント間の 性能スケーリング差異 の示唆

Kwa et al. (2025)の研究に基づくAIエージェントの長時間タスク性能モデル

Kwa et al. (2025) の実証研究に基づくAIエージェント評価
長時間タスクにおけるAIの成功率は 単純な数学モデル （各分ごとに一定の失敗率）で説明可能
タスク長が長くなるほど 成功率が指数関数的に減少 する現象
各AIエージェントは 独自の半減期 （50%成功率のタスク長）で特徴付け
この規則性により、異なるタスク長での 成功率推定 が可能

METRによるAIタスク完了能力の進展

METR のKwa et al. (2025)論文で、AIエージェントの タスク完了時間が7ヶ月ごとに2倍 になる指数的成長を発見
170種類の ソフトウェア工学、サイバーセキュリティ、一般推論、機械学習タスク で評価
タスクは人間がかかる時間に基づき分類
AIの成功率は タスク長が増すごとに減少 する傾向
50%成功率のタスク長と80%成功率のタスク長には 大きな差 （例：Claude 3.7 Sonnetでは59分 vs 15分）
- 80%成功率タスク長は50%成功率の1/4
- 50%成功率達成から80%成功率達成まで 約14ヶ月 （2回の倍増期間）
成功率ごとのタスク長 を用いたAI能力の時系列測定という新しいアプローチ
人間のタスク時間を共通指標とし、異種タスク間の比較が可能

この結果の一般化と限界

本研究の結果が 他のタスク群にも一般化可能かは未確定
人間が即座に解決できるがAIが苦手なタスク、逆にAIが得意なタスクも存在
「人間の所要時間」だけではAI能力の全てを説明できない
本タスク群には「自動スコアリング可能」「他エージェントとの相互作用なし」「資源制約が緩い」などバイアスあり
本稿ではこのデータを前提に 背景メカニズム を考察

一定ハザード率モデルによる説明

タスクの成功率低下を サバイバル分析 の観点から説明
一定ハザード率 （各単位時間ごとに一定の失敗確率）仮定
- 放射性崩壊の半減期に類似
AIエージェントの50%成功率タスク長＝ 半減期
タスクが 連続したサブタスク から成り、どこかで失敗すれば全体が失敗
- サブタスクごとに 独立した一定失敗率 を仮定
タスク分割の粒度に依存せず、 人間が必要とする総時間 で成功率が決定

成功率とタスク長の理論的関係

80%成功率タスク長 ≈ 50%成功率タスク長の1/3
- ln(0.8)/ln(0.5) ≈ 0.322
- 実測値（1/4）も理論値に近い
高成功率ごとのタスク長の目安
- T₈₀ ≈ 1/3 T₅₀
- T₉₀ ≈ 1/7 T₅₀
- T₉₉ ≈ 1/70 T₅₀
- T₉₉.₉ ≈ 1/700 T₅₀
- 各「ナイン」増加ごとにタスク長は10分の1

成長速度と成功率閾値の到達予測

80%成功率タスク長が特定長さに到達：50%成功率から約1年後
90%成功率：2年後
99%成功率：4年後
99.9%成功率：6年後
- 以降、各「ナイン」ごとに2年追加

実データとのフィット

成功率とタスク長の関係を ロジスティック関数 や 指数関数 で近似
指数関数近似はパラメータが少なく自然
人間の成功率カーブは 一定ハザード率よりも緩やか に減少
- 人間は長時間タスクでの成功率低下がAIより遅い傾向
- 人間は失敗したサブタスクの 自己修正能力 が高い可能性

人間とAIエージェントの性能スケーリングの違い

人間のタスク長と成功率の関係はAIと異なるスケーリングを示唆
人間の方が 長時間タスクでの成功率低下が緩やか
現在のAIパラダイムの 非効率性や改良余地 を示唆
さらなる研究の必要性

まとめ

AIエージェントの長時間タスク性能は 一定ハザード率モデル で単純かつ高精度に説明可能
成功率とタスク長の関係は 指数関数的 であり、半減期で特徴付け
人間とAIの違い が今後のAI開発・評価の重要な論点
本モデルの 一般化 や人間との違いの解明が今後の課題

Hackerたちの意見

これ、めっちゃ私の経験と一致してるわ。昨日、opusがライブラリで何かしようとしてビルドエラーに遭遇したケースがあったんだけど、そのエラーを直すんじゃなくて、別のライブラリに切り替えたんだよね。そしたらまた別のエラーが出て、今度は最初のライブラリに戻ることにした。LLMを数分以上回していい結果が出たことはないと思う。最初か二回目の試行で問題が解決しなかったら、急に適当なことを言い出したり、全然関係ない変更をして「これで解決するよ」って言ったり、同じことを何度も繰り返したりするみたい。

└

私はLLMを数分以上回していい結果が出たことはないと思う。これはAiderやCLineみたいなものでの話？私はClaude-Codeを使ってるんだけど（Maxプランだからトークンを無駄にする心配がない）、1時間以上かかるタスクも成功裏に処理できたよ。でも、そこにたどり着くのは簡単じゃないのは確か。指示やCLAUDE.mdファイルは完璧でなきゃいけない。

└

自分のコンテキストを毒してるんだよね。コンテキストが成長するにつれて、特に多くの気を散らす要素や行き止まりが増えると、出力の質が急激に落ちていく。良いコンテキストでも、100kトークンあたりでその劣化が見え始める（Gemini 2.5の場合）。彼らは本当に、以前のコンテキストを削除したり「忘れさせたり」する方法を見つける必要がある。そうすれば、ユーザーやモデルが毒のあるトークンを整理できるようになる。今は、定期的にインスタンスの要約を作って、新しいインスタンスを新鮮なコンテキストで立ち上げて、前のインスタンスの要約を入れることで対処してる。

└

コメントで「それはできない」と言う人と「こうやって動かしてる」と言う人がいるのはよく見るよね。確かにコツがあるのかもしれないけど、みんなが使おうとしてる問題の違いが、かなりの違いを説明してると思う。人々は自分が何をしようとしていたのかをあまり具体的に言わないことが多いし、プログラミングの議論でも同じことが言えるよね。

└

私も似たような経験がある。エージェントはとても便利で多くのタスクを自分で完了できるけど、時々行き詰まることもあって、その選んだ解決策が変だったりすることもある。例えば、先日モデルを変換してたんだけど、ディスクスペースが足りなくなってきたんだ。エージェントはスペースを節約するために量子化を変更することにしたけど、私は「もう少しディスクスペースが必要だよ」って聞いてほしかった。だから、一旦停止してスペースを空けてから、エージェントに元のコマンドを再試行させたよ。

└

特に難しいパースの問題があったから、いくつかテストを設定して、LLMにしばらく処理させておいて、他のことをしてたんだ。戻ってきたら、全部のテストが通ってた！でも、実行してみたら、まだ多くのケースが失敗してた。どうやらLLMがテスト値を「if (‘test value’) return ‘correct value’;」みたいにハードコーディングしてたみたい！

└

エラーを修正する代わりに、別のライブラリに切り替えることにした。私も似たような経験があって、エラーを修正する代わりに、その周りにtry/catchを追加して、ログメッセージを出して、実行を続けられるようにしてた。

└

Claude Codeを使ってて、変更しようとしてるのにテストがずっと失敗して、結局そのテストを削除してテストスイートを通過させたことがある。みんな経験あるよね！基本的に、セッションはペアリングセッションとして扱ってるんだけど、ペアリングセッションでは、失敗してる道を進むのをやめて、最初からやり直すことが必要な時もあるんだよね。

└

「数分以上LLMを回しっぱなしにして良い結果を得たことはない」って言うけど、私はその逆の経験があるよ。特に、LLMがテストスイートやプロジェクトが成功するまでのコンパイルエラーを修正するようなテストに対して検証する場合はね。うまくいくまでずっと頑張ってくれるし、最終的には良い結果が得られることが多いよ。ただ、AIが成功するまでの間は、そのエラーがすごくバカみたいで、見ててイライラすることもある。

└

なんか、こういうことに関係してる気がする：人間は問題解決で行き詰まると、新しい情報を得るために外に出ることが多いよね。それで直面した障害をよりよく対処できるようにする。これをトレーニング環境で再現するのは難しいと思うし、エージェントにGoogleを検索させるのはトレーニングサンプルを汚染しちゃうから難しいんじゃないかな。

└

最終的には正しい解決策にたどり着くかもしれないけど、一般的には、無駄に脱線する前に中断することでかなりの時間を節約できるよね。

だから、LLMから正しい解決策を引き出そうとするために、プロンプトやコンテキストを丁寧に構築する意味がないっていうのも理由の一つだよね。時間が経つにつれて、最終的な結果はどんどん脆弱になっていく。ゼロショットで成功できないなら、その問題に対してLLMは十分なトレーニングを受けてないってことだし、人間の手助けや少し違うトリガーワードが必要だと思う。最小限のプロンプトで解決策が得られたこともあって、まるでLLMが私の考えを読んでるみたいな感覚になったこともあるよ。

Hacker Newsで議論の続きを見る

ハクソク