AIを業務へ組み込むと、従来のシステム障害とは異なる兆候が現れます。誤った回答が一部の利用者だけに表示される、 特定の入力で有害な出力が繰り返される、外部ツールを意図せず操作する、モデル更新後に判断傾向が変わる、といった事象です。 サービスが停止していなくても、顧客、従業員、取引先、社会へ影響が及ぶ可能性があります。

ところが、AI導入時の審査や評価は整備していても、稼働後に「誰が異常を受け付けるか」「どの条件で止めるか」 「何を記録して誰へ伝えるか」「何を確認すれば再開できるか」まで決めていない組織は少なくありません。 事故が起きてから関係者を集めると、影響把握と事業継続の判断が遅れます。

経済産業省・総務省のAI事業者ガイドライン第1.2版は、リスクの大きさに応じて対策を選ぶリスクベースアプローチと、 環境変化に合わせて見直すアジャイル・ガバナンスを基本にしています。NIST AI 600-1は、生成AIのリスク管理において ガバナンス、導入前評価、コンテンツ来歴、インシデント開示を主要な検討事項とし、停止、復旧、振り返りまでの具体的な行動を示しています。 本記事では、これらを自社の運用へ落とす5つの手順を整理します。

具体的な課題：異常に気づいても、止める・伝える・戻す判断ができない

従来の障害対応手順をAIへそのまま適用すると、稼働率やエラーコードでは捉えにくい影響が抜け落ちます。 AIの出力は入力、モデル、検索データ、プロンプト、外部ツール、人の使い方の組み合わせで変わり、原因と影響範囲を一度で特定できないことがあります。

  • 受付口が分散する：利用者の違和感、監視アラート、顧客苦情、ベンダー通知が別々に管理される。
  • 事故と兆候を区別できない：実害が確認できない事象を放置する一方、軽微な誤回答ですべてを停止してしまう。
  • 停止権限が曖昧である：業務責任者、AI管理者、開発、セキュリティの誰が利用制限を決めるか分からない。
  • 証拠が残らない：入力、出力、モデル版、検索元、ツール実行、設定変更、利用者への表示を再現できない。
  • 再開条件がない：暫定修正後、どの評価と承認を経れば本番へ戻せるか決めていない。
AI事故対応は、発生後の技術調査だけではありません。検知から停止、共有、代替運用、再開、学習までを事業運用として設計します。

考え方：「インシデント」と「ハザード」を分け、同じ流れで扱う

OECDは、AIの開発・利用・誤作動が実際の被害へ直接または間接に結び付いた事象をAIインシデント、 被害へつながり得る事象をAIハザードとして整理しています。社内運用では、この区別を法的な判定として機械的に使うのではなく、 実害の有無と潜在的な影響を分けて初動を選ぶ共通言語として利用できます。

対応の基本構造は「検知・分類・封じ込め・共有・復旧と学習」です。分類の時点で完全な原因特定を待たず、 影響の大きさ、拡大可能性、対象者、外部依存、証拠の確かさを暫定評価します。新しい情報が得られたら、 重大度、対応範囲、連絡先を更新します。

NIST AI 600-1は、AIインシデント報告の最小項目として、システム識別子、件名、報告者、システム・情報源、 報告日、発生日、説明、影響、影響を受けた関係者などを挙げています。すべてを最初から確定させるのではなく、 未確認事項と更新履歴を含む一つの記録を、関係者が同じ判断に使える状態にします。

実践手順1：兆候、受付口、初期分類を決める

対象AIごとに、何を異常の兆候として扱うかを決めます。精度低下、有害出力、意図しない個人情報表示、 不公平な結果、権限外のツール実行、監視停止、モデルやデータの予期しない変更、利用者からの異議申立てなどです。 自動監視だけでなく、人が違和感を報告できる窓口を用意します。

受付時には、対象システム、利用場面、発見時刻、入力と出力の概要、影響対象、継続中か、再現するか、 機密情報を含むかを記録します。OECDの定義を参考に、実害が確認された「インシデント」、 被害の可能性がある「ハザード」、通常の品質改善、セキュリティ事象などへ暫定分類し、誤分類を後から修正できるようにします。

実践手順2：停止条件と代替運用を事前に合意する

NIST AI 600-1は、意図した利用と一致しない性能や結果を示すAIを停止・切り離す責任と仕組みを求め、 停止基準の定期的な見直しも提案しています。実務では、全面停止だけでなく、段階的な封じ込めを用意します。

  • 利用制限：対象ユーザー、機能、入力、外部連携を一時的に絞る。
  • 人の確認へ切替：自動実行を止め、承認が必要な助言モードや下書きへ戻す。
  • 安全な版へ戻す：検証済みのモデル、プロンプト、検索データ、設定へ切り替える。
  • 代替業務へ移る：手作業、既存システム、別チャネルで重要業務を継続する。

停止基準には、影響の重大性、拡大中か、再現性、外部への波及、検知と監督が可能かを含めます。 誰が即時停止できるか、誰へ報告するか、営業時間外の代理者、利用者への案内、代替運用の容量も決めます。

実践手順3：証拠を保全し、影響を更新し続ける

原因分析の前に、事実と推測を分けて保存します。入力と出力、時刻、モデル・アプリ・プロンプト・検索インデックスの版、 参照データ、外部ツールの呼び出し、権限、監視結果、変更履歴、利用者へ表示された説明などが候補です。 ただし、調査を理由に個人情報や機密情報を無制限に複製してはいけません。目的、閲覧権限、保持期間、マスキングを定めます。

影響評価は、停止時間だけでなく、誤判断、差別的な扱い、プライバシー、知的財産、情報の完全性、 身体・心理的安全、顧客や取引先への二次影響を確認します。対象者、件数、期間が分からない場合はゼロと扱わず、 確認済み範囲、推定範囲、不明点、次の確認時刻を記録します。

実践手順4：相手ごとに伝える内容と判断者を決める

NISTは、AIの提供者、運用者、下流の利用者、影響を受け得る関係者への連絡経路と責任を明確にすることを提案しています。 OECDの共通報告枠組みも、事象、AIシステム、影響、関係者などを比較可能な項目で記録する考え方を示しています。

社内では、経営、業務責任者、AI管理、開発・運用、セキュリティ、法務・コンプライアンス、広報、顧客対応が必要とする情報を分けます。 外部では、AI提供者、委託先、顧客、取引先、監督機関など、状況に応じた連絡先を台帳へひも付けます。 初報、更新、終報の様式を用意し、確認済み事実、暫定評価、現在の対応、利用者が取るべき行動、次回更新時刻を明確にします。

すべての事象を公開するという意味ではありません。報告義務、本人通知、契約上の連絡、証券・業界上の開示などは地域や状況で異なります。 期限や内容を独断で決めず、関係部門と必要に応じた専門家が確認します。

実践手順5：再開基準を評価し、振り返りを台帳へ戻す

復旧は、エラーが消えたことだけで決めません。原因または安全な回避策が確認できたか、影響範囲を把握したか、 修正後の評価が対象利用場面を覆うか、監視と人の監督が機能するか、再発時にすぐ止められるか、関係者への連絡が完了したかを確認します。 高リスクな利用では、限定利用、追加監視、段階的な再開を選びます。

収束後は、技術原因だけでなく、なぜ検知や判断が遅れたか、役割、評価、契約、教育、監視、変更管理のどこに弱点があったかを振り返ります。 NISTは事後レビューで対応と開示の不足を特定し、手順を更新することを提案しています。 学びをAI台帳、リスク評価、テスト項目、停止条件、ベンダー要求、教育へ戻し、類似システムへ横展開します。

注意点：止めれば安全、公開すれば透明とは限らない

  • 完全な原因特定を待たない：影響が拡大する可能性がある場合は、暫定分類と段階的な封じ込めを優先する。
  • 証拠保全とデータ最小化を両立する：調査目的に必要な情報だけを、権限と保持期間を決めて扱う。
  • 停止による二次影響を評価する：医療、福祉、顧客対応、重要業務では、代替運用なしの停止が別の危害を生むことがある。
  • ベンダー任せにしない：外部モデルの障害でも、自社の利用者対応、業務継続、下流への説明責任は残る。
  • 再開を担当者の安心感で決めない：評価結果、残存リスク、監視、承認者、見直し期限を記録する。
  • 公開範囲を一律にしない：透明性は重要だが、個人情報、機密情報、調査保全、法令・契約上の条件を確認する。
  • 海外資料を法的義務と誤解しない：NISTとOECD資料は実務の参考枠組みであり、個別の適用要件は別途確認する。

まとめ

AIガバナンスは、導入を許可する仕組みだけでは完成しません。稼働後の兆候を受け付け、事故とハザードを暫定分類し、 影響に応じて止め、証拠を保全し、関係者へ伝え、安全を確認して再開するところまでが一つの運用です。

最初の一歩は、重要なAI利用を一つ選び、「どの兆候で誰が判断し、どこまで止め、何を残し、誰へ伝え、何を確認して戻すか」を 一枚にまとめることです。机上演習で判断の迷いを洗い出し、台帳、評価、契約、監視へ反映すると、想定外を学習できるガバナンスへ近づけられます。

参考にした公式資料

本記事は公的資料をもとに一般的なAIリスク管理の考え方を整理したものであり、個別組織の法令適合性、事故認定、通知・開示義務、 契約、損害その他の法律上・専門上の助言を行うものではありません。公式資料は2026年8月10日時点で確認しています。 実際の対応では、対象地域、業界、利用目的、影響を受ける人、契約条件を踏まえ、関係部門および必要に応じた専門家へ確認してください。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る