2026-09-03·★ 会員·論文·21分で読めます

論文解説: StarHarness — モデルを凍結したまま「ハーネス」を進化させる

モデルの重みを一切変えず、エージェントを取り巻く「ハーネス」（プロンプト・ツール定義・スキル・MCP・サブエージェント・実行ループ）だけを探索で書き換える。企業向け3ベンチマークで20〜35ポイント改善し、進化に使わなかったタスクにも、別のモデルにも効いた。

#agents #harness #tool-use #mcp #enterprise #evaluation

対象textタスクagents

StarHarness: Evolving Harnesses with Stratified Search for Enterprise Environments

一次資料 — この記事の根拠

論文の発表 2026-08-25→この解説の公開 2026-09-03同月

StarHarness: Evolving Harnesses with Stratified Search for Enterprise EnvironmentsEsakkivel Esakkiraja, Denis Akhiyarov, Vikas Yadav ほか · 2026-08-25 · v1arXiv:2608.24804論文ページ·PDF

原文の要旨（Abstract）を読む

We present StarHarness, a framework for evolving environment-specific agent harnesses while keeping model weights fixed. The evolved harness can include prompt and task framing, tool interfaces, skills, MCP-backed providers, subagent structure, and agent-loop configuration. StarHarness constructs a compact evolution pool by stratifying tasks according to baseline failure behavior, separates proposer-visible search tasks from proposer-hidden selection tasks, and reserves held-out tasks for evaluating generalization. Across ITBench SRE, EnterpriseOps-Gym ITSM, and AutomationBench Finance, harness evolution improves full-benchmark performance by 20-35 percentage points over the default harness after 4-12 accepted changes per environment. These gains persist on tasks excluded from evolution and transfer without re-evolution across GPT and Qwen model families. Trace analysis links the improvements to interface repairs, environment conventions, and operational knowledge that compresses search, with fewer false-positive diagnoses and shorter trajectories in several settings. StarHarness therefore offers a practical way to reduce persistent model-environment mismatch in tool-rich enterprise tasks.

同じ料理人でも、厨房が変われば腕は出ない

腕のいい料理人を、初めての厨房に放り込んだとします。包丁の位置がわからない、コンロの火力の癖を知らない、この店では「塩」と札の貼られた瓶に実は砂糖が入っている。料理人の腕（＝モデルの重み）はまったく変わっていないのに、出てくる料理はひどいものになります。

いま企業でLLMエージェントを動かすと、これとよく似たことが起きます。モデルは十分賢いのに、社内システムのAPIスキーマが微妙に厳しかったり、「優先度を変えたら影響度と緊急度も一緒に更新する」といった業務の暗黙ルールがツールの説明書に書かれていなかったりする。これを論文はモデルと環境のミスマッチ (model–environment mismatch) と呼びます。

今回読むのはこの論文です。原題は "StarHarness: Evolving Harnesses with Stratified Search for Enterprise Environments"（ServiceNow / Mila / モントリオール大学、arXiv:2608.24804、2026年8月25日公開）。

要旨を日本語で言うと、こうなります。StarHarnessは、モデルの重みを固定したまま、環境ごとのエージェント・ハーネスを進化させるフレームワークです。進化の対象にはプロンプトとタスクの枠付け、ツールのインターフェース、スキル、MCPで裏打ちされたプロバイダ、サブエージェント構成、エージェントループの設定が含まれます。タスクをベースラインの失敗傾向で層別して小さな進化用プールを作り、提案者が見てよい探索タスクと、提案者に見せない選抜タスクを分け、さらに汎化を測るためのホールドアウトを別に取っておきます。ITBench SRE、EnterpriseOps-Gym ITSM、AutomationBench Finance の3環境で、環境あたり4〜12件の変更が採択された時点で、既定ハーネスに対しベンチマーク全体の性能が20〜35ポイント向上しました。この改善は進化に使わなかったタスクでも保たれ、GPT系とQwen系のあいだで再進化なしに転移しました。トレース分析はこの改善を、インターフェースの修復、環境の慣習、探索を圧縮する運用知識に結び付けており、いくつかの設定では誤診（偽陽性）の減少と軌跡の短縮も観測されています。

「ハーネス」とは何を指すのか

ハーネス（harness）は日本語だと「馬具」です。馬（モデル）そのものではなく、馬に付ける装具一式。エージェントの文脈では、モデルの周りにある実行可能な足場すべてを指します。論文の実装で編集可能とされている面は具体的で（§3.1）、プロンプトとタスクの枠付け、ツール定義とスキーマ、引数の前処理、スキル、MCPプロバイダ、サブエージェント構造、コンテキスト管理、検証、終了判定ロジックです。

ここが重要なところで、これらは全部ただのコードです。モデルの重みの中には入っていないので、gitのdiffとして提案でき、テストでき、気に入らなければrevertできます。論文もこの点を、重み更新と対比して明示しています（§2.1）。

実装は二層になっています。最適化する側はOh My Pi（Piエージェント・ハーネスの派生）の上に載ったコーディング・ハーネスで、これが提案・検証・評価のループを回します。最適化される側は別物のStirrupハーネスで、こちらが実際にベンチマークを解くエージェントです。進化の最中、モデルの重みとベンチマークは固定されたままです。

何を最大化したいのか

論文の目標はきれいに1行で書けます（§3.1）。

h^{*}=\underset{h\in\mathcal{H}}{\arg\max}\;J(h;\mathcal{D}_{\mathrm{holdout}})

(1)

読み下すとこうです。 $h$ はハーネス（＝上で挙げたコード一式）、 $\mathcal{H}$ は許可されたハーネスの空間、 $J(h;\mathcal{D})$ は固定モデル $M$ にハーネス $h$ を付けてタスク集合 $\mathcal{D}$ を解かせたときの平均スコア（高いほど良い）。つまり式(1)は「進化に一度も使っていないタスク集合 $\mathcal{D}_{\mathrm{holdout}}$ での平均点を最大にするハーネスを選びたい」と言っているだけです。

そして当然ながら、探索の最中にホールドアウトの結果を覗くことはできません。だからStarHarnessは、提案者に見せる探索タスクと、提案者に見せない選抜タスクでこの目標を代理的に近似します。ここが手法の肝です。

なぜ「層別」なのか — 進化用プールの作り方

ベンチマーク全体を毎回走らせると、探索1回あたりのコストが跳ね上がります。かといって適当に半分を選ぶと、その半分に都合のいいハーネスができあがる。いわゆる過学習です。

StarHarnessは進化の前に、全 $N$ タスクのうち評価が再現するものを $N'$ 件残し、そこから $K \approx N/2$ 件の進化用プールを抜き出します（§3.2）。抜き出す基準は、事前に取ったベースライン実行から計算した3つの記述子です。

ベースラインの失敗モード（例: wrong_tool、context_loss、missing_evidence、premature_conclusion）
ベースラインのタスクスコア
検証器（verifier）の通過率

進化用プールはさらに、提案者が見てよい探索タスクと、提案者に隠す選抜タスクに割られます。このとき両者のスコア分布・失敗モード分布・検証器通過率の分布を揃えるのがポイントです。提案者は探索タスクのトレースと結果は読めますが、選抜タスクの中身・トレース・検証器のフィードバック・タスクごとの結果は一切見られません。残った $N'-K$ 件がホールドアウトで、提案にも採択判定にも一切影響しません。

FIG 1次数（＝ハーネスをいじった量）を上げると訓練誤差は下がり続けるが、テスト誤差はどこかで上がる。探索セットだけを見て改良し続けると同じことが起きるので、StarHarnessは提案者に見せない選抜セットで採否を決め、ホールドアウトを最後まで温存する

探索の進め方 — 山登りと木探索

同じ提案者・検証器・評価器・採択基準を、論文は2つの探索手続きで使い分けます（§3.3）。

山登り (hill climbing) では、状態はただ1つの「フロンティア」ハーネスです。各反復で提案者はいまのフロンティアのトレースを見てパッチ $\Delta_t$ を1つ出し、選抜スコアが厳密に改善したときだけ（あるいは同点でかつ利用可能な検証器指標が改善したときだけ）採択します。それ以外は元に戻します。

木探索 (tree search) では、状態は候補ノードの集合です。各ノードは親ポインタ、累積パッチ、探索トレース、検証状態、選抜スコアを持ちます。提案者は「失敗パターンを探る」「パッチを書く」「失敗した候補をデバッグする」「両立する2ノードを統合する」「既存ノードを改良する」のいずれかを選べます。有効なノードは同じ隠し選抜セットで採点され、生き残った最良ノードが次のフロンティアになります。狙いは、最初に採択された編集にすぐ乗り換えず、代替仮説を残しておくことです。

FIG 2山登りは目の前の坂を登るだけなので、近くのくぼみで止まりうる。木探索は複数の出発点＝代替仮説を残す。論文はこの2モードをEnterpriseOps-Gymで逐次的に使った（木探索で探索→山登りで詰める）

ただし論文はここを正直に限定しています。この2モードの使い分けはEnterpriseOps-Gymだけで行った探索・活用の対照実験であり、木探索のあとに山登りを走らせる逐次構成なので、「木探索 vs 山登り」の因果的な直接比較にはなっていない、と明記しています（§3.3）。

カンニングを防ぐ仕組み

提案者はベンチマークのトレースを読めるので、放っておけば「タスクID 17 のときは答えXを返す」といった解答の埋め込みを始めます。StarHarnessはこれをガードレールで禁じます（§3.4）。

タスクIDでの分岐、ハードコードされた解答
検証器やアサーションの内容をエージェントのプロンプトに書くこと
正解表や隠し状態へのアクセス
ベンチマーク固有の解答マッピング

各候補は現フロンティアに対するgit diffで、編集可能ディレクトリと共有エージェント基盤の中だけにスコープされます。検証器はスコープ・import・単一タスクのスモークテストを確認し、どれかに失敗した候補は選抜評価を走らせる前にrevertされます。

さらに評価コストを削るために、選抜セット評価の手前にテストフリップというゲートがあります（§3.1）。提案者が自分で選んだ1タスクについて、その候補が結果をひっくり返せなければ、そこで却下を記録して高価な評価をスキップします。採択・却下・無効・クラッシュの記録は永続メモリ台帳に残り、フロンティアのスコア、タスクごとの結果、採択された仮説、捨てた試みが次の反復に引き継がれます。