「Fabric IQ documentation – Microsoft Fabric」の更新でまず押さえるべき点は、Fabric IQが単なる新機能ではなく、Microsoft Fabric上のデータを“業務用語・関係性・ルール”でつなぎ、AIエージェントや分析、計画業務に使えるようにするワークロードとして整理されていることです。管理者はテナント設定、GraphやOntologyの有効化、Copilot/Azure OpenAI関連のデータ処理設定を確認し、開発者やBI担当者は既存のPower BIセマンティックモデル、OneLake上のデータ、キー設計、更新運用を見直す必要があります。(Microsoft Learn)
Fabric IQ documentation – Microsoft Fabricで何が変わるのか
今回確認すべき変更は、Fabric IQが「ナレッジグラフ」「オントロジ」「Graph」「Data agent」「Operations agent」「Power BIセマンティックモデル」「Plan」といった複数の要素を組み合わせる領域として整理されている点です。公式ドキュメントのランディングページでは、Fabric IQ、Ontology、Microsoft 365 Copilot Cowork連携、Graph、GQL、Graph REST APIなどへの導線がまとめられています。(Microsoft Learn)
ドキュメントリポジトリ上では、Fabric IQのランディングページで「Connectors」カードを「Integrations」に変更し、配置を見直す更新も確認できます。これは表記上の小さな変更に見えますが、Fabric IQを単なる接続機能ではなく、Copilotや業務プロセス、Graph、Ontologyと連携する統合領域として扱う方向性を示す変更と見てよいでしょう。(GitHub)
また、Fabric IQ配下のPlan関連では、Planアイテムで複数ユーザーのコラボレーションを有効にするためのFabric SQL接続作成ドキュメントが2026年5月20日に更新されています。Planを使う場合は、OntologyやGraphだけでなく、SQL接続、共有権限、書き戻し、コラボレーションデータの保管先も確認対象になります。(Microsoft Learn)
Fabric IQとは何か：業務用語でデータを扱うための共通レイヤー
Fabric IQは、OneLake上のデータを業務の言葉に沿って文脈化し、分析、AIエージェント、アプリケーションへ一貫した意味を渡すためのMicrosoft Fabricワークロードです。公式ドキュメントでは、Ontology、Plan、Graph、Data agent、Operations agent、Power BIセマンティックモデルなどがFabric IQを構成するアイテムとして説明されています。(Microsoft Learn)
特に重要なのがOntologyです。Ontologyは、Customer、Product、Order、Shipment、Sensorのような業務概念を「エンティティ型」として定義し、プロパティやリレーションシップを通じて意味を統一します。そのうえで、OneLake、Lakehouse、Eventhouse、Power BIセマンティックモデルなどの実データにバインドし、人間とAIエージェントの両方が同じ業務語彙でデータを扱えるようにします。(Microsoft Learn)
従来のBIでは、部署ごとに「顧客」「売上」「案件」「解約」の定義が微妙に違い、レポートやKPIの解釈がずれることがよくあります。Fabric IQの狙いは、この定義のずれをOntologyとGraphで整理し、Power BIレポート、自然言語クエリ、AIエージェント、業務アクションまで同じ文脈でつなぐことです。
影響を受ける対象者と確認ポイント
Fabric IQの影響範囲は、Fabric管理者だけに限られません。Power BIのセマンティックモデルを管理するBI担当者、LakehouseやEventhouseを扱うデータエンジニア、AIエージェントを作る開発者、予算・計画業務を扱う業務部門まで関係します。
| 対象者 | 影響する主な領域 | まず確認すること |
|---|---|---|
| Fabric管理者 | テナント設定、容量、リージョン、Copilot/Azure OpenAI設定 | Ontology、Graph、Data agent、Planの作成権限を誰に許可するか |
| Power BI管理者・BI開発者 | セマンティックモデル、KPI、RLS、Build権限 | 既存モデルからOntologyを生成できるか、テーブルやリレーションが整っているか |
| データエンジニア | OneLake、Lakehouse、Eventhouse、データ更新 | バインド対象のテーブル形式、キー、データ型、更新タイミング |
| AI/アプリ開発者 | Data agent、Operations agent、GQL、REST API | 自然言語回答やアクション実行の根拠にOntologyを使えるか |
| 業務部門 | 用語定義、計画、予算、予測、承認 | 部門固有の言葉を全社共通の語彙として定義できるか |
Fabric IQはプレビュー機能を多く含みます。特にGraph in Microsoft Fabricはパブリックプレビューとして提供されており、運用前にはリージョン、容量消費、制約を確認する必要があります。(Microsoft Learn)
管理者が最初に確認すべきテナント設定
Ontologyを使うには、Fabricテナントで必要な設定を有効化する必要があります。公式ドキュメントでは、Ontology itemの作成設定と、Ontologyに関連するGraph作成設定が必須として示されています。Graph設定が無効な場合、新しいOntologyアイテムへのアクセス時にエラーが出る可能性があります。(Microsoft Learn)
| 設定項目 | 目的 | 注意点 |
|---|---|---|
| Users can create Ontology (preview) items | Ontologyアイテムを作成できるようにする | 全社有効ではなく、最初は検証用セキュリティグループに限定するのが安全 |
| User can create Graph (preview) | Ontologyに関連するGraphを使えるようにする | Graphが無効だとOntology作成後の表示や利用で失敗しやすい |
| Users can create and share Data agent item types | OntologyをData agentのソースとして使う | 自然言語回答の対象範囲と権限設計が必要 |
| Users can use Copilot and other features powered by Azure OpenAI | Data agentやAI機能の利用 | 組織のAI利用ポリシーと合わせて判断する |
| Azure OpenAIへのデータ処理・保存に関する設定 | 容量リージョン外での処理・保存が必要なケースに対応 | EU/US以外の容量では特に確認が必要 |
| Users can create Plan (preview) items | Planアイテムを作成する | Plan利用時はXMLA、Embed、容量、SQL接続も確認する |
Fabric Data agentを利用する場合、CopilotとAzure OpenAI関連の設定が必要です。設定変更は反映まで最大1時間かかる場合があるため、検証スケジュールには余裕を持たせてください。(Microsoft Learn)
開発者・BI担当者が見るべき設計ポイント
既存のPower BIセマンティックモデルから始めるか、OneLakeから直接作るか
Ontologyは、既存のPower BIセマンティックモデルから生成する方法と、OneLake上のデータから手動で作る方法があります。すでに整理されたセマンティックモデルがある場合は、そこからOntologyを生成すると初期構築が速くなります。一方、まだモデルが未整理の場合や、複数データソースを横断して業務概念を再設計したい場合は、OneLakeデータをもとに手動で作る方が向いています。(Microsoft Learn)
判断基準はシンプルです。既存のセマンティックモデルが「業務用語」「リレーション」「KPI」をすでに正しく表しているなら生成から始めます。逆に、レポートごとにテーブル名や指標名がばらついているなら、Ontology設計を先に行い、後からセマンティックモデルやData agentに展開する方が失敗しにくくなります。
エンティティ型とキーを先に決める
Ontologyでは、Customer、Store、Product、SaleEventのようなエンティティ型を作り、各エンティティにプロパティとキーを設定します。エンティティ型のキーは、取り込んだレコードを一意に識別するために使われます。キーが曖昧だと、Graphが疎になったり、Data agentの回答が不安定になったりします。(Microsoft Learn)
実務では、最初に「名詞」を洗い出すのが有効です。たとえば小売なら、Store、Product、Customer、Order、Inventory、Sensorを候補にし、それぞれに業務上の一意キーがあるかを確認します。キーがシステムごとに違う場合は、Ontologyに入れる前にデータ統合やマッピングルールを整理しておくべきです。
データバインドの制約を事前に確認する
Ontologyのデータバインドは、エンティティ型、プロパティ、リレーションシップを実データに接続する機能です。静的データはOneLake上のデータにバインドし、時系列データはOneLakeまたはEventhouseから扱えます。ただし、Lakehouseテーブルには制約があり、OneLake securityが有効なLakehouseや、外部テーブル、列マッピングが有効なDeltaテーブルはバインド時の制約に注意が必要です。(Microsoft Learn)
失敗しやすいのは、先に画面上でOntologyを作ってから、後で「このLakehouseは対象外だった」「キー列が型不一致だった」「列名に特殊文字があり列マッピングが有効になっていた」と気づくパターンです。検証前に、対象テーブル、キー列、データ型、列名、OneLake securityの状態を一覧化しておきましょう。
Graphと更新運用で注意すべきこと
Ontologyアイテムを作成すると、エンティティ型の詳細表示などで使われるGraph in Microsoft Fabricの子アイテムも作成されます。Entity type detailsでは、Configure、Instances、Overviewの各タブを使って、バインド済みデータ、インスタンス、関係性、時系列タイル、Graphビューを確認できます。(Microsoft Learn)
重要なのは、外部データソース側で新しい行が追加・更新・削除されても、Ontology側のGraphが自動的に最新化されるとは限らない点です。Ontologyスキーマの変更時には下流体験が更新されますが、元データの変更はGraphの手動更新やスケジュール更新で反映する必要があります。更新はGraphのフルリフレッシュになるため、頻繁に実行すると容量消費に影響します。(Microsoft Learn)
本番に近い運用を想定するなら、次のように分けて考えると安全です。
| 運用項目 | 推奨する考え方 |
|---|---|
| スキーマ変更 | 開発環境で確認してから本番相当ワークスペースに反映 |
| データ更新 | 日次・時間単位など、業務要件に合う更新頻度を決める |
| Graph更新 | 小さな変更ごとではなく、更新をまとめて実行 |
| 容量監視 | Fabric Capacity Metrics appでGraph関連の使用量を確認 |
| 障害時対応 | 403、Graph未表示、データ欠落、キー不一致を切り分ける手順を用意 |
GraphはGQLやNatural Language to GQLにも対応しており、関係性の多いデータを探索する用途に向いています。ただし、Graphの利用には容量消費やリージョン可用性の確認が必要です。(Microsoft Learn)
Data agentやCopilot連携で変わること
Fabric IQの価値は、データを整理するだけでなく、AIエージェントが業務用語を理解して回答やアクションにつなげられる点にあります。Data agentはOntologyをソースとして追加でき、ユーザーはテーブル名ではなく、Store、Product、Freezerのようなエンティティ名や関係性を使って自然言語で質問できます。(Microsoft Learn)
ただし、Data agentを作成した直後の初回クエリが失敗する場合や、集計がうまくいかない既知の問題も案内されています。公式チュートリアルでは、集計を改善するためにData agentの指示へ Support group by in GQL を追加する手順が示されています。(Microsoft Learn)
Microsoft 365 Copilot Coworkとの連携では、Power BIレポートやその背後のセマンティックモデルを根拠にチャットで質問し、回答をメール作成や文書作成、会議調整などの作業につなげられます。重要なのは、CoworkがPower BIに対してサインインユーザーとしてクエリを実行し、既存のアイテム権限や行レベルセキュリティが引き続き適用される点です。(Microsoft Learn)
Planを使う場合の追加注意点
Fabric IQの文脈では、Planも重要です。Planは、予算、予測、シナリオなどをMicrosoft Fabric内で作成・管理・分析するEPM/CPM領域のプレビュー機能として説明されています。Planning、PowerTable、Intelligenceなどの機能を通じて、過去実績、リアルタイムまたは更新済みデータ、将来予測を同じガバナンス基盤で扱う方向性です。(Microsoft Learn)
Planを使うには、Planアイテム作成のテナント設定だけでなく、XMLAエンドポイント、Embed content in apps、対応容量、セマンティックモデル接続所有者の権限も確認が必要です。Plan作成時にはFabric SQL databaseが自動作成され、Planレポートのメタデータを保存します。(Microsoft Learn)
また、PlanにはMicrosoft Entra B2B ID非対応、Private Link利用環境での非対応、My workspaceに発行されたセマンティックモデル非対応、OAuthベース接続のみ対応などの制約があります。外部ユーザーやPrivate Linkを前提とする組織では、早い段階で導入可否を確認してください。(Microsoft Learn)
移行・展開の進め方
Fabric IQは、既存のBIやデータ基盤を一気に置き換えるものとして導入すると失敗しやすくなります。最初は、業務用語の揺れが大きく、かつ改善効果が見えやすい1領域に絞るのが現実的です。たとえば、販売、在庫、設備監視、サプライチェーン、予算管理などが候補になります。
| ステップ | 実施内容 | 成功条件 |
|---|---|---|
| 1. 対象領域を選ぶ | 売上、在庫、設備、計画など1テーマに絞る | 関係者が共通の業務用語を定義できる |
| 2. 既存資産を棚卸しする | Power BIモデル、Lakehouse、Eventhouse、KPI、RLSを確認 | どのデータをOntologyにバインドするか決まる |
| 3. 管理者設定を限定有効化する | 検証用グループにOntology、Graph、Data agentを許可 | 不要なユーザーにプレビュー機能を開放しない |
| 4. Ontologyを作る | エンティティ、プロパティ、キー、リレーションシップを定義 | 業務用語とデータ列の対応が説明できる |
| 5. GraphとData agentで検証する | 自然言語質問、GQL、Graphビュー、権限を確認 | 回答が業務定義と一致し、不要なデータが見えない |
| 6. 更新・監視を設計する | Graph更新頻度、容量監視、障害時手順を決める | 古いデータや容量超過を検知できる |
| 7. 部門展開する | 用語定義、利用手順、問い合わせ先を整備 | 利用者が「どの質問をどこに投げるか」を理解する |
よくある失敗と対策
| 失敗しやすいポイント | 原因 | 対策 |
|---|---|---|
| Ontologyアイテムを作成できない | 必須のテナント設定が無効 | Ontology、Graph、Data agent関連設定を確認 |
| Graphが表示されない、データが欠ける | キー未定義、列マッピング、外部テーブル、アクセス権不足 | キー、管理テーブル、列名、Lakehouse権限を確認 |
| Entity type detailsで403が出る | バインド元Lakehouseへの権限不足 | 利用者に必要なデータアクセス権を付与 |
| Data agentの回答が曖昧 | Ontologyがソースに入っていない、名前や説明が不十分 | エンティティ名、リレーション名、説明文を業務用語で整備 |
| 集計結果が不安定 | Data agentのGQL集計に関する既知の注意点 | 指示に Support group by in GQL を追加して検証 |
| 元データを更新したのに画面が変わらない | Graph更新が未実行 | Refresh nowまたはスケジュール更新を設定 |
| Planで外部ユーザーが使えない | B2B ID非対応などの制約 | 外部共有前提の業務は別方式を検討 |
トラブルシューティングでは、Ontology作成エラー、セマンティックモデルからの生成失敗、Decimal型のnull、容量超過、Lakehouse未表示、Graph欠落、Data agent作成不可などが具体的に挙げられています。導入時は「画面で試す」だけでなく、これらの既知パターンをチェックリスト化しておくと、検証の手戻りを減らせます。(Microsoft Learn)
まず何から始めるべきか
最初にやるべきことは、Fabric IQを全社展開することではありません。まず、既存のPower BIセマンティックモデルとOneLake上の主要テーブルを棚卸しし、「どの業務用語を全社で共通化したいか」を決めることです。そのうえで、管理者はOntology、Graph、Data agent、Copilot/Azure OpenAI、Planの設定を検証用グループに限定して有効化し、開発者は1つの業務領域でOntologyとGraph更新、Data agent回答、権限継承を確認してください。
Fabric IQは、データ基盤を「保存・分析する場所」から「業務判断とAIアクションにつなげる場所」に近づける機能群です。プレビュー段階の制約を踏まえつつ、小さな業務領域でOntology、Graph、Data agent、Planの関係を検証することが、最も安全で効果の高い第一歩です。
コメント