AIサポートにおける顧客データプライバシー：PII、マスキング、保持

著者: Linh Ngo · 更新日: 2026年10月11日

AIサポートにおける顧客データプライバシーとは、AIシステムがどの個人データを目にするか、誰がそれをどれだけの期間保持するか、どこへ渡るか、そして誰が読めるかを決める対策の総称です。 実際には、次の6つを意味します。モデルやログに届く前に個人データをマスキングすること、保持期間を設定して実施すること、決済カード情報をチャットに一切入れないこと、ベンダーのデータ条件を読むこと、データの保管場所を選ぶこと、トランスクリプトを開ける人を制限することです。

サポートは、プライバシーの問題が気づかれないうちに起きやすい場所です。「どのようなご用件でしょうか」と尋ねられた顧客は、チャットボックスにアカウント番号や病状を貼り付けます。AIの層があると、1つひとつのメッセージが、プロンプト、プロバイダーのログ、QAデータセット、要約フィールドのいずれにも残る可能性があります。このガイドは、法律の学位がなくても「データはどこへ行くのか」に答えなければならないサポートリーダーの方を対象としています。法的助言ではありませんので、お客様の地域で何が適用されるかは、プライバシー担当の弁護士に確認してください。このガイドは、データのクリーニングを扱うAIのためのサポートデータの準備の続編にあたり、ここでは、そのデータの保護に焦点を当てます。

重要なポイント

• GDPR第5条1項(c)は、個人データが処理の目的に照らして「適切で、関連性があり、必要なものに限定される」ことを求めています。また、第5条1項(e)は、個人を特定できる形での保管は「必要な期間を超えてはならない」と定めています（GDPR、EUR-Lex）。
• PCI DSSでは、取引が承認された後はカード確認コードを保管することが認められていません。暗号化されていても、顧客が同意していても同じです（PCI SSC FAQ 1280）。
• GDPR第28条3項では、処理者は管理者の文書化された指示に従ってのみ行動でき、サービスの終了時には、管理者の選択に応じて個人データを削除または返還しなければなりません（GDPR、EUR-Lex）。
• OpenAIは、APIに送信されたデータは、顧客がオプトインしない限りモデルの学習には使われず、不正利用監視のログは既定で最長30日間保持されると説明しています（OpenAI）。
• Microsoftのオープンソースライブラリ「Presidio」は、自動検出ではすべての機密情報を見つけられる保証はないと注意を促しています（Presidio）。
• FTCは、以前の約束のもとで収集したデータをAIの学習に使えるよう、利用規約をひそかに書き換えることは、不公正または欺瞞的となり得ると述べています（FTC）。

AIサポートスタックで顧客データが置かれる場所

対策を選ぶ前に、データが実際に置かれている場所を洗い出してください。典型的なAIサポートの構成には、思っている以上に多くのコピーがあります。

プライバシーに関する請求や監査が届いたとき、自社の構成について、この表のすべての行を挙げられる状態にしておく必要があります。

チャネル別の実例

リスクの現れ方はチャネルごとに異なります。そのため、サポートチャネル全体でのAIには、専用のプライバシー確認が必要です。

チャット。 決済の失敗について尋ねる人は、カード番号をそのまま貼り付けることがよくあります。メッセージを保存したりモデルに送ったりする前に、カード番号に見える数字の並びをマスクしてください。

メール。 スレッドには、署名、転送された履歴、スキャンした身分証明書などの添付ファイルが含まれます。業務に必要でない限り、引用された履歴と添付ファイルのテキストは除去してください。

音声。 音声データは、最も消去しにくいデータです。PCI SSCはこの点に直接言及しています。承認後にデジタル音声録音に記録されたカード確認コードは保管ルールに違反し、データが録音されないようあらゆる努力をすべきで、録音を防げない場合は承認時点でただちに安全に削除すべきだとしています（PCI SSC FAQ 1210）。

社内向けのエージェントアシスト。 自社の担当者に返信を提案するだけのツールでも、会話の全体を見ています。エージェントアシストにも、顧客向けのボットと同じマスキングと保持のルールが必要です。

6つの対策

以下の各節では、実施する順序に沿って、それぞれの対策を取り上げます。

マスキング：トランスクリプト、プロンプト、ログ内のPII

GDPR第5条1項(c)は、マスキングの背景にある原則です。個人データは、処理の目的に照らして「適切で、関連性があり、必要なものに限定される」べきとされています（GDPR、EUR-Lex）。AIアシスタントにとっては、これは設計上のルールに置き換わります。モデルには、その1件の会話に必要な最小限だけを渡します。パスワードのリセットの依頼に必要なのは、アカウントの状態であって、請求履歴ではありません。GDPRの考え方について詳しくは、AIによるサービスのパーソナライゼーションをご覧ください。

マスキングは3つの時点で行うことができ、通常は3つすべてが必要です。

1. モデルの前。 受信したメッセージ内の個人データを検出し、[EMAIL]や[CARD_NUMBER]のようなプレースホルダーに置き換えます。そうすれば、モデルは実際のアドレスを一切保持しないまま、「そのメールアドレスに紐づくアカウントを見つけました」と回答できます。最終的な返信に実際の値が必要な場合は、モデルの応答後にシステム側で再挿入できます。
2. 保存の前。 トランスクリプトをヘルプデスク、ログのパイプライン、分析テーブルに書き込む前にも、同じマスキングを適用します。そうすれば、生の値が永続的な場所に残ることはありません。
3. 再利用の前。 QA、コーチング、チューニングのために会話をエクスポートするときは、もう一度マスキングします。ICOのAIツールキットは、可能な場合はモデルの学習に合成情報または匿名化された情報を使うことを推奨しています（ICO）。

ツールについての注意点があります。Microsoftのオープンソースの検出ツールキットであるPresidioは、検出が自動であるため、すべての機密情報を見つけられる保証はないと述べています（Presidio）。パターンマッチングは、カード番号やメールアドレスには強い一方、文中の氏名や病状の記述には弱いものです。マスキングしたトランスクリプトを毎週サンプリングし、漏れを探してください。

デバッグログ、エラートラッカー、チャットウィジェットのセッション録画にも生のテキストが残るため、これらは別途確認してください。

保持と削除

GDPR第5条1項(e)は、個人データは、処理の目的に必要な期間を超えて、個人を特定できる形で保管してはならないと定めています（GDPR、EUR-Lex）。前文では、管理者は消去または定期的な見直しの期限を定めるべきだと補足されています。また顧客は、第17条1項の文言にあるとおり、同条が列挙する状況において「自己に関する個人データの消去を管理者から得る権利」を持っています。

始めるのに、完璧な法的分析は必要ありません。必要なのは、担当者が決まっているスケジュールです。

• データの種類ごとに目的を決める。 トランスクリプト、録音、AIの要約、QAのサンプル、プロバイダーのログには、それぞれ存在する理由があります。それを保持期間の横に書いておきます。
• 理由に見合った期間を設定する。 保証や請求の紛争に備えるなら、チケットを長期間保管する理由になり得ます。営業時間について尋ねたチャットは、そうではありません。記録保存に関する法律は国によって異なるため、上限は通常、法務部門と財務部門が決めます。
• AIの副産物も削除する。 会話から作られた要約、感情スコア、抽出されたエンティティ、埋め込みは、同じ人物に関する派生データです。チケットだけを消してAI要約を残していたのでは、ほとんど何も削除したことになりません。
• 自動化する。 誰かが覚えていることに頼るスケジュールは、失敗します。ヘルプデスクの保持設定と、クラウドアカウントのストレージライフサイクルルールを使います。
• 例外は文書に残す。 ICOのAIツールキットは、文書化された保持スケジュールと、それに沿ったAIシステム内の個人情報の削除、そしてそれを超える保持についてはDPIAでの正当化を求めています（ICO）。

バックアップは、よくある落とし穴です。削除したデータがそこにどれだけ残るかをポリシーに明記し、ベンダーにも同じことを尋ねてください。

決済カード情報：チャットとAIのログに入れない

カード情報は、業界に厳格なルールがある唯一の領域であり、サポートチームは誰よりも不注意でそれを破っています。PCI DSSで重要なのは、カード番号（PAN）と、カードに印字されたセキュリティコードのような機密認証データとの区別です。

セキュリティコードについて、PCI SSCのFAQは明快です。取引が承認された後にカード確認コードを保持することは認められず、承認前に収集することは許されており、顧客の承認は保管を許可するものにはなりません（PCI SSC FAQ 1280）。別のFAQでは、機密認証データは暗号化されていても承認後に保管してはならず、これはPANが存在しない場合にも当てはまると補足しています（PCI SSC FAQ 1533）。

顧客がカード番号とコードをチャットに入力し、プラットフォームがトランスクリプトを保存すると、そのコードは決済後もデータベースに残ります。さらに、プロンプト、要約、QAのエクスポート、ベンダーのログにも流れ込む可能性があります。PCI SSCの音声録音に関するガイダンスは、これに最も近い期待される対応を示しています。可能であれば録音を防ぎ、防げない場合は承認時点でただちに削除することです（PCI SSC FAQ 1210）。

現実的な方法は、スコープの縮小です。これは、カード情報がサポートシステムに一切触れないように設計することを意味します。

1. チャット、メール、AIに対して、カード情報を求めない。 顧客を、決済プロバイダーが運営するホスト型の決済ページや安全なリンクに案内します。
2. カード番号のように見えるものは、受信時にマスクする。 保存の前、モデルの前に行い、そうしたことを顧客に伝えます。
3. AIが決済を参照する必要がある場合はトークンを使う。 PCI SSCのAI原則は、AIシステムの範囲と影響を限定するために、決済トークンや使い捨てのPANを検討することを勧めています。また、主要な保護策は、そもそもAIシステムに渡す機密データを限定することだとしています（PCI SSCのブログ）。
4. 認証情報も入れない。 同じ原則では、APIトークン、ユーザーの認証情報、暗号鍵はAIのデータセットに入れるべきではないとしています。
5. スコープをアクワイアラーまたは評価機関に確認する。 チャット、音声、AIの構成がどのように当てはまるか、またどのシステムがカード情報を取り扱うものとみなされるかを尋ねてください。

ベンダーの条件：学習データ、DPA、サブプロセッサー

AIベンダーは通常、自社に代わって動く処理者です。GDPR第28条3項は、処理者による処理は、処理者が「管理者の文書化された指示に基づいてのみ個人データを処理する」ことを定め、サービスの終了時には管理者の選択に応じて「すべての個人データを削除するか管理者に返還する」ことを定めた契約によって規律されるとしています（GDPR、EUR-Lex）。この契約がデータ処理契約、つまりDPAです。顧客データが流れ始める前に署名を済ませてください。

チームがつまずきやすい点が2つあります。

条件は製品ごとに異なります。 購入する製品ごとに、ベンダーのドキュメントを読んでください。たとえばOpenAIは、APIのデータはオプトインしない限りモデルの学習に使われないこと、不正利用監視のログは既定で最長30日間保持されること、そしてゼロデータ保持（Zero Data Retention）ではコンテンツがそれらのログから除外されるものの、事前の承認が必要であることを説明しています（OpenAI）。ヘルプデスクに組み込まれたAI、チャットボットのベンダー、音声プラットフォームには、それぞれ独自の条件があります。

条件は変わります。 FTCは、AIの学習へのデータ利用のように、より緩やかなデータ慣行を採用し、利用規約をひそかにさかのぼって変更することでしか顧客に伝えないのは、不公正または欺瞞的となり得ると警告しています。また、ある一連のプライバシーの約束のもとでデータを収集した事業者は、一方的にそれを反故にできないとも述べています（FTC）。これは顧客を守るものですが、ベンダーの条件を常に更新される文書として扱うべきだということも示しています。変更通知の連絡先を誰かのカレンダーに入れ、更新のタイミングで条件を見直してください。

ベンダーへの質問チェックリスト

すべてのAIベンダーとサポートツールのベンダーに尋ね、回答は営業の電話ではなく、契約書またはDPAに記載してもらってください。

• 自社のデータは、御社または第三者のモデルの学習や改善に使われますか。それは既定でオフですか、それともオプトインですか。
• プロンプト、出力、ログをどのくらいの期間保持しますか。短縮したり、保持ゼロに設定したりできますか。
• 契約終了時に自社のデータはどうなりますか。削除はどのように確認されますか。
• どのサブプロセッサーが自社のデータに触れますか。どの国にありますか。変更はどのように通知されますか。
• 保管と処理のリージョンを選べますか。サポート担当者は他のリージョンからアクセスしますか。
• 自社のデータについて、御社側にどのようなログとアクセス制御がありますか。
• 情報漏えいが起きた場合、どのように、どれくらいの時間内に通知されますか。
• 製品はカード番号をマスクまたは除外しますか。音声録音は別に扱われますか。

データの所在地と国境を越える移転

GDPR第5章は、第44条から始まり、第三国への個人データの移転を規律しています（GDPR、EUR-Lex）。サポートリーダーにとって実務上の問いは単純です。顧客のデータはどの国に保管され、どの国から読めるのか、ということです。

多くのAIプロバイダーが、リージョンの設定を提供しています。OpenAIは、データレジデンシーをプロジェクト単位のオプションとして文書化しており、対応するエンドポイントについて、顧客のコンテンツを保存時に選択したリージョンに置くとしています。システムデータは対象外です（OpenAI）。「保存時」は「リージョンから決して出ない」よりも範囲が狭いため、バックアップ、ログ、人のサポート担当者によるアクセスについて、各ベンダーに尋ねてください。

アクセス制御

サポートで最もよくあるプライバシーインシデントは、攻撃ではありません。必要以上のアクセス権を持つ人が、読む理由のないものを読んでしまうことです。GDPR第32条1項(a)は、検討すべき技術的措置として、仮名化と暗号化を挙げています（GDPR、EUR-Lex）。そこに、次の基本を加えます。

• ロールベースのアクセス。 担当者は自分のキューだけを見ます。QAのレビュー担当者はサンプルを見ます。生のエクスポートやAIのログを見られるのは、ごく少数のグループだけです。
• AI自身にも最小権限を。 PCI SSCのAI原則は、AIには必要なアクセスだけを与え、取り消し可能な専用の認証情報を持たせ、その操作を記録して責任者までたどれるようにすることを推奨しています（PCI SSCのブログ）。設定が楽だからとすべての顧客レコードを読めるようにしたボットは、遅かれ早かれ、特定の1人について尋ねられることになります。
• 監査ログ。 誰が、いつ、どのトランスクリプトを開いたかを把握しておきます。
• 退職時の処理とマスク表示。 退職した日にアクセス権を削除し、IDや電話番号は、既定では末尾の数桁だけを表示します。

8つのステップでの実装方法

1. 棚卸しする。 顧客データが置かれているすべての場所を、冒頭近くの表を使って洗い出します。
2. 分類する。 データの種類ごとに、通常の個人データ、機密データ、決済データ、認証情報のどれに当たるかを分類します。
3. 決済データをサポートの経路から外す。 ホスト型の決済ページとマスキングを使います。
4. マスキングを追加する。 モデルの前、保存の前、再利用の前に行い、毎週サンプリングします。
5. 保持スケジュールを書く。 担当者を決め、トランスクリプト、要約、録音、ログ、エクスポートにまたがる削除を自動化します。
6. DPAに署名する。 ベンダーのチェックリストを一通り確認します。
7. 各ツールでリージョンとアクセスを設定する。 ユーザー一覧を見直します。
8. テストする。 偽のカード情報と個人データをチャットに流し、すべてのコピーを探し出せるか試します。展開全体については、カスタマーサービスへのAI導入をご覧ください。

避けるべき落とし穴

モデルへの入力だけをマスキングする。 生のメッセージは、トランスクリプト、ログ、エクスポートに残ることが多くあります。書き留められる場所すべてでマスキングし、「PIIマスキング」のチェックボックス1つで、データウェアハウス、通話録音システム、AIベンダーのすべてをカバーできるとは考えないでください。

削除せず、暗号化で済ませる。 セキュリティコードについては、PCI SSCは、暗号化されていても保管の禁止が適用されると述べています（PCI SSC FAQ 1280）。

一度きりのエクスポートを放置する。 3月にQAレビューのために作ったスプレッドシートが、12月になっても共有ドライブに残っています。エクスポートには有効期限を設けてください。

顧客の視点を忘れる。 AIと話していることと、メッセージがどうなるかを、顧客に伝えてください。プライバシーの失敗が引き起こすより広い問題については、カスタマーサービスにおけるAIのリスクで扱っています。