生成AIのテスト設計：評価と回帰防止手順

生成AIを業務へ組み込むと、同じ入力でも出力が少しずつ揺れるため、従来の画一的なテストだけでは品質を見切れません。その一方で、要約、分類、問い合わせ対応、RAG、エージェント実行などを本番運用する以上、期待した振る舞いを定義し、変更時に回帰を見逃さない仕組みは必須です。実際、OpenAIは生成AIを従来型ソフトウェアと同じ感覚でテストするのは不十分であり、評価を早い段階から継続的に設計する必要があると案内しています。さらに、Anthropicもエージェントは多段処理やツール利用が入るため、問題が本番で見つかる前に評価で可視化する重要性を強調しています。つまり、生成AIのテスト設計とは「正解を一つ当てる」作業ではなく、業務上許容できる品質水準を明文化し、変化に強い検証手順へ落とし込むことです。この記事では、期待出力の決め方から、自動評価と人手評価の使い分け、回帰防止のためのケース管理、継続改善につながる基盤づくりまでを、実務目線で整理します。

生成AIにテスト設計が必要な理由

生成AIにテスト設計が必要なのは、出力が非決定的である一方、業務システムとしては安定した品質が求められるからです。たとえば、社内ヘルプデスクの分類AIであれば、昨日は「アカウント管理」と判断した問い合わせを、今日のモデル更新後に「その他」と返すだけで、現場の振り分け工数が増えます。FAQ要約、議事録作成、メール草案のような一見軽い用途でも、言い回しの変化が承認漏れや誤案内につながることがあります。OpenAIは評価を“早く、頻繁に、タスクごとに”行うべきだと案内しており、単なる雰囲気評価ではなく、運用に近い入力分布で測ることを推奨しています。また、OWASPのLLMSVSも、LLMアプリはアーキテクチャ、運用、統合を含めて検証すべき対象だと整理しています。つまり、生成AIでは「動いたからOK」では不十分で、何を成功とみなすか、何が失敗か、どの変更が危険かを最初から決めておかないと、改善と改悪の区別ができません。テスト設計は品質保証のためだけでなく、モデル変更、プロンプト修正、RAG改善、ツール追加を安全に進めるための土台でもあります。

期待出力をどう定義するか

期待出力を定義するときは、まず「完全一致する理想解」を無理に一つへ固定しないことが重要です。生成AIでは、同じ要点を異なる表現で返しても業務上は十分合格という場面が多いためです。そこで実務では、出力そのものではなく、満たすべき条件を定義します。たとえば問い合わせ分類なら「ラベルが3種類のいずれか」「根拠が入力文に沿っている」「禁止ラベルを使わない」といった条件です。要約なら「重要事項が抜けない」「日付・数値が改変されない」「300字以内」「箇条書きを使わない」などに分解できます。Google Cloudも評価設計では、GROUNDING、SAFETY、INSTRUCTION_FOLLOWINGのように、品質を観点別に分けて測る考え方を示しています。さらに、エージェントでは最終回答だけでなく、必要なツールを正しく呼んだか、不要な手順が増えていないかという“過程”も期待値になります。つまり、期待出力は「文章例」だけでなく、業務要件、禁止事項、形式制約、根拠整合性、ツール挙動まで含めて定義するのが実務的です。まずは合否を左右する条件を3〜5個に絞り、必須条件と望ましい条件を分けると、評価と改善の両方が進めやすくなります。

自動評価と人手評価の組み合わせ

評価を実務で回すには、自動評価だけでも、人手評価だけでも足りません。まず自動評価は、分類の正解率、文字数、禁止語、JSON形式、関数呼び出しの有無、SQL実行結果など、機械的に判定できる条件に強いです。OpenAIも exact match、string match、function call accuracy、実行可能な評価などを回帰試験に有効な数値評価として挙げています。一方で、読みやすさ、自然さ、業務に合う丁寧さ、要約の過不足、根拠の妥当性のような項目は、人の基準に近づけた評価が必要です。ここで有効なのが LLM-as-a-Judge ですが、OpenAIは自動評価を人手評価と突き合わせて調整することを推奨しており、Google Cloudも固定ルーブリックやカスタムルーブリックを使って観点を明示する設計を示しています。さらに、Anthropicはエージェント評価で、最終回答だけでなく試行、トレース、環境の変化まで見る重要性を説明しています。つまり、実務ではルールベース評価で早く異常を拾い、LLM評価で品質を広く見て、人手評価で基準を校正する三層構成が現実的です。たとえば週次で100件を自動採点し、そのうち境界ケース20件だけ担当者がレビューすると、工数と信頼性のバランスを取りやすくなります。

回帰を見逃さないテストケース管理

回帰防止で重要なのは、テストケースを一度作って終わりにしないことです。OpenAIは「ログを残し、そこから良い評価ケースを採掘する」ことを勧めており、LangfuseやArizeも、本番や検証環境で見つかった失敗例をデータセット化して回帰テストへ戻す考え方を示しています。実務では、ゴールデンデータセットと回帰データセットを分けて管理すると整理しやすくなります。前者は理想的な代表ケースで、分類正解や模範回答があるものです。後者は、過去に誤分類した問い合わせ、数値を落とした要約、不要ツールを呼んだエージェント、口調が崩れた回答など、実際の失敗を再発防止用に蓄積したものです。さらに、ケースごとに「要約」「RAG」「ツール呼び出し」「高リスク」「社内文書」「英数字多め」などのタグを付けると、変更の影響範囲を見やすくなります。エージェントや多段会話では、最終出力だけでなくトレースや会話履歴をセットで保存するのも有効です。Google Cloudはエージェント評価で最終回答とtrajectoryの両方を測る設計を案内しており、OpenAIも trace grading により、ツール呼び出しや判断の流れを構造化して確認できると説明しています。つまり、回帰を防ぐには、代表例、失敗例、会話履歴、トレース、タグ、版管理を持つことが重要です。最低でも「変更前に通っていたケースは変更後も通るか」をCIや定期ジョブで回せる状態を目指したいところです。

継続改善につながる評価基盤の作り方

継続改善につながる評価基盤は、単なる採点ツールではなく、ログ収集、データセット更新、比較実験、可視化、レビュー運用までつながっていることが理想です。まず、開発段階からプロンプト、モデル名、バージョン、入力、出力、参照文書、ツール呼び出し、レイテンシ、失敗理由を記録します。次に、評価ジョブを定期実行し、バージョン間で pass rate、grounding、instruction following、コスト、レイテンシなどを比較します。OpenAIは評価を継続的なプロセスとして扱うこと、Anthropicは複数試行やハーネスで再現可能にすること、LangfuseやArizeはデータセットと実験を結びつけて改善履歴を残すことの重要性を示しています。実務では、たとえば「モデル変更時は100件の代表ケース＋20件の回帰ケースを自動実行」「閾値未達なら本番反映不可」「境界ケースは週1で担当者レビュー」といった運用ルールにすると機能しやすくなります。また、スコアだけを見るのではなく、落ちたケースをレビューして、期待値定義、プロンプト、検索条件、ツール説明文、UI文言のどこを直すべきかを振り返る仕組みが必要です。つまり、良い評価基盤とは、評価結果を眺めるだけでなく、改善アクションへ自然につながる導線を持つ基盤です。最初は表計算とJSONL管理でも構いませんが、ケース数が増えたら Langfuse、Arize Phoenix、W&B Weave などの観測・評価基盤を併用すると、比較と履歴管理がしやすくなります。

生成AIの品質は、モデルの性能だけで自然に安定するものではありません。だからこそ、期待出力を定義し、自動評価と人手評価を組み合わせ、失敗例を回帰テストへ戻し続ける仕組みが必要です。まずは小さな代表ケース集を作り、変更時に必ず比較実行するところから始めると、感覚ではなくデータで改善を進めやすくなります。