Claude Code v2.1.278のAuto modeで、server-side classifierの課金判定を/statusから確認する手順を解説。/usage、ゲートウェイ、OpenTelemetryまで業務導入の確認点を整理。

結論：2026年9月19日現在、Claude Code v2.1.278では、Auto modeの安全判定がサーバー側で処理される接続ならclassifierのオーバーヘッドは課金されません。まず /status の「Auto mode server」を確認し、Enabled ならその状態を記録、Disabled なら課金されるローカル判定にフォールバックした理由を切り分けます。

最初に見る場所：/status の「Auto mode server」行。
注意すべき条件：v2.1.278以降でも、プラン・クラウド基盤・地域・認証経路によってサーバー側判定が未提供のことがあります。
管理者の判断：ゲートウェイがリクエストやレスポンスのフィールドを壊していないか、/usage と公式の請求画面を分けて確認します。

対象読者：Claude Codeを業務導入するエンジニア、開発基盤担当、FinOps担当、チームリード。今日やること：検証用セッションで /status と /usage を開き、接続方式・バージョン・判定状態を1行の台帳に残してください。

2026年9月19日時点で何が変わったか

Claude Codeの公式changelogでは、v2.1.278が2026年9月19日付で案内されています。このリリースでは、Claude API・Enterprise、Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundry、ゲートウェイ経由のAuto modeが、条件を満たす場合にserver-side classifierを既定で使うよう変更されました。サーバー側の判定はclassifierのオーバーヘッドを課金しない設計です。

従来のローカルclassifier課金と、v2.1.278でサーバー側判定が既定になった状態を左右で対比し、フォールバック時は従来どおり課金される点を添えた図。

ただし「v2.1.278に更新すれば必ず無料になる」という意味ではありません。公式ドキュメントは、サーバー側チェックがセッションに届かない場合、従来どおりClaude Code自身のclassifier requestへフォールバックし、そのリクエストは以前と同じように課金されると説明しています。

今回の変更を一文で整理する

見るべきなのはAuto modeの有無ではなく、そのセッションの安全判定を誰が実行しているかです。モデルの応答トークンや通常のツール実行費用が消えるわけではなく、判定経路の扱いが変わりました。

既存のAuto mode標準化記事との違い

Auto modeの有効化やチーム標準化は、既存のClaude Code auto mode標準化の記事で扱っています。本記事はその続編として、2026年9月19日の更新で追加された「サーバー側判定・課金フォールバック・確認手順」に絞ります。

最初の5分で行う判定フロー

本番の設定を変える前に、同じ認証経路・同じゲートウェイ・同じプロバイダーで短い検証セッションを開きます。ここで確認するのは、Claude Codeのバージョン、permission mode、接続方式、Auto mode serverの4点です。

検証セッションを開いてからバージョン確認、/statusのAuto mode server確認、/usageと請求の正本の切り分けまでを4段の流れで示した図。

1. バージョンを固定する

claude --version

公式changelog上の基準はv2.1.278です。組織内で複数のCLIやIDE拡張を使う場合、古いバンドルCLIを実行していないかも確認します。バージョン文字列を台帳に残し、アップデート前後の比較をできるようにします。

2. Auto modeの状態を開く

セッション内でAuto modeを選択し、次に /status を実行します。v2.1.278では、Auto mode serverという行が追加されました。Enabled はサーバー側classifierが判定している状態、Disabled はローカル側のclassifierへフォールバックしている状態です。

/status

3. 使用量の表示を請求額と混同しない

/usage のSession欄は、現在のセッションのトークン使用量からローカルに推計した金額を表示します。公式ドキュメントは、権威ある請求額はClaude ConsoleのUsageページで確認するよう案内しています。ProやMaxなどのサブスクリプションでは、Session欄のドル表示が請求の意味を持たない場合もあります。

/usage

したがって、/status は判定経路、/usage はセッションの利用状況、管理コンソールは請求・組織利用の正本、と役割を分けて読みます。

Auto mode serverがDisabledになる理由

Disabledを見たとき、すぐに「設定ミス」と決めつけないでください。公式ドキュメントは、プラットフォームや地域、認証情報でserver-side checksがまだ提供されていない場合と、ゲートウェイやプロキシが通信内容を変更している場合を挙げています。

Disabled表示の原因を提供状況・ゲートウェイのフィールド削除・通知時の操作の三段の審査として切り分ける図。

プラン・基盤・地域の提供状況

v2.1.278の公式説明では、EnterpriseやClaude APIだけでなく、Bedrock、Google CloudのAgent Platform、Microsoft Foundryなどが対象です。ただし、プラットフォームや地域のロールアウト状況によって異なります。Pro、Max、Teamではこの課金フォールバック通知は表示されないとされています。自社の接続方式を別の方式の資料から推測せず、実際のセッションの表示を記録します。

ゲートウェイがフィールドを落としている

最も実務的な切り分けポイントは、LLM gatewayやforward proxyです。公式ドキュメントは、未知のリクエストフィールドを削除・書き換えたり、レスポンスやストリーミングイベントのキーを落としたり、tool-use IDを書き換えたりすると、サーバー側チェックが届かなくなる可能性を説明しています。

特に、server-side checkに関係する safeguards リクエストフィールドや safeguard_results レスポンスフィールドを、プロキシが「未使用のフィールド」として削除しないことが重要です。これはゲートウェイを再構築する指示ではなく、既存の透過性を点検する観点です。

通知が出たときのEnterとEsc

「このセッションはAuto modeのclassifier requestが無料扱いの対象ではない」という通知が出た場合、Enterは保留されていたアクションを続行し、以後のセッションを従来のclassifier requestで進めます。EscまたはCtrl+Cは保留アクションと現在のターンを止めます。安全判定の経路を変えたい場合は、Enter後に Shift+Tab でpermission modeを変更します。

環境別の運用設計

チーム導入では、個人のCLI設定と組織のコスト管理を分けます。Auto mode serverの表示を全員に同じ値にすることより、接続方式ごとに「どの表示を正本とするか」を定義する方が事故が少なくなります。

Anthropic API・Enterpriseで使う場合

まずv2.1.278以降を配布し、検証用の代表セッションで /status を確認します。EnterpriseやAPI経由ではserver-side checksが既定対象ですが、認証経路や組織のゲートウェイによってはDisabledになる可能性があります。組織の請求確認はConsoleやEnterpriseの利用分析を使い、ローカル表示だけで月次請求を確定しません。

Bedrock・Vertex・Foundryで使う場合

クラウドプロバイダー経由の利用は、Claude Codeの表示とクラウド側の請求を二層で管理します。公式ドキュメントでは、v2.1.278以降、これらの経路でserver-side classifierを既定にする変更が案内されています。一方、認証・地域・ゲートウェイの条件でDisabledになる場合があるため、検証の証跡にはプロバイダー名とリージョンを含めます。

ゲートウェイ経由で使う場合

ゲートウェイは、コスト配賦・アクセス制御・監査の中心になり得ます。そのぶん、機能の透過性と課金判定の両方をテストします。設定を変更する前に、リクエスト／レスポンスのフィールド保持、ストリーミングイベントのキー、tool-use IDの不変性、Auto mode serverの表示を確認します。

チームで使える確認台帳の設計

「無料になった」「コストが下がった」といった結論を先に共有するのではなく、判定経路と請求の根拠を分けた台帳を作ります。次の項目なら、個人情報や秘密値を記録せずに比較できます。

項目	記録例	用途
確認日	2026-09-19	changelogとの対応
Claude Code	v2.1.278	機能の前提
接続方式	API / Bedrock / gateway	提供条件の切り分け
Auto mode server	Enabled / Disabled	判定経路の証跡
利用量	`/usage` の表示	セッション比較
請求の正本	Console / クラウド請求	月次精算

比較時に固定する条件

同じリポジトリ、同じモデル、同じpermission mode、同じゲートウェイ、同じ作業内容で比較します。モデルやコンテキスト量が変わるとトークン使用量も変わるため、Auto mode serverの切替だけの影響と断定できません。

記録に残さないもの

APIキー、Cookie、OAuthトークン、Authorizationヘッダーの値は台帳に書きません。必要なのは接続方式の名前、設定の有無、表示された状態、確認日時です。ログを共有する場合も、秘密値とプロンプト本文をマスキングしてから扱います。

コスト管理を広げるならOpenTelemetry

server-side classifierの課金有無だけでは、チーム全体のClaude Codeコストは説明できません。公式のコスト管理ドキュメントは、トークン使用量、モデル、prompt cache、組織の制限を別々に追跡する考え方を示しています。複数ユーザーの利用を自社の観測基盤で把握するなら、OpenTelemetryが候補になります。

最小構成の環境変数

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://collector.example.com:4317

上記は公式Monitoringドキュメントの構成例を短くしたものです。実際のエンドポイントや認証ヘッダーは自社の管理対象に置き、記事やリポジトリに実値をコミットしません。検証には、セッション開始時の claude_code.session.count や claude_code.user_prompt イベントが届くかを使えます。

テレメトリで注意すること

Claude Codeは、OTEL_* 環境変数をBash、hooks、MCPサーバーなどの子プロセスへそのまま渡しません。子プロセス側のアプリも観測したいなら、そのプロセスに必要な環境変数を別途設定します。また、ユーザープロンプト、ツール詳細、API bodyの記録は内容漏えいにつながるため、デフォルトの秘匿設定を確認してから有効化します。

modelPricingは請求書ではない

組織の契約単価をClaude Codeの表示に反映したい場合、公式にはmanaged settingの modelPricing が案内されています。これは表示・テレメトリ上の報告レートを合わせる設定で、Anthropicが請求する金額そのものを変更しません。契約単価を記事本文に固定値として書くのではなく、管理者が自社の契約に合わせて設定します。

実装時に使える確認プロンプト

次のプロンプトは、Claude Codeに自社の構成を点検させるための下書きです。モデルに判断を丸投げせず、出力された項目を公式ドキュメントと管理者のログで照合してください。

セッション状態を整理する

現在のセッションについて、次の項目だけを表にしてください。
1. Claude Codeのバージョン
2. permission mode
3. /status に表示された Auto mode server の状態
4. 接続方式として利用者が明示した情報
5. 追加確認が必要な項目
秘密値、Authorizationヘッダー、Cookie、プロンプト本文は出力しないでください。
不明な項目は「不明」と書き、推測で埋めないでください。

ゲートウェイの点検項目を作る

Claude CodeとLLM gatewayの互換性確認項目を作ってください。
対象は、未知のリクエストフィールド、レスポンスのキー、ストリーミングイベント、
tool-use IDの書き換え、safeguards、safeguard_resultsです。
実際に確認していない結果は書かず、「確認方法」と「合否欄」だけを出してください。

コストの説明文をレビューする

次の説明文をレビューしてください。
- classifierのオーバーヘッド
- 通常のモデル・ツール利用のトークン費用
- /usageの推計値
- Consoleまたはクラウド請求の正本
これらを混同している文を指摘し、根拠がない数字は削除してください。

障害時のログをマスキングする

このログから、APIキー、Cookie、Authorizationヘッダー、個人情報、プロンプト本文を除外し、
バージョン、接続方式、HTTPステータス、再現手順だけを残してください。
不明な値は [REDACTED] と表示してください。

よくある失敗パターンと回避策

失敗1：v2.1.278なら全員が自動で非課金だと思う

❌ バージョンだけを見て、Auto mode serverの状態を確認しない。
⭕ /status のEnabled / Disabled、接続方式、プロバイダー、確認日をセットで記録する。

サーバー側判定は提供条件と通信経路に依存します。Disabledなら、課金される可能性のあるclassifier requestを含む従来経路が使われるため、通知内容を無視して「無料」と説明しないことが重要です。

失敗2：/usageの金額を請求額として精算する

❌ セッション画面の推計値を月次請求の正本にする。
⭕ APIならConsole、クラウドプロバイダーなら各クラウドの請求画面、Team / Enterpriseなら組織の利用分析を使う。

公式ドキュメントは、/usage のドル表示がローカル計算の推計であることを説明しています。契約単価を反映した modelPricing を使う場合も、請求書と同一視しません。

失敗3：ゲートウェイのunknownフィールドを削除する

❌ スキーマにないフィールドを安全のために削除する。
⭕ 公式のgateway compatibility guideに沿って、リクエストボディ、レスポンス、ストリーミングイベントを透過的に扱えるかテストする。

機能追加で未知フィールドが増えるたびに、プロキシが機能を壊す可能性があります。許可リスト方式の変換を採るなら、アップデート時の互換性テストをCIに組み込みます。

失敗4：コスト削減率を未測定のまま公開する

❌ 「判定がサーバー側になったのでコストが何％下がった」と書く。
⭕ 測定していない数値は書かず、判定経路の変化と公式の課金説明だけを記載する。

実際の支出は、モデル、コンテキスト、cache hit、ツール回数、プラン、ゲートウェイ、同時実行数で変わります。Auto mode serverのEnabledは、チーム全体の請求が一定割合下がる保証ではありません。

導入チームの7項目チェックリスト

Claude Code v2.1.278以降か確認する。
検証セッションでAuto modeを選択する。
/status のAuto mode serverを記録する。
Enabled から Disabled になった時刻と経路を記録する。
/usage の表示とConsoleまたはクラウド請求を分けて管理する。
ゲートウェイが safeguards、safeguard_results、ストリーミングキー、tool-use IDを壊していないか確認する。
チーム共有資料には、確認日・対象プラン・接続方式・未確認事項を併記する。

この7項目を通過したら、次に利用者別のトークン・ツール・モデル使用量を観測します。Auto modeの判定経路とチームのFinOpsを同じ指標にしないことが、導入初期の混乱を減らします。

検証を自動化する実装パターン

毎回人が画面を見て終わりにすると、CLIの更新や経路変更のたびに確認が抜けます。ここでは、判定結果を自動で請求額に変換するのではなく、導入前の確認項目を機械的に揃える方法を考えます。目的は、バージョン・経路・表示状態を同じフォーマットで残し、Disabledに変わったときに調査を始められるようにすることです。

検証コマンドは読み取り専用にする

自動チェックでは、最初から設定変更やアップデートを実行しない方が安全です。バージョンの取得、設定ファイルの存在確認、接続方式のラベル出力だけを行い、Auto modeの切り替えは利用者がセッション内で明示します。特に本番のgateway設定を、確認スクリプトから書き換えない設計にします。

#!/usr/bin/env bash
set -eu
printf 'checked_at=%s\\n' "$(date -Is)"
printf 'claude_version='
claude --version
printf 'gateway_config_present='
if [ -n "${ANTHROPIC_BASE_URL:-}" ]; then printf 'yes\\n'; else printf 'no\\n'; fi
printf 'auto_mode_server_env='
if [ "${CLAUDE_CODE_AUTO_MODE_SERVER:-}" = "0" ]; then printf 'opted_out\\n'; else printf 'default_or_unknown\\n'; fi

この例は、接続先の秘密値を表示せず、環境変数の「設定済みかどうか」だけを出します。実際の運用では、claude --version の結果と、セッション内で確認した /status の値を同じ記録に追記します。

Disabledを異常終了にしない

Disabledは、ただちに障害を意味しません。提供状況、認証方式、地域、プロキシの仕様によって正常に起こり得るため、検証スクリプトはDisabledを「要調査」として扱います。自動的に「課金された」と断定するのではなく、公式通知の有無、接続経路、管理者向け請求データを次の調査へ渡します。

# 擬似的な判定結果の扱い
status=Disabled
case "$status" in
  Enabled)  result=server_side_check ;; 
  Disabled) result=investigate_fallback ;; 
  *)        result=unknown ;; 
esac
printf 'result=%s\\n' "$result"

CIでは公式仕様の差分を検知する

ゲートウェイを運用するチームは、Claude Codeのchangelogとgateway compatibility guideの更新をリリース確認に含めます。未知フィールドを許容する透過テスト、ストリーミングイベントのキー保持テスト、tool-use IDの不変性テストを分けて実行します。テストの目的は「無料」を保証することではなく、新しい安全判定機能を中継層が壊していないことを検知することです。

なお、実際のAPIリクエストに秘密値や利用者のプロンプトを含めたまま、第三者のログ基盤へ送ってはいけません。テスト用のダミー入力、短いセッション、マスキング済みの観測データを使い、保存期間とアクセス権も先に決めます。

結果をチケットへ渡す最小フォーマット

フィールド	内容
checked_at	確認日時（タイムゾーン付き）
cli_version	`claude --version` の結果
provider_route	API、Bedrock、Vertex、Foundry、gatewayなどの分類
auto_mode_server	セッションの `/status` の表示
notice_seen	classifier request課金通知の有無
next_check	サポート、管理者、プロキシログなど次の確認先

このフォーマットなら、ログ本文や認証情報をチケットに貼らずに、調査の開始点を共有できます。月次のコストレビューでは、ここに管理コンソールの集計を別の欄で紐づけ、セッションの推計値と請求額を混ぜないようにします。

権限・安全性とコストを同時に扱う

Auto modeは、ツール呼び出し前の安全判定を自動化する機能です。コストだけを理由に有効化したり、反対に課金フォールバックを避けるために安全設定を弱めたりするものではありません。Claude Codeの公式Permissionsドキュメントでも、権限ルールはモデルの文章ではなくClaude Code自身が強制すると説明されています。

安全判定と承認ルールの役割を分ける

permissions.allow、ask、denyは、ツールを許可・確認・拒否するためのルールです。Auto modeのclassifierはその実行前の判定経路の一つであり、組織のdenyルールや秘密情報の取り扱いを置き換えません。チームの設計資料では、権限ポリシー、Auto modeの利用条件、コスト監視を別セクションにします。

コスト上限を先に決める

APIやクラウド経由では、組織のワークスペース制限、クラウドの予算、gatewayの上限など、請求を止める仕組みを先に決めます。Claude Codeの公式コスト管理ページは、モデル選択、コンテキスト管理、prompt cache、OpenTelemetryを組み合わせてコストを管理する方法を説明しています。Auto modeのclassifier経路だけで全体の上限を設計しないでください。

設定変更のレビュー項目

変更対象が個人設定、プロジェクト設定、managed settings、gateway設定のどこか。
変更により権限モード、外部通信、ログ保存、請求経路のどれが変わるか。
EnabledからDisabledになった場合の調査担当と切り戻し手順が決まっているか。
APIキーやAuthorizationヘッダーをログ・チケット・記事に残さないか。

「課金が減るかもしれない」という理由だけでゲートウェイのフィールド変換を追加するより、まず透過性のテストと請求データの照合を用意する方が、導入後の説明責任を果たしやすくなります。

現場で迷いやすい表示の読み分け

Claude Codeには、セッション画面・ステータス・管理コンソール・OTelという複数の情報源があります。表示が違って見えたときは、どれが「現在の判定経路」を示し、どれが「請求・利用の集計」を示すかを確認します。

Auto mode serverの表示

これは当該セッションのAuto mode classifierがどこで処理されているかを確認する表示です。Enabledでも、通常のモデル出力やツール利用のトークンが無料になるわけではありません。Disabledでも、Claude Codeが動かなくなるとは限りません。公式通知どおり、従来のclassifier requestを使って継続する場合があります。

/usageのSession欄

Session欄は現在のセッションのトークン、キャッシュ、モデル別内訳を見るための画面です。公式ドキュメントでは、表示金額はローカルで計算する推計であり、契約単価を設定した場合でも請求書ではないとされています。ProやMaxでは、プランの利用状況とAPIのドル表示を混同しないようにします。

管理コンソールとクラウド請求

API利用の請求はConsole、TeamやEnterpriseの組織利用は管理画面、Bedrock・Vertex・Foundryは各クラウドの請求画面が根拠になります。どの画面を月次精算の正本にするかは、契約と社内経理のルールで決めます。Claude Codeのローカル表示をそのまま経費精算の証憑にしないでください。

OpenTelemetryのイベント

OTelは、セッション数、トークン、ツール活動などを自社の観測基盤へ送るための経路です。利用者別の傾向を把握できますが、collectorの設定が誤っていると欠測や過剰なログ保存が起きます。まずレッドアクションとして、ユーザープロンプトやtool contentを既定で秘匿し、必要性をレビューしてから追加の記録を有効にします。

変更を社内展開するときのリリースノート

最後に、開発者へ通知するときの文面に含めるべき情報を整理します。短い通知でも、バージョンと判定状態を明示すると、サポート問い合わせの往復を減らせます。

最低限伝える内容

対象バージョン：公式changelogの対象リリース。
対象経路：Anthropic API、Enterprise、クラウドプロバイダー、gateway。
確認手順：Auto modeを選択し、/status のAuto mode serverを確認。
Disabled時の扱い：通知を読み、必要なら管理者またはgateway担当へ連絡。
請求確認：/usage はセッション確認、請求額は組織の正本で確認。

書いてはいけない断定

「全ユーザーが無料」「Auto modeなら請求ゼロ」「Enabledなら月額が一定割合下がる」「/usageのドル表示が請求額」という表現は、公式資料から導けません。接続方式やプランを明記せずに断定すると、読者の環境で再現しないだけでなく、予算管理を誤らせます。

更新後の問い合わせテンプレート

対象：Claude Code v2.1.278以降
接続方式：API / Bedrock / Vertex / Foundry / gateway
確認日：YYYY-MM-DD（タイムゾーン）
/status の Auto mode server：Enabled / Disabled / 未確認
通知の有無：あり / なし
/usage の確認：済 / 未確認
請求の正本：Console / クラウド請求 / 組織管理画面
秘密値：記載しない

このテンプレートは、サポートへ送る情報を限定するためのものです。ログの添付が必要な場合は、秘密値、プロンプト、個人情報、リポジトリ固有の機密を除外してから共有します。

結論と次の一歩

2026年9月19日時点のClaude Code v2.1.278では、Auto modeのserver-side classifierが有効なセッションではclassifierのオーバーヘッドが課金されません。反対に、サーバー側チェックが届かないセッションは従来のclassifier requestへフォールバックするため、/status の確認なしに「非課金」と判断できません。

今日：代表セッションで claude --version、/status、/usage を確認する。
今週：API・クラウド・ゲートウェイ経路ごとに、Disabledの原因と請求の正本を台帳化する。
今月：必要ならOpenTelemetry、managed settings、ゲートウェイ互換性テストを組み合わせ、利用者別の観測に進む。

Claude Codeの導入で権限やチーム運用まで整理したい場合は、チーム導入を安全に進める手順、利用量の見方はトークン使用量とprompt cacheの記事も参照してください。個別の導入条件は、お問い合わせフォームから前提環境を添えて相談できます。

運営元 Uravation よりこの事例を自社の業務で試す場合のテーマ選定・評価・本番移行の確認項目を、無料のチェックリストにまとめています。 Claude Code業務自動化PoCチェックリストを受け取る（無料）

参考・出典

Claude Code changelog — v2.1.278（2026年9月19日）、v2.1.277（2026年9月18日）
Auto mode classifier request charges — server-side checks、通知、フォールバック、CLAUDE_CODE_AUTO_MODE_SERVER
Manage costs effectively — /usage、請求正本、組織のコスト管理
Monitoring — OpenTelemetryの設定、環境変数、データ秘匿
Configure permissions — permission mode、ルール、Auto modeとの関係
CLI reference — claude --version、-p、/status等のCLI運用

著者プロフィール

佐藤傑（さとう・すぐる）。株式会社Uravation代表取締役。X（@SuguruKun_ai）で生成AI・Claude Codeの活用情報を発信し、企業向けAI研修・導入支援を行う。技術記事では、公式ドキュメントで確認できる仕様と、測定していない想定を分けて紹介している。

読者向けの3アクション

確認する：チームの代表環境で /status のAuto mode serverを確認する。
共有する：接続方式・確認日・請求の正本を含む台帳テンプレートを開発基盤チームと共有する。
相談する：ゲートウェイ互換性、OpenTelemetry、managed settingsの設計条件を整理してから相談窓口へ送る。