9月3日、MarkTechPostが「Meet Switchyard: A Rust Proxy and Library That Routes and Translates LLM Traffic Across OpenAI and Anthropic APIs」と題した記事を公開した。エージェントのコードを一行も変えずにLLMバックエンドを切り替えられる——NVIDIAが公開したRust製プロキシ「Switchyard」の核心はこの一点に尽きる。OpenAIとAnthropicのAPIフォーマットを相互変換するレイヤーをプロキシ側に集約することで、クライアント側の改修を不要にする設計だ。
なぜ今、NVIDIAがこれを作ったのか
背景として押さえておきたいのは、SwitchyardがNVIDIAのNeMoエコシステムの一部として位置づけられているという点だ。NeMoはLLMの学習・推論・エージェント基盤を統合するNVIDIAのプラットフォームであり、SwitchyardはそのエージェントレイヤーとNIM（推論マイクロサービス）をつなぐ「のり」として機能する。
NVIDIA NIMはOpenAI互換のエンドポイントを提供するが、実際の現場ではAnthropicのMessages APIを前提としたClaude Codeのようなエージェントを使いたいケースが多い。また複数のモデルをコスト・品質で使い分けたいニーズも高まっている。NIMやオンプレ推論基盤への投資を活かしつつ、上位のエージェントツールをそのまま使えるようにするための実用的な接続層——それがSwitchyardの立ち位置だ。
SwitchyardはApache 2.0ライセンスで公開されており、公式ドキュメントはdocs.nvidia.com/nemo/switchyardで参照できる。
ただし、現時点はpre-alpha・実験的扱いであることは明記しておく必要がある。元記事および公式リポジトリのREADMEによれば、NVIDIAはプロダクション利用を明示的に禁じており、v1.0までにAPIもアルゴリズムも大きく変わる可能性がある。評価・検証用ツールとして扱うべき段階だ。
解決しようとしている問題
コーディングエージェントを運用するチームが直面する典型的な壁がある。Claude CodeはAnthropicのMessages APIを話し、Codex CLIはOpenAIのAPIを話す。一方、実際に使いたいモデルはvLLMやNVIDIA NIM、Ollamaの裏に座っている。エージェントのコードを書き直す選択肢はない。だから変換レイヤーはどこか別の場所に置くしかない。
Switchyardはその答えとしてNVIDIAが公開したOSSだ。OpenAIとAnthropicのAPIフォーマットを相互変換しながらリクエストをルーティングするRust製プロキシで、ライセンスはApache 2.0。
仕組みの核心：APIの「デカップリング」
Switchyardの設計思想はシンプルだ。クライアントは自身のネイティブAPIを変えない。Switchyardが受け取ったリクエストをプロバイダー中立なRust型にデコードし、ルーティングアルゴリズムでバックエンドを選択し、そのバックエンドのワイヤフォーマットに再エンコードして送る。レスポンス（ストリーミングイベントを含む）はクライアントが期待する形式に変換して返す。
サーバーが受け付けるインバウンドフォーマットは3つ：OpenAI Chat Completions、OpenAI Responses、Anthropic Messages。この3つはどれでも任意のルートに向けられる。エージェントのAPIとバックエンドのAPIが一致している必要はない、というのがポイントだ。
3つの起動方法
ランチャー経由（コーディングエージェント向け）は最も手軽だ：
uv tool install --python 3.12 "nemo-switchyard[cli]"
switchyard launch claude # Claude Code向け
switchyard launch codex # Codex CLI向け
switchyard launch openclaw
スタンドアロンサーバーはCargoで導入する：
cargo install --locked switchyard-server
--dry-runでコンフィグを検証してから起動できる。
ライブラリ（switchyard-libsy）はHTTPスタックを持たない。自前のRustアプリにルーティングアルゴリズムだけを組み込む用途で、モデル呼び出し自体はすべて呼び出し元に委ねる設計だ。
4種のルーティングアルゴリズム
ルートは「クライアントから見えるモデルID」＋「その裏のアルゴリズム」で構成される。
| アルゴリズム | 概要 |
|---|---|
passthrough |
全リクエストを1つのターゲットへ |
random |
重み付きでトラフィックを分散。シードで再現性も確保。A/Bや費用比較実験向け |
llm_classifier |
分類器モデルを呼んでルーティング先（strong/weak）を決定。escalationモードでは弱モデルで処理後、判定次第で強モデルに差し戻す |
stage_router |
直近ターンのツール結果・進捗シグナルをスコアリングして選択。分類器呼び出しコストを避けられる |
strong/weak/capable/efficientはモデルの固有属性ではなく、ルート内のロールだ。同じモデルが別のルートでは異なるロールを担える。
Prometheusメトリクスとルーティングオーバーヘッドの計測
GET /metricsでPrometheus形式のメトリクスを取得できる。リクエスト数、エラー、モデル呼び出しレイテンシ、プロンプト/補完/キャッシュトークン数など一通りのファミリーが揃う。
注目は**switchyard_routing_overhead_msだ。アルゴリズムの実行時間からリクエストを処理した呼び出しコストを引いた値を報告する。passthroughやrandomではサブミリ秒の値になり、llm_classifierでは分類器の呼び出し時間がここに現れる。バケットは0.1msスタート**と細かい。
ルーティングログは--routing-log-fileでJSON形式に出力でき、GET /v1/routing/session-statsでセッション単位の呼び出し・トークン集計も取れる。
設定ファイルの構造
TOMLで3層構造を取る：
- **
llm_clients**：ベースURL、ワイヤフォーマット、認証情報の環境変数名、リトライポリシー - **
targets**：1つのアップストリームモデルIDをクライアントに紐付け - **
routes**：クライアントから見えるモデルIDとアルゴリズムを定義
APIキーはファイルに直書きしない。api_key_envで環境変数名を指定する設計になっている。max_retriesのデフォルトは2で、タイムアウト・HTTP 408/429・5xxへのリトライに適用される。
詳細はMeet Switchyard: A Rust Proxy and Library That Routes and Translates LLM Traffic Across OpenAI and Anthropic APIsを参照していただきたい。
