DEV Community

Cover image for Claude APIの費用を抑える方法：Opus 4.8とFable 5
Akira
Akira

Posted on • Originally published at apidog.com

Claude APIの費用を抑える方法：Opus 4.8とFable 5

Claudeの利用料金でまず見るべきなのは、出力トークンよりも入力トークンです。Claude APIはステートレスなので、各リクエストでシステムプロンプト、ツール定義、貼り付けたドキュメント、過去メッセージを含む会話履歴全体を再送信します。長いエージェントループやClaude Codeセッションでは、この再送信コンテキストが膨らみ、リクエストごとに入力料金として効いてきます。

今すぐApidogを試す

したがって、Claude APIコストを下げる実装方針はシンプルです。

  1. 送信する入力を減らす
  2. トークン単価を下げる
  3. 不要なコンテキストの再送信を止める
  4. 開発・テスト中はライブAPIを叩かない

料金メーター、トークン、キャッシュ、バッチ課金の基本を先に確認したい場合は、Claude APIコスト解説を参照してください。この記事では、実装時にどこを変更すればコストが下がるかに絞ります。

テコ1：プロンプトキャッシュを使う

プロンプトキャッシュは、多くのエージェント実装で最初に入れるべきコスト削減策です。

対象にするのは、リクエスト間で変わらない長いプレフィックスです。

  • システムプロンプト
  • ツール定義
  • 長い仕様書・参照ドキュメント
  • 固定のルールセット

これらをキャッシュ可能にすると、次回以降、同じバイト列で始まるリクエストはキャッシュから読み取られます。

キャッシュ読み取りは基本入力料金の約0.1倍なので、キャッシュされた部分は最大約90%削減できます。一方、キャッシュ書き込みは通常入力より高く、5分TTLで1.25倍、1時間TTLで2倍です。つまり、1回しか使わないプレフィックスをキャッシュすると逆に高くなります。

目安は次の通りです。

TTL 損益分岐の目安
5分 約2リクエスト
1時間 約3リクエスト

実装時の注意点

キャッシュはバイトレベルのプレフィックスマッチです。見た目には同じプロンプトでも、1文字でも変われば別物として扱われます。

キャッシュ対象に入れてはいけないもの：

  • タイムスタンプ
  • セッションID
  • リクエストID
  • カウンター
  • ランダム値
  • 並び順が毎回変わるツール定義
  • ユーザーごとに変わる一時情報

悪い例：

System:
You are a coding assistant.
Current time: 2026-01-12T10:23:45Z
Session ID: abc-123
...
Enter fullscreen mode Exit fullscreen mode

良い例：

System:
You are a coding assistant.
Follow these coding rules:
...
Enter fullscreen mode Exit fullscreen mode

動的な情報は、キャッシュ対象の後ろに分離してください。

キャッシュが効いているか確認する

レスポンスの usage.cache_read_input_tokens を必ず確認します。

{
  "usage": {
    "input_tokens": 1200,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 24000,
    "output_tokens": 800
  }
}
Enter fullscreen mode Exit fullscreen mode

同じプレフィックスを使う繰り返しリクエストで cache_read_input_tokens がゼロのままなら、どこかが毎回変化しています。キャッシュの詳細は、プロンプトキャッシュとは何か、その仕組みを参照してください。

テコ2：タスクごとにモデルをルーティングする

コスト超過で多いのは、すべてのタスクを必要以上に大きなモデルで処理することです。

Claudeはモデルごとに価格帯が異なるため、アプリケーション側でタスク別にルーティングします。

モデル モデルID 入力 出力 コンテキストウィンドウ
Fable 5 claude-fable-5 $10 $50 1M
Opus 4.8 claude-opus-4-8 $5 $25 1M
Sonnet 5 claude-sonnet-5 $3 ($2 intro) $15 ($10 intro) 1M
Haiku 4.5 claude-haiku-4-5 $1 $5 200K

この表から、実装上の判断は次のようになります。

  • Fable 5：最も困難な長期推論に限定する
  • Opus 4.8：Claude Code、複雑なエージェント、コーディング支援の標準候補
  • Sonnet 5：品質とコストのバランスが必要な大量トラフィック向け
  • Haiku 4.5：分類、抽出、ルーティング、短い返信などの軽量タスク向け

例えば、ルーティング関数を用意してモデル選択を明示します。

type TaskType =
  | "simple_classification"
  | "short_extraction"
  | "coding_agent"
  | "long_reasoning"
  | "bulk_production";

function selectClaudeModel(task: TaskType): string {
  switch (task) {
    case "simple_classification":
    case "short_extraction":
      return "claude-haiku-4-5";

    case "bulk_production":
      return "claude-sonnet-5";

    case "coding_agent":
      return "claude-opus-4-8";

    case "long_reasoning":
      return "claude-fable-5";

    default:
      return "claude-opus-4-8";
  }
}
Enter fullscreen mode Exit fullscreen mode

Fable 5はOpus 4.8の2倍の入力・出力単価です。Opusで十分なタスクをFableに送ると、品質差が出ないまま請求だけが増えます。

Fable 5には請求上の補足があります。安全性分類器がリクエストを拒否した場合、ベータ版の fallbacks パラメーターによって、そのターンをOpus 4.8に再ルーティングできます。再ルーティングされたターンはOpusの料金で請求されます。FableトラフィックにOpus価格の行が出る可能性がある点は把握しておきましょう。

詳細な料金比較は、Opus 4.8の料金、Fable 5の料金、Fable 5 vs Opus 4.8の比較を参照してください。評価時に低コストまたは無料で試したい場合は、Opus 4.8を無料で利用する方法とFable 5 APIを直接呼び出す方法も確認できます。

テコ3：リアルタイム不要な処理はバッチAPIに送る

リアルタイム応答が不要な処理は、バッチAPIに移します。

/v1/messages/batches にジョブを送ると非同期で実行され、結果を後で取得できます。多くのバッチは1時間以内に完了し、上限は24時間です。バッチでは入力・出力を含むすべてのトークン料金に50%割引が適用されます。

バッチ向きの処理：

  • 評価データセット全体の実行
  • バックログに対する一括分類
  • 既存レコードの要約・タグ付け
  • 抽出処理
  • 夜間ジョブ
  • 数分〜数時間の遅延が許容されるオフライン処理

アプリケーションでは、同期処理とバッチ処理を分けます。

function shouldUseBatchJob(job: {
  requiresRealtime: boolean;
  itemCount: number;
  isNightlyJob: boolean;
}) {
  if (job.requiresRealtime) return false;
  if (job.isNightlyJob) return true;
  if (job.itemCount > 100) return true;

  return false;
}
Enter fullscreen mode Exit fullscreen mode

夜間処理や評価実行を同期エンドポイントで回している場合、バッチ化するだけで該当部分のトークン料金を50%削減できます。品質を変えずにレイテンシだけをトレードオフにできるため、検討しやすい施策です。

テコ4：effort、max_tokens、count_tokensを明示する

リクエスト単位のコストを制御するには、次の3つを設定します。

output_config.effort

output_config.effort は、モデルが応答前にどの程度思考するかを制御します。

指定できる値：

  • low
  • medium
  • high
  • xhigh
  • max

思考トークンも課金対象です。すべてを high 以上で実行するのではなく、タスクごとに下げて評価します。

例：

{
  "model": "claude-opus-4-8",
  "messages": [
    {
      "role": "user",
      "content": "このログを分類してください。"
    }
  ],
  "output_config": {
    "effort": "low"
  },
  "max_tokens": 300
}
Enter fullscreen mode Exit fullscreen mode

分類、抽出、短い変換では low や medium で十分なことが多いです。品質が維持されるなら、思考トークンと出力トークンを削減できます。

max_tokens

max_tokens は出力の上限です。

短いはずのレスポンス自体を安くするものではありませんが、暴走出力を止められます。

例えば、JSONだけが必要なら上限を小さくします。

{
  "model": "claude-haiku-4-5",
  "messages": [
    {
      "role": "user",
      "content": "次の問い合わせを billing / technical / other のJSONで分類してください。"
    }
  ],
  "max_tokens": 100
}
Enter fullscreen mode Exit fullscreen mode

「JSONを返して」と指示したのに長い説明文を出されるケースを防げます。

count_tokens

送信前に count_tokens で入力トークン数を見積もります。

ここで tiktoken を使わないでください。tiktoken はOpenAI向けのトークナイザーであり、Claudeのトークン数を約15〜20%少なく見積もる可能性があります。

リクエストあたりの予算を超えそうな場合は、送信前に止める実装にします。

const MAX_INPUT_TOKENS = 50_000;

async function assertTokenBudget(inputTokens: number) {
  if (inputTokens > MAX_INPUT_TOKENS) {
    throw new Error(
      `Input is too large: ${inputTokens} tokens. Reduce context before sending.`
    );
  }
}
Enter fullscreen mode Exit fullscreen mode

テコ5：再送信するコンテキストを削る

Claude APIはステートレスなので、長い会話では毎回履歴全体を送ります。

しかし30ターン目の時点では、過去の多くは不要になっています。

  • すでに処理済みのツール出力
  • 使わなかった探索結果
  • 一度読んだだけのファイル内容
  • もう参照されない中間ログ

これらを毎ターン再送信すると、入力料金が膨らみます。

Anthropic側には、これを抑えるサーバーサイド機能があります。

  • コンテキスト編集：clear_tool_uses_20250919
    • 古いツール結果を再送信コンテキストから削除する
  • 圧縮：compact_20260112
    • 古い履歴を短い形式に要約する

これらはサーバーサイドで動作するため、自前で要約器を書いたり、メッセージ配列を手動で切り詰めたりする負担を減らせます。

長時間のClaude Codeセッションでは、コンテキスト上限に到達する問題とも直結します。詳しくはClaude Codeのトークンウィンドウとリセットを参照してください。

実装上の判断はシンプルです。モデルがもう必要としない履歴を、次のターンに送らないでください。

さらに進んで：pxpipeでコンテキストを画像化する

Anthropic側のテコは、トークンを減らすか、単価を下げる方法です。pxpipeは別のアプローチを取ります。

pxpipeは、クライアントとAnthropic APIの間に置くローカルプロキシです。MITライセンスで、TypeScriptで書かれています。ANTHROPIC_BASE_URL をpxpipeに向けると、リクエスト送信前に内容を検査します。

仕組み

pxpipeは、かさばる安定したコンテキストをPNG画像に変換します。

対象になり得るもの：

  • システムプロンプト
  • ツールドキュメント
  • 古い履歴
  • 密度の高い長文コンテキスト

プロジェクトの報告では、約48,000文字のシステムプロンプトとツールドキュメントが、テキストでは約25,000トークン、画像では約2,700トークンになる例があります。

ただし、pxpipeはすべてを画像化するわけではありません。トークン計算上有利な場合のみ画像化し、まばらなテキストはそのまま通します。

インストールと実行 

npx pxpipe-proxy
Enter fullscreen mode Exit fullscreen mode

これで 127.0.0.1:47821 にプロキシが起動します。

Claude Codeをpxpipe経由で実行します。

ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude
Enter fullscreen mode Exit fullscreen mode

モデルサポート

デフォルトでは、pxpipeは claude-fable-5 とGPT 5.6のリクエストを画像化します。

Opus 4.7/4.8とGPT 5.5はオプトインです。プロジェクトは、これらのモデルが画像化されたコンテキストを著しく悪く読み取ると報告しています。有効化する場合は、PXPIPE_MODELS 環境変数またはプロキシURLのダッシュボードを使います。

報告されている削減効果

以下はpxpipeプロジェクト自身の報告値であり、独自検証値ではありません。

  • 本番スナップショットで59%の節約
  • 13,709リクエストで100ドルの請求が約41ドルに減少
  • SWE-bench Liteパイロットでリクエストサイズが65%削減

自分のトラフィックで必ず検証してください。

トレードオフ

pxpipeを使う前に、次の点を確認します。

プロンプトキャッシュと競合する可能性がある

プロンプトキャッシュはバイトレベルのプレフィックス一致です。画像化はリクエストのバイト列を変えるため、キャッシュと競合する可能性があります。

「キャッシュ + 画像化」で単純に効果が足し算されるとは考えないでください。実際のプレフィックスで両方をベンチマークします。

モデルは画像化された文字を視覚的に読む

長い16進数ID、正確なトークン、細かい文字列などは誤読される可能性があります。しかも、誤読はエラーとして返らない場合があります。

品質検証なしで本番投入しないでください。

リクエストパス上のプロキシになる

ローカル実行とはいえ、pxpipeはリクエストパス上に入ります。本番トラフィックを通す前に、セキュリティ要件と照らし合わせて評価してください。

コンテキストが大きく、密で、安定している場合はpxpipeを試す価値があります。一方、まばらなテキストやプロンプトキャッシュがよく効くワークロードでは、Anthropic側の機能だけで十分な可能性があります。

開発・テスト中のトークン消費を削減する

ここまでの施策は、本番または本番に近いClaude API利用のコストを下げるものです。

一方で、統合を作っている間にも有料トークンは消費されます。

  • 失敗した実行
  • リトライ
  • パース処理のデバッグ
  • エラーハンドリングの確認
  • CIでの自動テスト
  • プロンプト形状の調整

これらの多くは、実際のClaudeモデルを呼ばなくても検証できます。

Apidogが本番Claude請求額を削減するわけではありません。削減できるのは、開発・テストループで消費していたトークンです。

ApidogでAnthropic APIをモックする

ApidogでClaudeエンドポイントのリクエストとレスポンスのコントラクトを定義し、開発環境やCIをモックAPIに向けます。

実装手順は次の通りです。

  1. Claude API呼び出しのリクエスト形式を定義する
  2. 期待するレスポンス形式を定義する
  3. 成功レスポンス、エラーレスポンス、レート制限などのモックを用意する
  4. アプリケーションのAPIベースURLをモックサーバーに向ける
  5. テストとCIではモックを叩く
  6. 本番環境のみAnthropic APIに向ける

例えば、アプリケーション側でベースURLを環境変数化します。

const ANTHROPIC_BASE_URL =
  process.env.ANTHROPIC_BASE_URL ?? "https://api.anthropic.com";
Enter fullscreen mode Exit fullscreen mode

開発・CIではモックURLを指定します。

ANTHROPIC_BASE_URL=https://your-mock-server.example.com npm test
Enter fullscreen mode Exit fullscreen mode

これにより、パース処理、リトライ処理、エラー分岐、レスポンススキーマの検証を、有料トークンなしで回せます。

テコを組み合わせる

Claude APIコスト削減は、1つの設定で完了するものではありません。次の順で実装すると効果を測定しやすくなります。

  1. 安定したプレフィックスをキャッシュする

    • システムプロンプト、ツール、ドキュメントを対象にする
    • cache_read_input_tokens を確認する

  2. モデルをタスク別にルーティングする

    • 軽量タスクはHaiku
    • 大量処理はSonnet
    • エージェント・コーディングはOpus
    • Fableは必要な場合だけ使う

  3. オフライン処理をバッチ化する

    • 評価、夜間処理、一括分類を /v1/messages/batches に移す

  4. リクエストごとに上限を設定する

    • effort を下げて評価する
    • max_tokens で暴走出力を止める
    • count_tokens で送信前に見積もる

  5. 不要な履歴を再送信しない

    • コンテキスト編集と圧縮を使う
    • 古いツール結果や不要な履歴を持ち回らない

  6. pxpipeを検証する

    • 大きく密なコンテキストでのみ候補にする
    • キャッシュとの比較ベンチマークを行う

  7. 開発中はモックを使う

    • テストとCIを有料メーターから切り離す

最初に着手するなら、プロンプトキャッシュとモデルルーティングです。この2つが、多くのワークロードで最も大きな削減につながります。変更ごとに測定し、実際の請求額で判断してください。

FAQ

Claudeの請求額では、入力トークンと出力トークンのどちらが問題になりますか？

トークン単価は出力の方が高いです。ただし、エージェントやコーディング用途では、会話履歴全体を毎回再送信するため、入力トークンが請求額の大部分を占めることが多いです。そのため、主な削減対象は入力トークンです。

プロンプトキャッシュとバッチAPIはどちらが節約できますか？

ワークロードによります。プロンプトキャッシュは、繰り返し使うプレフィックスに対して最大約90%の削減が見込めます。バッチAPIは非同期でよい処理に対して一律50%削減できます。対話型処理はキャッシュ、オフライン処理はバッチ、という使い分けが現実的です。

すべてFable 5にすべきですか？

いいえ。Fable 5はOpus 4.8の2倍のコストがかかります。最も困難な長期推論に限定し、通常のエージェント作業やコーディング作業ではOpus 4.8を候補にします。軽量タスクはSonnetやHaikuに落とします。

pxpipeはプロンプトキャッシュと併用できますか？

単純には併用できません。画像化はリクエストのバイト列を変え、プロンプトキャッシュはバイトレベルで一致するプレフィックスを使います。両方を実際のワークロードで測定し、どちらが安くなるか確認してください。

Apidogは本番環境のClaudeコストを削減しますか？

いいえ。ApidogはAnthropic APIをモックすることで、開発・テスト・CI中の有料トークン消費を減らします。本番トラフィックのClaude請求額を直接下げるものではありません。

Top comments (0)