Power Queryで結合できない原因7選｜マージのエラーを直す方法

先に結論：マージエラーはキー品質・関係・結合種類で切り分ける

一致しないときは、左右のキーを同じ型・同じ文字・同じ桁へ整えます。行数が増えるときは右側キーの重複、行が消えるときは内部結合や途中フィルターを疑います。

結合後の結果だけを直さず、未一致を左反結合で一覧化し、マスター重複を別クエリで監査します。正常データと例外データを同じ更新で確認できるようにします。

症状が違えば、最初に確認する場所も変わります。

エラーが表示されないまま誤った結果になるケースもあります。マージ前後の行数と数量・金額合計を記録することが、最も早い異常検知になります。

マージを診断する前提

左と右、キー、期待する関係を言葉にする

売上へ商品マスターを付けるなら、左は売上、右は商品マスター、キーは商品番号、期待関係は多対1です。どちらの全行を残すか、右側キーが一意かを先に明確にします。

キーの見た目だけで判断せず、データ型、文字数、前後空白、null、個別件数を確認します。Power Queryの列プロファイルも診断に役立ちます。

結合前に売上行数、数量合計、金額合計、マスター行数、マスター個別キー数を記録します。修正後の正しさを判断する基準になります。

診断用のコピーではなく参照クエリを作る

元クエリを複製すると処理が分岐し、修正が片方にしか反映されないことがあります。完成クエリを参照し、未一致、重複、型エラーなどの監査クエリを作ります。

診断中も元キーを残します。トリムやゼロ埋め後のキーを別列にし、どの変換で一致したか追跡できるようにします。

左右のキーが一致判定へ届く前に通る処理を確認します。

結合ボタンを押す前に、左右キーを同じ処理へ通すことが重要です。片側だけTrimや型変換をしても一致率は改善しません。

結合できない原因を調べる7ステップ

症状から順番に確認する診断フローです。

7項目を一度に変更せず、1つずつ確認します。複数の問題が同時にある場合も、未一致件数の変化から各修正の効果を判断できます。

手順1：左右のデータ型をそろえる

キー列の型アイコンを確認し、両方をテキストまたは整数へ統一します。コードは通常テキストが安全です。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。

数値123と文字列”123″は同じ見た目でも結合キーとして一致しません。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。

型変換エラーとキーの最小・最大文字数を確認します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。

手順2：トリムとクリーンを適用する

テキストキーへトリム、クリーンを適用し、全角スペースや改行を必要に応じて置換します。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。

見えない文字は完全一致を妨げ、画面の目視では発見しにくいです。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。

変換前後の文字数と個別件数を比較します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。

手順3：先頭ゼロと記号を統一する

00123と123のどちらが正式か決め、テキストのゼロ埋めやハイフン統一を行います。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。

数値化で失った先頭ゼロは型を戻すだけでは復元できません。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。

正式なコード桁数と一致し、別コードを同一化していないか確認します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。

手順4：nullと空文字を監査する

キーがnull、空文字、空白だけの行を抽出し、除外・補完・未設定として残すルールを決めます。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。

値がない行はマスターへ正常に対応付けできず、置換で架空の共通キーを作ると誤結合します。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。

null件数と影響金額を確認します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。

手順5：マスターキーの一意性を確認する

右側キーでグループ化して行数を数え、2件以上を抽出します。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。

右側重複は左明細を一致数だけ複製し、合計を増やします。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。

マスター行数と個別キー数が一致するか確認します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。

手順6：左外部・内部・反結合を確認する

売上を残すなら左外部を基本とし、未一致調査には左反結合を使います。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。

内部結合では未一致の売上行が結果から消えます。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。

結合前後の左行数と未一致件数を比較します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。

手順7：複合キーと選択順を確認する

商品番号だけで一意でなければ会社コード+商品番号など必要列を同じ順で選びます。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。

キーが粗いと誤った複数行へ一致し、順番が違うと一致しません。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。

複合キーの重複と代表行の属性を確認します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。

診断に使えるMコード

画面操作で作れますが、Mコードを読むと、キー整形と結合種類を確認しやすくなります。

テキストキーを整えて左外部結合する例

元キーを残し、正規化キーを別列へ作ります。

let
    売上キー追加 = Table.AddColumn(売上, "商品キー", each Text.PadStart(Text.Clean(Text.Trim(Text.From([商品番号]))), 5, "0"), type text),
    マスターキー追加 = Table.AddColumn(商品マスター, "商品キー", each Text.PadStart(Text.Clean(Text.Trim(Text.From([商品番号]))), 5, "0"), type text),
    結合 = Table.NestedJoin(売上キー追加, {"商品キー"}, マスターキー追加, {"商品キー"}, "商品", JoinKind.LeftOuter)
in
    結合

ゼロ埋め桁数は業務ルールに合わせます。すべてのコードへ機械的に適用する前に、元コード体系を確認してください。

マスター重複を抽出する例

キーごとの件数を数え、2件以上だけを残します。

let
    件数 = Table.Group(商品マスター, {"商品キー"}, {{"行数", each Table.RowCount(_), Int64.Type}}),
    重複 = Table.SelectRows(件数, each [行数] > 1)
in
    重複

重複削除で1行を無作為に残すのではなく、複合キー不足、履歴、入力重複のどれかを確認します。

右側キーの重複が出力行数へ与える影響です。

マージが成功して値が表示されても、行数が増えていれば集計結果は誤ります。展開前後の行数と金額合計を必ず比較します。

マージ後に必ず行う検算

結合前後で左明細の行数が維持されるかを確認します。ただし右側に1対多を意図した結合では増加が仕様の場合もあるため、期待する関係を先に定義します。

数量・金額合計も照合します。行数が同じでも誤った属性へ一致している可能性があるため、高額行や主要コードをサンプル確認します。

マージ品質を6つの指標で確認します。

行数・合計・未一致・代表値を組み合わせると、欠落、複製、誤一致の3種類を検出しやすくなります。

監査クエリは毎回更新し、前回件数と比較します。未一致0件でも、誤った共通キーへ一致していれば問題なので、キー変換の代表例をテストとして残します。

原因7選を症状別に詳しく確認する

原因1・2：型と見えない文字

ほぼ同じコードなのに広範囲で一致しません。 この状態で更新を続けると、見た目は完成していても集計軸が分裂したり、明細が欠落したりするため、結果だけを手直ししてはいけません。

数値とテキスト、前後空白、制御文字、全角空白が混在しています。 原因を特定するときは、エラーが見えた最終ステップから戻るのではなく、値が初めて想定外になったステップを探します。

両側へ同じ型・トリム・クリーン処理を適用し、元キーを保持します。 修正ルールは元データを直接書き換えるのではなく、クエリの変換または管理可能なマスター表として残します。

未一致件数と文字数分布が改善するか確認します。 修正後は正常行だけでなく、例外行が0件になったか、または意図した監査表へ分離されたかまで確認します。

原因3・4：桁とnull

特定桁のコードや空欄行だけが一致しません。 この状態で更新を続けると、見た目は完成していても集計軸が分裂したり、明細が欠落したりするため、結果だけを手直ししてはいけません。

先頭ゼロ消失、ハイフン差、null・空文字がキーに含まれます。 原因を特定するときは、エラーが見えた最終ステップから戻るのではなく、値が初めて想定外になったステップを探します。

正式コード体系に合わせてゼロ埋め・記号統一し、nullは例外へ分離します。 修正ルールは元データを直接書き換えるのではなく、クエリの変換または管理可能なマスター表として残します。

桁数別未一致とnull影響額を確認します。 修正後は正常行だけでなく、例外行が0件になったか、または意図した監査表へ分離されたかまで確認します。

原因5：マスター重複

結合後の行数と売上合計が増えます。 この状態で更新を続けると、見た目は完成していても集計軸が分裂したり、明細が欠落したりするため、結果だけを手直ししてはいけません。

右側に同じキーが複数行あります。 原因を特定するときは、エラーが見えた最終ステップから戻るのではなく、値が初めて想定外になったステップを探します。

重複理由を確認し、正しい複合キーまたは有効期間で1件へ決定します。 修正ルールは元データを直接書き換えるのではなく、クエリの変換または管理可能なマスター表として残します。

右キー重複0件と結合前後合計一致を確認します。 修正後は正常行だけでなく、例外行が0件になったか、または意図した監査表へ分離されたかまで確認します。

原因6・7：結合種類とキー粒度

一部行が消える、または違う属性が付きます。 この状態で更新を続けると、見た目は完成していても集計軸が分裂したり、明細が欠落したりするため、結果だけを手直ししてはいけません。

内部結合、選択順の違い、商品番号だけでは一意でないなどが考えられます。 原因を特定するときは、エラーが見えた最終ステップから戻るのではなく、値が初めて想定外になったステップを探します。

左外部へ変更し、会社・商品など必要な複合キーを同順で選びます。 修正ルールは元データを直接書き換えるのではなく、クエリの変換または管理可能なマスター表として残します。

代表的な複数会社・同一商品コードをテストします。 修正後は正常行だけでなく、例外行が0件になったか、または意図した監査表へ分離されたかまで確認します。

エラーは上から順に切り分けると原因を早く特定できます。

個別の不一致値を見る前に、キー列や結合種類など全体設定を確認します。その後、未一致サンプルと重複へ範囲を狭めます。

完全一致とあいまい一致を使い分ける

商品番号、社員番号、伝票番号などの識別コードは完全一致で結合します。あいまい一致でコードを近さから結ぶと、別レコードを誤って対応付ける危険があります。

会社名や自由記述の名称では、正規化と変換表を先に使い、未一致の候補抽出にあいまい結合を使えます。確定した対応は変換表へ登録し、次回は完全一致で再現します。

マージの成功率だけを上げることが目的ではありません。誤一致を増やさず、未一致を説明できることが品質です。100%一致へ無理に近づけるより、確認対象を明確に残します。

実務で継続運用するためのポイント

クエリ名とステップ名を引き継げる形にする

入力、中間処理、完成データ、監査データの役割が名前で分かるようにします。自動生成された変更された型やカスタム1だけが並ぶ場合は、業務上の目的を表す名前へ変更すると、更新エラーの確認が速くなります。

元データの列名、型、保存場所など、クエリが前提とする条件を簡潔に記録します。操作手順を長く書くより、変えてよい入力と変えてはいけない契約を明示する方が、担当者変更やファイル改訂へ対応しやすくなります。

変更はテスト用ファイルで確認してから本番へ反映する

列追加、命名規則、マスター改訂などの変更があるときは、本番更新の前にコピーしたテスト環境で実行します。正常な既存ファイルと変更後ファイルを同時に試し、過去分を壊さず新形式も処理できるかを確認します。

変更前後の行数、主要合計、未一致、エラー件数を比較し、意図した差だけが生じたことを記録します。見た目が同じでもデータ型やnullの扱いが変わる場合があるため、監査値を変更承認の根拠にします。

更新履歴と復旧方法を残す

更新日、対象期間、採用ファイル、実行者、確認結果を残しておくと、後から数値が変わった理由を追跡できます。エラー時に前回確定版へ戻す方法、元ファイルを再取得する窓口、変換表やマスターの管理者も決めておきます。

自動化の品質は、正常時の速さだけでなく、異常を早く見つけて安全に復旧できるかで決まります。監査クエリを非表示にせず、担当者が更新のたびに確認する標準手順へ組み込みます。

よくある質問

結合時に選ぶ列の順番は重要ですか？

複数列結合では重要です。左で会社コードを1番、商品番号を2番にしたら、右も同じ順番で選びます。見出しに付く番号を確認してください。

nullを0や未設定へ置換すれば結合できますか？

複数の欠損行を同じ架空キーへ置換すると、誤結合する可能性があります。nullは例外として扱い、業務上の正式な未設定コードがある場合だけ使用します。

マージ後の行数が増えるのは必ずエラーですか？

右側の複数履歴へ意図的に展開する設計なら仕様の場合があります。ただし売上へ1件の商品属性を付ける多対1の想定なら、増加はマスター重複やキー粒度不足を示します。

UdemyでPower Queryをさらに学びたい方へ

マージのエラーは、データ型、キー、重複、結合方法を実データで試し、結果の変化を比べることで原因を見分けやすくなります。

Udemyは動画の再生速度を調整でき、必要な箇所を繰り返し確認できます。価格は講座やセール時期によって変わるため、申込み前に講座ページの内容、対応環境、最新価格をご確認ください。

※本記事にはアフィリエイトリンクが含まれます。リンク経由で申込みがあった場合、運営者に報酬が発生することがあります。

まとめ：未一致・複製・欠落を別々に検算する

Power Queryで結合できない原因は、型、空白・制御文字、桁・記号、null、右側重複、結合種類、キー粒度の7つに分けて診断できます。

左右へ同じ正規化を適用し、左外部結合で元明細を残します。未一致は左反結合、マスター重複はグループ化で別クエリへ出します。

結合前後の行数、数量・金額合計、未一致件数、右キー重複、代表属性を確認し、単に一致率を上げるのではなく、誤一致を防ぎながら説明可能な結合にしてください。