Power BI Direct Lake vs Databricks SQL: アーキテクチャ上のトレードオフとパフォーマンスの考察 ②

前回のブログでは、Azure Databricks を中心としたデータ基盤において、DirectQuery (DQ) on Databricks SQL と Direct Lake を比較した PoC の背景と、パフォーマンス結果の全体像をご紹介しました。

本稿ではその続編として、より技術的に踏み込み、Mirrored Unity Catalog（UC）から Direct Lake を構築した場合に直面する落とし穴を中心に解説していきます。

特に、ミラーリングはリアルタイム同期に優れる一方で、Direct Lake が求める分析向けデータレイアウトとは必ずしも相性が良くない点が、今回の PoC を通じて明確になりました。また、ADLS Gen2 ショートカットを用いた Direct Lake と、OneLake にデータを永続化した Direct Lake（Lakehouse における Fully Materialized Delta tables）では、パフォーマンス特性や運用上のメリット・デメリットが大きく異なります。

第2回では、これらの違いを整理しながら、なぜ Direct Lake の性能がアーキテクチャ次第で大きく変わるのか、そして Fabric を前提とした最適な設計とは何かについて、PoC で得られた学びをもとに考察していきます。

Direct Lake の2つのモードについて

Direct Lake についてはこのブログで何度も取り上げてきましたが、今回は Direct Lake のモードついて整理しておきます。

対象となるのは次の 2 つのモードです。

• DL on SQL（Direct Lake on SQL Analytics Endpoint *1）
• DL on OL（Direct Lake on OneLake）

同じ Direct Lake でも、接続経路やデータ参照の仕組みが異なるため、用途や要件によって適切なモードを選択する必要があります。本記事では、それぞれの違いを簡単に整理していきます。

*1:日本語ではSQL 分析エンドポイント

Power BI Direct Lake vs Databricks SQL: アーキテクチャ上のトレードオフとパフォーマンスの考察 ①

Power BI の Direct Lake と DQ on Databricks SQL（DirectQuery on Databricks SQL Warehouse）は、いずれもデータレイク上の大規模データを高速に分析できる一方で、前提とするアーキテクチャや最適化の考え方は大きく異なります。本ブログでは、顧客が実際に使用する数十億行規模の実データを用いた検証結果をもとに、Direct Lake と Databricks SQL それぞれが得意とするパターン、性能が頭打ちになる条件、データ構造・パーティション・ファイル配置の影響を整理します。加えて、Power BI Direct Lake と Databricks の連携を模索している方に向けて、ミラーリングされた Unity Catalog（UC）や外部テーブルショートカットを用いた構成も含めて検証し、どのような前提や制約のもとで有効に機能するのかを考察します。単なる性能比較に留まらず、「どのシナリオで、どの選択が合理的か」を判断するためのトレードオフを分かりやすく解説します。

なお、内容が膨大につき、2回に分けて紹介することにします。また、結果だけ知りたい方は、「パフォーマンス比較」を直接ご覧ください。

Power BI 2025：進化と終幕、その先にある「Fabric+Al」時代の幕開け

2025年の Power BI は、10歳の誕生日を迎えただけでなく、これまで以上に “変革の年” でした。新機能の登場、機能の廃止、AI 活用の急速な進展、そして Fabric 時代を見据えた大規模なアーキテクチャ転換等がありました。この1年を一言で表すなら、まさに 「Power BI が BI を超えて、Intelligence Platform へと歩み始めたターニングポイント」 と言えるでしょう。

本記事では、2025年に発表・提供された Power BI / Fabric の新機能、廃止されたサービス、Power BI の製品開発チームによる最新知見、日本企業の導入傾向、そして今後のロードマップを踏まえ、1年の動きを総整理していきたいと思います。

Fabric 容量の考え方 ②

前回 は Fabric 容量、スケール Out/Up 等に関する基礎的な概念について紹介をしましたが、今回は以下の通りの内容について解説をしていきます。

• コンピュート (Compute) と 課金 (Billing) を分けて考える
• Bursting / Smoothing / Throttling を正しくイメージする

Power BI Desktop や Power BI Pro / PPU をメインで活用するPower BI ペルソナは Fabric 容量を意識する必要はないですが、Fabric 機能を含む高度な機能を使用する必要がある場合、あるいは OneLake を中心にデータ活用をする必要がある場合、Fabric 容量に関してある程度しっかり把握しておくことが推奨されます。

Fabric 容量の考え方 ①

今回は、Microsoft Fabric を本気で使おうとすると必ずぶつかるテーマ、「Fabric 容量の仕組み」 について、少し腰を据えて整理してみます。まずは Fabric 容量とは何か？からスタートし、Fabric の PoC や本番導入をする際の下記の会話に深堀していきます。

• 「容量が足りないって言われるけど、そもそも容量って何？」
• 「Metrics アプリを見ると 100% って出てるのに、体感はそんなに詰まってない…？」
• 「Bursting？ Smoothing？ Throttling？ 結局どういうロジックで動いてるの？」
• 「Capacity Metrics App が難しすぎて、結局何を見ればいいのかわからない」

これらの概念は混乱しやすいため、分かりやすく嚙み砕いて紹介していきたいと思います。

アンケート結果を会話で分析: Standalone Copilotを使う

今回のタイトルは前回とは異なりますが、内容としては続編になります。今回は、私がスピーカーとして参加した某大手企業のPower BI 社内ワークショップで実施されたアンケートを題材に、得られたフィードバックをAI と組み合わせて活用するとどのような分析が可能になるのかを見ていきたいと思います。

アンケート調査は、組織が顧客や社員の声を把握し、改善の方向性を導き出すために欠かせない取り組みです。しかし、その結果を分析するとなると、Excel や BI ツールを使って集計を行い、グラフを作り込み、さらにインサイトを抽出するまでに多くの工数がかかります。このプロセスは労力がかかる一方で、「いま知りたいことを、もっと直感的に聞けたら…」 というニーズはますます高まっています。

そこで登場するのが、Microsoft Fabric における Standalone Copilot（Chat with your data、以下 CWYD） です。CWYD は、準備済みのセマンティックモデルをもとに「会話形式でデータに質問」し、結果を即座に返してくれる仕組みです。アンケートのように回答数が多く、設問の粒度も多岐にわたるデータを対象にすると、その効用は一層大きくなります。

本記事では、実際に Power BI のアンケート分析モデルを CWYD で扱ってみた事例を紹介し、従来の集計とどう違うのか、どのようなプロンプトを投げると効果的かを探っていきます。
過去記事（①、②、③）

Power BI サービスからインポートモデルを直接作る

2025年6月に発表された 「インポートモデルにおける Power Query の Web 編集」機能 は、Power BI サービスからインポートモデルを編集できるようになるという大きな発表でした。
Power BI 製品チームの最終的な目標は、Power BI Desktop と Web（Power BI サービス）での作成体験を同一化することにあります。その中で、Web 上でインポートモデルの ETL 部分（Power Query）を直接編集できるようになったのは、この目標に近づくための重要なマイルストーンです。

あまり知られていないことですが、初めてのインポートモデルを Power BI Desktop を使わずに、Fabric Portal＝Power BI サービスから直接作成することも可能になっています。
今回は、その具体的な手順をご紹介します。

Power BIがさらに賢く進化: Copilot ToolingとStandalone Copilot ③

少し間が空きましたが、前回（①、②）の続きになります。Copilot を Fabric ポータル上で直接活用できる「Standalone Copilot」（別名「CWYD: Chat with your data」）の体験方法についても詳しくご紹介します。従来の Power BI Desktop とは異なる操作性を持ち、Web 上で手軽に「データと会話できる」体験を実現するこの機能は、データ利用者のアクセシビリティと直感的な分析体験を大きく向上させます。

これらの新機能を組み合わせることで、Copilot の活用は“試験的な利用”から“業務に根ざした活用”へと進化することが期待できます。今回のブログでは、設定方法・活用シナリオ・注意点を含めて、CWYD の実践的な使い方をわかりやすく解説していきます。
※ Copilot の用語

Power BI レポート最適化の実践Tips

前回はスタースキーマを使用した場合にレポートのパフォーマンスがかえって悪化するという、特殊な事例をご紹介しました。今回はその続編として、「クエリ最適化・ドリルスルー・ビジュアルの制限・削減による実践的アプローチ」を実践することで、レポートのパフォーマンスをさらに改善するためのコツについてご紹介します。

今回のテーマは、以下の 3 点です：

1. 高カーディナリティ時のDAX メジャーの作成
2. Query Reduction（クエリの削減）設定の活用
3. ドリルスルーの活用によるパフォーマンス制御

今回ご紹介する内容は、全体として「気を付けるべきポイント」や「実践的なTips」の紹介となりますが、特にデータ量の多いレポートを作成する際に有効なベストプラクティスでもあります。実際のレポート設計やチューニング時にぜひ念頭に置いていただければと思います。
※注：本ブログでは説明に多数の GIF 動画を使用しています。ネットワーク速度が遅い環境では、GIF の読み込みに時間がかかる場合があります。