Power BIでスライサーの選択に応じて数値や表示を切り替えたいとき、DAXのSELECTEDVALUEはほぼ必修です。ところが実務では「なぜか空白になる」「想定外の分岐に入る」「ユーザーが複数選択した瞬間に壊れる」といった不安定さが出やすいのも事実です。ここでは power bi selectedvalue を使うときに、スライサー連動と条件分岐を安定させるための定石を、よくある失敗パターンから逆算して整理します。
SELECTEDVALUEが活躍する場面
SELECTEDVALUEが本領を発揮するのは、レポート上の「選択」をDAXの分岐に持ち込みたい場面です。代表例は次の通りです。
-
スライサーで「年度」「地域」「部門」などを選び、その選択に合わせて指標の計算式を切り替える
-
「売上」「利益」「前年差」などをユーザーが選んで、同じカードやグラフで表示指標を切り替える
-
動的タイトル（今どの条件で見ているか）や注意文（複数選択時は集計方法が変わる等）を表示する
-
パラメータテーブル（切断テーブル）と組み合わせて、メジャーのスイッチングを行う
この「ユーザーの操作＝フィルターの状態」を、DAX内で安全に受け取るのがSELECTEDVALUEの役目です。
基本形と戻り値のルール
SELECTEDVALUEはとてもシンプルなルールで動きます。
-
列に対して、選択された値が1つだけなら、その値を返す
-
1つに定まらない（未選択、複数選択、全選択で結果的に複数など）場合は、空白（BLANK）を返す
-
第2引数（代替値）を指定していれば、1つに定まらないときはその代替値を返す
基本形はこれです。
代替値つきはこれです。
実務で安定させる鍵は、ほぼ100%「第2引数（代替値）を設計すること」と「複数選択時の方針を決めること」に集約されます。
スライサー連動が不安定になる典型パターン
SELECTEDVALUEが原因で壊れて見える現象は、多くが次のどれかです。
(1) ユーザーが複数選択している
スライサーで複数選択が許可されていると、選択が2つ以上になった瞬間にSELECTEDVALUEは空白を返します。すると、IFやSWITCHの比較が成立せず、意図しない分岐（最後のELSE）に流れたり、計算結果が空白のままになります。
(2) 未選択（＝実質的に全件）になっている
スライサーで何も選んでいない状態は、見た目には「全体」を意味することが多いです。しかしSELECTEDVALUEから見ると「値が1つに定まらない」ので空白になりやすい。ここがユーザー感覚とDAXのズレの代表例です。
(3) 他のビジュアルやページフィルターの影響で、結果的に複数になっている
ユーザーはスライサーを1つ選んだつもりでも、別のフィルターがかかっていて列の候補が複数残るケースがあります。たとえば「年」は1つでも「年度表示用の列」が別テーブルにあり、関連の関係で複数に見えてしまう、といった状況です。
この3つを潰すのが「定石」です。
定石1：代替値（第2引数）を最初に決める
最初にやるべきは「1つに定まらないときはどう扱うか」を明文化して、第2引数に埋め込むことです。
よくある代替値の設計は次の3種類です。
A. 「全体」を意味するデフォルトにする
ユーザーが未選択でも“全体”として見せたい場合。
B. 「未選択」や「複数選択」の注意表示に使う
値の切り替えではなく、メッセージ表示に使う場合。
C. 「安全側の既定値（最も一般的な指標）」に倒す
メジャー切替で、未選択なら売上にしておく、など。
ここで重要なのは、代替値は「空白よりマシ」ではなく、「仕様として正しい状態」を返すことです。代替値が曖昧だと、安定はしても意図しない表示になります。
定石2：条件分岐はSWITCH(TRUE())で読みやすく、安全にする
SELECTEDVALUEを使った分岐は、IFをネストするよりSWITCH(TRUE())の形にすると事故が減ります。理由は、分岐条件の追加・変更がしやすく、最後の既定動作を明確に置けるからです。
指標切替の定番パターン（切断テーブルを使う）を例にします。
前提：切断テーブル（モデル上で他テーブルと関連を持たないテーブル）を用意し、列[項目]に「売上」「利益」「数量」を入れてスライサーに置く。
ポイントは2つです。
-
metricは必ず既定値つきで受ける（空白にしない）
-
最後に既定の戻り値（ここでは[売上]）を置く
これで「複数選択や未選択で空白→分岐不能」という事態をかなり防げます。
定石3：複数選択を許すか禁止するかを先に決める
安定させる最短ルートは、そもそもスライサーを単一選択にすることです。Power BIのスライサーには単一選択設定があります。指標切替やモード切替のように「1つに決めてほしい」用途では、単一選択を基本にするのが定石です。
ただし、業務要件で複数選択が必要なスライサーもあります（複数部門を選ぶ、複数商品カテゴリを選ぶ等）。その場合、SELECTEDVALUEで「1つだけ」を取り出す設計自体が相性悪くなります。対策は次のどれかです。
A. 複数選択時は特別扱いにする（注意表示や計算方法を固定）
B. そもそも単一値に頼らず、VALUESやINで集合として扱う
（例：特定部門が含まれるか、など）
C. 複数選択の内容を文字列として表示する（デバッグや注釈に便利）
複数選択を許す用途で、無理にSELECTEDVALUEだけで完結させようとすると不安定になります。「単一値が必要な場面」と「集合が必要な場面」を分けるのが定石です。
定石4：スライサー連動を安定させるなら切断テーブル（パラメータテーブル）を使う
スライサーで「計算ロジックを切り替える」場合、実データの列をそのまま使うより、切断テーブルを使う方が安定します。
理由は単純で、実データの列には他のフィルターやリレーションの影響が混ざりやすく、想定外に複数値になりやすいからです。切断テーブルは、選択のためだけに存在し、モデルの他の状態に引きずられにくい。
例えば「表示単位」を切り替える例です。「円」「千円」「百万円」をスライサーで選びます。
ここでも、既定値を「円」にしておくことで、未選択でも破綻しません。
定石5：動的タイトルと注釈で「ユーザーに状態を返す」
SELECTEDVALUEは計算だけでなく、「今どういう条件で見ているか」を返すのに強いです。これをタイトルやサブタイトルに入れると、レポートの誤読が減ります。
例：地域と年度をタイトルに出す。
注意点として、年度の列は日付テーブルの年度列など、評価が安定する列を使うのが無難です。別テーブルの表示用列を使うと、関係やフィルターで「1つに定まらない」が発生しやすくなります。
定石6：空白（BLANK）をそのまま返さない
SELECTEDVALUEの空白は、見た目の問題を起こしやすいです。カードが空白になって「壊れた」と思われたり、条件分岐が落ちたりします。そこで、空白を返さない工夫を入れます。
-
第2引数で代替値を返す（最優先）
-
COALESCEで最後に拾う（保険）
COALESCEは「左から順に空白でない最初の値」を返すので、最終防波堤として便利です。
SELECTEDVALUEとVALUES/HASONEVALUEの使い分け
実務で混乱しやすいポイントなので、基準だけ押さえます。
-
SELECTEDVALUE：単一値を取りたい。単一でないときの既定動作を定義したい
-
HASONEVALUE：単一かどうかの判定がしたい（単一でなければ別処理へ）
-
VALUES：現在のフィルター文脈での値の集合が欲しい（複数もあり得る）
よく言われる定番として、SELECTEDVALUEは概念的に次と近い動きです。
単一なら値、そうでなければ代替値。
この「単一前提で組む」ならSELECTEDVALUE、「複数の可能性を扱う」ならVALUES、という切り分けをすると安定します。
よくあるトラブルと対処
(1) 「スライサーは1つ選んでるのに空白になる」
原因候補
-
実は複数選択になっている（Ctrlクリック、チェックボックス型など）
-
別のフィルターで複数値が残っている
-
参照している列が適切でない（表示用列、別粒度の列、重複がある列）
対処
-
まずは選択内容を可視化するデバッグ用メジャーを作る
-
単一選択にするか、代替値を入れる
-
日付や地域などは、できるだけディメンション側のキーや一意列を参照する
デバッグ用メジャー例（複数も表示できる）：
(2) 「SWITCHで比較しているのに一致しない」
原因候補
-
列の値に余計なスペースがある
-
データ型が違う（数値と文字列の比較など）
-
表記揺れがある（全角半角、大文字小文字）
対処
-
切断テーブル側の値を固定（表記揺れをなくす）
-
比較対象の型を揃える
-
必要ならTRIMなどで整形する（ただし多用は避け、元データの品質で解決が基本）
(3) 「計算列でSELECTEDVALUEを使ったら意味が違う」
計算列は行ごとに評価されるため、メジャーとは感覚が違います。計算列でSELECTEDVALUEを使うと、その行の文脈では1つに定まってしまい、スライサー連動のような「レポート上の選択」を反映しません。スライサー連動をしたいなら、基本はメジャーで作ります。
実務での定番レシピ集
最後に、よく使う形をまとめます。
A. 指標切替（最重要）
B. 動的タイトル
C. 単一でないときは注意を出す
D. 複数選択の一覧表示（注釈・デバッグ）
まとめ：安定させるコツは「仕様を先に決めて式に埋める」
Power BIのSELECTEDVALUEは便利ですが、放っておくと空白に落ちる設計です。だからこそ、スライサー連動・条件分岐を安定させるには次が定石になります。
-
第2引数（代替値）を必ず設計する
-
単一選択が必要なスライサーは単一選択に寄せる
-
複数選択があり得るなら、単一値前提で組まない（VALUESや一覧表示を併用）
-
ロジック切替は切断テーブルで行い、他のフィルター影響を受けにくくする
-
動的タイトルや注釈で「今の状態」を返して誤読を防ぐ
この型に沿って作るだけで、「スライサーを触ったら壊れる」「条件分岐が不安定」という悩みの大半は解消できます。必要なのは難しいテクニックよりも、未選択・複数選択の扱いを最初に決めて、DAXに明示することです。
コメント