失敗からハーネスを改善する
失敗したという結果だけでは、ハーネス（harness）のどこを変えるべきか分からない。まず実行記録（trace）から期待状態からの最初のずれ（first divergence）を見つけ、原因仮説と小さな修正を作る。最初のずれは診断の起点であり、原因が確定したことを意味しない。
データベース問い合わせの例
たとえば、誤ったデータベーステーブルを選んだ後に構造化問い合わせ言語（Structured Query Language, SQL）の構文エラーが出た場合、構文だけを直しても上流のずれは残る。テーブル選択を変えて再実行すれば、それが原因だったという仮説を検証できる。ただし、誤ったスキーマメタデータなど、さらに上流の要因がないかも確認する。
図 1 は、最初のずれを見つけ、その直前のフックだけを修正し、修正前後を別の評価系で比較する流れを示す。
実際にどの実行情報を保存し、最初のずれや類似失敗をどうシグネチャ化するかは、Part IIの実行結果と失敗分析で扱う。
何を更新するか
失敗から得た情報の使い方には、少なくとも三つある。
- 次回に読むメモリを更新する
- ワークフローの修正候補を作り、評価して選ぶ
- 修正候補を作る編集器自体を学習する
Reflexionは失敗後の内省をメモリへ保存し、同じタスク内の次の試行で読むコンテキストを変える (Shinn ほか 2023年)。モデルの重みは変更しないが、独立した将来タスクへ更新後の成果物（artifact）を持ち越す評価ではない。
Harness-R1は、固定した対象エージェント（target agent）とは別に編集器を置く。編集器は失敗の記録を読み、事前に決めたフックだけを変更する (Shao ほか 2026年)。同じタスク集合を修正前後で再実行し、その差から編集器を学習する。
著者報告では、WebShop、ALFWorld、DBBenchの平均成功率が44.3%から53.6%へ上昇した。差は9.3パーセントポイントである。ただし、観測済みタスクで修正を学ぶため、この結果だけでは未知のタスクにも効くとは言えない。
出典: Shao et al., “Harness-R1” (Shao ほか 2026年) の未使用タスク分析。
図 2 は、編集器が大きければ良いわけではないことを示す。ただし、3シードと限られたドメインによる結果であり、別の環境やハーネス実装へ一般化する証拠ではない。
修正できる範囲を制限する
編集器にリポジトリ全体を自由に書き換えさせる必要はない。修正範囲を次のように制限する。
- フックごとに入力と出力の形式を固定する
- ツールの権限を変更できなくする
- 壊れた修正は適用せず、元のハーネスへ戻す
- 対象の失敗だけでなく、既存の成功も再実行する
- 修正、根拠となる実行記録、評価結果を一緒に保存する
狭い修正で足りなければ、検証できる範囲を一つずつ増やす。
要点
失敗からの改善では、実行記録を保存し、最初のずれから原因仮説を作り、最小の修正で反証する。編集器を学習する場合でも、修正の採否は編集器の外側で決める。