営業ツール解約時のデータ削除ポリシー｜確認すべき6つの論点

営業ツールの解約を決めたあと、管理画面の解約ボタンの前で手が止まってしまうことがあります。「解約後のデータの取り扱いについて同意します」という一文があり、その先に何が起きるのかが分からないからです。

やっかいなのは、止まる理由が自分の判断ではないことです。情シスに解約を相談すれば「預けている企業データの削除ポリシーを確認してほしい」と差し戻され、法務からは「利用規約の終了時条項を出してください」と言われます。営業現場からは「これまで送った会社の履歴は引き継げるのか」と聞かれます。解約という意思決定はすでに終わっているのに、社内に説明する材料がないために動けない、という状態です。

しかも営業ツールの中には、2 年分の送信リスト、誰にいつ何を送ったかという送信履歴、接触済み企業の除外リストが積み上がっています。これらは「顧客データ」と一括りにされがちですが、性質も、持ち出せるかどうかも、失ったときの損失もそれぞれ違います。とくに送信履歴と除外リストを失うと、解約後に同じ企業へもう一度営業してしまうという、営業活動固有の事故が起こり得ます。

解約時のデータの扱いは、実のところ「ベンダーの善意」ではなく利用規約とデータ処理に関する取り決めで決まっています。読む場所さえ分かれば、情シスにも法務にも根拠を示して回答できます。

本記事では、営業ツールの解約にあたって確認すべき利用規約の 3 条項、棚卸すべき営業資産の 5 分類、ベンダーに投げるデータ削除ポリシーの 6 論点、そして通知期限から逆算する解約スケジュールを順に整理します。あわせて、ここで洗い出した確認項目をそのまま次のツール選定の比較軸に転用する方法も示します。

営業ツールの解約で最初に詰まるのは「データの行き先」

解約は「やめる」という一回の判断で終わる作業に見えます。しかし実際には、社内の複数部門に対して「やめたあと、預けたデータがどう処理されるか」を説明する作業に変わります。ここを最初に認識しておくと、無駄な往復を減らせます。

BtoB の SaaS では、契約の見直しや乗り換えは特別な出来事ではありません。ツールの入れ替えが一定の頻度で起こることは業界の前提であり、ベンダー側もそれを想定して契約終了時の取り扱いを規約に書いています。解約を後ろめたい例外として扱う必要はなく、手順の問題として粛々と処理すれば済みます。

解約ボタンを押す前に返ってくる3つの差し戻し

営業企画の担当者が解約を進めようとしたとき、典型的に返ってくる確認は次の 3 つです。

3 つに共通するのは、いずれも「自部門で調べれば分かること」ではない点です。答えはベンダーの規約と運用の中にあり、担当者が単独で完結できません。つまり解約作業の本体は、ベンダーへの確認と、その回答を社内向けに翻訳することにあります。

汎用SaaSの解約と営業ツールの解約で異なる点

グループウェアやストレージサービスの解約であれば、論点は「自社のファイルを取り出せるか」に集約されます。ところが営業ツールの場合、預けているデータの多くが自社の情報ではなく、営業先である他社の情報です。

この違いは 2 つの形で効いてきます。

ひとつは説明責任の重さです。営業リストに含まれるのは他社の企業情報であり、問い合わせフォームの入力内容や担当者名を含む場合には個人情報にあたる可能性があります。自社データであれば「消えても自社が困るだけ」で済みますが、他社の情報を預けていた以上、どう処理されるかを説明できる状態にしておく必要があります。

もうひとつは、履歴そのものが営業資産である点です。誰にいつ何を送ったかという記録は、次の一手を決めるための材料であると同時に、二重接触を防ぐブレーキでもあります。ファイルのように「あとで探せば見つかる」性質のものではなく、その場で失われると復元できません。

解約後にデータがどうなるかは利用規約の3条項で決まる

SaaS の解約時にデータがどう扱われるかは、ほぼ例外なく利用規約か、それに付随するデータ処理に関する取り決め（DPA）に書かれています。全文を読み通す必要はありません。確認すべきは次の 3 条項です。

この 3 点を条番号つきで抜き出せれば、法務からの差し戻しにはそのまま回答できます。以下、それぞれの相場観を見ていきます。

条項1 契約終了後のデータ保持期間

契約が終了した瞬間にデータが消えるサービスは、実はそれほど多くありません。多くの SaaS は、利用企業がデータを取り出すための猶予期間を設けています。この保管期間として 30 日・60 日・90 日のいずれかを置くパターンが一般的とされています（SaaS解約時のデータ取扱い｜エクスポート義務と削除義務）。期間中は利用企業の請求に応じてデータを提供し、期間経過後はベンダーの判断で削除できる、という組み立てです。

段階的な状態遷移を設計している例もあります。一般法人向け Microsoft 365 では、サブスクリプションが「アクティブ → 期限切れ → 無効 → 削除済み」と遷移し、多くの提供形態で期限切れ状態が 30 日間、無効状態が 90 日間と定められています。無効状態の間は一般ユーザーはサービスにアクセスできず、管理者のみがデータにアクセスしてバックアップを取れます（一般法人向け Microsoft 365 のサブスクリプションが終了したとき、データとアクセスはどうなりますか?）。

削除側のタイムラインも公開されています。有料サブスクリプションが終了した場合、Microsoft は顧客データを 90 日間の制限付き機能アカウントに保持して抽出を可能にし、その後アカウントを無効化してデータを削除、サブスクリプション終了後 180 日以内にすべての顧客データを削除するとされています（Microsoft 365 でのデータの保持、削除、破棄）。「取り出せる期間」と「完全に消えるまでの期間」が別々に定義されている点が重要です。

注意したいのは、自分から解約操作をした場合に猶予期間が短縮されたり、スキップされたりするケースがあることです。前掲の Microsoft のドキュメントでも、解約ポリシーの期間内に月次サブスクリプションを取り消すと期限切れ状態を飛ばして無効状態に移ること、サブスクリプションを明示的に削除した場合は期限切れ・無効状態をスキップしてデータが直ちに削除されることが明記されています。「解約すれば猶予期間が始まる」と思い込まず、どの操作をするとどの状態に入るのかを確認してから操作する必要があります。

条項2 エクスポートの可否と提供形式

保持期間があっても、取り出せる形でなければ意味がありません。エクスポートについては次の 3 点を確認します。

標準機能で出せるか、依頼が必要か。管理画面から CSV でダウンロードできる範囲と、ベンダーへの申請が必要な範囲は分かれていることがあります。標準機能でのエクスポートは無償、個別の移行支援・大量データの抽出・特殊形式への変換は有償、という設計も見られます。有償になる場合は解約時の追加コストとして稟議に載せる必要があります。

提供形式が標準形式か独自形式か。CSV・JSON・XML のような標準形式で出せるなら、次のツールへの取り込みや表計算ソフトでの保管がしやすくなります。一方、独自形式や PDF での提供しかない場合、乗り換え先で再利用できず、実質的にデータを失うのと近い状態になります。形式は必ず事前に確認してください。

申請から取得までの所要時間。エクスポートは即時完了するとは限りません。たとえば Salesforce のデータエクスポートサービスでは、リクエストから準備完了の通知が届くまでデータ量に応じて時間がかかり、生成されたファイルは一定期間を過ぎるとサーバー上から削除されます（Salesforce からバックアップデータをエクスポートする）。準備に最大 48 時間程度を要し、ダウンロードできる期間も 48 時間に限られるという実務上の注意点が解説されています（Salesforceデータエクスポートサービス完全ガイド）。解約日の前日に申請して間に合わない、という事態は避けたいところです。

条項3 削除の範囲と方法

「削除します」という一文だけでは、情シスの確認には答えられません。削除の対象がどこまでかを分けて読む必要があります。

実務上、削除の対象は次の 3 層に分かれます。

• 本番環境のデータベース: 管理画面から見えているデータ。ここが削除されることは規約に書かれていることが多い層です
• バックアップ: 障害復旧のために別途保管されている複製。本番環境と同時には消えず、バックアップの世代が一巡するまで残る設計が一般的です
• ログ・監査記録: 操作履歴やアクセスログ。監査対応や法令上の要請から、一定期間の保存が求められる場合があります

規約でこの 3 層が書き分けられているか、書き分けられていない場合はどう扱われるのかを確認します。「本番環境からは即時削除、バックアップからは最長 N 日以内に削除」といった回答が得られれば、情シスにはそのまま伝えられます。

削除の方法も確認対象です。データを物理的・論理的にどう消去するかは、ベンダーによって開示の粒度が異なります。たとえば NTT コミュニケーションズの Smart Data Platform では、不要になった媒体について HDD の消磁やメモリの物理的な破壊を行って回復不能にしており、これらの手続きが ISO27017・SOC2 Trust サービス基準・ISMAP・PCI DSS（媒体破壊手続き）に準拠し、第三者の審査機関・監査法人による評価を受けていると説明されています（サービス解約時などのデータ削除時にデータ削除はどのように実施していますか？）。ここまで明示されていれば、準拠基準の名称を根拠として社内報告に使えます。

解約前に棚卸すべき営業資産は5種類ある

「データを取り出す」と一言で言っても、営業ツールに蓄積されているものは一様ではありません。持ち出せるかどうか、失ったときに何が起きるかは、資産の種類ごとに異なります。棚卸しの粒度を先に決めておくと、ベンダーへの質問も稟議の記述も具体化できます。

資産5種とエクスポート可否の整理

最初に着手すべきは 2 と 3 です。1・4 は出せることが多く、5 は出せなくても実害が限定的ですが、2 と 3 は「出せるかどうかがツール次第で、かつ失ったときの損失が大きい」という組み合わせだからです。

送信履歴と除外リストを失うと起きること（二度目の営業という信頼コスト）

営業ツールの解約で最も見落とされやすいのが、送信履歴と除外リストの消失です。これらは管理画面の中にあるときは当たり前に参照できるため、資産として認識されにくい傾向があります。

失われると、次のような事態が起こり得ます。

• 同じ企業への再送信: 半年前にフォームから問い合わせを送った企業に、新しいツールで再び送ってしまう。受け取った側から見れば「同じ会社から二度目」であり、単発のミスよりも印象が悪くなります
• お断りの意思表示の無効化: 「今後の送付は不要」と返信をもらった企業は除外リストに登録されているはずですが、リストごと消えればその意思表示がなかったことになります
• 既存取引先への営業送信: 取引中の企業を除外対象にしていた場合、リストを失うと営業部門が自社の顧客にフォーム営業をかけてしまう可能性があります
• 重複アプローチの検知不能: 別チャネル（メール・電話）との突合ができなくなり、社内の別担当と同じ企業に同時期に接触してしまいます

いずれも、失う金額としては見えにくい一方で、相手企業からの信頼という形で跳ね返ります。解約の稟議には「移行できないデータがある場合のリスク」として、この項目を明記しておくことをおすすめします。フォーム営業における受信企業側への配慮と法的な論点については、フォーム営業の法的リスクと個人情報の扱いもあわせてご覧ください。

スプレッドシートに退避する場合の最低限の項目設計

エクスポート機能がない、あるいは出せる形式が限られている場合、画面の情報をスプレッドシートに退避することになります。あとから使える形にするために、最低限そろえておきたい項目を挙げます。

除外リストとして残す場合

送信履歴として残す場合

ポイントは、企業ドメインを突合キーとして必ず入れておくことです。企業名は「株式会社」の前株・後株、全角半角、法人格の省略などで表記が揺れ、新しいツールに取り込んだときに照合できません。ドメインが入っていれば、退避したスプレッドシートを次のツールの除外リストとしてそのまま使える可能性が高まります。

データ削除ポリシーで確認すべき6つの論点

利用規約を読んでも書かれていないこと、書かれていても解釈が分かれることがあります。その場合はベンダーに直接確認します。以下の 6 論点をカバーしておけば、情シスと法務からの差し戻しにはおおむね回答できます。

6論点の確認項目表

質問はメールで送り、回答もメールで受け取ってください。口頭での回答は社内提出物の根拠にできません。

削除証明書に何が書かれるか、求めるべきか

データ消去証明書は、実施した消去について対象・方法・実施日・確認結果などを記録した書面または電子記録です。クラウドサービスの解約時には、どのデータがどの方法で消去されたと記録されているかを確認します（クラウドストレージのデータ消去証明書とは？解約時に確認する項目）。

一般に証明書へ記載される項目は次のようなものです。

• 消去の対象（機器・領域・データの範囲）
• 消去の方法（消去方式、使用したソフトウェアや手順）
• 消去の実施日時と実施者
• 消去の結果（成功・失敗）
• 証明書の発行日と発行者

ただし、SaaS では専有のハードウェアを利用しているわけではないため、機器単位の消去証明書がそのまま発行されるとは限りません。個人情報を含むデータについては、完全に削除したことを文書で証明する条項を契約に置くことが望ましいとする解説もあります（SaaS解約時のデータ返還・破棄ルール｜契約条項と削除証明の実務）。

現実的な落としどころとしては、次の順に確認するとよいでしょう。

1. 証明書の発行が可能か（可能なら取得する）
2. 発行できない場合、削除完了の通知メールを受け取れるか
3. 通知も行われない場合、規約上の削除期限と準拠基準を根拠として社内に報告する

3 の場合でも、「規約第 N 条により契約終了後 N 日以内に削除される」「削除手続きは ISO/IEC 27017 等に準拠していると説明されている」という形で記録を残せば、情シスへの回答としては成立します。

個人情報を含む営業リストを預けていた場合の追加確認

営業リストに担当者の氏名やメールアドレスが含まれていた場合、または問い合わせフォーム経由で個人が特定できる情報をやり取りしていた場合には、確認の重みが変わります。

個人情報保護法は、個人データの取扱いを委託する場合、委託先に対して必要かつ適切な監督を行うことを求めています。個人情報保護委員会のガイドライン（通則編）では、必要かつ適切な措置として、適切な委託先の選定、委託契約の締結、委託先における取扱状況の把握が挙げられています（個人情報の保護に関する法律についてのガイドライン（通則編））。契約終了時のデータの取り扱いを確認する行為は、この「取扱状況の把握」の一部として位置づけられます。

そのうえで、以下を追加で確認してください。

• 委託契約（または DPA）に、契約終了時のデータ返還・削除に関する定めが置かれているか
• 削除の完了を委託元が確認できる手段が定められているか
• 再委託が行われている場合、再委託先での削除まで担保されているか

ここから先の法的な解釈、たとえば「どこまでが委託にあたるか」「自社の対応が監督義務を満たすか」の判断は、社内法務または専門家に確認することをおすすめします。本記事は条文の解釈を示すものではなく、確認すべき観点を整理するものです。

解約スケジュールは「解約日」ではなく「通知期限」から逆算する

ここまでの確認項目をそろえるには時間がかかります。そして時間がかかることを見落とすと、最も避けたい事態、つまり「解約の意思は固まっていたのに、通知期限を過ぎて自動更新されてしまった」が起こります。

通知期限から逆算する標準スケジュール

年間契約の SaaS には、自動更新条項とセットで「更新しない場合は期間満了の N 日前までに通知する」という定めが置かれていることが一般的です。N は 30 日・60 日・90 日など契約によって異なります。まず契約書か利用規約でこの数字を確認し、それを起点にスケジュールを引きます。

ポイントは 2 つあります。ひとつは、通知は「解約日の前」ではなく「通知期限の前」に行うことです。もうひとつは、エクスポートは通知より後でよいことです。解約通知を出しても契約終了日まではサービスを利用できるのが通常なので、先に通知期限を守り、データの取り出しはそのあとで落ち着いて行うほうが安全です。ただし、通知と同時に機能が制限される契約もあり得るため、通知前に「通知後の利用可否」を確認しておいてください。

並行運用期間に除外リストを先行移行する理由

新しいツールへ乗り換える場合、旧ツールの契約終了日まで両方が使える期間ができます。この並行運用期間には固有のリスクがあります。旧ツールと新ツールの双方から、同じ企業に送信してしまうという事故です。

これを防ぐため、移行の順序を次のようにします。

1. 除外リストを最初に移す: 送ってはいけない企業の一覧を、新ツール側に先に登録します。これが済むまで新ツールからの送信は開始しません
2. 送信履歴を移す: 過去に接触済みの企業を把握できるようにします。除外リストに入っていなくても、直近で送った企業は当面対象から外す運用にします
3. 送信の主体を片方に寄せる: 新ツールで送信を開始したら、旧ツールからの送信は停止します。両方から送れる状態を長く維持しないことが最大の防御です
4. 送信リスト・文面を移す: 事故につながらないデータは後回しで構いません

除外リストを最後に回すと、その間に送ってしまった分は取り返せません。移行の順序は「失敗したときに取り返しがつかないもの」からと覚えておくと判断しやすくなります。乗り換え全体の進め方については、フォーム営業ツールの乗り換え手順で詳しく整理しています。

確認結果を稟議・情シス回答に落とし込む書き方

集めた情報は、社内提出物の形に整えて初めて意味を持ちます。ここまでの確認結果を、そのまま書類に転記できる形で整理します。

解約稟議に書く5項目

解約稟議でつまずくのは、たいてい「解約したい理由」ではなく「解約したあと何が起きるか」が書かれていないケースです。次の 5 項目を入れておけば、追加の質問はかなり減らせます。

3 と 4 が入っていることが、この稟議の価値です。情シスと法務が知りたいのはまさにこの 2 項目であり、稟議の段階で書かれていれば、承認プロセスの中で個別に聞かれることがなくなります。

情シス向けの回答は、稟議の 3 をそのまま転記する形で問題ありません。「規約第 N 条により、契約終了後 N 日以内に本番環境のデータを削除。バックアップからの削除は最長 N 日。実施方法は〇〇に準拠との回答をメールで受領済み（受領日 YYYY 年 MM 月 DD 日）」という粒度で書けば、必要な情報はそろっています。導入時のセキュリティ確認と観点を対比させたい場合は、営業ツールのセキュリティ確認 7 項目もあわせて参照してください。

ベンダー回答の記録と保全

ベンダーからの回答は、あとから参照できる形で残してください。最低限、次の 3 つを記録します。

• 回答日: いつ時点の回答かを特定するため
• 回答者: 所属と役割（サポート窓口／営業担当／セキュリティ担当）
• 根拠条項の番号: 回答が規約のどこに基づくものか

あわせて、確認時点の利用規約そのものを保全しておきます。利用規約は改定されるため、解約手続きの途中で内容が変わる可能性があります。該当ページを PDF として保存するか、条項部分のスクリーンショットを取得し、取得日とあわせて保管してください。規約の版（改定日）が明記されている場合は、その日付も控えておきます。

この記録があると、万一の認識違いが起きたときに「いつ、誰から、どの条項に基づいて、どう説明を受けたか」を提示できます。逆に記録がないと、確認作業を最初からやり直すことになります。

次のツールは「解約しやすさ」も比較軸に入れる

ここまでの確認項目は、解約時にだけ役立つものではありません。すべて、導入前に確認できる項目です。出口の要件を入口の比較軸に転用すれば、次の乗り換えで同じ停滞を繰り返さずに済みます。

出口から見た選定チェックリスト

ツール選定の際、機能や料金と並べて次の観点を確認します。トライアルや商談の場で聞けば、多くは回答が得られます。

このうち 1〜3 は、トライアル期間中にダミーデータでエクスポートを試してみるのが確実です。「できます」という回答と、出力されたファイルの中身が一致しないことは起こり得ます。

データの持ち出しやすさを設計に織り込んでいるか（Form Pilot の設計思想とCAPTCHAの扱い）

上記のチェックリストのうち、送信履歴の可視化と組織単位のデータ分離は、解約時だけでなく日常の運用品質にも直結する項目です。参考として、秋霜堂株式会社が提供する Form Pilot の設計を挙げます。

Form Pilot は、営業代行・BPO 事業者での利用も想定し、マルチテナント設計によって企業リスト・送信履歴・文面を組織単位で分離しています。他の組織からは参照できない構造です。また、送信履歴と失敗診断を画面上で確認できるようにしており、いつ・どこに送り、どの理由で失敗したかを運用中に把握できます。送信前には、他社（取引先や別チャネル）がすでに接触済みの企業ドメイン一覧を外部 API から取得して送信リストと突合し、該当する企業への送信を自動で回避します。判断できない場合は送らない側に倒す設計（fail-closed）を基本としています。

もう一点、フォーム営業ツールを比較するうえで押さえておきたいのが CAPTCHA の扱いです。Form Pilot は CAPTCHA の突破を行いません。CAPTCHA 等で完全な自動送信ができないフォームでは、Chrome 拡張機能が入力までを自動化し、送信ボタンは人が押すセミオート設計を採っています。CAPTCHA は受信側が「機械的な送信を受けたくない」と示す意思表示であり、それを不正な手段で迂回する行為は、送信元である利用企業の名前で行われることになる、という判断に基づく設計です。

フォーム営業ツールを比較するときは、送信の実行方式（完全自動／セミオート／人手代行）、CAPTCHA の扱い、接触済み企業の除外運用、送信履歴の可視化、データ分離の有無を並べて見ると、ツールごとの設計思想の違いが見えてきます。そしてその多くは、解約するときに自分が困るかどうかに直結します。

まとめ：営業ツールの解約は契約前から設計しておく

営業ツールの解約でつまずくのは、やめる判断ができていないからではなく、やめたあとに何が起きるかを社内に説明できないからです。説明に必要な材料は、次の 4 つの塊に整理できます。

• 利用規約の 3 条項: 契約終了後のデータ保持期間、エクスポートの可否と提供形式、削除の範囲と方法。保持期間は 30・60・90 日のいずれかに置かれることが多く、条番号つきで抜き出せば法務への回答になります
• 営業資産の 5 分類: 送信リスト・送信履歴・除外リスト・文面テンプレート・反応データ。とくに送信履歴と除外リストは、失うと解約後の再接触という信頼コストにつながります
• データ削除ポリシーの 6 論点: 起算日、削除対象の範囲、実施方法と準拠基準、削除証明の発行可否、再委託先での削除、個人情報を含むデータの扱い。メールで質問し、メールで回答を受け取ります
• 通知期限からの逆算: 解約日ではなく自動更新の通知期限を起点にスケジュールを引き、エクスポートの処理時間と並行運用期間の誤送信リスクを織り込みます

いま解約を検討している段階であれば、着手する順序は決まっています。

1. 契約書・利用規約で自動更新の通知期限を確認する（ここを過ぎると 1 年待つことになります）
2. 管理画面で営業資産 5 種のエクスポート可否を実地確認する（できる／できないの一覧をつくります）
3. 6 論点の質問をベンダーへメールで送る（回答に時間がかかる前提で早めに送ります）

この 3 つが終われば、稟議も情シスへの回答も書ける材料がそろいます。そして同じチェックリストは、次に選ぶツールの比較軸としてそのまま使えます。解約のしやすさは、契約する前にしか確認できない項目です。

関連情報

送信履歴の可視化や組織単位でのデータ分離を含め、フォーム営業ツールの設計を確認したい方は Form Pilot のサービスページをご覧ください。CAPTCHA を突破しないセミオート設計や、接触済み企業の自動除外の考え方を紹介しています。

営業ツールの乗り換え・導入の各段階については、以下の記事もあわせてご覧ください。

• フォーム営業ツールの乗り換え手順
• 営業ツールのセキュリティ確認 7 項目
• フォーム営業の法的リスクと個人情報の扱い