dbt Platform (旧Cloud)スタートアップでの導入事例
株式会社enechain / akizhou
メンバー / データエンジニア
| 利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|---|
Enterprise | dbt Platform | 10名以下 | 2025年5月 | B to B |
| 利用プラン | Enterprise |
|---|---|
| 利用機能 | dbt Platform |
| ツールの利用規模 | 10名以下 |
| ツールの利用開始時期 | 2025年5月 |
| 事業形態 | B to B |
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
enechainでは複数プロダクトのデータをBigQuery上で横断的に管理していましたが、データ変換処理はdbt Coreによるモデリングと、BigQuery Scheduled Queryによる処理が混在している状態でした。特に以下の課題がありました。
- ジョブスケジューリングやCI/CDを自前で構築・運用する必要があり、少人数チームのリソースを圧迫していた。
- Scheduled Queryで管理しているパイプラインはGit管理されておらず、変更時のテストは本番クエリをコピーして手元で修正し、両方の結果を目視比較するという手動プロセスに頼っていた。
- 重要なデータ集計の変更にレビュープロセスが存在せず、誰でもレビューなしで変更を反映できる状態だった。これがITGC上のリスクであると同時に、ロジックの属人化を招いていた。
- リネージやドキュメントを別途管理する必要があった。
どのような状態を目指していたか
- マネージド環境でジョブスケジューリング・CI/CD・リネージ可視化が一元管理できる状態
- 全データ変換を一つのフレームワークで管理し、Scheduled Queryで散在していたパイプラインも統合できる状態
- テストやレビュープロセスを標準化し、変更の品質を担保できる状態
- Semantic LayerやMCPなどの最新機能を活用し、データ活用の幅を広げられる状態
比較検討したサービス
- dbt Core
- dbt Cloud(現 dbt Platform)
- Dataform
比較した軸
- ジョブスケジューリング機能が十分か
- 権限管理・環境管理のマネージド機能が整っているか
- テストやレビュープロセスによる品質担保が実現できるか(CI機能、Compare機能など)
- 少人数チームで費用対効果が見合うか
選定理由
既に社内で先行してdbt Coreを利用していたのもあり、同一エコシステム内でマネージド環境に移行できるdbt Platformが最も自然な選択肢でした。要件を満たしているかの検証を行った結果、個別に実装が必要な部分が少なく、スピードを優先した判断として採用を決定しました。
- dbt Coreからの移行コストが最小限で済む。
- CI/CD、ジョブスケジューリング、Explorer(リネージ可視化)がマネージドで提供される。
- 要件を満たしており、個別実装が少なくて済むことが検証で判明。
- 公式サポートが手厚く、レスポンスも早い。
導入の成果
改善したかった課題はどれくらい解決されたか
マネージドなCI/CDとジョブスケジューリングにより、自前でのインフラ運用が不要になり、チームのリソースをデータモデリングに集中できるようになりました。Explorer機能によるリネージの可視化で、データ変換の依存関係を誰でも把握できる状態が実現し、障害時の原因特定が効率化しました。
どのような成果が得られたか
- GitHubでのPRレビューとdbt CloudのCI機能により、重要なデータ集計の変更に対してレビュープロセスが確立された。以前のScheduled Query時代にはレビューなしで変更が反映されていた属人的な運用が解消された。
- ユニットテストを既存のロジックに追加した結果、想定以上にテストが失敗するケースが見つかり、潜在的なバグの発見やロジック修正につながった。手動での目視比較に頼っていたテスト運用から脱却できた。
- staging → intermediate → martsの3層構成でデータ変換ロジックの責務が明確化し、開発効率が向上した。
- marts層でのcontract enforcement導入により、下流への破壊的変更を防止できるようになった。
- persist docsによりBigQuery上でもカラムの説明が参照可能となり、セルフサービス分析が促進された。
- dbt Platformがマネージドな実行環境を提供するため、チームごとのdbtプロジェクトや実行環境を自前で構築・管理する必要がなくなり、基盤構築・運用の工数が大幅に削減された。ただし、dbt Platform全体の設定やプロジェクト構成を把握するadmin的な役割の開発者は最低限1名必要。
- Scheduled Queryで散在していたパイプラインもdbtに統合し、全変換処理の一元管理を実現した。
Enterprise Planを選定して結局どうだったか
導入を検討していたタイミングで既に複数サービスにまたがるdbtプロジェクトの必要性が見えており、1プロジェクトしか作成できないTeam Planでは不十分でした。全社展開を見据えると必然的にEnterprise Planの選択となります。Enterprise Planにより以下の機能が利用可能となっています。
- マルチプロジェクト: サービスごとに独立したdbtプロジェクトを運用でき、デプロイサイクルやアクセス権限を分離できる。
- Audit Log: データ変換の実行履歴や変更履歴を追跡でき、ガバナンス要件への対応が容易になった。
- dbt Mesh: プロジェクト間でのモデル参照が可能となり、共通ロジックの再利用やデータの一貫性を確保できる。
導入時の苦労・悩み
- Scheduled Queryからdbtへの移行では、ドキュメントが存在しない既存クエリのロジック解読に時間がかかりました。属人化していたクエリの意図を理解し、staging/intermediate/martsの適切な粒度に分割する設計作業は想定以上に工数を要しました。
- dbt Coreからdbt Platformへの移行では、設定ファイルの違いや環境変数・varsの受け渡しなど、凝った構成を実現しようとすると一部自前実装が必要でした。
導入に向けた社内への説明
上長・チームへの説明
経営層への承認にあたり、主に「品質」と「生産性」、そして「将来のAIデータ民主化への準備」の3つの観点で説明しました。
品質面では、重要なデータ集計がレビュープロセスなしで変更可能な状態がITGC上のリスクであること、dbt Platformのテスト機能・変更時の比較機能・レビュープロセスにより品質担保の仕組みを構築できることを説明しました。
生産性面では、現状は各チームがそれぞれBigQuery上で個別にデータ開発を行っており車輪の再発明が発生しやすい状態であること、dbt Platformにデータ開発を集約することでコスト効率の改善が見込めることを伝えました。
将来のAI活用については、メタデータの整備が進めばAIを活用した自然言語でのデータ探索が現実的になること、dbt Platformはメタデータ管理に優れており、その基盤を今から整えられるという点を訴求しました。実際にClaudeとdbt MCPを使ったデモも提示し、将来像を具体的に示しました。
活用方法
よく使う機能
- dbt Explorer(リネージ可視化・ドキュメント閲覧)
- CI/CD(PRごとの自動テスト・差分ビルド)
- Semantic Layer(メトリクス定義の一元管理)
- dbt test / dbt_project_evaluator(データ品質・ガバナンス)
- dbt MCP(AIツール連携)
ツールの良い点
- Semantic Layer、MCP、Fusionなどデータエンジニアリングの最新トレンドが最も早く取り込まれ、モダンな技術スタックに追いつきやすい
- OSSコミュニティが活発で、サードパーティパッケージ(dbt_project_evaluator、Elementaryなど)やナレッジが豊富
- SQLベースで開発できるため、エンジニア以外のメンバーにもアクセシブル
ツールの課題点
- ライセンスコストが高い割に、ワークフローツールとしての成熟度はまだ発展途上
- MCPやSemantic Layerなど新しい機能は仕様通りに動作しないケースがあり、不安定さが残る
- 認証周りで数時間おきに再ログインが必要になるケースがあり、開発体験を損なう場面がある
ツールを検討されている方へ
dbt Coreは無料で始められるため、まずはローカルでdbtの開発体験を試すことをお勧めします。チーム規模が拡大し、CI/CDやジョブスケジューリング、リネージの可視化などマネージド機能が必要になったタイミングでdbt Platformへの移行を検討するのがよいと思います。ただし、ライセンスコストは開発者人数に比例するため、少人数チームでは費用対効果の試算を事前にしっかり行うことをお勧めします。また、dbt Platformはワークフローエンジンではなく、マネージドな実行環境として捉えるのが適切です。複雑なワークフロー制御を期待すると物足りなさを感じる場面があるため、ワークフローの要件が強い場合は別途オーケストレーションツールとの併用を視野に入れるとよいと思います
今後の展望
dbt Fusionエンジンへの移行を進めており、ローカル開発体験の大幅な改善を見込んでいます。また、dbt MCPを活用したAIツール連携の深化により、自然言語でのデータ探索やモデル開発のワークフローを発展させていきたいと考えています。Semantic Layerの活用範囲を広げ、組織全体でメトリクスの定義を統一していくことも今後の重要なテーマです。
株式会社enechain / akizhou
メンバー / データエンジニア
よく見られているレビュー
株式会社enechain / akizhou
メンバー / データエンジニア


