利益:
- AI 固有のインシデント タイプを分類し、対応サイクルを設計する能力
- イベント前に役割、権限、法的報告義務を定義する能力
- ビジネス継続性と責任のない事後分析により永続的な改善を確立する能力
どれだけうまく防御していても、いつか何か問題が起こるでしょう。キーが漏洩したり、インジェクションが機能したり、プロバイダーがクラッシュしたり、出力が顧客に損害を与えたりします。成熟した組織を成熟させるのは、イベントがないことではなく、イベントが発生したときに備えて迅速に対応できることです。この単元では、AI 固有のインシデント対応計画、役割、手順、ビジネス継続性を学びます。
AI ではインシデント対応が異なるのはなぜですか?
古典的なセキュリティ インシデントでは、多くの場合、「システムをシャットダウンして隔離する」だけで十分です。 AI イベントには追加の側面があります。イベントはコード内にあるのではなく、モデルの動作内にある可能性があります (例: 系統的に不正確/偏った出力)。証拠はプロンプト/応答ログにあります。また、誤った出力がすでに決定されているため、「元に戻す」ことができない場合があります。したがって、AI インシデント計画では、古典的なセキュリティとモデルの動作の両方をカバーする必要があります。
注意: 事件発生時には、計画は書かれておらず、それが実行されます。誰が誰に電話をかけるのか、誰が「システムを停止する」権限を持つのか、どのようにコミュニケーションを行うのかをイベント前に決めておく必要があります。
AI イベントの種類
- データ漏洩: PII または機密データが (プロンプト、ログ、または出力経由で) 漏洩しました。
- セキュリティ侵害: キーの漏洩、インジェクションの成功、不正アクセス。
- 有害/偏った出力: モデルは、不正確、差別的、または危険な反応を体系的に生成しました。
- サービス停止: プロバイダーがクラッシュしたか、速度制限に達しました。システムが応答できません。
- 悪用: システムは、設計されていない有害な目的で使用されました。
ステップバイステップ: インシデント対応サイクル
- 検出。監視アラーム、ユーザーからの苦情、または監査結果によってインシデントが明らかになります。
- 並べ替えて優先順位を付けます。影響と広がりに基づいてレベルを指定します (例: P1 重大 – P3 低)。
- 含む。拡散を阻止します。キーを取り消し、機能をオフにし、システムを読み取り専用にします。
- 撲滅＆回復。根本原因を修正し、安全な状態に戻します。
- 報告してください。法的/契約上の通知義務 (KVKK 72 時間など) および影響を受ける人々にタイムリーに通知します。
- イベント後の検査（死後）。責めることなく、根本原因と恒久的な修正を文書化してください。
役割と責任
インシデントの際に誰が何をするのかを明確にする必要があります。インシデント指揮官 (唯一の意思決定者)、技術的対応 (システムの停止/修復)、コミュニケーション (顧客/管理者/規制当局)、法務/コンプライアンス (報告義務) です。小規模なチームでは、1 人が複数の役割を担うことができますが、その役割を記述する必要があります。
4 つのコピー可能なテンプレート
イベント分類プロンプト:
次のイベントを分類します: {{event_description }}特定:- タイプ: データ漏洩 / セキュリティ侵害 / 悪意のある出力 / 停止 / 悪用 - 影響: 何人/レコード、どのデータ クラス、金銭/コンプライアンスへの影響? - 伝播: 停止中か進行中? - 優先度: P1 / P2 / P3 + 正当性 - 最初の制御ステップ: すぐに行うべきことは何ですか?
最初の対応 (封じ込め) チェックリスト:
インシデントが確認された最初の 30 分間: - [ ] 影響を受ける機能/ツールを無効にするか、読み取り専用に設定します - [ ] 疑わしいキー/セッションをキャンセルします - [ ] 証拠を保存します (関連ログを凍結し、trace_id を記録します) - [ ] インシデント コマンダーと必要な役割に通知します - [ ] 一時的なセーフ モード/バックアップ フローを展開します
通知ドラフトのプロンプト:
次のインシデントに関する内部通知の下書きを作成します: {{ Incident_summary }}含める必要があります: 何が起こったのか (非専門用語で)、いつ気づいたのか、どのデータ/誰が影響を受けたか、これまでに行われたこと、次のステップ、追加情報の入手先。憶測や非難は含まないでください。
死後の骨格:
イベント後のレビュー (責任なし):- タイムライン: 検出 -> 制御 -> 回復 (分単位) - 根本原因: 技術 + プロセス サイズ - 何がうまくいったか、何がうまくいかなかったのか - 永続的な修正 (誰が、いつ) - このイベントを早期に検出するための監視/制御
弱いプロンプト / 強いプロンプト
下手なアプローチ
強力なアプローチ
計画なしでイベントで即興で行う
事前に作成された計画、役割、権限
まず「誰が有罪か」を言う
最初に封じ込め、次に咎めなしの死後処理
遅延/スキップ通知
法定期間内（例：72時間）の通知
また同じイベントが起こるのを待っている
事後分析から永続的な制御を抽出する
ミニケース3個
ケース 1 — 72 時間ルール内に収まった。ある企業の従業員は、設定ミスにより 1,200 件の顧客レコードがログに残されたままになっていることに気付きました。文書化された計画のおかげで、事件指揮官は明確でした。チームは40分以内にアクセスを閉鎖し、法律は72時間以内にKVKKに通知した。タイムリーな報告により、犯罪リスクと風評被害が大幅に軽減されました。
ケース 2 — 読み取り専用セーフ モードで障害を処理しました。メインモデルプロバイダーは3時間外出しました。同社の事業継続計画には、バックアッププロバイダーと「セーフモード」（重要な機能のみ）への切り替えが含まれていた。ユーザーは完全な機能を失いましたが、システムは存続しました。重要な業務は停止しませんでした。
ケース 3 — 死後検査により再発が防止されました。間接インジェクションが成功すると、別のユーザーのデータがアシスタントに漏洩しました。責任を問わない事後分析により、根本原因は <データ> 分離の欠如であることが判明しました。恒久的な修正 (分離 + 出力スキャン + 回帰テスト) を追加しました。同じクラスの攻撃は再び成功しませんでした。
ヒント: 咎めを持たずに事後分析を行ってください。目的は人を見つけることではなく、同じ事件を二度と起こさないように体制を強化することだ。非難の文化により、人々は物事を隠すようになりますが、これが最も危険です。
よくある間違い
- イベント前に書面による計画と役割分担を準備していない。
- 主導権を握る前に口論や非難を始める。
- 法的通知義務がありません (KVKK/GDPR の期限)。
- 証拠（ログ）を保存せずにシステムをリセットする。
- ビジネス継続のためのバックアップ プロバイダー/セーフ モードは考慮されていません。
- 事後検証を行わず、同じ出来事が繰り返される余地を残しておきます。
要約すると
- 成熟とは、出来事が存在しないことではありません。それは、起こったときに備えて迅速に対応できることを意味します。
- AI イベントはコードではなくモデルの動作に含めることができます。証拠はプロンプト/応答ログにあり、逆転が常に可能であるとは限りません。
- 対応サイクル: 検出、分類、封じ込め、回復、報告、事後分析。
- 役割と権限 (インシデント指揮官、技術、通信、法務) はイベント前に書面で定めておく必要があります。
- ビジネス継続のためのバックアッププロバイダー/セーフモード。事件の余波に対しては、非難のない事後調査と恒久的な是正が不可欠です。
アプリケーションタスク
独自の AI システムのインシデント対応計画の草案を作成します。最も可能性の高い 3 つのインシデント タイプをリストし、最初の 30 分間の封じ込めチェックリストとそれぞれの役割を特定します。次に、机上演習を行います。「キーの漏洩」シナリオを段階的に実行し、計画に不足している点やあいまいな点を指摘し、修正します。
チェックリスト
- [ ] インシデント対応計画と役割分担が書面で定められています。
- [ ] 誰が「システムを停止する」権限を持っているかは明らかです。
- [ ] 最初の 30 分間の封じ込めチェックリストが完成しました。
- [ ] 法的な通知期間と責任者が定められています。
- [ ] ビジネス継続のために計画されたバックアップ プロバイダー/セーフ モード。
- [ ] インシデントごとに、責任のない事後検証と恒久的な修正が行われます。