AIプロダクトの品質はどう担保されているか：評価（evals）体制を技術DDの評価軸にする
結論を先に述べます。LLMを組み込んだプロダクトの品質は、従来の単体テスト・結合テストだけでは保証できません。出力が確率的で「正解」が一意に定まらないため、品質保証の役割を担うのは専用の評価（evals）体制です。技術DDでこの体制の有無と成熟度を確認することは、AI起因の不祥事リスクを見抜くだけでなく、「本当に運用が回っているAIプロダクトか」を判定する評価軸になります。評価データが存在しない、評価を人の感覚に依存している、リリース前に評価を通さずデプロイしている——この3つのいずれかに該当する組織は、成長フェーズで必ず品質問題に直面します。
従来のテストがLLMプロダクトで機能しない理由
従来のソフトウェア開発では、入力に対する「期待する出力」を1つに定義し、それと一致するかを検証するのが単体テストの基本形です。この前提はLLMを組み込んだプロダクトでは崩れます。
出力が確率的：同じプロンプトを2回投げても、モデルの温度パラメータやサンプリングの仕組みにより、表現が異なる出力が返ってくることがあります。文字列の完全一致で正誤を判定するテストは機能しません。
「正解」が一意に定まらない：要約・分類・対話生成といったタスクには、複数の妥当な出力が存在します。「この要約は正しいか」を判定するには、人間の評価基準に近い採点ロジックが必要になり、単純なアサーションでは足りません。
入力空間が事実上無限：ユーザーが自由入力するプロンプトの組み合わせは事前に網羅できません。従来のテストが「想定される入力パターンを列挙してカバーする」発想であるのに対し、LLMプロダクトでは代表的なシナリオをサンプリングして評価する発想に転換する必要があります。
回帰の検知が難しい：モデルのバージョンアップ、プロンプトの微修正、RAGの検索ロジック変更のいずれも、本番での挙動に予期しない影響を与えます。従来のCIが「テストが全部通ったから安全」と判定できたのに対し、LLMプロダクトでは変更の影響範囲を定量評価しないと安全性を主張できません。
これらの理由から、LLMプロダクトの品質保証には単体テストとは別の専用レイヤーが必要になります。それが評価（evals）です。
評価（evals）とは何か：3つの評価手法
evalsとは、LLMの出力を定量的・定性的に採点し、変更が品質にどう影響するかを継続的に測定する仕組みの総称です。手法は大きく3種類に分かれ、実務ではこれらを組み合わせて運用します。
| 評価手法 | 概要 | 強み | 限界 |
|---|---|---|---|
| オフライン評価 | ゴールデンデータセット（期待する入出力の対）に対してバッチで採点する | デプロイ前に実施でき、変更前後の比較が容易 | データセットが実際のユーザー分布から外れると精度が過大評価される |
| オンライン評価 | 本番トラフィックの一部をサンプリングし、リアルタイムまたは準リアルタイムで採点する | 実際のユーザー入力に対する品質を継続的に把握できる | 採点自体にコストがかかり、遅延や採点ロジックの整備が必要 |
| 人手評価 | 人間の評価者（社内担当者・専門家・クラウドワーカー）が出力を直接採点する | 自動採点が苦手な「文脈への適切さ」「トーン」等を評価できる | コストと時間がかかり、評価者間のブレ（inter-rater reliability）の管理が必要 |
自動採点の実装方式にも幅があります。文字列マッチングやルールベースの検証（出力に禁止語が含まれていないか等）は最も安価ですが評価できる範囲が狭く、別のLLMを評価者として使う「LLM-as-a-judge」方式は柔軲な評価が可能な一方、評価者モデル自体の偏りやコストが新たな論点になります。成熟した組織は、タスクの性質に応じてこれらを併用しています。
自社データ活用の選択肢としてよく比較されるLLMをプロダクトに組み込む際のアーキテクチャ判断軸の議論とも関係しますが、どの手法を選んでも、変更の効果を測る評価データセットがなければ「感覚的に良くなった」という主観的な判断しかできません。evalsは、AIプロダクト開発における「テストコード」に相当する基盤資産です。
評価体制の成熟度モデル：評価データなし→定期評価→リリースゲート
evalsの整備状況は組織によって大きく異なります。DDの実務では、以下の3段階の成熟度モデルに当てはめて位置づけを確認すると、議論が整理されます。
Stage 0（評価データなし）：多くのAIプロダクトはここから始まります。プロトタイプ段階で目視確認のみで進める運用自体は不自然ではありませんが、有料課金が始まった後もこの段階に留まっている場合はリスクとして扱うべきです。バイブコーディングのプロトタイプを製品化する議論と同様に、「動く」ことと「品質を保証できる」ことの間には距離があります。
Stage 1（定期評価）：ゴールデンデータセットを整備し、モデルやプロンプトの変更後に評価スコアの推移を記録する段階です。多くの組織はここで足踏みします。評価はしているが、その結果がリリース判断に直結していない——つまり「評価はあるが機能していない」状態です。少人数チームの品質ゲートの議論で指摘される「仕組みを増やすことと機能させることは別の問題」という論点は、evalsでも同様に当てはまります。
Stage 2（リリースゲート）：評価パイプラインをCIに組み込み、スコアが閾値を下回った変更は自動的にブロックする段階です。さらに本番でのユーザーフィードバック（低評価・訂正依頼等）を評価データセットに継続的に還流させる仕組みまで到達すると、evalsは品質保証の仕組みとして完成します。
DDで確認すべき質問と証跡
evalsの成熟度を口頭のヒアリングだけで判定すると、「評価しています」という回答の実態を見誤ります。以下の質問と、それぞれに紐づく証跡を確認することで、Stage 0〜2のどこに位置するかを客観的に判定できます。
| 確認する質問 | 求める証跡 | 見るべきポイント |
|---|---|---|
| ゴールデンデータセットは存在するか | データセットの実物（件数・カバー範囲） | 数十件程度では代表性が不足する可能性が高い |
| データセットは誰がいつ更新したか | 更新履歴（Git・スプレッドシートの変更ログ） | 直近半年更新がなければ形骸化のシグナル |
| 評価は誰が・どの頻度で実行しているか | 評価実行のログ・Slack通知・ダッシュボード | 「思い出したときに実行」は定期評価にあたらない |
| モデル/プロンプト変更前後のスコア比較記録はあるか | 変更履歴とスコアの対応表 | 記録がなければ回帰を検知できていない可能性が高い |
| 評価に落ちた変更をブロックした実例はあるか | CIログ・デプロイの差し戻し記録 | 「ブロックした実績がゼロ」は閾値が緩すぎるか運用されていない兆候 |
| 本番のネガティブフィードバックはどこに集約されるか | フィードバック収集の仕組みとデータセットへの反映プロセス | 集約先が個人のメモやSlackスレッドのみなら組織知にならない |
これらの証跡を確認する際の判断基準は、AI時代の技術DDは何が変わるかで挙げた「評価系（Eval）の存在」という論点をさらに深掘りする位置づけです。特に重要度が高いのは、評価に落ちた変更を実際にブロックした実例があるかという質問です。評価パイプラインの存在自体は多くの組織が「ある」と回答しますが、実際に機能を止めた経験があるかどうかで、Stage 1とStage 2の差が明確になります。
評価体制が競合優位性になる条件
evalsの整備は品質保証だけの論点ではありません。特定の条件下では、競合優位性の源泉としても機能します。
ドメイン特化の評価基準を持っている場合：汎用的なベンチマークではなく、自社のユースケースに特化した評価基準（例：医療分野での禁忌表現の検出、金融分野での数値の正確性検証）を構築している組織は、汎用LLMをそのまま使う競合に対して、品質面での差別化を主張できます。
評価データセットが本番フィードバックで継続的に太っている場合：ユーザーからの訂正・低評価が評価データセットに構造的に還流する仕組みがある組織は、時間が経つほど評価の精度が高まります。これはデータ資産の蓄積による優位性であり、後発企業が短期間で模倣しにくい構造です。
評価コストそのものが最適化されている場合：LLM-as-a-judgeのようなコストのかかる評価手法を、サンプリング戦略やキャッシュ設計によって効率化している組織は、評価の頻度を上げられる分、リリースサイクルを短縮できます。評価体制は品質保証であると同時に、開発速度のボトルネックにもなり得るため、このコスト構造まで見ておくと評価の深さが変わります。
一方で、評価基準が汎用ベンチマーク（公開されている標準的な精度指標）に留まっている場合は、模倣可能性が高く、競合優位性としては弱いと判断すべきです。DDの場面では「evalsがあるかどうか」だけでなく、「そのevalsは競合が容易に再現できるものか」まで踏み込んで評価する視点が有効です。
まとめ
LLMプロダクトの品質は、確率的な出力と一意でない正解という性質上、従来の単体テストでは保証できません。evals（オフライン評価・オンライン評価・人手評価）の整備状況を、評価データなし→定期評価→リリースゲートという成熟度モデルに当てはめて確認することが、AIプロダクトの技術DDにおける実務的な評価軸になります。
DDでは「evalsがあるか」という二択の質問ではなく、評価に落ちた変更を実際にブロックした実例があるか、本番フィードバックがデータセットに還流する仕組みがあるかまで踏み込むことで、口頭の説明と実態のギャップを見抜けます。またドメイン特化の評価基準や本番フィードバックの継続的な還流は、模倣困難な競合優位性としても評価できます。
投資家として技術DDの評価軸にevalsを組み込みたい場合は投資家向けTiedPro、スタートアップとして評価体制の構築を伴走支援してほしい場合はスタートアップ向けTiedProをご覧ください。
よくある質問
Q. evalsとテストコード（単体テスト・結合テスト）はどう違いますか？
テストコードは「入力に対する期待する出力」が一意に定まる場合に、完全一致または明確なルールで正誤を判定します。evalsはLLMの出力のように「正解」が一意に定まらないタスクに対して、採点基準（ルールベース・LLM-as-a-judge・人手）を使って品質を定量化する仕組みです。両者は排他的ではなく、決定的な部分はテストコードで、確率的な部分はevalsで担保するのが実務上の組み合わせです。
Q. 小規模なスタートアップでもリリースゲート（Stage 2）まで整備すべきですか？
事業のフェーズと本番稼働のインパクトによります。PMF検証段階でリリース頻度が高い場合、フルのリリースゲートは開発速度を落とす可能性があります。まずはゴールデンデータセット10〜20件程度の定期評価（Stage 1）から始め、有料課金や高感度ドメイン（医療・金融等）での本番稼働が始まった時点でリリースゲートへ移行するのが現実的な順序です。
Q. evalsの評価データセットは何件あれば十分ですか？
タスクの複雑さに依存するため一概には言えませんが、判断材料としては「本番で実際に起きた失敗パターンをどの程度カバーしているか」が件数の絶対値より重要です。件数が少なくても、直近のインシデントやユーザーからのネガティブフィードバックが継続的に反映されているデータセットは、件数が多くても更新されていないデータセットより実用的な評価精度を持ちます。