先に要点
「データを分析して意思決定に使いたい」「ダッシュボードで数字を見たい」── この段階で効くのが、マネージドDWH(データウェアハウス)を中心にしたデータ基盤です。アプリのDBで分析クエリを回すと本番が重くなるので、分析専用の置き場を持ちます(DBサーバーを分ける必要性の発想)。
対象と前提
- 複数のデータ(アプリDB・広告・SaaS・ログ等)をまとめて分析したい
- BI/ダッシュボードで数字を見る、レポートを自動化したい
- データ量は中規模(まだ大規模なリアルタイム処理は不要)
- 専任のデータエンジニアは少人数、または兼任
全体構成（リファレンスアーキテクチャ）
結論: 「集める(ELT) → ためる(DWH) → 整える(dbt) → 見る(BI)」。 マネージドサービスをつなぐだけで作れます。
各層の具体的な候補は次のとおりです。
| 層 | 役割 | 具体的な候補(2026年) |
|---|---|---|
| 収集(ELT) | 各ソースからDWHへ取り込む | Fivetran / Airbyte / 各クラウドの転送 |
| DWH(置き場) | 大量データをため、SQLで分析 | BigQuery / Snowflake / Redshift |
| 変換(モデリング) | 分析しやすい形に整える | dbt |
| 可視化(BI) | ダッシュボード・レポート | Looker / Metabase / Redash |
ELT(Extract-Load-Transform)は、まず生データをDWHへ入れ(Load)、DWHの中でSQLで変換(Transform)する考え方です。事前にデータを集計しておくロールアップ(事前集計)テーブルを作ると、ダッシュボードが速くなります。元データの保管にはS3のようなストレージも使います。
なぜこれを選ぶか
- 運用が軽い ── マネージドDWHは、サーバー管理なしでスケールする。少人数でも回る
- SQLで分析できる ── 多くの人が扱えるSQLで、巨大データも分析できる
- 本番を守れる ── 分析の重い処理を分析基盤に隔離し、アプリDBの負荷を上げない
コスト感
マネージドDWHは「スキャンしたデータ量」や「計算時間」で課金されることが多く、雑なクエリがコストに直結します。ELTサービスやBIも従量・席数課金があります。小さく始め、クエリの最適化(必要な列だけ・パーティション)とコスト監視を入れます。料金体系は製品で大きく異なるため、公式で必ず確認してください。
落とし穴
- クエリ課金の暴走 ── 全件スキャンの重いクエリが積み重なると費用が膨らむ。最適化と上限設定を入れる
- データガバナンス ── 個人情報や権限管理を最初に設計しないと、後で大変になる
- 過剰設計 ── 中規模で大層なストリーミング基盤まで作らない。まずバッチのELTで十分
- 鮮度の誤解 ── ELTは定期同期。リアルタイムが要るなら大規模構成の検討が必要
スケール時の移行余地
データ量が膨大になり、リアルタイム処理や組織横断の再利用が必要になったら、データ基盤・大規模の構成(ストリーミング+レイクハウス+オーケストレーション)へ進みます。多くの中規模はバッチのELTで十分です。
よくある質問
Q. アプリのデータベースで分析すればよいのでは？
A. 小さいうちは可能ですが、データが増えると分析クエリが本番を重くします。分析専用のDWHに分けると、重い集計を隔離でき、アプリの性能を守れます。また複数のデータソース(広告・SaaS等)を横断して分析するにも、まとめる置き場としてDWHが要ります。規模が出てきたら分けるのが定石です。
Q. DWHはBigQuery・Snowflake・Redshiftのどれがいいですか？
A. 使っているクラウドやチームの慣れで選ぶのが基本です。GCP中心ならBigQuery、クラウド非依存で使いやすさ重視ならSnowflake、AWS中心ならRedshift、が大まかな目安です。いずれもマネージドでSQL分析ができ、中規模なら十分こなせます。課金モデルが異なるので、想定クエリ量での試算が大切です。
Q. ELTとETLは何が違いますか？
A. 変換のタイミングが違います。ETLは取り込む前に変換しますが、ELTはまず生データをDWHに入れ、DWHの中でSQLで変換します。マネージドDWHが安く速くなった2026年では、ELTが主流です。Fivetran/Airbyteで取り込み、dbtでDWH内で変換する、という組み合わせが定番になっています。
Q. ダッシュボードが遅いときは？
A. 事前集計(ロールアップ)テーブルを作るのが効きます。毎回生データを集計するのではなく、日次などで集計済みのテーブルを用意し、ダッシュボードはそれを参照します。あわせてクエリの最適化(必要な列・期間だけ)、DWHのパーティション設計も効果的です。
関連する考え方
- 構成選びの総論: 構成の選び方（総論）
- 分析を分ける発想: DBサーバーを分ける必要性
- さらに大規模: データ基盤・大規模