ルーティング実践

このガイドは動作するモデルプロバイダーがあり、少なくとも 1 ツールから OcHub 経由のリクエストが成功していることを前提にします。各例では 1 層だけを 追加し、ログで効果を確認します。

判定順序

1. クライアントの Anthropic Messages、OpenAI Chat、OpenAI Responses を識別。
2. アプリに接続されたモデルプロバイダーを取得。
3. クライアントモデルを最初に一致する例外へ照合。
4. 上流へ送るモデル名を決定。
5. 有効なインターフェースから候補を作成。
6. ネイティブを優先し、変換可能な代替を試行。
7. 推論パラメーターを変換または削除。
8. リクエストモデル、上流モデル、課金モデル、トークン、状態、レイテンシーを記録。

モデルプロバイダーの API アドレスには標準推論パスではなく上流の origin またはカスタム接頭辞を 入力します。最終 URL が https://api.example.com/v1/messages なら、通常は https://api.example.com と入力し、OcHub がパスを追加します。

モデル名の優先順位

インターフェースだけを固定しモデルを空にした例外は、デフォルトモデルを通過せず元モデルを 維持します。

パターンは claude-*、*-reasoning、gpt-*-mini のように * を使えます。最初に 一致したルールが使われるため、正確なモデルを広いパターンより前に置きます。

例 1：クライアントエイリアスを変換する

クライアントの claude-sonnet-current を上流の anthropic/claude-sonnet-4-6 へ送ります。

1. モデルプロバイダーを編集し「モデル例外」を開きます。
2. モデルまたはパターンに claude-sonnet-current。
3. 上流モデルに anthropic/claude-sonnet-4-6。
4. インターフェースは自動。
5. 保存してエイリアスでリクエスト。
6. 詳細のリクエストモデル、モデル、課金モデルを比較。

一部上流は変換後もクライアントエイリアスを返します。必要ならプロバイダー側ログも比較します。

例 2：Codex から Chat 専用上流を使う

1. Chat 上流の基点を /v1/chat/completions なしで入力します。
2. OpenAI Chatだけを有効にします。
3. モデルプロバイダーを Codex へ適用します。
4. 最初はモデル例外を追加せず、Responses → Chat 自動変換を使います。
5. Codex を再起動し、Responses 固有機能に依存しない短いリクエストを送ります。
6. 使用量で状態、モデル、出力を確認します。

通常リクエストは変換できますが：

• Codex のリモート圧縮は Responses 上流が必要。
• Responses 固有項目は削除されるか完全に変換できない場合がある。
• ツール呼び出し、構造化出力、推論は上流実装に依存。

後から Responses が追加されたら検出して有効にします。自動ルーティングがネイティブを優先します。

例 3：モデル系列ごとにインターフェースを固定

モデル名を維持し、プロトコルだけを固定します。特定終点だけでモデルが使える、資料が推奨する、 通常テキストは動くがツール呼び出しが失敗する場合に使います。

例外が参照するインターフェースは無効化できません。

例 4：上流が 1 モデルだけ

すべてを company-model-v2 へ送る場合：

デフォルトモデル：company-model-v2

同時に * 例外を追加する必要はありません。デフォルトは例外に一致しないすべてを処理します。

1 モデルの内部ゲートウェイやクライアント側モデルを変えられない場合に適します。モデル選択が 必要、誤記を発見したい、価格差が大きい場合には適しません。

例 5：モデルとインターフェースを同時変更

モデル変換と Messages → Chat を同時に行います。先に通常テキスト、次にツール呼び出しを 確認します。失敗時は一度インターフェースを自動へ戻してモデルを確認し、その後 Chat を固定します。

例 6：推論強度を統一する

自動の 4 予算は正の昇順にします。

1. 上流の最小、標準、最大を確認。
2. 低に有効な最小値。
3. 中、高、最大を制限内で増加。
4. 中を先に確認。
5. レイテンシー、出力、トークンを比較して調整。

高い予算は最初のトークンと請求トークンを増やす場合があります。

例 7：予備のモデルプロバイダーを準備する

OcHub が自動で選択・再試行するのは1 つのモデルプロバイダー内の有効インターフェースです。 別のモデルプロバイダーのカードへの移動は自動ではありません。

1. 主系と予備を作成。
2. 両方で検出と実リクエストを確認。
3. 同等のエイリアスを設定。
4. 通常は主系へ接続。
5. 障害時にアプリページから予備へ手動切り替え。
6. 短いリクエストとログを確認。
7. 復旧後に戻す。

障害中にプロトコル、マッピング、予算、価格を同時変更せず、まず利用可能な経路を復元します。

リクエストログで確認する

毎回 1 変数だけを変え、識別しやすい短いプロンプトを使います。

診断表

ルール安定後、他ツールへ 1 つずつ適用し、各プロトコルで実リクエストを確認します。