実行結果と失敗分析
失敗率が30%だと分かっても、どこを直すべきかは分からない。全件が同じツールスキーマで失敗したのか、計画、ツール選択、検証で別々に失敗したのかによって、必要な修正は異なる。
前章では最適化ループの役割を分けた。更新候補（candidate）を作るには、最終スコアだけでなく、入力ごとの結果、動作と観測の列、例外などを最適化器（optimizer）へ返す必要がある。この章では、これらの実行フィードバック（execution feedback）から反証可能な修正仮説を作るまでを扱う。実際にどの成果物（artifact）を変更するかは次章で扱う。
実行結果から何が分かるか
実行から得られるフィードバックを、情報量の少ない順に並べる。
| 粒度 | 例 | 分かること | 分からないこと |
|---|---|---|---|
| 最終値 | 成功=0、正解率=0.6 | 更新候補間の順位 | どこで、なぜ失敗したか |
| タスク別の結果 | タスクID、期待値、実測値 | 失敗した入力 | 失敗ステップと原因 |
| 自然言語の批評 | 「表選択が誤り」 | 修正仮説 | 批評が正しいか |
| 実行軌跡（trajectory） | 動作、観測、ツール結果 | 最初のずれと後続影響 | 反実仮想の因果効果 |
| 実装診断 | 例外、遅延、権限、資源 | 実装上の失敗箇所 | 意味的な誤判断の原因 |
| 修正後の再実行 | 特定フックだけ変更して再実行 | 変更と結果の因果的な手掛かり | 他分布への一般化 |
単一スコアでは原因が消える
OPROは指示と学習スコアの履歴から次の指示を生成する (Yang ほか 2024年)。スコアだけでも更新候補を順位づけられるが、同じゼロスコアが誤ったツール選択、スキーマエラー、タイムアウトのいずれから生じたかは分からない。失敗帰属（failure attribution）は、スコアへ圧縮する前の実行軌跡へ戻り、変更候補を絞る作業である。
誤答例からテキストフィードバックを作る
ProTeGiはミニバッチの誤答を大規模言語モデル（large language model, LLM）へ与え、プロンプトの欠点を自然言語の「勾配」として記述させる。その勾配を反対方向へ適用するプロンプト編集を作り、ビーム探索（beam search）で評価する (Pryzant ほか 2023年)。ここで勾配は微分ではなく、誤答を説明するテキスト批評である。
TextGradはこの考えを計算グラフへ広げる。下流損失について自然言語フィードバックを生成し、上流のテキスト変数へ伝播させる (Yuksekgonul ほか 2025年)。GEPAはロールアウト実行記録と評価器（evaluator）のフィードバックを反省モデルへ渡し、複合システムのテキスト構成要素を変異させる (Agrawal ほか 2026年)。
テキストフィードバックはスカラーより豊かだが、正解情報ではない。批評モデルは、最終誤答からもっともらしい説明を後付けできる。次の三つを分けて保存する。
- 観測: 実際の実行軌跡と評価器出力
- 帰属仮説: 「このステップが原因」という推定
- 介入案: どの成果物をどう変えるか
仮説と観測を同じフィールドへ書くと、後から誤った帰属を検証できない。
最初のずれを特定する
最終回答だけでなく、各動作と観測を順序付きで保存し、期待状態または実行可能な制約から最初に外れたステップを探す。ただし、正解実行軌跡が存在しないタスクでは検証器（validator）自体が部分的であり、最初の明示的違反と根本原因も一致するとは限らない。早い段階の曖昧な検索が、後続の明示的エラーを誘発する場合があるためである。
実務では次の順で調べる。
- 生の実行軌跡を改変せず保存する
- 明示的な制約違反、例外、ツールエラーを基点にする
- その直前に選択されたコンテキスト、動作、分岐を確認する
- 同じ特徴を持つ他の失敗を探す
- 最小の成果物編集を作る
- 対象失敗と保持用データ集合を再実行する
- 結果が変わらなければ帰属を棄却する
失敗帰属は説明生成ではなく、介入で反証可能な仮説である。
似た失敗をまとめる
一つのタスクごとに例外処理を追加すると、ベンチマーク固有のパッチになりやすい。複数の実行軌跡から共通する失敗特徴（failure signature）を作る。
| 特徴の軸 | 例 |
|---|---|
| 段階 | 計画、検索、ツール選択、検証、復旧処理 |
| 事象 | 誤分岐、呼び出し欠落、スキーマエラー、タイムアウト |
| 証拠源 | 評価器、ツール、コンパイラ、人手ラベル |
| 事前条件 | タスク種別、ツールの版、コンテキスト長 |
| 結果 | 誤答、異常終了、コスト急増、権限違反 |
ExpeLは学習タスクの成功実行軌跡と失敗実行軌跡を比較し、未見タスクで再利用する自然言語の洞察を抽出する (Zhao ほか 2024年)。この方法はタスク横断メモリを作るが、同じテキスト洞察が異なる原因を過度に一般化する可能性がある。
Failure-Driven Workflow Refinementは、失敗実行記録（failure trace）を特徴空間へ写し、密な失敗モード（failure mode）へ制約付きグラフ編集を提案する (Zhang ほか 2026年)。失敗分布を直接扱う発想は、平均スコアだけの大域探索と異なる。ただし公開arXiv版の定量表は例示的予測であると本文に明記されており、実測値として引用できない。したがって、本書では失敗特徴に基づく機構だけを扱い、効果量の根拠には使わない。
実行軌跡から修正案を作る
フィードバックから編集を作る経路は一つではない。
| 方法 | 提案の作り方 | 代表例 |
|---|---|---|
| 直接書き換え | 誤答と批評からプロンプトを直接書き換える | ProTeGi |
| テキスト逆伝播（textual backpropagation） | 下流フィードバックを上流テキストへ伝播する | TextGrad |
| 反射的変異（reflective mutation） | 実行記録とフィードバックを要約して更新候補を変異させる | GEPA |
| 経験合成 | 成功・失敗差分から再利用する洞察を作る | ExpeL |
| 失敗モード編集 | 類似失敗クラスタ（failure cluster）へグラフ演算子を適用する | Failure-Driven Workflow Refinement |
| コード修正 | 実行時診断と実行軌跡からパッチを生成する | Meta-Harness、Harness-R1 |
Meta-Harnessの提案器は、過去の更新候補のソースコード、スコア、実行記録をファイルシステムから選択的に読む (Lee ほか 2026年)。Harness-R1の編集器は、複数の失敗実行軌跡から実行時フック（runtime hook）のパッチを生成し、コンパイル後に同じタスクバッチを再実行した差を報酬とする (Shao ほか 2026年)。
Harness-R1の対応再実行（paired rerun）は局所的な帰属検査として有用である。修正前後で対象モデル（target model）とタスクを揃えるため、差分をパッチへ対応づけやすい。一方、同じタスクバッチでパッチを作り評価する部分は観測済みタスクへの適応（transductive optimization）である。別に報告された保留タスク（held-out task）結果と混同しない。
原因の推定と採否を分ける
「この失敗は検索が原因」という帰属が正しくても、その修正を採用すべきとは限らない。検索再現率を上げるパッチが、遅延や下流コンテキスト品質を悪化させることがある。
更新候補\(c\)について、対象失敗集合\(F\)と保持用データ集合\(P\)を別に評価する。
\[ \Delta_F(c)=J_F(c)-J_F(H_t), \qquad \Delta_P(c)=J_P(c)-J_P(H_t). \]
帰属の支持には\(\Delta_F(c)>0\)が必要である。昇格（promotion）にはさらに、\(\Delta_P(c)\)、コスト、安全性、保留評価を採否規則（acceptance rule）へ入れる。対象失敗の再実行だけを昇格ゲートにしない。
評価情報の漏洩
豊富なフィードバックを最適化器へ返すほど提案は具体的になるが、評価器への過適合も容易になる。
- 期待回答を含む批評
- 隠しテストの失敗実行軌跡
- 判定プロンプトの全文
- 正確な単体テスト名や表明
- 安全フィルタの境界条件
これらを繰り返し見せると、最適化器はタスクを一般に解くハーネス（harness）ではなく、評価器を通る近道を作れる。開発用データ（development data）では詳細な実行記録を使ってよいが、昇格用検証データ（promotion validation）では返す情報を制限し、封印テスト（sealed test）は更新候補確定まで隠す。
最適化器が編集できるリポジトリにテストや評価器を置く場合は、読み取り専用パス、ハッシュ、別プロセス、別認証情報で境界を作る。評価器が外部にあることと、最適化器がその情報を利用できないことは別である。
信頼できない実行結果を扱う
ウェブページ、ツール出力、検索文書は信頼できない入力を含む。実行軌跡をそのまま編集器モデルへ渡すと、実行中に観測したプロンプトインジェクションが次の版の永続指示へ混入し得る。
- 生の観測とシステム指示を別チャネルへ保持する
- ツール出力内の命令文を提案指示として解釈しない
- パッチ提案に来歴を付ける
- 権限や認証情報へのアクセスを編集面（edit surface）外に置く
- 安全性退行テスト一式で間接プロンプトインジェクションを再実行する
コンパイルや隔離環境（sandbox）に通ることは、意味的安全性を意味しない。正常に実行できる危険なパッチもある。
版間を比較するには、タスク・実行時機構の同一性、順序付き事象、生の評価器出力、帰属、編集、検証、判断を同じ記録へ結びつける。自然言語要約だけで生の事象を置き換えない。要約モデルが見落とした失敗を後から再解析できなくなる。
要点
実行フィードバックはスカラースコアから完全実行軌跡、実行時診断、介入結果まで複数の粒度を持つ。失敗帰属はLLMの説明を信じる作業ではなく、観測、仮説、編集、再実行を分けて検証する過程である。豊富なフィードバックは提案を改善し得るが、評価器漏洩と永続プロンプトインジェクションの経路にもなる。