10月10日、Sergiovillaniが「Cost per task: Using cheap classifiers to route across Gemini models and thinking levels」と題した記事を公開した。LLMのトークン単価が下がり続ける一方、自律型コーディングエージェントの請求額が逆に膨らんでいる現実に対し、「タスク難易度に応じたモデルの振り分け」という実践的な解決策を50問のベンチマークで検証した内容だ。正規表現ヒューリスティックが未知データで23ポイント精度が崩落する失敗例も含め、再現性の高い知見が詰まっている。
LLMのトークン単価は下がり続けているが、自律型コーディングエージェントの請求額は逆に増え続けている。その原因はシンプルだ。「トークン単価」ではなく、「タスク成功あたりコスト」が本質的な指標なのに、すべてのリクエストを高性能・高コストなモデルに投げているからだ。
Sergiovillani（Google Cloud AI、Technical Solutions）は、TypeSafeのJevクラシファイアをGeminiのAPI呼び出しの前段に置き、タスクの難易度に応じてモデルを振り分ける構成を検証した。50問の自動採点コーディングベンチマークを使い、全コードと生のJSON結果はGitHubリポジトリで公開されている。
Jevとは何か、そしてTypeSafeとは
Jevは、TypeSafeが開発・提供する構造化出力専用のクラシファイアだ。TypeSafeはLLMを使ったシステムの信頼性と予測可能性を高めることをミッションとするAIスタートアップで、Jevはその中核プロダクトとして提供されている。テキスト生成を一切行わず、以下の3種類のプリミティブを1回のフォワードパスで返す点が最大の特徴だ：
- Choice：リストからの選択
- Score：数値スコア
- Noul：バイナリ命題の確率（0〜1）
重要なのは、このクラシファイアが「ほぼタダ」で動く点だ。意思決定のたびに高性能モデルを呼び出す代わりに、Jevで難易度を判定し、簡単なタスクは軽量モデルへ、複雑なタスクだけ重いモデルへ流す。通常のLLMがトークンを逐次生成するのと異なり、1回のフォワードパスで分類結果を返すため、ルーティングのオーバーヘッドを最小限に抑えられる。
最重要の知見：正規表現ヒューリスティックは本番では崩壊する
記事の核心はここだ。「分類器なんてPythonの正規表現で代替できる」という発想を、データで否定している。
Sergio氏はまず、sequence・modulo・race conditionなどのキーワードマッチや「35ワード以上は複雑扱い」といったヒューリスティックを実装した。開発用の16問では15/16（93.8%）の精度を記録した。
次に、そのコードを一切変更せずに、未知の34問（held-out）に適用した結果：
- 正規表現ヒューリスティック：70.6%（-23.2ポイント）
- Jevクラシファイア：100%（34/34）
失敗の内訳が興味深い。KubernetesのYAMLからポートを抽出するような「実際は簡単」なタスクが35ワードを超えたせいで難しいと誤判定された。逆に、Pythonの辞書キーハッシュ（{1: "a", True: "b", 1.0: "c"}の挙動）のような「実際は複雑」なタスクは、ヒューリスティックのキーワードに引っかからず簡単扱いされた。
ヒューリスティックが開発セットで高精度に見えるのは、そのデータに合わせてルールを書いたからにすぎない。
Jevへの質問設計も重要だ。 「これは簡単か複雑か」という広い二択（Choice）を投げると、ほぼすべてを「簡単」と判定してしまった。正しいアプローチは、1つの原子的なNoul質問に分解することだ：
def call_jev(question_text):
body = {
"state": question_text,
"model": "jev-latest",
"questions": {
"multi_step": {
"type": "noul",
"instructions": (
"Answering this requires performing more than one "
"sequential calculation, simulation step, or logical "
"deduction, rather than a single direct lookup, format "
"check, or one-step classification."
),
}
},
}
# POST to https://api.typesafe.ai/v1/systemone
# response.answers["multi_step"].noul が振り分けに使う確率値
ルーター構成の比較結果
50問のベンチマークで試した各構成の結果は以下の通りだ。なお、表中の「—」は元記事に該当データの記載がなく不明であることを示す。また、モデル名「Gemini 2.5 Flash」「Gemini 2.5 Pro」等については元記事の表記に準拠しているが、Googleの公式モデル一覧と照合したうえで読み進めることを推奨する（※編集部の考察：元記事に記載のモデル名が現行のGeminiバージョン体系と完全に一致するか確認が取れなかったため、本表では元記事の表記をそのまま使用している）。
| 構成 | 正解数 | コスト比 | 速度（タスクあたり） |
|---|---|---|---|
| Gemini 3.8 Flash（デフォルト） | 50/50 | 基準 | 3.1秒 |
| Gemini 3.8 Flash（低thinking） | 50/50 | 約半分以下 | 3.6秒 |
| Jevルーター（Flash-Lite→Flash低thinking） | 50/50 | 低thinkingより約15%安 | 1.9秒 |
| 正規表現ヒューリスティックルーター | 48/50 | 最安だが不正解あり | 元記事に記載なし |
| Gemini 3.1 Pro | 48/50 | 約12倍 | 元記事に記載なし |
最も費用対効果が高かったのは「Jevルーター（Flash-Lite→Flash低thinking）」だ。簡単なタスクはFlash-Liteへ（0.5秒、低コスト）、複雑なタスクのみFlash低thinkingへエスカレート。これにより低thinking-Flashに対して約15%のコスト削減、約1.9倍の高速化を実現した。なお、この「15%削減」はデフォルト設定（基準）との比較ではなく、すでに低thinkingに最適化した構成を基準とした削減幅である点に注意が必要だ。
一方でGemini 3.1 Proは、SQLインジェクションやXSSの脆弱性確認という単純なタスクを安全上の理由で拒否し、2問を落とした。最も高価なモデルが最高の結果を出すわけではないという実態が数字で示されている。
見落とされがちな落とし穴：maxOutputTokensは思考量を減らさない
「出力トークン数の上限を下げれば安くなる」という誤解も本記事で否定されている。maxOutputTokens=300とmaxOutputTokens=4096を比較したところ、簡単なタスクでのthinking tokens消費量はほぼ同じだった。上限キャップは出力の「天井」であり、モデルが考える量を制御しない。実際、300トークン制限下では難しいタスクの7問が壊れた（6問は回答未完了、1問は誤答）。
thinking量を直接制御したいなら、thinkingLevel: "LOW"を明示的に指定する必要がある。
実践的な3つのルール
記事の末尾で著者はまとめとして以下を提示している：
- まずFlash低thinkingを試す。ルーターを作る前に、これだけでデフォルト設定の半分以下のコストで全問正解できる場合がある
- 短い独立タスクにJevルーターを使う。1つのYes/No質問で分類し、簡単→Flash-Lite、複雑→Flash低thinkingへ振り分ける。コンテキストが長い会話ターンは単一モデルに固定してキャッシュを効かせる
- トークン単価ではなくタスク成功あたりコストで測る。不正解や拒否は全額を無駄にする
詳細はCost per task: Using cheap classifiers to route across Gemini models and thinking levelsを参照していただきたい。
