モデル階層¶

このダイヤルは何か¶

モデル階層は、タスクの種類や難易度に応じてどのクラスのLLMを使うかを制御するダイヤルです。小型モデル（高速・低コスト・低性能）、中型モデル、大型モデル（低速・高コスト・高性能）の中からタスク特性に最適なモデルを選択し、必要に応じて動的に切り替えます。

AIエージェントシステムでは、1回のセッション内で性質の異なる多数のタスクが実行されます。分類や情報抽出のような定型処理と、推論や計画のような高度な処理が混在しています。すべてを大型モデルで処理すれば品質は安定しますが、1リクエストが高コスト（F2）であるため、月間コストが桁違いに膨張します。一方、すべてを小型モデルで済ませようとすると、複雑なタスクで品質が崩壊します。

さらに、モデルのサイズはレイテンシのばらつき（F12）にも直結します。大型モデルは推論に時間がかかり、応答時間の分散も大きくなります。定型処理に大型モデルを使うと、本来100msで済む処理が数秒かかり、システム全体のP95レイテンシを不必要に悪化させます。

モデル階層のダイヤルは、「コスト」と「品質」を定数として固定するのではなく、タスク特性に応じた関数として最適化する仕組みです。実運用では全リクエストの概ね60〜80%が小型・中型モデルで十分に処理でき、大型モデルが必要なのは残りの20〜40%であることが多いです（ただしこの比率はドメインに大きく依存します）。

効かなすぎる害 ⇔ 効きすぎる害¶

効かなすぎる害（モデル階層が低すぎる/小型モデルに偏りすぎ）¶

すべてのタスクを小型モデルで処理しようとすると、品質が不足します。

複雑な推論タスク（多段の論理推論、因果関係の分析）で回答品質が崩壊します。小型モデルでは「もっともらしいが間違っている」回答が増えます
長い計画の立案で、整合性の取れないステップが生成されます。計画の途中で矛盾が発生し、実行フェーズで失敗します
コード生成で、構文は正しいが論理的に誤ったコードが生成される頻度が上がります
[failure_cost] が高いタスクに小型モデルを使うと、エラー修正のコスト（人間レビュー、リトライ、手戻り）が節約額を上回ります

効きすぎる害（モデル階層が高すぎる/大型モデルに偏りすぎ）¶

すべてのタスクを大型モデルで処理すると、コストとレイテンシが爆発します。

「YesかNoで答えてください」のような単純な分類タスクに大型モデルを使い、1リクエストあたりのコストが100倍になります
キーワード抽出やデータフォーマット変換のような定型処理に大型モデルを使い、応答時間が数秒に膨張します
月間コストが予算を超過し、サービスの継続性が危うくなります
大型モデルのレート制限に達しやすくなり、全リクエストが429エラーの影響を受けます

決め方¶

このダイヤルは [cost_sensitivity] と [request_value] の2つの駆動変数で決めます。

タスク種別による静的ルーティング¶

まず、タスクの種類に応じてモデル層を静的に割り当てます。

タスク種別	推奨モデル層	理由
分類・タグ付け・抽出	小型	定型処理で高い推論力は不要
要約・変換・翻訳	中型	ある程度の言語理解力が必要
推論・計画・コード生成	大型	複雑な思考が必要
検証・Judge	別系統（大型推奨）	生成系と独立にすることでバイアスを断ち切る

信頼度によるエスカレーション¶

静的ルーティングだけでは、小型モデルが苦手なタスクを見逃すことがあります。信頼度チェック（構造化出力のパースエラー率、回答の拒否率、内部ログ確率など）を設け、閾値未満であれば上位モデルにエスカレーションします。

[request_value] が高いリクエストほどエスカレーション閾値を下げ、早めに上位モデルを使います。逆に [cost_sensitivity] が高い場合は閾値を上げ、本当に必要な場合のみエスカレーションします。

フォールバックとしてのダウングレード¶

障害時には逆方向（大型→中型→小型）のフォールバックも有効です。A6 適応タイムアウトのサーキットブレーカが開いた場合に、縮退ラダーの一段として軽量モデルに切り替えることで、品質は落ちてもサービスを継続できます。

目安値（出発点）¶

設定項目	目安値	条件
モデル階層数	2〜3層	運用しやすさと最適化の精度のバランス。4層以上は管理コストが増大
エスカレーション閾値	信頼度 0.7〜0.85	`[request_value]` が高いほど下げる
ルーター方式	まずルールベース	LLMルーターはルーティング自体にコストがかかる
小型モデルの処理割合	概ね40〜60%	ドメインにより大きく異なる。測定して調整

コスト削減の試算例：全リクエストを大型モデルで処理する場合のコストを基準に、60%を小型モデル（コスト1/10）、20%を中型モデル（コスト1/3）、20%を大型モデルで処理すると、コストは概ね30%程度に削減できます。ただし実際の比率はドメインとタスク分布に強く依存します。

具体的なシナリオ¶

シナリオ1：カスタマーサポートの自動応答¶

タスクの種類が多岐にわたるカスタマーサポートシステムです。

タスク	モデル層	理由
質問の分類（FAQ/技術/請求）	小型	単純な分類タスク
FAQ回答の生成	小型	テンプレートベースで十分
技術的な問題の診断	中型〜大型	推論が必要
返金ポリシーの判断	大型	`[failure_cost]` が高く、正確さが重要
感情分析（優先度判定）	小型	定型的な分類

質問の分類を小型モデルで行い、分類結果に応じて適切なモデル層にルーティングします。全体の概ね70%がFAQと分類で小型モデルで完結し、大型モデルが必要なのは技術的な問題と返金判断の概ね20%程度です。

シナリオ2：データ分析パイプライン¶

大量のデータを処理し、分析レポートを生成するパイプラインです。

タスク	モデル層	理由
データフォーマット変換	小型	定型処理
数値データの要約統計	コード（LLM不要）	決定論的に計算
パターン分析・異常検知の解釈	大型	高度な推論が必要
レポート文章の生成	中型	言語能力は必要だが推論は不要
エグゼクティブサマリの生成	大型	全体を俯瞰した高品質な要約が必要

パイプラインの大部分は小型モデルとコードで処理でき、大型モデルが必要なのは解釈とサマリの生成だけです。[cost_sensitivity] が高い場合は中型モデルで代替することも検討します。

シナリオ3：障害時のフォールバック¶

通常時は大型モデルで推論を行うが、プロバイダ障害時に中型→小型とフォールバックする構成です。

正常時: 大型モデル（Claude Opus相当）
大型プロバイダ障害: 中型モデル（Claude Sonnet相当）にダウングレード。応答品質は低下するがサービスは継続
中型も障害: 小型モデル（Claude Haiku相当）にダウングレード。最低限の応答を維持
全プロバイダ障害: 静的フォールバック（「現在サービスが一時的に利用できません」）

縮退レベルをレスポンスのメタデータに含め、クライアント側で「通常より品質が低い可能性があります」と表示することを推奨します。

実践的なアドバイス¶

ルーター自身のコストを無視しないでください。LLMをルーターに使うと、分類コストだけで小型モデル1回分に匹敵することがあります。リクエスト量が少ないうちは入力長やキーワードに基づくルールベースのルーターで始め、精度が足りなくなったら分類モデルやLLMルーターに進化させます。
信頼度の定義を測定可能な指標に落としてください。「なんとなく自信がない」では運用できません。構造化出力のパースエラー率、特定トークンのログ確率、回答拒否率など、数値として閾値判定できる指標を使います。
モデル更新（プロバイダ側のバージョンアップ）時はルーティング比率を再検証してください。プロバイダがモデルを更新すると、コスト比や能力比が変動します。小型モデルの能力が上がれば大型へのエスカレーション率が下がりますし、逆もありえます。定期的にルーティング比率とコストを監視し、閾値を再調整します。
エスカレーションの無限ループを防いでください。上位モデルでも信頼度が閾値未満の場合の打ち切り条件を設定します。最上位で失敗したら人間エスカレーションまたはエラー返却とし、さらに上位を探し続けないようにします。
D6 セマンティックキャッシュとの併用を検討してください。ルーティングの前段でキャッシュヒットすればモデル呼び出し自体を省略できます。[cost_sensitivity] が高く同一パターンが多い環境では、キャッシュとモデル階層化の組み合わせで大幅なコスト削減が可能です。