AIにコードを最適化させる前に、合格条件を実行可能な形で書けるか

探索より先に評価契約を作る

評価器には五つの役割が必要である。比較元となる実行環境と基準値を固定する。改善方向を一つの計算可能な指標にする。正しさ、再現性、資源、インターフェースに関する絶対条件を検査する。予算や連続無改善回数で処理を止める。そして、差分と証拠を確認してリリース可否を決める責任者を置く。

これは書類を埋める作業ではない。Klarna Engineeringの事例では、変更範囲、指標、譲れない制約を技術者が定めていた。それでも決定性の条件が抜けた結果、高速だがデプロイできない経路が生まれた。また、改善なしで631回の評価が続いた記録は、停滞を検知する打ち切り条件の必要性を示している。

評価器の合格とリリース承認を分ける

実行ごとに初期版、環境、得点、制約検査、停止理由、最終差分を残す。責任者はその記録を読み、セキュリティ、運用、プロダクト面の追加確認へ進めるかを判断する。評価器が保証できるのは、書かれた条件に候補が適合したことまでである。条件そのものが十分だったとは証明できない。

最初の一歩は基盤導入ではない。境界の明確な最適化対象を一つ選び、基準値、指標、絶対条件、打ち切り条件、責任者を書く。曖昧な欄が残ったなら、探索を始めず、その欄を検証可能にすることが次の作業である。

評価する前に探索範囲を区切る

1. 園丁は小さな区画で数株の苗を比べ、管理できる試験から始める。
2. 苗の列が当初の範囲を越えて広がり、園丁は拡大の様子を見て立ち止まる。
3. 木杭とロープを使い、今回完了させる試験区を一つだけ囲い直す。
4. 囲った区画は健全に育ち、残りの畑は次の判断まで手を付けずに残る。