3日間で本番稼働：認証キューを待たずにWhatsApp受信メッセージを処理する — UnifyPort

2026年初頭、東南アジアの電子機器小売を運営する小さなオペレーションチームが、よくある行き詰まりに直面した。WhatsAppでのサポート問い合わせ量が手動のInboxで対応できる限界を超え、バックエンドシステムで受信メッセージを自動的に受け取ってルーティングする必要が生じていた。計画はシンプルだった。WhatsApp Business APIに接続し、インバウンドwebhookイベントを受信し、サポートのルーティングロジックに渡す。

Business Verificationを1月末に申請した。承認キューは3月まで伸びた。

問題は問い合わせ量ではなく、待機だった

待っている間も、サポートのInboxは手作業で積み上がり続けた。物流状況の確認、注文変更、在庫照会——買い手がWhatsAppで問い合わせてくるのは、それが彼らの慣れたコミュニケーション手段だからだ。メッセージは届いていた。対応する意欲のある人員も揃っていた。ボトルネックはアーキテクチャにあった。API権限が承認されるまで自動化は動かせないため、すべてのメッセージを人間が読んで答えるしかなかった。

2人のサポート担当者が、毎日約4時間をWhatsAppメッセージのトリアージに費やしていた。バックエンドへの問い合わせで数秒あれば答えられる注文ステータス照会、判断力を要しないFAQへの返信、数ルールで実装できるエスカレーションルーティング。待機はフラストレーションだけではなく、毎週積み上がるコストを伴っていた。

方向を変える

2月中旬、3週間経っても認証の返答がなく、チームは改めて考え直した。本当に必要なのは公式APIではなく、受信メッセージを構造化されたイベントとして受け取り、ルーティングシステムが処理できるようにすることだった。公式APIは一つの手段であって、唯一の手段ではない。

チームは、サポートに使っていた既存のWhatsAppアカウント——ずっと使い続けてきた通常番号——をUnifyPortに接続した。設定は半日で完了した。書類も、審査ウィンドウも、待機も必要なかった。

それ以来、顧客からのすべてのインバウンドメッセージが message.received webhookイベントとしてバックエンドに届くようになった。構造は一貫している。メッセージ本文、送信者の参照、会話スレッドID、タイムスタンプ。API権限を待ちながら空転していたルーティングロジックが、ようやく処理すべきものを得た。

最初の3日間

1日目： アカウント接続、webhookエンドポイント設定、最初のテストメッセージ受信・記録。イベントペイロードの形式がバックエンドの期待するスキーマと一致すること、HMAC-SHA256署名が正しく検証できることを確認した。

2日目： ルーティングルールのデプロイ。メッセージ本文に注文番号が含まれる → ステータスを自動照会し自動返信。新規連絡先からの初回メッセージ → CRMエントリを作成しセールスフォローアップキューに追加。その他 → メッセージのコンテキストを事前入力した上で人的確認フラグを立てる。

3日目： 実際の顧客トラフィックで本番稼働。シフトの半分をWhatsAppのトリアージに費やしていた2人の担当者は、真に人間の判断が必要なエスカレーション対応に集中できるようになった。

3日目終了時点で、システムはインバウンドメッセージ量の約70%を自動処理していた。残りの30%は、生のDMではなく事前分類済みのチケットとして担当者に届いた。

その後の数字

本番稼働後30日間の実績：

• 初回応答時間：手動トリアージ時の平均2.4時間から、自動応答で90秒以内、エスカレーション対応で8分以内に短縮
• WhatsAppに費やす担当者時間：2人合計で約4時間/日から45分以内に削減。全て判断力が必要なケースに集中
• 注文ステータス照会（最大メッセージカテゴリ）：94%のケースで人手を介さずエンドツーエンドで解決

Business Verificationは3月末に最終的に承認された。その時点でチームは6週間、自動インバウンド処理を稼働させていた。機能しているものから移行することはなかった。

必要なかったもの

サードパーティプラットフォームへの企業登記書類の提出はなし。テンプレートカタログの作成と承認申請もなし。メッセージカテゴリと受信国ごとにトラッキングするメッセージ単位の課金体系もなし。インバウンドを処理したアカウントは、チームが手動サポートで使っていたものと同じ——顧客の連絡先リストにすでに登録されていた通常番号だった。

チームが構築したルーティングロジックは、最初からチャネル非依存だった。後に一部の買い手向けにTelegramを追加した際も、同じルーティングルールがそのまま機能した。message.received イベントの形式は同一。HMAC署名の検証も同一。ペイロード内の唯一の違いは、送信者のプラットフォームを示すフィールドだけだった。

このパターン

これはこのチームだけの話ではない。同じ連鎖はマーチャントのサポート運営で繰り返し現れる。インバウンド自動化が必要になる → 公式APIを前提とする → 認証と適格性要件がソフトウェアの問題を調達の問題に変える → 何も作れないまま数週間が過ぎる。

リバースインバウンドの経路——既存アカウントを接続し、正規化されたイベントを受信し、既存のルーティングロジックに接続する——はその連鎖を短縮する。ソフトウェアの問題はソフトウェアの問題のままでいられる。UnifyPort はその接続を担う。WhatsApp、Telegram、LINE、TikTok、Zalo、Xからのインバウンドイベントをひとつのスキーマに正規化し、HMAC署名付きでwebhookエンドポイントに届ける。認証キュー不要。

3日間は特別な成果ではない。他者の承認プロセスを待つ必要がなければ、本来こういうタイムラインになる。