Microsoft Foundry Agent ServiceからFabric IQを呼び、企業ontology、Fabric data agent、Power BI semantic modelへ自然言語で問い合わせられるpreviewが公開されている。三つは同じ「Fabric IQ」として見えるが、endpoint、同期・非同期、private network、必要permissionが異なる。データを一括接続するのではなく、質問の種類とgovernanceに合うitem typeを選ぶ必要がある。
何が変わったか
Foundry agentへfabric_iq_preview toolを追加し、Fabric IQをserver-side toolとして呼び出せる。ontologyではNL2Ontologyが業務用語を構造queryへ変換し、data agentは会話型Q&A、Power BI semantic modelはmeasureとhierarchyを使った分析を返す。すべてsigned-in user contextで動き、Fabric permissionとgovernance policyを尊重する。
変更前後の差
従来はOneLake table、Power BI、独自semantic layerごとにconnectorとpromptを作る必要があった。Fabric IQは公開済みitemをMCP endpointとして接続し、business vocabularyを介してAgentへ提供する。一方、ontology・data agent・Power BIでserver URL patternとnetwork supportが異なるため、単一の共通設定では扱えない。
誰に影響するか
顧客、注文、製品などのontologyを整備するdata team、Power BI指標を自然言語で提供するBI team、業務Agentを作る開発teamが対象となる。利用者にも対象Fabric itemへアクセスできるlicense・permissionが必要で、未published itemはendpointから利用できない。
期限
強制導入期限はない。public previewでSLAがなく、本番推奨ではない。region availability、workspace region、Foundry region、private link要件を確認し、限定dataで評価する。
必要な対応
まずontology、data agent、Power BIのどれを使うか決める。data agentだけがbackground modeによるlong-running operationを利用でき、ontologyとPower BIは同期tool timeoutの影響を受ける。OBO認証を構成し、item typeに応じてItem.Execute.All、Item.Read.All、DataAgent.Execute.Allなどのdelegated permissionとadmin consentを設定する。
実装・移行手順
- 質問をentity探索、data agent Q&A、BI measureへ分類する
- 対象Fabric itemをpublishし、workspace・item IDを記録する
- item typeに合うMCP server URLを取得する
- BYO Entra appまたはmanaged OAuthを構成する
- Foundry connectionとFabric IQ toolを追加する
- permission trimmingとuser別結果を試験する
- data agentの長時間queryはbackground modeで検証する
- private link・region・trace保存を確認して段階展開する
失敗しやすい点
unpublished itemへ接続する、workspace IDとitem IDを取り違える、data agent以外でもbackground modeが使えると考える、Power BI semantic modelをprivate linkで利用できると想定する、user consent未完了のCONSENT_REQUIREDをsystem障害とみなす、といった問題がある。ontologyのentity・property・bindingが不完全なら、Agent側promptだけでは品質を直せない。
リスク
不完全なontologyやmeasure定義が、もっともらしい誤回答を生む。Foundry projectとFabric workspaceが別regionの場合のcross-region response、client secret管理、広すぎるdelegated permission、長時間queryの費用も考慮する。Agentが結果を別storeへ保存する場合はFabricの元permission境界を引き継げない可能性がある。
評価方法
- business questionの正答率
- ontology entity・propertyへの解決率
- Power BI measure一致率
- permission外data露出がゼロであること
- 同期timeout・background完了率
- user consent error率
- item type別P95 latencyと費用
ロールバック
Agent versionからFabric IQ toolを外し、connectionを無効化する。Entra appのconsentやsecretを失効し、公開item自体はBI利用へ残す。品質問題がontology由来なら旧versionへ戻し、Agent promptだけをrollbackして完了としない。
編集部分析
Fabric IQ接続の成否はmodelよりsemantic layerの品質に左右される。自然言語endpointが追加されても、entity、relationship、measure、permissionが曖昧なら結果は安定しない。Agent projectとdata projectで責任を分けず、評価datasetとontology変更を同じrelease processへ入れることが重要である。
実務チェックリスト
- [ ] 利用するFabric item typeを選定した
- [ ] itemをpublishした
- [ ] server URLとpermissionをitem別に確認した
- [ ] OBOとadmin consentを構成した
- [ ] background modeの対象を限定した
- [ ] private link・region差を確認した
- [ ] ontology・measureの回帰評価を用意した