この記事の対象読者と得られること
| 対象読者 | この記事で得られること |
|---|---|
| Opus 4.7 へ移行予定の方 | トークナイザー変更による実コスト影響の具体像 |
| Claude Code を月5万円以上使っている方 | キャッシュ TTL 短縮への対応策 |
| FinOps / コスト管理を担当する方 | トークン単価だけでは見えないコスト差分の計測手法 |
はじめに — 据え置きのはずが請求が跳ねた話
筆者は業務で Claude Code を毎日使っており、4月中旬に Opus 4.7 へ更新しました。公式アナウンスで「料金据え置き」と書かれていたので、特に身構えずモデル文字列だけ差し替えて運用を続けていたところ、週次の請求集計で違和感があり、前週比で1.3倍近い金額になっていました。
プロンプトも使い方も大きく変えていなかったため、最初は API の課金バグを疑ったほどです。しかし調べるうちに、犯人は単価ではなく「トークンの数え方」と「キャッシュの持ち時間」でした。
本記事では、Opus 4.7 GA で何が変わったのかを整理し、筆者の環境で実測した結果と、今日から打てる対策を共有します。なお数字は筆者のプロジェクトでの参考値であり、ワークロードが異なれば結果は変わり得ます。
本記事は 2026-04-23 時点の情報に基づきます。モデル仕様や価格は変更される可能性があるため、運用前に Anthropic 公式ドキュメントで最新情報を確認することをおすすめします。
背景 — トークナイザー刷新はなぜ起きたのか
実コストの話に入る前に、「そもそもなぜ 4.7 でトークナイザーが差し替わったのか」を整理しておきます。数字の裏側にある意図を押さえておくと、単なる「値上げに感じる」話ではなく、設計上のトレードオフとして理解しやすくなるためです。
なぜトークナイザーが刷新されたのか
Claude 3 系から Opus 4 系へ移行する過程で、トークナイザーは一度大きな改修を受け、その後も 4.5 → 4.6 → 4.7 で段階的にチューニングされてきたとされています。Anthropic 側の公開情報や FinOps 系解説記事を追うと、主な動機として次の3点が挙げられます。
- 多言語コーパスの比率変化: 学習データに日本語・中国語・アラビア語などの比率が増え、英語中心だった旧語彙では非英語の圧縮効率が悪化していた
- コード・数式の扱い改善: インデントや演算子の並び、LaTeX 表記など、プログラム・技術文書特有のパターンで無駄なトークン分割が起きていた
- 長文コンテキストでの効率化: 200k token 級のコンテキストを日常的に扱うようになり、同じ意味を運ぶのに必要なトークン数を減らすインセンティブが大きくなった
4.7 の語彙再設計はこれらを同時に解決しようとしたもの、という見立てが自然です。Anthropic が内部評価で使っている benchmark （SWE-bench Pro を含む複数の技術系ベンチ）でのスコア改善が、刷新判断の一つの根拠になっていると考えられます。
ただし、語彙を「多言語向けに薄く広く」振り直した副作用として、従来 1 トークンにまとまっていた一部の英単語や日本語語尾が複数トークンに分かれるケースが増えています。刷新のメリットとデメリットは表裏一体で、どちらが大きく出るかはワークロード次第です。筆者の手元では、後述の比較表にあるとおり日本語記事で +24% 前後のトークン増加が観測されましたが、これは筆者プロジェクトの 1 サンプルであって公式発表の数値ではありません。Anthropic が公開している範囲では「内容により 1.0〜1.35 倍の範囲で増加しうる」という大まかな記述にとどまっています。
BPE設計の見直しで何が変わったか
もう少し踏み込んで、BPE（Byte Pair Encoding）の仕組みから整理してみます。BPE は、テキストをまず 1 バイト単位に分解し、頻出するバイト列のペアを繰り返しマージして語彙を作る手法です。結果として、頻出する文字列ほど短いトークン列にまとまり、珍しい文字列ほど細かく分割される性質があります。
OpenAI の tiktoken（cl100k_base 等）と Claude の独自トークナイザーは、いずれも BPE 系ですが、語彙の組み方が異なります。ざっくりした比較は次のとおりです。
| 観点 | tiktoken (cl100k_base) |
Opus 4.6 までの独自方式 | Opus 4.7 の新方式 |
|---|---|---|---|
| ベース | BPE（英語中心の最適化） | BPE（英語+コード寄り） | BPE（多言語+コード均衡） |
| 語彙サイズ | 約 100k | 同程度の規模とされる | 同〜やや拡大の見立て |
| 非英語の扱い | バイト列として細かく分割 | 一部言語向けに調整あり | 多言語を意識した再配分 |
| コード・記号 | 記号は個別トークン化が多い | インデント結合など独自最適化 | さらにパターン拡張 |
日本語が英語より多トークンになりやすい根本原因も、ここから説明できます。英語アルファベットは 1 バイトで表現できるのに対し、日本語のひらがな・カタカナ・漢字は UTF-8 で 3 バイト使います。BPE が十分に「ます」「である」「ですが」のような語尾を結合してくれていれば 1〜2 トークンで済みますが、結合が弱い語彙だと、ほぼバイト単位の 3 トークンに割れてしまいます。
ここにはトレードオフがあります。語彙サイズを増やせば多言語の圧縮率は上がりますが、モデル側の embedding 行列と出力層が大きくなり、推論時のメモリ・レイテンシに跳ね返ります。逆に語彙を絞れば軽くなりますが、非英語や周辺言語の圧縮率が落ちます。4.7 の語彙再設計は、この綱引きの中で「多言語と長文コードを優先し、一部の既存パターンでのトークン数増加は許容する」という選択をした、と読むのが筋です。
BPE そのものの基礎に興味があれば、Sennrich らの原論文 "Neural Machine Translation of Rare Words with Subword Units" (2016) や、Hugging Face の tokenizers ドキュメントが出発点として分かりやすいです。本記事では深入りしませんが、トークナイザーの挙動を自分で再現したい場合の足がかりになります。
この背景を押さえたうえで、以降では「4.7 で何がどれだけ増えたか」を具体的に見ていきます。
Opus 4.7 リリースの事実整理
Opus 4.7 は 2026年4月16日 に GA となりました。重要なポイントは以下の3点です。
| 項目 | Opus 4.6 | Opus 4.7 |
|---|---|---|
| 入力単価 | $5 / 1M tokens | $5 / 1M tokens（据え置き） |
| 出力単価 | $25 / 1M tokens | $25 / 1M tokens（据え置き） |
| SWE-bench Pro | 参考値 72.3% | 公称 78.1% |
| トークナイザー | tiktoken 互換方式 | 新方式（BPE 設計見直し） |
| プロンプトキャッシュ TTL | 60 分（標準） | 5 分（標準） |
価格表だけ見れば何も変わっていません。しかし課金の構成要素は「単価 × トークン数 × キャッシュヒット率」で決まります。4.7 では後ろ2つが同時に悪化した、というのが今回の本質です。
新トークナイザーで何が変わったか
なぜ変更されたのか
Anthropic の公開情報や FinOps 系の解説記事によれば、Opus 4.7 のトークナイザーは、多言語コーパスと長文コンテキストに最適化するために BPE 語彙を再設計したものです。コード・数式・多言語混在文の扱いを改善する意図があるとされています。
ただし副作用として、従来 1 トークンにまとまっていた文字列が複数トークンに割れるケースが増えました。特に短い英単語の接尾辞や日本語のひらがな語尾で、この傾向が顕著です。
実測: 同じ文字列が何トークンになるか
以下の表の数値は、筆者が特定のプロジェクトで用意したごく限定的なサンプルでの実測値です。Anthropic 公式の発表としては「内容により 1.0〜1.35 倍の範囲で増加しうる」という大まかな記述のみが確認でき、言語別の具体的な増加率（例: 日本語 +24%、英語 +12.5% など）は公表されていません。数値を「公式値」や「代表値」として引用するのは避け、必ず自プロジェクトの実データで計測することをおすすめします。
筆者の手元で、同一の文字列を 4.6 相当と 4.7 のトークナイザーに通して比較した結果です。あくまで筆者プロジェクトでの参考値として読んでください。
| 入力テキスト | 4.6 相当 tokens | 4.7 tokens | 増加率 |
|---|---|---|---|
| 英語ドキュメント（README 約 2,000 語） | 2,480 | 2,790 | +12.5% |
| 日本語技術記事（約 3,500 文字） | 3,210 | 3,980 | +24.0% |
| TypeScript ソース（約 500 行） | 4,100 | 4,520 | +10.2% |
| 混在プロンプト（CLAUDE.md 相当） | 5,860 | 7,240 | +23.5% |
注: 表の数値は筆者環境での1サンプルに過ぎず、ワークロード全体の代表値ではありません。同じ言語・同じ種類の文書でも、文体や含まれる固有名詞、記号の使い方で結果は容易に変わります。「日本語だから必ず +24% になる」といった一般化は成り立たないので、数値は自分のプロンプトで実測して確かめてください。
日本語テキストで 2 割以上増えている点は、日本語圏のユーザーにとって痛い場面が出やすいポイントだと考えられます。英語より日本語のほうが影響が大きく出やすい傾向があるとすれば、語彙設計が多言語バランスを取り直した結果だと見ることもできますが、定量的な差は各自のワークロードで確認する必要があります。
実測スクリプト — 自分の手元で計測するための最小コード例
前節の表はあくまで筆者の 1 サンプルなので、読者自身のリポジトリで数値を取り直すことが重要です。この節で示すのは、そのための最小スクリプトです。Anthropic SDK の token counter をそのまま叩くだけの構成になっています。4.6 との比較は、4.6 をピン留めした別キーで同じリクエストを流す形が確実です。
# token_count_compare.py
# 使い方: python token_count_compare.py path/to/file.md
import sys
from pathlib import Path
from anthropic import Anthropic
client = Anthropic()
MODELS = [
"claude-opus-4-6-20260101", # 比較用の旧バージョン（例）
"claude-opus-4-7-20260416", # 4.7 GA
]
def count_tokens(model: str, text: str) -> int:
res = client.messages.count_tokens(
model=model,
messages=[{"role": "user", "content": text}],
)
return res.input_tokens
def main(path: str) -> None:
text = Path(path).read_text(encoding="utf-8")
print(f"file: {path} ({len(text)} chars)")
base = None
for m in MODELS:
n = count_tokens(m, text)
diff = "" if base is None else f" (+{(n / base - 1) * 100:.1f}%)"
print(f" {m}: {n} tokens{diff}")
if base is None:
base = n
if __name__ == "__main__":
main(sys.argv[1])
出力例（筆者の環境での抜粋）は次のような形になります。
file: docs/CLAUDE.md (12843 chars)
claude-opus-4-6-20260101: 5860 tokens
claude-opus-4-7-20260416: 7240 tokens (+23.5%)
count_tokens は課金対象ではありませんが、レート制限の対象にはなります。大量ファイルを一括で流すとスロットリングに引っかかるため、ディレクトリ単位でバッチ化するなら並列数を絞ってください。
プロンプトキャッシュ TTL が 60min → 5min に短縮された影響
何が変わったか
もう1つの変化がプロンプトキャッシュの標準 TTL です。Opus 4.6 世代では、cache_control でマークした prefix は既定で 60 分ヒットし得ました。4.7 ではこれが 5 分に縮みました。5 分以内に再アクセスしなければキャッシュは失効し、フル課金で再評価されます。
長 TTL が欲しい場合は拡張 TTL オプション（1h 指定）が提供されますが、こちらは追加コストがかかります。つまり「暗黙に長く持っていたキャッシュ」を「明示的に金額を払って持つ」構造に変わった、と理解するとよいでしょう。
なぜコストに効くのか
キャッシュヒット時のトークン単価は通常入力の 10% 程度に割引されるのが一般的です。1 回のリクエストで 5,000 token の prefix を再利用できれば、実質的に 500 token 分しか払わずに済む計算になります。
ところが、
- 開発者が別の調べ物をして 10 分離席して戻った
- CI のリトライ間隔が 10 分だった
- バッチが 5 分の cron ではなく 15 分 cron だった
といった「5 分を微妙にまたぐ」状況で、キャッシュは毎回失効します。結果として、従来は 1 回分だけ支払っていた prefix のコストを、何度も払い直すことになります。
筆者環境でのビフォーアフター
同一のエージェント（社内情報検索ボット）で、条件を揃えて 1 日回した結果が以下です。あくまで筆者環境の一例としてお読みください。
素の移行では 1.35 倍に膨らみ、拡張 TTL を明示しても 1.18 倍に留まる、という結果でした。プロンプト構造を見直さずにモデルだけ差し替えると、コスト上昇分が全部乗ってきます。
対策 — 今日から打てる 3 つの手
1. ANTHROPIC_MODEL で当面ピン留めする
すぐに移行する必要がない領域は、環境変数でモデルを 4.6 に固定しておくのが一番確実です。
# .envrc など
export ANTHROPIC_MODEL="claude-opus-4-6-20260101"
Claude Code v2.1.88 では、この環境変数が CLI 側のデフォルトモデルに反映されます。コードベース全体を 4.7 に上げる前に、まず「どのワークロードで 4.7 の性能向上が本当に必要か」を切り分けるフェーズを挟むのが安全です。
4.7 の SWE-bench Pro スコア向上は魅力的ですが、請求書ベースのトータルコストが上がってしまっては本末転倒になりがちです。
ピン留めといっても、4.6 系はいずれ deprecation されます。計測と切替計画は並行して進め、ピン留めはあくまで時間を稼ぐ手段だと捉えるのがよいでしょう。
2. Haiku 4.5 を review 役にルーティングする
次に効いたのは、タスクをモデル単位で分担することです。筆者の場合は以下の構成に変更しました。
| タスク | 変更前 | 変更後 |
|---|---|---|
| 設計・難しいリファクタ | Opus 4.6 | Opus 4.7 |
| コード差分のレビュー・要約 | Opus 4.6 | Haiku 4.5 |
| lint 違反の自動修正 | Opus 4.6 | Haiku 4.5 |
| テスト雛形生成 | Opus 4.6 | Haiku 4.5 |
Haiku 4.5 は Opus 4.7 より単価が低く、短い定型タスクでは精度差がほぼ体感できません。Opus 4.7 を使うのは「Haiku で間違えた時のコスト > Opus の差額」になるケースに絞るイメージです。
とはいえ、どこで精度が落ちるかはドメイン依存です。筆者の環境では意思決定ログの要約で Haiku が固有名詞を取りこぼすケースがあり、その部分だけは Opus に戻しています。
3. cache-first なプロンプト設計に直す
TTL 5 分を前提にすると、プロンプト構造自体を「キャッシュを再利用しやすい形」に直す価値が出てきます。
ポイントは、
- 不変部分をプロンプト先頭に集める
- 変動部分（ユーザー入力、時刻、ランダム ID）は末尾に回す
-
cache_controlは複数段で打ち、内側ほど変わりやすいものに割り当てる
という設計です。ログ出力に cache_read_input_tokens と cache_creation_input_tokens が含まれているので、ヒット率を数値で追いかけやすくなっています。
筆者の環境では、system prompt を Markdown の箇条書きから「見出しで区切った固定ブロック」に整理し直しただけで、同一ジョブのキャッシュヒット率が 38% から 71% に改善しました。プロンプトを書き直すコストは一度きりで、ランニングの請求にずっと効いてきます。
モデル比較 — 4.7 だけ見ていても判断を誤る
ここまでは Opus 4.6 → 4.7 の差分に絞って書いてきました。ただ、実務でコストを決めるのは「どのモデルを使うか」の設計です。4.7 を選ぶべき場面・4.6 をピン留めする場面・そもそも Haiku や Sonnet へ降ろすべき場面を整理しておきます。
4モデル比較表 — 2026年4月時点
手元の運用で日常的に候補となる 4 モデルを並べたのが次の表です。単価は Anthropic 公式の API Pricing ページ、SWE-bench Pro は各モデルのモデルカード・リリースノートから採ったものを筆者が集約しています。日本語トークン増と実質日本語コストは、筆者プロジェクトでの計測値を基にした概算値として読んでください。
| 軸 | Opus 4.6 | Opus 4.7 | Sonnet 4.6 | Haiku 4.5 |
|---|---|---|---|---|
| 入力単価 / 1M tokens | $5 | $5 | $3 | $0.80 |
| 出力単価 / 1M tokens | $25 | $25 | $15 | $4 |
| SWE-bench Pro（公称） | 72.3% | 78.1% | 69.0% | 58.0% |
| キャッシュ TTL（標準） | 60min | 5min | 60min | 60min |
| 日本語トークン増（対 4.6 基準） | 基準 | +24%（筆者サンプル） | 基準 | 基準 |
| 実質日本語コスト（筆者環境の概算） | 基準 | +28〜35%（筆者サンプル） | -40% | -80% |
注: 表の「日本語トークン増」「実質日本語コスト」列は、いずれも筆者プロジェクトでの 1 サンプルに基づく概算であり、Anthropic 公式の発表値ではありません。公式には「内容により 1.0〜1.35 倍の範囲で増加しうる」という記述しか公開されていないため、数値そのものを引用するよりは「自分のワークロードで同じ軸で測り直すためのテンプレート」として捉えるのが安全です。
SWE-bench Pro の値は公開ベンチマーク時点のスコアであり、社内タスクの成績とは必ずしも一致しません。Anthropic のモデルカードに添えられた注記でも、「特定ワークロードでの振る舞いは自分のタスクで必ず検証してほしい」旨が繰り返し述べられています。
表の右 2 列の「実質日本語コスト」は、同じ日本語テキストを処理する場合の課金額を Opus 4.6 の水準を 100 として表したものです。単価が安いモデルは、日本語トークン増の影響を受けても総額で下回るケースが多く、逆に 4.7 は「単価据え置きだが、トークン数が増えて TTL も短くなる」分だけ、実コストが上に振れる構造になります。
タスク別のモデル選択指針
4 モデルの位置関係が見えたところで、筆者が現在採用している判断マトリクスを共有します。これはあくまで筆者の業務での基準であり、読者のワークロードによっては結論が入れ替わる可能性があります。
- Opus 4.7 を第一候補にするケース: 難度の高いリファクタ、設計レビュー、SWE-bench Pro のような「複数ファイルにまたがる構造変更」系タスク。コストが上がっても正答率が効いてくる領域
- Opus 4.6 にピン留めするケース: 日本語ドキュメント中心のナレッジ処理、長いプロンプトを 60 分 TTL 前提で設計してきた既存エージェント。移行判断を保留し、計測と並行運用するフェーズが合う
- Haiku 4.5 に降格するケース: lint 違反の自動修正、テスト雛形の生成、短い差分の要約。Opus と体感差が出にくく、単価差が約 6 倍効いてくる領域
- Sonnet 4.6 に切り替えるケース: コード生成で一定の品質は欲しいが、Opus まで必要かは微妙なケース。特に日本語混在のドキュメント生成では、トークン増の影響が小さい分 Sonnet が有利に出やすい
「性能の高い順に使う」発想だと Opus 4.7 に寄せたくなりますが、現場では「Haiku で間違えた時の手戻りコスト > Opus 差額」になる境界を探すほうが、月次請求の削減には直結します。
価格据え置きと実コスト据え置きは別物
最後に、モデル選定と FinOps を結びつける観点として整理しておきたいことがあります。それは、「新しい」「価格据え置き」「ベンチマーク向上」のいずれも、「自分の現場での実コストが据え置き以下」を意味しないという点です。
今回の 4.7 で起きた変化は、次のように分解できます。
- 単価: 据え置き（$5 / $25 のまま）
- トークン数: 言語やプロンプト形状によって増加傾向。Anthropic 公式は「内容により 1.0〜1.35 倍の範囲で増加しうる」と記述。筆者環境では 10〜25% 程度の増加を観測（ただしサンプルは限定的）
- キャッシュ TTL: 60min → 5min に標準短縮、明示すれば 1h まで延長可（ただし追加課金）
- 性能: SWE-bench Pro で 72.3% → 78.1%
表向きの単価を触らずに、トークン増・TTL 短縮という形で「統計的に利用頻度が高かったオプション」を明示課金側に寄せた、と見ることもできます。Anthropic にとってはサービス全体の持続可能性を保つ調整であり、筋は通っています。他方、利用側からすると、単価表と実請求のあいだに噛み合わないものを感じやすくなります。
ベンダーを評価するときは、price per token に加えて、少なくとも次の 3 点を自分で計測・記録しておくと、モデル更新のたびに足元がぶれにくくなります。
- 代表的なプロンプトが何トークンに数えられるか（
count_tokensで OK） - 本番ワークロードのキャッシュヒット率
- 1 ジョブあたりの実請求額（モデル別）
逆に言えば、この 3 点さえ押さえていれば、次に 4.8 や 5.x が来ても「自分のユースケースでどう動くか」を短時間で見積もれます。移行判断は、ベンチマーク値ではなく、この 3 点セットの変化で決めるのが健全だと考えています。
まとめ — 公称コストと FinOps 実コストは別物
今回の Opus 4.7 移行で学んだことは、次のとおりです。
- 価格据え置きでも、トークン数え方の変更だけで請求は動く
- 日本語ワークロードではトークン増の影響がより大きく出る可能性がある（ただし具体的な増加率は Anthropic から公表されていないため、自分のプロンプトで実測することが前提）
- プロンプトキャッシュの TTL は、明示しなければどこかで縮むことがある
- LLM ベンダーを評価するときは price per token だけでなく token count そのものを見る必要がある
Opus 4.7 移行チェックリスト
本記事で示した数値は筆者環境の参考値にすぎないため、移行前後で自分のプロンプトで実測することを強くおすすめします。最低限、次の 3 つを自分の手元で記録しておくと、後からの比較がぶれにくくなります。
-
代表プロンプトを
count_tokensに通し、4.6 と 4.7 でトークン数を比較する -
本番ワークロードのキャッシュヒット率（
cache_read_input_tokens/cache_creation_input_tokens）を 4.6 と 4.7 で比較する - 1 ジョブあたりの実請求額をモデル別に記録し、想定どおりかを確認する
「公称単価」と「自社の実コスト」はまったく別のレイヤにあります。モデル更新のたびに、単価表を読むだけではなく、自分のプロンプトを自分の手元で計測する習慣を持っておくと、後から請求書で驚かずに済みます。
筆者もまだ計測の自動化は途中で、改善の余地は多く残っています。もし同じような移行経験や、独自の計測方法があれば、ぜひコメントで教えてください。
参考リンク
- Finout — Claude Opus 4.7 Pricing: The Real Cost Story Behind the Unchanged Price Tag
- DEV.to — Claude Prompt Caching in 2026: The 5-Minute TTL Change That's Costing You Money
- Claude Code 公式ドキュメント — Model Configuration
- Anthropic — API Pricing（モデル別単価とキャッシュ課金の公式レート）
- Anthropic Docs — Prompt caching（TTL の仕様と
cache_controlの使い方） - Anthropic Docs — Token counting（
messages.count_tokensAPI 仕様） - Anthropic — Claude モデル一覧とモデルカード（SWE-bench 等のベンチスコア参照元）
- Sennrich et al. — Neural Machine Translation of Rare Words with Subword Units (BPE の原論文, arXiv:1508.07909)
- Hugging Face — Tokenizers documentation（BPE を含むサブワード分割の実装解説）