Microsoft Fabric 2026年5月のリリースノート解説: OneLake security と data access roles が GA

Microsoft Fabric の What's new で、2026年5月の GA 項目として OneLake security と OneLake data access roles が案内されました。OneLake 上のデータに対して、フォルダー、テーブル、行、列といった粒度でアクセス制御を設計しやすくする更新です。

この月次記事の更新方針

Fabric の What's new は継続更新される公式ページです。月中や後日に同じページへ項目が追記される場合があるため、2026年5月分は行単位で再確認し、必要に応じてこの記事へ追記します。今回の初回確認では、May 2026 の GA 行として OneLake security / data access roles を扱います。

要点

• OneLake security と OneLake data access roles が generally available として掲載された
• OneLake に保存されたデータに対して、ロールベースのアクセス制御を適用できる
• 対象データはフォルダーやテーブル単位で管理でき、必要に応じて行レベル・列レベルの制御も組み合わせられる
• 権限は Fabric 内の複数エクスペリエンスからのデータ参照に影響するため、Lakehouse、mirroring、SQL analytics endpoint の運用設計と合わせて確認したい

今回の更新で何が変わるのか

OneLake security は、Fabric item の中にあるデータを「誰がどの範囲まで読めるか」という観点で管理する仕組みです。従来の workspace 権限や item 権限だけでは、同じ Lakehouse や mirrored database の中でデータ範囲を細かく分けたい場合に設計が粗くなりがちでした。

今回 GA として案内されたことで、OneLake を全社データレイクとして使うチームは、プレビュー検証から本番標準化の検討へ進みやすくなります。特に、データメッシュ、部門別データ共有、外部エンジン連携、AI/agent 利用のように、同じデータ基盤を複数の利用者・ワークロードで共有する環境では重要です。

一方で、アクセス制御を足すだけでは安全になりません。Microsoft Learn の関連ドキュメントでは、data access role にユーザーを追加する場合、DefaultReader role など既存の広い権限が残っていると意図した制限にならない点も説明されています。導入時は、ロール追加だけでなく、既存権限の棚卸しをセットで行う必要があります。

対象になりそうなチーム

• OneLake を組織横断のデータ基盤として運用している platform team
• Lakehouse、Mirrored Databases、Azure Databricks Mirrored Catalog を Fabric で扱う analytics engineering チーム
• 行レベル・列レベルのアクセス制御を Fabric 側で標準化したい governance / security 担当
• Copilot や data agent から参照できるデータ範囲を明確にしたい AI 活用推進チーム

実務でまず確認したいこと

1. Lakehouse や mirrored item ごとに、DefaultReader など広い既存ロールが残っていないか確認する
2. 部門、職務、プロジェクト単位で必要な data access role を設計する
3. 行レベル・列レベル制御が必要なデータと、フォルダー・テーブル単位で十分なデータを分ける
4. SQL analytics endpoint を OneLake security と組み合わせる場合、user identity access mode の設定要件を確認する
5. Fabric 外のエンジンや AI/agent 経由の利用でも、期待した制御が効くかテストする

結局、この更新をどう見るべきか

OneLake security の GA は、Fabric を単なる分析ワークスペースではなく、組織の共有データ基盤として扱うための重要な土台です。便利なアクセス機能というより、誰がどのデータを見られるかを Fabric 全体で説明可能にするための更新として読むべきです。