オープンウェイトモデルで開発からビジネス利用まで回すチーム AI 環境

はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。

チームで AI コーディングエージェントを使い始めると、コストとデータの扱いという 2 つの悩みがすぐに顔を出します。強いモデルに全部を任せると請求額が読みにくくなり、設定を野放しにすると、プロンプトに混ざった社内の情報がどこへ送られているのか誰も説明できなくなります。

この 2 つを「オープンウェイトモデル + 自動ルーティング + 漏らさない設定」の組み合わせで解決するチーム AI 環境を、社内開発チームで運用を検証しています。ルーター部分は Docker バンドルとして公開もしています。

https://github.com/himorishige/switchyard-opencode-bundle

構成の核は、opencode を NVIDIA の LLM ルーティング基盤 NeMo Switchyard 経由で Fireworks AI につなぎ、タスクの複雑さに応じて強いモデルと軽いモデルを自動で使い分けることです。先に結論を書いておくと、合成コーディングベンチ 39 run の実測で、タスク完遂率を落とさずに strong 固定比で約 27% のコスト削減（classifier コスト込み、strong が DeepSeek V4 Pro、weak が DeepSeek V4 Flash preview だった時点の数字）でした。代償はレイテンシで、ルーティングの分だけ応答は延びます（wall 中央値 30 秒 vs 21 秒）。

Switchyard 自体の仕組みと導入手順は以下の記事で紹介しています（2026-07-03 公開、2026-08-05 にこのチーム環境の実測を追記した記事です）。

https://dev.classmethod.jp/articles/nvidia-nemo-switchyard-first-touch/

この記事では、そのルーティングを土台にしたチーム環境の全体像を紹介します。どこに何を置くか、なぜ Fireworks か、モデルをどう 2 つに絞ったか、データを外に漏らさない設定、観測の現在地という設計判断の記録なので、チームに AI エージェントを配る立場の人に刺さるといいなと思っています。

チーム環境の全体像を 1 枚にまとめる

まず全体像です。開発者それぞれのローカルにルーターを置き、LLM は Fireworks のサーバレスに寄せる部分が現在の稼働範囲で、チーム共通の RAG と観測スタックを DGX Spark に載せる部分は検証を進めている段階です。

図の左半分、opencode から Switchyard を経由して Fireworks に抜ける経路がこの記事の主役です。Switchyard は各自のローカルに Docker コンテナとして常駐し、リクエストごとにタスクの複雑さを classifier で判定して、現在は強いモデル（Kimi K3）と軽いモデル（DeepSeek V4 Flash-0731）を自動で使い分けます。

Claude Code の LLM トラフィックは Anthropic に直行し、Switchyard は通りません。ルーティングの対象はあくまでオープンウェイトモデルを使う opencode 側で、Claude Code とは観測レイヤ（NeMo Relay）だけを共有する構造です。

右半分のサービス層と推論層は、チーム共通のナレッジ基盤（RAG）とローカル LLM の置き場所です。このうち RAG は別記事として公開しているので、この記事では入口の紹介にとどめます。

https://dev.classmethod.jp/articles/dgx-spark-nvidia-rag-blueprint-mcp/

置き場所は状態とキーで決めている

この構成を組むうえで最初に決めたのは、各コンポーネントを「共有サーバに置くか、各自のローカルに置くか」でした。判断軸は 2 つ、共有すべき状態を持つかどうかと、API キーを誰が持つかです。

ルーターを共有サーバにしない判断が、最初の分かれ道でした。Fireworks の API キーは個人単位で払い出されるため、これを共有プロキシに集約するとキーの帰属と課金の帰属が崩れます。ルーター自体はステートレスで、Docker コンテナ 1 つがラップトップに常駐しても負担になりません。それなら各自のローカルに置いて 127.0.0.1 にバインドするほうが、キーの管理も攻撃面も素直になります。配布は git リポジトリと docker compose up -d に乗せて、更新は git pull と restart で済む形にしました。

逆に、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、要件が出たら on-demand Tokyo」という使い分けで整理しています。なお PCI・PHI に相当する情報は契約上も投入禁止なので、この線は設定より先に運用ルールとして引いています。

モデルはオープンウェイト 2 つに絞った

チームで使うモデルは、strong に Kimi K3、weak と classifier に DeepSeek V4 Flash-0731 の 2 つへ絞りました。Fireworks serverless の Standard tier 価格（100 万トークンあたり、2026-08 時点）と役割は次のとおりです。

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 並列の両方を過去記事で検証しています。

https://dev.classmethod.jp/articles/dgx-spark-deepseek-v4-flash-0731-llama-cpp/

https://dev.classmethod.jp/articles/dgx-spark-2node-deepseek-v4-flash-dspark/

クラウドの serverless とローカルの DGX Spark で同じオープンウェイトモデルが動くということは、将来ガバナンス要件やコスト構造が変わったときに、Switchyard の接続先を差し替えるだけでローカル推論へ逃がせるということです。オープンウェイトに寄せる価値は、この逃げ道の存在が大きいと考えています。

モデルを 2 つに絞った理由も書いておきます。候補を増やすほど「どれをいつ使うか」の説明コスト、検証の組み合わせ、価格改定の追跡が膨らみます。Switchyard のルーティングが strong / weak の 2 tier 構造であることもあり、チーム標準は 2 モデルに固定して、例外はルート単位のオプトイン（後述の k3-only のような形）で逃がすのが運用としては一番回しやすい感触です。

strong を Kimi K3 に切り替えてみた

運用開始時の strong は DeepSeek V4 Pro でした。コーディングベンチでは満点で不満のない品質でしたが、深い設計相談やプランニングでは Kimi K3 の応答に分がある感触があり、まず k3-only というオプトインの固定ルートとして追加して個人で使い込んだ後、strong tier ごと K3 に切り替えました。

切り替え自体は route.yaml の 2 箇所を書き換えるだけです。classifier と weak は Flash-0731 のまま動かします。

routes:
  auto:
    strong:
      model: accounts/fireworks/models/kimi-k3 # ← deepseek-v4-pro から変更
  strong-only:
    type: model
    target: accounts/fireworks/models/kimi-k3 # ← 同上

ただし K3 は無料アップグレードではなく、明確にトレードです。運用済みベンチの実測トークンに K3 の単価を当てはめた事前試算では、strong 固定・auto ともコストは約 3.0 倍になる一方、auto の削減率はほぼ変わらない見立てでした。ルーティングは単価の梯子に対して働くため、strong が高価になるほど「weak に流せた分」の価値も膨らむ構図です。一方で事前の使い込みでは、壁打ち・戦略系の問いで思考トークンが長く出て実測コストが単価差以上に膨らむ（Pro 比 7.1 倍）、レイテンシも約 2.5 倍という特性も見えていたため、切替はベンチの再実測とセットで実施しています。

切替後に同じベンチ（code_fix ×10 + tool_calls ×3 を 3 アームで計 39 run）を再実走した結果が次の表です。品質と信頼性は切替前と変わらず、39 run 全完走・失敗ゼロ・全アーム満点でした。

strong 固定側は 3.7 倍と、試算の 3.0 倍に近い上振れで収まりました。想定が外れたのは auto 側です。この回は code_fix のピン先が 10 run すべて strong に振れ、classifier 込みで strong 固定とほぼ同額になりました。判定コールだけを条件分離して再実行して調べたところ、原因は K3 の応答文ではなく、K3 と同じ時期に差し替えていた classifier 側のモデル更新（V4 Flash preview → 0731）で、会話 transcript への判定傾向が strong 寄りに変わっていたことでした。単発プロンプトでの較正では両版の判定が一致していたため、差し替え時には気づけなかった形です。判定プロンプトを較正し直して配布バンドルに反映し、実際のエージェントループ形状の判定で weak 側への復帰を確認しています。

一方、tool calling 系のタスク（n=3）では auto が strong 固定比で約 4 割安く着地しており、weak に流れれば削減はきちんと出ています。削減率は固定の性質ではなく「ピン分布次第でゼロから 4 割超まで振れる変数」であり、単発ベンチの数字を実運用の約束として掲げるのは危険だというのが、この切替でのいちばんの教訓です。実運用でどこに落ち着くかは、チームの実トラフィックを継続して計測しながら見極めていく予定です。

チームへの展開は、これまでどおり配布リポジトリの PR とアナウンスで行い、体感が合わない場合に備えて revert 手順（git pull で route.yaml を戻して restart）も添えています。

ルーティングで救えない領域は固定で逃がす

自動ルーティングは万能ではありません。運用してみて、classifier に任せてはいけない領域が具体的にわかってきました。

Switchyard の coding_agent プリセットは、コード変更の範囲・ツール呼び出し数・コードベース文脈の要否といった「コード作業の軸」でタスクの複雑さを判定します。このため、ビジネス的な深い議論やアーキテクチャの壁打ちは「コードを触らない、ツールも要らない」と読まれて、軽いタスク側へ倒れることがあります。

実際に戦略・プランニング系を含む 17 問を本番と同じ判定パスで測ったところ、深い議論 13 問のうち 11 問は strong に届いた一方、外れた 2 問は confidence 0.95 という高い確信度で「単純」と誤判定されていました。正解した 11 問の confidence が 0.70〜0.85 だったのと逆転しています。正解ほど迷い、誤りほど自信があるパターンなので、確信度のしきい値（min_confidence）をどう調整しても、この 2 問は救えません。

そこで、classifier が構造的に苦手な領域はルーティングの外で固定しています。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 上に構築しています。

https://dev.classmethod.jp/articles/dgx-spark-nvidia-rag-blueprint-mcp/

詳細は上の記事（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 公開の記事です）。

https://dev.classmethod.jp/articles/nvidia-nemo-relay-first-touch/

Relay で 1 点だけ先に言っておくと、既定ではプロンプト本文が観測基盤側に届きます。チーム展開では first-party の pii-redaction プラグインで本文を落とし、ルーティングとコストの分析に必要なメタデータだけを残す構成を前提にしています。

2 つ目は Switchyard 自身のルーティングログです。各自のローカルで routing.jsonl にリクエスト単位の判定・モデル・トークン数が記録され（Docker の named volume なので設定変更やキーローテーションでも消えません）、週次のスナップショットスクリプトで回収してチーム分を集計します。ルート別の集計では、auto 経路の tier 分布に加えて、固定ルート利用分も pinned:kimi-k3 のような形で分離できるため、「自動と固定がそれぞれどれだけ使われたか」まで追えます。コストの突き合わせ先は Fireworks ダッシュボードのモデル別使用量です。strong と weak が別モデルなので、モデル別使用量がそのまま tier 分布とコストの内訳になります。

観測カバレッジの正直な現在地

観測の目標像は「全ハーネスを Relay に一本化」ですが、現在地はそこまで到達していません。経路ごとのカバレッジを正直に書くと次のとおりです。

肝心の 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 との native plugin 統合も進行中（NeMo Relay の Epic #401、Switchyard 側 PR #270）なので、対応が着地したら即検証してチーム展開し、一本化を完成させる方針です。

それまでの opencode は routing.jsonl と Fireworks ダッシュボードで代替観測しています。トレースの粒度では Relay に劣るものの、コストの実額に関してはむしろこの経路のほうが正確です。routing.jsonl はルーターがリクエスト単位で記録した一次データで、Fireworks のモデル別使用量は請求そのものだからです。観測の見た目は不揃いでも、「いくらかかったか」に答える力は落ちていない、というのが現在地の評価です。

まとめ

opencode を NeMo Switchyard 経由で Fireworks につなぎ、Kimi K3 と DeepSeek V4 Flash-0731 のオープンウェイト 2 モデルを自動ルーティングで使い分けるチーム AI 環境を紹介しました。切替前の合成ベンチではタスク完遂率を落とさずに約 27% のコスト削減（classifier 込み）が出た一方、strong を K3 に切り替えた再実測ではピン先の分布が変わって削減がほぼ出ない回もありました。削減率は環境の固定スペックではなく、構成とトラフィックで振れる「観測し続ける変数」だというのが運用しての実感です。ルーティングだけに頼らず、classifier が苦手な領域はモード単位の固定で逃がし、strict-privacy 設定と AGENTS.md の配置でデータの出口を閉じ、routing.jsonl と Fireworks ダッシュボードで実額を観測する。この一式を git リポジトリからの配布に乗せたことが、チーム環境としての要点です。

正直な限界も書いておきます。品質評価に使った合成ベンチは weak 単独でも満点が出る難度で、「ルーティングが品質を守った」証明としては弱いままです。レイテンシはルーティング分だけ延びますし、同じタスクでもセッションによって strong と weak のどちらにピンされるかが割れるため、削減率には分散があります。観測も opencode の Relay 対応待ちで 2 系統に分かれたままです。このあたりは実トラフィックの蓄積と上流の進展にあわせて更新していくつもりです。

チーム共通 RAG の構築編は公開済みなので、あわせて読んでいただけると全体像がつながるはずです。次は 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 公開）
• 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 を動かしてみた