Claude Code 料金を見直す：auto modeの分類器課金が消える条件

Claude Code 料金の変更点をひと言で

Claude Codeのauto modeを使うと、危険を伴う操作のたびに承認を求めることなく作業を続けられます。実行前には、より小さな判断モデルである分類器が、シェルコマンドやネットワークリクエストなどの操作をチェックします。

2026年9月19日のリリースまでは、API、Enterprise、対応するクラウドプロバイダーのセッションで、このチェックのために別のモデルリクエストが発生する場合がありました。そのリクエストはトークンを消費し、課金対象でした。エージェントがシェル操作やネットワーク操作を何度も実行すると、Claudeに依頼した本来の作業とは別に、安全レイヤーの利用料金が積み上がっていたのです。

バージョン2.1.278では別の経路が加わりました。Claude Codeは、セッションの通常のモデルリクエスト内で同じ安全判定を行うよう、サーバーに要求できます。このサーバー経路が有効なら、Anthropicでは分類器チェック分の課金は発生しません。

これはClaudeのトークン料金の割引ではなく、API単価の引き下げでもありません。対象セッションで、分類器リクエストとして別途発生していたオーバーヘッドがなくなる変更です。

また、すべてのAPIユーザーやEnterpriseユーザーがauto modeに切り替わるわけでもありません。今回変わるのは、すでにauto modeを使っているセッションで、チェックをどこで実行するかです。権限モデル全体については、Claude Code Auto Modeで解説しています。

請求経路は二つに分かれます

今回の変更は、ルーティングによって課金結果が変わる仕組みとして捉えると明快です。

コストの計算もシンプルです。

対象セッションのコスト = 通常のモデル利用 + 個別料金が設定されたツールの利用。

フォールバックセッションのコスト = 通常のモデル利用 + 個別料金が設定されたツールの利用 + 分類器リクエストのトークン利用。

削減できるのは最後の項目です。Claude Code 料金の全額がなくなるわけではありません。

Anthropicは、セッションごとの削減額を一律には公表していません。普遍的な削減率を示しても、根拠のない数字になってしまいます。クライアント側のチェックでは、会話履歴の一部と実行待ちの操作が送信されます。通常の読み取りや作業ディレクトリ内の編集では分類器を使わないことが多く、オーバーヘッドの大半はシェルコマンドとネットワーク操作から生じます。そのため、ツールを多用する無人ジョブのほうが、短いコード確認セッションより削減額が大きくなる可能性があります。ただし、正確な金額は自社の利用記録から算出すべきです。

適用可否はアカウントではなくセッションで決まります

Claude Codeは、Enterpriseプラン、Claude APIアカウント、Claude Platform on AWS、Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundry、ゲートウェイ経由のセッションで、標準でサーバー側チェックを要求します。対象範囲は広く見えますが、これらのプラットフォーム上の全セッションが現時点で利用できるという意味ではありません。

プラットフォームのロールアウト状況、リージョン、認証情報、トラフィック経路がすべて影響します。Bedrock、Agent Platform、Foundry、およびサインイン済みClaudeアプリのゲートウェイでauto modeを使うには、Claude Sonnet 5、Claude Opus 4.7以降、またはFableモデルも必要です。

そのため、2.1.278では/statusにAuto mode serverという行が追加されました。

• Enabledなら、セッション内のチェック対象操作をサーバーの判定が処理しています。分類器の追加料金は発生しません。
• Disabledなら、Claude Code独自の分類器リクエストにフォールバックしています。従来どおり、そのリクエストには課金されます。

この行は、プラン名やロールアウト告知よりも実用的です。そのセッションが実際にどちらの課金経路へ到達したかを確認できるからです。

最も問題が起きやすいのはゲートウェイです

サーバー経路を成立させるには、少量の制御データが往復の通信をそのまま通過する必要があります。既知のフィールドだけを転送するゲートウェイでは、通常のClaudeリクエストが動いていても、その制御データが削除されることがあります。

よくある原因は、リクエストヘッダーの書き換え、未知のボディフィールドの削除、レスポンスIDの変更、ストリーミングイベントからのキー消失です。この状態では、サーバーがチェック要求を受け取れないか、Claude Codeが判定結果を受け取れません。

互換性の要件は明確です。ゲートウェイは、safeguardsフィールドを含むリクエストヘッダーとボディフィールドを変更せずに通す必要があります。さらに、safeguard_resultsを削除したり、tool-use IDを書き換えたりせず、レスポンスとストリーミングイベントを返さなければなりません。ゲートウェイ互換性ガイドでは、将来のClaude Code機能で新しい項目が増える可能性があるため、フィールドとヘッダーをオープンリストとして扱うよう案内しています。

この通信経路が壊れても、auto mode自体が失敗するわけではありません。Claude Codeは独自の分類器へフォールバックし、課金に関する通知を表示します。作業が継続する点では有益ですが、予算上は見落としやすい挙動です。エージェントは動き続ける一方で、追加の利用料金が再び発生します。

四つのチームで運用を変える必要があります

LLMゲートウェイを運用するプラットフォームチーム

代表的なClaude Codeセッションを一つ選び、互換性テストに使います。/statusがDisabledなら、予測値を変える前に、ゲートウェイのリクエスト変換とストリーミングレスポンス変換を調べてください。

得られる効果は、現在の分類器料金をなくすことだけではありません。未知のフィールドを改変せずに通す設計にすれば、次のClaude Code機能が同じ境界で壊れるリスクも抑えられます。

エージェント業務を予測するFinOps責任者

見積もりを、通常のモデル支出と分類器のオーバーヘッドに分けます。後者を削除するのは、サーバー経路が有効と表示されたセッションだけです。

これにより、ゲートウェイが妨げている削減分を先に計上する誤りと、サーバーへ移行した後も分類器の予算を確保し続ける誤りの両方を防げます。モデルやプラン全体の金額は、引き続き主要なClaude Codeの料金モデルに含めてください。

複数リージョンへ展開するEnterprise管理者

一度だけ機能を承認し、すべての拠点、プロバイダーアカウント、認証情報で同じように動くとは考えないでください。開発者が実際に使う各経路で同じ確認を行います。

そうすれば、プラットフォームのロゴではなく、実セッションに基づく簡潔な適用可否マトリクスを作れます。サーバー側チェックがまだ展開されていないリージョンは、設定に問題がなくてもフォールバック経路に残ることがあります。

無人ジョブを動かすAgent SDKチーム

対話型ターミナルでは通知で処理が止まることがあります。非対話型の-p実行ではstderrに出力され、stream-jsonではAgent SDKアプリが読み取れるsystem警告として送られます。

このシグナルをログまたはテレメトリーに記録してください。そうしないと、ワークフローは成功し続け、課金のフォールバックに気づくのは支出が発生した後になります。

予算を変える前に実際の経路を監査します

正直に押さえておくべき限界

今回のリリースで変動費の一部はなくなりますが、エージェント予算から差し引ける固定の割合は示されていません。ベースモデルは引き続き、通常料金でコンテキストを読み、推論し、出力を書き、ツールを使います。セッション料金の大半は通常、これらの費用です。

適用可否は、自社で制御できない境界でも変わり得ます。クラウドプラットフォームでは、特定のリージョンや認証情報への展開が完了していない場合があります。ゲートウェイ事業者側で、パススルー動作の更新が必要なこともあります。どちらの場合も、Claude Codeは安全チェックを続け、フォールバックリクエストへの課金も続けます。

ゲートウェイがサーバー経路に対応できないと分かっているチームには、オプトアウト設定があります。

export CLAUDE_CODE_AUTO_MODE_SERVER=0

この設定を使うと、Claude Codeはサーバー側チェックを要求しなくなり、フォールバック通知も消えます。その一方で、課金対象のクライアント側分類器経路を意図的に使い続けます。通知を抑えるための設定であり、コスト削減の設定ではありません。Anthropicは一時的な設定とも明記しており、Anthropic APIへの直接接続では無視されます。

週明けにやること

API、Enterprise、プロバイダー経由、またはゲートウェイ経由のClaude Code展開を担当しているなら、今週中に対応してください。実際の経路を一つ選んで2.1.278以降へ更新し、auto modeセッションを実行して/statusを確認します。分類器のオーバーヘッドを予算から外す前に、ゲートウェイのリクエストとレスポンス処理も検証してください。

/statusがDisabledで、修正できるゲートウェイもない場合は、プラットフォーム、リージョン、または認証情報への展開を待ちます。待機中は、分類器の費用を予測に残してください。

Pro、Max、Teamを使っている場合、今回のリリースで分類器の予算は変わりません。これらのプランでは、分類器のオーバーヘッドはすでに無料です。auto modeを使わないチームにも影響はありません。

次のプラットフォーム変更も実務上の判断へ落とし込んで読みたい方は、ニュースレターにご登録ください。