AI事故は、システム復旧だけでは終わらない

OECDは、AIの開発・利用・故障が実際の害へ直接または間接に至った事象をincident、害へ至る可能性がある事象をhazardとして区別し、共通報告枠組みを29基準で構成しています。損失が確定していなくても、危険な挙動やニアミスを受付対象にすることで、重大化前の学習材料を増やせます。[2]

受付窓口では『AIが原因と確定したか』を最初の条件にしません。モデル名・版、利用機能、時刻、入力、出力、後続処理、人の介入、影響対象、現在も継続しているかを記録し、incident、hazard、通常障害、誤報を後から分類します。原因確定を待って受付が遅れる設計を避けます。[2]

一次判定は原因ではなく影響で行います。危険な出力が後続処理へ渡った、同型の利用が継続中、影響対象を特定できない、という状態を受付時に印付けし、いずれかが残る案件は通常問い合わせへ閉じません。OECDの分類は法的な重大性を自動判定しないため、社内の停止基準と外部報告要否は別の責任者が確認します。[2]

NIST AI RMF 1.0はGOVERN、MAP、MEASURE、MANAGEの4機能で継続的なリスク管理を構成し、MANAGEでは事故・事象への対応、回復、コミュニケーションの計画を扱います。[1] 上書きや早すぎる再開を避けるためのCatalysphereの運用提案として、サービスを戻す担当と、証拠を保全して影響を評価する担当を分けます。この分担による事故抑制効果をNISTが実証したという意味ではありません。

初動では対象機能を停止または縮退し、同じモデルを使う下流機能を探索します。同時に、モデル版、システムプロンプト、検索文書、ツール呼出し、ガードレール設定、監査ログ、人の承認履歴を保全します。個人情報や機密情報を含む証拠は、調査目的とアクセス権を限定し、二次被害を起こさない保管手順にします。

モデルが異常な文を出した事実だけで、根本原因をモデルへ固定しません。上流データ、検索文書、ツール応答、権限設定、担当者の承認、後処理を同じ時刻線へ並べ、各仮説を再現試験で落とします。証拠保全前の再実行は状態を変えることがあるため、復旧担当は複製環境を使い、原本ログを調査担当の管理下へ置きます。[1]

EU AI Act第73条は、EU市場の高リスクAIシステム提供者に重大インシデントの報告を求め、原則15日以内、広範な侵害等では2日以内、死亡では10日以内という異なる上限を置いています。必要なら不完全な初報の後に完全版を提出できる構造で、完全調査を待って時計を止める考え方ではありません。[3]

自社の重大度表には、身体・健康、基本権、重要インフラ、財産、地域社会、環境、情報漏えい、広がり、継続性を入れます。法定報告の対象外でも、顧客、委託先、経営、広報、セキュリティ、法務へ通知する内部期限を決めます。適用法と契約によって時計の起点が違うため、個別判断は専門家へ接続します。[2] [3]

OECDの共通報告枠組みは事象を比較可能な項目へ整理しますが、個別案件の因果関係や被害対象を自動で確定しません。[2] 事故対応では、問題の出力がどの画面、通知、ファイル、後続処理へ渡り、誰が閲覧または行動したかを逆引きする影響照合簿を作ります。確認時点も併記します。

照合簿は、出力識別子、配布先、後続の自動処理、人の判断、現実に実行された措置、訂正の要否を一本につなぎます。ログが欠ける区間は推測で埋めず、確認不能として範囲を広めに保留します。出力が誤っていても利用されなかった案件と、正しく見える出力が誤措置へ至った案件を分けます。

訂正では、元の表示を消したかだけでなく、転載、転送、手入力された記録、後続判断へ訂正が届いたかを対象ごとに閉じます。影響対象を特定できない場合は、分かった範囲と未確認範囲を分離し、追加連絡の判断者を置きます。原因調査の完了を待たず、回復可能な影響から順に処理します。

事故票を閉じる前に、修正した説明ではなく、同型の失敗を再び起こそうとする反証課題を設けます。元の入力、境界に近い入力、欠けていたログ条件、代替原因を再現した条件を分け、どの条件で検知、封じ込め、訂正開始が機能するかを確認します。成功例だけでは終結せず、失敗条件を保存します。

反証課題が失敗した場合は、修正不足、観測不足、権限不足、訂正経路不足へ分類し、事故原因のラベルと混ぜません。根本原因の説明が正しくても、影響検索や訂正が再現できなければ対応能力は未回復です。反対に原因が未確定でも、限定した範囲で封じ込めと回復を検証できた事実は別に記録します。

終結判断では、未訂正対象、残る原因仮説、再発時の検知条件、再び開くトリガーを明記します。調査担当ではない責任者が照合簿と反証結果を確認し、残余の不明点を引き受けたうえで閉じます。後から新しい対象や証拠が見つかったとき、同じ事故番号を再開できる状態を維持します。

• TRACE：出力、配布、後続処理、人の判断、現実の措置を結ぶ
• REPAIR：対象ごとに訂正先、到達確認、未確認範囲を閉じる
• REFUTE：元入力・境界条件・代替原因で同型失敗を再試験する
• CLOSE：未解決事項、再開トリガー、終結承認者を固定する

再開条件は『修正を入れた』ではなく、原因仮説、影響範囲、再現試験、回帰試験、残余リスク、代替手段、監視指標、責任者の承認で構成します。根本原因が特定できない場合は、対象利用者や機能を狭め、人的確認を追加し、観測期間を置くなど、可逆的な再開を選びます。[1]

事後レビューでは、誰を責めるかより、検知が遅れた理由、判断材料が欠けた理由、停止権限が曖昧だった理由を扱います。OECDの報告項目へ合わせて社内記録を標準化すると、事故間の比較と外部報告への転記がしやすくなります。ただし公開データだけでは見えない事故も多いため、自社のニアミス収集を別に維持します。[2]

限定再開では、対象利用者、許す機能、人的確認、観測する失敗類型、再停止条件を一枚にします。原因不明のまま再開する場合は、残余リスクを承認した責任者を記録し、同型ハザードが再発した時点で自動または当番者が退避へ戻せるようにします。復旧速度だけでなく、影響対象の特定と訂正が完了したかを終結条件に含めます。[1] [2]

• 検知：利用者報告、品質指標、セキュリティ監視を一つの受付へ集める
• 封じ込め：停止、権限遮断、モデル切替、手作業への退避を選べるようにする
• 説明：分かった事実、未確定事項、次回更新時刻を分けて伝える
• 再開：独立した承認者が残余リスクと監視計画を確認する
• 受付責任者：incident未確定でもhazardとして記録を開く
• 調査責任者：証拠保全と競合する原因仮説の検証を担う
• 再開責任者：残余リスク、再停止条件、訂正完了を承認する