Claude Opus 5のeffort使い分け方 — low/mediumでも品質は落ちない

effortはトークン消費と知性のトレードオフを操るパラメーター

effortは output_config.effort で指定するパラメーターで、low / medium / high / xhigh / max の5段階があります。値を上げるほど思考(thinking)が深くなり、トークン消費とレイテンシーが増える代わりに知性が上がる、というのが基本の設計です。effortパラメーターそのものの仕組みはClaude effortの使い分けガイドで解説しています。

Claude Opus 5では、この基本設計は変わっていません。変わったのは低い段階の実力です。従来のOpus系モデルでは、複雑なコーディングやエージェント作業を任せるならxhighが事実上の既定という運用が定着していました。Opus 5の公式ドキュメントは、この前提を明示的に見直すよう促しています。

Opus 5のlow/mediumは「品質を落とさずコストだけ落ちる」帯になった

公式のCapability improvements節は次のように整理しています。lowとmediumのeffortは、より高い段階のトークン数とレイテンシーのごく一部で、強い品質を出す。既定値のhighから始め、evalで測りながら調整し、low/mediumを「品質が保たれる限りコストとレスポンス時間を制御する主要な手段」として積極的に使い、要求の厳しいコーディングやエージェント作業だけxhighに上げる、という順序が推奨されています。

コードレビューとバグ検出はその代表例です。Opus 5は精度・再現率ともに高い水準でバグを見つけ、追加の指摘の大半が誤検知ではなく実際の問題です。この精度は低いeffort設定でも維持されるとドキュメントは述べています。レビューを高速パスと精査パスの2段階に分けるとき、最初のパスをlowやmediumで回しても質を落とさずに済む、という設計です。

前世代のeffort運用をそのまま引き継いだ場合、この記述はモデル移行時の見直しポイントになります。ドキュメントも「前モデルのeffort既定値を引き継いでいるなら、自分のevalでeffortの再検証を行うこと」と明記しています。

なぜ逆転が起きたか — 段階ごとの実力そのものが底上げされた

effortの仕組み自体はSonnet 5と共通です。Sonnet 5の解説では、low/medium/high/xhigh/maxの5段階それぞれの用途が次のように定義されています。

この定義自体はOpus 5でも据え置きです。Sonnet 5側には、移行時のクロスモデル対応の目安として、Sonnet 5のmediumはSonnet 4.6のhigh相当、Sonnet 5のhighはSonnet 4.6のmax相当という換算が示されています。ベンチマーク時は「effortの名前」ではなく「観測された思考の長さ」で揃えるべきだ、という注記も付いています。

Opus系にはここまで具体的な世代間換算の記述はありませんが、公式ドキュメントがlow/mediumを「高い段階のごく一部のトークン・レイテンシーで強い品質を出す」帯として押し出している以上、effortのラベルは世代をまたいで固定の絶対値ではなく、モデルごとに再校正が要ると読めます。「lowだから知性面で妥協する」という前提を疑ってevalで検証し直す価値がある、というのはこのためです。

low/mediumが向く場面、xhighが要る場面

段階を分けて実力が底上げされたとはいえ、xhighが不要になったわけではありません。使い分けの軸は次の3つです。

Sonnet 5側のドキュメントは、low/mediumについて「求められた範囲に仕事を絞り込み、余計なことをしない」性質を指摘しています。レイテンシーとコストには有利ですが、中程度に複雑なタスクをlowで回すと、考え込みが足りない「浅い推論」のリスクがあるとも書かれています。浅い推論が観測されたら、プロンプトで誘導するのではなく、まずhighかxhighに上げるのが公式の推奨です。

エージェント作業・サブエージェントへの効き方

Opus 5はSonnet 5と同じくアダプティブシンキング(モデルが自律的に思考の深さを決める仕組み)が既定でオンになり、Opus 4.8とはモデル切り替えの挙動も変わっています(詳細はClaude Opus 5のモデル切り替え)。effortの観点では、Opus 5はサブエージェントへの委任も判断材料になります。公式ドキュメントは、Opus 5が独立した大きな作業を複数のサブエージェントへ振り分ける精度が高い一方、小さな作業への委任はコストと時間を増やすだけだと注意を促しています。ここでも同じ考え方が使えます。個々のサブエージェントに渡すeffortを一律highやxhighにせず、単純な調査や要約を担うサブエージェントはlow/mediumに絞り込み、統合・意思決定を担う本体だけxhighに寄せる、という段階的な設計です。

Sonnet 5とOpus 5でeffortの効き方はどう違うか

同じeffortパラメーターでも、モデルによって効き方の強さは異なります。Sonnet 5のドキュメントは「Sonnet 5は特に低い側でeffort段階を厳格に守る」と述べ、low/mediumでは求められた範囲だけをこなし、範囲外への気配りはしない、という性質を明記しています。これは予測可能性を求めるAPI用途には好ましい半面、複雑なタスクをlowに落としすぎると浅い推論になりやすいという注意も伴います。

Opus 5のCapability improvements節にはこの種の「厳格さ」への言及はなく、代わりに「low/mediumでも強い品質が出る」という効率面の記述が中心です。同じ5段階のラベルを持つパラメーターでも、Sonnet系は「指示された範囲への忠実さ」、Opus系は「低コストでの実力の高さ」という異なる軸で語られている点は、モデルを使い分ける際に押さえておく価値があります。

制約と注意点

effortにはいくつかの制約があります。第一に、Opus 5でthinkingを完全に無効化(thinking: {type: "disabled"})できるのはhigh以下のeffortのときだけで、xhighやmaxと組み合わせると400エラーになります。thinkingを切って運用したい場合は、まずeffortをhigh以下に下げる必要があります。

第二に、旧来のthinking: {type: "enabled", budget_tokens: N}という固定トークン予算の指定方式は、Opus 5では受け付けられず400エラーを返します。トークン予算による制御は、effortパラメーターに完全に置き換わりました。migrationの際にこの指定方式が残っていないか、コードベースを確認しておく必要があります。

第三に、temperatureやtop_pといったサンプリングパラメーターも、Opus 5やSonnet 5では受け付けられません。出力のばらつきを抑えたい場合は、サンプリングではなくプロンプト側の指示かeffortの調整で対応することになります。

effortが制御しないもの — 応答の長さとナレーション

effortを下げれば応答も自動的に短くなる、と誤解しやすい点にも注意が必要です。公式ドキュメントは、effortパラメーターが制御するのはモデルがどれだけ「考える」かであって、どれだけ「話す」かではないと明確に区別しています。effortを下げても、ユーザーに見える応答の長さが確実に短くなるとは限りません。応答の長さそのものを調整したいときは、effortではなくプロンプト側で明示的に指示する必要があります。

Opus 5は既定のユーザー向け応答が前モデルより長くなる傾向があり、エージェント作業中も「これから何をするか」を逐一説明する、ナレーションの多いスタイルを取りがちです。ナレーションの量を絞りたい場合は、ツール呼び出し前に一言で要約させる、重要な発見や方針転換のときだけ更新するといった、具体的な頻度と形を指示する方法が有効です。

ツール呼び出しの前に、これから何をするか一文で述べてください。作業中は、重要な発見や方針転換があったときだけ簡潔に更新してください。

同様に、ディスクへ書き出すレポートやMarkdown文書のような成果物も、会話の冗長さとは別に長くなりやすいため、「タスクに必要な分量に絞り、余計なセクションや定型の要約で水増ししない」という長さの指示を別途添えるのが有効です。

長時間のエージェント作業でのeffortの位置づけ

自律的に長時間動くコーディングエージェントと、対話しながら都度指示を出すエージェントとでは、同じhighやxhighのeffortでもトークン消費と挙動が変わります。単一ターンで完結させる自律型のコーディング用途では、xhighまたはhighのeffortを使い、Auto modeのような自律機能を組み合わせ、人間とのやり取りの回数を減らすことが、パフォーマンスとトークン効率の両方を高める、という指針が示されています。これは対話的に細かく指示を出すスタイルとは異なる設計判断で、エージェント製品を作る際にeffortだけでなく、ターンの設計そのものを見直す材料になります。

実装での指定方法

effortはoutput_configの内側に置くパラメーターで、トップレベルの引数ではありません。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 16000,
    "output_config": {"effort": "medium"},
    "messages": [{"role": "user", "content": "..."}]
  }'

thinkingパラメーターを省略しても、Opus 5はアダプティブシンキング(モデルが自律的に思考の深さを決める仕組み)がオンの状態で動きます。この既定挙動はOpus 4.8やOpus 4.7から変わった点で、effortはこの思考の深さを調整するレバーとして働きます。

まとめ

Opus 5では、low/mediumのeffortが「知性を犠牲にしてコストを抑える」段階から「品質を保ったままコストとレイテンシーを抑えられる」段階に変わりました。前モデルからの移行では、xhighを既定にする運用をそのまま引き継がず、自分のevalでeffortを再校正することが公式の推奨です。難しいコーディングやエージェント作業には引き続きxhighが有効ですが、それ以外の大半のワークロードでは、highを起点に下げていく順序が合理的です。モデル全体の料金・仕様はClaude Opus 5の使い方と仕様にまとめています。