Claude Codeのauto modeを支える安全分類器まわりが、2026年9月の3つの更新でまとまって整理されました。先に結論です。(1) 分類器は2.1.278でサーバー側が既定になり、審査分のオーバーヘッド課金は対象環境では消えました。(2) ただしLLMゲートウェイを挟んだ環境では無料にならない条件があり、確かめ方は /status の1行です。(3) そして2.1.280で、審査が「断った」ときは1回で打ち切り、「答えない」ときは10連続でターンを停止する、という止まり方が数字で規定されました。
対象読者は、auto modeやそれに近い自律実行でClaude Codeを回している人と、これから無人運用に組み込もうとしている人です。素材は公式changelogと課金の専用ドキュメント、それに自分の無人Routine運用で同じ形の設計をした判断です。
auto modeの安全分類器とは——allowでもdenyでもない審査の層
auto modeは、実行の可否を人間への都度確認ではなく、機械の審査に委ねて進める動作モードです。公式ドキュメントには、auto modeでは分類器（classifier）がシェルコマンドやネットワーク要求を実行前に審査する、と書かれています（Auto mode classifier billing、確認日2026-09-21）。
権限設定のallow / denyルールが「書いた条件に一致するか」で機械的に判定する静的な層だとすると、分類器は要求の内容を見て通す・止めるを決める動的な層です。ルールの層については以前整理したので、この記事では扱いません。
Claude Codeの権限設定4層ガイド｜denyを厚くするだけでは守れないClaude Codeの権限設定を「渡さない・許す・止める・外側で強制」の4層で設計する方法を解説します。allowルールのワイルドカード警告や--restrictedフラグなど直近の公式アップデートを根拠に、hooksによる禁止だけでは塞げない穴と、各層の使い分けを実運用の構成で整理します。www.tentspace.net
無人運用の立場でこの層を見ると、知っておきたいことは3つに絞られます。どこで動いているのか。いくらかかっているのか。そして、答えないとき何が起きるのか。 9月の更新はちょうどこの3つに順番に答えていく内容でした。確認した順に並べるとこうなります。
| 確認日 | 更新 | 決まったこと |
|---|---|---|
| 2026-09-20 | 2.1.278 | 分類器がサーバー側既定に。サーバー側で審査した分は課金されない。/status に「Auto mode server」行を追加 |
| 2026-09-21 | 課金の専用ドキュメント | 無料の対象と条件（ゲートウェイのsafeguards素通し）、フォールバック時の通知仕様 |
| 2026-09-23 | 2.1.280 | 審査が断ったら1回で打ち切り。無応答は10連続でターン停止 |
以下、順に見ていきます。
2.1.278で分類器はサーバー側が既定になった
まず「どこで動いているのか」と「いくらかかるのか」です。
changelogの2.1.278（確認日2026-09-20）で、auto modeの分類器はサーバー側で動くのが既定になりました。対象はClaude APIとEnterpriseのユーザー、およびBedrock・Vertex・Foundry・ゲートウェイ経由の接続です。サーバー側で行われた審査には、分類器のオーバーヘッド課金がかかりません（出典: Claude Code changelog）。
このリリースには確認手段も一緒に入っています。/status に「Auto mode server」の行が追加され、いま自分のセッションの分類器がサーバー側で動いているかを見られるようになりました。サーバー側に届かず課金されるフォールバックへ落ちた場合は警告が出ます。また、CLAUDE_CODE_AUTO_MODE_SERVER=0 でサーバー側への問い合わせ自体を止めるオプトアウトも用意されています。
要するに、審査という「成果物には現れない工程」の実行場所とコストが、既定で利用側の負担から外れた、という変更です。ここまでなら良い話で終わりです。
「無料」には条件がある——ゲートウェイがsafeguardsを落とすと課金のまま
ところが、この無料化を規定した専用ドキュメントを読むと、話は「無料になった」ではなく「条件を満たした環境だけ無料になる」でした（確認日2026-09-21）。
Claude Code公式ドキュメント: Auto mode classifier billingResolve the Claude Code notice saying this session isn't eligible for auto mode's no-charge classifier requests: what it means, why it appears, and what to do.code.claude.com
仕組みはこうです。2.1.278以降、審査はセッション自身のモデルリクエストの一部としてサーバーへ依頼され、サーバーが行った分は課金されません。サーバーへ届かない場合は従来どおりクライアントが自前の分類器リクエストを投げ、それは従来どおり課金されます。
そして、届かない原因として最も多いと名指しされているのが、途中に挟まったLLMゲートウェイやプロキシです。ヘッダを落とす、知らないフィールドを捨てる、IDを書き換える、ストリームイベントのキーを落とす——このどれかをやると失敗します。ドキュメントは具体的に、リクエストの safeguards フィールドとレスポンスの safeguard_results キーを素通しさせることを求めています。
対象範囲も明記されています。EnterpriseプランとClaude APIアカウント、およびAWS（Bedrock）・Google Cloud Agent Platform・Microsoft Foundry上のClaude Platformが対象で、Pro・Max・Teamプランにはこの通知自体が出ません。
フォールバック通知は1回しか出ない
無人運用の視点で一番効くのは、課金フォールバックへ落ちたときの通知の仕様です。
- 初回は対象アクションを保留して通知が出ます。ただしEnterで確認すると、そのセッションでは二度と出ません
- 通知にゲートウェイ名が出た場合は、同じマシンで24時間出ません
claude -pの非対話実行ではstderrへ、stream-jsonではsystem警告として出ます
つまり、通知の出口はどれも「人が常時見ていない場所」です。日次のRoutineを -p で回している構成なら、stderrをログに残して警告を拾う経路がないと、サーバー側で審査されているつもりが黙って課金側へ戻っていた、ということが起こり得ます。
私はSNS運用の無人化で「観測できていない状態変化が一番厄介」という失敗を繰り返し踏んできたので（運用の失敗10選に書いたとおりです）、この手の「1回出て消える通知」は成功通知より警戒しています。黙って変わるものには、気づくための出口を先に用意するしかありません。非対話実行の設計はヘッドレスモードの記事でまとめたとおり、出力の受け口を決めるところまでが組み込みです。
ゲートウェイが対応できないと分かっているなら、CLAUDE_CODE_AUTO_MODE_SERVER=0 で問い合わせ自体を止める選択肢もあります。ドキュメントはこれを一時的な設定と位置づけていて、直接接続では読まれません。
審査が「断る」「答えない」ときの止まり方が数字で決まった（2.1.280）
3つ目の「答えないとき何が起きるのか」に答えたのが、2.1.280（確認日2026-09-23）の2件の修正です。
- 審査が実行審査を断った場合: これまでは同じアクションを何度も再試行していました。修正後は1回拒否して打ち切り、再試行しても無駄であることを明示します
- 審査が答えを返さない場合: これまでは休みなく拒否を繰り返していました。修正後は再試行がバックオフし、10連続で無応答ならメッセージ付きでターンを停止します
修正前の挙動に注目してください。どちらも「何度も繰り返していた」と書かれています。審査に断られたアクションを延々と再試行する。無応答の審査に対して休みなく拒否を打ち続ける。審査層が結論を返さないケースの挙動が決まっていないと、自律実行はこういう形の空回りになる、という実例がchangelogに残った格好です。
この2件が面白いのは、許可・拒否のほかに「審査側が機能していない」という第3の状態を仕様として認め、その始末を数字で決めたことです。断られたら1回、答えないなら10連続。しかも2つの状態で数字を分けています。「断られた」は審査層が明確な意思を返しているので即打ち切り、「答えない」は一時的な不調かもしれないのでバックオフしつつ上限で停止、という読み方ができる分け方です。審査をサーバー側の層へ出した2.1.278の直後のリリースで、その層が黙る・断るケースの規定が入った、という順番になっています。
なお、私の環境で10連続の無応答に実際に当たった記録はまだありません。ここは仕様の話として読んでください。
無人運用に持ち帰る——審査層が答えないときの挙動を自分でも決める
この一連の変更は、Claude Codeを使う話にとどまらず、自分でエージェントの審査層を作っている人への設計例でもあると読んでいます。
私の運用では、公開前審査をcriticという読み取り専用の審査役に分離しています。そこで最初に決めたのが上限の数字でした。同一対象の自動修正は2回まで、超えたら隔離して、呼び出し元の処理は止めずに次へ進む。審査が通らないものを無限に直し続けない、審査のために本流を止めない、という線引きです。auto modeの「1回で打ち切り」「10連続で停止」は、Claude Code本体が自分の審査層に対して同じ形の線を引いた変更だと理解しています。
AIエージェントの公開前チェックは2層に分ける｜決定的ルールとLLM審査の設計AIエージェントに公開作業を任せるときのチェック機構を「決定的に落とす層」と「LLMに判断させる層」の2層に分けて運用している実装記録。GitHubがalt textチェックで公開した同じ層分けの設計と突き合わせ、誤検知で審査が信用を失わないための逃げ道の作り方、PASSを床として扱う考え方をまとめます。www.tentspace.net
持ち帰りとして、点検は3つです。
/statusを開いて「Auto mode server」行を見る。Enabledか、Disabledか。確かめるのに必要なのはこの1行だけですclaude -pで回している経路があるなら、stderrをログへ残し、フォールバック警告に気づける出口を作る- 自分のシステムに審査層（LLM審査・外部の判定API）があるなら、「答えないときに何回・何秒で諦めるか」が数字で書いてあるかを棚卸しする。私も自分のRoutineを見返すと、回数の上限は書いてあるのに時間の上限を書いていない経路がまだ残っています
最後に、使うか使わないかの判断です。私は既定のまま使います。直接接続でゲートウェイを挟んでいない構成なら、課金の条件に触れる要素がそもそもなく、オプトアウトする理由もないからです。逆に、社内でLLMゲートウェイを挟む構成を選定する立場なら、safeguards / safeguard_results の素通し可否は選定チェックリストに足す項目になったと思います。ゲートウェイの「透過的です」という説明は、新しいフィールドが増えた瞬間に検証し直しになる——今回の変更はその具体例でもあります。
今回の更新の本体は「無料になった」ことではなく、審査の層がどこで動いているかを利用者が確かめられるようになったことだと思っています。確かめ方が1コマンドで済むようになった以上、確かめない理由はありません。