Claude Code v2.1.278 — auto modeの分類器をサーバー既定に変更

このリリースで何ができるようになるか

Claude Code v2.1.278は、auto modeの安全性チェックを担う分類器の実行場所を変更しました。Claude APIとEnterpriseプラン、そしてClaude Platform on AWS・Amazon Bedrock・Google CloudのAgent Platform(Vertex)・Microsoft Foundry・ゲートウェイ経由のセッションで、分類器判定が既定でサーバー側に切り替わります。

サーバー側で判定が完了すれば、分類器の呼び出し分はトークン課金の対象になりません。/statusに新設された「Auto mode server」の行で、いま動いているセッションがサーバー判定を使えているかを確認できます。

あなたの開発フローはどう変わるか

Pro・Max・Teamプランを使っている場合、この変更による体感の違いはありません。これらのプランでは、後述の通知自体が出ません。

Claude APIを直接契約している開発者と、Claude Platform on AWS・Bedrock・Vertex・Foundry上でauto modeを使っているチームには実質的な変更があります。これまでこれらの環境では、分類器の呼び出しがトークン使用量として課金されていました。v2.1.278以降は、サーバー側の判定が届く限り、その分の課金が発生しません。

LLMゲートウェイを自前運用しているチームは、注意が必要です。ゲートウェイがリクエストヘッダーやレスポンスのフィールドを書き換えていると、サーバー側の判定がセッションに届かなくなります。この場合、Claude Codeは最初にチェックが必要になったタイミングで動作を保留し、次のような通知を表示します。

We're changing auto mode to no longer charge for classifier requests in Claude Code. However, this session isn't eligible.

この通知は、サーバー側の判定がそのセッションに届かなくなったと分かった時点で出ます。Enterで応答すれば、そのセッションでは再表示されません。早ければセッション最初のチェック対象操作で表示されることもあります。個々の操作でたまたま判定がサーバーに届かなかっただけなら通知は出ません。

通知への応答は3通りです。

• Enter — それ以降はセッションの残り全体でClaude Code自身の分類器判定を使い続け、これまでどおりトークン課金されます。ゲートウェイの名前が特定できていれば、その回答は24時間そのマシンで記憶され、通知は再表示されません。名前が特定できていなければ、次回以降のセッションがフォールバックしたときに、また通知が出ます。
• Esc・Ctrl+C — 保留していた操作は実行されずそのターンが止まります。auto mode自体は維持され、次にチェックが必要な操作でまた通知が出ます。
• Shift+Tab(通知に答えたあと)— 権限モードを切り替え、auto mode自体の利用をやめられます。

ゲートウェイ側でサーバー判定を使えるようにするには条件があります。リクエストヘッダーとボディのフィールド(safeguardsなど未知のものを含む)をそのまま転送し、レスポンスのsafeguard_resultsやtool-use IDを書き換えずに返すことです。

自前のゲートウェイがこの要件を満たせないと分かっている場合は、CLAUDE_CODE_AUTO_MODE_SERVER=0をセッション開始前に設定します。この環境変数は、シェルで設定するほか設定ファイルのenvキーでも指定できます。常にClaude Code自身の分類器判定を使う従来の挙動に固定でき、通知自体も出なくなります。なお、Claude APIへ直接接続している場合、この環境変数は読み込まれません。設定しても効果が無いため、切り分けの際は接続経路を先に確認してください。

なお、CLAUDE_CODE_AUTO_MODE_SERVERを設定していない状態でCLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1を設定していると、サーバー側のチェックも合わせて無効になります。実験的な機能をまとめて止める運用をしているチームは、意図せずローカル判定のまま動いている可能性があります。

ゲートウェイを挟んでいないのに通知が繰り返し出る場合は、原因が自分の環境ではなく利用しているプラットフォーム・リージョン・認証情報の側にあることが多いです。その組み合わせでサーバー側チェックがまだ展開されていないケースです。この場合はサポートか会社の管理者に問い合わせるか、/feedbackから報告します。

対話セッション以外でも通知の出方は変わります。非対話モード(-p)では通知テキストが標準エラー出力に出力されます。stream-json出力ではsystemタイプの警告メッセージとして流れ、Agent SDKで組んだアプリケーションはメッセージストリームからこれを読み取れます。VS Code拡張では会話内の通知として表示されるだけで、確認操作は必要ありません。

応答を待てない状況では、同じ文言の通知が出ます。それでもセッションはauto modeのまま続行されます。同じマシンで24時間以内にゲートウェイの通知を確認済みなら、再表示もありません。

export CLAUDE_CODE_AUTO_MODE_SERVER=0

主な変更点

• 変更: Claude APIとEnterpriseプラン、Bedrock・Vertex・Foundry・ゲートウェイ上のauto modeを、分類器呼び出しを課金しないサーバー側判定に既定変更。課金対象のフォールバックが起きるときは警告が出る
• オプトアウト: CLAUDE_CODE_AUTO_MODE_SERVER=0でBedrock・Vertex・Foundry・ゲートウェイに限りローカル判定に戻せる
• 追加: /statusに「Auto mode server」の行を追加。そのセッションの分類器がサーバーで動いているかを表示する

CLAUDE_CODE_AUTO_MODE_SERVERという環境変数名自体は新しくありません。ただし値の意味は前バージョンから反転しています。

同じ環境変数でも、v2.1.273時点の=1とv2.1.278時点の=0は逆方向の指示です。以前のバージョンからCLAUDE_CODE_AUTO_MODE_SERVER=1を設定に残しているチームは、v2.1.278では既定と同じ動きになります。ただしCLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1を併用している場合は注意が必要です。公式ドキュメントが無効化の条件として明記しているのは、CLAUDE_CODE_AUTO_MODE_SERVERが未設定のときだけです。=1を明示した場合にサーバー判定が維持されるかどうかは記載がありません。CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1を使っていない環境では=1は既に不要で、むしろ問題は、それに気づかないまま設定に残り続ける点です。動作は既定と同じなので、誰も異常に気づきません。

Bedrock・Vertex・Foundry上の対応モデルは、Claude Sonnet 5、Opus 4.7以降、Fableモデルに限られます。これらのプラットフォームとサインイン済みのClaude appsゲートウェイセッションでは、auto mode自体がこの範囲のモデルでしか使えません。

なお、対象モデル一覧に入っていないモデルでは、今回の課金変更以前にauto mode自体が使えません。課金先の設定を調べる前に、まずモデルが対象かを確認してください。

サーバー判定はBedrockでの実験からClaude API既定へ広がった

この変更は思いつきではなく、直近数バージョンで続いてきた分類器の実行場所をめぐる調整の到達点です。v2.1.236でBedrock・Vertex・Foundry・テレメトリー無効環境の分類器がClaude APIと同じ既定に揃えられ、深刻度スコア付き判定が全プラットフォームに広がりました。ところがv2.1.273では、この方向が「当面は」反転し、これらのプラットフォームはローカル判定に戻りました。サーバー判定はCLAUDE_CODE_AUTO_MODE_SERVER=1によるオプトイン扱いになりました。この反転の詳細はClaude Code v2.1.273にあります。

v2.1.278は、このオプトインをまず既定に格上げしたうえで、対象をClaude APIとEnterpriseプランにまで広げています。Bedrock・Vertex・Foundryだけの実験だった仕組みを、Anthropicが直接提供する契約形態の主戦場に持ち込んだ格好です。分類器がツール呼び出しのたびに何を判定しているかは、Claude Codeのauto mode分類器は何を止めているかにまとめています。

混同しやすいのが、auto mode自体を有効にするCLAUDE_CODE_ENABLE_AUTO_MODEとの違いです。こちらはv2.1.207でBedrock・Vertex・Foundry向けのオプトイン要件が撤廃され、無効化したい場合は設定のdisableAutoModeを使う方式に切り替わりました(CLAUDE_CODE_ENABLE_AUTO_MODEとはで扱っています)。auto modeという機能自体を使えるようにする設定と、その内部で分類器をどこで実行するかを決める設定は別物です。v2.1.278が変えるのは後者のCLAUDE_CODE_AUTO_MODE_SERVERだけです。両者を同じ設定だと思ってCLAUDE_CODE_AUTO_MODE_SERVERだけを調べても、auto modeが有効かどうかの答えにはたどり着けません。

課金構造を変える機能は、ゲートウェイのような中間層の対応が追いつくまで揺り戻しが起きやすいという特徴があります。v2.1.273の反転がまさにその例で、v2.1.278の既定化がこのまま定着するかは、ゲートウェイ各社がヘッダーとレスポンスをそのまま転送する対応を進められるかにかかっています。ドキュメント自身もCLAUDE_CODE_AUTO_MODE_SERVERを「一時的な設定で、将来のリリースで削除される可能性がある」と位置づけており、現在の仕組みが最終形とは限りません。

課金が減るチームと、通知が出続けるチームの境目

まとめ

Claude APIを直接契約している開発者と、Bedrock・Vertex・Foundry上でauto modeを運用しているチームは、/statusの「Auto mode server」行を更新後に確認する価値があります。Enabledならサーバー判定が効いており、分類器呼び出し分の課金は原則発生しません。Disabledならフォールバック済みで、従来どおり課金されます。

自前のLLMゲートウェイを挟んでいるチームは、通知が出るかどうかをまず確認し、出る場合はゲートウェイ側の転送設定を見直すか、CLAUDE_CODE_AUTO_MODE_SERVER=0を設定して従来どおりの課金に固定するかを選ぶことになります。Pro・Max・Teamプランのユーザーは、今回の変更を意識する必要はありません。

関連ガイド

このバージョン単体の位置づけや前後の版とのつながりは、Claude Codeの基礎ガイドでまとめて確認できます。