「顧客表をAIに貼りました。履歴は消しました」と報告されたら。会社の初動

拡大を抑え、対象・時刻・共有先・保存条件を書き留め、必要な記録を保全して担当者へつなぎます。画面で削除できたことだけを、すべての保存先から消えた証拠にはしません。

社内の連絡先を持つ一般企業向けの初動整理です。漏えいか未確定でも使えます。報告が必要かは、法務などの担当者が原典で判断します。

いま起きた場合：止める、連絡する、最小限を残す

1. 追加の入力・添付・連携、公開や後続配信を止めます。操作権限がなければ、対象を伝えて管理者へ停止を依頼します。
2. 上長と情報管理担当へ直ちに連絡します。不在なら社内で決めた代行先へ。漏えいかどうかの確定を待ちません。
3. サービス・時刻・情報の種類・範囲・操作結果を残します。機密の全文を連絡欄へ貼り直したり、履歴を一括消去したりしません。分からない項目は不明のまま伝えます。

社内連絡の短い見本

顧客表12人分を誤って送信したときの連絡文です（想定例）。実際には自社の日時と保管先へ置き換えます。

本日9月15日9:10（日本時間）、AIサービスへ氏名・メールアドレス・商談メモを含む顧客表12人分を送信し、9:12に誤入力に気づきました。9:14に追加入力を止めています。サービス名・機能・アカウントは社内の初動記録に記載します。元資料と操作記録の保管先は、閲覧権限を決めてからお伝えします。提供元での閲覧・保持・連携先への送信はまだ分かっていません。次の対応をお願いします。

全文を共有する必要がある場合も、調査担当者だけが見られる保管先を使います。記録がそろう前でも、停止と第一報を先に進めます。

最初に拡大を抑える

誤入力なら、同じ資料を使う追加の質問、添付、外部連携を止めます。誤公開なら、該当ページや共有リンクを非公開にし、予約投稿・自動返信も止めます。操作権限がなければ管理者へ対象を伝え、停止を依頼します。公開中なのに、記録票を完成させるまで停止を待つ必要はありません。公開する前に、AIの回答の出典や数字を確かめる手順は、AIの回答の出典・数字・引用を確かめる手順にまとめています。

「入力欄に貼っただけ」と「送信が完了した」は分けて記録します。ただし、送信操作をしていないという記憶だけで、外部への送信がなかったと決めず、利用機能と履歴を調べます。誤送信では、一斉メールなどの残りの配信を止め、送付済みの相手への対応を切り分けます。

発生時刻と操作が曖昧なままでは、調べるログの範囲や、どの相手が情報に触れた可能性があるかを絞れません。停止の時刻・対象・操作した人を残し、上長と情報管理担当へ、分かっている事実だけを直ちに連絡します。担当不在時は代行先へつなぎます。

IPAは、被害の拡大防止と、不用意な操作で記録を消さないことを示しています。端末の初期化や履歴の一括消去を、通常の初手にはしません（出典：IPAガイドライン p.62（PDF））。

表1　誤入力と誤公開を並べた初動表（本記事の提案）

確認すること	誤入力：AIへ情報を渡した	誤公開：出力を外部へ出した
発生時刻と操作	入力・添付・連携の時刻、送信の成否を分けて記録	生成・承認・公開・停止の時刻を分けて記録
入力・公開した範囲	情報項目、元資料、対象人数、送信先、契約・設定	該当する文章・画像・URL、掲載先、配信先、閲覧状況
影響する相手	情報の本人、委託元・顧客、提供元、連携先	読者、回答を受けた顧客、権利者、業務判断をした人
停止・訂正・連絡	追加送信・自動連携を止め、社内担当へ連絡	公開・予約配信を止め、訂正と関係者への連絡を検討
保存と再発防止	必要な証跡を限定保管。保持・削除範囲を照会	公開版と修正版を区別。根拠資料と承認手順を見直す
判断が変わる条件	未送信か、送信済みか、相手側の取扱いが不明か	未公開か、限定共有か、誰でも閲覧できたか

2経路が重なる場合もあります。AIへ顧客情報を渡した後、その出力を誤った相手へ送ったなら、入力と外部への送付の両方を調べます。誤送信は、外部へ出した経路として表の右列を使い、宛先・添付・転送も調べます。

何が起きたかを確認する

記録するのは、サービス名と機能、プラン、個人管理か会社管理か、発生・発覚日時とタイムゾーン、情報の項目、操作履歴です。契約書や設定の画面を見た日も残します。事故当時と現在で設定が異なる可能性は、別の調査項目にします。

範囲は「氏名・メールアドレス・商談メモを含む12人分の表を添付」のように具体化します。人数・ファイル数・送付先数・閲覧数は別の単位です。全件か一部か、ログで数えた数か概数かも分けます。件数だけで報告要否を決めず、「報告・通知の要否を判断する」の条件に照らします。

個人データは、個人情報データベース等を構成する個人情報です。管理表から抜き出した情報も、元の管理方法を担当者へ伝えて該当性を判断します（出典：個人情報保護委員会「通則編」2-6）。

利用目的と提供元での利用も調べます。個人情報保護委員会の注意喚起は、入力が利用目的に必要な範囲かの確認を求めています。また、本人同意なしに個人データを入力し、応答の出力以外の目的で扱われる場合には法違反の可能性があるとして、機械学習に利用しないこと等の確認を求めています（出典：「生成AIサービスの利用に関する注意喚起等」別添1（1）（PDF））。

社内連絡では機密の全文を貼り直さず、情報の種類、対象範囲、証拠の保管先を伝えます。原本が必要な担当者だけが、アクセス制限した場所で見られるようにします。再現のために同じ情報を別のAIへ送ることも避けます。

削除と証拠保全を両立する

外部から見えなくする操作と、社内で事実を残す作業は別です。停止を優先しつつ、URLやメッセージID、操作時刻、対象ファイルの版、公開前後の内容など、調査に必要な範囲を保全します。全員に画面写真を配ったり、私物端末へ複製したりする必要はありません。

公開版の記録を保存する場合は、取得者・取得日時・保管先・閲覧者を残します。訂正前の記録と訂正後の版を混ぜず、元の記録は上書きしません。保管期間と見直し日を責任者が決め、調査や紛争対応上の保存要請がある場合は、独断で消さずに法務等に相談します。

提供元には、対象の会話・添付・連携先について、保存場所、保持期間、応答以外や学習への利用、削除の対象、バックアップ等の例外、処理状況を照会します。受付番号と回答日を記録し、何が分かり、何が回答されていないかを区別します。

「削除を依頼した」「画面から消えた」「提供元から対象を明示した回答が届いた」は、それぞれ異なる状態です。保持条件が不明なら不明と残します。「学習に使わない」という回答だけで、保存や外部連携の調査を終えない運用にします。

記録を残す原則と、外部サービスの役割・連絡先の整理は、IPAガイドライン p.39・63（PDF）を参照しています。

報告・通知の要否を判断する

社内報告、提供元への照会、取引先への連絡、当局への報告、本人への通知は、目的も判断根拠も違います。情報管理担当が窓口を整理し、法務・個人情報保護担当・業務責任者に必要な判断を割り振ります。

個人データの漏えい等やそのおそれがあるなら、現行の通則編で報告対象の類型・例外、報告主体、速報と確報、本人通知の条件を読みます。当局報告と本人通知は別欄にし、それぞれ要否・根拠・判断者・判断日時を残します。契約上の事故連絡や、著作権等の権利に関する対応は、該当する契約・素材・利用規約を法務等が別に判断します。

担当者が、発生を知った時点などの起算点、適用条項、期限・通知時期、提出先を現行原典から転記します。内部の「次回確認時刻」を法定期限の代わりにはしません。提供元の回答を待つ間も判断を進め、報告が必要な場合に全容判明まで先送りしないようにします（出典：個人情報保護委員会「通則編」3-5-2～3-5-4）。報告窓口は「漏えい等の対応とお役立ち資料」から確認します。

一方、公開情報だけで作った案内の誤りなら、訂正と影響を受けた顧客への説明が中心になる場合があります。個人データ漏えい等報告は、個人データの取扱いと漏えい等の条件に照らして判断します。ただし、個人情報の混入、権利侵害、健康・安全への影響等が見つかれば対応を再評価します。

もっともらしい誤りや、人がAIを過信するリスクは、NIST AI 600-1の2.2・2.7にも挙げられています。米国の任意枠組みであり、日本での法的な報告義務の根拠ではありません（出典：NIST AI 600-1、2.2・2.7（PDF））。

記入例：同じ「外へ出た」でも対応を分ける

9月15日に起きた三つの場面を比べます。時刻は日本時間です。

顧客管理表をAIへ送信した後の記入例

記録欄	記入済み見本
発生・発覚	09:10送信、09:12発覚。氏名・メール・商談メモ12人分。
操作・判断者	09:14追加入力停止／入力者A。09:16社内連絡／上長A。
影響する相手	対象の本人12人と顧客。提供元での閲覧・保持は不明。
選ぶ対応と次の確認	情報管理責任者Aが照会・証跡保全を指示。法務Aが報告・通知を確認中。内部再確認10:00。削除だけで終了しない。

自社の発送案内に誤りがあった場合（想定例）

記録欄	記入済み見本
発生・発覚	10:00公開、10:06発覚。自社サイト1ページ。閲覧人数は不明。
操作・判断者	10:08非公開／サイト管理者B。10:30訂正版公開／業務責任者B承認。
影響する相手	案内を見て注文を判断した顧客。承認済み案内で正しい条件を照合。
選ぶ対応と次の確認	入力・出力に個人データなしと確認した仮定。漏えい等報告はこの理由では行わず、訂正・顧客説明を進める。内部再確認11:00。

原価表を誤った取引先へ送った場合（想定例）

記録欄	記入済み見本
発生・発覚	11:00送信、11:03発覚。原価表1ファイル、誤送付先1社。
操作・判断者	11:05後続送信停止／送信担当C。11:10受信先へ利用・転送停止と削除を依頼／営業責任者C。
影響する相手	本来の取引先と誤送付先。添付の開封・転送・削除結果は不明。
選ぶ対応と次の確認	法務Cが契約の連絡条件と個人データの有無を確認。送信取消の操作だけで回収済みとしない。内部再確認12:00。

Bの例でも、公開文に顧客名が混じっていたと判明すれば、訂正だけでなく個人データの経路を調べます。Cで転送の有無が不明なら、受信先の回答と送信記録を追加で調べます。必要な情報と取得先を残し、未確認事項を次の担当者へ引き継ぎます。

再開条件を決める

再開は、どの条件を直し、誰が確かめたかで決めます。誤入力なら、許可された環境、入力する情報の範囲、連携権限を見直します。誤公開・誤送信なら、正しい根拠資料、承認者、公開先・宛先・添付を見直す手順を組み込みます。

変更後は、実際の機密を再投入せず、ダミーデータで停止・承認・送信の経路を試します。再開する業務と継続停止する業務、未解決事項、承認者、再点検日を残します。訂正版を手動公開しても、自動配信を同時に再開する必要はありません。

NISTは出典の検証と、狭い評価から性能を一般化しないことを勧めています。一度の試験で再発しないと保証せず、変更した範囲を記録して監視を続けます（出典：NIST AI 600-1、MEASURE 2.5（MS-2.5-001・003）（PDF））。

平時に、初動表と連絡先を用意する

初動を終える時点では、停止・訂正の結果、残る問い合わせ先、記録の保管責任者を引き継ぎます。判断表・初動記録票をダウンロード（Excel）し、空欄票と3ケースの見本を自社の連絡先・権限・保存条件に合わせて整えてください。

入力禁止情報や承認環境など、平時のルールは生成AIの情報漏えいを防ぐ7つの社内ルールにまとめています。

声や動画を使った不審な送金依頼では、登録済みの連絡先で確かめる手順が役立ちます（AIの偽音声・偽動画に備える本人確認と送金手順）。

初動後に、自社の業務とAIへ渡す情報・利用条件を整理する必要がある場合は、AI業務改善診断で見直せます。相談フォームには事故の原文や機密・認証情報を貼り付けず、共有方法を先に相談してください。

AI業務改善診断を見る

参考出典

• IPA「中小企業の情報セキュリティ対策ガイドライン」第4.0版（PDF）
• 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」（PDF）
• NIST「Generative Artificial Intelligence Profile」AI 600-1（PDF）
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」

資料確認日：2026年9月15日。