Microsoft FabricのFabric IQ (preview)は、OneLake上のデータを「業務で使う言葉」に合わせて整理し、Power BI、AIエージェント、アプリケーションが同じ意味でデータを扱えるようにする新しいワークロードです。単なる新機能の追加ではなく、データモデル、セマンティックモデル、グラフ、エージェント、計画業務をつなぐ“意味の共通基盤”として捉えると理解しやすいでしょう。公式情報では、Fabric IQはプレビュー機能であり、運用環境に広く展開する前に、テナント設定、容量、権限、ガバナンス、既存Power BIセマンティックモデルとの整合性を確認する必要があります。(Microsoft Learn)
特に管理者は「機能を有効化すればすぐ使える」と考えるのではなく、Ontology、Graph、Plan、Data agent、Operations agent、Copilot/Azure OpenAI関連設定まで含めて段階的に展開することが重要です。開発者やBI担当者は、既存データを移すかどうかよりも、Customer、Order、Asset、KPIなどの業務概念をどこで定義し、どのデータソースにひも付けるかを先に決める必要があります。
Fabric IQ (preview)で何が変わるのか
Fabric IQ (preview)の最大の変更点は、Microsoft Fabric上のデータを「テーブル名」や「列名」だけで扱うのではなく、業務上の概念として整理できるようになる点です。公式ドキュメントでは、Fabric IQはOneLake全体のデータを統合し、ビジネスの言語に従って整理し、一貫したセマンティックな意味とコンテキストを持つ分析、AIエージェント、アプリケーションに公開するワークロードと説明されています。(Microsoft Learn)
従来のBIやデータ活用では、部署ごとに「顧客」「売上」「出荷」「在庫」「障害」といった言葉の定義が微妙に異なりがちでした。Fabric IQでは、Ontologyを中心に業務概念、プロパティ、関係性、ルールを定義し、それをPower BIセマンティックモデル、Graph、Data agent、Operations agent、Planと連携させます。これにより、レポート、自然言語Q&A、リアルタイム監視、計画業務が同じ業務語彙を参照しやすくなります。(Microsoft Learn)
| 観点 | 従来のよくある状態 | Fabric IQ導入後に目指す状態 |
|---|---|---|
| 業務用語 | 部署やレポートごとに定義が分かれる | Ontologyやセマンティックモデルで共通定義を持つ |
| データ活用 | BI、分析、AI、業務アプリが別々にデータを解釈する | Power BI、エージェント、アプリが同じ意味でデータを扱う |
| 関係性の分析 | 複雑なJOINや個別実装に依存する | Graphでエンティティ間の関係を探索しやすくする |
| AI活用 | AIがテーブル構造に依存して回答する | 業務概念に基づいてAIエージェントをグラウンディングする |
| 計画・実行 | Excelや個別ツールで計画し、実績と突合する | Planで予算、予測、シナリオをFabric内のデータ基盤と結び付ける |
重要なのは、Fabric IQが「すべてのデータを新しい場所へ移行する機能」ではないことです。OneLake、Lakehouse、Eventhouse、Power BIセマンティックモデル、OneLakeショートカットなどを活用しながら、データの意味と関係性をそろえるための仕組みです。外部の運用データもOneLakeショートカットで参照でき、必ずしもコピーやETLパイプラインの構築を前提にしない点が特徴です。(Microsoft Learn)
Fabric IQに含まれる主要アイテム
Fabric IQ (preview)は、単一の画面や単一の機能ではなく、複数のFabricアイテムをまとめたワークロードです。公式情報では、Ontology、Plan、Graph、Data agent、Operations agent、Power BI semantic modelsがFabric IQの構成要素として挙げられています。また、一部のアイテムはReal-Time Intelligence、Data Science、Power BIなど他のワークロードとも共有されます。(Microsoft Learn)
| アイテム | 役割 | 向いている用途 | 確認すべきポイント |
|---|---|---|---|
| Ontology (preview) | 業務概念、プロパティ、関係、制約、ルールを定義する中核 | 部門横断で「同じ言葉」を使いたい場合 | 業務用語集、キー項目、データバインディング、Graph設定 |
| Plan (preview) | 予算、予測、シナリオ、計画データをFabric内で扱う | Excel中心の計画業務をFabricに寄せたい場合 | Plan作成設定、書き戻し先、既存セマンティックモデルとの接続 |
| Graph (preview) | ノード、エッジ、トラバーサルで関係性を分析する | 影響分析、依存関係、最短経路、サプライチェーン分析 | スキーマ設計、再取り込み、容量消費、対応リージョン |
| Data agent | 自然言語でデータに質問できるQ&Aエージェント | 利用者がSQL、DAX、KQLを書かずに分析したい場合 | データソース権限、読み取り専用、英語運用、Purviewポリシー |
| Operations agent (preview) | リアルタイムデータを監視し、推奨アクションを提示する | 異常検知、業務監視、Teams通知、承認付きアクション | Fabric容量、Teams、作成者権限、Copilot/Azure OpenAI設定 |
| Power BI semantic model | KPI、メジャー、リレーションシップを持つ分析モデル | 既存Power BI資産をFabric IQに活かしたい場合 | 用語、メジャー定義、RLS/CLS、Ontologyとの整合性 |
この表から分かるように、Fabric IQは「AIエージェント用の機能」だけではありません。既存のPower BIセマンティックモデルを活かしながら、Ontologyで業務語彙を統一し、Graphで関係性を扱い、Planで計画業務につなげる構成です。AIはその上で、共通の意味を参照して回答やアクションを行う位置づけです。
管理者が最初に確認すべき設定
Fabric IQ (preview)を試す前に、管理者はMicrosoft Fabricのプレビュー機能としての扱いを理解しておく必要があります。Microsoft Fabricのプレビュー機能は限定的な機能として提供され、別のプレビュー条件が適用され、本番利用を目的としたものではなく、SLA対象外である場合があります。また、プレビュー機能を有効化するにはFabric管理者ロールが必要で、委任されている場合は容量管理者が容量単位で有効化できます。(Microsoft Learn)
テナント設定のチェックリスト
Fabric IQ関連の設定は、1つのスイッチだけで完結しません。利用するアイテムに応じて、以下のように設定を確認します。
| 確認項目 | 目的 | 有効化しない場合の影響 |
|---|---|---|
| Users can create Fabric items | Fabricアイテム作成の基本設定 | Fabricアイテム作成自体が制限される |
| Users can create Ontology (preview) items | Ontologyアイテムの作成 | Ontology作成時にエラーになる可能性がある |
| User can create Graph (preview) | Ontologyに関連するGraphの利用 | 新規OntologyへのアクセスやGraph作成でエラーになる可能性がある |
| Users can create Plan (preview) items | Planアイテムの作成 | Plan作成時にエラーになる |
| Enable Operations Agents (Preview) | Operations agentの作成 | リアルタイム監視エージェントを展開できない |
| Users can use Copilot and other features powered by Azure OpenAI | Copilot/Azure OpenAI系機能の利用 | AIエージェントやCopilot連携が制限される |
| Azure OpenAIへのデータ処理・保存の地理設定 | EU/US以外の容量でAI機能を使う場合の前提 | Data agentやOperations agentで利用条件を満たせない可能性がある |
Ontologyについては、公式ドキュメントで「Enable Ontology item (preview)」と「User can create Graph (preview)」が必要設定として示されています。さらに、OntologyをData agentやOperations agentと組み合わせる場合は、それぞれのエージェント側のテナント設定も確認する必要があります。(Microsoft Learn)
CopilotとAzure OpenAIに関するテナント設定も見落としやすいポイントです。Fabric Copilot設定は「Copilot and Azure OpenAI Service」テナント設定グループで制御され、一部は既定で有効、一部は管理者による有効化が必要です。特に、容量の地理的リージョン、コンプライアンス境界、ナショナルクラウド境界の外でAzure OpenAIにデータを処理または保存させる設定は既定で無効とされています。(Microsoft Learn)
影響範囲：管理者、開発者、BI担当者で見るポイントが違う
Fabric IQ (preview)の影響範囲は、データ基盤チームだけにとどまりません。Power BIの運用、AIエージェントの設計、リアルタイム監視、計画業務、ガバナンスまで関係します。
管理者への影響
管理者は、機能の有効化範囲をいきなり全社に広げず、検証用のワークスペースや特定グループから始めるのが安全です。Fabric IQ関連機能は複数のワークロードにまたがるため、Ontologyだけ有効化しても、GraphやData agentの設定が不足していると想定どおり使えません。
また、GraphやOntologyは容量消費の確認が重要です。GraphはFabric容量を使用し、操作はCapacity Unitを消費します。Graphのドキュメントでは、Graph操作はCPU稼働時間に基づいて課金され、Graphストレージでは最小100GBがプロビジョニングされると説明されています。Ontology側でも、モデリング、ロジック、AI操作、関連するFabric GraphやActivatorなどが容量消費に影響するため、Capacity Metricsアプリで監視する運用を前提にしてください。(Microsoft Learn)
開発者・データエンジニアへの影響
開発者やデータエンジニアは、テーブルを追加する前に「どの業務概念にひも付くデータなのか」を整理する必要があります。Ontologyでは、エンティティ型、プロパティ、リレーションシップを定義し、それをOneLake上のLakehouseテーブル、Eventhouseストリーム、Power BIセマンティックモデルなどにバインドします。データバインディングにより、列、キー、関係が業務概念にマッピングされます。(Microsoft Learn)
注意すべき点は、Graphのスキーマ変更です。Graph in Microsoft Fabricは現時点でスキーマ進化をサポートしておらず、ノード、関係、プロパティの構造を変える場合は、更新後のソースデータを新しいモデルに再取り込みする必要があります。初期設計で「後からプロパティを増やせばよい」と考えすぎると、検証後の再作業が増えます。(Microsoft Learn)
BI担当者への影響
Power BI担当者にとって、Fabric IQは既存セマンティックモデルの価値を高める可能性があります。公式情報では、Power BIセマンティックモデルはFabric IQの構成要素の1つであり、Ontologyはセマンティックモデルから生成したり、用語やKPIの一貫性を保つために連携したりできます。(Microsoft Learn)
ただし、既存のPower BIモデルに曖昧なメジャー名や部門固有の略語が多い場合、AIエージェントやOntologyが意図どおりに解釈できない可能性があります。たとえば「売上」というメジャーが、あるレポートでは税抜、別のレポートでは税込、さらに別のレポートでは返品控除後を意味している場合、Fabric IQ導入前に名称、説明、計算式、利用範囲を整理すべきです。
AIエージェント開発者への影響
Data agentは、自然言語の質問をSQL、DAX、KQLなどに変換し、Fabric上のデータに対して読み取り中心の問い合わせを実行するための仕組みです。公式ドキュメントでは、Data agentはユーザーの権限を使い、Purviewなどのガバナンス制御を尊重し、読み取り専用アクセスを厳格に適用すると説明されています。(Microsoft Learn)
日本語圏で特に注意したいのは、Data agentの言語制限です。公式ドキュメントでは、Data agentは現時点で非英語をサポートしておらず、質問、指示、例示クエリは英語で提供することが推奨されています。日本語の業務利用を想定する場合でも、まずは英語の質問テンプレート、説明文、サンプルクエリで精度検証を行い、日本語UIや社内ドキュメントは補助的に使う設計が現実的です。(Microsoft Learn)
移行・展開時に押さえるべき実務ポイント
Fabric IQ (preview)は、既存のPower BI、Lakehouse、Eventhouse、KQLデータベース、SQL Database、ミラーリング、OneLakeショートカットなどを置き換えるというより、それらの上に業務意味のレイヤーを加える考え方に近いです。移行時は、既存資産を一括で作り直すのではなく、意味のブレが大きい領域から小さく検証するのが適しています。
まず既存の業務用語とKPIを棚卸しする
最初にやるべきことは、Ontologyを作ることではなく、業務用語の棚卸しです。たとえば営業領域なら、次のような項目を一覧化します。
- 顧客、取引先、請求先、出荷先の違い
- 売上、受注、粗利、返品、値引きの定義
- KPIごとの計算式と対象期間
- 部署ごとに異なる呼び方をしている項目
- Power BIセマンティックモデルで既に定義されているメジャー
この棚卸しをせずにOntologyを作成すると、既存の曖昧さをそのままFabric IQに持ち込むことになります。結果として、AIエージェントがもっともらしいが業務的には誤った回答を返すリスクが高まります。
Power BIセマンティックモデルは“移行元”ではなく“意味の資産”として扱う
Power BIセマンティックモデルが整備されている組織では、それをFabric IQの出発点にするのが現実的です。既存モデルにKPI、階層、リレーションシップ、DAXメジャーがあるなら、Ontologyと整合させることで、レポート、AIエージェント、計画業務で同じ用語を使いやすくなります。公式情報でも、Ontologyとセマンティックモデルを組み合わせることで、Customer、Shipment、Breachのようなエンタープライズ概念を一度定義し、用語やKPIの一貫性を保つ用途が示されています。(Microsoft Learn)
一方で、部門ごとに独自のPower BIモデルが乱立している場合は、いきなり全モデルをOntology化しない方が安全です。まずは共通KPIが多い1領域、たとえば売上管理、在庫管理、設備監視などから始め、定義の衝突を洗い出してください。
Graphは関係性が価値になる領域から使う
Graphは、すべてのデータに必要なわけではありません。公式ドキュメントでは、Graphは影響チェーン、コミュニティ、最短パスのような関係性の強い質問や、グラフネイティブなパフォーマンスが必要な場合に向いているとされています。(Microsoft Learn)
向いている例は、サプライチェーン、設備とセンサー、顧客接点、ID管理、障害影響分析です。たとえば「温度異常が発生したセンサーに関係する出荷ロットと顧客を追跡する」「ある部品不良が影響する製品、倉庫、販売チャネルをたどる」といった用途では、Graphの価値が出やすくなります。
逆に、単純な売上集計や月次レポートだけなら、Power BIセマンティックモデルの整備を優先した方が早い場合があります。
PlanはExcel置き換えではなく、計画と実績を結ぶ用途で考える
Plan (preview)は、予算、予測、シナリオなどの計画をMicrosoft Fabric内で作成、管理、分析するためのEPM/CPM領域の機能です。公式情報では、PlanはPlanning、PowerTable、Intelligenceを統合し、既存の計画ツールやスプレッドシート中心のワークフローを減らし、目標、計画、実績を共有セマンティックモデル上で結び付けることを目的としています。(Microsoft Learn)
ただし、Excelのすべての自由度をそのまま移すという発想は危険です。Planに向いているのは、部門別予算、需要予測、販売計画、シナリオ比較、計画対実績分析のように、統制されたデータ構造と承認・監査が重要な業務です。属人的なExcelファイルを単純にFabricへ持ち込むのではなく、入力項目、計算ルール、承認フロー、書き戻し先を先に整理しましょう。
Data agentとOperations agentの展開で注意すること
Data agentは便利ですが、万能の分析担当者ではありません。公式情報では、Data agentは最大5つのデータソースを組み合わせて構成でき、Lakehouse、Warehouse、KQL database、Power BI semantic model、Ontology、Microsoft Graphなどを対象にできます。一方で、PDF、DOCX、TXTのような非構造化データはサポート外であり、LakehouseのCSVやJSONファイルも、テーブルとして取り込むか公開しない限り直接読むわけではありません。(Microsoft Learn)
また、Data agentの回答は完全なデータ抽出ではなく、会話型の洞察を目的としています。公式ドキュメントでは、回答の行数・列数に上限があり、現在は最大25行・25列に制限されると説明されています。大量データのダウンロードや完全な明細出力をData agentに任せるのではなく、集計、要約、KPI確認、探索的な質問に使うのが適切です。(Microsoft Learn)
Operations agent (preview)は、リアルタイムデータを監視し、推奨アクションを提示する用途に向いています。前提条件として、Microsoft Fabric対応容量のワークスペース、EventhouseまたはOntology、Eventhouseを使う場合のKQL database、Microsoft Teamsアカウント、Operations agent previewとMicrosoft Copilot/Azure OpenAIに関する管理者権限が必要です。Trial容量はサポートされないため、検証環境でも容量要件を確認してください。(Microsoft Learn)
さらに重要なのは権限です。Operations agentは作成者の委任IDと権限で動作し、受信者が推奨アクションを承認した場合でも、作成者の権限を使って実行されます。業務アクションを自動化する前に、作成者アカウント、承認者、実行権限、監査ログの設計を明確にする必要があります。(Microsoft Learn)
失敗しやすいポイントと対策
Fabric IQ (preview)は概念として魅力的ですが、プレビュー段階であることも踏まえ、PoCの設計を誤ると「便利そうだが使いどころが分からない」「容量消費が読めない」「AIの回答が安定しない」といった状態になりやすいです。
| 失敗しやすいポイント | 起きること | 対策 |
|---|---|---|
| テナント設定を部分的にしか有効化していない | OntologyやGraph作成時にエラーになる | Ontology、Graph、Plan、Data agent、Operations agent、Copilot設定を用途別に確認する |
| 用語定義を決めずにOntologyを作る | 部署ごとの定義差がそのまま残る | 主要KPIと業務用語を先に棚卸しする |
| Graphを安易に全データへ適用する | スキーマ再設計や容量消費が増える | 関係性分析が価値になる領域に絞る |
| Data agentに日本語で複雑な質問を投げる | 期待した回答精度にならない | 英語の指示、説明、サンプル質問で検証する |
| Operations agentの権限を軽視する | 作成者権限で想定外のアクションが実行される | 作成者、承認者、実行権限、監査を事前に決める |
| いきなり本番業務に組み込む | 仕様変更や制限に影響される | プレビュー機能として限定範囲のPoCから始める |
| Capacity Metricsを見ていない | GraphやOntologyの容量消費を把握できない | 容量管理者がCapacity Metricsアプリで継続監視する |
特にコストと容量は、検証段階から見える化しておくべきです。Ontologyでは、モデリング、ロジック、AI操作、関連Fabricアイテム、Graph refreshなどが容量消費に影響します。公式情報では、Graph refreshのスケジュールも容量使用に寄与し、使用量が高い場合はGraphアイテムのスケジュールを編集または無効化できると説明されています。(Microsoft Learn)
どのアイテムから使うべきか
Fabric IQ (preview)を導入する際は、最初からすべてのアイテムを使う必要はありません。目的に応じて、入口を選ぶのが現実的です。
| 目的 | 最初に見るべきアイテム | 判断基準 |
|---|---|---|
| 部門横断でKPIや業務用語を統一したい | Ontology | 複数部門で同じ概念の定義が揺れている |
| 複雑な関係性や影響範囲を分析したい | Graph | JOINよりも経路、依存関係、接続関係が重要 |
| 既存Power BI資産をAIや計画に活かしたい | Power BI semantic model + Ontology | 既に信頼できるメジャーや階層がある |
| 自然言語でデータに質問したい | Data agent | 利用者がSQL、DAX、KQLを書かずに確認したい |
| リアルタイム監視から推奨アクションにつなげたい | Operations agent | EventhouseやOntologyのデータを監視してTeams通知や承認に進めたい |
| 予算・予測・シナリオ管理をFabricで扱いたい | Plan | 計画と実績を同じデータ基盤で分析したい |
公式ドキュメントでも、Ontologyはクロスドメインの整合性、ガバナンス、AI/エージェントの基礎が必要な場合、Graphは関係性の多い質問が意思決定を左右する場合、Power BIセマンティックモデルは信頼できるKPIと高速なビジュアルが必要な場合に向くと整理されています。(Microsoft Learn)
まず取るべきアクション
Fabric IQ (preview)を検討する企業は、まず全社展開ではなく、1つの業務ドメインを選んで検証するのが現実的です。おすすめは、既存のPower BIセマンティックモデルがあり、業務用語の定義差が課題になっていて、AIエージェントや関係性分析の効果を測りやすい領域です。
最初のステップは次の順番で進めると失敗しにくくなります。
- 対象業務を1つに絞る
売上管理、在庫管理、設備監視、サプライチェーンなど、関係者とKPIが明確な領域を選びます。 - 業務用語とKPIを整理する
Customer、Order、Asset、Revenueなど、主要概念と定義、計算式、既存Power BIモデルでの表現を一覧化します。 - 管理者設定を確認する
Ontology、Graph、Plan、Data agent、Operations agent、Copilot/Azure OpenAIのテナント設定を、利用シナリオに応じて有効化します。 - 小さなOntologyを作る
いきなり全社用語集を作らず、数個のエンティティ型、プロパティ、リレーションシップから始めます。 - 既存データにバインドする
Lakehouse、Eventhouse、Power BIセマンティックモデルなど、すでに品質が確認されているデータから接続します。 - GraphまたはData agentで効果を検証する
関係性分析が重要ならGraph、自然言語Q&Aが重要ならData agentで、実務に近い質問を使って検証します。 - 容量、権限、監査を確認する
Capacity Metrics、Purview、RLS/CLS、作成者権限、Teams通知、承認フローを確認してから展開範囲を広げます。
Fabric IQ (preview)は、Microsoft Fabric上のデータ活用を「データを集める」段階から「同じ意味で判断する」段階へ進めるためのワークロードです。現時点ではプレビュー機能であり、制限や仕様変更の可能性を前提に、管理者設定、容量監視、既存セマンティックモデルとの整合性を丁寧に確認する必要があります。まずは小さな業務領域でOntologyと既存Power BIモデルを接続し、GraphまたはData agentで実務上の効果を測ることから始めるのが、もっとも堅実な進め方です。
コメント