Claude Codeの承認疲れを減らす｜安全を捨てずに止まらない設定にする

たきびラボ | AIで副業

2026年5月8日 10:35

Claude Codeが何度も止まって、集中が切れていませんか？

Claude Codeを使っていて、いちばん地味にしんどいのが承認作業です。

ファイル編集のたびに承認。
Bashコマンドのたびに承認。
依存関係のインストールで承認。
テスト実行で承認。

最初は「安全のためだから仕方ない」と思っていました。けれど、長めの修正を任せていると、5分おきに画面へ戻ることになります。

これ、便利なはずのAI開発が「承認ボタンを押す仕事」になってしまうんですよね。

そこで、Claude Codeの公式ドキュメントを確認しながら、承認作業を減らす現実的な方法を整理しました。目指すべきは「全部許可」ではありません。

よく使う安全な作業だけ自動化し、危ない作業は確実に止める。

この設計にすると、作業はかなり滑らかになります。

確認日: 2026年5月7日

承認を減らす方法は5つある

Claude Codeで承認を減らす方法は、大きく5つあります。

1つ目は acceptEdits mode。
ファイル編集と一部のよく使うファイル操作を自動承認するモードです。

2つ目は permissions.allow。
よく使うコマンドだけを明示的に許可できます。

3つ目は sandbox。
BashコマンドをOSレベルで隔離し、その範囲内なら承認なしで実行しやすくする仕組みです。

4つ目は auto mode。
Claude Code側の分類器が安全性を見て、問題なさそうな操作を自動で通します。

5つ目は hooks。
承認そのものを減らすだけでなく、「承認待ちになったら通知する」「危ない操作は自動で止める」といった運用に使えます。

この中で、まず試す価値が高いのは acceptEdits と permissions.allow です。
次に sandbox。
利用条件を満たすなら auto mode。
最後に、運用が固まってきたら hooks を足す。

この順番が安全です。

まずはacceptEditsで編集承認を減らす

Claude Codeの権限モードには、default、acceptEdits、plan、auto、dontAsk、bypassPermissions があります。

標準の default はかなり保守的です。読み取りはできますが、編集やコマンド実行では止まりやすい。

日常的な開発作業なら、まず acceptEdits を使うのが一番わかりやすいです。公式ドキュメントでは、acceptEdits は作業ディレクトリ内のファイル編集と、mkdir、touch、mv、cp などの一般的なファイル操作を自動承認すると説明されています。

一時的に使うなら、Claude Code起動時にこうします。

claude --permission-mode acceptEdits

毎回このモードで始めたいなら、~/.claude/settings.json またはプロジェクトの .claude/settings.local.json に書けます。

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

個人的には、最初から全プロジェクトで有効にするより、よく触るリポジトリの .claude/settings.local.json で試すのが良いと思います。チーム共有の .claude/settings.json にいきなり入れると、他の人の安全感覚まで変えてしまうからです。

allowルールで「いつものコマンド」を通す

承認疲れの大半は、毎回ほぼ同じコマンドで起きます。

たとえば、このリポジトリなら uv run の検証コマンド、MarkdownやYAMLのlint、git diff、git status などです。

Claude Codeには permissions.allow があります。ここに許可したいツールやコマンドを書いておくと、該当する操作で毎回止まりにくくなります。

例です。

{
  "permissions": {
    "allow": [
      "Bash(uv run pytest *)",
      "Bash(uv run python scripts/validate_prompt_yaml.py *)",
      "Bash(git status *)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr merge *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push origin main)",
      "Bash(curl *)",
      "Bash(wget *)"
    ]
  }
}

ポイントは、allow だけでなく ask と deny も一緒に書くことです。

「よく使うものを許可する」だけだと、だんだん設定がゆるくなります。逆に「これは必ず止める」を同時に決めると、安心して自動化できます。

このリポジトリなら、git push origin main は禁止で良いです。AGENTS.mdでも main への直接Pushは禁止されています。こういうプロジェクトルールは、Claudeへのお願いではなく、設定で止めるほうが強い。

denyを先に考えると安全になる

Claude Codeの権限ルールは、deny、ask、allow の順で評価されます。

つまり、どこかで deny に一致した操作は、他の設定で許可していても止まります。

これはとても大事です。

たとえば、.env を読まない、secretsディレクトリを読まない、curl や wget をBashから勝手に使わせない、といったルールは先に決めておきたいところです。

特にBashは注意が必要です。Claude Codeの Read(./.env) deny はClaudeの組み込みReadツールを止める設定であって、Bashの cat .env までは同じ意味で止められません。公式ドキュメントでも、Bash subprocessまでOSレベルで縛るにはsandboxを使う説明になっています。

だから、機密情報があるリポジトリではこう考えます。

1つ目、Claudeのファイル読み取りには Read(./.env) のdenyを入れる。

2つ目、Bash経由の抜け道を減らすため、危ないネットワーク系コマンドをdenyする。

3つ目、さらに必要ならsandboxでOSレベルの境界を作る。

この3段階です。

sandboxは「承認を減らすための安全柵」

sandboxは、承認疲れ対策の中でも効き方が少し違います。

公式ドキュメントでは、sandboxはBashコマンドをファイルシステムとネットワークの境界内で動かす仕組みとして説明されています。安全な範囲を先に決めることで、その範囲内のBashコマンドを承認なしで動かしやすくする、という考え方です。

macOSではSeatbelt、Linuxではbubblewrapを使います。

設定例はこうです。

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["./", "/tmp"]
    }
  },
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

autoAllowBashIfSandboxed が有効だと、sandbox内で実行できるBashコマンドは承認なしで進みます。

ここで大事なのは、sandboxを「ゆるくする機能」ではなく「境界を先に固定する機能」として見ることです。

作業ディレクトリ内では動いてよい。
ホームディレクトリの秘密鍵やクラウド認証情報には触らせない。
許可していない外部ドメインには出さない。

この境界を作れるなら、毎回承認ボタンを押すより安全です。人間は何度も承認していると、だんだん読まなくなります。安全設計としては、疲れた人間に毎回判断させるより、境界をコード化したほうが強い場面があります。

auto modeは便利だが、使える人を選ぶ

2026年5月7日時点の公式ドキュメントでは、auto mode はClaude Code v2.1.83以降が必要で、利用条件もあります。

プランは Max、Team、Enterprise、API が対象で、Proでは使えません。TeamやEnterpriseでは管理者による有効化が必要です。対応モデルやプロバイダにも条件があります。

auto modeは、承認プロンプトを出さずに進める代わりに、別の分類器が各操作を見ます。破壊的な操作、外部へのデータ送信、production deploy、force push、mainへの直接pushなどは既定で止める方向の設計です。

かなり魅力的です。

ただし、公式もresearch previewとして扱っています。リスクがゼロになるわけではありません。

使えるなら、私はこういう用途に向いていると思います。

長めのローカル修正。
テスト修正。
ドキュメント整備。
feature branch上の作業。
コンテナやVMなど、壊れても戻せる環境での実装。

逆に、production環境、クラウド権限変更、DB migration、秘密情報を含む作業、会社の共有インフラ変更では、いきなり auto mode に任せるのは怖いです。

auto modeを使う場合は、autoMode.environment に信頼するGitHub org、内部ドメイン、CI、artifact registryなどを書いておくと、分類器が「どこまでが自分の環境か」を判断しやすくなります。

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: GitHub org github.com/your-org and repos under it",
      "Trusted internal domains: *.internal.example.com",
      "Key internal services: GitHub Actions and internal artifact registry"
    ]
  }
}

ここで "$defaults" を入れ忘れると、既定のルールを置き換えてしまう場合があります。公式ドキュメントでも、既定値を継承したい場合は "$defaults" を含める説明になっています。

bypassPermissionsは最後の手段

Claude Codeには bypassPermissions mode もあります。--dangerously-skip-permissions と同等の位置づけです。

名前からして強いですね。

これは承認プロンプトと安全チェックを飛ばします。作業は速くなりますが、prompt injectionや意図しない操作に対する防御も薄くなります。

公式ドキュメントでも、使うならコンテナ、VM、インターネットなしのdev containerなど、壊れてもよい隔離環境に限るべきだとされています。

私は普段のローカル開発では使わないほうがいいと思っています。

承認が多くて困っているなら、まず acceptEdits、allow、sandbox、auto modeを検討する。bypassPermissions は「どうしてもこの隔離環境で一気に走らせたい」という場面だけ。

安全を捨てて速くするのではなく、安全な範囲を狭く作って、その中で速くする。ここが肝です。

hooksで「見張る場所」を変える

hooksは、承認疲れへの少し違うアプローチです。

承認を全部なくすのではなく、Claude Codeのライフサイクルに処理を差し込みます。

たとえば、Claudeが承認待ちになったらmacOS通知を出す。
ファイル編集後に自動でformatterを走らせる。
危ないファイルへの編集を止める。
設定変更を監査する。

公式ドキュメントには、Notification hookで承認待ちを通知する例があります。

{
  "hooks": {
    "Notification": [
      {
        "matcher": "permission_prompt",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Claude Code needs your attention\" with title \"Claude Code\"'"
          }
        ]
      }
    ]
  }
}

これだけでも体感は変わります。

承認待ちを見張るためにターミナルを眺め続ける必要がなくなります。別の作業をして、通知が来たときだけ戻ればいい。

さらに運用が進んだら、PreToolUse hookで危ない操作を止めるのもありです。公式ドキュメントでは、hookはpermission modeより前に動き、bypassPermissions でもブロックできると説明されています。

つまり、hooksは「便利にするため」だけではなく、「絶対に越えてほしくない線」を作るためにも使えます。

私ならこの順番で設定する

自分のClaude Code環境を承認疲れ対策するなら、こうします。

まず、作業リポジトリの .claude/settings.local.json に acceptEdits を入れる。

次に、よく使う検証コマンドだけ permissions.allow に追加する。

そのうえで、.env、secrets、mainへの直接push、外部ネットワーク系コマンドを deny に入れる。

それでもBash承認が多いなら、sandboxを有効にする。

TeamやMaxなどで条件を満たしているなら、auto modeを試す。ただし、productionやクラウド変更では使わない。

最後に、Notification hookを入れて承認待ちに気づけるようにする。

いきなり全部やる必要はありません。

最初の一歩としては、これで十分です。

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(uv run pytest *)",
      "Bash(git status *)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(git push origin main)",
      "Bash(curl *)",
      "Bash(wget *)"
    ]
  }
}

これだけでも、毎回止まる回数はかなり減ります。

承認ゼロより、承認すべき場所で止まるほうがいい

Claude Codeの承認が多いと、つい「全部自動で通したい」と思います。

でも、本当に欲しいのは承認ゼロではありません。

テスト実行やローカル編集では止まらない。
mainへのpushでは止まる。
秘密情報へのアクセスでは止まる。
外部へのデータ送信では止まる。

この状態です。

承認疲れは、単に面倒なだけではありません。疲れた人間は、危ない承認も流れで押してしまいます。

だからこそ、安全な作業は設定で通し、危ない作業は設定で止める。

Claude Codeを長く使うなら、この権限設計はかなり効きます。AIに任せる範囲を広げるほど、「どこで止めるか」を先に決める価値が上がっていくはずです。

参考にした公式情報

Claude Code Docs: Configure permissions
https://code.claude.com/docs/en/permissions
Claude Code Docs: Choose a permission mode
https://code.claude.com/docs/en/permission-modes
Claude Code Docs: Sandboxing
https://code.claude.com/docs/en/sandboxing
Claude Code Docs: Configure auto mode
https://code.claude.com/docs/en/auto-mode-config
Claude Code Docs: Automate workflows with hooks
https://code.claude.com/docs/en/hooks-guide
Claude Blog: Auto mode for Claude Code
https://claude.com/blog/auto-mode

#takibiラボ #takibiラボ_AI #ClaudeCode #AI開発 #生成AI #セキュリティ #AIセキュリティ #開発効率化 #権限管理 #自動化

いいなと思ったら応援しよう！

よろしければ応援お願いします! 今月のClaude に大切に使わせていただきます!