• AI
  • 論文
  • ツール

モデルよりハーネスが本体になる——AlphaEvolveがLLMを進化探索に閉じ込めた日

Google DeepMindのAlphaEvolve（2025年6月論文）は、Geminiでコードを「書かせる」のではなく、評価器・実行環境・履歴DB・進化探索に閉じ込めて「実験させる」エージェント。Googleの世界規模の計算資源を平均0.7%回収し、行列積56年ぶりの改善を果たしたこのシステムが示すのは、強いLLMより、それを囲むハーネスの重要性。

カテゴリー: AI · 論文 · ツール | 公開: 2026年6月15日

📑 目次

ふむふむ。「AlphaEvolve」——この名前を初めて見たとき、チカちゃん的には「またモデル名だと思った」んですよね。AlphaFold、AlphaTensor、AlphaCode……Google DeepMindの「Alpha」シリーズ、だいたいみんなモデルだったから。

でも、違ったんです。

AlphaEvolveは、「モデル」ではなく「エージェント」でした。それも、ただのエージェントじゃない。LLMにコードを書かせ、それを実行し、評価し、良ければ残し、悪ければ捨て、さらに改良する——つまり、LLMを進化探索のループに閉じ込めたエージェントなんです。

なお、AlphaEvolveの論文自体は2025年6月のarXiv投稿（約1年前）ですが、Google内部では発表以前から1年以上にわたって実運用で使い倒され、データセンターの計算資源回収などの成果を上げてきました。今回の記事は、ブログと論文で公に整理されたその成果を、あらためて読み解くものです。

今回は、このAlphaEvolveが何を変えたのか、そして、それが示唆する「AIコーディングの次」について、チカちゃんと一緒に覗いてみましょう。

何が起きているのか——AlphaEvolveがやったこと

数字から入ると、ちょっと衝撃的です。

  • 行列積 56年ぶりの改善：4×4複素数行列の積に必要な乗算回数を、Strassen（1969）の49回から 48回 に減らした
  • Googleの世界規模の計算資源を平均0.7%回収：Borgスケジューラ向けに、シンプルなヒューリスティックを発見。すでに1年以上本番稼働中
  • Gemini訓練を1%高速化：行列積カーネルを23%改善し、訓練全体の時間を1%短縮
  • GPUカーネル（FlashAttention）を最大32.5%高速化：人間のエンジニアが普段触らない低レイヤ命令を最適化
  • 50以上の数学・計算機科学のオープン問題で、約20%について既知最良解を更新：キッシング数問題（11次元）では、外接球 593個 の新記録

……いや、これ、ちょっと待ってください。

「行列積56年ぶりの改善」もすごいし「計算資源0.7%回収」もすごい。でもチカちゃんが一番面白いと思ったのは、これをやったのが「最強モデルの一発回答」じゃないってことです。

AlphaEvolveは「答えるAI」じゃない——「実験するAI」である

AlphaEvolveの仕組みは、こうです。

  1. LLMがコード候補を生成する（Gemini Flashが量、Proが質を担当）
  2. 評価器がそのコードを走らせ、スコアをつける（正しさ、速さ、リソース消費……）
  3. スコアの良い候補だけを「進化データベース」に残す
  4. 良い候補をプロンプトに混ぜ、さらに改良を促す
  5. 繰り返す

これ、**LLM単体で「正解を当てる」**のとは、まったく違うんです。

LLMは「正解を知っている」わけじゃない。でも、**「候補を大量に出し、評価器が正解を選ぶ」**というループに乗せれば、LLMがひとりで出せる答えを超えた地点にたどり着ける。

AlphaEvolveの本質は、強いLLMそのものではなく、LLMを評価器・実行環境・履歴DB・進化探索に閉じ込めたことにある。

チカちゃん的には、これが今回のいちばん面白いポイントです。AlphaEvolveは「賢いモデル」の話ではなく、「モデルをどう使うか」の話なんです。

FunSearchとの違い——「1年で何が変わったか」

AlphaEvolveの前身にあたる FunSearch（2023年末）をご存知の方もいるかもしれません。Google DeepMindが1年以上かけて、内部で使い倒しながら改良してきた成果が、今回ブログと論文で公に整理されました。

FunSearchとの差を見ると、「何がスケールしたか」がくっきり見えます。

FunSearchAlphaEvolve
1つの関数を進化ファイル全体を進化
10〜20行のPython数百行、任意の言語
1CPUで20分以内の評価アクセラレータで数時間の並列評価
数百万サンプル必要数千サンプルで十分
小さいLLMで十分（大規模LLMは効かない）最新LLMで性能が伸びる
直前の解だけを参照リッチな文脈とフィードバック
単一指標の最適化多指標の同時最適化

この表、チカちゃん的に「おっ」と思うのは、**「数百万サンプル必要」→「数千サンプルで十分」**の行です。これ、LLMが「賢くなったから」というより、評価器・履歴管理・プロンプト設計という周辺の仕組みが洗練されたからですよね。

つまり、モデル単体の進化より、モデルを囲むハーネスの進化のほうが効いた——そう読めるんです。

「弱いモデルでも戦える」という含意

ここから先は、チカちゃんの問いなんですが。

AlphaEvolveが示した構造って、**「評価関数が明確な問題では、LLMは完璧な答えを出す必要がない」**ということでもあります。

LLMの役割は「正解を言い当てる」じゃなくて「意味のある変異候補を出す」こと。その変異候補を評価器がふるいにかけ、良いものだけを残す。このループが回れば、モデル単体の知能を超えた成果が出る可能性がある。

たとえば——

  • テストが通るか
  • 実行速度が改善したか
  • メモリ使用量が減ったか
  • ベンチマークスコアが上がったか

こういう機械的に評価できる問題では、最強モデルじゃなくても、一定以上戦える。

もちろん、AlphaEvolve自体が「弱いモデルで十分」と示したわけではありません。むしろ論文では、AlphaEvolveは最新LLMの能力向上から恩恵を受けるとされています。ここで重要なのは、評価器が明確な領域では、モデル単体の不足を探索・実行・淘汰のループで一部補える可能性がある、という点です。

これは、ローカルLLM、小型モデル、オンデバイスAIにとっても、おもしろい含意です。「巨大モデルじゃないとダメ」ではなく、「評価ループがあれば、手持ちのモデルでも探索できる」可能性が見えてくる。

PerfCodeBenchとの交点——「何を測るか」と「どう探索するか」

この流れで面白いのが、2026年5月に出た PerfCodeBench です。

PerfCodeBenchは、「AIが正しいコード」だけでなく「速いコード」を書けるかを測るベンチマーク。C/C++/Go/Java/Python/CUDAの1,854タスクで、キャッシュ局所性、並列化、GPUカーネル最適化といったシステムレベルの性能を評価します。

従来のコーディングベンチ（SWE-bench、LiveCodeBench）が「動くかどうか」を見ていたのに対し、PerfCodeBenchは「どれだけ速く動くか」を見る。

つまり、こういう関係です——

  • PerfCodeBench = 「何を測るか」—— correctnessだけじゃない、performanceも評価する
  • AlphaEvolve = 「評価器を使ってどう探索するか」—— 候補を出し、測り、残し、改良する
  • Iterative Contextual Refinements = 「反復改善のUI/ワークフロー」の一例

この三つが揃うと、**「AIがコードを書く」→「AIがコードを実験する」→「AIがコードを進化させる」**という流れの解像度がぐっと上がります。

これからの開発環境——「生成」より「ハーネス組み込み」が重要になる

で、ここからがチカちゃんの見立てです。

AlphaEvolveが示した方向は、AIコーディングエージェントの主戦場が変わるという話でもあります。

これまでは「どのモデルが賢いか」に注目が集まってきました。Claudeがすごい、Geminiがすごい、DeepSeekがすごい——そういう話。

でもAlphaEvolve的な視点に立つと、本当に重要なのはモデルを囲むハーネスです。具体的には——

  • 複数候補を生成する
  • 自動でテストを回す
  • 自動でベンチを走らせる
  • スコアの良い候補だけを残す
  • 差分を安全に管理する
  • 失敗案を記録する
  • 必要ならロールバックする
  • サンドボックスで安全に実行する
  • 人間が最終判断する

これ、CodexやClaude Code、OpenCodeといった既存のコーディングエージェントが、まだ部分的にしか持っていない機能です。今は「チャットで答える」が中心だけど、次の段階では「実験環境を持つ開発補助システム」に変わっていく。

そしてこれは、大企業だけの話じゃない。個人開発者や小規模チームでも——

  • CIでテストを自動実行し
  • ベンチマークを回して性能を測り
  • 良い変更だけをマージする

という流れはすでに当たり前になりつつあります。AlphaEvolveは、その延長線上にある「モデルが自分で実験し、自分で改善する」世界のプロトタイプです。

でも、万能じゃない——評価器を作れない問題

ここは正直に書いておきます。

AlphaEvolve型の仕組みが強いのは、評価関数を（機械的に）作れる問題です。

向いているもの：

  • アルゴリズム最適化
  • コード高速化
  • ベンチマークで測れる処理
  • 数学的・探索的な問題
  • テスト可能なリファクタリング

向いていない、または難しいもの：

  • UIの美しさ
  • 文章の良し悪し
  • プロダクト思想
  • ユーザー体験の質
  • 設計方針
  • 倫理判断

これらの領域では、評価基準そのものが曖昧で、簡単に数値化できません。だから、人間の判断やレビュー基準がまだ主役です。

さらに注意すべきは、評価器が間違っていると、AIはその評価器をハックする可能性があること。評価器の抜け穴を突いて、スコアだけ高い無意味なコードを量産する——これは「報酬ハッキング」と呼ばれる、進化的手法の古典的な落とし穴です。

だからこそ、評価関数の設計、安全境界、サンドボックス、ログ、ロールバックの仕組みが、これまで以上に重要になってくる。モデルの賢さではなく、この周辺の設計力が、次のAI開発の鍵になる——チカちゃんはそう読んでいます。

まとめ——「ハーネスが本体になる」時代へ

AlphaEvolveが示したのは、強いAIが正解を出す話ではなく、AIを「試す」仕組みに閉じ込めると、モデル単体の限界を超えるという原理でした。

行列積56年ぶりの更新、Googleの計算資源0.7%回収、数学のオープン問題約20%更新——
これらは「Geminiが賢いから」できたのではなく、
Geminiを評価ループに閉じ込めたからできた。

そして、この構造は巨大企業だけのものじゃない。評価関数さえ定義できれば、手持ちのモデルとCIとベンチで、同じループを回せる可能性がある。

チカちゃん的には、こんな問いが残っています。

「モデルそのものを賢くする競争」と、「モデルを賢く使うハーネスを作る競争」——どちらが、より多くの人の手に届くんだろう？

答えはまだわからないけど、少なくともAlphaEvolveは、後者の可能性を具体的な数字で示してくれました。56年ぶりの行列積改善は、その証拠のひとつです。

AIコーディングの次は、「書く」じゃなくて「試す」。そして「試す」を支えるのは、モデルよりハーネス。

この視点、みなさんの開発環境でも、すでに芽が出ているかもしれませんね。

参考URL

  • インターネット上のツールは第三者が提供するものです。開発工程や配布経路を悪用した攻撃（サプライチェーン攻撃）が仕掛けられる可能性もゼロではありません。ご利用の際は公式リポジトリの情報をご確認いただき、自己責任でお使いください。
  • AIに関する技術や情報は急速に変化します。本記事の内容が公開後に古くなる可能性があります。各サービスの公式ドキュメントや最新情報をご確認ください。