OpenClawマルチモデルフェイルオーバーと自動切り替え

なぜフェイルオーバーが必要なのか

本番環境において、単一のモデルプロバイダーに依存することは重大なリスクです。APIサービスはさまざまな理由で利用不可になる可能性があります：サーバーメンテナンス、地域的なネットワーク障害、レート制限、アカウント残高不足、さらにはプロバイダーの全面的なダウンタイムなどです。AIアプリケーションにフェイルオーバーメカニズムがない場合、いずれかのプロバイダーの問題がサービスの完全な中断に直結します。

OpenClawには成熟したマルチモデルフェイルオーバーシステムが内蔵されており、マルチアカウント認証ローテーション、クールダウン追跡、クロスプロバイダー自動切り替えの3つの層をカバーしています。本記事では、このメカニズムの動作原理と設定方法を深く解説します。

第一層：マルチアカウント認証ローテーション

フェイルオーバーの第一の防御線は、同一プロバイダー内でのマルチアカウントローテーションです。各プロバイダーに複数のAPIキー（profile）を設定でき、OpenClawは問題が発生した際に自動的に次の利用可能なキーに切り替えます。

{
  "providers": {
    "anthropic": {
      "auth": [
        { "key": "sk-ant-key-001", "profile": "チームメインアカウント" },
        { "key": "sk-ant-key-002", "profile": "個人バックアップ" },
        { "key": "sk-ant-key-003", "profile": "緊急用アカウント" }
      ]
    }
  }
}

動作メカニズム

OpenClawが最初のprofileでリクエストを送信した際、認証失敗（401）、レート制限（429）、サーバーエラー（500/502/503）に遭遇すると、システムは以下を実行します。

現在のprofileを即座に「クールダウン中」状態としてマーク。
失敗時刻を記録し、クールダウンタイマーを開始。
auth配列の次のprofileに自動切り替えしてリクエストをリトライ。
すべてのprofileがクールダウン状態の場合、プロバイダーレベルのフェイルオーバーをトリガー。

クールダウン追跡メカニズム

クールダウン追跡はOpenClawフェイルオーバーシステムのコアコンポーネントです。問題があると分かっているキーへの繰り返しの試行を防止しつつ、復旧後のキーを再有効化することが目的です。

クールダウン追跡の主要な動作：

失敗記録：リクエスト失敗ごとに失敗タイプとタイムスタンプを記録。
段階的クールダウン：連続失敗回数が多いほどクールダウン時間が長くなり、レート制限されているアカウントへの頻繁なリトライを回避。
自動復旧：クールダウン期間終了後、そのprofileは自動的に利用可能状態に復帰し、通常のローテーションスケジューリングに参加。
エラータイプ別の区別：認証エラー（401）のクールダウン時間は通常長く、レート制限（429）のクールダウン時間は比較的短い。

第二層：クロスプロバイダーフェイルオーバー

あるプロバイダーのすべてのキーが利用不可になった場合、OpenClawはクロスプロバイダーのフェイルオーバーを実行し、リクエストをバックアップモデルにルーティングします。

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "anthropic/claude-opus-4-5",
        "fallback": "openai/gpt-4o"
      }
    }
  }
}

フェイルオーバーチェーン

複数レベルのフェイルオーバーを設定して、完全なフェイルオーバーチェーンを構成できます。

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "anthropic/claude-opus-4-5",
        "fallback": "bedrock/anthropic.claude-3-5-sonnet-20241022-v2:0",
        "fallback2": "openai/gpt-4o",
        "fallback3": "openrouter/anthropic/claude-3.5-sonnet"
      }
    }
  }
}

この設定は4段階のフェイルオーバーを確立します。

第一選択はAnthropicの直接接続API。
Anthropic直接接続が利用不可の場合、AWS Bedrock経由でClaudeにアクセスを試行。
Bedrockも利用不可の場合、OpenAIのGPT-4oに切り替え。
最後に、OpenRouterを最終バックアップとして使用。

第三層：メタプロバイダーとしてのOpenRouter

OpenRouterはフェイルオーバー戦略において特別な役割を果たします。複数のモデルプロバイダーを集約するメタプラットフォームとして、OpenRouter自体がルーティングとフェイルオーバー能力を備えています。OpenRouterをフェイルオーバーチェーンの末端に配置することで、最後のセーフティネットとして機能します。

{
  "providers": {
    "openrouter": {
      "auth": [
        { "key": "あなたのOpenRouterキー" }
      ]
    }
  }
}

OpenRouterを通じて、xAI（Grok）、Groq、Mistralなど多数のプロバイダーのモデルにアクセスでき、システムの弾力性をさらに高められます。

実際のデプロイに関するアドバイス

推奨されるフェイルオーバー戦略

本番環境向けの推奨設定テンプレートを以下に示します。

{
  "providers": {
    "anthropic": {
      "auth": [
        { "key": "キーA", "profile": "メイン" },
        { "key": "キーB", "profile": "バックアップ" }
      ]
    },
    "openai": {
      "auth": [
        { "key": "キーC", "profile": "メイン" }
      ]
    },
    "openrouter": {
      "auth": [
        { "key": "キーD", "profile": "メイン" }
      ]
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "anthropic/claude-opus-4-5",
        "fallback": "openai/gpt-4o",
        "fallback2": "openrouter/anthropic/claude-3.5-sonnet"
      }
    }
  }
}

重要な原則

同レベルのバックアップを優先：まず同一プロバイダー内でキーローテーションを行い、次にクロスプロバイダー切り替え。
能力の一致：フェイルオーバーチェーン内のモデルは近い能力レベルであるべき。ユーザー体験の急激な変動を避ける。
コスト意識：バックアップモデルのコストは異なる場合がある。各モデルの料金を把握しておく。
テスト検証：フェイルオーバーチェーン内の各モデルが利用可能かを定期的にテスト。実際の障害時にバックアップも使えないことがないようにする。

監視とアラート

OpenClawのログはフェイルオーバーイベントを毎回記録します。以下の主要指標の監視を推奨します。

フェイルオーバーがトリガーされる頻度。
各profileのクールダウン状態。
リクエストの平均レイテンシ（フェイルオーバーは通常レイテンシを増加させる）。

マルチアカウント認証とクロスプロバイダーフェイルオーバーを適切に設定することで、OpenClawデプロイはほぼ100%の可用性を実現でき、単一プロバイダーの深刻な障害に直面してもサービスの継続性を維持できます。