AIは学習アルゴリズムを改良できるか。AI4AI-Benchで見えた0.250の壁
AIにコードを書かせて、AIそのものを賢くする。言葉にすると、もうすぐ自己改善のループが回り始めそうです。
ところが、実際にやらせてみると話はもっと地味で、もっと難しいものでした。AI4AI-Benchでは、6種類のAIシステムを29構成で動かし、10の研究プロジェクトを改善させました。合計290回の評価で、平均スコアは0.166。元の研究コードをそのまま使った基準が0.1、タスク上の最適値が1.0です。最強のシステムでも平均0.250にとどまりました。
さらに290回のうち124回は0.1を下回り、AIが書き換えた結果、元の学習法より悪くなっています。
この数字から見えるのは、AIがコードを変更できることと、学習アルゴリズムを改善できることの間にある大きな距離です。
「AIを改善する」を三つの層に分ける
AIシステムを改善する仕事は、大きく三つに分けられます。
一つ目はシステム層です。GPUカーネルを速くする、通信を詰める、メモリ使用量を下げるといった改善です。
二つ目はデータ層です。学習データを集める、不要な例を除く、合成データを作るといった改善です。
三つ目がアルゴリズム層です。目的関数、更新則、正則化、教師信号、データの使い方そのものを変えます。
AI4AI-Benchが狙うのは三つ目だけです。処理を速くした、学習時間を延ばした、良いデータを追加した、という成果ではなく、「モデルがどう学ぶか」を変えられたかを測ります。
ここが重要です。再帰的自己改善が積み上がるには、次の学習にも引き継げる変更が必要です。計算資源を一度増やしただけでは、次の世代へ複利のように効きません。一方、より良い目的関数や更新則は、その後の学習にも使えます。
10の研究コードを、同じ手順でやり直す
ベンチマークには10の凍結済み研究リポジトリが入っています。教師あり微調整、複数ターンのエージェントRL、オンポリシー蒸留、報酬モデル、選好最適化、拡散モデルのRL、機械的忘却、グラフ拡散、重み平均、枝刈りです。
タスクごとに使うモデルも評価指標も違います。コード生成ならLiveCodeBench、数理推論ならAIME、指示追従ならIFEval、画像生成なら美的スコアという具合です。
そこで研究チームは、異なる指標を0から1の共通軸に写しました。
- 0は有用な学習ができていない状態
- 0.1は元の研究リポジトリが提供する手法
- 1.0はそのタスクで定義した最適値
0.1を超えれば元の手法を上回り、1.0へ近づくほど残された差を埋めたことになります。実行可能な成果を返せなければ0です。
探索と本番評価を切り離す
評価手順の工夫は、短い探索と長い確認を分けたことです。
エージェントはNVIDIA B300を1基使い、4時間だけリポジトリを読み、コードを書き換え、安価な代理指標で短い実験を繰り返します。4時間が終わるとプロセスは止まり、次へ渡せるのはソースコードだけです。途中で作った重み、キャッシュ、メモは持ち越せません。
提出コードは新しいコンテナへ移され、初期状態から最大12時間実行されます。最終評価器は探索中のエージェントから見えません。元のコードも同じ条件で評価されます。
この分離には意味があります。探索中にたまたま良いチェックポイントを見つけ、その瞬間だけを成果として残すことを防げるからです。再実行しても改善が残るソースコードだけが評価対象になります。
ただし、完全な意味でデータが分離されているわけではありません。一部タスクでは、安価な代理指標と最終評価が同じコーパスを元にしています。保証されるのは、最終指標へのアクセスと評価タイミングの分離です。この違いは、結果を読むうえで外せません。
多くのAIは「学び方」まで届かなかった
研究チームは、提出された変更をコードから分類しました。
変更を分類できた263件のうち、141件、54%は運用側だけを触っていました。学習時間、保存頻度、学習率、バッチサイズ、モデル容量などです。大切な改善ではありますが、元の学習アルゴリズムは変わっていません。
残る122件、46%は目的関数、教師信号、更新則、データの使い方に踏み込みました。
差はスコアにも表れます。
- 運用側だけを変えた提出の平均は0.126
- 学習側まで変えた提出の平均は0.226
学習側へ踏み込んだ提出のほうが、平均では約1.8倍高いスコアです。それでも、過半数の提出はそこへ到達しませんでした。
AIに「研究コードを改善して」と頼むと、まず触りやすい設定を変える。これは人間の開発でもよくある動きです。設定変更は試しやすく、効果も早く見えます。しかし、訓練曲線や勾配、エントロピー、参照モデルとの差を読み、壊れている仕組みを特定し、その仕組み自体を直す仕事は一段難しくなります。
長く考えさせれば解決するのか
reasoning effortを上げると、学習側へ踏み込む割合は8%から64%へ増えました。平均スコアも0.094から0.196へ上がっています。
ただし、研究チームの公式ページが強調するように、各システムの成績は設定を上げるほど滑らかに良くなったわけではありません。最も高い設定が常に最良でもありませんでした。
費用との関係も単純ではありません。4時間の探索に使ったAPI費用は合計5,334米ドル。構成単位では4米ドルから626米ドルまで開きました。高価な構成がそのまま最良の構成になったわけではありません。
ここから「考える量は無意味」と結論づけるのも早すぎます。高いreasoning effortは、目的関数や更新則へ踏み込む勇気を増やした可能性があります。ただし、変更案の質、短い実験の設計、失敗した仮説からの学びまで自動で保証するものではありません。
実務では三つのゲートに分ける
AI4AI-Benchの設計は、大規模な学習研究だけでなく、日常のエージェント運用にも応用できます。
1. 何を変えたかを分類する
成果を「改善した」の一言でまとめず、変更層を分けます。
- 実行時間や並列度などの運用変更
- 学習率やバッチサイズなどの設定変更
- 目的関数や評価規則などの仕組み変更
- データの追加、除外、再構成
同じスコア上昇でも、次の案件へ再利用できる範囲が違います。
2. 探索用の指標と採否用の指標を分ける
探索中に何度も見た指標だけで採用を決めると、その指標へ合わせ込んだ案が勝ちやすくなります。探索では速い代理指標を使い、採否は別の固定評価で決めます。
記事生成なら、執筆中の文字数や見出し数と、公開前の事実監査を分ける。コーディングなら、手元の単体テストと、クリーン環境での統合テストを分ける。小さな形でも同じ考え方を使えます。
3. 成果物だけをクリーン環境へ渡す
探索環境のキャッシュや手動修正に頼らず、提出物から最初から再現します。コードならパッチ、記事なら原稿と参照元、分析ならスクリプトと入力条件です。
AIの作業時間を増やす前に、この三つを整えたほうが、何が本当に効いたかを判断しやすくなります。
公開コードはあるが、再現は軽くない
AI4AI-BenchのコードはApache-2.0で公開されています。10タスクの定義、資産準備、オーケストレーション、評価器、結果の受領方法が含まれています。公式ページからは290件の軌跡も確認できます。
一方、実行条件はLinux amd64、Python 3.10以上、Docker、NVIDIA Container Toolkit、NVIDIA GPUです。公式実行はB300を1基使っています。モデルやデータ、画像資産にはそれぞれ上流の利用条件があります。
さらに、公開版の最終評価はセルフホスト型です。現時点では、第三者が提出して同じ秘密評価を受けるブラインドサービスはありません。ローカルで評価器を動かせることと、公式結果と完全に同じ条件で比較できることは別です。
AICompanyでも、B300環境と全資産を使った290セルの再現実験は行っていません。この記事は、論文、公開リポジトリ、公式ページ、公開された評価設計を照合してまとめています。
0.250は失敗ではなく、測れる出発点
最強システムの平均0.250は、再帰的自己改善が目前だと示す数字ではありません。むしろ、現在のエージェントが研究コードを読み、仮説を立て、学習の仕組みを変え、長い再実行で改善を残すまでには距離があると示しています。
同時に、悲観だけで終わる結果でもありません。学習側へ踏み込んだ提出は、運用側だけの提出より明確に高い平均を出しました。どこへ手を伸ばせばよいかは見えています。
次に必要なのは、単に長く考えるモデルではなく、訓練の挙動から壊れた仕組みを診断し、短い試行で仮説を切り分け、クリーンな再実行に耐える変更を残せるエージェントです。
AIが自分を改善できるかという大きな問いに対し、AI4AI-Benchは少し地味な答えを返しました。まずは設定をいじることと、学び方を変えることを区別しよう。そこからです。