AIエージェントの性能はモデルではなくハーネスで決まる — Lilian Wengの「Harness Engineering」を読み解く

はじめに

エージェントの出来が悪いとき、私たちはたいてい2つの手を打つ。モデルを強いものに差し替えるか、指示書（CLAUDE.md や system prompt）を書き足すかだ。どちらも即座に打てる手であり、だからこそ真っ先に選ばれる。

だが、この2つはどちらも「モデルの内側」と「モデルへの入力」しか触っていない。その外側にある実行環境そのもの——どんなツールが生えていて、失敗がどうフィードバックされ、何がファイルとして残り、何をもって成功と判定するのか——を設計対象として名指ししたのが「ハーネス（harness）」という概念である。

2026年7月4日、Lilian Weng が Lil’Log に投稿した Harness Engineering for Self-Improvement は、この領域の研究を約35本の論文を横断してサーベイした長文記事だ。投稿から1ヶ月が経った8月上旬に Hacker News で再浮上し252ポイントを集めており、DeepSeek の研究者が賛意を示すなど反響も大きい。

主張の芯はシンプルだ。再帰的自己改善（RSI）は、モデルが自分の重みを書き換えることから始まるのではない。まずハーネスの改善から始まる。 そして、それはすでに始まっている。本記事では、この論考が何を整理したのかを追いながら、日々エージェントを使い倒しているエンジニアが明日から何を変えられるかまで落とし込む。

ハーネスとは何か — モデルの「外側」を設計対象にする

Weng の定義では、ハーネスとはベースモデルを取り囲む実行レイヤであり、次のことを決める層を指す。

モデルがどう考え、計画するか
どうツールを呼び、行動するか
どうコンテキストを知覚し、管理するか
どう成果物（artifact）を保存するか
どう結果を評価するか

「それは要するにエージェントフレームワークでは？」と思うかもしれない。違いは後半3つにある。従来のフレームワークがツール呼び出しとループ制御の抽象化に留まっていたのに対し、ハーネスは評価機構・権限制御・永続状態を一級の設計要素として含む。「LangChain で組んだ」と「ハーネスを設計した」の差は、そこに検証ループと状態の寿命設計があるかどうかだ。

この視点の何が効くのか。ハーネスを設計対象として切り出すと、改善対象が測定可能になるという点が大きい。「プロンプトを良くする」は評価が難しいが、「失敗ケースをクラスタリングして、その原因に対応するツールを1本足す」は前後で比較できる。Weng が繰り返し強調するのも、自己改善ループが成立する前提条件は観測可能で測定可能な評価が存在することだ、という一点である。

3つの基本パターン — ワークフロー・ファイルシステム・サブエージェント

論考はまず、実務で機能しているハーネスの設計パターンを3つに整理する。Claude Code や Codex を日常的に使っている人なら、どれも見覚えがあるはずだ。

1. ワークフロー自動化。 計画→実行→観測→改善のゴール指向ループを回し、失敗ケースを反復的に分析させる。ポイントは「反復」ではなく「失敗ケースの分析」のほうにある。単にリトライさせるループは自己改善にならない。

2. 永続メモリとしてのファイルシステム。 ログ、diff、トレースといった成果物を、コンテキストウィンドウ内に抱え込むのではなくファイルとして永続化する。これは単なるコンテキスト節約の話ではない。ファイルに落とした瞬間、それは人間もgrepできる検査対象になる。エージェントの内部状態を可観測にする最も安上がりな手段が、ファイルに書くことだ。

3. サブエージェントとバックグラウンドジョブ。 並列性を暗黙のスレッドではなく、ファイルとログとして明示的・検査可能な形で表現する。「何が並列に走っていて、それぞれ何を返したか」が後から追えることに価値がある。

コーディングエージェントのケーススタディでは、安定したツール群としてファイル探索、シェル実行、LSP、git 操作、Web 検索、エージェント委譲が挙げられている。これらがほぼ全ての主要コーディングエージェントで共通しているのは偶然ではなく、ハーネス設計の収束点だという見方ができる。

最適化の梯子 — プロンプトからハーネスコード、そして最適化コードへ

論考の中核は、「何を最適化の対象にするか」を段階として並べた梯子だ。

指示プロンプト → 構造化コンテキスト → ワークフロー → ハーネスコード → オプティマイザコード

左から右へ行くほど、改善の対象は抽象度を上げ、効果は持続的になる。この梯子の各段に対応する研究がある。

ACE（Agentic Context Engineering） は、コンテキストを「進化するプレイブック」として扱う。プロンプト全体を毎回書き直すのではなく、generator / reflector / curator の3コンポーネントが (識別子, 説明) という構造化された箇条書きを出力・更新していく。プロンプトを差分更新可能なデータ構造として設計する、という発想だ。

MCE（Meta Context Engineering） はさらに一段上がり、「コンテキストをどう管理するか（メカニズム）」と「コンテキストに何が入っているか（成果物）」を分離した二階層最適化を行う。メタレベルでスキルを進化させ、ベースレベルでコンテキストを最適化する。

Meta-Harness は最下層に降りる。最適化対象がハーネスのコードそのものになり、何を保存し・何を検索し・何を提示するかを決めるコードをコーディングエージェントに書かせて評価する。文字通り「ハーネスを最適化するためのハーネス」だ。

ワークフローの設計空間そのものを探索する試みも紹介されている。ADAS はメタエージェントが新しいワークフローをコードとして提案し、新規性の観点から自己改良してアーカイブに追加する。AFlow はワークフローをグラフとして表現し、モンテカルロ木探索で候補を最適化する。AI Scientist は研究アイデアの提案からコード実装、実験実行、分析、論文執筆、査読までを回す。

さらに進化的探索の系譜として、AlphaEvolve（凍結したLLMに差分を生成させ、反復評価で有望なものを残す）、DGM（Darwin Gödel Machine）（エージェントが自身のハーネスコードを改変することを許す）、ShinkaEvolve（親選択戦略・新規性による棄却・メタスクラッチパッドでサンプル効率を改善）が並ぶ。DGM が発見したエージェントは SWE-bench Verified で手書きベースラインに対し20〜50%の改善を示したと報告されている。

「強いモデルほど得をする」わけではない

この論考で最も直感に反し、かつ実務的な含意が大きい発見がこれだ。

Weng が引く実験結果によれば、ハーネスを更新する能力は Qwen2-32B クラスから最新の Opus 系まで、モデル間でほぼ横ばいだった。一方で、更新されたハーネスから利益を得る度合いは単調ではなく、中位クラスのモデルが最も恩恵を受けた。

解釈はこうだ。弱いモデルはそもそも良いハーネスを書けない。強いモデルは良いハーネスを書けるが、自力でも解けてしまうためハーネスを使い切らない。ハーネス整備の投資対効果が最大になるのは、その中間にいるモデルということになる。

コスト最適化の観点でこれは効く。 「難しいタスクだから最上位モデルへ」と反射的に上げる前に、中位モデル＋整備されたハーネスという組み合わせを検討する余地がある、ということだ。

長時間タスクにおける人間との比較も示唆的だ。RE-Bench では、2時間の予算ではエージェントが人間の4倍のスコアを出す一方、8時間以上の予算では人間が逆転する。PaperBench では Claude 3.5 Sonnet が約21%と ML の博士課程学生を下回った。エージェントは短距離では速いが、長距離では失速する——そしてこの失速こそが、メモリ管理と検証ループというハーネス側の課題である、という筋書きになっている。

実践に落とすと何が変わるか — CLI設計の3原則

抽象論だけでは動けないので、同日のトレンドから具体例を引く。Zenn に投稿された「AIエージェント向けのツールを、MCPではなくCLIとして作った — 設計の3原則」は、ハーネス設計の実践編として読める記事だ。

著者らは当初 MCP サーバーとして実装しようとしたが、MCP ではファイルを値渡しでしか受け取れないという制約に突き当たった。1MB のノートブックファイルの中身が丸ごとエージェントのコンテキストを通過してしまう。CLI なら cdm notebook validate ./file の一発で済み、ファイルそのものを中間表現として使える。CI 環境のような「エージェント不在の自動化」とも自然に噛み合う。

導かれた3原則は次の通りだ。

原則1：コンテキストを浪費させない。 出力形式に JSON や YAML ではなくマークダウンを選ぶ（構造記号が少なくトークン効率が高く、モデルが事前学習で慣れている）。validate のような業界標準の語彙を使い独自構文を避ける。仕様を全部プロンプトに積まず、cdm doc show <path> で必要時に取得させる。

原則2：間違えさせない工夫より、自己修正可能な設計に投資する。 エラーメッセージに行番号と該当行の抜粋、一意なエラー内容、修正方法のドキュメントURLを含める。チャートのような「見た目の誤り」は render で画像化してマルチモーダルに確認させる。LLM が苦手なランダムID生成はツール側で機械的に処理する。

原則3：ワークフロー全体を一本道にする。 SQL 実行の「ジョブ作成→ポーリング→結果取得」を1コマンドに畳み込み、完了待ちループをエージェントに管理させない。検証対象ごとにコマンドを分けず、常に同じ validate を叩く単純なループに統一する。

この3原則は、Weng の論考が挙げる要素にきれいに対応している。原則1はコンテキスト管理、原則2はverifier-grounded な失敗フィードバック（AHE が言う「実験観測性」）、原則3はワークフロー自動化そのものだ。研究側の抽象語彙と現場の設計判断が同じ場所を指している、というのは心強い。

そして重要なのは、この3原則のどれ一つとして、プロンプトを書き足すことでは達成できないという点である。ここが、ハーネスエンジニアリングという言葉が指す領域の輪郭だ。

指示書を厚くする方向の限界については、長文の指示書追従を測る HANDBOOK.md ベンチマークが定量的な証拠を出している（日本語解説）。20〜124ページの業務マニュアルを渡した65タスクで、ルール遵守率は最高でも36.2%、多くのモデルは25%を下回った。文書で「お願い」できる範囲には天井がある。守られないと事故になる制約は、文書ではなく権限設計と検証ステップ——つまりハーネス側——で担保するしかない。

7つの未解決課題

論考の後半は、この方向性が抱えるリスクの列挙にあてられている。楽観論だけで終わっていないのが本記事の良いところだ。

評価器が弱い — 多くの研究主張には高速で正確な verifier が存在せず、「筋の良さ」は曖昧なまま
コンテキスト／メモリのライフサイクル — 長文脈生成の限界を補完するメモリ管理が必要
ネガティブな結果を扱えない — 学習データが成功例に偏っているため、仮説を捨てる判断が苦手
多様性の崩壊 — 進化ループは既知パターンを深掘りしがちで、開かれた探索には多様性維持の機構が要る
報酬ハッキング — 自己改善ループは与えられた信号を何であれ最適化してしまう
長期的な成功指標の欠落 — 保守性・後方互換性・デバッグ負荷が最適化から漏れる
人間の役割 — 人間はスタックの上位に移動し、適切な抽象度で監督を提供すべき

5番目と6番目は、日常のエージェント運用でもすでに顔を出している課題だ。「テストが通った」を報酬にすれば、テストを書き換えて通す解が見つかる。「タスク完了」を報酬にすれば、保守不能なコードが積み上がる。自己改善ループを回す前に、何を測っているのかを疑う工程が要る。

まとめ

ハーネスとは、モデルの外側で計画・ツール呼び出し・コンテキスト管理・成果物保存・評価を司る層のこと。従来のエージェントフレームワークと違い、評価機構・権限制御・永続状態を設計要素として含む。
最適化の対象は「指示プロンプト → 構造化コンテキスト → ワークフロー → ハーネスコード → オプティマイザコード」と段階的に上がっていく。ACE / MCE / Meta-Harness はそれぞれ異なる段に対応する研究である。
ハーネスを書く能力はモデル間でほぼ横ばいだが、ハーネスから利益を得る度合いは中位モデルで最大になる。最上位モデルに上げる前に、ハーネス整備を検討する価値がある。
実践面では、CLI 設計の3原則（コンテキストを浪費させない／自己修正可能にする／ワークフローを一本道にする）が、研究側の語彙とそのまま対応する具体例になっている。
課題は評価器の弱さと報酬ハッキング。測定できないものは改善できず、間違ったものを測ると間違った方向に改善される。

Weng 自身が X で書いているように、ハーネスの改善はいずれ多くがモデル本体に内在化されていく。それでも「目標と制約とコンテキストを指定する必要は消えない」。プロンプトエンジニアリングが instruction tuning に吸収されてなお、何を頼むかを決める仕事が残ったのと同じ構図だ。モデルが強くなるほどハーネスは薄くなるが、ゼロにはならない。 薄くなった先に何を残すかを考えるのが、これからのエンジニアの仕事になる。

今日のその他のニュース

keyv 系 npm パッケージが Shai-Hulud 攻撃で侵害（HN 189pt） — メンテナの GitHub アカウントが乗っ取られ、main ブランチへの直接 push とリリース発行によって、GitHub Actions の正規 provenance 付きで汚染版が npm に公開された。keyv の依存は Cacheable / got 系に広く入り込んでおり間接被害の範囲が広い。日本語の対応指針は Flatt Security の記事が実務向けにまとまっている。npm ls keyv での依存確認と、CI で使っている npm トークンのローテーションまでを一連で行いたい。

The Warp Agent CLI（HN 38pt） — ターミナル製品の Warp がコーディングエージェント CLI を発表。GUI ターミナル側の資産を持つプレイヤーが CLI 側に降りてきた形で、Claude Code / Codex 系との正面競合になる。本記事の文脈で言えば、これもハーネスの実装が競争軸になっている一例だ。

エンジニアよ、商談に出よう（はてブ 156） — エンジニアが商談に同席することで得られる一次情報と、それが開発判断に与える影響について。同日には「コードを書くだけ」の仕事は、もう回ってこない。（はてブ 66）も上がっており、対で読める。Weng の言う「人間はスタックの上位に移動して監督を提供する」が、キャリアの話として国内でも同時に議論されている構図が見える。