# 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 ` / ツールの `--cwd` を使う。1呼び出し1コマンド。 2. `2>&1 | tail` `| head` などのパイプ後処理を付けない。 3. 使い捨てスクリプトは heredoc で流さず、scratchpad にファイルとして書いて `node ` で実行する。 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 でゼロになる。 ---