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

> 429が続くときは、依頼の再送や定期実行を増やさず、失敗した提供元・モデルと待機時間を確認してください。一時的な制限なら指定時間を待ち、利用枠や資格の問題なら条件を直すか利用可能な別経路へ進みます。再開前には完了した操作を確認し、残りの作業だけを続けます。

- URL: https://blog.laozhang.ai/ja/posts/openclaw-rate-limit-exceeded-429
- Published: 2026-10-05
- Updated: 2026-10-05
- Author: LaoZhang AI Team (https://blog.laozhang.ai/ja/about)
- Category: AIトラブルシューティング
- Tags: OpenClaw, 429エラー, レート制限, ClawHub, モデル設定

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

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

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

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

| 失敗した処理・表示 | 確認する対象 | 最初にすること |
| --- | --- | --- |
| チャットやagentのモデル要求でHTTP 429 | 実際に要求を受けた提供元とモデル | `Retry-After`、エラー本文、利用枠のリセット情報を確認する |
| `all profiles in cooldown`など、認証プロファイルがすべて待機中 | 対象agentのプロファイル状態と最後の失敗理由 | 最も早い解除時刻、モデル単位の制限か認証情報全体の無効化かを確認する |
| スキル検索・インストール・更新中の`Rate limit exceeded` | ClawHubの応答 | モデルの制限とは分け、取得要求を止めてレジストリの待機情報を読む |
| 長い要求だけで`Extra usage is required for long context requests` | 選んだモデル経路と認証情報の利用資格 | 通常のコンテキストで使う経路、資格のある認証情報、利用可能なfallbackを検討する |
| 429の後に401や`context length exceeded`へ変わった | 次に失敗した要求 | 認証または入力容量の対処へ切り替える |

最後の行は重要です。fallback先で別のエラーになった場合、最初の429だけを直そうとしても再開できません。401なら[認証経路を切り分ける手順](https://blog.laozhang.ai/ja/posts/openclaw-401-authentication-error)、入力容量の超過なら[コンテキスト超過と圧縮失敗の対処](https://blog.laozhang.ai/ja/posts/openclaw-context-length-exceeded)へ進みます。

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

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

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

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

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

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

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

```bash
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](https://docs.openclaw.ai/cli/logs)

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

```text
/model status
/status
```

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

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

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

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

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

![一時的な429は指定時間を待ち、利用枠や資格の問題は使える別経路を確認して、残りの作業だけ再開する説明図](https://blog.laozhang.ai/posts/ja/openclaw-rate-limit-exceeded-429/img/wait-or-fallback.webp)

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

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

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

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

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

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

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

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

| 確認できた制限 | 再開に必要な条件 |
| --- | --- |
| 一時的な要求数・トークン数の制限 | 指定された最低待機時間を守り、要求の量や並列数を減らす |
| 日次・週次・月次などの利用枠の消費 | 正確なリセットを待つか、別の利用可能な認証情報・モデル経路を使う |
| 支出上限や残高不足 | 対応する課金・利用条件を解決する。課金変更は費用と権限を確認して行う |
| 長いコンテキストの利用資格がない | 通常のコンテキストで使う経路、資格のある認証情報、適格なfallbackを選ぶ |

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

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

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

`Extra usage is required for long context requests`という本文を伴う429なら、まず長いコンテキストを使う経路と、選択された認証情報の資格を確認します。通常のコンテキストで動くモデルへ切り替える、対象の長い要求を使える認証情報を選ぶ、利用可能なfallbackを使う、という選択肢があります。課金を伴うExtra usageを自動で有効にする必要はありません。[OpenClawの該当エラーの案内](https://docs.openclaw.ai/es/gateway/troubleshooting#anthropic-429%3A-se-requiere-uso-adicional-para-contextos-largos)

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

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

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

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

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

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

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

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

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

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

```text
/model default
/model status
```

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

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

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

![モデルの推論要求とClawHubの検索・取得を分け、取得側の待機情報を読んで失敗した一つだけを再試行する説明図](https://blog.laozhang.ai/posts/ja/openclaw-rate-limit-exceeded-429/img/clawhub-recovery.webp)

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

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

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

| ClawHubのヘッダー | 意味と読み方 |
| --- | --- |
| `Retry-After` | 再試行まで待つ秒数。最短の待機時間として守る |
| `RateLimit-Reset` | リセットまでの秒数 |
| `X-RateLimit-Reset` | リセットする絶対時刻をUnix秒で示す |
| `RateLimit-Remaining` | 表示される場合は正確な残り枠。429では0 |

`Retry-After`がなければ、`RateLimit-Reset`、または`X-RateLimit-Reset`と現在時刻の差を使います。これはClawHubの仕様です。OpenAIの`x-ratelimit-reset-tokens`などにある`6m0s`のような期間表記へ、Unix時刻の読み方を持ち込まないでください。[ClawHubのヘッダー仕様](https://docs.openclaw.ai/clawhub/http-api)、[OpenAIのヘッダー仕様](https://developers.openai.com/api/docs/guides/rate-limits)

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

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

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

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

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

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

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

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

## よくある質問

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

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

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

同じ枠を共有するキーでは、容量が増えるとは限りません。OpenAI APIは組織・プロジェクト単位の制限と共有モデル枠を持ちます。利用可能な別経路を使う場合も、認証、枠、モデルの能力、費用を確認します。[OpenAIの制限単位](https://developers.openai.com/api/docs/guides/rate-limits)

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

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

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

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