Claudeの利用料金は、出力トークンではなく、入力トークンが主な要因です。APIはステートレスであるため、毎回、システムプロンプト、ツール定義、貼り付けたドキュメント、および以前のすべてのメッセージを含む、会話履歴全体を再送信します。長いエージェントループやClaude Codeセッションでは、再送信されるコンテキストが急速に蓄積され、リクエストごとにその料金を支払うことになります。出力は請求書のごく一部を占めるに過ぎません。
したがって、実際に請求額を左右する要因は、送信するデータを削減するか、トークンあたりの料金をカットするか、または不要なコンテキストの再送信を停止することです。このガイドでは、まずAnthropic側の具体的な方法、次に異なるアプローチを取るサードパーティプロキシ（pxpipe）、そして構築段階でモックAPIをどのように活用するかを順に説明します。
まず料金の基本（メーターの仕組み、トークンとは何か、キャッシュとバッチ処理の請求方法）を知りたい場合は、当社のClaude APIコスト解説でその内容を網羅しています。この投稿はコスト削減に焦点を当てているため、料金理論を長々と再説明することはありません。
テコ1：プロンプトキャッシュ
プロンプトキャッシュは、ほとんどのエージェントワークロードにおいて最も費用対効果の高い変更です。安定したプレフィックス（システムプロンプト、ツール定義、長い参照ドキュメントなど）をキャッシュ可能としてマークすると、Claudeはそれを保存します。次に同じバイトで始まるリクエストがあった場合、再処理のために全入力料金を支払う代わりに、キャッシュから読み取ります。
その経済性は強力です。キャッシュの読み取りは基本入力料金の約0.1倍で済むため、キャッシュされた部分については最大約90%の節約になります。キャッシュへの書き込みは通常の入力トークンよりもコストがかかります。5分間のTTLでは1.25倍、1時間のTTLでは2倍です。この書き込みプレミアムがあるため、キャッシュはプレフィックスを再利用する場合にのみ効果を発揮します。損益分岐点は、5分キャッシュでおよそ2リクエスト、1時間キャッシュでおよそ3リクエストです。プレフィックスが一度だけ使用されて破棄される場合、キャッシュはコスト増になりますが、何十回も使用される場合は、最初の書き込み後にはほとんど無料に近い状態になります。
問題は、キャッシュがバイトレベルでのプレフィックスマッチであるということです。キャッシュされた領域内で何らかの変更があると、キャッシュは無効化され、新たに全額料金を支払って書き込みが行われます。よくある原因は、「安定している」はずの部分に紛れ込む変数です。例えば、システムプロンプト内のタイムスタンプ、セッションID、リクエストカウンター、ツールリストの順序変更などです。あなたには安定しているように見えても、キャッシュには新しいバイトとして認識されます。
キャッシュが実際に機能していることを確認してください。レスポンスで usage.cache_read_input_tokens を確認してください。同じプレフィックスを共有する繰り返しのリクエストでは、この数値は大きく、ゼロ以外であるべきです。もしゼロのままであれば、あなたのプレフィックスの何かが呼び出しごとに変化しており、キャッシュされていると思い込んでいる間に全額を支払っていることになります。キャッシュの仕組みと理由については、プロンプトキャッシュとは何か、その仕組みを参照してください。
テコ2：モデルの適切なサイズ選択
最もよくあるコスト超過の原因は、タスクが必要とするよりも大きなモデルを実行することです。Claudeは明確な価格階層を提供しており、デフォルトで1つのモデルに頼るのではなく、タスクによってルーティングすることで、最も大きな費目削減を達成できることが多いです。
| モデル | モデル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の2倍の費用がかかり、広くリリースされているモデルの中で最も高価です。Opus 4.8は100万トークンのフルコンテキストウィンドウを持ち、長コンテキストプレミアムがないため、大規模なコードベースを投入しても追加料金はかかりません。Sonnet 5は、2026年8月31日まで導入価格$2/$10で提供され、その後$3/$15に移行します。Haiku 4.5は$1/$5が下限で、コンテキストウィンドウは20万と小さめです。
ジョブに合わせてモデルを選択してください：
- Fable 5は、追加機能が実際に結果を変える、最も困難な長期的推論向けです。Opusで十分な場合にFableをデフォルトにすることは、チームが不必要に請求額を2倍にする最も一般的な方法です。
- ほとんどのエージェント的な作業やコーディング作業にはOpus 4.8が適しています。Claude Codeやツールを多用するループには、賢明なデフォルトです。
- 低料金で高品質が必要な大量のプロダクショントラフィックにはSonnet 5が適しています。
- シンプルなタスクや速度が重要なタスク（分類、抽出、ルーティング、短い返信など）にはHaiku 4.5が適しています。
Fable 5に関する請求の詳細が1つあります。安全性分類器がリクエストを拒否した場合、ベータ版の fallbacks パラメーターによって、そのターンをOpus 4.8に再ルーティングでき、再ルーティングされたターンはOpusの料金で請求されます。これは通常、割引であり予期せぬ請求ではありませんが、FableのトラフィックにOpus価格の行が表示される可能性があることを知っておく価値はあります。
この2つの高額なティアに関する詳細なコスト分析については、Opus 4.8の料金、Fable 5の料金、そして2倍のコストをかける価値がある場合のFable 5 vs Opus 4.8の比較をご覧ください。評価中に低コストまたは無料で上位ティアを試したい場合は、Opus 4.8を無料で利用する方法とFable 5 APIを直接呼び出す方法を解説しています。
テコ3：バッチAPI（50%オフ）
作業でリアルタイムの応答が必要ない場合、バッチAPIはすべてのトークン料金を半額にします。ジョブを /v1/messages/batches に送信すると、それらは非同期で実行され、結果が返されます。ほとんどのバッチは1時間以内に完了します。上限は24時間です。50%割引は、入力と出力を含む、バッチ上のすべてのトークン使用量に適用されます。
その用途は限られていますが、価値があります。バッチは、待つことができる作業に適しています：
- テストセット全体での評価実行。
- バックログに対する一括分類または抽出。
- 既存レコードの要約、タグ、または埋め込み関連メタデータのバックフィル。
- 数分のレイテンシがコストにならない、あらゆる大規模なオフラインジョブ。
もしClaudeの支出の半分が、現在同期エンドポイントを介して実行している夜間処理である場合、それをバッチに移行することで、品質を損なうことなくその半分を直接50%削減できます。これは、どうせ使っていないレイテンシが唯一のトレードオフであるため、このリストの中で最も検討しやすい費用削減策です。
テコ4：effort、max_tokens、count_tokensの調整
3つの設定が単一リクエストの費用を制御し、これらを意図的に設定することでコストが上昇するのを防ぎます。
Effort。 output_config.effortパラメーターは、low、medium、high、xhigh、またはmaxを取ります。これは、モデルが応答する前にどの程度思考するかを制御し、思考トークンは課金されます。Effortが低いほど、思考トークンと出力トークンが少なくなります。習慣的にhighで実行されているタスクの多くは、mediumやlowでも同じ答えをより安価に生成します。1つか2つ下げてみて、品質が維持されるか確認してください。
max_tokens。これは出力の上限を厳しく設定するものです。もともと短かったはずの応答のコストを下げるわけではありませんが、暴走ケースを抑制します。たとえば、JSONオブジェクトを求めているのに、モデルが4,000トークンのエッセイを出力しようと決定してしまうような場合です。タスクに対して適切な上限を設定することで、1つの冗長な応答によって費用項目が膨らむのを防ぎます。
count_tokens。送信前にコストを見積もりましょう。count_tokensエンドポイントは、Claude独自のトークナイザーを使用して、リクエストが請求される入力トークン数を正確に教えてくれます。これにはtiktokenを使用しないでください。tiktokenはOpenAIのトークナイザーであり、Claudeのトークン数を約15〜20%少なく見積もるため、それに基づいて予算を立てると、実際の請求額が見積もりよりもかなり高くなることを意味します。リクエストあたりの予算に近い場合は、count_tokensを使用することで、過大なプロンプトがコストになる前に検知できます。
テコ5：再送信するコンテキストの削減
APIはステートレスであるため、長いエージェントループでは、毎回その履歴全体を再送信します。そして、その履歴のほとんどは30ターン目までには無駄な重荷となります。例えば、すでに対応済みのツール出力、通過済みの探索、一度読んだファイルなどです。これらすべてを再送信するために、全入力料金を支払い続けることになります。
2つのサーバーサイド機能が、これを自動的に剪定します。
- コンテキスト編集（
clear_tool_uses_20250919）は、再送信されるコンテキストから古いツール結果を削除するため、古いツール呼び出しが以降の各ターンで課金されるのを停止します。 - 圧縮（
compact_20260112）は、古い履歴をより短い形式に要約するため、長い会話が完全な生トランスクリプトを前方へ持ち運ぶのを停止します。
どちらもサーバーサイドで実行されるため、要約機能を自分で作成したり、メッセージ配列を手動でスライスしたりする必要はありません。長時間実行されるClaude Codeセッションでは特に、これはタスクの途中でコンテキスト制限に達する原因となるのと同じプレッシャーです。Claude Codeのトークンウィンドウとリセットに関するガイドでは、エディタでこれがどのように機能するかを説明しています。請求に関する教訓はシンプルです。モデルがもはや必要としないコンテキストを再送信するために料金を支払うのをやめましょう。
さらに進んで：pxpipeでコンテキストを画像としてレンダリングする
Anthropic側のテコはすべて、送信するトークンを削減したり、料金を再評価したりするものです。pxpipeは、同じ入力トークンコストに異なる方向からアプローチします。かさばる安定したコンテキストを画像としてレンダリングし、トークン化コストを削減します。
概要。 pxpipeは、クライアントとAnthropic APIの間に位置するローカルプロキシ（MITライセンス、TypeScriptで記述）です。ANTHROPIC_BASE_URLをそれに向けさせると、リクエストが送信される途中で各リクエストを検査します。
コスト削減方法。 密なテキストはトークンあたりのコストが高くなります。pxpipeは、リクエストのかさばる安定した部分（システムプロンプト、ツールドキュメント、古い履歴）を、リクエストがマシンを離れる前にコンパクトなPNG画像に書き換えます。密なコンテンツは、画像トークンあたり約3.1文字に対し、テキストトークンあたり約1文字であるため、そのコンテンツを画像化することで入力トークンを大幅に削減できます。プロジェクトは、約48,000文字のシステムプロンプトとツールドキュメントの例が、テキストとして約25,000トークンであるのに対し、画像として約2,700トークンになることを報告しています。重要なのは、収益性ゲートを使用していることです。トークン計算が実際に有利になるコンテンツのみを画像化し、まばらな文章はテキストとして変更されずに通過させます。
インストールと実行。 2つのコマンドです：
npx pxpipe-proxy
これにより、127.0.0.1:47821でプロキシが起動します。その後、Claude Codeをこれに向けます：
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude
モデルのサポート。 デフォルトでは、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%削減されたと報告しています。これらをベンダーのベンチマークとして扱い、ご自身のトラフィックで確認してください。
正直なトレードオフ。 画像化はタダではありません。
- プロンプトキャッシュとの相互作用。 画像化はリクエストのバイトを変更し、キャッシュされたプレフィックスはバイト単位で一致します。キャッシュと画像化は両方とも同じ入力トークンコストを対象としているため、互いに競合する可能性があります。画像化が有利になる変更が、キャッシュ領域を変更する変更となることがあります。どちらのアプローチがより多くの節約になるかは、特定のプレフィックスと再利用パターンによって異なります。両者が積み重なるものと仮定するのではなく、ご自身のワークロードで両方を測定してください。
- モデルは画像化されたコンテキストを視覚で読み取ります。 プロジェクト自体が、密な文字列（長い16進数ID、正確なトークンなど）が誤読される可能性があり、その見落としはサイレントでありエラーではないと警告しています。節約を信用する前に、ご自身のタスクで出力品質を確認してください。
- トラフィックを処理するサードパーティプロキシである。 ローカルで実行されるため良い点もありますが、それでもリクエストパス上に存在します。本番トラフィックを通過させる前に、ご自身のセキュリティ体制と照らし合わせて評価してください。
コンテキストが大きく安定した密なブロックで占められており、品質を検証できるのであれば、pxpipeをテストする価値はあります。まばらな、またはキャッシュに非常に適したワークロードの場合、Anthropic側のテコがすでにほとんどのメリットを捉えているかもしれません。
構築中に浪費する開発およびテストトークンを削減する
上記のどれも、統合を構築している間は実際の有料トークンを消費するという事実を変えるものではありません。Apidogがあなたの本番Claude請求額を削減することはありませんし、そう主張するつもりもありません。Apidogが費用を節約するのは、開発およびテストループにおいてです。
開発中にライブのAnthropic APIに対して統合を実行するたびに、各イテレーションで実際のトークンが消費されます。失敗した実行、再試行、プッシュごとにトリガーされるCIジョブなどです。プロンプトの形状、パースロジック、エラーハンドリングなどを反復して開発している間、その費用は積み重なりますが、これらの検証に実際のモデルは必要ありません。
代わりにApidogでAnthropicの応答をモックしてください。呼び出すClaudeエンドポイントのリクエストとレスポンスのコントラクトを定義し、テストとCIをモックに向けます。あなたのループは、期待する形式を返す決定論的なフェイクに対して実行され、配管の検証にトークンを一切費やすことはありません。また、そのリクエスト/レスポンスのコントラクトを同じ場所で設計・文書化できるため、誰もトークンを費やす前にチームがインターフェースについて合意できます。これは、構築中に浪費する開発およびテストトークンを削減するものであり、本番の請求額を削減するものではありません。それが正直な範囲です。
テコを組み合わせる
これらはどちらか一方を選ぶものではありません。最大の削減効果は、これらを組み合わせることで得られます。
- 安定したプレフィックスをキャッシュする。 システムプロンプト、ツール、ドキュメントなど。
cache_read_input_tokensがゼロでないことを確認してください。 - タスクごとにルーティングする。 デフォルトはOpus 4.8、Fable 5は結果を変える場合にのみ、Sonnet 5はボリューム向け、Haiku 4.5はシンプルな作業向け。
- オフライン作業をバッチ処理する。 レイテンシに影響されないものはすべて
/v1/messages/batchesに送り、50%オフを適用します。 - 各リクエストを制限する。
effortを適切に設定し、max_tokensに上限を設け、count_tokensで見積もります。 - 再送信を削減する。 コンテキスト編集と圧縮により、長いループで不要な履歴の支払いを停止します。
- 画像化が役立つかテストする。 コンテキストが大きく密である場合、ご自身のプレフィックスでpxpipeとキャッシュを比較ベンチマークしてください。
- 構築中はモックを利用する。 開発およびテストループを有料メーターから切り離します。
キャッシュとモデルルーティングから始めましょう。これら2つが通常、削減の大部分を占めるからです。変更ごとに測定してください。なぜなら、唯一重要なのは実際の請求書に記載された金額だからです。
FAQ
Claudeの請求額では、入力トークンと出力トークンのどちらが高いですか？ トークンあたりのコストは、どのモデルでも出力の方が入力よりも高くなります。しかし、エージェントやコーディングのワークロードでは、ステートレスなAPIが会話履歴全体を毎回再送信させるため、通常は入力側が請求額の大部分を占めます。そのため、最大の費用削減策は入力トークンを対象としています。
プロンプトキャッシュとバッチAPI、どちらがより大きな節約になりますか？ それはワークロードによります。キャッシュは、対話型トラフィックの繰り返されるプレフィックスに対して最大約90%節約できるため、システムプロンプトを再利用するチャットやエージェントループに有効です。バッチはすべてを50%削減しますが、非同期で実行できる作業に限られます。多くのチームは両方を併用しています。対話型パスはキャッシュし、オフラインジョブはバッチ処理します。
すべてをFable 5にデフォルトで設定すべきですか？ いいえ。Fable 5はOpus 4.8の2倍のコストがかかり、最も困難な長期的推論向けです。ほとんどのエージェント的な作業やコーディング作業では、Opus 4.8が半分の入力および出力レートで同じ結果を提供します。Opusで十分な場合にFableをデフォルトにすることは、最も一般的なコスト超過です。
pxpipeはプロンプトキャッシュと併用できますか？ きれいに併用できるわけではありません。画像化はリクエストのバイトを変更し、キャッシュはバイトレベルのプレフィックスマッチであるため、両者は同じ入力トークンコストを対象としており、互いに競合する可能性があります。実際のプレフィックスで両方をテストし、どちらがより多くの節約になるかを測定してください。両者が単純に加算されると仮定しないでください。
Apidogは本番環境のClaudeコストを削減しますか？ いいえ。ApidogはAnthropic APIをモックするため、構築中に有料トークンを消費する代わりに、テストやCIはフェイクをヒットします。これにより、開発およびテスト費用は削減されますが、本番の請求額は削減されません。