Power BIで分析を始めると、かなり早い段階で「2つのテーブルを結合したい」という場面が出てきます。売上明細に商品マスタをくっつけたい、勤怠に部署マスタを付けたい、実績と予算を同じ軸で比較したい、アンケート結果に社員情報を紐づけたい。こうした要望は自然です。
ただ、Power BIでの「結合」はひとつのやり方に限りません。Power Queryで物理的に結合（マージ）する方法もあれば、モデル上でリレーションを結ぶ方法もあります。さらにDAXで必要なときだけ結合に近いことをする選択肢もあります。ここを混同すると、数字が合わない、データが増殖する、更新が遅い、モデルが壊れやすい、といったトラブルにつながります。
この記事では、power bi 2つのテーブルを結合したいときに迷わないために、まず考える順番、結合の種類、手順、よくある失敗と対処、性能面の注意点までを、できるだけわかりやすくまとめます。
最初に結論：結合には3つのやり方がある
Power BIで2つのテーブルを結合する方法は、大きく次の3つに分かれます。
-
Power Queryで結合（マージ）する
データ取り込み時にテーブル同士を結合して、1つのテーブルに必要な列を増やすやり方です。SQLでいうJOINに一番近い発想です。 -
モデルでリレーションを結ぶ
テーブルは別々のまま、関係（1対多など）を設定して、フィルターや集計を連携させます。スター型モデルで最も推奨されやすい考え方です。 -
DAXで必要なときだけ紐づける
テーブルを物理的に結合しなくても、メジャーや計算列で必要なロジックだけを実現します。万能ではないですが、要件によっては最小変更で済みます。
初心者がやりがちな失敗は、何でもPower Queryで結合して巨大な1枚テーブルを作ってしまうこと、または逆に、結合が必要なのにリレーションだけで何とかしようとして数字が合わないことです。まずは目的から選び分けるのが一番の近道です。
どう選ぶ？結合（マージ）とリレーションの使い分け
同じ「くっつけたい」でも、目的が違います。次の質問で選ぶと迷いにくいです。
A. 欲しいのは列か、それとも集計の連携か
・あるテーブルに別テーブルの列を追加したい（例：売上明細に商品カテゴリ列を追加）
これはPower Queryの結合（マージ）が向いています。もちろんリレーションでも参照できますが、実務では「明細側でその列を使って加工したい」「文字列を整形したい」などがあるとマージの方が扱いやすいことがあります。
・テーブルは分けたまま、スライサーで絞った結果が集計に反映されればよい（例：商品カテゴリで売上を絞りたい）
これはリレーションが向いています。モデルがきれいに組めると、重複や増殖の事故が減り、保守もしやすいです。
B. 結合した結果、行が増えても問題ないか
Power Queryの結合は、キーの状態によっては行が増えます。たとえば、明細（多）にマスタ（多）がぶつかると、結合の仕方によっては同じ明細が複製されることがあります。行が増えると、集計が二重計上になりがちです。行が増えて困る場合は、まずリレーションでモデルを組むことを検討します。
C. 更新と性能の制約が厳しいか
大きいテーブル同士をPower Queryで結合すると、更新時間が増えたり、データセットが肥大化しやすくなります。大規模データや更新頻度が高い場合は、リレーションや集計テーブルの設計が効きます。
この3つを押さえるだけで、「結合したのに重い」「合計が合わない」事故の大半を避けられます。
Power Queryで2つのテーブルを結合する手順（マージ）
ここからは、power bi 2つのテーブルを結合する方法として一番イメージしやすい、Power Queryのマージ手順を整理します。
手順1：結合キーを決める
最初に、両テーブルで共通しているキーを確認します。例を挙げると以下です。
・売上明細：ProductID
・商品マスタ：ProductID
よくある落とし穴は、見た目は同じでも実際は一致していないケースです。ゼロ埋めの有無、全角半角、前後スペース、ハイフンの種類、英字の大文字小文字などで一致しなくなります。結合に入る前に、キーを正規化しておくのが安全です。
手順2：キー列のデータ型を合わせる
片方が数値、片方が文字列だと結合がうまくいかないことがあります。Power Query上でデータ型を揃えます。特に、郵便番号や社員コードのようにゼロから始まる可能性があるものは、数値にするとゼロが落ちるので注意が必要です。
手順3：Power Queryでマージを実行する
Power Queryエディターで、結合したい側のクエリを開きます。次に「クエリの結合（マージ）」を選び、結合先のテーブルとキー列を指定します。ここで結合の種類（結合方法）を選びます。
手順4：結合の種類（JOIN種類）を選ぶ
結合方法は目的で選びます。代表的なものは次の通りです。
・左外部結合（Left Outer）
左側テーブルの行をすべて残し、右側が一致するものだけ列を付けます。売上明細に商品情報を付けたい、といった典型はこれです。
・内部結合（Inner）
キーが一致した行だけ残します。不一致を捨ててよい場合に使います。
・完全外部結合（Full Outer）
左右両方の行をすべて残し、一致した部分は合わせます。差分確認やデータ突合の用途で便利ですが、分析の主テーブルとしては慎重に使います。
・左反結合（Left Anti）
左側にあって右側にない行だけを残します。たとえば「売上明細にあるが商品マスタに存在しないProductIDを抽出」など、データ品質チェックに使えます。
結合の種類を間違えると、消えるべき行が残ったり、残るべき行が消えたりします。最初は左外部結合が基本、差分確認は反結合、という感覚で覚えると実務で迷いにくいです。
手順5：展開（Expand）で必要な列だけ取り込む
マージ後は、結合先テーブルが「入れ子のテーブル」として1列に格納されます。ここから必要な列だけを展開して、元のテーブルに追加します。このとき、不要な列まで全部展開するとデータが重くなるので、使う列だけに絞ります。
手順6：結果確認（行数、欠損、重複）
結合が終わったら、次の確認を必ず行います。
・結合前後で行数が増えていないか
増えている場合は、結合先が一意ではない可能性があります。マスタ側が重複していると、明細が複製されて二重計上の原因になります。
・結合した列にNullが多くないか
一致していないキーがあるサインです。キーの正規化、型の不一致、ゼロ埋めのズレなどが疑われます。
・意図した列だけが入っているか
展開する列を絞り、型も整えます。
ここまでが、Power Queryでの結合の基本の流れです。
失敗しやすいポイント：結合で行が増殖するパターン
power bi 2つのテーブルを結合したときに、最も危険なのが「行が増える」ことです。例で説明します。
・売上明細（ファクト）：ProductIDが同じ行が何千行もある
・商品マスタ（本来は1側のはず）：ProductIDが重複して2行以上ある
この状態で左外部結合すると、売上明細の各行が、重複している商品マスタの行数分だけ複製されます。結果として、売上金額が倍になったり三倍になったりします。見た目はそれっぽく動くので、気づきにくいのが厄介です。
対処はシンプルで、商品マスタ側を「ProductIDごとに1行」に整えることです。Power Queryで重複の削除をしてディメンションを作る、あるいはデータソース側で正しいマスタを用意する、という方向が基本です。どうしても履歴や条件違いで重複が必要なら、そもそもそれはマスタではなく別粒度のテーブルです。結合する前に設計を見直した方が安全です。
リレーションで2つのテーブルをつなぐ（結合しないで連携する）
次に、物理的に結合せずに「つながっているように見せる」方法です。これはスター型モデルを組むときの王道です。
例：売上明細（多）と商品マスタ（1）
・商品マスタのProductIDは一意
・売上明細のProductIDは繰り返し出てくる
この場合、モデルビューで両テーブルに関係を設定します。基本は1対多、フィルター方向は単方向（1側から多側）にします。すると、商品カテゴリで絞ると売上明細が絞られ、売上集計が変わる、という動きが実現できます。
リレーションの良いところは、テーブルを分けたままなので、無駄に列を複製しにくく、モデルが整理されやすい点です。また、後から別のファクト（例：予算）を足すときも、同じ商品マスタを共有して比較がしやすくなります。
逆に、リレーションだけだと困る場面もあります。たとえば、売上明細を加工して「商品カテゴリ別のコード変換」をしたい、行レベルで別表の情報を使って条件分岐したい、といった場合は、結合して列を増やした方が素直なことがあります。ここが使い分けポイントです。
予算と実績を結合したいときの考え方（同じ軸で比較する）
実務で非常に多いのが「予算テーブル」と「実績テーブル」をまとめて見たいケースです。ここでやりがちなのが、Power Queryで2つを無理やり結合して1テーブルにしようとすることです。もちろん可能ですが、設計によっては複雑になりやすいです。
整理すると、予算と実績には典型パターンが2つあります。
パターン1：予算と実績を縦に積む（追加する）
予算も実績も「日付、部門、金額」のように同じ形なら、結合ではなく追加（Append）で縦に積む方が自然です。積んだ後に区分列（予算/実績）を付ければ、同じ軸で比較しやすくなります。
パターン2：予算と実績を別テーブルのまま、ディメンションを共有する
予算と実績が粒度や項目で違う場合は、無理に一体化せず、日付テーブルや部門テーブルを共有して、モデル上で比較する方が安定します。たとえば、実績は日次、予算は月次、のような場合はこの形が向いています。
どちらがよいかは、粒度（1行が何を表すか）が合うかどうかで決めると失敗しにくいです。
DAXで結合っぽいことをする場面（最小変更で済ませたいとき）
3つ目の選択肢がDAXです。Power Queryで結合するほどではないが、メジャーで参照したい、あるいは非アクティブ関係を使いたい、といった場面で出てきます。
代表例としては、次のようなケースがあります。
・同じファクトに日付列が2つある（注文日と出荷日など）
関係は1本だけアクティブにし、もう1本は非アクティブにして、必要なメジャーだけ切り替えて集計します。
・キーが直接一致しないが、特定の条件で紐づけたい
完全に結合するより、メジャー側で条件を指定して集計する方が安全な場合があります。
・本来はモデル設計で解決すべきだが、短期的に対処したい
ただし、DAXで無理をすると保守が難しくなるので、恒久対応はデータ整備やモデル見直しに寄せた方が長期的には楽です。
DAXは便利ですが、結合の万能薬ではありません。最終的にモデルが分かりにくくなるなら、Power Queryやリレーションで解けないかを先に検討するのが安全です。
結合キーが合わないときのチェックリスト（動かない原因はだいたいここ）
結合がうまくいかない、Nullが大量に出る、期待した行がつながらない。こうしたときは、次を順番に見ていくと原因に当たりやすいです。
-
データ型が一致しているか
文字列と数値、日付と文字列など。 -
前後スペースや不可視文字が混ざっていないか
見た目では気づきにくいです。トリムで除去します。 -
ゼロ埋めの有無が揃っているか
例：00123 と 123 は別物です。 -
大文字小文字、全角半角、記号の種類が揃っているか
ハイフンが違うだけでも一致しません。 -
キーが一意か（特に1側）
マスタの重複は増殖の原因です。 -
欠損や不正値の扱いが決まっているか
空白キーは「不明」として別カテゴリに落とすなど、運用を決めると後で困りにくいです。
このチェックだけで、結合トラブルの多くは解決します。
速度とサイズを悪化させないための考え方
power bi 2つのテーブルを結合すると、便利な反面、更新が遅くなる、データセットが重くなる、といった影響が出ることがあります。性能面で意識したいポイントを整理します。
・必要な列だけ展開する
結合先から全列を持ってくると、容量も更新も重くなります。
・明細同士の結合は慎重に
明細×明細の結合は行数が爆発しやすいです。可能ならディメンションを介したスター型に寄せます。
・データソースがDBの場合、なるべくソース側で処理できる形にする
Power Queryの変換がデータソース側で実行できると更新が速くなりやすいです。逆に、Power Queryで行ごとの複雑な加工を増やすと更新が重くなります。
・「結合して1枚にする」が正解とは限らない
分析で必要なのは、同じ定義で集計できることです。列追加が目的でなければ、リレーションで十分なことが多いです。
性能が気になるときは、まず列削減とモデル整理を優先し、その次に結合方法を見直すと効果が出やすいです。
実務でのおすすめ手順（迷ったらこの順で進める）
最後に、実際の案件で「2つのテーブルを結合したい」と言われたときのおすすめ手順をまとめます。
手順1：目的を決める
列を追加したいのか、集計連携したいのか。
手順2：キーを点検する
データ型、正規化、重複、欠損。
手順3：まずはリレーションで解けないか考える
スター型で組めるなら、壊れにくく保守しやすいです。
手順4：列が必要ならPower Queryでマージする
結合種類は左外部結合から検討し、展開列は最小限に。
手順5：行数の増殖とNullをチェックする
結合後の行数、欠損割合、集計値が想定と合うかを確認します。
手順6：重い場合は設計を見直す
不要列削減、ディメンション分離、明細の見せ方（集計してからドリル）などで体感が改善します。
この流れで進めると、結合に関するトラブルの大半は避けられます。
まとめ
power bi 2つのテーブルを結合する方法は、Power Queryでマージする、モデルでリレーションを結ぶ、DAXで必要なときだけ紐づける、の3つが基本です。どれが正解かは、目的（列が欲しいのか、集計の連携が欲しいのか）、行が増えて困らないか、更新や性能の制約があるかで決まります。
まずはキーの整備が最優先です。キーの型を揃え、表記ゆれを正し、1側の一意性を確保する。ここができていれば、結合もリレーションも安定します。反対に、ここが崩れていると、どの方法を選んでも数字が合わない、重い、壊れる、のループに入ります。
結合は便利ですが、便利だからこそ「結合しないで済むなら結合しない」という発想も大切です。目的に合った方法を選び、必要最小限の結合で、壊れにくいモデルを作る。これが、Power BIで長く使えるレポートを作る一番の近道です。
コメント