コスト対品質のトレードオフ

コストの文脈なしの品質は、意思決定の半分に過ぎません。パレートフロンティアが必要です — 各品質基準に対して、それを達成する最も安いコンフィグは何か？

使用時機

• 新機能のデフォルトモデルを選択する場合
• 既存機能のLLM支出を削減する場合
• プレミアムモデルへのアップグレードを正当化する（またはしない）場合
• プロンプトの複雑さ、モデルサイズ、シンキングバジェットをトレードオフする場合

パレートフロンティア

候補となる各コンフィグ（モデル × プロンプト × 設定）を品質（y軸）対リクエストあたりのコスト（x軸）でプロットします。フロンティアは、他のコンフィグがそれよりも安くて優れているものが存在しないコンフィグのセットです。

フロンティア上にないコンフィグは支配されています — 常に別のオプションより厳密に悪いです。削除してください。

  quality
   ↑
 1 |    *A (opus + thinking)
   |    *B (opus)
   |*G *D (sonnet + few-shot)
   |*F *C (sonnet)
 0 |*E (haiku)
   +---------------→ cost

パレート: A, B, D, C, E。支配される: F（同じコストでEより悪い）、G（同じコストでDより悪い）。

測定

候補ごとに以下を測定します:

メトリクス	例
リクエストあたりの入力トークン	2,500
リクエストあたりの出力トークン	400
リクエストあたりの$	$0.012
品質スコア	0.87
p95レイテンシ	1.8s

const costPerRequest = (usage.input_tokens / 1e6) * inputRate +
                       (usage.output_tokens / 1e6) * outputRate +
                       (usage.cache_creation_input_tokens / 1e6) * cacheWriteRate +
                       (usage.cache_read_input_tokens / 1e6) * cacheReadRate;

キャッシュコストを常に含めてください — キャッシュされたワークロードでは支配的です。

比較する一般的なコンフィグ

どの機能でも、少なくとも以下を試してください:

1. 簡潔なプロンプトを使用したHaiku
2. より長い / fewショットプロンプトを使用したHaiku
3. 簡潔なプロンプトを使用したSonnet
4. fewショット + 構造化出力を使用したSonnet
5. 拡張シンキングを使用したSonnet
6. 簡潔なプロンプトを使用したOpus
7. 拡張シンキングを使用したOpus

通常、これらのいずれかがワークロードのフロンティア上に存在します。推測せず、測定してください。

プロンプトをレバーとして

より大きなモデルに飛び込む前に、プロンプトレバーを試してください:

• Fewショット例（2-5個）は品質を5-15%向上させることが多く、コストは小さい
• 構造化出力（JSONスキーマ）はパースエラーを減らします
• 連鎖的思考プロンプティングはシンキングトークンなしで推論を支援します
• より良いシステムプロンプトスコーピング（何を含めるか/除外するか）は精度を向上させます

Haikuの方がよいプロンプトは、Sonnetの平凡なプロンプトを上回ることができ、コストは10分の1です。

損益分岐点分析

アップグレードを検討する際に、それが価値を生み出すタイミングを計算します:

リクエストあたりのコスト増加: Δcost = new - old
品質増加: Δquality = new - old
品質ポイントあたりの価値: V（ビジネスメトリクスから推定）

価値がある場合: Δquality × V > Δcost

例: 1%の品質向上がユーザー保持率の収益をリクエストあたり$0.003増加させ、Haiku→Sonnetへのアップグレードが+5%品質で+$0.002/リクエストかかる場合:

• 価値ゲイン: 5 × $0.003 = $0.015
• コスト: $0.002
• ネット: リクエストあたり+$0.013 → アップグレード

段階的ルーティング

1つを選ぶ必要はありません。難易度ごとにルートします:

const difficulty = await classifyDifficulty(query);
const model = difficulty === "simple" ? "claude-haiku-4-5"
            : difficulty === "medium" ? "claude-sonnet-4-6"
            : "claude-opus-4-6";

分類は安価なHaikuコールです。ほとんどのクエリはシンプルです。お金を節約します。難しいクエリはプレミアム処理を受けます。

測定: 段階的ルーティングは実際にコスト/品質の位置を改善しますか？時々分類エラーが利益を消します。

レイテンシを第3軸として

コスト対品質だけでは十分ではありません。レイテンシも重要です。これが支配的な例:

• チャットUIは最初のトークン < 2秒が必要 → シンキング実行せずOpusを除外
• 音声エージェントは完全な応答 < 500ms が必要 → Haikuを強制
• バックグラウンド要約: レイテンシは重要でなく、コスト/品質のみを最適化

3つ組を報告します: （品質、コスト、p95レイテンシ）。3Dのフロンティアはより小さいです。どの軸に制約があるかで選択します。

キャッシュを考慮した選択

入力の90%をキャッシュできる場合:

• 有効入力コストは約10倍低下します
• ロングコンテキスト + キャッシュは同じ品質でショートコンテキスト + キャッシュなしを上回ることが多い
• より大きなモデルはリクエストあたりがより手頃になります

キャッシュを考慮せずに行われた決定は通常間違っています。キャッシュを考慮して再測定してください。

サンプルバジェット

各コンフィグを10,000項目で評価しないでください。小さく始めます:

1. 50項目でショートリスト → 3つのコンフィグに絞る
2. 200項目で確認 → 勝者を選ぶ
3. 本番環境で5%トラフィックのカナリアで検証 → 完全ロールアウト

評価コストを10～100倍節約します。

アンチパターン

1. デフォルトで最大のモデルを選択する — 支配されることが多い
2. キャッシュコストを無視する — 全体像を歪める
3. 1次元最適化 — 品質のみはコスト増加を見落とします
4. 測定なしの段階的ルーティング — 分類エラーが利益を否定できます
5. 製品ごとのモデル選択 — インフラストラクチャ投資を再利用できません
6. プロンプトレバーをスキップする — モデルのアップサイズを試す前にfewショットを試す

ベストプラクティス

1. コスト、品質、レイテンシを測定します。パレートフロンティアをプロットします
2. プロンプトレバー（fewショット、CoT、構造化）を試してからモデルをアップサイズします
3. 損益分岐点を計算します: 品質向上はコスト差の価値がありますか？
4. 段階的ルーティングを検討します。実際に役立つかを測定します
5. キャッシュの読み取り/書き込みを常に考慮します — 決定を10倍変えることができます
6. 小さなサンプル（50-200）で評価してから、本番環境でカナリアを実施してから完全ロールアウトします
7. 四半期ごとに選択を見直します — 価格とモデル品質は変動します