結論：maxEffortLevelは「使える努力レベルの上限」を置く設定
Claude Code 2.1.267では、maxEffortLevelをトップレベル、またはmodelSettings内のモデル別設定として置き、すべてのプロバイダーで努力レベルの上限を決められます。利用者は上限より低いレベルを選べます。
これはモデルを選ぶ設定でも、常に最大推論を強制する設定でもありません。難しい作業だけ高くし、定型作業は低くする余地を残したまま、組織で許容する上限を管理するための機能です。まず対象モデル、適用scope、下限を選べることを小さな検証で確認します。
根拠はClaude Code公式changelogの2.1.267と、公式Model configurationです。changelogは新設定がAnthropic API、Bedrock、Vertex、Foundryを含むproviderへ適用されることを説明し、Model configurationはモデル選択・effort・providerごとのモデル解決を整理しています。公式情報が示していない削減額や品質保証は断定しません。
effort、model、maxEffortLevelの違いを比較する
| 項目 | 決めること | 企業での確認 |
|---|---|---|
model | どのモデルで実行するか | providerの実モデル、利用可能性、契約 |
| effort | そのsession・作業でどの程度考えるか | 作業種別、時間、品質、利用量 |
maxEffortLevel | 選択できる努力レベルの上限 | 組織の許容時間、費用、下限選択、例外 |
三つを混同すると、「上限を置いたから全員が同じ品質になる」「高いモデルを選べば上限を超える」といった誤解が生まれます。モデルは回答能力の土台、effortは実行時の強度、maxEffortLevelは強度の天井です。実際にはモデルごとの対応範囲やprovider差があるため、設定値だけを台帳へ残さず、実行時に表示されたモデルとeffortも記録します。
公式Model configurationではproviderによってaliasの解決先が異なります。Anthropic API、Claude Platform on AWS、Bedrock、Google Cloud、Foundryで同じaliasでも実体が変わり得ます。組織設定に上限を置く場合は、モデル名、provider、バージョン、設定ファイルのscopeを組にして管理してください。
導入手順：maxEffortLevelを7ステップで安全に試す
claude --versionで2.1.267以降か確認し、端末、provider、利用モデル、確認時刻を記録します。- 対象業務を定型、調査、設計の三つに分け、各業務で必要な品質と許容時間を一文で決めます。
- トップレベルに置くのか、
modelSettingsでモデル別に置くのかを決め、managed・project・userのscopeを分けます。 - 低い努力レベルを選べるテストと、上限を超える値を選ぼうとするテストを用意し、挙動を同じ入力で比較します。
- Anthropic API、Bedrock、Vertex、Foundryなど実際に使うproviderごとに、alias解決先と設定の適用結果を確認します。
- 回答品質だけでなく、完了時間、再実行回数、確認者の修正時間、利用量を記録します。
- 承認者、例外申請、見直し日、rollback方法を決め、限定ユーザーから段階展開します。
検証で重要なのは、上限の数値を決めること自体ではありません。業務の失敗がどこで起きるかを確認することです。例えば定型分類では低いeffortで十分でも、顧客への返信案では人間確認の時間が結果を左右します。高い上限を全業務へ配る前に、通常ケース、情報不足、誤入力、停止条件のケースを一件ずつ通します。
企業設定で起きやすい不一致と判断基準
設定ファイルは優先順位を持ちます。公式Settings文書が示すmanaged settings、command line、project、userなどのscopeを確認し、個人の設定を変えたのに組織設定へ戻る現象を別の原因と切り分けます。管理者は「誰に効く上限か」「session中の変更を許すか」「新しいモデルを追加した時にどうするか」を文書化します。
判断は次の三段階にすると運用しやすくなります。第一に、低いeffortで通常業務を処理できるかを確認します。第二に、境界ケースだけ高いeffortを許す例外を定義します。第三に、品質不足が発生した場合に、effortを上げるのか、入力を直すのか、人間確認へ戻すのかを決めます。effortを上げ続けることを品質改善の唯一の手段にしません。
料金について、changelogとModel configurationはmaxEffortLevelによる値引きや専用料金を定めていません。モデル選択画面の価格表示と、Bedrock等のproviderや組織契約が決める請求は別です。導入前後の利用量と費用を実測し、機能の存在だけで費用効果を主張しないでください。
チェックリスト：上限を本番適用する前に
□versionが2.1.267以降か □対象providerと実モデルを記録したか □top-levelとmodelSettingsの使い分けを決めたか □managed/project/userのscopeを確認したか □下限を選べることを試したか □上限超過時の挙動を試したか □通常・境界・停止ケースを比較したか □品質・時間・修正時間・利用量を測ったか □例外と承認者を決めたか □前の設定へ戻せるか
設定が効かない時は、version、provider、モデルの実体、読み込まれたsettings scope、session中の上書きを順に調べます。設定値をチャットやログへそのまま貼る必要はありません。差分、適用範囲、結果の要約だけを記録し、機密情報を含む環境変数や認証値を共有しない運用にします。
よくある質問
maxEffortLevelはモデルを固定しますか？
固定しません。モデルを選ぶ設定とは別に、選択可能な努力レベルの上限を扱います。モデルの固定が必要なら、model、provider、scopeを別途管理します。
上限を高くすると回答が必ず正確になりますか？
保証されません。入力、モデル、ツール、確認手順なども結果へ影響します。上限変更の前後で通常・境界ケースを比較し、人間確認を省略しないでください。
料金を抑えるために上限を低くすべきですか？
費用だけで決めません。公式情報は料金削減を保証していないため、時間、再試行、修正、モデル料金を実測し、業務ごとに判断します。
公式情報と無料診断
仕様は公式changelog、モデルとeffortは公式Model configuration、scopeは公式Settingsを公開直前に確認しています。Miraigentの無料診断では、モデル選定、設定scope、品質確認、費用計測を企業の運用表へ整理できます。