{ "schemaVersion": "1.0", "language": "ja", "canonicalUrl": "https://catalysphere.co.jp/articles/ai-incident-response/", "machineReadableUrl": "https://catalysphere.co.jp/articles/ai-incident-response/index.json", "publisher": { "name": "Catalysphere", "url": "https://catalysphere.co.jp/", "description": "AIとビッグデータを研究し、実務へつなぐリサーチ＆コンサルティングスタジオ。" }, "article": { "slug": "ai-incident-response", "title": "AI事故は、システム復旧だけでは終わらない", "summary": "モデル停止だけで終わらせず、被害、因果関係、版・データ・判断の証拠、対外報告、再発防止を一続きにする対応設計を整理します。", "takeaways": [ "AI事故では可用性の復旧だけでなく、影響を受けた人・権利・環境、モデルと事故の関係、入力・出力・人の判断の証拠を同時に扱います。[1] [2]", "OECDの共通報告枠組みは29基準を提示し、EU AI Actは対象となる重大事故に原則15日以内などの期限を設けています。[2] [3]", "平時に重大度、停止権限、証拠保全、通知先、代替業務、再開条件を決め、机上演習と事後レビューで更新します。" ], "publishedAt": "2026-07-13", "updatedAt": "2026-10-01", "readingMinutes": 12, "topics": [ "AIインシデント", "危機対応", "ガバナンス", "再発防止" ], "domains": [ "generative-ai", "organization-adoption", "governance-risk" ], "evidenceKind": "research-review", "status": "published", "image": { "prompt": "Abstract scientific editorial illustration for the research question “AI事故対応は、通常の障害対応と何が違うのか”, interpreted symbolically rather than typographically: separate knowledge clusters connected through a shared operating network, with a few gold checkpoints making coordination and handoffs visible; deep Catalysphere navy and indigo field, muted scientific blue, restrained antique-gold structure, translucent geometry, fine particles, subtle paper grain, generous negative space, one clear centered metaphor that survives a narrow mobile cover crop, calm premium research-journal art direction, no readable text, no logo, no literal chart, no photorealistic people.", "negativePrompt": "text, letters, numerals, watermark, logo, dashboard UI, humanoid robot, server rack, binary rain, stock-photo office, literal quantitative chart, red alarm graphics, neon cyberpunk, purple gradient, clutter", "alt": "複数の知識クラスターが金色の検証点を介して一つの運用ネットワークへ接続する抽象図", "aspectRatio": "16:9", "assetPath": "article-art/ai-incident-response.png", "status": "approved" }, "lead": "生成AIが誤情報を大量送信した、差別的な自動判定が続いた、機密情報が出力された。そのとき通常のシステム障害手順だけで足りるでしょうか。NIST、OECD、EUの一次資料を読むと、AI事故対応には技術復旧に加え、被害と因果関係の評価、証拠保全、影響を受けた人への連絡、規制報告、モデル再開の判断が必要です。[1] [2] [3]", "sections": [ { "heading": "事故とハザードを分けて入口を広げる", "paragraphs": [ "OECDは、AIの開発・利用・故障が実際の害へ直接または間接に至った事象をincident、害へ至る可能性がある事象をhazardとして区別し、共通報告枠組みを29基準で構成しています。損失が確定していなくても、危険な挙動やニアミスを受付対象にすることで、重大化前の学習材料を増やせます。[2]", "受付窓口では『AIが原因と確定したか』を最初の条件にしません。モデル名・版、利用機能、時刻、入力、出力、後続処理、人の介入、影響対象、現在も継続しているかを記録し、incident、hazard、通常障害、誤報を後から分類します。原因確定を待って受付が遅れる設計を避けます。[2]", "一次判定は原因ではなく影響で行います。危険な出力が後続処理へ渡った、同型の利用が継続中、影響対象を特定できない、という状態を受付時に印付けし、いずれかが残る案件は通常問い合わせへ閉じません。OECDの分類は法的な重大性を自動判定しないため、社内の停止基準と外部報告要否は別の責任者が確認します。[2]" ] }, { "heading": "復旧より先に被害と証拠を固定する", "paragraphs": [ "NIST AI RMF 1.0はGOVERN、MAP、MEASURE、MANAGEの4機能で継続的なリスク管理を構成し、MANAGEでは事故・事象への対応、回復、コミュニケーションの計画を扱います。[1] 上書きや早すぎる再開を避けるためのCatalysphereの運用提案として、サービスを戻す担当と、証拠を保全して影響を評価する担当を分けます。この分担による事故抑制効果をNISTが実証したという意味ではありません。", "初動では対象機能を停止または縮退し、同じモデルを使う下流機能を探索します。同時に、モデル版、システムプロンプト、検索文書、ツール呼出し、ガードレール設定、監査ログ、人の承認履歴を保全します。個人情報や機密情報を含む証拠は、調査目的とアクセス権を限定し、二次被害を起こさない保管手順にします。", "モデルが異常な文を出した事実だけで、根本原因をモデルへ固定しません。上流データ、検索文書、ツール応答、権限設定、担当者の承認、後処理を同じ時刻線へ並べ、各仮説を再現試験で落とします。証拠保全前の再実行は状態を変えることがあるため、復旧担当は複製環境を使い、原本ログを調査担当の管理下へ置きます。[1]" ] }, { "heading": "重大度と報告時計を別々に持つ", "paragraphs": [ "EU AI Act第73条は、EU市場の高リスクAIシステム提供者に重大インシデントの報告を求め、原則15日以内、広範な侵害等では2日以内、死亡では10日以内という異なる上限を置いています。必要なら不完全な初報の後に完全版を提出できる構造で、完全調査を待って時計を止める考え方ではありません。[3]", "自社の重大度表には、身体・健康、基本権、重要インフラ、財産、地域社会、環境、情報漏えい、広がり、継続性を入れます。法定報告の対象外でも、顧客、委託先、経営、広報、セキュリティ、法務へ通知する内部期限を決めます。適用法と契約によって時計の起点が違うため、個別判断は専門家へ接続します。[2] [3]" ] }, { "heading": "出力から現実の措置まで、影響を逆引きする", "paragraphs": [ "OECDの共通報告枠組みは事象を比較可能な項目へ整理しますが、個別案件の因果関係や被害対象を自動で確定しません。[2] 事故対応では、問題の出力がどの画面、通知、ファイル、後続処理へ渡り、誰が閲覧または行動したかを逆引きする影響照合簿を作ります。確認時点も併記します。", "照合簿は、出力識別子、配布先、後続の自動処理、人の判断、現実に実行された措置、訂正の要否を一本につなぎます。ログが欠ける区間は推測で埋めず、確認不能として範囲を広めに保留します。出力が誤っていても利用されなかった案件と、正しく見える出力が誤措置へ至った案件を分けます。", "訂正では、元の表示を消したかだけでなく、転載、転送、手入力された記録、後続判断へ訂正が届いたかを対象ごとに閉じます。影響対象を特定できない場合は、分かった範囲と未確認範囲を分離し、追加連絡の判断者を置きます。原因調査の完了を待たず、回復可能な影響から順に処理します。" ], "visual": { "kind": "workflow", "eyebrow": "判断と証拠の関係", "title": "復旧と訂正を同じ終了扱いにしない", "caption": "Catalysphereによる未検証の運用・測定設計案です。研究の実測値や導入効果を表した図ではなく、自社条件で検証する判断関係を示します。", "provenance": "catalysphere-authored", "steps": [ { "id": "s0", "label": "影響受付", "detail": "疑い段階から対象と発生時点を記録" }, { "id": "s1", "label": "封じ込め・証拠保全", "detail": "新規実行を止め、事故に関係する証拠を定めたアクセス・保持範囲で保全" }, { "id": "s2", "label": "訂正と限定再開", "detail": "訂正到達・未達を別記録し、残る影響を明示して限定再開を判定" }, { "id": "s3", "label": "終了判断", "detail": "到達・影響・終了判断の未確認は未解決のまま残す" } ], "feedback": [ { "from": "s3", "to": "s1", "label": "再発・影響追加", "detail": "案件を再開し封じ込め範囲と証拠を更新" } ], "measures": [ { "label": "訂正到達", "detail": "通知表示だけで到達済みにしない" }, { "label": "時計の起点", "detail": "適用法と認知時点を別途確認" } ] } }, { "heading": "事故終結前に、再発防止の主張を試験で疑う", "paragraphs": [ "事故票を閉じる前に、修正した説明ではなく、同型の失敗を再び起こそうとする反証課題を設けます。元の入力、境界に近い入力、欠けていたログ条件、代替原因を再現した条件を分け、どの条件で検知、封じ込め、訂正開始が機能するかを確認します。成功例だけでは終結せず、失敗条件を保存します。", "反証課題が失敗した場合は、修正不足、観測不足、権限不足、訂正経路不足へ分類し、事故原因のラベルと混ぜません。根本原因の説明が正しくても、影響検索や訂正が再現できなければ対応能力は未回復です。反対に原因が未確定でも、限定した範囲で封じ込めと回復を検証できた事実は別に記録します。", "終結判断では、未訂正対象、残る原因仮説、再発時の検知条件、再び開くトリガーを明記します。調査担当ではない責任者が照合簿と反証結果を確認し、残余の不明点を引き受けたうえで閉じます。後から新しい対象や証拠が見つかったとき、同じ事故番号を再開できる状態を維持します。" ], "bullets": [ "TRACE：出力、配布、後続処理、人の判断、現実の措置を結ぶ", "REPAIR：対象ごとに訂正先、到達確認、未確認範囲を閉じる", "REFUTE：元入力・境界条件・代替原因で同型失敗を再試験する", "CLOSE：未解決事項、再開トリガー、終結承認者を固定する" ] }, { "heading": "再開を新しいリスク判断にする", "paragraphs": [ "再開条件は『修正を入れた』ではなく、原因仮説、影響範囲、再現試験、回帰試験、残余リスク、代替手段、監視指標、責任者の承認で構成します。根本原因が特定できない場合は、対象利用者や機能を狭め、人的確認を追加し、観測期間を置くなど、可逆的な再開を選びます。[1]", "事後レビューでは、誰を責めるかより、検知が遅れた理由、判断材料が欠けた理由、停止権限が曖昧だった理由を扱います。OECDの報告項目へ合わせて社内記録を標準化すると、事故間の比較と外部報告への転記がしやすくなります。ただし公開データだけでは見えない事故も多いため、自社のニアミス収集を別に維持します。[2]", "限定再開では、対象利用者、許す機能、人的確認、観測する失敗類型、再停止条件を一枚にします。原因不明のまま再開する場合は、残余リスクを承認した責任者を記録し、同型ハザードが再発した時点で自動または当番者が退避へ戻せるようにします。復旧速度だけでなく、影響対象の特定と訂正が完了したかを終結条件に含めます。[1] [2]" ], "bullets": [ "検知：利用者報告、品質指標、セキュリティ監視を一つの受付へ集める", "封じ込め：停止、権限遮断、モデル切替、手作業への退避を選べるようにする", "説明：分かった事実、未確定事項、次回更新時刻を分けて伝える", "再開：独立した承認者が残余リスクと監視計画を確認する", "受付責任者：incident未確定でもhazardとして記録を開く", "調査責任者：証拠保全と競合する原因仮説の検証を担う", "再開責任者：残余リスク、再停止条件、訂正完了を承認する" ] } ], "note": "本稿は法的助言ではなく、業種横断の運用設計です。NIST AI RMF 1.0は任意利用の枠組みです。[1] OECDの29基準は国際的な共通化を目指す報告枠組みで、各国の法定様式を置き換えません。[2] EU AI Act第73条の期限は同規則が定義する高リスクAIシステムと重大インシデントに関するもので、対象、起算点、経過措置を個別に確認する必要があります。[3]", "sources": [ { "id": 1, "authors": "Elham Tabassi", "year": 2023, "title": "Artificial Intelligence Risk Management Framework (AI RMF 1.0)", "venue": "NIST AI 100-1, National Institute of Standards and Technology", "url": "https://doi.org/10.6028/NIST.AI.100-1", "finding": "GOVERN、MAP、MEASURE、MANAGEの4機能でAIリスク管理を構成し、対応、回復、事故コミュニケーションを含む継続的な管理結果を提示する。", "limitation": "任意利用で業種非依存の枠組みであり、個別事故の法定報告先・期限・技術手順を確定しない。" }, { "id": 2, "authors": "OECD", "year": 2025, "title": "Towards a Common Reporting Framework for AI Incidents", "venue": "OECD Artificial Intelligence Papers No. 34", "url": "https://doi.org/10.1787/f326d4ac-en", "finding": "法域や分野をまたいでAIインシデントを記録・比較するため、8次元から選定した29基準の共通報告枠組みを提示している。", "limitation": "共通化のための政策枠組みであり、各国の強制報告制度ではない。情報の入手可能性と報告者の判断により記録の完全性が変わる。" }, { "id": 3, "authors": "European Parliament and Council of the European Union", "year": 2024, "title": "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)", "venue": "Official Journal of the European Union", "url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj", "finding": "Article 73 requires providers of covered high-risk AI systems to report serious incidents, with differentiated maximum timelines including 15, 2, and 10 days depending on the incident category.", "limitation": "期限はEU AI Actの定義・適用範囲に従う法的義務であり、全AI障害へ一律適用されない。起算点や役割分担は個別事案で確認が必要である。" } ], "visual": { "eyebrow": "INCIDENT READINESS", "title": "事故対応を支える三つの外部基準", "caption": "枠組み、報告項目、法定期限は役割が異なり、単純な成熟度比較には使えません。", "metrics": [ { "value": "4 FUNCTIONS", "label": "GOVERN・MAP・MEASURE・MANAGEで回す継続管理", "source": "NIST AI RMF", "referenceId": 1 }, { "value": "29 CRITERIA", "label": "OECD共通インシデント報告枠組みの基準数", "source": "OECD 2025", "referenceId": 2 }, { "value": "15 DAYS", "label": "EU AI Act第73条の原則的な重大事故報告上限", "source": "EU AI Act", "referenceId": 3 } ] }, "url": "https://catalysphere.co.jp/articles/ai-incident-response/", "machineReadableUrl": "https://catalysphere.co.jp/articles/ai-incident-response/index.json", "topicFacets": [ { "id": "safety-resilience", "name": "安全性・レジリエンス", "url": "https://catalysphere.co.jp/topics/safety-resilience/" }, { "id": "governance-risk", "name": "AIガバナンス", "url": "https://catalysphere.co.jp/topics/governance-risk/" } ] } }