Power BIでの中間テーブル（ブリッジテーブル）活用ガイド

はじめに

Power BIでデータ分析を進めるとき、複数のテーブルが絡むリレーションシップ設定が必要になるケースは少なくありません。単純な「1対多」や「多対1」の関係なら大きな問題は起こりにくいですが、データ構造によっては「多対多」をどう扱うか頭を悩ませることがあります。

その際にしばしば登場するのが、いわゆる「中間テーブル」や「ブリッジテーブル」と呼ばれるテーブルです。本記事では、中間テーブルの概要から作り方、活用シーンなどをわかりやすく解説します。

1. 中間テーブル（ブリッジテーブル）とは？

1-1. 概念

中間テーブル（ブリッジテーブル） とは、2つ以上のテーブルを正しく関連付けるために、間に挟む補助的なテーブルのことです。主に以下の目的で利用されます。

多対多のリレーションシップを解決・回避する
ファクトテーブル（事実テーブル）間の共通参照先として使い、データの整合性を保つ
ユーザー定義のマッピング情報を集約し、スライサーやフィルターを簡単に管理できるようにする

1-2. 多対多を避けるメリット

Power BIでは、バージョンが進むにつれて多対多のリレーションシップを直接設定できるようになりました。ただし、多対多をそのまま使うと、

フィルターコンテキストが想定外に動く
重複値や集計値のブレが起こる
DAXの計算が複雑になりやすい

といった問題が発生しがちです。
中間テーブルを用いた1対多 — 多対1の関係に分解する ことで、リレーションシップをシンプルに保ち、予期せぬ結果を防ぎやすくなります。

2. 中間テーブルを使うシーン

2-1. 多対多を解消するための「ブリッジテーブル」

あるファクトテーブル（売上テーブルなど）に「商品ID」が複数入っており、別のテーブル（顧客テーブルなど）にも同じ商品IDが重複しているといったケースでは、多対多になる可能性があります。その場合、

商品IDの一覧だけを持つ中間テーブル を作る
両方のテーブルとは「商品ID」で1対多（または多対1）になるように設定する

こうすれば、Power BI内部のフィルターの動きが分かりやすくなり、集計時の不具合を回避できます。

2-2. 複数テーブルからの共通キーをまとめる

たとえば、複数の売上テーブルを年ごとや拠点ごとに分割している場合、データモデリングを行う際に共通のキー（顧客IDや商品IDなど）だけをまとめた中間テーブルを作り、そこを介して他のテーブルを参照すると便利です。

ユーザーは中間テーブルをスライサーに使う
各売上テーブルと中間テーブルをリレーションシップで結ぶ
といった構成で、不要な多対多関係を防ぎます。

2-3. 有効期限テーブルやマッピングテーブルとして

中間テーブルは単なる「ID一覧」に限らず、有効期限情報やラベル変更履歴などを一括管理する表として用いることもあります。たとえば、

商品IDごとに開始日・終了日が異なる価格設定を持つ
顧客IDごとに契約期間・契約ステータスを時系列管理している

といった場合に、時系列での集計やフィルタリングを実現するために「時刻軸＋ID」の組み合わせテーブルを作成しておき、そこから必要なレコードを持ってくる形にするとデータモデルが整理しやすくなります。

3. 中間テーブルを作成する手順

3-1. 必要な列を洗い出す

まずは中間テーブルに何の情報を入れるべきかを明確にします。

ブリッジのキーとなる列（IDやコードなど）
追加で必要なマスタ情報（名称や区分など）
日付範囲・フラグなど（発効日、終了日、バージョンなどが必要な場合）

基本的には、「複数テーブルの共通キー」と「分析上必要な最小限の情報（名称など）」だけに絞るのが一般的です。

3-2. Power Query Editorで作成または抽出

Power BIのデータ取り込み時、Power Query Editor上で中間テーブルを作るパターンが多いです。

抽出方法①: すでに取り込んだテーブルから必要な列だけを「参照」して、重複行を削除（Remove Duplicates）
抽出方法②: ExcelやCSV、別のマスタテーブルなどが用意されている場合、そのまま読み込む
抽出方法③: DAXで「計算テーブル (Calculated Table)」として作成する（必要に応じて）

3-3. リレーションシップの設定

中間テーブルが用意できたら、**「中間テーブル」と「ファクトテーブル」**の間でリレーションシップを設定します。

中間テーブルのキー列（例：ItemID） と ファクトテーブルのキー列（例：Sales[ItemID]） を結ぶ
多対1（一対多）の方向が適切か確認
「両方向／単方向」など、フィルターの方向も必要に応じて調整

中間テーブルとファクトテーブルに正しいキーが含まれていれば、ビジュアルやスライサーで連動した分析がスムーズに行えます。

4. 中間テーブル活用例：商品の多対多関係を解消

4-1. シナリオ

Salesテーブル：注文番号、商品ID、数量、顧客ID 等
Productsテーブル：商品ID、商品名、カテゴリ等
Salesテーブルには1つの注文番号で複数商品が紐づく場合があり、Productsテーブルとも「多対多」になるリスクがある

4-2. 中間テーブルの作成

Productsテーブルを参照コピー
- Power Query Editorでテーブルを右クリックし、「参照」で新たなクエリを作成
不要な列を削除し、商品IDのみのユニークなリストへ
- 商品名やカテゴリも必要なら残す
クエリ名を「Bridge_Product」 などに変更し、中間テーブルとして設定

4-3. リレーションシップ設定

Bridge_Product[商品ID] と Sales[商品ID]：1対多のリレーション
Bridge_Product[商品ID] と Products[商品ID]：1対多のリレーション
- あるいは、Productsテーブル自体をディメンションテーブルとして扱うなら、Bridge_Product ではなく Products をブリッジにするなど構成次第です。

これで、SalesとProductsの間に直接多対多を作ることなく、集計や商品別の分析が可能になります。

5. DAX計算とフィルターコンテキストへの影響

5-1. 中間テーブル経由のフィルター

スライサーに中間テーブルのキーや名前を置いた場合、Power BIのフィルターコンテキストは次のように流れます。

中間テーブルのスライサー → 中間テーブルのキーを絞り込み
中間テーブルとファクトテーブルのリレーション → ファクトテーブルが対応するキーに限定

こうしたフィルターが明確に分かれているため、複雑な多対多関係に悩まされることが少なくなります。

5-2. 関数の挙動を理解する

中間テーブルを導入しても、DAX関数（CALCULATEやFILTERなど） の基本的な挙動は変わりません。ただし、中間テーブル経由の場合は、「キーが存在するかどうか」が重要になります。

ファクトテーブルにキーが存在しない＝集計結果に現れない
中間テーブルのキーが多い＝ファクトにないキーはフィルターしてもレコードが存在しないため数値は0になる

6. よくある質問（FAQ）

6-1. 多対多のリレーションをそのまま使ってはダメなの？

絶対にダメというわけではありません。 Power BIは近年、多対多のリレーションに対応しています。ただし、下記のようなリスクがあるため、原則的には「1対多へ分解して整合性を取りやすくする」方がベターです。

計算結果が想定外になる
フィルターの向きが分かりにくい
データ量が増えたときにパフォーマンス面でトラブルが起きやすい

6-2. 中間テーブルが複数必要な場合は？

ビジネス要件によっては、複数の異なる中間テーブル（ブリッジテーブル）を用意するケースもあります。例えば、商品ID用、日付用、顧客ID用など。
ただし、乱立させるとモデルが複雑化するため、なるべく集約できないか検討することも大切です（星型スキーマ、スノーフレークスキーマの考え方を参考にしましょう）。

6-3. 中間テーブルをDAXの計算テーブルで作るか、Power Queryで作るかの違いは？

Power Queryで作る: ユーザーインターフェースで行うため直感的。リレーションやモデリングの前段階でテーブルを準備できる。
DAXの計算テーブルで作る: モデル上の他テーブルを参照して、より柔軟なロジックで作れる。設定が簡単だが、容量やパフォーマンスには注意。

大規模データセットや繰り返し参照する場合は、Power Query側で事前にまとめるほうが最適なことが多いです。

7. まとめ

中間テーブル（ブリッジテーブル） とは、複雑なリレーションシップを整理・シンプル化するために「IDやキーとなる列」を独立して保持するテーブルです。
多対多のまま直接リレーションを張ることは可能ですが、予期せぬ挙動や集計エラー、パフォーマンス低下を招きやすいため、原則は 1対多のリレーション による安定したデータモデルを目指すのがベストプラクティスです。
作成は Power Query か DAXの計算テーブル で行い、必要なキー列と最小限の属性情報を保持するようにします。
スライサーやビジュアルで中間テーブルのフィールドを使えば、フィルターコンテキストがスッキリと伝わり、正しい集計結果が得られます。

データモデリングは見落としがちですが、レポートを長く運用していくうえで非常に重要なステップです。中間テーブルを活用し、よりわかりやすくメンテナンスしやすいPower BIダッシュボードを実現してみてください。

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

「Power Automate のフロー設計が複雑でわからない」「Power BI 有料プランに移行すべきか判断が難しい」「会社全体で短期間にスキルを高めたい」といったお悩みがあれば、お気軽にご相談ください。
もし困り事があるなら、まずは無料相談はこちら

コンサルサービスの詳細や成功事例なども合わせてご紹介し、社内にデータ活用や自動化のノウハウが十分でない場合でも伴走サポートを提供いたします。

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

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

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

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

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

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

これで、Power BIにおける中間テーブル（ブリッジテーブル）の活用方法がイメージいただけると思います。データ構造を正しく整えることは、正確で説得力ある分析・レポートを作る上での大切な基盤です。ぜひ本記事を参考に、実際のデータモデル構築へ活かしてみてください。

Power BIで中間テーブルを活用：複雑なデータモデリングをシンプルに