カリフォルニアの一括削除「DROP」が稼働——B2B SaaSのID・データ設計を“削除起点”に作り替えるときです

今日の深掘りポイント

• Delete Act（SB 362）に基づく州の一括削除メカニズム（通称DROP）が始動し、カリフォルニア州民は登録データブローカーに対して一括削除要求を送れるようになりました。これは「個別のデータ売買主体」に直接ぶつける仕組みで、B2B SaaSには間接的に強い設計変更プレッシャーを与えます。
• 「SSOがあるから大丈夫」では届きません。SCIMは社内のユーザーライフサイクル自動化に有効ですが、消費者の削除権（DSR/DSAR）への応答には、ID検証・データ所在把握・証跡発行・第三者連鎖削除を含む“削除駆動”のデータ面アーキテクチャが必要です。
• 域外適用・国際整合の観点では、GDPRの消去権や各州法と整合する「一括削除」実装が、実務標準へ昇格する公算が高いです。短期は運用負荷が上がりますが、中期は自動化・監査性が競争力になります。

はじめに

2026年1月1日、カリフォルニア州の一括削除プラットフォーム（通称DROP）が稼働し、州民が登録データブローカーに対して個人データの一括削除を要求できるようになりました。Delete Act（SB 362, 2023）で予定されていた“ワンストップ・デリート”の実装が現実化した格好です。B2Cのデータブローカーに直接の義務が課される一方で、B2B SaaSは「顧客企業が受け取るデータ主体削除要求を、サービスプロバイダとして実現・証跡化する能力」を問われます。IDライフサイクル、SSO/SCIM、データモデル、ロギング——それぞれの“削除対応能力”が今後の選定基準になります。

本稿では法令の事実関係を押さえつつ、現場での設計・運用の作り替えポイントを深掘りします。なお、プラットフォーム開始日は外部報道に依拠し、法令本文は一次情報を確認のうえ言及します。

深掘り詳細

事実関係——Delete ActとDROPの位置づけ（一次情報の確認）

• Delete Act（SB 362, 2023）
  • カリフォルニア州は「データブローカー」制度を再設計し、消費者が登録データブローカーに対して“一括で”削除要求を行える仕組みの創設を規定しました。州のプライバシー機関（CPPA）が2026年までに当該メカニズムを整備することが定められています。California SB 362（Delete Act）法文 を一次情報として参照ください。
  • 「データブローカー」とは、消費者と直接の関係を持たない第三者に対して、個人情報を販売する事業を指す定義が採用されています（従前のデータブローカー法制を継承）。定義の根幹は法文側にあるため、該当性の見直しは必須です。
• CCPA/CPRAの削除権との関係
  • CCPA/CPRAは従前から消費者の削除権を定めていますが、Delete Actはその「実装のしやすさ」を押し上げる制度設計と言えます。CCPAの削除権は民法典に規定され、事業者の応答義務や第三者共有先への通知義務等が規定されています（参考：GDPRの消去権と議論の近接性も後述）。CCPA本体の条文は民法典（California Civil Code）にありますが、本稿では法令の一次情報性を担保するため、GDPRの比較のみを直接参照します。
• 稼働時期・運用の位置づけ
  • プラットフォーム開始については業界報道が1月1日の稼働を伝えていますが、行政当局の実装・運用要件（例えば照会頻度、応答期限、罰則計算方法など）は規則・実務ガイダンスで精緻化されるのが通例です。開始に関する報道は外部二次情報ですので、一次情報である法文に照らして「2026年に一括削除メカニズムが稼働する」という枠組みを前提に読み解くのが安全です。業界報道（Security Boulevard） も併せて参照ください。
• 国際比較の座標軸
  • GDPRの「消去権（Right to erasure, Art. 17）」は、法的根拠の欠如、撤回、不要化等の条件で削除義務を定め、第三者への通知努力義務（拡散先の抑止）を含みます。Delete Actの一括削除と思想の方向性は近く、今後の整合設計でGDPRとの共通解がレールになります。GDPR Art. 17（EUR-Lex） を参照ください。

ここまでが一次情報に基づく事実関係です。数字（登録件数など）は日々更新されるため、本稿では「報道によれば」という留保を付します。

インサイト——IDとデータを“削除駆動”で再設計する

• 「削除」はユースケースではなく“制約条件”
  • これまでは「ユーザー作成→権限付与→利用→退会」の後ろ側に削除が位置づけられがちでした。DROPはこの順序を逆転させ、「いつ削除要求が来ても、本人性を検証し、データ所在を解決し、各保存形態に応じた削除・マスキングを実行し、かつ可監査に証明できること」を、平時から満たすアーキテクチャを要求します。言い換えると、削除はアーキテクチャの制約条件であり、後付け機能では成立しません。
• SSO/SCIMの到達点と限界
  • SCIM（IETF RFC 7643/7644）は、組織内アカウントのライフサイクル自動化に強力です。一方で、消費者DSRの削除は「アカウント削除」だけでは終わらず、アカウント非依存のログ、バックアップ、キャッシュ、派生データ（特徴量、モデルの学習データへの混入の可能性）まで射程に入ります。SSO/SCIMは必要条件ですが、十分条件ではありません。RFC 7643、RFC 7644 を仕様の一次情報として参照ください。
• 本人性検証（VCR：Verified Consumer Request）の重心移動
  • 一括削除は利便と同時に、なりすまし削除のリスクを持ち込みます。NISTのデジタルIDガイドライン（SP 800-63-3）が示す「I AL/A AL（本人確認）とA AL（認証）レベル」を踏まえ、DSRフローに過不足のない検証を組み込むのが現実解です。たとえばAAL2相当の要素（二要素＋継続的リスク判定）をDSR承認直前に要求する、といった運用の設計が効きます。NIST SP 800-63-3 を参照ください。

実務論——“削除駆動”アーキの最小構成

• データ所在の即時解決
  • データカタログ（スキーマ、保存場所、保持期間、暗号化状態）、個人識別キーの解決（email/電話/端末ID/CRM IDの突合）、第三者共有先一覧（サブプロセッサ、分析基盤、バックアップ保管庫）を常時同期し、削除要求時にクエリ1回で網羅できるようにします。
• 実行と検証の分離
  • 削除オーケストレータは「実行」と「検証（後続スキャンや監査照合）」を分離し、レース条件や遅延副作用（ストリーミング基盤やCDC経由の遅延反映）を吸収します。監査観点では「削除発行→受領→完了→残存検知→再試行」の各ステータスを不変ログで保存します。
• 証跡の標準化
  • 顧客・当局向けに、削除要求の受付、本人性検証結果、処理対象システム一覧、完了タイムスタンプ、未削除の正当理由（法的保持・監査留保など）を含む“Deletion Receipt”を発行します。のちの紛争時にここが生命線になります。
• バックアップ・ML・派生物の扱い
  • 直近のバックアップからの復元時に削除データが再出現しないよう、復元後の再削除ジョブを自動投入するか、バックアップを不可逆暗号化し短期保有へ倒す運用に寄せます。ML学習データは削除要求の適用対象かをデータ保護影響評価（DPIA）に明記し、適用時の再学習ポリシーを事前に決めておきます。

リスク管理——濫用・過剰削除・サプライチェーン

• なりすまし削除
  • 高リスクシナリオは「第三者が標的のデータを消す」ケースです。本人性検証の強化、チャネル拘束（既存認証済チャネルへ確認）、異常スコアリング（新規端末・高頻度・TOR経由）で抑え込みます。削除前の「冷却期間＋通知」も有効です。
• 過剰削除の誤爆
  • マスターキーの誤紐付けで他者データを巻き込む事故が起こり得ます。データセット単位のドライラン（影響件数の事前見積もり）とサンプル検証、ロールバック手順（不可逆化の前段に論理削除層を挟む）が効きます。
• サプライチェーン遅延
  • サブプロセッサでの削除遅延がボトルネック化します。DPAにSLAと監査権限、削除証跡のフォーマットを明記して、連鎖削除の実働性を契約で確保します。

将来の影響と国際的含意

• 実務標準の国際化
  • GDPRの消去権とDelete Actの“一括削除”は相互に参照される関係にあり、B2B SaaSにとって「DSR API」「削除証跡」「連鎖削除SLA」は業界標準の三点セットになる可能性が高いです。米州・欧州・アジアでの要件差を「最小公倍数」仕様として先に実装した企業が、監査容易性と見積り明快さで優位に立ちます。
• 域外適用と選定基準の変化
  • 「カリフォルニア居住者を含むか」「データブローカー定義に接近していないか」を、海外SaaS選定の一次判定に組み込む動きが広がるはずです。日本発SaaSにとっては、米州顧客への説明責任を満たす“デリート・アーキテクチャ”の平時整備が輸出競争力に直結します。
• コスト構造の再編
  • 短期的にはDSR対応の人件費・再設計コストが跳ねますが、中期的には自動化・観測性・監査容易性がサブスクリプション継続率や大型顧客の獲得に寄与します。編集部の見立てでは、ここを“コスト”ではなく“売れる条件”として経営合意を取りに行くのが勝ち筋です。

セキュリティ担当者のアクション

• 30日以内
  • 自社のデータフロー台帳を更新し、個人識別子の解決マップ（IDグラフ）を作る。サブプロセッサ一覧に「削除SLA」「証跡提供可否」を追記する。
  • 現行のDSRハンドリングを棚卸しし、「本人性検証の強度」「削除の適用範囲（ログ・バックアップ・ML）」「証跡の網羅性」をギャップ分析する。
• 60日以内
  • 削除オーケストレータのMVPを構築。受付→本人性検証（NIST 800-63-3のAAL2相当を目安）→実行→検証→証跡発行を一気通貫にする。
  • SCIMは継続強化しつつ、DSR用の“消費者向け”API/ワークフローを別ラインで用意する。SSO/SCIMだけではDSR要件を充足しない前提で設計する。
• 90日以内
  • 顧客企業向けに「削除実装ホワイトペーパー」と「Deletion Receipt」のサンプルを提示し、監査時の問合せ負荷を先回りで下げる。
  • サブプロセッサと削除証跡の標準フォーマットを取り決め、四半期ごとの実地演習（Tabletop + サンプルデータの実削除リハーサル）を行う。
• 運用SLO/メトリクス（社内合意用の例）
  • 受領から削除完了までの中央値・P95、再試行率、第三者への伝播遅延、誤検知率（なりすまし検知での誤拒否/誤許可）を可視化し、四半期で改善を回す。
  • 監査適合性：削除証跡の完全率、正当な例外（法的保持）率、バックアップ再出現のゼロ化達成期間をモニタリングする。

参考情報

• California SB 362（Delete Act, 2023）法文（一次情報）: https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202320240SB362
• GDPR（Regulation (EU) 2016/679）公式公報（一次情報）: https://eur-lex.europa.eu/eli/reg/2016/679/oj
• SCIM Core Schema（IETF RFC 7643, 一次情報）: https://datatracker.ietf.org/doc/html/rfc7643
• SCIM Protocol（IETF RFC 7644, 一次情報）: https://datatracker.ietf.org/doc/html/rfc7644
• NIST Digital Identity Guidelines（SP 800-63-3, 一次情報）: https://pages.nist.gov/800-63-3/
• 業界報道（プラットフォーム開始の二次情報）: https://securityboulevard.com/2026/01/californias-drop-platform-launches-what-enterprise-b2b-saas-companies-need-to-know-about-data-deletion-compliance/

編集後記

• 「削除」は痛みを伴う機能ですが、DROPは“痛みを設計に内在化する”機会でもあります。削除を後ろに追いやらず、最前列に置く。そうすることで、プロダクトの信頼性はむしろ強くなります。今日の設計変更は、明日の提案資料で最初に語れる競争力になります。次の四半期のレビューで、その一歩を確認できるようにしておきたいですね。