AI コスト最適化 — LLM 請求額を70〜90%削減する完全ガイド

5つの手法は複合的に効果を発揮します。それぞれ請求額の異なる部分を削減するため、3つを組み合わせると品質を失わずに現実的には70%削減でき、5つすべてなら85〜90%に近づきます。このガイドでは、測定済みの削減額と各手法の実行可能なコードを含む全メニューを紹介します。各手法の詳細は、末尾の個別ガイドにリンクしています。

ROI順に並べた5つの手法

1. プロンプトキャッシュ — 圧倒的に最高ROIの手法

システムプロンプトが1,000トークンを超え、5分間に同じプロンプトを2回を超えて呼び出す場合、プロンプトキャッシュで簡単に費用を節約できます。Anthropicはキャッシュされた入力を入力料金の10%（Claude Fable 5.1では2.5%、Claude Opus 5.5では5%）で課金し、OpenAIは同等の処理を10%で自動適用します。追加するフィールドは1つだけです。

# Prompt caching: 1 extra field = 10% rate on cached input
resp = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=600,
    system=[{
        "type": "text",
        "text": LONG_SYSTEM_PROMPT,
        "cache_control": {"type": "ephemeral"},   # cache this part
    }],
    messages=[{"role": "user", "content": question}],
)

現実的な削減額：システムプロンプトが大きく安定している場合、入力コストを60〜90%削減できます。/app/usageダッシュボードを確認してください。cache_read_input_tokensが0なら、永続的な効果を生む30分間の作業が残っています。詳細ガイド。

2. モデルの階層化 — 十分な品質を持つ最安モデルを使う

Claude Haiku 4.5の料金はClaude Opus 4.7の約10%です。分類、整形、ルーティング判断、単純な要約にはHaikuで十分以上です。本当に難しい推論の呼び出しにのみOpusを使用してください。

# Pick the cheapest model that's still good enough for the task.
# Escalate by difficulty: cheap (Haiku 4.5 / GPT-5.6 Terra) -> Sonnet 5 -> Opus 4.7
def pick_model(difficulty: int) -> str:
    if difficulty <= 2: return "claude-haiku-4-5"     # ~10x cheaper than Opus
    if difficulty <= 4: return "gpt-5-6-terra"        # a second family, cheap output
    if difficulty <= 7: return "claude-sonnet-5"
    return "claude-opus-4-7"

階層化の判断を構築する方法：まず小さな分類器を使い（Haiku自体で入力100トークン以内に処理可能）、その後にルーティングします。ホールドアウト評価で出力品質を測定してください。直感で選ばず、ベンチマークしてください。

• 階層0（Haiku 4.5）：分類、抽出、翻訳、入力2K未満の要約 — 1呼び出しあたり数セント
• Tier 1（GPT-5.6 Terra）：長い要約、コード補完、単純なツール利用 — 同じく数セントだが長いコンテキストに強い
• Tier 2（Sonnet 5）：本格的な推論、複数ステップのエージェント、視覚タスク — 本番運用の主力
• Tier 3（Opus 4.7）：Sonnetが正しく処理できないことを確認した場合のみ

3. 出力上限 — 読み取る量ではなく生成する量を制限する

出力トークンは通常、入力より4〜5倍高額です。max_tokens=4096の緩いデフォルトはモデルの冗長な出力を促します。積極的に上限を設定し、適切なマーカーで打ち切るために停止シーケンスを使用してください。

# Two-layer caps: per-call max_tokens + per-key wallet cap
client.chat.completions.create(
    model="claude-sonnet-5",
    messages=[...],
    max_tokens=800,             # cap each call
    stop=["</answer>"],         # cut at terminator
)
# /app/keys → set "Spending limit" per key:
#   Production: $50/day · Experiment: $5/day · CI: $1/day

呼び出しごとのmax_tokensと、/app/keysのキーごとのウォレット支出上限を組み合わせてください。際限のないループやバグが1日の上限を超えることはありません。2つの層はいずれも重要です。

4. 並列処理 — バッチ型ワークロード向け

独立した項目を1,000件処理する場合（フィードバックの分類、リードのスコアリング、説明文の生成など）、逐次呼び出しでは1時間かかります。AsyncOpenAIによる非同期処理と同時実行数の制限を使えば1分未満で完了し、より短いタイムアウトによって遅い上流サービスへのリクエストを早期に失敗として処理できます。並列処理自体はトークン単価を下げませんが、冪等処理やより厳格なリトライ予算など、トークン単価を下げるアーキテクチャパターンを可能にします。

5. リトライの健全化 — 際限のない再試行に料金を支払わない

単純なコードは400を含むすべてのエラーで再試行します。これは失敗にコストを払うことになります（Kunavoでは4xxリクエストは課金されませんが、レート制限枠と実際の経過時間は消費します）。正しいポリシーは、408/429/5xxの場合にのみ再試行し、ジッターを伴う指数バックオフを使用して、試行回数を合計で最大5回、合計待機時間を最大30秒に制限することです。それ以外は即時に失敗として処理し、エラーを表示してください。

実際の削減額

月額5,000ドルを使うKunavo利用SaaSで測定した現実的な削減額：

• プロンプトキャッシュの追加：2,000ドル削減（−40%）
• 分類へのHaiku階層化：800ドル削減（−16%）
• max_tokensの厳格化：400ドル削減（−8%）
• 合計：月額3,200ドル削減、支出1,800ドル（合計−64%）

これらは複合的に効果を発揮します。次の手法は、すでに削減された基準額に対して機能します。最初にキャッシュを適用しなければ、他の手法による削減額は小さくなります。順序が重要です。#1、次に#2、次に#3から始めてください。

宣伝どおりには機能しないもの

• 「すべてにEmbeddingを使う」 — 埋め込みはテキスト検索のコストを削減しますが、生成のコストは削減しません。安価ですが、LLM呼び出しのコストは下がりません
• 「コスト削減のためのローカルファインチューニング」 — 限定されたタスクで1日1,000万トークン以上を処理する場合にのみ正当化できます。ほとんどのチームでは、運用が複雑なセルフホスティングよりも、プロンプトキャッシュとHaikuを使ったモデルの階層化の方が有利です
• 「より安いアグリゲーター」 — Kunavoはすでにほとんどのモデルをプロバイダーの公式料金より安く設定しています。より安いアグリゲーターは通常、要求されたモデルを密かにより安いモデルへ置き換えることで有利になります

次に確認する項目

まずキャッシュを適用してください。投資した時間あたりのROIが最も高いためです。次に/app/usageダッシュボードをモデルと階層別に計測します。その後で階層化してください。月間のアクティブユーザーあたりコストを北極星指標として追跡します。エンゲージメントが伸びる中で横ばいから低下しているなら、成功しています。

よくある質問