LendInvest2008年ロンドン創業、英国最大級のノンバンク住宅ローン貸し手。機関投資家と非典型的な借り手をつなぐフィンテック。本社ロンドン。
非典型的な住宅ローン借り手と貸し手をつなぐ（データ処理時間を11分の1に、重要データ問題の検知を大幅に高速化）
11xデータ処理時間の短縮
10sほぼリアルタイムで検知される問題の件数（数十件）
125%事業上重要なデータ問題を特定するまでの時間短縮
10分問題切り分けにかかる時間（従来1時間、少なくとも100%高速化）
MySQLのレガシーDWHとPython/SQLスクリプトでは、審査・サービシング・社内ローンエンジンの3システム間のデータ不整合を検知できず、FCA（英金融行為規制機構）への誤報告リスクを抱えていた。dbt Cloudでローンデータを正規化し、カスタムアサーションテストとSynqの重要度別アラートで突合を自動化。12時間間隔だった処理をほぼリアルタイム化し、アラートは四半期単位から毎時に、デバッグは1時間から10分に短縮した。
導入前（顧客の声）- レガシーのMySQL DWHとPython/SQLスクリプトでは、数千のデータモデルとダッシュボードを支えきれない。
- 審査プラットフォーム・サービシング・社内ローンエンジンの3システムで、ローン金額や金利などが一致しない小さなエラーが見つかる。誰かが片方だけ直したり、レポート後に遡って変更したりする。
- 「FCAに誤った内容を提出すれば罰金になる。間違いが続けば規制で退場させられかねない。」
- 「過去を再現できなかった。end-to-endで実行するには処理順序を知っていなければならず、レガシー基盤では信頼して動かせなかった。」
dbtでやったこと- dbt Cloudで3つの基幹システムからローンデータを抽出・変換し、比較可能な形式に正規化。
- ローン金額・金利などの項目差異を検知するカスタムdbtアサーションテストを作成し、新規ローンをほぼリアルタイムで下流モデルと突合。
- データ信頼性プラットフォームSynqで重要度に応じてアラートを振り分け（高重要度は上級ステークホルダーへ即時、低優先度は運用担当へ）、Metabaseで差異を確認して確認済・修正済・許容として記録する監査証跡を構築。
- 整合性、ソース鮮度、例外、異常検知の各アラートを整備。重要50テーブルは30分ごとに行数の volume monitor で監視。
こうしたアラートを四半期ごとではなく毎時受け取れるようになりました。異なるレベルでアラートを出せるということです。整合性アラート、ソース鮮度アラート、例外アラートがあり、最近は異常検知アラートも追加しています。
Rupert Arup, Data Team Lead, LendInvest
営業での使いどころ「基幹3システム間のローンデータ突合をdbtテストで自動化し、規制当局への誤報告リスクを毎時検知に変えた」事例として、金融庁報告や勘定系・審査系の整合性に悩む貸金・銀行顧客に使える。
製品・スタックdbt Cloud · custom assertion tests · source freshness ／ AWS, dbt Cloud, Synq, Tableau, Metabase
残り13件を表示Lendi、Nasdaq、Ramp、Bilt Rewards、Nitrogen、Norges Bank Investment Management (NBIM)、Blend、Fundrise、Pepperstone、Bilt Rewards、Rocket Money、Zip、M1 Finance
Lendiオーストラリア最大級のデジタル住宅ローンプラットフォーム。急成長フィンテックLendi Group傘下で、Aussie Home Loansブランドと並走。本社シドニー。
Lendi、dbtと信頼できるデータでAIネイティブな未来を築く（dbt Coreからdbt platformへ30日で移行、ダウンタイム0）
30日でdbt Coreからdbt platformへ移行
0移行中のダウンタイム
0本稼働後のプラットフォーム障害件数
16時間/月エンジニアリングチームのプラットフォーム管理工数の削減（平均）
dbt Coreと外部オーケストレーションによるセルフホスト環境の維持に工数を取られ、パイプライン障害やレポート鮮度低下が起きていた。セルフホスト継続コストとdbt platformを比較した上で、パートナーData Armyと共に30日・ダウンタイム0で移行。稼働後の障害は0件、エンジニアの運用工数を月16時間削減し、分析開発の貢献者を10人増やした。
導入前（顧客の声）- 経営・オペレーション・財務・マーケから分析要望が増える一方、エンジニアはdbt Coreと外部オーケストレーションのセルフホスト環境の保守に追われている。
- プラットフォームが不安定でパイプラインが失敗し、意思決定に必要なタイミングでレポートが古いままになる。
- 開発環境が複雑で、データエンジニアリング・分析・データサイエンス・AIエンジニアリングの各チームがdbtパイプラインに安全に貢献できない。
- 開発速度の低下で分析案件が滞留し、2026年のAIネイティブ化という全社目標に対してデータ基盤がボトルネックになっている。
dbtでやったこと- コンピュート・保守・サポート・機会損失を含むセルフホストの総コストをdbt platformと詳細比較し、dbt platformへの移行を決定。
- dbtコンサルタンシーData Armyと協働し、Terraformでプラットフォームを構成、Microsoft Entraと連携してロールベースアクセス制御、Bitbucketとリポジトリ連携。
- 移行はダウンタイム0で完了、第2フェーズは1週間以内に完了。複数プロジェクト・チーム・ジョブを支える構成に。
- Web IDE、dbt Mesh、dbt Copilotで複数チームが共有パイプラインに安全に貢献できる体制を構築。
Data ArmyはLendiで一貫して卓越した価値を提供してくれました。素早く文脈を吸収し、我々のスクワッドにシームレスに溶け込み、初日から意味のある成果を出してくれました。彼らの貢献は、AIネイティブというビジョンの実現と、事業全体で加速するイノベーションに向けて、我々を強く後押しし続けています。
Frank Colubriale, Data Product and Enablement Lead, Lendi Group
営業での使いどころ「dbt Coreセルフホストの総コストを試算してdbt platformに30日・無停止で移行し、パートナーSIが実装を担った」事例として、Core運用に疲弊した金融顧客とSI協業の両方に使える。
製品・スタックdbt platform · dbt Core · Web IDE · dbt Mesh · dbt Copilot ／ dbt platform（Terraform、Microsoft Entra、Bitbucketと連携）。パートナー: Data Army
Nasdaq北米・北欧で30の証券取引所を運営し、4,000社超の上場企業を擁する金融市場インフラ。130市場・2,200の金融機関にテクノロジーを提供。1971年創業、本社ニューヨーク。
金融市場のグローバルエンジン、クラウドで分析に踏み出す（1日1,000〜1,250億件のトランザクション、55名のビジネスユーザーをモデリングに参画）
100-125 billion1日に処理するトランザクション数
55モデリング・レポーティングに参画したビジネスユーザー数
10分1日150〜200億メッセージのモデルの実行時間（従来45分〜1時間）
6xデータレイク移行によるデータ基盤の最適化
取引システムのデータは性能最適化されていて分析に不向きで、Pentahoと大量のSQLスクリプトによるレガシー基盤ではビジネスユーザーが参加できず、レポート依頼に数週間〜数か月かかっていた。dbt Cloudとdbt Labsサービスチームの支援で数週間で本番実装し、オプション事業を皮切りに数百のモデルを整備。営業・経営層が自らデータを見られるようになり、1日150〜200億メッセージのモデルは45〜60分から10分に短縮した。
導入前（顧客の声）- 「取引システムのデータは本当に複雑。性能のために最適化されていて、クエリや分析のためではない。」2020年以降は1日1,000〜1,250億件に増加。
- ビジネスユーザーはチケットを出してレポートを待つしかなく、4つのデータチームのどこが何を担当しているかも不明確で混乱と重複が生じていた。
- Pentahoと「あちこちで動く大量のSQLスクリプト」がビジネスユーザーの参加を阻んでいた。
- 「担当者が退職するとSQLスクリプトの中身が誰にも分からず、コードを書き直すしかなかった。」
dbtでやったこと- ツールではなくエンドユーザー（営業・経営層）起点で選定し、dbt Cloudでビジネスユーザーがデータロジック変換に参加できる体制を構築。
- dbt Labsのサービスチームがアナリストの環境構築を支援し、数週間で本番実装。大規模ロールアウトでも設定やモデル最適化を伴走。
- 最も競争の激しいオプション事業から着手し、日々使う主要モデルにつながる数百のモデルを整備。
- 1日150〜200億メッセージを処理するモデルの性能問題をdbt Labsサービスチームと解消し、実行時間を45分〜1時間から10分に短縮。
最近、1日150〜200億メッセージを処理するモデルで性能問題がありました。dbt Labsのサービスチームがそれを解決してくれました。1日の実行に45分から1時間かかっていたモデルを、10分まで短縮してくれたのです。
Michael Weiss, Senior Product Manager, Nasdaq
営業での使いどころ「取引所レベルの超大量データでも、dbt Cloudとエンタープライズ支援でビジネスユーザー55名をモデリングに巻き込みセルフサービス化した」事例として、証券・市場インフラ系の大手顧客に使える。
製品・スタックdbt Cloud · dbt Labs services team (Enterprise support) ／ dbt Cloud、クラウド上のデータレイク（レガシー: Pentaho、SQLスクリプト）。Atlan、Monte Carloを統合中
Ramp法人カードと経費・請求書支払い・会計自動化を提供する財務自動化プラットフォーム（2019年創業）。決済額50億ドル超、1万社超・20万人超のカードホルダー、企業価値81億ドル。本社ニューヨーク。
Ramp、Snowflake・dbt・Hightouchのモダンデータスタックでデータ基盤コスト20%削減、変換速度33%向上、営業パイプラインの25%を創出
20%データプラットフォームコストの削減
33%データ変換ジョブの高速化
25%新設のアウトバウンド自動化チーム（OATs）が生む営業パイプラインの割合
3x直近12か月でのデータチームの増員
収益10倍・カードホルダー15倍という急成長でデータチームが3倍に増え、旧データウェアハウスは同時アクセスでデッドロックを起こし、テストもバージョン管理もないモデルから指標のばらつきが生じていた。Snowflakeを単一情報源に、dbtで指標を標準化して全変換ジョブを自動化、HightouchでSalesforce等へ還流。基盤コストを20%削減、変換を33%高速化し、dbtモデルを活用したアウトバウンド自動化チームが営業パイプラインの25%を生み出している。
導入前（顧客の声）- 直近12か月でデータチームが3倍になり、同時アクセスの問題で旧データウェアハウス全体がデッドロックして誰もデータに触れなくなる。
- 「前のデータウェアハウスのスケーリングで多くの問題が出た。ただ動かし続けるためにワークロードの微調整に時間を取られすぎていた。」
- Postgres、Salesforce、Hubspot、Zendesk、Outreach、各広告プラットフォームからのデータを変換するインフラを都度立ち上げるのが困難。
- テストもバージョン管理もなく手作業でデータモデルを作っていたため、コア指標にばらつきが出ていた。
dbtでやったこと- フルマネージドのSnowflakeを単一情報源として採用し、デッドロックや運用管理から解放。
- dbtでコア指標セットを標準化し、すべての変換ジョブを自動化・スケジュール実行。新しいデータ製品を本格投入する前の検証場としても活用。
- dbtジョブで顧客データを集約・変換・エンリッチして360°顧客ビューを構築し、リスクプロファイルやアプリ・Web・マーケのパーソナライズに利用。
- HightouchのReverse ETLでdbtモデルをSalesforce・Hubspot・Outreach・広告プラットフォーム・Postgres（審査プロセス自動化）へ同期。
すべてのモデルはdbtで生まれ育っています。きれいなデータといえば、みんなdbtモデルを思い浮かべます。Rampでdbtが支えていないものはほとんどありません。
Kevin Chao, Senior Analytics Engineer, Ramp
営業での使いどころ「dbtで標準化した顧客360°モデルを営業ツールに還流し、営業パイプラインの25%を生んだ」事例として、データ基盤投資を売上貢献で語りたい法人決済・フィンテック顧客に使える。
製品・スタックdbt · tests · version control · scheduled jobs ／ Fivetran, Snowflake, Airflow, dbt, Hightouch, Looker, Retool, PostgreSQL
Bilt Rewards家賃支払いでリワードが貯まるプラットフォーム。年間400億ドル超の家賃・HOA支払いを処理し、前年の3倍超に成長。本社ニューヨーク。
データで築くレンター向けリワードプログラム（dbt Labs Resident ArchitectでBigQueryコストを月2万ドル削減、10倍速の実装）
$20K/月BigQueryコストの削減額
10x実装スピード（数か月ではなく数時間でコスト削減を実現）
99%主要データセットのスキャンデータ量削減
$40B超年間の家賃・HOA支払い処理額（前年の3倍超）
毎日数百万件のトランザクションを全量再処理するBigQueryコストが膨らみ、データ形状の特殊さからインクリメンタルモデル化が自力では難航していた。dbt Labsプロフェッショナルサービスの Resident Architect が既存実装を診断してスケーラブルな修正パターンを導入し、主要データセットのスキャン量を99%削減。月2万ドルのコスト削減を数か月ではなく数時間で実現した。
導入前（顧客の声）- 毎日数百万件のトランザクションを扱っており、更新のたびにデータセット全体を再処理するコストが無視できない。
- データソースの形状が特殊で、インクリメンタルモデル化を試みたが技術的に難しく、コストも高いままだった。
- 「複雑なインクリメンタルモデルを考える時間がチームにない。自前でやれば数日から数週間かかる」状態。
- 経営陣にとってウェアハウスコストの抑制は最重要課題で、試行錯誤している間もコストは増え続ける。
dbtでやったこと- dbt Labsプロフェッショナルサービスの Resident Architect を起用し、データソース・ウェアハウスログ・性能問題・既存ワークフローを診断。
- 初期実装にスケーラブルで再利用可能な修正を加え、主要データセットのスキャン量を99%削減。
- モデリング規約、複数プロジェクトを分ける適切なタイミング、ジョブスケジュール最適化など運用の型を整備。
- カスタムテストやテストパッケージ、dbt Mesh、マルチスレッドプロジェクト、BigQueryのauthorized view権限付与最適化など発展的テーマも伴走支援。
Resident Architectのおかげで、主要データセットでスキャンするデータ量を99%削減できました。
Ben Kramer, Senior Director of Data Analytics, Bilt Rewards
営業での使いどころ「インクリメンタル化の専門家伴走でスキャン量99%減・月2万ドル削減を数時間で」の事例として、ウェアハウスコストに悩む顧客へのアーキテクト常駐型サービス提案の根拠に使える。
製品・スタックdbt Cloud · dbt Labs Professional Services (Resident Architect) · incremental models · dbt Mesh · custom tests ／ dbt Cloud, BigQuery, Github
Nitrogen2011年に「Riskalyze」として創業したウェルスマネジメント向け分析・コンプライアンスSaaS。カストディアンや銀行など数十社とのデータ連携を提供。本社カリフォルニア州オーバーン。
Nitrogen、dbt Cloudとモダンデータスタックでデータ連携の構築期間を50%短縮、運用コストを2〜4分の1に
50%データ連携の構築・納品期間の短縮（6週間で納品）
30%データセット配信の高速化（日次取込が4分未満）
2-4x従来ETLパイプラインと比べた運用コストの低減
6週間従来より少人数で新規データ連携を納品した期間
MySQL/Postgresと自社製変換アプリによるレガシー基盤では新規データ連携に四半期以上かかり、6週間で連携を求める中堅顧客の要件に応えられなかった。dbt CloudとSnowflakeを2名で立ち上げ、6週間で連携を納品。日次取込は4分未満で30%高速化、運用コストは2〜4分の1になり、レガシーDBの段階廃止を進めている。
導入前（顧客の声）- 数百名のアドバイザーを抱える中堅顧客から「契約開始前の6週間以内に新しいデータ連携を」と求められたが、レガシーパイプラインでの連携構築は通常四半期以上かかる。
- MySQL・Postgresと自社製の変換アプリケーションで構成された基盤はスケールせず、開発にも忍耐が必要。
- JSONオブジェクトを使ったデータ変換ロジックやカスタムアプリが複雑すぎる。
- 口座・ポジションデータが毎朝市場開始前に届かなければ、顧客であるアドバイザーは商品を使えない。データは製品価値そのもの。
dbtでやったこと- 投資家HGの推薦を受けてdbt Cloudを評価。SQLベースで習得が容易、コスト効率も良く「期限内に連携を納品できる唯一の選択肢」として採用。
- dbt CloudとSnowflakeで部門横断のハッカソンを実施して初期知見を獲得し、そのまま本番用途の連携構築へ。
- Director of Platform Engineeringと主任データエンジニアの2名で、最初のデータ連携を6週間で納品し顧客を獲得。
- dbt Labsトレーナーによる3週間・6コースのdbt Learnで残りのメンバーを迅速にオンボード、録画を新人教育にも活用。
過去のどの連携プロジェクトよりも少ない人数でしたが、たった6週間で連携を納品できました。同規模のプロジェクトにこれまでかかっていた時間のちょうど半分です。
Andrew Waters, Director of Platform Engineering, Nitrogen
営業での使いどころ「レガシーRDB＋自社製ETLからdbt Cloud＋Snowflakeへ移行し、2名・6週間で新規データ連携を納品、運用コスト2〜4分の1」として、少人数で顧客向けデータ連携を回す金融SaaSへの提案に使える。
製品・スタックdbt Cloud · dbt Learn · lineage ／ Snowflake, dbt Cloud, DOMO, Snowpipe, Github
Norges Bank Investment Management (NBIM)ノルウェー政府系ファンド（世界最大級）を運用する機関。運用資産2兆ドル超、世界の上場企業の約1.5%を保有。オスロ・ニューヨーク・シンガポールの投資チームを支えるデータ基盤を運営。
グローバル投資機関、dbt Fusion engineで実行時間を30〜40%短縮
30-40%エンドツーエンド実行時間の短縮（専用の最適化なし）
3か月dbt Fusion engineのロールアウト期間
5Fusionとdbt Stateで本番化したプロジェクト数
150+dbt開発者数（30超の分散プロジェクト）
150名超のdbt開発者と30超の分散プロジェクトに拡大し、技術系エンジニアとコードを書く事業部門の間で開発体験の差が課題になっていた。小規模で構造の良いプロジェクトから dbt Fusion engine と dbt State（state-aware orchestration）を3か月で展開し、5プロジェクトを本番化。最適化なしでもエンドツーエンド実行が30〜40%速くなり、パース・リンティングの改善で事業部門もより高品質なプロジェクトを作れるようになった。
導入前（顧客の声）- dbt開発者が150名超、分散プロジェクトが30超に拡大し、チームに負荷がかかっていた。
- 「AIエージェントやCursorのようなコーディングツールを多用している。技術系データエンジニアと、コードは書くが構造化が苦手な事業部門との差を埋めたかった。」
- 大規模パイプラインは夜間バッチ中心で、シンガポールのチームが検証して各タイムゾーンのポートフォリオマネージャーに早朝までにデータを届けるという厳しいSLAがある。
- パイプラインをより頻繁に回したいが、実行時間が伸びるのが懸念。
dbtでやったこと- 開発体験の改善を主目的にdbt Fusion engineを検討、dbt State（state-aware orchestration）は副次効果として位置づけ。
- 複雑なレガシープロジェクトからではなく、モデル数が少なく構造の良い小規模プロジェクトから着手し、3か月で5プロジェクト（プラットフォームメタデータ、広報インサイト、投資データ）を本番化。
- ユーザーのオンボーディングと並行して持続可能なペースで展開し、大きなトラブルなく移行。
- dbt Stateによりオーケストレーションを軽くし、実行時間を増やさずにモデル・パイプラインをより頻繁に実行。
SAO（dbt State）のおかげでオーケストレーションを軽くでき、実行時間を増やすことなくモデルとパイプラインをより頻繁に実行できます。下流でのコスト最適化にもつながると確信しています。
Øyvind Barsnes Eraker, Senior Data Engineer, Norges Bank Investment Management
営業での使いどころ「150名超・30超プロジェクトの大規模dbt環境で、小さく始めてFusion engineを3か月で展開し実行時間30〜40%短縮」として、Fusion移行の進め方と効果を大手資産運用・金融機関に示す事例に使える。
製品・スタックdbt Fusion engine · dbt State / state-aware orchestration ／ dbt Fusion engine, Snowflake, Fivetran, Tableau, Cursor
BlendWells Fargoなどの大手金融機関に住宅ローン申込などのデジタルバンキング基盤を提供するエンタープライズ向けクラウドバンキングプラットフォーム。毎日数十億ドルの取引を処理。本社サンフランシスコ。
Blend、dbt CloudとMonte Carloでデータモデリングと信頼性をスケール（社内POC比で価値創出まで4か月短縮）
4か月社内POCフレームワーク比での価値創出（time-to-value）短縮
100%自動監視を展開した本番テーブルの割合
32 / 12データソース数 / データを利用するチーム数
Airflowで手動スケジュールしたSQLクエリに依存し、データエンジニアリングがボトルネックになり、品質監視の欠如で収益数値が歪む事故も起きていた。自作の品質監視POCはRedshiftを圧迫して失敗。dbt CloudのモジュールSQLでアナリストがセルフサービス開発できるようにし、Monte Carloで本番テーブル100%を自動監視。価値創出までの期間を社内POCより4か月短縮し、顧客向けデータ製品のSLA遵守とコンピュートコスト削減を実現した。
導入前（顧客の声）- 32のデータソースと12の利用チームを、3つのデータチームがAirflow上の手動スケジュールSQLクエリで支えていて、再デプロイ修正が絶えない。
- 変換依頼のたびにデータエンジニアリングを待つしかなく、プロダクト分析チームは優先案件が止まるかアナリストが待たされるかの二択。
- 「収益数値が歪む事故があった。データ品質をきちんと計算できていなかったからだ。」
- 自作のデータ品質POCは検証クエリがウェアハウスを圧倒し、Redshiftクラスタのクエリ時間とCPUを食い潰した。
dbtでやったこと- Airflow上のSQL運用の自然な進化としてdbt Cloudを採用し、ソフトウェアエンジニアリングのベストプラクティスを導入。
- モジュール化されたSQLでアナリストが「アドホックなエンジニア」としてセルフサービスで変換を開発し、エンジニアは優先案件に集中。
- マイクロサービスのJSON blobに埋もれた外部キーなどをdbtで事前処理し、ダッシュボードツールが効率よく参照できるテーブルを構築してコンピュート負荷を削減。
- Monte CarloのノーコードML監視を本番テーブル100%に自動展開（鮮度・件数・スキーマ変更）。メタデータベースで軽量なためウェアハウス性能への影響が小さい。
Blendは大手金融機関のデータを扱うエンタープライズソフトウェアなので、データそのものが製品です。dbtがなければ、顧客に自分たちのデータの可視性を提供するという契約を守れないでしょう。あるいは、これらの製品を出すまでに何か月も余計にかかっていたはずです。
Noah Hall, Product Analyst, Blend
営業での使いどころ「Airflow手動SQLからdbt Cloud＋Monte Carloへ移行し、金融機関向けデータ製品のSLAと品質監視を両立した」事例として、金融機関にデータを提供するSaaS・BPO事業者への提案に使える。
製品・スタックdbt Cloud · modular SQL ／ Snowflake, dbt Cloud, Monte Carlo（レガシー: Airflow, Redshift）
Fundrise個人投資家にオルタナティブ投資への直接アクセスを提供する投資プラットフォーム。40万人超の投資家から30億ドル超を運用。本社ワシントンD.C.。
急成長するオルタナティブ投資プラットフォーム（新規データソース追加の時間を50%超短縮、パイプライン保守はほぼゼロ）
>50%新規データソース追加にかかる時間の短縮
0データパイプライン保守に費やす時間（ほぼゼロ）
$3B超運用資産額（40万人超の投資家）
「できるだけ低コストに」設計したレガシー分析基盤が、ユーザー数と製品の複雑化に耐えられず、少人数のデータチームは保守とトラブル対応に追われ数値エラーが増えていた。dbt CloudでSnowflake上のデータを整理し直し、テスト・ドキュメント・リネージ・アラートを整備。新規データソース追加の時間を50%超短縮し、保守時間はほぼゼロになり、事業部門のセルフサービス分析が広がった。
導入前（顧客の声）- 初期の「最小限のオーバーヘッドで最良の結果を」という割り切った構成が、ユーザー数・データ量・製品複雑性の指数的な増加に耐えられない。
- 「追加した複雑さのせいで、データが常に正しい状態を保てなくなった。しばらくは継ぎ接ぎで凌いだが、もう成り立たないのは明らかだった。」
- 少人数のデータチームが保守とトラブルシュートに膨大な時間を取られ、改善や新しい取り組みに手が回らない。
- マーケティングのアトリビューション数値が正しいか、毎日手作業で確認しなければならなかった。
dbtでやったこと- 社内事情に不慣れなエンジニアを採用・育成するより、ツール投資の方が効率的と判断し、dbt Cloudを採用。
- dbt CloudでSnowflake上のデータソースを整形し、Tableauで可視化する構成に移行。移行を機にデータウェアハウスを統一・再整理。
- dbt Cloudのテスト、自動ドキュメント、リネージ、エラーアラートを活用してトラブルシュート時間を削減し、データの正確性への信頼を回復。
- ドキュメントをステークホルダーに公開し、事業部門が自らダッシュボードを構築するセルフサービス分析を実現。
Fundriseには「アナリティクスエンジニア」という職種がありません。dbt Cloudがとても扱いやすいからです。SQLが書けるアナリストならdbtを習得できます。技術力よりビジネス感覚を優先して採用できるようになったのは、大きな解放です。
Jack Ploshnick, Analytics Manager, Fundrise
営業での使いどころ「エンジニア増員ではなくdbt Cloud導入で保守ゼロ・セルフサービス化を実現した少人数データチーム」の事例として、人手不足の中堅金融・資産運用会社に使える。
製品・スタックdbt Cloud · tests · auto-generated documentation · lineage · error alerting ／ Mixpanel, Snowflake, Fivetran, dbt Cloud, Tableau
Pepperstone2010年創業の世界有数のFXブローカー。30万人超のトレーダーを抱え、1日平均125億米ドル超の取引を処理。世界各地に拠点、本社メルボルン。
大手FXプレイヤー、dbt Cloudでレポート不整合を80%削減、デリバリー速度を30%向上
30%リネージ・データ民主化・新ワークフローによるデリバリー速度の向上
80%レポート不整合の削減（トラブルシュート容易化とソース・モデルのテストによる）
10件/月下流に影響する前に特定・解決した不整合データソース数
Redshift上の分析スキーマからTableauへ直接テーブルを作る構成では、データソースが増えるにつれリネージを見失い、同じ収益・継続率指標がダッシュボードごとに違う数字で出て経営層の信頼を失っていた。dbt Cloudのリネージ・ドキュメント・テストで信頼できる単一情報源を再構築。レポート不整合を80%減らし、月10件のソース側不整合を下流影響前に検知、デリバリー速度を30%高め、全社共通のドキュメントも初めて整備した。
導入前（顧客の声）- Redshiftの分析スキーマからTableau用のテーブル・ビューを作る構成が、新しいソースとメンバーの増加で天井にぶつかり、データセットが膨張してリネージが分からなくなった。
- 「上流の変更がTableauに出る下流データセットにどう影響するか追えなくなり、同じ指標が複数のダッシュボードで違う数字になることがよくあった。」
- 「FXは価格が1ミリ秒ごとに変わる業界。小さな不正確さが非常に大きなレポート問題に膨らむ。」
- 経営層が数字への信頼を失い、他部門が古いスプレッドシートから独自に数字を引いて意思決定するようになった。
dbtでやったこと- 元同僚の推薦で小さなプロジェクトからdbt Cloudを試し、視覚的なリネージ（DAG）を見た瞬間に採用を決定。
- レポート不整合を年間数件まで抑える目標を掲げ、最重要レポートに包括的なテストカバレッジを整備。「不正確なレポートを送るより遅らせる方がよい」を原則に。
- DAGとドキュメントでリネージを明確化し、新しいデータソースを追加・更新しやすい運用に。全社共通のデータソースドキュメントを初めて公開。
- Jinjaテンプレートとマクロでアナリストのスキルの天井を引き上げ、より多くのメンバーがデータモデリングに貢献。
リネージを見た瞬間に、dbtは我々に合うと確信しました。視覚的なので他の人に説明するのも簡単でした。読めばいい、実際に目で見えるのですから。
Sam Ellett, Lead Data Scientist, Pepperstone
営業での使いどころ「ダッシュボードごとに違う数字が出る問題をdbt Cloudのリネージとテストで80%削減し、複数国のライセンス規制対応にも耐える基盤にした」事例として、証券・FX・暗号資産系の顧客に使える。
製品・スタックdbt Cloud · lineage (DAG) · documentation · tests · Jinja / macros ／ Amazon DMS, Redshift, dbt Cloud, Airflow, Tableau, Sagemaker
Bilt Rewards家賃支払い・近隣飲食・旅行でポイントが貯まるリワードプラットフォーム（2021年創業）。金融機関・不動産管理会社・加盟店など10,000超のB2Bパートナーにデータを提供。本社ニューヨーク。
リーンなデータチームで多様な分析ニーズに応える（dbt Semantic Layerでデータコスト80%削減）
80%データコスト削減（BI埋め込みからdbt Semantic Layer経由へ切替）
3人データチームのアナリスト人数（10,000超の外部データ利用者を支援）
アナリスト3名で10,000超の外部データ利用者を支える必要があり、BI埋め込みのユーザー課金がパートナー増に比例して膨らんでいた。dbt Cloudで変換ロジックを集約し、dbt Semantic LayerとGraphQLエンドポイントでB2Bポータルに指標を直接提供するヘッドレスBIへ移行。データコストを80%削減し、データ品質問題の大半を解消した。
導入前（顧客の声）- BigQueryに200超のスキーマ、数千億行、50超のアプリケーションDBから取り込んでいるのに、データチームはアナリスト3名しかいない。
- B2BパートナーポータルにBI埋め込みを使っていたが、加盟店やパートナーを1社追加するごとにユーザー課金が線形に増えて持続できない。
- 変換ロジックがデータウェアハウスとBIツールの両方に散らばり、トラブルシュートが大変。BI埋め込みでは提供できる可視化の種類も限られる。
- ドキュメント、リネージ、バージョン管理、CI/CD、自動テストといった分析開発ライフサイクルの基本が未整備で、社内外の信頼が損なわれかけていた。
dbtでやったこと- dbt Coreも検討したが、速度とスケーラビリティを求めてdbt Cloudを採用。ドキュメント・リネージ・ガバナンスを標準機能で整備。
- dbt Semantic Layerで指標とディメンションを変換ロジックと同じ場所に一元定義し、GitHubで管理。
- BIツールから変換ロジックをdbtへ移し、BI埋め込みを廃止。dbtのGraphQLエンドポイント経由でB2Bポータルの可視化にデータを直接提供するヘッドレスBI構成に。
- 同じセマンティックモデルをモバイルアプリ・Webのパーソナライズ体験や、ML・LLM施策にも展開予定。
B2Bポータルの顧客向け可視化に本当に必要だったのはデータだけでした。dbtとSemantic Layerでデータ変換を一元化したら、フロントエンドへの可視化は簡単に作れました。とてもシンプルになり、GraphQLエンドポイント経由でデータを送る形へ素早く移行して、データコストは80%と大幅に下がりました。
Ben Kramer, Senior Director of Analytics, Bilt Rewards
営業での使いどころ「BI埋め込みのユーザー課金をdbt Semantic Layerのヘッドレス構成に置き換えてデータコスト80%減」として、顧客向けデータ提供（B2Bポータル）を持つ金融・決済系顧客への提案に使える。
製品・スタックdbt Cloud · dbt Semantic Layer · GraphQL endpoint ／ dbt Cloud, BigQuery, Github
Rocket Money家計管理・サブスク解約・請求交渉などを提供する個人向けファイナンスアプリ（2015年創業、2021年に上場企業に買収）。本社メリーランド州シルバースプリング。
データドリブンなデジタルファイナンス（3,000件のテストでSOX監査の指摘0件）
3,000データ品質を担保するために毎日実行するテスト数
0システム刷新後の初回SOX監査での指摘事項数
複数の収益源と決済プロバイダーのデータが分散し、GAAP準拠で監査可能な財務レポートの単一情報源がなかった。dbt Cloudで複雑な収益ロジックをモジュール化した Quote-to-Cash システムを構築し、毎日3,000件のテストで会計ロジックを検証。初回のSOX監査を指摘0件で通過し、月次決算のストレスを大幅に軽減した。
導入前（顧客の声）- 収益源が多く決済プロバイダーも複数あるため、収益認識・キャッシュ予測・月次決算に必要なデータを一つに集約する仕組みがない。
- 「同じはずの指標をチームごとに違う計算で出したくない。月次の収益は全員が同じ引き方で同じ数字にしたい。」
- 従来のプロセスは非常に時間がかかり、スケールも月次決算の迅速化もできない。
- データ検証の多くを財務・会計チームが手作業で行っており、事業拡大に耐えられない。
dbtでやったこと- dbt Cloudを採用し、発注書・請求書から収益・現金・売掛金までを追跡するGAAP準拠の Quote-to-Cash システムを構築。
- dbtのモジュール構造で、プロダクト・エンジニアリング・会計にまたがる複雑な収益ストリームのロジックを保守しやすい層に分解。
- Quote-to-Cash と本番データモデルに対して業務ロジック・会計ロジックを検証する3,000件のテストを毎日実行。
- dbt Cloudの自動生成ドキュメントと監査ログ、データ差分比較（data diff）で監査対応力を確保。
指摘ゼロで通過しました。素晴らしいことです。このシステムはまさにSOX監査で監査人が見るような仕組みなんです。
Amber Oar, Staff Analytics Engineer, Rocket Money
営業での使いどころ「dbt Cloud上のQuote-to-Cashと毎日3,000テストでSOX監査を指摘0件で通過」として、J-SOX・内部統制や決算早期化を課題に持つ金融・上場企業に使える。
製品・スタックdbt Cloud · tests · auto-generated documentation · audit logging · data diff ／ BigQuery, dbt, Looker, Shortcut
Zip数百万人の顧客を持つ「Buy Now, Pay Later」の急成長フィンテック。消費者と加盟店の両面マーケットプレイス。本社シドニー。
Zip、ベスト・オブ・ブリードのモダンデータスタックで顧客データを統合（18か月で本番モデル1,000超）
CRM（Braze）でセグメントした顧客に自社アプリでは同じオファーを出せないなど、顧客データが統合されておらず、従来の変換基盤は依存関係管理とドキュメントが弱点だった。Snowflake、dbt Cloud、Snowplow、Fivetran、Censusで用途に合ったスタックを構築。18か月で1,000超のモデルを本番稼働させ、マーケティングチームが360°顧客データを自ら活用できるようになった。
導入前（顧客の声）- グロースチームはBrazeで顧客をセグメントできているのに、自社のZipアプリでは同じセグメント別オファーを出せない。
- 加盟店は細かい顧客セグメントにキャッシュバックを届けたいのに、それを支えるデータが足りない。
- 以前の変換スタックは依存関係の管理とドキュメントが大きな痛点だった。
- 数百万人の顧客が生む膨大な生イベント量を以前のスタックでは処理できなかった。
dbtでやったこと- シームレスな連携・コストスケーラビリティ・実ビジネス用途を軸に評価し、Snowflake、dbt Cloud、Snowplow、Fivetran、Censusのベスト・オブ・ブリード構成を採用。
- dbt Cloudにビジネスロジックと変換を集約。クラウドIDEを活用し、マクロやインクリメンタルモデルも深く活用。18か月で本番モデル1,000超。
- Fivetranで3rd partyデータを取り込み、パッケージ化されたdbt変換モデルを活用してエンジニアのAPI対応工数を削減。
- Censusで Snowflake の360°顧客データを Braze などマーケティングツールへ同期し、非技術者がセグメントを作れるセルフサービスを実現。
コストのスケーラビリティは私たちにとって重要な検討事項です。イベント量で痛い目を見たことがあるので、コストのスケーラビリティには目を見開いて臨みました。
Moss Pauly, Sr. Product Manager, Zip
営業での使いどころ「BNPL事業者がSnowflake＋dbt Cloud中心のモダンデータスタックを組み、18か月でモデル1,000超まで拡大した」事例として、決済・消費者金融のスタック刷新提案の全体像を示すのに使える。
製品・スタックdbt Cloud · Cloud IDE · macros · incremental models · Fivetran dbt packages ／ Snowflake, dbt Cloud, Snowplow, Fivetran, Census
M1 Finance複雑で規制の厳しい金融データを扱う米国のフィンテック。アナリストや事業部門が正確なデータへ迅速にアクセスすることが戦略判断と規制対応の両面で不可欠。
M1 Finance、Claudeとdbtの構造化データでAIセルフサービス分析を実現
Supersetでのセルフサービスには事業部門にはないSQLスキルが必要で、データチームがボトルネックになっていた。Claude（Anthropic）でSQLを生成する最初のチャットボットは、データカタログ全体を渡したためハルシネーションが頻発。LLMにSQLではなくdbt Semantic Layerのコマンドを書かせる「穴埋め（Mad Libs）」方式に変え、検証済み指標のみを照会する仕組みにしたところ、ハルシネーションはほぼ解消し、非技術者の利用が最も多いツールになった。
導入前（顧客の声）- Supersetはデータウェアハウスに直接クエリできる強力なツールだが、ほとんどの事業部門には求められるSQLスキルがない。
- 「データチームが事業のボトルネックになっていた。データドリブンな意思決定を支えるどころか、我々を待つ間みんなの仕事を遅らせていた。」
- 最初のLLMチャットボットはカタログ全体（スキーマ、列名、説明）からSQLを生成する方式で、実在しない列名を作るなどハルシネーションが頻発。
- 生成SQLは実行できて結果も返るため、SQLを深く理解していないユーザーは誤りに気づけない。誤った数字は顧客ポートフォリオや経営計画に直結する。
dbtでやったこと- LLM（Claude）にSQLを直接生成させるのをやめ、ユーザーとdbt Semantic Layerの間のインターフェースとして位置づけ直した。
- システムプロンプトとユーザーの質問から、LLMが事前定義済みの主要指標を使うdbt Semantic Layerコマンドを「穴埋め」で生成し、実際のSQLはSemantic Layerが生成。
- 出力SQLは常にデータチームが意図したクエリ方法に準拠し、事業部門は検証済み指標のみを照会できる。
- 今後は指標追加、Supersetへのチャットボット組み込み、エラーハンドリング改善、dbt MCP ServerでSemantic Layerと構造化データをLLMに直接接続することを検討。
エンジニアリング部門と非エンジニアリング部門向けに説明会を開いたところ、反応はとても励みになるものでした。自分たちのツールが使われるのは嬉しいことですし、最も使ってくれているのは非技術系のステークホルダーなのです。
Kelly Wolinetz, Senior Data Engineer, M1 Finance
営業での使いどころ「LLMにSQLを書かせるとハルシネーションする問題を、dbt Semantic Layer経由の検証済み指標で解消した」事例として、生成AIによる自然言語分析を検討する金融顧客への提案に使える。
製品・スタックdbt Semantic Layer · dbt Cloud · dbt MCP Server ／ dbt Semantic Layer, Superset, Claude (Anthropic), データウェアハウス