GDPR対応リクエストにAIを使う：ヘルプデスクで自動化すべきことと、人が担うべきこと

TL;DR

GDPRリクエストへのAI活用は、削除する役ではなく、見つけて期限を管理する役として使うのが最適です。 AIにすべてのチケットを読ませ、誰も「GDPR」と入力していなくても「私のデータを送ってください」や「アカウントを削除してください」を認識させ、リクエストの種類にタグを付け、1か月の期限を開始し、受領確認を下書きさせます。人が担う手順は3つです。疑わしい場合の本人確認、データのエクスポートの承認、そしてあらゆる削除の承認です。

この分担が重要なのは、削除は元に戻せず、消去の権利は絶対ではないからです。未払いの請求書や未解決の紛争がある顧客は、法律上、一部を断らなければならない内容を求めているかもしれません。1通のメールを読むだけのモデルには、それが分かりません。アカウントを目の前にした人なら分かります。

多くのガイドが触れない点が2つあります。ヘルプデスクには、すでに頼ることになる削除や墨消しのツールがあること（Zendeskのものが最も充実しています）。そして、AIツールが過去のチケットから学習している場合、AIツールも削除チェックリストに入ることです。eeselは、Zendesk、Freshdeskなどのヘルプデスクの中で、検知、タグ付け、下書きの作業を担い、選んだ操作を承認待ちで保留し、過去のチケットの個人情報を保存前にマスクできます。ドイツのローン比較サイトsmavaは、月に約27,000件のZendeskチケットで、このようなまず分類する構成を運用しています。

サポートのキューで、何がGDPRリクエストになりますか？

GDPRリクエストとは、自分について保有されている個人データの閲覧、移行、訂正、削除を求めるあらゆるメッセージです。サポートのキューでは、ラベル付きで届くことはほとんどありません。

英国の規制当局はこの点をはっきり述べています。リクエストの認識に関するガイダンスによると、リクエストは口頭でも書面でも、SNSでも、組織のどの部署に対しても行え、「データ主体アクセス請求」という言葉を使う必要も法律名を挙げる必要もありません。個人情報を求めていることが明確であれば足ります。同じページには、どの従業員も有効なリクエストを受け取る可能性があり、そのすべてを正しく識別して処理しなければならないとも書かれています。

ここにAIを使う理由のすべてがあります。「GDPR」というキーワードのルールで拾えるのは、プライバシーポリシーを読んだお客様だけです。請求に関する苦情の末尾に「実際に私の何を持っているのですか？」や「アカウントを閉じて全部消してください」と書くお客様は見逃されます。AIエージェントは人と同じようにすべてのチケットを読むので、両方を拾えます。

私はeeselのヘルプデスク連携を作っており、以下のリクエストの種類は、最初にエージェントに教えたいものです。GDPRの第15条から第21条の権利に対応しています。

最後の行は些細に見えて、チームが最もつまずく部分です。「配信停止してください」を通常のチケットとして処理すると、丁寧な返信が届くだけで何も起きません。異議申立てとして処理すれば、すべてのマーケティングツールで確認されます。この違いを理解しているAIによるチケットのタグ付けは、どんな気の利いた返信よりも価値があります。

GDPRリクエストへの回答期限はどのくらいですか？

GDPRの第12条により、リクエストを受け取った日から暦月で1か月です。リクエストが複雑な場合や大量に受け取った場合は、さらに2か月延長できますが、その最初の1か月以内に理由を添えて本人に伝える必要があります。

英国規制当局の回答に関するガイダンスには、つまずきやすい数え方のルールが書かれています。

• 1か月は翌月の同じ日付まで。 5月14日のリクエストは6月14日の終わりが期限です。その日付が存在しない場合（1月31日）は、翌月の最終日を使います。
• 時計は、依頼した身分証明を待つ。 誰が請求しているのか本当に疑わしい場合、1か月は本人の身分証明または第三者の権限が届いた時点から始まり、それより前ではありません。
• 確認の依頼で時計が止まる。 5月15日に内容を確認し、5月18日に回答が届いたら、その4日分を加算します。
• 週末は先送りされる。 土曜日が期限なら、次の営業日の終わりに移ります。
• 28日の社内目標は認められる。 システム上、固定の日数が必要な場合で、常に1か月の範囲内に収まります。

この身分証明のルールこそ、AIエージェントが力を発揮するところです。確認を早く求めるほど、時計が動き出す前に1か月を消費することが減り、エージェントなら誰かが次にキューを開くのを待たず、最初の1分で依頼を送れます。正直な注意点がひとつあります。これらの数え方は英国の規制当局の解釈ですので、EUにお住まいの場合は、時計がいつ始まるかについて各国の規制当局のガイダンスを確認してください。リクエストが届いた日に身分証明を依頼すれば、その違いは問題になりません。

実際のチケットの日付を入力して期限を確認してください。上記の英国の数え方に従って計算します。

ヘルプデスクにSLAタイマーがあるなら、これがそのタイマーが数えるべき日付です。ほとんどの製品にあり、チケットの種類ごとに設定する方法はSLA管理ガイドで解説しています。

GDPRリクエストのどの部分をAIが担えますか？

AIは、読む、仕分ける、時間を管理する、書くという作業のすべてを担えます。誰かにデータを開示したり、データを破棄したりする作業は任せるべきではありません。

どのチームでも、最初はこの分担から始めることをお勧めします。

初日からAIに任せる

1. 検知。 新しいチケットとコメントをすべて読み、個人データに関するものにフラグを付けます。言語は問いません。キーワードルールが失敗するのがこの段階です。
2. 種類のタグ付け。 アクセス、消去、訂正、ポータビリティ、異議申立てのいずれかをチケットのフィールドに書き込み、集計できるようにします。
3. 時計の開始。 チケットが届いた瞬間に受領日と期限日を設定します。人が手を付けるまで待ちません。
4. 下書き。 受領確認、身分証明の依頼、「確認が必要です」の連絡、最終確認。すべて、プライバシー担当者が一度承認したテンプレートから作成します。
5. 情報の収集。 アカウントを調べ、この人のデータを持つシステムを一覧にし、未完了の注文や未払いの請求書など、削除を妨げるものにフラグを付けます。

人に残す

1. 疑わしい場合の本人確認。 規制当局は、ログイン済みのアカウントなど、すでにある確認手段を使い、合理的かつ適切な範囲で行うよう述べています。既知の顧客のアカウントのメールアドレスからのリクエストなら、通常それ以上は不要です。新しいアドレスから他人の注文履歴を求めるリクエストには、人が必要です。
2. エクスポートの承認。 ファイルが外に出る前に誰かが読みます。サポートチケットには、配送業者、CCに入っている同僚、苦情の相手など、他人の名前が多く含まれているためです。
3. 削除の承認。 問題が起きやすいため、次のセクションで扱います。

返金などで人への引き継ぎをすでに運用しているなら、これはそれと同じパターンで、ルールがより厳しいだけです。AIが準備し、人がボタンを押します。

なぜAIは顧客データを自分で削除してはいけないのですか？

削除は元に戻せず、しかも法律上、一部のデータは保持しなければならないことが多いからです。

英国規制当局の消去の権利に関するガイダンスは、まさにそこから始まります。この権利は絶対ではなく、特定の状況でのみ適用されるというものです。法的義務を果たすため、または法的請求の確立、行使、防御のためにデータが必要な場合は、全部または一部を拒否できます。サポートの現場では、チャージバックが進行中なのにすべてを消してほしいという顧客や、税務上、請求書を保管しなければならない顧客がこれに当たります。

ヘルプデスクのツール自体も、同じ前提で作られています。Zendeskのチケット墨消しは元に戻せません。Help Scoutのプロファイル削除は、関連するすべての会話を取り消しなしで削除します。FreshdeskのDelete foreverは、コンタクトのチケットとメモを削除し、同社の公式ガイドも、削除とエクスポートのリクエストは、依頼者が本物かを確認する管理者を通すべきだとしています。

順序もあります。ZendeskのGDPRガイドは、ユーザーは最後に削除するよう述べています。それらのチケットを探すのにプロファイルが必要なので、まずチケットの会話から個人データを消します。プロファイルを先に削除するエージェントは、残りの作業を自ら難しくしたことになります。

そのため、あらゆるエージェントの指示に書くルールは短くなります。削除は決して実行せず、必ず準備だけする。削除するものと保持するものの一覧を下書きし、理由にフラグを付けて、人に承認を求めます。

ヘルプデスクにはすでにどんなGDPRツールがありますか？

主要なヘルプデスクはどれも顧客を削除できます。違いは、墨消し、AIの支援、リクエストの受付口にあります。各ベンダーのヘルプセンターで確認しました。

「見当たらない」は、そのベンダーのGDPRヘルプページに記載がないという意味であり、製品内の別の場所に機能が存在し得ないという意味ではありません。

6製品のうち、GDPR対応そのものにAIを組み込んでいるのはZendeskだけです。墨消しの提案は個人データをオレンジ色でハイライトし、エージェントが一度の操作で墨消しできるようにします。

この機能は、Suite Enterprise以上向けのAdvanced Data Privacy and Protectionアドオンに含まれるため、前提に設計する前にZendeskのプランを確認してください。また、Zendeskは、AIエージェントのチケットでは使えないとも記しています。

HubSpotのリクエストページは、他のヘルプデスクでも真似したいものです。「削除ですか、エクスポートですか？」と尋ねるフォームは、曖昧なメールを、確認済みのアドレス付きで種類が決まったリクエストに変えます。これはAIエージェントが最も扱いやすい入力です。Freshdeskをお使いの場合は、そのGDPR設定を別に解説しています。GorgiasのチームはGorgiasとGDPRをご覧ください。

ヘルプデスクにGDPRリクエスト用のAIを設定する方法

どのヘルプデスクでも、この順序で設定します。AIに他は何も触らせなくても、ステップ1から3は最初の1週間で行う価値があります。

ステップ1：検知ルールを平易な言葉で書く

キーワードのリストではなく、リクエストがどういうものかの例をエージェントに渡します。「私についてどんなデータを持っていますか」「アカウントを削除してください」「すべてから私を外してください」「注文履歴のコピーがほしい」「私のデータを使わないでください」を、対応するすべての言語で用意します。苦情に埋もれたリクエストも対象であること、弁護士や親族が本人に代わって行うリクエストもリクエストであることを伝えます。

ステップ2：種類にタグを付け、日付を設定する

エージェントにリクエストの種類をチケットのフィールドへ書き込ませ、受領日を設定させます。そのうえで、時間の管理はヘルプデスクのSLAに任せます。このフィールドで集計すれば、月に5件なのか50件なのかが分かります。これはAIによるサポートのレポートのガイドで詳しく扱っています。

smavaは、規制の厳しい金融業界で、まさにこの形で運用しています。1つのeeselエージェントが、新しいチケットとコメントのたびに起動し、言語にタグを付け、チームが作成したマッピング文書から1つのカテゴリを選び、2つのZendeskフィールドに書き込みます。それ以外には何も触りません。1か月で約27,000件のチケットのうち約14,600件を分類し、自動返信の対象としてマークされたのは約1,100件だけでした。規制の厳しいキューでは、価値の大半は仕分けにあります。

ステップ3：受領確認と身分証明の依頼を下書きする

プライバシー担当者と一緒にテンプレートを一度だけ作成します。期限日を入れた受領確認、「ご本人であることをご確認ください」のメッセージ、確認事項の連絡、延長の通知です。エージェントがそれを埋めます。リクエストがSNSから来た場合は、非公開のチャンネルを依頼させます。規制当局は、SNSは本人にそのデータを送る安全な方法ではないと述べています。

ステップ4：取り消せない操作はすべて承認制にする

ここが、残りを安全にするステップです。eeselでは、エージェントが実行できる各操作を、エージェントごとに、自動で実行、先に確認、オフのいずれかに設定します。操作と承認のドキュメントでは、返信と取り消せない操作を承認制にした、監督付きの状態から始めることを推奨しています。

GDPRのチケットでは、タグ付けと社内メモは自動のまま、公開の返信は承認制、削除やデータのエクスポートの操作はオフか承認制にしておくことをお勧めします。操作がオンでも、特定のケースだけ保留にすることもできます。「データの削除に関することへの返信は、先に確認する」といった指示を与えると、エージェントはそのケースだけ止まります。他の種類のチケット向けのパターンは、承認ワークフローの記事で解説しています。

ステップ5：名前のある担当者に振り分ける

どのリクエストの種類も、グループの共有受信箱ではなく、個人に届くようにします。通常は、消去とアクセスはプライバシーまたはデータ保護の責任者、訂正とオプトアウトはサポート運用担当です。AIエージェントはタグで振り分けを即座に行えますが、どこにも届かない振り分けルールを直すことはできません。担当者を誰にするか検討するなら、サポートの職務の記事にモデルがあります。

ステップ6：ログを残す

規制当局やお客様から求められたときに、何が起きたかを示せる必要があります。ヘルプデスクはチケットの履歴を保持し、AIツールはすべての操作について独自の記録を保持すべきです。eeselでは、すべての実行が承認ステータスとともにアクティビティビューに表示されます。

ステップ7：過去のGDPRチケットでテストする

本番に移す前に、すでに処理したリクエストに対してエージェントを実行します。苦情に紛れたものも含め、すべて検知できたか。「配信停止してください」を一般的な質問ではなく異議申立てとしてタグ付けできたか。過去チケットでのシミュレーションなら午後のうちに答えが出て、ルールが見逃したであろうリクエストを見つける最も安い方法です。

AIツールもGDPRリクエストの対象ですか？

はい。そして、ほとんどのガイドが抜かしているのがこのステップです。AIエージェントが過去のチケットから学習している場合、忘れられることを求めたお客様が、ヘルプデスクから削除した後もAIツールの保存済みチケット履歴や検索インデックスに残っている可能性があります。

対処法は2つあります。1つ目は、そもそも個人データをAIのインデックスに入れないことです。eeselのPII墨消しは、保存やインデックス化の前に過去のチケットを検出器に通し、氏名、メールアドレス、電話番号、住所、IBAN、国民IDなど15のカテゴリをマスクします。エージェントはチームの返信の仕方を学習し続けますが、誰が質問したかは保存しません。連携ごとにオプトインで、ヘルプデスクから同期した過去のチケットに適用され、オンにする前にインデックス化されたチケットは対象外のため、最初の同期の前にオンにしてください。2つ目は、AIベンダーを削除チェックリストに加え、バックアップがデータを保持する期間を確認することです。eeselのTrust Centerには、暗号化されたバックアップは35日以内に消えると記載されています。

この35日という期間は一般的で、規制当局の消去に関するガイダンスも認めています。データは上書きされるまでバックアップに残っていてもよく、利用できない状態にし、本人に何が起こるかを明確に伝えていることが条件です。

ベンダー確認の残りは、他のAIサポートベンダーに対して行うものと同じです。

• データ処理契約。 eeselのものはGDPRに対応し、国際移転には標準契約条項を用います。
• 公開されたサブプロセッサーの一覧。 AIモデルのプロバイダーを含め、Trust Centerにあります。
• お客様のデータで学習しない。 eeselは顧客データでモデルの学習やファインチューニングを行いません。
• データの所在。 EUまたは米国のデータレジデンシーは、無料プランを含むすべてのeeselのプランに記載されています。

はっきり述べておくべき不足がひとつあります。eeselのSOC 2 Type II監査は進行中で、観察期間は2026年10月1日から12月31日まで、報告書は2027年に出る見込みです。調達部門が今日すぐに報告書を必要とするなら、それは現実的な制約です。代わりに何を求めるべきかは、セキュリティレビューのガイドで解説しています。

EUのチームは、これらの要件のもとで以前からeeselを運用しています。北欧のHRコンプライアンスソフトウェア企業Simployerは、導入事例で次のように語っています。

"We needed a turnkey solution for Confluence that met our GDPR requirements and could serve different teams through dedicated Slack bots. eesel AI delivered exactly that, with EU data residency included."

Flemming Ottosen, Development Director, Simployer

AIとGDPRリクエストでよくある間違い

最初の1か月で注意したいものを挙げます。

• 何も終わっていないのに、エージェントに「完了しました」と返信させる。 確認メールは事実の表明です。エージェントに下書きさせ、削除やエクスポートが承認され完了してから送信します。
• アクセスリクエストにチャットの履歴で答える。 アクセスリクエストは、チケットのやり取りだけでなく、すべてのシステムが対象です。エージェントの仕事はシステムの一覧を作ることで、その一覧が漏れなく揃っているかは人が確認します。
• 依頼してきた人に誰彼なくエクスポートを送る。 新しいメールアドレスから既存顧客のデータを求めるリクエストは、典型的なソーシャルエンジニアリングの手口です。まさにそのときに、規制当局の求める本人確認が必要になります。
• 他のツールを忘れる。 Gorgiasは、顧客を削除してもShopifyやKlaviyoには影響しないとはっきり述べています。チェックリストには、AIツールを含むすべてのツールが必要です。
• 「配信停止」を雑談として扱う。 これは処理への異議申立てです。タグ付けし、振り分け、オプトアウトが反映されたことを確認します。

こうした導入がどこでつまずくかについてセカンドオピニオンがほしい場合は、導入スケジュールの記事が、稼働開始の調整をより詳しく扱っています。

ヘルプデスクのGDPRリクエストにeeselを試す

eeselは、サポート向けのAIチームメイトとしてヘルプデスクに加わります。GDPRリクエストでは、新しいチケットをすべて読み、どんな言い回しや言語でもデータのリクエストを認識し、種類にタグを付け、テンプレートから受領確認と身分証明の依頼を下書きし、選んだすべての返信や操作を人の承認のために保留します。Zendeskと、上の表の他のヘルプデスクで動作します。Freshdeskでは、Freshdesk連携が同じように動きます。

承認は、チームがすでに使っている場所に届きます。ダッシュボード、Slackのスレッド、ヘルプデスクのメモ内のリンクです。プライバシー業務をターミナルで行うチームは、eesel CLI（eesel approvals）で保留中の操作を一覧表示して承認でき、Claude Codeのようなコーディングエージェントからも操作できます。

ルールは、あなたが書く平易な文章です。英国のナンバープレート販売業者Swiftregは、Zendesk上でeeselエージェントを運用しており、指示にそう書かれているため、個人の売り手を名前では呼ばず、「売り手」または「現在の所有者」とだけ呼びます。デンマークのDokument 24では、エージェントが月に約430件のチケットを製品別にタグ付けし、約670件のデンマーク語の返信下書きを、チームが送信する社内メモとして残します。GDPRリクエストでも、この形をお勧めします。エージェントが仕分けして下書きし、人が決めます。

プランは100クレジットの無料から始まり、GDPRのチケットも他のチケットと同じ1クレジットです。ご自身のキューでeeselを試すか、その前にお客様の事例をご覧ください。