概要
大規模言語モデル (LLM) システムの性能は、モデルのパラメータだけでなく、その `ハーネス` にも依存します。ハーネスとは、モデルにどのような情報を保存し、取得し、提示するかを決定するコードのことです。しかし、現在のハーネスは依然として手作業で設計されることが多く、既存のテキスト最適化ツールは、この状況には適していません。なぜなら、それらはフィードバックを過度に圧縮するからです。それらは、過去の情報を記憶しておらず、スカラー値のみに基づいて判断したり、フィードバックを短いテンプレートや要約に制限したりします。そこで、私たちは LLM アプリケーション向けのハーネスコードを探索する、外側のループシステムである `Meta-Harness` を提案します。これは、エージェントベースの提案システムを使用しており、ファイルシステムを通じて、すべての候補のソースコード、スコア、および実行履歴にアクセスします。オンラインテキスト分類タスクにおいて、Meta-Harness は、最先端のコンテキスト管理システムを 7.7 ポイント 上回る性能を発揮し、同時に 4 倍少ないコンテキストトークン で済みます。検索拡張型数学推論タスクでは、発見された単一のハーネスが、5 つの検証済みモデル全体で、200 個の IMO レベルの問題 に対する精度を平均 4.7 ポイント 向上させました。エージェントベースのコーディングタスクでは、発見されたハーネスが、TerminalBench-2 において、最も優れた手作業で設計されたベースラインを上回る性能を示しました。
はじめに
「Harness」とは?
AIシステムにおいて、「Harness(ハーネス)」とは、LLM(大規模言語モデル)を包み込むコードであり、モデルが「何を見るか」を制御します。これはモデルの重みそのものではなく、むしろ「配管」のようなものです。具体的には、関連ドキュメントの取得方法、プロンプトの整形、ターン間のメモリ管理、モデルの出力構造などを定義します。 **例:** AIカスタマーサポートボットを想像してみてください。この「ハーネス」が決定するのは、「顧客の注文履歴を応答前に参照するか?」「過去のメッセージをいくつ含めるか?」「「簡潔に」というシステムプロンプトを追加するか?」などです。これらのハーネスの決定を変更するだけで、ボットのパフォーマンスが劇的に変化することがあります。これは、モデル自体が全く同じ場合でも起こり得ます。 この論文では、同じモデルを使用した場合でも、ハーネスの違いだけで「6倍のパフォーマンス差」が存在することを示しています。Meta-Harnessは、最適なハーネスを自動的に検索します。大規模言語モデルの動作を調整する「ハーネス(harness)」を変更することで、同じベンチマークにおいて最大6倍の性能差が生じる可能性があります。このハーネスとは、モデルに何が保存され、どのように取得され、どのように表示されるかを決定するコードであり、モデルそのものほど重要である場合もあります。しかし、その重要性にもかかわらず、ハーネスの設計は依然として主に手作業で行われています。専門家は、問題箇所を調査し、ヒューリスティックを調整し、限られた数の設計を繰り返します。
既存の手法がうまくいかない理由:"圧縮されたフィードバック"の問題
多くのAI最適化手法では、フィードバックを簡潔な要約として送信します。これは、単一のプロンプトを最適化する場合には有効ですが、ハーネスエンジニアリングには適していません。その理由は以下の通りです。
- ハーネスは長距離の影響を持つ。ステップ1での「何を検索するか」という決定が、ステップ20でのモデルの成功に影響を与える可能性があります。単に「合格率62.9%」というスコアでは、結果は分かりますが、なぜそうなるのかが分かりません。ハーネスを修正するためには、その理由を知る必要があります。
- 実行トレースには診断が含まれている。モデルが何を見たか、何を試したか、どこでつまずいたかという完全なログは、多くの場合、数百万トークンにも及びます。これは、圧縮された要約では正確に表現できません。
Meta-Harnessの洞察は、最適化アルゴリズムに、この生のデータすべてへの直接的なファイルシステムアクセス権を与え、そしてアルゴリズム自身が何を読むべきかを判断させることです。そのため、Meta-Harnessは、単純なLLMプロンプトではなく、コーディングエージェント(grepやcatコマンドを実行できるもの)を使用しています。
自然な出発点としては、最近の研究されたテキスト最適化手法が挙げられます。なぜなら、テスト自動化エンジニアリングも、過去の試行からのフィードバックを用いて、テキストやコードの構成要素を反復的に改善するプロセスを含むからです。しかし、これらの手法は、テスト自動化エンジニアリングには必ずしも適していません。なぜなら、それらは短期間のフィードバックや、高度に圧縮されたフィードバックに基づいて動作するからです。具体的には、一部は現在の候補のみに基づいており、他のものは主にスカラー値のスコアに依存し、さらに他のものはフィードバックを短いテンプレートやLLMが生成した要約に限定しています。代表的なテキスト最適化手法において、最適化の各ステップで利用可能なコンテキストは、わずか100から30,000トークン(表1)の範囲に留まっており、これはテスト自動化における診断に必要な情報量よりもはるかに少ないのです。
この制限を解決するために、Meta-Harnessという、エンドツーエンドの探索を通じてハーネスを最適化するためのエージェントベースのシステムを開発しました。このシステムの提案者は、コーディングエージェントであり、言語モデルに基づいたシステムで、開発者ツールを呼び出し、コードを修正することができます。その重要な設計上の特徴は、ファイルシステムを通じて完全な履歴を公開することです。これにより、最適化された要約ではなく、生の過去のコードや実行トレースを選択的に診断することができます。実際には、提案者は1回の反復で平均82個のファイルを読み込み、ステップごとに20個以上の過去の候補を参照しています。1回の評価で生成される診断情報は最大で10,000,000トークンに達し、これは従来のテキスト最適化の設定と比較して、およそ3桁大きい数値です。
表1:テキスト最適化手法の比較
| Method | History | Log Content | MTok/iter |
|---|---|---|---|
| OPRO | Window | past (solution, score) pairs | 0.002 |
| TextGrad | Last | textual feedback on current artifact | 0.015 |
| AlphaEvolve | Window | program database + eval. scores | 0.022 |
| GEPA | Summary | reflective feedback from rollout traces | 0.008 |
| Feedback Descent | Summary | comparison + textual feedback | 0.012 |
| TTT-Discover | Window | prev. solution fragment | 0.026 |
| Meta-Harness | Full | all logs and scores | 10.0 |
Meta-Harnessを、オンラインテキスト分類、数学的推論、およびエージェントベースのコーディングの分野で評価しました。これにより、過去の経験へのより詳細なアクセスが、多様な分野にわたる自動的なハーネスエンジニアリングを可能にすることを示しました。
Meta-Harness:ハネスを最適化するためのハネス
`Harnessとは、言語モデルを包み込み、モデルが各ステップでどのようなコンテキストを見るかを決定する、状態を持つプログラムです。ある`Harness (H) とタスクインスタンス (x ∈ X') に対して、ロールアウト軌道 (T) を P_M(H, x) に従って実行します。`Harness'はモデル (M) にプロンプトを生成し、モデルが応答し、`Harness'は各インタラクション後に自身の状態を更新します。
目的は、期待される最終的な報酬を最大化するハーネスを見つけることです。具体的には、\(H^* = \arg\max_H \mathbb{E}_{x \sim \mathcal{X}', T \sim P_M(H,x)} r(T, x)\) となります。複数の目的が関連する場合(例えば、精度とコンテキストコストなど)、候補を パレート最適性 の観点から評価し、その結果得られるフロンティアを報告します。
正式な目的 — 平易な言葉で
数式で表される目的 H* = argmax E[r(T, x)] は、次のような意味を表しています。 **「平均的なタスクのパフォーマンスを可能な限り高くするための、最適なハーネスコード H を見つける。」**- H = ハーネス (最適化対象のコード)
- M = 固定された大規模言語モデル (LLM) (例: GPT-OSS-120B)。その重みは決して変化しません。
- x ~ X' = ランダムに選択されたタスク (例: 「この法的文書を分類する」)
- T ~ P_M(H, x) = ハーネス H をタスク x で実行した結果得られる、一連の操作 (プロンプト、モデルの応答、ツールの呼び出し)
- r(T, x) = その一連の操作に対する報酬/スコア (例: 分類結果は正解と一致したか?)
パレート最適性: 2つの目的 (精度とコンテキストトークンの使用量) を同時に最適化する場合、単一の「最適な」解はありません。代わりに、一方の指標を改善すると、もう一方の指標が低下するような、トレードオフの関係にある領域が存在します。Meta-Harness は、このトレードオフの関係全体を自動的にマッピングします。
検索ループ.
Meta-Harnessは、単一のコーディングエージェント(Claude Code with Opus-4.6)を使用しており、このエージェントは、フィードバックチャネルとして機能する、拡張可能なファイルシステムにアクセスできます。 従来のシステムが、手作業で設計された探索ループに改善ロジックを外部化するのに対し、Meta-Harnessは、診断と提案をコーディングエージェント自体に委ねます。 具体的には、エージェントが、どの既存の成果物を検査するか、どの種類のエラーに対処するか、そして、ローカルな編集を行うか、より大規模な書き換えを行うかを決定します。
評価対象の各ハーネスは、ソースコード、スコア、および実行トレースを含むディレクトリを提供します。ファイルシステムは通常、提案者のコンテキストウィンドウよりもはるかに大きいので、提案者は、単一のプロンプトとして全体を読み込むのではなく、`grep` や `cat` などのターミナルツールを使用してファイルシステムを検索します。最も負荷の高い設定では、提案者は1回の反復で平均82個のファイルを読み込み、各ステップで20件以上の過去の候補を参照しています。
ファイルシステムアクセスが重要な革新である理由
多くの最適化システムは、最適化エンジンが参照できる情報に固定された「範囲」を持っています。Meta-Harnessは、*あらゆるもの*をファイルシステムに保存し、コーディングエージェントが何を読むかを決定できるようにします。各ハーネスに含まれるファイルシステムの内容:
- ハーネスのソースコード
- すべての実行トレース—評価中のすべてのLLM呼び出し、ツールの呼び出し、および状態更新の完全なログ
- 評価スコア
これにより、真の因果関係に基づく推論が可能になります。「私の直前の2つのハーネスはどちらも性能が低下している。そのトレースを確認してみよう...両方ともプロンプトにクリーンアップ指示が含まれていた。その変数を特定してみよう。」これは、人間のエンジニアが実際に行うことと全く同じです。つまり、失敗事例を調査し、仮説を立て、それを検証します。Meta-Harnessは、そのプロセスを自動化します。
# Input: tasks X', LLM M, proposer P, iterations N
Initialize: population H # initial set of valid harnesses
Initialize: filesystem D ← ∅ # stores code, scores, traces
for H ∈ H do:
E_H ← Evaluate(H, M, X')
D ← D ∪ {(H, E_H)}
for t = 1 ... N do:
# Proposer P queries filesystem D
# inspects prior harnesses and scores
P proposes k new harnesses {H₁, ..., Hₖ}
for H ∈ {H₁, ..., Hₖ} do:
if H passes interface validation then:
D ← D ∪ {(H, Evaluate(H, M, X'))}
return Pareto frontier of harnesses in D
実際には、提案者PはClaude Codeで、使用モデルはOpus-4.6です。典型的な実行では、約20回の反復で60個のデータセットが処理されます。単一の評価で生成される診断情報のトークン数は、最大で10,000,000トークンに達する可能性があります。
ファイルシステムをフィードバックチャネルとして活用する
圧縮された要約の代わりに、提案者はgrep/catを使用して、生のコード、実行トレース、およびスコアに直接アクセスします。エージェントは、何を確認するかを決定し、これにより、損失のある要約から得られる最適化ではなく、根本原因の選択的な診断が可能になります。
コード空間検索
各ハーネス(Harness)は、完全なPythonプログラムです。検索、メモリ、またはプロンプト構築のロジックに小さな変更を加えるだけで、その後の多くの推論ステップに影響を与える可能性があります。コーディングモデルは、本質的に、もろいハードコーディングされた解決策ではなく、一貫性のあるアルゴリズムに偏りがちです。
創発戦略
固定された構造、アーカイブ、または永続的なメモリ機構は存在しません。提案者は、多くの場合、強力な事前知識に基づいて出発点とします。これは、あらかじめ決められたルールではなく、自律的に発展する戦略です。検索プロセスは、コーディングエージェントの能力が向上するにつれて、自動的に改善されます。
実験1:オンラインテキスト分類
我々は、オンラインテキスト分類の標準的な設定に従います。具体的には、LLM(大規模言語モデル)がラベル付きのサンプルを一つずつ受け取り、その情報を記憶に反映させ、そして、検証データセットを用いて評価を行います。分類器としてGPT-OSS-120Bを使用し、20回の進化イテレーションを実行します。各イテレーションでは、2つの候補を使用し(合計40の構成)、初期値として、ゼロショット、フューショット、ACE、およびMCEのベースラインを使用します。
Meta-Harnessは、すべての既存のベースラインモデルを上回る性能を発揮しました
表2:データセットごとのテストセットにおける精度
| Harness | USPTO | S2D | LawBench | Avg Acc | Ctx (K) |
|---|---|---|---|---|---|
| Zero-Shot | 12.0 | 63.2 | 7.0 | 27.4 | 0 |
| Few-Shot (8) | 14.0 | 67.9 | 21.0 | 34.3 | 2.0 |
| Few-Shot (32) | 13.0 | 72.2 | 21.0 | 35.4 | 7.9 |
| Few-Shot (all) | 15.0 | 78.3 | 29.0 | 40.8 | 12.3 |
| MCE | 14.0 | 83.0 | 23.0 | 40.0 | 28.5 |
| ACE | 16.0 | 77.8 | 29.0 | 40.9 | 50.8 |
| Meta-Harness | 14.0 | 86.8 | 45.0 | 48.6 | 11.4 |
アブレーションの結果が驚くべき理由
表3には驚くべき結果が示されています。LLMによって生成された実行トレースの要約 (Scores + Summary) を追加すると、実際には、スコアのみの場合よりも 性能が低下 します (Best Acc: 38.7% vs 41.3%)。なぜでしょうか? 考えられる理由: 要約によって診断に必要な情報が失われる。 LLMが「検索の失敗が原因でハーネスが失敗した」という要約を行う場合、生のトレースから見える具体的な失敗パターンが圧縮されてしまいます。提案者は、どの入力が具体的に失敗を引き起こしたのか、モデルが実際にどのような出力を生成したのか、そして失敗モードが一貫していたかどうかを把握できなくなります。 これは直感に反するかもしれません。つまり、圧縮された情報が、量としては少ないものの生のデータよりも劣る ことがあるのです。特に、ハーネスエンジニアリングのような体系的な最適化タスクにおいてはそうです。表3:アブレーション分析:どの情報が重要か?
| Method | Scores | Code | Summaries | Traces | Median Acc | Best Acc | >ZS |
|---|---|---|---|---|---|---|---|
| Scores Only | ✓ | ✓ | ✗ | ✗ | 34.6 | 41.3 | 26 |
| Scores + Summary | ✓ | ✓ | ✓ | ✗ | 34.9 | 38.7 | 23 |
| Meta-Harness (full) | ✓ | ✓ | — | ✓ | 50.0 | 56.7 | 39 |
精度と文脈のトレードオフ
Meta-Harnessは、ハーネスコードに対して自由形式の最適化を行うため、精度とコンテキストコストの両方に対する総合的な好みを表現できます。提案者は、パレート最前線の広範囲にわたるハーネスを発見し、これにより、滑らかな精度-コンテキストの曲線が得られます。これにより、あらかじめ設計された単一の動作点に固定するのではなく、制御された方法で、より高い精度に対して追加のコンテキストをトレードオフすることができます。
表4:テキスト最適化ツールとの比較(検索セット)
| Method | Median | Best |
|---|---|---|
| GEPA | 32.6 | 40.2 |
| Best-of-N | 34.0 | 44.2 |
| OpenEvolve | 39.1 | 43.3 |
| TTT-Discover | 34.1 | 45.6 |
| Meta-Harness | 50.0 | 56.7 |
「OOD汎化」が私たちに教えてくれること
OOD = 分布外 (Out-of-Distribution): これらの9つのデータセットは、探索プロセス中に一度も使用されていませんでした。Meta-Harnessが、これらの未知のタスクで平均73.1%のスコアを記録し、ACEの70.2%を上回ったことは、発見されたハーネスが、特定の探索セットに特化したテクニックではなく、一般的に有効な戦略を学習していることを裏付けています。注目すべきは、32を超える少量のサンプルを追加すると、9つのタスクのうち7つでパフォーマンスが低下することです。これは、賢い検索戦略なしに、単純なコンテキストのスケーリングは逆効果になる可能性があることを示唆しています。
表5:分布外汎化 (9つの未知のデータセット)
| Harness | SciC | FINER | Amz5 | FPB | GoEmo | Bank77 | News | SciT | TwHate | Avg Acc | Ctx ↓ |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Zero-shot | 32.7 | 56.0 | 52.7 | 90.0 | 42.0 | 80.7 | 84.7 | 89.3 | 75.3 | 67.0 | — |
| Few-shot (8) | 34.0 | 63.0 | 54.0 | 90.0 | 44.0 | 82.7 | 84.7 | 91.3 | 76.7 | 68.9 | 2.2 |
| Few-shot (32) | 38.7 | 62.0 | 53.3 | 90.7 | 43.3 | 86.0 | 85.3 | 90.7 | 76.7 | 69.6 | 5.2 |
| Few-shot (all) | 35.3 | 61.0 | 50.0 | 93.3 | 42.7 | 80.7 | 84.0 | 90.0 | 76.7 | 68.2 | 7.4 |
| ACE | 40.7 | 74.0 | 48.0 | 96.7 | 44.0 | 83.3 | 86.0 | 90.7 | 68.7 | 70.2 | 11.7 |
| Meta-Harness | 53.3 | 67.0 | 60.0 | 94.0 | 46.0 | 82.7 | 86.7 | 91.3 | 77.3 | 73.1 | 7.3 |
実験2:検索機能強化型数学的推論
我々は、500,000件以上の解答済み問題を含むデータベースからの検索機能と組み合わせた、オリンピックレベルの数学問題の解答方法を研究しています。単純な検索では、数学のベンチマークにおいてほとんどの場合うまくいきません。成功するためには、適切な検索ポリシーを発見する必要があります。我々は、そのポリシーを手作業で設計するのではなく、Meta-Harnessに厳選されたオリンピックの問題セットを与え、検索を通じて検索の振る舞いが自律的に進化するようにしています。
私たちは、250の問題セット(OlympiadBench + Omni-MATH hard)に対して40回の反復を行い、109個の候補となる検索システム(harness)を生成しました。その中から1つのシステムを選択し、IMO-AnswerBench、IMO-ProofBench、およびArXivMathから収集した、これまでに見たことのない200の問題(IMOレベル)で評価します。さらに、検索中に一度も使用されなかった4つのモデルも評価対象とします。
BM25検索とpass@1の説明
BM25は、キーワードに基づいた古典的な検索アルゴリズムであり、多くの検索エンジンの基盤となっています。数学の問題の場合、BM25は、数学的なキーワード(「組み合わせ論」、「合同算術」、「凸多角形」など)のマッチングによって、類似した以前に解決された問題を検索します。
単純なBM25では、誤った問題を検索してしまうことがあります。Meta-Harnessの解決策は、4つの経路を持つ語彙ルーターです。これは、問題の種類を特定し、経路ごとに異なるBM25パラメータを適用します。具体的には、異なるk値、重複排除の閾値、および再ランキングルールを使用します。これらのパラメータはすべて、40回の検索反復を通じて自動的に調整されます。
pass@1: モデルが、最初の試行で問題を解決する確率(3つのサンプルでの平均値)。これは、競技数学における標準的な評価指標です。
表6:検索拡張型数学の結果(IMOレベルの問題20問)
| Method | GPT-5.4n | GPT-5.4m | Gem-3.1FL | Gem-3F | GPT-20B | Avg. |
|---|---|---|---|---|---|---|
| No Retriever | 23.0 | 28.8 | 28.6 | 42.6 | 47.6 | 34.1 |
| Dense Retrieval (k=1) | 27.1 (+4.1) | 24.5 (-4.3) | 31.3 (+2.7) | 42.3 (-0.3) | 46.9 (-0.7) | 34.4 (+0.3) |
| Dense Retrieval (k=5) | 31.1 (+8.1) | 28.3 (-0.5) | 37.1 (+8.5) | 47.2 (+4.6) | 46.7 (-0.9) | 38.1 (+4.0) |
| Random Few-shot | 23.1 (+0.1) | 24.5 (-4.3) | 31.0 (+2.4) | 40.4 (-2.2) | 41.8 (-5.8) | 32.2 (-1.9) |
| BM25 Retrieval | 30.2 (+7.2) | 29.2 (+0.4) | 32.8 (+4.2) | 46.6 (+4.0) | 48.9 (+1.3) | 37.5 (+3.4) |
| Meta-Harness | 31.7 (+8.7) | 30.4 (+1.6) | 34.9 (+6.3) | 46.3 (+3.7) | 50.6 (+3.0) | 38.8 (+4.7) |
実験3:TerminalBench-2上でのエージェント主導型コーディング
TerminalBench-2 は、長期的な視野を持ち、複雑な依存関係下で完全に自律的に実行される89の困難なタスクにおいて、LLMエージェントを評価します。使用するハーネスの選択は、パフォーマンスに大きな影響を与えます。検索は、Terminus 2とTerminus-KIRAという2つの強力なオープンソースのベースラインから開始し、10回の検索イテレーションを実行しました。進化させたハーネスには、タスク固有の文字列が漏洩していないことを、手動で確認しました。
表7:TerminalBench-2 リーダーボード
| Agent | Auto | Pass Rate (%) |
|---|---|---|
| Claude Opus 4.6 | ||
| Claude Code | ✗ | 58.0% |
| Terminus 2 | ✗ | 62.9% |
| Mux | ✗ | 66.5% |
| Droid | ✗ | 69.9% |
| TongAgents | ✗ | 71.9% |
| MAYA-V2 | ✗ | 72.1% |
| Terminus-KIRA | ✗ | 74.7% |
| Capy | ✗ | 75.3% |
| Meta-Harness AUTO | ✓ | 76.4% |
| ForgeCode | ✗ | 81.8% |
| Claude Haiku 4.5 | ||
| OpenHands | ✗ | 13.9% |
| Claude Code | ✗ | 27.5% |
| Terminus 2 | ✗ | 28.3% |
| Mini-SWE-Agent | ✗ | 29.8% |
| Terminus-KIRA | ✗ | 33.7% |
| Goose | ✗ | 35.5% |
| Meta-Harness AUTO 🏆 #1 | ✓ | 37.6% |
TerminalBench-2とは?
TerminalBench-2は、AIエージェントが、コマンドライン環境で、複雑な依存関係を持つコードのコンパイル、サービスのセットアップ、複数ファイルプロジェクトのデバッグなど、89個の困難な実世界でのソフトウェアタスクを、自律的に完了させるためのベンチマークです。これらのタスクは、専門知識と多段階の推論を必要とする、長期的な処理を伴います。
現在、活発に競合が行われており、複数の業界チームが、自社のシステムをこのベンチマークのために直接最適化しています。自動化された検索方法が、Haiku 4.5エージェントの中で1位になることは注目に値る結果であり、Meta-Harnessが、非常に競争の激しい最先端の領域においても、改善点を見つけることができることを示しています。
"Auto"列 (✓/✗): ハーネスが、自動的に発見されたもの(Meta-Harnessによる)か、人間の専門家によって手作業で作成されたものかを示します。
検索履歴からの因果推論
この検索プロセスは、Meta-Harnessがどのように性能向上を達成しているかを示しています。初期の試行では、構造的な修正とプロンプト・テンプレートの編集を組み合わせましたが、どちらも性能低下を引き起こしました。3回目の試行で、提案者は性能低下の原因が共通のプロンプトによる影響であるという仮説を立て、構造的な変更を分離し、個別にテストしました。6回の試行を経て、彼は純粋に加算的なアプローチに切り替えました。これは、最初のLLMへの呼び出しの前に環境情報を追加するもので、推論フロー自体には変更を加えませんでした。
「これまでの6つのバージョンは、いずれも64.4%という基準値を下回っていました。これは、完了フロー、プロンプトテンプレート、または観察データの処理を変更したためです。evo_env_bootstrapは、全く異なるアプローチを採用しています。これは、既存の機能にものを加える形です。具体的には、最初のLLM呼び出しの前に環境のスナップショットを取得し、それを初期プロンプトに追加します。その他の部分は変更されていません。」
因果推論の実践 — イテレーション7
検索の軌跡は、ランダムな探索ではなく、体系的なデバッグを示しています。
- イテレーション1–2: 両方の候補において、構造的な修正とプロンプトの変更が同時に行われました。両方とも問題が発生しました(リグレッション)。
- イテレーション3: 提案者は、両方の失敗トレースを調査し、共通のプロンプトの変更が原因であることに気づき、構造的な修正のみをテストしました。
- イテレーション4–6: まだ、コンプリート処理ロジックを安全に修正できませんでした。得られた教訓:「コンプリートフローに手を出すことは、非常にリスクが高い」。
- イテレーション7: 戦略を変更しました。既存のものを変更せず、最初のLLM呼び出しの前に環境のスナップショットを追加するだけです。完全に付加的な変更であり、リグレッションのリスクはありません。これが成功しました。
これは、熟練したエンジニアがデバッグを行う方法を反映しています。仮説を立て、変数を分離し、証拠を蓄積し、特定の介入方法が脆弱であることがわかった場合に、戦略を転換します。
発見されたハーネスの内部構造
Meta-Harnessは、実行可能な推論時プロシージャを発見します。これらは、複雑な制御フローを持つ、構造化された、ドメイン固有のポリシーです。本稿では、パレート最適の極端を表す2つのテキスト分類ハーネスのバリアント、および汎化に関する証拠について検討します。
表9:発見されたテキスト分類モデルのパレート最適解
| Variant | USPTO ↑ | Symptom ↑ | LawBench ↑ | Avg ↑ | Ctx ↓ |
|---|---|---|---|---|---|
| Draft Verification | 18.0 | 85.4 | 17.0 | 40.1 | 5.4 |
| Error-Annotated | 9.0 | 87.7 | 24.0 | 40.2 | 22.3 |
| CoT Replay | 13.0 | 88.2 | 25.0 | 42.1 | 23.3 |
| Cluster Coverage | 12.0 | 86.8 | 33.0 | 43.9 | 31.2 |
| Cascade Retrieval | 12.0 | 86.8 | 36.0 | 44.9 | 39.2 |
| Label-Primed Query | 14.0 | 86.8 | 45.0 | 48.6 | 11.4 |
主な調査結果
10倍高速、10点以上の性能向上
テキスト分類において、Meta-Harnessは、既存のテキスト最適化手法(OpenEvolve、TTT-Discoverなど)の中から最適なものを選択し、評価回数を10分の1に抑えながら、最終的な精度を10ポイント以上向上させます。また、Meta-Harnessが生成する中央値の候補は、いずれかの手法による最適化で得られた最良の候補よりも優れた性能を発揮します。
IMO数学におけるクロスモデル転移
発見された単一の検索機構(harness)は、200個のIMOレベルの問題に対する5つの評価モデルにおいて、平均して4.7ポイントの精度向上をもたらします。この機構は、GPT-OSS-20Bの性能に基づいて選択されましたが、GPT-5.4-nano、GPT-5.4-mini、Gemini-3.1-Flash-Lite、およびGemini-3-Flashにも適用可能です。
TerminalBench-2 (Haiku 4.5) における #1 のエージェント
Meta-Harnessは、TerminalBench-2という、複数のチームが直接最適化を行う活発なベンチマークにおいて、Haiku 4.5エージェント全体で1位(37.6%)、Opus 4.6エージェント全体で2位(76.4%)となる最適な設定を自動的に発見します。
議論
分布外汎化 (Out-of-Distribution Generalization)
発見された手法は、未知の分類データセット(9つのOODタスクで平均+2.9ポイントの向上)や、未知の基本モデル(5つの検証モデルで合計+4.7ポイントの向上)にも適用可能であることが示されました。これは、発見された戦略が、一般的に有効なコンテキスト管理の原則を捉えていることを示唆しています。
高速な実行時間
検索処理は数時間で完了しますが、その結果として得られるのは、現在のモデルだけでなく、将来のモデルにも適用可能な、理解しやすく、再利用可能な戦略です。これらのプログラムは、完全にPythonで記述されており、エンジニアによって解釈および修正が可能です。
検証可能な過学習
コード空間における過学習(脆いif文の連鎖、ハードコーディングされたクラスのマッピングなど)は、観察することで明らかになります。これは、重み空間における過学習とは異なります。これにより、発見された仕組みが本当に汎用的なものなのか、それとも単に記憶しているだけのものなのかを検証しやすくなります。
より豊富な経験が重要です
主な利点は、単にコードを検索することではなく、ことです。提案者は、生のコード、実行履歴、および過去の失敗事例を調査し、変更すべき点に関する因果関係の仮説を立て、それを検証することができます。
私たちの研究結果は、機械学習における一般的な傾向を反映しています。つまり、探索空間が利用可能になると、特定のタスクに合わせて設計された手法よりも、より汎用的なエージェントの方が優れた性能を発揮する傾向があります。次に自然なステップとして、戦略とモデルのパラメータを同時に進化させることを考えられます。これにより、戦略がモデルの学習を促進し、同時にモデルが戦略を改善するという相互作用が生まれる可能性があります。
「苦い教訓」との関連性
この論文では、Rich Sutton氏の「苦い教訓」(2019年)が参照されています。これは、AIにおける一般的な傾向であり、計算を活用する汎用的な手法が、手作業で作られた解決策を最終的に上回るというものです。チェスエンジン→囲碁プログラム→タンパク質構造予測→現在では、エンジニアリングが活用されています。Meta-Harnessは、この傾向に合致しています。自動検索と強力なコーディングエージェントの組み合わせが、長年の人間のハーネス工学の専門知識を上回ります。このことを可能にしているのは、近年成熟した、大規模なコードベースを自律的にナビゲートできるコーディングエージェントです。
私たちの実験では、特に強力なコーディングエージェントであるClaude Code (Opus-4.6)を用いたハーネス探索について示しました。しかし、提案エージェントや、性能の低いモデルにおける効果の違いについては、今後の研究課題となります。
結論
Meta-Harnessは、自動的なハネスエンジニアリングが、多様な分野で実用的かつ効果的であることを示しています。Meta-Harnessは、コーディングエージェントが、共有ファイルシステムを通じて、過去の候補のソースコード、実行トレース、および評価スコアへの限定的なアクセス権を持つようにすることで、テキスト分類、数学的推論、およびエージェントによるコーディングにおいて、手作業で作成されたベースラインよりも優れた性能を発揮するハネスを発見できます。これらのハネスは、可読性が高く、移植可能であり、効率的に発見可能です。
これらの結果を総合的に見ると、過去の経験へのアクセスがより豊かになることで、自動化されたハーネス設計が可能になることが示唆されます。
謝辞
KRAFTON AIにご提供いただいたAPIクレジットに感謝申し上げます。本研究は、OpenAI、KFAS、およびSchmidt Sciences AI2050からの支援を受けて実施されました。また、Anikait Singh氏とJubayer Ibn Hamid氏には、貴重なフィードバックとご提案をいただき、Sienna J. Lee氏には、研究初期段階においてYL氏の未熟な考えを辛抱強く聞いていただき、深く感謝申し上げます。
参考文献
参考文献 (60件)
- [1] Agrawal et al. GEPA: Reflective prompt evolution can outperform reinforcement learning. arXiv:2507.19457, 2025.
- [2] Akyürek et al. What learning algorithm is in-context learning? Investigations with linear models. arXiv:2211.15661, 2023.
- [3] Andrychowicz et al. Learning to learn by gradient descent by gradient descent. NeurIPS, 2016.
- [4] Anthropic. Claude code: An agentic coding tool. https://www.anthropic.com/claude-code, 2025.
- [5] Anthropic and community contributors. agentskills/agentskills. GitHub repository, 2026.
- [6] Balunović et al. Matharena: Evaluating LLMs on uncontaminated math competitions. 2025.
- [7] Barbieri et al. TweetEval: Unified benchmark and comparative evaluation for tweet classification. 2020.
- [8] Beurer-Kellner et al. Prompting is programming: A query language for LLMs. PLDI, 2023.
- [9] Böckeler. Harness engineering. martinfowler.com, March 2026.
- [10] Bölük. I improved 15 LLMs at coding in one afternoon. only the harness changed. 2026.
- [11] Casanueva et al. Efficient intent detection with dual sentence encoders. arXiv:2003.04807, 2020.
- [12] Cemri et al. AdaEvolve: Adaptive LLM driven zeroth-order optimization. arXiv:2602.20133, 2026.
- [13] Chase. LangChain. GitHub, 2022.
- [14] Cohan et al. Structural scaffolds for citation intent classification. arXiv:1904.01608, 2019.
- [15] Demszky et al. GoEmotions: A dataset of fine-grained emotions. arXiv:2005.00547, 2020.
- [16] Fei et al. LawBench: Benchmarking legal knowledge of LLMs. EMNLP, 2024.
- [17] Finn et al. Model-agnostic meta-learning for fast adaptation of deep networks. ICML, 2017.
- [18] ForgeCode. Benchmarks don't matter. 2025.
- [19] Gretel AI. Symptom to diagnosis dataset. HuggingFace, 2023.
- [20] Hu et al. Automated design of agentic systems. ICLR, 2025.
- [21] Young. Effective harnesses for long-running agents. Anthropic Engineering Blog, 2025.
- [22] Keung et al. The multilingual Amazon reviews corpus. arXiv:2010.02573, 2020.
- [23] Khattab et al. DSPy: Compiling declarative LM calls into self-improving pipelines. arXiv:2310.03714, 2023.
- [24] Khot et al. SciTail: A textual entailment dataset from science question answering. AAAI, 2018.
- [25] KRAFTON AI and Ludo Robotics. Terminus-KIRA: Boosting frontier model performance on TerminalBench. GitHub, 2026.
- [26] Lee et al. Feedback Descent: Open-ended text optimization via pairwise comparison. arXiv:2511.07919, 2025.
- [27] Lehman et al. Evolution through large models. arXiv:2206.08896, 2022.
- [28] Lewis et al. Retrieval-augmented generation for knowledge-intensive NLP tasks. NeurIPS, 2020.
- [29] Loukas et al. FINER: Financial numeric entity recognition for XBRL tagging. ACL, 2022.
- [30] Luong et al. Towards robust mathematical reasoning. EMNLP, 2025.
- [31] Madaan et al. Self-Refine: Iterative refinement with self-feedback. NeurIPS, 2023.
- [32] Malo et al. Good debt or bad debt: Detecting semantic orientations in economic texts. arXiv:1307.5336, 2013.
- [33] Merrill et al. TerminalBench: Benchmarking agents on hard, realistic tasks in CLI. arXiv:2601.11868, 2026.
- [34] Nichols. How we scored #1 on terminal-bench (52%). Warp blog, 2025.
- [35] Novikov et al. AlphaEvolve: A coding agent for scientific and algorithmic discovery. arXiv:2506.13131, 2025.
- [36] OpenAI. Harness engineering: leveraging Codex in an agent-first world. OpenAI Blog, 2026.
- [37] Packer et al. MemGPT: Towards LLMs as operating systems. 2023.
- [38] Pryzant et al. Automatic prompt optimization with "gradient descent" and beam search. arXiv:2305.03495, 2023.
- [39] Romera-Paredes et al. Mathematical discoveries from program search with LLMs. Nature, 2024.
- [40] Schmidhuber. A neural network that embeds its own meta-levels. IEEE ICNN, 1993.
- [41] Schneider et al. What's what: The (nearly) definitive guide to reaction role assignment. JCIM, 2016.
- [42] Shakya et al. Adaptive retrieval helps reasoning in LLMs – but mostly if it's not used. arXiv:2602.07213, 2026.
- [43] Sharma. OpenEvolve: an open-source evolutionary coding agent. GitHub, 2025.
- [44] Snell et al. Prototypical networks for few-shot learning. NeurIPS, 2017.
- [45] Sutton. The bitter lesson. 2019.
- [46] Thrun and Pratt. Learning to learn: Introduction and overview. Springer, 1998.
- [47] Tian et al. SWE-Bench Mobile: Can LLM agents develop industry-level mobile applications? arXiv, 2026.
- [48] Trivedi et al. Interleaving retrieval with chain-of-thought reasoning. arXiv:2212.10509, 2023.
- [49] Xiao et al. RAR-B: Reasoning as retrieval benchmark. arXiv:2404.06347, 2024.
- [50] Xiong et al. Learning to continually learn via meta-learning agentic memory designs. OpenReview, 2026.
- [51] Yang et al. Large language models as optimizers (OPRO). ICLR, 2023.
- [52] Ye et al. Meta context engineering via agentic skill evolution (MCE). arXiv:2601.21557, 2026.
- [53] Yuksekgonul et al. TextGrad: Automatic "differentiation" via text. arXiv:2406.07496, 2024.
- [54] Yuksekgonul et al. Learning to discover at test time (TTT-Discover). arXiv:2601.16175, 2026.
- [55] Yuksekgonul et al. Learning to discover at test time. arXiv:2601.16175, 2026.
- [56] Zhang et al. Recursive language models. arXiv:2512.24601, 2026.
- [57] Zhang et al. MemEvolve: Meta-evolution of agent memory systems. arXiv:2512.18746, 2025.
- [58] Zhang et al. AFlow: Automating agentic workflow generation. arXiv:2410.10762, 2025.
- [59] Zhang et al. Agentic context engineering (ACE). arXiv:2510.04618, 2025.
- [60] Zhang et al. Character-level convolutional networks for text classification. arXiv:1509.01626, 2016.