ガイド June 26, 2026

X が 2026 年に自動 DM を禁止——受信専門のサポートチームが今も DM を受け取り、振り分ける方法 — UnifyPort

X でカスタマーサポートやコミュニティ運用をしているなら、2026 年のルール変更は不穏な件名とともに受信トレイに届いたはずです。自動 DM——誰かがフォローした瞬間に飛ぶ、あの「フォローありがとうございます、製品をぜひ」というメッセージ——は明確に禁止されました。自動化による一斉 DM、面識のない相手へのコールド DM もすべて不可。DM エンドポイントをマーケティング目的でプログラム的に使えば、API アクセスそのものを失う可能性があります。さらに 2026 年 2 月に従量課金へ切り替わり、DM を 1 通読むだけで課金対象のリクエストになりました。小さなチームにとって結論は身も蓋もありません——X でのアウトバウンド自動化は、いまや制限されたうえに有料です。

ただ、パニックの中で見落とされがちな点があります。あなたのチームが X を使ってメッセージを受信しているなら——注文の問い合わせ、サポートチケット、人の返信が必要なメンション——2026 年の締め付けはほとんど一つもあなたに向いていません。新ルールが狙うのは、ごく特定の行為だけです。すなわち、許可のない、自動化された、大規模なアウトバウンド DM。相手が意図的に送ってきたメッセージを受け取り、素早く人の手に渡すことは、別の問題であり、答えも違います。

実際に何が変わったのか

「X が DM 自動化を取り締まる」という見出しは、ルールそのものよりずっと広いので、新ルールを正確に押さえておきましょう。

禁止された行為は、本質的にすべて許可のないアウトバウンドです。フォロー起点の自動 DM、一斉 DM キャンペーン、先に連絡してきていない相手へのコールド DM、そしてマーケティング目的で自動送信されるあらゆる DM。X はデータ取り扱いの文言も厳しくしました——サービスは非公開の DM コンテンツを保存する前に明示的かつ説明を受けたうえでの同意を得なければならず、閲覧権限のない人に DM コンテンツを見せてはなりません。

料金面では、無料 API ティアが 2026 年 2 月に新規開発者向けに閉じられ、それ以外は従量課金へ移りました。公開後にレートは何度か変動しましたが、重要なのは構造です——どの読み取りも 1 リクエストであり、どのリクエストにも値段がつく。ポーリングで DM を監視するチーム——30 秒ごとに API を叩いて新着があるか確認する——にとって、これは止まらないメーターを意味します。その間に 10 件来ようと、1 件も来なかろうと、関係なく回り続けます。

つまりインバウンドのチームにとって、公式ルートはいまや無関係な 2 つのコストを抱えています。コンプライアンスコスト（高頻度のプログラム的アクセスは自動化ルールの下で精査される）と従量コスト（ポーリングのたびに課金される）です。そしてこの 2 つはいずれも、顧客が実際に送ってくるメッセージとは何の関係もありません。

なぜ「受信」は別の問題なのか

サポートチームが実際にやっていることを捉え直してみましょう。顧客が DM で質問を送る。人がそれを読み、返信を打ち、送る。このアウトバウンドのメッセージに「自動化」の要素は一切ありません——人が書いたものです——だから自動 DM 禁止は単純に当てはまりません。本当に自動化が必要なのは、入ってきたメッセージを十分速くチームの手に届けること、SLA 内に返信できる速さで届けること、それだけです。

これはインバウンドの振り分け問題であって、アウトバウンドの自動化問題ではありません。そして最もきれいな解はポーリングの正反対です——あなたのサービスが X に「もう新着ある?」と繰り返し尋ねるのではなく、メッセージが届いた瞬間にあなたへプッシュされる。ポーリングループがなければ、止まらない読み取りメーターもなく、自動化ルールに引っかかる高頻度アクセスのパターンもありません。相手が送ってきたものを受け取り、人が返信する。最初から最後まで、許可のない DM を自分から発信することはありません。

一つの Webhook で X の DM とメンションを受け取る

UnifyPort はあなたの X アカウントを接続し、インバウンドの DM とメンションを発生した瞬間にあなた自身の Webhook エンドポイントへプッシュします。エンドポイントを一度登録し、関心のあるイベントを購読すれば、インバウンドの活動は正規化された message.received イベントとして届きます——これは WhatsApp、Telegram、LINE、TikTok、Zalo と同じ形です。日本では LINE が顧客接点の中心であることが多いので、X と LINE の両方を同じ message.received スキーマで受けられる点はとくに効いてきます。マルチチャネルのサポートデスクが、6 種類のプロバイダー形式ではなく一つのスキーマを読むだけで済むのです。

Webhook を作成するときは subscribed_events を列挙し（["*"] で全カタログ、あるいは message.received と account.status.updated を明示）、signing_secret を設定します。以降の各配信には HMAC-SHA256 署名が付き、ハンドラはボディを信頼する前にそれを検証します。届いた DM はこんな形です。

{
  "event": "message.received",
  "data": {
    "account_id": "acct_x_support",
    "provider": "twitter",
    "chat_id": "dm_8841f0",
    "sender": "user_3a91c7",
    "message": {
      "id": "x_msg_5f2a91",
      "type": "text",
      "text": "こんにちは——注文は発送されましたか? 追跡リンクが 404 になります",
      "reply_token": "rt_9b1c7e..."
    },
    "timestamp": 1750939200
  }
}

受信側はまず署名を検証し、それからメッセージをチームがトリアージする場所——Slack チャンネル、ヘルプデスク、データベース——へ振り分けます。

const crypto = require("crypto");

app.post("/webhook", express.raw({ type: "application/json" }), (req, res) => {
  const signature = req.get("X-UnifyPort-Signature");
  const expected = crypto
    .createHmac("sha256", process.env.SIGNING_SECRET)
    .update(req.body)
    .digest("hex");
  if (signature !== expected) return res.sendStatus(401);

  const { event, data } = JSON.parse(req.body);
  if (event === "message.received" && data.provider === "twitter") {
    routeToTriage({
      chatId: data.chat_id,
      from: data.sender,
      text: data.message.text,
      messageId: data.message.id,
    });
  }
  res.sendStatus(200);
});

このハンドラがしないことに注目してください——DM を一切送りません。受信し、検証し、振り分けるだけです。担当者が返信を書いたら、それは UnifyPort の正規化された送信エンドポイントを通じて「人が書いたメッセージ」として送られます——自動 DM でも一斉マーケティングでもありません。（X 固有の注意点が一つ：引用返信の reply_to.reply_token フィールドは現状 WhatsApp のみ対応なので、X では引用ではなく通常の返信を送ります。インバウンドイベント自体にはこのトークンが含まれ、対応プラットフォームで使えます。）

イベントはプッシュされ、取りこぼしはポーリングで補填されないため、チームはメッセージ送信から数秒以内にインバウンドの活動を目にします——多くの場合 30 秒のポーリング周期より速く、しかも誰も来ない静かな日に読み取りメーターが裏で空回りすることもありません。

実務上の次の一歩

2026 年の新ルールは明快な線を引きました——X は自動アウトバウンドの DM で人々の受信トレイをあふれさせたくない、そしてプログラム的な読み取りに課金する。インバウンドのサポートチームは完全にその線の正しい側にいます——返信はすべて人が書き、そもそも API をポーリングする理由がありません。顧客がいつ書き込んできたかを知るためだけに X に対してポーリングサービスを走らせているなら、プッシュ型の Webhook への切り替えは、コンプライアンスリスクと従量読み取りを一手で取り除きます。

X アカウントを統一インバウンド Webhook に接続し、署名を検証して chat_id で振り分けるエンドポイントを指し示せば、チームは新ルールが一度も制限しなかった唯一のこと——連絡してきた人に答えること——に戻れます。