Microsoft Fabricの「Fabric data agent scenario (preview)」は、AdventureWorksデータセットを使ってFabric data agentを構成し、自然言語で業務データに質問できる状態まで試すための公式チュートリアルです。2026年6月5日時点で実務担当者が押さえるべき結論は、作成手順そのものよりも、テナント設定、Power BIセマンティックモデルの権限、Copilot連携、Notebook/API利用時の運用管理、Preview前提の制限を先に確認することです。対象のMicrosoft Learnページは「preview」と明記され、ページ上の最終更新日は2026-06-04と表示されています。(Microsoft Learn)
Fabric data agentは「AIにデータを読ませる」機能ではなく、Fabric上のlakehouse、warehouse、Power BI semantic model、KQL databaseなど、管理されたデータソースに対して、ユーザー権限に基づきSQL/DAX/KQLなどの読み取りクエリを生成・実行する仕組みです。PoCを始める前に、管理者はCopilot/Azure OpenAI関連のテナント設定を、開発者はデータソースのスコープ、英語の指示文、例示クエリ、公開後の利用経路を整理しておく必要があります。(Microsoft Learn)
Microsoft FabricのAI/Copilot更新で何が変わるのか
今回の「Fabric data agent scenario (preview)」で重要なのは、Fabric data agentを単体のチャットUIとして見るのではなく、Copilotや外部オーケストレーターから利用できる“データ問い合わせ用エージェント”として設計する必要がある点です。
Fabric data agentは、ユーザーの自然言語の質問を受け取り、選択されたデータソースのスキーマ、メタデータ、開発者が設定したinstructionsやexample queriesを使って、適切なクエリを生成します。lakehouseやwarehouseではSQL、Power BIセマンティックモデルではDAX、KQLデータベースではKQLが使われます。(Microsoft Learn)
一方で、何でも答えられる汎用AIではありません。公式ドキュメントでは、複雑な因果分析や高度な機械学習、外部要因を含む根本原因分析は現在の範囲外とされています。たとえば「2023年のカリフォルニアの売上合計は？」のように、構造化データから集計できる質問は向いていますが、「なぜQ2の生産性が落ちたのか？」のような原因分析は、必要なデータや分析ロジックが用意されていない限り期待通りに動きません。(Microsoft Learn)
| 観点 | 公式情報で確認すべきポイント | 実務上の影響 |
|---|---|---|
| データソース | lakehouse、warehouse、Power BI semantic model、KQL database、mirrored database、ontologyなどを対象にできる | どのデータをAIに見せるかを事前に絞り込む必要がある |
| Power BI権限 | data agent経由のセマンティックモデル利用はRead権限が中心。Build権限やworkspaceロールが不要なケースがある | 既存のPower BI配布設計を見直す必要がある |
| Copilot連携 | 公開後、Copilot in Power BIからdata agentを追加して利用できる | 利用者向け展開ではCopilot側のテナント設定も確認が必要 |
| プログラム利用 | Notebookから公開URLを使って呼び出せる | タイムアウト、ポーリング頻度、リソース削除、API移行計画が必要 |
| Preview制限 | 非英語、非構造化データ、完全なデータ抽出用途には制限がある | 日本語圏で使う場合も、指示文・質問・検証は英語中心で設計するのが安全 |
Fabric data agent scenario (preview)の全体像
このシナリオは、AdventureWorksデータセットを使ってlakehouseを作成し、そのlakehouseをFabric data agentに追加して、質問応答を行うまでの流れを説明しています。既にAdventureWorksLHのlakehouseまたはwarehouseがある場合は、データ作成手順を省略できます。(Microsoft Learn)
大まかな流れは次の通りです。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| データ準備 | Fabric notebookでAdventureWorksデータをlakehouseに読み込む | Notebook実行後は不要なセッションを停止する |
| data agent作成 | Workspaceで「Fabric data agent」を新規作成する | 名前は用途が分かるものにする |
| データ選択 | lakehouseを追加し、AIに使わせるテーブルを選択する | 全テーブルではなく、質問に必要なテーブルだけ選ぶ |
| instructions設定 | データソースの意味、使い分け、業務用語を英語で記述する | 曖昧な指示ではなく、ルール化して書く |
| example queries追加 | 質問とSQL/KQLのペアを登録する | スキーマに合う有効なクエリだけを入れる |
| テストと修正 | 実際の質問で結果と生成クエリを確認する | 誤答しやすい質問を重点的に検証する |
| 公開 | 検証後にPublishし、同僚やCopilotから利用できるようにする | 公開版と下書き版の差分管理が必要 |
公式チュートリアルでは、AdventureWorksLHに対してdimcustomer、dimdate、dimgeography、dimproduct、dimproductcategory、dimpromotion、dimreseller、dimsalesterritory、factinternetsales、factresellersalesなどを選択する例が示されています。これは「質問に必要なディメンションテーブルとファクトテーブルを明示的に選ぶ」設計のサンプルとして参考になります。(Microsoft Learn)
管理者が先に確認すべき設定
Fabric容量と基本要件を満たしているか
Fabric data agentを使うには、有償のF2以上のFabric capacity、またはMicrosoft Fabricが有効化されたPower BI Premium per capacityのP1以上が必要です。また、少なくとも1つのデータソースに読み取りアクセスできる状態である必要があります。(Microsoft Learn)
管理者が最初に確認すべきなのは、機能が表示されるかどうかではなく、次の3点です。
| 確認項目 | 見る場所 | 確認すべき理由 |
|---|---|---|
| Fabric capacity | Capacity設定 | F2以上またはP1以上の前提を満たしていないと検証が進まない |
| Microsoft Fabricの有効化 | Power BI Premium容量の設定 | P SKUを使う場合、Fabricが有効でないと対象機能を使えない |
| データソースへのRead権限 | Workspace、lakehouse、warehouse、semantic modelなど | data agentはユーザー権限に基づいてスキーマ参照とクエリ実行を行う |
特にPoC環境では、管理者権限を持つ人だけが動作確認して「使える」と判断してしまいがちです。実際の利用者アカウントで、対象データにRead権限だけを付与した場合にどう動くかまで確認してください。
CopilotとAzure OpenAI関連のテナント設定
Fabric data agentはCopilot/Azure OpenAI関連のテナント設定の影響を受けます。公式ドキュメントでは、Fabric管理者がAdmin PortalのTenant settingsから必要な設定を有効化する必要があると説明されています。また、テナント設定の反映には最大1時間かかる場合があります。(Microsoft Learn)
| 設定 | 確認すべき内容 | 失敗しやすいポイント |
|---|---|---|
| Users can use Copilot and other features powered by Azure OpenAI | CopilotやAgentsを利用可能にする設定 | 容量単位・テナント単位のどちらで制御しているか見落としやすい |
| Capacities can be designated as Fabric Copilot capacities | Copilot用容量として指定できるか | 容量管理者とFabric管理者の役割分担が曖昧だと展開が止まる |
| Data sent to Azure OpenAI can be processed outside your capacity’s geographic region | 対象リージョンがEU/US外の場合に必要になる可能性がある | 日本リージョンなどで検証する場合は特に確認が必要 |
| Data sent to Azure OpenAI can be stored outside your capacity’s geographic region | Copilot in NotebooksやFabric data agentで必要になる場合がある | セキュリティ部門の承認なしに有効化しない |
| Conversation history stored outside your capacity’s geographic region | 会話履歴をセッション横断で保持する場合の設定 | 履歴はユーザーが削除しない場合、最大28日保存されると説明されている |
| Users can access a standalone, cross-item Power BI Copilot experience | Copilot in Power BIからdata agentを使う場合に確認 | data agent側を公開しても、Copilot側の体験が有効でないと利用できない |
Microsoftは、Fabric data agentをMicrosoft Foundry、Microsoft Copilot Studio、Microsoft 365 Copilot、MCP serverなどのFabric外サービスから利用する場合、data agentの応答がFabricのコンプライアンス境界や地理的リージョンの外に送られ、各サービスの条件やデータ処理ポリシーに従って処理・保存される可能性があると注意喚起しています。(Microsoft Learn)
社内展開では、単に「AI機能をオンにする」ではなく、次の承認観点を事前にそろえておくべきです。
- どの部署・グループに利用を許可するか
- どの容量をCopilot/data agent検証用に使うか
- データが地理的境界を越える可能性を許容するか
- 会話履歴の保存を許容するか
- Fabric外サービスとの連携を許可するか
- 監査、eDiscovery、DLPの対象としてどう扱うか
Power BIセマンティックモデルの権限変更が実務に与える影響
今回の内容で特に影響が大きいのは、Power BI semantic modelをFabric data agentから使う場合の権限です。公式ドキュメントでは、data agent経由でセマンティックモデルに質問するユーザーはRead権限があればよく、workspaceアクセスやBuild権限は不要と説明されています。一方で、セマンティックモデルの変更やPrep for AIの利用にはWrite権限が必要です。(Microsoft Learn)
これは、Power BI運用において次のような意味を持ちます。
| 立場 | 影響 | 対応 |
|---|---|---|
| Power BI管理者 | Build権限を広く配らずに、data agent経由のQ&Aを提供しやすくなる | Read権限、RLS、CLSの設計を再確認する |
| Workspace管理者 | 利用者をworkspaceメンバーにしなくても活用できるケースが増える | workspaceロールではなくモデル単位のアクセス管理を整える |
| レポート開発者 | 既存のセマンティックモデルをAI Q&Aの基盤として使いやすくなる | メジャー名、テーブル名、列名、説明を分かりやすく整備する |
| セキュリティ担当 | AI経由でも権限境界が守られるかを検証する必要がある | RLS/CLS、Purviewポリシー、監査ログを確認する |
注意したいのは、このRead権限の扱いはdata agent経由の操作に関するものだという点です。Analyze in Excelやレポート作成など、他のPower BI利用経路では従来通り別の権限が必要になる場合があります。data agentで動くからといって、Power BI全体の権限設計を単純化しすぎないようにしてください。(Microsoft Learn)
開発者が押さえるべき構成ポイント
データソースは「多く追加する」より「質問に必要な範囲に絞る」
Fabric data agentでは、複数のデータソースを組み合わせられます。作成手順の公式ページでは、最大5つのデータソースを追加できると説明されています。対象にはlakehouse、warehouse、Power BI semantic model、KQL database、ontology、Microsoft Graphなどが含まれます。(Microsoft Learn)
ただし、実務では「使えるデータを全部追加する」のはおすすめできません。AIが参照する候補が広がりすぎると、質問に対してどのテーブルやモデルを使うべきか判断しづらくなります。
たとえば営業分析用のdata agentなら、最初は次のように絞ると検証しやすくなります。
| 用途 | 追加するデータ | 追加しない方がよいデータ |
|---|---|---|
| 売上集計 | 売上ファクト、商品、顧客、日付、地域 | 監査ログ、人事データ、未整理の一時テーブル |
| Power BI Q&A | 承認済みのセマンティックモデル | 作成途中のモデル、メジャー定義が不安定なモデル |
| 操作ログ分析 | KQL databaseの主要テーブル | 高頻度ログの全テーブル、用途不明の生ログ |
lakehouseの場合、data agentが直接読むのは選択したテーブルです。CSVやJSONなどのファイルをそのまま読ませるのではなく、テーブルとして取り込むか、テーブルとして公開する必要があります。(Microsoft Learn)
テーブル名と列名はAI向けの説明力を持たせる
公式ドキュメントでは、TableAやC1のような名前より、SalesData、ActiveCustomer、IsCustomerActiveのような説明的な名前が、AIによる正確なクエリ生成に役立つとされています。(Microsoft Learn)
これは地味ですが、実務では非常に重要です。人間の開発者ならER図や設計書を読んで補完できますが、data agentは選択されたスキーマ、メタデータ、instructions、examplesをもとに判断します。列名が短すぎる、略語が部署ごとに違う、同じ意味の列が複数ある、といった状態では誤ったSQLやDAXが生成されやすくなります。
最低限、次の観点で見直してください。
| 見直し対象 | 悪い例 | 改善例 |
|---|---|---|
| テーブル名 | T_SLS01 | SalesOrder |
| 顧客状態 | Flg1 | IsActiveCustomer |
| 金額 | Amount | SalesAmountJPY |
| 日付 | Date1 | OrderDate |
| 地域 | Area | SalesTerritory |
instructionsは英語で、業務ルールまで書く
Fabric data agentには、AIの振る舞いを誘導するinstructionsを追加できます。公式ドキュメントでは、Fabric data agent instructionsに最大15,000文字の英語テキストを記述できると説明されています。(Microsoft Learn)
日本語圏のチームでも、Preview段階では英語で設計するのが現実的です。公式の制限として、Fabric data agentは現在、非英語をサポートしていないため、質問、instructions、example queriesは英語で提供することが推奨されています。(Microsoft Learn)
たとえば、AdventureWorksLHを使う場合は次のようなinstructionsを用意します。
Use AdventureWorksLH for questions about customers, sales, products, dates, and geography.
Use factinternetsales for internet sales analysis.
Use factresellersales for reseller sales analysis.
Use dimdate when the user asks about calendar year, fiscal year, month, quarter, or year-to-date sales.
Use dimgeography when the user asks about country, region, city, or postal code.
When the user asks for sales, use SalesAmount unless another metric is explicitly requested.
Do not answer questions that require external market data or causal analysis unless the required data exists in the selected tables.ポイントは、単に「このデータソースは売上データです」と書くのではなく、どの質問で、どのデータソース・テーブル・指標を使うかまで書くことです。
example queriesは「よくある質問」から作る
example queriesは、質問とSQL/KQLのペアを登録し、data agentが似た質問に対して正しいクエリを生成しやすくするための設定です。公式ドキュメントでは、lakehouse、warehouse、KQL databaseなどでexample queriesを追加できる一方、Power BI semantic modelのデータソースではサンプルの質問/クエリペア追加は現在サポートされていないとされています。(Microsoft Learn)
実務で入れるべきexample queriesは、難しいSQLの見本ではありません。問い合わせが多く、かつ定義を間違えると業務上の影響が大きいものから優先します。
| 優先度 | 例 | 理由 |
|---|---|---|
| 高 | 月次売上、前年同月比、YTD売上 | 経営・営業で頻繁に使う |
| 高 | 地域別、商品カテゴリ別、顧客セグメント別の集計 | ディメンション結合を誤ると結果がずれる |
| 中 | リピート購入率、初回購入以降の売上 | 定義が業務ごとに違いやすい |
| 中 | 上位N件、未販売商品、例外データ | 集計条件を明示しないと誤答しやすい |
| 低 | 一度しか使わない探索的なSQL | exampleとしての再利用価値が低い |
example queriesは、スキーマに合っており、検証に成功した有効なSQL/KQLだけを使う必要があります。スキーマ変更後にexample queriesを放置すると、AIの出力品質が下がる原因になります。(Microsoft Learn)
Copilot in Power BIで使う場合の注意点
Fabric data agentは、公開後にCopilot in Power BIから追加して利用できます。公式チュートリアルでは、Copilot in Power BIの画面で「Add items for better results」からdata agentを追加し、権限のあるdata agentを選択して質問する流れが説明されています。(Microsoft Learn)
ここで管理者が確認すべきなのは、data agentの公開だけではありません。Copilot側のスタンドアロン体験が有効でないと、data agentをCopilotシナリオで使えない場合があります。対象ページでも、Power BI admin portalのTenant settingsで「Standalone Copilot experience」を有効にする必要があると注意されています。(Microsoft Learn)
Copilot in Power BIで見えない、使えない、期待した回答が出ない場合は、次の順で確認すると切り分けやすくなります。
| 症状 | 確認する場所 | よくある原因 |
|---|---|---|
| data agentが候補に出ない | data agentの公開状態、利用者権限 | Publishしていない、共有・権限が不足している |
| Copilot画面から使えない | Tenant settings | Standalone Copilot experienceが無効 |
| semantic modelに質問できない | セマンティックモデルのRead権限 | モデル単位のRead権限がない |
| 一部データが返らない | RLS、CLS、Purviewポリシー | ユーザー権限またはポリシーで制限されている |
| 回答が曖昧 | instructions、example queries、テーブル名 | 業務用語や指標定義が不足している |
NotebookやAPIから使う場合の運用リスク
Fabric data agentは、公開URLを使ってFabric notebookからプログラム的に呼び出すこともできます。公式チュートリアルでは、公開前はpublished URLがなく、Publish後にURLをコピーしてNotebook内のコードから呼び出す流れが説明されています。(Microsoft Learn)
開発者が特に注意すべきなのは、サンプルコードをそのまま本番運用に持ち込まないことです。公式ドキュメントでは、プログラム呼び出し時にポーリングのタイムアウト、最小限のポーリング頻度、作成したスレッドやリソースのクリーンアップ、Notebookセッションの終了を実装するよう注意されています。(Microsoft Learn)
| 実装項目 | 推奨される考え方 | 放置した場合のリスク |
|---|---|---|
| タイムアウト | 長時間待ち続けない上限を設定する | 無限ループで容量を消費する |
| ポーリング間隔 | 2〜5秒程度から始め、必要時のみ調整する | API呼び出し過多、不要な負荷 |
| リソース削除 | 完了後にthreadなどを削除する | 不要な履歴・リソースが残る |
| Notebook停止 | 処理後にセッションを終了する | Fabric capacityを無駄に消費する |
| エラー処理 | failed、cancelled、requires_actionを分岐する | 失敗時に原因が追えない |
また、公式チュートリアル内のコードはOpenAI Assistants APIを使う例として示されていますが、OpenAIはAssistants APIを非推奨化し、2026年8月26日に停止すると案内しています。Microsoft Learn側でも、Fabricのプログラムインターフェースは将来Responses APIへ移行する予定であり、更新されたサンプルが出たら移行計画を立てる必要があると説明されています。(Microsoft Learn) (OpenAI Platform)
したがって、本番展開を考える場合は、次のように進めるのが安全です。
- Notebook連携はまず検証用途に限定する
- サンプルコードを本番コードとして固定しない
- API呼び出し部分をラッパー化し、将来のResponses API移行に備える
- 依存パッケージのバージョンをFabric runtimeごとに検証する
- タイムアウト、リトライ、監査ログ、コスト監視を最初から入れる
ガバナンスとセキュリティで確認すべきこと
Fabric data agentは、選択されたデータソースに対して読み取りクエリを生成する仕組みです。公式ドキュメントでは、Fabric data agentはSQL、DAX、KQLの読み取りクエリのみを生成し、作成・更新・削除などのデータ変更操作は生成しないとされています。(Microsoft Learn)
ただし、「読み取り専用だから安全」とは言い切れません。AI経由で機密データの要約や抽出が可能になるため、Purview、DLP、アクセス制限、監査の観点で確認が必要です。
Microsoft PurviewのDLPポリシーやアクセス制限ポリシーが適用されている場合、agentが特定のデータへアクセスできなかったり、応答がブロック・切り詰められたりすることがあります。また、agentとのやり取りはPurview AuditやeDiscoveryで検出対象になる可能性があります。(Microsoft Learn)
| 確認項目 | 管理者が見るべきポイント |
|---|---|
| RLS/CLS | Power BI semantic modelで行レベル・列レベルの制御が期待通り効くか |
| Purview DLP | 機密データを含むwarehouseやlakehouseに対する応答が制限されるか |
| Access restriction policies | 機密分類されたデータがagentから見えないことを確認できるか |
| Audit/eDiscovery | AI経由の問い合わせが監査対象として追跡できるか |
| Outbound access protection | 外部データソースやMicrosoft Graphへの接続ルールが適切か |
| 外部サービス連携 | Copilot Studio、M365 Copilot、MCP serverなどに応答を渡す運用を許可するか |
特に、Fabric外サービスからdata agentを呼び出す構成では、Fabric内の権限設計だけでなく、連携先サービスのデータ保持、地理的処理、ログ、監査、削除ポリシーまで確認してください。
Preview段階で把握しておきたい制限
Fabric data agent scenarioはPreviewとして扱われているため、UIや仕様が今後変わる可能性があります。現時点の公式制限として、次の点はPoC前に関係者へ共有しておくべきです。(Microsoft Learn)
| 制限 | 実務への影響 | 対応策 |
|---|---|---|
| 非英語は現在サポート外 | 日本語質問では精度や挙動が安定しない可能性がある | instructions、examples、テスト質問を英語で作る |
| 非構造化データは未対応 | PDF、DOCX、TXTを直接読ませる用途には向かない | 必要な情報をテーブル化する |
| lakehouseのファイルを直接読むわけではない | CSV/JSONを置いただけでは対象にならない | テーブルとして取り込む |
| LLMを変更できない | モデル選択による最適化はできない | instructionsとexamplesで精度を調整する |
| 会話履歴が永続しない場合がある | 過去の会話に依存した運用は危険 | 必要条件はinstructionsやデータ側に持たせる |
| データソースとagentの容量リージョンが違うと実行できない場合がある | 複数リージョン運用で失敗する可能性がある | PoC前にworkspace/capacityのリージョンを確認する |
| 応答は最大25行・25列に制限される | 全件抽出やデータダウンロード用途には向かない | 集計・要約・上位件数の質問に寄せる |
| example queriesはデータソースごとに最大100件 | すべての業務質問を例示で解決する設計には向かない | 重要指標と頻出質問に絞る |
日本語圏の企業で特に問題になりやすいのは、非英語対応です。利用者には日本語で聞かせたいという要望が出やすいですが、Preview段階では「英語で質問できる分析担当者向け」または「アプリ側で日本語を英語に変換してから渡す」構成を検討した方が安全です。ただし、翻訳を挟む場合は、指標名や業務用語が変換で崩れないよう、用語辞書を整備する必要があります。
移行・展開前のチェックリスト
Fabric data agentを社内展開する場合は、いきなり本番データで公開せず、AdventureWorksのような検証データまたは限定された業務データで小さく始めるのが現実的です。
| フェーズ | 確認項目 | 完了基準 |
|---|---|---|
| 事前確認 | Fabric capacity、Copilot/Azure OpenAI設定、cross-geo設定 | 検証用ユーザーで機能が使える |
| データ準備 | 対象テーブル、列名、指標定義、RLS/CLS | 質問に必要なデータだけが選ばれている |
| agent設計 | instructions、example queries、データソースの説明 | 頻出質問に対して正しいクエリが生成される |
| テスト | 権限別、質問別、境界条件別の検証 | 管理者以外の一般ユーザーでも想定通り動く |
| 公開 | Publish、説明文、共有範囲 | 利用者が目的を理解して選択できる |
| Copilot連携 | Standalone Copilot experience、approved item設定 | Copilot in Power BIから対象agentを追加できる |
| API連携 | published URL、タイムアウト、クリーンアップ、API移行余地 | サンプルコード依存ではなく運用コードとして管理できる |
| 運用 | 監査、Purview、問い合わせログ、改善サイクル | 誤答・権限・コストを継続的に確認できる |
よくある失敗と対策
data agentを作ったのにCopilotから見えない
まずPublish済みか、利用者にdata agentへの権限があるか、Copilot in Power BIのスタンドアロン体験が有効かを確認します。Copilot側の設定が無効なままだと、data agent自体が正しく作成されていても利用シナリオに乗りません。(Microsoft Learn)
Power BIセマンティックモデルにBuild権限を付けすぎる
data agent経由で質問するだけなら、Read権限で足りるケースがあります。Build権限やworkspaceメンバー権限を広く配る前に、Read権限、RLS、CLSで必要な利用体験を満たせるか検証してください。(Microsoft Learn)
日本語で質問して精度が安定しない
現時点の制限として非英語はサポート外です。PoCでは英語の質問、英語のinstructions、英語のexample queriesで基準精度を確認し、その後に日本語利用の可否を検討する順序が安全です。(Microsoft Learn)
Notebookが動き続けて容量を消費する
AdventureWorksデータを読み込むNotebookやAPI呼び出し用Notebookで、無限ループや高頻度ポーリングを放置するとFabric capacityを消費し続ける可能性があります。処理完了後はアクティブセルを止め、不要なNotebookセッションを終了してください。(Microsoft Learn)
スキーマ変更後に古い回答が出る
データソースを変更した場合は、data agent側でRefreshを行い、Explorerに最新状態を反映させる必要があります。あわせて、instructionsとexample queriesが新しいテーブル・列名に合っているか確認してください。(Microsoft Learn)
まず何から始めるべきか
最初にやるべきことは、data agentを作ることではありません。管理者、開発者、データ所有者で次の3点を合意することです。
- どの業務質問に答えるagentにするのか
- どのデータソースとテーブルだけを対象にするのか
- どのユーザーに、どの経路で使わせるのか
そのうえで、AdventureWorksシナリオと同じ流れで小さく検証します。lakehouseを用意し、必要なテーブルだけを選び、英語のinstructionsとexample queriesを設定し、生成されたSQL/DAX/KQLを確認します。期待通りの回答が出るようになってからPublishし、Copilot in Power BIやNotebook連携へ広げるのが安全です。
Fabric data agentは、適切に設計すれば、SQLやDAXを書けない利用者にもデータ活用の入口を広げられます。ただし、Preview段階では制限も多く、特に日本語利用、権限、リージョン、Purview、API移行は慎重に扱う必要があります。まずは対象業務を1つに絞り、管理者設定と権限を確認し、回答品質を検証しながら段階的に展開してください。
コメント