Harnessとは一体何なのか

harnessとは、基盤モデルを包む一式のシステムであり、実行プロセス全体をオーケストレーションする。モデルがどう考え計画するか、どうツールを呼んで行動するか、コンテキストをどう認識・管理するか、成果物をどこに保存するか、そして結果が正しいかをどう検証するかを取り仕切る。

初期のagent論では、「agent = モデル + メモリ + ツール + 計画 + 行動」という定式が使われていた。harnessエンジニアリングはさらにその上に、ワークフロー設計（例えばそのループをどう設計するか）、評価、権限制御、永続的な状態管理といった層を重ねる。これはすでにランタイムやソフトウェアシステムの設計にかなり近く、モデルがどう観察し、どう行動し、どう記憶し、どう自己点検し、どう改善していくかという全体を語るものになっている。

モデルに自分で計画・記憶させ、分身して働かせる

Wengはまず、具体的で実行可能な3つのharness設計パターンを示す。これらが答えるのは同じ問いだ——長時間自律的に働けるシステムには、根本的にどんなピースが必要か。

パターン1：モデルに「反復できるワークフロー」を与える

鍵となるのは、モデルが「手を動かし、テストし、また直す」を繰り返せる流れをまず区切っておくことだ。よく使われるのは目標志向のループ：まず計画し、次に実行し、結果を観察・テストし、そして改善し、また実行する——これを一巡また一巡と、目標を達成するまで繰り返す。過程でモデルは主体的にユーザーに聞き返し、タスクを明確化することもできる。Karpathyのautoresearchリポジトリは、このワークフローの分かりやすい好例だ。このループが特に強調しているのは、モデルが自分の実行した軌跡や失敗事例を分析し、それをもとに反復すべきだという点であり、固定的なプロンプトのテンプレートに固執すべきではないということだ。

簡略化されたCodex agentループ：agentがツールを呼び出し、ツールが返した結果がモデルの次の生成に影響を与える。図の出典：OpenAI Codex agentブログ記事

パターン2：ファイルシステムをモデルの長期記憶にする

長時間働くagentでは、実験ログ、コードのdiff、論文の要約、エラー記録、過去の実行軌跡が、モデルが訓練時に見たコンテキストウィンドウよりもすぐに長くなってしまう。だからharnessは、プロセス全体とすべてのログを無理やりコンテキストに詰め込むのではなく、こうした永続的な状態をファイルに書き出し、必要なときに読み戻すべきだ。ファイルの読み書き・編集（一般にbashコマンドに頼る）はもともとAIモデルの基本スキルであり、ファイルというもっとも素朴な形で長期記憶を管理する方法は、モデル自体の能力向上とともに自然に良くなっていく。

パターン3：サブagentを並行させて働かせ、それでいて統制する

1つのharnessは複数のサブagentを派生させて並行実行させ、そのバックグラウンドタスクを見張ることができる。主agentが複数の仮説を同時に試したい、実験を並行して走らせたい、あるいは独立したサブタスクを切り出して主線のコンテキストを汚したくない、というときにこれが役立つ。このとき主agentには小型のプロセスマネージャーが必要になる——タスクを起動し、ログを確認し、失敗した実行をキャンセルし、結果を主線に統合できるものだ。

ここで最も重要な設計は、並行作業を検証可能・痕跡可能にすることだ。サブagentの成果が揮発性の会話コンテキストにしか存在しないなら、それらはすぐに古くなり、埋もれてしまう。ファイル、ログ、状態記録として保存して初めて、モデルは中断後に復帰でき、自分の実行履歴を振り返って整理できるようになる。

この3つを組み合わせると、現在主流のコーディングagentの姿になる。Wengが指摘するのは、Claude Code、Codex、OpenCode、Cursorといった製品のコアインターフェースがすでに収束しつつあり、いずれも類似した一連のツールで動いているということだ：

コーディングagentは一式のツールを手にすることで、コードリポジトリの中で開発・デバッグができる。人間の開発者が一式のIDEを持っているのとよく似ている。図の出典：Lil'Log

改変される対象はずっと格上げされ続けている：プロンプト改変から直接のコード改変へ

これが全文の中核をなす流れだ。harnessシステムの中で「最適化の対象」となるものは、一本の階段を上り続けている——プロンプト、構造化コンテキスト、ワークフロー、harnessコード、そして最適化器のコード。モデルが強くなるほど、それが扱える最適化の対象はより複雑に、より汎用的になっていく。

以下、三段階に進む3つの事例で、この階段を掘り下げよう。

ACE：コンテキストを差し替え式のノートとして扱う

すべてのツール応答とモデル生成をそのままコンテキストに積み上げていくと、タスクが長くなるにつれ収拾がつかなくなる。Agentic Context Engineering（ACE）は発想を変える——コンテキストを、書き足すたびに長くなる一本の文章としてではなく、項目が絶えず追加されていく差し替え式ノートとして維持するのだ。ノートの各項目には番号と一文の説明が付く。これは3つの役割が協働することで成り立つ：

ACEのカギとなる設計は、Curatorがプロンプト全体を書き直すのではなく、「番号+説明」の項目群を生成し、確定的なロジックで構造化ノートに統合し、定期的に精錬・重複除去を行う点にある。こうすることで、繰り返し書き直すことで「直すほどに細部が失われていく」という古くからの弊害——コンテキストの崩壊と過度な簡略化——を避けられる。

Agentic Context Engineering（ACE）フレームワーク：Generator、Reflector、Curatorの3役が協働し、項目化されたコンテキストノートを維持する。図の出典：Zhang et al. 2025

MCE：「ノートの管理方法」そのものも最適化する

ACEは実行軌跡から経験を学べるようになったが、その更新ルールと一連の流れは依然として人間が手で書いたものだ。Meta Context Engineering（MCE）はさらに一歩進み、「メカニズム」と「内容」を切り分ける——一方の層は具体的なコンテキストに何を入れるかを管理し（内層）、もう一方の層は「どんな方法でコンテキストを管理するか」を管理する（外層）。

具体的には、内層はあるタスクの具体的なコンテキストを最適化する戦略を与えられ、外層は過去の戦略と評価成績を記録したスキルライブラリの中で、交叉（crossover）の手法によって新しい戦略を進化させる。ACEと異なり、MCEはコンテキストがどんな形であるべきかを強制せず、自由形式の「スキル」を使ってあるタスクにとって最も重要な知識を保存し、スキルとそれに対応するコンテキストを一緒に進化させる。実装形態としては、専用ディレクトリ下の一群のファイル——静的なskill.mdもあれば、動的なコンテキストやデータファイルもある——になる。

Meta Context Engineering（MCE）：外層は「コンテキスト管理メカニズム」の中でスキル進化の探索を行い、内層は具体的なタスクのコンテキストを最適化する。図の出典：Ye et al. 2026

Meta-Harness：コーディングagentを使って直接harnessを作る

Meta-Harnessはさらにもう一段深い——最適化される対象は、「どんな情報を保存し、取得し、モデルに提示すべきか」を決めるそのコード自体になる。名前の「Meta-」とは、これがharnessを最適化するためのharnessだという意味だ。

新しいharnessを提案する提案者自体が、一つのコーディングagentであり、最終的に出力するのはパレートフロンティア複数の指標を同時に最良にできないとき（例えば正確さも速さも両方欲しいとき）、「他のどの案もあらゆる指標で同時に上回れない」一群を選び出すこと。単一の最適解を無理に選ぶのではない。上に位置するharness候補群だ。いくつかの細部が興味深い——実行履歴全体はファイルシステムに置かれ、コーディングagentはgrep、catでそれを読む。すべてを一つのプロンプトに詰め込むのではない。提案された各harnessは、ファイルシステム上の一つの辞書で、自身のソースコード、スコア、実行軌跡、状態更新を保持する。このループは新しいharnessを繰り返し生み出し、基準に達したものだけが残される。

Meta-Harnessの外層最適化フロー：一つのコーディングagentが新しいharness候補を繰り返し提案・評価・選別する。図の出典：Lee et al. 2026

この三段階を通じてWengが言いたいことははっきりしている——harnessの設計が実行可能な探索空間になった瞬間、十分に強いコーディングagentは、人間のエンジニアが使うのと同じその設計空間を採掘できるようになる。

詳細を見る：ワークフロー自体も探索問題として扱う

階段の中の「ワークフロー」という層も、人間が手作業で設計するだけでなく、アルゴリズムに探索させることができる。ADAS（Automated Design of Agentic Systems）は、agentの設計自体を最適化問題として扱う——まずCoT、self-refineといった単純なagentでアーカイブを構築し、次にメタagentがアーカイブ中の既存案を参考にしながらコードで新しいagent設計を書き、評価に通れば再びアーカイブに加える、というのを繰り返す。

ADAS：メタagentがコードで新しいagentワークフロー設計を繰り返し提案する。図の出典：Hu et al. 2025

AFlowはagentワークフローを一枚のグラフとして表現する——ノードはモデルを呼び出すアクション、エッジはコードで実装されたロジック操作——そのうえでモンテカルロ木探索（MCTS）を使ってこのグラフを最適化する。テンプレートから始め、スコアと探索を組み合わせた戦略でノードを選び、モデルに現在の成績をもとに新しいワークフローを作らせ、評価し、改善があれば木に加え戻す、というのを、スコアが頭打ちになるか予算を使い切るまで続ける。質問応答、コード、数学のタスクにおいて、AFlowは人手設計のワークフローやADASと比べても良い成績を出している。

AFlowと人手による手法、ADASとの比較実験。図の出典：Zhang et al. 2025

自動研究向けに専用設計されたワークフローも少なくない。例えばAI Scientist（アイデア出し、コード執筆、実験実行、論文執筆、査読までの一連のパイプライン）、ScientistOne（検証可能性を核心の制約に据え、あらゆる主張を証拠源に遡れるようにする）、そして「データサイエンティスト」役を担うAutodata（出題者・強い解答者・弱い解答者・審判の複数役を使い、難易度が「ちょうどよい」訓練データを合成する）などだ。

harnessに自分自身へ手術させる

前節までは「最適化の対象」が階段を上る話だった。この節では、AIはすでに本当の意味で自律的に自分の運用システムのコードを改変できるようになっている。単なるパラメータ調整ではない。

STOP：問題を解くのではなく、「解答を担当するその改善器」を改変する

Self-Taught Optimizer（STOP）は、再帰的に外殻を改善する早期の事例の一つだ。「種となる改善器」を持ち、入力は初期解、良し悪しを測る効用関数、ブラックボックスとして使う言語モデルで、出力はより良い解になる。STOPが本当に最適化しているのはこの改善器自体だ——前バージョンの改善器を使って次バージョンの改善器を生成し、一層また一層と自己最適化を重ねていく。

Zelikmanらの実験では、進化してきた改善器は実際にさまざまな戦略を自ら生み出した——遺伝的アルゴリズム、問題を分割して個別に改善する方法、多腕バンディット式のプロンプト探索、シミュレーテッドアニーリング、温度調整、ビームサーチや木探索。これはまさに、harnessのワークフローが最適化対象として扱えることを示している。

Self-Taught Optimizer（STOP）アルゴリズム：前バージョンの改善器を使って次バージョンを再帰的に生成する。図の出典：Zelikman et al. 2023

Self-Harness：弱点を掘り、改変を提案し、検証してから統合する

より新しいSelf-Harnessは、agentが「提案、評価、受理」のループを通じて自分のharnessを改善できるようにする。この循環は3つのステップに分かれる：

弱点を掘る：現行のharnessでタスクを実行させ、実行軌跡を収集して分析する。2回の失敗はエラーメッセージ上では同じように見えることがある（どちらもタイムアウト、どちらも成果物欠落）が、その背後の因果メカニズムは異なることがある。だから必要なのは、検証器レベルの終端的な原因だけでなく、関連する挙動の因果的な状態や、軌跡から浮かび上がる抽象的なメカニズムまで含んだ、情報量の豊かな失敗記録であり、これによって根本原因を掘り起こす——表面的なエラーメッセージだけを見るのではなく。

改変を提案：同じモデルが提案者として使われ、限定された情報を渡される——現行harnessの中で改変可能な部分、検証済みの失敗パターン、保持すべき通過済みの挙動、そしてこれまで試した改変の要約だ。優先して選ばれるのは、繰り返し現れ、かつ狭い範囲の改変で解決できるエラーであり（タスク自体が難しすぎるといった類のものではない）、候補同士は互いに異なり、多様性を持たなければならない。

検証して統合：候補となる改変は、held-in（弱点が本当に解消されたかを検証）とheld-out（別の未知の問題を持ち込んでいないかを検証）の2組のデータで回帰テストを行わなければならず、両方とも後退しない場合にのみ受理され、統合されて新バージョンのharnessになる。却下された候補は記録として残るが、現行のharnessは変更されない。MiniMax M2.5、Qwen3.5-35B-A3B、GLM-5という3つの異なる土台モデルで、Self-Harnessはそれぞれ専用のharness指示を学び出し、モデルごとに異なる弱点に対応させ、held-outの通過率を向上させた。

Self-Harnessの「弱点を掘る → 改変を提案 → 検証して統合」循環。図の出典：Zhang et al. 2026

もう一つの道：大量に変異体を作り、強いものを残し弱いものを淘汰する

これまでは一歩ずつ改変する話だった。もう一つの道は、自然選択のように——大量に変異体を作り、「適応度」の高いものだけを残し、弱いものを淘汰していく。探索空間が大きく捉えどころがなく、勾配で直接最適化するのが難しい一方で、ある案の良し悪しを採点するのは容易なとき、この進化的探索が力を発揮する。harnessの探索はまさにこの特徴に当てはまる。

進化的探索はすでにプロンプト最適化に使われてきた。例えばPromptbreeder（「モデルにプロンプトを変えさせるための、その変異プロンプト」自体も一緒に進化させる）、GEPA（反省に基づくプロンプトと進化的探索を組み合わせ、自然言語による試行錯誤軌跡の反省で改変を提案する）などだ。コード改変の層に来ると、代表格は以下の通りだ。

AlphaEvolve：プログラムプールを維持し、モデルに絶えずdiffを出させる

AlphaEvolveは、コーディングagent型の進化的探索システムだ。候補プログラムのプールを維持し、凍結されたモデルにdiff形式の修正を生成させ、子プログラムを繰り返し評価して成功したものを残し、時間をかけてより良い解を見つけていく。いくつかの設計上の細部——プロンプトには親プログラム、結果、指示、時にメタ情報も含まれる。コーディングagentはリポジトリ全体を見られるが、進化させてよいコード領域は# EVOLVE-BLOCK-STARTと# EVOLVE-BLOCK-ENDで明示的に区切られる。メタプロンプト自体も、解を求めるプログラムと一緒に進化していく。後継のShinkaEvolveは、サンプリング効率を上げる3つの工夫を追加した——よりサンプル効率の良い親サンプリング（成績のランキングと子孫の数のバランスを取る）、埋め込みのコサイン類似度で既存の個体群に似すぎた候補を除去する、そして成功した案のパターンを記録するメタメモ帳で以降の変異を誘導する、というものだ。ThetaEvolveは進化的探索と強化学習、コンテキスト内学習を組み合わせている。

AlphaEvolve：候補プログラムプール + 凍結モデルによるdiff生成 + 評価による成功した子孫の保持。図の出典：Novikov et al. 2025

AlphaEvolveの複数のアルゴリズムタスクにおける実験結果。図の出典：Novikov et al. 2025

DGM：「自分のコードを改変できるコーディングagent」を直接進化させる

Darwin Gödel Machine（DGM）は、上記の「解」を最適化する手法とは異なり、編集可能なharnessコードリポジトリを進化させることを狙う——このagentは自分自身のharnessを直接改変することを許される。プロセスはダーウィンの進化論のようだ：

プールの中の一つのコーディングagentからスタートする。毎ラウンド、「成績が良く、すでに子孫が少ない」ほど選ばれやすい確率で親を選び、これを改変・分岐させて新しいagentを生む。選ばれた親は自分の評価ログを振り返り、自身のharnessコードに改善を加えて新バージョンを生成する。コード編集にはbashとeditor（ファイルの閲覧・新規作成・編集）という2つの基礎ツールしか使わない。新しいagentは評価を受け、十分に良い成績のものだけがプールに加え戻される。DGMは固定されたモデルの下でharnessを進化させ、実験の土台にはClaude 3.5 Sonnetを使っている。後継のHyperagentsは、さらにメタagentを導入し、「既存のtask agentをどう改造して新しいagentを生むか」を専門に制御させている。

Wengが指摘するのは、この系統の手法は「候補案が自動評価でき、適応度が定量化しやすい」領域で最も力を発揮するということだ。例えば行列乗算、GPUカーネル最適化、アルゴリズムコンテスト、データセンタースケジューリングなど。評価が遅く、曖昧で、主に人間の判断に頼る領域になると、途端に苦しくなる。そのうえ進化そのものの計算効率と有効性も懸念材料であり続ける。

詳細を見る：モデル自身の重みも同時に変えられるか

harnessの進化が変えるのは、モデルの周りにある非パラメータ的なシステムだ。完全な自己改善を実現するには、モデルにも自分の重みを更新することを同時に許してよく、訓練パイプラインの改善やテスト時の継続学習によって実現できる。SIAは、harnessの改善とモデルパラメータの更新を同じ最適化ループに入れた早期の試みで、3つの役割が設計されている——Meta-Agentが初期harnessを提案し、Task-Specific Agentがタスクを実行し、Feedback-Agentが直近の軌跡をもとに今回はharnessを変えるべきか重みを変えるべきかを判断する。ただしWengが指摘するのは、SIAの実験にはいくつかの交絡要因があり、結果の解釈が難しいという点だ（例えばタスクを実行するagentが他の2つの役割よりずっと弱いモデルを使っている、ベースラインも弱めであるなど）。方向性としては興味深いが、証拠はまだ初歩的なものにとどまる。継続学習それ自体は、単独で一本記事を書く価値のあるテーマだ。

SIA：harnessの改善と重みの更新を同じループに入れる。図の出典：Hebbar et al. 2026

この道が今ぶつかっている7つの壁

進展は確かに本物だ。だが境界線もはっきりしている。Wengは現時点でまだ解けていない7つのボトルネックを挙げており、ざっと眺めるだけで現状がどこで止まっているかが分かる。

報酬ハッキングについて、Wengはさらに具体的な一言を添えている——評価器と権限制御は、進化するharnessのそのループの外側に座らせておくのが望ましく、あわせてheld-outテスト、軌跡の監査、そして重要な意思決定点での人間によるレビューを残しておくべきだ。こうした監督がどこまで自動化・スケール化できるかは、それ自体まだ開かれた研究課題である。

AIが自分で研究する、今どこまで来ているか

最後に、実測データに話を戻そう。AI Scientistの系統は、専門家が設計したharnessが自動研究ループのかなりの部分を協調できることを確かに証明した。しかし、それなりの論文を書けることは、科学的発見を成し遂げたこととイコールではない——システムはもっともらしく見える原稿を書けても、その裏では引用がでっち上げられていたり、実装が歪んでいたり、実験結果が根拠を欠いていたりすることがある。

AI Scientistパイプライン：アイデア出し、実験実行、論文執筆から査読までの一連の自動化フロー。図の出典：Lu et al. 2026

以下の早見表を見れば、「自動研究」が今どの水準で止まっているか一目で分かる：

補足：RE-Benchでは、人間の専門家は8時間の試行の82%でゼロでないスコアを獲得し、24%は参照解に達するかそれを上回った。データは61人の専門家による71回の8時間試行に基づく。

アイデアを実際に論文にする、どこでつまずくのか

Trehan & Chopra 2026は、より現実に近い実験を行った。モデルにはread_file、write_file、llm_search、list_filesといった基本的なツールだけを与え、研究アイデアから完成原稿まで一気通貫でたどり着けるかを見た。彼らは世界モデル、マルチエージェント強化学習、AI安全性・アライメントの3領域それぞれについて、新しいアイデアを喚起するための質の高いシード文書を45〜50本ずつ用意した。

プロセス中には6種類の失敗モードが繰り返し露呈した：

• 訓練データ中のデフォルトへの偏り：古びたライブラリ、時代遅れのコマンド、標準フォーマットを使ったり、実際のリポジトリやデータセットに基づかない仮定を置いたりする。
• 実行の重圧下での実装のドリフト：実装が技術的に複雑になると、モデルは元々提案した手法ではなく、より一般的でより簡単な方式に流れやすくなる。
• 記憶とコンテキストの劣化：長期プロジェクトでは、重要な細部は永続的な成果物として書き残されない限り失われてしまう。
• 過度な楽観：実験結果がまだノイズの範囲内、あるいはすでに失敗しているにもかかわらず、モデルは成功を宣言してしまう。他の場所でも観察されている「p値のつじつま合わせ、悟った振り」であり、「数値の絆創膏」で無理やり取り繕う。
• ドメイン直感の不足：モデルには、実装の複雑さを見積もる、実験結果が信頼できるか判断する、どの基準線が重要かを知るといった、言葉にしにくい職人的な勘が欠けている。
• 研究のセンスの弱さ：実験は動かせても、本当に問うべき問いには答えられていない。

Wengの締めくくりの姿勢は明確だ——完全なRSIに向けて、研究者たちは確かな進展を上げてきた。だが上記のボトルネックはまだ残っており、その多くは人間のフィードバックと導きを必要とする。結局のところ、我々がこの技術を作っているのは、人間にとってより良い未来のためであって、その逆ではないのだから。

Wengの見立てはこうだ——直近の自己進化は、モデルが重みを直接書き換えることを期待すべきではなく、まずは「デプロイシステム」の層に落ち着く。その中で最も重要な部品がharness（モデルの外側を包む運用システムで、ツールの呼び出し、コンテキストと記憶の管理、結果の検証を担う）だ。

だが「外殻を改変する」とは具体的に何を改変するのか、AIはどうやって自分の手で動かすのか？これがまさに全文の核心だ。

改変される対象は、一本の階段を上っていく——プロンプト → 構造化コンテキスト → ワークフロー → harnessコード → 最適化器のコード。上に行くほど、AIが自分で探索できる空間は広がり、モデルの地力も要求される。最もカギとなる層は、AIに自分の運用コードを直接改変させることで、具体的には次のように回る：

公式発表の「スコアが20%から50%に上がった」だけでは、普通の人にはピンとこない。同じ具体的なバグ数に置き換えれば一目瞭然だ（バーが長いほど修正できたバグが多い）。