Claude Code のコスト削減 セッションの単価と量を下げる運用
Claude Code を使い始めると、作業そのものは進むのに「いつの間にかトークンが溶けている」感覚が出てきます。ログを読ませたまま別の修正に入り、失敗した指示を訂正で積み、最後に `/compact` で片付ける。僕も最初はこの流れで運用しがちでしたが、今は 1 タスクごとにセッションを切り、設定を頭で固定するほうに寄せています。
Claude Code のコストを決めているのは「単価」と「量」の 2 つで、どちらもセッション開始時の小さな操作でかなり動きます。つまり、まだ自分の手が届く範囲に節約の余地が残っているということです。この記事では Anthropic の公式ブログを軸に、`/clear`、`/context`、`/effort`、`@` メンションまで、次のセッションから試せる形に落とします。
いつも通り動画でも解説しているので、こちらもご覧ください
コストは「単価×量」で決まる
Claude Code のコストは「単価」と「量」の掛け算です。単価側にはモデル、`effort`、thinking、プロンプトキャッシュの状態が入り、量側にはセッション長、ターン数、最初から載せている CLAUDE.md や MCP の定義が乗ります。Anthropic の公式ブログ「Maximizing the value of your Claude Code sessions」も、この分解から話を始めています。
Claude Sonnet 5 や Claude Haiku 4.5 のような軽いモデルでも実務に十分使える場面が増えていて、同じ流れで DeepSeek-V4 系の低コスト高性能モデルも出てきました。選べる単価の幅が広がったぶん、タスクに必要な推論量を先に決めておけば、毎回最大構成を選ばずに済みます。Claude Code では 1 ターンあたり入力が数万トークン、出力が数百トークンになりやすく、出力トークンは入力のおよそ 5 倍高いという非対称もあります。
ただし、表は上位モデルほど単価が高い並びで、Claude Fable 5 が Claude Opus 5 より上に来ます。単価が高いことがそのまま「日常で使わない理由」になるわけではありません (使い分けは次の節で扱います)。
この表は Anthropic のモデル概要 に基づいています。単価だけでは仕事の安さは決まりません。85 点品質の成果物を 1 つ作るまでに合計でどれだけトークンを使ったか、を僕は普段の物差しにしています。安いモデルで 20 回やり直した合計が、高めの設定で 3 回で終えた合計を超える場面もあります。
公式ブログの視点は、さらに Claude Code の内部へ寄っています。どのモデルを使うか、どれだけ長い会話を持ち回るか、何ターン続けるか、出力や thinking にどれだけ払うか。この 4 つは、どれもセッションの途中で自分の手で動かせます。
モデルと effort は最初の 30 秒で決める
まず `/model` と `/effort` を固定します。セッションを開いてすぐ打っておけば、あとから払う再読み込みを避けられる。途中で変えると次のターンでプロンプトキャッシュが壊れ、会話全体が新しい設定で再 prefill されます。Fast mode もキャッシュキーの一部なので、使うなら開始時点で固定。
`effort` は Claude の考える深さを調整する設定で、段階は `low`、`medium`、`high`、`xhigh`、`max` の 5 つ、既定は `high`。公式ドキュメントでは thinking だけでなく、ツール呼び出しを含む全トークンに効く設定として扱われています。
具体的には、日常タスクはスピード重視で、Claude Fable の `effort low` を僕は中心に置いています。単価表では一番高いモデルですが、やり直しが少なく 1 回で仕上がることが多いので、さきほどの総トークンの見方でいえば高くつきません。effort を low に絞れば、単価の高い出力側も膨らみにくい。自律的な品質改善ループや難しい設計判断だけ `xhigh` へ上げます。Claude Opus 5 は effort の段階で消費トークン数の雰囲気が大きく変わる実感があるため、最初に雑に選ぶと後半で効いてきます。
/model Claude Fable 5
/effort low設定後は `/model` と `/effort` の表示を見て、意図した組み合わせになっているかを確認します。軽い日常作業でそろえるのは、ここまでで十分。途中で設定を変えたくなったときは、その場でいじらずにいったんセッションを畳み、新しい会話で打ち直します。
定型作業まで整えるなら、skill の YAML frontmatter に effort を焼き込む方法もあります。仕事の型ごとに effort を変えたいので、僕は軽い分類や下調べを低め、品質改善ループを高めに振り分けている。`MAX_THINKING_TOKENS=0` は型が決まった決定論的な仕事で使えますが、Claude Fable 5 には効かない例外があります。
プロンプトキャッシュは触らず読ませ続ける
「さっきまで安かった会話」を自分の手で壊す、というのを僕は長いことやっていました。会話が伸びてきたので `/compact` を挟み、そのあと思いついて hooks を入れ、遅く感じたので Fast mode を後からオンにする。順番としてはどれも「良くするつもり」の操作でした。ところが、そこから先は作業量のわりにトークンだけがすぐ消えていく。同じ長さの会話なのに、設定を触る前と後で減り方が違いました。壊しているのが自分だと気づいたのは、そのあとです。
種明かしは読み出し単価にあります。通常入力を 1 と見ると、キャッシュ読み出しは 0.1 倍、5 分 TTL の書き込みは 1.25 倍、1 時間 TTL の書き込みは 2 倍。いったん書いたキャッシュを読み出し続けられるかどうかで、単価の見え方が変わります。
まず避けたいのは、モデルや effort をセッションの途中で変えることです。次ターンで会話全体の再 prefill につながりやすく、壊れ方としては一番大きい。その次に効くのが hooks や MCP の追加で、Fast mode を途中でオンにするのも同じ結果です。
Anthropic の Prompt caching docs を読むと、理屈はもっと素っ気ないことがわかります。ツール定義、system プロンプト、thinking パラメータ、effort 設定を変えると、変更した階層とそれ以降がまとめて無効になる。0.1 倍が効くのは、同じ前提を何度も読み直すあいだだけです。
5 分 TTL の API キー運用では、放置の時間も同じくらい効きます。キャッシュ寿命はリクエスト開始時点から計測され、応答生成にかかった時間もそのぶん寿命を削っていく。サブスクリプションでは 1 時間、API キーでは既定 5 分なので、API 側で長く保ちたい場合は `ENABLE_PROMPT_CACHING_1H=1` を検討する段階になります。
ただし `/compact` だけは例外です。席を離れる前に打つぶんには、キャッシュが生きているうちに要約できるので損はしません。とはいえ会話を書き換える操作なので、作業中に何度も挟むと判断材料の形まで変わってしまう。僕は使う場面を「離席前」と「長い会話の退避」の 2 つに絞り、それ以外で挟みたくなったらセッションごと切り替えています。
/context でセッションの荷物を見る
何が載っているかを見ないまま短いプロンプトだけ工夫しても、毎ターン裏側で大きな前提を送り続けていることがあります。だから量側は、新しいセッションを開いたら 1 回だけこれを打つところから始めます。
/context
出てくるのは、いまのセッションに最初から載っている CLAUDE.md、MCP、スキルの一覧です。何を削るかは、それを見てから決めればいい。
見るべきは、使っていない MCP や過剰な説明が常駐していないか。不要な MCP は `/mcp` で切ります。CLAUDE.md に長い方針を書きすぎているなら、よく使うコマンドだけ quiet フラグ付きで残すほうが、毎ターンの荷物は軽くなります。
次に効くのが `@` メンションです。読ませたいファイルが決まっているなら直接添付すると、Read 1 回ぶん、場合によっては検索ぶんも浮く計算になります。ただし同じファイルを 2 回 `@` すると 2 部目が付くので、1 会話 1 回にとどめます。
3 番目が出力の量です。コマンド出力は会話に積まれ、セッション終了まで残ります。30,000 文字を超える bash 出力はファイルに書き出されてプレビューだけが残り、`BASH_MAX_OUTPUT_LENGTH` で既定 30000、最大 150000 まで変更できる。ただ、上限を上げる前に、長いログをそのまま貼らず必要な範囲だけ読ませるほうが先です。
例外に見えて例外でないのが `/loop` で、これは 1 ターンとして会話全体を持ち回る扱いになります。だから毎回同じ大きな文脈を抱えたまま回すと、品質改善より文脈維持のほうにトークンが向かう。ループで品質を上げたい仕事は、次のサブエージェント運用へ逃がします。
セッションは細切れに切っていく
以前の僕は、同じ会話で次々に依頼を足していました。失敗した試行や古い判断が残ったまま別の作業に入ると、モデルが余計な文脈を拾いやすくなります。今は目的を達成した時点で会話を畳む運用で、`/clear` も使いますが、中心は Ctrl+C 2 回でセッションそのものを落とすほうです。
一方で公式のセッション管理ブログでは、続ける、`/rewind`、`/clear`、`/compact`、サブエージェントの 5 択を状況で使い分ける形になっています。長く続けた会話が常に強いわけではないのは、context rot、つまりコンテキストを使うこと自体が性能に影響する問題が出るからです。
まず試すのは `/rewind` です。変な方向に進んだ直後は、訂正メッセージを積むより会話の末尾を切り落とすほうが早く戻れます。この操作にコストはかかりません。Esc を 2 回押す操作でも戻れるので、説明して直す前に後ろを切る判断を挟みます。
日常の修正や調査は、会話を細切れにしておくほうが次に何をするか迷わずに済みます。`/compact` を選ぶのは、長い作業をどうしても続けるときか、席を離れる前に要約しておくときだけ。公式ブログでも `/rename` で名前を付けてから `/clear` する運用が紹介されています。
v2.1.221 以降なら、`/autocompact 200k` で自動コンパクトのセーフティネットを戻せます。切り忘れたまま会話が伸びたときの保険にはなりますが、新しいタスクはやはり新しいセッションで始めます。
今日からの判断は単純で十分です。順調なら続ける、直前の失敗なら `/rewind`、席を離れるなら `/compact`、1 タスク終わったら `/clear` か Ctrl+C 2 回。調査やログ読みのように出力が大きい仕事は、次のサブエージェントに回します。
大きい仕事はサブエージェントへ
サブエージェントは自分のコンテキスト、システムプロンプト、ツール、CLAUDE.md を持ち、親の会話は渡されません。だからログ調査や検索など、出力は大きいけれど手元の会話に全部残す必要のない仕事とかみ合います。
10 ファイル以上を探索する、独立した仕事が 3 つ以上ある。公式の目安では、このあたりからサブエージェントの立ち上げコストを回収しやすくなります。逆に、依存のある逐次作業、同一ファイルの同時編集、小さな修正では、親が読んだファイルを読み直すオーバーヘッドが勝ちます。
会話全体を抱えたまま反復すると、良い判断材料と古い迷いが一緒に残ります。品質改善ループをメインセッションで回さず外へ出しているのは、この理由からです。定型仕事ならサブエージェント定義側で `model: haiku` や `model: sonnet` を指定し、安い反復と重い判断を分けます。
最後に、Anthropic が示す優先順位は次の並びです。
モデル選択をタスクに合わせる
コンテキスト長を `/context` で点検する
ターン数を `/rewind` やセッション分割で減らす
出力トークンと thinking を effort で調整する
上から順に見ると、細かい節約に寄りすぎません。Claude Code のトークン効率は、使う量をただ減らすことではなく、使ったトークンが頼んだ仕事に向かうようにすることです。
コスト管理は、セッションを開いた最初の 30 秒でだいたい決まります。僕は Fable の `effort low`、`/context` の点検、Ctrl+C 2 回の細切れ運用をセットで使うようになってから、セッションを育てるか切るかの迷いが減りました。
もっと深掘りしたい方へ
メンバーシップでは、実際に手を動かしたログをもとに Claude Code や Codex の運用メモを続けています。ハーネスエンジニアリングの探索、AI エージェントの設計判断、勉強会や Discord での共有まで、本文と同じ温度で整理。興味があれば メンバーシップを見る から確認してください。
Claude Code の運用や AI ツールの実践メモを続けて読みたい場合は、まさおをフォロー しておくと追いやすくなります。この記事が役に立ったら、同じ悩みを持っている人にシェアしてもらえるとうれしいです。
