AIに顧客情報を入力するときの注意点

顧客情報を生成AIへ入力するときは、「学習に使われるか」だけで判断せず、入力する情報、利用する製品・契約、保存期間、共有範囲、出力の扱いを一緒に確認します。まず作業に不要な顧客情報を除き、残す必要がある場合は社内で承認されたサービスとアカウントを使います。個人向けサービスと法人契約では、学習・保持・管理者制御が異なることがあるため、製品名だけで安全性を決めないでください。

最初に決めるのは「何を入力してよいか」

表は横にスクロールできます

情報の例	まず行うこと	入力判断
公開済みの商品説明	個人名や未公開条件が混ざっていないか確認	公開情報の範囲なら社内ルールに従って利用
顧客名、メール、問い合わせ文	氏名・連絡先を削り、目的に必要な内容だけ残す	識別情報が必要な理由が説明できなければ入力しない
契約、価格交渉、未公開提案	承認済み環境、契約、アクセス権を確認	承認がなければ入力を保留
健康、金融、本人確認などの情報	取扱目的、法令・業法、委託先、保存条件を担当者へ確認	一般アカウントへ直接入力しない

この表は法的な個人情報区分を確定するものではありません。顧客に関する情報は、氏名がなくても、案件名・役職・時期・固有の事情の組み合わせで本人や企業を特定できる場合があります。「名前を消した」だけで匿名化できたと扱わず、入力文全体で再識別できないか確認します。

送信前の判断フロー

1. 作業を特定する。 要約、分類、返信案など、AIに任せる部分を一文にします。依頼目的が曖昧なら入力を始めません。

2. 最小化する。 氏名、連絡先、顧客番号、社名、金額、日付、自由記述のうち、作業に必要なものだけ残します。置換する場合は、元データとの対応表をAIサービスへ送らず社内で保管します。

3. 環境を照合する。 承認済みの製品・アカウントか、対象planか、学習設定・保持・管理者制御がどうなっているかを確認します。個人アカウントへ切り替わっていないかも見ます。

4. 共有範囲を確かめる。 DriveやCRM等のconnectorを使う場合、promptに貼った文だけでなく、接続先の権限・検索範囲・共有設定も確認します。

5. 出力を管理する。 生成結果に顧客情報が残る前提で、保存場所、閲覧者、転送先、削除方法を決めます。

6. 記録してから実行する。 利用目的、対象環境、入力を最小化した方法、確認者を記録します。未確認項目があれば、顧客データを使わないダミーデータで代替します。

「学習しない」と「保存しない」は別の条件

学習利用の設定は、サービスが入力をモデル改善に使うかを説明します。保持期間は、ログや会話履歴がサービス上に残る期間です。管理者が会話を閲覧できるか、削除後も法令・不正対策等の目的で保持されるか、connector先へデータが渡るかも別に確認します。学習に使われなくても、運用・安全対策のため一定期間ログが保存される場合があります。反対に、会話を削除できても、削除前に出力を社内の共有フォルダへコピーしていれば、そのコピーは残ります。

表は横にスクロールできます

確認項目	設定・契約で見る場所	未確認の場合
モデル学習	製品・plan別のdata use条件、個人向け設定	顧客データを送らず、承認窓口へ照会
保持・削除	abuse monitoring、履歴、削除期限、例外	機密度を下げるか、利用を保留
アクセス	workspace管理者、共有link、role、connector権限	対象accountと接続を確認してから使う
処理委託	DPA、再委託、保管地域、事故通知	法務・security担当が確認するまで保留
出力・保存先	共有先、CRM登録、mail転送、export	閲覧者と削除責任者を決める

製品名ではなく、使う面と契約を照合する

OpenAIは、対象となるBusiness、Enterprise、Edu、API等の組織向けサービスでは、既定で顧客データをモデル学習に使わないと案内しています。一方、個人向けChatGPTにはモデル改善の設定があり、データ管理設定を確認する必要があります。APIの保持・state条件はendpointや機能によって異なり、標準の不正利用監視ログが適用される場合もあります。「OpenAIなら全部同じ」とまとめず、ChatGPT、組織向けworkspace、APIのどれかを特定してください。

AnthropicもClaudeのconsumer製品と商用サービスを分けて確認します。商用APIのデータ保持は契約や利用条件により異なり、一定の標準保持期間が示される一方、Zero Data Retentionは対象となる組織のAPI利用など条件があり、Claudeの全製品へ一律に適用されません。Claude for Work等のworkspaceに保存される会話と、consumerアカウントの設定も同一視しないでください。

Google Workspaceの生成AIに関する保護説明は、対象となるWorkspace契約・サービスの範囲を確認して適用します。個人向けGeminiや別のGoogleサービスへ、Workspaceの管理者向け保護をそのまま当てはめないでください。管理者が有効にした機能、接続するWorkspaceデータ、共有範囲も確認します。

したがって、利用前に「サービス」「アカウント種別」「plan」「機能/API」「管理者設定」「契約書」を一組として記録します。公式ページに条件が書かれていない場合や、自社の契約がどの条件に該当するか分からない場合は、一般向けの説明から推定せず、管理者・提供事業者へ確認します。

個人情報と顧客情報は、利用目的も確認する

個人情報保護委員会は、生成AIサービスへ個人情報を含むプロンプトを入力する場合、サービス提供者が入力情報を機械学習等に利用しないことなどを十分確認するよう注意喚起しています。実際の取扱いでは、入力する目的、社内外への提供関係、委託先との契約、本人への説明なども関係します。個人情報に当たるか、第三者提供・委託に当たるかはケースと契約によって異なるため、記事だけで適法性を判断しないでください。個人情報以外でも、秘密保持契約、営業秘密、顧客との契約が入力を制限することがあります。

1件の作業で使う入力票

顧客メールを要約する例では、AIへ原文全体を貼る前に、次の入力票を埋めます。

• 目的： 問い合わせの論点と回答期限を抽出する。

• 必要な情報： 製品名、エラー内容、希望する解決だけを残す。

• 除く情報： 氏名、メール、電話、住所、顧客番号、契約金額。

• 環境： 会社が承認したworkspaceのアカウントを使用。個人アカウントは使わない。

• 接続先： 顧客メールやCRMを参照するconnectorは今回使わない。

• 保存： 出力をチケットへ貼る前に担当者が事実を確認し、不要な共有コピーを作らない。

この例で元メールを送らなくても要約が作れるなら、最小化した文章を使います。固有の事情が残って再識別される可能性がある場合や、回答に本人情報が必須の場合は、社内責任者が必要性と許可を確認するまで保留します。ダミーデータで手順を検証できるなら、まず実データを使わずに処理を設計します。

社内ルールに最低限書く項目

利用可能なサービスとアカウント、禁止データ、許可が必要なデータ、匿名化の手順、connectorの承認範囲、出力の保管場所、削除責任者、誤送信時の連絡先を短く定めます。ルールは「AIに個人情報を入力しない」とだけ書くと、担当者が顧客名を除けばよいのか、商談内容も対象なのか判断できません。実際の業務例と保留先を一つずつ示し、契約・サービス設定が変わったときの再確認担当も決めます。

AIものさしの判断

まず入力を減らし、次に使う製品・アカウント・planの条件を確かめ、最後にconnector・出力・共有・保存を確認します。「学習に使わない」という一項目だけでは顧客情報の取扱い全体を判断できません。環境や契約が確認できない場合は実データを送らず、匿名化・ダミーデータで代替します。要配慮情報、金融・医療情報、未公開契約、顧客納品を扱う場合は、社内の情報管理・法務責任者へ確認してから進めるのが現実的です。

入力可否を記録する短い判定メモ

利用前に、以下を1件ごとに記録すると、担当者が変わっても同じ確認を再現できます。

• 業務と目的： 何を作るために、どの情報を使うか。

• 分類と最小化： 個人・顧客・契約情報の有無、削除・置換した項目。

• 利用環境： 製品名、consumer / business / APIの別、plan、利用機能。

• 条件の根拠： 公式規約・管理者設定・契約の確認日とURL。

• 共有と保持： connector、workspace権限、出力先、削除方法。

• 承認： 確認者、追加条件、次回見直し日。

未確認を「問題なし」と記録せず、「未確認・実データ送信なし」とします。規約や設定に更新があったときは、以前の確認を流用せず影響する項目だけ再確認します。

入力後に誤送信へ気づいた場合は、該当チャットや共有先を消すだけで終わらせません。社内の事故対応窓口へすぐ連絡し、送信した情報、サービス・account、時刻、出力・共有の状態を記録します。削除可否やサービスへの連絡は組織の手順に従い、影響範囲を責任者が確認します。