Microsoft Learnの「Direct Lake overview – Microsoft Fabric」でまず押さえるべき結論は、Direct Lakeは「大容量データをPower BIで高速に分析するためのFabric向けストレージモード」ですが、ImportやDirectQueryの単純な上位互換ではないという点です。特に2026年5月時点では、オンプレミスゲートウェイやVNETゲートウェイを使ったDirect Lakeセマンティックモデルの更新はサポートされず、クラウド接続前提で設計する必要がある点が明確化されています。(Microsoft Learn)
この記事では、Microsoft FabricのDirect Lake overviewをもとに、何が重要なのか、誰に影響するのか、管理者・開発者が確認すべき設定、移行・展開時の注意点を実務目線で整理します。すでにPower BIのImportやDirectQueryを使っている組織は、「Direct Lakeにすれば更新も性能もすべて解決する」と考える前に、容量、権限、Deltaテーブル設計、接続方式を確認することが重要です。
Direct Lake overviewで分かること
Direct Lakeは、Microsoft Fabricで利用できるPower BIセマンティックモデルのテーブルストレージモードです。OneLake上のDeltaテーブルから必要なデータをメモリに読み込み、Power BIのVertiPaqエンジンでクエリを処理します。Importのように高い対話性能を狙いつつ、データ全体をセマンティックモデルへ複製するImport更新の負荷を避けやすいのが特徴です。(Microsoft Learn)
Importでは更新時にデータのコピーを作成しますが、Direct Lakeの更新は主にDeltaテーブルの最新メタデータを確認し、OneLake上のファイル参照を更新する「フレーミング」として動作します。そのため、更新処理そのものは軽量になりやすい一方で、実際のクエリ性能はDeltaテーブルの状態、容量SKU、メモリ、列の読み込み状況に大きく左右されます。(Microsoft Learn)
実務では、Direct Lakeを「更新不要の魔法のモード」と見るのではなく、「データ準備をOneLake側に寄せ、Power BI側では大規模データを効率よく参照する方式」と理解するのが安全です。Spark、T-SQL DML、データフロー、パイプラインなどで上流のデータ整形を済ませ、セマンティックモデルでは関係、メジャー、権限、表示設計に集中する構成が向いています。(Microsoft Learn)
2026年5月時点で特に重要な変更点
2026年5月時点で管理者が最初に確認すべき変更点は、Direct Lakeセマンティックモデルの更新にゲートウェイを使えない点です。MicrosoftDocsの更新履歴では、Direct Lake on OneLakeとDirect Lake on SQLのどちらも、オンプレミスゲートウェイおよびVNETゲートウェイ経由では動作せず、クラウド接続のみをサポートすることが明記されています。(GitHub)
この変更は、社内ネットワーク内のデータソースをゲートウェイ経由でPower BIに取り込んでいた組織に影響します。Direct LakeはOneLake上のDeltaテーブルを前提にするため、「既存のPower BI更新設定をそのままDirect Lakeへ置き換える」発想では失敗しやすくなります。データをFabricのLakehouseやWarehouse、またはDeltaテーブルとして扱えるFabricデータソースへ配置し、クラウド接続・権限・容量の設計を見直す必要があります。
もう一つの注目点は、Direct Lake on OneLakeとDirect Lake on SQLの使い分けがより重要になっていることです。Direct Lake on OneLakeはSQL分析エンドポイントを介したDirectQueryフォールバックを行わず、複数のFabricデータソースやImportテーブルとの組み合わせに向いています。一方、Direct Lake on SQLはSQL分析エンドポイントを使って検出や権限確認を行い、SQLビューやSQLベースの細かなアクセス制御がある場合にDirectQueryへフォールバックすることがあります。(Microsoft Learn)
Power BIの2026年4月更新では、Direct Lake on OneLake向けの計算列・計算テーブルや、ユーザーコンテキスト対応の計算列がプレビューとして案内されています。ただし、プレビュー機能は展開状況や制限が変わる可能性があるため、本番導入ではDirect Lake overview側の制限事項とPower BI更新情報の両方を確認してから採用判断するのが安全です。(Microsoft Learn)
Direct Lake on OneLakeとDirect Lake on SQLの違い
Direct Lakeを導入する際は、まず「Direct Lake on OneLake」と「Direct Lake on SQL」のどちらで作るのかを決める必要があります。名前は似ていますが、フォールバック、セキュリティ、複合モデル、ビュー利用の扱いが異なります。
| 比較項目 | Direct Lake on OneLake | Direct Lake on SQL |
|---|---|---|
| 主な接続先 | Deltaテーブルを持つ1つ以上のFabricデータソース | Deltaテーブルを持つ単一のFabricデータソース |
| SQL分析エンドポイント | フォールバック用途では使わない | テーブル・ビュー検出や権限確認に使う |
| DirectQueryフォールバック | サポートしない | 条件によってDirectQueryへフォールバックする |
| SQLビュー | 非マテリアライズドSQLビューのDirect Lakeテーブル化は非対応 | SQLビュー利用時はDirectQueryへフォールバック |
| 複合モデル | Importテーブルなどと組み合わせやすい | 同一モデル内でDirectQuery/Dualとの組み合わせに制限 |
| 向いている用途 | 複数Fabricソース、大規模ファクト、Importとの併用 | 既存のLakehouse/WarehouseのSQL分析エンドポイント利用 |
Direct Lake on OneLakeは、Fabric上のDeltaテーブルをより直接的に扱う構成です。DirectQueryフォールバックがないため、意図しない低速化は起きにくい一方、ガードレール超過や権限制約に引っかかるとクエリが失敗する可能性があります。Direct Lake on SQLはフォールバックにより結果を返し続けられる場面がありますが、その分、Direct Lakeとしての高速性を失う可能性があります。(Microsoft Learn)
判断基準はシンプルです。新規にFabric中心の分析基盤を作るなら、まずDirect Lake on OneLakeを検討します。SQLビュー、SQL分析エンドポイントの既存運用、SQLベースの権限制御に依存している場合はDirect Lake on SQLも候補になりますが、フォールバック発生時の性能低下を前提に監視とテストを行うべきです。
Import、DirectQuery、Direct Lakeの選び方
Direct Lakeは強力ですが、すべてのPower BIモデルを置き換えるものではありません。既存のImportやDirectQueryも、シナリオによっては引き続き適切です。
| ストレージモード | 向いているケース | 注意点 |
|---|---|---|
| Import | 小〜中規模データ、セルフサービス分析、Power Queryで柔軟に加工したい場合 | データ更新でコピーを作るため、大規模化すると更新時間・メモリ負荷が増える |
| DirectQuery | データソース側の最新状態を常に問い合わせたい場合、既存DBの制御を優先したい場合 | レポート操作のたびにソースへクエリが飛ぶため、性能はソース側に依存しやすい |
| Direct Lake | OneLake上の大規模Deltaテーブルを高速に分析したい場合、Import更新の負荷を避けたい場合 | Deltaテーブル設計、容量、権限、クラウド接続の設計が重要 |
| Direct Lake + Import | 大規模ファクトはDirect Lake、小規模ディメンションや補助テーブルはImportにしたい場合 | Direct Lake on OneLakeを前提に設計すると柔軟性が高い |
たとえば、売上明細のような数億行以上のファクトテーブルはDirect Lake、手入力で管理する予算分類や小規模マスタはImportにする構成が現実的です。逆に、分析担当者がPower Queryで試行錯誤しながらデータ加工したい場合は、最初からDirect Lakeに寄せすぎると開発スピードが落ちることがあります。(Microsoft Learn)
影響を受ける対象者
Direct Lake overviewの更新内容は、Power BIレポート作成者だけでなく、Fabric管理者、データエンジニア、セマンティックモデル開発者、セキュリティ担当者にも影響します。
| 対象者 | 主な影響 | 確認すべきこと |
|---|---|---|
| Fabric管理者 | 容量、クラウド接続、ワークスペース、権限設計に影響 | Fabric SKU、ゲートウェイ非対応、リージョン、XMLA設定 |
| Power BI管理者 | 既存の更新運用やゲートウェイ設計に影響 | 更新履歴、クラウド接続、固定ID、SSO |
| セマンティックモデル開発者 | モデル設計とストレージモード選択に影響 | Direct Lake on OneLake/SQL、複合モデル、リレーションシップ |
| データエンジニア | Deltaテーブル設計がレポート性能に直結 | V-Order、Parquetファイル数、行グループ、更新パターン |
| セキュリティ担当者 | OneLake Security、RLS、OLSの設計に影響 | モデル権限、OneLake権限、SQL分析エンドポイント権限 |
| レポート作成者 | ライブ編集やスキーマ同期の扱いに影響 | Build権限、Open data model、PBIP、Git連携 |
特に大きいのは、データエンジニアの役割です。Direct LakeではPower BI側の更新だけで性能問題を解決するのではなく、Deltaテーブルのファイルレイアウトや更新方式がレポートの応答性に直結します。(Microsoft Learn)
管理者が確認すべき設定
Fabric容量とガードレール
Direct LakeセマンティックモデルにはFabric容量ライセンスが必要です。SKUごとに、テーブルあたりのParquetファイル数、行グループ数、行数、モデルサイズ、メモリなどのガードレールが設定されています。ガードレールを超えた場合、Direct Lake on OneLakeでは更新が失敗し、Deltaテーブルを最適化するまでモデルを照会できない可能性があります。Direct Lake on SQLでは、フォールバックが有効な場合にDirectQueryへ切り替わり、結果は返るものの性能が低下する可能性があります。(Microsoft Learn)
確認すべき観点は、単に「F64以上なら安心」といったSKU名ではありません。対象テーブルのParquetファイル数、行グループ数、クエリで読み込まれる列、同時実行、メモリ圧迫時の挙動を確認する必要があります。Direct Lakeは必要な列をメモリに読み込む方式のため、テーブル全体の行数だけでなく、よく使われる列のカーディナリティやセグメント数も重要です。(Microsoft Learn)
ゲートウェイではなくクラウド接続を使う
Direct Lakeの更新では、オンプレミスゲートウェイやVNETゲートウェイを前提にしないでください。公式ドキュメントの制限事項では、Direct Lake on OneLakeもDirect Lake on SQLもゲートウェイ経由で動作せず、クラウド接続のみをサポートするとされています。(Microsoft Learn)
既存のPower BI更新がゲートウェイ経由でSQL Serverや社内DBを参照している場合、Direct Lakeへの移行ではまずデータ配置を見直します。社内DBからFabricへデータを取り込み、LakehouseやWarehouse上でDeltaテーブルとして整備し、その後にDirect Lakeセマンティックモデルを構築する流れが基本です。
SSOと固定IDの使い分け
Direct LakeはMicrosoft Entra ID認証を使います。既定ではSSOにより、セマンティックモデルを照会しているユーザーの権限でデータアクセスが確認されます。一方、固定IDのクラウド接続を使うと、各ユーザーに基盤データへの直接権限を付与せず、特定のIDの権限でデータへアクセスできます。(Microsoft Learn)
実務での判断基準は次の通りです。
| シナリオ | 推奨される考え方 |
|---|---|
| ユーザーごとに基盤データへのアクセス可否を反映したい | SSOを使う |
| レポート利用者にLakehouseやWarehouseを直接触らせたくない | 固定IDを検討する |
| Embeddedや多数の閲覧者向け配信を行う | 固定IDと最小権限を検討する |
| RLS/OLSを全Fabricエンジンで一貫させたい | OneLake Securityを優先して設計する |
注意点は、セマンティックモデルのRLSだけで守っているつもりでも、ユーザーがOneLakeやSQL分析エンドポイントに直接アクセスできる場合、別経路でデータを参照できる可能性があることです。包括的な制御が必要な場合は、OneLake Securityで行・列・テーブル単位の制御を設計する必要があります。(Microsoft Learn)
自動更新とフレーミング
Direct Lakeには、Direct Lakeテーブルを自動更新するセマンティックモデルレベルの設定があります。既定で有効になっており、OneLake側のデータ変更をセマンティックモデルへ反映しやすくします。ただし、長時間ETLの途中状態を見せたくない場合や、特定のタイミングで一貫したデータを公開したい場合は、自動更新を無効にして手動・スケジュール・APIによるフレーミング制御を検討します。(Microsoft Learn)
「最新データをすぐ見せる」ことと「業務的に整合したデータを見せる」ことは同じではありません。たとえば、売上、返品、在庫引当の3テーブルを順番に更新するETLでは、途中のタイミングで自動更新されると、レポート上の数字が一時的にずれる可能性があります。この場合、ETL完了後にセマンティックモデルをフレーミングする運用のほうが安全です。
開発者が確認すべき設計ポイント
Deltaテーブルの状態が性能を決める
Direct Lakeの性能は、セマンティックモデルの設計だけでなく、Deltaテーブルの品質に強く依存します。公式ドキュメントでは、V-Order最適化、Parquetファイル数を小さく保つこと、大きな行グループを使うこと、Deltaログへの更新影響を抑えることが推奨されています。(Microsoft Learn)
特に避けたいのは、大きなDeltaテーブルに対する破壊的な更新パターンです。小さな変更のつもりでも、Parquetファイルは不変のため、実際には既存ファイルを置き換える動きになり、Direct Lakeのインクリメンタルフレーミングの効果が下がることがあります。追加中心のパターンや、適切なパーティション設計、定期的なOPTIMIZEを組み合わせると、再読み込み負荷を抑えやすくなります。(Microsoft Learn)
モデルに含める列を絞る
Direct Lakeはクエリに必要な列を読み込む方式です。だからといって、Lakehouseの全列をそのままセマンティックモデルに入れるのはおすすめできません。フィルター、グループ化、ソート、集計、リレーションシップに必要な列を中心にモデルを設計し、使わない技術列や高カーディナリティの文字列列は見直します。(Microsoft Learn)
たとえば、ログテーブルに長いJSON文字列、リクエストID、セッションID、未加工メッセージが含まれている場合、それらをPower BIの標準レポートで使うのか確認します。使わない列を取り込むと、モデルの見通しが悪くなるだけでなく、誤ってビジュアルに使われた際にメモリや読み込み性能へ影響します。
リレーションシップとデータ型をそろえる
Direct Lakeでは、関連する列のデータ型が一致している必要があります。また、リレーションシップの一側に重複があるとクエリが失敗します。複雑なDelta列型、バイナリ、GUIDのセマンティック型もサポートされないため、文字列などサポートされる型へ変換する必要があります。(Microsoft Learn)
失敗しやすい例は、Lakehouse側では数値ID、別テーブルでは文字列IDとして保存されているケースです。見た目は同じ「1001」でも、型が違えば関係作成やクエリで問題になります。Direct Lakeへ移行する前に、主キー・外部キー相当の列を上流で統一しておくべきです。
計算列・計算テーブルは最新制限を確認する
Direct Lake overviewでは、Direct Lake列やDirect Lakeテーブルを参照する計算列・計算テーブルに制限があります。一方、Power BIの2026年4月更新では、Direct Lake on OneLakeの計算列・計算テーブルがプレビューとして案内されています。プレビュー機能は便利ですが、すべてのテナントや本番運用で同じ条件で使えるとは限らないため、機能の有効化状態、制限、展開状況を確認してから使うべきです。(Microsoft Learn)
実務では、まず上流のLakehouseやWarehouseで列を作ることを優先します。どうしてもモデル側で補助列が必要な場合のみ、対象がDirect Lake on OneLakeなのか、プレビュー利用が許容される環境なのかを確認してから採用します。
移行時の注意点
ImportからDirect Lakeへ移行する場合
ImportモデルからDirect Lakeへ移行する場合、Power Queryで行っていた加工をどこに移すかが最初の論点です。Direct Lakeはデータ準備をOneLake側へ寄せる前提のため、Power Queryの変換ロジックをSpark、SQL、データフロー、パイプラインなどへ移し、Deltaテーブルとして整備する必要があります。(Microsoft Learn)
移行前に確認すべきことは、次の4点です。
| 確認項目 | 具体的な確認内容 |
|---|---|
| Power Query加工 | どの変換をLakehouse/Warehouse側に移すか |
| 更新頻度 | Direct Lakeの自動更新でよいか、ETL完了後にフレーミングするか |
| 権限 | 利用者に基盤データ権限を与えるか、固定IDにするか |
| 容量 | 現在のFabric SKUで対象テーブルがガードレール内に収まるか |
既存Importモデルを一気に置き換えるより、大規模ファクトだけDirect Lake化し、小規模ディメンションや補助テーブルはImportのまま残す段階移行が現実的です。
DirectQueryからDirect Lakeへ移行する場合
DirectQueryからDirect Lakeへ移行する場合、レポート操作ごとにソースDBへ問い合わせる設計から、OneLake上のDeltaテーブルを列単位で読み込む設計へ変わります。これにより、レポート応答性の改善が期待できますが、データの見え方はフレーミング時点のDeltaテーブル状態に依存します。DirectQueryのように常にソースへ問い合わせる動きとは異なるため、鮮度要件を再定義する必要があります。(Microsoft Learn)
「1分以内の最新性が必要」なのか、「業務締め処理後の整合性が必要」なのかで運用は変わります。リアルタイム性を優先する場合でも、ETL途中の不整合を見せないように、フレーミングのタイミングを設計してください。
Direct Lake on SQLからDirect Lake on OneLakeへ移行する場合
Power BI Desktopでは、既存のDirect Lake on SQLセマンティックモデルをTMDLビューでDirect Lake on OneLakeへ移行する方法が案内されています。Direct Lake on OneLakeには、複数ソースを扱えること、DirectQueryフォールバックがないことなどの利点があります。ただし、SQL分析エンドポイントのビューを使っているモデルでは、この移行手順は推奨されていません。(Microsoft Learn)
移行時は、まずバージョン履歴を作成し、戻せる状態にしてからTMDLで接続式を変更します。成功後はモデルをRefreshしてスキーマとフレーミングを確認し、資格情報をWeb側の設定で整えます。移行後は、SQLビュー依存、RLS、フォールバック前提のレポートがないかを必ずテストしてください。
展開・運用で失敗しやすいポイント
本番モデルを直接ライブ編集してしまう
Direct Lakeテーブルを含むセマンティックモデルは、Power BI DesktopでローカルPBIXを編集して公開する従来の感覚とは異なります。Power BI Desktopで編集している場合でも、実体はFabricワークスペース上のセマンティックモデルをライブ編集しており、変更は自動保存されます。(Microsoft Learn)
本番モデルを直接編集すると、利用中のレポートに即座に影響する可能性があります。開発ワークスペースで編集し、Git統合やデプロイパイプラインで本番へ反映する運用にしてください。複数人で同じモデルを編集する場合は、競合や再同期にも注意が必要です。
スケジュール更新でスキーマ同期まで行われると思い込む
Power BI DesktopでDirect Lakeモデルをライブ編集してRefreshを押すと、スキーマ更新とDirect Lakeテーブルのリフレーミングが行われます。一方、Fabricワークスペースのスケジュール更新はDirect Lakeテーブルのリフレーミングのみで、スキーマ更新は行いません。(Microsoft Learn)
つまり、Lakehouse側で列を追加・削除・リネームした場合、「スケジュール更新されているからモデルにも反映される」と考えるのは危険です。スキーマ変更時は、WebモデリングやPower BI DesktopのRefresh、Edit tables、TMDLなどを使って、モデル側の列定義を意図通りに更新する必要があります。
SQLビューをDirect Lakeとして扱えると思い込む
Direct Lake on SQLではSQLビューを選べる場合がありますが、ビューに基づくモデルテーブルはDirectQueryへフォールバックします。Direct Lake on OneLakeでは、非マテリアライズドSQLビューに基づくDirect Lakeテーブル作成はサポートされません。必要であればLakehouseのマテリアライズドビューやDeltaテーブル化、またはImport/DirectQueryなど別のストレージモードを検討します。(Microsoft Learn)
SQLビューを多用している既存環境では、Direct Lake移行前に「このビューは本当にDirect Lakeで高速化されるのか」を確認してください。ビューのままでは期待した性能改善が得られないことがあります。
RLS/OLSの場所を混在させすぎる
Direct Lakeでは、セマンティックモデル、SQL分析エンドポイント、OneLake SecurityのどこでRLS/OLSを定義するかが重要です。特にDirect Lake on SQLでは、SQL分析エンドポイント側のRLS/OLSによりDirectQueryフォールバックやクエリ失敗が発生する場合があります。Direct Lake on OneLakeではOneLake Securityによる統一的なアクセス制御が有力な選択肢です。(Microsoft Learn)
複数レイヤーに似たような権限制御を重ねると、運用時に「なぜ見えないのか」「なぜ空の結果になるのか」を調査しにくくなります。全Fabricエンジンで一貫した制御をしたいならOneLake Security、レポート配信だけを制御したいならセマンティックモデルRLS、といった役割分担を明確にしてください。
導入前チェックリスト
Direct Lakeを導入する前に、次の順番で確認すると手戻りを減らせます。
| 手順 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | 対象データがOneLake上のDeltaテーブルとして整備されているか | 未整備なら先にLakehouse/Warehouse側を設計する |
| 2 | Direct Lake on OneLakeとDirect Lake on SQLのどちらにするか | 新規・複数ソース・複合モデル重視ならOneLakeを優先 |
| 3 | ゲートウェイに依存していないか | オンプレミス/VNETゲートウェイ前提なら設計変更が必要 |
| 4 | Fabric SKUのガードレール内に収まるか | Parquetファイル数、行グループ、モデルサイズを確認 |
| 5 | SSOか固定IDか | 利用者に基盤データ権限を与えるかで決める |
| 6 | RLS/OLSをどこで定義するか | OneLake Security、モデルRLS、SQL側制御を整理 |
| 7 | Deltaテーブルの更新パターンは適切か | 破壊的更新を避け、Appendや適切なパーティションを検討 |
| 8 | スキーマ変更時の運用が決まっているか | Refresh、Edit tables、TMDL、Git運用を定義 |
| 9 | POCで性能と権限を検証したか | 冷状態・温状態・フォールバック有無を確認 |
| 10 | 本番展開手順があるか | 開発ワークスペース、Git、デプロイパイプラインを使う |
このチェックリストの中で最も見落とされやすいのは、ゲートウェイ非対応と権限設計です。Power BIの既存運用ではゲートウェイとワークスペース権限だけで回っていた環境でも、Direct LakeではOneLake、Deltaテーブル、Fabric容量、セマンティックモデル所有者の権限まで含めて確認する必要があります。
管理者・開発者が次に取るべき行動
Direct Lake overviewを読んだ後に最初に行うべきことは、既存モデルをすぐ移行することではありません。まず、対象レポートを「大規模ファクト中心」「Import更新が重い」「DirectQueryが遅い」「権限要件が複雑」のように分類し、Direct Lakeが本当に効果を出せる領域を絞ります。
次に、1つの代表的なデータセットでPOCを作成します。Direct Lake on OneLakeを第一候補にし、必要に応じてImportテーブルを組み合わせます。そのうえで、容量ガードレール、ゲートウェイ非依存、SSOまたは固定ID、OneLake Security、Deltaテーブル最適化、スキーマ変更時の運用を検証してください。
Direct Lakeは、Microsoft Fabricで大規模BIを作るうえで非常に有力な選択肢です。ただし成功の鍵は、Power BI側のストレージモード変更だけでなく、OneLake上のデータ設計、クラウド接続、権限、容量、展開プロセスを一体で設計することにあります。まずは既存レポートのうち、更新負荷やDirectQuery性能に課題があるモデルを1つ選び、Direct Lake on OneLakeを中心に小さく検証するところから始めるのが現実的です。
コメント