安いモデルに落とす境界——品質が壊れる一点

目次▼

1. 1結論を先に
2. 2まず用語の地図
3. 3具体例
4. 4ルーティング表の設計と品質ゲートの粒度
5. 5よくある偏り
6. 6いまの一手

コストとレイテンシの最適化は「どこまで落とせるか」ではなく「どこで壊れるかを先に知っておく」問題だ。

---

この記事の使い方

決めること

• タスク種別ごとの「フォールバック先モデル」と切り替え条件
• 品質が壊れる兆候を検知するための評価指標

決めないこと

• 特定ベンダーのモデルを推奨すること（ベンチマーク数値は変動するため）
• 全タスクに通用する単一のルーティング式

前提

• APIコストを実際に払っているか、払う予定がある
• 複数モデルを呼び分ける実装が技術的に可能な状態
• 「安くしたい」より「安くしても壊れない範囲を知りたい」が本音

---

結論を先に

タスク分類	高コストモデルが必要な条件	安いモデルで代替できる条件	壊れる兆候
長文要約	原文が10,000トークン超・専門用語密度が高い	一般文書・3,000トークン以下	重要情報の脱落、数値の誤読
コード生成	複数ファイル依存・型推論が必要	単一関数・テストコード・スキャフォールド	コンパイルエラー率が上がる
分類・ラベリング	ラベル定義が曖昧・境界事例が多い	ラベルが明確・2〜4クラス	境界クラスの混同率が跳ねる
対話・チャット	文脈が10ターン超・感情的配慮が必要	1〜3ターン・FAQ応答	文脈の取り違え、トーンの崩れ
構造化抽出（JSON等）	スキーマが深い・ネスト3層以上	フラットなスキーマ・フィールド5個以下	フィールド欠損、型ミス
推論・計画	多段階の依存関係・反実仮想が含まれる	単一ステップ・事実確認	中間ステップの省略、論理の飛躍

---

まず用語の地図

用語	かみ砕いた意味
ルーティング	入力の内容や条件に応じて、呼び出すモデルを自動で切り替える仕組み
フォールバック	第一候補のモデルが失敗・低品質だったときに次のモデルへ切り替えること
レイテンシ	APIを叩いてから最初のトークンが返るまでの待ち時間（TTFT）と、全文生成完了までの時間（TGT）の二種類がある
トークン単価	入力・出力それぞれ1,000トークンあたりの料金。モデルによって入力と出力で非対称なことが多い
品質ゲート	「この指標がこの閾値を下回ったら合格とみなさない」と事前に決めた検証条件
カスケード	安いモデルから順に試し、品質が足りなければ次の高いモデルへ渡す多段構成
コンテキスト長	一度のAPI呼び出しで扱えるトークン数の上限。安いモデルほど短い傾向がある

---

具体例

構造化抽出のルーティング——フィールド数とネスト深さで切り替える

ECサイトの商品レビューから「評価点・カテゴリ・問題箇所・改善提案」を抽出するパイプラインを例にとる。

縦スライス：1件のレビューが処理されるまで

入力レビュー
  │
  ▼
【ルーター】スキーマ検査
  ├─ フィールド数 ≤ 5 かつ ネスト ≤ 1層
  │     → 軽量モデル（例: 小型の命令チューニング済みモデル）
  │
  └─ フィールド数 > 5 または ネスト ≥ 2層
        → 高性能モデル
              │
              ▼
        【品質ゲート】JSON検証
              ├─ スキーマ合致 → 出力確定
              └─ 不合致 → フォールバック（高性能モデルへ再送）

ポイントは「ルーターがモデルを呼ぶ前に判断する」こと。レビュー本文を読ませてから判断させると、その読み取りコスト自体が無駄になる。スキーマの複雑さはリクエスト送信前にコード側で計算できる。

---

受け入れ条件と失敗モードの対応表

チェック項目	合格条件	失敗モード	対処
JSONパース成功	エラーなし	閉じ括弧の欠損、末尾カンマ	フォールバックへ即時再送
必須フィールド存在	全フィールドが存在する	任意フィールドとの混同で欠損	プロンプトにフィールド一覧を明示
型の一致	数値は数値、文字列は文字列	評価点が文字列 “4点” で返る	スキーマにenum/typeを厳密に書く
値の範囲	評価点が1〜5の整数	0や6が返る	バリデーションで弾き再送
処理時間	TTFT ≤ 設定閾値	軽量モデルでも遅延が出る	タイムアウト後に高性能モデルへ

失敗モードの頻度感（実測ではなく設計上の読み枠）

• フラットスキーマ・5フィールド以下：軽量モデルで型ミスが出るのはだいたい5〜15%程度の入力
• ネスト2層以上：同条件で30〜50%に跳ねることがある
• この「跳ね」がフォールバック設計の根拠になる

---

ルーティング表の設計と品質ゲートの粒度

ルーティング表の三つの軸

ルーティングの判断軸はだいたい三層に分けて読む。

第一層：入力の構造的特徴（モデルを呼ぶ前に判断できる）

• トークン数の推定値
• スキーマの複雑さ
• 言語（多言語か単言語か）

第二層：タスクの意味的難易度（プロンプトを見て判断する）

• 曖昧な指示が含まれるか
• 反実仮想・仮定条件が含まれるか
• 専門用語の密度

第三層：出力の品質検証（モデルを呼んだ後に判断する）

• 構造的整合性（JSONパース、スキーマ合致）
• 意味的整合性（入力との矛盾がないか）
• 長さの妥当性（極端に短すぎ・長すぎ）

第一層だけでルーティングを完結させると実装コストが最小になる。第二層以降を使うほど精度は上がるが、判断コスト自体が発生する。

品質ゲートの粒度をどこに置くか

品質ゲートを細かくしすぎると、フォールバック率が上がりすぎて「常に高性能モデルを呼ぶ」状態と変わらなくなる。

実用的な粒度の目安：

ゲートの種類	実装コスト	推奨する場面
構造検証のみ（JSONパース等）	低	構造化出力全般
構造＋必須フィールド存在確認	低〜中	スキーマが固定されている場合
構造＋意味的整合性（LLMで評価）	高	誤りのコストが高い場面（医療・法務等）
A/Bサンプリングによる継続的評価	中	本番運用でドリフトを検知したい場合

意味的整合性の検証に別のLLMを使う「LLM-as-judge」は強力だが、そのコストがルーティングで節約した分を食いつぶすことがある。使うなら全件ではなくサンプリングで。

---

よくある偏り

「安いモデルは全部ダメ」という過剰な忌避 軽量モデルが苦手なのは「曖昧さの解消」と「多段推論」だ。入力が構造化されていて出力スキーマが明確なタスクでは、高性能モデルと遜色ない結果が出ることが多い。タスクを分解せずにモデルを比較すると、この差が見えない。

「コスト削減率」だけで評価する コスト削減率が高くても、フォールバック率が高ければ実質的な削減額は小さい。正しい指標は「同品質を維持した上での実コスト削減額」。フォールバック率・品質ゲート通過率・実コストの三点セットで追う。

フォールバックを「エラー処理」と混同する フォールバックは品質が閾値を下回ったときの正常な分岐であり、エラーではない。エラーログに混ぜると、品質劣化の傾向が見えなくなる。フォールバック率は専用のメトリクスとして別管理する。

ルーティングを一度決めたら変えない モデルのアップデートは頻繁に起きる。3ヶ月前に「安いモデルでは無理」と判断したタスクが、今は問題なく動くことがある。ルーティング表は定期的に再評価する前提で設計する。

レイテンシを「平均値」だけで見る P95・P99のレイテンシが重要。安いモデルは平均は速くても、高負荷時のスパイクが大きいことがある。ユーザー体験に直結する用途では分布で判断する。

---

いまの一手

本気でルーティングを実装する人へ

1. 現在のタスクを上記の6分類（要約・コード・分類・対話・構造化抽出・推論）に当てはめ、それぞれの月間トークン量を出す
2. タスクごとに「入力の構造的特徴」だけで判断できる条件を一つ書き出す（第一層から始める）
3. 軽量モデルで全件処理した場合の品質ゲート通過率を1週間計測する
4. フォールバック率が20%を超えるタスクは「そもそも分解できるか」を先に検討する

まだ様子見の人へ

• まず一つのタスクだけ選んで、同じ入力を高性能モデルと軽量モデルの両方に投げ、出力を並べて見る
• 「どこが違うか」を言語化する——それがそのタスクの品質ゲートの原型になる
• コストの計算は後でいい。先に「壊れる場所」を自分の目で確認する

---

モデル動向の全体像は kakoGENZAI models シリーズ でまとめています。