Claude Code の auto mode classifier に止められなくする — 実測に基づく3段階の根本対策

Claude Code を auto mode で運用すると、ツール呼び出しの一部が「auto mode classifier」（Anthropic 側の Sonnet が毎回の呼び出しを安全判定する仕組み）に拒否される。この指示書は、14日分の transcript を集計して拒否の原因を3つに分解し、それぞれを潰す手順をまとめたもの。AI にそのまま読ませて実行できる粒度で書いてある。

0. まず実測する（推測で直さない）

~/.claude/projects/*/*.jsonl の直近14日分を走査し、tool_result に auto mode classifier を含むものを数える。理由は Reason: [カテゴリ] の形で入っているので、カテゴリ別に集計する。合わせて、拒否された tool_use の command を取り出して眺める。

実測例（5,394 呼び出し中 246 拒否）:

• 理由なし「Blocked by classifier」168
• Credential Exploration 15 / Credential Materialization 10 / Permission Grant 8 / Production Deploy 8 / Modify Shared Resources 8 / Merge Without Review 6

1. 原因A: ルール文が classifier の禁止カテゴリを命じている

CLAUDE.md に「過去ログや .env から認証情報を復元せよ」「gh secret set で自動設定せよ」「PR はマージまで自走」「DM を自動送信」と書いてあると、それは classifier のカテゴリ名そのもの（Credential Exploration / Materialization / Permission Grant / Merge Without Review）になる。ルールに従うほど止まり、止まるたびに AI が言い換えて再試行するのでトークンとターンが増える。

対策:

• 認証情報は「探す」のではなく「取りに行く先を1本にする」。鍵配布サーバや env-kv のような専用ツール1本を allow に入れ、ルール文から「transcript を grep」「.env 直書き」を削除する。
• マージ・デプロイ・通知も専用スクリプト1本に統一し（例: CI 全成功を確認してから squash マージする pr-merge）、それだけを allow する。
• ルール文に「拒否されたら言い換え再試行をせず、classifier 拒否: <カテゴリ> と1行報告して次へ進む」と書く。

2. 原因B: cd X && cmd 連結で allow ルールが当たらない

permissions.allow に Bash(gh pr merge:*) があっても、実際の呼び出しが cd "/path" && gh pr checks … && gh pr merge … だと、連結の全部品が allow に一致しないため classifier に回る。理由なし拒否の大半がこれ。

対策（Bash 規約として CLAUDE.md に書く）:

1. cd X && 禁止。絶対パスか git -C <path> / ツールの --cwd を使う。1呼び出し1コマンド。
2. 2>&1 | tail | head などのパイプ後処理を付けない。
3. 使い捨てスクリプトは heredoc で流さず、scratchpad にファイルとして書いて node <file> で実行する。
4. until … sleep ポーリング禁止。バックグラウンド実行や gh pr checks --watch のような単一コマンドを使う。

allow ルールはコマンド族のプレフィックス形式にする（例）: Bash(gh pr:*) Bash(git -C:*) Bash(git status:*) Bash(node tools/*) Bash(node --test:*) Bash(cat:*) Bash(sed -n:*) Bash(grep:*) これを JSON（allow-rules.json）として repo に置き、セットアップ時に各PCの ~/.claude/settings.json へ冪等マージするスクリプトを用意すると全端末に配れる。

deny の副作用にも注意: Bash(git push --force*) は --force-with-lease を巻き込む。Bash(git push --force origin*) と Bash(git push -f*) に分ける。

3. 原因C: 「AI が自分の設定・許可・ガードを変える操作」は必ず止まる

allow を整えても、settings.json の許可を広げる編集、deny を緩める編集、ガード hook を緩める差分の git add は [Self-Modification] / [Permission Grant] で止まる。これは classifier の設計意図で、書き換えも迂回もできない。逆に、値を変えるだけの最小 Edit（effort の1行、CLAUDE.md、memory）は通る。

ここで2つの落とし穴がある:

• 一括操作が拒否されたことから、試していない個別操作まで「不可」と推定して人に手渡さない。手渡す前に目的の変更だけを最小単位で1回試す。
• 拒否は操作単位で評価される。障壁（hook・ブランチ・cooldown）を自分で取り除いた後は同じ操作を1回再試行する。

それでも止まる「緩める方向の変更」だけは人が行う。人に渡すときは、パッチスクリプト＋テスト＋コミット＋PR＋マージ＋反映確認を1つの .ps1 にまとめ、「この1行を実行」だけを渡す。

4. 最終手段: permission mode を bypassPermissions にして deny と hook で守る

「Claude 自身の運用基盤を直す作業」が月に何度も止まるなら、permission mode を bypassPermissions にして classifier を外し、安全装置を次の2層に置き換える判断がある。

• permissions.deny（bypass でも効く）: rm -rf、git reset --hard、git clean -f、force push、gh repo delete、curl … | sh、DB reset、Remove-Item -Recurse、.env 系ファイルの Read
• 自前の hook（permission mode と無関係に動く）: 内部宛メール送信ガード、危険モデル指定の禁止、完了報告前の検証ゲートなど

これは Anthropic 側の第二の目を外す決定なので、決定者・日付・理由・失うものを共通ルール文書に記録し、deny を先に強化してから切り替える。deny の追加（締める方向）は AI が自分で行ってよく、allow 追加・deny 削除・mode 変更（緩める方向）は人が行う、と役割を分けておく。

5. 効果測定

切り替えから7日後に §0 の集計を再実行し、拒否数を before/after で比べる。実測では原因A・Bで拒否の約9割が消え、原因Cは §4 でゼロになる。