Power BIで「同じレポートを配りたいけれど、部署や担当者ごとに“見えてよいデータだけ”を出したい」という場面はよくあります。そんなときの基本解がRLS（行レベルセキュリティ）です。この記事では、power bi rls 設定の手順をただ並べるだけでなく、漏れにくく・運用しやすく・遅くなりにくい設計の考え方から、具体的なDAX例、つまずきポイントの回避までを一気通貫で解説します。
RLSでできること・できないこと
RLSが得意なのは「閲覧者に応じて行（レコード）を絞り込む」ことです。たとえば、営業Aには自分の顧客だけ、関東支社には関東の売上だけ、取引先ごとに自社データを分離して提供したい、などに向きます。
一方で、RLSは万能ではありません。列そのものを隠したい、テーブルごと見せたくない、といった要件には別の仕組み（列/オブジェクト単位の制御や、そもそものモデル分割）が必要になります。また、RLSは「Power BIのデータセット上での閲覧制御」なので、元データソースに直接アクセスできる人まで守る仕組みではありません。まずは「どこを守りたいか（レポートの閲覧なのか、データソースそのものなのか）」を切り分けましょう。
設計編：最初に決める3つのこと
-
セキュリティの軸を決める
RLSは「何で絞るか」が肝です。代表例は以下です。
・担当者ID（SalesRepID）
・部署コード（DeptCode）
・支社/地域（Region）
・顧客ID（CustomerID）
・テナントID（TenantID：外部向け提供で多い）
軸はできるだけ安定したキー（ID）で持つのが原則です。名称やメールアドレスの表記揺れは運用で必ず事故ります。名称は表示用、IDは制御用、と役割を分けます。
-
静的RLSか、動的RLSかを決める
・静的RLS：役割（ロール）ごとに固定の条件を書く（例：関東ロールはRegion=”Kanto”）
・動的RLS：ログインユーザーに応じて条件を変える（例：UserEmail=USERPRINCIPALNAME()で自分の許可行だけ）
実運用で増減が多いのは動的RLSです。静的RLSは「組織単位で少数の区分」なら管理が楽ですが、人の異動や兼務が多い場合はロール爆発しやすいので注意してください。
-
“権限表（セキュリティテーブル）”をモデルに持つ
おすすめは、許可情報を1つのテーブルに集約する設計です。例：
Security
・UserEmail（ユーザー識別子）
・RegionID（許可される地域）
（担当者軸ならSalesRepID、顧客軸ならCustomerID）
このSecurityテーブルをディメンション側（Region、SalesRep、Customerなど）につなぎ、そこからファクト（売上など）へフィルターが伝播する形にします。RLSをファクトにベタ書きするより、漏れにくく保守しやすく、パフォーマンスも出やすいです。
設定編：Power BI DesktopでのRLS作成手順
ここからは、power bi rls 設定の王道フローを、実際に手を動かす順で説明します。
-
モデルにSecurityテーブルを用意する
・社内のマスタ（Excel/SharePoint/DB）から取り込む
・最低限「ユーザー識別子」と「許可キー」を持たせる
・複数許可（1人が複数地域など）は行を増やして表現する（UserEmail×RegionIDの組み合わせで複数行） -
リレーションシップを張る
例：Security[RegionID] → Region[RegionID]（多対一）
Region → Sales（RegionIDで多対一）
この“一本道”ができると、Securityで絞った結果がRegionに伝わり、さらにSales（売上）に伝わります。 -
役割（ロール）を作成する
モデリング（または「管理」）メニューから「役割の管理」を開き、ロール名を付けます。
動的RLSの場合、フィルターをSecurityテーブルに設定するのが定石です。 -
DAXフィルターを書く（動的RLSの基本形）
Securityテーブルに以下の条件を入れます。
Security[UserEmail] = USERPRINCIPALNAME()
これだけで「ログインユーザーのUPNと一致する行だけが残る」→「その行に紐づくRegionIDだけが許可」→「売上が絞られる」という流れになります。
表記揺れ対策として、両側を小文字化するのも有効です。
LOWER(Security[UserEmail]) = LOWER(USERPRINCIPALNAME())
-
Desktopでテストする（表示方法に注意）
「ロールとして表示（View as）」を使い、
・ロールを選択
・「他のユーザー」を指定（USERPRINCIPALNAMEの代替）
で確認します。
「自分のアカウントで正しく絞れる」だけでなく、「別ユーザーを仮定しても意図どおりか」を必ず見ます。
公開後の設定編：Power BI Serviceでの割当（ここが抜けがち）
Desktopで作っただけでは終わりません。公開後に“誰にRLSを適用するか”をサービス側で割り当てる必要があります。
-
データセット（セマンティックモデル）のセキュリティを開く
対象のデータセットを選び、セキュリティ設定を開きます。 -
ロールにユーザー/グループを追加する
ここが最重要ポイントです。ロールに割り当てられていないユーザーがデータセット/レポートにアクセスできる状態だと、RLSが適用されずに（権限の範囲で）全データが見えてしまうことがあります。
個人を直接追加するより、Azure ADのグループ（部署やプロジェクト）をロールに入れる運用が現実的です。異動や入退社のたびにPower BI側を触らずに済みます。
動的RLSでも「閲覧対象者（またはグループ）をロールに入れる」ことは必須だ、と覚えておくと事故が減ります。 -
検証は“閲覧者権限”のアカウントで行う
管理系の権限を持つユーザーだと、RLSの検証にならない（想定どおりに制限されない/挙動が違う）ことがあります。検証用の閲覧アカウントを用意し、そこで見え方を確認するのが安全です。
実装パターン集：現場で多い設計とDAX
パターンA：地域/部署で絞る（最も安定）
Security（UserEmail, RegionID）→ Region → Fact
ロール条件：Security[UserEmail] = USERPRINCIPALNAME()
特徴：許可単位が明確で、集計の整合が取りやすい。推奨度が高い。
パターンB：担当者で絞る（担当替えが多い場合は注意）
Security（UserEmail, SalesRepID）→ SalesRep → Fact
担当替えが頻繁なら、権限表の更新フロー（誰が、いつ、何を根拠に更新するか）を業務に組み込みます。
パターンC：顧客ごとに見せる（外部共有で多い）
Security（UserEmail, CustomerID）→ Customer → Fact
顧客数が多い場合、権限表の行数が膨らみます。更新頻度と性能を見ながら、顧客グループ単位にする、上位キー（TenantIDなど）でまとめる、といった設計も検討します。
パターンD：複雑な許可条件（複数軸・例外あり）
「基本は部署、ただしこの人だけ例外で別部署も見える」のようなケースは、例外をDAXに埋め込むより、権限表に例外行を足す方が長期的に安全です。ルールが見える化され、監査もしやすくなります。
運用編：安全に回すためのチェックリスト
権限は“作って終わり”ではなく、運用で壊れます。最低限、次を仕組みにしてください。
・権限表の更新責任者を決める（情シス、管理部門、各部門など）
・UserEmail（UPN）の形式を統一する（大文字小文字、別名、旧姓など）
・権限表のキーは必ず一意に管理する（同じUserEmailに同じRegionIDが重複しない）
・権限表はレポート上で非表示にする（閲覧者に割当情報を見せない）
・毎月/四半期に“棚卸し”する（退職者・異動者・一時付与の解除）
・テスト用アカウントを用意し、想定パターンを定期検証する
よくある失敗と対処法
失敗1：Desktopでは絞れているのに、サービスで全件見える
原因の多くは「サービス側でロールへの割当がされていない」ことです。公開後は必ずデータセットのセキュリティで、対象ユーザー（またはグループ）をロールに入れてください。検証は閲覧者権限のアカウントで行うのが安全です。
失敗2：USERNAME()を使って一致しない
DesktopとServiceで返る形式が変わることがあります。ユーザー識別にはUSERPRINCIPALNAME()を基準にし、権限表のUserEmailと揃えるのが無難です。
失敗3：権限表はあるのに、フィルターが伝わらない
多くはリレーションの向き・非アクティブ・キー不一致です。
・Securityからディメンションへ正しくつながっているか
・ディメンションからファクトへつながっているか
・キーのデータ型が一致しているか（文字列/数値混在は要注意）
を順に確認します。最短で効くのは「Security→ディメンション→ファクト」の一本道を作ることです。
失敗4：LOOKUPVALUEでエラー（複数値が返る）または遅い
権限表に重複があるとLOOKUPVALUEが複数行にヒットして失敗します。また、ファクトに直接LOOKUPVALUEで条件を書くと、行数が多いほど遅くなりがちです。
対策は、権限表を正規化（重複排除）し、できるだけ“関係で絞る”設計に寄せることです。
失敗5：計算テーブル/集計テーブルで情報が漏れる
計算テーブルは更新時に作られるため、意図せず「全体の集計結果」を持つテーブルができることがあります。RLSのフィルターが届かない独立テーブルに全体集計を置くと、閲覧者が全体像を推測できてしまいます。
集計は可能な限り通常のディメンション/ファクト上のメジャーで行い、どうしてもテーブル化するなら、RLSが伝播する関係（または同じ絞り軸）を確実に持たせます。
失敗6：双方向フィルターで想定外の絞り込み・表示崩れ
クロスフィルター方向を「両方向」にすると、意図しない経路でフィルターが回り、結果が変わることがあります。RLSと組み合わさると原因特定が難しくなるため、基本は単方向で設計し、必要な場合だけ最小限に両方向を使う方針が安全です。
失敗7：同じ人が複数部署/複数担当を持つと管理が破綻する
「1人1部署」の前提で作ると、兼務が来た瞬間に崩れます。最初から“1人に複数行を許す”権限表で設計し、例外は行追加で表現できるようにしておくと、後から強いです。
性能編：遅くしないためのコツ
・RLSの条件は、なるべく小さいテーブル（Security）に置く
・ファクトに複雑な条件を直書きしない（関係で伝播させる）
・権限表の行数を必要以上に増やさない（顧客単位の付与は要注意）
・キー列は辞書化が効く形（整数IDなど）を優先する
・文字列比較が多い場合は、表記統一や小文字化列の用意を検討する
よくある質問
Q：RLSを入れると、エクスポートで全件抜かれませんか？
A：基本的には、閲覧者が見えている範囲のデータだけが対象になります。ただし「誰にどの権限を与えるか（ワークスペースのロール、データセットの権限、共有方法）」次第で体感が変わるため、権限設計とセットで確認してください。
Q：レポートごとにRLSを変えられますか？
A：RLSはデータセット側の設定です。同じデータセットを使う複数レポートで共通に効きます。レポートごとに制御を変えたい場合は、データセットを分ける、モデルを分割するなど、設計から見直すのが基本です。
まとめ
RLSの成功は、DAXの小技よりも「権限表を中心にしたモデル設計」と「サービス側の割当・運用フロー」にかかっています。まずはSecurityテーブル＋USERPRINCIPALNAME()の動的RLSを基準に、ディメンション経由でファクトへフィルターを流す形を作りましょう。そこまでできれば、部署・地域・顧客などほとんどの要件は安全に捌けます。最後に、公開後の割当と検証（閲覧者権限での確認）だけは忘れずに。
こんな課題がある場合はご相談を
- 「セマンティックモデルは聞いたことがあるけど、具体的にどう始めればいいかわからない」
- 「既存のデータ構造が複雑すぎて、うまくモデル化できない」
- 「DAX の高度な使い方がわからない」
こういったお悩みをお持ちの方も多いのではないでしょうか。
Power BI の導入・活用でお困りの際は、ぜひ無料相談をご利用ください。
もし困り事があるなら、まずは無料相談はこちら
コンサルサービスの詳細や成功事例なども合わせてご紹介いたします。
社内にデータ活用のノウハウや専門人材が十分いない場合でも、弊社が伴走しながら最短ルートで成果を出せるようサポートいたします。
セマンティックモデルを活かすためのスキルアップ
📊 Power BIでより効率的なレポート作成を！
DAX 関数をマスターして、実務で使えるスキルを身につけませんか？
Power BIハンズオンセミナー中級編では、短時間でデータモデリングのノウハウを学び、ビジネスに活かせるレポート作成を実践形式で習得できます。
- 少人数制のため、定員になり次第締切！
👉 セミナー詳細を今すぐチェック
📈 Power BIスキルを次のレベルへ！
DAX関数 × データモデル設計 で、複雑なデータ分析やレポート作成もスムーズに！
Power BIハンズオンセミナー中級編 なら、実践形式で学べるから即戦力に。
業務効率をアップし、社内での評価を高めるチャンス！
- 今こそスキルアップのタイミング！
👉 詳細はこちら
セマンティックモデルを最大限に活用するためには、DAX やデータモデル設計の知識が欠かせません。レポートの正確性やパフォーマンスを大幅に改善できるため、学んでおいて損はない分野です。
コメント