WhatsApp Cloud API と Coexistence：番号に必要なのはどちらか

Cloud API と Coexistence は、本当に別のものですか？

いいえ。この捉え方が混乱を招きます。Cloud API は Meta がホストする WhatsApp Business Platform です。Coexistence は同じ API に番号を接続するオンボーディング方式で、その後も WhatsApp Business アプリを番号で使えるようにします。

つまり、エンドポイントは同じで、メッセージ形式も同じです。テンプレートの動作も同じで、24 時間のウィンドウも同じように適用されます。一方に合わせて書いたものは、もう一方でも動作します。

異なるのは電話側の扱いです。通常の方法で番号をオンボーディングすると、その番号では Business アプリが使えなくなります。番号はソフトウェア専用になり、これまで応答していた人は構築された仕組みから応答する必要があります。Coexistence なら両方の画面が有効になり、それぞれが相手の送信内容を確認できます。

通常の Cloud API を選ぶ方がよいのは、どんな場合ですか？

その番号で人が手動対応する必要がない場合です。これは思っているより一般的です。

注文の更新だけを送る通知用番号なら、人による対応を残す必要はありません。連携専用に新しく取得した番号なら、そもそも誰かのアプリで使われていたこともありません。ヘルプデスクですでに運用している大規模なサポート窓口なら、人の対応フローは完全に別の場所にあります。そこへ WhatsApp Business アプリを戻すと、運用が分断されます。

このような場合、Coexistence は不要な制約を加えます。Coexistence の番号では、処理量が品質評価やメッセージングティアに応じて拡大せず、Meta がスループットを固定します。また、定期的な端末アクティビティも必要になります。メリットがないまま、保守の負担だけを引き受けることになります。

Coexistence しか機能しないのは、どんな場合ですか？

その番号がすでに企業で使われていて、すでに人が応答している場合です。

これは多くの小規模企業に当てはまり、代理店が引き継ぐ番号ならほぼすべてに当てはまります。番号は車両、店舗、請求書、ウェブサイトに掲載されています。日中は誰かが電話から応答し、常連客の名前も把握しています。その人にアプリが使えなくなると伝えれば、話はそこで終わります。そのため、多くの企業が公式 API ではなく非公式ゲートウェイを利用していました。

Coexistence はこのトレードオフをなくします。アプリは使い続けられ、チームに新しい操作を覚えてもらう必要もありません。ソフトウェアは、通常の方法で得られるものと同じ API を利用できます。

後から 2 つの方式の間で番号を移動できますか？

番号は切断して再接続できるため、想像されるほど取り返しのつかない決定ではありません。ただし、チャット履歴の共有設定は永久に固定されます。

番号を最初に Coexistence で接続すると、Meta は既存の会話を API と共有するか尋ねます。これはオンボーディング時に一度だけ行う選択で、後から変更できません。拒否した後で履歴が必要になった場合は、切断して再接続するしかありません。

慎重に決めるべきなのは、どの方式でオンボーディングするかではありません。その日に履歴の共有を許可するかどうかです。後からやり直せないのは、その選択だからです。

よくある間違い

• Coexistence を下位の API と考えること。実際は同じ Cloud API で、オンボーディング方法と同じエンドポイント、同じルールを使います。
• 誰も手動対応しない番号に Coexistence を選ぶこと。存在しない電話対応のために、端末アクティビティの義務と固定スループット上限が加わります。
• オンボーディング時にチャット履歴を拒否し、後から追加できると考えること。この選択は一度だけで、変更できません。

よくある質問

続きを読む