Skip to main content

AIボイスエージェントのコールトラッキング:アトリビューションから売上へ

従来のコールトラッキングは着信数を数えるだけ。AIエージェントが応対すれば、意図・見込み度・通話結果、そしてCRM上の売上まで追えます。どの広告が電話を鳴らしたか、だけではありません。

Digvijay Singh Shekhawat
Digvijay Singh Shekhawat
July 26, 2026
1 min read
クリーム色の受話器が金色のらせん状コードで大理石の円盤を積み重ねたものにつながり、その脇に緑色のアーチが並ぶ

コールトラッキングとは、かかってきた電話を、その電話を生んだマーケティング施策までさかのぼって紐づける取り組みです。発信する直前に相手が見ていたキャンペーン、キーワード、ページを特定します。ウェブフォームならアトリビューションは自動で成立しますが、電話ではそうはいきません。だからこそ、最も売上を締めているチャネルが、最も過小に報告されがちなのです。

コールトラッキングの解説記事はたいてい同じことを約束します。キャンペーンごとに専用番号を割り当て、UTMを取得すれば、どの広告が電話を鳴らしたのかがついに分かる、と。これは本物の価値です。電話はウェブ経由のリードに比べて10〜15倍の確率で成約し、それを紐づけられなければ、その売上はダッシュボード上で説明のつかない急増として現れるだけになります。

しかし、誰も口にしない限界があります。従来のコールトラッキングは着信音で止まるのです。電話があったこと、どこから来たことは分かります。しかしその通話が何であったかは何も分かりません。意図はどうか、見込み客として条件を満たしていたか、何が解決したのか、商談につながったのか。人が受話器を取った瞬間にデータの足跡は途切れ、誰かがメモを残すことを思い出すまで真っ暗になります。

AIボイスエージェントが応対すれば、その足跡は途切れません。エージェント自体が記録システムそのものだからです。通話の結果をまるごと構造化し、そのままCRMへ書き込みます。本記事では、着信数を数える段階から、取得した結果を追う段階へどう移行するか、そしてどう構築するかを解説します。

コールトラッキングが測れるもの(と、その限界)

従来のインバウンド向けコールトラッキングは、次の3つをうまくこなします。

  • 流入元アトリビューション — チャネルごとの専用トラッキング番号(Google Ads、Facebook、ダイレクトメール、あの屋外看板)によって、すべての着信をきっかけとなった施策に紐づけます。
  • ダイナミック・ナンバー・インサーション(DNI) — サイト上の電話番号を訪問セッションごとに差し替えるため、チャネル単位だけでなくキーワード単位・セッション単位のアトリビューションが得られます。
  • 通話メタデータ — 通話時間、時間帯、発信者番号、初回か再架電か、録音

ほとんどのツールでは、製品としてはここまでです。逆に分からないのは次の点です。

  • 電話をかけてきたのは有望な買い手だったのか、それとも営業時間を確認しただけの人だったのか。
  • その人は実際に何を求めていたのか。
  • 用件は解決したのか、それとも留守番電話に流れたのか。
  • CRM上に商談が生まれたのか、そしてその商談は受注に至ったのか。

結果としてマーケティングは、唯一目に見える数字である着信件数を最適化する一方で、売上を予測できる指標は会話の中に閉じ込められたままになります。意図の薄い着信を大量に生むキャンペーンに予算を注ぎ、件数は少なくても価値の高い着信を生むキャンペーンを飢えさせることになるのです。

着信件数から取得した結果へ:AIが加えるもの

AIエージェントは会話そのものを担うため、リアルタイムで内容を構造化できます。すべての通話が、後から誰かが聞き直す録音ではなく、次のような構造化フィールドのレコードを生み出します。

項目従来のトラッキングAIエージェントによる結果トラッキング
流入元/キャンペーン✅ (番号/DNI)✅ (番号/DNI)
発信者の意図✅ 通話中に自動分類
見込み度判定(BANT/ICP)✅ 通話中にスコアリング
通話結果⚠️ 手入力のメモ✅ 構造化された列挙値
CRMへのレコード書き込み⚠️ 手作業✅ 自動・リアルタイム
結果 → 売上のひも付け✅ 商談+金額

変わるのはこの点です。電話があったことを測るのをやめ、その電話が何を生んだかを測り始める。キャンペーンの成果は「今週142件の着信」ではなく、「142件の着信、うち61件が有望、18件がデモ予約、影響を与えた商談パイプライン24万ドル」になります。これはCFOが予算を付けられる数字です。

VoIPとCRMの連携:構造化された通話結果を書き込む

VoIPとCRMの連携の多くは、まさにここで静かに失敗します。Bland自身の連携ガイドもこの数字を引いています。BtoB向けSaaSの連携はおよそ60%が失敗し、その原因はたいてい一方向の同期にあります。通話は記録として残るものの、そこで得られた情報がCRMへ戻ってワークフローを起動することがないのです。

本来の連携は双方向で、かつ構造化されています。Finnのエージェントは通話を終えると、次のように書き込みます。

{
  "contact": { "phone": "+14155550142", "match_strategy": "e164_normalized" },
  "source": { "campaign": "google/brand", "utm": "spring-promo", "gclid": "..." },
  "intent": "pricing_inquiry",
  "qualified": true,
  "disposition": "booked_demo",
  "crm": { "object": "opportunity", "stage": "SQL", "amount_est": 12000 },
  "transcript_url": "...",
  "next_action": "sdr_followup_24h"
}

従来の構成が壊れるところで、これが機能する理由は2つあります。

  1. 現実に耐える連絡先マッチング。 E.164 形式への正規化、1件の連絡先に複数の番号、国際表記への対応。マッチングが甘いと重複レコードが生まれたり、通話中に空白の画面が表示されたりします。CRMへの信頼を壊す最大の要因です。エージェントは書き込む前に連絡先を特定します。
  2. 自由記述ではなく列挙値。 通話結果は固定された語彙(booked_demoqualified_no_fitcallback_requestedspam)なので、そのまま集計できます。自由記述のメモではそうはいきません。

書き込みが通話終了と同時に行われるため、購買シグナルがリアルタイムでワークフローを動かします。booked_demo なら SDR 向けのタスクが立ち、qualified_no_fit ならリターゲティングの配信費用を止められます。

着信ではなく売上に結びつくアトリビューション

ここでループが閉じます。流入元のデータ(キャンペーン、UTM、gclid )と結果のデータ(見込み度、通話結果、商談、金額)が同じCRMレコード上に載るからです。アトリビューションは「どの広告が電話を生んだか」ではなく、「どの広告が取得できた売上を生んだか」に変わります。

具体的には、次の問いに答えられるようになります。

  • キャンペーン別の有望な着信1件あたりのコスト。単なるコール単価ではありません。
  • デモにつながるキーワードと、営業時間や道順の問い合わせにしかつながらないキーワードの区別。
  • 電話を起点として各チャネルに帰属する商談パイプラインと受注金額。

具体例を挙げます。2つのキャンペーンがそれぞれ100件の着信を、1件あたり50ドルで獲得したとします。従来のトラッキングでは両者は同等です。結果トラッキングで見ると、キャンペーンAは有望40件・デモ12件、キャンペーンBは有望8件・デモ1件でした。着信数は同じでも、取得した価値は12倍です。レコード上に構造化された結果がなければ、この差は決して見えません。

導入手順:番号の払い出し、流入元の取得、CRMへのマッピング

実務的な展開は次の4ステップです。

  1. トラッキング番号を払い出す。 キャンペーン/チャネルごとに1本、加えてセッション単位のアトリビューション用にサイトへDNIを設定します。すべての番号をAIエージェントに向けます。
  2. 接続時に流入元を取得する。 キャンペーン、UTM、gclid を通話メタデータとして渡し、開始0秒の時点でレコードに載せます。後から復元しようとしないことです。
  3. 通話結果のスキーマを定義する。 実際の結果を網羅する6〜10個の列挙値を用意します。ここが最も影響の大きい判断です。いい加減な列挙値は集計できないデータを意味します。それぞれをCRMのステージに対応づけましょう。
  4. 項目をCRMオブジェクトにマッピングする。 何を取引先担当者に、何をリードに、何を商談に書き込むかを決め、マッチングキー(正規化した電話番号、補助としてメールアドレス)を設定し、通話結果をワークフローに接続します。

最初の2週間は突合レポートで検証してください。1件の通話につきCRMへの書き込みはちょうど1件、しかも正しく紐づいているはずです。件数がずれるようなら、アトリビューションを信頼する前にマッチングを直しましょう。

Finnを使うべきでない場合

正直に書いておきます。インバウンドコールが本当に単純で件数も少なく、1日に数件、人がすぐ出られて記録も手間にならないのであれば、AIエージェントは過剰な作り込みです。また、どの広告が電話を鳴らしたかさえ分かればよく、結果を書き込むCRMも持っていないのなら、従来型のコールトラッキングツール(CallRailなど)のほうが安く、それで十分です。Finnが真価を発揮するのは、着信件数が多く、かつ結果データを取る価値がある場合です。つまり「電話があった」と「売上が立った」の隔たりが、実際の予算判断に実害を及ぼしているときです。

よくある質問

AIエージェントはコールトラッキングツールの代わりになりますか。 代わるのは結果の側だけです。流入元アトリビューションのためのトラッキング番号の払い出しとDNIはこれまでどおり必要で、エージェントはその上に意図、見込み度、通話結果、CRMへの書き込みを積み上げます。

既存のCRM連絡先とはどう突き合わせるのですか。 E.164 で正規化した電話番号を主キーとし、メールアドレスや氏名を補助として、レコードを書き込む前に特定します。そのため、再度かけてきた相手が重複レコードになることはありません。

HubSpotやSalesforceに直接書き込めますか。 はい。通話結果を各製品のオブジェクトとステージに対応づけます。書き込みはリアルタイムで走るため、ワークフローは夜間バッチではなく通話そのものをきっかけに動きます。

通話分析ツールとは何が違うのですか。 分析ツールは録音をもとに事後的に通話を採点します。AIエージェントは通話の最中に結果を構造化し、その場で書き込みます。レビュー待ちの行列は発生しません。

着信音ではなく、結果を追う

コールトラッキングは、着信音までのアトリビューションをもたらしました。Finnがもたらすのは、取得した売上までのアトリビューションです。すべての通話が分類され、見込み度を判定され、通話結果を付与され、リアルタイムでCRMに書き込まれます。FinnとCRMの連携をご覧ください →


関連記事:

Digvijay Singh Shekhawat
Digvijay Singh Shekhawat

創業者、Finn AI

Digvijayは Finn を開発しています。通話の内容を推論し、データを抽出し、システムをリアルタイムで更新する、エンタープライズ向けの音声オーケストレーション層です。音声AI、市場開拓(Go-to-Market)、そして自律型エージェントを大規模に提供するために必要なことについて執筆しています。

AIボイスエージェントのコールトラッキング:アトリビューションから売上へ — Finn