はじめに
前回、Claude Codeのauto modeには専用のclassifier（判定用の別モデル）がいて、実行前に各アクションを審査している、という話を書きました。危険な操作を止めてくれるのはありがたいのですが、実際に使い始めると、すぐにひとつの壁にぶつかります。classifierが、あなたの会社のふつうの操作まで止めてくるのです。
理由はシンプルで、classifierは初期状態だと「作業ディレクトリと、いま開いているリポジトリのリモート」しか信頼しないからです。自社のGitHub Organizationへのpushも、チーム共用のクラウドバケットへの書き込みも、classifierから見れば「見覚えのない外部」に見える。だから止まります。
これを直す方法が、autoMode という設定ブロックです。「うちが信頼しているリポジトリ、バケット、ドメインはこれだよ」とclassifierに教えると、routineな内部操作でいちいち止まらなくなります。この記事は、その設定リファレンスです。前回が「classifierは何を見ているか」なら、今回は「classifierにどう文脈を渡すか」の話になります。
先に3行でまとめると
- classifierは初期状態だと自社インフラを「外部」扱いする。
autoMode.environmentで信頼先を教えると誤ブロックが減る - 止めたい操作はルールで明示。ブロックは
hard_deny（無条件）→soft_deny（意図で解除可）→allow（例外）→ ユーザーの明示的意図、の4段で決まる - 設定は
~/.claude/settings.jsonか管理設定に書く。リポジトリ内の.claude/settings.jsonからは読まれない（自分に権限を付けられないため）
この記事に出てくる用語の位置づけ
Claude Code独自の設定名と、一般用語を先に整理します。迷ったらここに戻ってきてください。
| 用語 | 位置づけ | ざっくりの意味 |
|---|---|---|
autoMode.environment |
Claude Code独自 | 信頼できるインフラを自然文で教える設定 |
hard_deny / soft_deny / allow
|
Claude Code独自 | classifier内部のブロック／例外ルール |
permissions.ask / deny
|
Claude Code独自 | classifierより前に評価される権限ルール |
$defaults |
Claude Code独自 | 組み込みルールをその位置に差し込む合言葉 |
classifyAllShell |
Claude Code独自 | すべてのシェルをclassifierに通す設定 |
| 管理設定（managed settings） | Claude Code独自 | 組織が全開発者に配る、上書きできない設定 |
| exfiltration（持ち出し） | 一般用語 | データを外部へ不正に送り出すこと |
| IaC | 一般用語 | Terraform等でインフラをコードとして管理する手法 |
Claude Code独自の設定名は「この製品でだけ通じる書き方」、一般用語は「セキュリティ記事で普通に出てくる言葉」と考えてください。
まず、pushやPRに人間チェックを足す
設定を凝る前に、いちばん需要が高い「pushやPR作成の前に一回止めてほしい」を片付けておきます。
auto modeは初期状態で、作業中リポジトリのどのブランチへのpush（デフォルトブランチ含む）と、PRの作成を許可します。ただし production・release・gh-pages のように、名前からデプロイ先や公開先とわかる非デフォルトブランチは対象外で、そこへのpushはclassifierが個別に判断します。加えて、どのブランチでもpushの中身は審査されるので、force pushやシークレットの混入はブロックされます。
便利な反面、勝手にpushされると困る現場もあります。そこで確実に止めたいなら、permissions.ask にルールを足します。内容を絞ったaskルールはclassifierより前に評価され、auto modeでも必ず確認プロンプトを出します。
{
"permissions": {
"ask": [
"Bash(git push *)",
"Bash(gh pr create *)"
]
}
}
境界の"固さ"に応じて、使い分けは3つです。
| 境界 | 手段 | auto modeでの挙動 |
|---|---|---|
| 実行前に確認したい | permissions.ask |
内容を絞ったルールなら必ず確認。classifierが勝手に承認できない |
| 絶対に走らせたくない | permissions.deny |
classifierより前でブロック。意図でもclassifierでも覆せない |
| このセッション限りの一回きり | 会話で伝える（「レビューまでpushしないで」） | classifierがブロック。ただし圧縮で発言が消えると失われる |
恒久的に守らせたいなら会話ではなくask/denyルール、というのが結論です。
設定はどこに書くか
autoMode は、どこに書いても読まれるわけではありません。ここを間違えると設定が無視されてハマります。
| スコープ | ファイル | 用途 |
|---|---|---|
| 開発者ひとり | ~/.claude/settings.json |
個人の信頼インフラ |
| 組織全体 | 管理設定（managed settings） | 全開発者に配る信頼インフラ |
--settings フラグ / Agent SDK |
インラインJSON | 自動化での都度上書き |
重要なのは、classifierがプロジェクト設定（.claude/settings.json や .claude/settings.local.json）からは autoMode を読まないことです。これらはリポジトリ内にあるので、もし読んでしまうと、チェックアウトしたリポジトリやビルド手順が自分に都合のいいallowルールを注入できてしまいます。リポジトリが自分に権限を付与できないように、あえて読まない設計です。
一方、classifierはCLAUDE.mdの内容はClaude本体と同じように読みます。だから「force pushは絶対しない」のようなプロジェクトの方針をCLAUDE.mdに書けば、Claude本体とclassifierの両方が同時にそれを踏まえてくれます。プロジェクト固有の振る舞いはCLAUDE.md、部門横断の信頼インフラは autoMode、という住み分けが基本です。
信頼できるインフラを教える
多くの組織にとって、設定すべきはほぼ autoMode.environment だけです。ここに書いた内容から、classifierは「何が外部で、何が内部か」を判断します。裏を返すと、ここに載っていない宛先はすべて、潜在的な持ち出し先として警戒されます。
claude auto-mode defaults を実行すると、environmentのスロット（枠）が3種類あることがわかります。
3種類の性格は、こう捉えると腹落ちします。コンテキスト枠は、classifierに「うちはこういう会社・環境です」と背景を渡すもので、それ自体を狙うルールはありません。信頼枠は、「これは内側だから触ってOK」と名指すもの。機微枠は、逆に「これは高リスクだから守れ」と名指すものです。機微枠は名指ししなくても初期状態でヒューリスティック（経験則）が効いていて、たとえばホスト名やネームスペースに prod や production が入っていれば、自動的に本番の宛先として扱われます。具体名を書くと、その経験則の代わりに、あなたが名指しした対象へルールが適用されます。
書き方は正規表現でもツールパターンでもなく、ただの自然文です。新しく入ったエンジニアに自分のインフラを説明するつもりで書けば大丈夫です。組み込みのデフォルトを残したまま自分の項目を足すには、配列に "$defaults" という文字列を入れます。そこにデフォルトが差し込まれるので、自分の項目はその前でも後でも構いません。
{
"autoMode": {
"environment": [
"$defaults",
"Source control: github.example.com/acme-corp and all repos under it",
"Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
"Trusted internal domains: *.corp.example.com, api.internal.example.com",
"Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
]
}
}
全部を一度に埋める必要はありません。現実的な進め方としては、まずソース管理のOrgと主要な内部サービスを足す。これで「自社リポジトリへのpushが止まる」という最頻出の誤ブロックが片付きます。次に信頼ドメインとクラウドバケット。残りは、実際にブロックが起きたときに埋めていけば十分です。書いたあとは claude auto-mode config で、狙いどおり反映されているか確認しておくと安心です。
ブロックと許可のルールを上書きする
environment で足りないとき、classifierの組み込みルールそのものを差し替える3つのフィールドがあります。hard_deny（無条件の安全境界）、soft_deny（意図で解除できる破壊的操作）、allow（soft_denyへの例外）です。いずれも自然文の配列です。
肝心なのが優先順位です。classifier内部では、4段のティア（階層）で決着します。
上から順に、hard_deny は無条件でブロックし、ユーザーの意図でもallow例外でも覆りません。soft_deny は次にブロックしますが、こちらは意図やallowで覆せます。allow は該当する soft_deny を例外として上書きします。そして最後に、ユーザーの明示的な意図が残りのsoft_denyを上書きします。
この「明示的な意図」がポイントで、ざっくりした依頼はカウントされません。「リポジトリを掃除して」ではforce pushは許可されませんが、「このブランチをforce pushして」なら許可される、という線引きです。あなたのメッセージが、Claudeがまさに実行しようとしている操作を直接かつ具体的に言い当てているかどうか、で判断されます。
{
"autoMode": {
"allow": [
"$defaults",
"Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly"
],
"soft_deny": [
"$defaults",
"Never run database migrations outside the migrations CLI, even against dev databases"
],
"hard_deny": [
"$defaults",
"Never send repository contents to third-party code-review APIs"
]
}
}
environment・allow・soft_deny・hard_deny のいずれかを "$defaults" なしで書くと、そのセクションの組み込みルールを丸ごと捨てることになります。たとえば soft_deny を "$defaults" なしで書けば、force push・curl | bash・本番デプロイ・auto modeバイパスといった組み込みの防御が全部消えます。ルールを全部自分で持つと決めたとき以外は、必ず "$defaults" を入れてください。
なお、各セクションは独立に評価されます。environment だけを設定しても、allow / soft_deny / hard_deny のデフォルトはそのまま残ります。組織として「これは絶対に走らせない」を貫きたいなら、classifierの hard_deny よりも、classifierより前でブロックする管理設定の permissions.deny を使うのが確実です。
すべてのシェルをclassifierに通す
ひとつ、地味だけど効く設定を紹介します。デフォルトでは Bash(npm test) のような内容を絞ったallowルールは、auto modeでもそのまま生きて、classifierを通らずに実行されます。便利な一方で、ルールの接頭辞が想定していなかった引数やフラグが、classifierに見られないまま通ってしまう隙があります。
autoMode.classifyAllShell を true にすると、auto mode中は全部のBash・PowerShellのallowルールを一時停止して、あらゆるシェルコマンドをclassifierに評価させます。
{
"autoMode": {
"classifyAllShell": true
}
}
これはレイテンシとカバレッジのトレードオフです。allowルールなら即通っていたコマンドが、毎回classifierの判定を待つことになり、そのぶんclassifierの呼び出し回数も増えます。安全側に倒したいセッションでは有効ですが、常用すると待ち時間が積み上がる、という性質は知っておくとよいです（v2.1.193以降で対応）。
効いているか確認する
設定を書いたら、想定どおり効いているかを確かめたくなります。claude auto-mode サブコマンドがそのための道具です。
| コマンド | 何をするか |
|---|---|
claude auto-mode defaults |
組み込みのルール一覧をJSONで表示 |
claude auto-mode config |
自分の設定を反映した"実際に使われるルール"を表示 |
claude auto-mode critique |
自作ルールにAIがフィードバック（曖昧・冗長・誤検知しそうな箇所を指摘） |
claude auto-mode reset |
自分のカスタマイズを消してデフォルトに戻す（v2.1.212以降） |
実務での使い方はこうです。設定を保存したら claude auto-mode config を叩いて、"$defaults" が展開された状態で、自分の項目がちゃんと入っているかを確認する。自作ルールを書いたなら claude auto-mode critique でレビューしてもらう。組み込みルールを足すのではなく書き換えたいときは、claude auto-mode defaults の出力をファイルに保存し、リストを編集して、"$defaults" の代わりに設定へ貼り付けます。
拒否されたら、そこから学ぶ
auto modeが拒否したツール呼び出しは、/permissions の Recently denied（最近拒否した）タブに記録されます。拒否されたアクションで r を押すと再試行の印が付き、ダイアログを抜けるとClaudeにそのツール呼び出しを再試行してよいと伝わって会話が再開します。
拒否と一緒に表示される理由は、多くのセッションで固定文言の Blocked by classifier です（v2.1.208以降）。素っ気ないですが、直し方はブロックされたツール呼び出しが「何に届こうとしていたか」で選べます。
- タスク中ずっと必要な宛先（パッケージレジストリ、内部ドメイン、リポジトリのホストなど）なら、
autoMode.environmentに足す - これから確認なしで走らせたいコマンドなら、
allowルールを足す - 意図していた一回きりの操作なら、次のメッセージでその意図を伝えて再試行させる
同じ宛先で拒否が繰り返されるのは、たいていclassifierがその文脈を知らないだけです。autoMode.environment に足して、claude auto-mode config で反映を確認する。この往復に慣れると、auto modeはだんだん自分の環境に馴染んで、余計に止まらなくなっていきます。
🚀 Devin専門の解説メディア「StartDevin」を運営中！
Devinの導入・使い方・最新アップデート・活用事例を、日本語でまとめています。
👉 StartDevin をチェックする（startdevin.jp）
この記事にぜひ いいね❤️ していただけると励みになります 🙌
おわりに
auto-mode-configを触っていて感じたのは、この設定が本質的に「AIにインフラの地図を渡す作業」だということでした。正規表現でもコードでもなく、新入りのエンジニアに説明するのと同じ自然文で、「うちの内側はここまで、ここから先は外」と線を引く。classifierはその地図をもとに、routineな作業は通し、地図の外への持ち出しだけを止める。設定というより、信頼の範囲を言語化する作業に近いです。
Devinでもプレイブックやルールで「どこまで任せるか」を言語化していきますが、向かっている先は同じだと思います。エージェントに任せる範囲が広がるほど、「何を信頼していると明示できているか」が効いてくる。auto modeを実務で使うなら、前回の「classifierは何を見ているか」とこの「どう教えるか」をセットで押さえておくと、止まりすぎず、緩めすぎずの落としどころが見つけやすいはずです。自分の環境で environment を育てながらブロックの傾向を測ったら、また続きを書きます。
参考リンク
- Configure auto mode（Claude Code公式ドキュメント）（一次情報。environmentとルールの設定リファレンス）
- Choose a permission mode（Claude Code公式ドキュメント）（前回の記事で扱った権限モードとclassifier）
- Permissions（allow / ask / denyルール）
- Managed settings（組織全体への配布）