営業の活動量は週次で報告されているのに、「どの会話で案件が動いたのか」を聞かれると誰も答えられない。架電件数はスプレッドシートに積み上がっているが、CRMのコンタクトレコードを開いても通話の痕跡がない。商談化率を議論する会議で、インサイドセールスの部長が「つながった件数」を、営業企画が「有効会話数」を、執行役員が「商談化数」を別々の定義で話している。製造業や情報通信業の大規模組織で収益プロセスの再設計を進めるとき、この断絶はほぼ必ず電話の記録から始まります。
電話はBtoBの初期接触で依然として主要なチャネルでありながら、CRMの中で最も設計されないまま放置される領域です。メールやフォームは自動で記録が残るのに、通話だけは「担当者が終話後に手で入力する」前提のままになっている。入力されない記録は存在しないのと同じで、そこを起点にしたレポートはすべて実態からずれます。
この記事では、株式会社100がHubSpotの認定エリートパートナーとして収益プロセスを設計する立場から、HubSpotの通話機能とサードパーティCTIの使い分け、録音とAI文字起こしをCRMに乗せるための設定、コールアウトカム（通話結果）の設計、そして日本で通話録音を運用するときに確認すべき法令上の論点を整理します。
目次
通話連携の相談を受けるとき、最初に出てくる問いはたいてい「どのCTIをつなげばよいか」です。しかし私たちが支援の初期に必ず確認するのは、ツールの前にある三つの決めごとです。誰の番号で発信するのか、何を記録として残すのか、残した記録をどのKPIに接続するのか。この三つが決まっていない状態で連携だけ先行させると、通話ログは溜まるが分析には使えないという典型的な状態に着地します。
CRMに通話が記録されないとき、失われるのは「架電件数」だけではありません。失われるのは、接触から商談化までの経路そのものです。コンタクトのタイムラインに通話が載っていなければ、ライフサイクルステージが動いた理由を遡れず、どのリードソースから来た相手に何回接触して商談になったのかという、パイプライン設計の基礎データが欠落します。
HubSpotでは通話はブラウザーからの発信（HubSpot公式ナレッジベース）を含むアクティビティーの一種としてコンタクト・会社・取引・チケットに関連付けられ、通話時間や通話結果といった既定のアクティビティープロパティーを持ちます。既定のアクティビティープロパティー（HubSpot公式ナレッジベース）に通話向けの項目が用意されているのは、通話を自由記述のメモではなく構造化データとして扱うためです。ここを使い切らないまま運用を始めると、後からレポートを作る段階で「プロパティーに値が入っていない」という形で跳ね返ってきます。
私たちがリードの状態管理を設計する際は、通話結果とリードステータスを先に対応づけてから通話ツールの選定に入ります。HubSpotのリードステータスとライフサイクルステージの定義が曖昧なまま通話ログだけを増やしても、ファネルの歩留まりは計算できません。
日本のBtoB組織で電話連携が止まる原因は、ツールの機能不足よりも前提条件の確認漏れにあります。もっとも大きいのは発信者番号の扱いで、これは後述するとおりHubSpot標準の通話ツールを日本国内の架電にそのまま使うかどうかの判断を左右します。次に多いのが、録音を始めてから法務部門に止められるケースです。
この二つは、どちらもツールを契約した後に発覚すると手戻りが大きい論点です。発信者番号は営業現場の受容性に直結し、録音の可否は情報システム部門と法務部門の両方の承認を要します。営業・マーケ・ITが分断されている組織では、この承認フローの調整そのものがプロジェクトの律速になります。
HubSpotには追加のCTIを契約しなくても使える通話ツールが組み込まれています。利用にはSales HubまたはService Hubのシートの割り当てが必要で、これは自分の番号を登録する場合もHubSpot提供の番号を取得する場合も共通の要件です。ブラウザーから発信し、録音し、CRMのレコードに自動で記録するところまでが標準機能の守備範囲になります。モバイルアプリからの発信（HubSpot公式ナレッジベース）にも対応しています。
ただし「標準機能で足りるか」は国によって答えが変わります。HubSpotの通話はTwilioのVOIPサービスを基盤としており、各国の通信規制とキャリアの迷惑電話対策の影響を直接受けるためです。この構造を理解しないまま日本のチームに展開すると、現場から「相手に番号が表示されない」という報告が上がってきます。
HubSpotの通話ツールには二つの経路があります。HubSpotアカウント内で新しい番号を発行する方法（HubSpot公式ナレッジベース）による「HubSpot提供の電話番号」と、既に使っている携帯電話や固定電話を発信番号として登録する方法（HubSpot公式ナレッジベース）による「登録済み発信番号」です。両者はできることが明確に違い、特に着信とCRM記録の範囲が分かれます。
選択を分けるのは、着信をHubSpot側で受けるかどうかです。共有の問い合わせ窓口やヘルプデスクで電話を受ける設計にするなら、選択肢はHubSpot提供の番号に限られます。以下は両者の違いを整理したものです。
| 項目 | HubSpot提供の電話番号 | 登録済み発信番号 |
|---|---|---|
| CRMからの発信 | 可能 | 可能 |
| 会話インボックス／ヘルプデスクからの発信 | 可能 | 可能 |
| 転送先番号・ボイスメールへのルーティング | 可能 | 不可 |
| 発信通話のCRM記録 | 可能 | 可能 |
| 着信・不在着信・ボイスメールのCRM記録 | 可能 | 不可 |
| 管理者による番号の割り当て・再割り当て | 可能（スーパー管理者） | 不可（各ユーザーが自分で認証） |
| 規制審査 | Twilio経由の一度きりの審査あり | なし |
登録済み発信番号は、番号の所有権をHubSpotに移すものではありません。自分の番号であることを検証したうえで、CRMから発信したときの発信者番号として表示させる仕組みです。折り返しの電話は物理的な端末に直接かかるため、HubSpotでは録音も文字起こしもできません。営業担当が個人の携帯で折り返しを受ける運用は、記録という観点では穴になります。
ここが日本の組織にとって最も重要な確認事項です。日本については、HubSpotに登録されたいずれの番号から日本へ発信した場合も、発信者番号はブロックされます。回避策は、HubSpotの通話パートナーを利用してCRMから発信することです。
加えて、HubSpot提供の電話番号を取得できる国の一覧に日本は含まれていません。通話の対応国と電話番号の提供状況（HubSpot公式ナレッジベース）に掲載されている国別表はアルゼンチン、オーストラリア、カナダ、ドイツ、韓国などを列挙していますが、日本は別枠の「通話制限のある国」として扱われています。
この二つを合わせると、日本国内の顧客に電話をかける日本法人にとって、HubSpot標準の通話ツールは実務上の第一選択になりません。相手の端末に番号が表示されない状態での架電は、BtoBでは折り返しが期待できず、着信拒否の対象にもなりやすいためです。私たちが日本の営業組織に通話連携を設計する際は、この一点を理由にサードパーティのCTI連携を前提に置いています。海外拠点から現地顧客に架電する用途であれば、対応国の範囲内でHubSpot提供の番号が選択肢になります。
HubSpotの通話分数はユーザーごとではなくアカウント単位で集約され、全ユーザーで共有されます。使い切った場合は追加購入が可能で、翌月の初めにリセットされます。契約更新日ではなく暦月の初めという点は、月末に架電が集中する組織では運用上の注意点になります。各プランに含まれる分数はHubSpotの製品・サービスカタログに記載されており、本記事では個別の数値を引用していません。カタログの値は改定されるため、提案時には取得時点を明示する必要があります。
HubSpot提供の番号を取得する場合、選択した国によってはTwilioへ事業者情報を提出する一度きりの規制審査が必要になります。審査の承認までに3〜4営業日かかる場合があり、国や番号種別によっては番号の払い出しに1〜6週間かかる場合があります。導入スケジュールを引くときは、この待ち時間を工程表に載せておく必要があります。
会話インテリジェンス（Conversation Intelligence）は、録音された通話を文字起こしし、内容を解析してCRMに還元する機能群です。通話を「聞き直す資産」から「検索・集計できるデータ」に変えるのがこの機能の役割で、コーチングと案件分析の両方に効きます。ただし利用条件がシートとプランに紐づいているため、誰の通話が解析対象になるのかを先に確定させる必要があります。
会話インテリジェンスによる文字起こしと解析の利用には、Sales HubまたはService HubのProfessionalもしくはEnterpriseが必要です。自動で文字起こしされるのは、Sales SeatまたはService SeatのProfessional／Enterpriseを割り当てられたユーザーが行った録音に限られます。録音の再生とコーチング自体は録音を行ったユーザーであれば可能ですが、文字起こしの生成条件は別です。
この差は組織設計に直結します。インサイドセールスの一部メンバーにだけシートを割り当てると、同じチーム内で文字起こしのあるコールとないコールが混在し、トラッキングタームによる分析の母数が歪みます。また、問い合わせ受信箱やヘルプデスクのような共有ワークスペースに紐づく番号のボイスメールは文字起こしの対象外である点も、サポート部門に展開する際に確認しておくべき仕様です。
通話詳細画面では、通話の目的、主要な論点、決定事項、センチメント、次のステップに分けたAI生成の要約が表示されます。要約はテンプレートを切り替えられ、サポート担当向けは問題解決の経緯に、営業担当向けは案件のインサイトと反論対応に焦点が寄ります。要約そのものは編集できない仕様のため、補足はメモ欄に書く運用になります。営業担当が日常的に使うHubSpotのAI機能と組み合わせると、終話後の入力作業をかなり圧縮できます。
会話インテリジェンスには、通話をCRMレコードへ自動で関連付ける機能があります。通話に関連付けられた各ミーティングについて最大5件のコンタクトが、各コンタクトについて最大5件の会社が通話に関連付けられます。取引とチケットについてはAIモデルが通話との類似性を見て判定し、同じ会社に紐づいているか、取引名が通話名に含まれるかといった手がかりを使います。
既定では、通話の参加者に紐づく主要な会社へ自動的に関連付けが行われます。この挙動は通話設定から無効化できます。私たちが設計する際は、代理店や商社が介在して一つの案件に複数社が絡む構造の場合、自動関連付けをいったん無効にしてから関連付けラベルの設計を先に固めます。類似性ベースの自動判定は、同名の取引が並走する組織では誤接続の原因になるためです。
録音と文字起こしが溜まったあと、実際に分析の起点になるのは通話インデックスです。通話インデックスは、ユーザー、チーム、通話結果、通話時間といったプロパティーでフィルタリングできます。ここで「通話結果が商談化のもの」を絞り込めるかどうかが、後述するコールアウトカム設計の良し悪しを決めます。
トラッキングタームは、特定の語句が通話中にどれだけ出現したかをレポート化する機能で、Enterpriseでの利用が案内されています。競合名、価格に関する語、解約を示唆する語をカテゴリーとして登録しておくと、営業現場の肌感に頼らずに市場の変化を観測できます。AIが正しく動くためのデータ基盤という観点でも、音声という非構造データを構造化して蓄積する価値は大きい領域です。
通話連携が「記録は残るが分析できない」状態に陥る最大の原因は、通話結果の選択肢設計です。既定の選択肢のまま運用を始め、現場がとりあえず選べる値を選び、半年後に集計しようとして粒度が合わないことに気づく。この流れは組織の規模を問わず繰り返されます。
HubSpotではカスタムの通話結果と会議結果をそれぞれ最大30個まで作成でき、1件あたりの文字数は最大50文字です。作成にはSales HubまたはService HubのProfessional以上が必要で、アカウントアクセス権限を持つユーザーが設定します。通話設定側で通話結果の入力を必須にすることもできます。
注意すべきなのは、保存した結果の文言を後から編集できない仕様である点です。編集はレポートデータに影響するため、保存後に文言を変更することはできません。削除は可能ですが、削除した結果はワークフローやセグメントを含むHubSpotのツールで使えなくなります。つまり通話結果の命名は、事実上の一発勝負です。
私たちが設計する際は、通話結果を「相手の状態」ではなく「次に起こすべき行動が一意に決まる区分」で定義します。「不在」「留守電」「担当者不明」のように行動が分岐する事実だけを並べ、「見込みあり」「手応えあり」のような主観評価は入れません。主観評価は担当者ごとに基準が揺れ、集計した瞬間に意味を失うためです。
通話結果が「どうなったか」を表すのに対し、コールタイプは「何をする通話だったか」を表します。アカウント内で最大100個まで作成でき、Sales HubのProfessional以上でスーパー管理者が設定します。初回接触、ヒアリング、デモ日程調整、見積説明のように目的で分けておくと、活動量の内訳が可視化されます。
こちらにも運用上の罠があります。既存のコールタイプやミーティングタイプを編集すると、既存のラベルが更新されるのではなく、更新後の名称で新しいタイプが作成されます。過去に記録された通話は元のタイプ名を保持し、新しい通話だけが新名称を使います。名称を変えるとレポートの系列が分岐するため、タイプの命名も初期設計で固めるべき項目です。
この二軸を揃えると、「初回接触のうち有効会話に至った比率」「デモ日程調整の通話で日程確定に至った比率」のように、工程別の歩留まりを直接レポートできるようになります。HubSpot Sales Hubの商談管理と接続すれば、通話の積み上げが取引ステージの移動にどう効いたかまで追えます。
日本国内の架電では、発信者番号の制約からサードパーティCTIの採用が現実的な選択になります。HubSpotは通話アプリとの連携（HubSpot公式ナレッジベース）を前提に設計されており、アプリマーケットプレイスに掲載されたプロバイダーを接続するか、Calling Extensions SDKを使って自社の通話アプリを接続できます。
連携した通話アプリを使う場合、HubSpotアカウントの通話分数は消費しません。通話の課金はCTIベンダー側に移り、HubSpotは記録と解析の受け皿になります。接続方式によって画面挙動が変わり、通話リモートと通話ウィンドウの両方が開くもの、リモートのみのもの、どちらにも対応しない場合の通話ウィジェットの三通りがあります。ウィジェットの場合は通話中にページを離れられないため、通話しながらCRMを操作する運用には向きません。
自社開発のCTIや社内PBXをつなぐ場合は、Calling Extensions SDKを使った実装になります。HubSpot側の通話画面と自社アプリの間でイベントをやり取りする仕組みで、着信の受け取りまで対応させる場合は追加の実装要件があります。既存のコールセンター基盤を活かす方針の組織では、この経路の検討価値があります。
日本市場で採用例が多いCTIの一つが、株式会社RevCommの提供するMiiTelです。公開情報に基づく整理として、MiiTelは音声解析AIを搭載したクラウドIP電話で、通話内容を自動で録音・解析し、顧客情報に紐付けてクラウド上に蓄積する構成をとっています。MiiTel Phoneの機能紹介には、通話内容が自動で録音解析・文字起こしされ、利用中のCRMの活動履歴に自動保存される旨が記載されています。
HubSpotとの連携では、Sales Hubに登録された顧客情報と電話番号をMiiTel Analyticsの連絡先に取り込み、着信時にSales Hubの顧客情報を表示します。2023年2月には、HubSpotのアクティビティー連携に応対メモと音声認識結果（文字起こし）の登録機能が追加されました。
通話履歴をより細かく自社側で制御したい場合は、MiiTel DevelopersのOutgoing Webhook 通話履歴の仕様が公開されています。標準連携で足りない項目を外部に渡す設計はここが起点になります。なお、MiiTelは株式会社100が導入支援を行っている製品ではないため、本記事の記述はすべて公開情報に基づくものです。実際の連携可否と対応範囲は、契約前に提供元へ直接ご確認ください。
私たちが切り分けの判断基準として使っているのは、架電先の国、着信を受けるかどうか、既存のコールセンター資産の三点です。日本国内の新規開拓が主用途なら、発信者番号の制約からCTI連携を前提に置きます。海外拠点が現地顧客に架電する用途で、かつ着信も含めてHubSpot内で完結させたいなら、対応国の範囲でHubSpot提供の番号を使う構成が候補になります。
どちらを選んでも変わらないのは、コールアウトカムとコールタイプの設計がHubSpot側に残るという点です。CTIを入れ替えてもこの定義は資産として残るため、ツール選定よりも先に定義を固める順序が合理的です。
通話録音の可否を社内で議論すると、「録音する旨を必ず伝えなければならない」という前提で話が進むことがあります。実際の規律はもう少し細かく、個人情報保護委員会が公表しているQ&Aに判断の軸が示されています。ここを正確に押さえておくと、法務部門との調整が短くなります。
顧客との電話の通話内容は、通話内容から特定の個人を識別することが可能な場合には個人情報に該当します。一方で特定の個人を識別できない録音記録は、基本的には個人情報に該当しないとされています。ただし他の情報と容易に照合でき特定の個人を識別できる場合は全体として個人情報に該当しうるため、個別の事例ごとの判断が必要です。
CRMの文脈では、通話は必ずコンタクトレコードに紐づきます。氏名・会社名・電話番号と結びついた録音は容易照合性が認められる典型であり、実務上は個人情報として扱う前提で設計するのが妥当です。
個人情報に該当する場合、個人情報取扱事業者は個人情報保護法上、利用目的を通知又は公表する義務を負いますが、録音していることについて伝える義務までは負いません。つまり法令上の中心は録音の告知ではなく、利用目的の通知または公表です。
とはいえ、告知義務がないことと告知しない方がよいことは別問題です。相手が録音を認識していない状態で解析結果を社内共有する運用は、信頼の面でも、後から録音の削除を求められたときの対応コストの面でも不利になります。HubSpot提供の電話番号では、番号の設定時に録音同意メッセージの言語と音声を選択できる仕組みが用意されています。CTIを使う場合も、同等のアナウンスを入れられるかを選定条件に含めることをおすすめします。
海外拠点を含む運用では、地域によって両者同意（two-party consent）が求められる点にも注意が必要です。両者同意が必要な13の米国州への架電や、両者同意が求められる国際通話では、録音ボタンをクリックし、相手に伝えたことを確認する操作が必要です。この操作を行わないと録音は保存されません。
会話インテリジェンスを有効にすると、録音は音声ファイルから検索可能なテキストと解析結果に変わります。ここで利用目的の記載範囲が問題になります。「お問い合わせ対応のため」とだけ公表している状態で、通話内容を営業担当の評価や商談分析に使うのであれば、利用目的の記載を見直す必要があります。
さらに踏み込んだ論点として、個人情報保護委員会のQ1-11には、録音した音声から特徴情報を抽出し、話者認識システム等の本人を認証することを目的とした装置やソフトウェアにより本人を認証できるデータに変換した場合、当該データは個人識別符号に該当し、それ単体で個人情報に該当する旨が記載されています。話者を分離して表示する機能と、声紋による本人認証は法的な位置づけが異なるため、導入するCTIがどちらに該当するのかをベンダーに確認しておくと、法務レビューが一度で通ります。
ここまでの論点を工程に落とすと、ツール選定は中盤に来ます。先に決めるのは記録の定義で、その後に接続、最後に定着という順序です。順序を逆にすると、接続後に定義を変えることになり、過去データとの不整合が残ります。
私たちが通話連携のキックオフで埋めるのは、次の項目です。それぞれ決裁者が異なるため、並行して進めないとスケジュールが延びます。
接続が終わった後、最初の1か月で確認するのは通話結果の入力率です。入力が必須化されていない状態では、終話後の選択が飛ばされます。通話インデックスで通話結果が空の割合を見て、一定を超えるようなら必須化の設定を入れるか、選択肢が現場の実感と合っていないと判断して見直します。
次に見るのは、通話結果ごとの次アクションの発生率です。「再架電」を選んだ通話にタスクが紐づいているか、「資料送付」を選んだ通話にメールのアクティビティーが続いているか。ここが途切れている通話結果は、現場が逃げ場として選んでいる選択肢である可能性が高く、定義の見直し対象になります。
録音が保存されない事象が報告された場合は、設定ではなく操作が原因であることも多い領域です。録音を通話の途中でオフにすると保存されず、通話が接続しなかった場合は録音そのものが存在しません。問い合わせを受けたときは、この順で切り分けると早く解決します。
HubSpotの通話ツールの利用には、Sales HubまたはService Hubのシートの割り当てが必要です。シートを割り当てないメンバーに通話をさせる場合は、CTI側で発信し、通話ログをHubSpotに連携する構成になります。ただし会話インテリジェンスによる自動文字起こしはシートの条件に紐づくため、解析対象から外れる点は運用設計で織り込んでください。
保存済みのカスタム通話結果は編集できない仕様です。実務上は、新しい名称の結果を追加したうえで旧い結果を使用停止にし、レポート側で旧新を束ねる期間を設ける進め方になります。旧い結果を削除するとワークフローやセグメントで使えなくなるため、削除の前に参照箇所を洗い出してください。
標準の通話ツールで取得した録音の外部出力について、本記事の執筆時点でHubSpot公式ナレッジベースに一括エクスポートの手順は確認できませんでした。外部での解析を前提にするなら、CTI側のAPIやWebhookで通話データを受け取る構成のほうが設計の自由度があります。MiiTelのように通話履歴のWebhook仕様を公開している製品であれば、その経路で自社基盤に渡せます。
AI生成の要約は編集できない仕様で、通話の目的や決定事項をモデルが抽出したものです。社外に出す文書として使うのであれば、内容を人が確認したうえでメモ欄や別の成果物に転記する運用を推奨します。要約の誤りがそのまま顧客に渡ると、訂正のコストは自動化で削減した工数を上回ります。
個人情報保護委員会のFAQでは、録音している旨を伝える義務までは負わないとされる一方、利用目的の通知又は公表の義務は課されています。既存顧客への個別案内が必要かどうかは、利用目的の記載を変更するかどうかで判断が分かれます。自社の記載内容と変更の有無を踏まえ、法務部門と確認してください。
通話インデックスを通話結果と通話時間で分解すると、件数の増加が短時間の不在着信で構成されているのか、有効会話が増えているのかを分けられます。着信側の挙動はHubSpotブラウザーで電話を受けるに整理されています。有効会話が増えているのに商談が増えない場合は、トラッキングタームで競合名や価格に関する語の出現を見ると、失注要因の仮説が立てやすくなります。件数というひとつの数字のままでは、この切り分けができません。
HubSpot公式ナレッジベースの国別表に日本は掲載されておらず、HubSpot提供の電話番号を日本で取得できる旨の記載は確認できませんでした。さらに、HubSpotに登録されたいずれの番号から日本へ発信した場合も、発信者番号はブロックされます。日本国内の架電で番号を表示したい場合は、通話パートナーの利用が回避策になります。
コールアウトカム、コールタイプ、関連付けのルール、レポートの定義はHubSpot側に残る資産です。CTIを入れ替えても、通話ログの受け口が変わるだけでこれらの定義は引き継げます。むしろツール選定より先に定義を固めておくほうが、入れ替え時の比較検討が速くなります。
HubSpotの電話連携を設計するとき、判断の順序は次のとおりです。第一に、日本国内の架電では発信者番号がブロックされる仕様を前提に、CTI連携を含めた経路を決める。第二に、コールアウトカムとコールタイプを後から編集できない前提で確定させる。第三に、会話インテリジェンスの対象者をシートの割り当て計画と揃える。第四に、録音の利用目的を法務部門と確認する。この四つが決まってはじめて、どの製品をつなぐかという議論が意味を持ちます。
通話は、CRMの中で最後まで人の手に残っていた記録です。ここを構造化できると、営業活動は「量」ではなく「工程ごとの歩留まり」で語れるようになります。株式会社100は日本唯一のHubSpot認定エリートパートナーとして、収益プロセスの設計から定着までを支援しています。通話連携の設計でお困りの点があれば、お問い合わせよりご相談ください。
本記事の記述は2026年10月23日時点で公開されているHubSpot公式ナレッジベース、個人情報保護委員会のFAQ、各ベンダーの公式発表に基づいています。プランごとの通話分数、対応国、各機能の提供条件は変更される可能性があるため、導入判断の際は必ず最新の公式情報をご確認ください。