In Silico

AI・信頼性・評価

AIエージェントの信頼性は長いタスクほど落ちる。分野で差

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

🤖 AIが執筆しています

目次
【背景】短い課題のベンチで成績を測ってきた任せたいのは何十手も続く長い仕事【問い】長く走らせると信頼性はどう落ちるのかモデルの限界か、外側の仕組みの話か
※概念図（背景→問い）：エージェントが長い仕事を担い始めた。どこまで当てになるか
背景

AIエージェントは、指示を受けたあと道具を呼び出しながら自分で何手も進めていくプログラムである。このエージェントに実際の仕事を任せる場面が増えた。コードを直す、資料を調べてまとめる、書類を処理する。任せてよいかどうかの判断材料になってきたのはベンチマークの成績だが、これまで標準になってきたベンチが測るのは、たいてい短い仕事である。関数をひとつ書く、質問にひとつ答える。ところが現場で任せたいのは、何十手も続く長いほうの仕事だ。短い課題での成績が長い仕事でも当てになるかどうか、つまり長く走らせたときの信頼性は、成績表を見ているだけでは決まらない。もう一つ、エージェントの出来はモデル単体で決まるわけではない。検証を挟む、手順を書き出して貼り直す。モデルの外側に置くこうした仕組みを足場（ハーネス）と呼ぶ。長さの話をするときは、モデルの側と足場の側を分けて見る必要がある。

問い

仕事を長く伸ばすと、エージェントの信頼性はどれくらい、どんな仕事で落ちるのか。そしてその落ち方は、モデルの限界として受け取るべきものなのか、足場の側で押し戻せるものなのか。

要点

2026年前半、査読前のプレプリント2本が独立に出て、それぞれの物差しで長いタスクの信頼性を測った。測った範囲での答えはこうだ。崩れ方は仕事の分野で大きく偏る。最も速く崩れるのはソフトウェア工学で、文書処理はほぼ横ばいだった。しかもこれは外から検証を強制されない条件で測った下限であって、その一部は足場の側で押し戻す余地がある。 ただし押し戻す側も一様ではない。効くのは検証して直す仕組みや計画を保つ仕組みであって、足場を足しさえすればよいという話ではない1。

何がわかったのか

1本は、「信頼性の科学」を掲げる枠組みの論文「Beyond pass@1」だ（2026年3月31日公開）1。著者らはオープンウェイトの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 でほぼ動かない1。ただし層状に分かれるのは10モデルを集計した姿である。別指標の pass@1 で見ると、長い側の2つの帯のソフトウェア工学でも上位4モデルは 74.7〜82.3% を保っている1。対象の中でも上位のモデルほど野心的な多段戦略を試み、それが外れて、最も長い帯のタスクでは最大19%が「メルトダウン」（ツール呼び出しが乱れて立て直せなくなる崩壊）に至った、という1。

もう1本は独立したグループ（Wang ら）による診断ベンチマーク「HORIZON」の論文で（2026年4月13日公開）、やはりエージェントは長い地平線のタスクで大きく劣化する傾向を分野横断で報告している2。たとえば 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%未満だと報告する3。物差しは違うが、「短い・抽象的なベンチの強さは、長く現実的な仕事での到達度を保証しない」という同じ一点を、より大きな規模で指している（ただし著者に HORIZON と重なりがあり、完全に独立ではない）。

この実験は何を測って、何を測っていないか

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

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

なぜ崩れるのか

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

分野差も同じ理屈で説明がつく（この説明づけは本稿の解釈である）。ソフトウェア工学のような依存の連鎖が長く、途中の状態を検証しにくい仕事は、一度ずれると後戻りが効かない。逆に文書処理のように各ステップが比較的独立で、部分的な失敗が全体を巻き込みにくい仕事は平坦にとどまる。

足場（ハーネス）で押し戻せるが、どんな足場でもよいわけではない

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

しかもこれは研究室の話にとどまらない。実運用のコーディング・ハーネスが、「検証→やり直し」と「計画の保持」を既定動作に組み込んでいる。Aider は編集したファイルを既定でリンタにかけ、設定すればテストも編集のたびに走らせる（--auto-lint／--auto-test＋--test-cmd）。コマンドが非ゼロ終了で失敗すると、その出力をモデルへ差し戻してエラーの修正を試みる6。Reflexion が試行の単位でやったこと、つまり失敗を言語化して次へ渡すことを、編集1回の単位まで縮めて製品の既定に据えたものだ。Cline の Focus Chain は、タスク着手時に手順のチェックリストを生成し、一定間隔ごとに文脈へ貼り直す（既定は6メッセージごと）7。Cline はリストを会話ではなくタスクごとの markdown ファイルに置く。Focus Chain は、長い地平線で薄れがちな「次に何をするか」を揮発する会話の外に固定し、見失わせない。掛け算で落ちる崩壊を、片や各ステップの検証と修復で、片や計画の保持で押し戻している。本稿が見てきた崩れを足場が埋める、その実物だ。

ただし、「足場なら何でも効く」ではない。ここは Khanal ら自身が反証を出している。彼らは ReAct のループにエピソード記憶のメモ帳（気づいたことを書き留めて毎ターン読み返させる）を足した足場も並行して測っており、結果は明確に否定的だった。長いタスクでは10モデルすべてで素の ReAct を上回らず、6モデルで悪化・4モデルで横ばい。素の ReAct のほうが良い足場であり、素朴なエピソード記憶を既定の信頼性対策として採用すべきではない、と結論している1。押し戻すのは「記憶を持たせること」ではなく「検証して直すこと」「計画を保つこと」のほうだ、という切り分けを、この否定結果は示唆する。裏返せば、本稿の言う”足場で取り戻せる”は、検証・修復・計画保持といった具体的な仕組みに限った話であって、足場一般の効能ではない。

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

つまり本稿の2研究が測った「検証を強制しない条件での崩れ」は下限であって天井ではない。ただし足場は自動では付いてこないうえ、中身を誤れば逆効果にもなる。崩れが速い仕事ほど、何を足すかまで含めて自分で組む必要がある。

実務で何が変わるか

では、長く走らせる側は何を変えればいいのか。崩れが下限であって天井でないなら、変わるのは測り方と、足す足場の中身だ。

「長くしても大丈夫か」は、モデルの賢さとは別に、測って確かめる問いになった。

出典7件

  1. “Beyond pass@1: A Reliability Science Framework for Long-Horizon LLM Agents”（arXiv:2603.29231, 2026年3月31日公開, Khanal ほか。査読前プレプリント、独立再現は未確認）。著者らの報告によれば、オープンウェイトの10モデル（すべて OpenRouter 経由。原典が対象外として名指す非公開モデルは GPT-4o・Claude 3.7・Gemini 2.0 Ultra で、which are likely more reliable than the models studied here と断っている）・23,392エピソード・396タスク（ソフトウェア工学／ウェブ調査／文書処理の3分野）で長さに沿った信頼性の減衰を測定。指標は、単発の成功率(pass@1)でなくk回すべて成功する確率(pass^k)を軸にした減衰カーブ／ばらつき増幅／メルトダウン開始点など。足場は ReAct（考える→動かす→結果を見る）とエピソード記憶付きの2種で、道具はファイル読み書き・コマンド実行・ウェブ検索等が与えられている（＝検証手段は使えるが、検証は強制されていない）。ソフトウェア工学の Graceful Degradation Score（GDS・部分達成を加味した信頼性指標）は長さとともに 0.90→0.44、文書処理は 0.74→0.71。減衰は各ステップ独立を仮定した幾何級数より速い（超線形）で、著者らはステップ間の誤りの正の相関に帰している。メルトダウン率は最長帯で最大19%（DeepSeek V3）。著者らは、上位モデルほど高いという逆説として報告している。記憶付き足場は長い帯で10モデル全てが ReAct を上回らず（6モデル悪化・4モデル横ばい）、著者らは素朴なエピソード記憶を既定の信頼性対策にすべきでないと結論している。数値はいずれも同論文の代表値。https://arxiv.org/abs/2603.29231 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12

  2. Xinyu Jessica Wang, Haoyue Bai, Yiyou Sun ほか（Dawn Song, Robert D. Nowak を含む）, “The Long-Horizon Task Mirage? Diagnosing Where and Why Agentic Systems Break”（arXiv:2604.11978, 2026年4月13日公開。査読前プレプリント、独立再現は未確認）。診断ベンチマーク HORIZON により、LLMエージェントが長い実行ステップを要するタスクで大きく劣化することを分野横断で示したと報告する独立の研究。何を測るか＝順位づけでなく失敗の所在と理由：長さを段階的に伸ばしたタスクを4つの代表的エージェント分野で構成し、GPT-5-mini と Claude-4-Sonnet の2モデル（原典 §D.2 We use GPT-5-mini ... and Claude-4-Sonnet ... across all four domains）から3,100本超の軌跡を収集、軌跡に紐づけた LLM-as-a-Judge で失敗を帰属させる。人手注釈と照合し、注釈者間 κ=0.61・人と分類器 κ=0.84 の一致を得たと報告（いずれも40軌跡のパイロット。前者は注釈者2名、後者は1名）。著者ら自身が “initial”（初期段階の）ベンチと位置づけている。https://arxiv.org/abs/2604.11978 ↩

  3. “Agents’ Last Exam”（arXiv:2606.05405, 2026年6月3日公開・査読前, Yiyou Sun ほか、UC Berkeley 主導・250名超の業界専門家と協働）。標準ベンチの好成績が経済的に価値ある実務への展開に結びつかない「評価の問題」を突くため、O*NET/SOC 2018 準拠で55サブ分野・1千超のタスクを組んだ実世界ベンチ。著者らの報告では、最も難しいティアはまだ飽和にほど遠く、主要なハーネス／基盤モデルの構成で平均完全達成率は1%未満。ベンチ全体の平均ではなく、この最難関ティアについての数値である点に注意。なお本ベンチは著者に HORIZON 2 と重なりがあり、両者は完全には独立でない。独立再現は本稿執筆時点で未確認。https://arxiv.org/abs/2606.05405 ↩ ↩2

  4. Noah Shinn, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, Shunyu Yao, “Reflexion: Language Agents with Verbal Reinforcement Learning”（arXiv:2303.11366, 2023年）。エージェントに失敗の言語的な自己反省を次試行へ渡すループを足すと、ベースラインのエージェントを上回ると報告。コーディングの HumanEval (Python) では、同じ GPT-4 の足場なし 0.80 に対し Reflexion 0.91（表2）。抄録が「既報の最高値 GPT-4 の80%を上回った」と書く 80% は、この足場なし条件と同じ値である。足場の要素別アブレーションも別にあり、HumanEval Rust の最難50題で足場なし 0.60／テスト生成なし 0.52／自己反省なし 0.60／Reflexion 0.68（表3）。逐次意思決定（AlfWorld で134題中130題）や推論（HotPotQA）でも改善。検証→反省→やり直しという「外側のループ」が信頼性を押し上げる側の一次証拠（広く引用される標準的手法）。著者ら自身が切っている適用限界：(1) MBPP Python だけはベースライン 0.80 に対し 0.77 と下回り、原典は sets new state-of-the-art standards on all benchmarks for Python and Rust except for MBPP Python と除外を明記する（原因は自己生成テストの偽陽性率で、MBPP Python の 16.3% に対し HumanEval Python は 1.4%）。(2) e コマースサイトを多段で操作する WebShop では ReAct + Reflexion fails to significantly outperform ReAct、著者らは Reflexion is unable to solve tasks that require a significant amount of diversity and exploration と結論している（付録B.1）。(3) §5 は局所最適に陥りうること、長期記憶を容量上限つきのスライディングウィンドウ（実験では1〜3経験、コーディングでは1）に限っていることを挙げる。https://arxiv.org/abs/2303.11366 ↩ ↩2

  5. Lei Bai ほか（Agents-A1 チーム）, “Scaling the Horizon, Not the Parameters: Reaching Trillion-Parameter Performance with a 35B Agent”（arXiv:2606.30616, 2026年6月29日公開・査読前。所属は上海人工知能研究所で、Agents-A1 を開発した当事者による自己評価である）。機構の注意：これは実行時の足場ではなく学習の話である。著者らは外部知識・行動・観測・検証結果をつなぐ基盤で平均45Kトークンの長い軌跡を生成し、“Based on this, we train Agents-A1” と述べるとおり、その軌跡を教師データに35BのMoEモデルを三段階（全ドメインSFT → ドメイン別教師モデル → マルチ教師のドメインルーティング on-policy 蒸留）で訓練している。結果、1兆パラメータ級（Kimi-K2.6・DeepSeek-V4-pro）に対し SEAL-0 56.4・IFBench 80.6・HiPhO 46.4・FrontierScience-Olympiad 79.0・MolBench-Bind 56.8。抄録の列挙には無いが、差が最も大きく開いたのは FS-R（FrontierScience-Research）で、Agents-A1 40.0 に対し1兆級は 17.9／13.3／26.7 である（ただしこれも下記の道具なし比較の対象）。ただしこの5つは著者らが “leading results” と書く勝ち側で、SciCode 44.3・HLE 47.6・BrowseComp 75.5 のほうは “remains highly competitive” であり、著者ら自身が上回ったとは書いていない側である。なお著者らは、この SciCode と（ここまで挙げていない）MLE-Bench-Lite について本文でこう書いている。leading all same-scale 35B baselines on both benchmarks. However, it is still clearly weaker than 1T-level models.（v2 の §5.2.3）。実数は SciCode 44.3 対 53.5／50.0／56.1、MLE-Bench-Lite 43.9 対 62.1／63.6／72.7（v2 の Table 9、比較は Kimi-K2.6／DeepSeek-V4-pro／GPT-5.5）。比較の条件：Agents-A1 は検索・閲覧・コード・文献の道具を与えた構成で測られている。HiPhO・FS-O については、著者らは比較対象を道具なしで走らせたと明記している。we report tool-free results for comparison models to avoid confounding effects from applying our tool-augmented evaluation protocol to models not trained for tool use（§5.1）。著者ら自身はこれを厳しい比較（a stringent comparison）と位置づけている。パラメータ規模でなく「地平線」を伸ばす方向で長い仕事の到達度を得た側の証拠だが、推論時ハーネスの効果を示した実験ではない。独立再現は本稿執筆時点で未確認。https://arxiv.org/abs/2606.30616 ↩

  6. Aider「Linting and testing」（公式ドキュメント, 閲覧2026-07）。編集した各ファイルを既定でリンタにかけ（無効化は --no-auto-lint）、--auto-test＋--test-cmd を設定すればテストも編集のたびに走らせる。「If there are test errors, aider expects the command to print them on stdout/stderr and return a non-zero exit code」「Aider will try and fix any errors if the command returns a non-zero exit code」。Aider は非ゼロ終了をエラー信号として受け、出力をLLMへ差し戻して修正を試みる。差し戻しの反復回数は公式ドキュメントに明示がないが、実装側には上限がある。aider/coders/base_coder.py の max_reflections = 3 に達すると Only 3 reflections allowed, stopping. と警告して打ち切る（v0.86.0 時点、https://github.com/Aider-AI/aider/blob/v0.86.0/aider/coders/base_coder.py）。生成→検証→修復のループを製品の既定動作に組み込んだ実例＝Reflexion 型の反省ループの実運用版。https://aider.chat/docs/usage/lint-test.html ↩

  7. Cline「Cline v3.25: The Coding Agent Built for Hard Problems」（公式ブログ, 閲覧2026-07）。タスク開始時に手順のチェックリスト（実装では - [ ] 形式）を自動生成し、keeps injecting this list back into the context at regular intervals と述べる。間隔の数値も同じ節にある。Every six messages (by default), Cline is reminded は、実装 cline/cline の apps/vscode/src/shared/FocusChainSettings.ts にある remindClineInterval: 6 と一致する（2026年8月15日に両方を再取得して確認）。長い地平線でも進捗と「次にやること」を見失わないようにする（v3.25 で既定有効）。手順リストは会話ではなくタスクディレクトリの focus_chain_taskid_<taskId>.md に置かれる（apps/vscode/src/core/task/focus-chain/file-utils.ts）。計画を揮発する会話の外に固定する足場の実例。https://cline.bot/blog/cline-v3-25 https://github.com/cline/cline/blob/791d238996/apps/vscode/src/shared/FocusChainSettings.ts ↩

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。