Skip to content
無料相談
Claude Code の課金が跳ねる3つの瞬間 — 公式ドキュメントで検証

Claude Code の課金が跳ねる3つの瞬間 — 公式ドキュメントで検証

最終更新日: / 公開日:

最終更新日: / 公開日:

本記事のポイント

  • Claude Code のトークン課金が "全文フル価格" で発生するのは、セッションの最初・TTL 超えの再開・モデル切替直後の 3 つの瞬間だけ。連続作業中は履歴が約 1 割の単価で読めます
  • よく言われる「定額でも 5 分でキャッシュが冷える」は誤り。サブスク(定額)は 1 時間 TTL で、5 分に落ちるのは従量課金 / API キー利用のときです
  • 数値と挙動は 2026 年 7 月時点の Anthropic 公式ドキュメント 12 本で裏取りしました。自社条件で同じ検証を再現するプロンプトを巻末キットに用意しています

先に結論を早見表で示します。現場でよく聞く 3 つの不安と、公式ドキュメントで検証した実際は次の通りです。

よく聞く不安 検証した実際
巨大セッションは一言指示するたびフル課金? 半分だけ正しい。warm(温)なら履歴は約 1 割の単価で読める
モデルを切り替えたら作業がやり直しになる? 起きない。切替直後の 1 ターンだけ "全文フル再読み" が乗る
定額プランでも 5 分でキャッシュが冷える? 誤り。サブスクは 1 時間 TTL(従量に落ちたときだけ 5 分)

「セッションが 1M のうち 68 万トークンまで膨らんでいる。一言指示するたびに 68 万トークン分フルで課金されているのでは」。Claude Code を使い込む人からよく聞く不安です。本記事では、この直感が公式仕様のどこまで正しくどこから勘違いなのかを、一次ソースと突き合わせて検証します。特別な知識は不要で、巻末キットを使えば自社のプラン・利用形態で同じ検証を再現できます。

1. 検証の背景 — 2 つの直感はどちらも「半分正しい」

「行き詰まったので高性能モデルに切り替えたい。でも切り替えたら、今までの会話を最初から読み直しになってトークンが無駄になるのでは」。冒頭の課金への不安と並んで、これも Claude Code の相談でよく出てくる声です。

この 2 つの直感 — 「巨大セッションは毎ターンフル課金」「モデル切替で読み直し」 — は、どちらも半分正しく半分間違っています。そして半分を勘違いのまま運用すると、コストの読みを外します。厄介なのは、正しい半分があるぶん体感として説得力を持ってしまう点です。だからこそ、感覚ではなく公式仕様で線を引き直す価値があります。

検証の入口になる事実がひとつあります。Claude の API(Messages API)はステートレスで、サーバー側は過去のやり取りを覚えていません。だから毎回のリクエストで会話履歴を丸ごと送り直しています。「毎ターン 68 万トークンを送っている」という直感は、この一点では正しい。問題は「送っている量」と「課金される額」が別物だということで、ここから先が勘違いの温床です。Claude Code 自体がはじめての方は、先に マーケターのための Claude Code 入門 を読むと前提がつかめます。

2. 検証のセットアップ — 公式ドキュメント 12 本で裏取りした条件

検証の条件を正直に開示します。この記事は実費を計測したベンチマークではなく、現場の相談ログにあった主張を Anthropic の公式ドキュメントと突き合わせて真偽を確かめた、ドキュメント検証です。

  • 対象: プロンプトキャッシュ、Messages API のステートレス設計、Claude Code の TTL 自動選択、/compact(compaction)、1M コンテキストの料金、モデルの内省など、トークンコストに関わる挙動
  • 一次ソース: Anthropic の公式ドキュメント / リサーチ計 12 本(末尾の参考文献)
  • 取得日: すべて 2026 年 7 月時点。料金・TTL・キャッシュ倍率はモデル更新で変わりうるため、最新は公式表を参照してください
  • 検証手順: 相談ログの主張を項目に分解 → 各項目を独立して公式ソースで再確認 → 一次ソースで裏が取れない主張は本文で断定せず留保

この過程で、相談ログにあった主張のうち 4 点を訂正しています(TTL は一律 5 分ではない / キャッシュは会話単位ではなくディレクトリ単位 / モデルのサイレント自動切替に公式根拠はない / 最小キャッシュ長は一律ではない)。以降はこの検証結果を、仕組み → 考察 → 使い分けの順に並べます。

3. 結果①:API はステートレス、モデルを切り替えても作業はやり直さない

まず土台の事実から。Messages API はステートレスなので、毎回のリクエストでシステムプロンプト・過去の全メッセージ・ツールの実行結果をまるごと入力として送り直しています。打った指示が一言でも、その裏では 68 万トークンの履歴が毎回一緒に送られている。これはモデルの種類にも指示の長さにも関係なく常にそうで、「送っている量」という意味では巨大セッションは確かに毎ターン巨大な入力を送っています。

ここから、モデル切替の不安に決着がつきます。会話の途中でモデルを切り替えても、作業はやり直しになりません。API がステートレスということは、裏を返せば会話の状態が全部リクエストの中(トランスクリプト)に入っているということです。切り替えた先の新しいモデルはそのトランスクリプトをまるごと受け取るので、ファイルを読み直す・さっきの作業を再実行するといったことは起きません。履歴を見れば経緯が全部わかる状態で引き継がれます。

つまり「モデルを変えたら会話を読み直す」というイメージは半分だけ当たっています。読み直すのは "課金上の入力" であって "作業内容" ではない。失われるのは後述するキャッシュ(計算のショートカット)だけで、文脈そのものは失われません。

4. 結果②:プロンプトキャッシュで再送分は約 1 割、warm と cold で分かれる

では毎ターン 68 万トークンをフル課金しているのか。ここでプロンプトキャッシュが効きます。会話の前半のような安定して変わらない部分(接頭辞)は、2 回目以降キャッシュから読めます。この "キャッシュ読み取り" は通常の入力トークン単価の 0.1 倍、つまり 1 割の値段です。フル価格がかかるのは基本的に「今回新しく増えた差分」だけになります。

厳密には、1 ターンの入力コストはおおよそこう分解できます。

  • キャッシュ済みの接頭辞 × 0.1(1 割で読む)
  • 今回の新規分 × 1.0(フル価格)
  • 新規分のキャッシュ書き込み × 1.25(5 分キャッシュの場合)
  • 出力トークン × 出力単価

キャッシュ書き込みは 5 分キャッシュで 1.25 倍、1 時間キャッシュで 2 倍。読み取りはどちらも 0.1 倍です。だから実際は「68 万トークンをフル価格で毎ターン」ではなく「68 万の約 1 割 + 増えた差分」が毎ターンの入力コスト。冒頭の不安「巨大セッションだから毎指示ヤバい」は、ここで半分崩れます。ただし長い履歴の "1 割" が毎ターン乗り続けるのも事実で、従量課金だと地味に効いてきます。

キャッシュには 2 つの状態があり、これを混ぜると話が矛盾して聞こえます。

状態 条件 そのターンの入力コスト
warm(温) 同じモデルで、間隔を空けずに続けている 接頭辞は 0.1 倍 + 差分フル → 安め
cold(冷) 最初のターン / 長く放置後 / モデル切替直後 接頭辞ごと全部フル価格で 1 回読む → 高い(直後に再キャッシュ)

「増えた分だけ課金」は warm の話、「全文フルで読み直し」は cold の話で、両方とも本当です。ここで検証で確定した重要な制約が 2 つあります。ひとつは、キャッシュはモデルごとに別だということ。あるモデルが作ったキャッシュを別のモデルは読めないので、モデルを切り替えると内容が同じでも新モデルには cold から入ります。もうひとつは、キャッシュヒットには接頭辞が 100% 完全一致している必要があること。途中の文言が 1 文字でも変われば、そこから後ろはキャッシュが効きません。

TTL(キャッシュの有効時間)は認証方法で自動的に選ばれます。ここが相談ログからの最大の訂正点です。

  • サブスク(定額): 自動で 1 時間 TTL。ただしプラン上限を超えて従量課金に入ると 5 分に降格する
  • API キー / 各種クラウド経由: 既定は 5 分(環境変数で 1 時間に変更可)
  • サブエージェント: サブスクでも 5 分固定

つまり「5 分以上離席したらキャッシュが冷える」は、サブスクの通常利用ではあてはまりません。コーヒーを淹れて 30 分後に戻っても、1 時間 TTL の内側ならまだ warm です。なお TTL は使うたびにタイマーがリフレッシュされる(使い続ければ延命する)一方、無限に延命される保証ではありません。

5. 結果③:窓サイズ(1M)とコストは別軸、200K の割増はない

混同しやすい 2 つの軸を分けておきます。「コンテキストの窓が大きい(1M)」ことと「コストが高い」ことは別の話です。

  • 窓サイズ(1M)= 容量の天井。ここまで貯められるという上限で、埋まりに近づくと Claude Code は自動でコンテキストを圧縮(auto-compact)します。主要モデル(Opus 4.8 など)の 1M はネイティブのデフォルト窓で、ベータ指定は要りません
  • warm / cold = コスト。これは結果②のキャッシュの話で、窓サイズとは別軸です

検証で明確に否定できたのは「200K トークンを超えたら単価が上がる」という段差の存在です。旧 Sonnet の 1M ベータにはそうした割増がありましたが、現行の 1M モデル(Opus 4.8 等)には引き継がれていません。窓の全域が標準単価で、90 万トークンのリクエストも 9 千トークンと同じ per-token 単価です(キャッシュやバッチの割引も全域で標準どおり効きます)。

つまりコストは「閾値を超えた瞬間に跳ねる」のではなく、文脈量に応じてなだらかに増えます。文脈が大きいほど毎ターン処理する接頭辞も大きくなり、warm でもその接頭辞に 0.1 倍が乗り、cold ならその全量をフル価格で読む。だから「1M あるから貯め放題」ではありません。従量課金なら、大きな窓でも文脈は絞ったほうが warm の 0.1 倍分も cold の全量も小さくなって安い、という結論になります。

6. 考察:課金が跳ねるのは「3 つの瞬間」だけ

ここまでの結果を運用者の視点でまとめると、"全文をフル価格で読む cold" が起きるのは次の 3 つの瞬間だけです。

  1. セッションの最初のターン
  2. TTL(5 分または 1 時間)を超えて放置し、戻ってきた最初のターン
  3. モデルを切り替えた直後の最初のターン

この 3 回だけ、そのときのコンテキスト全量をフル価格で 1 回読みます。それ以外、連続して往復している間は接頭辞が約 1 割で読めるので、1 ターンあたりのコストは思うほど高くない。「巨大セッションだから毎指示ヤバい」ではなく「高いのはこの 3 瞬間だけ」が正確な理解です。

もうひとつ、放置しているだけのセッションはコストゼロです。API を呼んでいなければ課金は発生しません。費用が出るのは「戻ってきて最初の一言」を打った瞬間、つまり上の 2 番の cold read です。→ 自社の利用形態でこの 3 瞬間がどこに出るかは、巻末の 実行キット①(所要 20 分)で洗い出せます。

7. 考察:/compact はタダじゃない、複数ディレクトリは別キャッシュ

コスト対策として「こまめに /compact」を勧める声がありますが、検証すると冷静に見たほうがよい挙動でした。/compact は会話を要約してコンテキストを縮小しますが、その要約を作るために現在のコンテキスト全体を 1 回読みます(公式の例では入力 18 万トークンを処理して 3,500 トークンの要約を出力しています)。つまり compact 自体が "実質フル 1 回読み" を発生させます。

  • 休憩前に compact する → 「今フル 1 回(要約作成)」+「戻って小さい文脈を読む」
  • compact しない → 「戻ってフル 1 回」

単発の休憩ではどちらもフル読み 1 回を払います。compact の得は「その後、小さくなった文脈で何ターンも回せる」将来分であり、しかも要約すると細部は多少失われます。compact が本当に効くのは、圧縮後も同じ文脈で長く作業を続けるときと、安い(または定額の)モデルで compact してから高い従量課金モデルに渡すときの 2 場面です。なお Claude Code はコンテキスト上限に近づくと自動で管理し(まず古いツール出力を捨て、足りなければ会話を要約する)、手動 compact はこの自動処理を前倒しするイメージです。

複数セッションの扱いも勘違いしやすい点でした。「どれか 1 つを動かしていれば他も warm に保たれる」は誤りです。Claude Code のキャッシュは実質「マシン + ディレクトリ(+ モデル + 接頭辞一致)」単位なので、同じディレクトリで並行して動かすセッションは互いのキャッシュを読み合いますが、別ディレクトリ(別プロジェクト、別 worktree)のセッションは接頭辞が別物なので温め合いません。別 CWD を行き来する運用では、戻るたびに各セッションで 1 回ずつ cold read が起きます(TTL を超えていれば)。「会話ごと」ではなく「ディレクトリごと」に別、というのが正確な理由です。会話を分岐(フォーク)させた場合、分岐点までは元セッションのキャッシュに部分的にヒットし得ますが、フォークの実挙動は公式に明示されていないため理屈として捉えておくのが安全です。複数プロジェクトを一人で回す体制づくりは 一人マーケターの AI 活用 にもまとめています。

8. 使い分け指針:定額と従量で「意味」が変わる

なぜここまでコストにこだわるかは、課金形態で意味が変わります。

定額(サブスク)の場合。トークン単位の課金ではないので、1 ターンあたりのトークン額そのものは直接の心配になりません。cold read が意味するのはレート制限と少しの待ち時間くらいで、しかも 1 時間 TTL という余裕もあります。気にすべきはむしろコンテキスト上限(主要モデルは 1M トークン)と、長すぎる文脈による品質・速度の低下です。この観点は AI で業務効率を上げる考え方 とも地続きです。

従量課金(pay-per-use)の場合。ここは実費です。たとえば最上位モデルは入力 $10 / 出力 $50(100 万トークンあたり)といった単価で、標準的な Opus クラスでも入力 $5 / 出力 $25。cold read の "全文フル 1 回" がそのまま金額に乗ります。そして厄介なことに、従量課金モードでは TTL が 5 分に落ちる。つまり「コストが気になるモード」ほど「キャッシュが早く冷えるモード」でもある。だからこそ従量モデルに渡す前に定額側で compact しておく価値が高いわけです。

一点、検証で断定を避けた留保があります。「特定のモデルを使っていると勝手に別の高性能モデルに切り替わる」という体験談をよく聞きますが、通常のプロンプトで Claude Code がサイレントにモデルを降格・切替するという公式の記述は見当たりませんでした。公式に存在するのは安全分類器によるフォールバックで、特定カテゴリ(サイバー / 生物・化学 / モデル蒸留)を検知したときだけ別モデルが応答し、しかも通知されます(発生は全体の 5% 未満)。挙動を断定するのは避けますが、どちら向きの切り替えでも「文脈は維持・作業はやり直さない・切り替え直後の 1 ターンだけ cold」という原則は共通です。

翌日から使える運用ルールに落とすと、次の 5 つです。

  • 高いのは 3 瞬間だけと知る(最初 / TTL 超えの再開 / モデル切替)。連続作業中は神経質にならなくてよい
  • 定額で使う間は、トークン節約より「コンテキスト上限」と「集中力(長すぎる文脈は品質を落とす)」を基準に、区切りのいいところで一度 compact する
  • 従量モデルで局所的に解かせたいときだけ、切り替え直前に定額側で /compact。大きな文脈を高い側に食わせない
  • 巨大セッションを長時間放置してバウンスするより、用が済んだセッションは畳む
  • 隔離したいとき(worktree / 別ディレクトリ)は、それが cold から始まると承知で使う

9. 補足の検証:AI は自分のモデルを言い当てられない

コスト最適化のためにモデルを切り替えたとき、「本当に切り替わった?」を確かめたくなります。ここも検証しておくと、モデル本人に聞いても確実な答えは返りません。

モデルが自分のアイデンティティを知るのは、システムプロンプトでそう伝えられているからです(たとえば「現在選択中のバージョンは Claude Opus 4.8」といった一文)。一方で、モデルが「実際に自分を動かしている重みはどれか」を内省(introspection)で言い当てる能力は、Anthropic 自身の研究で "highly unreliable"(きわめて不安定)とされています。ある実験での成功率は約 2 割でした。

含意はシンプルです。今どのモデルで動いているか・切り替わったかどうかは、AI の自己申告ではなく、ハーネス(Claude Code)の表示で確認する。ここは人間側が握っておくべき情報です。→ 料金・TTL とあわせて自社が使うモデルの前提を再検証する手順は、巻末の 実行キット②(所要 15 分)にまとめています。

10. 検証の限界と次の検証

この検証には限界があります。誠実に開示しておきます。

  • 実費のベンチマークではない。本記事は公式ドキュメントの突き合わせで、n = 一次ソース 12 本。同一プロンプトを両モデルに投げて請求額を計測した実測ではありません。金額の体感は自社の利用ログで確かめてください
  • フォークのキャッシュ挙動は留保。分岐点までの部分ヒットは理屈上あり得ますが、Claude Code のフォークが実際にキャッシュをどう扱うかは公式に明示されていません
  • 数値はモデル更新で動く。料金・TTL・キャッシュ倍率・1M の扱いは、2026 年 7 月時点の値です。モデルが更新されれば前提が変わります

次の検証として現実的なのは、自社の利用ログ(定額のレート制限到達回数、従量の請求内訳)を 1 ヶ月ぶん集計し、「3 瞬間の cold read が実際にどれだけの金額 / 待ち時間になっているか」を実測することです。ドキュメント上の 0.1 倍・3 瞬間が、自社の使い方でどの程度効いているかは、そこではじめて数字で見えます。

まとめ

  • モデルを切り替えても作業のやり直しは起きない。起きるのは "課金上の全文再読み" が 1 回だけ
  • プロンプトキャッシュはモデル別・接頭辞完全一致。warm なら接頭辞は約 1 割の値段で読める
  • 高くつくのは 3 瞬間だけ(最初・TTL 超えの再開・モデル切替)。放置セッションは 0 円
  • Claude Code のサブスクは 1 時間 TTL(従量に落ちると 5 分)。「5 分で冷える」は従量 / API キー利用時の話
  • /compact はタダじゃない(要約に全文を 1 回読む)。真価は "定額で compact → 従量に小さく渡す"
  • 窓サイズ(1M)とコストは別軸。200K を境にした割増はなく、per-token 単価は窓の全域で一定
  • 「今どのモデルか」は AI の自己申告ではなく、ハーネスの表示で確認する(モデルの内省は不安定)

コストは「3 つの瞬間をどこで払うか」を設計する問題です。humbulls では、こうした AI ツールの運用設計から実務への落とし込みまで Growth Partner サービス で伴走しています。まずは巻末キットで、自社の使い方の "跳ねる瞬間" を洗い出すところから始めてみてください。

🤖 AI 実行キット

本文の検証結果を、そのまま自社の条件に当てはめて確かめるためのキットです。プロンプトは Claude(ブラウザ版で可)にコピペすれば動きます。

キット① 自社の利用形態から「課金が跳ねる瞬間」を洗い出す — 20 分

種別: 判断キット 使うもの: Claude(ブラウザ版で可) 事前に用意するもの: 普段の Claude Code の使い方メモ(プラン、1 日に何セッション、ディレクトリをいくつ行き来するか、モデルを切り替えるか)。粒度はバラバラで構いません。

プロンプト:

Claude Code のトークンコストについて、私の使い方で "全文フル価格で読む
cold read" がどこで起きるかを診断してください。

【私の利用状況】
- 契約形態: 定額サブスク(記入例。従量課金 / API キーなら書き換え)
- 1 日のセッション数: 3〜4(記入例)
- 行き来するディレクトリ数: 2(サイト制作 / アプリ開発。記入例)
- モデル切替: 行き詰まったとき上位モデルに切り替える(記入例)
- 離席の傾向: 30〜60 分空くことがある(記入例)

【診断基準(必ずこの基準に従うこと)】
- cold read(全文フル価格で 1 回読む)が起きるのは次の 3 つだけ:
  (1) セッションの最初のターン
  (2) TTL を超えて放置後に戻った最初のターン
  (3) モデル切替直後の最初のターン
- TTL: 定額サブスク = 1 時間 / 従量課金・API キー = 5 分 /
  サブエージェント = 5 分固定
- キャッシュは「マシン + ディレクトリ + モデル + 接頭辞完全一致」単位。
  別ディレクトリ・別モデルは温め合わない
- 放置しているだけ(API を呼んでいない)セッションは 0 円

【出力】
1. 私の 1 日の使い方で cold read が発生する箇所を時系列で列挙
   (どのセッション / 何が原因の cold か)
2. 各 cold read が「避けられる / 避けられない」の判定と根拠 1 行
3. 定額 / 従量それぞれの場合に、私が優先すべき節約アクションを 3 つ

出力の確認ポイント:

  • cold read の原因が (1)〜(3) 以外に挙げられていたら誤り。連続往復中のターンを「毎回フル課金」と診断していないか確認してください
  • 定額と診断された場合、節約アクションが「トークン削減」中心なら軸がずれています。定額で効くのはコンテキスト上限と品質・速度の管理です

うまくいかないとき:

  • 使い方が複雑で列挙が長くなりすぎる → 「一番よく使う 1 日の典型パターン」だけに絞って再実行

キット② 料金・TTL・キャッシュ倍率を公式ドキュメントで再検証する — 15 分

種別: 検証キット 使うもの: Claude(ブラウザ版で可。ウェブ参照が使える環境だと確実) 事前に用意するもの: 自分が使っているモデル名とプラン。本記事末尾の参考文献 URL(公式ソース)

プロンプト:

本記事で前提にしている数値が、今も公式ドキュメントと一致するかを
再検証してください。数値はモデル更新で変わるため、現時点の値に
更新した表がほしいです。

【私が使っているもの】
- モデル: Opus クラス(記入例。実際に使うモデル名に書き換え)
- プラン: 定額サブスク(記入例)

【検証してほしい項目(本記事の前提値)】
- キャッシュ読み取り = 入力単価の 0.1 倍
- キャッシュ書き込み = 5 分 1.25 倍 / 1 時間 2 倍
- TTL = サブスク 1 時間 / 従量・API キー 5 分 / サブエージェント 5 分固定
- 1M 窓は 200K を境にした割増なし・per-token 一定
- 使っているモデルの入力 / 出力単価

【参照先(必ず公式一次ソースで確認すること)】
- Prompt caching(platform.claude.com のドキュメント)
- Claude Code の Prompt caching / Costs ドキュメント
- Pricing / Models overview

【出力】
1. 各項目「本記事の前提値」と「現時点の公式値」を並べた比較表
2. 変わっている項目があれば、何がどう変わったかと出典 URL を明記
3. 変わっていなければ「2026 年 7 月時点から変更なし」と結論

出力の確認ポイント:

  • 出典 URL が公式ドメイン(platform.claude.com / code.claude.com / anthropic.com)になっているか確認してください。二次情報だけを根拠にしていたら再実行します
  • 「変更あり」と出たら、本記事の判断(3 瞬間・warm/cold の考え方)が崩れる変更か、単価だけの変更かを見分けてください。仕組みが変わっていなければ運用ルールはそのまま使えます

うまくいかないとき:

  • モデルによって最小キャッシュ長など細部が違う → 細部は一律ではないので、まず単価・TTL・0.1 倍の 3 点だけ確定させれば運用判断には十分です

参考文献(すべて 2026 年 7 月時点で確認)

文責:humbulls / 栗田一輝