なぜサーバー側の無料分類には「正当な分類リクエストとして検証可能に識別」することが必要なのか、技術的に何をチェックしているのか？
サーバー側は、そのリクエストが確かに公式の Claude Code クライアントから来ており、識別特性が中間層によって書き換えられていないことを確認した上で、その分類判定を「システム内部の運用コスト」として扱えると考えればよい。ゲートウェイやプロキシはレート制限やリクエストログ記録のために、ヘッダーの書き換えや接続のプーリング、リクエストの発信元識別方法の変更を行うことが一般的で、これらの変更がまさにサーバー側の元の発信元検証能力を損なう。
これは Anthropic がゲートウェイ利用者を意図的に課金しているわけではなく、無料メカニズムの技術的前提そのものがクリーンで改変されていないリクエスト経路に依存しているためである。
「this session isn't eligible」が表示された後、課金分類器へのフォールバック以外に Auto Mode の他の挙動に影響はありますか？
現在公開されている挙動の説明は課金経路の切り替えのみをカバーしており、分類の精度、速度、判定ロジック自体に違いがあるとは言及されていない。つまり課金分類器にフォールバックした後も、人的確認が必要かどうかを判断する Auto Mode の品質自体は理論上影響を受けず、唯一の違いはこの判定が使用量に計上される点である。
ただし、ゲートウェイがヘッダーレベルの書き換えだけでなくリクエスト内容自体を変更している場合は、課金以外に予期しない差異がないか、しばらく Auto Mode の挙動を観察することを勧める。
自分の構成が「ゲートウェイ」に該当するかどうか自信がない場合、どう素早く判断すればよいですか？
実用的な判断方法は、自分に問うことだ：Claude Code や API リクエストは Anthropic の公式エンドポイントに直接届いているか、それとも自分（または第三者）が構築した中継サービスを経由してから転送されているか。あなたまたは第三者が制御する追加のサーバー層がリクエストの転送、ログ記録、書き換えを行っている場合は、直接接続だと前提せず、ゲートウェイのシナリオにあると想定すべきである。
企業内でよくある統一 API ゲートウェイ、内部コンプライアンス監査プロキシ、複数のモデルプロバイダーを切り替えるための一部のサードパーティ LLM ルーティングサービスは、チーム内で「ゲートウェイ」という言葉を普段使っていなくても、このカテゴリに該当する。
アップグレード後 /status で Auto mode server が「対象外」と表示された場合、ゲートウェイの再構築以外に対処法はありますか？
短期的に現実的な方法は2つある。1つ目は、ゲートウェイが本当にこのカテゴリの分類リクエストを傍受する必要があるか評価し、不要であれば Auto Mode 分類トラフィックがゲートウェイを迂回して公式エンドポイントに直接届くよう例外設定を検討すること。2つ目は、ゲートウェイがコンプライアンスやセキュリティ上の要件で迂回できない場合、この分類コストを既存のゲートウェイ構成に内在する運用コストとして通常通り予算計上し、自動的に消えるものだと想定しないことである。
どちらが実行可能かは、そもそもなぜゲートウェイが存在するかに依存し、通常はゲートウェイを管理するチーム（セキュリティやプラットフォームエンジニアリング）と共に評価すべきで、Claude Code を使う開発者個人だけで決められるものではない。
Claude Code の Auto Mode は、現在の会話ターンやツール呼び出しが許可された行動範囲内かどうかを判定するために、バックグラウンドで安全分類器を実行している。この分類器は以前は使用量に計上されていた——分類判定のたびにトークン予算や API コストが消費され、ユーザーの多くはそれが動いていることにすら気づいていなかった。最近のリリースでは、これがデフォルトでサーバー側で無料実行されるように変更された。単純なコスト削減のように聞こえるが、ゲートウェイやプロキシ経由で Claude Code にアクセスしているチームには、この「無料」に自分で確認すべき例外がある。
新しいデフォルト挙動は次の通り：アカウントが Claude API、Enterprise、Amazon Bedrock、Google Vertex AI、Microsoft Foundry のいずれかのアクセス経路であれば、Auto Mode の安全分類判定は Anthropic のサーバー側で直接実行され、トークン使用量に計上されず、請求書にも表示されない。Auto Mode を多用するチーム（Claude Code に人的確認が必要かどうかを自律判断させる）にとって、これは実質的なコスト削減となる。高頻度の自動化フローでは、こうしたバックグラウンド判定呼び出しが静かに積み重なり、多くのチームが気づかないまま請求書に小さくない金額として現れていたためだ。
問題は「サーバー側での無料実行」が、Anthropic のサーバーがそのリクエストを正当な分類リクエストとして直接かつ検証可能に識別できることを前提としている点にある。企業内で統一されたリクエストログ記録、レート制限、マルチテナントの費用配分のために独自のゲートウェイやプロキシを構築している場合、この中間層がリクエストの識別特性を変えてしまい、サーバー側が無料分類の適格性を判定できなくなる。この場合 Claude Code は失敗するのではなく、「this session isn't eligible」（このセッションは対象外です）という通知を表示し、自動的に従来の課金分類器にフォールバックして動作を継続する。つまり機能は止まらないが、コストは無料モードから課金モードへ静かに切り替わり、その切り替えは自動かつ無通知で行われ、同意を求める追加の確認画面は出ない。
この更新では /status コマンドに「Auto mode server」という新しい行が追加され、現在のセッションが無料のサーバー側分類の対象になっているかを直接示すようになった。何らかのゲートウェイ、社内プロキシ、または非公式な経路で API トラフィックを転送しているチームは、アップグレード後まず /status を実行してこの行を確認することを強く勧める——「公式発表で無料と言っていたから無料だろう」と前提しないことが重要だ。特に複数層のプロキシを重ねている構成（社内セキュリティ監査ゲートウェイを経由してから Anthropic に転送する等）では、最終的なリクエスト自体に問題がなくても、中間層の存在だけでサーバーが対象外と判定するのに十分な場合がある。
公式の Claude Code を直接使い、独自のゲートウェイを持たないチームにとって、この更新は純粋なコスト削減であり、何もする必要はない。しかし、コンプライアンス、監査、複数アカウント間の費用分担などの理由で API ゲートウェイを構築している組織は、実際に /status を実行して「Auto mode server」フィールドを確認する必要がある——アップグレードしただけで自動的に無料分類の対象になると想定してはいけない。多くのチームは、最初からずっと課金フォールバック経路に乗っていたために、Auto Mode 関連の分類コストが実際には全く減っていなかったことに、翌月の精算時になって初めて気づくことになる。