現場でよく聞く迷いは「既存のIT運用ルールで十分だ」という点です。しかし生成AIは「正常に見える誤答」を返すため、誰が目視し、どのログで監視していつ停止するかを明確にしないと導入が止まるか、初動遅延で被害が拡大します。本稿では運用チームが現場で即使える「優先度付きチェックリスト」と「申請／承認／初動テンプレ」を提示します。
結論（運用チームがまずやること）
利用場面ごとに影響度・露出・検知性の3軸で数値化した「3軸スコア」を付け、スコアに応じて「最低確認ライン」「停止トリガー」「承認権限」を明文化してワークフローに組み込んでください。以下に申請フォームサンプル、誤答率の測り方と閾値例、承認ワークフロー（RACI・SLA）、初週の実行計画を示します。
既存運用ルールでは足りない理由（要点）
既存SLAは死活監視やエラーログ向けで、生成AI固有の「正しく見える誤答」を検知できません。被害は「どの画面／帳票で」「何人に」「どの頻度で」露出するかで決まるため、事前に目視範囲・必須ログ・即時停止条件を定めてください。
- 必ず全数目視：契約書・請求書・外部公開コンテンツ・法務関係の生成物
- ログ必須：外部API、ユーザID紐付くクエリ、財務/PIIを含む出力（全クエリ＋応答の保存とアクセス制御）
- 即時停止：高影響×高露出×低検知性で閾値超過（例：重大誤答1件、または誤答率の短期急上昇）
判断軸と優先度付けルール
影響度・露出・検知性の3軸でスコア化し、合計で運用ルールを決定します。
- 影響度（0–4）：0 無視〜4 重大（契約・請求・法的影響）
- 露出（0–4）：ユーザ数／頻度でスコア化（例：4＝1000+）
- 検知性（0–2、低がリスク高）：0 目視で発見困難〜2 自動テストで再現容易
優先度（合計0–10）例：
- 8–10：最優先 — 事前承認＋本番前厳格テスト＋毎日監視
- 5–7：中優先 — 限定ローンチ＋週次サンプリング
- 0–4：低優先 — セルフサービス／ライト監視
場面別チェックリスト（運用現場向けテンプレ）
導入判断会議
- 必須提出：用途、公開範囲(internal|external)、想定ユーザ数、想定露出（/日）、3軸スコア（自動算出）— 未記入で承認不可。
- 必須添付：失敗想定（最低3ケース）、停止条件、監視指標（誤答率等）。
- 合格ライン：スコア8以上は事前承認＋本番前サンプルテスト（例：実データ100件、重大案件は200件）。
PoC設計
- 観測項目：誤答率（不正確応答数÷全検証クエリ数）、カテゴリ別件数、再現手順（チケット化）。
- 測定/閾値例：初期サンプル100件（高影響200件）。誤答率≥5%で追加調査、≥10%または重大誤答1件で一時停止検討。高影響は合格率95%等で厳格化。
- 停止/ログ：重要領域は自動停止か承認者通知。全クエリ＋応答を最低30日保存（PIIはマスキング／暗号化、アクセス制御）。
承認ワークフロー（RACIとSLA）
- 流れ：申請→自動スコア→一次審査（運用）→リスク審査（Sec/Legal）→最終承認（IT Risk Owner）。
- RACI（例）：Requester=Responsible、App Owner=Accountable、Operations=Responsible、InfoSec/Legal=Consulted、IT Risk Owner=Approver
- SLA：高影響は72時間以内決裁。未回答は自動で上位へエスカレーション＋通知。承認滞留率（例30%超）でワークフロー見直し。
問い合わせ／クレームのトリアージ
- 基準：外部高影響→即エスカレーション（法務＋運用＋IT Risk）。外部低影響→運用一次対応で暫定措置。内部のみ→運用で完結可（記録必須）。
- 一次通知テンプレ（24時間以内）：「一次通知：調査中。暫定対応（機能停止/回収）を実施。24時間以内に経過報告します。」
- 記録項目：問い合わせID、該当クエリ＋応答ログ、スクリーンショット、影響度スコア、対応者・日時。
画面・帳票確認（日次運用）
- 重要フィールド（契約書・請求書等）は全数目視。その他は日次ランダム抽出（目安：50件/日）。
- 自動差分監視で数値/PII変化を検出し、差分でチケット発行。
- 停止トリガー：重要フィールドで重大誤答→即ログ取得＋一時停止。停止条件は「重大誤答検出」または「誤答率の短期急上昇」を組合せる。
PDF・帳票確認
- チェック項目：PII漏えい、誤字/数値不一致、フォーマット崩れ、署名欄欠落（Yes/No記録）。
- ローンチ直後：100%目視。その後はリスクスコアに応じたサンプリング（高露出は毎日50%等）。
- 発見時：帳票回収＋訂正文書の自動発行手順とチケット追跡。
失敗パターンと対策（必須化する項目）
- PoC基準を本番に流用→対策：本番切替時に別途切替チェックリストと再承認を必須化。
- チェック過多で承認滞留→対策：3軸スコアで優先度決定、最大滞留時間と自動エスカレーション設定。
- 問い合わせをすべて法務へ→対策：運用に一次対応権限、法務は高影響に集中するRACIを徹底。
- ログ不備で追跡不能→対策：全クエリ＋応答保存、ユーザID紐付け、アクセス制御を承認条件に。
初動テンプレ（最初の7日で必ずやること）
最初の7日で「承認内容再確認」「PoC観測項目確定」「日次目視スケジュール登録」「15分初動演習」を実行してください。
- D0（承認直後）：3軸スコア再確認、PoC範囲確定、ログ方針決定 → 成果物：承認チケット完了
- D1：観測項目確定（誤答率定義・サンプル数）、窓口と一次対応者確定 → 成果物：PoC観測リスト＋連絡先
- D2：日次UIサンプリング・帳票チェックスケジュール登録 → 成果物：運用カレンダー
- D3–D7：15分初動演習（想定インシデント）、一次原因特定フローの確認 → 成果物：演習レポート＋改善リスト
15分初動チェック（テンプレ）：担当者の連絡先とエスカレーション順、スクリーンショット＋クエリ/応答ログ取得、ログ確保と一時停止、一次通知送付、24時間以内に速報レポート。
申請フォームの完全サンプル（JSON＋記入例）
{
"service_name": "string",
"purpose": "string",
"exposure": "enum(internal,external)",
"estimated_users": "integer",
"expected_daily_requests": "integer",
"impact_score": "integer(0-4)",
"exposure_score": "integer(0-4)",
"detectability_score": "integer(0-2)",
"stop_conditions_upload": "file",
"data_includes_pii": "boolean",
"log_retention_days": "integer",
"app_owner": "string (email)",
"requested_launch_date": "date"
}
{
"service_name": "顧客向け契約書自動生成",
"purpose": "営業向け契約書ドラフト自動化",
"exposure": "external",
"estimated_users": 1200,
"expected_daily_requests": 300,
"impact_score": 4,
"exposure_score": 4,
"detectability_score": 0,
"stop_conditions_upload": "stop_conditions_contracts.pdf",
"data_includes_pii": true,
"log_retention_days": 90,
"app_owner": "taro.honsha@example.com",
"requested_launch_date": "2026-04-01"
}
このフォームを実装し自動で3軸合計スコアを算出して承認レベルへ振り分けることで承認作業が標準化されます。
まとめ（運用チームがまずやる3点）
- 導入判断：影響度(0–4)・露出(0–4)・検知性(0–2)の合算で自動振り分け。合計8点以上は事前承認＋厳格監視必須。
- 初動：申請フォームを導入（上記JSON例を流用）、最初の7日でPoC観測項目と日次目視スケジュールを確定、15分初動演習を実施。
- 停止トリガー：重大誤答検出／誤答率の短期急上昇（例：5ポイント）／ログで原因追跡不能／承認滞留率閾値超過で即停止・再設計。
運用は「誰が」「いつ」「何を」確認するかを1枚のチェックシートとワンページの初動タイムラインに落とし込み、申請フォームと72時間承認SLAを即運用してください。
関連：チャット対応やデータ入力の業務変化と合わせて運用フローを見直すと効果的です（参考記事：チャット対応の未来図、データ入力業務の未来）。生成AIの基礎理解は社内の共通言語化にも役立ちます（生成AIパスポート基礎知識）。
コメント