Claude Codeを業務で使い始めたエンジニアが、ある時点で必ずぶつかる壁がある。コードを書かせるたびに「このファイルを編集してもいいですか？」「このコマンドを実行してもいいですか？」という承認プロンプトが飛んでくる。最初は「ちゃんと確認してくれている」と安心するが、数時間後には手が止まるたびに「y」を打ち続けるだけになっている。
その答えとして --dangerously-skip-permissions を試した人もいるだろう。承認プロンプトは消える。作業は止まらない。だが、「何でも通る」という事実が頭から離れない。本番DBのマイグレーションも、force pushも、全部「y」扱いで流れていく可能性がある。承認疲れを解消したら、今度は別の不安が生まれた。
Auto Modeは、この二択に対するAnthropicの回答だ。
なぜAuto Modeが必要だったか
--dangerously-skip-permissions は「とにかく全部通す」という設計だった。これは個人の実験環境では便利だが、チームで使う道具としては粗すぎる。
Anthropicのエンジニアリングブログは、Auto Modeのことを「--dangerously-skip-permissions がそうあるべきだった姿」と表現している。承認を省くのではなく、危険かどうかを判断してから動く。判断できないものだけ止める。そのアーキテクチャが、Auto Modeの骨格だ。
内部では、Claude本体とは別の分類器モデルが動いている。Claude がツールを呼び出そうとするたびに、この分類器が「安全か危険か」を先に評価する。安全と判断すれば承認なしで実行され、危険と判断すればブロックしてClaudeに別のアプローチを促す。
承認プロンプトをゼロにするのではなく、「承認が必要な場面」を分類器が選別する。これが --dangerously-skip-permissions との根本的な違いだ。
利用要件：Proプランでは使えない
> ⚠️ Auto Modeは Max / Team / Enterprise / API プランのみ対応。Proプランは対象外。
まずここを確認してほしい。Claude Code v2.1.83以降が必要で、モデルも制約がある。
- Team / Enterprise / API: Claude Sonnet 4.6 / Opus 4.6 / Opus 4.7
- Max: Claude Opus 4.7 のみ
Haiku や claude-3系は非対応。Bedrock・Vertex・Foundryも対象外で、Anthropic APIに直接つなぐ必要がある。
Team / Enterprise では管理者が claude.ai/admin-settings/claude-code でAuto Modeを有効化しておく必要もある。
起動自体はシンプルだ。
# CLIフラグで起動
claude --permission-mode auto
# デフォルトに設定（ユーザー設定）
# ~/.claude/settings.json
{
"permissions": {
"defaultMode": "auto"
}
}セッション中に Shift+Tab でモードをサイクルさせると Auto が選択肢に現れる（要件を満たすアカウントのみ）。
なお、リポジトリ側の .claude/settings.json でautoをデフォルトに設定しても無視される。これは意図的な設計で、リポジトリ側のコードが勝手に権限モードを昇格させないための措置だ。
分類器が何をブロックし、何を通すか
デフォルトでブロックされるのは、curl | bash のようなダウンロード即実行、機密データの外部エンドポイントへの送信、本番デプロイやDBマイグレーション、クラウドストレージの大量削除、IAM・リポジトリ権限の付与、共有インフラの変更、main への直接pushやforce push、セッション開始前から存在したファイルの不可逆削除といった操作だ。
逆に通過するのは、working directory内のローカルファイル操作、lock filesやmanifestで宣言された依存のインストール、.env の読み取りと対応APIへの接続、読み取り専用のHTTPリクエスト、セッション開始ブランチまたはClaudeが作ったブランチへのpushだ。
Claudeに「pushしないで」と会話で伝えると、デフォルトで許可されているpushもブロックされる。ただしこの会話ベースの境界設定は、コンテキスト圧縮で消えると失われる。確実にブロックしたいなら permissions.deny ルールに書くほうが安全だ。
分類器にはフォールバック条件がある。3回連続でブロックが発生するか、累計20回ブロックに達すると、Auto Modeは一時停止して通常の承認プロンプトに戻る。許可されたアクションが1つでも入ればカウンタはリセットされる。PermissionDeniedイベントをHooksで捕捉してログに残す方法についてはHooks実例記事が参考になる。また、どのモードで動いているかをステータスラインで常時確認したい場合はStatusline記事も見てほしい。
autoMode.environmentで組織の信頼インフラを宣言する
Auto Modeはデフォルトで、working directoryとリモートリポジトリ以外をすべて「外部」として扱う。社内のJenkinsやArtifactory、特定のS3バケットを安全な操作先として認識させるには、autoMode.environment に明示的に記載する。
{
"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",
"Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
]
}
}"$defaults" を含めないと、組み込みのデフォルトルールが全部消える。警告対象になるので必ず入れること。
Team/Enterprise環境ではManaged Settingsで組織全体に配布できる。個別のエンジニアがそれぞれ設定するのではなく、管理者が一度書いてプッシュする形を取る。Managed Settingsと組み合わせたセキュリティ運用の詳細はこちらの記事で扱っている。
独自ルールが必要なら、autoMode.hard_deny（ユーザーの意図があっても絶対にブロック）、autoMode.soft_deny（通常はブロックだが明示的な意図で許可）、autoMode.allow（soft_deny の例外として許可）の3つで細かく調整できる。
設定の確認にはCLIコマンドが使える。
# 組み込みデフォルトを確認
claude auto-mode defaults
# 実効設定を確認
claude auto-mode config
# カスタムルールへのAIフィードバック
claude auto-mode critiqueclaude auto-mode critique が便利で、書いたカスタムルールに対してAIが「このルールは意図通りに機能するか」をフィードバックしてくれる。
サブエージェント環境での注意点
マルチエージェント構成でClaude Codeを使っている場合、分類器は親セッションだけでなくサブエージェントの動作も監視する。委譲するタスクの内容がサブエージェント起動前に評価され、実行中の各アクションも親と同じルールで判定される。サブエージェントが完了したときにfull action historyが再評価される仕組みで、エージェントが積み重ねた動作全体が安全だったかどうかを後から検証できる。
サブエージェントのfrontmatterに permissionMode を書いても無視される。権限は常に親セッションのルールに従う。
私が試したケースでは、Researcherエージェントが外部URLへの読み取り専用リクエストを送る処理はそのまま通り、Writerエージェントがファイルを編集・保存する処理も問題なかった。一方、Auditorエージェントがgit pushを試みたときは分類器がブロックし、Claudeが「直接pushはせずにPRを作成します」と代替アクションを選んだ。意図せず本番ブランチへ変更が飛ぶリスクが、エージェントが介在しても変わらず制御されていることが確認できた。
なお、分類器がセキュリティ上の問題を検出した場合、サブエージェントの出力の先頭に警告が付く。この警告をログに残しておくと、後から何が起きたかを追跡しやすい。
まとめ：YOLOを卒業する前に確認すること
Auto Modeを試す前に、自分のプランとモデルの組み合わせが要件を満たしているか確認してほしい。MaxプランでOpus 4.7以外を使っている場合は対応していない。
要件を満たしているなら、最初は claude --permission-mode auto で1セッションだけ動かしてみる。分類器が何をブロックして何を通すかを体感するほうが、ドキュメントを読むより早い。チームに展開する前に autoMode.environment で信頼インフラを宣言し、claude auto-mode critique でカスタムルールを検証する。
--dangerously-skip-permissions を使い続けるか、承認プロンプトを押し続けるか。その二択から外れる選択肢が、ようやく正式にリリースされた。
権限設計の基礎から整理したい場合はパーミッション設計記事も合わせて読むと、Auto Modeの設計思想がより腑に落ちるはずだ。
コメント