「Snowflakeにデータは集めた。だが営業現場では使われていない」——データ基盤の整備が一段落した企業で、次に出てくる問題です。データウェアハウスにきれいに揃った顧客データは、分析チームがダッシュボードを作るには十分でも、営業担当がその場で参照し、行動を変えるための形にはなっていません。
逆方向の問題もあります。CRMには商談の履歴があるが、その顧客の利用実績や請求状況は別のシステムにある。両方を突き合わせた条件でリストを作りたいのに、都度CSVを書き出して照合している。
HubSpot Data Studioは、この双方向の断絶を埋めるために用意された機能です。本記事では、HubSpot公式ナレッジベースの記載に基づき、何ができて何ができないのか、そしてクレジット消費と制限をどう見込むかを整理します。
目次
Data Studioは、HubSpot内部のデータと外部データソースを組み合わせてデータセットを作り、それをCRMの各機能で使える形に変える仕組みです。単なるレポート作成ツールではありません。作ったデータセットをリスト・ワークフロー・レポートに流し込み、さらにCRMレコードへ書き戻せる点が中核です。
従来のBIツールとの違いはここにあります。BIツールは「見る」ための道具です。Data Studioは「見る」だけでなく「使う」ための道具として設計されています。外部システムにある数値を条件にしてワークフローを起動できる、という機能はBIツールにはありません。
公式ナレッジベースによれば、Data StudioはData HubのProfessionalまたはEnterpriseで利用できます。またベータ機能であるため、スーパー管理者によるオプトイン登録が必要です。
この2つの条件は検討の前提を決めます。Data Hubを契約していない組織では使えません。そしてベータであるため、仕様が変わる可能性があります。基幹的な業務プロセスに組み込む前に、この点を情報システム部門と合意しておく必要があります。Data Hubの機能範囲はHubSpot Data Hub（旧Operations Hub）とは？で整理しています。
接続先は、既存のデータ基盤との相性を判断する材料になります。公式ナレッジベースが挙げているのは次のソースです。
この一覧で注目すべきはGoogle SheetsとCSVが含まれている点です。データウェアハウスを持たない組織でも使えます。実務では、事業部門が管理しているスプレッドシートを正として扱い続けたいケースが多くあります。そのスプレッドシートをCRMの条件として使えるようになる、というのが現実的な効きどころです。
Snowflakeについては、データシェアの接続が別途用意されています。既にSnowflakeを運用している企業では、この接続とData Studioを組み合わせて、変換レイヤーをHubSpot側に置く構成が取れます。
作成手順は直線的です。ただし「作った後にどう使うか」を先に決めておかないと、作っただけで終わります。用途から逆算して設計してください。
| 手順 | 操作 |
|---|---|
| 1 | ［データ管理］→［Data Studio］にアクセス |
| 2 | 「データセットを作成」を選択 |
| 3 | HubSpot CRMオブジェクトまたは外部ソースを追加 |
| 4 | 必要なプロパティ・フィールドを選択 |
| 5 | 結合・数式・エンリッチメントで加工 |
| 6 | フィルターを適用して保存 |
5行目の「結合」が設計の中心です。CRMのコンタクトと外部システムの利用実績を、どのキーで結合するかを決める必要があります。メールアドレスで結合するのか、外部システムの顧客IDをCRMに持たせて結合するのか。後者のほうが安定しますが、CRM側にIDを持たせる仕組みが必要になります。
アクティベーションと呼ばれる工程です。5つの出口が用意されています。
| 出口 | できること | 典型的な用途 |
|---|---|---|
| リスト／セグメント | データセットのコンタクトから動的セグメントを生成 | 外部の利用実績を条件にした対象抽出 |
| ワークフロー | データセットのレコードに対して単発または定期のワークフローを構築 | 解約リスクの高い顧客へのアラート |
| レポート | 複数のデータソースを統合したカスタムレポート | CRMと会計データを突き合わせた収益レポート |
| CRM同期 | 外部データをHubSpotのCRMレコードに書き込む | 利用状況を営業担当が画面で見られるようにする |
| エクスポート | Google SheetsまたはOffice 365 Excelへ出力 | 既存の報告フォーマットへの連携 |
4行目のCRM同期が、業務への影響が最も大きい出口です。営業担当が普段見ている取引レコードの画面に、外部システムの数値が表示される。この状態になると、営業は別システムを開かなくなります。データ統合の成果が「別のダッシュボードが増える」で終わるか「行動が変わる」に至るかは、この書き戻しを設計するかどうかで分かれます。
抽象的な説明では判断できないため、具体例で一連の流れを示します。SaaSや保守契約を持つ企業でもっとも需要が大きい用途です。
前提はこうです。契約情報はCRMにある。製品の利用ログは自社のデータウェアハウスにある。カスタマーサクセス担当は、利用が落ちている顧客を早く知りたいが、両方を突き合わせる手段がない。
この場合の組み立ては4段階になります。第一に、データウェアハウス側で「直近30日のログイン日数」「主要機能の利用回数」を顧客IDごとに集計したビューを用意します。第二に、Data Studioで顧客IDを結合キーとしてCRMの会社レコードと結合します。第三に、結合結果をCRM同期で会社レコードの専用プロパティへ書き戻します。第四に、そのプロパティを条件にしたワークフローで、担当者にタスクを起こします。
この設計の要点は、判定ロジックをどこに置くかです。「解約リスクが高い」という判定をデータウェアハウス側で行うのか、CRMのワークフロー側で行うのか。前者は分析チームが基準を管理し、後者はカスタマーサクセスが管理します。基準を頻繁に見直すならCRM側に置いたほうが運用は速くなります。分析の精度を優先するなら前者です。ここを決めずに実装すると、基準の変更依頼がどちらの部門にも滞留します。
ここが予算設計の要点です。Data StudioはHubSpotクレジットの消費対象です。
公式ナレッジベースによれば、「Use」権限を有効化すると、データセットの使用時にクレジットを消費します。対象となるのはワークフロー、セグメント、CRM同期、エクスポートです。つまり、データセットを作るだけでは消費せず、使い始めると消費が発生する構造です。
Data Hubの付与クレジットは他のハブより多く設定されています。Data HubはProfessionalで5,000クレジット、Enterpriseで10,000クレジット（他のハブは3,000／5,000）です。外部ソースの同期とCRMへの書き戻しを日常的に回すと、この差が実際の残量に表れます。私たちがData Studioを含む構成を設計するときは、同期の頻度と対象件数を先に固めてから、付与クレジットの範囲で足りるかを判定しています。消費レートの全体像はHubSpotクレジットとは？料金の仕組みと消費レートを徹底解説で解説しています。
実務上の注意は、定期実行の設計です。CRM同期を高頻度で回すと消費が読みにくくなります。営業が見る情報がリアルタイムである必要は多くの場合ありません。日次で足りるなら日次にしてください。
設計を始める前に、2つの制限を把握しておく必要があります。どちらも後から気づくと設計をやり直すことになります。
1つのデータセットで選択できるデータソースは最大5つとされています。CRMオブジェクトと外部ソースの合計です。
この制限は、設計方針を「1つの巨大なデータセット」から「用途別の複数のデータセット」へ寄せます。全社の全データを1つに統合しようとすると上限に当たります。逆に用途を絞れば5つで足ります。用途から設計するという原則は、この制限からも導かれます。
より注意が必要なのはこちらです。1対多の関係を含むデータセットでは、「要約ビュー」と「未要約ビュー」が生成され、CRM同期・ワークフロー・リストで利用できるのは要約ビューのみとされています。
具体例で考えます。1つの顧客に対して複数の請求明細があるデータを扱う場合、明細1行ごとの情報をワークフローの条件に使うことはできません。使えるのは「合計金額」「件数」「最終日付」といった集約後の値です。
この制約は、設計の初期に効きます。「明細レベルで条件分岐させたい」という要件があるなら、Data Studioでは実現できません。その場合はカスタムオブジェクトとして明細を持つか、外部システム側で判定してフラグだけを同期する構成を検討してください。カスタムオブジェクトの設計判断とあわせて検討する論点です。
データ基盤を既に持っている企業では、役割の重複が論点になります。結論を先に言えば、置き換えではなく住み分けです。
| 観点 | Data Studio | BIツール | ETL／データ基盤 |
|---|---|---|---|
| 主目的 | CRMでの活用（リスト・ワークフロー・書き戻し） | 分析・可視化 | 収集・変換・蓄積 |
| 利用者 | 営業・マーケの運用担当 | 分析担当・経営 | データエンジニア |
| 強み | 業務システムに直接作用する | 複雑な分析・自由な可視化 | 大量データの処理と履歴管理 |
| 弱み | 1対多の明細レベルの扱いに制限がある | 行動に接続しない | 現場が直接使えない |
この表の「弱み」の行を横に読むと、住み分けの理由が分かります。BIツールは行動に接続せず、データ基盤は現場が触れません。Data Studioが埋めるのは、蓄積されたデータを現場の行動に変える最後の区間です。したがって、既存の基盤を捨てる必要はありません。
株式会社100がデータ基盤の整備を支援する際も、この最後の区間の設計を最初に決めることを勧めています。「どの数値が、誰の、どの画面に、いつ表示されるか」が決まっていないデータ統合は、完成しても使われません。
公正に整理します。ベータ機能であることを踏まえた判断が必要です。
| 観点 | 導入が向いている | 慎重に検討すべき |
|---|---|---|
| 契約 | Data Hub Professional以上を保有している | Data Hubの契約がない |
| データの所在 | 顧客の利用実績・請求データが外部にある | すべてのデータが既にCRM内にある |
| 要件の粒度 | 集約値で条件分岐できる | 明細1行単位の判定が必要 |
| 安定性 | ベータ機能の仕様変更を許容できる | 基幹業務に直結し変更が許されない |
| 体制 | 結合キーを設計・維持できる担当者がいる | データ設計を担う人がいない |
最終行を軽視しないでください。結合キーの設計と維持は継続的な作業です。外部システム側の項目が変われば結合は壊れます。作った人が異動した後に誰も直せない、という状態が最も避けたい結末です。
Data Hub ProfessionalまたはEnterpriseの契約が必要です。加えて、ベータ機能のためスーパー管理者によるオプトインが必要とされています。
使えます。Google Sheets、AirTable、CSVファイル、データ同期アプリにも接続できるため、データウェアハウスを持たない組織でも利用可能です。
公式ナレッジベースの記載では、「Use」権限を有効化してデータセットを使用する際にクレジットを消費します。対象はワークフロー、セグメント、CRM同期、エクスポートです。公式ドキュメントは消費のタイミングを「使用時」としており、作成のみの場合については明示していません。私たちがクライアントのポータルで検証する際は、少数のデータセットを1サイクル動かして［使用状況と上限］の増減を実測し、その値をもとに本番の実行頻度を決めています。
最大5つとされています。CRMオブジェクトと外部ソースの合計です。上限に当たる場合は、1つに統合するのではなく用途別に分割してください。
明細1行単位では使えません。CRM同期・ワークフロー・リストで利用できるのは要約ビューのみとされているため、合計・件数・最終日付といった集約値で設計する必要があります。
書き戻し先のプロパティを既存の入力項目と分けて設計してください。営業が手入力する項目と、外部から同期される項目を同じプロパティにすると、どちらが正か分からなくなります。同期専用のプロパティを用意するのが定石です。
なりません。目的が異なります。Data StudioはCRM上での活用（リスト・ワークフロー・書き戻し）を担い、複雑な分析や自由な可視化はBIツールの領域です。両者は併存します。
仕様変更の可能性を前提に設計してください。具体的には、Data Studioが停止しても業務が止まらない構成——たとえば書き戻したデータを参照専用として使い、判断のロジックはワークフロー側に持たせる——にしておくと影響を限定できます。
本記事はHubSpot公式ナレッジベースおよび製品ページの公開情報（2026年9月1日取得時点）に基づいて作成しています。Data Studioはベータ機能であり、対応ソース・制限・クレジット消費の条件は変更される可能性があります。実装前に公式ドキュメントの最新記載をご確認ください。