2026年5月13日に確認されたMicrosoft 365 Copilot関連の公式情報で押さえるべきポイントは、Microsoft FabricのFabric data agentをMicrosoft 365 CopilotのAgent Storeに公開し、Teams上のCopilotから組織データへ自然言語で質問できるという点です。Microsoft Learn英語版では該当ページが「2026-05-12更新」と表示されており、時差や掲載タイミングにより国内での確認日とずれる場合があります。重要なのは、Fabric data agentそのものではなく、Microsoft 365 Copilotから利用する導線がプレビューとして案内されていることです。(Microsoft Learn)
この更新は、データ分析担当者だけでなく、Teamsで日常的に業務を進める営業、経理、CS、企画部門にも影響します。一方で、テナント設定、Fabric容量、Agent Store、データ権限、Purviewポリシーの確認をせずに展開すると、「エージェントが見えない」「共有したのに回答できない」「期待した表現と違う回答になる」といった問題が起きやすくなります。
Microsoft 365 CopilotからFabric data agentを使えると何が変わるのか
今回の公式情報で整理された内容は、Microsoft Fabricで作成したFabric data agentをMicrosoft 365 CopilotのAgent Storeに公開し、ユーザーがTeams上のCopilotから利用できるようにする流れです。Fabric data agentを公開する際に「Publish to Agent Store」を選ぶと、Microsoft 365 Copilot側のAgent Storeに表示され、ユーザーは直接チャットしたり、メインのCopilotチャットで@メンションして呼び出したりできます。(Microsoft Learn)
つまり、これまでFabricやPower BIの画面に入って確認していたデータ探索の一部を、Microsoft 365 Copilotの会話体験に寄せられます。たとえば、営業担当者がTeams上で「今月の地域別売上の上位5件を教えて」と質問し、Fabric上の許可されたデータから回答を得る、といった使い方が想定されます。
ただし、これは「誰でも全社データに質問できるようになる」という意味ではありません。公式情報では、ユーザーが見られる結果は基盤データへのアクセス権に基づき、行レベルセキュリティや列レベルセキュリティも尊重されると説明されています。共有時も、相手にはdata agent本体だけでなく、接続先データソースへの適切な権限が必要です。(Microsoft Learn)
| 観点 | 従来の利用イメージ | Microsoft 365 Copilot連携後の利用イメージ |
|---|---|---|
| 利用場所 | Fabric、Power BI、Notebookなど | TeamsやMicrosoft 365 Copilotのチャット |
| 主な利用者 | データ担当者、BI担当者、開発者 | 業務部門の一般ユーザーにも広がる |
| 操作方法 | レポート閲覧、SQL/DAX/KQL、Fabric画面操作 | 自然言語で質問、@でエージェント呼び出し |
| 権限制御 | FabricやPower BIの権限に依存 | 基盤データの権限、RLS/CLS、管理者設定を継承 |
| 注意点 | データモデル設計と権限管理 | Agent Store公開、Copilot拡張、回答変化への対策も必要 |
プレビュー機能として理解すべき範囲
この機能は公式ページでpreviewと明記されています。プレビュー段階では、一般提供済み機能と比べて仕様や管理画面、制限事項が変わる可能性があります。全社展開を急ぐより、まずは対象部門・対象データ・対象質問を絞った検証から始めるのが現実的です。(Microsoft Learn)
ここで混同しやすいのは、Fabric data agent自体の位置づけです。Microsoft Fabricの概念ページでは、Fabric data agentは組織内のデータに対して会話型Q&Aを構築する機能として説明されています。一方、今回のテーマである「Microsoft 365 CopilotからFabric data agentを利用する」体験はプレビューとして扱われています。(Microsoft Learn)
実務上は、次のように切り分けると判断しやすくなります。
| 項目 | 判断のポイント |
|---|---|
| Fabric data agentの作成・検証 | Fabric側でデータソース、テーブル、指示、例示クエリを設計する |
| Microsoft 365 Copilotでの利用 | Agent Store公開、Copilot拡張、Teams上での利用可否を確認する |
| 本番展開 | プレビュー機能であることを前提に、対象者を限定して段階展開する |
| 運用 | 回答品質、権限、監査、問い合わせ窓口を継続的に見直す |
利用に必要な前提条件
公式情報では、Microsoft 365 CopilotからFabric data agentを使うために複数の前提条件が示されています。主な条件は、Fabric容量、AI処理に関するテナント設定、データソース、ライセンス、同一テナント・同一アカウントでの利用です。(Microsoft Learn)
特に見落としやすいのは、Fabric側とMicrosoft 365 Copilot側の両方で条件を満たす必要があることです。Fabricでdata agentを作れたとしても、Microsoft 365 Copilot側のAgent StoreやCopilot拡張設定が整っていなければ、ユーザーに表示されない場合があります。
| 確認項目 | 内容 | つまずきやすい点 |
|---|---|---|
| Fabric容量 | 有料のF2以上のFabric容量、またはFabricが有効なPower BI Premium P1以上 | 容量はあるがFabricが有効化されていない |
| AI関連テナント設定 | Azure OpenAIを使うCopilot/Data agent関連設定 | 地域外処理・保存の設定が必要なケースを見落とす |
| データソース | Warehouse、Lakehouse、Power BI semantic model、KQL database、mirrored database、ontologyなど | データはあるがユーザーにRead権限がない |
| ライセンス | Microsoft 365 CopilotライセンスまたはOffice 365商用サブスクリプション、利用者ごとの必要ライセンス | 作成者だけにライセンスがあり、利用者側が不足する |
| テナント | Fabric data agentとMicrosoft 365 Copilotが同一テナント | 別テナントや別アカウントでサインインしている |
| Copilot拡張 | Microsoft 365管理センター側でエージェント利用が許可されている | Agent Storeに表示されない原因になりやすい |
管理者が最初に確認すべき設定
管理者が最初に見るべき場所は、Microsoft Fabricの管理ポータルとMicrosoft 365管理センターです。Fabric側では、data agentを使うためのテナント設定、CopilotとAzure OpenAI関連の設定、必要に応じた地域外処理・保存の設定を確認します。Microsoftの公式情報では、Fabricのテナント設定を有効にしてから反映まで最大1時間かかる場合があるとされています。(Microsoft Learn)
Fabric管理ポータルで確認する設定
Fabric管理ポータルでは、少なくとも次の観点を確認します。
| 設定 | 確認内容 | 実務上の判断基準 |
|---|---|---|
| Users can use Copilot and other features powered by Azure OpenAI | Fabric data agentを含むCopilot関連機能をユーザーが使えるか | 全社有効化ではなく、まず対象セキュリティグループで検証する |
| Capacities can be designated as Fabric Copilot capacities | 対象容量をCopilot用として指定できるか | 本番・検証用の容量を分け、負荷を観察する |
| Data sent to Azure OpenAI can be processed outside your capacity’s geographic region | 地域外処理が必要な環境か | データ所在地、社内規程、顧客契約を確認してから有効化する |
| Data sent to Azure OpenAI can be stored outside your capacity’s geographic region | 地域外保存が必要な機能を使うか | 法務・セキュリティ部門の確認を通す |
| Conversation history stored outside your capacity’s geographic region | 会話履歴の保存を許容するか | 会話履歴の扱い、削除手順、利用者周知をセットで決める |
会話履歴について、公式情報では、完全な会話型エージェント体験にはセッションをまたいだ履歴保存が必要になる場合があり、ユーザーが許可する範囲で、手動削除しない場合は最大28日まで保存されると説明されています。ユーザーはチャットをクリアすることで会話履歴を削除できます。(Microsoft Learn)
Microsoft 365管理センターで確認する設定
Microsoft 365管理センターでは、エージェントの可用性、アクセス、ブロック、割り当て、削除などを管理できます。公式情報では、Microsoft 365 Copilotライセンスを持つテナントでは該当機能が既定で有効と説明されていますが、実際の展開では組織のポリシーや管理者設定の影響を受けます。(Microsoft Learn)
管理者ロールとしては、AI Adminが編集に関わる管理ロールとして示され、Global Readerは表示専用です。Microsoftは、必要最小権限のロール利用を推奨しており、Global Administratorの利用は緊急時などに限定すべきとしています。(Microsoft Learn)
Microsoft 365管理センターのAgent settingsでは、許可するエージェント種別、共有、ユーザーアクセスなどを制御できます。たとえば、組織で作成したエージェントをユーザーに使わせるには、「apps and agents built by your organization」に該当する設定や、ユーザーアクセスの範囲を確認する必要があります。(Microsoft Learn)
開発者・データ担当者が準備すべきこと
開発者やデータ担当者の作業は、単にFabric data agentを作るだけではありません。Microsoft 365 Copilotで使われることを前提に、データソース、権限、説明文、指示、例示クエリ、回答の検証観点を設計する必要があります。
Fabric data agentは、Lakehouse、Warehouse、Power BI semantic model、KQL database、ontology、Microsoft Graphなどのデータに対して自然言語で質問できる会話型分析コンポーネントとして説明されています。仕組みとしては、ユーザーの質問、スキーマ情報、開発者が与えた指示や例をもとに、SQL、DAX、KQL、Microsoft Graphなどの適切な手段で問い合わせを組み立てます。(Microsoft Learn)
データソースは「多くつなぐ」より「答えやすく絞る」
Fabric data agentには最大5つまでデータソースを追加できます。複数のPower BI semantic modelだけで構成することも、Lakehouse、semantic model、KQL databaseを組み合わせることも可能です。(Microsoft Learn)
ただし、実務では「つなげるだけつなぐ」より、質問の用途に合わせて絞るほうが精度を上げやすくなります。たとえば、営業KPI用のdata agentなら、売上、顧客、商品、営業組織、期間に関係するテーブルを中心にし、在庫や人事データを同じagentに混ぜないほうが、質問意図の解釈が安定します。
Microsoftの作成ガイドでも、テーブル名や列名は説明的な名前にすることが推奨されています。TableAやC1のような名前より、SalesData、ActiveCustomer、IsCustomerActiveのような名前のほうが、AIが正確なクエリを生成しやすくなります。(Microsoft Learn)
Power BI semantic modelはRead権限の扱いに注意する
Power BI semantic modelをdata agent経由で利用する場合、公式情報では、ユーザーはsemantic modelへのRead権限があれば質問でき、Build権限やワークスペースのMemberロールは不要と説明されています。ただし、semantic modelを変更したり、Prep for AIのような機能を使ったりする場合はWrite権限が必要です。(Microsoft Learn)
これは展開時の影響が大きいポイントです。従来、レポート作成やExcel分析の文脈でBuild権限を広く付与していた組織では、data agent用のアクセス設計を見直せる可能性があります。一方で、「Readだけで質問できるなら安全」と短絡的に判断するのは危険です。質問によっては、ユーザーが見られる範囲のデータを要約・集計して返すため、RLS、CLS、Purviewポリシー、感度ラベル、DLPの設計を合わせて確認する必要があります。
指示文と説明文はCopilot連携を前提に書く
Fabric data agentでは、data agent instructionsとして平易な英語テキストで最大15,000文字の指示を追加できます。用途別にどのデータソースを使うか、業務用語をどう解釈するか、特定の指標をどう計算するかを明確にしておくと、回答品質を上げやすくなります。(Microsoft Learn)
Microsoft 365 Copilotに公開する場合は、公開時の説明文も重要です。公式情報では、Microsoft 365 Copilot側には独自のオーケストレーターがあり、チャット文脈、ユーザー意図、モデルの推論を使って最終回答を形成すると説明されています。data agentの出力をできるだけ変えずに扱いたい場合は、公開時の説明文に「要約、言い換え、追加解釈をせず、そのまま返す」といった指示を入れることで、変化を抑えることができます。ただし、最終回答には一定の変化が避けられないとされています。(Microsoft Learn)
実務では、次のような説明文をベースにすると検証しやすくなります。
This Fabric data agent answers questions about monthly sales, customer segments, and product performance based only on the configured governed data sources. Return numerical results as-is when possible. Do not summarize, rephrase, or add interpretation unless the user explicitly asks for analysis. If the requested metric is ambiguous, ask a clarification question before answering.日本語ユーザー向けに展開する場合でも、Fabric data agentの制限として、公式の概念ページでは現時点で非英語をサポートしておらず、最適なパフォーマンスのためには質問、指示、例示クエリを英語で提供するよう説明されています。日本語の質問でどこまで実用に耐えるかは、部門ごとの実データで必ず検証してください。(Microsoft Learn)
展開手順：小さく作って、権限を確認してからAgent Storeへ公開する
Microsoft 365 Copilot連携の展開は、いきなり全社公開するより、検証用data agentを作成し、限られたユーザーで回答精度と権限を確認してから進めるのが安全です。
| 手順 | 作業内容 | 完了条件 |
|---|---|---|
| 事前設計 | 対象業務、対象データ、利用者、禁止質問を決める | 「何に答えるagentか」が1文で説明できる |
| Fabric設定確認 | 容量、Copilot/Azure OpenAI設定、地域外処理設定を確認する | 管理者が設定値と影響範囲を記録している |
| data agent作成 | データソースとテーブルを追加し、指示文を設定する | 想定質問に対して正しいデータソースを使える |
| 権限テスト | 作成者、一般利用者、権限のないユーザーで回答差分を確認する | 見えてはいけないデータが返らない |
| 回答品質テスト | よくある質問、曖昧な質問、範囲外の質問を試す | 回答、拒否、確認質問の挙動を把握できる |
| 公開 | Fabric data agentを公開し、必要に応じてAgent Storeに公開する | Microsoft 365 CopilotのAgent Storeに表示される |
| Microsoft 365管理 | エージェント種別、ユーザーアクセス、共有設定を確認する | 対象ユーザーだけが使える |
| パイロット運用 | Teams上で@メンションや直接チャットを試す | 問い合わせ、誤回答、権限問題の記録がある |
| 本番展開 | 対象部門を広げ、利用ルールを周知する | 運用担当、問い合わせ先、見直し頻度が決まっている |
作成ガイドでは、data agentをテストし、SQL/DAX/KQLの生成が正確であることを確認してから公開する流れが示されています。公開後は、ドラフト版を改善しながら、公開版を利用者に共有できます。(Microsoft Learn)
共有時に必ず説明すべき権限の考え方
Teamsでリンクを共有できるようになると、利用者は「リンクを受け取ったから使える」と考えがちです。しかし、Fabric data agentの共有では、相手がagent本体にアクセスできるだけでなく、基盤となるデータソースにもアクセスできる必要があります。Microsoftの公式情報でも、この点が明確に注意されています。(Microsoft Learn)
たとえば、営業部門向けのdata agentを経理部門のユーザーに共有しても、そのユーザーが接続先のsemantic modelやwarehouseにRead権限を持っていなければ、期待どおり回答できません。逆に、権限を広く付与しすぎると、会話形式で集計結果を得られるため、従来より情報取得のハードルが下がります。
共有前には、次の3点を利用者向け説明に含めるとトラブルを減らせます。
- data agentの共有リンクは、基盤データへの権限を自動付与しない
- 回答はユーザー本人の権限に基づくため、人によって結果が異なる場合がある
- 機密データや個人情報を含む質問は、社内ルールに従って扱う
よくある失敗と対処法
Microsoft 365 Copilot連携では、機能そのものよりも、設定・権限・期待値のずれでつまずくケースが多くなります。
| 症状 | 主な原因 | 対処 |
|---|---|---|
| Agent StoreにFabric data agentが表示されない | Agent Storeに公開していない、反映待ち、Copilot拡張が無効、対象ユーザーではない | Publish to Agent Storeの有無、Microsoft 365管理センターのエージェント設定、ナビゲーション更新を確認する |
| 共有されたが回答できない | data agent本体または基盤データソースへの権限不足 | data agentとデータソースの両方の権限を確認する |
| 作成者と利用者で回答が違う | ユーザーごとのデータ権限、RLS/CLS、Purviewポリシーが異なる | 役割別にテストユーザーを用意し、想定結果を比較する |
| 回答が要約されすぎる | Microsoft 365 Copilotのオーケストレーターが最終回答を整形している | 公開説明文で「as-is」返却や追加解釈を避ける指示を入れる |
| 日本語質問の精度が安定しない | Fabric data agent側の非英語サポート制限 | 指示文・例示クエリを英語で整備し、日本語質問は検証範囲を限定する |
| 質問が高度すぎて答えられない | 因果分析、機械学習、外部要因分析を期待している | 「保存済みデータを構造化クエリで取得する用途」と説明する |
| Notebook連携で容量を消費し続ける | ポーリングの無限ループ、セッション停止漏れ | タイムアウト、ポーリング間隔、スレッド削除、Notebook停止を実装する |
公式情報では、Fabric data agentはSQL、DAX、KQLの読み取りクエリのみを生成し、データの作成・更新・削除は行わないと説明されています。また、PDF、DOCX、TXTのような非構造化データはサポート対象外で、LakehouseのCSVやJSONファイルも、テーブルとして取り込むか公開しなければ直接参照できません。(Microsoft Learn)
セキュリティとガバナンスで確認すべきポイント
Microsoft 365 Copilotから使えるようになると、データへの入口が増えます。これは利便性の向上である一方、ガバナンス設計を曖昧にしたまま展開すると、利用者が「聞けば何でも分かる」と誤解しやすくなります。
Fabric data agentは、ユーザーの資格情報と権限に基づいてスキーマを参照し、許可された範囲のデータに問い合わせます。Microsoft PurviewのDLPやアクセス制限ポリシーが適用される場合、それらもagentのアクセスや返却結果に影響します。(Microsoft Learn)
特に確認すべき項目は次のとおりです。
| 領域 | 確認内容 |
|---|---|
| データ分類 | agentが参照するデータに機密情報、個人情報、顧客契約上の制約がないか |
| Purviewポリシー | DLP、感度ラベル、アクセス制限、監査、eDiscovery、保持ポリシーの対象か |
| RLS/CLS | 行レベル・列レベルの制御が期待どおり反映されるか |
| 共有範囲 | Teamsチャネルやグループチャットで共有してよいagentか |
| 会話履歴 | 履歴保存、削除、監査、ユーザー周知のルールがあるか |
| 管理者権限 | AI Adminなど最小権限で運用できているか |
| 外部接続 | agentのアウトバウンド接続が組織の許可範囲に収まっているか |
開発・運用チームはALMを前提に管理する
Fabric data agentは、一度作って終わりのチャットボットではありません。データ構造、KPI定義、部門ルール、利用者の質問は変わります。公式情報では、診断、Git統合、デプロイメントパイプラインなど、ALMやDevOps向けの機能が説明されています。(Microsoft Learn)
本番利用を見据えるなら、少なくとも開発・検証・本番の環境を分け、次のような運用ルールを作るべきです。
| 運用項目 | 推奨ルール |
|---|---|
| 指示文の変更 | Gitで変更履歴を残し、誰が何を変えたか追跡する |
| データソース変更 | 本番反映前に、代表質問セットで回帰テストを行う |
| 例示クエリ追加 | 業務部門からのよくある質問をもとに追加する |
| 回答品質確認 | 誤回答、曖昧回答、権限エラーを分類して改善する |
| 本番公開 | Fabric deployment pipelinesで段階的に昇格する |
| 利用停止 | owner不在、古いデータ、不要なagentを定期的に棚卸しする |
Microsoft 365管理センター側でも、エージェントの一覧、公開、展開、ブロック、削除などを管理できます。組織内でagentが増えるほど、所有者不明、重複、古い業務定義の放置が起きやすくなるため、Agent Storeに出す前に命名規則と所有者ルールを決めておくと運用が安定します。(Microsoft Learn)
利用者へ案内するときの説明例
一般ユーザーに案内するときは、技術的な仕組みより「何ができるか」「何はできないか」「どう質問すればよいか」を明確に伝えるのが効果的です。
たとえば、営業部門向けには次のように説明できます。
このCopilotエージェントでは、営業実績、顧客セグメント、商品別売上について質問できます。
TeamsのMicrosoft 365 Copilotでエージェントを選ぶか、@メンションして質問してください。
良い質問例:
- What were the top 10 products by sales amount last month?
- Show monthly sales by region for FY2025.
- Which customer segment had the highest revenue in Q4?
注意:
- 回答はあなたのデータ権限に基づきます。
- 他の人と結果が異なる場合があります。
- 原因分析や将来予測ではなく、登録済みデータの集計・確認に使ってください。日本語利用者向けには、日本語質問を許可するかどうかを検証後に決めるべきです。公式情報上、Fabric data agentの最適なパフォーマンスには英語の質問、指示、例示クエリが推奨されているため、最初の展開では英語の質問テンプレートを配布し、利用者から集まった日本語の質問を開発チームが英語の指示や例示クエリに反映する運用が現実的です。(Microsoft Learn)
今回の更新で管理者・開発者が取るべき次の行動
Microsoft 365 CopilotからFabric data agentを利用できるようになると、業務部門はTeams上でデータにアクセスしやすくなります。一方で、これは「便利な入口が増える」だけでなく、Agent Store、データ権限、Copilot拡張、Purview、回答品質を横断して管理する必要があるという意味でもあります。
まずは、次の順番で進めるのが安全です。
- 対象業務を1つ選び、回答すべき質問を10〜20個に絞る
- Fabric容量、テナント設定、Microsoft 365管理センターのAgent設定を確認する
- 最小限のデータソースでFabric data agentを作成する
- 作成者、一般利用者、権限なしユーザーで回答と権限を検証する
- 公開説明文で、Copilot側の要約・解釈をどこまで許容するか明記する
- PilotユーザーだけにAgent Store公開し、問い合わせと誤回答を記録する
- ALM、所有者、棚卸し、利用停止ルールを決めてから対象部門を広げる
特に日本語圏の企業では、「Teamsで日本語で聞ける便利なデータAI」として期待されやすい反面、Fabric data agent側の非英語サポート制限、プレビュー機能としての不確実性、データ権限の誤解が展開リスクになります。最初のゴールは全社展開ではなく、権限が守られ、代表的な質問に安定して答えられる小さな成功パターンを作ることです。
コメント