同じ会社や商品でも、全角・半角、余分な空白、略称、旧名称が混ざると、ピボットテーブルでは別項目として集計されます。Power Queryでは、機械的に直せる文字を正規化したうえで、変換表と結合して正式名称へ統一できます。この記事では、変換表を育てながら更新できる名寄せ手順と、あいまい結合を人の確認なしで確定させないための境界を解説します。
- 空白・制御文字・英字表記をPower Queryで正規化できる
- 変換前と正式名称を持つ変換表で名寄せを更新可能にできる
- 未一致とあいまい一致を監査し、誤結合を防げる
先に結論：名寄せは正規化・変換表・監査の3段階で行う
表記ゆれを見つけるたびにクエリへ置換ステップを追加すると、ルールが散らばり、誰が何を正式名称と決めたのか分かりにくくなります。名寄せは、文字の正規化、管理表による対応付け、未一致の監査に分けて設計します。
名寄せの全体像では、自動で確定できる処理と、人が判断する処理の境界を確認してください。
この設計なら、新しい表記ゆれが出てもクエリ本体を変更せず、変換表への行追加で対応できます。更新結果と判断履歴が分離され、担当者が変わっても追跡しやすくなります。
| 段階 | 処理例 | 判断者 |
|---|---|---|
| 正規化 | トリム、クリーン、大文字化、記号除去 | ルールで自動 |
| 変換表 | (株)ABC→ABC株式会社 | 業務担当が登録 |
| 監査 | 未一致・複数候補・低スコア | 人が確認 |
表記ゆれが集計と結合へ与える影響
同じ対象が別の値として集計される
ABC株式会社、ＡＢＣ株式会社、ABC株式会社 は、人には同じに見えても文字列として異なります。そのまま集計すると売上が3行へ分かれ、上位顧客や構成比が正しく見えません。
マスター結合で未一致になる
取引データの会社名と顧客マスターの会社名が完全一致しなければ、通常のマージでは対応する顧客コードを取得できません。未一致を空欄のまま放置すると、地域、業種、担当者などの分析軸も欠落します。
似ている名称を同一視する危険
一方で、文字を削りすぎると別会社を同じ対象として扱う危険があります。例えばABC東京とABC大阪が別法人なら、地域語を一括削除してはいけません。名寄せは文字の近さだけでなく、顧客コード、住所、電話番号などの業務情報で判断します。
どの表記へ統一するかを決めずに置換を始めると、担当者ごとに結果が変わります。顧客マスターや商品マスターなど、正式名称の基準となる表を明確にしてください。
表記ゆれが標準名へ変わるまでの処理を追います。
元名称を直接上書きせず、照合用キーと標準名称を追加すると、原文を残したまま集計軸だけを統一できます。
Power Queryで名寄せする7ステップ
処理の中心は、正規化したキーで左外部結合し、正式名称がある行だけ置き換えることです。
元の文字列を上書きしないことが重要です。誤った変換が見つかったとき、原文と採用した正式名称を比較できれば、ルールの修正と再更新ができます。
手順1：元の名称列を複製して保持する
会社名や商品名の元列を複製し、会社名_元として残します。処理対象の列は会社名_正規化などの名前にします。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。
原文は監査証跡です。正規化後の値だけを残すと、どの文字が原因で一致しなかったのか調べられません。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。
出力表に元名称、正規化キー、正式名称の3列が並ぶ設計になっているか確認します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。
手順2：トリムとクリーンを適用する
名称列を選び、変換、書式からトリミングとクリーンを適用します。必要に応じて全角スペースを半角へ置換します。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。
前後の空白や印刷できない制御文字は画面で見つけにくい一方、完全一致を妨げます。まず機械的に安全な文字を除去します。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。
正規化前後の個別件数を比較し、同じ名称にまとまった値と、まだ分かれている値を確認します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。
手順3：英字・記号のルールを統一する
英字を大文字または小文字へ統一し、会社種別の括弧、ハイフン、全角英数字など、業務で同一と判断できる記号を置換します。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。
正規化ルールは適用順で結果が変わります。例えば全角スペースを半角にしてからトリムするなど、処理順を固定します。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。
別法人を区別する文字まで消していないか、代表的な名称10件程度を正規化前後で照合します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。
手順4：変換表をExcelテーブルで作る
別シートに変換前、正式名称、必要なら確認者と確認日を持つテーブルを作ります。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。
変換表をクエリ外で管理すると、現場担当者がPower Queryエディターを開かずにルールを追加できます。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。
変換前キーに重複がなく、1つの別名が複数の正式名称へ割り当てられていないことを確認します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。
手順5：変換表にも同じ正規化を適用する
変換表の変換前にも、元データと同じトリム、クリーン、大小文字、記号処理を適用し、変換キーを作ります。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。
片側だけを正規化すると、見た目が近くても結合キーが一致しません。共通関数として切り出せる場合は、同じ関数を両方へ適用します。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。
元データと変換表のキー列が同じデータ型で、nullや空文字がキーとして残っていないか確認します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。
手順6：左外部結合して正式名称を採用する
元データを左側、変換表を右側にし、正規化キーで左外部結合します。正式名称を展開し、値がある場合は正式名称、ない場合は元名称を採用する条件列を作ります。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。
左外部結合なら、変換表に未登録の取引行も消えません。未一致を残しつつ、登録済みの別名だけを統一できます。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。
結合前後の行数が同じか確認します。増えた場合は変換表キーの重複、減った場合は結合種類や途中フィルターを疑います。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。
手順7：未一致一覧を参照クエリで作る
名寄せクエリを参照し、正式名称がnullの行だけを残します。名称ごとに件数や金額を集計し、影響の大きいものから変換表へ追加します。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。
未一致を完成データの中で探すより、監査用クエリとして分離する方が更新後の確認を定型化できます。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。
未一致件数が前回より増えていないか、重要顧客や高額取引が含まれていないかを確認します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。
変換表を壊れにくく運用する
1つの変換キーに1つの正式名称を割り当てる
変換表で同じ変換キーが2行あり、異なる正式名称が登録されると、マージ後の元データが複製されます。変換キーをグループ化して件数を数え、2件以上をエラーとして抽出します。
追加と変更の履歴を持つ
変換前と正式名称だけでも処理はできますが、誰が、いつ、何を根拠に登録したかを残すと誤変換を修正しやすくなります。重要データでは確認者と確認日を持ち、変更前の行を履歴として保存します。
元データの品質改善へ戻す
変換表が増え続ける場合、入力システムや取引先コードの運用に問題があります。Power Queryで吸収するだけでなく、上位の表記ゆれを入力側へ伝え、選択式やコード入力へ変更すると、名寄せコストを減らせます。
変換表の品質は、次の6項目で確認します。
変換表は単なる置換リストではなく、業務上の同一性を記録するマスターです。件数が少なくても、重複と判断履歴を確認できる形にします。
結合後の行は一致と未一致へ分けて扱います。
未一致を削除すると売上や件数が欠落します。通常データと例外データを別の出口へ流し、未一致件数がゼロになるまで確認します。
あいまい結合を使う場面と使わない場面
Power Queryのあいまい結合は、テキスト列の類似度から候補を探します。タイプミスや単語の分割など、完全一致しない名称から候補を見つける用途に役立ちます。
ただし、類似度が高いことと、業務上同じ会社・商品であることは同じではありません。名称が短い、系列会社が多い、支店名が重要な場合は、誤結合の影響が大きくなります。
| 方法 | 得意なこと | 確定方法 |
|---|---|---|
| 正規化 | 空白・大小・記号など明確なルール | 自動確定しやすい |
| 変換表 | 略称・旧称・業務固有の別名 | 人が登録した対応で確定 |
| あいまい結合 | タイプミスや未知の表記の候補抽出 | 類似度と補助情報を人が確認 |
安全な使い方
- 正規化と変換表で確定できる行を先に処理する
- 未一致行だけをあいまい結合の対象にする
- 候補数を制限し、類似度スコアを出力する
- 住所、電話番号、コードなど別の列で確認する
- 確定した組み合わせを変換表へ登録する
この流れなら、あいまい結合は毎回の自動確定ではなく、新しい別名を発見する補助機能になります。誤結合を見逃しにくく、次回更新からは明示的な変換表で再現できます。
名寄せできない原因と対処法
正規化後も一致しない
空白や大小文字をそろえても、変換表に対応が見つからない値が残ります。 この状態で更新を続けると、見た目は完成していても集計軸が分裂したり、明細が欠落したりするため、結果だけを手直ししてはいけません。
略称、旧社名、語順違いなど、文字置換だけでは表せない業務上の別名が原因です。 原因を特定するときは、エラーが見えた最終ステップから戻るのではなく、値が初めて想定外になったステップを探します。
未一致一覧を確認し、正式名称を判断して変換表へ追加します。 修正ルールは元データを直接書き換えるのではなく、クエリの変換または管理可能なマスター表として残します。
追加後の更新で未一致件数が減り、行数や金額が維持されることを確認します。 修正後は正常行だけでなく、例外行が0件になったか、または意図した監査表へ分離されたかまで確認します。
マージ後に行数が増える
名寄せ後の取引件数や売上合計が元データより増えます。 この状態で更新を続けると、見た目は完成していても集計軸が分裂したり、明細が欠落したりするため、結果だけを手直ししてはいけません。
変換表に同じ正規化キーが複数あり、1つの取引が複数の正式名称へ一致しています。 原因を特定するときは、エラーが見えた最終ステップから戻るのではなく、値が初めて想定外になったステップを探します。
変換表をキーでグループ化し、重複を業務判断で解消します。 修正ルールは元データを直接書き換えるのではなく、クエリの変換または管理可能なマスター表として残します。
結合前後の行数と金額合計が一致し、重複キー一覧が0件であることを確認します。 修正後は正常行だけでなく、例外行が0件になったか、または意図した監査表へ分離されたかまで確認します。
異なる会社が同じ名称になる
正規化後に本来別の法人や支店が同じキーへまとまります。 この状態で更新を続けると、見た目は完成していても集計軸が分裂したり、明細が欠落したりするため、結果だけを手直ししてはいけません。
株式会社、地域名、番号など、区別に必要な文字まで一括削除しています。 原因を特定するときは、エラーが見えた最終ステップから戻るのではなく、値が初めて想定外になったステップを探します。
削除ルールを弱め、会社コードや住所などの補助キーを組み合わせます。 修正ルールは元データを直接書き換えるのではなく、クエリの変換または管理可能なマスター表として残します。
誤結合した代表例をテストデータとして残し、更新後も別々になることを確認します。 修正後は正常行だけでなく、例外行が0件になったか、または意図した監査表へ分離されたかまで確認します。
変換表は一度作って終わりではなく、未一致から育てます。
変換表を業務ルールとして管理すれば、次回以降は同じ表記ゆれが自動で標準名へ変換されます。
名寄せルールを継続運用するポイント
変換表の追加権限と承認方法を決める
誰でも変換表を変更できる状態では、同じ別名が別の正式名称へ割り当てられる可能性があります。登録者と確認者を決め、重要顧客や高額取引に関わる変更は二重確認にします。
変換表の行を削除すると過去の更新結果も変わります。誤登録を直す場合は、変更理由と適用日を残し、過去レポートを再計算するか、変更日以降だけ適用するかを決めます。
未一致を件数だけで判断しない
未一致1件でも大口顧客なら影響が大きく、100件あっても少額の自由記述なら優先度が低い場合があります。未一致名称ごとに行数、金額、最新発生日をまとめ、業務影響で対応順を決めます。
前回まで一致していた名称が未一致になった場合は、変換表の削除、正規化ルールの変更、マスター改訂を疑います。新規未一致と再発未一致を分けて確認すると、原因を特定しやすくなります。
正解データをテストケースとして残す
全角・半角、前後空白、略称、旧社名、似た別会社など、代表的な入力と期待する正式名称を少数のテスト表へ残します。クエリや変換表を変更した後、この表を更新して結果を比較します。
名寄せはルールを増やすほど安全になるわけではありません。誤って同一化してはいけない組み合わせもテストへ含め、正しく一致することと、正しく一致しないことの両方を品質基準にします。
よくある質問
置換機能だけで名寄せしてはいけませんか？
件数が少なく、一度だけ使うデータなら置換でも対応できます。毎月更新する、判断ルールを複数人で管理する、別名が増える場合は、変換表に分離した方が変更履歴と未一致を管理しやすくなります。
会社名から株式会社を削除してもよいですか？
分析目的とデータの性質によります。会社種別を除いても一意性が保てるなら正規化キーから除外できますが、正式名称列では保持します。同名企業が存在する場合は顧客コードや所在地も使ってください。
あいまい結合のしきい値はいくつが正解ですか？
一律の正解はありません。名称の長さや似た候補数によって誤結合率が変わります。正解が分かっているサンプルで複数のしきい値を比較し、低スコアや複数候補を人が確認する運用にします。
まとめ：変換表を育てる名寄せにする
Power Queryの名寄せは、トリムやクリーンだけで終わりません。まず安全に自動化できる文字を正規化し、業務判断が必要な別名は変換表で正式名称へ対応付け、未一致を監査します。
元名称を残し、正規化キーで左外部結合すれば、未登録の取引を消さずに名寄せできます。変換表の重複は行数増加につながるため、1つの変換キーに1つの正式名称というルールを守ります。
あいまい結合は便利ですが、候補抽出として使い、確認済みの対応を変換表へ戻す設計が安全です。更新のたびに未一致一覧を確認し、変換表と入力品質の両方を改善していきます。
コメント