WhatsApp CoexistenceでビジネスアプリとCloud APIを同時利用可能に——本当に両方必要ですか？
Metaが2026年に14カ国以上で本格展開したWhatsApp Coexistence機能は、WhatsAppビジネスユーザーを長年悩ませてきた問題を解決します：ビジネスアプリ（手動・スマホ操作）とCloud API（自動化・webhook駆動）のどちらか一方しか使えませんでした。Coexistenceなら、同一電話番号で両方を同時運用でき、メッセージはリアルタイムで同期されます。
確かに意味のある改善です。しかし問いかける価値があります：あなたのチームは本当に両方必要でしょうか？
Coexistenceが提供するもの
Coexistenceは、WhatsAppビジネスアプリとCloud API間のすべての1対1会話をリアルタイムでミラーリングします。顧客があなたの番号にメッセージを送ると、スマホのビジネスアプリとCloud APIのwebhookイベントの両方に同時に表示されます。どちら側から送った返信も数秒以内にもう一方に同期されます。
実用シナリオ：営業チームはスマホから返信し、サポートキューは自動化システムで処理。両方が同じ会話を見られます。転送不要、予備番号不要、「もう一方のチャネルを確認して」も不要です。
Coexistence有効化時にMetaは最大6ヶ月分の過去の1対1メッセージ履歴もバックフィルするため、API側が空のインボックスから始まることはありません。
Coexistenceの要件
要件リストを見ると、この機能のターゲットユーザー像が明確になります：
1. 承認済みのCloud API連携。 WhatsAppビジネスアカウントがMetaのオンボーディングフローを通じてCloud APIに接続されている必要があります——直接接続またはBSP（ビジネスソリューションプロバイダー）経由。ビジネス認証の完了、Meta Business Portfolioの設定、Meta Developer Consoleでのwebhookエンドポイント設定が必要です。
2. 正しいビジネスアプリバージョン。 WhatsAppビジネスアプリ2.24.17以降。旧バージョンは同期プロトコルに対応していません。
3. ウォームアップ期間。 Coexistence有効化前に、電話番号がビジネスアプリ上で最低7日間アクティブに使用されている必要があります。Metaは安定した同期のために1〜2ヶ月の継続使用を推奨しています。新規番号を登録してすぐに両方を有効化することはできません。
4. 14日間のハートビート。 Coexistence有効化後、最低14日に1回はビジネスアプリを開く必要があります。アプリが休眠状態になると、同期がサイレントに中断——APIメッセージは引き続き到着しますが、アプリ側は暗くなります。誰かがアプリを再度開くまで、営業チームはメッセージを確認できません。
5. BSPインフラ（ほとんどの構成で）。 MetaのCloud APIに直接統合しない限り（ほとんどの小規模チームはしません）、BSP経由での接続になります。プラットフォーム料金（$29〜$500+/月）、メッセージごとのマークアップ（通常15〜20%）、テンプレート管理のオーバーヘッドが発生します。
Coexistenceに適した3つのチームタイプ
すべてのWhatsApp構成が両端運用から恩恵を受けるわけではありません。Coexistenceは特定のプロファイルに適しています：
チームA：営業はスマホ、サポートは自動化。 フィールド営業がビジネスアプリから返信し、バックエンドシステムが注文確認とルーティングを処理。両方が同じ会話ビューを必要とする。Coexistenceはこれを直接解決します。
チームB：ビジネスアプリからCloud APIへ移行中。 ビジネスアプリで始めて、段階的にAPI自動化を追加しているチーム。Coexistenceなら移行期間中に番号をポーティングせず、アプリ側のワークフローを失わずに両方を運用できます。
チームC：コンプライアンスで人的チェックが必須。 規制により自動メッセージ送信前に人的レビューが必要。アプリ側がレビュー画面、API側が自動化を提供。
適さないチームタイプ
MetaのCoexistenceドキュメントに載っていない第4のプロファイルがあります：メッセージを受信するだけのチームです。
このチームはマーケティングブロードキャストを送らず、テンプレートメッセージを使わず、ビジネスアプリの手動返信インターフェースも不要です——サポートキューはすでにチケットシステム、CRM、またはAIエージェントパイプラインで処理されているからです。WhatsAppから必要なのはインバウンドメッセージだけ——ルーティング・記録・処理可能な構造化イベントとして届けられること。
このチームにとって、Coexistenceは使わない機能の両側にインフラを追加します：
- Cloud API側： ビジネス認証、Meta Developer Console、webhook設定、BSP契約、メッセージごとの課金（サービス会話は無料でも、遅延返信はテンプレート課金に——7月料金分析参照）
- ビジネスアプリ側： 14日ハートビート要件、アプリバージョン管理、ウォームアップ期間、チーム内の誰かがスマホをアクティブに保つ必要
両側間の同期がこの機能のコアです。どちらの側も必要なければ、同期はオーバーヘッドです。
両方をスキップするパス
UnifyPortの非公式インターフェースは通常のWhatsAppアカウントを接続——ビジネス認証不要、Cloud API承認不要、BSP不要——すべてのインバウンドメッセージを正規化されたwebhookイベントとして配信します：
{
"event": "message.received",
"account_id": "acct_7kQnWx",
"provider": "whatsapp",
"from": "user_d4f29a",
"text": "シンガポールへの発送はできますか？",
"timestamp": 1751270400,
"message_id": "wa_msg_8b3e71"
}バックエンドがsigning_secretでHMAC-SHA256署名を検証し、メッセージを既存のキューにルーティングします。ビジネスアプリを維持する必要なし、Cloud APIの設定不要、14日ハートビートの維持不要、BSPマークアップが意図しないテンプレート課金に複利する心配もなし。
返信はPOST /v1/messages——単一エンドポイント、テンプレート分類なし、会話ウィンドウ課金なし。同じwebhookエンドポイントがTelegram、LINE、TikTok、Zalo、Xからのメッセージも同一のmessage.receivedスキーマで受信します。LINEが主流の日本市場でも、既存のマルチプラットフォーム構成にWhatsAppを追加しても新しい課金モデルは増えません——payloadにprovider値が一つ増えるだけです。
判断マトリクス
| 要件 | Coexistence | UnifyPort |
|---|---|---|
| ビジネス認証 | 必須 | 不要 |
| BSP契約 | 通常必要 | 不要 |
| スマホアプリを14日ごとにアクティブ | 必須 | 不要 |
| アウトバウンドマーケティングテンプレート | 対応 | ユースケース外 |
| インバウンドメッセージwebhook | あり（Cloud API側） | あり |
| マルチプラットフォーム（Telegram、LINEなど） | 個別統合が必要 | 同一webhook |
| メッセージごとの課金 | Meta料金 + BSPマークアップ | なし |
| セットアップ時間 | 数日〜数週間（認証プロセス） | 数時間 |
あなたのシナリオはどちら
アウトバウンドキャンペーンを送る、フィールド営業にビジネスアプリが必要、または既存のビジネスアプリワークフローをAPI自動化に移行中——であればCoexistenceは待望の機能です。WhatsAppインフラの実際のギャップを解決します。
メッセージを受信し、キューにルーティングし、既存システムで返信する——であれば問題は「Coexistenceを有効にすべきか」ではなく「Coexistenceが接続するインフラが必要か」です。インバウンド専用ワークフローなら、答えは：どちら側も不要かもしれません。
完全なAPIリファレンスとwebhookドキュメント：unifyport.ai/docs。