Azure AI Foundryで社内データを使うAIエージェントを作る場合、今回のポイントは「Microsoft Fabricのデータエージェントを、Foundry Agent Serviceのナレッジソースとして呼び出せるようになった」ことです。これにより、Fabric OneLakeやPower BIセマンティックモデル、Lakehouse、Warehouse、KQLデータベースなどの管理されたデータを、Azure AI Foundry側のエージェントから自然言語で活用しやすくなります。(Microsoft Learn)
ただし、この機能はプレビューです。管理者はテナント設定、クロスジオ処理、RBAC、Purviewポリシー、データ境界を必ず確認する必要があります。開発者は「接続できるか」だけでなく、「誰の権限で、どのデータに、どの条件でアクセスするか」まで設計してから展開することが重要です。
Azure AI FoundryのFabricデータエージェント連携で何が変わるのか
今回の更新で注目すべき点は、FabricデータエージェントをAzure AI Foundry側のAIエージェントに組み込み、社内データを使った会話型Q&Aをより実務アプリに近い形で利用できるようになったことです。
Fabricデータエージェントは、Microsoft Fabric上のエンタープライズデータを会話型Q&Aシステムとして扱うための機能です。Foundry Agent Serviceと統合することで、Azure AIエージェントはFabric OneLake上の構造化データやセマンティックデータをナレッジソースとして参照できます。(Microsoft Learn)
実務目線では、次のような変化があります。
| 変更点 | これまでの課題 | 今回の連携でできること |
|---|---|---|
| FabricデータをFoundryエージェントから利用 | BIやデータ基盤とAIアプリが分断されやすい | FabricデータエージェントをFoundry Agent Serviceの知識ソースとして追加できる |
| ユーザー権限を考慮したデータ参照 | AIアプリ側で権限設計を作り込む必要があった | エンドユーザーIDを使ったOn-Behalf-Of認可により、ユーザーがアクセス権を持つデータに基づいて処理できる |
| UIとSDKの両方で設定可能 | PoCはできても運用自動化が難しい | Foundry UIまたはPython SDKでFabricツールを追加できる |
| 生成AIアプリに分析データを組み込みやすい | RAG用に別途データ抽出・同期が必要になりがち | Fabric側のデータエージェントを既存の管理データへの入口として活用できる |
特に大きいのは、Fabricのデータ管理・分析基盤をそのままAIエージェントの業務知識として使いやすくなる点です。営業実績、在庫、ログ、顧客セグメント、経営指標などを、個別にベクトルDBへ移す前に「Fabricデータエージェントで回答できるか」を検討する価値があります。
この機能でできること
Azure AI Foundry側では、Agent Serviceで作成したエージェントに「Microsoft Fabric」をソースとして追加し、Fabricデータエージェントをナレッジリソースとして扱います。接続には、公開済みFabricデータエージェントのエンドポイントに含まれるworkspace-idとartifact-idを使用します。(Microsoft Learn)
主な利用イメージは次のとおりです。
| 活用シーン | 具体例 | 向いている理由 |
|---|---|---|
| 経営・営業データの自然言語分析 | 「先月、東日本エリアで売上が落ちた商品は？」 | Power BIセマンティックモデルやWarehouseを使った分析に向く |
| 業務部門向けの社内AIアシスタント | 「今月の在庫回転率が悪いカテゴリを教えて」 | データ構造を知らない利用者でも質問しやすい |
| 運用ログ・イベント分析 | 「過去24時間でエラーが増えたサービスは？」 | KQLデータベースやEventhouse系のデータと相性がよい |
| マルチエージェント構成の分析担当 | 顧客対応エージェントが必要に応じて売上データを参照 | Foundry側のエージェントがFabricツールとして呼び出せる |
一方で、何でもできるわけではありません。Fabricデータエージェントは、会話型の分析情報を返す用途に向いた機能です。大量データの一括抽出、PDFやWord文書の検索、データ更新処理、非構造化ドキュメントQ&Aの中心機能として使う設計には向きません。
利用前に確認すべき前提条件
公式情報では、FabricデータエージェントをFoundryから利用するには、Fabric容量、データソース、権限、テナント設定の確認が必要です。特に管理者が見落としやすいのは、Foundry側のRBACだけでなく、Fabric側の容量・データアクセス・クロスジオ設定も影響する点です。(Microsoft Learn)
| 確認項目 | 必要な内容 | 見落とすと起きること |
|---|---|---|
| Fabric容量 | 有料F2以上のFabric容量、またはFabric有効化済みのPower BI Premium P1以上 | データエージェントを前提どおり利用できない |
| データソース | Warehouse、Lakehouse、Power BIセマンティックモデル、KQL DB、ミラー化DB、オントロジなど | エージェントが回答に使うデータがない |
| データアクセス権 | 対象データソースへの読み取りアクセス | 利用者によって回答できない、または結果が変わる |
| Foundry RBAC | 開発者・エンドユーザーに少なくともAI Developerロール | Foundry側でエージェントを利用できない |
| テナント設定 | CopilotとAzure OpenAI関連設定、必要に応じたクロスジオ処理・保存 | 組織ポリシーやリージョン要件に抵触する可能性 |
| テナント一致 | FabricデータエージェントとFoundryリソースは同じテナント、同じアカウントでサインイン | 接続や認可が期待通りに動かない |
管理者は、まず「誰が使うのか」「どのFabricワークスペースのどのデータにアクセスさせるのか」「そのデータをFoundry側のサービスで処理してよいのか」を整理してください。PoCであっても、本番データを使う場合は情報セキュリティ部門やデータ管理者の確認を先に入れるべきです。
管理者が必ず確認すべき設定
Fabricテナント設定とクロスジオ処理
FabricデータエージェントをMicrosoft Foundry、Copilot Studio、Microsoft 365 CopilotなどのFabric外サービスから利用する場合、Fabricのコンプライアンス境界または地理的リージョンの外に応答が送信され、接続先サービスの条件やデータ処理ポリシーに従って処理・保存される場合があります。これは、社内規程や顧客契約に関わる重要な確認ポイントです。(Microsoft Learn)
特に日本企業で確認したいのは次の3点です。
| 確認ポイント | 判断基準 |
|---|---|
| データ境界 | 対象データが国外処理・国外保存を許容できる分類か |
| 規程・契約 | 個人情報、機密情報、顧客データを外部AIサービスで処理できるか |
| 有効化範囲 | 全社有効ではなく、検証グループ・特定容量・特定ワークスペースから始められるか |
テナント設定は有効化後、反映まで最大1時間かかる場合があります。設定直後に動かない場合、権限ミスと決めつける前に反映待ちも考慮してください。(Microsoft Learn)
Purview、DLP、アクセス制限ポリシー
Fabricデータエージェントは、Microsoft Purviewのガバナンス制御や、基になるデータソースのDLPポリシー、アクセス制限ポリシーの影響を受けます。ポリシーによっては、クエリが実行されなかったり、回答に特定データが表示されなかったりする場合があります。(Microsoft Learn)
これは「不具合」ではなく、むしろ正しい制御です。検証時は、管理者アカウントだけでテストせず、実際の利用者ロールに近いアカウントで回答差分を確認してください。
おすすめのテスト方法は次のとおりです。
| テストユーザー | 確認すること |
|---|---|
| 管理者 | 接続、エージェント設定、データソース選択が正しいか |
| 一般利用者 | 許可された範囲のデータだけ回答されるか |
| 権限のない利用者 | 機密データや対象外データが回答されないか |
| 部門別ユーザー | 部門・地域・職位によるアクセス差分が反映されるか |
開発者が押さえるべき実装ポイント
Foundry UIで追加する場合
Foundry UIでは、エージェントのナレッジソースとしてMicrosoft Fabricを選択し、Fabricデータエージェントへの接続を作成します。接続作成時には、公開済みFabricデータエージェントのURLからworkspace-idとartifact-idを取り出し、カスタムキーとして登録します。公式ドキュメントでは、これらの値をシークレットとして扱う手順が示されています。(Microsoft Learn)
エンドポイント形式は次のようになります。
https://fabric.microsoft.com/groups/<workspace_id>/aiskills/<artifact-id>設定後は、Azure AIエージェントに「どのような質問でFabricデータエージェントを使うべきか」を指示する必要があります。単に接続するだけでは、エージェントが常に適切にFabricツールを使うとは限りません。
指示文には、次のように具体的なルールを入れると実務で安定しやすくなります。
売上、在庫、地域別実績、商品別実績に関する質問では、Microsoft Fabricのデータエージェントを使用してください。
推測で回答せず、Fabricツールから取得できた情報に基づいて回答してください。
データが取得できない場合は、取得できない理由を簡潔に説明してください。Python SDKで追加する場合
プログラムから追加する場合は、azure-identityとプレビュー版のazure-ai-projectsを使用します。公式手順では、PROJECT_ENDPOINT、MODEL_DEPLOYMENT_NAME、FABRIC_CONNECTION_NAMEを環境変数として設定し、Foundryプロジェクトの接続IDを取得してFabricToolに渡す流れが示されています。(Microsoft Learn)
pip install azure-identity
pip install --pre azure-ai-projectsimport os
from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential
from azure.ai.agents.models import FabricTool
project_client = AIProjectClient(
endpoint=os.environ["PROJECT_ENDPOINT"],
credential=DefaultAzureCredential(),
)
conn_id = project_client.connections.get(
os.environ["FABRIC_CONNECTION_NAME"]
).id
fabric = FabricTool(connection_id=conn_id)プレビューSDKを使うため、CI/CDに組み込む場合は「常に最新版を入れる」だけではなく、検証済みのバージョンをロックする運用も検討してください。プレビュー段階ではAPIや挙動が変わる可能性があるため、本番相当環境ではリリース前テストを必ず挟むべきです。
モデル選択で誤解しやすい点
Azure AI Foundryのエージェント設定で選ぶモデルは、Foundry側のオーケストレーションと応答生成に使われます。公式情報では、このモデル選択はFabricデータエージェントが内部で使用するモデルには影響しないと説明されています。(Microsoft Learn)
つまり、Foundry側で高性能なモデルを選んでも、Fabricデータエージェント自体のクエリ生成やデータ処理の性質がそのまま置き換わるわけではありません。
実務では、次のように役割を分けて考えると判断しやすくなります。
| 領域 | 主に担うもの | 設計上の注意 |
|---|---|---|
| Foundry側エージェント | ユーザーとの会話、ツール選択、回答のまとめ | どの場面でFabricツールを使うかを明確に指示する |
| Fabricデータエージェント | Fabricデータソースへの問い合わせ、SQL/DAX/KQLなどの生成・実行 | データソース選択、サンプル、用語定義、権限設計が重要 |
| Fabric/Purview側 | データ管理、アクセス制御、ガバナンス | AIだから特別扱いせず、既存のデータポリシーを適用する |
現時点の制限事項と注意点
Fabricデータエージェントには、運用設計に影響する制限があります。特に本番導入前に確認したいのは、読み取り専用、非構造化データ非対応、英語以外の言語サポート、リージョン、返却行列数の制限です。(Microsoft Learn)
| 制限・注意点 | 実務への影響 | 対策 |
|---|---|---|
| 読み取りクエリのみ | データ作成・更新・削除はできない | 更新処理は別APIやワークフローに分離する |
| PDF、DOCX、TXTなどの非構造化データ非対応 | 社内文書検索には向かない | Azure AI Searchなど別のRAG基盤を検討する |
| 英語以外は現時点で非対応とされる | 日本語質問の精度・安定性に注意が必要 | 内部指示やクエリ例は英語で整備し、日本語UI側で補助する |
| Fabricデータエージェントが使うLLMは変更不可 | モデル差し替えで品質改善する設計はできない | データソース設計、指示、例、検証ケースで品質を上げる |
| 容量リージョンが異なるとクエリできない場合がある | 複数リージョンのデータ基盤で失敗しやすい | データソースとエージェントの容量リージョンを確認する |
| 応答は最大25行・25列に制限 | 明細一覧や全件出力には不向き | 集計・ランキング・要約用途に寄せる |
この機能を「自然言語で社内データに聞ける万能AI」として展開すると失敗しやすくなります。正しくは「Fabric上で管理された分析データに対し、権限を守りながら会話形式で洞察を得るための仕組み」と捉えるべきです。
移行・展開時の進め方
既存のFabricデータエージェントをAzure AI Foundryから利用する場合でも、単純に接続するだけでは不十分です。管理者、データ所有者、開発者、利用部門がそれぞれ確認する項目を分けて進めると、展開後のトラブルを減らせます。
| フェーズ | 実施内容 | 完了条件 |
|---|---|---|
| 現状確認 | 利用予定のFabricデータエージェント、ワークスペース、データソースを棚卸し | 対象データと所有者が明確になっている |
| ガバナンス確認 | テナント設定、クロスジオ処理、Purview、DLP、RBACを確認 | セキュリティ部門・データ所有者の承認がある |
| 接続設定 | FoundryでMicrosoft Fabric接続を作成し、workspace-idとartifact-idを登録 | Foundryエージェントのナレッジリソースに追加されている |
| 指示設計 | Fabricツールを使う条件、回答ルール、禁止事項をエージェント指示に記述 | 想定質問で適切にツールが選択される |
| 権限テスト | 管理者、一般ユーザー、権限なしユーザーで回答差分を確認 | 許可範囲外のデータが返らない |
| 品質テスト | 業務でよく使う質問、曖昧な質問、誤った質問を検証 | 回答精度と失敗時メッセージが許容範囲 |
| 限定展開 | 部門・用途を絞って公開 | 問い合わせ、誤回答、権限問題を監視できる |
| 本番展開 | 利用ガイド、問い合わせ窓口、変更管理を整備 | 運用担当と改善サイクルが決まっている |
特に重要なのは、業務ユーザーがよく使う質問を事前に集めることです。たとえば「売上が悪い商品を教えて」という質問でも、売上金額なのか粗利なのか、返品後なのか、対象期間はいつなのかで意味が変わります。データエージェントの指示には、こうした社内用語や指標定義を明記してください。
失敗しやすいポイント
管理者アカウントだけで検証してしまう
管理者アカウントでは正しく回答できても、一般ユーザーでは権限不足で回答できないことがあります。逆に、管理者権限で作ったデモだけを見て「全員が同じ結果を見られる」と誤解するのも危険です。
本番前には、最低でも次の3パターンでテストしてください。
- 対象データを閲覧できる一般ユーザー
- 一部データだけ閲覧できる部門ユーザー
- 対象データを閲覧できないユーザー
「日本語で質問できる前提」で設計する
公式情報では、Fabricデータエージェントは現時点で英語以外の言語をサポートしていないとされています。日本語UIや日本語利用者を想定する場合でも、裏側の指示、用語定義、サンプルクエリは英語中心で設計したほうが安全です。(Microsoft Learn)
日本語で使わせる場合は、次のような工夫が現実的です。
| 工夫 | 例 |
|---|---|
| 業務用語の対訳を用意 | 売上高 = Sales Amount、粗利 = Gross Profit |
| 質問テンプレートを提供 | 「Show sales amount by region for last month」など |
| Foundry側で質問を整形 | 日本語の質問を英語の分析意図に変換してからFabricツールを使う |
| 回答検証を強化 | 日本語質問と英語質問で結果が一致するか確認する |
大量明細の出力に使おうとする
Fabricデータエージェントは、会話型の分析情報を返す用途に設計されています。最大25行・25列の制限があるため、「今年の全取引を一覧で出して」といった用途には合いません。(Microsoft Learn)
向いている質問は、次のような集計・比較・要約です。
- 先月の売上上位10商品は何か
- 前月比で落ち込みが大きい地域はどこか
- エラー件数が増えたサービスはどれか
- 粗利率が低いカテゴリを教えて
全件エクスポートや詳細な帳票作成は、Power BI、SQL、Data Factory、Notebookなど既存のデータ処理手段に分けるべきです。
管理者・開発者別チェックリスト
管理者向けチェックリスト
| 項目 | 確認 |
|---|---|
| Fabric容量はF2以上、またはFabric有効化済みPower BI Premium P1以上か | □ |
| CopilotとAzure OpenAI関連のテナント設定を確認したか | □ |
| クロスジオ処理・保存を許可してよいデータ分類か確認したか | □ |
| Foundry利用者に必要なRBACロールを付与したか | □ |
| FabricとFoundryが同一テナントで利用されているか | □ |
| Purview、DLP、アクセス制限ポリシーの影響を検証したか | □ |
| 検証対象を全社ではなく限定グループに絞ったか | □ |
開発者向けチェックリスト
| 項目 | 確認 |
|---|---|
公開済みFabricデータエージェントのworkspace-idとartifact-idを取得したか | □ |
| Foundry接続でID情報をシークレット扱いにしたか | □ |
| エージェント指示にFabricツールを使う条件を書いたか | □ |
| 代表的な業務質問でツール選択を検証したか | □ |
| 権限が異なるユーザーで回答結果を比較したか | □ |
| SDK利用時にプレビュー版依存の変更リスクを管理しているか | □ |
| 失敗時のメッセージや人手確認への導線を用意したか | □ |
実務でおすすめの展開パターン
最初から全社向けの汎用AIアシスタントに組み込むより、業務領域を絞って始めるほうが成功しやすくなります。
おすすめは「1部門・1データエージェント・20〜30個の定番質問」から始める進め方です。たとえば営業部門なら、売上、粗利、商品、地域、顧客セグメントに絞ります。ログ分析なら、対象サービス、期間、エラー種別、影響範囲に絞ります。
最初に絞るべき項目は次のとおりです。
| 絞る項目 | 例 |
|---|---|
| 利用部門 | 営業企画、経営管理、SRE、カスタマーサポート |
| データソース | 1つのPower BIセマンティックモデル、1つのWarehouseなど |
| 質問範囲 | 月次売上、商品別実績、障害件数など |
| 利用者 | 5〜20人程度の検証ユーザー |
| 成功基準 | 回答精度、回答時間、問い合わせ削減、分析作業時間短縮など |
AIエージェントは、接続した瞬間に業務で使えるわけではありません。データソースの選び方、指示文、業務用語、権限設計、利用者教育で品質が大きく変わります。特にFabricデータエージェントは、構造化データを扱う強みがあるため、「何でも聞けるAI」ではなく「このデータについて正しく聞けるAI」として設計するのが現実的です。
まず何をすべきか
Azure AI FoundryでFabricデータエージェントを使うなら、最初にやるべきことは接続作業ではなく、対象データと権限の整理です。
次の順序で進めると、設定漏れや手戻りを減らせます。
- 利用したいFabricデータエージェントとデータソースを決める
- データ所有者と管理者で、クロスジオ処理・保存の可否を確認する
- Fabric容量、テナント設定、Foundry RBACを確認する
- Foundry UIでMicrosoft Fabric接続を作成する
- エージェント指示に、Fabricツールを使う条件を明記する
- 権限が異なる複数ユーザーで回答をテストする
- 限定ユーザーに展開し、質問ログと誤回答パターンを改善する
今回の更新は、Fabric上の管理されたデータをAzure AI Foundryのエージェント体験に近づける重要な一歩です。一方で、プレビュー機能であり、データ境界、権限、言語、出力制限には注意が必要です。まずは影響範囲を限定したPoCから始め、管理者・開発者・データ所有者が同じチェックリストで確認しながら、本番展開に進めるのが安全です。
コメント