Pockit
Back

LLM APIコストを90%削減する方法：キャッシング・ルーティング・プロンプト最適化の実践ガイド

今月のLLM API請求額が2,400に達しました。先月は2,400に達しました。先月は800、その前は$300。プロダクトは順調に成長し、ユーザーはAI機能を気に入っていますが、経理チームが気まずい質問を始めています。

心当たりはないでしょうか？あなただけではありません。2026年現在、AI機能を搭載した平均的なSaaS製品は**インフラ予算の30-50%をLLM API呼び出しに費やしています。**そしてその支出の大部分は、実は不要なものです。

不都合な真実を一つ。**ほとんどのアプリケーションは、重複クエリを送り、些細なタスクに高額モデルを使い、必要以上のトークンを送信しています。**解決策はAIの利用を減らすことではなく、よりスマートに使うことです。

このガイドでは、プロダクト品質を落とさずにLLM APIコストを70-90%削減できる5つの実績ある戦略を取り上げます。理論上のトリックではありません。すべての手法にプロダクションレベルのコード、実際のコスト計算、率直なトレードオフ分析が付いています。

まず：コスト構造を理解する

何を最適化するにも、まず課金の仕組みを正確に理解する必要があります。「トークンにお金がかかる」という漠然とした認識はあっても、全体像を把握していない開発者がほとんどです。

トークンエコノミクス

主要なLLMプロバイダーはすべてトークン単位で課金しますが、単純な掛け算では済みません：

2026年 料金スナップショット（100万トークンあたり）：

┌─────────────────────────┬──────────┬───────────┐
│ モデル                   │  入力     │  出力     │
├─────────────────────────┼──────────┼───────────┤
│ GPT-4.1                 │  $1.00   │   $4.00   │
│ GPT-4.1 mini            │  $0.20   │   $0.80   │
│ GPT-4.1 nano            │  $0.05   │   $0.20   │
│ Claude Opus 4.6         │  $5.00   │  $25.00   │
│ Claude Sonnet 4.6       │  $3.00   │  $15.00   │
│ Claude Haiku 4.5        │  $1.00   │   $5.00   │
│ Gemini 2.5 Pro          │  $1.25   │  $10.00   │
│ Gemini 2.5 Flash        │  $0.30   │   $2.50   │
│ DeepSeek V4             │  $0.30   │   $0.50   │
└─────────────────────────┴──────────┴───────────┘

すぐに2つのことが目に飛び込んできます：

  1. 出力トークンは入力トークンの3-5倍高い。 200トークンのプロンプトで2,000トークンの応答を得ると、入力だけで想像するよりはるかに高額になります。
  2. ティア間の価格差が巨大。 Claude Opus 4.6の出力トークンはGPT-4.1 nanoの125倍高い。そして多くのタスクでは、安いモデルでも同等に機能します。

お金が実際にどこで使われているか

一般的なAI搭載アプリケーションでのコスト分布はこうなっています：

典型的なLLMコスト分布：

  繰り返し/類似クエリ：           35-45%  ← キャッシュ可能
  高額モデルで処理した単純タスク：  20-30%  ← 安いモデルにルーティング可能
  肥大化したプロンプト：          15-20%  ← 圧縮可能
  本当に必要な複雑な固有クエリ：   10-20%  ← 出力長の最適化

つまりLLM支出の60-80%は削減可能です。プロダクト品質に影響を与えずに。一つずつ見ていきましょう。

戦略1：セマンティックキャッシング

実装できる最適化の中で最もROIが高いものです。繰り返しパターンを扱うアプリケーション — カスタマーサポート、コンテンツ生成、コードアシスタント、検索 — を運用しているなら、同一または極めて類似したAPI呼び出しを数千回繰り返している可能性が高いです。

従来のキャッシュの限界

従来のキャッシュは文字列の完全一致を使います。しかしLLMクエリが完全に同一であることはほぼありません。以下の3つのユーザー入力を見てください：

「パスワードのリセット方法は？」
「パスワードを変更したいのですが」
「パスワードを忘れました。再設定するにはどうすれば？」

意味的には同一の質問です — 同じ応答を返すべきです。しかし完全一致キャッシュはこれを3つの別々の課金対象API呼び出しとして処理します。

セマンティックキャッシングの仕組み

クエリを埋め込みベクトルに変換し、コサイン類似度で「意味的に十分近い」キャッシュ済み応答を探します：

import { OpenAI } from 'openai';
import { createClient } from 'redis';
import { Index } from '@upstash/vector';

const openai = new OpenAI();
const redis = createClient();
const vectorIndex = new Index({
  url: process.env.UPSTASH_VECTOR_URL!,
  token: process.env.UPSTASH_VECTOR_TOKEN!,
});

interface CachedResponse {
  response: string;
  model: string;
  timestamp: number;
  hitCount: number;
}

const SIMILARITY_THRESHOLD = 0.92; // この値の調整が肝
const CACHE_TTL = 86400; // 24時間

async function queryWithSemanticCache(
  prompt: string,
  systemPrompt: string,
  model: string = 'gpt-4.1-mini'
): Promise<{ response: string; cached: boolean; savings: number }> {
  // 1. 受信クエリの埋め込みを生成
  const embedding = await openai.embeddings.create({
    model: 'text-embedding-3-small',
    input: `${systemPrompt}\n${prompt}`,
  });
  const vector = embedding.data[0].embedding;

  // 2. 意味的に類似したキャッシュを検索
  const results = await vectorIndex.query({
    vector,
    topK: 1,
    includeMetadata: true,
  });

  // 3. 十分に類似するマッチがあるか確認
  if (results.length > 0 && results[0].score >= SIMILARITY_THRESHOLD) {
    const cacheKey = results[0].id;
    const cached = await redis.get(`llm:${cacheKey}`);

    if (cached) {
      const parsed: CachedResponse = JSON.parse(cached);
      parsed.hitCount++;
      await redis.set(`llm:${cacheKey}`, JSON.stringify(parsed), {
        EX: CACHE_TTL,
      });

      return {
        response: parsed.response,
        cached: true,
        savings: estimateCost(prompt, parsed.response, model),
      };
    }
  }

  // 4. キャッシュミス — 実際のAPI呼び出し
  const completion = await openai.chat.completions.create({
    model,
    messages: [
      { role: 'system', content: systemPrompt },
      { role: 'user', content: prompt },
    ],
  });

  const response = completion.choices[0].message.content!;

  // 5. ベクトルインデックスとRedis両方に保存
  const cacheId = crypto.randomUUID();
  await vectorIndex.upsert({
    id: cacheId,
    vector,
    metadata: { prompt: prompt.slice(0, 200) },
  });

  await redis.set(
    `llm:${cacheId}`,
    JSON.stringify({
      response, model, timestamp: Date.now(), hitCount: 0,
    } satisfies CachedResponse),
    { EX: CACHE_TTL }
  );

  return { response, cached: false, savings: 0 };
}

類似度閾値がすべてを決める

SIMILARITY_THRESHOLDは最も重要なチューニングパラメータです。これを間違えると：

  • 高すぎる場合（>0.97）： ほぼ何もマッチしません。ヒット率ゼロ付近。高価なno-opを作っただけです。
  • 低すぎる場合（<0.85）： 無関係なクエリがキャッシュ応答を返します。ユーザーが間違った回答を受け取ります。

最適値はユースケースによって変わります：

ユースケース推奨閾値理由
FAQ / カスタマーサポート0.90 - 0.93質問がトピック別に集中するため
コード生成0.95 - 0.97微小なプロンプト差異が全く異なるコードを生むため
コンテンツ要約0.88 - 0.92同一文書なら表現に関係なく同じ要約になるため
クリエイティブライティングキャッシュ非推奨毎回異なる応答が求められるため

実際のコスト削減効果

月100,000件のクエリを処理するサポートチャットボットで計算してみましょう：

キャッシュなし：
  100,000クエリ × ~500入力トークン × ~800出力トークン
  = 50M入力 + 80M出力トークン
  GPT-4.1 mini: (50 × $0.20) + (80 × $0.80) = $74/月

セマンティックキャッシング適用（65%ヒット率）：
  35,000実API呼び出し + 65,000キャッシュヒット
  埋め込み: $0.04
  API: (17.5M × $0.20 + 28M × $0.80) / 1M = $25.90/月
  Vector DB: ~$10 / Redis: ~$5
  合計: ~$41/月 → 45%削減

これは控えめな65%ヒット率での計算です。反復パターンが明確なアプリケーション（サポートボット、ドキュメント検索）ではヒット率80%以上が一般的で、削減効果は70%を超えます。

戦略2：モデルルーティング

大半のチームが「余計に複雑になりそう」と敬遠する最適化ですが、数字は説得力があります。おそらく15/Mトークンのモデルで、15/Mトークンのモデルで、0.05/Mトークンのモデルで十分なタスクを処理しているはずです。

ルーティングのアーキテクチャ

考え方はシンプルです。高額モデルにリクエストを送る前に、クエリを分類し、処理できる最も安いモデルに振り分けます。

type ComplexityLevel = 'trivial' | 'simple' | 'moderate' | 'complex';

interface RouteConfig {
  model: string;
  maxTokens: number;
  temperature: number;
  costPer1MInput: number;
  costPer1MOutput: number;
}

const MODEL_ROUTES: Record<ComplexityLevel, RouteConfig> = {
  trivial: {
    model: 'gpt-4.1-nano',
    maxTokens: 256,
    temperature: 0.1,
    costPer1MInput: 0.05,
    costPer1MOutput: 0.20,
  },
  simple: {
    model: 'gpt-4.1-mini',
    maxTokens: 1024,
    temperature: 0.3,
    costPer1MInput: 0.20,
    costPer1MOutput: 0.80,
  },
  moderate: {
    model: 'claude-haiku-4.5',
    maxTokens: 2048,
    temperature: 0.5,
    costPer1MInput: 1.00,
    costPer1MOutput: 5.00,
  },
  complex: {
    model: 'claude-sonnet-4.6',
    maxTokens: 4096,
    temperature: 0.7,
    costPer1MInput: 3.00,
    costPer1MOutput: 15.00,
  },
};

async function classifyComplexity(prompt: string): Promise<ComplexityLevel> {
  // 最も安いモデルで分類 — メタ最適化！
  const classification = await openai.chat.completions.create({
    model: 'gpt-4.1-nano',
    max_tokens: 10,
    temperature: 0,
    messages: [
      {
        role: 'system',
        content: `Classify the user query complexity. Respond with ONLY one word:
          - "trivial": greeting, yes/no question, simple lookup
          - "simple": single-step task, basic Q&A, formatting
          - "moderate": multi-step reasoning, comparison, analysis
          - "complex": creative writing, code generation, deep research
          Respond with the single classification word only.`,
      },
      { role: 'user', content: prompt },
    ],
  });

  const level = classification.choices[0].message.content!
    .trim().toLowerCase() as ComplexityLevel;
  return MODEL_ROUTES[level] ? level : 'simple';
}

async function routedQuery(
  prompt: string,
  systemPrompt: string
): Promise<{ response: string; model: string; cost: number }> {
  const complexity = await classifyComplexity(prompt);
  const route = MODEL_ROUTES[complexity];

  const response = await callModel(route.model, systemPrompt, prompt, {
    maxTokens: route.maxTokens,
    temperature: route.temperature,
  });

  const inputTokens = estimateTokens(systemPrompt + prompt);
  const outputTokens = estimateTokens(response);
  const cost =
    (inputTokens / 1_000_000) * route.costPer1MInput +
    (outputTokens / 1_000_000) * route.costPer1MOutput;

  return { response, model: route.model, cost };
}

分類コストのパラドックス

「ちょっと待ってください — 分類のために追加のAPI呼び出しをしていますよね。それって余計にコストがかかるのでは？」

計算してみましょう。分類呼び出しはGPT-4.1 nanoで入力100トークン、出力5トークン：

クエリあたりの分類コスト：
  (100 / 1M) × $0.05 + (5 / 1M) × $0.20 = $0.000006

全部Claude Sonnet 4.6に送った場合のクエリあたりコスト：
  (500 / 1M) × $3.00 + (800 / 1M) × $15.00 = $0.0135

ルーティング適用（40% Sonnet, 30% Haiku, 20% Mini, 10% Nano）：
  = (0.4 × $0.0135) + (0.3 × $0.0045) + (0.2 × $0.00074) + (0.1 × $0.000185) + $0.000006
  = クエリあたり$0.0069

削減率：クエリあたり49%

分類器は自身のコストの1000倍を回収します。これは控えめな試算です。

応用：品質認識ルーティング + フォールバック

より高度なバージョンでは、ルーティングだけでなく、安いモデルの出力品質を検証します：

async function routedQueryWithFallback(
  prompt: string,
  systemPrompt: string,
  qualityThreshold: number = 0.7
): Promise<{ response: string; model: string; attempts: number }> {
  const complexity = await classifyComplexity(prompt);
  const route = MODEL_ROUTES[complexity];

  const response = await callModel(route.model, systemPrompt, prompt, {
    maxTokens: route.maxTokens,
  });

  // complex以外のルートでは安価なチェックで品質検証
  if (complexity !== 'complex') {
    const qualityScore = await quickQualityCheck(prompt, response);

    if (qualityScore < qualityThreshold) {
      // 次のティアにエスカレーション
      const nextTier = getNextTier(complexity);
      const betterResponse = await callModel(
        MODEL_ROUTES[nextTier].model,
        systemPrompt,
        prompt,
        { maxTokens: MODEL_ROUTES[nextTier].maxTokens }
      );
      return { response: betterResponse, model: MODEL_ROUTES[nextTier].model, attempts: 2 };
    }
  }

  return { response, model: route.model, attempts: 1 };
}

戦略3：プロンプト圧縮

大半のプロンプトは肥大化しています。特にシステムプロンプトは、時間とともに指示・例・エッジケースが追加されて膨らみがちです。200トークンで始まったシステムプロンプトが2,000トークンに膨れ上がり — そのコストがすべてのリクエストで乗算されます。

システムプロンプトを点検する

Before（847トークン）：

You are a helpful customer support assistant for our e-commerce platform.
You should always be polite and professional in your responses.
When a customer asks about their order, you should look up the order
details and provide them with relevant information about the status
of their order, including the tracking number if available...
（さらに400トークン続く）

After（189トークン）：

E-commerce support agent. Rules:
- Lookup order details, provide status + tracking if available
- If no access to order data, direct to support team
- Match customer's language
- Never reveal internal systems/pricing/employee info
- For frustrated customers: acknowledge → empathize → solve
- Tone: professional, warm, concise

同じ動作でトークン78%削減。GPT-4.1 miniで月100,000件なら：

トークン削減: 658トークン × 100,000 = 65.8Mトークン/月
コスト削減: (65.8 / 1M) × $0.20 = 月$13.16（入力のみ）

13/月は少額に見えますが、積み重なります。AI機能が10個あってそれぞれプロンプトが肥大化していたら、月13/月は少額に見えますが、積み重なります。AI機能が10個あってそれぞれプロンプトが肥大化していたら、月130 — 年間$1,560 — システムプロンプトの整理だけで削減できます。

プログラムによるプロンプト圧縮

コンテキストを含む動的プロンプト（RAG、会話履歴）は、送信前に圧縮します：

function compressConversationHistory(
  messages: Array<{ role: string; content: string }>,
  maxTokens: number = 2000
): Array<{ role: string; content: string }> {
  const estimated = messages.reduce(
    (sum, m) => sum + estimateTokens(m.content),
    0
  );

  if (estimated <= maxTokens) return messages;

  // 戦略：最初のメッセージ（コンテキスト）と最後のN件を保持
  // 中間を要約
  const first = messages[0];
  const last3 = messages.slice(-3);
  const middle = messages.slice(1, -3);

  if (middle.length === 0) return messages;

  const middleSummary = middle
    .map(m => `${m.role}: ${m.content.slice(0, 50)}...`)
    .join('\n');

  return [
    first,
    {
      role: 'system',
      content: `[会話の要約: ${middleSummary}]`,
    },
    ...last3,
  ];
}

出力トークンの罠

覚えておいてください：出力トークンは入力トークンの3-5倍高い。max_tokensの設定はコスト制御の最も簡単な方法です：

// ❌ 良くない例：モデルに長さを任せる
const response = await openai.chat.completions.create({
  model: 'gpt-4.1-mini',
  messages: [{ role: 'user', content: 'この記事を要約して' }],
  // max_tokensなし = モデルが長さを決定
});

// ✅ 良い例：出力長を制限
const response = await openai.chat.completions.create({
  model: 'gpt-4.1-mini',
  messages: [{ role: 'user', content: 'この記事を3文で要約して。' }],
  max_tokens: 200, // セーフティネットとして
});

構造化された出力が必要な場合はJSONモードを使います — 一貫して短く予測可能な応答が得られます：

const response = await openai.chat.completions.create({
  model: 'gpt-4.1-mini',
  response_format: {
    type: 'json_schema',
    json_schema: {
      name: 'sentiment_analysis',
      schema: {
        type: 'object',
        properties: {
          sentiment: { type: 'string', enum: ['positive', 'negative', 'neutral'] },
          confidence: { type: 'number' },
          keywords: { type: 'array', items: { type: 'string' }, maxItems: 5 },
        },
        required: ['sentiment', 'confidence', 'keywords'],
      },
    },
  },
  messages: [{ role: 'user', content: `分析: "${text}"` }],
  max_tokens: 100,
});

戦略4：バッチ処理

ワークロードがリアルタイムでなくてよいなら、バッチAPIが大幅割引を提供します。OpenAIのBatch APIはリアルタイム呼び出しより50%安い。夜間コンテンツ生成、一括分類、データ補強などのバックグラウンド処理には、もらい得です。

バッチ処理が適切な場面

リアルタイム必須：
  ✗ ユーザー対面チャット
  ✗ リアルタイムコード補完
  ✗ インタラクティブ検索

バッチ向き：
  ✓ 夜間コンテンツ要約
  ✓ メール一括分類
  ✓ 週次レポート生成
  ✓ データラベリング・補強
  ✓ コンテンツモデレーションの溜まり処理
  ✓ 翻訳の一括処理

実装

import { OpenAI } from 'openai';
import * as fs from 'fs';

const openai = new OpenAI();

interface BatchItem {
  custom_id: string;
  method: 'POST';
  url: '/v1/chat/completions';
  body: {
    model: string;
    messages: Array<{ role: string; content: string }>;
    max_tokens: number;
  };
}

async function submitBatchJob(
  items: Array<{ id: string; prompt: string }>,
  systemPrompt: string,
  model: string = 'gpt-4.1-mini'
): Promise<string> {
  // 1. JSONLファイルを作成
  const batchLines: string[] = items.map(item => {
    const batchItem: BatchItem = {
      custom_id: item.id,
      method: 'POST',
      url: '/v1/chat/completions',
      body: {
        model,
        messages: [
          { role: 'system', content: systemPrompt },
          { role: 'user', content: item.prompt },
        ],
        max_tokens: 1024,
      },
    };
    return JSON.stringify(batchItem);
  });

  const filePath = `/tmp/batch-${Date.now()}.jsonl`;
  fs.writeFileSync(filePath, batchLines.join('\n'));

  // 2. ファイルをアップロード
  const file = await openai.files.create({
    file: fs.createReadStream(filePath),
    purpose: 'batch',
  });

  // 3. バッチを作成
  const batch = await openai.batches.create({
    input_file_id: file.id,
    endpoint: '/v1/chat/completions',
    completion_window: '24h',
  });

  return batch.id;
}

async function checkBatchStatus(batchId: string) {
  const batch = await openai.batches.retrieve(batchId);

  if (batch.status === 'completed') {
    const file = await openai.files.content(batch.output_file_id!);
    const text = await file.text();
    const results = text
      .split('\n')
      .filter(Boolean)
      .map(line => JSON.parse(line));
    return results;
  }

  return { status: batch.status, progress: `${batch.request_counts.completed}/${batch.request_counts.total}` };
}

コスト効果

毎晩10,000件を処理するジョブの場合：

リアルタイムAPI（GPT-4.1 mini）：
  10,000 × (500入力 + 800出力トークン)
  = (5M × $0.20 + 8M × $0.80) / 1M = $7.40

バッチAPI（50%割引）：
  = $3.70

月間削減：~$111（毎日実行の場合）
年間削減：~$1,332

戦略5：LLMゲートウェイとオブザーバビリティ

測定できないものは最適化できません。LLMゲートウェイをアプリケーションとAPIプロバイダーの間に配置すると：

  • 機能別コスト帰属 — どの機能がお金を消費しているか把握
  • 自動リトライ・フェイルオーバー — OpenAI障害時にAnthropicに切り替え
  • レート制限 — バグや悪用によるコスト暴走を防止
  • 使用量分析 — 最適化ポイントの発見

軽量ゲートウェイの構築

interface LLMRequest {
  featureId: string;
  prompt: string;
  systemPrompt: string;
  model?: string;
  maxTokens?: number;
  userId?: string;
}

interface LLMMetrics {
  featureId: string;
  model: string;
  inputTokens: number;
  outputTokens: number;
  cost: number;
  latencyMs: number;
  cached: boolean;
  timestamp: number;
}

class LLMGateway {
  private metrics: LLMMetrics[] = [];
  private rateLimiter: Map<string, { count: number; resetAt: number }> = new Map();

  async query(request: LLMRequest): Promise<string> {
    // 1. レート制限
    this.enforceRateLimit(request.featureId);

    // 2. 予算チェック
    await this.checkBudget(request.featureId);

    const startTime = Date.now();

    // 3. セマンティックキャッシュを優先
    const cached = await queryWithSemanticCache(
      request.prompt,
      request.systemPrompt,
      request.model
    );

    if (cached.cached) {
      this.recordMetrics({
        featureId: request.featureId,
        model: request.model || 'gpt-4.1-mini',
        inputTokens: 0, outputTokens: 0, cost: 0,
        latencyMs: Date.now() - startTime,
        cached: true, timestamp: Date.now(),
      });
      return cached.response;
    }

    // 4. 最適モデルにルーティング
    const result = await routedQuery(request.prompt, request.systemPrompt);

    // 5. メトリクスを記録
    this.recordMetrics({
      featureId: request.featureId,
      model: result.model,
      inputTokens: estimateTokens(request.prompt + request.systemPrompt),
      outputTokens: estimateTokens(result.response),
      cost: result.cost,
      latencyMs: Date.now() - startTime,
      cached: false, timestamp: Date.now(),
    });

    return result.response;
  }

  getFeatureCosts(period: 'day' | 'week' | 'month'): Record<string, number> {
    const cutoff = {
      day: 86400000,
      week: 604800000,
      month: 2592000000,
    }[period];

    const recent = this.metrics.filter(
      m => Date.now() - m.timestamp < cutoff
    );

    return recent.reduce((acc, m) => {
      acc[m.featureId] = (acc[m.featureId] || 0) + m.cost;
      return acc;
    }, {} as Record<string, number>);
  }

  private enforceRateLimit(featureId: string) {
    const limit = this.rateLimiter.get(featureId);
    const now = Date.now();

    if (limit && now < limit.resetAt && limit.count >= 1000) {
      throw new Error(`Rate limit exceeded for feature: ${featureId}`);
    }

    if (!limit || now >= limit.resetAt) {
      this.rateLimiter.set(featureId, { count: 1, resetAt: now + 60000 });
    } else {
      limit.count++;
    }
  }

  private async checkBudget(featureId: string) {
    const monthlyCosts = this.getFeatureCosts('month');
    const featureBudget = await getFeatureBudget(featureId);

    if ((monthlyCosts[featureId] || 0) >= featureBudget) {
      throw new Error(
        `Monthly budget exceeded for ${featureId}: $${monthlyCosts[featureId]?.toFixed(2)} / $${featureBudget}`
      );
    }
  }

  private recordMetrics(metrics: LLMMetrics) {
    this.metrics.push(metrics);
    // 本番環境：分析パイプラインに送信
  }
}

必要なダッシュボード

最低限、機能別・日別で以下を追跡すべきです：

┌─────────────────────────────────────────────┐
│ LLMコストダッシュボード - 2026年3月         │
├──────────────┬────────┬────────┬────────────┤
│ 機能         │ 呼出数  │  コスト │ キャッシュ │
├──────────────┼────────┼────────┼────────────┤
│ チャット支援  │ 45,231 │ $89.40 │    72%     │
│ コードレビュー │ 12,847 │ $67.20 │    34%     │
│ 要約         │  8,392 │ $12.10 │    81%     │
│ 検索         │ 31,094 │ $23.40 │    68%     │
│ 翻訳         │  3,201 │  $8.90 │    45%     │
├──────────────┼────────┼────────┼────────────┤
│ 合計         │100,765 │$201.00 │    63%     │
└──────────────┴────────┴────────┴────────────┘

 先月（最適化なし）：$890
 今月（全戦略適用後）：$201
 総削減額：$689（77%）

すべてを組み合わせる：最適化スタック

これらの戦略は複合的に効果を発揮します：

受信LLMリクエスト
        │
        ▼
  ┌─────────────┐
  │ レート制限   │─── 超過？ → エラー
  └──────┬──────┘
         │
         ▼
  ┌──────────────┐
  │ 予算チェック  │─── 超過？ → エラー
  └──────┬───────┘
         │
         ▼
  ┌─────────────────────┐
  │ セマンティックキャッシュ │─── ヒット？ → キャッシュ返却
  └──────────┬──────────┘
             │ ミス
             ▼
  ┌────────────────────┐
  │ プロンプト圧縮      │─── トークン削減
  └──────────┬─────────┘
             │
             ▼
  ┌────────────────────┐
  │ モデルルーター       │─── 処理可能な最安モデルを選択
  └──────────┬─────────┘
             │
             ▼
  ┌────────────────────┐
  │ API呼出 + メトリクス │─── すべて記録
  └──────────┬─────────┘
             │
             ▼
  ┌────────────────────┐
  │ レスポンスキャッシュ  │─── 将来のヒット用に保存
  └────────────────────┘

現実的な総合削減効果

実際のアプリケーションでモデリングしてみましょう — 月200,000件のクエリを処理する開発ドキュメントアシスタントが、すべてClaude Sonnet 4.6で処理している場合：

基準（最適化なし）：
  200,000クエリ × 600平均入力 × 1,200平均出力トークン
  入力：120Mトークン × $3.00/1M = $360
  出力：240Mトークン × $15.00/1M = $3,600
  合計：$3,960/月

最適化スタック適用後：
  1. セマンティックキャッシング（70%ヒット率）：140,000件のクエリ削減
     残り：60,000件 / 埋め込み：$0.24 / キャッシュインフラ：$15/月

  2. 残り60,000件のルーティング：
     - 15% complex → Claude Sonnet 4.6（9,000件）
     - 25% moderate → Claude Haiku 4.5（15,000件）
     - 40% simple → GPT-4.1 mini（24,000件）
     - 20% trivial → GPT-4.1 nano（12,000件）

  3. プロンプト圧縮：全体で30%トークン削減

  コスト計算：
     Sonnet: $124.74 / Haiku: $69.30
     Mini: $18.14 / Nano: $2.27
     分類器: $0.36 / キャッシュインフラ: $15 / 埋め込み: $0.24

  合計：~$230/月

  削減：月$3,730（94%減）

3,960から3,960から230へ。年間$44,760の削減です。多くのスタートアップにとって、これは黒字化とランウェイ枯渇の分かれ目です。

避けるべきよくある失敗

1. 無効化なしのキャッシング

キャッシュ応答は古くなります。製品情報が変わったのにチャットボットが昨日の回答を返してはいけません。TTLの設定と、コンテンツ更新時の手動キャッシュ破棄を実装してください。

2. 安いモデルへの過度なルーティング

ユーザーの5%が誤分類されたクエリで品質の低い応答を受け取れば、コストは削減できても信頼を失います。品質スコアを監視し、上述のフォールバックパターンを使いましょう。

3. 過度な圧縮

プロンプトからコンテキストを削ると、応答品質が微妙に低下することがあります。プロンプト変更は必ず品質メトリクスと合わせてA/Bテストしてから本番適用してください。

4. プロバイダー間の違いを無視

各プロバイダーに長所があります。Claudeは長文分析に強く、GPT-4.1 nanoは分類のコスパが最強、Gemini Flashは汎用タスクの価格対性能比が優秀です。一つのプロバイダーに固定しないでください。

5. 埋め込みコストの見落とし

セマンティックキャッシングは全クエリの埋め込みが必要です。大規模では無視できなくなります。text-embedding-3-smallを使い（largeではなく）、可能なら埋め込みリクエストもバッチ処理してください。

まとめ

LLM APIコストは物理法則ではありません — エンジニアリングで解決できるエンジニアリングの問題です。このガイドの5つの戦略 — セマンティックキャッシング、モデルルーティング、プロンプト圧縮、バッチ処理、オブザーバビリティ — で、ユーザー体験を損なわずにコストを70-90%削減できます。

実装の優先順位はこちらです：

  1. セマンティックキャッシング — ROI最大、最初に実装
  2. プロンプト圧縮 — クイックウィン、今日システムプロンプトを点検
  3. モデルルーティング — 削減効果大、複雑さは中程度
  4. オブザーバビリティ — 次の最適化ポイントを見つけるために必要
  5. バッチ処理 — バックグラウンドのワークロードで手軽に削減

まず一つの戦略から始めて効果を測定し、その上に次の戦略を積み重ねてください。私の経験では、5つすべてを実装したチームは「シリーズBをOpenAIの請求書のために調達する必要があるかも」から「LLMコストは丸め誤差レベル」に変わります。

API請求書が怖い必要はありません。退屈なものにしてしまいましょう。

AILLMOpenAIAnthropiccost-optimizationsemantic-cachingprompt-engineeringTypeScript

関連ツールを見る

Pockitの無料開発者ツールを試してみましょう

PDF回転
ページの向きを正しく修正できます。ブラウザ内で完結するため、機密文書でも安全に回転・保存が可能です。
使ってみる
PDF圧縮
共有しやすいサイズに軽量化しましょう。セキュリティを保ちながら、画質と容量のバランスを調整してPDFを圧縮します。
使ってみる
コード整形・圧縮
1行にギュッと詰まった圧縮コードを読みやすく整形したり、本番用にサイズを小さくしたり。JS、CSS、HTML対応。ブラウザで完結するからコードは外に出ません。
使ってみる
JSONフォーマッター
乱雑なデータを見た目良く整理しましょう。JSONの構文エラーを自動で修正し、読みやすい形式に整形します。
使ってみる
年齢計算機
大切な日を忘れません。正確な満年齢だけでなく、次の誕生日までの日数も一瞬で計算します。
使ってみる
D-Day計算機
大切な日までカウントダウン。誕生日、試験、記念日、旅行などを一目で管理できます。
使ってみる