スループットとレート制限を考慮した Copilot Studio エージェントの展開計画

本番環境対応のCopilot Studioエージェントには、ライセンスや総メッセージ量の計画以上のものが必要です。 また、スループット計画も必要です。 スループットプランニングには、トラフィックがどれだけ速く到達するか、ソリューションが呼び出すプラットフォームサービス、そしてソリューション全体に適用される制限が含まれます。

本記事は、ソリューションアーキテクト、作成者、Power Platform管理者が、Copilot Studioの大規模展開を本番トラフィック、ユーザー受け入れテスト（UAT）、負荷テスト、B2C（一般消費者向け）シナリオ、および自律型ワークロードに向けて準備する際に役立ちます。

レートプロビジョニングはライセンスプロビジョニングとは区別されます

本番環境のCopilot Studioの計画には、関連しつつ独立した2つの作業ストリームがあります。

• ライセンスのプロビジョニングは、ライセンス、クレジット、事前購入容量、メッセージパック、従量課金制などの商用権利や消費をカバーします。
• レート プロビジョニングとは、スロットリングやサービス保護制御が適用される前に、トラフィックをどれだけ迅速に処理できるかを規定するものです。

Pay-as-you-goは、低容量の構成と比べて利用可能な制限を増やすことができますが、スループットは無限ではありません。 現在のCopilot Studioの制限、Power Platformのリクエスト割り当て、Power Automateの制限、Dataverseのサービス保護制限、コネクタのスロットリングルール、および下流 API の制限を確認してください。

調整が発生した場合はどうなりますか?

スロットリングはサービス保護の仕組みです。 これは、公開されている制限、バースト制御、またはサービス容量を超えるトラフィックパターンから共有サービスを保護します。 正確な症状は、どのサービスがスロットリングされているかによって異なります。

限界に達したとき、その結果は単なる計画上の問題以上のものとなります。 リクエストはスロットリングされたり、遅延されたり、ブロックされたり、拒否される場合があります。 ユーザー向けチャットでは、この動作が一時的なサービス中断として発生する場合があります。 例えば、ユーザーが次のメッセージを送信できなくなったり、エージェントの利用不可や使用制限のメッセージを受け取ったり、フロー、コネクタ、Dataverse 呼び出し、AI サービス、または外部 API が上限に達したために手順が失敗することがあります。

Copilot Studio固有の症状やエラーメッセージについては、エージェントの使用制限エラーの解決をご参照ください。

レート制限の測定方法

レート制限は、特定の時間枠内でサービスが受け入れることのできるトラフィック量を測定します。 これらの時間枠をより細分化して考えてみてください：1分ごと、5分ごと、10分ごと、1時間ごと、1日ごと、1週間ごと、1か月ごと。 月間や週間のトラフィック量は総需要の推定に役立ちますが、レート制限の割り当てにおいては短期間の時間枠が重要です。なぜなら、スロットリングは集中したトラフィックによって発生することが多いからです。

例えば、B2C企業では、特定のキャンペーンの1時間にエージェントのトラフィックの大部分が集中する場合があります。 週平均は低く見えるかもしれませんが、その1時間だけでスループット圧力が高まり、スロットリングやサービス中断を引き起こす可能性があります。 週次や月次レベルで問題がないと見なされる設計でも、1時間のピーク時には制限を超過する可能性があります。

制限の範囲を理解する

制限は個々のエージェントレベルだけに適用されるものではありません。 サービスによっては、環境レベル、ツールレベル、APIレベル、コネクタレベル、チャネルレベル、または下流サービスレベルで制限が適用されることがあります。

例えば、Copilot Studioのメッセージからエージェントへの制限はDataverse環境単位で設定されています。 トラフィックを推定する際には、その環境でエージェントにメッセージを送信するすべてのソースを含めてください。ユーザー向けチャネル、統合、自律的なワークロード、Azure Bot Frameworkのスキルなどが含まれます。 Copilot Studio のクォータと制限で現在の値や適用範囲を確認してください。

レートプロビジョニングがあなたのエージェントに適用されるかどうか決定してください

すべてのエージェントが詳細なレートプロビジョニング作業を必要とするわけではありません。 少人数の利用者を対象とし、利用パターンが予測可能で、下流サービスへの呼び出しがほとんどない簡易な内部FAQエージェントは、レート制限に達する可能性は低いです。 月単位の利用が少なくても、エージェントが1分または1時間ごとのリクエスト制限を超える可能性がある場合、レートプロビジョニングは重要になります。

プロジェクトの早い段階で、ソリューション設計と並行して、想定されるトラフィックについて考えましょう。 ユーザーアクセプタンステスト（UAT）や負荷テストを開始する前に、チームはエージェント設計、環境、接続サービス、下流システムが期待されるスループットプロファイルに対応できることを確認しておく必要があります。

この指針は、トラフィックが突発的に発生したり、多くのユーザーやイベントが同時にエージェントを呼び出したり、各対話が複数のプラットフォームサービスに依存したりする、より大規模で集中的なエンタープライズグレードエージェントに対して特に重要です。 これは、短期間のローンチウィンドウや部門全体のイベント、スケジュールされたプロセス、数分間に多数のリクエストを生成するワークフローなど、集中した利用パターンを持つ小規模なエージェントにも適用されます。

B2Cエージェントや自律型エージェントには早期のレート設定が求められます

顧客向けB2Cエージェントは、キャンペーン・公開ウェブサイト・顧客ポータル・インシデントコミュニケーション・製品発売・季節的な需要などからトラフィックを受信できます。 自律型エージェントは、スケジュール、イベント、バックグラウンドプロセス、または複数のツールやワークフローを呼び出した際に、高頻度のトラフィックを生成できます。

ピーク時の短時間（ピークウィンドウ）も考慮し、月間の総量だけでなく両方を確認しましょう

エージェントが1分または1時間以内に集中的なリクエストを作成できるかどうかを尋ねてください。 小規模なシナリオでも、短時間に負荷テストやキャンペーン、障害対応、または自動トリガーによって大量のメッセージ、生成 AIコール、ワークフローアクション、コネクターコール、またはDataverseリクエストが環境を通過する場合、レートプロビジョニングが必要になることがあります。

月間利用量は総需要を見積もるのに役立ちますが、レートプロビジョニングには十分ではありません。 予想される使用量をより短い時間ウィンドウに変換して、設計をリンク先ページに記載されている現在の1分あたりのリクエスト数（RPM）、1時間あたりのリクエスト数（RPH）、バースト、および1日あたりの制限と比較してください。

平均トラフィックプロファイルとピークトラフィックプロファイルの両方を構築しましょう。 例えば、毎日午後5時から6時の間にトラフィックが集中する場合、1時間あたりのピークはその集中を反映すべきです。 トラフィックが 1 つの時間帯に集中している場合、1日の推定値はピーク時間の24倍にする必要はありません。

他にどんな場合にスロットリングが発生するのでしょうか？

スロットリングは以下の場合にも起こり得ます:

• 従業員の多くが、部署全体のイベントや研修など、予測可能なピーク時間帯にエージェントを利用します。
• マーケティングキャンペーン、障害、ローンチ、または予定されたビジネスイベントが一時的なトラフィック急増を引き起こします。
• Power Automateのフローには、ループ、リトライ、ページネーション、子フローなどが含まれており、これらがリクエスト量を増加させます。
• 報告、監査、利用統計情報のエクスポート、またはトランスクリプトのキャプチャは、ユーザーの操作中に同期的に実行されます。
• 複数のエージェントやワークロードが同じ環境、アイデンティティ、コネクタ、または下流APIのキャパシティを共有することがあります。
• 負荷テストの規模拡大は、本番環境のアーキテクチャやサポートプロセスが想定していたよりも速いペースで進んでいます。

関連するレート制限を調べる場所

Copilot Studioには独自の制限があり、エージェントのランタイムパスには他のサービスが含まれており、それぞれに固有の制限がある場合があります。 エージェントが利用するサービスに関するすべての制限事項を確認してください。

Copilot Studio の制限

考慮すべき他のプラットフォームの制限

実行経路上の最も低い制限がユーザー体験を決定します。 Copilot Studio エージェントは自身の制限内で動作していても、フロー、コネクタ、Dataverse コール、言語サービス、または外部 API がスロットルされることがあります。

スループット負荷を低減するための設計

レートの増加を最初の設計対応策にしないでください。 まず、エージェント設計を見直し、効率を最適化しましょう。 エージェントが何かを調べる必要がある場合は、外部呼び出しを意図的に行い、APIコールを最適化し、Copilot Studio、Power Automate、Dataverse、コネクタ、下流システム間で不要なリクエスト量を避けてください。

設計が効率的になった後は、スループットを制御して、トラフィックが予測可能な方法でプラットフォームに到達するようにします。

• 環境レベルの制限については、運用設計に合う場合は、エージェントを複数の環境に分散させることを検討してください。 このアプローチにより、大量のエージェント、事業部門、地域、または自律的なワークロードが、同じ環境範囲の制限をめぐって無関係なワークロードと競合するのを防ぐことができます。
• 自律型エージェントの場合、キュー、バッチ処理、トリガーフィルター、スケジュールされた処理、再試行制御、モニタリングを活用し、バックグラウンド作業が制御されていないバーストとして流入しないようにしましょう。
• スケジュールされた処理、レポート作成、監査エクスポート、利用統計情報の作業は、可能な限りインタラクティブなチャットパスの外で実施してください。
• ロードテスト結果や本番利用統計情報を確認し、リクエストが集中している箇所を特定した上で、エージェント、フロー、コネクタ、下流APIを調整し、より高い制限を申請してください。

自律エージェントは、リクエストのキューイングやトリガーレートの制御によって、割り当てられた容量を高い予測性と観察性をもって最大限活用できる、独自の立場にあります。

デフォルトのレート制限が十分でない場合の対応方法

ピークトラフィックの予測で、エージェントや接続されているサービスが現在の公開制限を超える可能性がある場合は、UAT、負荷テスト、または本番環境の開始前にレート制限設定のサポートプロセスを開始してください。 最初の本番環境でのエラーを待ってはいけません。

サポート要求をオープンにする

管理者は Power Platform 管理センターからサポートを依頼できます。

チケットは早めに発行し、入手可能な最良の見積もりを含めてください。 詳細をより多く提供すれば、審査プロセスはよりスムーズに進みます。 設計が改良されたり、負荷テストで観測データが得られたりした場合は、要求内容を更新してください。

含めるコア情報

参考になる詳細

関連情報

• Copilot Studio のクォータと制限
• 会話エージェントのパフォーマンス向上のベストプラクティス
• エージェントの使用制限エラーの解決
• 要求の制限と割り当て
• プラットフォームの制限を理解し、調整を回避する
• 自動化フロー、スケジュールされたフロー、インスタント フローの制限事項
• サービス保護の API 制限
• Dataverse API 制限の概要
• 会話言語理解を統合の制限
• Power Platform 管理センターでサポートを受ける