---

title: "NIST AI RMFのManage機能で組む、AIインシデント初動対応フロー" slug: "nist-ai-incident-management-first-response-flow-20260608" description: "NIST AI RMFのManage機能とAIインシデント管理の考え方をもとに、AIの誤回答・誤実行・情報漏えいが起きたときの通報、ログ保全、停止判断、影響調査、報告、再発防止までの初動フローを実務手順で解説します。" lead_summary: "AIの事故は、システムが止まる障害とは違い、誤った出力や誤った操作として静かに進むことがある。NIST AI RMFのManage機能を土台に、通報からログ保全、停止判断、影響調査、報告、再発防止までの初動フローを事前に決める方法を整理する。" date: "2026-06-29" updatedAt: "2026-06-29" category: "セキュリティ" tags: ["NIST","AIインシデント","AIリスク","インシデント対応","ログ","CSIRT"] author: "GXO株式会社"

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

つまずきやすい点

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

GXOに相談するとよい場面

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

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

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

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

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

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

よくある質問

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

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

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

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

再発防止はモデルを作り直せばよいのではないですか

多くのAI事故は、モデルそのものより、過剰な権限や誤った参照データ、業務上のチェック不足が原因です。再発防止では、モデル・データ・権限・業務手順のどこを直すべきかを切り分けてから対策します。原因を特定せずにモデルだけ更新しても、同じ事故が別の経路で繰り返される恐れがあります。

参照元

• NIST Workshop on AI Incident Management
• NIST AI Risk Management Framework