Datastream の使い分け）¶

作成日: 2026-09-27 出典: Findy Tools「39社のデータ基盤アーキテクチャ特集」（2024-10-08 公開、各社レビューの公開抜粋）、レバレジーズデータAIブログ「Fivetran で ELT 処理を楽々実装しよう！」（2024-08-20）関連: 社内saasデータ統合基盤_ai活用_事例比較_整理 / gitlab_データ基盤_saas取り込み戦略と権限設計_整理 / layerx_コーポレートエンジニアリング_smarthr起点abacとn8n_整理 / メルカリ_arca_ai時代の高速プロトタイピング基盤_整理

注意: 出典はいずれも 2024 年時点の情報。各社の現在の構成とは異なる可能性がある（例: LayerX は当時すでに BigQuery → Snowflake 移行中と明記）。Findy Tools の各社アーキテクチャ図は会員限定で、本ノートは公開部分の文章のみに基づく。

0. 要点（3行）¶

一言で: 国内では「SaaS は trocco か Fivetran で DWH に生のまま入れ、変換は dbt に寄せる」がほぼ定番。取り込みツールは差別化要素ではなく、専任データエンジニアがいなくても回ることが選定理由の中心。
使い分けの型がある: trocco＝国内 SaaS（kintone 等）への対応と非エンジニアでも設定できること、Fivetran＝運用工数の削減と差分同期（タイミーは Embulk 時代の約7人日 → 1.5時間）、Datastream＝自社 DB の大量テーブル・ほぼリアルタイム。
取り込みの置き換えに備える設計が効いている: ドクターメイトは lake / warehouse / mart の3層で、転送ツールの接続先を lake に限定し「trocco を別の手段に替えても影響が小さい」構成に。M&Aクラウドは取り込み時に個人情報列を削除・ハッシュ化。

1. 定番構成¶

flowchart LR
    subgraph Src[ソース]
        SaaS[業務 SaaS<br>Salesforce・HubSpot・kintone<br>Zendesk・GA・広告]
        AppDB[自社アプリの DB<br>MySQL・Postgres・AlloyDB]
    end
    subgraph Ingest[取り込み]
        Trocco[trocco]
        Fivetran[Fivetran]
        DS[Datastream / Embulk]
    end
    subgraph DWH[DWH]
        Lake[(lake / raw<br>なるべく未加工)]
        WH[(warehouse)]
        Mart[(mart)]
    end
    SaaS --> Trocco
    SaaS --> Fivetran
    AppDB --> DS
    AppDB --> Fivetran
    Trocco --> Lake
    Fivetran --> Lake
    DS --> Lake
    Lake -->|dbt / Dataform| WH
    WH -->|dbt / Dataform| Mart
    Mart --> BI[BI<br>Looker・Tableau・Lightdash]
    Mart -.->|リバース ETL| SaaS

2. 企業別の要点¶

2-1. SaaS 取り込みが明記されている事例¶

企業	ソース	取り込み	DWH	工夫
M&Aクラウド	MySQL、Salesforce	trocco	BigQuery	転送時に個人情報列を削除、一部列をハッシュ化。想定外の使い方として MySQL → Salesforce のリバース ETL にも使う
ドクターメイト	各種（kintone が決め手）	trocco	BigQuery（3層）	lake / warehouse / mart のプロジェクト群を分離。trocco の転送先は lake のみ → 転送手段を替えても影響が小さい
アソビュー	GA など Google 系	trocco	BigQuery	サービスアカウントの BigQuery への書き込み権限の向きを統一し、データの出どころを分かりやすくした。BI は Tableau に統一
スペースマーケット	GA、Amplitude、Zendesk など	（記載なし）	BigQuery	Looker 導入と同時に DWH を選定。社内のサードパーティツールのデータを BigQuery に集約し Looker で可視化
レバレジーズ	MySQL、Postgres、Mailchimp、HubSpot、AppsFlyer、Salesforce	Fivetran（Embulk から全面移管予定）	BigQuery	Fivetran のメタデータ列を除き日時型をキャストした参照用ビューを作って利用者に見せる

2-2. 取り込みツールの使い分けが明記されている事例¶

企業	使い分け
atama plus	trocco＝外部 SaaS や新規アプリ向け、Datastream＝転送テーブルが多くリバース ETL もしたいアプリ向け。まず trocco で始め、staging 環境が必要になったドメインから IaC・ワークフローエンジンとの相性を見て Datastream に移行
マイベスト	データ抽出とリバース ETL を trocco に集約して、データソースの所在と状態を把握しやすく。マートの作成方針と SQL レビューのため Dataform と併用
コミューン	trocco は転送だけ。加工は dbt Cloud
ノバセル	trocco を ETL / リバース ETL に。UI が分かりやすく、ビジネスサイドも設定している。DWH は Snowflake、管理に Terraform と dbt
タイミー	Fivetran を連携の第一選択に。国内 SaaS 等の未対応コネクタは by request program で対応を依頼できる。Embulk 時代の約7人日分の運用タスクが1.5時間に（導入前後の半年比較）
WED	アプリの DB（AlloyDB）は Datastream で BigQuery へ。他社提供データは Cloud Composer で取り込み
LayerX（2024年時点）	取り込みは実装速度・料金・保守コストのバランスで OSS / SaaS を選定。Raw のまま取り込み、変換は dbt に寄せる。当時 Snowflake へ移行中

3. trocco と Fivetran の選び分け¶

公開レビューの傾向（Findy Tools 編集部コメントと各社レビュー）から整理。

観点	trocco	Fivetran
強み	日本の SaaS への対応（kintone 等）、手厚い日本語サポート、非エンジニアでも設定できる UI	コネクタ数、差分転送・削除データの同期、ドキュメントとサポートの質
典型の利用者	専任データエンジニアがいない会社、ビジネスサイドも触る会社	開発・保守工数を最小化したい少人数チーム
付加機能	データマート生成、ジョブ管理、リバース ETL	RDB の差分同期（Teleport Sync）、CDC
課金	（本ノートでは未確認）	月間に更新があったレコード数（MAR）に応じた課金

Fivetran を使うときの注意点（レバレジーズの実体験）¶

flowchart TB
    F[Fivetran で SaaS を同期] --> P1[Salesforce の数式項目<br>formula field は同期されない]
    F --> P2[Marketo はスキーマを見るのに<br>全データ同期が必要・API 容量超過]
    F --> P3[差分のたびに BigQuery で MERGE<br>DWH 側の更新コストが膨らむ]
    F --> P4[SaaS の更新レコード数が<br>想像以上に多いことがある]
    P1 --> A1[数式は dbt 側で再実装するか<br>別手段で取得]
    P3 --> A3[Fivetran の MAR だけでなく<br>DWH 側の費用も合算で監視]

Salesforce の数式項目（formula field）は連携されない。Fivetran が差分検知に使う SystemModStamp が数式項目の変更を反映しないため。他オブジェクトを集計する数式が多いと、それ抜きでは使えるデータにならない
Marketo は同期するまでスキーマが見えない。API 容量制限があり、1オブジェクト同期するたびに容量超過で1日使えなくなることも
DWH 側の課金: 差分は BigQuery で MERGE 文として反映されるので、同期頻度を上げると DWH の更新コストが増える。「MAR は大したことないのにトータルでは大きな金額」になりうる
Standard プランではコンソールでログを見られない（コネクタで BigQuery にログを出して確認）

4. 権限・個人情報の扱いで参考になる点¶

企業	やり方
M&Aクラウド	取り込み時点で個人情報列を削除・ハッシュ化（DWH に入れない）
PREVENT	生データの「ソース Layer」と加工後の「プロダクト Layer」に分け、個人単位の医療情報を含むソース Layer のアクセス権を限られた開発メンバーのみに
アソビュー	サービスアカウントの書き込み権限の向きを統一し、出どころを追えるように
ナウキャスト	データは基本1アカウントに集約しつつ、適切な権限の Role を簡単に作れる仕組みを用意（Snowflake + Terraform + dbt）
WED	巨大テーブルにはパーティションフィルタを必須に。INFORMATION_SCHEMA からクエリ履歴とコストを監視

PoC 環境やエージェントにデータを開くとき（メルカリ_arca_ai時代の高速プロトタイピング基盤_整理 8-5）は、M&Aクラウド型の「入口で落とす」と PREVENT 型の「層で分けて生データ層を絞る」の両方が効く。

5. まとめ¶

一言で: 「取り込みは買う、変換は dbt、置き換えに備えて層を分ける」。

状況	推奨	参考
専任データエンジニアがいない	trocco か Fivetran で始める	atama plus、エムスリーキャリア、コミューン
kintone など国内 SaaS が主	trocco（または Fivetran の by request）	ドクターメイト、タイミー
自社 DB のテーブルが多い・準リアルタイム	Datastream / Fivetran の CDC	atama plus、WED、レバレジーズ
取り込みツールを将来替えるかも	lake 層だけを転送先にし、下流は dbt	ドクターメイト
個人情報を DWH に入れたくない	取り込み時に列を削除・ハッシュ化	M&Aクラウド
Salesforce の数式項目が必要	Fivetran では来ないので dbt で再実装か別手段	レバレジーズ
同期コストが読めない	ETL の課金と DWH の MERGE コストを合算で見る	レバレジーズ

参考リンク¶

Findy Tools「39社のデータ基盤アーキテクチャ特集」（2024-10-08）: https://findy-tools.io/articles/data-review/28
レバレジーズデータAIブログ「Fivetran で ELT 処理を楽々実装しよう！」（2024-08-20）: https://analytics.leverages.jp/entry/2024/08/20/180000
trocco で Salesforce のデータを BigQuery に連携してみた（Zenn / Cloud Ace）: https://zenn.dev/cloud_ace/articles/d8d22e63f86a3b

作成: 2026-09-27 ／最終更新: 2026-09-27