Claude Opus 5 に上げる前の 5 項目チェック — 実測データつき
Claude Opus 5 が 2026-07-24 にリリースされました。モデル名を差し替えるだけの移行だと、動いていたコードが壊れます。
この記事は「何がすごいか」ではなく、切り替える前に確認する 5 項目だけを扱います。各項目に、公式ドキュメントの根拠と自分で測った数値を付けました。
TL;DR
| # | 確認すること | 見落とすとどうなるか |
|---|---|---|
| 1 |
max_tokens を見直す |
思考が既定でオンになり、出力が途中で切れる |
| 2 | thinking 無効 × effort の組み合わせを確認する |
xhigh / max との併用は 400 エラー
|
| 3 | 「検証して」系の指示を消す | 出力が 2.3 倍。成果物は変わらない |
| 4 | effort を選び直す | Claude Code は Opus 5 だけ前の設定を引き継ぐ |
| 5 | 会話の途中で effort を変えない | キャッシュが壊れて料金が 12.5 倍 |
いちばん効くのは 3 です。公式が名指しで「消せ」と書いている指示が、多くのプロンプトに残っています。
検証環境: claude-opus-5 / Claude Code v2.1.219 / 2026-07-25 実測。詳しい検証条件と考察は Zenn 版 に書きました。
上げたモデルで実際に業務を回している側 — 50 案件の進捗確認を Claude に任せている運用のプロンプト 4 本の全文と、動くコード一式・セットアップ手順は、note の実践パッケージ（¥1,480〜）にまとめています。
1. max_tokens を見直す — 出力が途中で切れる
Opus 4.8 では、thinking の指定がなければモデルは考えずに答えていました。Opus 5 は既定で考えます。
公式の移行ガイドにこうあります。
max_tokensremains a hard limit on total output, thinking plus response text, so revisit it for workloads that ran without thinking on Claude Opus 4.8.
（max_tokensは思考と回答テキストを合わせた総出力に対する上限のままなので、Opus 4.8 で思考なしで動かしていた処理では見直すこと）
max_tokens は「回答の長さの上限」ではなく、思考 + 回答の合計の上限です。これまで 0 だった思考の分が、いきなり上限を食い始めます。
実測
max_tokens: 2000・thinking 指定なしという、Opus 4.8 時代のよくある設定のまま、モデル名だけ差し替えました。
| 停止理由 | 出力トークン | 思考 | 回答の長さ | |
|---|---|---|---|---|
| Opus 5 |
max_tokens（打ち切り） |
2,000（上限到達） | あり | 1,124 文字 |
| Opus 4.8 |
end_turn（正常完了） |
682 | なし | 803 文字 |
同じリクエストです。停止理由が end_turn（言い終わった）から max_tokens（上限で止められた）に変わる = アプリから見ると回答が尻切れで返ってきます。
対処: xhigh / max を使うなら 64k 以上が公式の出発点です。
2. thinking 無効 × effort の組み合わせを確認する
思考を切ること自体は今もできますが、条件が付きました。
You can still turn thinking off with
thinking: {type: "disabled"}, but only at an effort level ofhighor below. A request that combinesthinking: {type: "disabled"}with effortxhighormaxreturns a 400 error.
（thinking: {type: "disabled"}で思考を切ることはできるが、effort がhigh以下の場合に限る。xhighまたはmaxと組み合わせたリクエストは 400 エラーを返す）
実際に投げると、こう返ります。
HTTP 400 invalid_request_error
output_config.effort 'xhigh' is not supported when thinking is disabled
on this model. Use effort 'high' or below, or enable thinking.
3 条件で確かめました。
| モデル | thinking | effort | 結果 |
|---|---|---|---|
| Opus 5 | 無効 | xhigh |
HTTP 400 |
| Opus 5 | 無効 | high |
HTTP 200 |
| Opus 4.8 | 無効 | xhigh |
HTTP 200（4.8 では通っていた） |
検証はリクエストごとに独立して走るので、会話の途中で effort を上げた瞬間に落ちます。
対処: 思考を戻すか、effort を high 以下に下げるか。公式は前者を勧めています（思考を切ると、ツール呼び出しがテキストに漏れる・<thinking> タグが出力に混ざる、という副作用があるため）。
3. 「検証して」系の指示を消す — 出力が 2.3 倍になる
ここがいちばん効きます。公式が名指しで削除を指示しています。
If your prompt contains explicit verification instructions ("include a final verification step for any non-trivial task," "use a subagent to verify"), remove them: instructions like these cause over-verification on Claude Opus 5, and removing them reduces wasted tokens with no loss in quality.
（プロンプトに明示的な検証指示（「自明でないタスクには最後に検証ステップを入れること」「サブエージェントを使って検証すること」）が含まれているなら、消すこと。この種の指示は Opus 5 では過剰検証を招き、消しても品質を落とさずに無駄なトークンを減らせる）
消す対象はこれです。
- 「最後に検証ステップを入れて」
- 「サブエージェントで検証させて」
- 「答えをダブルチェックして」
- 「返答前に再確認して」
理由は、Opus 5 が言われなくても自己検証するから。指示を重ねると同じ作業を 2 回やらせることになります。
実測
3 つのタスク（要約 / 会議メモからの抽出 / CSV → JSON 変換）を、素のままと「検証ステップを入れて、ダブルチェックして」を足した場合で、各 3 回ずつ比較しました。
| タスク | 素のまま | 検証指示あり | 増加 |
|---|---|---|---|
| CSV → JSON 変換 | 303 tok | 555 tok | +83% |
| 会議メモから抽出 | 558 tok | 1,132 tok | +103% |
| 文章を 3 行に要約 | 188 tok | 741 tok | +294% |
| 平均 | 350 tok | 810 tok | +131% |
所要時間も約 2 倍です（要約: 3.8 秒 → 10.5 秒）。
では品質は上がったのか。 ここが肝心なので成果物を突き合わせました。
CSV → JSON は正解が一意に決まるタスクです（カテゴリ A = 15、B = 12）。結果は6 回すべて正解。検証指示ありの回は検算の内訳が加わっただけで、成果物は同一でした。
要約タスクは差が分かりやすいです。
- 素のまま: 165 文字の要約 3 行
- 検証指示あり: 715 文字。要約の中身は同じで、後ろに 550 文字の検証レポート（対応表 7 行 + チェックリスト 4 項目 + 「事実の欠落・改変はないと判断します」）
3 行の要約を頼んで、要約の 3 倍の分量の点検レポートが付いてきます。 出力単価 $25 / 100 万トークンで、1 リクエストあたり約 460 トークンの上乗せ。日に 100 回動かすなら月 $35 前後です。
レビュー用途の落とし穴 — 「重大なものだけ」と書くと、本当に減る
コードレビュー・設計書レビュー・文書チェックに AI を使っている人向けに、もう 1 つ。ここは公式の記述で、自分では実測していませんが、影響が大きいので取り上げます。
If your review prompt says "only report high-severity issues" or "be conservative," the model may follow that instruction literally and report less; ask it to report everything and filter in a separate pass instead.
（レビュー用プロンプトに「重大な問題だけ報告して」「保守的に判断して」と書いてあると、モデルはその指示に文字通り従って報告を減らすことがある。代わりに、すべて報告させて別のパスでフィルタすること）
何が起きるか。
レビューを頼むとき、こう書いた経験はないでしょうか。
- 「重大な問題だけ報告して」
- 「細かい指摘はいらない、致命的なものに絞って」
- 「保守的に判断して」
どれもノイズを減らすつもりの一文です。指摘が 30 件返ってきて全部読む気が失せた経験があれば、自然に書きたくなります。
ところが Opus 5 はこれを、報告する内容のフィルタではなく**「重大かどうかを判断する基準そのものを上げろ」**という指示として受け取ることがあります。結果、拾えていたはずの問題が、そもそも出力に現れません。
厄介なのは、減ったことが見えない点です。
レビュー結果が「重大な問題は見つかりませんでした」で返ってきたとき、それが
- 本当に問題がない
- 基準を上げたせいで出てこなかった
のどちらなのか、受け取った側からは区別がつきません。見落としが、成果に見えてしまいます。 30 件の指摘なら「多いな」と分かりますが、0 件の見落としは静かです。
対処: 判断を 2 回に分ける。
公式の「すべて報告させて、別のパスでフィルタする」を具体化すると、こうなります。
1 回目: 「気づいたことを、重要度を問わずすべて挙げてください。
重要度の判定はしなくて構いません」
2 回目: (1 回目の出力を貼って)
「この中から、リリースを止めるレベルのものだけ選んでください。
選ばなかった理由も一行ずつ書いてください」
ポイントは、絞り込みの基準を、モデルの中ではなく自分の手元に置くことです。2 回目で「選ばなかった理由」まで書かせると、外した判断が妥当かを自分で点検できます。1 回目の全件リストが手元に残るので、後から「あれは本当に無視してよかったか」と戻ることもできます。
トークンは余計にかかりますが、この項目 3 の話（検証指示を消すと出力が半分以下になる）で浮いた分を、こちらに回すくらいでちょうどよいはずです。
補足: レビューの精度が「頼み方」でどれだけ動くかは、別記事で実測しています（設計書に欠陥 7 個を仕込んで、素朴に頼むと検出 0 個、役割を 3 つに分けて頼むと 6 個）。あちらはブラウザ版 Claude の Sonnet 5 での実測で、Opus 5 では測り直していません。ただ「指示の書き方ひとつでレビューの出力が大きく動く」という点は、モデルが変わっても共通でした。
4. effort を選び直す — Claude Code は Opus 5 だけ引き継ぐ
effort は「どれだけトークンを使って考えるか」を 5 段階（low / medium / high / xhigh / max）で指定するパラメータです。既定は high。
公式はこう書いています。
If you carried effort settings over from an earlier model, run a fresh effort sweep on your evals rather than reusing them.
（以前のモデルから effort 設定を持ち越しているなら、それを再利用せず、自分の評価セットで振り直しを実行すること）
ところが Claude Code 側のドキュメントには、こうあります。
When you first run Fable 5, Opus 4.8, or Opus 4.7, Claude Code applies that model's default effort even if you previously set a different level for another model... Opus 5 has no such hold: a level you previously set carries over.
（Fable 5、Opus 4.8、Opus 4.7 を初めて使うとき、Claude Code は他のモデルで別のレベルを設定していたとしても、そのモデルの既定 effort を適用する。Opus 5 にはこの保持がなく、以前に設定したレベルがそのまま引き継がれる）
他のモデルは「前の設定を無視して既定に戻す」のに、Opus 5 だけは前の設定をそのまま持ってきます。「持ち越すな」と言われている当のモデルが、Claude Code では唯一、自動で持ち越す側になっています。
実測: 5 段階の違い
同じ質問を 5 段階で各 3 回、max_tokens: 16000 で実行しました。
表の 2 列を分けている理由を先に書いておきます。出力トークンは「思考 + 回答」の合計で、料金はこちらで決まります。回答の文字数は、画面に実際に表示された文章の長さです。思考の部分は課金されますが、読者の目には触れません。
| effort | 出力トークン（思考 + 回答） | 画面に出た回答の文字数 | 所要秒 |
|---|---|---|---|
low |
2,142 | 1,944 | 45.3 |
medium |
2,350 | 1,961 | 46.8 |
high（既定） |
3,988 | 2,877 | 74.4 |
xhigh |
4,889 | 3,175 | 90.2 |
max |
5,288 | 3,361 | 97.0 |
low と medium がほとんど同じでした（2,142 対 2,350 トークン、45.3 対 46.8 秒）。このタスクに関する限り、medium を選ぶ理由は見当たりません。コストを下げる目的なら low まで落とす方が効きます。
なお公式は「effort は思考量の制御であって、回答の長さは確実には短くならない」と書いていますが、実測では画面に出る回答の文字数も +73% 伸びました（1,944 → 3,361 字）。出力トークンの伸び（+147%）の方が大きいので、増えた分の多くは思考に使われていますが、読者の目に触れる部分も一緒に長くなっています。
つまり effort を下げるとコストと時間が減るだけでなく、回答も短くなる（少なくともこのタスクでは）。逆に言えば、長さを確実に制御したいなら effort ではなくプロンプトで指定する、という公式の結論自体は変わりません。
対処: Claude Code なら /effort を一度実行して選び直す。
5. 会話の途中で effort を変えない — キャッシュが 12.5 倍のコストになる
Because effort shapes the rendered prompt, changing it between requests does not preserve cached prefixes from earlier turns; if you rely on prompt caching across a long session, pick an effort level at the start and keep it constant.
（effort はプロンプトの構築に影響するため、リクエスト間で変更すると以前のターンのキャッシュ済みプレフィックスが保持されない。長いセッションでプロンプトキャッシュに依存しているなら、最初に effort を決めて一定に保つこと）
プロンプトキャッシュは、同じ前置き（システムプロンプトや長い資料）を繰り返し送るときに料金を下げる仕組みです。effort を途中で変えると効かなくなります。
実測
7,521 トークンの前置きをキャッシュさせた状態で 4 回続けて送り、3 回目で effort を high から medium に変えました。
| 回 | effort | キャッシュ書き込み | キャッシュ読み出し |
|---|---|---|---|
| 1 | high | 7,521 | 0 |
| 2 | high | 0 | 7,521（効いている） |
| 3 | medium に変更 | 7,521 | 0（作り直し） |
| 4 | medium | 0 | 7,521（また効く） |
送信内容は 1 文字も変えていません。変えたのは effort の値だけです。
キャッシュの読み出しは通常入力料金の 0.1 倍、書き込みは 1.25 倍。つまり effort を 1 回変えるたびに、同じ前置きに 12.5 倍の料金を払います。前置きが数万トークンある長いセッションで何度も切り替えれば、無視できない額です。
対処: 会話の頭で effort を決めて固定する。
おまけ: 体感がいちばん変わるのは待ち時間
同じ質問を両モデルにストリーミングで各 5 回投げました（effort max）。
| Opus 4.8 | Opus 5 | 倍率 | |
|---|---|---|---|
| 最初の 1 文字が届くまで | 1.00 秒 | 14.79 秒 | 14.8 倍 |
| 最後まで書き終わるまで | 23.78 秒 | 50.45 秒 | 2.1 倍 |
| 回答の長さ | 1,551 文字 | 2,680 文字 | 1.7 倍 |
ばらつきも小さく、Opus 4.8 は 5 回とも 0.87〜1.16 秒、Opus 5 は 11.09〜17.44 秒でした。
Opus 4.8 はほぼ即座に話し始め、Opus 5 は 15 秒黙ってから話し始めます。 「思考が既定でオンになった」ことの、体感としての意味がこれです。対話的に使っていて気になるなら、思考を切るのではなく effort を下げるのが公式の推奨です。
まとめ
上から順に潰せば、この記事の内容はひととおり反映されます。
-
max_tokensを見直した（xhigh/maxを使うなら 64k 以上が出発点） -
thinking 無効 × effort
xhigh/maxの組み合わせがないか確認した - プロンプトから「検証して」「ダブルチェックして」系を消した
- レビュー用プロンプトから「重大な問題だけ報告して」を消した
-
effort を選び直した（Claude Code なら
/effortを一度実行） - 会話の途中で effort を上げ下げしていないか確認した
移行で壊れるものの多くは、「足す」ではなく「引く」ことで直ります。検証しろ、ダブルチェックしろ——どれも過去のモデルには正しい工夫で、だからプロンプトに残っています。Opus 5 では、それが二重になります。
検証条件の詳細、公式ドキュメントの原文引用、Claude Code のプラン別設定（1M コンテキストの課金など）は Zenn 版 に書きました。
出典
この検証の続き: 実測で見つかった点検項目を、月 2 回ほどのメールで配信しています。登録すると、社内文書を AI に読ませる前の点検シートをその場で受け取れます。「自社の文書で実際どこまで測れるのか知りたい」という相談の窓口も、届いた 1 通目のメールでご案内しています → 登録はこちら