1つのAI APIに依存すると、レート制限や障害のたびに作業が止まります。開発者のdirekturcrypto氏は、セルフホスト型エージェント基盤のOpenClawを使い、4社のAIプロバイダを同時に運用する構成を公開しました。レート制限時の自動フェイルオーバー、無料モデルの迅速な追加、トークン削減まで一気通貫でまとめられており、APIコストと安定性の両方を意識した実践例として参考になります。
この記事でわかること
- OpenClawがマルチプロバイダ運用に向く理由
- レート制限時の自動フェイルオーバーの仕組み
- 無料モデルの追加とトークン削減の設定ポイント
- 導入時に押さえるべき注意点
なぜマルチプロバイダ運用が必要か
AIエージェントを本番運用すると、HTTP 429（レート制限）やプロバイダ側の過負荷エラーに頻繁に遭遇します。単一のAPIキーだけに頼ると、制限に達した瞬間にエージェント全体が応答不能になります。
direkturcrypto氏はX（旧Twitter）で、OpenClawを4社のAIプロバイダにまたがって稼働させていると報告しています（参考）。1社が制限に達しても、次のプロバイダへ自動で切り替わるため、手動でのキー入れ替えや再起動が不要になります。
OpenClawとは
OpenClawは、自分のマシン上で動かすセルフホスト型のAIエージェント基盤です。WhatsAppやTelegram、Slackなどのチャットアプリと接続し、ツール実行やファイル操作、ブラウザ操作をエージェントに任せられます。MITライセンスのオープンソースで、Anthropic・OpenAI・Googleなど複数のLLMプロバイダに対応しています（公式ドキュメント）。
エージェントの制御はGatewayという常駐プロセスが担い、セッション管理やモデル切り替え、認証プロファイルのローテーションを一元化します。アプリ側にフェイルオーバー処理を書かなくても、Gatewayがプロバイダ間の切り替えを処理する点が、マルチプロバイダ運用の肝です。
レート制限時の自動フェイルオーバー
OpenClawのフェイルオーバーは2段階で動きます（Model failover）。
まず、同一プロバイダ内の認証プロファイル（APIキーやOAuthトークン）をローテーションします。複数のキーを登録しておけば、1つが429を返しても別のキーへ切り替わります。デフォルトでは、レート制限時に同一プロバイダ内で1回プロファイルを切り替えた後、次のモデル候補へ進みます。
次に、agents.defaults.model.fallbacksに設定したモデルチェーンを順に試します。例えばAnthropicのClaudeをプライマリにし、OpenAIのGPTをフォールバックに指定すれば、Anthropic側が枯渇した際に自動でOpenAIへ移行します。429だけでなく、過負荷エラーやタイムアウトもフェイルオーバー対象です。
フェイルオーバーが発動すると、チャット上に「↪️ Model Fallback:」という通知が表示されます。どのモデルに切り替わったかが一目で分かるため、運用中のトラブルシュートが楽になります。プライマリが復旧すると、5分間隔のプローブで自動的に元のモデルへ戻ります。
設定例は以下のとおりです。
{
"agents": {
"defaults": {
"model": {
"primary": "anthropic/claude-sonnet-4-6",
"fallbacks": [
"openai/gpt-5.4",
"openrouter/google/gemini-2.5-flash"
]
}
}
}
}
無料モデルの迅速な追加
direkturcrypto氏は、新しい無料モデルが登場した際に30秒以内で追加できると報告しています（参考）。OpenClawにはOpenRouterの無料モデルカタログを走査するCLIコマンドopenclaw models scanが用意されています（Models）。
このコマンドはOpenRouterの:freeタグ付きモデルを一覧し、ツール対応や画像入力の有無をプローブで検証します。--set-defaultフラグを付ければ、見つかった最初のモデルをプライマリに設定できます。無料枠のモデルはレート制限が厳しいことが多いため、フォールバックチェーンと組み合わせる運用が現実的です。
openclaw models scan --set-default
プロバイダの追加自体はopenclaw configureやopenclaw models auth login --provider <id>で行います。既存のプライマリモデルは上書きされないため、4社目のプロバイダを後から足しても既存構成を壊しません（Model providers）。
トークン削減の仕組み
direkturcrypto氏の運用では、ビルトインの圧縮機能によりトークン消費が20〜40%減ったと報告されています（参考）。OpenClawが標準で備える削減手段は主に3つです。
コンパクション（Compaction）は、会話がコンテキスト上限に近づくと古いメッセージを要約に置き換えます。デフォルトで有効で、コンテキスト溢れエラーが返った場合も自動で要約してリトライします（Compaction）。チャットで/compactを実行すれば手動でも要約できます。
セッションプルーニング（Session pruning）は、各LLM呼び出しの前に古いツール結果をトリミングします。exec出力やファイル読み取り結果がコンテキストを膨らませるのを防ぎ、ディスク上の履歴はそのまま残します（Session pruning）。Anthropicプロファイルではデフォルトで有効です。
コンテキスト診断では、チャットの/context detailでツール・スキル・システムプロンプトごとのトークン消費を確認できます（Token use）。使わないスキルを無効化するだけで、毎回のAPI呼び出しコストを下げられます。
さらに圧縮を強化したい場合は、OpenCompressプラグインが選択肢になります。5段階のプロンプト圧縮パイプラインで、既存のプロバイダ設定を変えずにトークン数を削減します（OpenCompress）。
導入の流れ
OpenClawの導入はopenclaw onboardコマンドから始めます。ウィザードがGateway、ワークスペース、チャンネル、スキルの設定を順に案内します。daemonとしてインストールすれば、マシン起動後も常時稼働します。
マルチプロバイダ構成を組む手順は次のとおりです。
openclaw configureで各プロバイダのAPIキーまたはOAuthを登録する~/.openclaw/openclaw.jsonのagents.defaults.modelにプライマリとフォールバックを記述するopenclaw models listで利用可能なモデルを確認する- 必要に応じて
openclaw models scanで無料モデルを探索する - Gatewayを起動し、チャットアプリからエージェントに話しかけて動作を確認する
注意点
フェイルオーバーは万能ではありません。コンテキスト溢れエラーはコンパクションで処理されるため、フォールバックには進みません。プロバイダごとにコンテキスト上限が異なる場合は、フォールバック先のモデル選定に注意が必要です。
また、ユーザーが/modelコマンドで明示的にモデルを指定した場合、その選択は厳密モードになります。指定モデルが失敗しても、設定済みのフォールバックには自動で切り替わりません。日常運用ではプライマリ＋フォールバックの自動切り替えに任せ、手動指定は一時的なテストに留めるのが安全です。
同一プロバイダ内のレート制限がモデル単位でスコープされている場合、兄弟モデルへの切り替えが先に試されます。プロバイダ全体が枯渇した場合に初めて別プロバイダのフォールバックへ進むため、フォールバックチェーンの順序設計が運用の安定性を左右します。
実践から学べること
direkturcrypto氏の事例は、単一ツールで「冗長化」「コスト削減」「新モデルの迅速な取り込み」を同時に実現できることを示しています。アプリコードにフェイルオーバーロジックを書く代わりに、OpenClawのGateway設定に委ねることで、運用の複雑さを大幅に下げられます。
AI APIの料金はトークン数に比例するため、コンパクションとプルーニングの標準機能を有効にしたまま運用するだけでも、コスト削減の効果が見込めます。無料モデルをフォールバックチェーンの末端に置けば、有料APIの消費を抑えつつ、制限時にもエージェントを止めずに済みます。