SharePoint Online を Veeam Backup for Microsoft 365 でバックアップしていると、突然ジョブが遅くなり「429/503 が出ている＝スロットリング」と言われることがあります。本記事ではスロットリングの仕組み、上限の確認方法、影響範囲の切り分け、運用での緩和策を実務目線でまとめます。
SharePoint Online のスロットリング（Throttling）とは
SharePoint Online のスロットリング（Throttling / アクセス抑制）は、クラウド側の性能と安定性を守るために、一定時間あたりの要求（API 呼び出し、検索、ファイル取得、メタデータ参照など）が多すぎると判断したときに、処理を一時的に制限する仕組みです。障害のように見えても、実態は「サービスを落とさないためのブレーキ」であることが多く、バックアップや移行、全社一斉の同期など“短時間に大量の要求が出る作業”で発生しやすくなります。
Veeam Backup for Microsoft 365（Veeam の M365 バックアップ）のバックアップは、SharePoint Online に対して継続的に API を呼び出しながらデータを収集します。並列処理（同時実行数）や対象サイトの規模、実行時間帯が重なると、SharePoint 側の判断でスロットリングが入り、ジョブは失敗ではなく「待たされながら進む」状態になります。結果として、完了までの時間が想定より大幅に伸びる、バックアップウィンドウ内に終わらない、といった運用課題につながります。
スロットリング時に返りやすいステータスコード
スロットリングが疑われるとき、ログ上で最も目にするのが HTTP 429 と HTTP 503 です。多くのケースで Retry-After（何秒待って再試行すべきか）の情報が返り、バックアップ製品側は推奨待機時間に従ってリトライします。
| ログで見えるもの | 意味（ざっくり） | バックアップ現場での症状 | 基本方針 |
|---|---|---|---|
| HTTP 429 Too Many Requests | 短時間に要求が多すぎるため抑制 | 処理速度が急に落ちる／リトライが増える／進捗が“止まったように見える” | Retry-After を尊重し、並列数やジョブ分割で要求の山をならす |
| HTTP 503 Service Unavailable / Server Busy | サーバー混雑や一時的な制限 | 断続的に待機が入り、完了までの時間が読めなくなる | 同様に待機して再試行。頻発する場合は実行時間帯や対象の見直し |
ポイントは、429/503 が出たからといって「壊れた」「設定ミス」と断定しないことです。クラウドは“過負荷のサイン”をコードと待機時間で返し、クライアントはそれに従う前提で設計されています。逆に言えば、待機を無視して押し続けると、制限が強くなったり、完了がさらに遅れたりすることがあります。
スロットリングと“障害”を見分けるためのチェック
バックアップが遅いとき、「スロットリング」なのか「サービス障害・劣化」なのかで対応が変わります。判断の軸をシンプルにすると、次の 3 点が分かりやすいです。
| チェック観点 | スロットリング寄りのサイン | 障害・劣化寄りのサイン | まずやること |
|---|---|---|---|
| ステータスコード | 429 / 503 が散発し、待機して再試行で進む | 認証エラーや 5xx が継続、処理が進まない | Veeam ログでコードと頻度を確認 |
| 時間帯の偏り | 特定時間帯（利用ピーク）に集中しがち | 時間帯を問わず継続的に悪い | Service health と突合しつつ時間帯変更を試す |
| 影響範囲 | Veeam のバックアップ系処理で顕著（他の閲覧は平気） | ユーザーの通常利用（閲覧/編集）にも影響 | ユーザー影響の有無を現場に確認 |
「自分の上限（リミット）はどこで確認できる？」への現実的な答え
結論から言うと、SharePoint Online のスロットリングには「固定の公開上限値」が用意されていない（またはテナントごとに一定で表示される形では提供されない）ため、管理者が管理画面で「今の上限は毎分○回」といった値を正確に確認する方法は基本的にありません。
理由は、クラウド側がテナントの利用状況、リソースの混雑度、要求の種類（重い処理かどうか）、アプリの挙動などを見ながら、制限を動的に調整しているからです。いわゆる“速度制限”というより、サービス全体の健全性を守るためのリアルタイムな交通整理に近いものです。
| 知りたいこと | 管理画面でできる？ | 現実的な確認方法 | おすすめの記録 |
|---|---|---|---|
| いまのスロットリング上限（数値） | 基本的に不可 | ログの 429/503 と Retry-After の増減で推測 | 1時間ごとの 429/503 件数、待機秒数の合計 |
| どの操作が抑制されているか | 限定的 | Veeam の処理ステップ（オブジェクト種別）とエラー箇所を突合 | 対象サイト／ライブラリ／アイテム種別 |
| いつから・どの時間帯に多いか | 一部は可 | ジョブ開始・終了、処理速度の時系列で確認 | 実行時間帯、他ジョブ（Teams/OneDrive）との重なり |
つまり、「上限値を見に行く」のではなく「上限に当たっている兆候を観測する」発想が重要です。運用としては、スロットリングが少ない時間帯・設定値を探して“テナントに合うバックアップ設計”に寄せていくのが現実解になります。
Veeam 側でスロットリングを“確定”させる見方
Veeam サポートから「SharePoint の制限に当たっています」と言われたとき、まずは Veeam 側のログでHTTP 429/503 と待機（Retry-After 相当）が増えているかを確認します。Veeam 製品は一般に、制限を検知すると自動でリトライを行うため、ジョブ自体は Success / Warning で終わることもあります。
ログで拾うべき情報（サポートに渡すと強い）
| 項目 | 例 | なぜ重要か |
|---|---|---|
| 発生時刻（タイムゾーン含む） | 2025-01-15 23:10〜23:40（JST） | Microsoft 側のテレメトリ照会やサービス状況との突合に使える |
| 対象の範囲 | サイト URL、ライブラリ名、OneDrive か SharePoint か | “特定サイトだけ”か“広域”かの切り分け材料になる |
| HTTP ステータス | 429 / 503 | スロットリングの典型的シグナル |
| 推奨待機時間 | Retry-After: 120 秒 など | 抑制の強さを推測でき、設定調整の指標になる |
| リクエスト識別子 | Request ID / Correlation ID 相当 | Microsoft サポートがバックエンドで追跡する“鍵”になりやすい |
| 同時実行数・プロキシ構成 | プロキシ台数、同時タスク数 | 負荷の出し方（押し方）を説明できる |
ログの見え方（イメージ）
環境やバージョンで表記は異なりますが、概念としては次のような行が並びます。重要なのは、429/503 と“待ってから再試行する”流れが繰り返されているかです。
例：SharePoint Online からの応答により待機
- Request failed with HTTP 429 (Too Many Requests)
- Retry-After: 60 seconds
- Retrying operation...
- Request failed with HTTP 503 (Server Busy)
- Retry-After: 120 seconds
- Retrying operation...このような状態が短時間に多発しているなら、バックアップ処理そのものは正しくても、SharePoint 側の制限で速度が頭打ちになっています。体感としては「突然遅くなった」「進捗が増えない」と見えますが、実際は“待機と再試行のループ”で時間を消費しています。
Admin Center / Message Center で分かること・分からないこと
「Message Center に何か出ていますか？」は現場でよく聞かれます。整理すると、Message Center はMicrosoft 365 管理センター（Admin Center）内の機能で、サービスの重要通知、変更告知、広域障害などが提示されます。一方で、スロットリングは“設計上の挙動”として起きることが多く、個別テナントの上限値や瞬間的な抑制状況が Message Center に表示されるとは限りません。
| 確認先 | 見える情報 | スロットリング調査での使いどころ | 注意点 |
|---|---|---|---|
| Message Center | 重要通知、変更点、広域影響の告知 | 「SharePoint 全体が不安定」「仕様変更が入った」などのヒント確認 | 個別テナントの 429/503 を“上限値として”見せる場所ではない |
| サービス正常性（Service health） | インシデント、アドバイザリ、影響範囲 | 同時間帯に SharePoint Online の障害・劣化がないか確認 | “障害が無い＝スロットリングが無い”ではない |
| SharePoint 管理センター | サイト設定、ストレージ、管理ポリシー | 対象サイトの規模や設定（外部共有等）を俯瞰する | スロットリングの上限を直接表示する画面は期待しない |
管理センターは“全体の健康状態”を見るには有効ですが、スロットリングのようなテナント固有・ワークロード固有の抑制は、最終的にログ（Veeam 側／Microsoft 側）で突き合わせる必要があります。
影響範囲は「このユーザーだけ？このサイトだけ？」をどう考えるか
バックアップでスロットリングが出たときに悩ましいのが影響範囲です。結論として、スロットリングは一般に「特定ユーザー 1 人だけ」の問題として固定されるよりも、要求を出しているアプリ（Veeam 等）とテナント／ワークロード、そして操作の種類の組み合わせで発生しやすい傾向があります。
ただし、現場では次のように“限定されて見える”こともあります。
- 大規模サイトだけ極端に遅い：ライブラリ数やアイテム数が多く、メタデータ取得・差分確認が重い
- 特定時間帯だけ遅い：社内の利用ピーク（共同編集・検索・大量アップロード）と重なる
- 特定ジョブだけ遅い：同時に走っている別ジョブが SharePoint に負荷を寄せている
| 観測された症状 | 疑う範囲 | 切り分けの一手 | 次に打つ手 |
|---|---|---|---|
| 複数ジョブが同じ時間帯に一斉に遅い | テナント／アプリ単位の抑制 | ジョブ開始時間をずらし、重なりを解消して再実行 | 並列数・時間帯・ジョブ分割を設計し直す |
| 特定サイト（例：サイトA）だけ 429 が多い | リソース（サイト）特性、データ構造 | サイトAのみ単独で走らせ、他サイトと比較 | サイトAを別ジョブ化／小分け化／実行窓の分離 |
| 特定の処理ステップで止まりやすい | 操作種別依存の抑制 | ログで“どの処理ステップ”で遅いか確認 | 並列や対象の調整、ベンダー推奨構成の確認 |
ここで重要なのは、スロットリングが出た瞬間に「このユーザーだけが悪い」と切り捨てないことです。バックアップは“システムとしての負荷”なので、設計（並列・時間帯・分割）で改善できる余地が大きい領域です。
バックアップが遅くなりやすい典型パターン
同じテナントでも「遅い日」と「普通の日」がある場合、次のような条件が重なっていることがよくあります。該当が多いほど、スロットリングが発生しやすいイメージです。
| 典型パターン | 何が起きているか | 現場での対策例 |
|---|---|---|
| 初回バックアップ（初回フルに近い動き） | 差分が無く、参照・取得が大量になる | 初回だけジョブを分割／長めのウィンドウを確保 |
| 大規模ライブラリ（小さいファイルが大量） | “件数ベース”で API 呼び出しが増える | サイト単独ジョブ化、並列を下げる |
| 同時間帯に OneDrive や Teams もバックアップ | Microsoft 365 への要求が重なりやすい | ワークロード別に開始時刻をずらす |
| 日中の共同編集・検索が多い組織 | 通常利用の負荷が高く、バックアップが押される | 夜間・早朝に寄せる、週末に重い処理を回す |
Microsoft サポートで「上限解除・引き上げ」はできる？
「急ぎのバックアップ（または移行）があるので、スロットリングを解除してほしい」と考えるのは自然ですが、SharePoint Online のスロットリングはサービス保護の仕組みであるため、常に都合よく解除できるものではありません。
- まずはグローバル管理者権限でサポートチケットを起票し、同時間帯のサービス状況や、特定リソースでの抑制が異常に強くないかを調査依頼します。
- ただし結論が「仕様どおりの抑制」であれば、恒久的な解除ではなくクライアント側の調整（待機・並列・時間帯）が推奨されます。
- 調査を早く進めるためにも、前述の時刻・対象・Request ID 相当・ログを揃えて提示することが重要です。
実務で効く回避・緩和策（Veeam バックアップ運用のコツ）
スロットリング対策の基本はシンプルで、「要求の出し方を穏やかにして、待機を正しく守る」ことです。下記は現場で効果が出やすい順に整理した対策です。
並列数を下げて“長くても止まらない”設計にする
最も効くのは、バックアップの同時実行数（並列数）を下げることです。短時間で押し込んで終わらせたい気持ちは分かりますが、スロットリングが発生すると待機が挿入され、結果的にトータル時間が伸びます。まずは並列を落として、429/503 の頻度が減るかを確認してください。
ジョブを分割して“要求の山”をならす
対象サイトが多い場合、1 ジョブで全サイトを一気に回すと、最初の立ち上がりで要求が集中しがちです。サイト規模や重要度でジョブを分け、重いサイトは単独ジョブにするなど、負荷が偏らない形にすると安定します。
実行時間帯をオフピークへ寄せる
SharePoint Online は世界中で使われるため“絶対的なオフピーク”はありませんが、少なくとも自社の利用ピーク（朝〜夕方）を避けるだけでも改善することがあります。バックアップウィンドウに余裕があるなら、開始時刻を少しずらすだけでも効果が出る場合があります。
リトライ待機（Retry-After）を尊重する
バックアップ製品が自動リトライしてくれるとはいえ、運用上のトラブルは「待機を短縮したい」「失敗扱いにして即再実行したい」といった“人の操作”で悪化することがあります。Retry-After はクラウド側からの明確な指示なので、待機を前提にウィンドウを設計し、必要ならジョブ開始時刻や並列数で調整します。
チューニングの進め方：小さく変えて比較する
“いきなり大改造”をすると、何が効いたのか分からなくなります。おすすめは、1 回の変更幅を小さくし、ログと所要時間で比較する進め方です。
| ステップ | やること | 見る指標 | 判断 |
|---|---|---|---|
| ステップA | 現状のまま 2〜3 回実行し、基準値を作る | 総時間、429/503 件数、待機の有無 | 「普段はこれくらい」を決める |
| ステップB | 並列数を 1 段階下げる | 429/503 の減少と総時間の変化 | 総時間が短く/安定するなら継続 |
| ステップC | 重いサイトだけ別ジョブに分ける | 全体ジョブの安定化、重いサイトの完了可否 | “巻き込み遅延”が解消するか |
| ステップD | 開始時刻をずらす（30〜60分単位） | ピークとの競合が減るか | 時間帯依存が強いなら有効 |
| 対策 | 期待できる効果 | 副作用・注意点 | おすすめの使いどころ |
|---|---|---|---|
| 並列数を下げる | 429/503 が減り、待機が減ることで総時間が安定 | 単純に処理は遅くなる可能性がある（ただし“待機ループ”よりは速いことが多い） | まず最初に試す基本策 |
| ジョブ分割（サイト別/部門別） | 負荷集中を回避し、失敗時の影響を局所化 | ジョブ管理が増える | 大規模サイトが混在する環境 |
| 実行時間帯の変更 | 利用ピークとの競合を避け、抑制が弱まることがある | 夜間運用・監視が必要になる場合がある | 日中に共同編集・検索が多い組織 |
| 重いサイトを単独ジョブ化 | 全体が巻き込まれて遅くなるのを防ぐ | 完了タイミングが分散し、レポートが複雑になる | 巨大ライブラリ、頻繁な更新があるサイト |
「遅い」を定量化する：現場で役立つ観測項目
スロットリング対策は、感覚だけで調整すると迷子になりがちです。おすすめは、次のように“数字で比較”できる形にしてから、並列数や時間帯を調整することです。
- ジョブ総時間：開始〜終了まで（分/時間）
- 処理スループット：アイテム数/分、GB/時など（Veeam のレポート値で十分）
- 429/503 の発生回数：ログから抽出（最低でも日別・時間帯別）
- 待機時間の合計：Retry-After の総和（見えれば強い）
これを 1〜2 週間分だけでも集めると、「何曜日の何時が遅い」「並列を下げたら 429 が減って総時間が短くなった」といった、再現性のある改善につながります。
サポート問い合わせ用：チェックリスト（そのまま転記できる形）
Veeam サポート／Microsoft サポートに調査を依頼するとき、情報が揃っているほど解決が早くなります。以下はテンプレとして使える項目です。
| カテゴリ | 記載する内容 | 例 |
|---|---|---|
| 環境情報 | Veeam 製品名とバージョン、構成（プロキシ、リポジトリ） | Veeam Backup for Microsoft 365 vX.X / Proxy 2 台 |
| 対象 | SharePoint サイト URL、対象の範囲（全体/特定サイト） | <tenant>.sharepoint.com/sites/<site> など |
| 発生状況 | 発生日、発生時間帯、頻度（毎回/時々） | 毎晩 23:00 開始のジョブで頻発 |
| ログ抜粋 | 429/503、推奨待機時間、Request ID 相当 | HTTP 429, Retry-After 60s |
| 切り分け結果 | 並列数変更・時間帯変更・ジョブ分割の試行結果 | 並列を半分にしたら 429 が減少 |
よくある質問（FAQ）
429/503 が出てもバックアップは壊れていませんか？
多くの場合、壊れているのではなく抑制されて待機している状態です。Veeam が Retry-After を守って再試行していれば、時間はかかっても完了することがあります。ただし、同じ箇所で長時間進まない／常に失敗する場合は、障害・権限・ネットワーク要因も含めて切り分けが必要です。
「特定サイトだけ遅い」はスロットリング以外の可能性もありますか？
あります。例えば、アイテム数が極端に多い、特殊な権限継承が多い、更新が激しいなどで処理コストが上がり、結果として 429 を引きやすくなるケースがあります。まずはそのサイトを単独ジョブで回し、他サイトと比較すると判断しやすくなります。
並列数は下げれば下げるほど良いですか？
下げすぎると単純に遅くなるため、429/503 の頻度と総時間のバランスで決めるのが現実的です。「並列を下げたのに総時間が短くなった」なら、スロットリング由来の待機が減った可能性が高いサインです。
よくある誤解と落とし穴
- 「429/503 が出た＝障害」：広域障害の場合もありますが、バックアップのような高負荷処理では仕様として出ることも多いです。まずは Service health とログの両方で判断します。
- 「速くしたいから並列数を上げる」：短期的には速く見えても、スロットリングが入ると待機が増え、総時間が伸びることがあります。
- 「失敗したからすぐ手動で再実行」：Retry-After を無視して再実行を繰り返すと、抑制が強まる・回復が遅れるリスクがあります。
- 「特定ユーザーだけが悪い」：多くの場合はアプリとテナントの負荷設計の問題です。犯人探しより“押し方の最適化”が近道です。
まとめ
SharePoint Online のスロットリングは、サービスの安定性を守るために設計された仕組みであり、Veeam Backup for Microsoft 365 のように大量アクセスを行う処理では避けて通れないことがあります。重要なのは、管理画面で「上限値」を探すよりも、ログで 429/503 と待機時間を観測し、並列・ジョブ分割・時間帯で負荷をならしていくことです。
スロットリングを“敵”ではなく“信号”として扱い、待機を守って確実に進める運用に寄せると、結果的にバックアップは安定し、復旧の信頼性も高まります。まずは今日のログから 429/503 の頻度を把握し、最小の変更（並列数の調整）から試してみてください。
コメント