【第5の闇】待機時間の謎 : 15分・2時間・72時間…エラーの自然回復に差が出る理由

これは「スロットリング」と呼ばれる仕組みで、
短時間に大量の要求が飛んできた時、サービスを一時的に制限して、
過負荷を防いでいるんだよ。

だから、「再試行」を連打すると、
早く直すどころか、余計な制限を踏みに行く可能性すらある。

そして「15分」という数字だが、
Windows のアカウントロックアウト設定で、
Microsoft 側は、15分程度の短い値を推奨例として挙げている。

つまり、
認証を失敗し続けた後は、15分程度いったん待つ
という考え方自体が、Microsoft の設計思想にあるんだよ。

軽い認証エラーやクルクル状態なら、まず15分は触らず様子を見る

という判断はひとまず合理的だな。

2時間は、OneDrive だけじゃないぞ。

今度は企業向けの認証世界、
Microsoft Entra界にも「2時間」の認証時計があるんだ。

Microsoftの認証では、
アプリがサービスへアクセスする際に「アクセストークン」という認証情報を使っている。

このアクセストークンの既定寿命は通常、

60〜90分、平均75分。

条件付きアクセスを使っていない環境では、
Teams や Microsoft 365など一部のクライアントについて、
既定のアクセストークン寿命が「2時間」と Microsoft が明記している。

つまり、60〜90分や2時間という認証情報の寿命が実際に存在する。
ただ、PRTというSSO（シングルサインオン）を支える延長トークンの仕組みがあるから、2時間ごとに毎回パスワードを入れ直す必要はないけどな。

その通り。
認証時計が一度回るところまでは見てみようということだね。

ただし、企業環境には「4時間」という時計も動いているぞ。
さっき話していた PRT も、4時間ごとに更新を試みると明記されている。

そう、ここからは、PCの中だけじゃなくて、
クラウド側の処理待ちだな。

Microsoft公式を調べると、
24時間という数字も、かなりよく見かける。

OneDriveでは、ファイル共有の上限に達した場合、共有制限は24時間後にリセットされると明記しているし、
Microsoft アカウントの本人確認や、大量共有に伴う一時的ブロックも、24時間以内に解除されるケースがある。

つまり、クラウド側の同期・反映待ちとして、一つの目安となる時間だな。

この72時間も、祈りをささげる謎数字じゃないぞ。

Microsoft Store でゲームの払い戻しを申請した場合、
Microsoft公式は、払い戻し要求の処理に
最大72時間かかる場合があると案内している。

つまり「申請した」→「利用者側の操作は終了」
でも「Microsoft側では処理継続中」
という状態が、クラウド側だけで3日続くことがあるという実例だ。

Microsoft自身が、クラウド側の処理時間として72時間を公式に使っている
ことは確認できる。
ただし、その中に人間の確認が入るか、自動処理だけかは公開されていない。

ただ、どちらか分からない以上、ユーザー側が「十分待った」と判断するための最終ラインと考えていいだろう。