Microsoft Fabricの「Fabric data agent」は、Fabric上のデータに対して自然言語で質問し、SQL・DAX・KQLなどのクエリに変換して回答を返す会話型AI機能です。結論として、今回の公式情報で管理者や開発者が特に確認すべきなのは、Copilot/Azure OpenAI関連のテナント設定、データソース権限、Power BIセマンティックモデルのRead権限、サービスプリンシパル認証、Git連携・デプロイパイプラインによる展開管理です。
単に「AIでデータに質問できるようになる」だけではありません。どのデータをAIに見せるか、誰の権限でクエリを実行するか、どの環境から公開するかを整理しないまま展開すると、回答精度の低下、権限不足、想定外のデータ露出、検証前エージェントの公開といった問題につながります。本記事では、2026年5月13日時点で確認できるMicrosoft Learnの公式情報をもとに、Fabric data agentの作成手順、変更点、影響範囲、管理者・開発者が確認すべき実務上の注意点を整理します。なお、作成手順ページの公式メタデータは2026年5月12日更新、サービスプリンシパル認証ページは2026年5月13日更新として公開されています。(GitHub)
Microsoft FabricのAI/Copilot更新で何が変わるのか
Fabric data agentは、Microsoft Fabric内のレイクハウス、ウェアハウス、Power BIセマンティックモデル、KQLデータベース、オントロジー、Microsoft Graphなどのデータに対して、英語の自然言語で質問できるデータQ&A用のエージェントです。ユーザーはSQL、DAX、KQLを直接書かなくても、選択されたデータソースに対してデータに基づく回答を得られます。(Microsoft Learn)
重要なのは、Fabric data agentが「何でも答える汎用チャットボット」ではない点です。ユーザーのMicrosoft Entra IDの権限、ワークスペース権限、データソース権限に基づいてスキーマを参照し、クエリを生成・検証・実行します。作成・更新・削除のようなデータ変更操作は許可されず、基本的には読み取り用途の会話型分析機能として位置付けるべきです。(Microsoft Learn)
今回の確認ポイントを実務目線でまとめると、次の通りです。
| 確認ポイント | 内容 | 実務上の影響 |
|---|---|---|
| 対応データソース | 最大5つのデータソースを組み合わせて追加できる | 1つの巨大な汎用エージェントより、営業・財務・運用など用途別に分けた方が精度を出しやすい |
| 権限 | Power BIセマンティックモデルは、data agent経由ならRead権限で利用可能 | Build権限やワークスペースロールを安易に付与しなくてもよいケースがある |
| テナント設定 | Copilot and Azure OpenAI Service関連の設定が必要 | 管理者が事前に有効化しないと、作成者側で準備しても利用できない |
| サービスプリンシパル | 公開済みdata agentを自動化・バックグラウンド処理・カスタムアプリ・CI/CDから呼び出せるPreview機能が追加 | 人のサインインに依存しない連携設計が可能になるが、制限と権限設計が重要 |
| ALM/展開 | Git統合、デプロイパイプライン、診断に対応 | 開発・検証・本番を分けた運用がしやすくなる |
| 制限 | 非英語、非構造化ファイル、完全な大量データ返却には制限がある | 日本語利用やPDF/Word文書検索の用途では過度な期待を避ける必要がある |
Fabric data agentでできること
Fabric data agentが得意なのは、構造化されたデータに対する「集計」「検索」「比較」「ランキング」「条件抽出」です。たとえば、次のような質問は相性が良いです。
| 向いている質問 | 理由 |
|---|---|
| “What were our total sales in California in 2023?” | 条件付き集計としてSQLやDAXに変換しやすい |
| “What are the top 5 products with the highest list prices?” | 並べ替えと上位抽出に変換しやすい |
| “Which customers had no purchases this quarter?” | テーブル間の結合やフィルターで回答できる |
| “Show operational errors by severity for last week.” | KQLデータベースのログ分析に向いている |
反対に、原因分析や外部要因を含む推論は、Fabric data agentだけで完結するとは考えない方が安全です。公式ドキュメントでも、工場の生産性低下の理由や売上急増の根本原因のような質問は、複雑な推論、相関分析、外部要因が必要になるため範囲外と説明されています。(Microsoft Learn)
Fabric data agentでできないこと・注意すべき制限
Fabric data agentを導入する前に、特に次の制限を押さえておく必要があります。
| 制限 | 具体的な注意点 |
|---|---|
| データ変更は不可 | SQL、DAX、KQLの読み取りクエリを生成する用途であり、作成・更新・削除は行わない |
| 非構造化ファイルは非対応 | PDF、DOCX、TXTなどを直接読ませる用途には向かない |
| レイクハウスの単体ファイルは直接対象外 | CSVやJSONは、テーブルとして取り込むか公開する必要がある |
| 非英語は現時点で非対応 | 質問、指示、サンプルクエリは英語で設計するのが安全 |
| LLMは変更不可 | 利用者側でモデルを選択する運用はできない |
| 容量リージョンに注意 | data agentのワークスペース容量とデータソースのワークスペース容量が異なるリージョンだとクエリ実行できない場合がある |
| 返却件数に制限 | 会話型インサイト向けであり、完全なデータセット出力には向かない |
特に日本語圏の企業で重要なのは、本番運用では英語の質問・指示・サンプルを前提に検証することです。UI上で日本語を入力できたとしても、公式制限として非英語はサポート対象外とされているため、業務利用では「英語プロンプトをテンプレート化する」「利用者向けに質問例を用意する」「日本語の業務用語は英語定義としてinstructionsに入れる」といった工夫が必要です。(Microsoft Learn)
管理者が最初に確認すべき設定
Fabric data agentを作成する前に、管理者は容量、テナント設定、データ処理リージョン、権限、ガバナンスを確認する必要があります。作成者だけが画面上で操作しても、管理ポータル側の設定が不足していると利用できません。
容量要件を確認する
前提条件として、有料のFabric容量F2以上、またはMicrosoft Fabricが有効化されたPower BI Premium per capacity P1以上が必要です。さらに、少なくとも1つのデータソースが存在し、そのデータソースに対する読み取りアクセス権が必要です。(Microsoft Learn)
確認すべき項目は次の通りです。
| 項目 | 確認内容 |
|---|---|
| Fabric容量 | F2以上の有料容量があるか |
| Power BI Premium | P1以上を使う場合、Microsoft Fabricが有効か |
| データソース | lakehouse、warehouse、Power BI semantic model、KQL database、mirrored database、ontologyなどが準備済みか |
| 権限 | 作成者と利用者が対象データにRead権限を持っているか |
Copilot and Azure OpenAI Serviceのテナント設定を確認する
Fabric data agentはAzure OpenAIを利用するFabricのAI機能に含まれるため、管理ポータルの「Copilot and Azure OpenAI Service」関連設定が重要です。公式情報では、Fabric data agentを利用するには「Users can use Copilot and other features powered by Azure OpenAI」や、必要に応じてクロスジオ処理・保存に関する設定を確認する必要があります。設定変更は反映まで最大1時間かかる場合があります。(Microsoft Learn)
| 設定 | 確認する理由 |
|---|---|
| Users can use Copilot and other features powered by Azure OpenAI | Fabric data agentを含むAzure OpenAIベースの機能利用に必要 |
| Capacities can be designated as Fabric Copilot capacities | 容量管理者がCopilot用容量を指定できるようにする |
| Data sent to Azure OpenAI can be processed outside your capacity’s geographic region | EU Data Boundaryおよび米国外の容量で必要になる場合がある |
| 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日間保存されると説明されています。セキュリティレビューでは「AIに何を送るか」だけでなく、「会話履歴を保存する必要があるか」「保存先リージョンに関する社内ルールに抵触しないか」も確認してください。(Microsoft Learn)
Purview、DLP、アウトバウンドアクセス保護を確認する
Fabric data agentはMicrosoft Purviewのガバナンスポリシーを尊重します。データソースにアクセス制御や秘密度ラベル、DLP、アクセス制限ポリシーが適用されている場合、エージェントの回答やクエリ実行にも影響します。また、エージェントのアウトバウンド接続は、Fabric管理ポータルで構成されたネットワークやアクセスルールの対象になります。(Microsoft Learn)
管理者は、少なくとも次の観点を確認しましょう。
| 観点 | 確認内容 |
|---|---|
| Purviewポリシー | 機密データがdata agent経由で表示される範囲を確認する |
| DLP | プロンプトや回答に機密情報が含まれる場合の動作を確認する |
| アウトバウンドアクセス | エージェントが到達できる外部エンドポイントを制御する |
| 監査 | 誰が、どのエージェントで、どのデータに質問したかを追跡できるようにする |
| 最小権限 | 利用者・作成者・サービスプリンシパルに過剰な権限を付与しない |
Fabric data agentの作成手順
Fabric data agentの作成は、ワークスペースから新しいアイテムとして追加する流れです。ただし、本番運用では「作る」よりも「何を選ぶか」「どのように検証するか」が重要です。
| 手順 | 作業 | 注意点 |
|---|---|---|
| 1 | 対象ワークスペースを開く | 容量と権限を事前に確認する |
| 2 | New ItemからFabric data agentを選択 | 検索してdata agentを追加する |
| 3 | 名前を付ける | 用途が分かる名前にする。例：Sales Analytics Agent |
| 4 | OneLake catalogからデータソースを追加 | 最大5つまで。必要なものだけ選ぶ |
| 5 | Explorerで利用するテーブルを選択 | AIに見せるテーブルを絞る |
| 6 | 質問して動作確認 | 回答だけでなく生成されたクエリや中間ステップも確認する |
| 7 | instructionsを設定 | 英語で役割、利用データソース、回答形式、用語定義を書く |
| 8 | example queriesを追加 | lakehouse、warehouse、KQL databaseなどで有効。Power BI semantic modelやontologyではサンプル質問・クエリペア追加に制限がある |
| 9 | Publishして共有 | 下書きと公開済みバージョンを分けて管理する |
Fabric data agentでは、初回作成後にOneLake catalogからデータソースを追加し、Explorerで利用対象テーブルを選択します。データソースは最大5つまで追加でき、追加は1つずつ行います。テーブル名や列名は、TableAやC1のような曖昧な名前ではなく、SalesData、ActiveCustomerのように意味が分かる名前にする方が、AIのクエリ生成精度を高めやすいとされています。(Microsoft Learn)
回答精度を上げる設定のコツ
Fabric data agentの精度は、モデルの賢さだけで決まりません。むしろ、データソースの範囲、テーブル・列名、instructions、example queries、Power BI側のPrep for AI設定が大きく影響します。
データソースは広げすぎない
最初から全社横断の万能エージェントを作るより、用途を絞ったエージェントを作る方が安定します。たとえば「経営会議向け売上分析」「サポート問い合わせ分析」「運用ログ監視」のように目的を分けます。公式のベストプラクティスでも、特定ドメインやユースケースに焦点を当てたdata agentを設計し、必要なデータソースとテーブルだけを含めることが推奨されています。(Microsoft Learn)
悪い例と良い例は次の通りです。
| 設計 | 例 | 問題・効果 |
|---|---|---|
| 悪い例 | 全部門のlakehouse、warehouse、semantic modelを1つのagentに追加 | 質問意図の解釈が曖昧になり、誤ったデータソースを選びやすい |
| 良い例 | 営業KPI専用agentに、売上・顧客・商品・期間テーブルだけを追加 | 回答精度、説明しやすさ、検証しやすさが上がる |
instructionsは「禁止」より「正しい動き」を書く
instructionsには、単に「間違えないでください」と書くのではなく、どのデータソースを使うか、どの指標を優先するか、情報が不足した場合どう回答するかを具体的に書きます。公式ベストプラクティスでも、曖昧な否定指示より、正しい処理方法を明確に書くことが推奨されています。(Microsoft Learn)
たとえば、営業分析用のFabric data agentなら次のように書くと実務で使いやすくなります。
You are a Sales Analytics Agent for the revenue operations team.
Use the Sales Lakehouse for raw transaction questions.
Use the Power BI semantic model for official financial metrics.
When the user asks about revenue, use NetSalesAmount unless they explicitly ask for GrossSalesAmount.
If the requested period is unclear, ask a follow-up question.
If data is missing or incomplete, say that the available records are insufficient.
Return concise answers with a short explanation of the query logic.このように、役割、対象データ、指標の定義、曖昧な質問への対応、回答形式を明記すると、利用者が期待する回答に近づけやすくなります。
example queriesは複雑なロジックを伝えるために使う
example queriesは、SQLやKQLの生成を安定させるための「見本」です。特に、日付処理、結合条件、部門コードの変換、売上指標の計算、KQLのユーザー定義関数を使うケースでは有効です。
ただし、example queriesには注意点があります。Fabric data agentは、選択されたテーブルのスキーマに合致し、有効なSQL/KQL構文として検証されたクエリだけを参照します。検証が完了していないクエリは利用されません。(Microsoft Learn)
Power BIセマンティックモデルはPrep for AIを優先する
Power BIセマンティックモデルをFabric data agentのデータソースにする場合、通常のdata agent instructionsだけでは不十分です。公式ベストプラクティスでは、セマンティックモデルに対するDAX生成は、モデルのメタデータやPrep for AI設定に依存し、data agentレベルのinstructionsはDAX生成では参照されないと説明されています。(Microsoft Learn)
そのため、Power BIセマンティックモデルを使う場合は、次の順序で準備します。
| 作業 | 目的 |
|---|---|
| AI data schemaを設定 | AIが使うテーブル、列、メジャーを絞る |
| ビジネスに分かりやすい名前へ変更 | TR_AMTではなくTotal Revenueのようにする |
| Verified answersを設定 | よくある質問に対して安定した回答を促す |
| AI instructionsをPrep for AI側に記述 | セマンティックモデル固有の指示をDAX生成に反映させる |
| data agent側では共通指示に限定 | トーン、回答形式、データソースのルーティングなどを書く |
Power BIレポートですでに使っているセマンティックモデルを追加するだけでは、必ずしも正しい回答にはなりません。AIに使わせるメジャー、同義語、非表示項目、スター schema、検証済み回答を整えることが重要です。
権限設計で押さえるべきポイント
Fabric data agentでは、データアクセスはユーザーのMicrosoft Entra ID、ワークスペース権限、データソース権限に基づいて行われます。独自にAzure OpenAIキーやアクセストークンを用意する必要はありません。(Microsoft Learn)
特にPower BIセマンティックモデルでは、data agent経由の利用においてRead権限が重要です。公式情報では、Power BIセマンティックモデルをdata agentのデータソースとして追加する場合、Write権限は不要で、Read権限で足りると説明されています。また、data agent経由の操作ではBuild権限やワークスペースロールが不要なケースが示されています。ただし、セマンティックモデル自体の変更やPrep for AIなどの機能を有効化する場合はWrite権限が必要です。(Microsoft Learn)
| 操作 | 必要な権限の考え方 |
|---|---|
| data agentでPower BI semantic modelに質問する | semantic modelのRead権限が基本 |
| semantic modelを変更する | Write権限が必要 |
| Prep for AIを設定する | Write権限が必要 |
| 他の入口で分析やレポート作成を行う | Build権限など別の権限が必要になる場合がある |
| warehouse、lakehouse、KQL databaseを使う | 対象データソースへの読み取り権限が必要 |
ここで誤りやすいのは、「data agentを共有すれば、裏側のデータにもアクセスできる」と考えることです。data agentは呼び出し元の権限で動作するため、利用者やサービスプリンシパルが対象データソースにアクセスできなければ、質問しても期待した回答は得られません。
サービスプリンシパル認証の追加で開発者が確認すべきこと
2026年5月13日更新の公式情報では、Fabric data agentがサービスプリンシパル認証をPreviewとしてサポートし、公開済みのdata agentを自動化、バックグラウンドサービス、カスタムアプリ、CI/CDパイプラインから呼び出せると説明されています。これにより、ユーザーの対話的なサインインに依存しないアプリ連携がしやすくなります。(Microsoft Learn)
ただし、これは「何でもサービスプリンシパルで実行できる」という意味ではありません。開発者と管理者は、次の条件を確認する必要があります。
| 確認項目 | 内容 |
|---|---|
| Microsoft Entraアプリ登録 | サービスプリンシパルを作成し、App ID、tenant ID、資格情報を管理する |
| Fabric API設定 | 管理ポータルで「Service principals can use Fabric APIs」を有効にする |
| スコープ | 組織全体ではなく、可能ならセキュリティグループに限定する |
| ワークスペース権限 | data agentが公開されているワークスペースにMemberまたはContributorを付与する |
| データソース権限 | 追加済みデータソースすべてに明示的なRead権限を付与する |
| トークン取得 | Microsoft Entraのclient credentials flowでFabricリソース向けトークンを取得する |
| 制限 | managed identitiesは未対応。KQL databaseに接続されたdata agentではサービスプリンシパル認証が未対応 |
特に重要なのは、data agentアイテムだけを共有しても不十分という点です。サービスプリンシパルは、data agent本体だけでなく、接続されている各データソースにも読み取りアクセスを持つ必要があります。(Microsoft Learn)
Git連携・CI/CD・デプロイ時の注意点
Fabric data agentは、Git統合やデプロイパイプラインによるALMに対応しています。公式情報では、Git連携によりdata agentの構成、instructions、example queries、データソース選択などをバージョン管理でき、開発・テスト・本番環境へ段階的に昇格できると説明されています。(Microsoft Learn)
本番展開で失敗しやすいのは、下書きと公開済みバージョンの扱いです。data agentをPublishすると、現在の下書きとは別に公開済みバージョンが作成されます。開発者は下書きを改善し続けられますが、利用者が触るのは公開済みバージョンです。そのため、検証前のエージェントを本番ワークスペースで公開しないように、ワークスペースと権限を分ける必要があります。(Microsoft Learn)
展開設計では、次のようなルールを決めておくと安全です。
| 項目 | 推奨運用 |
|---|---|
| 開発 | 専用の開発ワークスペースとfeature branchで変更する |
| レビュー | instructions、データソース、example queriesの差分を確認する |
| テスト | テストワークスペースで代表質問セットを実行する |
| 本番 | 本番ワークスペースから公開されたdata agentのみ利用者に案内する |
| Git運用 | publishedフォルダーを直接編集せず、draft側で変更してPublishする |
| デプロイ | sourceとtargetのワークスペースが同一テナント内にあるか確認する |
| 頻繁な更新 | 大量コミットでリポジトリサイズや性能に影響が出ないよう運用ルールを作る |
移行・展開前の実務チェックリスト
Fabric data agentを本番利用に進める前に、管理者、開発者、データ所有者で次の項目を確認してください。
| 担当 | チェック項目 |
|---|---|
| Fabric管理者 | F2以上またはP1以上の容量を確認したか |
| Fabric管理者 | Copilot and Azure OpenAI Serviceの必要設定を有効化したか |
| Fabric管理者 | クロスジオ処理・保存・会話履歴の要否を確認したか |
| Fabric管理者 | Purview、DLP、アウトバウンドアクセス保護の影響を確認したか |
| Fabric管理者 | サービスプリンシパル利用時の許可範囲をセキュリティグループで制御したか |
| データ所有者 | AIに見せるテーブル・列を最小限に絞ったか |
| データ所有者 | テーブル名、列名、メジャー名を業務用語に近づけたか |
| Power BI担当 | Prep for AI、AI data schema、Verified answersを整備したか |
| 開発者 | instructionsを英語で具体的に書いたか |
| 開発者 | 複雑なSQL/KQLロジックをexample queriesで補ったか |
| 開発者 | 代表質問セットで回答と生成クエリを検証したか |
| DevOps担当 | Git連携、デプロイパイプライン、ブランチ運用を設計したか |
| セキュリティ担当 | 利用者とサービスプリンシパルに過剰な権限がないか確認したか |
導入時におすすめの進め方
最初から全社展開するのではなく、1つの業務領域で小さく始めるのが現実的です。たとえば「営業KPIの確認」「月次財務指標の照会」「サポートチケットの傾向分析」のように、質問範囲が明確で、正解を検証しやすいテーマを選びます。
進め方は次の順序が安全です。
| フェーズ | やること |
|---|---|
| PoC | 1つのデータソース、10〜20個の代表質問で検証する |
| 精度改善 | テーブル名、instructions、example queries、Prep for AIを調整する |
| セキュリティ確認 | 権限、Purview、DLP、会話履歴、クロスジオ設定を確認する |
| 展開準備 | Git連携とデプロイパイプラインを整える |
| 本番公開 | 本番ワークスペースの公開済みagentだけを利用者に案内する |
| 運用 | 誤回答、権限エラー、よくある質問を定期的にレビューする |
Fabric data agentは、正しく設計すれば、専門知識のない利用者でもFabric上のデータにアクセスしやすくなる強力な機能です。一方で、データの準備、権限、ガバナンス、英語前提の設計、サービスプリンシパルの制限を無視すると、期待した成果は出にくくなります。まずは対象業務を絞り、代表質問セットで回答と生成クエリを検証し、管理者設定とALMを整えてから本番公開へ進めるのが最も安全です。
コメント