Claude Code Auto Modeにおけるサーバーサイド分類器：課金、ゲートウェイ、フォールバックの仕組み

Claude Codeをアップデートした後、Auto Modeでのコマンド実行中にターミナルが一時停止し、次のような警告が表示された場合：

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

これは、クライアントが追加コストのかからない新しいサーバーサイド安全性検証を有効化しようとしたものの、インフラストラクチャ上の制約によって現在のアクティブなセッションに適用できなかったことを意味します。

Auto Modeでは、分類器（classifier）がBashの実行、システムコマンド、外部へのネットワーク呼び出しなど、潜在的にリスクのあるアクションを事前に精査します。バージョンv2.1.278以前は、これらのチェックは課金対象のトークンを消費する個別のクライアント側リクエストとして実行されていました。v2.1.278以降は、検証処理がデフォルトでAnthropicおよびクラウドプラットフォームのサーバー側にオフロードされ、メインモデルへのリクエスト内で直接、追加料金なしで実行されるようになっています。

サーバーサイドの検証が利用できない場合でも、Claude Codeはクライアント側の分類器リクエストを通じてアクションの検証を継続します。このフォールバックリクエストは従来通り標準のトークン料金で課金されます。この警告は、検証が課金対象となるクライアント側の分類器リクエストにフォールバックしたことを示しているだけであり、セキュリティチェックが無効化されたわけではありません。

---

警告通知への対応：Enter と Esc / Ctrl+C の挙動

サーバーサイドのチェックが利用できない場合、Claude Codeは検証が必要な最初のコマンドを実行する前に処理を一時停止し、ユーザーの応答を待ちます。

• Enterキーを押す: 保留されていたコマンドの実行を承認します。セッションはAuto Modeのまま継続し、標準のトークンレートで課金されるクライアント側の分類器チェックを使用します。プロンプト内に中継ゲートウェイまたはプロキシが明示的に特定されていた場合、この承認はローカルマシン上に24時間キャッシュされます。ゲートウェイ名が特定されなかった場合、次回セッションがフォールバックした際にプロンプトが再表示されます。
• EscキーまたはCtrl+Cを押す: 保留中のアクションを直ちに中止し、アクティブなターンを終了します。セッションはAuto Modeにとどまり、承認は保存されないため、検証を要する次のコマンド実行時に再びプロンプトが表示されます。
• モードを切り替える: Shift+Tabを押すと、Auto Modeを完全に終了できます。トークン料金を節約する目的でセキュリティポリシーやサンドボックス保護を無効化することは決して推奨されません。

非対話的な自動化環境では、Claude Codeの挙動は以下のように適応されます。

• ヘッドレスモード（-p）では、通知はstderrに出力され、コマンドの実行はそのまま継続されます。
• stream-jsonモードでは、クライアントはメッセージストリームにsystem警告イベントを出力します（Agent SDK経由で処理可能）。
• VS Code拡張機能では、通知はチャットUI内の情報バナーとして表示され、キーボードによる確認は不要です。

---

セッション診断：/status コマンドとフォールバックの判定ロジック

現在Auto Modeが安全性チェックをどのように処理しているかを確認するには、組み込みのステータスコマンドを実行します。

/status

出力結果の中にある Auto mode server の行を確認してください。

• Enabled: 安全性検証がサーバー上で実行されています。分類器に対する個別のトークン課金は発生しません。
• Disabled: セッションがクライアント側の分類器にフォールバックしています。安全性チェックのリクエストがローカルから送信され、通常のトークン消費として課金されます。

単発のエラーとセッション単位のフォールバックの違い

一時的なネットワークの不調と、持続的なセッション全体のフォールバックは明確に区別する必要があります。

1. 単一のアクション: サーバーが特定のアクションの検証に失敗した場合、Claude Codeは自前で1回だけローカルチェックを実行し、次のリクエストで再びサーバーサイド検証を試行します。この場合、セッション警告プロンプトは表示されません。
2. セッション単位のフォールバック: 画面上のプロンプトが表示されるのは、セッション全体でサーバーサイドチェックが利用できなくなった場合のみです（これは検証対象となる最初のコマンドの時点で発生することもあります）。

---

プラットフォーム別の対応状況、地域別ロールアウト、および制限事項

サーバーサイドの安全性検証は、Claude Code v2.1.278以降、以下の環境においてデフォルトで有効化されています。

• Claude APIおよびEnterpriseアカウント
• AWS上のClaude Platform、Amazon Bedrock、Google Cloud Agent Platform（Vertex）、Microsoft Foundry
• 互換性のあるプロキシおよびゲートウェイ

主な利用条件と制約事項は以下の通りです。

• Pro、Max、Teamプラン: これらの個人向けおよびチーム向けプランの加入者には、この通知が表示されることはありません。
• クラウド上のモデル制限: Amazon Bedrock、Google Cloud Vertex、Microsoft Foundryにおいて、Auto Mode全体はClaude Sonnet 5、Opus 4.7以降、およびFableファミリーのモデルでのみサポートされています。
• 段階的なロールアウト: サーバーサイド検証の提供状況は、プラットフォーム、リージョン、認証情報によって異なります。プロキシや企業向けゲートウェイを経由していないにもかかわらず/statusがDisabledと表示される場合、考えられる原因の一つは、該当の構成に対してまだ機能が展開されていないことです。管理者に確認するか、/feedbackから報告してください。

---

ゲートウェイにおける課題：透過的パススルーと CLAUDE_CODE_AUTO_MODE_SERVER フラグ

この通知が表示される最も一般的な原因は、クライアントとアップストリームAPIの間にある企業向けLLMゲートウェイやプロキシ（モデルルーターやロードバランサーなど）が、通信トラフィックの一部を除去または改変していることです。

ゲートウェイに求められる要件

サーバー検証を機能させるには、エンドツーエンドでのメタデータの透過的な転送が不可欠です。ゲートウェイ経由で追加コストなしのサーバーチェックを利用できるようにするには、管理者が以下のパススルールールを設定する必要があります。

• セキュリティパラメータ（具体的にはsafeguardsフィールド）を含め、すべてのリクエストヘッダーおよびリクエストボディのパラメータを変更せずにそのまま転送すること。
• 不明なキー（具体的にはsafeguard_resultsペイロード）を削除することなく、レスポンスやストリーミングイベントをクライアントに返送すること。
• プロキシ層でツールの実行識別子（tool_use_id）を書き換えず、元の値を保持すること。

一時的な無効化フラグとそのトレードオフ

社内ゲートウェイがこれらのメタデータフィールドの透過に対応しておらず、すぐにアップデートできない場合は、以下の環境変数を設定することで実行をブロックするプロンプトを抑止できます。

export CLAUDE_CODE_AUTO_MODE_SERVER=0

この環境変数に関して理解しておくべき重要なポイント：

• トレードオフ: この変数を設定すると、Claude CodeはBedrock、Vertex、Foundry、またはゲートウェイ経由のルートにおいてサーバーサイドチェックを要求しなくなります。警告プロンプトは表示されなくなりますが、すべての分類器チェックが課金対象のクライアント側リクエストとして実行されるようになります。
• 直接接続時は無視される: 公式のAnthropic APIに直接接続している場合、この変数は読み込まれず、完全に無視されます。
• CLAUDE_CODE_AUTO_MODE_SERVERが未定義の場合、CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1を設定することでも同様の効果が得られます。
• この設定は一時的な救済措置であり、今後のClaude Codeのリリースで非推奨化または削除される可能性があります。

---

コスト診断：イベントタイムラインと実際のコスト要因

Auto Modeのトークン消費やHTTP 429エラーに関しては、様々な憶測が飛び交っています。客観的なコスト評価を行うには、仮説に頼るのではなく、公式のリリースタイムラインと生のログデータを照らし合わせて分析することが不可欠です。

プロンプト、課金フォールバック、ゲートウェイ設定に関する公式の詳細情報については、公式のClaude Codeドキュメントを参照してください。

イベントのタイムライン

timeline
    title Auto Mode検証メカニズムの変遷
    2026-09-08 : 過去のインシデント #93558 : リクエスト帰属ヘッダーに起因するバージョン2.1.263–2.1.267での特定429エラー
    2026-09-19 : 公式リリース v2.1.278 : サーバー分類器のデフォルト化、/statusインジケーター、fallback警告
    2026-09 : Redditでの議論 : 原因の切り分けのないGitOpsサイクルでの$50/hour消費報告

1. 2026年9月8日〜9日（旧バージョンにおける過去のインシデント）: イシュー報告 #93558 では、クライアントバージョン 2.1.263〜2.1.267 における不具合が記録されました。カスタムゲートウェイと CLAUDE_CODE_ATTRIBUTION_HEADER=0 を併用した場合、分類器のチェック時にクライアントが15回連続で空のHTTP 429レスポンスを受け取り、Bashコマンドがブロックされる現象が発生しました。このフラグを削除することで問題は解消しました。旧クライアントはデフォルトの api.anthropic.com ホストに対してのみリクエスト帰属（アトリビューション）ヘッダーを復元し、カスタムエンドポイントでは欠落させていたことが判明しています。
   • 注意: この問題は古いクライアントバージョンに特有のものです。この報告には、v2.1.278で同様の問題が再発するという証拠はなく、すべての429ステータスコードがリクエスト帰属ヘッダーの挙動に起因しているわけでもありません。
2. 2026年9月19日（v2.1.278のリリース）: サポート対象プラットフォームにおいてサーバーサイド分類がデフォルト化され、/status に Auto mode server 行が追加され、課金フォールバックを通知するダイアログが導入された公式リリース。
3. Redditでの1時間あたり50ドルの支出に関する議論: あるユーザーが、Opus 5-high を用いたGitOps自動化（Ansible、OpenTofu）の長時間実行において、1時間あたり約50ドル（$50/hour）を消費したと報告しました。このユーザーは、Auto Modeの分類器がコマンドごとに会話履歴全体を送信しているのではないかと推測しました。ただし、このスレッドには裏付けとなるトークン内訳の計算データは提示されていませんでした。

なぜ分類器のコストをログ監査なしに断定してはならないのか

ログデータによる検証なしに、1時間あたり50ドルの請求を分類器のオーバーヘッドに直接結びつけることには、客観的な証拠がありません。

• Redditの投稿者はJSONL形式のセッションログを保存していたものの、分類器のトークン消費量とメインモデルの推論とを切り離すコンポーネント単位のコスト内訳分析を行っていませんでした。そのセッションにおける実際のコスト要因は未検証のままです。
• Anthropicが事前の告知なしにキャッシュの料金体系を変更したとするフォーラム上の主張は、ユーザー側の憶測に過ぎず、確認された事実ではありません。
• ドキュメントでは、サーバーチェックは追加の課金を発生させず、クライアント側フォールバック時のリクエストも従来通りの標準トークン料金で請求されることが明記されています。単一のユーザー報告のみをもって分類器のオーバーヘッドを定量化することはできません。
• GitOpsのワークフローでは、膨大なAnsibleの出力やOpenTofuのインベントリ/リストといったコマンド出力が、メインモデルのコンテキストを増大させる要因となり得ます。分類器のオーバーヘッドだと結論付ける前に、まず個別のセッションログを直接監査すべきです。

---

エンジニア向けの実践的なトラブルシューティング手順

予期せぬトークン消費やフォールバック通知に遭遇した場合は、以下の診断チェックリストに沿って対応してください。

1. バージョンの確認: Claude Codeのバージョンが 2.1.278 以降であることを確認します（claude --version）。
2. セッション状態の確認: /status を実行し、Auto mode server の行を確認します。
   • Enabled の場合: 分類器はサーバー側で動作しており、追加のトークン料金は発生していません。
   • Disabled の場合: セッションは課金対象となるクライアント側のチェックにフォールバックしています。
3. フォールバックの根本原因を特定:
   • 中継ゲートウェイを経由している場合: プロキシログを確認し、safeguards や safeguard_results フィールドが削除されていないか、あるいは tool_use_id の値が変更されていないかを調査します。ゲートウェイを直ちに更新できない場合は、一時的な回避策として export CLAUDE_CODE_AUTO_MODE_SERVER=0 を使用します。
   • APIに直接接続している場合: サーバー検証がお使いのリージョンまたはアカウント階層にまだ順次展開中である可能性があります。管理者に確認するか、/feedback からフィードバックを送信してください。
4. JSONLログを用いた支出の監査:
   • セッショントランスクリプト（.jsonl）ファイルを開きます。
   • リクエストタイプごとにトークン数（input_tokens、cache_read_input_tokens、output_tokens）を分類・集計します。
   • 安全性分類器の呼び出しと、メインモデル（Opus/Sonnet）へのリクエストを分離します。
   • ターミナルの詳細な出力が累積コンテキストウィンドウに与えた影響を測定します。
5. セキュリティ基準の維持: トークンコストを削減しようとして、安全ガードレールや権限境界を無効化することは決して行わないでください。