AIへ誤った資料を送った、回答を違う相手へ送信した、secretを会話やlogへ出した疑いがある場合、最初に拡散する経路を止め、対象・時刻・行先・現在状態を確認します。「削除したから解決」「学習に使われないから影響なし」と先に結論づけず、送信・保存・共有・利用の範囲を分けて記録します。
本稿は社内初動手順を作るための例です。事故対応、account停止、credential失効、削除、関係者への通知は実施していません。法的な報告要否や期限を決める記事ではなく、適用する規程と法務・privacy・security担当の判断へ必要な情報をそろえます。
目次
発見時点の事実と、未確認を分ける
発見時刻、対象service、account/project、操作、data区分、送信先、共有範囲、元の依頼を記録します。実際に送信されたのか、下書きだけか、tool要求後に結果が分からないのかを分けます。記録を集めるため同じdataを再送しないようにします。
表は横にスクロールできます
| 事象 | 最初の確認 | 別に調べること |
|---|---|---|
| AIへ誤upload | ファイル ID・account・保存状態 | 共有・保持・連携先 |
| 誤送信 | message ID・宛先・delivery | 閲覧・転送・download |
| 公開link | 公開範囲と有効状態 | copy・index・cache |
| secret露出 | credential識別と用途 | 利用履歴・依存system |
| 不審なagent操作 | tool・対象・結果 | 入力資料と権限境界 |
証拠にはsecretや個人情報を重複させず、制限された保存先の参照を使います。誤った本文を社内の広いchatへ貼って相談すると、調査そのものが新しい拡散になります。担当窓口へ必要な識別情報だけを渡す書式を用意します。
拡散経路と自動処理を、影響範囲に沿って止める
継続送信するworkflow、公開link、共有、同期先、定期処理など、現在も影響が増える経路を特定します。停止で別の業務が壊れる場合は、対象を絞り、担当者が状態を記録して実施します。原因不明のまま全logやaccountを消して証拠を失う方法にはしません。
露出したcredentialは、ファイルの行を消すことと利用を止めることを分けます。OWASPのsecret対応資料（新しいタブで開く）は、露出したkeyの失効・切替と関連記録を扱っています。通常rotationの無停止手順を、侵害が疑われる緊急対応へそのまま当てはめず、依存serviceと影響をsecurity担当が判断します。
dataの行先を段階別に追う
入力された会話やファイル、AI serviceの保存、connector/検索index、出力、送信先、export、cache、backupを分けます。画面から見えなくなったことが、すべてのcopyの削除を意味するとは限りません。service側の削除・保持・support対応の範囲を現行公式条件で確認します。
送信先が一人でも、その人の転送やdownloadを確認できなければ不明です。一方、確認できないだけで全世界へ流出したと断定もしません。閲覧可能範囲、実際のアクセス記録、copyの可能性を別欄に残します。
社内の判断担当へ、短い事実表を渡す
NIST SP 800-61 Rev.3（新しいタブで開く）は、incident responseを組織のrisk managementへ組み込む考え方を示しています。自社手順では、初動担当、技術調査、privacy/法務、業務owner、対外連絡の責任を明確にします。AIが作った説明を、そのまま通知内容の確定や法的判断にしません。
表は横にスクロールできます
| 報告欄 | 残す内容 | 不明なら |
|---|---|---|
| 対象 | service・account・data区分 | 調査中と明示 |
| 発生と発見 | それぞれの時刻と根拠 | 観測区間を記録 |
| 影響 | 確認できた受信者・操作 | 推定と確定を分ける |
| 封じ込め | 実施内容と実施者 | 予定を完了としない |
| 残課題 | copy・利用・復旧条件 | 担当と次の確認 |
送信先への削除依頼、service提供元への問い合わせ、利用者への説明は、対象と内容を決めた責任者の手順で行います。自動で全員へ通知したり、事故内容を公開したりする工程を、初動scriptへ無条件に含めません。
復旧条件と、再開後の確認を決める
漏れた経路を直したこと、必要なcredentialが切り替わったこと、共有が意図した範囲へ戻ったこと、滞留処理を二重実行せず再開できることを別々に確認します。errorが消えたことだけで影響調査を終了しません。
誤送信やuploadを取り消せても、すでに利用されたcopyまでは戻せない場合があります。回復できた範囲とできない範囲を残し、必要な監視や追加確認を担当へ引き継ぎます。復旧確認で実機密をもう一度同じ経路へ流すのではなく、害のないfixtureで再発条件を確認します。
原因と改善を、結果に合わせて見直す
誤った宛先選択、過大権限、tool出力、資料内の不審指示、data分類漏れ、review不足など、実際の記録から原因を分けます。「AIが悪い」「利用者の注意不足」だけでは、どの境界を改善するか決まりません。
改善記録には、変更した権限・入力・送信確認・logの範囲、検証したcase、残る不明、手順ownerを残します。削除・通知・復旧の予定と完了を区別し、関係者が同じ事実表から判断できる状態にします。