Microsoft は 2026年4月10日ごろに確認できる最新のドキュメント更新で、Microsoft Fabric データ エージェントの作成ガイダンスを見直しました。Learn の公開ページ自体は 2026年3月31日更新表示ですが、GitHub の履歴では 4月9日 UTC に追補コミットが入っており、日本時間では 4月10日相当の更新として追えます。(Microsoft Learn)
結論から言うと、今回の更新で重要なのは、Microsoft Fabric データ エージェントを「自然言語でデータに質問できる便利機能」ではなく、Purview ポリシー、最小権限、監査、共有設計の上で動く統制済みの会話型分析レイヤーとして扱うべきだと、Microsoft がより明確に打ち出した点です。公式ガイドでは、Fabric データ エージェントが一般提供機能であることの明確化に加え、Purview の DLP やアクセス制限、読み取り専用の実行、権限境界、運用監督まで説明が厚くなっています。(GitHub)
この記事では、Microsoft がファブリック データ エージェント作成ガイダンスを更新した意味を、単なる要約で終わらせず、実務で何を変えるべきかまで整理します。
今回の更新で先に押さえるべきポイント
- Fabric データ エージェントは Microsoft Fabric の一般提供機能として位置付けられ、より広い agentic application architectures の中で、conversational analytics component として説明されています。つまり、データ サイエンス部門だけの話ではありません。(GitHub)
- Purview の DLP やアクセス制限ポリシーは、エージェントの回答可否や回答内容そのものに影響します。答えが出ないのは不具合ではなく、ポリシーどおりの動作である可能性があります。(Microsoft Learn)
- Power BI semantic model は、Fabric データ エージェントを直接使うシナリオでは Read 権限で利用でき、workspace access や Build 権限は不要と明記されました。RLS/CLS も継続適用されます。(Microsoft Learn)
- 一方で、Foundry Agent Service 経由のドキュメントでは、semantic model に Build 権限を求める記述があります。利用シナリオごとに権限要件を読み分けないと、実装時に食い違います。(Microsoft Learn)
Microsoft がファブリック データ エージェント作成ガイダンスを更新して見えた変化
今回の追補自体は、GitHub 履歴を見ると「一般提供機能であることの明確化」が中心です。ただし、実務上のインパクトが大きいのは、その少し前に続けて入った一連の更新です。履歴には、Purview ガバナンスの追加、governance and intent layers の追加、semantic model 権限の見直し、operational oversight の追加が並んでおり、ガイドの重心が「作り方の説明」から「統制された運用の説明」へ移ったことが分かります。(GitHub)
便利なQ&A機能から、企業向けの分析インターフェースへ
公式コンセプトでは、Fabric データ エージェントは OneLake 上のデータに自然言語で質問できる仕組みであるだけでなく、より広い agentic application architectures における会話型分析コンポーネントとして説明されています。さらに、Microsoft Foundry から呼び出したり、Microsoft 365 Copilot の Agent Store へ公開したり、Copilot Studio の connected agent として組み込んだりできるため、もはやデータ サイエンス部門だけのローカルな機能ではありません。(Microsoft Learn)
「作る」前に「統制する」が前提になった
最新のガイドでは、作成手順の前段に Governance prerequisites が置かれ、Purview ポリシーの下でエージェントが動くことが明示されています。さらに、運用面では Logging and audit、Human-in-the-loop escalation、Periodic review が推奨事項として追加されました。つまり、これからの Fabric データ エージェントは、精度だけ見て公開するものではなく、誰が、どのデータに、どの条件で、どのように質問できるかまで含めて設計する対象です。(Microsoft Learn)
Fabric データ エージェントがデータ サイエンスだけでなく、セキュリティとガバナンスの議論に参加する理由
回答品質だけでなく、回答可否がポリシーで決まるから
Fabric データ エージェントは、Purview の DLP ポリシーやアクセス制限ポリシーの影響を受けます。公式ドキュメントには、ポリシーの適用によりクエリが走らない、結果が一部しか返らない、そもそも特定のデータ ソースへアクセスできない場合があると書かれています。現場では「AI が不安定」と誤解されやすい部分ですが、実際には統制が効いているから止まるケースがあるわけです。(Microsoft Learn)
ユーザー権限のまま動くので、最小権限設計がそのまま品質に効くから
データ アクセスは Microsoft Entra ID のユーザー ID と既存のデータ権限に基づいて行われ、エージェントは読み取り専用で動作します。さらに、ガードレールにより、設定した範囲外のデータ ソースへは触れないよう制約されます。つまり Fabric データ エージェントは、魔法の裏口ではなく、既存の権限モデルを会話型 UI に持ち込む仕組みです。ここが曖昧だと、権限不足で答えられないか、逆に過剰権限で公開範囲を広げすぎるかのどちらかになりがちです。(Microsoft Learn)
監査、保持、eDiscovery の対象になり得るから
Microsoft は、Purview による risk discovery and auditing、DSPM Data Risk Assessments、Insider Risk Management、Audit・eDiscovery・retention の適用可能性を明記しています。つまり、Fabric データ エージェントの会話は「ただのチャット」ではなく、組織の監査・証跡・コンプライアンスの文脈で見られる対象です。セキュリティ部門が関与すべき理由はここにあります。(GitHub)
他の AI エージェントから呼ばれる前提があるから
Foundry Agent Service では、Fabric データ エージェントを enterprise data へのツールとして利用でき、identity passthrough によってエンドユーザーの権限でデータへアクセスします。Microsoft 365 Copilot では Agent Store から Teams 上で利用でき、Copilot Studio では connected agent として別エージェントに接続できます。会話型分析が他の AI の一部になる以上、セキュリティとガバナンスの話を後回しにはできません。(Microsoft Learn)
権限設計で一番間違えやすいポイント
Fabric で直接使う場合と、外部オーケストレーションで使う場合は分けて考える
Fabric 内でデータ エージェントを直接使う場合、Power BI semantic model は Read 権限で十分で、workspace access や Build は不要です。共有時も RLS/CLS はそのまま効きます。これは、部門横断で「閲覧だけさせたい」ケースではかなり使いやすい変更です。(Microsoft Learn)
ただし、Foundry Agent Service 経由の公式ドキュメントでは、Power BI semantic model に Build 権限を求めています。ここを見落として「Read だけ付けたのに Foundry 連携だけ動かない」というトラブルは十分ありえます。“Fabric 直接利用”と“他サービスからの利用”は別シナリオとして権限表を分けるのが安全です。(Microsoft Learn)
Microsoft 365 Copilot や Copilot Studio に公開する場合も、エージェント本体の共有だけでは足りません。共有先ユーザーは、基になるデータ ソースにもアクセス権が必要です。Microsoft 365 Copilot 側でも、結果は underlying data へのアクセスに基づいて返され、RLS/CLS が尊重されます。(Microsoft Learn)
実務で効く Fabric データ エージェントの作り方
1つのエージェントに何でも詰め込まない
Fabric データ エージェントは最大 5 つのデータ ソースを組み合わせられますが、Microsoft は広すぎる設計を勧めていません。ベスト プラクティスでは、用途ごとに specialized agent を作ること、必要なデータ ソースとテーブルだけに絞ること、1データ ソースあたりのテーブル数は 25 以下を目安にすることが示されています。たとえば「全社売上」「人事問い合わせ」「SOC 分析」を 1 つにまとめるのではなく、役割別に分けたほうが精度も権限管理も安定します。(Microsoft Learn)
名前と用語を整える
Table1、col1、flag のような曖昧な名前は、エージェントの精度を落とします。逆に、CustomerOrders や order_submission_date のように意味が明確な名前は、クエリ生成の成功率を上げます。さらに、「calendar year」と「fiscal year」、「sales」の定義、「NPS」や「MAU」の略語など、社内用語を agent-level instructions や data source instructions へ定義することが重要です。(Microsoft Learn)
指示は「禁止事項」より「正しい振る舞い」を書く
Microsoft のガイドでは、「これをするな」だけでなく、「どう振る舞うべきか」を具体的に書くほうがよいとされています。たとえば「古い給与データを出すな」より、「常に公式給与システムの最新データを使い、不明なら HR へ誘導する」と書くほうが動きが安定します。SQL や KQL の癖が強い質問では、LIKE '%bike%' のような leading words を instruction に含めるのも有効です。(Microsoft Learn)
Example queries を使う場所を間違えない
Example queries は、自然言語の質問と対応する SQL/KQL をセットで与える few-shot です。Lakehouse、Warehouse、Eventhouse KQL Database では使えますが、Semantic model と Ontology では使えません。また、データ ソースごとに最大 100 件まで追加でき、スキーマに対して検証が通ったものだけが使われます。Lakehouse や Warehouse を中心に運用するなら、複雑な join やフィルター条件を例示クエリで教える価値は大きいです。(Microsoft Learn)
Semantic model は「Prep for AI」を主役にする
Power BI semantic model をデータ ソースにする場合は、考え方が少し変わります。DAX 生成ツールは、semantic model の metadata と Prep for AI の設定を使って動き、data agent 側の instructions は DAX 生成には渡されず無視されます。つまり、semantic model の AI data schema、verified answers、synonyms、measure の整理が本丸です。ここを整えずに data agent 側だけ頑張っても、精度は上がりにくいです。(Microsoft Learn)
特に注意したいのは、duplicate or overlapping measures、曖昧な date field、implicit measures です。たとえば「売上」を意味する measure が Total Sales、Sales Amount、Revenue と複数あると、AI は迷います。semantic model を AI 用に簡素化し、Verified Answers で代表的な質問を固定化したほうが、現場では安定します。(Microsoft Learn)
変更管理と監視を最初から入れる
Fabric データ エージェントには Git integration と deployment pipelines を使った ALM の考え方が用意されており、source control は preview です。加えて、最新ガイドでは logging and audit、human-in-the-loop escalation、periodic review が運用上の要点として明示されました。最初から「検証環境で instruction を更新し、代表質問セットで比較し、監査ログも確認する」流れを作っておくと、本番公開後のトラブルを減らせます。(Microsoft Learn)
日本語環境で見落としやすい制約
日本語圏の実務で特に見落としやすいのが、現時点では非英語をサポートしていないという点です。公式には、質問、instructions、example queries は英語で行うことが推奨されています。日本語 UI でそのまま全社展開する前に、まずは英語ベースで運用評価する前提を置いたほうが無難です。(Microsoft Learn)
また、Fabric データ エージェントは会話型インサイト向けであり、完全なデータ抽出用途ではありません。応答は 最大 25 行 × 25 列に制限され、チャット履歴の影響で後続の回答が偏ることもあるため、一覧取得や検証用途には向きません。大量データを返したいなら、Warehouse、Lakehouse、Power BI レポートなど別の導線を用意すべきです。(Microsoft Learn)
さらに、PDF、DOCX、TXT のような非構造化データは直接扱えず、Lakehouse でも CSV や JSON をそのまま読むのではなく、テーブルとして取り込まれていることが前提です。会話履歴は常に永続化されるわけではなく、バックエンド変更やモデル更新で失われる可能性もあります。加えて、データ ソースの workspace capacity と data agent の capacity が異なるリージョンにあると実行できません。(Microsoft Learn)
導入前に現実的にやるべきこと
最初の1本は、用途を絞って小さく始める
最初から全社向けの万能エージェントを作るより、1部門・1ユースケースに絞るほうが成功しやすいです。たとえば「営業会議用の売上確認」「セキュリティ運用向けの KQL 問い合わせ」「経営会議前の KPI 確認」など、利用者、使うデータ、答えるべき質問を限定すると、権限も instruction も作りやすくなります。これは Microsoft の specialized agents と scope 最小化の考え方にも合っています。(Microsoft Learn)
権限表を、利用シナリオ別に分けて作る
最低限、次の 3 パターンは分けて確認すると事故が減ります。
- Fabric で直接使う
semantic model は Read 権限中心で考え、RLS/CLS の効きを確認する。(Microsoft Learn) - Foundry など別エージェントから呼ぶ
semantic model の権限要件が direct use と異なる可能性があるため、接続先ドキュメントを別途確認する。(Microsoft Learn) - Microsoft 365 Copilot / Copilot Studio に配る
公開済みエージェントであること、同一テナント要件、共有先が underlying data にもアクセスできることを確認する。(Microsoft Learn)
semantic model を使うなら、先に Prep for AI を整える
Power BI semantic model を中心に使うなら、エージェント作成より前に Prep for AI を整えるほうが先です。AI data schema を絞り、Verified Answers を入れ、measure の重複を減らし、名前をビジネス用語に寄せる。この順番を逆にすると、いくら data agent 側を微調整しても効果が薄くなります。(Microsoft Learn)
公開前テストでは「失敗ケース」も確認する
公開前に見るべきなのは、正しい質問で正しく答えるかだけではありません。権限がないときに何が起きるか、機密データに触れる質問でどう止まるか、想定外のプロンプトでどこまで拒否できるかも確認すべきです。今回の更新が示しているのは、Fabric データ エージェントの品質評価には、精度テストとガバナンステストの両方が必要だということです。(Microsoft Learn)
まとめ
今回の Microsoft による Fabric データ エージェント作成ガイダンス更新が示したのは、Fabric データ エージェントの価値が「SQL や DAX を書かずに聞ける」ことだけではなく、governed data を会話インターフェースとして安全に配ることにある、という点です。Purview ポリシー、最小権限、RLS/CLS、監査、ALM、Prep for AI まで含めて初めて、運用に耐えるデータ エージェントになります。(GitHub)
次にやるべきことは明確です。まず 1 つの部門ユースケースを選び、データ ソースを絞り、利用シナリオ別の権限表を作り、semantic model を使うなら Prep for AI を先に整える。そのうえで、正常系だけでなくポリシー違反や権限不足の失敗系も試してから公開すると、Fabric データ エージェントを「便利だけど危ない機能」にせず、「統制された分析基盤の一部」として育てやすくなります。(Microsoft Learn)
コメント