Claude APIの料金を抑える方法：実践的なトークンコストガイド

トークン予算の考え方

すべてのリクエストには、費用を左右する要素が二つあります。

• 入力トークン：システムプロンプト、ユーザーメッセージ、会話履歴、ツール定義、取得したドキュメント、およびキャッシュが適用されない場合に計上されるキャッシュ対象のプレフィックス。
• 出力トークン数：モデルの回答。意図しない冗長な出力や再試行も含みます。

考え方として役立つ式は、次のとおりです。

request_cost ≈ input_tokens × input_rate + output_tokens × output_rate

当たり前に聞こえるかもしれませんが、この考え方によって費用の原因を調べる方法が変わります。平均的なリクエストで出力の費用が「安い」一方、入力の費用が高いなら、モデルに簡潔な回答を求めるよりも、システムプロンプトから400トークンを削るほうが効果的かもしれません。

モデル選びから始める

すべてのタスクに最も高性能なモデルが必要なわけではありません。実際のシステムでは、モデルの選択が最も低コストな最適化になることがよくあります。

よくある落とし穴は、「初期選択を上位モデルにする」ことです。チームは、安心できるという理由で、すべてのプロンプトを最上位モデルに送ることがよくあります。実際には、その恩恵を受けないタスクに高額な保険料を払っているようなものです。通常、ルーティング層を設ける価値はあります。

• Haiku は、迅速な分類、JSONの抽出、ログのラベル付け、初期トリアージに使用します。
• Sonnet は、エージェント型の処理や開発者ツールのワークロードの大半に使用します。
• Opus は、タスクがより強力な推論や細やかな情報統合を本当に必要とする場合、または失敗のコストを測定済みの場合にのみ使用します。

効果的なシンプルな方針は、次のとおりです。

1. 低コストで処理できる構造化タスクには、まずHaikuを試します。
2. 確信度が低い場合や出力形式が不正な場合は、Sonnetに切り替えます。
3. 本当に難しいケースに限り、Opusに切り替えます。

このように段階的に切り替える仕組みは、通常、すべてのリクエストでOpusの料金を支払うよりも安くなります。

システムプロンプトを徹底的に削る

システムプロンプトは、目につく場所にトークンの無駄が潜むところです。技術的負債のように増えがちで、方針の一文、スタイルのルール、誰も削除しなかった五つの例が少しずつ積み重なっていきます。

削除するもの

• アプリケーションがすでに強制している、重複した指示。
• 動作を変えない、長々とした「役に立つように」という文章。
• すでに重要ではなくなった例外的なケースの古い例。
• リクエストごとに繰り返されるポリシーの文章。
• 簡潔なスキーマで十分な場合の、冗長なツール説明。

残すもの

• 必ず守るべき動作上の制約。
• 出力形式のルール。
• 安全性に不可欠な指示。
• 信頼性を実質的に高める最小限の例。

実際に、モデルの品質を変えずに、繰り返し使うプレフィックスから数百、数千のトークンを削減したチームを見てきました。コツは、システムプロンプトを本番コードのように扱うことです。使われていない文章を削除し、重複するルールを整理して、動作に影響するものだけを残します。

より良い方法は、文章ではなく構造として表現することです。

{
  "style": "concise",
  "output": "json",
  "must_include": ["root_cause", "next_steps"],
  "must_avoid": ["speculation", "apologies"]
}

そのほうが、三段落にわたる文章形式の指示よりも内容を把握しやすくなります。

変わらないプレフィックスにプロンプトキャッシュを使う

使用している技術スタックがプロンプトキャッシュに対応しているなら、リクエスト間で繰り返されるものに活用してください。システムプロンプト、ツールスキーマ、少数の例、長いポリシーブロックなどが対象です。

大切なのは、「キャッシュは無料」という考えではありません。無料ではありません。利点は、同じプレフィックスに対して、呼び出しのたびに通常料金を払い直す必要がなくなることです。

キャッシュに適したもの

• 製品全体で共通のシステムプロンプト
• 大規模な関数・ツール定義
• 再利用する情報検索の指示
• 書式やスタイルに関する固定の例
• ほとんど変わらないエージェントの基本構成

キャッシュに適さないもの

• リクエストごとのユーザーコンテキスト
• 新たに取得したドキュメント
• 頻繁に変わる指示
• セッション固有の作業メモ

よくある間違いは、変化の大きい内容をプレフィックスに入れたうえで、キャッシュのヒット率が低いことを不思議に思うことです。効果を得るには、キャッシュ対象の部分を固定し、リクエスト固有のデータをその後ろに移してください。

リクエスト構成の例：

{
  "system": "Stable application prompt + tool definitions + output contract",
  "messages": [
    { "role": "user", "content": "New ticket text here" }
  ]
}

変わらない部分をそのまま維持すれば、キャッシュが実際に効果を発揮できるようになります。リクエストごとにプレフィックスが変わるなら、何の恩恵もなくキャッシュ管理のオーバーヘッドを支払うだけです。

設定する項目： max_tokens 本気で取り組む

気づきにくい費用の原因としてよくあるのが、大きすぎる出力上限です。 max_tokens を「念のため」に極端に大きく設定すると、特にモデルが確信を持てない場合や冗長になりがちな場合に、長い回答を招きます。

タスクを完了できる範囲で、最小の上限を使用してください。

実用的な範囲

• 抽出 / 分類：32～128トークン
• 短い要約：128～256トークン
• コードの差分 / 説明：256～800トークン
• 自由形式の生成：必要な範囲に限って高く設定

タスクが「JSONオブジェクトをひとつ返す」ことなら、厳格な上限を設けましょう。タスクが「このアーキテクチャを説明する」ことなら、長大な説明が必要でない限り、モデルが小説ほどの長文を書ける余地を残さないようにしましょう。

多くのチームは、リトライループの回数制限も忘れがちです。解析に失敗したときに、同じ余裕のある出力上限のままモデルに自動で再試行させると、ユーザーの一度の操作で出力コストが倍、あるいはそれ以上に膨らむことがあります。

小さなジョブをまとめてバッチ処理する

指示にかかるオーバーヘッドが似ている、小さく独立したタスクが多数ある場合、バッチ処理が役立ちます。

次のようにする代わりに：

• 50件の個別の分類リクエスト
• 50回繰り返されるシステムプロンプト
• 50回繰り返されるツール定義

次のようにしましょう：

• 50件の項目を含む単一のリクエスト
• 共通の指示ブロック
• 簡潔な出力スキーマ

プロンプトのパターン例：

Classify each item into one of: bug, feature, question, billing.

Items:
1. "App crashes after login"
2. "Can you add dark mode?"
3. "How do I reset my password?"

レスポンスの仕様：

[
  {"id": 1, "label": "bug"},
  {"id": 2, "label": "feature"},
  {"id": 3, "label": "question"}
]

これにより、繰り返し発生するオーバーヘッドを削減でき、多くの場合はスループットも向上します。トレードオフは、失敗の影響範囲です。ある項目が形式を崩すと、バッチ全体の復旧が必要になる場合があります。重要度が高い処理や、ユーザー向けで遅延に敏感な処理経路では、小さなバッチのほうが適していることもあります。

ストリーミングは応答性を改善するが、トークンコストは減らさない

ストリーミングはUXに優れており、場合によってはコスト管理にも役立ちますが、それだけで わけではありません 課金対象のトークン数が魔法のように減るわけではありません。モデルが生成した分の料金は引き続き発生します。

ストリーミングが役立つのは、 早期停止:

• ユーザーは進捗をより早く確認できます。
• アプリケーションは、十分な内容が得られた時点でキャンセルできます。
• 回答が際限なく長くなっても、設定した上限に達する前に停止できます。

最後の点は重要です。後続のパーサー向けに回答を生成していて、最初の120トークンに必要なJSONがすでに含まれているなら、さらに800トークン分の説明を収集し続けないようにしましょう。

実際には、アプリが生成の途中で対応できる場合に、ストリーミングを使う価値があります。ログにストリーミングして、結局は回答全体を待つだけなら、UX上のメリットは得られても、コスト削減効果はあまりありません。

月単位だけでなく、リクエストごとのコストを測定する

月間支出を見れば、問題があることはわかります。リクエスト単位の指標を見れば、その問題がどこにあるかわかります。

少なくとも次を追跡しましょう：

• input_tokens
• output_tokens
• cache_hit_tokens 取得できる場合
• モデル名
• エンドポイント / 機能の処理経路
• レイテンシー
• リトライ回数
• 切り詰めや解析失敗の発生率

シンプルなログ用ペイロードは、次のようになります：

usage = response["usage"]

record = {
    "model": response["model"],
    "input_tokens": usage["input_tokens"],
    "output_tokens": usage["output_tokens"],
    "latency_ms": latency_ms,
    "cache_hit_tokens": usage.get("cache_read_input_tokens", 0),
    "request_type": "ticket_summary",
}
print(record)

次に、コストを一元的に計算します：

def estimate_cost(input_tokens, output_tokens, input_rate, output_rate):
    return (input_tokens * input_rate) + (output_tokens * output_rate)

正確な料金はプロバイダーとモデルによって決まりますが、手順は同じです。リクエストをコスト順に並べられるようになると、通常は原因がすぐに見えてきます：

• 巨大な隠れたプレフィックスを持つ「小さな」プロンプト
• 毎ターン、文書全体を再送するツール呼び出し
• タスクに必要な量の10xに設定された生成上限
• 気づかないうちに使用量を倍増させるリトライループ
• Haikuを使うべきなのに、常にOpusを使っている処理経路

気づきにくい無駄を避ける

トークンの無駄の大半は地味なもので、そのためコードレビューをすり抜けます。

よくある原因

• 毎ターン、同じ長い会話履歴を再送する
• 差分だけでよいのに、ソースファイル全体を含める
• 構造化されたJSONで十分なのに、文章を要求する
• 機械処理する側に冗長な説明を返す
• 実際のタスクよりも大きなツールスキーマを渡す
• 自動リトライで、同じ高コストのプロンプトを再実行させる
• ログや内部メモをモデルのコンテキストに残す

特に厄介な落とし穴が、「親切心からのコンテキスト拡張」です。検索システムは、誰かが念のためにと考えた結果、情報を取得しすぎることがよくあります。モデルが必要としているのが関連性の高い上位の数段落だけなら、チャンク分割レイヤーで簡単に渡せるからという理由で、文書全体を与えないようにしましょう。

もうひとつあります。モデルに「簡潔に答えて」と指示する追加のプロンプトをかぶせると、より厳密な出力スキーマで解決すべき冗長さの問題を解決するために、かえってトークンを追加している可能性があります。

実用的なリクエスト設計

多くの本番タスクでうまく機能するパターンを紹介します：

request = {
    "model": "claude-sonnet-4.6",
    "max_tokens": 180,
    "system": "Extract the root cause and next action. Return strict JSON.",
    "messages": [
        {
            "role": "user",
            "content": "Investigate this incident summary: ... "
        }
    ]
}

この構成が機能する理由：

• 選択したモデルが、中程度の推論に十分な能力を備えています。
• 出力上限によって、過度に冗長な出力を抑えられます。
• システムプロンプトが短く、具体的です。
• 出力形式が機械処理に適しています。
• ユーザーペイロードには、タスクに必要な入力だけが含まれています。

さらにコンテキストが必要なら、意図的に追加しましょう。いつの間にかコンテキストが積み重ならないようにしてください。

実際に料金を左右するもの

効果の大きい施策を順位づけするなら、次のようになります：

1. 簡単なタスクには、より安価なモデルを選ぶ
2. プロンプトの肥大化を抑える
3. 上限を設定する max_tokens 厳しく
4. 固定のプレフィックスにプロンプトキャッシュを使う
5. 小さく独立したジョブをバッチ処理する
6. リクエスト単位の使用量を測定する
7. リトライループによる支出の倍増を防ぐ

この順序は重要です。チームはしばしば、明らかな問題を修正する前に、凝った最適化から始めます。実際には、最も高価なモデルに、過剰なコンテキストを与え、過剰な内容を、過剰な頻度で求めているだけなのです。

実践上のポイント

• 使用するモデルは、 Haiku 簡単な抽出とルーティングには、 Sonnet 製品開発の大半の作業には、そして Opus タスクに見合う場合に限って使います。
• この システムプロンプト をコストの発生源として捉え、繰り返される文章を削除し、動作を変える指示だけを残しましょう。
• 有効にする プロンプトキャッシュ ポリシー、ツールスキーマ、few-shotの例など、固定のプレフィックスに対して。
• 設定する項目： max_tokens 実用上必要な最小限の上限に設定し、タスクごとに見直しましょう。
• バッチ処理する 指示のオーバーヘッドが大部分を占める場合は、小さく独立したジョブを。
• 追跡する 入力トークン、出力トークン、キャッシュヒット、リトライ、レイテンシー リクエストごとに。
• 注意する 気づきにくい無駄：履歴の繰り返し、過剰な検索結果、冗長な出力、自動リトライループ。

ご希望であれば、具体的なコストダッシュボードの例と、Haiku/Sonnet/Opusのルーティングルールをいくつか盛り込んだ関連記事にまとめることもできます。