テーマ解説 — データ基盤とデータアーキテクチャ
データウェアハウス、データレイク、ETL……カタカナの壁に阻まれがちなこの領域、実は「倉庫と物流」の話だと分かれば一気に見通しが良くなります。このページでは、ITが専門でない方に向けて、データ基盤の全体像を現場の言葉で解説します。
これらは「分析したい人」と「データがある場所」の間に道路と倉庫が無いことから起きる問題です。その道路と倉庫にあたるものがデータ基盤、その全体設計図がデータアーキテクチャです。
まず、この領域でいちばん大事な原則をひとつだけ。「日々の業務を回すシステム」と「分析する場所」は分ける、です。
工場を思い浮かべてください。工場（業務システム）は製品（データ）を作る場所です。そこに「先月の生産傾向を調べたい」という人が大勢立ち入って作業台を占領したら、生産ライン（日々の業務）が止まってしまいます。「システムが重くなるからやめて」と言われるのは、まさにこれです。
だから、製品は工場から倉庫に運び出し、調べものは倉庫でやる。この「分析専用の倉庫」と「工場から倉庫への物流」を合わせたものが、データ基盤の基本形です。レジ打ちのシステムが1件ずつ確実に記録することに特化している（業務系）のに対し、倉庫側は大量のデータをまとめて眺めることに特化している（分析系）——得意技が違うので、場所を分けるのです。
似たカタカナが並ぶ紛らわしいゾーン。「倉庫のたとえ」に置き換えて覚えるのがおすすめ
| 用語（試験用語） | 倉庫でいうと | 役割 |
|---|---|---|
| データウェアハウス （DWH） |
整理された中央倉庫 | 各システムのデータを分析しやすい形に整えて蓄積する。全社分析の本拠地 |
| データレイク | とりあえず置き場 | 加工前の生データを、形式を問わず大量にためておく。後で何に使うか決まっていなくてもよい |
| データマート | 部門用の売り場 | 中央倉庫から、営業部など特定部門が使う分だけ取り出して使いやすく並べた小さな棚 |
| ETL | 搬入トラックと仕分け | 各システムからデータを「取り出し（Extract）→加工（Transform）→格納（Load）」する物流作業 |
| バッチ処理 | 1日1回の定期便 | 夜間などにまとめて運ぶ方式。月次集計など「即時性が要らない」用途向け |
| リアルタイム連携 （ストリーミング） |
ベルトコンベア | 発生した瞬間に流し続ける方式。コールセンターの状況監視など「今」を見たい用途向け |
よく試験で問われるのは「レイクとDWHの違い」と「DWHとマートの違い」です。レイクは生のまま・何でも、DWHは整理して・分析用に、マートは特定部門向けに・小さく。「とりあえず置き場 → 中央倉庫 → 売り場」という流れで覚えれば混ざりません。
倉庫を建てる前には設計図が要ります。データの世界の設計図がデータアーキテクチャ（全社のデータの流れ・配置の全体図）とデータモデル（個々のデータの構造図）です。
家づくりにたとえると、モデリングは3段階で進みます。最初は概念データモデル——「寝室3つ、リビングは広く」レベルの間取りスケッチで、業務に登場する「モノ（顧客・商品・注文）」と「その関係」だけを描き、システムの都合は一切入れません。ここは業務を知っている人にしか描けない図です。次の論理データモデルで項目を細かく詰め、最後の物理データモデルで「どの製品でどう建てるか」という施工図に落とします。
もうひとつ、設計の知恵として知っておきたいのが正規化です。1つの表に商品名を何度も繰り返し書いてしまうと、商品名が変わったとき全部直す羽目になり、直し漏れが起きます。重複する情報は別の表に一度だけ書き、そこを参照する——この整理術が正規化で、データ品質のページで見た「同じ情報の二重管理が汚れを生む」問題への、設計段階からの予防策になっています。
ちなみに、倉庫に入れるデータにも種類があります。日々増え続けるトランザクションデータ（売上明細など）、業務の基盤として参照されるマスターデータ（顧客・商品情報）、分類のための参照データ（都道府県コードなど）。形の面では、表に収まる構造化データ、タグ付きだが表ではない半構造化データ（JSONなど）、録音や写真のような非構造化データがあり、「何でも置けるレイク」の出番は後者ほど増えます。
ここまで読むと「結局これはIT部門の仕事では？」と思うかもしれません。建てるのは確かにITの仕事です。しかし、何をどの棚に、どんな切り口で並べるべきかを言えるのは業務側だけです。
つまり、データ基盤の成否は「どう建てるか」より「何のために・何を運ぶか」で決まり、それを語れるのは現場です。「この項目が要る」「この単位で集計したい」「ここはリアルタイムでなくていい」と言葉にできる人は、基盤プロジェクトで最も貴重な存在になります。試験がこの領域を非エンジニアにも問うのは、そういう人を増やしたいからだと言えます。
EXAM NOTE — データマネジメント試験（仮称）
本サイトのオリジナル問題では、DWH・レイク・マート・ETLの役割の区別、バッチとリアルタイムの使い分け、概念／論理／物理モデルの違いを題材にしています。倉庫のたとえ（とりあえず置き場／中央倉庫／売り場／定期便／ベルトコンベア）に置き換えれば、初見の言い回しでも判断できます。
事例問題（科目B）では、「この業務にはどの連携方式が適切か」のような用途と仕組みの対応付けが問われる形式が想定されます。「即時性が本当に必要か？」を最初に考えるのがコツです。
ITパスポート試験でも問われます。シラバス案Ver.0.1では、中分類9「データ分析・データ利活用」の小分類1がそのまま「データ基盤」で、用語例にはデータレイク・データウェアハウス（DWH）・データマート・ELT/ETLが並びます。公式サンプル問題の問2も「データのサイロ化」を題材にしていました。分野構成の変化はITパスポート試験はこう変わる、現行シラバスとの対応は新旧シラバス対応表で整理しています。
例題 — 力だめしに1問どうぞ
データウェアハウス（DWH）から、特定の部門（例：マーケティング部、人事部など）や特定の目的のために、データを抽出・要約して使いやすくした小規模なデータストレージとして、最も適切なものはどれか。
正解：イ
データマートは、中央倉庫（DWH）から特定部門・特定目的向けに取り出して使いやすくした「売り場」です。「マート（mart）＝小売店」という語感どおり、小さく・使う人向けに整えられているのがポイント。データレイク（ア）は加工前の生データを何でもためる「とりあえず置き場」なので方向が逆です。
出典：本サイト作成のオリジナル問題（IPA公式の問題ではありません）。オリジナル問題演習でこの続きが解けます。
中心に「売上金額」などの数値の表（ファクトテーブル）を置き、周囲に「商品」「店舗」「期間」など切り口の表（ディメンションテーブル）を放射状に配置する、分析用データモデルの代表格。星形に見えることからこの名前。
本文02で説明した「日々の業務を回すシステム」がOLTP（オンライントランザクション処理）、「大量データをまとめて分析する仕組み」がOLAP（オンライン分析処理）。この2つを分けるのが大原則。
銀行の口座振替のように、一連の処理を「全部成功するか、全部なかったことにする（中途半端に残さない）」よう扱うデータベースの性質。業務システム（OLTP）側の得意技。
取り出したデータをまず倉庫（データレイクなど）に入れ、必要になってから加工する方式。ETLの語順違いで、「とりあえず置き場」の普及とともに広まった。
理解できたか、実際の問題で確かめてみましょう。
データ基盤・モデリングを題材にした問題を一問一答形式で解けます。
← テーマ解説の一覧へ ／ X（旧Twitter）@dm_exam_site でも毎朝1問ずつ出題しています。
※ 本ページの解説・たとえ話・用語の言い換えは本サイト独自のものです。2026年8月31日公開のデータマネジメント試験（仮称）シラバス案 Ver.0.1 では、「データ基盤」が科目A重点分野（中分類9）の小分類として立ち、データレイク／DWH／データマート、ELT/ETLに加えてデータ仮想化・データファブリック・セマンティックレイヤーが用語例に挙げられていることを確認しています。
