入力 100万トークンあたり $5、出力 $25。Opus 4.8 とまったく同じ数字のまま、2026年7月24日に Claude Opus 5 が出た。同じ日に Claude Code v2.1.219 が既定の Opus をこれに切り替えたので、設定を触っていない人の手元でも中身だけが入れ替わっている。価格が動かない載せ替えは、請求書を見ても気づけない。
目次
7月24日に何が公開されたか
Anthropic が公開した Claude Opus 5（API のモデルID は claude-opus-5）の主な数字は次のとおりだ。価格は Opus 4.8 から据え置き、コンテキストは 1M トークンが既定かつ最大で、小さい版の選択肢はない。
| 項目 | Opus 5（通常） | Opus 5（fast mode） |
|---|---|---|
| 入力 / 100万トークンおすすめ | $5 | $10 |
| 出力 / 100万トークン | $25 | $50 |
| コンテキスト | 1M トークン（既定かつ最大） | |
| 最大出力 | 128k トークン | |
| 思考（thinking） | 既定でオン。low / medium / high の効果切り替えあり | |
| 速度 | 基準 | 約2.5倍 |
fast mode は賢さが上がる版ではない。能力は同じで、出力が速くなる代わりに単価が倍になる。ここを取り違えると、急ぎでもない夜間バッチに倍額を払い続けることになる。
ベンチマークについては Anthropic 自身が Frontier-Bench と GDPval-AA でトップ、ARC-AGI 3 で次点モデルの3倍スコアと主張している。筆者は同じ条件で追試していないので、ここは開発元の主張として読んでいる。X では発表動画が広く回っていて「新しい装備が配られたのに旧式のまま戦っている」といった感想も見かけた。ただ、その空気で乗り換えを決めると、自分の使い方に合っているかは分からないままになる。
気づかないうちに中身が入れ替わる
今回いちばん厄介なのは、価格が同じで名前も「Opus」のままだという点だ。Claude Code を使っていて、モデルを明示していなければ、7月24日を境に呼び出し先が静かに変わっている。設定ファイルにもコミット履歴にも痕跡が残らない。
車で言えば、同じ車種名・同じ月々の支払いのまま、エンジンだけ載せ替わったようなものだ。燃費が良くなったか悪くなったかは、走って給油してみるまで分からない。
自分がどのモデルで動いているかは、次で確認できる。
# 現在の既定モデルと解決先を確認する
claude --version
claude config get model # 明示設定していなければ空 or alias
# セッション内なら /status で解決済みモデルIDが出る
# 例: claude-opus-5 / claude-opus-5-fastここで opus のような別名を設定している場合、その別名が指す実体はバージョンアップで移動する。固定したいなら、フルのモデルIDを書いておく必要がある。
固定を強く勧めたいのは、タスクスケジューラや cron から回している無人ジョブのほうだ。人が見ていない処理でモデルが入れ替わると、出力の形が変わってもその場では誰も気づかない。筆者は週次のニュース収集を Windows のタスクスケジューラから claude -p で起動しているが、この手のジョブは失敗しても静かに終わる。起動行にモデルIDを書いておけば、少なくとも「いつから挙動が変わったか」を後から特定できる。
rem 無人ジョブでは別名でなくモデルIDを明示する
claude.exe -p "/weekly-collect" --model claude-opus-5 --permission-mode dontAsk価格が同じときに請求額を決めるのはトークン量だけ
筆者が最初にやったのは、1タスクあたりの総トークンを測り直す準備だった。単価が固定されているとき、支払額を動かせる変数はそれしか残っていない。
賢いモデルは、同じ課題をより少ない試行で終わらせることがある。思考が既定でオンになっているぶん、簡単な課題にも長い推論が付いて出力トークンが膨らむこともある。どちらに転ぶかは課題の性質で変わるので、他人のベンチマークでは代わりにならない。
例えば「テストが1本落ちているので直す」という日常的な依頼を考える。Opus 4.8 が3往復で直し、Opus 5 が1往復で直したなら、1回あたりの出力トークンが多少増えても総額は下がる。逆に「READMEの誤字を直す」ような課題で長い思考が付くと、単価据え置きのまま請求だけが増える。
筆者の環境では後者のパターンが怖い。週次のニュース収集や公開前検査を無人ジョブで回しているので、細かい依頼が自動で何十回も走る。1回あたり数円の差でも、月に均すと無視できない額になる。
手元で測り直す手順
難しい計測は要らない。同じプロジェクト・同じ CLAUDE.md・同じサブエージェント構成のまま、モデルだけ入れ替えて同一タスクを流し、使用量を記録すれば足りる。
# 1. 計測前にプロジェクトを固定する（作業ツリーを汚さない）
git switch -c bench/opus5-compare
git status --short # 空であることを確認してから始める
# 2. モデルを明示して同じ依頼を流す
claude -p "tests/test_parser.py の失敗を修正して、原因を1行で説明して" \
--model claude-opus-5 --permission-mode dontAsk
# 3. 直後に使用量を見る（セッション内なら /cost でも可）
claude usage --today記録する列は4つで足りる。入力トークン・出力トークン・所要時間・目的を達成できたか（成否）。成否を入れるのが肝で、これが無いと「安いが失敗して2回やり直した」モデルが最安に見えてしまう。
model in out sec ok
opus-4.8 18,200 3,400 92 yes
opus-5 17,900 5,100 61 yes
sonnet-5 17,800 2,900 38 no(2回目でyes)この表の読み方には注意がいる。1行ずつの比較では差が出ないことも多い。筆者は同じ課題を3回ずつ回して中央値を見るようにしている。1回だけの結果で乗り換えを決めると、たまたま当たった回に引きずられる。
測るときに数字が狂う3つの原因
比較のつもりが比較になっていない、という失敗をしやすい箇所がある。筆者が踏んだ順に挙げる。
同じセッションを使い回す。2回目以降は前の会話が文脈に残っているので、後から測ったモデルほど有利になる。毎回新しいセッションで始める。
プロンプトキャッシュの当たり外れ。同じ入力を短時間に繰り返すと入力トークンの課金が下がる。キャッシュが効いた回と効かない回を並べて平均すると、実態から離れた数字が出る。
作業ツリーが汚れている。前の試行が残したファイルがあると、次のモデルは「もう半分できている状態」から始める。計測ごとにブランチを切り直すか、git stash で戻す。
1M コンテキストは全部入れるための枠ではない
1M トークンが既定になったので、リポジトリごと放り込む使い方が技術的には可能になった。入力も課金対象で、$5/100万トークンは「1回のリクエストで最大 $5 使える」という意味でもある。
筆者が1M枠を使う判断をするのは、分割すると答えが変わる作業のときだけだ。設計の一貫性を見るレビュー、複数ファイルにまたがる移行、長いログの突き合わせ。「この関数を直す」類は、関連ファイルだけ渡したほうが速いし安い。文脈を増やすほど賢くなるわけではない。
効果の切り替え（low / medium / high）も同じ考え方で決められる。定型の置換や書式直しは low で足りる。設計判断や原因不明のバグ調査は high に上げる価値がある。全部を high にすると、思考トークンぶんの請求が全依頼に乗る。
fast mode の使いどころも同じ発想で切り分けられる。人が画面の前で待っている作業（対話しながらの設計・デバッグ）は倍額を払う価値があり、待っていない作業（夜間の一括処理・定期ジョブ）は通常版でいい。Claude Mission Control のように複数エージェントを並べて回す構成だと、この差が請求額にそのまま効いてくる。
筆者ならこう扱う
常に最上位モデルを指名する運用はしていない。設計で詰まったときだけ上位に上げ、実装は下位に任せる形を既定にしている。今回の載せ替えでも、この方針自体は変えていない。変えたのは基準値のほうだ。
よく使う3種類の依頼（テスト修正・小さな機能追加・設計レビュー）について、Opus 5 での総トークンと所要時間を取り直して手元のメモを更新した。基準値が古いままだと、上位に上げるかどうかの判断が去年の感覚で行われる。
もうひとつ決めたのは、fast mode を既定にしない基準を明文化したことだ。速いモデルは体感が良いので、放っておくと全部そちらに寄る。倍額の根拠を「人が待っているか」に固定しておくと迷わない。バイブコーディングの方法論で書いたとおり、AIの出力は読んでから受け取る前提なので、読む速度を超えて生成が速くなっても得はしない。
モデルを指定する場所を1箇所に決める
Claude Code はモデルの指定を複数の場所から受け取る。起動時の引数、設定ファイル、プロジェクトごとの設定、対話中の切り替え。優先順位を把握していないと、「指定したはずなのに別のモデルで動いていた」が起きる。
| 指定する場所 | 効く範囲 | 向いている用途 |
|---|---|---|
--model 引数 |
その1回の実行だけ | 比較計測・無人ジョブ |
| プロジェクトの設定おすすめ | そのリポジトリでの作業 | チーム・長期プロジェクトの既定 |
| ユーザー全体の設定 | すべてのプロジェクト | 個人の好みの既定値 |
| 対話中の切り替え | そのセッション内 | 難所だけ一時的に上げる |
筆者はプロジェクト単位で既定を決め、難所だけセッション内で上げる形にしている。ユーザー全体の設定に強い指定を書くと、軽い用事のリポジトリまで上位モデルで動いて、気づかないうちに費用が乗る。
計測のときだけは引数で明示する。設定ファイルを書き換えて測ると、測り終えた後に戻し忘れる。戻し忘れは、次の請求書を見るまで気づけない類の事故になる。
効果の切り替えをどこで使うか
low / medium / high の切り替えは、モデル選択とは別の軸になる。同じ Opus 5 でも、考える量を変えられる。筆者の割り当てはこうしている。
| 効果 | 回す作業 | 判断の基準 |
|---|---|---|
| low | 書式直し・定型の置換・コミットメッセージ | 正解が1つに決まっていて、探索が要らない |
| medium | 小さな機能追加・テスト修正 | 手順は見えているが、細部の判断が要る |
| high | 設計レビュー・原因不明のバグ・移行計画 | どこから手を付けるかの探索が中心 |
全部を high にすると、思考ぶんのトークンが全依頼に乗る。書式直しに深い思考が要らないのは、人間がやる場合と同じだ。
よくある疑問
Opus 4.8 に戻せるか。モデルIDを明示すれば指定できる。比較の基準として旧モデルを残しておくと、次の載せ替えでも同じ物差しが使える。
1M コンテキストだけ目当てに上げる価値はあるか。扱う入力が数十万トークンに届いていないなら、枠の広さは効かない。手元の実作業でどれだけ入力しているかを claude usage で1週間ぶん見てから決めればいい。
ベンチマークの順位は選定の根拠になるか。開発元の主張として参考にはなる。自分の課題と評価軸が一致している保証はないので、筆者は手元の3種類の依頼の結果を優先している。
まとめ
同じ価格で上位モデルに載せ替わったときにやることは、料金表の比較ではない。自分がよく出す依頼を3種類選び、総トークン・所要時間・成否を測り直して基準値を更新する。これをやっておくと、次のモデルが出たときも同じ物差しで比べられる。
手元のプロジェクトで1つだけ試すなら、テスト失敗の修正がいい。成否がテストの結果で機械的に決まるので、判断がぶれない。
一次ソース: Introducing Claude Opus 5（Anthropic） / What’s new in Claude Opus 5（Claude Platform Docs）
