はじめに
2026年9月22日、Claude Codeの v2.1.280 が公開された。目玉は新モデル「Claude Opus 5.5」の追加だが、それと同じリリースにさりげなく書かれているもう1行が、Pro・Team Standardプランの個人開発者にとってはむしろ本題になる。
GitHubのCHANGELOG.mdにはこうある。
Changed the default model on Pro and Team Standard plans from Sonnet to Opus, matching Max, Team Premium, and Enterprise
「Pro・Team Standardプランの既定モデルをSonnetからOpusに変更した(Max・Team Premium・Enterpriseと同じにする)」。1行だけの地味な記述だが、意味するところは大きい。/modelで明示的にSonnetを選んだ覚えがない限り、これまでSonnetで動いていたセッションが、バージョンを上げた瞬間からOpus 5.5で動き出すということだ。しかもOpus 5.5の単価はCHANGELOG.mdに明記されている通り「$4/$20 per Mtok(キャッシュ読み込みは$0.20/Mtok)」で、Sonnetより明確に高い。
この記事では、この変更が実際にどう効くのかを推測で終わらせず、手元の環境で新旧バージョンを並べて実行し、同じ質問を投げて何が変わるかを実測した。結果を先に言うと、同一アカウント・同一の1行質問で、実際に返ってきた請求額が約55〜70%増えた。加えて、この変更に対して「今日のうちに」できる現実的な対処(固定するか、固定しつつコストを制御するか)を、公式ドキュメントの記述と実機検証の両方から整理する。
一次情報は次の3つ。
– GitHub CHANGELOG.md(anthropics/claude-code): https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
– 公式ドキュメント「Model configuration」: https://code.claude.com/docs/en/model-config
– 公式ドキュメント「Manage costs effectively」: https://code.claude.com/docs/en/costs
なお、本稿の執筆前にWeb検索で見つけた「Claude Codeの週次利用上限が9月14日から25%引き上げ・実質17%減」という話題も検討したが、Anthropic公式サイト(anthropic.com/news)・公式ドキュメント・GitHub CHANGELOG.mdのいずれにもこの変更の一次情報記載が見当たらなかったため、本稿では扱わない。裏取りできない数字は書かない、という本ブログの方針を優先した。
手順: 自分の環境で「本当に既定モデルが変わったか」を3ステップで確認する
推測に頼らず、自分の手元で確認する手順を示す。CLIフラグを何も指定せず、同じ1行の質問を新旧バージョンに投げてmodelUsageフィールド(JSON出力に実際に含まれる、応答に使われたモデル名の集計)を見比べるだけでよい。
ステップ0: 自分のバージョンを確認する(無料・数秒)
claude --version
v2.1.280より前なら、今回の変更はまだ手元では発生していない。筆者の検証環境は v2.1.270 だった。
ステップ1: 新バージョンをグローバル環境を汚さずに隔離導入する
mkdir -p /tmp/cc-2.1.280
npm install @anthropic-ai/claude-code@2.1.280 --prefix /tmp/cc-2.1.280 --no-save
/tmp/cc-2.1.280/node_modules/.bin/claude --version
期待結果: 2.1.280 (Claude Code) と表示される。グローバルのclaude本体には一切触れないので、既存の自動化・エイリアスに影響しない。
ステップ2: 何も指定せず同じ質問を新旧バージョンに投げ、modelUsageを比較する
旧バージョン(v2.1.270、手元のグローバルインストール)で実行:
claude -p "1+1?" --output-format json | grep -o '"modelUsage":{"[a-z0-9.-]*"'
実際の出力:
"modelUsage":{"claude-sonnet-5"
新バージョン(v2.1.280、隔離導入した方)で同じ質問を実行:
/tmp/cc-2.1.280/node_modules/.bin/claude -p "1+1?" --output-format json | grep -o '"modelUsage":{"[a-z0-9.-]*"'
実際の出力:
"modelUsage":{"claude-opus-5-5"
成功判定: --modelフラグも/model設定も一切変えていないのに、返ってきたモデル名がバージョンだけでclaude-sonnet-5→claude-opus-5-5に変わっていれば、CHANGELOG.mdの記述どおり既定モデルの切り替えが自分のアカウントにも実際に効いていることが確認できる。
ステップ3: 実費への影響を数字で見る
同じ1行質問でも、実際に請求されたtotal_cost_usdは次のようになった(3回ずつではなく、それぞれ実行できた回数分の実測値)。
| 実行 | バージョン | 使われたモデル | total_cost_usd |
|---|---|---|---|
| 「1+1?」 | v2.1.270(旧・既定) | claude-sonnet-5 | $0.092046 |
| 「1+1?」 | v2.1.280(新・既定) | claude-opus-5-5 | $0.1556522 |
| 「5+5?」 | v2.1.280(新・既定、再現確認) | claude-opus-5-5 | $0.1425476 |
同じくらいの短さの質問で、Opus側は約55〜70%高い。ここで正直に書いておくと、この2〜3件はキャッシュトークンの状態(セッションが新規かどうか)が完全には揃っておらず、「必ずこの倍率になる」という精密な原価比較ではない。だが「既定モデルが変わった結果、同じ使い方でも単価の高いモデルに請求が寄る」という方向性そのものは、3回とも一貫してOpus 5.5が選ばれたことで裏付けられている。
実際のJSON出力からキャッシュ関連トークン数も抜き出しておく。
| 実行 | モデル | cache_creation(書き込み) | cache_read(読み込み) | output_tokens |
|---|---|---|---|---|
| 「1+1?」v2.1.270 | claude-sonnet-5 | 22,169 | 16,680 | 3 |
| 「1+1?」v2.1.280 | claude-opus-5-5 | 19,222 | 8,141 | 12 |
同じ「1+1?」という1トークンの質問でも、Opus側はキャッシュ読み込みトークンが少なく(セッションのキャッシュがまだ温まっていなかったため)、出力トークンも4倍(3→12)になっている。出力トークンが増えている分だけでも、Opusの方が「同じ質問への回答が長くなりがち」という副次的な傾向が見て取れる。CHANGELOG.mdに明記されたOpus 5.5の単価($4/$20 per Mtok、キャッシュ読み込みは$0.20/Mtok)と合わせて考えると、単価差だけでなく出力の長さの違いも、今回観測した請求額の差に寄与している可能性がある(原因を単一のものに断定はしない)。
なぜこの変更は気づきにくいのか
これまでの版差検証記事では「CLIフラグは即エラー」「設定ファイル経由の新機能は無言で無視される」という壊れ方の分類を何度か扱ってきたが、今回はその2つとも異なる。今回の変更はerrorにもならなければ、無視されて何も起きないわけでもない。セッションは正常に起動し、正常に応答し、ただ内部で選ばれるモデルだけが静かに切り替わる。 /modelを開いて明示的にPickerを見ない限り、あるいは今回のように--output-format jsonでmodelUsageフィールドを確認しない限り、Sonnetで動いているつもりのままOpus 5.5に切り替わっていることに気づく手段がない。CHANGELOG.mdの記述自体も「Changed」の1行に埋もれており、Opus 5.5という新モデルの華やかな見出しの裏に隠れている点も、気づきにくさに拍車をかけている。
関連する変更: API/Enterprise環境のauto modeにも別のコスト変更がある
今回のOpus既定化とは別に、1つ前のリリース(v2.1.278)にも別のコスト関連の変更がある。CHANGELOG.mdには次のように明記されている。
Changed auto mode for Claude API and Enterprise users, and on Bedrock, Vertex, Foundry and gateways, to default to the server-side classifier, which does not charge for classifier overhead (
CLAUDE_CODE_AUTO_MODE_SERVER=0opts out on Bedrock, Vertex, Foundry and gateways); warns on billed fallback.
これはauto modeの安全性チェック(classifier)の課金方式を、サーバー側実行(課金なし)に既定変更するという内容で、対象はAPIキー契約・Enterprise・Bedrock/Vertex/Foundry環境であり、本稿で検証したPro/Team Standardの個人向けサブスクリプションとは対象範囲が異なる。本稿ではこちらは実機検証しておらず、CHANGELOG.mdの記載を紹介するにとどめる。「同じ2リリースの中に、対象読者の異なる2つのコスト関連変更が混在している」こと自体が、CHANGELOG.mdを読む際に見落としやすい点として書き添えておく。
コピペ用プロンプト集
以下は実際に動かして確認済みのコマンド・設定例。1本目は無料・10秒ほどで終わる。
1. 自分のバージョンと、既定モデルが変わる境界(v2.1.280)との差を確認する(無料・数秒)
claude --version
期待結果・成功判定: 表示されたバージョンが 2.1.280 より前なら、この変更はまだ手元の既定モデルには反映されていない(Pro・Team Standardプランの場合)。2.1.280以降ならすでに切り替わっている可能性が高い。
2. 新バージョンを隔離導入し、既定モデルを自分のアカウントで実測する
mkdir -p /tmp/cc-model-check
npm install @anthropic-ai/claude-code@2.1.280 --prefix /tmp/cc-model-check --no-save
/tmp/cc-model-check/node_modules/.bin/claude -p "1+1?" --output-format json \
| grep -o '"modelUsage":{"[a-z0-9.-]*"'
期待結果・成功判定: claude-opus-5-5と表示されれば切り替わっている。claude-sonnet-5のままなら、Max・Team Premium・Enterpriseなど元々Opusが既定だったプラン、またはsettings.json等で別のモデルが明示的に固定されている可能性が高い。
活用例: チームで複数人がClaude Codeを使っている場合、各自にこのコマンドを実行してもらうだけで「誰がいつのまにかOpus既定に切り替わっているか」を洗い出せる。
注意点: このコマンド自体がAPI呼び出しを伴うため実費が発生する(上表のとおり1回あたり約9〜16セント)。何度も繰り返し実行する必要はない。
3. Sonnetに固定したい場合: --modelフラグでその場だけ上書きする
/tmp/cc-model-check/node_modules/.bin/claude -p "3+3?" --model sonnet --output-format json \
| grep -o '"canonicalModel":"[a-z0-9.-]*"'
実際の出力:
"canonicalModel":"claude-sonnet-5"
期待結果・成功判定: claude-sonnet-5と表示されれば、既定がOpusに変わっていても--modelフラグでその場でSonnetに戻せることが確認できる。
4. Sonnetを恒久的に固定したい場合: settings.jsonのmodelキーで指定する(実機で動作確認済み)
echo '{"model":"claude-sonnet-5"}' > /tmp/my-settings.json
/tmp/cc-model-check/node_modules/.bin/claude -p "4+4?" --settings /tmp/my-settings.json --output-format json \
| grep -o '"canonicalModel":"[a-z0-9.-]*"'
実際の出力:
"canonicalModel":"claude-sonnet-5"
期待結果・成功判定: --modelフラグを付けなくてもclaude-sonnet-5が使われていれば、設定ファイル経由の恒久指定が効いている。恒久的にこの設定を使いたい場合は、この内容を~/.claude/settings.json(全プロジェクト共通)や各プロジェクトの.claude/settings.jsonに書けばよい。公式ドキュメント「Model configuration」が明記するモデル解決の優先順位は次のとおり(高い方が勝つ):
1. セッション中の /model <alias|name>
2. 起動時の --model フラグ
3. 環境変数 ANTHROPIC_MODEL
4. settings ファイルの model フィールド
5. 環境変数 ANTHROPIC_DEFAULT_MODEL(新規セッションの既定)
活用例: 「基本はSonnetで動かし、必要な時だけ/model opusで一時的に切り替える」という運用(過去記事で書いたモデル使い分けフローと同じ考え方)を、Opus既定化後も維持できる。
注意点(つまずき所): GitHub Issue #83795(open、2026-08-04作成)は「settings.jsonのmodelキーで固定したはずが、サーバー側の“推奨”モデルに無言で上書きされた」という報告だが、これは旧世代モデル(Sonnet 4.6など)がモデル一覧から撤去された際の話であり、今回のOpus 5.5既定化とは別の事象である。今回、筆者がsettings.json経由でSonnet 5に固定するテストを実際に行った限りでは、意図通りSonnet 5が使われた(上記の通り再現確認済み)。「固定が効かなくなる」という過去の報告を、今回の変更にそのまま当てはめるのは誠実性に反するため区別して書いている。
5. Opus既定のまま使い続ける場合: モデルごとのeffortレベルでコストを調整する
Opus 5.5はデフォルトのeffortレベルがmediumになる(他の多くのモデルの既定highより低い)ことが公式ドキュメントに明記されている。単価が高い分、思考トークンの既定消費を抑える設計になっているとも読める。さらに簡単なタスク用に下げたい場合は、モデルごとにeffortLevelではなくmodelSettingsキーで個別指定する。
{
"modelSettings": {
"claude-opus-5-5": {
"effort": "low"
}
}
}
期待結果・成功判定: このJSONを~/.claude/settings.jsonに追加後、/effortを開くとOpus 5.5のセッションがlowから始まる(モデルごとに保存される設定のため、他のモデルの設定には影響しない)。
注意点(つまずき所): 公式ドキュメントには「以前/effortが書き込んでいた旧形式のトップレベルeffortLevelキーは、Opus 5.5には適用されない」と明記されている。つまり、Opus 5未満の時代に設定した古いeffortLevelをそのまま持っている人は、Opus 5.5では静かに無視され、既定のmediumから始まる。これは筆者が自分のeffort設定を書き換えて実測したわけではなく、公式ドキュメントの記載をそのまま引用したものであることを明記しておく。
活用例: 立場別にどう対応するか
- 個人のPro/Team Standardプランで、コストに敏感な開発者: まずステップ1〜2の隔離導入チェックで、自分のアカウントが実際にOpus既定へ切り替わったかを確認する。切り替わっていれば、プロンプト3・4のどちらかで一旦Sonnetに固定し、必要な場面だけ
/model opusまたは/effortで明示的にOpusへ上げる、という運用に切り替えるのが最も直接的な対処になる。 - Opusの回答品質を活かしつつコストも抑えたい人: プロンプト5の
modelSettingsでOpus 5.5のeffortをlowやmediumに固定し、複雑な設計判断が必要な時だけ/effort highでその場だけ上げる、という使い分けができる。 - チームでコストを横断的に把握したい管理者: 今回のプロンプト2は1人ずつ手動で実行する前提だが、複数人の環境差を横断的に見たい場合は、公式ドキュメントが案内する組織analytics(
Enterprise Analytics APIやConsole dashboard)を使う方法もある。ただしこの記事ではAPIキー契約・Enterprise環境そのものは検証しておらず、公式ドキュメントの記載を紹介するにとどまる。
注意点・つまずき所・限界
- 自分のプラン種別はローカル設定ファイルからは分からなかった:
~/.claude.jsonを実際に検索したが、プラン種別(Pro/Max/Team Standard等)を示すフィールドは見つからなかった。今回の「新旧バージョンで同じ質問を投げて既定モデルの違いを見る」という方法は、プラン種別を直接読み取れない環境でも「実際に既定が変わったかどうか」だけは確認できる、という限られた範囲の診断法であることを明記しておく。 - コスト比較は精密な原価実験ではない: 上表の3件は同じ1行質問だが、セッションごとのキャッシュ書き込み/読み込みトークン数が完全には揃っていない(新規セッションのたびにキャッシュ状態が変わるため)。「既定がOpusに切り替わった事実」は3回とも一貫して確認できたが、「必ず何%増える」という一般化はできない。
- Issue #83795の「固定が効かない」報告と混同しない: 前述の通り、この報告は2026年8月時点の旧世代モデル撤去に関するものであり、今回のOpus既定化とは別の事象。今回の検証範囲では
settings.json固定・--modelフラグのいずれも意図通り動作した。 - effortレベルの引き継ぎ挙動は公式ドキュメントの記載のみで、自分では未検証: 「旧形式の
effortLevelキーがOpus 5.5に適用されない」という点は、実際に自分の設定ファイルを古い状態にして確かめたわけではなく、公式ドキュメントの記載をそのまま引用している。 - 週次利用上限の変更は本稿では扱わない: 前述の通り一次情報で裏取りできなかったため。
- 検証コスト: 本稿の検証のために
claude -pをあわせて6回実行した。金額を正確に記録できたのは3回分(合計 $0.390118)で、残り3回(--model sonnet指定・settings.json固定・2回目のOpus既定確認)は同程度の1行質問だったため、実費の合計はおおよそ0.6〜0.8ドル程度と見積もっている。正確な内訳をすべて記録できなかった点は今後の改善課題としたい。
締め: 今日やること
Claude Codeのバージョンをclaude --versionで確認し、v2.1.280以降でPro・Team Standardプランを使っているなら、まず一度だけ隔離導入した新バージョンで「本当にOpus 5.5が既定になっているか」を確認してほしい。もし切り替わっていて、それが望む結果でないなら、--modelフラグでのその場しのぎではなく、settings.jsonのmodelキーで恒久的にSonnetへ戻すのが最も手間の少ない対処になる。逆にOpusの品質をそのまま活かしたいなら、modelSettingsでeffortレベルを個別に調整するところから始めるとよい。どちらを選ぶにせよ、「気づかないまま単価の高いモデルで動き続ける」状態だけは避けられる。
自動化・定期実行でClaude Codeを回している場合は特に注意したい。人が毎回/modelのPickerを目視するインタラクティブセッションと違い、claude -pを使った無人実行はエラーも警告も出ないままモデルだけが切り替わるため、月間の請求額が変わって初めて気づく、という順序になりやすい。本稿の検証手順(ステップ1〜2)は、そうした無人パイプラインの設定ファイルに対しても、実行前に一度だけ確認する形でそのまま使える。
Comments