ガイド July 13, 2026

TikTok Shop 4PL の住所マスキング規則: 注文 PII とサポート ID を分離する

**要点：**TikTok Shop が 2026 年 7 月 13 日に新しい 4PL マスキング規則を導入したわけではありません。現在の TikTok Shop Partner Center 公式ガイドは 2025 年 5 月 28 日公開で、2025 年 7 月 21 日までの実装を予定していました。米国のローカル・越境注文、Orders API 202309 以降では、recipient_address の表示可否は fulfillment type と order_status によって変わります。

重要なポイントは次のとおりです。

すべての 4PL 住所が常にマスクされるわけではなく、表示可否は order_status で変わります。
公式ガイドでは Seller Shipping（3PL）と TikTok Shipping（4PL）に同じステータス表が適用されます。
Fulfilled by TikTok（FBT）は、より多くの状態で住所フィールドをマスクします。
TikTok は、住所の表示ではなく order_status で出荷可否を判断するよう案内しています。

配送先の電話番号や住所は物流データであり、安定したサポート ID や help desk のルーティングキーではありません。注文 payload をカスタマーサポートの中心に置いているなら、次のフィールド変更前にレイヤーを分けるべきです。

米国の住所マスキング規則が実際に対象とするもの

公式ガイドは、米国のローカル・越境注文と Orders API 202309 以降を対象とします。3PL と 4PL では、UNPAID、ON_HOLD、CANCELLED、または COMPLETED から 30 日を超えた注文で、電話番号、氏名、詳細住所、住所行、配達設定、郵便番号、一部の地域情報がマスクされます。FBT はさらに厳格です。TikTok は 3PL・4PL の履約可否には影響しないと説明し、order_status に基づく出荷判断を推奨しています。

小規模チームでは、よく次のような形になります。

注文同期が届く
  -> 受取人の電話番号と住所を読む
  -> 過去のチケットやスプレッドシートと照合
  -> どの買い手が TikTok メッセージを送ったか推測
  -> サポート case をルーティング

これは、プラットフォームがフィールドをマスクする、買い手が別の電話番号を使う、同じ住所を家族で共有する、顧客が WhatsApp、LINE、Zalo に移って問い合わせを続ける、という瞬間に壊れます。サポートのタイムラインが切れるのは、ID モデルが物流データに置かれていて、会話データに置かれていないからです。

日本や東南アジアを含む越境チームでは、特にこの分離が重要です。TikTok Shop の注文は米国で履約され、最初の問い合わせは TikTok、追加確認は WhatsApp、国内オペレーションは LINE で進むことがあります。1 つの物流フィールドがマスクされたからといって、顧客タイムライン全体が見えなくなるべきではありません。関連情報は TikTok Shop DM webhook ガイドと LIVE room ID 連携の解説を参照してください。

3 つの ID を分ける

プラットフォームが受取人データをマスクしたとき、別の露出フィールドを探すのではなく、自分たちが使っている ID を名前で分けます。

ID	所属する場所	答えるべき質問
物流 ID	注文・履約システム	荷物はどこに行き、次の配送アクションは何か？
コマース ID	TikTok Shop、CRM、分析	どの注文、SKU、キャンペーン、LIVE ルーム、交換フローか？
サポート ID	インバウンドメッセージキュー	誰が、どのチャネルから、何を問い合わせたか？

これらの ID は後から結合できます。CRM は会話を注文に紐づけられます。倉庫ダッシュボードは履約例外の横に最近のサポートメモを表示できます。AI トリアージは、返品リクエストの前に買い手が何を聞いたかを要約できます。ただし、同じ主キーにすべきではありません。

物流 PII はサポート ID として特に弱いです。センシティブで、マスクされ、修正され、共有され、省略され、そもそも存在しないことがあります。会話イベントは違います。顧客が接触した瞬間に、チャネル、アカウント、会話、送信者、メッセージ、時刻を記録します。

インバウンドメッセージを署名付きキューへ

UnifyPort の標準 message.received イベントは、通常のメッセージングアカウントから非公式インターフェースでインバウンドメッセージを受け取り、1 つの正規化された webhook ストリームとして届けます。これにより、サポートシステムの記録は注文 payload の PII に依存しません。

まず webhook endpoint を作成します。

curl -X POST https://api.unifyport.ai/v1/webhook-endpoints \
  -H "X-Api-Key: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
  "url": "https://support.example.com/webhook",
  "status": "active",
  "subscribed_events": ["message.received"],
  "signing_secret": "<WEBHOOK_SIGNING_SECRET>"
}'

買い手からメッセージが届くと、受信側は標準イベント envelope を受け取ります。

{
  "id": "evt_20260713_tiktok_4pl_001",
  "type": "message.received",
  "provider": "tiktok",
  "account_id": "acc_tiktok_us_shop",
  "occurred_at": "2026-07-13T02:24:18Z",
  "data": {
    "conversation": { "id": "tt_conv_71942", "type": "user", "title": "Jordan Lee" },
    "sender": { "id": "tt_user_28491", "type": "user", "name": "Jordan Lee" },
    "message": {
      "id": "tt_msg_20260713_001",
      "type": "text",
      "text": "The tracking page says my exchange is delayed. Can someone check it?",
      "direction": "inbound",
      "sent_at": "2026-07-13T02:24:15Z"
    },
    "event": { "kind": "message_received" }
  }
}

endpoint に signing_secret がある場合、各 delivery には X-Device-Timestamp と X-Device-Signature が付きます。Webhook delivery と署名検証ガイドに従って解析前に検証し、イベント ID で重複排除し、まだ注文と一致しなくてもメッセージを保存します。

これが設計上の大きな変化です。インバウンドメッセージは、注文 payload に十分な PII があるから保存するのではなく、顧客が連絡してきたから保存します。

後から結合し、返信は明示する

イベントを保存したあとで、コマースシステムから文脈を補います。

TikTok Shop order sync
  -> order id、SKU、exchange status、logistics state

UnifyPort message.received webhook
  -> provider、account_id、conversation、sender、message、occurred_at

CRM or support backend
  -> 既知のアカウント対応、直近注文の時間枠、顧客が伝えた注文番号、または担当者レビューで結合

このモデルはマスキングに強いです。電話番号がなくてもチケットは残ります。住所が隠れてもメッセージはルーティングされます。同じ買い手が WhatsApp や LINE に移っても、provider が変わるだけで、同じ正規化形状のイベントとして届きます。

返信も明示的に保ちます。ワークフローが返信を決めたら、POST /v1/messages のテキスト送信ガイドに従って接続済みアカウントと宛先へ送信します。

curl -X POST https://api.unifyport.ai/v1/messages \
  -H "X-Api-Key: <YOUR_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
  "account_id": "acc_tiktok_us_shop",
  "to": { "id": "tt_user_28491", "type": "user" },
  "message": {
    "type": "text",
    "text": "We found the exchange delay and will update you here once the carrier scan refreshes."
  }
}'

注文システムは注文の仕事を続けます。サポートシステムは会話の仕事を続けます。物流フィールドのマスキングが、そのままカスタマーケアの障害にはなりません。

実装チェックリスト

受取人住所のマスキング規則を、短い監査として使いましょう。

注文同期ジョブで phone、address、recipient name を使った照合ロジックを探す。
履約に必要な結合と、サポート上の近道にすぎない結合を分ける。
サポート intake を署名付き message.received キューへ移す。
すべてのインバウンドイベントで id、provider、account_id、conversation、sender、message、occurred_at を保存する。
自動結合が弱いときは、会話内で注文番号を確認する。
返信は物流同期ジョブに隠さず、POST /v1/messages に集約する。

注文データが不要になるわけではありません。注文データには注文データの仕事があります。TikTok Shop が物流 payload のプライバシーを強めても、サポート運用は壊れないようにできます。

電話番号と住所のマスキングは、サポートには独自の source of truth が必要だという合図です。センシティブな注文フィールドは履約レイヤーへ。顧客メッセージは署名付きインバウンドキューへ。必要なときだけ結合すれば、プラットフォームが commerce payload を引き締めても、チームはサポートを作り直さずに済みます。

よくある質問

すべての 4PL 配送先住所がマスクされますか？

いいえ。米国の 3PL・4PL では表示可否が order_status によって変わります。FBT はより厳格なマスキングモデルです。

どの市場と API バージョンが対象ですか？

米国のローカル・越境注文と Orders API 202309 以降が対象です。

住所マスキングで履約できなくなりますか？

TikTok は 3PL・4PL の履約可否には影響しないと説明しています。住所の表示ではなく order_status で出荷を判断します。

受取人の電話番号を顧客 ID にできますか？

推奨しません。電話番号や住所はマスク、変更、共有、削除される可能性があります。インバウンドイベントの conversation と sender を保存し、信頼できる注文番号で後から関連付けます。

出典と次のステップ

TikTok Shop Partner Center: 米国市場の recipient_address マスキング規則。2025 年 5 月 28 日公開、2026 年 7 月 13 日確認。
UnifyPort: webhook endpoint の作成と Webhook 署名検証から始めてください。