Power BIのOLS（オブジェクトレベルセキュリティ）とは？テーブル/列を見せない設計の基本

Power BIでレポートを全社に展開していくと、ある段階で必ず壁になります。「同じデータセットを使わせたい。でも、全員に全部の“項目”を見せたくない」。たとえば人事データの給与列、取引先の個人情報、原価や粗利、監査用のログ、社内だけの管理キーなどです。

このとき、RLS（行レベルセキュリティ）だけでは解決できません。RLSは“どの行を見せるか”の制御であって、“どのテーブル/列を見せるか”の制御は別問題だからです。そこで登場するのがOLS（オブジェクトレベルセキュリティ）です。power bi object level security を押さえると、同じデータセットを共有しながら、ユーザーの役割に応じて「見えてよいフィールドだけ」を出す設計ができるようになります。

この記事では、OLSの基本概念、RLSとの違い、テーブル/列を見せないための設計の考え方、実装の流れ、そして実務で事故が起きやすい注意点を、わかりやすくまとめます。

OLSでできることは「データ」ではなく「オブジェクト」を隠すこと

OLSは、Power BIのデータセット（セマンティックモデル）の中にある“オブジェクト”を、ロール（役割）ごとに見えなくする仕組みです。ここでいうオブジェクトは主に次のようなものです。

• テーブル（例：HR、原価、監査ログ）

• 列（例：給与、メールアドレス、住所、原価、利益）

• メジャー（例：粗利率、原価合計、利益）

• 階層や計算列など（モデル内の要素）

重要なのは、OLSは「その列を値として見せない」だけでなく、「列そのものを“存在しないように見せる”」方向の制御だという点です。単に“非表示（Hide）”にしただけだと、権限がある人は別ツールや作成機能でフィールドへ到達できることがあります。しかしOLSは、アクセスしたユーザーに対して“そのオブジェクトを参照する権利がない”状態を作ります。

だからこそ、次のような場面でOLSが効きます。

• 部署横断で同じデータセットを使わせたいが、経理だけが利益関連の列/メジャーを見られるようにしたい

• 顧客データは全社で使うが、個人情報列は特定部門だけに限定したい

• 自己分析（セルフサービス）を許可したいが、技術列や管理キー、監査テーブルは使わせたくない

OLSでできないことも押さえると設計が崩れない

OLSは万能ではありません。誤解しやすいポイントを先に整理します。

• OLSは“行”を絞りません（それはRLSの役割）

• OLSは“見えるメジャーが出す結果”までは自動で守りません
  たとえば給与列を見せなくしても、給与合計のメジャーを見せたら結果として給与情報に近いものを渡してしまうことがあります。守るべき情報は「列」だけでなく「結果（アウトプット）」も含まれる、という意識が必要です。

• OLSはレポートを魔法みたいに自動調整しません
  あるロールで列を見せない設定にした場合、その列を使ったビジュアルは壊れます。全員が同じレポートを見る運用だと、ロールごとに表示が崩れる可能性があります。

つまりOLSは「モデルの守り」を強化する仕組みで、レポート側の設計・分岐・テストとセットで初めて“実務で安全に回る”ようになります。

RLSとOLSの違いと、組み合わせの基本

よくある整理の仕方はこうです。

• RLS：誰が見てもよい“項目”は同じだが、見える“範囲（行）”が違う
  例：営業担当者は自分の顧客だけ

• OLS：見える“項目（テーブル/列/メジャー）”自体が違う
  例：経理だけが原価列を見られる

実務では、RLSとOLSは競合ではなく共存です。たとえば次のような組み合わせが王道です。

• 全社員：RLSで自部門の売上だけ見える、OLSで原価/利益系は見えない

• 経理：RLSは全社、OLSで原価/利益系も見える

• 経営層：RLSは全社、OLSもすべて見える

このとき注意したいのが「ロールの設計」です。Power BIのロールは“ユーザーがどのロールに属するか”で効き方が変わります。運用を楽にするなら、ロール数は増やしすぎず、Entra IDのグループ単位で割り当てるのが現実的です。

テーブル/列を見せない設計の基本は「守る対象の棚卸し」から

OLSを入れる前に、まず“何を隠すべきか”を分類します。ここが曖昧だと、現場が混乱し、過剰制限でレポートが壊れるか、逆に守りきれません。

棚卸しの観点は次の4つが実務向きです。

1. 個人情報・機微情報
   氏名、住所、電話、メール、社員番号、口座、健康情報など

2. 金額の中でも出すと問題になるもの
   原価、粗利、利益、単価、仕入れ、契約条件、与信など

3. 技術・運用上の都合で見せたくないもの
   サロゲートキー、内部ID、結合用のキー、監査ログ、ETL中間テーブル

4. “見せてよいが、作成を暴走させる”もの
   明細粒度の巨大テーブルや、誤解を生む列（未確定値、テスト列など）

この棚卸し結果を「全社で見せる」「特定部門だけ」「誰にも見せない（モデル内部用）」の3段階くらいに落とすと、ロール設計が一気に楽になります。

OLSを使うか、データセットを分けるかの判断基準

設計として悩みやすいのが「同じデータセットでOLSを使う」か「そもそもデータセットを分ける」かです。目安はこう考えるとブレません。

OLSが向くケース

• 指標（メジャー）やディメンションは多くの人で共通

• 隠したいのは一部の列や一部のテーブル

• 1つの“公式モデル”を軸に全社展開したい

• セルフサービスを許可しつつ、危ない項目だけ塞ぎたい

データセット分割が向くケース

• 部門ごとに必要な項目が大きく違う

• ロールごとにレポート構造が根本的に違う（同一レポートを共有できない）

• “見せる/見せない”だけでなく、定義や粒度が異なる

• 強い秘匿が必要で、出せる指標もかなり限定したい

無理にOLSで全部を解決しようとすると、ロールが増えてテストが破綻しがちです。「隠すのが少し」ならOLS、「世界が違う」なら分割、が実務ではだいたい当たります。

実装の流れ：Power BIでOLSを設定する全体像

OLSは“レポートの設定”ではなく、“データセット（セマンティックモデル）の設定”です。イメージとしては次の順番で進めます。

1. まず通常どおりデータセットを作成し、必要なテーブル/リレーション/メジャーを整える

2. どのロールが何を見えるべきか決める（ロール設計）

3. 外部ツールやXMLA経由で、ロールごとにテーブル/列/メジャーの権限を設定する（ここがOLS）

4. Power BI Service側でロールにユーザー/グループを割り当てる

5. ロール別にレポートの壊れをチェックし、必要ならレポートを分ける・ビジュアルを作り替える

実務での重要ポイントは「Desktopで完結しないことが多い」点です。OLSはモデルの詳細権限なので、外部ツールでの編集が前提になりやすいです（環境やライセンス、管理設定により利用可否が変わるため、組織の設定状況に合わせた進め方が必要です）。

設定の考え方：ロールごとに“見せない”を決める順番

OLSの設計は、次の順番で決めると破綻しにくいです。

1) まず「全員に見せてよいテーブル」を確定する

ディメンション（部署、商品、カレンダーなど）は、多くの場合で全員共通になります。ここが揺れるとレポートの基本構造が崩れます。

2) 次に「隠すべき列」をテーブル単位で洗い出す

テーブルを丸ごと隠す前に、列だけ隠せば足りることが多いです。たとえば顧客テーブルで隠したいのは住所や電話だけで、地域や業種は見せてよい、というケースはよくあります。

3) 最後に「隠すべきテーブル」を決める

監査ログや中間テーブルなど、見せる意味がないものはテーブルごと隠すとモデルが整理されます。

4) “見せてよいメジャー”を最後に再点検する

ここが最重要です。列を隠しても、メジャーが結果を出してしまえば情報は漏れます。守りたい情報が「列」なのか「値」なのかを必ず確認します。

たとえば「原価列は見せないが、粗利率メジャーは見せる」は、業務要件としてOKな場合もあれば、NGな場合もあります。数値の公開範囲を決めるのは技術ではなく、ルールと合意です。

つまずきポイント：OLSを入れるとレポートが壊れる理由

OLS導入で一番多い現象はこれです。

• あるロールでは、特定のビジュアルがエラーになる

• フィールド一覧から列が消え、既存のビジュアルが参照できなくなる

• スライサーやフィルターが期待通り動かない

原因は単純で、そのロールでは“参照できない列”をレポートが使っているからです。対策の方向性は3つあります。

1. ロールごとにレポートを分ける
   もっとも確実で、運用も分かりやすい方法です。たとえば「全社員用レポート」と「経理用レポート」を分ける。

2. 共通レポートにするなら、参照列を共通部分だけに寄せる
   全員が見られる列だけでレイアウトを組み、秘匿列を使ったビジュアルは作らない。

3. モデル側で“公開用の列/テーブル”を別に用意する
   個人情報列を持つテーブルと、公開用の属性だけを持つテーブルを分け、レポートは公開用だけを見るようにする。

「同じレポートを全員に見せたい」気持ちは分かりますが、OLSは“見える項目が違う世界”を作る機能です。レポートの共通化は、できる範囲で割り切るのが成功のコツです。

セキュリティとしての注意点：複数ロール所属は“権限が広がる”方向に働きやすい

運用で意外と見落とされるのが、ユーザーが複数ロールに入ったときの扱いです。多くの設計で、ロールは「足し算」になりがちです。つまり、Aロールで見えるものとBロールで見えるものを両方持つユーザーは、結果としてより多くの項目が見えてしまうことがあります。

対策としては次が有効です。

• できるだけ「1ユーザー＝1ロール（または1系統）」にする

• グループ設計を見直し、兼務者の入れ方を明確にする

• どうしても複数所属が必要なら、想定どおりの見え方になっているか必ずテストする

「経理グループにも所属している営業」のような例外が、権限の穴になりやすいです。

OLSとエクスポート・作成権限の関係を整理する

実務で安全設計をするなら、「見る」と「作る」を分けて考える必要があります。

• レポートを見る権限（閲覧）

• データセットに接続して分析する権限（Build）

• データをエクスポートする権限

OLSは“モデル上のオブジェクト”へのアクセスを制御するため、Build権限があるユーザーがセルフサービスで分析する場合にこそ真価を発揮します。逆に言うと、Build権限の付け方が雑だと「本来は作らせたくないのに作れてしまう」状態になります。

運用の定石は次です。

• 一般閲覧者：レポートは見せるが、Buildは付けない（セルフサービスさせない）

• 分析者：Buildを付ける代わりに、OLSで危ない項目を塞ぐ

• 管理者・モデル管理者：Buildも広く、OLSも全開だが、人数を最小にする

「レポートを見る人は多い」「作る人は少ない」。この前提で権限設計をすると破綻しにくいです。

実務で効く設計パターン

パターン1：個人情報列だけをOLSで隠し、分析の自由度は維持する

顧客テーブルに「氏名・住所・電話」などの列がある場合、それらだけを特定ロールで見えなくします。地域や業種など分析に必要な属性は公開し、個人情報だけ塞ぐ。導入効果が分かりやすく、現場の抵抗も少ないパターンです。

パターン2：原価・利益の世界を“メジャーごと”分ける

原価列そのものを隠すのに加え、粗利・利益系メジャーもロールごとに見せ分けます。ここで大事なのは「原価列を隠したから安心」ではなく、「利益を推定できるメジャーが残っていないか」をチェックすることです。

パターン3：セルフサービス用に“公開ゾーン”を作り、内部テーブルはテーブルごと隠す

巨大な明細テーブルや中間テーブルをそのまま公開すると、誤った集計や重いレポートが乱立しがちです。公開用のディメンションと、必要最小限の事実（または集計テーブル）だけを見せ、内部用はOLSで隠します。結果として、ガバナンスと性能の両方が改善しやすいです。

パターン4：どうしても共通レポートにしたいなら、公開用テーブルに寄せる

OLSで列が消えるとビジュアルが壊れる問題を避けるため、共通レポートは公開用テーブルだけで完結させます。経理向けの深掘りは別レポートに切り出す。運用負荷は少し増えますが、トラブル対応は減ります。

運用の基本：OLSは「作った後の変更管理」が本番

OLSは一度作って終わりではありません。組織変更、データ項目追加、指標追加のたびに、ロール別に「見せる/見せない」の判断が発生します。運用で押さえると良いポイントは次です。

• 新しい列やメジャーを追加したら、必ず「どのロールで見えるべきか」を確認する
  追加した瞬間に全員に見えてしまう設計だと事故が起きます。

• 本番反映前に、ロール別テストを必ず行う
  「経理ロールで見える」「一般ロールで壊れていない」を最低限確認します。

• ロール割り当ては個人ではなくグループ中心にする
  人の増減に強くなり、棚卸しもしやすいです。

• 役割が違うユーザーに“両方のグループ”を付けない運用を決める
  複数ロール所属が権限拡大につながりやすいためです。

まとめ：OLSは“項目の公開範囲”を決めるための基礎体力

OLS（オブジェクトレベルセキュリティ）は、Power BIを全社展開するほど効いてくる「項目そのものを見せない」ための仕組みです。RLSが“どこまでのデータ（行）を見せるか”なら、OLSは“どのフィールド（テーブル/列/メジャー）を見せるか”を決める土台になります。

うまく設計するコツは、次の4点に集約されます。

• 隠す対象を棚卸しし、「全社OK」「限定公開」「非公開」を決める

• ロールを増やしすぎず、グループで運用できる形にする

• 列を隠して終わりにせず、メジャーの“結果”が漏えいにならないか点検する

• OLSで列が消えるとレポートが壊れる前提で、レポート分割や公開ゾーン設計を用意する

power bi object level security を正しく使うと、「公式データセットを共有したい」という理想と、「項目の公開範囲を守りたい」という現実の両方を、無理なく両立しやすくなります。全員に同じものを見せるのではなく、“必要な人に必要な項目だけ”を見せる。その発想をモデル設計に落とすための基本装備がOLSです。