WhatsApp Meta Business Agent の token 課金：インバウンド中心のチームが 8 月 1 日までに決めること
7 月 2 日以降、WhatsApp Business の価格変更は単なる請求の話ではなく、AI アーキテクチャの話になりました。
Meta の価格更新によると、2026 年 8 月 1 日から、WhatsApp Business Platform 上の Meta Business Agent が生成するメッセージは token ベースで課金されます。もう 1 つ重要な日付があります。2026 年 10 月 1 日から、customer service window 内で送信される service messages と utility templates も、再びメッセージ単位で課金されます。つまり、多くのサポートチームが低コストだと考えていた自由形式の返信が、再び明確な課金対象になります。
これは価格だけの変更ではありません。顧客メッセージを受信し、AI でトリアージ、見込み度判定、検索、一次返信を行いたいチームの判断基準を変えます。
アウトバウンドキャンペーンを運用しているなら、template category と配信単価を追うのは当然です。しかし、ワークフローが主に inbound なら、問いは別です。Meta のホスト型 agent を WhatsApp 内に置くべきか。それともインバウンド層を自分たちで持ち、メッセージを自社の AI agent に流すべきか。
新しい判断ポイント
Meta Business Agent は、ノーコードで自動化したい個人事業者や小規模チームにとって魅力的です。Meta はこの agent を、質問への回答、商品推薦、顧客情報の収集、予約、必要に応じた人への引き継ぎができるものとして説明しています。WhatsApp Business App の中だけで仕事をしている店舗には、便利なパッケージです。
ただし、サポート量が多い技術チームは、別のモデルと比較する必要があります。
| 判断項目 | Meta Business Agent | インバウンド webhook 上の自社 AI agent |
|---|---|---|
| メッセージの到着先 | WhatsApp / Meta の agent 層 | 自社の webhook、キュー、CRM、ヘルプデスク |
| 課金単位 | 8 月 1 日から Meta Business Agent の token 使用量 | 自社のモデル/provider コストとインフラコスト |
| service 返信 | 10 月 1 日から、Meta Business Agent 以外の返信は再び課金対象 | どの送信経路を選ぶかによる |
| AI の制御 | Meta の agent 製品内で設定 | prompt、モデル、検索、ツール、人への引き継ぎを完全に制御 |
| 複数チャネル | WhatsApp と Meta 系の面が中心 | 同じ handler で WhatsApp、Telegram、LINE、TikTok、Zalo、X を受信 |
| データ保存 | Meta 製品の境界内 | 到着時に自社システムへ保存 |
ホスト型 agent は、「ソフトウェアは作らずに WhatsApp 顧客へ自動返信したい」場合に合っています。webhook モデルは、WhatsApp がより大きなサポートシステムの 1 チャネルである場合に強くなります。
これは通常の rate card 更新ではない
6 月の rate card 記事は、template 価格と市場ごとの変化についてのものでした。今回の論点は制御面です。
service-message 課金は、24 時間の customer service window 内で顧客へ返信するチームに影響します。token 課金は、Meta のネイティブ AI agent を選ぶチームに影響します。この 2 つの変化は、チームに選択を迫ります。Meta が WhatsApp 内に統合した AI 経路に支払うのか、WhatsApp を入力チャネルとして扱い、自社の推論層を動かし続けるのか。
2 人から 10 人程度の技術チームでは、後者のほうが評価しやすいことが多いです。アーキテクチャが明示的だからです。
- 顧客が WhatsApp メッセージを送る。
- メッセージが標準イベントとして webhook に届く。
- バックエンドが署名を検証する。
- ルーターが、人、CRM 検索、AI agent のどこへ送るかを決める。
- システムがイベント、モデル出力、人への引き継ぎ判断を保存する。
重要なのは AI があるかどうかではありません。メッセージが最初に、自分たちが制御できるデータになる場所です。
UnifyPort の経路
UnifyPort を使うと、WhatsApp アカウントのインバウンドメッセージを、他のメッセージチャネルと同じ webhook endpoint に届けられます。イベントは message.received として届き、provider が変わっても安定した共通 envelope を使います。
{
"id": "evt_7c41f0b2a9",
"type": "message.received",
"provider": "whatsapp",
"account_id": "acc_8c21d0",
"occurred_at": "2026-07-03T09:24:18Z",
"data": {
"conversation": {
"id": "84901234567",
"type": "user"
},
"sender": {
"id": "84901234567",
"type": "user",
"name": "Minh Tran"
},
"message": {
"id": "wamid.HBgM",
"type": "text",
"text": "Can your team check my shipment before closing today?",
"direction": "inbound",
"sent_at": "2026-07-03T09:24:16Z"
},
"event": {
"kind": "message_received"
}
}
}webhook endpoint に signing_secret が設定されている場合、署名付き配信には X-Device-Timestamp と X-Device-Signature が含まれます。署名は timestamp、ドット、raw request body に対する HMAC-SHA256 の hex digest です。これにより、AI agent や人のキューがメッセージを扱う前に、バックエンド側で 1 つの検証経路を持てます。
その後の AI アーキテクチャは自分たちで決められます。シンプルなサポートパイプラインは次のようになります。
WhatsApp message
-> UnifyPort message.received webhook
-> Signature verification
-> Intent classifier
-> CRM / order lookup
-> AI draft response
-> Human review or auto-reply rule同じパイプラインで Telegram、LINE、TikTok、Zalo、X も受信できます。変わるのは provider の値であり、handler を作り直す必要はありません。AI サポートシステムは、顧客の全体像を見られるときに初めて役に立ちます。WhatsApp agent が 1 チャネルだけを回答し、LINE や Zalo のメッセージが別の場所に残るなら、自動化はまだ分断されたままです。
8 月 1 日までに確認する 3 つのこと
Meta Business Agent の token 課金が始まる前に、現在の WhatsApp サポートワークフローを 3 つの観点で確認してください。
第一に、インバウンドルーティングと AI 返信を分けて考えること。 AI に返信案を書かせたいとしても、WhatsApp を system of record にする必要はありません。CRM、ヘルプデスク、社内ダッシュボードが顧客コンテキストを持つなら、インバウンドメッセージは最初にそこへ届くべきです。
第二に、監査が必要な判断を洗い出すこと。 リード判定、返金対応、予約変更、エスカレーションルールは、単なるチャット返信ではなく業務判断です。なぜ顧客がそのルートに振り分けられたのか、AI がどの情報源を使ったのか、いつ人に引き継いだのかを見たいなら、チャットアプリの外にイベントログが必要です。
第三に、チャネル数を数えること。 WhatsApp が唯一の顧客チャネルなら、Meta のホスト型 agent で十分かもしれません。Telegram、LINE、TikTok、Zalo、X も扱うなら、WhatsApp-only agent は複雑さを減らすのではなく、別の運用モデルを増やす可能性があります。
Meta Business Agent が正解になる場合
Meta Business Agent が正しい既定値になるケースはあります。
個人事業者で、ほとんどのメッセージが WhatsApp 内にあり、独自 CRM を使っておらず、コードを書かずに事業コンテンツからよくある質問に答えるアシスタントが欲しいなら、Meta の製品はそのために設計されています。設定は WhatsApp 内で行い、agent は事業コンテンツから学習し、人への引き継ぎ制御も同じアプリ内にあります。
これは、複数チャネルをバックエンドに統合する技術チームとは別の買い手です。そのチームにとって、ホスト型 agent のコストは token 請求だけではありません。データ、ルーティング、エスカレーションを複数の面に分けるコストも含まれます。
アーキテクチャ判断に書くべきこと
実務上の判断はシンプルです。
- WhatsApp 自体が作業場所なら、WhatsApp-native agent を使う。
- WhatsApp がサポートシステムへの 1 つの入力なら、インバウンド層を中立に保つ。
- AI 判断を記録、ルーティング、テスト、複数チャネルで再利用する必要があるなら、agent を自社 webhook パイプラインの後ろに置く。
UnifyPort の役割は狭く、意図的です。WhatsApp と主要メッセージングプラットフォームからのメッセージを、1 本の署名付きイベントストリームとして自社システムへ届けます。AI モデル、prompt、CRM、エスカレーションルールを決めるのは UnifyPort ではありません。システムが十分早い段階で原材料を受け取り、自分たちで判断できるようにするだけです。
8 月 1 日には AI コストが見えるようになります。10 月 1 日には service 返信のコストも再び見えるようになります。インバウンド中心のチームにとって、次の 1 か月は、WhatsApp に agent を持たせるのか、WhatsApp には信頼しているシステムへメッセージを届けてもらうだけにするのかを決める時間です。