記事公開日
【Copilot Studio】Copilot クレジットの制御｜テナント容量からの引き落としを止める
この記事の重要ポイント
- GitHub Copilot ハーネスのエージェントは、公開前のビルドやテストの段階から Copilot クレジットを消費し、Microsoft 365 Copilot ライセンスの対象外です
- 新規環境では「テナントで利用可能な容量から引き落とす」が既定で有効なため、外さないとテナントで共有している容量が減り続けます
- この設定は Power Platform API からも変更できますが、リクエストに書かなかった項目は元の値が保持されず上書きされます
こんにちは、DXソリューション営業本部の中井です。
Copilot Studio に GitHub Copilot ハーネスが加わり、エージェントの作り方と課金の仕組みが変わりました。
本ブログでは、環境単位で Copilot クレジットの消費範囲を区切る設定を、Power Platform 管理センターの操作と、手動トリガーのクラウドフローの両方で解説します。
執筆者：中井（DXソリューション営業本部）
Power Platform と Copilot Studio を中心に業務改善・DX 推進に従事。
市民開発者の教育・コミュニティ運営支援やガバナンス整備を強みとし、ハンズオン／ハッカソン登壇は数十件以上。
GitHub Copilot ハーネスは作り始めた時点から課金される
GitHub Copilot ハーネスで作ったエージェントは、消費ベースの課金になります。
公式ドキュメントには「エージェントのビルド、テスト、評価、実行が Copilot クレジットを消費する」「この使用量はユーザーの Microsoft 365 Copilot ライセンスには含まれない」と記載があります。
従来の標準ハーネスが公開後から課金される一方で、GitHub Copilot ハーネスは作り始めた時点から課金が始まります。
クレジットを消費するのは、自然言語での作成、エージェントのプレビューとテスト、エージェント評価の生成などです。
消費の対象は大規模言語モデルのトークンだけでなく、ツール（ナレッジや MCP を含む）とハーネスそのものも含まれます。
作成時と実行時のどちらも、ユーザーのライセンスに関係なくすべての利用が課金されます。
もう一つ押さえておきたいのが期限です。
公式ドキュメントには「開発者環境と試用版環境は 2026年9月1日に使用量ベースの課金へ移行する」と記載があります。
それまでは非課金として集計されている消費が、この日を境に請求対象になります。
料金の考え方そのものについては、こちらの記事でまとめています。
テナント容量の引き落としが有効なままだと何が起きるか
Power Platform 管理センターでは、環境ごとに Copilot クレジットを割り当てられます。
この画面にあるのが「容量の超過」の設定で、テナントで利用可能な容量から引き落とすというチェックボックスです。
| 状態 | 環境の挙動 |
|---|---|
| チェックあり | 割り当てたクレジットを使い切った後も、テナントの未割り当て容量から引き落とし続ける |
| チェックなし | その環境は割り当てた分が上限になり、使い切ったところで消費が止まる |
実際に環境を新しく作成して確認したところ、既定でこのチェックが入った状態でした。
つまり何もしなければ、その環境で開発者がエージェントを作成・テストしたりするだけで、テナント全体で共有している容量が減っていきます。
それぞれの環境は「テストするだけ」「少し試すだけ」のつもりで使っています。
誰も上限を超えているわけではありませんが、同じ皿から取り分けているため、テナント全体の残量だけが減っていきます。
減っていることに気づくのは、たいてい残量が少なくなってからです。
無効にしない限り引き落としが続く仕様であるため、環境を作ったら設定を確認する運用にしておくのが確実です。
💡 環境の目的で方針を分ける
開発・検証用の環境は、引き落としを無効にして消費を割り当ての範囲内に閉じるのが基本です。
同じ設定を全環境に一律で適用するのではなく、環境の目的ごとに方針を決めておくと運用が安定します。
管理センターで環境の設定を変える
まずは画面での操作を確認します。
この操作には Power Platform 管理者、またはグローバル管理者のロールが必要です。
- Power Platform 管理センターにサインインする
- ナビゲーションで「ライセンス」を選択する
- 「製品」から「Copilot Studio」を選択する
- 「Copilot クレジットの管理」を選択する
- 対象の環境を選択する
- 「容量の超過」で「テナントで利用可能な容量から引き落とす」のチェックを外す
- 「保存」を選択する
画面には、その環境で消費済みのクレジット数、既に割り当て済みの数、テナントから割り当て可能な残数が表示されます。
手動のクラウドフローで同じ設定を変えてみる
画面での操作は環境1つずつになります。
同じ設定は Power Automate からも変更できるため、ここでは手動トリガーのクラウドフローで1環境の設定を書き換えてみます。
挙動を理解するための最小構成として作り、対象の環境 ID は実行時に手で指定します。
今回は更新だけを行う構成にします。
開発や検証用の環境であれば、クレジットが割り当てられているかどうかに関わらず引き落としを無効にしておくのが基本の考え方になるためです。
現在の状態によって処理を分ける必要がないので、フローもその分だけ短くなります。
ただし後述のとおり、既に割り当てがある環境を対象にする場合は、実行前に現在の割り当て数を管理センターで確認しておく必要があります。
使うコネクタとアクション
使うのは「Microsoft Entra ID を使用した HTTP」コネクタの「HTTP 要求を呼び出す」アクションです。
このコネクタは接続を作るときに認証先のリソースを指定する形になっているため、Power Platform API を呼ぶためのアプリ登録を別途用意する必要がありません。
接続に使うアカウントには、管理センターでの操作と同じく Power Platform 管理者またはグローバル管理者のロールが必要です。
今回使用するコネクタはプレミアムコネクタとなるので、Power Automate Premium といった有償ライセンスが別途必要になります。
標準コネクタの「Power Platform for Admins V2」にも割り当てを更新するアクションがありますが、確認した時点では引き落としのルールまでは設定できませんでした。
ただし Microsoft の Copilot Studio CAT Team のブログによると、今後はこのコネクタでも代替できるようになるとのことです。
Copilot クレジットは、API 上では MCSMessages という通貨の種類として扱われます。
また、管理センターの「テナントで利用可能な容量から引き落とす」は、API 上では TenantPool というルールに対応します。
画面のチェックを外す操作は、このルールを無効にする操作と同じ意味になります。
対応関係について詳しくはこちらの公式チュートリアルをご参照ください。
エンドポイントの仕様そのものは、REST API リファレンスの「Allocations By Environment」に記載があります。
指定できる通貨の種類やルールの種類を確認したいときは、こちらのリファレンスをご参照ください。
フローの全体像
フローはトリガーと1つのアクションで構成します。
手動で実行し、対象の環境 ID を受け取って、その環境の設定を更新する流れです。
各アクションの設定
STEP 1 トリガーに「フローを手動でトリガーします」を選び、テキスト型の入力を1つ追加します。
ここに対象の環境 ID を入れて実行します。
環境 ID は、Power Platform 管理センターの環境の詳細画面で確認できます。
実行のたびに手で指定するため、意図しない環境を書き換える心配がありません。
STEP 2 「HTTP 要求を呼び出す」を追加します。
このアクションを初めて使うときは接続の作成を求められるので、認証先のリソースを指定します。
| 項目 | 設定値 |
|---|---|
| ベース リソース URL | https://api.powerplatform.com |
| Microsoft Entra ID のリソース URI | https://api.powerplatform.com |
どちらにも同じ値を指定します。
ここで認証先を指定するため、アプリ登録を別途用意する必要がありません。
STEP 3 アクションにリクエストの内容を設定します。
URL には環境 ID を含めず、本文で対象の環境 ID と設定内容を渡します。
| 項目 | 設定値 |
|---|---|
| 方法 | PATCH |
| 要求の URL | /licensing/allocationsByEnvironment?api-version=2024-10-01 |
| ヘッダー | Content-Type: application/json |
| 本文 | { |
environmentId にはトリガーの入力を動的なコンテンツで差し込みます。
enforcementRules の TenantPool を false にすることで、割り当てを使い切った後にテナントの容量から引き落とすのを止められます。
これが管理センターでチェックを外す操作に対応します。
allocated には、その環境に割り当てるクレジット数を指定します。
上の例を 0 にしているのは、作成したばかりの環境をまず止めておく想定だからです。
新しく作られた環境にはまだ割り当てがないため、0 のまま引き落としを無効にしておき、必要になった時点で改めて割り当てる運用にできます。
一方、既に割り当てがある環境に実行する場合は、その環境の現在の割り当て数を必ず指定してください。
現在の割り当て数は、管理センターの Copilot クレジットの管理画面で確認できます。
また enforcementRules にも、変更しないルールを含めてすべて指定します。
上の例で TenantPool だけでなく Alert も書いているのはこのためです。
💡 指定しなかった項目は保持されません
このリクエストは、送った内容で既存の設定を置き換える動きになります。
検証では次の2点を確認しました。
・1000 クレジットを割り当てていた環境で allocated を省略したところ、割り当てが 0 になりました
・enforcementRules に TenantPool だけを指定したところ、Alert が無効になりました
メソッドは PATCH ですが、書かなかった項目が元の値のまま残るとは考えないほうが安全です。
変更しない項目も含めて、現在の値をすべて本文に書いてください。
なおルールの種類は、リファレンス上は Alert・TenantPool・PayGo・Deny の4つが定義されています。
環境によっては今回指定した2つ以外のルールが設定されていることもあるため、実行前に現在の設定を確認してください。
割り当てが 0 で、なおかつテナントからの引き落としも無効という状態になると、その環境でクレジットを必要とする操作は使えなくなります。
新しい環境をまず止めておく場合は意図どおりですが、既に利用中の環境で同じ状態にすると、開発者の作業も止まります。
最初は検証用の環境の ID を指定して、挙動と出力を確認してから本番の環境に適用してください。
なお、意図せず割り当てを変えてしまった場合は、allocated に元の値を入れて同じリクエストを実行し直せば戻せます。
置き換えの動きは元に戻す方向にも働くため、実行前に現在の値を控えておくと復旧しやすくなります。
更新が適用されたかどうかは、アクションの出力で確認できます。
応答の本文には、適用後の割り当て内容が含まれています。
| 更新アクションの応答の本文（抜粋） |
|---|
{ |
enforcementRules の TenantPool が false になっていれば、引き落としの無効化は受け付けられています。
同時に allocated も確認できるため、割り当て数が意図せず変わっていないかをここで見ておくと安心です。
💡 実運用では複数の環境をまとめて変更したい
ここまでは1環境だけを対象にした最小構成です。
実際のテナントでは環境の数が多く、1つずつ実行していくのは現実的ではありません。
環境の一覧を取得する処理と繰り返し処理を組み合わせれば、複数の環境をまとめて更新することもできます。
新しい環境を定期的に検知して適用する形にしておけば、設定漏れを防げるため、ガバナンスの面でも扱いやすくなります。
ただし一括で処理する場合は、前述の置き換えの動きによる影響範囲が一気に広がります。
対象の環境をどう絞り込むか、環境ごとに異なる現在の割り当て数をどう引き継ぐか、途中で失敗したときにどう扱うかを設計しておく必要があります。
この設定の制御が及ばない範囲
引き落としを無効にしても、それだけでクレジットの消費が止まるわけではありません。
この設定の制御が及ばない経路が2つあるため、あわせて押さえておきます。
従量課金プランからの消費
環境が従量課金プランにリンクされている場合、テナントの容量からの引き落としを止めても、リンク先の Azure サブスクリプション経由で利用が続きます。
プリペイド容量と従量課金は別の経路なので、両方を確認する必要があります。
Azure の予算とアラートについても、通知は送られますが Copilot Studio でのクレジット消費を止めるものではありません。
予算の管理と消費の停止は別のものとして考える必要があります。
Power Platform 以外で使われるクレジット
本記事で扱った設定は、あくまで Power Platform の世界における Copilot クレジットの制御です。
プリペイドの容量パックは Microsoft 365 側の機能からも使われ、Power Platform の環境に割り当てられた容量や Copilot Studio が消費した容量は、Cowork や Work IQ といった Microsoft 365 の機能が使えるプリペイド容量を消費します。
つまり Copilot Studio 側を絞っても、Microsoft 365 側が同じ容量を消費していればテナント全体の残量は減りますし、逆に環境設定で Microsoft 365 側の消費を止めることもできません。
Microsoft 365 側は管理センターの「Copilot」から「コスト管理」で扱うため、テナント全体を見るときは2つの管理センターを合わせて確認する必要があります。
2026年9月1日までに確認しておきたいこと
公式ドキュメントには、開発者環境と試用版環境が使用量ベースの課金へ移行する前にやることとして、次の項目が挙げられています。
- GitHub Copilot ハーネスで作成されたエージェントを特定する
- 直近の非課金の消費量を確認する
- 環境の容量と、容量超過時の挙動を設定する
- リスクの高いエージェントに上限と通知を設定する
- 従量課金プランに Azure の予算とアラートを設定する
- 課金開始後に消費を確認する担当者を決める
最初の「特定する」は、管理センターで手早く確認できます。
「管理」から「Copilot Studio」を開き、ハーネスの列を GitHub Copilot で絞り込むと、該当するエージェントが一覧で見られます。
2番目の「非課金の消費量」は、エージェントの管理ページと、ダウンロードできる消費レポートで確認できます。
ただし、あくまで消費の傾向をつかむための参考情報なので予算の根拠として使うのではなく、どの環境とエージェントを先に手当てするかの判断材料として見るのが適切です。
よくある質問
Q. テナント全体で「テナントで利用可能な容量から引き落とす」を一括で無効にできますか？
公式ドキュメントで案内されている設定の単位は環境ごとです。環境数が多い場合は、Power Platform API や管理用の SDK を使って複数の環境に同じ設定を適用する方法が公式に案内されています。
Q. 引き落としを無効にすれば、その環境のクレジット消費は必ず止まりますか？
プリペイド容量からの追加消費は止まりますが、環境が従量課金プランにリンクされている場合は、リンク先の Azure サブスクリプション経由で利用が続きます。従量課金プランの有無も合わせて確認してください。
Q. 使い切ったクレジットは翌月に繰り越せますか？
繰り越しはできません。クレジットの使用量は月単位で集計され、毎月1日にリセットされます。未使用の容量は翌月に持ち越されないため、割り当ては月単位の想定消費量をもとに決める必要があります。
まとめ
GitHub Copilot ハーネスのエージェントは、作り始めた時点から Copilot クレジットを消費します。
そして環境の「テナントで利用可能な容量から引き落とす」設定を外さない限り、割り当てを使い切った後もテナントの共有容量から引き落としが続きます。
新規環境では既定でこのチェックが入っているため、環境を作ったら設定を確認する運用にしておくと安心です。
1つの環境の設定を変えること自体は、ここまで見てきた手順で対応できます。
難しいのはその先で、どの環境をどの方針に当てはめ、新しく作られた環境をどう見つけ、止まった開発者の申請をどう受けるかという部分です。
Copilot クレジットの制御は、設定作業ではなく運用の設計から始まる話だと考えています。
QESでは、Copilot エージェントのセキュリティ・ガバナンス設計から、PoC・本番構築、運用と継続改善までを一貫してご支援しています。
プロフェッショナル開発と市民開発のどちらにも対応していますので、以下のリンクからサービスの詳細をご確認ください。
※ 本ブログで参照されている、Microsoft、Microsoft Copilot Studio、Power Platform、Power Automate、Microsoft 365 Copilot、Microsoft Entra ID、Microsoft Azure、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。
※ その他の会社名、製品名は各社の登録商標または商標です。
