SharePoint Online で調整またはブロックを回避するAvoid getting throttled or blocked in SharePoint Online

ここでは、SharePoint Online の調整を説明し、調整とブロックを回避する方法を検討します。Find out about throttling in SharePoint Online, and learn how to avoid being throttled or blocked. 簡単に使用できる CSOM サンプルと REST コードも紹介します。Includes sample CSOM and REST code you can use to make your task easier.

SharePoint Online でファイルを移行するときなどに CSOM プロセスが実行されるものの調整されていることがよくありますか。さらに悪いことに、完全にブロックされることさえあります。このような状況の詳細と、これを回避する方法を説明します。Does this sound familiar? You're running a CSOM process - for example, to migrate files in SharePoint Online - but you keep getting throttled. Or even worse, you get completely blocked. What's going on and what can you do to make it stop?

調整とはWhat is throttling?

SharePoint Online は、SharePoint Online サービスの最適なパフォーマンスと信頼性を維持する目的で調整を使用します。調整では、リソースの過剰な使用を防ぐため、ユーザー アクションまたは (スクリプトまたはコードによる) 同時呼び出しの数が制限されます。SharePoint Online uses throttling to maintain optimal performance and reliability of the SharePoint Online service. Throttling limits the number of user actions or concurrent calls (by script or code) to prevent overuse of resources.

ただし、ユーザーが SharePoint Online で調整されるケースは非常に稀です。サービスは堅牢であり、非常に大量のボリュームにも対処できるように設計されています。調整が発生する場合、99% の割合でその原因はカスタム コードにあります。この原因以外に調整が発生することがないというわけではありませんが、そのような状況は一般的ではありません。たとえば 10 台のマシンをスピンアップし、10 台すべてのマシンでクライアント同期が実行され、各マシンで 1TB のコンテンツが同期されるとします。このような状況では調整が発生する可能性があります。That said, it is extremely rare for a user to get throttled in SharePoint Online. The service is robust, and it is designed to handle very high volume. If you do get throttled, 99% of the time it is because of custom code. That doesn't mean that there aren't other ways to get throttled, just that they are less common. For example you spin up 10 machines and have a sync client going on all 10. On each sync 1TB of content. This would likely get you throttled.


SharePoint Online で調整が発生する状況What happens when you get throttled in SharePoint Online?

あるユーザーが使用制限を超えると、そのユーザー アカウントからさらに送られる要求は SharePoint Online によって短時間、調整されます。調整が有効な間、ユーザー操作はすべて調整されます。When a user exceeds usage limits, SharePoint Online throttles any further requests from that user account for a short period. All user actions are throttled while the throttle is in effect.

  • ユーザーがブラウザーで直接実行する要求の場合、SharePoint Online はユーザーを調整情報のページにリダイレクトし、要求は失敗します。For requests that a user performs directly in the browser, SharePoint Online redirects you to the throttling information page, and the requests fail.

  • その他すべての要求の場合 (CSOM または REST 呼び出しを含む)、SharePoint Online は HTTP ステータス コード 429 (「要求が多すぎます」) または 503 (「サーバーがビジー状態です」) を返し、要求は失敗します。For all other requests, including CSOM or REST calls, SharePoint Online returns HTTP status code 429 ("Too many requests") or 503 ("Server Too Busy") and the requests will fail.

問題のあるプロセスにより使用量の制限を超え続ける場合、SharePoint Online はプロセスを完全にブロックします。そうなった場合、要求はすべて失敗し、Office 365 メッセージ センターでブロックの通知をいたします。If the offending process continues to exceed usage limits, SharePoint Online might completely block the process; in this case, you will not see any successful requests and we will notify you of the block in the Office 365 Message Center.

アプリケーションの調整Application Throttling

ユーザー アカウントによる調整に加え、制限は各アプリケーションにも適用されます。In addition to throttling by user account, limits are also applied to each application. SharePoint Online のすべてのアプリケーションにはそれぞれ固有の利用可能なリソースがありますが、同一のテナントに対して複数のアプリケーションが実行されると、最終的には同じリソース バケットからリソースを共有することになり、まれにですがレート制限が発生します。Every application in SharePoint Online has its own available resources, but multiple applications running against the same tenant ultimately share from the same resource bucket and in rare occurrences can cause rate limiting. このような場合は、SharePoint Online はバックグラウンドの動作よりもインタラクティブなユーザー要求を優先させようとします。In these cases, SharePoint Online will attempt to prioritize interactive user requests over background activities.

SharePoint Online での一般的な調整シナリオCommon throttling scenarios in SharePoint Online

SharePoint Online でユーザー単位の調整が生じる最も一般的な原因は、クライアント側オブジェクト モデル (CSOM) コードまたは Representational State Transfer (REST) コードで実行される操作の頻度と数が多すぎることです。The most common causes of per-user throttling in SharePoint Online are client-side object model (CSOM) or Representational State Transfer (REST) code that performs too many actions too frequently.

  • 散発的なトラフィックSporadic traffic

    影響を少なくするため、SharePoint Online に対する一定負荷または繰り返しの複雑なクエリは最適化する必要があります。Constant load or repetitive complex queries against SharePoint Online must be optimized for low impact. アプリケーションをスキャンするためのベスト プラクティス」に従ってファイルの一括処理を行わない場合、調整が発生する可能性が高くなります。Failing to follow best practices for scanning applications that process files in bulk will likely result in throttling. これらのアプリケーションには、同期エンジン、バックアップ プロバイダー、検索インデクサー、分類エンジン、データ損失防止用ツール、およびデータ全体を推論して変更を適用しようとするその他のツールが含まれます。These apps include sync engines, backup providers, search indexers, classification engines, data loss prevention tools, and any other which attempts to reason over the entirety of data and change.

    • たとえば、ファイルを SharePoint Online へ移行した後に、ファイルのメタデータを更新するカスタム CSOM または REST スクリプトを実行するとします。CSOM/REST スクリプトは多数のファイルを非常に高い頻度で更新するため、調整が発生します。同様に、REST サービスを使用するオートコンプリート UI ウィジェットは、各エンド ユーザー操作中にリストの呼び出しを多数実行するため、同時にリソースを消費するその他の操作によっては、調整が発生することがあります。For example, after migrating files to SharePoint Online, you run a custom CSOM or REST script to update metadata on the files. The CSOM/REST script is updating a large number of files at a very high frequency, which triggers throttling. Similarly, an autocomplete UI widget using REST services, making too many calls to lists during each end user operation, may also cause throttling, depending on what other operations are consuming resources at the same time.


  • 圧倒的な大量トラフィックOverwhelming traffic

    1 つのプロセスが、長期にわたって継続的に調整制限を大幅に超過します。A single process dramatically exceeds throttling limits, continually, over a long time period.

    • Web サービスを使用して、ユーザー プロファイル プロパティを同期するツールを作成したとします。このツールは、基幹業務 (LOB) 人事 (HR) システムの情報に基づいてユーザー プロファイルのプロパティを更新します。このツールが呼び出しを実行する頻度が高すぎます。You used web services to build a tool to synchronize user profile properties. The tool updates user profile properties based on information from your line-of-business (LOB) human resources (HR) system. The tool makes calls at too high a frequency.

    • SharePoint Online でロード テスト用のスクリプトを実行すると、調整が生じます。SharePoint Online ではロード テストはできません。You're running a load-testing script on SharePoint Online and you get throttled. Load testing is not allowed on SharePoint Online.

    • SharePoint Online のチーム サイトをカスタマイズし、ステータス インジケーターをホーム ページに追加しました。このステータス インジケーターが頻繁に更新されて、そのページで SharePoint Online サービスに対する呼び出しが多くなりすぎ、調整が発生します。You customized your team site on SharePoint Online, for example, by adding a status indicator on the Home page. This status indicator updates frequently, which causes the page to make too many calls to the SharePoint Online service - this triggered throttling.


正確な調整制限を設定できない理由Why can't you just tell me the exact throttling limits?

正確な調整制限を設定し公開するというのは簡単そうに思えるかもしれませんが、実際にはさらに厳しい制限につながります。Setting and publishing exact throttling limits sounds very straightforward, but in fact it would result in more restrictive limits. Microsoft では、SharePoint Online でのリソースの使用状況を継続的に監視しています。We continually monitor resource usage on SharePoint Online. SharePoint Online の信頼性とパフォーマンスを低下させることなくユーザーが最大数のリソースを利用できるように、使用状況に応じてしきい値を微調整しています。Depending on usage, we fine-tune thresholds so users can consume the maximum number of resources without degrading the reliability and performance of SharePoint Online. このため、CSOM または REST コードが Retry-After ヘッダー値を尊重することが非常に重量です。これにより、コードは常時可能な限り高速で実行され、調整制限に達した場合も、コードは必要最小限の範囲で要求を減らすことができます。That's why it's so important for your CSOM or REST code to honor the retry-after header value; this lets your code run as fast as possible on any given day, and it lets your code back off "just enough" if it hits throttling limits. この記事で後述するコード サンプルでは、Retry-After ヘッダーを使用する方法を説明します。The code samples later in this article show you how to use the retry-after header.

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

  • 要求あたりの操作数を削減するReduce the number of operations per request

  • 呼び出しの頻度を減らすReduce the frequency of calls

  • ユーザーがわかるように、トラフィックを装飾する (後述のトラフィックを装飾するためのベストプラクティスを参照)Decorate your traffic so we know who you are (see section on traffic decoration best practice more on that below)

  • Retry-After ヘッダーを活用するLeverage the retry-after header

お客様の要求に対して調整が行われた場合、調整が解除されるまでの遅延を最小限に抑えるため、Retry-After ヘッダーを活用する必要があります。If you do run into throttling, we require leveraging the retry-after header to ensure minimum delay till the throttle is removed.

SharePoint Online は再トライのタイミングを動的に決定するため、Retry-After は、調整を受けた際に最も早く対処できる方法です。Retry after is the fastest way to handle being throttled because SharePoint Online dynamically determines the right time to try again. 言い換えると、呼び出しが失敗する場合でも、使用量の制限に反して呼び出しが発生するため、積極的なリトライは不利に働きます。In other words, aggressive retries work against you because even though the calls fail, they still accrue against your usage limits. Retry-After ヘッダーを活用すれば、遅延を最小限に抑えられます。Following the retry header will ensure the shortest delay.

SharePoint Online アクティビティの監視方法について詳しくは、「 Diagnosing performance issues with SharePoint Online」をご覧ください。For information about ways to monitor your SharePoint Online activity, see Diagnosing performance issues with SharePoint Online.

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

調整を回避するために、http トラフィックを装飾する方法How to decorate your http traffic to avoid throttling?

高い可用性の維持のため、一部のトラフィックが制限される可能性があります。To ensure and maintain high-availability, some traffic may be throttled. 調整はシステムの健全性が危険にさらされている場合に発生します。調整で使用する要件のひとつとしてトラフィックの装飾があります。これはトラフィックの優先度決定に直接影響を与えます。Throttling happens when system health is at stake and one of the criteria used for throttling is traffic decoration, which impacts directly on the prioritization of the traffic. 適切に装飾されたトラフィックは、不適切な装飾を施したトラフィックより優先されます。Well decorated traffic will be prioritized over traffic which is not properly decorated.

装飾されていないトラフィックの定義は?What is definition of undecorated traffic?

  • SharePoint Online への CSOM または REST API 呼び出しに、AppID/AppTitle および User Agent 文字列がない場合は、非装飾のトラフィックです。Traffic is undecorated if there is no AppID/AppTitle and User Agent string in CSOM or REST API call to SharePoint Online. User Agent 文字列は、次のように、特定の形式になっている必要があります。The User Agent string should be in a specific format as described below.

推奨事項には何がありますか?What are the recommendations?

  • アプリケーションを作成した場合、AppID と AppTitle を登録して使用するようお勧めします。これにより、総合的なエクスペリエンスが向上し、今後の問題解決のための最善の道筋が確立されます。If you have created an application, the recommendation is to register and use AppID and AppTitle – This will ensure the best overall experience and best path for any future issue resolution. また、次の手順に従い、User Agent 文字列情報も使用してください。Include also the User Agent string information as defined in following step.

  • SharePoint への API の呼び出しに、次の命名規則に従った User Agent 文字列を必ず含めてください。Make sure to include User Agent string in your API call to SharePoint with following naming convention

種類Type ユーザー エージェントUser Agent 説明Description
ISV ApplicationISV Application ISV|CompanyName|AppName/VersionISV|CompanyName|AppName/Version ISV を指定し、会社名、アプリ名をパイプ文字で区切り、その後ろにスラッシュで分離してバージョン番号を追加します。Identify as ISV and include Company Name, App Name separated by a pipe character and then adding Version number separated with a slash character
エンタープライズ アプリケーションEnterprise application NONISV|CompanyName|AppName/VersionNONISV|CompanyName|AppName/Version NONISV を指定し、会社名、アプリ名をパイプ文字で区切り、その後ろにスラッシュで分離してバージョン番号を追加します。Identify as NONISV and include Company Name, App Name separated by a pipe character and then adding Version number separated with a slash character
  • SharePoint Online API を呼び出すための自前の JavaScript ライブラリを構築している場合は、http 要求にユーザー エージェント情報を付加していることを確認してください。また、適切な場所で、使用する Web アプリケーションをアプリケーションとしても登録することを検討してください。If you are building your own JavaScript libraries, which are used to call SharePoint Online APIs, make sure that you include the User Agent information to your http request and potentially register your web application also as an Application, where suitable.


ユーザー エージェント文字列の形式は RFC2616 に従ったものとします。よって、この勧告に従った右の区切り文字を使用してください。Format of the user agent string is expected to follow RFC2616, so please follow up on the above guidance on the right separators. 要求された情報のやりとりにも既存のユーザー エージェント文字列を付加することができます。It is also fine to append existing user agent string with the requested information.


ブラウザーで実行中のフロント エンド コンポーネントを開発している場合、最新のブラウザーのほとんどはユーザー エージェント文字列の上書きを許可していないので、この機能を実装する必要はありません。If you are developing front end components executing in the browser, most of modern browsers don't allow overwriting the user agent string and you don't need to implement this.

クライアント側オブジェクト モデル (CSOM) を使用した場合で、ユーザー エージェントを使いトラフィックを装飾する例Example of decorating traffic with User agent when using Client Side Object Model (CSOM)

// Get access to source site
using (var ctx = new ClientContext(""))
    //Provide account and pwd for connecting to SharePoint Online
    var passWord = new SecureString();
    foreach (char c in pwd.ToCharArray()) passWord.AppendChar(c);
    ctx.Credentials = new SharePointOnlineCredentials("", passWord);

    // Add our User Agent information
    ctx.ExecutingWebRequest += delegate (object sender, WebRequestEventArgs e)
        e.WebRequestExecutor.WebRequest.UserAgent = "NONISV|Contoso|GovernanceCheck/1.0";

    // Normal CSOM Call with custom User-Agent information
    Web site = ctx.Web;

REST API を使用した場合で、ユーザー エージェントを使いトラフィックを装飾する例Example of decorating traffic with User agent when using REST APIs

次の例は、C# の形式ですが、SharePoint Online のページで使用されている JavaScript ライブラリに対しても、同様のユーザー エージェント情報の使用をお勧めします。Following sample is in c# format, but the similar User Agent information is recommended to be used even for the JavaScript libraries used in the SharePoint Online pages.

HttpWebRequest endpointRequest = (HttpWebRequest)HttpWebRequest.Create(sharepointUrl.ToString() + "/_api/web/lists");
endpointRequest.Method = "GET";
endpointRequest.UserAgent = "NONISV|Contoso|GovernanceCheck/1.0";
endpointRequest.Accept = "application/json;odata=verbose";
endpointRequest.Headers.Add("Authorization", "Bearer " + accessToken);
HttpWebResponse endpointResponse = (HttpWebResponse)endpointRequest.GetResponse();

CSOM コード サンプル: ExecuteQueryWithIncrementalRetry 実行メソッドCSOM Code sample: ExecuteQueryWithIncrementalRetry extension method


SharePoint Online CSOM バージョン 16.1.8316.1200 (2018 年 12 月のバージョン) 以降を使用することが必要になります。You'll need to use SharePoint Online CSOM version 16.1.8316.1200 (December 2018 version) or higher.

静的クラス内にこの拡張メソッドを追加し、ExecuteQuery ではなく ExecuteQueryWithIncrementalRetry を使用することで、コードによって要求の調整を処理します。Add this extension method in a static class and use ExecuteQueryWithIncrementalRetry instead of ExecuteQuery to make your code handle throttling requests.

public static void ExecuteQueryWithIncrementalRetry(this ClientContext clientContext, int retryCount, int delay)
    int retryAttempts = 0;
    int backoffInterval = delay;
    int retryAfterInterval = 0;
    bool retry = false;
    ClientRequestWrapper wrapper = null;
    if (retryCount <= 0)
        throw new ArgumentException("Provide a retry count greater than zero.");
    if (delay <= 0)
        throw new ArgumentException("Provide a delay greater than zero.");

    // Do while retry attempt is less than retry count
    while (retryAttempts < retryCount)
            if (!retry)
                // retry the previous request
                if (wrapper != null && wrapper.Value != null)
        catch (WebException ex)
            var response = ex.Response as HttpWebResponse;
            // Check if request was throttled - http status code 429
            // Check is request failed due to server unavailable - http status code 503
            if (response != null && (response.StatusCode == (HttpStatusCode)429 || response.StatusCode == (HttpStatusCode)503))
                wrapper = (ClientRequestWrapper)ex.Data["ClientRequest"];
                retry = true;

                // Determine the retry after value - use the retry-after header when available
                string retryAfterHeader = response.GetResponseHeader("Retry-After");
                if (!string.IsNullOrEmpty(retryAfterHeader))
                    if (!Int32.TryParse(retryAfterHeader, out retryAfterInterval))
                        retryAfterInterval = backoffInterval;
                    retryAfterInterval = backoffInterval;

                // Delay for the requested seconds
                Thread.Sleep(retryAfterInterval * 1000);

                // Increase counters
                backoffInterval = backoffInterval * 2;
    throw new MaximumRetryAttemptedException($"Maximum retry attempts {retryCount}, has be attempted.");

public class MaximumRetryAttemptedException : Exception
    public MaximumRetryAttemptedException(string message) : base(message) { }

SharePoint Online でブロックが生じた場合の対処方法What should you do if you get blocked in SharePoint Online?

ブロックは、最も強い形式の調整です。Blocking is the most extreme form of throttling. SharePoint Online サービス全体の正常性を脅かすような極端な過剰トラフィックが長期に渡り検出された場合を除き、テナントをブロックすることはまずありません。We rarely ever block a tenant, unless we detect long-term, extremely excessive traffic that may threaten the overall health of the SharePoint Online service. ブロックは、過剰トラフィックが SharePoint Online のパフォーマンスと信頼性を低下させてしまうことを防ぐために適用されます。We apply blocks to prevent excessive traffic from degrading the performance and reliability of SharePoint Online. 通常、ブロックはアプリまたはユーザー レベルで配置され、問題が解決されるまで問題のあるプロセスが実行できないようにします。A block - which is usually placed at the app or user level - prevents the offending process from running until you fix the problem. サブスクリプションをブロックする場合、ブロックを削除する前に、問題のあるプロセスを変更するよう対処する必要があります。If we block your subscription, you must take action to modify the offending processes before the block can be removed.

サブスクリプションがブロックされた場合は、Office 365 メッセージ センターでブロックのお知らせをいたします。If we block your subscription we will notify you of the block in the Office 365 Message Center. メッセージでは、ブロックを引き起こした原因の説明と問題の解決方法のガイダンスが提供され、ブロックを解除するための連絡先も書かれています。The message describes what caused the block, provides guidance on how to resolve the offending issue, and tells you who to contact to get the block removed.

関連項目See also