FitGap
2026-02-13

同意撤回・削除依頼の対応漏れをなくし法定期限内に完了を証明できる体制をつくる方法

顧客から個人情報の削除依頼や同意撤回の連絡を受けたとき、対応が完了するまでの流れを正確に追跡できているでしょうか。問い合わせの受付はメールや電話で行い、顧客情報はCRMやファイルサーバーに散在し、削除作業の進捗はスプレッドシートで管理する。このようにシステムがバラバラだと、どの部門が何を削除したのか、本当にすべて消し終わったのかが分からなくなります。個人情報保護法では、本人からの削除請求に対して遅滞なく対応する義務があり、対応漏れや遅延は是正勧告や訴訟リスクに直結します。

この記事は、従業員50〜300名規模の企業で、個人情報の管理や問い合わせ対応を兼務している情シス担当者や総務・法務部門の担当者を想定しています。読み終えると、削除依頼の受付から全システムでの削除完了・証跡の保存までを一本の流れとして管理できるワークフローを設計できるようになります。大規模エンタープライズ向けの全社DLP導入計画や、個人情報保護法の逐条解説は扱いません。

なお、本記事で紹介するツールの組み合わせは代表的な一例です。同じ役割を果たす別の製品でも、同様のワークフローを構築できます。

読み終えた時点で、削除依頼の受付から完了報告までの3ステップのワークフローと、各ステップで使うツールの設定方針が手元に揃います。

Workflow at a glance: 同意撤回・削除依頼の対応漏れをなくし法定期限内に完了を証明できる体制をつくる方法

  • Step 1: 削除依頼を受け付けてチケットを起票する (Zendesk) (カスタマーサポートツール)
  • Step 2: 対象データを特定し各部門で削除を実行する (Salesforce / コラボフロー)
  • Step 3: 完了を記録し依頼者へ通知する (Zendesk / コラボフロー)

なぜ削除依頼の対応が追跡できなくなるのか

受付と作業と記録が別々のシステムに分かれている

削除依頼が発生する入口は、メール、電話、Webフォームなど複数あります。受付した内容を問い合わせ管理システムに登録しても、実際に顧客データが保管されているのはCRM、ファイルサーバー、マーケティングツール、バックアップなど多岐にわたります。さらに、削除作業の進捗を管理する場所がスプレッドシートや口頭連絡だけだと、どのシステムの削除が終わったのかを横断的に確認する手段がありません。

担当部門が複数にまたがり引き継ぎで情報が消える

営業部門のCRMデータ、マーケティング部門のメール配信リスト、経理部門の請求データなど、個人情報は部門ごとに異なるシステムに格納されています。削除依頼を受けた窓口担当者が各部門に依頼を回す際、メールやチャットで個別に連絡すると、誰がいつ対応したのかが一元的に見えません。結果として、ある部門では削除済みなのに別の部門では手つかずという状態が放置されます。

対応完了の証跡が残らず監査に耐えられない

仮にすべてのシステムから削除できたとしても、いつ・誰が・どのデータを削除したかという記録が残っていなければ、監督官庁や顧客から問い合わせがあった際に対応済みであることを証明できません。個人情報保護委員会の立入検査や、顧客からの再問い合わせに対して、対応履歴を即座に提示できない状態は、実質的に未対応と同じリスクを抱えています。

重要な考え方:1件の依頼を1つのチケットに集約し、全部門の完了を1画面で確認できる状態をつくる

削除依頼の対応漏れを防ぐために最も大切なのは、1件の依頼に対して1つのチケット(管理番号)を発行し、そのチケットの中に各部門・各システムでの削除状況をすべて紐づけることです。

チケットを起点にした進捗の可視化

チケットには、対象となる顧客の識別情報、削除が必要なシステムの一覧、各システムでの削除ステータス(未着手・作業中・完了)、対応期限を記録します。これにより、チケットを開くだけで全体の進捗が一目で分かります。どこかの部門が止まっていれば、チケット上で即座に把握できます。

期限管理と自動リマインドの仕組み

個人情報保護法では、削除請求に対して遅滞なく対応することが求められています。実務上は受付から2週間以内の完了を目安にしている企業が多いです。チケットに期限を設定し、期限の3日前・1日前に自動でリマインド通知を飛ばす仕組みを入れておけば、担当者の失念による遅延を防げます。

証跡の自動蓄積

チケット上でのやり取りや、ステータス変更の履歴はすべてシステム内に自動で記録されます。後から監査や再問い合わせがあった際に、チケット番号で検索するだけで対応の全経緯を提示できます。

削除依頼を受付から完了証明まで一気通貫で管理するワークフロー

ステップ 1:削除依頼を受け付けてチケットを起票する(Zendesk)

顧客からの削除依頼は、メール・電話・Webフォームなどさまざまな経路で届きます。Zendeskをすべての受付窓口として設定し、どの経路から届いた依頼も自動的に1つのチケットとして起票されるようにします。

チケット起票時に、以下の情報をカスタムフィールドとして入力します。

  • 依頼者の氏名・メールアドレスなどの識別情報
  • 依頼の種類(同意撤回 / データ削除 / 利用停止)
  • 対応期限(受付日から14日後を自動設定)

Zendeskのトリガー機能を使い、チケット起票と同時に次のステップの担当者へ自動通知を送ります。窓口担当者がやることは、依頼内容を確認してカスタムフィールドを埋めるだけです。受付完了後、依頼者へは自動返信メールで受付番号と対応予定期間を通知します。

担当者:問い合わせ窓口担当(カスタマーサポートまたは総務) 頻度:依頼発生の都度(中小規模の企業であれば月に数件程度) 引き継ぎ:チケット起票完了をトリガーに、ステップ2の担当者へZendesk内で自動通知

ステップ 2:対象データを特定し各部門で削除を実行する(Salesforce / コラボフロー)

チケットが起票されたら、次はその顧客のデータがどのシステムに存在するかを特定し、各部門に削除作業を依頼します。

まず、Salesforceで対象顧客のレコードを検索します。Salesforceは顧客情報の中核データベースとして、氏名・連絡先・取引履歴などを保持しています。Salesforce上で該当レコードを特定したら、関連するデータの範囲(取引履歴、活動履歴、添付ファイルなど)を確認します。

次に、コラボフローで削除依頼のワークフローを起動します。コラボフローには、あらかじめ削除対象システムの一覧をチェックリスト形式で用意しておきます。具体的には以下のような項目です。

  • Salesforce上の顧客レコードと関連データ
  • メール配信ツールの配信リスト
  • ファイルサーバー上の契約書・見積書
  • バックアップデータ

コラボフローのワークフローでは、各項目に対して担当部門(営業部、マーケティング部、情シス部など)を割り当て、並行して削除作業を依頼します。各担当者は自分の担当システムでデータを削除したら、コラボフロー上で完了チェックを入れ、削除した内容(レコード数やファイル名など)をコメント欄に記録します。

コラボフローの承認ルート機能を活用し、すべての部門が完了チェックを入れないとワークフローが次に進まない設定にします。これにより、1つでも未完了の部門があれば全体が止まるため、対応漏れを構造的に防げます。

担当者:情シス担当者(ワークフロー起動)、各部門の担当者(削除実行) 頻度:チケット起票後、原則3営業日以内に全部門の削除を完了 引き継ぎ:コラボフローで全部門の完了が確認されたら、ステップ3へ進む

ステップ 3:完了を記録し依頼者へ通知する(Zendesk / コラボフロー)

コラボフロー上で全部門の削除完了が確認されたら、Zendeskのチケットに戻り、対応完了の記録を行います。

チケットのカスタムフィールドに、削除完了日と対応サマリーを記入します。コラボフローの承認履歴(誰がいつ何を削除したか)のスクリーンショットまたはPDF出力をチケットに添付し、証跡として保存します。

その後、Zendeskから依頼者へ対応完了の通知メールを送信します。通知メールには、削除が完了した旨と、今後同じデータが復元されることはない旨を記載します。

最後にチケットのステータスを完了に変更します。完了したチケットはZendesk上に永続的に保存され、後日の監査や再問い合わせ時に検索・参照できます。

担当者:問い合わせ窓口担当(最終確認と通知) 頻度:ステップ2完了後、1営業日以内 引き継ぎ:なし(このステップで対応完了)

この組み合わせが機能する理由

Zendesk:受付から完了までの一貫した時系列記録

Zendeskは問い合わせ管理システムとして、メール・電話・Webフォームなど複数チャネルからの依頼を1つのチケットに集約する機能に優れています。カスタムフィールドで依頼種別や期限を管理でき、トリガー機能で自動通知やリマインドを設定できるため、窓口担当者の負担を最小限に抑えられます。チケットの全履歴が自動保存されるため、監査時の証跡としてそのまま使えるのも大きな利点です。一方、Zendesk単体では各部門への作業指示と進捗管理を細かく制御するのが難しいため、ワークフローシステムとの組み合わせが必要になります。料金は1エージェントあたりの月額課金で、問い合わせ件数が少ない企業でもエージェント数分のコストが発生する点は考慮してください。

Salesforce:顧客データの中核データベースとしての検索性

Salesforceは顧客情報を一元管理するCRMとして、削除対象データの特定に不可欠な役割を果たします。顧客名やメールアドレスで検索すれば、取引履歴・活動履歴・添付ファイルなど関連データの全体像を把握できます。ただし、Salesforce以外のシステム(メール配信ツール、ファイルサーバーなど)に保管されているデータはSalesforceからは見えません。あくまでCRM内のデータ特定と削除に使い、他システムのデータはコラボフローのチェックリストで管理する設計です。また、Salesforceは多機能な分、ライセンス費用が高めです。すでにSalesforceを導入済みの企業にとっては追加コストなく活用できますが、未導入の場合はより安価なCRMでも同じ役割を果たせます。

コラボフロー:複数部門の並行作業を漏れなく管理する承認フロー

コラボフローは国産のワークフローシステムで、複数部門への並行承認・作業依頼を得意としています。今回のワークフローでは、削除対象システムのチェックリストを承認ルートとして設定し、全部門が完了しないと次に進めない仕組みを実現しています。日本語UIで操作が直感的なため、ITに詳しくない部門担当者でも完了チェックとコメント入力だけで参加できます。弱点としては、Zendeskとの自動連携にはAPI設定が必要で、手動での情報転記が発生する場合がある点です。FitGapでは、まずは手動転記で運用を開始し、件数が増えてきた段階でAPI連携やZapierなどの自動化を検討することをおすすめします。

Recommended tool list

ToolRolePricingImplementation timeNotes
Zendesk削除依頼の受付・チケット管理・証跡保存月額課金1〜2週間カスタムフィールド(依頼種別・対応期限)の設定とトリガーによる自動通知の設定が必要。Webフォーム・メール受付の統合設定を先に行う。
Salesforce顧客データの検索・特定・CRM内データの削除月額課金既存導入済みなら即日、新規導入は2〜4週間既存のSalesforce環境をそのまま利用。削除対象データの検索ビューを事前に作成しておくと作業効率が上がる。未導入の場合はより安価なCRMでも代替可能。
コラボフロー複数部門への削除作業依頼と並行進捗管理月額課金1〜2週間削除対象システムのチェックリストを承認フォームとして作成。全部門完了を必須条件とするルート設定を行う。日本語UIのため現場担当者への展開が容易。

結論:1件1チケットの原則を守れば削除依頼の対応漏れは防げる

削除依頼の対応漏れは、受付・作業・記録がバラバラのシステムで管理されていることが根本原因です。Zendeskで受付と証跡管理を一元化し、Salesforceで対象データを特定し、コラボフローで各部門の削除作業を並行管理する。この3ステップのワークフローを導入すれば、どの依頼がどこまで進んでいるかが常に1画面で把握でき、法定期限内の対応完了を確実にできます。

最初の一歩として、まずは直近で受けた削除依頼を1件、このワークフローに沿って処理してみてください。実際に動かすことで、自社のデータ保管場所の棚卸しにもなり、チェックリストの過不足が見えてきます。その結果をもとにコラボフローのチェックリストを調整すれば、2件目以降はスムーズに回り始めます。

Mentioned apps: Zendesk, コラボフロー, Salesforce

Related categories: カスタマーサポートツール, ワークフローシステム, 営業支援ツール(SFA)

Related stack guides: 輸出管理教育の受講完了と実務権限を自動連動させ未受講者による誤申請を防ぐ方法, 該非判定の根拠資料が散逸して再現できない問題を解消し監査対応を万全にする方法, 顧客の最終用途情報と該非判定を一元管理し安全保障貿易管理の審査漏れを防ぐ方法, 補助金の変更申請と実績報告の整合性を保ち事後監査での指摘と返還リスクを防ぐ方法, パートナーへの変更依頼が社内承認後に正しく伝わらない問題を解消し手戻りとプロジェクト遅延を防ぐ方法

サービスカテゴリ

AI・エージェント

汎用生成AI・エージェント
LLM・大規模言語モデル
エージェントフレームワーク
エージェントオートメーション基盤

ソフトウェア(Saas)

オフィス環境・総務・施設管理
開発・ITインフラ・セキュリティ
データ分析・連携