Claude Codeが自分でモデルを選ぶ時代へ。JevでHaiku・Sonnet・Opusを自動振り分けする仕組みが出てきた
Jevを追い始めて、かなり面白い変化が起きています。
これまでの記事では、
Jevとは何か。
Claude Codeと組み合わせるとどうなるのか。
Jevの実力。
弱点。
日本語性能。
まで見てきました。
そして次に出てきたのが、
「どのAIモデルを使うかを、Jevに決めさせる」
という使い方です。
たとえばClaude Codeには、
軽い作業を高速にこなすモデル。
普段使いに向くモデル。
難しい問題を深く考えるモデル。
と複数の選択肢があります。
普通なら人間が、
「今回はHaikuでいいかな」
「これはSonnet」
「これは難しいからOpus」
と選びます。
でももし、
その判断自体をJevが自動化したら？
今日は、そこまで実装されたプロジェクトが出てきています。
そもそも毎回Opusを使う必要はあるのか？
Claude Codeを使っていると、作業の難易度は毎回違います。
例えば、
「READMEの誤字を直して」
と、
「巨大なコードベースを調査してアーキテクチャを再設計して」
では必要な能力が全然違います。
Anthropic自身も、Claude Codeのモデル選択について、
Haikuは高速で簡単な編集や検索向き。
Sonnetは大部分のコーディング作業に適したバランス型。
Opusは難しいデバッグ、大規模リファクタ、アーキテクチャ判断などの複雑な仕事向き、
という使い分けを案内しています。
つまり本来、
仕事によってモデルを変えたほうが合理的
なんです。
ただし問題があります。
毎回人間が判断するのは面倒。
そこで出てくるのがJevです。
Jevに「この仕事、どのモデルが必要？」と聞く
GitHubで公開されている「jev-router」（gargpratyush/jev-router。同じ名前のリポジトリがほかにもあります）は、この考え方をそのまま実装しています。
Claude CodeやOpenAI Codexへ入力された新しい依頼をJevが先に見て、
Fast
Balanced
Strong
Long
のような抽象的な難易度へ分類します。
その結果に応じて、実際に使うモデルを切り替える仕組みです。
イメージするとこうです。
ユーザー
↓
「このテストだけ直して」
↓
Jev
↓
簡単
↓
高速モデル
別の依頼なら、
ユーザー
↓
「このシステム全体の設計問題を調査して」
↓
Jev
↓
難しい
↓
高性能モデル
になる。
つまり、
AIを使う前に、AIが仕事の難易度を判断する。
かなり面白い構造です。
「AIがAIを選ぶ」時代が始まっている
これまでは、
人間
↓
Claude
でした。
そこにJevを入れると、
人間
↓
Jev
↓
適切なClaude
↓
実行
になります。
さらに将来的には、
Jev
↓
Claude
Jev
↓
GPT
Jev
↓
小型モデル
Jev
↓
検索システム
Jev
↓
普通のコード
のように、
仕事内容によって処理先そのものを変える
こともできます。
これが「モデルルーティング」です。
そして個人的には、Jevの本命用途の一つはここではないかと思っています。
今日、日本でも40回の実装テストが出た
ちょうど2026年9月18日、日本でもかなり興味深い検証が公開されました。
クラスメソッドのDevelopersIOで、
NVIDIAのLLMルーティング基盤「NeMo Switchyard」にJevをclassifierとして実際に組み込む実装が公開されています。
テストでは、
simple
medium
complex
reasoning
という4種類の仕事を用意。
それぞれ10回。
合計、
40回
Jevにモデルティアを分類させています。
結果は、
40/40で期待したティアと一致。
報告された中央値は、
simple：0.265秒
medium：0.278秒
complex：0.254秒
reasoning：0.282秒
でした。
まだ40件なので巨大なベンチマークではありません。
でも重要なのは、
Jevを「モデルを選ぶAI」として実際のルーティング基盤に組み込む実装が動いた
ということです。
ただし、Switchyard 本体への取り込みは、9月19日時点ではまだ PR が出ている段階です。
なぜJevがルーターに向いているのか
モデルルーティング自体は新しい考え方ではありません。
これまでも、
「この質問は簡単か？」
を別のLLMに判定させ、
小型モデル。
大型モデル。
へ振り分ける方法はありました。
しかしここには少し変な問題があります。
高価なAIを使うか節約するか決めるために、
別の高価なAIへ毎回相談する。
これではルーター自身が重くなります。
Jevは、
文章を書かない。
長い推論を生成しない。
Choiceとして候補を選択する。
ここに特化しています。
だから、
「simple / medium / complex / reasoningのどれ？」
という仕事と相性がいい。
今回のSwitchyard実装でも、
TypeSafe単体についてIssue内に記載された比較では、
Jev：平均281ms
GPT-5.6 Sol：平均1,653ms
という数字が紹介されています。
双方10/10だった小規模テストでの値なので一般化はできませんが、ルーターそのものを軽くするというJevの狙いは分かりやすいです。
Claude Code用のルーターまで、すでに作られている
さらに面白いのが、
jev-router
です。
これはNeMo Switchyardのようなサーバー基盤だけではありません。
Claude CodeやCodexを普段使っている人向けに、
そのままモデル自動選択を追加しようとするOSSです。
Claude Codeなら、
jev-claude
Codexなら、
jev-codex
として起動。
普段のClaude CodeやCodexの操作感を残したまま、各ターンの最初にJevがモデルを選択します。
面白いのは、
ツール。
セッション。
権限設定。
/resume
などをなるべくそのまま維持し、
モデル選択部分だけJevに差し込む
設計になっていることです。
これはかなり実用的な考え方です。
例えばこんな使い方になる
朝、Claude Codeを開く。
最初の依頼。
「このファイルの文言を変更して」
Jev：
Fastで十分。
高速モデルへ。
次。
「このエラーの原因を調べて修正して」
Jev：
Balanced。
Sonnet系へ。
次。
「既存システム全体を調査して、安全にモジュール分割する移行計画を作って」
Jev：
Strong。
Opus系へ。
人間はモデルを意識しなくなる。
ただ、
やりたい仕事だけ伝える。
裏側でJevが適切な頭脳を選ぶ。
この世界です。
ただし「自動で安いモデルにすればいい」ではない
ここで重要なのがconfidenceです。
例えばJevが、
Fast 51%
Balanced 47%
Strong 2%
みたいな判断を出したとします。
この状態で、
「Fastが1位だからFast！」
と切り替えるのは少し危険です。
jev-routerでは、低confidenceの場合に安易なダウングレードを避けるルールが用意されています。
Jev側で問題が起きた場合も、現在のモデルを維持するフォールバックがあります。
Switchyard側の実装も同じ思想です。
confidenceが設定されたthresholdを下回った場合、
Jevの判断を採用せず、
デフォルトの分類へフォールバックします。
つまり、
Jevに全部決めさせるのではない。
自信があるときだけJevの判断を使う。
ここでもJevらしい設計が出てきます。
これは「コスト削減ツール」だけではない
最初にモデルルーティングを見ると、
「高いモデルを使う回数を減らして節約する仕組み」
に見えます。
もちろんそれもあります。
でも、自分はもっと大きい可能性があると思っています。
例えば会社に、
文章を書くAI。
プログラムを書くAI。
画像を作るAI。
データを調べるAI。
経理AI。
営業AI。
法務チェックAI。
がいたとします。
仕事が入るたびに、
誰へ渡すのかを人間が選んでいたら、
AI社員が100体いても管理が大変です。
そこでJevが、
「この仕事は誰に渡す？」
だけ担当する。
つまり、
Jev自体が仕事をするのではなく、
仕事を適切なAIへ配るAI
になる。
会社で言えば、
受付。
ディスパッチャー。
管理職。
司令塔。
に近い存在です。
Jevは「AI社員」より「AI管理職」に近い？
これまで自分はJevを、
判断専用AI
として見てきました。
でも最近の実装を見ていると、少し見え方が変わってきました。
Jev自身に記事を書かせる必要はない。
Jev自身にコードを書かせる必要もない。
Jev自身に調査させる必要もない。
むしろ、
「誰にやらせる？」
「続行していい？」
「人間に上げる？」
「どのツールを使う？」
「この結果を信用していい？」
こうした判断を担当する。
そう考えると、
AI社員というより、AI社員を管理する薄い判断レイヤー
に近い。
ここが面白い。
MCPでも同じ流れが起きている
モデル選択だけではありません。
JevをMCPとしてClaude CodeやCodexへ接続するプロジェクトも増えています。
例えばjev-mcpでは、
claimの検証。
コンテンツのscreening。
候補のranking。
などをJevへ渡せます。
typesafe-mcpでは、Claude Code・Claude Desktop・CodexからJevへ判断を送り、型付きJSONと確率を受け取る構造になっています。
さらにjevwireでは、
ツール実行前。
検索結果取得後。
ターン終了前。
といったエージェントの境界にJev判断を挟む設計が試されています。
2026年9月18日時点のv0.4.0では、ライブTypeSafe APIを使った動作確認も行われています。
つまりJevは、
モデル選択だけではなく、AIエージェントの行動そのものを判断する位置
へ入り始めています。
ここで見えてきた「AIシステムの新しい形」
これまでのAIは、
ユーザー
↓
巨大LLM
↓
回答
でした。
これからは、
ユーザー
↓
Jev
↓
どのAI？
↓
Claude / GPT / 小型AI
↓
ツール実行
↓
Jev
↓
結果は妥当？
↓
続行 / 再検討 / 人間確認
のようになる可能性があります。
つまり巨大LLMが1体で全部を担当するのではない。
判断AIが、複数のAIとツールを動かす。
自分はJevのニュースを追っていて、
ここが一番大きな変化になる可能性があると思っています。
ただし、まだ実験段階
ここは冷静に見ます。
jev-routerはコミュニティOSSです。
Claude CodeやCodexの内部リクエスト形式は公開契約ではないため、上流側の変更によって動作しなくなる可能性があることもREADMEで明記されています。
また、ルーティングのためにユーザーのプロンプト本文がTypeSafeへ送信される点も、利用前に理解する必要があります。
Switchyardの40/40も有望ですが、
4種類×10回という限定されたテストです。
だから、
「Jevを入れれば最適モデルを100%選べる」
とはまだ言えません。
ただ、
「Jevを判断レイヤーとしてAIシステムへ組み込めるのか？」
については、
実装例が急速に増え始めています。
個人的に、ここからがJevの本番だと思う
Jev公開直後は、
「文章を書かないAI」
という珍しさが注目されました。
でも数日追ってみると、
本当に重要なのはそこではない気がします。
Jevは、
文章を書かないから軽い。
判断だけするから速い。
出力候補を制限できる。
confidenceを持てる。
そしてその結果を、
普通のプログラムがそのまま次の行動へ使える。
だから、
AIとAIの間。
AIとツールの間。
AIと人間の間。
に置ける。
Jevは主役のAIではなく、
AIチーム全体を動かす「判断インフラ」
を狙えるのかもしれません。
次に試すならこれ
ここまで来たら、ZEN AI LABでも面白い検証ができます。
例えば同じ100個のClaude Code依頼を用意して、
Jevに、
Fast。
Balanced。
Strong。
へ振り分けさせる。
そして実際に、
Jevが選んだモデル。
常に高性能モデル。
常に中間モデル。
の3パターンを比較する。
見るのは、
成功率。
作業時間。
使用量。
やり直し回数。
Jevのconfidence。
そして、
本当に「必要な仕事だけ強いAIへ送る」ことができるのか。
ここまでやれば、
単なるJev紹介ではありません。
AI開発コストそのものを最適化できるのか
という独自検証になります。
Jevが「判断するAI」から、
「AIを使い分けるAI」
へ進めるのか。
これはかなり追う価値がありそうです。
Jev研究室のほかの記事
※本記事は2026年9月18日時点のAnthropic公式情報、DevelopersIOで公開されたNeMo Switchyard＋Jev実装、GitHub上のjev-router、jev-mcp、typesafe-mcp、jevwire等の公開情報をもとに整理しています。コミュニティOSSはTypeSafe・Anthropic・OpenAIの公式機能とは限らず、仕様・対応モデル・互換性は今後変更される可能性があります。
参考にした公開情報
