【重複購入のご注意】この記事は「AI開発者の手帖」がnoteで販売している同名記事（auto modeの「対象外」通知の判定手順）と同じ内容です。すでにnoteで購入・閲覧できる方は重複購入にご注意ください。
auto modeで「this session isn't eligible」という通知が出た方に向けて、条件を整理します。Claude Code 2.1.278（2026年9月19日）で、auto modeの安全チェックをどこが実行するかが変わりました。これまではClaude Code自身が分類器へリクエストを送り、その分が課金されていました。
対象の環境では、サーバーがセッション自身のモデルリクエストの一部としてチェックを行い、サーバーが実行した分は課金されません。サーバーが実行する場合とClaude Code自身が実行する場合で判定内容が変わるかどうかには、言及がありません。公式changelog 2.1.278・公式ドキュメント（いずれも2026-09-20取得）
本稿は筆者が公式資料を照合して作った判断資料で、実行して確かめた結果ではありません。
サーバー側のチェックが届かないときは、Claude Codeは従来どおり自分の分類器リクエストを使い、課金も従来どおりです。その場合、操作が保留されて次の通知が出ます。
We're changing auto mode to no longer charge for classifier requests in Claude Code. However, this session isn't eligible.
（このセッションは対象外だ、という通知です。）公式ドキュメント（2026-09-20取得）
チェックが1回届かなかっただけでは出ません。 公式によれば、通知が出るのは「サーバーのチェックがそのセッションの残り全体に届かなくなったあと」で、「セッション最初のチェック対象操作という早い時点でも起こりうる」。単発で届かなかった操作はClaude Codeが自分で処理し、次のリクエストではまたサーバーへ尋ねます。
2本の道は環境の固定的な区別ではなく、同じセッションが操作ごとに行き来します。下の図では、Claude Code自身を「手元のツール」、Claude Code自身が実行することを「手元でチェックする」と書いています。下の道に入っても、通知が出るのは残り全体で届かなくなったときだけです。上の道でも、届かなかった個々の操作の分は例外です（次の「現状を読む一行」）。
誰に関係する話か
サーバー側チェックが既定で要求されるのは、Enterpriseプラン、Claude APIを使うアカウント、そしてClaude Platform on AWS・Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundryです（changelogの列挙は範囲が一致しません。差は有料部で扱います）。実行されるかは展開状況によります。公式は「Pro, Max, and Team plans never show the notice」とも書いています。Pro・Max・Teamだけなら、この通知は出ません。
もう一つ、課金より手前の条件があります。Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry・サインイン済みのClaude appsゲートウェイのセッションでは、auto modeが使えるモデル自体がClaude Sonnet 5・Opus 4.7以降・Fable系に限られます。この4つの環境で対象外のモデルを使っているなら、分類器の課金以前にauto modeが動きません。
このうちClaude Platform on AWSについては、変数で止める方法が公式に書かれていません（取れる対応は有料部で扱います）。
向かないのは、auto modeを使っていない方と、Pro・Max・Teamのみの方です。中継（LLMゲートウェイやプロキシ）の設定を自分で変えられず依頼先もない方は、有料側の素通し（リクエストとレスポンスを変えずに通すこと）を依頼する節は使えませんが、通知そのものを止める設定（結論2）と確認先の案内は当てはまります。直結の判定例は、前提が違っても前提→理由→結論の組み立て方として読めます。
現状を読む一行
auto modeのセッションで /status を実行すると、2.1.278で追加された Auto mode server の行があります。サーバーのチェックが判定している間は Enabled、フォールバック後は Disabled です。公式が Disabled の条件として書いているのはフォールバック後だけで、サーバー側チェックをそもそも要求していないセッション（Pro・Max・Teamなど）に何が表示されるかは記載がありません。Enabled が示すのは現在サーバーが判定していることまでです。届かなかった操作はClaude Codeが自分で処理するため、その分は従来どおり課金されると読めます（原文が書いているのは実行主体までです）。全操作の課金ゼロを保証する表示ではありません。
判定の一例——Anthropic APIへ直結している場合
公式は CLAUDE_CODE_AUTO_MODE_SERVER について「The variable isn't read on a direct connection to the Anthropic API」と書いています。直結ではこの変数が読まれないので、CLAUDE_CODE_AUTO_MODE_SERVER によるオプトアウトはできません。公式は CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 でも（当該変数が未設定のとき）サーバー側チェックが切れると接続方式を限定せずに書いていますが、直結でこの設定に頼れるかは公式に明示がありません。中継がないので、ゲートウェイを直す道もありません。残るのは、公式が案内する確認先（サポート、自社の管理者、/feedback）へ回すことと、auto modeを続けるなら当面はEnterで答えて従来どおりの課金で進めることです。auto modeをやめるなら、答えたあとに Shift+Tab で権限モードを切り替えます。
前提（直結）→理由（変数が読まれず、直す中継もない）→結論（確認先へ回し、auto modeを続けるなら当面は受容）。経路が変われば結論も変わります。
限界
筆者の環境ではauto mode設定の自己観測が拒否され、通知の実表示も /status の実画面も取得できていません。節約額や割合は公式が量を示しておらず、書きません。
有料部分では、筆者の整理として判定手順と対応表、原因確認と暫定行動、オプトアウトの戻し方の落とし穴を、公式記載の整理としてEnterとEscの違い、素通し依頼の3項目、非対話モードの挙動をまとめます。状況は中継の有無と接続先で4通りに分かれ、行によって素通しの依頼・オプトアウト・受容と取れる対応が変わります。自分がどの行かは、プラン→中継の有無の順に見て、中継が無いときだけ接続先を見て決めます。
この記事の販売者
