Claude CodeのAuto modeを使っていると、たまに「この判定はどこで行われたのか」「その判定コストは課金されるのか」が気になります。
2026年9月19日のClaude Code v2.1.278で、Auto modeの分類器に関する変更が入りました。Claude APIやEnterprise、Bedrock、Vertex、Foundry、gatewayでは、サーバー側のclassifierを既定にできるようになり、classifier overheadを課金しない経路が用意されています。
今回は、公式リリースノートで確認できた内容をもとに、何が変わったのか、どこを見れば現在の判定場所が分かるのかを整理します。手元の契約や接続先で同じ表示になるとは限らないため、未確認の挙動は断定しません。
Auto modeの「判定」は別の処理
Auto modeは、すべてのコマンドを同じ扱いで実行するモードではありません。実行しようとする操作を見て、承認を求めるか、そのまま許可できるかを分類します。
この分類をモデル本体の回答と同じものだと考えると、コストや遅延の説明が合わなくなることがあります。Auto modeには、操作を分類するためのclassifierという別の処理があるからです。
ここで大事なのは、実際の処理が「モデル本体」と「Auto mode classifier」の2段に分かれる可能性があることです。
ユーザーの指示
↓
Claude Codeの実行判断
↓
Auto mode classifier
↓
許可 / 承認要求 / 拒否この分類器がどこで動くかによって、表示や課金の説明が変わります。
v2.1.278でサーバー側classifierが既定に
公式リリースノートのv2.1.278では、Claude APIとEnterprise、さらにBedrock・Vertex・Foundry・gatewayについて、サーバー側classifierを既定にする変更が説明されています。
サーバー側の経路では、classifier overheadを課金しないと説明されています。ただし、これは「Claude Codeを何回動かしても無料」という意味ではありません。モデルへのリクエスト、入力トークン、出力トークン、接続先の料金体系は別に考える必要があります。
正確には、Auto modeの分類器にかかる追加処理の扱いが変わった、という話です。利用量全体の上限や、モデル本体の料金が消えるわけではありません。
以前の経路と何が違うのか
リリースノートの変更を運用上の言葉に直すと、主な違いは次のようになります。
- サーバー側classifier: 接続先のサービス側でAuto modeの分類を処理する
- ローカルまたは課金されるfallback: サーバー側の経路を使えない場合に別の分類経路へ戻る
- 表示: 現在のセッションでどちらの経路を使っているかを確認できる
ここでいう「ローカル」は、必ずしも自分のPCだけで完結するという意味ではありません。公式の説明にない細かい実装境界まで、リリースノートだけから推測するのは危険です。
私が確認できた確定情報は、サーバー側classifierが既定になったこと、classifier overheadを課金しないこと、サーバー側を無効化する環境変数があること、そして/statusに状態が表示されることです。
/statusでAuto mode serverを見る
v2.1.278では、/statusにAuto mode serverの行が追加されています。まずは現在のセッションでここを確認するのが安全です。
/status表示が出れば、Auto modeのclassifierがサーバー側で動いているかどうかをセッション単位で確認できます。契約やgatewayの設定によって表示内容が異なる可能性があるため、他人のスクリーンショットを自分の環境の証拠にはしない方がよいでしょう。
無人実行のログに残すなら、次のように「設定した値」だけでなく「実際のstatus表示」も記録します。
実行前: claude --version
実行中: /status
記録: Auto mode server = enabled / disabled / fallback の表示設定ファイルにサーバー側を使う値を書いたとしても、接続先がそれを受け付けたとは限りません。設定と実際の表示を分けて確認するのがポイントです。
CLAUDE_CODE_AUTO_MODE_SERVER=0は何をするか
v2.1.278の説明には、Bedrock・Vertex・Foundry・gatewayでサーバー側classifierを無効化するためのCLAUDE_CODE_AUTO_MODE_SERVER=0も登場します。
$env:CLAUDE_CODE_AUTO_MODE_SERVER="0"
claudePowerShellでは、現在のターミナルセッションにだけ環境変数を設定できます。まず一時的に試し、/statusの表示が変わるか確認するのがよいでしょう。
ただし、この設定を入れれば必ず同じfallbackになるとは限りません。公式リリースノートの対象は接続先ごとに書かれているため、Claude APIやEnterpriseでの扱いまでこの例から一般化しないでください。
fallbackが課金される場合に注意する
公式の変更説明には、サーバー側classifierが使えない時に、課金されるfallbackが発生する場合の警告も含まれています。
この警告を見た時にやることは、すぐにAuto modeを捨てることではありません。まず、どの接続先を使っているか、/statusでサーバー側経路が有効か、環境変数で明示的に無効化していないかを確認します。
# PowerShellで現在の値を確認
$env:CLAUDE_CODE_AUTO_MODE_SERVER
# Claude Codeを起動後、セッション内で確認
/status値が空でも、既定値がどう解釈されるかはバージョンと接続先に依存します。空だから無効、という意味ではありません。
無人ループで残すべき証跡
定期実行では、Auto modeの表示を毎回長文で保存する必要はありません。ただし、コストや許可動作を調べる時に追跡できる最低限の情報は残した方が安全です。
- Claude Codeのバージョン
- 使用した接続先またはprovider
- Auto mode serverの
/status表示 - 明示的に設定した環境変数
- fallback警告の有無
たとえば、メトリクス収集のような軽い処理でも、実行時の設定を1行だけ残しておけば、後から請求や挙動を比較しやすくなります。
逆に、classifierがサーバー側になったからといって、検収を省略する理由にはなりません。コマンドが成功したか、ファイルが更新されたか、APIの戻り値が期待どおりかは、別に確認します。
手元で確認できる最小手順
まずバージョンを確認します。
claude --version次にClaude Codeを起動し、セッション内で/statusを実行します。
claude
/statusAuto mode serverの表示が確認できたら、同じ操作をfallbackを無効化する設定の有無で比較します。大きなコード変更をしながら試すのではなく、読み取りだけの安全な操作で差分を見る方が原因を切り分けやすいです。
この検証で分かるのは、現在のセッションがどの経路を示しているかだけです。契約全体の請求額や、すべてのproviderの挙動を証明するものではありません。
Auto modeを使うべきか
私は、承認を毎回手で判断するより、Auto modeに任せられる範囲を明示した方がよい場面では使います。ただし、無人実行だから無条件に許可する、という意味ではありません。
Auto modeには分類器がありますが、分類が常に自分の意図どおりになるとは限りません。重要なファイルを変更する処理、外部へ送信する処理、課金に影響する処理は、設定とログと検収を組み合わせます。
今回のv2.1.278は、Auto modeの判定経路とそのコストを見えやすくする変更です。便利さだけでなく、どの経路で何が起きたかを確認する入口が増えた、と捉えるのが現実的です。
まとめ
Claude Code v2.1.278では、対象となる接続先でAuto modeのサーバー側classifierが既定になりました。サーバー側経路ではclassifier overheadを課金しないと説明されています。
現在の状態は/statusのAuto mode server行で確認できます。Bedrock・Vertex・Foundry・gatewayではCLAUDE_CODE_AUTO_MODE_SERVER=0でサーバー側経路を無効化できますが、接続先ごとの対象範囲は公式情報で確認してください。
サーバー側classifierが有効でも、モデル本体の利用量や検収が不要になるわけではありません。バージョン、provider、status表示、環境変数、fallback警告を小さく記録しておくと、無人実行の説明責任を保ちやすくなります。
参考：Claude Code v2.1.278公式リリースノート、Auto mode classifierの課金に関する公式ドキュメント
コメント