Fivetran後のデータ活用を最大化！会計・CRM・広告データをビジネス価値に変える「整形レイヤー」の全貌

Fivetranを導入し、SalesforceやGoogle広告、会計ソフトのデータをデータウェアハウス（DWH）に集約したものの、「分析結果が合わない」「BIツールでグラフが作れない」「結局Excelに書き出して手集計している」という壁に突き当たっていないでしょうか。Fivetranが担うのは、モダンデータスタック（MDS）における「E（抽出：Extract）」と「L（格納：Load）」です。しかし、ビジネス価値を生むには、その後の「T（変換：Transform）」、すなわち整形レイヤーの構築が不可欠です。

本記事では、日本国内のデータエンジニアリング実務に基づき、Fivetranで集計した「生データ（Raw Data）」を、どのようにして経営判断やマーケティング施策に直結する「使えるデータ」に変えるのか。その具体的な手順、アーキテクチャ、そして運用リスクの回避策を15,000文字規模の詳説で解き明かします。

1. Fivetran導入後に「データが使えない」と言われる3つの根本原因

データ統合の自動化（ELTのEL）を完了させた直後、多くの企業で「期待していたものと違う」という落胆の声が上がります。このギャップは、技術的な不足ではなく、データ構造の性質を理解していないことに起因します。

1-1. ELTパラダイムにおける「T（変換）」の不在

従来のETL（Extract, Transform, Load）では、DWHにデータを入れる前に加工を行っていました。しかし、計算リソースが安価で強力になった現代のモダンデータスタック（MDS）では、ELT、つまり「まずDWHに入れてから、DWH内で加工する」手法が標準です。

Fivetranはロードまでを完璧にこなしますが、DWH（SnowflakeやBigQueryなど）の中には、ソースシステム（Salesforce等）の複雑なテーブル構造がそのままコピーされます。この「生データ」は、正規化が進みすぎていたり、システム管理用のIDが乱立していたりするため、そのままBIツール（TableauやLooker Studio）で接続しても、人間が理解できるレポートにはなりません。

1-2. サイロ化したデータに潜む「粒度の不一致」

データ活用で最も頻発する問題が「粒度（データの細かさ）」のズレです。

• 広告データ： 「キャンペーン×日次」の集計済みデータ。
• CRMデータ： 「商談（Opportunity）単位」のトランザクション。発生は不定期。
• 会計データ： 「仕訳（Journal Entry）単位」。月次締めによって値が確定する。

これらを無理に結合しようとすると、1つの商談に複数の広告クリックが多重に紐付き、売上が数倍に膨れ上がる「二重計上」が発生します。整形レイヤーは、これらを共通の粒度（例：顧客ID単位、月次単位）に揃える「炊飯器」のような役割を果たします。

1-3. 意味論（セマンティクス）の欠如

システムごとに用語の定義が異なることも大きな障壁です。Salesforceでの「受注」と、freee会計での「売上計上」は、タイミングも金額も異なる場合があります。

関連記事：【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』

2. 整形レイヤーの主役「dbt」とモダンデータスタックの全体像

現在、整形レイヤーのデファクトスタンダードとなっているのがdbt (data build tool)です。

2-1. dbtとは何か：データエンジニアリングの民主化

dbtは、SQLを用いてDWH内のデータを変換するためのフレームワークです。従来の「ストアドプロシージャ」や「GUIベースのETLツール」と決定的に違う点は、**「SQLでロジックを書き、ソフトウェア開発の作法（バージョン管理、テスト、CI/CD）をデータの世界に持ち込んだ」**ことにあります。

2-2. 主要ツールの役割と機能・料金比較

モダンデータスタックを構築する際、どのレイヤーにどのツールを配置すべきか、以下の比較表にまとめました。

2-3. データ変換方式の比較：dbt vs 従来型

なぜ今、dbtが選ばれるのか。従来のストアドプロシージャ方式と比較すると、運用の安定性が劇的に向上します。

出典：dbt Labs 公式「What is dbt?」 — https://www.getdbt.com/product/what-is-dbt

3. 【実務手順】データ整形レイヤーを構築する10ステップ

Fivetranでデータをロードした後、具体的にどのような工程で「整形」を進めるべきか。プロの現場で行われる10のステップを詳説します。

ステップ1：ソースデータの棚卸しとスキーマ確認

Fivetranが作成した RAW スキーマ内のテーブル一覧を確認します。Salesforceであれば account, opportunity, user など、何百ものテーブルが作成されますが、最初からすべてを使う必要はありません。

ステップ2：Stagingレイヤーの作成（1対1の鏡）

元データに直接加工を加えるのは厳禁です。まずは stg_ という接頭辞をつけたモデルを作成し、以下の「お掃除」だけを行います。

• 不要なカラムの削除（個人情報やシステム用フラグなど）。
• カラム名の正規化（ id を customer_id に、 createddate を created_at に変更）。
• データ型のキャスト（文字列型のタイムスタンプを TIMESTAMP 型へ）。

ステップ3：重複排除とユニークキーの保証

SaaSからの連携データには、稀に重複レコードが含まれます。 dbt test を用いて、プライマリキーに重複がないか、 NOT NULL であるかを確認します。

ステップ4：Intermediateレイヤー（中間加工）

複数のテーブルを結合（JOIN）し、特定のビジネス概念を作ります。
例： stg_salesforce__opportunity と stg_salesforce__opportunity_line_item を結合し、「どの商談でどの商品が売れたか」という粒度の中間テーブルを作成します。

ステップ5：マスタデータの「名寄せ（Normalization）」

例えば、freee会計の「取引先名」とSalesforceの「アカウント名」で表記が揺れている場合（例：「株式会社」の有無）、正規化ロジックをSQLで記述、または外部の名寄せマスタ（Seedファイル）をdbtに読み込ませて結合します。

ステップ6：Martレイヤーの構築（スター・スキーマ化）

BIツールから参照するための「最終形」を作ります。ここでは、分析のしやすさを最優先し、数値を持つ「ファクトテーブル」と、属性情報を持つ「ディメンションテーブル」に切り分けます。

ステップ7：ビジネスロジックの実装（配賦・計算）

会計データにおいて、部門共通費を各部門の売上比率で按分するような「配賦ロジック」を実装します。

関連記事：【完全版・第5回】freee会計の「経営可視化・高度連携」フェーズ。会計データを羅針盤に変えるBIとAPI連携術

ステップ8：テストコードの実装

「売上の合計値がマイナスになっていないか」「商談終了日が開始日より前になっていないか」といったビジネスルールを dbt test として定義し、パイプライン実行のたびに自動検証します。

ステップ9：ドキュメント生成と共有

dbt generate-docs コマンドで、データの系統図（リネージ）と定義書を自動生成します。これにより、「この数字はどこから来たのか」という疑念を払拭します。

ステップ10：継続的統合（CI）の設定

GitHub等にコードをプッシュした際、自動的にテストが走り、問題がない場合のみ本番環境のデータが更新される仕組み（CI/CD）を構築します。

4. 業界別・データソース別の整形ベストプラクティス

データソースごとに、整形レイヤーで格闘すべき「固有の課題」があります。

4-1. CRMデータ（Salesforce等）：商談プロセスの可視化

Salesforceの生データは、現在の状態（Snapshot）を保持していますが、過去の推移（History）を追うのは苦手です。

整形ポイント： OpportunityFieldHistory テーブルを活用し、商談が「リード」から「受注」に変わるまでの各ステージ滞留時間を算出します。

実務のコツ： LAG 関数や LEAD 関数を使い、前のレコードとのタイムスタンプ差分を取ります。このとき、土日祝日を除外するロジックをdbtの macro として共通化しておくと便利です。

4-2. 会計データ（freee会計・勘定奉行等）：月次比較と配賦

会計データは「確定した過去」を扱いますが、管理会計（予算 vs 実績）を行うには工夫が必要です。

整形ポイント： 会計期間を月次単位で正規化します。また、freeeの deal データに含まれる「タグ」をパースし、属性情報としてフラットなカラムに変換します。

異常系への対応： 取消仕訳（赤黒処理）が行われた際、単純な集計では数値が合わないことがあります。計上日と更新日のどちらを基準にするかをビジネスサイドと合意し、SQLでフィルタリングを明示する必要があります。

4-3. 広告データ（Google/Meta/LINE等）：クロスチャネル分析

各媒体で「インプレッション」「クリック」などの用語は共通していますが、テーブル構造はバラバラです。

整形ポイント： Fivetranの「Ad Reporting」パッケージ等を利用して、各媒体のデータを共通のスキーマ（ユニオン）に流し込みます。

実務のコツ： キャンペーン名に特定の命名規則（例： [Summer_2024][Tokyo][Product_A] ）がある場合、正規化（REGEXP）を用いて「シーズン」「地域」「商品名」のカラムに分割します。

5. 整形レイヤー構築時のトラブルシューティングと異常系シナリオ

データパイプラインは「一度作れば終わり」ではありません。外部要因で容易に崩壊します。

5-1. スキーマ・ドリフト（Schema Drift）

SaaS側の担当者が、Salesforceに新しいカスタムフィールドを追加したり、既存フィールドの名前を変えたりすると、dbtのSQLがエラーで止まります。

対策： Fivetranにはスキーマ変更を検知して自動でDWHに反映する機能がありますが、dbt側では「明示的にカラムを指定する」記述を徹底し、 dbt test で異常を早期発見します。

5-2. APIレートリミットと同期の遅延

大量のデータを一度にFivetranで同期しようとすると、SaaS側のAPI制限に抵触し、同期が数時間止まることがあります。

対策： 全件同期（Full Refresh）ではなく、更新分のみを取り込む「増分更新（Incremental Sync）」が正しく設定されているか確認してください。また、更新頻度はビジネスの緊急度に合わせて最適化（例：会計は1日1回、広告は1時間1回）します。

5-3. 数値の不一致（二重計上）

JOINの条件が不適切な場合、1つの親レコードに対して複数の子レコードが紐付き、金額が倍増することがあります。

対策： Martレイヤーの最終出力直前で、 row_number() 関数を使用してユニーク性を担保するか、集計（GROUP BY）をかけてからJOINする「集計後結合」を徹底します。

6. 実務で必須となる「リバースETL」の活用事例

整形レイヤーで磨き上げたデータは、DWHの中に眠らせておくだけでは宝の持ち腐れです。これを現場のツールへ「逆流」させるのがリバースETL（Reverse ETL）です。

6-1. 事例：LTVに基づいた広告運用の自動最適化

あるEC企業では、Google広告のクリックデータと、バックエンドの購入データをSnowflakeで統合しました。dbtで「過去1年間の購入総額（LTV）」を顧客ごとに算出。この数値をリバースETL（Hightouch）経由でSalesforceの顧客担当者（CS）に通知すると同時に、Google広告の「オフラインコンバージョン」として戻しました。

結果： 高LTV顧客に類似したユーザーへ広告を配信する「類似オーディエンス」の精度が向上し、CPA（顧客獲得単価）が30%改善しました。

6-2. 事例：解約予兆検知とカスタマーサクセス

SaaS企業では、プロダクトの利用ログ（BigQuery）と契約情報（Salesforce）を整形レイヤーで結合。「直近2週間でログイン頻度が50%以上低下した有料顧客」というフラグを作成しました。

活用： このフラグをSlackやSalesforceの商談画面にリアルタイムで戻すことで、解約前にCS担当者がアプローチできる体制を構築しました。

関連記事：広告×AIの真価を引き出す。CAPIとBigQueryで構築する「自動最適化」データアーキテクチャ

7. 導入・運用に関するFAQ（よくある質問）

実務担当者や決裁者から寄せられる代表的な疑問に回答します。

Q1. dbt Cloudとdbt Core（オープンソース版）のどちらを選ぶべき？

A. 小規模な個人プロジェクトならdbt Coreで十分ですが、エンタープライズ（企業利用）であれば、ジョブのスケジューリング、実行ログの管理、IDE（開発環境）、セキュリティ（SSO連携）が備わった dbt Cloud を強く推奨します。運用のためのサーバー構築・管理コストを考えれば、有料版の方がROIが高いと言えます。

Q2. Fivetranの料金が高騰しないか不安です。

A. Fivetranは「MAR（Monthly Active Rows：月間アクティブ行数）」で課金されます。全データを15分おきに同期すると高額になりますが、「更新頻度を落とす」「不要なテーブルを同期対象から外す」「DWH側で一度取り込んだデータを削除しない（増分のみ取り込む）」といった工夫でコストをコントロール可能です。

Q3. データエンジニアがいなくても構築できますか？

A. SQL（SELECT文、JOIN、CASE式など）を正確に書けるアナリストがいれば、dbtによるモデリングは可能です。ただし、インフラ構築（DWHの権限設計、GitHub連携、CI/CD環境）については、最初に専門家（エンジニアまたは外部パートナー）による「土台作り」が必要です。

Q4. データの正確性は誰が担保すべきですか？

A. 技術的な整合性（データが欠落していないか等）はエンジニアが担当しますが、「ビジネス上の正しさ（この計算式で合っているか）」は各部門の責任者（オーナー）が承認すべきです。dbtのドキュメント機能を使い、ロジックを非エンジニアでも読める状態に保つことが、ガバナンスの第一歩です。

Q5. 導入期間はどのくらいかかりますか？

A. 環境構築（Fivetran + Snowflake + dbt）自体は数日で完了しますが、主要な3〜5つのデータソースを実用的なMartに落とし込むには、要件定義を含めて 3ヶ月程度 を目安にするのが一般的です。

8. まとめ：整形レイヤーこそがデータ駆動経営の「心臓部」である

「データを集める（EL）」段階は、いわば食材を市場から買ってきた状態です。しかし、そのままでは食べられません。dbtを活用した「整形レイヤー（T）」によって適切に調理（加工・結合・テスト）され、リバースETLによって食卓（現場のSaaS）に運ばれて初めて、データはビジネス価値という栄養になります。

日本国内でも、freeeやSalesforceなどの主要SaaSのAPI連携はFivetranによって劇的に簡素化されました。今、私たちが注力すべきは、その「運ばれてきたデータ」をいかに自社のビジネスロジックに適合させ、誰もが信じられる「単一の真実（Single Source of Truth）」を構築するか、という一点に尽きます。