顧客データ消去リクエスト 保留期間が「10 日 → 5 日」に短縮

図解 ： 顧客データ消去リクエストの保留期間が 10 日から 5 日に短縮 Developer Changelog / 顧客データ・プライバシー 顧客データ消去リクエスト 保留期間が「10 日 → 5 日」に短縮 2026 年 11 月 10 日以降、顧客データの消去リクエストはリクエスト送信から 5 日後に処理される。顧客の直近の注文日には左右されない。例外は「送信予約済みギフトカードの受取人」だけ。 このページの構成 そもそも何が変わるのか（30秒で理解） タイムライン図解 ： リクエストから処理まで 唯一の例外 ： 送信予約済みギフトカード 変更前 vs 変更後の比較 記事に書かれていること／書かれていないこと 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか 顧客データの消去リクエストは、これまで 10 日間「保留（pending）」状態 に置かれていた。 2026 年 11 月 10 日からは リクエスト送信の 5 日後に処理 される。顧客が最後に注文した時期は関係ない。 期間 ： 5 日 リクエストが送信された日から数えて 5 日後に処理。 直近注文日は無関係 「顧客の最新注文がいつだったか」に関わらず、一律 5 日。 例外はギフトカード受取人 送信予約済みのギフトカードが届くまでは保留のまま。 2 タイムライン図解 ： リクエストから処理まで 記事の表現は「 no longer be held in a pending state for 10 days 」→「 processed 5 days after the request was submitted, regardless of when the customer's most recent order was placed 」。 起点は リクエスト送信日 、条件として 直近注文日を見ない ことが明記されている。 3 唯一の例外 ： 送信予約済みギフトカード 対象は 「送信予約された（scheduled to send）ギフトカードの受取人」 。ギフトカードが配送されるまで消去リクエストは pending に留まる。配送後に何日で処理されるかは記事に記載なし。 4 変更前 vs 変更後の比較 項目 変更前 変更後（2026/11/10〜） 保留期間 10 日 pending 5 日 送信の 5 日後に処理 直近注文日の影響 記載なし（※記事は「今後は関係ない」と明記） 影響なし 注文時期に関わらず一律 予約済みギフトカード受取人 記載なし 例外 配送完了まで pending 狙い — 顧客データリクエスト管理の体験をシンプルにする マーチャント／開発者の作業 — 記載なし 5 記事に書かれていること／書かれていないこと 記載あり 明記されている事実 ・適用日 ： 2026 年 11 月 10 日 ・10 日の pending を廃止 ・送信から 5 日後に処理 ・直近注文日は無関係 ・予約済みギフトカード受取人は配送まで pending ・目的 ： 管理体験のシンプル化 記載なし 書かれていないこと ・API／Webhook の挙動や payload の変更 ・既に pending 中のリクエストの扱い ・管理画面 UI の変更 ・対象プラン／地域の制限 ・ギフトカード配送後の処理タイミング アプリ側への影響（消去通知を受けて自社 DB を消すタイミング等）は記事に記載なし。顧客データ消去に連動する処理を持つアプリは、実際の通知タイミングを開発ストアで確認しておくのが安全。 6 技術者が押さえるべき5つのポイント 1. 消去までのリードタイムが半分に 10 日 → 5 日。「消去前に顧客データを参照・退避する」前提の処理を組んでいるなら、使える猶予が短くなる。 2. 起点は「送信日」、注文日ではない 直近注文日に依存しなくなったので、処理予定日は「リクエスト送信日 + 5 日」で単純に見積もれる。 3. ギフトカード受取人は別扱い 送信予約済みギフトカードの受取人は、配送完了まで pending。「5 日で必ず消える」という前提でテストを書かない。 4. API／Webhook の変更点は記載なし 記事はタイミングの変更のみ。通知の形式や API の差分は書かれていないので、連携アプリは実機で挙動を確認する。 5. 社内ドキュメント・顧客向け説明を更新 プライバシーポリシーの説明文、CS 用 FAQ、運用手順書に「10 日」と書いているなら 「5 日（予約済みギフトカード受取人は配送後）」 に揃える。適用日は 2026 年 11 月 10 日。 7 業務に活かせる3つのユースケース USE CASE 1 連携アプリの「消去前データ退避」処理の見直し 課題 顧客データ消去の前に、集計や監査用の匿名化データを退避するバッチを 10 日の猶予を前提に週次で回している。 打ち手 バッチ頻度を猶予 5 日以内に収まる間隔に見直す。処理予定日を「送信日 + 5 日」で計算する。 効果 退避漏れを防ぎつつ、消去を遅らせる運用上のリスクを避けられる。 技術メモ 通知のタイミングや形式の変更は記事に記載なし。開発ストアで実際に消去リクエストを流して確認する。 USE CASE 2 ギフト需要が多いストアの CS 対応フロー整備 課題 年末・記念日向けに日時指定のギフトカード送信を多用するストアで、「消去を依頼したのにまだ残っている」という問い合わせが出る。 打ち手 CS 用 FAQ に「送信予約済みギフトカードの受取人は、配送完了まで消去が保留される」と明記する。 効果 問い合わせへの回答が統一され、プライバシー対応の信頼性が上がる。 技術メモ 配送後に処理されるまでの日数は記事に記載なし。FAQ では断定的な日数を書かない。 USE CASE 3 プライバシー関連ドキュメントの一斉更新 課題 運用マニュアル、アプリのプライバシー説明、クライアント向け保守ドキュメントに「消去は 10 日後」と書いたままになっている。 打ち手 「10 日」の記述を検索して洗い出し、「送信から 5 日後（2026/11/10〜）／予約済みギフトカード受取人は例外」に書き換える。 効果 顧客・クライアントへの説明と実際の挙動のズレがなくなる。 技術メモ 適用日の前後で説明を分けたい場合は、適用日 2026 年 11 月 10 日を明記する。 8 提案で使える1行サマリ 「顧客データの消去リクエストは、2026 年 11 月 10 日から 直近注文日に関係なく、送信の 5 日後に処理（従来は 10 日 pending）。 例外は送信予約済みギフトカードの受取人だけ。データ退避処理と説明文の『10 日』を見直そう。」 source ： shopify.dev / changelog / updated-handling-of-customer-data-erasure-requests 元記事公開日 ： 2026-11-11（Shopify Developer Changelog）