はじめに
少し前 SNS でもざわつきがありましたが、Copilot Studio の自律型エージェントを使う際の「クレジット消費の考え方」が、お客様にお伝えする上でかなりややこしくなってきていると感じています。
特に「Microsoft 365 Copilot のライセンスがあるユーザーが作る／使うエージェントなら、一部例外を除いて、Copilot Studio クレジットの消費は気にしなくてよい」と理解されている方が多いと思うのですが、自律型エージェントを作る場合、作り方次第ではクレジットを消費するケースとしないケースがあることが分かってきました。
本記事では、実際に手元で検証した挙動と、Microsoft の公式ライセンスガイド・FAQ の記載を突き合わせながら、
- 365 Copilot ライセンスがあるユーザーでもクレジットが消費されるのはどんなケースか
- 環境へのクレジット割り当てが必要になるのはどんなときか
- 自律型エージェントを公開する前にどんなヒアリングをすべきか
このあたりを整理してみたいと思います。
なお、エージェントフローと「新しいワークフロー」の使い分け自体については、以前以下の記事を書いておりますので、合わせて参照いただければと思います。
チャット型エージェントの場合の認識
Microsoft 365 Copilot のライセンスがある利用者がチャット型エージェント（ユーザーが対話で呼び出すタイプのエージェント）を使う場合、コア機能（従来の回答・生成回答・エージェントアクション・エージェントフロー）の利用は Microsoft 365 Copilot 使用権に含まれる扱いとなり、Copilot Studio のクレジットは消費しない、という認識です。
公式の請求レートと管理のページにも、課金レート表に「Microsoft 365 Copilot のライセンスを持つユーザーによって使用されます」という列があり、エージェントフローアクションを含めて「無料」と記載されています。
そのため、これまでは「作成者・利用者ともに 365 Copilot ライセンスを持っているのであれば、エージェントフローを呼び出してもクレジット消費は気にしなくてよい」と捉えることが出来ます。
実際に、本記事と同様の構成のエージェントを以前検証した際は、環境にクレジットを割り当てていない状態でもエージェントフローが問題なく実行されていた認識です。
今回検証した構成と挙動
ここからが本題です。今回、シンプルな構成で改めて検証してみたところ、自律型として実行した際に挙動が変わっていることが分かりました。
検証用に作ったエージェントフロー
総務人事部門向け FAQ エージェントで使うことを想定し、以下のような非常にシンプルなエージェントフローを用意しました。365 系のコネクタ（SharePoint・Teams）のみを使う構成です。
- 項目の作成（SharePoint リスト）
- チャットまたはチャネルでメッセージを投稿する（Microsoft Teams）
環境にクレジットを割り当てていない状態だと警告が出る
このエージェントフローを作成した環境にクレジット（前払い容量または従量課金プラン）を割り当てていない場合、フローの詳細画面に以下のような警告が表示されます。
この環境では Copilot クレジットが未設定しています
このフローを実行するには、この環境に Copilot クレジットが必要です。M365 Copilot のユーザーによるエージェントからのみテストでは、クレジットは消費されます。
警告メッセージ自体は表示されますが、これまでの認識では「365 Copilot ライセンスがあるユーザーが呼び出せばクレジット消費しないから気にしなくてよい」と思っていました。実際、上述の通り、チャット型エージェントから呼び出す分にはこの状態でも動いていた認識です。
トリガー付き（自律型）にすると、エージェントフローの実行に失敗する
今回、エージェントに「新しいメールが届いたとき（V3）」のトリガーを設定して、自律型エージェント扱いで動かしてみました。
※エージェント側にトリガーを設定すると「自律型エージェント」として扱われます。
エージェント自体は動作し、ナレッジ検索なども問題なく進むのですが、終盤のエージェントフローの呼び出しのところで失敗します。エラーメッセージとしては以下のような内容が返ってきました。
flowActionForbidden フロー 'RequestToSoumu_20260319' は応答コード 'Forbidden' で実行できませんでした。エラーコード: NotSpecified、エラーの詳細: The environment 'xxxx' does not have sufficient Copilot Credits to run workflows.
「エージェントの作成者は 365 Copilot ライセンスを持っているし、これまでは動いていたはずなのに……」と少し戸惑いました。
興味深いのは「コネクタ直接呼び出し」は問題なく動くこと
同じエージェントで、エージェントフロー経由ではなくエージェントから直接コネクタを呼び出すツール（例：「メールに返信する」コネクタ）も用意していました。こちらは環境にクレジットを割り当てていない状態でも、自律型実行で問題なく動作しました。
つまり、同じ自律型エージェントの中でも、
- コネクタを直接呼ぶアクション → 環境クレジット不要
- エージェントフローを呼ぶアクション → 環境クレジット必要
という、構成要素ごとの差が出ています。
環境に従量課金プランを割り当てたら、自律型でも実行成功
そのため、環境に対して請求プラン（Pay-as-you-go）を設定してみたところ、
自律型エージェントからのエージェントフロー実行が問題なく成功しました。
こちらの挙動を踏まえ、改めて、Microsoft の公式仕様（後述）を踏まえ整理してみます。
公式ドキュメントを読み直してみる
ここで Microsoft の公式情報を改めて確認してみます。
Microsoft Copilot Studio Licensing Guide（May 2026 版）では、365 Copilot ライセンスによる Copilot Studio 機能の包含について以下のように記載されています（原文ママ）。
Employee-facing scenarios (Business to Employee) usage of Microsoft Copilot Studio agents and the Microsoft Copilot Studio tools/features invoked by the said agents, are included in the Microsoft 365 Copilot User SL when the user of the agent is licensed with Microsoft 365 Copilot and the agent is operating using the authenticated Microsoft 365 Copilot User SL user's identity.
また、Microsoft Learn の請求レートと管理の「エージェントフローの施行」セクションには、以下のような記載もあります。
Microsoft 365 Copilot ライセンスユーザー: Microsoft 365 Copilot でライセンスされたユーザーによって呼び出されるエージェントフローアクションは、前払い容量を消費せず、強制の対象になりません。
両方の記載で共通しているのは、**「認証された 365 Copilot ライセンスユーザーの ID で動作している」「ユーザーによって呼び出される」**という条件が付いている点です。
自律型エージェント（スケジュール、メール受信、ファイル作成などのトリガー起点）は、ユーザーの対話を起点とせず、認証された 365 Copilot ライセンスユーザーの ID を伴わずに動作すると判断されるということでしょうか。トリガーのフロー自体は、エージェント (フロー) 作成者の権限で動作する認識ですが。そのため、今回エージェントフロー呼び出しが拒否された挙動は、上記の条件を字面通りに読むと「免除対象外なのでクレジットが必要」という整理で説明できなくもなさそうであります。
正直、解せない部分も残っています
ここまで読むと「自律型はユーザー ID を伴わないからクレジット必要、で完結」のように見えるのですが、今回の検証結果と突き合わせるとそう単純でもありません。
具体的には、同じ自律型エージェントの中でも、エージェントから直接コネクタを呼び出す構成は環境クレジットを割り当てない状態でも動いたという事実があります。コネクタ呼び出しも「ユーザーが対話で呼び出した」わけではないので、ライセンスガイドの条件をそのまま当てはめれば、こちらも免除対象外になりそうなものです。
この対称性の崩れについて、ライセンスガイドや FAQ を見ても明確な説明は見つけられませんでした。可能性としては、
- エージェントフローの施行（agent flow enforcement）は、一般のエージェント施行（125% 超過で発動）とは別の、より厳しいポリシーが適用されている
- コネクタ直呼びは、フロー実行とは異なる課金扱い／施行扱いになっている
といった理由が考えられますが、いずれも公式に明記されている内容ではない認識のため、現時点では**「そのような解釈が成り立ちそう」**というレベルで捉えておくのが無難かなと思っています。
少なくとも観測された挙動として確実に言えるのは、
- 自律型エージェント + エージェントフロー呼び出し → 環境クレジットが必要（無いと拒否される）
- 自律型エージェント + コネクタ直接呼び出し → 環境クレジットを割り当てなくても実行できた
という事実で、ここは案件で考慮しておく必要があるポイントだと考えています。「動きが変わった」のか、「もともとこの仕様だったのか」については、私自身も断定はできないところで、引き続き公式情報の更新を見ながらアップデートしていきたいと思います。
構成パターン別のクレジット消費まとめ
ここまでの検証結果と公式情報の記載を踏まえて、365 Copilot ライセンスを持つユーザーが作成・利用する場合の環境クレジットの要否を、構成パターン別に表にまとめてみました。
| エージェントの種類 | 構成要素 | 環境クレジット要否 | 根拠・補足 |
|---|---|---|---|
| チャット型 | コネクタ直接呼び出し | 不要 | 365 Copilot ライセンスユーザーの ID で呼び出されるため、ライセンスガイドの条件を満たし免除対象 |
| チャット型 | エージェントフロー呼び出し | 不要 | 同上（公式 FAQ にも「ユーザーによって呼び出されるエージェントフローアクションは前払い容量を消費しない」と明記） |
| 自律型（トリガー起点） | コネクタ直接呼び出し | 不要（観測ベース） | ライセンスガイドの「認証ユーザー ID で動作」の条件には合致しないが、実機検証では動作した。公式情報では明確な説明は見当たらない |
| 自律型（トリガー起点） | エージェントフロー呼び出し | 必要 | 環境クレジット未割当だと flowActionForbidden で実行が拒否される |
| 新しいワークフロー | （全体が自律型として動作） | 必要（想定） | 構成上、ワークフロー自体が自律型エージェントとして動作するため、365 Copilot ライセンス保持者が作成・利用する場合でもクレジット消費が発生する想定 |
※ 上記は 2026 年 5 月時点での検証結果と Microsoft 公式ドキュメント（Copilot Studio Licensing Guide May 2026 版、Microsoft Learn 請求レートと管理）に基づくものです。観測ベースの記載（自律型 + コネクタ直呼び）については、公式情報だけでは綺麗に説明しきれない部分があるため、案件ごとに最新情報を確認することをおすすめします。
個人的に押さえておきたいポイント
ここまでの検証と公式情報の確認を踏まえて、個人的には以下のポイントを押さえておく必要があると考えています。
1. 「365 Copilot ライセンスがあるから大丈夫」とは言い切れない
これまで、365 Copilot ライセンスを持つお客様に対しては「Copilot Studio で作ったエージェントを使う限り、追加のクレジット消費は基本気にしなくてよい」と解釈している人も少なからずいる認識です。
※例外としては、例えば、Computer Use を使う場合とチャット型エージェントの展開先が Teams/Microsoft 365 Copilot/SharePoint 以外の場合はクレジット消費すると認識していた人もいる認識です
しかし、自律型エージェントを作る場合は、エージェントの中身（エージェントフローを呼ぶか）次第でクレジット消費が発生するため、ライセンスだけで判断するのは難しくなっています。
特に、
- メール受信トリガー
- スケジュールトリガー
- ファイル作成トリガー
など、実行頻度が高い、または不確定なトリガーで自律型エージェントを動かしている場合、エージェントフローを使った構成だと「予想以上に環境クレジットを消費してしまう」可能性があると考えます。設計上の暴走（ループ・無限実行）リスクも考慮すると、コストマネジメント観点では結構気を遣うポイントです。
2. 新しいワークフローを使う場合はさらに注意
冒頭で参考記事をご紹介しましたが、エージェントフローの後継的な位置づけとして「新しいワークフロー」が用意されています。
こちらで作る場合、構成上、ワークフロー自体が自律型エージェントとして動作する形になるため、365 Copilot ライセンスを持つユーザーが作成・利用する場合においても、基本的にはクレジットが消費されることになると思います。実際に、私が試した際は、環境にクレジットを割り当てていないと、エージェントのテストに失敗しました。
※アクション単位のテストは成功しました
新しいワークフローでは、Agent ノードや Prompt ノードを組み込みつつ業務プロセスを記述するため、「自律型エージェントを作っている」という感覚が薄いまま作れてしまう側面があります。今後、新しいワークフローが主流になっていくと、自律型エージェントの公開時はこれまで以上に注意が必要になりそうです。
3. リリース前のヒアリングで「エージェントフローの有無」を確認する
運用観点では、自律型エージェントを本番公開する前に、以下のような確認ステップを設けたほうがよいかなと感じています。
- 自律型エージェントになっているか（トリガーが設定されているか）
- エージェントフロー（または新しいワークフロー）を呼ぶ構成になっているか
- 想定されるトリガー頻度はどの程度か
- 環境への請求プラン（Pay-as-you-go）または前払い容量の割り当てはあるか
- 個別エージェント単位での月間使用量制限を設定するか
特に、Power Platform 管理センターでは、個々のエージェントの月間使用量の制限を設定できるようになっています（該当ドキュメント参照）。暴走対策としては、環境単位の制御と組み合わせて、エージェント単位の制御もかけておくほうが安心かと思います。
4. 「同じことが直接コネクタ呼び出しでできないか」を一度考える
今回の検証で印象的だったのは、エージェントから直接コネクタを呼び出す構成は環境クレジット不要で動いた点です。
もちろん、エージェントフローや新しいワークフローのほうが、複雑な業務ロジック・複数ステップの処理・エラーハンドリングを組みやすいというメリットはあります。ただ、「同じ処理がエージェントの直接アクションだけで実現できるなら、そのほうがクレジット運用上は楽」というケースもありそうです。
もちろん、エージェントフローを使うべき場面はあるので「全部コネクタ直呼びにすべき」という話ではなく、シナリオに対して最小構成を選ぶ意識は持っておきたいと感じました。
まとめ
今回は、Copilot Studio の自律型エージェントとエージェントフローを組み合わせた場合のクレジット消費について、検証結果と公式情報を整理してみました。
Copilot Studio を組織展開する立場からすると、ライセンス × クレジットの組み合わせはどうしても複雑になりがちです。現状の動きですと、「365 Copilot ライセンスがあれば大丈夫」と一括りにせず、エージェントの作り方単位で見極める姿勢が必要になってきたかなと感じています。
なお、本記事は 2026 年 5 月時点での検証結果と公式ドキュメントの記載に基づくものです。仕様や挙動は今後も変更される可能性が高い領域なので、案件で判断する際は必ず最新の Microsoft Copilot Studio ライセンスガイドおよび公式 FAQ をご確認いただければと思います。
本記事が、Copilot Studio の自律型エージェントを組織で展開する際のクレジット運用検討のお役に立てば幸いです。
参考リンク
- 請求レートと管理 - Microsoft Copilot Studio | Microsoft Learn
- Copilot Studio の課金とライセンスに関する FAQ - Microsoft Copilot Studio | Microsoft Learn
- Copilot Studio のクレジットと容量を管理する - Power Platform | Microsoft Learn
- Copilot Studio Licensing: M365 Copilot + Credit Pack + HTTP Action via Power Automate Autonomous Trigger - Microsoft Q&A
- Copilot Studio の新しいワークフローを試してみた - Qiita
- Copilot Studio の新しい「ワークフロー」と従来の「エージェントフロー」の現時点での使い分けを整理してみる - Qiita