Microsoft Graph 調整ガイドMicrosoft Graph throttling guidance

調整とは、リソースの使いすぎを防ぐために、サービスの同時呼び出し数を制限することをいいます。Microsoft Graph は、大量の要求を処理できるよう設計されています。過剰な数の要求が発生した場合、調整を行うことは Microsoft Graph サービスの最適なパフォーマンスと信頼性の維持に役立ちます。Throttling limits the number of concurrent calls to a service to prevent overuse of resources. Microsoft Graph is designed to handle a high volume of requests. If an overwhelming number of requests occurs, throttling helps maintain optimal performance and reliability of the Microsoft Graph service.

制限の調整はシナリオによって異なります。たとえば、大量の書き込みを行う際には、読み込みのみを行う場合に比べて調整が起こる可能性は高くなります。Throttling limits vary based on the scenario. For example, if you are performing a large volume of writes, the possibility for throttling is higher than if you are only performing reads.

調整が発生すると、何が起こるのでしょうかWhat happens when throttling occurs?

調整のしきい値を超えた場合、Microsoft Graph はそのクライアントの以降の要求を一定時間制限します。調整が発生した場合、Microsoft Graph は HTTP ステータス コード 429 (Too Many Requests) を返し、要求は失敗します。失敗した要求の応答ヘッダーで、推奨される待機時間を返します。調整の動作は要求の種類と数によります。たとえば、大量の要求があれば、すべての種類の要求が調整されます。しきい値は要求の種類によって異なります。そのため、書き込みは調整を受けるが、読み込みはそのままで許容されるシナリオが起こりえます。When a throttling threshold is exceeded, Microsoft Graph limits any further requests from that client for a period of time. When throttling occurs, Microsoft Graph returns HTTP status code 429 (Too many requests), and the requests fail. A suggested wait time is returned in the response header of the failed request. Throttling behavior can depend on the type and number of requests. For example, if you have a high volume of requests, all requests types are throttled. Threshold limits vary based on the request type. Therefore, you could encounter a scenario where writes are throttled but reads are still permitted.

一般的な調整のシナリオCommon throttling scenarios

クライアントに対して調整が発生する最も一般的な原因は次のとおりです。The most common causes of throttling of clients include:

  • あるテナントのすべてのアプリケーションから大量の要求がある。A large number of requests across all applications in a tenant.
  • すべてのテナントで、特定のアプリケーションから大量の要求がある。A large number of requests from a particular application across all tenants.

調整に対応するためのベスト プラクティスBest practices to handle throttling

調整に対応するためのベスト プラクティスには、次のようなものがあります。The following are best practices for handling throttling:

  • 要求あたりの操作の数を減らす。Reduce the number of operations per request.
  • 呼び出しの頻度を減らす。Reduce the frequency of calls.
  • すべての要求が使用量の制限に計上されるため、即時の再試行を避ける。Avoid immediate retries, because all requests accrue against your usage limits.

エラー処理を実装する場合は、HTTP エラー コード 429 を使用して調整の発生を検出します。失敗した要求には、Retry-After 応答ヘッダーが含まれています。Microsoft Graph はクライアントが調整による制限を受けている間でもリソースの使用量を記録しています。そのため、Retry-After の指示に従って要求を遅延させることが最も迅速に調整を解消できる方法です。When you implement error handling, use the HTTP error code 429 to detect throttling. The failed response includes the Retry-After field in the response header. Backing off requests using the Retry-After delay is the fastest way to recover from throttling because Microsoft Graph continues to log resource usage while a client is being throttled.

  1. Retry-After ヘッダーに指定された秒数だけ待機してください。Wait the number of seconds specified in the Retry-After field.
  2. 要求を再試行してください。Retry the request.
  3. 要求が再度エラーコード 429 で失敗した場合は、依然として調整を受けています。推奨された Retry-After 遅延に引き続き従い、成功するまで再試行してください。If the request fails again with a 429 error code, you are still being throttled. Continue to use the recommended Retry-After delay and retry the request until it succeeds.

現在、次のリソースで Retry-After ヘッダーが提供されています。The following resources currently provide a retry-after header:

Microsoft Cloud における調整についてのより幅広い議論については「調整パターン」を参照してください。For a broader discussion of throttling on the Microsoft Cloud, see Throttling Pattern.

サービス固有の制限Service-specific limits

Microsoft Graph では、Outlook や Azure Active Directory などの複数のサービスのデータにアクセスできます。Microsoft Graph allows you to access data in multiple services, such as Outlook or Azure Active Directory. これらのサービスは、Microsoft Graph を使用してそれらにアクセスするアプリケーションに影響する独自に調整した制限を課します。These services impose their own throttling limits that affect applications that use Microsoft Graph to access them.

注意

ここで説明する特定の制限は変更される場合があります。The specific limits described here are subject to change.

Outlook サービスの制限Outlook service limits

Outlookサービスの制限は、アプリ ID とメールボックスの組み合わせごとに判定されます。Outlook service limits are evaluated for each app ID and mailbox combination. つまり、説明されている制限は、特定のメールボックス (ユーザーまたはグループ) にアクセスする特定のアプリに適用されます。In other words, the limits described apply to a specific app accessing a specific mailbox (user or group). アプリケーションが 1 つのメールボックス内で制限を超えても、別のメールボックスにアクセスする機能には影響しません。If an application exceeds the limit in one mailbox, it does not affect the ability to access another mailbox.

極限Limit 適用対象Applies to
10 分間で 10,000 件の API リクエスト10,000 API requests in a 10 minute period v 1.0 およびベータ版エンドポイントv1.0 and beta
4 つの同時リクエスト4 concurrent requests ベータ版エンドポイントBeta endpoint
30 秒間で15 mbのアップロード (PATCH、POST、PUT)15 megabit upload (PATCH, POST, PUT) in a 30 second period ベータ版エンドポイントBeta endpoint

Outlook サービス リソースOutlook service resources

次のリソースは、Outlook サービスによって提供されます。The following resources are provided by the Outlook service.

予定表の API リソースCalendar API resources
メールの API リソースMail API resources
個人用連絡先 API リソースPersonal contacts API resources
ソーシャル インテリジェンスおよび職場のインテリジェンスのリソースSocial and workplace intelligence resources
To do タスク API (プレビュー) リソースTo-do tasks API (preview) resources