「Claude APIの請求、今月2万円超えてるんだけど」——先月末、Anthropicのコンソールを開いた筆者の第一声がこれでした。個人開発の要約ツールを細々と回していただけのつもりが、気づけば飲み代3回分が静かに溶けていたわけです。というのも、コスト構造をまるで理解しないまま、全リクエストを一番高いモデルに投げ続けていたから。そこから2週間かけて実装を見直した結果、翌月の請求は4,000円台まで落ちました。
そもそも、なぜAPIの請求は静かに膨らむのか
Claude APIの料金は「入力トークン」「出力トークン」「キャッシュ」の3つで決まります。ここまではドキュメントを読めば誰でも分かる話です。ただ、実際に使い始めると、この3つのうちどれが自分の請求を押し上げているのかが驚くほど見えにくい。
筆者の場合、犯人は入力トークンでした。要約ツールは毎回同じ長いシステムプロンプト（出力形式の指定やNG表現のリスト）を先頭に付けて投げる設計だったんですね。1回あたり3,000トークン強。それを日に200回叩けば、それだけで月1,800万トークンです。なぜなら、システムプロンプトは毎回「新しい入力」として課金されるから。要するに、同じ文字列を何百回も定価で買い直していたことになります。
そして、日本語ユーザー特有の落とし穴がもう一つあります。日本語は英語に比べてトークン効率が悪く、同じ内容でもおおよそ1〜1.5倍のトークンを消費する。海外の記事に載っている「月10ドルで足りる」という感覚をそのまま持ち込むと、確実に足が出ます。
2026年7月時点の料金感を、ざっと押さえておく
打ち手に入る前に、現在の単価を整理しておきます。百万トークンあたりの入力／出力で見ると、Haiku 4.5がおよそ1ドル／5ドル、Sonnet 5が2ドル／10ドル、Opus 5が5ドル／25ドルというレンジ。上位モデルほど当然高くなります。
ただ、金額そのものより注目すべきは倍率です。HaikuとOpusでは入力も出力も5倍前後の開きがある。つまり「そのタスク、本当にOpusじゃないと駄目ですか？」という問いが、そのまま請求書に効いてくるわけです。とはいえ単価は改定されるので、実装前には必ずAnthropicの公式ページで最新値を確認してください。
打ち手の前に、まず1週間かけて計測した
とはいえ、いきなり設定をいじるのは危険です。というのも、どこがコストの主因か分からないまま最適化しても、労力の割に請求が変わらないという事態になりかねないから。
そこで筆者は、まず1週間ぶんのリクエストにタグを付けて記録することにしました。用途ごとに識別子を振り、レスポンスに含まれる使用トークン数（入力・出力・キャッシュの読み書き）をログに落とすだけの単純な仕組みです。実装は30分ほどで終わりました。
結果は明快でした。全コストの実に7割が「要約ツールの入力トークン」に集中していたんです。逆に言えば、他をいくら削っても残り3割の世界の話でしかない。この1枚のログがあったから、迷わずプロンプトキャッシュから着手できました。計測なき最適化は、ただの勘です。
請求を5分の1にした4つの打ち手
1. プロンプトキャッシュを設定する
いちばん効いたのがこれです。プロンプトキャッシュは、繰り返し送る固定部分をサーバー側に保持しておく仕組みで、キャッシュにヒットした入力は通常の1割程度のコストで済みます。ざっくり9割引きです。
やること自体は単純で、システムプロンプトのブロックにキャッシュ指定を付けるだけ。ただし順序が重要で、キャッシュしたい固定部分を必ずリクエストの先頭に置き、可変部分であるユーザー入力を後ろに回す必要があります。筆者は最初、テンプレートの都合で固定プロンプトを末尾に置いていて、当然ながら一度もヒットしませんでした。実装を数行入れ替えるだけの話なので、ここは真っ先に確認する価値があります。
2. モデルを1段階落とす勇気を持つ
エンジニアとして感じたのは、「とりあえず最上位モデル」は思考停止だということ。筆者の要約ツールがやっていたのは、決まったフォーマットに文章を流し込む作業がほとんどでした。それならHaikuで十分だったんです。
実際に同じ100件をHaikuとOpusの両方で処理して出力を並べたところ、明確に品質差を感じたのは7件ほど。ならば全体をHaikuで回し、精度が要る数件だけを人間が拾ってOpusに投げ直せばいい。この2段構えに変えただけで、モデル起因のコストは6割減りました。
3. 急がない処理はBatch APIへ逃がす
即時レスポンスが不要な処理なら、Batch APIが使えます。まとめて投げて結果を後で受け取る方式で、料金は一律50%オフ。しかもプロンプトキャッシュの割引と重ねられるのが大きい。
筆者の場合、夜間に走らせているデータ整形バッチをまるごとこちらに移しました。翌朝に結果が揃っていれば何の問題もない処理だったので、これは正直やらない理由がなかった。リアルタイム性が要らない処理を洗い出すだけで、請求書の合計が静かに縮みます。
4. 出力トークンは入力の5倍高いと意識する
見落としがちですが、出力単価は入力のおよそ5倍です。だから「丁寧に長く説明して」というプロンプトは、そのまま請求額に跳ね返ってきます。
そこで筆者は出力形式をJSONに固定し、不要な前置きを書かせない指示を入れました。「説明は不要、JSONのみを返せ」という一文です。地味な変更ですが、1リクエストあたり200トークン削れれば、月4万リクエストで800万トークン。馬鹿になりません。
やらなくてよかった、遠回りだったこと
ところで、失敗談も正直に書いておきます。筆者は最初、コスト削減と聞いてローカルLLMへの全面移行を本気で検討しました。GPUを積んだマシンを買えばAPI代はゼロになる、と単純に考えたわけです。
ただ、見積もりを出した時点で手が止まりました。ハードだけで20万円近く、しかも出力品質は明らかに落ちる。月2万円のAPI代を消すために10か月分を先払いして、品質を下げる——冷静に考えると本末転倒でした。結局、上の4つを実行したら月4,000円台まで落ちたので、ローカル移行の話は自然消滅しています。まず実装を見直す。ハードを買うのは、それでも足りなかったときの話です。
まとめ：コスト削減は「買い物」ではなく「実装の見直し」
整理すると、Claude APIのコストは次の順で手を付けるのが効率的でした。
- プロンプトキャッシュを設定する（最大9割引き・効果最大）
- タスクに対してモデルが過剰でないか見直す
- 即時性の不要な処理をBatch APIへ移す
- 出力トークンを削る指示をプロンプトに入れる
どれも新しいツールを買う必要はなく、既存コードの数行を書き換えるだけで済みます。逆に言えば、ここを放置したままプランを上げても、穴の空いたバケツに水を注ぐようなものです。
まずは自分のコンソールを開いて、入力・出力・キャッシュのどれが請求を押し上げているのかを確認するところから始めてみてください。主因さえ分かれば、打ち手は自ずと決まります。筆者は2週間で5分の1になりました。
コメント