データマートとは、特定の部門や業務テーマで使うデータを、分析しやすい形に絞って提供する仕組みです。例えば営業部門が「月別の受注額と商品別の件数」を同じ定義で確認するために、必要な項目と集計粒度をそろえたデータを用意します。単に小さなデータベースを作ることではなく、誰が何を判断するためのデータかを決めることが重要です。
データマートとは？DWH・データレイクとの役割の違い
| 仕組み | 主な役割 | 利用範囲の例 |
|---|---|---|
| データレイク | 多様な形式のデータを保管し、後から加工・分析に利用する | 複数部門にまたがる原データ |
| データウェアハウス（DWH） | 複数の情報源を統合し、全社で使うデータの基盤にする | 全社の分析・レポート |
| データマート | 特定の利用者・テーマに必要なデータを整えて提供する | 営業、財務、マーケティングなどの分析 |
AWSの解説では、データマートは部門に固有の情報を扱い、DWHから作る場合も外部の情報源から直接作る場合もあると説明されています。DWHやデータレイクの詳細はそれぞれデータウェアハウスの記事、データレイクの記事に譲り、本記事ではデータマートの設計と運用に絞ります。
データマートを作る前に決める5項目
1. 利用者と意思決定を特定する
「営業の週次会議で、商品別売上の変化を見る」のように、利用者、頻度、判断する内容を一文で書きます。目的が曖昧なまま全列を集めると、DWHの複製になりやすくなります。
2. 指標と粒度を定義する
売上なら税込・税抜、キャンセルの扱い、集計日、通貨をそろえます。1行を「注文」単位にするのか「商品×日」単位にするのかも決めます。同じ名称でも部門ごとに計算が異なると、数字が一致しません。
3. 情報源と利用権限を確認する
既存のDWH、業務システム、公開データなど、どこを正とするかを記録します。個人情報や契約上の制限がある列は、必要性とアクセス権を確認してください。Webページの情報を使う場合も、公式API・公開データの有無とサイトの利用条件を先に確認します。
4. 更新と検証の方法を決める
日次・週次など利用目的に合う更新頻度、更新失敗時の通知先、前回成功時刻を決めます。件数、欠損値、重複キー、合計値を元データと照合し、異常時には古い数字を最新として表示しない設計にします。
5. 責任者と変更手順を決める
指標の定義、アクセス権、データ取り込み、ダッシュボードの担当を分けて記録します。元システムの列名や仕様が変わった場合に、誰が影響を確認するかまで決めると、部門だけに閉じたデータのサイロ化を防ぎやすくなります。MicrosoftのBIアーキテクチャー資料も、データモデルとガバナンス、利用者に渡す層の設計を重視しています。
従属型・独立型・ハイブリッド型の選び方
| 種類 | 主な情報源 | 先に確認したいこと |
|---|---|---|
| 従属型 | 既存のDWH | 全社共通の指標定義を引き継げるか |
| 独立型 | 業務システムなどから直接 | 他部門との数字の不一致、重複取り込みを防げるか |
| ハイブリッド型 | DWHと別の情報源 | 結合キー、更新時刻、権限をそろえられるか |
この分類はIBMのデータマート解説にも示されています。どの型でも「1週間で完成する」「必ずDWHより安い」とは言えません。既存基盤、データ品質、セキュリティ要件、運用人数で工数と費用は変わります。
例：営業向けデータマートの最小構成
営業部門が商品別の受注傾向を毎週確認する場合、まず受注日、商品ID、数量、金額、キャンセル区分を業務システムから取得し、商品マスタと結びます。指標の定義を確定したうえで、週別・商品別の集計表を作ります。更新後は元データとの件数・金額の差、重複した注文ID、欠損した商品IDを確認します。必要な列だけを公開し、顧客の氏名など分析に不要な情報は含めません。
この受注データに、比較対象となる商品の公開表示価格を補助情報として加えたい場合があります。公式APIや公開データで足りるならそれを優先し、Webページからの収集が許可されている場合に限ってOctoparseを入力手段として検討します。表示価格は実際の受注価格ではないため、二つを同じ指標として集計しないことが重要です。
Octoparseの収集データをデータマートに渡す具体例
次は架空の小売チームが、自社の週別販売実績と、利用を許された外部ページの公開表示価格を並べて確認する例です。Octoparseが担当するのはWeb側の収集と出力までで、データマートの結合・集計・権限管理は別のデータ基盤で行います。
- 収集対象を決める：サイトの利用条件とAPIの有無を確認し、必要な商品ページだけを選びます。商品一覧を使う場合は、Octoparseのテンプレートが目的に合うか確認するか、カスタムタスクで商品名・表示価格・通貨・商品URLをフィールドにし、必要なページネーションを設定します。
- 少数件で検証する：ローカル実行で複数ページを試し、価格の欠損、別商品の値の混入、同一URLの重複、最終ページでの停止を確認します。取得日時も記録し、いつ見た価格なのかを後から識別できるようにします。
- 収集結果を受け渡す：OctoparseからCSVまたはExcelへ出力し、まず取込用の一時領域に置きます。継続運用では定期実行の設定と利用プランの条件も確認します。
- マート用に整える：通貨・数値形式を統一し、商品URLと取得日時で重複を確認します。外部の商品名と社内の商品IDの対応は自動一致と決めつけず確認したうえで、自社の受注実績と結合します。更新失敗時は古い価格を最新値として表示しません。
| 層 | 1行の単位と主な列 | 担当する処理 |
|---|---|---|
| Octoparseの収集結果 | 商品URL×取得日時：商品名、表示価格、通貨、URL、取得日時 | 許可されたWebページから必要項目を抽出して出力 |
| 取込・整形層 | 検証済みの価格観測1件：社内商品ID、出典、価格、通貨、取得日時 | 型の統一、重複除去、商品対応付け、失敗記録 |
| 営業向けデータマート | 週×社内商品ID：販売数量、受注額、参照用の外部表示価格とその取得日時 | 社内受注との結合、指標定義、アクセス制御、更新検証 |
この例でOctoparseはデータマートそのものではなく、外部情報の一つの入口です。Web側の表示価格が取得できなかった週は欠損として扱い、社内の受注額を外部価格で置き換えません。収集後の一般的なクレンジング手順はデータ準備の記事に譲り、本記事では「週×社内商品ID」というマートの粒度、指標の意味、更新検証を中心に扱います。タスクの作り方は公式ヘルプのワークフローの説明も参照してください。
よくある質問
データマートはDWHがないと作れませんか？
作れます。業務システムなどから直接作る独立型もあります。ただし、部門ごとに同じ指標を異なる定義で作らないよう、共通の用語と更新ルールを管理してください。
データマートと単なるCSV集計表は同じですか？
CSVは保存・受け渡しの形式です。継続利用するデータマートでは、利用者に合わせたデータの定義、更新、検証、アクセス権、変更管理まで考えます。小規模な試作はCSVから始めても、そのまま運用基盤と同一視しないことが大切です。
まとめ
データマートは、特定の部門が必要な情報を一貫した定義で利用するためのデータ提供層です。構築前に利用目的、指標と粒度、情報源、更新検証、責任者を決めます。DWHやデータレイクの広い説明と混同せず、まず一つの業務判断に必要な最小のデータから設計すると、運用上の問題も見つけやすくなります。
競合情報も営業リストも、ウェブデータをそのままExcel・CSV・Google Sheetsに出力
コード不要、誰でも今日から。クリック操作だけで必要な項目を自動抽出
Google Maps・食べログ・iタウンページ向けテンプレートで、リード獲得をすぐに開始
クラウドで毎日・毎週自動実行。大量取得でも安定して、競合動向を常に把握
MCP対応でAIエージェントと連携。収集データをAIに渡して分析・活用まで一気通貫
クレジットカード不要で無料スタート。世界600万人以上が選んだ信頼のツール
