TikTok には DM API が存在しない——それでもチームが TikTok Shop のメッセージを受信できている理由 — UnifyPort
カスタマーサポートの仕組みはすでに整っています。ライブ配信は売上につながり、購入者からは次々と DM が届く——「もう発送された?」「サイズはまだ変更できる?」。あなたはこれらのメッセージを自動的にシステムへ取り込み、購入者が興味を失う前にオペレーターや AI が返信できるようにしたい。そこで TikTok for Developers のコンソールを開き、受信メッセージ用の Webhook を登録しようとします。
ところが、そんなエンドポイントは存在しません。2026 年時点で、TikTok 公式の開発者 API は DM の送信も受信もできません——Content Posting API でも、Display API でも、汎用的な形でも一切です。TikTok は、プライバシーとセキュリティ上の理由から、DM データをサードパーティ連携に開放していないと明言しています。
プラットフォームは即レスを求めるのに、受信する手段をくれない
これは多くのチームの不意を突きます。TikTok Shop が、DM への素早い返信を実質的に必須にしたからです。12 時間以内の返信率は正式なストアヘルス指標であり、ライブ配信中はその期待が 1 時間以内にまで厳しくなります。プラットフォームは一方の手でリアルタイムの DM 対応へとあなたを押し出しながら、もう一方の手では、その DM を実際に受信するプログラム的な手段を開発者 API でまったく与えてくれません。
ごく狭い例外があり、ここは正確に書いておく価値があります。TikTok Shop の出品者・パートナー向けプラットフォームは一定のメッセージ機能を提供していますが、ゲートがかかっています。審査を通過した TikTok Shop の出品者またはパートナーのアカウントが、対象市場で、Shop API とその独自のオンボーディング・審査を経て使うものです。そこから外れる大量のアカウント——対象外の国の出品者、Shop を持たないクリエイター、クライアントの代理でアカウントを運用する代理店、あるいは普通の TikTok 受信箱をバックエンドにつなぎたいだけのチーム——には、いずれも使えません。汎用の開発者 API は DM とは無縁のままです。
結果として残るのは手作業です。誰かが TikTok アプリを開きっぱなしにし、メッセージを 1 件ずつ CRM に手入力する。これはライブ配信の波には耐えられません。質問はぽつぽつではなく一気に押し寄せますし、チームがすでに掛け持ちしている他のプラットフォームに横展開できるものでもありません。
視点を変える:探している API が違う
ここが肝心な発想の転換です。あなたを止めているのは「TikTok のメッセージ連携が難しい」ことではなく、公式の開発者 API——プライベートメッセージを開放するようには設計されていない API——の中にその機能を探していることです。あの API はコンテンツを公開し、公開分析データを読むためのもの。1 対 1 の DM を受信するのはまったく別の面であり、TikTok は意図的にそこを閉じています。
非公式のインバウンド接続は、アプリと同じように——普通のアカウントを通じて——TikTok につながり、届いた DM を 1 件ずつ HTTP イベントに変えてあなたのサーバーへ届けます。Shop 出品者の審査を勝ち取る必要も、対象市場の条件も、ビジネス認証も不要。いま手元にあるアカウントをそのまま使います。
メッセージは実際にどうやって届くのか
これこそ UnifyPort が埋めるために作られたギャップです。TikTok アカウントを一度つなげば、以降は届くすべての DM が、正規化された message.received イベントとして Webhook に到着します——UnifyPort が WhatsApp、Telegram、LINE、Zalo、X に対して配信するのとまったく同じイベント形です。公式の DM エンドポイントは不要。メッセージはアカウントの層でキャプチャされ、あなたへプッシュされるからです。
受信した TikTok のメッセージはこのようになります。
{
"event": "message.received",
"account_id": "acct_tk_4Lm9",
"provider": "tiktok",
"from": "user_3f9c1a",
"text": "こんにちは、配信で見た M サイズはまだ在庫ありますか?",
"timestamp": 1749340800,
"message_id": "tt_msg_3f9c1a"
}
tiktok を whatsapp に変えても構造はまったく同じ——同じフィールド、同じ型です。日本で主流の LINE のインバウンドをすでにルーティングしているなら、TikTok のハンドラはすでに書いたコードそのものです。各 Webhook エンドポイントには signing_secret を持たせられるので、すべての配信が HMAC-SHA256 で署名され、サーバー側で正当性を検証できます。各エンドポイントでは message.received だけ(あるいはすべてを受け取る ["*"])を購読すれば十分です。
この正規化こそが、12 時間ルールを乗り切れるものにします。ライブ配信の波は、構造の揃ったイベントの連なりになります——キューが吸収し、AI レイヤーがトリアージし、オペレーターが内容の入ったチケットとして引き継ぐ。誰かがアプリを更新し続けて取りこぼさないよう祈る、という運用とは違います。
まずどこから
TikTok が DM API を出すのを待っているなら、正直に言えば、公式の開発者 API はそれを与えるようには作られておらず、Shop のメッセージ経路は大多数のアカウントに閉じられています。いま TikTok の DM をプログラムで受信するには、アカウントを非公式のインバウンド接続でつなぎ、メッセージをイベントとして向こうから届かせることです。
すでに他のチャネルを運用しているなら——TikTok Shop の 12 時間ルールとイベント駆動カスタマーサービス、LINE・Zalo・X を 1 つの Webhook で、あるいは公式 API を使わない WhatsApp インバウンド受信——TikTok は同じ Webhook に加わるだけです。TikTok アカウントを 1 つつなぎ、signing_secret 付きの Webhook を登録し、message.received を購読して、自分宛てにテスト DM を送ってみてください。他のどのチャネルとも同じ形でバックエンドに届くのが見えるはずです。