power bi 多対多で数字が合わない原因と、壊れないモデルに直す手順（ブリッジ・関係方向・DAXまで）

Power BI でモデルを組んでいると、いつか必ずぶつかるのが「多対多」です。最初は関係がつながって動いたように見えるのに、合計が増えたり減ったり、スライサーの挙動が不自然になったり、特定の組み合わせでだけ数字が崩れたりします。しかも、直し方がひとつではなく、場当たりで触るほど複雑になっていくのが厄介です。

多対多が難しい理由はシンプルで、Power BI が得意なのは「スター型（1対多の連鎖）」だからです。スター型は、フィルターが流れる方向と集計の粒度が読みやすく、性能も安定しやすい。一方、多対多は「どっちが1側なのか」「どの経路でフィルターが伝わるのか」が曖昧になりやすく、結果として集計がブレやすくなります。

ここでは、多対多が発生する典型パターン、よくある事故、そして実務で壊れないモデルに直すための考え方と手順をまとめます。ゴールは、単に多対多を設定することではなく、運用で数字がズレない構造に落とすことです。

多対多が発生する典型パターン

多対多は「現実の業務データがそうなっている」ことが多いです。よくある例を挙げます。

• 社員とプロジェクト
  1人の社員は複数プロジェクトに関わる。1つのプロジェクトには複数社員が関わる。

• 顧客と商品
  1社が複数商品を買う。1商品は複数顧客に買われる。

• 案件とタグ
  1案件に複数タグ。1タグは複数案件に付く。

• 店舗と商圏（エリア）
  1店舗が複数エリアを担当。1エリアには複数店舗が絡む。

この「双方が複数」を、そのまま2つのテーブルだけで表現しようとすると、多対多になります。多対多は悪ではありませんが、集計モデルとしては扱いに注意が必要です。

多対多で起きる“数字が合わない”の正体

多対多で数字が崩れる理由は、だいたい次のどれかに当てはまります。

• 二重計上（同じ明細が複製された扱いになる）
  例えば、売上明細が顧客と商品にぶら下がっているつもりが、関係の作り方によっては同じ売上が複数回カウントされます。見た目では気づきにくく、合計だけが膨らみます。

• フィルター経路が複数になって曖昧になる
  あるスライサーの選択が、別の経路でも同じテーブルへ伝わると、Power BI は「どっちを正にするか」判断できず、関係が無効化されたり、意図しない絞り込みが起きたりします。

• 両方向フィルターの連鎖で、思っていないところまで絞られる
  多対多を成立させようとして両方向を増やすと、スライサーの候補が消えたり、別ページの集計が変わったりします。便利なはずが、結果は不安定になりがちです。

• “多対多のまま集計する”という前提が誤っている
  実は、分析したいのは「社員×プロジェクトの関係（所属）」そのものだった、ということがあります。この場合、社員テーブルとプロジェクトテーブルを無理につなぐより、所属テーブルを中心に据えた方が自然です。

多対多を扱う基本方針は「ブリッジ（中間）テーブルを主役にする」

多対多を安定させる最も強い方法は、ブリッジテーブルを明示的に置くことです。多対多の実体は「関係を表す明細」が存在することなので、それをテーブルとして扱います。

社員とプロジェクトの例で言うと、こうします。

• Employee（社員マスタ：社員IDが一意）

• Project（プロジェクトマスタ：プロジェクトIDが一意）

• EmployeeProject（所属・アサイン：社員IDとプロジェクトIDの組み合わせが並ぶ）

関係は次の2本に分けます。

• Employee（1）→ EmployeeProject（多）

• Project（1）→ EmployeeProject（多）

これで、モデル上はすべて1対多になります。多対多の“見た目”を、1対多の連鎖に分解した形です。

ここが重要で、Power BI は「1対多の連鎖」を非常に得意とします。フィルターの流れも読みやすく、二重計上の事故も減ります。

ブリッジを置いたら次に決めること（何を集計したいか）

ブリッジを作ると、次に悩むのが「何を足し上げるのか」です。例えば、所属（EmployeeProject）に金額があるのか、売上明細が別にあるのかで設計が変わります。

パターンA：ブリッジ自体が“事実”である
所属やタグ付けの件数を見たいなら、EmployeeProject の行数がそのまま指標になります。
例：プロジェクトに何人アサインされているか、タグ別に案件が何件か、など。

パターンB：別のファクト（売上など）にブリッジ経由でフィルターを通したい
例えば、売上明細（Sales）があり、Sales は顧客IDと日付を持っている。さらに顧客と商品に多対多が絡む、のようなケースです。
この場合は、売上を“何に帰属させるか”が必須になります。帰属ルールがない多対多は、集計すると必ず揉めます。

例として「1社の売上を複数担当に割り当てる」なら、配賦比率が必要になります。比率がないのに担当別売上を出すと、どうしても二重計上になります。モデル以前に、業務定義が必要です。

Power BI の多対多リレーションを“そのまま使う”のはいつか

Power BI には関係のカーディナリティとして「多対多」を選べます。これが便利な場面もありますが、万能ではありません。実務の感覚としては、次の条件を満たすときに限定して使うと安定しやすいです。

• どうしてもブリッジを作れない（ソース制約、工期、簡易分析）

• 二重計上が起きない（または起きても許容できる）集計だけに使う

• フィルターの方向や経路が複雑にならないモデルになっている

• “公式レポート”ではなく、探索的な分析に近い用途

逆に、経営会議で使う公式数字、部門横断で共有する KPI などは、できるだけブリッジを明示して1対多の連鎖に寄せた方が、後々の手戻りが少ないです。

フィルター方向は「単方向が基本、必要なら限定して両方向」

多対多の相談で多いのが、「両方向にしたら動いた」という話です。確かに動きます。ただ、動くことと、正しく安定することは別です。

基本ルールとしては次の通りです。

• ディメンション（マスタ）→ ブリッジ → ファクト（明細）の方向で単方向

• 両方向は、スライサーの候補連動など、明確な目的がある場合だけ

• 両方向を入れたら、モデル全体で“フィルター経路が複数になっていないか”を必ず点検

両方向は便利ですが、ページが増えたり、別のテーブルが増えたりすると急に崩れます。最初にラクをすると、後で辛くなる領域です。

多対多を“壊れない形”に直す手順

ここからは、実際に多対多で悩んだときに、現場でやり直しやすい順番をまとめます。

1. 今の多対多は「データの事実として多対多」か、「マスタ重複で擬似的に多対多」かを分ける
   例えば、本当は商品マスタが商品IDで一意であるべきなのに重複していて多対多になっている、というケースがあります。これは多対多ではなくデータ品質問題です。まず重複排除してディメンションを作るだけで1対多に戻ります。

2. 分析したい軸（ディメンション）と、集計したい明細（ファクト）を言語化する
   例：商品カテゴリ別の売上を見たい、担当者別の売上を見たい、など。
   “誰が何を見たいか”が決まると、どのテーブルが中心かが決まります。

3. 多対多の間にある「関係の明細」をブリッジとして切り出す
   社員×プロジェクト、顧客×担当者、案件×タグ、など。
   ブリッジの粒度は「キーの組み合わせで1行」になることが基本です。

4. ブリッジの両側を一意なディメンションに整える
   Employee は社員IDが一意、Project はプロジェクトIDが一意。
   一意でない場合、ディメンションとして成立していません。重複排除、最新行だけ採用、別粒度のテーブルに分離、などで整えます。

5. 関係は 1対多 の連鎖にする
   Employee（1）→ Bridge（多）
   Project（1）→ Bridge（多）
   ここを単方向にして、まず正しい絞り込みができる状態を作ります。

6. 二重計上が起きる指標があるなら、配賦ルールを決める
   例えば、顧客売上を複数担当へ割り当てたいなら、担当比率や優先担当などのルールが必要です。ルールなしで多対多の軸に金額をぶら下げると、必ず揉めます。

7. 最後に、ユーザー体験のために必要な範囲だけ両方向や DAX 制御を検討する
   例えば「社員を選ぶとプロジェクト候補が連動して欲しい」など。
   ここは最初からやらず、正しい集計が出てから足すのが安全です。

多対多でよくある“やってはいけない”に近い設計

現場でハマりがちな設計を、あえて整理します。絶対ダメではありませんが、理由が説明できないなら避けた方が安全です。

• ファクト同士を直接つなぐ
  売上明細と在庫明細を直接つなぐ、など。後で必ず複雑になります。共通ディメンション（日付・商品・店舗など）を介してつなぐ方が安定します。

• 多対多を両方向で網の目にする
  その場は便利でも、フィルター経路が複数になりやすく、少し拡張しただけで数字が崩れます。

• 重複しているマスタを放置して多対多で逃げる
  マスタ重複が原因の多対多は、後から必ず問題になります。正しくはディメンションを作り直すべきです。

• 配賦ルールなしに金額を多対多の軸へ割り当てる
  多対多の軸（担当者、タグなど）に金額を出したいなら、業務ルールが必要です。ルールがないなら、金額ではなく件数や存在確認に留める方が安全な場合もあります。

多対多とパフォーマンスの関係

多対多は、モデルが複雑になりがちで、結果としてクエリも複雑になりやすいです。特に次の条件が重なると体感が悪化します。

• ブリッジが巨大（何千万行など）

• 両方向フィルターが多い

• スライサーに高カーディナリティ列（IDや名前）を置いている

• DirectQuery で毎回データソースに問い合わせている

• 多対多の上で複雑なメジャー（反復計算、重い DISTINCTCOUNT など）を多用

対策として効きやすい順は次の通りです。

• スター型（1対多）へ寄せる、ブリッジを明示する

• フィルター方向は単方向を基本に戻す

• スライサーは階層で絞れるようにする（地域→店舗、カテゴリ→商品など）

• “明細を大量に出すページ”を分離する（必要なときだけドリル）

• よく使う粒度は集計済みテーブルを用意する（必要なら）

多対多のトラブルシュートチェックリスト

最後に、数字が合わないときに最短で疑うポイントをまとめます。

• 1側のはずのディメンションに重複がないか

• 多対多のまま金額を集計していないか（配賦ルールがあるか）

• ブリッジの粒度が正しいか（キーの組み合わせで1行か）

• 両方向フィルターが増えすぎていないか

• フィルター経路が複数になっていないか（曖昧性の原因）

• スライサーに高カーディナリティ列を置いて重くしていないか

• 同じ意味のテーブルが複製されていないか（似たデータセット乱立）

• “正しい数字”の定義が業務として合意されているか（特に配賦）

まとめ

多対多は、Power BI の機能で設定できるからといって、簡単に扱えるわけではありません。大事なのは、多対多をそのまま成立させることではなく、分析モデルとして壊れない形に落とすことです。

最も安定する道は、関係を表す明細をブリッジとして明示し、ディメンション（1）→ ブリッジ（多）→ ファクト（多）という1対多の連鎖に分解することです。フィルター方向は単方向を基本にし、両方向は必要な範囲に限定する。金額を多対多の軸へ載せたいなら、必ず配賦ルールを決める。これだけで、多対多が原因の「数字が合わない」「挙動が不安定」「遅い」といった問題の多くは回避できます。

多対多は難所ですが、きれいに整理できると、モデルは一段強くなります。最初にブリッジで構造を整え、正しい集計を出してから、使い勝手の改善を足していく。この順番で進めるのが、実務で一番安全です。

もし困り事があるなら、まずは無料相談を

「DAX 関数が多すぎてどれを使えばいいか分からない」「複雑なロジックを組みたいけれど、エラーが出て解決できない」「会社全体で DAX を学習したい」など、Power BI やデータ活用でお悩みの方はぜひお気軽にご相談ください。
もし困り事があるなら、まずは無料相談はこちら

コンサルサービスの詳細や成功事例なども合わせてご紹介いたします。
社内にデータ活用のノウハウや専門人材が十分いない場合でも、弊社が伴走しながら最短ルートで成果を出せるようサポートいたします。

セミナーで学ぶ！DAX 関数の実践スキル

📊 Power BIでより効率的なレポート作成を！

Power BIハンズオンセミナー初級編では、短時間でデータモデリングのノウハウを学び、ビジネスに活かせるレポート作成を実践形式で習得できます。
少人数制のため、定員になり次第締切！
👉 セミナー詳細を今すぐチェック

📈 Power BIスキルを次のレベルへ！

DAX 関数 × データモデル設計 で、複雑なデータ分析やレポート作成もスムーズに！
Power BIハンズオンセミナー中級編 なら、実践形式で学べるから即戦力に。
業務効率をアップし、社内での評価を高めるチャンス！
今こそスキルアップのタイミング！
👉 詳細はこちら

DAX を使いこなすことで、Power BI の真価を最大限に引き出し、より高度な分析をスムーズに進められます。実践的な知識を身につけて、組織のデータドリブンな文化をリードしましょう。