LLM APIのコストを抑える実践テクニック

※本ページには広告（アフィリエイトプログラム等）が含まれます。

※本ページには広告（アフィリエイトプログラム等）が含まれます。掲載している料金は 2026年8月16日時点の Anthropic 公式ドキュメントの記載です。API の料金は改定されるため、実際の請求前に公式で確認してください。

🎯 結論：キャッシュ・バッチ・モデル選択の 3 つで、同じ処理の請求が一桁変わる

結論から書きます。LLM の API 費用を下げる手は、実質この 3 つです。

• ✅ プロンプトキャッシュ → キャッシュ読み出しは入力料金の約 0.1 倍。同じ前置きを使い回すなら最優先
• ✅ バッチ処理 → 急がない処理は 50% 引き。コードの変更もほぼ要らない
• ✅ モデルの使い分け → 入力 $1 と $10 では10 倍違う。全部を最上位で回さない
• ⚠️ 会話を分けない → 実測で読み込みトークンの 98.4% が読み直しだった月がある（後述）
• ⛔ キャッシュを付ければ安くなる、ではない → 書き込みは割増。回数が少ないと逆に高くつく

現行モデルの料金（2026年8月16日時点）

100 万トークンあたりの単価

⚠️ Claude Sonnet 5 には2026年8月31日までの導入価格（入力 $2.00 / 出力 $10.00）が設定されています。今の見積もりをそのまま来月に当てはめないでください。

出力は入力の 5 倍という構造

どのモデルも出力単価は入力の 5 倍です。ここを踏まえると、費用を削る順番が決まります。

長いプロンプトを短くするより、「出力を短くさせる」ほうが 5 倍効く。実際、要約や分類のように出力が短いタスクは、入力が大きくても総額はそれほど伸びません。

いちばん効く判断は「Haiku で足りないか」

Haiku 4.5 と Fable 5 では入力単価が 10 倍、出力単価も 10 倍違います。分類・抽出・整形のような定型処理まで最上位モデルで回していると、桁が一つ変わります。

プロンプトキャッシュ：読み出しは 0.1 倍

倍率と TTL

同じ前置き（システムプロンプト、長い資料、few-shot の例）を毎回送るなら、ここがいちばん効きます。

何回使えば元が取れるか

書き込みは割増なので、回数が少ないと損をします。計算するとこうなります。

• TTL 5 分：1.25（書き込み）＋ 0.1（読み出し）＝ 1.35 倍。キャッシュ無しの 2 回ぶん（2 倍）より安いので、2 回で元が取れる
• TTL 1 時間：2 ＋ 0.2 ＝ 2.2 倍。3 回ぶん（3 倍）より安いので、3 回必要

つまり1 回しか使わないプロンプトにキャッシュを付けるのは純粋な損です。5 分以内に再利用が発生しない散発的なアクセスなら、TTL 1 時間のほうが有利になります。

書き方

キャッシュしたいブロックに cache_control を付けます。

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    system=[
        {
            "type": "text",
            "text": LARGE_SHARED_PROMPT,
            "cache_control": {"type": "ephemeral"},  # 既定は TTL 5 分
        }
    ],
    messages=[{"role": "user", "content": question}],
)

TTL を 1 時間にする場合は {"type": "ephemeral", "ttl": "1h"} です。ブレークポイントは 1 リクエストあたり最大 4 個。

⚠️ 効いているか必ず数字で確認する

キャッシュは前方一致です。前置きの中に 1 バイトでも変わる要素があると、そこから後ろは全部無効になります。効いているかはレスポンスの usage で確認できます。

print(response.usage.cache_creation_input_tokens)  # 書き込んだ量（割増）
print(response.usage.cache_read_input_tokens)      # 読み出した量（0.1 倍）
print(response.usage.input_tokens)                 # キャッシュに乗らなかった量（1 倍）

同じ前置きで繰り返し呼んでいるのに cache_read_input_tokens がゼロのままなら、無効化する要素が混ざっています。よくある犯人はこれです。

• システムプロンプトに datetime.now() や UUID を埋め込んでいる
• json.dumps() を sort_keys=True なしで使っていて、キー順が毎回変わる
• ユーザー ID をシステムプロンプトに差し込んでいる（ユーザーごとに別キャッシュになる）
• ツール定義の順序や内容がリクエストごとに変わる（ツールは先頭に描画されるので影響が最大）

短すぎるプロンプトは黙って乗らない

キャッシュには最小トークン数があり、下回るとエラーも警告も出ないまま乗りません。しかも世代順に単調ではありません。

3,000 トークンのプロンプトは Opus 5 では乗り、Haiku 4.5 では乗りません。安いモデルに落としたらキャッシュが効かなくなった、という逆転が起きます。

バッチ処理：急がないなら 50% 引き

条件

即答が要らない処理は Batches API に回せます。全トークンが 50% 引きで、Messages API の機能（画像・ツール・キャッシュ）はそのまま使えます。

• 1 バッチあたり 最大 10 万リクエスト、または 256MB
• 多くは 1 時間以内に完了。最大 24 時間
• 結果は作成から 29 日間取得可能

投げ方

batch = client.messages.batches.create(
    requests=[
        {
            "custom_id": "req-1",
            "params": {
                "model": "claude-haiku-4-5",
                "max_tokens": 1024,
                "messages": [{"role": "user", "content": "..."}],
            },
        },
    ]
)
print(batch.id, batch.processing_status)

結果は順番どおりに返らない

ここが実装で詰まる点です。結果の順序は保証されません。必ず custom_id で突き合わせてください。

for result in client.messages.batches.results(batch.id):
    if result.result.type == "succeeded":
        store(result.custom_id, result.result.message.content)
    elif result.result.type == "errored":
        retry_later(result.custom_id)

夜間に回すバッチ処理なら、Haiku 4.5 × バッチ 50% 引きの組み合わせが最も安くなります。入力 $1.00 の半額なので、実質 $0.50 / 1M トークンです。

実測：読み込みの 98.4% が「読み直し」だった

会話を分けないと何が起きるか

これは自分の作業で計測した数字です。AI エージェントに 1 つの会話の中で複数の作業を続けさせたところ、こうなりました。

なぜこうなるのか

LLM は1 往復ごとに会話全体を読み直します。前の作業の記録が同じ会話に残っていると、それ以降のすべての往復でそれを再読するので、無関係な文脈が往復回数ぶん課金されます。

上の例では、本来の作業に必要だったのは全体の 1.6% でした。話題が変わった時点で会話を切っていれば、同じ結果が4 分の 1 の費用で得られた計算になります。

ただし分けすぎても損をする

逆に、同じ対象を続けて触るなら会話は分けないほうが安いです。同じ文脈の読み直しはキャッシュ読み出し（0.1 倍）で済むのに対し、会話を切ると書き込みからやり直しになるからです。

判断基準は「話題が変わったかどうか」。作業が変わったら切る、同じ作業を続けるなら切らない、で十分です。

そのほかに効く設定

effort を下げる

思考の深さを制御する effort は low / medium / high / xhigh / max の 5 段階で、既定は high です。定型処理を既定のまま回していると、必要のない思考トークンを払い続けます。

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    output_config={"effort": "low"},   # 短く scoped なタスク向け
    messages=[{"role": "user", "content": "..."}],
)

トークン数は投げる前に数える

見積もりは推測ではなく実数で出せます。⚠️ tiktoken は OpenAI 用のトークナイザなので使わないでください。Claude のトークン数を 15〜20% 少なく数えます（コードや日本語ではさらにずれます）。

count = client.messages.count_tokens(
    model="claude-opus-5",
    messages=messages,
)
print(count.input_tokens)

並列リクエストはキャッシュを共有できない

キャッシュは最初のレスポンスがストリーミングを開始してから読めるようになります。同じ前置きの N 本を同時に投げると、全部が満額を払います。1 本投げて最初のトークンが返ってから残りを流してください。

よくある質問

Q1. いちばん費用対効果が高い施策はどれですか？

結論：同じ前置きを繰り返し送っているならプロンプトキャッシュです。キャッシュ読み出しは入力料金の約 0.1 倍で、2 回目の呼び出しから元が取れます（TTL 5 分の場合）。前置きが毎回違うなら効果はゼロなので、その場合はモデルの使い分けが先です。

Q2. キャッシュを付けたのに安くなりません

結論：`cache_read_input_tokens` がゼロなら、前置きの中に毎回変わる要素があります。システムプロンプト内の現在時刻・UUID・ユーザー ID、キー順が不定な JSON、リクエストごとに変わるツール定義が典型です。前置きは固定し、変動する情報は後ろに置いてください。

Q3. バッチ処理はどれくらい安いですか？

結論：全トークンが 50% 引きです。1 バッチ最大 10 万リクエスト、多くは 1 時間以内、最大 24 時間で完了します。即答が要らない処理をここに寄せるだけで、コードをほとんど変えずに半額になります。

Q4. 安いモデルに落とすだけでいいのでは？

結論：それが最も効く場面は多いですが、キャッシュの最小トークン数に注意してください。Haiku 4.5 の最小は 4,096 トークンで、Opus 5 の 512 より大きいです。3,000 トークンの前置きは Opus 5 では乗り、Haiku 4.5 では乗らないため、モデルを落とした結果かえって高くなることがあります。

Q5. トークン数の見積もりに tiktoken を使ってもいいですか？

結論：使わないでください。tiktoken は OpenAI のトークナイザで、Claude のトークン数を 15〜20% 少なく見積もります。コードや英語以外の入力ではさらに大きくずれます。count_tokens エンドポイントを使ってください。

Q6. 会話は分けたほうがいいですか？

結論：話題が変わったら分けてください。実測では、別作業を同じ会話に同居させた結果、読み込みトークンの 98.4% が読み直しになりました。逆に同じ対象を続けて触るなら分けないほうが安く済みます（同じ文脈の読み直しはキャッシュ読み出しになるため）。

まとめ

LLM の API 費用は、プロンプトキャッシュ・バッチ処理・モデルの使い分けの 3 つでほぼ決まります。2026年8月16日時点の公式価格で整理すると、優先順位はこうなります。

• 🎯 同じ前置きを使い回している → キャッシュ（読み出しは0.1 倍、2 回で元が取れる）
• 🎯 即答が要らない → バッチ（50% 引き）
• 🎯 定型処理を上位モデルで回している → Haiku 4.5（入力 $1.00、最上位の 1/10）

料金は改定されます。この記事の数値は 2026年8月16日時点のもので、とくに Claude Sonnet 5 の導入価格は 2026年8月31日までです。見積もりの前に公式で確認してください。サーバー側の運用コストを詰める話はスワップの追加やAI を使ったログの切り分け、常駐処理の組み方はsystemd のユニットファイルにまとめています。