省略の理由は、たいてい正しく聞こえる
検証工程が省かれるとき、その理由はたいてい正しく聞こえます。「AIなので従来のテストは当てはまらない」「実データは用意できない」。どれも部分的には本当です。
省略の理由として挙げられる説明は、たいてい部分的に正しいものです。「AIの出力は毎回変わるから、従来のテストは意味がない」という指摘は事実です。問題は、そこから「だから検証しない」という結論が導かれることです。正しい結論は「だから検証の方法を変える」です。
型1 ― 「AIだから品質保証は不要」という詭弁
この主張は、次の形で現れます。それぞれ、正しい部分と成立しない部分を分けます。
| 主張 | 正しい部分 | 成立しない部分 |
|---|---|---|
| 「出力が毎回変わるのでテストできない」 | 同じ入力に同じ出力を期待するテストは使えない | 複数回の出力が許容範囲に収まるかは判定できる |
| 「正解が一意に決まらない」 | 要約や文章生成では正解は一意でない | 必須要素の含有は判定でき、自動化できる |
| 「AIの判断は説明できない」 | モデル内部の仕組みは説明が難しい | 入力・出典・判断者は記録でき、説明できる |
| 「精度は使うほど上がる」 | データを追加すれば改善する場合がある | 自動的には上がらない。何を追加するか、誰が作業するかが必要 |
| 「人が確認するので品質は担保される」 | 確認工程は必要 | 確認は続けるうちに形式的になる。記録がなければ検知できない |
4行目の確認が実務では有効です。「何をどう追加すると精度が上がるのですか。その作業は誰がしますか」と聞くと、改善の計画があるかが分かります。答えが「使っていくうちに」で止まる場合、改善の仕組みは存在しません。
型2 ― 人によるレビュー体制を形だけにする
確認工程を置いていても、実質的に機能しない状態があります。表の網羅版 第16章「AIガバナンス体制の構築」で扱った「根拠が示されない出力の確認を担当者に負わせる設計」がその一つです。
形だけになる条件を挙げます。
- 判断に必要な情報が提示されない ― 出典、根拠、確信度が表示されず、確認のしようがない。
- 確認の時間が確保されていない ― 通常業務に上乗せされ、実質的に目を通すだけになる。
- 確認の記録が残らない ― 「確認済み」のチェックだけで、修正の内容が残らない。
- 1回の確認件数が多すぎる ― 連続して大量に確認させると、集中が維持できない。
- 確認結果が使われない ― 修正内容が改善に反映されないため、確認の意味が感じられなくなる。
3番目が最も重要です。修正の内容が記録されていないと、確認が形骸化したことを検知できません。逆に記録があれば、修正率の推移から形骸化の兆候が見えます(表の第14章)。
形骸化の検知方法
- 修正率を月次で見る。急に下がった場合、品質が上がったのか確認が形骸化したのかを調べる。
- 確認にかかる時間を記録する。極端に短くなっていれば、目を通すだけになっている可能性がある。
- 抜き取り検査を行う場合は、検査件数と発見件数の両方を記録する。
型3 ― 回帰テストを省略し、劣化に気づけない運用
本書で最も影響が大きい省略です。表の第13章・第14章で述べたとおり、AIを含む仕組みではコードを変えていないのに品質が変わることがあります。
変化の原因は複数あります。
- 提供元によるモデルの更新(同じモデル名のままの場合もあります)
- 参照データの更新・追加による検索結果の変化
- 入力データの傾向の変化
- 別の担当者によるプロンプトの調整
- 生成パラメータや閾値の変更
これらのいずれが起きても、稼働状況の監視では検知できません。検知できるのは検証セットの定期実行だけです。
省略される理由
回帰テストの実装は大きなものではありません。検証セットとスクリプト1本で成立します。それにもかかわらず省略される理由を挙げます。
- 検証セットがない ― これが最大の理由。作成に数日かかるため、着手されない。
- 納品物に含まれていない ― ベンダーが検収時に作ったものが引き渡されていない。
- 必要性が伝わっていない ― 「動いているのに何を確認するのか」という認識。
- 担当者が決まっていない ― 稼働後の運用の役割が空欄になっている(表の網羅版 第8章「組織・人材・チェンジマネジメント」)。
受け入れ条件に「検証セットと回帰テストの仕組みの引き渡し」が含まれていない場合、モデル更新のたびにベンダーへの依頼が必要になります。加えて、検収時にベンダーが作った実データと期待出力の組が残っていないと、稼働後に品質が悪化したことを客観的に示せません。この状態では、悪化の指摘に対して「元からその水準だった」という応答が可能になり、議論が主観の対立になります。
型4 ― 検証に使うデータをベンダーが用意する
受け入れ判定に使う実データと期待出力を、ベンダー側が用意する形です。この形では、判定が実質的に自己評価になります。
問題になる点を挙げます。
- 難しい例が含まれない(例外パターン、判断が分かれるもの)
- 件数の配分が実態と違う(頻出パターンの比率が実際と異なる)
- 期待出力の水準が自社の業務要件と一致しない
- 自社が保有していないため、稼働後の回帰テストに使えない
対処は明確です。検証に使う実データと期待出力は発注側が用意します(表の第14章)。作成には数日かかりますが、この投資は複数の場面で回収されます。モデル選定、変更の影響確認、更新の検知、受け入れ判定、そして移行時の品質比較(第10章)。
型5 ― 「精度○%」の測り方を確認しない
精度の数値が示されても、測り方が確認されなければ判断に使えません。確認すべき点を挙げます。
| 確認する点 | なぜ重要か |
|---|---|
| 何を正解としたか | 正解の定義が業務要件と一致しなければ意味がない |
| 項目ごとか、件単位の完全正解率か | 確認工数を決めるのは件単位の完全正解率 |
| 使ったデータの件数と出所 | 手作業で整えた少数のデータでは再現性が不明 |
| 難しい例が含まれるか | 頻出パターンだけでは実運用の精度を示さない |
| 複数回実行した結果か | 1回の結果では振れ幅が分からない |
| いつ測ったか | モデル更新後に再測定されているか |
2行目が実務では効きます。各項目の正解率が高い場合でも、1件の中に誤りが1つあれば、その件は人の確認に回ります。確認工数を見積もるには件単位の完全正解率が必要です。
二年目の一月末、朝凪精機に受注入力の仕組みを納品したアストラム・データは、受け入れ検査を合格としました。受注メール200件を1回ずつ流し、業務課の修正が必要なのは8件(基準は20件以下)。ただし200件は、アストラムが作ったものでした。情報システム課の森が自社の過去1年分から実際の比率のまま200件を抜いて流すと、修正が必要なのは41件でした。アストラムの200件には、ファクスのPDF、分納、旧品番、訂正のメールといった例外が入っていなかったのです。検査に使うデータを朝凪が用意し、例外を含む実際の配分で流したことで、41件の半分が分納の納期と訂正メールだと分かり、受け入れ前に必要な調整が明確になりました。この200件は、その後の月次報告で精度を毎月測る検証セットにもそのまま使われました。
この場面は網羅物語之巻 第11章「テストは本番で」に出てきます。
省略させないための確認項目
この章の内容を、発注と運用の両面で使える形にまとめます。
発注時
- 受け入れ条件を件数で定義する(「実データ○件で修正必要が○件以下」)
- 検証に使う実データと期待出力は自社が用意する
- 納品物に検証セットと回帰テストの仕組みを含める
- 精度の数値については、測り方(前掲の6点)を確認する
運用時
- 検証セットを週1回または月1回、自動で実行する
- 結果を時系列で記録し、閾値を超えた低下で通知する
- 人による修正の内容を記録し、修正率を月次で見る
- 修正内容を検証セットに追加していく
運用の4番目が、時間とともに効果を増します。実際に誤っていた例が蓄積されるほど、検証セットの品質が上がります(表の網羅版 第24章「継続的な検証・改善サイクル」)。