7月26日、費用の記録に見慣れない名前が現れた。claude-opus-5。

見つけたのはうちのCCだ。日ごとの費用を勝手に見ていて、報告してきた。私は頼んでいない。

私はモデルの指定を変えていない。それなのに、翌27日には、私の環境の応答の 97.1% が新しいほうのモデルから返っていた。

指定を変えていないのに、使うモデルが2日で入れ替わったことになる。

配布元の移行の手引きには、この入れ替わりが何をもたらすかが書かれている。いちばん厄介そうなのは「応答が途中で切れる」という症状だ。

そこで自分のログを数えた。26,520件の応答のうち、上限で切れたものは0件だった。

この記事は、入れ替わりが実際に起きたことの実測と、言われている実害を自分の環境で数えた結果と、あなたが同じ確認を自分の環境でやる手順をまとめたものだ。

指定していない起動だけが、静かに乗り換わる

配布元が公開している変更の記録を直接開いて確かめた。2.1.219 の項目に、新しいモデルが加わり、それがOpusの系列の既定になったと明記されている。

「既定」ということは、モデルを明示していない起動は、この日を境に別のモデルで動き始める。私の環境は自動で再起動する仕組みを持っていて、その起動の指令にモデルの指定を入れていない。だから記録の中身が、私の操作なしに入れ替わった。

自分のセッションの記録から、Opusの系列の応答を日ごとに数えるとこうなった。

日付	Opus 4.8	Opus 5	新しいほうの割合
7月26日	85件	1,846件	95.6%
7月27日	169件	5,651件	97.1%

古いほうは消えていない。3%ほど残っている。私は最初これを「消えた」と書いていて、記録を見直して直した。消えたのではなく、既定でないものは呼ばれなくなるだけだ。指定を明示している経路だけが残る。

単価が同じ、というのが罠になる

ここで安心してしまうところがある。新しい既定のモデルの単価は、それまでの既定と同じなのだ。

モデル	入力の単価	出力の単価
Claude Opus 5	100万トークンあたり5.00米ドル	100万トークンあたり25.00米ドル
Claude Opus 4.8	100万トークンあたり5.00米ドル	100万トークンあたり25.00米ドル

同じである。一度に読み込める量も両方とも100万トークンで、長い文脈への追加料金もない。

だから単価の表を見た人は「同じ値段なら影響はない」と結論する。私も最初はそう考えた。

言われている実害

配布元の移行の手引きに、破壊的な変更として書かれている項目がある。

【CC補足】思考の既定が反転した
移行の手引きに破壊的な変更として明記されている。Opus 4.8 と 4.7 では thinking を省略すると思考しなかったが、Opus 5 では省略時に思考する。つまり設定を一文字も変えていない呼び出しが、この日を境に思考のぶんのトークンを追加で使い始める。

【CC補足】上限は思考と本文の合計にかかる
max_tokens は応答の本文だけにかかるのではなく、思考と本文の合計に対して効く。思考しない前提で上限を切り詰めていた設定は、思考が既定で入った分だけ本文に使える余地が減る。結果、それまで最後まで出ていた応答が途中で切れる。

答えの長さにぴったり合わせて上限を詰めていた人ほど割を食う、という話になる。無駄な余裕を持たせない丁寧な設定だったはずのものが、ある日から答えを切り落とし始める。

ここまでは全部、配布元の文書に書いてあることだ。私が測ったわけではない。

数えた。0件だった

切れた応答は、見た目としては一見それらしく終わっていることがある。だから目で見るのではなく、終了の理由を数えた。

期間	応答の総数	上限で切れた数
7月17日〜22日（入れ替わり前・Opus 4.8）	18,781件	0件
7月26日〜27日（入れ替わり後・主にOpus 5）	7,739件	0件

合計26,520件で0件。入れ替わりの前も後も、一度も起きていない。

ここで一度立ち止まった。0件は「本当に0」なのか、「私の数え方が間違っている」のか。
同じ書き方で、必ず存在する値を数えて対照を取った。

終了の理由	件数
`tool_use`	71,409
`end_turn`	4,202
`stop_sequence`	100
`null`	84
`max_tokens`	0

同じ書式で end_turn が4,202件出たので、0は書式の間違いではない。
記録の全体75,795件を通して、上限で切れた応答は一度も現れていない。

0が出た時は、まず自分の数え方を疑うほうがいい。必ず存在する値で同じ検査をすると、
道具が壊れているのか本当に無いのかが分かれる。

なぜ0だったのか——これはあなたにも当てはまるとは限らない

ここを曖昧にすると嘘になるので、条件を書く。

私の環境で0件だったのは、私が上限を詰めていないからだ。上限に余裕がある設定では、思考のぶんが増えても本文の余地はまだ残る。だから切れない。

逆に言えば、上限を答えの長さぴったりに詰めている人には起こりうる。移行の手引きに書かれている機序そのものは実在する。私の0件は「この症状は起きない」の証拠ではなく、「私の設定では起きなかった」の証拠だ。

だから結論は「心配しなくていい」ではない。自分の環境で数えろ、になる。

費用が増えたかは、自分のデータからは分からなかった

もう一つ、測ろうとして測れなかったことを書いておく。

思考が既定で入るなら使用量が増えるはずだ。増えたかどうかを、モデルごとの出力トークンの中央値で比べた。2通りの取り方をしたら、逆の答えが出た。

比べ方	Opus 4.8	Opus 5	見かけの結論
全期間をまとめて	1,245	799	新しいほうが軽い
両方が動いた同じ日だけ	457 / 444	942 / 757	新しいほうが重い

原因は分かっている。モデルの割り当てが無作為ではないからだ。同じ日でも、古いほうは残った小さい仕事を、新しいほうは本流の重い仕事を担当している。日付をそろえても、仕事の種類がそろわない。

だから平均の比較では、モデルの差なのか仕事の差なのかを分けられない。日ごとの費用の合計も同じで、作業量に連動してしまう。

測れないことを測ったように書きたくないので、ここは「分からなかった」で置く。

【CC補足】なぜ日付をそろえても足りないのか
比較で交絡を消すには、比べる2群が「調べたい要因以外は同じ」でなければならない。ここで違っているのは日付ではなくどの仕事がどのモデルに割り当てられたかで、これは実験者（この場合は運用の仕組み）が決めている。無作為でない割り当ての下では、群の平均差は要因の効果と割り当ての偏りの合計になり、片方だけを取り出せない。分けるには、同じ入力を両方のモデルに通して比べる（対応のある比較）必要がある。

自分の環境で確かめる——見るのは三つ

1. いま実際に何が使われているか

日ごとの記録を残しているなら、使われたモデルの名前の変化を見る。うちはこれで気づいた。

自動で起動する仕組みを持っている人は、その起動の指令にモデルの指定が入っているかを見てほしい。私の場合はこうなっていた。

claude --dangerously-skip-permissions

モデルの指定がない。だから既定が変わった日に、使うモデルも変わった。

2. 切れているかを数える

目で見ない。終了の理由を数える。自分のログから数えるならこれで足りる。

grep -h '"stop_reason":"max_tokens"' ~/.claude/projects/*/*.jsonl | wc -l

0以外が出たら、上限が詰まっている。自分でAPIを呼ぶ作りなら、応答のたびにこの値を見る。

if response.stop_reason == "max_tokens":
    print("上限で切れた", response.usage)

3. 思考を切っているなら深さとの組み合わせを見る

【CC補足】無効化には深さの制約がある
移行の手引きによれば、思考を無効にできるのは effort が high 以下のときだけで、より深い設定と無効化を組み合わせた呼び出しは400で拒否される。しかもこの検査は呼び出しごとに行われるため、会話の途中で深さを引き上げると、それまで通っていた同じ組み合わせがそこで拒否される。前半が成功していたことは、後半の成功を保証しない。

指定していないものは、いつか変わる

自分が何も変えていないのに前提のほうが変わる、という型の詰まりは、これが初めてではない。設定のファイルが上書きされる、版が上がって既定が変わる、依存するものが勝手に更新される。いずれも自分の操作の記録を追っても原因が出てこない。

今回に固有なのは、請求の単価が変わらないので金額からは気づけないことだ。

そして今回いちばん学んだのは、警告を読んだら自分のログで数えるほうが早い、ということだった。数える前は「切れているかもしれない」と思っていた。数えたら0件で、代わりに「なぜ0なのか」という条件のほうが分かった。条件が分かると、どの設定の人が危ないかも分かる。

自動で動かしているものほど、何を指定していないかを一度数えておく価値がある。

同じように「金額からは気づけない」形でトークンが消える経路を、800時間の運用の記録から集めてトークン消費を半分にする本（¥2,500）にまとめてある。第2章まで無料で読める。