Claude Code 2.1.292の529リトライを安全に調整する

結論：backoff変更と再実行の承認を分ける

529はサービス側の混雑を示すことがありますが、ログイン失敗、permission、proxy、入力過大、MCP停止とは別です。待ち時間を伸ばすだけで原因を隠すと、利用者は同じjobを再送し、外部更新や請求を二重に実行する恐れがあります。既存の出力上限の確認はtool結果のサイズが主題で、本稿はHTTP 529時の待機と副作用の判断に絞ります。

529・timeout・認証失敗を比較する

兆候	優先して見る場所	暫定対応
529 overloaded	status、retry、発生時刻、provider	backoff後に限定的に再試行
timeout	処理時間、context、tool、network	job分割とtimeoutを見直す
401・403	認証、scope、組織policy	再試行せず権限を確認
同じ外部処理が不明	job ID、受付番号、監査log	停止して人間が状態確認

「retryable」という言葉を全処理へ適用しないことがポイントです。読み取り、要約、テストのように同じ入力で再実行できる処理と、公開、削除、決済、権限変更のように副作用がある処理をジョブ台帳で分離します。

8手順で遅延と停止条件を決める

1. まずclaude --version、実行面、provider、発生時刻、HTTP statusを保存します。
2. 529以外の401、403、400、network errorを同じ事象として数えず、原因欄を分けます。
3. 処理をread-only、再実行可能なbuild、外部副作用のあるjobに分類します。
4. read-onlyの検証jobだけでCLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MSを設定し、値、設定scope、effective configurationを記録します。
5. retry回数と全体timeoutを別に決め、backoff中に利用者が同じjobを手動再送しない表示を用意します。
6. 各jobへ入力hash、job ID、外部受付番号、開始・終了時刻を付け、再接続後に実行済みか確認できるようにします。
7. 529が続く、費用上限に近い、結果が不明、副作用がある場合は自動retryを止めます。
8. 復旧後は成功率だけでなく、重複実行、待ち時間、失敗分類、追加費用を確認して基準を更新します。

環境変数を入れる場所と確認方法

設定を変更する前に、現在の失敗率と待ち時間を基準値として保存します。変更後に成功率だけが上がっても、queue滞留、利用者の再送、CIの同時実行数が増えていれば安全な復旧とは言えません。読み取りjob、テストjob、外部更新jobを別のメトリクスにして、どの処理の遅延が伸びたかを追えるようにします。

一時的な検証ならコマンド実行時だけ環境変数を与え、共有設定へいきなり書きません。チーム運用なら、ユーザー、project、managed settings、CI secretのどこで値を管理するかを決めます。公式settings docsの通りmanaged settingsやcommand lineなどの優先順位があるため、「設定ファイルに書いた」だけでは実効値を説明できません。

CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS=3000 claude -p "read-only test"

上の数値は導入例であり、公式の推奨値や成功保証ではありません。実際にはサービスの状態、許容待ち時間、jobのtimeout、provider契約を基準に段階的に測ります。環境変数を設定しても、permissionや認証エラーを529として扱ったり、外部jobを無制限に繰り返したりしてはいけません。

利用状況を組織で管理する場合はコスト管理やGatewayのネットワーク境界と接続します。待機時間の増加が席・gateway・CIの滞留を増やしていないか、個別jobだけでなく全体で見ます。

運用開始前チェックリスト

復旧テストでは、意図的に短い過負荷ケースを作るだけに留め、本番の外部システムへ同じ更新を繰り返しません。再試行の各回に同じjob IDを付け、受付番号が一つか複数かを確認します。自動処理を再開する担当者は、状態が未実行・実行済み・不明のどれかを明示し、不明のまま再送しないことを承認条件にします。

障害の連絡文にも「ただいま再試行中」とだけ書かず、status、開始時刻、次に確認する時刻、手動再送を禁止する範囲を明記します。利用者が別の端末で同じsessionを再開する場合は、job IDと外部システムの受付番号を照合します。結果が不明な操作を成功扱いにしないことが、遅延調整より重要です。

• 529と401・403・timeoutを別分類した
• 2.1.292以上、provider、実行面を記録した
• 環境変数のscopeとeffective値をreadbackした
• retry回数、base delay、全体timeoutを別に決めた
• read-onlyと副作用jobを分離した
• job ID、入力hash、受付番号を残した
• 結果不明・費用超過・連続529の停止条件がある

障害時の目標は、待ち続けることではなく、二重実行を避けながら復旧可能な証跡を残すことです。無料のAI導入・運用の無料診断（60秒）では、retry表と停止承認の責任分界を整理できます。

復旧後に残す監査項目

復旧報告には、最初の529、各retryの時刻、設定したbase delay、最終結果、手動操作の有無を残します。成功したケースだけでなく、停止したケースも保存すると、次回の閾値を決めやすくなります。サービス側の混雑が解消した後に設定を戻す条件も、変更時点で決めておきます。長いbackoffを恒久設定にすると、通常時の障害発見まで遅れるためです。

同じエラーが特定のproviderやネットワークだけで起きるなら、全利用者へ遅延を適用する前に経路を分けて比較します。Gateway、proxy、CI runnerの待ち行列を個別に見て、Claude Codeの設定変更で解決すべき問題か、基盤側で解決すべき問題かを判断します。

復旧判断の責任者

自動retryを止める責任者と、再開を承認する責任者を同じにするか分けるかも決めます。障害中に設定値を変更した人が、そのまま結果を成功と判定しないよう、ログと外部受付を別担当が確認できる形にします。

変更を戻す条件

base delayを戻す条件は、529の発生率、平均待ち時間、queueの滞留、手動再送の件数から決めます。混雑が収まった後も長い遅延を残すと、別のtimeoutや利用者の再送を誘発します。設定変更の前後を同じ期間で比較し、戻す作業にも承認者を置きます。

FAQ

529が出たら待てば必ず成功しますか？

いいえ。過負荷の一時障害と、認証・権限・入力・networkの障害を分けます。

待ち時間を長くすればリトライ回数も増えますか？

環境変数は過負荷時のbackoff基準遅延です。回数、timeout、jobの副作用は別に設計します。

リトライ設計を相談できますか？

できます。再実行可能性、job ID、停止条件、費用上限を無料診断（60秒）で整理します。