Azure AI FoundryでFabric data agentを使う方法｜利用条件・データ境界・管理策

Azure AI FoundryでMicrosoft Fabric data agentを利用する連携の要点は、公開済みのFabric data agentをFoundry Agent Serviceのツールとして呼び出し、利用者の権限を引き継いだままFabric上の業務データへ自然言語で問い合わせられるようになることです。Foundry側が会話の進行とツール選択、Fabric側がSQL・DAX・KQLの生成とデータ取得を担うため、データ接続や自然言語クエリを一から実装する範囲を減らせます。(Microsoft Learn)

ただし、既存環境へ自動的に適用される変更ではありません。Fabric data agentの作成・公開、Foundryとの接続、権限付与、管理者設定が必要です。また、Fabric data agent自体は一般提供されていますが、Foundry Agent Serviceのツールとして使う連携はパブリックプレビューで、SLAがなく、本番ワークロードへの利用も推奨されていません。現時点では、全社展開よりも管理されたPoCで評価すべき機能です。(Microsoft)

対象のMicrosoft Learnページは、ページ上の最終更新日が2026年6月2日、公式GitHubの履歴では2026年7月8日に同期コミットが確認できます。本記事では、2026年7月8日時点で公開されていた仕様を基準に、利用条件、データ境界、管理策、導入判断を整理します。(GitHub)

Azure AI FoundryとFabric data agentの連携で何が変わるのか

今回の連携では、FabricのデータをFoundryから直接検索するのではなく、あらかじめ作成・公開したFabric data agentを1つのツールとして登録します。

実務上の違いは次のとおりです。

論点	個別に実装する場合	Fabric data agent連携
データ接続	アプリごとにWarehouseやLakehouseへの接続を実装	公開済みFabric data agentを接続
自然言語からのクエリ生成	プロンプト、スキーマ取得、SQL生成処理を個別設計	Fabric data agentがSQL・DAX・KQLを生成
権限制御	アプリ側で利用者とデータ権限を関連付ける	利用者のMicrosoft Entra IDを引き継ぐOBOが基本
会話制御	データ検索専用の処理になりやすい	Foundryが複数ツールを選択して回答を組み立てる
運用成熟度	実装内容に依存	Foundry連携部分はパブリックプレビュー

たとえば、営業担当者が「今月の製品別粗利と前年同月比を教えて」と質問した場合、Foundry Agent Serviceは質問内容に応じてFabric data agentを呼び出します。Fabric data agentは、許可されたPower BIセマンティックモデルやWarehouseなどに対して読み取り専用のクエリを生成し、結果をFoundryへ返します。

Foundry側とFabric側では異なるモデルが動く

Foundryエージェントで選択するモデルは、主に会話の進行、ツールの選択、最終回答の生成に使われます。Fabric data agentが自然言語からSQLなどを生成する際のモデルは別であり、Foundry側のモデルを変更してもFabric data agentのNL2SQLモデルは変わりません。(Microsoft Learn)

そのため、回答品質を改善するときは、原因を次の2つに分けて考える必要があります。

Fabric data agentが適切なデータソースやテーブルを選べていない
FoundryエージェントがFabricツールを選ばない、または取得結果を正しく説明できていない

前者はFabric data agentの指示、データソース構成、サンプル質問を調整します。後者はFoundryエージェントのシステム指示やツール利用条件を調整します。

公式ガイドでも、エージェントの指示にツールの用途を明記するか、必要に応じてtool_choiceでツールを指定するよう案内されています。ツールを登録しただけでは、毎回確実に呼び出されるとは限りません。(Microsoft Learn)

利用前に満たすべき条件

FoundryからFabric data agentを利用するには、Foundry側の権限だけでなく、Fabricの容量、公開状態、データソース権限、テナント設定まで確認する必要があります。主な条件は次のとおりです。(Microsoft Learn)

確認項目	主な条件	導入時の判断
提供状態	Foundry連携はパブリックプレビュー	本番SLAが必須なら見送る
Fabric容量	原則としてFabric F2以上、またはFabricを有効化したPower BI Premium P1以上	無料環境だけでの本番評価は避ける
Fabric data agent	作成後に公開していること	下書きのままでは共有利用できない
テナント	FoundryプロジェクトとFabric data agentが同一テナント	クロステナント連携には使えない
リージョン	Data agentと接続先データソースの容量が同じリージョン	複数リージョン構成では事前確認が必要
Foundry権限	開発者と利用者に最低でもFoundry Userロール	開発者だけでなく実利用者にも必要
Fabric権限	Data agentへの読み取り権限と、接続先への権限	Data agentを共有しただけでは不十分
管理者設定	FabricのCopilot関連設定と、必要なリージョン外処理設定	日本リージョンでは特に重要
認証	利用者IDを使うOBOが、個別ガイド上の基本方式	アプリ専用IDは追加検証が必要

データソースごとに必要な権限が異なる

Foundry連携の個別ガイドでは、利用者にFabric data agentへのREADアクセスを付与したうえで、接続先ごとに次の権限を求めています。(Microsoft Learn)

データソース	Foundry連携ガイドに記載された権限
Power BIセマンティックモデル	Build。Readを含む
Lakehouse	Read
Warehouse	SELECT
KQLデータベース	Reader

注意したいのが、Power BIセマンティックモデルの権限です。Foundry連携の個別ガイドはBuildを要件としていますが、Fabric data agentの共有ガイドでは、質問への回答だけならReadで利用でき、ワークスペースへのアクセスも不要と説明されています。RLSとCLSも引き続き適用されます。(Microsoft Learn)

公式資料間で記載が一致していないため、実務では次の進め方が安全です。

PoC用の限定されたセマンティックモデルと専用グループを用意する
個別ガイドに従ってBuild権限で接続を成立させる
Readだけに変更して同じテストを実施する
Readで問題がなければ、不要なBuild権限を削除する
テスト結果と必要権限を運用手順書に残す

全利用者へ一律にBuild権限を付与するのではなく、データセット単位、利用者グループ単位で最小権限を確認することが重要です。

利用者IDのOBOを基本に設計する

公式のFoundry連携ガイドでは、サインイン中の利用者IDを引き継ぐ方式が説明されています。FoundryからFabric data agentへ問い合わせるときも、利用者が持っている範囲の権限だけが使われます。

利用者がFabric data agentへアクセスできても、元のWarehouseやセマンティックモデルに権限がなければ呼び出しは失敗します。エージェントを経由したことで、元データへの権限が自動的に追加されるわけではありません。(Microsoft Learn)

一方で、認証方式については公式資料の記載に差があります。

Foundry連携の個別ガイドでは、サービスプリンシパルは未サポートと記載
2026年5月のFabric公式発表では、カスタムアプリやFoundryからのサービスプリンシパル認証をプレビュー提供すると案内
サービスプリンシパル経由のKQL対応については、公式発表時点で今後対応と説明

したがって、社内利用者がサインインして質問するエージェントでは、OBOを基準にするのが確実です。バッチ処理やバックエンドサービスなど、利用者のサインインを伴わない構成では、サービスプリンシパル対応をテナント、SDK、接続先データソースの組み合わせごとに検証してください。プレビュー発表だけを根拠に本番設計を確定するのは避けるべきです。(Microsoft Learn)

データ境界は「Fabricの中だけ」とは限らない

導入判断で最も重要なのは、Fabric側のアクセス権限だけではありません。

Fabricの管理者向け資料では、Fabric data agentをMicrosoft Foundryなどの非Fabricサービスから利用すると、Fabric data agentの応答がFabricのコンプライアンス境界や地理的リージョンの外へ送信され、非Fabricサービス側の条件やポリシーに基づいて処理・保存される可能性があると明記されています。(Microsoft Learn)

「データソースがFabricにあるから、質問内容や回答も常にFabricの境界内に留まる」とは判断できません。

境界	実際の制御	管理者が確認すること
テナント境界	FoundryプロジェクトとFabric data agentは同一テナント	別テナントのデータを接続しない設計か
ID境界	OBOでは利用者のEntra ID権限を引き継ぐ	ゲスト、退職者、異動者の権限管理
データ境界	選択されたデータソースとテーブルを読み取り専用で検索	不要なテーブルを登録していないか
行・列の境界	Power BIのRLS・CLSなどが適用される	部門別、役職別の否定テスト
地理的境界	応答がFabric外のサービスへ送信される可能性がある	Foundry、モデル、ログの処理場所と契約条件
履歴境界	設定によってリージョン外に会話履歴を保持	保存の可否、利用者による削除、保持期間
モデル境界	FoundryモデルとFabricのクエリ生成モデルは別	どちらの処理へ何が渡るかを整理

Fabricの会話履歴をリージョン外で利用する設定を有効にした場合、履歴は利用者が許可している間、最長28日間保持される場合があります。利用者はチャット履歴を消去できますが、組織として保存を認めるかどうかは、個人任せにせず管理方針を決める必要があります。(Microsoft Learn)

日本リージョンでは管理者設定を先に確認する

Fabric管理ポータルには、CopilotやAzure OpenAIを利用するための設定に加え、データがリージョン外またはコンプライアンス境界外で処理・保存される可能性を許可する設定があります。

日本リージョンの容量を利用する組織では、特に次の項目を先に確認します。

FabricでCopilotおよびAzure OpenAIを利用できる設定になっているか
対象容量がFabric Copilot用の容量として指定されているか
リージョン外での処理を許可する範囲が適切か
リージョン外での保存を許可する範囲が適切か
会話履歴を利用する必要があるか
設定対象を全社ではなく、特定のセキュリティグループへ限定できないか

設定変更が反映されるまで最大1時間かかる場合があります。設定直後に接続できないときは、権限やコードを変更する前に反映待ちの可能性も確認してください。(Microsoft Learn)

管理者が用意すべき制御

Fabric data agent連携は、Foundry管理者だけで完結しません。Fabric管理者、データ所有者、セキュリティ担当、開発者の役割を分けると、過剰な権限付与を防ぎやすくなります。

担当	主な管理項目
Fabric管理者	Copilot設定、容量設定、リージョン外処理・保存、対象グループ
Foundry管理者	Foundry UserなどのRBAC、接続リソース、モデルデプロイ、プロジェクト権限
データ所有者	Data agentの公開、データソース選定、テーブル選定、利用者への共有
セキュリティ担当	RLS・CLS、秘密度ラベル、DLP、監査、データ境界の承認
開発者	ツール選択ルール、エラー処理、回答形式、監視、回帰テスト

Fabric data agentへ登録するデータを絞る

Fabric data agentには複数のデータソースを接続できますが、公式仕様では最大5つです。登録したデータソースの全テーブルを無条件に見せるのではなく、質問対象として必要なテーブルを選びます。Fabric data agentの接続は読み取り専用で、データの作成、更新、削除には使われません。(Microsoft)

最初のPoCでは、次のような構成が適しています。

1つの業務領域に限定する
データソースは1つから開始する
個人情報や機密情報を含まない
定義済みのKPIを持つ
正解を人が確認できる
RLSやCLSのテスト対象を含める

営業、在庫、人事、財務を最初から1つのData agentへ集約すると、データソースの選択ミスや用語の衝突が起きたときに原因を切り分けにくくなります。

Purviewと元データのポリシーを維持する

Fabricでは、Microsoft Purviewによる秘密度ラベル、DLP、監査などを利用できます。Power BIセマンティックモデルに設定されたRLSやCLSも、Fabric data agent経由で引き続き適用されます。(Microsoft Learn)

ただし、Purviewを設定しているだけで、Foundryへ応答を渡すことが自動的に承認されるわけではありません。

次の2点は分けて判断します。

元データに対して誰がどの行・列を参照できるか
取得した結果をFoundry側で処理・表示・記録してよいか

たとえば、個人単位の人事評価データをRLSで管理していても、回答がFoundryの会話履歴や監視ログへ残ることを許可できるとは限りません。PoC開始前に、入力、検索結果、最終回答、ログのそれぞれについて取り扱いを決めてください。

Foundry Observabilityで呼び出し状況を確認する

2026年6月の公式更新では、FoundryからFabric data agentを呼び出した際の遅延、ステータス、エラー情報をFoundryの可観測性機能で確認できるプレビュー機能が案内されています。([Microsoft Fabric Community][6])

運用時は、少なくとも次の指標を記録します。

Fabricツールが選択された割合
呼び出し成功率
権限エラーの件数
タイムアウト件数
平均応答時間
回答不能時に推測で補完した件数
利用者や部門ごとの失敗傾向

単に「回答できたか」だけでなく、「正しいツールを選び、正しい利用者権限で、正しいデータを取得したか」を監視することが重要です。

FoundryからFabric data agentを使う導入手順

業務質問とデータ区分を決める

最初に、エージェントへ回答させる質問を具体化します。

「売上について何でも答える」ではなく、次のように範囲を定義します。

月次売上と前年同月比
製品別の粗利
営業所別の受注件数
在庫切れが近い商品
重大度別のシステム障害件数

各質問について、参照するデータ、機密区分、正解の確認方法、利用できる部門を決めます。

Fabric管理者設定を確認する

Copilot関連設定、対象容量、リージョン外処理、保存、会話履歴を確認します。設定は必要最小限のセキュリティグループへ限定し、全社一括有効化を避けます。

Fabric data agentを作成する

対象のWarehouse、Lakehouse、Power BIセマンティックモデル、KQLデータベースなどを接続します。質問に必要なテーブルだけを選び、業務用語や集計定義をカスタム指示へ追加します。

Fabric data agentでは、データソースごとにサンプル質問を登録できます。公式仕様では1データソース当たり最大100件です。実際の利用者が使う表現を収集し、正しいクエリへ誘導できる質問例を登録します。(Microsoft)

Data agentを公開して権限を付与する

下書きで動作確認した後、Data agentを公開します。公開版は利用者向けの読み取り専用バージョンとなり、その後の下書き変更は再公開するまで公開版へ反映されません。(Microsoft Learn)

次に、開発者と利用者へ以下を付与します。

FoundryプロジェクトのFoundry User以上
Fabric data agentへのREADアクセス
接続先データソースへの必要最小限の権限

FoundryでMicrosoft Fabric接続を作成する

Fabric data agentのURLからworkspace_idとartifact_idを確認します。

Foundryポータルの管理センターで接続済みリソースを開き、Microsoft Fabric接続を作成します。Workspace IDとArtifact IDを登録し、作成された接続IDを取得します。(Microsoft Learn)

SDKを利用する場合は、主に次の値を環境変数などで管理します。

FOUNDRY_PROJECT_ENDPOINT
FOUNDRY_MODEL_DEPLOYMENT_NAME
FABRIC_PROJECT_CONNECTION_ID

REST APIを利用する構成では、これらに加えてエージェント用トークンが必要になります。(Microsoft Learn)

Foundryエージェントへツールを登録する

Python、C#、JavaScript、JavaのSDK、またはREST APIからFabric data agentツールを登録できます。SDKではMicrosoftFabricPreviewToolを利用します。(Microsoft Learn)

Foundryエージェントの指示には、どの質問でFabricツールを使うかを明記します。Fabric data agentが英語を前提としている点を考慮し、ツール向けの指示は英語で記述する方法が安全です。

Use the Fabric data agent for questions about sales, inventory, and gross margin.
Do not estimate values when the tool returns no data, an authorization error,
or an ambiguous result.

「データが取れない場合は推測しない」「権限エラーを別のデータで補わない」といった失敗時の動作も指定します。

複数の利用者で否定テストを行う

管理者アカウントだけで成功しても、OBOを使った権限制御を確認したことにはなりません。少なくとも次のテストを実施します。

テスト	確認する内容
権限を持つ利用者	正しいデータを取得できる
Data agentだけ共有された利用者	元データ権限がなければ拒否される
異なる部門の利用者	RLSにより異なる結果になる
CLS対象の利用者	許可されていない列が回答に現れない
曖昧な質問	推測せず、確認質問を返す
日本語の業務用語	正しい英語の項目や指標へ対応できる
大量データの要求	集計や絞り込みを案内する
Fabric側の障害	エラーを隠して数値を生成しない

Fabric data agentのチャット出力は最大25行、25列であり、大量データを一覧出力する用途には向きません。また、非構造化ファイルは直接扱えず、Lakehouse上のファイルもテーブルとして利用できる状態にする必要があります。(Microsoft)

業務や開発で効果が出やすい使いどころ

Fabric data agent連携は、構造化された業務データを自然言語で確認する用途に向いています。

活用場面	具体例	適している理由
経営KPIの照会	売上、粗利、予算差異、前年同期比	定義済み指標を会話で取得できる
部門別データ分析	営業所別実績、担当者別案件数	RLSを維持したまま回答できる
在庫・調達確認	欠品候補、滞留在庫、納期遅延	WarehouseやLakehouseを横断せず照会できる
システム運用	障害件数、重大度、発生時間帯	KQLデータを会話形式で集計できる
複合エージェント	データ分析後に別ツールで説明文を作成	Foundryがツール選択と回答生成を担える
社内セルフサービス分析	定型レポート外の追加質問	BI担当者への個別照会を減らしやすい

最初のPoCには、Power BIセマンティックモデルを使ったKPI照会が比較的適しています。指標の定義、リレーション、RLS、CLSがすでに整備されていれば、回答の正否と権限制御を検証しやすいためです。

現時点では適さない用途

次の要件がある場合は、別方式を検討するか、正式提供まで待つのが安全です。

SLAが必要な基幹業務
データの登録、更新、削除
承認処理やトランザクションの実行
PDF、Word、テキストファイルを直接検索する文書回答
数千行を超えるデータの抽出やダウンロード
異なるMicrosoft Entraテナント間の接続
日本語だけで高い回答精度を保証する必要がある業務
未検証のサービスプリンシパルを使った無人実行
データや回答をFabricの境界外へ出せない環境

Fabric data agentは読み取り専用で、非構造化データには対応せず、Foundry連携もパブリックプレビューです。業務データを参照して人の判断を支援する用途と、業務処理そのものを実行する用途を混同しないことが重要です。(Microsoft)

日本語で利用するときの設計ポイント

Fabric data agentの公式資料では、現時点で英語以外の言語はサポート対象外とされ、最適な結果を得るには英語の使用が推奨されています。(Microsoft)

日本語圏で利用する場合は、Foundryエージェントを日本語の窓口とし、Fabric data agentへ渡す意図や用語を英語へ正規化する構成が考えられます。

たとえば、利用者の質問が次の場合を考えます。

先月の関東支店の粗利率は？

Foundry側で、Fabric data agentへ渡す意図を次のように整理します。

Calculate the gross margin percentage for the Kanto branch
for the previous calendar month.

Fabricから返された数値と集計条件を使い、Foundryが日本語で回答します。

ただし、これは日本語対応を保証する仕組みではありません。導入時は、業務用語の対訳表を作り、代表質問ごとに結果を検証します。

特に誤りやすいのは次の用語です。

売上高と受注高
粗利と営業利益
当月と直近30日
前年同月比と前月比
店舗、支店、営業所
顧客数、取引数、注文件数
在庫数、引当可能数、安全在庫

日付条件や指標定義は単純翻訳に任せず、Fabric data agentのカスタム指示やセマンティックモデルで定義してください。

対応要否は3段階で判断する

判断	該当する組織
PoCを開始する	FabricとFoundryをすでに利用し、同一テナントの構造化データを利用者IDで参照したい。プレビューを許容できる
管理者レビューを先に行う	日本リージョン、機密データ、RLS・CLS、会話履歴、サービスプリンシパルを利用する
現時点では見送る	本番SLA、書き込み処理、非構造化文書検索、クロステナント、大量データ出力が必須

今回の更新によって、すべてのAzure AI Foundry利用組織が直ちに設定を変更する必要はありません。対応が必要なのは、Fabric上のデータをFoundryエージェントから自然言語で検索したい組織です。

最初に確認すべきなのは、接続手順ではなく、Fabric data agentの応答をFoundry側へ渡すことを組織として許可できるかです。許可できる場合は、機密度の低い1つのデータソース、限定した利用者グループ、代表的な業務質問からPoCを始めます。

PoCでは、正常回答だけでなく、権限のない利用者、RLS・CLS、曖昧な質問、日本語の業務用語、Fabric障害時の動作まで確認します。その結果と必要権限、データ境界、監視方法を文書化したうえで、対象データと利用者を段階的に拡大するのが安全です。
[6]: https://community.fabric.microsoft.com/t5/Fabric-Updates-Blog/Fabric-June-2026-Feature-Summary/ba-p/5190690 “
Fabric June 2026 Feature Summary – Microsoft Fabric Community
“

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure AI FoundryでFabric data agentを使う方法｜利用条件・データ境界・管理策