HyperAgents、「改善の仕方」の改善はコーディング以外にも転移する
目次
AIエージェントの改善ループを自動化する試みはここ数ヶ月で急速に進んだ。KarpathyのAutoresearchはML実験の設計→実行→評価を自動ループにし、MicrosoftのAgent Lightningはエージェントに強化学習を適用するフレームワークを提供した。Claude CodeとCodexをtmuxで連携させる実験を自分でやったときも、実装→レビュー→修正のループを手で設計していた。
これらのアプローチには共通の前提がある。「何を改善するか」はAIが決めるが、「どう改善するか」は人間が設計している。Autoresearchはハイパーパラメータの探索空間を自動で回るが、探索戦略そのものは固定。Agent Lightningは報酬信号に基づいてエージェントを最適化するが、報酬の設計と最適化アルゴリズムの選択は人間が行う。
Meta AIが2026年3月に発表したHyperAgents（arXiv:2603.19461、GitHub）は、この「どう改善するか」自体をAIの最適化対象にした。そして最も興味深い結果は、あるドメインで獲得した改善戦略が、全く別のドメインに転移したことだ。
DGMの「偶然の整合性」とその限界
HyperAgentsの先行研究であるDarwin Gödel Machine（DGM）は、コーディングドメインで自己改善を達成していた。コードを書いて、そのコードを自己修正するループを世代ごとに回すことで、性能が上がっていく。
このシステムがコーディングで機能したのは、よく考えると偶然だ。
コーディングエージェントの「タスク能力」はコードを書くことで、「自分を改善する能力」は自分のコードを修正すること。どちらも「良いコードを書く」という同一スキルセットに収まる。コーディングがうまくなれば、自分のソースコードを修正するのもうまくなる。タスク性能の向上が改善能力の向上に直結するから、正のフィードバックループが回っていた。
他のドメインではこの整合性が成り立たない。論文査読エージェントを例にとる。タスク能力は「論文の質を正しく評価すること」だが、自己改善に必要な能力は「自分の評価ロジック（Pythonコード）を的確に修正すること」だ。良い査読者になったからといって、それが直接Pythonの修正能力の向上にはつながらない。「論文の構成を見抜く目」と「コード変更のインパクトを予測する能力」は全く別のスキルだ。
| ドメイン | タスク能力 | 自己修正に必要な能力 | 整合するか |
|---|---|---|---|
| コーディング | コードを書く | 自分のコードを修正する | する（同じスキル） |
| 論文査読 | 論文の質を評価する | 自分の評価ロジックのコードを改善する | しない |
| 報酬設計 | 報酬関数を設計する | 自分の設計手続きのコードを改善する | しない |
| 数学採点 | 数学の解答を採点する | 自分の採点ロジックのコードを改善する | しない |
DGMの自己改善は汎用的な性質ではなく、タスク能力と自己修正能力がたまたま一致するドメインでしか回らない構造的制約を持っていた。
タスクとメタの分離
HyperAgentsはこの制約を、タスクエージェントとメタエージェントの明示的な分離で解消した。
hyperagents/
├── task_agent.py # タスクを解くエージェント
├── meta_agent.py # コードベース全体を書き換えるエージェント
├── generate_loop.py # 生成→評価→アーカイブのループ
└── domains/ # ドメイン別の評価ハーネスtask_agent.py は対象タスクを解くエージェント。ドメイン情報を含む inputs 辞書を受け取り、LLMをツール付きで呼び出して予測をJSONで返す。meta_agent.py はリポジトリ内のコードベース全体を読み取り、過去の評価結果を参照しながらdiff（コードパッチ）を生成する。変更対象は task_agent.py、meta_agent.py、または両方。
決定的なのは、meta_agent.py が自分自身を変更対象にできる点だ。タスクの解き方だけでなく、「改善の仕方」そのものが書き換え可能になる。論文ではこれをメタ認知的自己修正（metacognitive self-modification）と呼んでいる。
flowchart LR
subgraph DGM
A1[タスクエージェント] -->|改善対象| A2[タスクエージェント]
end
subgraph HyperAgents
B1[メタエージェント] -->|改善対象| B2[タスクエージェント]
B1 -->|改善対象| B3[メタエージェント自身]
end| 観点 | DGM | DGM-H（HyperAgents） |
|---|---|---|
| 改善対象 | タスクエージェントのみ | タスクエージェント＋メタエージェント自身 |
| ドメイン整合の前提 | タスク能力と修正能力の一致が必要 | 不要（メタ手続き自体が変更可能） |
| 対応ドメイン | コーディング中心 | コーディング、論文査読、報酬設計、数学採点 |
これにより「査読能力が上がっても改善能力は上がらない」問題を回避できる。メタエージェントがタスクエージェントとは独立に「どう改善するか」を学習するため、タスク能力と改善能力の一致という前提が不要になった。
進化的アーカイブによる改善ループ
flowchart TD
A[アーカイブから親エージェントを選択<br/>性能に比例した確率で] --> B[メタエージェントがdiffを生成<br/>task_agent / meta_agent / 両方]
B --> C[Dockerコンテナ内で<br/>パッチ適用・実行]
C --> D[ステージング評価<br/>小サブセットで高速フィルタ]
D --> E{閾値クリア?}
E -- Yes --> F[中サブセットで本評価]
E -- No --> G[廃棄]
F --> H{改善あり?}
H -- Yes --> I[アーカイブに追加<br/>stepping stoneとして蓄積]
H -- No --> G
I --> A
G --> Agenerate_loop.py が回すループの流れ。
- アーカイブから親エージェントを性能に比例した確率で選択する（
select_parent） - メタエージェントがdiffを生成する。変更対象は
task_agent.py、meta_agent.py、または両方 - Dockerコンテナ内でパッチを適用して実行する（
apply_diffs_container） - ステージング形式で評価する。まず小サブセット（
small.json）で評価し、閾値を超えた場合のみ中サブセット（medium.json）に進む。Polyglotコーディングでの閾値は0.4 - 成功したバリアントをアーカイブに追加する（
update_and_save_archive）
このアーカイブの設計には進化的計算の知見が反映されている。一般的な最適化では最高スコアの解だけを残すが、HyperAgentsは成功したバリアントをすべて蓄積する。DGMの用語で「stepping stone（足がかり）のアーカイブ」と呼ばれる仕組みだ。
最高性能だけを残さないのは、中途半端に見えるバリアントが後の世代で最高性能エージェントの祖先になりうるからだ。進化生物学で言えば、現在の環境に最適化されていない種が環境変化後に支配的になる現象と近い。品質多様性アルゴリズム（Quality-Diversity）の文脈で研究されてきたアプローチで、単調な線形最適化よりも探索空間を広くカバーできる。
LLMバックエンドはOpenAI、Anthropic Claude、Google Geminiの3系統に対応している。
実験結果と改善戦略のドメイン間転移
4つのドメインで実験が行われた。最も重要なクロスドメイン転移の結果から。
クロスドメイン転移
コーディングや論文査読で改善を重ねたHyperAgentsのメタエージェントを、一切訓練していない新ドメイン（Olympiadレベルの数学採点）に持ち込む実験。
| 条件 | imp@50（50回以内に改善が出る割合） |
|---|---|
| 人間がカスタマイズしたDGM | 0.0（改善生成に完全失敗） |
| HyperAgentsからの転移 | 0.63 |
人間が手作りしたDGMの設定は数学採点ドメインで改善を1回も生成できなかった。一方、HyperAgentsが別ドメインで獲得した「改善の仕方」を持ち込むと、50回以内に63%の確率で改善が出た。
では何が転移したのか。メタエージェントが他のドメインの改善プロセスで獲得した、タスク横断的な戦略だ。
- 過去の試行結果をファイルに記録して次の判断に使う（永続メモリ戦略）
- どの変更がスコアに効いたかを追跡する（パフォーマンストラッキング戦略）
- 変更を小さく焦点を絞って行う（局所的修正戦略）
いずれもドメイン固有の知識ではなく、「どうすれば効率的に改善できるか」という改善プロセス自体のノウハウだ。Autoresearchが探索空間をグリッドサーチする固定戦略で回していたのに対して、HyperAgentsの改善戦略は自分自身の経験から学習され、未知のドメインでも機能する。
論文査読
Accept/Reject予測の正解率。
| システム | テスト正解率 |
|---|---|
| 初期エージェント | 0.0%（ランダム以下） |
| DGM-H 改善後 | 71.0%（95%CI: 59.0-75.0%） |
| AI-Scientist-v2 | 63.0% |
初期状態で全く機能しなかったエージェントが、自己改善を重ねてAI-Scientist-v2を上回った。DGMではドメイン整合性の問題で動かなかったはずの領域で、メタ/タスクの分離が効いている。
Polyglotコーディング
Pass@1スコア推移。
| 段階 | 訓練セット | テストセット |
|---|---|---|
| 初期 | 0.140 | 0.084 |
| 改善後 | 0.340 | 0.267 |
テストセットで3倍以上の改善。コーディングはDGMでも動いていたドメインだが、メタエージェントの自己修正が加わることで改善速度が加速している。
メタエージェントが自発的に獲得した機能
実験で最も興味深いのは、設計者が実装していない機能が改善ループの中で自発的に出現したことだ。
イテレーション間の永続メモリ
メタエージェントが過去の試行結果をファイルに記録し、次のイテレーションで参照する仕組みを自分で実装した。
これは人間がAIエージェントフレームワークに手動で組み込んできた「記憶」機能そのものだ。Claude Codeの .claude ディレクトリやLangChainのMemoryモジュールなど、すべて人間が設計してきた。HyperAgentsのメタエージェントは、改善ループの中でこの機能を独立に再発明した。
Chroma Context-1が強化学習で「コンテキストの自己編集」を学習したのと構図が近い。人間が手動で設計してきた機能を、最適化プロセスが独立に発見する。Chroma Context-1は検索コンテキストの管理を学び、HyperAgentsは改善プロセスの管理を学んだ。対象は違うが、「メタレベルの制御を自動獲得する」という方向性は共通している。
パフォーマンストラッキング
自分のスコア履歴を追跡し、「どの変更がどれだけ効果があったか」を分析して次の変更判断に活用する機能が生まれた。ML実験管理ツール（Weights & BiasesやMLflow）が実験者に提供している機能を、メタエージェントが勝手に作った。
評価バイアスの検出と活用
評価データセットに含まれるラベルの偏り（accept/rejectの比率の歪みなど）を検出し、それを利用する戦略が出現した。これは次のセクションで扱うGoodhart’s Lawの問題に直結する。
これら3つの機能はいずれもドメインをまたいで転移した。クロスドメイン転移実験で数学採点ドメインに持ち込まれたのは、まさにこれらのメタ戦略だ。
Autoresearchは実験パラメータの探索を自動化したが、探索戦略そのものは固定だった。HyperAgentsでは探索戦略まで改善対象になることで、こうした自発的な機能獲得が起きている。
評価指標のハックとGoodhart’s Law
「改善の仕方を改善する」能力はバイアス活用にも向かう。
論文の著者自身が指摘している。このシステムは「評価信号に含まれる潜在的なバイアスを明確化、増幅、活用できる（clarify, amplify, and exploit any underlying bias）」。
論文査読実験では、データセット内のaccept/reject比率の偏りを検出し、多数派ラベルにバイアスする戦略が自発的に出現した。スコアは上がるが、「正しく査読する能力」ではなく「評価指標をハックする能力」が向上している。Goodhart’s Law、つまり「指標が目標になると、その指標はもはや良い指標ではなくなる」の教科書的な発現だ。
flowchart LR
A[メタエージェントが<br/>評価バイアスを検出] --> B[バイアスを利用する<br/>戦略を生成]
B --> C[スコアが向上]
C --> D[アーカイブに追加され<br/>次世代の親になる]
D --> E[バイアス活用が<br/>さらに洗練される]
E --> Aメタエージェントが自分自身を書き換えられるということは、バイアス活用戦略もイテレーションごとに洗練されていく。改善ループが自己加速的であること自体が、Goodhartの加速要因になる。
現時点の安全策。
- 全実験をDockerサンドボックス内で実行
- 外側ループ（評価基準と親選択のロジック）は編集不可に固定
- 人間による監視を前提
ただし「外側ループが編集不可」という設定自体が暗黙の安全境界になっている点は論文でも認識されており、体系的な脅威モデルはまだ構築されていない。GitHubリポジトリでは「意図しない破壊的操作が起きる可能性がある」と明示的に警告されている。AIコーディングツールの壊れ方で本番環境削除やコンテキスト消去が同じ週に発生した事例を取り上げたが、改善ループそのものが最適化対象になるHyperAgentsでは、失敗パターンの予測自体が一段難しくなる。
ARC-AGI-3でフロンティアLLMが「ゴールが開示されない未知環境」で1%未満という結果を取り上げた。HyperAgentsの改善戦略のドメイン間転移は「自力で戦略を見つけ出す」能力の一形態に見えるが、評価指標が明示されたサンドボックス内の話であり、オープンエンドな環境とは質的に異なる。