進化計算の初期の実践では、「進化」の対象となるものはほぼすべて数値パラメータ——学習率、バッチサイズ、正則化強度、重みの初期化方法などでした。探索空間は数値の集合であり、評価方法は1回の学習と1回の検証でした。計算資源の規模が拡大し大規模モデルの能力が成熟するにつれて、進化可能な対象は明らかに広がりました。プログラム、モデル構造、アルゴリズムの仕組み、さらには一塊のソフトウェアエンジニアリング状態（設定、依存バージョン、インターフェース契約、デプロイと運用戦略）まで含まれます。
この拡張の道筋は、明確な矢印の連鎖で表せます。数値パラメータ → プログラムとモデル構造 → ソフトウェアエンジニアリング状態とシステムレベルの候補。階層が右に進むほど表現力が高まり、カバーできる変化の種類が増えるため、システムレベルの進化が可能になります。
3層の進化対象、それぞれのコストは異なる
- 数値パラメータ層：候補は数値の集合であり、生成は安価で評価も速いものの、「うまく調整できたか」にしか答えられず、そもそも欠けている仕組みを補うことはできません。
- プログラムとモデル構造層：候補はネットワーク構造、演算子の組み合わせ、プロンプトワークフロー、コードパッチであり、変化は「どれだけ正確にできるか」だけでなく「システムが何をできるか」を変えます。
- ソフトウェアエンジニアリング状態層：候補は設定、依存バージョン、インターフェース契約、デプロイ戦略であり、システムが安定的に動作するか、再現可能かを直接左右します。
重心の移行：「候補をいかに生成するか」から「いかに実行し評価するか」へ
候補が数値からプログラムになると、「候補の生成」はもはやボトルネックではなくなります。大規模モデルは構造、仕組み、パッチをまとめて生成できるからです。進化が有効かどうかを本当に決めるのは、実行と評価の仕組みです——候補を実際に動かせること、そして許容できるコスト内でそれを残す価値があるかを見極められることが重要です。
表現力が高いほど、評価の負担は重くなります。1つの数値パラメータは1回の学習で採点できますが、1つのコードパッチはサンドボックス分離、回帰テスト、ベースライン比較を経て初めて、本当に有効か、リスクをもたらすか、結果を再現できるかという3つの問いに答えられます。サンドボックス、回帰テスト、ベースラインこそがコスト・リスク・再現性を制約するためのエンジニアリング装置であり、変化を安定的に保持または淘汰することを可能にします。
エンジニアリング上のトレードオフ：候補が増えても進化が良くなるとは限らない
チームの実践では、まず学習率とハイパーパラメータを調整し、その後徐々にネットワーク構造、演算子の組み合わせ、プロンプトワークフロー、コードパッチの探索へと広げるのが一般的な道筋です。1層拡張するごとに、次のことに同時に答える必要があります。評価にどれだけの計算資源と時間がかかるか？失敗した候補が既存システムを汚染しないか？同じ結果を次回も再現できるか？表現力、評価コスト、再現性、安全性のバランスが取れて初めて、システムレベルの進化は真に実現可能になります。
進化対象の3層拡張図の矢印の連鎖は、数値パラメータからプログラムとモデル構造へ、さらにソフトウェアエンジニアリング状態とシステムレベルの候補へと向かっています。右に進むほど変更できる対象が増え、表現力も高まります。しかしコストも同時に上昇し、数値パラメータは1回の学習で採点できますが、コードパッチはサンドボックス分離、回帰テスト、ベースライン比較を経なければ、有効性・リスク・再現性を判断できません。
