Microsoft Fabric Copilot Studio データエージェント連携でまず押さえるべき結論は、Fabric 上のデータエージェントを Copilot Studio のカスタム AI エージェントに接続し、Teams などの会話画面から業務データに基づく回答を返せるようにする点です。2026年4月22日に更新された Microsoft Learn 日本語版では、この機能がプレビューであること、利用条件、追加手順、認証、Teams 展開時の注意点が整理されています。(Microsoft Learn)
データエンジニア、DBA、分析リーダーにとって重要なのは、「AIチャットを作れる」こと自体ではありません。現場ユーザーが自然言語で質問したときに、Fabric のレイクハウス、ウェアハウス、Power BI セマンティックモデル、KQL データベースなどの信頼できるデータに基づいて回答できる導線を、権限管理込みで設計できることです。プレビュー機能のため、いきなり全社展開するよりも、Teams 向けの限定シナリオから検証するのが現実的です。
Microsoft Fabricの最新動向: Copilot Studioでデータエージェントを使う意味
Microsoft Fabric のデータエージェントは、組織のデータに対して自然言語で質問し、回答や洞察を得るための会話型分析コンポーネントです。Microsoft の説明では、Fabric data agent 自体は会話型 Q&A システムを構築するための一般提供機能として位置付けられており、OneLake 上のデータや Fabric 内の各種データソースに対する自然言語での分析を支援します。(Microsoft Learn)
今回のポイントは、そのデータエージェントを Copilot Studio のカスタム AI エージェントに「接続されたエージェント」として追加できることです。これにより、Copilot Studio 側のエージェントが業務窓口となり、必要に応じて Fabric データエージェントを呼び出して、企業データに基づく回答を返せる構成になります。Microsoft はこの構成を、エージェント間のコラボレーションを可能にするものとして説明しています。(Microsoft Learn)
実務上は、次のような使い方が見えてきます。
| 利用シーン | 具体例 | 主な担当者 |
|---|---|---|
| 経営・部門KPIの確認 | 「今月の地域別売上の落ち込み要因は？」とTeamsで質問する | 分析リーダー、BI担当 |
| データ問い合わせの一次対応 | 定義済みのセマンティックモデルやウェアハウスから回答する | データエンジニア |
| 運用ログやイベント分析 | KQL データベースに対して自然言語で調査の入口を作る | DBA、SRE、運用担当 |
| 現場向けセルフサービス分析 | レポート作成依頼を減らし、定型的な質問をエージェントで処理する | データ活用推進担当 |
特に大きいのは、Copilot Studio のエージェントが単なるFAQボットではなく、Fabric 側の管理されたデータソースに基づいて回答できる点です。SharePoint やファイルを知識ソースにするだけでは答えにくい、数値・集計・ログ・メトリクスの問い合わせに向いています。
2026年4月更新で押さえるべき変更点
今回の公式ドキュメント更新で実務担当者が確認すべきポイントは、接続方法そのものよりも「どの条件を満たすと使えるのか」「どのチャネルで検証済みなのか」「権限をどう扱うのか」です。Microsoft Learn 日本語版の該当ページは、2026年4月22日更新と表示されています。(Microsoft Learn)
| 観点 | 押さえるべき内容 | 実務上の意味 |
|---|---|---|
| 機能ステータス | Copilot Studio で Fabric データエージェントを使う機能はプレビュー | 本番適用前にPoCと変更追跡が必要 |
| 接続方式 | Copilot Studio のカスタム AI エージェントに Fabric データエージェントを追加 | 業務エージェントの中に分析エージェントを組み込める |
| 前提データソース | ウェアハウス、レイクハウス、Power BI セマンティックモデル、KQL DB、ミラー化DB、オントロジなど | 既存の分析基盤をそのまま会話UIに近づけられる |
| 認証 | User authentication または Agent author authentication を選択可能 | 利用者ごとの権限で動かすか、作成者側の設計で扱うかを検証する必要がある |
| 展開チャネル | 接続済み Fabric データエージェントを持つ Copilot Studio エージェントは Teams で検証済み | まず Teams 利用を前提に設計するのが安全 |
| Microsoft 365 Copilot | Copilot Studio 経由の接続済み構成は Microsoft 365 Copilot では現時点で未サポート | Microsoft 365 Copilot で使う場合は別ルートとの違いを理解する必要がある |
Microsoft の手順では、Copilot Studio のカスタム AI エージェントに Fabric データエージェントを追加し、必要に応じて Microsoft Fabric との接続を作成し、対象のデータエージェントを選択します。その後、認証方式を確認し、生成AIオーケストレーションを有効化してテスト、公開チャネルを選びます。(Microsoft Learn)
導入前に確認すべき前提条件
この機能は、Copilot Studio の画面からすぐ試せるように見えても、実際には Fabric 側、Microsoft 365 側、テナント設定、データソース権限の確認が必要です。前提条件の確認を飛ばすと、エージェントが一覧に出ない、回答できない、特定ユーザーだけ失敗する、といった問題が起きやすくなります。
| 確認項目 | 必要な内容 | 失敗しやすいポイント |
|---|---|---|
| Fabric 容量 | 有料の F2 以上の Fabric 容量、または Fabric が有効な Power BI Premium P1 以上 | 試用環境や容量未割り当てで動作確認しようとする |
| テナント設定 | Copilot と Azure OpenAI 関連の設定、必要に応じたクロスジオ処理・保存設定 | 管理者設定の反映に時間がかかることを見落とす |
| データソース | データを持つウェアハウス、レイクハウス、Power BI セマンティックモデル、KQL DB など | ソースに読み取り権限がない |
| データエージェント | 事前に動作確認し、詳細な説明を付けて公開しておく | 下書きのまま Copilot Studio 側で探す |
| テナント | Fabric データエージェントと Copilot Studio エージェントが同じテナントにある | 別テナントや別アカウントでサインインしている |
| ライセンス | Microsoft 365 Copilot ライセンス、カスタムエージェントを構築・管理するユーザーライセンス | 開発者と利用者のライセンス要件を分けて確認していない |
| 権限 | Fabric データエージェントへの読み取り以上、Copilot Studio での作成・変更権限、基になるデータソースへのアクセス | エージェントにはアクセスできるが、データソースにアクセスできない |
Fabric データエージェントのテナント設定では、Copilot と Azure OpenAI Service に関する設定、AI 用のクロスジオ処理・保存に関する設定が関係します。Microsoft のドキュメントでは、テナント設定の反映に最大1時間かかる可能性があることも示されています。(Microsoft Learn)
Copilot StudioにFabricデータエージェントを追加する手順
実装時は、いきなり本番エージェントに組み込むのではなく、検証用の Copilot Studio エージェントを作成して動作を確認します。特に、権限、回答精度、呼び出しタイミング、Teams での見え方は、実データに近い環境で確認すべきです。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | Fabric 側でデータエージェントを作成・検証する | 代表的な質問に期待どおり答えられるか |
| 2 | データエージェントを公開する | 説明文が具体的で、用途が分かるか |
| 3 | Copilot Studio で対象環境を選ぶ | Fabric 側と同じテナント・アカウントか |
| 4 | 新しいカスタム AI エージェントを作成する | 名前と説明に役割を明記する |
| 5 | 上部の Agents から Add を選ぶ | Microsoft Fabric を拡張方法として選択できるか |
| 6 | Fabric 接続を作成または選択する | 対象の Fabric データエージェントが一覧に出るか |
| 7 | データエージェントを追加する | 説明文を必要に応じて調整する |
| 8 | 認証方式を確認する | User authentication の場合、各ユーザーのデータアクセス権が必要 |
| 9 | 生成AIオーケストレーションを有効化する | 接続済みエージェントが適切に呼び出されるか |
| 10 | テストチャットで検証し、Teams に公開する | 期待する質問で正しいエージェントが使われるか |
公式手順でも、Copilot Studio のテストチャットで応答を確認し、接続された Fabric データエージェントが回答取得に使われるかを検証する流れが示されています。また、生成AIオーケストレーションを有効化することも手順に含まれています。(Microsoft Learn)
認証と権限設計は最初に決める
この連携で最も慎重に扱うべきなのは、認証と権限です。Microsoft の手順では、接続済みの Fabric データエージェントに対して User authentication または Agent author authentication を選択できるとされています。User authentication を選ぶ場合、利用者が Fabric データエージェントと基になるデータソースへアクセスできる必要があります。(Microsoft Learn)
実務では、まず User authentication を基準に検証するのが安全です。利用者の権限に応じて見えるデータを制御しやすく、既存のデータガバナンスと整合しやすいためです。一方で、部門共通の定型問い合わせに限定したい場合や、利用者ごとの権限設計が複雑な場合は、別の認証方式を検討する余地があります。ただし、プレビュー段階では実際の権限評価、監査ログ、共有時の挙動を必ず検証してください。
Fabric データエージェントの共有と権限管理では、基になるデータソースへのアクセスも必要です。Microsoft は、Fabric データエージェントがユーザー権限、RLS、CLS を尊重すること、Power BI セマンティックモデルではエージェント経由の問い合わせに Read 権限で足りること、Build 権限やワークスペースアクセスが常に必要なわけではないことを説明しています。(Microsoft Learn)
Microsoft 365 Copilotとの違いを混同しない
注意したいのは、「Copilot Studio のカスタムエージェントに Fabric データエージェントを接続する方法」と、「Fabric データエージェントを Microsoft 365 Copilot で直接使う方法」は別ルートだという点です。
| ルート | 使い方 | 向いている場面 |
|---|---|---|
| Copilot Studio + Fabric データエージェント | Copilot Studio のカスタム AI エージェントに接続済みエージェントとして追加する | 業務フロー、トピック、ツール、他エージェント連携を組み合わせたい |
| Microsoft 365 Copilot の Agent Store | Fabric データエージェントを Agent Store に公開し、Teams などから直接利用する | ユーザーがデータエージェントそのものに直接質問したい |
Copilot Studio 経由の構成について、Microsoft の該当ページでは、接続された Fabric データエージェントを持つカスタムエージェントは Microsoft 365 Copilot では現在サポートされておらず、Teams に対して検証済みであると説明されています。(Microsoft Learn)
一方、別の Microsoft Learn ページでは、Fabric データエージェントを Microsoft 365 Copilot の Agent Store に公開し、ユーザーが直接チャットしたり、@ でメンションして利用したりできる構成が説明されています。このルートでは、共有相手にもデータエージェントと基になるデータソースへのアクセスが必要で、RLS と CLS も尊重されます。(Microsoft Learn)
つまり、業務エージェントの中に分析機能を組み込みたいなら Copilot Studio 連携、Fabric データエージェントそのものを Microsoft 365 Copilot で使わせたいなら Agent Store 公開、と分けて考えるべきです。
データエンジニアが設計すべきポイント
データエンジニアは、エージェントに接続するデータソースを広げすぎないことが重要です。Fabric データエージェントは複数のデータソースを扱えますが、Microsoft の概念ドキュメントでは最大5つのデータソースを組み合わせられると説明されています。対象を広げすぎると、どのデータソースを使うべきかの判断が難しくなり、回答品質が不安定になります。(Microsoft Learn)
最初のPoCでは、次のような小さなスコープに絞ると検証しやすくなります。
| PoCテーマ | 接続するデータソース例 | 検証する質問 |
|---|---|---|
| 売上KPI確認 | Power BI セマンティックモデル | 「今月の売上が前年同月比で下がった地域は？」 |
| 在庫分析 | ウェアハウス | 「欠品リスクが高い商品カテゴリは？」 |
| ログ調査 | KQL データベース | 「直近24時間でエラーが増えたサービスは？」 |
| 顧客対応分析 | レイクハウステーブル | 「問い合わせ件数が増えた要因は？」 |
また、データエージェントの説明文は単なる紹介文ではなく、Copilot Studio 側や他のオーケストレーターが「いつ呼び出すべきか」を判断する材料になります。たとえば「売上、粗利、地域別実績、月次KPIに関する質問に回答する」など、対象データと得意な質問を明確に書くべきです。
DBAとガバナンス担当が見るべきポイント
DBA やガバナンス担当は、エージェントを「便利な検索窓」としてではなく、「権限を持った新しいデータアクセス経路」として扱う必要があります。Fabric データエージェントは読み取り専用のクエリを生成する仕組みであり、作成・更新・削除を行う SQL、DAX、KQL クエリは生成しないと説明されています。(Microsoft Learn)
ただし、読み取り専用だから安全とは限りません。機密データに対する質問、集計結果からの推測、部門外データの参照、監査対象となる問い合わせなどは、通常のレポート閲覧と同じか、それ以上に注意が必要です。Microsoft のドキュメントでは、Purview の DLP やアクセス制限ポリシーによって、回答がブロックまたは制限される可能性があることも示されています。(Microsoft Learn)
運用前には、最低限次のチェックを行いましょう。
| チェック項目 | 確認内容 |
|---|---|
| 最小権限 | 利用者に必要以上の Build 権限やワークスペース権限を付けていないか |
| RLS / CLS | 部門・役職・地域ごとのアクセス制御がエージェント経由でも期待どおりか |
| 監査 | 誰が、いつ、どのエージェントに、どの種類の質問をしたか追跡できるか |
| 機密情報 | DLP や Purview ポリシーの対象データで応答がどう変わるか |
| 共有 | エージェントを共有した相手が、基になるデータソースにも適切な権限を持つか |
分析リーダーが考えるべき活用シナリオ
分析リーダーにとって、この更新は「BIレポートをAIで置き換える」話ではありません。むしろ、既存の Power BI レポートや Fabric データ基盤を補完し、現場ユーザーが最初の問いを投げやすくする仕組みです。
たとえば、月次会議の前に次のような質問を Teams で投げられるようになります。
- 「今月の売上未達が大きい地域を3つ挙げて」
- 「粗利率が下がった商品カテゴリは？」
- 「先週から問い合わせが増えたサービスは？」
- 「このKPIの定義を説明して」
- 「前年差が大きい指標を確認して」
ただし、最終判断をエージェント回答だけに任せるべきではありません。重要な経営判断や顧客影響の大きい判断では、回答の根拠となるデータソース、集計ロジック、更新日時、フィルター条件を確認できる運用にする必要があります。
失敗しやすいポイントと対処法
Copilot Studio 連携では、設定ミスが回答品質の問題に見えやすい点に注意が必要です。特に多いのは、エージェントが見つからない、呼び出されない、期待したデータを使わない、権限エラーになる、というパターンです。
| 症状 | 主な原因 | 対処法 |
|---|---|---|
| Fabric データエージェントが一覧に出ない | 未公開、別テナント、別アカウント、権限不足 | 公開状態、サインインアカウント、テナント、Fabric ワークスペース権限を確認 |
| テストチャットで回答しない | 生成AIオーケストレーションが無効、説明文が曖昧 | オーケストレーションを有効化し、エージェント説明文を具体化 |
| 一部ユーザーだけ失敗する | User authentication で基になるデータソース権限が不足 | データエージェント権限とデータソース権限を両方確認 |
| 回答が浅い | 対象テーブルが広すぎる、ビジネス用語が不足 | 関連テーブルに絞り、説明文・指示・例を追加 |
| 全件取得できない | データエージェントは完全なデータ抽出用途ではない | レポート、SQL、エクスポート処理と使い分ける |
| 日本語質問で精度が安定しない | Fabric データエージェントは非英語を現在サポートしないとされている | グローバル運用では英語の質問例、説明文、指示を標準化する |
Microsoft の制限事項では、Fabric データエージェントが非構造化ファイルを直接扱わないこと、非英語を現在サポートしないこと、回答が最大25行・25列に制限されること、異なるリージョンの容量にあるデータソースではクエリを実行できない場合があることなどが示されています。(Microsoft Learn)
このため、日本語圏の組織であっても、グローバル利用や精度重視の用途では、データエージェント名、説明文、代表質問、メトリクス定義を英語で整備する選択肢を検討すべきです。ユーザー向けの案内は日本語で用意しつつ、エージェント設定は英語中心にするハイブリッド運用が現実的です。
本番導入前のチェックリスト
本番に近づける前に、次のチェックリストで抜け漏れを確認してください。
| 項目 | 確認 |
|---|---|
| スコープ | 最初の対象業務、対象データ、対象ユーザーを限定している |
| データ品質 | 質問に必要なテーブル、列、メトリクス定義が整理されている |
| 説明文 | Fabric データエージェントの説明が、用途・対象データ・不得意領域まで具体的に書かれている |
| 権限 | 利用者、作成者、管理者の権限を分けて確認している |
| 認証方式 | User authentication と Agent author authentication の違いを検証している |
| ガバナンス | RLS、CLS、Purview、DLP、監査要件を確認している |
| チャネル | まず Teams で検証している |
| テスト質問 | 正常系、権限不足、曖昧な質問、対象外質問を試している |
| 運用 | 回答不備の報告先、改善サイクル、公開版と下書き版の管理方法を決めている |
Fabric データエージェントは、公開すると読み取り専用の公開版を共有でき、下書き版は改善を続けられる構成です。Microsoft の共有ドキュメントでは、公開版とドラフト版を切り替えて同じ質問をテストし、変更の効果を比較できることも説明されています。(Microsoft Learn)
よくある質問
Fabricデータエージェント自体はGAですか？
Microsoft の概念ドキュメントでは、Microsoft Fabric のデータエージェント自体は一般提供機能として説明されています。一方、Copilot Studio で Fabric データエージェントを使用する今回の機能はプレビューです。導入判断では、この2つのステータスを分けて考える必要があります。(Microsoft Learn)
Microsoft 365 Copilotでそのまま使えますか？
Copilot Studio のカスタム AI エージェントに接続した Fabric データエージェント構成は、Microsoft 365 Copilot では現在サポートされておらず、Teams で検証済みとされています。一方、Fabric データエージェントを Microsoft 365 Copilot の Agent Store に公開して直接使う別ルートは存在します。(Microsoft Learn)
SQLやDAXを書けないユーザーでも使えますか？
使えます。Fabric データエージェントは自然言語の質問から SQL、DAX、KQL などの問い合わせ生成を支援します。ただし、ユーザーがクエリを書かなくてよいだけで、データ定義や権限設計が不要になるわけではありません。データチームは、回答が正しいデータソースとロジックに基づくように設計・検証する必要があります。(Microsoft Learn)
日本語だけで運用できますか？
慎重に検証すべきです。Microsoft の制限事項では、Fabric データエージェントは現在非英語をサポートしないとされています。日本語圏で使う場合も、エージェントの説明文、指示、代表質問、メトリクス名は英語を基本にし、利用者向けガイドで日本語の質問例を補助する構成が現実的です。(Microsoft Learn)
まず何から始めるべきか
Microsoft Fabric Copilot Studio データエージェント連携を試すなら、最初にやるべきことは全社展開ではなく、小さな業務テーマでのPoCです。おすすめは、既に品質管理されている Power BI セマンティックモデル、または利用範囲が明確なレイクハウス・ウェアハウスを1つ選び、Teams 上で5〜10個の代表質問に答えられるかを検証することです。
そのうえで、データエンジニアはデータソースと説明文を整備し、DBAや管理者は権限・監査・ガバナンスを確認し、分析リーダーは現場ユーザーがどの業務判断に使えるかを評価します。プレビュー段階では、便利さよりも「安全に使える範囲」を先に決めることが成功の近道です。
コメント