第2回では、パイプライン・メダリオン・ショートカット・ミラーリングでデータをOneLakeに集める技術を整理しました。データが揃ったら、いよいよ「分析して見える化する」フェーズです。ここでFabricの真価が発揮されます。特に Direct Lakeモード は、「なぜFabricのPower BIは速くて手間がかからないのか」の核心にあたる、Fabric最大の目玉のひとつです。
Power BIはインポートかDirectQueryの2択だと思ってた。Direct Lakeって、その第3の選択肢？何がおいしいの？
この記事は、Fabricシリーズの第3回として、「分析・可視化」を次の2つに絞って整理します。
- Direct Lakeモード を理解している
- Power BI連携（セマンティックモデル）を理解している
2項目と少なめですが、Direct Lakeは従来のPower BIの常識をひっくり返す重要トピックなので、じっくり整理します。まずは前提として、従来のPower BIの2つのモードを押さえるところから始めましょう。
前提：従来のPower BI「インポート」と「DirectQuery」
Direct Lakeを理解するには、まず従来の2モードの「トレードオフ」を知る必要があります。Power BIは長らく、この2つのどちらかを選ぶ必要がありました。
| インポート | DirectQuery | |
|---|---|---|
| 仕組み | データをPower BIにコピーして保持 | 都度元データに問い合わせ |
| 速度 | ◎ 高速（手元にある） | △ 遅い（毎回問い合わせ） |
| 鮮度 | △ 古い（更新が必要） | ◎ 常に最新 |
| 弱点 | データ更新（リフレッシュ）が重い | クエリのたびに元DBに負荷 |
つまり「速いけど鮮度が犠牲（インポート）」か「最新だけど遅い（DirectQuery）」という、あちらを立てればこちらが立たずの二択でした。大規模データではインポートのリフレッシュが何十分もかかったり、DirectQueryで元DBがパンクしたり——これが従来の悩みです。
Direct Lakeモード｜両者の「いいとこ取り」
Direct Lakeモードとは、OneLake上のParquetファイルを直接読み込むことで、インポートの「速さ」とDirectQueryの「最新さ」を両立させる、Fabric専用の新しいモードです。
カラクリはシンプルです。第1回で見たとおり、OneLakeのデータは Delta Lake / Parquet というオープンな列指向形式で保存されています。この形式は、実はPower BIがインポート時に内部で使う圧縮形式と非常に相性が良いのです。Direct Lakeは、データをコピーもDBへの問い合わせもせず、OneLakeのParquetをそのまま直接メモリに読み込みます。
【3モードの比較】
インポート : 元データ ──コピー──► Power BI内 ──► 表示
（速いが、コピーが古くなる／更新が重い）
DirectQuery : 表示のたびに ──問い合わせ──► 元DB
（最新だが、毎回遅い／元DBに負荷）
Direct Lake : OneLakeのParquetを ──直接読込──► 表示
（コピー無し＝最新／列指向で読むから高速）
★ 速さと鮮度を両立結果として、Direct Lakeは「インポート並みに速く、DirectQueryのように常に最新」を実現します。データのリフレッシュ（コピーの再取り込み）が原理的に不要なので、大規模データでもリフレッシュ待ちがありません。第2回のミラーリングやパイプラインでOneLakeのデータが更新されれば、それがそのままPower BIに反映されるわけです。
「OneLakeのParquetを直接読むから、コピー不要（＝最新）なのに速い」。これがOneLake一枚岩構造のご褒美なんだね！
「速さと鮮度を両立できるなら、なぜ最初からこれが無かったのか」と思うかもしれません。答えは、OneLakeのように全データが1つのオープン形式で統一されている土台が無いと成立しないからです。データがバラバラの場所・形式に散っていた従来では不可能で、Fabricの一枚岩構造があって初めて実現できた、というのがポイントです。
【ここが説明できればOK①】
「Direct Lakeは、OneLakeのParquetを直接読み込むことで、インポートの速さとDirectQueryの最新さを両立するモード。コピー不要でリフレッシュ待ちがない」——これを説明できれば、1つ目のチェックはクリアです。
Power BI連携｜セマンティックモデルからレポートへ
Direct Lakeで高速にデータを読めるようになったら、次は実際にレポートを作る流れです。ここで登場するのが セマンティックモデル です。
セマンティックモデルとは、レイクハウスやウェアハウスの生データに、テーブル同士の関係・計算指標（メジャー）・表示名などの「意味づけ」を与えた、レポートの土台となるモデルです。
生のテーブルは、そのままではただの数字と文字の羅列です。そこに「この売上テーブルとこの顧客テーブルはIDで繋がっている」「売上合計というメジャーはこう計算する」といったビジネスの意味を定義したものがセマンティックモデルです。レポート作成者は、この意味づけされたモデルの上でドラッグ＆ドロップしてグラフを作ります。
【FabricでのPower BI連携の流れ】
レイクハウス／ウェアハウス（OneLake上の実データ）
│
▼
セマンティックモデル（意味づけ：関係・メジャー・表示名）
│ ← Direct Lakeモードで直接接続すると高速＆最新
▼
Power BI レポート／ダッシュボード
│
▼
組織で共有（誰でも同じ数字を見られる）Fabricの強みは、この一連が同じ環境で完結することです。従来はデータの置き場所とPower BIが別サービスで、接続設定やデータのコピーが必要でした。Fabricでは、レイクハウスを作ると自動的に既定のセマンティックモデルが用意され、そのままDirect Lakeで繋いでレポートを作れます。データエンジニアが整えたGold層を、アナリストがすぐ可視化できる——第1回で触れた「役割別ワークロードが1つの環境で繋がる」メリットが、ここで実感できます。
なお2026年時点では、Copilotがセマンティックモデルの作成・改善を支援したり、AIエージェントがレポートページを自動生成したりと、この工程自体もAIで加速しています（AI連携は次の第4回で扱います）。
【ここが説明できればOK②】
「セマンティックモデルは生データに関係・メジャー・表示名の意味づけを与えたレポートの土台。Fabricではレイクハウス/ウェアハウス上にこれを作り、Direct Lakeで繋いでPower BIレポートを構築する」——これを説明できれば、2つ目のチェックはクリアです。
まとめ
今回は分析・可視化の核心を整理しました。この2つ、特にDirect Lakeの「なぜ速くて最新なのか」を説明できれば、Fabricの理解は一段深まります。
- Direct Lakeモード：OneLakeのParquetを直接読み込み、インポートの速さ×DirectQueryの最新さを両立
- セマンティックモデル：生データに意味づけを与えたレポートの土台。Direct Lakeで繋いでPower BIレポート化
- これらが成立するのは、OneLakeが全データを1つのオープン形式で統一しているから
ここまでで「集める→整える→可視化する」という王道の流れを一周しました。次の第4回では、少し毛色の違う2つのテーマ——リアルタイム分析（Real-Time Intelligence） と、2026年の目玉である AI連携（Fabric IQ / Data Agent） を扱います。「動いているデータ」と「データに自然言語で問う」世界です。
