「Claude Code」セッションの価値を最大化する

2026年8月15日原文(claude.com)

概要

Claude Codeのリクエストは 入力トークン と 出力トークン の2段階課金
プロンプトキャッシュ 活用でコスト最適化が可能
セッション履歴やツール出力が 文脈（コンテキスト） に蓄積される仕組み
モデル切替や/effort変更 はキャッシュ破棄の要因
サブエージェント 活用で不要な履歴を本体コンテキストから分離可能

Claude Codeにおけるトークン課金とプロンプトキャッシュの仕組み

Claude Codeのリクエスト処理は プレフィル（入力） と デコード（出力） の2段階
- プレフィル：システムプロンプトや会話履歴を 入力トークン としてGPUに送信
- デコード：モデルが 出力トークン を1つずつ生成、1トークンごとにGPUを長時間占有
出力トークン は 入力トークンの約5倍のコスト
出力には「思考トークン」も多く含まれ、/effortコマンドで思考量調整が可能
- /effort設定はセッションごとに保持され、次回以降もデフォルトで適用
/modelや/effortの変更時は キャッシュ破棄 が発生し、全履歴が再度フルコストで送信される

プロンプトキャッシュの動作原理とコスト最適化

プロンプトキャッシュ ：直前のリクエストと同一のトークン列で始まる場合、その部分の状態をキャッシュから再利用
- キャッシュからの読み出しは 通常入力の0.1倍のコスト
- キャッシュへの書き込みは 通常入力の最大2倍コスト （ただし1回限り）
Claude Codeは全リクエストでキャッシュを自動管理
- キャッシュ利用のためにはリクエスト先頭部分（ツール定義、システムプロンプト、CLAUDE.md、会話履歴）が完全一致している必要
キャッシュ破棄要因
- /model、/effort、fast mode、/compactの利用や、リクエスト先頭部分の変更
- キャッシュ有効期限：サブスクリプションは1時間、APIキーは5分
/rewind で直近の履歴のみ削除すれば、キャッシュは維持されコスト増加なし
- /compactは会話全体を書き直すためコスト増加

セッションコストの決定要素とコンテキスト管理

セッションコストは 文脈（コンテキスト）に含まれるトークン数 と それが何ターン保持されるか が主要因
コンテキストには以下が含まれる
- ツール定義、システムプロンプト、CLAUDE.md（起動時にロード）
- 会話中に追加されたツール結果（ファイル読み込みやコマンド出力）
ファイル参照は@メンション推奨 ：最初のリクエストに添付されReadコール不要
コマンド出力は30,000文字超で自動的にファイル化、会話にはプレビューのみ
不要な履歴や出力は/clearや/compactで整理
- /renameでセッション名変更後に/clearで履歴管理
- /autocompactで自動コンパクト設定も可能（Claude Code v2.1.221+）

サブエージェントの活用

サブエージェント ：独立したコンテキストで処理し、本体には結果のみ返却
- 本体コンテキストが不要な履歴で圧迫されるのを防止
- サブエージェントは独自のトークンコストが発生、小規模処理では割高
- 大量出力処理やノイズが多い作業で有効
定期的に実行するノイジーなジョブは model: haiku や sonnet 指定でサブエージェント化推奨

コスト最適化のための実用Tips

/model, /effort, fast modeの切替はセッション開始直後か/clear直後が最適
/rewind で不要なターンのみ削除し、キャッシュ維持
@メンション でファイル指定しReadコール削減
CLAUDE.md には頻繁に使うコマンドや静かなフラグを記載
/clearや/compact で文脈の無駄な肥大化を防止
サブエージェント で不要な履歴を本体から切り離し

以上がClaude Codeのトークン課金・キャッシュ・コンテキスト管理の要点とコスト削減の実践知となります。

Hackerたちの意見

予想外のキャッシュの書き換えがすごくコストかかってる気がする。キャッシュのTTLを1時間に設定してて、書き換えを引き起こすようなことは何もしてないのに（時間通りのレスポンスで、モデルや努力、ツールの変更もなし）。400Kトークンのところでメッセージを書くと、/usageではキャッシュ書き込みの増加がほんの少ししか見えない。次のメッセージではキャッシュ書き込みが800Kになってて、最終的には説明もなしに2Mのキャッシュ書き込みに達することが多い。これが起こるのは、/btwを使ったり、コードのレビューを頼んだり、他のランダムなタイミングの時なんだけど。誰かこれがどうなってるか知ってる？

└

あなたの質問には答えないけど、ステータスラインでキャッシュの期限がどれくらい近いかを教えてくれるclaude stop hookを使ってるよ。https://pastebin.com/JLXUG16Q 完全にvibecodedだから、@はやめてね。

└

/btwがHaikuみたいな低いレベルのモデルを使ってるんじゃないかと長いこと疑ってるけど、確認はできてない。レビューをトリガーする方法によっては、サブエージェントを使ってるかもしれないね？

└

Claude Codeの「既知の」バグに遭遇してるかもね。: https://github.com/anthropics/claude-code/issues/63930

プレフィックスキャッシュが努力に結びついてる理由を説明できる人いる？よくFableをxhigh努力で動かして、学部レベルを超えた統計モデリングをやってるんだけど。Claude Fableは修士号レベルの出力を出して、その後、いろんな部分を説明してもらうために何度も往復するんだ。最初の部分は確実に追加の努力を使ってるけど、質問の演習はもっとシンプルなモデル、もしくは同じモデルでずっと少ない努力でも答えられることなんだよね。

└

一つのコツは、高努力モデルと対話している時に、単に早い答えを求めることだね。バカみたいだけど、これをいつもやってて効果がある。今対話してるから、考えずに超速の答えが必要だって伝えるだけ。努力がキャッシュにリンクしてる理由も知りたいな、かなり不便だから。努力を示すためのトークンが最初に一度だけ渡されて、その後の思考トレースでは渡されないのか、それとも単純に異なる努力には異なるモデルの重みがあるのかな？

└

上にモデルにその推論予算について教えるシステムプロンプトがあるんじゃないかな。だから推論の努力を切り替えるとキャッシュが壊れちゃうんだ。

これは「持ち方が間違ってる」っていうAnthropic版のように感じる。(1) 1) https://www.wired.com/2010/06/iphone-4-holding-it-wrong/

└

もっとひどい感じ。どのシステムでもすでに最適化されてるような初心者レベルの提案ばかりだよ。

└

ステップ1: 同じレベルの品質で10倍遅くて2〜5倍高いLLMを使わないこと。

@-mentionファイルを名前で呼ぶ代わりに。Claudeは好きだけど、デスクトップアプリでは@メンションが壊れてる。同じプロジェクトで同じクエリ「@ephem」を入力すると、CLIでは：https://imgur.com/a/VZMUCOa（良い、関連性のある結果）デスクトップでは：https://imgur.com/a/QLSo4Ms（悪い、無関係）これについて問題を開いたけど、自動的に閉じられちゃった：https://github.com/anthropics/claude-code/issues/71421 もっと良く問題を書けたかもしれない（VS Codeの代わりにCLIを比較に使うべきだった）。でも、Claudeなら1分で自分でこれを直せると確信してる。

└

これについての問題をオープンしたけど、自動的にクローズされた: […] 補足: 提出時には閉じられなかった。約17日間オープンのままで、ボットが古くなったとマークして、誰も反応しなかったから閉じられた。二段階のプロセスは最近まで知らなかった部分だね: 古くなったラベルは「これまだ関連ある？」って聞いてるようなもので、それに答えると次回はボットが引き下がる。nixpkgsも同じことをしてる。バンプするのはほとんどのトラッカーでは良くない感じがするけど、こんなに問題が多いと他に何が効果的かわからない。とにかく、コメントすれば再オープンできるはず。CLIとデスクトップのスクリーンショットは、そのトラッカーの中ではほとんどのものよりも良い再現だよ。

Hacker Newsで議論の続きを見る

ハクソク