アーカイブ / LLM / AI Agent
修正エージェントの作業記録から、失敗につながる反復を調べる
Thought-Action-Result Trajectory Analysis
Thought-Action-Result Trajectory Analysisの原論文から掲載した図です。細部はクリックして拡大できます。
原論文の図の説明を読む
Fig. 2 : Comparative trajectory length between successful and unsuccessful trajectories (y-axis differs between the agents).
概要
- 三つの修正エージェントの120件の作業記録を、思考・操作・結果の共通形式で分析した。
- 著者らは、失敗例に同じ操作の反復や、結果を生かさない進行が見られると報告した。
- 実務では最終的な成功率とともに、試験結果を次の操作へ反映できたかを記録すると改善点を探しやすい。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、Thought-Action-Result Trajectory Analysisの仕組み
- 01修正作業の記録
- 02三要素へ整形
- 03操作列の集計
- 04行動パターン
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
この研究は、ソフトウェア修正エージェントが問題を解く途中の作業を分析する。エージェントはコードを探し、編集し、試験結果を読みながら次の操作を決めるが、最終的な成功率だけでは失敗までの経緯が分からない。
著者らは一連の記録を「軌跡」と呼び、考えたこと、外部への操作、その結果の組として扱う。どこで結果を見落としたか、同じ操作を繰り返したかを調べることが、設計改善の手掛かりになる。
手法
研究者はRepairAgent、AutoCodeRover、OpenHandsのログを、思考・操作・結果の三要素が反復する共通形式へ変換した。例えば「関数の使われ方を調べる」と述べ、検索を実行し、該当箇所が返る、という一連を一回分として記録する。そこから反復回数と消費トークン数を数え、操作を探索、修正、試験など八種類へ分類した。
続いて、連続する四操作の組が成功例と失敗例でどう現れるかを調べた。さらに人が記録を読み、前の結果が次の考えや操作へ反映されたかを分類した。ここでの「意味的な整合」とは、説明した目的と実際の操作が筋道として合っているかを指す。出力は修正コードではなく、行動傾向と失敗の兆候である。
新規性
本研究は、新しい修正エージェントの性能競争ではなく、既存の三つのエージェントがどう作業したかを共通形式で調べる実証研究だ。「考えたこと」「実行した操作」「得られた結果」のつながりを、成功と失敗を分けて分析する。
操作の順序だけでなく、結果を次の判断に使ったか、考えと操作が一致したかを人手で分類した。最終的な修正の成否だけでは見えない、途中の行動を評価対象にした点に価値がある。
従来手法との違い
論文はRepairAgent、AutoCodeRover、OpenHandsの作業記録を比較する。RepairAgentとOpenHandsには試験を回しながら修正する流れがあり、AutoCodeRoverは探索、場所の特定、修正を短い手順で進めるという違いが報告された。
ただし、対象の課題や実装上の反復上限が同一ではない。平均反復数がAutoCodeRoverで少ないことを、修正品質の優越と直結させることはできない。比較の狙いは、各方式の作業量と失敗時の行動パターンを把握することにある。
実験結果
著者らは各エージェント40件、計120件の軌跡と2,822回の反復を調べた。平均反復数はRepairAgentが34、OpenHandsが29、AutoCodeRoverが6。平均トークン数は順に約22万、約120万、約2万3千と報告する。反復回数やトークン数は課題の難しさと設計の双方に影響される。
全体で多かった操作は修正案の生成23％、試験20％、説明20％、探索18％だった。著者らは、失敗例で同じ操作の反復や、途中の試験を欠く修正を観察した。RepairAgentでは失敗例の平均反復数40が成功例の22を上回った。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：社内のコード修正エージェントで、失敗案件を振り返るための作業記録画面を作る。入力は各操作の前の説明、実行した検索・編集・試験、返ってきた結果、最終的な試験結果である。
出力は時系列の一覧と、「同じ試験を変更なしで繰り返した」「試験失敗を成功と解釈した」といった確認候補にする。開発者が候補を読み、エージェントへの指示や停止条件を改善する。分類結果を自動的な原因確定として扱わない。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：まず一種類の修正エージェントについて、成功例と失敗例の作業記録を同じ項目で保存する。最終的な試験通過率を基準に、反復回数、トークン数、変更なしの試験再実行回数を集計する。
次に少数の記録を開発者二人で読み、前の結果を次の操作へ使ったかを独立に分類して判定の一致を確かめる。繰り返しが多い案件には停止や再計画の条件を試し、同種の課題で成功率と作業量がどう変わるかを比較する。
限界と課題
著者らの対象は三つのエージェントから各40件、計120件の標本で、全ての開発エージェントを代表するものではない。操作の8.3％は用意した分類に入らず、後続の操作分析から除外された。AutoCodeRoverの半構造化記録には推定的な解析も使っている。
導入時には、記録に残る「考えたこと」が実際の判断をどこまで表すか、分類者によって判定が変わらないかを確かめたい。失敗との相関が見えても、その行動を除けば成功率が上がるという因果関係までは、この観察研究だけでは示せない。
出典
元のタイトル・要旨を確認する（英語）
Understanding Software Engineering Agents: A Study of Thought-Action-Result Trajectories
Large Language Model (LLM)-based agents are increasingly employed to automate complex software engineering tasks, such as program repair and issue resolution. These agents operate by autonomously generating natural language thoughts, invoking external tools, and iteratively refining their solutions. Despite their widespread adoption, the internal decision-making processes of these agents remain largely unexplored, limiting our understanding of their operational dynamics and failure modes. In this paper, we present a large-scale empirical study of the thought-action-result trajectories of three state-of-the-art LLM-based agents: RepairAgent, AutoCodeRover, and OpenHands. We unify their interaction logs into a common format, capturing 120 trajectories and 2,822 LLM interactions focused on program repair and issue resolution. Our study combines quantitative analyses of structural properties, action patterns, and token usage with qualitative assessments of reasoning coherence and feedback integration. We identify key trajectory characteristics, such as iteration counts and token consumption, recurring action sequences, and the semantic coherence of thoughts, actions, and their results. Our findings reveal behavioral motifs and anti-patterns that distinguish successful from failed executions, providing actionable insights for improving agent design, including prompting strategies, failure diagnosis, and anti-pattern detection. We release our dataset and annotation framework to support further research on transparent and robust autonomous software engineering agents.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-09-29