モダンデータスタックとは｜5レイヤー構造と従来型との違い・ETLからELTへの転換

モダンデータスタック（MDS: Modern Data Stack）という言葉がデータ基盤の設計において頻繁に使われるようになっています。しかし、この用語が指す範囲は曖昧で、「クラウドベースのデータ基盤ツール群」程度のざっくりした理解のまま議論が進んでいるケースも少なくありません。

モダンデータスタックとは ― 一文での定義

モダンデータスタックとは、データの取り込み・変換・蓄積・分析・オーケストレーションの各レイヤーを専門のSaaSに分担させ、クラウドDWH上でデータを変換（ELT）する前提で組み立てたデータ基盤の設計思想です。

特定の製品群の呼び名ではありません。「どのツールを使うか」ではなく「レイヤーごとに責務を分け、各ツールが自分の責務に集中できる構造にする」という考え方が本体です。したがって同じツールを使っていても、責務の分離ができていなければモダンデータスタックとして機能しません（後述の失敗パターン）。

以降では、従来型との違い → 5つのレイヤー構造 → 横断的な課題 → よくある失敗、の順に整理します。

従来型との設計思想の違い ― ETLからELTへ

モダンデータスタックの本質は、ツールの新しさではなく設計思想にあります。従来のデータ基盤と比較すると、その違いが明確になります。

この表の中で最も重要な変化は「ELTへの移行」と「レイヤー別のツール分離」の2つです。従来はデータをロードする前に変換（Transform）していましたが、MDSではまず生データをクラウドDWHにロードし、DWH上で変換を行います。この「ELT」のモデルが成立するのは、クラウドDWHのコンピュート性能が十分に高く、ストレージコストが十分に低くなったからです。

そして、各レイヤー（データ取り込み、変換、ストレージ、分析、オーケストレーション）をそれぞれ専門のSaaSツールが担い、組み合わせて使う。この「レイヤー別分離」の設計思想が、モダンデータスタックの核心です。

本記事では、このレイヤー構造を整理した上で、各レイヤーのツール選定の判断基準と、レイヤー間の統合設計のポイントを解説します。

5つのレイヤー構造

モダンデータスタックは、以下の5つのレイヤーで構成されます。

以下、各レイヤーの設計ポイントを掘り下げます。なお、レイヤー構成そのものをどう選ぶかという上位の判断はデータ基盤アーキテクチャの選定基準で5つの軸として整理しています。

レイヤー1：Ingestion（データ取り込み）

Ingestionレイヤーは、ソースシステム（SaaS、データベース、APIなど）からDWHにデータを取り込む工程です。従来のETLでは、取り込みと変換を1つのパイプラインで処理していましたが、MDSでは取り込み（EL）と変換（T）を明確に分離します。

Fivetran、Airbyte（クラウド版）に代表されるマネージドELツールは、ソースシステムからDWHへのデータ同期を、コネクタの設定だけで自動化します。従来はETLパイプラインのコードを書いてソースごとのデータ取り込みロジックを開発・保守していましたが、マネージドELツールはこの工程を大幅に簡素化します。

コネクタの対応範囲。自社が使っているソースシステム（Salesforce、HubSpot、MySQL、PostgreSQL、Google Analytics等）のコネクタがあるかが最初の確認事項です。主要SaaSのコネクタはほとんどのツールで対応していますが、社内の独自データベースやレガシーシステムの場合はカスタムコネクタの開発が必要になるケースがあります。

増分同期（Incremental Sync）の対応。全データを毎回取り込むフルロードではなく、前回同期以降の差分のみを取り込む増分同期に対応しているかどうか。データ量が大きくなるほど、増分同期の有無がコストとパフォーマンスに直結します。

マネージド vs セルフホスト。Fivetranは完全マネージド（SaaS）、Airbyteはマネージド版とセルフホスト版の両方を提供しています。データのセキュリティ要件やコスト構造に応じて選択します。セルフホスト版は運用の自由度が高い反面、インフラの管理負荷がかかります。

レイヤー2：Transform（変換）とdbt

Transformレイヤーは、MDSにおいて最も設計思想の変化が大きいレイヤーです。この変化の中心にあるのがdbt（data build tool）です。

dbtが持ち込んだ設計思想は「Analytics Engineering」と呼ばれ、データ変換をソフトウェアエンジニアリングのプラクティスで管理するアプローチです。具体的には、SQLでデータモデルを定義し、Gitでバージョン管理し、テストで品質を担保し、CI/CDで自動デプロイする。従来のETLツールのGUI上で変換ロジックを組む方式とは根本的に異なります。

1. SQLファースト。変換ロジックはSQLで記述します。Pythonや独自DSLではなく、データ分析者が最も慣れ親しんだ言語で変換を定義できることが、チームへの定着を容易にします。

1. モデルの依存関係の明示。ref()関数でモデル間の依存関係を宣言的に定義し、DAG（有向非巡回グラフ）として管理します。どのモデルがどのモデルに依存しているかが可視化され、変更の影響範囲を事前に把握できます。

1. テストの組み込み。各モデルにテスト（NULLチェック、ユニーク制約、参照整合性等）を定義し、ビルドのたびに自動実行します。データ品質の担保がパイプラインに組み込まれるため、「知らないうちにデータが壊れていた」状態を防止できます。

1. ドキュメントの自動生成。モデルの定義からドキュメントとリネージ（データの流れ）を自動生成します。データカタログの基礎情報がTransformレイヤーから自動で提供される構造です。

Storageレイヤー（クラウドDWH）の選定は、モダンデータスタック全体の中心的な判断になります。主要3プラットフォームの得意領域の違いはSnowflake・Databricks・BigQuery比較2026、Databricksを選んだ場合の実装はDatabricksを使ったデータ基盤設計の実務で扱っています。

レイヤー3：Orchestration（オーケストレーション）

Ingestion→Transform→BIの各工程を、正しい順序で、正しいタイミングで、障害時には適切にリトライする。この「交通整理」を担うのがOrchestrationレイヤーです。

ツール選定の判断基準は「チームの習熟度」と「管理するジョブの範囲」です。dbtのジョブだけを管理するならdbt Cloudが最もシンプルです。Ingestionを含む全パイプラインを統合管理するなら、AirflowまたはDagsterが選択肢になります。チームにPythonの経験者が多く、DAGの定義に慣れているならAirflow。テスト容易性とMDSとの設計的な親和性を重視するならDagster。

レイヤーを横断する3つの課題

5つのレイヤーの各論に加えて、レイヤーを横断する設計課題が3つあります。

① データカタログとメタデータ管理

データカタログは「どのデータがどこにあり、どういう意味を持ち、誰が管理しているか」を整理・検索可能にする仕組みです。dbtのドキュメント自動生成やSnowflakeのスキーマ情報から基礎的なカタログは構築できますが、ビジネス上の意味（「このカラムは売上の何を指しているか」）を付与するには、ビジネスサイドの協力が必要です。

ツールとしてはAtlan、Select Star、OpenMetadataなどがあります。カタログに載せる前提となる品質指標の定義はデータ品質管理とKPI設計で6次元として整理しています。カタログの導入は「ツールの導入」よりも「運用プロセスの設計」が成否を分けます。メタデータの更新ルール、データオーナーの定義、カタログの利用を業務プロセスに組み込む設計がなければ、カタログは「誰も見ないドキュメント」になります。

② データ品質とオブザーバビリティ

データ品質の管理は、Transformレイヤー（dbtのテスト）だけでは不十分です。Ingestionの段階でソースデータに異常があるケース、DWHのストレージレベルでデータの鮮度が落ちているケース、BIレイヤーで表示されるデータと実態が乖離するケース。データ品質は全レイヤーを横断して監視する必要があります。

品質指標の定義そのものはデータ品質管理とKPI設計、検知の仕組みと運用はデータ基盤の「サイレント障害」を可視化するで扱っています。Great Expectations、Soda、Monte Carloなどのデータオブザーバビリティツールは、データ品質の監視を自動化します。異常の検知、アラート、影響範囲の特定を、パイプラインの各段階で行う仕組みです。

③ アクセス制御とガバナンス

レイヤーごとにツールが分かれるMDSでは、アクセス制御とデータガバナンスの一貫性を維持するのが難しくなります。Ingestionツール、DWH、BIツールのそれぞれでアクセス権限を管理する必要があり、ポリシーの不整合が生じるリスクがあります。

Snowflakeの行レベルセキュリティ、BigQueryのIAM統合、Databricks Unity Catalogなど、DWHレイヤーのガバナンス機能を中核に据え、上下のレイヤーからこのポリシーを参照する設計が現実的なアプローチです。

よくある3つの失敗

失敗1：ツール起点で導入する

「dbtがいいらしい」「Fivetranが便利らしい」という情報をきっかけにツールを導入したものの、レイヤー間の責務分離が曖昧で、結果的に「新しいツールで古い設計を再現しただけ」の状態になるケースです。MDSのメリットはツール単体ではなく、レイヤー分離の設計思想から生まれます。ツール選定の前に、ID21で整理したような「自社の要件と制約」を構造化するステップが不可欠です。

失敗2：ツールが増えすぎる

ベストオブブリードの思想を追求しすぎると、ツールの数が際限なく増えます。Ingestionに2ツール、Transformに1ツール、Orchestrationに1ツール、データ品質に1ツール、カタログに1ツール。合計6〜7ツールの認証管理、バージョン管理、障害対応、コスト管理を同時に行う運用負荷は、小規模チームには過大です。

「最小構成で始め、必要に応じて追加する」アプローチが重要です。最初はIngestion（Fivetran/Airbyte）＋Storage（Snowflake/BigQuery）＋Transform（dbt）の3ツールで始め、データ品質やカタログは後から追加する。この段階的な構築が、運用の持続性を担保します。

失敗3：ツールだけ入れて文化が伴わない

dbtを導入しても、チームがSQLでモデルを定義し、テストを書き、Gitでバージョン管理する「Analytics Engineering」の文化が定着しなければ、dbtはただの変換ツールに過ぎません。従来のETLツールでGUIを使っていたチームが、いきなりSQL＋Gitベースの開発に移行するのはハードルが高い。段階的な教育と、チーム内に「dbtに詳しいメンバー」を最低1名確保することが定着の前提です。

まとめ：機能するのは「責務の分離」ができているから

本記事では、モダンデータスタックの5つのレイヤー構造、各レイヤーの設計ポイント、横断的な課題、失敗パターンを整理しました。

• MDSの本質はツールの新しさではなく「ELT」「レイヤー別の責務分離」「コードによるデータ管理」の設計思想
• 5レイヤー（Ingestion / Storage / Transform / BI / Orchestration）それぞれに選定の判断軸がある
• 横断的な課題（データカタログ・品質・ガバナンス）はツール導入よりも運用プロセスの設計が成否を分ける
• 「最小構成で始め、必要に応じて追加する」段階的な構築が運用の持続性を担保する

モダンデータスタックは、個々のツールが優れているから機能するのではなく、レイヤーごとの責務が明確に分離され、各ツールが自分の責務に集中できる設計だから機能します。この設計思想を理解した上でツールを選定し、自社のチームと要件に合った構成を段階的に構築する。それが、MDSを「流行のツール群」ではなく「実際に機能するデータ基盤」にするための条件です。

次に読む記事