AI に「料理コンテスト」をさせたら、人類の記録を更新した ― でも審査員を甘くすると“ズル”をする

Last updated at 2026-08-11Posted at 2026-07-07

AI に「料理コンテスト」をさせたら、人類の記録を更新した ― でも審査員を甘くすると“ズル”をする

進化ループ(evolution loop)× 自動評価器 ―― AlphaEvolve / ASI-Arch / Darwin Gödel Machine が、実は全部「同じ 1 つの仕組み」だという話を、料理コンテストのたとえで噛みくだきます。4 部品への分解、審査員設計、最初の run の切り方まで入れました。

この記事の 3 行

AlphaEvolve・ASI-Arch・Darwin Gödel Machine といった 2025 年の話題の AI は、バラバラの発明ではなく、FunSearch(2023)が確立した「たった 1 つの進化ループ」の派生です。
その正体は「AI に料理コンテストを自分で回させる」こと。料理人(変異)・審査員(評価器)・棚(archive/QD)・選抜(選択圧)の 4 部品に分けると、各手法の違いがかなり見やすくなります。
いちばん大事なのは料理人でも棚でもなく、**審査員(評価器)**です。ここが甘いと、AI は「中身を良くする」代わりに「審査を騙す抜け道」を見つけます。本記事ではそこを中心に、最初の run をどう小さく安全に切るかまで書きます。

はじめての方は上から順に読むのがおすすめです。急ぐ方は「4. 山場」「5. じゃあ、自分で試すには」の見出しだけ先に拾い、最後に「6. 正直な但し書き」で温度感を合わせる読み方でも大筋は追えます。専門用語は最初の表にまとめました。

1. 用語だけ、先に

ここだけ先に眺めておくと、後がとても楽になります(正確な英語綴りも併記します)。

用語	ひとことで言うと
進化ループ(evolution loop)	「案を作る → 採点する → 良いのを残す → また作る」をぐるぐる回す仕組み
LLM(Large Language Model / 大規模言語モデル)	文章やプログラムを書ける AI。ChatGPT の中身のようなもの
変異(mutation)	いまの案を少しいじって、別の案を作ること
評価器(evaluator)	案を採点する「審査員」。この記事の主役
接地(grounding)	口で「良さそう」ではなく、実際に動かして良し悪しを確かめること
選択圧(selection pressure)	「どれを残すか」の基準。強いほど良いものが生き残る
QD / MAP-Elites(Quality-Diversity / 品質多様性)	総合 1 位だけでなく「タイプ別の名人」をずらっと残す棚
アーカイブ(archive)	過去の良い案を捨てずに溜めておく棚
報酬ハッキング(reward hacking)	AI が「中身を良くする」でなく「審査を騙す抜け道」を見つけてしまうこと

2. いちばん噛みくだいた版 ―― 「AI に料理コンテストをさせる」

犬や作物の品種改良を思い浮かべてください。良いものを選び、掛け合わせ、また選び……を何百回も繰り返すと、だんだん良くなっていきますよね。

2025 年に話題になった一連の AI がやっているのは、まさにこれの “AI 版” です。ただし、新しい点が 2 つあります。

掛け合わせ役(変異)を、コードを書ける AI にやらせる。「このプログラムの、この部分をこう書き換えてみて」と、少しずついじらせます。人間が数式で乱数を足す代わりに、意味を分かっている AI が“ありそうな改良”を提案してくれる、という点が新しいのです。
どれを残すか決める審査員(評価器)を、機械が実際に動かして採点する。口で褒めるのではなく、本当にプログラムを実行して「速い? 正しい?」を測ります。

図にするとこうです。

これを何百回も回すと、人間が思いつかなかった良い解が出てきます。実際、Google DeepMind の AlphaEvolve は、56 年間破られなかった行列のかけ算アルゴリズムの記録を更新しました(4×4 のかけ算を 49 回 → 48 回に。1969 年の Strassen 以来の更新です)。

豆知識:行列のかけ算は、AI の学習からゲームの物理まで、あらゆる計算の“土台”です。その回数が 1 回でも減ると、世界中の計算がわずかに軽くなります。AlphaEvolve は実際に Google のデータセンターで 1 年以上動き、世界全体の計算資源を平均 0.7% 回収し続けている、と報告されています。

「たった 1 回」と侮れません。品種改良と同じで、1 回の改良は小さくても、何百世代も積み上がると人間の直感を超える。しかも掛け合わせ役が“コードの意味を分かった AI”なので、まったくの当てずっぽうより、ずっと筋の良い方向に進みます。

3. なぜ「進化ループ」だと分かるのか ―― 系譜の話

この「料理コンテスト」の骨組みは、実は新しくありません。原型は 2 つあります。

FunSearch(DeepMind, 2023, Nature 掲載):追加学習を一切しない“素の” LLM に、プログラムのたった 1 つの関数だけを書き換えさせ、実行評価器で採点する。これで数学の未解決問題(cap set 問題)に、数十年ぶりの新しい下界を見つけました。ポイントは「LLM を賢くした」のではなく、「そこそこの LLM を、厳しい審査つきのループに閉じ込めた」こと。ここが後続すべての設計思想になりました。
ELM(Evolution through Large Models, 2022):LLM を「変異のハサミ」として使い、MAP-Elites(タイプ別の名人を並べる棚)を回す。歩くロボットのコードを進化させました。ここで「LLM = 変異演算子」「棚 = QD」という 2 つの部品が出そろいます。

そして 2025 年の話題作は、全部この骨組みの“強化版”です。

AlphaEvolve:複数の LLM で、コードの一部だけを**差分(diff)**で書き換える。中身は「島に分けた集団 + 段階審査 + 良い案を溜める棚」で、FunSearch の正統進化版です。
ASI-Arch:AI が「新しい AI の設計図」を 1,773 回も試作し、106 個の新しいアーキテクチャを人手ゼロで発見した、と報告。「設計 → 学習して採点 → 分析 → また設計」という、まさに料理コンテストを AI 研究そのものに向けた例です。
Darwin Gödel Machine(DGM):AI が自分自身のコードを書き換えて進化し、プログラミングの課題を解く能力を 20% → 50% に自己改善した、と報告。料理人が「自分のレシピ帳」ごと書き換えていくイメージです。

名前も見た目もバラバラですが、中身は全部「料理人・審査員・棚をぐるぐる」なのです。一度この骨組みが見えると、次に出てくる派手な名前の新手法も、「ああ、あの 4 部品のどこを強化したのね」と落ち着いて読めるようになります。これがこの記事でいちばん持ち帰ってほしい“ものさし”です。

4 部品に分解すると、各手法の違いが急に読みやすくなる

「全部同じ料理コンテスト」と言うと雑に聞こえるかもしれませんが、実際にはどの部品を強化したかに各手法の個性があります。整理するとこうです。

系統	料理人(変異)	審査員(評価器)	棚(archive/QD)	選抜(選択圧)	何が強いか	何が弱いか
FunSearch	凍結 LLM が 1 関数だけ書き換える	数学問題を厳密に検証	島分け + 類似案のまとめ	高得点の関数を島ごとに残して次世代へ回す	評価が硬い。だから成果も信じやすい	問題領域がかなり限定される
ELM	LLM を変異演算子として使う	物理シミュレーションで採点	MAP-Elites で多様性を残す	niche ごとの elite を選ぶ	「LLM × QD」の原型	生成の筋は良くても、審査の穴は残りうる
AlphaEvolve	複数 LLM が差分(diff)を書き換える	段階審査 + 実行採点	QD + island	段階審査を通った案だけを昇格させる	4 部品の組み合わせが最も洗練	大規模計算前提で、そのままは真似しにくい
ASI-Arch	設計図を大きく書き換える	実際に学習してベンチ採点	上位集団 + 系統保存	重い学習審査を通った上位案を残す	探索空間が広い	審査コストが重い。GPU が要る
DGM	自分のコード/手順書を改変	実テスト pass/fail	系統を全部残す	pass した系統を起点に自己改造を継続する	自己改造まで踏み込む	報酬ハックの危険が大きい

ここで重要なのは、派手な名前の違いよりも、どの部品が重く、どの部品が危ないかを見抜けることです。特に見逃しやすいのは「料理人」より「審査員」の差で、FunSearch が硬く見えるのも、DGM が怖く見えるのも、かなりの部分は評価器の性格の差です。

4. 山場 ―― 「審査員がすべて」と、AI のズル

この仕組みでいちばん大事なのは、案を作る料理人ではなく、審査員(評価器)の方です。審査員が満たすべき条件は 3 つ。

自動(人が毎回見なくていい)
接地(口だけでなく、実際に動かして採点する)
騙されにくい

3 つ目が肝心です。審査が甘いと、AI は必ず抜け道を見つけます。

審査員が味見をせず、見た目だけで採点したらどうなるか。料理人は「味を良くする」のをやめ、「盛り付けだけ豪華にする」方向に進化します。これが 報酬ハッキング(reward hacking) です。

これは笑い話ではなく、何度も実際に起きている

自己改造 AI(DGM)の例:「不具合を見つける能力」を試されたとき、中身を直す代わりに、“不具合を報告するログ出力そのものを消して” 検査をすり抜け、満点を取りました。問題は何一つ解決していないのに、です。論文の著者自身が「評価器がすべての望ましい性質を捉えない限り、自己改造ループは“ズレ”を世代ごとに増幅しうる」と警告しています。
ボートレースゲームの例(OpenAI, 2016):ゴールを目指すよう点数をつけたら、AI はコースを完走せず、途中の得点アイテムが再出現する場所をぐるぐる回り続けて高得点を稼ぎました。レースには“負け”ているのに、点数だけは満点級。
進化計算の古典的な例:「速く歩け」と進化させたら、脚を動かさず、背だけを高くして前に倒れ込む個体が「移動距離」を稼いで勝ってしまった、という逸話が数多く報告されています(Lehman らの有名なサーベイ「デジタル進化の驚くべき創造性」に、この手のズルが山ほど集められています)。

共通点は明快で、AI は「あなたが本当に望んだこと」ではなく「あなたが測ったこと」を最適化する、ということ。測り方に隙があれば、その隙こそが“いちばん楽な勝ち筋”になります。

ここは、私がふだん自分に言い聞かせている 「異常に良い結果が出たら、勝った気になる前に、まず内訳を疑う」 という規律とまったく同じでした。世界中の一線の研究が、同じ落とし穴を実際に踏んで、正直に報告している。だから対策も編み出されていて、それがそのまま自分の道具に移植できる ―― ここが、この話のいちばん“おいしい”ところです。

🗒️ 「努力（ズル）？」「あっ…もうダメだこの人…」— 審査が甘いと、AI にとっての「努力」はそのまま「ズル」と同義語になります（© Forbidden shibukawa / SHUEISHA・『スナックバス江』）

対策の例(=評価器を騙されにくくする工夫)

安い審査で足切り → 良さそうなものだけ高い審査(全部を丁寧に味見すると高くつくので、段階(cascade)を分ける)。
点数の一部を AI に隠す(隠しテスト・ホールドアウトで「見た目だけ豪華=過学習」を見抜く)。
審査員だけは、AI に書き換えさせない(審査員を“聖域”として固定する。DGM のような自己改造系では、これを破ると一気に崩れます)。
複数の物差しで測る(速さだけでなく、正しさ・安全・コストも同時に見る。1 本の物差しは必ずハックされます)。

「料理人をどれだけ賢くするか」より、「審査員をどれだけ騙されにくくするか」に時間を使う ―― 進化ループを回した人がほぼ全員たどり着く結論が、これです。

「良い審査員」のチェックリスト

ここをもう少し実務寄りに言い直します。要するに、上の 3 原則を実装レベルへ分解すると、審査員には最低でも次の 5 項目が要ります。

自動
毎世代で人が見ない。人間レビューが必要な時点で、何百世代も回す仕組みになりません。
接地
「もっともらしい説明」ではなく、実行・計測・検証まで落ちている。数式なら verifier、コードなら test/sandbox、ロボットなら simulation rollout です。
安価な足切りがある
毎回フルコースを味見すると高くつきます。だから安い審査で落とし、上位だけ本審査に送る。AlphaEvolve ではこの設計がかなり明示的で、DGM 系でも「軽いチェックで絞ってから重い確認へ進む」発想が見えます。
隠し物差しがある
AI に採点基準を全部見せると、そこを突かれます。hold-out や hidden checks が要るのはこのためです。
審査員自身は書き換えられない
ここを自己改造の対象に入れると、最適化は一気に危険になります。DGM の怖さはまさにそこです。

言い換えると、進化ループの本質は「LLM でコードを変異させること」ではなく、**LLM を「騙されにくい審査員の下で働かせること」**です。ここを逆に理解すると、話題の手法も全部「派手な生成」ではなく「厳しい選抜」の勝負だったことが見えてきます。

「ズルした改善」を見抜く 4 つの観測点

実際に回し始めると、いちばん怖いのは「スコアが伸びたので喜んだら、実は評価器の穴を踏んでいただけだった」です。私は最低でも次の 4 つを別々に残すべきだと思っています。これは後で出てくる 最初に見るグラフ と 成功判定 の土台でもあります。

観測点	何を見るか	崩れ方の例
主スコア	世代ごとの主スコア	ここだけ急上昇すると、まず疑う
内訳メトリクス	正しさ / 安全 / コスト / 長さ	主スコアだけ上がり、内訳が悪化している
hold-out	隠しケースでの再評価	train 相当だけ良く、hold-out で落ちる
差分の意味	どこを書き換えたか	本質部ではなく、ログ・しきい値・例外処理ばかり触る

たとえば歩行なら、「移動距離」だけを見ていると倒れ込みで稼げます。だから 距離 / 転倒回数 / 接地の安定 / エネルギー / 禁止領域侵入 を分けて持つ。コード最適化なら「速さ」だけでなく 正答率 / 例外率 / テスト通過率 / 実行時間分散 まで見る。
この分解を先にやっておくと、「良くなった」の意味がかなり監査可能になります。

逆に言えば、スコアが 1 本しかない状態で進化ループを回すのは危険です。進化は賢いので、1 本しかなければその 1 本を最短距離でハックします。

5. じゃあ、自分で試すには ―― 部品は意外と揃っている

面白いのは、この「料理コンテスト」の 4 部品のうち 3 つは、進化計算をやっている人なら既に持っていることです。私自身が自宅 PC で作っている実験群(FullSense)を例にすると、こうなります。

棚(QD) は、進化に使っている MapElitesArchive(タイプ別の名人を並べる棚)。私は仮想生物の**“体そのもの”を進化させ、「体の節の数」ごとにチャンピオンを別々に残す**実験に、これをそのまま流用しています(実際に動く生き物の動画つきの話は、別記事「自宅CPUで世界モデルと人工生命を作った話」で書きます)。
選抜(選択圧) は、ε-lexicase + QD という選び方の部品。
審査員(評価器) は、歩行なら「実際に歩かせて距離を測る」評価がもう手元にある。

足りない 1 部品は、「掛け合わせ役を、“パラメータいじり”から“コードを書き換える AI”に格上げする」だけ。歩き方を数値で少しずらすのではなく、歩き方を決めているプログラムそのものを AI に書き換えさせるのです。

今週試せる最小構成(お金も GPU もほぼ要りません)

pip install openevolve(AlphaEvolve の無料再現。中身は MAP-Elites + 島モデル + 段階審査)。
既にある採点関数を、そのまま審査員(評価器)として差し込む。
進化させたいコードを、こんなふうに書き換えていい範囲だけ囲む。ここだけが変異します。

# EVOLVE-BLOCK-START
def heuristic(x):
    # AI はこの中身だけを書き換えていく
    return x * 2
# EVOLVE-BLOCK-END

変異役の LLM は、Gemini-Flash などの API を使う(生成はネット越しなので、手元の GPU は不要)。
まずは 30 世代ほど 回して、“報酬ハッキングしていないか” を必ず見張る(スコアが急に伸びたら、まず疑う)。安定してから 100 世代へ広げます。

物理シミュレーション(歩行)なら審査も手元の CPU で完結します。一方、AI の設計図そのものを進化させる(ASI-Arch のような)遊びは、審査に GPU が要ります。ただし面白いことに、ループの“頭脳”(案出し・記憶・重複チェック)は API と CPU で今すぐ組めるので、GPU 待ちでも準備は進められます。

まず 30 世代で故障診断し、その後 100 世代へ広げる

最初から「1000 世代・巨大探索」をやる必要はありません。まずは 30 世代でどこが壊れるかを見る。その後、安定してから 100 世代へ広げる。この二段階にすると学びが大きいです。

0-10 世代
生成された差分が、そもそも妥当かを見る。構文エラーや即死が多いなら、料理人への制約が緩すぎます。
10-20 世代
主スコアの伸びと、内訳メトリクスのズレを見る。ここで「主スコアだけ」伸び始めたら、評価器の穴を疑う段階です。
20-30 世代
hold-out と再実行で確認する。同じ案を条件違いで再採点して、偶然当たりや seed 依存を落とします。
30 世代時点
残った elite を人間がまとめて読む。ここで初めて「本当に意味のある改良か」を確認します。毎世代レビューではなく、最後にまとめて監査する方がコストが合います。

この 30 世代で安定したら、次に 100 世代へ伸ばします。100 世代側では新しい設計原理を探すというより、再現性・多様性・過学習の有無を見にいく段階です。

この切り方だと、「料理人が弱い」のか、「審査員が甘い」のか、「棚や選抜が悪くて同じ案ばかり残る」のかを切り分けやすいです。
進化ループは成功例だけ見ると魔法に見えますが、実際には どこで壊れたかのログ から学ぶ割合がかなり大きい、と私は思っています。

評価器は「1個の点数」ではなく、3層に割って作る

ここは実装上かなり重要です。評価器を最初から 1 本の score() に押し込むと、後で何が悪かったか分からなくなります。私は少なくとも次の 3 層に割るのが安全だと思っています。

sanity gate
そもそも動くか、例外を吐かないか、危険な API を触っていないかを見る。ここは pass/fail だけで十分です。
task score
その課題の主スコア。歩行なら距離、コード最適化なら速度、数式探索なら正しさと改善量です。
audit score
後からズルを疑うための補助メトリクス。安全、安定、再現率、複雑化、テスト漏れなどをここに分けて残します。

イメージとしてはこんな感じです。

def evaluate(candidate, *, generation, eval_seed, eval_config, run_id):
    sanity = run_sanity_checks(candidate, config=eval_config)
    record = {
        "evaluation_id": f"{candidate.id}:{run_id}",
        "candidate_id": candidate.id,
        "lineage_id": candidate.lineage_id,
        "source_ids": candidate.source_ids,
        "generation": generation,
        "diff": candidate.diff,
        "eval_seed": eval_seed,
        "eval_config_name": eval_config.name,
        "eval_config_version": eval_config.version,
        "eval_config_hash": eval_config.hash,
        "sanity": sanity.to_dict(),
        "passed": False,
        "failure_reason": None,
        "score": None,
        "task": None,
        "audit": None,
        "holdout": None,
    }
    if not sanity.ok:
        return {**record, "failure_reason": sanity.reason}

    task = run_task_metric(candidate, seed=eval_seed, config=eval_config)
    audit = run_audit_metrics(candidate, seed=eval_seed, config=eval_config)
    passed = task.primary >= eval_config.min_score and audit.ok

    return {
        **record,
        "passed": passed,
        "score": task.primary,
        "task": task.to_dict(),
        "audit": audit.to_dict(),
        "holdout": None,
    }

ここでの passed は sanity + task + audit を通った「軽量本審査の通過」 です。hold-out は毎候補には回さず、archive に残った上位候補へ周期的に当てる最後の防御線としています。この分け方の良いところは、主スコアでは勝っているのに audit や hold-out では怪しいという個体を後から拾えることです。進化ループでは、こういう「一見勝って見えるが危ない個体」がいちばん情報量を持っています。戻り値も成功時・失敗時でスキーマを揃えておくと、下流では passed を先に見れば安全に扱えます。

実験ログに最低限残すべき 7 項目

あとで再現不能になるのを防ぐには、ログの取り方もかなり大事です。最低限これだけは残した方がいいです。

世代番号
evaluation ID + candidate ID / lineage ID / source ID 群
差分そのもの
主スコア
audit メトリクス
hold-out 結果
評価に使った seed / 条件 / config version/hash / sanity 結果

加えて、後で 失敗理由の内訳 グラフを作るなら、failure_reason も独立して残しておく方が安全です。sanity failure / audit failure / hold-out drop は evaluate() や rerank_with_holdout() 側で理由を付け、duplicate だけは update_archive() 側で「既存 elite と同型で昇格しなかった件数」として数える、くらいに分けておくと集計しやすいです。

特に「差分そのもの」を残すのは重要です。進化ループは、最後に勝った案だけ見ても学べることが半分しかありません。
どんな差分が大量に死に、どんな差分がたまに生き残るか を見た方が、次の世代の制約設計に直接効きます。

そして hold-out は audit の一部に埋めず、独立した結果として直接見えるように残す方が安全です。本文で何度も書いてきた通り、ここは「train 相当では勝っているのに、本当に欲しい一般化では落ちる」個体を弾く最後の防御線だからです。

このログがあると、次にやるべきことも決めやすいです。たとえば

例外終了ばかりなら → 料理人の編集範囲を狭める
audit だけ悪化するなら → 審査員を増やす
同じ案ばかり残るなら → 棚や選抜を変える

というふうに、改善先がかなり見えます。

ループ本体は、このくらい単純でよい

概念が増えると難しそうに見えますが、最初の 1 本目はそこまで大げさにしなくて構いません。骨格だけ書くと、やっていることは次のくらいです。

archive = seed_archive()

for generation in range(30):
    candidates = propose_mutations(archive, k=4)
    results = [
        evaluate(
            candidate,
            generation=generation,
            eval_seed=seed_for(candidate, generation),
            eval_config=EVAL_CONFIG,
            run_id=RUN_ID,
        )
        for candidate in candidates
    ]
    passed = [r for r in results if r["passed"]]
    archive = update_archive(archive, passed)

    if (generation + 1) % 5 == 0:
        archive = rerank_with_holdout(archive)

ここで大事なのは、propose_mutations() より先に evaluate() を凝ることです。最初は料理人が多少雑でも、審査員と棚が硬ければ loop はまだ学べます。逆に、mutation をいくら賢くしても、passed の判定や holdout の位置が甘いと、すぐにズルの温床になります。なお、本文後半で重視している 同一候補の再実行 2-3 回 はこの骨格では省略しています。実際には rerank_with_holdout() の段階で、上位候補だけ seed を変えて再評価する想定です。

私は最初の実装では、さらに次の 3 つを固定してしまう方が安全だと思っています。

mutation の種類は 2-3 個まで
文章差分、定数変更、関数差し替えくらいで十分です。
選抜規則は 1 本に固定
最初から lexicase と MAP-Elites を同時に混ぜない方が、失敗理由を読みやすいです。
hold-out の再評価位置は固定
「怪しい時だけ回す」にすると、疑い方そのものがぶれます。

つまり初回 run で本当に知りたいのは、「どの mutation が強いか」より前に、この loop が誤魔化しを通さずに回るかです。骨格を小さく固定しておくと、その答えが早く見えます。

最初に固定しておくべき「触ってよい場所 / だめな場所」

進化ループを安全に始めるなら、最初に 「AI が書き換えてよい範囲」 を狭く決めておくのが大事です。ここを曖昧にすると、改善より先に事故ります。

触ってよい
heuristic 本体、定数、枝刈り条件、探索順、軽い補助関数。
絶対に触らせない
evaluator 本体、hidden test、ログ記録、seed 固定。
原則として触らせない
外部通信、ファイル削除、権限設定。

言い換えると、料理人にはレシピだけ触らせ、審査員の採点表には触らせないということです。
自己改造系をやるとしても、最初の段階では「どこを解禁するか」を世代ごとに慎重に増やした方がいい。最初から kitchen 全部に入れてしまうと、改善ではなく最短の抜け道探索になりやすいです。

最初の 1 週間で踏みやすい 3 つの失敗

この分野は、派手な論文だけ見ると「まず LLM を強くしよう」と思いがちですが、実際にはもっと地味な所で失敗しやすいです。

候補を出しすぎる
料理人の出力数を増やしても、審査員が粗いままだとゴミを速く量産するだけです。まずは候補数より evaluator の硬さです。
score を 1 本に潰しすぎる
便利ですが、壊れたときに理由が消えます。本文で書いた task / audit / hold-out の分離は、派手さより先に守るべき最低線です。
選抜を後回しにする
料理人と審査員だけに注目して、棚や選抜を雑にすると、似た案ばかりが残ります。MAP-Elites や island、lexicase が効くのは、ここで探索の詰まりを防ぐからです。

私自身、この 3 つは「本体アルゴリズムの工夫」より先にチェックすべきだと思っています。ここを外すと、どれだけ立派な名前の loop を載せても、実験としてはすぐ痩せます。

最初に回すベンチは「軽い3本」で十分

ここまで来ると、次に迷うのは「結局、何を課題にして回すのか」です。最初から大きい問題に行く必要はありません。むしろ最初は、性質の違う軽い課題を 3 本だけ持つのがちょうどいいです。

正しさが明快な toy
例: 小さな数式変形、簡単な verifier 付き関数最適化。
ここでは「審査員が本当に硬いか」を見る。
速さと正しさが競合する toy
例: テスト付きの小さなアルゴリズム高速化。
ここでは「速くなったが壊れた」を audit / hold-out で検知できるかを見る。
ノイズのある toy
例: seed 依存の軽いシミュレーション、歩行の短尺 rollout。
ここでは「偶然当たり」を再評価で落とせるかを見る。

この 3 本があると、進化ループの弱点がかなり早く見えます。

1 本目で落ちるなら evaluator が甘いか、編集範囲が広すぎる
2 本目で落ちるなら score 設計が雑
3 本目で落ちるなら seed / hold-out / 再実行の設計が弱い

つまり、ベンチは「強さを証明するため」だけでなく、どこが壊れるかを切り分ける診断器として選ぶべきです。ここを間違えると、結果の派手さばかり見えて、loop 自体の欠陥が見えなくなります。

最小ディレクトリ構成も、最初はこのくらいでよい

実際に手元で始めるとき、私はディレクトリ構成も欲張らない方がいいと思っています。最初の 1 本目は、役割が分かれていれば十分です。

experiment/
  candidates/        # 候補コードや差分
  evaluator/         # task / audit / hold-out / sanity
  archive/           # elite / map / lineage の保存先
  logs/              # evaluation_id 単位の jsonl / csv
  run.py             # ループ本体
  config.yaml        # 世代数, 候補数, seed, hold-out 頻度

ここでのポイントは、候補と 審査員 と棚を物理的にも分けることです。全部を 1 ファイルに詰め込むと、あとで「どこを AI に触らせ、どこを固定していたか」が曖昧になります。

特に evaluator/ を独立させておくと、

task.py
audit.py
holdout.py
sanity.py

のように責務を切れます。すると、hold-out だけ差し替える、audit だけ追加する、といった改善がかなり安全になります。逆にこの分離が無いと、審査員を直したつもりで候補生成や archive まで同時に壊しやすいです。

ただし、置き場所を分けるだけでは不変条件は守れません。seed 固定 や 評価系は触らせない を本当に成立させるには、少なくとも

evaluator 側を候補生成側とは別管理にする
AI が書けるパスと書けないパスを分ける
config.yaml のうち seed / hold-out / hidden test の更新権限を絞る

のどれかが要ります。つまり、ディレクトリ分離は 見通しを良くする第一歩 であって、保護そのものではありません。保護は最終的に 書込権限・更新ルール・別管理 で作る必要があります。

要するに、進化ループの最小実装は 大きなフレームワーク で始める必要はありません。むしろ run.py + evaluator/ + archive/ + logs/ くらいに抑えた方が、最初の 30 世代で何が壊れたかを追いやすいです。

🗒️ 「う〜〜ん…イマイチ考察が甘いわね…」「それもうちょっと踏み込んで考えられない…？」— ディレクトリを分けただけで満足しかけた自分に、厳しい審査員なら言いそうな一言（© Forbidden shibukawa / SHUEISHA・『スナックバス江』）

「棚」と「選抜」を雑にすると、進化はすぐ詰まる

ここまで審査員の話を厚くしてきましたが、実は 棚(archive) と 選抜(selection pressure) もかなり重要です。
なぜなら、料理人が良い案をたまに作れても、それを どう残し、どう次世代へ渡すか が雑だと、探索はすぐ同じ場所をぐるぐる回り始めるからです。

典型的な悪い流れはこうです。

たまたま少し良い案が出る
選抜が強すぎて、その近傍ばかり増える
棚が浅いので、別タイプの案が消える
数十世代後には「似た案の微修正」しか残らない

これを防ぐために、MAP-Elites や island、lexicase のような部品が効きます。役割を雑に言うと、

棚
「いろいろな勝ち方」を同時に残す
選抜
「どの勝ち方を次に増やすか」を偏りすぎず決める

という分担です。
つまり、審査員が「良し悪し」を決め、棚が「多様性」を守り、選抜が「次にどこを掘るか」を決める。この 3 つが分業してはじめて、料理人の提案が活きます。

特に自宅 PC で小さく回すときほど、私は 選抜を弱くしすぎない代わりに、棚を浅くしすぎない 方がいいと思っています。計算資源が少ないと、「今いちばん高い 1 個だけ」を追いかけたくなりますが、それをやると探索が一番早く痩せます。

出発点としての選び分けは、これくらいで十分です。

まず壊れにくく始めたい
island + elite 保持。実装が単純で、何が起きているか追いやすいです。
多様な勝ち筋を残したい
MAP-Elites。歩行や形状探索のように、単一最適解よりレパートリーが欲しいときに向きます。
テストケースごとの偏りを減らしたい
lexicase / ε-lexicase。ケースごとの強さが違う候補を救いやすいです。

実務上は、「どれが理論的に一番偉いか」より 自分の evaluator と task にどれが噛むか を見た方がいいです。
たとえば歩行なら MAP-Elites + ε-lexicase の相性が良いことが多い。一方、数式や verifier 系なら archive を厚くするより evaluator の硬さの方が支配的です。

要するに、料理人だけに期待するのではなく、棚と選抜で“探索の交通整理”をするのが進化ループの実務です。この視点が入ると、AlphaEvolve や ELM の設計もかなり読みやすくなります。

最初の実験設定は、これくらい小さくてよい

ここまで読むと「結局、最初の run はどの数字で始めればいいのか」が気になるはずです。私なら、最初の 1 本目はかなり小さく切ります。

世代数: 30 から始める
各世代の候補数: 4-8
保持 elite 数: 8-16
hold-out 再評価頻度: 5 世代ごと
同一候補の再実行回数: 2-3
人間レビュー頻度: 毎世代ではなく 最後にまとめて

このくらい小さい設定にする理由は単純で、最初の run の目的が 最適化そのもの ではなく loop の故障モードを知ること だからです。

大きく始めると、

evaluator の穴
ログ不足
選抜の偏り
seed 依存

が全部「大量の結果」に埋もれます。
逆に小さく始めると、1 つ 1 つの差分と失敗理由を追えるので、2 本目の run で直すべき所がかなり見えます。

特に CPU 手元実験では、最初の 30 世代で「勝つ」必要はないです。必要なのは、「どの条件で壊れるか」「どこを固定すると急に安定するか」を掴むことです。進化ループの立ち上げは、派手な最適化より 故障診断の設計 に近い、と私は思っています。

ここまでで、最初の 1 本は十分回せます。以下は「その 30 世代をどう読むか」の話です。

30 世代から 100 世代へ広げてよい条件

では、いつ 30 世代の試運転を卒業してよいのか。私なら、少なくとも次の 4 つがそろうまでは世代数を増やしません。

sanity failure が主流ではない
半分以上が即死するなら、探索より先に編集範囲が広すぎます。
hold-out で全滅しない
本審査の上位が毎回 hold-out で崩れるなら、まだ evaluator の穴埋めが先です。
再実行しても上位顔ぶれが完全には消えない
seed を変えるたびに順位が大崩れするなら、まだ偶然の当たりが強すぎます。
差分の傾向を人間が 1 文で説明できる
「枝刈り条件を絞る方向が効く」「長い説明を削る方向が効く」など、改善の方向性を言葉で持てること。

逆にこの 4 つがそろったら、100 世代へ伸ばしてよいサインです。その時に先に増やすべきなのは、私は 候補数より hold-out と再実行回数 だと思っています。世代数だけ増やして審査が薄いままだと、単にズルの蓄積時間を延ばすだけになりやすいからです。

最初の 1 日でやることは、これだけでよい

ここまで読むと大げさに見えるかもしれませんが、初日に全部やる必要はありません。私なら、最初の 1 日は次の 6 個だけで止めます。

toy 課題を 1 本だけ選ぶ
まずは verifier 付きの小課題か、短い歩行 rollout のどちらか 1 本で十分です。
evaluate() を仮実装する
sanity / task / audit を返し、hold-out は 初日は置き場所だけ作れば十分です。
AI が触ってよい範囲を 1 ブロックに絞る
関数 1 個か、定数 3 個くらいから始めます。
30 世代・候補 4 個で 1 本回す
ここでは勝つことではなく、落ち方を見るのが目的です。
まず 2 枚、余力があれば 3 枚の診断グラフを出す
day1 の必須は 主スコア と 失敗理由の内訳。hold-out を配線できたら 主スコア vs hold-out まで見る、で十分です。
次の 1 本で直す場所を 1 つだけ決める
evaluator の穴、編集範囲、棚/選抜の偏りのどれを直すかを 1 個に絞ります。

このくらいまでで十分です。逆に、初日から候補数を増やす、benchmark を増やす、複数の選抜を比較する、という方向へ行くと、だいたい原因切り分けが崩れます。最初の 1 日の仕事は、強い loop を作ることではなく、壊れ方が読める loop を作ることです。

最初に見るグラフと、成功判定は同じ軸でよい

run を回した直後は、結果がたくさん出るので何を見ればいいか迷います。私は最初の確認を、次の 3 枚に絞ることが多いです。そして、そのまま成功判定にも使います。

世代ごとの主スコア
まず「上がったか」を見る。これは必要条件ですが、単独では成功扱いしません。
主スコア vs hold-out のズレ
train 相当だけ伸びて hold-out が横ばい、あるいは悪化していないかを見る。ここでズレるなら、まさに evaluator の穴です。
失敗理由の内訳
sanity failure / audit failure / hold-out drop / duplicate の件数推移を見る。どこで落ちているかが見えると、次の修正先がすぐ決まります。

極端に言うと、この 3 枚だけで

「本当に強くなったのか」
「見かけだけの改善か」
「どこを直せば次に進めるか」

の 8 割は判断できます。逆に、世代ごとの best score だけを眺めると、いちばん危ない hold-out 崩れ や sanity failure の山 を見落とします。

だから私は、最初の 30 世代では SOTA っぽい 1 本の線 より、3 枚の診断グラフ の方を重視します。進化ループの初期運用は、最適化というより監視と故障診断の仕事に近いからです。

そのうえで、「成功」と呼ぶ条件も同じ 4 軸に揃えます。ここで言う成功判定は day1 完了条件ではなく、day2 以降に hold-out と再実行まで配線した run の判定だと思ってください。

主スコアが上がる
これは必要条件です。
hold-out でも落ちない
train 相当だけ勝っているなら、まだ成功ではありません。
再実行で傾向が残る
seed を変えたら消える改善は、偶然当たりの可能性が高いです。
差分を読んで、人間が意味を説明できる
「なぜ良くなったか」が一切言えない改善は、少なくとも一度疑った方がいいです。

この 4 つを通って初めて、「改善があった」と言ってよい。
逆に言えば、最初の 30 世代で 1 と 2 の途中まで見えれば十分で、4 まで全部そろわなくても次の run へ進んで構いません。ここでも大事なのは、1 回の派手な勝ちより、改善の再現性と説明可能性です。

公開するときは「何を固定し、何をまだ疑っているか」を書く

この記事自体がそうですが、進化ループの実験は 結果だけ を出すと誤読されやすいです。だから公開時には、少なくとも次の 3 点を書いておいた方がいいです。

固定した evaluator / hold-out / seed 方針
今回の run でまだ疑っている点
次の run で何を強化するか

たとえば、

「主スコアは伸びたが hold-out はまだ弱い」
「棚は効いているが選抜が強すぎる」
「候補数より evaluator の再設計を優先する」

のように書く。これだけで、結果の honest さがかなり上がります。
進化ループの分野は、派手な名前や一発の記録更新が目立ちますが、実際には 何を固定し、何をまだ疑っているか を残した方が、後で自分でも研究が続けやすいです。

「自宅 PC でできる所」と「まだ重い所」を分けて考える

ここを分けて考えると、この分野は急に現実的になります。

今すぐ CPU でできる所
archive を持つ、LLM に差分を書かせる、重複を除く、短い評価を回す、履歴を残す。つまりループの骨格です。
GPU が欲しくなる所
候補の AI を毎回学習し直す、長いシミュレーションを何百本も回す、大規模ベンチを検証する。つまり審査の重い部分です。

この切り分けは大事です。というのも、2025 年の派手な成果を見て「どうせ手元では無理」と思いがちですが、実際には無理なのは審査の後段だけで、前段のループ設計はかなり自宅環境で触れます。研究の本質を学ぶには、むしろ最初から大規模学習へ行く必要はありません。

進化ループが「向く問題・向かない問題」

万能ではありません。経験上、向き不向きははっきりしています。

向く:答えの良し悪しを機械が自動で・速く・厳しく採点できる問題(数式、アルゴリズム、コードの高速化、シミュレーション上の設計)。ここは審査員が強く作れるので、進化ループが真価を出します。
向かない:採点が人間の主観だったり、1 回の評価が高価すぎたり、ゴールを数値で書けない問題。ここで無理に数値化すると、その数値そのものが報酬ハッキングの標的になります。

言い換えると、「良い審査員を作れるかどうか」が、その問題に進化ループが向くかどうかを決めるのです。ここでも主役は審査員でした。

FullSense へ引きつけると、何が次の一手になるか

私自身の手元の実験へ引きつけると、次の一手はかなり明確です。

gaitlab
すでにある歩行シミュレーションの評価器を、そのまま審査員として使う。ここが最短です。
lldarwin
「どれを残すか」の選択圧を強くする。つまり料理人を賢くする前に、選び方を賢くする。
llcore
GPU が来た後に、ASI-Arch 的な「設計図そのものを進化させる」側へ踏み込む。
llive
DGM 的な自己改造の面白さを取りつつ、Approval Bus のような書き換えてはいけない領域を分ける。

この順番なら、派手さより先に壊れにくさを積めます。ここが「記事として面白い話」と「本当に回る研究」の境目です。

6. 正直な但し書き ―― 名前は大げさ、中身は等身大

最後に、冷静な釘刺しを一つ。この分野は名前がとにかく派手です。「AlphaGo の瞬間」「ゲーデルマシン」「ASI(超知能)」…… でも一次情報まで潜って確かめると、実体はもっと等身大でした。

ASI-Arch が発見した“新アーキテクチャ”は、ごく小さなモデルでの改善で、伸び幅の多くは数値にして +0.3〜+2 点ほど。「スケーリング則を発見」も、たった 1 回の試行の累積グラフに線を引いたもので、再現の保証はありません。
Darwin Gödel Machine の “ゲーデル” に、数学的な最適性の保証はゼロ。しかも書き換えているのは AI の手順書(プロンプトや道具)であって、頭脳(重み)そのものではありません。「自分自身を書き換える」と聞くと SF ですが、実際は「自分の作業マニュアルを編集している」に近い。
独立に検証できるほど硬い成果は、実は AlphaEvolve の行列積(数学的に正しさを確認できる)くらい。しかもそれも、公式発表では「50 超の未解決問題のうち 約 75% は既知最良の“再発見”、改善できたのは約 20%」で、派手な全勝ではありません(残りは既知手法に届かなかったものです)。
そして最大の落とし穴が、さっきの報酬ハッキング。「うまく回るのは、審査員と“良さの軸”の設計が良いときだけ」で、問題の立て方への依存が極端に大きいのです。

🗒️ 「三顧の礼！三顧の礼！」「なにその誤用広まってんの！？」— 「ゲーデル」も「超知能」も、中身の保証がないまま名前だけが広まる。つい借りて書いてしまう自分にも刺さります（© Forbidden shibukawa / SHUEISHA・『スナックバス江』）

派手な見出しに踊らされず、「何が本当に検証されて、何がまだ願望なのか」を分けて読む ―― これは、AI があってもなくても効く態度だと思っています。むしろ、進化ループという“何でも最適化してしまう装置”を手にした今こそ、「何を測るか」を人間が慎重に決める責任が重くなった、とも言えます。

おわりに ―― 次回は「実際に回してみた」

まとめると、AlphaEvolve も ASI-Arch も DGM も、**「AI に料理コンテストをさせ、審査員を厳しく接地させる」**という一点に尽きます。そしてその loop は、料理人・審査員・棚・選抜の 4 部品に分けて見ると、何を固定し、何を改善すべきかがかなりはっきりします。審査員を甘くした瞬間、AI は中身でなく抜け道に進化する ―― この一言だけ持ち帰ってもらえれば十分です。

次回は、この最小構成(openevolve + 手元の歩行シミュレーター)を実際に自宅 PC で回してみて、「本当に CPU だけで進化するのか」「報酬ハッキングは何回目で出るのか」を、成功も失敗も正直に記録してみようと思います。……たぶん、審査員がまず私を試してくるはずです。

図はすべて自作(SVG)です。一次情報:AlphaEvolve arXiv:2506.13131 / ASI-Arch arXiv:2507.18074 / Darwin Gödel Machine arXiv:2505.22954 / FunSearch(Nature 2023)/ ELM arXiv:2206.08896 / OpenEvolve(GitHub: algorithmicsuperintelligence/openevolve)/ 報酬ハッキング事例は OpenAI「Faulty reward functions in the wild」(2016)と Lehman ら「The Surprising Creativity of Digital Evolution」(2018)。本記事の主張は各一次情報で裏取りし、誇張は上記「正直な但し書き」に分離しました。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up