生成AI機能をリリースしたあと、「気づいたら回答の質が落ちていた」「プロンプトを改善したつもりが、別のケースで悪化していた」——こうした事故が起きるのは、生成AIが出力の変わる（非決定的な）機能だからです。同じ入力でも出力が揺れるため、従来の「入力Aなら必ず出力B」というテストだけでは品質を守りきれません。
だからこそ、生成AI機能には**評価（どれだけ良いかを測る）と監視（本番で劣化を検知する）**の仕組みが要ります。とはいえ、最初から大がかりな基盤は不要です。この記事では、評価・監視をどこから始めるかを手順で解説します。プロンプト改善の土台はプロンプト設計の基本と改善の進め方、本番化でつまずく全体像は生成AIのPoCが本番に上がらない理由もあわせてご覧ください。
なお筆者・馬込は、生成AI機能の実装から精度検証までを担い、品質を見ながら改善を回してきた経験があります。本記事はその実務目線でまとめています。
結論：まず「評価データ」を作る。話はそこから
評価も監視も、出発点は同じで**「良し悪しを判断する基準（評価データ）」**です。基準がなければ、改善したかどうかも、劣化したかどうかも分かりません。①評価データを作る → ②リリース前に評価する → ③本番を監視する、の順で始めます。
手順1：代表的な入力と「期待する出力」を集める
まず、実際に起きる代表的な入力と、それに対する「良い出力（あるいは満たすべき条件）」をセットで集めます。これが評価データになります。
- ユーザーの典型的な質問・入力を20〜50件ほど集める（多すぎなくてよい）
- 各入力に「期待する回答」または「満たすべき条件」を添える
- 正解が一つに決まらない場合は、「含むべき要素」「してはいけないこと」を条件として書く
完璧な正解を用意する必要はありません。「この条件を満たしていれば合格」という基準があれば、評価は回り始めます。
手順2：リリース前に評価し、変更の前後を比較する
評価データができたら、プロンプトやモデルを変更するたびに、この評価データで前後を比較します。改善が本当に改善かを、感覚ではなく基準で確かめる工程です。
- 変更前後で、評価データの合格率がどう変わったかを見る
- 一部だけ良くなって別が悪化していないか（デグレード）を確認する
- 判定は人手でもよいが、条件が明確なものはLLM自身に採点させる方法（LLM-as-a-judge）もある
ここを飛ばすと、「あるケースは良くなったが別のケースが壊れた」という見えない劣化に気づけません。全体で良くなったかを基準で確認します。
手順3：本番の入出力を記録し、劣化を監視する
リリース後は、本番の入力・出力・（あれば）ユーザーの反応を記録し、継続的に見られるようにします。生成AIは、モデル更新や利用傾向の変化で後から品質が動くためです。
| 監視する対象 | 見るポイント |
|---|---|
| 出力ログ | 想定外の形式・空回答・エラー率 |
| ユーザー反応 | 低評価・再質問・離脱の傾向 |
| コスト・遅延 | トークン量・応答時間の急変 |
すべてを自動で判定できなくても、まずは記録して振り返れる状態にするだけで、劣化に早く気づけます。記録がないと、問題が起きても原因を追えません。
手順4：モデルやプロンプトを変えるときの手順を決めておく
生成AI機能で品質が落ちる場面は、たいてい何かを変えたときです。モデルのバージョンを上げた、プロンプトを直した、参照文書を差し替えた——こうした変更のたびに、品質は静かに動きます。だからこそ、変更の手順をあらかじめ決めておくことが、事故を防ぐ現実的な策になります。
決めておくべきは、次の3点です。
| 決めること | 内容 |
|---|---|
| 変更前に何をするか | 評価データで現状のスコアを記録（比較の基準点） |
| 変更後に何を確認するか | 同じ評価データで前後比較。全体が良くなったか、悪化がないか |
| 戻す条件 | どこまで悪化したら元に戻すかを、変更前に決めておく |
特に3つ目が抜けがちです。「戻す条件」を変更前に決めておかないと、悪化しても「もう少し調整すれば良くなるかも」と引きずり、その間ずっとユーザーに劣化した出力が届きます。先に線を引いておけば、迷わず戻せます。
もう一つ現実的なのが、モデル提供側の更新は自分たちの都合では止められないという点です。使っているモデルが更新されれば、こちらが何も変えていなくても出力は動きます。だからこそ、変更していない期間も評価データで定期的に確認しておくと、「いつの間にか劣化していた」を早期に捕まえられます。
よくある落とし穴
- 評価データを作らずに改善する：良くなったか分からず、感覚頼みになります。まず基準を作ります。
- 一部の改善だけ見てデグレードを見逃す：全体の合格率と、悪化がないかを確認します。
- 本番を記録していない：劣化に気づけず、原因も追えません。入出力を記録します。
- 最初から完璧な自動評価を目指す：着手が遅れます。手動評価＋記録から始めます。
- 「戻す条件」を決めずに変更する：悪化しても引きずり、その間ユーザーに劣化した出力が届きます。変更前に線を引いておきます。
よくある質問
Q. 評価はすべて自動化しないと意味がないですか？ A. いいえ。最初は人手の評価でも十分始められます。条件が明確な項目から徐々に自動化するのが現実的です。大事なのは「基準を持って前後を比較すること」で、自動化はその効率化にすぎません。
Q. LLMに採点させる方法（LLM-as-a-judge）は信頼できますか？ A. 条件が明確な判定では有効ですが、万能ではありません。採点用プロンプト自体の設計が必要で、重要な判断は人手の確認と併用します。まずは人手で基準を固め、安定した部分から採点を任せるのが安全です。
Q. 監視は何から始めればいいですか？ A. まず本番の入出力とエラー・空回答の記録からです。高度な品質スコアの前に、「想定外の出力がどれくらい出ているか」を見える化するだけで、多くの劣化に早く気づけます。
生成AI機能の品質は、①評価データを作る ②リリース前に前後を比較する ③本番を記録して監視する、という仕組みで守れます。出力が変わる機能だからこそ、一度のテストではなく、測り続ける・見続ける体制が要ります。まずは小さな評価データと記録から始めるのが出発点です。
自社プロダクトの生成AI機能の品質設計や運用の相談は、開発支援について相談するからお問い合わせください。