Microsoft 365 Copilot Chatでエージェント利用を始める企業にとって、今回のポイントは「前払いのCapacity Packsだけで運用する」「Pay-as-you-go課金だけで運用する」「前払いを優先し、不足分だけ従量課金に逃がす」という3つの選択肢を明確に選べるようになったことです。
特に管理者が押さえるべき結論はシンプルです。予算超過を絶対に避けたい部門はCopilot credit policyのみ、業務停止を避けたい本番部門はCopilot credit policy＋Pay-as-you-go、利用量が読めない検証段階はPay-as-you-goのみが現実的な選び方です。Microsoft Learnでは、Copilot Studio capacity packはMicrosoft 365 Copilot ChatとSharePoint agentsの利用に使えるCopilot Creditsを提供し、1パックあたり月25,000 creditsとして説明されています。(Microsoft Learn)
Microsoft 365 Copilot Chatの課金方式で何が変わったのか
Microsoft 365 Copilot Chatのエージェント利用では、これまで「Azureサブスクリプションに紐づくPay-as-you-go課金を前提に考える」場面が多くありました。今回の公式情報で重要なのは、Copilot credit policyを使うことで、Pay-as-you-goを必須にせず、前払いCapacity Packsのクレジットだけを特定ユーザーや部門に割り当てられる点です。
Microsoftの説明では、管理者は次の3構成から選べます。1つ目はCopilot credit policyのみ、2つ目はCopilot credit policyとPay-as-you-go billing policyの併用、3つ目はPay-as-you-go billing policyのみです。Copilot credit policyのみの場合はAzureサブスクリプションが不要で、前払いクレジットが尽きると対象ユーザーのCopilot Chatは次の請求サイクルでクレジットが補充されるまで利用できなくなります。(Microsoft Learn)
この変更は、単なる請求方法の追加ではありません。部門ごとのAI利用予算、試験導入、本番展開時の継続性、Azure課金の統制に直接関わります。Microsoft 365 Copilotを社内展開する管理者は、「誰に使わせるか」だけでなく、「どの予算枠で、どこまで使わせるか」まで設計する必要があります。
Prepaid Capacity Packs、Pay-as-you-go、Copilot credit policyの違い
混乱しやすいのは、Capacity Packs、Pay-as-you-go billing policy、Copilot credit policyがそれぞれ別の役割を持つ点です。名前が似ていますが、実務では次のように整理すると判断しやすくなります。
| 項目 | 役割 | 向いているケース | 注意点 |
|---|---|---|---|
| Prepaid Capacity Packs | Copilot Creditsを前払いで購入する容量パック | 月間利用量をある程度見込める部門、本番運用前の予算確保 | クレジットの割り当て設定が必要 |
| Pay-as-you-go billing policy | 利用した分をAzureサブスクリプションに従量課金する設定 | 利用量が読めない検証、繁忙期に利用が増える業務 | 予算設定は通知であり、利用停止の上限ではない |
| Copilot credit policy | 前払いクレジットを特定ユーザーやグループに紐づけるポリシー | 部門別の予算管理、対象ユーザーの限定 | Microsoft 365 Copilot Chat向けの機能として案内されている |
Copilot credit policyは、前払いで購入したクレジットを「誰が消費できるか」を決めるための管理単位です。Microsoft Learnでは、セキュリティグループ、配布グループ、テナント全体などをスコープにでき、テナントあたり最大10個まで作成できると説明されています。(Microsoft Learn)
一方、Pay-as-you-go billing policyは、Azureサブスクリプションやリソースグループと結びつく従量課金のための設定です。Microsoft 365 admin centerでは、billing policyを作成してからCopilotサービスへ接続する流れになっています。(Microsoft Learn)
3つの課金構成をどう選ぶべきか
予算超過を避けたいならCopilot credit policyのみ
最も保守的な選択肢は、Copilot credit policyのみで運用する方法です。Pay-as-you-goを併用しないため、前払いクレジットを使い切った時点で対象ユーザーのCopilot Chat利用は止まります。
この構成が向いているのは、次のような組織です。
- 研究開発部門や一部部署で小さく試したい
- Azure従量課金を部門に開放したくない
- AI利用予算の上限を明確にしたい
- 月末に想定外の請求が発生するリスクを避けたい
ただし、業務利用が定着している部門では注意が必要です。たとえば問い合わせ対応、営業支援、社内ナレッジ検索などでCopilot Chatエージェントを日常的に使う場合、月中にクレジットが尽きると業務影響が出ます。停止しても問題ない検証用途か、止まると困る本番用途かを事前に分けてください。
業務停止を避けたいならCapacity Packs＋Pay-as-you-go
本番運用で最も現実的なのは、Copilot credit policyとPay-as-you-go billing policyを組み合わせる構成です。前払いクレジットを先に消費し、足りなくなった分だけPay-as-you-goで処理します。
Microsoftは、前払い容量を超えた場合にCopilot ChatやSharePoint agentsがPay-as-you-goへ自動的に切り替わり、ユーザーが継続利用できる構成として説明しています。超過分は接続されたAzureサブスクリプションに請求されます。(Microsoft Learn)
この構成は、以下のような部門に向いています。
- 営業、カスタマーサポート、情報システムなど停止影響が大きい部門
- 月ごとの利用量に波がある業務
- まず前払いで予算を確保し、繁忙期だけ従量課金で吸収したいケース
- 利用拡大を見込みながら、初期段階では消費傾向を見たいケース
注意点は、Pay-as-you-goを併用すると「止まらない代わりに課金が続く」ことです。Microsoft 365 admin centerで予算や通知を設定しても、それは原則として通知であり、超過を強制的に止める仕組みではないと説明されています。(Microsoft Learn)
利用量が読めない初期検証ならPay-as-you-goのみ
Capacity Packsを購入せず、Pay-as-you-goのみで始める方法もあります。利用した分だけAzureサブスクリプションに課金されるため、PoCや小規模検証では始めやすい構成です。
Pay-as-you-goの利点は、利用パターンを把握しやすいことです。どの部署がどれくらいCopilot Chatエージェントを使うのか、テナントGraph groundingやアクションを使うエージェントがどれくらいクレジットを消費するのかを見てから、Capacity Packsに移行する判断ができます。
一方で、対象ユーザーを広げすぎると消費が急に増える可能性があります。最初は「全ユーザー」ではなく、特定のセキュリティグループに絞って開始するのが安全です。
管理者が確認すべき設定ポイント
必要な管理者ロールを確認する
Capacity Packsの購入、クレジットポリシーの作成、Pay-as-you-go設定では必要な権限が異なります。Microsoft Learnでは、Capacity Packsの購入にはGlobal AdministratorまたはBilling Administrator、Capacity Pack利用の有効化にはGlobal Administrator、Pay-as-you-go設定にはBilling AdministratorまたはAI Administratorも関与できると説明されています。(Microsoft Learn)
実務では、すべてをGlobal Administratorで実施するのではなく、作業内容ごとに最小権限を割り当てるべきです。MicrosoftもGlobal Administratorは高権限ロールであり、必要な場合に限定する考え方を推奨しています。(Microsoft Learn)
| 作業 | 主な確認者 | 実務上の注意 |
|---|---|---|
| Capacity Packsの購入 | ライセンス・購買担当、Billing Administrator | 契約形態、請求プロファイル、購入数を確認 |
| Copilot credit policy作成 | Microsoft 365管理者 | 対象グループと部門予算の対応を確認 |
| Pay-as-you-go policy作成 | Azure管理者、Billing Administrator、AI Administrator | Azureサブスクリプション、リソースグループ、請求先を確認 |
| 容量割り当て | Power Platform管理者、Microsoft 365管理者 | Copilot Chat環境への割り当て漏れに注意 |
| 利用状況監視 | 情シス、FinOps、部門管理者 | 月次レビューとアラート設定を運用に組み込む |
Copilot credit policyのスコープを部門単位で設計する
Copilot credit policyのスコープ設計は、後からの運用負荷に直結します。おすすめは、組織図そのものではなく「請求・予算管理の単位」でグループを作ることです。
たとえば、営業本部、カスタマーサポート、情報システム部門がそれぞれ別予算でCopilot Chatエージェントを使うなら、次のように分けます。
| ポリシー名の例 | 対象グループ | 運用意図 |
|---|---|---|
| copilot-credit-sales | 営業部門のセキュリティグループ | 商談準備や顧客対応の支援 |
| copilot-credit-support | サポート部門のセキュリティグループ | FAQ、問い合わせ回答、ナレッジ検索 |
| copilot-credit-it | 情報システム部門 | 社内問い合わせ、運用手順検索、検証 |
避けたいのは、「とりあえず全社」で作ることです。全社ポリシーは簡単ですが、どの部門がどれだけ消費したのかを後から説明しにくくなります。部門別の予算管理が目的なら、最初からグループ単位で分けてください。
Power Platform admin centerで容量割り当てを忘れない
Capacity Packsを購入しただけでは、Copilot Chat環境でクレジットを使える状態になりません。Microsoft Learnでは、購入後にPower Platform admin centerでMicrosoft 365 Copilot Chat環境へ容量を割り当てる手順が示されています。(Microsoft Learn)
設定の流れは次のとおりです。
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | Microsoft 365 admin centerでCapacity Packを購入 | 1パックあたり月25,000 creditsとして購入数を確認 |
| 2 | Copilot > Billing & usageでCopilot credit policyを作成 | 対象ユーザーまたはグループを指定 |
| 3 | 必要に応じてPay-as-you-go billing policyを接続 | Azureサブスクリプションと請求先を確認 |
| 4 | Power Platform admin centerのLicensing > Copilot Studioへ移動 | Microsoft 365 Copilot Chat環境を選択 |
| 5 | Manage capacityでクレジットを割り当て | 購入済み容量を超えて割り当てない |
| 6 | しきい値通知やoverage設定を確認 | 容量不足時に止めるか、従量課金へ逃がすかを決める |
特に見落としやすいのが、購入後の「環境への割り当て」です。購買担当がCapacity Packsを購入し、Microsoft 365管理者がポリシーを作成し、Power Platform管理者が容量を割り当てる、と担当が分かれている企業では、引き継ぎ漏れが起きやすくなります。
開発者・エージェント作成者が注意すべき点
エージェント設計によってCopilot Credits消費は変わる
Microsoft 365 Copilot Chatの課金を考えるとき、管理者だけでなくエージェント作成者も関係します。Copilot Creditsの消費量は、単にユーザー数だけで決まるわけではありません。Microsoftは、エージェントの設計、利用頻度、使用する機能によって消費クレジットが変わると説明しています。(Microsoft Learn)
たとえば、単純な固定回答に近いエージェントと、Microsoft Graph上の情報を参照して回答するエージェントでは、消費の傾向が異なります。Copilot Studioの課金情報では、Classic answer、Generative answer、Agent action、Tenant graph groundingなど、機能ごとにCopilot Creditsのレートが分かれています。(Microsoft Learn)
開発者は、精度を上げるために機能を足すだけでなく、「その機能追加で月間消費がどれくらい増えるか」を見積もる必要があります。特に以下の設計は、検証段階で消費を確認してください。
- Microsoft Graphや外部データを参照する回答
- 複数ステップのアクションを実行するエージェント
- 頻繁に呼び出される社内FAQエージェント
- 高度な推論や生成AIツールを組み込むシナリオ
- 全社員向けに公開する汎用エージェント
本番公開前に少人数で消費傾向を測る
いきなり全社公開すると、クレジット消費の原因分析が難しくなります。まずは特定グループで公開し、1週間から1か月程度の利用ログや消費傾向を確認するのが安全です。
実務では、次の順序で進めると失敗しにくくなります。
| フェーズ | 対象 | 確認すること |
|---|---|---|
| 検証 | 情シス・開発者のみ | エージェントが期待どおり回答するか、消費が極端に大きくないか |
| パイロット | 1部門または数十名 | 実業務で使われる頻度、よく使われるプロンプト、失敗回答 |
| 限定展開 | 複数部門 | 部門別の消費差、Capacity Packsの不足リスク |
| 本番展開 | 全対象部門 | 月次予算、通知、Pay-as-you-go超過分のレビュー |
開発者側では、プロンプト改善やナレッジソース整理によって、回答品質と消費量のバランスを取ることが重要です。「便利だから全部のデータを参照させる」のではなく、「その業務に必要な情報だけに絞る」設計が、コスト管理にも効きます。
移行・展開時に失敗しやすいポイント
既存のPay-as-you-go構成を把握せずに変更する
すでにPay-as-you-goを使っているテナントでは、既存のbilling policyやAzureサブスクリプションとの関係を確認してからCapacity Packsを導入してください。Microsoft Learnでは、既存構成がある場合も継続して動作し、必要に応じてCopilot credit policyを作成できると説明されています。(Microsoft Learn)
ただし、現場では「誰がどのAzureサブスクリプションに課金されているか」が曖昧なまま運用されていることがあります。移行前に、次の項目を棚卸ししてください。
- 既存のPay-as-you-go billing policy名
- 接続先のAzureサブスクリプション
- 対象ユーザーまたはグループ
- 予算設定と通知先
- Microsoft 365 admin centerとPower Platform admin centerのどちらで管理しているか
- Cost Management上の費用確認方法
Microsoft 365 CopilotのAI/Copilot更新では、機能追加そのものより「管理画面が複数にまたがること」による見落としがよく起きます。Microsoft 365 admin centerだけで完結したつもりにならず、Power Platform admin center側の容量・環境も必ず確認してください。
予算アラートを「利用停止」と誤解する
Pay-as-you-goのbudget設定は便利ですが、上限に達したら自動停止する仕組みとして扱うのは危険です。Microsoft Learnでは、予算額を設定すると支出状況に応じたメール通知が行われる一方、システムが予算超過を強制的に防ぐわけではなく、利用は継続できると説明されています。(Microsoft Learn)
そのため、予算超過を避けたい場合は次のように運用します。
| 目的 | 推奨設定 | 理由 |
|---|---|---|
| 絶対に超過させたくない | Copilot credit policyのみ | クレジット枯渇時に利用が止まる |
| 止めたくないが早めに気づきたい | Capacity Packs＋Pay-as-you-go＋通知 | 前払いを優先し、超過はAzure請求で継続 |
| 利用傾向を調べたい | Pay-as-you-go＋小さな対象グループ | 初期コストを抑えつつ実データを確認 |
| 部門別に管理したい | グループ別ポリシー | 消費責任と対象ユーザーを対応させやすい |
SharePoint agentsとCopilot Chatを同じ前提で考える
今回のCopilot credit policyは、公式情報上ではMicrosoft 365 Copilot Chat向けとして案内されています。SharePoint agentsについては、引き続き既存のPay-as-you-go設定プロセスを使うよう注意書きがあります。(Microsoft Learn)
つまり、Microsoft 365 Copilot Chatでは前払いのみの構成を検討できても、SharePoint agentsまで同じように扱えるとは限りません。社内説明資料や設計書では、「Copilot Chatエージェント」と「SharePoint agents」を分けて記載してください。
管理者向けチェックリスト
展開前に、少なくとも以下を確認しておくとトラブルを減らせます。
| チェック項目 | 確認内容 |
|---|---|
| 課金方式 | Copilot credit policyのみ、併用、Pay-as-you-goのみのどれにするか |
| 対象範囲 | 全社、部門、セキュリティグループのどれで管理するか |
| Azure課金 | Pay-as-you-goを使う場合、正しいAzureサブスクリプションに紐づいているか |
| 容量割り当て | Power Platform admin centerでCopilot Chat環境に容量を割り当てたか |
| 通知 | 容量不足や予算到達の通知先が部門管理者・情シスに届くか |
| 既存設定 | 既存のPAYG設定やPower Platform側の設定と重複・混乱がないか |
| エージェント設計 | Graph grounding、Agent action、生成AIツールなどの消費増要因を把握したか |
| 運用レビュー | 月次で消費量、超過分、部門別利用状況を確認する担当を決めたか |
このチェックリストで特に重要なのは、「容量を買ったか」ではなく「誰が、どのポリシーで、どの環境の容量を使うか」までつながっているかです。購入、ポリシー、環境割り当て、監視の4点がそろって初めて、運用できる状態になります。
まず取るべき実務アクション
Microsoft 365 Copilot ChatのCapacity PacksとPay-as-you-go billingは、どちらが優れているかではなく、用途によって使い分けるものです。予算統制を優先するなら前払い中心、業務継続を優先するならPay-as-you-go併用、利用量の見極め段階ならPay-as-you-goから始めるのが現実的です。
まずは、現在のテナントで次の3点を確認してください。
- 既存のPay-as-you-go billing policyがあるか
- Copilot Chatエージェントを使わせる対象部門・対象グループはどこか
- クレジット枯渇時に「止めてよい」のか「止めてはいけない」のか
この3点が決まれば、選ぶべき構成はほぼ決まります。検証部門はCopilot credit policyのみ、本番部門はCapacity Packs＋Pay-as-you-go、利用傾向が不明な段階は小さなPay-as-you-goから始める。これが、2026年時点のMicrosoft 365 Copilot Chat課金設計で最も失敗しにくい進め方です。
コメント