オープンウェイトモデルで開発からビジネス利用まで回すチーム AI 環境
はじめに
こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。
チームで AI コーディングエージェントを使い始めると、コストとデータの扱いという 2 つの悩みがすぐに顔を出します。強いモデルに全部を任せると請求額が読みにくくなり、設定を野放しにすると、プロンプトに混ざった社内の情報がどこへ送られているのか誰も説明できなくなります。
この 2 つを「オープンウェイトモデル + 自動ルーティング + 漏らさない設定」の組み合わせで解決するチーム AI 環境を、社内開発チームで運用を検証しています。ルーター部分は Docker バンドルとして公開もしています。
構成の核は、opencode を NVIDIA の LLM ルーティング基盤 NeMo Switchyard 経由で Fireworks AI につなぎ、リクエストごとに「軽いモデルで足りるか」を判定して強いモデルと軽いモデルを自動で使い分けることです。先に結論を書いておくと、合成コーディングベンチ 52 run の実測で、タスク完遂率を落とさず、strong 固定なら $0.035/run のタスクを自動ルーティングは $0.0009/run で完走しました（判定コスト込み）。ベンチは軽いモデル単独でも満点が出る難度なので「軽いタスクを高いモデルに流さない」効果の数字ですが、削減の実額はトラフィックの中身で振れる変数だという実感も含めて、本文で正直に書いています。
Switchyard 自体の仕組みと導入手順は以下の記事で紹介しています。
この記事では、そのルーティングを土台にしたチーム環境の全体像を紹介します。どこに何を置くか、なぜ Fireworks か、モデルをどう 2 つに絞ったか、データを外に漏らさない設定、観測の現在地という設計判断の記録なので、チームに AI エージェントを配る立場の人に刺さるといいなと思っています。
チーム環境の全体像を 1 枚にまとめる
まず全体像です。開発者それぞれのローカルにルーターを置き、LLM は Fireworks のサーバレスに寄せる部分が現在の稼働範囲で、チーム共通の RAG と観測スタックを DGX Spark に載せる部分は検証を進めている段階です。
図の左半分、opencode から Switchyard を経由して Fireworks に抜ける経路がこの記事の主役です。Switchyard は各自のローカルに Docker コンテナとして常駐し、リクエストごとに「軽いモデルで完遂できる確率」を classifier で推定して、現在は強いモデル（Kimi K3）と軽いモデル（DeepSeek V4 Flash-0731）を自動で使い分けます。ルーターの実体は Switchyard の standalone Rust サーバー（switchyard-server）で、設定は routes.toml 1 ファイルです。
Claude Code の LLM トラフィックは Anthropic に直行し、Switchyard は通りません。ルーティングの対象はあくまでオープンウェイトモデルを使う opencode 側で、Claude Code とは観測レイヤ（NeMo Relay）だけを共有する構造です。
右半分のサービス層と推論層は、チーム共通のナレッジ基盤（RAG）とローカル LLM の置き場所です。このうち RAG は別記事として公開しているので、この記事では入口の紹介にとどめます。
置き場所は状態とキーで決めている
この構成を組むうえで最初に決めたのは、各コンポーネントを「共有サーバに置くか、各自のローカルに置くか」でした。判断軸は 2 つ、共有すべき状態を持つかどうかと、API キーを誰が持つかです。
| コンポーネント | 共有すべき状態 | API キー | 置き場所 |
|---|---|---|---|
| Switchyard ルーター | なし（ログは各自のローカル volume） | Fireworks（個人払い出し） | 各自ローカル（127.0.0.1） |
| web 検索 | なし | 検索 API（個人払い出し） | 各自ローカル（skill） |
| RAG（ベクタ DB 込み） | コーパスとインデックス | サーバ側に集約 | 常駐機（DGX Spark） |
| 観測（Tempo / Grafana） | トレース | 不要（受け側） | 常駐機（DGX Spark） |
ルーターを共有サーバにしない判断が、最初の分かれ道でした。Fireworks の API キーは個人単位で払い出されるため、これを共有プロキシに集約するとキーの帰属と課金の帰属が崩れます。ルーター自体はステートレスで、Docker コンテナ 1 つがラップトップに常駐しても負担になりません。それなら各自のローカルに置いて 127.0.0.1 にバインドするほうが、キーの管理も攻撃面も素直になります。配布は git リポジトリと docker compose up -d に乗せて、更新は git pull と restart で済む形にしました。ルーターの実装ごと変わる更新だけはイメージの再ビルドが必要で、Rust のコンパイルに初回 10〜20 分かかります（以降はキャッシュで数十秒です）。
逆に、RAG のベクタ DB や観測のトレースは、チームで 1 つの状態を共有してこそ意味があるデータです。こちらはキーをサーバ側に集約できることもあり、常駐機に置いています。
途中で web 検索だけは「チーム 1 契約の共有サーバに集約する」案も試したのですが、最終的には各自のローカルに戻しました。検索 API のキーは個人払い出しでも摩擦が小さく、サーバを消せるなら消したほうが運用が軽いためです。このとき整理した「消せるサーバがあるなら skill として配る、サーバが本質的に残るなら MCP で公開する」という線引きは、後の章で出てくる web 検索（skill）と RAG（MCP）の配布方式の違いにそのまま表れています。
なぜ Fireworks でオープンウェイトを動かすのか
LLM の調達先を Fireworks AI のサーバレスにした理由は 3 つあります。
1 つ目は鮮度です。オープンウェイトモデルの新版がリリース当日から serverless で使えます。実際、DeepSeek V4 Flash の公式版 0731 は 2026 年 7 月 31 日のリリース当日に掲載され、チームの weak tier をその週のうちに差し替えられました。マネージド系のクラウドサービスではオープンウェイトモデルの掲載が世代遅れになることも珍しくないため、鮮度重視の用途では効いてきます。
2 つ目はデータの扱いが契約レベルで確認できることです。Fireworks の DPA（Data Processing Addendum）4.3(f) は、プロンプトや入出力を含む Covered Data をモデルの学習・改善に使うことを契約条項として禁止しています。Zero Data Retention もデフォルトで有効で、プロンプトと生成結果はリクエスト処理中の揮発メモリにしか存在しません。Trust Center では SOC 2 Type II、ISO 27001:2022、AI マネジメントの ISO/IEC 42001:2023 などの認証も確認できます。チームで使う以上「入力が学習に使われない」ことをポリシーページの一文ではなく契約文書で確認できるかを重視しました。
3 つ目は従量課金です。GPU もコンテナも持たず、使ったトークン分だけ支払う形なので、後述するルーティングによる削減がそのまま請求額に反映されます。
一点、リージョンには注意が必要です。serverless はリージョン選択ができず、処理場所の契約上の保証もありません（インフラは US 中心）。国内処理やレイテンシの要件がある場合は、専有デプロイの on-demand で AP_TOKYO_1 / AP_TOKYO_2 を選ぶ形になります。
| 用途 | 提供形態 | リージョン | 課金 |
|---|---|---|---|
| 普段の開発（本環境の範囲） | serverless | 選択不可（US 中心） | トークン従量 |
| 国内処理・レイテンシ要件 | on-demand（専有） | AP_TOKYO_1/2 を選択可 | GPU 時間課金 |
自分たちの用途は公開情報とコードが中心のため、「普段の開発は serverless、要件が出たら on-demand Tokyo」という使い分けで整理しています。なお PCI・PHI に相当する情報は契約上も投入禁止なので、この線は設定より先に運用ルールとして引いています。
モデルはオープンウェイト 2 つに絞った
チームで使うモデルは、strong に Kimi K3、weak と classifier に DeepSeek V4 Flash-0731 の 2 つへ絞りました。Fireworks serverless の Standard tier 価格（100 万トークンあたり、2026-08 時点）と役割は次のとおりです。
| 役割 | モデル | input | cached input | output |
|---|---|---|---|---|
| strong | Kimi K3 | $3.00 | $0.30 | $15.00 |
| weak + classifier | DeepSeek V4 Flash-0731 | $0.14 | $0.028 | $0.28 |
| （参考）切替前の strong | DeepSeek V4 Pro | $1.74 | $0.145 | $3.48 |
weak と strong の単価差は input で 21 倍、output で 54 倍あります。この落差こそが自動ルーティングの原資で、軽いタスクを weak に流せた分だけ請求額が下がる構図です。
Flash-0731 は context 1M・function calling 対応で、エージェントループの生命線であるストリーミングの tool_call delta も検証済みです。ベンダー公表値では preview 版から agentic 系ベンチマークが大きく伸びており（Terminal Bench 61.8 → 82.7 など）、weak tier と classifier の 2 役を 1 モデルで安心して任せられる水準になっています。
もう 1 つ、このモデルは DGX Spark でローカルにも動かせることを確認済みです。llama.cpp での単機動作と、2 ノード vLLM 並列の両方を過去記事で検証しています。
クラウドの serverless とローカルの DGX Spark で同じオープンウェイトモデルが動くということは、将来ガバナンス要件やコスト構造が変わったときに、Switchyard の接続先を差し替えるだけでローカル推論へ逃がせるということです。オープンウェイトに寄せる価値は、この逃げ道の存在が大きいと考えています。
モデルを 2 つに絞った理由も書いておきます。候補を増やすほど「どれをいつ使うか」の説明コスト、検証の組み合わせ、価格改定の追跡が膨らみます。Switchyard のルーティングが strong / weak の 2 tier 構造であることもあり、チーム標準は 2 モデルに固定して、例外はルート単位のオプトイン（後述の auto-esc のような形）で逃がすのが運用としては一番回しやすい感触です。
strong を Kimi K3 に切り替えてみた
運用開始時の strong は DeepSeek V4 Pro でした。コーディングベンチでは満点で不満のない品質でしたが、深い設計相談やプランニングでは Kimi K3 の応答に分がある感触があり、まず k3-only というオプトインの固定ルートとして追加して個人で使い込んだ後、strong tier ごと K3 に切り替えました。
切り替え自体は設定ファイル routes.toml の 1 行です。書き換えて restart するだけで、イメージの再ビルドは要りません。classifier と weak は Flash-0731 のまま動かします。
[targets.strong]
id = "accounts/fireworks/models/kimi-k3" # ← deepseek-v4-pro から変更
ただし K3 は無料アップグレードではなく、明確にトレードです。運用済みベンチの実測トークンに K3 の単価を当てはめた事前試算では、strong 固定のコストは約 3.0 倍になる見立てでした。ルーティングは単価の梯子に対して働くため、strong が高価になるほど「weak に流せた分」の価値も膨らむ構図です。一方で事前の使い込みでは、壁打ち・戦略系の問いで思考トークンが長く出て実測コストが単価差以上に膨らむ（Pro 比 7.1 倍）、レイテンシも約 2.5 倍という特性も見えていたため、切替はベンチの再実測とセットで実施しています。
切替後の実測は、code_fix ×10 + tool_calls ×3 を 4 アームで計 52 run 回しました。アームには通常の auto に加えて、オプトインの auto-esc も並べています。全リクエストを weak で始めて、同じエラーの反復のような「詰みの軌跡」を検知したときだけセッションごと strong に昇格するモードです。昇格前は応答が全文まとめて返る制約があるため、cron のような非対話ワークロード向きです。
| アーム（code_fix、n=10） | 品質（pytest 採点・5 点満点） | コスト / run | strong 固定比 | wall 中央値 |
|---|---|---|---|---|
| strong 固定（Kimi K3） | 満点 | $0.0353 | — | 25.5 秒 |
| weak 固定（Flash-0731） | 満点 | $0.00066 | −98.1% | 8.7 秒 |
| auto（判定コスト込み） | 満点 | $0.00088 | −97.5% | 9.1 秒 |
| auto-esc（判定コスト込み） | 満点 | $0.0021 | −94.1% | 20.9 秒 |
52 run は全完走・全アーム満点で、tool calling 系（n=3）でも auto は約 9 割安く着地しています。code_fix の auto は 10 run すべて weak に落ち、Kimi K3 の呼び出しはゼロでした。注記を 2 つ添えると、このベンチは weak 単独でも満点が出る難度なので、この表は「軽いタスクを高いモデルに流さない」効果の証明です。また判定コールは同一内容の再判定スキップが効いてほとんど走っておらず、実運用の判定コストはこの表より上振れします。
この数字は最初から出ていたわけではありません。運用開始時（strong が V4 Pro）の実測は約 27% の削減、K3 切替直後はピン先が strong に全振れして削減がほぼ消えました。原因は K3 ではなく、同時期に差し替えていた判定モデル側の読み方の変化です。その後 Switchyard が判定方式を「タスクの複雑さ分類」から「weak が完遂できる確率の推定」へ刷新し、同じベンチ・同じモデルで上の表の数字になりました。この「判定の静かな変化」は、複数の判定モデルを横断した実験とあわせて別記事で深掘りする予定です。
チームへの展開は、これまでどおり配布リポジトリの PR とアナウンスで行っています。ルート ID（auto / strong-only / weak-only など）は構成の更新をまたいで温存しているため、メンバーの opencode 設定は無変更のままです。体感が合わない場合に備えて、strong-only 固定の逃げ道と revert 手順も添えています。
ルーティングに任せきれない領域は固定で逃がす
自動ルーティングは万能ではありません。運用してみて、classifier に任せきると取りこぼす領域が具体的にわかってきました。
現在の classifier は、既定では user メッセージの最初と最新だけを読んで「weak がこのタスクを完遂できる確率」を推定し、しきい値と比較して行き先を決めます。コードを書く・直すタスクはしきい値 0.75、壁打ちや戦略議論のようなコード外のタスクは判定ルールにマッチせず、一段厳しいしきい値が自動で適用されます。迷ったら strong に倒れる設計です。
実際に深い議論 13 問を本番と同じ判定パスで測ると、既定のしきい値 0.5 では 9 問しか strong に届きませんでしたが、0.75 への較正で 11〜12 問まで拾えるようになりました（境界の 1 問は実行ごとに揺れます）。それでも 1〜2 問は weak に落ちます。9 割前後は拾えても全部ではない、というのが自動判定の現在地です。
判定に見せる範囲そのものは設定で変えられます。ルートに recent_turn_window を足すと、最初のタスクに加えて直近 N 件の会話（アシスタントの応答やツール結果を含む）が判定材料に入ります。コード作業の実運用形状 40 件で窓を off / 2 / 4 / 8 と振って測った範囲では、行き先の判定はほとんど動かず、上に書いた取りこぼしがこれで直るわけではありませんでした。効いたのは別のところで、判定にかかる時間が中央値 17.5 秒から 3 秒前後へ、判定モデルの思考トークンが 1,713 から 227 へ落ちています。材料が足りないまま長考していた分が消えた形です。アームの順番を入れ替えても同じ結果になったので、配布設定にも recent_turn_window = 4 として取り込みました。
そこで、取りこぼしが許容できない領域はルーティングの外で固定しています。opencode の設定でモード・エージェント単位にモデルを割り当てる形です。
{
// 既定は自動ルーティング
"model": "switchyard/auto",
// タイトル生成などの補助コールは weak 固定
"small_model": "switchyard/weak-only",
"agent": {
// 深いプランニングは strong（Kimi K3）直結。classifier に判定させない
"plan": { "model": "switchyard/strong-only" },
// サブエージェントは呼び出し元のモデルを継承するため明示して断つ
"explore": { "model": "switchyard/weak-only" },
"scout": { "model": "switchyard/weak-only" }
}
}
この agent ブロックは配布バンドルの設定例で既定有効にしてあり、チームメンバーは設定を貼るだけで同じ線引きになります。
それぞれの意図を補足します。plan モードを strong 直結にしているのは、壁打ちは頻度が低く品質が支配的で、ルーティングで数円を節約する場面ではないためです。explore / scout への weak 明示は逆方向の防御で、opencode のサブエージェントは呼び出し元のモデルを継承するため、指定しないと grep 結果の読み取りのような単純作業にまで $15/1M の output 単価を払うことになります。small_model の weak 固定は実測起点で、タイトル生成のような補助コールが auto 経由で strong に流れていた記録があり、固定にしてから高単価への流出が消えました。
「自動に任せる範囲」と「固定で逃がす範囲」の線引きが見えてくると、ルーティングはかなり安心して使えるようになります。
strict-privacy と web 検索でデータを外に漏らさない
LLM の経路を Fireworks 1 点に収束させても、opencode には LLM 以外の外部送信経路が残っています。チーム配布の前に、ここを 1 つずつ潰しました。設定のベースは社内で整理されている opencode-with-strict-privacy の推奨構成で、バンドルにはこれとマージ済みの完成形 opencode.jsonc.example を同梱しています。
最初の課題は組み込みの websearch です。opencode 標準の web 検索は検索プロバイダ Exa のホステッド MCP に API キーなしの匿名接続でつながるため、企業契約（データ処理契約）の除外条項に乗らず、一般プライバシーポリシーが適用されます。そして Exa のポリシーには検索クエリを「モデルの training and fine-tuning に使う」ことが明記されており、オプトアウト機構がありません。コーディング中の検索クエリにはエラーメッセージや社内の文脈が混ざるので、ここは tools.websearch: false と permission.websearch: "deny" で無効化しています。あわせて会話の共有リンク生成（share）と自動アップデートも無効化しました。
次が、この章でいちばん伝えたい落とし穴です。opencode は Global の ~/.config/opencode/AGENTS.md が存在しない場合、互換フォールバックとして ~/.claude/CLAUDE.md をグローバルルールに読み込みます（公式仕様）。Claude Code を併用していると、Claude 向けに書いた個人設定やメモの内容が、opencode の接続先モデルへの全リクエストに注入されることになります。実際、自分の環境でもこのフォールバックが発動しており、Claude Code 用の個人設定がまるごと DeepSeek へのリクエストに同乗していました。設定ファイルをいくら固めても、ここは AGENTS.md を置かない限り閉じません。対処は最小の Global AGENTS.md を置くだけです。
mkdir -p ~/.config/opencode
cat > ~/.config/opencode/AGENTS.md <<'EOF'
# Global rules
- web 検索クエリには顧客名・社内プロジェクト名・未公開のコード名を含めない
EOF
もう 1 つの罠が設定のスコープです。プライバシー設定は必ず Global スコープ（~/.config/opencode/opencode.json）に置きます。プロジェクト側の opencode.json は Global を上書きするため、リポジトリごとの設定に引きずられて無効化が抜け落ちることがあります。.json と .jsonc の二重配置も片方しか読まれないので禁止です。さらに、無効化フラグの一部は設定ファイルではなく環境変数側にあります。
export OPENCODE_ENABLE_EXA=0 # Exa 検索を無効化
export OPENCODE_EXPERIMENTAL=0 # 実験機能を一括無効化
export OPENCODE_EXPERIMENTAL_EXA=0 # 旧 Exa フラグ（レガシー）
export OPENCODE_AUTO_SHARE=0 # 自動共有を無効化
環境変数は設定ファイルと別系統なので漏れやすく、実際に自分のメイン端末でも設定ファイル側だけ適用して rc 側が未設定だった期間がありました。チーム配布ではオンボーディング手順のチェックリストに env | grep OPENCODE_ を入れて、機械的に確認できるようにしています。
websearch を無効化した代わりの web 検索は、学習不使用を契約で確認できる検索 API を各自のキーで直接叩く skill として配っています。バックエンドは Gemini（Google AI Studio、無料枠あり）と OpenAI（Responses API の web_search）の 2 択で、選定条件は検索プロバイダの機能ではなく「クエリが学習に使われない契約になっているか」です。Gemini は課金有効な GCP プロジェクトで発行したキーが必須（free tier のキーは学習利用の対象）、OpenAI は API 既定で学習不使用という違いがあるため、ここだけはオンボーディング手順で飛ばさず読んでもらうようにしています。
ビジネス利用の入口はチーム共通 RAG
ここまでは開発者の入口の話でしたが、チーム AI 環境の価値はコーディングだけではありません。ドキュメントを横断して探す・要約する・引用つきで答えるといったビジネス利用の入口として、NVIDIA RAG Blueprint をベースにしたチーム共通 RAG を DGX Spark 上に構築しています。
詳細は上の記事（2026-08-07 公開）に譲りますが、この記事の文脈で押さえておきたいのは接続の形です。RAG は MCP サーバとして公開しており、開発者は opencode や Claude Code から、そのままチームのナレッジを引けます。エンジニア以外に向けては Web UI が入口になります。検索・生成のパイプラインは DGX Spark 上でローカル完結できることを検証済みなので、社内文書を入れる段階になっても「データが外に出ない」線を守れる設計です。
開発の入口は opencode + ルーティング、ナレッジの入口は RAG + MCP という 2 本立てが、この環境の全体像ということになります。
観測は 2 系統で回している
チーム環境は「配ったら終わり」ではなく、実際にどう使われて、いくらかかっているかを観測できて初めて改善が回ります。現在の観測は 2 系統です。
1 つ目は NVIDIA の NeMo Relay です。Claude Code や Codex CLI のエージェント実行（モデル呼び出し・ツール実行・サブエージェント分岐）を記録し、OpenTelemetry 形式で OTel Collector から Tempo / Grafana に流します。セットアップと注意点は以下の記事で紹介しています（2026-08-06 公開の記事です）。
Relay で 1 点だけ先に言っておくと、既定ではプロンプト本文が観測基盤側に届きます。チーム展開では first-party の pii-redaction プラグインで本文を落とし、ルーティングとコストの分析に必要なメタデータだけを残す構成を前提にしています。
2 つ目は Switchyard 自身のルーティングログです。各自のローカルで routing.jsonl にリクエスト単位の判定・モデル・トークン数が記録され（Docker の named volume なので設定変更やキーローテーションでも消えません）、週次のスナップショットスクリプトで回収してチーム分を集計します。ルート別の集計では、auto 経路の tier 分布に加えて、固定ルート利用分も pinned:kimi-k3 のような形で分離できるため、「自動と固定がそれぞれどれだけ使われたか」まで追えます。現在のサーバーでは判定コールも tier="classifier" の独立行として記録されるようになり、旧構成では推計でしか追えなかった判定コスト（実測で全体の約 8%）が週次集計にそのまま乗ります。あわせて Prometheus 形式の /metrics もあり、判定の fail-open 回数のようなヘルス指標も取れます。コストの突き合わせ先は Fireworks ダッシュボードのモデル別使用量です。strong と weak が別モデルなので、モデル別使用量がそのまま tier 分布とコストの内訳になります。
観測カバレッジの正直な現在地
観測の目標像は「全ハーネスを Relay に一本化」ですが、現在地はそこまで到達していません。経路ごとのカバレッジを正直に書くと次のとおりです。
| 経路 | NeMo Relay | Switchyard stats（routing.jsonl） | Fireworks ダッシュボード |
|---|---|---|---|
| Claude Code | ✅ | ❌（Anthropic 直行のため） | ❌ |
| Codex CLI | ✅ | ❌ | ❌ |
| opencode | ❌ | ✅ | ✅ |
肝心の opencode が Relay に載っていないのは、Relay 側の対応方式が理由です。opencode 向けの passive plugin 方式は 2026 年 6 月に見送りとなり、NVIDIA は wrapped execution 方式での opencode 対応を予告しています（NeMo Relay PR #73 のクローズコメント、2026-06-03）。Relay 本体は 2026 年 8 月に 0.7 系として正式リリースされました。Switchyard との統合は担い手が移っている最中で、Relay リポジトリにある実験的な連携例（Relay 側が Switchyard の判定 API を呼ぶ方式）は 0.8 で削除され、Switchyard が持つ native plugin に置き換わることがドキュメントに明記されています（NeMo Relay の Epic #401、Switchyard 側 PR #270）。対応が着地したら即検証してチーム展開し、一本化を完成させる方針です。
あわせて書いておくと、Switchyard 本体は 2026 年 8 月に standalone の Rust サーバー実装へ大きく再設計されたばかりで、成熟度表記も pre-alpha（"Not for production use"）です。パッケージレジストリへの公開もまだないため、バンドルはコミット SHA を固定して追従しています。上流の変化に付き合う覚悟込みの構成だという点は、これから試す方への注意事項です。
それまでの opencode は routing.jsonl と Fireworks ダッシュボードで代替観測しています。トレースの粒度では Relay に劣るものの、コストの実額に関してはむしろこの経路のほうが正確です。routing.jsonl はルーターがリクエスト単位で記録した一次データで、Fireworks のモデル別使用量は請求そのものだからです。観測の見た目は不揃いでも、「いくらかかったか」に答える力は落ちていない、というのが現在地の評価です。
まとめ
opencode を NeMo Switchyard 経由で Fireworks につなぎ、Kimi K3 と DeepSeek V4 Flash-0731 のオープンウェイト 2 モデルを自動ルーティングで使い分けるチーム AI 環境を紹介しました。合成ベンチではタスク完遂率を落とさずに strong 固定 $0.035/run のタスクを $0.0009/run で完走できた一方、判定モデルの更新で削減がほぼ消えた時期もありました。削減の効き方は環境の固定スペックではなく、構成とトラフィックで振れる「観測し続ける変数」だというのが運用しての実感です。ルーティングだけに頼らず、classifier に任せきれない領域はモード単位の固定で逃がし、strict-privacy 設定と AGENTS.md の配置でデータの出口を閉じ、routing.jsonl と Fireworks ダッシュボードで実額を観測する。この一式を git リポジトリからの配布に乗せたことが、チーム環境としての要点です。
正直な限界も書いておきます。品質評価に使った合成ベンチは weak 単独でも満点が出る難度で、「ルーティングが品質を守った」証明としては弱いままです。判定が走るターンには判定コールの待ちが乗りますし、トラフィックの中身しだいで削減の実額は大きく振れます。観測も opencode の Relay 対応待ちで 2 系統に分かれたままです。このあたりは実トラフィックの蓄積と上流の進展にあわせて更新していくつもりです。
チーム共通 RAG の構築編は公開済みなので、あわせて読んでいただけると全体像がつながるはずです。ルーターの新しい Rust 版サーバー実装の中身も、上流のリリースにあわせて別記事で取り上げる予定です。次は Hermes Agent をチームアシスタントとして載せて、Slack から自然文でナレッジを引ける入口を作るところを試したいと考えています。
参考リンク
- himorishige/switchyard-opencode-bundle — 本記事のルーター配布バンドル（Apache-2.0）
- NVIDIA-NeMo/Switchyard
- NVIDIA/NeMo-Relay
- cm-dyoshikawa/opencode-with-strict-privacy — opencode プライバシー設定の推奨構成
- Fireworks AI — Serverless Pricing
- Fireworks AI — Data Handling（Zero Data Retention）
- Fireworks AI — DPA（4.3(f) が学習利用の契約上の禁止条項）
- Kimi K3 on Fireworks
- DeepSeek-V4-Flash-0731（Hugging Face）
- NVIDIA の新しい LLM ルーティング基盤 NeMo Switchyard を試してみた（2026-07-03 公開、初期の Python 版ルーター時点。追記あり）
- NVIDIA RAG Blueprint × DGX Spark でチーム共通 RAG を組んで MCP でつないでみた（2026-08-07 公開）
- NeMo Relay first-touch（2026-08-06 公開）
- DeepSeek V4 Flash-0731 を llama.cpp で DGX Spark 1 台に載せてみた（2026-08-02 公開）
- DGX Spark 2 台で DeepSeek V4 Flash-DSpark を動かしてみた
