サービス保護の API 制限

すべてのユーザーに一貫した可用性とパフォーマンスを確保するために、システムは API の使用方法に制限を適用します。これらの制限は、クライアントアプリケーションがサーバーリソースに対して特別な要求を行うタイミングを検出します。

これらの制限は、対話型クライアントの通常のユーザーには影響しません。これらは、大量の API 要求を実行するクライアントアプリケーションにのみ影響します。これらの制限により、Microsoft Dataverse プラットフォームは、可用性とパフォーマンスを脅かす要求ボリュームのランダムで予期しない急増から保護されます。

クライアントアプリケーションが非常に要求の厳しい要求を行う場合、Dataverse はオンラインサービスの一般的なパターンに従います。受信した要求が多すぎることを示すエラーが返されます。

Web API を使用すると、Dataverse から 429 要求が多すぎますというエラーが返されます。
Dataverse SDK for .NET では、3 つの特定のエラーコードのいずれかで OrganizationServiceFault エラーが発生します。

サービス保護 API の制限エラーについて説明します

クライアントアプリケーションへの影響

クライアントアプリケーションは、サービス保護 API 制限のエラーを管理する責任を負います。このエラーを管理する方法は、アプリケーションの性質によって異なります。

対話型クライアントアプリケーション

サービス保護の制限は十分に高いため、対話型クライアントアプリケーションを使用している個人が通常の使用中に発生することはまれです。ただし、クライアントアプリケーションで一括操作が許可されている場合は可能です。クライアントアプリケーション開発者は、サービス保護 API の制限がどのように適用されるかを認識し、ユーザーが非常に要求の厳しい要求をサーバーに送信する可能性を減らすために UI を設計する必要があります。この場合でも、サービス保護 API の制限エラーが発生し、それらを処理するための準備が整っていることを期待する必要があります。

クライアントアプリケーション開発者は、ユーザーにメッセージを表示するために単にエラーをスローするべきではありません。エラーメッセージはエンドユーザー向けではありません。操作を再試行するための特定の戦略について説明します。

データ統合アプリケーション

Dataverse にデータを読み込むか、一括更新を実行するように設計されたアプリケーションでは、サービス保護 API の制限エラーを管理する必要があります。これらのアプリケーションは、最小限の時間で作業を完了できるように、スループットに優先順位を付けます。これらのアプリケーションには、操作を再試行する方法が必要です。最大スループットを取得するために適用できる戦略がいくつかあります。スループットを最大化する方法について説明します。

ポータルアプリケーション

ポータルアプリケーションは通常、匿名ユーザーからサービスプリンシパルアカウントを介して要求を送信します。サービス保護 API の制限はユーザーごとに基づいているため、ポータルアプリケーションは、ポータルで発生するトラフィックの量に基づいてサービス保護 API の制限に達する可能性があります。対話型クライアントアプリケーションと同様に、サービス保護 API を表示しないと、ポータルのエンドユーザーにエラーが制限されます。ポータルの UI は、それ以上の要求を無効にし、サーバーがビジー状態であることを示すメッセージを表示する必要があります。メッセージには、エラーで返されたRetry-After 期間を使用して計算された、アプリケーションが新しい要求の受け入れを開始できる時間が含まれている可能性があります。

プラグインとカスタムワークフローアクティビティへの影響

プラグインとカスタムワークフローアクティビティは、受信要求によってトリガーされるビジネスロジックを適用します。サービス保護の制限は、プラグインとカスタムワークフローアクティビティに由来するデータ操作には適用されません。プラグインとカスタムワークフローアクティビティは、分離サンドボックスサービス内で実行されます。サンドボックスサービスで呼び出されたデータバース操作では、パブリック API エンドポイントは使用されません。

アプリケーションがカスタムロジックをトリガーする操作を実行する場合、プラグインまたはカスタムワークフローアクティビティによって送信された要求の数は、サービス保護 API の制限にはカウントされません。ただし、これらの操作が提供する追加の計算時間は、それらをトリガーした最初の要求に追加されます。この計算時間は、サービス保護 API の制限の一部です。システムが Service Protection API の制限を適用する方法について説明します。

再試行操作

サービス保護 API の制限エラーが発生すると、ユーザーからの新しい要求を処理するまでの期間を示す値が提供されます。

Web API から 429 エラーが返されると、応答には秒単位の Retry-After ヘッダーが含まれます。
.NET 用 SDK では、TimeSpan 値がキー OrganizationServiceFault をもつ ErrorDetails.Retry-After コレクションで返されます。

Retry-After 期間

Retry-After期間は、前の 5 分間に送信された操作の性質によって異なります。要求が厳しいほど、サーバーの復旧にかかる時間は長くなります。

現在、制限の評価方法により、サービス保護 API の制限が有効になるまでの 5 分間の要求数と実行時間制限を超える可能性があります。ただし、同時要求の数を超えると、すぐにエラーが返されます。アプリケーションが引き続きこのような要求を送信する場合は、共有リソースへの影響を最小限に抑えるために期間が延長されます。この拡張機能により、個々の再試行後の期間が長くなります。つまり、アプリケーションでは、待機中に非アクティブな期間が長くなります。この動作は、将来変更される可能性があります。

可能な場合は、要求の数を減らしてから、サービス保護 API の制限に達するまで徐々に増やして、一貫したレートを実現してください。その後、5 分以内に処理できる要求の数をサーバーに通知します。この 5 分間に要求の最大数を制限し、徐々に増加することで再試行時間を低く抑え、合計スループットを最適化し、サーバーリソースの急増を最小限に抑えます。

対話型アプリケーションの再試行

クライアントが対話型アプリケーションの場合は、ユーザーが行った要求を再試行するときに、サーバーがビジーであることを示すメッセージを表示します。ユーザーが操作を取り消すオプションを指定できます。送信した前の要求が完了するまで、他の要求の送信をユーザーに許可しないでください。

非対話型アプリケーションの再試行

クライアントが対話型でない場合は、要求を再度送信する前に、継続時間が経過するまで待ちます。現在のタスクの実行を一時停止するには、 Task.Delay または同等のメソッドを使用します。

再試行する方法

次のセクションでは、Dataverse SDK for .NET または Web API を使用して .NET アプリケーションを再試行する方法について説明します。

SDK for .NET
Web API

SDK for .NET を使用している場合は、 PowerPlatform.Dataverse.Client.ServiceClient クラスまたは Xrm.Tooling.Connector.CrmServiceClient クラスを使用します。これらのクラスは IOrganizationService メソッドを実装し、返されるサービス保護 API の制限エラーを管理できます。

Xrm.Tooling.Connector の 9.0.2.16 (2019 年 5 月) 以降のバージョンでは、クライアントはRetry-After期間の後に要求を自動的に一時停止して再送信します。

現在、アプリケーションで低レベルの Xrm.Sdk.Client.OrganizationServiceProxy クラスまたは Xrm.Sdk.WebServiceClient.OrganizationWebProxyClient クラスを使用している場合は、それらのクラスを ServiceClient クラスまたは CrmServiceClient クラスに置き換えます。 OrganizationServiceProxy クラスは非推奨です。

詳細情報:

クライアントライブラリで Web API を使用している場合は、429 エラーで想定される再試行動作がサポートされている場合があります。クライアントライブラリの発行元に確認してください。

PowerShell を使用している場合、PowerShell Invoke-RestMethod コマンドレット MaximumRetryCount パラメーターは、エラーコードが 400 から 599 (304 を含む) の間で受信されたときに PowerShell が要求を再試行する回数を指定します。つまり、このパラメーターの値を含めると、PowerShell は Dataverse サービス保護 429 エラーを再試行します。 PowerShell を使用した Dataverse サービス保護の制限の管理の詳細について説明します。

独自のライブラリを記述した場合は、ヘルパー WebAPIService クラスライブラリ (C#) のこのサンプルコードに含まれている動作と同様の動作を含めることができます。

/// <summary>
/// Specifies the Retry policies
/// </summary>
/// <param name="config">Configuration data for the service</param>
/// <returns></returns>
static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy(Config config)
{
    return HttpPolicyExtensions
      .HandleTransientHttpError()
      .OrResult(httpResponseMessage => httpResponseMessage.StatusCode == System.Net.HttpStatusCode.TooManyRequests)
      .WaitAndRetryAsync(
         retryCount: config.MaxRetries,
         sleepDurationProvider: (count, response, context) =>
         {
            int seconds;
            HttpResponseHeaders headers = response.Result.Headers;

            if (headers.Contains("Retry-After"))
            {
               seconds = int.Parse(headers.GetValues("Retry-After").FirstOrDefault());
            }
            else
            {
               seconds = (int)Math.Pow(2, count);
            }
            return TimeSpan.FromSeconds(seconds);
         },
         onRetryAsync: (_, _, _, _) => { return Task.CompletedTask; }
      );
}

この例では、 Polly (.NET の回復性と一時的な障害処理ライブラリ) を使用します。これにより、開発者は、再試行、サーキットブレーカー、タイムアウト、バルクヘッド分離、フォールバックなどのポリシーを、流暢でスレッドセーフな方法で表現できます。

HTTP 応答ヘッダー

Web API で HTTP 要求を使用している場合は、次の HTTP 応答ヘッダーを使用して残りの制限値を追跡できます。

Header	値の説明
`x-ms-ratelimit-burst-remaining-xrm-requests`	この接続に対する要求の残りの数
`x-ms-ratelimit-time-remaining-xrm-requests`	同じユーザーアカウントを使用するすべての接続の残りの合計期間

送信する要求の数を制御するために、これらの値に依存しないでください。これらはデバッグを目的としています。アフィニティ Cookie を削除する場合は、別のサーバーに接続すると、これらの値がリセットされます。

システムが Service Protection API の制限を適用する方法

サービス保護 API の 2 つの制限では、5 分 (300 秒) のスライディングウィンドウが使用されます。いずれかの制限が上記の 300 秒を超えた場合、システムは後続の要求でサービス保護 API 制限エラーを返します。このエラーは、Retry-After 期間が終了するまでサービスを保護します。

システムは、各ユーザーのサービス保護 API の制限を評価します。認証された各ユーザーには、独立した制限があります。システムは、特別な要求を行うユーザーアカウントのみを制限します。他のユーザーには影響はありません。

システムは、次の 3 つのファセットに基づいてサービス保護 API の制限を適用します。

ユーザーが送信する要求の数。
ユーザーが送信する要求を処理するためにシステムが必要とする結合実行時間。
ユーザーが送信する同時要求の数。

システムが、ユーザーが送信する要求の数のみに制限を適用した場合は、それをバイパスできます。システムは、これらの試行に対抗するために他のファセットを追加します。例えば次が挙げられます。

バッチ操作でバンドルすることで、送信する要求が少なくなります。
- 合算される実行時間制限によって、この制限が相殺されます。
要求を個別に連続して送信するのではなく、サービス保護 API の制限が適用される前に多数の同時要求を送信できます。
- 同時要求の上限はこの制限を打ち消します。

環境で使用できる各 Web サーバーでは、これらの制限が個別に適用されます。ほとんどの環境には、複数の Web サーバーがあります。試用版環境では、1 つの Web サーバーのみが割り当てられます。環境で使用できる Web サーバーの実際の数は、複数の要因によって決まります。 Dataverse は、マネージドサービスの一部としてこれらの要因を提供します。要因の 1 つは、購入したユーザーライセンスの数です。

次の表では、 システムが Web サーバーごとに適用する既定のサービス保護 API の制限について説明します。

測る	Description	Web サーバーあたりの制限
要求の数	ユーザーが行った要求の累積数。	5 分のスライドウィンドウ内で 6,000
実行時間	ユーザーが行うすべての要求の合計実行時間。	5 分のスライドウィンドウ内で 20 分 (1,200 秒)
同時要求の数	ユーザーが行う同時要求の数。	52 以上

Important

これらの制限は変更される可能性があり、環境によって異なる場合があります。これらの数値は既定値を表し、期待できる値を把握できます。

サービス保護 API の制限エラー

このセクションでは、システムが返すことができる 3 種類のサービス保護 API 制限エラーについて説明します。また、これらのエラーの原因となる要因と、考えられる軽減戦略についても説明します。

エラーコードは、SDK for .NET OrganizationServiceFault.ErrorDetails が返す数値エラー値です。
16 進コードは、Web API が返す 16 進数のエラー値です。

要求の数

この制限は、前の 300 秒の期間中の要求の合計数をカウントします。

エラーコード	16 進コード	メッセージ
`-2147015902`	`0x80072322`	`Number of requests exceeded the limit of 6000 over time window of 300 seconds.`

対話型アプリケーションの一般的なユーザーは、アプリケーションでユーザーが一括操作を実行できない限り、1 分あたり 1,200 件の要求を送信してこの制限を超えません。

たとえば、リストビューで一度に 250 個のレコードを選択でき、ユーザーがこれらすべてのレコードに対して何らかの操作を実行できる場合、ユーザーはこの操作を 300 秒のスパンで 24 回実行する必要があります。ユーザーは、12.5 秒以内に各リストの操作を完了する必要があります。

アプリケーションでこの機能が提供される場合は、次の戦略のいくつかを検討してください。

ユーザーが一覧で選択できるレコードの合計数を減らします。リストに表示される項目の数が 50 に減った場合、ユーザーはこの操作を 300 秒以内に 120 回実行する必要があります。ユーザーは、各リストの操作を 2.5 秒以内に完了する必要があります。
選択した操作をバッチに結合します。バッチには最大 1,000 個の操作を含めることができるので、要求数の制限を回避できます。ただし、実行時間制限に備える必要があります。

実行時間

この制限は、前の 300 秒の期間中の受信要求の合計実行時間を追跡します。

エラーコード	16 進コード	メッセージ
`-2147015903`	`0x80072321`	`Combined execution time of incoming requests exceeded limit of 1,200,000 milliseconds over time window of 300 seconds. Decrease number of concurrent requests or reduce the duration of requests and try again later.`

一部の操作では、他の操作よりも多くのリソースが必要です。バッチ操作、ソリューションのインポート、非常に複雑なクエリは、非常に厳しい場合があります。これらの操作は、同時要求でも同時に実行される場合があります。そのため、5 分以内に、合計計算時間が 20 分を超える操作を要求できます。

この制限は、バッチ操作と同時要求を含む戦略を使用して、要求数の制限を回避する場合に発生する可能性があります。

同時要求数

この制限により、同時要求の数が追跡されます。

エラーコード	16 進コード	メッセージ
`-2147015898`	`0x80072326`	`Number of concurrent requests exceeded the limit of 52.`

クライアントアプリケーションは、個々の要求を順番に送信するだけではありません。クライアントは、並列プログラミングパターンまたはさまざまなメソッドを適用して、複数の要求を同時に送信する場合があります。サーバーは、同じユーザーからの複数の要求に同時に応答するタイミングを検出できます。同時実行要求の数がこの数を超えると、サーバーはこのエラーを発生させます。場合によっては、上限が 52 を超える場合があります。

同時要求の送信は、スループットを最大化するための戦略の重要な部分ですが、制御を維持することが重要です。 .NET で並列プログラミングを使用する場合、並列処理の既定の次数は、コードを実行しているサーバー上の CPU コアの数によって異なります。制限を超えてはなりません。 ParallelOptions.MaxDegreeOfParallelism プロパティを同時実行タスクの最大数を定義するように設定できます。

並列要求の送信について説明します。

スループットを最大化する方法

最短の期間で最も多くのデータを移動するためにスループットに優先順位を付ける必要があるアプリケーションがある場合は、次の戦略を適用します。

処理できる量をサーバーに通知する

一度に送信する要求の数を計算しないでください。環境ごとに異なる場合があります。制限に達し始めるまで要求を送信する速度を徐々に増やし、サービス保護 API の制限 Retry-After 値に依存して、送信するタイミングを示します。この値により、合計スループットが可能な限り高いレベルで維持されます。

複数のスレッドの使用

同時実行スレッドの数の上限が高いほど、アプリケーションでパフォーマンスが大幅に向上するために使用できます。この改善は、個々の操作が比較的迅速な場合に当てはまります。処理するデータの性質によっては、最適なスループットを得るためにスレッドの数を調整することが必要になる場合があります。要求を並列で送信する方法について説明します。

大量バッチを避ける

バッチ処理 とは、1 つの要求で複数の操作を送信することを指します。

ほとんどのシナリオでは、並列処理の度合いが高い 1 つの要求を最速で送信します。バッチサイズによってパフォーマンスが向上する可能性がある場合は、10 の小さなバッチサイズから開始し、再試行するサービス保護 API の制限エラーが発生し始めるまでコンカレンシーを増やします。

SDK for .NET では、このアプローチは ExecuteMultipleRequest を使用することを意味します。通常、要求で最大 1,000 個の操作を送信できます。この方法の主な利点は、ネットワーク経由で送信する必要がある XML ペイロードの総量を減らすことです。この方法では、ネットワーク待機時間が問題である場合にパフォーマンス上の利点があります。サービス保護の制限では、要求あたりの合計実行時間が増加します。サイズの大きいバッチでは、要求数の制限ではなく、実行時間の制限が発生する可能性が高くなります。

以前は、 ExecuteMultiple 操作は、この制限が与える可能性のあるパフォーマンスへの影響により、一度に 2 つだけに制限されていました。サービス保護の実行時間 API の制限によってその制限が冗長になっているため、この制限は当てはまることがなくなりました。

Web API を使用する場合、個々の要求に対してネットワーク経由で送信される JSON ペイロードが小さいということは、ネットワーク待機時間が問題ではないことを意味します。 Web API を使用したバッチ操作の実行について説明します。

注

バッチ操作は、エンタイトルメント制限をバイパスするための有効な戦略ではありません。サービス保護 API の制限とエンタイトルメントの制限は個別に評価されます。権利制限は CRUD 操作に基づいており、それらがバッチ操作に含まれているかどうかに関わらず蓄積されます。エンタイトルメントの制限について学ぶ。

サービス保護 API の制限を管理するための戦略

このセクションでは、サービス保護 API の制限エラーを回避するようにクライアントとシステムを設計する方法について説明します。また、影響を軽減するためにライセンスを管理する方法を検討することもできます。

クライアントアプリケーションを更新する

Dataverse では、2018 年から Service Protection API の制限が適用されています。ただし、多くのクライアントアプリケーションは、これらの制限が存在する前に記述されていました。これらのクライアントはこれらのエラーを予期せず、エラーを正しく処理できません。これらのアプリケーションを更新し、前に説明した再試行操作にパターンを適用します。

リアルタイム統合への移行

サービス保護 API の制限の主な目的は、短期間に集中する高負荷な要求の影響を緩和することです。現在のビジネスプロセスが、短時間で大量のデータを処理しようとする大規模な定期的な夜間、毎週、または毎月のジョブに依存している場合は、リアルタイムのデータ統合戦略を有効にする方法を検討してください。要求の厳しい操作を必要とするプロセスから離れる場合は、サービス保護の制限に与える影響を軽減できます。

よく寄せられる質問

このセクションには、よく寄せられる質問が含まれています。回答できない質問がある場合は、このページの下部にある [フィードバック ] ボタンを使用して投稿し、このページに関するフィードバックを送信します。

ライセンスを取得した ETL アプリケーションを使用しています。最適なスループットを得るにはどうすればよいですか?

ETL アプリケーションベンダーと協力して、適用する設定を確認してください。 Retry-After 動作をサポートする製品のバージョンを使用していることを確認します。

これらの制限は Dataverse 検索に適用されますか?

No. Dataverse ネイティブ検索では、異なる API (api/searchではなくapi/data) が使用され、規則が異なります。 Dataverse 検索 API を使用する場合、ユーザーごとに 1 秒あたり 1 つの要求の調整制限があります。

Dataverse Search Service Protection の制限について説明します。

これらの制限は、ユーザーが毎日受け取る権利のある要求の数にどのように適用されますか?

これらの制限は、エンタイトルメントの制限とは関係ありません。エンタイトルメントの制限について学ぶ。

制限はアプリケーションユーザーに対して異なる方法で適用されますか?

No. システムは、すべてのユーザーに同じ制限を適用します。

こちらも参照ください

Power Platform の管理/ ライセンスとライセンスの管理 / 要求の制限と割り当て
 Dataverse API の制限の概要
 Dataverse Web API を使用する
 Dataverse SDK for .NET を使用する

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-01-09