実績は明細、予算は月次:Power BIで粒度の異なるデータのモデリング4パターンを徹底比較

実績は明細、予算は月次:Power BIで粒度の異なるデータのモデリング4パターンを徹底比較

2025.11.21

今まで色んなPower BIのモデリングパターンを作ってきました。全てのパターンを振り返って、まとめていきたいと思います。

この記事で学べること

  • 4つのモデリングパターンの総合比較
  • 状況に応じた最適なパターンの選び方
  • 各評価軸の具体的な意味と重要性
  • 実務での選択基準

4つのモデリングパターンのおさらい

連載で紹介した4つのパターンを簡単に振り返ります。

1. 月次予算+月次実績

予算と実績の粒度を月次に揃えて管理する、最もシンプルなパターン。

このような形でデータを持ちます。

年月 地域 カテゴリ 売上予算金額 売上実績金額
2024/01 九州 家電 4,230,000 4,560,000

リレーションは下記のようになります。
2025-09-powebi-1-06

2. 日割り予算+日次実績

月次予算を日割りして、日次実績と比較できるようにしたパターン。

このような形でデータを持ちます。

地域 カテゴリ 売上予算金額 売上実績金額
2024/01/11 九州 家電 136,452 145,000

リレーションは下記のようになります。

2025-09-powebi-2-10

3. 月次予算+実績明細(ブリッジテーブル)

実績明細をそのまま活用し、ブリッジテーブルで月次予算と紐づけるパターン。

以下のような形でデータを持ちます。
実績ファクト

行ID オーダーID 出荷日 オーダー日 出荷モードID 製品ID 顧客ID 店舗ID 売上実績金額 地域ID カテゴリID key
12345 a-11111 2024/01/03 2024/01/01 1 22222 3333 4444 5,555 1 2 202401-1-2

予算ファクト

予算年月 地域ID カテゴリID 売上予算金額 key
2024/01 1 2 4,230,000 202401-1-2

Keyブリッジテーブル

年月 地域ID カテゴリID key
2024/01 1 2 202401-1-2

リレーションは下記のとおりです。

ポイント:
実績と予算は直接結合せず、ブリッジテーブルを介して関連付けます。これにより、N対Nリレーションを回避しながら柔軟な分析が可能になります。

2025-09-powebi-4-09

4. 統合ファクト

予算と実績を1つのテーブルに統合し、指標種別で区別するパターン。

以下のような形でデータを持ちます。

日付 地域ID カテゴリID 指標種別 金額 製品ID 店舗ID 顧客ID 出荷モードID
2024/01/01 R001 CAT001 予算 32,258 null null null null
2024/01/01 R001 CAT001 実績 25,000 P001 S001 C001 SM001

リレーションは下記のとおりです。

ポイント:
統合ファクトテーブルは1つなので、リレーション設計は非常にシンプルです。カレンダーテーブルの日付列と統合ファクトの日付列を紐づけ、各マスタも同様に紐づけます。

2025-10-powebi-4-2

総合結果まとめ

6つの評価軸で4つのパターンを比較しました。

評価軸 月次予算+月次実績 日割り予算+日次実績 月次予算+実績明細
(ブリッジテーブル)
統合ファクト
運用性 ★★★★★ ★★★☆☆ ★★☆☆☆ ★★★☆☆
パフォーマンス ★★★★★ ★★★★☆ ★★☆☆☆ ★★★★☆
学習コスト ★★★★★ ★★★★☆ ★☆☆☆☆ ★★☆☆☆
柔軟性 ★☆☆☆☆ ★★☆☆☆ ★★★★★ ★★★★☆
データ整合性 ★★★★★ ★★☆☆☆ ★☆☆☆☆ ★☆☆☆☆
拡張性 ★☆☆☆☆ ★★☆☆☆ ★★★★☆ ★★★★★

評価サマリー

月次予算+月次実績

  • 最もシンプルで学習コストが低い
  • パフォーマンスとデータ整合性に優れる
  • 柔軟性と拡張性に課題

日割り予算+日次実績

  • 日次での進捗管理が可能
  • バランスの取れた性能
  • 予算の日割りロジックに注意が必要

月次予算+実績明細(ブリッジテーブル)

  • 最も柔軟な分析が可能
  • 学習コストとパフォーマンスに課題
  • N対Nリレーション回避の理解が必須

統合ファクト

  • 拡張性が最も高い
  • データ加工はシンプル
  • DAX関数が複雑になりがち

どれがいいのか?

どれが良いのかは、状況によって優先する評価軸が変わるので、ケースバイケースです。どういう場合に何を優先するのがおすすめかをまとめてみました。

ケース 推奨パターン 優先する評価軸
経営層向け月次レポート 月次予算+月次実績 学習コスト、パフォーマンス
初めての開発 月次予算+月次実績 学習コスト、運用性
データ量が非常に大きい 月次予算+月次実績 パフォーマンス
営業現場の日次進捗 日割り予算+日次実績 運用性、柔軟性(日次)
製品別・顧客別詳細分析 統合ファクト 柔軟性、拡張性
将来的な拡張が多い局面 統合ファクト 拡張性、メンテナンス性
複数の予算シナリオ 統合ファクト 拡張性
予算と実績で分析軸が異なる ブリッジテーブル 柔軟性、データ整合性

モデリングパターン選びの簡単ガイド

迷ったら「月次予算+月次実績」がおすすめです。

Q1. 実績の詳細分析(商品別、顧客別など)は必要ですか?

  • 必要 → Q2へ
  • 不要 → 「月次予算+月次実績」がおすすめ

Q2. 日次での進捗管理は必要ですか?

  • 必要 → 「日割り予算+日次実績」がおすすめ
  • 不要 → Q3へ

Q3. 将来的に新しい指標(見込み、着地予測など)を追加する予定はありますか?

  • ある → 「統合ファクト」がおすすめ

それぞれの評価軸の意味

1. 運用性

定義
日常的にレポートを運用する際の容易さ・安定性

具体的な評価ポイント

  • データ更新の手間: 毎日/毎月のデータ更新作業が簡単か
  • エラーの起きにくさ: データ投入時のエラーハンドリング
  • 説明のしやすさ: ビジネスユーザーに仕組みを説明できるか
  • トラブルシューティング: 問題発生時の原因特定の容易さ
  • 属人化リスク: 特定の人しか運用できない状態になっていないか

月次予算+月次実績は非常にシンプルで明快です。対して、ブリッジテーブルはkeyの生成ルールやリレーションシップを理解していないと運用が難しい側面があります。これはそのままメンテナンスのしやすさに直結します。

2. パフォーマンス

定義
レポートの表示速度・応答速度

具体的な評価ポイント

  • データ量: テーブルの行数・カラム数
  • リレーションシップの複雑さ: 結合処理の負荷
  • クエリの効率: DAXエンジンの処理効率
  • メモリ使用量: Power BIのメモリ消費
  • ビジュアルの描画速度: グラフ・テーブルの表示時間

評価の理由
月次予算+月次実績はデータ件数が少なく、結合もシンプルです。対して、ブリッジテーブルは実績明細データを全て持つことになるので、データ件数が多く、パフォーマンスは落ちます。

3. 学習コスト

定義
そのモデリングを理解・実装するために必要な知識・時間、このモデリングを使ってメジャー作成するときの難易度

具体的な評価ポイント

  • 前提知識: Power BI、データモデリングの必要スキルレベル
  • DAXの複雑さ: メジャー作成の難易度
  • 概念の理解: モデリングパターンの理解しやすさ
  • ドキュメント: 参考資料の豊富さ
  • 習得時間: 実装できるようになるまでの時間

評価の理由
ここでも、月次予算+月次実績は一番評価が高いです。基本的なリレーションシップとSUM関数くらいのため、一番早く使えるようになると思います。最も難しいのは統合ファクトで、CALCULATEでのフィルタリング必須になります。

4. 柔軟性

定義
様々な分析要件に対応できる幅広さ

具体的な評価ポイント

  • 分析粒度: 日次・週次・月次・年次など複数の時間軸に対応できるか
  • 分析軸の多様性: 製品別・顧客別・店舗別など詳細な切り口が可能か
  • アドホック分析: 想定外の質問にも答えられるか
  • ドリルダウン: サマリから明細への掘り下げが可能か

評価の理由
高評価になるのは、明細の情報を持っているブリッジテーブル、統合ファクトです。実績明細を保持しているため、あらゆる切り口で分析可能になります。逆に低評価になるのは、月次実績+月次予算です。月次・地域・カテゴリ以外の分析は不可能だからです。

5. データ整合性

定義
データの正確性・一貫性が保たれやすいか

具体的な評価ポイント

  • 集計の正確性: 意図しない重複集計や漏れが起きないか
  • データの意味の保持: 元データの意味が変質していないか
  • 検証のしやすさ: Excelなどで検算して確認できるか
  • 誤用のリスク: 間違った使い方をしにくい設計か
  • マスタとの整合性: ディメンションテーブルとの結合が正しいか

評価の理由
高評価になるのは、月次実績+月次予算です。粒度が揃っており、検算が容易で、誤った集計が起きにくい作りになっています。
低評価になるのは、ブリッジテーブルと統合ファクトです。ブリッジテーブルは正しいリレーションシップの理解のもとでブリッジのキーを設定しておかないと、N対Nが残ってしまって間違えた集計になってしまう可能性があります。また、統合ファクトの場合は指標種別のフィルタを忘れると予算と実績が合算される危険性があり、間違えた使い方がされる可能性があるため、低い評価にしています。

6.拡張性

定義
将来的な要件追加・変更への対応しやすさ

具体的な評価ポイント

  • 新しい指標の追加: 見込み、着地予測、前年実績などを追加できるか
  • 新しい分析軸の追加: 新しいディメンション(担当者、チャネルなど)を追加できるか
  • データ量の増加: 年数が増えても対応できるか
  • 構造の変更コスト: 大幅な要件変更時の改修範囲
  • 再利用性: 他のレポートでも同じモデルを使えるか

評価の理由
高評価になるのは、統合ファクトです。指標種別に「見込み」「着地予測」を追加するだけで、構造を変えずに取り込めるからです。
低評価になるのは、月次実績+月次予算です。新しい指標を追加する場合、テーブル構造から見直しが必要ですし、日次分析への対応は実質不可能だからです。

振り返り

私が予実管理と聞いて、最初に思い浮かべて作るのは「月次予算+月次実績」です。これが、最も理解しやすく、パフォーマンスもよいので、最強だと思っていました。このモデリングの難点は、柔軟性・拡張性がないことです。この点をカバーすべく、ブリッジテーブルと統合ファクトという方法をやってみました。

この二つのモデルは柔軟性・拡張性があるものの、やはり学習コストや運用面でのデメリットがあり、メリットデメリットを踏まえて選んでいくことが必要そうです。

実務での推奨アプローチ

まずは「月次予算+月次実績」から始めましょう

この記事のために、全てのモデリングパターンを書き出して実際にデータ加工しました。その際に気が付いたのは、先に簡単なモデルでやっておかないと、いきなり難易度の高いモデリングをやろうとすると混乱するということです。

例えば、「将来の拡張性を考えて、最初から統合ファクトで作ろう」という考え方で作ろうとするよりも、先にシンプルな月別の状態を見て、「月別に事前集計すると、新しい指標が追加になった時に作り直しになるな」と課題を認識してから作る方が、はるかにイメージが湧きました。手を動かして実際に要件が発生して、課題を討議した上で移行しても遅くないのではないかと思いました。

つまり、「今作ったものをずっと維持することにこだわらず、いつかやり直すかもしれない」という視点を頭の片隅に持っていた方がよいと思いました。

シンプルなモデルで運用を開始し、実際のユーザーのフィードバックを得てから拡張する方が、結果的に良いレポートになるし、使いこなせるのではないかと思います。

また、このレポートを作る人・使う人の顔を思い浮かべておくことも大事だと思います。数字やデータに慣れていて、数字を見ただけで集計のための関数がパパっと頭に思い浮かぶような人なのか、Power BIにどれだけ慣れているのか。そういったことを考慮すると、より使いやすいモデリングになると思います。

モデリングは一度作ると作り直しが大変なのは事実です。しかし、フェーズに合わせて使い分けていくこと、環境の変化に合わせて適宜作り直す勇気も必要だなと思いました。

この記事が皆様のPower BI スキルに役に立てれば幸いです。

この記事をシェアする

FacebookHatena blogX

関連記事