Power BIで動的RLS（ユーザー別フィルター）を作る方法：部署別・担当者別の見せ分け実践

Power BIで「同じレポートなのに、見る人によって表示されるデータが違う」状態を作りたい場面は多いです。たとえば営業部は営業部の数字だけ、東日本支社は東日本だけ、担当者は自分の顧客だけ、マネージャーは配下メンバー分まで――こうした見せ分けを、レポートを複製せずに実現できるのがRLS（行レベルセキュリティ）です。

中でも“動的RLS”は、ユーザーごとにフィルター条件を変えられます。つまり「ログインした人が誰か」をキーにして、部署別・担当者別のフィルターを自動適用できます。いわゆる power bi rls dynamic の代表的な実装パターンです。

この記事では、動的RLSを実務で使える形に落とし込むために、最短の作り方から、兼務・複数部署・管理職の配下閲覧まで、つまずきポイント込みで解説します。

動的RLSの基本は「ユーザー ↔ アクセス権」の対応表

動的RLSの考え方はシンプルです。

1. 「このユーザーは、どの部署（または誰の担当データ）を見てよいか」を表す対応表を用意する

2. ログインユーザーを取得する関数で、対応表を絞り込む

3. その絞り込みが、部署テーブルや担当者テーブルを経由して、売上などの事実テーブルに伝播するようにモデルを組む

重要なのは、RLSは“データモデルのフィルター伝播”で効かせるのが一番安定する、という点です。DAXで無理やり複雑な条件を書けなくはありませんが、まずは「関係（リレーションシップ）で自然に絞れる形」を作るのが実務では強いです。

事前に決めておくと迷わない2つのこと

動的RLSは、作り始める前にここだけ決めると失敗が減ります。

ユーザーを識別する文字列を何にするか

Power BIでログインユーザーを取得する代表関数は次の2つです。

• USERPRINCIPALNAME()：多くの環境で「メールアドレス形式のUPN」が返る（推奨寄り）

• USERNAME()：環境によって「domain\user」形式になったり、挙動差が出やすい

現場での運用を考えると、対応表（アクセス権表）には「UPN（メールアドレス形式）」を入れて、RLS条件は USERPRINCIPALNAME() を使う形が扱いやすいことが多いです。大小文字の違いが混ざることもあるので、正規化（小文字化）も最初から入れておくと安定します。

“部署”で見せるのか、“担当者（社員）”で見せるのか

よくある見せ分けは以下です。

• 部署別：部署キーで絞る（例：DepartmentID）

• 担当者別：社員キーで絞る（例：EmployeeID、SalespersonID）

• 両方：部署でも担当者でも絞りたい（例：部長は部署、担当は自分）

この違いで、アクセス権表に入れるキーが変わります。まずはどちらを主軸にするか決めると、モデル設計がスムーズです。

最短で作る「部署別」動的RLS（おすすめの基本形）

ここでは、典型的な星型モデルを例にします。

• 事実テーブル：Sales（売上明細）

• ディメンション：Department（部署マスタ）

• アクセス権表：UserDept（ユーザーと部署の対応）

1) アクセス権表（UserDept）を作る

最低限、次の列を用意します。

• UserDept[UPN]：ユーザー（例：tanaka@company.com）

• UserDept[DepartmentID]：部署キー（例：D001）

兼務で複数部署を見られる人がいる場合は、同じUPNで行を複数作るだけでOKです。

例：

• tanaka@company.com / D001

• tanaka@company.com / D003

2) リレーションシップを張る（ここが肝）

• UserDept[DepartmentID] → Department[DepartmentID]（多対1、単方向）

• Department[DepartmentID] → Sales[DepartmentID]（1対多、単方向）

この2本がつながることで、UserDeptが絞られると、Departmentが絞られ、Salesが絞られます。

ポイントは「UserDept → Department → Sales」とフィルターが流れる向きになっていることです。ここが逆だったり、関係が曖昧（多対多のまま放置）だと、期待通りに絞れません。

3) ロールを作って、UserDeptにフィルターを設定する

Power BI Desktopの「ロールの管理」でロール（例：RLS_Dynamic）を作り、UserDept テーブルに次のフィルターを設定します。

これだけで、ログインユーザーのUPNに一致する行だけが残り、その部署だけが見えるようになります。

4) Desktopでテストする

「表示 > ロールとして表示」で、作ったロールを選び、「他のユーザー」としてUPNを入力して確認します。

• 自分の部署だけに絞れているか

• 兼務ユーザーは複数部署が見えるか

• 部署が見えないユーザー（対応表にいない）では何も表示されないか

このテストで「部署テーブルは絞れているのに売上が絞れない」場合は、関係の向きやキーの一致、Sales側のDepartmentID欠損などを疑います。

「担当者別」動的RLS（自分の顧客・自分の売上だけ見せる）

担当者別は、部署別と同じ形を“社員（担当者）ディメンション”で作ります。

• 事実テーブル：Sales

• ディメンション：Employee（社員/担当者）

• アクセス権表：UserEmp（ユーザーと社員の対応）

1) UserEmpを作る

• UserEmp[UPN]

• UserEmp[EmployeeID]

「ログインユーザー＝社員本人」の前提なら、UPNとEmployeeIDを1対1で持たせればOKです。派遣・兼務・代理対応などがあるなら、1人のUPNに複数EmployeeIDを付ける設計もできます。

2) 関係を張る

• UserEmp[EmployeeID] → Employee[EmployeeID]

• Employee[EmployeeID] → Sales[EmployeeID]

3) ロールのフィルター

部署別と同じで、アクセス権表を“ユーザーで絞る”だけです。フィルターの伝播に任せると、DAXがシンプルになり、運用も楽になります。

部署別と担当者別を“同じレポートで”併用する考え方

実務では「一般社員は自分の担当だけ、部長は部署全体、経営層は全社」といった混在が普通です。ここで無理に1つのアクセス権表で全部を表現しようとすると、判断が複雑になりがちです。おすすめは次のどちらかです。

パターンA：ロールを分ける（シンプルで分かりやすい）

• Role_Employee：UserEmpを使って担当者で絞る

• Role_Department：UserDeptを使って部署で絞る

• Role_All：絞りなし（管理者・経営層など）

メリットは、意図が明確で事故が減ることです。ユーザー割り当て（どのロールに誰を入れるか）を管理者側で丁寧に運用できるなら、この方式は堅いです。

パターンB：1ロールで「権限レベル」列を持たせる（運用人数が多いときに有効）

アクセス権表に、権限タイプを持たせます。

例：UserAccess

• UPN

• AccessType（”Employee” / “Department” / “All”）

• DepartmentID（部署権限用）

• EmployeeID（担当者権限用）

ただしこの方式は、モデル設計と条件分岐が増えて難度が上がります。最初はパターンAで始め、必要になったらパターンBに拡張するほうが安全です。

兼務・複数部署・複数担当を自然に扱う方法

動的RLSの強みは「対応表に行を足すだけで拡張できる」ことです。

• 兼務で複数部署：同一UPNに対してDepartmentIDの行を増やす

• 複数担当者を代理閲覧：同一UPNに対してEmployeeIDの行を増やす

• プロジェクト別：ProjectIDで同じ設計を作る

ここでのコツは、キーは“数値や短いコード（ID）”を使うことです。部署名や担当者名で結ぶと、表記ゆれや改名で壊れます。必ずIDを持たせ、名前はディメンション側で表示用に使います。

管理職が「配下メンバー」を見られる階層RLSの実装イメージ

「上司は部下の売上も見たい」は超定番です。部署で見せられるなら部署RLSで済みますが、部署横断の兼務や、個別の配下構造で見せたい場合は階層RLSが役立ちます。

考え方は2通りあります。

方式1：事前に“上司が見られる社員一覧”を作っておく（おすすめ）

データベースやETL側で、次のような表を作ります。

• ManagerEmp：ManagerUPN / EmployeeID

上司UPNごとに、閲覧可能なEmployeeIDを全て列挙してしまう方式です。Power BI側は担当者別と同じ実装で済み、パフォーマンスも安定します。組織変更が多い場合でも、元データを更新すれば追従できます。

方式2：Power BI側で階層を辿る（小規模なら可能）

社員テーブルに、EmployeeIDとManagerEmployeeIDを持たせ、DAXで階層判定をします。ただし、モデルが大きいと重くなりやすく、実務では方式1のほうが運用しやすいことが多いです。

Power BI Serviceに公開した後に必ずやること（割り当ての落とし穴）

動的RLSは「ロールを作っただけ」では効きません。公開後、データセットのセキュリティ設定で、ユーザー（またはグループ）をロールに割り当てる必要があります。

実務でおすすめの運用はこれです。

• 個人ユーザーを1人ずつ割り当てない

• 部署や利用者のEntra IDグループ（旧Azure ADグループ）をロールに割り当てる

• ユーザーの見える範囲は“アクセス権表”でコントロールする

つまり「このレポートを見る権利がある人たち」をロールに入れ、個別の見える範囲はUserDept/UserEmpで絞る、という二段構えにします。人数が増えても破綻しにくいです。

つまずきやすい注意点（ここでハマる人が多い）

UPNの一致問題（これが一番多い）

• 対応表のUPNが「メール」なのに、実際のログインは別表記

• 大文字小文字が混ざる

• サブドメイン違い、旧メールアドレスが残っている

対策：

• LOWER() で比較する

• 対応表のUPNは、実在するログインUPNと同じ形式に統一する

• 最初に少人数で検証し、表記揺れのパターンを潰す

関係（リレーションシップ）の向きが原因で絞れない

• UserDeptが絞れているのにSalesが絞れない

• 部署テーブルを介していない列で集計している

対策：

• 「UserAccess → ディメンション → 事実」の伝播を意識する

• なるべく星型（ディメンションが事実を絞る形）に寄せる

• 多対多は最後の手段。どうしても必要なら橋渡しテーブルで制御する

双方向フィルターを多用すると、意図しない“見え方”になりやすい

双方向は便利ですが、RLSでは「どこからどこへフィルターが流れるか」が複雑になり、想定外の結果になりやすいです。

対策：

• 基本は単方向で組む

• どうしても必要な箇所だけに限定する

• モデルが複雑なら、まずは橋渡しテーブルで単方向の鎖を作る

「pbixを配布すると中身のデータが見える」問題

RLSはPower BI Service上での閲覧を守る仕組みです。Importで取り込んだデータが入ったpbixを配布すると、受け取った側がローカルでデータを見られる可能性があります。

対策：

• pbix配布を前提にしない（配布はサービスのアプリや共有で）

• どうしても必要なら、権限やデータ持ち出しルールを別途徹底する

DirectQuery/複合モデルではパフォーマンスに注意

動的RLS自体は動きますが、フィルター条件がソース側に押し込まれるため、ソースの設計（インデックス、結合キー、ビュー設計）が弱いと遅くなりがちです。

対策：

• キー列で結ぶ（文字列結合を避ける）

• アクセス権表を小さく保つ

• 可能なら集計テーブルや適切なモデリングで負荷を下げる

運用を回すコツ：RLSは「作る」より「保つ」が難しい

動的RLSが現場で続かない原因の多くは、対応表のメンテが追いつかないことです。退職・異動・兼務・組織改編が起きた瞬間に、見えるべき人が見えない／見えてはいけない人が見える、が発生します。

実務で効く運用は次です。

• 対応表は“手入力”ではなく、できるだけ人事・組織マスタから自動連携する

• 例外（代理閲覧・短期プロジェクト）は、期限列を持たせて棚卸ししやすくする

• 月次で「対応表にいないのに閲覧が必要な人」「対応表に残った退職者」をチェックする

• ロール割り当てはグループ運用に寄せ、個人割り当てを増やさない

RLSはセキュリティ機能ですが、現場から見ると“業務が止まる要因”にもなり得ます。だからこそ、更新フローを最初に作っておくのが成功の分かれ目です。

まとめ：動的RLSを成功させる最短ルート

動的RLSは、難しいDAXを頑張るより先に、次の順で整えるのが一番早く、事故が少ないです。

• アクセス権表（UPNと部署ID/社員ID）を用意する

• 「UserAccess → ディメンション → 事実」の単方向の鎖でフィルターが流れるモデルにする

• ロールではアクセス権表だけを USERPRINCIPALNAME() で絞る（条件をシンプルに）

• Service公開後、ロール割り当てはグループで運用する

• 異動・退職・例外対応を回す“更新の仕組み”を作る

この形に乗せれば、部署別・担当者別の見せ分けはもちろん、兼務や代理閲覧、管理職の配下閲覧まで、段階的に拡張できます。最初は部署別か担当者別のどちらかで小さく作って、モデルと運用が固まってから範囲を広げると、現場でも使い続けられる動的RLSになります。