AIの自己進化は、まずモデルの外側の殻から変わる——Lilian Wengが語るharnessエンジニアリング
- 元OpenAI安全システム責任者のLilian Wengが「harnessエンジニアリング」という概念を提唱。モデルを包み込み、ツール呼び出し・コンテキスト管理・メモリ・評価を担うこの運用システム層こそ、AIの再帰的自己改善（RSI）への道筋を左右する、見落とされがちな鍵だと説く。
- harnessの中で最適化される対象を、一本の階段として整理した：プロンプト、構造化コンテキスト、ワークフロー、harnessコード自体、そして最適化器のコード。上に行くほど、探索可能な設計空間は広がる。
- 記事はACE、MCE、Meta-Harness、STOP、Self-Harness、AlphaEvolve、DGMなど、2023年から2026年にかけての20以上の研究を整理し、AIがすでに自分自身の「外殻」に改修を加え、テストを走らせ、より強い版を残せることを示している。
- 実測データは自己進化が確かに効くことを示す：DGMはコーディングagentのSWE-bench Verifiedのスコアを20%から50%へと進化させた。ただしSTOPの実験は、この仕組みが土台となるモデルが十分強いときにしか機能せず、弱いモデルではむしろ劣化することも示している。
- 記事の最後では、この路線が現在ぶつかっている7つのボトルネック——評価基準の弱さ・曖昧さ、報酬ハッキング、多様性の崩壊など——を挙げ、人間は循環の外に追い出されるのではなく、重要な節目に留まって監督すべきだと強調する。
なぜモデルの外側にあるものが急に重要になったのか
OpenAI元安全システム責任者のLilian Wengが、個人ブログLil'Logで長文を発表し、「harnessエンジニアリング」というテーマを提唱、AIの再帰的自己改善（RSI）の研究方向と体系的に結びつけた。
彼女の核心的主張はシンプルだ——モデルと現実世界の間に立つシステムは、モデルそのものの生の知能と同じくらい重要である。人はモデルがどれほど賢いかにばかり注目しがちだが、その外側を包み、すべてを調整するその殻の重要性を、私たちはしばしば過小評価している。
なぜ読む価値があるか：RSIという発想は、1965年にI.J. Goodが提唱した「超知能機械」（自分より賢い機械を作れる機械）まで遡ることができ、2008年にYudkowskyがこれに「再帰的自己改善」という名を与えた。現代版は、モデルが自分の重みを直接書き換える形もあれば、モデルが訓練パイプラインやデプロイシステムを改善していく、より間接的だが現実味のある形もある。Wengは、AnthropicとOpenAIの両社が、フロンティア研究所の研究スピードが明らかに加速していることを観測していると指摘する。
Wengの見立てはこうだ——直近のRSIは、いきなりモデルが自分の重みを直接書き換える形にはなりにくい。むしろ最初は「デプロイシステム」の層に現れ、そのデプロイシステムの中で最も重要な部品がharness、つまりClaude CodeやCodexといった成功しているコーディングagent製品を支えるあのシステムだ。この記事が焦点を当てるのは、harnessエンジニアリングをめぐる研究、そしてそれがどのように自己改善へと一歩ずつつながっていくかである。
Harnessとは一体何なのか
harnessとは、基盤モデルを包む一式のシステムであり、実行プロセス全体をオーケストレーションする。モデルがどう考え計画するか、どうツールを呼んで行動するか、コンテキストをどう認識・管理するか、成果物をどこに保存するか、そして結果が正しいかをどう検証するかを取り仕切る。
初期のagent論では、「agent = モデル + メモリ + ツール + 計画 + 行動」という定式が使われていた。harnessエンジニアリングはさらにその上に、ワークフロー設計（例えばそのループをどう設計するか）、評価、権限制御、永続的な状態管理といった層を重ねる。これはすでにランタイムやソフトウェアシステムの設計にかなり近く、モデルがどう観察し、どう行動し、どう記憶し、どう自己点検し、どう改善していくかという全体を語るものになっている。
harnessとモデルの関係は、OSとCPUの関係によく似ている。モデルは生の計算力を提供するCPUで、harnessはその周りで走るOS、スケジューリング・権限管理・ファイル保存といった「地味な仕事」を担う。OSと同じく、優れたharnessは複雑なロジックを内部に隠し、外向きのインターフェースはシンプルに保つ。Wengは、業界の発展とともに、設定やツールインターフェースといったプロトコルも次第に標準化へ向かうだろうとも述べている。
モデルに自分で計画・記憶させ、分身して働かせる
Wengはまず、具体的で実行可能な3つのharness設計パターンを示す。これらが答えるのは同じ問いだ——長時間自律的に働けるシステムには、根本的にどんなピースが必要か。
パターン1：モデルに「反復できるワークフロー」を与える
鍵となるのは、モデルが「手を動かし、テストし、また直す」を繰り返せる流れをまず区切っておくことだ。よく使われるのは目標志向のループ：まず計画し、次に実行し、結果を観察・テストし、そして改善し、また実行する——これを一巡また一巡と、目標を達成するまで繰り返す。過程でモデルは主体的にユーザーに聞き返し、タスクを明確化することもできる。Karpathyのautoresearchリポジトリは、このワークフローの分かりやすい好例だ。このループが特に強調しているのは、モデルが自分の実行した軌跡や失敗事例を分析し、それをもとに反復すべきだという点であり、固定的なプロンプトのテンプレートに固執すべきではないということだ。
パターン2：ファイルシステムをモデルの長期記憶にする
長時間働くagentでは、実験ログ、コードのdiff、論文の要約、エラー記録、過去の実行軌跡が、モデルが訓練時に見たコンテキストウィンドウよりもすぐに長くなってしまう。だからharnessは、プロセス全体とすべてのログを無理やりコンテキストに詰め込むのではなく、こうした永続的な状態をファイルに書き出し、必要なときに読み戻すべきだ。ファイルの読み書き・編集（一般にbashコマンドに頼る）はもともとAIモデルの基本スキルであり、ファイルというもっとも素朴な形で長期記憶を管理する方法は、モデル自体の能力向上とともに自然に良くなっていく。
パターン3：サブagentを並行させて働かせ、それでいて統制する
1つのharnessは複数のサブagentを派生させて並行実行させ、そのバックグラウンドタスクを見張ることができる。主agentが複数の仮説を同時に試したい、実験を並行して走らせたい、あるいは独立したサブタスクを切り出して主線のコンテキストを汚したくない、というときにこれが役立つ。このとき主agentには小型のプロセスマネージャーが必要になる——タスクを起動し、ログを確認し、失敗した実行をキャンセルし、結果を主線に統合できるものだ。
ここで最も重要な設計は、並行作業を検証可能・痕跡可能にすることだ。サブagentの成果が揮発性の会話コンテキストにしか存在しないなら、それらはすぐに古くなり、埋もれてしまう。ファイル、ログ、状態記録として保存して初めて、モデルは中断後に復帰でき、自分の実行履歴を振り返って整理できるようになる。
この3つを組み合わせると、現在主流のコーディングagentの姿になる。Wengが指摘するのは、Claude Code、Codex、OpenCode、Cursorといった製品のコアインターフェースがすでに収束しつつあり、いずれも類似した一連のツールで動いているということだ：
