CRMと音声AIの連携ワークフローを専門用語なしで解説

CRMとAI音声エージェントの連携は、4つの受け渡しに集約されます。CRMが誰に電話をかけるかを決めます。発信リクエストが、エージェントに必要な情報を運びます。エージェントが会話を行います。そして結果が同じCRMレコードに戻ります。連携に関する混乱の多くは、この4つを混同したり、それぞれをどのシステムが担うのかを把握していなかったりすることから生じます。

本ガイドでは、HubSpotのワークフローを例にこの流れを順を追って説明し、続いてWebhookを送信できるあらゆるCRMで同じループを実現する方法を紹介します。

CRMと音声AIの連携ワークフローの4つのステージとは？

トリガー、コンテキスト、会話、書き戻しの4つです。

1. トリガー。CRMのイベント（フォーム入力、取引ステージの変更、特定の日付への到達など）がワークフローを開始し、音声プラットフォームに発信を依頼します。
2. コンテキスト。発信リクエストにはCRMレコードのデータが含まれるため、エージェントはコンタクトの名前や状況をあらかじめ把握した状態で通話を始められます。
3. 会話。エージェントが会話を行い、その間にCRMレコードを参照・更新することもできます。
4. 書き戻し。通話後、要約、構造化された結果フィールド、文字起こし、録音がCRMレコードに添付され、次に何をするかはCRMのワークフローが判断します。

CRMからAI通話を実際に起動するものは何か？

CRMワークフローが通話を起動する方法は2つあります。ネイティブのワークフローアクションか、自社のサービスがAPI呼び出しに変換するWebhookです。

ネイティブアクション（HubSpot）。HubSpot MarketplaceのRetell AIアプリを導入すると、HubSpotのワークフローにMake a Phone Callアクションが追加されます。フォーム送信、新規レコード、取引ステージの変更、予約日などの日付プロパティといった、すでに使用しているトリガーから始めましょう。「Phone number is known」条件を追加して、電話番号のないコンタクトが登録されないようにします。次に、アクションの3つのフィールドを入力します。From（Retellのエージェントと電話番号）、To（コンタクトの電話番号トークン）、そして任意でJSON形式のDynamic Variablesです。ワークフローは通話が終了するまで一時停止します。

Webhook＋API（あらゆるCRM）。CRMのワークフローからWebhookを送信できる場合は、その送信先を自社で管理する小さなサービスに設定します。そのサービスがRetellのCreate Phone Call APIを呼び出し、4つの情報を渡します。from_number、to_number、retell_llm_dynamic_variables内のコンテキストフィールド、そしてmetadata内のCRMレコードIDです。Retellはmetadataを通話とともに保存し、以降のWebhookで通話オブジェクトに含めて返します。これにより、結果が正しいレコードに戻る仕組みです。

イベントではなくリストを使う場合。単一のイベントではなくセグメントを対象にキャンペーンを行う場合は、リストをエクスポートして一括発信（バッチコール）として実行します。電話番号の列を含むCSVを用意すれば、追加の列はすべてエージェントが使える変数になります。

どの方法でも2つの前提条件があります。発信元の番号にアウトバウンドエージェントが紐づいていること、そして発信先の番号が有効なE.164形式（例：+14155550123）であることです。

エージェントはどうやって通話相手を把握するのか？

Dynamic Variables（動的変数）によってです。これは{{first_name}}や{{deal_stage}}のような名前付きの値で、エージェントが話し始める前にRetellが値を埋め込みます。値の取得元は3つあります。

• 発信リクエスト。HubSpotアクションのJSONやAPI呼び出しでretell_llm_dynamic_variablesに渡した値です。
• 同期されたコンタクトフィールド。RetellのネイティブCRMコンタクト同期を利用している場合、番号が同期済みコンタクトと一致する通話では、そのコンタクトのマッピング済みフィールドが自動的に変数として渡されます。
• 通話前の検索。エージェントのWorkflowページで設定する通話前関数により、CRMでその番号を検索し、レスポンスのフィールドを変数にマッピングできます。アウトバウンド通話では、Retellが発信する前に実行されるため、コンタクトが検索処理を耳にすることはありません。

同じ名前の変数が複数の取得元から来た場合、リクエストの値が同期済みコンタクトフィールドより優先され、通話中にエージェントが収集した値はその両方より優先されます。

エージェントがプレースホルダーをそのまま読み上げてしまうケースの大半は、次の3つのルールで防げます。

• すべての値を文字列として送信します。42やtrueではなく、"42"や"true"とします。
• オブジェクトはフラット化します。{{client.name}}は解決されないため、代わりにclient_nameを送信します。
• エージェントレベルのデフォルト値を設定します。値のない変数は、prompt内で{{braces}}の形のまま残ります。

通話中には何が起きるのか？

エージェントはpromptと変数に基づいて会話を進め、ツールを与えておけば通話中にCRMを操作することもできます。

RetellのネイティブインテグレーションでHubSpotを接続している場合、エージェントは会話中にSearch Contact、List Contact Deals、Update Deal、Update Contact、Create Taskなどのツールを使用できます。コンタクトが伝えたばかりのメールアドレスを修正したり、コンタクトが合意したフォローアップタスクを作成したりできます。ネイティブ連携のないCRMでは、カスタム関数で自社のAPIを通話中に呼び出すことで、同じ処理を実現できます。

想定しておくべき動作が2つあります。CRMツールの呼び出しが失敗またはタイムアウトしても会話は継続するため、検索結果が空だった場合に何を話すべきかをpromptで指示しておく必要があります。また、アウトバウンド通話が本人ではなく留守番電話につながった場合、エージェントは設定に応じて電話を切るかメッセージを残し、その通話にはin_voicemailフラグが付きます。このフラグは書き戻しの段階で重要になります。

通話結果はどのようにCRMレコードに戻るのか？

通話終了後、Retellは文字起こしに対して通話後分析を実行します（製品上はPost Call Extractionと呼ばれます）。その結果は、CRMが対応している方式とマッピングロジックをどちらが担うべきかに応じて、3つの経路のいずれかでCRMに届きます。

生成されるデータ。すべての通話にcall_summary、user_sentiment、call_successful、in_voicemailが付与されます。独自の結果を記録するカスタムフィールドも追加でき、それぞれboolean、text、number、selectorのいずれかの型を指定します。例：qualified、budget_range、callback_requested。通話レコードには、完全な文字起こしと録音URLも含まれます。フィールドの定義方法については通話後分析をご覧ください。

経路1：HubSpot Marketplaceアプリ。通話が完了すると、アプリは要約と分析結果をコンタクトのアクティビティタイムラインに書き込み、録音と文字起こしを通話ログに格納し、そのログを関連する会社のタイムラインにも表示します。その後、一時停止していたワークフローが再開し、Call Success、User Sentiment、Call Outcomeなどの出力に基づいて分岐できます。成功時にはフォローアップメール、応答がない場合は再発信やSMS、といった具合です。

経路2：ネイティブCRM連携。RetellのHubSpot、Salesforce、Microsoft Dynamics 365、GoHighLevel、Zoho CRMとの連携では、通話後分析のフィールドをコンタクトフィールドにマッピングし、CRMレコードに反映します。各マッピングには更新モードがあります。ステータスフィールドにはOverwrite、メールアドレスのように変わらない情報にはFill only if empty、複数の通話にわたるメモを統合するにはAccumulate & summarizeを使います。Log activities automaticallyを有効にすると、各通話がコンタクトにも記録されます。たとえばHubSpotではCall engagementとして、SalesforceではTaskとして記録されます。通話後関数を使えば、followup_neededフィールドがtrueの場合にのみHubSpotのCreate Taskを実行するなど、対象を絞った書き込みを追加できます。

経路2には注意点が1つあります。書き込み対象は、有効なCRM接続からインポートされたコンタクトのみです。同期済みコンタクトと一致しない番号ではアクティビティレコードが作成されず、Create new contacts in CRMを有効にしない限り、Retellは新しいレコードを作成せず既存のCRMレコードを更新します。

経路3：CRMへのWebhook。Retellは、文字起こし、録音URL、分析結果、トリガー時に送信したmetadataを含む完全な通話オブジェクトとともに、call_analyzedイベントをお使いのendpointに送信します。自社のサービスがmetadataからレコードIDを読み取り、CRMのAPIに書き込みます。x-retell-signatureヘッダーを検証し、10秒以内に2xxを返してください。返さない場合、Retellは最大3回まで再送します。再送によって同じ通話が二重に書き込まれないよう、call_idで重複排除を行います。リッスンするのはcall_endedではなくcall_analyzedです。call_endedのペイロードは分析の実行前に送信されるため、分析結果が含まれていません。

トリガーから書き戻しまでの全体像は？

次の表は、HubSpotの代表的なトリガーと、それに対するエージェントの動作、レコードに書き戻される内容を対応させたものです。Webhook経路でも同じ3列の流れになります。

つながらなかった通話ではカスタム分析フィールドが埋まらないため、応答なしの分岐はカスタムフィールドではなく、組み込みフィールドと通話結果に基づいて構築してください。

本番稼働前に確認すべきことは？

• 登録されるすべてのコンタクトに有効なE.164形式の電話番号があり、それ以外はワークフローで除外されていること。
• CRMの認証情報に、書き戻し対象のすべてのオブジェクトへの書き込み権限があること。HubSpotではスコープが不足していても接続にエラーは表示されず、該当する書き込みだけが機能しなくなります。
• 各カスタム分析フィールドに、LLMが抽出の基準とする具体的な説明があり、対応するCRMプロパティが存在すること。
• 通話後の書き込みに条件が設定されており、つながらなかった通話が誤解を招くデータを書き込まないこと。
• タイムラインへの記録を1つのシステムが担当していること。Marketplaceアプリとネイティブ連携は独立しており同時に動作できるため、どちらで通話を記録するかを決めておきます。
• 発信禁止（Do-not-call）が想定どおりに適用されていること。Retellのdo_not_callコンタクトフィールドだけでは通話はブロックされません。API呼び出しでhonor_internal_dnc: trueを渡すとRetellが発信を拒否します。CRM側の除外ルールもトリガーに残しておきましょう。
• サンドボックスのレコードでテストすること。作成・更新ツールのテストを行うと、実際のレコードが書き込まれます。

まずはここから

HubSpotを基幹システムとして使用している場合、RetellのHubSpot連携がこのループの両方をカバーします。エージェントにコンテキストを渡して結果を書き戻すネイティブ接続と、HubSpotワークフローから発信できるMarketplaceアプリです。プライベートアプリのスコープを含む詳しい設定手順は、HubSpot設定ガイドをご覧ください。Salesforce、Dynamics 365、Zohoなどをお使いの場合は、インテグレーション一覧から始め、掲載されていないCRMにはWebhook経路をご利用ください。

関連記事：アウトバウンド電話番号チェックリスト、初めてのパートナー案件のスコープ設定、その他のガイドはRetell Learnハブでご覧いただけます。