「⚠️ Rate limited — switching to fallback provider」が繰り返される本当の理由と解決法

これは「フォールバックのバグ」ではなく、プライマリモデルが現在レート制限（rate limit）を受けているため、Hermesが設計通りにフォールバック先の

sg-claude-opus-4.7 via custom

警告メッセージの意味

• Hermesは、レート制限、サーバーエラー、認証エラー、404エラー、応答の破損や繰り返しエラーなどが発生した場合に、自動的にフォールバックを実行します。
• フォールバック後も会話のコンテキスト（文脈）は保持され、予備のモデルで会話を継続できます。
• ただし、このフォールバックはそのターン限りで有効です。次のターンでは再びプライマリモデルを試行し、失敗すれば再度フォールバックするという動作を繰り返します。

なぜ延々と繰り返されるのか

• 直接的な原因：上流（アップストリーム）のプライマリモデルが依然としてレート制限状態にあるため、新しいターンごとに接続失敗→フォールバックの流れが発生します。
• 実際のエラーが

  HTTP 429

  （Too Many Requests）である場合、OpenClawのドキュメントではこれをゲートウェイレベルで調査・トラブルシューティングすべきレート制限/アップストリーム制限のエラーグループに分類しています。
• 特に、プロンプトやコンテキストが非常に長い「ロングコンテキストリクエスト」の場合、429エラーが発生しやすくなることも指摘されています。

特に注意すべきポイント

• sg-claude-opus-4.7 via custom

  という表示は、フォールバックがHermes内で事前設定されたカスタムエンドポイント/プロバイダーを経由していることを示しており、完全に別のネイティブプロバイダーに切り替わっているわけではありません。
• もしプライマリとフォールバックが同じアップストリームやAPIキープールを共有している場合、プロバイダーが切り替わったように見えても実質的に同じ制限の影響を受け続けることになります。この2つの経路が同一プールを使っているかどうかは、実際の設定ファイル（config.yaml）を確認する必要があります。
• Hermesのドキュメントによれば、カスタムエンドポイントは config.yaml に保存され、フォールバックチェーンも同じ config.yaml 内の fallback_providers セクションで管理されています。

まず確認すべきこと

1. 現在のプライマリモデルとフォールバックチェーンの設定を config.yaml で確認する。
2. プライマリと

   sg-claude-opus-4.7 via custom

   が、同一のゲートウェイ、APIキープール、またはバックエンドを共有していないか検証する。
3. OpenClawゲートウェイやカスタムゲートウェイを経由している場合は、プローブ（

   openclaw gateway probe

   ）やステータス確認（

   openclaw status --all

   ）を実行し、実際のエラーが429なのか、認証エラーなのか、あるいは古いクライアントやゲートウェイの不一致なのかを特定する。
4. ゲートウェイやサービスが環境変数からAPIキーを読み込んでいる場合、キーが正しく配置されていることを確認し、キーや設定を変更した後はゲートウェイを再起動する。
5. 長文の会話で特にエラーが多発する場合は、ロングコンテキストリクエストの制限が原因である可能性を考慮する。

まとめ

この警告が繰り返されるのは、Hermesのper-turnフォールバック機構が正常に機能している証拠であり、プライマリモデルのレート制限が解消されない限り続きます。警告を止めるには、「フォールバックへの切り替え」メッセージそのものではなく、プライマリモデル、ゲートウェイ、またはAPIキープールの根本原因に対処する必要があります。

設定ファイルを直接確認すれば、どのプライマリが失敗しているのか、sg-* フォールバックが実際にどこを指しているのか、そしてなぜ毎ターンプライマリに戻ろうとするのかを正確に特定できます。