# EasyCoexistence: 日本語 (ja) EasyCoexistence is an independent Meta Tech Provider. It is not a Meta product and is not affiliated with or endorsed by Meta. Product documentation (English): https://easycoexistence.com/llms-full.txt ## Claude、ChatGPT、Cursor向け WhatsApp MCP サーバー https://easycoexistence.com/ja/whatsapp-mcp-server MCP サーバーを使うと、AI アシスタントから WhatsApp を直接操作できます。番号の一覧表示、メッセージやテンプレートの送信、接続状態の確認、Webhook の接続先設定が可能です。EasyCoexistence は Meta の公式 Cloud API 上で MCP サーバーを提供するため、顧客がすでにメッセージを送っている番号を公式のまま利用でき、BAN のリスクもありません。 ### WhatsApp MCP サーバーとは何ですか？ MCP（Model Context Protocol）は、AI アシスタントが自分では所有していないツールにアクセスするための仕組みです。コネクタを一度追加すれば、間に接着用コードを書くことなく、自然な言葉でアシスタントに代わりにツールを呼び出させることができます。 WhatsApp MCP サーバーは、WhatsApp 番号をそのようなツールの 1 つとして公開します。API に対する認証、ペイロードの作成、レスポンスの処理を行うスクリプトを書く代わりに、「この顧客にメッセージを送って」「注文状況の更新用テンプレートを作って」「この番号の接続状態を教えて」と依頼できます。呼び出しはアシスタントが実行します。 重要なのは、どの WhatsApp に接続するかです。同じ名前で呼ばれるものが 2 つあり、その違いによって顧客の番号を維持できるかどうかが決まります。 ### なぜ多くの WhatsApp MCP サーバーで番号が BAN されるのですか？ 現在インストールできる WhatsApp MCP サーバーのほとんどは、WhatsApp Web を操作する仕組みです。ブラウザクライアントと同じようにリンク端末としてサインインし、そのセッションを自動操作します。 これは WhatsApp の規約に違反します。規約では、個人向けクライアントの自動利用や大量利用が禁止されており、リンク端末も個人向けクライアントです。その方法で使う番号は BAN される可能性があります。また、BAN 防止をうたっていても、ベンダーが管理できない事象です。 個人用の番号なら不便で済むかもしれません。しかし、顧客がすでにメッセージを送っている番号にとっては、事業そのものに関わります。 EasyCoexistence のコネクタは、この方法を使いません。Meta 公式の Coexistence 機能を通じてオンボーディングされた番号に対し、Meta の公式 Cloud API を呼び出します。リンク端末も、失うセッションもありません。 ### AI は実際に何ができますか？ 実際に求められる操作に対応する 16 個のツールを利用できます。 読み取りでは、アカウント上の番号一覧、番号の接続状態、品質評価、メッセージングティアを確認できます。必要に応じて、別の場所で使うための API 認証情報も読み取れます。 送信では、24 時間のセッション内でメッセージを送信できます。番号に登録されたテンプレートの一覧表示、新しいテンプレートの作成、Meta に承認されたかどうかの確認、承認済みテンプレートの送信による期間外の会話開始も可能です。 接続設定では、Webhook の送信先を設定し、受信メッセージを Meta から自分のサーバーへ直接ルーティングできます。また、接続を開始すると、顧客が自分の番号を接続するために開くリンクが返されます。さらにドキュメント用のツールもあり、アシスタントは推測せずに仕組みを調べられます。 最後の 2 つが、単なるチャットのおもちゃ以上の価値を生みます。エージェントは、人がダッシュボードを開かなくても番号をオンボーディングし、自分のシステムを接続できます。 Partner API：自社のソフトウェアから顧客が自分の番号を接続できるようにする場合は、さらに 5 個のツールでホスト型の接続リンクを設定します。設定状況の確認、API キーの作成と取り消し、ステータスイベントを受け取る URL の設定、顧客 1 社ごとの接続リンクの作成ができます。 ### 企業はスマートフォンのアプリを使い続けられますか？ はい。それこそ、企業がすでに使っている番号でこの仕組みを利用できる理由です。 Coexistence は、WhatsApp Business アプリと Cloud API を 1 つの番号で同時に動かすための Meta 公式モードです。チームはこれまでどおり、同じチャット、同じ履歴、同じ端末から応答できます。その間も API は同じ回線で送受信します。API が送信した内容はアプリに表示され、チームがアプリで入力した内容は API から確認できます。 つまり、エージェントが誰かに置き換わるわけではありません。対応できるときはエージェントが答え、必要なときは人がスマートフォンで同じスレッドを引き継ぎます。どちらも相手の存在を意識する必要はありません。 1. Connect the number: Sign up, then run Meta's Embedded Signup and scan the code from the WhatsApp Business app. About two minutes, and nothing about the app changes. 2. Add the connector: In Claude, ChatGPT, Cursor or Claude Code, add a custom connector pointing at https://easycoexistence.com/api/mcp and sign in. OAuth, so no key is pasted anywhere. 3. Ask for something: "Which of my numbers is unhealthy?" or "Send Sarah the booking confirmation." The assistant picks the tool and makes the call. - 24 時間のセッション外で通常のテキストを送信すること。期間外は承認済みテンプレートしか送れないため、send_message しか知らないエージェントは 25 時間目から応答できなくなります。 - グループチャットを期待すること。すべてのプロバイダーで、Coexistence 番号は groups API の対象外です。 - Meta の GET ハンドシェイクに応答できない URL を Webhook の送信先に設定すること。Meta は配信前にエンドポイントを確認するため、無反応な 404 は最初のメッセージが届かないまで正常な設定と同じように見えます。 **この仕組みが原因で顧客の番号が BAN される可能性はありますか？** いいえ。Meta の公式 Cloud API を、Meta 独自の Coexistence 機能を通じて利用します。BAN のリスクが語られるのは、リンク端末としてサインインする非公式ゲートウェイによるもので、これはまったく別の仕組みです。 **このコネクタはどのアシスタントで使えますか？** OAuth を使った HTTP 経由の MCP に対応するものであれば利用できます。現在は Claude、ChatGPT、Cursor、Claude Code、Codex に対応しています。リモートのエンドポイントは 1 つだけなので、お使いのマシンでは何も実行されません。 **会話は御社のサーバーを経由しますか？** いいえ。受信メッセージは Meta から指定した Webhook へ直接ルーティングされ、当社が会話内容を保存することはありません。接続の監視に必要なアカウントと電話番号の状態だけを保持します。 **1 つのコネクタを複数の顧客に使えますか？** はい。1 つのアカウントに必要な数だけ番号を登録でき、各番号は個別の接続として請求されます。コネクタにはすべての番号が表示され、サポートする企業での利用に制限はありません。 --- ## WhatsApp Coexistence：1つの番号でアプリと API を併用 https://easycoexistence.com/ja/whatsapp-coexistence Coexistence は、1つの番号で WhatsApp Business アプリと Cloud API を同時に使う Meta 公式のモードです。チームは同じ電話から、同じチャットと履歴を使って回答を続けられ、その間ソフトウェアは同じ番号で送受信できます。移行は発生せず、番号も変わりません。 ### Coexistence は実際にどのような問題を解決しますか？ Coexistence が登場する前は、企業の番号を WhatsApp API に接続すると、アプリを手放す必要がありました。番号は移行され、電話は WhatsApp クライアントとして使えなくなり、日中ずっと顧客に回答していた担当者は、購入したソフトウェア経由で対応しなければなりませんでした。多くの小規模チームはその代償を受け入れられず、自動化を始めることもありませんでした。 Coexistence はこの代償をなくします。アプリはこれまでどおり動作します。同じ担当者が同じ電話から回答し、同じ会話を見られるため、新しい操作を覚える必要もありません。同時に API が同じ番号に接続され、送受信や他のシステムとの連携が可能になります。 つまり、電話を手放すかどうかではなく、ソフトウェアに何を任せるかが問題になります。必要なときは、担当者が同じ会話を引き継げます。 ### 接続後、電話では何が変わりますか？ ほとんど何も変わりません。それが Coexistence の目的です。アプリは同じように開き、連絡先リストも同じで、以前の会話もすべて残ります。新しい場所でサインインする必要はありません。 変わるのは、電話からは見えにくい部分です。API が送信したメッセージはアプリの会話スレッドに表示されるため、回答する担当者は一部ではなく全体を確認できます。アプリで入力したメッセージは API からも確認できるため、担当者がすでに回答した後にソフトウェアが重ねて返信することもありません。 番号を初めて接続すると、Meta はおよそ 6 か月分の履歴を同期します。そのため API が何もない状態から始まることはありません。最初に知っておきたい制限は 2 つあります。Coexistence の番号では、どのプロバイダーでもグループチャットは API の対象外です。また、番号を WhatsApp の一般向けアプリで使うことはできず、Business アプリのみ利用できます。 ### Coexistence は誰に向いていますか？ 主に 2 つのグループが対象で、Coexistence に求めるものはそれぞれ異なります。 1つの番号を少人数で使う企業は、電話を使い続けながら、確認やリマインダー、営業時間外の最初の返信といった定型作業を自動化したいと考えます。誰かを置き換えるためにソフトウェアを導入するのではありません。夜の時間を取り戻すために導入します。 代理店、コンサルティング会社、開発者は反対の立場です。複数の企業を支援し、それぞれ移行や変更ができない番号を持っています。そして、構築したシステムからその番号にアクセスできる必要があります。顧客のスタッフが手動で回答し続ける番号に API を接続する公式の方法は、Coexistence だけです。 どちらにも共通して必要なのは、接続を維持し、問題が起きたときに誰かが気づくことです。 ### Coexistence の接続に監視が必要なのはなぜですか？ 誰にも通知されないまま、動作しなくなることがあるためです。 番号には品質評価とメッセージングティアがあり、Meta は受信者の反応に応じて調整します。評価は下がり、ティアは変わります。アクセストークンは期限切れになります。応答しなくなった Webhook の送信先は、永遠に再試行されるわけではありません。これらは電話にアラートを表示せず、アプリも通常どおり動作し続けるため、最初の兆候は顧客からの「メッセージが届いていない」という連絡になりがちです。 また Meta には、API のアクティビティが 14 日間ない接続には対応が必要になるルールがあります。隠された不公平な仕組みではありませんが、見過ごしやすい点です。 EasyCoexistence はここを監視します。接続を継続的に確認し、変化があれば顧客からではなく私たちからお知らせします。 1. Sign up: Create an account and add a card. The first 3 days are free, and nothing is charged until they end. 2. Run Embedded Signup: Meta's own flow opens, you pick the number, and you scan a code from the WhatsApp Business app. About two minutes. 3. Point it somewhere: Set the webhook destination to your own system, or add the MCP connector and let an assistant do it. The app on the phone carries on as before. - WhatsApp の一般向けアプリにある番号を接続しようとすること。Coexistence には Business アプリが必要で、先に番号を移す必要があります。 - グループチャットも届くと思い込むこと。どのプロバイダーでも Coexistence の番号では API の対象外なので、グループを前提にした仕組みは動きません。 - 顧客の最後のメッセージから 24 時間を超えてフリーテキストで返信すること。その時間を過ぎると、承認済みのメッセージテンプレートのみ送信できます。 - Meta の認証リクエストに応答できない URL を Webhook の送信先にしたままにすること。Meta は配信前にエンドポイントを確認するため、応答がない場合は正常な設定と同じように見えます。 **チームは電話の利用をやめる必要がありますか？** いいえ。それが Coexistence の目的です。WhatsApp Business アプリは同じ番号で、同じ会話を使って動作し続け、API も並行して動作します。 **既存の会話は失われますか？** いいえ。会話はアプリに残り、番号の接続時に Meta が約 6 か月分の履歴を API と同期します。そのため、ソフトウェアも文脈を把握した状態で始められます。 **元に戻せますか？** はい。番号の接続を解除できます。アプリはこれまでどおり動作し、接続によって番号自体が恒久的に変更されることもありません。 **これは非公式の WhatsApp API と同じですか？** いいえ。その違いが番号を維持できるかどうかを左右します。Coexistence は Cloud API 上の Meta 公式機能です。非公式ゲートウェイは WhatsApp Web をリンク済みデバイスとして操作するため、規約違反となり、番号が利用停止になる可能性があります。 --- ## 非公式 WhatsApp API で実際に番号が停止される理由 https://easycoexistence.com/ja/unofficial-whatsapp-api-risks 非公式 WhatsApp API は、リンク済みデバイスとしてサインインし、WhatsApp Web のセッションを自動化して動作します。これは WhatsApp の規約違反であり、Meta がそのパターンを検知すると、番号が停止されます。公式の Cloud API は、企業がすでに使っている番号上で、Meta がサポートするインターフェースを通じて同じ処理を行います。 ### 非公式 WhatsApp API はどのように動作しますか？ マーケティング上の説明が何であれ、内部ではどれも同じことを行います。WhatsApp Web が使うプロトコルを開き、アカウントにリンク済みデバイスとしてペアリングし、そのセッションをプログラムから操作します。ライブラリはソケットから受信メッセージを読み取り、送信メッセージを同じ経路で送り返します。 これが、安価で、数分でインストールでき、公式 API が公開していない機能にもアクセスできる理由です。申請するアカウントも審査もありません。コードをスキャンすれば、すぐに送信できます。 同時に、これが番号を危険にさらす理由でもあります。そのセッションは Meta の承認を受けていません。WhatsApp の規約は、一般ユーザー向けクライアントの自動利用や大量利用を禁止しており、リンク済みデバイスもそのクライアントに当たります。利便性とリスクは、同じ事実を別の側面から見たものです。 ### Meta は実際にどのように検知しますか？ ライブラリ名を探すわけではありません。多くの人がそう思うため、書き換えれば助かると考えてしまいます。検知は挙動に基づき、通信のパターンを監視します。 シグナルは、自動化によって自然に生じるものです。送信メッセージと受信した返信の比率です。実際の会話はおおむね釣り合いますが、一斉送信は釣り合いません。連絡先グラフ上の距離も見られます。自分に連絡したことがなく、共通の連絡先もない相手に書き込む動きは、通常の利用とは大きく異なります。人間は一定間隔で送信しないため、送信タイミングの規則性も対象です。受信者からの報告は重く評価され、最も早く届くシグナルです。 そのため、1 年間稼働しているゲートウェイも安全の証拠にはなりません。通信がまだしきい値を超えていないというだけです。そのしきい値は、どのライブラリがメッセージを送るかには左右されません。 ### 番号が停止されると、実際に何を失いますか？ 自動化に見合う価値をはるかに超える損失です。ここが過小評価されがちな点です。 動かなくなるのは自動化ではなく、番号です。その番号でのすべての会話にアクセスできなくなり、会話中の顧客は何が起きたのか知ることもありません。ただ返信が来なくなります。車両、店舗、名刺、または過去数千件の請求書に番号を印刷している企業にとって、番号はソフトウェアの一部というより電話回線に近いものです。 履歴も失われます。スレッド内で蓄積した連絡先リストも同様です。異議申し立ては可能で、うまくいくこともありますが、時間がかかり、結果を保証できる人はいません。 代理店の場合は計算がさらに厳しくなります。動かなくなる番号は、仕組みについて知らされていなかった顧客のものだからです。 ### 代わりに公式ルートを使うと、どうなりますか？ 以前は、公式 API への反対意見にも根拠がありました。番号の移行が必要で、電話上の WhatsApp Business アプリが使えなくなったため、小規模チームには受け入れにくいものでした。 Coexistence によって、その問題は解消されました。これは、同じ番号で Business アプリと Cloud API を同時に動かす Meta 独自のモードです。チームは電話から回答し続けられ、チャットと履歴もそのまま残り、API は同じ回線に接続されます。リンク済みデバイスも、サーバー上で保持するセッションも、盗まれる価値のある認証情報もありません。 制約はありますが、大きなものではありません。フリーテキストが使えるのは顧客の最後のメッセージから 24 時間以内で、テンプレートには承認が必要です。また、グループチャットは利用できません。その代わり、仕組み自体を理由に番号が停止されることはありません。 - アンチバン保護をうたうライブラリなら問題を解決したと信じること。検知が監視するのは通信の挙動であり、送信に使うコードではありません。その主張は、ベンダーが制御できないことを説明しているにすぎません。 - 数か月間の稼働を安全の証拠とみなすこと。通信がまだしきい値を超えていないというだけで、別の意味の説明です。 - 最初に個人番号で試すこと。そこで停止されると困りますが、はるかに多くの通信を担う企業番号については何も学べません。 - 共有サーバーに非公式のセッションを保存すること。その認証情報はアカウントへの完全なアクセス権を与え、既知の標的になります。 **このような API を使っている場合、すでに番号は危険ですか？** セッションが動作している間は、常にリスクがあります。一定の日付に発動するものではないため、長期間稼働していても安心材料にはなりません。同じ番号のまま公式 API に移行することは可能で、アプリも失いません。 **番号を変えずに公式 API へ移行できますか？** はい。Coexistence は現在使っている番号に接続し、WhatsApp Business アプリも電話上でそのまま動作します。移行作業はありません。 **公式 API でできないことは何ですか？** Coexistence 番号ではグループチャットを利用できません。フリーテキストが使えるのは顧客の最後のメッセージから 24 時間以内で、その時間を過ぎると Meta が承認したテンプレートを使う必要があります。 **公式ルートのほうが高くなりますか？** Meta のメッセージング料金はどちらの方法でも発生し、直接お客様に請求されます。違いは、番号を失うリスクではなく、番号ごとの固定月額料金です。 --- ## 公式 Cloud APIでWhatsAppをn8nに接続 https://easycoexistence.com/ja/integrations/n8n Webhookの送信先をn8n Webhookノードに指定すると、その番号へのすべてのメッセージがワークフローのトリガーとして届きます。返信は Cloud API経由、またはn8nがOAuth2対応のMCP Client Toolから接続できるMCPサーバー経由で送信できます。電話もそのまま使えます。 ### WhatsAppのメッセージはどのようにn8nのワークフローへ届きますか？ Metaは、その番号に送られたすべてのメッセージを、指定した1つのURLへHTTP POSTで配信します。このURLが統合全体です。本番用URLにn8n Webhookノードを置き、番号のWebhook送信先として設定すると、受信メッセージごとにワークフローが実行されます。 ペイロードには、送信者、テキストまたはメディアの参照先、タイムスタンプ、メッセージIDが含まれます。その後は通常のn8nワークフローです。内容で分岐し、顧客を検索し、必要な処理を呼び出して、返信するかどうかを決めます。 これはCoexistenceなので、同じメッセージが電話のWhatsApp Business アプリにも表示されます。人が返信することもできます。ワークフローは人が送った内容を確認でき、人もワークフローが送った内容を確認できるため、互いの返信に重ねて返信することがありません。 ### ワークフローから返信を送るにはどうしますか？ 番号のphone number idとアクセストークンを使い、Cloud APIに対してHTTP Requestノードから送信します。どちらもダッシュボードから確認できます。必要であれば、MCPコネクター経由でアシスタントに取得させることもできます。 送信内容はタイミングによって異なります。ここが見落とされやすい点です。顧客の最後のメッセージから24時間以内なら自由文を使え、返信はワークフローが作成した内容になります。その時間を過ぎると、Metaがすでに承認したメッセージテンプレートだけが送信できます。自由文しか送らないワークフローは、メッセージの数秒後に行うテストでは問題なく見えます。しかし、実際に一晩空いたケースで初めて停止します。 確実な構成は分岐です。最後の受信メッセージからの経過時間を確認し、自由文かメッセージテンプレートかを選択します。 ### n8nではMCPコネクターも使えますか？ はい。この点でn8nは特殊です。MCP Client ToolノードからリモートMCPサーバーへ接続でき、OAuth2にも対応しています。これは当社のMCPサーバーに必要な機能なので、ワークフロー内のAI Agentノードから当社のツールを直接呼び出せます。 これは重要な点です。ほとんどの自動化プラットフォームは対応していません。MakeとZapierはどちらも独自のMCPサーバーを実行しますが、MCPクライアントとしては動作しないため、第三者のサーバーへ接続できません。n8nなら接続できます。 MCPが適しているのは、実行中のワークフローでエージェントノードがメッセージ送信、番号の接続状態確認、メッセージテンプレートの承認状況の取得などを判断して実行する部分です。Webhookの代わりにはできません。MCPには受信メッセージで呼び起こされる仕組みがないためです。 ### ワークフローではどちらを使うべきですか？ 役割が異なるため、両方を使います。これは好みの問題ではありません。 Webhookは、処理を開始する方法です。顧客が書き込み、MetaがWebhookノードへ配信し、ワークフローが実行されます。どのツールにもMCPで同じことをする仕組みはありません。MCPは、呼び出しを受けるものではなく、リクエストとレスポンスのプロトコルだからです。 MCP Client Toolは、ワークフロー内のエージェントが、呼び出しをハードコードせずに処理を実行するためのものです。送信内容がすでに決まっているなら、Cloud APIに対するHTTP Requestノードのほうが簡単で、問題も起きにくくなります。エージェントが判断するなら、コネクターから16個のツールと各ツールの説明に含まれるルールを利用できます。24時間の時間枠もその一つです。 ### これは、すでに使われているn8nのWhatsAppノードと何が違いますか？ 一般に見かけるn8nのWhatsApp構成の多くは、リンク済みデバイスとしてログインする非公式ゲートウェイを使っています。始めるのは簡単ですが、その仕組みはWhatsAppの規約に反しており、Metaはライブラリではなく通信パターンを検出するため、番号を危険にさらします。 もう一つの一般的な方法は、Coexistenceなしで公式APIを使うことです。動作しますが、番号を移行する必要があります。WhatsApp Business アプリはその番号で使えなくなり、一日中対応していたチームは新しいツールへ移行しなければなりません。多くの小規模企業にとって現実的ではないため、最初から非公式ゲートウェイを選ぶ企業が多くなりました。 Coexistenceは、これまで欠けていた組み合わせです。公式APIを使いながら、電話も使い続けられます。 - n8nのテスト用URLをWebhook送信先に使うこと。エディターを閉じると待ち受けが停止するため、メッセージはどこにも配信されません。 - Metaの認証リクエストに応答しないこと。Metaは配信前にチャレンジ付きのGETを送信します。ノードがその内容を返さなければ、メッセージを受信できません。 - 24時間の時間枠を過ぎて自由文で返信すること。ワークフロー上は静かに失敗し、承認済みのメッセージテンプレートだけが送信されます。 **このためにn8nの専用ノードが必要ですか？** いいえ。Webhookノードで受信し、HTTP Requestノードで送信します。統合はURLとREST呼び出しで構成されるため、インストールは不要です。 **チームは電話から引き続き返信できますか？** はい。それがCoexistenceの意味です。同じ番号のWhatsApp Business アプリが使い続けられ、ワークフローと人の双方が互いのメッセージを確認できます。 **1つのワークフローで複数の顧客の番号を処理できますか？** はい。すべての番号を同じWebhookに指定し、ペイロードの受信側phone number idで分岐します。1つのアカウントで必要な数の番号を保持できます。 **n8nのインスタンスが停止したらどうなりますか？** Metaは一定期間配信を再試行し、その後停止します。メッセージは電話のWhatsApp Business アプリには届くため、企業にとって失われることはありません。ただし、ワークフローでは受信できません。 --- ## カスタムコネクタで WhatsApp を Claude に接続 https://easycoexistence.com/ja/integrations/claude Claude に https://easycoexistence.com/api/mcp をカスタムコネクタとして追加し、サインインしてください。Meta の公式 Cloud API 上で、Claude から番号の一覧表示、接続状態の確認、メッセージやテンプレートの送信、Webhook の送信先指定ができます。リンク済みデバイスのセッションは使用しません。 ### Claude に追加する方法を教えてください Claude で設定を開き、EasyCoexistence MCP エンドポイントを指定したカスタムコネクタを追加します。Claude がサインインページを開くので認証すると、ツールが表示されます。OAuth を使用するため、キーの生成も設定ファイルへの貼り付けも必要ありません。 Claude Desktop でも同じコネクタを使用できます。「設定」の「コネクタ」から追加してください。設定ファイルには Claude Desktop 自身が起動するローカルサーバーだけを記述するため、このようなリモートエンドポイントは記述しません。 どちらの場合も、サーバー自体はリモートです。インストールは不要で、ノートパソコンのバックグラウンドで何かが実行されることもありません。アプリを閉じても接続は切れません。Claude が開いているかどうかにかかわらず、番号は接続されたままです。 ### 接続後、Claude で何ができますか 自然な言葉で依頼すると、Claude がツールを選択します。「どの番号の接続状態が悪いですか」「この顧客に予約確認を送ってください」「注文更新用のテンプレートを作成し、Meta の承認時に知らせてください」「この番号の Webhook を自分のサーバーに向けてください」といった依頼が可能です。 日常的によく使う読み取りツールには、番号の一覧表示、品質評価、メッセージング階層、接続状態の確認、別の処理で必要な認証情報の取得があります。送信ツールでは、時間枠内のフリーテキストと、その外側での承認済みテンプレートを扱えます。 顧客にサービスを提供する場合、特に重要なのは接続の開始と Webhook の送信先設定です。Claude から顧客の番号をオンボーディングし、ダッシュボードを開かずにシステムへ接続できます。 ### この方法で番号が停止される心配はありませんか はい。理由は Claude ではなく、その下で使われる仕組みにあります。 通常見つかる WhatsApp MCP サーバーは、WhatsApp Web をリンク済みデバイスとして操作します。これは WhatsApp の規約に違反し、Meta は通信挙動から検出するため、どのアシスタントが指示したかにかかわらず番号が停止されます。慎重なアシスタントを使っても、禁止されている仕組み自体は変わりません。 このコネクタは、Meta 独自の Coexistence 機能でオンボーディングした番号に対して、Meta の公式 Cloud API を呼び出します。リンク済みデバイスも、どこかに保持されるセッションもなく、規約違反にもなりません。代わりに通常の制限が適用されます。顧客の最後のメッセージから 24 時間以内はフリーテキスト、それ以外は承認済みテンプレートのみ送信でき、グループチャットには対応しません。 **Claude Code と Claude アプリで使えますか？** はい。OAuth 対応の HTTP 経由リモート MCP サーバーなので、カスタムコネクタをサポートするサービスで利用できます。Claude Code、ChatGPT、Cursor にも対応しています。 **Claude は顧客との会話を見ますか？** 依頼した内容だけです。受信メッセージは Meta から指定した Webhook の送信先へ送られ、会話内容を保存することはありません。 **Claude は新しい番号を自動で接続できますか？** 手続きを開始できます。コネクタがリンクを返すので、企業の所有者が開き、Meta のフローを通じて自分の番号を認証します。この手順を完了できるのは所有者だけです。 **時間枠外に Claude が送信しようとするとどうなりますか？** Cloud API が拒否し、Claude にエラーが表示されるため、承認済みテンプレートに切り替えられます。何も通知なく破棄されることはありません。 --- ## WhatsApp Cloud API と Coexistence：番号に必要なのはどちらか https://easycoexistence.com/ja/whatsapp-cloud-api-vs-coexistence Coexistence は Cloud API の代替ではなく、Cloud API へのオンボーディング方法です。通常の Cloud API の番号はソフトウェア専用です。Coexistence の番号では API と WhatsApp Business アプリを同時に使えるため、チームは電話からの応答を続けられます。 ### 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 を選ぶこと。存在しない電話対応のために、端末アクティビティの義務と固定スループット上限が加わります。 - オンボーディング時にチャット履歴を拒否し、後から追加できると考えること。この選択は一度だけで、変更できません。 **Coexistence は通常の Cloud API より遅いですか？** Coexistence の番号では、スループットが品質評価やメッセージングティアに応じて拡大せず、Meta によって固定されます。会話中心の利用では、この上限が問題になることはほとんどありません。ただし、大量送信では問題になる場合があります。 **どちらでもテンプレートは同じように使えますか？** はい。テンプレートは Meta に審査を申請し、API 経由で同じように送信します。Coexistence の番号では電話アプリからテンプレートを送信できないため、24 時間のウィンドウを過ぎたメッセージは API 経由で送る必要があります。 **新しい番号を Coexistence に接続できますか？** まず WhatsApp Business アプリに登録する必要があります。Coexistence は、すでにアプリで使っている番号を接続する仕組みだからです。誰も手動対応しない番号なら、通常の Cloud API のオンボーディングが適しています。 **代理店は顧客の番号にどちらを使いますか？** ほぼ常に Coexistence です。顧客の番号は、スタッフがすでに応答している番号です。移行すると WhatsApp Business アプリが使えなくなるため、同意する顧客はいません。 --- ## WhatsApp エラー 131047：再エンゲージメントメッセージ https://easycoexistence.com/ja/docs/whatsapp-error-131047 エラー 131047 は、顧客の最終メッセージから 24 時間を超えたことを示します。顧客対応ウィンドウが閉じているため、フリーテキストは配信されません。会話を再開できるのは、Meta が事前承認したメッセージテンプレートだけです。 ### エラー 131047 の原因は何ですか？ 顧客からあなたへの最終メッセージが 24 時間より前である場合に、フリーテキストを送信すると発生します。 WhatsApp Business Platform では、企業が顧客対応ウィンドウ内でのみ自由にメッセージを送信できます。このウィンドウは顧客からメッセージを受信した時点で始まり、24 時間続きます。ウィンドウ内なら自由に送信できますが、ウィンドウ外では API がフリーテキストを 131047 で拒否します。受信者が求めていないメッセージを配信しないためです。 テストでは発生せず、本番環境で発生するのはタイミングが原因です。通常、連携のテストではメッセージを送信して数秒後に返信するため、常にウィンドウ内です。初めて一晩空いた場合や、顧客が 1 日静かにしていた場合に、このエラーが表示されます。 ### どうすれば解決できますか？ フリーテキストの代わりに、承認済みのメッセージテンプレートを送信してください。 メッセージテンプレートは、事前に Meta へ提出し、審査を受けるメッセージです。承認されれば、まだ一度もメッセージを送っていない相手にも、いつでも送信できます。送信すると会話が再開し、顧客が返信した時点から新たな 24 時間、フリーテキストを送信できます。 継続的な解決策は再試行ではありません。送信前に、その連絡先から最後にメッセージを受信してからの経過時間を確認する分岐を実装します。24 時間以内ならフリーテキストを送信し、24 時間を超えていれば状況に合うメッセージテンプレートを送信します。フリーテキストしか送れない連携では、このエラーが繰り返され、会話を見ている人にはエラーではなく沈黙に見えてしまいます。 ### Coexistence の番号にも適用されますか？ はい。さらに、知っておくべき影響が 1 つあります。 このウィンドウは、番号が Coexistence でオンボーディングされたかどうかにかかわらず同じように機能します。これはオンボーディング方式ではなく、プラットフォームのルールだからです。異なるのは、対応できる場所です。Coexistence の番号では WhatsApp Business アプリからメッセージテンプレートを送信できないため、ウィンドウ外の送信はすべて API 経由で行う必要があります。 つまり、スマートフォンから対応するチームは進行中の会話には自由に返信できますが、アプリから途切れた会話を再開することはできません。再開には API が必要です。これが、企業がそもそも番号を接続する実務上の理由の 1 つです。 - 同じフリーテキストを再送すること。ウィンドウは自動で再開しないため、再試行しても同じように失敗します。 - ウィンドウを顧客の最終メッセージではなく、自分の最終メッセージから測ること。ウィンドウを開始するのは顧客のメッセージです。 - メッセージテンプレートを作成して即時送信できると思うこと。まず Meta の審査が必要で、通常は数分以内ですが、1 日かかる場合もあります。 **24 時間のウィンドウを延長できますか？** いいえ。Meta が固定しており、どのプロバイダーも延長できません。再開できるのは、顧客が再びメッセージを送った場合だけです。 **顧客がメッセージテンプレートに返信すると再開しますか？** はい。メッセージテンプレートへの返信を含め、顧客からのメッセージは新たな 24 時間を開始します。 **どのメッセージテンプレートカテゴリを使うべきですか？** 取引に関するメッセージには Utility、販促メッセージには marketing を使います。marketing の送信には、自分の WhatsApp Business Account に支払い方法の登録が必要です。 **エラー 131047 は 131049 と同じですか？** いいえ。131047 は閉じたウィンドウを示します。131049 はエコシステムの健全性を守るために Meta が配信を制限するもので、別の状態です。 --- ## WhatsApp エラー 131049：エコシステムの健全性によるメッセージブロック https://easycoexistence.com/ja/docs/whatsapp-error-131049 エラー 131049 は、エコシステム全体で健全な利用を保つために、Meta がこのメッセージを配信しないことを選択したことを示します。24 時間枠の問題でも、テンプレートの問題でもありません。Meta の案内では、その顧客への再送信まで少なくとも 24 時間待つ必要があります。 ### ここでいうエコシステムの利用状況とは何ですか？ 受信者が企業から送られた内容を歓迎しているかどうかを、あなたのアカウントだけでなくプラットフォーム全体で判断する Meta の用語です。 プラットフォームが特定の送信を歓迎されないと判断すると、そのメッセージをブロックして 131049 を返します。これは、あなたが固定のルールに違反したという判断ではなく、メッセージと受信者に関する判断です。そのため、品質評価に問題がないアカウントでも発生することがあります。 特に、反応していない受信者へのマーケティング送信や、似たメッセージを大量に同時送信した場合に発生しやすくなります。電話番号へのペナルティではなく、送信パターンに対するシグナルです。 ### テンプレートを送信しても解決しないのはなぜですか？ テンプレートが問題ではないからです。 送信がブロックされると、別のよくある失敗である 131047 の対策としてテンプレートを使いたくなります。しかし 131047 は時間に関するルールです。時間枠が終了しているため、承認済みのテンプレートで再開します。一方、131049 は特定の相手への特定のメッセージに関する判断であり、テンプレートも同じ配信経路を使います。 テンプレートを使う場合でも使わない場合でも、すぐに再試行すると、発生原因となったパターンを強めることがあります。Meta 自身の案内では、その受信者への再試行まで少なくとも 24 時間待ち、そのメッセージが相手に望まれていたかを確認する必要があります。 ### 再発を防ぐにはどうすればよいですか？ 送信方法ではなく、送信内容を変えてください。 リスト全体ではなく、最近反応した人に送信します。大量にほぼ同じメッセージを送るパターンが監視対象になるため、内容にも変化を持たせます。配信型のプロモーションより、注文や予約など顧客の行動に関連する実用的なメッセージを優先してください。 品質評価とメッセージング階層は、同じ根本原因で変動するため、併せて確認する価値があります。受信者の反応が悪いと、両方に影響します。品質評価が下がり始めると、より深刻な制限の前にこのエラーが増えることが一般的です。早期に変化を捉えれば、調整で済むか、制限を受けるかが変わります。 - 24 時間枠の問題と考え、テンプレートに切り替えること。条件が異なっても、結果は同じです。 - すぐに再試行すること。Meta の案内では、その受信者への再送信まで少なくとも 24 時間待ちます。 - 利用停止だと解釈すること。電話番号は利用でき、今回のメッセージだけが配信されません。 **電話番号は利用停止になっていますか？** いいえ。131049 は 1 件のメッセージをブロックします。電話番号は引き続き利用でき、ほかの送信は成功する可能性があります。 **どのくらい待つ必要がありますか？** Meta の案内では、その受信者への再送信まで少なくとも 24 時間待ちます。正確な時間は公開されていません。 **品質評価に影響しますか？** 同じ根本的な指標からのシグナルです。頻繁に発生する場合は、単独のエラーではなく、品質低下の早期警告として扱う価値があります。 **プロバイダーなら回避できますか？** いいえ。配信時に Meta が適用するため、公式 API を使うすべてのプロバイダーで同じ動作になります。 --- ## WhatsApp エラー 131048：スパム送信制限 https://easycoexistence.com/ja/docs/whatsapp-error-131048 エラー 131048 は、番号の品質が低下したため Meta がその番号からの送信を制限していることを示します。通常は、受信者によるブロックやメッセージの報告が原因です。番号は引き続き機能します。変わったのは、品質が回復するまで送信できる量だけです。 ### 番号の品質が低下する原因は何ですか？ 受信者の反応が悪くなることです。Meta はあなたのコードから推測するのではなく、実際の反応を測定します。 指標になるのは、ブロック、報告、そして返信を期待するメッセージに単に返信しない人の割合です。大量に送信して受信が少ない番号は、会話を続けている番号とは異なる動きを見せます。その差が積み重なり、品質評価になります。 評価は緑、黄、赤の順に変化します。赤になると、このエラーによって送信が失敗し始めます。こうした変化は電話上で通知されず、WhatsApp Business アプリもその間は通常どおり動作します。そのため、多くの企業にとって最初の兆候は警告ではなく、送信の失敗です。 ### 番号はどのように回復しますか？ 品質低下の原因になった送信を止めれば、自然に回復します。 品質は継続的に変化する指標です。最近の送信への反応が良くなると評価が戻り、制限も同時に緩和されます。申立てを提出する必要も、プロバイダが切り替えられる設定もありません。そのため、誰かが修正を販売できるものでもありません。 実際に役立つのは、メッセージを送る相手を絞ることです。最近やり取りした人に送信してください。配信型の宣伝よりも、顧客の行動に結び付いた実用的なメッセージを優先します。個人ではなくリスト全体に送っている内容は削減してください。評価を下げたパターンがそのまま評価を低く保つため、そのパターンを変えることから回復が始まります。 ### 送信が失敗する前に、どうすれば分かりますか？ 評価そのものを監視するしかありません。接続するだけでなく、接続状態を監視すべき理由がここにあります。 Meta は電話番号に品質評価とメッセージングティアを表示しており、送信に影響が出る前に変化します。番号が緑から黄に変わった場合、まだ対処する時間がある警告です。赤になってこのエラーを返し始めた番号は、すでに送信数を失っており、その時点で影響を受けたメッセージはキューに入らず消えています。 変化は WhatsApp Business アプリには表示されません。そのため、電話から対応するチームには、送信が止まる瞬間まで通常どおりに見えます。 - 送信コードのバグだと考えることです。リクエストは正常で、制限されているのは番号です - 回避するためにプロバイダを変更することです。評価は番号に紐付き、番号とともに引き継がれます - 通知を待つことです。電話上で品質低下を知らせるものはありません **メッセージは引き続き受信できますか？** はい。受信には影響せず、その番号の WhatsApp Business アプリも通常どおり動作します。 **回復にはどのくらいかかりますか？** Meta は具体的な期間を公開していません。継続的に変化する指標なので、一定期間の経過ではなく、最近の送信内容が改善すると回復します。 **別のプロバイダに移行するとリセットされますか？** いいえ。品質は送信を行う相手ではなく、電話番号に紐付いています。 **これは利用停止と同じですか？** いいえ。利用停止では番号が使えなくなります。これは、品質が回復するまで、利用中の番号が送信できる量を制限するものです。 --- ## WhatsApp エラー 132001: テンプレートが存在しません https://easycoexistence.com/ja/docs/whatsapp-error-132001 エラー 132001 は、送信しようとしたテンプレートが指定した言語に存在しないか、存在しても未承認であることを示します。テンプレートは名前と言語の組み合わせで識別されるため、別のロケールで同じ名前を使っても別のテンプレートです。 ### 存在するテンプレートでも 132001 が返るのはなぜですか？ ほとんどの場合、原因は言語コードです。 テンプレートは名前と言語の組み合わせで識別されます。en_US で order_update として作成したテンプレートは、en、pt、pt_BR の order_update としては存在しません。正しい名前でもロケールが違えば、このエラーがそのまま発生します。しかも、名前と言語のどちらが間違っているかは、メッセージから判断できません。 もう 1 つの原因は承認状態です。作成済みでも審査中のテンプレートは送信できず、却下されたテンプレートも送信できません。どちらも、まったく作成されていないテンプレートと同じコードを返すため、名前が間違っていると決めつける前に状態を確認してください。 ### 正しい名前と言語はどうやって確認しますか？ 設定内容を信頼するのではなく、その番号のテンプレート一覧を取得して確認してください。 一覧には、正確な名前、正確な言語コード、各テンプレートの審査状態が表示されます。この 3 つを一度に確認できるため、エラーの主な原因をすべて解消できます。テンプレートは作成元が名前を記録した後に編集または却下されることもあるため、一覧が唯一信頼できる情報源です。 MCP コネクタでは API リクエストではなく、質問するだけで確認できます。ある番号で承認済みのテンプレートを尋ねると、アシスタントが一覧を読み取ります。自分のコードからは、接続に使う phone number id と token を指定し、WhatsApp Business Account に対して 1 回の Graph リクエストを送ります。 ### 承認にはどのくらいかかりますか？ 通常は数分ですが、最長で 1 日かかることがあります。 Meta は、すべてのテンプレートを送信前に審査します。多くはすぐに処理されますが、所要時間は保証されず、プロバイダーが早めることもできません。テンプレートを作成してすぐ送信する仕組みでは、審査中の間、送信がこのエラーで失敗するため注意が必要です。 連携の設定時にあらかじめテンプレートを作成し、使用前に状態を確認するのが確実です。コネクタを使うアシスタントなら、テンプレートを送信した後、承認済み、却下、審査中のどれかを報告できます。 - テンプレートが en_US で作成されているのに en を送信する。API 上では別のテンプレートです - テンプレートを作成した同じ処理で送信する。Meta が先に審査します - 却下されたテンプレートが使えると思い込む。存在しない場合と同じく、このエラーが返ります **正確な言語コードはどこで確認できますか？** その番号のテンプレート一覧で確認できます。名前、言語、状態が一緒に表示されるため、ここが唯一信頼できる情報源です。 **審査中のテンプレートは送信できますか？** いいえ。配信できるのは承認済みのテンプレートだけで、審査中のテンプレートを送ると同じエラーが返ります。 **却下されたテンプレートは作り直す必要がありますか？** 編集して再申請できます。ただし、却下状態のまま送信することはできません。 **WhatsApp Business アプリからテンプレートを送信できますか？** Coexistence 番号ではできません。テンプレートは API 経由で送信します。これが、番号を接続する実際的な理由の 1 つです。 --- ## WhatsApp エラー 132000: パラメーター数の不一致 https://easycoexistence.com/ja/docs/whatsapp-error-132000 エラー 132000 は、指定した変数がメッセージテンプレートの定義と一致しない場合に発生します。プレースホルダーが 2 つあるテンプレートには、順番どおりに 2 つの値が必要です。テンプレートを編集した後、送信コードを更新していない場合によく発生します。 ### メッセージテンプレートの変数はどのように数えますか？ テンプレート本文の番号付きプレースホルダーを使い、コンポーネントごとに順番どおり数えます。 「Hello {{1}}, your order {{2}} has shipped」という本文のメッセージテンプレートでは、2 つの変数が定義されています。そのため、送信時には body コンポーネントに正確に 2 つの値を指定する必要があります。1 つまたは 3 つを指定すると、このエラーが返されます。2 つ指定していても、誤ったコンポーネントに指定した場合は同様です。header、body、button のパラメーターは、1 つのリストにまとめず個別に数えるためです。 そのため、最初はエラーの内容が間違っているように見えることがあります。値の合計数が正しくても、コンポーネント間の配分が正しくない場合があるためです。 ### 昨日まで動いていたメッセージテンプレートで、なぜ発生するのですか？ 誰かがメッセージテンプレートを編集した後、送信コードを更新していないことが原因です。 承認後でもメッセージテンプレートは編集でき、プレースホルダーを追加または削除すると、送信側から見た仕様が通知なしに変わります。連携側には警告が表示されないため、次の送信で失敗します。WhatsApp Manager でマーケティング担当者がメッセージテンプレートを編集し、エンジニアリング担当者が送信コードを管理するチームでは、これが最もよくある発生原因です。 対策は、初回作成時に記録した値を信頼するのではなく、メッセージテンプレートを読み取り直すことです。メッセージテンプレートの一覧取得では現在の定義が返されます。送信時に重要なのは、この最新版だけです。 ### 値はどのように正しく指定しますか？ メッセージテンプレート自体の構造に合わせて components 配列を組み立てます。 各コンポーネントには type が指定され、プレースホルダーの出現順に独自の parameters を持たせます。変数が 2 つある本文には、2 つのテキストパラメーターを持つ body コンポーネントが必要です。header にも変数があるメッセージテンプレートでは、header コンポーネントと独自のパラメーターも指定します。header の値を body のリストに追加してはいけません。 MCP コネクターを使う場合、この処理の多くは自動化できます。アシスタントがメッセージテンプレートを読み取り、各コンポーネントのプレースホルダー数を確認して、依頼内容から値を設定します。独自コードでは、変更される可能性のある構造をハードコードせず、起動時にメッセージテンプレートの定義を読み取ると安心です。 - header と body の変数を 1 つのリストにまとめる。変数はコンポーネントごとに数えます - 変数の数をハードコードする。メッセージテンプレートの編集で、送信側への通知なしに変わります - 未使用のプレースホルダーに空文字列を送る。テンプレートには定義が残るため、数を一致させる必要があります **変数のないメッセージテンプレートを送信できますか？** はい。定義されている変数がなければ、パラメーターを送信しません。指定すると、このエラーが返されます。 **値の順番は重要ですか？** はい。プレースホルダーには番号があり、順番に値を設定します。2 つの値を入れ替えるとエラーにはならず、誤ったメッセージになります。 **同じ送信が、ある言語では成功し別の言語では失敗するのはなぜですか？** 言語ごとのバージョンは別々のメッセージテンプレートです。編集後は、プレースホルダーの数が異なる場合があります。 **これは 132001 と同じエラーですか？** いいえ。132001 はメッセージテンプレートが見つからないか、承認されていないことを示します。132000 はメッセージテンプレートが見つかり、変数だけが一致しないことを示します。 --- ## WhatsApp エラー 2593107：同期上限を超えました https://easycoexistence.com/ja/docs/whatsapp-error-2593107 エラー 2593107 は、この番号で連絡先とチャット履歴の同期がすでに一度実行されたことを示します。同期はオンボーディングごとに一度だけ実行され、繰り返すことはできません。もう一度実行するには、番号を切断してから再接続する必要があります。 ### ここでいう同期とは何ですか？ Coexistence の番号にある既存の連絡先と会話履歴を API 側へ移行する手順です。これにより、企業が何年も使ってきた番号でも、ソフトウェアが何もない状態から始めずに済みます。 この機能があるのは Coexistence の場合だけです。通常の方法でオンボーディングした番号には、移行すべき過去のアプリ履歴がないため、同期するものがありません。Coexistence の番号には両方があり、Meta は番号の接続時に一度だけ移行できるようにしています。 そのため、Cloud API を長く使ってきた人でも、このエラーにはなじみがない場合があります。これまで使ったことのないオンボーディング方式に属するエラーだからです。 ### なぜ一度しか実行できないのですか？ これは継続的な機能ではなく、オンボーディングの一部として接続時に行う判断だからです。Meta はこの判断を一度きりのものとして扱います。 Embedded Signup の途中で、企業の担当者は既存のチャット履歴を共有するかどうかを尋ねられます。「はい」と答えると、同期を実行できるようになります。後から再び有効にする設定も、同期を繰り返すエンドポイントもありません。そのため、2 回目の呼び出しでは、解除されるレート制限ではなく、このエラーが返されます。 実際には、その場での選択が見た目以上に重要です。オンボーディングを急いで進め、拒否のほうが安全に感じて履歴を共有しない選択をすると、完全な切断と再接続を行わない限り、その判断をやり直せません。 ### 本当にもう一度必要になった場合はどうなりますか？ 番号を切断してから再接続する必要があります。これは設定変更ではなく、実際の操作です。 再接続すると、電話でのコードスキャンを含め、Embedded Signup が最初から実行されます。そのため、履歴を受け入れる新たな機会が得られます。WhatsApp Business アプリはその間も影響を受けないため、企業のデータが失われることはありません。ただし、バックグラウンドで静かに完了する操作ではなく、誰かが電話を操作する必要があります。 計画しておくべき点が 1 つあります。切断すると Webhook の配信先が削除されます。配信先は番号ではなく、アプリのサブスクリプションにある上書き設定として登録されているためです。再接続すると送信と監視は復元されますが、何らかの処理で再登録しない限り、自社サーバーへの配信は戻りません。 - 同期を再試行すること。これは一度だけの処理なので、再試行しても成功せず、同じエラーが返されます。 - 慎重になるため、オンボーディング中にチャット履歴を拒否すること。その選択をやり直すには、番号を再接続するしかありません。 - Webhook の配信先を復元する計画なしに再接続すること。配信先はアプリと一緒に削除されます。 **通常の Cloud API の番号でも発生しますか？** いいえ。過去のアプリ履歴を移行できるのは Coexistence の番号だけなので、同期機能も Coexistence の番号にしかありません。 **どのくらいの履歴が同期されますか？** Meta はオンボーディング時に、最近の会話履歴を一定期間分同期します。正確な範囲はプロバイダーではなく Meta が決定します。 **再接続すると、電話のチャットが失われますか？** いいえ。番号を切断して API 側を再接続しても、WhatsApp Business アプリとその会話は影響を受けません。 **2593108 も同じ問題ですか？** いいえ。2593108 は同期がすでに実行されたことではなく、オンボーディングから 24 時間を超えて同期が試みられたことを示します。 --- ## WhatsApp エラー 2593108：24 時間枠外の同期 https://easycoexistence.com/ja/docs/whatsapp-error-2593108 エラー 2593108 は、電話番号のオンボーディングから 24 時間を超えて連絡先とチャット履歴の同期を開始したことを示します。この時間枠は Meta によって固定されており、過ぎた後に同期するには電話番号を再接続するしかありません。 ### この 24 時間枠は何ですか？ メッセージングの時間枠ではありません。このエラーで混乱が起きる主な理由です。 WhatsApp Business Platform には、顧客の最後のメッセージから数える、よく知られた 24 時間のカスタマーサービス時間枠があります。この枠によって自由入力テキストを送信できるかどうかが決まります。これはまったく別の時間枠です。Coexistence の電話番号がオンボーディングを完了した時点から数え、連絡先とチャット履歴を取り込めるかどうかだけを決めます。 この 2 つは、電話番号に関係するという点を除いて無関係です。メッセージを正常に送信できても、同期時間枠がまだ開いているとは限りません。 ### なぜ見落とされるのですか？ オンボーディングと統合は通常、別の日に、別の担当者によって行われるからです。 よくある流れでは、企業の担当者が午後に電話番号を接続し、その週の後半に代理店や開発者がシステムへ接続します。誰かが履歴を確認しようとする頃には時間枠が閉じており、警告ではなく、見慣れないエラーコードとして失敗が返されます。 同期は統合の一部ではなく、オンボーディングの一部として扱うのが適切です。履歴が必要なら、電話番号を接続した当日に、ほかの作業を始める前に取り込む必要があります。 ### 時間枠が閉じた後の選択肢は何ですか？ 電話番号を切断して再接続するか、履歴なしで開始します。 再接続すると、電話でのスキャンを含む Embedded Signup が再開され、新しい時間枠が開きます。WhatsApp Business アプリには影響しないため、どちらの場合も企業側の会話は保持されます。必要なのは、誰かが再び電話の前にいることだけです。 履歴なしで始めても問題ない場合は多くあります。API は接続した時点からすべてを受信するため、多くの統合では過去の会話より新しい会話が重要です。履歴が最も重要になるのは、顧客の過去の状況をすぐに確認する必要がある場合ですが、実際にはそれほど多くありません。 - この時間枠をメッセージングの時間枠と混同する。2 つは別々の時間を測定します。 - 統合作業を始めるまで履歴を残しておく。その時点では時間枠が閉じていることがほとんどです。 - 切断後に Webhook の送信先を復元せず再接続する。送信先は切断後も保持されません。 **これはメッセージングの時間枠と同じ 24 時間ですか？** いいえ。こちらはオンボーディングから数え、同期を決めます。メッセージングの時間枠は顧客の最後のメッセージから数え、自由入力テキストの送信を決めます。 **時間枠を延長できますか？** いいえ。Meta が設定しているため、どのプロバイダーも延長できません。 **再接続には料金がかかりますか？** 再接続自体に料金はかかりません。ただし、誰かが電話の前にいて、もう一度コードをスキャンする必要があります。 **履歴を一度も同期しない場合はどうなりますか？** API は電話番号を接続した時点からすべてを受信します。履歴が必要なのは、過去の状況をすぐに確認する必要がある場合だけです。 --- ## WhatsApp エラー 131026：メッセージを配信できない https://easycoexistence.com/ja/docs/whatsapp-error-131026 エラー 131026 は、Meta がその宛先に配信できなかったことを示します。通常の原因は、その番号が WhatsApp に登録されていないことです。ただし、古いクライアントや、ユーザーが同意していない利用規約によっても同じコードが返ります。 ### 有効に見える番号に配信できないのはなぜですか？ 電話番号を持っていることと、その番号で WhatsApp を利用していることは同じではないためです。 最も多い原因は、宛先のユーザーがその番号を WhatsApp に一度も登録していないか、登録後に削除したことです。番号の形式からは判断できないため、CRM から取り込んだリストではこのエラーが大量に発生します。電話番号は含まれていても、その一部しか WhatsApp の番号ではないためです。 頻度は低いものの、同じコードになる原因が 2 つあります。宛先のユーザーが、送信するメッセージ形式に対応していない古い WhatsApp クライアントを使っている場合です。また、新しい機能に必要な利用規約に同意していない場合もあります。どちらも送信者が制御できるものではありません。 ### このエラーが出たらどうすればよいですか？ 再試行せず、連絡先に記録して、その番号への送信を停止してください。 原因は宛先側にあるため、すぐに再試行しても同じ結果になり、予約した再試行でも通常は解決しません。一時的なエラーとして扱うと、今後も受信できない番号への送信でスループットを消費することになります。 より有効なのは、その連絡先を WhatsApp では到達不能として記録し、別の連絡手段に振り分けることです。これにより、連絡先リストが時間とともに気づかないまま劣化するのも防げます。本当に WhatsApp を利用している番号であれば、対応すべきなのは送信者ではなく宛先側です。 - 予約して再試行すること。原因は宛先側にあり、時間が経過しても解消しません。 - 形式の問題だと考えること。番号は Meta に到達したうえで、認証ではなく配信時に拒否されています。 - フィルタリングせず CRM リストに送信すること。電話番号が必ず WhatsApp の番号とは限りません。 **番号が WhatsApp に登録されているか、事前に確認できますか？** 確実な確認はできません。Meta も照会機能を提供していないため、実際には最初の送信が確認になります。 **これは品質評価に影響しますか？** 配信不能な宛先は、あなたをブロックまたは報告した宛先とは異なります。ただし、そのような宛先が多いリストへ大量送信すると、別の場所にも影響が現れる可能性があります。 **番号の形式が問題ですか？** 通常は違います。形式が不正な番号には、代わりにパラメーターエラーが返ります。このコードは、番号が認識されたものの到達できなかったことを示します。 **連絡先を削除すべきですか？** 削除せず、WhatsApp では到達不能として記録してください。その人が後から同じ番号を登録する可能性があります。 --- ## WhatsApp エラー 131042：ビジネスアカウントの支払い問題 https://easycoexistence.com/ja/docs/whatsapp-error-131042 エラー 131042 は、WhatsApp Business アカウントに有効な支払い方法がないため、Meta がメッセージ料金を請求できないことを示します。料金は Meta から直接請求されるため、接続先の API を提供する会社ではなく、WhatsApp Manager で解決します。 ### 実際に誰が誰へ請求していますか？ 請求する会社は 2 社ありますが、プロバイダーに関係する請求はそのうち 1 つだけです。 Meta は WhatsApp Business Platform 上の会話に対して請求し、お客様自身の WhatsApp Business アカウントに登録された支払い方法へ請求します。この関係は、お客様と Meta の間にあります。プロバイダーはその横で、接続やツールの利用料を請求しますが、会話料金を受け取ることはありません。 そのため、このエラーはプロバイダーに連絡しても解決できず、プロバイダーが代わりにカードを追加することもできません。また、プロバイダーが受け取らない会話料金に、プロバイダーが上乗せすることもありません。 ### 支払い方法はどこで設定しますか？ 番号を所有する WhatsApp Business アカウントの WhatsApp Manager で設定します。 そこで支払い方法を追加または更新します。特定の送信を利用するには、アカウントに支払い方法が登録されている必要があります。特にマーケティングテンプレートの送信には必須です。そのため、顧客への返信だけに使っていたアカウントで、初めてプロモーションメッセージを送ろうとしたときに、このエラーが表示されることがあります。 API からこの設定はできません。カードを登録するエンドポイントがないのは意図的な仕様です。これはメッセージ操作ではなく、アカウント単位の商取引上の関係だからです。 - プロバイダーに修正を依頼すること。請求関係はお客様と Meta の間にあり、カードを登録できる API もありません。 - プロバイダーの料金にメッセージ料金が含まれると考えること。別会社による別々の請求です。 - 支払い方法が未登録のアカウントでマーケティングテンプレートを試すこと。Meta はその送信に支払い方法を要求します。 **EasyCoexistence が代わりに Meta へ支払えますか？** いいえ。料金はお客様自身の WhatsApp Business アカウントに登録された支払い方法へ請求され、登録用の API もありません。 **なぜ今になって表示されたのですか？** 初めてマーケティングテンプレートを送信しようとしたことが原因である場合が多いです。Meta はその送信に支払い方法を要求します。 **受信メッセージも停止しますか？** 受信には影響しません。失敗するのは、Meta が料金を請求する必要がある送信です。 **Meta の料金を完全に避ける方法はありますか？** 24 時間のカスタマーサービス期間内の返信は無料です。Meta が請求するのは、その期間外に開始された会話です。 --- ## WhatsApp エラー 133010：電話番号が未登録 https://easycoexistence.com/ja/docs/whatsapp-error-133010 エラー 133010 は、電話番号が WhatsApp Business プラットフォームへの登録を完了していないことを示します。アカウントに追加され、ダッシュボードに表示されていても、登録が完了するまでは何も送信できません。 ### ここでいう登録とは、実際には何を意味しますか？ 番号が WhatsApp Business アカウントに存在することとは別に、送信に使える状態にする最後の手順です。 オンボーディングでは番号をアカウントに追加し、識別子を取得します。登録によって、番号が送受信できる状態になったことをプラットフォームに伝えます。ダッシュボードに番号が表示された時点で、登録を完了していないことに気づきにくい場合があります。すべて接続済みに見えるのに、最初の送信だけが失敗します。 Coexistence の番号では、別の理由でも見落としやすくなります。電話の WhatsApp Business アプリは処理中も問題なく動作するため、企業の日常業務からは未完了に気づけません。 ### オンボーディングが未完了になるのはなぜですか？ 通常は、途中でウィンドウを閉じてしまうためです。 Meta の Embedded Signup はポップアップで開き、電話でのコードスキャンなど複数の手順があります。番号が表示された後、処理が完了する前に閉じると、まさにこの状態になります。電話を途中で使えなくなった場合や、端末を探している間にセッションがタイムアウトした場合も同じです。 対処法は、送信を再試行するのではなく、処理を最初からもう一度実行することです。再接続すると最初からやり直して登録を完了できます。番号や WhatsApp Business アプリが、2 回実行したことで影響を受けることはありません。 - 送信を再試行すること。メッセージを送ろうとしても登録は完了しません。 - 表示されている番号なら使えると思い込むこと。アカウントに追加済みでも、未登録のままの場合があります。 - 電話だけで判断すること。登録が完了していなくても、WhatsApp Business アプリは通常どおり動作します。 **番号は失われていますか？** いいえ。Meta のオンボーディングをもう一度実行すれば登録が完了し、その間も WhatsApp Business アプリには影響ありません。 **API から登録できますか？** 登録は Meta のオンボーディングに含まれるため、ブラウザと電話が必要です。スキャンを省略する API の方法はありません。 **なぜメッセージを受信できるのですか？** 受信と送信は同じ手順で制限されないため、オンボーディング途中の番号でも電話側では動作しているように見えます。 **これは 133006 と同じですか？** いいえ。133006 は登録前に番号の確認が必要なことを示します。このエラーは、登録自体が完了していないことを示します。 --- ## WhatsApp エラー 190: アクセストークンの期限切れ https://easycoexistence.com/ja/docs/whatsapp-error-190 エラー 190は、リクエストに使ったアクセストークンの期限切れ、または無効化を意味します。すべての呼び出しが同じように失敗するため、番号が消えたように見えます。しかし実際には認証情報の問題で、番号は通常そのままです。 ### 期限切れのトークンが、なぜ番号を失ったように見えるのですか？ すべてのリクエストが同じように失敗するためです。 番号の読み取り、接続状態の確認、メッセージテンプレートの一覧表示、メッセージ送信が一度に停止します。外部から見ると、番号がアカウントから削除された状態と区別できません。認証情報を 1 つしか使わない連携では、2 つを見分ける方法もありません。そのため、実際には切断されていないのに、切断されたと判断する人が多くなります。 この違いは重要です。壊れた認証情報は交換できますが、削除された番号は再接続が必要で、企業の所有者と電話が必要になります。 ### 違いをどう見分ければよいですか？ 同じアカウントを読み取れる 2 つ目の認証情報を用意します。 EasyCoexistence は、各接続について顧客のトークンと独自の System User トークンを保持します。一方が拒否されたとき、もう一方で WhatsApp Business アカウントを読み取り、どちらが壊れたのかを判定できます。顧客のトークンが拒否されても、2 つ目の読み取りが成功すれば、期限切れは認証情報側で、番号は正常です。両方が失敗する場合は、番号自体に問題が起きています。 2 つ目の読み取り手段がなければ、区別するには企業の所有者に確認してもらうしかありません。これは、監視で避けるべき中断そのものです。 ### トークンはどのように無効化されますか？ いくつかの方法があり、その多くは意図的な操作ではありません。 トークンには有効期間があり、自動的に期限切れになります。Meta アカウントのパスワード変更でも無効化されます。誰かがビジネス設定でアプリのアクセス権を削除した場合や、Meta が侵害されたと判断してトークンを取り消した場合も同様です。これらは事前に警告されず、電話の WhatsApp Business アプリから確認することもできません。 そのため、トークンの有効性はエラーハンドラーではなく監視で確認すべきです。エラーハンドラーが検知する頃には、送信はすでに失敗しています。 - トークンが問題なのに番号を再接続する。不要な作業を企業の所有者に求めることになります。 - 一時的な問題と考えて再試行する。無効化されたトークンは自然には復旧しません。 - 認証情報を 1 つだけ使う。認証情報の失敗と番号の喪失を区別できません。 **番号はまだ使えますか？** 通常は使えます。WhatsApp Business アプリには影響せず、番号自体も intact です。停止したのは API アクセスです。 **エラー 0 も同じですか？** 実質的には同じです。Meta はエンドポイントによって、この状態を 2 つのコードで報告します。 **再接続すれば直りますか？** 直りますが、軽い問題に対して企業の所有者と電話が必要になる大がかりな対応です。新しい認証情報だけで解決できます。 **トークンを期限切れにしない方法はありますか？** System User トークンは長期間有効にできるため、2 つ目のトークンを保持する価値があります。 --- ## WhatsApp エラー 130429：スループット上限に到達 https://easycoexistence.com/ja/docs/whatsapp-error-130429 エラー 130429 は、この番号の Cloud API のメッセージ送信スループット上限に到達したことを示します。これは量ではなく速度の問題です。同じメッセージでも、よりゆっくり送れば送信できます。Coexistence 番号では、上限が Meta によって固定されています。 ### 実際に制限されているものは何ですか？ 制限されるのは、1 日に送信できるメッセージ数ではなく、メッセージを送信する速度です。 プラットフォームは、1 つの番号から 1 秒あたりに送信できるメッセージ数を定めています。その上限を超えたリクエストはキューに入らず、拒否されます。そのため、1 万件のメッセージを送ること自体は問題ではありません。すべてを同じ 1 秒に送信することが問題です。同じバッチでも数分に分散すれば、そのまま送信できます。 これは、1 日に会話を開始できるユニークな顧客数を定めるメッセージングティアや、受信者の反応が悪い番号を制限する品質制限とは別のものです。3 つの異なる上限に、それぞれ異なるコードがありますが、混同されることがよくあります。 ### 上限を引き上げることはできますか？ Coexistence 番号ではできません。Meta が一定の速度に固定しており、どのプロバイダーも引き上げることはできません。より高い数値を前提に設計する前に、この点を把握しておく必要があります。 通常の方法でオンボーディングした番号では、時間の経過とともに品質評価とメッセージングティアに応じてスループットが拡大します。この違いは、Coexistence における数少ない本当のトレードオフの 1 つです。そのため、大量配信に使う番号は、通常は Coexistence を使わずにオンボーディングしたほうが適しています。 会話用途では、この上限が制約になることはほとんどありません。コードが許す限りの速度でリストを処理して送信すると、上限に達します。そのような設計自体を避ける価値があります。 ### 送信側は代わりに何をすべきですか？ すぐに再試行するのではなく、送信速度を調整し、バックオフを設けて再試行してください。 一定の速度で処理するキューが、長期的に使える解決策です。これにより、上限は本番環境で初めて発見する問題ではなく、システムの性質になります。そこまでの仕組みが難しい場合は、このコードに対して指数バックオフを設定するだけでも、多くの効果があります。 機能しないのは、短い間隔での再試行です。拒否された瞬間に即時再試行するループは、番号がすでに速度上限を超えているときに、さらにリクエストを発生させます。その結果、状態が解消されるどころか長引きます。 - すぐに再試行する。拒否された瞬間にリクエストを増やすと、番号は速度上限を超えたままになります。 - メッセージングティアと混同する。メッセージングティアが定めるのは日次のユニークな会話数であり、1 秒あたりのメッセージ数ではありません。 - スループットが拡大する前提で Coexistence 番号を設計する。スループットは拡大せず、上限は固定されています。 **この場合、番号が制限されているということですか？** いいえ。通常の速度制限です。番号は正常で、同じメッセージもゆっくり送れば成功します。 **Coexistence 番号はどのくらいの速度で送信できますか？** Meta が Coexistence 番号に固定速度を設定します。品質やティアに応じて拡大することはありません。 **80007 も同じですか？** いいえ。80007 は、番号のメッセージ送信スループットではなく、WhatsApp Business Account の速度制限です。 **別のプロバイダーなら、より速く送信できますか？** いいえ。制限を決めるのは、API を呼び出すプロバイダーではなく、その番号と Meta です。 --- ## 公式 Cloud API で WhatsApp を Make に接続する https://easycoexistence.com/ja/integrations/make 番号の Webhook 送信先を Make のカスタム Webhook に指定すると、受信メッセージごとにシナリオが開始します。返信は HTTP モジュールで Cloud API 経由に戻します。Make は MCP サーバー自体でありクライアントではないため、当社の MCP サーバーは利用できません。 ### WhatsApp のメッセージで Make のシナリオを開始するには？ Make でカスタム Webhook モジュールを作成し、表示された URL をコピーして、番号の Webhook 送信先に設定してください。以降、Meta は番号宛てのすべてのメッセージを HTTP POST でその URL に直接配信し、シナリオが実行されます。 ペイロードには、送信者、メッセージ本文またはメディア参照、タイムスタンプ、メッセージ ID が含まれます。そこからは通常のシナリオです。内容で振り分け、顧客を検索し、必要な処理を呼び出します。 これは Coexistence なので、同じメッセージはスマートフォンの WhatsApp Business アプリにも表示されます。担当者が返信すると、シナリオはその送信内容を認識し、双方の返信が重なることもありません。 ### Make で MCP コネクタを使えないのはなぜですか？ Make は MCP クライアントではなく、MCP サーバーだからです。Make は独自のシナリオを Claude や ChatGPT などのアシスタントに公開し、アシスタントが Make に接続します。他社の MCP サーバーへ外向きに接続する仕組みではありません。 違いは接続方向にあります。当社のコネクタは呼び出しを待つサーバーですが、Make には外部サーバーを呼び出す機能がないため、両者は接続できません。これは、MCP Client Tool ノードを備え、OAuth でリモートサーバーを利用できる n8n とは異なる製品です。 実質的な追加費用はかかりません。Webhook の経路だけでシナリオに必要な処理ができ、受信メッセージにも反応できます。MCP はどのツールでもこの処理には対応できません。 ### シナリオから返信を送るには？ 番号の phone number id とアクセストークンを使い、Cloud API に対して HTTP モジュールを実行します。どちらもダッシュボードで確認できます。必要であれば、MCP コネクタ経由でアシスタントに取得させることもできます。 送信内容はタイミングによって異なります。顧客の最後のメッセージから 24 時間以内なら自由入力テキストを送信できます。それを過ぎると、Meta が承認したメッセージテンプレートだけが配信されます。自由入力テキストしか送らないシナリオでは、最初の夜間対応で止まってしまいます。 安定した構成はルーターです。最後の受信メッセージからの経過時間を確認し、自由入力テキストまたはメッセージテンプレートの分岐に振り分けてください。 - 停止中のシナリオの Make URL を Webhook に指定したままにする。Meta はそこへ配信しますが、何も実行されません。 - Meta の認証リクエストに応答しない。Meta は配信前に challenge を含む GET を送信します。 - 24 時間の期限を過ぎて自由入力テキストで返信する。送信に失敗し、シナリオ上は何も起きなかったように見えます。 **Make から御社の MCP サーバーに接続できますか？** いいえ。Make はクライアントではなく MCP サーバーなので、当社のサーバーを呼び出せません。Webhook の経路だけでシナリオに必要な処理ができます。 **WhatsApp 用の Make アプリは必要ですか？** いいえ。カスタム Webhook で受信し、HTTP モジュールで送信します。連携に必要なのは URL と REST リクエストだけです。 **チームはスマートフォンから引き続き返信できますか？** はい。それが Coexistence です。同じ番号のアプリを使い続けられ、シナリオは担当者の送信内容を認識します。 **1 つのシナリオで複数の顧客に対応できますか？** はい。すべての番号を同じ Webhook に指定し、ペイロード内の phone number id で振り分けてください。 --- ## 公式 Cloud API で WhatsApp を Zapier に接続 https://easycoexistence.com/ja/integrations/zapier 番号の Webhook 配信先を Zapier のキャッチフックに設定すると、受信メッセージごとに Zap が起動します。返信は Webhook アクションを使い、Cloud API 経由で返します。Zapier はクライアントではなく MCP サーバーなので、当社の MCP サーバーは利用できません。 ### 受信メッセージで Zap を起動するには？ Webhooks by Zapier のトリガーで Zap を開始し、「Catch Hook」を選択して、Zapier が生成する URL をコピーします。その URL を番号の Webhook 配信先に設定すると、Meta がすべての受信メッセージを直接そこへ配信します。 ペイロードには送信者、メッセージ内容、タイムスタンプ、メッセージ ID が含まれます。これはほとんどの Zap で分岐に使う情報です。インフラストラクチャで何も実行する必要はなく、統合の接続面は URL なので、保守する Zapier アプリもありません。 同じ番号では WhatsApp Business アプリも引き続き動作します。そのため、Zap が処理しない会話には担当者が対応できます。 ### Zapier が MCP コネクターを使わないのはなぜですか？ Zapier は MCP クライアントではなく、MCP サーバーとして動作するためです。Claude や ChatGPT などのアシスタントが Zapier に接続し、そのアクションを利用します。Zapier は第三者の MCP サーバーへ外向きに接続しないため、当社のサーバーには到達できません。 実際の影響はありません。MCP は人が依頼したときにアシスタントが操作するためのもので、Zap は逆の構成です。何かが起きると、自動化が応答します。MCP クライアントを備えたツールを含め、これはすべて Webhook の領域です。 アシスタントも処理に加えたい場合は、Zap の内部ではなく、Claude または ChatGPT でコネクターを Zap と併用してください。 ### Zap から返信を送るには？ Webhooks by Zapier の POST アクションで Cloud API にリクエストし、ダッシュボードにある番号の電話番号 ID とアクセストークンを使用します。 送信できる内容はタイミングで決まります。顧客の最後のメッセージから 24 時間以内なら、自由入力のテキストを送信できます。時間を過ぎると、承認済みのメッセージテンプレートだけが送信できます。テストは常にメッセージの数秒後に行うため、本番で多くの Zap がここで失敗します。 両方に対応する Zap には、最後の受信メッセージからの経過時間で分岐するパスフィルターが必要です。追加する手順は 1 つだけですが、火曜日の午後だけ動く自動化と、深夜 3 時にも動く自動化の違いになります。 - Zapier のテスト URL を配信先に設定する。リッスンを停止し、メッセージがどこにも配信されなくなります。 - Meta の認証 GET を忘れる。配信開始前に、キャッチフックが challenge を返す必要があります。 - 24 時間の時間枠外で自由入力テキストを送信する。Zap 側からは静かに失敗します。 **公式の WhatsApp Zapier アプリはありますか？** ここでは必要ありません。キャッチフックで受信し、Webhook アクションで送信するため、中間サービスなしで公式 Cloud API を利用できます。 **Zapier は当社の MCP サーバーを利用できますか？** いいえ。Zapier 自体が MCP サーバーであり、クライアントとして動作しないため、当社のサーバーへ接続できません。 **チームは電話を使えなくなりますか？** いいえ。Coexistence により、同じ番号で WhatsApp Business アプリを引き続き利用できます。 **Zap が一時停止している場合はどうなりますか？** Meta は一定期間リトライした後、停止します。メッセージは電話のアプリには届くため、企業側で失われるものはありません。 --- ## WhatsApp を ChatGPT にカスタムコネクタで接続する https://easycoexistence.com/ja/integrations/chatgpt ChatGPT の設定で開発者モードをオンにし、EasyCoexistence をコネクタとして追加すると、Meta 公式 Cloud API 上で番号の一覧表示、接続状態の確認、メッセージとテンプレートの送信、独自システムへの Webhook 設定ができます。 ### ChatGPT に追加するにはどうすればよいですか？ 設定を開き、「コネクタ」に移動して「詳細設定」を開き、開発者モードをオンにしてください。これにより、組み込みリストから選ぶのではなく、URL でコネクタを追加するオプションが表示されます。 EasyCoexistence MCP エンドポイントを指定するコネクタを追加してください。ChatGPT が初めてツールを呼び出すとサインイン画面が開くため、そこで認証します。コネクタは API キーではなく OAuth を使用するため、生成、コピー、貼り付けは必要ありません。 サーバー自体はリモートにあります。インストールもバックグラウンド処理もマシン上では行われず、ChatGPT を閉じても接続済みの番号には影響しません。 ### 接続すると ChatGPT で何ができますか？ 自然な言葉で依頼すると、適切なツールが選ばれます。「自分の番号で接続状態が悪いものはどれ？」「この顧客に予約確認を送って」「注文更新用のテンプレートを作成して、Meta の承認時に知らせて」「この番号の Webhook を自分のサーバーに設定して」といった依頼ができます。 読み取りツールでは、番号の一覧表示、品質評価、メッセージング階層、接続状態の確認、別の処理で必要になった際の認証情報の取得ができます。送信ツールでは、セッション時間内の自由文と、それ以外の承認済みテンプレートを送信できます。 16 個のツールの 1 つが、ドキュメントをマークダウンとして ChatGPT に渡します。そのため、ChatGPT は推測ではなく、当社のドキュメントをもとに仕組みについて回答できます。 ### できないことは何ですか？ 受信メッセージへの自動応答です。多くの人がアシスタントならできると思う機能なので、ここは明確にしておく必要があります。 MCP はリクエストとレスポンスの仕組みです。ChatGPT は依頼されたときにツールを呼び出します。顧客の WhatsApp メッセージをきっかけに ChatGPT が起動し、午前 3 時に自動返信する仕組みはありません。当社のコネクタもその点は変えず、どの製品の MCP サーバーにもその機能はありません。 自動返信には Webhook を使います。Meta が受信メッセージを指定したシステムに届け、そのシステムが処理を決めます。この 2 つは連携でき、コネクタから Webhook の送信先を設定することもできます。 - 自動で顧客に返信できると思う。MCP は依頼時に動作し、受信メッセージには Webhook が必要です。 - 組み込みコネクタリストで EasyCoexistence を探す。開発者モードをオンにし、URL で追加します。 - キーが必要だと思う。コネクタは OAuth で認証するため、貼り付けるものはありません。 **有料の ChatGPT プランは必要ですか？** カスタムコネクタは設定の開発者モードから利用します。利用可否は当社が管理するものではなく、OpenAI 独自のプラン規則に従います。 **ChatGPT は顧客との会話を見ますか？** 依頼した内容だけです。受信メッセージは Meta から指定した Webhook 送信先に送られ、当社が会話内容を保存することはありません。 **新しい番号を接続できますか？** 手続きを開始できます。コネクタがリンクを返すため、企業の所有者が開いて Meta のフローで自分の番号を認証します。 **Claude と同じアカウントで利用できますか？** はい。1 つの EasyCoexistence アカウントと 1 つのエンドポイントで、接続したすべてのアシスタントが同じ番号を参照できます。 --- ## MCP 経由で WhatsApp を Cursor に接続する https://easycoexistence.com/ja/integrations/cursor EasyCoexistence を Cursor の MCP 設定に追加すると、プロジェクトを離れずに実際の WhatsApp 番号へ接続できます。番号一覧の確認、接続状態の確認、メッセージや承認済みテンプレートの送信、構築中のサービスへの Webhook 送信先の指定を、Meta の公式 Cloud API 上で行えます。 ### Cursor に追加するにはどうすればよいですか？ 設定を開いて MCP セクションを見つけ、EasyCoexistence のエンドポイントを指定するサーバーを追加してください。Cursor は mcp.json ファイルも読み取ります。複数のマシンを設定する場合や、設定をバージョン管理したい場合はこちらが適しています。 再読み込み後、Cursor に番号一覧を表示するよう依頼してください。初回はサインインが行われ、それ以降はツールを利用できるようになります。インストールするパッケージも、生成するキーもありません。 サーバーはリモートで動作するため、編集画面と並行して何かを実行する必要はありません。Cursor を閉じても、接続済みの番号には影響しません。 ### 編集画面で WhatsApp を使う理由は何ですか？ 構築しているもの自体が通常は連携機能であり、この仕組みがないとフィードバックの循環が遅くなるためです。 Webhook を接続し、認証済みか確認し、自分宛てにテストメッセージを送り、テンプレートの承認ステータスを読み取る。そのたびにダッシュボードへ移動して戻る必要があります。このコネクターなら、コードがある場所でそのまま質問できます。 顧客のプロジェクトに取り組みながら、その顧客の番号を設定する最も速い方法でもあります。get_connect_link は顧客が開くリンクを返し、set_webhook_destination は番号を構築中のサービスへ向けます。Meta のポップアップ以外のブラウザタブを開く必要はありません。 - メッセージを受信できると考える。MCP は依頼されたときに動作します。受信トラフィックには Webhook の送信先が必要です。 - 設定にトークンを入れる。コネクターは OAuth を使用するため、ファイルにシークレットは不要です。 - 1 日書き込みのない連絡先に自由入力を送る。24 時間を過ぎると、承認済みテンプレートだけが配信されます。 **インストールするものはありますか？** ありません。OAuth を使う HTTP 経由のリモートサーバーなので、Cursor はサーバーを実行せずに接続します。 **設定をバージョン管理できますか？** はい、mcp.json を使えます。初回利用時の認証は OAuth 経由で行われるため、ファイルにシークレットはありません。 **Claude Code でも動作しますか？** はい、1 つのコマンドで利用できます。エンドポイントはすべてのクライアントで同じです。 **どの番号にも送信できますか？** アカウントに接続した番号から、任意の WhatsApp 宛先へ送信できます。通常の時間帯とテンプレートのルールが適用されます。 --- ## MCP 経由で WhatsApp を Claude Code に接続する https://easycoexistence.com/ja/integrations/claude-code claude mcp add コマンドを 1 回実行すると、Claude Code から実際の WhatsApp 番号に接続できます。番号の一覧表示、接続状態の確認、メッセージとメッセージテンプレートの送信、Webhook の送信先設定をすべて、リンク済みデバイスのセッションではなく Meta の公式 Cloud API 上で行えます。 ### 追加するにはどうすればよいですか？ 任意のターミナルで、http トランスポートと EasyCoexistence のエンドポイントを指定して claude mcp add を実行します。次に Claude Code 内で /mcp を実行して認証します。それ以降、そのマシンのすべてのセッションで 16 個のツールを利用できます。 設定エントリ以外は何もインストールされません。サーバーはリモートにあるため、常時稼働させるプロセスも、ディスク上に保持されるセッションもありません。 認証には OAuth を使用するため、トークンがシェル履歴、ドットファイル、リポジトリに残ることはありません。ターミナルの設定は誤ってコミットされやすいため、デスクトップアプリよりもここでは重要です。 ### 実際には何に役立ちますか？ WhatsApp とコードベースにまたがる作業を同時に行うエージェント作業です。これは有料ユーザーの多くが行っていることです。 エージェントは get_connect_link で顧客の番号をオンボーディングし、set_webhook_destination で構築中のサービスを接続先に指定してから、テストメッセージを送信し、Webhook が認証されたかを読み取れます。通常ならダッシュボード、電話、そして長い待ち時間が必要な一連の作業を完結できます。 ドキュメントをモデルに届ける方法でもあります。get_docs は製品ドキュメントをマークダウンで返すため、エージェントが Coexistence のルール、24 時間の期間、14 日間の条件について回答するとき、記憶に頼らず当社のドキュメントを参照できます。 - 受信メッセージがエージェントに届くと考えること。MCP はリクエストとレスポンスの仕組みであり、配信には Webhook が必要です。 - プロジェクトごとに追加すること。マシン単位で設定され、その後のすべてのセッションで利用できます。 - 期間外にスクリプトから自由形式のテキストを送信すること。最後の受信時刻を確認し、メッセージテンプレートに切り替えてください。 **Codex でも動作しますか？** OAuth を使う HTTP 経由の MCP に対応するものなら、同じエンドポイントを利用できます。 **トークンはディスクに保存されますか？** いいえ。認証には OAuth を使用するため、設定ファイルにシークレットは保存されません。 **エージェントだけで番号を接続できますか？** プロセスは開始できます。ただし、Meta のフローにはブラウザと電話が必要なため、返されたリンクは企業の所有者が開く必要があります。 **ターミナルを閉じると接続は解除されますか？** いいえ。サーバーはリモートにあり、ローカルで何が実行されているかに関係なく番号は接続されたままです。 --- ## WhatsApp の Webhook：メッセージをサーバーへ直接振り分ける https://easycoexistence.com/ja/whatsapp-webhook WhatsApp の Webhook は、指定した HTTPS エンドポイントです。Meta はそこへ、受信メッセージ、配信ステータス、品質変更、アカウント更新などのイベントを送信します。Coexistence の番号では、配信先を自社サーバーに設定できるため、会話がプロバイダーを経由することはありません。 ### Meta は Webhook に実際に何を送信しますか？ イベントはカテゴリー別に送信され、その違いがアーキテクチャを決めます。 メッセージ経路には、顧客が送信した内容と、Coexistence の番号でチームが WhatsApp Business アプリから送信した内容のエコーが含まれます。該当するフィールドは messages と smb_message_echoes で、会話の内容を含むのはこの 2 つです。 運用経路には、それ以外のすべてが含まれます。接続状態が変わったときの account_update、品質やスループットが変化したときの phone_number_quality_update、account_alerts、account_review_update、business_capability_update、phone_number_name_update です。これらに会話の内容は含まれず、監視はこれらをもとに構成します。 メッセージ経路に入るプロバイダーは最初のグループを受信します。入らないプロバイダーは受信しません。 ### Meta はエンドポイントをどのように認証しますか？ Meta は何かを配信する前に GET リクエストを送信します。この認証に失敗すると、設定が完了しているように見えてもメッセージを受信できません。 Meta は hub.mode に subscribe、hub.verify_token、hub.challenge の値を設定して URL を呼び出します。エンドポイントは、その challenge を JSON で包まず、何も追加せず、生のレスポンス本文として返す必要があります。返さなければ Meta は配信を開始せず、どのダッシュボードにもそのことは表示されません。 エンドポイントは HTTPS である必要もあります。何も返さない 404 や、Meta を拒否する認証レイヤーの背後にあるエンドポイントは、最初のメッセージが届かなくなるまで、正常な設定と見分けがつきません。 ### 配信先を自社サーバーにできますか？ できます。ここがプロバイダーによって異なる部分です。 Meta では、特定の WhatsApp Business Account の Webhook 配信先をアプリから上書きできます。EasyCoexistence では、その上書き先をお客様の URL に設定し、メッセージ経路のイベントを当社のコールバックからお客様の URL へ移します。ダッシュボードとアラートは運用イベントで構成されるため、運用イベントは当社で保持します。 これは、当社が公開するポリシーではなく、アーキテクチャ上の結果です。会話の内容は当社に配信されないため、当社側に保存される場所はありません。上書き設定のないアカウントは当社のデフォルトコールバックに戻り、ハンドラーがイベントを保存せずに破棄します。 ### 番号を再接続すると、配信先はどうなりますか？ 削除されます。ほとんど誰も想定していない失敗です。 配信先は電話番号のプロパティではありません。当社アプリが WhatsApp Business Account のサブスクリプションに設定する上書きです。Meta の 14 日間の非アクティブ規則などにより接続が削除されると、アプリがそのアカウントからアンインストールされ、上書き設定も削除されます。 再接続すると送信と監視は復元されますが、自社サーバーへの配信は復元されません。エラーも報告されないため、顧客から「誰も返信しない」と連絡が来て初めて気づくことになります。実際に、正常に再接続した番号が無音になったことがあるため、当社は再接続のたびに上書き設定を再適用します。 - 認証 GET に JSON を返す。Meta が求めるのは生の hub.challenge の値だけです。 - 一時 URL やテスト URL を使う。生成したツールがリッスンを停止した後も、Meta はそこへ配信し続けます。 - 配信先が再接続後も残ると考える。配信先はアプリのサブスクリプションに属し、アプリとともにアンインストールされます。 - Meta のリクエストを拒否する認証の背後にエンドポイントを置く。 **メッセージは EasyCoexistence を経由しますか？** いいえ。上書き設定により、メッセージ経路のイベントは Meta からお客様のエンドポイントへ直接送信されます。上書き設定のないアカウントのイベントは当社のコールバックに戻り、保存せずに破棄されます。 **後から配信先を変更できますか？** できます。ダッシュボードまたは MCP コネクターから、いつでも変更できます。null を渡すと当社のデフォルトに戻ります。 **Meta の配信時にサーバーが停止していたらどうなりますか？** Meta は一定期間再試行し、その後停止します。電話の WhatsApp Business アプリにはメッセージが届くため、統合が停止しても企業が受け取るメッセージは失われません。 **複数の番号に 1 つの Webhook で対応できますか？** できます。すべての番号を同じエンドポイントに指定し、ペイロード内の受信先 phone number id で処理を分岐してください。 --- ## Python から WhatsApp を送受信する https://easycoexistence.com/ja/integrations/python 受信は、Meta の認証 GET に応答して POST を受け付ける、Web フレームワーク内のルートです。送信は、電話番号の phone number id とトークンを使って Cloud API に HTTPS リクエストを送ります。当社の SDK は不要で、インストールするものもありません。 ### Python でメッセージを受信するには？ すでに使っている任意のフレームワークで、1 つのルートに 2 つのハンドラーを設定します。 GET ハンドラーは Meta の認証に応答します。クエリ文字列から hub.mode、hub.verify_token、hub.challenge を読み取り、トークンを独自のものと照合し、challenge を生のボディとして返します。ここで JSON を返すのが最もよくある間違いで、エラーが表示されないまま失敗します。 POST ハンドラーはイベントを受信します。Meta は遅いレスポンスを失敗とみなして再試行するため、同じメッセージを 2 回処理することになります。すぐに 200 を返してから処理してください。インラインで処理せず、キューに入れるかバックグラウンドタスクに渡します。 メッセージには wamid のメッセージ ID が含まれます。再試行は例外ではなく通常の動作なので、最初からこの ID で重複排除しておく価値があります。 ### 送信するには？ 電話番号の phone number id に対する Cloud API の messages エンドポイントへ、ベアラートークン付きで POST を 1 回送ります。 2 つの値は接続情報から取得できます。ダッシュボードに表示されますし、アシスタントに取得させたい場合は get_api_credentials が返します。この呼び出しに当社固有の要素はないため、どの HTTP ライブラリでも利用でき、リクエストは Meta 公式ドキュメントのものとまったく同じです。 タイミングによって変わるのはボディです。顧客の最後のメッセージから 24 時間以内なら、テキストオブジェクトを送信します。時間を過ぎた場合は、承認済みのテンプレートとその言語を指定するテンプレートオブジェクトを送信します。最初の形式しか知らないクライアントはテストでは完全に動作しますが、初めて夜間に届いたメッセージで失敗し、エラー 131047 を返します。 ### 本番用のハンドラーには、これ以外に何が必要ですか？ 後から追加するとコストが高く、簡単に見落としやすいことが 3 つあります。 Meta は再試行するため、メッセージ ID で重複排除します。Webhook URL に長いランダムなシークレットを含め、それがないリクエストは拒否してください。そうしないと、推測しやすい URL を知った誰でも POST できます。署名ヘッダーはここでは選択肢になりません。Meta はサブスクリプションを所有するアプリのアプリシークレットで署名しますが、そのアプリは当社のもので、シークレットが共有されることはありません。また、連絡先が最後にメッセージを送ってからどれくらい経ったかで分岐し、人が判断しなくても送信経路がテキストかテンプレートかを選べるようにします。 これらにフレームワークやライブラリは必要ありません。必要なのは集合、チェック、比較です。最初の顧客を迎える前に整えておくことが、静かに動く統合と、対応を求めるアラートが鳴る統合の違いになります。 - 認証 GET から生の challenge 値ではなく JSON を返す。 - 200 を返す前にインラインで処理する。Meta は遅いレスポンスを再試行するため、メッセージを 2 回処理します。 - 時間枠を確認せずにフリーテキストを送信する。131047 が返り、何も起きなかったように見えます。 **Python SDK はありますか？** 当社提供のものはありませんが、必要もありません。API は Meta のもので、Meta がドキュメントを提供しており、任意の HTTP ライブラリから利用できます。 **どのフレームワークを使うべきですか？** どれでも構いません。必要なのは GET に応答して POST を受け付けるルートで、すべての Python Web フレームワークが対応しています。 **メッセージを 2 回処理しないようにするには？** ペイロード内の wamid メッセージ ID で重複排除します。Meta は仕様として再試行するため、これは例外的なケースではなく想定される動作です。 **チームは引き続き電話を使えますか？** はい。Coexistence により、同じ番号で WhatsApp Business アプリを使い続けられます。チームが送信した内容は、ハンドラーからエコーイベントとして確認できます。 --- ## Node.js で WhatsApp を送受信する https://easycoexistence.com/ja/integrations/node 受信は、Meta の認証 GET に応答し、POST を受け付けるルートです。送信は、電話番号の phone number id とトークンを使い、Cloud API へ fetch リクエストを送ります。こちらの SDK はなく、インストールも不要です。 ### Node でメッセージを受信するには？ Express、Fastify、Next のルートハンドラー、またはプレーンなサーバーで、2 つのメソッドを持つ 1 つのルートを使います。 GET では Meta の認証に応答します。クエリから hub.mode、hub.verify_token、hub.challenge を読み取り、トークンを自分のものと比較して、challenge をプレーンテキストで返します。JSON で返すのは典型的なミスです。見た目は正しくても、エンドポイントが何も受信しなくなります。 POST ではイベントを受信します。すぐに 200 を返し、その後で処理してください。Meta は遅いリクエストを再試行するため、応答前に処理すると同じメッセージを複数回受け取ります。特にサーバーレスでは、先に返してからキューに処理を追加することで、コールドスタートによる重複を防げます。 ### 送信するには？ 電話番号の messages エンドポイントへ、トークンを bearer ヘッダーに設定して fetch します。 こちら固有の処理はないため、リクエストは Meta の公式ドキュメントと完全に一致し、覚えるラッパーや依存する仕組みもありません。2 つの値はダッシュボードにあり、アシスタントが接続を設定する場合は MCP コネクターの get_api_credentials から取得できます。 本文は送信時点によって変わります。顧客の最後の受信メッセージから 24 時間以内なら、text オブジェクトを送ります。時間外は、承認済みのテンプレート名と言語を指定した template オブジェクトを送ります。text だけを送るコードはすべてのテストに通っても、夜間に届いた最初のメッセージで失敗します。 ### サーバーレスでは何が違いますか？ 違いは 2 つあり、どちらも処理が終わる前に関数が終了することに関係します。 200 を返してから処理を続けても、応答した瞬間に停止する関数では動きません。プラットフォームが提供する、応答後も処理を継続する仕組みを使うか、ペイロードをキューに送り、別の関数で処理してください。Meta に必要なのは迅速な確認応答であり、処理の完了ではありません。 コールドスタートによって応答が遅くなり、再試行や重複が増えることもあります。この構成では、wamid メッセージ ID による重複排除は任意ではなく、信頼性を確保するために必要です。 - challenge を生の本文ではなく JSON として返す - 200 を返す前に処理する。サーバーレスでは、応答した瞬間に関数が停止することがあります - 重複排除を省く。Meta は仕様として再試行するため、重複は例外ではなく通常発生します **ライブラリは必要ですか？** いいえ。ルートと fetch だけで十分で、呼び出しは Meta のドキュメントと完全に一致します。 **Vercel や Lambda で動きますか？** はい。ただし通常のサーバーレスの注意点があります。先に確認応答を返し、その後はインライン処理ではなく、キューやバックグラウンドの仕組みで処理してください。 **リクエストが Meta から来たことを確認するには？** Webhook URL に長いランダムなシークレットを含め、それがないリクエストはすべて拒否します。Meta はサブスクリプションを所有するアプリのアプリシークレットで署名します。ここではそのアプリは当社のもので、シークレットが共有されることはないため、お客様側で署名ヘッダーを検証することはできません。 **TypeScript は使えますか？** はい。ペイロードは Meta のもので、Meta がドキュメント化しているため、こちらで型を定義する必要はありません。 --- ## EasyCoexistence と BSP インボックスの違い https://easycoexistence.com/ja/compare/coexistence-vs-bsp BSP はプラットフォームを提供します。チームで使う共有インボックスにメッセージが保存され、BSP のサーバーを経由します。Coexistence は電話の WhatsApp Business アプリを維持し、指定した自社システムへメッセージを振り分けます。選択のポイントは、作業に使うプロダクトが必要なのか、それとも構築の土台となる接続が必要なのかです。 ### BSP は実際に何を提供しますか？ プロダクトです。それは批判ではありません。 Business Solution Provider は通常、共有インボックスを提供します。担当者がログインし、会話を割り当て、定型返信、タグ、レポート、モバイルアプリを使えます。8 人のサポートチームが作業を分担し、誰が何に返信したかを確認する必要があるなら、それは本当に適した購入です。自社で構築するのは賢明ではありません。 構造上の結果として、メッセージはそのプラットフォームを通過し、保存されます。共有インボックスは履歴を表示する必要があるため、そうでなければ成り立たないからです。これは特定のベンダーが選んだ仕様ではなく、プロダクトそのものに備わる性質です。 ### Coexistence はどんな場合に適していますか？ すでに業務の進め方が決まっている企業で、その方法を変えたい人がいない場合です。 1 台の電話から返信する小規模チームに、会話の割り当ては必要ありません。必要なのは夜の時間を取り戻すことです。つまり、電話が今までどおり動き続ける一方で、確認メッセージや最初の返信を自動処理する仕組みです。インボックスへ移行しても、存在しない問題を解決し、求めていなかった問題を生むだけです。 別の理由ですが、代理店も同じ状況になります。顧客は電話番号を移行したり、スタッフを再教育したりしません。会話を第三者のプラットフォームに置くこと自体を受け入れない場合もあります。Coexistence は、顧客に何も求めない唯一の公式な方法です。 ### ソフトウェアを構築する場合、どちらが適していますか？ ほとんどの場合は Coexistence です。その理由は機能ではなく、構造にあります。 会話を処理する仕組みを構築するなら、BSP のインボックスは構築対象の競合製品であり、あなたと Meta の間に入るレイヤーです。Cloud API ではなく BSP の抽象化に対して統合することになるため、Meta の制限に加えて、BSP のレート制限、Webhook の形式、リリーススケジュール、料金にも従うことになります。 Coexistence では Webhook が自社のエンドポイントに届き、API リクエストは Meta 自身のものを使います。Meta がドキュメントを公開しています。統合のどの部分も特定ベンダー専用ではないため、離脱も可能になります。 - 料金だけで選ぶことです。これは別のプロダクトであり、安い方がもう一方の小型版というわけではありません。 - 何も構築されていない接続だけに、8 人のサポートチームを載せることです。チームにはインボックスが必要で、それなしでは不満が生じます。 - BSP なら WhatsApp Business アプリを維持できると思い込むことです。Coexistence で維持できる BSP もありますが、できない BSP も多いため、直接確認する価値があります。 **両方使えますか？** BSP が Coexistence に対応していれば、実質的には使えます。確認すべき質問は、会話内容がどこに保存されるかです。実際の違いはそこにあるからです。 **BSP の方が信頼性は高いですか？** どちらも Meta の Cloud API 上で動作するため、配信は同じです。異なるのは、Meta と自社システムの間に何者が入るかです。 **どちらが安いですか？** 通常、固定の接続料金は席数ごとのインボックス料金より安価です。ただし別の購入なので、数字だけで比べると誤解を招きます。 **離脱した場合、履歴はどうなりますか？** Coexistence では、履歴が私たちのもとに保存されたことはありません。プラットフォームではそこに保存され、取り出すにはエクスポートが必要です。 --- ## EasyCoexistence と自分で構築する場合の比較 https://easycoexistence.com/ja/compare/build-it-yourself-vs-easycoexistence この製品が行うすべての API 呼び出しは Meta がドキュメントで公開しており、Meta アプリがあれば誰でも利用できます。接続の構築は週末でできます。時間がかかるのは Tech Provider になること、そして終わりがないのは接続が静かに停止したことに気づく監視です。 ### 実際には何を構築する必要がありますか？ 最初のバージョンに必要なものは想定より少なく、実用に耐えるバージョンに必要なものは想定より多くなります。 最初のバージョンに必要なのは、Meta アプリ、Embedded Signup、認証ハンドシェイクに応答するエンドポイント、そして送信リクエストです。OAuth と Webhook に慣れている人なら、本当に週末で構築できます。私たちのドキュメントページでも、その大部分を説明しています。 実用に耐えるバージョンは別物です。8 種類の Webhook イベントを名前で処理し、取り消されたトークンと削除された番号を区別します。また、どちらも信頼できるイベントとして届かないため、品質評価とメッセージング階層を定期的に取得します。再接続によって解除された Webhook オーバーライドを再適用し、14 日間の非アクティブによる接続解除と、実際に離脱した顧客を区別します。これらはすべて、何かが壊れた経験から得られたものです。 ### 短縮できない部分は何ですか？ 自分で Meta Tech Provider になることです。これが、1 つの番号を接続することと、他人の番号を接続することの違いです。 費用はかかりませんが、すぐには完了しません。認証済みの Business Manager、App Review に合格するアプリ、そしてフローを実演する録画ビデオが必要です。完了するまでは他社のプロバイダーアカウントを利用することになります。既製ツールで多くの人が直面する接続数の上限は、これが原因です。 自分が所有する 1 つの番号を接続するだけなら、これは不要なので、自分で構築してください。顧客の番号を接続するなら、これが実際のプロジェクトです。作業日数ではなく、待機を含む数週間単位で考える必要があります。 ### 監視の実行には実際いくらかかりますか？ 完了日がない部分です。その点で、他の作業とは異なります。 接続は何の通知もなく失敗します。WhatsApp Business アプリは、品質低下、期限切れのトークン、削除された Webhook オーバーライド、14 日間の接続解除が起きても動作し続けます。そのため、電話上では問題がわからず、最初の兆候は通常、「なぜ誰も返信しないのか」という顧客からの問い合わせです。 これを検知するには、スケジュール実行するポーラー、Webhook 受信処理、状態の保存先、アラート、そしてアラートを確認する担当者が必要です。どれも難しくありません。ただし、すべてを継続して動かし、Meta の変更に合わせて正しく保ち続ける必要があります。Meta は実際に変更を加えます。ここで購入しているのは、API 呼び出しではなく、この正直な運用部分です。 - 最初のバージョンだけを基準に見積もること。番号 1 件の接続は週末でできますが、50 件を接続し続けるのは別です。 - 期限を決めて Tech Provider になろうと計画すること。App Review の所要期間は自分で管理できません。 - 監視を後のフェーズとして扱うこと。監視が検知する障害は静かに起きるため、見つかっていないことは発生していない証拠になりません。 **ここに独自技術はありますか？** ありません。すべての呼び出しは Meta がドキュメントで公開している Cloud API です。これは意図的な設計です。特定のサービスに縛られず、独自の連携を維持したまま離脱できます。 **番号が 1 つなら、自分で構築すべきですか？** おそらく、そうしてください。自分が所有する 1 つの番号を一度接続するだけなら、小規模なプロジェクトです。プラットフォームを正しく理解する機会にもなります。 **Tech Provider のステータス取得にはどのくらいかかりますか？** 費用はかかりませんが、認証済みの Business Manager と App Review が必要で、録画ビデオも提出します。長いのは待機期間です。 **自分で構築すると何を失いますか？** 技術的に失うものはありません。終わりがなく、静かに失敗する監視を自分で引き受けることになります。 --- ## WhatsApp エラー 368：ポリシーによりアカウントが制限されています https://easycoexistence.com/ja/docs/whatsapp-error-368 エラー 368 は、ポリシー違反への対応として Meta が WhatsApp Business アカウントを制限したことを示します。これはリクエストではなくアカウント単位の判断であり、プロバイダーではなく Meta に異議申し立てを行います。 ### 制限とは実際に何を意味しますか？ Meta が企業アカウントに対して措置を講じたことを意味します。通常は、1 回のイベントではなく、ポリシー上の問題が繰り返された後に発生します。 よくある原因は、WhatsApp のコマースまたはビジネスポリシーに違反するメッセージ内容、受信者がメッセージを報告する状態が続くこと、または企業認証の詳細に不備があることです。共通しているのは、特定のメッセージではなくアカウントに関係する点です。そのため、一部ではなくすべての送信が失敗します。 健全なアカウントが送信できる量を制限する品質制限とは分けて考える必要があります。制限は、そのアカウント自体が運用を続けるべきかどうかに関する判断であり、送信量を減らしても解決しません。 ### どのように解決しますか？ Meta の Business Manager で、アカウントの所有者だけが対応します。 Business Manager の措置通知には、どのポリシーが適用されたか、異議申し立てが可能かが記載されています。異議申し立ては可能で、成功する場合もありますが、誰も保証できる期間はなく、プロバイダー経由のエスカレーション手段もありません。API 接続を販売する事業者には、措置の判断を確認したり影響を与えたりする権限はありません。 これは、どのベンダーからも「最も知りたいことには対応できない」と正直に伝えられる数少ない状況の一つです。ベンダーが伝えられるのは、どのアカウントが制限され、いつ発生したかです。そのために接続タイムラインがあります。 - プロバイダーに解除を依頼すること。措置の判断は Meta に属し、他の誰も確認できません。 - 番号を別のプロバイダーで接続すること。制限は企業アカウントに適用されるため、番号を移しても引き継がれます。 - 品質制限と混同すること。品質制限は健全なアカウント自体ではなく、送信量を制限します。 **番号を別のプロバイダーへ移せますか？** いいえ。制限は WhatsApp Business アカウントに適用されるため、その番号をどこで使っても影響します。 **異議申し立てにはどのくらいかかりますか？** Meta は期間を公表しておらず、プロバイダーも手続きの状況を確認できません。 **受信にも影響しますか？** 措置の内容によって異なります。ただし、送信が停止する点は共通しています。 **131031 も同じですか？** 関連しています。131031 は、認証データの不一致を伴う制限に関連し、メッセージの利用状況ではなく企業情報に問題があることを示します。 --- ## WhatsApp エラー 131031：アカウント制限またはデータ不一致 https://easycoexistence.com/ja/docs/whatsapp-error-131031 エラー 131031 は、WhatsApp Business アカウントが制限されていることを示します。多くの場合、企業認証の情報が Meta の保有情報と一致しないか、二段階認証 PIN が関係しています。コードではなく Business Manager で解決します。 ### どのような不一致が原因ですか？ Meta が企業について保有する情報と提出された情報の違いです。小さな違いに見えても、制限につながります。 企業認証では、企業名、住所、登記情報、証明書類によって法人とアカウントを紐付けます。企業側で情報が変わったのに Meta で更新していない場合や、提出内容が Meta の照合する登記情報と一致しない場合、情報が一致するまでアカウントが制限されることがあります。 もう一つのよくある原因が二段階認証 PIN です。これは電話番号に設定され、特定の操作に必要です。忘れてしまった場合や、すでに退職した人が設定した場合は、ほかの操作をする前にリセットする必要があります。 ### 実際にはどこを確認しますか？ 電話番号ではなく、企業アカウントの Business Manager です。 認証ステータスと制限に関する通知はどちらもここに表示されます。通常は、この 2 つを確認すれば、2 つの原因のどちらに該当するか分かります。プロバイダーのダッシュボードでは、番号がいつ停止したかは確認できますが、認証記録は見られないため、どの情報が間違っているかは分かりません。 認証が原因なら、企業情報を更新して再提出します。PIN が原因なら、その番号の WhatsApp Manager の設定からリセットします。後で企業が確認できる場所に記録しておくと安心です。 - コードの不具合だと考えること。リクエストは正しく、アカウントが拒否されています。 - 拒否されたものと同じ情報で認証を再提出すること。 - PIN がプロバイダーに保存されていると考えること。Meta 独自の設定で番号に対して設定されています。 **これは 368 と同じですか？** 関連はありますが、同じではありません。368 はポリシー執行による制限で、こちらは通常、企業認証情報または二段階認証 PIN を示します。 **プロバイダーは認証ステータスを確認できますか？** いいえ。認証ステータスは Business Manager の企業アカウントにあり、プロバイダーには公開されません。 **再接続すれば解決しますか？** いいえ。制限はアカウントに適用されるため、新しい接続でも同じ条件に該当します。 **二段階認証 PIN はどうリセットしますか？** WhatsApp Manager で、その電話番号の設定からリセットします。後で企業が取得できる場所に記録してください。 --- ## WhatsApp エラー 132015：品質低下でメッセージテンプレートを一時停止 https://easycoexistence.com/ja/docs/whatsapp-error-132015 エラー 132015 は、品質が低下したため Meta がこのメッセージテンプレートを一時停止したことを示します。通常は、そのテンプレートを使ったメッセージを受信者がブロックまたは報告した後に発生します。電話番号には問題ありません。一時的に送信できないのは、このメッセージテンプレートだけです。 ### なぜ 1 件のメッセージテンプレートだけが一時停止されるのですか？ 品質は電話番号全体だけでなく、メッセージテンプレートごとにも測定されるためです。問題のあるものだけを分離すれば、ほかのすべてに影響を与えずに済みます。 Meta は、各メッセージテンプレートで送信されたメッセージに対する受信者の反応を確認します。ブロック、報告、そして受信者が実際に反応したかどうかが対象です。悪い反応が継続するメッセージテンプレートは一時停止され、同じ電話番号にあるほかのメッセージテンプレートは引き続き機能します。これは意図的に範囲を絞った対応です。一見すると厳しく見えても、どのメッセージに問題があるかを正確に把握できるため役立ちます。 よくある原因は、ユーティリティ用のメッセージテンプレートに宣伝内容を含めること、どの企業からの連絡か明確でないメッセージを送ること、または受信者が受け取るとは思っていなかった相手に送ることです。 ### 一時停止されたメッセージテンプレートにはどう対応すべきですか？ 再送信するのではなく編集し、一時停止を内容に関する情報として扱ってください。 一時停止されたメッセージテンプレートは、一定期間が過ぎると再び送信できるようになります。しかし、同じ内容を同じような対象者に送れば、同じ反応が起きて再度一時停止されます。Meta は一時停止が繰り返されるとメッセージテンプレートを完全に無効化します。その場合は、内容を変えた新しいものを作成するしかないため、2 回目の一時停止を避けることが重要です。 編集では通常、最初の行で目的を明確にし、企業名を記載し、なぜその人が受信するのかを正直に伝えます。誰に送信するかの確認も必要です。関心のないリストに良いメッセージテンプレートを送っても、同じ反応が生じるためです。 - 一時停止が解除された後、同じメッセージテンプレートを再送信すること。原因は内容にあります。 - 電話番号の問題だと解釈すること。同じ電話番号にあるほかのメッセージテンプレートは引き続き機能します。 - 3 回目の一時停止を待つこと。一時停止が繰り返されるとメッセージテンプレートは完全に無効になります。 **ほかのメッセージテンプレートは送信できますか？** はい。一時停止の対象はこのメッセージテンプレートだけで、電話番号にあるほかの承認済みメッセージテンプレートには影響しません。 **一時停止はどのくらい続きますか？** Meta は固定の期間を公開していません。一時停止が繰り返されるほど、期間は長くなります。 **一時停止されたメッセージテンプレートは編集できますか？** はい。編集することが重要です。内容を改善して再申請することで回復できます。 **132016 とは何ですか？** 完全に無効化された場合のコードです。一時停止が繰り返されるとメッセージテンプレートは無効になり、新しいものに置き換える必要があります。 --- ## WhatsApp エラー 100：パラメータが無効です https://easycoexistence.com/ja/docs/whatsapp-error-100 エラー 100 は、Meta が受け付けないパラメータをリクエストに含めたことを示します。未対応、誤記、またはそのエンドポイントに合わない形式が原因です。決定論的なエラーのため、同じリクエストは毎回同じように失敗し、再試行しても解決しません。 ### 何が原因ですか エンドポイントが認識できないリクエストボディやクエリが原因で、発生理由は一貫しています。 - フィールド名の誤記、または大文字と小文字の誤りです - 別のエンドポイントに属するパラメータです - 想定される整数の代わりに文字列で送るなど、値の型が違います - ネストされたオブジェクトを平坦化した、またはオブジェクトが必要な場所に単一の値を送っています ### なぜ再試行しても無意味ですか 試行の間にプラットフォーム側で何も変わっていないためです。不正な形式のリクエストは、1 回目と同じ理由で 2 回目も不正です。このエラーに対する再試行ループは成功ではなく、元の問題に加えてレート制限を引き起こします。 有効な対応は、エラーとともにリクエストボディを記録し、エンドポイントのリファレンスとフィールドごとに比較することです。ほとんどの場合、1 分以内に違いを見つけられます。 - 再試行することです。リクエストは決定論的で、毎回同じように失敗します - 電話番号の問題だと考えることです。このエラーは接続について何も意味しません - 一般的な失敗として読むことです。これはパラメータの問題を具体的に示しており、欠落した値と範囲外の値には、より限定的なコード 131008 と 131009 があります **電話番号が壊れているという意味ですか？** いいえ。このエラーはリクエストだけに関係し、電話番号には影響しません。 **なぜこれほど曖昧なのですか？** パラメータの問題をまとめて扱うコードだからです。Meta には、パラメータの欠落と無効な値に対する、より限定的なコードがあります。 **プロバイダーが原因になることはありますか？** リクエストを構築する場合に限り、原因になり得ます。直接統合では、リクエストを作成するのはお客様です。 **バックオフして再試行すべきですか？** いいえ。決定論的なエラーであり、一時的な問題ではないため、再試行するとレート制限が加わります。 --- ## WhatsApp エラー 131008：必須パラメータがありません https://easycoexistence.com/ja/docs/whatsapp-error-131008 エラー 131008 は、リクエストに必須パラメータがない場合に発生します。パラメータ全般の形式不正を示すエラー 100 より限定的で、値が間違っているのではなく、フィールド自体がないことを示します。 ### 通常、何がありませんか 任意に見えても必須のフィールドです。そのため、同じ項目が何度も登場します。 - 毎回の送信で whatsapp に設定する messaging_product。 - 必要なメッセージ形式に設定する recipient_type。 - テンプレート送信時の言語オブジェクト。1 つしかなくても必須です。 - 変数を定義するテンプレートの components。空のリストは省略とは異なります。 ### なぜ良い知らせなのですか この種類のエラーでは、最も具体的な失敗だからです。エラー 100 はどこかのパラメータが間違っていることを示しますが、こちらは必須パラメータが完全にないことを示します。そのため、確認範囲をエンドポイントの必須フィールド一覧に絞れます。 呼び出すエンドポイントのリファレンスを読み、リクエストを必須項目と照合してください。数分で確認できるため、ログでは両方を不正なリクエストとしてまとめず、エラー 100 と区別する価値があります。 - エラー 100 と同じものとして扱うこと。こちらは項目がないことを示すため、より具体的です。 - 空の components 配列を省略と同じように送ること。API では別の扱いです。 - messaging_product を省略すること。毎回の送信で必須であり、最も多い単一原因です。 **どのパラメータがありませんか** レスポンスに表示されます。表示されない場合は、エンドポイントのリファレンスで必須項目を確認してください。 **messaging_product は本当に必須ですか** はい。毎回の送信で whatsapp に設定します。最も多い省略項目です。 **これはエラー 100 と同じですか** いいえ。100 は存在するものの間違ったパラメータ、こちらは存在しないパラメータを示します。 **再試行すれば解決しますか** いいえ。リクエストは同じ結果になるため、フィールドを追加するまで同じように失敗します。 --- ## WhatsApp エラー 131009：無効なパラメーター値 https://easycoexistence.com/ja/docs/whatsapp-error-131009 エラー 131009 は、1 つ以上のパラメーター値が無効な場合に発生します。フィールド自体は存在して認識されていますが、その内容をエンドポイントが受け付けません。多くはロケールコード、電話番号の形式、enum 値が原因です。 ### 特に失敗しやすい値 大半の原因は 3 種類で、どれも見た目には正しく見えます。 - ロケールコード：テンプレートが en_US で作成されているのに en を指定する、または pt_BR なのに pt を指定する場合です。 - 句読点、先頭の 0、プラス記号を含む電話番号です。国際形式の数字のみが必要です。 - テンプレートカテゴリなど、enum 値の大文字と小文字が違う場合です。 - エンドポイントの仕様とは異なる形式の日付またはタイムスタンプです。 ### ロケールの問題を特に確認すべき理由 エンドポイントによって異なる 2 種類のエラーが発生するため、誤った原因を追いかけがちです。 その名前に存在しない言語でテンプレートを送ると 132001 が返り、テンプレートが存在しないように見えます。一方、ロケールを先に検証するエンドポイントに不正なロケールを渡すと、このエラーが返ります。根本原因は同じで、どちらの場合もテンプレート一覧を確認し、形式を推測せず正確な言語文字列をコピーすることが解決策です。 - en と en_US は互換性があると思い込む。これらは別のテンプレートを識別します。 - プラス記号や句読点付きの電話番号を送る。国際形式で数字のみを指定します。 - 再試行する。値が決定的に誤っています。 **どの値が間違っていますか？** 通常はレスポンスにパラメーター名が示されます。示されない場合は、まずロケールと電話番号形式を確認してください。 **電話番号はどのような形式にすべきですか？** 国際形式で、プラス記号や句読点を使わず、数字のみで指定してください。 **同じミスで 132001 が返ることがあるのはなぜですか？** テンプレート送信では名前と言語を組み合わせて解決するため、未知の組み合わせがテンプレート不在として扱われるからです。 **これは自分の番号の問題ですか？** いいえ。このエラーの対象はリクエストのみです。 --- ## WhatsApp エラー 131051：サポートされていないメッセージタイプ https://easycoexistence.com/ja/docs/whatsapp-error-131051 エラー 131051 は、送信するメッセージタイプがサポートされていないことを示します。形式が不正なタイプ値の場合もありますが、Coexistence 番号では、その接続で許可されていないタイプを指定したことが主な原因です。 ### 2 つの異なる原因 1 つ目は通常の原因です。タイプ値のスペルが間違っているか、API で定義されていない値を指定しています。エンドポイントリファレンスを確認すれば、すぐに解決できます。 2 つ目は構造上の原因で、同じコードが返るため見落としやすいものです。Coexistence 番号では、通常の Cloud API 番号でできることがすべてできるわけではありません。その操作を試みると、より明確なメッセージではなく、このエラーが返ります。消えるメッセージ、一度だけ表示するメディア、リアルタイム位置情報、ブロードキャストリストは接続済みの番号で無効になり、グループチャットは API の対象外です。 ### どちらの原因かを見分ける方法 送信しようとした内容で判断できます。 - API で定義され、以前に送信したことがあるタイプ：形式の誤りです。ペイロードを比較してください。 - グループ宛ての内容：構造上の制限で、どのプロバイダーでも有効にできません。 - リアルタイム位置情報、一度だけ表示するメディア、消えるメッセージ：Coexistence 番号では構造上利用できません。 - 初めて送信する新しいタイプ：アカウントと地域で利用可能か確認してください。 - グループチャットを前提に構築すること。すべてのプロバイダーで API の対象外です。 - プロバイダーが無効なタイプを有効にできると考えること。プラットフォームレベルの制限です。 - 再試行すること。どちらの原因も一時的なものではありません。 **グループに送信できますか？** いいえ。Coexistence 番号ではグループチャットは API の対象外で、どのプロバイダーでも利用できません。 **リアルタイム位置情報がサポートされないのはなぜですか？** Coexistence が有効になると番号で無効になる機能の 1 つだからです。 **これは修正できますか？** 原因が不正なタイプ形式なら修正できます。プラットフォームの制限なら修正できません。 **受信にも影響しますか？** いいえ。このエラーは許可されていないタイプの送信に関するものです。 --- ## WhatsApp エラー 131052：メディアの取得に失敗 https://easycoexistence.com/ja/docs/whatsapp-error-131052 エラー 131052 は、Meta がメッセージに添付されたメディアを取得できなかったことを示します。問題はリクエストではなくメディア自体にあるため、コードを変更するより別の方法で再送してもらうのが実際的です。 ### 発生する理由 受信メディアは直接配信されず、取得されるためです。メッセージにはメディア ID が含まれ、バイトデータはそれを使って別途取得されます。 送信側の問題で、この取得に失敗することがあります。アップロードが完了していない、取得前にファイルの有効期限が切れた、生成元で形式が維持されなかった、といった理由です。これらはお客様側から確認できず、リクエストを変更しても解決しません。 ### 対処方法 添付ファイルなしで受信したメッセージとして扱い、他の不完全な入力と同じように処理してください。 - メッセージを記録し、イベント全体を破棄せずメディアを利用不可として記録する - メディアを速やかに取得する。ID は永続的に有効ではありません - 人が対応する場合は顧客に再送を依頼する。多くの場合これで解決します - 無期限に再試行しない。初回取得と 1 回の再試行に失敗したら、メディアは取得できません - メッセージ全体を破棄する。添付ファイルがなくても本文とコンテキストは役立ちます - 受信から長時間経ってメディアを取得する。ID には有効期限があります - ループで再試行する。取得に失敗した場合、後から成功することはほとんどありません **メッセージは失われますか？** いいえ。メッセージは届いており、失敗したのは添付ファイルの取得です。 **顧客に再送を依頼すべきですか？** 人が対応する場合は、はい。多くの場合すぐに解決します。 **メディア ID はどのくらい有効ですか？** 無期限ではありません。そのため速やかな取得が重要です。 **131053 も同じですか？** いいえ。こちらは送信するメディアのアップロード失敗です。 --- ## WhatsApp Cloud API のエラーコード https://easycoexistence.com/ja/docs/whatsapp-error-codes 文書化している WhatsApp Cloud API の全エラーコードを、意味と再試行の効果とともに 1 つの表にまとめています。ほとんどは再試行しても解決しません。決定論的なエラーのため、同じリクエストは同じように失敗し、再試行ループによって不正なリクエストがレート制限を招きます。 ### 再試行の列の読み方 この列には 3 つの値があり、選択を誤ると、このリファレンス全体で最も大きな損失につながります。 No は失敗が決定論的であることを示します。失敗したのはリクエスト、テンプレート、または受信者の状態であり、同じリクエストを再送しても同じエラーが発生します。そのうえ、後で必要になるスループットを消費します。はい は Meta 側の障害であり、バックオフによって実際に解消できます。待機 は状態が実在するものの一時的であることを示します。制限やロックが自然に解除されるため、解除前に再試行しても何も起こらず、状態が長引く可能性があります。 ### これらの多くが再試行できない理由 プラットフォームが曖昧なエラーではなく、具体的なコードを返すためです。不正なパラメーター、存在しないテンプレート、終了したメッセージングウィンドウ、オプトアウトした受信者は、レスポンスの時点で原因を特定できます。そのため Meta は曖昧に失敗させず、原因をコードで示します。 - リクエストの問題は、2 回目の試行で正しくなりません。 - テンプレートの問題はテンプレート内にあり、リクエストでは変更できません。 - ウィンドウやオプトアウトの問題は、あなたではなく受信者の状態に関するものです。 - アカウント制限は決定であり、再試行しても異議申し立てにはなりません。 ### このエラーが届いたときに記録する内容 再現せずに診断できるだけの情報です。これが 5 分で直せるか、推測に 1 日かかるかの違いになります。 - trace id を含む完全なエラーレスポンス。Meta サポートが求める情報です。 - 意図した内容ではなく、送信したままのリクエスト本文。両者の差が通常はバグです。 - phone number id。1 つの番号だけの問題か、アカウント全体の問題かを区別できます。 - タイムスタンプ。その時点の接続状態と照合できます。 ### Coexistence にのみ存在するコード 2 つあります。通常の送信失敗に見えるため、混乱を招きます。2593107 と 2593108 はどちらもチャット履歴の同期に関するコードです。これは、番号を初めて接続したときに WhatsApp Business アプリから最近の会話をコピーする処理です。 これらはメッセージングエラーではなく、接続の失敗を意味しません。同期が制限を超えた場合や、許可された時間帯の外で実行された場合も、番号は接続されたまま通常どおり送信できます。ただし、コピーされる履歴は想定より少なくなります。これを接続障害と解釈して切断し、最初からやり直すと、履歴を復旧するどころか、さらに失うことになります。 - デフォルトで再試行すること。これらのコードの多くは決定論的で、ループによってレート制限まで招きます。 - リクエスト本文なしでエラーを記録すること。送信内容と意図した内容の差が通常はバグです。 - 同期エラーを接続障害と解釈すること。番号は接続されたまま送信できます。 - trace id を破棄すること。これがあって初めてサポートへの問い合わせが対応可能になります。 **どのエラーは再試行すべきですか？** 131016 と 131000 です。指数バックオフを使用してください。130429、132015、133008 は待つと自然に解消します。それ以外はすべて決定論的です。 **エラーコードは番号が切断されたことを意味しますか？** 通常は意味しません。これらの多くはリクエスト、テンプレート、受信者に関するものです。接続の問題は送信エラーではなく、アカウントや品質の Webhook として現れます。 **trace id とは何ですか？** Meta サポートが特定のリクエストを見つけるための、エラーレスポンス内の識別子です。すべての失敗で記録してください。これがないと問い合わせに対応できません。 **これらのコードはどのプロバイダーでも同じですか？** はい。Meta の Cloud API が返すコードなので、どのプロバイダーで番号を接続しても同じです。プロバイダーが変えられるのは、コードがどれだけ明確に届くかだけです。 --- ## WhatsApp エラー 131053：メディアのアップロード失敗 https://easycoexistence.com/ja/docs/whatsapp-error-131053 エラー 131053 は、Meta がリクエスト内のメディアをアップロードできなかったことを示します。受信時に発生する関連エラー 131052 とは異なり、管理しているファイルが対象なので修正できます。容量、形式、リンクを送る場合は Meta が実際に到達できるかを確認してください。 ### 3 つの原因 実際に発生する順番です。 - 容量：ファイルが種類ごとの上限を超えています。画像は 5 MB、動画と音声は 16 MB、ドキュメントは 100 MB です - 形式：API が受け付けないコーデックまたはコンテナです。編集ソフトから書き出した動画でよく発生します - 到達性：アップロード済みの ID ではなくリンクを送る場合です。URL にログインが必要、ファイアウォールの内側にある、リダイレクトするなどの原因があります - 有効期限：作成から長時間経過したメディア ID を使用しています ### リンクよりアップロード リンクを送ると、送信時に Meta がファイルを取得するため、自分のネットワークからは見えない失敗要因が増えます。ブラウザーで問題なく開ける URL でも、地域制限、ファイアウォール、ブラウザーが保持する認証 Cookie により、Meta のインフラから到達できないことがあります。 先にファイルをアップロードし、返されたメディア ID を送ると、この種の失敗を完全に取り除けます。リクエストは 1 件増えますが、送信結果が安定するため、大量送信ではその価値があります。 - ブラウザーで開ける URL なら Meta でも使えると思い込む。セッションもネットワークも同じではありません - コーデックを確認せずに動画を書き出す。編集ソフトの初期設定は対応していないことがあります - アップロードから長時間経過したメディア ID を再利用する。ID には有効期限があります **容量の上限は？** 画像は 5 MB、動画と音声は 16 MB、ドキュメントは 100 MB です。 **アップロードと URL 送信のどちらがよいですか？** アップロードしてください。到達性を失敗原因から除外できます。 **URL は自分には開けます。なぜ Meta では開けないのですか？** Meta のネットワークはあなたのものとは異なります。地域、ファイアウォール、認証の条件も異なります。 **131052 と同じエラーですか？** いいえ。131052 は、顧客が送信したメディアのダウンロード失敗です。 --- ## WhatsApp エラー 131016：サービスを利用できません https://easycoexistence.com/ja/docs/whatsapp-error-131016 エラー 131016 は、Meta 側のサービスが一時的に利用できないことを示します。本当に一過性のプラットフォームエラーの一つなので、調査ではなく指数バックオフによる再試行が適切です。 ### このエラーが異なる理由 このプラットフォームの多くのエラーは決定的です。リクエストの形式が正しくない、テンプレートが存在しない、送信可能な期間が終了している、といった原因です。これらを再試行するとリクエストを無駄にし、レート制限を受ける可能性があります。 このエラーは例外です。リクエストや電話番号ではなく、Meta が運用するサービスが現在応答できないことだけを示します。同じリクエストを 1 分後に送ると通常は成功します。まさにバックオフが役立つケースです。 ### 正しく再試行する方法 再試行の集中によって障害を悪化させないよう、控えめに行ってください。 - 指数バックオフを使います。1 秒、2 秒、4 秒、8 秒と待ちます。 - 試行回数に上限を設けます。通常は 5 回とし、その後はメッセージをキューに入れて後で処理します。 - ジッターを加え、複数のワーカーが同時に再試行しないようにします。 - 冪等性を確保し、エラーが届く前に実際は送信済みのメッセージを二重送信しないようにします。 - 短いループで直ちに再試行すること。すでに問題を抱えているサービスへの負荷が増します。 - 接続の問題として扱うこと。電話番号には問題ありません。 - 上限なしで再試行すること。再試行ポリシーで想定すべき期間を超えて障害が続くこともあります。 **再試行すべきですか？** はい。指数バックオフを使ってください。再試行が有効なエラーの一つです。 **電話番号に影響はありますか？** いいえ。プラットフォーム側の障害です。 **どのくらい続きますか？** 通常は数秒から数分です。5 回のバックオフで大半をカバーできます。 **実際の障害とどう区別できますか？** 継続しているかどうかで判断できます。継続的な監視が推測なしに答えを示します。 --- ## WhatsApp エラー 131000：問題が発生しました https://easycoexistence.com/ja/docs/whatsapp-error-131000 エラーコード 131000 は、Meta が分類できなかった理由でメッセージ送信に失敗したことを示します。未分類のエラーに該当するため、まずはバックオフを入れて 1 度だけ再試行し、続く場合はレスポンスのトレース ID を添えてサポートへ報告してください。 ### 実際に何を示すエラーですか Meta の送信処理で失敗したものの、名前付きのコードに対応付けられなかったあらゆる状態を含みます。実際の一時的な障害や内部エラーのほか、API の新しいバージョンでは固有のコードがあるものの、その時点ではコード化されていなかった状態も含まれます。 対象範囲が広いため、常に同じ対応が正しいとは限りません。1 度だけならノイズです。同じ受信者で繰り返し発生するなら、サポートチケットを開く価値のあるパターンです。 ### このエラーが出たらどうすればよいですか 次の順に対応し、1 つ成功した時点で止めてください。 - 短いバックオフを入れて 1 度だけ再試行してください。一定数は一時的なエラーです。 - トレース ID を含むレスポンス全体を記録してください。サポートが確認を求める情報です。 - 1 件の受信者だけか、すべての受信者かを確認してください。1 件だけならその電話番号側、すべてならプラットフォーム側の可能性があります。 - 再試行しても続く場合は、トレース ID とタイムスタンプを添えてサポートチケットを開いてください。 - 無期限に再試行すること。2 回失敗したなら一時的なエラーではありません。 - トレース ID を破棄すること。サポートチケットを調査可能にする唯一の情報です。 - 電話番号が壊れていると考えること。通常はそうではありません。 **再試行すべきですか？** バックオフを入れて 1 度だけ再試行してください。それ以上は一時的なエラーではありません。 **トレース ID とは何ですか？** エラーレスポンスに含まれる識別子で、Meta サポートが特定のリクエストを検索できます。 **電話番号が停止しているという意味ですか？** 通常は違います。他の送信が成功しているか確認してください。 **いつサポートチケットを開くべきですか？** 再試行しても繰り返す場合です。トレース ID とタイムスタンプを添えてください。 --- ## WhatsApp エラー 131021：送信者と受信者が同じ https://easycoexistence.com/ja/docs/whatsapp-error-131021 エラー 131021 は、送信者と受信者が同じ番号であることを示します。WhatsApp ではビジネス番号から自分自身にメッセージを送れません。原因のほとんどは、別の電話ではなく接続済みの番号宛てにテストメッセージを送っていることです。 ### 発生する理由 番号を接続した後、まずテストメッセージを送るのが一般的ですが、手元にある番号は接続したばかりの番号だけだからです。自然な操作ですが、プラットフォームでは拒否されます。 変更できる設定はありません。WhatsApp の個人向けアプリでは自分用メモとして自分宛てに送信できますが、API では利用できません。 ### 正しくテストする方法 別の番号を使い、どちら向きの送信をテストしているかを確認してください。 - テストの受信者には個人の電話を使います。接続済みの番号以外なら、どの WhatsApp 番号でも利用できます。 - 自由に送信できるかテストするには、まずテスト用の番号からビジネス番号へメッセージを送ってもらい、24 時間のサービスウィンドウを開きます。 - その時間外をテストするには、承認済みのメッセージテンプレートを送信します。その時間外に許可されるのはこれだけです。 - テストだけのために 2 つ目のビジネス番号を登録する必要はありません。通常の個人番号で十分です。 - テストのために接続済みの番号へ送信する。仕様上、拒否されます。 - 自分用メモが API でも使えると思う。利用できません。 - 顧客から先にメッセージを受け取らず自由形式のメッセージをテストする。その場合は 131047 で失敗します。 **自分の番号にメッセージを送れますか？** いいえ。WhatsApp では API 経由で自分の番号に送信できません。 **このための設定はありますか？** いいえ。プラットフォームの仕様です。 **何を使ってテストすればよいですか？** 個人の電話を含む、別の WhatsApp 番号を使ってください。 **テストが 131047 で失敗したのはなぜですか？** 自由形式のメッセージには、顧客から過去 24 時間以内にメッセージを受信している必要があるためです。 --- ## WhatsApp エラー 131045：電話番号が未登録 https://easycoexistence.com/ja/docs/whatsapp-error-131045 エラー 131045 は、電話番号が Cloud API のメッセージ送信用に登録されていないことを示します。WhatsApp Business アカウントへの番号追加と、送信用の登録は別の手順です。このエラーは、後者が完了していないことを意味します。 ### なぜ 2 段階あるのですか WhatsApp Business アカウントには、まだ送信に使われていない番号も追加できるためです。番号を追加すると所有権が確立され、登録すると Cloud API のメッセージ送信が有効になり、2 段階 PIN が設定されます。 手動設定では、これらは別々の API リクエストです。そのため、最初の手順だけ完了して 2 つ目を忘れがちです。すると番号はアカウントに表示され、ダッシュボード上も正しく見えますが、送信するたびにこのエラーが返されます。 ### どうすれば解決できますか 番号がどのように追加されたかによって異なります。 - 手動設定の場合は、電話番号 ID と 2 段階 PIN を使って登録エンドポイントを呼び出します - プロバイダー経由の Coexistence オンボーディングでは、登録はフロー内で行われます。そのため、このエラーは通常、フローが完了していないことを示します - 別のアカウントから最近移行した番号の場合は、新しいアカウントで登録をやり直す必要があります - 登録自体に失敗する場合は、通常 PIN が原因です。この場合はエラー 133005 が返されます - ダッシュボードに表示される番号は、送信の準備ができていると思い込むこと。表示されることと登録済みであることは別です - オンボーディングの途中で離脱すること。最後の手順で登録が行われます - 登録ではなく認証に関する 133006 と混同すること **登録とは何ですか** アカウントへの追加とは別に、Cloud API のメッセージ送信用に番号を有効化することです **自分で行う必要がありますか** 手動設定では必要です。Coexistence フローでは自動で処理されます **繰り返し行う必要はありますか** 番号を別のアカウントへ移行した場合にのみ必要です **登録に失敗した場合はどうなりますか** 通常は 2 段階 PIN が原因で、エラー 133005 が返されます --- ## WhatsApp エラー 133005：2 段階認証の PIN が正しくありません https://easycoexistence.com/ja/docs/whatsapp-error-133005 エラー 133005 は、登録時に入力された 2 段階認証の PIN が正しくなかったことを示します。これは番号を最初に登録したときに設定した 6 桁の PIN です。誤った入力を繰り返すと以降の試行がロックされるため、再試行よりも復旧の手順が重要です。 ### PIN はどこで設定されるのか PIN は、番号を Cloud API でのメッセージ送信用に初めて登録するときに設定されます。その後の再登録でも必要になり、番号を別のアカウントへ移行する場合も同様です。 問題はこの空白期間から始まります。セットアップ時に一度だけ設定し、1 年間使わなかった PIN は、書き留められていないことが多く、設定した本人もすでに異動していることがよくあります。その結果、番号の移行や再登録という、ただでさえ余裕のない場面でエラーが表示されます。 ### 誰も PIN を知らない場合 推測するより時間はかかりますが、確実に復旧できる手順があります。 - 推測入力をやめてください。失敗を繰り返すと 133008 が返され、一定期間は試行がロックされます。 - WhatsApp Manager で、その番号の 2 段階認証の設定から PIN を変更します。2 段階認証を無効にする API エンドポイントはありません。 - 管理者は、電話番号 ID に対する POST で API から新しい PIN を設定し、その PIN で再登録することもできます。 - 復旧できたら、次の担当者が見つけられる場所に新しい PIN を保管してください。 ### 次回に備えるには PIN は個人の情報ではなく、インフラの一部として扱ってください。アカウントの認証情報と同じ場所に置き、たまたまセットアップを担当した人ではなく企業が管理し、その担当者が退職しても残るようにします。 対策を怠った場合の損失はエラーそのものではありません。エラー自体は些細なものです。本当の損失は、必要なときに稼働中の番号を移行も再登録もできなくなることです。 - 何度も推測して入力する。133008 が返され、ロックされます。 - PIN を企業ではなく一人の担当者だけが保管している。 - セットアップ後は二度と必要ないと考える。移行時に必要になります。 **この PIN はどこで設定されましたか？** 番号を Cloud API でのメッセージ送信用に初めて登録したときです。 **PIN がわからない場合はどうすればよいですか？** WhatsApp Manager で、その番号の 2 段階認証の設定から変更するか、API で新しい PIN を設定してください。 **推測を続けるとどうなりますか？** 試行がロックされ、代わりにエラー 133008 が返されます。 **PIN はいつ必要になりますか？** 登録時に必要で、再登録や移行のたびにも必要になります。 --- ## WhatsApp エラー 133008：PIN の試行回数が多すぎます https://easycoexistence.com/ja/docs/whatsapp-error-133008 エラー 133008 は、2 段階認証 PIN の誤入力が多すぎて、一定期間それ以上の試行がブロックされたことを示します。133005 エラーが繰り返された後に発生するため、PIN を間違えた場合は再試行せず、停止するのが正しい対応です。 ### 発生する条件 PIN の誤入力が短時間に続くと発生します。間違った PIN はもう一度試したくなりやすいため、すぐにこの状態へ達することがあります。しかし、再試行してはいけません。最初の 133005 は、推測を続けずに PIN を正しく確認するためのサインです。 ロックされると、その期間が過ぎるまで番号を登録できません。その間に正しい PIN が分かっても同じです。 ### ロック中にすること 無理に試さず、待機してください。 - 試行を停止してください。再試行すると、ロック期間が短くなるどころか延長されることがあります。 - 待機中に PIN を確認またはリセットしてください。アカウントレベルのトークンで 2 段階認証を無効にするか、Meta サポートに問い合わせます。 - 正しい電話番号 ID を登録していることを確認してください。別の番号に対する PIN エラーも同じように見えます。 - 状態を繰り返し確認せず、期間が過ぎてから再試行する計画を立ててください。 - ロック中も試行を続けること。解決にはつながらず、ロック期間が延長されることがあります。 - 待機時間を PIN の正しいリセットに使わないこと。 - 番号が利用停止されたと思い込むこと。PIN のロックアウトは一時的で、ポリシー適用とは無関係です。 **ロックはどのくらい続きますか？** Meta が設定した期間です。その間に再試行すると、短くなるどころか延長されることがあります。 **番号が利用停止されたのですか？** いいえ。これは認証時のロックアウトで、ポリシー適用とは無関係です。 **ロック中に PIN をリセットできますか？** はい。待機時間の最も有効な使い方です。 **なぜ発生したのですか？** 133005 が返される PIN の誤入力を繰り返したためです。 --- ## WhatsApp エラー 133006：電話番号が認証されていません https://easycoexistence.com/ja/docs/whatsapp-error-133006 エラー 133006 は、メッセージ送信用に電話番号を登録する前に認証が必要であることを示します。SMS または音声通話で送られるコードにより、番号を管理していることを証明します。これは番号の追加や登録とは別の手順です。 ### 認証と登録の違い 認証では、企業がその番号を管理していることを証明します。登録では、Cloud API でのメッセージ送信を有効にします。認証が先、登録が後の順序で行われ、このエラーは最初の手順が完了していないことを示します。 実際に必要なのは、その番号で SMS または自動音声通話のコードを受け取れる人がいることです。誰も応答できない番号は認証できません。多くの場合、API リクエストよりも、これが本当の障害になります。 ### 認証を妨げるもの ほとんどの場合、技術的な問題ではなく、物理的な要因です。 - 端末または SIM を誰も持っていません。以前の所有者から引き継いだ番号でよく起こります。 - SMS を受け取れない固定電話です。この場合は音声認証を使用します。 - プロバイダーがコードを遮断または遅延させる仮想番号です。 - その番号が別の WhatsApp アカウントですでに登録されています。先に解決する必要があります。 - 認証前に登録を試みること。順序が重要です。 - 固定電話で SMS を選ぶこと。音声認証はこのために用意されています。 - 仮想番号なら確実にコードを受け取れると思い込むこと。実際には受け取れない番号も多くあります。 **認証するにはどうすればよいですか？** 番号自体に SMS または自動音声通話で送られるコードを使用します。 **固定電話の場合はどうすればよいですか？** SMS を使えない番号向けの音声認証を使用してください。 **これは登録と同じですか？** いいえ。認証は管理権限を証明し、登録はメッセージ送信を有効にします。 **スキップできますか？** いいえ。認証が完了するまで、登録時にこのエラーが返されます。 --- ## WhatsApp エラー 131050：ユーザーが受信を拒否しました https://easycoexistence.com/ja/docs/whatsapp-error-131050 エラー 131050 は、受信者が企業からのメッセージ受信を拒否したことを示します。障害ではなく、技術的な回避策もありません。相手が選択した結果なので、正しくは記録して送信を停止します。 ### 回避策がない理由 この仕組みは、拒否の意思を受け入れない企業から人々を守るために存在します。回避できるプラットフォームは、企業にとっても利用者にとっても価値がありません。 Meta は、その後の動きも確認しています。受信を拒否した相手への送信を繰り返すと、品質評価に影響するシグナルにつながります。品質評価が低下すると、その受信者だけでなく番号全体のメッセージ送信容量が減少します。 ### 代わりに行うこと 正しく一度記録し、システム全体でその情報を尊重できるようにします。 - 連絡先に受信拒否を記録し、自動的に再送されないようにします - エラーが発生したキャンペーンだけでなく、すべてのキャンペーンと自動化で番号を抑制します - 別の企業番号から連絡しようとしないでください。同じ人による同じ選択です - 後から相手が先にメッセージを送ってきた場合は、ウィンドウが再開され、返信できます。決めるのは相手であり、企業ではありません - 再試行する。相手が変更するまで、意図的かつ恒久的にブロックされています - 失敗したキャンペーンだけで抑制し、別のキャンペーンが翌日に再送してしまう - 同じ相手に別の番号から連絡する。無視されている選択は同じです **もう一度メッセージを送れますか？** 相手が先にメッセージを送った場合のみです。その時点でサービスウィンドウが再開します。 **回避する方法はありますか？** ありません。試みると品質評価に悪影響を与えます。 **番号全体に影響しますか？** 受信拒否はその受信者に適用されますが、繰り返し送信すると全体の品質評価に影響します。 **リストから削除すべきですか？** 失敗したキャンペーンだけでなく、すべての場所で抑制してください。 --- ## WhatsApp エラー 130497：受信者の国が許可されていません https://easycoexistence.com/ja/docs/whatsapp-error-130497 エラー 130497 は、アカウントで受信者の国へのメッセージ送信が許可されていないことを示します。これは受信者ではなく地域に関する制限であり、通常はリクエストの間違いではなく、アカウント側の制限を意味します。 ### 国の制限が発生する原因 複数の原因があり、すべてが永続的とは限りません。 - 新しい、または未認証のアカウントで、企業認証後に制限が解除される場合 - Meta がプラットフォーム全体に適用している制限対象の国 - 審査や措置の際に設定されたアカウントレベルの制御 - 国番号が間違った形式の番号。意図していない国への送信としてエラーが発生します。 ### まず番号の形式を確認する 自分で修正できる唯一の原因であり、ほかの原因よりもよくあるためです。 先頭の 0 を残した電話番号や、国番号を省略してデフォルト値が適用された番号は、意図とは異なる国の番号として解釈されます。その結果、関係のない国への制限によって送信に失敗します。番号が正しい国番号を含む国際形式で、数字のみになっているかを確認すれば、最も可能性の高い原因をすぐに排除できます。 - 受信者に原因があると思い込む。制限されているのはアカウントとその国です。 - 再試行する。試行の間で状況は変わりません。 - 番号の形式確認を省略する。これは自分で確認できる唯一の原因です。 **受信者にブロックされていますか？** いいえ。アカウントに対する国レベルの制限です。 **解除できますか？** 一部は一時的なもので、企業認証により解除されます。プラットフォーム全体に適用される制限もあります。 **番号の形式ミスの可能性はありますか？** はい。まず確認する価値があります。間違った国番号は、別の国の番号として解釈されます。 **再試行すると解決しますか？** いいえ。試行しても制限は変わりません。 --- ## WhatsApp エラー 132007：テンプレートポリシー違反 https://easycoexistence.com/ja/docs/whatsapp-error-132007 エラー 132007 は、テンプレートが WhatsApp のビジネスメッセージポリシーに違反していることを示します。現在の内容ではメッセージを送信できないため、リクエストを変更するのではなく、テンプレートを書き直して再提出してください。 ### ポリシーが実際に禁止していること 最初のテンプレートを書くときに多くの人が想定するより、対象は限定的です。 - 依頼していない相手には、一方的なプロモーションと受け取られるコンテンツ。 - 特定の金融、健康、規制対象製品などの禁止カテゴリ。 - 送信者を偽ったり、存在しない関係や提携を示したりする表現。 - 誤解を招く緊急性や、返信を迫る構成。 ### 文面と同じくらいカテゴリが重要な理由 ユーティリティとして提出したテンプレートがマーケティングの内容に見える場合、文面自体に問題がなくてもポリシー違反になります。Meta がテンプレートをカテゴリ分けするのは、カテゴリごとに同意に関する期待が異なるためです。ユーティリティカテゴリでプロモーションメッセージを送ると、その前提に反します。 実務上は、カテゴリに正直な内容としてテンプレートを書くことが重要です。マーケティング用だと明示したテンプレートは承認されます。配信通知を装ったマーケティング用テンプレートは承認されず、カテゴリを変えずに文面だけ修正しても、解決できないことがほとんどです。 - 送信を再試行する。問題はリクエストではなく、テンプレートです。 - 表面的な修正だけで再提出する。カテゴリが間違っていれば、文面を直しても解決しません。 - 承認が恒久的だと思い込む。テンプレートは後から 132016 により無効化されることがあります。 **送信を再試行できますか？** いいえ。テンプレートを書き直して再提出してください。 **文面に問題がなさそうなのに、なぜ拒否されたのですか？** 多くの場合はカテゴリが原因です。ユーティリティとして提出したマーケティングメッセージは、文面にかかわらずポリシー違反になります。 **再提出にはどのくらいかかりますか？** 審査は通常すぐに完了しますが、保証された時間はありません。 **これは 132016 と同じですか？** いいえ。132016 は、承認後にテンプレートが恒久的に無効化された場合のコードです。 --- ## WhatsApp エラー 132012：テンプレートパラメーター形式の不一致 https://easycoexistence.com/ja/docs/whatsapp-error-132012 エラー 132012 は、送信したパラメーター値がテンプレートで定義された形式と一致しないことを示します。変数が 3 つあるテンプレートには、正しい型の値を順序どおりに 3 つ指定する必要があります。少しでも異なると、このエラーが発生し、部分送信にはなりません。 ### 何を一致させる必要がありますか すべてです。部分一致はなく、すべての不一致は通知なしに失敗します。 - 個数：本文にプレースホルダーが 3 つある場合、本文パラメーターも過不足なく 3 つ必要です。 - 順序：パラメーターは位置で対応付けられます。2 つを入れ替えると、値が誤った場所に入ったメッセージが送信されるか、型が異なる場合はこのエラーになります。 - 型：通貨や日付のパラメーターには定義済みのオブジェクト形式があり、プレーンテキストとして送信できません。 - コンポーネント：ヘッダー、本文、ボタンのパラメーターは別々のリストであり、1 つにまとめることはできません。 ### 本番環境を止める編集 テンプレートを編集する人と API を呼び出す人は、同じとは限りません。メッセージをわかりやすくするために誰かが変数を追加し、テンプレートが再承認されると、変更していない連携からの送信がすべて失敗し始めます。 これは、発生してから気付くのではなく、事前に防ぐべき問題です。テンプレート状態の Webhook を購読すると、編集をイベントとして受け取れます。また、テンプレートの変数数を連携の仕様の一部として扱い、変更時に確認すれば、文言の改善が障害に変わるのを防げます。 - 念のため余分なパラメーターを送る。多すぎても少なすぎても誤りです。 - 位置パラメーターを名前付きとして扱う。位置だけで対応付けられます。 - 送信処理のコードを確認せずにテンプレートを編集する。 **パラメーターはいくつ送信しますか？** テンプレートで定義されている数と同じ数を、順序どおりに送信します。 **余分なパラメーターを送信できますか？** いいえ。多すぎる場合も少なすぎる場合と同じように失敗します。 **なぜ突然この問題が起きたのですか？** 通常は、テンプレートが編集されて変数の数が変わったことが原因です。 **パラメーターには名前がありますか？** いいえ。位置で対応付けられるため、順序が重要です。 --- ## WhatsApp エラー 132016：テンプレートが完全に無効化されています https://easycoexistence.com/ja/docs/whatsapp-error-132016 エラー 132016 は、テンプレートが完全に無効化され、二度と使用できないことを示します。通常は品質低下の末に発生します。受信者がそのテンプレートで送信されたメッセージをブロックまたは報告し、品質評価が低下した結果、Meta が無効化します。 ### この状態になるまで 通常、一度で発生するわけではありません。承認済みのテンプレートが受信者に嫌がられると、ブロックや報告が蓄積し、品質評価が緑から黄色、赤へ下がって一時停止されます。一時停止が繰り返されると、最終的に完全な無効化に至ります。 監視していれば、その流れはすべて確認できます。テンプレート品質 Webhook は変更のたびに通知し、テンプレートが黄色になった時点で、まだ対応できる時間があることを警告します。これを無視すると、使えるテンプレートが使用できないものになります。 ### 対処方法 次の 2 つを、この順番で行ってください。 - このテンプレートでの送信を停止し、別のテンプレートに切り替えてください。このテンプレートは二度と使えません。 - 受信者に嫌がられた理由を理解してから代替テンプレートを作成してください。そうしないと、代替テンプレートも同じ経路をたどります。 - 文面だけでなく、対象者も確認してください。想定していない相手に良いテンプレートを送っても、ブロックは蓄積します。 - テンプレート品質 Webhook を購読し、次の低下が無効化ではなく黄色の段階で分かるようにしてください。 - 新しい名前で同じテンプレートを作り直すこと。失敗したのは内容です。 - 黄色の品質評価を無視すること。黄色は警告で、赤は結果です。 - 問題が対象者にあったのに、文面のせいにすること。 **再び有効化できますか？** いいえ。完全に無効化された状態は元に戻せません。 **新しい名前で作り直せますか？** 作り直せますが、低下の原因は内容なので、同じ経路をたどる可能性が高いです。 **132015 との違いは何ですか？** 132015 は解除される一時停止です。こちらは解除されません。 **事前に分かりましたか？** はい。テンプレート品質 Webhook は、この状態に至る前に低下を通知します。 --- ## WhatsApp エラー 131056：1 人の受信者へのメッセージが多すぎます https://easycoexistence.com/ja/docs/whatsapp-error-131056 エラー 131056 は、短時間に企業の電話番号から 1 人の受信者へメッセージを送りすぎたことを示します。これはアカウント全体のスループットとは別の、ペア単位のレート制限です。通常は、自動化処理が同じ動作を繰り返していることを意味します。 ### なぜペア単位なのですか 防ぐ対象は全体的な送信量ではなく、1 人の相手にメッセージが集中することだからです。アカウントが全体のスループットの範囲内でも、1 分間に 1 人へ 30 件のメッセージを送ることはできます。その場合、アカウント全体の量に関係なく、相手にはスパムとして届きます。 そのため、この制限はアカウントではなくペアに適用されます。全体のレート制限に近づいたことがない、利用量の少ない番号でも発生するのはこのためです。 ### 通常は何が原因ですか ほとんどの場合、人が入力したものではなく自動処理が原因です。 - 配信失敗を送信失敗と判断し、再送するリトライループ - 返信を送信する Webhook ハンドラーが、同じイベントに対して複数回呼び出される - チャットボットが 1 つの返信を短いメッセージに分割し、短時間に続けて送信する - 開発中に同じ番号へ繰り返し送信するテストスクリプト ### どうすれば防げますか アカウント単位だけでなく、会話単位でスロットリングします。送信前に受信者ごとの 1 分あたりのメッセージ数を制限すれば、ほとんどコストをかけずに、このエラーとその背後にある顧客体験の問題を防げます。 メッセージの重複排除も同じくらい重要です。Webhook イベントは複数回配信されることがあり、処理済みの message id かどうかを確認せずに返信を送るハンドラーは、負荷が高い状況でまさにこのパターンを引き起こします。 - リトライして、すでにメッセージが集中している受信者へさらに送信する - アカウント単位だけでスロットリングする。この制限は受信者単位です - message id による重複排除なしで Webhook イベントを処理する **これはアカウントのレート制限ですか？** いいえ。アカウントの制限は 130429 です。こちらは受信者単位です。 **利用量の少ない番号でなぜ発生しますか？** 制限はアカウント全体ではなく、ペアに適用されるためです。 **どうすれば止められますか？** 会話単位でスロットリングし、message id によって Webhook イベントを重複排除します。 **リトライすべきですか？** いいえ。同じ受信者へ別のメッセージを送ることになります。 --- ## WhatsApp エラー 80007：WhatsApp Business アカウントのレート制限 https://easycoexistence.com/ja/docs/whatsapp-error-80007 エラー 80007 は、WhatsApp Business アカウントがレート制限に達したことを示します。メッセージングスループットではなく、管理や読み取りの API 呼び出しに適用されます。通常の原因はポーリングです。データの変化よりはるかに頻繁にステータスを確認している状態です。 ### 何がカウントされますか 顧客へのメッセージではなく、アカウントに対する API 呼び出しです。 - 電話番号、その品質評価、スループットレベルの読み取り - メッセージテンプレートの一覧取得と読み取り - サブスクリプションと Webhook の設定に関する API 呼び出し - スケジュールで実行するすべてのステータス確認。通常、呼び出し量はここで増えます。 ### 修正すべき原因はポーリングです 少数の番号に対して 30 秒ごとにステータスを確認すると、月に数回しか変化しないデータに対して、1 日に数千回の API 呼び出しが発生します。やがてこの制限に達し、重要な変化が起きたまさにその時点でポーリングが機能しなくなります。 Webhook なら仕組みが逆になります。Meta は品質評価の変更、アカウントの更新、メッセージテンプレートのステータス変更が発生した時点で通知を送ります。API 呼び出しを消費せず、どのポーリングよりも速く届きます。変更の検知には Webhook を使い、ポーリングは主な仕組みではなく、低頻度の整合性確認に限定するのが適切です。 - 短い間隔でステータスをポーリングする。ほとんど変化しないデータに制限を使い切ります。 - リトライを追加して対処する。制限をさらに早く消費します。 - 130429 と混同する。130429 はメッセージ送信に関するコードです。 **これはメッセージ送信に関するエラーですか？** いいえ。その制限は 130429 です。80007 は管理や読み取りの API 呼び出しに適用されます。 **原因は何ですか？** 通常は、短い間隔でステータスをポーリングしていることです。 **代わりに何をすべきですか？** Webhook を購読し、ポーリングは低頻度の整合性確認に限定してください。 **自然に解除されますか？** はい。制限時間が過ぎると解除されます。ただし、ポーリング方法を変えなければ再発します。 --- ## 代理店・コンサルティング会社向け WhatsApp Coexistence https://easycoexistence.com/ja/whatsapp-coexistence-for-agencies 代理店は顧客ごとに同じ壁にぶつかります。番号はスタッフがすでに対応しているもので、移行すると WhatsApp Business アプリが使えなくなるためです。Coexistence なら、仕事の進め方を変えずに顧客の番号を接続できます。 ### なぜ顧客の番号が多くの連携を妨げるのですか？ その番号を変更できるのは顧客であり、すでにあらゆる場面で使われているからです。 顧客の番号は車両、請求書、Web サイト、そして何年分もの過去の会話に表示されています。誰かが一日中スマートフォンで応答し、常連客の名前も把握しています。その番号の移行を含む提案をした瞬間、WhatsApp Business アプリが使えなくなり、その担当者は構築した仕組みに移らなければなりません。多くの顧客が断るのは当然です。 そのため、多くの代理店は非公式のゲートウェイに頼りました。顧客が最も重視する電話の利用を維持できた一方、利用停止のリスクは問題が起きるまで見えませんでした。Coexistence は、同じ約束を公式に実現する方法です。 ### 顧客の導入は実際にどのように進みますか？ 顧客が自分の電話で行う操作は 1 つだけで、所要時間は約 2 分です。 接続リンクを送ると、顧客はそれを開き、Meta のポップアップで Business Portfolio と番号を選び、WhatsApp Business アプリでコードをスキャンします。必要なのはそれだけです。インストールも認証情報の受け渡しもなく、スキャンが完了した時点でアプリは使い続けられます。 番号はあなたの配下ではなく、顧客の Business Portfolio に残ります。これは 2 つの理由で重要です。接続の所有者を聞かれたときの明確な答えになり、顧客が代理店を変更しても関係が維持されるからです。事後に説明するより、あらかじめ約束しやすい仕組みです。 ### 顧客が 20 社いる場合、どのようになりますか？ 1 つのアカウントに 20 個の番号を登録し、番号ごとに定額料金が発生します。一覧も確認できます。 使い切れない階層や、一定数を超えると変わるプランはありません。21 件目の顧客を追加する操作も、最初の 1 件と同じです。各番号には品質評価、メッセージング階層、接続状態が表示されるため、番号の状態が悪化した顧客にも、問い合わせを受ける前に気づけます。 この規模では、その可視性に大きな価値があります。接続がひそかに失敗しても、WhatsApp Business アプリはほとんどの場合そのまま動き続け、顧客には知る方法がありません。監視がなければ、自動化が止まった理由を顧客から尋ねられて初めて気づくことになり、よい始まり方とはいえません。 ### 担当者が人に代わって導入を進められますか？ 大部分は可能です。できない部分は、どのみち顧客自身が行う操作です。 MCP コネクタを使えば、アシスタントが get_connect_link を呼び出して顧客が開くリンクを作成し、set_webhook_destination でその番号をあなたのシステムに接続できます。その後、番号の接続状態を確認して稼働を確かめられます。ダッシュボードを開く人がいなくても、これが一連の流れです。 できないのはコードのスキャンです。Meta の導入処理はブラウザーで実行され、その番号を保持する電話が必要です。これは不足ではなく、意図された保護です。自分の番号を認証できるのは顧客本人だけであり、それが適切な仕組みです。 - 顧客にスタッフが気づかないと約束してから番号を移行すること。移行するとアプリが使えなくなり、すぐに気づかれます。 - 顧客の番号を自社の Business Portfolio に接続すること。各番号は顧客のポートフォリオに残し、接続の所有者も顧客にしてください。 - 大規模運用で監視を任意扱いすること。20 社に 20 個のひそかな障害があれば、例外ではなくサポート業務になります。 **顧客ごとにあなたのサービスのアカウントが必要ですか？** いいえ。管理するすべての番号を 1 つのアカウントに登録でき、料金は番号ごとに発生します。コネクタにはすべての番号が表示され、支援する企業に制限なく利用できます。 **接続を所有するのは私ですか、それとも顧客ですか？** 番号は顧客の Business Portfolio に残ります。あなたが接続を管理しますが、Meta との基礎となる関係は顧客のものです。顧客に尋ねられたときも、それが正確な答えです。 **顧客が離れたらどうなりますか？** 番号を接続解除すると、顧客の WhatsApp Business アプリは以前とまったく同じように使えます。接続していたことによって、番号が恒久的に変更されることはありません。 **メッセージ料金を Meta に支払うのは誰ですか？** 顧客が、自分の WhatsApp Business アカウントに設定した支払い方法で支払います。料金が当社を経由することはないため、誰かが上乗せすることもありません。 --- ## Meta Tech Provider とは何か、なぜ重要なのか https://easycoexistence.com/ja/meta-tech-provider Meta Tech Provider は、認証済みの Business Manager 上で自社の Meta アプリを運用し、そのアプリを通じて他社の WhatsApp 番号を接続できます。EasyCoexistence もその一つです。そのため、番号はリセラーのアカウント配下ではなく、お客様自身のポートフォリオに直接接続されます。 ### Tech Provider は実際に何をするのですか？ 他社が WhatsApp 番号を接続するためのアプリを運用します。 企業がオンボーディングを開始すると、Meta の Embedded Signup が開き、アプリの認証を求めます。そのアプリは Tech Provider に属しており、認証されると、企業に代わって番号を操作できます。接続状態の確認、メッセージの送信、テンプレートの管理、Webhook の配信先設定が可能です。プロバイダーが提供する機能は、すべてこの関係を基盤にしています。 このステータスが、接続を正規のものにします。Meta は、App Review を経て、認証済み Business Manager 上に自社アプリを持つ企業に付与します。これにより、他社の認証情報を保持するだけのスクリプトとプロバイダーが区別されます。 ### なぜアプリの所有者が重要なのですか？ 顧客の電話番号が、どのアカウントに紐づくかを決めるからです。 他社のプロバイダーアカウント上に構築されたツールは、そのアカウントの制約を引き継ぎます。一般的な自動化プラットフォームで接続数の上限に達するのはこのためです。プラットフォームが 1 つのプロバイダー関係を保持し、それを利用者全員で共有します。 自社アプリを使う場合、接続は顧客の Business Portfolio と Meta の間で直接行われます。番号は顧客のものであり続け、リセラーが保持することもありません。次の番号の追加も、最初の番号と同じ操作で行えます。代理店にとって、これは技術上の細部ではなく、顧客から番号の管理者を尋ねられたときの答えです。 ### このステータスには何が必要ですか？ 認証済み Business Manager、App Review に合格するアプリ、そしてフローを記録したデモが必要です。 企業認証により、アプリが実在する法人と結び付けられ、Meta は登記情報と照合して書類を確認します。App Review では、アプリが何をリクエストし、その理由は何かを審査します。WhatsApp の場合は、オンボーディングが最初から最後まで正常に動作することを示す録画動画も含まれます。費用はかかりませんが、すべてに時間が必要です。ここは短縮できません。 自社で構築することを検討している場合は、この点を知っておく必要があります。自社所有の 1 つの番号を接続するだけなら、これらは不要です。顧客の番号を接続するにはすべて必要で、待ち時間は数日ではなく数週間単位になります。 ### 番号を接続する企業にとって、何が変わりますか？ 変わるのは 3 つですが、どれもインターフェースには表示されません。 番号は企業自身の Business Portfolio に接続されるため、Meta との関係も企業のものです。会話料金は Meta から企業の WhatsApp Business Account に直接請求されるため、途中の事業者が上乗せすることもありません。また、1 つのアカウントが保持できる番号数に上限はありません。共有されたプロバイダー関係を分割して使わないためです。 変わらないのはオンボーディングそのものです。Embedded Signup は Meta 独自のフローで、ポップアップも Meta のものです。コードのスキャンは WhatsApp Business アプリで行います。Tech Provider がこれらを置き換えるのではなく、利用できるようにする役割を担います。 - すべてのプロバイダーが自社の Tech Provider ステータスを持つと思い込むことです。実際には他社のステータス上に構築されたものも多く、そこから接続数の上限が生じます - 期限を決めて取得できると考えることです。App Review の所要時間は企業が管理できません - 単なるバッジとして扱うことです。これはアカウント間の関係であり、顧客の番号をどのポートフォリオが保持するかを決めます **これは Meta が EasyCoexistence を推奨しているという意味ですか？** いいえ。どのプロバイダーも、そのように示すべきではありません。Tech Provider は、承認済みアプリを通じて他社の番号を接続できる技術的なステータスです。その上に構築された製品への推奨を意味しません。 **自分で Tech Provider になれますか？** はい。認証済み Business Manager を持ち、App Review に進む企業であれば、無料で利用できます。費用ではなく、待ち時間が必要です。 **私の番号を保持する Business Portfolio はどれですか？** お客様のものです。接続はお客様のポートフォリオと Meta の間で行われ、当社のアプリには番号を操作する権限が付与されます。当社のアカウント配下に移ることはありません。 **接続できる番号数に上限はありますか？** ありません。他のサービスで上限に達するのは、多数の利用者が 1 つのプロバイダー関係を共有するためです。この仕組みでは共有しません。 --- ## WhatsApp Coexistence の料金を事業者別に比較 https://easycoexistence.com/ja/whatsapp-coexistence-pricing-compared 事業者の料金は、番号単位、シート単位、メッセージ単位の 3 種類の単位で決まります。そのため表に出ている料金は直接比べられず、実際の費用は接続数を決めて初めて見えてきます。このページでは 1 件、10 件、50 件の番号で試算します。 ### なぜ表に出ている料金は比べられないのですか？ 各社が課金している対象が違い、その単位によってどのような事業に向くかが決まるためです。 番号単位の料金は、保有する WhatsApp の回線数に応じて決まります。代理店が実際に管理できる単位であり、EasyCoexistence、360dialog、Dualhook が採用しています。 シート単位やコンタクト単位の料金は、対応する人数と、やり取りする顧客の数に応じて決まります。WATI と respond.io がこれにあたり、オペレーターのチームそのものを購入する場合に適した単位です。 メッセージ単位の料金は送信量だけで決まります。これは Twilio のモデルで、プラットフォーム料金も番号ごとの料金もありませんが、Meta の請求に加えてメッセージごとに課金されます。 そのため、公平に比べられるのは接続数を決めた場合だけです。下の表はその方法で整理しています。 ### プラットフォーム型の事業者は、同じ件数でいくらになりますか？ プラットフォーム型の事業者は、料金が番号の件数ではまったく変わらないため、同じ列に並べて公平に比べることはできません。変わるのはシートとコンタクトの数です。 WATI の公開プランは、3 から 10 ユーザー、月間アクティブコンタクト 500 から 2,500 件の範囲です。respond.io は 5 ユーザー、コンタクト 1,000 件で US$ 79 を公開しており、上位は US$ 279 です。YCloud は無料プランのあと US$ 39、US$ 89、US$ 399 を公開し、ユーザーとチャネルはオプションとして月額それぞれ US$ 10 と US$ 5 で追加できます。 番号が 1 件のサポートチームなら、これらは十分に競争力があり、接続だけでは得られない受信トレイも含まれます。顧客の番号が 50 件ある代理店では、オプションの追加分が費用の中心になり、それは会話ごとではなくチャネルごとに発生します。 判断の決め手は、支払っている受信トレイに実際にログインする人がいるかどうかです。 ### どちらも課金しない Twilio はどうですか？ Twilio はメッセージ 1 通につき、送信と受信のそれぞれで US$ 0.005 を公開しています。これに加えて Meta のテンプレート料金がかかりますが、こちらは上乗せなしでそのまま請求されます。公開されている料金には、月額のプラットフォーム料金も番号ごとの料金もありません。 そのため、ほとんど送信しない番号を持つ方法としては最も安く、活発に使う番号を運用する方法としては最も高くなります。使われていない 50 件の番号は費用がかかりませんが、実際に会話をしている 50 件の番号では、メッセージごとに料金がかかり続けます。 なお、Twilio の料金ページは Coexistence には触れていません。番号上で WhatsApp Business アプリを使い続けることが重要なら、ほかを比べる前にその点を問い合わせてください。 ### 代理店は結局どれを選ぶべきですか？ 事業の中で増えていくものと、単位が一致している事業者です。 増えるのが顧客の番号なら、数量割引のある番号単位の料金だけが、成長に対して不利にならない形です。EasyCoexistence は 5 件まで 1 件あたり US$ 9 で、番号が増えるにつれて US$ 1 まで下がります。そのため顧客が 50 件になれば、1 件あたりの料金は最初の 1 件より安くなります。 増えるのが 1 つの受信トレイで対応するオペレーターなら、シート単位のプラットフォームが適した選択です。このページもそれに異論はありません。WATI と respond.io はそのために作られており、きちんと機能します。 増えるのが少数の番号でのメッセージ量なら、実際の送信量で Twilio のメッセージ単位モデルとほかを試算してみる価値があります。 この製品が想定しているのは、自社のものではない番号を保有する代理店や開発者です。その場合、数量割引のある番号単位の料金が、事業と同じ方向に拡大する唯一の形です。件数が増えるほど、番号 1 件あたりの料金が下がります。 - 表に出ている料金を直接比べること。3 つの異なる単位で課金されており、最も小さい数字が最適とは限りません。 - どこかが Meta のメッセージ料金に上乗せしていると思い込むこと。このページの事業者はどれも上乗せしておらず、Meta がお客様に直接請求します。 - 記載がないことを機能がないことと読み違えること。料金ページに Coexistence の記載がない場合は、この表を信じる前に事業者へ確認してください。 **これらの料金は最新ですか？** 2026 年 9 月時点で各事業者の料金ページに掲載されていた内容で、上の数値からリンクしています。料金は変わるため、決める前に出典をご確認ください。 **EasyCoexistence は、なぜ番号 1 件あたりの料金が下がるのですか？** 接続を監視するコストは、件数に比例しては増えないためです。50 件の番号を持つ代理店でも作業が 50 倍になるわけではないので、料金も 50 倍にはなりません。 **これらの事業者は Meta の料金に上乗せしていますか？** このページの事業者はどれも上乗せしていません。Meta は、お客様ご自身の WhatsApp Business アカウントの支払い方法にメッセージ料金を請求します。そのため、間に入る事業者が割引することもできません。 **Coexistence に対応している事業者はどこですか？** YCloud と 8x8 が対応を文書化しており、Dualhook と EasyCoexistence は Coexistence を前提に作られています。ほかの料金ページには記載がないものもありますが、それは対応の有無の証拠にはならないため、直接問い合わせることをおすすめします。 --- ## WhatsApp Coexistence 用語集 https://easycoexistence.com/ja/whatsapp-coexistence-glossary WhatsApp Coexistenceに関する用語は混同しやすく、実際には同じ言葉を別の意味で使うことが混乱の原因です。このサイトで使う定義を、詳しく説明するページへのリンクとともにまとめています。 ### なぜ用語がこれほど混乱を招くのですか？ これらの用語のいくつかは、同じ階層に見えても、実際には異なる階層のものを指すからです。 Business PortfolioにはWhatsApp Business Accountが含まれ、その中に電話番号があり、それぞれに電話番号 IDがあります。会話ではこの4つすべてがアカウントと呼ばれるため、「アカウントが動作しているか確認してください」という文が、4種類の異なる確認を意味することがあります。このプラットフォームにある2つの24時間ウィンドウでも同じことが起こります。両者は無関係なものを測定しますが、常に取り違えられています。 もう一つの理由は、Metaとプロバイダーが同じものに異なる言葉を使い、プロバイダー同士でも用語が一致していないことです。このページでは、存在する場合はMeta独自の用語を使い、当社独自の用語である場合はそのことを明確にします。 ### 実際の運用で重要な違いは何ですか？ 3つあります。どれも誰かの1日を費やす原因になっています。 顧客対応ウィンドウと同期ウィンドウはどちらも24時間ですが、互いに関係ありません。一方は自由入力メッセージを配信できるかどうかを決めるもので、顧客の最後のメッセージから数えます。もう一方はチャット履歴を引き続き取得できるかどうかを決めるもので、オンボーディングから数えます。 接続済みデバイスはAPIではありません。別の場所でWhatsAppの一般ユーザー向けクライアントにログインした状態です。非公式ツールはこれを自動化するため、電話番号が利用停止になる原因になります。 また、Webhookの送信先は番号の設定ではありません。アカウントに対するアプリのサブスクリプションを上書きする設定です。そのため、接続を削除すると消え、再接続時に設定し直す必要があります。 **CoexistenceはCloud APIとは別のAPIですか？** いいえ。Coexistenceは、WhatsApp Business アプリをその番号で引き続き使えるようにしながら、Cloud APIに番号をオンボーディングする方法です。エンドポイント、メッセージ形式、ルールは同一です。 **Business PortfolioとWABAの違いは何ですか？** Business PortfolioはMeta Business Managerにおける企業レベルのコンテナです。その中にWhatsApp Business Accountがあり、電話番号を保持します。1つのポートフォリオに複数のWABAを含めることができます。 **BSPはTech Providerと同じですか？** 重なる部分はありますが、異なるものを指します。Tech Providerは、自社のアプリを通じて他社の番号を接続できるMeta上のステータスです。BSPは通常、メッセージングプラットフォームを販売する企業を指し、その企業自身がこのステータスを持つとは限りません。 **MCPはWhatsAppとどう関係しますか？** 本質的な関係はありません。MCPはAIアシスタントにツールへのアクセスを提供するプロトコルで、WhatsApp MCPサーバーは番号をそのツールの一つとして公開します。メッセージを受信することはできず、依頼されたときだけ動作します。 --- ## WhatsApp Webhook フィールドと送信先 https://easycoexistence.com/ja/docs/webhook-fields WhatsApp Business アカウントは、名前付きフィールドとしてイベントを送信します。2 つは会話内容を運び、エンドポイントにルーティングされます。6 つは運用状態を運び、監視の基盤になります。どのフィールドかを把握することが、アーキテクチャを決めます。 ### 各フィールドは何を運びますか？ messages は、顧客が番号に送信するすべての内容を運びます。テキスト、メディア参照、返信、リアクションが含まれます。smb_message_echoes は、チームが WhatsApp Business アプリから送信した内容を運びます。このフィールドは Coexistence 番号にのみ存在し、ソフトウェアが人間の返信を認識するために使われます。 account_update は接続状態を運びます。アプリがアカウントからアンインストールされたときの PARTNER_REMOVED、ACCOUNT_OFFBOARDED、ACCOUNT_RECONNECTED、制限や違反のイベントが含まれます。phone_number_quality_update は品質評価とスループットの変更を運びます。account_alerts は Meta がアカウントに対して発生させたアラートを運び、account_review_update は審査結果を運びます。 business_capability_update はメッセージ上限と機能の変更を運び、phone_number_name_update は表示名の承認と却下を運びます。 ### この分岐はアーキテクチャ上なぜ重要ですか？ 会話内容がプロバイダーに届くかどうかを決めるためです。 上書き設定により、2 つのメッセージフィールドは Meta から直接エンドポイントに送信されます。6 つの運用フィールドは引き続きプロバイダーに送信されるため、誰もメッセージを保持せずにダッシュボードとアラート機能を実現できます。 そのため、「メッセージを保存しない」という説明は、ポリシーではなく構造に基づく場合があります。メッセージフィールドが別の場所に配信されるなら、それを保存できるコード経路はありません。この場合、上書き設定のないアカウントはデフォルトのコールバックに戻り、ハンドラーはイベントを永続化せずに破棄します。 ### ハンドラーはどのフィールドを想定すべきですか？ 上書き設定がある場合は、2 つのメッセージフィールドだけです。それ以外のフィールドは、エラーにするのではなく無視するようハンドラーを実装するのが適切です。 Meta は時間とともにフィールドを追加するため、ペイロードの形に予告なくキーが増えることがあります。フィールド名で分岐し、認識できないものを無視するハンドラーなら動作し続けます。形を固定して想定するハンドラーは、初めて見たイベントでエラーになります。 smb_message_echoes も、ノイズとして扱わず明示的に処理する価値があります。これがないと、ソフトウェアは人間がすでに返信したことを把握できません。その結果、顧客が同じ質問に対する返信を 2 つ受け取ることになります。 - 一般的なペイロードだと考える。すべてのイベントにはフィールド名があり、ハンドラーはそれで分岐すべきです。 - smb_message_echoes を無視する。これがないと、ソフトウェアはすでに返信した人間の上から返信します。 - 認識できないフィールドをスキップせずエラーにする。Meta は確認なくフィールドを追加します。 **一部のフィールドだけ受信できますか？** 上書き設定によりメッセージ経路を自分側へ移せます。監視がこの分岐を基盤にするため、運用フィールドの分岐は固定です。 **通常の Cloud API 番号にも smb_message_echoes はありますか？** いいえ。Coexistence 番号では、アプリから人間が送信すると同時に、API からソフトウェアも送信するため存在します。 **送信先を設定しない場合、メッセージイベントはどうなりますか？** 当社のデフォルトのコールバックに届き、永続化されずに破棄されます。 **フィールド名は Meta のものですか、それとも独自のものですか？** Meta のものです。当社が考案した名前ではないため、一度覚える価値があります。 --- ## WhatsApp Webhook エンドポイントの認証 https://easycoexistence.com/ja/docs/webhook-verification イベントを配信する前に、Meta は hub.mode、hub.verify_token、hub.challenge を含む GET をエンドポイントに送ります。エンドポイントはトークンを比較し、チャレンジをレスポンスボディとしてそのまま返す必要があります。それ以外の場合、配信は始まりません。 ### Meta は具体的に何を送りますか？ 3 つのクエリパラメータを付けた GET リクエストを URL に送ります。hub.mode は subscribe に設定されます。hub.verify_token は、送信先の設定時に指定したトークンです。hub.challenge は、この試行のために Meta が生成する値です。 エンドポイントでは、hub.verify_token と指定したトークンを比較してください。一致した場合は、200 と hub.challenge だけをレスポンスボディ全体として返します。JSON で包まず、値を引用符で囲まず、一部のフレームワークが標準で追加する末尾の改行も付けません。 トークンが一致しない場合は 403 を返します。これがプロトコルのすべてで、意図的に小さく設計されています。 ### 間違った返答はなぜ何も知らせずに失敗しますか？ 認証の失敗は、あなたのシステムのエラーではなく、Meta 側で配信が存在しない状態になるためです。 チャレンジが正しく返されないと、Meta はその送信先への配信を開始しません。サーバーは認証に 200 を返し、ログにはリクエストの到着が記録されますが、どのダッシュボードにも問題は表示されません。唯一の症状はメッセージが届かないことです。そのため、多くの人はこれをハンドシェイクの問題ではなく Coexistence の問題だと判断します。 だからこそ、呼び出し前の検証が重要です。EasyCoexistence は Graph リクエストを送る前に、URL が HTTPS であり、認証トークンが指定されていることを確認します。そのため、不正な送信先は接続済みのように見えるのではなく、すぐに失敗します。 ### ほかに認証を妨げるものはありますか？ コードとは無関係なものが 3 つあります。 エンドポイントの前に認証を置くことです。ゲートウェイ、基本認証レイヤー、IP 許可リストは Meta のリクエストを拒否します。Meta には提示できる認証情報がありません。認証なしで認証ルートに到達できる必要があります。 リダイレクトです。Meta は指定された URL を呼び出しますが、正規ホストへの 301 がハンドシェイクを完了する形で追跡されるとは限りません。最終 URL を指定してください。 そして、レスポンスをシリアライズするフレームワークです。ハンドラーから文字列を返しても、すべてを JSON で包む設定だと、チャレンジが引用符で囲まれたボディになります。その場合は一致しません。 - JSON を返すこと。ボディは余計なものを付けず、チャレンジの値をそのまま返す必要があります。 - エンドポイントを認証の背後に置くこと。Meta には認証情報がないため、拒否されます。 - リダイレクトする URL を Meta に渡すこと。最終 URL を使用してください。 **どのトークンを使用すればよいですか？** 任意の文字列を指定できます。URL を知っている他の人ではなく、Meta からのリクエストだとエンドポイントが判断するために使います。 **認証はどのくらいの頻度で行われますか？** 設定時と、送信先を設定するたびに行われます。動作しているエンドポイントがイベントごとに再認証されることはありません。 **自分でテストできますか？** はい。3 つのパラメータを付けて自分のエンドポイントを呼び出し、ボディがチャレンジの値と完全に一致することを確認してください。 **認証中にサーバーが停止していた場合はどうなりますか？** ハンドシェイクが失敗し、送信先は有効になりません。もう一度保存すると再実行されます。 --- ## MCP ツールリファレンス https://easycoexistence.com/ja/docs/mcp-tools-reference このコネクタは、アカウント内のすべての番号を対象に 16 個のツールを提供します。list_numbers が最初なのは、ほかのすべてのツールがそこから取得した connection_id を受け取るためです。料金の支払いが滞ると 6 個が制限されます。外部に作用する 4 個、アクセストークンを返す get_api_credentials、create_connect_link です。残りの 10 個、つまり接続状態とテンプレートの読み取り用ツールと Partner API の設定用ツールは引き続き利用できます。 ### 各ツールは何をしますか？ 読み取り：list_numbers は、接続済みの電話番号、ステータス、品質評価、メッセージング階層を返します。ほかのすべての呼び出しはここから始まります。get_number_health は、Meta の最新スナップショットに加え、最近の監視タイムライン、Webhook イベント、ポーラーのチェック結果をまとめて返します。get_api_credentials は、Graph API のベース URL、WABA id、phone number id、利用可能な場合はアカウント独自のアクセストークンを返します。 送信：send_message は 24 時間のウィンドウ内で自由文を送信します。この間の返信は無料です。send_template は承認済みのテンプレートを送信します。まだメッセージを送っていない相手との会話を始める方法です。list_templates、create_template、get_template_status は、テンプレートのライフサイクルを扱います。 接続設定：set_webhook_destination は受信メッセージとアプリからのエコーをシステムへ転送します。null を渡すと設定がリセットされます。get_connect_link は、新しい番号を接続するためのダッシュボードリンクと手順を返します。get_docs は、製品ドキュメントを Markdown として返します。 Partner API は、自社の顧客が番号を接続するソフトウェアや代理店向けです。get_partner_setup は、料金の状態、API キー、イベント URL、次の手順を返します。create_api_key は Partner API キーを発行して一度だけ表示し、明示的な確認がない限り既存のキーを置き換えません。revoke_api_key はキーを無効にします。これも確認後のみです。set_partner_events_url はステータスイベントの送信先を設定し、署名シークレットを一度だけ返します。create_connect_link は、顧客 1 人向けに 1 時間有効なホスト型の接続リンクを作成します。POST /api/v1/connect-sessions と同じ処理です。 ### connection_id が重要なのはなぜですか？ 特定の番号に指示を結び付ける値であり、アシスタントが推測できないためです。 番号に作用するすべてのツールは connection_id を受け取ります。その値を取得できる場所は list_numbers だけです。実際には、メッセージの送信を頼まれたアシスタントは最初に list_numbers を呼び出します。そのため、セッションの最初のリクエストは通常、それ以降より時間がかかります。 また、複数の番号を持つアカウントでも、仕組み上あいまいさがありません。デフォルトの番号も暗黙の選択もないため、番号を特定しない指示は推測されず、どの番号についての指示か確認されます。 ### 料金の支払いが滞るとどうなりますか？ 制限されるのは 6 個のツールです。外部に作用する send_message、send_template、create_template、set_webhook_destination、アカウントのアクセストークンを返す get_api_credentials (ブロックされたアカウントが Graph API から直接送信できてしまうため)、そして新しい番号を接続する create_connect_link です。ほかの読み取りはすべて引き続き利用でき、Partner API の設定用ツール get_partner_setup、create_api_key、revoke_api_key、set_partner_events_url も同様です。 これは見落としではなく、意図した仕様です。ブロックされた理由を確認できない、または番号の接続状態を確認できないアカウントは、サポートへの問い合わせ以外に復旧の道がありません。接続状態の監視も同じ読み取り機能に依存しているため、最も必要なときに監視を止めることになります。 その結果、料金の支払いが滞ったアカウントでも、自分の状態について質問でき、監視も継続されます。停止するのは、顧客に届く処理だけです。 - コネクタがメッセージを受信すると考える。MCP はリクエストとレスポンスで動作し、受信トラフィックには Webhook が必要です。 - connection_id をハードコードする。list_numbers から取得する値であり、書き留めておくものではありません。 - 料金の支払いが滞ったアカウントは完全にオフラインだと考える。読み取りと監視は意図的に継続されます。ただし、送信に使うアクセストークンを含む認証情報は除きます。 **どのツールを呼び出すか選ぶ必要がありますか？** いいえ。自然な言葉で依頼すれば、アシスタントが選びます。ツールの説明はそのために書かれています。 **会話を読み取れますか？** いいえ。受信メッセージは指定した Webhook の送信先へ転送されます。コネクタが読み取るのはアカウントと番号の状態です。 **get_docs は役に立ちますか？** 思った以上に役立ちます。アシスタントに当社のドキュメントを Markdown で渡すため、Coexistence のルールに関する回答は記憶ではなく当社のドキュメントに基づきます。 **1 つのコネクタで複数の顧客を扱えますか？** はい。1 つのアカウントに必要な数の番号を登録でき、list_numbers がすべて返します。 --- ## 番号を手順どおりに接続する https://easycoexistence.com/ja/docs/connecting-a-number 接続は Meta 独自の Embedded Signup で進めます。Business Portfolio、WhatsApp Business Account、番号を選び、WhatsApp Business アプリでコードをスキャンします。約 2 分で完了し、その間もアプリは使い続けられます。 ### フローでは何が起こりますか？ Meta のポップアップが開き、3 つの項目を順番に確認します。 最初は Business Portfolio です。これは Business Manager における企業レベルのコンテナです。次に、その中の WhatsApp Business Account を選びます。最後に電話番号を選びます。この番号は、すでに WhatsApp Business アプリに登録されていなければなりません。Coexistence は新しい番号を作るのではなく、アプリで使っている番号を接続するためです。 その後、フローは電話に移ります。Meta がコードを表示し、その番号が入った端末で誰かが WhatsApp Business アプリを開いてコードをスキャンします。ブラウザから離れるのはこの手順だけで、企業に代わって他の人が実行することはできません。 ### オンボーディング中に決まり、変更できないことは何ですか？ 既存のチャット履歴を共有するかどうかです。この確認は一度だけ行われ、その接続では変更できません。 「はい」を選ぶと、最近の会話履歴が API に同期されるため、ソフトウェアは何もない状態ではなく会話の背景を把握した状態で始められます。「いいえ」を選ぶと、API が認識するのは接続した時点以降のメッセージだけです。どちらも妥当な選択で、新しい会話を扱う連携では多くの場合問題ありません。ただし、接続を解除して再接続しない限り、決定をやり直せません。 時間制限もあります。同期はオンボーディングから 24 時間以内に開始する必要があり、実行できるのは 1 回だけです。どちらかを逃すと警告ではなく分かりにくいエラーになるため、連携作業中ではなく、その日に履歴の共有を決めることをおすすめします。 ### 開始前に何を準備すべきですか？ 3 つあります。準備しておくと、途中でフローを中断せずに済みます。 番号を所有する Business Portfolio へのアクセス権です。通常は連携を担当する人ではなく、企業の所有者が持っています。次に、その番号が入った電話を用意します。ロックを解除し、WhatsApp Business アプリをインストールしておいてください。最後に、できれば Webhook の送信先も準備します。オンボーディングの最後に設定できるため、後で思い出すより確実です。 完了前にフローを閉じると、番号がアカウントに紐づいていても登録されていない状態になることがあります。その場合、最初の送信でエラーが発生します。フローを最初からもう一度実行すれば解決できます。 - 電話を近くに置かずに始める。別の端末から後でスキャンすることはできません。 - 番号が表示された時点でポップアップを閉じる。その後にも手順があり、止めると登録されません。 - 連携が完成するまで履歴の共有を決めない。オンボーディングから 24 時間後に期限切れになります。 **自分が所有していない番号も接続できますか？** その番号を所有する企業だけが認証できます。相手にリンクを送り、本人の電話でフローを完了してもらってください。 **オンボーディング中にアプリは停止しますか？** いいえ。コードをスキャンしている間も含め、終始使い続けられます。 **番号が個人向け WhatsApp アプリに入っている場合はどうなりますか？** 先に WhatsApp Business アプリへ移行する必要があります。Coexistence が接続できるのは Business アプリの番号です。 **フローをやり直せますか？** はい。接続を解除して再接続すると、フローを最初から実行できます。チャット履歴を共有するかどうかも改めて選べます。 --- ## 24 時間のカスタマーサービスウィンドウ https://easycoexistence.com/ja/docs/customer-service-window カスタマーサービスウィンドウは、顧客があなたの電話番号にメッセージを送ると始まり、24 時間続きます。期間内はフリーテキストを送信でき、返信も無料です。期間外に配信できるのは、Meta が承認したメッセージテンプレートだけです。 ### 時間は正確にはいつ始まりますか？ 顧客がメッセージを送信したときに始まり、顧客が新たにメッセージを送信するたびにリセットされます。 ここは誤解されやすいポイントです。ウィンドウは、あなたが最後に送信したメッセージ、会話の開始時刻、チケットを開いた時刻を基準にするものではありません。顧客から直近に届いたメッセージを基準にします。そのため、やり取りが続いている会話は実質的に終了せず、一方的な会話は 1 日後に終了します。 また、このウィンドウは電話番号単位ではなく、連絡先単位です。同じ電話番号でも、ある顧客は期間内、別の顧客は期間外という状態が、同じ時点で発生します。 ### 期間内と期間外には何を送信できますか？ 期間内は、フリーテキスト、メディア、必要に応じたメッセージテンプレートなど、何でも送信できます。期間外は、Meta がすでに承認したメッセージテンプレートだけです。 これがメッセージテンプレートの存在する理由です。メッセージテンプレートは、まだメッセージを送っていない相手との会話を開始または再開するための承認済みの方法です。受信者がメッセージを求めていないため、事前に審査されます。 Coexistence の電話番号では、さらに制約があります。WhatsApp Business アプリからメッセージテンプレートを送信できないため、期間外の送信は API 経由で行う必要があります。スマートフォンから対応するチームは、進行中の会話には自由に返信できますが、休止中の会話を再開することはできません。これが、電話番号を接続する実務上の理由の一つです。 ### なぜ連携では本番環境で初めてこの仕組みに気づくのですか？ テストは常にウィンドウ内で行われるためです。 連携を構築する担当者は、自分自身にメッセージを送信し、数秒後に返信します。これは 24 時間以内なのでフリーテキストが機能し、すべてのテストに合格します。最初に失敗する実際のケースは、前日にメッセージを送った顧客です。通常、この時点では本番環境へのリリース後です。 堅牢な実装では、送信前に分岐します。連絡先が最後にメッセージを送ってからどのくらい経過したかを確認し、フリーテキストの経路かメッセージテンプレートの経路を選びます。最初から実装すれば、ほとんどコストはかかりません。後から対応すると、コードベース内のすべての送信箇所を探す必要があります。 - 自分が最後に送信したメッセージを基準にする。ウィンドウを開くのは顧客のメッセージです。 - 電話番号単位の仕組みとして扱う。同じ電話番号でも、2 つの会話は異なる状態になり得ます。 - メッセージの直後だけテストする。この場合は常にウィンドウ内です。 **ウィンドウを延長できますか？** いいえ。Meta が期間を固定しているため、どのプロバイダーも延長できません。 **メッセージテンプレートへの返信で再開しますか？** 再開するのは顧客の返信です。メッセージテンプレートを送信しても、それだけでフリーテキストのウィンドウが開くことはありません。 **返信は本当に無料ですか？** Meta はカスタマーサービスウィンドウ内に送信したメッセージには課金しません。課金対象は、期間外に開始した会話です。 **別の 24 時間ウィンドウについて読んだことがありますが、何ですか？** それはオンボーディングから数える同期ウィンドウで、送信ではなくチャット履歴を管理します。両者は無関係です。 --- ## WhatsApp メッセージテンプレート https://easycoexistence.com/ja/docs/message-templates テンプレートとは、事前に Meta へ審査を申請するメッセージです。承認後は、まだメッセージを送ったことがない相手にも、いつでも送信できます。24 時間のカスタマーサービス期間外に配信できる唯一の手段です。 ### 3 つの種類は何のためにありますか？ メッセージの種類を Meta に伝えるためのもので、種類によって審査と料金の両方が変わります。 utility は、注文の更新、予約確認、配送通知など、顧客の操作に関連する取引メッセージを対象とします。marketing は宣伝コンテンツを対象とし、送信には WhatsApp Business アカウントの支払い方法が必要です。authentication はワンタイムコードを対象とし、より厳しい形式のルールがあります。 種類を間違えると、よく審査に落ちます。utility のテンプレートに宣伝文句を入れると検出されます。検出される確率が高いため、試す価値はありません。 ### 変数はどのように機能しますか？ 番号付きのプレースホルダーを順番に埋め、コンポーネントごとに数えます。 「Hello {{1}}, your order {{2}} has shipped」という本文では、2 つの変数を定義しています。送信時は、本文に対して正確に 2 つの値を指定する必要があります。ヘッダーとボタンのパラメーターは 1 つのリストにまとめず、別々に数えます。そのため、合計数が合っていても送信が拒否されることがあります。 テンプレートの作成時には、実際のメッセージがどう見えるか審査担当者が確認できるよう、Meta が例の値も求めます。配置にもルールがあります。メッセージの先頭または末尾に変数を置く場合や、周囲のテキスト量に対して変数が多すぎる場合は、どちらも拒否されます。 ### 電話アプリから Coexistence の番号で送信できないのはなぜですか？ テンプレートはアプリの機能ではなくプラットフォームの機能であり、アプリにはテンプレートの概念がないためです。 これは早い段階で知っておくと役立ちます。Coexistence で接続した企業は、チームが電話から返信を続けられ、進行中の会話には返信できます。ただし、会話が途切れた相手とのやり取りをアプリから再開することはできません。その場合はテンプレートが必要で、テンプレートは API 経由でのみ利用できるためです。 したがって、予約送信、取引メッセージ、または当日にメッセージを送っていない相手への送信は、必ず API の処理になります。多くの企業にとって、接続を導入する目的はまさにこの不足を補うことです。 - テンプレートの作成と送信を同じ処理で行う。Meta は先に審査し、通常は数分ですが、1 日かかる場合もあります。 - ヘッダーと本文の変数をまとめて数える。変数はコンポーネントごとに数えます。 - utility のテンプレートに marketing の表現を使う。これは一貫して審査に落ちる理由です。 **審査にはどのくらいかかりますか？** 通常は数分ですが、最長で 1 日かかることもあります。どのプロバイダーも審査を早めることはできません。 **テンプレートは言語ごとに必要ですか？** はい。テンプレートは名前と言語の組み合わせで識別されるため、別の地域設定で同じ名前を使うと別のテンプレートになります。 **承認済みのテンプレートは編集できますか？** はい。ただし編集すると変数の仕様が変わるため、以前の個数を固定した送信処理が動かなくなります。 **支払い方法は必要ですか？** marketing の送信では必要です。ご自身の WhatsApp Business アカウントに設定してください。Meta が求めるもので、プロバイダーが代わりに追加することはできません。 --- ## account_update Webhook と切断理由の全一覧 https://easycoexistence.com/ja/docs/webhook-account-update account_update は、接続状態が変化したことを Meta が通知する仕組みです。イベント名で何が起きたかを判別でき、削除の場合は disconnection_info.reason で理由が分かります。その理由によって、番号が復旧するのか、完全に失われたのかを判断できます。 ### account_update にはどのようなイベントが含まれますか？ アカウントから WhatsApp Business アプリがアンインストールされたときは、PARTNER_REMOVED が送られます。これは正式な切断シグナルです。フィールドが false になったことから切断を推測するより、このイベントを基に処理してください。 番号が完全に利用停止されたときは ACCOUNT_OFFBOARDED、以前削除された接続が復旧したときは ACCOUNT_RECONNECTED が送られます。さらに、ACCOUNT_RESTRICTION や ACCOUNT_VIOLATION などの措置イベントと、名前に DISABLED または BAN を含むイベントもあります。 認証や承認の結果もここに届き、イベント名には VERIFIED または APPROVED が含まれます。ハンドラーはイベント名で分岐し、認識できないイベントは失敗させず情報として扱ってください。Meta は予告なくイベントを追加するためです。 ### 切断理由にはどのようなものがありますか？ 6 つあり、それぞれ意味が大きく異なります。 PRIMARY_INACTIVITY は、WhatsApp Business アプリがプライマリデバイスで約 14 日間開かれなかった場合です。復旧可能で、最もよく発生します。 COMPANION_INACTIVITY はコンパニオンデバイスでの同様の非アクティブ状態で、期間は約 30 日間と長めです。 BUSINESS_DOWNGRADE は、番号が一般向け WhatsApp アプリに戻ったことを示します。Business アプリが必要な Coexistence は終了します。 CHANGE_NUMBER は電話番号自体が変更された場合です。USER_RE_REGISTERED は新しいデバイスで再登録された場合です。ACCOUNT_DISCONNECTED は利用者が意図的に切断したか、措置によって切断された場合です。 この理由は disconnection_info.initiated_by とともに届き、利用者とシステムのどちらが実行したかを示します。 ### イベントより理由が重要なのはなぜですか？ PARTNER_REMOVED だけでは、どのように対応すべきか分からないためです。 PRIMARY_INACTIVITY による削除なら、番号は復旧します。企業がアプリを開いて再接続すれば、すべて再開します。これを顧客の離脱として扱うと、今も顧客である相手に解約メールを送ることになります。 BUSINESS_DOWNGRADE や ACCOUNT_DISCONNECTED による削除は別の状況です。一時的なものとして扱うと、接続がいつまでも保留状態に残ります。 理由なしで削除が届いた場合は、initiated_by が代替シグナルになります。利用者が実行した削除なら意図的と判断できますが、理由不明のシステムによる削除はそうとは限りません。この違いは、後でサポート対応に任せるのではなく、コードで判定する価値があります。 - すべての PARTNER_REMOVED を同じように扱うこと。理由によって、2 週間の停止なのか顧客の離脱なのかが分かれます。 - このイベントではなく、フィールドが false になったことから切断を推測すること。それが誤アラートの原因になります。 - 認識できないイベント名で処理を失敗させること。Meta はイベントを追加するため、ハンドラーは未知のイベントをスキップしてください。 **PARTNER_REMOVED は永続的ですか？** 通常は違います。多くは PRIMARY_INACTIVITY によるもので、アプリが開かれなかっただけです。再接続すればすべて復旧します。 **再接続すると Webhook の送信先も復元されますか？** いいえ。ここが注意点です。送信先はアプリのサブスクリプションに設定された override で、アプリとともにアンインストールされます。再設定が必要です。 **COMPANION_INACTIVITY とは何ですか？** プライマリデバイスではなくコンパニオンデバイスで発生する、同じ非アクティブ状態です。期間は約 30 日間と長めです。 **理由なしでこのイベントを受け取ることはありますか？** はい。その場合、意図的な削除かどうかを判断できる唯一のシグナルは disconnection_info.initiated_by です。 --- ## phone_number_quality_update Webhook https://easycoexistence.com/ja/docs/webhook-phone-number-quality-update phone_number_quality_update は、番号のスループットとメッセージング上限の変更を通知します。2026 年現在、名前に反して緑、黄、赤の品質評価は含まれず、電話番号からポーリングする必要があります。 ### この Webhook には実際に何が含まれますか？ イベント値として配信されるスループットとメッセージング上限の情報、および現在の上限を示すフィールドです。 実際の内容は、番号の容量が変わったことです。別のメッセージングティアに移行したか、スループットのレベルが調整されています。これらは連携で実行できる処理を変えるため記録する価値があり、ティアの低下は初期兆候にもなります。 フィールド名に反して、品質評価は含まれません。古いドキュメントを基に書かれたハンドラーは、ここで GREEN、YELLOW、RED を探しますが何も見つからず、品質は変化しないと判断してしまいます。 ### では、色の品質評価はどこから取得しますか？ スケジュールに従って、電話番号を直接読み取ります。 quality_rating フィールドは Graph API の電話番号オブジェクトにあり、待つのではなくポーリングする必要があります。そのため、接続を適切に監視するには Webhook レシーバーだけでなくポーラーも必要です。両者が扱う情報は異なり、どちらか一方だけでは不十分です。 これが、多くの連携で品質低下を検知できない理由でもあります。品質低下をプッシュ通知する仕組みはなく、WhatsApp Business アプリにも表示されません。エラー 131048 が発生する頃には、影響を受けた送信はすでに失敗しています。 - このペイロードで GREEN、YELLOW、RED を探す。2026 年現在、それらは含まれません。 - Webhook だけで監視を構築する。品質評価にはポーリングが必要です。 - ティアの低下を無視する。通常、問題を示す最初の目に見える兆候です。 **なぜフィールド名に品質が含まれているのですか？** 変更前から使われていた名前だからです。内容が変わっても名前が残ったため、混乱が生じます。 **品質評価はどのくらいの頻度でポーリングすべきですか？** 制限に達する前の低下を検知できる頻度にしてください。EasyCoexistence ではオンデマンドではなく、スケジュールに従ってポーリングします。 **アプリに品質評価は表示されますか？** いいえ。電話の WhatsApp Business アプリには表示されません。 **131048 は関連していますか？** はい。低い品質評価によって制限が始まると、番号が返し始めるエラーです。 --- ## smb_message_echoes Webhook https://easycoexistence.com/ja/docs/webhook-smb-message-echoes smb_message_echoes は、チームが WhatsApp Business アプリから送信した内容を配信します。Coexistence 番号にのみ存在します。電話から人が送信し、API からソフトウェアも送信するのは Coexistence 番号だけだからです。 ### このフィールドはなぜ存在するのですか？ Coexistence によって、API がもともと想定していなかった状況が生まれるからです。1 つの番号から 2 つの送信元が送信します。 通常の Cloud API 番号では、送信元はソフトウェアだけなので、報告するものはありません。Coexistence 番号では、チームが電話から回答を続けています。それを確認する方法がなければ、ソフトウェアは会話の半分について何が起きたか把握できません。 このエコーがその問題を解消します。誰かが WhatsApp Business アプリで返信を入力すると、受信メッセージと同じ形式のイベントとしてエンドポイントに届きます。ただし、企業からの送信であることが示されます。 ### 無視すると何が起きますか？ 顧客が 2 回回答を受け取り、対応が雑に見えてしまいます。 よくある流れは、顧客が朝 8 時に質問し、1 分以内に担当者が電話で対応する一方、返信を確認できなかった自動化が 3 分後に同じ質問へ回答するというものです。顧客から見ると、企業が自分の回答内容を把握していません。 処理は複雑ではありません。受信メッセージと同じように、会話にエコーを正確に記録し、送信前に直近の活動を確認してください。問題がテストでは見えないのは、人が回答するテスト会話になっていないからです。 - エコーを不要なものとして破棄する。人がすでに返信したことを示す唯一のシグナルです。 - すべての番号にこのフィールドがあると思い込む。Coexistence 固有のフィールドです。 - 人を含めずにテストする。これが、問題が決して現れない唯一の状況です。 **エコーにはメディアが含まれますか？** 送信された内容を通知します。メディアへの参照も含まれ、受信メッセージと同じ形式です。 **通常の Cloud API 番号にも存在しますか？** いいえ。Coexistence がなければアプリから人が送信することがないため、エコーする内容もありません。 **無効にできますか？** メッセージ経路に含まれています。その経路をエンドポイントへルーティングするとエコーも含まれます。コードで無視するかどうかは、影響を伴う選択です。 **料金はかかりますか？** いいえ。メッセージ送信ではなく、Webhook イベントです。 --- ## messages Webhook https://easycoexistence.com/ja/docs/webhook-messages messages は、顧客が番号に送るすべてを運ぶフィールドです。テキスト、メディア、返信、リアクション、インタラクティブな応答が含まれます。ルーティングされた Coexistence 番号では、Meta からエンドポイントへ直接届き、プロバイダーを経由しません。 ### ペイロードに含まれる内容 1 回の配信に 1 件以上のメッセージが含まれ、それぞれに送信者、ID、タイプがあります。タイプによって、存在する他のキーが決まります。 - 送信者の電話番号と、送信先番号の phone_number_id。 - 重複排除の基準になる wamid メッセージ ID。 - Unix タイムスタンプ。 - text、image、audio、video、document、sticker、location、contacts、reaction、button、interactive のいずれかの type。 - メディアタイプでは、データ本体ではなく取得に使う media id。 ### ルーティングされた番号で当社に届かない理由 override により、このフィールドと smb_message_echoes が、指定した送信先へ移動するためです。 Meta では、WhatsApp Business Account の Webhook 配信先をアプリで上書きできます。当社ではその上書き先をユーザーの URL に設定するため、メッセージの経路は当社のインフラを完全に離れます。当社側に配信されないため、コピーもキューも保持もありません。 送信先が設定されていない場合、これらのイベントは当社のデフォルトコールバックにフォールバックし、ハンドラーが永続化せず破棄します。これは保存に関する主張とコードパスの違いです。会話内容が送られる場所はありません。 ### 正しく応答する方法 処理の後ではなく、処理の前に 200 を返してください。 Meta は遅いレスポンスを失敗として扱い、再試行します。そのため、インラインで処理するハンドラーでは同じメッセージを複数回受け取ることがあります。すぐに応答し、ペイロードをキューまたはバックグラウンドタスクに入れて、リクエストの外で処理してください。 サーバーレスでは、これは任意ではありません。関数は応答後も処理を続けようとすると、その時点で停止される可能性があります。そのため、応答と処理は実際に分離する必要があります。 ### 重複排除 常に wamid を基準にしてください。再試行は例外ではなく、通常の動作だからです。 同じメッセージが 2 回届くのは、ユーザー側のバグとは無関係な理由でも起こります。遅いレスポンス、ネットワークタイムアウト、配信途中のデプロイなどです。受信済み ID を保存して重複をスキップする処理は数行で書けます。顧客に 1 回だけ返信するか、2 回返信するかを分ける重要な処理です。 Coexistence 番号では、smb_message_echoes も同じ経路で届くため、さらに重要です。すべてのイベントを新規として扱うハンドラーは、担当者がすでに返信した内容に重ねて返信してしまいます。 - 200 を返す前に処理する。Meta は遅いレスポンスを再試行するため、メッセージを 2 回処理します。 - 重複排除を省く。再試行は設計上の動作であり、例外ではありません。 - ペイロードにメディア本体が含まれると考える。取得に使う media id が含まれます。 **EasyCoexistence は顧客のメッセージを見ますか？** いいえ。このフィールドは上書き設定によりユーザーのエンドポイントへ配信されます。フォールバックコールバックに届いたものも、永続化せず破棄されます。 **1 回のリクエストに複数のメッセージが届くことはありますか？** はい。1 回の配信に複数件含まれることがあるため、ハンドラーは最初の 1 件だけでなく、すべてを反復処理してください。 **メディアを取得するにはどうすればよいですか？** ペイロードに media id が含まれます。番号のアクセストークンを使ってその ID で URL を取得し、ダウンロードしてください。 **smb_message_echoes とは何ですか？** WhatsApp Business アプリからチームが送信した内容を運ぶ関連フィールドです。Coexistence 番号にのみ存在します。 --- ## phone_number_name_update Webhook https://easycoexistence.com/ja/docs/webhook-phone-number-name-update phone_number_name_update は、表示名の申請結果を伝えます。decision フィールドで、Meta がその名前を承認したか却下したかが分かります。この結果が通知される場所はこのイベントだけで、WhatsApp Business アプリには何も表示されません。 ### 通知される内容 イベント上の判定として通知される、表示名申請の結果です。表示名は顧客が会話の上部で見る名前で、変更すると Meta の審査を受けます。 このイベントを購読する価値は、ほかに結果を伝える場所がないことです。WhatsApp Business アプリには何も表示されないため、数週間前に変更を申請した企業は、誰かがこのイベントを受信していない限り、変更が完了したか確認できません。 タイムラインに記録すれば、「名前の変更は完了したか」という問い合わせを、日付のある事実に変えられます。 ### 名前が却下される理由 主な理由は、アカウントが認証された企業と名前が一致していないことです。 - 法人名、登録商号、またはウェブサイト上のブランドと一致する名前は、承認されやすい傾向があります。 - 一般的な説明や、認証済みの企業と関係のない名前は、承認されにくい傾向があります。 - 名前ではなくキーワードに見えるものは、一貫して検出されます。 ### 名前がないと制限されること 一部の送信が制限されます。これにより、多くのユーザーは名前が承認されていなかったことに気づきます。 承認済みの表示名がない番号は、表示名を必要とする操作でエラー 131037 を返します。番号上のほかの機能は動作するため、実行した人にはコードの不具合に見えます。多くの場合、無料トライアルの接続時に名前の設定を飛ばし、その後確認していなかったことが原因です。 表示名の申請は見た目だけの手順ではなく、番号を正しく設定する一部です。番号を接続した日に実施する価値があります。 - 何も通知がないので承認されたと思い込む。判定結果はここにしか届かない - 名前ではなくキーワードを申請する。Meta は認証済みの企業情報と照合する - 無料トライアル中に表示名を設定せず、必要な送信でエラー 131037 に遭遇する **審査にはどのくらいかかりますか？** Meta は固定の期間を公開しておらず、どの事業者も審査を早めることはできません。 **後から名前を変更できますか？** はい。変更するたびに再度審査を受け、その結果としてここに別のイベントが生成されます。 **顧客には番号も表示されますか？** 承認済みの表示名が表示されます。表示名を設定する目的はそこにあります。 **エラー 131037 とは何ですか？** 承認済みの表示名がない番号が、それを必要とする操作を実行したときに返すエラーです。 --- ## message_template_status_update Webhook https://easycoexistence.com/ja/docs/webhook-message-template-status-update message_template_status_update は、テンプレートの審査状態が承認、拒否、一時停止、無効化に変わったことを通知します。連携でテンプレートを送信した後、Meta に定期的に問い合わせて結果を推測する必要がなくなります。 ### 通知されるステータス テンプレートはいくつかの状態を経て変化し、その都度ここに通知されます。 - 承認済み：以後、テンプレートを送信できます。 - 拒否：送信できず、理由がイベントに含まれます。 - 一時停止：品質が十分に低下したため、Meta が一時的に停止しています。 - 無効化：一時停止が繰り返された結果、恒久的に停止され、新しいテンプレートが必要です。 ### 監視が不要になる理由 代わりに何度も問い合わせ、頻度を推測する必要がなくなるためです。 このイベントがない場合、テンプレートを作成する連携は、結果が変わるまで一定間隔で get_template_status を監視する必要があります。頻度が高すぎると無駄になり、低すぎると承認済みのテンプレートが 1 時間も気付かれないままになります。 このイベントがあれば、送信して待つだけです。通常は数分以内に Meta が結果を通知し、連携は一度だけ対応します。顧客に代わってテンプレートを作成する代理店にとって、これは自動で処理が進むキューと、誰かが監視し続けるキューの違いになります。 ### 結果ごとの対応 承認済みの場合は簡単で、送信可能として記録します。価値があるのは残り 3 つの状態です。 拒否には理由が含まれるため、要約せずそのまま表示する価値があります。理由は通常、対応に十分なほど具体的で、言い換えると重要な情報が失われます。 一時停止は、内容が悪い反応を生んだことを意味します。停止が解除された後に同じ内容を再送しても、同じ結果になります。待つのではなく、編集するための合図です。 無効化は、そのテンプレートにとって最終状態です。前に進むには内容を変えた新しいテンプレートを作るしかなく、一時的な状態として扱うと送信経路が恒久的に壊れたままになります。 - このイベントが通知する承認結果を監視し続ける。 - 拒否理由をそのまま表示せず要約する。対応に必要なのは具体的な内容です。 - 無効化されたテンプレートが戻るのを待つ。この状態は恒久的で、新しいテンプレートが必要です。 **通常、承認にはどのくらいかかりますか？** 通常は数分ですが、最長で 1 日かかることもあります。どのプロバイダーも審査を早めることはできません。 **一時停止されたテンプレートは、無効化されたテンプレートと同じですか？** いいえ。一時停止は一定期間後に解除されますが、無効化は恒久的で、繰り返された一時停止の後に発生します。 **拒否理由は表示されますか？** はい。理由は対応に十分なほど具体的なので、編集せずそのまま渡す価値があります。 **1 つのテンプレートが一時停止中でも、他のテンプレートは送信できますか？** はい。状態が適用されるのはそのテンプレートであり、番号ではありません。 --- ## message_template_quality_update Webhook https://easycoexistence.com/ja/docs/webhook-message-template-quality-update message_template_quality_update は、特定のメッセージテンプレートに対する受信者の反応の変化を通知します。品質が一時停止につながる前に届くため、送信失敗後に原因を説明するのではなく、対応する時間を確保できる唯一のテンプレート通知です。 ### 何を測定しているか 電話番号全体ではなく、特定のメッセージテンプレートで送信したメッセージへの反応を測定します。ブロックや報告が大きく影響し、まったく反応しないことも評価に反映されます。 メッセージテンプレート単位で対象になるため、役立つ通知です。電話番号全体は健全でも、1 つのメッセージテンプレートだけが対象者の反応を悪化させることがあります。このイベントが、その違いを示します。これがなければ、電話番号上の他のメッセージテンプレートが通常どおり動作していても、最初に気づくのはそのメッセージテンプレートの送信失敗です。 ### 早期対応が重要な理由 この後に起きる状態はすべて、より悪く、元に戻しにくいからです。 品質が大きく低下するとメッセージテンプレートは一時停止され、送信を試みるたびにエラー 132015 が返されます。Meta が公表していない期間が過ぎるまで解除されません。一時停止が繰り返されると永久に無効になり、その時点で内容を新しい名前のメッセージテンプレートとして作り直す必要があります。 メッセージテンプレートがまだ送信できる間に品質通知が届くことが、編集のコストがない唯一のタイミングです。一時停止後も編集は適切な対応ですが、誰も気づかなかった期間だけ、送信経路はすでに止まっています。 ### 通常の原因 原因は、順に内容と対象者です。後者は忘れられがちです。 - ユーティリティーとして申告したメッセージテンプレートに、受信者が想定していなかった宣伝文句が含まれている。 - どの企業が送信しているのか、メッセージから明確に分からない。 - 最近やり取りした人ではなく、リスト全体に送信している。 - 依頼していない対象者に、同じメッセージテンプレートを大量送信している。 - 単なる情報として扱う。メッセージテンプレートがまだ機能している間に届く最後の通知です。 - 電話番号の問題だと考える。対象は 1 つのメッセージテンプレートです。 - 文面だけ編集して対象者を変えない。誰に送るかは、何を書くかと同じ通知につながります。 **これは他のメッセージテンプレートにも影響しますか？** いいえ。この通知は 1 つのメッセージテンプレートが対象で、同じ電話番号上の他のメッセージテンプレートには影響しません。 **アプリで確認できますか？** いいえ。電話の WhatsApp Business アプリには、メッセージテンプレートの品質に関する情報は表示されません。 **無視するとどうなりますか？** 品質低下が続くとメッセージテンプレートは一時停止され、一時停止が繰り返されると永久に無効になります。 **文面を編集すれば十分ですか？** 多くの場合は十分ですが、必ずとは限りません。誰に送るかは、何を書くかと同じ通知につながります。 --- ## history Webhook https://easycoexistence.com/ja/docs/webhook-history history は、Coexistence 番号にある既存の会話を API へ一度だけ転送します。履歴共有に同意してオンボーディングを完了すると届き、転送が実行されたことを連携に知らせる唯一のシグナルです。 ### 何が届くか WhatsApp Business アプリでその番号がすでに受信していた 1 対 1 のメッセージ履歴が転送されます。何年も使ってきた番号でも、ソフトウェアが何もない状態から始めずに済みます。 グループ会話は含まれません。Coexistence 番号ではグループ会話は API から完全に除外されます。また、アプリ独自の機能であるラベル、クイック返信、挨拶メッセージ、不在メッセージにも API 相当の機能はなく、デバイス上に残ります。 このフィールドは Coexistence 番号にだけ存在します。通常の方法でオンボーディングした番号には移行すべきアプリの履歴がないため、届くものもありません。 ### なぜ 1 回だけ発生するか この転送は継続的な機能ではなく、オンボーディングの一部だからです。 Embedded Signup では、企業の担当者に既存の会話を共有するかどうかを尋ねます。「はい」と答えることで同期が実行できるようになります。後から再び有効にする設定も、繰り返し実行するエンドポイントもありません。2 回目の試行では、解除されるレート制限ではなく 2593107 が返されます。 期限もあります。同期はオンボーディング後 24 時間以内に開始する必要があり、それ以降に試行すると 2593108 が返されます。どちらかを逃した場合は、番号を切断して最初からフローをやり直す必要があります。 ### ハンドラーでの処理方法 一度だけ届き、大量になる可能性があるバッチとして扱い、メッセージ経路に追加される通常のトラフィックとは分けて処理してください。 - すぐに受け付けて非同期で処理します。他の配信と同じ方法です。 - メッセージ ID で重複排除します。オンボーディングの前後では、history と通常のメッセージが重なる可能性があります。 - 届かない場合も想定します。担当者が履歴を拒否した番号では何も届かないため、連携はどちらの場合でも動作する必要があります。 - オンボーディングをこれに依存させません。転送が完了する前でも接続は利用できます。 - 履歴が存在することを前提に連携を構築すること。履歴なしで接続される番号は多数あります。 - 2593107 の後に同期を再試行すること。1 回限りのイベントなので、再試行しても同じエラーが返されます。 - 連携作業の開始まで履歴の選択を保留すること。通常、その時点では 24 時間の期限が過ぎています。 **どれくらいの履歴が届きますか？** Meta がプロバイダーではなく決める、直近の 1 対 1 の会話が一定期間分届きます。 **グループチャットも移行されますか？** いいえ。Coexistence 番号ではグループチャットは API から完全に除外されます。 **後からもう一度リクエストできますか？** いいえ。オンボーディングごとに 1 回だけ実行され、再実行するには番号を切断して再接続する必要があります。 **担当者が履歴を拒否した場合はどうなりますか？** このフィールドには何も届かず、API には番号が接続された時点以降のメッセージだけが届きます。 --- ## smb_app_state_sync Webhook https://easycoexistence.com/ja/docs/webhook-smb-app-state-sync smb_app_state_sync は WhatsApp Business アプリ自体の状態を伝えます。主な内容は、Coexistence 番号の接続時に行われる連絡先同期です。会話を伝える history とは別で、Coexistence 番号にのみ存在します。 ### 何を伝えるか アプリ側の状態です。実際には、企業が電話に登録していた連絡先を指します。 WhatsApp 番号を持つ連絡先はすべてプラットフォームに同期できます。そのため、何年も企業の電話に登録されている顧客を新しい番号として扱わず、ソフトウェアで認識できます。これは会話そのものとは別です。会話は history フィールドに届きます。一方は連絡先一覧、もう一方は会話記録なので、2 つは分かれています。 history と同様に、これは Coexistence にのみ存在します。一度もアプリに登録されていない番号には、同期するアプリ状態がありません。 ### 何を伝えないか アプリ独自の操作機能です。これらはプラットフォーム側に対応する情報がありません。 - 端末上に保存され、ソフトウェアから読み取れないラベル - クイックリプライ、あいさつメッセージ、不在メッセージ - カタログ、注文、ステータス - チャネル、音声通話やビデオ通話の履歴 ### 連携において重要な理由 初日から、誰がメッセージを送っているかをシステムが把握できるかどうかを左右するためです。 連絡先同期がなければ、受信メッセージは名前のない電話番号として届き、顧客情報との照合はシステム側の課題になります。同期があれば、企業自身の連絡先一覧を利用でき、照合の大部分が済んだ状態になります。 企業が同期を拒否したり、同期期間を逃したりする可能性があるため、両方のケースを想定しておく価値があります。連絡先が存在すると仮定した連携では、開いた人に大量の番号だけが表示されることになります。 - 連絡先が必ず存在すると考えること。企業は同期を拒否したり、同期期間を逃したりできます。 - このペイロードにラベルやクイックリプライが含まれると考えること。これらは端末に残ります。 - 連絡先一覧ではなく会話を伝える history と混同すること。 **これは history の同期と同じですか？** いいえ。こちらは主に連絡先などのアプリ状態を伝えます。history は会話を伝えます。 **複数回実行されますか？** 初回同期はオンボーディング時に一度だけ行われます。history と同じ 24 時間の期間内に実行されます。 **ラベルは取得できますか？** いいえ。ラベルはアプリの機能で、API 上の相当機能はありません。 **通常の Cloud API 番号にも存在しますか？** いいえ。通常の Cloud API 番号には、同期する WhatsApp Business アプリの状態がありません。 --- ## template_category_update Webhook https://easycoexistence.com/ja/docs/webhook-template-category-update template_category_update は、Meta がテンプレートを utility、marketing、authentication の間で再分類したことを知らせます。カテゴリによって会話にかかる Meta の料金が決まるため、誰も編集していなくても再分類で料金が変わります。 ### カテゴリが自動で変わる理由 Meta は申告された内容だけでなく、テンプレートに実際に書かれている内容も確認するためです。 utility として申請されたテンプレートにオファーが含まれている場合、安いラベルを付けた販促コンテンツとみなされます。審査時に発見されて却下されることもあれば、承認後、実際の利用で内容が確認されてから再分類されることもあります。このイベントは後者を知らせます。 こちら側で何かを実行したことが原因ではありません。テンプレートもコードも変わっていないのに、このイベントがなければ、最初に気付くのは予測と一致しない請求書です。 ### 変わる内容 それ以降、そのテンプレートが開始するすべての会話の料金です。 - Meta は utility、marketing、authentication の会話に異なる料金を設定しています。 - marketing の送信には、WhatsApp Business アカウントに支払い方法も必要です。 - 支払い方法がないアカウントで marketing に再分類されると、131042 が返されます。 - テンプレート自体は引き続き機能します。変わるのは料金と必要な条件です。 ### 再分類を避ける方法 最適化するより、正直に申告するほうが安く済みます。 utility のテンプレートは、注文、予約、配送など、顧客が行ったことを説明します。顧客の行動がなければ存在しないメッセージなら utility です。販売したいという理由で送るメッセージなら marketing です。そのように申告しておけば、望まないタイミングで後から変更されるより費用を抑えられます。 誤ったカテゴリでテンプレートを繰り返し申請すると、アカウント自体が注視されることもあります。marketing のメッセージに marketing 料金を支払うほうが、悪い結果を避けられます。 - 安くするため、販促コンテンツを utility として申告する。後から、より悪いタイミングで再分類されます。 - このイベントを無視する。自分で管理している内容を変えずに、請求額が変わります。 - 承認が最終決定だと思い込む。承認後にテンプレートが移動することもあります。 **テンプレートは停止しますか？** いいえ。送信は続きます。変わるのは会話の料金と、marketing の場合は支払い方法の要件です。 **再分類に異議を申し立てられますか？** カテゴリに関する異議申し立ては Meta 独自の窓口で扱われます。プロバイダーがカテゴリを変更することはできません。 **最も安いカテゴリはどれですか？** Meta は市場ごとに異なる料金を設定しています。正しいカテゴリのうち最も安いのは、メッセージの内容を正直に表すカテゴリです。 **131063 とは何ですか？** アカウントで marketing のテンプレートが無効になっている状態です。支払い方法がない場合とは異なります。 --- ## Meta Business Portfolioとその中身 https://easycoexistence.com/ja/docs/meta-business-portfolio Business Portfolioは、Meta Business Managerにおける企業単位のコンテナです。WhatsApp Business アカウントを保持し、その中に電話番号が入ります。顧客が番号を接続しても、プロバイダーのポートフォリオへ移らず、顧客自身のポートフォリオに残ります。 ### 階層はどのように構成されていますか？ 3 つの階層があり、すべてをアカウントと呼ぶことが、多くの混乱の始まりです。 Business Portfolioは最上位にあり、Meta Business Managerで企業を表します。広告アカウント、ページ、WhatsApp Business アカウントなどのアセットを保持します。WhatsApp Business アカウントの中には電話番号があり、それぞれに固有の phone number id、品質評価、メッセージング階層があります。 そのため、「アカウントが動作しているか確認してください」という文は、誰が言うかによって 4 種類の確認を意味します。問題が起きたとき、どの階層を指しているかを明確にすれば、診断にかかる時間の大半を短縮できます。 ### どのポートフォリオが番号を保持するかは、なぜ重要ですか？ 接続を実際に管理する人が決まるからです。 Tech Provider自身のアプリを通じてオンボーディングすると、番号は顧客のポートフォリオ内で接続され、プロバイダーのアプリには操作権限が付与されます。Metaとの関係は顧客に属し、会話料金は顧客の支払い方法に請求され、顧客自身がアクセスを取り消せます。 他社のプロバイダーアカウント上にツールを構築すると、番号の紐付け先が変わります。汎用自動化プラットフォームで発生する制限は、その共有された関係に起因します。これは、代理店にとって、すべての本格的な顧客がいずれ尋ねる質問への答えです。 - ポートフォリオとWABAを同じものとして扱うこと。一方が他方を保持しており、発生する問題も異なります。 - 顧客の番号を自社のポートフォリオで接続すること。接続が顧客のものではなく、自社のものになります。 - ビジネス認証が番号に紐付くと思い込むこと。ビジネス認証はポートフォリオ単位です。 **ポートフォリオは WhatsApp Business アカウントと同じですか？** いいえ。ポートフォリオは企業のコンテナで、WABAはその中にあり、電話番号を保持します。 **1 つのポートフォリオに複数のWABAを保持できますか？** はい。顧客がブランドごとに別のアカウントを持つ場合、代理店ではよく見られます。 **ポートフォリオへのアクセスを付与できるのは誰ですか？** 通常は連携作業者ではなく、そのポートフォリオの管理者である企業オーナーです。 **接続すると番号は移動しますか？** いいえ。番号はご自身のポートフォリオに残り、プロバイダーのアプリには操作権限だけが付与されます。 --- ## WhatsApp Business Account とオーバーライドがそこに設定される理由 https://easycoexistence.com/ja/docs/whatsapp-business-account WhatsApp Business Account には電話番号とメッセージテンプレートが保存されます。Webhook のルーティングは電話番号ごとではなくこの単位で適用されるため、見た目以上に重要です。そのため、接続を削除するとルーティングも失われます。 ### WABA には実際に何が保存されますか？ 電話番号とメッセージテンプレートです。一見した印象以上に重要な組み合わせです。 メッセージテンプレートは電話番号ではなくアカウントに属するため、同じ WABA 上のすべての電話番号が同じテンプレートライブラリを共有します。注文更新用に 1 つ作成すれば、すべての番号から送信できます。Meta はアカウントあたりのメッセージテンプレート数に上限を設けているため、1 つのアカウントで多くのブランドを管理する代理店では、この制限に達することがあります。 各電話番号には、それぞれの phone number id、表示名、品質評価、メッセージングティアがあります。これらは電話番号ごとの情報なので、同じアカウント上でも一方の接続状態が低下し、もう一方が正常な場合があります。 ### Webhook オーバーライドはなぜこの単位に設定されますか？ 変更対象のサブスクリプションが、電話番号ではなくアプリとアカウントのサブスクリプションだからです。 宛先を設定すると、実際には override_callback_uri が当社アプリの WABA に対するサブスクリプションに適用されます。そのアカウント上のすべての電話番号が、メッセージパスのイベントをそこへ配信するようになります。電話番号ごとのルーティングはないため、1 つの顧客の下で複数の番号を管理する人は驚くことがあります。 計画しておくべき重要な結果があります。14 日間の非アクティブ期間ルールなどによって接続が削除されると、アプリがアカウントからアンインストールされ、オーバーライドも一緒にアンインストールされます。再接続すると送信と監視は戻りますが、オーバーライドを再設定するものがない限り、自社サーバーへの配信は戻りません。 - 電話番号ごとの Webhook ルーティングを想定する。オーバーライドはアカウントごとです。 - 再接続すれば宛先も復元されると思い込む。アプリと一緒にアンインストールされるため、再適用が必要です。 - メッセージテンプレートが共有されることを忘れる。アカウント上のすべての電話番号が同じライブラリを参照します。 **1 つの WABA 上の 2 つの電話番号を別々のエンドポイントにルーティングできますか？** いいえ。オーバーライドはアカウントに適用されるため、そのアカウントのすべての電話番号が同じ宛先に配信します。 **メッセージテンプレートはアカウント間で移行されますか？** いいえ。作成元のアカウントに属します。 **電話番号を削除するとオーバーライドはどうなりますか？** アプリがアカウントからアンインストールされると、オーバーライドも一緒に削除されます。再接続すると送信は戻りますが、宛先は戻りません。 **メッセージテンプレートに上限はありますか？** Meta はアカウントごとのメッセージテンプレート数に上限を設けており、超過すると専用のエラーが返されます。 --- ## WhatsApp 番号の 2 段階認証 https://easycoexistence.com/ja/docs/two-step-verification 2 段階認証は、WhatsApp Business の電話番号に設定する PIN です。一部の操作で必要になります。通常はオンボーディング時に一度設定した後、再び使うことがないため、企業内の誰も覚えていないことがよくあります。 ### PIN が実際に必要になるのはいつですか？ 番号の登録や再登録の際と、Meta が保護している一部のアカウント操作で必要です。 つまり、多くの企業はオンボーディング時に設定した後、二度と目にしません。だからこそ問題になります。設定した担当者が退職し、PIN はどこにも記録されず、18 か月後に、すでに何かが壊れているまさにその瞬間に必要になります。 関連するエラーは具体的なので、原因を特定できます。誤った PIN を入力すると 133005 が返されます。試行が多すぎると 133008 が返され、レスポンスに記載された期間、追加の試行がロックされます。試行が短時間に送信されると 133009 が返されます。これは誤答ではなく、レート制限です。 ### PIN を紛失した場合はどうしますか？ 番号の設定にある WhatsApp Manager でリセットします。リセットには、その番号を所有するアカウントへのアクセスが必要です。 これはプロバイダーではなく、企業の所有者が行う操作です。API で PIN を読み取ったりリセットしたりすることはできません。プロバイダーも PIN を保持していません。これは設計上の仕様です。プロバイダーが取得できる認証情報は、二要素目の認証にはならないためです。 実務上は、代理店ではなく企業自身が取得できる場所に PIN を記録してください。代理店のパスワードマネージャーだけに保存すると、別の担当者に引き継いだ後、まったく同じ問題が起きます。 - 誤った PIN の後ですぐに再試行する。133009 が返され、次に正しく試行できるまでの時間が延びます。 - 代理店側だけに PIN を保存する。企業自身が取得できるようにする必要があります。 - プロバイダーが復旧できると思い込む。誰も保持していないことが、この仕組みの目的です。 **PIN をリセットできますか？** いいえ。PIN は Meta 独自の設定で番号に設定されており、どのプロバイダーも読み取ったり変更したりできません。 **ロックアウトはどのくらい続きますか？** 133008 では、固定期間ではなく、Meta がエラーレスポンスに待機時間を示します。 **PIN は番号ごとですか、アカウントごとですか？** 電話番号ごとです。 **これはビジネス認証と同じですか？** いいえ。認証はポートフォリオレベルの法人を対象とします。こちらは番号に設定する PIN です。 --- ## account_review_update Webhook https://easycoexistence.com/ja/docs/webhook-account-review-update account_review_update は、Meta によるビジネスアカウントの審査結果を伝えます。decision フィールドには決定内容が入り、拒否は単なる情報ではなく、接続状態の低下として扱う価値があります。通常、その後に送信機能が制限されるためです。 ### 審査はいつ行われますか？ Meta がビジネスアカウントを調査したときに行われます。認証の申請、異議申し立て、またはメッセージ送信の挙動による自動フラグがきっかけになることがあります。 審査そのものは、プロバイダーが開始したり内部を確認したりできるものではありません。届くのは、decision を伴うイベントとしての結果です。承認は特に問題ありません。対応する価値があるのは拒否です。拒否は問題を終わらせるのではなく、制限に先行することが多いためです。 WhatsApp Business アプリには審査に関する表示がないため、ビジネスが審査中になり、拒否されても、何も起きたと分からないまま電話から顧客への返信を続けられます。 ### 拒否をニュースではなく接続状態の低下として扱うのはなぜですか？ 拒否は通常、最後のイベントではなく、複数のイベントの最初に発生するためです。 審査の拒否は、Meta がアカウントを確認し、問題があると判断したことを意味します。その後は制限が続くことが多く、送信が完全に停止し、enforcement イベントを伴う account_update として届きます。拒否の時点で接続状態を低下として記録すれば、監視担当者は顧客との相談に早く着手できます。 情報として記録するだけでは、送信が失敗し始めてから初めて対応することになります。その時点でビジネスはすでに顧客へ連絡できず、相談は警告への対応ではなく危機対応から始まります。 - 拒否を記録しても状態を変更しないこと。これは脚注ではなく、先行指標です。 - このイベントに理由が含まれると期待すること。伝わるのは決定であり、詳細は Business Manager にあります。 - ビジネスが気付くと思い込むこと。審査に関する表示は電話に出ません。 **プロバイダーは審査に失敗した理由を確認できますか？** いいえ。制限の通知と理由は、ビジネスアカウントの Business Manager にあります。 **拒否されると必ず制限されますか？** 必ずではありません。ただし、警告として扱うのが適切なほど頻繁に起こります。 **誰が異議を申し立てられますか？** ビジネスアカウントへの管理者アクセスを持つ人です。プロバイダーが代理で申し立てることはできません。 **これはテンプレート審査と同じですか？** いいえ。テンプレート審査の結果は別に届き、アカウントではなく 1 つのテンプレートに関係します。 --- ## business_capability_update Webhook https://easycoexistence.com/ja/docs/webhook-business-capability-update business_capability_update は、アカウントで可能な操作、特にメッセージ上限の変更を通知します。現在の上限、つまり 1 日あたり会話を開始できる一意の顧客数を含みます。上限は増減します。 ### メッセージ上限は実際に何を制限しますか？ ローリング 1 日間に会話を開始できる一意の顧客数です。送信できるメッセージ数でも、送信速度でもありません。 ここが混同されやすい点です。スループットは 1 秒あたりで測る速度で、超過すると 130429 が返ります。メッセージティアは新しい会話の 1 日あたりの件数で、超過時は別の状態です。番号がティアの範囲内でも速度制限を受けることがあり、逆も同様です。 開いているカスタマーサービスウィンドウ内の返信は、会話を開始しないためティアを消費しません。消費するのは、まだメッセージを送っていない相手に連絡することです。 ### なぜ下がることがあるのですか？ ティアは品質に従い、品質は受信者の反応に左右されるためです。 受信者によるブロックやメッセージの報告が多い番号は評価を失い、ティアも調整されます。そのため、下がったことは有用な早期シグナルになります。通常は何かが使えなくなる前に届くため、送る内容や相手を見直す時間が残っています。 上がる方向はより遅く、良好な反応を継続して得ることで実現します。どちらの変化も企業が確認できる場所では通知されません。そのため、障害への対応だけでなく、このイベントを記録する価値があります。 - ティアとスループットを混同すること。一方は 1 日あたりの会話数、もう一方は 1 秒あたりのメッセージ数です。 - 返信をティアに加算すること。開いているウィンドウ内のメッセージは会話を開始しません。 - 下がったことを無視すること。何かが壊れる前に届くことが、この通知の価値です。 **ティアを上げるにはどうすればよいですか？** 申請ではなく、時間をかけた品質に基づきます。必要としている相手に適切に送ることが仕組みです。 **テンプレートの送信は必ずティアを消費しますか？** 会話を開始するテンプレートは消費します。開いているウィンドウ内で送る場合は消費しません。 **messaging_limit_update は別のものですか？** Meta は関連する変更について両方の名前を送信します。役立つ内容は同じため、ハンドラーでは同じように処理します。 **これは Coexistence の番号にも適用されますか？** はい。Coexistence で固定されるのはスループットであり、メッセージティアではありません。 --- ## account_alerts Webhook https://easycoexistence.com/ja/docs/webhook-account-alerts account_alerts は、企業アカウントに関する情報を知らせる Meta の一般通知チャネルです。他のイベントと異なり、適用すべき状態を運ばないため、自動処理ではなく確認を促す通知です。 ### このチャネルには何が届きますか？ Meta がアカウントについて知らせる価値があると判断した内容が届きます。内容は意図的に限定されておらず、時間とともに拡張されています。 内容が固定された一覧ではないため、特定のアラート種別だけを判定するハンドラーでは、新しいアラートを見落とします。長期的に有効な方法は、アラートを記録してアカウントに関連付け、人に提示することです。種類ごとに自動レスポンスへ割り当てる方法ではありません。 これは、判断するのではなく気付くことが適切な唯一の運用イベントです。こちらのハンドラーはアラートの到着を記録し、そこから状態を推測しません。 ### 監視ではどのように扱えばよいですか？ 状態を持つイベントの横に、タイムライン上のフラグとして記録してください。 価値は一連の流れにあります。審査の却下、その後の制限の直前にアラートが届いた場合、3 つを個別に見るだけでは分からない経緯が見えてきます。1 つのタイムラインに記録することで、それが可視化され、クライアントとの会話が推測ではなく日付とイベントに基づくものになります。 アラートから何かを実行してはいけません。アラートは接続解除でも品質低下でも制限でもありません。これらのいずれかとして扱うと誤警報が発生し、本当のアラートまで無視されるようになります。 - 特定のアラート種別だけを判定すること。種類は増えるため、現在の一覧を前提にしたハンドラーは古くなります - アラートから自動処理を起動すること。状態を持たないため、推測にすぎません - 処理できないとして破棄すること。他のイベントとの流れに価値があります **なぜ接続状態が変わらないのですか？** 何が変わったのかを示す通知ではないためです。ここから状態を推測すると誤警報が発生します。 **詳細はどこで確認できますか？** 企業アカウントの Business Manager で確認できます。このイベントは、そこで確認するよう促す通知です。 **まれにしか届きませんか？** 日常的なイベントではありません。そのため、届いたときに表示する価値があります。 **何か問題があるという意味ですか？** 必ずしもそうではありません。Meta が何かを知らせたという意味であり、自動処理ではなく人による確認が適しています。 --- ## WhatsApp ビジネス番号の表示名 https://easycoexistence.com/ja/docs/display-names 表示名とは、顧客があなたの番号との会話の上部で見る名前です。変更には Meta の承認が必要で、判断は phone_number_name_update webhook で届きます。拒否の主な理由は、名前が企業と一致していないことです。 ### Meta は何を確認しますか？ 基本的には、名前がそのアカウントで認証された企業に対応しているかを確認します。 法人名、登録された商号、または顧客が Web サイトで認識できるブランド名と一致する名前は、承認されやすい傾向があります。一方、一般的すぎる説明、認証済み企業と関係のない名前、名前ではなくキーワードのように見えるものは、承認されにくい傾向があります。 承認済みの表示名がない番号は、実行できる操作が制限され、特定の送信では専用のエラーを返します。これは、無料トライアル中に番号を急いで接続し、表示名の設定を完了しなかった人が、ある種類の送信だけ失敗し、他は成功する理由を後から知るケースにつながります。 ### 判断はどのように届きますか？ phone_number_name_update webhook で、判断フィールドとともに届きます。 これは接続が購読する 6 つの運用フィールドの 1 つで、申請した名前の結果が確定したことを示す唯一のシグナルです。WhatsApp Business アプリには表示されないため、数週間前に名前の変更を申請した企業は、誰かがそのイベントを受信していない限り結果を知る方法がありません。 接続のタイムラインに記録しておけば、「名前の変更は通ったか」という問いへの答えが推測ではなく日付になります。そうでなければ、この種の確認はサポートへの問い合わせになりがちです。 - 名前ではなくキーワードを送信する。Meta は検索ボリュームではなく、認証済み企業との一致を確認します。 - 知らせがないから承認されたと思い込む。判断は Webhook で届き、それ以外には届きません。 - トライアル中に表示名の設定を省略し、表示名が必要な送信で 131037 が返される。 **承認にはどのくらいかかりますか？** Meta は固定の期間を公表しておらず、どのプロバイダーも承認を早めることはできません。 **後から変更できますか？** はい。変更するたびに再度審査を受けます。 **エラー 131037 とは何ですか？** 承認済みの表示名がない番号が、表示名を必要とする操作を試みたときに返されるエラーです。 **顧客には電話番号も表示されますか？** 承認されると表示名が表示されます。表示名を設定する目的はそこにあります。 --- ## テンプレートカテゴリ：ユーティリティ、マーケティング、認証 https://easycoexistence.com/ja/docs/template-categories すべてのテンプレートは作成時にカテゴリを指定します。ユーティリティは顧客の行動に関連する取引メッセージ、マーケティングはプロモーションで、アカウントに支払い方法が必要です。認証は、より厳しい形式ルールに従うワンタイムコードを扱います。 ### 各カテゴリには何が該当しますか？ ユーティリティは取引に関するメッセージで、顧客が行ったアクションに関連します。注文確認、配送状況の更新、予約リマインダー、予約変更などが該当します。顧客が自分の行動を理由にそのメッセージを受け取ると期待するかどうかが、判断の基準です。 マーケティングは、オファー、新製品、再利用を促すメッセージ、ニュースレターなど、プロモーションを目的とするものです。送信には WhatsApp Business Account の支払い方法が必要です。そのため、これまで顧客への返信しか行っていないアカウントで、初めてマーケティングを送信すると失敗しやすくなります。 認証はワンタイムパスコードと確認を扱います。コードの前後に置ける内容などに厳しい制約があるため、最も厳格な形式です。配信に対する期待が異なることから、独立したカテゴリとして存在します。 ### すべてをユーティリティとして申告してはいけないのはなぜですか？ Meta は再分類するため、正直に申告するほうが有利です。 ユーティリティテンプレート内のプロモーション内容は一貫して検出されます。審査で却下されるか、承認後に再分類されます。後者の場合、誰も変更していないのに、ユーティリティとして請求されていた送信がマーケティングとして請求され始めます。これは節約ではなく、請求書上の予想外の変更です。 分類を誤ったテンプレートを繰り返し送信すると、アカウント自体にも注目が集まります。メッセージの実際の内容を申告するほうが低コストです。テンプレートが申告どおりかを審査できるため、審査も速くなります。 - ユーティリティテンプレートにオファーを入れる。確実に検出され、承認後に再分類される可能性があります。 - アカウントに支払い方法がない状態でマーケティングを送信する。Meta は支払い方法を必須としており、プロバイダーが追加することはできません。 - パスコード以外の用途に認証を使う。形式上の制約が厳しく、承認されません。 **マーケティング送信の料金は誰が支払いますか？** Meta が、お客様自身の WhatsApp Business Account に設定された支払い方法へ請求します。当社を経由することはありません。 **テンプレートのカテゴリは変更できますか？** 申告内容と実際のコンテンツが一致しない場合、Meta は承認後に再分類できます。 **ユーティリティは無料ですか？** ユーティリティの会話には Meta の料金がかかります。無料のカスタマーサービスウィンドウ内の返信とは異なります。 **エラー 131063 とは何ですか？** アカウントでマーケティングテンプレートが無効になっている状態です。支払い方法がない状態とは異なります。 --- ## 番号が使えなくなった場合の原因の調べ方 https://easycoexistence.com/ja/docs/troubleshooting-a-connection 接続済みの番号が使えなくなったとき、原因がコードであることはほとんどありません。発生頻度の高い順に、期限切れのトークン、再接続で失われた Webhook オーバーライド、14 日間の非アクティブによる切断、品質低下、アカウント制限を確認してください。 ### 電話ではなぜ何も問題がないように見えるのですか？ WhatsApp Business アプリと API は、同じ番号上にある別々の画面だからです。ほとんどの障害は、その一方だけに影響します。 トークンの有効期限が切れても、アプリには影響しません。Webhook オーバーライドが削除されても、アプリには影響しません。品質が低下しても、アプリには影響しません。どの場合も、企業は顧客への対応を続け、通常どおり動作していると考えるため、報告する理由がありません。 これが、誰かがダッシュボードを確認する運用ではなく、監視が必要な理由です。障害は実際に起きていますが、静かに進行し、番号に最も近い人ほど気づきにくいのです。 ### どの順番で確認すればよいですか？ まずトークンを確認してください。最も多い原因で、最も安く修正できるためです。期限切れまたは無効化された認証情報は、すべてのリクエストで同じように失敗し、番号が削除された場合とまったく同じに見えます。同じアカウントに対して 2 つ目の認証情報を保持すると、両者を見分けられます。 次に Webhook オーバーライドを確認してください。再接続が起きると、送信先はアプリと一緒に削除されます。そのため、送信と監視は動作していても、サーバーへの配信だけが静かに停止します。 次に切断を確認してください。アカウントの account_update イベントに PARTNER_REMOVED と理由が含まれます。PRIMARY_INACTIVITY は、アプリが約 14 日間開かれなかったことを意味し、再接続で解決します。 その次が品質です。品質はプッシュ通知ではなくポーリングで確認します。最後が制限です。これはアカウントレベルの措置であり、どのプロバイダーも解除できません。 ### ほとんど原因にならないものは何ですか？ 昨日まで動作していて、何もデプロイしていないなら、コードです。 Cloud API は安定しており、リクエストの形式が知らないうちに変わることもありません。数か月動いていた連携が停止した場合、可能性が高いのは認証情報、ルーティングの変更、またはアカウントレベルのイベントです。いずれも、誰もリポジトリに触れずに起こります。 例外として挙げるべきなのは、テンプレートが編集された場合です。テンプレート内の変数の数を変更すると、すべての送信者に対する仕様が静かに変わります。WhatsApp Manager で別の人が行った内容の変更ですが、コードの障害のように見えます。 - 最初に番号を再接続すること。トークンの期限切れなら、不要な作業を企業の担当者に求めることになります。 - コードが壊れたと思い込むこと。安定した API とデプロイがない事実は、別の原因を示します。 - 症状を電話で確認すること。これらの障害のほとんどが起きても、アプリは動作を続けます。 **電話では番号が使えるのに、何も送信できません。どこから確認すればよいですか？** アクセストークンです。最も多い原因で、削除された番号に最も似た状態になります。 **再接続したのに、メッセージがサーバーに届きません。** Webhook オーバーライドがアプリと一緒に削除されています。再適用が必要ですが、EasyCoexistence が自動で行います。 **14 日間のルールが原因だったかどうかは、どうすれば分かりますか？** account_update イベントに、理由 PRIMARY_INACTIVITY とともに切断が届きます。 **テンプレートの編集で送信が壊れることはありますか？** はい。コードの障害に似て見える唯一の原因です。変数の数を変更すると、すべての送信者に対する仕様が変わります。 --- ## Meta が課金する WhatsApp メッセージ https://easycoexistence.com/ja/docs/free-and-paid-conversations Meta はやり取り単位ではなく、配信されたメッセージ単位で課金します。2026 年 10 月 1 日以降、ビジネス電話番号ごとに月 1,000 件のサービスメッセージが無料になります。対象は 24 時間のカスタマーサービスウィンドウ内で送る返信で、1,001 件目から課金されます。テンプレートは配信時に課金され、ユーティリティテンプレートも例外ではありません。これらの料金は、お客様ご自身の WhatsApp Business Account に登録した支払い方法に請求されます。 ### 無料になるのは何ですか？ ビジネス電話番号ごとに、月 1,000 件までのサービスメッセージです。サービスメッセージとはテンプレート以外のメッセージを指し、開いているカスタマーサービスウィンドウ内でのみ送信できます。ウィンドウとは、顧客から最後にメッセージが届いてからの 24 時間です。月内の 1,001 件目からは、1 件ごとに Meta が課金します。使いきれなかった無料枠は翌月に繰り越されません。 この点は、連携の設計において思った以上に重要です。問い合わせに届いたメッセージへの返信だけを行うサポートのワークフローは、この無料枠を超えるまでは無料で、超えた分から 1 件ごとに課金されます。一方、こちらから先に連絡するワークフローでは、配信したテンプレートのすべてが課金対象です。2026 年 10 月 1 日以降は、開いているウィンドウ内で送ったユーティリティテンプレートも含まれます。 つまり、連携にかかる費用を決めるのは、やり取りの数ではなく、配信したメッセージの件数とカテゴリです。送信量が同じでも、2 つのシステムで Meta の課金額が大きく異なることがあります。 ### Meta は誰に請求しますか？ 請求先は、お客様ご自身の WhatsApp Business Account に WhatsApp Manager で設定した支払い方法です。 これは企業と Meta との直接の関係です。料金が Tech Provider を経由することはなく、そのためプロバイダーが上乗せしたり、他のサービスにまとめたり、再販したりすることもできません。WhatsApp のメッセージ料金を割引すると案内する事業者は、別の契約形態を持つ再販業者か、Meta の課金とは別のものを説明しているかのどちらかです。 実務上の影響として、支払い方法が未登録のアカウントは、月間の無料枠を使いきるまでは返信できます。しかし、テンプレートや無料枠を超える返信を送った時点で送信に失敗します。この仕組みを理解していないと、原因がわかりにくい不具合になります。 - 返信は常に無料だと思い込むこと。2026 年 10 月 1 日以降、Meta は 1 番号あたり月 1,000 件を超えるサービスメッセージと、ウィンドウ内のユーティリティテンプレートにも課金します。 - プロバイダーの請求書に Meta の料金が含まれると考えること。Meta の料金は直接、別に請求されます。 - アカウントに支払い方法を登録しないままワークフローを構築すること。テンプレートは送信されず、月間の無料枠を使いきると返信も止まります。 **返信はすべて無料ですか？** 無料なのは、ビジネス電話番号ごとに毎月最初の 1,000 件のサービスメッセージだけです。それ以降は 1 件ごとに Meta が課金します。24 時間のウィンドウ外ではテンプレートが必要で、こちらは配信時に課金されます。 **カテゴリによって料金は変わりますか？** はい。Meta はマーケティング、ユーティリティ、認証、サービスの各メッセージで料金が異なり、受信者の国によっても料金が変わります。 **プロバイダーならもっと安い料金にできますか？** Meta の料金についてはできません。その料金がプロバイダーに届くことはないためです。 **支払い方法が失敗するとどうなりますか？** 課金が必要な送信は停止し、エラー 131042 が返されます。受信には影響しません。 --- ## MCP と Webhook、実際に必要なのはどちらか https://easycoexistence.com/ja/docs/mcp-or-webhook MCPはリクエストとレスポンスの仕組みです。ユーザーが依頼すると、アシスタントがツールを呼び出します。Webhookはその逆で、Metaがイベントを届け、システムが対応を決めます。自動で反応する仕組みは、MCPだけでは構築できません。 ### MCPでは顧客に自動返信できないのはなぜですか？ プロトコルに、起動される仕組みがないためです。 MCPサーバーは、クライアントが呼び出すツールを公開します。呼び出し元はアシスタントであり、アシスタント自身がユーザーに応答しています。受信方向の仕組みはないため、顧客が WhatsApp メッセージを送っても、それがアシスタントに届いて動作を開始させることはできません。これは当社の制限ではなく、あらゆる製品のあらゆるMCPサーバーに当てはまります。 そのため、購入検討者がいずれ尋ねる、AIが営業時間外に顧客へ返信できるかという問いには、MCPではなくWebhookが答えになります。Metaが、あなたの運用するシステムにメッセージを届け、そのシステムが対応を決めます。そこにはモデルの呼び出しも含められます。 ### それぞれの経路は、実際には何に向いていますか？ MCPは、人が行っている作業に向いています。どの番号の接続状態が悪いか確認する、この顧客に確認メッセージを送る、注文更新用のメッセージテンプレートを作る、この顧客の番号を自分のサーバーに向ける。どれも誰かの依頼から始まり、ダッシュボードよりアシスタントを使うほうが速く進められます。 Webhookは、誰もその場にいなくても実行する必要がある処理に向いています。営業時間外の初回返信、適切な担当者への振り分け、CRMへの記録、ワークフローの起動などです。 便利なのは、MCPでWebhookを設定できることです。get_connect_linkはクライアントが開くリンクを生成し、set_webhook_destinationは番号をシステムに接続します。そのため、エージェントは自分では対応できない経路のオンボーディングを実行できます。 ### どのツールがどの経路に対応していますか？ アシスタントはMCPを使います。Claude、ChatGPT、Cursor、Claude Codeが該当します。一方、自動化プラットフォームの多くはMCPを使わないため、この違いは予想されにくいものです。 MakeとZapierは、どちらも独自のMCPサーバーを実行し、アシスタントにアクションを公開します。ただし、どちらもMCPクライアントとしては動作しないため、当社のMCPサーバーを呼び出せません。両者にとっての連携は、WebhookとHTTPリクエストです。 n8nは例外です。MCP Client Toolでリモートサーバーに接続でき、OAuth2にも対応しています。そのため、n8nのワークフロー内にあるエージェントノードから、当社のツールを直接呼び出せます。それでもワークフローはWebhookから始まります。反応を起こせるのはWebhookだけだからです。 - 自動返信を期待してMCPを購入すること。MCPは依頼されたときに動きますが、3amに依頼するものはありません。 - MCPサーバーを持つプラットフォームなら、MCPサーバーを利用できると思い込むこと。MakeとZapierは公開しますが、利用する側ではありません。 - 同じ処理を行うために両方の経路を構築すること。両者は、同じシステムの異なる役割を担います。 **アシスタントに WhatsApp を監視させられますか？** いいえ。MCPサーバーにイベントをプッシュすることはできません。監視にはWebhookを使い、そのWebhookからモデルを呼び出します。 **両方が必要ですか？** 実際のシステムの多くは両方を使います。MCPは人が行う作業に、Webhookは人がいなくても起きる処理に使います。 **Zapierで御社のMCPサーバーを使えますか？** いいえ。ZapierはクライアントではなくMCPサーバーなので、当社のサーバーを呼び出せません。 **n8nでは使えますか？** はい。MCP Client ToolとOAuth2を使って接続できます。3つの自動化プラットフォームの中で対応できるのはn8nだけです。 --- ## 接続後、WhatsApp Business アプリで変わること https://easycoexistence.com/ja/docs/what-changes-in-the-app 電話で変わることはほとんどありません。これまでと同じチャット、履歴、連絡先、端末を使い、チームは従来どおり返信できます。変わるのは、同じ番号に API が接続され、双方が相手の送信内容を確認できること、そしてグループが API の対象外になることです。 ### そのまま変わらないものは何ですか？ アプリ、番号、会話、そして返信する担当者です。 WhatsApp Business アプリはこれまでと同じように開き、連絡先リストも変わらず、過去の会話もすべて残ります。新しい場所でサインインする必要も、何かをインストールする必要も、研修もありません。火曜日の午後に番号を接続した企業でも、水曜日の朝はこれまでの水曜日の朝とまったく同じです。 これが接続の目的です。以前に移行を提案された企業にとっては、あまりに都合のよい話に聞こえるため、具体的に説明する価値があります。 ### 実際に変わることは何ですか？ 3 つありますが、目に見えるのは 1 つだけです。 API から送信したメッセージはアプリの会話スレッドに表示されるため、電話を見ている担当者は一部ではなく全体を把握できます。これが目に見える変化であり、業務を妨げるものではなく改善です。 アプリで入力したメッセージはソフトウェアから見えるようになり、smb_message_echoes イベントとして届きます。電話を見ている人は気づきませんが、人が返信した後に自動化が重ねて返信するのを防ぐ仕組みです。 また、グループチャットは API の対象外です。チームはこれまでどおりアプリからグループを使えますが、どのプロバイダーでもソフトウェアから確認や送信はできません。 ### 企業は何を続ける必要がありますか？ アプリを開くことです。どのみち必要になる操作です。 メイン端末でおよそ 14 日間アクティビティがないと、Meta は Coexistence 接続を解除します。顧客に継続して返信している企業では問題になりません。季節によって利用が止まる番号や、閑散期の顧客向けに代理店が管理する番号では注意が必要です。 接続解除は復旧できるため、損失ではなく不便にとどまります。計画しておくべきなのは、その後の動作です。接続とともに Webhook の送信先も解除されるため、再接続すれば送信は復旧しますが、再適用しない限り自社サーバーへの配信は停止したままです。 - チームが何も気づかないと約束した後、接続ではなく移行すること。移行するとアプリが使えなくなります。 - グループチャットを前提に構築すること。どのプロバイダーでも API の対象外です。 - 利用の少ない番号も接続されたままだと思うこと。アプリを 14 日間開かなければ接続は解除されます。 **チームは何かを覚える必要がありますか？** いいえ。今までどおり WhatsApp Business アプリを使い続けられます。 **過去の会話は失われますか？** いいえ。アプリに残り、オンボーディング時に約 6 か月分の履歴を API と共有することもできます。 **グループは引き続き使えますか？** アプリからは、はい、これまでどおり使えます。API からは、どのプロバイダーでも使えません。 **2 週間誰もアプリを開かなかった場合はどうなりますか？** Meta が API 側の接続を解除します。再接続すれば復旧し、アプリ自体はその間も影響を受けません。 --- ## Coexistence リファレンス https://easycoexistence.com/ja/docs/coexistence Coexistence では、1 つの番号で WhatsApp Business アプリと Cloud API を同時に使えます。このページでは、仕組み、メッセージの流れ、できないこと、解除方法を確認できます。導入する理由についてはガイドで説明しています。 ### 概要 Meta の公式モードで、1 つの電話番号上で WhatsApp Business アプリと Cloud API を同時に実行できます。別の API ではありません。同じ Cloud API を、オンボーディング後もその番号でアプリが動作するように設定します。 ### チームが利用する理由 ほぼすべての接続は、次の 4 つの理由で説明できます。 - 車両、領収書、Web サイトにすでに掲載している番号を維持できます。 - 新しいツールへ移行せずに、API 送信、Webhook、テンプレートを追加できます。 - 会話をプロバイダーの共有インボックスの外に保てます。 - 代理店が多数の顧客番号を、それぞれ顧客自身のポートフォリオに保持できます。 ### 通信の仕組み 両方の画面で同じスレッドを確認できます。API から送信した内容はアプリに表示されます。チームがアプリで入力した内容は smb_message_echoes イベントとしてソフトウェアに届くため、人が返信した後に自動化が返信するのを防げます。 ### 料金の仕組み Meta はメッセージではなく会話に料金を設定し、ユーザー自身の WhatsApp Business Account の支払い方法に請求します。24 時間のカスタマーサービスウィンドウ内の返信は無料です。ウィンドウ外で会話を開始するにはテンプレートが必要で、料金が発生します。 ### リンク済みデバイス Coexistence はリンク済みデバイスではなく、それを使用しません。リンク済みデバイスは別の場所でサインインしたコンシューマークライアントで、非公式ツールが自動化に使い、WhatsApp の規約で禁止されている仕組みです。ここでは、この仕組みを一切使用しません。 ### 機能上の制限 Meta によって固定されており、すべてのプロバイダーで同じです。 - グループチャットは API では利用できません。 - テンプレートは電話アプリから送信できず、API 経由でのみ送信できます。 - 送信スループットは、品質やティアに応じて拡大せず固定されています。 - チャット履歴の共有は、オンボーディング中に一度だけ決定されます。 ### 利用条件 接続するには、番号が事前に次の条件をすべて満たしている必要があります。 - コンシューマーアプリではなく、すでに WhatsApp Business アプリで有効になっていること。 - アクセス権のある Business Portfolio に含まれていること。 - 別のプロバイダーのアプリにすでに接続されていないこと。 ### 運用上の注意 接続後に適用され、見落としやすい事項です。 - アプリを定期的に開かないと、Meta が API 側を切断します。 - 切断すると、アプリとともに Webhook のオーバーライドもアンインストールされます。 - 品質評価はプッシュ通知ではなくポーリングで取得するため、低下しても通知されません。 - 2 つ目の認証情報がない場合、失効したトークンは削除された番号と同じように見えます。 ### アカウント選択に関する注意 Embedded Signup では、Business Portfolio と WhatsApp Business Account を別々の手順で選択します。誤ったアカウントを選ぶと、意図しない場所に番号が関連付けられます。その後に移動するには、切断して最初からフローをやり直す必要があります。 ### 一度きりの決定 既存のチャット履歴を共有するかどうかは一度だけ尋ねられ、後から変更できません。また、同期はオンボーディングから 24 時間以内に開始する必要があり、一度しか実行できません。どちらも、期限を逃すと警告ではなく、分かりにくいエラーが表示されます。 ### 切断または元に戻す方法 番号は、ダッシュボードまたはコネクターからいつでも切断できます。WhatsApp Business アプリは、会話と履歴を保持したまま、以前とまったく同じように動作します。接続したことによって、番号自体が恒久的に変更されることはありません。 - Coexistence を別の API として扱うこと。実際には、オンボーディング方法が異なる Cloud API です。 - グループチャットを中心に設計すること。すべてのプロバイダーで対象外です。 - 再接続すれば Webhook の送信先が復元されると考えること。復元されません。 **これは Cloud API と同じですか？** はい。Coexistence は Cloud API にオンボーディングする方法で、番号上の WhatsApp Business アプリも引き続き動作します。 **元に戻せますか？** はい。切断しても、アプリと会話はそのまま残ります。 **チームにトレーニングは必要ですか？** いいえ。これまでどおり WhatsApp Business アプリを使い続けられます。 **アプリからテンプレートを送信できないのはなぜですか？** テンプレートはアプリの機能ではなく、プラットフォームの機能です。24 時間のウィンドウ外のメッセージは API 経由で送信します。 --- ## API に同期されるもの、されないもの https://easycoexistence.com/ja/docs/what-syncs-and-what-does-not 連絡先と 1 対 1 のメッセージ履歴は API に同期され、その後はメッセージが双方向に反映されます。グループは同期されず、WhatsApp Business アプリ固有のカタログ、注文、ステータス、ラベル、クイック返信、挨拶メッセージ、離席メッセージも同期されません。 ### 同期されるもの 2 つあります。どちらも、企業が何年も使ってきた電話番号でソフトウェアを始める際に重要なものです。 - 連絡先：WhatsApp の番号を持つすべての連絡先をプラットフォームに同期できます - 1 対 1 のメッセージ履歴：API 導入前の会話も API から確認できます - その後はメッセージが双方向に反映されます。API から送った内容はアプリに表示され、チームがアプリで入力した内容はシステムに届きます ### 同期されないもの 想定より多くあります。クライアントに何ができるかを約束する前に、この一覧を確認してください。いずれもプロバイダーの制限ではなく、プラットフォームの仕様です。 - グループチャット：同期されず、どのプロバイダーでも API から到達できません - ビジネスツール：カタログ、注文、ステータスです - メッセージツール：挨拶メッセージ、離席メッセージ、クイック返信、ラベルです - チャンネル、音声通話とビデオ通話、ビジネスプロフィールの詳細です ### アプリ固有のツールが同期されない理由 これらはプラットフォームではなくアプリの機能であり、API に相当する機能がないためです。クイック返信とラベルはデバイス上に保存されます。離席メッセージは、誰もアプリを見ていないときにアプリが送信するものです。これらは API の概念として存在しないため、同期先がありません。実際には、ラベルで業務を整理している企業はアプリで使い続けることになりますが、ソフトウェアからは確認できません。その整理方法が構築する機能に必要なら、読み取るのではなく自社側で再構築する必要があります。 ### 見逃す可能性がある時間枠 同期はオンボーディング後 24 時間以内に開始する必要があります。逃すと、もう一度機会を得るには電話番号を接続解除して再度オンボーディングする必要があります。これは送信を左右する顧客対応の 24 時間ウィンドウとは別のものです。両者は頻繁に混同されます。顧客対応の時間枠は顧客の最後のメッセージから数え、自由入力を送信できるかを決めます。こちらはオンボーディングから数え、履歴を同期できるかを決めます。そのため、履歴をいつ取得するかは統合作業の開始時ではなく、電話番号を接続した日に決める価値があります。通常、統合作業は別の週に始まるためです。 - クライアントに、ラベルやクイック返信がシステムに表示されると約束すること。これらはアプリに残ります - グループチャットを前提に構築すること。どのプロバイダーでも同期されません - 統合作業が終わるまで履歴同期を先延ばしにすること。時間枠はオンボーディングから 24 時間です **以前の会話は API に表示されますか？** オンボーディング中に承認すれば、1 対 1 の履歴は同期されます。グループの会話は同期されません。 **自分のラベルをソフトウェアから確認できますか？** いいえ。ラベルは API に相当する機能がないアプリ機能のため、デバイスに残ります。 **チームはクイック返信を失いますか？** いいえ。これまでどおりアプリで使えます。ただし、ソフトウェアから確認することはできません。 **24 時間の同期時間枠を逃すとどうなりますか？** 電話番号をいったん接続解除して再接続する必要があります。オンボーディングが再実行され、新しい時間枠が始まります。 --- ## Coexistence 後に使えなくなる WhatsApp 機能 https://easycoexistence.com/ja/docs/features-disabled-by-coexistence Coexistence を通じて電話番号を接続すると、4 つの機能が使えなくなります。1 対 1 チャットでは消えるメッセージ、1 回表示メッセージ、ライブ位置情報がすべて無効になり、ブロードキャストリストも完全に無効になります。既存のリストは削除されず、読み取り専用になります。 ### 4 つの機能 それぞれ非表示になるのではなく、プラットフォームレベルで無効になります。いずれも、API が会話を認識できることに関係する理由があります。 - 消えるメッセージ：すべての 1 対 1 チャットで無効になります。 - 1 回表示メッセージ：すべての 1 対 1 チャットで無効になります。 - ライブ位置情報メッセージ：すべての 1 対 1 チャットで無効になります。 - ブロードキャストリスト：無効になり、既存のリストは削除されず読み取り専用になります。 ### なぜこの 4 つだけなのか これらはすべて、API と両立しない約束をする機能だからです。 消えるメッセージは、内容が残らないことを約束します。1 回表示メッセージは、1 回だけ見られることを約束します。どちらも、他の場所にコピーが残らないことが前提です。しかし、接続済みの番号は定義上、メッセージを別のシステムにも届けます。 ライブ位置情報はメッセージではなく継続的なストリームであり、API 上の表現がありません。ブロードキャストリストは、アプリ側から一度に多くの人へ送信する方法です。プラットフォーム側でその役割を担うのがメッセージテンプレートで、API 経由で承認を受けて送信します。 つまり、これらは任意に決められた制限ではありません。プラットフォームが、守れなくなった約束をしないようにしているのです。 ### 顧客の番号を接続する前に確認すること 企業がこれらの機能を使っているか確認してください。後から判明すると、説明が難しくなります。 実際の企業で問題になりやすいのはブロードキャストリストです。ブロードキャストリストで 200 人の顧客に毎週メッセージを送る店舗は、その運用を失います。代わりに承認済みのマーケティングテンプレートが必要で、アカウントには支払い方法の登録と Meta の審査が必要です。 消えるメッセージは別のタイプのユーザーに影響します。通常は、一度有効にしたまま忘れているケースです。ライブ位置情報が問題になるのは、配送やフィールドサービス以外ではほとんどありません。 - ブロードキャストリストに依存している番号を、企業に説明せず接続すること。代わりにテンプレートが必要で、承認と請求が伴います。 - 既存のブロードキャストリストが削除されると思い込むこと。読み取り専用になります。 - 番号の接続中にこれらの機能が戻ると期待すること。戻りません。 **消えるメッセージを再び有効にできますか？** 番号の接続中はできません。接続を解除すると、アプリの通常の動作に戻ります。 **既存のブロードキャストリストは削除されますか？** いいえ。読み取り専用になるため内容は残りますが、そのリストから送信することはできません。 **グループチャットにも影響しますか？** 無効化が文書化されているのは 1 対 1 チャットです。Coexistence の番号では、グループは API の対象外です。 **ブロードキャストリストの代わりになるものは何ですか？** API 経由で送信する承認済みのマーケティングテンプレートです。自分の WhatsApp Business アカウントに支払い方法を登録する必要があります。 --- ## Coexistence で利用できる番号 https://easycoexistence.com/ja/docs/number-eligibility 番号は WhatsApp Business アプリで使用中で、バージョン 2.24.17 以降を利用し、管理できる Business Portfolio 内にあり、別のプロバイダーに接続されていない必要があります。地域は条件ではありません。それ以外の場合、オンボーディング中に拒否されます。 ### 番号自体に必要な条件 4 つの条件があり、すべて Meta 独自のオンボーディング中に確認されます。プロバイダーが確認するものではありません。 - 一般向け WhatsApp アプリではなく、WhatsApp Business アプリに登録済みで使用中であること。 - メイン端末でアプリのバージョン 2.24.17 以降を実行していること。 - 管理者アクセス権を持つ Meta Business Portfolio 内にあること。 - 別のプロバイダーのアプリに接続されていないこと。 ### Coexistence を利用できる地域 WhatsApp Business アプリが動作する地域であれば利用できます。Business アプリユーザー向けの Meta の最新オンボーディング文書には地域制限がないと記載されています。地域限定で始まった展開も 2026 年中に完了し、南アフリカとナイジェリアが最後に追加された市場の一部です。 展開中に公開された地域別リストが今も出回っており、数か月前から対応している国を対象外として記載したものもあります。そのため、リストを読んだ企業が、実際には使える機能を使えないと判断することがあります。 Meta は日付付きの国別リストを公開していないため、信頼できる確認方法はフロー自体です。番号が WhatsApp Business アプリで有効になっていて、Embedded Signup が地域を理由に拒否しなければ、その番号では Coexistence を利用できます。 ### オンボーディングで起きる問題 大半の問題は 3 つの失敗に分類でき、それぞれ挙動が異なります。 一般向け WhatsApp アプリの番号には、Coexistence が表示されません。先に WhatsApp Business アプリへ移行する必要があり、企業が電話上で行う移行です。 古いバージョンのアプリではフローが開始してもスキャンを完了できません。更新して再試行してください。 途中で閉じたフローでは、番号がアカウントに接続されたまま登録されないことがあります。ダッシュボードでは接続済みに見えても、最初の送信でエラー 133010 が発生します。フローを最初からもう一度実行すれば完了します。 - 一般向け WhatsApp アプリのままの番号でオンボーディングを開始すること。先に Business アプリへ移行する必要があります。 - 展開時の地域対応リストを信頼すること。古いリストが多く、対応済みの国を対象外として記載しています。 - 番号が表示された時点で Meta のポップアップを閉じること。その後の手順で登録が完了します。 **固定電話番号や仮想番号は使えますか？** WhatsApp Business アプリに登録された番号である必要があります。登録メッセージを受信できなければなりません。 **必要なアプリのバージョンは？** 番号を保持する端末で 2.24.17 以降が必要です。 **自分の国で Coexistence は利用できますか？** ほぼ確実に利用できます。Meta の最新オンボーディング文書に地域制限はなく、地域展開も 2026 年中に完了しています。信頼できる確認方法はフロー自体です。 **番号はダッシュボードに表示されますが、送信できません。** オンボーディングが完了していない可能性があります。エラー 133010 が返されますが、フローを再実行すれば解決します。 --- ## EasyCoexistence と 360dialog の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-360dialog 360dialog と EasyCoexistence は、接続済みの番号ごとの定額料金と、Meta のメッセージ料金を利用者が直接支払う料金モデルを採用しています。どちらも上乗せはありません。違いは金額、段階の数、そして料金で得られるものです。 ### 番号ごとの料金 どちらも番号単位で課金し、Meta のメッセージ料金に上乗せしません。違いは金額と、その料金で得られるものです。 - 360dialog:: 2026年9月時点で、WhatsApp API は番号あたり月額 €49、€99、€500 の 3 段階です。登録時にプランを選び、その後は利用数のしきい値を超える必要があります。 - EasyCoexistence:: 公開されている料金表は 1 つだけで、接続済みの番号 1 件あたり月額 US$ 9 から、番号を追加するにつれて US$ 1 まで下がります。機能による制限はありません。代理店の 20 番目の番号も 1 番目と同じことができ、料金は安くなります。アップグレード先もないため、アップグレードの相談も不要です。 ### 顧客を追加するとどうなるか 番号ごとの料金が、単なる端数では済まなくなるケースです。 - 360dialog:: 先方の最低料金では、20 個の番号で Meta の料金を含める前から月額 €980 です。モデルは合理的ですが、掛け算の結果は変わりません。 - EasyCoexistence:: 20 個の番号なら月額 US$ 140 です。各番号は顧客ごとの Business Portfolio に個別接続され、請求も明細ごとに分かれます。何個追加しても段階料金には達しません。 ### 会話の内容はどこへ送られるか 後から変更できないため、最初に確認しておくべき点です。 - 360dialog:: 先方の料金ページには、メッセージの経路が記載されていません。どちらとも判断できないため、先方に最初に確認すべき事項です。 - EasyCoexistence:: Meta は、アプリからアカウントへのサブスクリプションに設定した上書きを通じて、指定した URL にメッセージイベントを配信します。宛先を設定していないアカウントのイベントは当社のコールバックに送られ、ハンドラーが保存せずに破棄します。 ### Coexistence そのもの 接続後も、その番号で WhatsApp Business アプリを使い続けられるかという点です。 - 360dialog:: 先方の料金ページには記載がありません。比較ページも含め、記載がない機能を未対応と決めつけず、先方に直接確認してください。 - EasyCoexistence:: これが製品の中心です。番号は Meta 独自の Coexistence フローで接続され、アプリはこれまでどおり動作し、どちらの画面でも相手側が送った内容を確認できます。 ### 完全な BSP 関係が必要な場合 該当するケースは 1 つあります。実際に意味のある選択肢です。 - 360dialog:: 接続ではなく、ベンダーとの関係を購入したい場合です。先方は長い運用実績、地域拠点、サポート体制を持つ実績ある BSP であり、小規模な製品では同じ体制を提供できません。大量送信者に必要な機能があるため、最高料金の段階が用意されています。 - EasyCoexistence:: 機能を絞った製品です。メールサポートと、何がいつ起きたかを示す接続タイムラインを提供します。独自の画面を構築する人に必要なのはこれであり、アカウント管理の関係ではありません。 ### どちらを選ぶか 担当アカウントマネージャーと、人が対応するエスカレーション経路が必要なら、それは BSP との関係であり、先方が該当します。 顧客の番号を預かり、その周りにソフトウェアを構築するなら、判断は料金で決まります。同じ料金モデルで価格は 5 分の 1、接続状態を監視し、メッセージを自社システムへ送れるため、代理店には EasyCoexistence のほうが規模に合わせて拡大できます。 - 月額料金だけを比較すること。料金で得られるものの違いは、金額以上に大きいです。 - どちらかが Meta の手数料を上乗せしていると思い込むこと。どちらも上乗せせず、Meta が利用者に直接請求します。 - 記載のない機能を未対応と読むこと。比較ページも含め、先方に確認してください。 **料金は最新ですか？** 2026年9月に 360dialog の料金ページで公開され、上にリンクした内容です。料金は変わるため、決定前に元の情報を確認してください。 **Meta の料金に上乗せされますか？** いいえ。どちらもそのまま請求し、Meta が利用者自身の WhatsApp Business Account に直接請求します。 **360dialog は Coexistence に対応していますか？** 先方の料金ページには記載がありません。どちらとも判断できないため、先方に確認してください。 **代理店にはどちらが適していますか？** 代理店には、顧客ごとにプラットフォームを持つ構成ではなく、顧客ごとに接続を持つ EasyCoexistence が適しています。番号数が増えるほど、番号単位の料金差が大きくなります。 --- ## EasyCoexistence と WATI https://easycoexistence.com/ja/compare/easycoexistence-vs-wati これは1つの製品の競合版ではなく、異なる製品です。WATIはチーム共有の受信箱を提供し、ユーザー数と月間アクティブ顧客数で課金します。EasyCoexistenceは接続そのものを提供し、番号単位で課金します。受信箱はありません。 ### 月額請求の実際の対象 2つの製品は異なる単位で料金が決まり、複数の番号を持つ場合、その差は毎月積み重なります。 - WATI:: ユーザー単位と月間アクティブ顧客単位です。2026 年 9 月時点で、公開プランはユーザー 3 人から 10 人、顧客 500 件から 2,500 件までです。雇う担当者や対応する顧客が増えるたびに請求額も増えます。 - EasyCoexistence:: 接続済みの番号 1 件あたりの定額です。ユーザー数と顧客数に制限はありません。代理店の 20 件目の顧客が 1 件目より高くなることはなく、忙しい月も静かな月も同じです。 ### 顧客との会話が行き着く場所 後から元に戻せない違いであり、それぞれの製品の性質から生じます。 - WATI:: 相手のプラットフォーム上です。共有受信箱は、開いた人にメッセージを表示するため内容を保存する必要があり、料金ページでも全プランの主要機能として示されています。 - EasyCoexistence:: こちら側には保存されません。Metaはメッセージイベントを指定した URL に直接届け、フォールバックコールバックに到達したものは保存せず破棄します。これはポリシー上の説明ではなく、コードで強制されています。 ### チームの働き方を変える必要があるか 何かに同意する前に、経営者が確認する質問です。 - WATI:: 担当者は相手の受信箱にログインします。会話の割り当て、タグ付け、返信をそこで行うため、チームは電話から新しいツールへ移ることになります。 - EasyCoexistence:: 誰も移りません。WhatsApp Business アプリは Coexistence を通じて同じ番号で使い続けられ、チャットも履歴もそのままです。ソフトウェアが構築した処理を担います。 ### 成長して上限を超えたとき どちらにも上限はあります。ただし、場所が異なります。 - WATI:: ユーザー数とアクティブ顧客数を増やすたびに、有料の上位段階へ移行します。プラットフォーム自体が製品なので、規模の拡大には追加購入が必要です。 - EasyCoexistence:: 段階制限も、超えるべき上限もありません。構築するのはインターフェースなので、拡張するのは自社システムです。間に当社のものを挟まず、Metaの文書化された API を使えます。 ### 受信箱が必要な場合 該当するケースは1つです。これを明確にすることで、このページの残りも役立ちます。 - WATI:: 8 人のサポートチームが相手のプラットフォーム内で会話を分担する場合です。ユーザー 3 人、月間アクティブ顧客 500 件で月額 4,999 ルピーから始まり、追加ユーザーには別途料金がかかるプランです。 - EasyCoexistence:: 別の仕事です。ここには受信箱も担当者画面もありません。インターフェースは、あなたや顧客がすでに持っている部分だからです。 ### どちらを選ぶか 担当者チームが毎日ログインし、会話そのものが仕事になるなら、受信箱を購入してください。WATIは受信箱を構築しており、説明どおりに機能します。 それ以外の人、つまりこのページを読む人の大半にとって、受信箱は料金を払うだけで使わない部分です。顧客の番号を管理する代理店は、誰も開かない席を購入することになります。インターフェースを構築する開発者は、自社製品とMetaの API の間に競合製品を置くことになります。小規模企業は、すでに機能している電話から移るよう求められます。 EasyCoexistenceはその下にある接続で、番号単位の定額です。会話は自社システムに届き、チームは使い慣れたアプリを使い続けられます。 - 月額料金を直接比較すること。一方には受信箱とユーザーが含まれ、もう一方には含まれません。 - チームに受信箱が必要なのに接続を選ぶこと。不満が出るのは当然です。 - 自分でインターフェースを構築しているのに受信箱を選ぶこと。2つ持つことになります。 **顧客数が 500 件を超えるとどうなりますか？** 相手の最安プランでは上位段階へ移行します。当社では何も起きません。料金に関係なく顧客数の制限がないため、顧客 10,000 件の月も 10 件の月と同じです。 **どちらが安いですか？** 相手の最安プランと比べると、6 番号までは当社です。そのプランは月額 4,999 ルピー、約 US$ 53 で、ユーザー 3 人と月間アクティブ顧客 500 件までです。当社は接続済みの番号 1 件あたり US$ 9、6 番号以上なら 1 件あたり US$ 7 なので、6 番号で月額 US$ 42 です。それを超えると、答えは相手の追加ユーザー料金と顧客数の段階料金によります。こちらはチームと顧客の増加に合わせて上がり、当社の料金は番号の数だけで決まります。 **WATIは Coexistence に対応していますか？** 相手の料金ページでは説明されていません。このページだけを頼りにせず、相手に確認してください。 **モバイルアプリはありますか？** ありません。チームはWhatsApp Business アプリを使います。それが Coexistence の目的です。 --- ## EasyCoexistence と respond.io の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-respond-io respond.ioは、チーム受信トレイ、ワークフロー、AIエージェント、ブロードキャストを備えたマルチチャネルプラットフォームです。ユーザー数と顧客数の上限があり、月額 US$ 79 から利用できます。EasyCoexistenceはその下の接続層で、番号単位の料金です。これらの機能は含みません。 ### 運用にかかる料金 2026年9月に公開されている、異なる単位での料金です。 - respond.io:: 月額 US$ 79 からで、ユーザー 5 人と月間アクティブ顧客 1,000 人が含まれ、最大 US$ 279 です。料金は応対する人数と、リーチする顧客数に応じて変わります。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 から、番号を追加するにつれて US$ 1 まで下がります。ユーザー数や顧客数の上限はありません。料金は保有する番号数に応じるため、企業や代理店が実際に管理する対象に対応します。 ### 会話コンテンツの保存場所 接続ではなく受信トレイを提供することから生じる違いです。 - respond.io:: 履歴を表示するためにチーム受信トレイが必要となる、同社のプラットフォーム上です。料金ページには保存期間の詳細がないため、重要であれば確認してください。 - EasyCoexistence:: 当社側には保存されません。Webhook の override_callback_uri により、メッセージイベントは Meta から直接お客様のエンドポイントへ送られます。フォールバックに届いたデータも保存されず破棄されます。 ### お客様と Meta の間にあるもの ソフトウェアを構築する人にとって、判断を分ける問いです。 - respond.io:: 同社のプラットフォームです。同社の抽象化、レート制限、Webhook の形式、リリーススケジュールに合わせて統合します。構築したものを移行できる範囲も、同社が許可する範囲に限られます。 - EasyCoexistence:: 何もありません。API は Meta 独自のもので、Meta が文書化しています。Webhook はお客様のエンドポイントに届きます。当社独自の仕様に依存せずに構築できるため、離脱も可能です。 ### 接続状態を監視するもの 料金ページではほとんど触れられませんが、この製品が存在する理由です。 - respond.io:: 同社の料金ページには記載がなく、断定すべきではありません。顧客の番号を保有するなら、接続がひそかに切れたときの動作を具体的に確認してください。 - EasyCoexistence:: 品質評価、メッセージング階層、スループットを定期的に取得します。Meta のアカウントイベントはイベント名で処理します。2つの認証情報を保持するため、失効したトークンを番号の消失と誤認しません。再接続で消えた Webhook の上書き設定も再適用します。 ### プラットフォームが必要な場合 2つの製品が異なる問いに答えることを、明確にしておく価値があります。 - respond.io:: プラットフォームが必要な場合です。公開プランには、チーム受信トレイとカスタム受信トレイ、ワークフロー、ブロードキャスト、AIエージェント、レポートが含まれます。上位プランでは SSO と複数ワークスペースも利用できます。WhatsApp 専用ではなく、マルチチャネルです。 - EasyCoexistence:: 意図的に異なる範囲です。1つの番号、1つの接続、16 個の MCP ツール、1つの Webhook を提供し、インターフェースはお客様に委ねます。 ### どちらを選ぶべきか これらは、1つの製品の競合版ではなく異なる層です。お客様側でインターフェースを構築する人がおらず、エージェントが作業する完成済みの場所が必要なら、探すべきものはプラットフォームです。 構築するのがお客様なら、プラットフォームは自社スタック内で競合になります。ユーザーが見ない受信トレイに席数分を、製品がすでに処理する会話に顧客数分を支払い、Meta が文書化し安定して維持する API ではなく、抽象化された仕様に対して統合することになります。 EasyCoexistenceはその下の層です。番号ごとの定額料金で、Webhook をお客様のシステムへ向け、接続を監視します。ひそかな障害が顧客の喪失につながることを防ぎます。 - US$ 9 と US$ 79 を、同じものの価格であるかのように比較すること。実際には異なります。 - 製品が必要なのに接続を選ぶこと。受信トレイを再構築するのに何か月もかかります。 - どのプロバイダーも接続を監視すると考えること。料金ページに載ることはまれなので、具体的に確認してください。 **どちらが自分に適していますか？** 異なる層です。respond.ioはその中で作業するプラットフォームで、EasyCoexistenceはその下の接続です。インターフェースを自社で構築するチーム向けです。 **respond.ioから移行できますか？** 番号はお客様のもので、Coexistenceを通じて接続できます。失うことになるのは、同社の受信トレイとワークフローです。 **ワークフローやAIエージェントはありますか？** ありません。MCP コネクタでアシスタントが番号を使い、Webhook でお客様のシステムが反応できます。どちらもワークフロー構築機能ではありません。 **これらの料金は最新ですか？** 2026年9月に公開され、上記にリンクした料金です。判断する前に出典を確認してください。 --- ## EasyCoexistence と Dualhook の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-dualhook どちらも同じ基本構成の Coexistence プロバイダーです。WhatsApp Business アプリは使い続けられ、メッセージの Webhook はプロバイダーを経由せず Meta から直接サーバーへ届きます。違いは共通点より細かいものの、確認する価値があります。 ### 両製品の概要 サイト上で最も近い比較です。位置付けがほぼ同じだからです。 - Dualhook:: 同じ基本方針の Coexistence プロバイダーです。WhatsApp Business アプリを使い続けながら、メッセージを保存せず Meta からサーバーへ直接 Webhook を送ります。ドキュメントではこれを Webhook Override と説明しています。 - EasyCoexistence:: Meta が使う名称と同じ仕組みです。WhatsApp Business Account へのアプリのサブスクリプションに override_callback_uri を設定し、メッセージ経路のフィールドをお客様のエンドポイントへ移します。その間も運用関連のフィールドは維持します。 ### メッセージの送信先 どちらも直接ルーティングします。違いは、ルーティングされないイベントの扱いです。 - Dualhook:: メッセージを保存せず Meta から直接ルーティングします。これは相手のサイトにも明記されており、当社と同じ構成です。 - EasyCoexistence:: ルーティングは同じです。当社ではフォールバック経路の動作を追加できます。override が設定されていないアカウントは既定のコールバックに届き、ハンドラーが保存せずイベントを破棄します。この主張はポリシーではなくコードで適用されます。 ### 14 日間の非アクティブ規則 主要デバイスでおよそ 14 日間アクティビティがないと、Meta は Coexistence 接続を切断します。両製品は異なる方法で対応します。 - Dualhook:: 相手のドキュメントでは、13 日目に警告し、カウントダウンとリマインダーメールを送ると説明しています。これは時間が進んでいることを知らせるもので、接続が実際に切断された理由を知ることとは別です。 - EasyCoexistence:: 当社は切断そのものを監視し、Meta の reason フィールドを読み取ります。PRIMARY_INACTIVITY、BUSINESS_DOWNGRADE、CHANGE_NUMBER などを区別できます。理由があれば、2 週間静かだったのか、顧客が実際に離脱したのかが分かります。 ### 再接続で壊れるもの 非アクティブ規則の中で最も大きな影響があり、どのプロバイダーにも確認すべき点です。 - Dualhook:: 相手のドキュメントでは、再接続後に Webhook オーバーライドがどうなるか説明していません。対応していない証拠ではありませんが、直接確認すべき質問です。 - EasyCoexistence:: 削除するとアプリがアカウントからアンインストールされ、override も失われます。再接続すると送信と監視は戻りますが、サーバーへの配信は気付かないまま止まります。当社は実際に再接続後に配信が止まった番号を確認したため、毎回再適用します。 ### 電話番号 1 件あたりの料金 どちらも座席数やメッセージ数ではなく、接続済み電話番号ごとの月額固定料金です。Meta が会話に請求する料金への上乗せもありません。 - Dualhook:: 相手の比較ページでは、2026 年 9 月時点で月額 US$ 12 からの固定料金と説明しています。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 から、番号を追加するほど下がり US$ 1 までです。ユーザー数や連絡先数の制限はありません。代理店では、顧客の番号を追加するたびに差額が積み重なります。 ### MCP コネクタ 特定の利用者にとって、当社が優位になる点です。 - Dualhook:: 相手のドキュメントには MCP サーバーの説明がありません。製品には API とダッシュボードからアクセスします。 - EasyCoexistence:: OAuth 対応のリモート MCP サーバー上で 16 個のツールを提供します。Claude、ChatGPT、Cursor、Claude Code から番号の一覧表示、接続状態の確認、メッセージやテンプレートの送信、Webhook の送信先設定ができます。アシスタントから顧客をオンボーディングする代理店には、この違いが重要です。 - 記載のない機能を、存在しない機能だと判断することです。相手に確認してください。このページは、相手のドキュメントに記載がない範囲を推測せず示しています。 - 料金だけで選ぶことです。Meta が会話に請求する料金と比べれば、どちらも小さな固定費です。 - 再接続後にどのプロバイダーも Webhook オーバーライドを再適用すると考えることです。選ぶ相手に具体的に確認してください。 **本当に同じ構成ですか？** メッセージ経路については同じです。どちらも Meta の機能で WhatsApp Business Account の Webhook 配信先を変更し、会話内容をプロバイダー経由ではなくサーバーへ送ります。 **14 日間の規則への対応はどう違いますか？** 相手は 13 日目に時間が進んでいることを警告します。当社は Meta 自身の切断理由を読み取り、2 週間静かだったのか顧客が実際に離脱したのかを区別します。さらに、再接続で失われた Webhook オーバーライドを再適用し、配信が気付かないまま止まるのを防ぎます。 **EasyCoexistence の違いは何ですか？** 相手のドキュメントに記載のない 16 個のツールを備えた MCP コネクタと、再接続で失われた Webhook オーバーライドの自動再適用です。 **このページは公平ですか？** ここにある数字はすべて相手が公開したページから引用し、日付を付けています。判断する前に確認してください。一方が書いた比較は証拠であって、判決ではありません。 --- ## WhatsApp Business アプリと API を同じ番号で使えますか？ https://easycoexistence.com/ja/whatsapp-business-app-and-api-same-number はい。Meta はこれを Coexistence と呼んでおり、回避策ではなく公式機能です。スタッフはスマートフォンの WhatsApp Business アプリで対応を続け、Cloud API も同じ番号で同時に動作します。どちらからも同じ会話を確認できます。 ### 1つの番号を同時に両方で使えるのはなぜですか？ Meta がそのためのモードを用意したからです。以前は、番号を API に移行すると WhatsApp Business アプリが使えなくなりました。そのため、スマートフォンで対応するスタッフがいる企業は、顧客を知る担当者と新たに追加したい自動化のどちらかを選ぶ必要がありました。 Coexistence により、この選択は不要になります。番号は Meta に API 番号として登録される一方、WhatsApp Business アプリとのリンクは維持されます。顧客からのメッセージはスマートフォンのアプリと API の Webhook の両方に届き、どちらから送った返信も会話に表示されます。何かを偽装したり回避したりするのではなく、アプリと API が同じ番号への正式な 2 つの入口になります。 ### スマートフォンでは実際に何が変わりますか？ 予想より変化は少ないものの、接続前に知っておくべき違いがあります。 スタッフはこれまでどおり、同じアプリ、同じチャット、同じ連絡先、同じ番号を使えます。使えなくなるのは、Coexistence の番号で Meta が無効にする 4 つの機能です。消えるメッセージ、1 回表示メディア、ライブ位置情報、ブロードキャストリストが対象です。グループチャットはアプリで引き続き利用できますが、API の対象外なので自動化からは確認できません。 また、番号を初めて接続するときに同期の手順があり、最近の会話履歴がコピーされます。そのため API 側が何もない状態から始まることはありません。対象は最近のメッセージで、番号の全履歴ではありません。それより古い内容は、これまでどおりスマートフォンに残ります。 ### 考えが変わった場合、何か壊れますか？ いいえ。これは、試すことをためらう理由になりやすい不安なので、はっきりお伝えします。 会話はスマートフォンに保存され、ずっとそこにあります。番号と API の接続を解除しても、WhatsApp Business アプリはチャットを保持したまま、以前とまったく同じように動作します。そもそも何かを移動したわけではないからです。API はアプリを置き換えるのではなく、アプリと並行して追加されます。 番号は全期間を通じて企業自身の Meta Business Portfolio に残ります。プロバイダーは Tech Provider として接続しますが、これは所有権ではなく権限です。そのためプロバイダーを削除しても、番号がプロバイダーと一緒に移ることはありません。 ### 動作させるには何が必要ですか？ 必要なのは 3 つで、そのうち 2 つはすでにお持ちのはずです。 番号は一般向け WhatsApp アプリではなく WhatsApp Business アプリに登録されている必要があります。また、別の場所ですでに Cloud API に登録されていてはいけません。さらに、オンボーディングを実行する Meta Tech Provider が必要です。Coexistence は Meta のダッシュボードから自分で設定できず、承認済みプロバイダーのアプリを通じて接続するためです。 そこで EasyCoexistence の出番です。Meta 公式の Embedded Signup でポートフォリオ、アカウント、番号を選び、WhatsApp Business アプリでコードをスキャンして確認します。数分で番号を接続でき、接続中もアプリはそのまま利用できます。 - 番号を選ぶ必要があると思い込む。Coexistence は、まさに選ばなくて済むように存在します。 - API でグループチャットを扱えると期待する。グループチャットはアプリに残り、どこでも API の対象外です。 - Meta のダッシュボードに設定項目が出るまで待つ。Coexistence のオンボーディングは Tech Provider を通じて実行します。 **公式機能ですか？** はい。Coexistence は Meta 独自の機能であり、Meta が使う正式名称です。ブリッジ、リンク済みデバイス、回避策ではありません。 **スタッフは違いに気づきますか？** なくなるのは 4 つの機能だけです。消えるメッセージ、1 回表示、ライブ位置情報、ブロードキャストリストです。それ以外は以前と同じです。 **チャット履歴は失われますか？** いいえ。履歴はスマートフォンに残ります。番号の接続時には最近の履歴も API 側にコピーされます。 **元に戻せますか？** はい。番号の接続を解除すると、会話を保持したままアプリは以前とまったく同じように動作します。 --- ## チャットを失わずに WhatsApp を API に接続する方法 https://easycoexistence.com/ja/connect-whatsapp-without-losing-chats チャットは電話に保存されており、API に接続しても移動しません。Coexistence では WhatsApp Business アプリを置き換えずに Cloud API を追加するため、会話はそのまま残り、アプリも使い続けられます。 ### 以前は API に接続すると、なぜチャットを失ったのですか？ 以前の方法は追加ではなく、移行だったためです。Cloud API に番号を登録すると WhatsApp Business アプリから番号が外れ、すべての会話はアプリ内に保存されていました。そのため番号は履歴もアプリもない API エンドポイントとして戻り、多くの企業が一度 API を検討しただけで導入を見送っていました。 このトレードオフは現実のものであり、中小企業が公式 API を使わない最大の理由でした。また、アプリをリンク済みデバイスのように装って使い続ける非公式ゲートウェイへ利用者を向かわせ、番号が利用停止になるリスクも生みました。 ### Coexistence は何が違うのですか？ アプリを削除せずに API を追加します。番号は Meta に API 番号として登録されますが、WhatsApp Business アプリとのリンクは維持されるため、同じ番号で両方を同時に使えます。 会話が移動することはありません。会話はこれまでどおり電話上のアプリに保存され、API 接続後に何が起きてもそこに残ります。番号を初めて接続すると、Meta は最近の会話履歴を API 側に同期します。これにより自動化を何もない状態から始めずに済みますが、これは転送ではなくコピーです。端末から何かが取り除かれることはありません。 その後に届いた顧客からのメッセージは、電話上のアプリと Webhook の両方に届きます。スタッフは必要に応じてアプリで返信でき、システムから返信することもでき、どちらも同じ会話に表示されます。 ### 何が同期され、何が同期されないのですか？ 接続後の一定期間内に、最近のメッセージ履歴が同期されます。これにより、自動化や担当者は、見たことのない相手に手探りで返信するのではなく、進行中の会話の背景を把握できます。 同期されないのは、それより古いすべての履歴、接続前のメディア、グループ会話です。これらが失われるわけではありません。以前と同じように電話上のアプリに保存され、スタッフが読めます。同期はアーカイブではなく、自動化を始めるための出発点だからです。 別の場所に完全な履歴が必要な場合は、アプリからエクスポートしてください。これは番号の接続とは別の作業なので、混同しないことが大切です。 ### 後で切断するとどうなりますか？ アプリはそのまま動作し、チャットも残ります。チャットが移動したことはないためです。 切断すると、番号の API 側が削除されます。WhatsApp Business アプリはすべての会話を保持したまま動作し続け、復元するものもなく、企業は接続前とまったく同じ状態に戻ります。これが開始前に理解しておくべき安全策です。以前の移行とは異なり、この判断は可逆的です。 番号はその間ずっと、自社の Meta Business Portfolio に残ります。プロバイダーは Tech Provider として接続しますが、これは付与した権限であり、取り消せます。そのためプロバイダーを離れても、番号をプロバイダーから取り戻す必要はありません。 - 不安から先にすべてをエクスポートする。チャットがなくなることはありません。 - API 側に完全な履歴が表示されると期待する。同期されるのは最近の背景情報であり、アーカイブではありません。 - アプリを使い続けるために非公式ゲートウェイを使う。Coexistence なら利用停止のリスクなしで実現できます。 **チャット履歴は失われますか？** いいえ。チャットは電話に保存され、そのまま残ります。接続するとアプリを置き換えずに API が追加されます。 **古い履歴はシステムに表示されますか？** 接続後に最近の履歴が同期されます。古いメッセージやメディアは電話に残ります。 **スタッフはアプリを使い続けられますか？** はい。これまでどおり使えます。それが Coexistence の目的です。 **切断するとどうなりますか？** 何も移動していないため、すべての会話を残したままアプリを使い続けられます。 --- ## WhatsApp Business APIを最安で導入する方法 https://easycoexistence.com/ja/cheapest-whatsapp-business-api API 自体は無料です。支払うのは、会話に対する Meta の料金と、接続に対するプロバイダー料金です。Meta の料金は利用先にかかわらず同じなので、最適化できるのはプロバイダー料金だけです。最も安い形は、上乗せ料金のない番号ごとの定額料金です。 ### 実際に何に支払っていますか？ 別々の 2 つに支払っており、これを混同することが、この分野の料金比較がうまくいかない理由です。 1 つ目は Meta の会話料金です。Meta はカテゴリーごとに会話料金を請求し、料金は国によって異なります。また、24 時間以内のサービス会話は、企業が開始する会話とは異なる扱いになります。この費用は Meta の料金なので、どのプロバイダー経由で購入しても発生し、通常はこちらのほうが大きな金額です。 2 つ目は、接続に対してプロバイダーが請求する料金です。これはプロバイダー側の完全な商業判断であり、選択によって実際に変更できる請求項目はここだけです。この 2 つを分けずに総額だけでプロバイダーを比較するのは、ノイズを比べているようなものです。 ### どこで料金が漏れていますか？ 上乗せ料金です。メッセージ 1 件あたりでは小さいため、見落としやすい項目です。 複数のプロバイダーは、Meta の料金に加えてメッセージ単位の料金を設定しています。Twilio は受信、送信それぞれについて、メッセージ 1 件あたり US$ 0.005 を公開しています。Gupshup は US$ 0.001 を公開しています。Meta の料金を含めた一括料金を提示するプロバイダーもありますが、その場合は上乗せ料金が実際に存在しても、Meta が公開する料金と照合できません。 1 セントの 10 分の 1 でも、掛け合わせれば無視できません。月 100,000 件のメッセージでは、Gupshup の公開料金は US$ 100、Twilio は US$ 500 になり、いずれも Meta の請求に加えて毎月発生します。機能だけで選ぶ前に、表計算シートに入れて比較する価値がある数字です。 ### 最も安い料金体系はどれですか？ 接続済み番号ごとの定額料金で、Meta の請求が利用者に直接届き、手を加えられていない形です。 この形には、ほかの選択肢にはない 2 つの特徴があります。番号を接続すれば料金は増えないため、利用量が増えても費用は変わりません。また、プロバイダーの料金が請求に組み込まれていないので、Meta の請求書を監査できます。Meta 自身が公開している料金と照合できるためです。 当社の料金は接続済みの番号 1 件あたり月額 US$ 9 から、番号を追加するにつれて US$ 1 まで下がり、メッセージごとの料金はありません。Twilio の公開料金では、月 1,800 件程度を超えると当社のほうが安くなり、利用量が増えるほど差は広がります。座席数で課金するプラットフォームは別の計算になります。メッセージではなく利用者数に対して請求するため、損益分岐点は人数によって変わります。 ### 最安の選択肢が適切ですか？ 必ずしもそうではありません。適さない場合についても、正直に考える価値があります。 チームが 1 日中使う共有受信トレイ、キャンペーン機能、分析機能を 1 つの製品に求めるなら、座席単位で課金するプラットフォームは実際の価値を提供しており、その料金には理由があります。当社に安く支払って、その機能を自分で構築するなら、節約にはなりません。 すでにシステムがある場合は、最安の選択肢が適しています。CRM、ヘルプデスク、自動化ツール、AI エージェントを使っている企業に必要なのは、メッセージを読む 2 つ目の場所ではなく、WhatsApp を最初のシステムにつなぐことです。その用途なら、公式 API を使いながら支払える最低限の料金は、番号単位でメッセージごとの料金がない形です。 - Meta の会話料金とプロバイダー料金を分けずに比較すること。 - 一括のメッセージ単位料金を、上乗せ料金がないと受け取ること。内訳が示されていないだけです。 - 実際にはプラットフォームが提供する受信トレイが必要なのに、最安の料金だけで選ぶこと。 **WhatsApp Business API は無料ですか？** 接続自体は無料です。Meta は会話料金を請求し、プロバイダーはその上に接続料金を請求します。Meta の料金はどこでも同じです。 **最も安いプロバイダーはどこですか？** 最も安い形は、上乗せ料金のない番号ごとの定額料金です。当社は番号 1 件あたり US$ 9 から始まり、番号を追加するにつれて US$ 1 まで下がります。 **安いプロバイダーだと API の品質が下がりますか？** いいえ。どの場合も Cloud API は Meta のものです。プロバイダーによって変わるのは、その前段に何を置くかと、請求する料金です。 **より高いプロバイダーを選ぶ価値があるのはいつですか？** チームが 1 日中使う共有受信トレイなど、相手が販売する製品自体を必要とする場合です。 --- ## メッセージテンプレートの構成要素：ヘッダー、本文、フッター、ボタン https://easycoexistence.com/ja/docs/template-components メッセージテンプレートは、ヘッダー、本文、フッター、ボタンの最大 4 つのコンポーネントで構成されます。変数を使えるのはヘッダーと本文だけです。また、各コンポーネントには、Meta の審査前にメッセージの内容を決める制限があります。 ### ヘッダー 任意で、テキスト、画像、動画、ドキュメントの 4 種類から選べます。テキストヘッダーは 60 文字までで、変数を 1 つだけ使えます。メディアヘッダーには送信時に指定するファイルを付けられるため、領収書やチケットを添付できます。 - テキストヘッダー：60 文字まで、変数は最大 1 つです - メディアヘッダー：画像、動画、ドキュメントを送信ごとに指定します - 1 つのメッセージテンプレートに設定できるヘッダーは 1 つだけです - 一部のカテゴリでは位置情報ヘッダーを利用できます ### 本文 必須のコンポーネントで、最大 1024 文字です。複数の変数を使えるのは本文だけです。変数は位置で決まり、番号付きのプレースホルダーとして記述します。そのため、最初の変数には送信する最初のパラメーターが入ります。 固定テキストが少なく、ほとんどが変数の本文は Meta に拒否されます。テンプレート単体でほとんど内容を伝えられないと、任意のコンテンツを入れる空欄と区別できないためです。プレースホルダーの前後には、意味のある文章を記述してください。 ### フッター 任意で、60 文字までの固定テキストです。変数は一切使えません。本文より小さく薄い色で表示されるため、常に表示する注記には適していますが、メッセージの内容に応じて変わる情報には適していません。 マーケティング用テンプレートで、配信停止の案内を表示するのが一般的です。これにより、受信者からの信頼を保ちやすくなります。 ### ボタン 合計 10 個まで設定でき、3 種類の組み合わせによって承認されやすさが大きく変わります。 - クイック返信：タップすると固定テキストの返信を送信します - アクション：URL を開くか、電話番号に発信します - URL ボタンでは変数を 1 つ使え、固定のベース URL の末尾に追加されます - コードをコピー：認証用のコードを受信者がコピーできます ### 審査前に構成が重要な理由 Meta はメッセージテンプレート全体を審査するため、拒否の多くは文言ではなく構成が原因です。 本文のほとんどが変数、企業と無関係な URL を指す URL ボタン、マーケティング用メッセージをユーティリティカテゴリで申請するケースは、いずれも構成上の理由で拒否されます。先に構成を正しく整えると、文言の審査も進めやすくなります。ポリシー違反で拒否された場合は、実際の原因を示すのではなく error 132007 が返されます。 - プレースホルダーが大半を占める本文を作成すること。固定テキストが少なすぎるテンプレートは Meta に拒否されます - フッターで変数を使えると考えること。例外なく固定テキストです - マーケティング用メッセージをユーティリティカテゴリで申請すること。文言を直しても、誤ったカテゴリは承認されません **どの部分で変数を使えますか？** ヘッダーでは最大 1 つ、本文では複数の変数を使えます。フッターでは使えず、URL ボタンでは末尾に追加する値を 1 つ使えます。 **本文は何文字まで入力できますか？** 1024 文字までです。4 つのコンポーネントの中で、本文が大幅に最も長く設定できます。 **ボタンはいくつまで設定できますか？** 合計 10 個までです。種類ごとにも制限があります。 **メッセージテンプレートが拒否された理由は何ですか？** 多くの場合、文言ではなく構成が原因です。固定テキストが少なすぎるか、カテゴリが間違っています。その場合は error 132007 が返されます。 --- ## メッセージテンプレートのステータスのライフサイクル https://easycoexistence.com/ja/docs/template-status-lifecycle メッセージテンプレートは複数の状態を順に進み、承認は終点ではなく途中にあります。承認済みでも品質によって一時停止され、自動的に再開し、再び停止された後、最終的に誰も操作しないまま恒久的に無効化されることがあります。 ### 状態 通常、メッセージテンプレートがたどる順序です。 - PENDING: 送信され、審査を待っている状態です。 - APPROVED: 送信に使用できる状態です。 - REJECTED: 審査で拒否された状態で、通常は構成またはカテゴリが理由です。 - PAUSED: 品質低下後、一時的に使用できない状態です。 - DISABLED: 恒久的に使用できず、最後の状態です。 ### メッセージテンプレートが一時停止される仕組み あなたが操作した結果ではありません。受信者がそのメッセージテンプレートで送られたメッセージをブロックまたは報告すると、テンプレート自体の品質評価が緑から黄色、赤へ低下します。Meta は低下を止めるために一時停止します。 一時停止は一時的で、自動的に解除されます。重要なのはその後です。繰り返し一時停止されると対応が強まり、赤に戻り続けるメッセージテンプレートは、再び一時停止されるのではなく、最終的に恒久的に無効化されます。 ### 2 つの Webhook サイクル全体を確認するには両方が必要です。一方だけを購読すると、見えない部分が残ります。 - message_template_status_update: 承認、拒否、一時停止、無効化を通知します。 - message_template_quality_update: 品質評価が緑、黄色、赤の間で変化したことを通知します。 - 品質 Webhook は早期警告で、ステータス Webhook はその結果を通知します。 - どちらも初期状態では有効でないため、両方を購読する必要があります。 ### 黄色の段階で対応する理由 メッセージテンプレートが一時停止された時点では、そのテンプレートでの送信はすでに失敗し、キャンペーンも止まっています。黄色は、まだ動作していて、低下が見えている段階です。 黄色で対応するには、文面だけでなく対象者も確認します。内容の整ったメッセージテンプレートでも、受信を予想していない人に送れば、内容の悪いテンプレートと同じ速さでブロックされます。リストを変えずに文面だけ書き直しても、何も変わりません。 ### 編集による影響 承認済みのメッセージテンプレートは編集でき、その後もう一度審査に進みます。これは便利ですが、本番環境で問題になる結果もあります。編集によって変数の数が変わると、変更していない連携からの送信はすべて error 132012 で失敗し始めます。 テンプレートの変数の数は、マーケティング担当者が管理する文面の一部ではなく、連携の契約の一部として扱ってください。 - 承認を永続的だと考える。承認済みのメッセージテンプレートも一時停止され、最終的に無効化されることがあります。 - ステータスだけを購読し、品質を購読しない。品質フィールドが早期警告になります。 - 送信コードを確認せずに、メッセージテンプレートの変数を編集する。 **承認済みのメッセージテンプレートは承認されたままですか？** 必ずしもそうではありません。否定的な反応が続くと一時停止され、最終的に恒久的に無効化されることがあります。 **一時停止と無効化の違いは何ですか？** 一時停止は自動的に解除されます。無効化は恒久的で、そのメッセージテンプレートは再び使用できません。 **事前に確認するにはどうすればよいですか？** メッセージテンプレートの品質 Webhook を購読してください。テンプレートがまだ動作している間に、黄色への移行が通知されます。 **編集後に送信が失敗し始めたのはなぜですか？** 編集で変数の数が変わると、変更していない連携が誤った数のパラメーターを送信するため、error 132012 が返されます。 --- ## 変数を含むテンプレートの送信 https://easycoexistence.com/ja/docs/sending-a-template-with-variables テンプレート変数は名前ではなく位置で指定します。コンポーネントごとにパラメータのリストを順番に送り、テンプレートの定義と件数を正確に一致させる必要があります。間違えると 3 種類のエラーが発生し、それぞれ異なる原因を示します。 ### パラメータの照合方法 名前ではなく位置で照合します。本文リストの最初のパラメータが最初のプレースホルダーに入り、2 番目が 2 番目に入り、その後も同様です。変数に名前を付ける方法はありません。2 つのパラメータを入れ替えると、値が間違った場所に入ったまま、メッセージは正常に送信されます。 このケースが危険なのは、何も失敗しないためです。顧客には、金額が入るべき場所に日付が入った注文確認が届きますが、どこにもエラーは記録されません。 ### コンポーネントは別々のリスト ヘッダー変数と本文変数は同じリストを共有しません。各コンポーネントが独自のパラメータを持つため、それらを結合すると件数不一致になります。 - ヘッダーのパラメータはヘッダーコンポーネントに入れます。最大 1 つです。 - 本文のパラメータは本文コンポーネントに順番どおり入れます。 - ボタン URL のパラメータはボタンごとにインデックス付けし、ボタンコンポーネントに入れます。 - すべてを 1 つのフラットなリストで送ると、エラー 132000 が返ります。 ### 言語を正しく指定する テンプレートは名前と言語の組み合わせで識別されるため、同じ名前でも言語が違えば別のテンプレートです。テンプレート作成時の言語が en_US なのに en を送ってもフォールバックせず、エラー 132001 でテンプレートが存在しないように扱われます。 番号のテンプレート一覧を取得し、形式を推測せず、正確な言語文字列をコピーしてください。これは最もよくあるテンプレートエラーで、最も説明が不十分なエラーでもあります。 ### 型付きパラメータ ほとんどのパラメータはプレーンテキストです。ただし例外があり、それらをテキストとして送るとエラー 132012 になります。 - 通貨パラメータには、金額、通貨コード、フォールバック文字列を指定します。 - 日付と時刻のパラメータには、フォールバックを含む構造化オブジェクトを指定します。 - メディアヘッダーのパラメータには、ファイル名ではなくメディア ID またはリンクを指定します。 - フォールバック文字列は、受信者のアプリで値を表示形式に変換できない場合に表示されます。 ### それぞれのエラーの意味 3 つの失敗は区別できます。テンプレートエラーとしてまとめず、個別にログへ記録すれば、原因を推測する手間を大きく減らせます。 エラー 132001 は名前と言語の組み合わせを解決できなかったことを示すため、まず言語を確認します。エラー 132000 は件数が間違っていることを示すため、テンプレート自身の定義と比較します。エラー 132012 は値の形式が間違っていることを示し、通常は型付きパラメータをプレーンな文字列として送っています。 - en が en_US にフォールバックすると考える。実際にはフォールバックせず、テンプレートがないというエラーになります。 - ヘッダーと本文のパラメータを 1 つのリストに結合する。これらは別々のコンポーネントです。 - 通貨や日付をプレーンテキストで送る。型付きパラメータには決められた形式があります。 **テンプレート変数に名前はありますか？** いいえ。位置で指定するため、パラメータの順番がすべての契約になります。 **テンプレートが存在しないのはなぜですか？** 通常は言語コードが原因です。テンプレートは名前と言語の組み合わせで識別され、フォールバックはありません。 **パラメータを多く送りすぎるとどうなりますか？** エラー 132000 になります。少なすぎる場合と同じように失敗します。 **金額はどのように送信しますか？** プレーンテキストではなく、金額、通貨コード、フォールバック文字列を含む通貨パラメータとして送信します。 --- ## レート制限とメッセージングのスループット https://easycoexistence.com/ja/docs/rate-limits-and-throughput 制限は 4 種類あり、これらを混同することがレート制限をわかりにくくしている原因です。メッセージング上限は Business Portfolio 全体で 1 日にメッセージを送れるユニークな受信者数を制限し、スループットは 1 秒あたりのメッセージ数を、ペア制限は特定の 1 人に送れるメッセージ数を制限します。管理上限は、メッセージ以外の API 呼び出しを制限します。 ### メッセージングティア カスタマーサービスウィンドウの外で、直近 24 時間に何人のお客様へメッセージを届けられるかを示す上限です。2025 年 10 月 7 日以降は Business Portfolio 単位で設定され、その中のすべての番号で共有されます。品質が保たれ、送信量が増えるにつれて自動的に引き上げられます。 - 上限は 1 日あたりのユニークな受信者数で、250、2,000、10,000、100,000、無制限の順に上がります。 - カウントされるのは、カスタマーサービスウィンドウの外で配信したメッセージだけです。 - サービスウィンドウ内の返信はカウントされません。 - 品質が下がっても上限が戻ることはなくなりましたが、上限の引き上げは止まります。 ### スループット 1 秒あたりのメッセージ数で、1 日のティアとは別のものです。ティアには十分な余裕があっても、短時間に一斉送信するとスループットの上限に達することがあります。 Coexistence の番号では、この上限が思わぬ落とし穴になります。標準的な Cloud API の番号より低く設定されているためです。この上限は Meta が定めたもので、すべての Coexistence プロバイダーに適用されるため、どのプロバイダーも引き上げることはできません。 ### 相手ごとの制限 短い期間に、お客様の番号と特定の 1 人の受信者との間でやり取りできるメッセージ数の上限で、エラー 131056 として返されます。1 人に大量のメッセージが届くのを防ぐ仕組みなので、送信量が少ないアカウントでも発生することがあります。 原因はほとんどの場合、自動処理です。リトライのループ、同じイベントに対して Webhook ハンドラーが 2 回呼び出されること、ボットが 1 つの返信を短いメッセージに分割して送ることなどが挙げられます。 ### 管理呼び出しの制限 メッセージとは関係のない制限です。番号の取得、メッセージテンプレートの一覧取得、ステータスの確認はいずれも、アカウント単位の別の上限にカウントされ、エラー 80007 として返されます。 上限を使い切る原因は、ポーリングです。30 秒ごとにステータスを確認すると、月に数回しか変わらないデータに対して 1 日に数千回も呼び出すことになります。Webhook を使えば、そのほとんどが不要になります。 ### 上限が上がる条件 決め手は品質と送信履歴であり、支払いではありません。購入できるプランはなく、お客様に代わって上限を引き上げられるプロバイダーもありません。 - 品質評価を緑に保ってください。評価を下げるのは、受信者によるブロックです。 - 送信量は、一度にまとめて送らず、継続的に保ってください。 - ビジネス認証を完了してください。250 から 2,000 に上がる経路の 1 つです。 - 現在の上限の半分以上を使ってください。2,000 を超える引き上げは自動で行われます。 - すべてのレート制限を 1 つのものとして扱うこと。4 つの制限は、4 種類の異なるエラーを返します。 - 短い間隔でステータスをポーリングすること。ほとんど変わらないデータのために、管理上限を消費してしまいます。 - お金を払えば上限が上がると考えること。上限は品質と履歴に応じて動きます。 **送信量が少ないのにレート制限がかかるのはなぜですか？** おそらく相手ごとの制限（エラー 131056）です。アカウント全体の送信数に関係なく、1 人への送信数が制限されます。 **料金を払ってメッセージング上限を上げることはできますか？** できません。上限は、品質と送信履歴に応じて自動的に上がります。 **Coexistence ではスループットが低くなりますか？** はい。Meta が標準的な Cloud API の番号より低く制限しており、どのプロバイダーも引き上げることはできません。 **管理呼び出しの上限には何がカウントされますか？** 読み取りと設定の呼び出しです。番号、メッセージテンプレート、ステータスの一覧取得が該当します。Webhook を使えば、そのほとんどを避けられます。 --- ## インタラクティブメッセージの送信：ボタンとリスト https://easycoexistence.com/ja/docs/sending-interactive-messages インタラクティブメッセージでは、受信者は入力する代わりにボタンやリストをタップできます。種類は返信ボタンとリストメッセージの 2 つで、どちらも固定された小さな制限があり、会話の設計を大きく左右します。 ### 返信ボタン メッセージの下に最大 3 個のボタンを配置できます。受信者が 1 つをタップすると、ボタンの id を含む通常の受信メッセージとして返信が Webhook に届きます。そのため、ラベルではなく id で照合してください。タイトルは 20 文字までで、思ったより短く、通常は書き直しが必要になる制約です。 - 1 メッセージあたり最大 3 個のボタン - タイトルは 20 文字まで - 各ボタンには任意の id を設定でき、返信で返される - 周囲に任意のヘッダー、本文、フッターを配置できる ### リストメッセージ 1 個のボタンから、最大 10 行のメニューを開けます。メニューは最大 10 セクションに分けられます。各行にはタイトル、任意の説明、id を設定できます。ボタン 3 個では足りない場合に使ってください。受信者はリストを開くまで内容を見られないため、ボタンのラベルが重要です。 - 合計最大 10 行、最大 10 セクション - 行タイトルは 24 文字まで、説明は 72 文字まで - 1 メッセージにつき 1 リストで、ボタンとは組み合わせられない - すべてのカテゴリのメッセージテンプレートで利用できるわけではない ### 返信の届き方 他の受信メッセージと同じ messages Webhook に、ボタンまたは行の id を示す interactive オブジェクトが届きます。別の購読設定は必要ありません。 タイトルではなく id で照合してください。タイトルはコピーを編集する人によって書き換えられます。テキストで照合するハンドラーは、誰かが誤字を直した瞬間に静かに動かなくなります。 ### Coexistence で変わること ボタンとリスト自体については何も変わりません。通常の Cloud API メッセージとして、Coexistence の番号でも他の番号と同じように機能します。 変わるのは返信の届く場所です。Coexistence の番号では、顧客のタップがスマートフォンの WhatsApp Business アプリと Webhook の両方に届きます。自動返信するハンドラーでは、アプリ上で人が同じメッセージに返信する可能性も考慮してください。 - ボタンタイトルで返信を照合する。タイトルは編集されますが、id は変わりません。 - 3 個を超えるボタンを前提に設計する。この上限は固定で、回避策はありません。 - 同じタップに人が WhatsApp Business アプリから返信する可能性を忘れる。 **送信できるボタンの数は？** 3 個です。固定されたプラットフォーム上限で、回避策はありません。 **タップすると何が返りますか？** ボタンまたは行に設定した id を含む、messages Webhook 上の通常の受信メッセージです。 **ボタンとリストは組み合わせられますか？** いいえ。1 メッセージにはどちらか一方だけを含められます。 **追加料金はかかりますか？** いいえ。通常のメッセージとして、同じ会話内の他のメッセージと同じく Meta の料金体系で課金されます。 --- ## メディアの送信：画像、動画、音声、文書 https://easycoexistence.com/ja/docs/sending-media-messages メディアは、ファイルを先にアップロードして返された id を指定する方法と、Meta に取得させる公開リンクを渡す方法で送信できます。アップロードのほうが信頼性が高く、サイズ上限は種類ごとに異なるため注意が必要です。 ### 種類ごとの上限 種類ごとに異なり、上限を超えると説明的なエラーではなく error 131053 が返ります。 - 画像：5 MB。JPEG と PNG。 - 動画：16 MB。MP4 と 3GPP。動画は H.264、音声は AAC。 - 音声：16 MB。AAC、AMR、MP3、MP4 音声、Opus を使用する OGG。 - 文書：100 MB。PDF や Office 形式を含む、一般的な文書形式の多くに対応します。 - ステッカー：アニメーションは 100 KB、静止画は 500 KB。WebP のみ。 ### アップロードとリンクの比較 同じファイルを送る方法は 2 つありますが、失敗の仕方が異なります。 アップロードでは、まずファイルを Meta に送信し、送信時に指定する media id が返されます。リンクでは、送信時に Meta が取得する URL を渡します。リンクの方法は簡単に見えますが、見えない失敗要因が増えます。ブラウザーで開ける URL でも、地域制限、ファイアウォールルール、ブラウザーが保持しているセッション Cookie により、Meta のインフラから到達できない場合があります。 アップロードしてください。リクエストは 1 回増えますが、失敗要因を 1 つの種類ごと取り除けます。 ### メディアの受信 受信したメディアはバイトデータではなく media id として届きます。ハンドラーは、その id を使ってファイルを別途取得します。 - すぐに取得してください。id は無期限に有効ではありません。 - 取得に失敗すると error 131052 が返ります。通常は送信者のアップロードが完了していないことを意味します。 - 後で必要になる場合は、ファイルを自分で保存してください。Meta はアーカイブではありません。 - メディアの取得に失敗してもメッセージを記録し、テキストとコンテキストを残してください。 ### Coexistence で変わること Coexistence 番号のメディアは、他の Cloud API 番号とまったく同じように動作し、上限も同じです。 知っておくべき唯一の違いは履歴です。番号を初めて接続すると、Meta は WhatsApp Business アプリから最近のメッセージを同期します。ただし、この同期の対象はメッセージ本文であり、メディア全体のアーカイブではありません。接続前のメディアは、これまでどおり電話に保存されています。 - 簡単に見えるからとリンクを送る。Meta のネットワークはブラウザーと同じではありません。 - 受信メディアを数時間後に取得する。メディア id には有効期限があります。 - コーデックを確認せずに動画を書き出す。編集ソフトの初期設定は対応していないことがあります。 **送信できる最大ファイルサイズは？** 100 MB です。ただし文書のみです。動画と音声は 16 MB、画像は 5 MB が上限です。 **アップロードと URL のどちらを使うべきですか？** アップロードしてください。到達不能を失敗の原因から取り除けます。 **メディア id はどのくらい有効ですか？** 無期限ではありません。そのため、受信イベントが届いたらすぐにメディアを取得してください。 **接続時に古いメディアも同期されますか？** いいえ。履歴の同期対象は最近のメッセージ内容です。接続前のメディアは電話に残ります。 --- ## メッセージリアクション：絵文字の送受信 https://easycoexistence.com/ja/docs/message-reactions リアクションは、既存のメッセージに 1 つの絵文字を付けます。送信時はメッセージ ID と絵文字を指定し、削除時は削除処理を呼び出さず、同じリアクションの絵文字を空文字列にして送信します。 ### リアクションを送信する type が reaction のメッセージで、リアクション対象のメッセージ ID と 1 つの絵文字を指定します。同じメッセージに 2 つ目のリアクションを送ると、追加ではなく 1 つ目が置き換わります。これは、送信者が 1 メッセージにつき 1 つしかリアクションを持てないためです。 メッセージ ID は、番号から確認できるものでなければなりません。その顧客から受信したメッセージ、または顧客に送信したメッセージが対象です。 ### リアクションを削除する ここが意外に感じられる点です。削除用のリクエストはありません。emoji フィールドを空文字列に設定した同じリアクションメッセージを送信すると、リアクションが消去されます。 削除イベントを想定したハンドラーは、いつまでも待ち続けます。届くのは emoji が空のリアクションで、新しいリアクションと同じ形式です。フィールドを確認して、削除として読み取る必要があります。 ### リアクションを受信する 受信したリアクションは messages Webhook に届きます。type が reaction のメッセージとして、対象のメッセージ ID と絵文字が含まれます。 - messages フィールドを購読してください。リアクション専用のフィールドはありません。 - 空の絵文字は、顧客がリアクションを削除したことを示します。 - 参照されるメッセージ ID は、以前に送信または受信したものです。 - リアクションによって 24 時間のサービスウィンドウが再開することはありません。 ### サービスウィンドウは適用される リアクションはメッセージのため、送信には 24 時間のカスタマーサービスウィンドウが開いている必要があります。3 日前の顧客メッセージにリアクションすると、テキストメッセージと同じく、エラー 131047 が返されます。 顧客からリアクションを受信すると、ウィンドウは再開します。受信したメッセージはすべて対象となるためです。自動化では、最後のメッセージへの親指を立てるリアクションが、自由に返信できる有効なシグナルになります。 - 削除用のエンドポイントを探す。削除は絵文字を空にして同じリクエストを送ります。 - 空の絵文字を不正な形式として扱う。削除はこの形式で表されます。 - サービスウィンドウ外でリアクションを送信する。他のメッセージと同じように失敗します。 **リアクションを削除するにはどうすればよいですか？** 絵文字を空文字列にした同じリアクションメッセージを送信します。削除用のリクエストはありません。 **リアクションに料金はかかりますか？** いいえ。課金対象の会話は開始されません。 **どのメッセージにもリアクションできますか？** 番号から送信または受信したメッセージに限り、24 時間のサービスウィンドウ内でリアクションできます。 **顧客のリアクションでウィンドウは再開しますか？** はい。リアクションを含め、顧客からの受信メッセージで再開します。 --- ## 位置情報と連絡先メッセージの送信 https://easycoexistence.com/ja/docs/sending-location-and-contacts 位置情報メッセージでは、名前や住所を追加したピンを送信できます。連絡先メッセージでは、1 件以上の連絡先カードを送信できます。どちらも簡単ですが、知っておくべき制限があります。移動に合わせて更新されるライブ位置情報は、Coexistence 番号では利用できません。 ### 位置情報メッセージ 緯度と経度に加えて、ピンの下に表示する名前と住所を追加できます。受信者には地図のプレビューが表示され、自分の地図アプリで開けます。 名前と住所の入力には手間をかける価値があります。入力しない場合、ピンには座標だけが表示されるため、顧客は正しい店舗かどうか判断できません。 ### 位置情報の受信 顧客が位置情報を共有すると、座標とともに、顧客のアプリから提供された場合は名前と住所も、タイプが location のメッセージとして messages Webhook に届きます。 - 座標は必ず含まれますが、名前と住所は含まれない場合があります。 - 共有された位置情報はメッセージのため、24 時間のサービスウィンドウが再開します。 - 座標はおおよその位置として扱ってください。電話の精度は異なります。 - 必要な情報だけ保存してください。Meta は位置情報履歴を提供するものではありません。 ### 連絡先メッセージ 1 件のメッセージに 1 件以上の連絡先カードを含められます。各カードには vCard のフィールドである名前、電話番号、メールアドレス、住所、組織、誕生日が含まれます。受信者はカードを直接保存できます。 顧客に適切な担当者の詳細を渡す場合に便利です。チャットに番号を入力すると書式のないテキストとして届き、手作業でコピーする必要があります。 ### Coexistence で利用できなくなる機能 ライブ位置情報は、Coexistence が有効になると Meta が番号で無効にする 4 つの WhatsApp 機能の 1 つです。消えるメッセージ、1 回表示メディア、ブロードキャストリストも含まれます。 これを送信しようとすると、サポートされていないメッセージタイプを示すエラー 131051 が返されます。書式の誤りのように見えますが、実際には違います。Meta の制限であり、すべての Coexistence 番号に適用されるため、どのプロバイダーも有効にできません。固定の位置情報ピンには影響がなく、通常どおり利用できます。 - 名前や住所なしでピンを送信する。座標だけでは顧客に何も伝わりません。 - ライブ位置情報を前提に構築する。すべての Coexistence 番号で無効になっています。 - タイプが実際に利用できないのに、エラー 131051 を書式の問題として扱う。 **ライブ位置情報を送信できますか？** Coexistence 番号では送信できません。Meta が無効にしているため、どのプロバイダーも再び有効にできません。 **固定の位置情報ピンは利用できますか？** はい、通常どおり利用できます。地図プレビューの下に名前と住所を追加表示できます。 **1 件のメッセージに何件の連絡先を含められますか？** 複数含められます。各カードには標準の vCard フィールドが含まれ、受信者は直接保存できます。 **共有された位置情報でサービスウィンドウは再開しますか？** はい。他のメッセージと同じ受信メッセージとして扱われます。 --- ## EasyCoexistence と AiSensy https://easycoexistence.com/ja/compare/easycoexistence-vs-aisensy AiSensyは月額制で提供されるWhatsAppマーケティングおよびチャットボット基盤で、インドのEC企業に広く使われています。EasyCoexistenceはインフラです。Meta独自のCoexistence機能で番号を接続し、メッセージを既存のシステムに配信し、接続済みの番号ごとに課金します。どちらが安いかは、内部で使う製品が必要かどうかで決まります。 ### それぞれの製品とは 同じ購入目的で競合する製品ではありません。その点を明確にすると、比較が役立ちます。 - AiSensy:: ブロードキャストキャンペーン、チャットボットフロー、チーム共有の受信トレイを中心としたWhatsAppエンゲージメント基盤です。連絡先数やエージェント数に上限がある段階制の月額プランで提供されます。 - EasyCoexistence:: Coexistenceのインフラです。スマートフォンのWhatsApp Business アプリはそのまま動作し、Cloud APIは同じ番号で稼働します。メッセージイベントはMetaからCRM、ヘルプデスク、自動化基盤、AIエージェントへ直接送られます。チームが移行する製品はありません。 ### どのような利用者向けか どちらもWhatsAppに接続しますが、想定される日々の作業は異なります。 - AiSensy:: ブロードキャストキャンペーンやチャットボットのファネルを運用するマーケティングチーム向けです。キャンペーン作成、連絡先リスト、分析を1か所で使い、その環境内で作業したい企業に適しています。 - EasyCoexistence:: すでにシステムを持つ企業や開発者向けです。WhatsAppメッセージを既存システムに入れ、接続を維持した後は運用の邪魔をしません。キャンペーンが必要なら、顧客データがある場所で実行できます。 ### スマートフォンでアプリを使い続ける Coexistenceが存在する理由そのものであり、どの基盤にも確認すべき点です。 - AiSensy:: 製品の中心はプラットフォームの受信トレイです。そのため、会話はスマートフォンのWhatsApp Business アプリではなく、そこで処理する想定です。 - EasyCoexistence:: WhatsApp Business アプリはこれまでどおり正確に動作します。スタッフはスマートフォンで返信し、APIは同じ会話を認識します。どちらも停止する必要はありません。それがこの機能のすべてです。 ### 請求額は何に連動するか 構造上の違いであり、規模拡大時の総額を左右します。 - AiSensy:: ユーザー数とプラン階層を基準にしたサブスクリプションです。請求額はチーム規模と解放する機能に連動し、席を使っていなくても支払います。 - EasyCoexistence:: 接続済みの番号です。席数がないため、同僚を追加しても料金はかかりません。番号を追加するほど1番号あたりの料金は下がり、US$ 9からUS$ 1になります。代理店の40番目の番号も最初の番号と同じことができ、料金は安くなります。 ### 解約するとどうなるか 会話を預けるものなら、確認しておきたい点です。 - AiSensy:: 受信トレイ、連絡先履歴、自動化はプラットフォーム内に保存されます。それが機能する理由である一方、離れる際には移行作業が必要になります。 - EasyCoexistence:: お客様のデータが私たちの中に入ることはありません。メッセージは届いた時点で自社システムに配信され、番号はお客様自身のMeta Business Portfolioにあります。そのため、私たちを削除しても元の場所に残ります。 - 自社の利用形態に合わせて両方の必要数を数えず、席単価と番号単価を比較すること - チームがすでにCRMで作業しているのに、受信トレイの料金を支払うこと - WhatsApp接続が異なると思い込むこと。どちらも基盤はMetaのCloud APIです。 **どちらが安いですか？** 利用形態によります。1つの受信トレイを5人で使うチームなら、席数制を選ぶ場合があります。番号と既存システムがある企業なら、私たちの番号単位の料金で大幅に安くなります。 **共有の受信トレイは失いますか？** 共有の受信トレイに移行することはありません。メッセージはチームがすでに使っているツールに届き、そこで作業を続けられます。 **WhatsApp接続は異なりますか？** いいえ。どちらもMetaのCloud APIです。異なるのは、その前に何を置くかと、料金の仕組みです。 **ブロードキャストキャンペーンは使えますか？** 私たちからは提供しておらず、その料金も請求しません。メッセージは自社システムに届くため、顧客データがある場所でキャンペーンを実行できます。 --- ## EasyCoexistence と Interakt の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-interakt Interaktはエージェント数に上限がある月額制のWhatsAppコマースおよびサポート基盤です。EasyCoexistenceはインフラであり、Meta独自のCoexistence機能を通じて番号を接続し、メッセージを既存のシステムに届けます。料金は接続済みの番号単位です。どちらが安いかは、業務に組み込む製品が必要かどうかで決まります。 ### それぞれの製品とは 同じ購入目的を競う製品ではありません。その違いを明確にすると、比較が役立ちます。 - Interakt:: カタログ連携、注文通知、共有受信トレイ、自動化を備えたWhatsAppコマース基盤です。エージェント数と連絡先数に上限がある月額制で提供されます。 - EasyCoexistence:: Coexistenceのインフラです。電話のWhatsApp Business アプリは動作し続け、Cloud APIは同じ番号で動き、メッセージイベントはMetaからCRM、ヘルプデスク、自動化基盤、AIエージェントへ直接届きます。チームが移行して使う製品はありません。 ### コマースのロジックはどこにあるか オンラインストアにとっての本当の分岐点は、カタログがすでにどこにあるかです。 - Interakt:: プラットフォーム内にあり、ストアと接続します。開発なしで注文通知やカタログメッセージを一か所で設定したい場合に便利です。 - EasyCoexistence:: ストア内にあります。WhatsAppのイベントをバックエンドに届けるため、注文を把握している既存のシステムから注文通知を送信できます。別の製品に同期する必要はありません。 ### 代理店が支払う料金 エージェント単位の料金と番号単位の料金の差が、最も大きく表れる部分です。 - Interakt:: エージェント数と連絡先数に上限があるプランです。複数の顧客の番号を管理する企業は、アカウントごとに席数と利用枠を購入します。 - EasyCoexistence:: 1つのアカウントに、必要な数だけ顧客の番号を登録できます。各番号は接続として請求され、利用量に応じて料金が下がります。数えるエージェントも、超過する連絡先枠もありません。 ### 請求額を左右するもの 構造上の違いであり、規模を拡大したときの総額を決める要素です。 - Interakt:: ユーザー数とプラン階層を基準にしたサブスクリプションです。請求額はチームの規模と解放される機能に連動し、席を使わなくても支払います。 - EasyCoexistence:: 接続済みの番号です。席数がないため、同僚を追加しても料金はかかりません。番号を追加するほど1番号あたりの料金は下がり、US$ 9 から US$ 1 まで下がります。代理店の40番目の番号も最初の番号と同じことができ、料金はより安くなります。 ### 解約するとどうなるか 会話を預けるサービスなら、確認しておきたい点です。 - Interakt:: 受信トレイ、連絡先履歴、自動化はプラットフォーム内にあります。それが機能する理由である一方、解約時には移行作業が必要になります。 - EasyCoexistence:: お客様のデータは当社内にありません。メッセージは受信時に自社システムへ届けられ、番号は顧客自身のMeta Business Portfolioにあるため、当社を削除しても元の場所に残ります。 - 自社の構成に必要な両方の数を計算せず、席数料金と番号料金を比較すること - チームがすでにCRMで働いているのに、受信トレイの料金を支払うこと - WhatsAppの接続方式が異なると思い込むこと。どちらも基盤はMetaのCloud APIです。 **どちらが安いですか？** 一律の答えはありません。1つの受信トレイを5人で使うチームは席数制を選ぶ可能性があります。番号が多く既存システムを使う企業は、当社なら番号単位で大幅に安くなります。 **共有受信トレイは失われますか？** 共有受信トレイへ移行することはありません。メッセージはチームがすでに使っているツールに届き、そこで対応できます。 **WhatsAppの接続方式は異なりますか？** いいえ。どちらもMetaのCloud APIです。異なるのは、その前段に何を置くかと、料金の計算方法です。 **カタログメッセージは送れますか？** はい。自社の番号でCloud APIを通じて送信し、自社システムから配信できます。ストアにはすでにカタログがあるため、当社がカタログを構築することはありません。 --- ## EasyCoexistenceとDoubleTickの比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-doubletick DoubleTickはユーザー単位で販売されるWhatsApp営業プラットフォームで、モバイル中心の共有受信箱を軸にしています。EasyCoexistenceはインフラです。Meta独自のCoexistence機能で番号を接続し、メッセージを既存のシステムへ届け、接続済みの番号単位で課金します。どちらが安いかは、どの製品を業務に組み込みたいかによって異なります。 ### それぞれの製品とは 同じ購入目的を競う製品ではありません。その点を明確にすると、比較が役立ちます。 - DoubleTick:: モバイル共有受信箱、バルクメッセージ送信、カタログ共有を軸にしたWhatsApp営業プラットフォームです。ユーザーシート単位で課金され、スマートフォンで働く営業チームを対象にしています。 - EasyCoexistence:: Coexistenceインフラです。スマートフォンのWhatsApp Business アプリは動作し続け、Cloud APIは同じ番号で稼働し、メッセージイベントはMetaからCRM、ヘルプデスク、自動化ツール、AIエージェントへ直接送られます。チームが移行する製品はありません。 ### 営業チームの日々の働き方 両製品の購入判断の根底にある違いです。 - DoubleTick:: 共有受信箱、カタログ、バルク送信がある同社のアプリ内で働きます。月額約 2,500 ルピーから始まり、ユーザー単位で課金されるため、請求額は営業担当者の人数に応じて変わります。 - EasyCoexistence:: チームがすでに使っているCRM内で働きます。会話をそこへ届けるため、営業担当者は別のアプリを開く必要がなく、案件情報の横でWhatsAppを確認できます。 ### 2つ目の番号の料金 複数の回線を使う営業業務では、よくある論点です。 - DoubleTick:: 課金単位はシートです。そのため、2つ目の番号にも、チームの人数に応じて増えるユーザー単位のサブスクリプションがかかります。 - EasyCoexistence:: 2つ目の番号は、公開料金で追加する2つ目の番号にすぎず、番号が増えるほど料金は下がります。従業員数は計算に一切入りません。 ### 請求額が連動するもの 構造上の違いであり、規模拡大時の総額を決める違いです。 - DoubleTick:: ユーザー数とプラン階層を軸にしたサブスクリプションです。請求額はチームの規模と利用可能な機能に連動し、シートを使っていなくても支払います。 - EasyCoexistence:: 接続済みの番号です。シートがないため、同僚を追加しても料金はかかりません。番号が増えるほど 1 件あたりの料金は下がり、US$ 9 から US$ 1 になります。代理店の 40 件目の番号も 1 件目と同じことができ、料金は安くなります。 ### 解約するとどうなるか 会話を預けるサービスには、確認しておく価値があります。 - DoubleTick:: 受信箱、連絡先履歴、自動化機能はプラットフォーム内にあります。それによって機能しますが、解約時には移行プロジェクトが必要になります。 - EasyCoexistence:: お客様のデータは当社内にありません。メッセージは到着時にお客様のシステムへ届けられ、番号はお客様自身のMeta Business Portfolioにあるため、当社を削除しても元の場所に残ります。 - 自社の運用形態に合わせて両方の料金を計算せず、シート料金と番号料金を比較することです。 - チームがすでにCRMで働いているのに、受信箱の料金を支払うことです。 - WhatsAppの接続方法が異なると思い込むことです。どちらも基盤はMetaのCloud APIです。 **どちらが安いですか？** 運用形態によって異なります。1つの受信箱を5人で使うチームなら、シート課金が合う場合があります。複数の番号と既存システムがある企業なら、当社の番号課金で大幅に安くなります。 **共有受信箱は失いますか？** 共有受信箱へ移行する必要はありません。メッセージはチームがすでに使っているツールに届き、そこで業務を続けられます。 **WhatsAppの接続方法は異なりますか？** いいえ。どちらもMetaのCloud APIです。異なるのは、その前段に何があるかと、料金の計算方法です。 **モバイルアプリはありますか？** 当社はインフラなので、チームが使うのはすでに利用しているアプリです。スマートフォンのWhatsApp Business アプリも、利用中ずっと動作します。 --- ## EasyCoexistence と Zoko の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-zoko ZokoはShopifyストア向けのWhatsAppコマース基盤で、月額プランで提供されます。EasyCoexistenceはインフラです。Meta独自のCoexistence機能で番号を接続し、メッセージを既存のシステムに届け、接続済みの番号ごとに課金します。どちらが安いかは、内部で使う製品を求めるかによって異なります。 ### 各製品の違い 同じ購入目的を競う製品ではありません。その点を明確にすると、比較が役立ちます。 - Zoko:: Shopifyを中心に設計されたWhatsAppコマース基盤で、カタログ、カート放棄対策、注文フロー、共有受信箱を月額プランで提供します。 - EasyCoexistence:: Coexistenceのインフラです。スマートフォンのWhatsApp Business アプリはそのまま使え、同じ番号でCloud APIが動作し、メッセージイベントはMetaからCRM、ヘルプデスク、自動化システム、AI エージェントへ直接届きます。チームが移行して使う製品はありません。 ### Shopifyストアの場合 本当に異なる購入目的だからこそ、正直な答えが必要です。 - Zoko:: まさにその用途のために作られています。カート回収、カタログ、注文フローは開発ではなく設定で使えるため、Shopifyが事業のすべてで、今週中に稼働させたいなら実質的な価値があります。 - EasyCoexistence:: 下位のレイヤーです。ストアがShopifyでない場合や、ロジックが自社バックエンドにある場合、WhatsAppのイベントをそこへ届け、メッセージの意味を自社システムに判断させます。対応していないプラットフォームに合わせた設定はありません。 ### ストアが事業のすべてでない場合 ストア中心の製品が合わなくなるケースです。 - Zoko:: 1つのエコシステムに深く対応します。これは専門製品が選ぶトレードオフであり、その中で強く機能する理由でもあります。 - EasyCoexistence:: エコシステムを問いません。Webhookは指定したエンドポイントに届くため、同じ接続をShopifyストア、自社バックエンド、n8nワークフロー、AI エージェントで使えます。番号の接続方法は変わりません。 ### 請求額を決めるもの 構造上の違いであり、成長時の合計額を左右します。 - Zoko:: ユーザー数とプラン階層を軸にしたサブスクリプションです。請求額はチームの規模と解放される機能に連動し、ユーザー枠を使わなくても支払います。 - EasyCoexistence:: 接続済みの番号です。ユーザー枠がないため、同僚を追加しても料金はかかりません。番号を追加するほど1番号あたりの料金は下がり、US$ 9 から US$ 1 になります。代理店の40番目の番号も最初の番号と同じ機能で、料金は安くなります。 ### 解約するとどうなるか 会話を預ける製品なら、確認しておく価値があります。 - Zoko:: 受信箱、連絡先履歴、自動化は製品内にあります。それが機能する理由である一方、離れる際には移行作業が必要になります。 - EasyCoexistence:: こちらにお客様のデータはありません。メッセージは届くたびに自社システムへ配信され、番号は顧客自身のMeta Business Portfolioにあるため、接続を外しても元の場所に残ります。 - 自社の構成に必要な両方の数を数えず、ユーザー枠の料金と番号ごとの料金だけを比較すること - チームがすでにCRMで働いているのに、受信箱の料金を支払うこと - WhatsAppの接続方法が異なると思い込むこと。どちらも基盤はMetaのCloud APIです。 **どちらが安いですか？** 構成によって異なります。1つの受信箱を5人で使うチームなら、ユーザー枠が合う場合があります。番号と既存システムを使う企業なら、当社では番号ごとの料金が大幅に安くなります。 **共有受信箱は失われますか？** 共有受信箱へ移行する必要はありません。メッセージはチームがすでに使っているツールに届き、そのままそこで対応できます。 **WhatsAppの接続方法は異なりますか？** いいえ。どちらもMetaのCloud APIです。異なるのは、その前に何を置くかと、料金の計算方法です。 **Shopifyを使っています。Zokoを使うべきですか？** Zokoは設定済みのShopifyフローを月額プランで提供します。ロジックが自社ストアやバックエンドにあるなら、当社はUS$ 9で番号ごとにWhatsAppを組み込み、注文データがある場所でフローを維持できます。 --- ## EasyCoexistence と Trengo の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-trengo TrengoはWhatsApp、メール、音声、チャットに対応する、ユーザー単位で料金が決まるマルチチャネルのチーム用受信箱です。EasyCoexistenceはインフラであり、Meta独自のCoexistence機能を通じて番号を接続し、メッセージを既存のシステムへ届けます。料金は接続済み番号単位です。既存システムを使う場合は、EasyCoexistenceのほうが安くなります。 ### それぞれの製品とは 同じ購入対象を競う製品ではありません。その点を明確にすると、比較の意味が分かります。 - Trengo:: WhatsApp、メール、ライブチャット、音声、ソーシャルを1つの画面にまとめるマルチチャネルのチーム用受信箱です。ユーザー席単位で課金され、複数チャネルを扱うサポートチームを対象としています。 - EasyCoexistence:: Coexistenceのインフラです。スマートフォンのWhatsApp Business アプリはそのまま動作し、Cloud APIは同じ番号で動き、メッセージイベントはMetaからCRM、ヘルプデスク、自動化システム、AIエージェントへ直接送られます。チームが移行して使う別の製品はありません。 ### すべてのチャネルを1つの受信箱で Trengoの中心的な提案であり、適したチームには有効です。 - Trengo:: メール、WhatsApp、チャット、音声を1か所で扱い、担当者の割り当てやルールを共有できます。タブを行き来し続けるサポートチームにとって、この統合こそが製品であり、実際に機能します。 - EasyCoexistence:: 当社は1つのチャネルに対応し、統合を求めません。ヘルプデスクがすでにメールとチャットを扱っているなら、WhatsAppは Webhook 経由でそこに届き、チームは別のツールを覚える必要がありません。 ### チームが成長したときの料金 席数単位の料金には一定の傾向があります。採用前に確認する価値があります。 - Trengo:: ユーザー単位の料金なので、WhatsAppを使うかどうかにかかわらず、新しいサポート担当者を採用するたびに月額料金が増えます。 - EasyCoexistence:: 番号単位の料金です。請求単位は担当者ではなく接続なので、2人のサポートチームも20人のサポートチームも同じ料金です。 ### 請求額を決めるもの 構造上の違いであり、規模が大きくなったときの総額を左右します。 - Trengo:: ユーザー数とプラン階層を軸にしたサブスクリプションです。チームの規模と利用できる機能に応じて請求され、席を使っていなくても料金が発生します。 - EasyCoexistence:: 接続済み番号です。席数がないため、同僚を追加しても料金はかかりません。番号を追加するほど1件あたりの料金は下がり、US$ 9 から US$ 1 になります。代理店の40番目の番号も最初の番号と同じことができ、料金はさらに安くなります。 ### 利用をやめるとどうなるか 会話を保管するものについては、確認しておく価値があります。 - Trengo:: 受信箱、連絡先履歴、自動化機能はプラットフォーム内にあります。それによって機能する一方、利用をやめると移行プロジェクトが必要になります。 - EasyCoexistence:: 当社の中に顧客のデータはありません。メッセージは到着時に顧客自身のシステムへ届けられ、番号は顧客自身のMeta Business Portfolioにあります。そのため当社を削除しても、番号は元の場所に残ります。 - 自社の利用形態に合わせて双方の料金を計算せず、席単位と番号単位の料金だけを比較することです。 - チームがすでにCRMで業務をしているのに、受信箱の料金を支払うことです。 - WhatsAppの接続方式が異なると思い込むことです。どちらも基盤にはMetaのCloud APIを使っています。 **どちらが安いですか？** 既存システムがあり、番号単位で使う企業なら、EasyCoexistenceのほうが安くなります。1つの受信箱で5人が使う場合は、席単位の製品が適することもあります。 **共有受信箱は失われますか？** 共有受信箱へ移行する必要はありません。メッセージはチームがすでに使っているツールに届き、そこで業務を続けられます。 **WhatsAppの接続方式は異なりますか？** いいえ。どちらもMetaのCloud APIです。異なるのは、その前段に何を置くかと、料金の計算方法です。 **メールやチャットも必要です。対応していますか？** いいえ。メールやチャットの料金も請求しません。すでに他のチャネルを扱っているヘルプデスクへ、WhatsAppを接続します。 --- ## EasyCoexistence と Rasayel の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-rasayel Rasayel は CRM 連携に対応した WhatsApp 中心の営業受信トレイで、料金はユーザー単位です。EasyCoexistence はインフラであり、Meta 独自の Coexistence 機能を通じて番号を接続し、メッセージを既存のシステムに届けます。料金は接続済みの番号単位です。どちらが安いかは、既存システム内で動く製品を求めるかどうかで変わります。 ### それぞれの製品とは 同じ購入目的の製品ではありません。違いを明確にすると、比較しやすくなります。 - Rasayel:: HubSpot や Pipedrive などの CRM と双方向連携できる、営業チーム向けの WhatsApp 中心の共有受信トレイです。料金はユーザー枠単位です。 - EasyCoexistence:: Coexistence のインフラです。電話の WhatsApp Business アプリはそのまま使え、同じ番号で Cloud API が動作し、メッセージイベントは Meta から CRM、ヘルプデスク、自動化ツール、AI エージェントへ直接届きます。チームが移行して使う製品はありません。 ### WhatsApp を CRM に取り込む方法 2 つの製品が最も近い部分です。ここは正確に見ておく価値があります。 - Rasayel:: 受信トレイの会話を CRM に同期するため、営業担当者はどちらでも作業でき、記録も引き継がれます。実際の製品であり、その裏には実際の開発があります。 - EasyCoexistence:: メッセージは Meta から CRM に直接届くため、間に同期用の受信トレイはありません。会話は 2 つではなく 1 つだけになり、同期に失敗しても照合作業は不要です。 ### 料金の対象 どちらも WhatsApp を CRM に届けますが、請求方法が異なります。 - Rasayel:: 受信トレイが製品であり、営業担当者はそこで作業するため、ユーザー枠に対して料金がかかります。 - EasyCoexistence:: 接続そのものが料金の対象です。営業チーム全員が、すでに料金を支払っている CRM 内で WhatsApp を読み取れ、人数に関係なく番号単位で請求します。 ### 請求額を左右するもの 構造上の違いであり、規模拡大時の総額を決めるポイントです。 - Rasayel:: ユーザー数とプラン階層に応じたサブスクリプションです。チームの規模や利用できる機能に応じて請求され、ユーザー枠を使わなくても料金が発生します。 - EasyCoexistence:: 接続済みの番号です。ユーザー枠がないため、同僚を追加しても費用はかかりません。番号を追加するほど 1 件あたりの料金は下がり、US$ 9 から US$ 1 になります。代理店の 40 件目の番号も 1 件目と同じことができ、料金は安くなります。 ### 解約するとどうなるか 会話を保持する製品なら、確認しておきたい点です。 - Rasayel:: 受信トレイ、連絡先履歴、自動化はプラットフォーム内に保存されます。それが機能する理由である一方、解約時には移行作業が必要になります。 - EasyCoexistence:: お客様のデータが当社内に保存されることはありません。メッセージは到着時にお客様のシステムへ届けられ、番号もお客様自身の Meta Business Portfolio にあるため、当社を削除しても元の場所に残ります。 - 自社の利用形態に必要な数を数えず、ユーザー枠単位と番号単位の料金だけを比較すること - チームがすでに CRM で作業しているのに、受信トレイに料金を支払うこと - WhatsApp の接続方式が異なると思い込むこと。どちらも基盤は Meta の Cloud API です。 **どちらが安いですか？** 利用形態によって異なります。1 つの受信トレイを使う 5 人のチームなら、ユーザー枠が適する場合があります。番号が複数あり既存システムを使う企業なら、当社の番号単位料金のほうが大幅に安くなります。 **共有受信トレイはなくなりますか？** 共有受信トレイへ移行することはありません。メッセージはチームがすでに使っているツールに届き、そこで作業できます。 **WhatsApp の接続方式は異なりますか？** いいえ。どちらも Meta の Cloud API です。異なるのは、その前に何を置くかと請求方法です。 **HubSpot と連携できますか？** Meta の Webhook を任意のエンドポイントに届けるため、受信 Webhook に対応した CRM や、その前段のワークフローツールで会話を直接受け取れます。 --- ## EasyCoexistence と Callbell の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-callbell Callbell は小規模チーム向けの、ユーザー単位で課金される複数担当者向け WhatsApp 受信トレイです。EasyCoexistence はインフラで、Meta 独自の Coexistence 機能を通じて番号を接続し、メッセージを既存のシステムに届け、接続済みの番号単位で課金します。どちらが安いかは、チームをどの製品内で働かせるかで決まります。 ### それぞれの製品とは 同じ購入目的の製品ではありません。その違いを明確にすると、比較が役立ちます。 - Callbell:: チャットボットのフローと基本的な自動化を備えた、小規模チーム向けの複数担当者向け WhatsApp 受信トレイです。ユーザー席単位で課金され、ラテンアメリカや南ヨーロッパの小規模企業に利用されています。 - EasyCoexistence:: Coexistence のインフラです。スマートフォンの WhatsApp Business アプリはそのまま動作し、同じ番号で Cloud API が動き、メッセージイベントは Meta から CRM、ヘルプデスク、自動化ツール、AI エージェントへ直接送られます。チームが移行して使う製品はありません。 ### 小規模チームの場合 相手の料金が最も妥当になり、比較が最も近くなるケースです。 - Callbell:: 1つの番号を 2 人または 3 人の担当者で共有し、簡単な受信トレイを使い、CRM 連携がない場合です。公開料金はユーザー単位の月額で、WhatsApp も追加料金となるため、この規模でも席数の料金とチャネル料金が発生します。 - EasyCoexistence:: すでにシステムを持つ同じ企業の場合です。スプレッドシートや簡単なバックエンドで注文を管理する小規模店舗なら、席の料金より安く WhatsApp を組み込めます。スタッフはこれまでどおり WhatsApp Business アプリで返信できます。 ### 複数拠点で 1 つのアカウント 両者の違いが明確に分かれるケースです。 - Callbell:: 契約には番号ごとの料金と担当者ごとの料金が含まれるため、店舗チェーンは席数と番号を同時に購入します。 - EasyCoexistence:: 各拠点が公開料金の接続 1 件となり、追加するほど料金が下がります。10 個の番号を持つ 10 店舗と 40 人のスタッフでも、支払うのは 10 個分の番号料金です。 ### 請求額を左右するもの 構造上の違いであり、規模を拡大したときの合計額を決めるポイントです。 - Callbell:: ユーザー数とプラン階層を中心としたサブスクリプションです。請求額はチーム規模と解放する機能に連動し、席を使っていなくても料金がかかります。 - EasyCoexistence:: 基準は接続済みの番号です。席数がないため、同僚を追加しても料金はかかりません。番号を追加するほど、1 件あたりの料金は US$ 9 から US$ 1 まで下がります。代理店の 40 件目の番号も、1 件目と同じ機能を使えて、料金は安くなります。 ### 解約するとどうなるか 会話を預けるサービスなら、確認しておきたい点です。 - Callbell:: 受信トレイ、連絡先の履歴、自動化はプラットフォーム内に保存されます。それによって機能する一方、解約時には移行作業が必要になります。 - EasyCoexistence:: お客様のデータは EasyCoexistence 内に保存されません。メッセージは到着時にお客様のシステムへ届けられ、番号もお客様自身の Meta Business Portfolio にあるため、接続を解除しても元の場所に残ります。 - 自社の利用形態に必要な両方の料金を計算せず、席単価と番号単価だけを比較すること - チームがすでに CRM で働いているのに、受信トレイに料金を支払うこと - WhatsApp の接続方式が異なると思い込むこと。どちらも基盤は Meta の Cloud API です。 **どちらが安いですか？** 1つの受信トレイを 5 人で使うなら席課金が合う場合があります。番号と既存システムがある企業なら、EasyCoexistence の番号課金のほうが大幅に安くなります。 **共有受信トレイは失いますか？** 共有受信トレイへ移行することはありません。メッセージはチームがすでに使っているツールに届き、そこで対応できます。 **WhatsApp の接続方式は異なりますか？** いいえ。どちらも Meta の Cloud API です。異なるのは、その前段に何があるかと、料金の請求方法です。 **2 人の担当者なら Callbell のほうが安いですか？** 1つの番号だけで既存システムがない場合は、Callbell のほうが安くなることがあります。2 つ目の拠点や CRM を追加すると、番号課金のほうがすぐに有利になります。 --- ## EasyCoexistence と Baileys の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-baileys Baileysは、リンク済みデバイスのプロトコルを直接実装してWhatsAppに接続するオープンソースライブラリです。動作し、無料または低コストですが、公式の方法にはないリスクがあります。WhatsAppのビジネス規約はリンク済みデバイスのセッションによる自動メッセージ送信を想定しておらず、この方法で使用する番号は予告なく制限または停止される可能性があります。EasyCoexistenceは、Meta独自のCoexistence機能を通じて同じ番号を接続します。 ### WhatsAppへの接続方法 比較の核心はここにあり、ほかの違いもすべてここから生じます。 - Baileys:: WhatsAppのリンク済みデバイスプロトコルを WebSocket で実装する TypeScript ライブラリです。QRコードをスキャンしてWebクライアントと同じ方法でログインし、その後のセッションを自ら保持します。Metaに申請しないため、Metaの承認は必要ありません。 - EasyCoexistence:: Metaが顧客自身の WhatsApp Business アカウントに発行した認証情報で、Coexistenceを通じてMetaの Cloud APIに接続します。番号はMetaにAPI番号として登録され、同時にスマートフォン上の WhatsApp Business アプリも使い続けられます。 ### 問題が起きたときの違い どちらも時々停止します。違うのは、問い合わせ先があるかどうかです。 - Baileys:: GitHub上のコミュニティプロジェクトです。WhatsAppがプロトコルを変更すると、ライブラリが対応するまで接続が停止します。サポート契約も停止への異議申し立てもありません。 - EasyCoexistence:: Meta自身のインフラ上の接続を継続的に監視します。切断時はMetaの切断理由を確認できるため、14 日間の非アクティブ状態と実際の削除を区別でき、顧客が気づく前にお知らせします。 ### 実際の料金 非公式の方法は無料に見えますが、比較の本質はライセンス料金ではありません。 - Baileys:: ライブラリ自体は無料ですが、実行用のサーバー、維持するセッション、それを理解するエンジニアが必要です。コストはライセンスではなく、保守とリスクにあります。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 からで、ホスティング、監視、MCPコネクターを含みます。サーバーの運用、セッションの再接続、プロトコル変更時の再構築は不要です。 ### 実際にできること ここが率直な部分であり、非公式プロジェクトが存在する理由でもあります。 - Baileys:: 公式APIより多くのことができる場合があります。グループチャット、個人間の会話、プレゼンス、既読通知をプロトコルレベルで扱えます。それがこの方法の存在理由です。 - EasyCoexistence:: Cloud APIで許可されるすべての機能を使えます。メッセージ、テンプレート、メディア、インタラクティブメッセージの送受信が可能で、WebhookはMetaから配信されます。グループチャットはAPIの対象外で、自由形式の返信には24 時間のウィンドウが必要です。これはMetaのルールであり、すべての公式プロバイダーに適用されます。 ### どちらを選ぶべきか どちらにも適した用途があり、番号の価値によって決まります。 - 失っても問題ない番号での個人プロジェクトなら、非公式の方法は無料で多機能です。 - 企業が顧客対応に使う番号なら、停止で業務用回線が失われるため公式の方法を選んでください。 - 顧客の番号を使う場合は、リスクを自社で負うべきではないため公式を選んでください。 - スマートフォンで WhatsApp Business アプリを使い続ける必要がある場合は、私たちが提供する Coexistence を選んでください。 - 企業の番号で非公式ブリッジを試す。停止は予告なく発生し、異議申し立てもできません。 - 長期間の稼働実績を安全性とみなす。取り締まりは継続的ではなく、断続的に行われます。 - 停止の影響がAPIだけに及ぶと思い込む。WhatsApp Businessのプロフィールも失われます。 **Baileysは実際に動作しますか？** はい。そのため人気があります。問題は動作するかではなく、WhatsAppに検知されたとき番号がどうなるかです。 **この方法で番号が停止されることはありますか？** はい。WhatsAppのビジネス規約は非公式アクセスを想定しておらず、取り締まりに際して予告も異議申し立てもありません。 **御社を使うと WhatsApp Business アプリは停止しますか？** いいえ。それが Coexistence の目的です。スマートフォン上のアプリを使いながら、同じ番号で Cloud API を実行できます。 **Baileysは違法ですか？** 犯罪ではありませんが、WhatsAppのビジネス規約が想定していない方法です。法的措置ではなく、番号に対する取り締まりが結果として生じます。 --- ## EasyCoexistence と WPPConnect の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-wppconnect WPPConnect は、制御されたブラウザセッションで WhatsApp Web を自動化するオープンソースプロジェクトです。動作し、無料または安価ですが、公式の方法にはないリスクがあります。WhatsApp のビジネス規約はリンク済みデバイスのセッションによる自動メッセージ送信を想定しておらず、この方法で使用する番号は警告なく制限または利用停止になる可能性があります。EasyCoexistence は Meta 独自の Coexistence 機能を通じて、同じ番号を接続します。 ### それぞれ WhatsApp に接続する方法 比較の核心はここにあり、他の違いもすべてここから生じます。 - WPPConnect:: ヘッドレスセッションで WhatsApp Web を操作し、その上に REST ラッパーを置くブラウザ自動化プロジェクトです。番号は QR コードでリンクされ、セッションはブラウザプロファイル内に保存されるため、WhatsApp からは API クライアントではなくリンク済みデバイスとして認識されます。 - EasyCoexistence:: Meta が顧客自身の WhatsApp Business アカウント向けに発行した認証情報を使い、Coexistence 経由で Meta の Cloud API に接続します。番号は Meta に API 番号として登録され、同時にスマートフォンの WhatsApp Business アプリも使い続けられます。 ### 問題が起きたときの違い どちらも時々停止します。違いは、問い合わせ先があるかどうかです。 - WPPConnect:: 活発で対応の早いオープンソースコミュニティがありますが、誰かに対応する義務はありません。WhatsApp Web の変更でセッション処理が壊れる可能性があり、アクセスが認可されていないため、利用停止になっても異議申し立ての道はありません。 - EasyCoexistence:: Meta 自身のインフラ上で接続し、継続的に監視します。停止したときは Meta 自身の切断理由を読み取れるため、14 日間の非アクティブ状態と本当の削除を区別でき、お客様が気づく前に通知できます。 ### 実際にかかる料金 非公式の方法は無料に見えますが、比較すべきなのはライセンス料金だけではありません。 - WPPConnect:: 無料ですが、ブラウザを常時稼働させられるサーバー、各セッション用のメモリ、セッション停止時に再起動する担当者が必要です。番号が増えるほど、その負担も増えます。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 からで、ホスティング、監視、MCP コネクターを含みます。サーバーの運用も、セッションの再リンクも、プロトコル変更時の再構築も必要ありません。 ### それぞれが実際にできること 非公式プロジェクトが存在する理由でもある、正直な比較です。 - WPPConnect:: WhatsApp Web でできることはすべて実行でき、グループや個人チャットにも対応します。公式 API より機能の幅が広い点は事実です。ただし、ブラウザが経路に入るため、動作は遅く負荷も大きくなります。 - EasyCoexistence:: Cloud API が許可するすべての機能を利用できます。メッセージ、テンプレート、メディア、インタラクティブメッセージの送受信に対応し、Webhook は Meta から配信されます。グループチャットは API の対象外で、自由形式の返信には 24 時間のウィンドウが開いている必要があります。これらは Meta のルールであり、すべての公式プロバイダーに適用されます。 ### どちらを選ぶべきか どちらにも適した用途があり、番号の価値によって決まります。 - 失っても困らない番号での趣味のプロジェクトなら、無料で機能の多い非公式の方法が適しています。 - 企業が顧客対応に使う番号なら、利用停止で業務回線が失われるため、公式の方法を選んでください。 - 顧客の番号を使うものは、リスクを自分で負うべきではないため、公式の方法を選んでください。 - スマートフォンで WhatsApp Business アプリを使い続ける必要がある場合は、私たちが提供する Coexistence を選んでください。 - 企業の番号で非公式ブリッジを試すこと。利用停止は警告も異議申し立てもなく発生します。 - 長年の稼働実績を安全性とみなすこと。取り締まりは継続的ではなく、断続的に行われます。 - 利用停止の影響が API だけに及ぶと思うこと。WhatsApp Business プロフィールも失われます。 **WPPConnect は実際に動作しますか？** はい。だから人気があります。問題は動作するかではなく、WhatsApp に気づかれたとき番号に何が起きるかです。 **この方法で番号が利用停止になることはありますか？** はい。WhatsApp のビジネス規約は非公式アクセスを想定しておらず、取り締まりに警告も異議申し立てもありません。 **御社を使うと WhatsApp Business アプリは停止しますか？** いいえ。それが Coexistence の目的です。スマートフォンのアプリを使いながら、同じ番号で Cloud API を実行できます。 **ブラジルで人気なのはなぜですか？** 早くから普及し、ドキュメントがポルトガル語で、無料だったため、現地の連携では一世代にわたり標準的な選択肢になりました。 --- ## EasyCoexistenceとEvolution APIの比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-evolution-api Evolution APIは、非公式のWhatsAppライブラリを扱いやすいREST APIで包むオープンソースのAPIです。動作し、無料または安価ですが、公式の方法にはないリスクがあります。WhatsAppのビジネス規約はリンク済みデバイスのセッションによる自動メッセージ送信を想定しておらず、この方法で使用する番号は予告なく制限または停止される可能性があります。EasyCoexistenceは、Meta独自のCoexistence機能を通じて同じ番号を接続します。 ### それぞれWhatsAppにどう接続するか 比較の核心はここにあり、ほかの違いもすべてここから生まれます。 - Evolution API:: リンク済みデバイスのライブラリを扱いやすいインターフェースで包む、自前運用のREST APIと管理機能です。ダッシュボード、複数インスタンス、Webhookに対応しています。開発者体験は良好ですが、各インスタンスの実体はQRコードでリンクしたデバイスです。 - EasyCoexistence:: Metaが顧客自身のWhatsApp Business Account向けに発行した認証情報を使い、Coexistence経由でMetaのCloud APIに接続します。番号はMetaにAPI番号として登録され、同時にスマートフォン上のWhatsApp Business アプリも動作し続けます。 ### 問題が起きたときどうなるか どちらも、ときどき停止します。違いは、問い合わせられる相手がいるかどうかです。 - Evolution API:: 大規模なコミュニティを持つ、活発なオープンソースプロジェクトです。インターフェースは安定していますが、包んでいる対象は認可されていません。そのため、非公式アクセスを理由に停止された番号は、ラッパーの品質にかかわらず失われます。 - EasyCoexistence:: Meta自身のインフラ上で動く接続を継続的に監視します。切断時にはMeta独自の切断理由を読み取れるため、14 日間の非アクティブ状態と実際の削除を区別でき、お客様が気づく前に通知できます。 ### 料金を正直に比較すると 非公式の方法は無料に見えますが、比較の本質はライセンス料金ではありません。 - Evolution API:: ライセンスは無料で、自分でホスティングします。実際のコストはインフラと、それを維持する担当者です。見た目が整っているため始めやすくても、その本質は変わりません。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 からで、ホスティング、監視、MCPコネクタを含みます。サーバーの運用、セッションの再リンク、プロトコル変更時の作り直しは必要ありません。 ### 実際にできること 非公式プロジェクトが存在する理由そのものです。 - Evolution API:: メッセージの送受信、メディア、グループ、1 回のデプロイからの複数インスタンスに対応し、Webhookと使いやすいダッシュボードも利用できます。開発者にとって、利用できる非公式の選択肢の中では最も扱いやすい部類です。 - EasyCoexistence:: Cloud APIで許可されるすべての機能を使えます。メッセージ、テンプレート、メディア、インタラクティブメッセージの送受信に対応し、WebhookはMetaから配信されます。グループチャットはAPIの対象外で、自由形式の返信には24 時間のウィンドウが開いている必要があります。これらはMetaのルールであり、すべての公式プロバイダーに適用されます。 ### どちらを選ぶべきか どちらにも選ぶ理由があります。番号にどれだけ価値があるかで決まります。 - 失っても構わない番号での趣味プロジェクトなら、非公式の方法は無料で高機能です。 - 企業が顧客対応に使う番号なら、公式の方法を選んでください。停止されると業務用の回線が使えなくなるためです。 - 顧客の番号を使う場合は、公式の方法を選んでください。リスクを負うべきではありません。 - スマートフォン上でWhatsApp Business アプリを使い続ける必要があるなら、私たちが提供するCoexistenceです。 - 企業の番号で非公式ブリッジを試すこと。停止は予告も異議申し立ての機会もなく発生します。 - 何年も稼働した実績を安全性と読み違えること。取り締まりは継続的ではなく、周期的に行われます。 - 停止の影響がAPIだけだと思うこと。WhatsApp Businessのプロフィールも失われます。 **Evolution APIは実際に動作しますか？** はい。人気がある理由もそこにあります。問題は動作するかではなく、WhatsAppに検知されたとき番号がどうなるかです。 **この方法で番号が停止されることはありますか？** はい。WhatsAppのビジネス規約は非公式アクセスを想定しておらず、取り締まりに予告も異議申し立ての機会もありません。 **御社を使うとWhatsApp Business アプリは使えなくなりますか？** いいえ。それがCoexistenceの目的です。スマートフォン上のアプリを使い続けながら、同じ番号でCloud APIを動かせます。 **見た目はプロ向けです。より安全ですか？** いいえ。インターフェースは多くの選択肢より優れていますが、包んでいるのは同じリンク済みデバイス方式で、取り締まりの対象はラッパーではなく番号です。 --- ## EasyCoexistence と Whapi の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-whapi Whapi は、非公式ゲートウェイ経由で WhatsApp へのアクセスを提供するホステッドサービスです。動作し、無料または安価ですが、公式ルートにはないリスクがあります。この方法で接続した番号は WhatsApp の利用規約違反となり、予告なく利用停止される可能性があります。EasyCoexistence は Meta 独自の Coexistence 機能を通じて、同じ番号を接続します。 ### それぞれ WhatsApp にどう接続するか 比較の核心はここにあり、他の違いもすべてここから生じます。 - Whapi:: REST API と有料プランを備えたホステッドゲートウェイです。サーバーの運用やライブラリの保守が不要という利便性はあります。ただし実際には、番号は Meta に API 番号として登録されず、デバイスとしてリンクされます。 - EasyCoexistence:: クライアント自身の WhatsApp Business アカウントに Meta が発行した認証情報を使い、Coexistence 経由で Meta の Cloud API に接続します。番号は Meta に API 番号として登録され、同時にスマートフォン上の WhatsApp Business アプリも動作します。 ### 問題が起きたときにどうなるか どちらも時々停止します。違いは、問い合わせられる相手がいるかどうかです。 - Whapi:: サポートを提供する商用プロバイダーです。オープンソースライブラリより手厚い対応を受けられます。ただし、Meta に認められていないアクセスであるため、利用停止を取り消すことはできず、不服申し立てもできません。 - EasyCoexistence:: Meta 自身のインフラ上で接続し、継続的に監視します。接続が切れた場合は Meta 独自の切断理由を確認できるため、14 日間の非アクティブ状態と実際の削除を区別できます。顧客が気づく前にお知らせします。 ### 実際の料金 非公式ルートは無料に見えますが、比較の焦点はライセンス料金だけではありません。 - Whapi:: 月額料金がかかるため、オープンソースのルートほど安価ではありません。利便性に料金を払いながら、無料ツールと同じリスクを抱えることになります。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 からで、ホスティング、監視、MCP コネクターを含みます。サーバーの運用、セッションの再リンク、プロトコル変更時の再構築は不要です。 ### それぞれが実際にできること ここが正直な部分であり、非公式プロジェクトが存在する理由でもあります。 - Whapi:: インフラを運用せず、整った REST API でメッセージの送受信、メディア、グループ、個人チャットを扱えます。機能の広さでは公式 API を上回ります。 - EasyCoexistence:: Cloud API が許可するすべての機能を利用できます。メッセージ、テンプレート、メディア、インタラクティブメッセージの送受信に対応し、Webhook は Meta から配信されます。グループチャットは API の対象外で、自由形式の返信には 24 時間のウィンドウが必要です。これは Meta のルールであり、すべての公式プロバイダーに適用されます。 ### どちらを選ぶべきか どちらにも選ぶ理由があり、番号の価値によって判断が決まります。 - 失っても困らない番号で趣味のプロジェクトを行う場合。非公式ルートは無料で多機能です。 - 企業が顧客対応に使う番号の場合。利用停止になると業務用回線が止まるため、公式ルートを選んでください。 - 顧客の番号を使うあらゆる用途。負うべきリスクではないため、公式を選んでください。 - WhatsApp Business アプリをスマートフォンで使い続ける必要がある場合。Coexistence を選んでください。これが私たちの提供する方法です。 - 企業の番号で非公式ブリッジを試すこと。利用停止は予告も不服申し立てもなく発生します。 - 何年も稼働している実績を安全性と考えること。取り締まりは継続的ではなく、周期的に行われます。 - 利用停止の影響が API だけに及ぶと思うこと。WhatsApp Business プロフィールも同時に失われます。 **Whapi は実際に動作しますか？** はい。そのため人気があります。問題は動作するかどうかではなく、WhatsApp に検知されたとき番号がどうなるかです。 **この方法で番号が利用停止になることはありますか？** はい。非公式アクセスは WhatsApp のビジネス利用規約に違反し、取り締まりの予告も不服申し立てもありません。 **EasyCoexistence を使うと WhatsApp Business アプリは停止しますか？** いいえ。それが Coexistence の目的です。スマートフォン上のアプリを使い続けながら、同じ番号で Cloud API を実行できます。 **有料なら Meta に承認されていますか？** いいえ。第三者に料金を支払っても、アクセスが認められるわけではありません。Meta がその番号用の認証情報を発行することが承認の条件であり、それを行うのが Coexistence です。 --- ## WhatsApp Coexistence対応サービスのおすすめ https://easycoexistence.com/ja/compare/best-whatsapp-coexistence-providers 短い一覧です。CoexistenceはWhatsApp API業界より新しく、まだ対応していないサービスが多いためです。対応しているサービスと料金、対象となる企業の種類を紹介します。 ### 1. EasyCoexistence、接続だけを求める企業や代理店向け 自社サービスを最初に挙げていますが、残りも読み、出典を確認してください。対象は明確です。この一覧中で公開開始料金が最安で、番号単位の料金体系に座席数やプラン階層はありません。メッセージイベントは別の受信箱ではなく、Metaから自社システムへ直接配信されます。Meta自身の切断理由を読み取る継続監視と、AIアシスタントで全体を操作できる MCP コネクターも備えています。 - 接続済みの番号 1 件あたり月額 US$ 9 から、番号を追加するほど US$ 1 まで。 - 座席数、契約期間、初期費用はなく、3 日間無料です。 - 上乗せ手数料はなく、会話料金はMetaが顧客に直接請求します。 - OAuth経由で Claude、ChatGPT、Cursor、Claude Codeから使える16個の MCP ツール。 ### 2. YCloud、周辺機能を備えたプラットフォームを求めるチーム向け 位置付けが最も近い選択肢です。Coexistenceへの対応を明示し、WhatsAppメッセージへの上乗せ手数料ゼロを約束している点は、特に重要です。違いは請求方法です。有料プランは月額 US$ 39 からで、1つの番号を数える前に、ユーザー座席、チャネル、AIクレジットで構成されます。当社は座席数やクレジットなしで、接続済みの番号 1 件あたり US$ 9 から始まります。そのため、番号が 1〜3 件の企業なら数分の一で済み、40 件の代理店では料金が US$ 5 まで下がります。 ### 3. SleekFlow、共有受信箱を中心に業務を行うチーム向け Coexistenceをソリューションの一つとして掲載しており、キャンペーンや自動化機能を備えたオムニチャネル受信箱を提供しています。料金はユーザー座席単位で、最低座席数があり、追加のWhatsApp番号には別料金がかかります。全員が一つの場所で作業したい営業やサポートチームには向いています。一方、複数拠点の企業には不向きです。座席数と番号の追加料金がどちらも負担になります。 ### 4. 8x8、すでに通信サービスを導入している大企業向け Coexistenceの説明はどのサービスより明確で、当社を含め、どこを選ぶ場合でも読む価値があります。コンタクトセンターや音声通信とともに、アカウントチームや個別の商談を通じて販売されるエンタープライズ向け CPaaS です。通信費をすでに集約している企業には適しています。ただし、1つの番号と Webhook のためだけなら、大がかりな導入です。 ### 5. Dualhook、直接利用できる専門サービス 当社と同じ構成です。Metaから直接 Webhook にルーティングするCoexistenceで、メッセージを保存せず、公開料金を設定しています。公開料金は番号 1 件あたり US$ 12 で、当社の US$ 9 を上回ります。13 日間の時点で時間が進んでいると警告しますが、Meta自身の切断理由を読み取る仕組みではありません。また、MCP コネクターについての説明もありません。 ### 契約前にどのサービスにも確認すべきこと この一覧のサービスを分ける4つの質問です。営業ページだけでは答えが分かりません。 - 番号は自社の Meta Business Portfolio に残り、料金はMetaから直接請求されますか。 - メッセージごとに追加料金がかかりますか。Metaの料金と分けて明細化されますか。 - 再接続後に Webhook の上書きを再適用しますか。それとも配信が気づかれないまま停止しますか。 - 14 日間の非アクティブ規則にどう対応しますか。Metaの切断理由を読み取りますか。 - 機能数だけで選ぶこと。CoexistenceはMetaの仕組みなので、その下のプラットフォームはどこでも同じです。 - WhatsAppに対応しているからCoexistenceにも対応していると思い込むこと。まだ対応していないサービスが大半です。 - 自社の利用形態に合わせて両方を数えず、座席単位の料金と番号単位の料金を比較すること。 **なぜ自社サービスを最初に挙げているのですか。** 公開開始料金が最安で、座席数がなく、上乗せ手数料ゼロで監視も含まれるためです。すべての数値に出典があるので、確認してください。 **Coexistenceに対応しているサービスはどこですか。** WhatsApp全般に対応するサービスより、はるかに少数です。この一覧のサービスは自社サイトで対応を明記していますが、WhatsApp API業界の大半はまだ提供していません。 **サービスによってCoexistenceでできることは変わりますか。** 変わりません。この機能はMetaのものなので、制限はどこでも同じです。無効になる4つの機能、14 日間の規則、グループチャット非対応も共通です。 **最も安い選択肢はどれですか。** 公開開始料金では当社です。番号が増えるほど、当社は番号単位の料金が下がる一方、座席単位やプラン単位の料金は下がらないため、差が広がります。 --- ## 最適な WhatsApp Cloud API プロバイダー https://easycoexistence.com/ja/compare/best-whatsapp-cloud-api-providers ここで紹介するプロバイダーは、すべて同じ Cloud API に接続します。Meta の API は 1 つしかないためです。違いは料金体系で、メッセージ単位、ユーザー単位、接続済みの番号単位の 3 つに分かれます。 ### 3 つの料金体系、本当の選択肢はどれか 基盤となる API は同じなので、機能一覧だけでは違いが見えません。一方、請求額の計算方法は明確に異なり、企業の成長に伴う料金を決めます。 - メッセージ単位：すべてのメッセージに料金がかかるため、事業の成功と同じ割合でコストが増えます。 - ユーザー単位：ユーザーごとに料金がかかるため、チームが大きくなるほどコストが増え、ログインしなくても支払います。 - 番号単位：接続ごとに料金がかかり、番号を接続した後は増えません。 ### メッセージ単位で課金するプロバイダー CPaaS のグループです。Twilio は Meta の料金に加えて、受信と送信それぞれ 1 メッセージあたり US$ 0.005 と公開しています。Gupshup は標準料金として 1 メッセージあたり US$ 0.001 を公開しています。Bird は Meta の料金を含む混合料金を提示しているため、上乗せはありますが、Meta 公開の料金との比較はできません。Infobip は販売担当者を通じて送信先の国ごとの料金を提示します。4 社とも機能的なプラットフォームですが、いずれもプラットフォーム料金がメッセージ量に応じて変わります。 ### ユーザー単位で課金するプロバイダー 受信トレイのグループです。SleekFlow、Wati、Respond.io は、キャンペーンや自動化機能を備えた共有受信トレイを、プラン階層ごとのユーザー単位で販売しています。複数のサービスでは、WhatsApp 番号ごとの追加料金もかかります。チーム全員が 1 日中 1 つの製品で作業したい場合に適した選択です。すでに CRM がある場合は、誰も開かなくても 2 つ目の受信トレイに料金を払うため、適していません。 ### 番号単位で課金するプロバイダー インフラのグループで、最も小規模です。EasyCoexistence は接続済みの番号 1 件あたり月額 US$ 9 から、番号を追加するにつれて US$ 1 まで下がります。メッセージ単位の料金もユーザー単位の料金もありません。Dualhook も、番号単位の料金を公開している専門サービスです。すでにシステムを持ち、そこに WhatsApp を接続したい企業に適しています。多数の顧客番号を管理する代理店では、番号単位の料金低下が積み重なるため、特に適しています。 ### 料金体系が交差する地点 思い込みで決めずに計算する価値があります。計算は簡単です。 - 1 メッセージあたり US$ 0.005 の場合、番号単位の US$ 9 は月約 1,800 メッセージを超えると安くなります。 - 1 メッセージあたり US$ 0.001 の場合、分岐点は月約 9,000 メッセージです。 - ユーザー単位の料金体系は量ではなく人数で分岐するため、ユーザー数と番号数を比較してください。 - Meta 独自の会話料金はどの料金体系でも同じで、ここで比較している対象ではありません。 ### どのプロバイダーも変えられないこと 機能比較で誤解する前に、知っておくべき点です。 - Cloud API は Meta のものなので、信頼性と機能はプロバイダーではなくプラットフォームのものです。 - テンプレートの承認は Meta が決定するため、プロバイダーが速めることはできません。 - 品質評価とメッセージング階層は、受信者の行動をもとに Meta が設定します。 - 対応している場合の Coexistence は Meta の機能なので、上限はどのプロバイダーでも同じです。 - 表面的な機能だけを比較する。基盤となる API は、どのプロバイダーでも Meta の同じ API です。 - 分岐点となるメッセージ量を無視する。わずかな差額でも、1 年分に掛け合わせると変わります。 - メッセージ単位の包括料金に上乗せがないと思い込む。料金の内訳に表示されていないだけです。 **あるプロバイダーの Cloud API は、別のプロバイダーより速いですか？** いいえ。どの場合も Meta の API です。プロバイダーが変えられるのは、その前段にある仕組みと料金だけです。 **最も安い料金体系はどれですか？** 一定量を超える場合は番号単位です。Twilio の公開料金では月約 1,800 メッセージ、Gupshup では月約 9,000 メッセージが分岐点です。 **プロバイダーは必ず必要ですか？** すでに WhatsApp Business アプリを使っている番号で Cloud API に接続するには必要です。Coexistence のオンボーディングには Meta Tech Provider が必要です。 **メッセージ料金は誰から請求されますか？** プロバイダーが再販しない場合は Meta です。当社では Meta が直接請求し、当社が上乗せすることはありません。 --- ## 最適な WhatsApp MCP サーバー https://easycoexistence.com/ja/compare/best-whatsapp-mcp-servers WhatsApp MCP サーバーを検索すると、多くは WhatsApp にリンク済みデバイスとしてログインするオープンソースプロジェクトです。動作しますが、番号が危険にさらされます。重要なのは機能ではなく、サーバーが Meta の公式 API と通信するかどうかです。 ### 重要な分岐点 WhatsApp MCP サーバーは、ツールの種類ではなく、1 本の境界線のどちら側にあるかで分かれます。 - 公式: サーバーが Meta 発行の認証情報で Meta の Cloud API を呼び出します。認可された方法で、番号は安全です。 - 非公式: Web クライアントと同じように、リンク済みデバイスとしてログインするライブラリをサーバーが操作します。 - 非公式の方法は Meta の承認が不要なため、オープンソースプロジェクトで広く使われています。 - これは WhatsApp の利用規約にも反しており、番号は警告も異議申し立てもなく凍結されます。 ### 見つかるオープンソースプロジェクト GitHub にある WhatsApp MCP サーバーの多くは、リンク済みデバイスのプロトコルをリバースエンジニアリングする Baileys、WPPConnect、Venom などのライブラリを基盤にしています。実際に巧妙で無料であり、公式 API では公開されない個人チャットやグループへのアクセスをアシスタントに与えます。代償はアカウントです。この方法で凍結された番号では WhatsApp Business プロフィールも失われ、申し立てるサポート窓口もありません。失ってもよい個人番号なら、この交換条件に意味がある場合もあります。企業が顧客対応に使う番号では、選ぶべきではありません。 ### 実際に運用する場合に必要なこと リスク以外にも実務上の違いがあり、2 日目にはその問題に直面します。 - 通常はノートパソコン上でローカルサーバープロセスを実行し、アシスタントが動作する間は起動し続ける必要があります。 - デバイスをリンクするために QR コードをスキャンし、セッションが切れるたびに繰り返します。 - 認証情報をローカル設定ファイルに保存するため、API トークンもそこに置かれます。 - ノートパソコンがスリープすると、アシスタントと番号の接続はなくなります。 ### 公式ルートの EasyCoexistence OAuth 経由のリモート MCP サーバーなので、インストールも設定ファイルへのトークン保存も不要です。16 個のツールで、番号の一覧表示、番号の接続状態の確認、API 認証情報の読み取り、メッセージの送信、メッセージテンプレートの一覧表示・作成・送信、テンプレートのステータス確認、Webhook のシステムへの設定、ドキュメント検索、新しい接続の開始といった、実際に求められる操作を行えます。さらに 5 個のツールで、Partner API の設定状況の確認、API キーの発行、イベント URL の設定、ホスト型の接続リンクの作成を行えます。ホスト型のためノートパソコンを開いていなくても動作します。番号は Coexistence を通じて Meta の公式 Cloud API 上にあるため、WhatsApp Business アプリも使い続けられ、危険にさらされません。 ### 公式ルートでできないこと 非公式プロジェクトが存在する理由であり、選ぶ前に知っておくべき点なので、明確に説明します。 - グループチャットは、すべての公式プロバイダーで Cloud API の対象外です。 - 個人用 WhatsApp アカウントの個人間の会話にはアクセスできません。 - 自由形式の返信は 24 時間のサービスウィンドウ内でのみ可能です。時間外は承認済みのメッセージテンプレートで会話を開始します。 - これらは当社ではなく Meta のルールであり、公式プロバイダーが解除することはできません。 - ツール数だけで MCP サーバーを判断すること。重要なのは Meta の API と通信するか、電話を装うかです。 - 企業の番号で非公式ブリッジを試すこと。凍結は警告も異議申し立てもなく発生します。 - ローカルサーバーなら非公開だと思うこと。ノートパソコンの設定ファイルにトークンを置く構成は、より脆弱です。 **オープンソースの WhatsApp MCP サーバーは安全ですか？** 動作しますが、リンク済みデバイスとしてログインするため、WhatsApp の利用規約に反します。番号は警告なしに凍結されます。 **公式 MCP サーバーでグループチャットを読めますか？** いいえ。グループチャットは、当社を含むすべての公式プロバイダーで Meta の Cloud API の対象外です。 **何かインストールする必要がありますか？** いいえ。当社のサーバーは OAuth 経由のリモートサーバーなので、エンドポイントを追加してサインインするだけです。端末上では何も動きません。 **どのアシスタントで利用できますか？** MCP クライアントであれば利用できます。当社のドキュメントでは Claude、ChatGPT、Cursor、Claude Code を案内しています。 --- ## EasyCoexistence と Twilio の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-twilio Twilioは複数チャネルでWhatsAppを再販する汎用通信プラットフォームで、Metaの料金に公開されたメッセージ従量課金を上乗せします。EasyCoexistenceはWhatsApp Business アプリの番号をCoexistence経由で接続することに特化し、番号ごとの固定料金を請求します。 ### それぞれ何に使うものか 製品が解決する課題は異なります。まず、この点を明確にすることが大切です。 - Twilio:: SMS、音声、メール、WhatsAppを扱い、複数チャネルのメッセージングを組み立てるエンジニアリングチーム向けの通信プラットフォームです。WhatsAppは多数あるチャネルの 1 つで、他と同じくメッセージ単位で料金がかかります。 - EasyCoexistence:: Coexistenceに特化した製品です。スマートフォンのWhatsApp Business アプリはそのまま動作し、同じ番号でCloud APIが稼働します。メッセージイベントはお客様のエンドポイントに届き、接続状態も監視します。1 つの役割を、最後まで担います。 ### 成長すると料金はどう変わるか 差が積み重なる部分で、意見ではなく計算で決まります。 - Twilio:: Metaの料金とは別に、受信と送信の各メッセージに US$ 0.005 かかります。すべての会話に応じて料金が増えるため、プラットフォーム料金はビジネスの成果に連動します。 - EasyCoexistence:: 接続済み番号ごとの固定料金です。1 か月に 10,000 件送っても 10 件でも料金は同じです。成果が出るほどメッセージ 1 件あたりの料金は下がり、上がることはありません。利用量が増えると番号ごとの料金も下がります。 ### WhatsAppアカウントを管理するのは誰か 番号とMetaとの関係をどこに置くかで、どちらからも離れやすいかが決まります。 - Twilio:: 番号はTwilioの送信元を通じて登録され、メッセージングの関係はTwilioのインフラを経由します。請求関係もそこにあります。 - EasyCoexistence:: 番号はお客様自身のMeta Business Portfolioにある、お客様自身のWhatsApp Business Accountに残ります。会話の料金はMetaからお客様に直接請求されます。EasyCoexistenceは接続を担うTech Providerであり、削除しても番号は移りません。 ### メッセージはどこへ届くか どちらもお客様が管理するサーバーに受信メッセージを届けます。異なるのは経路と、その上に何があるかです。 - Twilio:: 受信メッセージはTwilioを経由してお客様のWebhookに届きます。Twilioは通過する各メッセージを処理し、請求します。 - EasyCoexistence:: WhatsApp Business AccountのMeta独自のoverride_callback_uriを設定するため、メッセージイベントはMetaからお客様のエンドポイントへ直接届きます。EasyCoexistenceを通過せず、保存もされないため、経路上で計測されるものはありません。 ### AIアシスタントから利用するには 新しい利用方法に関する問いであり、汎用プラットフォームが答える理由はあまりありません。 - Twilio:: 主要言語向け SDK を備えた完全な REST APIです。公開された US$ 0.005 のメッセージ従量課金があるため、作成した連携は送受信のたびに請求されます。 - EasyCoexistence:: 基盤は同じAPIで、OAuth対応の 16 個のツールを備えたリモートMCPコネクターが加わります。Claude、ChatGPT、Cursor、Claude Codeから、クライアントを作成せずに番号の一覧表示、接続状態の確認、メッセージ送信、Webhook送信先の設定ができます。 - 見出しの料金だけを比較すること。メッセージ単位の料金と番号単位の料金は、まず損益分岐点となる利用量を計算すべきです。 - 大規模なプラットフォームならWhatsApp接続も優れていると考えること。どちらも基盤はMeta独自のCloud APIです。 - Metaが誰に請求するかを見落とすこと。Metaの請求書との間に入るプロバイダーは、料金を上乗せできるプロバイダーです。 **Twilioは少量利用なら安いですか？** 月 2,000 件程度まではメッセージ従量課金は小額です。それを超えると番号単位の固定料金が有利になり、利用量が増えるほど差が広がります。 **TwilioはCoexistenceに対応していますか？** TwilioのWhatsApp料金ページでは説明されていません。Coexistenceに特化しているため、WhatsApp Business アプリは同じ番号で動作します。 **APIは異なりますか？** いいえ。どちらも基盤はMeta独自のCloud APIです。異なるのは経路上に入る相手、料金、そしてMetaが請求する相手です。 **後から番号を移せますか？** はい。番号はお客様自身のBusiness Portfolioに残るため、EasyCoexistenceを削除しても元の場所にそのまま残ります。 --- ## EasyCoexistence と Gupshup の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-gupshup Gupshup は、Meta の会話料金に加えてメッセージ単位の料金を公開している会話型メッセージングプラットフォームです。EasyCoexistence は接続済みの番号ごとに月額固定料金を課金し、メッセージ料金には何も加えません。利用量が増えるほど、この違いが積み重なります。 ### 請求額の仕組み 10 分の 1 セントは小さく見えますが、規模が大きくなると会話全体のコストになります。 - Gupshup:: Meta の料金に加えて、メッセージ 1 件あたり US$ 0.001 の標準料金がかかります。テンプレートメッセージとセッションメッセージの両方が対象です。月 100,000 件なら、Meta の料金を除いてプラットフォーム料金だけで US$ 100 です。 - EasyCoexistence:: メッセージごとの料金はありません。料金はトラフィックではなく番号に連動するため、月 100,000 件のメッセージでも 10 件の場合と同じ費用です。番号の利用量が多いほど、会話ごとの料金に占める当社の費用は小さくなります。 ### 製品の中心にあるもの どちらも WhatsApp に接続しますが、異なる業務を中心に設計されています。 - Gupshup:: ボット構築、キャンペーン機能、幅広いチャネルに対応する会話型プラットフォームです。大規模なアウトバウンド施策を行う企業を対象にしています。 - EasyCoexistence:: Coexistence のインフラです。WhatsApp Business アプリはスマートフォンで動き続け、Cloud API は同じ番号で稼働し、メッセージイベントは既存のシステムや AI エージェントに届きます。チームの移行は必要ありません。 ### 会話データの保存先 自社の業務のどれだけが、他社製品の中で動くのかを左右する問いです。 - Gupshup:: メッセージはプラットフォームを通過します。それにより、ボットビルダー、キャンペーン機能、分析機能が利用できます。これらを求めるなら、合理的なトレードオフです。 - EasyCoexistence:: メッセージイベントは Meta から Meta 独自の Webhook オーバーライドを通じて、直接お客様のエンドポイントに届きます。当社は会話内容を一切見ないため、離脱時に取り出すべきデータも、経路上で計測するものもありません。 ### アプリが稼働中の番号を接続する Coexistence が存在する理由そのものです。 - Gupshup:: 公開されている料金ページでは、Coexistence について説明されていません。対応していない証拠ではないため、直接確認するのが適切です。 - EasyCoexistence:: これが製品のすべてです。WhatsApp Business アプリがすでに稼働している番号を Meta 独自の Embedded Signup で接続し、アプリを使い続けながら、同じ番号で数分以内に Cloud API を利用できます。 - US$ 0.001 を無視できる金額だと考えること。判断する前に、実際の利用量を 1 年分掛けてください。 - 使わないキャンペーン機能に料金を払うこと。プラットフォーム料金は、使うかどうかにかかわらず製品全体にかかります。 - どのプロバイダーでも Coexistence に対応していると思い込むこと。選ぶ相手に、必ず具体的に確認してください。 **メッセージ単位の料金は実際にいくらかかりますか？** 月 100,000 件のメッセージでは、Gupshup の公開料金 US$ 0.001 により、プラットフォーム料金は US$ 100 です。当社の 1 番号あたりの料金は、利用量にかかわらず US$ 9 です。 **Gupshup は Coexistence に対応していますか？** 同社の料金ページには記載がありません。Coexistence は当社が提供する製品そのものです。 **御社を利用するとキャンペーン機能を失いますか？** 当社はキャンペーンツールではなく、そのような料金体系でもありません。メッセージはお客様のシステムに届くため、キャンペーンは既存の環境で実行できます。 **Meta に料金を支払うのは誰ですか？** お客様が自身の WhatsApp Business アカウントから、Meta に直接支払います。当社が Meta の料金に上乗せすることはありません。 --- ## EasyCoexistence と Infobip の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-infobip Infobipは、WhatsAppの料金を国別に見積もり、営業を通じて契約する企業向け通信プラットフォームです。EasyCoexistenceは料金を公開し、3日間の無料トライアルを提供します。対話なしで番号を接続できるため、異なる購入者向けの別の製品です。 ### 各製品の対象ユーザー どちらかが劣る製品ではありません。対象となる購入者が異なり、それがほかのほぼすべてを決めます。 - Infobip:: オムニチャネルルーティング、コンタクトセンター機能、グローバルな通信事業者との関係を備えた企業向け CPaaS です。営業担当を通じて、調達プロセスと利用量の確約がある組織に販売されます。 - EasyCoexistence:: すでに WhatsApp Business 番号を持ち、今日中に Cloud API で使いたい中小企業または代理店向けです。登録して接続すれば完了です。交渉することがないため、話す相手もいません。 ### 契約前に確認できること 最も実用的で、最初に違いを感じる点です。 - Infobip:: 料金は接続先の国ごとに見積もられ、営業を通じて調整されます。これは企業向け CPaaS では一般的で、年間利用量を交渉する購入者に適しています。 - EasyCoexistence:: 料金ページに全料金表を掲載し、通貨と利用量別の料金帯を表示しています。アカウントを作成する前に料金を計算でき、最初の 3 日間は無料です。 ### 判断から番号の利用開始まで 番号 1 つで現実の課題を抱える企業にとって、重要なのはこの比較です。 - Infobip:: 専任サポートと設定支援を含む企業向けの導入です。大規模な導入には実際に必要な支援です。 - EasyCoexistence:: 数分です。Meta独自の Embedded Signup でポートフォリオ、アカウント、番号を選択できます。WhatsApp Business アプリはその間も使い続けられ、監視もすぐに始まります。 ### 接続が切れたときの対応 Coexistence の接続はいつか不調になります。違うのは、誰がそれに気づくかです。 - Infobip:: 企業向けのサポート窓口と営業担当があります。契約と担当者がいる場合に適したモデルです。 - EasyCoexistence:: 接続を継続的に監視し、Meta独自の切断理由を読み取ります。そのため、14 日間の非アクティブで番号が切断されたケースと、顧客が実際に離れたケースを区別できます。アラートは顧客が気づく前に届きます。 - 企業向け CPaaS と番号単位のツールを機能だけで比較すること。答える課題が異なります。 - 番号 1 つのために調達サイクルを始めること。ツールの年間料金より時間のコストが高くなります。 - 少量利用なら見積もりが公開料金を下回ると考えること。そうなることはほとんどありません。 **Infobipはなぜ一律料金を公開していないのですか？** 接続先の国ごとに見積もる料金体系で、利用量を交渉する企業の購入者に適しています。当社は、購入者が今日決められるよう料金を公開しています。 **大企業にはInfobipのほうが適していますか？** Infobipは、グローバルな通信事業者への対応と営業担当を必要とする購入者向けに作られています。自社の番号を接続する企業には、当社のほうが速く、安価な方法です。 **開始時に誰かと話す必要はありますか？** ありません。最初に接続する番号は 3 日間無料で、Meta独自の Embedded Signup を通じて接続できます。 **メッセージ料金を請求するのは誰ですか？** Metaが、お客様自身の WhatsApp Business アカウントに直接請求します。当社が請求を介することはありません。 --- ## EasyCoexistence と YCloud の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-ycloud YCloudはCoexistenceに対応し、当社と同じくMetaのメッセージ料金に上乗せしません。違いは購入するものです。YCloudの有料プランは席数、チャネル、AIクレジットを含むプラットフォームのサブスクリプションで、当社は接続済みの番号ごとの料金でインフラを提供します。 ### 両社が正しく提供していること 比較を実際の違いに絞るため、まず明確にしておきます。 - YCloud:: Coexistenceに対応し、公開している料金ページでWhatsAppメッセージへの上乗せがゼロだと明記しています。プロバイダー選びで最も重要な2点について、両社とも適切な方針です。 - EasyCoexistence:: 同じ2つの約束です。Meta独自のフローによるCoexistenceと、Metaのメッセージ料金に何も加えないことです。違いはその周辺すべてにあります。 ### サブスクリプションで実際に買うもの ここが本当の分岐点で、どちらが安いかを決めます。 - YCloud:: プラットフォームです。有料プランは月額 US$ 39 からで、ユーザーの席数、チャネル、AIクレジットによって分かれます。チームで相手の製品内で作業したい場合に適した形です。 - EasyCoexistence:: インフラです。接続済みの番号 1 件あたり US$ 9 からで、数える席数も、段階制のチャネルも、使い切るクレジットもありません。1つの番号を使う企業は1つ分を支払い、40個の番号を使う代理店は番号単価が下がります。 ### 会話が最終的に届く場所 両社とも同じ Cloud API に接続します。その後メッセージをどう扱うかが設計上の判断です。 - YCloud:: 相手のプラットフォームです。受信トレイ、キャンペーン、AIクレジットがそこにあり、番号料金を数える前から月額 US$ 39 かかります。メッセージが届く場所でチームが作業します。 - EasyCoexistence:: お客様のシステムです。Meta独自の Webhook オーバーライドを設定し、メッセージイベントをMetaから直接エンドポイントへ、または MCP 経由でAIエージェントへ送ります。移行先も移行元もなく、チームが確認する2つ目の受信トレイもありません。 ### 代理店が成長すると支払う料金 2つのモデルの差が最も大きくなるケースです。 - YCloud:: 席数を含むプランの段階制です。人数やチャネルが増えるたびに、アップグレードを判断することになります。 - EasyCoexistence:: 番号を追加するほど下がる番号単価です。US$ 9 から US$ 1 まで下がります。アップグレード先がないため、アップグレードの相談もありません。40個目の番号も1個目と同じことができ、料金はより安くなります。 ### AIアシスタントから接続先にアクセスする どちらのプラットフォームのプランにも書かれていない、いま増えている問いへの答えです。 - YCloud:: AIクレジットは相手のプラン構成に含まれており、製品内に組み込まれたAI機能を示しています。 - EasyCoexistence:: OAuth 経由で16個のツールを提供するリモート MCP コネクタです。Claude、ChatGPT、Cursor、Claude Codeから番号の一覧表示、接続状態の確認、メッセージやテンプレートの送信、Webhook送信先の設定を直接実行できます。クライアントの開発もクレジットの購入も不要です。 - 先に席数と番号数を数えず、席単位のプランと番号単位の料金を比較する。 - チームにすでに受信トレイがあるのに、受信トレイの料金を支払う。使わなくてもプラットフォーム料金に含まれます。 - AI機能と MCP コネクタを同じものだと考える。一方は相手の製品内で動き、もう一方はお客様の製品内で動きます。 **本当に両社とも上乗せゼロですか？** はい。YCloudの料金ページにも当社にも、上乗せゼロと記載されています。比較すべきなのはメッセージ料金ではなく、プラットフォーム料金です。 **どちらが安いですか？** 番号が1〜4個なら当社です。4個で月額 US$ 36、YCloudの最安プランは US$ 39 です。5個以上では、当社の合計額と、必要な席数やチャネル数に合うプランの段階を比べてください。当社の番号単価は番号を追加するほど US$ 1 まで下がります。 **御社を使うと受信トレイを失いますか？** 受信トレイへ移行する必要はありません。メッセージは、チームがすでに使っているお客様のシステムまたはAIエージェントに届きます。 **YCloudには MCP コネクタがありますか？** YCloudの料金ページが説明しているのは、MCPサーバーではなく、プラットフォーム内のAIクレジットです。当社はOAuth経由の16個のツールで、あらゆる MCP クライアントから利用できます。 --- ## EasyCoexistence と SleekFlow の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-sleekflow SleekFlowはユーザー席単位で販売するオムニチャネルメッセージング基盤で、最低席数があり、WhatsApp番号ごとに追加料金がかかります。EasyCoexistenceは接続済み番号ごとに課金し、席という概念がありません。そのため、料金はチームの規模ではなく、保有する番号数に応じて決まります。 ### 実際に料金を払う対象 2つの料金モデルは異なる問いに答えます。そのうち1つは組織図を前提にします。 - SleekFlow:: プランごとにユーザー席単位で料金が決まる共有受信トレイ兼キャンペーン基盤です。チームが日中そこで仕事をするなら、理にかなっています。 - EasyCoexistence:: 接続です。単位は人ではなく接続済み番号なので、同僚を追加しても費用はかかりません。チームが増減しても請求額は変わりません。 ### チームが仕事をする場所 料金モデルの根底にある判断で、後から変更しにくい点です。 - SleekFlow:: SleekFlowの中です。それがこの製品です。受信トレイ、オートメーション、キャンペーンを1か所にまとめており、1か所に集約したいチームには実際に役立ちます。 - EasyCoexistence:: 今使っている場所です。メッセージイベントは Meta から CRM、ヘルプデスク、社内ツール、AIエージェントへ、Meta独自の Webhook オーバーライドを通じて直接届きます。新しい受信トレイを覚える必要も、移行作業もありません。 ### 2つ目、3つ目の番号を追加する場合 複数拠点を持つ企業ではよくあることで、2つのモデルの差が大きく表れます。 - SleekFlow:: 追加の WhatsApp 番号は、席数ベースのプランに加算される追加料金です。そのため、2つ目の番号はサブスクリプションに加わる別の判断になります。 - EasyCoexistence:: 2つ目の番号は、公開料金で追加できる2つ目の番号です。追加するほど料金は下がります。1つのアカウントに20番号あっても、プラン変更も相談も必要ありません。 ### 支払いをやめるとどうなるか 会話を保持する製品なら、確認しておく価値があります。 - SleekFlow:: 受信トレイ、履歴、オートメーションはプラットフォーム内にあります。それが機能する理由である一方、離れる際には移行が必要になります。 - EasyCoexistence:: 移行すべきデータは当社内にありません。メッセージは届いた時点であなたのシステムに配信され、番号はあなた自身の Meta Business Portfolio にあるため、当社を削除しても番号はそのまま残ります。 - 席数料金と番号単位料金を、両方の数を数えずに比較すること。3席と1番号では、1席と3番号の場合と請求額が大きく異なります。 - チームが開かない受信トレイに料金を払うこと。使っていなくても席数料金は発生します。 - 複数拠点の企業で、番号ごとの追加料金を見落とすこと。 **どちらが安いですか？** 受信トレイが特に必要でない限り、当社のほうが安価です。相手の公開料金は最低席数のある席単位で、WhatsApp番号ごとに月額追加料金がかかります。当社は接続済み番号1件あたり US$ 9 から、番号が増えるにつれて US$ 1 まで下がり、席数はありません。 **共有受信トレイは使えますか？** いいえ。その料金もかかりません。メッセージは、チームがすでに使っているあなた自身のシステムに届きます。 **複数拠点の場合はどうなりますか？** 各番号に公開料金が適用され、追加するほど料金は下がります。プラン変更も、交渉が必要な追加料金もありません。 **データは囲い込まれますか？** 当社では囲い込まれません。メッセージは Meta からあなたのエンドポイントへ直接届き、番号はあなた自身の Business Portfolio に残ります。 --- ## EasyCoexistence と Bird https://easycoexistence.com/ja/compare/easycoexistence-vs-bird Birdは配信メッセージごとに WhatsApp 料金を設定し、Meta の料金を含めています。EasyCoexistenceは接続済みの番号ごとに定額を請求し、メッセージ請求には表示されません。Meta の料金は明確に分離されます。 ### 込みの料金で見えなくなるもの 不誠実ということではなく、相手のページにも明記されています。ただし、確認できる内容は変わります。 - Bird:: 配信メッセージごとの 1 つの料金に、Meta の取り分が含まれます。Bird のページでは、処理中に送信料金を請求し、配信レシートから Meta の取り分を記録すると説明しています。 - EasyCoexistence:: 混ざることのない 2 つの請求書です。Meta はお客様の WhatsApp Business Account での会話を顧客に請求し、当社は接続料金を請求します。統合されていないため、それぞれを元の請求元と照合できます。 ### Meta が料金を変更するとどうなりますか Meta は会話料金を定期的に改定しており、2 つの料金モデルではその影響の現れ方が異なります。 - Bird:: 基になる料金が変わると、込みの料金も改定が必要になります。お客様に提示される金額自体が変わるということです。 - EasyCoexistence:: 当社側の料金は変わりません。Meta の変更は、Meta が適用する日に、Meta 独自の料金で顧客の Meta 請求書に反映されます。当社の料金は接続に対するもので、メッセージ料金とは関係ありません。 ### 各製品が中心に据えるもの どちらも WhatsApp メッセージを送信しますが、同じ用途を競う製品ではありません。 - Bird:: メール、SMS、WhatsApp にまたがるマーケティングおよび顧客エンゲージメントのプラットフォームです。複数チャネルで大規模なキャンペーンを運用するチーム向けに構築されています。 - EasyCoexistence:: すでに WhatsApp Business アプリを使っている番号のための Coexistence インフラです。アプリは動作し続け、Cloud API が並行して動作し、イベントはお客様のシステムに届きます。1 つの番号に 1 つの役割を、適切に実現します。 ### 会話の管理主体は誰か 両方の料金モデルの根底にある構造上の問いです。 - Bird:: メッセージはプラットフォームを通過する際に処理および請求されます。これにより、キャンペーン機能や分析機能が可能になります。 - EasyCoexistence:: メッセージイベントは Meta から Meta 独自のオーバーライドを通じて、お客様のエンドポイントへ直接届きます。当社を経由せず、当社も保存しないため、当社がメッセージごとに請求する料金はありません。 - 込みの料金を Meta の公開料金と同じものとして比較すること。一方の料金にはもう一方が含まれています。 - 込みの料金なら上乗せがないと考えること。上乗せ分が項目別に表示されていないだけです。 - 1 つの番号と 1 つの Webhook のために、キャンペーンプラットフォームを選ぶこと。 **Birdの料金設定は不誠実ですか？** いいえ。Meta の料金を含むことを明確に示しています。ポイントは、統合された料金を Meta 独自の公開料金と照合できないことです。 **こちらを使う場合、メッセージ料金は誰が請求しますか？** Meta が、お客様自身の WhatsApp Business Account に対して直接請求します。当社が Meta の料金に上乗せしたり、再販売したりすることはありません。 **Meta が料金を引き上げた場合はどうなりますか？** Meta の料金で、お客様の Meta 請求書に反映されます。当社の料金はメッセージに連動していないため、影響を受けません。 **Birdは Coexistence に対応していますか？** Bird の WhatsApp 料金ページでは、その点に触れていません。Coexistence は当社が提供するすべてです。 --- ## EasyCoexistence と Zenvia の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-zenvia Zenviaは月額ソフトウェア料金に加え、チャネルパッケージと WhatsApp 有効化の初期設定料金を請求します。EasyCoexistenceは接続済み番号ごとの公開料金のみで、プラン、パッケージ、初期設定料金はありません。小規模企業にとって、料金体系が大きく異なります。 ### 請求額の構成 構造上の違いであり、合計額を決めるポイントです。 - Zenvia:: 月額ソフトウェアプランに、想定利用量に合わせたチャネルパッケージと、WhatsApp チャネルの有効化時に初期設定料金が加わります。マーケティング運用を担う企業に適した、3つの判断と3行の請求です。 - EasyCoexistence:: 1行だけです。接続する番号が増えるほど下がる、番号ごとの公開料金です。プランもパッケージもなく、開始時の支払いもありません。Metaの会話料金は Meta から顧客に別途、Meta独自の料金で請求されます。 ### それぞれの対象企業 どちらも本格的な製品ですが、対象とする企業が異なります。 - Zenvia:: マルチチャネルキャンペーン、ジャーニー、大規模なブラジル企業の顧客基盤を備えた顧客体験プラットフォームです。体系的なコミュニケーション施策を運用する企業向けに販売されています。 - EasyCoexistence:: スマートフォンで WhatsApp Business 番号をすでに使っていて、アプリを失わずに Cloud API でも使いたい企業向けです。アプリは動作し続け、APIは同じ番号で稼働し、メッセージは企業がすでに使っているシステムに届きます。 ### 利用量が増えるとどうなるか 2つの料金モデルは反対方向に動きます。 - Zenvia:: チャネルパッケージは利用量に合わせて設定されるため、利用量が増えると上位パッケージへの移行が必要になり、プランの段階も上がる可能性があります。 - EasyCoexistence:: 番号を追加するほど1番号あたりの料金が下がり、メッセージ量は計算に一切入りません。10万件のメッセージを送る番号も、利用の少ない番号と同じ料金です。 ### 番号が使えるようになるまでの時間 小規模企業にとって、これが判断のすべてになることもあります。 - Zenvia:: WhatsApp チャネルの有効化手順を含む、商用の導入プロセスです。大規模な導入で役立つサポートも受けられます。 - EasyCoexistence:: Metaの Embedded Signup を使って数分で完了し、最初の接続番号から 3 日間無料です。その間も WhatsApp Business アプリは使い続けられ、番号の接続直後から監視が始まります。 - プラン料金だけを比較すること。チャネルパッケージと初期設定料金も合計額に含まれます。 - 接続の問題を解決するためにキャンペーンプラットフォームを購入すること。 - Metaの会話料金がどこかに含まれていると思うこと。料金は顧客自身のアカウントで支払います。 **レアルで支払えますか？** はい。料金はレアルとドルで公開され、通貨は最初のサブスクリプションで選んだものに固定されます。 **初期設定料金はありますか？** ありません。3 日間無料で、その後は番号ごとの料金のみです。番号で WhatsApp を有効化するための支払いはありません。 **キャンペーン機能は失われますか？** 当社はキャンペーンプラットフォームではなく、そのような料金体系でもありません。メッセージはお客様自身のシステムに届くため、キャンペーンは現在の運用場所で実行できます。 **Metaへの会話料金は誰が支払いますか？** お客様が自身の WhatsApp Business Account から Meta に直接支払います。当社が Meta の料金に上乗せすることはありません。 --- ## EasyCoexistence と 8x8 の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-8x8 8x8は企業向け通信サービスで、Coexistenceのドキュメントが非常に明確です。そのため、よく参照されています。EasyCoexistenceは、そのドキュメントを読み、企業向けの営業プロセスなしで、今日から番号を接続したい企業向けに作られています。 ### 2つのサービスが重なる部分 違いを説明する前に、技術的な基盤を共有していることを確認しておきます。 - 8x8:: 8x8の Coexistenceドキュメントは正確で、番号を接続すると無効になる WhatsApp 機能など、制約を通常より明確に説明しています。実際に役立つ参考資料です。 - EasyCoexistence:: 同じ制約があるのは、それが各プロバイダーではなく Meta によるものだからです。私たちも制約を説明し、14 日間の非アクティブ化ルール、同期期間、使えなくなる機能と共存できるように製品を設計しています。 ### 読むことから接続まで ドキュメントだけでは埋まらない差です。 - 8x8:: アカウント担当者、コンタクトセンター製品、キャリアサービスを備えた企業向け CPaaSで、調達プロセスのある組織に販売されています。大規模導入に必要な支援を受けながらオンボーディングできます。 - EasyCoexistence:: サインアップして接続します。Meta自身の Embedded Signup がポートフォリオ、アカウント、番号を選び、WhatsApp Business アプリも使い続けられます。最初の 3 日間は無料で、電話を予約する相手もいません。 ### 契約前に分かること 小規模企業や代理店にとっての実用的な違いです。 - 8x8:: 料金は商談で決まります。これは企業向け CPaaSでは標準的で、音声、コンタクトセンター、メッセージングをまとめて大量購入する顧客には適した方式です。 - EasyCoexistence:: 料金表をすべて公開し、お客様の通貨で利用量ごとの料金帯も示しています。40 番号を扱う代理店なら、アカウント作成前に請求額を計算できます。 ### 番号を接続した後 Coexistenceの接続は静かに失敗するため、多くの比較で見落とされる部分です。 - 8x8:: 契約がある場合に適した、企業向けサポートとアカウント担当者による関係です。 - EasyCoexistence:: Meta自身の切断理由を読み取る継続的な監視により、14 日間の非アクティブ化と、顧客が離脱したケースを区別できます。さらに 16 個のツールを備えた MCP コネクターにより、誰もダッシュボードを開かずにアシスタントが接続状態を確認し、再接続できます。 - 優れたドキュメントを製品そのものだと考えること。ドキュメントが説明するのは Meta の仕組みであり、どのプロバイダーも共有するものです。 - 1 つの番号を接続するために企業向けの手続きを始めること。 - 接続後はどのプロバイダーも監視してくれると思い込むこと。誰を選ぶ場合でも、具体的に確認してください。 **8x8のドキュメントは正確ですか？** はい。私たちも参照しています。説明されている制約は Meta によるものなので、私たちを含むすべての Coexistenceプロバイダーに適用されます。 **Coexistenceではどの機能が使えなくなりますか？** 8x8のドキュメントと私たちの説明によると、消えるメッセージ、一度だけ表示するメディア、ライブ位置情報、ブロードキャストリストの 4 つです。グループチャットは API の対象外です。 **企業向け契約は必要ですか？** 私たちの場合は必要ありません。3 日間無料で、公開料金により、数分で番号を接続できます。 **接続が切れた場合はどうなりますか？** Metaの切断理由を読み取り、アラートでお知らせします。これにより、14 日間の非アクティブ化ルールと実際の離脱を区別できます。 --- ## Coexistence の登録で「この電話番号は対象外です」と表示されたとき https://easycoexistence.com/ja/docs/coexistence-error-number-not-eligible Meta の登録画面に「対象外」と表示されるのは、その番号の WhatsApp Business アプリのアカウントが、プラットフォームへの接続に関する Meta の確認を通過しなかったときです。Meta が公開している理由は、アプリでの利用実績が不十分なことです。対処法は、その番号でアプリを実際に使い続け、そのうえでもう一度フローを実行することです。 ### 実際にはどんなメッセージが表示されますか？ ポップアップには、表示言語に合わせたメッセージが出ます。英語では「This phone number isn't eligible for registration or migration」、スペイン語では「Este número de teléfono no cumple los requisitos para el registro ni la migración」と表示されます。Meta の Embedded Signup のエラーリファレンスでは、コード 3441045 に最も近い文言として「Your phone number isn't eligible to connect to the WhatsApp Business Platform」が記載されています。 言語が違っても意味は同じです。フローは電話番号の手順まで進み、Meta はその番号に登録されている WhatsApp Business アプリのアカウントを確認したうえで、API への接続を見送りました。お使いのスマートフォンには何も変更が加わっておらず、アプリはこれまでどおり動作します。 ### 対象になりそうな番号を Meta が断るのはなぜですか？ 3441045 に対する Meta 自身の解決策は簡潔です。対象かどうかを判断するため、WhatsApp Business アプリでの利用をさらに増やす必要がある、というものです。Meta はしきい値、日数、メッセージ件数を公表していません。そのため、他所で目にする具体的な数字は、Meta のルールではなくプロバイダーの観測値です。 素直に読めば、実際の利用が少ないアカウントが対象です。たとえば、登録して間もない番号や、実際のやり取りがほとんどない番号です。 似て見えても別物の拒否が 2 つあります。コード 3441042 は、その地域の番号ではこの機能が利用できないことを示します。API 側の 2388091 と 2388093 は、移行の対象ではないため登録コードを受け取れない、または確認できないことを示します。これは移行の経路に関するもので、Coexistence とは関係がありません。 ### 再試行の前に何をすべきですか？ WhatsApp Business アプリでその番号を普段どおり使ってください。お客様との実際のやり取りを、送信も受信も、ある程度の期間にわたって続けます。待っている間は、アカウントを削除したり番号を再登録したりしないでください。Meta が見ているのはそのアカウントの利用実績であり、やり直すと確認材料が減ってしまいます。 基本事項も同時に確認してください。アプリは通常の WhatsApp ではなく WhatsApp Business アプリであること、バージョンが 2.24.17 以降であること、そして番号が別の API プロバイダーに接続されていないことが必要です。これらに該当する場合は別のメッセージが表示され、それぞれ個別のページで解説しています。 そのうえで、フローを最初からやり直してください。対象かどうかは試行のたびに Meta が判断します。実際の利用を重ねたあとの新しい試行だけが、意味のある確認になります。 - 続けて何度もフローを再試行すること。対象かどうかは Meta が判断するため、繰り返してもレート制限にかかるだけの場合があります。 - 新規インストールで番号を再登録し、最初からやり直そうとすること。Meta が見ているのは利用実績であり、新しい登録には実績がありません。 - プロバイダーがその番号を例外として承認できると思い込むこと。Meta の判断を覆せるプロバイダーはありません。 **この番号は禁止されたのですか？** いいえ。このメッセージは、番号を API に接続することについてのものです。スマートフォンの WhatsApp Business アプリは、これまでどおり動作します。 **再試行まで、どのくらい待てばよいですか？** Meta は固定の期間を公表していません。Meta が示す解決策は、WhatsApp Business アプリでの実際の利用を増やすことです。そのため、番号が実際に使われる状態になるまで待ってください。 **なぜメッセージに「移行」と出るのですか？** 同じポップアップが、アカウント間での番号の移動も扱っているためです。拒否は両方の経路に共通なので、文言にも両方が含まれています。 **別のプロバイダーなら結果は変わりますか？** いいえ。どのプロバイダーも Meta の同じ Embedded Signup を使っており、対象かどうかの確認は Meta が行います。 --- ## 「この電話番号は既に WhatsApp アカウントに登録されています」 https://easycoexistence.com/ja/docs/coexistence-error-number-already-registered Meta のサインアップのポップアップがこのメッセージを表示するのは、番号がすでに別の場所に登録されていて、試行中の手順が先に進めないときです。登録先は、一般向けの WhatsApp、WhatsApp Business API のアカウント、または他のプラットフォーム上のアカウントのいずれかです。まずその登録先から番号を切断する必要があります。切断後、番号が再び使えるようになるまで数分かかることがあると Meta は説明しています。 ### Meta のドキュメントではこのメッセージはどういう意味ですか？ Meta の Embedded Signup エラーリファレンスには、このメッセージが「This number is registered to an existing WhatsApp account. To use this number, disconnect it from the existing account. Then, return to this page and re-enter the number.」と記載されています。番号が使えるようになるまで最大 3 分かかることがある、という補足もあります。 Meta の説明によると、この電話番号はすでに Meta のプラットフォームに登録されています。登録先として挙げられているのは WhatsApp Messenger、WhatsApp Business アプリ、WhatsApp Business API で、対処法は番号の登録を解除するか、別の番号を使うことです。ポップアップはユーザーの言語で表示されるため、イタリア語、スペイン語、ポルトガル語でも同じ意味の拒否メッセージが届きます。 ### Coexistence のサインアップでこのエラーが出るのはなぜですか？ Coexistence は、すでに WhatsApp Business アプリに登録されている番号を接続するための仕組みです。そのため、登録済みであること自体は問題ではありません。このメッセージが出るのは、フローが Coexistence の経路に入っていないとき、または登録の種類が合っていないときです。 原因は主に 3 つあります。1 つ目は、番号が WhatsApp Business アプリではなく一般向けの WhatsApp にあるケースで、Coexistence では接続できません。2 つ目は、既存の WhatsApp Business アプリのアカウントを接続する選択肢ではなく、通常の新規番号サインアップを実行しているケースで、Meta はその番号を新規登録するものとして扱います。3 つ目は、番号がアプリの外で WhatsApp Business API に直接登録されているケースです。 対処法はそれぞれ異なります。メッセージだけでは動けないのはそのためです。 ### 番号を解放して再試行するにはどうすればよいですか？ 番号がどこにあるかに合わせて対処します。 一般向けの WhatsApp にある場合は、先にスマートフォン上で WhatsApp Business アプリへ移行してください。WhatsApp Business アプリにあるのにポップアップが同じメッセージを出す場合は、フローに既存の WhatsApp Business アプリのアカウントを接続する選択肢が表示されたかを確認してください。その画面が出ないなら、実行しているフローが違います。他のプラットフォーム経由で API に登録されている場合は、そのプラットフォーム側で切断する必要があります。 切断したら、Meta の案内どおり数分待ってからポップアップに戻り、番号をもう一度入力します。ポップアップを閉じてしまった場合は、古いウィンドウを使い回さず、最初からやり直してください。 - 切断した直後に同じ番号で再試行する。Meta によると、利用可能になるまで最大 3 分かかります。 - アプリの番号に対して通常の新規番号サインアップを実行する。Coexistence には、既存の WhatsApp Business アプリのアカウントを接続する選択肢が出るフローが必要です。 - エラーを解消しようとして WhatsApp Business アプリのアカウントを削除する。Coexistence が接続する登録そのものがなくなってしまいます。 **Meta が言う「既存のアカウント」とはどれですか？** ポップアップには表示されません。番号が現在登録されている場所を指します。一般向けの WhatsApp、誤った経路の WhatsApp Business アプリ、または他のプラットフォーム経由の API のいずれかです。 **切断するとチャットは消えますか？** プラットフォームからの切断は、WhatsApp Business アプリの「設定」、「アカウント」、「ビジネスプラットフォーム」から行います。アプリのアカウントを削除する操作とは別のものです。なお、アカウントの削除は解決策ではありません。 **イタリア語で表示されました。同じエラーですか？** はい、同じです。ポップアップは各言語に翻訳されるため、同じ拒否メッセージがセッションの言語で表示されます。 **プロバイダー側での作業は必要ですか？** 番号がそのプロバイダー経由で接続されている場合のみ必要です。新しいフローを完了する前に、そのプロバイダー側で切断してください。 --- ## 「Request code failed: Our servers are temporarily unavailable」 https://easycoexistence.com/ja/docs/coexistence-error-request-code-unavailable 「Request code failed: Our servers are temporarily unavailable. Please wait 1 hour before trying again」は、サインアップ中に番号の認証コードをリクエストしたものの、Meta がコードを送信しなかった場合に表示されます。対処はメッセージの指示どおりです。コードのリクエストをやめ、1 時間しっかり待ってから、新しいフローで 1 回だけ再試行してください。 ### Meta 側の障害ですか？ 障害の可能性はありますが、このメッセージに近い公式のエラーは別の原因を示しています。Meta の Embedded Signup のエラー一覧に、この文言そのものは載っていません。ただし、同じ挙動をする認証コード拒否の系統は載っています。「You have requested your code too many times」、繰り返しのリクエストを示すコード 2494158 と 2388367、コードのリクエスト中のエラーを示す 2593037 です。いずれも、しばらくしてからやり直すよう案内しています。 実際にプラットフォーム側で問題が起きている場合もあります。API では 133004 がサーバーの一時的な利用不可を意味し、Meta は再試行の前に WhatsApp Business Platform のステータスページを確認するよう案内しています。ステータスページに障害の記載がなければ、その番号に対するコードのリクエスト制限と考え、メッセージにある 1 時間を守ってください。 ### Coexistence の番号でコードが求められるのはなぜですか？ Coexistence の経路では、番号はすでに WhatsApp Business アプリに登録されています。そのため Meta はパートナーに、電話番号の登録手順を省略するよう案内しています。Meta が定めるフローでは、所有の確認はアプリ自体で行います。企業は WhatsApp Business アプリで Facebook Business の公式アカウントからのメッセージを受け取り、「Connect」をタップして、そこで認証の手順を完了します。 そのため、コードのリクエストが失敗し続ける場合は、ポップアップがどの経路に入っているかを確認してください。既存の WhatsApp Business アプリのアカウントを接続する画面が表示されなかったなら、フローはその番号を新規登録として扱い、SMS または音声のコードを求めています。今回の制限がかかるのは、まさにこの場面です。 ### 状況を悪化させずに再試行するには？ メッセージが求める 1 時間をそのまま待ち、その間に別のコードをリクエストしないでください。Meta によると、システムは一定の時間内にコードをリクエストできる回数を制限しているため、待機中のリクエストは逆効果になります。 1 時間が過ぎたら、開いたままのウィンドウで再送ボタンを押すのではなく、古いポップアップを閉じてフローを最初からやり直してください。既存の WhatsApp Business アプリのアカウントを接続する選択肢を選び、その番号のスマートフォンをロック解除した状態で手元に置き、認証が届いたらすぐアプリで完了します。 誤ったコードを何度も入力した場合は、Meta の案内が異なります。システムは認証の試行回数に上限を設けており、再試行までおよそ 12 時間待つよう案内しています。 - 1 時間の待機中に再送を何度も押すこと。Meta は一定の期間内にコードをリクエストできる回数を制限しています。 - 障害が長引くと思い込み、番号を切り替えること。メッセージが示しているのは一時的な待機です。 - アプリの番号を新規番号として登録すること。Coexistence の認証は、新たな SMS 登録ではなく WhatsApp Business アプリで行います。 **1 時間より長く待てば効果がありますか？** メッセージが示すのは 1 時間です。それより長く待っても問題はありませんが、その間にコードをリクエストすると逆効果です。 **プロバイダーが制限を解除できますか？** いいえ。認証コードの制限は Meta が番号に対して適用するもので、どのプロバイダーにも解除できません。 **WhatsApp Business アプリには影響がありますか？** いいえ。アプリはスマートフォンでそのまま使えます。拒否されるのは、ブラウザー上のサインアップの手順だけです。 **本当に障害なのか、どう確認できますか？** Meta の WhatsApp Business Platform のステータスページを確認してください。障害の記載がなければ、コードのリクエスト制限と考えてください。 --- ## WhatsApp Business アプリで Coexistence の QR コードのスキャンに失敗する https://easycoexistence.com/ja/docs/coexistence-error-qr-code-pairing-failed Coexistence の登録中にコードのスキャンが失敗する場合、確認すべき原因は電話側にあります。WhatsApp Business アプリが古い、別のアプリや端末でスキャンした、スキャン後に表示される案内に応答していない、のいずれかです。対処法は、アプリを更新し、番号を持つ電話の WhatsApp Business アプリでスキャンして、すべての案内を最後まで完了することです。 ### 電話側では何が起きるはずですか？ Meta のドキュメントでは、電話側の手順を次の 4 つで説明しています。まず、WhatsApp Business アプリ内で公式の Facebook ビジネスアカウントからメッセージが届き、企業側が「接続」をタップします。次に、ビジネスプラットフォームへの接続をタップします。続いて「確認」をタップし、ここでチャット履歴を共有するかどうかを選びます。最後に認証コードの手順を完了し、ブラウザに戻ってフローを終えます。 ブラウザに表示されるコードは、アプリ内でのこのやり取りを始めるためのものです。そのため、スキャンしても何も起きない場合や、スキャンした瞬間に電話にエラーが出る場合は、これらの手順のどれかを開始できなかったことを意味します。それより前のブラウザ側の手順は、すでに正常に完了しています。 ### なぜスキャンに失敗するのですか？ 確認すべき原因は 4 つあります。次の順に見てください。 アプリが古い場合です。Meta は WhatsApp Business アプリのバージョン 2.24.17 以降を求めています。また、Embedded Signup にはアプリを最新バージョンに更新するよう伝えるだけのエラー 4563015 があります。 別のアプリでスキャンした場合です。コードは、メインの電話で番号を持つ WhatsApp Business アプリで処理する必要があります。一般向けの WhatsApp、電話のカメラアプリ、WhatsApp Web や WhatsApp Desktop などのリンク済み端末では処理できません。 案内を完了していない場合です。スキャンは手順を開くだけです。「接続」、ビジネスプラットフォームへの接続、「確認」を順にタップして初めて先に進みます。 ポップアップを閉じた場合です。ブラウザのウィンドウがなくなると、電話側で進めていたフローも一緒に失われます。 ### きれいにやり直すにはどうすればよいですか？ まずアプリストアで WhatsApp Business アプリを更新し、開き直してください。手元の電話が番号を持つ端末であること、ロックが解除されていてオンラインであることを確認します。 次に、ブラウザで登録フローを最初からやり直し、既存の WhatsApp Business アプリのアカウントを接続するオプションを選びます。電話で作業している間は、ポップアップを開いたままにしてください。コードは WhatsApp Business アプリの中で処理し、表示される案内に一つずつ応答して、ブラウザに戻って完了させます。 接続が完了すると、リンク済み端末はログアウトされます。Meta は番号が API に接続された時点ですべてのコンパニオンアプリのリンクを解除しますが、あとで再度リンクできます。 - 電話のカメラアプリでスキャンすること。コードは番号を持つ WhatsApp Business アプリで処理する必要があります。 - 電話で作業中にブラウザのポップアップを閉じること。電話側の手順は、それを開始したフローがないと進みません。 - リンク済み端末のログアウトを失敗とみなすこと。Meta は接続時にコンパニオンアプリのリンクを解除しますが、再度リンクできます。 **企業の代わりに別の人がスキャンできますか？** 番号を持つ電話であれば可能です。この手順は、その端末の WhatsApp Business アプリで行います。 **WhatsApp Web でスキャンできますか？** できません。リンク済み端末はアカウントのコンパニオンです。電話側の手順は、メインの電話の WhatsApp Business アプリで行うものです。 **スキャンに失敗すると電話の状態は変わりますか？** 変わりません。フローが完了するまで番号は接続されず、アプリはこれまでどおり使えます。 **アプリは最新と表示されます。次はどうすればよいですか？** バージョン番号が 2.24.17 以降であることを確認し、フローを最初からやり直して、すべての案内を完了してください。 --- ## 古い Business Portfolio が原因で Coexistence の登録がブロックされる https://easycoexistence.com/ja/docs/coexistence-error-inaccessible-business-portfolio 登録ポップアップで選択した Business Portfolio とは別の Meta Business Portfolio に番号が紐づいていると、Meta は「選択したビジネスに関連付けられていない番号」として拒否します。その別の Business Portfolio 内で番号の紐づけを解除する必要があり、そこで管理者権限を持つ人の協力が要ります。もう一つの方法は、その Business Portfolio 側でフローを実行することです。 ### この問題が起きると Meta は何と表示しますか？ Meta の Embedded Signup エラーリファレンスには、コード 3441041 が載っています。「入力した電話番号は、選択したビジネスに関連付けられていません。続行するには、この電話番号をそのビジネスから解除するか、別の番号を入力してください。」 ここでいう選択したビジネスとは、ポップアップの最初の画面で選んだ Business Portfolio のことです。このメッセージは、Meta がすでにその番号を別の Business Portfolio に関連付けていることを意味します。紐づけは過去の設定に由来する場合があります。たとえば、以前その番号を接続した代理店、退職した従業員の Business Manager、広告用に作られた古い WhatsApp アカウントなどです。今フローを実行している人は、その存在に気づいていないことがよくあります。 ### 別の Business Portfolio から番号の紐づけを解除するには？ Meta が示す解決方法は 2 段階で、どちらも現在その番号を保持している Business Portfolio の中で行います。 まず、その番号に紐づく WhatsApp アカウントを削除します。Meta Business Suite の「設定」から「アカウント」、「WhatsApp アカウント」の順に開き、「アカウントを削除」を選びます。次に、WhatsApp Manager の「電話番号」タブで、電話番号そのものを削除します。 どちらの手順もその Business Portfolio 内で行うため、管理者権限を持つ人が必要です。Meta は、Business Portfolio 内で WhatsApp Business アカウントを作成するだけでも管理者レベルの権限を求めています。番号が解放されたら、もう一度登録を実行し、自分が管理している Business Portfolio を選択してください。 ### 古い Business Portfolio に誰もアクセスできない場合は？ その場合、現実的な選択肢は 2 つに絞られます。 1 つ目はアクセス権の回復です。その Business Portfolio を作成した人、または残っている管理者なら、現在の担当者を管理者として追加できます。代理店が保有している場合は、アクセス権の付与か、紐づけ解除の代行を代理店に依頼してください。 2 つ目は、アクセスを回復したうえで、番号を移さずにその古い Business Portfolio 内でフローを実行する方法です。Coexistence は変換後のアカウントをお客様自身の Business Portfolio に残すため、フローを実行した Business Portfolio が、その後の番号の置き場所になります。1 年後も企業が管理し続けられる方を選んでください。 - 新しい Business Portfolio を作ってやり直す。番号は古い Business Portfolio に紐づいたままなので、同じ拒否が返ってきます。 - 紐づけを切るために WhatsApp Business アプリのアカウントを削除する。紐づけは Meta 側の、別の Business Portfolio 内に保持されています。 - 企業が管理していない Business Portfolio に番号を置いたままにする。その Business Portfolio を管理する人が接続を握ることになります。 **Meta のサポートに番号を移してもらえますか？** 3441041 に対する Meta の解決方法は、別の Business Portfolio にアクセスできる人がその中で紐づけを解除することです。Meta が代わりに番号を移す手順は、公式には説明されていません。 **どの Business Portfolio が番号を保持しているか、どう調べますか？** Meta のメッセージには Business Portfolio の名前が出ません。社内の誰かが使ったことのあるすべての Business Portfolio を確認してください。代理店が作成したものも含みます。 **紐づけを解除すると WhatsApp Business アプリは止まりますか？** この手順で削除するのは、Meta Business Suite と WhatsApp Manager 上の WhatsApp アカウントと電話番号です。スマートフォンのアプリ上で行う操作ではありません。 **番号が別のプロバイダーに接続されている場合と同じ問題ですか？** いいえ。別のプロバイダーの場合は、他社パートナーのアプリへの接続です。今回は、番号が別の Business Portfolio に属している状態です。 --- ## 「既存の WhatsApp Business アプリを接続する」オプションが表示されない https://easycoexistence.com/ja/docs/coexistence-error-option-not-showing 既存の WhatsApp Business アプリのアカウントを接続するオプションは、Meta の Embedded Signup を起動するプラットフォームがコードで有効にしている場合にのみ表示されます。その設定がないと、ポップアップは通常のアカウント選択画面を表示し、電話番号を新規登録として扱います。企業側でオンにすることはできず、プラットフォーム側の対応が必要です。 ### オプションを表示するかどうかは誰が決めますか？ ポップアップを起動するプラットフォームです。Meta のドキュメントでは、パートナーが Embedded Signup を起動する際に、whatsapp_business_app_onboarding を設定した featureType プロパティを追加するよう案内しています。確認方法も示されています。アカウント選択画面が、既存の WhatsApp Business アカウントの接続を提案する画面に置き換わっていれば、機能は有効です。 つまり、企業側に WhatsApp Business アカウントの選択や作成、登録する電話番号の入力といった通常の画面が表示された場合、ポップアップはその設定なしで起動されています。企業自身の Meta 設定を変更しても、これは変わりません。企業にできるのは、この機能を有効にしているプラットフォームのサインアップリンクに切り替えることだけです。 ### プラットフォームが対応していないのはなぜですか？ Meta は、有効化の前にプラットフォーム側が満たすべき要件を定めています。プラットフォームはすでに Solution Partner または Tech Provider であること、Cloud API の使い方を理解していること、Webhook を受信して処理できるコールバックを持っていること、そしてセッションログを有効にして Embedded Signup を実行していることが必要です。 セルフホストのツールや、Tech Provider ではない開発者アプリで構築した連携は、最初の要件を満たせません。その場合、企業側の設定変更でオプションを復活させることはできません。解決策は、この対応を済ませているプラットフォームを使うことです。 もう一つの原因はバージョンです。Embedded Signup v2 と v3 は 2026 年 10 月 15 日に廃止されます。Meta はパートナーに、それまでに v4 へ移行するよう案内しています。 ### オプションは表示されるのにアカウントを選べない場合は？ それは別の拒否で、原因はプラットフォームではなくアカウント側にあります。 Meta のエラーリファレンスには 3441047 が載っています。マーケティングメッセージを使用しているアカウントでは機能が利用できず、企業は別の WhatsApp Business アカウントを選択する必要があります。コード 3441042 は、その地域の電話番号では機能が利用できないことを意味します。また、バージョン 2.24.17 未満のアプリは、最新バージョンへの更新を求められて拒否されます。 これらはそれぞれ、ポップアップ内に専用のメッセージが表示されます。メッセージがまったくないままオプションが表示されない場合は、フローの起動方法に原因があります。 - 企業の Meta 設定で Coexistence のスイッチを探し続けること。このオプションは、ポップアップを起動する側が設定します。 - オプションがないまま通常のフローを完了すること。Meta は電話番号を新規登録として扱うため、Coexistence にはなりません。 - 古い Embedded Signup 連携でも対象になると思い込むこと。Meta は v2 と v3 を 2026 年 10 月 15 日に廃止します。 **企業側で Coexistence を有効にできますか？** ポップアップ内ではできません。このオプションは、Embedded Signup を起動するプラットフォームが featureType の設定で有効にします。 **オプションが有効かどうかは、どう確認できますか？** Meta の確認方法は次のとおりです。アカウント選択画面が、既存の WhatsApp Business アカウントの接続を提案する画面に置き換わっていれば有効です。 **企業に認証済みの Business Portfolio は必要ですか？** このオプションについて Meta が挙げている要件は、起動するプラットフォーム側のものです。企業側には、アプリのバージョン 2.24.17 以降が必要です。 **地域による制限ですか？** 地域による拒否は、コード 3441042 の専用メッセージとして表示されます。メッセージなしでオプションが表示されない場合は、フローの起動方法に原因があります。 --- ## Coexistence の登録中に「WhatsApp Business アプリを更新してください」と表示される https://easycoexistence.com/ja/docs/coexistence-error-business-app-outdated Coexistence を利用するには、番号を保持している端末の WhatsApp Business アプリがバージョン 2.24.17 以降である必要があります。これより古いと、Meta の登録ポップアップは番号を拒否し、アプリを最新バージョンに更新するよう求めます。アプリストアで更新し、最初からフローをやり直せば解決します。 ### メッセージにはどう書かれていますか？ Meta の Embedded Signup エラーリファレンスには、コード 4563015 として「Update your WhatsApp Business App to the latest version to use this phone number」というテキストが記載されています。対処法はその文面のとおりで、アプリを最新バージョンに更新することです。 この背景にある要件は、Meta の Coexistence オンボーディングのドキュメントに記載されています。企業のお客様は WhatsApp Business アプリのバージョン 2.24.17 以上を使用する必要があります。メッセージが求めているのは最低バージョンではなく最新バージョンですが、利用可能な最新バージョンに更新すれば両方を満たせます。 ### どの端末を更新する必要がありますか？ メインの端末です。つまり、WhatsApp Business アプリに番号を登録している端末を指します。Meta が確認するのはこのアプリであり、フローの電話側の手順を処理するのもこのアプリです。 WhatsApp Web、デスクトップアプリ、アカウントにリンクしたタブレットを更新しても対象にはなりません。これらは登録そのものではなく、リンク済みのサブデバイスだからです。Meta のドキュメントには、番号が API に接続されるとリンク済みクライアントは解除されること、また WhatsApp for Windows と WhatsApp for WearOS はその後サポート対象のリンク済みクライアントではないことも記載されています。 代理店として設定を進める場合、ブラウザでフローを操作する担当者が端末を持っていないことがよくあります。開始前に、企業の担当者に端末のバージョンを確認しておくべき手順です。 ### バージョンの確認と再試行はどうすればよいですか？ 番号を保持している端末で、WhatsApp Business アプリのインストール済みバージョンを確認します。アプリ内のヘルプ情報か、端末のアプリストアにあるアプリのページで確認できます。2.24.17 より古い場合、またはストアに更新が表示されている場合は、更新をインストールしてください。 更新後はアプリをいったん閉じて開き直し、新しいバージョンで動作している状態にします。そのうえで、拒否が表示されたポップアップを再開するのではなく、ブラウザで登録フローを最初からやり直し、既存の WhatsApp Business アプリのアカウントを接続するオプションを選択してください。 更新はアプリストアで行うもので、登録ポップアップ内では行えません。そのため、端末を持っている人が実施する手順になります。更新が完了したと思い込まず、フローを再実行する前に、新しいバージョン番号を本人に確認してください。 - WhatsApp Web やデスクトップアプリを更新する。Meta が確認するのは、メインの端末の WhatsApp Business アプリです。 - 両方のアプリが入っている端末で、一般向けの WhatsApp を更新する。Business アプリは別のインストールで、バージョンも別に管理されます。 - 更新後に同じポップアップで再試行する。フローを最初からやり直し、新しいバージョンで確認が行われるようにしてください。 **2.24.17 で足りますか。それとも最新バージョンが必要ですか？** Meta が示す最低バージョンは 2.24.17 です。エラーメッセージは最新バージョンを求めているため、最新に更新すれば両方を満たせます。 **更新するとチャットは消えますか？** 更新は同じ登録のままアプリのバージョンを置き換えるだけです。アカウントの削除や番号の再登録とは異なります。削除や再登録は避けてください。 **接続後もバージョンは重要ですか？** Meta の要件はオンボーディング時のものです。ただし端末は接続の一部であり続けるため、アプリを最新に保つことをおすすめします。 **番号が対象外であることと同じですか？** いいえ。対象かどうかはアカウントのアクティビティに関するものです。このエラーは、端末のアプリのバージョンだけが原因です。 --- ## Coexistence エラー：番号がすでに別のプロバイダーに接続されています https://easycoexistence.com/ja/docs/coexistence-error-number-on-another-provider Meta の Coexistence フローでは、別のプラットフォームが番号を保持している間は、WhatsApp Business アプリの番号を新しいプラットフォームに接続できません。番号がすでに別のプロバイダーに接続されている場合、Meta の登録ポップアップは番号を受け付けず、このフローではパートナーの切り替えはサポートされないと表示します。企業は WhatsApp Business アプリで現在のプラットフォームの接続を解除し、15 分待ってから、新しい登録を実行してください。 ### 番号が別のプロバイダーにあることを示すメッセージは？ Meta の Embedded Signup エラーリファレンスには、WhatsApp Business アプリユーザーのオンボーディングの項目に、この状況に該当するものが 3 つあります。 - 2655093：この企業はすでに WhatsApp Business アカウントをパートナーと共有しており、このフローではパートナーの切り替えはサポートされていません。 - 3441049：番号はすでにこの製品に登録されているため、WhatsApp Business アプリで現在のアカウントから接続を解除する必要があります。 - 2655094：続行するにはビジネスプラットフォームの接続を解除し、15 分待ってから再試行してください。 ### 現在のプロバイダーはどのように解除しますか？ スマートフォンの WhatsApp Business アプリで行います。Meta が示す手順は、「設定」、「アカウント」、「ビジネスプラットフォーム」の順に開き、接続中のプラットフォームを選んで「接続を解除」をタップする方法です。また Meta によると、アプリと Cloud API の両方で使用中の番号には、API 側の登録解除の呼び出しは使えません。そのため、解除は以前のプロバイダーのダッシュボードではなく、アプリで行います。 企業が接続を解除すると、Meta は以前のプラットフォームに、PARTNER_REMOVED イベントを含む account_update の Webhook を送信します。以前のプロバイダーはこれで解除を把握します。そのプロバイダーとのサブスクリプションは、企業と先方の間で別途対応する事項です。 ### 接続を解除したあとはどうなりますか？ 待ってください。3441049 と 2655094 の Meta のメッセージは、どちらも再試行の前に 15 分待つよう案内しています。 その後、新しいプラットフォームの登録を最初から実行し、既存の WhatsApp Business アプリのアカウントを接続するオプションを選びます。これは新規のオンボーディングです。チャット履歴の共有が再び提案され、新しいプラットフォームにはオンボーディング後 24 時間の間に、連絡先と履歴を同期する猶予があります。 切り替えが止まる場合が 1 つあります。Meta によると、過去にパートナーと連携し、そのパートナーのクレジットラインをいまも共有している企業は、新しいパートナーへ移る際にエラーが表示されることがあります。Meta は解決方法を説明する別のガイドを公開しています。 - 以前のプロバイダーに番号の登録解除を依頼すること。Meta によると、アプリと Cloud API の両方で使用中の番号には、登録解除の呼び出しは機能しません。 - 接続を解除して数分で再試行すること。Meta は 15 分待つよう案内しています。 - 古い接続を断つために WhatsApp Business アプリのアカウントを削除すること。公式の手順は、設定から接続を解除する方法です。 **番号を 2 つのプロバイダーに同時に接続できますか？** このフローではできません。Meta のメッセージによると、現在のプロバイダーの接続を先に解除しない限り、パートナーの切り替えはサポートされません。 **接続を解除するとチャットは削除されますか？** 削除されるのはプラットフォームとの接続です。WhatsApp Business アプリはスマートフォンに残り、そのまま使えます。 **新しいプロバイダーが以前のプロバイダーを解除してくれますか？** いいえ。解除は、企業が WhatsApp Business アプリで行います。 **新しいプロバイダーで履歴は再び同期されますか？** 新しいオンボーディングで履歴の共有が再び提案され、新しいプラットフォームには同期を実行するための 24 時間があります。 --- ## Coexistence 登録後に「This authorization code has expired」と表示される https://easycoexistence.com/ja/docs/coexistence-error-authorization-code-expired Meta の Embedded Signup が完了すると、起動元のプラットフォームに有効期間の短いコードが渡されます。このコードは 30 秒以内にアクセストークンへ交換する必要があります。交換が遅れた場合や、以前の試行で発行されたコードを使った場合、Meta は認可コードが期限切れであると応答します。フローをもう一度実行すると、新しいコードが発行されます。 ### どのコードが期限切れになったのですか？ 企業が Embedded Signup を完了すると、Meta はアセット ID と交換用トークンコードを、ポップアップを開いたブラウザーのウィンドウに返します。プラットフォームはそのコードを自社のサーバーに送り、サーバーがアプリ ID とアプリシークレットを使って Meta の oauth access_token エンドポイントを呼び出し、ビジネストークンに交換します。 Meta の実装ガイドでは、タイミングが明確に定められています。交換用トークンコードの有効期間は 30 秒で、プラットフォームは期限が切れる前に交換できる状態にしておく必要があります。それを過ぎて交換しようとすると拒否され、その拒否が「This authorization code has expired」と表示されます。企業側がポップアップをゆっくり完了したことが原因ではありません。コードが返された時点から時間が数えられます。 ### ポップアップの完了が遅れたり、2 回実行したりすると、なぜ起きるのですか？ 交換が制限時間を過ぎてしまう状況はいくつかあります。 フローの完了時にブラウザーのタブがバックグラウンドにあった、またはノート PC がスリープしていた場合、コードは発行からかなり経ってからプラットフォームのサーバーに届きます。プラットフォームのサーバーが、交換をすぐに行わず他の処理の後ろに回した場合もあります。また、利用者がフローを 2 回開いて両方を完了し、2 つ目の完了後に 1 つ目のウィンドウのコードを交換した場合にも起こります。 テスト中には 4 つ目の原因があります。ブラウザーのコンソールからコードをコピーし、cURL や Postman で手作業で交換するケースです。Meta のガイドはまさにこの点に注意を促しており、開始前に交換リクエストを準備しておくよう案内しています。 ### 接続を完了するにはどうすればよいですか？ 1 つのウィンドウでフローを最初からやり直し、プラットフォームのページを前面に表示したまま完了させてください。完了のたびに新しいコードが返されるので、プラットフォームはそれをすぐに交換すれば十分です。 Coexistence の番号の場合は、速やかに行ってください。企業がフローを完了した時点で、Meta は WhatsApp Business アカウントを変換します。プラットフォームが顧客のオンボーディングを行ってから、メッセージ履歴を同期できる時間は 24 時間です。それを過ぎると、企業をいったんオフボーディングし、フローを最初からやり直す必要があります。 プラットフォーム側の恒久的な対策は、コードが届いた瞬間に、他のオンボーディング手順より先にサーバーで交換することです。 - 同じコードでトークンの交換を再試行すること。コードは 30 秒で期限切れとなり、元には戻りません。 - 2 つのウィンドウで同時にサインアップを実行すること。有効なのは、交換する試行で発行されたコードだけです。 - ブラウザーからコードを交換すること。Meta は、アプリシークレットを用いたサーバー間リクエストでの交換を求めています。 **企業は番号を接続できたのですか？** 企業は Meta のフローを完了しましたが、プラットフォームがコードを有効なトークンに交換できなかったため、まだその番号を操作できません。フローをもう一度実行すれば、新しいコードが発行されます。 **コードの有効期間を延ばせますか？** いいえ。30 秒の有効期間は Meta が定めており、どのプラットフォームも延長できません。 **WhatsApp Business アプリには影響がありますか？** いいえ。この問題を解決している間も、アプリは携帯電話で通常どおり動作します。 **アクセストークンの期限切れと同じものですか？** いいえ。これは有効期間の短いサインアップ用コードです。正常に動作している接続でアクセストークンが期限切れになった場合は、エラー 190 が返されます。 --- ## 「Your app is missing required Graph API permissions for Cloud API companion pairing」 https://easycoexistence.com/ja/docs/coexistence-error-companion-pairing-permission このメッセージは、サインアップを開始したプラットフォームが、WhatsApp Business アプリの電話番号を Cloud API に接続するために Meta が求める WhatsApp 権限を、求められるアクセスレベルで持っていないことを示します。Meta では、プラットフォームが Advanced access を持つ権限しか企業は付与できません。企業側では解決できず、プラットフォーム側で対処する必要があります。 ### このメッセージは何を意味しますか？ 全文は次のとおりです。「Your app is missing required Graph API permissions for Cloud API companion pairing. Please verify advanced WhatsApp Business permissions are granted, then try again.」Meta が公開しているエラーリファレンスにこの文言そのものは載っていませんが、各部分は Meta の公開ドキュメントにある内容に対応しています。 「Your app」とは、サインアップを実行しているプラットフォームの Meta アプリを指し、スマートフォン上の WhatsApp Business アプリではありません。companion pairing について Meta は公開で定義していませんが、文脈から読むと、WhatsApp Business アプリに登録されたままの番号に Cloud API が加わる仕組み、つまり Coexistence の構成を指しています。また「advanced」な WhatsApp Business 権限とは、Meta が App Review を通じて付与する Advanced access のことです。 ### どの権限が関係していますか？ Meta の権限ドキュメントでは、WhatsApp 連携で一般的に必要になる権限として 2 つが挙げられています。whatsapp_business_management は、アカウントのメタデータ、テンプレート、電話番号、分析、アカウントの Webhook を扱います。whatsapp_business_messaging は、メッセージの送信と、メッセージおよびステータスの Webhook の受信を扱います。 クライアントが自社のアプリを使うパートナーの場合、Meta はアプリに必要なすべての権限について App Review と Advanced access を求めます。Meta は結果も明示しています。ある権限の Advanced access がなければ、クライアントは Embedded Signup を通じてその権限をアプリに付与できません。Advanced access なしで、アプリが所有していないアカウントに whatsapp_business_management で呼び出しを行うと、エラー 200 が返ります。 企業が実際に何を付与したかは、Meta の debug_token エンドポイントでトークンを調べると確認できます。付与済みの権限は scopes に一覧表示されます。 ### 企業側でできることはありますか？ 企業側でできることはほとんどなく、このエラーを解消しようとして Meta の設定を変更するべきでもありません。対処はプラットフォーム側にあります。プラットフォームは Tech Provider または Solution Partner である必要があり、これは Meta が WhatsApp Business アプリのユーザーをオンボードする条件として挙げています。さらに、WhatsApp 権限について Advanced access の承認を受ける必要があります。 企業ができるのは、表示されたメッセージをそのままプラットフォームに伝えることです。そのうえで、プラットフォームがアクセスを確認してから再試行するか、すでにその資格を持つプラットフォームを利用してください。それまでに同じプラットフォームで同じ手順を繰り返しても、結果は変わりません。スマートフォン上の WhatsApp Business アプリにも影響はありません。 - 企業自身の Meta 設定で権限を追加付与しようとすること。不足しているアクセスは、プラットフォームのアプリ側にあります。 - App Review を受けずに、開発者アプリ上でツールを自社運用すること。Advanced access がなければ、企業は必要な権限を付与できません。 - 同じプラットフォームで何度も再試行すること。結果が変わるのは、そのプラットフォームのアクセスが変わったときだけです。 **WhatsApp Business アプリに問題があるのでしょうか？** いいえ。このメッセージが指しているのはプラットフォームの Meta アプリであり、お使いのスマートフォンのアプリではありません。スマートフォンのアプリはそのまま使えます。 **自分で権限を付与できますか？** 付与の対象として表示されるのは、プラットフォームが Advanced access を持つ権限だけです。不足しているアクセスは、まずプラットフォームに対して承認される必要があります。 **プラットフォームはどうすれば Advanced access を取得できますか？** クライアントが自社のアプリを使うパートナーとして、アプリに必要な権限ごとに Meta の App Review を受けます。 **企業にも App Review は必要ですか？** いいえ。Meta によれば、自社のビジネスデータにのみアクセスする直接の開発者には、App Review も Advanced access も不要です。 --- ## WhatsApp エラー 0：アプリユーザーを認証できません https://easycoexistence.com/ja/docs/whatsapp-error-0 エラーコード 0 は、Meta がアクセストークンの背後にあるアプリユーザーを認証できなかったことを意味します。Meta の説明は「We were unable to authenticate the app user.」です。トークンの有効期限切れ、トークンの無効化、またはユーザーがすべてのアプリによるデータへのアクセスをブロックしたことが原因です。対処法は再試行ではなく、新しいアクセストークンの取得です。 ### WhatsApp のエラーコード 0 は何を意味しますか？ プラットフォームがリクエストを受け取ったものの、信頼できるアプリユーザーと結び付けられなかったことを意味します。 Meta は Cloud API のエラーリファレンスで、コード 0 を認可エラーに分類しており、詳細テキストは「We were unable to authenticate the app user.」です。挙げられている原因はすべてトークンに関するものです。トークンの有効期限が切れた、トークンが無効化された、またはトークンを許可した本人がすべてのアプリによるデータへのアクセスを禁止する設定に変更した、のいずれかです。 この一覧に、電話番号、WhatsApp Business アカウント、送信中のメッセージに関する項目はありません。リクエストはそれらを確認する段階まで進んでいないということです。 ### エラー 0 はどう直しますか？ 新しいアクセストークンを取得してください。これは Meta が示している対処法であり、有効な方法はこれだけです。 ただし、交換する前に 3 つの原因のどれに当たるかを突き止めてください。原因を放置すると、同じエラーが再発するためです。有効期間の短いユーザートークンは、期限が来ればまた切れます。無効化されたトークンは、誰かが改めてアクセスを許可するまで失敗し続けます。アプリのアクセスを完全にオフにしたユーザーの場合は、まずそれをオンに戻さない限り、そのユーザーのどのトークンも使えません。 サーバー間の送信では、Meta のアクセストークンガイドが System User トークンを推奨しています。長期間有効で、ユーザー操作を必要としない自動化サービスに向いていると説明されています。 ### エラー 0 とエラー 190 は同じですか？ 実際には重なる部分がありますが、Meta は別のコードとして掲載しています。 エラー 190 の詳細テキストは「Your access token has expired.」です。エラー 0 はより広い範囲を指し、期限切れのトークン、無効化されたトークン、アプリのアクセスを完全にブロックしたユーザーを含みます。どちらも同じ認可エラーの表に載っており、どちらも新しいトークンの取得で対処します。 実務上の違いは原因の切り分けです。190 ならトークンが期限切れになったと分かります。0 は認証に失敗したことしか分からず、理由は自分で調べる必要があります。調べずに交換すると、1 時間後にまったく同じ理由で失敗する可能性があります。 - 同じリクエストを再試行すること。認証されていないトークンは認証されないままなので、再試行のたびにコード 0 が返ります。 - 番号を再接続すること。番号はそもそも確認されていないため、オンボーディングをやり直しても企業の担当者に余計な作業を頼むだけで、何も変わりません。 - バックエンドのジョブに、有効期間の短いユーザートークンを新しく発行すること。期限が来ればまた切れて、エラーが再発します。 **エラー 0 は番号の接続が切れたという意味ですか？** いいえ。Meta がコード 0 の原因として挙げているのは、すべてアクセストークンに関するものです。番号や、スマートフォン上の WhatsApp Business アプリは関係ありません。 **エラー 0 はどこに記載されていますか？** Meta の Cloud API エラーコードのリファレンスにある、認可エラーの表に記載されています。Cloud API は Graph API を基盤としており、同じエラー形式を使います。 **待てばエラー 0 は解消しますか？** いいえ。期限切れや無効化されたトークンが自然に回復することはありません。新しいトークンが必要です。 **トークンで何ができるかを確認するには？** Meta のアクセストークンデバッガーか、debug_token エンドポイントを使ってください。どちらも、トークンが有効かどうか、有効期限、付与されている権限を確認できます。 --- ## WhatsApp エラー 3: 機能または権限の問題 https://easycoexistence.com/ja/docs/whatsapp-error-3 エラーコード 3 は、エンドポイントを呼び出したアプリに、そのエンドポイントが必要とする機能または権限がないことを意味します。Meta の説明は「Capability or permissions issue」です。Graph API ではこのコードを API Method と呼んでいます。対処は、アクセストークンデバッガーでトークンに付与されている権限を確認し、エンドポイントが必要とする権限を追加することです。 ### WhatsApp のエラーコード 3 は何を意味しますか？ リクエストの認証は通ったものの、アプリが要求した操作を行う許可がないことを意味します。 Meta は Cloud API リファレンスの認可エラーの一覧にコード 3 を載せ、詳細テキストを「Capability or permissions issue」としています。Cloud API が引き継いでいる Graph API のエラー処理ガイドでは、同じコードを API Method と呼び、呼び出しに必要な機能や権限がアプリにあるかを確認するよう案内しています。 つまり、トークンは機能しています。本人確認の問題ではないため、この点がコード 0 や 190 との違いです。問題になっているのは、トークンがどこまで操作を許可されているかです。 ### トークンにどの権限があるかを確認するには？ アクセストークンデバッガーを使うか、同じ情報を返す debug_token エンドポイントを使います。 レスポンスの scopes プロパティに、付与済みの権限が一覧で表示されます。この一覧を、失敗したエンドポイントのリファレンスページと照らし合わせてください。各リファレンスには、必要な権限が明記されています。 WhatsApp では、2 つの権限でほぼすべてをカバーできます。whatsapp_business_management は、アカウントのメタデータ、テンプレート、電話番号の一覧、分析、アカウントの Webhook に必要です。whatsapp_business_messaging は、あらゆるメッセージの送信と、メッセージおよびステータスの Webhook の受信に必要です。どちらか一方しか持たないトークンは、もう一方が必要な呼び出しで失敗します。 ### 直接開発する場合は出ないのに、パートナーのアプリでエラー 3 が出るのはなぜですか？ 他社向けにサービスを提供するパートナーには、追加の関門があるためです。 Meta の権限ガイドによると、顧客企業がアプリを通じて自社データにアクセスするパートナーは、アプリレビューを通過し、アプリが必要とするすべての権限について Advanced access を持つ必要があります。自社のビジネスデータだけを扱う直接の開発者には、アプリレビューも Advanced access も必要ありません。 そのため、同じコードが開発者自身のアカウントでは問題なく動き、顧客のアカウントでは失敗することがあります。このパターンに当てはまる場合、確認すべきなのはトークンにどの権限が欠けているかではなく、自社が所有しないアセットに対してその権限を使うことがアプリに承認されているかどうかです。 - 同じスコープで新しいトークンを発行する。同じ権限の新しいトークンでも、同じ箇所で失敗します。 - 権限の名前をトークンではなくアプリの設定で確認する。重要なのは、トークンに実際に付与された内容です。 - 自分のアカウントだけでテストする。パートナーのアプリは、顧客のアカウントが呼び出しを受け付ける前に Advanced access が必要です。 **エラー 3 は電話番号の問題ですか？** いいえ。アプリのトークンに何が許可されているかに関するエラーです。リクエストが拒否される前に、電話番号は確認されません。 **エラー 3 とエラー 10 の違いは何ですか？** コード 3 は機能または権限の問題です。コード 10 は、権限が付与されていないか、削除されたことを示します。どちらも、トークンのスコープを確認することで解決できます。 **メッセージを送信するにはどの権限が必要ですか？** whatsapp_business_messaging です。Meta の権限ガイドでは、あらゆる種類のメッセージを送信するために必要と説明されています。 **再試行すれば解決しますか？** いいえ。再試行してもトークンの権限は変わらないため、結果は同じです。 --- ## WhatsApp エラー 4：アプリが API 呼び出しのレート制限に達しました https://easycoexistence.com/ja/docs/whatsapp-error-4 エラーコード 4 は、アプリが API 呼び出しのレート制限に達したことを意味します。Meta の説明は「The app has reached its API call rate limit.」です。数えられるのは番号から送信したメッセージ数ではなく、アプリが直近 1 時間（ローリング）に行った呼び出し数です。App Dashboard で使用状況を確認し、しばらく待ってから、アプリが API を呼び出す頻度を減らしてください。 ### WhatsApp のエラーコード 4 は何を意味しますか？ 現在のウィンドウ内でアプリの API 呼び出しが多すぎるため、カウントが下がるまで以降の呼び出しが拒否されている状態です。 Meta はコード 4 をスロットリングエラーに分類し、詳細テキストは「The app has reached its API call rate limit.」です。Graph API のエラー処理ガイドでは API Too Many Calls と呼び、一時的なスロットリングの問題としています。 混同しやすい別のスロットリングコードが 2 つあります。80007 は WhatsApp Business アカウントがレート制限に達した場合、130429 は Cloud API のメッセージスループットです。コード 4 はどちらでもなく、アプリ自体の呼び出し枠に関するものです。 ### アプリの呼び出し上限はどのように計算されますか？ アプリのアクセストークンで行うリクエストについて、Meta の Graph API レート制限ガイドには計算式があります。1 時間あたりの呼び出し数は、200 にユーザー数を掛けた値です。 ユーザー数は、アプリの一意な日次アクティブユーザー数が基準です。日次の利用が落ち込むときは、週次や月次の数値が使われます。上限はユーザーごとではなくアプリ全体に適用されるため、少数のアクティブなユーザーがほとんどを使い切ることもあります。 ガイドによると、使用状況は App Dashboard に表示され、十分な数の呼び出しが行われるとレスポンスの X-App-Usage ヘッダーにも含まれます。このヘッダーを見れば、エラー 4 が出る前に上限への接近に気づけます。 ### エラー 4 が出たらどうすればよいですか？ しばらく呼び出しを止め、その後は呼び出しを減らしてください。 前半について、Meta のレート制限ガイドは明確です。上限に達したら API 呼び出しを止めてください。続けると呼び出し数が増え、再び成功するまでの時間が長くなるためです。 後半は設計の問題です。リクエストはバーストさせず均等に分散し、レスポンスは必要な情報が 1 回で返るように絞り込み、重複するデータを取得する呼び出しは避けます。原因として多いのはポーリングです。同じアカウントの状態を数秒おきに問い合わせる連携は、すでに持っている答えのために枠を使ってしまいます。 - ループで再試行する。追加の呼び出しのたびにカウントが増え、回復がさらに遠のきます。 - 送信制限だと思い込む。コード 4 はアプリの呼び出しを数えるもので、メッセージのスループットは 130429 です。 - ステータス用エンドポイントを短い間隔でポーリングする。変わらないデータを繰り返し読むと、1 時間の枠を消費します。 **エラー 4 とエラー 130429 は同じですか？** いいえ。130429 は番号のメッセージスループットです。エラー 4 は、アプリが行った API 呼び出しの数に関するものです。 **エラー 4 はどのくらい続きますか？** ローリング 1 時間のウィンドウ内の呼び出し数が上限を下回るまで続きます。その間に呼び出すと、さらに延びます。 **アプリが上限にどれだけ近いかはどこで確認できますか？** App Dashboard の Application Rate Limit セクションと、レスポンスで返される X-App-Usage ヘッダーで確認できます。 **エラー 4 とエラー 80007 は同じですか？** いいえ。80007 は WhatsApp Business アカウントがレート制限に達したときに Meta が使うコードで、エラー 4 はアプリ自身の呼び出しを数えます。 --- ## WhatsApp エラー 10: 権限が付与されていない、または削除された https://easycoexistence.com/ja/docs/whatsapp-error-10 エラーコード 10 は、アプリのトークンにエンドポイントが必要とする権限がないことを示します。権限が一度も付与されていないか、後から削除されたことが原因です。Meta の説明は「Permission is either not granted or has been removed.」です。Meta は WhatsApp 固有の原因も 2 つ挙げています。Flows with Endpoint で許可リストに登録されていない電話番号を使った場合と、API の利用資格の要件を満たしていない場合です。 ### WhatsApp のエラーコード 10 は何を意味しますか？ トークンは Meta に届いて認識されたものの、呼び出しに必要な権限がそのトークンに含まれていない、という意味です。 Meta の Cloud API リファレンスでは、コード 10 の詳細テキストは「Permission is either not granted or has been removed.」とされています。Graph API エラー処理ガイドでは API Permission Denied と呼ばれ、不足している権限に対処するよう案内しています。 重要なのは「削除された」という点です。権限は設定時に付与されても、後で取り消されることがあります。たとえば、誰かが「ビジネス設定」でアプリのアクセス権を取り消した場合です。そのため、数か月問題なく動いていた連携が、コードを一切変更していないのに 10 を返し始めることがあります。 ### エラー 10 について Meta が挙げているほかの原因は何ですか？ WhatsApp 固有の原因が 2 つあります。どちらもスコープとは無関係なので、見落としやすい原因です。 WhatsApp Flows with Endpoint では、ビジネスの公開鍵の設定に使った電話番号が許可リストに登録されていることを確認するよう、Meta は案内しています。許可リスト外の番号では、トークンにすべての権限があってもこのコードが返されます。 また Meta によると、呼び出している API の利用資格の要件を満たしていないアカウントにも、このコードが返されます。この場合、原因は認証情報ではなくアカウントの利用資格にあるため、トークンを変更しても解決しません。 ### エラー 10 はどう解決しますか？ まず、Meta が最初の確認手段として挙げているアクセストークンデバッガーを使います。 `scopes` の一覧にエンドポイントが必要とする権限がない場合は、企業側にその権限を付与し直してもらってください。パートナーアプリの場合は、その権限の高度なアクセス権が承認されているかの確認も必要です。Meta の権限ガイドでは、顧客のアカウントで使うには高度なアクセス権が必須とされています。 スコープが揃っているように見える場合は、WhatsApp 固有の 2 つの原因を確認します。Flows の呼び出しなら、公開鍵を設定した電話番号が許可リストにあるかを確認してください。それ以外の呼び出しなら、対象 API の利用資格の要件を読み、アカウントが満たしているかを確かめます。認証情報を変更するのは、その後です。 - デプロイが原因で連携が壊れたと決めつけること。「ビジネス設定」で権限が削除されると、コードを変更しなくてもこのコードが返されます。 - 原因が利用資格なのにトークンを作り直すこと。認証情報で、利用資格のないアカウントを適格にすることはできません。 - Flows の許可リストを見落とすこと。Flows with Endpoint では、許可リスト外の番号はすべてのスコープがあっても 10 を返します。 **エラー 10 とエラー 131005 は同じものですか？** Meta のリファレンスでは、両者の説明文は同じです。コード 10 は Graph API のコードで、131005 は WhatsApp 用の範囲にあるコードです。確認方法はどちらも同じです。 **昨日まで動いていた番号でエラー 10 が出ることはありますか？** あります。Meta の説明には削除された権限も含まれているため、以前に付与されたアクセスが後から取り消されることがあります。 **エラー 10 はトークンの有効期限切れを意味しますか？** いいえ。トークンの期限切れはコード 190 または 0 です。コード 10 は、トークンは有効でも必要な権限がないことを意味します。 **付与されている権限はどこで確認できますか？** `debug_token` を呼び出すか、アクセストークンデバッガーを開いてください。`scopes` プロパティに、そのトークンのすべての権限が一覧表示されます。 --- ## WhatsApp エラー 200：アクセストークンが指定されていません https://easycoexistence.com/ja/docs/whatsapp-error-200 エラーコード 200 は、アクセストークンなしのリクエストが Meta に届いたことを意味します。Meta の説明は「No access token was provided」で、API は「Provide valid app ID」というメッセージを返します。whatsapp_business_profile など、一部の GET エンドポイントで発生します。また、200 から 299 までのコードは、権限が付与されていない、または削除された場合も表します。 ### エラー 200 に「Provide valid app ID」と表示されるのはなぜですか？ API がそのメッセージを返すためで、実際の問題はトークンの欠落です。 Meta のエラーリファレンスによると、コード 200 は whatsapp_business_profile など一部の GET エンドポイントでトークンが含まれていないときに発生し、API は「Provide valid app ID」というメッセージを返します。同じリファレンスには、同じ漏れに対して他のエンドポイントが 190 や 104 を返す場合があるとも書かれています。 つまり、文面はアプリ ID を指していますが、直すべきなのはトークンです。Authorization ヘッダーが付いていて綴りも正しいか、リクエストを組み立てた時点でトークンを入れる変数に値が入っていたかを確認してください。 ### エラー 200 が権限不足を意味するのはどんなときですか？ トークンは付いているものの、呼び出しに必要な権限がアプリにないときです。 Meta は 200 から 299 の範囲を「Permission is either not granted or has been removed」としており、対処法はコード 10 と同じで、アクセストークンデバッガーでトークンを確認することです。ドキュメントには具体的なケースが 2 つあります。権限ガイドでは、Advanced access なしで、自社が所有していない WABA に whatsapp_business_management を使うアプリは、エラー 200 になるとされています。登録ガイドでは、whatsapp_business_management なしで電話番号の登録を解除するとエラー 200 が返るとされています。アクセストークンガイドにはもう 1 つあり、System User トークンのユーザーが問い合わせ先のリソースにアクセスできない場合も 200 で拒否されます。 見分けるには、メッセージ本文を読んでください。トークンがない場合は「Provide valid app ID」と表示されます。 ### エラー 200 とエラー 190 はどう違いますか？ エラー 190 は、送信されたトークンが期限切れであることを意味します。エラー 200 の最初の意味は、トークンが送信されなかったことです。 Meta のリファレンスはこの違いを明記しています。200 の対処法は、リクエストに有効なアクセストークンを含めることで、期限切れや無効なトークンを扱う 190 とは別の状態だとしています。 見るべき場所が変わります。190 ならトークンの有効期間と更新を確認します。「Provide valid app ID」付きの 200 なら、リクエストを組み立てるコードを確認します。認証情報が自社のシステムから出ていないからです。 - アプリ ID の問題を探してしまう。メッセージにはアプリ ID とありますが、Meta が示す原因はトークンなしのリクエストです。 - 送信されていないトークンを更新してしまう。新しいトークンでも、リクエストに付けなければ同じエラーになります。 - 200 をすべてトークン欠落と決めつける。トークンがある場合、200〜299 の範囲は権限不足を意味します。 **正常に動作している番号でもエラー 200 は出ますか？** はい。エラー 200 は番号ではなくリクエストについての内容です。接続状態が正常な番号でも、トークンなしで届いた呼び出しは拒否されます。 **あるエンドポイントは 200、別のエンドポイントは 190 を返したのはなぜですか？** Meta によると、トークンがない場合、一部の GET エンドポイントは 200 を返し、他のエンドポイントは 190 や 104 を返すことがあります。 **電話番号の登録解除には特別な権限が必要ですか？** はい。Meta の登録ガイドによると、whatsapp_business_management なしで登録を解除するとエラー 200 が返ります。 **エラー 200 はエラー 10 と関係がありますか？** 権限の意味では関係があります。どちらも、権限が付与されていない、または削除されたという説明が付いています。 --- ## WhatsApp エラー 130472：実験の一環としてメッセージが送信されなかった https://easycoexistence.com/ja/docs/whatsapp-error-130472 エラー 130472 は、受信者が Meta のマーケティングメッセージ実験の対象になっているため、マーケティングテンプレートメッセージが送信されなかったことを示します。Meta の説明は「Message was not sent as part of an experiment.」です。ごく一部の WhatsApp ユーザーには、カスタマーサービスウィンドウまたは無料エントリーポイントウィンドウが開いている場合を除き、マーケティングテンプレートが届きません。このメッセージには課金されません。 ### WhatsApp エラー 130472 は何を意味しますか？ 受信者が実験グループに属しているため、Meta がマーケティングテンプレートを保留したことを意味します。 Meta の実験に関するページによると、WhatsApp はメッセージがユーザー体験に与える影響を測定するため、継続的に実験を行っています。マーケティングメッセージ実験では、ごく一部の WhatsApp ユーザーが、その企業とのカスタマーサービスウィンドウまたは無料エントリーポイントウィンドウが開いていない限り、どの企業からもマーケティングテンプレートメッセージを受け取りません。 このようなユーザーにマーケティングテンプレートを送信しても、WhatsApp は送信せず、課金もしません。ステータスの Webhook が届き、status は `failed`、エラーコードは 130472 となります。 ### エラー 130472 になるお客様には、どう連絡すればよいですか？ お客様から先にメッセージを送ってもらい、カスタマーサービスウィンドウを開いてもらう方法です。 Meta の実験に関するページには、テンプレートを再送しても同じエラーになると明記されています。Meta が示している方法は、WhatsApp 以外の別の手段でユーザーに連絡し、メッセージを送ってもらうことです。そうすれば、開いたカスタマーサービスウィンドウの中でテンプレートを送信できます。 この実験の対象はマーケティングテンプレートに限られます。グループに入っているユーザーには、送信元の企業を問わず適用されます。そのため、アカウント、テンプレート、番号のいずれにも原因はなく、それらを変更しても解決しません。 ### 連携システムではエラー 130472 をどう処理すべきですか？ そのメッセージの最終状態として扱い、再試行すべき失敗としては扱いません。 このエラーは送信リクエストのレスポンスだけでなく、ステータスの Webhook を通じて届きます。そのため、処理は Webhook のプロセッサー側に置くのが適切です。メッセージを「実験により保留」と記録し、再試行をキューに入れず、失敗率のアラートからも除外してください。配信品質の問題に見えてしまうのを防げます。 レポートでも分けて集計することをお勧めします。130472 が数件あるキャンペーンは、御社の対応によって品質やリーチを落としたわけではありません。本当の失敗と一緒に数えると、数値が読み取りにくくなります。 - テンプレートを再送する。Meta は、再送しても同じエラーになると説明しています。 - 品質の問題として扱う。この実験は、すべての企業に対して同じようにユーザーのグループへ適用されます。 - 送信リクエストのレスポンスだけを見る。130472 のステータスは、メッセージの Webhook を通じて届きます。 **130472 でブロックされたメッセージには課金されますか？** いいえ。Meta の実験に関するページによると、メッセージは送信されず、課金もされません。 **自社を実験のオプトアウトにできますか？** できません。Meta は例外やオプトアウトを用意しておらず、実験に終了日も定めていないと説明しています。 **エラー 130472 はユーティリティテンプレートにも影響しますか？** Meta はこの実験の対象をマーケティングテンプレートメッセージとして説明しており、ほかのカテゴリは挙げていません。 **それでもメッセージを届けるにはどうすればよいですか？** 別の手段でお客様に連絡し、メッセージを送ってもらってください。開いたカスタマーサービスウィンドウの中で、テンプレートを送信できます。 --- ## WhatsApp エラー 131005：アクセス拒否、権限不足 https://easycoexistence.com/ja/docs/whatsapp-error-131005 エラー 131005 は、アクセストークンに WhatsApp エンドポイントが必要とする権限がないことを示します。権限が一度も付与されていないか、後から削除されたことが原因です。Meta の説明は「権限が付与されていないか、削除されています」という内容です。対処は、アクセストークンデバッガーでトークンを確認し、不足している権限を付与するか、その権限を持つトークンに切り替えることです。 ### WhatsApp エラー 131005 とは何を意味しますか？ トークン自体は正規のものとして受理されていますが、エンドポイントが確認する権限を持っていない、という意味です。 Meta の Cloud API リファレンスでは、131005 の詳細テキストは「権限が付与されていないか、削除されています」と記載されています。Graph API のエラー 10 にもまったく同じ文が使われています。違いはコードの範囲だけです。10 は汎用的な Graph API のコードで、131005 は 131 で始まる WhatsApp 用のコードに含まれます。 文言が同じなので、診断も同じです。どちらの場合も Meta が示す対処は、アクセストークンデバッガーを使い、エンドポイントが要求する権限をアプリが持っているかを確認することです。 ### 通常、どの権限が不足していますか？ 多くの場合、2 つの WhatsApp 権限のどちらかです。どちらかは、呼び出しの内容によって決まります。 Meta の権限ガイドでは、用途ごとに分かれています。whatsapp_business_messaging は、あらゆる種類のメッセージの送信と、メッセージおよびステータスの Webhook の受信に必要です。whatsapp_business_management は、アカウントのメタデータ、メッセージテンプレートの管理、電話番号の一覧取得、分析、アカウントの Webhook に必要です。 管理用の権限だけで生成したトークンは、アカウントの読み取りやテンプレートの一覧取得はできますが、送信しようとした途端に失敗します。システムユーザーのトークンを生成するときは、Meta のアクセストークンガイドに従い、business_management、whatsapp_business_management、whatsapp_business_messaging をまとめて割り当ててください。 ### エラー 131005 はどのように修正しますか？ まずトークンを確認し、不足している部分だけを変更します。 debug_token エンドポイントを呼び出すか、トークンをアクセストークンデバッガーに貼り付けてください。scopes プロパティに、付与されているすべての権限が表示されます。これを、失敗したエンドポイントのリファレンスページと照らし合わせます。 権限が足りない場合は、その権限を含む新しいトークンを生成してください。トークンがパートナー経由のフローで発行されたものであれば、企業の所有者に権限をもう一度付与してもらいます。すべての権限が揃っているのにエラーが続く場合は、トークンの元になっているシステムユーザーに、対象の WhatsApp Business アカウントへのアクセスが付与されているかを確認してください。スコープがすべて揃っていても、そのアセットに割り当てられていないトークンはあり得ます。 - トークンの期限切れと決めつけること。期限切れでは 190 または 0 が返ります。このコードは、トークンは有効だが権限が足りない場合に返ります。 - 管理用の権限だけでトークンを生成し、そのまま送信に使うこと。送信には whatsapp_business_messaging が必要です。 - スコープだけを確認して終わりにすること。システムユーザーには、その WhatsApp Business アカウントへのアクセス付与も必要です。 **131005 はエラー 10 と同じものですか？** Meta のリファレンスでは同じ説明文です。131005 は WhatsApp 用の範囲、10 は Graph API 用の範囲に属します。 **設定後に権限が削除されることはありますか？** あります。Meta の説明には、一度も付与されていない権限だけでなく、削除された権限も明記されています。 **エラー 131005 は、スマートフォンの WhatsApp Business アプリにも影響しますか？** いいえ。影響するのは API のトークンだけです。スマートフォンのアプリはこれまでどおり使えます。 **エラー 131005 のあとは再試行すべきですか？** いいえ。同じトークンで再試行しても同じ結果になります。先に権限を修正してください。 --- ## WhatsApp エラー 131037: 表示名が未承認の 555 番号 https://easycoexistence.com/ja/docs/whatsapp-error-131037 エラー 131037 は、表示名がまだ承認されていない 555 ビジネス電話番号からメッセージを送信したことを示します。Meta の説明は「リクエストの送信に使用された 555 ビジネス電話番号には、承認済みの表示名がありません」というものです。555 番号は Meta が表示名を承認するまでメッセージを送信できないため、対処としては表示名を変更します。 ### 555 ビジネス電話番号とは何ですか？ 対象となる企業に、Meta が Embedded Signup を通じて提供する番号です。 Meta の Embedded Signup の概要によると、企業は 555 番号を最大 2 件まで取得できます。米国の国番号 +1 に市外局番 555 を組み合わせた番号で、自動的に認証され、別の WhatsApp Business アカウントへの移行や、WhatsApp Business Platform の外での利用はできません。 それ以外は通常のビジネス番号と同じで、料金ルールや品質評価の対象になります。ただし 1 つだけ条件が加わります。このエラーの原因もここにあり、555 番号はメッセージを送信する前に表示名の承認を受ける必要があります。 ### エラー 131037 はどう解決しますか？ 表示名を承認してもらう必要があります。実際には、審査を通る名前に変更することになります。 Meta が示す対処は 555 番号の表示名の変更で、WhatsApp Business の表示名の変更に関するヘルプセンターの記事が案内されています。WhatsApp Manager では「アカウントツール」、「電話番号」の順に進み、対象の番号の「プロフィール」タブを開いて、「表示名」セクションの「編集」を選びます。Meta の表示名ガイドラインに従ってください。却下された名前のままでは状況が変わりません。 Meta の表示名ガイドによると、名前の変更が承認された後、番号を再登録できる期間は 14 日間です。承認前に再登録しても効果はありません。 ### 表示名が承認されたかどうかはどう確認しますか？ 電話番号 ID に対して name_status フィールドをリクエストします。 Meta の表示名ガイドによると、verified_name フィールドには審査に出された名前の文字列が入るだけで、承認されたかどうかは分かりません。承認の状況が分かるのは name_status フィールドです。phone_number_name_update Webhook でも結果が通知され、decision に APPROVED または REJECTED が入ります。 名前が却下された場合、name_status は DECLINED になります。Meta の案内では、ガイドラインを確認して名前を編集するか、開発者サポートから異議申し立てを行います。ステータスが変わるまで、その 555 番号からの送信は引き続き 131037 を返します。 - verified_name を承認の証拠として読むこと。Meta によると、名前が承認されたかどうかを示すのは name_status だけです。 - 承認前に再登録すること。Meta によると、新しい名前が承認されるまで効果はありません。 - ガイドラインを読まずに名前を何度も変更すること。Meta は 30 日間に 10 回まで変更を認めています。 **エラー 131037 は通常のビジネス番号にも発生しますか？** いいえ。Meta の説明は、承認済みの表示名がない 555 ビジネス電話番号に限定されています。 **555 番号を別のアカウントに移せますか？** いいえ。Meta によると、555 番号は別の WhatsApp Business アカウントへ移行できません。 **名前が承認されたことはどうすれば分かりますか？** decision が APPROVED の phone_number_name_update Webhook が届き、name_status も APPROVED になります。 **表示名が却下された場合はどうすればよいですか？** Meta の表示名ガイドラインに沿って名前を編集するか、開発者サポートから異議申し立てを行ってください。 --- ## WhatsApp エラー 131057：ビジネスアカウントがメンテナンスモード https://easycoexistence.com/ja/docs/whatsapp-error-131057 エラー 131057 は、WhatsApp Business アカウントがメンテナンスモードにあり、短時間リクエストが拒否されていることを示します。Meta の説明は「Business Account is in maintenance mode.」です。Meta が挙げる理由の一つがスループットの更新で、最長 1 分かかります。リクエストの内容は変更せず、待ってから再試行してください。 ### WhatsApp エラー 131057 は何を意味しますか？ Meta が WhatsApp Business アカウントをメンテナンスモードにしており、その時点ではこのアカウント宛のリクエストを受け付けていない、という意味です。 Cloud API のリファレンスには、詳細テキストとして「Business Account is in maintenance mode」が記載されており、理由の一つとしてアカウントのスループット更新が挙げられています。ここで重要なのは「理由の一つ」という表現です。Meta は更新を考えられる原因として示しているだけで、唯一の原因とは述べていません。 リクエストに誤りはありません。メンテナンスが終われば、同じ呼び出しを変更せずに送っても成功すると想定されます。待つことが対処のすべてになる、数少ないコードの一つです。 ### スループットの更新でエラー 131057 が起きるのはなぜですか？ より高い送信レートへ移行する間、その番号が一時的に使えなくなるためです。 Meta のスループットに関するガイドによると、Cloud API は既定で毎秒最大 80 件のメッセージに対応し、自動更新により最大 1,000 件まで引き上げられます。更新には最長 1 分かかることがあり、その間は番号をプラットフォーム上で使用できず、API リクエストはすべて 131057 を返します。最初の更新後は、以降の引き上げはダウンタイムなしで行われます。 ガイドには適用条件も記載されています。Business Portfolio のメッセージ送信上限が無制限であること、直近 24 時間の移動期間内にカスタマーサービスウィンドウ外で 10 万人以上の一意のユーザーにメッセージを送信していること、品質評価が Medium 以上であることです。 ### エラー 131057 は Coexistence の番号にも当てはまりますか？ どの番号にも表示される可能性はありますが、スループットによる説明は Coexistence の番号にはあまり当てはまりません。 Meta のスループットに関するガイドでは、WhatsApp Business アプリと Cloud API の両方で使用している番号は、アプリとの互換性を保つため、スループットが毎秒 20 件に固定されるとされています。同じガイドで説明されている 1,000 件への自動更新は、既定のレベルにある番号が対象です。 そのため Coexistence の番号では、131057 を文字どおり「アカウントがメンテナンスモードにある」という意味で捉え、待ってから再試行してください。数分を大きく超えて続く場合は、番号を再接続せず、レスポンスに含まれる fbtrace_id を添えて Meta のサポートに問い合わせてください。 - リクエストを書き換えてしまう。リクエスト自体は有効なので、アカウントがメンテナンス中は変更しても効果がありません。 - 間隔を空けずに再試行する。更新中の 1 分間は、どの呼び出しも同じコードを返します。 - 番号を再接続してしまう。メンテナンスモードは Meta 側の状態で、企業側の操作なしで終了します。 **メンテナンスモードはどのくらい続きますか？** Meta によると、スループットの更新にかかる時間は最長 1 分です。それ以外のメンテナンス要因については、Meta は所要時間を公表していません。 **更新が完了したら通知されますか？** はい。番号の更新が完了すると、Meta は event に THROUGHPUT_UPGRADE を設定した phone_number_quality_update の Webhook を送信します。 **スループットが上がると料金も高くなりますか？** いいえ。Meta のスループットに関するガイドによると、更新は無料で、料金には影響しません。 **エラー 131057 は 130429 と関係がありますか？** 間接的に関係します。130429 は、スループットの上限を超える速さで送信したことを意味します。131057 は、そのスループットを引き上げている間に表示されることがあります。 --- ## WhatsApp エラー 132005（翻訳後のテキストが長すぎる） https://easycoexistence.com/ja/docs/whatsapp-error-132005 エラー 132005 は、送信しようとしたメッセージテンプレートのテキストが、使用した言語版で長すぎることを示します。Meta の説明は「Translated text is too long.」です。Meta の案内では、WhatsApp Manager でメッセージテンプレートが翻訳されているかを確認し、そのステータスを見直します。メッセージテンプレートの本文は最大 1,024 文字、フッターは最大 60 文字です。 ### WhatsApp エラー 132005 は何を意味しますか？ 送信しようとした言語版のテキストがプラットフォームの許容量を超えたため、メッセージテンプレートの送信に失敗したことを意味します。 Meta は 132005 をメッセージテンプレート関連のエラーに分類し、詳細テキストを「Translated text is too long.」としています。対処法は、WhatsApp Manager でメッセージテンプレートが翻訳されているかを確認し、ステータスの確認方法についてはメッセージテンプレートの品質に関するドキュメントを参照することです。 ヒントは「翻訳」という言葉です。メッセージテンプレートは言語ごとに存在し、失敗するのは送信リクエストの言語コードに対応する版です。最初に作成して確認した版とは限りません。 ### エラー 132005 はどう修正しますか？ WhatsApp Manager でメッセージテンプレートを開き、送信している言語版を確認してください。 まず、リクエストの言語コードに対応する翻訳が存在し、そのステータスが送信可能であることを確認します。次に、Meta のコンポーネント上限に照らして長さを確認します。本文は最大 1,024 文字、フッターは最大 60 文字です。翻訳は原文より長くなりやすいため、ある言語では収まるメッセージテンプレートが、別の言語では上限を超えることがあります。 翻訳が長すぎる場合は、WhatsApp Manager でその言語版を短く編集してください。同じ言語で同じメッセージテンプレートを編集せずに再送しても、同じように失敗します。 ### 多言語のメッセージテンプレートで 132005 を防ぐには？ 申請する前に、最初の言語だけでなく、すべての言語版を上限と照らして確認してください。 メッセージテンプレートを作成するツールで簡単な文字数チェックを行えば、ほとんどのケースを防げます。各翻訳の本文とフッターの文字数を数え、1,024 と 60 に照らして比較してください。本文に変数がある場合は余裕を持たせます。送信時に埋め込まれる値も、お客様が受け取るメッセージの一部だからです。 送信ロジックの言語コードは、実際に存在する翻訳とひも付けておきましょう。メッセージテンプレートにない言語を指定した場合は別のエラー 132001 になります。両者を区別しておくと、ログが読みやすくなります。 - 原文の言語だけを確認すること。失敗するのは、リクエストの言語コードに対応する翻訳版です。 - 編集せずに再送すること。再送してもテキストの長さは変わりません。 - 132001 と混同すること。このコードは、その言語にメッセージテンプレートが存在しないか、承認されていないことを示します。 **エラー 132005 は変数が原因ですか？** Meta の説明は、翻訳後のテキストが長すぎることを指しています。まず翻訳の長さを確認し、変数の値が入る余裕も見込んでください。 **メッセージテンプレートの本文の上限は？** Meta のメッセージテンプレートのコンポーネントのリファレンスでは、本文は最大 1,024 文字と定められています。 **翻訳はどこで確認できますか？** WhatsApp Manager で該当のメッセージテンプレートを開き、リクエストの言語コードに対応する言語版を確認してください。 **エラー 132005 と 132001 は同じですか？** いいえ。Meta は 132001 を、指定した言語にメッセージテンプレートが存在しないか、承認されていない状態と説明しています。 --- ## WhatsApp エラー 133000：以前の登録解除の試行が失敗しました https://easycoexistence.com/ja/docs/whatsapp-error-133000 エラー 133000 は、以前に電話番号の登録解除を試みて失敗したため、その問題が解消するまで番号を登録できないことを示します。Meta の説明は「A previous deregistration attempt failed.」です。Meta が示す対処法は、番号をもう一度登録解除してから登録することです。どちらのエンドポイントも、1 つの番号につき 72 時間のスライディングウィンドウで 10 リクエストまでに制限されています。 ### WhatsApp エラー 133000 は何を意味しますか？ この番号について、未完了の登録解除がプラットフォームに記録されたままになっており、その上から番号を登録することはできない、という意味です。 Meta は 133000 に「A previous deregistration attempt failed」という詳細テキストを付け、対処法として「登録の前にもう一度番号を登録解除する」と一行で示しています。そのため、原因は以前の登録解除の呼び出しにあっても、エラーは登録の呼び出しで表示されることがよくあります。 登録解除は、電話番号 ID の登録解除エンドポイントへ POST して行います。Meta の登録ガイドによると、登録解除をすると再度登録するまで番号は Cloud API で使えなくなりますが、番号やメッセージ履歴が削除されることはありません。 ### エラー 133000 はどう解決しますか？ 登録解除をやり直し、成功したことを確認してから登録します。 登録解除の呼び出しが成功すると、success が true で返ります。このレスポンスを確認できてから、messaging_product フィールドと、その番号の 6 桁の 2 段階認証 PIN を付けて登録を呼び出してください。 登録解除の呼び出しには whatsapp_business_management 権限が必要です。Meta の登録ガイドによると、この権限がないリクエストはエラー 200 を返すため、同じ種類の失敗が続いていると誤解しやすくなります。登録解除そのものが失敗し続ける場合は、次のリクエストを送る前に各レスポンスの details の値を読んでください。どの試行も、次に説明する上限の回数に数えられるためです。 ### なぜここで試行回数の上限が重要なのですか？ このエラーの解決自体が複数回の試行になり、Meta がその回数に上限を設けているからです。 登録ガイドでは、登録と登録解除の両方のエンドポイントについて、企業の番号 1 つにつき 72 時間のスライディングウィンドウで 10 リクエストまでと定められています。超えるとエラー 133016 が返り、その番号は以後 72 時間、その操作ができなくなります。 失敗後に登録解除と登録を繰り返すスクリプトは、数秒で上限を使い切り、番号を 3 日間使えない状態にしてしまうことがあります。試行は一回ずつ意図して行い、レスポンスをログに残し、2、3 回失敗したら自動で続けずに手を止めて原因を調べてください。 - 先に登録解除をせず、もう一度登録を呼び出す。Meta の対処法では、登録の前に登録解除を完了させる必要があります。 - 登録と登録解除の呼び出しを自動でループさせる。上限は 72 時間で 10 リクエストで、超えると番号がブロックされます。 - whatsapp_business_management なしで登録解除する。エラー 200 が返り、番号の本当の状態が見えなくなります。 **登録解除をすると番号は削除されますか？** いいえ。Meta の登録ガイドによると、登録解除で番号やメッセージ履歴が削除されることはありません。 **Coexistence の番号を API で登録解除できますか？** いいえ。Meta によると、Cloud API と WhatsApp Business アプリの両方で使用中の番号には、登録解除エンドポイントを使えません。 **10 回試行するとどうなりますか？** API は 133016 を返し、その番号は以後 72 時間、その操作ができなくなります。 **もう一度登録するのに PIN は必要ですか？** はい。2 段階認証が有効な場合、登録にはその番号の 6 桁の 2 段階認証 PIN が必要です。 --- ## WhatsApp エラー 133004: サーバーが一時的に利用できない状態 https://easycoexistence.com/ja/docs/whatsapp-error-133004 エラー 133004 は、リクエストを処理するサーバーが一時的に利用できなかったことを示します。Meta の説明は「Server is temporarily unavailable.」です。リクエスト自体に問題はありません。Meta の案内では、再試行の前に WhatsApp Business Platform のステータスページを確認し、レスポンスの `details` の値を読んだうえで、間隔を空けて再試行します。 ### WhatsApp エラー 133004 は何を意味しますか？ サーバーが利用できなかったため、その時点ではプラットフォームがリクエストを処理できなかったことを意味します。 Meta は Cloud API のエラーリファレンスで 133004 を挙げ、details の説明文を「Server is temporarily unavailable.」としています。ポイントは「一時的」という点です。アクセストークンも電話番号もメッセージも拒否されているわけではなく、少し時間を置けば同じリクエストが成功することがあります。 このコードは 133 番台に含まれます。133 番台の多くは電話番号の登録と登録解除に関するもので、登録の呼び出し時によく見かけます。ただし Meta は登録時だけに限定していません。どこで表示されても、サーバー側の状態として扱ってください。 ### 再試行の前に何を確認すべきですか？ 確認するのは次の 2 点です。どちらも Meta 自身の対処方法に書かれています。 1 つ目は、metastatus.com にある WhatsApp Business Platform のステータスページです。Meta が障害を公表している間は、解消されるまで再試行しても意味がありません。自社のログを調べるより、このページのほうが早く答えが分かります。 2 つ目は、レスポンスの `error_data` に含まれる `details` の値です。Meta のエラーリファレンスでは、`details` はエラーの最も可能性の高い理由であり、対処方法が添えられることもあると説明されています。このコードについては、再試行の前に確認するよう Meta が明記しています。ステータスページに障害がなく、`details` にも待ち時間の指示がない場合は、すぐに再試行せず、間隔を徐々に延ばしながら再試行してください。 ### 133004 は他の一時的なエラーとどう違いますか？ Meta は、一時的に利用できない状態を示すコードをいくつか挙げています。ログ上では区別しておくと便利です。 コード 1 は無効なリクエストまたはサーバーエラーの可能性、コード 2 はダウンタイムや過負荷による一時的な問題、131016 はサービスが一時的に利用できない状態と説明されています。133004 はサーバーを名指ししています。 どのコードでも対処はほぼ同じです。プラットフォームの状態を確認し、`details` の値を読み、間隔を空けてから再試行します。それでも正確なコードは記録してください。ある時間帯に同じコードが集中していれば、「API が止まっていた」という漠然としたメモよりも、Meta のサポートにはるかに有益な情報になります。 - 短い間隔で即座に再試行を繰り返すこと。停止中のサーバーは、次のミリ秒も停止したままです。 - `details` の値を読み飛ばすこと。Meta は再試行の前に読むよう案内しており、理由が書かれている場合があります。 - 回避しようとしてリクエストの内容を変えること。エラーの原因はリクエストにはありません。 **エラー 133004 は自分の側の問題ですか？** いいえ。Meta はサーバーが一時的に利用できない状態だと説明しています。リクエストが原因ではありません。 **WhatsApp Business Platform のステータスページはどこにありますか？** Meta はエラーコードのリファレンスから metastatus.com/whatsapp-business-api へリンクしています。 **再試行までどのくらい待てばよいですか？** Meta は決まった時間を示していません。`details` の値とステータスページを確認し、間隔を徐々に延ばしながら再試行してください。 **問題が続く場合、Meta のサポートには何を送ればよいですか？** エラーのレスポンスに含まれる `fbtrace_id` です。Meta は、エラーのデバッグに役立つ場合があるとしています。 --- ## WhatsApp エラー 133009: 2 段階認証 PIN の入力が速すぎる https://easycoexistence.com/ja/docs/whatsapp-error-133009 エラー 133009 は、2 段階認証 PIN の試行が Meta の受け付ける速度を超えて届いたことを示します。Meta の説明は「Two-step verification PIN was entered too quickly」です。PIN が正しいか誤っているかは関係ありません。再試行する前にレスポンスの `details` の値を読み、そこに示された待ち時間が過ぎてから次の試行を送ってください。 ### WhatsApp のエラー 133009 は何を意味しますか？ この番号への PIN の試行が短い間隔で続いており、Meta が最新の試行を内容の判定なしに拒否した、という意味です。 Cloud API リファレンスでは、133009 の詳細テキストは「Two-step verification PIN was entered too quickly」で、指示は 1 つだけです。再試行する前にレスポンスの `details` の値を確認してください。 このコードは隣り合う 2 つのコードの間に位置します。133005 は PIN が正しくないことを示し、133008 はその番号に対する PIN の推測が多すぎることを示します。133009 が問題にするのは試行の速さだけです。そのため、`register` 呼び出しの再試行ループのように、プロセスが PIN の試行を立て続けに送ると発生します。 ### エラー 133009 はどう解決しますか？ 速度を落とし、推測をやめてください。 次の試行の前に、`error_data` の `details` の値を読んでください。Meta のリファレンスでは、`details` はエラーの最も可能性が高い理由と説明されており、このコードでは Meta が最初に確認するよう求めている項目です。 そのうえで、次の試行には誰かが実際に知っている PIN を使ってください。誰も知らない場合は、Meta の 2 段階認証ガイドにある WhatsApp Manager でのリセットを行います。電話番号の設定を開き、「2 段階認証」を選んで「PIN を変更」をクリックしてください。新しい PIN を決めるほうが、推測を重ねて 133008 に至り、さらに長く待つよりも早く済みます。 ### PIN はどこで使われますか？ Cloud API 用に番号を登録するときと、その前後のいくつかのアカウント操作で使われます。 Meta の 2 段階認証ガイドによると、この設定では電話番号の登録時に 6 桁の PIN が必要です。2 段階認証が有効な場合、登録の呼び出しでは PIN が必須フィールドになります。Meta の電話番号ガイドには、PIN の変更時と、プラットフォームから番号を削除するときにも PIN が必要だと書かれています。 使う機会が少ないため、PIN は忘れられがちです。番号を最初に設定した担当者個人ではなく、企業のほかのアカウント情報と一緒に保管してください。 - `register` の呼び出しをループで即座に再試行する。このコードが報告しているのは、まさにこうした短時間の PIN 試行です。 - 再試行のたびに違う PIN を推測する。推測が多すぎると 133009 から 133008 に移ります。 - `details` の値を無視する。Meta は、再試行の前に確認すべき項目としてこの値を挙げています。 **エラー 133009 は PIN が間違っているという意味ですか？** 必ずしもそうではありません。試行が速すぎたという意味です。PIN が正しくない場合は 133005 として報告されます。 **133009 の後はどのくらい待てばよいですか？** Meta は固定の待ち時間を公表していません。再試行する前に、レスポンスの `details` の値を読んでください。 **API で 2 段階認証を無効にできますか？** できません。Meta の 2 段階認証ガイドには、無効にするエンドポイントはないと記載されています。代わりに新しい PIN を設定できます。 **忘れた PIN はどうリセットしますか？** WhatsApp Manager で電話番号の設定を開き、「2 段階認証」を選んで「PIN を変更」をクリックしてください。 --- ## WhatsApp エラー 133015：番号が最近削除され、削除が未完了 https://easycoexistence.com/ja/docs/whatsapp-error-133015 エラー 133015 は、登録しようとしている電話番号が最近削除され、その削除がまだ完了していないことを意味します。Meta の説明は「登録しようとしている電話番号は最近削除され、削除はまだ完了していません」です。公式に示されている対処法は、5 分待ってから登録リクエストを再試行することです。 ### WhatsApp エラー 133015 とは何ですか？ 同じ番号の削除処理がまだ続いている間に、登録リクエストが届いたことを意味します。 Meta のリファレンスには詳細テキストとして「登録しようとしている電話番号は最近削除され、削除はまだ完了していません」と記載されています。対処法も明確で、リクエストを再試行する前に 5 分待つことです。 よくある原因は番号の移行です。ある WhatsApp Business アカウントから番号を削除してすぐに別のアカウントへ登録したり、やり直すために削除して再追加したりすると、バックグラウンドで最初の処理が終わる前に 2 つ目のリクエストが Meta に届いてしまいます。 ### ビジネス用の電話番号はどのように削除しますか？ 削除できるのは WhatsApp Manager 上のみで、実行できるのは Business Portfolio の管理者だけです。 Meta の電話番号に関するガイドによると、ビジネス用の電話番号は API では削除できません。削除は WhatsApp Manager で行い、接続済みの番号を削除するには 2 段階認証の PIN が必要です。また、過去 30 日以内に有料メッセージを送信した番号は、最後の送信から 30 日が経過するまで削除できません。 削除と登録解除は別の操作です。Meta の登録ガイドでは、登録解除は番号を Cloud API で使えなくするだけで、番号やメッセージ履歴は削除されないと説明されています。エラー 133015 が扱うのは削除のみです。 ### 番号を移行するとき、エラー 133015 を避けるにはどうすればよいですか？ 待ち時間は、後から気づくのではなく、手順にあらかじめ組み込んでおきましょう。 番号を削除したら、register を呼び出す前に最低 5 分間は間を空けます。それでも 133015 が返る場合は、すぐに再試行せず、もう一度待ってください。 慎重に待つべき理由は登録回数の上限です。Meta は register エンドポイントへのリクエストを、1 つの番号につき 72 時間の移動期間内で 10 回までに制限しています。上限を超えると API は 133016 を返し、以後 72 時間は登録がブロックされます。133015 に対して数秒おきに再試行するループを組むと、削除が終わる前にこの 10 回を使い切ってしまうことがあります。 - register の呼び出しを数秒おきに再試行する。呼び出しはすべて 72 時間あたり 10 回の上限に数えられます。 - 削除と登録解除を混同する。登録解除では番号は削除されず、このコードが示すのは削除の状態です。 - API で番号を削除しようとする。Meta が削除に対応しているのは WhatsApp Manager のみです。 **エラー 133015 が出たら、どのくらい待てばよいですか？** Meta は、登録リクエストを再試行する前に 5 分待つよう案内しています。 **API でビジネス用の電話番号を削除できますか？** できません。Meta の電話番号に関するガイドでは、削除は WhatsApp Manager でのみ可能とされています。 **番号をどうしても削除できないのはなぜですか？** 過去 30 日以内に有料メッセージを送信した番号は、Meta により削除がブロックされます。最後の送信から 30 日後に削除できます。 **再試行の回数が多すぎるとどうなりますか？** 72 時間以内に register リクエストが 10 回に達すると、API は 133016 を返し、72 時間は登録がブロックされます。 --- ## WhatsApp エラー 135000: リクエストパラメーターの不明なエラー https://easycoexistence.com/ja/docs/whatsapp-error-135000 エラー 135000 は、リクエストパラメーターに不明なエラーがあり、メッセージの送信に失敗したことを示します。Meta の説明は「Message failed to send because of an unknown error with your request parameters.」です。Meta は、エンドポイントのリファレンスで正しい構文を確認すること、そしてエラーが繰り返し発生する場合はカスタマーサポートに連絡することを案内しています。 ### WhatsApp エラー 135000 は何を意味しますか？ プラットフォームがメッセージを送信できず、正確な理由は特定できないものの、問題はリクエストパラメーターにあると判断した、という意味です。 Meta のリファレンスでは、135000 の詳細テキストは「Message failed to send because of an unknown error with your request parameters.」です。対処法は、エンドポイントのリファレンスで呼び出しの構文が正しいかを確認することです。コードが繰り返し返る場合は、カスタマーサポートに連絡してください。 この点が 131000 との違いです。131000 は、パラメーターには触れずに不明なエラーとして説明されており、対処はまず再試行することから始まります。 ### 問題のあるパラメーターはどう見つけますか？ 送信したリクエストボディそのものを、エンドポイントのリファレンスとフィールドごとに見比べてください。 エラーと一緒にペイロード全体をログに残しましょう。原因となる値はメッセージごとに変わるものであることが多く、たとえば形式が想定外の電話番号、テキストが必要な箇所の空文字列、フィールドの位置が誤っているネストされたオブジェクトなどです。そのうえで、error_data の details の値を読んでください。Meta はこれをエラーの最も可能性の高い理由と説明しています。 135000 で失敗したペイロードが、変更後に成功した場合は、両方のバージョンを残しておきましょう。その差分が答えであり、次回の送信前に何を検証すべきかを教えてくれます。 ### エラー 135000 で Meta サポートに連絡するのはどんなときですか？ リクエストがリファレンスどおりであるにもかかわらず、コードが繰り返し返ってくるときです。 Meta は、135000 が解消しない場合の次の手順としてサポートへの連絡を挙げています。エラーレスポンスの fbtrace_id を必ず含めてください。Meta によると、エラーの調査に役立つ可能性があります。あわせて、タイムスタンプ、エンドポイント、認証情報を除いたリクエストボディも伝えましょう。 チケットを作成する前に、同じリクエストが毎回失敗するかを確認してください。1 度失敗しても、1 分後に同じ内容で成功する場合は、パラメーターではなくプラットフォーム側の問題を疑います。その確認には、WhatsApp Business Platform の Meta ステータスページが早道です。 - 同一のリクエストを何度も再試行する。Meta は問題の所在をパラメーターとしているため、同じペイロードは同じように失敗しやすいです。 - エラーだけをログに残す。リクエストボディがないと、原因のパラメーターを特定できません。 - fbtrace_id なしでサポートに連絡する。Meta は、エラーの調査に役立つ ID としてこれを挙げています。 **エラー 135000 とエラー 131000 は同じですか？** いいえ。131000 は原因が示されていない不明なエラーです。135000 は、Meta がリクエストパラメーターに起因するとしている不明なエラーです。 **エラー 135000 とエラー 100 は同じですか？** いいえ。エラー 100 は、未対応または綴りの誤ったパラメーターを指します。135000 は、パラメーターが原因で、Meta が特定できないエラーが起きたことを示します。 **135000 の後に再試行すべきですか？** そのままでは再試行しないでください。まずリクエストをエンドポイントのリファレンスと照合してください。 **Meta サポートには何を送ればよいですか？** レスポンスの fbtrace_id、エンドポイント、発生時刻、認証情報を除いたリクエストボディです。 --- ## EasyCoexistence と Z-API の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-z-api Z-API は、インスタンス単位で販売されているブラジル発の WhatsApp API です。WhatsApp Web が端末をリンクするのと同じように、QR コードをスキャンして番号を接続します。EasyCoexistence は Coexistence を通じて、番号を Meta 公式の Cloud API に接続します。そのため WhatsApp Business アプリはそのまま使え、接続方法が WhatsApp の利用規約に反することもありません。 ### WhatsApp への接続方法の違い このページの他の違いはすべてここから生じるため、最初に説明します。 - Z-API:: 同社のドキュメントには、WhatsApp Web と同様に、接続には QR コードのスキャンまたは電話番号の入力が必要だと書かれています。また同社サイトは、公式の Cloud API は別の経路であり、自社はそれに対する市場の代替手段だと説明しています。 - EasyCoexistence:: Meta の Cloud API を使い、認証情報は Meta が企業自身の WhatsApp Business Account に対して発行します。接続は Meta の Embedded Signup を通じて行います。番号は API 用の番号として登録され、同じ電話機で WhatsApp Business アプリも引き続き使えます。 ### 番号ごとの料金 どちらも番号単位の課金なので、単位が揃う数少ない比較の一つです。 - Z-API:: 同社サイトの公開情報では、Ultimate プランはインスタンス 1 件あたり月額 R$ 99,99、Partner プランは最低 10 インスタンスからで 1 件あたり R$ 89,99 です。トライアルは 2 日間です。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 から（1 件から 5 件まで）、6 段階の料金帯を経て、番号を追加するにつれて 1 件あたり US$ 1 まで下がります。最初の 3 日間は無料です。Meta のメッセージ料金は Meta から企業へ直接請求され、上乗せはありません。 ### WhatsApp が措置を取った場合、番号はどうなるか インスタンス単価だけでは見えないリスクです。 - Z-API:: リンク済み端末のセッションは、WhatsApp のビジネス向け規約が自動化されたビジネスメッセージ用に認めている経路ではありません。この方法で接続したアカウントは、制限や停止を受ける可能性があります。 - EasyCoexistence:: 接続は Meta 自身の機能であり、Meta 自身のフローを通じて、独立した Meta Tech Provider が行います。番号の接続方法について、WhatsApp が取り締まれる点はありません。 ### 電話機を使い続けられるか どちらの製品を使う小規模な企業でも、多くは電話機からお客様に返信しています。そのため、日々の運用がここで決まります。 - Z-API:: インスタンスは WhatsApp Web と同じ意味でのリンク済みセッションなので、そのリンクが生きている間しか続きません。同社サイトでは、Meta の Coexistence 機能には触れていません。 - EasyCoexistence:: Coexistence こそが製品の中心です。チームは WhatsApp Business アプリを使い続け、API は同じ番号で動作します。接続は監視されており、Meta の 14 日ルールのような切断が起きた場合も、発生してすぐに通知されます。 - QR コードでリンクしたインスタンスと Cloud API を、料金が違うだけの同じ製品だと考えること。両者は異なる経路で WhatsApp に接続します。 - 企業のメイン番号を、リンク済み端末のセッションで運用すること。停止されると、その番号の WhatsApp 上の存在ごと失われます。 - Cloud API ではメッセージテンプレートが有料であることを見落とすこと。これは Meta から企業へ請求され、どちらのサブスクリプションにも含まれません。 **Z-API は公式の WhatsApp API ですか？** いいえ。同社サイトは、公式の Cloud API を Meta 経由の経路、Z-API を市場の代替手段と説明しています。また同社のドキュメントには、インスタンスは WhatsApp Web のように接続すると書かれています。 **どちらが安いですか？** 当社のほうが低料金です。Z-API は 1 インスタンスあたり月額 R$ 99,99 と公開しています。当社は接続済みの番号 1 件あたり月額 US$ 9 から（5 件まで）で、番号を追加するにつれて US$ 1 まで下がります。 **御社を使う場合、メッセージテンプレートの承認は必要ですか？** 24 時間のウィンドウ外で会話を開始するメッセージのみ必要です。これは公式プロバイダーすべてに適用される Meta のルールです。ウィンドウ内の返信はフリーテキストで送れます。 **Z-API から EasyCoexistence へ番号を移せますか？** はい。セッションのリンクを解除し、WhatsApp Business アプリを使い続けたまま、Embedded Signup で番号を接続します。アプリのバージョン 2.24.17 以降と、最近の実際の利用履歴が必要です。 --- ## EasyCoexistence と Blip の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-blip Blip はブラジル発の会話型プラットフォームで、WhatsApp などのチャネルでチャットボットの構築とカスタマーサービスの運用ができます。有料プランの料金は営業経由での案内です。EasyCoexistence は WhatsApp への接続そのものを提供します。Coexistence により Meta の Cloud API に接続し、料金は接続済みの番号 1 件あたりで公開しています。WhatsApp Business アプリも、そのまま携帯電話で使えます。 ### それぞれの製品の位置づけ どちらも Meta の公式 API を使います。その上で提供しているものが異なります。 - Blip:: 独自のフローや自然言語処理を備えたボットを構築し、有人対応のサービスデスクも含めて、WhatsApp、Instagram、Messenger などのチャネルで運用するプラットフォームです。料金ページでは、Meta Business Solution Provider の公式パートナーであると記載されています。 - EasyCoexistence:: WhatsApp Business アプリで既に使っている番号と Meta の Cloud API をつなぐ接続サービスで、その接続を継続的に監視します。メッセージは、CRM、n8n、自社コード、MCP 経由の AI エージェントなど、企業が既に使っているシステムに届きます。 ### 料金 違いは、誰かに問い合わせる前に料金を確認できるかどうかです。 - Blip:: エージェント 2 名までの無料プランがあり、月間の会話数に制限があります。有料プランの料金はページに載っておらず、詳細は問い合わせる形です。金額は営業との話し合いで決まります。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 から、番号を追加するほど US$ 1 まで下がります。1〜5 件の場合は US$ 9 で、最初の 3 日間は無料です。Meta のメッセージ料金は企業ご自身のアカウントに請求され、上乗せは一切ありません。 ### 携帯電話のアプリは使い続けられるか 携帯電話で顧客対応をしている小規模な企業にとって、多くの場合まず気になる点です。 - Blip:: 料金ページには Coexistence への言及がありません。接続中も番号を WhatsApp Business アプリで使い続けられるかどうかは、このページに頼らず、Blip に直接確認してください。 - EasyCoexistence:: はい、設計上そうなっています。Coexistence では同じ番号で WhatsApp Business アプリが引き続き動作し、直近のチャット履歴も同期されます。API はその裏で並行して動きます。Coexistence の番号のスループットは 1 秒あたり 20 メッセージです。 ### ボットのロジックはどこにあるか 自動化はどこかで動かす必要があり、その選択が何に縛られるかを左右します。 - Blip:: Blip の中です。フロー、ボット、サービスデスクは同社のプラットフォーム上で構築・運用します。それが Blip の販売する製品です。 - EasyCoexistence:: 既に使っている開発環境の中です。Meta はメッセージの Webhook をお客様のシステムに直接届けます。会話の内容を当社側で保存することはありません。MCP サーバーを使えば、Claude、ChatGPT、Cursor、Codex からその番号でメッセージを送信できます。 - ボットプラットフォームの見積もりと接続料金を、項目ごとに単純比較してしまうこと。前者にはビルダーとサービスデスクが含まれています。 - Meta のパートナーならどこでも WhatsApp Business アプリが使い続けられると思い込むこと。Coexistence への対応と有効化が必要です。 - Meta 自体のメッセージ料金を忘れること。どちらの製品を選んでも、Meta から請求されます。 **Blip は料金を公開していますか？** 公開されているのは無料プランのみで、エージェント 2 名まで、会話数に制限があります。有料プランの料金は料金ページに載っていません。 **どちらが安いですか？** 当社は料金を公開し、Blip は公開していません。そのため確認できるのは当社の料金です。接続済みの番号 1 件あたり月額 US$ 9 から、台数が増えると US$ 1 まで下がり、エージェント数の上限もありません。 **EasyCoexistence でチャットボットを作れますか？** はい。ただし、既にお使いのツールの中で作ります。メッセージは Webhook、n8n、Make、または MCP 経由の AI エージェントに届き、ロジックはそちら側に置きます。 **EasyCoexistence は Meta の製品ですか？** いいえ。当社は独立した Meta Tech Provider で、Meta 公式の Embedded Signup と Cloud API を利用しています。 --- ## EasyCoexistence と Digisac の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-digisac Digisac はブラジル発のマルチチャネル型の顧客対応プラットフォームで、料金は個別見積もりにより月額 R$ 197 から。公式の WhatsApp API を Gupshup と 360dialog 経由で提供し、Coexistence もそれらを通じて対応します。EasyCoexistence は番号そのものを接続する Meta Tech Provider で、番号ごとの料金を公開しており、間にプラットフォームは入りません。 ### 料金の決まり方 一方は見積もり、もう一方は料金表です。この違いが、その後のすべてに影響します。 - Digisac:: 固定プランはありません。同社のページによると、開始価格は R$ 197 で、担当者数、チャネル数、AI モジュールなどの機能、連携の内容に応じて変わり、営業チームが見積もりにまとめます。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9（1 件から 5 件）で、6 段階の料金帯を経て、番号を追加するほど 1 件あたり US$ 1 まで下がります。担当者数を数える必要も、モジュールを追加する必要もありません。最初の 3 日間は無料トライアルです。 ### Meta との間にいるのは誰か 番号の背後にある企業の連なりが、不具合のときに誰が直せるかを決めます。 - Digisac:: このプラットフォームは、Meta のパートナーである Gupshup と 360dialog を通じて API を運用しています。同社の Coexistence に関する記事によると、有効化は 360dialog などの公式プロバイダーを通じて行われ、Digisac はその手続きで顧客を支援します。 - EasyCoexistence:: 誰もいません。当社は独立した Meta Tech Provider です。企業は Meta 自身の Embedded Signup を通じて、自社の WhatsApp Business アカウントで登録し、Meta の Webhook は企業のシステムに直接届きます。 ### チームが作業する場所 顧客対応プラットフォームと接続とでは、日々の業務で変わる部分が異なります。 - Digisac:: WhatsApp、Instagram、Telegram、Messenger、メール、Web チャットを一元化する共有型の顧客対応プラットフォームで、会話の振り分け、社内チャット、営業ファネルを備えています。チームはその中で作業します。 - EasyCoexistence:: 新たにログインするものはありません。チームは WhatsApp Business アプリをそのまま使い、自動化、CRM、AI エージェントは API を通じて同じ番号で動作します。 ### 番号が使えるようになるまでの時間 小規模な企業では、この点だけで決めることもよくあります。 - Digisac:: まず商談と見積もりがあり、その後にプロバイダーとの有効化が行われます。同社のページでは、CNPJ、Meta Business Manager、ポリシーの遵守が前提条件に挙げられています。 - EasyCoexistence:: 通常は Embedded Signup で 2 分もかかりません。Facebook でログインし、番号を入力して、アプリで QR コードを読み取るだけです。番号が接続された時点から監視が始まります。 - Digisac の開始価格を、番号ごとの料金と比べてしまうこと。Digisac の料金は、担当者数、チャネル数、モジュールに応じて増えていきます。 - Coexistence をプラットフォームの機能だと思い込むこと。Coexistence は Meta の機能で、Meta 側のプロバイダーを通じて有効になります。 - Meta の料金を予算に入れ忘れること。どちらを選んでも、Meta の料金は Meta から請求されます。 **Digisac は Coexistence に対応していますか？** はい。同社の記事によると、360dialog などの公式プロバイダーを通じて有効化され、Digisac がその手続きを支援します。 **どちらが安いですか？** 番号が 1 件なら、当社の方が安価です。月額 US$ 9 に対し、Digisac の開始価格は R$ 197 で、担当者数、チャネル数、モジュールに応じて上がります。当社の料金は、番号が増えるほど下がります。 **御社では共有受信トレイを使えなくなりますか？** 当社は共有受信トレイを販売していません。チームは WhatsApp Business アプリをそのまま使い、そのほかの用途はお客様が選んだツールで運用します。 **Meta への支払いは誰が行いますか？** 企業が、自社の WhatsApp Business アカウントで Meta に直接支払います。当社が Meta の料金に上乗せすることはありません。 --- ## EasyCoexistence と Octadesk の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-octadesk Octadesk はチャットボット、AI エージェント、ヘルプデスクを組み合わせたブラジル発のカスタマーサービス基盤です。料金は 3,000 件の会話で月額 R$ 2.499 から、さらに導入コンサルティングが必須です。EasyCoexistence は、WhatsApp Business アプリで使っている番号を Coexistence で Meta の Cloud API に接続します。番号ごとの料金は公開されており、会話数の上限も初期費用もありません。 ### 月額料金は何に対する料金か 課金の単位が違います。その差は、お客様からのメッセージが増えるほど広がります。 - Octadesk:: 会話数でプランが決まります。One は 3,000 件で月額 R$ 2.499、Flow は 5,500 件で R$ 4.399、Nexus は 9,000 件で個別見積もりです。ヘルプデスクのユーザーは別途ユーザー数に応じて課金され、どのプランも導入コンサルティングが必須で、料金は個別見積もりです。 - EasyCoexistence:: 接続済みの番号ごとに一律の料金です。1 から 5 件までは月額 US$ 9 で、番号を追加するにつれて 1 件あたり US$ 1 まで下がります。会話が 1 万件ある月も、静かな月も料金は同じです。Meta のメッセージ料金は Meta から直接請求されます。 ### それぞれの製品の位置づけ どちらも番号を公式 API に載せます。違うのは、その上に何が作られているかです。 - Octadesk:: サービス全体を担う基盤です。チャットボット、AI エージェント、SLA とチケット履歴を備えたヘルプデスク、WhatsApp の一斉送信を備え、各プランに公式 WhatsApp API の番号 1 件が含まれます。 - EasyCoexistence:: 接続とその監視に特化しています。番号は WhatsApp Business アプリに残り、API も同時に動きます。メッセージは、企業が既に使っているツールに届きます。MCP サーバー経由で AI エージェントにも届けられます。 ### 2 件目や 10 件目の番号を追加するとき 代理店や複数拠点を持つ企業が、まず最初に確認する点です。 - Octadesk:: 各プランに含まれる公式 WhatsApp API の番号は 1 件です。追加の番号の料金は、料金ページには掲載されていません。 - EasyCoexistence:: 1 アカウントで番号数は無制限で、それぞれ段階ごとの料金です。番号が増えるほど 1 件あたりの料金は下がり、6 件目からは US$ 7、番号を追加するにつれて US$ 1 まで下がります。 ### スマートフォンでそのまま使い続けられるか 小規模なチームが仕事の進め方を変えなければならないかどうかを左右する点です。 - Octadesk:: 料金ページには Coexistence についての記載がありません。API に載せた後も番号を WhatsApp Business アプリに残せるかどうかは、Octadesk に直接ご確認ください。 - EasyCoexistence:: 残せます。当社が接続するのは Coexistence のみです。アプリのチャットはそのまま残り、約 6 か月分の履歴を同期でき、同じ番号で API も動きます。接続は常に監視されており、切断はすぐに通知されます。 - 会話数を数えずにプラン料金だけを比べてしまうこと。Octadesk のプランには会話数の上限がありますが、接続料金にはありません。 - 導入コンサルティングを予算に入れないこと。Octadesk ではどのプランでも必須で、料金は個別見積もりです。 - プランにメッセージテンプレートの料金が含まれると思い込むこと。Meta はそれを企業に直接請求します。 **どちらが安いですか？** 接続が目的であれば、EasyCoexistence のほうが大幅に安くなります。Octadesk は月額 R$ 2.499 からで、導入支援の費用が別にかかります。EasyCoexistence は接続済みの番号 1 件あたり月額 US$ 9 です。 **会話が 3,000 件を超えるとどうなりますか？** Octadesk の One プランでは、上位のプランに移ることになります。EasyCoexistence では何も変わりません。どの料金でも会話数の上限はありません。 **Octadesk は Coexistence に対応していますか？** 料金ページには記載がありません。このページの情報に頼らず、Octadesk に直接ご確認ください。 **EasyCoexistence でも AI を使えますか？** はい。当社の MCP サーバーを使えば、Claude、ChatGPT、Cursor、Claude Code、Codex から、その番号でメッセージやテンプレートを送信できます。 --- ## EasyCoexistence と Huggy の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-huggy Huggy はブラジル発のオムニチャネル対応カスタマーサービス用インボックスで、料金はプランと接続ユーザー数で決まり、WhatsApp の料金は数量とカテゴリーに応じて別途かかります。EasyCoexistence は WhatsApp との接続そのものです。WhatsApp Business アプリで使っている番号に、Coexistence を通じて Meta の Cloud API をつなぎ、接続した番号ごとに公開料金 1 つだけで提供します。 ### 毎月の請求は何に対するものか Huggy の請求額はチームの人数に応じて増えます。当社は番号の数だけで増えます。 - Huggy:: 接続ユーザー 1 名を含むプランに、追加ユーザーごとの料金が加わります。Starter は R$ 69,90、月額 R$ 579 からの Intermediate は R$ 119,90、R$ 989 からの Custom は R$ 189,90 です。WhatsApp の料金は数量とカテゴリーに応じて別にかかり、導入支援は任意で R$ 1.250 です。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 から、1 から 5 件まではこの料金で、番号を追加するほど 1 件あたり US$ 1 まで下がります。ユーザー数による課金はありません。最初の 3 日間は無料で、メッセージ料金は Meta から企業に直接請求されます。 ### それぞれがどのような製品か インボックスと接続は、必要になる理由が異なります。 - Huggy:: WhatsApp、Instagram、Messenger、Telegram、メール、SMS、音声を一か所にまとめるサービス用インボックスで、チャットボットとレポート機能を備えます。料金ページでは、Meta の公式パートナーとして公式 API を有効化できると説明しています。 - EasyCoexistence:: WhatsApp Business アプリの番号と Meta の Cloud API をつなぐ接続で、常時監視しています。メッセージは、Meta の Webhook または当社の MCP サーバー経由で、企業がすでに使っているシステムに届きます。 ### チームの働き方は変わるか 契約を決める前に、経営者が確認したい点です。 - Huggy:: 担当者は Huggy のインボックスにログインし、すべてのチャネルの会話を割り当てて対応します。料金ページには、WhatsApp Business アプリとの Coexistence についての記載はありません。 - EasyCoexistence:: 誰も移行する必要はありません。WhatsApp Business アプリは同じ番号でチャット履歴ごとそのまま使え、API は企業が自動化したい処理のために並行して動きます。 ### 会話はどこに保管されるか あとから元に戻すのが難しい判断です。 - Huggy:: Huggy のプラットフォーム上です。インボックスは、開いた担当者に会話を表示するために、これを必要とします。 - EasyCoexistence:: 当社側にはありません。会話の内容は一切保存せず、Meta は受信メッセージを企業自身の Webhook に直接送ることができます。 - WhatsApp の料金を含めずに Huggy の費用を見積もること。プランとは別に、数量とカテゴリーに応じて請求されます。 - 現在のチームの人数だけで数えること。インボックス型のプランでは、ユーザーが増えるたびに月額料金が加わります。 - 1 つの番号で API を使うためにインボックスを購入すること。必要なのは接続だけです。 **どちらが安いですか？** 接続が必要な企業にとっては、当社のほうが安くなります。Huggy の Intermediate プランは、WhatsApp の料金を除いてユーザー 1 名で月額 R$ 579 から、当社は接続済みの番号 1 件あたり月額 US$ 9 です。 **Huggy は公式 API を使っていますか？** 料金ページでは、Meta の公式パートナーであり、Meta の公式 API を有効化すると説明しています。 **Huggy は Coexistence に対応していますか？** 料金ページには記載がありません。このページを頼りにせず、Huggy に直接お問い合わせください。 **インボックスはありますか？** ありません。チームは WhatsApp Business アプリをそのまま使い続けます。それこそが Coexistence の目的です。 --- ## EasyCoexistence と Umbler Talk の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-umbler-talk Umbler Talk は、公式 API 上で動くブラジル発の WhatsApp 共有インボックス、CRM、チャットボットです。料金は担当者 1 人あたり月額 R$ 99,90 からで、最低 2 人からの契約になります。EasyCoexistence は、WhatsApp Business アプリで使用中の番号を Coexistence で Meta の Cloud API に接続します。料金は接続した番号の数で決まるため、対応する人数によって請求額が変わることはありません。 ### 毎月の請求は何に対するものか Umbler Talk は人数を数えます。EasyCoexistence は番号を数えます。 - Umbler Talk:: 担当者 1 人あたり月額で、Essencial は R$ 99,90（2 人以上）、Impulso は R$ 149,90、Escala は R$ 219,90（いずれも 3 人以上）です。最も安い請求額は Essencial に 2 人で、月額 R$ 199,80 になります。 - EasyCoexistence:: 接続した番号 1 件あたり月額 US$ 9 から（1 件から 5 件まで）、6 つの料金帯を経て、番号を追加するにつれて US$ 1 まで下がります。担当者数の条件も最低料金もありません。最初の 3 日間は無料で、メッセージ料金は Meta から直接請求されます。 ### それぞれがどんな製品か どちらも Meta の公式 API で動いており、Umbler Talk も自社ページでそう明記しています。 - Umbler Talk:: ビジュアルな CRM パイプライン付きの共有インボックスに、チャットボット、AI エージェント、ナレッジベース、ウェブチャットが加わります。上位プランでは WhatsApp キャンペーンも使えます。チームはこの中で業務を行います。 - EasyCoexistence:: 提供するのは接続とその監視です。番号は WhatsApp Business アプリに残り、API も同時に動きます。メッセージは CRM、n8n、自社コード、または MCP 経由の AI エージェントに届きます。 ### 何件の番号まで使えるか 代理店や複数拠点の企業では、プラン名よりも番号数の上限が重要です。 - Umbler Talk:: Essencial は WhatsApp 番号 2 件、Impulso は最大 3 件で、Escala は番号数の上限が可変と説明されています。番号を増やすには、全担当者分のプランを上げる必要があります。 - EasyCoexistence:: アカウントあたりの番号数は無制限で、各番号に料金帯の単価が適用されます。番号が増えるほど 1 件あたりの料金は下がり、20 件目の番号は 1 件目より安くなります。 ### WhatsApp Business アプリは使い続けられるか 小規模なチームが真っ先に気にする点です。 - Umbler Talk:: プランのページには Coexistence への言及がありません。接続後も番号が WhatsApp Business アプリで使えるかどうかは、直接お問い合わせください。 - EasyCoexistence:: はい、使えます。当社が接続するのは Coexistence のみです。アプリのチャットはそのまま残り、API も並行して動きます。Meta の 14 日ルールのような切断が起きないかも、接続を監視して確認します。 - 担当者 1 人あたりの料金をそのまま請求額と考えてしまうことです。最低 2 人からで、上位プランではさらに増えます。 - 番号数の上限でプランを選び、その結果、全担当者に高い料金を払うことになることです。 - Meta のテンプレート料金を予算に入れ忘れることです。この料金は Meta から企業に直接請求されます。 **どちらが安いですか？** 当社の方が安いです。Umbler Talk の最低請求額は、担当者 2 人で 1 人あたり R$ 99,90、月額 R$ 199,80 です。当社は接続した番号 1 件で US$ 9 で、誰が返信しても変わりません。 **Umbler Talk は WhatsApp の公式 API を使っていますか？** はい。同社のページには、Umbler Talk は WhatsApp の公式 API を使い、プラットフォームのガイドラインに従っていると記載されています。 **Umbler Talk は Coexistence に対応していますか？** プランのページには記載がありません。このページの情報に頼らず、直接お問い合わせください。 **EasyCoexistence は担当者数で課金しますか？** いいえ。料金は接続した番号の数で決まります。その番号で何人が返信しても、API 経由で何人が作業しても同じです。 --- ## EasyCoexistence と Whaticket の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-whaticket Whaticket は WhatsApp などのチャネルに対応した複数担当者向けのインボックスです。月額 US$ 49 から、最低 3 ユーザーと WhatsApp 回線 1 本が条件で、接続方法は QR コードか、Coexistence を使った公式 API から選べます。EasyCoexistence は公式の接続だけを提供します。WhatsApp Business アプリで使っている番号に Meta の Cloud API をつなぎ、料金は番号 1 件あたり US$ 9 です。 ### 番号の接続方法の違い Whaticket は WhatsApp への接続方法を 2 種類用意しています。EasyCoexistence は 1 種類だけです。 - Whaticket:: WhatsApp Web のようにスキャンして使う WhatsApp QR か、Coexistence を使った WhatsApp API を選べます。同社のサイトには、WhatsApp Business での一斉送信はブロックの原因になり得ると書かれており、リスクを減らすために API が推奨されています。 - EasyCoexistence:: Meta の Cloud API のみを、Meta の Embedded Signup と Coexistence で接続します。そのため同じ番号で WhatsApp Business アプリも使い続けられます。QR セッションの選択肢はなく、非公式の方法に切り替えることもありません。 ### 毎月の請求の中身 2 つの請求は、異なる要素で構成されています。 - Whaticket:: Basic は 3 ユーザーと回線 1 本で月額 US$ 49、回線を追加するごとに月額 US$ 20、Pro プランは US$ 109 です。QR 接続でのキャンペーン配信にはクレジットを消費し、1,000 件で US$ 25 からです。API 経由のキャンペーンは対象外です。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 から、番号が増えるにつれて US$ 1 までです。1 から 5 番号までが US$ 9 で、ユーザー課金もクレジットもありません。Meta のメッセージ料金は、上乗せなしで企業に直接請求されます。最初の 3 日間は無料です。 ### それぞれの製品の役割 一方は担当者が作業する場所で、もう一方はその下で動く接続の部分です。 - Whaticket:: メッセージのチャネルを一元化して自動化する、複数担当者向けのインボックスです。キャンペーン機能もあり、チームは Whaticket のプラットフォーム内で返信します。 - EasyCoexistence:: 接続と 24 時間 365 日の監視を提供します。チームは WhatsApp Business アプリをそのまま使え、メッセージは自社の Webhook に届き、AI エージェントは MCP サーバー経由でその番号を操作できます。 ### 2 番号目、5 番号目、10 番号目の費用 代理店や複数拠点の企業は、まずこの計算をします。 - Whaticket:: プランに加えて回線 1 本ごとに US$ 20 かかるため、Basic で 5 回線にすると、3 ユーザーで月額 US$ 129 になります。 - EasyCoexistence:: 5 番号なら月額 US$ 45 です。番号あたりの単価は下がり続け、6 番号目からは 1 件あたり US$ 7、番号が増えるにつれて US$ 1 になります。 - 業務用の番号を QR 接続で運用すること。Whaticket のサイトにも、その接続での一斉送信はブロックの原因になり得ると書かれています。 - メッセージクレジットを見落とすこと。QR 接続でのキャンペーンは、プラン料金とは別に 1,000 件単位で課金されます。 - 追加の回線をプランと同じ料金で見積もること。1 本ごとに月額 US$ 20 が加わります。 **どちらが安いですか？** EasyCoexistence の方が安いです。Whaticket Basic の 1 回線は月額 US$ 49、当社の接続済み番号 1 件は US$ 9 です。5 番号では US$ 129 に対して US$ 45 になります。 **Whaticket は Coexistence に対応していますか？** はい。料金ページには、QR 接続と並んで Coexistence を使った WhatsApp API が接続方法として掲載されています。 **QR 接続は公式の方法ですか？** いいえ。WhatsApp Web と同じ形でセッションを連携する方法です。Whaticket のサイトでも、ブロックのリスクを減らすために API が推奨されています。 **Whaticket のようなインボックスはありますか？** ありません。チームは WhatsApp Business アプリをそのまま使い、自動化する処理はお客様自身のツールで動かします。 --- ## EasyCoexistence と Leadsales の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-leadsales Leadsales は、WhatsApp、Facebook、Instagram で販売するためのメキシコ発の会話型 CRM です。Basic プラン（月額 US$ 97）ではウェブセッション経由で WhatsApp に接続し、公式 API は月額 US$ 133 の Professional プランから利用できます。EasyCoexistence は Coexistence により、1 番号あたり US$ 9 で番号を Meta の Cloud API に接続します。 ### 公式に WhatsApp へ接続できるのはどのプランか Leadsales ではプランによって接続方法が変わります。EasyCoexistence では変わりません。 - Leadsales:: Basic は Business API ではなく、Messenger とウェブセッション経由で WhatsApp に接続します。月額 US$ 133（MX$ 3,239.88）の Professional と、月額 US$ 247 の Advanced は公式 API を使います。 - EasyCoexistence:: すべての番号が Meta の Cloud API 上にあり、Meta 自身の Embedded Signup と Coexistence で接続されるため、スマートフォンの WhatsApp Business アプリもそのまま使えます。安価な非公式プランはありません。 ### 毎月の料金は何に対するものか Leadsales はプランごとにユーザー数と会話数に上限があります。EasyCoexistence はどちらにも上限がありません。 - Leadsales:: Basic は 3 ユーザーとアクティブな会話 5,000 件、Professional は 4 ユーザーと 20,000 件、Advanced は 5 ユーザーと 50,000 件が含まれます。年払いでは最大 20% 割引されます。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9（1 から 5 件の場合）で、番号を追加するほど下がり、1 件あたり US$ 1 まで下がります。ユーザー数や会話数の課金はなく、最初の 3 日間は無料です。メッセージ料金は Meta が企業に直接請求します。 ### それぞれの製品は何か CRM と接続サービスは、解決する課題が異なります。 - Leadsales:: ファネル、共有ワークスペース、ステージ別の一斉送信、上位プランの AI エージェントを備えた営業向け CRM です。リードは Leadsales の中で対応します。 - EasyCoexistence:: 接続とその監視を担います。メッセージは Meta の Webhook を通じて、企業が既に使っている CRM やツールに届き、AI エージェントは当社の MCP サーバー経由で番号を操作できます。 ### ウェブセッション上の番号はどうなるか 安いプランに伴うリスクです。 - Leadsales:: Basic プランの番号は、Business API ではなくウェブセッション経由で WhatsApp に届きます。このやり方は、自動化された企業メッセージについて WhatsApp のビジネス規約が認めていない経路です。 - EasyCoexistence:: 接続は Meta 自身の Coexistence 機能を Meta 自身のフローで行うため、規約違反として是正される要素がなく、24 時間体制で監視されています。 - 価格を理由に Basic プランを選び、API を使うと思い込むこと。実際にはウェブセッションで接続します。 - ユーザー数だけを数えて、アクティブな会話数の上限を見落とすこと。各プランに上限があります。 - プランに Meta のテンプレート料金が含まれると考えること。それらは Meta が企業に直接請求します。 **どちらが安いですか？** 当社です。公式 API を使える Leadsales の最安プランは月額 US$ 133、当社は接続済みの番号 1 件あたり US$ 9 です。 **Leadsales は公式 WhatsApp API を使っていますか？** Professional と Advanced では使っています。Basic プランでは、代わりに Messenger とウェブセッション経由で WhatsApp に接続します。 **Leadsales は Coexistence に対応していますか？** 料金ページには、場合によっては番号をスマートフォンで引き続き使えるが、完全に API へ移行する場合もあると記載されています。当社では常に WhatsApp Business アプリに残ります。 **今の CRM を使いながら EasyCoexistence を利用できますか？** はい。Meta は指定した Webhook にメッセージを届けるため、Webhook を受け付ける CRM であればどれでも受信できます。 --- ## EasyCoexistence と Treble の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-treble Treble は、自動フロー、キャンペーン、AI 対応を提供する中南米発の WhatsApp Business API プラットフォームで、営業チーム経由での販売となり、料金は公開されていません。EasyCoexistence は、企業が WhatsApp Business アプリですでに使っている番号を、Coexistence を通じて Meta の Cloud API に接続します。セルフサービスで、接続済みの番号 1 件あたり月額 US$ 9 と料金を公開しています。 ### WhatsApp Business アプリはどうなるか 2 つの製品は、電話機の扱いについて正反対の前提から出発しています。 - Treble:: Treble のホームページには、無料の WhatsApp Business アプリではなく WhatsApp Business API を基盤とするソリューションだと記載されています。Coexistence への言及はないため、番号をアプリに残せるかどうかは直接お問い合わせください。 - EasyCoexistence:: アプリはそのまま使えます。Coexistence では同じ番号で WhatsApp Business アプリが動き続け、約 6 か月分のチャット履歴が同期され、その横で Cloud API が自動化を担います。 ### 料金はいくらか 現時点で確認できる料金は片方だけです。もう片方は問い合わせが必要です。 - Treble:: 料金は公開されていません。ホームページに料金の表示はなく、料金ページにはパスワードが求められるため、金額は営業チームから案内を受けることになります。 - EasyCoexistence:: 1 件から 5 件までは接続済みの番号 1 件あたり月額 US$ 9 で、6 つの料金帯を経て、番号を追加するほど 1 件あたり US$ 1 まで下がります。メッセージ料金は Meta が企業に直接請求し、上乗せは一切ありません。 ### それぞれがどのような製品か どちらも Meta の公式 API を利用していますが、提供する層が異なります。 - Treble:: 自動チャットフロー、一斉配信キャンペーン、AI カスタマーサービスのためのプラットフォームです。HubSpot や Salesforce とのネイティブ連携があり、独自の連携向けに API も用意されています。 - EasyCoexistence:: 提供するのは接続と、その 24 時間 365 日の監視です。Meta が Webhook をお客様のシステムへ直接送り、会話の内容は当社側に保存されません。MCP サーバーにより、AI エージェントがその番号からメッセージを送信することもできます。 ### 番号が使えるようになるまでの時間 小規模な企業にとっては、決め手になることが多い点です。 - Treble:: 営業プロセスを経る形です。導入の前に、プランと料金を Treble のチームと取り決めます。 - EasyCoexistence:: 通常は Meta の Embedded Signup を使って 2 分以内です。Facebook でログインし、番号を入力し、アプリで QR コードを読み取ります。必要条件は、アプリのバージョンが 2.24.17 以降であることと、直近に実際の利用があることです。 - Coexistence を確認せずに、よく使われているアプリの番号を API 専用の構成へ移してしまうこと。電話機が、チームが返信する場所ではなくなります。 - キャンペーンプラットフォームの見積もりと、接続料金を比べてしまうこと。前者にはフローとキャンペーンが含まれています。 - Meta のテンプレート料金を計算に入れ忘れること。これはどちらの事業者でもなく、Meta から請求されます。 **Treble は料金を公開していますか？** いいえ。ホームページには料金の記載がなく、料金ページもパスワードで保護されています。 **どちらが安いですか？** 当社は料金を公開しており、Treble は公開していません。確認できるのは当社の料金で、接続済みの番号 1 件あたり月額 US$ 9 から、番号を追加するほど US$ 1 まで下がります。 **Treble は Coexistence に対応していますか？** ホームページには Coexistence への言及がなく、Treble は WhatsApp Business アプリではなく API を基盤とするものだと説明されています。直接お問い合わせください。 **EasyCoexistence でキャンペーンを実施できますか？** はい。承認済みのテンプレートを使い、Cloud API 経由で、お客様ご自身のシステムやツールから実施できます。テンプレートの料金は Meta からお客様に直接請求されます。 --- ## EasyCoexistence と Botmaker の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-botmaker Botmaker は WhatsApp Business Platform 上で動作する、ラテンアメリカ発のチャットボット兼カスタマーサービス向けプラットフォームです。月額 US$ 149 から（3,000 会話分）で、WhatsApp アカウント開設に一度だけ US$ 99 がかかります。Coexistence にも対応しています。EasyCoexistence は Coexistence の接続だけを提供し、接続済みの番号 1 件あたり月額 US$ 9 です。会話数のバンドルはありません。 ### 毎月の請求は何に対するものか Botmaker が販売しているのは会話です。EasyCoexistence が販売しているのは接続です。 - Botmaker:: Standard は US$ 149 で 3,000 会話、Scale は US$ 249 で 5,000 会話、Pro は US$ 499 で 10,000 会話です。超過分は 1 会話あたり US$ 0.07 から US$ 0.05 で、WhatsApp アカウントの開設に US$ 99 がかかります。プッシュメッセージには WhatsApp の料金に 20% のサービス手数料が加わります。 - EasyCoexistence:: 1 件から 5 件までは接続済みの番号 1 件あたり月額 US$ 9 で、番号を追加するほど 1 件あたり US$ 1 まで下がります。バンドルも超過料金も開始費用もありません。Meta の料金は Meta から企業に直接請求され、当社が上乗せすることはありません。 ### それぞれの Coexistence の仕組み どちらも番号上で WhatsApp Business アプリを使い続けられます。違いはそれ以外の設定にあります。 - Botmaker:: Botmaker のヘルプセンターによると、Coexistence は新しい回線または新しい構成でのみ利用でき、スマートフォンから返信するとボットが一時停止し、グループチャットはこのプラットフォームでは未対応です。 - EasyCoexistence:: Coexistence そのものが当社の製品です。Meta の Embedded Signup を使って約 2 分でセルフサービス設定でき、その後は 24/7 の監視が続きます。Meta の 14 日ルールのような切断も、発生した時点で通知されます。 ### それぞれの製品の位置づけ ボットプラットフォームと接続は、別の製品を買うということです。 - Botmaker:: WhatsApp 上でボットを作成し、オペレーター対応を運用するためのプラットフォームです。プランに応じて 10 から 50 のオペレーター席が含まれます。フローは Botmaker の中に置かれます。 - EasyCoexistence:: 当社が提供するのは接続です。Meta の Webhook はお客様自身のシステムに届き、会話の内容を当社側で保存することはありません。MCP サーバーを通じて、Claude、ChatGPT、Cursor、Claude Code、Codex から番号を操作できます。 ### 事業の成長が請求に与える影響 事業が忙しくなるにつれて、2 つの料金モデルは反対の方向に動きます。 - Botmaker:: 会話が増えると、会話ごとの超過料金がかかるか、上位プランへの移行が必要になります。そのため、忙しい月は閑散期の月より高くなります。 - EasyCoexistence:: メッセージ量は料金に影響しません。請求が変わるのは番号を追加したときだけで、追加するほど 1 件あたりの料金は下がります。 - プラン料金だけを比べて、US$ 99 のアカウント開設費用とプッシュメッセージの 20% のサービス手数料を見落とす。 - 現在の会話数に合わせてプランを選ぶ。バンドルを超えた分は、会話ごとに超過料金がかかります。 - スマートフォンから返信してもボットが動き続けると考える。Botmaker では、スマートフォンで応答するとボットが一時停止します。 **Botmaker は Coexistence に対応していますか？** はい。ヘルプセンターに記載があり、新しい回線または新しい構成で利用できます。 **どちらが安いですか？** 当社のほうが安価です。Botmaker は月額 US$ 149 から、さらにアカウント開設に US$ 99 かかります。当社は接続済みの番号 1 件あたり月額 US$ 9 で、開始時の費用はありません。 **Meta の料金に手数料は上乗せされますか？** いいえ。Meta はメッセージ料金を企業自身のアカウントに直接請求し、当社が上乗せすることはありません。 **EasyCoexistence でボットを作れますか？** はい。n8n、Make、独自のコード、または MCP 経由の AI エージェントで作れます。メッセージは Meta の Webhook を通じてお客様のシステムに届きます。 --- ## EasyCoexistence と Gallabox の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-gallabox Gallabox と EasyCoexistence は、解決する課題が異なります。Gallabox は公式の WhatsApp Business API 上で動くチーム向けインボックスと自動化のスイートで、ユーザー数が固定されたプランで販売されています。EasyCoexistence は接続そのものです。WhatsApp Business アプリと同じ番号で Meta の Cloud API を使えるようにし、料金は番号ごと、インボックスもユーザー数の制限もありません。 ### 月額料金は何に対する支払いか 両者は課金の単位が異なり、その単位によって料金の増え方が決まります。 - Gallabox:: チーム人数を固定したプランの月額制です。Basic は 3 か月ごとの請求で月額 ₹ 2,999、3 ユーザー分と掲載されており、同社のページでは上限は厳格とされています。人数が多いチームは Essential か Advanced へ移ります。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 から、番号を追加するにつれて US$ 1 までです。ユーザー数も連絡先数も課金に関係しないため、担当者が増えても、対応するお客様が増えても、請求額は変わりません。 ### Coexistence を有効にする方法 どちらも Meta の Coexistence 機能を使うため、携帯電話上の WhatsApp Business アプリはそのまま使えます。ただし、そこへ至る手順は異なります。 - Gallabox:: 同社のドキュメントによると、Coexistence は初期状態では有効になっておらず、開始前に Gallabox のサポートへ連絡してワークスペースを有効化してもらう必要があります。 - EasyCoexistence:: Coexistence こそが製品です。企業のオーナーが Meta の Embedded Signup を約 2 分で、セルフサービスで完了できます。条件は、アプリがバージョン 2.24.17 以降であること、番号が他のプロバイダーに接続されていないことです。 ### 会話はどこに保存されるか 独自のインターフェースを構築する場合や、顧客の番号を預かる場合に、最も重要になる違いです。 - Gallabox:: 同社のプラットフォーム内です。共有インボックス、チャットボットビルダー、一斉配信ツールは、担当者に表示するためにメッセージを自社側で保存する必要があります。 - EasyCoexistence:: 当社では保存しません。Meta が Webhook を指定されたエンドポイントへ直接送り、会話が当社側に保存されることはありません。データは、お客様の CRM、アプリ、または AI エージェントに届きます。 ### どちらを選ぶべきか 購入したいものが、チャットボットやキャンペーン機能を備えたチーム向けインボックスであれば、Gallabox はそのための製品です。接続とは別の購入になります。 購入したいものが番号そのもの、つまり公式に接続され、維持される番号であれば、EasyCoexistence のほうが用途が絞られ、料金も安くなります。顧客の番号を自社のシステムに組み込む代理店、すでにインターフェースを持つ開発者、チームを電話から離さずに自動化したいオーナーに向いています。接続は Meta の 14 日ルールを含めて監視され、メッセージ料金は Meta から直接お客様のアカウントに請求されます。当社による上乗せはありません。 - プランの料金を単純に比較すること。一方はインボックスと AI クレジットを含み、もう一方は接続のみです。 - プロバイダーが有効化する前に Coexistence の設定を始め、同じ番号で何度もやり直すこと。 - メッセージを自社のソフトウェアで処理する番号に、ユーザー数に上限のあるインボックスを購入すること。 **EasyCoexistence は Gallabox より安いですか？** 接続に限れば、はい。Gallabox の Basic は 3 か月ごとの請求で月額 ₹ 2,999、3 ユーザーまでです。EasyCoexistence は接続済みの番号 1 件あたり月額 US$ 9 でユーザー数の制限がないため、チームの規模にかかわらず、1 番号なら US$ 9 です。 **Gallabox は Coexistence に対応していますか？** はい。同社のドキュメントに説明があり、設定の前にワークスペースでサポートによる有効化が必要とされています。 **EasyCoexistence には Gallabox のようなインボックスがありますか？** いいえ。チームは WhatsApp Business アプリをそのまま使い、ソフトウェアは Meta がお客様のシステムへ送る Webhook を通じて同じメッセージを受け取ります。 **Meta のメッセージ料金は誰が支払いますか？** EasyCoexistence では、お客様ご自身の WhatsApp Business アカウントで Meta に直接お支払いいただきます。当社が上乗せすることはありません。 --- ## EasyCoexistence vs TimelinesAI https://easycoexistence.com/ja/compare/easycoexistence-vs-timelinesai TimelinesAI は CRM と同期する共有 WhatsApp インボックスで、料金はシート単位です。番号の接続方法は QR コード、公式の WhatsApp Business API、Coexistence から選べます。EasyCoexistence は Meta の Cloud API と Coexistence だけで番号を接続し、料金は番号単位です。メッセージはインボックスではなく、お客様ご自身のシステムに送られます。 ### それぞれの番号の接続方法 接続方法によって番号がさらされるリスクが変わるため、最初に比較します。 - TimelinesAI:: どのプランでも 3 つから選べます。番号をリンク済みデバイスとして接続する QR コード、公式の WhatsApp Business API、そしてアプリと API を同時に動かす Coexistence です。 - EasyCoexistence:: 方法は 1 つだけです。Meta の Embedded Signup を通した、Cloud API と Coexistence の組み合わせです。QR セッションの選択肢はないため、当社経由で接続した番号がリンク済みデバイスの接続維持に左右されることはありません。 ### 月額料金は何に対する支払いか シート単位と番号単位では、料金が増える理由が異なります。 - TimelinesAI:: Starter は 1 シートあたり月額 US$ 35、年払いなら US$ 28 で、Pro は 1 シートあたり US$ 49 です。料金ページには、WhatsApp アカウントを接続するユーザーごとにシートが必要と記載されています。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 から、番号を追加するほど US$ 1 まで下がります。人数は数えません。Meta のメッセージ料金は、Meta からお客様に直接請求されます。 ### 会話の行き先 インボックスと接続では、データの置かれる場所が異なります。 - TimelinesAI:: 共有インボックスに届き、選択した CRM へ同期されます。インボックス自体が製品のため、メッセージは先方のプラットフォームを経由して表示されます。 - EasyCoexistence:: お客様のエンドポイントに直接届きます。Meta が指定された URL へ Webhook を送り、会話は当社側に保存されません。そのため、取引先のデータを自社で管理するシステム内にとどめられます。 ### どちらを選ぶか CRM の中で共有インボックスを使いたい営業チームが探しているのはインボックスで、TimelinesAI はそれに当たります。 番号を公式に接続し、経路に QR セッションを含めず、仲介業者にデータを保存させたくない企業が探しているのは接続です。EasyCoexistence はその接続を提供します。Meta 自身の切断理由を読み取る接続状態の監視、AI アシスタント向けの MCP サーバー、チームの人数に関係なく番号ごとの定額料金です。 - 速いからという理由で、業務用の番号を QR コードで接続してしまう。リンク済みデバイスのセッションは、Meta の Business Platform ではありません。 - 人ではなくソフトウェアが応答する番号にまでシートを数えてしまう。 - QR 接続の番号と API 接続の番号を同じアカウントに混在させ、どちらがどれか管理していない。 **EasyCoexistence は TimelinesAI より安いですか？** 接続した番号 1 件あたりで比べれば、はい、安くなります。TimelinesAI Starter は 1 シートあたり月額 US$ 35 です。EasyCoexistence は接続済みの番号 1 件あたり月額 US$ 9 で、WhatsApp Business アプリで応対するチームは何人でも追加料金がかかりません。 **TimelinesAI は Coexistence に対応していますか？** はい。料金ページには、すべてのプランで QR コードや公式 API と並んで Coexistence が記載されています。 **EasyCoexistence で QR コードによる接続はできますか？** できません。すべての番号は、リンク済みデバイスではなく、Meta の Cloud API と Coexistence で接続します。 **スマートフォンの WhatsApp はそのまま使えますか？** はい。Coexistence により、API を並行して動かしたまま、同じ番号で WhatsApp Business アプリを使い続けられます。 --- ## EasyCoexistence と Periskope の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-periskope Periskope は、スマートフォンの「デバイスをリンク」画面で QR コードを読み取って WhatsApp の番号を接続します。同社のドキュメントには、WhatsApp API の番号はリンクできないと記載されています。EasyCoexistence は逆のルートです。Coexistence を通じて番号を Meta の Cloud API に登録するため、WhatsApp Business アプリはそのまま使え、接続も公式のものになります。 ### それぞれ WhatsApp にどう接続するか このページの違いはすべて、接続方法から生じます。 - Periskope:: スマートフォンで WhatsApp の設定を開き、「デバイスをリンク」を選んで、Periskope が表示する QR コードを読み取ります。番号はリンク済みデバイスとして接続されます。同社のトップページでは、Business API が不要であることが特長として紹介されています。 - EasyCoexistence:: Meta の Embedded Signup が、お客様自身の WhatsApp Business アカウントに Meta が発行する認証情報を使って、番号を Cloud API に登録します。Coexistence により、同じ番号のままスマートフォンのアプリも使い続けられます。 ### 毎月の料金 どちらも料金を公開していますが、課金の単位が異なります。 - Periskope:: Starter は 1 ユーザーあたり月額 US$ 25、Pro は月額 US$ 35 です。最初の 1 台は含まれ、2 台目以降はそれぞれ別のライセンスとして同じプラン料金が課金されます。Enterprise はユーザーまたは電話が 50 件以上必要です。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9（1 件から 5 件）から始まり、6 段階の料金帯を経て番号を追加するほど US$ 1 まで下がります。ユーザーライセンスはなく、メッセージ料金は Meta から上乗せなしで直接お客様に請求されます。 ### 接続が置かれるリスク リンク済みデバイスのセッションと API 登録は、WhatsApp では異なる扱いを受けます。 - Periskope:: リンク済みデバイス経由のアクセスは、Meta のビジネスプラットフォームの外で動作します。自動化や第三者による利用は WhatsApp の商用規約で定められており、この方法で接続した番号は Meta から API レベルの扱いを受けません。 - EasyCoexistence:: すべての呼び出しは Meta の Cloud API に送られます。接続が切れた場合は、Meta 自身が示す切断理由を確認してアラートでお知らせします。Coexistence の番号に適用される 14 日間のアプリ利用ルールも対象です。 ### どちらを選ぶべきか 判断の軸は、その番号にどれだけの価値があり、どこで運用する必要があるかです。Periskope のモデルは、グループを含め、既存の番号をデバイスとしてリンクすることを前提にしており、API の番号はまったく受け付けません。 お客様が頼りにしている番号や、代理店が責任を負うクライアントの番号であれば、Meta の規則の内側にとどまれるのは公式ルートです。EasyCoexistence は、番号ごとの定額料金でそのルートを提供し、WhatsApp Business アプリも引き続き使え、メッセージはお客様自身のシステムに届きます。 - 有料ツールなら Meta が認めたアクセスだと思い込むこと。Meta が API 認証情報を発行して初めて、公式のアクセスになります。 - 企業の番号をデバイスとしてリンクし、後でリンクを解除せずに API プロバイダーへ移そうとすること。 - メッセージの大半が人ではなく自動化で処理されるのに、ユーザー単位で料金を見積もること。 **EasyCoexistence は Periskope より安いですか？** はい、EasyCoexistence の方が安価です。Periskope Starter は 1 ユーザーあたり月額 US$ 25 で、電話を追加するごとにさらに月額 US$ 25 かかります。EasyCoexistence は接続済みの番号 1 件あたり月額 US$ 9 で、ユーザー課金はありません。 **Periskope は公式の WhatsApp API を使っていますか？** いいえ。ドキュメントによると、番号は「デバイスをリンク」から QR コードで接続され、WhatsApp API の番号はリンクできないと明記されています。 **EasyCoexistence でグループは使えますか？** いいえ。グループチャットは Meta の Cloud API の対象外です。このルールは、公式プロバイダーすべてに共通です。 **アプリはそのまま使えますか？** はい。Coexistence により、同じ番号で Cloud API が動作しながら、スマートフォンの WhatsApp Business アプリも引き続き使えます。 --- ## EasyCoexistence と Wassenger の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-wassenger Wassenger はチーム向けインボックスと WhatsApp API を備えたプラットフォームで、QR コードのセッションと Meta の Cloud API という 2 つの接続方式があり、Coexistence は API 側で利用できます。EasyCoexistence は Coexistence 対応の Cloud API のみを提供します。インボックスはなく、エージェント数が決まったプランではなく、接続済みの番号 1 件あたり月額 US$ 9 からという料金です。 ### それぞれの番号の接続方法 Wassenger 自身のヘルプセンターが 2 つの接続方式を比較しており、最初に読むのに最適です。 - Wassenger:: QR 接続は、ワーカーサービスを介したセッション方式で、スマートフォンのオンライン状態が必要です。また WhatsApp のスパム検知の対象になると説明されています。もう 1 つは Meta で認証する Cloud API 接続で、Coexistence は API 側で利用できます。 - EasyCoexistence:: Meta の Cloud API のみで、Meta の Embedded Signup と Coexistence を通じて接続します。セッション用ワーカーも QR 接続も製品に存在しないため、選び間違える余地がありません。 ### 月額料金は何に対する支払いか エージェントのプランと番号ごとの料金は、増える対象が異なります。 - Wassenger:: Professional は番号 1 件とエージェント 3 名で月額 €39.90、Business はエージェント 6 名で €69.90、Enterprise はエージェント 9 名で €99.90 です。Meta が定めるテンプレートの料金は、原価のまま別途請求されます。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 から、番号を追加するにつれて US$ 1 まで下がります。エージェント数による課金はありません。Meta はメッセージ料金をお客様ご自身の WhatsApp Business アカウントに請求し、当社を経由することはありません。 ### 会話はどこに保存されるか インボックスは表示する内容を保存します。接続は受け取った内容を転送します。 - Wassenger:: 共有のチームインボックスに保存されます。エージェントはそこでチャットの割り当てを受け、キャンペーンを実行し、AI アシスタントを使います。エージェントが対応できるよう、メッセージは Wassenger のプラットフォーム上に置かれます。 - EasyCoexistence:: お客様ご自身のシステムに届きます。Meta が設定済みのエンドポイントへ直接 Webhook を送信し、会話が当社に保存されることはありません。チームはこれまでどおり WhatsApp Business アプリから返信できます。 ### どちらを選ぶべきか エージェントが共有インボックスにログインして使いたいチームが求めているのはインボックスであり、Wassenger のプランはそのために作られています。 番号を公式 API に載せるだけでよい場合、たとえばクライアントの番号を接続する代理店、既存のアプリにデータを渡す開発者、新しいツールなしで自動化を加えたい経営者には、EasyCoexistence のほうが範囲の絞られた製品です。接続方式は 1 つ、番号ごとの定額、Coexistence の接続が切れる前に知らせる監視、そして Claude、ChatGPT、Cursor 向けの MCP サーバーを備えています。 - テストのために QR 接続で始め、動いたあともそのまま本番の番号を QR 接続に置いたままにする。 - 月額 €39.90 のプランと番号単位の料金を、プランに含まれるエージェントとインボックスを数えずに比べる。 - チャット履歴が引き継がれるかを確認せずに、接続方式の間で番号を移す。 **EasyCoexistence は Wassenger より安いですか？** 接続だけで比べれば安いです。Wassenger Professional は番号 1 件で月額 €39.90 です。EasyCoexistence は接続済みの番号 1 件あたり月額 US$ 9 で、5 件でも合計 US$ 45 です。 **Wassenger は Coexistence に対応していますか？** はい。Wassenger は、同じ番号で WhatsApp Business アプリと自社の API プラットフォームを併用するための Coexistence のページとヘルプ記事を公開しています。 **Wassenger の QR 接続は公式のものですか？** Wassenger は、セッション方式で WhatsApp のスパム検知の対象になると説明しています。Meta で認証されるのは Cloud API 接続のほうです。 **EasyCoexistence を使うにはサーバーが必要ですか？** Webhook を受け取るエンドポイントか、MCP サーバー経由で接続した AI アシスタントが必要です。接続そのもののホスティングは料金に含まれています。 --- ## EasyCoexistence vs WANotifier https://easycoexistence.com/ja/compare/easycoexistence-vs-wanotifier WANotifier は公式 API 上で動く WhatsApp のマーケティング・通知プラットフォームで、プランと連絡先ティアで料金が決まり、月ごとのメッセージ上限があります。EasyCoexistence は Coexistence に対応した公式接続そのもので、接続済みの番号ごとに課金され、連絡先数やメッセージ数の上限はありません。どちらも Meta のメッセージ料金は上乗せなしでそのまま請求されるため、違いは月額料金で何が手に入るかにあります。 ### 月額料金は何の対価か WANotifier はオーディエンスの規模で料金が決まります。EasyCoexistence は番号の数で決まります。 - WANotifier:: 連絡先 1,000 件未満のティアで、Essentials US$ 69、Advanced US$ 119、Premium US$ 199（いずれも月払い）です。月ごとの送信上限はそれぞれ 4,000 件、8,000 件、12,000 件です。連絡先リストが大きくなると、上位のティアが適用されます。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 から、5 件までの料金で、番号を追加するにつれて US$ 1 まで下がります。連絡先 5 万件のリストでも、50 件のリストでも料金は変わりません。 ### Coexistence の位置づけ どちらも Meta の公式 API で接続し、Coexistence にも対応しているため、WhatsApp Business アプリはそのまま携帯電話で使えます。 - WANotifier:: Coexistence は全プランの機能の一つとして掲載されており、キャンペーン、チャットボット、ドリップ配信、チーム共有の受信トレイと並んでいます。 - EasyCoexistence:: Coexistence が製品のすべてです。セルフサービスの Embedded Signup は約 2 分で完了し、接続状態を継続的に監視します。14 日間のアプリ利用ルールを含め、Meta 自身の切断理由に基づいてアラートを出します。 ### メッセージの届き先 キャンペーンツールは、メッセージをツールの中で処理します。接続は、メッセージをそのままお客様の手元に渡します。 - WANotifier:: WANotifier のダッシュボード、受信トレイ、自動化ビルダーに届きます。連携用の REST API と Webhook は、Advanced と Premium で利用できます。 - EasyCoexistence:: すべての番号で、お客様のエンドポイントに直接届きます。Meta が指定された URL に Webhook を送るためです。当社側には何も保存されません。MCP サーバーにより、Claude、ChatGPT、Cursor からその番号を操作することもできます。 ### どちらを選ぶか 一斉配信、ドリップ配信、チャットボットビルダーを一つのダッシュボードで使いたい場合は、キャンペーンツールを購入することになります。これは接続とは別の製品です。 すでにソフトウェアをお持ちの場合、または開発中の場合は、番号を公式に接続し、接続を維持することが必要です。それが EasyCoexistence で、料金は連絡先数や送信量によって変わりません。Meta のメッセージ料金は、どちらの場合もお客様のアカウントに直接請求されます。 - 付属する月ごとのメッセージ上限を確認せずに、価格だけでプランを選んでしまうことです。 - 月の途中で連絡先リストがティアの境界を超え、上位ティアへの移行分を予算に入れていないことです。 - 上乗せ 0% を、プラットフォーム料金がかからないという意味だと誤解することです。月額料金と Meta の料金は、どちらも発生します。 **EasyCoexistence は WANotifier より安いですか？** はい、接続の料金は EasyCoexistence のほうが安くなります。WANotifier の Essentials は、最小の連絡先ティアで月額 US$ 69 です。EasyCoexistence は接続済みの番号 1 件あたり月額 US$ 9 からで、連絡先数やメッセージ数の上限はありません。 **WANotifier は Coexistence に対応していますか？** はい。料金ページに、すべてのプランで WhatsApp Coexistence が掲載されています。 **どちらも Meta の料金を上乗せなしで請求しますか？** はい。WANotifier は上乗せ 0% を明記しています。EasyCoexistence では、Meta がお客様ご自身のアカウントに直接請求します。 **EasyCoexistence でキャンペーンを送れますか？** 承認済みのテンプレートを、お客様のシステムまたは AI アシスタントから Cloud API 経由で送信できます。キャンペーンビルダーはありません。 --- ## EasyCoexistence と Eazybe の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-eazybe Eazybe は営業チーム向けの CRM レイヤーで、WhatsApp Web に Chrome 拡張機能として導入します。Starter プランはユーザー単位の料金で、上位プランでは WhatsApp API の番号と Coexistence が加わります。EasyCoexistence は公式の接続だけを提供する別のプロダクトです。Meta の Cloud API と Coexistence を使い、番号単位の料金で、メッセージをお客様ご自身のシステムへ届けます。 ### それぞれの WhatsApp への接続方法 2 つのプロダクトは置かれる場所が異なります。一方は担当者のブラウザ、もう一方は Meta の API 上です。 - Eazybe:: 各担当者がすでに開いている WhatsApp Web のセッションの上に Chrome 拡張機能を追加し、ラベル、CRM 同期、スケジュール送信を加えます。上位プランでは WhatsApp API の番号と Coexistence も用意されています。 - EasyCoexistence:: Meta の Cloud API を、Meta の Embedded Signup と Coexistence で登録します。ブラウザのタブでは何も動かないため、WhatsApp Web を開いている人がいなくてもメッセージは流れます。 ### 月額料金の内訳 Eazybe は訪問者の現地通貨で料金を表示し、プランごとに課金単位が変わります。 - Eazybe:: Starter はユーザー 1 人あたり月額です。Scaler、Basic AI、Pro AI は番号 1 件あたり月額で、3 人または 5 人分のユーザーが含まれ、追加ユーザーは別料金です。さらに AI 返信は 1 件ごとに課金されます。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 から、番号を追加するほど US$ 1 まで下がります。ユーザー数による課金も AI クレジットもなく、メッセージ料金は Meta からお客様ご自身のアカウントへ直接請求されます。 ### 会話の届け先 CRM 拡張機能はチャットを CRM にコピーします。接続は、指定したシステムへそのまま転送します。 - Eazybe:: WhatsApp Web から、HubSpot、Zoho、Salesforce など連携している CRM へ、同社のプラットフォームを通じて同期されます。 - EasyCoexistence:: Meta が Webhook として、指定したエンドポイントへ配信します。当社側には保存されません。CRM、アプリ、自動化ツール、MCP サーバー経由の AI アシスタントが直接受け取ります。 ### どちらを選ぶべきか ブラウザ上で各チャットの横に CRM の項目を表示したい営業チームが求めているのは CRM 拡張機能です。Eazybe の Starter プランがそれに当たります。 すべての番号を Meta の公式 API に載せ、ブラウザのセッションに依存したくない企業には、接続そのものが適しています。EasyCoexistence は番号ごとの定額料金で提供し、接続状態を常時監視します。14 日間のアプリ利用ルールが切れる前に警告し、チームは使い慣れた WhatsApp Business アプリをそのまま使えます。 - WhatsApp Web 上のブラウザ拡張機能を API 接続と同じものとして扱うこと。タブが開いていることが前提になります。 - 1 つの番号を何人の担当者で共有するかを数えずに、ユーザー単位のプランと番号単位の料金を比べること。 - すべてのプランに公式 API が含まれていると思い込むこと。Eazybe では Scaler 以上で提供されます。 **EasyCoexistence は Eazybe より安いですか？** チームで 1 つの番号を共有する場合は、安くなります。Eazybe Starter はユーザー単位、API プランは番号単位に加えて追加ユーザーの料金がかかります。EasyCoexistence はチームの人数に関係なく、接続済みの番号 1 件あたり月額 US$ 9 です。 **Eazybe は Coexistence に対応していますか？** Eazybe は、同じ番号で WhatsApp Business アプリと公式 API を併用する Coexistence のページを公開しています。 **EasyCoexistence を使うとき、WhatsApp Web を開いておく必要はありますか？** いいえ。Cloud API は Meta のサーバー上で動き、チームはスマートフォンの WhatsApp Business アプリをそのまま使い続けられます。 **メッセージを CRM に同期できますか？** はい。Meta の Webhook の送信先を、CRM、n8n や Make などの自動化ツール、またはご自身のコードに設定します。 --- ## EasyCoexistence と Superchat の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-superchat Superchat は WhatsApp、Instagram、メールなど複数のチャネルをまとめる統合受信箱で、最低契約期間 12 か月のプランで販売されています。Coexistence のオプションにはベータ版と表示されています。EasyCoexistence が扱うのは一つだけです。Coexistence を通じて WhatsApp の番号を Meta の Cloud API に接続するサービスで、料金は接続済みの番号ごとの月額です。メッセージは御社自身のシステムに届きます。 ### 月額料金は何に対する支払いか Superchat はプランの中でアカウントと番号を数えます。EasyCoexistence が数えるのは番号だけです。 - Superchat:: Basic は月額 US$ 19、Professional は US$ 29、Advanced は US$ 69（いずれも税抜）で、アカウントは 3、6、12 件、WhatsApp の番号は 1、2、4 件です。番号の追加は 1 件あたり月額 US$ 49、ログインの追加は 1 件あたり US$ 19 で、最低契約期間は 12 か月です。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 から、番号を追加するにつれて US$ 1 まで下がります。数えるアカウントやログインはありません。Meta のメッセージ料金は Meta から直接請求されます。 ### Coexistence の提供のされ方 どちらも公式 API で接続し、どちらも Coexistence を提供しているため、WhatsApp Business アプリは携帯電話で使い続けられます。 - Superchat:: 接続方法は 4 種類あるうちの一つです。ほかに、新しい番号、完全な移行、他社プロバイダーからの切り替えがあります。ヘルプセンターには、Coexistence の方法は現在ベータ版で、機能に制限がある場合があると記載されています。 - EasyCoexistence:: 唯一の方法です。Meta の Embedded Signup を使い、セルフサービスで約 2 分で完了します。その後は常時監視され、接続が切れてもお客様が気づく前に検知されます。 ### 会話の届き先 受信箱は担当者のために会話を保管します。接続は会話を先へ渡します。 - Superchat:: Superchat の統合受信箱の中です。テンプレート、ラベル、AI エージェント、レビュー管理が、プラットフォーム内のメッセージに対して動作します。 - EasyCoexistence:: 指定したエンドポイントです。Meta が Webhook をそこへ直接送るためです。会話が EasyCoexistence 側に保存されることはなく、チームは WhatsApp Business アプリをそのまま使えます。 ### どちらを選ぶべきか 複数のチャネルへの返信を一つの受信箱で行いたい企業が購入するのは、複数チャネル対応の受信箱です。WhatsApp の接続とは別の製品になります。 WhatsApp の番号を公式 API に載せたまま維持し、メッセージを自社の CRM、アプリ、AI アシスタントへ送りたい企業には、EasyCoexistence が適しています。番号ごとの定額料金で、Coexistence はベータ版のオプションではなく製品の中核です。 - 月額料金だけを見て、それに付いている最低契約期間を確認しない。 - 番号を増やす必要があるのに、プラン料金だけで計算する。番号の追加には別の月額料金がかかります。 - すでに他社の API プロバイダーに接続されている番号で、Coexistence のオンボーディングを始める。 **EasyCoexistence は Superchat より安いですか？** はい、WhatsApp の接続としては安価です。Superchat Basic は月額 US$ 19 で、最低契約期間は 12 か月です。EasyCoexistence は接続済みの番号 1 件あたり月額 US$ 9 で、チームの人数に関係なく WhatsApp Business アプリで対応できます。 **Superchat は Coexistence に対応していますか？** はい、接続オプションの一つとして対応しています。ただしヘルプセンターではベータ版と表示されています。 **EasyCoexistence は Instagram やメールにも対応していますか？** いいえ。Meta の Cloud API を通じて WhatsApp の番号を接続するだけです。 **Meta のメッセージ料金は誰が支払いますか？** 御社が、ご自身の WhatsApp Business アカウントで Meta に直接支払います。EasyCoexistence が上乗せすることはありません。 --- ## EasyCoexistence と Sinch の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-sinch Sinch は SMS、音声などのチャネルとあわせて WhatsApp を再販する企業向けコミュニケーションプラットフォームで、お客様ごとの契約に基づき、Meta の料金とは別に独自のメッセージ料金を課金します。EasyCoexistence は、WhatsApp Business アプリの番号を Coexistence で Meta の Cloud API に接続するサービスです。セルフサービスで番号ごとの定額制、メッセージ料金は Meta が直接請求します。 ### メッセージ 1 通あたりの料金 違いは、すべてのメッセージに 2 つ目の料金が加わるかどうかです。 - Sinch:: すべてのメッセージに 2 層の料金がかかります。カテゴリと国ごとに決まる Meta の料金と、プラットフォーム利用とメッセージ送信に対する Sinch の料金です。後者は公開料金表ではなく、Sinch との契約で決まります。 - EasyCoexistence:: 料金は 1 層です。Meta の料金はお客様ご自身の WhatsApp Business アカウントに請求され、当社が上乗せすることはありません。当社の料金は、接続済みの番号 1 件あたり月額 US$ 9 から、番号を追加するにつれて US$ 1 まで下がります。通信量には左右されません。 ### それぞれが想定している番号 多くの小規模企業は、すでに WhatsApp Business アプリでお客様に対応しています。重要なのは、その番号です。 - Sinch:: Sinch Engage Classic のセットアップガイドでは、国際 SMS または通話を受信でき、かつどの WhatsApp アカウントにも接続されていない番号が求められます。オンボーディングの記事には、Coexistence での接続方法の説明がありません。 - EasyCoexistence:: すでに WhatsApp Business アプリで使っている番号を、Coexistence で接続します。チャット、履歴、スマートフォンのアプリはそのまま残り、同じ番号で Cloud API も動作します。 ### 利用開始までの流れ 一方は営業契約を経由し、もう一方はサインアップページから始まります。 - Sinch:: Sinch Build ダッシュボードの Embedded Signup は、Sinch の説明では現時点で直接契約の企業顧客のみが利用でき、料金は契約内容によって異なります。 - EasyCoexistence:: Meta の Embedded Signup をセルフサービスで、約 2 分で完了できます。最初の 3 日間は無料です。アプリはバージョン 2.24.17 以降で、直近の実際の利用履歴が必要です。 ### どちらを選ぶべきか SMS、音声、WhatsApp を 1 つの契約でまとめて、交渉した条件のもとで購入する企業が買っているのは CPaaS です。WhatsApp の接続とは別の製品です。 お客様がすでに WhatsApp Business アプリにメッセージを送ってくる企業や、そうした番号をクライアント向けに接続する代理店に必要なのは、Coexistence、公開された料金、そしてメッセージごとの上乗せ料金がないことです。EasyCoexistence はまさにそのために作られており、Meta から御社のシステムへ直接送られる Webhook と、AI アシスタント向けの MCP サーバーを備えています。 - プロバイダーがメッセージごとに独自の料金を加えているのに、Meta の料金表だけで予算を組んでしまう。 - API 用に新しい番号を登録し、お客様がアプリ上の従来の番号に書き込み続ける状態を放置する。 - 番号を空けるために WhatsApp Business アプリのアカウントを削除する。Coexistence なら残したまま使えます。 **EasyCoexistence は Sinch より安いですか？** はい、当社が管理できる部分については安くなります。Sinch は契約に基づき、すべてのメッセージに独自の料金を加えます。EasyCoexistence はメッセージごとの料金がなく、接続済みの番号 1 件あたり月額 US$ 9 から利用できます。 **Sinch は Coexistence に対応していますか？** このページの作成にあたり確認した Sinch のオンボーディング記事では、触れられていません。このページに頼らず、Sinch に直接お問い合わせください。 **Sinch は WhatsApp の料金を公開していますか？** Sinch のヘルプセンターには、料金は契約内容によって異なると書かれており、メッセージごとの公開料金は掲載されていません。 **EasyCoexistence との契約は必要ですか？** いいえ。Meta の Embedded Signup からセルフサービスで登録でき、最初の 3 日間は無料です。 --- ## EasyCoexistence と Vonage の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-vonage Vonage は、Messages API で WhatsApp を SMS や RCS などのチャネルとともに送信できる開発者向けの通信プラットフォームです。Meta の料金に加えて、メッセージごとに Vonage のプラットフォーム料金が加算されます。EasyCoexistence は、WhatsApp Business アプリの番号を Coexistence で Meta の Cloud API に接続し、料金は番号ごとの定額です。メッセージの料金は Meta からお客様に直接請求されます。 ### 請求額の仕組み 従量課金と定額では、ボリュームが増えたときの挙動が異なります。 - Vonage:: Meta の配信メッセージごとの料金に加えて、Vonage のプラットフォーム料金が 1 通あたり 0.0001 ユーロから加算され、ボリュームや地域に応じて変動します。通話にはさらに 1 分あたり US$ 0.004 の Vonage 料金がかかります。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 から、番号を追加するほど US$ 1 まで。メッセージはお客様ご自身の WhatsApp Business Account に対して Meta が請求し、当社がメッセージごとに加算する料金はありません。 ### それぞれが対象とする番号 小規模な企業がすでに応対に使っている番号は、多くの場合 WhatsApp Business アプリの番号です。 - Vonage:: WhatsApp の料金ページと、パートナー向けにホストされた Embedded Signup のガイドでは、アプリを API 番号上で動かし続ける Meta の機能である Coexistence に触れられていません。 - EasyCoexistence:: 対象は Coexistence の番号です。WhatsApp Business アプリはチャット履歴を保ったまま携帯電話で使え続け、同じ番号で Cloud API が、Coexistence の処理能力である毎秒 20 メッセージで動作します。 ### お客様と Meta の間にあるもの どちらも API 製品です。違いは、どの API を呼び出すかです。 - Vonage:: Vonage Messages API は、WhatsApp と他のチャネルを一つにまとめたインターフェースです。コードは Vonage を呼び出し、Vonage が Meta を呼び出します。 - EasyCoexistence:: お客様ご自身のアカウントに発行された認証情報で、Meta が公開している Cloud API を利用します。Webhook は Meta からお客様のエンドポイントへ直接送られます。会話の内容が当社に保存されることはありません。 ### どちらを選ぶか SMS、RCS、メール、WhatsApp を一つの API で扱いたい開発者が求めているのはマルチチャネルの CPaaS であり、WhatsApp の接続とは別の製品です。 WhatsApp Business アプリの番号を Meta 自身の API で使いたい企業や代理店で、メッセージごとの料金や新しい番号を避けたい場合は、Coexistence が必要です。EasyCoexistence ならセルフサービスで約 2 分で接続でき、各接続を常時監視し、MCP サーバー経由で Claude、ChatGPT、Cursor からその番号を利用できます。 - メッセージごとのプラットフォーム料金だけでコストを見積もり、Meta 自身の料金を加えていない。 - Meta の Cloud API は仕様が公開され移行も容易なのに、特定ベンダーのメッセージスキーマに合わせてコードを書いてしまう。 - アプリで稼働中の番号を、CPaaS のオンボーディングがそのまま受け付けると思い込む。 **EasyCoexistence は Vonage より安いですか？** 一定以上のボリュームであれば安くなります。Vonage はメッセージごとにプラットフォーム料金を加算しますが、EasyCoexistence は加算しません。当社の料金は、メッセージ数にかかわらず接続済みの番号 1 件あたり月額 US$ 9 のままです。 **Vonage は Coexistence に対応していますか？** WhatsApp の料金ページとホストされた Embedded Signup のページでは、Coexistence に触れられていません。このページの情報に頼らず、Vonage に直接お問い合わせください。 **今使っている WhatsApp の番号をそのまま使えますか？** はい。Coexistence では、WhatsApp Business アプリで使っている番号を、チャット履歴ごと接続できます。 **WhatsApp メッセージの料金は誰が請求しますか？** Meta が、お客様ご自身の WhatsApp Business Account に対して直接請求します。EasyCoexistence がその料金に上乗せすることはありません。 --- ## EasyCoexistence と Qontak の比較 https://easycoexistence.com/ja/compare/easycoexistence-vs-qontak Mekari Qontak は、公式の WhatsApp API 上で動くインドネシア発のオムニチャネル CRM 兼カスタマーサービス製品です。プランは 5 ユーザーからで、Coexistence には別途サブスクリプションが必要です。EasyCoexistence は接続だけを提供します。WhatsApp Business アプリの番号を Coexistence で Meta の Cloud API に接続し、接続済みの番号ごとに課金します。メッセージはお客様自身のシステムに届きます。 ### 月額料金は何の対価か Qontak が販売するのは CRM 製品です。EasyCoexistence が販売するのは接続です。 - Qontak:: Service Suite と Sales Suite は Plus で月額 Rp2.000.000 から、Ultimate で Rp3.000.000 からです。Qontak 360 は Rp3.500.000 からで、いずれのプランも 5 ユーザーから始まります。 - EasyCoexistence:: 接続済みの番号 1 件あたり月額 US$ 9 から、番号を追加するほど US$ 1 までです。チームの人数に関係なく、アプリから対応する番号 1 件なら US$ 9 です。 ### Coexistence の設定方法 どちらも Meta の Coexistence フローで接続するため、スマートフォンの WhatsApp Business アプリはそのまま使えます。 - Qontak:: Qontak のガイドでは、連携前の要件として、META Coex の有効なサブスクリプション、30 日以上利用されている番号、Facebook のビジネス認証の完了が挙げられています。 - EasyCoexistence:: Coexistence そのものが製品で、追加料金はかかりません。登録はセルフサービスで約 2 分です。条件は、アプリがバージョン 2.24.17 以降であること、最近の実際の利用があること、番号が他のプロバイダーに紐づいていないことです。 ### 会話の行き先 CRM 製品は会話を蓄積して対応に使います。接続は会話を次へ受け渡します。 - Qontak:: Qontak のオムニチャネル受信箱と CRM に届き、WhatsApp Business アプリと同期されます。チケット管理、チャットボット、一斉配信も Qontak のダッシュボードから実行します。 - EasyCoexistence:: お客様が指定したエンドポイントに届きます。Meta が Webhook を直接そこへ送るためです。会話が当社に保存されることはなく、MCP サーバーによって番号を AI アシスタントにも接続できます。 ### どちらを選ぶべきか 営業パイプライン、チケット管理、複数チャネルを 1 つの製品にまとめたい企業が購入するのは CRM です。WhatsApp の接続とは別の製品です。 すでに CRM をお持ちの企業や、顧客の番号を自社のスタックにつなぐ代理店に必要なのは、公式 API 上で接続が維持された番号です。EasyCoexistence は番号ごとの定額料金でそれを提供し、各接続を監視して、Meta の 14 日間のアプリ利用ルールが切れる前にアラートでお知らせします。 - 一般向け WhatsApp アプリに登録された番号を接続しようとすること。Coexistence には WhatsApp Business アプリが必要です。 - 連携のためだけに新しい Business Portfolio を作成すること。Qontak のガイドでもこれは推奨されていません。 - アカウントの問題を解消するためにアプリをリセットすること。履歴は元に戻らず、接続が壊れる場合があります。 **EasyCoexistence は Qontak より安いですか？** はい、接続に関しては安くなります。Qontak のプランは 5 ユーザー以上で月額 Rp2.000.000 からで、Coexistence のサブスクリプションが別に必要です。EasyCoexistence は接続済みの番号 1 件あたり月額 US$ 9 で、Coexistence を含みます。 **Qontak は Coexistence に対応していますか？** はい。ヘルプセンターで連携方法が説明されており、有効な META Coex のサブスクリプションが要件として挙げられています。 **EasyCoexistence では 30 日以上利用された番号が必要ですか？** いいえ。必要なのは WhatsApp Business アプリでの最近の実際の利用です。これは Coexistence に対する Meta 自身の適格性チェックです。 **EasyCoexistence に CRM は含まれますか？** いいえ。メッセージは、Meta がお客様のエンドポイントへ送る Webhook を通じて、既存の CRM やアプリに届きます。 --- ## Coexistence 番号の WhatsApp メッセージを HubSpot に記録する https://easycoexistence.com/ja/integrations/hubspot HubSpot には Communications オブジェクトがあり、チャネルタイプに WHATS_APP を指定できます。HubSpot の外で行われたメッセージを記録するための仕組みです。番号の Webhook を n8n のワークフローに送り、電話番号でコンタクトを検索または作成し、メッセージごとに /crm/v3/objects/communications へ POST します。会話はコンタクトのタイムラインに記録され、チームはこれまでどおり WhatsApp Business アプリから返信できます。 ### WhatsApp メッセージはどのように HubSpot のコンタクトに記録されますか？ 3 つのステップで記録されます。まず Meta が、番号に設定した Webhook の送信先（ここでは n8n の Webhook ノード）へメッセージを届けます。次にワークフローが、送信者の電話番号で HubSpot のコンタクトを検索し、一致するものがなければ新規作成します。最後に、メッセージ本文を持つ communication レコードを作成し、そのコンタクトに関連付けます。 HubSpot はこの用途のために Communications オブジェクトを用意しています。HubSpot の外で送受信された WhatsApp、LinkedIn、SMS のメッセージを表し、記録された通話やメールと同じようにレコードのタイムラインに表示されます。必須のプロパティは、チャネルタイプ、CRM に設定した hs_communication_logged_from、本文、オーナー、タイムスタンプです。 HubSpot のマーケットプレイスアプリは必要ありません。n8n の HTTP Request ノードは、HubSpot ノード用に設定済みの認証情報をそのまま使えます。呼び出しはメッセージごとに POST が 1 回です。 ### スマートフォンから入力した返信も記録できますか？ 記録できます。これが Coexistence 番号ならではの点です。チームの誰かが WhatsApp Business アプリから返信すると、Meta はその送信メッセージのエコーを同じ Webhook の送信先に送ります。受信メッセージとエコーの両方を処理するワークフローなら、会話の両側がタイムラインに書き込まれます。HubSpot でコンタクトを開いた営業担当者は、お客様の質問と自社の返信を一緒に確認できます。 Webhook のフィールドで処理を分岐させてください。受信メッセージは messages、スマートフォンからの返信は smb_message_echoes で届きます。前者を受信、後者を送信として記録すれば、タイムラインは時系列どおりに並びます。 ワークフロー自身が Cloud API で送る返信は、送信の時点で内容が分かっています。Webhook を待たず、送信時に記録してください。 ### HubSpot 独自の WhatsApp 受信トレイチャネルとは何が違いますか？ 別の連携です。HubSpot の会話受信トレイは WhatsApp の番号を HubSpot 自体に接続するもので、ナレッジベースには、その番号を他の WhatsApp 連携に接続してはならないと記載されています。利用できるのは Marketing Hub または Service Hub の Professional と Enterprise です。 EasyCoexistence で接続した番号は逆の流れになります。Meta が Webhook をお客様自身の URL に送り、HubSpot は API 経由でレコードを受け取ります。会話への返信はスマートフォンまたはワークフローから行い、HubSpot はコンタクト、取引、チケットに紐づく履歴を保持する記録システムになります。 この呼び出しには、実行する非公開アプリまたは認証情報にコンタクトの書き込みスコープが必要です。ワークフローがコンタクトを作成するために、もともと必要なスコープと同じです。 ### ワークフローは送信者とコンタクトをどう照合すべきですか？ 電話番号で照合します。ただし検索の前に正規化してください。Meta は送信者を、国番号付きで + を含まない数字だけの形式（例: 14155550188）で送ってきます。一方、HubSpot のコンタクトは手入力のため、同じ人が +1 415 555 0188 や (415) 555-0188 の形で保存されていることがあります。 確実な方法は、数字だけの番号を保持する専用のコンタクトプロパティを用意することです。ワークフローがコンタクトを作成するときにその値を設定し、検索もそのプロパティで行います。標準の電話番号フィールドを直接検索すると、ワークフローが作成したコンタクトは見つかりますが、人が作成したコンタクトの多くは見つからず、重複の原因になります。 検索で何も見つからなかった場合は、Webhook のペイロードにあるプロフィール名を名として、数字だけの番号を両方のフィールドに入れてコンタクトを作成します。統合や名前の変更は後から担当者が行えますし、会話はすでに紐づいています。 - 受信メッセージだけを記録してしまうこと。スマートフォンで入力した返信は smb_message_echoes イベントとして届くため、記録しないとタイムラインには質問だけが残り、回答がありません。 - hs_communication_logged_from を未設定のままにすること。API で communication を作成するとき、HubSpot はこの値を CRM にするよう求めます。 - 生の電話番号フィールドでコンタクトを検索すること。Meta の数字だけの形式は、人が入力した値とほとんど一致せず、一致しないたびに重複コンタクトが作られます。 **HubSpot の中からお客様に返信できますか？** Communications オブジェクトは記録用のため、そこからは返信できません。返信は WhatsApp Business アプリか、Cloud API を呼び出すワークフローから送ります。どちらの返信もコンタクトに記録されます。 **ワークフローにはどの HubSpot の権限が必要ですか？** コンタクトの読み取りと書き込みです。HubSpot は Communications API のスコープとして crm.objects.contacts.read または crm.objects.contacts.write を挙げています。コンタクトの作成にはもともと書き込みスコープが必要です。 **同じワークフローから最初のメッセージも送れますか？** 送れます。n8n に別の分岐を作り、承認済みのメッセージテンプレートを、番号の `phone_number_id` とアクセストークンを使って Cloud API 経由で送信します。その後、送信済みの communication としてコンタクトに記録します。 **EasyCoexistence はメッセージの内容を途中で保存しますか？** 保存しません。Meta は Webhook をお客様の n8n の URL へ直接届けます。EasyCoexistence が会話の内容を保存することはありません。 --- ## Coexistence 番号の WhatsApp 会話を Salesforce に送る https://easycoexistence.com/ja/integrations/salesforce この番号の Webhook を n8n のワークフローに送り、Salesforce で phone を条件に SOQL クエリを実行して送信者を検索します。該当がなければリードを作成し、各メッセージを ToDo またはレコード上のメモとして記録します。n8n の Salesforce ノードで 3 つの呼び出しすべてに対応できます。チームは WhatsApp Business アプリでの返信を続けられ、履歴は Salesforce に残ります。 ### n8n のワークフローはどのような構成ですか？ 4 つのノードを一列に並べ、Meta のすべての Webhook に必要な認証ブランチを加えた構成です。 まず Webhook ノードが、メッセージごとに Meta から送られる POST を受け取ります。次に Salesforce ノードが、phone が送信者と一致するリードまたは取引先責任者を SOQL クエリで検索します。IF ノードで結果の有無を分岐し、見つかった場合はレコード ID をそのまま次へ渡します。見つからない場合は、ペイロードのプロフィール名でリードを作成する Salesforce ノードに進みます。最後の Salesforce ノードが、そのレコードに ToDo を作成します。説明欄にメッセージ本文を入れ、件名には WhatsApp メッセージであることを記します。 認証ブランチは、Meta の GET リクエストに対して hub.challenge の値をそのまま本文として返します。これがないと Meta は配信を開始せず、残りのワークフローは動きません。 ### メッセージは ToDo とメモのどちらに記録すべきですか？ 多くのチームには ToDo をお勧めします。営業担当者がすでに見ている活動タイムラインに表示され、レポートにも使えるためです。状況を完了にしておけば未完了の ToDo として表示されません。件名にチャネル名を入れておけば、WhatsApp の活動を絞り込む条件は 1 つで済みます。 n8n ノードの「Add note」操作は、別の用途に向いています。メッセージごとではなく要約を残したい場合です。1 日分のメッセージを連絡先ごとにまとめ、夜に 1 件のメモとして書き込むワークフローもあります。お客様が短い文を 20 通送ってきても、タイムラインが読みやすいままです。 どちらを選ぶ場合も、WhatsApp のメッセージ ID をレコードに書き込んでください。Meta は配信を再試行するため、書き込む前に既存の ID を確認すれば、同じメッセージを二重に記録することはありません。 ### 電話からの返信は引き続き可能ですか。また Salesforce に反映されますか？ どちらも可能です。Coexistence では同じ番号で WhatsApp Business アプリが使い続けられるため、これまでお客様に返信していた担当者はそのまま対応できます。アプリから返信すると、Meta は送信メッセージのエコーを同じ Webhook の宛先に、smb_message_echoes フィールドとして送ります。 ワークフローにこのエコー用の 2 つ目の経路を追加し、送信側の ToDo として記録します。リードを開いた担当者には、お客様の質問と店舗側の回答が順番に表示され、チャットを手作業でコピーする必要はありません。 ワークフロー自身が Cloud API に対して HTTP Request ノードで送る返信は、送信した時点で記録してください。その時点で、本文とレコード ID はすでにワークフローの手元にあります。 ### リードの重複を防����にはどうすればよいですか？ 入力されたままの項目ではなく、正規化した電話番号で照合します。Meta は送信者を、国番号を含みプラス記号のない数字だけで送ってきます。一方、Salesforce の電話項目には、レコードを作成した人が入力した内容がそのまま入っており、スペースやかっこ、ハイフンが含まれます。 確実なのは、数字だけの番号を保持するカスタムのテキスト項目を用意する方法です。ワークフローがリードを作成するときにその項目を埋め、既存のレコードにはバックフィルで値を入れます。SOQL クエリはこの項目を完全一致で比較するため、高速かつ正確です。 リードだけでなく取引先責任者も検索してください。すでに成約したお客様は取引先責任者になっています。リードしか検索しないワークフローでは、既存のお客様が連絡してくるたびに新しいリードが作られてしまいます。 - Lead オブジェクトだけを検索している。既存のお客様は取引先責任者なので、連絡のたびに重複したリードが作られます。 - メッセージを未完了の ToDo として記録している。お客様の発言ごとに担当者へ ToDo が発生するので、作成時に状況を完了にしてください。 - ワークフローで認証用の GET ブランチを省略している。Meta が宛先を確認できず、メッセージは一切配信されません。 **この連携に Salesforce AppExchange のパッケージは必要ですか？** いいえ、不要です。n8n 標準の Salesforce ノードで検索、リード作成、ToDo 作成まで対応できます。ノードにない操作は、同じ認証情報を使った HTTP Request ノードで補えます。 **Make でも同じことはできますか？** はい、できます。Make のカスタム Webhook でメッセージを受け取り、Salesforce モジュールでレコードを書き込みます。シナリオの構成は n8n のワークフローと手順ごとに一致します。 **Salesforce からリードに WhatsApp のテンプレートを送れますか？** ワークフローを介せば可能です。Salesforce から n8n の Webhook を呼び出し、n8n が承認済みのメッセージテンプレートを、その番号の phone number id とトークンを使って Cloud API 経由で送信します。 **EasyCoexistence はメッセージのコピーを保存しますか？** いいえ、保存しません。Meta は各 Webhook をお客様の n8n の URL に直接配信し、EasyCoexistence が会話の内容を保存することはありません。 --- ## Coexistence 番号で WhatsApp を Zoho CRM に接続する https://easycoexistence.com/ja/integrations/zoho-crm 番号の Webhook を n8n のワークフローに送り、phone パラメーターで Zoho CRM を検索します。このパラメーターはモジュール内のすべての電話番号項目を確認します。一致がなければリードを作成し、各メッセージをそのレコードのノートとして追加します。n8n の Zoho CRM ノードはリードとコンタクトを扱い、ノートは同じ認証情報を使って Zoho の Notes API を HTTP で 1 回呼び出すだけです。 ### WhatsApp のメッセージはどのように Zoho CRM のレコードになりますか？ Meta は、番号に届いたすべてのメッセージを、設定した Webhook の送信先に送ります。ここでは n8n の Webhook ノードです。ワークフローはペイロードから送信者の番号を取り出し、その番号を phone に指定して Zoho の検索エンドポイントを呼び出します。対象はまずリード、次にコンタクトです。Zoho はモジュール内のすべての電話番号項目を確認するため、Mobile と Phone のどちらに登録されていても一致します。営業担当者がどの項目を使ったかを推測する必要はありません。 一致するレコードがなければ、n8n の Zoho CRM ノードが WhatsApp のプロフィール名と番号でリードを作成します。どちらの場合でも、ワークフローはレコード ID を持っているので、POST /Notes を通じてそのレコードにメッセージをノートとして書き込みます。ノートに必要なのは Note_Content と、モジュールとレコードを示す Parent_Id だけです。 ### n8n の認証情報にはどの Zoho 権限が必要ですか？ 検索と書き込みを行うモジュールの読み取りと作成、さらに Notes の作成権限が必要です。Zoho ではノートのスコープを ZohoCRM.modules.notes.CREATE と呼び、親モジュールの作成スコープも併せて求めます。そのため、リードは作成できてもノートのスコープが付与されていない認証情報では、最後のステップで認可エラーになります。 n8n の Zoho CRM ノードは、リード、コンタクト、アカウント、商談、各種営業ドキュメントに対応し、作成、upsert、取得、全件取得、更新、削除ができます。ただしノートはリソースに含まれないため、ノートは HTTP Request ノードで書き込みます。このノードでは、すでに接続した Zoho の認証情報を再利用できるので、管理する OAuth の許可は 2 つではなく 1 つで済みます。 API ドメインは、利用している Zoho のデータセンターに合わせて設定してください。EU リージョンで作成した認証情報は、zohoapis.com ではなく zohoapis.eu を呼び出します。 ### Zoho CRM は何件のメッセージを処理できますか？ Zoho は API をクレジット制で計測しており、24 時間のローリング期間ごとの上限は、エディションとユーザー数によって決まります。Free エディションは 5,000 です。Standard は 50,000 に 1 ユーザーあたり 250 を加えた数、Professional は 50,000 に 1 ユーザーあたり 500、Enterprise は 50,000 に 1 ユーザーあたり 1,000 を加えた数で、いずれもエディションごとの上限があります。 受信メッセージ 1 件につき、検索とノートの書き込みが 1 回ずつ、初めての送信者ではさらにリードの作成が発生します。小規模な企業の番号であれば、有料エディションの上限には十分収まります。先に問題になるのは、たいてい同時実行数です。Free は同時 5 件、Standard は同時 10 件までなので、一斉送信への返信が集中するとキューに溜まることがあります。Zoho から上限エラーが返る場合は、n8n のワークフローを 1 件ずつ処理する設定にしてください。 ### 電話から送った返信も Zoho CRM に届きますか？ 届けることができます。Coexistence の番号では WhatsApp Business アプリがそのまま使えます。そこから誰かが返信すると、Meta はその送信メッセージのエコーを、smb_message_echoes フィールドとして同じ Webhook の送信先に送ります。 ワークフローにエコー用の分岐を作り、送信済みと分かるタイトルを付けてノートとして書き込んでください。Zoho でリードを開いた営業担当者は、会話の双方のやり取りを読めるようになり、CRM にスクリーンショットを貼り付ける必要もなくなります。 ワークフロー自身が Cloud API で送るメッセージも同様です。たとえば商談のステージが変わったときに送る承認済みテンプレートは、送信の時点で記録するのが最適です。その時点でワークフローが本文とレコード ID を保持しているからです。 - 認証情報にリードのスコープだけを付与し、ZohoCRM.modules.notes.CREATE を付与していない。検索とリードの作成までは動きますが、その後のノートがすべて失敗します。 - 別の Zoho データセンターのアカウントから zohoapis.com を呼び出している。アカウントが属するリージョンの API ドメインを使ってください。 - リードだけを検索している。成約済みのお客様はコンタクトにいるため、その方が連絡してくるたびに重複したリードが新しく作られます。 **これは Zoho 自身の WhatsApp 連携の代わりになりますか？** 別のアプローチです。ここでは番号を EasyCoexistence 経由で接続したまま、Zoho CRM が API を通じてレコードを受け取り、チームは電話またはワークフローから返信します。 **n8n の代わりに Make を使えますか？** はい。Make のカスタム Webhook でメッセージを受け取り、Zoho CRM のモジュールまたは HTTP モジュールで、検索、リード作成、ノート書き込みを行えます。 **商談のステージ変更で WhatsApp のテンプレートを送れますか？** はい、ワークフローを通じて送れます。ステージ変更時に n8n の Webhook URL を呼び出すようにすると、n8n が番号の phone number id とトークンを使い、Cloud API で承認済みテンプレートを送信します。 **メッセージは EasyCoexistence に保存されますか？** いいえ。Meta は Webhook をお客様の n8n の URL に直接送ります。EasyCoexistence が会話の内容を保存することはありません。 --- ## Coexistence の番号で WhatsApp と Pipedrive を接続する https://easycoexistence.com/ja/integrations/pipedrive 番号の Webhook を n8n のワークフローに送り、電話番号で Pipedrive の人物を検索します。一致する人物がいなければ、人物とリードを作成し、各メッセージを人物または取引のメモとして書き込みます。これらはすべて n8n の Pipedrive ノードで実行できます。チームはこれまでどおり WhatsApp Business アプリから返信でき、その返信も記録できます。 ### WhatsApp のメッセージは、どのように Pipedrive の人物に届きますか？ Meta は、番号宛てのメッセージを設定した Webhook の送信先に送信します。ここでは n8n の Webhook ノードです。ワークフローは送信者の番号で Pipedrive の人物を検索します。Pipedrive の人物検索は電話番号フィールドを対象にでき、完全一致のフラグも使えます。人物が見つかれば、その ID を使います。見つからなければ、WhatsApp のプロフィール名と番号で人物を作成し、その人物に紐づくリードを作成します。これにより、初めて連絡してきた相手のメッセージが Leads Inbox に表示され、担当者が見込みを判断できます。 メッセージ本文はメモになります。Pipedrive のメモに必要なのは内容だけで、HTML も使えます。あわせて、人物、取引、組織、リードのいずれかの ID が 1 つ以上必要です。進行中の取引があれば取引に、なければ人物に紐づけてください。 ### なぜ検索のステップが最初に制限に達するのですか？ Pipedrive では、検索に別枠のはるかに小さい上限が設けられているためです。一般的な API 呼び出しは、ユーザーごとに直近 2 秒間のスライディングウィンドウで制限され、API トークンを使う Lite では 20 リクエスト、Ultimate では 120 リクエストまでです。Search API は、全プランで 2 秒あたり 10 リクエストに制限されています。 あまりメッセージが来ない番号なら、制限に気づくことはありません。しかし、数百人の顧客にテンプレートを送り、1 分間に 50 件の返信が届くような番号では制限に達します。返信のたびに検索が始まるためです。ワークフローは 429 レスポンスを受け取り、リトライがなければメモが失われます。 対策は 2 つあります。Pipedrive の検索ノードで、待機付きのリトライを有効にします。そして、電話番号から人物 ID へのマッピングを、n8n のワークフローの静的データか小さなテーブルにキャッシュします。そうすれば、同じ顧客が続けて 6 件送っても、検索は 6 回ではなく 1 回で済みます。 ### スマートフォンから入力した返信も記録できますか？ はい、できます。Coexistence では同じ番号で WhatsApp Business アプリを使い続けられます。チームの誰かがアプリから返信すると、Meta は送信したメッセージのエコーを、smb_message_echoes フィールドで同じ Webhook の送信先に送ります。 このエコー用の分岐を追加し、送信済みと分かるようにメモとして記録します。チームが活動件数でレポートしている場合は、完了済みの活動として記録してもかまいません。取引を開いた営業担当者は、顧客の質問とお店の回答を時系列で確認できます。 取引のステージが変わったときのテンプレートのように、ワークフロー自身が送るメッセージは、送信した時点でメモを記録してください。ワークフローは本文と取引 ID をすでに持っているため、Webhook を待つ必要はありません。 ### 電話番号はどのように正規化すればよいですか？ 国番号を含む数字だけの形にします。Meta が送ってくる形式がそうだからです。送信者は 14155550188 のように届きますが、Pipedrive に手入力された人物は +1 (415) 555-0188 のようになっていることがあります。 ワークフローが人物を作成するときは、この数字だけの形式で番号を保存してください。そうすれば、自分で作成した記録は常に一致します。手入力で作成された人物については、n8n で既存の電話番号を同じ形式に書き換える一度限りの整理をおすすめします。最初の 1 週間で元が取れます。これを行わないと、完全一致の検索ではチームが入力した人物が見つからず、ワークフローがそれぞれに重複を作成してしまいます。 チームが元の表記のほうが読みやすいと感じる場合は、元の書式を 2 つ目の電話番号として残してください。Pipedrive の人物には、複数の電話番号を登録できます。 - キャッシュなしで、メッセージごとに検索を 1 回実行している。返信が集中すると Search API の 2 秒あたり 10 リクエストの上限に達し、メモが失われます。 - 新規の人物ごとではなく、メッセージごとにリードを作成している。Leads Inbox に同じ顧客のコピーがあふれます。 - 取引が進行中なのに、メモを人物だけに紐づけている。取引を担当する営業が、やり取りを見られなくなります。 **メッセージは Pipedrive の Messaging の受信トレイに表示されますか？** いいえ。この方法では、Pipedrive の API を通じてメモとリードを書き込みます。会話への返信は WhatsApp Business アプリまたはワークフローから行い、その内容が人物または取引に記録されます。 **n8n の代わりに Make や Zapier を使えますか？** はい。カスタム Webhook またはキャッチフックでメッセージを受け取り、Pipedrive のステップか HTTP ステップで、人物、リード、メモを同じ順序で書き込みます。 **取引のステージ変更で WhatsApp のテンプレートを送れますか？** はい、ワークフローを通じて送れます。ステージの変更で n8n の Webhook URL を呼び出すと、n8n が承認済みのテンプレートを、その番号の phone_number_id とトークンを使って Cloud API 経由で送信します。 **EasyCoexistence はメッセージを保存しますか？** いいえ。Meta は各 Webhook を、お客様の n8n の URL に直接配信します。EasyCoexistence が会話の内容を保存することはありません。 --- ## Coexistence 番号の WhatsApp を Bitrix24 CRM に接続する https://easycoexistence.com/ja/integrations/bitrix24 番号の Webhook を n8n のワークフローに送り、Bitrix24 の受信 Webhook URL を使って呼び出します。crm.duplicate.findbycomm で送信者の電話番号を持つリード、連絡先、会社を探し、該当がなければ crm.lead.add でリードを作成し、crm.timeline.comment.add でメッセージをレコードのタイムラインに書き込みます。チームは引き続き WhatsApp Business アプリから返信できます。 ### n8n は Bitrix24 とどのように連携しますか？ 受信 Webhook を使います。Bitrix24 の受信 Webhook はイベントを受け取る口ではなく、認証情報の役割を持ちます。Bitrix24 の開発者向けリソースで作成し、使用できるスコープを選ぶと、ポータルのアドレス、作成したユーザーの ID、秘密コードを含む URL が発行されます。この URL の末尾にメソッド名を付けると、そのユーザーの権限で REST API を呼び出せます。 そのため n8n では、Bitrix24 に対する各ステップを、この URL に crm.lead.add.json のようなメソッドを付けて POST する HTTP Request ノードとして組みます。OAuth の手順を踏む必要はなく、アプリを公開する必要もありません。Webhook には CRM スコープだけを付与してください。また、Bitrix24 はそのユーザーの権限でアクセスを確認するため、ワークフローが参照すべきリードと連絡先をすべて見られるユーザーで作成してください。 ### ワークフローはどの Bitrix24 メソッドを呼び出しますか？ n8n の Webhook ノードが Meta からメッセージを受け取った後、次の 3 つを順に呼び出します。 crm.duplicate.findbycomm に type として PHONE と送信者の電話番号を渡すと、その番号を持つリード、連絡先、会社の ID が返ります。3 種類を一度に検索でき、テキスト項目ではなく連絡先情報での照合を目的に作られているため、この検索に適しています。 何も返らなかった場合は、crm.lead.add で WhatsApp のプロフィール名をタイトルに、電話番号を電話項目に入れたリードを作成します。続いて crm.timeline.comment.add に ENTITY_TYPE、ENTITY_ID、COMMENT を渡し、メッセージ本文をレコードへのコメントとして書き込みます。コメントは通話やメールと並んでタイムラインに表示されるので、営業担当者がいつも見ている場所で確認できます。 ### レート制限はワークフローの設計にどう影響しますか？ Bitrix24 は REST 呼び出しをリーキーバケット方式で制限しています。リクエストのたびにカウンターが加算され、カウンターは毎秒一定量ずつ減り、しきい値を超えると次のリクエストには 503 と QUERY_LIMIT_EXCEEDED が返ります。Enterprise プランではカウンターが毎秒 5 ずつ減り、しきい値は 250 です。それ以外のプランでは毎秒 2 ずつ減り、しきい値は 50 です。 受信メッセージ 1 件につき呼び出しは 2、3 回なので、一定のペースで届く間はしきい値に近づきません。問題になるのはバーストです。同じメッセージテンプレートに 1 分以内に 50 人のお客様が返信すると、最大 150 回の呼び出しになります。HTTP Request ノードは失敗時に短い待機を挟んで再試行する設定にし、ワークフローの実行は 1 件ずつ処理するようにしてください。そうすれば、バーストが弾かれることなく Bitrix24 へ順に流れ込みます。 ### スマートフォンで入力した返信も Bitrix24 に届きますか？ 届けられます。Coexistence の番号では WhatsApp Business アプリが引き続き使えます。アプリから返信すると、Meta は送信メッセージのエコーを smb_message_echoes フィールドとして、同じ Webhook の送信先に送ります。 ワークフローに 2 つ目の分岐を設け、このエコーも受信メッセージと同じ方法で処理し、コメントには送信メッセージであることを示す印を付けます。これでレコードには、お客様の発言と店舗側の返信が順番に並んだ会話全体が残ります。 ワークフロー自身が Cloud API で送る返信は、送信する時点ですでにワークフローの手元にあります。Webhook が戻ってくるのを待たず、送信と同時に記録してください。 - 受信 Webhook の URL をクライアント側のコードや共有ドキュメントに貼り付けること。URL に含まれる秘密コードで、その Webhook に付与したすべてのスコープが使えてしまいます。 - すべてのリードを見られないユーザーで Webhook を作成すること。検索で既存のレコードを見落とし、ワークフローが重複を作ってしまいます。 - 再試行なしでバースト的に呼び出しを送ること。Bitrix24 が 503 QUERY_LIMIT_EXCEEDED を返し、そのメッセージはタイムラインに届きません。 **会話は Bitrix24 のオープンチャネルに表示されますか？** このワークフローでは表示されません。CRM REST API を通じてリードとタイムラインのコメントを書き込む方式で、会話への返信は WhatsApp Business アプリか、ワークフローから行います。 **n8n の代わりに Make を使えますか？** はい。Make のカスタム Webhook でメッセージを受け取り、HTTP モジュールで受信 Webhook URL に対して同じ 3 つのメソッドを呼び出します。 **Bitrix24 のデータをもとに WhatsApp のメッセージテンプレートを送れますか？** はい。n8n が Bitrix24 から必要な情報を読み取り、承認済みのメッセージテンプレートを、番号の phone_number_id とアクセストークンを使って Cloud API 経由で送信します。 **EasyCoexistence はメッセージを保存しますか？** いいえ。Meta がそれぞれの Webhook を直接お客様の n8n URL に配信します。EasyCoexistence が会話の内容を保存することはありません。 --- ## WhatsApp の連絡先を RD Station Marketing のコンバージョンに変える https://easycoexistence.com/ja/integrations/rd-station 番号の Webhook を n8n のワークフローに転送し、送信者ごとに api.rd.services/platform/conversions へ API キー付きでコンバージョンイベントを POST します。RD Station はメールの代わりに電話番号でも受け付けるため、メールのない WhatsApp の連絡先でもリードとして登録され、タグが付き、オートメーションフローにすぐ使えます。チームはこれまでどおり携帯電話から返信できます。 ### WhatsApp のメッセージはどのように RD Station のリードになりますか？ Meta は、番号に届いた各メッセージを、設定した Webhook の送信先、ここでは n8n の Webhook ノードに送ります。ワークフローはペイロードから送信者の電話番号とプロフィール名を読み取り、RD Station Marketing のコンバージョンエンドポイントに HTTP POST を 1 回送ります。API キーはクエリ文字列に入れます。 ボディには、CONVERSION を設定した event_type、CDP を設定した event_family、そして任意で決められる conversion_identifier（例: whatsapp-inbound）を含むペイロードを入れます。ペイロードの中には name、mobile_phone、必要なタグを入れます。RD Station は新規の連絡先であれば作成し、既存の場合も含めてコンバージョンを記録します。そのため、連絡先の履歴には WhatsApp から来たことと、その日時が残ります。 そこから先は通常の RD Station の使い方です。コンバージョンやタグでセグメントを作り、オートメーションフローに任せてください。 ### メッセージごとにコンバージョンとして記録すべきですか？ いいえ。ここが設計上もっとも重要な判断です。お客様が短いメッセージを続けて 8 通送ると、コンバージョンが 8 件記録され、レポートが水増しされるうえ、同じオートメーションフローが 8 回起動することもあります。 コンバージョンにするのは、その番号からの最初のメッセージ、または一定期間（例えば 30 日）あいたあとの最初のメッセージにします。n8n では、番号ごとの最終コンバージョン日をワークフローの静的データや小さなテーブルに保持し、直近であれば呼び出しをスキップできます。 初回の連絡より細かい区別をしたい場合は、別々の conversion_identifier を使います。プロモーション用テンプレートへの返信、特定のキーワードを含むメッセージ、インタラクティブメッセージのボタンのタップは、それぞれ独立したコンバージョンにできます。これにより、区別のない 1 本の流れではなく、整理されたセグメントを RD Station 上に作れます。 ### RD Station から WhatsApp メッセージを送り返せますか？ ワークフローを介せば可能です。RD Station Marketing は、リードがコンバージョンしたときや商談として設定されたときに Webhook を送れます。受け取る側の n8n の Webhook から、承認済みの WhatsApp メッセージテンプレートを Cloud API 経由で送信します。このとき、EasyCoexistence のダッシュボードにある番号の phone_number_id とアクセストークンを使います。 ここでテンプレートが重要になるのは、リードが直近 24 時間以内にメッセージを送っていない場合があるためです。この時間枠の外では、Meta が承認したテンプレートだけが配信され、フリーテキストは失敗します。時間枠の内であれば、通常のテキスト返信が使えます。 携帯電話の WhatsApp Business アプリにも、これらの送信済みメッセージが表示されます。Coexistence により、アプリと API が同じ番号を共有するためです。電話でその会話を引き継いだ営業担当者は、自動化がすでに何を伝えたかを確認できます。 - メッセージごとにコンバージョンを送ってしまう。よくメッセージを送るお客様 1 人が多数のコンバージョンとして記録され、同じオートメーションフローが繰り返されます。 - 誰でも読めるブラウザのページから API キーを POST する。呼び出しは n8n のワークフロー内で行い、キーを非公開に保ってください。 - 24 時間以内にメッセージを送っていないリードに、RD から起動したフローでフリーテキストを送る。その場合に配信されるのは、承認済みのテンプレートだけです。 **この RD Station の呼び出しに OAuth は必要ですか？** いいえ。コンバージョンエンドポイントは、クエリ文字列の API キーで認証します。コンバージョンイベントの送信は、まさにこのキーの用途です。 **WhatsApp の連絡先にメールがない場合はどうなりますか？** 電話番号を送ってください。RD Station がコンバージョンにメールを必須とするのは、電話番号が含まれていない場合だけです。 **n8n の代わりに Make や Zapier を使えますか？** はい。Webhook を受信して HTTP POST を送れるツールであれば、同じコンバージョンのボディを RD Station に送れます。 **EasyCoexistence はメッセージを保存しますか？** いいえ。Meta はお客様の n8n の URL に Webhook を直接配信し、EasyCoexistence が会話の内容を保存することはありません。 --- ## Coexistence の番号で WhatsApp を GoHighLevel のコンタクトに連携する https://easycoexistence.com/ja/integrations/gohighlevel 番号の Webhook を n8n のワークフローに送り、n8n の HighLevel ノードで送信者を HighLevel のコンタクトとして upsert し、各メッセージを POST /contacts/{contactId}/notes でノートとして書き込みます。認証にはサブアカウントの設定で発行する Private Integration トークンを使います。phone_number_id とサブアカウントの対応表を持てば、1 つのワークフローですべてのクライアントに対応できます。 ### WhatsApp のメッセージはどのように HighLevel のコンタクトに届きますか？ Meta は、番号に届いたメッセージをすべて、設定した Webhook の送信先に POST します。ここでは n8n の Webhook ノードです。ワークフローは送信者の電話番号と WhatsApp のプロフィール名を n8n の HighLevel ノードに渡します。このノードのコンタクトリソースには作成または更新の操作があるため、新しい送信者はコンタクトになり、既知の送信者は重複せずに見つかります。 コンタクト ID が得られたら、HTTP Request ノードでメッセージ本文を /contacts/{contactId}/notes に POST します。ノートはコンタクトのレコードに表示され、開いた人は誰でもお客様が何を書いたかを確認できます。フォローアップが必要なメッセージの場合は、HighLevel ノードでコンタクトにタスクを作成したり、パイプラインに商談を作成したりすることもできます。どちらもノードが直接サポートしています。 チームは、これまでどおり WhatsApp Business アプリから返信を続けられます。 ### ワークフローにはどのトークンを使うべきですか？ Private Integration トークンです。HighLevel の API v2 には OAuth かこのトークンのどちらかでアクセスし、旧 v1 の API キーはすでにサポートが終了しています。Private Integration トークンはサブアカウントの設定で作成し、チェックを入れた権限にスコープが限定され、他のアクセストークンと同じく Authorization ヘッダーで送信します。 このトークンは自動では更新されません。これは自動化には好都合で、誰かがローテーションするまで使い続けられます。ローテーションすると、HighLevel は古いトークンと新しいトークンを 7 日間どちらも有効にします。この期間内に新しいトークンを n8n に貼り付けてください。 スコープは、ワークフローに必要なものだけにチェックを入れてください。コンタクトとノート、使う場合は商談とタスクです。設定に Private Integrations が見つからない場合は、HighLevel の案内に従い、Labs で有効にしてください。 ### 1 つのワークフローで複数のクライアントのサブアカウントに対応するには？ 受信した番号でルーティングします。Meta が送るすべての Webhook には、メッセージを受け取った企業の番号の phone_number_id が含まれています。すべてのクライアントの番号を同じ n8n の Webhook に向け、各 phone_number_id をそのクライアントのサブアカウントとトークンに対応づける小さなテーブルを用意し、実行の最初にトークンを引き当てます。 これにより、全クライアントに対して保守するワークフローは 1 つで済みます。代理店にとっては特に大きな利点です。照合ロジックやノートの形式を修正すれば、全員に一度に反映されます。 レート制限はアプリごと、サブアカウントごとにカウントされるため、クライアント同士で枠を奪い合うことはありません。それぞれに 10 秒あたり 100 リクエスト、1 日 200,000 件が割り当てられます。 ### スマートフォンで入力した返信も HighLevel に届きますか？ 届けられます。Coexistence の番号では WhatsApp Business アプリを引き続き使え、そこから返信すると、Meta は送信したメッセージのエコーを同じ Webhook の送信先に smb_message_echoes フィールドで送ります。 このエコー用の分岐を追加し、送信済みと分かる形でノートに書き込んでください。コンタクトのレコードには、お客様の発言と企業の返信が順番に並びます。クライアントが CRM を開いたときに期待する表示です。 ワークフロー自身が Cloud API でメッセージを送る場合は、たとえば予約確定後に承認済みのテンプレートを送るときなどに、送信の時点でノートを書き込みます。ワークフローは本文とコンタクト ID をすでに持っています。 - v1 の API キーを使うこと。HighLevel の v1 API はサポートが終了しています。API v2 には Private Integration トークンか OAuth が必要です。 - 7 日間の重複期間内に n8n を更新せずに Private Integration トークンをローテーションすること。古いトークンが失効すると、すべての呼び出しが失敗します。 - すべてのクライアントのメッセージを 1 つのサブアカウントのトークンで書き込むこと。先に phone_number_id を正しいサブアカウントに対応づけないと、レコードが別のクライアントに入ってしまいます。 **メッセージは HighLevel の Conversations タブに表示されますか？** このワークフローでは表示されません。API 経由で書き込むのはコンタクト、ノート、タスク、商談で、会話への返信は WhatsApp Business アプリまたはワークフローから行います。 **n8n の代わりに Make や Zapier を使えますか？** はい。カスタム Webhook またはキャッチフックでメッセージを受信し、HTTP ステップで同じトークンを使って HighLevel の API v2 を呼び出します。 **予約が入ったら WhatsApp で確認メッセージを送れますか？** はい、ワークフローで可能です。HighLevel が n8n の Webhook URL を呼び出すと、n8n が番号の phone_number_id とトークンを使い、Cloud API で承認済みのテンプレートを送信します。 **EasyCoexistence はメッセージを保存しますか？** いいえ。Meta は各 Webhook をお客様の n8n の URL に直接配信し、EasyCoexistence が会話の内容を保存することはありません。 --- ## Coexistence の番号を Chatwoot の WhatsApp Cloud インボックスとして使う https://easycoexistence.com/ja/integrations/chatwoot Chatwoot の WhatsApp Cloud インボックスで入力する値は 3 つです。WhatsApp Business Account の ID、電話番号 ID、アクセストークンです。Coexistence の番号なら、この 3 つがすべて揃います。これらでインボックスを作成し、番号の Webhook 送信先を Chatwoot の Webhook URL に設定して同じ認証トークンを入力すれば、チームは Chatwoot から、担当者は携帯電話から返信できます。 ### Coexistence の番号を Chatwoot に接続するには？ 2 か所で、次の順に設定します。 Chatwoot でインボックスを追加し、WhatsApp を選んで、手動設定の WhatsApp Cloud プロバイダーを選びます。番号、電話番号 ID、WhatsApp Business Account の ID、アクセストークンを入力します。これらは EasyCoexistence のダッシュボードの接続画面に表示され、アシスタントからは get_api_credentials で取得できます。すると Chatwoot が、そのインボックス用の Webhook URL と Webhook 認証トークンを表示します。 次に EasyCoexistence で、番号の Webhook 送信先をその URL に設定し、同じ認証トークンを入力します。Meta が Chatwoot に認証リクエストを送り、Chatwoot が応答すれば、以降はその番号宛のすべてのメッセージがインボックスに届きます。間に処理を挟まないため、動かし続けるワークフローはありません。 ### 携帯電話から送った返信は Chatwoot に表示されますか？ はい、表示されます。Coexistence の番号では、WhatsApp Business アプリで入力した返信を Meta が smb_message_echoes イベントとして通知します。Chatwoot の Webhook ジョブがこのフィールドを認識し、該当する会話に送信済みメッセージとして記録します。ソースコードにも、Chatwoot とアプリの両方から返信する企業のメッセージを Chatwoot に同期するケースとして明記されています。 これにより、実際の運用で役割分担が成り立ちます。オーナーは常連のお客様には携帯電話から返信を続け、チームは席で共有インボックスを担当し、互いの送信内容がスクリーンショットの転送なしで見られます。 Chatwoot から送ったメッセージは、同じ番号の Cloud API 経由で送信されるため、携帯電話にも表示されます。 ### Chatwoot のインボックスにアプリシークレットを設定してはいけないのはなぜですか？ 配信が、手元にないシークレットで署名されているからです。Meta は各 Webhook を、サブスクリプションを所有するアプリ、つまり EasyCoexistence のアプリのアプリシークレットで署名します。このシークレットが共有されることはありません。 Chatwoot の現行ソースでは、手動設定の WhatsApp Cloud チャネルで X-Hub-Signature-256 ヘッダーを検証するのは、アプリシークレットが保存されている場合か、Chatwoot 独自の embedded signup で作成したチャネルの場合だけです。アプリシークレットのない手動インボックスは配信を受け付けますが、何かしらのアプリシークレットを入力したインボックスは、すべての配信を未認証として拒否します。 ここで保護の役割を果たすのが認証トークンです。長いランダムな値を選んでください。Chatwoot が Meta の認証リクエストとそれ以外を見分ける手がかりになります。 ### この番号で Chatwoot にできないことは何ですか？ 同時に 2 か所で Webhook を受け取ることです。Meta は番号の Webhook を 1 つの送信先にだけ届けるため、Chatwoot が受け取っている間は、n8n のワークフローには同じイベントが届きません。両方必要な場合は、各配信を Chatwoot とワークフローの両方に転送する小さな中継サーバーを自前で用意し、送信先をそこに向けてください。 Coexistence の制限は、他の環境と同じく適用されます。API の送信は毎秒最大 20 メッセージ、フリーテキストはお客様の最後のメッセージから 24 時間以内にしか送れず、それ以降はメッセージテンプレートを使います。 WhatsApp Business アプリは、少なくとも 14 日に 1 回は開く必要があります。EasyCoexistence がこれを監視しています。 - Chatwoot のインボックスにアプリシークレットを入力する。配信は EasyCoexistence のアプリのシークレットで署名されているため、Chatwoot はすべてを未認証として拒否します。 - EasyCoexistence に、Chatwoot が表示したものと違う認証トークンを入力する。Meta の認証が失敗し、インボックスにメッセージが一切届きません。 - 手動設定ではなく Chatwoot の embedded signup を選ぶ。番号が Chatwoot 独自の Meta アプリ経由で接続され、別の接続になってしまいます。 **セルフホストの Chatwoot でも使えますか？** はい。Webhook URL に app.chatwoot.com の代わりにご自身の Chatwoot ドメインが使われる点だけが違い、残りの設定は同じです。 **Chatwoot のために自前の Meta アプリは必要ですか？** いいえ、不要です。番号は EasyCoexistence 経由で接続され、認証情報の提供と Webhook の振り分けも EasyCoexistence が行います。Chatwoot のガイドに Meta アプリの作成手順があるのは、アプリを持っていない前提だからです。 **複数の番号を Chatwoot に入れられますか？** はい。番号ごとに WhatsApp Cloud インボックスを 1 つ作成し、各番号の Webhook 送信先に、それぞれのインボックスの URL と認証トークンを設定してください。 **EasyCoexistence は会話の内容を見られますか？** いいえ、見られません。Meta が Webhook を Chatwoot に直接届けており、EasyCoexistence が会話の内容を保存することはありません。 --- ## WhatsApp のメッセージを Airtable に記録し、ベースから送信する https://easycoexistence.com/ja/integrations/airtable Airtable の受信 Webhook トリガーは POST リクエストしか受け付けません。そのため Meta の認証用 GET に応答できず、番号の Webhook 送信先にはなれません。送信先は、各メッセージをテーブルに追加する n8n のワークフローに向けてください。送信は Airtable の中だけで完結します。Run a script オートメーションから fetch で Cloud API を呼び出し、番号のアクセストークンはシークレットとして保存します。 ### Airtable で WhatsApp の Webhook を直接受け取れないのはなぜですか？ Meta は、メッセージを配信する前に送信先を確認するためです。チャレンジ値を付けた GET リクエストを送り、同じ値がレスポンスボディとして返ることを求めます。Airtable の「When webhook received」トリガーは POST リクエストしか受け付けず、固定の JSON を返すため、この確認は通らず、Meta は配信を開始しません。 解決策は、間に 1 つ手順を挟むことです。n8n の Webhook ノードが認証を処理して各メッセージを受信し、n8n の Airtable ノードが 1 行を追加します。記録する内容は、送信者、プロフィール名、本文、メッセージ ID、タイムスタンプ、受信側の電話番号 ID です。Make や Zapier でも同じ構成で動きます。 間に挟む手順には、もう 1 つ利点があります。Airtable の Webhook トリガーは 1 秒あたり 5 リクエストまでですが、ワークフローツールならバーストをキューに溜められるため、拒否されるはずだったリクエストも処理できます。 ### Airtable のベースから WhatsApp テンプレートを送信するには？ アクションに Run a script を指定したオートメーションを使います。トリガーには、レコードがビューに入ったとき、フィールドが変更されたとき、ボタンがクリックされたときのいずれかを選べます。スクリプトは input.config() でレコードの電話番号とフィールドを読み取り、fetch で Cloud API の messages エンドポイントを呼び出します。Airtable のオートメーションスクリプトはサーバー側で実行されるため、ブラウザの制約は受けません。 アクセストークンはコードに書かず、スクリプトエディタのシークレットとして保存してください。Airtable はコンソール出力からシークレットを伏せ字にし、スクリプトのすべてのシークレットにアクセスできるユーザーだけが編集できます。 お客様から直近 24 時間以内にメッセージがない場合は、必ずテンプレートを使ってください。フリーテキストが届くのは、この 24 時間の枠内だけです。スクリプトから返されたメッセージ ID をレコードに書き戻せば、送信と行を結び付けられます。 ### メッセージ用のテーブルはどう設計すればよいですか？ メッセージ 1 件につき 1 行とし、WhatsApp のメッセージ ID を主フィールドにします。Meta は失敗したと判断した配信を再試行しますが、追加の前に ID を検索するワークフローなら、同じメッセージを二重に書き込むことはありません。 方向を示すフィールドを用意し、inbound と outbound を記録します。Coexistence の番号では、チームが WhatsApp Business アプリで入力した返信も、smb_message_echoes イベントとして同じ Webhook に届きます。これを outbound の行として記録すれば、ベースには片側だけでなく会話の全体が残ります。 各メッセージは、数字のみの電話番号をキーにした Contacts テーブルにリンクします。これは Meta が送ってくる形式です。ロールアップを使えば連絡先ごとの最終受信時刻が分かり、オートメーションがフリーテキストとテンプレートのどちらを使うかを判断するには、このフィールド 1 つで足ります。 - Airtable の Webhook URL を番号の送信先に設定する。POST しか受け付けないため Meta の認証用 GET が失敗し、何も配信されません。 - アクセストークンをスクリプト本体に貼り付ける。スクリプトのシークレットとして保存すれば、コードにもログにも残りません。 - 24 時間以内に連絡のない相手へ、レコードのオートメーションからフリーテキストを送る。届くのは承認済みのテンプレートだけです。 **Run a script は Airtable の無料プランで使えますか？** Airtable は、このアクションをすべてのプランで制限付きで利用できるとしています。ただし、Team プランの無料トライアルでは利用できません。 **n8n を使わずに Make や Zapier を使えますか？** はい。3 つのどれでも、Webhook の受信、認証への応答、行の追加ができます。送信先になれないのは Airtable 自体だけです。 **Airtable のボタンから WhatsApp メッセージを送れますか？** はい。「When a button is clicked」トリガーと、Cloud API を呼び出す Run a script アクションを組み合わせます。テンプレートには、その行のデータが差し込まれます。 **EasyCoexistence はメッセージを保存しますか？** いいえ。Meta は各 Webhook をお客様の n8n の URL に直接配信します。コピーが残るのは、ワークフローが Airtable に書き込んだ分だけです。 --- ## WhatsApp のメッセージを Google Sheets に記録し、シートから送信する https://easycoexistence.com/ja/integrations/google-sheets 番号の Webhook 送信先を n8n ワークフローに向け、Google Sheets ノードでメッセージごとに 1 行を追加します。記録する項目は送信者、名前、本文、メッセージ ID、時刻です。シートから送信するには、Apps Script の関数で行をループし、UrlFetchApp で Cloud API を呼び出します。その際、番号の電話番号 ID とアクセストークンを使います。チームはこれまでどおり WhatsApp Business アプリで返信を続けられます。 ### WhatsApp のメッセージはどのように 1 行になるのですか？ Meta は、番号に届いたすべてのメッセージを、設定した Webhook の送信先に送ります。ここでは n8n の Webhook ノードが送信先となり、Meta の検証リクエストにも応答します。次のノードは Google Sheets で、操作に Append Row を選びます。ペイロードの項目を列に割り当てます。送信者の番号、プロフィール名、本文、WhatsApp のメッセージ ID、タイムスタンプ、受信側の電話番号 ID です。 再試行しても問題が起きないようにするには、単純な追加ではなく、メッセージ ID をキーにした Append or Update Row を使ってください。Meta は配信に失敗したと判断するとメッセージを再送します。ID をキーにしておけば、2 回目の配信は同じ行の更新として処理されます。 Coexistence 番号では、WhatsApp Business アプリで入力した返信も、smb_message_echoes イベントとして同じ Webhook に届きます。方向を示す列を設けて記録すれば、シートにはやり取りの両側が残ります。 ### Sheets のクォータが問題になるのはどこですか？ ユーザーごとの書き込みです。Sheets API の書き込みリクエストは、プロジェクトあたり 1 分間に 300 件、プロジェクト内のユーザーあたり 1 分間に 60 件まで許可されます。n8n の認証情報は 1 ユーザーとして数えられます。そのため、メッセージごとに 1 行を追加するワークフローで継続的に処理できるのは、1 秒に約 1 件のメッセージです。 多くの店舗の番号なら、これで十分です。足りなくなるのは、一斉送信したメッセージテンプレートに数百人のお客様が数分以内に返信したときです。API は 429 Too Many Requests を返し、再試行がなければ行が欠落します。 対処法は 2 つあり、どちらか一方で足ります。1 つ目は、Google Sheets ノードで待機付きの再試行を有効にする方法です。指数的にバックオフするという Google 自身の推奨にも沿っています。2 つ目はバッチ処理です。n8n で 30 秒間メッセージを集め、1 回のリクエストでまとめて追加すれば、多数の書き込みが 1 回になります。 ### シートからメッセージテンプレートを送るにはどうしますか？ シートの拡張機能メニューから Apps Script を使います。関数が未送信の行を読み取り、行ごとに UrlFetchApp で Cloud API の messages エンドポイントを呼び出します。返されたメッセージ ID と時刻は、その行に書き戻します。時間主導型トリガーで数分おきに実行することも、カスタムメニューから手動で実行することもできます。 アクセストークンはコードに直接書かず、スクリプトのプロパティに保存してください。スクリプトを閲覧できる人にトークンが見えてしまうのを防げます。 クォータにも注意が必要です。URL Fetch の呼び出しは、個人の Google アカウントでは 1 日 20,000 回、Workspace アカウントでは 100,000 回までです。また、1 回の実行は 6 分で停止します。行を小分けにして処理し、次へ進む前に各行を送信済みにしてください。停止した実行も、続きから再開でき、二重送信を避けられます。 - メッセージ ID をキーにせずに追加している。Meta の再送によって、同じメッセージが 2 行に書き込まれます。 - 返信が集中する間、1 つの認証情報でメッセージごとに 1 行を書き込んでいる。ユーザーあたり 1 分間 60 件の書き込み上限により 429 が返り、行が失われます。 - 24 時間以内にメッセージを送っていない相手に、シートからフリーテキストを送っている。この時間枠の外で届くのは、承認済みのメッセージテンプレートだけです。 **n8n の代わりに Make や Zapier も使えますか？** はい。Make のカスタム Webhook または Zapier の catch hook でメッセージを受け取り、それぞれの Google Sheets のステップで行を追加します。 **n8n はどの Google アカウントとして書き込みますか？** n8n の Google 認証情報を承認したアカウントです。このアカウントにはシートの編集権限が必要で、ワークフローが消費するのも、そのアカウントのユーザーあたりの書き込みクォータです。 **電話番号の列は正しく書式設定されていますか？** 番号はプレーンテキストで保存してください。国番号付きで、プラス記号のない数字だけという、Meta が送る形式です。そうしないと Sheets が数値として扱い、先頭のプラス記号が消えたり、長い値の表示形式が変わったりすることがあります。 **EasyCoexistence はメッセージのコピーを保持しますか？** いいえ。Meta が各 Webhook をお客様の n8n の URL に配信するため、シートが唯一のコピーになります。 --- ## Supabase Edge Function で WhatsApp の Webhook を受信する https://easycoexistence.com/ja/integrations/supabase Supabase Edge Function は、番号の Webhook 送信先としてそのまま使えます。Meta の認証 GET には hub.challenge の値で応答し、POST されたメッセージを Postgres のテーブルに挿入し、Cloud API で返信します。デプロイ時は JWT 検証をオフにしてください。Supabase は既定で有効な JWT を要求しますが、Meta は JWT を送れないためです。 ### Edge Function は何をする必要がありますか？ 2 つのメソッドで、2 つのことを行います。 GET では Meta の認証に応答します。クエリ文字列から hub.mode、hub.verify_token、hub.challenge を読み取り、トークンを送信先に入力した認証用トークンと比較して、challenge をプレーンテキストの本文としてステータス 200 で返します。トークンが一致しない場合は 403 を返してください。 POST ではイベントを受信します。本文を解析し、entry、changes、value からメッセージを取り出してテーブルに挿入し、200 を返します。応答は速くしてください。Meta は応答が遅い、または失敗した場合を配信失敗とみなして再送するため、同じメッセージが 2 回届くことになります。 EasyCoexistence で、関数の URL を同じ認証用トークンとともに番号の Webhook 送信先に設定すると、Meta からの配信が始まります。 ### なぜ関数は Meta に 401 を返すのですか？ JWT 検証が有効だからです。Supabase は Edge Function のハンドラーが実行される前に、Authorization ヘッダーの JWT を検証します。これはすべての関数の既定の動作です。Meta はそのようなヘッダーを送らないため、プラットフォームが認証の GET も各配信もすべて拒否し、コードには届きません。 この関数に限って無効にしてください。supabase functions deploy whatsapp --no-verify-jwt でデプロイするか、supabase/config.toml の該当関数のセクションに verify_jwt = false を設定します。Supabase のドキュメントでも、外部の Webhook 提供元から呼び出される公開エンドポイントというまさにこのケースが説明されています。 プラットフォーム側のチェックを外す場合は、関数自身で確認する必要があります。署名ヘッダーは使えません。Meta は購読を所有するアプリのアプリシークレットで署名するためです。送信先 URL のクエリパラメータに長いランダムなシークレットを入れ、それがないリクエストは拒否してください。サンプルでも POST でそのようにしています。 ### 関数はどのように保存し、返信すべきですか？ 先に保存し、返信は後にします。WhatsApp のメッセージ ID に一意制約を付けて upsert すれば、Meta の再送が重複を作らず同じ行に入ります。複数の番号がこの関数を指している場合は、受信した phone_number_id を各行に保持してください。 モデルや別の API の呼び出しなど、時間のかかる処理は EdgeRuntime.waitUntil に渡し、すぐにレスポンスを返します。その Promise が完了するまで関数は動き続け、Meta にはすでに 200 が返っています。Supabase はアイドル状態が 150 秒に達すると待機をやめて 504 を返すため、応答前にすべての処理を行うハンドラーは、再送を最も招きやすくなります。 返信は Cloud API のメッセージ用エンドポイントに、関数のシークレットとして保存した番号の phone number id とトークンで送ります。お客様の最後のメッセージから 24 時間以内ならフリーテキストで送れますが、それを過ぎると承認済みのメッセージテンプレートのみ送信できます。 ### 電話から送ったメッセージも関数に届きますか？ はい。Coexistence の番号では WhatsApp Business アプリが引き続き使え、そこから返信すると、Meta は送信したメッセージのエコーを同じ送信先に配信します。このとき messages ではなく、smb_message_echoes フィールドの message_echoes 配列で届きます。 パーサーを拡張して両方を読み取り、direction 列を保存してください。すると、テーブルにはお客様の発言と企業の回答を含む会話全体が残ります。応答時間、未回答のスレッド、連絡先ごとの最後の受信時刻など、多くの人があとで集計したい内容です。 この最後の値は、あらゆる送信経路で必要になる入力でもあります。返信をフリーテキストにできるか、メッセージテンプレートにする必要があるかを決めるからです。テーブルに対するビューを作れば、連絡先ごとの値をアプリの他の部分に公開できます。 - JWT 検証を有効にしたままデプロイする。ハンドラーが実行される前に Supabase が Meta のリクエストを 401 で拒否し、メッセージは一切届きません。 - challenge を JSON で包んで返す。Meta は本文として生の値を必要とし、認証は何も表示されないまま失敗します。 - 応答の前に時間のかかる処理を行う。Meta は失敗とみなしたものを再送するため、同じメッセージが 2 回処理されます。 - 独自のチェックなしで JWT 検証をオフにする。URL を知った人なら誰でも、偽のメッセージをテーブルに投稿できてしまいます。 **Supabase の無料プランでも動作しますか？** Edge Functions は無料プランでも動作します。ウォールクロックの制限は無料プランで 150 秒、有料プランで 400 秒です。すばやく応答する Webhook ハンドラーなら、どちらでも十分に余裕があります。 **関数内で service role キーを使うべきですか？** ここで示したようにサーバー側のみで、関数の環境変数から読み取る場合に限ります。このキーは行レベルセキュリティを回避するため、ブラウザには決して渡さないでください。 **1 つの関数で複数の番号を扱えますか？** はい。すべての番号の Webhook 送信先をこの関数に向け、各ペイロードの phone_number_id で処理を分岐させてください。 **EasyCoexistence はメッセージを見られますか？** いいえ。Meta が各 Webhook をお客様の関数に直接配信し、EasyCoexistence は会話の内容を一切保存しません。 --- ## Coexistence 番号で WhatsApp を Activepieces に接続する https://easycoexistence.com/ja/integrations/activepieces Activepieces には WhatsApp Business ピースがあり、アクセストークンと WhatsApp Business アカウント ID で接続します。この 2 つは Coexistence 番号から取得できます。New Incoming Message トリガーは Meta の認証に自ら応答するため、その URL を番号の Webhook 送信先にそのまま使えます。ピースの任意項目であるアプリシークレットは空のままにしてください。フローはすべてのメッセージで実行され、チームはこれまでどおりスマートフォンで対応を続けられます。 ### Coexistence 番号を Activepieces に接続するには？ Activepieces で WhatsApp Business の接続を作成し、アクセストークンと WhatsApp Business アカウント ID の 2 つを入力します。どちらも EasyCoexistence のダッシュボードで確認でき、アシスタントからは get_api_credentials で取得できます。ピースの案内には Meta アプリとシステムユーザーの作成手順がありますが、これはどちらも持っていない場合を想定したものです。この番号はすでに接続済みなので、値を貼り付けるだけで済みます。 次に、New Incoming Message トリガーから始まるフローを作り、任意の検証トークンを設定して、フローを公開します。トリガーの Webhook URL を、EasyCoexistence の番号の Webhook 送信先に、同じ検証トークンとともに設定してください。Meta が認証リクエストを送り、トリガーが応答すると、その番号へのメッセージごとにフローが実行されます。 ### アプリシークレットを空にしておくのはなぜですか？ これらの配信に署名するシークレットは、お客様が貼り付けられるものではないからです。Meta はサブスクリプションを持つアプリのアプリシークレットで Webhook に署名します。EasyCoexistence 経由で接続した番号では、それは EasyCoexistence アプリであり、そのシークレットが共有されることはありません。 ピースではこの欄は任意です。空のままなら、トリガーは届いた配信をそのまま受け付けます。他のアプリのシークレットを入れると、すべての配信が X-Hub-Signature-256 の検証に失敗して黙って無視され、メッセージが届かないのと全く同じ状態に見えます。 検証トークンは、第三者がハンドシェイクに入り込むのを防ぐものです。長いランダムな値を選び、フローを起動するアドレスであるトリガー URL は非公開にしてください。 ### メッセージが届いたあと、フローでは何ができますか？ トリガーは、送信者、プロフィール名、メッセージ ID、種類、テキスト、メディア ID、ボタンやリストの返答、受信した電話番号 ID を平坦化した形でフローに渡します。そこから先は通常の Activepieces のフローで、CRM、スプレッドシート、AI ステップなど他のピースと組み合わせられます。 返信にも同じピースを使います。Send Message はフリーテキストを送りますが、お客様の最後のメッセージから 24 時間以内にしか届きません。Send Template Message は承認済みのメッセージテンプレートを送り、この時間枠を過ぎたあとに届けられるのはこれだけです。インタラクティブボタン、リスト、メディア、位置情報、リアクションは、それぞれ独立したアクションです。 Activepieces の案内にもあるとおり、Meta はアプリごとにコールバック URL を 1 つしか受け付けません。番号ごとの送信先でも上限は番号あたり 1 つの URL なので、複数の種類のイベントを扱うフローは、1 つのフロー内で分岐させてください。 ### スマートフォンで入力した返信はフローに届きますか？ Webhook には届きますが、このトリガーでは受け取れません。Coexistence 番号では、WhatsApp Business アプリで入力した返信のエコーを、Meta が smb_message_echoes フィールドで同じ送信先に送ります。ピースの New Incoming Message トリガーは messages フィールドだけを読み取り、それ以外は破棄します。 スマートフォンからの返信をフローで扱いたい場合は、代わりに Activepieces の汎用 Webhook ピースでフローを開始してください。このピースは任意の HTTP メソッドを受け付けます。認証の GET には、同期 URL 上の Return Response ステップで応答します。その場合、生のペイロードは自分で解析することになり、両方のフィールドが含まれます。 ほとんどのフローでは、ピースのトリガーのほうが簡単です。お客様からのメッセージに反応し、チームの返信はスマートフォンのアプリで引き続き確認できます。 - アプリシークレットを WhatsApp の接続に貼り付けてしまう。配信は EasyCoexistence アプリのシークレットで署名されるため、すべて無視されます。 - フローを公開する前に送信先を設定してしまう。Meta は即座に認証を行い、未公開のフローは応答できません。 - New Incoming Message トリガーで、スマートフォンで入力した返信も受け取れると思い込む。このトリガーが読むのは messages フィールドだけで、smb_message_echoes は対象外です。 **セルフホストの Activepieces でも使えますか？** はい。ピースはオープンソースで、Activepieces のクラウドでもセルフホストでも動作します。ただし、インスタンスがインターネットから HTTPS で到達できることが条件です。 **フローはどの電話番号から送信しますか？** アクションの電話番号欄で選んだ番号です。この欄には、接続先の WhatsApp Business アカウントにある番号が一覧表示されます。 **同じ番号で n8n や Make も使えますか？** 同時には使えません。Meta は 1 つの番号の Webhook を 1 つの送信先にしか送らないため、受信するツールを 1 つ選ぶか、そこから他方へ転送してください。 **EasyCoexistence はメッセージを保存しますか？** いいえ。Meta が各 Webhook を Activepieces のトリガーに直接届けるため、EasyCoexistence が会話の内容を保存することはありません。 --- ## Coexistence で Typebot のフローを WhatsApp 上で動かす https://easycoexistence.com/ja/integrations/typebot Typebot の WhatsApp チャネルでは、トークン、WhatsApp Business アカウント ID（WABA ID）、電話番号 ID を入力すると、コールバック URL と Verify Token が発行されます。この 3 つは接続した番号の値を入れ、Typebot の任意項目である app secret は空欄のままにします。そして Typebot の Callback URL と Verify Token を、その番号の Webhook の送信先に設定してください。 ### 接続した番号の値を入れる Typebot の項目はどれですか？ Typebot の WhatsApp ウィザードは、ボットの「Share」タブにあり、app secret、System User Token、WABA ID、電話番号 ID の 4 つを求めます。 このうち 3 つは、接続の画面でそのまま確認できます。ダッシュボードには、番号ごとの WABA ID、電話番号 ID、アクセストークンが表示されます。アシスタントに取得を任せる場合は、get_api_credentials ツールが同じ値を返します。それぞれ対応する項目に貼り付けてください。 app secret だけは空欄にします。Typebot が受信データに対して app secret を使うのは、Meta が配信ごとに付ける X-Hub-Signature-256 ヘッダーの検証だけです。Tech Provider 経由で接続した番号では、Meta は提供元の app secret で署名します。この値は共有されないため、ここに何かを入力すると、Typebot は正規のメッセージをすべて拒否してしまいます。空欄にしておけば、Typebot はこの検証を行わず、配信を受け付けます。 ### Typebot のコールバック URL と Verify Token はどこに設定しますか？ 設定先は、Meta アプリのダッシュボードではなく、番号の Webhook の送信先です。 Typebot のウィザードは、Callback URL と Verify Token をご自身の Meta アプリの WhatsApp 設定に貼り付けるよう案内します。しかし EasyCoexistence を通じた Coexistence では、ご自身のアプリは関与しません。Meta は番号のイベントを、その接続に設定された送信先へ届けます。そのため、Typebot の最後のステップで 2 つの値をコピーし、ダッシュボードまたは set_webhook_destination で送信先として設定してください。 その後、Meta が確認用の GET リクエストを Typebot に送り、Typebot が challenge を返します。以降、番号宛てのメッセージはすべてボットに届きます。Typebot の Verify Token は一度しか使えません。確認が成功した時点で、Typebot のデータベースから削除されます。後で送信先を設定し直す場合は、先にウィザードをやり直して新しいトークンを発行してください。 ### 24 時間ウィンドウに対して、ボットはどう動きますか？ Typebot は、先に連絡してきた相手に返信します。そのため、ほとんどのメッセージはカスタマーサービスウィンドウの内側に収まります。Meta はお客様が書き込むたびに 24 時間のウィンドウを開き、その間はテンプレートなしで、あらゆるサービスメッセージを送信できます。返信しかしないボットは、最も扱いやすいケースです。 注意が必要なのは、待機を含むフローです。Wait ブロックや、お客様が 1 日以上応答しなかった後に再開するセッションでは、ウィンドウ外でフリーテキストを送ろうとします。Meta はこれをエラー 131047 で拒否します。Typebot のセッション有効期限のタイムアウトは、初期値が 4 時間で、最大 48 時間まで変更できます。この設定は、戻ってきたお客様の会話を新しいチャットとして始める時点を決めるもので、Meta がメッセージを受け付けるかどうかとは関係ありません。 Coexistence なので、チームは WhatsApp Business アプリですべての会話を確認でき、ボットに任せたくない場面では携帯電話からいつでも対応を引き継げます。 - Meta アプリの app secret を Typebot に貼り付けること。配信は Tech Provider の secret で署名されているため、Typebot は署名が無効だとして、すべてのメッセージを拒否します。 - 古い Typebot の Verify Token を再利用すること。確認に成功すると削除されるため、送信先を設定し直すときはウィザードで新しいトークンが必要です。 - コールバック URL を共有すること。署名の検証をしない構成では、URL を知っていればリクエストを送れてしまいます。パスワードと同じように扱ってください。 **Typebot を使うのに、自分の Meta アプリは必要ですか？** いいえ、必要ありません。Typebot のガイドがアプリを前提にしているのは、多くの方がご自身で番号を接続するためです。Tech Provider 経由の Coexistence では、トークンと各 ID は接続から取得でき、Webhook は Meta が Typebot へ届けます。 **ボットが送ったメッセージは、携帯電話でもチームに見えますか？** はい、見えます。Cloud API で送ったメッセージは、同じ番号の WhatsApp Business アプリにも表示されます。担当者はやり取りを読み、そのまま対応を引き継げます。 **同じ番号のメッセージを Typebot と n8n の両方で受け取れますか？** いいえ、できません。1 つの番号に設定できる Webhook の送信先は 1 つです。両方でイベントが必要な場合は、送信先を n8n に向け、ワークフローから元のペイロードを Typebot のコールバック URL へ転送してください。 **Typebot は会話を保存しますか？** Typebot は、どのチャネルでも同様に、自身のセッションと結果のデータを保持します。一方、EasyCoexistence はメッセージの内容を一切保存しません。Meta が、設定された送信先へ直接配信します。 --- ## Botpress のボットを Coexistence で WhatsApp に接続する https://easycoexistence.com/ja/integrations/botpress Botpress の WhatsApp インテグレーションを Manual Configuration で使います。接続済みの電話番号のアクセストークンと phone number id を貼り付け、Verify Token を任意に決め、App ID と Client Secret は空のままにします。次に、Botpress の Webhook URL とその Verify Token を電話番号の Webhook の送信先に設定すると、Meta がすべてのメッセージをボットへ配信します。 ### Coexistence の電話番号で使える Botpress の設定はどれですか？ Manual Configuration です。それ以外の選択肢は、Botpress 自身の Meta アプリを通して電話番号を接続します。これは既に接続済みの番号を使う方法ではなく、番号の別のオンボーディングになります。 WhatsApp インテグレーションで Configuration のドロップダウンを開き、Manual Configuration を選びます。入力を求められるのは Verify Token、Access Token、Default Bot Phone Number ID で、任意項目として App ID、Client Secret、WABA ID があります。 アクセストークン、phone number id、WABA id は接続から取得します。ダッシュボードに表示され、アシスタントには get_api_credentials が返します。Verify Token は自由に決めた文字列で構いません。App ID と Client Secret は空のままにします。Botpress のガイドではシークレットを入力する項目として案内されていますが、インテグレーション定義では任意とされ、未入力の場合は署名検証をスキップすると記載されています。これは重要です。Meta は各配信に Tech Provider のアプリシークレットで署名しますが、それを持っているお客様はいないためです。 ### Botpress の Webhook は、どのように Meta のメッセージを受け取りますか？ 電話番号の Webhook の送信先を通して受け取ります。Botpress のガイドでは、Botpress の Webhook URL と Verify Token を Meta アプリの WhatsApp 設定に貼り付けます。ここではご自身の Meta アプリは存在せず、Meta は接続に指定された送信先へ電話番号のイベントを届けます。そのため、Botpress がインテグレーションに表示する Webhook URL をコピーし、同じ Verify Token とともに、ダッシュボードまたは set_webhook_destination で送信先として設定してください。 Meta が確認用の GET を送り、Botpress が応答すると、配信が始まります。Botpress は手動設定を保存するとき、トークンを発行したアプリを Graph に問い合わせて確認します。そのため、無効または失効したトークンは、最初のメッセージではなく保存時に失敗します。 Botpress のハンドラーは smb_message_echoes も処理します。これは WhatsApp Business アプリから誰かが返信したときに Meta が送るイベントです。したがって、スマートフォンからの返信はボットから見えない状態にはなりません。 ### Coexistence について、ボットは何を知っておくべきですか？ 人がすでに対応している可能性がある、という点です。電話番号では WhatsApp Business アプリが引き続き使えるため、お客様が同じ 1 分以内にスマートフォンとボットの両方から返信を受け取ることがあります。エコーが届いたときにフローでどう動くかを決めてください。多くのチームは、そのお客様に対してしばらくボットを一時停止し、対応に入った担当者の発言にボットが割り込まないようにしています。 2 つ目はタイミングです。受信メッセージに応答するボットは、フリーテキストが使える 24 時間のカスタマーサービスウィンドウの中で動作します。1 日後のフォローアップやリマインダーのようなメッセージを送るフローには、承認済みのメッセージテンプレートが必要です。この場面でフリーテキストを送ると、エラー 131047 が返ります。Botpress のガイドがテンプレートのステータスのフィールドを購読するのは、まさにこうした能動的なメッセージのためです。 なお、Coexistence の電話番号のスループットは毎秒 20 メッセージで固定です。会話型のボットが送る量をはるかに上回ります。 - Client Secret にご自身の Meta アプリのシークレットを入力する。署名が一致せず、Botpress はすべての配信に 401 を返します。 - Manual Configuration ではなく OAuth やサンドボックスの選択肢を選ぶ。これらは既に接続済みの番号ではなく、Botpress 自身のアプリ経由で番号を接続します。 - エコーを無視する。スマートフォンから送った返信への対応ルールがないと、すでに対応に入った担当者の発言に、ボットが重ねて返信してしまいます。 **署名検証をスキップしても安全ですか？** 保護の役割が URL に移ります。Botpress はインテグレーションごとに Webhook URL を生成するため、URL は非公開にしてください。メディアはトークンを使って Meta から取得する必要があり、偽造されたイベントではこれを再現できません。 **同じ電話番号から n8n にもイベントを送れますか？** 電話番号に設定できる Webhook の送信先は 1 つです。1 つのシステムに向け、2 つ目のシステムにもイベントが必要なら、そこから転送してください。 **Botpress に WABA id は必要ですか？** 現時点では任意項目とされていますが、将来のメジャーバージョンで必須になると定義に記載されています。接続から取得して入力しておいてください。 **メッセージは EasyCoexistence を経由しますか？** いいえ。Meta が Botpress の Webhook URL へ直接配信し、内容が当社側に保存されることはありません。 --- ## Dify アプリで WhatsApp メッセージに自動応答する https://easycoexistence.com/ja/integrations/dify 番号の Webhook を小さな受信側に向けます。n8n のワークフローや自社コードのルートなどで、各メッセージを Dify の Send Chat Message API に渡し、回答を Cloud API 経由で返します。Dify 側では EasyCoexistence MCP サーバーをツールとして追加でき、エージェントが番号そのものを操作できます。 ### Meta は WhatsApp メッセージを Dify に直接送れますか？ Meta のハンドシェイクを完了できる形では送れません。Meta はメッセージを配信する前に、送信先へ GET リクエストを送り、hub.challenge の値を生のレスポンス本文としてそのまま返すことを求めます。Dify の Webhook Trigger は 1 つのトリガーにつき HTTP メソッドを 1 つしか受け付けず、ドキュメントによると JSON 以外のレスポンス本文は自動的に JSON に変換されるため、OK はメッセージオブジェクトとして返ります。チャレンジを正確にそのまま返すことはできず、Meta は配信を開始しません。 そのため、手前に小さな受信側を置きます。n8n の Webhook ノード、Python や Node のルート、サーバーレス関数のいずれかで GET に応答し、POST を受け取り、テキストを Dify に渡します。Webhook URL に含めた長いランダムな秘密文字列を確認するのもこの受信側です。X-Hub-Signature-256 ヘッダーは Tech Provider のアプリシークレットで署名されており、顧客側では検証できないためです。 ### 受信側は Dify アプリとどのようにやり取りしますか？ Dify の Service API を 1 回呼び出します。POST /chat-messages を、アプリの API キーで認証して送ります。本文には、顧客のテキストである query と、自分で定めた識別子である user を含めます。user には送信者の WhatsApp 番号を使い、Dify が返す conversation_id を保持しておくと、同じ相手の次のメッセージが同じ会話として続きます。 response_mode には注意が必要です。blocking は回答の完成後に返りますが、Dify のドキュメントは、Dify Cloud では長い生成がエッジプロキシによって打ち切られることがあると警告しています。エージェントアプリはストリーミングのみに対応しており、blocking のリクエストは 400 で失敗します。ストリームを読み取り、最後に WhatsApp メッセージを 1 通送る受信側が堅実な構成です。 返信は Cloud API のテキストメッセージとして同じ番号へ送ります。顧客のメッセージで開いた 24 時間のウィンドウ内であれば無料です。 ### Dify の中で MCP サーバーは何を可能にしますか？ 呼び出しごとの配線なしで、Dify のエージェントが番号を操作できるようになります。Dify は HTTP で MCP サーバーに接続し、デフォルトでは OAuth の動的クライアント登録でサーバーに自身を登録します。EasyCoexistence MCP サーバーはこれに対応しています。「ツール」から追加して一度サインインすると、エージェントは次のツールを使えます。番号の一覧、番号の接続状態の確認、メッセージ送信、承認済みテンプレートの送信、テンプレートのステータス確認です。 これは能動的な処理に適した使い方です。翌日にフォローアップする Dify のワークフローでは send_template を使う必要があります。ウィンドウ外のフリーテキストはエラー 131047 を返し、ツールの説明がモデルにそう伝えているためです。 MCP にできないのは、顧客が書き込んだときに Dify を起動することです。このプロトコルはリクエストとレスポンスの形式なので、受信メッセージは引き続き Webhook と手前の受信側を通って届きます。 - Dify の Webhook Trigger の URL を Webhook の送信先にすること。チャレンジが JSON で包まれて返り、Meta はエンドポイントを確認できません。 - Dify のエージェントアプリに blocking のリクエストを送ること。エージェントアプリはストリーミングのみ対応で、呼び出しは 400 で失敗します。 - メッセージごとに新しい user の値を使うこと。Dify は会話を user 単位で管理するため、毎回新しい会話になり、記憶が引き継がれません。 **Dify に WhatsApp チャネルはありますか？** ドキュメントにはありません。Dify アプリは Service API で呼び出せるため、その API を呼ぶ受信側を通して WhatsApp に接続します。 **n8n を受信側にできますか？** はい。Webhook ノードで受信し、HTTP Request ノードで Dify を呼び出し、2 つ目の HTTP Request ノードで Cloud API 経由の返信を送ります。 **チームは携帯電話から返信できますか？** はい。Coexistence により、番号上で WhatsApp Business アプリを引き続き使えます。携帯電話から送った返信は、echo イベントとして受信側に届きます。 **EasyCoexistence は会話を見られますか？** いいえ。Meta は受信側へ直接配信し、メッセージの内容は当社側に保存されません。MCP サーバーが読み取るのはアカウントと番号の状態です。 --- ## Flowise のチャットフローで WhatsApp メッセージに自動応答する https://easycoexistence.com/ja/integrations/flowise 番号の Webhook 送信先を、小さな受信用サーバーに設定します。n8n のワークフローでも、自社コードのルートでも構いません。受信側は各メッセージを送信者の番号をセッション ID として Flowise の Prediction API に渡し、返ってきた回答を、その番号のトークンと phone_number_id を使って Cloud API から返信します。 ### なぜ Flowise の前に中継役が必要なのですか？ Meta の Webhook と Flowise の API では、やり取りの形式が異なるためです。Meta は送信先の確認に GET を送り、hub.challenge を生のボディとして返すことを求めます。その後、各メッセージを入れ子構造の JSON の POST で配信します。一方、Flowise の Prediction API は、/api/v1/prediction/ にフロー ID を続けた URL への POST と、question フィールドを期待します。どちらも相手に合わせてくれないため、受信側が変換を担います。 受信側には、n8n の Webhook ノード、Python や Node で書いたルート、任意のサーバーレス関数が使えます。受信側は確認用の GET に応答し、Webhook URL に含めた長いランダムなシークレットを検証し、Meta にはすぐに 200 を返してから、実際の処理を行います。ここで有効な認証は URL に含めたシークレットです。Meta は Tech Provider のアプリシークレットで配信に署名しますが、このシークレットは共有されないため、X-Hub-Signature-256 ヘッダーをこちら側で検証することはできません。 ### 受信側は Prediction API をどう呼び出せばよいですか？ お客様のテキストを question に、お客様の WhatsApp 番号をセッションとして渡します。Flowise はリクエストごとに overrideConfig を受け付けます。その中の sessionId によって、メモリノードが全員を 1 つのスレッドに混ぜず、1 人につき 1 つの会話を保持できます。Webhook のペイロードに含まれる送信者の番号は、そのための安定した自然なキーです。 チャットフローが API キーで保護されている場合、受信側はそれを Bearer トークンとして送ります。受信側がストリームを組み立てる作りでない限り、streaming は false にしてください。WhatsApp はトークンごとではなく、完成した 1 通のメッセージとして届けるためです。 回答は、同じ番号から Cloud API のテキストメッセージとして送信します。お客様のメッセージで開いた 24 時間のウィンドウ内であれば、無料で送信できます。リマインダーなど、フローが後から送りたいメッセージは、承認済みのメッセージテンプレートにする必要があります。 ### Flowise のエージェントから EasyCoexistence の MCP サーバーを使えますか？ 現時点ではできません。Flowise の Custom MCP は、URL とヘッダーの組を使って Streamable HTTP サーバーに接続します。通常は Flowise の変数に保存した固定の Bearer トークンを使います。EasyCoexistence の MCP サーバーは OAuth で認証し、ブラウザでのサインインと自社で発行するトークンを使うため、ヘッダーに入れられる固定キーがありません。 実用的な分担は、フローが判断し、受信側が送信する形です。フローは、返信するテキストを返します。お客様からの連絡が 1 日以上途絶えている場合は、メッセージテンプレート名を返します。受信側は、その番号のトークンで Cloud API を呼び出します。こうすればトークンが Flowise の中に置かれることはなく、24 時間ルールも、忘れる可能性のあるモデル任せにせず、連絡先が最後に書き込んだ時刻をコードで確認して守れます。 受信メッセージは、送信をどの方法で行う場合でも、引き続き Webhook 経由でのみ届きます。 - sessionId を省略すること。全てのお客様が 1 つのメモリを共有し、ある人の情報が別の人への返信に現れるおそれがあります。 - Flowise の処理を待ってから Meta に応答すること。200 の返信が遅れると再送され、同じメッセージが二重に処理されます。 - 1 日後にフローからフリーテキストを送らせること。ウィンドウ外では、Meta がエラー 131047 で拒否します。 **Flowise に WhatsApp ノードはありますか？** ドキュメントには記載がありません。Prediction API 経由で接続するため、Meta とフローの間に受信側を置きます。 **n8n を受信側にできますか？** はい。Webhook ノードで受信し、HTTP Request ノードで Flowise を呼び出し、別の HTTP Request ノードで Cloud API から回答を送信します。 **担当者がスマートフォンから返信したとき、ボットを止めるにはどうすればよいですか？** echo イベントを監視してください。WhatsApp Business アプリから送った返信は受信側に届くため、その連絡先についてフローを一時停止できます。 **会話は EasyCoexistence に保存されますか？** いいえ。Meta はお客様の受信側に直接配信します。Flowise には、メモリノードの設定で保持するよう指定した内容だけが残ります。 --- ## LangChain エージェントに WhatsApp 番号を持たせる https://easycoexistence.com/ja/integrations/langchain LangChain エージェントで WhatsApp を使うには、受信と操作の 2 つを用意します。受信メッセージは、番号の Webhook を通じてお客様側の Web ルートに届き、そのルートがエージェントを呼び出します。エージェントが操作するときは、LangChain の MCPAdapter と OAuth で EasyCoexistence の MCP ツールを読み込むか、番号のアクセストークンと phone_number_id を使って Cloud API を直接呼び出します。 ### LangChain エージェントは WhatsApp のツールをどう読み込みますか？ LangChain の MCP クライアントである MCPAdapter を使います。MCP サーバーのツールが、通常の LangChain ツールとして create_agent に渡されます。langchain[mcp] のバージョン 1.4.0 以降が必要で、現在はベータ版です。 認証は FastMCP に任せます。クライアントで auth="oauth" を指定すると、探索、動的クライアント登録、ブラウザへのリダイレクト、トークン交換まで、OAuth 2.1 のフロー全体が実行されます。EasyCoexistence の MCP サーバーが求めるのはこの方式なので、キーを作成して貼り付ける手間はありません。既定ではトークンはメモリ上にのみ保持され、実行のたびにブラウザでの手順が繰り返されます。トークンストアを備えた FastMCP の OAuth プロバイダーを使うと、実行をまたいで保持できます。 読み込みが終わると、エージェントは各ツールを説明付きで認識します。最初に使うのは list_numbers です。ほかのすべてのツールが、これで得た connection_id を必要とするためです。そのあとに send_message、send_template、list_templates、get_number_health などが続きます。 ### WhatsApp の受信メッセージは、どうやってエージェントに届きますか？ Webhook を使います。MCP では実現できないためです。MCP はリクエストとレスポンスのプロトコルなので、お客様が書き込んだときにサーバーからクライアントを起動する仕組みがありません。 番号の Webhook の送信先を、お客様自身のアプリケーション内のルートに設定します。URL パスには長いランダムなシークレットを含めてください。このルートは、Meta の検証用 GET にチャレンジ値をそのまま返し、各 POST を受け付けて、すぐに 200 を返したうえで処理をキューに入れます。その後ワーカーがペイロードから送信者とテキストを取り出し、エージェントを呼び出します。このとき送信者の電話番号をスレッド ID にすると、メモリがお客様ごとに分かれます。 検証には X-Hub-Signature-256 ヘッダーではなく、URL 内のシークレットを使ってください。Meta は Tech Provider のアプリシークレットで署名しますが、これは共有されないため、お客様側ではこのヘッダーを検証できません。 ### エージェントは MCP と Cloud API のどちらで送信すべきですか？ どちらでも動作します。違いは、ルールをどこで管理するかです。MCP ツールは、WhatsApp のルールを説明文に含んでいます。たとえば send_message は 24 時間ウィンドウ内でのみ使え、まだ書き込んでいない相手に連絡するには send_template を使う、といった内容です。モデルはこの説明を読んで、多くの場合は正しいツールを選びます。エージェントが自由に判断する場面では、これが役立ちます。 エージェントの役割が限られている場合は、番号のアクセストークンで Cloud API の messages エンドポイントに送信する自作のシンプルなツールのほうが簡単です。たとえば、いま書き込んだ相手にだけ返信する場合です。その場合、ウィンドウの確認はお客様のコード側に置くことになります。絶対に破ってはならないルールは、そこに置くべきです。ウィンドウ外でフリーテキストを送るとエラー 131047 が返り、お客様には何も届きません。 - MCP が受信メッセージを届けてくれると期待すること。Webhook のルートがなければ、エージェントはお客様の発言を受け取れません。 - OAuth のトークンをサーバーのメモリ上に置いたままにすること。再起動のたびにブラウザでのサインインが必要になります。トークンストアで永続化してください。 - 全員のお客様で 1 つのスレッドを使うこと。エージェントのメモリは、送信者の電話番号をキーにしてください。 **Python だけで使えますか？** MCPAdapter の例は Python です。Webhook と Cloud API は通常の HTTP なので、LangChain が動作する言語であれば、どれでも受信と送信ができます。 **エージェントは毎回 list_numbers を呼ぶ必要がありますか？** connection_id が必要で、それを得られるのは list_numbers だけです。番号が 1 つの場合、エージェントは最初に 1 回呼び出せば十分です。 **チームはこれまでどおり携帯電話から返信できますか？** はい。Coexistence により WhatsApp Business アプリは引き続き使えます。携帯電話からの返信は echo イベントとしてお客様のルートに届くため、エージェントが内容を考慮できます。 **EasyCoexistence は会話の内容を読みますか？** いいえ。Meta はお客様のルートに直接配信し、メッセージの内容が当社側に保存されることはありません。MCP ツールが読み取るのは、アカウントと番号の状態です。 --- ## OpenAI Agents SDK のエージェントを WhatsApp で動かす https://easycoexistence.com/ja/integrations/openai-agents-sdk 電話番号の Webhook の送信先を、Python アプリ内のルートに設定します。メッセージを受信するたびに、Runner.run と送信者の番号をキーにしたセッションでエージェントを実行し、result.final_output を、その番号のトークンと phone number id を使って Cloud API から返信します。同じ番号で WhatsApp Business アプリも引き続き使えます。 ### WhatsApp のメッセージはどのようにエージェントの実行になりますか？ Meta が呼び出す、自社アプリ内のルートを経由します。電話番号の Webhook の送信先にそのルートを設定し、パスには長くランダムなシークレットを含めてください。ルートは、Meta の検証用 GET に対して hub.challenge をプレーンテキストで返し、各 POST を受け付けてすぐに 200 を返したうえで、処理をキューに入れます。Meta は応答が遅いとリトライするため、先にエージェントを実行するとエージェントが二重に動いてしまうからです。 その後、ワーカーがペイロードから送信者とテキストを読み取り、Runner.run を呼び出します。このとき、送信者の番号をセッション ID としたセッションを渡します。SDK がその ID で会話を保存するため、同じ顧客の次のメッセージは前回の続きから始まり、別の顧客と履歴が混ざることはありません。最初は SQLiteSession で十分です。複数のワーカーで動かす場合は、SDK に含まれる Redis や SQLAlchemy のセッションを使えます。 ここでは URL 内のシークレットが認証の役割を果たします。Meta は Tech Provider のアプリシークレットで配信に署名するため、顧客側では署名ヘッダーを検証できないからです。 ### 返信はエージェントではなく、なぜ自社のコードが送るべきですか？ 絶対に破ってはいけない唯一のルールは時間に関するルールであり、プロンプトよりもコードのほうが確実に守れるからです。顧客がメッセージを送ると、Meta は 24 時間のカスタマーサービスウィンドウを開きます。この間はフリーテキストを送れますが、ウィンドウ外では承認済みのメッセージテンプレートしか送れず、フリーテキストはエラー 131047 で返されます。 届いたばかりのメッセージに答えるワーカーは常にウィンドウ内にいるため、result.final_output をテキストとして送る方法は構造上安全です。翌朝のフォローアップやリマインダーなど、後から行う処理は別の経路に分け、フリーテキストではなく必ずメッセージテンプレートを送ってください。 エージェントにツールを持たせることもできます。注文や予約の照会などにはファンクションツールを渡し、WhatsApp への送信はワーカー側に残してください。そうすれば、モデルが任意の引数で呼び出せるものの中に、アクセストークンが入りません。 ### エージェントから EasyCoexistence の MCP サーバーを使えますか？ 使えます。MCPServerStreamableHttp を通じて接続できますが、ヘッダーを足すだけより設定は多くなります。SDK は params["auth"] に Authorization ヘッダーまたは httpx.Auth を受け付けます。EasyCoexistence の MCP サーバーは、ブラウザーでのサインイン後に動的クライアント登録と PKCE を使って独自の OAuth トークンを発行するため、固定のキーはありません。MCP Python SDK には、PKCE とトークン更新を含むそのフローを実行する HTTP 認証ハンドラーの OAuthClientProvider があり、これを params["auth"] に渡します。 この方法が向くのは、エージェント自身に判断させたい場合です。たとえば、番号の接続状態を確認する、メッセージテンプレートの状態を読む、ツールの説明にあるルールに従って send_message と send_template を選ぶ、といった用途です。応答するだけの窓口であれば、前述のワーカーのほうが短く済み、問題も起きにくくなります。 どちらの方法でも Webhook は必要です。MCP はリクエストとレスポンスの仕組みであり、顧客のメッセージがエージェントに届く経路は、Meta が呼び出すルートだけだからです。 - Meta に 200 を返す前にエージェントを実行する。遅い応答はリトライされ、顧客に回答が 2 回届きます。 - 全顧客で 1 つのセッションを使う。送信者の番号をキーにしないと、履歴が混ざります。 - 遅れて送るフォローアップでフリーテキストを使う。24 時間を過ぎると 131047 で失敗するため、メッセージテンプレートを送ってください。 **OpenAI Responses API のホスト型 MCP ツールは必要ですか？** いいえ。ワーカーが Runner.run でエージェントをローカル実行し、WhatsApp 側は自社のコードが行う通常の HTTPS 呼び出しです。 **どの Graph API バージョンを使えばよいですか？** Meta の最新の例では v25.0 が使われています。バージョンはコード内の 1 か所で固定しておくと、アップグレードが 1 行の変更で済みます。 **電話から人が対応を引き継げますか？** はい。Coexistence により WhatsApp Business アプリが引き続き使え、電話からの返信は echo イベントとしてルートに届くため、ワーカーはそれを使ってエージェントを一時停止できます。 **EasyCoexistence は会話を保存しますか？** いいえ。Meta がルートへ直接配信します。セッションが保存する内容は、すべて自社のデータベースにあります。 --- ## Vercel AI SDK で WhatsApp エージェントを作る https://easycoexistence.com/ja/integrations/vercel-ai-sdk 受信したメッセージは、番号の Webhook 送信先に設定したルートハンドラーに届きます。ハンドラーは generateText を呼び出し、その回答を Cloud API で送信します。番号を操作するツールが必要な場合は、@ai-sdk/mcp の createMCPClient が HTTP 経由で EasyCoexistence の MCP サーバーに接続し、authProvider を通じて OAuth でサインインします。 ### ルートハンドラーはどのように WhatsApp のメッセージを受信しますか？ 1 つのルートに 2 つのメソッドを用意し、パスに長いランダムなシークレットを含めた URL を番号の Webhook 送信先に設定します。 GET は Meta の検証に応答します。クエリから hub.mode、hub.verify_token、hub.challenge を読み取り、トークンを照合して、challenge をプレーンテキストで返します。JSON 用のヘルパーで返してしまうのが典型的な失敗です。本文が引用符で囲まれた状態で届くため、Meta は配信を開始しません。 POST はイベントを受け取ります。まず 200 をすぐに返し、モデルの呼び出しはその後に行ってください。Meta は応答が遅いと再試行するため、コールドスタート中にモデルを同期的に実行すると、同じメッセージに 2 回回答してしまうことがあります。レスポンスの送信時に関数が終了するプラットフォームでは、処理をキューに渡すか、レスポンス後に処理を続けるためのプラットフォームの仕組みを使ってください。 パスのシークレットが認証の役割を果たします。Meta は各配信を Tech Provider のアプリシークレットで署名するため、X-Hub-Signature-256 ヘッダーをお客様側で検証することはできません。 ### AI SDK は WhatsApp のツールをどのように読み込みますか？ @ai-sdk/mcp の createMCPClient と HTTP トランスポートを使います。AI SDK のドキュメントでも、本番環境ではこの方法が推奨されています。トランスポートにはサーバーの URL と authProvider を渡します。EasyCoexistence の MCP サーバーは OAuth と authProvider の組み合わせで認可されます。サーバーは OAuth メタデータを公開し、動的クライアント登録と PKCE に対応しており、サインイン後に独自のトークンを発行します。ヘッダーに入れる API キーはありません。 クライアントのツールは、そのまま generateText や streamText に渡せます。モデルからは list_numbers、send_message、send_template、get_number_health などが見え、説明文には 24 時間ウィンドウの条件が明記されています。呼び出しが終わったらクライアントを閉じてください。ストリームでは onEnd コールバックで、それ以外では finally ブロックで閉じます。これは AI SDK のドキュメントにも記載されています。 モデルに判断させたい場面で使います。届いたばかりのメッセージに返信するだけなら、ハンドラーから Cloud API を直接呼ぶ方が簡潔です。 ### 番号が Coexistence で動いていると、何が変わりますか？ コードで把握しておくべき点が 2 つあります。1 つ目は、すでに担当者が会話に加わっている可能性があることです。番号では WhatsApp Business アプリが引き続き使え、スマートフォンで入力した返信はすべてエコーイベントとしてルートに届きます。エコーを受け取った連絡先についてモデルを一時停止するハンドラーにすれば、担当者の返信に重ねて回答することを防げます。 2 つ目は、番号ごとの送信が毎秒 20 メッセージで固定されていることです。会話型のエージェントがこの上限に達することはありませんが、連絡先リストに Promise.all を使った一斉送信のループを書くと上限に達します。まとめて少しずつ送信してください。 それ以外は通常の Cloud API と同じです。お客様の最後のメッセージから 24 時間以内であれば、フリーテキストを送信できます。それを過ぎると承認済みのメッセージテンプレートしか送れず、フリーテキストはエラー 131047 を返し、お客様には何も表示されません。 - challenge を JSON のレスポンスヘルパーで返してしまうこと。引用符が付くため、Meta の検証に失敗します。 - Meta に応答する前に generateText を実行すること。コールドスタート時は再試行により、2 回目の回答が送られます。 - MCP クライアントを閉じ忘れること。リクエストのたびに接続が開いたままになり、プラットフォームに強制終了されるまで残ります。 **Vercel でしか動作しませんか？** いいえ。AI SDK は TypeScript のライブラリです。ルートは HTTPS で公開でき、GET と POST に応答できるホスティング環境であればどこでも動作します。 **MCP クライアントは必ず必要ですか？** 返信だけなら不要です。番号のトークンを使って Cloud API のメッセージ用エンドポイントに fetch すれば送信できます。MCP が役立つのは、モデルが何をするかを自分で選ぶ場面です。 **モデルはどのプロバイダーのものを使えますか？** AI SDK が対応しているものであれば何でも使えます。WhatsApp 側はモデルに依存しないため、プロバイダーを切り替えてもルートや Cloud API の呼び出しを変更する必要はありません。 **EasyCoexistence はメッセージを見ることができますか？** いいえ。Meta はお客様のルートに直接配信し、メッセージの内容が当社側に保存されることはありません。 --- ## Shopify から WhatsApp で注文メッセージを送信する https://easycoexistence.com/ja/integrations/shopify Shopify Flow の「Send HTTP request」アクションを使えば、注文の作成時に承認済みテンプレートを Cloud API へ送信できます。接続した番号の `phone_number_id` と、Flow シークレットとして保存したトークンを使います。このアクションがないプランでは、Shopify 管理画面の Webhook を n8n などの受信側に向け、受信側から同じ呼び出しを行います。 ### Shopify Flow は WhatsApp メッセージをどのように送信しますか？ 「Send HTTP request」アクションを使います。このアクションは任意の URL にヘッダーとボディを付けて POST でき、ボディにはトリガーの Liquid 変数も使えます。 注文作成トリガーでワークフローを作成し、「Send HTTP request」を追加します。URL は、接続した番号の `phone_number_id` に対応する Cloud API のメッセージ用エンドポイントです。Authorization ヘッダーには、Bearer に続けてその番号のアクセストークンを指定します。トークンは Flow シークレットとして保存し、シークレット変数として参照してください。シークレットの値は Flow の画面に表示されず、実行ログでも伏せ字になるため、トークンの保管先として適しています。ボディはテンプレートメッセージで、`to` フィールドにお客様の電話番号を、テンプレートのパラメーターに注文内容を指定します。 Flow は 2XX または 3XX のレスポンスを成功と見なします。Meta は有効なリクエストにメッセージ ID を返すので、実行が成功した場合は Meta がメッセージを受け付けたことになります。 ### 注文メッセージはなぜテンプレートでなければならないのですか？ 店舗側が先にメッセージを送るからです。Meta の 24 時間のカスタマーサービスウィンドウは、お客様がその番号にメッセージを送ったときにだけ開きます。注文確認、発送のお知らせ、カゴ落ちのリマインダーはそれより前に送るため、フリーテキストは拒否され、事前に承認されたテンプレートだけが送信できます。 テンプレートは、注文や発送の通知向けのユーティリティカテゴリで一度作成し、承認されてからワークフローを有効にしてください。リクエストボディの名前と言語は承認済みテンプレートと完全に一致させる必要があり、パラメーターの数もプレースホルダーの数と合わせます。 同意の取得も必要です。Meta は、企業が WhatsApp でメッセージを送る前にオプトインを得ることを求めています。つまり、本人が電話番号を伝え、その企業からのメッセージ受信に同意している状態です。チェックアウトにその旨のチェックボックスを置くのが一般的な取得方法で、ワークフローでは送信前にその同意を確認してください。 ### ストアのプランに「Send HTTP request」が含まれていない場合はどうなりますか？ 代わりに Shopify 管理画面の Webhook を使います。「設定」から「通知」、「Webhook」の順に開くと、注文作成などのイベントに対して、JSON 形式で URL へ送信する Webhook を作成できます。送信先は受信側に設定します。n8n の Webhook ノードでも、PHP、Python、Node で作った route でも構いません。受信側は注文を読み取り、同意を確認して、Cloud API に同じテンプレート呼び出しを行います。 どちらの方法で送信しても、返信の扱いは同じです。お客様が注文メッセージに返信すると、その番号は Coexistence で接続されているため、返信は店舗の端末の WhatsApp Business アプリに届き、フリーテキストを送れる 24 時間のウィンドウも開きます。番号の Webhook の送信先を設定している場合は、返信がお客様のシステムにも届きます。注文メッセージ自体もアプリに表示されるので、返信する担当者は、お客様が何に返信しているのかを確認できます。 - 注文の作成時にフリーテキストを送る。お客様がまだメッセージを送っていないため、Meta に拒否されます。承認済みテンプレートを使ってください。 - 4XX レスポンスでもエラー処理を「再試行」にしたままにする。Meta が決して受け付けないリクエストを、Flow が最大 24 時間再試行することがあります。 - トークンをヘッダーにそのまま書き込む。Flow シークレットとして保存すれば、画面やログに表示されません。 **テンプレートメッセージの料金は誰が支払いますか？** メッセージの料金は、Meta が企業の WhatsApp Business アカウントに直接請求します。EasyCoexistence が上乗せすることはありません。 **チームはこれまでどおり携帯電話からお客様に返信できますか？** はい。それが Coexistence の特長です。店舗が送信に使う番号と同じ番号で、WhatsApp Business アプリも使えます。 **Shopify のアプリは必要ですか？** いいえ。Flow の「Send HTTP request」か、受信側への管理画面 Webhook があれば十分です。Cloud API は HTTPS の呼び出し 1 回で利用できます。 **`to` フィールドの電話番号はどの形式にしますか？** 国番号を付けた国際形式で、数字のみにします。お客様はスペースや記号を入力することがあるため、チェックアウトの電話番号欄の値は送信前に整形してください。 --- ## WooCommerce の注文更新を WhatsApp で送信する https://easycoexistence.com/ja/integrations/woocommerce 注文イベント用の WooCommerce Webhook を作成し、送信先を受信サーバーに指定します。受信サーバーは n8n のワークフローでも、小さな PHP のルートでも構いません。受信サーバーは WooCommerce の署名を検証し、お客様が WhatsApp メッセージに同意していることを確認したうえで、接続済みの番号の phone number ID とトークンを使い、承認済みテンプレートを Cloud API から送信します。 ### WooCommerce の注文は、どのように WhatsApp メッセージのきっかけになりますか？ WooCommerce の Webhook と受信サーバーを使います。WooCommerce の「設定」、「詳細」、「Webhook」で Webhook を追加し、「注文作成」や「注文更新」といった注文のトピック、配信 URL、シークレットを指定します。以降、該当するイベントが起きるたびに、WooCommerce が注文内容を JSON として配信 URL に POST します。 ペイロードの形式は固定なので、Cloud API に直接向けることはできません。間に受信サーバーを置きます。n8n の Webhook ノード、店舗の PHP 内のルート、小さなサービスなど、何でも使えます。受信サーバーは注文を読み取り、お客様の電話番号とメッセージに必要な情報を取り出して、接続済みの番号の Cloud API メッセージエンドポイントに HTTPS リクエストを 1 回送ります。このとき、その番号のアクセストークンを Bearer トークンとして使います。 order.updated トピックは特定のステータスに限定されません。そのため、受信サーバーは注文の status フィールドを読み取り、送信したい遷移ごとに 1 回だけ送信してください。また、WooCommerce は既定で wp-cron を使ってバックグラウンドで配信するため、メッセージは注文から少し遅れて届くことがあります。 ### 受信サーバーは、リクエストが店舗から届いたものだとどう判断しますか？ WooCommerce の署名で判断します。配信ごとに X-WC-Webhook-Signature ヘッダーが付きます。これは、Webhook に設定したシークレットで生のペイロードから計算した HMAC-SHA256 を base64 エンコードしたものです。受信サーバーは受け取ったボディに対して同じハッシュを計算して比較し、一致しないものは拒否します。 これは店舗自身のシークレットなので、WhatsApp の受信メッセージに付く Meta の署名とは異なり、検証できます。比較は定数時間で行い、ハッシュはフレームワークが解析する前の生のボディに対して計算してください。JSON を再エンコードするとハッシュが変わってしまうためです。 応答はすぐに 2xx で返してください。WooCommerce は 2xx、301、302 以外の応答をすべて失敗と数え、連続で 5 回を超えて失敗すると Webhook を無効にします。デプロイ中でサーバーが止まっていたり、Meta の応答を待ってから返すために遅くなったりすると、誰も気づかないうちに店舗のメッセージ送信が止まることがあります。 ### 店舗は何を、どんなときに送信できますか？ 店舗から先に送る場合は、承認済みテンプレートを使います。Meta の 24 時間のカスタマーサービスウィンドウは、お客様がその番号にメッセージを送ったときにしか開きません。注文確認や発送通知は企業側からの送信にあたるため、フリーテキストは拒否されます。更新の種類ごとにユーティリティテンプレートを作成し、承認を待ってから、名前と言語を指定し、注文番号などの情報をパラメータとして渡して送信します。 Meta はオプトインも求めています。お客様が自分の番号を伝え、この企業から WhatsApp で連絡を受けることに同意している必要があります。最も簡単な記録方法は、チェックアウト画面のチェックボックスを注文に保存することです。受信サーバーは送信前にこれを確認してください。 お客様が返信した後は、通常の Coexistence の会話になります。返信は店舗の端末の WhatsApp Business アプリに表示され、ウィンドウが開いているためフリーテキストも送れます。チームはこれまでどおりアプリから返信できます。 - WooCommerce に応答する前に Cloud API を呼び出してしまう。送信の遅延や失敗が Webhook の失敗として数えられ、5 回を超えると無効になります。 - 解析済みの JSON をハッシュしてしまう。署名が一致せず、正規の配信がすべて拒否されます。 - order.updated の配信のたびに送信してしまう。このトピックは特定のステータスに限定されないため、どの遷移を送信済みか記録していないと、お客様に同じメッセージが重複して届きます。 **この連携に WordPress プラグインは必要ですか？** いいえ。WooCommerce 標準の Webhook と受信サーバーがあれば足ります。受信サーバーは、同じ PHP アプリケーション内のルートでも構いません。 **注文メッセージの料金は誰が支払いますか？** メッセージ料金は、Meta が企業の WhatsApp Business アカウントに直接請求します。EasyCoexistence が上乗せすることはありません。 **チームはこれまでどおり端末を使えますか？** はい。Coexistence により、店舗の番号で WhatsApp Business アプリを引き続き使えます。店舗が送信したテンプレートも、スレッドに表示されます。 **Webhook が無効になった場合はどうすればよいですか？** 受信サーバーを修正してから、WooCommerce で Webhook のステータスを有効に戻してください。無効の間に作成された注文では、メッセージは送信されていません。 --- ## PHP と Laravel から WhatsApp を送受信する https://easycoexistence.com/ja/integrations/php-laravel 受信は、Meta の認証用 GET に応答し POST を受け付ける Laravel のルートで行います。PHP はドットをアンダースコアに変換するため、パラメーターは hub_mode、hub_verify_token、hub_challenge として読み取ります。送信は、番号の phone number id とトークンを使って、Cloud API のメッセージ用エンドポイントに `Http::withToken()` で POST するだけです。SDK は不要です。 ### Laravel で WhatsApp のメッセージを受信するには？ routes/api.php に、同じパスで GET と POST を定義します。ファイルがない場合は、先に php artisan install:api を実行してください。API ルートはステートレスで web グループの外にあるため、Meta の POST が CSRF トークンなしで拒否されることはありません。routes/web.php のルートでは拒否されます。 GET は Meta の認証に応答します。Meta は hub.mode、hub.verify_token、hub.challenge を送りますが、PHP は受信した変数名のドットをアンダースコアに書き換えるため、Laravel には hub_mode、hub_verify_token、hub_challenge として届きます。ドット付きの名前で読むと null になり、認証は通りません。challenge は response()->json() ではなく、プレーンテキストで返してください。 POST は、ペイロードをキューに入れたジョブに渡し、すぐに 200 を返します。パスには長いランダムなキーを入れ、両方のルートで確認してください。Meta は Tech Provider のアプリシークレットで配信に署名するため、署名ヘッダーをこちら側で検証することはできません。 ### Laravel から WhatsApp のメッセージを送信するには？ Laravel の HTTP クライアントを使い、phone number id のメッセージ用エンドポイントに POST を 1 回送ります。アクセストークンは bearer トークンとして付けます。どちらの値も接続から取得でき、ダッシュボードに表示され、get_api_credentials でも返されます。コードに直接書かず、環境変数を参照する config/services.php に置いてください。 ボディの形式は経過時間によって変わります。お客様の最後のメッセージから 24 時間以内なら、以下のように `text` オブジェクトを使えます。その時間を過ぎると、Meta が受け付けるのは、承認済みのメッセージテンプレートとその言語を指定した `template` オブジェクトだけで、フリーテキストはエラー 131047 で失敗します。原因はレスポンスで確認できます。失敗した呼び出しは、問題の内容を示す code を持つ error オブジェクトを返すので、捨てずにログに残してください。 このリクエストに EasyCoexistence 固有の部分はありません。Meta 自身のドキュメントにある呼び出しそのものなので、Guzzle でも素の cURL でも、どの PHP の HTTP クライアントでも同じように動きます。 ### 本番の Laravel ハンドラーには、それ以外に何が必要ですか？ 本物のキュー、重複排除、そして 24 時間の時間枠の確認です。 キューが重要なのは、Meta が遅い応答を再送するためです。HandleWhatsAppEvent::dispatch() がすぐに戻るのは、キュー接続が実際のもので、ワーカーが動いている場合だけです。sync ドライバーではジョブがリクエストの中で実行され、モデル呼び出しやデータベース書き込みが遅いと、重複配信につながります。 重複排除には、各メッセージに含まれるメッセージ ID の wamid を使います。再送は例外ではなく通常の動作だからです。その列にユニークインデックスを張るか、それをキーにしたキャッシュロックで十分です。 さらに、各連絡先が最後に書き込んだ時刻を保存してください。そのタイムスタンプがあれば、送信処理が自動でテキストかテンプレートかを選べます。お客様が待っている状態になってからエラー 131047 で気づく必要はありません。WhatsApp Business アプリで電話から入力した返信は、同じルートに echo イベントとして届くため、担当者が会話を引き継いだこともハンドラーで把握できます。 - hub.challenge をドット付きで読み取っている。PHP が hub_challenge に名前を変えているため、ハンドラーは空のボディを返し、Meta の認証は通りません。 - Webhook を routes/web.php に置いている。Meta の POST には CSRF トークンがないため、419 で拒否されます。 - sync キューにディスパッチしている。ジョブが 200 を返す前に実行され、処理が遅いと再送され、メッセージが二重に処理されます。 - challenge を response()->json() で返している。値を囲む引用符のせいで、Meta のチェックに失敗します。 **PHP 用の SDK はありますか？** 当社からは提供しておらず、必要もありません。API は Meta のもので、Meta がドキュメントを公開しており、Laravel の HTTP クライアントや Guzzle から直接呼び出せます。 **Laravel なしでも使えますか？** はい。素の PHP なら、$_GET['hub_challenge'] を読み取って text/plain で出力し、送信は cURL で行います。アンダースコアの規則は、すべての PHP フレームワークに当てはまります。 **なぜ URL のパスにキーが必要なのですか？** 実際に機能する認証だからです。Meta の署名は Tech Provider のアプリシークレットを使い、これは共有されません。そのため、第三者による偽のイベントの送信を防ぐのは URL のシークレットです。 **チームは引き続き電話を使えますか？** はい。Coexistence により、その番号で WhatsApp Business アプリが引き続き使え、電話から送ったメッセージは echo イベントとしてお使いのルートに届きます。 --- ## ブラジルでの WhatsApp Coexistence: 提供状況と Meta の料金 https://easycoexistence.com/ja/docs/whatsapp-coexistence-brazil Coexistence はブラジルで利用できます。WhatsApp Business アプリ利用者向けの Meta のオンボーディング資料には、地域の制限がありません。+55 宛てのメッセージには Meta のブラジル向け料金表が適用され、2026 年 10 月 1 日からはマーケティングテンプレートが US$ 0.0625、ユーティリティまたは認証テンプレートが US$ 0.0068 です。BRL の料金も併せて公表されています。 ### ブラジルで WhatsApp Coexistence は利用できますか？ はい、利用できます。Meta の WhatsApp Business アプリ利用者向けオンボーディング資料には、番号が満たすべき要件が挙げられていますが、国に関する条件はありません。ブラジルの番号も他の国と同じ条件で対象になります。すでに WhatsApp Business アプリで使われていること、アプリがバージョン 2.24.17 以降であること、Tech Provider または Solution Partner が Embedded Signup でオンボーディングを行うことが条件です。 接続後も端末のアプリはそのまま使え、同じ +55 の番号で Cloud API も利用できるようになります。アプリとの互換性を保つため、Meta はこれらの番号のスループットを 1 秒あたり 20 メッセージに固定しています。 ### ブラジルでは Meta はメッセージ 1 通あたりいくら請求しますか？ Meta は、配信されたメッセージごとに、カテゴリと受信者の国番号に基づいて料金を請求します。ブラジル（+55）は料金表に独立した市場として載っているため、ブラジルの番号宛てには地域平均ではなくブラジル固有の料金が適用されます。ここに示すのは、Meta の USD と BRL の料金表にある 2026 年 10 月 1 日からの定価です。ユーティリティと認証の料金は、月間の送信量に応じた段階でさらに下がることがあります。この段階は Meta が市場とカテゴリごとに適用します。 ### 無料のままのメッセージはどれですか？ 無料のものは 3 つあります。1 つ目は、端末の WhatsApp Business アプリで入力して送るメッセージです。Meta が Cloud API の料金を適用するのは API 経由の送信だけなので、オンボーディング後も無料です。2 つ目は、電話番号ごとに月 1,000 件まで無料のサービスメッセージです。これは 24 時間のカスタマーサービスウィンドウ内で送る、テンプレートを使わない返信を指します。3 つ目は、Click to WhatsApp 広告から顧客が来たときに開く無料エントリーポイントのウィンドウ内で送るすべてのメッセージで、最長 7 日間無料です。 2026 年 10 月 1 日に 2 点が変わりました。毎月 1,000 件を超えたサービスメッセージは課金対象になり、カスタマーサービスウィンドウ内で送るユーティリティテンプレートも課金対象になります。 ### Meta はブラジルの企業にレアルで請求しますか？ はい、現在は可能です。Meta は 2026 年 7 月 1 日にブラジル向けの請求ローカライズを開始しました。Billing Hub の Sold-To 国がブラジルである Solution Provider や直接連携の企業は、BRL でメッセージングアカウントを作成でき、そのアカウントの料金は Meta の現地法人である Facebook Brasil が BRL で請求します。 この変更には期限があります。対象となる顧客は、2027 年 6 月 30 日までに Business Portfolio 内のすべてのメッセージングアカウントを BRL に移行する必要があります。2027 年 7 月 1 日からは、BRL 以外のアカウントからのメッセージ配信を Meta が停止するためです。アカウント作成時に選んだ通貨は後から変更できないため、Meta は移行用に Currency Migration API を提供しています。 1. Check the number: Confirm the +55 number is on the WhatsApp Business app, version 2.24.17 or newer, and not attached to another provider. 2. Set up billing: Add a payment method in Billing Hub, in BRL if your Sold-To country is Brazil. 3. Run Embedded Signup: Log in with Facebook, choose the portfolio and the number, and confirm the connection in the app. - Sold-To 国がブラジルなのに、2027 年 6 月 30 日を過ぎても USD のメッセージングアカウントを使い続けること。2027 年 7 月 1 日から、そのアカウントのメッセージは Meta に配信されません。 - すべての返信が無料だと考えること。2026 年 10 月 1 日以降、1 つの番号で月 1,000 件を超えたサービスメッセージは課金されます。 - 企業の所在地で予算を組むこと。Meta は受信者の国番号で料金を決めるため、ポルトガルの番号宛てのメッセージには Rest of Western Europe の料金が適用されます。 **Coexistence を使うにはブラジルの企業である必要がありますか？** いいえ。Meta の要件は番号とアプリに関するもので、企業の登録地は問われません。企業の所在地が影響するのは、請求の通貨と請求元の Meta 法人だけです。 **BRL の料金は USD の料金と同じですか？** Meta は通貨ごとに別の料金表を公表しています。ブラジルについては、2026 年 10 月 1 日の料金表で、マーケティングが BRL 0.3217、ユーティリティと認証が BRL 0.035 です。 **端末から送るメッセージには料金がかかりますか？** いいえ。Meta の資料によると、WhatsApp Business アプリから送るメッセージは、オンボーディング後も無料です。Cloud API の料金が適用されるのは API 経由の送信だけです。 **アカウントに支払い方法がない場合はどうなりますか？** 1,000 件の無料枠の範囲内であれば、Meta はサービスメッセージを引き続き配信しますが、枠を使い切ると配信を停止します。Meta が課金する送信を行う前に、Billing Hub で支払い方法を追加してください。 --- ## メキシコでの WhatsApp Coexistence：対応状況と Meta の料金 https://easycoexistence.com/ja/docs/whatsapp-coexistence-mexico Coexistence はメキシコで利用できます。WhatsApp Business アプリのユーザーを対象とした Meta のオンボーディング資料に、地域の制限は設けられていないためです。+52 の番号宛てのメッセージには、Meta のメキシコ向け料金表が適用されます。2026 年 10 月 1 日からは、マーケティングテンプレートが US$ 0.0397、ユーティリティまたは認証テンプレートが US$ 0.0085 です。ペソ建ての料金表では、それぞれ MXN 0.7298 と MXN 0.1565 になります。 ### メキシコの企業は WhatsApp Coexistence を使えますか？ はい、使えます。WhatsApp Business アプリのユーザーをオンボーディングする際の Meta の要件は、国ではなく番号とアプリに関するものです。具体的には、その番号が WhatsApp Business アプリですでに有効であること、アプリのバージョンが 2.24.17 以降であること、Tech Provider または Solution Partner が Embedded Signup で接続することの 3 点です。 これらの条件を満たす +52 の番号は、スマートフォンのアプリをそのまま使い続けながら、同じ番号で Cloud API も利用できるようになります。こうした共有番号では、Meta が API のスループットを 1 秒あたり 20 メッセージに制限しています。 ### メキシコでは Meta はメッセージ 1 件あたりいくら課金しますか？ Meta は配信されたメッセージごとに課金します。料金は、メッセージのカテゴリと受信者の国番号の 2 点で決まります。メキシコ（+52）は料金表に専用の行があります。ここに示すのは 2026 年 10 月 1 日から適用される定価で、この日は Meta がメキシコのマーケティング料金を引き上げた日でもあります。月間の送信量が増えると、Meta のボリューム階層により、ユーティリティと認証の料金が下がる場合があります。 ### 無料になるのはどのような場合ですか？ WhatsApp Business アプリでスマートフォンから入力して送るメッセージは無料です。Meta の資料によると、番号をオンボーディングした後も変わりません。Cloud API 経由で送るメッセージだけが、Cloud API の料金に従います。 API 側では、ビジネス用の電話番号ごとに毎月 1,000 件のサービスメッセージが無料です。これは 24 時間のカスタマーサービスウィンドウ内で送る、テンプレートを使わない返信が対象です。無料枠は毎月リセットされ、翌月への繰り越しはありません。Click to WhatsApp 広告から来たお客様については、最大 7 日間の無料エントリーポイントウィンドウが開きます。この間は、マーケティング、ユーティリティ、認証、サービスのいずれのメッセージにも Meta は課金しません。 ### Meta はメキシコのアカウントにペソで請求できますか？ MXN は、Meta が WhatsApp Business Platform で提供する 16 通貨の 1 つで、2026 年 1 月 1 日に開始されました。Meta は USD の料金表と並べて、MXN の料金表も全面的に公開しています。 通貨はメッセージング用アカウントの作成時に選び、後から単純に切り替えることはできません。後で別の通貨に移行したい場合は、Meta の Currency Migration API を使います。ブラジルやインドとは異なり、Meta の料金ページにはメキシコで現地通貨への請求移行を義務づける記載はありません。そのため、MXN と USD のどちらを選ぶかは企業の判断に任されています。 1. Check the number: Make sure the +52 number runs the WhatsApp Business app, version 2.24.17 or newer, and is not attached to another provider. 2. Pick the currency: Choose MXN or USD when the account is created, and add a payment method in Billing Hub. 3. Connect: Run Embedded Signup, select the portfolio and the number, and confirm the connection from the app. - ペソで請求を受けたいのに USD でアカウントを作成してしまうこと。通貨は作成時に固定され、変更には Meta の Currency Migration API が必要です。 - 2026 年 10 月 1 日より前の料金を参照すること。Meta はこの日にメキシコのマーケティング料金を引き上げました。 - 返信は常に無料だと思い込むこと。番号ごとに月 1,000 件のサービスメッセージを超えると、Meta は課金します。 **+52 1 で始まる携帯電話の番号は扱いが異なりますか？** Meta は +52 の国番号全体をメキシコ市場に対応させています。そのため、メキシコの受信者にはすべて、メッセージのカテゴリに応じたメキシコの料金が課金されます。 **メキシコの料金は最近変わりましたか？** はい。Meta の 2026 年 10 月 1 日の更新で、メキシコのマーケティング料金が引き上げられました。ユーティリティと認証の料金は、この変更の対象に含まれていません。 **米国のお客様へのメッセージも同じ料金ですか？** いいえ。米国の番号は Meta の北米地域に属し、独自の料金が設定されています。料金は受信者の国番号で決まります。 **API を接続すると、アプリは使えなくなりますか？** いいえ。番号は WhatsApp Business アプリに残り、スマートフォンでの送受信もこれまでどおり続けられます。 --- ## WhatsApp Coexistence のコロンビア対応状況と Meta の料金 https://easycoexistence.com/ja/docs/whatsapp-coexistence-colombia Coexistence はコロンビアで利用できます。WhatsApp Business アプリ利用者向けの Meta のオンボーディング資料に、国による制限は記載されていません。+57 の番号宛てのメッセージには Meta のコロンビア向け料金表が適用されます。2026 年 10 月 1 日以降は、マーケティングテンプレートが US$ 0.0125、ユーティリティまたは認証テンプレートが US$ 0.0008 です。ペソ建ての料金表では、それぞれ COP 46.0227 と COP 2.9455 です。 ### WhatsApp Coexistence はコロンビアの番号で使えますか？ はい、使えます。Meta の WhatsApp Business アプリ利用者向けオンボーディング資料には、番号が満たすべき条件が示されていますが、地域に関する条件はありません。+57 の番号は、すでに WhatsApp Business アプリで使われていること、アプリがバージョン 2.24.17 以降であること、Tech Provider または Solution Partner が実行する Embedded Signup でオンボーディングすることを満たせば対象になります。 オンボーディング後も、スマートフォンではチャットを含めてこれまでどおり利用でき、同じ番号が Cloud API 経由でも応答します。共有番号の API 側スループットは 1 秒あたり 20 メッセージで固定されています。 ### コロンビア宛ての Meta のメッセージ単位の料金はいくらですか？ Meta は、配信されたメッセージ 1 件ごとに、カテゴリと受信者の国番号に応じて料金を設定しています。コロンビア（+57）は個別に設定された市場で、2026 年 10 月 1 日の料金表では、Meta が掲載する「その他の中南米」地域を含め、中南米の市場の中でマーケティングとユーティリティの料金が最も低くなっています。以下の数値は定価で、月間の送信量が多い場合はボリューム階層によってユーティリティと認証がさらに下がることがあります。 ### コロンビアで無料になるメッセージはどれですか？ 他の国と同じです。Meta の無料の対象は市場ごとではなく、全世界共通だからです。 番号を接続した後も、スマートフォンの WhatsApp Business アプリから送るメッセージは無料のままです。Cloud API の料金が発生するのは API から送信した分だけです。各企業の電話番号には、24 時間のカスタマーサービスウィンドウ内でテンプレートを使わずに返信するサービスメッセージが、月 1,000 件まで無料で付与されます。Click to WhatsApp 広告から始まった会話では、最大 7 日間の無料エントリーポイントウィンドウが開き、Meta Business Agent のメッセージを除くすべてのカテゴリで料金は発生しません。 2026 年 10 月 1 日からは、開いているカスタマーサービスウィンドウ内で送信したユーティリティテンプレートは課金対象です。 ### コロンビアの企業は Meta にペソで支払えますか？ COP は Meta が 2026 年に追加した通貨の一つで、2026 年 4 月 1 日から利用でき、専用の料金表が公開されています。Meta の COP 料金表ではすべての市場がペソで表示されます。そのため、コロンビアの企業がメキシコやスペインのお客様にメッセージを送った場合も、その料金は COP で確認できます。 通貨はメッセージングアカウントの作成時に設定され、以後は固定されます。後から変更するには Meta の Currency Migration API を使います。Meta の料金ページで現地通貨への請求移行が必須とされているのはブラジルとインドだけです。コロンビアでは COP は必須ではなく、選択肢の一つです。 1. Check the number: The +57 number must be on the WhatsApp Business app, version 2.24.17 or newer, and free of any other provider. 2. Choose COP or USD: Pick the currency at account creation and add a payment method in Billing Hub. 3. Run Embedded Signup: Log in with Facebook, select the portfolio and the number, and confirm in the app. - コロンビアの料金をすべてのお客様に当てはめてしまうことです。ペルーやチリの番号宛てのメッセージには、その市場の料金が適用され、2026 年 10 月の料金表では数倍高くなります。 - 請求通貨を軽い気持ちで決めてしまうことです。アカウントを作成した後に変更するには、Meta の Currency Migration API が必要です。 - アカウントに支払い方法を登録しないままにすることです。その月の無料の 1,000 件を使い切ると、サービスメッセージが配信されなくなります。 **コロンビアの料金は近隣の国よりなぜ大幅に低いのですか？** Meta は市場ごとに料金を設定しており、個々の数値の理由は説明していません。2026 年 10 月 1 日の料金表では、コロンビアが他の中南米の市場より低く掲載されているだけです。 **認証はユーティリティと料金が異なりますか？** コロンビアでは異なりません。2026 年 10 月 1 日の料金表ではどちらも US$ 0.0008 で、authentication-international の料金は適用されません。 **お客様から届くメッセージにも料金はかかりますか？** いいえ。Meta が課金するのは企業が配信したメッセージだけで、ユーザーから企業へのメッセージは無料です。 **アプリのチャット履歴は残りますか？** はい。番号を API に接続した後も、WhatsApp Business アプリはスマートフォンでチャットを保ったまま使えます。 --- ## アルゼンチンでの WhatsApp Coexistence: 対応状況と Meta の料金 https://easycoexistence.com/ja/docs/whatsapp-coexistence-argentina Coexistence はアルゼンチンで利用できます。WhatsApp Business アプリ利用者向けの Meta のオンボーディング資料に、地域の制限が設けられていないためです。+54 の番号宛てのメッセージには、アルゼンチン独自の料金が適用されます。2026 年 10 月 1 日以降は、マーケティングテンプレートが USD 0.0618、ユーティリティまたは認証テンプレートが USD 0.026 です。Meta のペソ建て料金表では、それぞれ ARS 89.562 と ARS 37.6798 になります。 ### アルゼンチンの番号で Coexistence は利用できますか？ はい、利用できます。WhatsApp Business アプリ利用者をオンボーディングするための Meta の資料には、国によって条件が変わる記載はありません。Meta が確認するのは番号とアプリです。具体的には、WhatsApp Business アプリですでに使われている +54 の番号で、アプリのバージョンが 2.24.17 以降であり、Tech Provider または Solution Partner が Embedded Signup で接続することが条件です。 結果として、1 つの番号を 2 通りの方法で使えます。スタッフはこれまでどおり携帯電話から返信でき、ソフトウェアは Cloud API を通じて送受信できます。ただし、番号をアプリと共有している間は、Meta により 1 秒あたり 20 メッセージが上限になります。 ### アルゼンチン宛てのメッセージ料金は Meta でいくらですか？ 配信されたメッセージには、カテゴリごとに料金がかかります。料金は、受信者の国番号が属する市場の単価で決まります。アルゼンチン（+54）は、Meta の料金表で独立した市場です。ここに挙げるのは、Meta の USD と ARS の料金表から取った、2026 年 10 月 1 日から有効な標準料金です。ユーティリティと認証については、1 か月にアルゼンチンへ十分な数を送信したビジネスポートフォリオに対し、Meta の月間ボリューム別の段階料金で単価が下がります。 ### アルゼンチンの企業が無料で送れるメッセージはありますか？ 携帯電話で入力した返信は無料です。Meta の資料によると、WhatsApp Business アプリから送るメッセージはオンボーディング後も無料のままで、Cloud API の料金が適用されるのは API 経由の送信だけです。 API 経由の場合、企業の電話番号ごとに毎月 1,000 件の無料サービスメッセージ枠があります。これは、24 時間のカスタマーサービスウィンドウ内で送るテンプレート以外の返信が対象です。枠は毎月リセットされ、未使用分は繰り越されません。Click to WhatsApp 広告から連絡してきたお客様については、最大 7 日間の無料エントリーポイントウィンドウが開きます。この間は、マーケティング、ユーティリティ、認証、サービスのいずれのメッセージにも料金はかかりません。 ### アルゼンチンのアカウントはペソで請求できますか？ ARS は 2026 年 4 月 1 日から WhatsApp Business Platform の通貨として利用可能になりました。Meta は USD の料金表と並べて、ARS の完全な料金表も公開しています。ペソの料金表では、アルゼンチンだけでなくすべての市場が ARS で示されています。 通貨はメッセージングアカウントの作成時に決まり、その後は自由に切り替えられません。切り替えには Meta の Currency Migration API を使います。Meta の料金ページが現地通貨での請求を必須としているのはブラジルとインドだけです。そのため、アルゼンチンでは ARS と USD のどちらにするかを企業が選べます。 1. Check the number: The +54 number must run the WhatsApp Business app at version 2.24.17 or newer and not be connected to another provider. 2. Set the currency and payment: Choose ARS or USD when the account is created and add a payment method in Billing Hub. 3. Connect the number: Complete Embedded Signup with the portfolio and number, then confirm the link in the app. - ラテンアメリカ共通の地域料金が適用されると思い込むこと。Meta の料金表では、アルゼンチンは独自の行を持ち、その他のラテンアメリカとは異なる金額です。 - ユーティリティテンプレートを返信として送れば無料だと考えること。2026 年 10 月 1 日以降、Meta はカスタマーサービスウィンドウ内のユーティリティテンプレートにも料金を課します。 - 日付を確認せずに料金表を読むこと。Meta は適用開始日つきで料金表を公開しており、ここに載せた金額は 2026 年 10 月 1 日時点のものです。 **お客様から届いたメッセージにも Meta の料金はかかりますか？** いいえ。Meta が料金を課すのは、企業がユーザーに配信したメッセージだけです。ユーザーから企業に送られたメッセージには課金されません。 **ARS の金額は為替レートに合わせて変わりますか？** Meta は通貨ごとの料金表を適用開始日つきで公開し、独自のスケジュールで料金を更新します。USD の料金表を換算するのではなく、最新の ARS 料金表をご確認ください。 **アルゼンチンでは認証の料金とユーティリティの料金は同じですか？** はい。2026 年 10 月 1 日の料金表では、どちらも USD 0.026 です。また、Meta はアルゼンチンに対して国際認証の料金を設定していません。 **接続した後も、アプリは使い続けられますか？** はい。WhatsApp Business アプリは携帯電話でそのまま使え、同じ番号で API も利用できるようになります。 --- ## チリでの WhatsApp Coexistence：対応状況と Meta の料金 https://easycoexistence.com/ja/docs/whatsapp-coexistence-chile Coexistence はチリで利用できます。WhatsApp Business アプリのユーザー向けに Meta が公開しているオンボーディング資料には、国や地域の条件がありません。+56 の番号宛てのメッセージには Meta のチリ向け料金表が適用され、2026 年 10 月 1 日からはマーケティングテンプレート 1 件あたり US$ 0.0889、ユーティリティまたは認証テンプレート 1 件あたり US$ 0.02 です。ペソ建ての料金表では、それぞれ CLP 78.4917 と CLP 17.6584 になります。 ### チリの企業は WhatsApp Coexistence を使えますか？ はい、使えます。Meta の WhatsApp Business アプリユーザー向けオンボーディング資料には、番号、アプリ、パートナーに関する条件はありますが、国に関する条件はありません。+56 の番号は、WhatsApp Business アプリで使用中で、バージョン 2.24.17 以降であり、Tech Provider または Solution Partner が Embedded Signup で接続すれば対象になります。 スマートフォンではこれまでどおりチャットを使い続けられます。番号には Cloud API へのアクセスが加わり、送信上限は毎秒 20 メッセージで固定されます。これは Meta がアプリと共有している番号に適用する上限です。 ### チリ宛てのメッセージに Meta はいくら課金しますか？ Meta は配信されたメッセージに対して、カテゴリ別に、受信者の市場の料金で課金します。チリ（+56）は個別に指定された市場で、2026 年 10 月 1 日時点の料金表では、マーケティング料金が中南米の全項目で最も高く、「その他の中南米」地域よりも高くなっています。ユーティリティと認証は US$ 0.02 です。チリ宛てに大量送信するポートフォリオでは、Meta の月間ボリューム階層によってこの 2 つが下がる場合があります。 ### チリ宛てで、Meta が課金しないメッセージは何ですか？ WhatsApp Business アプリそのものから送るメッセージです。Meta の資料によると、アプリのメッセージはオンボーディング後も料金がかからず、料金の対象になるのは Cloud API からの送信だけです。 API では、ビジネス電話番号 1 件につき毎月最初の 1,000 件のサービスメッセージには課金されません。これは、24 時間のカスタマーサービスウィンドウ内で送るテンプレート以外の返信を指します。また、Click to WhatsApp 広告から始まった会話では、最大 7 日間の無料エントリーポイント期間が開き、Meta Business Agent のメッセージを除くすべてのカテゴリで課金されません。 チリのマーケティング料金を考えると、販促メッセージを送るなら、この無料エントリーポイント期間がもっとも安い方法です。 ### Meta はチリペソでの請求に対応していますか？ はい、選択肢として対応しています。CLP は 2026 年 4 月 1 日に、その年に Meta が追加した通貨の 1 つとして有効になりました。Meta はすべての市場を網羅した CLP 料金表を公開しているため、海外の顧客宛てのメッセージもペソで表示されます。 請求通貨はメッセージングアカウントの作成時に選び、その後は固定されます。変更できるのは、Meta の Currency Migration API を利用する場合だけです。Meta の料金ページで現地通貨での請求が必須とされているのはブラジルとインドだけで、チリの企業は CLP か USD を自分で選びます。 1. Check the number: The +56 number must be on the WhatsApp Business app, version 2.24.17 or newer, and not connected to another provider. 2. Choose CLP or USD: Set the currency at account creation and add a payment method in Billing Hub. 3. Connect: Run Embedded Signup, pick the portfolio and the number, and confirm from the app. - フォローアップをすべてマーケティングテンプレートにしてしまうこと。チリでは 1 通あたり US$ 0.0889 になりますが、正しく分類したユーティリティテンプレートなら US$ 0.02 です。 - サービスメッセージの無料枠が繰り越されると思い込むこと。無料の 1,000 件は毎月リセットされ、未使用分は持ち越されません。 - チリのキャンペーンの費用を「その他の中南米」の数字で見積もること。チリは個別に指定された市場で、独自の料金があります。 **マーケティング料金はチリのほうがアルゼンチンより安いですか？** いいえ。2026 年 10 月 1 日の料金表では、チリのマーケティング料金は US$ 0.0889、アルゼンチンは US$ 0.0618 です。 **Meta は私のテンプレートのカテゴリを変更することがありますか？** はい。Meta はテンプレートのカテゴリを審査しており、変更することがあります。カテゴリが変わると、そのテンプレートに適用される料金も変わります。 **受信したメッセージにも料金はかかりますか？** いいえ。Meta が課金するのは企業が配信したメッセージだけで、顧客が送ったメッセージには課金しません。 **番号はアプリでも引き続き使えますか？** はい。番号を API に接続した後も、WhatsApp Business アプリはスマートフォンで有効なままです。 --- ## ペルーでの WhatsApp Coexistence: 利用可否と Meta の料金 https://easycoexistence.com/ja/docs/whatsapp-coexistence-peru Coexistence はペルーで利用できます。WhatsApp Business アプリ利用者向けの Meta のオンボーディング資料に、国による制限がないためです。+51 の番号宛てのメッセージにはペルーの料金表が適用されます。2026 年 10 月 1 日以降は、マーケティングテンプレートが US$ 0.0703、ユーティリティまたは認証テンプレートが US$ 0.03 です。Meta の PEN 料金表では、それぞれ PEN 0.2339 と PEN 0.0998 になります。 ### ペルーで WhatsApp Coexistence は利用できますか？ はい、利用できます。WhatsApp Business アプリ利用者をオンボーディングするための Meta の資料では、条件が課されるのは国ではなく、番号とアプリに対してです。+51 の番号であれば、すでに WhatsApp Business アプリで有効であること、アプリのバージョンが 2.24.17 以降であること、Tech Provider または Solution Partner を通じて Embedded Signup でオンボーディングすることを満たせば対象になります。 接続後も、スマートフォンでは通常どおり送受信でき、同じ番号が Cloud API からも利用できるようになります。アプリと共有する番号の API スループットは、Meta により毎秒 20 メッセージに固定されています。 ### ペルー宛てのメッセージ 1 件あたりの Meta の料金はいくらですか？ Meta は配信されたメッセージ単位で課金し、カテゴリと、受信者の国番号が示す市場によって料金が決まります。ペルー（+51）には専用の料金区分があります。2026 年 10 月 1 日に Meta はペルーのユーティリティと認証の料金を引き上げ、現在は US$ 0.03 です。これは料金表に載っているラテンアメリカの市場の中で最も高いユーティリティ料金です。ここで示すのは定価で、月間の送信量が多い場合はボリューム段階によりユーティリティと認証が安くなることがあります。 ### ペルーの企業で無料のままなのは何ですか？ スマートフォンの WhatsApp Business アプリから送るメッセージです。Meta の資料によると、これらはオンボーディング後も無料で、課金されるのは Cloud API 経由で送るメッセージだけです。 API を使う場合、Meta は企業の電話番号ごとに毎月 1,000 件のサービスメッセージを無料にしています。これは 24 時間のカスタマーサービスウィンドウが開いている間に送る、テンプレートを使わない返信で、毎月リセットされます。Click to WhatsApp 広告から来たお客様の場合は、最長 7 日間の無料のエントリーポイントウィンドウが開き、その間はマーケティング、ユーティリティ、認証、サービスのどのメッセージにも課金されません。 カスタマーサービスウィンドウ内で送るユーティリティテンプレートは、2026 年 10 月 1 日から課金されています。 ### Meta はペルーのアカウントにソル建てで請求できますか？ はい、PEN を選べます。PEN は Meta が 2026 年に追加した通貨の一つで、2026 年 4 月 1 日に開始されました。Meta は、料金を設定しているすべての市場を網羅した PEN 料金表を公開しています。 通貨は Messaging アカウントの作成時に選び、その後は固定されます。変更できるのは Meta の Currency Migration API を使う場合だけです。Meta の料金ページで現地通貨への請求移行が必須とされているのはブラジルとインドだけなので、ペルーの企業は PEN と US$ のどちらにするかを自分で決められます。 1. Check the number: Confirm the +51 number is on the WhatsApp Business app, version 2.24.17 or newer, and not attached to another provider. 2. Choose PEN or USD: Pick the currency when the account is created and add a payment method in Billing Hub. 3. Run Embedded Signup: Log in with Facebook, select the portfolio and the number, and confirm the connection in the app. - 2026 年 10 月 1 日より前の金額でユーティリティの送信費用を見積もること。Meta はこの日にペルーのユーティリティと認証の料金を引き上げました。 - 返信にユーティリティテンプレートを使い続けること。ウィンドウが開いている間は、無料のサービスメッセージで同じ役割を果たせます。上限は番号ごとに月 1,000 件です。 - 近隣の市場も同じ料金だと思い込むこと。同じ料金表で、コロンビアのユーティリティ料金は US$ 0.0008 です。 **2026 年 10 月にユーティリティの費用が増えたのはなぜですか？** Meta が 2026 年 10 月 1 日にペルーのユーティリティと認証の料金を引き上げ、同じ日からカスタマーサービスウィンドウ内で送るユーティリティテンプレートへの課金も始めたためです。 **お客様から届くメッセージにも Meta は課金しますか？** いいえ。課金されるのは、企業が配信したメッセージだけです。 **ペルーには国際認証の料金区分がありますか？** いいえ。2026 年 10 月 1 日の料金表にペルー向けの区分はないため、認証は US$ 0.03 で課金されます。 **スマートフォンのアプリは使い続けられますか？** はい。番号を API に接続した後も、WhatsApp Business アプリはスマートフォンでそのまま動作します。 --- ## コスタリカでの WhatsApp Coexistence:利用可否と Meta の料金 https://easycoexistence.com/ja/docs/whatsapp-coexistence-costa-rica コスタリカでも Coexistence を利用できます。WhatsApp Business アプリのユーザー向けに Meta が公開しているオンボーディング資料に、国による制限はありません。Meta の料金表にコスタリカ独自の項目はなく、+506 の番号には Rest of Latin America の料金が適用されます。2026 年 10 月 1 日からは、マーケティングのメッセージテンプレートが USD 0.074、ユーティリティまたは認証のメッセージテンプレートが USD 0.0113 です。 ### コスタリカの番号で WhatsApp Coexistence を使えますか？ はい。WhatsApp Business アプリのユーザーをオンボーディングするための Meta の資料では、番号とアプリに条件がありますが、国の条件はありません。+506 の番号は、すでに WhatsApp Business アプリで使われていること、アプリがバージョン 2.24.17 以降であること、Tech Provider または Solution Partner が Embedded Signup で接続することを満たせば対象になります。 スマートフォンはこれまでのチャットをそのまま使え、番号では Cloud API も利用できるようになります。アプリと API で共有する番号のスループットは、Meta により 1 秒あたり 20 メッセージに固定されています。 ### なぜコスタリカは Rest of Latin America の料金になるのですか？ Meta の料金表では 39 か国が個別に掲載され、残りは 8 つの地域にまとめられています。コスタリカ（+506）は Rest of Latin America 地域の 15 市場の一つで、パナマ、グアテマラ、エクアドル、ウルグアイなどと同じ区分です。これらの市場の番号に配信されたメッセージには、すべてこの地域の料金が課金されます。 ユーティリティと認証のボリュームティアでも、この地域区分が関わります。ティアは市場とカテゴリごとに数えられるため、Rest of Latin America の各国宛てのメッセージは、コスタリカ単独ではなく同じ地域のティアに合算されます。 ### コスタリカの企業にとって、無料になるメッセージは何ですか？ スマートフォンの WhatsApp Business アプリで入力したメッセージです。Meta の資料によると、オンボーディング後もアプリのメッセージは無料で、Cloud API の料金は API 経由の送信だけが対象です。 API 側では、企業の電話番号ごとに毎月 1,000 件のサービスメッセージが無料です。これは 24 時間のカスタマーサービスウィンドウ内で送るテンプレート以外の返信で、翌月への繰り越しはありません。Click to WhatsApp 広告から始まった会話では、最大 7 日間の無料エントリーポイントウィンドウが開き、この間はマーケティング、ユーティリティ、認証、サービスのどのメッセージにも Meta は課金しません。カスタマーサービスウィンドウ内で送るユーティリティのメッセージテンプレートは、2026 年 10 月 1 日から課金対象です。 ### Meta はコスタリカのアカウントにどの通貨で請求しますか？ Meta が WhatsApp Business Platform で有効にしている請求通貨は 16 種類で、コスタリカ・コロンは含まれていません。コスタリカの企業は、メッセージングアカウントを作成するときに公開されている通貨から USD などを選びます。Rest of Latin America の料金は、Meta の各通貨の料金表に掲載されています。 アカウント作成後は、通貨を自由に変更できません。切り替えには Meta の Currency Migration API を使います。Meta の料金ページには、コスタリカ向けの現地請求プログラムは載っていません。 1. Check the number: The +506 number must be on the WhatsApp Business app, version 2.24.17 or newer, and not attached to another provider. 2. Set up billing: Choose one of Meta's supported currencies, such as USD, and add a payment method in Billing Hub. 3. Connect: Complete Embedded Signup with the portfolio and the number, and confirm the link from the app. - 料金表でコスタリカの項目を探してしまう。項目はなく、+506 は Rest of Latin America で請求されます。 - 中米の近隣国はメキシコと同じ料金だと思い込む。メキシコは個別に掲載された市場で、地域よりマーケティング料金が低く設定されています。 - 返信にユーティリティのメッセージテンプレートを使ってしまう。開いているウィンドウ内のサービスメッセージは、番号ごとに月 1,000 件まで無料です。 **コスタリカ宛てのメッセージは、メキシコ宛てより安いですか？** マーケティングについては安くありません。2026 年 10 月 1 日の料金表では、Rest of Latin America はマーケティングのメッセージテンプレート 1 件あたり USD 0.074、メキシコは USD 0.0397 です。 **Meta への支払いをコロンでできますか？** できません。コスタリカ・コロンは、Meta が WhatsApp Business Platform で有効にしている 16 種類の通貨に含まれていません。 **お客様から届くメッセージにも料金はかかりますか？** いいえ。Meta が課金するのは、企業が配信するメッセージだけです。 **API を接続すると、アプリは使えなくなりますか？** いいえ。WhatsApp Business アプリは、これまでのチャットとともにスマートフォンでそのまま使えます。 --- ## スペインでの WhatsApp Coexistence: 提供状況と Meta の料金 https://easycoexistence.com/ja/docs/whatsapp-coexistence-spain Coexistence はスペインで利用できます。WhatsApp Business アプリのユーザー向けに Meta が公開しているオンボーディング資料には、EU を含め、地域による制限はありません。+34 の番号宛てのメッセージには、スペイン独自の料金表が適用されます。2026 年 10 月 1 日以降、マーケティングテンプレートは EUR 0.0585、ユーティリティまたは認証テンプレートは EUR 0.0166 です。USD では 0.0707 と 0.02 です。 ### WhatsApp Coexistence はスペインと EU で利用できますか？ はい、利用できます。Meta が現在公開している WhatsApp Business アプリのユーザー向けオンボーディング資料には、番号、アプリ、パートナーに関する要件はありますが、地域による制限は記載されていません。+34 の番号は、すでに WhatsApp Business アプリで使用中であること、バージョンが 2.24.17 以降であること、Tech Provider または Solution Partner が Embedded Signup で接続することの 3 つを満たせば対象になります。 提供開始当初の、EU を除外した一覧が今も出回っていますが、Meta の資料では裏付けられていません。オンボーディング後も携帯端末のアプリはそのまま使え、番号は Cloud API 経由で毎秒 20 メッセージの固定速度で応答します。 ### スペイン宛てのメッセージに Meta はいくら課金しますか？ Meta は、配信されたメッセージ 1 件ごとに、カテゴリと受信者の国番号に基づく市場別の料金を課金します。スペイン（+34）は個別の市場として設定されており、ポルトガルやアイルランドなどを含む西ヨーロッパのその他地域とは別枠です。ここに示すのは 2026 年 10 月 1 日から適用される定価で、マーケティング料金の直近の引き上げは 2026 年 7 月 1 日でした。スペイン宛ての月間送信量が多いポートフォリオでは、ボリュームティアによりユーティリティと認証の料金が下がる場合があります。 ### スペインの企業にとって無料になるメッセージはどれですか？ 端末の WhatsApp Business アプリから送信するメッセージです。Meta の資料には、オンボーディング後も無料のままと明記されており、Cloud API の料金が適用されるのは API 経由で送るメッセージだけです。 API 経由の場合、Meta は企業の電話番号ごとに、毎月 1,000 件の無料のサービスメッセージを提供します。これは 24 時間のカスタマーサービスウィンドウ内に送る、テンプレートを使わない返信が対象で、毎月リセットされます。Click to WhatsApp 広告から来たお客様の場合は、最長 7 日間の無料のエントリーポイントウィンドウが開き、その間はマーケティング、ユーティリティ、認証、サービスのどのメッセージも課金されません。 2026 年 10 月 1 日以降は、開いているカスタマーサービスウィンドウ内で送るユーティリティテンプレートは課金対象です。 ### スペインの企業は Meta から EUR で請求を受けられますか？ はい。EUR は、Meta が 2026 年に通貨を 10 種類追加する前から、WhatsApp Business Platform で選べる通貨でした。Meta はスペインだけでなく全市場を EUR 建てにした完全な料金表を公開しています。 通貨はメッセージングアカウントの作成時に選び、その後は固定されます。変更できるのは Meta の Currency Migration API を使う場合だけです。Meta の料金ページが現地通貨への請求移行を必須としているのはブラジルとインドだけなので、スペインの企業は EUR か他の対応通貨を自分で選びます。 1. Check the number: The +34 number must be on the WhatsApp Business app, version 2.24.17 or newer, and not attached to another provider. 2. Choose EUR or USD: Set the currency when the account is created and add a payment method in Billing Hub. 3. Run Embedded Signup: Log in with Facebook, select the portfolio and the number, and confirm the connection in the app. - EU を除外した古い提供状況の一覧を信じてしまうこと。Meta の現在のオンボーディング資料に地域制限はありません。 - ポルトガルのお客様にスペインの料金を当てはめること。ポルトガル（+351）は西ヨーロッパのその他地域に含まれ、料金が異なります。 - 2026 年 7 月 1 日より前のマーケティング料金を使うこと。Meta はその日にスペインのマーケティング料金を引き上げました。 **Coexistence は EU で利用できなかった時期がありましたか？** 提供開始当初の一覧では EU が除外されていました。Meta の現在の Business アプリユーザー向けオンボーディング資料には地域制限がないため、実際の接続フローで確認するのが確実です。 **スペインから中南米へ送るメッセージも、スペインの料金になりますか？** いいえ。Meta は受信者の国番号で課金するため、メキシコの番号宛てならメキシコの料金が適用されます。 **お客様から届くメッセージにも料金はかかりますか？** いいえ。Meta が課金するのは、企業がユーザーに配信したメッセージだけです。 **接続後も WhatsApp Business アプリは使えますか？** はい。WhatsApp Business アプリはチャット履歴とともに端末に残り、番号に API でのアクセスが加わります。 --- ## インドでの WhatsApp Coexistence: 対応状況、Meta の料金、INR 請求 https://easycoexistence.com/ja/docs/whatsapp-coexistence-india Coexistence はインドの番号でも利用できます。WhatsApp Business アプリのユーザー向けに Meta が公開しているオンボーディング資料には、国の制限は記載されていません。2026 年 10 月 1 日から、+91 の番号に配信されたマーケティング用メッセージテンプレートには US$ 0.0118、ユーティリティ用または認証用のメッセージテンプレートには US$ 0.0014 が Meta から課金されます。Billing Hub の Sold-To 国がインドの企業は、すべての WhatsApp Business Account を 2026 年 12 月 31 日までに INR へ移行する必要があります。 ### インドで WhatsApp Coexistence は利用できますか？ はい、利用できます。Meta が現在公開している WhatsApp Business アプリユーザー向けのオンボーディング資料には、要件として、アプリのバージョン 2.24.17 以降、そして Embedded Signup を運用する Tech Provider または Solution Partner が挙げられています。制限事項は、スループットが毎秒 20 メッセージで固定されることの 1 点です。国、地域、国番号による制限は記載されていないため、WhatsApp Business アプリで有効な +91 の番号は、他国の番号と同じ条件で対象になります。 インドの番号が利用できなくなる原因は、他の国の番号と同じです。個人向けの WhatsApp アプリのままである、アプリのバージョンが 2.24.17 より古い、すでに別のプロバイダーに接続されている、のいずれかです。Embedded Signup で番号が拒否されなければ、Coexistence を利用できます。 ### インドでは Meta のメッセージ単価はいくらですか？ Meta は配信されたメッセージテンプレートごとに課金します。料金は受信者の国番号で決まり、企業の所在地には左右されません。+91 の番号に配信されたメッセージテンプレートは、送信元がどこにあっても、インドの料金が適用されます。 以下の金額は、2026 年 10 月 1 日から適用される Meta の USD および INR 料金表に基づきます。24 時間のカスタマーサービスウィンドウ内であれば、メッセージテンプレート以外の返信は無料です。このウィンドウ内で送るユーティリティ用メッセージテンプレートも無料で、Coexistence の番号で WhatsApp Business アプリから入力して送るメッセージも引き続き無料です。マーケティング用メッセージテンプレートは常に課金されます。Meta の月間ボリュームティアにより、大量送信の場合はユーティリティと認証の料金が下がることがあります。 ### インドの INR 請求では何が変わりますか？ Meta は 2026 年 1 月 1 日に INR 請求のローカライズを開始しました。対象は、Billing Hub の Sold-To 国がインドであるパートナーと、直接連携している企業です。これらの企業は、ポートフォリオ内のすべての WhatsApp Business Account を 2026 年 12 月 31 日までに INR へ移行しなければなりません。Meta は、2027 年 1 月 1 日以降、対象のお客様に属する INR 以外のアカウントのメッセージは配信しなくなると表明しています。 Coexistence の番号では、API 経由の有料送信が影響を受けます。支払い方法が、企業自身の WhatsApp Business Account に設定されているためです。インドには国際認証の料金もあり、インド国外に拠点を置く対象企業に対して、Meta が開始日を定めてから 30 日前の通知を経て適用されます。 ### インドの番号を API に接続しつつ、アプリも使い続けるにはどうすればよいですか？ Tech Provider が運用する、Coexistence オプション付きの Meta の Embedded Signup を使います。企業は Facebook でログインし、Business Portfolio を選択して、WhatsApp Business アプリにすでに登録されている +91 の番号を入力します。その後、アプリに表示される QR コードをスキャンして確認します。アプリのチャット履歴は同期でき、メディアは直近 2 週間分のみ利用できます。 番号は引き続きアプリで使え、毎秒 20 メッセージ固定で Cloud API も利用できるようになります。各画面で求められる内容を含む全手順は、番号の接続のページに掲載しています。 - Sold-To 国がインドなのに、2026 年 12 月 31 日を過ぎても WhatsApp Business Account を USD のままにしておくこと。Meta は、そのメッセージの配信を停止すると表明しています。 - 送信元の国でキャンペーンの費用を見積もること。Meta は受信者の国番号で課金するため、+91 の受信者にはインドの料金がかかります。 - すべてのメッセージテンプレートをユーティリティ扱いにすること。Meta がマーケティングに分類したメッセージテンプレートは、インドではユーティリティ料金の 8 倍以上かかります。 **インドのお客様への返信は無料ですか？** 24 時間のカスタマーサービスウィンドウ内であれば、メッセージテンプレート以外の返信は無料です。WhatsApp Business アプリから入力して送るメッセージも無料です。ウィンドウ外のメッセージテンプレートは課金されます。 **Meta はインドの企業にどの通貨で請求しますか？** Billing Hub の Sold-To 国がインドの企業は INR への移行が進んでおり、すべてのアカウントを 2026 年 12 月 31 日までに INR にする必要があります。Meta はそのための INR 料金表を公開しています。 **自社がインド国外にある場合も、インドの料金を支払いますか？** マーケティングとユーティリティでは、はい。料金は受信者の +91 の国番号で決まるためです。認証は、Meta がお客様の企業に開始日を定めた時点で、国際認証の料金に切り替わることがあります。 **スマートフォンのアプリは引き続き使えますか？** はい。Coexistence では、同じ番号で WhatsApp Business アプリが引き続き使えます。条件は、バージョン 2.24.17 以降であることと、アプリを定期的に開くことです。 --- ## インドネシアでの WhatsApp Coexistence：対応状況、Meta の料金、設定方法 https://easycoexistence.com/ja/docs/whatsapp-coexistence-indonesia インドネシアの番号でも Coexistence を利用できます。WhatsApp Business アプリのユーザー向けに Meta が公開しているオンボーディング資料に、国の制限が設けられていないためです。2026 年 10 月 1 日から、+62 の番号に配信されるマーケティング用のメッセージテンプレート 1 通につき US$ 0.0411（IDR 586.33）、ユーティリティまたは認証用のメッセージテンプレート 1 通につき US$ 0.025（IDR 356.65）を Meta が請求します。カスタマーサービスウィンドウ内の返信は引き続き無料です。 ### インドネシアで WhatsApp Coexistence は利用できますか？ はい。Meta が公開している、WhatsApp Business アプリのユーザーを Cloud API にオンボーディングするためのページでは、アプリのバージョン（2.24.17 以降）とパートナー（Embedded Signup を使う Tech Provider または Solution Partner）に要件がありますが、除外される国や国番号は記載されていません。WhatsApp Business アプリで登録済みかつ有効な +62 の番号は、他の国の番号と同じ条件で対象になります。 実際に障害となるのは一般的なものです。個人向け WhatsApp アプリのままの番号、古いバージョンのアプリ、すでに他社プロバイダーのアプリに接続されている番号などです。対象条件のページで、それぞれの内容と対処法を説明しています。 ### インドネシアでは Meta のメッセージ料金はいくらですか？ Meta は配信されたメッセージテンプレートごとに、受信者の国番号の料金で課金します。+62 の番号に届くメッセージテンプレートはすべてインドネシアの料金が適用され、送信する企業がジャカルタにあっても海外にあっても同じです。 料金は、2026 年 10 月 1 日から適用される Meta の USD と IDR の料金表に基づいています。インドネシアではユーティリティと認証が同じ US$ 0.025 で、マーケティング料金の約 61% です。24 時間の開いたサービスウィンドウ内のフリーテキストの返信は無料で、そのウィンドウ内で送るユーティリティのメッセージテンプレートも無料です。Coexistence の番号で企業が WhatsApp Business アプリから入力して送るメッセージも無料です。 ### インドネシアの企業は請求通貨と認証について何を知っておくべきですか？ IDR は、Meta が料金表を公開している請求通貨の一つで、USD や他の 14 通貨と並んでいます。そのため、インドネシアの企業は換算せずに、Meta の料金表からルピア建ての費用を直接確認できます。 インドネシアは、Meta の認証国際料金の対象国一覧にも含まれています。インドネシア国外に拠点を置く企業が +62 の番号にワンタイムパスコードを送る場合、認証用メッセージテンプレート 1 通あたり US$ 0.136 に移行されることがあり、国内料金の 5 倍以上です。Meta は開始日を企業ごとに設定し、30 日前に通知します。インドネシアのユーザーを認証する海外のアプリは、登録数を増やす前に備えておいてください。 ### アプリを使えなくせずにインドネシアの番号を接続するには？ Meta の Embedded Signup で、既存の WhatsApp Business アプリの番号を使うオプションを選びます。企業は Facebook でサインインし、Business Portfolio を選んで +62 の番号を入力し、アプリに表示される QR コードをスキャンします。完了後 24 時間以内にパートナーが連絡先とチャット履歴の同期を開始する必要があり、そうでない場合は企業が最初からやり直すことになります。 オンボーディング後も携帯電話はこれまでどおり使え、番号は Cloud API でも応答します。両者は 1 秒あたり 20 メッセージの固定スループットを共有します。番号の接続ページで、すべての画面を順に説明しています。 - USD の価格を手作業でルピアに換算すること。Meta は IDR の料金表を公開しており、IDR のアカウントにはその金額が請求されます。 - 海外に拠点を置く企業のワンタイムパスコードを、国内料金で予算化すること。インドネシアには US$ 0.136 の認証国際料金があります。 - QR コードのスキャン後に手順を中断すること。同期は 24 時間以内に開始する必要があり、そうでなければオンボーディングをやり直すことになります。 **インドネシアの料金は、ユーティリティと認証で同じですか？** はい。2026 年 10 月 1 日から適用される Meta の料金表では、どちらも配信されたメッセージテンプレート 1 通につき US$ 0.025（IDR 356.65）です。 **Meta からルピアで請求してもらえますか？** IDR は、Meta が料金ページに掲載している請求通貨の一つで、専用の料金表があります。そのため、ルピアの金額は Meta から直接確認できます。 **接続後、携帯電話から送るメッセージには料金がかかりますか？** いいえ。Meta は、Coexistence のオンボーディング後も WhatsApp Business アプリから送るメッセージは無料のままだと説明しています。Cloud API からの送信だけが Cloud API の料金に従います。 **番号がまだ通常の WhatsApp のままの場合は？** 先に WhatsApp Business アプリへ移行する必要があります。Coexistence は、すでに Business アプリにある番号にのみ提供されます。 --- ## UAE の WhatsApp Coexistence：提供状況、Meta の料金、AED 請求 https://easycoexistence.com/ja/docs/whatsapp-coexistence-uae Coexistence はアラブ首長国連邦の番号でも利用できます。WhatsApp Business アプリ利用者向けの Meta のオンボーディング資料に、国の制限が記載されていないためです。2026 年 10 月 1 日から、+971 番号に配信されるマーケティング用メッセージテンプレート 1 通あたり US$ 0.0576（AED 0.2115）、ユーティリティまたは認証用のメッセージテンプレート 1 通あたり US$ 0.0157（AED 0.0576）が Meta から請求されます。 ### UAE で WhatsApp Coexistence は利用できますか？ はい、利用できます。WhatsApp Business アプリの利用者を Cloud API にオンボーディングするための Meta の資料には、企業とパートナーに必要な条件が挙げられています。主な条件は、アプリのバージョン 2.24.17 以降と、Embedded Signup を使う Tech Provider または Solution Partner です。国、地域、国番号による除外は記載されていません。WhatsApp Business アプリで実際に使用中の +971 番号は対象になります。 UAE の番号が利用できない場合の原因は、他の国の番号と同じです。個人向けの WhatsApp アプリで使っている、アプリが古い、番号が別のプロバイダーに接続されたままになっている、のいずれかです。確実な確認方法は Embedded Signup そのものです。番号が受け付けられるか、受け付けられない理由が表示されます。 ### UAE では Meta はメッセージ 1 通あたりいくら請求しますか？ Meta は配信されたメッセージテンプレートごとに課金し、料金は受信者の国番号で決まります。+971 番号に配信されるメッセージテンプレートは、送信元の企業がどこで登録されていても UAE の料金で請求されます。UAE は「その他の中東」の料金を共用せず、Meta の料金表に独自の行があります。 上記の金額は、2026 年 10 月 1 日から適用される Meta の USD と AED の料金表に基づいています。開いている 24 時間のカスタマーサービスウィンドウ内のフリーテキストの返信は無料です。そのウィンドウ内で送るユーティリティ用メッセージテンプレートも無料です。Coexistence の番号で WhatsApp Business アプリから送るメッセージも引き続き無料です。マーケティング用メッセージテンプレートは、配信されるたびに課金されます。 ### UAE の料金と請求は最近どう変わりましたか？ Meta の料金変更履歴のうち、次の 2 点が直接関係します。2025 年 10 月 1 日に、Meta はアラブ首長国連邦のマーケティングメッセージ料金を引き上げました。2026 年 4 月 1 日には AED を含む 8 つの請求通貨を追加したため、UAE の企業はディルハムで請求を受け、AED の料金表でコストを確認できます。 UAE は、国際認証料金が設定されている Meta の対象市場にも含まれています。UAE 国外に拠点を置く企業が +971 番号にワンタイムパスコードを送る場合、Meta が開始日を設定すると、認証用メッセージテンプレート 1 通あたり US$ 0.051 に切り替わることがあります。開始日は 30 日前に告知されます。 ### UAE の番号を API に接続し、アプリも使い続けるにはどうしますか？ Tech Provider が実行する Meta の Embedded Signup で、既存の WhatsApp Business アプリのオプションを選びます。企業は Facebook でログインし、Business Portfolio を選択して +971 番号を入力し、アプリに表示される QR コードで確認します。同期されるチャット履歴のメディアは、直近 2 週間分のみ利用できます。 接続後も WhatsApp Business アプリはスマートフォンでそのまま使えます。同じ番号で Cloud API を通じた送受信ができ、処理速度は 1 秒あたり 20 メッセージで固定です。番号の接続のページに、各ステップと必要事項をすべて掲載しています。 - UAE を「その他の中東」の料金だと思い込むことです。Meta の料金表には、より高い UAE 独自の行があります。 - USD の料金を手作業でディルハムに換算することです。2026 年 4 月 1 日から、Meta は独自の金額を載せた AED の料金表を公開しています。 - 国外から +971 番号にパスコードを送る際に、国内向けの予算で見積もることです。国際認証料金は 3 倍以上高くなります。 **Meta は UAE の企業にディルハムで請求できますか？** はい。2026 年 4 月 1 日から AED が WhatsApp Business Platform の請求通貨となり、独自の料金表があります。 **UAE とサウジアラビアの料金は同じですか？** マーケティングは同じで、2026 年 10 月 1 日の料金表ではどちらも US$ 0.0576 です。ユーティリティと認証は異なり、UAE は US$ 0.0157、サウジアラビアは US$ 0.0107 です。 **お客様が先にメッセージを送ってきた場合、返信は課金されますか？** 24 時間のカスタマーサービスウィンドウ内のフリーテキストの返信であれば課金されません。ウィンドウ外で送るメッセージテンプレートは課金されます。 **スマートフォンのアプリは使えなくなりますか？** いいえ。Coexistence により、同じ番号で WhatsApp Business アプリを引き続き使えます。アプリから送るメッセージも無料のままです。 --- ## サウジアラビアの WhatsApp Coexistence：利用可否、Meta の料金、SAR 請求 https://easycoexistence.com/ja/docs/whatsapp-coexistence-saudi-arabia サウジアラビアの番号でも Coexistence を利用できます。Meta の WhatsApp Business アプリ利用者向けオンボーディング資料には、国の制限がありません。2026 年 10 月 1 日以降、Meta は +966 の番号に配信されたマーケティングのメッセージテンプレート 1 通につき US$ 0.0576（SAR 0.2159）、ユーティリティまたは認証のメッセージテンプレート 1 通につき US$ 0.0107（SAR 0.0401）を請求します。カスタマーサービスウィンドウ内のフリーテキストでの返信は無料です。 ### サウジアラビアで WhatsApp Coexistence は利用できますか？ はい、利用できます。WhatsApp Business アプリの利用者を Cloud API に移行するための Meta の資料には、アプリのバージョン（2.24.17 以降）と Embedded Signup を実行するパートナーに関する条件はありますが、除外される国、地域、国番号の記載はありません。WhatsApp Business アプリに登録済みで有効な +966 の番号であれば対象になります。 サウジアラビアの番号が拒否される場合、原因は一般的なものです。番号が一般向けの WhatsApp アプリで使われている、アプリが 2.24.17 より古い、番号がまだ別のプロバイダーに紐づいている、のいずれかです。各ケースと対処法は対象条件のページで説明しています。 ### サウジアラビアでは Meta のメッセージ料金はいくらですか？ Meta は、配信された各メッセージテンプレートに、受信者の国番号に基づいて料金を設定しています。+966 の番号に配信されたメッセージテンプレートは、送信元がどこにあっても、サウジアラビアの料金で請求されます。サウジアラビアは料金表に独立した項目があります。 上記の金額は、2026 年 10 月 1 日適用の Meta の USD と SAR の料金表によるものです。24 時間のカスタマーサービスウィンドウが開いている間のフリーテキストでの返信は無料で、そのウィンドウ内で送信したユーティリティのメッセージテンプレートも無料です。Coexistence の番号で WhatsApp Business アプリから送信したメッセージも無料です。マーケティングのメッセージテンプレートは配信ごとに課金されます。大量に送信する場合は、月間の送信量に応じた段階料金により、ユーティリティと認証の料金が下がることがあります。 ### 2026 年にサウジアラビアの企業にどんな変更がありましたか？ Meta の料金変更履歴では、2026 年 4 月 1 日に 2 つの変更がありました。サウジアラビアのマーケティングメッセージ料金が引き上げられ、SAR が新しく追加された 8 つの請求通貨の 1 つになりました。これにより、サウジアラビアの企業はリヤルで請求を受け、ドルから換算せずに SAR の料金表でコストを確認できます。 サウジアラビアは、認証（国際）料金が設定されている市場の 1 つでもあります。国外に拠点を置く企業が +966 の番号にワンタイムパスコードを送信する場合、認証のメッセージテンプレート 1 通あたり US$ 0.0598 に移行されることがあります。これは国内料金の 5 倍以上です。適用開始日は Meta が企業ごとに決定し、適用の 30 日前に通知します。 ### サウジアラビアの番号を接続しながらアプリを使い続けるには？ Meta の Embedded Signup で、WhatsApp Business アプリにある既存の番号用のオプションを選びます。フローは Tech Provider が提供します。企業は Facebook でログインし、Business Portfolio を選択して +966 の番号を入力し、アプリに表示される QR コードをスキャンします。その後、パートナーが同期を開始できる期間は 24 時間です。この期間を過ぎた場合は、フローをやり直す必要があります。 以降も携帯電話はこれまでどおり使え、同じ番号で Cloud API 経由の送受信も行えます。送信は毎秒 20 メッセージで固定です。各手順は番号の接続ページで説明しています。 - 2026 年 4 月 1 日より前の料金でサウジアラビア向けのマーケティング配信を予算化すること。Meta は同日にマーケティング料金を引き上げました。 - USD の料金表から通貨換算ツールで SAR のコストを算出すること。Meta は独自の SAR 料金を公開しています。 - 国外の企業から +966 の番号へのパスコード送信を国内料金で見積もること。認証（国際）料金は US$ 0.0598 です。 **サウジアラビアの企業はリヤルで請求を受けられますか？** はい。Meta は 2026 年 4 月 1 日に請求通貨として SAR を追加し、SAR の料金表を公開しています。 **サウジアラビアは「その他の中東」の料金で計算されますか？** いいえ。Meta の料金表に独立した項目があり、マーケティングは US$ 0.0576、ユーティリティと認証は US$ 0.0107 です。 **アプリで入力して送るメッセージにも料金はかかりますか？** いいえ。Meta は、Coexistence のオンボーディング後も WhatsApp Business アプリから送信するメッセージは無料のままだと明示しています。 **必要なアプリのバージョンは？** +966 の番号を登録した携帯電話で、WhatsApp Business アプリ 2.24.17 以降が必要です。 --- ## トルコでの WhatsApp Coexistence：利用可否、Meta の料金、設定方法 https://easycoexistence.com/ja/docs/whatsapp-coexistence-turkey トルコの番号でも Coexistence を利用できます。Meta の WhatsApp Business アプリ利用者向けオンボーディング資料に、国の制限は記載されていません。2026 年 10 月 1 日から、Meta は +90 の番号に配信されるマーケティングテンプレート 1 通につき US$ 0.0109、ユーティリティまたは認証テンプレート 1 通につき US$ 0.0009 を請求します。Meta は 2026 年 4 月 1 日にトルコのユーティリティと認証の料金を引き下げており、トルコリラの料金表は公開していません。 ### トルコで WhatsApp Coexistence は利用できますか？ はい、利用できます。Meta が公開している、WhatsApp Business アプリの利用者を Cloud API へ移行するためのページでは、アプリのバージョン（2.24.17 以降）とパートナー（セッションログを有効にした Embedded Signup を使う Tech Provider または Solution Partner）に要件が定められていますが、国や国番号による除外はありません。WhatsApp Business アプリで利用中の +90 の番号は対象です。 トルコの番号が利用できないのは、他の国の番号と同じ理由に限られます。一般向けの WhatsApp アプリで使っている、アプリの更新が必要、別のプロバイダーがまだその番号を保持している、のいずれかです。どれも端末側か以前のプロバイダー側で解消でき、対処法は対象要件のページに載っています。 ### トルコでの Meta のメッセージ料金はいくらですか？ Meta は、配信されたテンプレートごとに、受信者の国番号に応じた料金を請求します。そのため、送信元がどこであっても、+90 の番号に届くテンプレートはすべてトルコの料金で計算されます。トルコは料金表に独立した行があります。 2026 年 10 月 1 日から適用される Meta の USD 料金表では、トルコは表の中でも最も安い水準です。マーケティングは US$ 0.0109、ユーティリティと認証は US$ 0.0009 です。EUR の料金表では €0.009 と €0.0007 です。トルコには認証インターナショナルの料金は設定されていません。24 時間のカスタマーサービスウィンドウ内のフリーテキストの返信は無料で、そのウィンドウ内に送るユーティリティテンプレートも無料です。Coexistence の番号で WhatsApp Business アプリから送るメッセージも引き続き無料です。 ### トルコの企業は Meta から何の通貨で請求されますか？ Meta は WhatsApp Business Platform の料金表を 16 の通貨で公開しています。USD、AED、ARS、AUD、BRL、CLP、COP、EUR、GBP、IDR、INR、MXN、MYR、PEN、SAR、SGD です。トルコリラは含まれていないため、トルコの企業は USD や EUR など、これらのいずれかの通貨で請求されます。費用は換算せず、その通貨の料金表の数字で確認してください。 最も重要な料金改定は最近のものです。Meta は 2026 年 4 月 1 日にトルコのユーティリティと認証の料金を引き下げました。これにより、+90 の番号への注文通知やワンタイムパスコードは、1 通あたり 1 セントの何分の一かになります。この日より前に作った予算は、これらの費用を過大に見積もっています。 ### トルコの番号を接続しつつ、アプリを使い続けるにはどうしますか？ Meta の Embedded Signup で、すでに WhatsApp Business アプリで使っている番号向けのオプションを選びます。ホストするのは Tech Provider です。企業は Facebook でログインし、Business Portfolio を選び、+90 の番号を入力して、アプリで QR コードをスキャンして確認します。同期は 24 時間以内に開始する必要があり、過ぎた場合はフローをやり直します。 接続後も端末は変わらず使え、同じ番号で Cloud API を毎秒 20 メッセージの固定レートで利用できるようになります。手順は番号の接続のページで画面ごとに説明しています。 - トルコリラの料金表を探すこと。Meta は公開していません。アカウントの請求通貨である USD または EUR の料金表を確認してください。 - 2026 年 4 月 1 日より前に作った予算を使うこと。Meta はその日にトルコのユーティリティと認証の料金を引き下げました。 - 費用を抑えるために、プロモーションをユーティリティに分類すること。Meta はテンプレートのカテゴリを審査し、マーケティングテンプレートにはマーケティングの料金が課されます。 **トルコには認証インターナショナルの料金はありますか？** いいえ。2026 年 10 月 1 日から適用される Meta の料金表では、トルコは対象外とされています。 **Meta からトルコリラで請求してもらえますか？** いいえ。Meta が料金表を公開している 16 の請求通貨に、トルコリラは含まれていません。 **トルコのお客様への返信は無料ですか？** 24 時間のカスタマーサービスウィンドウ内のフリーテキストの返信は無料です。ウィンドウ外のテンプレートは、配信ごとに課金されます。 **API を接続すると、アプリは使えなくなりますか？** いいえ。Coexistence では、同じ番号で WhatsApp Business アプリを引き続き使え、アプリから送るメッセージも無料のままです。 --- ## ドイツでの WhatsApp Coexistence：提供状況、Meta の料金、設定方法 https://easycoexistence.com/ja/docs/whatsapp-coexistence-germany ドイツの電話番号でも Coexistence を利用できます。WhatsApp Business アプリのユーザー向け Meta のオンボーディング資料には、国や EU に関する制限の記載がありません。2026 年 10 月 1 日から、+49 の番号に配信されるマーケティング用メッセージテンプレートは 1 通あたり US$ 0.1365（€0.1131）、ユーティリティまたは認証用メッセージテンプレートは 1 通あたり US$ 0.055（€0.0456）が Meta から請求されます。カスタマーサービスウィンドウ内のフリーテキストでの返信は無料です。 ### ドイツでは WhatsApp Coexistence を利用できますか？ はい、利用できます。WhatsApp Business アプリのユーザーを Cloud API へオンボーディングするための Meta の資料では、アプリのバージョン（2.24.17 以降）と Embedded Signup を実行するパートナーに条件が定められていますが、国、地域、国番号による制限は記載されていません。欧州連合に固有の条件もありません。WhatsApp Business アプリに登録済みで有効な +49 の番号は、対象となります。 Embedded Signup でドイツの番号が受け付けられない場合、原因は一般的なもののいずれかです。番号がまだ個人向けの WhatsApp アプリで使われている、アプリが 2.24.17 より古い、または別のプロバイダーがその番号をまだ保持している、というケースです。それぞれの対処は対象要件のページで説明しています。 ### ドイツでは Meta はメッセージごとにいくら請求しますか？ Meta は、配信されたメッセージテンプレートごとに、受信者の国番号に応じた料金を請求します。+49 の番号に配信されたメッセージテンプレートには、送信する企業がベルリン、ウィーン、その他どこにあっても、ドイツの料金が適用されます。 ドイツは Meta の料金表に独自の区分があり、その他の西ヨーロッパの区分を大きく上回ります。マーケティングは US$ 0.1365 に対して US$ 0.0592、ユーティリティは US$ 0.055 に対して US$ 0.0171 です。Meta はドイツ向けの国際認証料金を掲載していません。24 時間のカスタマーサービスウィンドウが開いている間のフリーテキストでの返信は無料で、その間に送るユーティリティ用メッセージテンプレートも無料です。Coexistence の番号で WhatsApp Business アプリから入力して送ったメッセージも無料のままです。 ### ドイツの料金は、API の使い方にどう影響しますか？ +49 の番号へのマーケティング用メッセージテンプレートは 1 ドルの 13 セント超、ユーティリティ用は 5.5 セントかかります。そのため、ドイツで最も安いメッセージは、Meta が一切課金しないメッセージです。 つまり、カスタマーサービスウィンドウが最大のコスト調整手段になります。連絡をくれた相手に 24 時間以内に返信するワークフローは、メッセージごとの料金が発生しません。このウィンドウが開いている間に送るユーティリティ用メッセージテンプレートも無料です。料金が積み上がるのは、メッセージテンプレートでやり取りを始めるアウトリーチです。Coexistence の番号では、スタッフが WhatsApp Business アプリで端末から入力したメッセージも無料なので、API は自動送信用に取っておけます。 ### ドイツの番号を接続しつつ、アプリを使い続けるにはどうしますか？ Meta の Embedded Signup で、すでに WhatsApp Business アプリにある番号向けのオプションを使います。Tech Provider がフローを提供し、企業は Facebook でログインして Business Portfolio を選択し、+49 の番号を入力して、アプリに表示される QR コードで確認します。同期は完了から 24 時間以内に開始する必要があり、そうでない場合はフローをやり直します。 その後も端末はそのまま使え、同じ番号が Cloud API 経由で毎秒 20 メッセージの固定速度で送受信します。各画面の内容は、番号の接続のページで説明しています。 - ドイツの受信者をその他の西ヨーロッパの料金で見積もってしまう。ドイツには独自の区分があり、マーケティングは 2 倍以上です。 - 24 時間ウィンドウ内の返信で足りる場面で、メッセージテンプレートからやり取りを始めてしまう。ドイツでは無料と有料の差が大きくなります。 - 料金を抑えるためにプロモーションをユーティリティに分類してしまう。Meta はメッセージテンプレートのカテゴリーを審査し、マーケティングにはマーケティング料金を請求します。 **Meta はドイツの企業にユーロで請求できますか？** はい。EUR は Meta が料金表を公開している請求通貨の一つで、2026 年 10 月 1 日の料金表では、ドイツのマーケティングは €0.1131 です。 **EU では Coexistence に追加の条件がありますか？** WhatsApp Business アプリのユーザー向けの Meta の現行のオンボーディング資料には、記載がありません。要件はどこでも同じで、アプリ 2.24.17 以降と、Embedded Signup のパートナーです。 **ドイツのお客様への返信には課金されますか？** 24 時間のカスタマーサービスウィンドウ内のフリーテキストでの返信には、課金されません。ウィンドウ外のメッセージテンプレートは、配信ごとに課金されます。 **端末からのメッセージは引き続き無料ですか？** はい。Meta は、オンボーディング後も WhatsApp Business アプリから送信したメッセージは無料のままだと明記しています。Cloud API からの送信だけが Cloud API の料金に従います。 --- ## イタリアでの WhatsApp Coexistence：対応状況、Meta の料金、設定方法 https://easycoexistence.com/ja/docs/whatsapp-coexistence-italy イタリアの番号でも Coexistence を利用できます。WhatsApp Business アプリ利用者向けの Meta のオンボーディング資料に、国や EU に関する制限の記載がないためです。2026 年 10 月 1 日から、+39 の番号に配信されるマーケティングのメッセージテンプレートには 1 通あたり US$ 0.0795（€0.0658）、ユーティリティまたは認証のメッセージテンプレートには US$ 0.03（€0.0248）が Meta から請求されます。Meta は 2026 年 7 月 1 日にイタリアのマーケティング料金を引き上げました。 ### イタリアで WhatsApp Coexistence は利用できますか？ はい、利用できます。WhatsApp Business アプリのユーザーを Cloud API にオンボーディングするための Meta の資料には、必要条件として主にアプリのバージョン 2.24.17 以降と、Embedded Signup を使用する Tech Provider または Solution Partner が挙げられています。国、地域、国番号による除外はありません。欧州連合の番号に条件を追加する記載もありません。WhatsApp Business アプリで現在使用中の +39 の番号は対象になります。 イタリアの番号が断られるのは、一般的な理由に限られます。個人向けの WhatsApp アプリで使われている、アプリの更新が必要、または別のプロバイダーがまだその番号を保持している場合です。それぞれの内容と解消方法は、対象条件のページで説明しています。 ### イタリアでは Meta のメッセージ料金はいくらですか？ Meta は、配信されたメッセージテンプレートごとに、受信者の国番号に応じた料金で請求します。そのため、+39 の番号に届くメッセージテンプレートは、企業の登録国にかかわらずイタリアの料金が適用されます。イタリアは「西ヨーロッパその他」の料金ではなく、料金表に独自の行があります。 以下の数値は、2026 年 10 月 1 日適用の Meta の USD 料金表と EUR 料金表によるものです。Meta はイタリアについて、国際認証の料金を掲載していません。開いている 24 時間のカスタマーサービスウィンドウ内のフリーテキストの返信は無料で、そのウィンドウ内に送るユーティリティのメッセージテンプレートも無料です。Coexistence の番号で WhatsApp Business アプリから送信したメッセージには料金がかかりません。 ### 2026 年にイタリアの料金で何が変わりましたか？ Meta の料金変更履歴によると、今年のイタリアの変更は 1 件で、2026 年 7 月 1 日からマーケティングメッセージの料金が引き上げられました。この更新ではスペイン、ポーランド、ハンガリー、ルーマニア、英国などの料金も変更されています。ユーティリティと認証は変更の対象ではありません。 実務上の影響はキャンペーンに出ます。2026 年 7 月より前に作成した、+39 の番号向けのプロモーション用メッセージテンプレートの予算は、コストを低く見積もっています。一方、注文確認、配送状況の通知、ワンタイムパスコードの料金は従来どおりです。EUR は Meta が料金表を公開している通貨の一つなので、ユーロでの請求に換算は不要で、マーケティングの €0.0658 は Meta 自身の数値です。 ### イタリアの番号を接続しつつ、アプリも使い続けるにはどうすればよいですか？ Meta の Embedded Signup で、WhatsApp Business アプリにすでに登録されている番号を選ぶオプションを使います。フローは Tech Provider が提供します。企業は Facebook でサインインし、Business Portfolio を選択して +39 の番号を入力し、アプリに表示される QR コードをスキャンします。同期されるチャット履歴のメディアは、直近 2 週間分のみです。 オンボーディング後も携帯電話はそのまま使え、同じ番号が Cloud API でも毎秒 20 メッセージの固定レートで送受信できます。各手順は「番号の接続」のページで説明しています。 - 2026 年 7 月 1 日より前に作成した、+39 の受信者向けのマーケティング予算をそのまま使うこと。Meta はその日にイタリアのマーケティング料金を引き上げました。 - イタリアの番号に「西ヨーロッパその他」の料金を適用すること。Meta の料金表では、イタリアに独自の行があります。 - 個人向けの WhatsApp アプリにある番号でオンボーディングを始めること。先に WhatsApp Business アプリへ移行する必要があります。 **Meta はイタリアの企業にユーロで請求できますか？** はい。EUR は Meta の請求通貨の一つで、EUR 料金表ではイタリアはマーケティングが €0.0658、ユーティリティと認証が €0.0248 です。 **2026 年にイタリアのユーティリティの料金は変わりましたか？** いいえ。2026 年 7 月 1 日の更新で引き上げられたのは、イタリアのマーケティング料金のみです。 **イタリアのお客様への返信には料金がかかりますか？** 24 時間のカスタマーサービスウィンドウ内のフリーテキストの返信は無料です。ウィンドウ外で送るメッセージテンプレートは、配信時に課金されます。 **スタッフは引き続きアプリを使えますか？** はい。Coexistence により、同じ番号で WhatsApp Business アプリがそのまま使え、アプリから送信したメッセージは無料のままです。 --- ## Coexistence を解除して WhatsApp Business アプリのみに戻す方法 https://easycoexistence.com/ja/docs/disconnecting-coexistence Coexistence の解除は WhatsApp Business アプリ自体から行います。「設定」、「アカウント」、「Business Platform」の順に開き、「アカウントの接続を解除」を選びます。アプリはその番号で引き続き使え、プロバイダーのアクセスは終了し、PARTNER_REMOVED を含む account_update Webhook が送信されます。両方で使用中の番号には、Cloud API の Deregister エンドポイントは使えません。 ### Coexistence を解除するには？ 番号を保持している端末から行います。番号が WhatsApp Business アプリと共有されている場合、企業が Cloud API から離れる方法として Meta が案内しているのは 1 つだけで、ダッシュボードやエンドポイントではなくアプリを通じて行います。判断するのはメインの端末を持つ人なので、代理店や開発者は企業側に操作を依頼することになります。 - メインの端末で WhatsApp Business アプリを開きます。 - 「設定」、「アカウント」、「Business Platform」の順に進みます。 - 「アカウントの接続を解除」をタップして確定します。 - API 側では、PARTNER_REMOVED イベントを含む account_update Webhook が届きます。 ### なぜ Deregister API は番号を拒否するのですか？ Meta が Coexistence の番号を意図的に対象外としているためです。登録に関するドキュメントには、Cloud API と WhatsApp Business アプリの両方で使用中の企業の電話番号は、Deregister エンドポイントで登録解除できないと明記されています。 登録解除とは、番号を Cloud API で使えなくする操作です。API 専用の番号であれば、これで回線をプラットフォームから外せます。しかし共有されている番号では、アプリが回線の主たる所有者です。そのため Meta は、判断を番号を持つ人に戻しています。ソフトウェアがこのエンドポイントを先に試すと、接続解除ではなくエラーが返り、アプリでボタンがタップされるまで番号は接続されたままです。 ### アプリ、履歴、番号はどうなりますか？ 接続の解除はアカウントの削除とは異なります。この違いが答えのすべてです。 メッセージ履歴が失われるという Meta の警告は、WhatsApp Business アプリのアカウントを削除して、その番号を Cloud API に登録する場合のものです。接続の解除ではどちらも行いません。アプリはインストールされ登録されたままで、番号もそのままです。チームは同じ端末で引き続きお客様に対応できます。 終了するのは API 側です。プロバイダーのアプリが番号から削除されるため、Cloud API 経由の送信と、その番号への Webhook 配信が止まります。Coexistence で無効になっていた機能（たとえば一斉送信リスト）については、無効になる機能のページで説明しています。 ### 後から同じ番号を再接続できますか？ はい。オンボーディングの流れを最初からやり直します。Meta 自身のドキュメントでも、オフボーディングして流れをもう一度完了することが、接続をリセットする通常の方法とされています。たとえば、連絡先と履歴を同期できる 24 時間の期限を過ぎた場合です。 再接続は新規のオンボーディングなので、チャット履歴を共有するかどうかなど、初回と同じ質問が再び表示されます。以前の接続で設定していた内容（Webhook の上書きなど）は、もう一度設定する必要があります。別のプロバイダーに移す場合も同じ手順です。ここで接続を解除し、新しいプロバイダーでオンボーディングします。 - Coexistence の番号に Deregister エンドポイントを呼び出す。Meta は拒否します。接続の解除はアプリで行います。 - 抜けるために WhatsApp Business アプリのアカウントを削除する。これがチャット履歴を失う方法です。 - PARTNER_REMOVED を障害とみなして再試行する。これは企業が意図的に行った接続の解除です。 **接続を解除するとチャットは消えますか？** いいえ。接続の解除は番号から API を外すだけで、WhatsApp Business アプリのアカウントは削除されません。Meta が履歴を失うと警告しているのは、アカウントの削除です。 **API から接続を解除できますか？** いいえ。Cloud API とアプリの両方で使用中の番号には、Meta は Deregister エンドポイントを許可していません。 **解除されたことをシステムはどう知りますか？** 企業が接続を解除すると、Meta が PARTNER_REMOVED イベントを含む account_update Webhook を送信します。 **同じ番号を再接続できますか？** はい。初回の接続と同じように、オンボーディングの流れを最初からやり直してください。 --- ## 番号を Coexistence から Cloud API のみへ移行する https://easycoexistence.com/ja/docs/moving-from-coexistence-to-cloud-api Coexistence の番号を API のみにするには、WhatsApp Business アプリで接続を解除し、アプリのアカウントを削除したうえで、2 段階認証の PIN を使って Cloud API に番号を登録します。Meta は既存のメッセージ履歴が失われると警告しています。また、Cloud API から登録解除しない限り、その番号をアプリに戻すことはできません。 ### なぜアプリをやめるのですか？ 多くの場合、スマートフォンから返信する人がいなくなったためです。すべての会話をソフトウェアや API 上の受信トレイで処理するようになると、アプリは負担を増やすだけで何も生みません。メイン端末を定期的に開く必要があり、番号も Coexistence の固定スループットのままになります。 Meta の資料によると、アプリと Cloud API の両方で使う番号のスループットは毎秒 20 メッセージで固定です。API のみの番号は、既定で最大毎秒 80 メッセージから始まり、Meta の条件を満たすと自動的に 1,000 まで引き上げられます。大量に送信する番号にとっては、この差が移行する理由になります。 ### 手順はどのような順番ですか？ 手順は 4 つあり、順番が重要です。Deregister エンドポイントは、アプリと共有されたままの番号を拒否するためです。最後の手順を除き、各手順は企業側がスマートフォン上で行います。最後の手順は、今後その番号を運用する担当者が行う API 呼び出しです。 - Meta の推奨どおり、WhatsApp Business アプリでチャット履歴をバックアップします。 - アプリで接続を解除します。「設定」「アカウント」「ビジネスプラットフォーム」の順に進み、アカウントの接続を解除します。 - アプリのアカウントを削除します。「設定」「アカウント」「アカウントを削除」の順に進み、最大 3 分待ちます。 - 6 桁の 2 段階認証の PIN を使って、Cloud API に番号を登録します。 ### 企業は何を手放すことになりますか？ スマートフォン上の会話と、スマートフォンから返信する手段です。 Meta は、WhatsApp Business アプリのアカウントを削除して Cloud API に番号を登録すると、既存のメッセージ履歴が失われると明記しています。履歴が保持され、両方のアプリが同時に動作する Coexistence のオンボーディングとは逆の動きです。 また、先に Cloud API から登録解除しない限り、その番号を WhatsApp Business アプリで再び使うことはできません。つまりこれは、業務の進め方を意図的に変える、後戻りできない変更です。開始前に、チームの誰もアプリに頼っていないことを確認してください。 ### API 側で変わらないことは何ですか？ ソフトウェアが番号とやり取りする方法です。引き続き Cloud API であり、メッセージの種類、メッセージテンプレート、Webhook、料金体系は同じです。Coexistence は、同じプラットフォームへの別のオンボーディング方法にすぎないためです。 変わるのは登録方法です。Coexistence の番号はオンボーディングのフローで登録されますが、API のみの番号は 2 段階認証の PIN を添えた register 呼び出しで登録します。Meta はこの呼び出しを、72 時間の移動ウィンドウ内で番号あたり 10 回に制限しています。失敗すると回数を消費するため、再試行の前に PIN を確認してください。 - チャットをバックアップする前にアプリのアカウントを削除する。この方法では履歴が失われると Meta は明記しています。 - 番号がアプリと共有されたままの状態で Deregister を呼び出す。Meta はこれを拒否します。 - ループで登録を再試行する。Meta が許可する register リクエストは、番号あたり 72 時間で 10 回です。 **API のみに移行しても、チャット履歴は残せますか？** API では残せません。Meta は履歴が失われると警告しており、先にアプリからバックアップするよう推奨しています。 **その番号を後からアプリに戻せますか？** Meta の移行ガイドによると、Cloud API から登録解除した後にのみ戻せます。 **スループットは向上しますか？** はい。Coexistence の番号は 20 mps で固定ですが、API のみの番号は最大 80 mps から始まります。 **Deregister API から始めてもよいですか？** 番号がアプリと共有されている間はできません。先に WhatsApp Business アプリで接続を解除してください。 --- ## 別の WhatsApp プロバイダーから番号を移行する https://easycoexistence.com/ja/docs/migrating-a-number-from-another-provider 現在の番号の接続方法によって異なります。他社プロバイダー経由で WhatsApp Business アプリと共有している番号は、アプリ内で接続を解除してから、新しいプロバイダーで改めてオンボーディングします。API のみの番号は Meta の電話番号移行を使い、表示名、品質評価、メッセージ送信上限、公式ビジネスアカウントの状態が維持されます。 ### 自分はどちらのケースですか？ 確認するのは 1 点だけです。この番号に、今もスマートフォンの WhatsApp Business アプリから返信している人はいますか？ いる場合、その番号は現在のプロバイダーと Coexistence で接続されており、番号を保持しているのはアプリです。そのプロバイダーから離れる操作はアプリ内で行い、新しいプロバイダーへの接続は新規の Coexistence オンボーディングになります。 いない場合、その番号は Cloud API だけに登録されており、背後にアプリはありません。この場合は Meta に別の移行手順があり、番号を一から登録し直すことなく、あるパートナーの WhatsApp Business アカウントから別のパートナーのものへ移せます。この 2 つを取り違えることが、移行が途中で止まる典型的な原因です。 ### Coexistence の番号はどうやってプロバイダーを変更しますか？ 接続を解除し、あらためてオンボーディングします。Meta のドキュメントによると、企業はアプリの「設定」、アカウント、ビジネスプラットフォームの順に開き、接続解除のボタンで Cloud API との接続を解除します。このとき、プロバイダーには PARTNER_REMOVED を含む account_update の Webhook が届きます。 接続を解除すると、その番号は再び WhatsApp Business アプリだけの番号になり、新しいプロバイダーが Embedded Signup でオンボーディングできます。条件は通常の Coexistence と同じです。最近のバージョンのアプリ、自分が管理者である Business Portfolio、他のプロバイダーが接続されていないことが必要です。履歴を共有するかどうかの確認も再度行われ、24 時間の同期期間も新しいオンボーディングから改めて始まります。 ### API のみの移行では何が引き継がれますか？ 多くの方が想像するより多くの項目が引き継がれます。削除して登録し直すのではなく、この移行手順が用意されているのはそのためです。顧客との間で築いた番号の評価は維持され、やり直しになるのはテンプレートの品質履歴だけです。 - 表示名、品質評価、メッセージ送信上限、公式ビジネスアカウントの状態は維持されます。 - 対象のテンプレートは、同じステータスのまま移行先のアカウントに複製されます。 - 番号にすでにアップロードされているメディアは、引き続き使用できます。 - テンプレートの品質評価は引き継がれません。移行されたテンプレートはすべて UNKNOWN から始まります。 ### API のみの移行の前に何を準備しますか？ Meta は双方に条件を定めていますが、移行が止まりやすいのは企業側の条件です。 企業の Meta の Business Portfolio が認証済みで、既存の WhatsApp Business アカウントが承認済みであり、有効な支払い方法が登録されている必要があります。番号の 2 段階認証は無効にしておく必要がありますが、Meta には無効にするための API エンドポイントがないため、プロバイダーが API でこの手順を代行することはできません。受け取る側では、移行先のアカウントで、少なくとも 1 つのアプリが Webhook を購読している必要があります。 新しいアカウントへの登録は即時で、メッセージ送信が中断されることもありません。ただしテンプレートの複製には時間がかかるため、複製が完了するまで、対象のテンプレートは使用できません。 - 古いプロバイダーが接続されたまま、新しいプロバイダーでオンボーディングを始めてしまう。先にアプリで番号の接続を解除する必要があります。 - 2 段階認証を有効にしたまま API のみの移行を始めてしまう。Meta は無効化を必須としており、それを行うエンドポイントはありません。 - テンプレートの品質評価が残ると思い込んでいる。移行されたテンプレートは UNKNOWN から再スタートします。 **Coexistence のプロバイダーを変更すると、チャットは失われますか？** アプリには、チャットがそのまま残ります。新しい接続への履歴の共有は、オンボーディングの際にあらためて選択できます。 **API のみの移行で、表示名は変わりますか？** いいえ。Meta は表示名、品質評価、メッセージ送信上限、公式ビジネスアカウントの状態を維持します。 **なぜテンプレートの品質評価がなくなったのですか？** Meta はテンプレートを移行先のアカウントに複製し、複製されたものはすべて UNKNOWN の評価から始まるためです。 **ダウンタイムはありますか？** Meta によると、API のみの移行での登録は即時で、メッセージ送信は中断されません。テンプレートは複製が完了すれば使用できます。 --- ## Coexistence の番号での WhatsApp グループと API https://easycoexistence.com/ja/docs/whatsapp-groups-and-the-api Meta の Groups API を使うと、Cloud API の番号で少人数の招待制グループを作成し、メッセージを送れます。ただし Meta は、WhatsApp Business アプリの電話番号では利用できないと明記しており、Coexistence の番号はこれに該当します。アプリにある既存のグループも同期されません。共有している番号では、グループはアプリ専用の機能のままです。 ### WhatsApp には Groups API がありますか？ はい、あります。Meta の Groups API を使うと、企業は Cloud API の番号でグループの作成、一覧取得、更新を行い、テキスト、メディア、メッセージテンプレートをグループに送信できます。招待リンクの管理、参加リクエストの承認と拒否、参加者の削除にも対応しています。 機能はあえて小さく作られています。グループは招待制で、企業が送るリンクから参加します。Meta の上限を見ると、コミュニティというよりプロジェクトルームに近い規模です。 - 1 グループあたり最大 8 人まで参加できます。 - 1 つの企業の番号につき最大 10,000 グループまで作成できます。 - 1 グループにつき Cloud API の企業は 1 社です。 - テキスト、メディア、テキスト形式のメッセージテンプレート、メディア形式のメッセージテンプレートを送れます。 ### Coexistence の番号でも使えますか？ いいえ、使えません。Groups API のページには、WhatsApp Business アプリの電話番号では利用できないと記載されています。この表現は、WhatsApp Business アプリのユーザーをオンボーディングするための Meta 自身のガイドにリンクしており、それがまさに Coexistence です。また利用条件は公式ビジネスアカウントであることですが、Meta の公式ビジネスアカウントのページによれば、WhatsApp Business アプリの電話番号にはこのステータスが付与されません。 つまりこの除外は、すべてのプロバイダーに対して Meta が定めたものです。アプリと API で共有している番号では、API からグループを作成することも、グループに送信することもできず、グループのイベントも届きません。 ### アプリにある既存のグループはどうなりますか？ アプリに残り、これまでどおり使えます。Meta の Coexistence のドキュメントでは、番号のオンボーディング時に同期されないものとしてグループチャットが挙げられています。そのため、履歴も新しいグループメッセージも API には届きません。 スマートフォンを使うチームは、これまでと同じようにグループを作成し、投稿し、読めます。ソフトウェアからはそのやり取りが見えないだけです。スタッフ同士の配送の調整など、グループに依存する業務はアプリ内で続けられます。その周辺の自動化は、1 対 1 の会話をもとに組み立てる必要があります。 ### API 経由のグループの代わりに何を使えばよいですか？ 1 対 1 の会話です。このプラットフォームはそれを前提に作られています。グループ宛てに送るはずだったメッセージは、お客様一人ひとりに個別に送ります。24 時間のカスタマーサービスウィンドウ内ならフリーテキストで、ウィンドウ外なら承認済みのメッセージテンプレートで送信します。 API で管理するグループがどうしても必要な場合、Groups API には、Cloud API のみに登録され、公式ビジネスアカウントを持つ番号が必要です。つまりその番号は Coexistence をやめることになります。これは回線の構成に関わる判断であり、設定では切り替えられません。そして回線からアプリがなくなります。 - Groups API が存在すると知って、Coexistence の番号にも使えると思い込むこと。Meta は WhatsApp Business アプリの番号を除外しています。 - オンボーディング後にグループの履歴が API に表示されると期待すること。グループチャットは同期されません。 - 参加者 8 人という上限に合うかを確かめないまま、グループ前提の業務フローを計画すること。 **API から WhatsApp グループにメッセージを送れますか？** 公式ビジネスアカウントを持つ API 専用の番号から、Groups API を使う場合のみ可能です。Coexistence の番号からは送れません。 **既存のグループは引き続き使えますか？** はい、WhatsApp Business アプリで使えます。API には同期されません。 **API のグループには何人まで参加できますか？** Meta は、Groups API で作成するグループの上限を参加者 8 人としています。 **これは利用しているプロバイダーの制限ですか？** いいえ。WhatsApp Business アプリの番号を除外しているのは Meta で、どのプロバイダーでも同じです。 --- ## Meta Verified と Coexistence 番号の公式ビジネスバッジ https://easycoexistence.com/ja/docs/meta-verified-and-coexistence 青いバッジと呼ばれるものは 2 種類あります。Official Business Account は Cloud API の番号に対して申請するステータスで、Meta のドキュメントでは WhatsApp Business アプリの電話番号には付与されないと説明されています。WhatsApp Business 向けの Meta Verified は、アプリ内で申し込むサブスクリプションで、認証バッジ、複数担当者でのアクセス、強化されたサポートが含まれます。 ### Official Business Account とは何ですか？ WhatsApp Business Platform に登録された企業の電話番号に付くステータスです。Meta は、本物であると認証された企業が所有する番号で、連絡先の表示で名前の横に青いチェックマークが付くものと説明しています。申請は WhatsApp Manager の番号のプロフィールから、または API の official_business_account フィールドで行います。 - 企業が WhatsApp Business メッセージングポリシーを遵守していること。 - プラットフォームに 30 日以上登録されていること。 - Business Portfolio が Business Verification に通過していること。 - 番号で 2 段階認証が有効になっており、表示名が承認済みであること。 ### Coexistence の番号は OBA ステータスを取得できますか？ Meta の OBA ドキュメントには、企業の従業員、テストアカウント、WhatsApp Business アプリの電話番号には OBA ステータスを付与しないと記載されています。Meta は Groups API のページでも同じ「WhatsApp Business アプリの電話番号」という表現を使い、WhatsApp Business アプリのユーザーをオンボーディングするガイド、つまり Coexistence へのリンクを示しています。 アプリと API で共有する番号について、Meta は別個のルールを公開していません。そのため、文書上の立場は上記のとおりです。却下された申請は 30 日後に再申請でき、その間もビジネスプロフィールは編集できます。 ### WhatsApp Business 向けの Meta Verified とは何ですか？ WhatsApp Business アプリから申し込む有料のサブスクリプションで、プラットフォームの OBA の手続きとは別のものです。Meta のリソースページには、認証バッジ、カスタムウェブページ、強化されたサポート、複数のデバイスを接続しチャットを営業担当者に割り当てられるマルチエージェントアカウント、最大 10 件の WhatsApp チャンネルの認証バッジが含まれると記載されています。 アプリ内で購入するため、Coexistence の番号ではアプリ側に属します。Meta のページは、申し込む前にビジネス情報とアカウント情報を最新にしておくよう求めており、そこでは固定の料金は公開されていません。 ### 番号を移行してもバッジは維持されますか？ OBA については、Meta が明示している事例が 1 つあります。Embedded Signup を通じて Solution Partner 間で移行した電話番号は、表示名、品質評価、メッセージ送信上限、Official Business Account ステータスを引き継ぎます。 番号そのものを変更する場合に同等の記載はなく、OBA は特定の企業の電話番号に紐づくため、別の番号は別の申請になります。表示名の承認は OBA の条件の 1 つです。名称変更は、申請の後ではなく前に計画しておくことをおすすめします。 - OBA と Meta Verified を 1 つのバッジとして扱うこと。一方はプラットフォームのステータス、もう一方はアプリのサブスクリプションです。 - プラットフォームでの登録が 30 日に満たないうちに OBA を申請すること。Meta はこの最低期間を求めており、却下されると 30 日待つことになります。 - 2 段階認証がオフ、または表示名が審査中の状態で OBA を申請すること。どちらも条件に挙げられています。 **Meta Verified は Official Business Account と同じものですか？** いいえ。Meta は両者を別々に説明しています。OBA はプラットフォームの番号に対して申請するステータス、Meta Verified はアプリ内で申し込むサブスクリプションです。 **Coexistence の番号でも Meta Verified に申し込めますか？** Meta Verified は WhatsApp Business アプリから申し込む形で、Coexistence の番号は引き続きそのアプリを使い続けられます。 **OBA を申請できるのは、どのくらい経ってからですか？** 番号が WhatsApp Business Platform に 30 日以上登録されている必要があります。 **OBA の申請が却下された場合はどうなりますか？** Meta は、再申請の前に 30 日待つよう案内しています。 --- ## 1 つの Coexistence 番号に複数の担当者とシステムで対応する方法 https://easycoexistence.com/ja/docs/multiple-agents-on-one-number Coexistence の番号には、人とソフトウェアが同時に対応できます。スタッフは WhatsApp Business アプリと、メインの電話以外に最大 4 台までのリンク済みデバイスを使い、システムは Cloud API を使います。アプリやコンパニオンデバイスから人が送信したメッセージはすべて smb_message_echoes Webhook としてソフトウェアに届くため、双方が同じスレッドを共有できます。 ### 複数の担当者は同じ番号にどう対応するのですか？ リンク済みデバイスを使います。WhatsApp では、1 つのアカウントをメインの電話以外に最大 4 台の追加デバイスで利用できます。この機能の発表でも、小規模企業の従業員が同じ WhatsApp Business アカウントで、それぞれの携帯電話からお客様に返信する使い方が明示されていました。 Coexistence の番号でもこれは変わりません。アカウントの所有者はメインの電話のままで、ほかのスタッフはリンクした携帯電話、タブレット、ブラウザ、デスクトップアプリから対応します。対応するコンパニオンクライアントと、オンボーディングによる影響については、リンク済みデバイスのページで説明しています。 ### ソフトウェアはどこに関わりますか？ 同じ番号の API 側です。CRM、自動化ツール、AI エージェントが Cloud API で送信し、お客様のメッセージは Webhook で受け取ります。その間も、スタッフはアプリを使い続けられます。 番号は両側で同じ回線なので、お客様から見ると、誰が書いたかに関係なく会話は 1 つです。API が送信したメッセージはアプリのスレッドにも表示されるため、スタッフはシステムがすでに伝えた内容を確認できます。共有される制約は送信量だけです。アプリと Cloud API の両方で使う番号について、Meta は毎秒 20 メッセージに固定しています。 ### 担当者がすでに返信したことを、ソフトウェアはどう知るのですか？ エコーで知ります。Meta の smb_message_echoes Webhook は、パートナー経由でオンボーディングした企業が WhatsApp Business アプリまたはコンパニオンデバイスからメッセージを送信したときに発火します。アプリからメッセージを編集または削除したときにも発火します。 メインの電話で入力した場合も、リンクしたノートパソコンで入力した場合も、その番号を使う全員が対象です。エコーを読み取るシステムは、会話を「担当者が対応済み」として扱い、自動返信を止められます。これが、チームを支援する自動化と、チームの発言に割り込む自動化の違いです。 - アプリまたはコンパニオンデバイスから送信: エコーが届きます。 - アプリで編集: エコーが届きます。 - アプリで削除: エコーが届きます。 ### それぞれの側で気をつけることは何ですか？ スタッフは、メインの電話を使い続けてください。Meta は、メインデバイスが約 14 日間操作されないと Coexistence の番号の接続を解除し、コンパニオンデバイスも単独で約 30 日間操作されないと接続を解除します。ノートパソコンだけで運用しているチームは、両方を失うおそれがあります。 ソフトウェアは、プラットフォームのルールに従います。24 時間のカスタマーサービスウィンドウ内ではフリーテキスト、それ以外ではテンプレートを使います。また、アプリと共有する番号では Meta がグループチャットを対象外としているため、API ではどちら側もグループチャットを利用できません。 - smb_message_echoes を無視すること。これがないと、リンクしたノートパソコンから担当者がすでに返信したことを、ボットが判断できません。 - メインの電話を何週間も使わず、リンクしたノートパソコンだけでチーム全体を運用すること。 - オンボーディング後に WhatsApp for Windows をリンクすること。Meta は、Coexistence の番号では非対応としています。 **1 つの番号に何人で対応できますか？** WhatsApp では、メインの電話以外に最大 4 台のリンク済みデバイスを使えます。それぞれを別の担当者が使えます。 **リンクしたノートパソコンからのメッセージは CRM に届きますか？** はい。アプリまたはコンパニオンデバイスから送信されたメッセージについて、Meta が smb_message_echoes を送信します。 **チャットボットと担当者は 1 つの会話を共有できますか？** はい。どちらも同じスレッドに書き込み、エコーによってボットは担当者の返信を把握できます。 **API 側にシートの上限はありますか？** Meta が制限するのは API の送信量です。共有する番号は毎秒 20 メッセージに固定されており、システムの数に上限はありません。 --- ## リンク済みデバイスと Coexistence：解除される端末 https://easycoexistence.com/ja/docs/linked-devices-and-coexistence WhatsApp Business アプリの番号を Cloud API に接続すると、そのアカウントに紐づく全てのコンパニオンデバイスのリンクが解除されます。WhatsApp Web やコンパニオンとしてリンクした携帯電話など、対応しているものは接続後に再リンクできます。WhatsApp for Windows と WhatsApp for WearOS は Coexistence の番号では非対応です。また、約 30 日間使われなかったコンパニオンデバイスは接続が切れます。 ### 接続時、リンク済みデバイスはどうなりますか？ 全てサインアウトされます。Meta のドキュメントによると、企業が既存の WhatsApp Business アプリのアカウントと番号で Cloud API に接続すると、全てのコンパニオンアプリがアカウントからリンク解除され、その後、対応しているコンパニオンアプリは再リンクできます。 これによって失われるものはありません。アカウントとトーク履歴はメインの携帯電話に残ります。ただし、ブラウザや 2 台目の携帯電話で応対している受付などは、接続が完了した瞬間にログアウトされます。QR コードを読み取った後ではなく、読み取る前にチームへ伝えておくことをおすすめします。 ### 接続後に使えるコンパニオンデバイスはどれですか？ 2 つを除く全てです。Meta は、WhatsApp for Windows と WhatsApp for WearOS を除く全てのコンパニオンクライアントを Coexistence の番号で対応としています。対応しているものは、これまでと同じくメインの携帯電話で QR コードを読み取って再リンクします。デバイス数の上限も従来と同じです。 - ブラウザの WhatsApp Web：対応。QR コードで再リンクできます。 - コンパニオンとしてリンクする追加の携帯電話：対応。 - WhatsApp for Windows：非対応。 - 腕時計の WhatsApp for WearOS：非対応。 ### 何台までリンクできますか？ メインの携帯電話のほかに最大 4 台です。WhatsApp は携帯電話のマルチデバイス対応の発表で、携帯電話を、ウェブブラウザ、タブレット、デスクトップと同様に最大 4 台の追加デバイスの 1 つとしてリンクできると説明しています。用途として、小規模ビジネスのスタッフが自分の携帯電話でお客様に応対する場面を挙げています。 Coexistence の番号では、この上限は対応しているコンパニオンクライアントで共有されます。これまで Windows アプリを使っていたオフィスは、多くの場合、そのデスクをブラウザの WhatsApp Web に切り替えます。WhatsApp Web も他のコンパニオンと同じく 4 台のうちの 1 台として数えられます。 ### リンク済みデバイスの接続は何で維持されますか？ デバイスの種類ごとに 1 つずつ、合計 2 つの非アクティブ規則があり、どちらも Meta の切断データに理由として表示されます。 PRIMARY_INACTIVITY はメインの携帯電話が対象で、約 14 日間操作がないと発生します。WhatsApp は、メインデバイスが長期間非アクティブになるとコンパニオンデバイスの全てからアカウントをログアウトするとも説明しています。使われていないメインの携帯電話があると、リンク済みの全てのデバイスも一緒に切断されます。 COMPANION_INACTIVITY はコンパニオンデバイス単体が対象で、約 30 日間使われないと発生します。支店でほとんど使われないノートパソコンが典型的な例です。 - WhatsApp Web で応対しているスタッフに伝えずに接続を進める。接続が完了した時点でログアウトされます。 - WhatsApp for Windows アプリを再リンクしようとする。Meta は Coexistence の番号では非対応としています。 - 全員がリンク済みデバイスで作業しているからと、メインの携帯電話を引き出しにしまったままにする。メインの携帯電話が非アクティブになると、コンパニオンデバイスも切断されます。 **Coexistence で WhatsApp Web のリンクは解除されますか？** はい。接続時に全てのコンパニオンデバイスのリンクが解除されます。WhatsApp Web は対応しているため、すぐに再リンクできます。 **WhatsApp の Windows デスクトップアプリは使えますか？** Coexistence の番号では使えません。Meta は WhatsApp for Windows を非対応のコンパニオンとしています。 **Coexistence 自体がリンク済みデバイスになりますか？** いいえ。Coexistence は Meta の接続手続きで番号に紐づけられる Cloud API であり、コンパニオンの枠は使いません。 **コンパニオンは何台までリンクできますか？** メインの携帯電話のほかに最大 4 台です。Meta が対応しているコンパニオンクライアント全体で数えます。 --- ## Coexistence 接続の電話番号を変更するとき https://easycoexistence.com/ja/docs/changing-the-phone-number Coexistence 接続は 1 つの電話番号に紐づいています。企業が WhatsApp Business アプリで番号を変更すると、Meta は理由 CHANGE_NUMBER で接続を切断します。新しい番号はプラットフォーム上では別のビジネス用電話番号として扱われるため、Coexistence のフローで新しい接続として改めてオンボーディングする必要があります。 ### 番号を変更すると、接続はどうなりますか？ 接続は終了します。Meta は、電話番号の変更を Coexistence 接続が切断される理由の 1 つとして挙げており、account_update Webhook の disconnection_info に理由 CHANGE_NUMBER を載せて通知します。 これは厳しい仕様というより、プラットフォームの一貫した設計によるものです。API 側が把握している情報はすべて、ビジネス用電話番号を単位に管理されています。電話番号 ID、表示名、品質評価、Webhook のサブスクリプションなどです。番号が違えば別のアセットになるため、旧番号に紐づいていたものは自動では引き継がれず、旧接続は番号を変更した時点で機能しなくなります。 ### 新しい番号はどのように接続しますか？ 初めての接続として行います。新しい番号も、Coexistence に参加する他の番号と同じ条件を満たしたうえで、最初からオンボーディングを行う必要があります。旧接続のものは何も再利用されないため、日程を決めた短いプロジェクトとして切り替えを進めると安心です。 - WhatsApp Business アプリで有効になっており、バージョンが 2.24.17 以降であること。 - ご自身が管理者である Business Portfolio に属していること。 - 他のプロバイダーに接続されていないこと。 - 他のビジネス用電話番号と同様に、登録時に表示名を提供すること。 ### API 側では何を更新すべきですか？ 旧番号またはその ID を保存しているすべての場所です。Cloud API 経由で送信する連携は電話番号 ID を宛先に指定するため、旧 ID を指したままの CRM、自動化ワークフロー、AI エージェントは、新しい番号に切り替わらずに失敗します。 新しい接続では、オンボーディングの質問も最初からやり直しになります。チャット履歴を共有するかどうかや、同期のための 24 時間の期間も含まれます。旧接続に設定していた Webhook の送信先は、新しい接続にも設定し直してください。Portfolio の上限も確認しておきましょう。Meta は、新しい Business Portfolio に登録できるビジネス用電話番号を、認証が完了するか 2,000 件のメッセージ送信上限に達するまで 2 件までに制限しています。 ### プラットフォーム上の旧番号はどうなりますか？ 誰かが削除するまで、WhatsApp Business アカウントのアセットとして残ります。Meta では、ビジネス用電話番号を削除できるのは Business Portfolio の管理者だけです。また、過去 30 日以内に有料メッセージの送信に使われた番号は削除できません。 削除は任意の整理作業であり、新しい番号を接続するための必須条件ではありません。ただし、古い番号をアカウントに残しておくと、システムが誤った番号を宛先にし続けやすくなります。30 日が過ぎてから削除すると、アカウントの見通しが保てます。 - 再接続の計画を立てる前にアプリで番号を変更してしまうこと。旧接続はその時点で終了します。 - 連携先に旧電話番号 ID を残したままにすること。送信は新しい番号に追従せず、失敗します。 - 切り替えの直後に旧番号を削除しようとすること。30 日以内に有料メッセージを送信していた場合、Meta はブロックします。 **新しい番号に接続は引き継がれますか？** いいえ。Meta は理由 CHANGE_NUMBER で接続を切断し、新しい番号は新しい接続としてオンボーディングします。 **新しい電話番号 ID は必要ですか？** はい。新しい番号はプラットフォーム上で別のビジネス用電話番号であり、固有の ID を持ちます。 **旧番号をすぐに削除できますか？** 過去 30 日以内に有料メッセージを送信していない場合のみ可能です。また、削除できるのは Business Portfolio の管理者だけです。 **表示名をもう一度選ぶ必要がありますか？** はい。Meta は、ビジネス用電話番号の登録時に表示名の情報を求めています。 --- ## Meta ビジネス認証と Coexistence の番号 https://easycoexistence.com/ja/docs/business-verification Meta ビジネス認証は電話番号ではなく、Meta Business Portfolio に適用されます。認証がなくても Portfolio は送信でき、上限は 1 日あたり一意の受信者 250 件、登録できる番号は 2 件から始まります。認証は上限 2,000 に到達する方法の一つで、番号の上限を 20 に引き上げ、青いチェックマークを申請する前に必要です。 ### 番号を接続するのにビジネス認証は必要ですか？ いいえ、必要ありません。Meta のドキュメントでは、認証は Portfolio でできることを広げるための手段であり、送信そのものの条件とは位置づけられていません。 新規に作成した Business Portfolio は、カスタマーサービスウィンドウの外で直近 24 時間に一意の受信者 250 件というメッセージ上限と、登録できるビジネス用電話番号 2 件という上限から始まります。どちらも認証の有無に関係なく適用され、企業はこの範囲内であれば初日からお客様にメッセージを送れます。 認証で変わるのは上限の天井です。Meta がメッセージ上限を 250 から 2,000 へ引き上げる方法として挙げる 3 つの経路の一つであり、登録できる番号の上限を 20 に引き上げる 2 つの条件の一つでもあります。 ### WhatsApp でビジネス認証をすると何が可能になりますか？ よく一つにまとめて説明されますが、実際には別々の 3 つです。 - メッセージ上限の経路：認証は 2,000 の条件を満たす方法の一つで、その後は Meta の自動スケーリングが引き継ぎます。 - 番号の上限の拡大：Meta が Portfolio の登録可能な番号を 2 件から 20 件に引き上げ、business_capability_update の Webhook を送信します。 - 公式ビジネスアカウントの対象：青いチェックマークを申請する前に、番号を所有する Portfolio が認証されている必要があります。 - この 3 つのいずれも、スマートフォン上の WhatsApp Business アプリの動作は変えません。 ### Coexistence の番号にはどのように適用されますか？ Portfolio を通じて適用されます。Coexistence で接続した番号は、Meta Business Portfolio に属する WhatsApp Business アカウントに置かれ、認証はその Portfolio の属性です。Portfolio 内のすべての番号が、メッセージ上限とあわせて認証の結果を共有します。 青いチェックマークはもう少し条件が狭くなります。Meta の公式ビジネスアカウントのページでは、WhatsApp Business アプリの電話番号などにはこのステータスを付与しないと明記されていますが、アプリと Cloud API の両方で使用している番号については個別に説明していません。そのほかの条件は、認証済みであること、プラットフォーム上で 30 日以上の利用実績があること、番号に 2 段階認証を設定していること、表示名が承認されていることです。 ### どの Portfolio を認証すればよいですか？ WhatsApp Business アカウントを所有している Portfolio です。自社の番号を接続する企業であれば、自社の Portfolio にあたります。 代理店にとっては重要な点です。クライアントの番号を代理店の Portfolio 内で接続した場合、適用されるのは代理店の認証、上限、番号数の上限であり、クライアントの上限は代理店がそこで保有するほかのすべての番号と共有されます。Meta も、ある期間に 1 つの番号が Portfolio のメッセージ容量をすべて使い切る場合があると明記しています。 企業ごとに自社の Portfolio 内で接続すれば、認証、上限、請求が実際に送信している企業のもとに残ります。 - 認証が終わるまで接続を先送りする。開始時の上限の範囲内なら、認証なしでも送信できます。 - WhatsApp Business アカウントを所有する Portfolio とは別の Portfolio を認証する。結果は引き継がれません。 - 複数のクライアントの番号を 1 つの代理店 Portfolio にまとめて置く。メッセージ上限も番号数の上限も共有されます。 **Coexistence を使うのにビジネス認証は必要ですか？** いいえ。Portfolio は認証なしでも送信でき、開始時の上限は直近 24 時間で一意の受信者 250 件です。 **認証すると青いチェックマークがもらえますか？** それだけでは付与されません。認証は公式ビジネスアカウントの条件の一つで、申請は別に行い、Meta が審査します。 **認証は番号ごとに行いますか？** いいえ。認証は Meta Business Portfolio に紐づき、その Portfolio 内のすべての番号が共有します。 **認証するとスマートフォンのアプリは変わりますか？** いいえ。変わるのはプラットフォームの上限と対象条件で、WhatsApp Business アプリの動作は変わりません。 --- ## WhatsApp のメッセージ上限：現在のポートフォリオ単位のティア https://easycoexistence.com/ja/docs/messaging-limits-and-tiers メッセージ上限は、カスタマーサービスウィンドウの外で、企業が直近 24 時間に届けられるユニークな相手の人数を制限する仕組みです。2025 年 10 月 7 日以降は Meta Business Portfolio 単位で設定され、ポートフォリオ内のすべての番号で共有されます。上限は 250 から始まり、2,000、10,000、100,000、無制限と上がっていきます。 ### メッセージ上限は実際に何を数えるのですか？ カスタマーサービスウィンドウの外で、直近 24 時間以内に御社がメッセージを届けた WhatsApp ユーザーの電話番号のうち、重複を除いたものです。この定義から、次の 3 点が導かれます。 まず、開いているカスタマーサービスウィンドウ内の返信は数えません。そのため、問い合わせてきた相手にだけ返信している番号は、上限に触れることなく上限をはるかに超える量を運用できます。次に、同じ相手に複数のテンプレートを送っても、その相手は 1 人として数えます。そして、期間は暦日ではなく直近 24 時間で動くため、古い送信が期間から外れるにつれて枠が少しずつ空きます。 上限が決めるのは、最初に何人にリーチできるかです。送信の速さや量ではありません。 ### 2025 年 10 月に何が変わったのですか？ 2025 年 10 月 7 日より前は、電話番号ごとに独自の上限があり、新しい番号は同じ仲間の番号の実績に関係なく 250 から始まりました。現在は上限がビジネスポートフォリオに属し、その中のすべての番号が共有します。 - 新しく登録した番号は、すぐにポートフォリオの上限を共有します。 - 250 の次の段階は 2,000 になりました。以前は 1,000 でした。 - 引き上げは、条件を満たしてから 6 時間後に反映されます。以前は 24 時間でした。 - 番号の品質評価が下がっても、上限は引き下げられなくなりました。 - 参照するフィールドは whatsapp_business_manager_messaging_limit です。messaging_limit_tier は非推奨です。 ### 上限はどのように引き上げられますか？ 2 段階です。250 から上げるには、ポートフォリオが次のいずれかのスケーリング経路を完了します。ビジネス認証を行う、オンボーディングパートナーに認証してもらう、または品質評価の高いテンプレートを使い、30 日以内にカスタマーサービスウィンドウの外でユニークな受信者 2,000 人にメッセージを届ける、のいずれかです。その後 Meta がメッセージの品質を審査して承認または却下し、却下の場合は、別に取るべき経路を示した account_alerts Webhook が届きます。 2,000 以降は自動でスケーリングされます。ポートフォリオ内のすべての番号とテンプレートで高品質なメッセージを送り、直近 7 日間に現在の上限の半分以上を使っていれば、Meta が 1 段階引き上げます。購入するものも、申請もありません。 ### メッセージ上限とスループットはどう違いますか？ 上限は 1 日あたりの人数を数え、スループットは 1 秒あたりのメッセージ数を数えます。両者は別々に設定され、別々に制限にかかります。 Coexistence の番号では、この違いがはっきり表れます。Meta は、WhatsApp Business アプリと Cloud API の両方で使用している番号のスループットを、アプリとの互換性を保つため 1 秒あたり 20 メッセージに固定しています。この値はポートフォリオのティアによって変わりません。そのため、メッセージ上限が無制限のポートフォリオでも、Coexistence の番号からは 1 秒あたり 20 通で送信されます。 1 秒あたりの制限、受信者ごとの制限、管理 API 呼び出しの制限には、それぞれ専用のページとエラーコードがあります。 - messaging_limit_tier を読み取ってしまう。これは非推奨で、現在のフィールドは whatsapp_business_manager_messaging_limit です。 - 新しい番号は必ず 250 から始まると思い込む。2025 年 10 月以降は、ポートフォリオの上限をすぐに引き継ぎます。 - 返信を上限に数えてしまう。開いているカスタマーサービスウィンドウ内のメッセージは対象外です。 - 1 つの番号のキャンペーンが他の番号の枠を使い切ってしまう。ポートフォリオ全体が同じ上限を共有しています。 **上限は番号ごとですか、それともアカウントごとですか？** 2025 年 10 月 7 日以降は Meta Business Portfolio 単位です。ポートフォリオ内のすべての番号が共有します。 **お客様からの返信も上限に数えられますか？** いいえ。数えるのはカスタマーサービスウィンドウの外への送信だけで、ユニークな受信者は直近 24 時間につき 1 人として数えます。 **品質評価が低いと上限は下がりますか？** 2025 年 10 月以降は下がりません。Meta は品質低下による上限の引き下げをやめました。ただし、上限が上がるかどうかは今も品質で決まります。 **ティアが上がると Coexistence のスループットも上がりますか？** いいえ。Coexistence の番号のスループットは、ティアに関係なく 1 秒あたり 20 メッセージに固定されています。 --- ## Coexistence 番号での商品カタログ https://easycoexistence.com/ja/docs/catalog-and-coexistence Coexistence で番号を接続しても、WhatsApp Business アプリのカタログ、注文、ステータスの各ツールはアプリ内でそのまま使えます。ただし、Cloud API ではこれらのアプリのツールは利用できません。API の商品メッセージは、Meta にアップロードして WhatsApp Business アカウントに接続したカタログを使い、設定は電話番号ごとに行います。 ### WhatsApp Business アプリのカタログは Coexistence の後も使えますか？ はい、スマートフォン上のアプリでは使えます。Meta の Coexistence 機能表では、カタログ、注文、ステータスなどのビジネスツールは、接続後も WhatsApp Business アプリでの動作に変更がないとされています。 同じ行には、これらが Cloud API では非対応であることも記載されています。連携を設計する際はこの点が重要で、アプリのカタログツールを API 経由で読み取ったり、編集したり、同期したりすることは想定しないでください。 そのため、アプリのカタログで販売している店舗は、接続後も同じ方法で販売を続けられます。変わるのは、API も使えるようになり、商品を送る独自の方法が加わる点です。 ### Cloud API で商品カタログはどのように動作しますか？ Meta にアップロードして WhatsApp Business アカウントに接続したカタログを使います。カタログは商品やサービスを構造化した在庫情報で、各アイテムには名前、説明、価格、画像、在庫状況などが含まれます。Meta は次の 4 つの段階を示しています。 - 在庫のアップロード: Commerce API または Meta Commerce Manager を使用します。 - 電話番号ごとのコマース設定: カートを有効にするか、カタログを表示するかを選びます。 - 商品の共有: カタログメッセージ、単一商品メッセージ、複数商品メッセージ、カルーセルメッセージで送ります。 - お客様の反応: 注文内容や商品に関する質問が Webhook 通知として届きます。 ### アプリと API で商品メッセージにはどんな違いがありますか？ Meta が明記している目に見える違いは 1 つです。Cloud API 経由で送信したメッセージでは、アプリから送った商品メッセージと異なり、現時点ではチャット画面のヘッダーにショッピングカートのアイコンが表示されません。 API 側には、アプリでは同じ形で提供されていない設定もあります。既定では、アカウント内のすべてのビジネス用電話番号でショッピングカートが有効、ストアフロントのアイコンが非表示になっており、どちらもコマース設定のエンドポイントで番号ごとに切り替えられます。カタログを無効にすると、wa.me のカタログリンクや「カタログを表示」ボタンをタップした際に、無効なカタログであることを示す警告が表示されます。 カスタマーサービスウィンドウの外では、他の企業起点のメッセージと同様に、承認済みのメッセージテンプレートの中で商品を送ります。 ### 商品は誰が審査しますか？ Meta が自動で審査します。WhatsApp Business アカウントに接続したカタログに追加された商品は審査の対象となり、ポリシーに違反する商品にはフラグが付けられ、企業には WhatsApp Commerce Policies が案内されます。承認されなかった商品は、Meta Commerce Manager で異議を申し立てられます。 お客様は、メッセージで受け取った特定の商品を報告することもでき、その場合は個別に審査が行われます。企業そのものに対する報告は別の扱いで、Meta が番号の品質評価に使うシグナルの 1 つになります。 インドに拠点を置く企業には、オンライン販売に関する法令を遵守する追加の義務があり、Meta は Business Compliance API を通じてこれに対応しています。 - アプリのカタログツールを API で読み取れると想定すること。Meta は Cloud API では非対応としています。 - wa.me のカタログリンクが出回っている番号でカタログを無効にすること。リンクを開くと、無効なカタログであることを示す警告が表示されます。 - カスタマーサービスウィンドウの外で、テンプレートを使わずに商品を送ること。企業起点のメッセージにはテンプレートが必要です。 **接続するとカタログは削除されますか？** いいえ。Meta は、カタログを含むアプリのビジネスツールは Coexistence の接続後も変わらないとしています。 **API でアプリのカタログを読み取れますか？** Meta は、アプリのビジネスツールを Cloud API では非対応としています。API の商品メッセージは、WhatsApp Business アカウントに接続したカタログを使います。 **1 通のメッセージに何点の商品を入れられますか？** 複数商品メッセージでは、セクションに分けて最大 30 点まで入れられます。 **カートをオフにできますか？** はい、コマース設定のエンドポイントで電話番号ごとに設定できます。既定では有効になっています。 --- ## Coexistence 後のブロードキャストリストとマーケティングテンプレート https://easycoexistence.com/ja/docs/broadcast-lists-vs-templates Coexistence で番号を接続すると、WhatsApp Business アプリのブロードキャストリストは読み取り専用になり、新しく作成することはできなくなります。API での代替手段は、受信者ごとに送信するマーケティングテンプレートです。オプトインが必要で、Business Portfolio のメッセージ上限に計上され、Meta から課金され、各ユーザーのマーケティング設定も尊重されます。 ### API ではブロードキャストリストの代わりに何を使いますか？ 承認済みのマーケティングテンプレートを、Cloud API で受信者ごとに 1 件ずつ送信します。API 側にリストというオブジェクトはありません。連携システムが配信対象を保持し、その中の各番号にテンプレートを送ります。 これにより、3 つのことが同時に変わります。まず、内容は送信前に Meta のテンプレート審査を通る必要があります。次に、カスタマーサービスウィンドウの外で送信するたびに会話が開始され、その料金は企業自身の WhatsApp Business アカウントに登録した支払い方法に Meta から請求されます。さらに、一意の受信者ごとに、直近 24 時間の Business Portfolio のメッセージ上限に計上されます。 無効化そのものと Meta が示している理由については、Coexistence で無効になる機能のページで説明しています。 ### マーケティングテンプレートを受け取れるのは誰ですか？ 企業に番号を伝え、企業からの連絡を受け取ることにオプトインした人です。Meta のビジネスメッセージングポリシーはこの 2 つの条件を明記しており、オプトインでは企業名を示し、その企業からのメッセージ受信に同意することを明確にする必要があります。 方法については、これらの要件と適用される法令を満たす限り、Meta は企業に委ねています。SMS、ウェブサイトのフォーム、IVR 通話、署名入りの紙の書面などが例として挙げられています。そのため、オプトインの証拠は端末の連絡先ではなく、企業自身の記録に残すことになります。 オプトインしていない相手に送信すると、ブロックや報告が最も早く集まります。それが品質の低下につながります。 ### マーケティングテンプレートが届かないことがあるのはなぜですか？ API では、ブロードキャストリストでは見えなかった制御が受信者ごとに適用されるためです。 - ユーザーごとのマーケティング上限: 反応する可能性が低いと判断された相手へのマーケティングテンプレートを、WhatsApp が保留することがあり、その場合は 131049 が返されます。 - マーケティングの停止: ユーザーは「特典とお知らせ」設定で、企業からのマーケティングメッセージを停止できます。その場合は 131050 が返されます。 - 米国の番号: WhatsApp は現在、米国の電話番号を持つユーザーにはマーケティングテンプレートを配信しません。 - 対象外の地域: ユーザーごとの上限は、現在 EEA、英国、日本、韓国では有効になっていません。 ### アプリ自体のマーケティングメッセージ機能は今も使えますか？ Meta の Coexistence 機能一覧では、アプリのメッセージ機能がまとめて 1 行に記載されています。マーケティングメッセージ、あいさつメッセージ、不在メッセージ、クイック返信、ラベルが対象で、オンボーディング後も WhatsApp Business アプリ内での変更はないとされています。同じ行で、これらは Cloud API では未対応と示されています。 つまり、アプリのマーケティングメッセージ機能と API のマーケティングテンプレートは、同じ番号で使える別々の経路です。また Meta は、WhatsApp Business アプリから送信するメッセージはオンボーディング後も無料のままで、Cloud API 経由で送信するメッセージは Cloud API の料金に従うと説明しています。 変更が生じる例外がブロードキャストリストであり、そのために代替手段が必要になります。 - 131049 をすぐに再試行する。Meta は少なくとも 24 時間空けるよう求めており、早めに再試行すると、最大 1 日のあいだ以降の試行がブロックされることがあります。 - 131050 を再試行する。ユーザーは企業からのマーケティングメッセージを停止しており、メッセージは受信されません。 - ブロードキャストリストをそのままオプトインリストとして取り込む。番号を保存しているだけでは、ポリシーが定めるオプトインにはなりません。 **ブロードキャストリストは削除されますか？** いいえ。既存のブロードキャストリストは読み取り専用になり、番号が接続されている間は新しく作成できません。 **ブロードキャストの配信先にメッセージを送るには、テンプレートが必要ですか？** カスタマーサービスウィンドウの外では必要です。企業から始める販促には、API ではマーケティングテンプレートを使います。 **テンプレートが 131050 で失敗したのはなぜですか？** その受信者が、御社からのマーケティングメッセージの受信を停止しているためです。Meta は再試行しないよう案内しています。 **アプリのマーケティングメッセージ機能はなくなりましたか？** いいえ。Meta は、マーケティングメッセージを含むアプリのメッセージ機能は、オンボーディング後もアプリ内で変更なしとしています。 --- ## 企業発信メッセージに必要な WhatsApp のオプトイン要件 https://easycoexistence.com/ja/docs/opt-in-requirements 企業が WhatsApp で相手にメッセージを送る前に、Meta のポリシーは 2 つの条件を求めています。相手が企業に電話番号を伝えていること、そして企業からのメッセージを希望するというオプトインを企業が受け取っていることです。2024 年 11 月以降、オプトインは WhatsApp に限定しない一般的な内容でも構いませんが、企業名を明記し、現地の法令に従う必要があります。 ### Meta のオプトインポリシーは何を求めていますか？ 企業が WhatsApp で相手に連絡する前に、次の 2 つの条件をどちらも満たす必要があります。相手が企業に携帯電話番号を伝えていること。そして、企業からの今後のメッセージや通話を受け取りたいという相手のオプトイン許可を、企業が受け取っていることです。 オプトイン自体にも 3 つの要件があります。相手が企業からの連絡の受信にオプトインしていることを明確に示すこと。企業名を明確に示すこと。そして適用法令に従うことです。何が法令に適合するかの判断は、すべて企業に委ねられています。 2024 年 11 月のポリシー更新で 1 点が緩和されました。現地の法令に従っていれば、オプトインは一般的な内容でよく、WhatsApp に言及する必要はありません。 ### Meta はどのオプトイン方法を認めていますか？ 3 つの要件を満たす方法であれば、どれでも認められます。Meta はそのような方法がポリシーに適合すると明言し、選択は企業に任せたうえで、対応する方法の例を挙げています。どの方法を使う場合でも、メッセージを受け取ることで相手にどんなメリットがあるかを明確にするよう、Meta は勧めています。 - SMS。 - ウェブサイトのフォーム。 - 電話での自動音声応答（IVR）フロー。 - 対面または紙面での、署名入りの書面。 - どの方法でも、適用法令が求める通知と許可は企業の責任です。 ### WhatsApp Business アプリの連絡先に入っていればオプトインになりますか？ それだけではなりません。Meta のポリシーは、企業からのメッセージを希望するという相手本人の確認を許可の根拠としています。連絡先リストに電話番号があるだけでは、2 つの条件のうち最初の 1 つを満たすにとどまります。 この点は Coexistence の番号で特に重要です。接続によってアプリの連絡先を同期できるため、既存の顧客層が最初のメッセージテンプレートによる配信先に見えやすいからです。番号を知っていることと、相手の確認を得ていることは別です。 顧客のほうから企業にメッセージを送ってきた場合は別のケースです。そのメッセージによってカスタマーサービスウィンドウが開き、その間は企業から返信できます。 ### オプトインが不十分だとどうなりますか？ 受信者から反発が起こり、プラットフォームはそのフィードバックに反応します。Meta のオプトインガイダンスによると、ユーザーは企業をブロックまたは報告したり、マーケティングメッセージを停止したりでき、品質が長期間低いままの企業には、Meta のシステムが送信数の制限をかけます。 Meta の実践的なアドバイスはここから導かれます。送信するメッセージのカテゴリを事前に伝えて期待値を合わせるか、カテゴリごとにオプトインを取得してください。特定のカテゴリを停止する手順を分かりやすく案内し、その希望を尊重してください。オプトインとオプトアウトの導線を分かりやすくし、新しいオプトイン方法を開始したときは品質評価を注意深く確認してください。 またポリシーは、WhatsApp 上かどうかを問わず、ブロック、中止、オプトアウトのすべての依頼を尊重し、その相手を連絡先リストから削除することも求めています。 - 同期したアプリの連絡先をオプトインのリストとして扱うこと。ポリシーが求めるのは電話番号だけでなく、一人ひとりからの確認です。 - 企業名を示さないままオプトインを取得すること。Meta は企業名を明確に示すことを求めています。 - WhatsApp 上で届いたオプトアウトだけを尊重すること。ポリシーはあらゆる経路での依頼を対象としています。 **オプトインに WhatsApp への言及は必要ですか？** いいえ。2024 年 11 月のポリシー更新以降、現地の法令に従っていれば一般的なオプトインが認められています。 **先にメッセージをくれた顧客への返信にオプトインは必要ですか？** 顧客からのメッセージによってカスタマーサービスウィンドウが開き、その間は返信できます。オプトインが対象とするのは、企業から開始するメッセージです。 **オプトインはオフラインで取得できますか？** はい。Meta は、対面または紙面での署名入りの書面を、認められる方法の一つとして挙げています。 **相手がオプトアウトしたらどうすべきですか？** 相手がどの経路で依頼したかにかかわらずメッセージの送信を止め、ポリシーが求めるとおり連絡先リストから削除してください。 --- ## ブロックと報告が WhatsApp の品質評価に与える影響 https://easycoexistence.com/ja/docs/quality-rating-blocks-and-reports メッセージの品質は、過去 7 日間に受信者が企業のメッセージをどう受け止めたかで判定され、直近のものほど重く評価されます。シグナルは、ブロック、報告、ミュート、アーカイブ、そしてブロック時にユーザーが選ぶ理由です。品質が低い状態が続くと、送信制限、送信時のエラー 131048、テンプレートの一時停止につながります。 ### どのようなフィードバックが WhatsApp の品質評価を下げますか？ Meta は、ブロック、報告、ミュート、アーカイブ、そしてユーザーが企業をブロックするときに選ぶ理由をシグナルとして明示しています。品質は過去 7 日間にメッセージがどう受け止められたかに基づき、直近ほど重く評価されます。そのため、昨日の不適切な送信は 6 日前のものより大きく影響します。 ここから 2 つのことが言えます。1 つは、ターゲティングを誤った配信が 1 回あるだけで評価が急に動き得ることです。Meta は、トラフィックの多い番号では品質が数分で変わることが多いと説明しています。もう 1 つは、評価の対象が直近 7 日間だけなので、それより古いフィードバックは評価に含まれなくなることです。 テンプレートには、番号の評価とは別に、フィードバックと既読率をもとにした独自の評価があります。 ### 品質が下がるとどうなりますか？ 複数のレベルで、いくつかの影響が出ます。 - 送信が 131048 で失敗することがあります。Meta はこれを、ブロックやスパム報告が多すぎることと結び付けています。 - YELLOW または RED のテンプレートも送信はできますが、一時停止や無効化のリスクがあります。 - 品質はテンプレートのペーシングに影響し、配信の進み方が遅くなることがあります。 - ポリシー上、WhatsApp はブロックや報告に基づいて、企業が送信できるメッセージ数を制限できます。 - 2025 年 10 月 7 日以降、品質が下がってもポートフォリオのメッセージ上限は下がりませんが、上限の引き上げは止まることがあります。 ### 低い品質評価はどう回復させますか？ まず否定的なフィードバックの原因を止め、その後 7 日間のウィンドウが過ぎるのを待ちます。 チェックリストとして使えるのが、Meta の高品質メッセージのガイドラインです。企業からのメッセージ受信にオプトインした人にだけ送信します。メッセージはパーソナライズし、役に立つ内容にします。目的の曖昧な挨拶や自己紹介のメッセージは避けます。1 日に送るメッセージ数を増やしすぎないようにします。内容と長さは簡潔に保ちます。 実際には、ブロックを集めているキャンペーンやテンプレートを止め、どの配信先セグメントに送ったか、そのセグメントがどのようなオプトインをしていたかを確認します。Meta のオプトインのガイダンスでも、メッセージのカテゴリごとにオプトインを取得することを勧めています。想定外のカテゴリこそ、ユーザーがブロックする理由になるためです。 ### 品質評価はどこに表示されますか？ WhatsApp Manager の Account tools にある Phone numbers で、番号のステータスやメッセージ上限とともに確認できます。Graph API では、電話番号オブジェクトの quality_rating として取得できます。テンプレートの評価は各テンプレートの quality_score にあり、Manage templates パネルでは High、Medium、Low、Quality pending と表示されます。 端末の WhatsApp Business アプリには、評価に関する表示が一切ありません。そのため Coexistence の番号では、店舗の誰も気付かないうちに品質が下がることがあります。なお、phone_number_quality_update Webhook は、フィールド名に反して評価そのものを配信しません。この Webhook が実際に何を運ぶかは、専用のページで説明しています。 - 新しくインポートしたリストに、目的の曖昧な挨拶メッセージを送ってしまう。Meta が避けるべきものとして挙げており、ブロックを招きます。 - 131048 で失敗した送信を再試行する。制限は番号に対するものなので、送信を重ねるほど原因となるフィードバックが増えます。 - 番号の評価だけを見ている。テンプレートには別の評価があり、番号が問題なさそうでも RED のテンプレートは一時停止されることがあります。 **ブロックが 1 件あるだけで評価は下がりますか？** Meta はしきい値を公表していません。品質は、過去 7 日間のメッセージ全体に対するフィードバックを、直近ほど重く扱って反映します。 **評価が低いと、メッセージ上限も下がりますか？** 2025 年 10 月 7 日以降は下がりません。ただし、上限の引き上げが止まったり、送信が制限されたりすることはあります。 **回復までにどのくらいかかりますか？** Meta は回復までの期間を公表していません。評価の対象は直近 7 日間なので、それより古いフィードバックは含まれなくなります。 **ミュートされたチャットも対象になりますか？** はい。Meta は、ブロックや報告と並べて、ミュートとアーカイブも品質のシグナルとして挙げています。 --- ## GDPR と Coexistence: メッセージデータの行き先 https://easycoexistence.com/ja/docs/gdpr-and-coexistence Coexistence で番号を接続すると、その番号のメッセージは WhatsApp Business アプリと Cloud API の間でミラーリングされます。Meta は、Cloud API については企業の代わりにデータ処理者として行動し、メッセージを最長 30 日間保持し、各企業が自社の GDPR 上の義務を果たすことを求めると述べています。 ### 番号で Coexistence を使うと、メッセージデータには何が変わりますか？ 会話が、スマートフォンだけでなく Cloud API からも見えるようになります。Meta の Coexistence に関するドキュメントによると、送受信したメッセージは Cloud API と WhatsApp Business アプリの間でミラーリングされ、WhatsApp の電話番号を持つ連絡先は同期でき、直近 6 か月分のチャットメッセージはオンボーディング中に同期できます。グループチャットは同期されません。 その時点から、番号の 1 対 1 のメッセージは Cloud API を経由します。Meta は、受信したメッセージを復号して企業へ転送し、送信するメッセージは Signal プロトコルで暗号化してから配信すると説明しています。 このページは、Meta が公表している内容と EasyCoexistence の動作を記したものです。法的助言ではありません。特定の構成が GDPR を満たすかどうかは、企業とその専門家が判断してください。 ### GDPR における自社の役割について、Meta は何と述べていますか？ Meta の Cloud API データプライバシーのページに、Meta 自身の言葉で立場が示されています。 - 法律がデータ処理者の概念を認める場合、Meta は Cloud API の提供にあたり、企業の代わりに処理者として行動します。 - Cloud API は、別段の指示がない限り、処理するメッセージを企業の代理として、企業の指示に従ってのみ利用します。 - メッセージの保持は最長 30 日間です。ユーザー識別子は、メッセージの最後のステータス更新から 30 日以内に削除されます。 - Cloud API の利用企業は、GDPR などの法律に基づく自社の義務を自ら果たす必要があります。 - 欧州地域の利用企業は、WhatsApp Business Data Transfer Addendum の対象となります。 ### メッセージデータを EU 内に保存できますか？ Meta は Cloud API のローカルストレージを提供しています。短い使用中の期間を経たあと、メッセージの内容を選択した国に保存します。Cloud API では、この使用中の期間は最長 60 分で、その間、内容は Meta のデータセンターで国際的に処理される場合があります。欧州の選択肢は、EU 向けのドイツ、スイス、英国です。 ローカルストレージは番号の登録時に設定します。登録済みの番号で変更するには、登録解除してから再登録する必要があります。また Meta の登録に関するドキュメントには、Cloud API と WhatsApp Business アプリの両方で使用中の番号には登録解除のエンドポイントを使えないと記されており、Coexistence の番号でローカルストレージを有効にする別の手順は説明されていません。 ### Meta を経由したあと、メッセージはどこへ届きますか？ WhatsApp Business アカウントの Webhook を受け取るエンドポイントへ届きます。Meta の Webhook オーバーライドを使うと、アプリは特定のアカウントの Webhook を、アプリ自体のコールバック URL とは別の URL に送れます。 EasyCoexistence はこのオーバーライドを使い、メッセージイベントを企業自身のシステムに向けます。そのため Meta は会話の内容を当社ではなく企業のシステムへ届け、EasyCoexistence が会話の内容を保存することはありません。当社が保持するのは、接続状態や品質など、監視の材料となる運用上のイベントだけです。 また Meta は、Cloud API について SOC 2 Type II と ISO 27001 のレポートを持ち、Business Messaging Compliance Center で公開していると説明しています。 - Meta が処理者であれば企業自身の義務も含まれると考えること。Meta は、利用企業が自社の GDPR 上の義務を果たす必要があると述べています。 - 同期先を決めないまま履歴の同期を承諾すること。最大 6 か月分のチャットが受信側のシステムに届く可能性があります。 - ローカルストレージを後から有効にするつもりでいること。設定は登録時に行い、変更するには再登録が必要です。 **Cloud API で Meta は処理者ですか、管理者ですか？** Meta は、法律がその概念を認める場合、Cloud API については企業の代わりにデータ処理者として行動すると述べています。 **Meta はメッセージの内容をどのくらい保持しますか？** Meta は、再送信などの機能のために、Cloud API のメッセージを最長 30 日間保持すると述べています。 **EasyCoexistence は私たちの会話を見られますか？** メッセージイベントは Meta から御社のシステムへ届けられ、EasyCoexistence が会話の内容を保存することはありません。 **このページは法的助言ですか？** いいえ。Meta が公表している内容と EasyCoexistence の動作を記したものです。コンプライアンスの評価は、企業とその専門家が行ってください。