インシデント対応

NIST AI RMFのManage機能で組む、AIインシデント初動対応フロー

2026年6月29日15分で読める

QUICK CHECK

本文を読みながら、自社で進めるべきか、相談前に何を整理するかを確認できます。

GXO COLUMN

セキュリティ

AIを業務に組み込むと、これまでの障害対応では捉えきれない種類の事故が起きるようになります。サーバーが落ちるわけでも、エラーが出るわけでもなく、AIが自信ありげに誤った回答を返し、誤った宛先に情報を送り、想定外のツールを実行してしまう。NISTはこうした状況を、AIが攻撃の対象にも、リスクの発生源にもなる新しい種類のインシデントとして整理し、AIインシデント管理に関するワークショップを通じて、組織横断で対応のあり方を議論しています。本記事では、NIST AI RMF（AIリスクマネジメントフレームワーク）のManage機能を土台に、AI事故が起きた瞬間から動ける初動フローを実務として組み立てます。

結論：AI事故は「気づいてから」ではなく「気づける設計」で備える

AIインシデントへの備えで決定的なのは、事故が起きてから対応手順を考えるのではなく、通報を受け、ログを保全し、止めるか判断し、影響を調べ、報告し、再発を防ぐという流れを、平時にあらかじめ決めておくことです。AIの事故は影響が後から判明することが多く、初動の数時間で何を保全したかが、後の調査の精度を左右します。

この記事が役に立つのは、AIをすでに本番で動かしている企業の情報システム部門、セキュリティ担当、法務、内部監査、そして報告を受ける経営層の方です。NIST AI RMFは一過性の話題ではなく、AIを運用し続ける限り回し続ける恒常的な管理の枠組みとして使えます。GXOでは、インシデント対応支援を入口に、いまのAI利用でログがどこまで残っているか、止める権限が誰にあるかといった初動の前提から確認します。事故が起きる前のログ・権限・監視の継続的な整備はセキュリティ運用伴走、本番投入前の備えの点検はPoC・本番化レディネス診断が対応します。

SECURITY OPERATION

日常の脆弱性運用、情シス1人で回せる体制にしませんか？

月次棚卸・重大度判定・パッチ適用代行まで含む「セキュリティ運用伴走」プラン。単発対応からの卒業で、止まらない運用体制を作ります。

運用プランを相談する

なぜ従来の障害対応の延長では足りないのか

これまでの障害対応は「動いているか、止まっているか」を起点に組まれてきました。ところがAIの事故は、システムが正常に稼働したまま、出力の中身が間違っているという形で起きます。チャットボットが誤った社内規程を案内し続ける、要約AIが事実と異なる数値を作る、エージェントが連携先のシステムへ誤った更新をかける。いずれも監視ダッシュボードは緑のまま進行します。

NIST AI RMFは、Govern（統治）、Map（特定）、Measure（測定）、Manage（対処）の4機能で構成されます。このうちManage機能は、特定・測定されたリスクへの対処に資源を割り当てる役割を担い、インシデント対応手順の整備、復旧、関係者への伝達、そして学んだ教訓をGovernへ戻すところまでを含みます。AI事故の初動フローは、このManage機能を自社の現場手順へ落とし込む作業だと捉えると、設計の軸が定まります。

AIインシデント初動フローの全体像

AI事故の初動は、次の6段階で考えると抜けが減ります。各段階は順番に進むだけでなく、影響が読めない局面では「止める」へ先回りする判断も含みます。

横にスクロールして確認できます

段階	この段階でやること
通報	AI起因の異常を受け付ける窓口を決め、通常の障害窓口と切り分けて記録する
ログ保全	プロンプト、AIの出力、ツール実行履歴、参照したデータを上書き前に確保する
停止判断	影響範囲が読めないときに、利用停止または権限縮小を即断できる権限者を置く
影響調査	誤出力や誤実行がどの相手・どのデータに及んだかを、保全したログから追う
報告	顧客、社内、監督官庁への報告要否を、事実関係が固まる前段階から検討する
再発防止	モデル、データ、権限、業務手順のどれを直すべきかを切り分けて対策する

この6段階を1枚の手順書にまとめ、誰が各段階の責任者かを名前で埋めておくことが、初動を速める最大の準備になります。

FREE DOWNLOAD

AI導入チェックリスト（PoC 失敗要因 10項目）

情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。

30分で相談するチェックリストをDL

ログ保全がAI事故対応の成否を分ける理由

6段階の中で、平時の準備が最も効くのがログ保全です。AI事故の調査では、「AIが何を入力され、何を出力し、その結果どのツールがどう動いたか」を時系列で再現できるかどうかが、原因特定の可否を決めます。ここで具体的に問題になるのが、保全すべき対象が一般的なシステムログより広いという点です。

たとえば社内文書を検索して回答するAIが誤った機密情報を提示した場合、調査に必要なのはアクセスログだけではありません。利用者が入力したプロンプト、AIが内部で参照した文書のバージョン、回答に至るまでに呼び出した検索や外部APIの履歴が揃って初めて、なぜその誤りが起きたかを説明できます。これらは保持期間が短く設定されていたり、そもそも記録されていなかったりすることが多く、事故後に取りに行っても残っていません。だからこそ、初動フローを作る前段階として、何をどれだけの期間ログに残すかを決めておく必要があります。ログ設計はManage機能の対処を支える土台であり、ここが弱いと、後段の影響調査も報告も精度を欠きます。

初動フローを定着させる手順

手順書を作っただけでは、実際の事故の場面で動けません。次の流れで、平時に役割と判断基準まで固めておくことをおすすめします。

AI起因の異常を受け付ける窓口を決め、通常の障害・問い合わせと識別できるようにする
AIごとに保全すべきログ（入力、出力、ツール実行、参照データ）と保持期間を定義する
影響範囲が不明な状況で利用停止や権限縮小を即断できる権限者を、役職とともに明文化する
顧客・社内・監督官庁への報告基準を、事実確定を待たずに判断できる形で用意する
再発防止で「モデルを直す」「データを直す」「権限を直す」「業務手順を直す」を切り分ける枠を持つ

この順序で整えると、事故のたびに場当たりで判断していた状態から、誰が、何を、どこまでの権限で決めるかが定まった状態へ移せます。GXOが初動設計の相談でまず見るのは、AIの製品名ではなく、現状どのログが残っていて、誰が止める権限を持っているかという運用の足元です。

事前に確認しておくチェックリスト

AI起因の異常を受け付ける窓口が、通常の障害窓口と区別して決まっているか
プロンプト、出力、ツール実行、参照データのログを、調査に足る期間だけ保持しているか
影響範囲が読めないときに、利用を即時停止できる権限者が明確になっているか
顧客・社内・監督官庁への報告基準を、事実確定前でも判断できる形で持っているか
再発防止策を、モデル・データ・権限・業務手順のどこを直すかで切り分けられるか
事故対応で得た教訓を、運用ルールやガバナンスへ戻す経路があるか

複数の項目が未整備のままなら、新しいAIを増やす前に、いま動いているAIの初動フローを先に固めておく方が安全です。まずはインシデント対応支援で、ログの残り方と停止権限の現状を確認することから始められます。

つまずきやすい点

AI事故対応で行き詰まりやすいのは、止める判断を現場が抱え込んでしまう構図です。影響範囲が読めない局面ほど、利用停止には「業務を止めてよいのか」という重い判断が伴い、権限が曖昧だと誰も決められず時間だけが過ぎます。NIST AI RMFのManage機能が停止や権限縮小を対処の選択肢として明示しているのは、止める判断を平時に承認しておくべきだからです。もう一つの落とし穴は、再発防止をモデルの再学習だけに矮小化することです。多くのAI事故は、モデルそのものより、与えた権限や参照データ、業務上のチェック手順の欠落から生まれます。原因を切り分けないまま「モデルを直した」で終えると、同じ事故が別の形で再発します。

GXOに相談するとよい場面

次のような状況にあてはまるなら、事故が起きる前に初動フローを整えておくことをおすすめします。

AIを本番で使い始めたが、誤回答や誤実行が起きたときの受付窓口と止め方が決まっていない
ログは取っているつもりだが、調査に必要なプロンプトやツール実行履歴が残っているか不安がある
AIインシデントの報告基準や、監督官庁への連絡要否の判断軸を持っていない
AI事故対応をCSIRTやセキュリティ運用の枠組みへ組み込みたいが、設計の入口が見えない

AIインシデントの初動フローを一緒に固めませんか

NIST AI RMFのManage機能を土台に、通報窓口、ログ保全範囲、停止権限、報告基準、再発防止の切り分けまで、自社のAI運用に合わせた初動フローの形を一緒に組み立てます。

AI事故の初動対応を相談する

初回相談では、対策製品の説明よりも、いまのログ・権限・報告経路に何が足りないかの洗い出しを優先します。

実務判断のポイント

この記事は、経営者、CIO、情シス、セキュリティ担当、開発責任者向けです。脆弱性管理、外部公開資産棚卸し、月次セキュリティ運用、インシデント対応を自社で進めるか、外部の専門家と整理するかを判断する材料として使えます。

GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。NIST AI RMFのManage機能で組む、AIインシデント初動対応フローに関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。

放置した場合と整備した場合の違い

横にスクロールして確認できます

観点	放置した場合	整備した場合
業務影響	属人的な判断が増え、対応の優先順位がぶれやすい	影響範囲、期限、責任者を決めて進められる
投資判断	ツール導入や外注費だけが先行し、効果測定が曖昧になる	売上、工数削減、リスク低減の指標にひも付けられる
現場運用	例外処理や承認フローが残り、定着しにくい	権限、ログ、教育、改善サイクルまで設計できる
経営報告	問題が発生してから説明資料を作ることになる	月次で状況、課題、次の打ち手を説明できる

導入・改善前のチェックリスト

対象業務、対象部門、対象データを明文化しているか
現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
例外処理、承認、差し戻し、監査証跡まで確認しているか
社内で判断できる範囲と外部支援が必要な範囲を分けているか
初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
経営判断に必要な資料を1枚で説明できる状態にしているか
次の90日で検証する範囲と、やらない範囲を明確にしているか

GXOの見解

セキュリティニュースは読むだけでは価値がなく、自社資産、影響判定、対応期限、経営報告に変換して初めて防御力になる。

GXOは単発診断よりも、月次の棚卸し、優先順位付け、証跡管理、改善実行までを運用化すべきだと見る。

自社だけで整理が難しい場合、GXOは脆弱性診断、インシデント対応、月次運用、開発保守の改善まで接続できる。最初から大規模な発注を前提にせず、現状整理や診断から必要な範囲を確認できます。

実行までの進め方

現在の業務、データ、ツール、担当者を棚卸しする
売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
初期対応、90日以内の改善、半年以上の投資を分ける
必要な社内体制、外部支援、予算、セキュリティ確認を整理する
小さく検証し、効果測定後に本番化や横展開を判断する

よくある質問

システム障害の対応手順があれば、AI事故にもそのまま使えますか

完全には流用できません。従来の障害対応は稼働しているかを起点にしますが、AI事故はシステムが正常に動いたまま出力が誤るため、ログとして残すべき対象や、止めるか継続するかの判断軸が異なります。既存の対応手順を土台にしつつ、プロンプトや参照データの保全、誤出力の影響調査といったAI固有の段階を足す形が現実的です。

どのログを残しておけば、AI事故の調査に足りますか

最低限、利用者の入力したプロンプト、AIの出力、AIが呼び出したツールや外部APIの履歴、回答時に参照したデータのバージョンが必要です。これらが揃って初めて、なぜその誤りが起きたかを時系列で説明できます。保持期間が短すぎると事故後に取りに行っても残っていないため、平時に保全範囲と期間を決めておくことが重要です。