※この記事は 2026/01 時点で公開されている Microsoft Learn の仕様をベースに整理しています。OneLake セキュリティはプレビューのため、挙動や制約は今後変わる可能性があります。
はじめに
OneLake セキュリティ（プレビュー）が出てきて、
- データへのアクセス制御を “OneLake 側（データプラットフォーム側）” に寄せたい
- ショートカットで下流ワークスペースにデータを配布しても、同じルールで守りたい
というニーズはかなり強いと思います。
ただし実際に触ってみると、「何でも OneLake セキュリティに寄せればOK」ではないポイントがありました。
特に 列レベル（CLS）を使うと、Power BI レポートがエラーになるケースが起こり得ます。
そこでこの記事では、
- OneLake セキュリティとショートカットを組み合わせるときの “押さえ所”
- 列の守り方の選択肢（OneLake / Notebook / Warehouse DDM）
- どういうときにどれを選ぶべきか（意思決定チャート）
を整理します。
想定する構成（OneLake セキュリティを一元管理したい）
OneLake セキュリティとショートカットを組み合わせると、イメージはこんな構成になります。
▽ 参考記事（おすすめ！）
OneLake セキュリティとショートカットの組み合わせの基本ルール、課題、惜しいと感じている点（筆者抜粋）
1) OneLake セキュリティは「物理テーブル側（ショートカット元）」で設計する
OneLake セキュリティの設定は、基本的に 物理テーブルが存在する Lakehouse 側（ショートカット元） を起点に考える。
ショートカット先の Lakehouse で “同じ設定をもう一回やる” というより、元データ側で統一的に守る発想になる。
なので「ショートカットで配布しても、元データのルールを引き継がせたい」という目的とは相性が良い。
2) OneLake セキュリティが効くのは「主に ワークスペース権限：Viewerのユーザー」
OneLake セキュリティのロールは、Viewer（または ワークスペース権限がはなく、itemレベルの権限は持っている） のユーザーに対してデータアクセスを付与・制限するための仕組みです。
一方で Admin / Member / Contributor は OneLake セキュリティの影響を受けず、フルアクセスになり得ます。
= “守りたい相手” を ワークスペース権限 で強い権限にしない設計が大事）
3) ショートカット先ワークスペースで“共同作成者以上”を付けると、Notebook 経由で「参照できる範囲の複製」は可能になる
※想定する構成（OneLake セキュリティを一元管理したい）の図の構成が前提です。
OneLake セキュリティで行・列レベルの制御を入れていても、ショートカット先ワークスペースで共同作成者以上の権限を付与すると、Notebook（Spark）経由で 「ショートカットテーブルから参照できた行・列の範囲」 を読み取り、別テーブルとしてコピー（派生テーブル化）することは可能になる。
なお、OneLake セキュリティの行・列レベル制御と書き込み許可は現状併用はできない。
ショートカットテーブルそのものを書き換える（UPDATE/DELETE 等）ことを許す、という意味ではない点には注意したい。
また、パイプラインは（少なくとも現時点では）OneLake セキュリティが適用されたテーブルに対しては使用できず、データフローも利用できる機能が限定される。
4) 動的なアクセス制御（状況で変わる判定）は現状できない
ユーザー属性や条件で動的に切り替わる ようなアクセス制御（いわゆる動的制御）は現状サポート外
この要件が強い場合は、ウェアハウスの導入を考える必要が出てくる
5) 【本題】列レベルセキュリティ（CLS）は、レポートの “ビジュアルエラー” が起きる（データは守られる）
CLS を適用したテーブルを参照するレポートでは、
1つでも許可されていない列がビジュアル内で参照されていると、ビジュアル全体がエラー になる。（CLSが適用されているユーザーが参照する場合）
つまり、期待しがちな「許可された列だけ都合よく表示される」挙動にはならない。
ただ、RLSで指定した列を守る観点では正しい挙動だが、そのレポートビジュアルが見れなくなってしまうのは不便さを感じる。
▽列レベルセキュリティがかかっていない人のレポートの見え方
▽列レベルセキュリティが適用された人の画面はビジュアルでエラーになる
【判断フロー】OneLake セキュリティで列を守るべきか？
ここまでで、OneLake セキュリティ×ショートカットを採用するうえでの 基本ルール と、実務で踏みやすい 制約・注意点 を整理しました。
（特に、CLS を入れたときに Power BI 側でビジュアルエラーが起こる点は致命的になり得ます）
とはいえ、OneLake セキュリティでアクセス制御を データプラットフォーム側に寄せて一元管理できる のは、やはり大きな魅力です。
だからこそ「OneLake セキュリティを使う／使わない」を感覚で決めるのではなく、
- 本当に OneLake セキュリティが要件に合っているのか？
- もっとシンプルに、Notebook で“配布用テーブル”を作る方が事故が少ないのでは？
- 逆に OneLake セキュリティでは要件を満たせず、Warehouse を採用して DDMに寄せた方が良いのでは？
…という観点で、判断の軸を明確にして選べるように意思決定チャートに落としてみました。
※想定する構成（OneLake セキュリティを一元管理したい）の図の構成を前提で以下のチャートが当てはまります。
まとめ
- OneLake セキュリティは「データ側で統一的に守る」には強いが、プレビュー制約と “Viewer向け” という性質を理解する必要がある
- OneLakeセキュリティのCLS適用範囲の列がレポートビジュアルに含まれると、エラーになりビジュアル全体が見れなくなる
- “列を消す” と “値を伏せる” を分けると、選択肢（OneLake / Notebook / DDM）がスッキリ決まる
Youtubeもやってます！
FabricやDatabricksについて学べる勉強会を毎月開催！
次回イベント欄から直近のMicrosoft Data Analytics Day(Online) 勉強会ページ移動後、申し込み可能です！