テスト・品質保証

出力が毎回同じでない前提での品質保証

従来のソフトウェアテストは「同じ入力に同じ出力が返る」ことを前提に組み立てられています。生成AIを含む仕組みでは、この前提が成り立ちません。

したがって「1回動いたか」ではなく「複数回の出力が許容範囲に収まるか」を判定する形に変える必要があります。本章はその方法を扱います。第13章(アーキテクチャ)の延長であり、第24章(継続的な改善)の前提になります。

検証セットを作る ― すべての土台

本章の内容は、すべて検証セットの存在を前提にします。検証セットとは、業務の実データと、期待する出力の組を集めたものです。

作り方

1. 実際の業務データを集める ― 過去に処理した実データを50〜200件。作った例題では意味がありません。
2. 期待する出力を人が書く ― 正解が一意でない場合は、許容できる範囲を書きます。
3. 難しい例を意図的に入れる ― 例外パターン、判断が分かれるもの、過去に間違えたもの。
4. 件数の配分を実態に合わせる ― 頻出パターンが8割なら、検証セットも同じ比率にします。
5. 更新の担当を決める ― 新しい例外が見つかったら追加します。

作成には数日かかります。しかしこの投資は複数の場面で回収されます。

• モデル選定時の比較(第3章)
• プロンプト変更時の影響確認
• モデル更新時の再検証(第10章)
• 継続的な品質監視(第24章)
• ベンダーへの受け入れ条件の定義(第9・17章)

検証セットがないと、これらすべてが感覚的な判断になります。逆に言えば、検証セットを作ることが品質保証の入口です。

3種類の正解の形

用途によって、正解の定義が変わります。

2番目の場合、実務的な方法は必須要素の一覧を作ることです。「この要約には、決定事項・担当者・期限が含まれていること」という形にすれば、含有の確認は自動化できます。文章の良さは測れませんが、必要な情報が落ちていないかは測れます。

AI出力の精度評価

判定を伴う処理の評価

抽出・分類では、適合率と再現率で測ります(第1章)。実務では次の形で集計します。

• 項目ごとの正解率(金額は99%、支払先は92%、備考は70%)
• 1件のうち1項目でも誤りがある割合(実務ではこれが確認工数を決めます)
• 誤りの種類別の件数(読み取り不可、誤読、項目の取り違え)

2番目の指標が重要です。項目ごとの精度が高くても、1件のうちどれか1つが誤っていれば、その1件は人が確認することになります。確認工数を見積もるには、件単位の完全正解率が必要です。

生成処理の評価

文章生成では、次の3層で評価します。

1. 形式 ― 指定した構造・項目・長さに収まっているか。自動判定できます。
2. 内容の正しさ ― 事実誤り、数値の誤り、指示の無視。必須要素の含有確認と、原典との突き合わせ。
3. 質 ― 読みやすさ、適切さ。人の評価が必要です。

1と2を自動化し、3をサンプルで人が見る、という組み合わせが現実的です。1と2を自動化しないまま人が全件見る運用は、件数が増えると必ず崩れます。

複数回実行して振れ幅を見る

出力が毎回同じでないため、1回の結果では判定できません。実務的な方法は、同じ入力で3〜5回実行し、結果の振れ幅を見ることです。

• すべて許容範囲 → 安定している
• 一部が範囲外 → プロンプトの明確化、または確認工程の追加が必要
• 毎回大きく違う → 用途に対してモデルまたは指示が適していない

この確認は導入前に必ず行ってください。「1回試して良かった」だけで判断すると、稼働後に振れ幅の問題が出ます。

A/Bテストと継続的評価

比較の設計

プロンプト、モデル、参照データの構成を変える際は、変更前後を比較します。注意点は一度に1つだけ変えることです。複数を同時に変えると、どれが効いたか分かりません。

実務的な手順は次のとおりです。

1. 検証セットで変更前の結果を記録する(基準線)
2. 1箇所だけ変更する
3. 同じ検証セットで実行し、結果を比較する
4. 改善した項目と悪化した項目の両方を確認する
5. 全体として改善しているかを判定する

4番目が重要です。プロンプトの調整では、ある項目を改善する変更が別の項目を悪化させることが頻繁に起きます。検証セット全体で見なければ気づけません。

本番環境での比較

利用者に対して2つの構成を並行提供し、実際の結果を比較する方法です。実施できる条件があります。

• 件数が十分にある(少数では差が判定できません)
• 結果の良否を記録できる(人による修正の記録が使えます)
• 利用者に不利益が生じない範囲である

件数が少ない業務では、検証セットでの比較にとどめるのが現実的です。

回帰テスト ― 劣化を検知する

AIを含む仕組みで最も重要な仕組みです。理由は第13章で述べたとおり、コードを変えていないのに品質が変わることがあるためです。

変化の原因

• モデルの更新 ― 提供元の更新により出力の傾向が変わる(第10章)
• 参照データの変化 ― 文書が更新・追加され、検索結果が変わる
• 入力データの傾向の変化 ― 業務の変化により、来るデータの性質が変わる
• プロンプトの変更 ― 別の担当者が調整した
• 設定値の変更 ― 生成パラメータや閾値の変更

実務的な回帰テストの運用

1. 検証セットを定期的に流す ― 週1回または月1回。自動実行にします。
2. 結果を記録し、前回と比較する ― 正解率の推移を残します。
3. 閾値を決めて通知する ― 正解率が一定以上下がったら通知します。
4. 変更のたびに実行する ― プロンプト・モデル・参照データを変えたときは必ず。
5. 費用も記録する ― 1件あたりの費用の変化も、同時に把握できます。

この仕組みの実装は、それほど大きなものではありません。検証セットとスクリプト1本で成立します。それにもかかわらず、これがないと品質の劣化に気づく手段が「利用者からの申告」だけになります。

人によるレビュー体制(Human-in-the-loop)

人の確認を工程に組み込む設計です。形骸化させないための要点を扱います。

確認の3つの型

第4章で示した型を、品質保証の観点から再掲します。

形骸化を防ぐ

確認作業は、続けているうちに形式的になります。これは意志の問題ではなく、人間の注意の性質です。防ぐ方法は記録を残すことです。

• 確認したことだけでなく、修正の内容を記録する ― 「確認済み」のチェックだけでは、見たかどうかは分かりません。
• 修正率を月次で見る ― 急に下がった場合、品質が上がったのか確認が形骸化したのかを調べます。
• 意図的に誤りを混ぜて検知率を測る ― 検査工程の実効性を測る方法です。実施する場合は事前に周知します。
• 確認の時間を業務時間として確保する ― 時間がなければ形式的になります(第8章)。

確認する人の負荷設計

見落とされやすい点です。確認作業は単調で、集中の維持が難しい作業です。次の配慮が実効性に効きます。

• 1回の確認件数に上限を設ける(連続して大量に確認させない)
• AIが着目した箇所を提示する(全体を読み直させない)
• 確信度が低い箇所を強調表示する
• 過去に誤りが多かった項目を優先的に表示する

品質基準と受け入れ条件の定義

外部に発注する場合も、社内で作る場合も、完成の判定基準が必要です。

「正常に動作すること」では機能しない

AI案件では、この定義は判定に使えません。出力が毎回変わる前提では、単発の動作確認が合否の判断にならないためです。

件数で定義する

実務で機能する定義の形を示します。

• 「実データ100件を処理し、人の修正が必要な件数が10件以下」
• 「金額項目の完全一致率が99%以上、その他の項目が90%以上」
• 「必須要素(決定事項・担当者・期限)の含有率が95%以上」
• 「同じ入力で5回実行し、すべてが許容範囲に収まる」
• 「処理時間が1件あたり30秒以内、費用が1件あたり○円以内」

これらの形であれば、双方が同じ基準で判定できます。使用する実データと検証セットは、発注側が用意します。ベンダーが用意したデータでの結果は、受け入れ判定には使えません。

受け入れ条件に含める非機能項目

精度以外に、条件として明記すべき項目を挙げます(第11章の8項目と対応します)。

1. 異常系の動作(通信断、想定外入力、二重実行)
2. 認証と権限の設計
3. ログの記録項目(第13章)
4. 費用の上限管理
5. 設計資料と運用手順書の納品
6. 検証セットと回帰テストの仕組みの引き渡し

6番目を条件に含めておくと、稼働後の品質監視を自社で継続できます。これを引き渡してもらえないと、モデル更新のたびにベンダーに依頼することになります。

品質保証の最小構成

大掛かりな体制は不要です。次の4点があれば、品質保証は成立します。

1. 検証セット(実データ50〜200件と期待出力)
2. それを流すスクリプト(正解率と費用を出力する)
3. 定期実行と結果の記録(週1回または月1回)
4. 人による修正の記録(品質の実測値)

この4点で、モデル更新の検知、プロンプト変更の影響確認、品質の推移把握、受け入れ判定のすべてが可能になります。逆に、この4点がない状態では、品質について語れることが何もありません。