2026 年 5 月 17 日、InfoQ が Neobank Monzo Builds Governed Data Mesh Across 100 Teams and 12000 dbt Models を報じました。Monzo は 100 チーム × 12,000 dbt モデルという規模で 「分散所有 × 中央ガバナンス」を両立させる データメッシュ（Data Mesh） を完成させました。データ所有権をドメインチームに委ねつつ、契約・品質・系譜（Lineage）は中央プラットフォームが担保する構造です。
受託で中堅企業のデータ基盤を設計する立場では、これは 「dbt が増えすぎて誰も全体を把握できない」問題の処方箋です。これまで DuckLake 1.0 中堅企業データレイクハウス受託 や Netflix Model Lifecycle Graph 受託 MLOps ガバナンス で扱った 「データの所有と責任を分散しつつ、品質を中央で担保する」構造を、dbt エコシステムで完成させた最初の大規模事例といえます。本記事では弊社が提供する 「データメッシュ移行 + dbt ガバナンス代行」 パッケージを整理します。
なぜ「dbt が増えすぎる」中堅企業で受託需要が爆発するか
| 構造 | モノリス DWH | 無秩序な dbt 増殖 | ガバナンス付きデータメッシュ |
|---|---|---|---|
| モデル所有 | データチームが全部 | 不明（誰が変更したか追えない） | ドメインチームが明示的に所有 |
| 品質責任 | データチーム | 曖昧 | ドメイン + 中央契約 |
| 依存関係 | 把握可能 | 12,000 モデルで爆発 | データ契約で明示 |
| 変更影響 | 全社調整 | 「壊してから気付く」 | 契約違反検知で事前ブロック |
| 新規追加 | データチーム承認 | 各チームが勝手に追加 | ドメイン承認 + 中央レビュー |
| PII / コンプライアンス | 中央チェック | 抜け穴多数 | タグベース自動検査 |
つまり中堅企業の 「dbt モデルが 500 を超えた瞬間に崩壊する」問題は、データメッシュ移行で構造的に解決できます。
ガバナンス付きデータメッシュが変える 3 つの構造
構造 1: 「データチーム独占」から「ドメイン所有」へ
営業・経理・マーケなど 各ドメインチームが自らの dbt モデルを所有・更新します。データチームは プラットフォーム提供者として一段引いた立場に再定義されます。
構造 2: 「目視チェック」から「データ契約」へ
スキーマ・行数・NULL 率・カーディナリティなどを データ契約（Data Contract）として明文化し、CI で自動検証します。違反は本番デプロイをブロックします。
構造 3: 「経営層が KPI を信じられない」から「系譜で追える」へ
経営ダッシュボードの数字が、どの dbt モデル → どのソーステーブル → どの基幹システムから来たかを Lineage で 1 クリック追跡できます。経営会議で「この数字は信頼できるのか」が議論にならなくなります。
受託で提供する「データメッシュ移行 + dbt ガバナンス」5 フェーズ
フェーズ 1: 現状 dbt 棚卸し（2〜3 週間）
顧客の dbt プロジェクトを全数調査し、「所有不明モデル / 重複ロジック / 廃止候補 / 高リスク変更」を可視化します。多くの中堅企業では 20〜40% が廃止可能です。
フェーズ 2: ドメイン分割設計（3〜4 週間）
経営・営業・経理・マーケ・プロダクトなど 3〜7 ドメインに dbt モデルを分割します。ドメイン責任者を顧客側で指名いただきます。
フェーズ 3: データ契約とガバナンス基盤構築（4〜6 週間）
- dbt-checkpoint / dbt-meta-testing / Great Expectations での自動検証
- OpenMetadata / DataHub / Unity Catalog での系譜管理
- PII タグ + 自動マスキング
フェーズ 4: ドメインチーム巻き込み（6〜8 週間）
各ドメインに 「自分のチームの dbt は自分で書き、自分でレビューする」運用を教育します。受託会社は コーチング役に変わります。
フェーズ 5: 月次データガバナンス会議（継続）
月次で 「契約違反件数 / 廃止モデル数 / 新規モデル数 / ドメイン別品質スコア」を経営層に報告します。
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| データ変換 | dbt Core / dbt Cloud | SQLMesh |
| データ契約 | dbt-contracts / Soda | Great Expectations |
| メタデータ管理 | OpenMetadata / DataHub | Unity Catalog |
| DWH | BigQuery / Snowflake | Databricks / DuckLake |
| オーケストレーション | dbt Cloud / Dagster | Airflow |
| 可視化 | Looker Studio / Metabase | Tableau |
| CI | GitHub Actions + dbt CLI | GitLab CI |
これは BigQuery + Looker Studio 中堅企業データ基盤受託 の延長線として位置づけられます。
どの案件に必要か / 不要か
| 必要な案件 | 不要な案件 |
|---|---|
| dbt モデル数 200 以上 | dbt 未導入 / モデル 50 未満 |
| 5 ドメイン以上の組織 | 単一ドメイン |
| 経営層が KPI 数字を疑う | KPI 数字に疑問なし |
| 月次 / 週次でレポート遅延 | リアルタイム性が低い業務 |
| PII / 個人情報を扱う | 内部統計のみ |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象 dbt プロジェクト | 範囲一覧 | 範囲外の責任 |
| データ契約の SLA | 違反検知 〜 是正期限 | 業務影響の許容範囲 |
| ドメイン責任者の権限 | 承認 / レビュー権 | 兼務時の負荷 |
| PII タグ精度目標 | 95% 以上 など | 監査時の証跡 |
| 退会時の引き渡し | dbt + メタデータ + IaC | 著作物としての帰属 |
| 障害時の連絡網 | 営業時間 / 24h | 経営層直通の要否 |
価格モデル — データメッシュ移行 + dbt ガバナンス代行パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 診断 | 100 万円〜（4 週間） | 現状棚卸し + 移行ロードマップ | レポート |
| Lite | 40 万円〜 / 月 | dbt モデル 300 未満 | 月次レビュー |
| Standard | 90 万円〜 / 月 | dbt モデル 300〜1,000 | + 24h 体制 + 契約違反対応月 5 件まで |
| Enterprise | 180 万円〜 / 月 | dbt モデル 1,000 以上 | + 専任担当 + 契約違反対応月 15 件まで |
別途 dbt Cloud / OpenMetadata / Snowflake などの利用料（顧客実費 + マネジメントフィー 10〜15%）。
顧客側 ROI 試算（dbt 1,200 モデル / 6 ドメイン想定）
| 項目 | 移行なし | 移行あり | 差分 |
|---|---|---|---|
| 月間「壊れたダッシュボード」件数 | 28 件 | 4 件 | -24 件 |
| データチーム工数 | 月 480 時間 | 月 180 時間 | -300h |
| 経営層への報告遅延 | 月 12 日 | 月 2 日 | -10 日 |
| 廃止できた dbt モデル | 0 | 320 件 | — |
| 監査対応工数（年間） | 240h | 60h | -180h |
| 年間効果 | — | — | 約 2,400〜 3,600 万円 |
Standard プラン（年額 1,080 万円）でも 初年度から黒字化が射程です。
ハマりやすい 5 つの落とし穴
落とし穴 1: 「ドメイン責任者」を兼務で決める
実質的な所有が機能しません。専任 0.3〜0.5 人月を契約に組み込みます。
落とし穴 2: データ契約を厳格にしすぎる
開発速度が落ちます。最初は警告のみ、3 ヶ月後にブロックなどの段階導入が必須です。
落とし穴 3: 既存 dbt を全部移行しようとする
20〜40% は廃止候補です。「廃止 → 統合 → 移行」の順序を契約で明示します。
落とし穴 4: メタデータ管理基盤を選定しない
OpenMetadata / DataHub / Unity Catalog で運用思想が大きく異なります。3 つの PoC を顧客と必ず実施します。
落とし穴 5: 経営層への可視化を後回しに
「契約違反件数」だけでは経営層に伝わりません。「数字が信頼できる率」という KPI 化が必須です。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜3 | dbt 棚卸し + ドメイン候補設計 |
| Week 4〜7 | データ契約基盤 + メタデータ管理基盤導入 |
| Week 8〜10 | 1〜2 ドメインで先行運用 |
| Week 11〜13 | 全ドメイン展開 + 月次会議立ち上げ |
まとめ — 「dbt が増えすぎて止まる」を救うガバナンス受託
Monzo の事例は 「100 チーム × 12,000 dbt モデル」でも秩序を保てることを示しました。中堅企業の受託データ基盤を預かる立場では、ドメイン所有 × 中央ガバナンスの設計が 次世代の標準サービスになります。
弊社では 診断 / Lite / Standard / Enterprise の 4 段階で データメッシュ移行 + dbt ガバナンス代行パッケージを提供しています。「dbt モデルが増えすぎて誰も全体を把握できない」「経営層が KPI 数字を疑う」「ダッシュボードが壊れることが多い」というご相談は お問い合わせフォーム からお気軽にどうぞ。
