WhatsAppをCRMに接続する実際の3つの方法(ネイティブ連携、ミドルウェア、カスタムAPI構築)それぞれのコストとセットアップにかかる手間、そして連携という課題そのものを回避するスタンドアロンの選択肢について解説します。
「WhatsApp CRM連携」という言葉は、持っているか持っていないかのどちらかのひとつのものであるかのように使われがちです。しかし実際はそうではありません。どのCRMを使っているか、そしてどれだけのエンジニアリング工数を割く覚悟があるかによって、WhatsAppをCRMに接続することは、ベンダーがすでに用意した設定をオンにするだけのこともあれば、コネクターアプリを介して2つのツールをつなぐことのこともあり、開発者にMetaのAPIへ直接コードを書かせることのこともあります。どの経路を選ぶかによって、コスト、コントロールできる範囲、そして最初のメッセージを送るまでにかかる時間はまったく違ってきます。
ここでは実際に存在する3つの方法それぞれが何を伴うのか、そして連携という問題そのものを丸ごと回避するスタンドアロンのツールがどこに位置づけられるのかを見ていきます。
ZohoやKommoをはじめとする一部のCRMには、WhatsAppのサポートが製品に直接組み込まれています。設定ページを開いてWhatsApp Businessの番号を接続するだけで、他に何もインストールすることなく、連絡先やリード、案件のレコードにメッセージが表示されるようになります。
内部的には、「ネイティブ」だからといってCRMベンダーがWhatsAppへの専用回線を持っているわけではありません。それが意味するのは、そのベンダーがすでにMeta承認済みのビジネスソリューションプロバイダー(BSP)になる、あるいは提携するという作業を済ませており、自分でBSPを別途探す必要がないということです。あるCRMについて、その設定が実際にどのようなものかをZohoのWhatsApp連携ガイドで詳しく取り上げています。Metaの承認待ちの時間や、どのネイティブ連携でも避けられないテンプレート承認のステップも含めて解説しており、これはどのCRMもMeta自身の審査プロセスを省略できないためです。
向いているケース: CRMにすでにこの機能が組み込まれていて、ネイティブ機能でカバーされていない要素を必要としないチーム。代償: そのベンダーが構築したものの範囲に限定されること、そして後でCRMを乗り換える場合、WhatsAppの設定は何一つ引き継げないことです。
CRMにWhatsAppが組み込まれていない場合、あるいはネイティブ版に必要な機能が欠けている場合は、コネクターアプリが両者の間に入ります。これは一括りにされがちな2つの異なるものを指します。1つは、個々のWhatsAppイベントをトリガーとしてCRMに渡すZapierやMakeのようなワークフローツール、もう1つは、ネイティブチャネルを持たないCRMにWhatsAppを橋渡しするために専用に作られたCRMマーケットプレイスアプリ(PickyAssist、Interakt、TimelinesAIなど)です。
どちらの経路も、関係にもう1つのベンダーを加えることになります。CRM、コネクター、そしてコネクターが実際にWhatsAppへ到達するために使うBSPです。つまり、請求先がもう1つ増え、不具合が起こりうる箇所ももう1つ増えるということです。新しいWhatsAppメッセージをリードとしてCRMに流し込むZapierの自動化は、Metaがwebhookのペイロードを変更したり、Zapが静かに動作を止めたりするまでは問題なく機能しますが、ネイティブ連携とは異なり、そうなったときにチェーン全体に責任を持つ単一のベンダーは存在しません。マーケットプレイスアプリは汎用的なZapよりも目的に特化していて概して信頼性も高いものの、それでもCRMとMeta自体のメッセージ料金の両方に加えて、別途のサブスクリプションが積み重なることに変わりはありません。
向いているケース: ネイティブサポートを一度も構築していないCRMから、カスタムコードを発注することなくWhatsAppに到達したい場合。代償: 追加のサブスクリプション、維持すべき追加の連携、そして目的特化型のネイティブチャネルほどには整理されない会話スレッドです。
最も柔軟で、最もコストのかかる方法は、開発者にWhatsApp Business APIをCRM自身のAPIに直接接続させ、どちらかのベンダーがあらかじめ用意したコネクターに頼るのではなく、両システム間のマッピングを自分たちで書くことです。社内にエンジニアリングチームを抱える大企業や、非常に特殊なデータフローを必要とする企業が、SalesforceやCRM内製ツール、あるいはネイティブ連携もマーケットプレイスの選択肢も一切ないCRMにWhatsAppを組み込む際、たいていはこの方法に行き着きます。
カスタム構築を使えば、WhatsAppの会話がどのようにレコードに対応づけられるか、何が何をトリガーするか、エラーがどう処理されるかを正確に制御できます。これらはいずれも、ネイティブチャネルやコネクターアプリでは触れられない部分です。ただし出荷までに最も時間がかかり(数時間ではなく数週間)、リリース後は誰かがメンテナンスを担う必要があります。Metaは定期的にAPIを変更しますし、カスタム構築は放っておいても自動的に更新されるわけではないからです。
向いているケース: 既製の選択肢ではサポートされない特定のデータフローが必要な場合、あるいはベンダーが用意したWhatsAppへの経路が一切ないCRMの場合。代償: 事前の開発者の工数と、その後継続するメンテナンス、それに加えてMeta自体のメッセージ単位の料金です。
| セットアップ期間 | 誰が構築するか | 継続コスト | 向いているケース | |
|---|---|---|---|---|
| ネイティブCRM連携 | 数日(主にMetaの承認待ち) | すでにCRMベンダーが構築済み | CRMのプラン料金 + Metaのメッセージ単位の料金 | すでに機能があり、特別なデータフローが不要なCRM |
| ミドルウェアコネクター | 数日〜数週間 | マーケットプレイスアプリ、または自分で設定するワークフロー | コネクターのサブスクリプション + CRM + Metaの料金 | ネイティブサポートがなく、社内に開発者もいないCRM |
| カスタムAPI構築 | 数週間 | 自社の開発者、または実装パートナー | 開発者の工数、メンテナンス + Metaの料金 | 既製の選択肢では対応できないエンタープライズのデータフロー |
この3つはいずれも、内部的にはMetaのWhatsApp Business Platformの上で動いており、つまり3つとも同じ要件を引き継ぐことになります。Metaを通じて認証された専用のビジネス番号(個人のWhatsApp番号は、いったんAPIに載せると再利用できません)、顧客側から始まった24時間ウィンドウの外に送るメッセージのための事前承認済みテンプレート、そしてCRMやコネクターがいくら請求するかに関わらず上乗せされるMeta自体のメッセージ単位の課金です。この3つの方法のどれを選んでも、これらはなくなりません。なぜならそれはCRM側のルールではなく、Meta側のルールだからです。そもそもAPIが正しい出発点かどうか確信が持てない場合は、WhatsApp CRMに公式のWhatsApp Business APIは必要かを参照してください。
上記のすべての方法は、すでに運用しているCRMにWhatsAppを接続することがゴールだという前提に立っています。The Chat Quotientは違う前提から出発します。WhatsAppを別のCRMに配線する代わりに、CRMの機能をChrome拡張機能としてWhatsApp Webの中に直接組み込むのです。接続すべき外部のものが存在しないため、構築すべき連携もそもそもありません。
つまり、その裏側にMeta Business Platformへの申請も、BSPとの関係も、テンプレート承認の待ち行列も存在しないということです。リードやフォローアップ、メモは複数同時に運用できるビジュアルなカンバンパイプライン上で管理され、キャンペーン配信はMetaのテンプレートシステムを介さず、1日あたりの上限の範囲内でランダム化された間隔で送信されます。そして自社の情報をもとに設定したAIエージェントが、引き継ぐ準備が整うまでリードとの会話を進めることができます。返信の面では、自社のナレッジベースから引き出されたAIによる返信案とワンクリックのチャット要約が、すでに使っているメッセージ入力欄にそのまま表示されます。
The Chat Quotientは、Zoho、HubSpot、Salesforce、その他どのCRMのプラグインでもなく、それらと同期することもありません。これが向いているのは、WhatsAppの使い方に「CRM型の穴」が空いていることが本当の課題であるチームであり、すでにあらゆる場面で頼っているCRMに「WhatsApp型の穴」が空いているチームではありません。もし後者の説明の方が自分のチームに当てはまるなら、上記3つの方法のいずれかが依然として正解であり、すでにフルCRMを通じて回っているワークフローにブラウザ拡張機能を無理やり組み込もうとするよりも、ネイティブ連携やよく選ばれたコネクターアプリの方がうまく機能するはずです。
CRMにすでにWhatsAppが組み込まれていて、それが必要な範囲をカバーしているなら、それを使いましょう。すでに機能しているネイティブ機能の上に、コネクターやカスタム構築を追加する理由はありません。組み込まれておらず、割ける開発者の時間もない場合は、チェーンにもう1つベンダーが加わることを受け入れたうえで、マーケットプレイスのコネクターがより速く安価な選択肢になります。カスタムAPI構築に手を伸ばすべきなのは、既製の選択肢では本当に対応できない特定のデータフローがあり、なおかつその後もメンテナンスできる社内体制がある場合に限られます。そして、すでに導入しているCRMスタックにWhatsAppを正式に統合することよりも、単にWhatsAppの会話を見失わないようにしたいというのが本当の目的であるなら、そもそもその連携が必要かどうかを問い直す価値があります。
WhatsAppをCRMと連携する最も速い方法は? CRMにすでにネイティブ連携があるなら、それが最速です。実質的な待ち時間はMeta自身のビジネスおよび番号認証(24〜72時間)だけだからです。ミドルウェアコネクターがそのすぐ後に続きます。カスタムAPI構築は最も遅く、通常は数週間かかります。
3つの方法はすべてWhatsApp Business APIを必要としますか? はい。ネイティブ連携、ミドルウェアコネクター、カスタム構築のいずれも、内部的にはMetaのWhatsApp Business Platformを介して接続されているため、3つとも専用の認証済み番号と、24時間の返信ウィンドウ外に送るメッセージのための事前承認済みテンプレートを必要とします。
これらの連携方法のいずれかで、個人のWhatsApp番号を使うことはできますか? いいえ。ネイティブCRM連携、コネクター、カスタム構築のいずれを通じてであっても、いったん番号がWhatsApp Business APIに接続されると、通常のWhatsApp一般利用者向けアプリでは同時に使えなくなります。
ZapierのようなミドルウェアコネクターはWhatsAppとCRMの同期に信頼できますか? 機能はしますが、目的特化型の連携ではなくチェーンにもう1つ加わったベンダーであるため、ネイティブチャネルや専用のマーケットプレイスアプリに比べて、自動化が静かに壊れやすい傾向があります。
The Chat Quotientは既存のCRMと連携しますか? いいえ。WhatsApp Web自体の中で動作するスタンドアロンのWhatsApp CRMであり、Zoho、HubSpot、Salesforce、その他どのCRMのコネクターやプラグインでもありません。別のCRMの連携機能を通じてWhatsAppを運用することの代替として作られたものであり、そこへの橋渡し役ではありません。
「WhatsAppをCRMと連携する」という言葉は、ベンダーがすでに用意した設定の切り替えを指すこともあれば、2つの別々のツールを橋渡しするコネクターアプリを指すことも、カスタムコーディングされたAPI構築を指すこともあり、どれが正解かはCRMがすでに何を提供しているかと、割ける開発者の時間次第です。この3つはいずれも、MetaのWhatsApp Business Platformとそのルールの上で動いていることに変わりありません。もし本当のゴールが、すでに全面的に頼っているCRMを拡張することではなく、WhatsAppの会話を整理することであるなら、The Chat Quotientのようなスタンドアロンのツールは別の問いに答えます。それは、WhatsAppをどうやってCRMに接続するかではなく、そもそも接続する必要があるのか、という問いです。
Chrome拡張機能を追加して、ビジネスのWhatsApp会話管理の方法を変革しましょう。
