TikTok ShopのDMはセラーセンターに閉じ込められている——3人チームがWebhookで受信するまでの話 — UnifyPort
そのチームは、ホーチミンシティで3人がコスメを販売するTikTok Shopの小さなショップだった。最初のライブセールで、1つのSKUを11分で完売した。ピーク時の同時視聴者数は400人、コメント欄は読みきれないほど流れ、リアルタイムで注文が入り続けた。配信が終わってセラーセンターを開くと、DMが140件待っていた。そのほとんどの12時間返信タイマーは、すでに2時間動いていた。
問題はすぐにわかった——人員の問題ではなく、「アクセス」の問題だ。3人いれば通常の問い合わせには十分対応できる。問題は、すべてのDMがTikTokセラーセンターという手動受信ボックスの中に閉じ込められており、チームがすでにWhatsAppやZaloで使っているサポートツールへメッセージを自動で流す方法がないことだった。別の画面を常に監視して、メッセージを手で書き写してから、セラーセンター内で返信するしかない。140件のDMを前に、その方法は限界だった。
問いはシンプルだった。TikTokのDMをプログラムからWebhookで受信できるか——WhatsAppメッセージを受信しているように？ 1日かけてあらゆる選択肢を調べた。結果、3つのルートが見つかった。
ルート1：セラーセンター手動受信ボックス
TikTokセラーセンターにはメッセージタブがある。購入者からのDMはすべてここに届き、閲覧も返信も完全にTikTokのインターフェース内で行う。APIもWebhookもエクスポート機能もない。担当者がそのタブを監視し、メッセージを手でCRMやスプレッドシートにコピーし、セラーセンターから返信する。
1日に10件程度の安定したインバウンドなら何とかなる。しかしライブセール後のメッセージの波には対応できない。最初の1件を読んでいる間にキューは20件増えている。しかもこれは、チームの残りの人間が使っているツールとは完全に切り離された別のアプリを専任で見張ることを意味する。
判定：少量なら何とかなる。ライブセールで量が増えると機能しない。
ルート2：TikTok公式開発者API / Shop Partner API
TikTok for DevelopersのコンソールでDMエンドポイントを探した。存在しない。TikTokの公式開発者APIはコンテンツ投稿のために作られている——動画投稿、公開アナリティクスの取得、クリエイティブ素材の管理。プライベートなDMは明確にスコープ外で、TikTokはプライバシー上の理由から第三方へのDMデータ提供をしないと明示している。
もう少し狭い別のルートもある。TikTok Shop Partner APIには、ショップコンテキスト内のメッセージ機能の一部へのアクセスが含まれている。しかし、TikTokの審査を経た認定Shop PartnerまたはSellerアカウントが必要で、対象市場も限定されている。このチームのアカウント——ベトナムで通常のTikTok Shop販売者登録を経て開いた小さなショップ——は要件を満たしていなかった。審査だけで数週間かかり、承認の保証もない。
判定：一般の開発者APIにDMアクセスはない。Shop Partnerルートはゲートがかかっており、ほとんどのアカウントは使えない。
ルート3：非公式インバウンドインターフェース
3つ目のルートは、TikTokのDMへのアプローチを根本から変える。開発者API（そもそもDMを公開するために設計されていない）を使うのではなく、非公式インバウンドインターフェースがアプリと同じようにアカウントレベルでTikTokに接続し、入ってきたDMをHTTPイベントに変換して、登録したWebhookサーバーにプッシュする。Partnerの審査も、対象市場の要件も、開発者コンソールの設定も不要。すでに持っているアカウントをそのまま使えばいい。
| ルート1：セラーセンター | ルート2：公式API | ルート3：非公式インバウンド | |
|---|---|---|---|
| 開始までの時間 | 即時 | 数週間（審査）、承認保証なし | 1日以内 |
| DM APIアクセス | なし（手動のみ） | 一般アカウントは不可 | 完全なWebhook |
| 自動化 | 不可 | 不可 | 可能 |
| ライブセール規模に耐える | 不可 | — | 可能 |
| すべてのアカウントで使える | 可能 | 不可 | 可能 |
表を見れば答えは明らかだった。ルート2は閉まっている。ルート1は量に耐えられない。実際に機能するのはルート3だけだ。
ルート3の実際の姿
チームはUnifyPortを通じてTikTokアカウントを接続し、Webhookエンドポイントを登録し、signing_secretを設定した。以降、入ってくるTikTokのDMはすべて、正規化されたmessage.receivedイベントとしてバックエンドに届く:
{
"event": "message.received",
"account_id": "acct_tk_9Zp2",
"provider": "tiktok",
"from": "user_c14f8b",
"text": "こんにちは、昨日のライブでローズセットを買いました。いつ発送されますか？",
"timestamp": 1750060800,
"message_id": "tt_msg_c14f8b"
}バックエンドはHMAC-SHA256を使いWebhookエンドポイントのsigning_secretと照合して各配信を検証し、WhatsAppやZaloと同じサポートキューにメッセージを追加する:
app.post("/webhook", (req, res) => {
if (!verifySignature(req)) return res.sendStatus(401);
const evt = req.body;
if (evt.event === "message.received") {
supportQueue.add({
channel: evt.provider, // "tiktok"、"whatsapp"、"line" など
customer: evt.from,
text: evt.text,
messageId: evt.message_id,
});
}
res.sendStatus(200);
});providerフィールドがどのチャンネルからのメッセージかをルーティングロジックに伝える。キューのロジック、CRMへの書き込み、エージェントUI——何も変える必要がない。TikTokからのmessage.receivedイベントは、WhatsAppのものと構造が同じだからだ。TikTok専用のキューを作る必要はなかった。既存のキューにTikTokを追加しただけだ。LINEアカウントを追加する場合も、providerが"line"になるだけで同じハンドラーがそのまま使える。
変わったこと、変わらなかったこと
次のライブセールでは、TikTokのDMがWhatsAppやZaloのメッセージと一緒にキューに入った。エージェントは1つのリストだけを見て対応できた。12時間以内返信の指標——店舗の露出に影響するTikTokの公式評価基準——は心配の種ではなくなった。メッセージは送信から数秒でシステムに入るからだ。手動で記録するのを待つ必要がない。
チームが気づいたのは、ライブセール後のDMが短く密集していることだ。発送確認、在庫問い合わせ、注文内容の確認。それぞれのメッセージが届いたとき、送信者ID、テキスト、タイムスタンプがすでにパースされているので、エージェントはTikTokアプリからコピーする手間がない。メッセージは最初からサポートフローが期待する形式で届く。
新しいツールは導入しなかった。採用も増やさなかった。Webhookエンドポイント1つと署名シークレット1つで、TikTokのDMが他のチャンネルと同じように流れるようになった。TikTokとWhatsApp、LINEを同時に運用するセラーには、同じmessage.receivedイベントが届く——非公式インバウンドインターフェースがコードに到達する前にチャンネルの違いを吸収しているからだ。