ルーティングとモデル選択：チャネル、モデル、クライアントの関係

AI ゲートウェイを使用する際、最も混同しやすいのが チャネル、モデル、クライアント という 3 つの概念です。これらの関係を理解しておけば、ルーティングを正しく設定でき、「なぜリクエストが期待したチャネル経由で処理されないのか」といった混乱を避けられます。

3 つの基本概念

これらの関係は次のような一方向のチェーンです。

クライアント →（仮想キー）→ ゲートウェイ（ルーティングポリシー）→ チャネル → モデル

リクエストのたびに、クライアントがリクエスト内でモデル名を指定します。ゲートウェイはそのモデル名をもとに、それを提供できるチャネルを見つけてリクエストを転送します。

Claude Code や opencode などのクライアントのモデルセレクターには、qwen3:8b (Ollama Qwen3) のような項目が表示されます。括弧内の名前はそのモデルの提供元チャネルを示すものであり、「もう 1 つの接続」ではありません。

クライアントとゲートウェイの間には常に 1 本の接続（1 つのアドレス + 1 つの仮想キー）しか存在しません。
同じモデルを複数のチャネルに設定することも可能です。この場合もセレクターには 1 行だけ表示され（括弧内には提供元チャネルのうち 1 つが表示されます）、各リクエストが実際にどのチャネルで処理されるかは、ルーティングポリシーによって決まります（後述）。

ルーティングポリシーが答える問いは、同じモデルを複数のチャネルが提供できるとき、どれを使うか？ です。

モード	動作	適したシーン
Fixed（固定）	常に同じチャネルを使用	チャネルの品質が安定しており、提供元を固定したい場合
Failover（プライマリ／バックアップ）	プライマリチャネルが失敗した、またはクォータが尽きた場合に、順番にバックアップチャネルへ切り替え	プライマリとバックアップを備えた構成
Balanced（分散）	利用可能なチャネル間でリクエストを順番に割り当て	同等の複数チャネルで負荷を分散したい場合

押さえておくべき重要なポイントが 2 つあります。

ルーティングで切り替わるのはチャネルだけで、モデルは切り替わりません。 どのモデルにリクエストするかは常にクライアント側で決定され、ゲートウェイがモデルを勝手に変更することはありません。
異なるモデルは、そもそもそれぞれ専用のチャネルを通ります。 Balanced が「今回は A チャネルのモデル、次は B チャネルのモデル」といった動作をすることはありません。あくまで同じモデルを提供する複数チャネルの間で順番に振り分けるだけです。

ゲートウェイが担当するのは転送だけです。ツールがリクエストごとにモデル名を送り、ゲートウェイはそれに従ってルーティングします。モデルの切り替えはクライアント側で行います。

opencode：TUI で /models と入力して選択します。または opencode.json で model（メインモデル）と small_model（タイトル生成などの軽量タスク用）を設定します。
Claude Code：/model コマンドで切り替えます。
Codex：-m <model> パラメータまたは設定ファイルで指定します。

日常の使用への影響が心配な方は、次の手順で進めてください。

まず重要度の低いプロジェクトで試す：重要でないプロジェクトディレクトリでワンクリック接続を完了し、ワークフローが正常に動作することを確認します。
テストリクエスト 1 件で検証：テストリクエストを送信し、「使用履歴」ページで、どのモデル・どのチャネルで処理され、どれだけのコストがかかったかを確認します。
いつでも元に戻せる：「接続管理」ページで引き継ぎを停止します。停止すると、ServBay が書き込んだ設定は削除され、引き継ぎで作成された仮想キーは失効します。以前のカスタム設定が自動的に復元されることはありませんので、必要に応じて手動で調整し、クライアントを再起動すると変更が反映されます。

チャネル = 上流への接続、モデル = チャネルが持つ能力、そしてモデル名はクライアントがリクエストごとに指定します。
ルーティングポリシーは「同じモデルを提供する複数チャネル」の間でのみ選択を行います。Fixed は固定、Failover はプライマリ／バックアップ、Balanced は順次振り分けです。
モデルの切り替えはクライアントのモデルセレクターで行い、各リクエストの処理先とコストは「使用履歴」ページで確認します。