Claude Code は素晴らしいですが、複数のモデルが必要になると話が変わってきます。Anthropic でレート制限に当たり、長いコンテキストなら Gemini が欲しい、特定のタスクには GPT-4o が必要だといった場合です。デフォルトのセットアップではプロバイダーをまたいだルーティングの手段がありません。
私は Claude Code と LLM プロバイダーの間に入るゲートウェイを一週間テストしました。目標はシンプルでした。複数のモデルを設定し、ルーティングの重みを指定し、自動フェイルオーバーを実現し、Claude Code が通常どおり動き続けること。
Bifrost が明らかな勝者でした。オープンソースで Go で書かれており、リクエストあたりのオーバーヘッドは 11 マイクロ秒です。ここでは、マルチモデルのルーティングをどう設定したか、そして学んだことを紹介します。
なぜマルチモデルのルーティングが重要なのか
モデルによって得意分野が違います。Claude Sonnet はツール利用が得意です。GPT-4o は特定のコード生成タスクに強いです。Gemini 2.5 Pro は非常に大きなコンテキストウィンドウを扱えます。すべてを 1 つのモデルに任せると、パフォーマンスを取りこぼすことになります。
マルチモデルのルーティングにより、次が可能になります:
- 重みによってプロバイダー間でトラフィックを分割する
- プロバイダーがダウンしたときに自動的にフェイルオーバーする
- 特定のモデルを特定のタスクに固定する
- 単純な処理ではより安いモデルへルーティングしてコストを制御する
課題: Claude Code はデフォルトで api.anthropic.com に接続します。ネイティブのマルチモデル対応はありません。ゲートウェイが必要です。
セットアップ: Claude Code のゲートウェイとして Bifrost を使う
Bifrost は Anthropic と互換性のあるエンドポイントを公開します。Claude Code はゲートウェイが存在することを知りません。標準的なリクエストを送るだけで、Bifrost がそれを変換し、設定した任意のプロバイダーへルーティングします。
完全な Claude Code の統合ドキュメントはこちら。
インストールして接続する
npx -y @maximhq/bifrost
これでゲートウェイがローカルで起動します。セットアップガイドに詳細があります。
Claude Code を Bifrost に向けます:
export ANTHROPIC_BASE_URL=http://localhost:8080/anthropic
export ANTHROPIC_API_KEY=your-bifrost-virtual-key
ここでの ANTHROPIC_API_KEY は Bifrost の仮想キーであり、あなたの実際の Anthropic キーではありません。プロバイダーキーは Bifrost の設定に保存されます。これは Anthropic API の ドロップイン置換です。
以上です。すべての Claude Code のリクエストが今は Bifrost を経由します。
重み付けルーティング設定
これはマルチモデルルーティングの要です。プロバイダーに重みを割り当て、Bifrost がそれに応じてトラフィックを分配します。重みは自動的に 1.0 になるよう正規化されるため、任意の数値を使えます。
以下は GPT-4o と Claude Sonnet の間でトラフィックを分割する設定例です:
accounts:
- id: "dev-team"
providers:
- id: "openai-primary"
type: "openai"
api_key: "${OPENAI_API_KEY}"
model: "gpt-4o"
weight: 70
- id: "anthropic-secondary"
type: "anthropic"
api_key: "${ANTHROPIC_API_KEY}"
model: "claude-sonnet-4-20250514"
weight: 30
リクエストの 70% は GPT-4o、30% は Claude Sonnet に送られます。これを使うことで、手動で切り替えることなく、実際のコーディングセッションの中でプロバイダーごとの出力品質を比較できました。
ルーティングのドキュメントには、すべての設定オプションが説明されています。
重要な詳細: プロバイダー間のルーティングは自動では行われません。設定ファイル内で、それぞれのプロバイダーを明示的に設定する必要があります。Bifrost はルーティングルールを推測したり、推論したりしません。
自動フェイルオーバー
重み付けルーティングは便利です。自動 フェイルオーバー は必須です。プロバイダーが落ちます。レート制限に当たります。Claude Code のセッションがタスクの途中で壊れてほしくありません。
Bifrost は重みに基づいてプロバイダーを並べ替え、失敗した場合にリトライします。プライマリが失敗したら、次のプロバイダーがリクエストを引き継ぎます。
accounts:
- id: "dev-team"
providers:
- id: "openai-primary"
type: "openai"
api_key: "${OPENAI_API_KEY}"
model: "gpt-4o"
weight: 80
- id: "gemini-fallback"
type: "gemini"
api_key: "${GEMINI_API_KEY}"
model: "gemini-2.5-pro"
weight: 15
- id: "anthropic-fallback"
type: "anthropic"
api_key: "${ANTHROPIC_API_KEY}"
model: "claude-sonnet-4-20250514"
weight:5
OpenAIがダウンして、BifrostはGeminiでリトライします。Geminiが失敗したら、Anthropicにフォールバック。私のコーディングセッションは一度も中断されません。
Bedrock と Vertex AI のためのモデル固定
チームが AWS Bedrock または Google Vertex AI を使っている場合、特定のモデルを直接固定できます。
# Bedrock
export ANTHROPIC_DEFAULT_SONNET_MODEL="bedrock/global.anthropic.claude-sonnet-4-6"
# Vertex AI
export ANTHROPIC_DEFAULT_SONNET_MODEL="vertex/claude-sonnet-4-6"
また、--model フラグ、または Claude Code 内の /model コマンドで、セッション途中でもモデルを上書きできます。タスクの異なる部分ごとにモデルを切り替えたいときに便利です。足場作りは Sonnet から始め、難しい実装には GPT-4o に切り替えて、また戻します。ゲートウェイは、各プロバイダごとの翻訳レイヤーを処理します。
ここで重要になるのが Anthropic SDK との互換性 です。Bifrost は Anthropic のメッセージ形式との完全な互換性を維持しているため、モデルの固定や切り替えが、クライアント側の変更なしで機能します。
プロバイダ設定のドキュメント には、サポートされているすべてのプロバイダとモデル形式が一覧で示されています。
プロバイダ全体にわたる予算コントロール
すべてのトラフィックが 1 つのゲートウェイを経由するようになれば、コスト管理は簡単になります。Bifrost には 4 階層の 予算階層 があります。顧客、チーム、仮想キー、プロバイダ設定です。
budgets:
- level: "virtual_key"
id: "claude-code-dev"
limit: 200
period: "monthly"
上限を設定します。上限に達すると、リクエストはブロックされます。暴走した Claude Code セッションからの不意の請求はありません。
あらゆる設定済みプロバイダに対して、レート制限、アクセス制御、支出管理を行うのが ガバナンスレイヤー です。
すべてのプロバイダにわたる可観測性
Bifrost 経由のすべてのリクエストが記録されます。レイテンシ、トークン数、コスト、使用したプロバイダ、レスポンスのステータスです。 可観測性レイヤー により、すべてのプロバイダを一つの視点で確認できます。
これは特にマルチモデルのルーティングで有用です。どのプロバイダが各リクエストを処理したのかを正確に把握でき、モデル間でレスポンス時間を比較し、プロバイダごとのコストも追跡できます。私が GPT-4o と Claude Sonnet の間で 70/30 の重み付きルーティングを動かしていたとき、可観測性データは、実際のコーディングタスクにおいて各モデルがどう振る舞ったかを正確に示してくれました。レスポンス時間、トークン消費量、リクエストあたりのコストが、すべて一箇所にまとまっています。
中央集権化されたログがない場合は、複数のプロバイダのダッシュボードを確認し、どのモデルが何を処理したのか推測することになります。これは、Claude Code 経由で複数のプロバイダを毎日運用しているときには持続できません。
正直なトレードオフ
完璧なツールはありません。私が分かったのは次のとおりです：
OpenRouter のストリーミング制限。 OpenRouter は関数呼び出しの引数を適切にストリーミングできません。これにより、Claude Code におけるファイル操作の失敗が発生します。OpenRouter をプロバイダとして使う場合は、ツールの利用に関して問題が起きる可能性を見込んでください。
Anthropic 以外のモデル要件。 ルーティングする Anthropic 以外のモデルは、ツール利用をサポートしている必要があります。Claude Code は関数呼び出しに強く依存しています。適切なツールサポートがないモデルでは、ファイル操作、検索、その他のエージェントタスクが失敗します。
セルフホストのみ。 オープンソース版では、ゲートウェイを実行し、保守する必要があります。マネージドのクラウド提供はありません。つまり、監視、更新、デバッグはすべて自分たちで行うことになります。
新しいプロジェクト。 Bifrost のコミュニティは成長していますが、既存の古い代替手段よりまだ小さいです。ドキュメントはしっかりしていますが、エッジケースでは GitHub 上の課題を掘り下げる必要が出るかもしれません。
追加ホップ。 Claude Code とプロバイダの間にプロセスを追加することになります。11 マイクロ秒のオーバーヘッドは無視できるほど小さいですが、チェーンの中にもう一つ稼働要素が増えるのは事実です。
パフォーマンス
ベンチマークガイド に合わせてベンチマークを実行しました。結果は維持されました。ルーティングのオーバーヘッドは 11 マイクロ秒、単一インスタンスで 1 秒あたり 5,000 リクエストです。Go 実装は本当に効いています。私がテストした Python ベースのゲートウェイは、より大きな遅延を追加しました。
すべての LLM 呼び出しのクリティカルパスに入るゲートウェイでは、低いオーバーヘッドが重要です。
クイックスタート要約
# 1. Bifrost を開始
npx -y @maximhq/bifrost
# 2. bifrost.yaml でプロバイダを設定（重み付きルーティング + フェイルオーバー）
# 3. Claude Code を Bifrost に向ける
export ANTHROPIC_BASE_URL=http://localhost:8080/anthropic
export ANTHROPIC_API_KEY=your-bifrost-virtual-key
# 4. Claude Code は通常どおり使用
以上です。これで Claude Code のセッションは、フェイルオーバーと予算コントロールを自動的に行いながら、複数のモデルにルーティングされます。
実作業で Claude Code を動かしているなら、マルチモデルのルーティングは必須です。単一プロバイダの構成は、最悪のタイミングで壊れます。ルーティング、フェイルオーバー、コストコントロールを一箇所で処理するゲートウェイは、デバッグのための数時間と、想定外の支出で数千円（あるいはそれ以上）を節約します。
何か問題が起きたら、repo に Issue を作成してください。
