「AutoSaddler」とは何か──harnessの改善を「浅い内省」でなく「深いデバッグ」でやると9〜10ポイント伸びる

LLMエージェントは長期タスクにおいて依然として信頼性が低く、小さな局所的失敗が長い対話の中で積み重なり、タスク全体の失敗につながることがある。外部のharnessはこの頑健性を大きく改善できるが、harnessの設計は手作業かつ高コストなプロセスのままで、プロンプト・ツール設定・制御ロジックという広大な空間を探索する必要がある。2026年8月24日にarXivで公開された論文「AutoSaddler: Automatic Harness Optimization with Durable Updates from Agent Execution Traces」は、このharness設計そのものを自動化しようとしている。著者はPOSTECH・KAIST・南方科技大学・Microsoftの4組織にまたがる13名で、所属欄でMicrosoftと明記されているのは責任著者のJue Zhang氏を含む8名（POSTECH 2名・KAIST 2名・南方科技大学1名）。筆頭著者のSungho Park氏には「Microsoftでのインターンシップ中の成果」と注記がある。要旨だけでなくarXiv HTML版の本文とプロジェクトページも確認した。

3行まとめ

1. GAIA2のテストセットPass@1平均で、手動のDefault Agentが53.0、自動最適化の既存手法GEPAが54.6・Meta-Harnessが53.2にとどまる中、AutoSaddlerは62.0まで到達（3回実行の平均）
2. Terminal-Bench 2.0では、手動でチューニングされた「Terminus KIRA」ハーネスが47.5点と強く、AutoSaddlerは2イテレーション目の時点では45.0点でまだ下回っていた。34イテレーション進めて初めて50.0点に到達し、Terminus KIRAを上回った
3. アブレーション実験では「Generalization-Aware Selection（汎化を意識した更新選択）」を抜くとGAIA2平均が62.0→50.6まで落ち、3つの構成要素の中で最大の性能低下だった

harnessの改善を「オフライン学習問題」として定式化する

AutoSaddlerは、harnessの改善をオフライン学習問題として定式化し、ミニバッチから得られる失敗シグナルを使ってharnessを反復的に更新する自動harness最適化フレームワークだ。3つの要素を組み合わせている。失敗トレースの診断（failure-trace diagnosis）、harnessをコードそのものとして扱う構造化パッチ生成、そして検証にもとづく更新選択（validation-based update selection）だ。

3つのベンチマークで9〜10ポイントの改善

論文はGAIA2・SWE-Bench Pro・Terminal-Bench 2.0という3つのベンチマークで実験を行い、対応するベースharnessに対してエージェントの性能を大幅に改善したと報告している。改善幅はそれぞれ9.0ポイント、9.6ポイント、10.0ポイントだ。

さらにアブレーション実験（要素を1つずつ取り除いて効果を確認する実験）からは、効果的なharness最適化には3つの要素が必要だと示唆されている。表面的な内省（shallow reflection）ではなく深いデバッグ、無制約な編集ではなく的を絞った修正、そして特定の軌跡だけに対する場当たり的な修復ではなく、汎化を意識した更新選択の3つだ。論文は、これらの結果を合わせて「自動harness最適化が、より高性能で信頼性の高いエージェントシステムへの有望な道筋だ」と結論づけている。

「なぜ失敗したか」を掘るか、「とりあえず反省文を書かせるか」の差

harnessを自動で改善しようとするとき、手っ取り早いのは、失敗した後にモデル自身に「次はどうすればいいと思う？」と聞き、その答えをそのままharnessに反映させるやり方だ。論文が「浅い内省ではなく深いデバッグ」を条件に挙げているのは、この手っ取り早いやり方では不十分だという指摘だと読める。表面的な反省（「もっと注意深く読みます」といった一般論）は、次に似たような失敗が起きたときに同じように役に立たない可能性が高い。一方、失敗トレースを実際に遡って「どのステップで、どんな入力に対して、なぜ間違った判断をしたか」まで掘り下げて診断できれば、そこから得られる修正はより具体的で再現性の高いものになる。この「表面的な反省で満足しない」という設計思想は、harness最適化に限らず、人間のミス対応（なぜなぜ分析など）にも通じる考え方だ。

GAIA2での実際の数字：手動53.0→AutoSaddler62.0、既存の自動最適化手法は伸びない

論文本文のTable 2には、GAIA2（スマートフォン環境を模した汎用アシスタント評価）でのテストセットPass@1（1回目の回答での成功率）の比較が載っている。3回実行の平均値（%）は次の通り。

比較対象のGEPA・Meta-Harnessという既存の自動最適化手法は、手動のDefault Agent（53.0）から1〜2ポイントしか伸びていない。一方AutoSaddlerは62.0まで伸びており、3つのアブレーションのうち「Generalization-Aware Selection」を除いた場合の落ち込み（62.0→50.6、Default Agentの53.0すら下回る）が最も大きく、論文もこれを「全構成要素の中で最大の性能低下」と位置づけている。

Terminal-Bench 2.0：手動チューニング済みharnessに追いつくまで34イテレーション

Terminal-Bench 2.0（テストスプリット40件）の結果も本文に載っており、興味深いニュアンスがあった。

手動でチューニングされた「Terminus KIRA」というharnessは47.5点と高く、AutoSaddlerは最適化の2イテレーション目の時点（45.0点）ではまだこれに届いていない。34イテレーションまで最適化を進めて、ようやく50.0点でTerminus KIRAを上回っている。「自動最適化が常に手動チューニングより優れている」という単純な話ではなく、優れた手動harnessに追いつくまでにも一定の反復回数が必要、という実態を示す数字だ。SWE-Bench Pro（3リポジトリ平均）ではAutoSaddler 46.9に対し、GEPA 42.5・Meta-Harness 35.3・手動のSWE-agent 37.3という結果だった。

プロジェクトページのデモ：dev-setでは47.7%から72.3%まで

論文本文のPass@1（テストセット）とは別に、著者らのプロジェクトページには開発（dev）セットでの最適化過程を可視化したデモがあり、次のように説明されている。

"Starting from the default agent harness (47.7%), AutoSaddler discovers prompt rules, new tools, and agent loop fixes that push dev-set accuracy to 72.3% over two epochs."

（デフォルトのagent harness（47.7%）から出発し、AutoSaddlerはプロンプトのルール・新しいツール・エージェントループの修正を発見し、2エポックかけてdev-setの精度を72.3%まで押し上げる）

この72.3%という数字は、本文のTable 2にあるテストセットPass@1の62.0とは異なる指標（開発セット上での最適化過程のスコア）である点に注意が必要だ。最適化に使う開発セットのスコアと、最終的な未知データ（テストセット）でのスコアが異なるのは、機械学習における一般的な現象であり、論文が両方を別々に報告している点は、成果を誇張しない書き方だと言える。

最適化に使ったモデルはClaude Opus 4.6、弱いモデルにも効果が転移するか検証している

論文本文で使われているエージェントの土台モデルも確認した。Table 2・Table 3の結果は、最適化役（optimizer）とタスクを実行するエージェント本体（agent backbone）の両方に「Claude Opus 4.6」を使ったものだと明記されている。その上で付録Eでは、「強いモデルで最適化したharnessは、より弱いモデルに配備しても効果が残るか」という追加検証を行っている。

"Table 9 shows that AutoSaddler achieves an overall improvement of +5.6 pp over the default agent, demonstrating effective cross-model transferability."

（Table 9は、AutoSaddlerがデフォルトエージェントに対して+5.6ポイントの全体的な改善を達成しており、モデルをまたいだ効果的な転移が実証されたことを示している）

具体的には、Opus 4.6で最適化したharnessをそのまま変更せず、タスク実行だけ弱いモデル「Claude Haiku 4.5」に置き換えてGAIA2を再評価している。Table 9の平均値（Pass@1）は、Default Agent（手動）が30.0、GEPA（自動）が31.4、Meta-Harness（自動）が30.2にとどまる中、AutoSaddlerは35.6まで到達しており、既存の自動最適化手法を上回る形でモデル間の転移が確認されたとしている。

コストと速度：GEPAより高いが、Meta-Harnessより速い

付録Iの「End-to-End Optimization Cost Characterization」には、GAIA2上でパッチ1件を生成するのにかかる実測コストが載っている。

論文はこの数字について「AutoSaddlerはMeta-Harnessより1パッチあたり$1.91高いが、所要時間は533秒対883秒で39.6%短い」と述べている。診断・構造化パッチ生成・振り返り・進化という複数ステップを踏んでいるにもかかわらず、Meta-Harnessより実行時間が短く済んでいる点を、論文は明示的な数字で示している。なお、GAIA2の1タスクのエージェント実行1回あたりには平均20.2回のLLM呼び出し・約55万トークンの入力・203.9秒の実行時間がかかるとも記載されており、harness評価そのものが最適化操作よりずっと高コストだと説明されている。

GitHubリポジトリは実際に公開されている

論文本文が「Code」として指すリンク先はGitHubのmicrosoft/AutoSaddlerリポジトリで、実際にアクセスして中身を確認した。README.md・SECURITY.md・SUPPORT.md・pyproject.toml・uv.lockを含む17件のトップレベルファイル・ディレクトリが置かれており、Pythonパッケージとしてuv（Pythonのパッケージ管理ツール）でのビルドを想定した構成になっている。スター数は本記事確認時点（2026年8月31日）で158件だった。空のプレースホルダーではなく、実際に動くコードとして公開されていることは確認できたが、次の段落で述べる通り、コードを手元でクローンして実行し、論文のTable 2・Table 3の数値を再現する検証までは行っていない。

デモ動画そのものとGitHubコードの実行結果までは見ていない

• 論文自体は44ページ・図15点というボリュームの技術報告で、本記事は本文の中でも実験結果（Table 2・Table 3）と要旨・イントロの記述を中心に確認しており、付録に多数ある個別ケーススタディ（GAIA2・Terminal-Bench 2.0で発見されたパッチのカタログなど）までは網羅していない
• プロジェクトページで言及されている「Demo of AutoSaddler」の動画そのものは、この記事では見ていない
• GitHubリポジトリの存在とファイル構成は確認したが、実際にコードをクローンして動かし、Table 2・Table 3の数値を自分の手元で再現する検証はしていない
• GAIA2・SWE-Bench Pro・Terminal-Bench 2.0それぞれのベンチマーク自体の定義（タスクの中身・採点基準）を定めた個別の論文までは、本記事では遡って確認していない

関連記事

• ハーネスエンジニアリングとは何か──「エージェント＝モデル＋ハーネス」という考え方
• AIコーディングアシスタント比較──Copilot/Cursor/Claude Code【2026年】
• LLMベンチマークの読み方──MMLU・HumanEval・Arenaの注意点【2026年版】