ブログ一覧

AIプロダクトの品質をどう測る？受け入れ基準・評価セット・本番監視のつなぎ方

2026年10月26日 · 約12分で読めます

回答の平均点が上がっても、確認の手間や重大な誤りが増えれば業務は改善しません。問い合わせ対応AIを例に、期待結果の合意、業務全体の指標、LLM評価、公開条件、構成の版管理、本番の業務結果までを6件のTipsから解説します。

AIプロダクトの品質とは？まず業務が終わる条件を決める

生成AIの回答は自然なのに、現場では確認や手直しが多くて使い続けられない。こうした問題を扱うには、回答の正しさに加え、利用者が仕事を終えられるか、失敗から戻れるか、継続できる時間と費用かを確かめる必要があります。

この記事では、問い合わせを要約し、社内の手順から回答案を作る架空のサポートAIを考えます。担当者が確認して送信し、必要な案件は専門窓口へ引き継ぎます。「完了」は案件ごとに合意した条件を満たし、解決または引き継ぎ先での処理終了を確認できた状態です。回答案が出ただけでは完了にしません。

受け入れ基準：正答・確認・保留・引き継ぎを事例にする

受け入れ基準は、利用者の必要を満たす結果になったかを判断する条件です。GOV.UKのService Manualも、必要を満たしたかを確認する結果の一覧として説明しています。サポートAIなら「親切に答える」を、入力、利用者権限、参照手順の版、期待する動作、判定理由に分解します。

担当者同士で期待結果が割れたら、適用する手順や前提を業務責任者と確かめます。人数の多い側を正解にするだけでは、前提の違いが残ります。判断を決められない場合は、AIが確認する情報と、判断を引き受ける人を決めます。

保留や引き継ぎも、期待する動作なら評価上は成功になり得ます。その成功と業務の完了は別に集計します。何でも保留する仕組みが高品質に見えないよう、誤案内、不要な保留、最終的な完了率を合わせて見ます。

品質指標：生成・確認・修正を含む業務全体を測る

「AIが速く答えても、確認と手直しが増えたら業務は速くならない」というTipの計算を使います。以前は1件10分。導入後、人が下書きに2分、確認に5分、修正に4分使うなら、作業時間は2＋5＋4＝11分です。同じ対象範囲と品質なら1分増えています。この2分はAIの推論時間ではなく、人の下書き作業の時間です。

GOV.UKは、利用者の一連の行動を通した完了率と所要時間の計測を説明しています。AIでも、使った人の成功例だけを抜き出すと、難しい案件を人へ回した結果を見落とします。導入前後で対象や難しさが変わっていれば、単純な差を導入の効果とは断定できません。

LLM評価セット：変更前後を同じ条件で比較する

評価セットは、入力と合格基準を組にした問題集です。合意した通常・例外・保留の事例に、許可された実例と境界の入力を加え、用途、言語、権限、資料の版を付けます。調整用と最終確認用の事例は分けます。確認用の失敗を使って修正したら、その事例は回帰確認に残し、必要に応じて未使用の事例も補います。

「もっと短く」と指示を変えた場面を考えます。LLM評価のTipでは、300件全体の合格率が86%から88%へ上がる一方、返金の問い合わせは92%から71%へ落ちています。説明のため、返金100件、その他200件という内訳をこの記事で仮定すると、次の件数で同じ数字を再現できます。

全体は6件増えても、返金では21件減っています。金額や注文番号が省かれたなら、その失敗を直して全カテゴリを再評価します。カテゴリの母数と実際の失敗例を公開判断に添えます。これは1回の仮定の結果です。2ポイントの差が安定した改善かを確かめるには、同じ事例で複数回実行し、実行ごとの揺れと比較します。

指示文を比べるなら、モデル、資料、検索設定、採点基準などをそろえて指示文を変えます。構成をまとめて変える場合も同じ事例で新旧を評価できますが、どの要素が差の原因かは切り分けが必要です。評価件数やカテゴリ構成が変わった集計値を、そのまま前回と比較しないようにします。

採点方法：コード・人・LLM-as-a-Judgeを組み合わせる

Anthropicは、目的に応じてコード、モデル、人の採点を組み合わせる方法を説明しています。LLM-as-a-Judgeの原論文も、回答の順序や長さなどへの偏りを報告しています。採点基準と判定理由を明示し、業務担当者が確認した事例で照合します。同じモデルを採点に使うかどうかにかかわらず、この照合は必要です。採点モデルや指示の変更も記録して検証します。

品質ゲート：平均点で相殺できない公開条件を置く

品質ゲートは、公開や構成の切り替え前に満たす条件です。業務責任者と許容できない失敗を決め、合否を止める必須条件と、比較のための品質スコアを分けます。以下はこのサポートAI向けの設計例で、すべてのAIプロダクトに共通の数値基準ではありません。

返金カテゴリの基準を満たさない版は、この業務では公開できません。文体の改善で埋め合わせず、必須情報が抜けた原因を直します。一方、根拠不足で正しく保留した事例を、回答しなかったという理由だけで誤答にしないことも必要です。合否と、保留後も含む業務完了の計測をつなぎます。

版管理：評価した構成と公開した構成を結ぶ

同じモデルでも、指示、文書の分割、索引、検索、ツールの仕様が変われば結果は変わります。Google Cloudの運用ガイドは、プロンプト、構成要素、モデルの版と評価結果を記録するよう説明しています。モデル名に加え、公開版を構成する識別情報をリリースマニフェストとしてまとめます。

{
  "release": "support-ai-r12",
  "model": "M2",
  "prompt": "P7",
  "index": "I4",
  "retrieval": "R3",
  "tools": "T2",
  "evaluationSet": "E5",
  "grader": "G3",
  "application": "A8"
}

本番の処理記録から公開版へたどれるようにし、モデルIDの実体と利用可能な期間、検索データの版、評価結果も参照できるようにします。記録は比較に役立ちますが、同じ文章の再生成を保証しません。戻す場合もツールとの互換性、現在の権限・削除状態を確認します。削除済み文書が残る古い索引を、そのまま復元してはいけません。

本番監視：HTTP成功から業務結果まで追う

HTTP 200が返り、回答に「引き継ぎました」とあっても、実際の受付が失敗している可能性があります。OpenTelemetryでは、作業単位をspanとして記録し、関連する処理をtraceとして結びます。この考え方を使い、検索・生成・検証・外部操作と、その後の業務結果を関連付けます。

生成の成功、外部窓口の受付、業務完了を別の状態にします。要求ID、公開版、参照元の識別子、段階ごとの時間と成否、再試行数、利用量、外部操作の結果を必要な範囲で結びます。後日完了する案件は永続的な業務IDから追跡します。モデルが述べた理由は、実際に操作が成功した証拠にはなりません。

OWASPのLogging Cheat Sheetは、アクセストークンや機密情報などを通常のログへ直接記録しないよう説明しています。本文の全量保存を前提にせず、必要な情報、閲覧権限、保持期間を決めます。文書IDや業務IDも機密になり得ます。内容が必要な診断では、許可した範囲の追加収集を別に設計します。

新しい失敗では、入力条件、構成の版、実際の結果を照合します。利用許可と機密情報の扱いを確認した事例を評価へ戻し、修正が他カテゴリを壊していないか再検証します。回答文への高評価に加え、再問い合わせ、手直し、引き継ぎ先の負担も確かめます。

最初の一歩：1つの業務で品質の合意と検証を回す

1. 対象の業務と完了条件を決め、通常・例外・保留の入力と期待結果を業務担当者とそろえる。
2. 現行の完了率、人の作業時間、経過時間、誤り、費用を測る。AI未利用と引き継ぎも追う。
3. 調整用と確認用の事例を分け、コード・人・LLMの採点を照合し、同じ条件で変更前後を比較する。
4. カテゴリ別の母数と失敗例を見て、必須条件で公開を判断する。評価した構成と戻す条件を記録する。
5. 限定した範囲で使い、業務結果と負担を確認する。本番で得た失敗を次の評価に加える。

受け入れ基準・評価・運用を確認する一次資料

• GOV.UK Service Manual — Writing user stories: acceptance criteria
• GOV.UK Service Manual — Measuring the success of your service
• Anthropic — Demystifying evals for AI agents
• Zheng et al. — Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena
• Google Cloud — Deploy and operate generative AI applications
• OpenTelemetry — Traces
• OWASP — Logging Cheat Sheet