冒頭は記事のために生成したイメージ映像です。実機、実在施設、観測データを示すものではありません。
「結局、どのAIが一番賢いんですか？」
生成AIを仕事へ入れようとすると、かなりの確率でこの質問に辿り着く。
新しいモデルが出るたびにベンチマークを眺め、総合一位を探す。その一つを会社の標準にして、調査も、文章も、コードも、定型処理も、すべて任せる。
けれど、AI Agentが長い仕事を担うようになると、この選び方は少し窮屈になってくる。
配送会社が、最速の車を一台だけ買ったとしよう。
近所へ封筒を一通届ける時も、冷蔵品を運ぶ時も、引っ越し荷物を運ぶ時も、その一台を使う。たしかに速い。けれど、荷物によっては大きすぎるし、燃費も悪い。そもそも積めない荷物もある。
必要なのは、最速の一台ではない。
荷物を見て、いま空いている車と、目的地と、締切を考え、適切な一台を出す配車係だ。
2026年8月、NVIDIAが発表したNemotron 3.5 LightningとNeMo Switchyardは、まさにこの変化を象徴している。注目すべきは新しいAIモデルだけではない。複数のモデルへ仕事を振り分ける「配車係」が、同じ発表の主役になったことだ。
NVIDIAが出したのは、AIモデルと「配車係」だった
NVIDIAは2026年8月11日、Nemotron 3.5 Lightningを発表した。30BパラメータのMixture-of-Expertsモデルで、大量に繰り返すAgent処理や、tool利用、コードレビューなど、専門的な仕事を高速に回す用途を想定している。
同時に発表されたNeMo Switchyardは、OpenAI、Anthropic、open modelなど、異なる提供元のモデルへリクエストを振り分けるopen-sourceのrouting libraryだ。
NVIDIAが示した構図は分かりやすい。
難しい計画や判断は、能力の高いfrontier modelへ。すでに方針が決まった反復処理や、専門領域の定型作業は、軽くて速いmodelへ。途中でエラーが続けば、強いmodelへ戻す。
一つのモデルを買い替える話ではない。
一つの仕事を、複数の知性で運ぶ話だ。
NVIDIAは、Nemotron 3.5 Lightningについて同クラス比で最大4倍の出力速度、Agentのtask completionを30％高速化したと説明している。またSwitchyardについては、社内benchmarkでfrontier級の精度を維持しながら、Opus 4.8単独時の約3分の1までtask costを下げたとしている。
ただし、これらはNVIDIAによる提供値であり、すべての現場へそのまま当てはまる数字ではない。
発表内のLangChain事例では、145件のmulti-turn taskでコストを74％削減した一方、精度は6％下がった。ここは見逃せない。routingは「品質を一切落とさず、請求だけを消す魔法」ではない。何を優先し、どこまでの低下を許容するかを決める仕組みだ。
NVIDIA発表(2026年8月11日)の構図を編集的に整理。LangChain事例はNVIDIA提供値で独立検証ではない。 図を大きく開く
一つの依頼は、一回の推論ではなくなった
チャット欄へ質問し、回答を一つ受け取るだけなら、モデルを一つ選ぶ考え方でも困らない。
しかし、Agentへ「この機能を作って」「この市場を調べて」「この記事を公開できるところまで整えて」と頼むと、内部では性質の違う工程が連続する。
目的を理解し、計画を立てる。
資料やコードを広く探索する。
決められた形式へ整理する。
toolを使って変更する。
テストし、失敗原因を探す。
結果を検証し、全体へ統合する。
この全部で、同じ能力が必要なわけではない。
最初の設計や、行き詰まった時の回復には、広い視野と強い推論がいる。一方で、仕様が固まった後の抽出、整形、確認は、速いspecialistの方が気持ちよく進むこともある。
逆に、単純に見えた作業が、toolの失敗や予想外の依存関係で急に難しくなることもある。
だからroutingは、最初のpromptだけを見て「簡単」「難しい」と分類するだけでは足りない。
Switchyardのstage routerは、探索が続いているか、エラーが重なっているか、実際の書き込みが進んでいるかといった、作業途中の信号を使う。進んでいる時はefficient tierへ、迷走や回復が必要な時はcapable tierへ寄せる。
これは、仕事の難しさが最初から決まっているのではなく、進めてみて初めて分かることを前提にした設計だ。
NeMo Switchyardのstage router説明に基づく(NVIDIA公式、2026年8月)。 図を大きく開く
AIの配車で見るべき、四つの軸
model routingは、単なる「高いAIと安いAIの切り替え」ではない。
少なくとも、四つの軸を同時に見る必要がある。
1．精度──その仕事を、任せてよいか
法務、会計、公開前のfact check、設計方針の決定。失敗時の損失が大きい工程は、少し安いことより、正しく検証できることが優先される。
ただし、大きなmodelが常に正解するわけでもない。FrugalGPTの研究では、高価なmodelが誤り、安価なmodelが正答した例も示された。重要なのはmodelの格ではなく、その仕事に対する実測だ。
2．速度──待ち時間は、仕事のリズムを変える
思考を深く掘る一回と、百件の情報を整形する処理では、許される待ち時間が違う。
一回の回答が数秒速いだけでも、Agentが何十回もmodelを呼ぶと差は積み上がる。反対に、速さを優先して誤りが増え、後から人間が全部見直すなら、その「高速化」は借金になって返ってくる。
3．コスト──一回の単価ではなく、完了までを見る
安いmodelが三度失敗し、最後に高いmodelへやり直させたら、最初から強いmodelへ渡すより高くなることがある。
見るべきなのは一回のtoken単価ではない。再試行、tool call、router自身の判定、検証、人間の手直しまで含めたtask completion costだ。
4．continuity──賢さは、引き継げなければ消える
長い仕事では、過去に何を試し、なぜ採用し、どこで失敗したかが資産になる。
turnごとにmodelを変えれば、能力を最適化できるように見える。けれど、引き継ぐcontextが粗ければ、新しいmodelは同じ調査をやり直し、同じ失敗を繰り返す。
prompt cacheも無関係ではない。OpenAIの公式資料では、cache hitにはprompt前方のexact matchが必要で、instructions、tools、schema、shared contextを安定させることが推奨されている。providerやprompt構造を頻繁に変えると、安くしたかったroutingがcacheの利点を壊す可能性もある。
前の担当者が何を知っているか。
この問いは、人間のチームだけでなく、AIチームにも必要になる。
配車係にも、誤配車はある
routingの研究は、単一model固定より良い結果を出せる可能性を示してきた。
RouteLLMは、強いmodelと安いmodelをqueryごとに選ぶことで、公開benchmark上で品質を保ちながらcostを半分以下へ抑えられる条件を報告した。2026年のLLMRouterBenchでも、modelごとに数学、コード、論理などの得意分野が異なり、上位routerはBest Single modelより平均精度を最大4％上げたり、同等性能でcostを最大31.7％削減したりしている。
しかし、同じ研究はもう一つの現実も示している。
現在のrouterと、毎回正しいmodelを選べる仮想的なoracleの間には、まだ大きな差がある。正答できるmodelが少数しかない時に、そのmodelを選び損ねる「model-recall failure」も残る。
簡単に言えば、配車係も間違える。
簡単な仕事を高いmodelへ回す誤配車は、請求書を膨らませる。
難しい仕事を軽いmodelへ回す誤配車は、静かに品質を落とす。こちらの方が怖い。文章としては自然で、処理も完了したように見えるため、失敗に気づけないことがあるからだ。
さらに、providerを跨ぐと、同じAPI風に見えてもtool、structured output、reasoning state、context、cacheの仕様は揃っていない。OpenAIのAgents SDKも、複数providerを混在させる時にはfeature differencesを確認するよう案内している。
routerを一枚挟めばvendor lock-inが消える、というほど単純ではない。
routing policy、評価データ、prompt、tool schemaが一社固有の仕様へ寄れば、鍵を一つ増やしただけで、別の場所に新しい鍵穴を作ることになる。
なお、2026年9月28日時点でもSwitchyard自身のREADMEは「Pre-1.0 software」であることを明記しており、中核コンポーネントの一つswitchyard-serverは依然「Demo」段階でproduction use向けではないとしている（他コンポーネントはBeta/Alphaへ段階的に成熟中）。方向性は重要だが、成熟した完成品として扱う段階ではない。
最初から「賢いrouter」に、全部を任せない
では、複数modelを使いたい企業は、何から始めればよいのか。
私たちの推しは、deterministic firstだ。
最初からblack boxのAIへ「いい感じに振り分けて」と任せるのではなく、まず人間が説明できる単純なルールを作る。
仕事を工程へ分ける。
調査、計画、実装、検証、統合のように、成果物と失敗条件が違う単位へ切る。既定の行き先を決める。
すべてを最強modelへ送らず、定型処理には十分なmodelを置く。上位へ切り替える条件を明文化する。
重要判断、連続失敗、矛盾、公開前確認など、explicit triggerを決める。同じ成果を作り直さない。
検証済みの調査、生成物、tool resultはcacheし、成功済みの工程をむやみに再実行しない。observeしてから任せる。
最初はrouterの提案だけを記録し、実際の処理は信頼できる既定modelへ送る。誤配車を測ってから適用範囲を広げる。最後はtask単位で評価する。
token代だけでなく、完成率、所要時間、再試行、人間の修正、continuity lossを記録する。
OpenAIのAgents SDKも、LLMに自由な判断をさせるorchestrationと、codeで順番を決めるorchestrationを併用できるとしている。後者は速度、コスト、性能を予測しやすい。
すべてをAIへ決めさせることが、AI活用の完成形ではない。
決める価値のないところは自動化し、判断が必要なところへ知性を集める。
それが、routingの本当の役割だと思う。
AIチームには、監督と引き継ぎがいる
EDIFORCEでも、複数のAI modelやAgentを、仕事の性質に応じて使い分けている。
大きな目的と計画を持ち、成果を統合する役割。範囲を絞った調査や実装を担う役割。結果を疑い、根拠や動作へ戻す検証。そして、公開や外部への影響を最終的に引き受ける人間。
細かな運用手順は、私たちの仕事のレシピでもあるので、ここでは公開しない。
ただ、一つ確かに言えることがある。
modelを増やしただけでは、チームにはならない。
誰が目的を守るのか。誰が全体を見ているのか。何を渡せば次の担当が同じ場所から始められるのか。失敗した時、どこへ戻すのか。
この設計がなければ、優秀なmodelを何人並べても、それぞれが別方向へ走るだけだ。
最強の一人より、良い配車表
新しいAIが出るたびに、「前のmodelより何点賢くなったか」は、これからもニュースになる。
それ自体は大切だ。modelの基礎能力が上がれば、できる仕事は増える。
けれど、実務で問われるものは、もう一段先へ進んでいる。
この工程には、どの能力が必要か。
どこまで速くしてよいか。
どこでお金を使うべきか。
いつ強いmodelへ助けを求めるか。
そして、昨日まで積み重ねた文脈を、明日へどう渡すか。
AI時代の競争力は、「一番賢いAIを契約していること」から、「複数の知性を、一つの目的へ届けられること」へ移っていく。
最速の車を持っている会社が、荷物を最も上手に届けるとは限らない。
荷物を理解し、道を知り、事故が起きた時に別の車を出し、それでも目的地を見失わない。
最後に差を作るのは、良い配車係と、良い配車表なのだと思う。
一次資料・関連研究
注記：記事中のNVIDIA製品の性能値と導入事例は、2026年8月11日のNVIDIA公式発表に基づく提供値であり、独立した第三者検証の結果ではない。モデル、価格、API、routing softwareの仕様は変わるため、導入時には最新の公式資料と、自社workflowによる評価を確認してほしい。
