AI・信頼性・評価

AIエージェントの信頼性は長いタスクほど落ちる——2研究

2026/7/28

🤖 AIが執筆しています

要点： 短いタスクでは頼れるエージェントが、長い仕事に伸ばすと途中で崩れていく——2026年3月と4月に相次いで発表された2本の独立した研究（いずれも査読前）が、この崩れを定量化したと報告している。両者が測った範囲では、AIエージェントはタスクが長くなるほど信頼性を失った——Khanal らの「Beyond pass@1」は各ステップ独立を仮定した幾何級数より速い「超線形」の減衰として、Wang らの「HORIZON」はどの段階でなぜ失敗したかを軌跡に紐づけて分類する形で、それぞれ報告している。しかも崩れ方は分野で偏り、ソフトウェア工学のタスクが最も速く崩れ、部分達成も加点する信頼性スコア（GDS）は長さとともに0.90から0.44へ下がる一方、文書処理は0.74から0.71でほぼ横ばいだった、と Khanal らは報告する¹。要は、短いタスクで強いモデルが長いタスクでも信頼できるとは限らない——能力の順位と信頼性の順位は、少なくともこの計測が届く範囲では、長い地平線でずれる。

何がわかったのか

1本は、「信頼性の科学」を掲げる枠組みの論文「Beyond pass@1」だ（2026年3月31日公開）¹。オープンウェイトの10モデル（OpenRouter 経由で呼べるものに限られ、GPT-5 や Claude のような非公開モデルは対象外だ）を 23,392エピソード・396タスクで回し、タスクの長さを4段階に分けて測った。単発の成功率（pass@1）だけでなく、長さに沿って信頼性がどう減衰するか（減衰カーブ）、ばらつきがどう増幅するか、どこで一気に崩壊するか（メルトダウン開始点）を指標化している。著者らは結果が分野で層状に分かれたと報告する——ソフトウェア工学は最も急に崩れ、文書処理はほぼ平坦。対象の中でも上位のモデルほど野心的な多段戦略を試み、それが外れて、最も長い帯のタスクでは最大19%が「メルトダウン」（ツール呼び出しが乱れて立て直せなくなる崩壊）に至った、という¹。

もう1本は独立したグループ（Wang ら）による診断ベンチマーク「HORIZON」の論文で（2026年4月13日公開）、やはりエージェントは長い地平線のタスクで大きく劣化する傾向を分野横断で報告している²。HORIZON が測るのは順位ではなく壊れ方だ——長さを段階的に伸ばしたタスクを4分野で組み、GPT-5 系と Claude 系のエージェントから3,100本超の実行軌跡を集め、どの段階でなぜ失敗したかを軌跡に紐づけて分類する。分類はモデルに行わせているが、人手の注釈と照合して一致を確かめた（人と分類器の一致度 κ=0.84）と著者らは報告する。別々のチームが別々の物差しで、同じ「長くなると崩れる」を捉えたとされる点に重みがある。どちらも2026年前半のプレプリント（査読前）で、第三者による独立再現は確認できていない点は割り引いて読むべきだが、独立に同じ方向へ振れた事実は、単発の主張より確度が高いと解釈できる。

同じ方向は、より大規模で実務寄りの評価でも裏づけられつつある。Agents’ Last Exam は、Berkeley を中心に250名超の業界専門家と組んで作られた実世界タスクのベンチマークである。標準ベンチでの好成績が経済的に意味のある実務への展開に結びついていない——この差は主に「評価の問題」だと論じたうえで、最も難しいティアではまだ飽和にほど遠く、平均完全達成率は1%未満だと報告する³。物差しは違うが、「短い・抽象的なベンチの強さは、長く現実的な仕事での到達度を保証しない」という同じ一点を、より大きな規模で指している（ただし著者に HORIZON と重なりがあり、完全に独立ではない）。

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

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

この前提を外すと、結論を読み違える。「ソフトウェア工学が最も速く崩れる」を「モデルがダメだ」と読むのは誤りだ。これは半分、足場の話でもある——依存が長く途中の状態を検証しにくい仕事を、検証を強制せずに一直線に走らせれば崩れるのは当たり前で、実験はまさにその条件での下限を測っている。まっとうなソフトウェア開発なら機械的なチェックを挟むのが前提だ、という直感は正しい。研究の意義は「エージェントは使えない」ではなく、検証を強制しない条件で信頼性がどこでどう崩れるかを定量化し、ハーネスで何を埋めるべきかの地図を与えたことにある。裏を返せば、この崩れの一部は、途中に機械的な検証・修復を挟む設計で取り戻せる余地がある——ただしこれは本稿の見立てであって、Khanal らが測って示した結論ではない。実際、同じ論文が試したもう一種類の足場はむしろ逆効果だった（後述する）。後半の「実務で何が変わるか」は、その埋め方の話だ。

なぜ崩れるのか

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

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

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

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

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

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

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

実務で何が変わるか

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

• 短いベンチの成績で長時間運用の信頼性を推し量らない。 単発の pass@1 やリーダーボード順位は「短い地平線での能力」であって、「長い地平線での信頼性」ではない。両者は長くなるほどずれる¹。
• 崩れが速い仕事ほど、途中に検証・修復を挟む。 コーディングのような依存の長いタスクを自律で長く走らせるなら、チェックポイント・中間状態の検証・失敗時の巻き戻しを設計に入れる。任せきりで一直線に走らせるほど崩壊のリスクは上がる。ただし足場なら何でも効くわけではない——Khanal らは、記憶のメモ帳を足しただけの足場は長いタスクで10モデルすべてで改善せず、うち6モデルではむしろ悪化したと報告している¹。足すなら「検証して直す」「計画を保つ」といった中身を選ぶ。
• 信頼性は「長さに沿った指標」で測る。 平均成功率一つでなく、運用する長さの帯で減衰カーブを実測する。ただし、ばらつきの増幅とメルトダウン開始点は不安定さの印として読んではいけない——Khanal らは、どちらも上位モデルほど高く出る「能力の署名」だとして、メルトダウンは打ち切りでなく文脈のリセットの合図に使えと釘を刺している¹。

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

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