Claude Code と Codex の長い session で token の無駄を減らす方法

まず結論

Claude Code や Codex の session が長くなるほど遅くなり、扱いづらくなり、API 課金の workflow ではコストまで膨らむなら、見直すべきなのは「もっと良い prompt」ではなく workflow の形そのものだ。

2026-04-17 に、NVIDIA の Dynamo チームは agentic inference に関する詳細な記事を公開し、その中で Claude Code と Codex 風の session を具体例として使った。ポイントは実務的だ。長い coding session は write-once, read-many system のように振る舞う。高コストなのは、system instructions、tool definitions、repo rules、そして task の中で複数 turn にわたって変わらない部分から成る安定した prefix である。そこを毎回書き換えれば再計算が増え、安定させれば再利用しやすくなる。

prompt caching をサポートする API を使っているなら、その再利用は repeated-input spend の削減にもつながる。ただし「文面がだいたい同じ」だけでは足りない。Anthropic の prompt-caching docs では、cacheable content block と明示的な cache breakpoint が必要で、しかも cache point は後続 request でも同一のまま残る内容の後ろに置く必要がある。OpenAI の prompt-caching guide も、再利用は exact prefix match に依存し、prompt が少なくとも 1,024 tokens に達してから始まると説明している。Claude Code や Codex desktop のような bundled product を使う場合は、まずは billing savings の保証ではなく、latency と context hygiene の改善として捉えるのが安全だ。

最も無難な default はシンプルである。

• 1 つの session には 1 つの objective だけを持たせる
• 安定した instruction は小さく再利用できる prefix に寄せる
• parallel work は branch が本当に独立している時だけにする
• thread が transcript dump になる前に milestone を file に要約する
• 現在の turn に不要な tool や file はぶら下げない

長い Session は問題を増幅する

この話題が今重要なのは、単に「agents が流行っているから」ではなく、2026-04-17 に具体的な trigger が出たからだ。

NVIDIA の公式記事によれば、coding-agent session は巨大な shared prefix を維持したまま数百回の API call を行うことがある。公開された例では、Claude Code 風 session の後半 turn は初回 write のあと cache reuse が 85% から 97% に達し、4-agent team では aggregate cache hit rate 97.2%、read-to-write ratio 11.7x だった。これは infrastructure 層の数字であって、すべての hosted product 体験を約束するものではない。それでも、長い session が「同じ context の繰り返し再利用」に強く支配されることはよく分かる。

API 課金 workflow では、pricing もこの差を大きくする。

2026-04-20 時点で、Anthropic の prompt-caching docs は default cache lifetime を 5 minutes と説明している。Anthropic の pricing page では Sonnet 4.6 は input $3 / MTok、5 分 cache write $3.75 / MTok、cache read $0.30 / MTok。OpenAI の API pricing page では GPT-5.4 は input $2.50 / 1M、cached input $0.25 / 1M、GPT-5.4 mini は input $0.75 / 1M、cached input $0.075 / 1M となっている。bundled product を使っていて raw API billing ではない場合、これらの数字は直接の請求額ではなく、reuse economics と latency behavior の証拠として読むべきだ。

Coding Agent で Token Waste を生むもの

token waste の多くは、1 回の bad answer から来るわけではない。問題は、model に変動の大きい context を何度も読み直させることだ。

よくある原因は次の通り。

パターン	起きること	より良い手
1 つの chat に無関係な job を詰め込む	prefix が伸びる一方で、現在の turn に本当に関係ある部分は減る	objective が変わったら新しい session を始める
repo rule を毎回説明し直す	安定 instruction が毎回書き換えられたり言い換えられたりする	repo rule は小さな file にまとめ、agent にはそれを参照させる
loosely related な作業で subagent を乱立させる	各 branch が cold start し、setup context を重複して運ぶ	output を独立に review できる時だけ split する
file や log を丸ごと chat に貼る	もう不要な detail を thread がずっと背負い続ける	note、diff、issue comment に要約する
多数の tool を scope に残したままにする	tool schema や permission surface が context と複雑さを増やす	現在の task に必要な tool だけを残す

Tip 1: Stable Instruction は Chat Chatter ではなく Prefix に置く

多くの turn をまたいで生き残る rule は、会話の往復の中ではなく外に置くべきだ。

Anthropic の prompt-caching docs は、cached prompt structure を後続 turn の前にある stable prefix として捉えている点で参考になる。Anthropic の Claude Code memory docs も同じ考え方を workflow レベルに持ち込んでおり、durable な project rule は毎回 chat に書くのではなく CLAUDE.md に置くよう勧めている。

API を直接使うなら、ここはさらに具体化した方がいい。Anthropic の docs では、cache hit は breakpoint をどこに置くか、そして reusable prefix が model の minimum cacheable length を満たすだけ十分に長いかに依存する。OpenAI の docs では、reusable part は prompt の先頭から exact に一致しなければならず、意味が近いだけでは足りない。「だいたい同じ」は「cacheable」と同義ではない。

実際にこれらの product の中で作業するなら、product-native な session control も使うべきだ。2026-04-20 時点で、Anthropic の Claude Code commands docs には current conversation を圧縮する /compact と、history を消して fresh start する /clear が載っている。OpenAI の Introducing the Codex app では、Codex agent は project ごとに整理された separate thread で動き、app には built-in worktrees があると説明されている。実務的にはこういう意味だ。

• Claude Code では、objective は同じだが transcript が膨らみすぎた時は /compact を使い、history が完全に dead context になった時は /clear を使う
• Codex では、新しい thread を優先し、code path まで分岐したなら fresh worktree も切る。無関係な作業を 1 つの長い session に押し込まない

stable prefix に寄せやすいものは次のような内容である。

• repo conventions
• coding style rules
• test commands
• review checklist
• approval boundaries
• task 全体を通して relevant な product docs や API docs への link

Claude Code なら、これはたいてい CLAUDE.md のようなコンパクトな project instruction file や repo docs を意味する。Codex なら、小さく保った task brief と、毎回貼り直すのではなく file に置いた project note を意味する。

悪い例：

Use TypeScript. Also keep accessibility in mind. Also do not change analytics. Also prefer server components. Also keep changes small. Also run the same test command as before.

より良い例：

Use the repo rules in AGENTS.md.
Task: fix the mobile checkout validation error without changing analytics or auth flows.
Stop after code changes plus the exact verification commands.

見た目は小さな変更だが、本質は大きい。stable instruction が、増え続ける paraphrase ではなく reusable prefix になるからだ。

Tip 2: 1 Session には 1 Objective

coding thread には 1 本の finish line が必要だ。

良い session boundary：

• 1 つの bug
• 1 つの subsystem の中だけで閉じる refactor
• 1 回の PR review pass
• 1 回の setup または migration task
• 1 つの verification path を持つ documentation change

悪い session boundary：

• "clean up the repo while you are here"
• "also update docs and fix CI and compare pricing and review this PR"
• "keep this chat as my general coding workspace for the week"

使いやすい reset rule はこうだ。

• acceptance test が変わったら、新しい session を始める
• main directory が変わったら、おそらく新しい session にした方がよい
• 新しい task を聞く前に old context を説明し直さないといけないなら、確実に session を分けるべきだ

ここで worktree も効いてくる。新しい worktree は新しい branch、小さな diff、そして fresh agent session を開く自然な場所を与えてくれる。

git worktree add ../repo-fix-checkout -b fix-checkout-validation
cd ../repo-fix-checkout

Tip 3: Parallel Agent は独立 Branch にだけ使う

NVIDIA の 2026-04-17 post が useful なのは、lead agent と subagent を分けている点だ。すべての parallelism が無料だとは言っていない。

parallel work が効くのは、各 branch が狭い質問に答えられる時だ。例えば：

• 1 つの failing test を trace する
• 1 つの dependency upgrade を inspect する
• 1 つの folder の dead code を review する
• 2 つの implementation option を compare する

逆に、各 branch が repo 全体の背景と full conversation history を必要とするなら、parallelism はむしろ足を引っ張る。

API ユーザー向けには、ここにも cache timing caveat がある。Anthropic の prompt-caching docs は、cache entry は最初の response が始まってからでないと他の request で使えないと説明している。OpenAI の prompt-caching guide も、同じ prompt prefix を持つ request が一斉に到着すると cache routing により効率が落ちうると説明している。shared prefix を効かせたいなら、まず 1 本の lead request でそれを確立し、その後で narrower branch に fan out する方が安全だ。

もう 1 つ agent を起こす前に、次の quick rule を使える。

• If the subtask can end with a small memo, diff, or yes/no recommendation, spawn it.
• If the subtask needs the full evolving plan, keep it in the main thread.

conversation 全体を転送するより、短い delegation prompt の方が効きやすい。

Check only `src/payments/` for why the checkout form sends duplicate validation events.
Do not edit files.
Return:
1. likely root cause,
2. exact files involved,
3. whether the fix is low, medium, or high risk.

これなら独立性を保てるし、各 branch が抱える context 量も抑えられる。

Tip 4: Thread が Log Archive になる前に Milestone を要約する

長い coding chat が劣化するのは、古い exploration が間違っていたからではなく、それがいつまでも active context に残り続けるからだ。

より良いパターンは、一時的な reasoning を milestone ごとに durable な note へ変換することだ。例えば：

• repo exploration の後
• root cause identification の後
• chosen fix の後
• verification の後
• 別の agent や人間へ handoff する前

summary は短く、file-backed であるほどよい。

checkpoint note の例：

## Checkout validation checkpoint
- Root cause: `useCheckoutValidation` fires both on blur and on submit for the same empty state.
- Files: `src/features/checkout/useCheckoutValidation.ts`, `src/features/checkout/CheckoutForm.tsx`
- Safe fix path: dedupe submit-time emission when blur already marked the same field invalid.
- Verify with: `bun test src/features/checkout` and manual mobile checkout flow.

次の turn を気にすべき事実へ再アンカーできるので、60 turn 分の exploration をそのまま引きずるよりずっと良い。

Tip 5: 長い Session では Tool Scope を狭く保つ

tool、connector、permission surface が増えるほど、無関係な context、長い tool definition、pause 後の recovery コストも増える。

2026-04-16 時点で、OpenAI の Codex update post は、browser actions、plugins、memory、multiple terminals、review-comment handling、automations まで product surface が広がっていることを示している。便利ではあるが、そのぶん「active surface area が広すぎる session」を作りやすくもなる。

安全で効果的な default は地味だ。

• 現在の task に必要な tool だけを有効にする
• browser や desktop control は本当に必要な step の時だけ使う
• docs、logs、screenshots を "just in case" で抱え込まない
• long-lived memory には volatile な project state ではなく stable preference を入れる

Claude 側の workflow でも考え方は同じだ。安定して残る部分だけを cache し、temporary debris で live thread を埋めないこと。

たいてい Waste を減らせる Simple Session Template

non-trivial な coding task を始める時は、次の template が使いやすい。

You are helping with one bounded coding task.
Goal: fix [specific problem].
Scope: only [files, folders, or subsystem].
Constraints: follow repo rules in [file]; do not change [out-of-scope areas].
Tools: use only what is needed for this task.
Process:
1. inspect,
2. propose the smallest fix,
3. apply it,
4. run the exact verification commands,
5. stop.
Return a short checkpoint summary before any optional follow-up work.

この template が効くのは、prefix を安定させ、同時に session に stop line を与えるからだ。

これらの Tips を無視して Fresh Start すべき時

現在の thread を最適化するより、最初からやり直した方がよい場面もある。

• agent が何 turn も task を取り違えたまま進んでいる
• 採用した plan 自体が変わった
• 関連する repo area が完全に変わった
• thread が dead context でいっぱいになった
• 既存 session より clean な review record が必要になった

多くの場合、膨らみきった thread を救うより fresh session の方が楽で安い。

FAQ

token 課金の時だけ気にすればいい？

いいえ。billing signal が最も分かりやすいのは API pricing だが、同じ reuse pattern は bundled product の中でも latency や session quality の改善として現れうる。

prompt caching があるなら巨大 thread をずっと維持していい？

いいえ。Anthropic の docs は prompt caching を prefix reuse と説明しているのであって、無関係な context を延々足していいという意味ではない。relevance は依然として重要だ。

subagent は常に使った方が速い？

いいえ。branch を narrow に保てて、bounded な result を返せる時だけ有効だ。そうでなければ cold start と review work を増やすだけになりやすい。

summary file は本当に chat history より良い？

たいていは yes だ。短い file-backed checkpoint は、次の turn を今も重要な事実へ戻してくれる。一方 full transcript は、不要になったものまで全部 carry し続ける。

検証メモ

検証日：2026-04-20。

確認した公式ソース：

• NVIDIA: Full-Stack Optimizations for Agentic Inference with NVIDIA Dynamo：2026-04-17 の公開日、cache reuse の例、multi-agent read-to-write ratio の確認用。
• Anthropic Prompt Caching、Anthropic Claude Code Memory、Anthropic Claude Code Commands、Anthropic Pricing：default cache lifetime、cache breakpoint、concurrency behavior、CLAUDE.md memory guidance、/compact、/clear、Sonnet 4.6 の cache pricing の確認用。
• OpenAI Prompt Caching、OpenAI API Pricing：exact-prefix matching、minimum cacheable length、cache-routing caveat、GPT-5.4 / GPT-5.4 mini の cached-input pricing の確認用。
• OpenAI: Introducing the Codex app：Codex thread が project ごとに整理されること、built-in worktrees、session-history continuity の確認用。
• OpenAI: Codex for almost everything：Tip 5 で触れている 2026-04-16 時点の Codex desktop feature surface の確認用。