プロンプトを1つ直したら、別のケースで急に応答がおかしくなった——エージェント開発をしていれば一度は経験する「もぐら叩き」状態を、どう構造化して防ぐかがこの記事のテーマだ。

3段階のフライホイール

Googleが提示しているのは、Build & Test(作って検証する)、Ship & Monitor(出荷して監視する)、Learn & Refine(学んで磨き直す)という3段階を回し続ける枠組みだ。名前だけ聞くと目新しさはないかもしれないが、ポイントはこれをコーディングエージェントの日常的な作業フローに組み込んでいる点にある。特別な評価専任チームがバッチで回すものではなく、開発者が普段触っているエージェントから直接、品質改善のループを回せるようにしている。

ソフトウェアテストとの共通点、そして違い

「変更前後を同じ条件で比較し続ける」という発想自体は、単体テストや回帰テストと本質的に変わらない。決定論的なコードであれば、テストが通ればほぼ確実に同じ結果が返る。ところがLLMベースのエージェントは、同じ入力でも出力が揺れうる。だからこそAutoRatersのような評価の仕組みで、1回の実行結果ではなく傾向として良くなったかどうかを見る必要がある。従来のソフトウェアテストの考え方を土台にしつつ、確率的なシステム向けに拡張したものと理解すると位置づけがはっきりする。

「勘」から「工程」への移行

これまでのエージェント開発は、少数のデモがうまく動けば良しとする、ある種の勘に頼った進め方になりがちだった。品質フライホイールという名前を与えて明文化したこと自体に価値がある。評価を継続的な工程として組み込む文化が広がれば、エージェントの改善が「たまたま今回はうまくいった」で終わらなくなる。AutoRatersの具体的な仕組みや導入手順は、Google Developers Blogの記事(https://developers.googleblog.com/driving-the-agent-quality-flywheel-from-your-coding-agent/)で解説されている。