WhatsApp 受信メッセージを受け取る3つの方法：Cloud API・BSP・非公式インターフェース 完全比較 — UnifyPort
WhatsApp のインバウンドメッセージを受信する方法は、一見すると解決済みの問題に見えます。しかし3つの選択肢には大きな差があり、誤った選択をすると導入に数週間の遅れが生じるか、コストが大幅に増加します。
まず確認しておくべき重要な変更点があります。WhatsApp オンプレミス API は 2025 年 10 月 23 日をもってサービスを終了しました。WhatsApp の Docker コンテナを自社インフラで稼働させる旧来のドキュメントを参照している場合、その方法はすでに閉鎖されています。現在は Cloud API、または公式 API 以外の代替手段を使うことになります。
方法1：Meta Cloud API（直接接続）
公式ルート。Meta Business Platform に電話番号を登録してウェブフックを設定すると、インバウンドイベントが Meta のサーバーから直接届きます。中間サービスは不要です。
必要なもの： Facebook Business Manager アカウント、Meta for Developers アカウント、WhatsApp 未登録の電話番号、ビジネス認証用の書類（税務番号・法人設立証明書・公共料金の領収書など）。
導入期間： アプリ作成・番号登録・ウェブフック設定といった技術的な作業は1時間以内に完了します。ボトルネックはビジネス認証（Business Verification）です。書類を提出してから Meta の承認を得るまで、通常2〜5営業日かかり、最長2週間になるケースもあります。
認証前の制限： アカウントは24時間ローリングウィンドウで、ビジネス側から開始できる会話が250件に制限されます。ユーザー側から送られてくるメッセージ（ユーザー起点の会話）にはこの制限が適用されません。受信が主な用途であれば、認証完了前でもメッセージ受信は開始できます。
認証後： メッセージ上限が第1ティア（24時間あたり1,000件のビジネス起点会話）に引き上げられ、品質評価に応じて上位ティアへの申請が可能になります。
費用： API アクセスは無料。2025年7月1日以降、配信されたテンプレートメッセージ1件ごとに課金されます。費率はメッセージカテゴリ（マーケティング・ユーティリティ・認証・サービス）と受信者の国によって異なります。毎月1,000件のサービス会話が無料枠として提供されます。ウェブフックのインフラは自社で構築・維持する必要があります。
方法2：BSP（公式パートナー）
BSP（Business Solution Provider）は Meta が認定したパートナー企業で、WhatsApp Business API アクセスを再販します。Meta と直接やりとりする代わりに、BSP のプラットフォームを通じてオンボーディングします。BSP は API 接続とウェブフック配信を管理し、多くの場合は管理 UI も提供します。
主要な BSP には Twilio、WATI、360dialog、SleekFlow、1msg、Vonage などがあります。
導入期間： Cloud API 直接接続より一般的に速く、ガイド付きのオンボーディングプロセスが用意されています。一部では基本的なユースケースなら数時間での導入を謳っています。ただし上位メッセージティアでは Meta の認証要件が引き続き適用されます。
費用：
- Meta のメッセージ課金（直接接続と同じ基本レート）
- BSP の上乗せ：1件あたり $0.003〜$0.010 の追加料金、または基本レートに10〜30%のマークアップ
- 月額プラットフォーム料金：基本プランで月$29程度から、エンタープライズプランで$500+
- 番号単位の料金：番号1件あたりの追加料金を設ける BSP もあります（例：月額$15/番号）
低流量の場合は月額プラットフォーム料金が主要コスト、高流量になると1件あたりのマークアップが大きくなります。いずれにせよ Cloud API 直接接続より費用は高くなります。
得られるもの： 管理されたインフラ、受信トレイとテンプレート管理 UI、コンプライアンスガイダンス、WhatsApp のポリシーを理解したサポート体制。
方法3：非公式インターフェース
3つ目の方法は Meta の API スタックを使用しません。非公式インターフェースはブラウザが使う仕組みと同じ WhatsApp Web 経由で接続し、インバウンドメッセージを構造化されたウェブフックイベントとして受け取ります。
これが UnifyPort のインバウンド処理の方法です。通常の WhatsApp アカウント（個人番号や既存のサポート用番号を含む）を一度接続すると、すべてのインバウンドメッセージが標準的な message.received イベントに正規化され、HMAC-SHA256 署名付きでウェブフックに配信されます。
必要なもの： 既存の WhatsApp アカウント。ウェブフックエンドポイント。
導入期間： 通常1日以内。書類不要、審査待ち不要、Business Manager アカウントも不要です。
費用： メッセージ単位課金ではなくサービスサブスクリプション。インバウンド側に Meta 料金は発生しません。
得られるもの： 迅速な開始、既存番号のそのままの利用（顧客の連絡先に登録済みの番号が使える）、そして Telegram・LINE・TikTok・Zalo・X からのイベントと構造的に同一の message.received フォーマット——1つのスキーマですべてのチャネルをカバー。
引き受けるもの： この方法は WhatsApp の利用規約の範囲外で動作します。WhatsApp は行動分析やパターンマッチングにより非公式 API の利用を積極的に検知しています。検知された場合、アカウントが停止されるリスクがあります。これが主なトレードオフであり、仮定上のリスクではありません。
比較表
| Cloud API（直接） | BSP | 非公式インターフェース | |
|---|---|---|---|
| 初回ウェブフック受信まで | 数時間 + 2〜14日（認証） | 数時間〜数日 | 1日以内 |
| ビジネス認証の要否 | 必要 | プロバイダーによる | 不要 |
| 既存番号の利用可否 | 不可（未登録番号のみ） | 不可 | 可能 |
| API 基本費用 | 無料（メッセージ課金） | 無料 + 10〜30% マークアップ | サブスクリプション |
| 月額プラットフォーム料金 | なし | $29〜$500+ | サブスクリプション |
| データのルーティング | Meta → 直接 | BSP 経由 | サービス経由 |
| WhatsApp 利用規約準拠 | 準拠 | 準拠 | 非準拠 |
| マルチチャネル正規化 | なし | なし | あり（6プラットフォーム） |
どの方法がどの状況に適しているか
Cloud API 直接接続： 大規模展開を目指す場合、公式コンプライアンスが必要な場合、認証待ちの余裕がある場合、長期的に最低単価を追求する場合に適しています。
BSP： 技術力の低いチームで管理 UI が重要な場合、テンプレート管理を自前で構築したくない場合、セットアップの速さと運用サポートのために追加コストを払える場合に適しています。
非公式インターフェース： 今すぐメッセージ受信を開始する必要がある場合、既存番号がすでに顧客の連絡先に登録されている場合、認証待ちで数週間のローンチ遅延が発生する場合、そして利用規約リスクを評価・許容した場合に適しています。すべてのチャネルを1つの正規化イベントスキーマでカバーしたい場合にも選択肢となります。
3つの方法は同じユーザーを取り合っているわけではありません。多くのチームは選択を行った後、いずれこの比較に立ち戻ることになります。決める前に3つすべてを理解しておく価値があります。