「単価は変わっていない」——その言葉を信じた翌月、請求書が3割増えていた
Sonnet 5に移行したエンジニアが、翌月のAnthropic請求書を開いて絶句する。表示価格は据え置きのはずなのに、数字が明らかにおかしい。同じコードレビューツール、同じドキュメント生成パイプライン、同じ月間ワークロード——それで請求額が約35%跳ね上がっている。
答えはAPIレスポンスの奥深くに隠されている。「1トークンあたりの単価」ではなく「カウントされるトークン数そのもの」が変わっているのだ。これは価格表を見ても絶対に気づけない、構造的な「見えない値上げ」だ。
「価格同等」の裏側——Claude Sonnet 5で何が起きているのか
Anthropicが公表したSonnet 5の標準価格は、Sonnet 4.6と完全に一致する。入力$3.00/1Mトークン、出力$15.00/1Mトークン。価格表だけ見れば、移行コストゼロの優れたアップグレードに映る。
しかし、SitePointおよびTechJack Solutionsが実施した独立した実測レポートが示す数字は、その「常識」を覆す。同一テキストをSonnet 4.6とSonnet 5に投入した場合、Sonnet 5側のusage.input_tokensの返り値が約30〜35%高いのだ。
月間100万トークン相当ワークロードでの試算
- Sonnet 4.6：1,000,000トークン × $3.00/1M = $3.00
- Sonnet 5（同一テキスト）：APIが返すトークン数1,350,000 × $3.00/1M = $4.05
- 実質値上げ率：+35%
月間API費用が$1,000規模のチームなら、同一ワークロードで$1,350の請求が来る。年換算で$4,200——約63万円の追加コストだ。「価格同等」という言葉は、単価の同等性を指しているに過ぎない。同一アウトプットあたりの実効コストは、まったく同等ではない。
なぜこのような乖離が生まれるのか。Anthropicは公式に原因を説明していないため、現時点では構造的な問題として認識しつつ、自社ワークロードでの実測が必須だ。
なぜトークン数が膨らむのか——3つの技術的原因と日本語への特別リスク
技術的に考えられる要因は3つある。非専門家にも理解しやすいよう、順を追って整理する。
原因① トークナイザ語彙の変更
新しいトークナイザは語彙サイズや文字列の分割ロジックが異なり、同じテキストをより細かい単位に切り刻む。「apple」を1トークンで処理していたところを「app」「le」の2トークンに分割するイメージだ。特に日本語・コード・記号が混在するテキストは影響を受けやすい。
原因② システムプロンプトの内部展開
モデルが内部的にシステムプロンプトを拡張・前処理している場合、APIが返すトークン数がユーザーの体感より多くなる。ユーザーが100トークンのシステムプロンプトを送ったつもりでも、内部処理後に130トークンとしてカウントされるケースがこれにあたる。
原因③ 特殊トークンの追加
新しいアーキテクチャが追加の制御トークンを使用している場合、ユーザーには見えない形でトークン数が水増しされる。ログには現れないが、請求には確実に反映される。
日本語ユーザーへの特別リスク：最大50%増の可能性
ここで日本のエンジニアが特に注意すべき事実がある。日本語はそもそもトークン効率が英語の半分以下になるケースがあるのだ。ケンジの調査レポートが示す具体例を見てほしい。
- 「このシステムはユーザー認証機能を提供します」（日本語）→ 推定20〜30トークン
- “This system provides user authentication functionality.”（英語）→ 推定9〜10トークン
同じ意味の文章で、日本語は英語の2〜3倍のトークンを消費する。この構造的不利に、トークナイザ変更の影響が上乗せされる。日本語メインのワークロードでは、30〜35%どころか40〜50%のコスト増になる可能性がある——これは日本市場固有のリスクとして明確に認識すべきだ。
RAGシステム、多言語チャットボット、日本語ドキュメントの自動要約——これらすべてで、見えないコスト膨張が進行している。
フリーランス・SIerの原価計算が崩れる——Claude Code改定との複合ダメージ
「月$50のAPI費用」で見積もりを組んでいた日本のフリーランスエンジニアが、実態では$67.5を支払わされている。年間に換算すると約31,500円の原価増だ。複数クライアントを抱え、各案件でAPIを活用するフリーランスであれば、この倍数がそのまま利益を圧迫する。
典型的なフリーランスの原価変動（月間）
- 改定前の想定：Claude API $50 + その他ツール $30 = AI関連原価 $80
- Sonnet 5移行後の実態：Claude API $67.5 + その他ツール $30 = AI関連原価 $97.5（+21.9%増）
さらに深刻なのは、この増額をクライアントに説明できないことだ。「単価は変わっていない」というAnthropicの言葉が、エンジニア自身の首を絞める。請求書に「Claude API費用」と書いても、クライアントには追加請求の根拠を示しにくい——「見えない値上げ」の最も悪質な側面はここにある。
Claude Code改定（2026年6月15日）との複合効果
さらに追い打ちをかけるのが、2026年6月15日に施行されたClaude Codeの料金体系改定だ。利用枠が「おさいふ2つ」に分離され、CI/CDパイプラインやGitHub Actionsなどの自動化ユーザーは月次クレジット（Agent SDK月次クレジット）から消費する仕組みに変わった。
- おさいふ1（インタラクティブ）：ターミナル/IDE上のClaude Code → サブスクリプション枠（従来通り）
- おさいふ2（Agent SDK月次クレジット）：Agent SDK・
claude -p・GitHub Actions → 月次クレジット（API標準レートで消費）
Max 5xプランで月$100のクレジットが付与される。しかし、トークン数が35%増加した状態でこのクレジットを消費すれば、実質的な処理能力は$74相当に目減りする。CI/CDで自動化を組んでいるエンジニアは、トークン増加と枠の分離という二重の打撃を受けることになる。
固定価格契約（ラボ型・一括請負）でClaude APIを組み込んでいる中堅SIerも同様だ。大量ドキュメントの自動要約、コードレビュー自動化、RAGシステム——入力トークンが多いユースケースほど、収益性への直撃は大きい。
今すぐ取るべき3つのアクション——代替モデル比較と見積もり防衛術
状況を整理した上で、今すぐ動けるアクションを示す。
アクション① 競合モデルの実効コストで比較する
2026年7月時点の主要LLMコスト比較（CostGoatデータ参照）は以下の通りだ。
- Claude Sonnet 5：入力$3.00 / 出力$15.00（実効コストは+30〜35%上乗せ）
- GPT-5.4：入力$2.50 / 出力$15.00
- Gemini 3.1 Pro Preview：入力$2.00 / 出力$12.00
- DeepSeek V4 Pro：入力$0.44 / 出力$0.87（圧倒的低価格）
- Kimi K2.6：入力$0.66 / 出力$3.41
コスト最適化の観点だけで見れば、DeepSeekやGeminiへの乗り換えは経済合理性がある。ただし、DeepSeek・Kimiは中国系モデルであり、データ主権・セキュリティ・APIの安定性というコスト以外の判断軸が必ず存在する。日本企業が個人情報や機密情報を含むワークロードに使用する場合、この点を無視した乗り換えは危険だ。
ワークロード別の判断軸として、コードレビューや社内ドキュメント要約など機密性が低いタスクはGemini 3.1 Pro Previewが有力な代替候補だ。顧客データを含むRAGシステムは品質・セキュリティ優先でSonnet 5を維持しつつ、トークン数の実測と予算バッファで対応する選択肢もある。
アクション② 実測トークン数の計測を習慣化する
まず自社ワークロードでusage.input_tokensをSonnet 4.6と比較計測する。「30〜35%増」という数値はあくまで英語テキスト中心の実測値であり、日本語ワークロードでは乖離が大きくなる可能性がある。予算計画に他社の数値をそのまま使うのは危険だ——自社実測なしに動かない。
アクション③ 見積もりと契約の防衛ラインを引く
- 提案単価へのAPIコスト変動バッファを組み込む：「APIコストは実測値に基づき±20%の変動を想定」と明記する
- クライアントへの説明文言を準備する：「APIプロバイダーの内部処理変更により、同一機能でも課金トークン数が変動するリスクがある」という一文を契約書・提案書に入れる
- 固定価格契約にAPI変動条項を追加する：特にラボ型・一括請負では、API費用の実費精算オプションを設ける
品質向上によるコスト正当化の可能性も排除しない。Sonnet 5の高精度によってエラー修正の反復回数が20%削減されるなら、実効コストの30%増は部分的に相殺される。この検証なしに単純なコスト比較だけで乗り換えを判断するのは早計だ。
ハナの所見
今回の件でハナが最も問題だと断言するのは、コストの増加そのものではない。「価格同等」という言葉の定義権を、ベンダーが一方的に握っているという構造的な問題だ。
単価が同じであれば「価格同等」と言える——この定義が通用する限り、トークンの数え方を変えることで実質的な値上げを繰り返すことができる。Anthropicが意図的にそうしているかどうかは問題ではない。この構造が許容されている限り、同様の事態は今後も繰り返されるという問題がある。
日本特有の障壁：情報格差とベンダー依存の二重苦
日本のエンジニアコミュニティには、この種の問題を声高に指摘する文化的・構造的な障壁がある。英語の実測レポート（SitePoint、TechJack Solutions）が出ても、日本語での検証・拡散が遅れる。APIの詳細な挙動を検証できる技術者が限られ、「ベンダーの言うことを信じる」という受動的なスタンスが根強い。
さらに、日本語ワークロードはトークン効率が構造的に低いにもかかわらず、日本語環境での実測データがほぼ存在しない。英語圏の「30〜35%増」という数値が日本語環境でどこまで増幅されるか、現時点では誰も正確に把握していない——これはデータの空白であり、日本市場固有の情報格差だ。
時期を明示した予測
2026年末までに、日本語ワークロードにおけるSonnet 5の実効コスト増が40〜50%に達するケースが複数報告され、フリーランス・SIer双方で原価計算の見直しが業界的な話題になる。2027年前半には、日本のエンジニアコミュニティまたは業界団体が「実効トークン効率の開示」をAPIプロバイダーに求める動きが具体化する——ハナはそう予測する。
重要なのは単価ではなく、「同一アウトプットあたりの実効コスト」で比較する習慣を業界標準にすることだ。これはコスト問題ではなく、情報の非対称性という構造問題だ。日本のエンジニアコミュニティが声を上げ、APIプロバイダーに対して「実効トークン効率の開示」を義務化するよう求めるべき段階に来ている。価格表の透明性だけでは不十分——処理の透明性こそが次の戦場だ。
まとめ：「価格同等」を自分の目で検証せよ
- Sonnet 5は単価据え置きでも、同一ワークロードの請求額が30〜35%増加する実測データが存在する
- 日本語ワークロードでは40〜50%増になる可能性があり、日本市場固有のリスクとして認識が必要だ
- Claude Code改定との複合効果で、CI/CD自動化ユーザーのクレジット実質価値は最大35%目減りする
- 代替候補としてGemini 3.1 Pro Preview（$2.00/$12.00）が有力だが、データ主権の観点から機械的な乗り換えは禁物だ
- 今すぐ
usage.input_tokensの実測を始め、見積もりにAPIコスト変動バッファを組み込む
「単価は変わっていない」——この言葉を今後は疑いの目で見てほしい。変わったのは単価ではなく、単価の分母だ。
あなたのワークロードでの実測トークン数、ぜひXで #Sonnet5実測 タグで共有を。編集部でデータを集計し、日本語環境での影響レポートを続報でお届けします。日本語の実測データが集まれば集まるほど、業界全体への発信力が高まる——ハナからのお願いだ。
