AIの自己進化はまずモデルの外側から：Lilian Wengが語るハーネス工学
- 元OpenAI安全システム責任者のLilian Weng氏が「harnessエンジニアリング」を提唱。AIモデルを包み、ツール呼び出し、コンテキスト管理、記憶、評価を担う実行システムであり、AIの再帰的自己改善（RSI）への鍵でありながら見過ごされがちな要素だと指摘。
- 彼女は、harness内で最適化される対象を、プロンプト、構造化コンテキスト、ワークフロー、harnessコード自体、そしてオプティマイザコードへと続く進化の階梯として整理。階梯を上がるほど、探索可能な設計空間は広がる。
- 論文では、ACE、MCE、Meta-Harness、STOP、Self-Harness、AlphaEvolve、DGMなど、2023年から2026年にかけての20以上の研究を概観。AIが自らの「外殻」に変更を提案し、テストを実行し、より強力なバージョンを残せることを示している。
- 実証的証拠は自己進化の有効性を示している。DGMはプログラミングエージェントの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のような成功したプログラミングエージェント製品の背後にあるシステムだ。本稿が焦点を当てるのは、まさにharnessエンジニアリングを巡る研究と、それがどのように自己改善へと一歩ずつ繋がっていくかである。
Harnessとは一体何か
harnessとは、基盤モデルの外側を包むシステム全体を指す。実行プロセス全体を編成し、モデルがどのように思考・計画し、ツールを呼び出して行動し、コンテキストを認識・管理し、生成物をどこに保存し、そして結果が正しいかをどう検証するかを決定する。
初期のエージェントの定義は「エージェント = モデル + 記憶 + ツール + 計画 + 行動」だった。harnessエンジニアリングは、その上にさらにいくつかの層を加える。ワークフロー設計（例えば、ループをどう設計するか）、評価、権限管理、永続的な状態管理などだ。これはもはやランタイムやソフトウェアシステムの設計に近く、モデルがどのように観察し、行動し、記憶し、自己点検し、改善するかという一連のサイクルを扱う。
harnessとモデルの関係は、オペレーティングシステム（OS）とCPUの関係によく似ている。モデルは根源的な計算能力を提供するCPUであり、harnessはその周りで動作し、スケジューリング、権限管理、ファイルストレージといった「汚れ仕事」を担当するOSだ。OSと同様に、優れたharnessは複雑なロジックを内部に隠蔽し、外部へのインターフェースはシンプルに保つ。Weng氏はまた、業界の発展に伴い、設定やツールインターフェースなどのプロトコルは徐々に標準化されていくだろうと述べている。
モデルに自己計画、記憶、そして分身作業をさせる
Weng氏はまず、具体的で実行可能な3つのharness設計パターンを提示する。これらは共通の問いに答えるものだ。すなわち、長時間自律的に作業できるシステムには、最低限どのようビルディングブロックが必要か、という問いだ。
パターン1：モデルに反復可能なワークフローを与える
重要なのは、モデルが「実行し、テストし、修正する」ことができるプロセスをまず定めることだ。一般的なのは、目標指向のループである。まず計画し、次に実行し、結果を観察またはテストし、続いて改善し、再び実行する。このサイクルを目標達成まで回し続ける。その過程で、モデルは能動的にユーザーに質問し、タスクを明確にすることもできる。Karpathyのautoresearchリポジトリは、この種のワークフローのクリーンな一例だ。このループが特に強調するのは、モデルが自身の実行軌跡や失敗例を分析し、それに基づいて反復することであり、固定されたプロンプトテンプレートに固執することではない。
パターン2：ファイルシステムをモデルの長期記憶と見なす
長時間稼働するエージェントでは、実験ログ、コードの差分、論文要約、エラー記録、過去の実行軌跡などが、モデルが訓練時に見たコンテキストウィンドウよりもすぐに長くなってしまう。そのため、harnessはプロセス全体と全ログをコンテキストに無理やり詰め込むのではなく、これらの永続的な状態をファイルに書き込み、必要な時に読み戻すべきだ。ファイルの読み書きや変更（通常はbashコマンドに依存）は、もともとAIモデルの基本スキルであり、ファイルという最も素朴な形式で長期記憶を管理することは、モデル自体の能力向上に伴って自然と改善されていく。
パターン3：サブエージェントを並行作業させ、かつ管理下に置く
一つのharnessは、複数のサブエージェントを派生させて並列実行させ、それらのバックグラウンドタスクを監視することができる。これは、メインエージェントが複数の仮説を同時に試したり、実験を並行して実行したり、独立したサブタスクを切り離したいがメインのコンテキストを汚したくない、といった場合に非常に有用だ。このとき、メインエージェントには小規模なプロセス管理機能が必要になる。タスクの起動、ログの閲覧、失敗した実行のキャンセル、そして結果をメインのラインに統合する機能だ。
ここでの最も重要な設計は、並列処理を検証可能かつ追跡可能にすることだ。もしサブエージェントの出力が揮発性の対話コンテキスト内にしか存在しないなら、それらはすぐに古くなり、埋もれてしまう。ファイル、ログ、状態記録として保存して初めて、モデルは中断後に再開し、自身の実行履歴を遡って整理することができる。
これら3つのピースを組み合わせると、現在の主流なプログラミングエージェントの姿が見えてくる。Weng氏は、Claude Code、Codex、OpenCode、Cursorといった製品のコアインターフェースは既に収斂しつつあり、同様のツールセットを使って動作していると指摘する。
