InfoQが取り上げたのは、UKのデジタル銀行 Monzo が進めているデータ基盤の再設計です。
ひとことで言うと、「たくさんのチームが自由に動けるようにしつつ、データの品質とコストはちゃんと管理する」という、なかなか欲張りな挑戦です。
しかも規模がすごい。Monzoでは100以上の独立したチームが、12,000を超える dbt models を扱っています。
dbt model というのは、ざっくり言えば SQLで書かれたデータ変換の部品 です。生のデータを、分析しやすい形に変えるための“加工レシピ”みたいなものだと思うとわかりやすいでしょう。
チームが多いデータ基盤で起こりがちなのは、次のような問題です。
Monzoも、まさにこの難しさに直面していたわけです。
個人的には、ここがとても重要だと思います。データ基盤って、最初は「作ること」自体が目標になりがちですが、規模が大きくなると本当に難しいのは**“運用し続けること”**なんですよね。
Monzoは、自分たちのアプローチを so-called “meshy” と呼んでいます。
これは data mesh の考え方をベースにしつつ、各チームの自律性を残しながら、共通ルールと自動化で統制するやり方です。
ざっくり言うと、
という設計です。
ここでいう CI は Continuous Integration の略で、変更を入れたときに自動でテストやチェックを走らせる仕組みです。
人間がレビューで全部見るのではなく、機械に“最低限の品質チェック”を任せるのがポイントです。これはかなり現実的で、私はかなり好感を持ちました。データの世界で「ドキュメントを読んでなんとかしてね」は、だいたい破綻しやすいので……。
Monzoはデータモデルを4つのレイヤーに整理しています。
/filters:no_upscale()/news/2026/05/monzo-data-mesh/en/resources/1blog_post_visual-1777979944235.jpg)
Normalized models
エンティティ（顧客、口座、取引など）を履歴付きで表す層
Logical models
ビジネスロジックを組み合わせる層
Presentation models
下流の用途に合わせて見せ方を整える層
この分け方の良いところは、「どこまでが生データで、どこからが業務ルールなのか」 が見えやすくなることです。
データ基盤が荒れる最大の理由のひとつは、この境界が曖昧になることなので、こういう層の整理は地味だけど効くはずです。
Monzoでは、チーム間で使うデータのやり取りを、ただの口約束やドキュメントで済ませていません。
明示的に定義された interface model を使い、さらにそれを CIで検証 しています。
ここがかなり面白いところです。
普通のソフトウェア開発なら「API仕様を守る」のは当たり前ですが、データの世界ではまだこれが徹底されていないことが多い。
Monzoはそこを、**“データもコードと同じように扱う”** 方向へ寄せているわけです。
Monzoの analytics engineers は、次のように説明しています。
100以上の独立したチームが12,000超の dbt models を扱っている。分散所有は強力だが、大規模になると難しい。
さらにAI支援コーディングが一般化し、誰でも本番の dbt project に貢献できるようになると、出力の性能・一貫性・品質をどう守るかが課題になる。
これはかなり今っぽい論点です。
AI-assisted coding が広がると、コードを書く敷居は下がる一方で、**“誰でも作れるが、ちゃんと動くとは限らない”** 問題が増えます。データ基盤はその影響をモロに受けるので、Monzoのようにルールを仕組みに埋め込むのは、かなり筋が良いと思います。
Monzoでは Modelgen という command-line tool を使い、object definition から SQL や YAML を生成しています。
つまり、手で毎回書くのではなく、共通の定義からモデルを自動生成する わけです。
さらに、各モデルには次のようなルールが求められます。
ここでの incremental は、毎回全件を作り直すのではなく、増えた分だけ処理する方式です。
これがうまく回ると、処理時間もコストもかなり抑えやすくなります。
個人的には、この「incremental をデフォルトにする」という考え方はとても実務的だと思います。
データ基盤は、理想論だけではなく**“毎日ちゃんと安く動くこと”**が大事なので。
Monzoによると、この取り組みはまだ完全移行ではなく、全体の約30%ほど進んだ段階です。
それでも初期成果はかなり良く、
という数字が出ています。
ここでいう landing time は、データが取り込まれて使える状態になるまでの時間だと考えるとわかりやすいです。
銀行のような組織では、データが早く届くことは単なる快適さではなく、意思決定や不正検知の鮮度にも関わるので、これは大きいです。
このMonzoの事例、私が面白いと思ったのは「data mesh を理想論で終わらせていない」点です。
よくある話として、分散型にしたい → 各チームが自由にやる → カオスになる、という流れがあります。
でもMonzoはそこに、標準化・自動生成・CI検証 をちゃんと足している。つまり、自由と統制のバランスをかなり現実的に取っています。
特に重要なのは、**“ガバナンスは人間の頑張りでなく、仕組みで担保する”** という発想です。
これは地味ですが、長く続く組織ほど効いてくるはずです。
もちろん、これがそのままどの会社でも通用するとは限りません。
ただ、「チームを増やすなら、ルールもコード化しないと持たない」 という教訓はかなり普遍的ではないかと思います。
Monzoは、100以上のチームが扱う巨大なデータ環境を、
分散 ownership + 明確な interface + 自動チェック で回す仕組みに作り替えています。
結果として、コストは下がり、データは早く届くようになった。
まだ移行途中とはいえ、これはかなり説得力のある成功例です。
データ基盤の話はどうしても難しく聞こえがちですが、要するにやっていることはシンプルで、
「勝手に増えるものを、勝手に壊れないようにする」 ための工夫です。
Monzoのやり方は、その答えのかなり洗練された形だと感じました。
参考: Neobank Monzo Builds Governed Data Mesh across 100 Teams and 12000 dbt Models
