Microsoft Fabricでdata agentを使う場合、最初に確認すべきは「エージェントの作り方」ではなく、テナント設定です。2026年4月21日に更新された Microsoft Learn の「Configure Fabric data agent tenant settings」では、Fabric data agentを利用する前提として、CopilotとAzure OpenAI Serviceに関するテナントスイッチを有効化する必要があることが整理されています。特に日本を含むUS/EU外の容量リージョンでは、クロスジオ処理・保存・会話履歴の扱いを事前に判断しないと、PoCは動いても本番展開で止まりやすくなります。(Microsoft Learn)
この記事では、Microsoft Fabric data agent tenant settingsの2026年4月更新ポイントを、data engineers、DBAs、analytics leaders向けに実務目線で解説します。結論としては、まず管理者が「誰に使わせるか」「どの容量で使わせるか」「データがどの地域で処理・保存されることを許容するか」を決め、そのうえで段階的に有効化するのが安全です。
Microsoft Fabric data agent tenant settingsの2026年4月更新で押さえるべき点
今回取り上げる公式ドキュメントは、2026年4月21日に更新された「Configure Fabric data agent tenant settings」です。内容の中心は、Fabric data agentを使うために必要なテナント設定の確認手順と、CopilotおよびAzure OpenAI Service関連スイッチの扱いです。(Microsoft Learn)
重要なのは、これは単なる「AI機能をオンにする設定」ではないという点です。Fabric data agentは自然言語でデータに質問できる機能ですが、その裏側ではユーザーの権限、Fabric容量、Azure OpenAIによる処理、会話履歴、データリージョンが関係します。設定を一括で全社開放すると、セキュリティ部門やデータガバナンス部門との調整不足が後から問題になりやすくなります。
更新ポイントの要約
| 確認項目 | 実務上の意味 | まず取るべき行動 |
|---|---|---|
| Copilot/Azure OpenAI関連設定 | data agentの利用可否を左右する | テナント管理者が対象グループ単位で有効化する |
| Fabric Copilot容量 | どの容量でAI利用を許可するかを決める | PoC用容量と本番容量を分けて確認する |
| クロスジオ処理 | US/EU外の容量でAzure OpenAI処理が地域外になる可能性がある | 日本・アジア・豪州などの容量では必ず確認する |
| クロスジオ保存 | data agentやNotebook Copilotの利用時に保存設定が必要になる場合がある | セキュリティ・法務・データ保護担当と事前合意する |
| 会話履歴 | セッションをまたいだ文脈保持に関係する | 履歴保存の必要性と削除運用を決める |
Fabric data agentとは何か
Fabric data agentは、Microsoft Fabric内のデータに対して自然言語で質問し、回答を得るための会話型AI機能です。対象データソースには、lakehouse、warehouse、Power BI semantic model、KQL database、mirrored database、ontologyなどが含まれます。Microsoftの説明では、Fabric data agentは組織内のユーザーがFabric OneLakeなどに格納されたデータへ平易な英語で質問し、関連する回答を得られるようにする機能とされています。(Microsoft Learn)
実務で分かりやすく言えば、Fabric data agentは「SQL、DAX、KQLを書けない利用者にも、管理された範囲内でデータ問い合わせを行えるようにする仕組み」です。たとえば、営業部門のユーザーが「2025年度の地域別売上トップ5を教えて」と質問し、背後ではsemantic modelやwarehouseに対して適切なクエリが生成・実行されます。
ただし、万能な社内AI検索ではありません。Fabric data agentは、構造化データに対する会話型分析に向いています。PDF、Word、テキストファイルのような非構造化データは現在サポート対象外で、lakehouse内のCSVやJSONも、そのままではなくテーブルとして取り込む、またはテーブルとして参照できる形にする必要があります。(Microsoft Learn)
どのテナント設定を確認すべきか
Fabric data agentを使うには、Fabric管理者がAdmin PortalのTenant settingsにアクセスし、必要な設定を有効化します。公式ドキュメントでは、管理者アカウントでFabricにサインインし、右上の歯車アイコンからAdmin Portalを開き、左メニューのTenant settingsへ進む流れが示されています。また、設定の反映には最大1時間かかる可能性があります。(Microsoft Learn)
必須確認となるCopilot/Azure OpenAI関連設定
| 設定 | 何を制御するか | 判断ポイント |
|---|---|---|
| Users can use Copilot and other features powered by Azure OpenAI | ユーザーがCopilotやAzure OpenAIベースの機能を使えるか | 全社ではなく、まず検証用セキュリティグループで有効化する |
| Capacities can be designated as Fabric Copilot capacities | 容量管理者がFabric Copilot容量を指定できるか | AI利用を許可する容量を明確に分ける |
| Data sent to Azure OpenAI can be processed outside your capacity’s geographic region, compliance boundary, or national cloud instance | データが容量リージョン外で処理されることを許可するか | US/EU外の容量では特に重要 |
| Data sent to Azure OpenAI can be stored outside your capacity’s geographic region, compliance boundary, or national cloud instance | データが容量リージョン外で保存されることを許可するか | Notebook Copilotやdata agent利用時の保存要件を確認する |
| Conversation history stored outside your capacity’s geographic region, compliance boundary, or national cloud instance | 会話履歴をリージョン外に保存することを許可するか | セッションをまたぐ会話体験を使うかどうかで判断する |
Fabric data agentが正常に機能するには、Copilot and Azure OpenAI Serviceのテナント設定を有効にする必要があります。これらの設定は、ユーザーアクセスだけでなく、データ処理ポリシーにも関係します。(Microsoft Learn)
日本を含むUS/EU外リージョンではクロスジオ設定が重要
日本の読者が特に注意すべきなのは、Azure OpenAI Serviceの処理リージョンです。Microsoft Learnでは、Fabric Copilotを支えるAzure OpenAI ServiceはUSの複数データセンターとEUのFrance Centralに配置されていると説明されています。また、容量がJapan、Asia、Australia、Canada、India、Koreaなどにある場合、Fabric Copilotを使うにはCopilotをオンにするだけでなく、クロスジオデータ処理の有効化が必要とされています。(Microsoft Learn)
これは、グローバル企業や日本企業の本番導入で見落としやすいポイントです。たとえば、PoCでは少人数の検証環境で問題なく動作しても、本番で「日本リージョンのデータをAI処理のために地域外へ送ってよいのか」という確認が後から必要になることがあります。
リージョン別の実務判断
| 容量リージョン | 注意点 | 推奨判断 |
|---|---|---|
| US | クロスジオ処理の論点は比較的少ない | Copilot利用者と容量管理を中心に確認する |
| EU Data Boundary | EU境界内での扱いを確認する | 組織のEUデータポリシーと照合する |
| Japan / Asia / Australiaなど | Azure OpenAI処理が容量リージョン外になる可能性がある | クロスジオ処理・保存・履歴保存を個別に承認する |
| グローバル複数リージョン | データソースとdata agentの容量リージョンが分散しやすい | 先にリージョン設計を棚卸しする |
特に「会話履歴」は、利用者体験を高める一方で、保存場所と保存期間の確認が必要です。公式ドキュメントでは、data agentやNotebook Copilotのような会話型AI体験ではセッションをまたいで文脈を保持するため会話履歴を保存する場合があり、ユーザーが削除しない場合は最大28日保存されると説明されています。ユーザーはチャットをクリアすることで履歴を削除できます。(Microsoft Learn)
テナント設定はセキュリティ対策そのものではない
FabricのTenant settingsは、機能を誰に使わせるかを制御するための重要な管理ポイントです。一方で、Microsoft Learnでは、テナント設定はガバナンスポリシーの確立には役立つものの、それ自体がセキュリティ対策ではないと説明されています。たとえば、UI上のエクスポート機能を制限しても、semantic modelへの読み取り権限を持つユーザーが別の経路でデータを扱える可能性があります。(Microsoft Learn)
Fabric data agentでも同じ考え方が必要です。テナント設定で機能を制御しつつ、実際のデータアクセスはMicrosoft Entra IDのユーザー権限、workspace権限、semantic modelの権限、Microsoft Purviewポリシー、RLSやCLSなどと組み合わせて管理します。
DBAやデータ管理者にとって重要なのは、data agentが「ユーザーの権限を無視して何でも検索できるAI」ではない点です。Microsoft Learnでは、data agentはユーザーの資格情報と権限を使ってスキーマ参照やクエリ実行を行い、読み取り専用アクセスを厳格に適用すると説明されています。(Microsoft Learn)
data engineers、DBAs、analytics leaders別の確認ポイント
data engineersが見るべきポイント
data engineersは、data agentが正しく回答できるようにデータソースとメタデータを整える役割を担います。Fabric data agentでは、最大5つのデータソースを組み合わせて追加でき、対象にはlakehouse、warehouse、KQL database、Power BI semantic model、ontologyなどが含まれます。(Microsoft Learn)
実務では、次の準備が重要です。
- テーブル名や列名を業務利用者が理解しやすい名称にする
- 不要なテーブルをdata agentの対象に含めない
- よくある質問に対応するexample queriesを用意する
- 「売上」「粗利」「有効顧客」など、社内用語の定義をinstructionsに書く
- CSVやJSONは、必要に応じてlakehouse tableとして取り込む
公式ドキュメントでも、説明的なテーブル名・列名を使うことでAIがより正確で信頼性の高いクエリを生成しやすくなるとされています。(Microsoft Learn)
DBAsが見るべきポイント
DBAsは、生成されるクエリの範囲とデータアクセス制御を確認する必要があります。Fabric data agentは、SQL、DAX、KQLの読み取りクエリを生成できますが、データの作成・更新・削除を行うクエリは生成しません。(Microsoft Learn)
ただし、読み取り専用だから安全と考えるのは危険です。機密データは読み取りだけでも漏えいリスクになります。特に以下を確認してください。
| 確認項目 | 理由 |
|---|---|
| RLS / CLSの適用状況 | semantic model経由の問い合わせでユーザーごとの表示範囲を制御するため |
| Purviewポリシー | DLPやアクセス制限により、機密データの露出を抑えるため |
| workspaceとdata agentの容量リージョン | 異なるリージョン構成でクエリ実行に影響が出る可能性があるため |
| 監査ログ | 誰がどのような質問をしたかを後から確認するため |
| 出力上限 | data agentを大量データ抽出の代替として使わせないため |
公式ドキュメントでは、data agentは完全なデータセットを返す用途ではなく会話型インサイト向けに設計されており、回答は最大25行・25列に制限されるとされています。大量抽出や定型帳票は、Power BIレポート、Data Warehouse、Notebookなど別の手段を使うべきです。(Microsoft Learn)
analytics leadersが見るべきポイント
analytics leadersは、「便利だから全社展開する」ではなく、対象業務を絞って効果を測るべきです。Fabric data agentは、SQLを書けないビジネスユーザーに分析の入り口を提供できますが、正しい業務定義、信頼できるデータソース、利用者教育がないと、誤解を招く回答が増えます。
最初のユースケースとしては、次のような領域が向いています。
| 向いているユースケース | 理由 |
|---|---|
| 売上・在庫・顧客などの定型分析 | 質問が構造化データに変換しやすい |
| 経営ダッシュボードの補助説明 | semantic modelの指標と相性がよい |
| 運用ログやイベント分析 | KQL databaseと組み合わせやすい |
| データ利用部門のセルフサービス分析 | BIチームへの単純問い合わせを減らせる |
逆に、原因分析、将来予測、複雑な因果推論、外部要因を含む判断はdata agentだけに任せるべきではありません。公式ドキュメントでも、工場生産性低下の原因や売上急増の根本原因のような質問は、現在のdata agentの範囲外の例として示されています。(Microsoft Learn)
導入前に失敗しやすいポイント
Copilotをオンにしただけでdata agentが使えると思い込む
Fabric data agentでは、Copilot/Azure OpenAI関連設定、容量設定、リージョン外処理・保存の設定が絡みます。特に日本などUS/EU外の容量を使う場合、「Users can use Copilot and other features powered by Azure OpenAI」だけを有効化しても、必要なクロスジオ設定が不足する可能性があります。(Microsoft Learn)
日本語での利用を前提にしすぎる
日本語圏の導入で注意したいのが言語対応です。Microsoft Learnでは、Fabric data agentは現在非英語をサポートしておらず、最適な性能のためには質問、instructions、example queriesを英語で提供することが推奨されています。(Microsoft Learn)
そのため、日本企業で使う場合は、少なくとも初期導入では英語の質問テンプレートを用意するのが現実的です。たとえば、社内ポータルに次のような例文を置くと、利用者のばらつきを抑えられます。
Show total sales by region for FY2025.
List the top 10 customers by revenue in Q4.
Compare monthly inventory turnover by product category.日本語の業務用語が必要な場合でも、instructions側に英語で定義を書いておくと、解釈のブレを減らせます。
全データを対象にしてしまう
data agentは、対象テーブルを絞り込むことで精度と安全性が上がります。最初からすべてのテーブルを対象にすると、似た名前のテーブルが競合し、AIが意図しないデータソースを選ぶ可能性が高まります。
たとえば、売上分析用agentであれば、最初は次のように絞るのが現実的です。
| 対象に含める | 後回しにする |
|---|---|
| 売上ファクトテーブル | 検証用・一時テーブル |
| 商品マスタ | 古い履歴テーブル |
| 顧客マスタ | 重複した旧マスタ |
| 日付ディメンション | 開発中の中間テーブル |
会話履歴の扱いを決めないまま展開する
data agentの会話履歴は、セッションをまたいだ文脈理解に役立ちます。一方で、どの情報が履歴に残るか、ユーザーがどのように削除できるか、組織として監査やeDiscoveryの対象にするかを決めておく必要があります。公式ドキュメントでは、ユーザーがチャットをクリアできること、削除しない場合は最大28日保存されることが説明されています。(Microsoft Learn)
実務でおすすめの設定・展開手順
検証用セキュリティグループを作る
最初から全社有効化せず、data engineers、DBAs、BIチーム、セキュリティ担当、代表的な業務ユーザーを含む小さなグループで始めます。Fabricのテナント設定は、組織全体、特定グループ、除外グループなどで制御できます。(Microsoft Learn)
容量リージョンとデータソースを棚卸しする
次に、data agentを配置するworkspaceの容量リージョンと、参照するデータソースの容量リージョンを確認します。公式ドキュメントでは、data agentのworkspace容量とデータソースのworkspace容量が異なるリージョンにある場合、クエリを実行できない制限が示されています。(Microsoft Learn)
クロスジオ処理・保存・履歴保存を承認する
日本、アジア、豪州などUS/EU外の容量を利用する場合は、クロスジオ処理の承認が特に重要です。セキュリティレビューでは、少なくとも次の観点を確認してください。
| レビュー項目 | 確認内容 |
|---|---|
| 処理場所 | Azure OpenAIによる処理がどの地理境界で行われるか |
| 保存有無 | data agent利用時にどの情報が保存され得るか |
| 保存期間 | 会話履歴が最大何日残るか |
| 削除方法 | ユーザーがチャットをクリアできるか |
| 監査 | 監査ログやPurviewの対象にするか |
| 利用者範囲 | どの部門・グループに許可するか |
data agentを最小構成で作る
検証段階では、対象データソースを1〜2個に絞ります。たとえば、売上分析ならPower BI semantic modelを1つ、詳細確認用にwarehouseを1つだけ追加します。Fabric data agentでは、最大5つまでデータソースを追加できますが、最初から上限まで使う必要はありません。(Microsoft Learn)
instructionsとexample queriesを整備する
data agentの精度は、データソースの選び方だけでなく、instructionsとexample queriesにも左右されます。Microsoft Learnでは、data agentに組織固有の指示、例、ガイダンスを追加することで、組織のニーズや目標に沿った回答に近づけられると説明されています。(Microsoft Learn)
実務では、次のようなinstructionsが有効です。
Use the Sales semantic model for revenue, margin, and customer performance questions.
Use the Lakehouse tables only for raw transaction exploration.
When the user asks about "active customers", interpret it as customers with at least one purchase in the last 12 months.
Do not answer questions about forecasts unless the selected data source contains forecast tables.回答だけでなく生成クエリも確認する
Fabric data agentは、回答とともに中間ステップや生成されたコードを確認できるため、検証時は回答文だけでなくSQL、DAX、KQLの妥当性も確認します。特にDBAやBIチームは、誤った結合、意図しない粒度、RLS/CLSの適用、集計定義のずれを重点的に見てください。(Microsoft Learn)
導入判断のチェックリスト
本番展開前に、以下をすべて確認しておくと失敗を減らせます。
| チェック | 確認済み |
|---|---|
| data agentを使う業務シナリオが明確になっている | |
| 利用者をセキュリティグループで限定している | |
| Copilot/Azure OpenAI関連テナント設定を確認している | |
| Fabric Copilot容量の扱いを決めている | |
| 日本などUS/EU外リージョンでクロスジオ処理を確認している | |
| 会話履歴の保存・削除・監査方針を決めている | |
| Purview、RLS、CLS、workspace権限を確認している | |
| 対象テーブルを必要最小限に絞っている | |
| 英語の質問例とinstructionsを用意している | |
| 生成クエリと回答品質を検証している | |
| 利用者向けに「できること・できないこと」を説明している |
よくある質問
Fabric data agentを使うにはAzure OpenAIのキーが必要ですか？
通常のFabric data agent利用では、Azure OpenAIキーやアクセストークンをユーザーが用意する必要はありません。Microsoft Learnでは、FabricがMicrosoft管理のAzure OpenAI Assistantを使い、認証を処理すると説明されています。(Microsoft Learn)
Fabric data agentとCopilotは同じものですか？
同じではありません。どちらも生成AIを使いますが、Fabric data agentはデータソース、instructions、example queriesを構成できる会話型分析用のアーティファクトです。一方、Fabric内の各CopilotはNotebook、Data Factory、Data Warehouse、Power BIなど特定ワークロードの作業支援に使われます。(Microsoft Learn)
設定変更はすぐ反映されますか？
公式ドキュメントでは、Fabric data agent向けのテナント設定変更が反映されるまで最大1時間かかる可能性があるとされています。検証時は、設定直後に動作しない場合でも、権限ミスと決めつけず反映待ちの時間を考慮してください。(Microsoft Learn)
日本語で質問しても使えますか？
現時点のMicrosoft Learnでは、Fabric data agentは非英語をサポートしておらず、最適な性能のためには質問、instructions、example queriesを英語で使うことが推奨されています。日本語圏で導入する場合は、英語の質問テンプレートや業務用語の英語定義を用意するのが安全です。(Microsoft Learn)
data agentでデータ更新や削除はできますか？
できません。Fabric data agentは読み取りクエリを生成するための機能であり、データの作成、更新、削除を行うSQL、DAX、KQLクエリは生成しません。(Microsoft Learn)
まとめ：まず設定、次にデータ設計、最後に利用者展開
Microsoft Fabric data agent tenant settingsの2026年4月更新ポイントは、Fabric data agentを利用するにはCopilot/Azure OpenAI関連のテナント設定を正しく構成する必要がある、という前提を明確にした点にあります。特に日本を含むUS/EU外リージョンでは、クロスジオ処理・保存・会話履歴の扱いを早い段階で確認することが欠かせません。
次に取るべき行動は明確です。まずFabric管理者が対象ユーザーと容量を限定してテナント設定を確認します。次にdata engineersとDBAsがデータソース、権限、Purview、RLS/CLS、instructionsを整備します。最後にanalytics leadersが、業務シナリオ、利用者教育、回答品質の評価基準を決めて段階的に展開します。
Fabric data agentは、正しく設定すればデータ活用の入り口を大きく広げられます。一方で、設定・リージョン・権限・言語対応を軽視すると、本番利用でつまずきやすい機能でもあります。PoCの段階から「誰が、どのデータに、どの地域条件で、どの範囲まで質問できるのか」を明文化しておくことが、安定した導入への近道です。
コメント