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

Microsoft Fabric の What's New で、2026年5月の generally available features として OneLake security と OneLake data access roles が案内されています。OneLake に置いたデータへ、フォルダー、行、列の粒度を含むアクセス制御をかけるための更新です。

要点

• Fabric の What's New に、2026年5月 GA 行として OneLake security と OneLake data access roles が掲載された
• OneLake 上のデータに対し、role permissions と folder / row / column-level security を組み合わせた制御を行う方向の更新
• Lakehouse、Warehouse、Power BI、AI agent workflow など、複数の Fabric 体験から同じデータを読むチームほど影響が大きい
• 既存の 2026年4月 Fabric 月次記事とは別の May 2026 native row として扱うべき更新

今回のリリースノートで語られていること

今回の Microsoft Learn の What's New では、Fabric の GA features 一覧に OneLake security と OneLake data access roles が May 2026 の項目として追加されています。説明の中心は、OneLake に保存されたデータへ fine-grained access control を適用し、role permissions と folder、row、column-level security を組み合わせて扱えるようにする点です。

Fabric を単なる BI や個別ワークロードの集合として使っている段階では、アクセス制御は workspace、item、semantic model、warehouse などの単位で考えがちです。しかし OneLake を組織の共通データレイヤーとして使い、Lakehouse、Warehouse、Notebook、Dataflow、Power BI、Real-Time Intelligence、さらに AI agent や MCP 経由の利用まで広げると、同じファイルやテーブルを複数の読み取り経路から参照することになります。このとき、データの置き場所に近い層で一貫した security model を持てるかどうかが、運用のしやすさとリスク管理に直結します。

OneLake data access roles は、その観点で重要です。単に「誰が lakehouse を開けるか」ではなく、どの role がどのフォルダー、どの行、どの列へアクセスできるかを設計することで、部門別データ、個人情報、財務指標、顧客属性、生成 AI に渡す前処理済みデータなどをより細かく分けて扱えます。AI 活用が進むほど、データセットが人間の dashboard だけでなく agent、tool、notebook、API の入力にもなるため、アクセス境界を後付けの運用ルールだけに頼るのは危険です。

GA として掲載されたことも見逃せません。Preview の段階では、評価環境で設計を試す意味合いが強く、全社標準に組み込むには制限や仕様変更を見込む必要があります。GA になったことで、Fabric を本番の統合分析基盤として使う組織は、OneLake security を権限設計、データ分類、監査、semantic model、shortcut、AI ワークフローの標準設計に組み込む検討をしやすくなります。

対象になりそうなチーム

• Microsoft Fabric を全社データ基盤として運用している platform administrator
• OneLake、Lakehouse、Warehouse、Power BI semantic model を横断して使う analytics engineering team
• 部門別データ、個人情報、財務情報、顧客データの閲覧範囲を細かく分けたい governance / security team
• Fabric 上のデータを AI agent、Notebook、MCP、Copilot 系ワークフローへ渡すチーム

実務で確認したいポイント

まず、既存の workspace / item / semantic model 権限と、OneLake security の責務分担を整理する必要があります。すべてを OneLake 側だけで解決するのではなく、どの層でアクセスを止めるべきか、どの層では用途別の view や semantic model を使うべきかを決めます。

次に、folder-level、row-level、column-level のどれを主軸にするかをデータ分類ごとに分けます。たとえば部門別データは folder や table 単位、地域・顧客セグメントは row 単位、個人情報や機密属性は column 単位で考えるほうが自然です。Power BI だけでなく notebook、warehouse query、agent tool からの読み取りも含めて、期待どおりに制御されるかを検証したいところです。

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

2026年5月の OneLake security / data access roles GA は、Fabric を AI 時代の共通データ基盤として使うための統制面の更新です。新しい見た目の機能というより、複数のワークロードと AI 利用が同じ OneLake データに触れる前提で、アクセス制御を本番運用に耐える粒度へ寄せる動きとして見るのがよさそうです。