AI Security Playbook

手順 / 約18分

漏えい・異常・消失に気づいたとき、最初にすること

AIに削除・交換を案内された後まで。失効・履歴・保全・復旧を分け、対象に応じた初動と再開条件を整理する。

入門 · 専門知識は不要です。異常に気づいたときの初動を役割別に確認します。

読む前の補足
  • 確認した事実と推測を分けて記録する。
  • 事故の種類に応じて相談と拡大防止を選ぶ。
  • 復元したことと原因を解消したことを区別する。

公開 内容更新 情報確認

この記事の目次

AIから「このキーは削除して、再発行してください」と案内されました。公開したファイルを直し、新しいキーへ交換しました。では、これで対応は終わりでしょうか。

古いキーがもう使えないか。誰かが使った形跡はあるか。交換後のアプリは動いているか。ファイルの修正とは別に確かめることがあります。

この記事は、秘密の公開、他人のデータの表示、予想外の請求、データの消失に気づいた個人開発者や運営者に向けた初動の案内です。原因が分からなくても、次に調べる対象と、相談する相手を整理できます。業務や他人の情報が関係するときは、所属組織や提供元の対応手順を優先します。

漏えい・異常・データ消失に気づいたら利用量が急に増えた。いま分かっている事実は？

最初に、いま広がっていることを絞る

慌ててすべてを消す前に、対象のプロジェクト・公開先・気づいた時刻を確認します。ただし、情報が公開され続けているなら、詳しい調査が済むまで放置するわけではありません。担当者と連携し、対象の公開停止や権限の制限など、実行できる拡大防止を進めます。

確認した事実とまだ分からないことを分けると、相談が具体的になります。

事実：自分の公開ページに秘密の値が含まれていた。気づいた時刻は14:20。対象ページの公開を停止した。

未確認：公開の開始時刻、閲覧範囲、キーの利用状況。

「流出したかもしれない」と「不正利用が確認された」は同じではありません。逆に、ログに異常が見つからないだけで、誰も見ていないと断定もしません。記録の保持範囲や、何を記録しているかにも限界があります。

事実・拡大防止・調査を分けて進める

  1. 対象と時刻を絞る

    どのプロジェクトで、何を実際に見たか。

  2. 拡大を抑える

    対象の公開・権限を、担当と確認して制限。

  3. 記録を保全して相談

    秘密を広めず、未確認の範囲も伝える。

公開が続いているとき、調査完了まで放置する順序を示すものではありません。

キーを消したあとも、古いキーの有効性は別に見る

ファイルや投稿から値を削除するのは、これ以上見られる場所を減らす対応です。一方、キーを失効するのは、発行元でそのキーを使えなくする対応です。キーを新しく作っただけでは、古いキーが有効なままのサービスもあります。

削除・失効・確認は、それぞれ仕事がある

  1. 公開場所から除く

    これ以上、その場所から値を見られないようにする。

  2. 発行元で失効・交換

    古いキーを無効にし、利用する処理を更新。

  3. 履歴と動作を確認

    利用履歴と影響、交換後のアプリを確かめる。

露出したキーへの対応です。具体的な順序は発行元・組織の手順で速やかに進めます。

露出した秘密は、発行元の公式手順で速やかに失効・交換し、利用履歴や影響を確認します。通常の定期交換で古いキーをしばらく併用する手順と、露出が疑われるキーへの対応は分けます。GitHub公式：機密情報への対応

交換先が複数ある場合は、アプリ、本番の環境設定、バッチ、CIなど、そのキーを使う処理を整理します。秘密の値自体を一覧やチャットへ貼る必要はありません。管理者と、失効による停止の影響も共有します。

スクリーンショットやログを証拠として扱うときは、キー全文を公開の質問欄に載せません。詳しい調査に必要な元の記録は、アクセスを制限した場所で保全し、外へ共有する説明とは分けます。

見つけた症状によって、急ぐことは違う

表がはみ出す場合は、横にスクロールして読めます。

気づいたこと 最初に絞る対象 次に確認すること
秘密のキーが見えた 発行元、対象キー、公開先 失効・交換、利用履歴、利用する処理
他人の情報が表示された 自分の操作、画面、対象サービス 追加閲覧を止め、管理者へ非公開で連絡
料金が急増した サービス、プロジェクト、時間帯 利用量、実行中の処理、請求窓口
データが消えた 保存先、時点、書き込みの状況 復旧できる範囲と、復元で失う更新
不審な変更がある 対象アカウント、権限、変更履歴 セッションや権限の制限、記録の保全

料金増加は、ループや設定ミス、通常の利用増加でも起きます。原因を決めつけず、拡大を抑える方法と調査を並行して考えます。予算の通知を設定していても、必ず処理を自動停止するとは限らないため、サービスごとの上限や停止手順を確認します。

他人の情報が見えたときは、範囲を確かめようとしてさらに開いたり、再現の詳細を公開したりしません。自分が見た事実と時刻を、提供元や管理者の窓口へ伝えます。

原因を当てるより、対象を絞って支援を求める。

一人で全部を止める・消す必要はありません。プロジェクト、気づいた時刻、止めた操作、未確認の点が分かると、担当者も次の確認を選びやすくなります。

昨日に戻すと、今日の予約はどうなる？

バックアップがあっても、「戻せる」と「現在のデータを失わずに戻せる」は別です。昨日の状態へ戻すなら、その後に追加・変更された記録をどう扱うか考えます。

次は、予約IDだけを使った架空の比較です。昨日の控えには2件、現在の一覧には4件あります。本番のデータを読んだり、復元したり、削除したりする処理ではありません。

const backupIds = ["demo-1", "demo-2"];
const currentIds = ["demo-1", "demo-2", "demo-3", "demo-4"];
const absentFromBackup = currentIds.filter(id => !backupIds.includes(id));
console.log("控えにない予約:", absentFromBackup.join(", "));
console.log("戻す前に扱いを決める件数:", absentFromBackup.length);
控えにない予約: demo-3, demo-4
戻す前に扱いを決める件数: 2

この例で分かるのは、2件のIDが昨日の控えにないことだけです。同じIDでも内容が変わっている場合や、削除済みの記録まで比較しているわけではありません。実際の復旧では、更新内容と時刻、整合性、重複処理も確認します。

戻す時点と、その後の更新を分ける

  1. 昨日の控え

    demo-1 と demo-2。2件の予約がある。

    復元元の時点

  2. 現在の一覧

    上の2件に加え demo-3 と demo-4 がある。

    追加された2件の扱いを決める

架空のID比較です。内容の更新・削除・画像まで比較する演習ではありません。

DBの控えに、画像ファイルの本体や外部サービスの設定まで含まれるとは限りません。たとえばSupabaseは、DBバックアップとStorageのオブジェクト本体を区別しています。Supabase公式：バックアップの範囲

可能なら、担当者と隔離した復旧先で確かめます。本番へ何度も上書きする前に、どの時点へ、どの範囲を戻し、その間の更新をどう扱うかを決めます。

バックアップがあっても、復旧で苦労した事故

分類：事故の公表。 GitLabは2017年1月31日のDB誤削除について、同年2月10日に振り返りを公開しました。長時間の停止と、一部のデータを復旧できなかったことを説明しています。GitLabの当事者報告

この事故を、現在のGitLabやほかのサービスで同じ問題が起きる証拠にはしません。学ぶ点は、「バックアップがある」という設定だけでなく、必要なときにどの範囲を戻せるか、復旧の手順が使えるかまで確かめることです。

動くようになったことと、再開してよいことは別

画面が戻っても、古いキーや侵入口が残っていれば、同じ問題が続く可能性があります。復旧後は、利用者の権限、接続するキー、データの整合性、外部への送信や決済なども確かめます。

復旧した画面だけで、対応完了にしない

  1. 原因・権限・キー

    同じ問題が続く経路を残していないか。

  2. 動作とデータ

    戻した範囲、失った更新、外部への処理を確認。

  3. 監視と連絡

    再開後に見る指標、担当、利用者への案内を決める。

復元と、原因への対処、再開の判断を別々に確認します。

障害だったのか、漏えいが疑われるのかによって、相談や通知の担当も変わります。第三者の個人情報や業務データが関係する場合は、自己判断で「問題ありません」と公表せず、組織の責任者や専門家と対応を決めます。ここでは個別の法的な報告要否を判断しません。

一人で作っていても、3つの役割を分ける

気づいた人：事実を短く残す

時刻、対象、見た現象、すでに止めた操作を整理します。元のログを消したり、秘密を別の会話へ貼り直したりせず、確認済みと推測を分けます。相手のデータが見えた場合は追加閲覧を止めます。

サービスを管理する人：拡大防止と連絡を進める

公開停止、対象の権限・キーの制限、提供元の窓口を確認します。自分で制御できない処理は、プロジェクト名と現象を伝えて支援を求めます。利用者への案内が必要かも、責任を持つ担当と決めます。

技術担当・提供元：調査と再開条件を確認する

記録、アクセス、キーの利用履歴、原因、復旧の範囲を調べます。原因を直す作業とデータを戻す作業を分け、再開後に見る指標や異常の通知先まで決めます。自分が兼任する場合も、分からない操作は支援を依頼します。

落ち着いたら、次に迷わないための短い手順へ。

今回分かった保存先、相談先、止め方、復旧で足りなかったものを残します。「注意する」だけで終えず、次の公開前に確かめられる手順へ直します。

対応を終える前に確かめること

  • 事実： 時刻・対象・現象と未確認事項を分け、相談相手へ伝えた。
  • 拡大防止： 対象の公開や権限を見直し、露出したキーは発行元で失効・交換したことを確認した。
  • 調査： 利用履歴と保存されている記録の範囲を確認し、記録のない部分を「問題なし」にしていない。
  • 復旧： 復元する時点・対象・失う更新・DB外のファイルを確認した。
  • 再開： 原因と権限・キーを見直し、動作・データ・監視と連絡先を確かめた。

次は、公開前の手順へ戻す

キーの扱いはAPIキーの教材、履歴の保全は会話ログの教材、再公開の準備は公開前の確認へ戻ります。未確認が残る場合は、分かったことと次に確認する担当を明確にします。

一次資料

情報確認日：2026年10月24日。実際の初動と復旧は、利用するサービスの公式手順・組織の対応手順で確認してください。

書いた人

マーケティングの現場から、AIをつくり、仕事で使う側へ。実際に試したことや、つまずいたことを、図解と具体例で伝えています。

プロフィール・発信先 →著作権・利用条件 →

この記事のURL：https://nekoai-lab.github.io/ai-security-playbook/learn/incident-response/

このシリーズはここまで

シリーズ · 全14記事のうち14記事目

ほかの教材を探す別の教材を探すテーマや検索から、次に確かめたいことを選べます。
読む順番・ルートを見るAIで作って公開する基本
  1. AIに渡す情報を、送る前に分ける
  2. 「学習しない」AIなら、仕事の個人情報を使える？
  3. AIで作ったアプリの、動く場所を知る
  4. AIに「APIキーを設定して」と言われた。どこに入れるのが正解？
  5. APIキーを替えたのに、古いキーが使われている？
  6. ログインと、データを使う権限を分ける
  7. 公開したのは、本当に見せたいファイルだけ？
  8. コードには書いていない。名前やメールは、どこから公開される？
  9. 緑のチェックが付いた。その変更を公開していい？
  10. AIレビューが合格した。その結果を、どこまで信じていい？
  11. AIにデプロイを頼んだ。その認証情報は、どこまでできる？
  12. AIで作ったサービスを、公開する前に確かめる
  13. 外部サービスが止まったら、自分のアプリはどうなる？
  14. 漏えい・異常・消失に気づいたとき、最初にすること

関連する教材

APIキーを替えたのに、古いキーが使われている？ →約20分 · 解説
AIに「APIキーを設定して」と言われた。どこに入れるのが正解？ →約18分 · 手順

異常に気づいたらの教材へ戻る →

この教材のソース・修正提案 ↗