社内でClaude Codeを使い始めると、すぐに困るのが「全員が同じ重さでAIを回す」問題です。簡単な文章修正にも深い推論を使えば、待ち時間と利用枠を消費します。逆に、設計や障害調査まで軽い設定に固定すると、手戻りが増えます。
2026年9月9日公開のClaude Code 2.1.267は、この調整に管理者側の上限を加えました。新しいmaxEffortLevelは、利用者が選べる推論の深さに天井を設定します。AWS Bedrock、Google Vertex AI、Microsoft Foundryを含む各プロバイダーが対象です。利用者は上限より低い段階を選べますが、上限は越えられません。
推論の深さに「社内の上限」が付いた
Claude Codeには、作業に応じて推論量を変えるeffort設定があります。公式ドキュメントでは、軽い作業向けのlowから、複雑な推論向けのhigh、xhighまでを案内しています。2.1.267で追加されたのは、個人が選ぶ初期値ではなく、組織が決める最大値です。
設定は全体に置くか、modelSettingsのモデルごとに置けます。たとえば日常作業で使うモデルはmediumまで、設計レビュー用のモデルはhighまで、という分け方ができます。上限を一律に下げるより、仕事とモデルの組み合わせで決める方が現実的です。
ここでの狙いは、AIを弱くすることではありません。推論の深さを手動のギアとして扱い、作業に合わない高いギアを踏み続けないようにします。誤字修正、定型テスト、ファイル整理は低いギア。複数システムをまたぐ設計、原因が読めない障害、権限設計は高いギア。会社側が上限を決めても、運転する人には下げる余地が残ります。
まず仕事を2種類に分ける
私なら、導入初日に細かなルールを作りません。最初は「日常処理」と「高難度判断」の2種類で十分です。
- 日常処理：文章修正、既存コードに沿った小変更、テスト実行、定型データ整理
- 高難度判断：新規設計、障害の根本原因調査、大規模変更、セキュリティと権限のレビュー
日常処理はmediumを上限候補にし、高難度判断だけhigh以上を許可します。ただし、この値は公式の正解ではありません。利用モデル、契約、作業内容で結果が変わるため、自社の記録から決めます。
1週間だけ、依頼の種類、選んだeffort、完了までの時間、やり直し回数を残します。品質を測らずに利用量だけ下げると、後工程の人手が増えて逆効果です。使っていないスキルや長い指示が文脈を圧迫している場合は、Claude Codeのスキル棚卸しと文脈コストの確認手順も先に見直します。見るべき数字はAIの使用量単独ではなく、「完了までに人が何分使ったか」と「差し戻しが何回あったか」です。
上限設定は品質保証ではない
maxEffortLevelは、出力の正しさを保証しません。highなら正解、mediumなら雑、という単純な関係でもありません。曖昧な指示、古い仕様、足りないテストは、推論を深くしても残ります。
そのため、上限設定と品質ゲートは分けます。コード変更ならテストと差分レビュー。顧客向け文書なら事実、数字、リンク、固有名詞の確認。外部送信や削除は人の承認。AIのギアを何段にしても、最後の合格条件は業務側に置きます。
高いeffortを許可する条件も明文化します。「担当者が必要だと思ったから」では運用が揺れます。私なら、影響範囲が複数システムに及ぶ、失敗時に顧客や売上へ影響する、標準手順で一度失敗した、のいずれかを満たす仕事に絞ります。
利用量だけで判定しない
上限導入の効果を確かめる時は、変更前後で同じ種類の仕事を比べます。見る項目は、着手から完了までの時間、人がレビューした時間、差し戻し回数、テスト不合格数です。契約画面に利用量が出るなら、それも同じ記録へ加えます。
たとえば利用量が減っても、レビューが毎回20分増えたなら、会社全体のコストは下がっていません。反対に、難しい仕事でhighを使い、調査のやり直しが1回減るなら、高いギアを許可する理由になります。AI側の数字と人の作業時間を同じ表で見ます。
比較期間中にモデルや指示文まで同時に変えると、何が効いたか分からなくなります。最初の検証では、対象業務、モデル、合格条件を固定し、effortの上限だけを変えます。20件ほど集めた後で、仕事別の標準値を決めれば十分です。
設定が読めない時に広く許可しない
同じリリースには、管理設定の安全側への修正も入っています。allowedHttpHookUrls、httpHookAllowedEnvVars、allowedChannelPluginsが読み取れない場合、何でも許可するのではなく、何も許可しない動作へ変わりました。
これは地味ですが、社内利用では重要です。設定ファイルが壊れた時に制限が外れると、外部HTTPフック、環境変数、チャネル用プラグインの許可範囲が意図せず広がります。今回の修正は、異常時に処理を止める側へ倒します。
一方、止まるだけでは業務が復旧しません。管理設定を更新したら、許可済みフックが動くこと、未許可URLが拒否されること、必要なプラグインだけ読み込まれることを定型テストにします。設定ファイルを配布できたことと、制限が効いていることは別の確認です。
再開後に文脈を落とさない修正も入った
2.1.267では、5MBを超える大きな会話を再開した際、並列ツール呼び出しとhook出力が欠ける問題も修正されました。MCP接続やツール定義が変わった時に、以前の推論が落ちる問題にも複数の修正があります。
長時間のAI業務では、再開できるだけでは足りません。何を実行し、どの結果を受け取り、どこまで判断したかが残っていなければ、同じ処理をやり直す恐れがあります。更新後の受け入れテストには、長いセッションの再開、並列実行結果の保持、承認待ち状態の維持を入れた方が安全です。
導入手順は小さく始める
- Claude Codeを使う仕事を日常処理と高難度判断に分ける
- モデルごとの上限案を設定し、少人数へ適用する
- 1週間、完了時間と差し戻し回数を記録する
- 品質が落ちた仕事だけ上限または手順を見直す
- 管理設定の拒否テストとセッション再開テストを通す
全員へ一度に配る必要はありません。まず1チーム、または影響の小さい業務で試します。日常処理の時間が伸びず、差し戻しも増えないなら対象を広げます。高難度判断で手戻りが増えるなら、その仕事だけ上限を上げるか、人のレビューを前に置きます。
今回の判断
Claude Code 2.1.267は、複数人で利用量と品質を管理したい組織には更新候補です。特にmaxEffortLevelは、個人の注意に頼っていたギア選択を設定に移せます。管理設定が読めない時に拒否側へ倒れる修正も、本番運用には効きます。
ただし、いきなりhighを禁止する運用は勧めません。先に1週間の実績を取り、日常処理で不要な高effortが使われている場所を探します。最初の一手は、上限値を決めることではなく、AIへ任せている仕事を2種類に分けることです。
一次情報
確認日：2026年9月10日。機能名と挙動は公式リリース、effortの段階と設定方法は公式ドキュメントを基準にしています。上限候補は運用例であり、Anthropicの推奨値ではありません。