Agents CLIのevalでエージェント品質を継続的に改善する手順

題材は Agents CLI v1.8.0 に付属する LangChain テンプレートである。4件のデータセットを用意し、gemini-3.8-flash を審査役とするカスタムの LLM-as-judge 指標で1〜5点を付ける。ベースラインの平均は4.0、標準偏差は1.41だった。

システムプロンプトをシェフの人格に誤って差し替えると、平均は2.75に下がった。eval compare でケース別に見ると、sf_weather は get_weather ツールを呼ばず天気をでっち上げて4.0から2.0に落ちた。greeting は5.0から4.0、off_topic は5.0から3.0に下がっている。コードが動くため単体テストでは検出できない変化を、評価が数値で示した。

モデルを gemini-2.5-flash に差し替えた実験でも平均は4.00から2.75に下がり、プロンプト誤りと同じ下げ幅になった。しかし内訳では低下の大半が off_topic（5.0から1.0）に集中し、他のケースはほぼ維持されていた。平均だけを見ると判断を誤るという例である。ただしプロンプトとモデルは相互作用する点と、審査モデルを固定する点も注意として挙げている。

運用面では、cron や Cloud Scheduler で eval generate と eval grade を定期実行し、平均スコアが基準から閾値以上落ちたときに非ゼロで終了する Python スクリプトでアラートを出す例を示している。ADK プロジェクトでは eval optimize が GEPA フレームワークでプロンプトを自動改善するが、LangChain 拡張は未対応で、指標への過適合を避けるため人によるレビューが前提になる。

得られた教訓として、小さく代表的なデータセットから始めること、スコアだけでなく結果ファイルを保存すること、データセットと期待値の設定を分けることを挙げている。また、agents-cli を使うコーディングエージェントは eval の実行回数が4倍になるが、eval 後にエージェントを変更する頻度はほぼ変わらなかったという自社調査にも触れている。