OpenClawの429レート制限を直す：待つ条件・止める条件と作業の再開手順

OpenClawで429やRate limit exceededが出たら、まず同じ依頼の再送を止め、どのサービスが要求を拒否したかを確認します。モデル提供元の一時的なレート制限なら、応答にある待機時間を守って既存の回復処理を待ちます。日次・週次の利用枠、支出上限、長いコンテキストを使う資格の問題なら、短く待つだけでは解消しません。スキルの検索・取得で出た429はClawHub側の制限として調べます。

回答が途中で止まっても、直前のファイル編集や外部への操作が完了していることがあります。再開するときは、成果物と実行記録を確認し、未完了の部分だけを続けてください。この記事は2026年10月4〜5日に確認した公式資料に基づく対処手順です。実機での復旧試験や、有料モデルへの呼び出しは行っていません。

最初に、429が出た場所を見分ける

エラーの数字だけで、APIキーの交換やGatewayの再起動へ進まないでください。失敗した処理、返答したサービス、エラー本文を対応付けると、次の操作を選べます。

最後の行は重要です。fallback先で別のエラーになった場合、最初の429だけを直そうとしても再開できません。401なら認証経路を切り分ける手順、入力容量の超過ならコンテキスト超過と圧縮失敗の対処へ進みます。

追加要求を止め、完了した操作を残す

同じ依頼を何度も送る、複数の会話から同時に試す、短い間隔のcronを動かし続ける、といった操作は新たな要求を生みます。現在の実行が回復待ちなら、追加のメッセージで復旧を急がせず、まず要求を出している箇所を減らしてください。

2026年2月のHiroaki氏によるOpenClawの運用メモでも、429の繰り返しと、キー・モデルの切り替え、cronや新しいメッセージが重なる状況が報告されています。これは個人の当時の経験であり、現在の再試行回数や状態の保存方式は、以下の現行資料で確認します。

1. 新しい要求の発生を抑えます。 自分が管理する定期実行や並列ジョブのうち、同じ提供元へ要求を出すものを一時停止・延期します。すでに待機中の実行へ、同じ依頼を重ねて送らないでください。
2. 既存の実行を待つか、止めるか決めます。 一時的な制限で待機時間が分かり、期限内に収まるなら待ちます。期限を超える、利用枠の回復条件が未解決、外部操作の結果が不明な場合は、追加処理を止めて確認へ移ります。キャンセルすると、その実行の回復処理も停止します。
3. 成果物と実行履歴を確認します。 完了した編集、取得済みファイル、送信済みの処理、最後のツール結果を短いメモへ残します。モデルが応答できない状態なら、人が画面やファイルを確認して保存します。
4. 不明な操作を先に照合します。 送信・公開・購入などが成功したか不明なときは、送信先や履歴で確かめます。同じ操作を最初から再実行しないでください。

現在のOpenClawの一時的な失敗からの回復は、元の依頼を丸ごと再送するのではなく、既存の会話記録を引き継ぎます。完了した作業を保ち、中断した操作を調べてから繰り返すか判断するよう指示します。ただし、承認待ち、キャンセル、実行期限は続行を止めます。公式の再試行仕様

ログで、提供元・モデル・待機情報を揃える

Gatewayが動くマシンで、対象の環境を選んで状態と失敗時刻のログを確認します。以下は利用者が実行するための公式コマンド例で、この記事で実行した結果ではありません。

openclaw --version
openclaw models status --agent <agentId>
openclaw logs --limit 200 --max-bytes 250000 --plain

<agentId>を失敗したagentのIDへ置き換えます。名前付きのOpenClawプロファイルを使っているなら、例えばopenclaw --profile work logs --limit 200 --plainのように、実際のプロファイルを指定します。ログは選択したGatewayからRPC経由で取得され、日ごと・プロファイルごとのファイルが使われます。古い記事にある固定のログパスを、すべての環境に当てはめないでください。logs CLI

問題が起きた会話では、別途次を入力します。

/model status
/status

CLIのmodels statusはagentの既定モデル、fallback、認証情報、利用できないプロファイルなどを示します。その会話だけのモデル固定は、会話内で確認します。--checkが成功しても、提供元への要求が成功する証明ではありません。--probeは実要求を出し、トークン消費やレート制限を伴うため、429の最中に状態表示のつもりで繰り返さないでください。models CLIの表示とprobeの範囲

確認する記録は次の組です。

• 失敗時刻、agent、会話またはジョブ。
• 選択中のモデルと、実際に試されたprovider/model。
• 選ばれた認証プロファイルのID。キーやトークンの値は残しません。
• HTTPステータス、エラー本文、Retry-Afterやリセット情報。
• 再試行回数、クールダウンの理由・解除時刻、fallback先とその結果。

ログの追跡が切れた場合は、モデル要求の429と分けて考えます。logs --followにも再接続処理がありますが、これはモデルの再試行回数ではありません。ログ元の切り替えで同じ行が重なる場合もあるため、重複表示をすべて別の要求として数えないでください。ログ追跡の再接続と出力元

一時的なレート制限なら、指定時間を守って待つ

図は待機と別経路の判断を示すイメージです。実際の画面や復旧試験の結果ではありません。

一時的な429であれば、OpenClawは同じモデルで回数を限定した回復を試します。現行の公式資料では、レート制限は合計で最大10回の試行です。待機はランダムなばらつきを加えた指数バックオフを使い、提供元のretry-after、retry-after-msや「何秒後に再試行」といった情報を最低待機時間として扱います。モデル要求の再試行

通常のバックオフにある30秒の上限は、「提供元が90秒待つよう求めても30秒で再送する」という意味ではありません。また、他の一時的な失敗に適用される90秒の連続障害ウィンドウを、429全般の解除時間と読むこともできません。途中でツールが動いたことや部分的な文章が出たことだけでは、回復処理の障害ウィンドウはリセットされません。

提供元が長い待機を求める場合、OpenClawの保存済み設定retry.provider.maxRetryDelayMsは、fallbackが設定されているときの待ち方に影響します。既定値は60秒です。提供元の最低待機時間がその上限を超えれば、利用可能なfallbackへ進みます。fallbackがなければ最低待機時間を全て守り、maxRetryDelayMs: 0はこの上限を無効にします。60秒が経過したから利用枠が回復する、という設定ではありません。長い待機とfallbackの条件

さらにOpenClaw内で使う一部SDKには、内部待機が長くなりすぎないよう制御を返す別の仕組みがあります。同じ60秒という数字でも、SDK内の待機上限と、モデル復旧を管理する上限は別です。独自の外側ループを重ねる前に、OpenClawと実行方式がすでに行う再試行を把握してください。

OpenAI APIでは、失敗した要求も分単位の制限に数えられます。RPM、TPMなどは別々の制限で、要求数が少なくても長い入力でトークン側に達することがあります。slow_downによる429は、名目上のRPM・TPM以内でも急な負荷増加で起こり得ます。まず並列要求と入力・出力の量を減らし、回復後に徐々に増やします。OpenAIのレート制限と再試行

待つだけでは直らない429を切り分ける

日次・週次・月次の枠や支出上限に達した場合は、短時間の負荷超過とは対応が変わります。エラー本文や利用状況から、何を待つのか、何を変更する必要があるのかを確認してください。Retry-Afterがあるという理由だけで、期間全体の利用枠を使い切ったとは断定できません。

OpenAIのレート制限は組織・プロジェクト単位で、一部モデルには共有の制限枠があります。同じ組織のキーを増やすことや、共有枠の別モデルへ切り替えることが、新しい容量を作るとは限りません。通知だけの支出アラートと、要求を429で拒否するhard spend limitも区別します。OpenAIの利用枠と支出制御

Claude APIの429も、レート制限のほか、利用tierの月次支出上限やClaude Codeワークスペースの支出上限を含みます。tierの支出上限による429はretry-afterがなく、利用が再開できるまで失敗が続きます。「すべての429は1〜2分待てば直る」とは扱えません。Claude APIの429の意味

長い要求だけでExtra usageのエラーが出る場合

Extra usage is required for long context requestsという本文を伴う429なら、まず長いコンテキストを使う経路と、選択された認証情報の資格を確認します。通常のコンテキストで動くモデルへ切り替える、対象の長い要求を使える認証情報を選ぶ、利用可能なfallbackを使う、という選択肢があります。課金を伴うExtra usageを自動で有効にする必要はありません。OpenClawの該当エラーの案内

古い非GAモデルのcontext1m設定を外す案内は、その古い経路に対するものです。現在のGAモデルも含めて一律に削除したり、どのAPIキーでも長い要求を使えると考えたりしないでください。履歴自体が容量を超えたエラーなら、資格の問題と分けて入力予算と圧縮を調べます。

全プロファイルがクールダウン中でも、再起動で解除しない

OpenClawは失敗した認証プロファイルにクールダウンを記録します。通常の一時的な失敗では、最近の失敗回数に応じて30秒、1分、最大5分へ伸びます。状態はagentごとのSQLiteにあるusageStatsへ保存され、cooldownUntilなどの期限を持ちます。Gatewayを再起動しても、保存済みのクールダウンや提供元の利用枠が消えるわけではありません。クールダウンの現在の保存仕様

all profiles in cooldownが出たら、最後の429本文とUnavailable auth profilesを合わせて、次を確認します。

1. 最も早い解除時刻が分かるなら、その時刻と提供元の最低待機時間を守ります。追加要求を抑えたまま待ってください。
2. 制限がモデル単位なら、同じ提供元の別モデルが候補になることがあります。ただし、提供元で共有枠がある場合は、別モデルでも同じ制限を受けます。
3. billingなどの無効化は認証情報全体を対象にするため、同じプロファイルでモデルだけを変えても解消しません。現在の仕様では初回10分の無効化が記録され、課金条件を解決しても保存済み期限が自動で消えるわけではありません。
4. 認証の永続的な失敗なら、待機だけでなく認証を修正します。具体的な401や失効の記録がある場合は、認証エラーの対処へ進みます。

現在のOpenClawは、すべてのプロファイルが待機中でも、その提供元を永遠に除外するわけではありません。primaryの期限が近い場合の限定した確認や、モデル単位の制限に対する同じ提供元の候補を扱えます。これは手動で大量のprobeを繰り返す理由にはなりません。クールダウン中の候補選択

古いauth-profiles.jsonや状態データベースを削除して、失敗履歴だけを消す復旧は避けてください。まず実際の期限、理由、利用できる経路を確認します。プロセス内だけに保持される一部の認証失敗キャッシュが再起動で消えることと、永続クールダウンの解除は別です。

fallbackが動かないときは、会話のモデル固定を見る

fallbackが設定されていても、今の会話で必ず使われるとは限りません。既定モデル、fallbackを明示したagentのprimary、cronのprimaryなどは、対応する候補へ進めます。一方、会話で具体的なモデルを明示選択した場合、その選択は厳密に扱われ、失敗しても無関係な別モデルへ黙って移りません。選択元ごとのfallback方針

まず同じ会話の/model statusと、agentのmodels statusを照合します。既定のfallbackを使いたい場合は、会話で次を入力し、モデル固定を解除します。

/model default
/model status

個別agentに独自のprimaryがあるなら、そのagentに明示されたfallbackも確認します。空のfallback指定は無効化の意思表示です。別モデルの接続がまだできていない場合は、LLM接続とfallbackの設定手順で一つの経路を完成させてから使います。未検証のモデル名を候補へ大量に追加する必要はありません。

fallbackが成功しても、そのターンで回答したモデルと、次のターンの選択モデルは区別します。現在の復旧は、fallback先を会話の恒久的な選択へ書き換えません。/statusで選択モデルと実際に応答したモデルを見て、次のターンにも同じ制限が残るかを確認してください。fallbackの状態表示

ClawHubの検索・取得で出た429は、別の制限として待つ

図は取得処理の切り分けを示しています。実際のインストール結果ではありません。

スキルやプラグインのインストール中にRate limit exceededが出た場合、モデルのAPIキーを増やしてもClawHubの取得枠は増えません。現在のClawHubは、読み取り・書き込み・ダウンロードに別々の制限を持ちます。匿名要求はIP単位、有効なBearer認証の要求はユーザー単位で扱われ、トークンがない・無効な場合はIP側の制限へ戻ります。共有の外向きIPなら、自分の要求が少なくても制限に達することがあります。ClawHub HTTP APIの制限

同時インストールや一括更新を止め、失敗した一つのパッケージと取得済みの状態を残します。応答に待機情報が出ていれば、次のように読みます。

Retry-Afterがなければ、RateLimit-Reset、またはX-RateLimit-Resetと現在時刻の差を使います。これはClawHubの仕様です。OpenAIのx-ratelimit-reset-tokensなどにある6m0sのような期間表記へ、Unix時刻の読み方を持ち込まないでください。ClawHubのヘッダー仕様、OpenAIのヘッダー仕様

公式案内は、可能ならサインインし、表示された時間を待って再試行するよう勧めています。ただし、別のclawhub CLIでwhoamiが成功しても、OpenClaw標準の取得処理が同じトークンを使った証明にはなりません。モデルのログイン、ClawHub CLIのログイン、実際に失敗した取得経路を分けて確認します。ClawHubの429対処、OpenClawのコマンドとClawHub CLIの役割

待機後は、失敗した一つの取得だけを再試行し、目的のバージョンが実際にインストールされたか確認します。すでに成功した取得を一括で繰り返したり、ローカルで編集したスキルを強制更新で上書きしたりしないでください。同じ429が続く場合は、待機情報と認証の適用状況を見直し、取得を止めて時間を置きます。

残りの作業を一つだけ再開して、復旧を確認する

待機時間が過ぎた、利用条件を解決した、または利用可能な別経路を選べたら、並列ジョブをまとめて戻す前に一つの作業だけ再開します。現在の実行がまだ自動回復中なら、その終了を確認してから次の依頼を送ります。

例えば、完了したファイル編集を保って確認だけ続けるなら、次のように依頼できます。これは再開用の記入例です。

report.mdの表の更新は完了しており、ファイルで確認済みです。
最初から更新し直さず、表と本文の数値を照合する作業だけを続けてください。
最後の検証結果は不明なので、記録を確認してから必要な検証を行ってください。
公開・外部送信は行わないでください。

成功条件は、状態表示が正常なことだけではありません。一つのモデル応答または必要な作業が完了し、使われた提供元・モデルを確認でき、完了済みの操作が重複していないことを確かめます。ClawHubなら、目的のパッケージ取得が完了し、対象のバージョンを確認できることが基準です。

同じ429が再び出たら、要求を止めて新しい応答の理由とリセット情報を確認します。401、入力容量超過、利用資格の不足へ変わった場合は、その問題を直します。解除時刻も理由も分からない場合は、バージョン、実行方式、失敗したモデル・プロファイルID、秘密情報を除いたエラー、試した変更をまとめて問い合わせてください。キーや非公開の会話全文を貼る必要はありません。

よくある質問

Gatewayを再起動すれば429やクールダウンは消えますか？

提供元の利用枠と、SQLiteに保存されたクールダウンは消えません。再起動が必要なのは、設定変更の反映など別の理由がある場合です。一部のプロセス内キャッシュが消えることを、429の一般的な解除方法と考えないでください。クールダウンと保存状態

APIキーを増やせば、OpenClawのレート制限を回避できますか？

同じ枠を共有するキーでは、容量が増えるとは限りません。OpenAI APIは組織・プロジェクト単位の制限と共有モデル枠を持ちます。利用可能な別経路を使う場合も、認証、枠、モデルの能力、費用を確認します。OpenAIの制限単位

再試行を止める設定をopenclaw.jsonへ書けばよいですか？

公式のretry.provider.maxRetriesは組み込み実行方式のセッション設定で、openclaw.jsonのキーではありません。0はその回復の再試行を無効にしますが、ネイティブ実行方式内部の要求再試行を変更するものではありません。無効な設定を貼る前に、今の実行方式と適用先を確認してください。設定の適用範囲

429が出たら、新しい会話に移れば直りますか？

新しい会話は提供元の共有利用枠をリセットしません。入力を短くすることでトークン側の負荷を減らせる場合はありますが、先に完了した操作と未処理の依頼を残します。容量の超過も確認できた場合は、作業を保って会話を引き継ぐ手順を使ってください。