チュートリアル May 25, 2026

TikTok Shopの12時間ルール：カスタマーサービスにイベント駆動アーキテクチャが必要な理由 — UnifyPort

TikTok Shopが静かに、しかし重要な政策変更を行いました。12時間以内のDM応答率が、ストアの健全性を評価する正式な指標になったのです。応答が遅すぎると、ストアの露出が下がります。ライブ配信中は、この基準がさらに厳しく、1時間以内に収められます。

これは些細な話ではありません。TikTok Shopの直近12ヶ月の流通総額は331億ドルに達しています。プラットフォームには19.9億人の月間アクティブユーザーがおり、1日あたり平均95分利用されています。ライブ配信でコンバージョンが発生すると、購入者はメールを送りません——DMを送ります。そして忘れる前に返事を期待しています。

問題は人手不足ではありません。アーキテクチャの問題です。

なぜライブ配信中に手動DM対応が破綻するのか

TikTokのライブ配信はバースト型イベントです。数分でトラフィックが急増し、購入がリアルタイムで発生し、続いて「注文できましたか」「サイズ変更できますか」「いつ発送されますか」という質問が、細い流れではなく一気に押し寄せます。

DMの受信トレイを手動で処理するチームは、安定した通常量なら対応できます。しかし配信者がライブを終えてから20分以内に数百件のメッセージが届く状況には対応できません。最初のメッセージを人間が読む頃には、すべてのメッセージの12時間カウントダウンがすでに始まっています。

解決策はライブ中にエージェントを増やすことではありません。イベントが届いた瞬間に応答するシステムを構築することです。

TikTok DMは受信トレイのアイテムではなく、イベントとして届く

ここに重要な思考の転換があります。ユーザーがTikTokであなたにDMを送ると、TikTokはあなたが受信トレイを確認するのを待ちません。登録したURLにHTTP通知——Webhookイベント——を送信します。あなたのシステムはそれをほぼリアルタイムで受信し、処理し、アクションを実行します。

つまりDMはポーリングで取得するものではなく、能動的に届いてパイプラインをトリガーするシグナルです。この違いが、イベント駆動カスタマーサービスアーキテクチャの基盤です。

運営担当者にとっての実際的な意味は、応答速度がDMタブを誰が何分おきに確認するかではなく、システムが受信イベントを処理する速度によって決まるということです——正しく設計されていれば、それは秒単位です。

開発者にとっては、イベントのペイロードにメッセージ内容、送信者ID、会話スレッドの参照、タイムスタンプが含まれています。バックエンドがルーティング、ログ記録、自動応答を行うために必要なすべてです。

イベントを中心にシステムを設計する

TikTok Shopのイベント駆動カスタマーサービスシステムは4つのステージで構成されます。

TikTokプラットフォーム
      ↓  （Webhookプッシュ）
イベント受信層
      ↓  （正規化 + 検証）
ルーティングエンジン
      ↓  （ルールベースまたはAI支援）
アクション層
 ├── 自動応答（注文状況、FAQ）
 ├── CRM書き込み（会話記録、連絡先タグ付け）
 └── エスカレーションキュー（人間エージェントへのフラグ）

イベント受信層は生のWebhookを受け取り、署名を検証し、ペイロードをダウンストリームに渡します。この層はブロックせずにバーストを処理します——即座に受信確認し、非同期で処理します。

正規化層はTikTokのイベント形式を一貫した内部構造に変換します。これは見た目以上に重要です。ライブ配信後に数千のイベントを処理する際、すべてのダウンストリームコンポーネントがイベントの発生元にかかわらず同じ構造で動作することが求められます。

ルーティングエンジンが次のアクションを決定します。シンプルなルールでほとんどのケースをカバーできます。注文番号を含むメッセージは履行ステータスを照会して自動返信、ネガティブな感情はエスカレート、新規連絡先からの最初のメッセージはCRMに書き込んでセールスキューに割り当て。

アクション層が実行します。自動応答はTikTokメッセージAPIを通じて送信され、CRMエントリが自動作成され、人間エージェントには生のDMではなく事前入力済みのチケットが表示されます。

結果として、ライブ配信後にバーストした300件のメッセージが、秒単位でルーティング、記録、初回応答まで完了します。12時間の窓はリスクではなくなります——ライブが終わる前にすべて処理されています。

マルチチャネルの問題

TikTok Shopは特定のオーディエンスに向いています。しかし、TikTokで相当な規模を持つほとんどのビジネスは、同時にカスタマーサポートでWhatsAppを使い、ベトナム市場向けにZaloを使い、タイの購入者向けにLINEを使っています。

各プラットフォームの受信メッセージ形式はそれぞれ異なります。WhatsAppには独自のイベントスキーマがあります。Zaloはまた別の形式です。ルーティングエンジンがTikTokの特定のペイロード形式に対して構築されているなら、同じ作業を4回繰り返すことになります。

よりクリーンなアプローチは、各プラットフォームのWebhookとルーティングエンジンの間に統一された受信イベント層を置くことです。バックエンドは4種類のイベント形式ではなく、1種類だけを扱います。TikTokからのmessage.receivedイベントは、WhatsAppからのmessage.receivedイベントと構造的に同一になります——同じフィールド、同じ型、同じルーティングロジック。

UnifyPortはこの問題を解決するために構築されています。TikTok、WhatsApp、Telegram、LINE、Zalo、Xからの受信イベントを受け取り、統一スキーマに正規化し、HMAC署名付きでWebhookエンドポイントに配信します。ルーティングエンジンが理解すべきイベント形式は1つだけです。

次のステップ

ここで説明したアーキテクチャは、量と一貫性の問題を解決します。しかし、TikTok Shop、さらには電子商取引全体の2026年の方向は、AIエージェントが人間の介入なしにすべての会話の最初の応答を処理することです。

イベント駆動システムがそれを可能にする前提条件です。DMが構造化された正規化済みイベントとして届く場合、AIエージェントはそれを読み取り、APIを呼び出して注文状況を確認し、今日のルールベースのルーターが使うのと同じパイプラインで返信できます。AIが解決できない場合にのみ、人間に引き渡されます。

TikTok Shopの12時間ポリシーは強制力です。マーチャントをリアルタイムでイベントに応答するシステムへと向かわせています——そして、そのインフラはAI支援トリアージ、統合マルチチャネル受信トレイ、エンゲージメントの高いプラットフォームのユーザーがすでに期待している顧客体験も支えています。

ボトルネックは人ではありません。常にアーキテクチャにあります。