AIエージェントの失敗はどこで始まったか。LongRCA Benchが示す24.1%の壁
失敗が見つかった場所と、失敗が始まった場所は同じとは限りません。
あるソフトウェア修復の軌跡では、エージェントは163ステップ目まで作業を続け、完了を報告しました。ところが事後評価では、必要な47テストが一つも通りませんでした。目立つ症状は最後にあります。しかし、人が特定した原因は37ステップ目の修復計画でした。間違ったAPIの使い方が引き継ぎ指示へ入り、その後126ステップにわたって実行されていたのです。
LongRCA Benchは、こうした長いエージェント実行の失敗を集めたベンチマークです。問うのは、最後に誰がエラーを出したかではありません。「どの役割が責任を持つのか」と「最初の決定的な原因は何ステップ目か」を分けて測ります。
最良の提案手法でも、原因ステップの完全一致は24.1%でした。ログを全部読ませれば原因が分かる、というほど話は簡単ではありません。
最後のエラーだけでは原因に届かない
長時間のエージェントには、計画、引き継ぎ、ツール実行、検証、修正が連なります。途中の誤りが一度直れば、それは最終失敗の原因ではありません。反対に、早い段階の誤った指示が直らないまま後工程へ渡れば、最後にエラーを表面化させた実行役だけを責めても改善につながりません。
LongRCA Benchは原因ステップを「最終的に確認された失敗に関係し、修復されずに残った、最初の決定的な誤り」と定義します。後から同じ誤りを実行したステップや、症状を発見したステップは置き換えません。
もう一つ大切なのが、責任役割を原因ステップの発言者から自動的に決めないことです。計画役が誤った指示を出し、実行役がその通り動いた場合、原因ステップと責任役割の関係を別々に判断します。
この分離は少し面倒です。しかし、面倒なところに原因は隠れがちです。障害調査の妖怪は、だいたい最後の赤いログの少し前に住んでいます。
1,140件の自然な失敗を145ステップの長さで追う
ベンチマークは、五つの既存環境で実際に失敗した1,140件の軌跡から作られています。人工的にエラーを差し込んだデータではありません。
- SWE-bench Proのソフトウェア修復が128件
- Terminal Bench 2の端末作業が42件
- TravelPlannerの旅行計画が685件
- VitaBenchのサービス操作が108件
- WebArena Verifiedのウェブ操作が177件
合計は178,137ステップです。軌跡の長さは平均156.3ステップ、中央値145、最大728でした。原因から実行終了までの距離も中央値48、90パーセンタイル183、最大605です。
原因の後に50ステップを超えて処理が続く軌跡は49.0%、100ステップ超は28.4%、200ステップ超でも7.7%ありました。最終エラー付近だけを見る診断では、かなりの割合で入口を見落とします。
人間でも原因ステップは簡単に一致しない
正解ラベルは22人のコンピュータ科学系大学院生が作成しました。全規模の段階では1,100軌跡に1,444件の注釈が付き、重複して注釈された部分は人間同士の一致率も測られています。
責任役割の完全一致は65.9%でした。一方、原因ステップの完全一致は39.5%、役割とステップの両方が一致した割合は38.4%です。異なる番号を選べば、近いステップでも不一致になる厳しい指標とはいえ、原因を一点へ固定する難しさがよく分かります。
著者らは不一致を単純な多数決や平均で処理していません。元の指示、完全な履歴、評価結果、注釈者の根拠を見直し、証拠に支えられた人間の注釈を最終ラベルに選びました。
この数字は、24.1%というモデル成績の見方も変えます。モデルが低いだけでなく、評価対象そのものに判断の難しさがあります。自動診断をそのまま人事評価や責任追及へ使うのは危険です。まずは調査候補を狭める補助として扱うべきでしょう。
RCTAは症状から引き継ぎ指示へ遡る
提案手法のRoot-Cause Trajectory Attribution、略してRCTAは、追加学習を使わない診断パイプラインです。長いログを一度に丸ごと判定させるのではなく、三段階に分けます。
最初に、軌跡を連続した区間へ分けます。各区間を要約し、誤りの候補になりそうなステップ番号を集めます。区間の境界付近には最大5ステップの重なりを残し、引き継ぎを切断しにくくします。
次に、候補ステップの元テキストを取り出します。実行役や検証役が出した候補なら、その役割へ向けられた直前の引き継ぎ指示を探します。候補が指示を忠実に実行しただけなら、誤りを含んでいた指示側まで戻ります。候補が指示から逸脱したなら、その候補自体を原因として残します。
最後に、責任役割と原因ステップを別々の欄で出します。役割名がログ内にあるか、番号が実在するか、引用した引き継ぎ文が元テキストにあるかをプログラムで検証します。形式が壊れた回答には一度だけ修正機会を与え、それでも無効なら根拠のない欄を落とすか保留にします。
責任役割51.1%、原因ステップ24.1%
評価は1,140件すべてを使い、RCTAと五つの比較手法を同じDeepSeek-V4-Flashで動かしています。
RCTAの責任役割精度は51.1%、原因ステップの完全一致は24.1%、正解の前後5ステップ以内は37.4%でした。最強の比較手法ECHOは、それぞれ27.5%、13.2%、24.7%です。ログを一度に渡す単純な方法は26.2%、7.6%、19.9%でした。
ここから言えるのは、区間で候補を絞り、引き継ぎへ遡る設計がこの条件では有効だったことです。ただし、RCTAが原因を確実に特定できるわけではありません。役割は約半分、原因ステップは約4分の1です。
また、全手法で同じ推論モデルを使った比較なので、手法間の差は見やすい一方、絶対値が別のモデルでも変わらないとは言えません。構成要素ごとのアブレーションもなく、候補抽出、引き継ぎ追跡、検証のどれがどれだけ効いたかは未確定です。
実務ログへ四つの足場を作る
RCTAをそのまま導入しなくても、考え方は日々のエージェント運用に使えます。
1. ログへ安定した座標を付ける
各記録にステップ番号、役割名、元の内容を残します。計画、ツール出力、検証結果を一つの文章へ丸めると、原因候補を正確に指せません。
2. 三つの問いを分ける
「何が失敗したか」「どの役割が責任を持つか」「最初の決定的な誤りはどこか」を別々に記録します。最終エラーを出した役割を、そのまま原因役にしないことが重要です。
3. 症状から引き継ぎへ戻る
たとえば、73ステップ目の検証で形式エラーが見つかり、48ステップ目の実行が誤った値を書いていたとします。そこで止まらず、12ステップ目の計画がその形式を指示していなかったかを確認します。これは説明用の思考実験ですが、後工程から前工程の指示へ戻る順序がポイントです。
4. 根拠が弱ければ保留する
候補番号、役割、引用、評価結果が元ログと対応するかを機械的に確かめます。複数候補が残る場合は無理に一点へ決めず、人のレビューへ送ります。診断モデルの出力は判決ではなく、調査票です。
公開データはあるが、実装と利用条件は要確認
公開データセットには、1,140件の履歴、責任役割、0始まりの原因ステップ、人が書いた根拠文が含まれています。三つのParquetファイルとして公開され、閲覧に申請は必要ありません。
一方、データセットカードにはライセンス表示が見当たりません。RCTAの公式実装リポジトリも確認できませんでした。データを再配布したり製品へ組み込んだりする場合は、元ベンチマークを含む利用条件の確認が必要です。
データの60.1%はTravelPlannerで、軌跡生成モデルもMiniMax-M2.5、Kimi-K2.5、Qwen3.5-Plusの三つです。五領域を含みますが、あらゆるエージェントや障害の代表標本ではありません。
さらに、この研究が扱うのは失敗が終わった後の診断です。早期警告や途中介入、原因から結果までの完全な因果連鎖は評価していません。AICompanyでも1,140件すべての推論は再実行しておらず、論文と公開データの構造を照合してまとめています。
失敗を減らす前に、失敗をたどれるようにする
LongRCA Benchの24.1%は、現在の自動診断がまだ人を置き換えられないことを示します。同時に、最終ログだけを見るより、候補を絞り、引き継ぎへ遡り、根拠を検証するほうが良いという方向も示しました。
長時間エージェントを安定させるには、モデルの能力だけでなく、失敗をたどれるログ設計が要ります。誰が最後に触ったかではなく、どの指示が最初に流れを曲げたかを探せること。その座標がなければ、次の実行でも同じ失敗を別の場所で見つけるだけです。
まず残すべきは、責任役割、原因ステップ、引き継ぎ、そして根拠です。賢い診断の前に、迷子にならない地図を作る。LongRCA Benchが実務へ持ち帰れる一番大きな教訓です。