Claude Media
Claude Opus 5のeffort使い分け — low・medium・highの違いと選び方

Claude Opus 5のeffort使い分け — low・medium・highの違いと選び方

Opus 5のeffortはlow・medium・highをどう選ぶか。lowは単純作業向け、既定はhigh、難所だけxhighに上げます。Opus 5.5の既定mediumとの違いも載せました。

Opus 5のeffortは、単純な処理にlow、日常の作業にmedium、難しい推論やコーディングに既定のhigh、と使い分けます。lowは単純なタスクと高頻度の呼び出し向けで、mediumは速度・コスト・品質の釣り合いを取る段階です。Opus 5.5の既定はmediumです。

Claude Opus 5では、lowとmediumのeffortが「知性を削ってコストを抑える」帯から「品質を保ったままコストを抑える」帯に変わりました。Claude CodeではOpus 4.7の既定effortがxhighでしたが、Opus 5の既定はhighです。前のモデルのeffort設定を引き継いでいるなら、測り直すようAnthropicは促しています。

この記事は、APIでclaude-opus-5を指定し続ける読者に向けて、Opus 5のeffortを決める順序と、下げてよい場面・上げる場面の判断軸を書いています。現行のOpusはOpus 5.5(既定はmedium)ですが、Opus 5の扱いは変わりません。乗り換えるときの違いは、後半の1節で比べます。effortというパラメーター自体の仕組みはClaude effortの使い分けガイドにあります。

どのeffortから始めればよいか

output_config.effortにはlow / medium / high / xhigh / maxの5段階があり、値を上げるほど思考が深くなり、トークン消費とレイテンシーが増えます。Opus 5のAPI既定値はhighです。推奨の順序は、既定のhighから始め、自分のevalで測りながら動かすことです。

手順

Opus 5でeffortを決める順序

  1. 1

    high から始める

    既定値のまま、自分のevalで基準の品質を測ります。前のモデルの設定を引き継いでいるなら、その値のまま使わず、effortのスイープをやり直します。

  2. 2

    単純な処理を low / medium に落とす

    品質が保たれるなら、下げるほどトークンとレイテンシーが減ります。lowとmediumはコスト・応答時間の「主要な操作手段」として積極的に使う位置づけです。

  3. 3

    難所だけ xhigh に上げる

    要求の厳しいコーディングやエージェント作業に上げます(例: マルチファイルの機能追加、大規模リファクタ)。maxはトークン消費に制約を設けたくないときの選択肢です。

  4. 4

    thinkingを切るなら high 以下にする

    thinkingを切る場合の条件は、後段の「thinkingを切るときの制約」にあります。

low・medium・highの違いと、使えないと感じたとき

3段階の役割は、公式の表では次のように分かれます。

  • low: 速度とコストを最優先する段階で、サブエージェントのような単純な処理に向く。能力は多少落ちる
  • medium: 速度・コスト・性能の釣り合いを取る段階で、エージェント作業の中心に置きやすい
  • high: Opus 5のAPI既定値。複雑な推論や難しいコーディングに向く

mediumとhighで迷うときは、highで品質を測り、同じevalでmediumが保たれるかを見ます。保たれる範囲が、mediumに落としてよい仕事です。

「Opus 5が使えない」と感じる原因がlowの浅い推論なら、プロンプトを足す前にeffortを一段上げる手があります。effortは、モデルがどれだけ考えるかを決める設定だからです。

lowでも品質が保たれる根拠はどこにあるか

公式が名前を挙げている代表例が、コードレビューとバグ検出です。Opus 5は精度と再現率がともに高く、追加の指摘の大半は誤検知ではなく実際の問題です。この精度は低いeffortでも保たれるので、レビューを高速パスと精査パスの2段階に分け、最初のパスをlowやmediumで回す設計が成り立ちます。

同じ節にはもう1つ注意があります。レビュー用のプロンプトに「重大度の高い問題だけ報告する」「控えめに」と書くと、モデルがそれを文字どおりに受け取って報告を減らすことがあります。全件を報告させ、絞り込みは別のパスで行うのが公式の勧めです。

Opus 5.5へ移るとeffortの既定はどう変わるか

Opus 5のモデル概要ページでは、Opus 5は旧世代の提供モデル、現行のOpusはOpus 5.5という扱いです。Opus 5を使い続けるあいだの設定は変わらず、移るときだけ次の違いが効きます。

くらべる

Opus 5 と Opus 5.5 の既定

旧世代

Opus 5

API既定のeffortはhigh。料金は入力$5・出力$25(100万トークンあたり)。thinkingはhigh以下なら無効化できます。

現行

Opus 5.5

API既定のeffortはmedium。料金は入力$4・出力$20。adaptive thinkingは常時オンで、thinking: {"type": "disabled"}はどのeffortでも400エラーです。

Claude Codeの公式ドキュメントによると、Anthropicの検証(コーディングと知識労働のeval)でOpus 5.5のmediumはOpus 5のhighと同等以上でした。一方で、同じ段階名でもOpus 5.5のほうが1ターンあたりに多く考える傾向があります。Opus 5から移るときは、Opus 5で使っていた段階をそのまま持ち込まず、mediumから測り始める流れです。段階名は世代をまたぐ固定の絶対値ではなく、モデルごとに校正されています。

Sonnet 5にも同じ性質が見えます。Sonnet 5の解説には、mediumはSonnet 4.6のhighに、highはSonnet 4.6のmaxに相当するという移行時の目安があり、ベンチマークでは段階名でなく観測された思考の長さで揃えるよう添えています。Opus 5.5への移行手順の全体はClaude Opus 5.5の記事を参照してください。Opus 5.5のeffortごとの点差と費用はSWE-bench Proの実測値にまとめています。

Claude Codeで指定するときの挙動

Claude Codeのセッションでは、--effortフラグか/effortコマンドでeffortを指定します。v2.1.285でclaude --helpを実行すると、フラグの説明は次のように出力されます。

--effort <level>    Effort level for the current session
                    (low, medium, high, xhigh, max)

指定がないときにどの値が使われるかは、Claude Codeの設定ドキュメントに解決順が書かれています。①環境変数CLAUDE_CODE_EFFORT_LEVEL・--effort・セッション中の/effort、②設定ファイルに保存した値、③モデルの既定値、の順です。③の既定値は、Opus 5とSonnet 5を含む多くのモデルでhighで、Opus 5.5とSonnet 5.5はmedium、Opus 4.7はxhighです。

つまりモデルを切り替えると、effortを指定していなければ既定値も変わります。よくある落とし穴はeffortLevelキーです。旧形式のユーザー設定effortLevelはOpus 5やFable 5.1以前のモデルには効き続けますが、Opus 5.5には効きません。Opus 5.5は、/effortや/modelピッカーで選ぶまで自分の既定値(medium)で始まります。プロジェクト設定・ローカル設定・管理設定・--settingsで渡したeffortLevelは全モデルに効きます。

そのほかに、知っておくと迷わない挙動が3つあります。

  • モデルが対応しない段階を指定すると、指定以下で最も高い対応段階に落ちます(xhighはOpus 4.6ではhighとして動く)
  • maxは環境変数で指定しない限り、現在のセッションにだけ適用されます
  • 管理者はmaxEffortLevelの管理設定で、組織のeffortに上限をかけられます

同じ公式ドキュメントはmaxについて、収穫逓減や過剰思考に陥りやすいので広く採用する前に検証するよう書いています。ultracodeは段階ではなくClaude Codeの設定で、実質的なタスクごとに動的ワークフローを計画させるものです。--effort ultracodeはセッションをxhighで始めます。

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

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

判断軸low/mediumxhigh/max
タスクの難度low/medium単純な参照・分類・短いスコープの編集xhigh/max要求の厳しいコーディングやエージェント作業(例: マルチファイルの機能追加、大規模リファクタ)
コスト・レイテンシーlow/mediumサブエージェントや高頻度呼び出しで積み上がるxhigh/max1回あたりの正確性がコストより優先される
検証手段low/mediumevalで品質維持を確認済みxhigh/maxevalで劣化が確認された、または前例のない難問

xhighとmaxを使うときは、max_tokensを大きく取る必要があります。effortのドキュメントでは、Opus 5でxhighかmaxを回すなら64kトークンから始めて調整するのが妥当な既定です。max_tokensは思考と応答テキストを合わせた出力の上限だからです。

Sonnet 5の解説は、low/mediumについて「求められた範囲に仕事を絞り、余計なことをしない」性質を指摘しています。中程度に複雑なタスクをlowで回すと浅い推論になるおそれがあり、その場合はプロンプトで誘導する前にまずhighかxhighへ上げるのが推奨です。

Opus 5には逆向きの注意があります。Opus 5のプロンプト解説の「Task scope and over-verification」では、Opus 5は頼まれていない手順を足して、タスクの範囲を広げることがあるとされています。狭いタスクを任せるときは、範囲をプロンプトで明示します。検証指示の外し方はOpus 5のプロンプトから検証の指示を外す方法にあります。

サブエージェントの分業にeffortを当てる

Opus 5はSonnet 5と同じくadaptive thinking(モデルが自律的に思考の深さを決める仕組み)が既定でオンです。サイバーセキュリティ関連のリクエストでは、Opus 4.8へ自動で切り替わることがあります(詳細はClaude Opus 5のモデル切り替え)。

Opus 5は独立した大きな作業を複数のサブエージェントへ振り分けるのが得意な一方、小さな作業まで委任するとコストと時間が増えるだけです。委任に上限をかけるなら、Claude CodeではCLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTHとCLAUDE_CODE_MAX_CONCURRENT_SUBAGENTSの環境変数と、SDKのmax_budget_usdが使えます(Claude Code 2.1.217以降)。

effortの観点では、サブエージェントごとに段階を変える設計が考えられます。単純な調査や要約を担う側はlow/mediumに絞り、統合と意思決定を担う本体だけxhighに寄せる形です。これはドキュメントの記述から導いた設計案で、各段階の効果は自分のevalで測る前提です。

thinkingを切るときの制約

effortを下げる代わりにthinkingを切ろうとする人がいますが、Opus 5ではthinking: {"type": "disabled"}を使えるのはhigh以下のeffortのときだけです。xhighやmaxと組み合わせると400エラーになります。旧来のthinking: {"type": "enabled", "budget_tokens": N}はOpus 4.7以降のモデルで削除済みで、400エラーを返します。トークン予算による制御はeffortに置き換わっています。

推奨は、thinkingを切らずに、effortを下げてコストを抑える方向です。ほとんどのタスクでは、thinkingを有効にしたlowのほうが、同程度のコストでthinkingを無効にしたときより性能が上です。thinkingを無効にすると、2つの副作用が表に出ることがあります。

  • ツール呼び出しが構造化されたtool_useブロックにならず、応答テキストとして書かれてしまう。呼び出しは実行されず、エージェントのループでは履歴に残って以降のターンに響く
  • <thinking>などの内部XMLタグが応答に混入する。システムプロンプトに「考えるな」と指示していると、混入が増える

thinkingを切ったまま運用する必要があるなら、システムプロンプトに1文を足す手があります。ツール呼び出しの前に一言添えてよいと許可し、合うツールがなければ推測せずそう述べさせ、内部タグを出さないようにする内容です。タグ名を名指しした指示は効果が弱めです。

Sampling系の指定にも注意が要ります。temperature・top_p・top_kに既定値以外を渡すと、Opus 4.7以降のモデルは400エラーを返します。Opus 5もOpus 5.5もこの対象です。Sonnet 5も同じです。移行ガイドは、これらをリクエストから外し、プロンプトで挙動を導くよう書いています。

effortが制御しないもの

effortを下げれば応答も短くなる、とは限りません。effortが制御するのはモデルがどれだけ「考える」かで、どれだけ「話す」かではありません。応答の長さを変えたいときは、プロンプトで明示的に指示します。

Opus 5は既定のユーザー向け応答が前モデルより長く、エージェント作業中も「これから何をするか」を逐一説明しがちです。例示されている抑え方は、最初のツール呼び出しの前に一文で述べさせ、重要な発見や方針転換のときだけ更新させる、という頻度と形の指示です。

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

ディスクへ書き出すレポートや文書も、会話の冗長さとは別に長くなりやすいので、「必要な分量に絞り、余計なセクションや定型の要約で水増ししない」という指示を別に添えます。自己修正の言及も多めなので、ユーザーのコードや結論を変える誤りだけ訂正を述べさせる指示が公式に載っています。

実装での指定方法

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はadaptive thinkingがオンで動きます。会話の途中でeffortを変えたいときは、メッセージ単位のoutput_configで指定する方法があり、プロンプトキャッシュが保たれます。これはベータ機能で、ベータヘッダーmid-conversation-output-config-2026-07-01が必要です。ベータ機能に対応しないモデルでこの指定をすると400エラーになります。

まとめ

Opus 5でコストを削るなら、thinkingを切るよりlow/mediumへ下げるほうが効きます。Opus 5.5へ移る日が来たら、段階名を持ち込まずmediumから測り直します。モデル全体の料金や仕様はClaude Opus 5の使い方と仕様にまとめています。

この記事を共有:XはてブLinkedIn