Microsoft 365 Copilot と Microsoft Fabric／Power BI を組み合わせて使う企業で、Copilot 利用量の請求先が分散して分かりにくい場合は、「Fabric Copilot Capacity」を確認すべきです。2026年6月30日に更新された Microsoft Learn の公式情報では、Power BI Desktop、Power BI Pro、Premium Per User（PPU）ワークスペース、Fabric ワークロードで発生する Copilot やデータエージェントの利用量を、指定した単一の Fabric 容量に集約して課金・監視できる仕組みとして整理されています。これはエンドユーザー向けの新しいチャット機能ではなく、管理者向けの「課金先・監視・ガバナンス」を整えるための更新です。(Microsoft Learn)
特に、Power BI Desktop で Copilot を使う部門が増えている組織、Pro／PPU ワークスペースを多く運用している組織、Microsoft 365 Copilot や Copilot Studio から Fabric data agents を利用する構成を検討している組織では、早めに設定方針を決めておく価値があります。Fabric data agents は Microsoft 365 Copilot など Fabric 以外のサービスから利用される場合があり、その場合は Fabric のコンプライアンス境界や地理的リージョンの外へ応答が送られる可能性があるため、単なる課金設定ではなく、データガバナンス上の確認項目として扱うべきです。(Microsoft Learn)
Fabric Copilot Capacity とは何か
Fabric Copilot Capacity は、特定のユーザーグループによる Copilot と data agent の利用量を、指定した Fabric 容量にまとめて請求するための仕組みです。通常、Fabric では Copilot の利用量はユーザーが操作しているコンテンツを保持する容量に課金されます。そのため、複数部門がそれぞれ別の Fabric 容量や Power BI 容量を使っていると、Copilot 利用コストが組織内に分散し、費用配賦や監視が難しくなります。Fabric Copilot Capacity を使うと、この Copilot 利用量を一つの容量に集約できます。(Microsoft Learn)
実務上のポイントは、「どのワークスペースにコンテンツがあるか」ではなく、「対象ユーザーがどの Copilot 容量に割り当てられているか」で Copilot 利用量の請求先を制御できることです。ユーザーが割り当てられると、追加操作なしでそのユーザーの Copilot 利用量が指定容量に自動的に計上されます。(Microsoft Learn)
| 確認項目 | 内容 | 管理者にとっての意味 |
|---|---|---|
| 主な目的 | Copilot と data agent の利用量を単一容量に集約 | 部門別・プロジェクト別の費用配賦を設計しやすい |
| 対象ユーザー | Fabric Copilot Capacity に割り当てたユーザー | ユーザーグループ単位で課金先を制御する |
| 対象シナリオ | Power BI Desktop、Power BI Pro／PPU ワークスペース、Fabric 容量ワークスペースなど | Power BI 利用部門にも影響がある |
| エンドユーザー操作 | 割り当て後の追加操作は不要 | 利用者教育よりも管理者設定が重要 |
| 監視 | Fabric Capacity Metrics app で容量消費を確認 | 利用開始後の継続監視が必要 |
今回の更新で確認すべきポイント
今回の公式情報で重要なのは、Fabric Copilot Capacity が「Power BI Desktop、Pro、PPU ワークスペースを含む Copilot 利用量の集約先」として明確に説明された点です。Power BI Desktop の Copilot 利用は、従来のワークスペース容量ベースの理解だけでは把握しにくい場面があります。Fabric Copilot Capacity を指定すれば、対象ユーザーの Copilot AI 消費を一つの容量にまとめ、管理者が利用傾向を追いやすくなります。(Microsoft Learn)
ただし、これは Microsoft 365 Copilot のライセンス費用そのものを Fabric 容量に移す仕組みではありません。Word、Excel、Teams などの Microsoft 365 Copilot 利用料を Fabric 容量で支払う機能ではなく、Microsoft Fabric／Power BI 側の Copilot と data agent 利用量をどの Fabric 容量に計上するかを制御する仕組みです。
また、Power BI 向けの公式情報では、Fabric Copilot Capacity は Copilot AI 消費、つまりプロンプト処理や応答生成に対して課金され、セマンティックモデルへのクエリなど下流の処理は、そのセマンティックモデルが存在する容量に課金されると説明されています。ここを誤解すると、「Copilot 容量に集約したはずなのに、別容量の使用率が上がっている」と混乱しやすくなります。(Microsoft Learn)
影響範囲：誰が何を確認すべきか
Fabric Copilot Capacity の影響は、Fabric 管理者だけに限られません。Power BI の管理者、容量管理者、情報システム部門、セキュリティ・コンプライアンス担当、費用配賦を行う経理・IT企画部門にも関係します。
| 役割 | 確認すべきこと | 失敗しやすいポイント |
|---|---|---|
| Fabric 管理者 | Copilot と Azure OpenAI 関連のテナント設定 | Copilot を有効化すると、Power BI だけでなく Fabric ワークロード全体に影響する点を見落とす |
| 容量管理者 | Copilot 容量として指定する容量、対象ユーザー、監視方法 | 小さすぎる容量に集約し、スロットリングや利用制限の原因を作る |
| Power BI 管理者 | Power BI Desktop、Pro、PPU ワークスペースの利用状況 | Desktop 利用分が見えにくく、コスト予測から漏れる |
| セキュリティ担当 | リージョン、データ処理、会話履歴、メタデータの扱い | グローバル利用時の越境データ処理設定を未確認のまま有効化する |
| 経理・IT企画 | Copilot 利用量の費用配賦ルール | 「誰の利用をどの部門費用にするか」を後から決めようとして揉める |
Fabric Copilot Capacity では、利用量や請求記録に Fabric アイテム名やワークスペース名などのメタデータが含まれ、Copilot 容量の管理者が確認できる場合があります。監査や費用配賦には有用ですが、部門横断で管理する場合は、どの管理者にどこまで見せるかを事前に決めておくべきです。(Microsoft Learn)
対応しているシナリオ
公式情報では、Fabric Copilot Capacity に割り当てられたユーザーが利用できる主なシナリオとして、Power BI Desktop の Copilot、Power BI の Pro／PPU／Fabric 容量ワークスペースでの Copilot、F64 未満の Fabric 容量ワークスペースにおける Fabric Copilot、data agents などが挙げられています。対象ワークロードには Data Factory、Data Engineering、Data Warehouse、Data Science、Real-Time Intelligence、Activator が含まれます。(Microsoft Learn)
特に注目したいのは、Power BI Pro や PPU ワークスペースを多く使っている組織です。従来は「Copilot を使うには大きな容量が必要」という印象が先行しがちでしたが、Fabric Copilot Capacity を設計することで、Power BI Desktop や Pro／PPU ワークスペースからの Copilot 利用量を一元管理しやすくなります。
| 利用場面 | Fabric Copilot Capacity の意味 |
|---|---|
| Power BI Desktop でレポート作成を支援する | Desktop 側の Copilot 利用量を指定容量に集約しやすい |
| Pro ワークスペースで Copilot を使う | ワークスペース単位ではなく、ユーザー割り当てで課金先を整理できる |
| PPU ワークスペースで利用する | PPU 利用部門の Copilot コストを別途可視化しやすい |
| Fabric data agents を使う | データエージェント利用量の請求先を統制できる |
| 複数部門で Fabric を運用する | 部門別の容量消費と Copilot 消費を分けて考えられる |
設定変更で見るべきポイント
Fabric Copilot Capacity の有効化には、Fabric 管理者と容量管理者の両方が関係します。公式情報では、Fabric 管理者が組織内ユーザーに Copilot を有効化し、容量管理者が自分の容量を Copilot 容量として指定できるようにし、容量管理者が対象ユーザーグループを割り当てる流れが示されています。(Microsoft Learn)
設定前に確認すべき順序は、次のとおりです。
| 手順 | 確認内容 | 実務上の判断基準 |
|---|---|---|
| テナント設定を確認 | Copilot と Azure OpenAI Service 関連設定 | 全社展開か、特定グループ限定かを決める |
| 容量を選定 | Copilot 利用量を受ける Fabric 容量 | 既存業務負荷と Copilot 利用増を分けて考える |
| 管理者権限を確認 | Fabric 管理者、容量管理者 | 設定変更者と監視者を分けるか決める |
| 対象ユーザーを割り当て | 部門、プロジェクト、検証グループ | 最初は小さなグループで検証する |
| Metrics app で監視 | CU 使用量、ピーク、スロットリング | 利用開始後に容量サイズを見直す |
Fabric の管理ポータルでは、容量設定の中に「Copilot capacity」を指定する項目があり、容量の詳細設定や委任されたテナント設定を容量管理者が確認できます。容量設定にたどり着くには、Fabric で歯車アイコンから Admin portal を開き、Capacity settings を選択します。(Microsoft Learn)
制限事項と注意点
Fabric Copilot Capacity を導入する前に、制限事項を必ず確認してください。公式情報では、Fabric Copilot Capacity は Fabric テナントのホームリージョンでのみサポートされ、少なくとも F2 または P1 SKU の容量が必要とされています。また、Embedded ライセンスモードの容量はサポート対象外です。(Microsoft Learn)
さらに、1人のユーザーに対してサポートされる Fabric Copilot Capacity は一つだけです。複数の Copilot 容量に同じユーザーを割り当てた場合、最も新しく作成された Copilot 容量に利用量が記録されるとされています。部門別に費用配賦したい場合、同じユーザーが複数部門のプロジェクトに参加しているケースでは、割り当てルールを慎重に設計する必要があります。(Microsoft Learn)
| 注意点 | 起きやすい問題 | 対策 |
|---|---|---|
| ホームリージョン制約 | グローバル容量に同じ設定を展開できない | テナントのホームリージョンと容量配置を先に確認する |
| F2／P1 以上が必要 | 試用容量や小規模検証の前提が崩れる | 本番利用前に SKU と課金責任を確認する |
| Embedded は対象外 | Embedded 用途の容量に集約できると誤解する | Power BI Embedded 構成は別途設計する |
| 1ユーザー1 Copilot 容量 | 複数部門所属ユーザーの費用配賦が曖昧になる | Entra ID グループ設計と配賦ルールを統一する |
| AI Functions は対象外 | Fabric のすべての AI 消費が集約されると誤解する | Copilot／data agent と AI Functions を分けて監視する |
グローバル利用ではリージョンとデータ処理設定が重要
グローバル企業や日本を含む海外拠点で使う場合は、リージョンとデータ処理設定を必ず確認してください。Fabric の Copilot と Azure OpenAI Service 関連設定では、容量の地理的リージョン、コンプライアンス境界、国別クラウドインスタンスの外でデータを処理・保存できるかを制御する設定があります。これらの設定の一部は既定で無効化されているため、対象地域によっては Copilot が期待通りに使えない場合があります。(Microsoft Learn)
公式情報では、日本、アジア、オーストラリア、カナダ、インドなど一部の地域では、Copilot in Fabric の Azure OpenAI Service が米国側でホストされる扱いとなり、利用には Copilot の有効化に加えて越境データ処理設定が必要になるケースが示されています。日本企業が国内テナントで利用する場合も、「日本語で使えるか」だけでなく、「どの地域でプロンプトや応答が処理されるか」を確認する必要があります。(Microsoft Learn)
また、会話履歴を保持する Copilot in notebooks や Fabric data agents では、ユーザーセッションをまたいで文脈を維持するために会話履歴が保存される場合があります。履歴はユーザーが削除でき、手動削除されない場合は一定期間保存されると説明されています。セキュリティレビューでは、プロンプト、スキーマ、会話履歴、アイテム名など、どの情報が処理・保存・監視対象になるかを確認してください。(Microsoft Learn)
移行期限はあるのか
Fabric Copilot Capacity そのものについて、2026年6月30日時点の公式ページでは、特定の日付までに必ず移行しなければならない期限は示されていません。したがって、すぐに既存環境が使えなくなる変更ではなく、Copilot 利用量の課金・監視を整理したい組織が計画的に導入する管理機能として捉えるのが現実的です。(Microsoft Learn)
ただし、Power BI Premium per capacity の P SKU を使っている組織は別です。Microsoft は Power BI Premium P SKU を段階的に Fabric 容量へ移行する方針を示しており、既存顧客は契約更新時に F SKU への移行を Microsoft 担当者と相談する必要があります。P SKU が自動的に Fabric 容量へ変換されるわけではなく、新しい Fabric 容量を購入したうえで、ワークスペースを再割り当てする必要があります。(Microsoft Learn)
Power BI Premium のサブスクリプション終了後には、一定期間アクセスや移行を支援する猶予が説明されていますが、移行中にワークスペースを新しい容量へ割り当て直すとアクティブなジョブはキャンセルされるため、業務時間外の移行やジョブ再実行計画を用意しておくべきです。(Microsoft Learn)
管理者が最初に行うべき確認リスト
Fabric Copilot Capacity を検討する場合、いきなり全社有効化するよりも、対象範囲を絞って利用量と影響を測るほうが安全です。特に Copilot は使い始めると利用頻度が急に増える可能性があるため、容量サイズ、利用部門、予算、監視方法をセットで決める必要があります。
| 優先度 | 確認項目 | 具体的な作業 |
|---|---|---|
| 高 | Copilot 利用対象者 | Power BI 作成者、Fabric 開発者、data agent 利用者を洗い出す |
| 高 | 容量 SKU とリージョン | F2／P1 以上か、ホームリージョン要件を満たすか確認する |
| 高 | テナント設定 | Copilot、Azure OpenAI、越境データ処理、会話履歴関連設定を確認する |
| 中 | ユーザーグループ設計 | 部門別、プロジェクト別、検証用グループを分ける |
| 中 | 監視方法 | Microsoft Fabric Capacity Metrics app を導入・更新する |
| 中 | 費用配賦ルール | Copilot AI 消費と下流のセマンティックモデル処理を分けて説明する |
| 低 | 利用者向け案内 | Copilot 利用時の注意、プロンプトに入れてはいけない情報を周知する |
Microsoft Fabric Capacity Metrics app は、Fabric 容量の消費状況を監視し、容量のスケールアップや利用パターンの判断に役立ちます。利用データには通常 10〜15分程度の処理・更新遅延があり、新しい容量やワークスペースなどの情報は次回更新まで表示されない場合があります。リアルタイム監視ツールではない点に注意してください。(Microsoft Learn)
導入時に失敗しやすいポイント
最も多い失敗は、Fabric Copilot Capacity を「Copilot の利用を許可するスイッチ」と誤解することです。実際には、Copilot を使えるようにするテナント設定と、Copilot 利用量をどの容量へ課金するかの設定は分けて考える必要があります。Copilot と Azure OpenAI Service のテナント設定では、ユーザーが Copilot や Azure OpenAI ベースの機能を使えるか、容量を Copilot 容量として指定できるか、越境データ処理を許可するかなど、複数の設定が管理されています。(Microsoft Learn)
次に多いのは、費用集約だけを目的に小さな容量へ全社の Copilot 利用量を集めてしまうことです。Fabric Copilot Capacity は便利ですが、利用量が増えれば当然その容量に負荷が集まります。まずは部門単位や検証グループ単位で利用量を見て、Power BI Desktop の作成者、データエンジニア、データサイエンティストなど、利用頻度が高いユーザーを把握してから対象範囲を広げるべきです。
もう一つの落とし穴は、Microsoft 365 Copilot との境界を曖昧にすることです。Microsoft 365 Copilot、Copilot Studio、Fabric data agents、Power BI Copilot は連携する場面がありますが、課金体系やデータ処理の責任範囲は同じではありません。特に data agents を Microsoft 365 Copilot など Fabric 以外のサービスから利用する構成では、応答データの扱いが接続先サービスの条件に従う可能性があります。(Microsoft Learn)
よくある疑問
Microsoft 365 Copilot の料金も Fabric 容量に集約されるのか
集約されません。Fabric Copilot Capacity は、Microsoft Fabric／Power BI 側の Copilot と data agent 利用量を指定した Fabric 容量に請求するための仕組みです。Microsoft 365 Copilot のユーザーライセンス費用や、Word、Excel、Teams などでの利用を直接 Fabric 容量に移すものではありません。
Power BI Desktop の Copilot 利用も対象になるのか
対象になります。公式情報では、Power BI Desktop の Copilot 利用が Fabric Copilot Capacity の対応シナリオに含まれています。Power BI Desktop の利用者が多い組織では、レポート作成者グループを先に割り当てて利用量を確認すると、容量設計の判断がしやすくなります。(Microsoft Learn)
F64 以上の容量が必須なのか
Fabric Copilot Capacity 自体は、少なくとも F2 または P1 SKU の容量が必要とされています。一方で、Power BI や Fabric の Copilot 利用条件はワークロード、リージョン、テナント設定、容量設定によって変わるため、「F2 ならすべて問題ない」と単純化せず、対象シナリオごとに公式要件を確認する必要があります。(Microsoft Learn)
既存の Power BI Premium P SKU からすぐ移行する必要があるのか
Fabric Copilot Capacity の設定自体に即時の移行期限は示されていません。ただし、Power BI Premium P SKU は Fabric 容量への移行方針が示されており、契約更新時に F SKU への移行を検討する必要があります。既存の P SKU が自動的に Fabric 容量へ変わるわけではないため、容量購入とワークスペース再割り当ての計画が必要です。(Microsoft Learn)
まずは小さく検証し、課金・監視・ガバナンスを分けて設計する
Fabric Copilot Capacity は、Microsoft 365 Copilot 時代のデータ活用基盤において、Copilot 利用量を管理しやすくする重要な仕組みです。ただし、導入の目的は「Copilot を使えるようにすること」ではなく、「誰の Copilot 利用量を、どの容量で、どのように監視・配賦するか」を明確にすることです。
最初に行うべきことは、対象ユーザーと対象ワークロードを絞ることです。Power BI Desktop の作成者、Pro／PPU ワークスペースの利用部門、Fabric data agents を使うチームを洗い出し、テナント設定、容量 SKU、リージョン、越境データ処理、監視方法を確認します。そのうえで、小さなユーザーグループを Fabric Copilot Capacity に割り当て、Microsoft Fabric Capacity Metrics app で利用傾向を見ながら拡大していくのが安全です。
Copilot の活用が広がるほど、便利さだけでなくコストとデータ管理の重要性も増します。Fabric Copilot Capacity は、その両方を管理者がコントロールしやすくするための機能として、早めに設計方針を決めておくべき更新ポイントです。
コメント