2026年6月15日に Claude Code の課金が分離し、claude -p・CI・SDK のようなプログラムからの自動の起動の分が、購読の枠とは別の従量の枠で課金される予定でしたが、施行当日に一時停止されました(再実施に備えます)。対話だけで使っている人には、この変更は当てはまりません。
「自分が対象かどうか」を確かめる記事は、もう各所に出ています(claude -p や cron を grep する、対話だけなら影響なし、という確認です)。対象かどうかが分かったら、次に効くのは「対象だとして、月にいくら増えるのか」という金額の問いですが、そこを自分のログの実数で出す手順はまだ見当たりません。この記事は、その先を埋めます。請求が来てから慌てる前に、推測でなく自分のログの実数で、5分で自分の数字を出してください。
影響額 M とは
対応の道は、ひとつの数字で分かれます。その数字を M と呼びます。意味は「自分の今の利用量を、標準の API 料金(米ドル)に換算した月額」です。
- M が今の plan の月の枠を下回るなら、今日の変更の影響はほぼ0。何もしなくて大丈夫です。
- 枠の**100〜150%**なら、軽い手当てで枠の中に戻せます。
- **150〜300%**なら、構造の判断が要ります。
- 300%超なら、問いは「どう枠に収めるか」でなく「続けるか」に変わります。
自分の JSONL ログから M を出す
Claude Code は各セッションの記録を ~/.claude/projects/<エンコードされた作業ディレクトリ>/<session-id>.jsonl に残します。各行の message.usage に、その呼び出しの入力・出力・キャッシュの読み書きのトークン数が入っています。これを集計して公開料金を当てれば、API 換算の費用が出ます。
import json, glob, os, datetime
# Opus の公開料金($ / 100万トークン)。入力5 / 出力25 / キャッシュ読み0.5(入力の0.1倍)/ キャッシュ書き6.25(1.25倍)
RATES = {"input": 5.0, "output": 25.0, "cache_read": 0.5, "cache_creation": 6.25}
KEYS = {
"input": "input_tokens", "output": "output_tokens",
"cache_read": "cache_read_input_tokens", "cache_creation": "cache_creation_input_tokens",
}
cutoff = datetime.datetime.now(datetime.timezone.utc) - datetime.timedelta(days=30)
tot = {k: 0 for k in RATES}
for path in glob.glob(os.path.expanduser("~/.claude/projects/*/*.jsonl")):
for line in open(path, encoding="utf-8"):
try:
d = json.loads(line)
except Exception:
continue
ts = d.get("timestamp")
if ts:
try:
if datetime.datetime.fromisoformat(ts.replace("Z", "+00:00")) < cutoff:
continue
except Exception:
pass
u = (d.get("message") or {}).get("usage") if isinstance(d.get("message"), dict) else None
if not u:
continue
for k, src in KEYS.items():
tot[k] += u.get(src, 0)
m = sum(tot[k] * RATES[k] for k in RATES) / 1_000_000
print("直近30日のトークン:", {k: f"{v:,}" for k, v in tot.items()})
print(f"M(直近30日の API 換算)= ${m:,.2f}")
実際に自分の環境で走らせると、消費の大半が cache_read(毎回の文脈の再送)であることが分かるはずです。私の長いセッションの1本では、cache_read だけで1億6千万トークンを超え、その1本で100ドル相当を超えていました。M を決めるのはコードの行数でなく、文脈のサイズ×ターン数です。これが「軽い作業のはずなのに枠が尽きる」の正体です。
ここが大事——対話とプログラムを分ける
6月15日の変更が課金するのは、プログラムから起動した分(claude -p・CI・SDK)だけです。上のスクリプトは全部のセッションを足すので、対話の分も混ざります。自分の M のうち「プログラムから起動した分」がどれだけかを分けないと、影響を過大に見積もります。
各行には起動の種類を示す欄(entrypoint など)が入っていることがあり、対話と非対話を切り分ける手がかりになります。ただし、対話のセッションの中で起きたサブエージェントや hook や MCP の呼び出しが、どちらの枠に属するかは、提供側がまだ明示していない曖昧な部分です。だから、ここは実機のログで確かめられる範囲(プログラムから起動したセッションの分)を下限として見て、断定はしないのが安全です。
M を出した後の4つの道
M を出して、プログラムの分が自分の枠を超えると分かった人のために、4つの独立した対応の道があります。
- 対話への畳み込み(自動の分を対話の枠に寄せる)
-
claude -pの最適化(消費を減らす。cache_readが支配的なので、文脈を小さく保つのが最大のレバー) - API への移行(自動の分を従量に分離する。ただし
ANTHROPIC_API_KEYを全体に設定すると対話まで従量になる罠に注意) - 混在(用途で分ける)
それぞれの費用と制限と手順、残り日数別の作業の時系列を、¥800の手引き「Claude Code の6月15日の課金分離に備える」にまとめています。第1章(M の出し方)と第2章(5分の棚卸し)は無料で読めます。 まず無料の自己診断だけ試して、「影響なし」と分かれば本は要りません。
自動の運用に費用の上限や安全装置を足したい人は、800件以上の無料の hook を集めた cc-safe-setup も置いています。
まず、自分のトークン消費がどこで膨らんでいるかは、無料のトークン消費チェックアップで30秒あたりをつけられます。無料で自分の浪費を確かめてから、下の本で全手順を読むのが早いです。
6月15日の課金の変更とは別に、普段のトークンの消費そのものを構造立てて減らしたい人には、Claude Codeのトークン費用を減らす運用ガイド（Zenn Book、¥2,500）を用意しています。モデルの使い分け・文脈の圧縮・無駄な再読の削減を26章で整理した、課金分離の後も効く恒常的な費用対策です。
よくある質問。
Q. 対話でしか使っていません。影響はありますか?
A. ほぼありません。上のスクリプトの M が小さい、または自動起動のセッションが無ければ、何もしなくて大丈夫です。
Q. なぜ cache_read がこんなに大きいのですか?
A. Claude Code は毎ターン、それまでの文脈をまとめて送り直します。その大半はキャッシュから読まれ(入力の0.1倍の料金)、それでも積み上がると支配的になります。減らす最大のレバーは /clear と、文脈を小さく保つことです。
800時間の Claude Code 運用データから、トークン消費の削減・複数ベンダー(Claude / Codex / Gemini / Copilot)の並行運用・事故の検知と復旧・サブエージェントの沈黙の失敗対策など、主題別の手引きを公開しています。気になる人は著者の本の一覧から、価格と評価を見て選べます。