AI Agent Harness Engineering：モデル外側の実行システム

**先に結論：**AI Agent harness engineering とは、モデルの外側にある実行システムの設計です。与えるコンテキスト、使えるツール、残す記憶、通す評価、権限、人間が承認する地点を決めます。強いモデルでも、実務で信頼できる働きをするには強い harness が必要です。

前の二本では scaling laws を扱いました。モデルサイズ、データ、計算量が、AI訓練の経済性をどう決めるかという話です。

今回は一段外側を見ます。

Lilian Weng の「Harness Engineering for Self-Improvement」は、モデルの重みを大きくする話ではありません。モデルの外側にある実行システムの話です。

基盤モデルが十分に賢くなった時、その周囲の runtime は、どうやって長い仕事を実行させ、道具を使わせ、失敗を記録し、評価し、少しずつ改善していくのか。

キーワードは harness です。

Harness は、モデルの学校、道具箱、ノート、試験システム、安全境界だと考えると分かりやすいです。

モデルは脳です。Harness は、その脳が何を見るか、どの道具を使えるか、何を記憶するか、どう検査するか、どこで人間が介入するかを決めます。

Harness はモデルの外側の実行システム

図1：基盤モデルは知的行動を生みます。Harness はコンテキスト、ツール、記憶、評価、権限、人間の監督を管理します。

なぜ重要なのでしょうか。

近い将来のAI自己改善は、モデルが直接自分の重みを書き換えることから始まるとは限りません。より現実的な道はこうです。

モデルが働く環境を改善する。良い環境は良い軌跡、失敗記録、評価、記憶を生む。それらが次の harness 改善に使われる。

これが harness engineering の事業価値です。

Harness とは何か

単純な式で書くと：

y = H_h(M, x)

ここで：

$M$ は基盤モデルです。
$x$ はタスクです。
$h$ は harness の設計です。
$H_h$ はモデルを囲む実行システム全体です。
$y$ は最終成果物です。

普通のチャットはこうです。

y = M(x)

Agent harness はこうです。

y = H_h(M, x, c, T, R, E)

追加されたものが重要です。

$c$ ：現在モデルに見せるコンテキスト
$T$ ：検索、ファイル、コード実行、DB、ブラウザなどのツール
$R$ ：ログ、失敗、軌跡、成果物などの記憶
$E$ ：テスト、採点、監査、回帰確認などの評価器

問うべきことは「モデルは賢いか」だけではありません。

モデルはどんな作業環境に置かれているのか。

なぜ自己改善につながるのか

再帰的自己改善は派手に聞こえます。しかし近い実装は、むしろ慎重なソフトウェア工学に近いです。

現在の harness $h_t$ でタスクを実行する。
軌跡、エラー、ツール呼び出し、diff、テスト結果を保存する。
Agent が繰り返し現れる失敗パターンを掘る。
小さな harness 変更 $h'$ を提案する。
held-in と held-out のタスクで検証する。
既知問題を直し、未知の退化を起こさない時だけ採用する。

数式では：

h_{t+1} = \begin{cases} h' & \text{if } J_{\text{in}}(h') > J_{\text{in}}(h_t) \text{ and } J_{\text{out}}(h') \ge J_{\text{out}}(h_t) \\ h_t & \text{otherwise} \end{cases}

意味は単純です。

新しい harness が既知の失敗を直し、一般性能を壊さない時だけアップグレードする。

Self-harness improvement loop animation

図2：自己改善は「好きに改造する」ことではありません。失敗を掘り、小さな変更を提案し、回帰テストに通ったものだけを採用します。

三つの設計パターン

Lilian の文章には多くの設計パターンが出てきます。中心は三つです。

ワークフロー自動化

Agent は一回答えて終わりではありません。長い仕事にはループが必要です。

計画 → 実行 → 観察/テスト → 反省 → 修正 → 再実行

Coding agent が動くのは、ファイルを読み、コードを編集し、テストを走らせ、エラーを見て、再修正できるからです。これはチャット画面ではなく、runtime loop です。

ファイルシステムを永続記憶にする

長いタスクは情報を大量に生みます。生の会話、ツール出力、コード差分、エラー、実験ログは、すぐに context window を超えます。

Harness は詳細な歴史をファイルへ置き、現在必要な要約だけを context window に入れるべきです。

c_t = \text{compress}(q_t, R_t) \quad \text{s.t.} \quad |c_t| \le W

$W$ は context window の上限、 $R_t$ は永続記憶です。

Context and memory lifecycle

図3：生の履歴はすぐ大きくなります。良い harness は作業コンテキストを小さく保ち、完全な履歴をファイルに残します。

Sub-agent とバックグラウンドジョブ

人間も一つのスレッドだけで研究しません。複数の調査、実験、レビューを並行して進めます。

Agent も同じです。

直列なら：

T_{\text{serial}} = \sum_i t_i

並列なら近似的に：

T_{\text{parallel}} \approx \max_i t_i + T_{\text{merge}}

ただし harness は小さな process manager になります。ジョブを起動し、ログを見て、失敗を止め、結果を保存し、統合する必要があります。

モデル能力と Harness 品質

これは二者択一ではありません。

強いモデルを弱い harness に入れると、ノートも道具も試験もない部屋に賢い学生を置くようなものです。

弱いモデルを強い harness に入れても限界はあります。

簡単な関数で表すと：

\text{Success} = \sigma(aM + bH + cMH - d)

$M$ はモデル能力、 $H$ は harness 品質、 $MH$ は相互作用です。

Model and harness success surface

図4：モデル能力と harness 品質は掛け算に近い関係です。同じモデルでも、製品によって体験が大きく変わります。

Harness optimization

最適化対象はこう移っています。

prompt → 構造化コンテキスト → ワークフロー → harnessコード → optimizerコード

初期のAIプロダクトは prompt を最適化しました。しかし prompt はシステムの一部にすぎません。より深い設計面には次があります。

何を context に入れるか
いつ tool を呼ぶか
失敗をどう分類するか
どのログを残すか
どの変更を自動 merge できるか
どこで人間レビューが必要か
sub-agent をどう分担させるか
evaluator をどう設計するか

目的関数は次のように書けます。

J(h; M, \mathcal{D}) = \mathbb{E}_{x \sim \mathcal{D}} \left[\text{score}(H_h(M,x))\right] - \lambda \text{Cost}(h) - \mu \text{Risk}(h)

良い harness は高得点なだけではありません。コストとリスクも制御されている必要があります。

コンテキスト工学

Context engineering は、記憶を長い会話ログではなく、構造化され、重複が除かれ、更新できる作業手帳に変えます。

ACE の考え方はこう整理できます。

役割	何をするか	学生の比喩
Generator	タスク軌跡を作る	問題を解く
Reflector	成功と失敗から学びを抽出	間違いを復習する
Curator	構造化 context を更新	ノートを整理する

Meta Context Engineering はさらに、「ノートに何を書くか」だけでなく、「ノートの書き方そのもの」を最適化します。

二層最適化はこうです。

\text{Inner: } c_s^*=\arg\max_{c_s}J_{\text{train}}(c_s;s)

\text{Outer: } s^*=\arg\max_{s\in\mathcal{S}}J_{\text{val}}(c_s^*)

内側は、ある context 管理スキルで最良の context を探すこと。

外側は、どの context 管理スキルが良いかを探すことです。

ワークフロー探索

ワークフローも最適化できます。

ワークフローはグラフとして表せます。

W = (V, E)

$V$ はモデル呼び出し、コード実行、テスト、レビューなどの行動です。
$E$ は「テストが落ちたら編集に戻る」のような遷移です。

探索目的は：

W^* = \arg\max_W J(W)

ADAS や AFlow が重要なのは、agent design を手書き prompt ではなく探索空間として扱うからです。

Self-Harness と権限境界

Self-Harness の考え方は強力ですが、境界づけられているからこそ安全に近づきます。

失敗パターンを掘る。
小さな harness 変更を提案する。
held-in タスクで既知問題が直ったか調べる。
held-out タスクで未知の退化がないか調べる。
回帰がなければ merge する。

危険も明確です。プログラムが自分を評価し制約するシステムを自由に編集できると、抽象境界が壊れます。

生産システムには少なくとも三つの境界が必要です。

境界	目的
編集可能範囲	harness の一部だけを変更できる
権限制御	重要リソースをループ外に置く
外部評価	評価器は被評価システムから編集できない

自己改善は、自己放任ではありません。

進化探索

Harness 設計の多くは、勾配で直接最適化しにくい一方で、候補を評価することはできます。

そこで候補 harness の集団を持ち、変異させ、評価し、良いものを残します。

一つの選択規則は次のように書けます。

P(h_i) \propto \frac{\exp(\beta J(h_i))}{1 + n_i}

高得点候補は選ばれやすい。ただし子どもを多く作りすぎた候補は割り引かれ、多様性を保ちます。

図5：進化探索では、得点だけでなくリスクと多様性も見る必要があります。価値があるのは、少しずつ改善する Pareto 前線です。

AlphaEvolve や Darwin Gödel Machine 型の仕事が面白いのは、評価できるタスクなら、候補を生成し、試し、良いものを残せるからです。

ただし限界もあります。

評価が遅いと高価になる
評価が曖昧だと自己欺瞞になる
報酬設計が悪いと reward hacking が起きる
短期スコアだけを追うと長期保守性を壊す

最も難しいのは評価器

自己改善の核心は、新案を出すことではありません。新案が本当に良いかを判断することです。

評価器が単体テストなら、agent はテストに過適合するかもしれません。

評価器が別のモデルなら、その judge に好かれる方法を学ぶかもしれません。

評価器が benchmark なら、benchmark の穴を使うかもしれません。

Agent が最適化するのは：

\nabla_h J_{\text{proxy}}(h)

しかし事業が欲しいのは：

\nabla_h J_{\text{real}}(h)

危険はこのズレです。

J_{\text{proxy}} \ne J_{\text{real}}

これは agent 時代の Goodhart の法則です。

企業への示唆

第一に、モデルだけを買ってはいけません。モデルの周りの operating system を買う必要があります。

企業価値は、再現可能な workflow、監査できる trace、復旧可能な失敗記録、検証済み評価セット、権限システム、実業務データにつながる tool layer から生まれます。

第二に、軌跡データは資産です。

Agent の実行は、何を読んだか、どのツールを使ったか、どこで失敗したか、どう復旧したか、どのテストが問題を見つけたかを記録します。これは単なるログではなく、次の harness 改善材料です。

第三に、AI組織は prompt 管理から harness 管理へ移る必要があります。

Prompt は文書で管理できます。Harness には version control、テスト、監視、rollback、権限、監査が必要です。

投資判断の見方

これは投資助言ではなく、分析枠組みです。

モデルAPIが商品化するほど、複利的価値はシステム層へ移ります。

AI moat matrix for harness engineering

図6：モデル重みとAPI接続は商品化圧力を受けます。評価体系、軌跡データ、業務フロー所有、権限・規制対応はより長期資産になり得ます。

見るべき問いは次です。

問い	良いシグナル	危険シグナル
評価体系を持つか	held-out テストと回帰基準	demo だけ
軌跡データを保存するか	失敗、tool call、修復経路	最終回答だけ
安全に改善できるか	小変更、検証、rollback	agent が自由にシステムを改変
権限は外部化されているか	安全層がループ外にある	最適化対象が評価器も編集
業務に埋め込まれているか	実業務システムと接続	チャット画面だけ
コストは制御されているか	routing、cache、並列管理	すべて最も高いモデル

長期の堀は、業務フロー所有、専有評価、タスク軌跡、深い tool integration、人間レビュー点、compliance system、失敗から学ぶ仕組みから生まれる可能性があります。

一文でまとめる

Scaling laws は、モデル、データ、計算量で AI 能力がどう伸びるかを説明します。

Harness engineering は、その能力が現実世界で長い仕事を安定してできるかを説明します。

現実的な自己改善ループはこうです。

より良い harness → より良いタスク軌跡 → より良い評価と記憶 → より良い harness

一夜でAIが自分を書き換える話より地味ですが、今日のAIプロダクトで複利が起きる場所としては、こちらの方が近いかもしれません。

References

Lilian Weng, Harness Engineering for Self-Improvement, 2026.
I. J. Good, Speculations Concerning the First Ultraintelligent Machine, 1965.
Eliezer Yudkowsky, Recursive Self-Improvement, 2008.
Zhang et al., Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models, 2025.
Ye et al., Meta Context Engineering via Agentic Skill Evolution, 2026.
Lee et al., Meta-Harness: End-to-End Optimization of Model Harnesses, 2026.
Zelikman et al., Self-Taught Optimizer: Recursively Self-Improving Code Generation, 2023.
Zhang et al., Self-Harness: Harnesses That Improve Themselves, 2026.
Hu, Lu, and Clune, Automated Design of Agentic Systems, 2025.
Zhang et al., AFlow: Automating Agentic Workflow Generation, 2025.
Novikov et al., AlphaEvolve: A coding agent for scientific and algorithmic discovery, 2025.
Zhang et al., Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents, 2025.
Trehan and Chopra, Why LLMs Aren't Scientists Yet: Lessons from Four Autonomous Research Attempts, 2026.