Microsoft Fabric に Ontology という概念が登場しました。Power BI が Business Intelligence である一方、Ontology は Operational Intelligence となります。 Microsoft Fabric では、Fabric IQ ワークロードの一部として Ontology アイテムが提供されています (2026年5月時点ではPreview)。Ontology は、企業内の業務用語、エンティティ、プロパティ、関係、ルールを定義し、OneLake 上のデータや Power BI セマンティックモデル、AI agent、Real-Time Intelligence と接続するための共有ビジネスコンテキスト層です。
ただ、正直なところ、最初にドキュメントを読むとかなり難しく感じます。
このような単語が一気に出てくるため、Power BI を中心に扱ってきた人にとっては、
「これは Power BI のセマンティックモデルと何が違うのか？」
「テーブルや列とどう関係するのか？」
「AI Agent と何が関係あるのか？」
が分かりにくいと思います。
この記事では、Ontology を Power BI ペルソナ向け に、できるだけ分かりやすく整理します。
続きを読む前回のブログでは、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 で得られた学びをもとに考察していきます。
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回に分けて紹介することにします。また、結果だけ知りたい方は、「パフォーマンス比較」を直接ご覧ください。
2025年の Power BI は、10歳の誕生日を迎えただけでなく、これまで以上に “変革の年” でした。新機能の登場、機能の廃止、AI 活用の急速な進展、そして Fabric 時代を見据えた大規模なアーキテクチャ転換等がありました。この1年を一言で表すなら、まさに 「Power BI が BI を超えて、Intelligence Platform へと歩み始めたターニングポイント」 と言えるでしょう。
本記事では、2025年に発表・提供された Power BI / Fabric の新機能、廃止されたサービス、Power BI の製品開発チームによる最新知見、日本企業の導入傾向、そして今後のロードマップを踏まえ、1年の動きを総整理していきたいと思います。
前回 は Fabric 容量、スケール Out/Up 等に関する基礎的な概念について紹介をしましたが、今回は以下の通りの内容について解説をしていきます。
Power BI Desktop や Power BI Pro / PPU をメインで活用するPower BI ペルソナは Fabric 容量を意識する必要はないですが、Fabric 機能を含む高度な機能を使用する必要がある場合、あるいは OneLake を中心にデータ活用をする必要がある場合、Fabric 容量に関してある程度しっかり把握しておくことが推奨されます。
続きを読む今回は、Microsoft Fabric を本気で使おうとすると必ずぶつかるテーマ、「Fabric 容量の仕組み」 について、少し腰を据えて整理してみます。まずは Fabric 容量とは何か？からスタートし、Fabric の PoC や本番導入をする際の下記の会話に深堀していきます。
これらの概念は混乱しやすいため、分かりやすく嚙み砕いて紹介していきたいと思います。
続きを読む今回のタイトルは前回とは異なりますが、内容としては続編になります。今回は、私がスピーカーとして参加した某大手企業のPower BI 社内ワークショップで実施されたアンケートを題材に、得られたフィードバックをAI と組み合わせて活用するとどのような分析が可能になるのかを見ていきたいと思います。
アンケート調査は、組織が顧客や社員の声を把握し、改善の方向性を導き出すために欠かせない取り組みです。しかし、その結果を分析するとなると、Excel や BI ツールを使って集計を行い、グラフを作り込み、さらにインサイトを抽出するまでに多くの工数がかかります。このプロセスは労力がかかる一方で、「いま知りたいことを、もっと直感的に聞けたら…」 というニーズはますます高まっています。
そこで登場するのが、Microsoft Fabric における Standalone Copilot（Chat with your data、以下 CWYD） です。CWYD は、準備済みのセマンティックモデルをもとに「会話形式でデータに質問」し、結果を即座に返してくれる仕組みです。アンケートのように回答数が多く、設問の粒度も多岐にわたるデータを対象にすると、その効用は一層大きくなります。
本記事では、実際に Power BI のアンケート分析モデルを CWYD で扱ってみた事例を紹介し、従来の集計とどう違うのか、どのようなプロンプトを投げると効果的かを探っていきます。
過去記事（①、②、③）
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 サービスから直接作成することも可能になっています。
今回は、その具体的な手順をご紹介します。
