この記事の結論

NVIDIA NeMo Switchyardが9月22日に0.3.0を公開。Advisor Gateなどを追加した一方、旧Pythonサーバーを廃止した互換性のない更新です。16日のGuardrails 0.24.1にも触れます。

概要：Switchyard 0.3.0は破壊的な更新

NVIDIAは2026年9月22日、AIエージェントの要求を複数のモデルに振り分けるオープンソースのルーター「NeMo Switchyard」のv0.3.0をGitHubで公開しました。8月10日のv0.2.0以来、約6週間ぶりのリリースです。当サイトでは8月にSwitchyardの発表を紹介しましたが、今回はその後の大型更新にあたります。

リリースノートは冒頭で、ライブラリとPython CLIの利用者にとって互換性のない更新（breaking upgrade）であり、更新前に移行メモを確認するよう求めています。新機能として、強いモデルが実行役のモデルを見守る「Advisor Gate」、分類器と段階ルーターを組み合わせる「Composite routing」、あらかじめ用意された「Auto」プリセットなどが加わりました。

また9月16日には、エージェントの入出力に安全対策をかける「NeMo Guardrails」のv0.24.1も公開されました。こちらは不具合修正版で、安全性判定用のモデル「Nemotron 3.5 Content Safety」の応答を解析する処理が加わっています。NemoClawと組み合わせて複数モデルを使い分けている、または検討している日本の開発者は、両方の変更を確認しておく必要があります。

Switchyard 0.3.0の主な新機能

Advisor Gateは、作業を実行するモデルに、より強い「助言役」のモデルを組み合わせ、確認・承認・やり直しの判断を任せる仕組みです。セッションごとの確認回数の上限や、処理が止まったときのチェックポイントも設けられています。安いモデルに作業させつつ、重要な判断だけ強いモデルに見てもらう使い方を想定したものと読めます。

Composite routingは、LLMによる分類器と段階ルーター（Stage Router）を組み合わせる方式です。Autoプリセットは、能力重視と効率重視の段階構成を用意しています。新しいswitchyard-runnerはTOML形式の設定を読み込み、プロセス内でルーティングを実行します。NeMo RelayとLiteLLMとの連携は、ネイティブのルーティング経路を使うようになりました。

ほかに、サブエージェントごとのルーティング、振り分け先ごとのシステムプロンプトと推論の強さの指定、クライアントごとの期限設定が加わりました。ルーティングの結果は、選ばれたモデルの一覧と判断の根拠をRust、Python、ログ、OpenTelemetryで確認できます。

移行時の注意点：廃止された機能

今回いちばん注意が必要なのは、廃止された機能です。Pythonのswitchyardコマンド、switchyard serve、コーディングエージェント用のラッパー、YAML形式のルート定義、旧サーバー一式が削除されました。今後は単独のswitchyard-serverにTOML形式の設定で接続します。

Pythonパッケージの追加オプション[server]、[all]、[cli]、[tracing]、[affinity-redis]も無くなりました。設定項目ではsession_affinityがclassify_triggerに置き換わり、従来のセッション固定と同じ動きにするにはclassify_trigger = "new_session"を指定します。PythonはPython 3.10以上が必要です。

インストールは、Pythonのバインディングがpip install nemo-switchyard==0.3.0、単独サーバーがcargo install --locked switchyard-server --version 0.3.0です。リリースノートは、単独サーバーは引き続きデモ・評価用の部品であり、検証範囲はUbuntu 24.04のLinux x86_64のみと明記しています。本番の中核に据える段階ではない点に注意してください。

NeMo Guardrails 0.24.1：Nemotron 3.5の応答解析を修正

9月16日に公開されたNeMo Guardrails v0.24.1は、不具合修正と改善のためのパッチリリースです。変更点は4つで、ベンチマーク機能での同時接続数の測定の修正、コンテンツ安全性チェックでのNemotron 3.5 Content Safetyの応答の解析、IORailsの受け入れ制限時にサーバーが過負荷応答を返すようにする修正、組み合わせ設定でconfig.pyを読み込むようにする修正です。

このうち応答解析の修正は、安全性判定用のモデル「Nemotron 3.5 Content Safety」向けのものです。対応するプルリクエスト（#2370）によると、このモデルは従来の安全性判定モデル（Llama 3.1 NemoGuard 8B Content Safety）のようなJSONではなく、「User Safety: unsafe」のような「項目名: 値」の文字列で判定結果を返すため、JSONとして解析できず、専用の解析処理が追加されました。同じプルリクエストは、モデルに同梱されたチャットテンプレートを適用する推論サーバー（vLLMやSGLangなど）で動かすことを前提とし、テンプレートを適用しないサーバーでは動かないと注意しています。

NVIDIAのモデルページによると、Nemotron 3.5 Content SafetyはGoogleのGemma-3-4B-itをもとにNVIDIAが調整した小型モデルで、入力と応答が安全かどうかを判定する専用のモデルです。当サイトで紹介してきたエージェント用の汎用モデルNemotron 3.5 Lightningとは別のモデルなので、Lightningを使っているだけなら今回の修正は直接関係しません。

複数の設定を組み合わせて使っている場合にconfig.pyが読み込まれない問題も直っています。独自の処理をconfig.pyに書いている利用者は、更新後に意図どおり動くかを確認してください。

日本の利用者がやること

  1. Switchyardをswitchyard serveやYAMLのルート定義で動かしている場合、0.3.0にそのまま上げると動かなくなります。pipでバージョンを固定したうえで、検証環境でTOML設定と単独サーバーへの移行を試してください。
  2. コスト削減目的でSwitchyardを検討している場合、Advisor Gateは「作業は安いモデル、確認は強いモデル」という構成を試す手段になります。ただし単独サーバーはデモ・評価用とされているため、まずは評価用途にとどめるのが無難です。
  3. Guardrailsの安全性チェックにNemotron 3.5 Content Safetyを使う場合は、0.24.1以降に更新し、推論サーバーがモデルのチャットテンプレートを適用しているかを確かめたうえで、判定結果が期待どおりになるかを数件のテスト入力で確認してください。

いずれもGitHubのリリースノートに基づく内容で、当サイトでの実機検証結果ではありません。

出典