スループットとレート制限を考慮して Copilot Studio エージェントのデプロイを計画する

運用環境に対応したCopilot Studio エージェントには、ライセンスとメッセージ ボリュームの合計計画以上のものが必要です。 また、スループット計画も必要です。 スループット計画では、トラフィックの到着速度、ソリューションが呼び出すプラットフォーム、およびソリューション全体に適用される制限について説明します。

この記事は、ソリューション アーキテクト、作成者、および Power Platform 管理者が、運用トラフィック、ユーザー受け入れテスト (UAT)、ロード テスト、企業間 (B2C) シナリオ、自律ワークロード用に大量のCopilot Studio展開を準備するのに役立ちます。

料金のプロビジョニングはライセンスのプロビジョニングとは別です

本番環境での Copilot Studio の計画には、相互に関連しているものの別個の作業ストリームが 2 つあります。

• ライセンスのプロビジョニングは、ライセンス、クレジット、前払い容量、メッセージ パック、従量課金など、商用利用権と使用量を対象とします。
• レート プロビジョニング では、スロットリングまたはサービス保護制御が適用される前に、トラフィックをどれだけ速く処理できるかについて説明します。

従量課金制では、容量の低い構成と比較して使用可能な制限を増やすことができますが、スループットは無限ではありません。 現在の Copilot Studio の制限、Power Platform の要求割り当て、Power Automate の制限、Dataverse のサービス保護制限、コネクタのスロットリング規則、およびダウンストリーム API の制限を確認してください。

スロットリングが発生するとどうなりますか?

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

制限に達すると、結果は計画上の問題以上の結果になります。 リクエストは、スロットルされる、遅延される、ブロックされる、または拒否されることがあります。 ユーザー向けのチャットでは、この動作は一時的なサービス中断として表示される可能性があります。 たとえば、フロー、コネクタ、Dataverse 呼び出し、AI サービス、またはダウンストリーム API が制限に達したため、ユーザーが次のメッセージを送信できない、エージェントが使用できない、または使用制限メッセージを受信できない、または失敗した手順が発生する可能性があります。

エージェントの使用制限エラーの解決では、Copilot Studio 固有の現象とエラー メッセージについて説明します。

レート制限の測定方法

レート制限は、特定の時間枠内にサービスが受け入れ可能なトラフィックの量を測定します。 これらのウィンドウについては、1 分ごと、5 分ごと、10 分ごと、1 時間ごと、1 日あたり、週ごと、月単位で細かく考えてください。 毎月または毎週のボリュームは、総需要を見積もるのに役立ちますが、多くの場合、調整はトラフィックの集中に起因するため、レート プロビジョニングの期間は短くなります。

たとえば、B2C 企業は、1 つの集中キャンペーン時間内にエージェント トラフィックの大部分を受信する場合があります。 毎週の平均は低く見えるかもしれませんが、その 1 時間でも、調整やサービスの中断を引き起こすのに十分なスループット負荷が発生する可能性があります。 週単位または月単位のレベルで安全に見えるデザインは、1 時間のピーク時に制限を超える可能性があります。

制限の範囲を理解する

制限は、個々のエージェント レベルでのみ適用されるわけではありません。 サービスに応じて、環境レベル、ツール レベル、API レベル、コネクタ レベル、チャネル レベル、またはダウンストリーム サービス レベルで適用できます。

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

レート プロビジョニングがエージェントに適用されるかどうかを決定する

すべてのエージェントで詳細なレート プロビジョニング作業が必要なわけではありません。 対象ユーザーが少なく、使用量が予測可能で、ダウンストリーム呼び出しがほとんどまたはまったくない単純な内部 FAQ エージェントは、レート制限に達する可能性はほとんどありません。 エージェントが 1 分あたりの要求数または 1 時間あたりの要求数の制限を超える可能性がある場合は、毎月のボリュームが控えめに見える場合でも、レート プロビジョニングが重要になります。

ソリューション設計と共に、プロジェクトの早い段階で予想されるトラフィックについて考えます。 ユーザー受け入れテスト (UAT) とロード テストを開始する前に、チームは、エージェントの設計、環境、接続されたサービス、およびダウンストリーム システムが予想されるスループット プロファイルをサポートできることを確信する必要があります。

このガイダンスは、トラフィックが急増したり、多くのユーザーまたはイベントが同時にエージェントを呼び出したり、各対話が複数のプラットフォーム サービスに依存したりする、より大規模で集中的なエンタープライズ レベルのエージェントにとって最も重要です。 また、短い起動ウィンドウ、部門全体のイベント、スケジュールされたプロセス、数分で多数の要求を作成するワークフローなど、集中した使用パターンを持つ小規模なエージェントにも適用できます。

B2C と自律型エージェントには、レートの早期設定が必要です。

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

月単位の合計だけでなく、ピーク時のウィンドウを使用する

エージェントが 1 分または 1 時間で集中要求を作成できるかどうかを確認します。 ロード テスト、キャンペーン、停止応答、または自動トリガーによって、環境を介して大量のメッセージ、生成 AI 呼び出し、ワークフロー アクション、コネクタ呼び出し、または Dataverse 要求が短いウィンドウでプッシュされる場合、より小さなシナリオでは、レート プロビジョニングが必要な場合があります。

月間ボリュームは総需要を見積もるのに役立ちますが、レート プロビジョニングでは不十分です。 予想される使用量をより小さな時間枠に変換して、デザインと、リンク ページからの現在の 1 分あたりの要求数 (RPM)、1 時間あたりの要求数 (RPH)、バースト、日単位の制限を比較できるようにします。

平均トラフィック プロファイルとピーク トラフィック プロファイルの両方を構築します。 たとえば、ほとんどのトラフィックが毎日午後 5 時から午後 6 時の間に発生する場合、毎時のピークはその濃度を反映する必要があります。 トラフィックが 1 つのウィンドウに集中している場合、1 日の見積もりはピーク時の 24 倍である必要はありません。

これらの見積もりを使って設計のサイズと検証を行いましょう。 見積もりだけではスループット増加の要請にはなりません。 リクエストはパイロットフェーズで観察されたトラフィックと比較してレビューされます。これは「 パイロットフェーズを実行してからスループット増加を要求する」と説明されています。

スロットリングは他にどのような場合に発生しますか？

スロットリングは、次の場合にも発生することがあります:

• 大規模な従業員は、部門全体のイベントやトレーニングなど、予測可能なピーク期間にエージェントを使用します。
• マーケティングキャンペーン、障害、公開、または予定されているビジネスイベントによって、トラフィックが短時間急増します。
• Power Automateフローには、要求ボリュームを増幅するループ、再試行、改ページ、または子フローが含まれます。
• レポート、監査、テレメトリのエクスポート、またはトランスクリプト キャプチャは、ユーザー ターン パスで同期的に実行されます。
• 複数のエージェントまたはワークロードが、同じ環境、ID、コネクタ、またはダウンストリーム API の容量を共有します。
• ロード テストは、運用アーキテクチャまたはサポート プロセスが処理する準備が整ったよりも速く上昇します。

関連するレート制限を検索する場所

Copilot Studioには独自の制限があり、エージェントのランタイム パスには、独自の制限を持つ他のサービスが含まれる場合があります。 エージェントが使用するサービスに関連するすべての制限を確認します。

Copilot Studioの制限

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

ランタイム パスの最小制限によって、ユーザー エクスペリエンスが決まります。 Copilot Studio エージェント自体はその制限内に収まっていても、フロー、コネクタ、Dataverse 呼び出し、言語サービス、または外部 API はスロットリングされる可能性があります。

スループットの負荷を軽減する設計

レートの引き上げを最初の対応策にしないでください。 まず、エージェントの設計を確認し、効率を最適化します。 エージェントが何かを検索する必要がある場合は、外部呼び出しを意図的に維持し、API 呼び出しを最適化し、Copilot Studio、Power Automate、Dataverse、コネクタ、およびダウンストリーム システム全体で不要な要求ボリュームを回避します。

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

• 環境レベルの制限については、そのアプローチが運用設計に一致する場合は、複数の環境にエージェントを分割することを検討してください。 このアプローチは、大量のエージェント、ビジネス ユニット、リージョン、または自律ワークロードが、同じ環境スコープの制限に関連しないワークロードと競合しないようにするのに役立ちます。
• 自律エージェントの場合は、キュー、バッチ処理、トリガー フィルター、スケジュールされた処理、再試行制御、監視を使用して、バックグラウンド処理が制御されていないバーストとして到着しないようにします。
• 可能な場合は、スケジュールされた、レポート、監査のエクスポート、テレメトリの作業を対話型チャット パスの外部に移動します。
• ロード テストの結果と運用テレメトリを確認して、要求が集中する場所を特定し、より高い制限を要求する前にエージェント、フロー、コネクタ、ダウンストリーム API を調整します。

自律エージェントは、要求をキューに入れ、トリガーレートを制御することで、割り当てられた容量の使用を堅牢な予測可能性と可観測性で最大化するように独自に配置されています。

スループット増加を依頼する前にパイロットフェーズを実行してください

デフォルトの制限は、月間アクティブユーザー数が数千人規模のエージェントを含む、ほとんどの本番環境のエージェントに適しています。 スループットの向上を計画する前に、そのエージェントに本当にそれが必要かどうかを確認してください。

いきなり本格的なローンチに進むのは、対応される展開パターンではありません。 まずは対象対象のサブセットにエージェントをリリースし、実際の利用状況を観察し、その測定値をもとに全体の展開計画を立てましょう。 パイロット段階は打ち上げリスクを低減し、スループット増加申請に必要な証拠を生み出します。

実際の使用量は発売前の推定値と頻繁に異なります。 セッションの長さ、セッションごとのメッセージ数、ユーザーが生成応答やアクションにどれくらいの頻度で到達するか、リトライ動作、フロー、コネクター、Dataverse、外部API呼び出しのターン数などは、エージェントが実際のユーザーの手に渡るまで予測が難しいです。 パイロットは重要な制限や事前に予測が難しい交通パターンを提示します。

効果的なパイロットの設計

パイロット中の測定

公表されたレート制限に直接対応する値を取得します:

• 1分あたり・1時間あたりのメッセージ数、平均とピーク時の両方です。
• セッション数、同時セッション数、セッション長、および各セッションあたりのメッセージ。
• ターンごとおよびセッションごとの生成 AI 呼び出し回数（生成された回答、エージェントのアクション、ツールを含む）
• Power Automateのアクション、コネクタ呼び出し、エージェントターンごとに発生するDataverseリクエスト。
• スロットリングイベント、使用制限エラー、再試行、パイロットのピークウィンドウ中のレイテンシなどがあります。
• パイロット版の視聴者数は、意図された全視聴者の割合で表されます。

最大容量まで外挿する

観測されたピーク測定値を全聴衆にスケールし、使用した方法を記録しましょう。 パイロット期間中のピークトラフィックに基づいてスケーリングの基準を設定してください。日次平均や週次平均ではなく、スロットリングはトラフィックの集中によって発生するためです。 パイロット版で含まれていなかった追加リージョン、チャネル、自律的なワークロード、あるいはパイロット期間よりもトラフィックを集中させるローンチキャンペーンなどを考慮してください。

その結果、エビデンスに基づく要求が生まれます。すなわち、測定されたパイロットトラフィック、パイロットの聴衆シェア、外挿法、そしてそれに伴うフルスケールのピーク要件です。

既定のレート制限で十分でない場合の対応

パイロットトラフィックが見られた場合でも、エージェントや接続サービスが本格的に現在の公開上限を超えた場合は、展開拡大前にレートプロビジョニングサポートプロセスを開始してください。 最初の運用エラーを待つ必要はありません。

サポートリクエストを開く

管理者は 、Power Platform 管理センターにサポートを要求できます。

パイロットフェーズ終了後にチケットを開き、測定結果と最大容量への外推を添付してください。 設計時の見積もりや小さなUAT結果のみを含むリクエストはレビューできず、増加を遅らせることはできません。 詳細を丁寧に提供すればするほど、レビューは速くなります。 展開が拡大し、さらなるテレメトリーが利用可能になるにつれてリクエストを更新してください。

含めるコア情報

役に立つ詳細情報

関連情報

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