AIエージェントの性能は、基盤モデルだけでなく「ハーネス」と呼ばれる周辺設計に大きく左右されます。Xiaomi傘下のDarwin Agent Teamが公開したHarnessXは、このハーネスをタスク実行中に自律的に書き換え、モデル本体を変えずにエージェントを強化する枠組みです。

この記事では、HarnessXが解決する課題と仕組み、ベンチマーク結果、導入の進め方までを整理します。

この記事でわかること

  • ハーネスとは何か、なぜ手作業のままでは限界があるのか
  • HarnessXのコア設計（processor、AEGIS、共進化）
  • 5つのベンチマークで得られた数値と、小さいモデルほど伸びる理由
  • GitHubで試す際の前提と注意点

https://github.com/Darwin-Agent/HarnessX

HarnessXが変えること

HarnessXは2026年6月にarXiv（2606.14249）で公開された研究に基づくオープンソースプロジェクトです。論文とGitHubリポジトリの両方で、エージェントの「ハーネス・ファウンドリ（鋳造所）」として位置づけられています。

ここでいうハーネスとは、LLMと外部環境をつなぐ実行層のことです。プロンプト、ツール連携、メモリ管理、制御フローなどが含まれ、モデルが環境を観測し、推論し、行動する方法を決めます。VentureBeatの報道でも、長期タスクを担うエンタープライズ向けエージェントの性能が、この周辺設計に縛られることが指摘されています（参考）。

HarnessXの要点は、ハーネスを静的な手書きコードではなく、独立して差し替え・進化できる「第一級オブジェクト」として扱う点です。モデル設定とハーネス設定を分離し、agent = model.agentic(harness) の一行で組み立てます。

なぜ手作りハーネスでは足りないのか

論文は、現状のハーネス開発に3つの構造的な課題があると整理しています。

まず、多くのハーネスは静的で手作業です。基盤モデルの更新、新ツールの追加、ドメイン変更のたびにコードを書き直す必要があり、実行ログから自律的に学習する仕組みがありません。

次に、設計が絡み合っています。プロンプト、ツールラッパー、リトライ方針、メモリが同じコードパスに混在すると、一部を直しただけで別の挙動が壊れます。ドメインをまたいで再利用しづらく、コピーと修正の繰り返しになりがちです。

最後に、ハーネス改善とモデル学習が分断されています。ハーネス調整中に集まる実行トレースは、モデル訓練データとして活かされにくく、モデル強化もハーネス改善に直結しません。HarnessXはこの3点を、モジュール化・トレース駆動の進化・共進化の3本柱で受け止めます。

HarnessXの3つの柱

1. モジュール化されたハーネス構成

HarnessXはハーネスを9次元の行動空間に分解します。モデル選択、コンテキスト組み立て、メモリ、ツール、実行環境、評価、制御・安全、可観測性、学習ブリッジが対象です。

各挙動は「processor」と呼ばれる部品として実装され、タスク開始から終了までの8つのライフサイクルフックに差し込まれます。processorは | 演算子で組み合わせられ、型安全な置換代数で差し替え可能です。エージェント本体を書き直さず、ツール追加やメモリ導入、ガードレール設定といった「行動の差し替え」が目的です。

2. AEGISによるトレース駆動の進化

ハーネス改良の中核はAEGIS（Adaptive Evolution engine Grounded In Symbolic space）です。実行トレースと検証スコアを手がかりに、ハーネス適応を強化学習（RL）と対応づける「操作的ミラー」を採用しています。

AEGISは4段階のパイプラインで動きます。

  • Digester: 実行トレースを圧縮し、失敗箇所を構造化する
  • Planner: 要約から構造的な変更案を探索する（局所プロンプト調整に偏らない）
  • Evolver: コードレベルのハーネス編集を生成し、実行確認する
  • Critic: 報酬ハッキング（検証をすり抜ける抜け道）を検出する

さらに決定論的なゲートが、過去に解けていたタスクが後退する編集を拒否します。これはRLで知られる「破滅的忘却」への対策です。第三の病理である探索不足には、Plannerが構造変更を提案することで対処します。

実験ではメタエージェント（ハーネスを書き換える側）にClaude Opus 4.6を、タスク実行側にClaude Sonnet 4.6・GPT-5.4・Qwen3.5-9Bを使い、モデル非依存性を検証しています。

3. ハーネスとモデルの共進化

HarnessXの差別化ポイントは、ハーネス単独の最適化で止めない点です。ハーネスだけを進化させると、モデルの推論力が新ツールを使い切れず「足場の天井」に当たります。モデルだけを訓練しても、ハーネスが能力を引き出さなければ「学習信号の天井」に当たります。

共進化では、ハーネス進化中に得たトレースを共有リプレイバッファに蓄積し、cross-harness GRPO（Group Relative Policy Optimization）でモデルを微調整します。GRPOはDeepSeek-R1など推論モデルの訓練にも使われるRL手法です。異なるハーネス版で同じタスクを走らせた軌跡をまとめて学習するため、プロンプト表現の微差ではなく、新APIの使い方や実行予算の管理といった戦略変化をモデルが内面化しやすくなります。

共進化の追加効果はオープンウェイトモデルに限られ、平均で+4.7%の上乗せが報告されています（ハーネス単独進化との比較）。

ベンチマークで何が起きたか

検証は5ベンチマークで行われました。内訳はALFWorld（身体性プランニング）、GAIA（多段推論）、WebShop（Web操作）、τ³-Bench（マルチターン顧客対応）、SWE-bench Verified（ソフトウェア工学）です。

ハーネス進化だけで、15のモデル×ベンチマーク組み合わせのうち14で改善し、平均絶対値は+14.5%でした。個別の伸びは0.0%から+44.0%の範囲です。

小さいモデルほど伸びが大きい「逆スケーリング」が顕著です。オープンウェイトのQwen3.5-9BはALFWorldで+44.0%（ベースライン53.0%から）、SWE-bench Verifiedで+18.2%（23.6%から）の改善を記録しました。一方、すでに高いベースラインのτ³-BenchではQwen3.5-9Bは+1.1%にとどまります。

具体例も報告されています。GAIAではWikipedia取得用のヘッドレスブラウザがJavaScript多めのフロントでタイムアウトし続けたため、HarnessXはMediaWiki APIを直接叩くツールを新設し、差し替えました。WebShopでは「次へ」ページを繰り返すループに陥る問題に対し、同じナビゲーションの繰り返しを検知して警告をコンテキストへ注入するprocessorを追加し、ループを断ち切りました。

GitHubのREADMEではGAIAベンチマーク上でQwen 3.5 9Bが初期33%から進化ラウンド3で47%（+14ポイント）に達した例も示されています。GPT-5では62%から84%への改善が掲載されています。

既存アプローチとの違い

プロンプト最適化（DSPyやOPROなど）やワークフロー探索（AFlowなど）は、ハーネスの一部しか触れません。HarnessXはツール実装、メモリ方針、制御フローまで含むハーネス全体を進化対象にします。

SICAやDarwin Gödel Machineのようにソースコードを直接書き換える系譜とも近いですが、HarnessXは型付きprocessorとゲートで編集範囲を制約し、トレース可観測性とモデル共進化を一体で設計しています。Claude Code SDKを単一エージェント進化器として比較した実験では、AEGISの4段階パイプラインが優位なケースも報告されています。

使い方と現状の制約

https://github.com/Darwin-Agent/HarnessX

リポジトリはMITライセンス、Python 3.11+、バージョン0.1.0のベータです。インストールスクリプト、hx CLI、Python SDK、Harness Lab UIが用意されています。進化ループは「Harness Evolution」（モデル固定でハーネス探索）と「Model Evolution」（トレースをVERL経由のRL微調整に回す）の2系統で、先にハーネスを進化させ、その上でモデルを訓練する構成が推奨されています。

一方で制約も明記されています。メタエージェントには現時点でClaude Opusのような強いフロンティアモデルが必要で、オープンウェイトモデルが同等の進化品質を出せるかは未検証です。タスクモデル自体が弱すぎる場合、新しいハーネスが提案する複雑なワークフローを実行できず、改善が頭打ちになります（Qwen3.5-9BのSWE-benchでの観察）。異種タスクが混在するGAIAでは単一ハーネス進化が停滞する例もあり、variant isolation（タスク群ごとにハーネスを分岐）が必要でした。

開発者が取れる次の一手

HarnessXが示すのは、「もっと大きいモデルに乗り換える」前に、周辺設計をデータ駆動で磨く選択肢が現実的だということです。特にオープンウェイトの9Bクラスを本番ワークフローに載せているチームにとって、+14.5%平均・最大+44%という数字は、コスト増なしで試せるレバーとして意味があります。

コードはGitHubで公開済みです。論文著者は完全なコードベースのオープンソース化を今後のリリースで行うとも述べています。エージェント基盤をすでに持つ開発者は、まず既存ワークフローをHarnessXのprocessorモデルに落とし込み、失敗トレースからAEGISに何を直させるかを観察するのが現実的な第一歩です。