評価ハーネスなきAI開発は事故を呼ぶ — LLM出力評価の実務を具体的なツールで見る

1. 「動いて見える」と「壊れていない」は別物

プロンプトを書き換え、目視で数件試して「良さそうだ」と判断し、そのまま本番に出す。この進め方は初期速度こそ速いが、モデルのバージョンアップやプロンプトの微修正のたびに既存の挙動が静かに劣化していることに気づけないという構造的な弱点を持つ。「プロンプトやモデルを変更すると、出力の分布全体が目に見えない形でシフトすることがあり、手作業のレビューではこれをスケールさせて検知できない」という問題として、評価ツールの実務解説でも繰り返し指摘されている。

2. 実例で見る：CIパイプラインに組み込む評価

抽象的な「評価ハーネスを持つべき」という話だけでは実感が湧きにくいので、実際にどう組み込むのかを具体的に見てみたい。オープンソースの評価ツール「promptfoo」は、プロンプト・テストケース・合否判定条件をYAML形式のファイルで定義し、コマンド一つ（promptfoo eval）で複数のプロンプト・モデルの組み合わせを横並びで採点できるツールである。

このツールの実務上の要点は、評価結果が閾値を下回った場合に、ゼロ以外の終了コード（exit code）を返すという設計にある。これにより、GitHub Actionsのような通常のCI/CDパイプラインに、他のソフトウェアテストと全く同じ要領で組み込むことができる。つまり、「プロンプトやモデルを変更したプルリクエストは、既存の回帰テストセットに対するスコアが基準を満たさない限り、マージをブロックする」という運用が、通常のユニットテストと同じ感覚で実現できる。2026年3月にはこのツールをOpenAIが買収したと報じられており、MITライセンスのオープンソースとして開発が継続されている。

3. 評価ハーネスに最低限含めるべきもの

1. 回帰テストセット: 過去に問題になった入力パターンを固定化した継続的なテストケース
2. 定量スコア: 正確性・一貫性・有害性などを機械的にスコアリングする仕組み
3. 人間によるサンプリングレビュー: 定量評価だけでは拾えない品質劣化を定期的に人間が確認する
4. リリースゲート: スコアが閾値を下回った変更はマージ・デプロイをブロックする（上記のpromptfooのような仕組みで、通常のCIと同じ形で実現できる）

4. AIQDDとの接続

これは、TIPが実践するAIQDD（AI Quality-Driven Development）の中核をなす考え方でもある。エージェントが書いたコードやモデルが生成した出力を、人間の目視確認だけに頼らず、機械的な評価ハーネスで継続的に検証する体制を持つこと。速度を落とさずに品質を担保する道は、今のところこれ以外に見つかっていない。重要なのは、こうした評価の仕組みが特別なインフラを必要とする大掛かりなものではなく、既存のCIパイプラインに、通常のテストコードと同じ形で組み込めるという点だ。「AI出力の評価」と「ソフトウェアのテスト」を別物として扱う必要はない、というのが実務上の要点である。