02 LLMルーティング — 複数LLMの使い分け設計

コストと品質を最適化するためのモデルルーティング設計パターン

なぜルーティングが必要か

最高品質のモデル（例: Claude Opus）をすべてのタスクに使うのは非効率です：

コストが高い
レート制限に達しやすい
軽量タスクには過剰な能力

ルーティング設計で「タスクの重さに合ったモデル」を自動選択します。

3層ルーティング設計

タスク受信
    ↓
┌──────────────────────────────┐
│  Tier 1: 高品質モデル        │  複雑な設計・コードレビュー
│  (例: Claude Opus)           │  長文の文脈理解が必要なタスク
└──────────────┬───────────────┘
               │ 失敗 or コスト節約したい
               ↓
┌──────────────────────────────┐
│  Tier 2: バランス型モデル    │  通常の実装・質問応答
│  (例: Claude Sonnet)         │  多くの日常タスク
└──────────────┬───────────────┘
               │ 高速・大量処理が必要
               ↓
┌──────────────────────────────┐
│  Tier 3: 軽量モデル          │  要約・フォーマット変換
│  (例: Claude Haiku)          │  テストデータ生成・単純作業
└──────────────────────────────┘

自動委譲パターン

大量処理タスクは軽量モデルに自動委譲することでコストを削減：

タスク種別	推奨モデル	理由
要約・抽出	軽量	精度より速度とコストを優先
フォーマット変換	軽量	定型処理は高品質モデル不要
テストデータ生成	軽量	パターン生成は軽量モデルで十分
コードレビュー	高品質	見落としのない正確な判断が必要
アーキテクチャ設計	高品質	複雑なトレードオフの評価が必要
ドキュメント執筆	バランス	品質と効率のバランスが重要

ローカルプロキシパターン

注意: このパターンはWSL CLI版（Claude Code CLI）でのみ有効。 Windows Desktopアプリ版はエンドポイント変更不可のため、GLM/MiniMaxはMCPサーバー経由で委譲する別の方法を使う。

Claude Code CLIから複数のAPIプロバイダーを透過的に切り替えるには：

Claude Code CLI（WSL）
    ↓ HTTP
localhost:8787 (ローカルプロキシ / glm-rate-proxy)
    ↓
    ├── 通常時 → ZAI API (GLM-5.1)
    ├── ピーク時 → MiniMax API
    └── 429/5xxエラー時 → MiniMax API（フォールバック）

⚠️ 重要な制限: コンテキストウィンドウが上限に達した場合、Claude Code本体がAPIリクエストを送る前にエラー判定するため、プロキシに届かずフォールバックも発動しない。早めの /compact / /new-session が必要。

実装例（概念）:

# proxy.py
import time
from fastapi import FastAPI

app = FastAPI()

def get_provider():
    hour = time.localtime().tm_hour
    if 15 <= hour < 19:          # ピーク時間帯
        return "provider_b"       # コスト削減プロバイダー
    return "provider_a"           # 通常プロバイダー

@app.post("/v1/messages")
async def route_message(request):
    provider = get_provider()
    return await forward_to(provider, request)

メリット:

Claude Codeの設定を変えずにモデルを切り替えられる
時間帯・エラー状況に応じた動的切替
料金ピーク時のコスト自動最適化

CLAUDE.mdでのルーティング設定

## LLM利用ポリシー
- デフォルト: Claude Sonnet（バランス型）
- 複雑なタスク: ユーザー許可後にOpusを使用
- 大量処理: Haiku等の軽量モデルに自動委譲
- バッジ表示: レスポンス冒頭に使用モデルを明示

レート制限への対処

## settings.jsonでの設定例
{
  "env": {
    "ANTHROPIC_BASE_URL": "http://localhost:8787"
  }
}

プロキシ側でレート制限を検知してフォールバック
429エラー → 自動リトライ（指数バックオフ）
繰り返し失敗 → 別プロバイダーへ切替

モデル選択の判断フロー

新しいタスクが来た
    ↓
複雑さを判定
    ├── 高複雑度（設計・レビュー）→ 高品質モデル
    ├── 中複雑度（通常実装）    → バランス型
    └── 低複雑度（定型・大量）  → 軽量モデル
    ↓
コスト制約を確認
    ├── 制約あり → 一段階下のモデルを検討
    └── 制約なし → そのまま実行
    ↓
実行 → 結果を評価
    └── 品質不足 → より高品質なモデルで再実行

コスト最適化のポイント

プロンプトキャッシュ活用: システムプロンプトをキャッシュ
バッチ処理: 複数リクエストをまとめて送信
モデル階層の明確化: タスク種別ごとに使用モデルをルール化
不要なコンテキストを削除: /compact で履歴を圧縮