Zalo の2026年6月版 OA 料金が始動：あるクロスボーダーチームが OA の手続き地獄を避けつつ Zalo メッセージを受け続けた方法 — UnifyPort
2026年6月1日、Zalo の新しい公式アカウント（OA）サービス料金が施行された。ホーチミンの小さなオフィスでスキンケアを売る5人のクロスボーダーチームにとって、そのメールは最悪のタイミングで届いた。セール真っ最中、すでにスタッフ2人がほぼ一日中、Zalo と WhatsApp のチャットで顧客対応をしていた。この料金通知は、彼らが先送りにしてきた問いを突きつけた——今やっていることを続けるのに、実際いくらかかるのか？
彼らがやっていたことはシンプルだ。顧客が Zalo で店にメッセージを送る。誰かが返信する。それだけ。ニュースレターも、一斉配信も、自動シナリオ配信もない。ところが Zalo が「プログラムでメッセージを受信したい企業」のために用意した道は、公式アカウントの仕組み一式を通る——そしてその仕組みは配信者向けに作られていて、最初にメッセージをくれた人に返信したいだけのチーム向けではない。
OA という「トレッドミル」が合わなかった理由
公式ルートで Zalo メッセージを受信するということは、公式アカウントを立ち上げ、認証を取り、OA のルールの中で生きるということだ。一番こたえるのはインタラクションウィンドウだ。OA がユーザーに自由にメッセージを送れるのは、そのユーザーが連絡してきた後の限られた時間枠の中だけ。その枠を外れれば——翌朝フォローする、2日後に注文の更新を送る——もう Zalo Notification Service（ZNS）の領域で、各メッセージは事前承認されたテンプレートに乗り、1通ごとに課金される。
配信者にとっては妥当な取引だ。だが5人の店にとっては、これはトレッドミルだ。テンプレートはどれも、書いて、提出して、承認されてから初めて使える。6月1日の料金改定は OA プランの区分を見直し、何が無料枠に入り何が課金されるかを変えた——そしてチームの読みでは、自分たちの本当に低ボリュームで会話的な使い方が、より高く、より手続き的になろうとしていた。彼らは何千通もマーケティングメッセージを送っているわけではない。質問に答えているだけだ。なのに、自分たちがやってもいないことをやっている会社のコスト構造と承認フローを、採用しろと求められていた。
しかも Zalo は受信箱の一つにすぎない。同じスタッフ2人は一日中 WhatsApp にもいて、そちらにはそちらの仕組みがある——ビジネス認証、1通ごとの課金、独自のテンプレート審査。2つのプラットフォーム、まったく別の2つのルール、自動化したければ2つの連携。コストはお金だけではない。チームが本当にやりたいたった一つのこと——メッセージが入ってくるのを見て、返信する——に到達する前に、各チャネルが別々のシステムを学べと要求してくることだった。
問題の捉え直し：必要なのは受信であって、公式アカウントではない
突破口を開いた気づきは、自分たちに必要なものと公式ルートが抱き合わせにしているものを切り分けたことだ。OA の配信機構——テンプレート、ZNS、インタラクションウィンドウ、料金区分——は、企業が大規模にこちらから接触を開始できるようにするためにある。このチームは決して自分から始めない。会話はすべて顧客から始まる。必要だったのは、入ってくるメッセージを確実に受信し、顧客がすでに開いた会話の中で返信することだけ。
これは「公式アカウントを運営する」よりずっと小さな問題だ。受信のみ、セッション内返信のみの使い方には、配信ツールはまるで要らない。そう見えた瞬間、問いは「どの OA プランを買うか」ではなく「入ってきた Zalo メッセージをバックエンドに届け、同じチャットに返信を返す、一番シンプルな方法は何か」に変わった。
Zalo と WhatsApp を1本の webhook で
彼らは両方のアカウントを UnifyPort の非公式インバウンドインターフェースで接続した。これは各チャネルを、プラットフォームごとの連携ではなく、1本の正規化された webhook の背後にまとめる。Zalo のメッセージと WhatsApp のメッセージは、まったく同じ形で届く。違いは provider フィールドだけだ：
{
"event": "message.received",
"account_id": "acct_7Hm2pX",
"provider": "zalo",
"from": "user_9a3f21",
"text": "Sản phẩm này còn hàng không ạ?",
"timestamp": 1749513600,
"message_id": "zalo_msg_4c8e1d"
}バックエンドは message.received という1つのイベントだけを購読し、単一フィールドで振り分ける。Zalo メッセージを処理するコードと WhatsApp メッセージを処理するコードは同じ——受信側にプラットフォーム別の分岐は存在しない：
app.post("/webhook", (req, res) => {
if (!verifySignature(req)) return res.sendStatus(401);
const evt = req.body;
if (evt.event === "message.received") {
// evt.provider が "zalo" でも "whatsapp" でも振り分けは同一
queue.add({
channel: evt.provider,
customer: evt.from,
text: evt.text,
accountId: evt.account_id,
});
}
res.sendStatus(200);
});各配信には署名が付く。だからチームは、どんな payload も信頼する前に、webhook に設定した signing_secret に対して HMAC-SHA256 検証を行う——どのプラットフォームから来ても、同じ verifySignature ステップだ。返信は鏡写しで、アカウントと宛先を指定する1回の POST /v1/messages 呼び出し。顧客が先にメッセージを送っているので、返信はすべて顧客が開いた会話の中に届く——チームが元々手作業でやっていたセッション内のやり取りそのものが、テンプレートの事前承認なしにスクリプト化された。
実際の結果として、6月1日の料金通知は予算の緊急事態ではなくなった。チームは、低ボリュームで顧客起点のチャットに答え続けるために OA の上位区分を買い上がる必要がなかった。サポート2人は同じ2つの受信箱で働き続け、ただその2つが今は1つのキュー、1つのスキーマ、1つの返信経路に流れ込む——そして後日、日本のサプライヤー向けに LINE を足すのも、同じ message.received ハンドラがもう一度動くだけで、3つ目の連携プロジェクトではなかった。日本では LINE が事実上の標準チャネルなので、これは絵空事ではなく現実的な次の一手だ。
ここから持ち帰れること
教訓は「Zalo の公式アカウントを避けろ」ではない——大規模に配信キャンペーンを回すなら、OA と ZNS はまさにそのために作られているので、使うべきだ。教訓は、公式ルートが解いているのがあなたの問題なのか、それともあなたが抱えていないもっと大きな問題なのかを確かめること。高ボリュームの配信者を狙った料金改定が、「ただ顧客に返信する」コストを静かに押し上げることがある。公式ルートが両方の振る舞いを同じアカウントに抱き合わせているからだ。
必要なのが入ってくるメッセージの受信とセッション内返信だけなら、それは切り離せる、ずっと安い問題だ。バックエンドを正規化されたインバウンド webhookに向け、message.received を購読すれば、OA のトレッドミルなしに Zalo メッセージがキューに入ってくる——そして必要になった日には、LINE を含む残り5つのチャネルが、同じハンドラを通って届く。