電話の問い合わせが、どの広告から来たか分からない。鳴った電話を自動で数える仕組み（PBX×BigQuery）

サイトに電話番号を載せている会社で、こんな状態になっていないでしょうか。フォーム経由の問い合わせは件数も流入元も見えている。一方で、電話でかかってきたお客様は「だいたい多い気がする」で止まっている。広告のレポートを見ても、電話は数字に乗っていない。

電話が売上の柱になっている業種ほど、この穴は痛いところです。1日に何本も鳴っているのに、その電話がどの広告から来たのか、本当に予約や契約まで進んだのかが分からない。結果、広告の良し悪しを「フォームCVだけ」で判断してしまい、電話で効いている媒体を止めてしまう事故が起きます。

電話を数えること自体は、考え方としては別記事にまとめました。経営目線で全電話を可視化する発想はサイトに眠る電話トラフィックを可視化する戦略で整理しています。本記事はその先、「実際に電話が鳴った」という通話の実績データを、会社の電話交換システムから取り出してデータ基盤に突合する編です。サイトでタップされた回数ではなく、現実に着信した1本1本を数えにいきます。

この記事では、PBX（＝会社の電話交換システム。社内の電話回線をまとめて管理する装置）とBigQuery（＝Googleの大規模データ集計サービス）をつなぎ、サイト掲載番号への電話CVを自動で分類・蓄積する構成を紹介します。何を使えば作れるか、初期構築はどのくらいの規模か、自社でやるべきか外注すべきかを、判断できるところまで書きます。

結論：PBXの通話ログをBigQueryに毎日流し込む4部品で組む

電話CVの自動計測は、次の4つの部品でできあがります。サイトのタップ数を数えるのとは別物で、PBXに残る通話ログ（＝実際の着信記録）を主役に据えるのが肝です。

PBXは多くのIP-PBX製品が通話履歴取得APIを備えている。これを毎日叩いてBigQueryに貯め、顧客DBと突合すれば、「鳴った電話」を新規・既存・予約成立まで分解できます。フォームと違ってユーザーの操作ログに依存しないので、着信の実数を数える精度はタップ計測より一段高くなります（ただし流入元への紐付けは別問題で、後述します）。

ただしこの構成は、レポート自動化のような「半日で作れる軽い処理」ではありません。主役の論点は運用費の安さではなく、初期構築の規模と、止まったときのデータ欠損リスクです。そこを後半でコスト表に分けて書きます。

ビフォーアフター：電話が数字になると何が変わるか

一番効くのは「広告評価に電話が乗る」点です。電話が主戦場の業種では、フォームCVだけ見て予算を組むと判断を誤ります。実際に鳴った電話を媒体別に分解できると、止めるべき広告と伸ばすべき広告が入れ替わることがよくあります。

どんな数字が出てくるか（マスク済みの実例）

抽象的な説明だけだと信用しづらいので、出力イメージを匿名で示します。ある医療系のクライアントで構築した実例を、件数は規模感に丸め、固有情報は伏せています（実数そのものではありません）。

公式サイト掲載番号への着信を、過去30日ぶんで分類すると、こういう内訳になりました。

導入前は「ホームページからの問い合わせ」とひとまとめにされていた数字が、新規・既存・留守録・匿名・予約成立まで割れました。これが電話CV計測の持ち帰りです。媒体別の評価に進む前に、まず「鳴った電話の中身」が事実として見えるようになります。

設計の全体像

処理の流れはこうなります。

```[サイト掲載番号にお客様が架電] ↓[PBX（会社の電話交換システム）に着信ログが残る] ↓[① 目覚まし：毎日深夜に起動] ↓[② 取得役：PBX APIから前日分の通話ログを取得 → BigQueryへ] ↓[③ 仕分け役：BigQuery上で分類] ├─ 転送経由の通話を除外（二重計上防止） ├─ 顧客DBと電話番号で突合（新規 / 既存） └─ 有効 / 無効 / 留守録 / 匿名に分類 ↓[④ 見える化役：レポート・ダッシュボード]```

中心になる作り込みは2つです。「転送経由の通話をどう見抜くか」と「電話番号という個人情報をどう守りながら突合するか」。順に説明します。

中核1：転送経由の電話を見抜いて二重計上を防ぐ

PBXには転送機能があり、広告LP用の番号にかかってきた電話を公式番号に転送して受ける運用がよくあります。ここに落とし穴があります。製品や設定によっては、転送先の通話ログでは発信者番号が「転送元の番号」に書き換わることがある（元の番号を保持する構成を選べる製品も多い）。

つまり公式番号の通話ログには、本当に公式番号へかけてきた人（発信者番号＝実際のお客様の番号）と、広告LP経由で転送されてきた人（発信者番号＝広告LP用の番号）が混ざります。後者はコールトラッキングSaaS側ですでに計測されているので、そのまま数えると二重計上になります。

これを防ぐ部品が、BigQuery側での突合です。発信者番号を「自社の全PBX回線の番号一覧」と照らし合わせ、一致したら転送由来とみなして除外する。実装者向けの勘所だけ書くと、番号はそのまま比較せずハッシュ化（＝元に戻せない短い符号に変換）した値どうしで突き合わせます。生の番号を集合演算に晒さないためです。SQLの全文は割愛しますが、やっていることは「回線一覧にある番号からの着信は数えない」という1行のフィルタに集約されます。

中核2：電話番号という個人情報を守りながら突合する

着信した番号を顧客DB（予約管理SaaSやCRM）と突合すると、新規か既存か、予約まで進んだかが分かります。ただし電話番号は個人情報です。生のままBigQueryに貯めると、漏洩時の影響範囲が一気に広がります。

そこで保管を3層に分けました。

突合は番号の表記ゆれをそろえる正規化から始めます。全角・半角、ハイフン、カッコ、国際表記（+81）の揺れをならして、同じ番号は同じ形にしてから照合する。ここを雑にやると、同じお客様が別人として数えられます。

なお国内の携帯番号は組み合わせが有限なので、単純なハッシュ化だけだと総当たりで元の番号を逆算される危険があります。鍵付きのハッシュ（鍵を知らないと逆算できない方式）を使い、その鍵をクラウドの鍵管理サービスで守る、というのが個人情報を守りながら突合する最低ラインです。

中核3：紐付け率は100%にならない前提で設計する

電話CV計測で一番つまずくのは、技術ではなく期待値です。「鳴った電話を全部、流入元まで紐付けたい」という前提で設計すると破綻します。現実には紐付かない通話がそれなりにあるからです。

経験的に、流入元まで紐付くのは半分前後と見ておくのが安全です。これを「一般的な傾向」として受け入れ、紐付いた分はしっかり媒体評価に使い、紐付かない分は推計で補う。受付ヒアリング（「何でお知りになりましたか」をメモに残す）を併用すると、紐付け率はもう少し底上げできます。ここはクライアント固有の数値ではなく、電話計測一般に当てはまる感覚値として書いています。

どの方式で作るか：選択肢を比べる

電話CVを計測する手段はPBX×BigQueryだけではありません。安さ以外の軸で並べます。電話計測の主役は「精度」と「広告との突合のしやすさ」なので、その2軸を意識して見てください。

PBX×BigQueryを選ぶ理由は、サイトに載せている固定番号への「実際の着信」を主役に据えられる点です。SaaSが取りこぼす公式サイト直接架電を、通話ログという事実から拾える。逆に「広告LP経由だけ取れれば十分」ならコールトラッキングSaaSのほうが速くて安いこともあります。精度を取りにいくか、手軽さを取るかの選択です。

いくらかかるか：運用費だけ見ると判断を誤る

この構成の運用コスト自体は重くありません。Cloud Schedulerは無料枠に収まりやすく、Cloud Runは1日に数分動くだけ、BigQueryも通話ログの量なら少額です。問題は、運用費が安いことを理由に「では安く作れる」と早合点することです。レポート自動化と違い、この構成は初期構築の比重が大きいテーマです。

発注や内製を判断するなら、次の4つを必ず分けて見てください。

電話CV計測で最大の論点は、最後の「データ欠損リスク」です。毎日の取得が静かに止まると、その日の電話は永久に数えられません。エラーで派手に落ちるなら気づけますが、空のデータが返ってくるタイプの停止は気づきにくい。だから「止まったとき誰がどう検知して直すのか」を、安さの議論より先に決めておく必要があります。

初期構築の規模感を一言でいうと、レポート自動化が「半日から1日」なのに対し、この構成は「PBXのAPI調査から本番安定まで含めて、数週間スパン」が現実的です。PBX製品ごとにAPIの癖が違い、転送仕様の確認や顧客DBとの突合検証に時間がかかるためです。

自社でやるべきか、外注すべきか

「運用費が安いなら自社で」と決める前に、次の3点で判断してください。電話CV計測は、レポート自動化より内製のハードルが一段高いテーマです。

特に2つ目が重い。電話番号は個人情報で、突合設計を誤ると漏洩リスクに直結します。生の番号を集計テーブルに置く、鍵管理を省く、といった手抜きが事故の入口になる。ここを安全に設計できる人が社内にいなければ、外注したほうが安全です。

こんな会社は無理に作らないほうがいい

正直なところ、向かないケースもあります。

• 電話問い合わせがそもそも少ない：浮く判断材料より構築の手間が上回る
• フォームCVだけで広告判断ができている：電話が主戦場でないなら優先度は低い
• PBXに通話履歴取得APIが無い：古い電話システムだと、そもそも通話ログを外に出せないことがある。まずPBXの仕様確認から

電話が売上の柱で、かつ広告評価に電話が乗っていない会社ほど、この計測の費用対効果が高くなります。

つまずきポイント

実際に構築するとき、ここで手が止まりやすい場所です。自社で挑戦する場合も、外注先に確認する場合も、知っておくと話が早く進みます。以下は今回の構成で実際に詰まった箇所です。

つまずき1：転送経由の電話を除外し忘れて二重計上する

最初に書いた転送の仕様を知らないと、広告LP経由で転送されてきた電話まで「公式サイト直接架電」として数えてしまいます。コールトラッキングSaaS側ともダブって、電話CVが実態より膨らむ。発注時は「転送経由の二重計上をどう除外するか」を必ず確認項目に入れてください。

つまずき2：PBX製品ごとにAPIと転送の挙動が違い、調査に時間を食う

転送時に発信者番号がどう記録されるかは、PBX製品によって挙動が違います。今回の構成がそのまま別の製品で動く保証はなく、最初の仕様確認を飛ばすと突合設計のやり直しになります。初期構築が「数週間スパン」になる理由の多くはここです。発注時は「うちのPBXの機種でAPIと転送仕様を確認した上での見積もりか」を聞いてください。

つまずき3：「ハッシュ化したから安全」で止まる

電話番号を符号に変換したから個人情報は守れている、と思い込むのが一番危ない。国内の電話番号は組み合わせが有限なので、鍵なしの単純なハッシュ化は総当たりで元の番号に戻せてしまいます。鍵付きのハッシュと、その鍵をクラウドの鍵管理サービスで守るところまでがワンセット。外注するなら「ハッシュ化の方式と鍵の管理方法」まで確認項目に入れると、保護設計の実力が分かります。

医療系で扱うときの法令まわり

今回のクライアントは医療系だったため、通話録音と文字起こしの扱いは慎重に整理しました。同業種で電話CV計測を検討する方の参考に、要点だけ残します。

通話内容から得た気づきを広告改善に使うのは通常のマーケティングの範囲ですが、患者の発話をそのまま広告コピーに載せるのは別問題です。文字起こしは内部分析に限定し、気づきを抽出してから人が書き直す、というワンクッションを必ず挟む方針にしました。

同じ電話番号を複数拠点で使っているときの判別4手段

運用を始めると必ず聞かれるのが「この着信はどの拠点宛てか」です。サイトごと・拠点ごとに番号を分けていれば悩みませんが、共通のフリーダイヤル1本で受けている場合、判別手段は次の4つに整理できます。

1. 訪問者IDと電話番号の直接突合：不可。Webページは訪問者の電話番号を知り得ないため、原理的に突合キーが存在しません
2. CRMの電話番号突合：着信の発信者番号を顧客管理の登録番号と照合し、登録レコード側の拠点情報で判別。実測では着信の半分程度に拠点が付きました（未登録の人は判別不可）
3. タップ時刻×着信時刻の時間窓突合：どのサイト・どのページで電話リンクがタップされたかと、着信の開始時刻を突き合わせる。本文で書いた仕組みの応用で、推定ベースながらサイト単位の判別ができます
4. 番号の分離（構造解）：拠点・サイトごとにトラッキング番号を分ける。判別精度は100%になり、以後の集計が全部シンプルになります。回線追加のコストと天秤にかけて、計測を本気でやるならこれが本命です

1〜3は今あるデータで始められ、4は仕組みで解決する話。順番としては2と3で実態をつかみ、その価値が見えてから4に投資する流れが現実的でした。

まとめ：「鳴った電話」を事実として数える

サイト掲載番号への直接架電は、長く「計測できない」と諦められてきた領域です。PBXとBigQueryをつなげば、そこを事実ベースで埋められます。

1. PBXの通話ログを毎日BigQueryに流し、顧客DBと突合する4部品で組む
2. 主役の論点は運用費の安さではなく、初期構築の規模とデータ欠損リスク
3. 電話番号は個人情報。ハッシュ化・隔離・鍵管理まで設計しないと事故になる
4. 紐付け率は半分前後が現実値。100%を目指さず、紐付いた分を評価に使い残りは推計

サイトでタップされた回数ではなく、現実に鳴った電話を数える。電話が売上の柱なら、ここを数字にするだけで広告判断の精度が変わります。

電話CV計測・データ基盤の設計でお困りなら

「電話で問い合わせてくるお客様が多いのに、広告評価に電話が乗っていない」「PBXに通話ログはあるが、どの広告から来たのか紐付けられていない」。そう感じている会社は業種を問わず増えています。ただ、PBXの仕様確認・転送の除外設計・電話番号の保護設計を最初に詰めないと、作っても止まる仕組みになりがちです。

f2t.jpでは、PBX × BigQuery の電話CV計測について、自社で作るべきか外注すべきかの線引き、初期構築の規模、個人情報の保護設計、止まったときの検知方法まで、最初の整理からお手伝いしています。お問い合わせフォームから、自社の「電話が数字になっていない」状況をご相談ください。