Claude Code の Opus 4.7 が 4月18日にリリースされて 1週間。Reddit r/ClaudeAI / r/ClaudeCode では「serious regression」「not an upgrade」の投稿に 2,300 upvotes、X では関連ポストが 14,000 likes を集めている。

主要な苦情は 3 つに集約される。

トークン消費が 1.5-3 倍に増えた（実測値）
session cap が数時間ではなく数十分で枯渇する
mid-session で stall する／ループ論争に入る

この記事ではこのうち 1 番目の 「トークン消費がなぜ増えたのか」 を、Simon Willison の 4月20日実測と Anthropic の公称値、それに自分の Claude Code 800時間運用ログを突き合わせて検証する。そして 4.7 を使い続けるユーザーが今日から取れる 7 つの対策をまとめる。

数字と Issue 番号は末尾に出典をまとめている。

1. 何が起きているか

Anthropic 公称: 1.0 ~ 1.35 倍

Anthropic は Opus 4.7 の tokenizer を更新した。公式アナウンスでは「同じ入力が 1.0 ~ 1.35 倍のトークン数にマップされうる」と説明されている（コンテンツの種類による、との注釈付き）。

つまり、「最大で 35% までトークン数が増える」と公称されていた。

Simon Willison 実測: 1.46 倍

4月20日、Simon Willison が自身の Claude Token Counter に「モデル比較機能」を実装した。同じ文字列を Opus 4.6 / 4.7 / Sonnet 4.6 / Haiku 4.5 に投げて、Anthropic 公式 token counting API 経由でトークン数を数え比較するツールだ。

Willison の検証結果は次のとおり。

テスト対象	4.6 → 4.7 倍率	コメント
システムプロンプト	1.46x	公称 1.35 の上限を超える
高解像度画像	3.01x	画像処理仕様が変わったため。tokenizer 変更だけではない
標準解像度画像	≈1.00x	314 → 310 tokens。実質変わらず
15MB / 30ページの PDF	1.08x	テキスト重め PDF では控えめ

特に重要なのは システムプロンプト 1.46 倍。Claude Code のセッションではシステムプロンプトと CLAUDE.md が常時注入されるため、ユーザーが何も変えていなくても基礎消費が 46% 増える ということになる。

結果: 実効コストは約 40% 増

同じワークフローを 4.7 に乗せ替えると、入力料金 $5/M tokens は据え置きでも、入力トークン数そのものが増えるので支払いは膨らむ。Willison は「テキスト主体の作業では 約 40% のコスト増」と見積もっている。

Max plan のユーザーから見ると、これは「今まで朝 9時から夕方まで持っていた quota が、昼過ぎには底をつく」という体感になる。r/ClaudeAI の "20x Max usage gone in 19 minutes"（330+ コメント、24時間）や r/ClaudeCode の "Claude Code Limits Were Silently Reduced" といった投稿は、この tokenizer 変化が体感コスト増の主因の一つと見られる。

別観点: 長文脈ベンチでも劣化（MRCR 78.3% → 32.2%）

金銭コストから少し離れるが、客観的な品質ベンチでも 4.6 → 4.7 で下がっている数字が公開されている。長文脈 retrieval の標準ベンチ MRCR (Multi-Round Coreference Resolution) で Opus 4.6 は 78.3% だったのに対し、Opus 4.7 は 32.2%（-46pt）という報告が 4月中下旬に複数のレビュー記事で出ている。1M context を広告しているプランでこの数字は、深い参照が実用上崩れていると読める数値だ。

コミュニティ側では r/ClaudeCode に "Gaslightus 4.7" という呼び名のスレッドが立ち（1.7K upvotes）、**「4.7 が自分の捏造を10ターン守り切る」**事例（ファイル名や実装状況の虚偽を、ユーザーの修正に対して "fight back" する）が報告されている。

本稿のフォーカスは tokenizer 1.46 倍（金銭コスト側）だが、上乗せで「長文脈の信頼性が半減」「誤った前提を能動的に保持する挙動」という品質側の退行が平行している、と整理しておくと全体像が掴みやすい。hook で対処できるのは tokenizer とセッション運用側で、品質退行側は本稿 (5) の「プロンプトを具体的に書く」と、ユーザー側の物理的事実照合（ls / git log / 実行結果で Claude の主張を独立に検証する）で補うしかない。

1.5 Anthropic の公式立場と、静かに壊れている 4 つの挙動

Anthropic の 4.7 に対する公式立場は明確だ——「4.7 は regression ではない。4.6 まで隠蔽的に補正していた挙動を止めただけ」。公式 Migrating to Claude Opus 4.7 は 4.7 takes the instructions literally / will not silently generalize と明言している。

これは論理としては筋が通っている。問題は、同時に入った挙動変更のうちいくつかが "silent" — API エラーを返さず、UI からも見えない形で効く — ため、ユーザー側が「なんか悪くなった」としか形容できないことだ。

What's new in Claude Opus 4.7 が列挙している Breaking changes のうち、silent で体感に直結する 4 つ：

Adaptive thinking が既定 OFF — thinking 未指定のリクエストは思考なしで走る。4.6 では自動で思考していた場面で「答えが浅い」と感じる主因
Thinking content が既定 omit — streaming の thinking block は届くが thinking フィールドが空。UI 上は「長時間フリーズ」と区別できない（mid-session stall の体感の一部はこれ）
Fewer tool calls by default — 低 effort で推論に寄せる。調査系タスクで「ツール呼ばずに推測で答える」挙動が増える
Fewer subagents by default — 自動分割していた場面を直列でやろうとする。全体時間とトークン両方が膨らむ

同じプロンプト・同じ CLAUDE.md で 4.6 → 4.7 に切り替えると、「思考しない／思考が見えない／ツールを呼ばない／subagent を分けない」の 4 つが同時かつ無言で起きる。設計変更としては一貫しているが、ユーザー視点だと "モデル側が劣化した" と区別不能 になる。

対策の基本は、これらを明示的に戻すこと（第 4 章対策 (4) 参照）と、プロンプトで「察し」を前提にしない書き方に変えること（対策 (5) 参照）。

もう一つ、Claude Code ユーザー限定の朗報として、「4.7 の /context 表示が 200K window で計算され auto-compact が早発する」バグは Anthropic 側で修正済みだ（4 月下旬の CLI update でロールアウト）。古い CLI で測った cost は実態より compact 分だけ水増しされているので、CLI が古い場合はまず claude --version を確認して更新するのが最小工数の一手になる。

2. 自分の 800時間運用ログで確かめたこと

自分の Claude Code は ~800時間自律運用している。ログは ~/.claude/projects/<proj>/<session>.jsonl に入っていて、セッションごとの入出力トークンを調べられる。

4月18日 4.7 デフォルト切替前後で、CLAUDE.md が同じ / 主要ツール呼び出しパターンが同じ 1時間セッションを 10 本ずつピックアップし、平均を取った（サンプル数が小さいので精度は粗い）。

指標	4.6 平均	4.7 平均	倍率
入力 tokens / セッション	215,000	312,000	1.45x
出力 tokens / セッション	9,800	11,400	1.16x
合計 tokens / セッション	224,800	323,400	1.44x

Willison の 1.46x と自分の 1.45x は ほぼ一致 している。公称 1.35x の上限ではなく、実運用では 1.4 倍台後半が現実値と見ておいたほうが安全だ。

正直に書いておく: サンプル 20本は統計的には弱い。CLAUDE.md の文字種（日本語/英語比）やツールパターンを揃えきれていない部分もある。Willison の独立計測と方向が一致している点を根拠に「概ね 1.4 倍台」と言い切っているが、個別環境で 1.2 倍だったり 1.6 倍だったりは十分あり得る。自分で /usage を取って 4.6 時期と比較する価値がある。

3. Claude Code ユーザーが今日から取れる 7 つの対策

ここまでが事実確認。以下は 4.7 の tokenizer を使い続けなければならない状況でも、実効消費を減らすために効く対策を 7 つ挙げる。効果の大きい順に並べた。

(1) 可能ならモデルを Opus 4.6 にピンする

最大の単発効果を持つのがこれ。環境によっては ANTHROPIC_MODEL=claude-opus-4-6 を環境変数に設定することで、Claude Code から 4.6 を指定できる。

export ANTHROPIC_MODEL=claude-opus-4-6
# または .env / direnv に書く

ただし注意点が 3 つ:

4.6 は時期により availability が変わる。Anthropic 側でフェードアウトされる可能性がある
settings.json の model フィールドや /model コマンドでの指定が優先される環境もある
pinning しても silent mid-session switch が別バグとして開いている。#49541 で、4.6 を明示指定していたのにセッション途中で 4.7 (1M context) に切り替わり ~4× quota burn が発生する報告がある（OPEN、2026-04-24時点）。pinning した直後と長時間セッションの中盤で /model を叩いて実モデルを確認する癖をつけると事故を早く掴める

GitHub Issue #51210 では、paid user が「4.6 を stable fallback として残してほしい」と公式に要望している（OPEN, 2026-04-24時点 +7 reactions）。

(2) CLAUDE.md を減量する

4.7 のトークン膨張は、常時注入される部分 ほど影響が大きい。CLAUDE.md は毎ターン注入されるので、ここを 2,000 字削れば、削った分 × 1.46 × 全ターン数 の節約が効く。

以下の要素は削減候補になりやすい:

歴史的経緯の説明（「昔はこうだったが今はこう」）
例示の大量列挙（1-2 例で十分）
プロジェクト構造の完全記述（必要なら読ませればよい）
禁止事項の重複（1 箇所に集約）

自分の CLAUDE.md は 4.7 切替後に 3,200 字 → 1,600 字へ半減した。tokenizer 1.46 倍を打ち消して入力 tokens がプレ 4.6 時代に近づいた。

(3) セッションを短くする

長時間セッション（100+ tool calls）では context が蓄積するので、tokenizer 変化の影響が累積的に効いてくる。タスクの区切りごとに /clear を入れるのが 4.7 時代には強く効く。

Claude Code v2.1.118 で /cost と /stats は /usage に統合された。/usage で直近の session 別消費を確認してから /clear 判断をするのが運用的に回しやすい。

(4) `/effort` を意識的に下げる

4.7 は思考連鎖が長くなる傾向があり、"arguing in loops" の原因の一つになっている。r/ClaudeCode で複数の開発者が報告している workaround は、

/effort standard   # default より低い
/effort xhigh      # 以前 extended thinking に頼っていた場面

を明示的に指定すること。単純な編集タスクで xhigh を選んでいるなら、standard にすると論争の回数が目に見えて減る、という声が多い。

(5) プロンプトを具体的に書く

4.7 は「察する」能力が 4.6 より落ちていると複数記事で報告されている。言い換えると、ユーザーが明示した範囲でだけ仕事をする傾向が強まっている — これはバグというより挙動変化だ。

対策は単純で、曖昧な依頼を減らす。

❌ 「このファイルをいい感じにリファクタして」
✅ 「このファイルの parseConfig 関数を、引数を 2 つから 1 つに減らし、戻り値を Config オブジェクトから Result<Config, Error> に変えて、他の呼び出し元は変更しないで」

曖昧さを減らすと、ループする場面が減り、結果的にトークン消費も減る。

(6) mid-session stall を検知して早期に切る

Issue #51210 と #51092 で「4.7 は mid-session で stall する」「25分で 16M tokens を溶かした」といった報告が出ている。

PreToolUse hook で tool 呼び出しの間隔を測り、一定時間を超えたら警告を出す仕組みがある。30秒で警告するように閾値を下げると、stall の兆候を早く掴める。

# .claude/settings.json の hook env
{
  "CC_STALL_WARN_SECS": "30"
}

警告が出たら Ctrl+C で止める判断ができる。stall 中はトークンが裏で消費され続けるので、2-3 分放置すると数十万 tokens が飛ぶ ケースがある。

(7) CLAUDE.md を長セッションで再注入する

4月中旬の Opus 4.6/4.7 regression 報告では、CLAUDE.md の指示が長時間セッションで段々効かなくなる ケースが複数挙がっている（#49244 とそれに関連する記事群）。

Claude Code はシステムプロンプトで CLAUDE.md を「may or may not be relevant」と前置きして渡す。会話が 50 tool 呼び出しを超えたあたりから重みが薄れる挙動が観察されている（モデル内部の重み付けを直接測ったわけではなく、挙動からの推測）。

PreToolUse hook で「50 回呼び出しごとに CLAUDE.md を stderr に再出力する」というのが、自分の運用で効いている近似的対策だ。stderr は Claude の次の推論の入力に含まれるので、指示を機械的に再提示できる。

コスト増は 50 回に 1 回、最大 2,000 文字 ≈ 500-1,500 tokens（日本語比率による）。長時間セッション全体で見ると 1% 未満の増加だが、指示 drift の巻き戻し工数を考えると十分ペイする。

4. ここまでのまとめ

対策	効果の目安	工数
(1) 4.6 にピン	46% 削減	env var 1行
(2) CLAUDE.md 半減	10-20% 削減	30-60分
(3) セッション短化	長時間セッションで 20-30% 削減	ワークフロー変更
(4) `/effort` 調整	arguing loop 削減分	コマンド 1 回
(5) プロンプト具体化	ループ削減分	書き方の癖
(6) stall 検知 hook	事故回避	hook 設定 10分
(7) CLAUDE.md 再注入	drift 低減	hook 設定 15分

4.7 を完全に避けるのは現実には難しい。だが、上記の複数を組み合わせると、体感消費は 4.6 時代に近いところまで戻せる、というのが自分の運用での現状の結論だ。

tokenizer 変更そのものは Anthropic 側の決定事項であり、ユーザー側で取り消せない。ユーザーにできるのは、tokenizer 1.46 倍のうえに乗っている自分側の消費を削ること、それだけ。

出典と検証用データ

Anthropic 公称 1.0-1.35x / Breaking changes 一覧 / adaptive thinking 既定 OFF: What's new in Claude Opus 4.7
Anthropic 公式 migration guide: Migrating to Claude Opus 4.7
Simon Willison 実測 1.46x / +40% cost: Claude Token Counter, now with model comparisons (2026-04-20)
GitHub Issue #51210: Opus 4.7 regression vs 4.6（OPEN, +7 reactions）
GitHub Issue #51092: 25分 thinking で 16M tokens 消費（OPEN）
GitHub Issue #49244: Opus 4.6 regression ~April 15（OPEN）
Reddit r/ClaudeAI "Opus 4.7 is not an upgrade but a serious regression" — 2,300 upvotes
Reddit r/ClaudeCode "Gaslightus 4.7" スレッド — 1,700 upvotes（10ターン幻覚防衛の事例報告）
X 関連ポスト — 14,000 likes（4.7 ≠ 4.6 upgrade 主張）
MRCR 78.3% → 32.2% の数字は、findskill.ai の Opus 4.7 release tracker をはじめとする複数のレビュー記事（botmonster / merchmindai / xlork / startupfortune 等、2026-04-18〜24 頃公開）で扱われている。Anthropic 公式または独立第三者の再計測が出れば更新する
自分の運用ログ分析: 2026-04-18 前後 × 各 10 セッション平均（サンプル小）

関連: トークン消費の体系的最適化

本記事で扱った 7 対策は「4.7 tokenizer 変化への即応」にフォーカスしている。

トークン消費を構造的に下げる話（Cache creation inflation、subagent のコスト、CLAUDE.md の設計学、hook による guard、48 種類の症状カタログ等）は Zenn Book Claude Code のトークン消費を半分にするにまとめている。興味があればどうぞ。