Power BI でデータを扱っていると、必ず出てくる作業のひとつが「置換」です。表記ゆれを直す、不要な文字を消す、コードを別の値に置き換える、NULL を埋める、カテゴリ名を統一する。どれも地味ですが、置換が甘いと、集計が割れる、フィルターが効かない、同じはずの値が別物として扱われる、という形でレポートの信頼性が崩れます。
一方で、置換はやり方を間違えると、更新が遅くなる、あとから原因が追えなくなる、別の列まで壊す、といった事故も起きます。特に「その場しのぎの置換」を積み重ねると、半年後に誰も直せないモデルになりがちです。
この記事では、power bi 置換を現場で安全に回すために、どこで置換するべきか、どの粒度でやるべきか、よくある置換パターン、つまずきポイント、運用で壊れない設計をまとめます。
置換の基本方針は「まずデータを汚さない」
置換をするときに最初に意識したいのは、元データの意味を変えすぎないことです。例えば「部署名を統一する」つもりが、別部署と同名にしてしまい、分析上は別物なのに同じ扱いになってしまう。こうなると後から戻せません。
実務でおすすめの考え方は次です。
・元の列は残し、置換後の列を別名で作る(必要なときだけ)
・置換のルールは目に見える形に残す(後から追える)
・置換は局所ではなく、再利用できる形に寄せる(同じ置換を各所に散らさない)
「置換=正規化」の作業だと思うと、やり過ぎや誤置換が減ります。
置換する場所は3つある(迷ったら Power Query から考える)
Power BI で置換をする場所は、大きく3つです。どれでもできる場面がありますが、向き不向きがはっきりしています。
Power Query(取り込み・変換段階)
最もおすすめされやすい置換の場所です。理由は、置換の結果がデータとして確定し、モデルが安定しやすいからです。表記ゆれ、不要文字削除、空白の整理、コード変換などは基本的に Power Query でやると運用が楽になります。
DAX 計算列(モデルに列として追加)
置換結果を列として持ちたい場合に使います。ただし、計算列は更新時に全行計算されるため、大きなテーブルでは重くなりがちです。置換目的が「分類列として使いたい」など明確な場合に限定するのが安全です。
DAX メジャー(表示時に変える)
値そのものを置換するより、表示や条件分岐で別の文字を出したい場合に使います。たとえば、空白なら「未設定」と表示する、特定条件なら警告文を出す、などです。データの正規化には向きませんが、見せ方の調整には便利です。
実務では「データの意味を整える置換は Power Query」「見せ方の置換はメジャー」「分類としての置換は計算列」という住み分けがしっくりきます。
Power Query での置換:最も出番が多い使い方
power bi 置換の中心は Power Query です。現場で頻発する置換を、パターン別に整理します。
表記ゆれの統一(部署名・商品カテゴリ名・拠点名など)
同じ意味なのに、入力した人やシステムが違うと表記が割れます。
例
・「東京」「東京都」「東京本社」
・「営業1部」「営業一部」「営業1部」
・「A社」「A社」「(株)A」「株式会社A」
この状態だと、集計が割れます。置換で統一したいのですが、ここで大事なのは「統一後の名前を業務として合意する」ことです。勝手に短くしたり、別の呼び方にすると、利用者が混乱します。
実務でのやり方としては、まず「辞書テーブル」を作るのが強いです。
・元の値(表記ゆれの候補)
・正規化後の値(統一した名称)
これを Power Query でマージして正規化列を作ると、置換のルールが見える形で残り、後から追加も簡単です。置換の積み重ねより、辞書で管理する方が壊れにくいです。
前後スペース、連続スペース、不可視文字の除去
「置換したのに一致しない」原因の多くは、見えない空白です。
・前後スペース
・全角スペース
・タブ
・改行
・複数スペース
これらは、人間の目では気づきにくいのに、データとしては別物になります。対策は、置換とトリムを組み合わせて正規化します。
実務では次の順番が効きます。
・前後スペースを削る
・連続スペースを1つにする
・全角スペースを半角に揃える(必要なら)
・改行やタブを空白に置換する
文字列は「見えるとおりに一致する」とは限りません。置換で直す前に、まず余計な文字を落とすのが定石です。
記号や接頭辞・接尾辞の除去
コード列や名称列には、システム側の都合で記号が混ざることがあります。
例
・商品コードに「-」「_」が混ざる
・顧客名に「(株)」「株式会社」が混ざる
・部門名に「【】」「()」「※」が混ざる
これも集計が割れる原因になります。ただし、記号を消すと同名衝突が起きることがあるので、衝突しないか確認してから進めます。例えば「A-B」と「AB」が別物として存在するなら、安易に記号を消してはいけません。
NULL や空白の置換(未設定を見える化する)
Power BI は空白を “何もない” として扱いますが、利用者には分かりにくいことがあります。そこで「未設定」などの値に置換したくなる場面があります。
ただし、空白を文字列で埋めると、後で数値計算や関係が壊れることがあります。おすすめは、次のように使い分けることです。
・分類列として必要なら「未設定」を入れる
・計算に使う列は空白のままにして、表示側で「未設定」と見せる
・キー列の空白は、そもそもデータ品質問題なので原因を追う(置換で誤魔化さない)
空白埋めは便利ですが、やりすぎると原因を隠してしまいます。
DAX 計算列での置換:分類やフラグに向く
置換を DAX の計算列でやる場面は、「分類として列が欲しい」場合です。例えば次のようなケースです。
・ステータスを統一して表示したい
・条件に応じてカテゴリを置換したい(例:大分類へまとめる)
・特定の値だけ別名にしたい(表示名を調整したい)
よく使う書き方は SWITCH です。
例:表記ゆれをまとめる(小規模の場合)
ただし、このやり方はルールが増えるほど保守が辛くなります。数十、数百の置換ルールがあるなら、辞書テーブルを作って Power Query で処理した方が現実的です。DAX 計算列で巨大な置換をやると、更新が重くなるだけでなく、ルールの追加が怖くなります。
DAX メジャーでの置換:表示のための置換
メジャーは「表示の言い換え」に向きます。データを正規化する場所ではなく、「見せ方を整える場所」です。
例:値が空白なら “未設定” と表示する
例:特定条件なら警告文を出す
こういう用途なら、置換というより UI の改善として効果があります。データをいじらずに体験を改善できるので、安全に使えます。
置換を増やしすぎないための「辞書テーブル」運用
置換が増えると、どこで何を置換したか分からなくなります。そこで効くのが辞書テーブルです。これは特別な機能ではなく、ただのテーブルです。
構成例
・元の値(RawValue)
・正規化後の値(NormalizedValue)
・対象列(必要なら)
・備考(置換理由、登録日、登録者)
辞書テーブルを使うメリット
・置換ルールが一覧で見える
・追加や修正が簡単
・レビューできる(勝手な置換が減る)
・同じ置換を複数レポートで再利用できる
・Power Query のマージで処理できるので、モデルが安定する
表記ゆれが多い領域(顧客名、商品名、部署名、拠点名)は、置換をコードに埋め込まず辞書化する方が、長期的に運用が楽です。
置換でよく起きる事故と防ぎ方
power bi 置換の事故は、意外とパターンが決まっています。
事故1:置換したら別の値まで巻き込まれた
原因は「部分一致の置換」です。例えば「東京」を「東京本社」に置換したら、「東京都」も「東京本社都」になってしまう、などです。
対策
・部分一致ではなく完全一致を基本にする
・部分一致を使う場合は、対象のパターンを明確に限定する
・置換後のサンプルを必ず確認する
事故2:置換した結果、同名衝突が起きた
「(株)A」と「株式会社A」を統一して「A」にしたら、別の「A」が存在していて混ざった、などです。
対策
・統一後の名称にコードを併記する
・名称を変える前にユニーク性を確認する
・同名になって困るなら、置換ではなく表示用の別列で対応する
事故3:置換が増えすぎて更新が遅い
置換そのものが重いというより、置換をステップとして大量に積むと、Power Query の処理が長くなりやすいです。
対策
・置換をまとめる(同じ列への連続置換を減らす)
・辞書テーブルでマージして一回で決める
・処理の早い段階で列削減・行削減をする
事故4:置換の影響範囲が分からなくなった
「どこで直しているのか」が不明になると、追加要望や不具合対応が遅れます。
対策
・置換はなるべく辞書化する
・変換ステップ名を分かりやすくする
・置換の意図を備考に残す
置換が必要か迷ったときの判断基準
最後に、置換するか迷ったときの判断軸をまとめます。
・それは表記ゆれか、それとも別概念か
別概念なら統一しない方が安全です。
・置換はデータ品質の問題を隠していないか
本来は入力ルールやマスタの整備で直すべき問題を、置換で誤魔化していないか確認します。
・置換後の値は業務で合意できるか
「誰が見ても同じ意味になるか」が大事です。
・置換ルールは今後増えるか
増えるなら辞書テーブル運用に寄せます。
・置換はどこでやるべきか
データ正規化なら Power Query、分類列なら計算列、見せ方ならメジャー、が基本です。
まとめ
power bi 置換は、レポートの正しさと使いやすさを支える重要な作業です。表記ゆれや不要文字を放置すると集計が割れ、フィルターが効かず、利用者の信頼が落ちます。一方で、置換を雑に積むと、巻き込み事故や保守不能に陥ります。
置換の基本は、Power Query で正規化し、ルールが増えるなら辞書テーブルで管理し、表示の言い換えはメジャーで対応することです。元の列を残し、置換ルールを見える形にしておけば、置換は「場当たりの修正」ではなく、「データ品質を守る仕組み」になります。
コメント