effortダイヤルは、上げるほど良いわけではない
Claude の「effort（思考の深さ）」は、これまで上げれば上げるほど賢くなると考えられてきました。しかし Opus 5 では、コーディング系タスクでeffort を high 超（xhigh・max）まで上げるとスコアがむしろ下がるケースが確認されています。「迷ったら max」で運用しているチームは、いま見直しどきです。
「上げるほど良い」が
崩れた瞬間
Claude には effort という、思考の深さを調整するパラメータがあります。上げるほど時間とトークンを使って粘り強く考える仕組みで、Opus 4.8 世代までは「複雑なタスクほど effort を高く」が定石でした。実務では「迷ったら max にしておけば安全」という運用も珍しくありませんでした。
2026年7月24日、Opus 4.8 の後継として登場した Claude Opus 5 は、この前提を覆しました。Anthropic 公式のMigration Guideは「ほとんどのタスクで high をデフォルトにすべき。これは Opus 4.8 で xhigh を使っていたワークロードも含む」と明記しています。モデル本体の素の性能が上がった結果、以前より低い effort で同水準、あるいはそれ以上の結果に届くようになったのです。
さらに踏み込んだ論点があります。コーディング系タスクでは、effort を high からさらに xhigh・max へ上げるとスコアがむしろ下がる場合があることが同ガイドで示されています。「思考量は多いほど良い」という Opus 4.8 時代の素朴な直感は、Opus 5 では単純には成立しません。
| Opus 4.8 時代の運用 | Opus 5 で見直すべき点 |
|---|---|
| 迷ったら effort は max に固定 | タスクごとに high を起点として検証 |
| 複雑なコーディングは xhigh 推奨 | high で同等以上に到達する場合が多い |
| effort は上げるほど安全という前提 | xhigh・max は過剰検討でスコア低下の恐れ |
5段階のダイヤル、
今どこに置くべきか
Opus 5 が公開する effort レベルと、公式ガイドが示す新しい目安。
What's new in Claude Opus 5 でも effort の使い分けが明記されており、公式ガイドは max について次のように注意を添えています——「トークン消費より最大の能力が重要な場面で max を試すこと。最も要求の厳しいタスクでは効果が出る一方、トークン消費が増えても伸びが鈍化しやすく、簡単なタスクでは考えすぎ（overthinking）に陥りやすい」。
つまり max は「常に最善」ではなく、「使いどころを選ぶオプション」として再定義されたということです。
エンジニアとPM、
それぞれの実害
effort の固定運用は、職種によって効いてくる場所が違います。
開発チーム
コーディングエージェントや自動レビューの effort を一律 max に固定していないか確認してください。Opus 5 ではその設定が、レビュー通過率やテスト成功率をむしろ下げている可能性があります。CI パイプラインの effort 指定は要棚卸しです。
PM・プロダクト責任者
effort を上げるほどレイテンシとトークン課金は増えます。「精度のために常に max」という社内ポリシーは、コスト超過と応答遅延を招くだけでなく、タスクによっては品質でも損をする組み合わせになり得ます。SLA とコスト試算をあわせて見直すタイミングです。
まず、この3つを
自分のevalでeffortを測り直す
Opus 4.8 向けに調整した設定をそのまま引き継がず、low〜max の5段階を自社のタスクセットで再ベンチマークします。公式ガイドも「以前のモデル用に調整した設定を引き継ぐのではなく、自分のevalで新たに効果を測る」ことを推奨しています。
コーディング系はhighを起点にする
特別な理由がない限り、コーディングタスクの effort は xhigh・max 固定をやめ、high を既定値として運用を始めます。
max運用はログで検証する
max を使い続ける箇所は、トークン消費・レイテンシ・実際のタスク成否を記録し、費用対効果を定点観測します。効果が出ていない max はコストの無駄です。
以前のモデル向けに調整した設定を
そのまま引き継ぐのではなく、自分たちのevalで
effortを測り直す。
「maxを使うな」ではない
注意しておきたいのは、これが「effort は低いほど良い」という単純な逆転ではないという点です。Anthropic 公式ガイドの記述はあくまで定性的な推奨で、high 超でスコアがどの程度下がるかを示す公開ベンチマーク表は出ていません。低下傾向の有無や大きさはタスクの種類やプロンプト設計によって変わり得るため、実際の影響は各チームが自分たちのevalで確認する必要があります。
ガイド自身も「最も要求の厳しいタスクでは max が効果を出す場合がある」としており、max=常に悪という単純化も誤りです。effort の最適値はワークロード依存であり、今回の教訓は「一律 max」という思考停止をやめ、タスクごとに検証する運用へ切り替えることだと捉えるのが妥当です。