「テストでスコアが上がったから本番へ」──その短絡で現場が止まるのを何度も見てきました。本稿はPoC→AB→本番切替／ロールバックまで、会議で即答できる最小の実務ガイドを示します。キックオフ議事録、AB設計書、観測設計書、ロールバック手順書といった合意すべき成果物、主要KPIの算出式と計測窓、ABに必要な統計基準、即使える判定・ロールバック閾値を手に入れられます。
要点
勝敗は次の4軸で決まります：業務妥当性、信頼性・安全性、観測性・再現性、運用コスト・スループット。各軸に対して主要KPI（算出式・計測窓・閾値）をキックオフで合意すれば、判定は自動化でき、現場の判断ミスを減らせます。ChatGPTやClaudeのようなモデル選定やモデルタグ運用も、このフレームに沿って扱います。
スコア信仰を壊す：なぜ「正答率↑＝本番投入」は危険か
スコア改善は必要条件に過ぎません。テストデータが代表的でない、PDFテンプレート差やOCR崩れ、実運用でのプロンプト差などにより本番で誤応答が起きます。さらにログが不十分だと原因追跡や監査説明ができず、正答率だけでは死角を検出できません。
対策（必須ルール）：PoC成功条件に必須ログ（原文＋応答＋model_id＋チャネル）と重大誤答定義を入れ、「スコア改善のみでは承認不可」を初動で明文化します。
現場で迷う具体場面とよくある失敗
場面ごとに必須ログ・計測窓・代表的失敗と線引きを定め、観測設計書に落とします。主要な場面と要点は以下です。
問い合わせチャネル（チャット／メール）
- 必須ログ例：original_text（匿名化可）、user_id_hash、channel、timestamp、model_id、response_text、response_score、escalation_flag、session_id、response_label。
- KPI：Self-serve解決率 = 解決セッション数 / 全セッション数（集計窓：rolling7/30）。日次アラート・週次で目視50件。
- 失敗／線引き：属性ごとに最低サンプル目安100件〜（統計基準で調整）。ログ完全性＜70%は配信停止の判断材料。
画面表示（FAQ／選択肢）
- 必須ログ例：ui_state、display_text、click_path、screenshot_on_error。
- KPI：UI切断率 = 切れた表示件数 / 総表示件数（集計窓：日次/rolling7）。
- 線引き：全文表示されない応答は運用不可。UI切断率が0.5%超で即ロールバックを基準の一例とします。
PDF・帳票の情報抽出
- 必須ログ例：原画像、ocr_raw_output、ocr_score、extracted_fields、field_confidence、template_id、model_id。
- KPI：抽出F1（フィールド単位、rolling30日）。代表テンプレ3種以上で検証。
- 線引き：抽出F1＜0.85や必須フィールド欠落率＞15%は本番見送りの目安。
AB配信設計
- 必須ログ例：split_rule、assignment_history、exposure_ratio、attribute_distribution、sample_size_per_attribute、期間。
- チェック項目：配信開始直後に属性別カバレッジ確認。属性カバレッジ不足のスプリットは判定無効。
勝敗を決める4つの判断軸と実務で使える指標
承認は4軸のAND評価です。各指標は算出式・計測窓・閾値を事前合意します。
-
業務妥当性
指標：Self-serve解決率（＝解決セッション数 / 全セッション数、rolling30日）・エスカレーション率。目標例：解決率≥80%、エスカレーション増分Δ≤5pp（ベースライン比較）。 -
信頼性・安全性
指標：誤応答率（Severity別、rolling30日）・機密情報応答検知数。重大誤答（Severity-1）＝1件で即ロールバック。機密応答検知ルールの精度が担保されていることが必須です。 -
観測性・再現性
指標：ログ完全性スコア（必須項目揃い率、目標≥90%、daily/rolling7）・再現可能サンプル比（目標≥80%）。追跡不能事象比率20%超は運用不可の目安です。 -
運用コスト・スループット
指標：監視工数（FTE換算/日）、平均応答遅延と処理能力。追加監視工数が事前想定（例：1FTE）を超える場合はROIを再評価します。
統計基準（実務目安）：二値指標はα=0.05、β=0.2でサンプルを設計します。p≈0.5でΔ=5pp検出に各群約1,500件、Δ=10ppなら約400件です。AB判定では事前に有意水準と属性別最低サンプル数を定義し、未達は「不確定」とします。
現場テンプレ：AB設計→観測設計→判定→ロールバックの手順
成果物ベースで運用を回します：キックオフ合意→承認資料→AB配信と観測→定期判定→即時ロールバック。会議で必ず次の4点を提示できなければAB開始不可です。
-
キックオフ（成果物：キックオフ議事録）
必須記載：目的、対象チャネル、代表帳票、主要KPI（算出式・計測窓・閾値）、属性別最低サンプル数、合意者。議事録冒頭に「満たさない限り本番承認なし」を明記します。 -
承認資料（成果物：ROI・リスクシート）
要素：期待効果と想定Δ、追加監視工数、想定リスクとロールバック閾値を数値で示し承認を得ます。 -
AB配信・観測設計（成果物：配信設計書・観測設計書）
定義項目：スプリット方法・期間・最小サンプル（属性別）・必須ログ・アラート閾値・判定アルゴリズム。監査資料として保持します。 -
判定（成果物：判定レポート）
フロー：日次自動チェック（KPI・ログ完全性・重大誤答）→週次深掘り→閾値超過は自動アラートで即エスカレーション。判定は事前定義のANDルールで機械的に出します。 -
ロールバック（成果物：ロールバック手順書）
含む内容：即時トリガー（例：重大誤答1件、ログ完全性＜70%、抽出F1急落）、実行手順（トラフィック切替、モデルタグ差替、ユーザー告知）、連絡先。定期DRILLで有効性を確認します。
まとめ：導入判断・小さく試す順番・見送る条件
最低ライン（会議で宣言できる合格基準の例）：
- 業務妥当性：代表チャネルのSelf-serve解決率≥80%（rolling30日、算出式は議事録に明記）。
- 信頼性：重大誤答（Severity-1）＝0件。機密応答検知ルールが有効で精度を示せること。
- 観測性：ログ完全性≥90%（rolling7日）、再現可能サンプル比≥80%。
- 運用コスト：初期監視が1FTE以内か追加予算承認済み。
- 統計基準：代表属性ごとに事前合意の最低サンプル数（目安：各群n≥400で10pp検出、n≥1,500で5pp検出）。
小さく試す順番：フェーズ0 内部検証→フェーズ1 帳票（OCR）検証→フェーズ2 限定公開で統計要件達成→フェーズ3 スケール・運用確立。見送る条件例：必須ログ収集率＜70%、解決率閾値未達で回復見込みなし、重大安全性未解消、統計基準未達。
5分チェックリスト（会議で回す）
- キックオフ議事録：目的・代表チャネル・代表帳票・KPI算出式・計測窓・閾値・属性別最低サンプルが明記されているか。
- AB配信設計書：スプリット・期間・最小サンプル・属性バランスが定義されているか。
- 観測設計書：必須ログ項目と収集頻度・欠損時の扱いが明記されているか。
- 承認資料：ROIとリスク（監視工数含む）を数値化して提示できるか。
- ロールバック手順書：即時閾値・担当・実行手順が明確か（DRILL計画含む）。
最後に：スコアは証拠の一つに過ぎません。本番で確実に動くかは「見えているか（観測性）」「巻き戻せるか（ロールバック）」「誰が責任を取るか（合意）」で決まります。次回キックオフで最低限持ち帰る合意は、代表チャネル1つ＋代表帳票3種＋KPI算出式とサンプル要件＋ロールバック基準の4点です。
コメント