--- read_when: - 認証プロファイルのローテーション、クールダウン、モデルのフォールバック動作を診断する - 認証プロファイルまたはモデルのフェイルオーバールールの更新 - セッションのモデルオーバーライドとフォールバック再試行の相互作用を理解する sidebarTitle: Model failover summary: OpenClaw が認証プロファイルをローテーションし、モデル間でフォールバックする仕組み title: モデルのフェイルオーバー x-i18n: generated_at: "2026-07-26T09:00:31Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 32 provider: openai source_hash: 3dfedbc85038eebb5be056a7b3ffa3275b4329a0b0d791e1a2b4701cbaa4b595 source_path: concepts/model-failover.md workflow: 16 --- OpenClaw は障害を 2 段階で処理します。 1. 現在のプロバイダー内での**認証プロファイルのローテーション**。 2. `agents.defaults.model.fallbacks` 内の次のモデルへの**モデルフォールバック**。 ## ランタイムフロー アクティブなセッションモデルと認証プロファイルの優先設定を解決します。 現在のモデル選択と、その選択元に対するフォールバックポリシーから、モデル候補チェーンを構築します。設定済みのデフォルト、Cron ジョブのプライマリ、および自動選択されたフォールバックモデルでは、設定済みのフォールバックを使用できます。ユーザーが明示的に選択したセッションモデルには厳密に従います。 認証プロファイルのローテーションとクールダウンのルールに従って、現在のプロバイダーを試行します。 そのプロバイダーの候補をすべて試してもフェイルオーバー対象のエラーが発生する場合は、次のモデル候補に進みます。 セッションで選択されているプロバイダーやモデルを変更せずに、成功したフォールバック候補を実行します。 すべての候補がプロバイダーの過負荷のみを理由に失敗した場合、ツール実行もアシスタント出力も開始されていない間は、指数バックオフを使用してターンローカルのチェーン全体を最大 10 回再試行します。30 秒が経過したら、ユーザーを無言で待たせないようにステータス通知を 1 回送信します。 すべての候補が失敗した場合は、試行ごとの詳細と、判明している場合は最も早いクールダウン終了時刻を含む `FallbackSummaryError` をスローします。 フォールバックの実行はターンローカルです。返信ランナーが永続化するのはフォールバック通知の状態のみです。これにより、`/status` と遷移通知で、選択されたモデルと実際に応答したモデルを区別できます。次のターンのモデル選択としてフォールバックを永続化することはありません。 ## 選択元ポリシー 選択元によって、フォールバックチェーンを使用できるかどうかが決まります。 - **設定済みのデフォルト**: `agents.defaults.model.primary` は `agents.defaults.model.fallbacks` を使用します。 - **エージェントのプライマリ**: そのエージェントのモデルオブジェクトに独自の `fallbacks` が含まれていない限り、`agents.entries.*.model` には厳密に従います。厳密な動作を明示するには `fallbacks: []` を使用し、そのエージェントでモデルフォールバックを有効にするには空でないリストを使用します。 - **ランタイムフォールバック**: フォールバック候補は現在のターンにのみ適用されます。次のターンは、選択されたプライマリから再び開始します。OpenClaw は以前に保存された `modelOverrideSource: "auto"` エントリも引き続き認識し、設定された元の候補を 5 分ごとにプローブして、回復するとエントリをクリアします。`/new`、`/reset`、および `sessions.reset` でも、これらのエントリがクリアされます。 - **ユーザーのセッションオーバーライド**: `/model`、モデルピッカー、`session_status(model=...)`、および `sessions.patch` は `modelOverrideSource: "user"` を書き込みます。これはセッションに対する厳密な選択です。選択されたプロバイダーやモデルが返信を生成する前に失敗した場合、OpenClaw は無関係な設定済みフォールバックから応答せず、障害を報告します。 - **従来のセッションオーバーライド**: 古いセッションエントリには、`modelOverrideSource` がなく `modelOverride` のみが存在する場合があります。OpenClaw はこれらをユーザーオーバーライドとして扱うため、古い明示的な選択が暗黙にフォールバック動作へ変換されることはありません。 - **Cron ペイロードモデル**: Cron ジョブの `payload.model` / `--model` はジョブのプライマリであり、ユーザーのセッションオーバーライドではありません。ジョブに `payload.fallbacks` が指定されていない限り、設定済みのフォールバックを使用します。`payload.fallbacks: []` を指定すると、Cron の実行は厳密になります。 ターンがフォールバックへ移行すると、OpenClaw はユーザーに見える通知を送信し、その後のターンで選択されたプライマリが成功すると、別の通知を送信します。通知状態を永続化することで、連続するターンで同じ選択済みモデルとアクティブモデルの組み合わせが使われた場合の通知の繰り返しを防ぎますが、モデル選択自体は変更されません。 ## 認証失敗スキップキャッシュ デフォルトでは、新しい各ターンで既存のフォールバック再試行動作が維持されます。OpenClaw は、最近 `auth` または `auth_permanent` で失敗した非プライマリ候補を含め、設定された各フォールバック候補を再び試行します。 繰り返される認証失敗を抑制するには、次を設定してオプトインします。 ```bash OPENCLAW_FALLBACK_SKIP_TTL_MS=60000 ``` 有効にすると、OpenClaw は認証クラスの障害後に、非プライマリのフォールバック候補に対するインメモリかつセッションスコープのスキップマーカーを記録します。キーにはセッション ID、プロバイダー、モデルを使用します。プライマリ候補はスキップされないため、ユーザーが明示的に選択したモデルでは実際の認証エラーが引き続き表示されます。キャッシュはプロセスローカルであり、Gateway の再起動時にクリアされます。 値はミリ秒単位の TTL です。`0` または未設定の場合、キャッシュは無効になります。正の値は 1 秒から 10 分の範囲に制限されます。 ## ユーザーに表示されるフォールバック通知 セッションが自動選択されたフォールバックへ移行すると、OpenClaw は同じ返信画面にステータス通知を送信します。 ```text ↪️ モデルフォールバック: （選択済み: ; ） ``` 後続のプローブが成功し、セッションが選択済みのプライマリに戻ると、OpenClaw は次を送信します。 ```text ↪️ モデルフォールバックを解除: （以前: ） ``` これらの通知は運用メッセージであり、アシスタントのコンテンツではありません。可能な場合は副作用のみのターンも含め、状態の変更ごとに 1 回配信されますが、ターンローカルのフォールバック遷移が繰り返されても再送されません。配信は通常の送信元返信抑制をバイパスし、スレッド形式のチャンネルにおける最初のアシスタント返信枠を消費せず、テキスト読み上げとコミットメント抽出の対象外です。 ## 認証ストレージ（キー + OAuth） OpenClaw は API キーと OAuth トークンの両方に**認証プロファイル**を使用します。 - シークレットとランタイムの認証ルーティング状態は `~/.openclaw/agents//agent/openclaw-agent.sqlite` に保存されます。 - 設定 `auth.profiles` / `auth.order` は**メタデータとルーティング専用**です（シークレットは含まれません）。 - インポート専用の従来の OAuth ファイル: `~/.openclaw/credentials/oauth.json`（初回使用時にエージェントごとの認証ストアへインポートされます）。 - 従来の `auth-profiles.json`、`auth-state.json`、およびエージェントごとの `auth.json` ファイルは、`openclaw doctor --fix` によってインポートされます。 詳細: [OAuth](/ja-JP/concepts/oauth) 認証情報の種類: - `type: "api_key"` → `{ provider, key }` - `type: "oauth"` → `{ provider, access, refresh, expires, email? }`（一部のプロバイダーではさらに `projectId`/`enterpriseUrl`） - `type: "token"` → 静的な Bearer 形式のトークン。有効期限は任意です。OpenClaw はこれを更新しません（`aws-sdk` およびその他の認証情報チェーン認証モードで使用） ## プロファイル ID OAuth ログインでは、複数のアカウントが共存できるように個別のプロファイルが作成されます。 - デフォルト: メールアドレスを取得できない場合は `provider:default`。 - メールアドレスを使用する OAuth: `provider:`（例: `google-antigravity:user@gmail.com`）。 プロファイルは、エージェントごとの `openclaw-agent.sqlite` 認証プロファイルストアに保存されます。 ## ローテーション順序 プロバイダーに複数のプロファイルがある場合、OpenClaw は次の順序で選択します。 `auth.order[provider]`（設定されている場合）。 プロバイダーで絞り込まれた `auth.profiles`。 そのプロバイダーに対応する、エージェントごとの SQLite 認証プロファイルエントリ。 明示的な順序が設定されていない場合、OpenClaw は次のラウンドロビン順序を使用します。 - **プライマリキー:** プロファイルの種類（**OAuth、静的トークン、API キーの順**）。 - **OAuth のセカンダリキー:** 現在使用可能なアクセストークンを持つプロファイルを、 アクセストークンの有効期限が切れたプロファイルより先にします。使用可能な同等プロファイルがない場合に ランタイムが更新できるよう、有効期限切れの OAuth プロファイルも候補として維持されます。 - **次のキー:** `usageStats.lastUsed`（各種類および状態階層内で古いものから順）。 - **クールダウン中または無効なプロファイル**は末尾へ移動し、終了時刻が早い順に並べられます。 ### セッション固定（キャッシュ効率を考慮） OpenClaw は、プロバイダーのキャッシュをウォーム状態に保つため、**セッションごとに選択した認証プロファイルを固定**します。リクエストごとにはローテーション**しません**。固定されたプロファイルは、次のいずれかが発生するまで再利用されます。 - セッションがリセットされた場合（`/new` / `/reset`） - Compaction が完了した場合（Compaction 回数が増加） - プロファイルがクールダウン中または無効な場合 `/model …@` による手動選択は、そのセッションに**ユーザーオーバーライド**を設定します。新しいセッションが開始されるまで自動ローテーションされません。 自動固定されたプロファイル（セッションルーターによって選択されたもの）は**優先設定**として扱われます。最初に試行されますが、レート制限やタイムアウトが発生した場合、OpenClaw は別のプロファイルへローテーションすることがあります。元のプロファイルが再び利用可能になると、選択されたモデルやランタイムを変更せずに、新しい実行で再びそのプロファイルを優先できます。ユーザーが固定したプロファイルは、そのプロファイルにロックされたままです。失敗し、モデルフォールバックが設定されている場合、OpenClaw はプロファイルを切り替える代わりに次のモデルへ移動します。 ### OpenAI Codex サブスクリプションと API キーのバックアップ OpenAI エージェントモデルでは、認証とランタイムは分離されています。認証では Codex サブスクリプションプロファイルと OpenAI API キーのバックアップ間をローテーションできますが、`openai/gpt-*` は Codex ハーネス上に維持されます。 ユーザー向けの順序には `auth.order.openai` を使用します。 ```json5 { auth: { order: { openai: ["openai:user@example.com", "openai:api-key-backup"], }, }, } ``` ChatGPT/Codex OAuth プロファイルと OpenAI API キープロファイルの両方に `openai:*` を使用します。サブスクリプションが Codex の使用量上限に達すると、Codex からリセット時刻が提供される場合、OpenClaw はその正確な時刻を記録し、順序内の次の認証プロファイルを試行して、実行を Codex ハーネス内に維持します。リセット時刻を過ぎるとサブスクリプションプロファイルが再び候補となり、次の自動選択でそのプロファイルに戻ることができます。 そのセッションで 1 つのアカウントまたはキーを強制的に使用する場合にのみ、ユーザー固定プロファイルを使用してください。ユーザー固定プロファイルは意図的に厳密であり、暗黙に別のプロファイルへ切り替わることはありません。 ## クールダウン 認証エラーやレート制限エラー（またはレート制限のように見えるタイムアウト）が原因でプロファイルが失敗すると、OpenClaw はそのプロファイルをクールダウン状態にして、次のプロファイルへ移動します。 このレート制限区分は単純な `429` より広く、`Too many concurrent requests`、`ThrottlingException`、`concurrency limit reached`、`workers_ai ... quota limit exceeded`、`throttled`、`resource exhausted` などのプロバイダーメッセージや、`weekly limit reached` または `monthly limit exhausted` などの定期的な使用量ウィンドウ制限も含まれます。 フォーマットエラーや無効なリクエストのエラーは、同じペイロードを再試行しても同じように失敗するため、通常は終了エラーとして扱われます。そのため、OpenClaw は認証プロファイルをローテーションせずにエラーを表示します。既知の再試行修復パスでは、明示的にオプトインできます。たとえば、Cloud Code Assist のツール呼び出し ID 検証エラーはサニタイズされ、`allowFormatRetry` ポリシーを通じて 1 回再試行されます。 `Unhandled stop reason: error`、`stop reason: error`、`reason: error`、`Provider finish_reason: error` など、OpenAI 互換の**プロバイダー完了済み**停止理由または終了理由は、タイムアウトではなく **`server_error`**（HTTP 相当のステータス 500）として分類されます。モデルやプロファイルのローテーションにおけるフェイルオーバー対象のままですが、診断ではユーザー向けの文言を「LLM リクエストがタイムアウトしました」に書き換えず、プロバイダーの終了理由テキストを保持します。`Provider finish_reason: abort`、`network_error`、`malformed_response` など、トランスポート由来の終了理由はタイムアウト / フェイルオーバー区分（ステータス 408）のままです。 送信元が既知の一時的なパターンに一致する場合、一般的なサーバーテキストもこのタイムアウト区分に含まれることがあります。たとえば、モデルランタイムの簡素なストリームラッパーメッセージ `An unknown error occurred` は、共有モデルランタイムがプロバイダーストリームを `stopReason: "aborted"` または `stopReason: "error"` で終了し、具体的な詳細を提供しない場合に出力されるため、すべてのプロバイダーでフェイルオーバー対象として扱われます。`internal server error`、`unknown error, 520`、`upstream error`、`backend error` などの一時的なサーバーテキストを含む JSON `api_error` ペイロードも、フェイルオーバー対象のタイムアウトとして扱われます。 OpenRouter 固有の汎用アップストリームテキスト（単独の `Provider returned error` など）は、プロバイダーコンテキストが実際に OpenRouter である場合にのみタイムアウトとして扱われます。`LLM request failed with an unknown error.` などの汎用的な内部フォールバックテキストは保守的に扱われ、それ自体ではフェイルオーバーを引き起こしません。 一部のプロバイダー SDK は、そのままでは OpenClaw に制御を戻す前に長い `Retry-After` ウィンドウの間スリープすることがあります。Anthropic や OpenAI などの Stainless ベースの SDK では、OpenClaw は SDK 内部の `retry-after-ms` / `retry-after` 待機をデフォルトで 60 秒に制限し、それより長い再試行可能な応答を直ちに表面化して、このフェイルオーバーパスを実行できるようにします。`OPENCLAW_SDK_RETRY_MAX_WAIT_SECONDS` で上限を調整または無効化できます。詳細は[再試行の動作](/ja-JP/concepts/retry)を参照してください。 レート制限のクールダウンはモデル単位にすることもできます。 - 失敗したモデル ID が判明している場合、OpenClaw はレート制限の失敗について `cooldownModel` を記録します。 - クールダウンの対象が別のモデルである場合、同じプロバイダーの兄弟モデルを引き続き試行できます。 - 請求／無効化ウィンドウは、引き続きすべてのモデルについてプロファイル全体をブロックします。 通常の（請求関連でも永続的な認証関連でもない）クールダウンは、プロファイルの直近のエラー数に応じて延長されます。 - 1 回目の失敗: 30 秒 - 2 回目の失敗: 1 分 - 3 回目以降の失敗: 5 分（上限） プロファイルに組み込まれた失敗ウィンドウが経過すると、カウンターはリセットされます。 状態は、`usageStats` のエージェント単位の SQLite 認証状態に保存されます。 ```json { "usageStats": { "provider:profile": { "lastUsed": 1736160000000, "cooldownUntil": 1736160600000, "errorCount": 2 } } } ``` ## 請求による無効化 請求／クレジットの失敗（たとえば「クレジット不足」／「クレジット残高が低すぎる」）はフェイルオーバーの対象として扱われますが、通常は一時的なものではありません。OpenClaw は短いクールダウンを設定する代わりに、プロファイルを**無効**としてマークし（より長いバックオフを設定）、次のプロファイル／プロバイダーへローテーションします。 請求に見えるすべての応答が `402` であるわけではなく、すべての HTTP `402` がここに分類されるわけでもありません。プロバイダーが代わりに `401` または `403` を返した場合でも、OpenClaw は明示的な請求テキストを請求レーンに維持しますが、プロバイダー固有のマッチャーはそれを所有するプロバイダーのみに限定されます（たとえば OpenRouter の `403 Key limit exceeded`）。 一方、一時的な `402` の使用量ウィンドウおよび組織／ワークスペースの利用上限エラーは、メッセージが再試行可能に見える場合（たとえば `weekly usage limit exhausted`、`daily limit reached, resets tomorrow`、または `organization spending limit exceeded`）、`rate_limit` として分類されます。これらは長い請求無効化パスではなく、短いクールダウン／フェイルオーバーパスに留まります。 確度の高い永続的な認証失敗（取り消された／無効化されたキー、無効化されたワークスペース）には同様の無効化レーンが適用されますが、一部のプロバイダーは障害発生時に認証エラーに見えるペイロードを一時的に返すため、請求関連よりもはるかに早く回復します。 状態は、エージェント単位の SQLite 認証状態に保存されます。 ```json { "usageStats": { "provider:profile": { "disabledUntil": 1736178000000, "disabledReason": "billing" } } } ``` 過負荷およびレート制限エラーは、請求関連のクールダウンより積極的に処理されます。デフォルトでは、OpenClaw は同一プロバイダー内で認証プロファイルの再試行を 1 回許可した後、待機せずに次の設定済みモデルフォールバックへ切り替えます。 ## モデルフォールバック あるプロバイダーのすべてのプロファイルが失敗すると、OpenClaw は `agents.defaults.model.fallbacks` 内の次のモデルへ移動します。これは、プロファイルのローテーションを使い切った認証失敗、レート制限、タイムアウトに適用されます（その他のエラーではフォールバックは進みません）。十分な詳細を提示しないプロバイダーエラーも、フォールバック状態では正確にラベル付けされます。`empty_response` はプロバイダーが使用可能なメッセージもステータスも返さなかったことを、`no_error_details` はプロバイダーが明示的に `Unknown error (no error details in response)` を返したことを、`unclassified` は OpenClaw が未加工のプレビューを保持したものの、まだどの分類器にも一致していないことを意味します。 `ModelNotReadyException` などのプロバイダーがビジー状態であることを示すシグナルは過負荷バケットに分類され、レート制限と同じく、1 回ローテーションしてからフォールバックするポリシーに従います（上記のデフォルト表を参照）。 候補チェーン全体が過負荷による失敗のみで使い切られた場合、応答ランナーは同じターン内でチェーンを最大 10 回再試行します。ターン全体の再試行は、ツールの実行またはアシスタントの出力が開始される前にのみ許可されます。これにより、観測可能な処理の後に過負荷が発生した場合の変更やメッセージの重複を回避します。バックオフは 2.5 秒から始まり、倍増して上限の 30 秒に達します。ターンの待機時間が 30 秒に達すると、OpenClaw は一時的なステータス通知を 1 回送信します: `The AI service is temporarily overloaded. I’m still retrying; this may take a few minutes.` 再試行と、フォールバックで最終的に選ばれた候補は、そのターン内にのみ有効です。通常の一時的なサーバーエラーには、別途 1 回の再試行ポリシーが適用されます。 実行が、設定済みのデフォルトプライマリ、Cron ジョブのプライマリ、明示的なフォールバックを持つエージェントプライマリ、または自動選択されたフォールバックオーバーライドから開始された場合、OpenClaw は対応する設定済みフォールバックチェーンを順に試行できます。明示的なフォールバックを持たないエージェントプライマリ、および明示的なユーザー選択（たとえば `/model ollama/qwen3.5:27b`、モデルピッカー、`sessions.patch`、または一時的な CLI プロバイダー／モデルオーバーライド）は厳密に扱われます。そのプロバイダー／モデルに到達できない、または応答を生成する前に失敗した場合、OpenClaw は無関係なフォールバックで応答する代わりに失敗を報告します。 ### 候補チェーンのルール OpenClaw は、現在要求されている `provider/model` と設定済みフォールバックから候補リストを構築します。 - 要求されたモデルが常に先頭になります。 - 明示的に設定されたフォールバックは重複排除されますが、モデル許可リストによるフィルタリングは行われません。これらはオペレーターの明示的な意図として扱われます。 - 現在の実行ですでに同じプロバイダーファミリーの設定済みフォールバックを使用している場合、OpenClaw は引き続き設定済みチェーン全体を使用します。 - 明示的なフォールバックオーバーライドが指定されていない場合、要求されたモデルが別のプロバイダーを使用していても、設定済みフォールバックが設定済みプライマリより先に試行されます。 - フォールバックランナーに明示的なフォールバックオーバーライドが指定されていない場合、設定済みプライマリが末尾に追加されます。これにより、それ以前の候補を使い切った後、チェーンは通常のデフォルトに戻れます。 - 呼び出し元が `fallbacksOverride` を指定した場合、ランナーは要求されたモデルとそのオーバーライドリストのみを使用します。空のリストを指定するとモデルフォールバックが無効になり、設定済みプライマリが隠れた再試行先として追加されることも防止されます。 ### フォールバックを進めるエラー - 認証失敗 - レート制限およびクールダウンの使い切り - 過負荷／プロバイダーのビジー状態エラー - タイムアウト形式のフェイルオーバーエラー - 請求による無効化 - `LiveSessionModelSwitchError`。これは、古い永続化モデルによって外側の再試行ループが発生しないよう、フェイルオーバーパスに正規化されます - 候補がまだ残っている場合の、その他の認識されないエラー - タイムアウト／フェイルオーバー形式ではない明示的な中止 - Compaction／再試行ロジック内に留めるべきコンテキストオーバーフローエラー（たとえば `request_too_large`、`input token count exceeds the maximum number of input tokens`、`input exceeds the maximum number of tokens`、`input too long for the model`、または `ollama error: context length exceeded`） - 候補が残っていない場合の最終的な不明エラー - Claude Fable 5 の安全性に基づく拒否。直接 API キーを使用するリクエストでは、代わりに Anthropic のサーバー側フォールバックによってプロバイダーレベルで `claude-opus-4-8` へ切り替えて処理します（[Anthropic](/ja-JP/providers/anthropic#safety-refusal-fallback-claude-fable-5)を参照） ### クールダウン時のスキップとプローブの動作 あるプロバイダーのすべての認証プロファイルがすでにクールダウン中であっても、OpenClaw はそのプロバイダーを永続的に自動スキップするわけではありません。候補ごとに判断します。 - 永続的な認証失敗では、プロバイダー全体を直ちにスキップします。 - 請求による無効化では通常スキップしますが、再起動せずに回復できるよう、プライマリ候補についてはスロットル付きでプローブすることがあります。 - プライマリ候補は、プロバイダー単位のスロットル付きで、クールダウンの期限が近づいた時点にプローブされることがあります。 - 失敗が一時的に見える場合（`rate_limit`、`overloaded`、または不明）、クールダウン中でも同じプロバイダーの兄弟フォールバックを試行できます。これは特に、レート制限がモデル単位であり、兄弟モデルが直ちに回復できる可能性がある場合に重要です。 - 一時的なクールダウンのプローブは、1 回のフォールバック実行につきプロバイダーごとに 1 回に制限されます。これにより、単一のプロバイダーがプロバイダー間のフォールバックを停滞させることを防ぎます。 ## セッションオーバーライドと実行中のモデル切り替え セッションのモデル変更は共有状態です。アクティブなランナー、`/model` コマンド、Compaction／セッション更新、および実行中セッションの整合処理は、すべて同じセッションエントリの一部を読み書きします。フォールバックの実行はモデル選択フィールドを書き込まないため、再試行中に新しい手動選択を置き換えることはありません。 実行中のモデル切り替えは、次のルールに従います。 - 明示的なユーザー操作によるモデル変更のみが、保留中の実行中切り替えとしてマークされます。これには `/model`、`session_status(model=...)`、および `sessions.patch` が含まれます。 - フォールバックのローテーション、Heartbeat オーバーライド、Compaction などのシステムによるモデル変更は、それ自体では保留中の実行中切り替えとしてマークされません。 - ユーザーによるモデルオーバーライドは、フォールバックポリシー上、厳密な選択として扱われます。そのため、選択されたプロバイダーに到達できない場合、`agents.defaults.model.fallbacks` によって隠されるのではなく、失敗として表面化します。 - ランタイムのフォールバック候補は、そのターン内にのみ有効です。次のターンは、前回の実行中に行われた手動選択を含む、現在選択されているモデルから開始されます。 - 以前に保存された自動フォールバックオーバーライドは引き続きサポートされます。OpenClaw は設定された元の候補を定期的にプローブし、回復するとオーバーライドを解除します。`/new`、`/reset`、および `sessions.reset` は、自動設定されたオーバーライドを直ちに解除します。 - ユーザーへの応答では、フォールバックへの移行と、フォールバック解除後の回復を、状態変化ごとに 1 回通知します。選択済みモデルとアクティブモデルの組み合わせが同じままのターンが繰り返されても、通知は繰り返されません。 - `/status` は選択されたモデルを表示し、フォールバック状態が異なる場合は、アクティブなフォールバックモデルと理由も表示します。 - 実行中セッションの整合処理では、古いランタイムモデルフィールドよりも永続化されたセッションオーバーライドが優先されます。 - 実行中切り替えのエラーがアクティブなフォールバックチェーン内の後続候補を指している場合、OpenClaw は無関係な候補を先に順番に試すのではなく、選択されたそのモデルへ直接移動します。 アクティブな実行は、選択した候補を直接保持します。実行中の整合処理がその候補を変更するのは、明示的に保留中となっているユーザー切り替えの場合のみです。そのため、一時的なフォールバックオーバーライドやロールバックは不要です。 ## 可観測性と失敗の要約 `runWithModelFallback(...)` は、ログおよびユーザー向けのクールダウンメッセージに使用される試行ごとの詳細を記録します。 - 試行したプロバイダー／モデル - 理由（`rate_limit`、`overloaded`、`billing`、`auth`、`model_not_found`、および同様のフェイルオーバー理由） - 任意のステータス／コード - 人間が読めるエラー要約 構造化された `model_fallback_decision` ログには、候補が失敗した場合、スキップされた場合、または後続のフォールバックが成功した場合に、フラットな `fallbackStep*` フィールドも含まれます。これらのフィールドは、試行された遷移（`fallbackStepFromModel`、`fallbackStepToModel`、`fallbackStepFromFailureReason`、`fallbackStepFromFailureDetail`、`fallbackStepFinalOutcome`）を明示するため、最終的なフォールバックも失敗した場合でも、ログおよび診断エクスポーターはプライマリの失敗を再構築できます。 すべての候補が失敗すると、OpenClaw は `FallbackSummaryError` をスローします。外側の応答ランナーはこれを使用して、「すべてのモデルが一時的にレート制限されています」のような、より具体的なメッセージを作成し、判明している場合は最も早いクールダウン終了時刻を含めることができます。 このクールダウンの概要はモデルを考慮します。 - 試行したプロバイダー／モデルチェーンと無関係な、モデルスコープのレート制限は無視されます - 残っているブロックが一致するモデルスコープのレート制限である場合、OpenClaw はそのモデルを引き続きブロックしている最後の一致する終了時刻を報告します ## 関連設定 以下については、[Gateway の設定](/ja-JP/gateway/configuration)を参照してください。 - `auth.profiles` / `auth.order` - `agents.defaults.model.primary` / `agents.defaults.model.fallbacks` - `agents.defaults.imageModel` ルーティング より広範なモデル選択とフォールバックの概要については、[モデル](/ja-JP/concepts/models)を参照してください。