LINEもまとめて1本のWebhookへ:東京のチームがLINEとWhatsAppの受信を統合した方法 — UnifyPort

2026年4月下旬、東京を拠点とする4人体制のスキンケアブランドが、初夏のキャンペーンの最終準備を進めていました。期間限定の日焼け止めラインをローンチし、それに合わせてLINEベースのカスタマーサポート・ロイヤルティチャネルを用意する計画です。日本の消費者にとって、ブランドに連絡する手段としてLINEはほぼデフォルトです。計画はシンプルでした——顧客がブランドのLINEアカウントに新商品や再入荷時期、注文状況について問い合わせると、そのメッセージは既存のサポート処理キューにルーティングされる、というものです。

その「既存のキュー」とは、WhatsAppのことでした。このブランドは中国と東南アジア全域のサプライヤーから包装資材を調達しており、サプライヤーとのやり取りはすべてWhatsApp上で行われ、年初からUnifyPort経由でバックエンドに接続されていました。チームの見立てでは、LINEの追加も同じ作業のはずでした——アカウントを接続し、メッセージを受信し、ルーティングする。

しかし、そうはいきませんでした。LINEの公式な道のりは、「アカウントを接続する」ところから始まらないからです。

ローンチ2週間前に立ちはだかった「60営業日の壁」

LINE上でプログラム的にメッセージを受信するには、Messaging APIにLINE公式アカウントが必要です。チームは5月初旬に登録申請を行い、通常の承認プロセスだと考えていました。しかしLINE自身のドキュメントには、認証済み公式アカウントの審査には最長60営業日かかると記載されていました。一方、未認証の公式アカウントは友だち数500人までという上限があり、本格的な反応が見込まれる季節キャンペーンであれば初週でこの上限に達してしまいます。

5月初旬から数えて60営業日は、キャンペーンのローンチ期間どころか、日焼け止めの販売シーズン自体を大きく過ぎてしまいます。チームの前にあったのは、いつもの選択肢でした。LINEサポートなしでローンチする(LINEがほぼカスタマーサポートそのものという市場で)、未認証アカウントでローンチしてトラフィックのピーク時に友だち数の上限に当たる、あるいは現地の代理店に登録の優先処理を依頼する——コストもスケジュールも、両創業者には見通せませんでした。

これらの選択肢は、どれも技術の話ではありませんでした。バックエンドの処理ロジック——メッセージを受信し、注文を照会し、返信する——は、WhatsApp向けに書いたあの9行のルーティングロジックとほぼ同じです。本当のボトルネックは、「LINEアカウントは既にある」と「バックエンドがそのアカウント宛のメッセージを見られる」の間にある審査待ちの行列に、完全に存在していました。

視点の転換:WhatsAppの接続方法が、すでにこのパターンを実証していた

チームのリード開発者は、数ヶ月前にUnifyPort経由でWhatsAppを接続していました——MetaのCloud APIではなく、UnifyPortの非公式インバウンドインターフェースです。既存のWhatsAppアカウントに直接接続し、message.receivedイベントをWebhookに配信する仕組みで、Business Verificationは不要でした。当時その選択をした理由はLINEとは無関係でした(サプライヤー向けのWhatsApp番号には対外的なマーケティング機能は不要で、安定したインバウンドだけが必要だった)。しかし、その経験こそが、今チームがLINEに対して必要としていた判断をすでに証明していたのです。公式認証・審査の仕組みが管理しているのは、対外的なブロードキャスト能力であり、インバウンドメッセージの到達そのものではないということです。

顧客が最初にブランドのLINEアカウントへメッセージを送る——このケーススタディのすべてのシナリオがこれです——という行為は、そのメッセージがバックエンドに届くために、ブランド側がフォロワー数を満たした認証済み公式アカウントを持つ必要があることを意味しません。WhatsAppを静かに処理し続けていたのと同じ非公式インバウンドインターフェースで、LINEアカウントも同じように接続できるはずでした。

既存のWebhookにLINEを追加する

チームは、設定済みのWhatsAppアカウントと並べて、LINEアカウントをUnifyPortに接続しました——新しいWebhookエンドポイントも、2つ目の署名方式も、別途管理する認証情報のローテーションスケジュールも不要です。両方のアカウントは同じPOST /webhookURLに、同じHMAC-SHA256シークレットで署名されて配信されます。

LINE顧客(日本)            ──┐
WhatsAppサプライヤー(中国/東南アジア) ──┼──► UnifyPort ──► POST /webhook(既存バックエンド)
                          ┘     X-UnifyPort-Signature: sha256=...

LINEの顧客からの再入荷に関する問い合わせと、WhatsAppのサプライヤーからのメッセージは、まったく同じ構造で届きます——変わるのはproviderフィールドだけです。

{
  "event": "message.received",
  "account_id": "acct_3Tn8qZ",
  "provider": "line",
  "from": "U2c91af77b8d4e...",
  "text": "新作の日焼け止め、再入荷はいつ頃ですか？",
  "timestamp": 1748332800,
  "message_id": "line_msg_7e2a91"
}

WhatsAppのサプライヤーからのメッセージを調達キューに振り分けていた既存のルーティングハンドラーには、分岐がひとつ増えただけです。provider == "line"の場合はカスタマーサポートキューへ。新しいスキーマを解析する必要もなく、署名検証を再実装する必要もなく、重複排除やリトライのロジックを別に書く必要もありません。年初から本番で稼働していたWhatsAppの処理ロジックが、1つの条件分岐でLINEを取り込みました。

キャンペーン開始後ではなく、開始前から稼働

LINEの接続は、設定した当日のうちに本番稼働しました——キャンペーン開始のおよそ2週間前で、ソフトローンチの実トラフィックでルーティングルールをテストする時間も十分にありました。6月初旬に日焼け止めラインが正式にローンチされると、LINE経由で届いた顧客からの問い合わせは、最初の1件目から自動で分類・ルーティングされ、他のチャネルのメッセージと一緒に同じ処理キューに入りました。

5月初旬に提出していたLINE公式アカウントの申請は、キャンペーン開始時点ではまだ審査中でした。最終的に承認が下りたのは、そこから約7週間後でした。しかしその時点では、LINEのインバウンドはキャンペーン期間全体を通じて本番で稼働し続けており、審査結果はもう何もブロックしていませんでした。今後この公式アカウントが承認され、チームが欲しい機能(リッチメニュー、公式バッジ、より大きなフォロワー層への配信など)が手に入ったとしても、インバウンドの経路に手を入れることなく、その上に重ねていけます——そもそもインバウンドはブロックされていた部分ではなかったからです。

このパターンを一般化すると

うまくいった理由は、LINE特有のテクニックではありません。チームがWhatsAppの導入から学んでいたのは、インバウンドの受信とアウトバウンドのブロードキャスト資格は、それぞれ別のゲートキーパーが管理する別々の問題だという考え方です。あるプラットフォーム用に正規化されたインバウンドWebhookが一度できあがれば、2つ目のプラットフォームを追加するのは、ほとんどの場合、別のアカウントを同じ接続にぶら下げ、すでに動いているハンドラーに1つ分岐を加えるだけの作業です。

日本、タイ、台湾など、LINEが主要な顧客チャネルであるどの市場のチームにとっても、本当に問うべきことは「キャンペーン開始までにLINE公式アカウントを承認してもらえるか」ではありません。「初日からアウトバウンドのブロードキャスト能力が必要なのか、それとも今顧客が何を聞いてきているかを見たいだけなのか」です。後者であれば、LINEアカウントをUnifyPortに接続するのは1日で完了するタスクです。WhatsApp、Zalo、TikTok、Xも既にUnifyPortで使っているなら、それは同じWebhook——メッセージはもうそこに届いています。

公式の審査プロセスは、今もバックグラウンドで進んでいます。ただ、それはもうクリティカルパス上にはありません。