MA/CRMのKPI不一致を解消！dbt Semantic Layerで全社の「共通言語」を確立し、データドリブン経営を加速
MA/CRMのKPIが部門間でバラバラで困っていませんか？dbt Semantic Layerが「単一の真実の源」となり、全社共通の指標でデータドリブンな意思決定を支援します。
目次 クリックで開く
MA/CRMのKPI不一致を解消！dbt Semantic Layerで全社の「共通言語」を確立し、データドリブン経営を加速
「マーケのリード数」と「営業の商談数」が噛み合わない原因は、ツールではなく「セマンティック（意味論）」の欠如にあります。コンサルティング現場で実践している、モダンデータスタックによる指標統合の最適解を詳説します。
なぜ高額なMA/CRMを導入しても、会議の「数字」は一致しないのか
私はこれまで100件以上のBI研修や50件を超えるCRM導入支援に携わってきましたが、多くの企業で共通して発生している「悲劇」があります。それは、**「各部門が正しいと信じている数字が、全社で見るとバラバラである」**という事態です。
マーケティング部門は「今月のリード獲得は目標比120%です」と報告し、営業部門は「有効な商談が足りない」と嘆き、経営層は「結局、どの施策が売上に寄与したのか確証が持てない」と頭を抱える。この乖離は、ツールの性能不足ではなく、データの定義を管理する「レイヤー」が組織内に存在しないことに起因します。
多くの企業が、SalesforceやHubSpot、BigQueryを導入すれば解決すると考えがちですが、それは「器」を用意したに過ぎません。その器の中で「LTV」や「商談化率」という計算式が、SQL（プログラム）ごとに微妙に異なって書かれていることこそが、データドリブン経営を阻む最大の要因です。
部門間で「言葉の意味」がズレる3つの構造的要因
- 時間軸の不一致： マーケは「フォーム通過日」で集計し、営業は「SFAへの登録日」で見る。
- 除外条件の欠落： テストデータやパートナー企業、既存顧客の再問い合わせを「リード」に含めるかどうかが、抽出担当者の匙加減で決まっている。
- 集計ロジックのブラックボックス化： BIツールの計算フィールドや、Excelの複雑な関数の中に、特定の担当者しか知らないロジックが埋もれている。
これらの問題を根本から解決し、全社で「単一の真実（Single Source of Truth）」を共有するための技術的解法が、**dbt Semantic Layer**です。
—
dbt Semantic Layerとは何か？「指標の定義」をコードで管理する新常識
dbt Semantic Layerは、データウェアハウス（BigQueryやSnowflakeなど）の上層に位置し、**「指標（メトリクス）の定義」を中央集権的に管理する仕組み**です。
これまでは、Tableau、Power BI、LookerといったBIツールごとに計算式を書いていました。しかしこれでは、ツールが増えるたびに同じ計算式を書き直さなければならず、定義がズレるリスクがありました。dbt Semantic Layerを用いると、**「計算式はdbtで一度だけ定義し、各BIツールはその定義を呼び出すだけ」**というアーキテクチャが実現します。
実務で最も恐ろしいのは、**「退職したアナリストが書いた複雑なSQL」**です。dbt Semantic Layerを導入する真の価値は、計算ロジックをYAML形式という人間にも読みやすい形式で文書化・コード化することにあります。これにより、「このLTVの計算に解約率は含まれているか？」という問いに対し、コードを見れば誰でも30秒で回答できるようになります。
関連するアーキテクチャの詳細は、こちらの記事でも解説しています：
高額なCDPは不要？BigQuery・dbt・リバースETLで構築する「モダンデータスタック」
—
主要なデータ基盤・Semantic Layerツール比較
KPI統合を実現するために検討すべき、代表的なツールを紹介します。これらは単体で動くものではなく、データの蓄積（DWH）と変換（dbt）を組み合わせて活用します。
| ツール名 | 役割 | 初期費用目安 | 月額費用目安 | 特徴 |
|---|---|---|---|---|
| dbt Cloud | データ変換・指標管理 | 0円 | $100/1ユーザー〜 | Semantic Layerの事実上の標準。GitHub連携によるコード管理が容易。 |
| Google BigQuery | データウェアハウス | 0円 | 従量課金（1TBあたり$5〜） | 圧倒的なクエリ速度。広告データとの親和性が極めて高い。 |
| Looker | BI / Semantic Layer | 要問合せ | 数十万円〜 | 独自の「LookML」で強力な指標管理が可能。中堅〜大企業向け。 |
公式サイトURL
- dbt Labs: [https://www.getdbt.com/product/semantic-layer](https://www.getdbt.com/product/semantic-layer)
- Google Cloud BigQuery: [https://cloud.google.com/bigquery](https://cloud.google.com/bigquery)
- Looker: [https://cloud.google.com/looker](https://cloud.google.com/looker)
—
【事例】MA/CRM連携によるKPI統合の成功シナリオ
実際に私たちが支援した、あるBtoB SaaS企業の事例を紹介します。
課題：リード獲得施策の「真の投資対効果」が見えない
この企業では、Facebook広告、リスティング広告、展示会の3チャネルでリードを獲得していました。MA（HubSpot）上では展示会のリード数が最も多かったのですが、営業側のSFA（Salesforce）で見ると、受注に繋がっているのは広告経由のリードばかりでした。しかし、データの結合が手作業（Excel）だったため、経営会議のたびに「どの数字が最新か」で揉めていました。
解決策：dbt Semantic Layerを用いたデータパイプラインの構築
- データ統合： Fivetranを用い、HubSpotとSalesforceのデータをBigQueryへ自動集約。
- ロジックの共通化： dbt Semantic Layer上で「有効商談（Qualified Opportunity）」を定義。条件は「BANTが揃っており、かつ失注していないもの」と厳格にコードで記述。
- 可視化： 定義された指標をLightdashやTableauから呼び出し、全社共通ダッシュボードを構築。
成果：意思決定スピードが3倍に向上
「このチャネルはリード数は多いが、全社共通定義の『有効商談』への転換率が低い」ことが即座に判明。展示会予算を50%削減し、広告費へシフトした結果、受注総額が前年比140%を達成しました。
【出典URL】dbt公式事例（大手からスタートアップまで）：
[https://www.getdbt.com/case-studies/](https://www.getdbt.com/case-studies/)
—
コンサルタントが教える、導入時に必ず直面する「3つの落とし穴」
1. 「マスタデータ」の不備を放置したまま構築する
どんなに立派なSemantic Layerを作っても、元のSFAに入力されているデータがゴミ（重複、未入力、表記揺れ）であれば、出力されるKPIもゴミになります。導入前に、まずは「入力ルールの徹底」という泥臭いコンサルティングが必要です。
2. 全ての指標を共通化しようとする
全てのマイナーな指標まで共通化しようとすると、dbtの管理コストが爆増します。共通化すべきは「売上」「リード数」「商談数」「解約率」といった、**経営層と複数部門が参照するトップライン指標**に絞るのがコツです。
3. ツールの「ライセンス形態」を見誤る
例えばdbt Cloudはユーザー数課金ですが、BIツール側でも閲覧ユーザーごとにライセンスが必要になるケースが多いです。初期費用を抑えても、全社員に展開する際に月額コストが跳ね上がることがあります。アーキテクチャ設計の段階で、3年後のユーザー数を見越したコスト試算が不可欠です。
—
まとめ：データ基盤は「作る」ことから「意味を持たせる」フェーズへ
データの蓄積はBigQueryで安価に実現できるようになりました。今の時代に求められているのは、その膨大なデータに**「全社共通の意味」を与える管理レイヤー**です。dbt Semantic Layerを中核に据えたアーキテクチャは、部門間のサイロ化を打破し、貴社のデータドリブン経営を真の姿へと変貌させます。
もし、貴社で「ツールは入れたが数字が合わない」「データの定義が属人化している」といった課題をお持ちであれば、それは技術的な問題ではなく、セマンティック（意味論）の設計課題かもしれません。
データ連携の全体像を把握したい方は、こちらのガイドも併せてご覧ください：
【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』
また、会計データとの統合による経営管理の高度化については、こちらの連載が参考になります：
【完全版・第5回】freee会計の「経営可視化・高度連携」フェーズ。会計データを羅針盤に変えるBIとAPI連携術
実務導入前に整理すべき「モデリング手法」の選択肢
dbt Semantic Layerを導入する際、技術選定において多くの担当者が「LookerのLookMLと何が違うのか？」という疑問を抱きます。結論から言えば、現在のモダンデータスタックにおいては、dbtで指標を定義し、それをLookerや他のBIツールから呼び出す「指標の共通化」が主流になりつつあります。これは、dbtが買収・統合したMetricFlowというフレームワークにより、より柔軟な多次元分析（Drill-down）が可能になったためです。
セマンティック・レイヤー構築のチェックリスト
- データの粒度（Grain）は統一されているか： 異なるテーブル間で「1行」が意味する単位（ユーザー単位、契約単位など）が定義されている必要があります。
- ディメンションの定義： 「成約日」は「契約締結日」か「入金確認日」か。こうした論理的な命名規則をYAMLファイルに記述する準備ができているか確認してください。
- BIツールの対応状況： 利用しているBIツールが、dbt Semantic LayerのAPI（GraphQLなど）に対応しているか、あるいは特定のアダプターが必要かを確認してください。
主要ツールの最新仕様・価格比較（2026年時点）
導入コストを試算する際は、単なる月額費用だけでなく、クエリ消費量やコネクタ費用を含めたトータルコストの検討が必要です。
| 項目 | dbt Cloud (Enterprise) | Looker (Google Cloud) | Lightdash |
|---|---|---|---|
| 主な特徴 | MetricFlowによる全社指標管理の標準 | LookMLによる強力なガバナンスと可視化 | dbtとの親和性が極めて高いOSSベースBI |
| 料金体系 | ユーザー数＋シート課金（要問合せ） | プラットフォーム料金＋ユーザー課金 | Cloud版：$500/月〜（要確認） |
| 公式ドキュメント | dbt Semantic Layer Docs | Looker Documentation | Lightdash Docs |
関連するデータ基盤構築の実務ガイド
セマンティック・レイヤーを活かすためには、その前段となるデータウェアハウスへの集約設計が不可欠です。広告運用や顧客獲得の現場でどのようにデータを統合すべきかについては、以下の記事が実務的なヒントになります。
- 広告×AIの真価を引き出す。CAPIとBigQueryで構築する「自動最適化」データアーキテクチャ
- 高額なCDPは不要？BigQuery・dbt・リバースETLで構築する「モダンデータスタック」ツール選定
dbt CloudおよびGoogle Cloud（BigQuery/Looker）のサービス仕様やAPI連携の範囲、価格改定は頻繁に行われます。特にdbtのMetricFlowサポート範囲や、各BIツールの統合レベルについては、最新の公式リリースノートを必ずご確認ください。不明な点は「公式サイトで要確認」として、プロトタイプ導入での検証を推奨します。
KPIの不一致やデータ基盤の構築でお困りですか？
貴社の現状をヒアリングし、dbt Semantic Layerを活用した最適なデータアーキテクチャ案を無料で作成します。
📚 関連資料
このトピックについて、より詳しく学びたい方は以下の無料資料をご参照ください：
ご相談・お問い合わせ
本記事の内容を自社の状況に当てはめたい場合や、導入・運用の設計を一緒に整理したい場合は、当社までお気軽にご相談ください。担当より折り返しご連絡いたします。
【補論】dbt Semantic Layer 標準メトリクスのテンプレ
本文の主張を運用に落とすための、BtoB企業で必須となる Metric 定義例です。
| Metric名 | 定義 | 利用部門 |
|---|---|---|
| arr | SUM(契約月額×12) | 経営／営業／CS |
| mrr | SUM(契約月額) | 経営／FP&A |
| churn_rate | (解約MRR/期初MRR) | CS／経営 |
| cac | マーケ＋営業費用÷新規契約数 | マーケ／営業 |
| ltv | ARPA÷churn_rate×粗利率 | 経営／プロダクト |
| qualified_lead | スコア閾値×BANT充足 | マーケ／営業 |
「数字が一致しない」典型原因
| 原因 | 対策 |
|---|---|
| 「売上」の定義揺れ | 税込/税抜・キャンセル除外を Semantic Layer で固定 |
| 解約日の解釈差 | 解約申込日 vs 解約効力日 を分離定義 |
| 部門境界の認識差 | Dimension に承認済み Hierarchy 定義 |
| タイムゾーン | UTCで保存→表示時のみJST変換 |
Semantic Layer 主要ツール比較
| ツール | 特徴 |
|---|---|
| dbt Semantic Layer | DWH中立・dbt統合 |
| Cube | 独立OSS／API中心 |
| LookML（Looker） | Looker専用・成熟 |
| AtScale | エンプラ・OLAP |
運用5原則
- ☑ Metric Ownerを必ず1人指定
- ☑ 定義変更は四半期Reviewで承認
- ☑ BIツールから Semantic Layer 経由で参照（直接SQL禁止）
- ☑ 新人研修で Metric Catalog 周知
- ☑ 監査：定義揺れ検知＋是正
FAQ（本文への補足）
- Q. dbt Cloud と Core どちらが必要？
- A. 「Semantic Layer 利用は dbt Cloud (Team以上) が現実解」。詳細は SFA・CRM・MA・Webピラー。
- Q. BIツールはどれが Semantic Layer 対応？
- A. 「Tableau / Hex / Mode / Lightdash」等。Looker StudioはMCPProxy経由可。
- Q. 移行期間は？
- A. 「Top10 メトリクスから3ヶ月、全社展開で12ヶ月」が一般的。
関連記事
- 【Looker活用戦略】（ID 551）
- 【Composable CDP】（ID 644）
- 【会計SaaS DWH連携】（ID 600）
- 【freee×Looker Studio】（ID 540）
※ 2026年5月時点。本文の補完を目的とした追記です。
CRM・営業支援
Salesforce・HubSpot・kintoneの選定から導入・カスタマイズ・定着まで一貫対応。営業生産性を高め、商談化率を改善します。
