More in
Chat Funnel 構築ガイド
WhatsApp Business API と CRM の連携(実践的なセットアップ)
4月 18, 2026 · Currently reading
Click-to-WhatsApp 広告キャンペーン:セットアップから初回コンバージョンまで
4月 18, 2026
購買担当者を不快にさせない会話型資格審査の質問設計
4月 18, 2026
高単価 B2B 向け Chat Funnel の設計(EC 向けではない)
4月 18, 2026
AI エージェントが失敗したときのフォールバックフロー設定
4月 18, 2026
チームを疲弊させずに 24 時間 365 日稼働する Chat Funnel の構築
4月 18, 2026
Chat Funnel の A/B テスト:何をどのようにテストするか
4月 18, 2026
EU 購買担当者向け GDPR 準拠の Chat Funnel
4月 18, 2026
Chat Funnel パフォーマンスの測定:本当に重要な指標
4月 9, 2026
チャットで獲得した Lead の自動ルーティング設定
4月 7, 2026
WhatsApp Business APIとCRMの統合(実際に動く設定方法)
これは非常に頭を悩ませる現実です。WhatsAppの会話が流れ始め、担当者が返信し、Leadが関心を示します。ところが、そのコンタクトの40%がCRMに一切現れません。技術的な制限ではなく、静かに失敗する形で統合が誤設定されているためです。
あるB2B SaaS企業のRevOpsマネージャーは、WhatsAppのレポートとHubSpotを照合したときにこれを発見しました。差異は実在し、2ヶ月間蓄積されていました。どの経路にいるか、何が誤設定されているかを特定してからは、修正に半日もかかりませんでした。
このガイドでは、ManyChat → HubSpot、Respond.io → HubSpot、webhook-to-any-CRMの3つの主要な統合設定と、それぞれで必要なフィールドマッピング、重複排除ロジック、UTMアトリビューションの手順を解説します。
統合経路の選択
設定を触る前に、経路を選びましょう。判断の基準は既存のツールスタックとCRMです。MetaのWhatsApp Business Platform公式ドキュメントによると、Business APIは異なるメッセージング機能を持つ3つの認証ティアをサポートしており、統合経路によってどのティアが適用されるかが決まります。どのチャットプラットフォームがワークフローに合うか検討中の場合は、B2B営業向けRespond.io対ManyChatの比較でトレードオフを整理しています。
| 経路 | 最適な状況 | 技術要件 | 同期の深さ |
|---|---|---|---|
| ManyChat → HubSpot | フローにManyChatを使用しているチーム | 低(ネイティブコネクタ) | コンタクト + カスタムプロパティ |
| Respond.io → HubSpot | Respond.ioをメインinboxとして使用しているチーム | 低(ネイティブコネクタ) | コンタクト + ライフサイクルステージ + 会話履歴 |
| Webhook → Any CRM | Salesforce、Pipedrive、カスタムCRM | 中(ZapierまたはMake必要) | webhookペイロード経由で設定可能 |
HubSpotを使用し、ManyChatでフローを積極的に構築している場合は経路Aを選択します。すべてのチャット業務をRespond.ioで行っている場合は、経路Bでより深い同期が得られます。HubSpot以外のCRMをお使いの場合は経路Cが選択肢となります。
経路A: ManyChat → HubSpot
統合の有効化
ManyChatで設定 → インテグレーション → HubSpotに移動します。必要なものは以下の通りです。
- コンタクトアクセス権のあるHubSpotアカウント
- ManyChatの管理者権限
- HubSpot APIキーまたはOAuth接続(OAuthを推奨)
「接続」をクリックし、HubSpot接続を承認して、リンクされたポータルを確認します。
必要なHubSpotの権限
接続するHubSpotユーザーには最低限、コンタクト(表示と編集)、プロパティ(表示)、ワークフロー(表示)の権限が必要です。ManyChatのデータによってトリガーされるHubSpotワークフローを使用する場合は、ワークフロー(編集)も追加します。
コンタクトフィールドのマッピング
ManyChatのサブスクライバーデータはHubSpotのコンタクトプロパティにマッピングされます。デフォルトのマッピングとカスタマイズが必要な箇所を以下に示します。
| ManyChatフィールド | HubSpotプロパティ | 備考 |
|---|---|---|
| First Name | firstname | 自動マッピング |
| Last Name | lastname | 自動マッピング |
| Phone | phone | プライマリ電話にマッピング(E.164フォーマットに注意) |
| フローで収集した場合のみ存在 | ||
| カスタム属性: company_size | company_size(カスタム) | HubSpotで事前にプロパティを作成する必要あり |
| カスタム属性: industry | industry | 標準HubSpotプロパティにマッピング |
| カスタム属性: use_case | hs_lead_status(カスタム) | このためのカスタムフィールドを作成 |
| フローソース(広告ID) | hs_analytics_source | UTMパススルーの設定が必要 |
カスタム属性をマッピングするには、ManyChat → インテグレーション → HubSpot → フィールドマッピングに移動し、新しい行を追加します。HubSpotのプロパティは、マッピングする前に存在していなければなりません。まずHubSpotのコンタクト → プロパティで作成してください。
コンタクトオーナーの割り当て
ManyChatはラウンドロビンまたは固定オーナーに基づいてHubSpotコンタクトオーナーを割り当てられます。HubSpotインテグレーション設定 → デフォルトオーナーで設定します。テリトリーベースのルーティングを行っているチームでは、コンタクト作成時にトリガーされるHubSpotワークフローを使用して、企業または地域に基づいて再割り当てする必要があります。
同期されるものとされないもの
ManyChatはコンタクトプロパティを同期し、オプションで会話サマリーをメモとしてプッシュします。ネイティブではHubSpotに完全な会話トランスクリプトは同期されません。会話履歴が必要な場合は経路Bまたはwebhookの回避策が必要です。
また、すべてのメッセージに対してリアルタイムでコンタクトの更新がプッシュされるわけではありません。フロー内の特定のイベント(通常はopt-inまたはフローステップがHubSpotアクションを実行したとき)でトリガーされます。
経路B: Respond.io → HubSpot
Respond.ioのネイティブHubSpotモジュールで接続
Respond.ioで設定 → インテグレーション → HubSpotに移動します。OAuthで認証します。初期接続にはHubSpotの管理者アカウントが必要です。
接続後、Respond.ioは双方向同期を作成します。Respond.ioで作成されたコンタクトはHubSpotに表示され、既存のHubSpotコンタクトはRespond.ioの会話にプルできます。
ライフサイクルステージのマッピング
Respond.ioは会話イベントに基づいてHubSpotのライフサイクルステージを更新できます。HubSpotインテグレーション設定で以下を設定します。
- WhatsAppからの新規コンタクト → Lead
- クオリフィケーション質問の完了 → Marketing Qualified Lead
- ミーティング予約 → Sales Qualified Lead
これらのマッピングは、フローの該当ステップが完了したときに自動的に発火するよう設定します。
電話番号によるコンタクト重複排除
Respond.ioはHubSpotに同期する際、電話番号を主要な重複排除キーとして使用します。HubSpotに同じE.164フォーマットの電話番号を持つコンタクトが既に存在する場合、Respond.ioは重複を作成せず、既存のレコードを更新します。
注意点として、電話番号のフォーマットは完全に一致している必要があります。HubSpotが「+1 (555) 000-0000」を保持し、Respond.ioが「+15550000000」を送信した場合、重複排除は機能しません。両システムで電話番号をE.164フォーマットに標準化してください。HubSpotでは、「電話番号のフォーマット」アクションを使用したワークフローで既存のレコードを正規化できます。
会話履歴の同期オプション
Respond.ioはコンタクトレコードのメモとして会話履歴をHubSpotにプッシュできます。HubSpotインテグレーション → 同期オプション → 会話のログで有効化します。各会話は完全なやり取りを含むタイムスタンプ付きのメモになります。
これは、チャット経由のLeadに電話する前に担当者がコンテキストを確認したいチームにとって、経路Aに対する経路Bの最大の利点です。
経路C: Webhookから任意のCRMへ
Respond.ioのWebhookペイロードの構成
Respond.ioは会話イベント(新規コンタクト、メッセージ受信、フローステップ完了)によってトリガーされるアウトバウンドwebhookをサポートします。設定 → デベロッパー → Webhooksで設定します。
コンタクトがクオリフィケーションフローステップを完了したときのサンプルペイロードは以下の通りです。
{
"event": "contact.updated",
"contact": {
"id": "abc123",
"phone": "+15550001234",
"firstName": "Jane",
"lastName": "Chen",
"customAttributes": {
"company_size": "50-200",
"use_case": "sales_automation",
"timeline": "Q2_2026",
"source_ad_id": "23849572894"
},
"createdAt": "2026-04-18T09:32:00Z",
"optInTimestamp": "2026-04-18T09:31:47Z"
},
"conversation": {
"id": "conv_xyz789",
"channel": "whatsapp"
}
}
ZapierまたはMakeのZapの構築
Zapierの場合:
- トリガー: Webhooks by Zapier → Catch Hook
- webhook URLをRespond.ioにコピー
- サンプルデータを生成するためにテストコンタクトをフローに通す
- アクション: CRMでコンタクトを作成または更新
- webhookペイロードからCRMフィールドにフィールドをマッピング
- フィルターステップを追加:
phoneが空でない場合のみ処理を続行
Make(旧Integromat)の場合は、WebhooksモジュールをトリガーとしてCRMのコンタクト作成/更新モジュールにルーティングします。
電話番号フォーマットの問題への対処
WhatsAppは常にE.164フォーマットで電話番号を送信します。ほとんどのCRMはE.164を受け入れますが、Salesforceなど一部のCRMにはローカルフォーマットの要件があります。CRMアクションが実行される前に、国番号プレフィックスを取り除くか必要なフォーマットに変換するテキストフォーマッターステップをZapier/Makeに追加してください。
UTMとソースアトリビューション
MetaのADからコンタクトがWhatsApp funnelに流入する際、ハンドオフが正しく設定されている場合に限り、広告ソースデータが一緒に届きます。このアトリビューションパイプラインに繋がる広告設定の詳細については、Click-to-WhatsApp広告キャンペーンのガイドをご参照ください。
MetaはClick-to-WhatsApp広告から会話が開始されるときにad_idとcampaign_idパラメータを渡します。Respond.ioはこれらを会話メタデータに自動的にキャプチャします。ManyChatはフローにMetaの広告ソースステップを追加している場合、User Input変数としてキャプチャします。
CRMでキャンペーンレベルのアトリビューションを得るには:
- ad_id、ad_set_id、campaign_idをチャットプラットフォームのカスタム属性として保存します
- CRMへのフィールドマッピングまたはwebhookペイロードに含めます
- campaign_idにマッピングした「WhatsApp Campaign Source」というHubSpotカスタムプロパティを作成します
- 「WhatsApp Campaign Source」でフィルタリングしたHubSpotレポートを構築してキャンペーン別のPipelineを確認します
これにより、サードパーティのアトリビューションツールを使わずに、キャンペーンからPipelineまでのシンプルなビューが得られます。
重複排除のルール
同じ電話番号が複数回funnelに流入する場合(リターゲティングキャンペーンでは一般的)、統合には明確なルールが必要です。これはマルチチャネルLeadの重複排除で複数チャネルからコンタクトが同時に流入する場合にも特に重要です。
優先順位:
- まず電話番号で照合(E.164正規化済み)
- 一致が見つかった場合: 既存レコードを更新し、新規作成しない
- 一致が見つからない場合: 新規コンタクトを作成し、新規Leadとしてフラグを立てる
- 電話番号は一致するがメールが異なる場合: 既存レコードにメールがない場合のみメールを更新する
HubSpotのネイティブな重複排除はデフォルトではメールのみを照合します。電話番号による重複排除には、HubSpotワークフローを使用します。コンタクト作成をトリガーとし、電話番号で既存コンタクトを検索し、見つかった場合はカスタムコードステップまたはDedupely等のサードパーティ重複排除アプリを使用してレコードをマージします。
Salesforceでは、設定 → 重複管理の下で、Phoneフィールドの照合ルールを含む重複排除ルールを使用します。GartnerによるCRMデータ品質の調査によると、データ品質の低さは組織に年間平均1,290万ドルのコストをもたらします。電話番号の重複排除は最もコスト効率の高い対策のひとつです。
統合のテスト
本番稼働前に、この6ステップのシーケンスを実行してください。
- テスト用電話番号を使用してWhatsAppフローの全体を自分で通過する
- チャットプラットフォーム(ManyChat/Respond.io)で、すべてのカスタム属性が入力された状態でコンタクトが作成されたことを確認する
- 2から3分待った後、CRMで一致する電話番号を持つ新規コンタクトを確認する
- マッピングされた各フィールドが正しい値で届いていることを確認する(特にカスタム属性)
- コンタクトオーナーが正しく割り当てられていることを確認する
- 同じ電話番号で2回目のテストを送信し、重複排除を確認する(重複作成ではなく更新)
ステップ3が失敗した場合: まず統合の接続ステータスを確認し、次にチャットプラットフォームのイベントログで同期エラーを確認してください。
ステップ4でカスタム属性が欠けて失敗した場合: フロー中に属性が入力されたかを確認し(ManyChat/Respond.ioでコンタクトレコードを確認)、フィールドマッピングが正しく設定されているか確認してください。
よくある落とし穴
電話番号フォーマットの不一致。 最も一般的な障害原因です。マッピングを構築する前に、すべての箇所でE.164に正規化してください。EU購買者向けGDPR準拠のchat funnelでは、コンタクトがEU在住の場合の電話番号保存に関する追加要件を説明しています。
opt-inタイムスタンプの欠落。 GDPRとWhatsApp Business Policyの規定はいずれも、ユーザーがopt-inした日時の記録を義務付けています。後から追加するのではなく、初日からCRMフィールドとしてopt-inタイムスタンプを保存してください。
メールなしのレコードをCRMがブロックする。 HubSpotとSalesforceはコンタクト作成時にメールを必須として設定できます。WhatsAppのコンタクトは多くの場合メールが収集されていません。チャット経由コンタクトのメール必須要件を削除するか、フローステップとしてメールを収集してください。
HubSpotプロパティタイプの競合。 ManyChatのテキスト属性をHubSpotの数値プロパティにマッピングすると、同期は静かに失敗します。プロパティタイプを正確に一致させてください。テキストはテキストに、数値は数値に、ドロップダウンはドロップダウンに対応させます。
次にすべきこと
統合が正常に動作することを確認したら、「WhatsApp Campaign Sourceが空でない」でフィルタリングしたCRMビューを構築します。このビューと堅実なCRMデータモデル設計を組み合わせることで、カスタムチャットプロパティを一貫したスキーマに整理できます。これがチャット経由のPipelineを追跡するための継続的なビューになります。他のLeadソースと週次で比較して、このチャネルの貢献度を確認しましょう。
次に、アトリビューションを収益に結びつけましょう。チャット経由のLeadがクローズしたとき、そのディールに元のキャンペーンソースをタグ付けします。60日後には、単に会話を生み出すだけでなく、クローズされた収益をもたらすキャンペーンに向けて広告費を最適化するのに十分なデータが揃います。
関連記事

Principal Product Marketing Strategist
On this page
- 統合経路の選択
- 経路A: ManyChat → HubSpot
- 統合の有効化
- 必要なHubSpotの権限
- コンタクトフィールドのマッピング
- コンタクトオーナーの割り当て
- 同期されるものとされないもの
- 経路B: Respond.io → HubSpot
- Respond.ioのネイティブHubSpotモジュールで接続
- ライフサイクルステージのマッピング
- 電話番号によるコンタクト重複排除
- 会話履歴の同期オプション
- 経路C: Webhookから任意のCRMへ
- Respond.ioのWebhookペイロードの構成
- ZapierまたはMakeのZapの構築
- 電話番号フォーマットの問題への対処
- UTMとソースアトリビューション
- 重複排除のルール
- 統合のテスト
- よくある落とし穴
- 次にすべきこと
- 関連記事