あるデータチームには、1 日 1 回走らせる定期計算があり、終わるまでに 40 分かかる。エンジニアはそのコードを自動最適化ツールに渡し、目標を「できるだけ速く」と設定した。一晩たつと、ツールは 12 分で終わる版を返してきた。テストもすべて通っている。翌週、照合作業で、いくつかの金額の小数点以下の数桁が以前と食い違っていることがわかった。新しい版は速さのために精度の低い計算方法に切り替えていて、既存のテストはたまたまその桁を確かめていなかった。

2026 年 7 月、Google Cloud は AlphaEvolve を企業向けに公開した。Gemini モデルを土台にしたコード最適化ツールで、利用者が最初のプログラムと評価プログラムを用意すると、修正版を大量に繰り返し作っては評価プログラムに点数を付けさせ、点数の高いものを残していく。こうしたツールは、人が思いつかない解を本当に見つけることがある。だが見ているのは、評価プログラムが測れるものだけだ。だから任せる前に、チームは「より良い」を実行できる条件に書き直しておく必要がある。「もっと速く、品質は落とさずに」だけでは足りない。

測られたものだけが最適化される

Google DeepMind は 2025 年に AlphaEvolve を初めて紹介したとき、自動化された評価指標で候補のプログラムを検証、実行し、それぞれに点数を付けると説明している。点数の高い版が残り、次の回の生成の方向に影響する。すべてが点数頼みなので、この種のツールは、進歩をはっきり測れる分野にいちばん向いている。

Google Cloud の説明では、使い方は四つの段階に整理されている。最初のプログラムと問題を定義する、採点の方法を決める、ツールに最適化させる、結果を本番環境に適用する。評価プログラムは利用者が自分で用意し、結果が決まっていて再現できるスクリプトでなければならない。コンパイルし、テストし、点数を返す役目を負う。

問題はこのスクリプトにある。このサービスを報じた InfoQ ははっきり注意している。進化的な探索は、評価プログラムが測っていないものを何でも突いてくる。たとえば、速いがテストで見つからない細かな誤りを含むコードを生み出す。記事はまた、これまで公開された成果の数字は Google や顧客自身によるもので、独立したベンチマークはまだないと指摘している。

冒頭のチームに起きたのは、まさにこれだ。評価プログラムは速さを測ったが精度は測らなかったので、ツールは精度と引き換えに速さを手に入れた。

任せる前に、評価の契約を書く

自動最適化ツールに渡すのは、目標だけではなく、実行できる契約であるべきだ。少なくとも次の五つに答えている必要がある。

  • 基準： どの版と、どんな環境で比べるのか。
  • 点数： 「より良い」を、実行時間やメモリ使用量など、どう数字にするのか。
  • 破れない制約： 点数が上がっても決して破ってはいけない条件。結果が旧版と完全に一致する、出力の形式を変えない、メモリの上限を超えない、など。一つひとつを、評価プログラムが自動で確かめるテストにする。
  • 停止条件： どれだけの計算予算、どれだけの時間、あるいは何回続けて改善がなければ止めるのか。
  • 承認する人： 変更の中身と確認の結果を見て、使うかどうかを決める名前のある担当者。

五つのうちいちばん漏れやすいのは、破れない制約だ。人がレビューするときは「この数字は変わってはいけない」と自然に思いつく。だが評価プログラムに書かれていない条件は、ツールにとっては存在しないのと同じだ。

広告

その目標が向いているかを見分ける

契約を書くこと自体が判断になる。次の順に問うといい。

  • 結果を客観的に採点でき、制約もすべて自動で確かめられる： 始めてよい。ただし変更の範囲と予算を絞り、結果は人が確認し、自動では本番に出さない。
  • 採点はできるが、使えるかどうかの判断がまだ経験頼み： まだ始めない。よくある却下の理由を一つテストにして評価プログラムに加え、自動化できない判断がまだどれだけ残るかを見る。
  • 良し悪しが人の好みで決まる、あるいは間違えたときの代償を前もって止められない： 自動探索には向かない。AI に選択肢を整理させることはできるが、決定と責任は人に残る。

採点を通っても、要件が揃っているとは限らない

評価プログラムをどれだけ丁寧に作っても、それを通ったということは、候補が書き出された条件を満たしているというだけで、要件そのものが網羅されていることまでは意味しない。実行ごとに最初の版、環境、点数、制約の確認結果、停止した理由を残し、承認する人がすべての証拠を見られるようにしておく。必要に応じて、セキュリティ、運用、製品の観点からの確認も加える。

また、評価プログラムを書くこと自体にも時間がかかる。数回しか走らせず、遅くても困らないコードなら、その手間は割に合わない。投資する価値があるのは、毎日実行され、費用や速さの差が積み重なっていく計算だ。

次の一歩として、範囲がはっきりしていて、チームが前から速くしたいと思っていた計算を一つ選び、五つの項目を書いてみてほしい。書けない項目があれば、まずそこを補う。AI に版を増やさせるのを急ぐ必要はない。候補が返ってきた後、誰がそれを理解し保守するかは、AI が出したコード変更の第一版は試し見積もり。本当の請求はレビューと保守にあるを参考にしてほしい。探索の途中でどこで止まって証拠を見るかは、その issue を coding agent に渡せるかは、最初の diff を書き出せるかで決まるが参考になる。

AI 整理カード

自動最適化ツール（AlphaEvolve のように、コードの版を繰り返し作り、点数で選ぶツール）にコードの一部を改善させたい。その前に、目標が向いているかを判断したい。
判断方法はこの記事による：https://boosterminiclass.com/ja/posts/ai-code-optimization-needs-evaluator-contract/
記事の見方はこうだ。この種のツールは評価プログラムが測れるものだけを最適化し、書かれていない制約は犠牲になりうる。任せる前に、評価の契約を書く。基準、点数、破れない制約、停止条件、承認する人だ。

まず私に 3 つ質問してほしい：
1. 最適化したいのはどのコードで、いまの性能と比較環境はどうなっているか；
2. 「より良い」をどう数字にするか。点数が上がっても破ってはいけない条件は何か；
3. それらの条件に、いま自動テストはあるか。新しい版を採用するかは誰が決めるか。

私の回答をもとに、次を出力してほしい：
- 評価の契約の下書き：基準、点数、破れない制約（それぞれ自動テストがあるかを明記）、停止条件、承認する人。欠けているものは「要確認」と書く；
- 評価プログラムが測り漏らし、ツールに突かれやすいところ；
- 一行の判断：始めてよい／先に評価プログラムを補う／自動探索に向かない、と最も重要な理由；
- 今日できて、本番に出さない次の一歩を一つ。
コードや設定は一切変更しないこと。点数の高い版は、名前のある担当者が差分と確認結果を見てから、リリースの流れに入れること。
広告

Share

このミニクラスを共有

このミニクラスが仕事の詰まりをほどく助けになったら、AI の使い方を考えている人にも共有してください。

参考資料