導入と結論（要約）
問い合わせを受けた瞬間、現場は「まずモデル停止」と短絡しがちです。しかし停止は証拠を失わせ、復旧を長引かせることがあります。ランブック向けの結論：オンコールは30分以内に「5点初動チェック」を完了し、SLA（業務影響度）・再現性・証拠完全性の3軸で一次判定する。モデル停止やロールバックは承認と回帰テストを経た最終手段とします。
誤解を壊す：初動でモデル停止は原則禁止
初動での停止を原則禁止とし、手順は「証拠確保→仮トリアージ→限定ワークアラウンド→承認付き停止」の順で進めます。よくある失敗：ユーザー報告ですぐ停止提案→承認待ちでログやネイティブ出力が失われ再現不可、原因不明で復旧が長期化。現場の責任議論も発生します。
実務判断の要点
- まず行うのは証拠確保（スクショ／ネイティブ出力）とログ保全。これがなければ原因立証は難しい。
- 「バイアスだ」と即断せず、入力・前処理・モデルバージョン・設定・外部API応答を確認する。
- 停止は最後の手段。まずは限定ワークアラウンド（UI非表示、出力のバッチ化、特定顧客の旧フロー退避）で業務継続を優先する。
短いIF/THENルール
- IF 証拠が揃い（スクショ＋ネイティブ出力＋ログ）かつSLAが高 THEN 停止含む即時対応を検討。
- IF 証拠不十分で再現性低い THEN まず保全と監視継続（5点を完了）→追加データで再判断。
短時間で決めるトリアージ軸（SLA・再現性・証拠）
30分ルールは「業務影響度（SLA）」「再現性」「証拠の完全性」の3軸で運用します。オンコール会議では即時に「即対応（停止含む）／限定ワークアラウンド／監視継続」のいずれかを宣言してください。
具体的な閾値（運用テンプレ目安）
- SLA（業務影響度）
- 高：影響ユーザー数 ≥ 100人、または決済・出荷・請求等の重要業務に直接影響
- 中：数十人〜100人、重要業務の一部に影響
- 低：単発・非クリティカル
- 再現性
- 高：同一手順で再現／継続発生
- 中：条件付きで再現（特定入力や時間帯）
- 低：単発報告
- 証拠完全性
- 高：スクショ＋ネイティブ出力＋サーバログ＋リクエストID
- 中：スクショ＋操作手順のみ
- 低：口頭報告のみ
時間軸テンプレ
- 0–30分：一次判定（即対応／限定ワークアラウンド／監視継続）を宣言し、5点を完了する。
- 3時間：仮復旧または詳細調査の結論（カナリア比率やフラグで段階適用）。
- 24時間：全面対応（ロールバック、公開告知含む）の是非を確定する。
現場で使える初動チェックリスト（30分内の5点）と問い合わせテンプレ
最初の30分で必ず完了する5点を最小必須手順として運用します。誰が何分で何をするかを明確にし、完了しない限り停止判断を行わない運用ルールにしてください。
30分で回す5点（役割と想定所要時間）
- 標準ヒアリング送付（オンコール/CS、0–3分）
- スクショ＋操作手順の取得（オンコール→ユーザー、3–10分）
- PDF／帳票のネイティブ出力保存（ユーザーまたはCS、3–10分）
- 関連ログのエクスポート＆保全（SRE、並行実行、0–15分）
- 仮トリアージとチケット化（オンコールが記載、15–30分）
問い合わせテンプレ（コピペ可）
件名：出力確認のお願い（要対応）
本文：お問い合わせありがとうございます。至急以下をお送りください：1) 影響操作日時（タイムスタンプ） 2) フルスクリーンのスクショ（全画面） 3) 可能ならネイティブPDF/帳票ファイル（印刷→PDF保存） 4) 実行した操作手順（どのボタン/フィルタ） 5) 影響ユーザー数や業務名。受領後、ログ保全と一次対応を実行します。
スクショしかない場合の代替手順
- ユーザーがネイティブ出力を出せない場合はブラウザの「印刷→PDF」を依頼し、タイムスタンプ・アカウントID・操作手順を明記してもらう。
- それでも取得不能ならSREに該当時間帯のサーバログ／DBクエリログを範囲指定で抽出してもらう。
ログ保全のSRE向けテンプレ
kubectl logs -n <namespace> deploy/<deploy-name> --since=2h > /tmp/<incident-id>-model.log kubectl logs -n <namespace> -l app=<app-label> --since=2h | grep <request-id> > /tmp/<incident-id>-request.log aws s3 cp /tmp/<incident-id>-*.log s3://company-incident-archive/<service>/<incident-id>/ --acl private
保存先のS3バケットでは該当オブジェクトのライフサイクル停止やオブジェクトロックを適用してください。
証拠保存の注意点
- スクショだけで終わらせず、ネイティブ出力を優先して取得する。
- 機密情報が含まれる可能性がある場合は即座にマスキングを適用し、法務へ報告のトリガーをランブックに明記する。
- インシデントチケットにはS3パス／ログファイル名／スクショを必ずリンクで残す。
ロールバック前の必須チェック：承認フロー・回帰テスト・外部確認・法務
ロールバックは最終手段です。実行前に承認者、回帰テスト計画、外部依存確認、法務確認の4点を満たすことを必須化してください。
会議で確認する承認項目
- 承認者：サービス責任者（PO）、SREリード、オンコールリード、法務/コンプライアンス担当（連絡先付き）
- 影響範囲：戻すバージョン、対象ユーザー、想定影響（数値で）
- 回帰テスト計画：PoC環境での再現手順と主要ユースケース（決済等の1ケース以上）を自動テストで確認
- ログ差分：本番差分ログを保存し、ロールバック後に差分比較可能にする
- 外部依存：外部APIやクラウドのステータス確認
- 法務判断：データ漏えい疑い時の通知条件と承認者
段階適用の運用例
PoCで主要シナリオ（業務重要度順に最低10ケース）を自動テスト→合格後にカナリア（10%→50%→100%）で段階適用。各段階で監視指標と閾値を定め、閾値超過で自動ロールバックする仕組みを用意します。
中間判断（IF/THEN）
- IF 再現性高 AND SLA高 AND 回帰テスト合格 THEN ロールバックを短時間で実施可能（議事録＋監査証跡必須）。
- IF 再現性低 OR 外部依存が示唆される THEN 限定ワークアラウンドや外部ベンダーとの協働調査を優先。
実務に落とすための持ち帰り
- ランブックに5点チェックの責任者と所要時間を明記する。
- スクショしかない場合の代替手順とSREが即実行するログ抽出コマンドを掲載する。
- インシデントチケットの必須フィールド（タイムスタンプ、S3パス、再現性評価、初動判定）を定義する。
スポーツの試合での交代判断のように、運用でも最短で情報を揃え、仮トリアージで試合（業務）を止めずに対応する姿勢が有効です。
まとめ
導入判断の条件：影響範囲を限定でき、ログ保全と30分初動チェック（5点）が運用に組み込めること。SLA違反を即検出でき、法務・コンプライアンスの重大リスクが事前に排除できること。満たさない場合は限定運用で始めるか導入を見送って代替案を提示してください。
小さく試す手順：1) PoC（限定ユーザー／限定機能）で初動チェックを運用化→2) ランブックにテンプレ・ログコマンド・保存先を明記してリハーサル→3) 段階展開で30分/3時間/24時間ルールを評価して本番化。
締め：最初の30分で回すべき5点（ユーザーヒアリング／スクショ取得／PDF原本保存／ログ保全／トリアージ判定）をランブックの最小必須手順に固定し、SLA・再現性・証拠の3軸で即断できる体制を作ってください。
コメント