Sonnet 5.5のeffortはどう選ぶ？medium・high・maxの評価方法

Sonnet 5.5のeffortは品質保証ではなく、評価する設定項目です。 Anthropicは、要件が明確なエージェント型コーディングや複数段階のツール作業ではmediumから始め、難しい作業や長い作業ではhighに上げることを推奨しています。応答時間が重要なチャットにはmediumかlowを挙げています。ネイティブAPIの既定値はhighで、Claude Codeには別の既定値があります。

この推奨は2026年9月29日に確認したSonnet 5.5の動作資料に基づきます。本記事はその釣り合いの調べ方を説明するもので、Ofoxが全effortをベンチマークしたという主張ではありません。

作業を決めてから設定を選ぶ

最後の行は評価の提案であり、xhighやmaxで失敗が解消すると公式に保証されたわけではありません。要件不足、使えないツール、矛盾する指示があれば、どの設定でも解決しない場合があります。

モデルページはAPIの既定をhighとし、Claude Code設定資料は同クライアントでSonnet 5.5をmediumとしています。比較前に入口を記録してください。どちらも「既定のSonnet」と呼んでいても、設定が異なる場合があります。

maxを一律に勧められない理由

Artificial Analysisの公開時評価では、maxの出力トークン消費が多く、一部の代替構成に比べ費用との釣り合いが不利でした。同じレポートは高いベンチマーク能力も示しています。大量のトークンを使って高い結果に到達することはあり、両者は矛盾しません。

この報告は構造化出力のバグがある公開前環境を測定し、関連評価を再実施するとしています。ベンチマーク費用は自分のバグ修正の見積もりではなく、maxの実行がすべて無駄だとも証明しません。費用と品質を一緒に記録する理由として使ってください。

高いeffortでは、見える動作も変わることがあります。関連する仮説を確かめる探索なら役立ちますが、依頼範囲を超えたり無関係な作業に時間を使ったりすると逆効果です。合格基準にはテスト1本の成功だけでなく、作業範囲も含めましょう。

小さな比較実験を設計する

期待出力や合格条件がある代表タスクを用意します。モデル版、ツール、入力、リポジトリの開始状態を固定し、基準設定を実行してから同じタスクで高い・低い設定を試します。最初の試行が次の試行に答えを教えないようにしたい場合は、独立したセッションを使います。

少なくとも次を記録します。

タスク | Effort | 適用設定 | 合格 | 試行回数
経過秒数 | 入力トークン | キャッシュ区分 | 出力トークン
ツール料金 | 合計費用 | 範囲外の編集 | レビュー所見

初回の結果と再試行後の結果を分けます。時間やトークン上限で止めた実行には明示的な印を付け、通常の完了回答として扱いません。失敗も残してください。成功例だけの表では、最も安定した構成は分かりません。

追加費用や遅延に見合うほど重要な結果が改善した場合だけ、高い設定を維持するという判断ができます。結果を見る前に、その基準を定めましょう。たとえば誤ったパッチを減らすことを待ち時間より重視するチームもあれば、チャット製品では逆の場合もあります。他人のベンチマークから万能なしきい値を借りないでください。

無効なリクエストを作らずに設定する

ネイティブAPIのadaptive thinkingでは、次の本文を指定できます。

{
  "model": "claude-sonnet-5-5",
  "max_tokens": 2048,
  "thinking": {"type": "adaptive"},
  "output_config": {"effort": "high"},
  "messages": [{"role": "user", "content": "List the acceptance checks for a CSV parser fix."}]
}

これは資料に沿ったリクエスト本文であり、実APIテストではありません。max_tokensは思考と回答本文の合計を制限します。思考本文が省略されても、そのトークンは出力として課金されます。思考量をその値まで要求する設定でも、すべてを含むドル予算でもありません。認証、バージョンヘッダー、レスポンス処理は別に必要です。

冒頭の思考を無効にするbetween_toolsでは、effortをhigh以下にします。xhighとmaxには対応せず、会話途中のeffort変更にも制約があります。古いdisabledや手動予算設定をコピーする前に移行チェックリストを確認してください。

Claude Codeでは--effort mediumで起動するか、/effortで対応するレベルを選びます。管理設定で実行時の上限が制限される場合があります。クライアントとアカウントの動作を確認せず、要求値と適用値を同一視しないでください。

effort、出力上限、ツール権限を区別する

3 つの設定は別の問題を扱います。effort は推論の度合い、max_tokens は thinking を含む応答 token の上限、ツール権限はアプリが実行できる操作を決めます。effort を上げても存在しないファイルツールや私有リポジトリへの権限は得られません。出力上限を増やしても、矛盾した要件は解消しません。

「CSV の合計を修正してテストする」場合を考えます。ソースと実行可能なテストがあれば、effort は比較すべき変数です。エラー画像しかなくソースを読めなければ、最初に入力を補います。正しいパッチがあるのにテスト実行が拒否されるなら、承認された検証経路を整えます。全部を「max が必要」と扱うと原因が隠れます。

これは編集上の診断枠組みであり、ある effort が必ず課題を解く測定結果ではありません。仕様を改善したら元の失敗も保存します。そうしないと、プロンプト改善の効果を effort の効果と取り違えます。

受け入れられた課題あたりの費用を計算する

同じ 10 課題を 2 設定で試すと仮定します。以下は合成の教材データで、Sonnet の測定値ではありません。medium は全試行に $0.40 を使い、8 課題が合格。high は $0.60 で 9 課題が合格。合格 1 件あたりは $0.40 / 8 = $0.05 と、$0.60 / 9 ≈ $0.0667 です。

この例では high は合格 1 件あたり約 3 分の 1 高くなりますが、1 件多く完了します。価値があるかは完了の重要性と失敗後の処理によります。「medium は 25% 不正確」「high は常に優秀」と結論付けられません。少数の合成データは本番の信頼性を証明しません。

次に medium を全件に実行し、失敗した 2 件だけ high に上げる方針を考えます。その追加試行が計 $0.12 で両方合格すれば、総額 $0.52、10 件合格、1 件 $0.052 です。この計算は段階的な引き上げの有用性を説明するだけで、high がすべての失敗を直す予測ではありません。追加 2 件とも失敗なら、総額は同じ $0.52 でも合格は 8 件のままなので $0.065 になります。

中止や失敗を含め全試行を費用に入れます。ツール料金と人のレビュー時間は単位が違えば分けます。合格ゼロなら比率は未定義であり、$0.00 ではありません。サブスクリプションで信頼できる課題別請求がなければ、観測した使用量と時間を別々に示し、API 料金表から架空の金額を作らないでください。

第三者が再確認できる比較にする

出力を見る前に課題を選びます。コード課題には説明、起点 commit、変更可能ファイル、テストコマンド、成功条件を含めます。文書なら同じソース一式と主張の出典要件を保ちます。製品自体が修復パイプラインである場合を除き、一方だけが他方の回答を先に見ないようにします。

同じ状態から新規会話で各設定を実行します。可能なら順番を交互にし、一時的なサービス状態やキャッシュの温まりで常に後の設定が有利になるのを避けます。キャッシュ状態を記録し、不変と仮定しません。同じ課題の反復は同一課題の試行であり、独立した課題数には加えません。

行ごとに課題 ID、正確なモデルと endpoint、要求 effort、観察可能なら実効 effort、終了理由、時間、使用量区分、再試行、テスト結果、範囲外編集を残します。判定を監査できる応答や diff も保存します。実効設定が API に現れない場合は「独立に観測できない」と書き、要求値を転記して検証済みにしないでください。

平均だけでなく、同じ課題同士の結果を比較します。medium と high が同じ課題に合格したなら、その集合で high の完了率向上は示せません。重要な失敗を high が直す一方、簡単な全課題を遅くするなら、その失敗種別だけを high に送る選択肢があります。曖昧な主観評価 1 件の差だけなら、勝者を決める前に評価を増やすか基準を明確にします。

引き上げと停止の条件を先に決める

範囲が明確なコード課題を medium で始め、推論の失敗と確認できた場合に同じ完全な入力で high を 1 回試し、まだ無効ならレビューで止める、といった方針が考えられます。これは例であり Anthropic の既定動作ではありません。権限不足、非対応パラメーター、入力不足を effort 引き上げの対象にしないと先に決めます。

xhigh や max は、追加の推論が観察した失敗に役立ちそうで、費用と遅延の制約が許す場合に試します。これらには adaptive thinking を使います。between_tools の文書上の最高は high で、会話途中の effort 変更にも制約があります。モードを比べるときは、無効な混在会話を作らず新規の管理された試験にします。

課題単位の停止条件は複数試行を含めます。応答 1 回の token 上限では、何度も呼び出す Agent の総量は制限できません。試行数、経過時間、アプリ予算の上限で停止し、途中成果を保存して上限到達と記録します。最後の文が断定的でも、通常の成功とは数えません。

最終方針には適用範囲を書きます。例えば「検証済みの CSV 修正では medium を基準とし、列挙した失敗に high を評価する」です。普遍的な最良ラベルより役立ち、モデル版や課題構成が変わっても検証できます。

モデル変更も比較する

難しい作業が残る場合は、Sonnetのeffortを上げる方法と別モデルを試す方法を比べます。Claude内の選択はSonnetとOpus、他社との試験はSonnetとSolで説明しています。構成を変えるときも、タスクと合格テストは固定します。

基準構成を選んだら、理由と、設定を上げるべき失敗を記録します。次のモデル更新も評価しやすくなります。Sonnet 5.5のeffortはSonnet 5から再調整されているため、古いラベルをそのまま使っても同じ動作の証拠にはなりません。