OpenClaw Gateway が立ち上がったあと、本番では多くの場合 コストとレイテンシを同時に抑える 方法が問われます。modelRouting は、常に最上位モデルの価格を払うのではなく、上流呼び出しの前に 見積もりコンテキスト規模 でトラフィックを階層化します。本稿では 何の問題を解くのか、openclaw.json 内で agents.defaults や フォールバック とどう並べるか、SLO を maxTokens の段階にどう対応づけるか、および 6 段階のロールアウトチェックリスト と誤設定の切り分けを解説し、当サイトのインストール・systemd・Docker 各記事を補います。
本番では OpenClaw のリクエストに システムプロンプト、会話履歴、ツール出力、RAG チャンク がまとめて載りがちです。すべてを常にフラッグシップ 1 種に流し続けると請求とテールレイテンシが膨らみ、失敗後のフォールバックだけに頼ると、すでに巨大コンテキストを焼いたあとで「別ルートだった」と気づきます。modelRouting は上流推論の前に コンテキストのトークン規模 を見積もり、階層を選ぶので、既定では「小さな質問には小さなモデル」を事後ではなく事前に適用できます。
チームがよく見る痛みのシグナルが 6 つ—複数当てはまるなら、Grafana だけ見るのではなくルーティングを設定レビューに載せましょう。
テールレイテンシ： QPS が同じでも p95/p99 が平均から離れ、会話長と連動する—重いコンテキスト経路の使い過ぎ。
非線形の支出： トラフィック +30% で請求 +100%—「全セッションが最大モデル既定」になりがち。
ツール呼び出しがコンテキストを膨らませる： 1 ターンで多段ツール出力がトークンを跳ね上げ、静かな切り捨てや予期せぬ再試行を招く。
フォールバック連鎖が長い： ユーザーには見えないが 1 リクエストでモデルを連ねており、レイテンシとコストが積み上がる。
ルーティングの可観測性がない： 最終モデル名だけをログし、なぜその階層かが分からない—切り分けが推測になる。
マルチテナントの分離が弱い： 共有 Gateway で重いセッションが軽いセッションの SLO を引きずる—コンテキスト形状でのハードゲートが必要。
当サイトの OpenClaw インストール／デプロイ シリーズを終えていれば、「プロセスは生き続け、ポートとトンネルは健全」という前提はすでにあります。本文はその長寿命プロセスの中でのモデル選択を扱います。リモート実行（セルフホスト Runner や専用リモート Mac）とは直交しており、ルーティングはどの頭脳か、実行層はどのマシンで動かすかを決めます。
誤解の一つに、modelRouting は「もう一つのロードバランサ」というものがあります。実際は コンテキスト形状ルーティング に近く、規模を見積もってからモデルを選びます。ラウンドロビンにすると、見た目は賢いトレースでも請求は正直です。
両者は排他的ではありませんが、役割を分けてください。フォールバック は 失敗の意味論—モデル利用不可、エラー、レート制限—に合います。modelRouting は コスト／レイテンシの意味論—このターンがどれだけ重いか—に合います。混ぜると「ルートは大きいモデルを選び、失敗で小さいモデルに落ちた」という二重請求のドラマになります。
| 観点 | primary＋フォールバック（古典） | modelRouting（コンテキスト階層） |
|---|---|---|
| トリガー | エラーコード、タイムアウト、再試行可能な失敗 | 見積もりコンテキストのトークンしきい値（例：コンテキスト規模戦略） |
| 主な利点 | 可用性：悪いモデルからの救出 | 効率：軽いチャットがフラッグシップ価格を払わない |
| 典型リスク | 長い連鎖がテールレイテンシと二重請求を膨らませる | 悪いしきい値が重い／軽いを誤分類する |
| 可観測性 | 失敗率、再試行、切り替え理由 | ルートヒットの偏り、しきい値付近のエラー、トークンのパーセンタイル |
| agents.defaults | プライマリとフォールバック一覧を宣言 | defaults 配下にルーティングブロックを足し、呼び出し前に分割 |
「失敗で差し替え」と「失敗の前に選ぶ」を別ページに書け—オンコールが感謝します。
ルーティング決定を構造化してログに出してください（階層ヒット、見積もりトークン帯、最終モデル ID）。そうでないと本番は最終モデルしか見えず、しきい値をレビューできません。下の 6 ステップがそのリリースゲートになります。
設定変更をすでに出せるエンジニア向けに—各ステップに成果物を置き、modelRouting が一度きりの JSON 落書きにならないようにします。
SLO の言語を固定： 目標 p95 レイテンシ、セッションあたりのコスト上限、「重い」セッションの想定割合。SLO がなければ本気のしきい値はありません。
トークン分布をサンプル： 実チャットとツール出力—平均だけでなく尾部も含めて。
3 階層をスケッチ： 軽／中／重のモデル ID と、軽階層に絶対に載せてはいけないタスク（例：多段ツール）。
modelRouting とテレメトリを配線： ヒット、見積もりトークン、最終モデルを構造化ログとメトリクス基盤へ。
制御付きカナリア： スライスで新旧を二重実行し、コストとレイテンシのパーセンタイルを見てから昇格。
ロールバックスイッチ： ルーティングが外れたときに「defaults＋短いフォールバック連鎖」へ戻すスナップショットを保持。
{
"agents": {
"defaults": {
"model": { "primary": "anthropic/claude-sonnet-4-5" },
"modelRouting": {
"enabled": true,
"strategy": "context-size",
"thresholds": [
{ "maxTokens": 4000, "model": "anthropic/claude-haiku-4-5", "description": "light" },
{ "maxTokens": 100000, "model": "anthropic/claude-sonnet-4-5", "description": "medium" },
{ "maxTokens": null, "model": "anthropic/claude-opus-4-5", "description": "xlarge context" }
],
"fallbackOnOverflow": true
}
}
}
}
注： ここでは 形と意味 を示しています。実際のキーと既定値は利用中の OpenClaw バージョンに合わせてください。設定を diff し、Gateway を上げる前に統合フィクスチャを回してください。
整理のための心の模型：defaults がプライマリと一般的なフォールバックを宣言し、modelRouting（バージョンに依存）が defaults と協調して コンテキストに基づく分割 を行い、フォールバック は依然として上流の失敗を処理します。ステージングでは次の 3 点を確認してください：健全な経路でモデルが振れないこと（振れるならしきい値が厳しすぎる）、ルーティング後のフォールバックが期待どおりであること、ログで ルートヒット と 失敗による差し替え が分かれること。
リモート計算では、Gateway を Linux VPS やコンテナに置き、重いツールチェーンや macOS 限定ステップを 専用リモート Mac 実行体へのキューで回す構成がよくあります。modelRouting は Gateway 内の推論だけを階層化し、マシン横断のスケジューリング（キュー／Runner の問題）を置き換えません。
1 つの Gateway にマルチテナントのエージェントがある場合は、テナントごとにルーティングプロファイルやキーを分けないと、重いテナントのコンテキスト見積もりが全員の水準を押し上げます。
警告： fallbackOnOverflow は「モデルにコンテキストが収まらない」場合の意味として扱い、「節約」のつまみではありません。誤用すると静かな切り捨てや隠れた再試行を招きます。
オンコールの早道として使ってください。見積もりトークンとプロバイダ請求が大きく食い違う場合は、ツール出力が見積もりから外れているか、ログがサンプリングで落ちているかを確認します。
fallbackOnOverflow の意味を再検証。容量保証のない使い捨てノート PC やホストで Gateway を動かすと、ルーティングが完璧でも p95 は崩れます。排他的で常時オンで契約可能な macOS 実行面がなければ、ツールチェーンやローカルビルドは自動化に抵抗します。OpenClaw を iOS／macOS ビルド、CI、エージェントと同一の 長寿命の本番 SLO に載せたいチームは、使い捨て環境より 専用リモート Mac ノード に重い実行を載せた方が早く安定します。ルーティング方針と実行体の経済性のバランスとして、NodeMini の Mac Mini クラウドレンタル は基盤になり得ます：Gateway では modelRouting で推論を階層化し、重いツールチェーンは専用ノードへ載せ、鍵とキャパシティをランブックに明記してください。
modelRouting は見積もりコンテキストに基づき上流呼び出しの前に階層化し、コストとレイテンシを最適化します。フォールバックは通常、失敗に反応します。併用は可能ですが境界を定義してください。ほかの OpenClaw 記事は カテゴリ絞り込み からどうぞ。
ステージングで実トランスクリプトをフィクスチャでリプレイし、ルートヒットを確認したうえでカナリアし、トークンとレイテンシのパーセンタイルを見ます。並列計算が必要なら、リモート Mac 実行ノード向けに 価格ページ でキャパシティを揃えてください。
それらはデーモンと公開を扱い、本文は Gateway 内のルーティングです。まずデプロイを安定させ、次に openclaw.json を締めます。接続と権限は ヘルプセンター を参照してください。