>
>
公開日
SaaSの解約後に残るデータ・連携・DNS設定・アカウント・請求を、情シス向けに整理します。解約前・解約直後・解約後1〜3か月の確認事項と担当者、削除証明書の扱い、サブドメイン乗っ取りへの対処を解説。サービス別の比較表と、そのまま使える台帳・チェックリストで、後始末の完了条件まで把握できます。
SaaS解約後の後始末とは
SaaS解約後の後始末とは、契約終了とは別に、残存データ・連携・DNS設定・アカウント・請求の状態を確認し、対応記録を残す作業です。
本記事のポイント
解約とデータ削除は別の手続きです。
外部連携とDNS設定も確認対象です。
解約前・直後・1〜3か月後に担当者を割り当てます。
削除確認と請求確認の記録を残します。
対象は、法人でクラウドサービスの利用終了を管理する情報システム部門の担当者・管理者です。情報は2026年10月28日時点です。データ削除の方法・期限や最終請求の扱いは、対象サービスの契約条件によって異なります。SaaSの解約とデータ削除を分け、利用部門や経理と役割を決めて、契約・技術設定・支払いの各状態を記録にまとめます。
着手時は、末尾の「後始末台帳の項目と完了条件」の台帳とチェックリストで対象サービスと担当者を整理します。削除や請求停止を裏付ける記録がそろえば完了とし、不明な項目があれば未完了として担当者と再確認日を残します。
解約しても残るデータとアカウント
SaaS解約後は、契約終了とデータ・アカウントの消去を別々の確認対象として扱います。解約日だけでは、データを取り出せる最終日、本番環境の削除予定日、バックアップの削除完了時点、アカウントの削除状況を判断できません。
保持期間と取り出し期限
データの保持期間を、そのまま取り出し可能な期間と見なしてはいけません。管理上は、解約日を契約が終了する日、取り出し期限を必要なデータを取得できる最終日、削除予定日を事業者が対象データを消去する予定日として分けて記録します。
主なSaaSについて、各社の公式文書に書かれている解約後の扱いは次のとおりです（2026年10月28日時点）。契約形態や地域、プランで条件が変わることがあるため、自社の契約に適用される文書で確かめます。
サービス | 公式文書に書かれている解約後の扱い | 一次資料 |
|---|---|---|
Google Workspace | 「ユーザーのデータを削除する」を選ぶと、ドライブのデータは90日以内に削除されます。ユーザーアカウント・グループ・組織構造は、組織のGoogleアカウントを削除するまで残ります。サードパーティ製アプリのデータは、解約しても自動では削除されません。 | |
Microsoft 365 | 有料サブスクリプションの終了後90日間は、機能を制限したアカウントでデータを保持し、データを取り出せるようにします。90日を過ぎるとアカウントを無効にし、データを削除します。 | |
Salesforce | データの返却を求められるのは契約終了後30日以内です。表では、本番環境からの削除が終了後121〜211日目、バックアップからの削除が121〜301日目とされています。 | |
Box | 書面で依頼すると、データを取り出すために最長30日間利用できます（地域別規約の記載で、すべての契約に同じ条件が適用されるとは限りません）。 |
どのサービスも、解約した日にデータが消えるわけではありません。反対に、取り出せる期間には期限があり、期限を過ぎると取り出せなくなります。解約日・取り出し期限・削除予定日を分けて台帳に記録します。
表を確定する際は、期間だけでなく「何を起点に、どの条件で、その期間が適用されるか」を根拠とセットで記録します。取り出し期限が確定できれば取得作業の締切を設定し、確定できなければ解約後も取得できる前提を置かず、解約前のデータ確保を作業条件にします。
本番・バックアップ・アカウントの残存
本番とは通常のサービス提供で使用する環境、バックアップとは復旧用の複製データです。ログインできなくなったことだけを、両方のデータが消えた証拠にはしません。
本番データは、削除対象と完了を裏付ける記録がそろえば完了とし、予定日しか分からなければ未完了にします。
バックアップは、本番とは別に削除予定日と適用条件を記録し、根拠がなければ未確認として残します。
アカウントは、利用停止と削除を区別し、組織アカウントや外部アプリのデータを一括して削除済みと判定しません。
再点検の確認日を設定しても、その日を事業者の削除完了日と同一視しない運用にします。事業者が示す削除予定日が先なら、台帳は未完了のまま担当者へ引き継ぎ、期限到来後の再確認日を設定します。完了の根拠を取得できれば該当項目を閉じ、取得できなければ未確認の状態を維持します。
利用者側の責任と削除を確かめる記録
利用者側では、契約終了の手続きと分けて、データ返還・消去の確認と記録の保管を管理します。ここでいう「後始末の責任」は、利用者側が確認作業を管理するという意味であり、あらゆる損害や法的責任を利用者だけが負うという意味ではありません。
個人情報保護委員会の個人情報保護法ガイドライン（通則編）は、利用する必要がなくなった個人データを遅滞なく消去するよう努めることを定めています（3-4-1）。また、個人データの削除を委託した場合は、委託先が確実に削除したことを証明書等で確認することが重要としています（10-5(4)）。本記事は法的助言ではありません。委託・共同利用・保存義務が関わる場合は法務部門に確認し、保存義務があるデータは消去対象から外して保管期間を台帳に記録します。
行政機関の例では、デジタル庁のガバメントクラウドの利用に関する文書（第3.0版）が、利用を終える前にデータを自らの責任で消去すること、消去しないまま利用を終えて消去できなくなった場合は利用した側が責任を負うことを定めています。自治体向けの文書ですが、「解約前に消しておかなければ、後から消せなくなる」という点は、民間のSaaS契約でも契約書で確かめておく事項です。
事業者に削除証明書を依頼する場合は、次の項目を依頼文に含めます。「削除済み」という回答だけで対象を判断せず、自社が消去を求めたデータと回答内容を照合できる形にします。
対象サービス：サービス名と契約・利用環境を特定する情報
対象データ：返還・消去を求めるデータの種類
削除対象範囲：どの保存領域や複製まで対象とするか
実施日または予定日：完了した日か、今後の予定かの区別
バックアップの扱い：削除対象に含むか、残る場合の扱いと消去予定
依頼文は、上の5項目を埋めた次の形でそのまま使えます。
件名：【サービス名】解約に伴うデータ消去のご確認と削除証明書の発行依頼（契約ID：＿＿）
契約ID＿＿のサービスは、＿＿年＿＿月＿＿日付で契約が終了します。下記のデータについて、消去の実施状況をご回答ください。
①対象データ：＿＿
②削除対象範囲：本番環境・バックアップ・連携先への複製のうち＿＿
③実施日（予定の場合は予定日と明記）：＿＿
④バックアップに残る場合の扱いと消去予定日：＿＿
削除証明書を発行いただけない場合は、同じ内容を記載した回答書面をご提供ください。回答期限：＿＿年＿＿月＿＿日
証明書を取得できる場合は、後始末台帳の該当サービスに紐付けます。ただし、証明書の受領だけでは完了にしません。対象データと削除範囲が依頼内容に合い、予定ではなく実施済みで、未確認事項が残っていなければ、消去確認を完了とします。バックアップなどに未確認の範囲があれば、その範囲と次の確認日を台帳に残します。
証明書を取得できない場合は、事業者の回答、回答が対象とする範囲、未確認事項を記録し、未完了として扱います。契約終了の受付メールを、データ消去の完了記録として代用する運用は避けます。
契約終了時の返還・消去を委託先管理と結び付けて確認する場合は、委託先管理の記事を参照します。委託該当性の判定や委託先評価全体はそちらで扱い、ここでは返還・消去の回答と証跡を台帳の完了判定につなげます。
▲ データ消去の確認可否と完了を判定する判断フローです。
解約前のデータ確保と期限管理
解約前は、データの書き出しと利用確認を終え、削除確認の依頼先と解約予告期限を台帳に残します。
SaaS解約後もデータを業務で使う場合は、ファイルの取得だけで完了にせず、利用部門による内容確認までを解約前の作業に含めます。以下は、データの保存や移行が必要な場合の運用例です。担当名だけでなく、利用権限を失う日から逆算した期限と、作業を閉じる条件を割り当てます。
時期 | 確認対象 | 担当例 | 完了条件 | 記録 |
|---|---|---|---|---|
解約前 | 保存対象、書き出し、解約予告期限 | 情シス・利用部門・契約管理担当 | 利用権限を失う前に移行先で利用でき、解約受付または終了可能日が確定している | 取得対象、確認結果、受付記録、終了日 |
解約直後 | 削除確認の依頼、問い合わせ経路、連携先の保存データ | 情シス・契約管理担当 | 対象ごとに返還・消去の確認先と回答予定日が決まっている | 依頼先、受付番号、回答予定日 |
解約後1〜3か月 | 未回答の削除依頼、支払対象期間との照合 | 契約管理担当・経理 | 回答を保存し、未解決事項の担当と次回期限が決まっている | 回答記録、請求照合結果、残課題 |
データ確保の完了条件は、利用部門が移行先または保管先で内容を利用できることです。保存対象が決まったら、情シスが書き出しを行い、利用部門が必要な期間・項目・添付資料などを照合する分担にします。読めない場合や対象が不足する場合は、完了扱いにせず、利用権限を失う前に再取得または移行手順を見直します。ファイルが存在するだけで利用確認を省く進め方は避けます。
社内で保存が必要と判断したデータと、事業者に消去を依頼するデータは、台帳上で分けて記録します。同じデータを社内に保管し、サービス側では消去する場合も、保管場所と消去対象を別々に記載すれば、作業範囲を取り違えずに済みます。
削除の回答を解約後に受け取る運用なら、ログインできる間に次の項目を埋めます。
削除証明書を依頼する窓口と、発行可否を記録します。発行されない場合は、削除対象・実施日・結果を回答として残せるか事業者に照会し、取得できる記録を決めます。
解約後の問い合わせ経路と受付番号を保存します。管理画面以外の連絡手段が未確定なら、契約管理担当の未完了作業として期限を付けます。
連携先アプリにもデータを保存している場合は、連携解除とは別に、返還・消去の確認先と社内担当を割り当てます。
契約上の解約予告期限がある場合は、通知を出す期限と契約終了日を別項目にします。期限内なら申請内容と受付記録を保存し、期限を過ぎている場合は、契約管理担当が契約書と事業者の回答を基に終了可能日と支払対象期間を確定します。経理には確定した期間を共有し、希望終了日だけで支払終了を判断しない運用にします。解約予告期限そのものの管理は契約管理の運用で行い、ここではデータ確保の作業期限との対応を残します。
▲ 解約前から解約後1〜3か月にかけて進める後始末のステップです。
解約直後の連携解除とDNSの後始末
解約直後は、外部連携とDNS設定を確認し、残作業に使う管理経路を確保したうえで不要な接続を解除します。SaaS解約後の後始末では、データだけでなく、サービスに接続する許可や認証情報、自社ドメインからの参照も作業対象に含めます。
OAuth・API・Webhookの解除
外部連携は、設定権限を持つ担当者が連携元・連携先の管理画面で対象を特定し、残作業への影響がないものから解除します。契約名だけで探すのではなく、接続先や利用目的を照合すると、別の業務で使っている連携との取り違えを避けられます。
OAuthはアプリに与えるアクセス許可、APIキーはAPI接続に使う認証情報、Webhookはイベントが発生した際の通知先です。それぞれ役割が異なるため、どれか一つを解除しただけで、すべての接続を処理したとは判断しません。
対象を見つけたら、次のチェックリストに沿って、利用責任者と設定権限を持つ担当者が解除範囲を決めます。
連携元・連携先の管理画面で、アプリ名、キーの識別情報、通知先と利用目的を照合します。
書き出しや移行先での処理に使う接続なら、作業担当者と終了期限を指定して一時的に残します。
不要と判断できた接続は、OAuthの許可を取り消し、APIキーを失効させ、Webhookの通知先を削除または無効化します。
解除後は、残す業務の動作と両側の設定を確認し、解除対象・作業日時・担当者を記録します。
同じキーや通知先を別の処理でも使っている場合は、その処理を切り分けてから解除に進みます。用途を特定できない接続は、調査担当者と判断期限を決め、期限までに用途を確認します。製品ごとの確認場所の例として、Google Workspace では管理コンソールの「API の制御」で連携アプリとアクセス範囲を確認し、アプリをブロックできます（Google Workspace 管理者ヘルプ）。GitHub では、承認済みの OAuth アプリを一覧で確認し、取り消せます（GitHub Docs）。
SSO・SCIMと管理者アカウントの整理
認証やアカウント情報の連携は、残作業を終えられる管理経路を確保してから解除します。SSOは認証連携、SCIMはアカウント情報の連携であり、外部アプリへのアクセス許可とは分けて整理する対象です。
書き出し、削除依頼、証跡取得に管理者アクセスを使う場合は、「誰が、何のために、いつまで使うか」を先に決めます。管理者でしか実施できない作業が終わっていなければ、その作業に必要な範囲だけ経路を残し、完了後に連携とアカウントを整理する順序にします。
唯一の管理経路を、残作業の完了前に消してはいけません。SSOの解除や管理者アカウントの削除を予定する場合は、解除後も必要な操作を続けられるかが判断の分かれ目です。別の管理経路が利用できるなら接続を試したうえで切り替え、利用できなければ、必要な操作を終えてから解除します。代替経路を確認できない限り、SSOや管理者アカウントの解除は行いません。
SCIMについても、連携先のアカウントをどう扱うかを決めてから停止します。連携停止とアカウント整理を別々の完了項目にすると、停止しただけで削除まで済んだという取り違えを防げます。退職者アカウント削除の記事が扱うのは「人の利用終了」であり、ここで扱う「サービスの利用終了」とは、整理する範囲を分けて考えます。
DNS設定とダングリングレコードの処理
DNS設定は、解約したサービスを参照するレコードを洗い出し、参照先の利用継続の有無で削除・変更・引き継ぎを判断します。DNSはドメイン名の参照先などを管理する仕組みであり、SaaS側の契約手続きとは別に棚卸しする対象です。
CNAMEは別の名前への参照、NSは名前解決を担当するサーバーの指定です。これらを含む設定について、対象ドメイン、参照先、利用用途、管理担当者を一覧にします。解約したサービス名と一致する設定だけでなく、そのサービスで使っていたサブドメインからも照合します。
サービス利用終了後も残り、参照先がすでに使われていないDNSレコードを、ダングリングレコードと呼びます。ダングリングレコードの参照先の名前を第三者が登録・取得して利用できる状態になると、自社のサブドメインを第三者に使われる「サブドメイン乗っ取り」につながるおそれがあります。ただし、参照設定の残存だけで、乗っ取りや情報漏えいが発生したと断定はできません。
JPRSは2025年1月の注意喚起で、事業者のサービスを解約してWebサイトの公開を終える場合は、公開時に設定したDNS設定を削除・変更する必要があると呼びかけています。設定が残ったままのダングリングレコードは外部から検出でき、サブドメインテイクオーバーやNSテイクオーバーに使われる可能性があります。Microsoft も、サービスを停止するときのチェックリストに「DNSエントリの削除」を入れるよう案内しています（Microsoft Learn）。
行政でも例があります。総務大臣は2025年1月14日の記者会見で、令和2年の特別定額給付金の特設サイトに使っていたドメインが、閉鎖後に不正利用され得る状態だったと説明しました。外部からの情報提供で把握して対応しており、実際に不正利用された事実は把握していないとしています。
処理は、次の条件で分けます。
参照先を使う業務が残っていなければ、対象レコードを削除します。
移行先でも同じ名前を使うなら、新しい参照先へ変更し、意図した接続先になるかを確かめます。
別用途で利用を継続するなら、利用責任者へ設定と管理権限を引き継ぎます。
影響範囲を特定できない場合は、一括削除せず、DNS管理担当者と利用部門で依存関係を整理します。特にNSは、指定先が担当する範囲を把握してから変更する扱いにします。解除後の設定と引き継ぎ先を残せば、次の請求・アカウント再点検でも、未処理の接続と継続利用を区別できます。
▲ 解約直後に解除する外部連携の役割と対応操作の違いです。
解約後1〜3か月の請求・アカウント再点検
再点検では、請求・アカウント・再契約の有無を突き合わせ、削除期限が未到来の項目は追跡を続けます。再点検の時期は、契約ごとの終了日、事業者が示す削除予定日、最終請求の時期から決めます。契約上の削除期限が先にある項目は、次回確認日と担当者を残して管理を継続します。
社内の再点検では、経理・情シス・利用部門が持つ情報を同じ契約単位で照合します。
請求とアカウントの再点検
経理は請求書・支払履歴を契約終了日と照合し、情シスと利用部門は検出されたアカウントや契約の所属を確かめます。判断と引き継ぎは、次の順で整理すると迷いません。
経理は、支払いが見つかったら対象利用期間と対象契約を特定します。契約終了前の利用分なら、その根拠を記録して整理します。
契約終了後の継続契約が疑われる場合は、請求書と終了日の情報を添えて契約担当へ引き継ぎます。支払いの検出だけで誤請求とは断定しません。
情シスは残存アカウントと管理画面の状態を確認し、元の契約に紐付くものかを照合します。アカウントが見えるという理由だけで、契約継続や課金中とは判断しません。
利用部門は、別部署や個人による新しい契約・再契約の有無を確認します。元の契約の残存と識別できれば台帳を分け、識別できなければ契約者・支払元・利用目的を未確定事項として追跡します。
同じサービス名の支払いが再び見つかっても、解約済み契約の残存とは限りません。新しい契約なら別件として管理し、元の契約の後始末と混同しない運用にします。反対に、支払いが見つからないことだけを理由に、アカウントやデータの削除まで完了扱いにするのも避けます。
利用できる情報に応じた管理ツールの使いどころ
SaaS管理ツールを使う場合は、社内で取得できる情報の種類ごとに、再点検での使い方を次のように分けます。
利用できる情報 | 再点検での使い方 |
|---|---|
会計・支払データ | 把握していないサービスの利用を調べる手がかりにし、検出結果を契約終了日・対象利用期間と照合します。 |
アカウント連携による情報 | 一覧化できる範囲のアカウントを確認し、元の契約の残存か、新規契約に属するものかを利用部門に照会します。 |
登録した契約情報 | 終了日や次回確認日を追跡します。リマインダーを利用できる場合は、未確定事項の再確認に使います。 |
マネーフォワード Admina では、会計・支払データから社内で使われているSaaSを検出できるため、解約したはずのSaaSへの支払いが続いていないかを確かめる手がかりになります。380以上のSaaSとの連携でアカウントを一覧にでき、未登録のSaaSの検出や、契約情報の登録とリマインダーにも対応しています。実際の画面はデモで確認できます。
ツールによる検出は調査の入口として扱い、データ削除、DNS削除、連携解除、削除証明書の取得が済んだ証拠には置き換えません。再点検後も未確定事項が残るなら、担当者と次回確認日を決めて引き継ぎ、確認の結果に応じて完了・継続追跡・別契約への分離を判断します。
後始末台帳の項目と完了条件
後始末台帳は、解約日だけでなく、削除予定日・連携解除・DNS設定・確認者を記録して管理します。SaaS解約後の作業を引き継ぐ場合は、サービスごとに次の7項目を設け、記入内容と完了の根拠を対応させます。
必須項目 | 記入内容 | 完了と判断する根拠 |
|---|---|---|
SaaS名 | サービス名・契約を識別する情報 | 解約対象と契約情報が一致 |
解約日 | 申請日ではなく契約終了日 | 解約受付通知などで終了日を確認 |
データ削除の予定日 | 予定日・対象データ・実施状況 | 提供元の完了回答などで対象と実施を確認 |
削除証明書の有無 | 発行可否・依頼状況・保管先 | 発行される場合は受領。発行されない場合は代替の完了回答を保存 |
DNS設定の解除 | ドメイン名の参照先などを定める設定のうち、解除対象と対応状況 | 対象設定の解除後の記録 |
連携の解除 | 接続先・認証情報・解除状況 | 対象の接続・権限を解除した記録 |
確認者 | 根拠を確認した人の氏名 | 確認対象と確認結果の記録 |
引き継ぎがある場合は、担当者、最終請求確認、確認日、証跡の保管先、次回確認日も追加します。証跡とは、受付通知や設定画面など、実施内容を裏付ける記録です。担当者は作業を進める人、確認者は根拠を確かめる人として分けて記入します。
状態は「予定」「依頼」「完了」「未確認」を使い分けます。実施日を決めた段階は「予定」、提供元などへ対応を求めた段階は「依頼」、根拠を確認した段階で「完了」とします。削除予定日を過ぎても実施根拠がなければ「未確認」に変更し、次回確認日を設定します。DNSや連携が対象外なら「設定なし」などの理由を添えて「対象外」と記録します。空欄や予定日だけを完了扱いにしてはいけません。
時期別チェックリストは、以下をそのまま転記して使えます。各行の担当・状態・証跡欄を埋め、未完了の行には次回確認日を追記します。
時期 | 確認項目 | 担当欄 | 状態欄 | 証跡欄 |
|---|---|---|---|---|
解約前 | 必要データの出力と内容確認 | 記入：＿＿ | 記入：＿＿ | 出力先・確認記録：＿＿ |
解約前 | 解約日・データ取得期限・削除予定日の整理 | 記入：＿＿ | 記入：＿＿ | 契約条件・回答：＿＿ |
解約前 | 削除証明書の発行可否と代替証跡の整理 | 記入：＿＿ | 記入：＿＿ | 提供元の回答：＿＿ |
解約前 | DNS・連携・アカウントの解除対象の整理 | 記入：＿＿ | 記入：＿＿ | 対象一覧：＿＿ |
解約直後 | 解約受付と契約終了日の照合 | 記入：＿＿ | 記入：＿＿ | 受付通知：＿＿ |
解約直後 | 連携・認証情報・不要アカウントの解除 | 記入：＿＿ | 記入：＿＿ | 解除記録：＿＿ |
解約直後 | 対象のDNS設定の解除 | 記入：＿＿ | 記入：＿＿ | 設定変更記録：＿＿ |
解約後1〜3か月 | 最終請求と継続課金の有無の照合 | 記入：＿＿ | 記入：＿＿ | 請求明細：＿＿ |
解約後1〜3か月 | 残存アカウント・連携・DNSの再点検 | 記入：＿＿ | 記入：＿＿ | 再点検記録：＿＿ |
解約後1〜3か月 | 削除実施根拠の回収と未完了事項の引き継ぎ | 記入：＿＿ | 記入：＿＿ | 完了回答・次回確認日：＿＿ |
根拠がそろった項目だけを完了にすれば、後任者も残作業を判別できます。解約予告期限そのものの管理は、SaaS契約管理の記事で扱っています。
上表の台帳とチェックリストは、そのまま転記して運用できます。サービス終了以外の点検範囲は、サイバーセキュリティチェックリストの記事で確認できます。
まとめ
解約後は、解約手続きとデータ削除を区別し、台帳と証跡で完了を判断します。解約前のデータ確保は利用部門、解約直後の連携解除は情シス、後日の再点検は請求を経理、アカウントを情シスが担う形で、3段階の担当を決めます。
全社棚卸しを待たず、直近に解約したサービスの解約日・削除予定日・確認者を台帳へ記入するところから始めます。未確認項目には担当者と次回確認日を付け、証跡で完了を確かめられれば完了扱いとし、確かめられなければ未完了として残します。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
