この記事の3行サマリー

  • AIの利用料は「1トークンあたりの単価」ではなく「1タスクを終えるまでの総額」で見る。
  • 削減施策には順番がある。品質を落とさずに効く施策（キャッシュ・入力の整理・バッチ）を先に、品質と引き換えの施策（思考量の調整・モデル変更）を後に。
  • 最初にやるべきはプロンプトキャッシュ。Anthropicの計測では、エージェント処理のコストが2.5〜3.7分の1になった例が公表されています。

「AIを業務に入れたら、想定より利用料が膨らんだ」。API連携で本格的にAIを使い始めた企業から、よく伺う相談です。この記事では、Claudeの利用料を下げるためのトークン削減施策を、効果が大きく副作用のないものから順に整理します。

結論：削減は「無料で効く施策」から。モデルのグレードを下げるのは最後

先に結論です。トークン削減には明確な優先順位があります。

  1. プロンプトキャッシュ（最大の削減幅・品質への影響なし）
  2. 入力トークンの整理（渡しすぎているものを削る）
  3. バッチ処理（急がない処理を50%オフに回す）
  4. 思考量（effort）の調整（ここから品質とのトレードオフ）
  5. モデルの変更（最後）

多くの企業が真っ先に「安いモデルに変えよう」と考えますが、そこは最後に触る場所です。1〜3を飛ばしてモデルを下げると、品質だけ落ちて削減幅は小さい、という結果になりがちです。

前提：コストは「1トークンあたり」ではなく「1タスクあたり」で測る

単価の安いモデルが、必ずしも安上がりとは限りません。失敗したAIも、そのトークン分は課金されるからです。安いモデルが3回やり直して終わるより、高いモデルが1回で終わるほうが安い、ということは普通に起こります。

判断の単位は「1リクエストいくら」ではなく、「1つの仕事が終わるまでにいくらかかったか」。ここを取り違えると、削減施策の評価そのものが狂います。

なぜ利用料は思ったより膨らむのか

AIに複数の手順を任せる「エージェント」的な使い方をすると、毎回のやり取りで、それまでの会話すべてを送り直しています。

システムプロンプト、ツールの定義、過去のやり取り。40往復する処理なら、最初のやり取りは40回送られている計算です。つまり、処理のコストは往復回数のおよそ2乗で増えていきます。

ここが、体感と請求額がずれる最大の理由です。

手順1：プロンプトキャッシュを入れる（まずこれ）

プロンプトキャッシュは、送り直しをなくす仕組みではなく、送り直しの値段を下げる仕組みです。一度キャッシュされた部分は、以降の読み込みが通常の入力料金の約0.1倍になります。

効果の目安

Anthropicが公表している計測では、プロンプトキャッシュはあらゆるモデル・ベンチマークで単独として最大の削減施策であり、エージェント処理のコストを2.5〜3.7分の1に下げました（キャッシュヒット率81〜90%時）。小規模な問い合わせ振り分けエージェントでは、キャッシュだけで請求額が83%減った例も公表されています。

書き込みには割増がかかる

キャッシュは書き込み時に割増料金がかかります。ここを知らずに使うと、かえって高くつくことがあります。

TTL（保持時間） 書き込み 読み込み 損益分岐
5分 1.25倍 0.1倍 2回使えば得
1時間 2倍 0.1倍 3回使えば得

選び方はシンプルで、同じ内容を使うリクエストの間隔で決めます。5分以内に次が来るなら5分TTL（読むたびに時計がリセットされるので、実質ずっと温かい）。人の返信を挟むなど5〜60分空くなら1時間TTL。1時間以上空くなら、どちらも直接は効きません。

キャッシュを黙って壊す「5つの書き方」

プロンプトキャッシュは前方一致で効きます。先頭から1バイトでも変わると、それ以降すべてが無効になります。次のような書き方は、キャッシュを静かに壊します。

  • システムプロンプトに現在時刻を入れている：毎回変わるので、毎回作り直しになる
  • リクエストIDやUUIDを冒頭に入れている：同上
  • JSONをキー順を固定せずに文字列化している：同じ内容でも並びが変わり、バイトが一致しない
  • 条件分岐でシステムプロンプトを組み立てている：分岐の組み合わせの数だけ別物になる
  • ユーザーごとにツール定義を変えている：ツールは先頭に置かれるため、誰の間でも共有できなくなる

いずれも「動くけれど、キャッシュだけが効かない」状態になります。エラーは出ません。

効いているかは、コードではなく実測で確認する

キャッシュが効いているかどうかは、レスポンスの利用状況（cache_read_input_tokens）を見れば分かります。繰り返し実行しているのにここがゼロなら、上の5つのどれかを疑ってください。

なお、キャッシュが作られる最小の長さはモデルごとに違い、短すぎるプロンプトはマーカーを付けてもエラーなく無視されます。

手順2：入力トークンを減らす（渡しすぎをやめる）

次に効くのが、そもそも送る量を減らすことです。

  • 毎回添付している大きな参照資料：ツールやスキルの形にして、必要なときだけ取りに行かせる
  • システムプロンプト内のツール説明の重複：ツールの定義は自動で送られているので、文章での説明は消す
  • 画像・PDFを原寸で渡している：画像は面積でトークン化されるため、事前に縮小するだけで効く（1280×720程度が目安）
  • 巨大な表をそのまま貼っている：ファイルとして渡して集計させ、結果だけを受け取る
  • 古いモデル向けに書かれたプロンプトを使い続けている：これが意外に大きい

最後の項目には具体的な計測値があります。Anthropicの公表値では、旧世代モデル向けに書かれたプロンプトを新モデルでそのまま使うと1件あたり36%割高になり、書き直したところ14%安くなったうえに精度も上がった（92%→97%）という結果が出ています。プロンプトは書いたら終わりではなく、モデルを乗り換えたら見直す対象です。

ただし注意点があります。 前提を削りすぎると、AIが「調べに行く」ためのやり取りが増えて、かえって総額が上がることがあります。減らしたら必ず、前後で比較してください。

手順3：急がない処理はバッチに回す

誰も待っていない処理なら、バッチ処理で全トークンが50%オフになります。キャッシュの読み書きにも割引が乗るので、手順1との併用が効きます。

向いているのは、夜間の一括処理、定期レポートの生成、検証用の一括実行など。結果は24時間以内に非同期で返るため、画面の向こうで人が待っている処理には使えません。

手順4：ここから先は品質とのトレードオフ

ここまでが「品質を落とさずに効く施策」です。ここから先は、効果と引き換えに失うものがあります。必ず、自社の実際の業務で比較してから決めてください。

思考量（effort）を下げる

Claudeには考える深さを指定するパラメータがあります。Anthropicの計測では、調べもの・知識作業の系統はこの曲線がほぼ平らでした。最低設定でも精度は1〜3ポイントしか落ちず、コストは3分の1〜半分。中間設定なら、標準設定と同じ精度を70〜85%のコストで達成しています。

一方で長時間のコーディング作業では明確なトレードオフが出ます。中間設定で約2ポイント落として半額、最低設定では約8ポイント落として4分の1、という結果でした。つまり、業務の種類によって答えが逆になります。

「失敗したものだけ、やり直す」

成否を機械的に判定できる業務であれば、これが効きます。全部を低い設定で走らせ、失敗したものだけ標準設定でやり直す。Anthropicのコーディング検証では、約93%を1件あたり約$0.70で処理できました（全件を標準設定で走らせた場合は91.7%・$1.39）。失敗した分の費用も含めて、ほぼ同じ精度で半額です。

手順5：モデルの変更は最後

モデル選択が最後なのは、それが能力の上限そのものを決めてしまうからです。

判断するときは、平均ではなく「難しい方の1割」で比べてください。ふつうの仕事ではどのモデルも似た結果になり、安いモデルが良く見えます。しかし請求額を決めているのは、安いモデルが失敗するタスクのほうです。

やってはいけない節約 3つ

削減のつもりが逆効果になる、代表的な3つです。

  1. max_tokens を絞る：これは出力の上限を切るだけで、AIはその存在を知りません。途中で切られた回答は失敗であり、やり直しになります。Anthropicの計測では、上限を16,384に絞ったコーディング処理でOpus 5の15%が未解決のまま打ち切られ、1件あたりの単価は下がっても、解けた数も比例して減りました
  2. コンテキスト編集を節約目的で使う：古いやり取りを消す機能は「文脈の枠を空ける」ための道具であって、削減策ではありません。消すたびにキャッシュが作り直されるため、実測では削減額より増加額のほうが大きかったと報告されています
  3. 計測せずに乗り換える：施策は一度に1つずつ変え、その都度、自社の実務で前後比較する。まとめて変えると、何が効いたのか分からなくなります

よくある質問（FAQ）

Q. Claude Codeを定額プランで使っている場合も関係ありますか？ A. 請求額という意味では直接は関係しません。ただし「毎回すべての履歴を送り直している」「渡す前提が多すぎる」という構造は同じなので、手順2（入力の整理）は応答の速さと精度に効きます。API連携で本格的に組む段階になったら、手順1から順に見てください。

Q. どこから手をつけるべきですか？ A. まず現状を測ることです。何にトークンを使っているか分からないまま施策を入れても、効果を判定できません。測ったうえで、キャッシュ→入力の整理→バッチ、の順です。

Q. 削減できる金額の目安はありますか？ A. 業務の形によって大きく変わります。同じ内容を繰り返し送っている処理ほどキャッシュが効き、毎回まったく違うデータを送る処理では効きません。まず自社の使い方がどちらに近いかを見極めるところからです。

まとめ：順番を守れば、品質を落とさずに下げられる

要点を振り返ります。

  • 判断の単位は「1トークンあたり」ではなく「1タスクを終えるまでの総額」
  • 品質を落とさない施策（キャッシュ・入力の整理・バッチ）を先に、品質と引き換えの施策（思考量・モデル）を後に
  • 最初はプロンプトキャッシュ。ただし現在時刻やIDを先頭に置くと静かに無効化される
  • 業務の種類によって効く施策は変わる。必ず自社の実務で前後比較する
  • max_tokens を絞る、コンテキスト編集で節約する、計測抜きで乗り換える——この3つは逆効果

カラフルボックスの Scale Works では、Claude / Claude Code を使った業務自動化を伴走型で支援しています。「AIを入れたが利用料が読めない」「どこにトークンを使っているのか分からない」という段階からのご相談も承っています。まずは現状の使い方を一緒に測るところから始めませんか。