図1：この記事で扱う手順の全体像。
「異常かどうかの判定」から始めて「請求データの分解」「リクエスト単位の特定」「打ち手の分岐」「効果測定」の順に進みます。

Claude APIの請求を見て「高い」と思ったとき、最初に開くのは削減策の記事ではないでしょうか。
私もそうしました。
プロンプトキャッシュ、モデルの使い分け、Batch API。
どれも間違っていない話が並んでいます。

ただ、そのどれを適用すべきかは、自分の請求の内訳を割ってからでないと決まりません。
2026年8月、私は自分の環境でClaude APIとX APIのコストを分析しました。
そこで分かったのは、削減策を並べる前に順番があるということでした。

なお、この記事では課金の単位を「トークン」と書きます。
トークンとは、文章を細かく区切った単位のことです。
日本語ではおおよそ1文字が1〜2トークンにあたり、APIの料金はこの数で決まります。
送った文章の分が「入力トークン」、モデルが書いた文章の分が「出力トークン」です。

---

「使いすぎ」ではなく「設定を変えていないのに増える」が2026年の主原因

請求が増える4つの原因タイプ

呼び出し回数が増えた。
1回あたりの入力が長くなった。
1回あたりの出力が長くなった。
そして、モデル側のデフォルト挙動が変わった。

前の3つは自分の変更をたどれば見つかります。
やっかいなのは4つめです。
コードを一行も変えていないのに実効コストが動くため、原因を自分の側で探しても見つかりません。

2026年に起きたモデル側の仕様変更

Claude Opus 5では、thinking パラメータ（モデルに答える前の思考時間を取らせるかどうかの指定）を省略したリクエストが、モデルが自分で思考時間の長さを決めて答える動作になります。
この動作を適応的thinkingと呼びます。
デフォルトの effort（思考にどれだけ手間をかけるかの水準）は high です。
Opus 4.8では同じリクエストがthinkingなしで動作していました（出典: platform.claude.com のモデル移行ドキュメント、2026年8月14日確認）。

つまり、モデル名を新しくしただけで、同じコードでもモデルが答える前に考えた分の文章（思考トークン）を生成し始めます。
そして、思考トークンは出力トークンと同じレートで課金されます。

ここで効いてくるのが、入力と出力の単価差です。
たとえばClaude Sonnet 5は100万トークンあたり入力2ドル・出力10ドルで、出力が入力の5倍にあたります（出典: platform.claude.com/docs/en/about-claude/pricing、2026年8月14日確認）。
主要モデルはおおむねこの比率ですが、倍率はモデルごとに異なるため、自分が使うモデルの実額を価格ページで確認してください。
入力側を1割削る努力と出力側を1割削る努力では、金額に数倍の差が出ます。

---

手順0：自分の請求額が本当に異常かを公式ベンチマークで判定する

公式が出している平均額と自分の額を比べる

分析の前に、自分の額が異常なのかを確かめます。
Claude Code公式のコストページは、エンタープライズ導入全体の平均を開発者1人あたり1稼働日約13ドル、月150〜250ドルとし、90%のユーザーが1稼働日30ドル未満に収まるとしています（出典: code.claude.com/docs/en/costs）。

この数字を見て安心する人もいるでしょうし、逆に青くなる人もいるはずです。
どちらにしても、まず立っている位置が分かります。

絶対額ではなく月内の増加率と処理別の構成比を見る

ただ、この数値はチーム開発の平均です。
個人や小規模事業者が回している自動化のパイプライン（決まった処理を順につないで自動実行するしくみ）とは前提が違います。
絶対額を公式平均に合わせようとしても意味がありません。
見るべきは、月内での増加率と、処理別の構成比です。

以降この記事では、私の環境の金額を出しません。
全体に対する比率で書きます。

---

手順1：請求データを公式ツールで割る（モデル・日・APIキー・トークン種別）

Consoleのコストレポートで割れる粒度

Anthropic Consoleのコストレポートは、モデル別・日時別・APIキー別の内訳を表示できます。
棒グラフをクリックすると、時間単位、さらに分単位まで掘れます（出典: support.anthropic.com「Cost and usage reporting in Console」）。
閲覧できるのはDeveloper・Billing・Adminロールに限定され、権限が足りないとこの画面そのものが出ません。

Usage and Cost APIで4種のトークンに分ける

もう一段細かく見るなら、Usage and Cost APIです。
/v1/organizations/usage_report/messages を呼ぶと、モデル別・ワークスペース別に、未キャッシュ入力・キャッシュ読み取り・キャッシュ作成・出力の各トークンを集計できます。
集計の時間区切りは1分・1時間・1日から選べます（出典: platform.claude.com/docs/en/build-with-claude/usage-cost-api）。

ここでいうプロンプトキャッシュは、毎回同じ入力を保存し、次回以降に割安な単価で使い回すしくみです。
この4種を分けられることが要点です。
「入力が多い」だけでは打ち手が決まりません。
一方、保存した入力を示すキャッシュ作成だけが増え、再利用した入力を示すキャッシュ読み取りがゼロなら、保存はしているのに一度も再利用できていないと分かります。

ただし、このAPIはAdmin APIキー（組織全体の管理操作に使う、通常のAPIキーとは別種の鍵）が必要で、通常のAPIキーでは呼べません。

Pro/Maxプラン利用者はConsoleに出ない

Pro/MaxプランだけでClaude Codeを使っている場合、Consoleのこの情報は見られません。
これらのプランはConsole上の組織アカウントを伴わないため、Admin APIキーの発行対象にもなりません。
その場合はここで止まらず、次の手順2へ直行してください。
パソコン内に残る記録から、同じことをやれます。

3つの手段を粒度と必要な権限で比べる

---

手順2：リクエスト単位まで落とす（自社で実際にやった順番）

図2：請求額の実績と、APIを呼ぶ箇所を全部並べた一覧を突き合わせ、1回の会話のまとまりごとの集計で費用の大半を占めている処理を特定するまでの流れ。

最初にやるのはAPIを呼ぶ箇所と定期実行を全部一覧にすること

2026年8月14日、私はClaude APIとX APIのコストを分析しました。
このときは、1回の作業のなかで155回やり取りしました。
最初にやったのは請求データを見ることではありません。
ソースコードを保管している場所（リポジトリ）を対象に、APIを呼ぶ行を検索して一覧にしました。
あわせて、cron（決まった時刻に処理を自動実行するしくみ）の設定ファイルを開き、何時にどの処理が動くかを同じ一覧に書き出しました。

請求データには合計額しか出ません。
先にコード側でAPIを呼ぶ箇所を全部リスト化しないと、請求額が突出している日と、その時刻に動いた処理を並べて照合できません。

ローカルの記録ファイルを集計して実使用量を出す

リポジトリ全体を claude-opus-5 の文字列で検索したところ、記事生成のスクリプトがその指定を残していました。
自分で書いたコードですが、どのモデルを指定したままかは覚えていませんでした。
モデル指定は記憶に頼らず、リポジトリ全体を文字列検索して機械的に確認するのが確実です。

次にローカルの記録を見ました。
2026年8月14日時点で、私のパソコン内のClaude Codeの記録は合計約2GBあり、ここから実使用量を集計しました。
生データは ~/.claude/projects/<プロジェクト名>/<会話ID>.jsonl に置かれます。
.jsonl は、1行に1件のデータを並べたテキストファイルの形式です。

集計にはccusageというツールを使いました。
これはAnthropic公式ではなく、有志が公開している第三者製のツールです（出典: github.com/ryoppippi/ccusage）。
日次（daily）、月次（monthly）、利用量を5時間ごとに区切って数える単位（課金ウィンドウ／blocks）、会話セッション単位（session）で集計できます。
社内規程で外部ツールの利用に制限がある場合は、.jsonl を自前のスクリプトで読む方法でも同じことができます。

支配的だった処理をどう特定したか

ccusage session は、セッション（1回の会話のまとまり）ごとの合計金額を出します。
これを金額の降順に並べ、上位3件の金額合計が全セッションの金額合計の50%を超えるかを見ます。
超えていれば、削るべき対象はその3件のセッションで動いていた処理です。
超えていないなら、原因は個別の処理ではなく呼び出し回数そのものです。

前者なら、その3件のモデル指定と、入力トークンと出力トークンの比を見にいきます。
後者で見るのは次の3点です。

• 定期実行の間隔。1時間ごとに回す必要が本当にあるか
• 1回の実行で何度APIを呼んでいるか。ループの中で呼んでいないか
• 失敗時の再試行（リトライ）の設定。上限なしで再送していないか

私の記録について、上位3件が全体の何割だったかは、この記事の時点で数字を確定できていません（確認が必要）。
約2GBのログ全件の突き合わせが終わっていないためです。
確定している事実は一つ、記事生成のパイプラインで最上位モデルを指定したままにしていた点です。
このタイプの指定漏れは、集計を待たずに文字列検索だけで見つかります。

---

1回の呼び出しで送る文章が多いか、書かせる文章が多いかで打ち手が変わる

1回の呼び出しで、送る文章のトークン数が多いものを入力支配型、モデルが書く文章のトークン数が多いものを出力支配型と呼びます。

図3：支配的な処理の入力トークンと出力トークンの比を見て、入力支配型ならプロンプトキャッシュとcontext editing、出力支配型ならeffortの水準とモデル名の指定へ進むという分岐。

入力支配型の見分け方と打ち手

支配的な処理が絞れたら、その処理の入力トークンと出力トークンの比を見ます。

入力が支配的な処理は、長い指示書や資料を毎回送り直しているタイプです。
ここにはプロンプトキャッシュが効きます。
プロンプトキャッシュとは、システムプロンプトなど毎回同じ入力の先頭から連続する範囲を保存しておき、次回以降は割安な単価で再利用するしくみです。
以降この記事では、この範囲を「先頭から連続する範囲」と書きます。
キャッシュ読み取りの単価は標準入力価格の0.1倍です。

ただし、この再利用には条件があります。
送った入力を先頭から前回の内容と1文字ずつ照合し、先頭から一致した範囲までが割安な単価で再利用され、最初に違った文字以降は通常単価の入力として再送されます。
この先頭から連続する範囲をプレフィックスと呼び、この照合方式をプレフィックス一致と呼びます。

やるべき作業は並べ替えです。
システムプロンプトの先頭に現在時刻を差し込む書き方をやめ、毎回変わらない指示文を先頭側にまとめて置き直します。

出力支配型の見分け方と打ち手

出力が支配的な処理は、記事生成やコード生成のように長い文章を書かせるタイプです。
答える前に思考する動作（thinking）が有効な処理もここに入ります。

この型にプロンプトキャッシュは一切効きません。
キャッシュは送る文章を保存して再利用する仕組みです。
モデルが書いた文章は毎回新しいので保存対象になりません。
ここで変える設定は effort の水準と、リクエストに指定するモデル名です。

---

打ち手ごとの削減率と、価格前提で間違えやすいところ

公式が公表している削減幅と、効かない条件

Anthropicが自社の評価で数値を出している施策を、効かない条件とあわせて並べます。
どの数値も特定の作業パターンでの測定結果であって、請求額の予測ではありません。

キャッシュの書き込みコストは1回きりの利用だと損になる

プロンプトキャッシュには、読み取り時の割安さとは別に、書き込み側の追加コストがあります。
書き込み単価は標準入力より高く設定されており、保持時間（TTL：保存されたキャッシュが有効な時間）が長い設定ほど高くなります。
具体的な倍率はモデルとTTLの設定で変わるため、価格ページで確認してください。

要点は、1回しか使わないプロンプトをキャッシュすると、かえって高くつくということです。
繰り返し送るものだけをキャッシュ対象にしてください。

2026年8月時点の価格で間違えやすいところ

Claude Sonnet 5の100万トークンあたり2ドル（入力）・10ドル（出力）は、ローンチ時には2026年8月31日までの導入価格として発表されました。
しかしこれが標準価格となり、9月1日に予定されていた3ドル・15ドルへの引き上げは実施されないとされています（出典: platform.claude.com/docs/en/about-claude/pricing、2026年8月14日確認）。
2026年8月中旬に更新された二次記事の多くが、まだ「9月1日に値上げ」と書いています。

私も自分の環境を分析するとき、記憶していた単価と実際の表が合わなくて確認し直しました。
モデル名と価格は、毎回 platform.claude.com/docs/en/about-claude/pricing を開いて確認してください。
100万トークンまで送れる拡張設定を使い、処理地域を米国に指定する inference_geo: "us" を付けた場合、Claude 4.6以降のモデルでは1.1倍の価格乗数が適用される点も見落としやすいところです。

---

効果測定：削減できたかを比率で検証する

context editingは削除前後のトークン数を比べる

設定を入れたつもりでも、実際には削減処理が動いていない状態が一番まずい状態です。

context editingを入れたなら、レスポンスに返る2つの値を比べます。
古いツール実行結果を消す前の総量が original_input_tokens、消した後に実際に課金される量が input_tokens です（出典: platform.claude.com/docs/en/build-with-claude/context-editing）。

削減率は次の式で出します。

削減率 = 1 −(input_tokens ÷ original_input_tokens)

たとえば original_input_tokens が50,000、input_tokens が8,000なら、1 −(8,000 ÷ 50,000)= 0.84 で84%の削減です。
2つの値が同じままなら、設定は入っているが、削除やキャッシュ再利用が一度も実行されていない状態です。

キャッシュは cache_read_input_tokens がゼロでないかを見る

キャッシュを入れたなら、レスポンスの cache_read_input_tokens（キャッシュから読み込めた入力トークン数）を見ます。
繰り返し同じリクエストを送っているのにこの値がゼロなら、どこかにキャッシュを無効化している要素があります。

よくある原因は3つです。
システムプロンプトの先頭に現在時刻を入れている。
JSONのキー順が毎回変わる。
ツールの一覧が呼び出しごとに違う。
どれも先頭からの一致が成立せず、キャッシュが再作成されます。

なお、キャッシュ可能な最小の長さは約1,024トークンです。
これより短い先頭から連続する範囲は、エラーも出さずにキャッシュされません。

Agent SDKでは costUSD を自分で積算する

Agent SDK（Claudeを組み込んだプログラムを作るための開発キット）を使っている場合は、modelUsage からモデル別の costUSD（そのモデルで発生した費用のドル額）を取得できます。
ただし各 query() が返すのは自身の total_cost_usd だけで、複数回呼ぶなら合計は自分で積算する必要があります（出典: platform.claude.com/docs/en/agent-sdk/cost-tracking）。

---

コスト分析チェックリスト

■ 手順0：異常かどうかの判定
□ 直近1か月の総額を出し、公式ベンチマークと比べる
   （1人1稼働日 約13ドル / 月150〜250ドル / 90%が1稼働日30ドル未満）
□ 絶対額ではなく「月内の増加率」を見る

■ 手順1：請求データを割る
□ Consoleのコストレポートを開く（要 Developer / Billing / Admin ロール）
   → モデル別・日別・APIキー別に分け、突出した日を分単位まで掘る
□ Usage and Cost API を呼ぶ（要 Admin APIキー）
   GET /v1/organizations/usage_report/messages
   → 未キャッシュ入力 / キャッシュ読み取り / キャッシュ作成 / 出力 に分ける
□ Pro/Maxプランのみの場合はここを飛ばして手順2へ

■ 手順2：リクエスト単位まで落とす
□ リポジトリ全体を検索し、APIを呼んでいる箇所を全部リストにする
□ cron など定期実行の設定を全部リストにする
□ 各箇所のモデル指定を文字列検索で確認する（記憶に頼らない）
□ ~/.claude/projects/<プロジェクト名>/<会話ID>.jsonl を集計する
   ccusage daily / monthly / blocks / session
□ セッション単位で降順に並べ、上位3件が全体の何割かを出す
   → 半分を超える：その3件が原因
   → 超えない：呼び出し回数が原因。定期実行の間隔 / 1実行あたりの
     呼び出し数 / リトライ上限の3点を確認する

■ 分岐点：支配的な処理の入力トークンと出力トークンの比を出す
□ 入力支配型 → プロンプトキャッシュ / context editing / Tool Search Tool
□ 出力支配型 → effort の引き下げ / モデル選択 / 出力の長さをプロンプトで指定

■ 効果測定
□ context editing：1 −(input_tokens ÷ original_input_tokens)が削減率
   （2つの値が同じならキャッシュ再利用が一度も起きていない）
□ プロンプトキャッシュ：cache_read_input_tokens がゼロでないか
   ゼロの場合の典型原因：先頭の現在時刻 / JSONのキー順 / ツール一覧 /
   先頭から連続する範囲が1,024トークン未満
□ Agent SDK：modelUsage の costUSD を自分で積算する

■ 価格前提の確認（毎回）
□ platform.claude.com/docs/en/about-claude/pricing を開き直す
□ 100万トークンまで送れる拡張設定 + inference_geo:"us" は1.1倍

---

よくあるご質問

まとめ

請求が高いと感じたとき、削減策のカタログを先に読むと、自分に効かない施策に時間を使うことになります。
私は2026年8月に自分の環境を分析して、リポジトリを検索してAPIを呼ぶ行と定期実行の設定を一覧にする作業を先にやる順番に落ち着きました。

公式ベンチマークで異常かを判定する。
請求データをモデル・日・トークン種別に割る。
ローカル記録でリクエスト単位まで落とす。
入力支配型か出力支配型かで打ち手を分ける。
比率で効果を検証する。

このうち一番飛ばされやすいのが、最後の効果測定です。
cache_read_input_tokens がゼロのまま何か月も走っている環境は、珍しくないだろうと思います。

私の環境で支配的な処理の比率は、まだ全件の突き合わせを終えていません。
分かったら比率の形で追記します。
APIコストの内訳を割るところで詰まったときは、ご相談いただければ一緒に見ます。

自社に合う導入設計を、相談から。

対象部署・育成人数・業界固有の業務を伺い、法人受講とAI導入の進め方を整理します。

法人受講を相談する無料体験会を確認する