AIインシデントレスポンスとは？Microsoft Securityが示すIR運用の変化と実務対応

AIインシデントレスポンスは、従来のIRを捨てて作り直す話ではありません。Microsoft Securityが「Same fire, different fuel」と表現している通り、火事そのものは同じでも、燃料が変わったと考えるのが実務的です。つまり、封じ込め、指揮命令、証拠保全、関係者への説明、再発防止というIRの基本は変わりません。一方で、AIシステムでは証拠の集め方、監視すべきテレメトリ、ツールの使い方、プレイブックの粒度を見直す必要があります。

特に、Microsoft Security、Microsoft Defender XDR、Microsoft Sentinel、Microsoft Security Copilotを使う組織では、「AIだから特別な別チームに任せる」のではなく、既存のSOC・CSIRT運用にAI固有の観点を足すことが重要です。2026年4月16日時点で押さえるべきポイントは、AI incident responseを新しい流行語として扱うのではなく、従来のインシデント対応能力をAIシステム向けに拡張することです。Microsoft Security Blogは、AIでは同じプロンプトが翌日に違う出力を生む可能性があり、原因も単一のコード欠陥ではなく、学習データ、コンテキスト、入力、検索結果などの相互作用になり得ると説明しています。(Microsoft)

AIインシデントレスポンスで変わるもの、変わらないもの

AIインシデントレスポンスで最初に整理すべきなのは、「何を変えるべきか」と「変えてはいけないもの」を分けることです。

従来のIRでは、マルウェア感染、認証情報の漏えい、権限昇格、不正アクセス、データ流出などを対象に、ログを確認し、侵害範囲を特定し、封じ込め、復旧、再発防止へ進みます。この流れ自体はAIシステムでも有効です。

ただしAIでは、次のような問題が起こります。

観点	従来のIR	AIシステムのIR
再現性	同じ入力で同じ結果を再現しやすい	同じプロンプトでも出力が変わる可能性がある
証拠	認証ログ、端末ログ、通信ログ、ファイル変更履歴が中心	プロンプト、応答、コンテキスト、RAGの参照元、モデル設定、フィルター判定も必要
被害分類	機密性・完全性・可用性で整理しやすい	有害出力、誤情報、差別的出力、危険手順の生成、意図しない自動実行なども含む
封じ込め	アカウント停止、端末隔離、通信遮断、パッチ適用	機能停止、プロンプト制限、出力フィルター強化、特定コネクタの無効化などが必要
検証	パッチ適用後のテストで確認しやすい	継続的なテストと監視で「再発していない傾向」を確認する必要がある

Microsoftは、AIインシデントでも「明確なオーナーシップ」「調査より先に封じ込め」「早期エスカレーション」「分かっていること・疑っていること・対応中のことを明確に伝えるコミュニケーション」は引き続き有効だとしています。つまり、IRの土台はそのまま使えます。変えるべきなのは、土台ではなく、観測対象と判断材料です。(Microsoft)

Microsoft Securityが示す「Same fire, different fuel」の意味

「Same fire, different fuel」は、AIインシデントを必要以上に神秘化しないための良い表現です。

火事、つまりインシデント対応の本質は同じです。被害を止め、影響範囲を把握し、関係者に説明し、再発を防ぐ。この流れは変わりません。

一方で、燃料が変わります。AIシステムでは、モデルの非決定性、自然言語インターフェース、外部データ連携、エージェント的な自律処理、コンテンツ安全性、利用者の誤用などが新しい燃料になります。

たとえば、社内向けAIチャットボットが機密文書を要約できる場合、従来のIRでは「誰がファイルにアクセスしたか」を追います。しかしAIインシデントでは、それだけでは足りません。

確認すべきことは次のように広がります。

• 誰がどのプロンプトを入力したか
• AIがどの文書、検索結果、ナレッジベースを参照したか
• 応答にどの機密情報が含まれたか
• 出力フィルターや分類器はどう判定したか
• 同様のプロンプトや類似パターンが他にもあったか
• その応答をユーザーがコピー、共有、外部送信したか

ここで重要なのは、AIの出力そのものを「証拠」として扱うことです。従来のログだけを見ていると、「システム上は正常に応答しただけ」に見えてしまうケースがあります。

AIシステムで証拠収集が難しくなる理由

AIインシデントレスポンスで最も実務上の差が出るのは証拠収集です。AIシステムは、プライバシー保護やデータ最小化のために入力・出力を詳細に保存しない設計になっていることがあります。これは通常時には望ましい設計ですが、インシデント時には「何が起きたのか分からない」という問題につながります。

Microsoftも、AIシステムでは最小ログ、短い保持期間、匿名化された入力といったプライバシー重視の設計が、ユーザーが何を見たのか、モデルがどのデータに触れたのか、攻撃者がどう操作したのかを調べる際のフォレンジック記録を狭める可能性があると指摘しています。(Microsoft)

AIインシデントで最低限集めたい証拠

AIシステムの運用では、平時から次の証跡を取れるようにしておくと、インシデント時の初動が速くなります。

証拠カテゴリ	具体例	使い道
入力	プロンプト、添付ファイル、ユーザー指示、会話履歴	攻撃手法、誤用、再現条件の確認
出力	AIの応答、生成ファイル、推奨アクション	有害出力、機密漏えい、誤情報の影響確認
コンテキスト	RAGで参照した文書、検索結果、プラグインの戻り値	出力の根拠、誤参照、不要なデータ露出の確認
モデル・設定	モデル名、バージョン、温度、システムプロンプト、ガードレール設定	変更前後の比較、再発防止策の検証
判定ログ	コンテンツフィルター、DLP、分類器、信頼度スコア	検知漏れ、誤検知、しきい値調整
操作ログ	ユーザー、権限、コネクタ実行、外部送信、承認履歴	権限濫用、過剰権限、二次被害の把握

ただし、すべてを無制限に保存すればよいわけではありません。個人情報、機密情報、法令・契約上の制約を踏まえ、保存対象、保存期間、閲覧権限、マスキング方法を事前に決める必要があります。

実務では、「インシデント時に必要な最小限の証拠」と「通常時に保存してはいけない情報」の境界を、セキュリティ部門だけで決めないことが重要です。法務、プライバシー、AIガバナンス、事業部門を含めて設計してください。

Microsoft Defender XDRとSentinelで見直すべき監視観点

Microsoft Securityを使う組織では、AIインシデント対応を既存のMicrosoft Defender XDRやMicrosoft Sentinelの運用に接続することが現実的です。

Microsoft Defender XDRの高度なハンティングは、最大30日間の生データを探索するクエリベースの脅威ハンティング機能で、Microsoft Defender for Endpoint、Defender for Office 365、Defender for Cloud Apps、Defender for Identity、Microsoft Sentinelなどのデータセットを横断して確認できます。(Microsoft Learn)

AIシステムのIRでは、従来の端末・ID・メール・クラウドアプリのログに加えて、AI利用のイベントを結び付ける視点が必要です。

監視すべきAI固有のシグナル

Microsoft Security Blogでは、AIインシデントで見るべきシグナルとして、異常な出力パターン、ユーザー報告の急増、コンテンツ分類器の信頼度変化、アップデート後の予期しないモデル挙動などを挙げています。(Microsoft)

実務では、次のような観点をSIEMやXDRの検知ロジックに組み込みます。

監視観点	例	初動判断
プロンプト異常	短時間に大量のプロンプト、禁止ワード回避、役割上不要な質問	レート制限、アカウント確認、類似操作の調査
出力異常	機密情報らしき文字列、危険手順、差別的・暴力的内容	出力停止、フィルター強化、影響範囲確認
データ参照異常	通常アクセスしない文書群をAI経由で参照	権限見直し、RAGソース確認、DLP調査
コネクタ実行異常	AIエージェントが外部送信、チケット作成、ファイル更新を連続実行	コネクタ停止、承認フロー追加、ロールバック
モデル更新後の変化	新モデルや新設定の後に苦情・検知が増加	変更差し戻し、A/B比較、ウォッチ期間延長

ポイントは、「AIの問題」をAI基盤だけで見ないことです。たとえば、AIチャットで機密情報が出力された場合、その前後でユーザーがSharePoint、OneDrive、Teams、メール、クラウドアプリにどのようにアクセスしたかを見る必要があります。

AIの出力は結果であり、原因はID権限、データ分類、共有設定、DLP、コネクタ設計にあることも多いからです。

Microsoft Security CopilotはIRを置き換えず、判断材料を圧縮する

Microsoft Security Copilotは、AIインシデントレスポンスにおいて「自動で全部解決する魔法のツール」ではありません。実務での価値は、膨大なアラート、ログ、タイムライン、エンティティ情報を短時間で整理し、レスポンダーが判断に集中できる状態を作ることです。

Microsoft Learnでは、Security CopilotがMicrosoft Defenderポータルに組み込まれ、インシデント調査、対応、脅威ハンティング、脅威インテリジェンス活用を支援すると説明されています。(Microsoft Learn)

また、Microsoft Defender XDRでは、Security Copilotの機能を使ってインシデント概要を作成し、攻撃開始日時、関係する資産、タイムライン、IoC、関連する次の調査プロンプトなどを確認できます。(Microsoft Learn)

Security Copilotを使う場面と注意点

使う場面	期待できる効果	注意点
インシデント概要の作成	初動メンバーが状況を早く把握できる	要約を事実として鵜呑みにせず、元ログで確認する
タイムライン整理	攻撃や誤動作の流れを説明しやすくなる	時刻、タイムゾーン、ログ欠損に注意する
KQL作成支援	ハンティングの初速を上げられる	生成クエリの対象テーブル、期間、条件を確認する
報告書の下書き	経営層・法務・顧客向け説明を整理しやすい	断定表現、未確認事項、影響範囲の表現をレビューする
関連エンティティ調査	ユーザー、端末、IP、URLの関係を追いやすい	権限不足やデータ未連携による抜けを考慮する

Security Copilotは、レスポンダーの代わりに責任を負う存在ではありません。AIによる要約や推奨は、意思決定前の「圧縮された判断材料」として扱うべきです。

特にAIインシデントでは、生成AIの出力、Copilotの要約、実際のログが混ざりやすくなります。報告書では「確認済みの事実」「推定」「未確認」を明確に分けてください。

AIインシデント対応プレイブックに追加すべき項目

AIシステム向けのプレイブックは、従来のIRプレイブックを全面的に置き換えるものではありません。既存の「検知」「トリアージ」「封じ込め」「調査」「復旧」「事後対応」に、AI固有の確認項目を追加する形が現実的です。

Microsoft Sentinelでは、自動化ルールを使ってインシデントやアラートへの対応を管理・オーケストレーションできます。ルール設計では、対象範囲、トリガー、条件、アクションを事前に決めることが推奨されています。(Microsoft Learn)

AIインシデント用プレイブックの実務例

フェーズ	実施内容	判断基準
検知	ユーザー報告、異常出力、DLP検知、分類器スコア変化を確認	単発か、複数ユーザー・複数出力で再現しているか
初期封じ込め	対象機能の一時停止、レート制限、特定プロンプト・出力のブロック	被害が継続しているか、業務影響が許容範囲か
影響範囲確認	類似プロンプト、同一ユーザー、同一データソース、同一モデル設定を検索	影響が特定ユーザーか、全社機能か
原因調査	RAG参照元、権限、モデル設定、ガードレール、直近変更を確認	単一原因か、複数要因の組み合わせか
恒久対応	分類器更新、データ権限見直し、コネクタ制御、承認フロー追加	回避プロンプトや類似ケースにも耐えられるか
ウォッチ期間	再発監視、ユーザー報告監視、出力サンプリング	一度のテストで終えず、一定期間の傾向で確認する

Microsoftは、AIインシデントの修復を「Stop the bleed」「Fan out and strengthen」「Fix at the source」の3段階で捉えています。最初に既知の悪い入力のブロック、フィルター適用、アクセス制限で被害を止め、次に関連パターンへ対策を広げ、最後に分類器やモデル、システム設計を修正する考え方です。(Microsoft)

この考え方は実務に落とし込みやすいです。最初から完璧な根本原因を探していると、被害が広がります。まず止血し、その後で広げ、最後に根本対策を行う順番をプレイブックに明記してください。

Severity判断は「技術的深刻度」だけで決めない

AIインシデントの難しさは、重大度の判断にもあります。

たとえば、AIが誤った回答を出したとしても、雑学の回答と医療・金融・法務・セキュリティ手順の回答ではリスクがまったく違います。同じ「不正確な出力」でも、誰が受け取り、何に使い、どの程度拡散したかで深刻度は変わります。

AIインシデントのSeverityでは、少なくとも次の観点を加えてください。

• 影響を受けたユーザー数
• 出力内容の種類
• 機密情報、個人情報、規制対象データの有無
• 危険行為や違法行為につながる可能性
• 自動実行された操作の有無
• 外部共有やSNS拡散の有無
• 社会的・倫理的な影響
• 事業継続や顧客信頼への影響

Microsoft Security Blogも、AIインシデントでは従来の機密性・完全性・可用性だけでは分類しにくい害があり、危険な指示の生成、特定集団を対象にしたコンテンツ、自然言語インターフェースを通じた誤用などを考慮する必要があると説明しています。(Microsoft)

Severity分類の例

Severity	例	初動
Low	社内FAQ botが古い手順を案内したが、影響は限定的	ナレッジ更新、再発監視
Medium	特定部署の内部情報を、本来見えないユーザーに要約した	対象機能停止、権限調査、影響者通知
High	個人情報や顧客データをAI出力に含めた可能性がある	法務・プライバシー部門へ即時連携、証拠保全
Critical	AIエージェントが外部送信、削除、権限変更などを誤実行した	コネクタ停止、全社影響調査、経営層報告

ここでの注意点は、AIインシデントを過小評価しないことです。「モデルの回答が少し変だった」ではなく、「誰にどの影響が出たか」で判断してください。

AIエージェント時代は「権限」と「実行」を分けて考える

生成AIがチャットで回答するだけなら、主なリスクは出力内容です。しかし、AIエージェントがメール送信、ファイル更新、チケット作成、ワークフロー実行、外部API呼び出しを行う場合、インシデントの性質は大きく変わります。

この場合、調査では「何を答えたか」だけでなく、「何を実行したか」を追う必要があります。

実務では、AIエージェントに次の制御を入れてください。

• 高リスク操作には人間の承認を必須にする
• 削除、外部送信、権限変更、支払い、契約関連操作は別扱いにする
• AIが使えるコネクタを業務単位で制限する
• 実行ログを通常の監査ログと紐付ける
• 一定回数以上の連続実行や異常な失敗を検知する
• 緊急停止できるキルスイッチを用意する

AIエージェントのIRでは、封じ込めも変わります。アカウント停止だけでは足りず、対象エージェント、プラグイン、コネクタ、APIトークン、承認済みアプリを止める必要があります。

失敗しやすいポイント

AIインシデント対応でよくある失敗は、技術的な高度さよりも、準備不足から起こります。

ログを取っていない

最も多い失敗は、インシデントが起きてから「プロンプトと出力が残っていない」と気付くことです。プライバシー保護は重要ですが、調査に必要な証跡まで消してしまうと、影響範囲を説明できません。

対策は、保存するデータを最小化しつつ、インシデント時に必要な識別子やメタデータを残すことです。全文保存が難しい場合でも、会話ID、ユーザーID、参照データID、モデル設定、分類器判定、出力リスクラベルを残すだけで調査効率は大きく変わります。

「プロンプトブロック」で恒久対応にしてしまう

特定の危険プロンプトをブロックすることは初動として有効です。しかし、それだけでは回避表現に弱くなります。

Microsoftも、戦術的な許可リスト・ブロックリストはトリアージには必要だが、永続的な解決策としては不十分で、分類器やシステム的な修正がより持続的な答えだと述べています。(Microsoft)

ブロックリストは「止血」、分類器更新や権限設計の見直しは「治療」と分けて考えてください。

AIの要約をそのまま報告書に貼る

Security CopilotなどのAI支援は便利ですが、報告書にそのまま貼るのは危険です。要約には、前提の抜け、ログ欠損、推定の混入があり得ます。

報告書に入れる前に、次の3分類で確認します。

区分	書き方の例
確認済み	「4月16日 10:12に対象ユーザーが該当機能を使用したことをログで確認」
推定	「類似プロンプトの傾向から、同一手法による試行の可能性がある」
未確認	「外部共有の有無は調査中」

この整理だけで、経営層、法務、顧客対応チームとの認識ずれを減らせます。

レスポンダーの負荷を軽視する

AI安全性に関わるインシデントでは、暴力的、差別的、性的、搾取的、または精神的負荷の高いコンテンツを確認する可能性があります。Microsoftも、AIの悪用報告や安全性インシデントを扱う防御側は有害コンテンツにさらされ、長期化するほど心理的負荷が高まると指摘しています。(Microsoft)

プレイブックには、交代制、レビュー時間の上限、心理的負荷の高い作業の分担、マネージャーによる休憩指示、ピアサポートを入れてください。人が疲弊すると、判断ミス、記録漏れ、説明ミスが増えます。

セキュリティリーダーが今すぐ確認すべきチェックリスト

AIインシデントレスポンスは、発生してから整備するものではありません。Incident respondersとsecurity leadersは、次の項目を現状確認してください。

確認項目	できていない場合のリスク
AI機能・AIエージェントの一覧がある	どの機能を止めるべきか判断できない
AIが参照できるデータソースを把握している	機密情報の露出範囲を追えない
プロンプト・出力・参照元の証跡方針がある	インシデント時に事実確認できない
Severity分類にAI固有の害を含めている	有害出力や誤情報を過小評価する
Microsoft Defender XDRやSentinelにAI関連ログを連携している	既存SOCで検知・相関分析できない
Security Copilotの利用ルールがある	AI要約を過信した判断が起きる
AI機能の停止・制限手順がある	被害を止めるまでに時間がかかる
法務・プライバシー・広報との連絡基準がある	外部説明や通知判断が遅れる
ウォッチ期間の運用がある	修復後の再発を見落とす
レスポンダーの心理的負荷対策がある	長期対応で品質が落ちる

まず取り組むべきは、AIシステムの棚卸しとログ設計です。高度な自動化やAIによる分析支援は、その次で構いません。見えていないものは守れず、記録していないものは説明できません。

Microsoft Security環境での実装イメージ

Microsoft Securityを中心に運用している場合、次のような構成で考えると整理しやすくなります。

• Microsoft Defender XDR：ID、端末、メール、クラウドアプリ、アラート相関、インシデント管理
• Microsoft Sentinel：SIEM/SOAR、外部ログ連携、分析ルール、自動化ルール、プレイブック
• Microsoft Security Copilot：インシデント要約、調査支援、KQL作成支援、報告書作成支援
• Microsoft Purview：データ分類、DLP、情報保護、監査
• Microsoft Entra：ID、条件付きアクセス、権限、アプリ同意、ワークロードID管理

Microsoft SentinelとSecurity Copilotの連携では、SentinelデータをDefenderポータルのSecurity Copilotと統合でき、インシデント要約やセキュリティデータに関する回答取得、自然言語からKQLへの支援などに活用できます。(Microsoft Learn)

ただし、製品を導入しただけではAIインシデント対応は完成しません。必要なのは、次のような運用設計です。

1. AIシステムのログをどこに集めるか決める
2. AI固有のイベントを共通スキーマで整理する
3. Defender XDRやSentinelの既存インシデントと紐付ける
4. 初動時にSecurity Copilotで要約し、元ログで確認する
5. Sentinelの自動化ルールやプレイブックで通知・タスク化する
6. 修復後も一定期間ウォッチし、再発傾向を監視する

この流れを作ると、AIインシデントを「特殊対応」ではなく、既存SOCの延長として扱えます。

まとめ：AI incident responseはIRの再発明ではなく、運用能力の拡張

AIインシデントレスポンスで最も重要なのは、従来のIRを否定しないことです。封じ込め、証拠保全、影響範囲の特定、関係者への説明、再発防止という基本は変わりません。

変わるのは、見るべき証拠です。プロンプト、出力、コンテキスト、RAG参照元、分類器スコア、モデル設定、AIエージェントの実行ログを扱えるようにする必要があります。

Microsoft Securityが示す「Same fire, different fuel」という考え方は、実務にそのまま使えます。火事への対応手順は持っている。しかし、燃え方が変わった。だから、監視、証拠、ツール、プレイブックを更新する。これがAI incident responseの現実的な進め方です。

まずは、自社のAI機能を棚卸しし、ログ設計と初動プレイブックを見直してください。そのうえで、Microsoft Defender XDR、Microsoft Sentinel、Microsoft Security Copilotを使い、AI固有のシグナルを既存のSOC運用に接続することが次の一手です。