Claude Opus 5の「max effort」設定は、日常的なリクエストの価格を0.76ドルから19.21ドルへと跳ね上げますが、得られる機能的な出力は本質的に同じです。追加のコストは、より良いソリューションを買っているのではなく、内部的な監査プロセス（audit pass）を買っているに過ぎず、測定可能な改善が見られるのはテストカバレッジが低い状態から始まるタスクに限られます。
テストの結果
この実験では、日常的なコーディング作業と、意図的に難易度を高めた問題という2種類のプロンプトタイプにおいて、Claude Opus 5のデフォルトの努力レベルと「max effort」設定を比較しました。
- 通常のタスクでは、低努力（low-effort）での実行は2分で終了し、コストは0.76ドルでした。設定を最大（max）に上げると請求額は19.21ドルにまで膨れ上がりましたが、要件充足スコア（requirement-coverage score：モデルが指示にどの程度従えたかを示す指標）は全く同じままでした。
- トランスクリプト（実行ログ）を見ると、「作成」から「修正」へとシフトしていることがわかります。モデルは新しいコードの生成を止め、すでに書いたものを磨き上げる作業に入りました。修正回数は新規作成回数の2.4倍に達しました。「read」ツールへの呼び出しは18倍に増加し、「bash」ツールの呼び出しは6倍に増加しました。実際、モデルは指示されていないにもかかわらず、モジュールの再読み込み、自身のテストの再実行、リンティング、さらにはミューテーションテストまで行っていました。
「max effort」設定は新しいアルゴリズムを導入するものではなく、単にモデルが使用できる予算を引き上げるものです。予算が十分に大きくなると、モデルは自己監査モード（self-audit mode）に切り替わり、追加コストをかける価値があると判断できる微調整を探し始めます。
なぜコストが急騰するのか
モデルが監査を行うと決めた場合、追加の「read」や「bash」の呼び出しがすべて請求額に加算され、その乗数効果によって総コストは急速に膨れ上がります。
監査モードは明示的な設計上の選択です。モデルは、増額された予算を「修正する価値のあるものを見つける」ための許可として扱います。改善の余地がない場合、追加の支出は機能的なメリットをもたらしません。
高い努力レベルが有効なケース
監査モードが真価を発揮するのは、初期の出力に改善の余地がある場合に限られます。テストカバレッジが0.73のGoプロジェクトでは、努力レベルを最大にすることでカバレッジが0.88まで向上しました。
逆に、すでに0.98のカバレッジを達成していたPythonのタスクでは、予算を増やしても変化は見られませんでした。モデルは単に同じ高品質なコードを再チェックしただけで、価値を付加することなくコストだけを膨らませていました。
潜在的なデメリット
- 予算の爆発 – 低努力レベルの価格帯に慣れているユーザーは、同じ成果物に対してコストが25倍に跳ね上がることに驚くかもしれません。
開発者への実用的なガイダンス
- 日常的なプロンプトはデフォルトの努力レベルに保ってください。わずかなコストで同じ機能的な結果が得られます。
- 「max effort」は、テストカバレッジの低さ、リンティング警告の欠如、その他の測定可能なギャップなど、明確な品質基準を満たしていないコードのために取っておきましょう。
- この設定を、より良い回答を即座に得るための手段ではなく、オプションの自己レビュー工程という、別のモードとして扱ってください。
まとめ
Claude Opus 5のmax-effortスイッチは、より良いコードを得るためではなく、内部的な品質チェックのためにコストを支払うものです。ベースラインの結果に埋めるべき定量的な欠陥がある場合にのみ、控えめに使用してください。そうでなければ、安価なデフォルト設定でも、監査モードの価格を払うことなく同じ結果が得られます。
Community discussion: https://t.me/GyaanSetuAi