CLAUDE_CODE_AUTO_MODE_MODELでauto modeの分類器モデルを選ぶ

CLAUDE_CODE_AUTO_MODE_MODEL は、auto modeで操作を審査する分類器のモデルを選ぶ環境変数です。v2.1.302で加わりました。ただし効くのは、Claude Code自身が分類器のリクエストを送る「クライアント側」の審査だけです。サーバー側で審査されるセッションでは、この変数を設定してもモデルは変わりません。

先に押さえたいのは、手元のセッションがどちらの経路かという点です。多くの環境は既定でサーバー側になっているため、設定したのに何も起きない、という状況が普通に起こります。

変数が効くのは「クライアント側の審査」だけ

v2.1.302の更新履歴には、次の1行が載っています。

Added CLAUDE_CODE_AUTO_MODE_MODEL to choose the model the client-side auto mode classifier uses; it does not change the model for server-side auto mode

auto modeには、審査を担う場所が2つあります。

サーバー側の審査を使うセッションは、権限モードのドキュメントにバージョンごとの条件つきで挙がっています。

v2.1.282以降は、テレメトリーを切るなどして機能フラグを取得しないセッションも、どの種類でも既定でサーバーに審査を頼みます。つまり最近のバージョンなら、この変数の出番があるのは次のどちらかです。

• サーバーが審査を引き受けない環境(ゲートウェイがリクエストやその結果を落とす、プラットフォームやリージョンが未対応など)で、Claude Codeが自前の分類器にフォールバックしている
• CLAUDE_CODE_AUTO_MODE_SERVER=0 を設定して、意図的にクライアント側へ戻している

後者の変数は、サーバー側審査を使うかどうかを切り替えるものです(用途はサーバー側審査の記事が扱っています)。ドキュメントには「一時的な設定で、後のリリースで削除される可能性がある」と書かれています。

分類器の既定モデルは何か

選ぶ前に、何が既定かを知っておくと判断しやすくなります。分類器は、/model で選んだモデルではなく、既定でClaude Sonnet 5で動きます。サーバー側でAnthropicが分類器のモデルを設定している場合は、そちらが既定より優先されます。

既定が使えない場合のフォールバックも決まっています。

• セッションのモデルがClaude Sonnet 4.6、または availableModels がSonnet 5を除外している場合は、セッションのモデルで動く
• セッションがFableモデルの場合は、Opus系のモデルで動く
• Anthropic API以外のプロバイダーでは、このOpusのフォールバックは ANTHROPIC_DEFAULT_OPUS_MODEL に設定したモデル、未設定ならOpus 5になる

セッション最初のauto modeリクエストで、Sonnet 5が既定として検証されます。成功すればそのセッションの分類器はSonnet 5のまま、モデルが使えないという理由で失敗すれば、上のフォールバックに切り替わります。

権限モードのページは、この既定モデルとフォールバックだけを定めていて、新しい変数との優先順位には触れていません。変数が既定より優先されるのかは、このページからは言えません。

設定の書き方

シェルの環境変数として設定する場合は、次のようにします。

export CLAUDE_CODE_AUTO_MODE_MODEL=<モデル名>
claude --permission-mode auto

<モデル名> は例示用のプレースホルダです。値の書式は後述の表のとおり未記載です。

毎回exportしたくない場合は、設定ファイルの env キーに書く方法もあります。CLAUDE_CODE_AUTO_MODE_SERVER の説明が env キーでの指定を案内しているので、同じ形を使えます(<モデル名> は同じくプレースホルダです)。

{
  "env": {
    "CLAUDE_CODE_AUTO_MODE_MODEL": "<モデル名>"
  }
}

効いているかは、次の節の手順で確かめられます。

効いているか、そもそも効く経路かを確かめる

変数を設定する前に、手元のセッションがクライアント側かサーバー側かを見ます。auto modeに入った状態で /status を開くと、Auto mode server の行があります。

• Enabled: サーバー側の審査がセッションの判定を決めている。この間、変数を設定してもモデルは変わらない
• Disabled: サーバー側の審査が効いておらず、Claude Codeが自前の分類器リクエストを送っている。この状態が、変数の対象

この行は、サーバー側審査の状況を確かめるためにドキュメントが案内している方法です。Disabled になる原因として、課金の通知に関するページが最初に挙げているのは、LLMゲートウェイやプロキシの存在です。

サーバー側を意図して止める場合は CLAUDE_CODE_AUTO_MODE_SERVER=0 を使いますが、費用の面は押さえておく必要があります。Enterpriseプラン、およびClaude API・Claude Platform on AWS・Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundryを使うアカウントでは、クライアント側の分類器リクエストがトークン使用量に数えられます。1回の審査でトランスクリプトの一部と保留中の操作が送られ、実行前に往復が1回増えます。審査が走るのは主にシェルコマンドとネットワーク操作で、作業ディレクトリ内の読み取りや編集は分類器を通りません。

サーバー側の審査が届かずフォールバックした場合は、課金される旨の通知が出るアカウントがあります。通知が出るセッションと出ないセッションの境目は、v2.1.278のリリースノート記事で扱っています。Pro・Max・Teamでは、この通知は出ません。

文書に書かれていない点

この変数の説明は、更新履歴の1行だけです。環境変数の一覧、モデル設定のページ、設定リファレンスには、この名前の行は載っていません。次の点は、どのページにも記述がありません。

右列は、記述がない部分を実際に動かして確かめるための手順です。

分類器が応答しないときの見分け方

選んだモデルがうまく動かないとき、症状は分類器のエラーとして現れます。ドキュメントには、分類器モデルが判定を返せない場合のメッセージが載っています。

<model> is temporarily unavailable, so auto mode cannot determine the safety of <tool> right now. Wait a moment and then try this action again.

メッセージにはモデル名が入ります。変数でモデルを変えたあとにこの文が出たら、まずそのモデル名が意図したものかを見ます。原因の種類は、(rate-limited)・(overloaded)・(server error)・(timed out)・(connection failed) のカッコ書きで示されます。どれにも当てはまらないとき、カッコは付きません。

Amazon Bedrockでは、AWSアカウントがメッセージに出たモデルを呼び出せない場合にも同じ文が出ます。この場合は、アカウントにそのモデルへのアクセスが付与されるまで、再試行のたびに繰り返されます。対処は、標準のBedrockモデルならIAMポリシーでそのモデルの呼び出しを許可しているかの確認、Mantleのモデルなら、AWSのアカウントチームへの問い合わせです。

対話型のセッションでは、赤いエラーではなく、薄い Not run · auto mode's check had no usable answer の行がツール呼び出しの下に出ます。内容は Ctrl+O のトランスクリプト表示で読めます。v2.1.296より前は、メッセージが赤いエラーとして出ていました。分類器が応答しない状況の全体像は分類器が応答不能になるとBashが止まる原因の記事が詳しく扱っています。

モデルを変える前に、分類器が何を見ているかを知る

クライアント側の分類器リクエストで、分類器が見るのは、ユーザーのメッセージ、読み取り専用の参照を除くツール呼び出し、CLAUDE.mdの内容です。ツールの実行結果は、リクエストから取り除かれます。ファイルやWebページに紛れた悪意のある文字列が、分類器を直接動かせないようにするためです。

モデルを変えたときに判定の精度がどう動くかについて、ドキュメントに比較はありません。判定の中身を変える手段としては、autoMode の environment・allow・soft_deny に自然文のルールを書く方法が別にあります。判定の順序と書き換え方は、auto mode分類器の判定順序の記事が説明しています。

組織で既定のモデルを配っている場合の優先順位は、別の仕組みです。分類器のモデルではなくセッションのモデルについては、組織デフォルトモデルの優先順位の記事で扱っています。

まとめ

この変数は、クライアント側の分類器にだけ効きます。設定する前に /status で Auto mode server の行を見て、Disabled のセッションか、自分で CLAUDE_CODE_AUTO_MODE_SERVER=0 を設定したセッションに限って意味があると考えるのが筋です。

Bedrockのように呼び出し権限が絡む環境では、モデルを指定する前に、そのモデルをAWSアカウントが呼べるかを先に確かめておくと、再試行が止まらない状況を避けられます。書式などの未確認点は表の手順で潰せるので、費用の面でクライアント側へ戻すことの影響が大きいアカウントほど、この確認を優先する価値があります。

v2.1.302全体の変更はリリースノート記事にまとめています。