2026年 OpenClaw：マルチプロバイダのフェイルオーバーと 429／5xx の指数バックオフ——ゲートウェイルーティング、タイムアウト分割と独占リモート Mac SSH の再現トラブルシュート＋FAQ

TL;DR — 要点

結論： プロバイダは「契約」ではなく信頼できないバスとして扱う。ゲートウェイは経路を選び、健全性を測り、Mac のファイル記述子が枯渇する前に負荷を捨てる。

• ルーティング： 外向き API は安定させ、論理モデル名から物理プロバイダ ID への写像は一箇所に集約し、フェイルオーバーでクライアント再配布を要さないようにする。
• 429： サーバのヒントを尊重——Retry-After（秒または HTTP-date）をパースし、その上に full jitter を載せ、プロバイダ鍵あたりの同時実行数を上限する。
• 5xx： 短い試行回数に指数バックオフとサーキットブレーカーを組み合わせ、同じ壊れた上流へ十回リトライするより二次プロバイダへ速やかに逃がす。
• タイムアウト： 接続、TLS、初バイト（TTFB）、エンドツーエンドのツール予算に分割し、巨大な単一タイムアウトでどのホップが詰まったか見えなくしない。
• SSH Mac： 版を固定し、リクエスト相関 ID をログに載せ、CI が使うのと同じ curl をリプレイする——独占筐体なら競合が読みやすい。

インバウンド HTTP（Webhook や CI コールバック）側でも 429 とプロキシタイムアウトが絡む場合は、ゲートウェイ正面のレート制限とタイムアウト階層を同じ考え方で揃えてください。専用ノード上で Runner と常駐デーモンを同居させる設計の比較は、 2026年 エンタープライズ iOS/macOS CI 選定：GitLab Runner（macOS）と GitHub Actions セルフホスト Runner の比較——専用リモート Mac ノードにおける並行性、SSH アカウント分離、キャッシュマウントと運用 FAQ の意思決定マトリクス がキューと SSH 境界の語彙を揃えるのに役立ちます。クラウド上の Mac mini を前提にした CI 全体像は 2026年クラウドMac mini構築と実践：iOS CI（継続的インテグレーション）シナリオ から俯瞰できます。Windows 側から iOS ビルドだけリモートに逃がす読み替えは 2026年Windows開発者必見！React Native iOSアプリをMac miniレンタルでリモートビルドする方法 も参考になります。

1. マルチプロバイダ構成：ゲートウェイは一つ、上流は複数

レジリエントな配置では、Mac 上に一つのリスナ（または HA で密結合したペア）を置きます。IDE 拡張、CLI エージェント、自動化はすべてあなたのホスト名へ。ゲートウェイ内のルータ表が、一次クラウド API・二次ベンダ・ローカル Ollama・トリアージ用の安価モデルなど、どの上流が各リクエストを満たすかを決めます。

プロバイダ URL をスキルやシェルスクリプトに散らさない。エンドポイントローテやモデル文字列廃止のたびにリポジトリ全体を漁るのではなく、設定の再読込一回で済ませたいからです。

2. ヘルスシグナル：いつフェイルオーバーし、いつしないか

2.1 ハードシグナル

• 鍵ローテ後の HTTP 401／403 —— 盲信でフェイルオーバーせず、資格情報を先に直す。
• クォータ意味が明確な HTTP 429 —— 失敗リクエストだけでなく、その鍵に対して全体を減速する。
• HTTP 5xx の連発や接続リセット —— 短い指数リトライの候補、その後サーキットオープンで代替上流へ。

2.2 ソフトシグナル

• ステータスは 200 のまま p95 の初トークンまでの時間が伸びる —— 崩壊の前触れ。早めに負荷を捨てる。
• ツール途中でストリームが止まる —— チャンク境界をログし、上流メンテ窓と突き合わせる。

3. バックオフ設計：429 と 5xx

429（Too Many Requests）： 事業者は待てと言っている。Retry-After をパースし、API 鍵ごとのトークンバケツと併用する。ヘッダが無い場合は保守的な基底遅延（例：1〜2 秒）から始め、[0, d] の full jitter を載せてプロセス横断の雷群を避ける。

5xx／ネットワークエラー： 小さなリトライ予算（例：2〜4 回）に指数基底と jitter。サーキットブレーカーと併用し、窓 W で N 回失敗したら M 分は新規トラフィックを二次プロバイダへ、その後単発プローブ。

層をまたいでリトライを掛け算しない——CLI がリトライし、ゲートウェイがリトライし、リバースプロキシもリトライすると自己 DDoS になる。リトライの所有者は一つに決め、下位層は構造化エラーで速く失敗させる。

4. 2026 年のトラフィック急増でも残るゲートウェイルーティング

• スティッキセッションは必要な場所だけ： 会話メモリはストア側に置き、偶発的な「ある上流ポッド依存」にしない。
• カナリア比重： 新プロバイダへ 5% だけ流してから、設定の primary ポインタを反転する。
• 決定的劣化： プレミアムがすべて赤なら「最低限動くモデル」ルートを定義する——正直な短文のほうが、三十分ハングよりマシ。

5. タイムアウト分割：犯人ホップを特定する

すべてを一つのノブにまとめると、いつまでも誤診する。別々に測り、設定する。

• 接続＋TLS（健全なら通常数秒）。
• ヘッダ送信完了から初バイトまで（TTFB）。ストリーミング chat completions で特に重要。
• エンドツーエンドの利用者予算（ツール実行と Mac 上のディスク I/O を含む）。
• ストリームチャンク間のアイドル（クライアントが沈黙を失敗とみなす場合）。

四つとも同じ相関 ID でログする。SSH 越しに本番と同じトンネル経路で curl -w '%{time_connect} %{time_starttransfer} %{time_total}\n' をリプレイする。

6. 再現チェックリスト：SSH で届く独占リモート Mac

1. 版の固定： openclaw／ゲートウェイパッケージ／Node を plist や compose の横にコミットするファイルへ記録。
2. 設定を Git に： プロバイダ表、タイムアウト、リトライ上限——サーバだけの手編集差分を残さない。
3. launchd ログ： stdout／stderr のローテーション。JSON ログなら相関 ID を載せる。
4. 故障注入： ノートから Mac の /etc/hosts で一次ホスト名を一時ブロックするか、クォタゼロのテスト鍵で 429 を強制し、フェイルオーバー指標が期待どおり動くか確認。
5. リプレイ脚本： 短文チャット、長文コンテキスト、ツール多めの三種を保存し、アップグレードのたびに実行。

7. FAQ — 症状と最初の確認

コントロールプレーンなら、macOS × Mac mini が足元に合う

ゲートウェイとルータはバースト型のゲーム負荷ではなく、開発者とエージェントが叩き続ける週単位の常駐プロセスです。Apple Silicon 上の macOS は、アイドル電力が低く（Mac mini M4 クラスは待機で数ワット程度に抑えやすい）、TLS 終端と JSON ストリームのシングルスレッド応答性に優れ、SSH ファーストの自動化には Homebrew・ネイティブ OpenSSH・サービス用アカウントのファイル権限が素直に効きます。

Gatekeeper、SIP、FileVault による無人時の脅威面の縮小と、ハードと OS の一体最適化による性能の予測しやすさは、観測エージェントを足しても挙動が変わりにくいという意味で TCO に効きます。ステージングと同じフェイルオーバー挙動を火曜深夜にも求めるなら、信頼できる筐体にゲートウェイを載せるのは強いデフォルトです。

「自分のノートでは動いた」を「常時オンで信頼できるルーティング」へ進めるなら、Mac mini M4 は依然として費用対効果の高い出発点です。プラン比較は SSHMac のトップページからどうぞ。