← 全記事
チュートリアル

2026 年 10 月 1 日までに WhatsApp service message の料金を追跡する方法

2026 年 10 月 1 日からの WhatsApp service message 料金を追跡するには、Meta の Pricing Analytics API で配信済みの SERVICE message を計測し、message status webhook の pricing object を保存します。結果は電話番号と市場別に分けてください。現時点で volume の基準値は作れますが、Meta が 9 月 1 日までに 10 月適用分の service rate を公開した後、forecast を更新する必要があります。

要点

  • Meta は 2026 年 10 月 1 日から、配信済みの service message ごとに課金します。customer service conversation は課金単位ではなくなります。
  • Pricing Analytics では、対象 record が pricing_type: REGULAR と pricing_category: SERVICE で識別されます。
  • 課金対象の status webhook では、pricing object 内に billable: true、type: regular、category: service が含まれます。
  • Service rate は市場ごとに異なり、その市場の utility rate と authentication rate に揃えられます。volume tier はありません。
  • Click-to-WhatsApp 広告と Facebook の call-to-action button から始まる 72 時間の free entry point では、message delivery は引き続き無料です。forecast では分けて扱ってください。

2026 年 10 月 1 日に変わること

Meta の公式価格更新によると、non-template message を送信できるのは 24 時間の customer service window が開いている間だけです。10 月 1 日以降、Meta Business Agent を利用していない人または third-party AI が送る non-template message は、1 通ごとに service message として課金されます。

計測計画では、次の 3 つの境界を維持する必要があります。

境界Meta の分類追跡する項目
開いている window 内で人または third-party AI が返信Service message市場別の配信済み message 数
Meta Business Agent が返信Meta Business Agent message専用 category と token ベースの料金
72 時間の free entry point window 内の messageDelivery は引き続き無料Entry point と window の状態

1 通の message に適用される category charge は 1 つだけです。同じ non-template reply に service charge と Meta Business Agent charge を重ねて計上しないでください。また、現時点の 10 月向け rate を確定値と考えてはいけません。Meta は 10 月 1 日に適用される rate を 2026 年 9 月 1 日までに公開し、その後も四半期ごとに更新する場合があるとしています。

以前のMeta Business Agent の価格比較では、architecture の選択を解説しています。2026 年 7 月の rate card guideでは、市場別 rate の背景を確認できます。本 guide はその判断後を対象にし、課金開始前にチームが計測すべき項目を示します。

WhatsApp service message の料金を追跡する方法

1. 配信済み message の基準値を作る

通常は、完全な 4 週間など代表性のある期間を選び、service category を指定して Pricing Analytics を query します。Meta が公開している結果には、次の field が含まれます。

Field基準値での用途
start / endreporting window を固定する
phone_number送信元の電話番号ごとに分ける
countryvolume を正しい市場 rate に結び付ける
pricing_type: REGULAR別の pricing type を除外する
pricing_category: SERVICEservice message だけを数える
volume配信済み service message を計測する
cost課金開始後に料金を照合する

結果は日、電話番号、country ごとに保存してください。「conversation」にまとめてはいけません。10 月以降の Meta の計測単位は、business から配信された message 1 通ごとです。サポート担当者が 5 回返信したやり取りは、1 conversation ではなく 5 つの計測単位になります。

2. Status webhook の pricing object を保存する

Meta によると、category と charge は message status webhook にも含まれます。課金対象の service-message record は次の形です。

{
  "pricing": {
    "billable": true,
    "pricing_model": "PMP",
    "type": "regular",
    "category": "service"
  }
}

集計する前に、pricing object を自社の message record と一緒に保存してください。agent がその返信を「support」だと判断したかではなく、Meta が配信済み message を category: service かつ billable と報告したかどうかが重要です。

3. Webhook と Pricing Analytics を照合する

毎日、次の 2 つの件数を照合します。

  1. pricing.category が service の配信済み status-webhook record。
  2. 同じ電話番号、country、日付範囲について、pricing_category が SERVICE の Pricing Analytics volume。

差が出た場合は、平均して済ませず原因を調べてください。よくある境界には、遅れて届く status event、time zone の不一致、最終日を含まない report window、service ではなく Meta Business Agent に分類された message があります。日本のチームが複数市場を運用する場合も、reporting time zone を先に固定しておくと照合条件を一貫させられます。

4. 10 月の rate を作り出さずに forecast を組む

Volume と rate を分けた式を使います。

service-message の予測コスト
  = 市場別の配信済み SERVICE volume
  × その市場で公開された service rate

9 月 1 日より前の計画では、service rate は市場ごとの utility rate と authentication rate に揃えられる、という Meta の説明を入力値に使えます。ただし、現在の rate は計画用であり、確約された値ではありません。公式の 10 月向け rate が公開されたら model を更新してください。また Meta は service message に volume tier はないと説明しているため、utility / authentication の volume-tier discount を適用してはいけません。

Business Solution Provider が platform fee や service fee を加える場合、その項目は別にしてください。BSP 請求の監査 guideでは、Meta の usage と provider fee をまとめると、必要な判断が見えにくくなる理由を解説しています。

5. 開始日前に例外を test する

10 月 1 日までに、小さな acceptance matrix を用意します。

  • 24 時間の customer service window 内で人が通常返信するケース。
  • 同じ window 内で third-party AI が生成した返信。
  • Meta Business Agent の返信。
  • 有効な 72 時間の free entry point window 内の返信。
  • 同じ scenario を 2 つの受信者市場で実行するケース。

各 case について、status webhook が返した category と、対応する Pricing Analytics row を記録します。最初の請求が届く前に、finance、support、engineering が共通の定義を持てるようになります。

UnifyPort が該当する範囲

ここまでの計測は、公式 WhatsApp Business Platform を通じて送信する traffic が対象です。通常アカウントの inbound messaging に UnifyPort の非公式インターフェースを使うチームでは control plane が異なり、その経路では Meta の Pricing Analytics category が source of truth にはなりません。

UnifyPort は、WhatsApp の inbound message を Telegram、LINE、TikTok、Zalo、X と共通の標準 message.received envelope で配信します。

{
  "id": "evt_7c41f0b2a9",
  "type": "message.received",
  "provider": "whatsapp",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-07-14T02:15:00Z",
  "data": {
    "conversation": { "id": "84901234567", "type": "user" },
    "sender": { "id": "84901234567", "type": "user", "name": "Minh Tran" },
    "message": {
      "id": "wamid.HBgM",
      "type": "text",
      "text": "Can you check my delivery window?",
      "direction": "inbound",
      "sent_at": "2026-07-14T02:14:58Z"
    }
  }
}

署名を有効にしている場合は、event を処理する前に signing_secret と X-Device-Timestamp を使い、正確な raw body に対して X-Device-Signature を検証します。Webhook delivery referenceには、HMAC-SHA256 の入力値と delivery behavior が記載されています。

これは、Meta 経由で送信しながら公式 platform の料金を消す方法ではありません。通常アカウントの inbound access、または複数の messaging channel を 1 つの正規化された queue にまとめる必要があるチーム向けの、別の integration choice です。

制約と trade-off

承認済み template、公式 campaign tooling、Meta-native analytics、Click-to-WhatsApp attribution、Business Solution Provider の managed support が必要なら、公式 WhatsApp Business Platform のほうが適しています。workflow の一部でも公式 platform を使う場合は、公式向けの計測計画を維持してください。

UnifyPort は、WhatsApp policy compliance、公式 marketing capability、Meta の billing record を置き換えません。非公式インターフェースでは、Meta の Pricing Analytics category も提供されません。混在する architecture では ledger を分け、すべての outbound path を明示的に label してください。

FAQ

2026 年 10 月 1 日以降、WhatsApp service message は conversation 単位で課金されますか？

いいえ。Meta は、配信済み service message ごとに課金すると説明しています。24 時間の customer service window ごとではなく、service に分類された business からの返信を 1 通ずつ数えてください。

Service message は Pricing Analytics のどの category で追跡しますか？

pricing_type: REGULAR と pricing_category: SERVICE を使います。返された volume と cost を、電話番号、country、reporting window ごとに分けてください。

2026 年 7 月時点で 10 月の最終コストを計算できますか？

Volume を計測して model を作ることはできますが、最終的な rate はまだ確定していません。Meta は、10 月 1 日に適用する rate を 2026 年 9 月 1 日までに公開するとしています。

Service message に WhatsApp の volume-tier discount は適用されますか？

いいえ。Meta の更新では、utility message と authentication message には引き続き volume tier がありますが、service message にはないと説明されています。

72 時間の free entry point window は引き続き無料ですか？

Message delivery は無料です。Meta によると、有効な 72 時間の free entry point window 内の message delivery は引き続き無料ですが、Meta Business Agent の token usage は別途課金される場合があります。

次のステップ

公式の billing model と並行して正規化された inbound path を評価する場合は、UnifyPort Quickstartに沿って、production routing を変更する前に署名付き message.received event を test してください。

Sources