← 全記事
ガイド

WhatsAppのBSUID移行が7月7日に開始 — インバウンド専用チームのための5項目チェックリスト — UnifyPort

MetaがWhatsApp APIにおけるユーザー識別の仕組みを変更します。2026年7月7日（Wave 1）から、Business-Scoped User ID（BSUID）という新しいフィールドがすべてのWebhookペイロードに追加され、WhatsAppユーザーネームを設定したユーザーについては、電話番号がペイロードに含まれなくなる可能性があります。

サポート対応、CRM連携、AIエージェントのパイプラインなど、何らかの形でWhatsAppメッセージを受信しているチームにとって、今回の移行はコードに影響します。どの程度の影響があるかは、WhatsAppメッセージがバックエンドに届くまでにどの経路を通るかによって決まります。

この記事はチェックリストです。監査すべき5つの領域、1つの判断マトリクス、そして多くの少人数チームが実際に抱えている疑問「7月7日までに何かやる必要があるのか？」への明確な回答をまとめています。

BSUIDとは何か

すべてのWhatsAppユーザーに新しい識別子が割り当てられます。Business-Scoped User IDです。フォーマットは、2文字の国コード、ドット、最大128文字の英数字 — たとえば BR.1A2B3C4D5E6F7G8H9I0J のような形式です。最も重要な特性は、同じユーザーでもやり取りするビジネスごとに異なるBSUIDが生成されるという点です。あなたのサービスにおけるユーザーAさんのBSUIDは、別の会社におけるAさんのBSUIDとは異なります。

Metaのロールアウトスケジュール：

Wave日付対象範囲
Wave 12026年7月7日初期対象市場
Wave 22026年7月20日拡大ロールアウト
グローバル2026年9月残りの全市場

BSUIDは2026年3月31日から新しい user_id フィールドとしてWebhookペイロードに出現し始めています。しかし、破壊的変更が起きるのはWave 1以降です。ユーザーがWhatsAppユーザーネームを設定すると、wa_id や from フィールドに電話番号が含まれなくなる可能性があります。

チェックリスト：監査すべき5つの領域

1. Webhookペイロードのパース処理

何が変わるか： すべてのメッセージWebhookに新しい user_id フィールドが追加されます。ユーザーネームを有効にしたユーザーの場合、これまで電話番号が入っていた wa_id と from フィールドにBSUIDが入るか、フィールド自体が存在しなくなります。

確認すべきこと： Webhookハンドラーが from を常に電話番号だと想定していませんか？ 数字の正規表現でマッチさせている、データベースキーとして使用している、電話番号バリデーションライブラリに渡しているなどのケースは、from に 5511999887766 ではなく BR.1A2B3C4D5E... が入った時点で壊れます。

2. CRM・顧客マッチング

何が変わるか： CRMが電話番号をキーに顧客レコードを管理している場合、ユーザーネームを設定したユーザーからのメッセージに電話番号が一切含まれないことがあります。顧客の特定ができなくなります。

確認すべきこと： 顧客データベースは電話番号に加えてBSUIDでの保存・照合に対応できますか？ MetaはContact Book APIを提供しており、過去の会話から電話番号とBSUIDの対応関係を保持できます。ただし、新しいWebhookから電話番号が消える前に呼び出しておく必要があります。

3. 会話履歴とスレッド管理

何が変わるか： 電話番号で会話をスレッド化している場合（例：「+5511999887766からの全メッセージを表示」）、同じユーザーのメッセージがBSUID識別子で届くようになります。過去の電話番号ベースのレコードと新しいBSUIDを紐づけない限り、会話履歴が二つに分断されます。

確認すべきこと： メッセージストアが会話スレッドの主キーとして電話番号を使用していませんか？ もしそうなら、Wave 1の前にバックフィルを計画してください。Contact Bookのマッピングを使って、既存の電話番号ベースのレコードをBSUIDに紐づけます。

4. テンプレートメッセージ・アウトバウンド送信

何が変わるか： テンプレートメッセージ（アウトバウンド）を送信する際、最終的には電話番号ではなくBSUIDで宛先を指定する必要があります。特に、ユーザーネームを設定して電話番号が公開されなくなったユーザーに対しては必須です。

確認すべきこと： 注文確認、配送通知、予約リマインダーなどのプロアクティブメッセージを送信していますか？ 送信ロジックが電話番号で宛先を解決しているなら、直近のインバウンドメッセージからBSUIDを保存し、今後のアウトバウンド送信に使用する必要があります。

5. データ保管とコンプライアンス

何が変わるか： BSUIDは新たな個人識別情報です。ビジネスごとにスコープされているため（企業間でのユーザー照合には使えない）、範囲は限定的ですが、ほとんどのプライバシーフレームワークではPIIとして扱われます。

確認すべきこと： データ保持ポリシーは新しい識別子タイプをカバーしていますか？ GDPR、日本の個人情報保護法、またはAPEC CBPRに基づく削除フローで、ユーザーに紐づく全識別子を列挙している場合、BSUIDも含める必要があります。

どの経路を使っていますか？

5つのチェックリスト項目すべてに対応が必要なわけではありません。WhatsAppメッセージがバックエンドに届くまでの経路によって異なります。

連携経路該当するチェック項目移行の負荷
Cloud API（直接接続）全5項目高 — MetaのWebhookを直接パースしているため、ペイロードの変更がすべてコードに影響
BSP（Wati、360dialogなど）項目2, 3, 4, 5中 — BSPがWebhookフォーマットを抽象化している場合もあるが、CRMと送信ロジックの更新は必要
非公式インバウンドインターフェースなしゼロ — 続きをお読みください

非公式インバウンドが影響を受けない理由

WhatsAppメッセージをUnifyPortの非公式インターフェース経由で受信している場合、BSUID移行はパイプラインに一切影響しません。理由はシンプルです。UnifyPortはMetaのCloud API経由でメッセージをルーティングしていないからです。非公式経路はWhatsAppに直接接続します — スマートフォンでWhatsAppを使うのと同じ仕組みです。そのため、Webhookで受信するメッセージは最初からCloud APIのペイロード形式ではありません。

日本市場でLINEとWhatsAppを併用しているチームにとって、この点は特に重要です。UnifyPortは6つのチャネル（WhatsApp、Telegram、LINE、TikTok、Zalo、X）すべてを同一の正規化Webhook形式で配信するため、WhatsApp側でIDスキームが変わっても、LINEやその他チャネルのハンドラーに一切影響がありません。

Webhookには今まで通り同じ message.received イベントが届きます：

{
  "event": "message.received",
  "account_id": "acct_3qPmRz",
  "provider": "whatsapp",
  "from": "user_88c1ae",
  "text": "注文#2241の発送状況を教えてください",
  "timestamp": 1751875200,
  "message_id": "wa_msg_f4e29a"
}

from フィールドはUnifyPort独自の正規化ユーザー識別子であり、電話番号でもBSUIDでもありません。最初から電話番号ではなかったため、MetaがID体系を変更しても移行作業は発生しません。CRMマッチング、会話スレッド管理、Webhookパース処理のすべてが変更なしで動作し続けます。

WebhookエンドポイントのHMAC-SHA256署名検証も影響を受けません。署名シークレットと署名フォーマットはUnifyPortのものであり、Metaのものではないからです。

今週やるべきこと

Cloud APIまたはBSP経由で接続している場合：まずチェックリスト項目1（Webhookパース処理）から始めてください。受信Webhookのサンプルをログに記録し、user_id フィールドがすでに存在するか確認します — 3月31日からロールアウトが始まっています。フィールドが存在していれば、ペイロードはすでに変化し始めています。7月7日までに項目2〜5を完了させましょう。

非公式インバウンド経路を使用している場合：何も変わりません。BSUID移行はCloud APIの課題であり、あなたのメッセージはCloud APIを経由していません。引き続き開発を進めてください。