LLMアプリで事故が起きたら？止める・調べる・再発を防ぐ手順
LLMアプリの事故は、サービス停止だけではない。誤った回答の大量送信、権限外の情報表示、同じ外部操作の重複、古い規程に基づく案内、費用の急増も利用者へ影響するインシデントになり得る。
事故の最中に完全な原因を探し続けると、被害が広がる。最初に影響を抑え、安全な状態へ戻す。その後で証拠を保全し、原因を切り分け、再発防止を評価セットと運用へ戻す。通常のサービス運用と同じ原則を使いながら、生成結果、検索根拠、道具の操作を含むLLM特有の状態も扱う必要がある。
何をインシデントと呼ぶか先に決める
回答が気に入らないという一件と、緊急対応が必要な事故を同じ扱いにしない。利用者への影響、データや権限、安全性、外部操作、発生範囲、継続時間で重大度を決める。
例えば次の事象は、即時確認の候補になる。
- 秘密情報や他人の情報を回答へ含めた
- 承認なしで送信、購入、削除などを実行した
- 同じ操作を複数回実行した
- 誤情報を多数の利用者へ継続して返した
- 安全上重要な拒否が機能しなくなった
- 呼び出し回数、費用、遅延が運用上限を大きく超えた
品質低下を発見した人が、どこへ連絡し、誰が事故を宣言できるかを決める。緊急停止を承認できる担当者が不明だと、検知できても被害を止められない。
原因究明より先に影響を抑える
Google SREのインシデント対応資料は、影響を評価し、緩和し、その後に根本原因を分析する順序を示している。完全な説明ができなくても、安全な構成へ戻せるなら先に戻す。
LLMアプリで使える緩和策には、問題のある構成版から直前の版へ戻す、特定の道具だけを無効にする、書き込み操作を読み取り専用へ落とす、対象の文書群を検索から外す、利用者を人の窓口へ案内する、機能全体を一時停止する方法がある。
モデルを切り替えるだけでは直らない場合も多い。原因が古い検索索引、壊れた道具の応答、誤った権限設定なら、モデル変更は影響を隠すだけかもしれない。どの層を止めれば被害を最小化できるかを事前に試す。
すでに外部操作が行われた場合は、アプリの応答を止めるだけで終わらない。送信先、更新対象、実行IDを確認し、取消可能な操作と、人の対応が必要な操作を分ける。自動で逆操作すると、さらに重複や損失を増やす可能性がある。
対応中の役割を分ける
小規模なチームでも、判断、調査、記録、利用者への連絡を意識して分ける。一人が全ログを読みながら、復旧操作と説明文の更新を同時に行うと、重要な判断が埋もれる。
指揮役は重大度、緩和策、次の確認時刻を決める。調査役は仮説と証拠を整理する。記録役は発見、変更、判断、復旧の時刻を残す。連絡役は確認済みの影響と回避策だけを伝える。人数が少なく同じ人が兼任しても、役割ごとの作業を区別する。
対応用の記録には、事象ID、開始時刻、影響範囲、現在の構成版、実施した緩和策、未確認事項、次の担当者を持たせる。チャットだけに断片を残すと、交代時に同じ調査を繰り返す。
調査できる証拠を平時から残す
生成AIの実行は、同じ入力でも出力が変わる。事故後に再実行した結果だけを見ても、実際に利用者へ返した内容を再現できない場合がある。実行ID、時刻、モデルとプロンプトの版、入力の分類、取得文書のIDと版、道具の名前と結果、最終出力、ガードレール判定を対応付ける。
ただし、入力全文や道具の結果には個人情報、秘密値、業務データが含まれ得る。本文を既定で保存するのではなく、用途ごとに伏字、暗号化、アクセス制御、保持期間を決める。全文が不要なら、ハッシュ、型、件数、エラー分類、安定した文書IDで調査できるようにする。
事故が起きてからログ項目を増やしても、過去の証拠は戻らない。一方、何でも保存すれば情報漏えい時の影響が増える。想定する事故と調査に必要な最小情報を対応表にする。
LLM特有の原因を層ごとに切り分ける
「AIが間違えた」で調査を終えない。少なくとも入力、プロンプト、モデル、検索、参照文書、道具、権限、後処理、表示、評価の層に分ける。
誤回答なら、必要な文書を取得できたか、取得文書は最新だったか、文書と回答が一致するかを順に見る。誤操作なら、モデルが誤った道具を選んだのか、引数検証が通したのか、承認画面が対象を明示したのか、同じ実行IDが再処理されたのかを確認する。
直前の変更が原因とは限らない。モデルとコードが同じでも、質問の分布、原本、索引、APIの返却値が変わることは、前の記事で扱ったドリフトの一部である。構成変更の時系列と外部状態の時系列を並べる。
仮説ごとに、支持する証拠、反する証拠、次の確認を記録する。推測を事実として利用者へ説明しない。
復旧は停止解除ではなく再評価まで含む
修正できたら、事故を再現する入力を非公開の回帰例にする。期待する回答だけでなく、禁止する操作、必要な承認、使うべき根拠を記録する。事故例だけを通す修正ではなく、既存の評価セットも実行して別の機能を壊していないか確認する。
復旧は限定した範囲から始める。影の実行、社内利用、一部通信の順に広げ、同じ失敗、関連する安全指標、遅延、費用を監視する。再発した場合に一つの操作で安全な構成へ戻せることを確認してから全体へ展開する。
ロールバック手順は文書だけでなく実際に試す。Google SREの事例では、ロールバック手順を試験していなかったことが復旧を長引かせた。モデル、プロンプト、索引、道具定義を独立して戻せるか、戻した版が現在の外部Schemaと互換かも確認する。
事後検証は責任追及ではなく仕組みを直す
復旧後の記録には、利用者への影響、検知から緩和までの時系列、直接原因、影響を拡大した条件、うまく機能した防御、機能しなかった検知、再発防止項目を含める。個人の不注意だけで終わらせず、なぜ一つの判断が事故へ到達できたかを調べる。
Google SREは、非難しない事後検証と、担当者・期限を持つ是正項目を重視している。文書を書いても行動が完了しなければ再発防止にならない。各項目に所有者、期限、確認方法を付ける。
LLMアプリでは、事故例を評価セットへ追加し、ガードレール、権限、承認、ログ、監視、ロールバックのどこを改善したかを結び付ける。似た事故を想定した演習も行い、夜間や担当者不在でも停止と連絡ができるかを試す。
NISTは生成AIのリスク管理で、公開前試験だけでなく、インシデント開示と運用中の管理を扱っている。技術的な復旧に加え、契約、法令、利用者通知に関する判断経路も平時に確認しておく。
LLMアプリの事故対応では、賢い原因推定より、影響を早く止められる設計が重要である。停止手段、最小限の証拠、層ごとの切り分け、限定復旧、回帰評価、担当者付きの再発防止を準備しておけば、予測できなかった失敗を次の防御へ変えられる。