Claude Codeで確認なしに実行する権限設定｜permissionsの安全な使い方

Claude Codeの権限設定とは

Claude Codeを使っていると、コマンド実行やファイル操作の前に確認が出ます。

毎回止まるのは、たしかに煩わしい。 ただし、確認を全部なくすことは「効率化」とは別です。

安全に使うなら、低リスクな操作だけを確認なしにして、破壊的な操作や外部状態を変える操作は確認あり、またはブロックにする。これが permissions 設定の基本です。

この記事では、2026年7月時点のClaude Code設定に合わせて、settings.json の階層、allow / ask / deny の使い分け、チームで共有する時の考え方を整理します。

公式ドキュメントはこちらです。

• Claude Code settings
• Claude Code permissions
• Claude Code model configuration

settings.jsonの階層

Claude Codeの設定は、1つのファイルだけで決まるわけではありません。

通常設定の優先順は、次の通りです。

Managed > CLI引数 > Local > Project > User

ここで注意したいのは、permission rulesは単純な上書きではないことです。 通常の設定は上位スコープが下位スコープを上書きしますが、permissions のルールはスコープ間でマージされます。

つまり、どこかのスコープに deny がある場合、別のスコープで allow を書いても通らないことがあります。

allow / ask / deny の使い分け

permissions には3つの配列があります。

• allow: 一致した操作を確認なしで許可する
• ask: 一致した操作は確認を出す
• deny: 一致した操作をブロックする

評価順は次の通りです。

deny -> ask -> allow

先に一致した結果が勝ちます。 「より具体的に書いたから勝つ」わけではありません。

たとえば、deny に Bash(aws *) がある場合、allow に Bash(aws s3 ls) を書いても通りません。 同じように、ask に一致すれば、より具体的な allow があっても確認が出ます。

安全な許可の例

最初から広く許可しない方がいいです。 まずは、読み取り・差分確認・テストなど、失敗しても外部状態を変えにくいものに絞ります。

実ファイルに貼るJSONにはコメントを書けません。 下の例は、そのまま settings.json として使える形式です。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(rg *)",
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "WebFetch(domain:docs.anthropic.com)",
      "WebFetch(domain:github.com)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm install *)",
      "Bash(gh *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl *)",
      "Bash(wget *)"
    ]
  }
}

npm run lint や npm run test * は、プロジェクトのscript内容が安全だと分かっている場合だけ allow に入れます。 npm script は任意の処理を実行できるため、一般論として広く許可しない方が安全です。

また、ls、cat、pwd、head、tail、grep、find、wc、which、diff、stat、du、read-onlyなgit操作などは、Claude Code側で読み取り系として扱われるものがあります。 毎回すべてを allow に足す必要はありません。

避けるべき許可

確認なしにしたいからといって、次のような広い許可を入れるのは避けます。

• Bash / Bash(*)
• Bash(git *)
• Bash(npm *)
• Bash(node *)
• Bash(python *)
• Bash(make *)
• Bash(curl *)
• Bash(wget *)
• Bash(vercel *)
• Bash(gh *)
• Bash(aws *)
• Bash(kubectl *)
• Bash(terraform *)
• Bash(rm *)
• Bash(chmod *)
• Bash(chown *)
• Bash(sudo *)

これらは単なる効率化ではありません。 本番環境への書き込み、外部サービス操作、ファイル削除、権限変更、secret流出、外部からのダウンロードなどにつながる可能性があります。

とくに Bash や Bash(*) を allow に入れるのは、全Bash許可です。 これは「確認を減らす設定」ではなく、安全境界を外す設定として扱うべきです。

チーム開発での共有方法

チームで共有したい設定は、リポジトリ内の .claude/settings.json に置きます。

ここに入れる候補は、たとえば次のようなものです。

• そのプロジェクトで安全だと合意したlint/testコマンド
• secretを読ませないための deny
• チームで参照する公式ドキュメントのWebFetch許可
• プロジェクト共通のhooksやMCP設定

一方で、個人差がある設定は .claude/settings.local.json に置きます。

• ローカルだけの実験
• 個人の作業環境に依存する設定
• 自分の端末でだけ使うパス
• チームに共有すべきではない許可

Claude Codeが .claude/settings.local.json を作成した場合はgitignore対象になります。 自分で作成した場合は、手動で .gitignore に入れてください。

ワイルドカードと段階的追加

ワイルドカードは便利ですが、範囲を広げすぎやすいです。

たとえば、Bash(git diff *) は差分確認に寄っています。 一方で、Bash(git *) は push、reset、clean、checkout なども含み得ます。

最初は狭く書く。 必要になったら、実際に確認が出たコマンドだけを見て追加する。

この順番の方が、運用が壊れにくいです。

ホットリロードとモデル指定

Claude Codeは、多くの設定ファイル変更を実行中のセッションへ再読み込みします。 permissions や hooks は保存後に反映されます。

一方で、model は別の話です。 セッション中にモデルを変えるなら /model を使います。

この記事のサンプルでは、あえて model を入れていません。 権限設定の記事にモデル指定を混ぜると、論点が散るからです。

必要な場合は、公式ドキュメントを見て、/model または model fieldでaliasやモデルIDを選びます。 ただし、どのモデルが最適かは契約、コスト、速度、用途で変わります。

bypassPermissionsを通常運用にしない

bypassPermissions や --dangerously-skip-permissions は、通常の開発運用として推奨しません。

使うとしても、壊れてよいコンテナやVMなど、隔離された環境に限定すべきです。

Bash(*) は、便利な設定ではありません。 安全境界を外す設定です。

Claude Codeを個人効率化で終わらせない

permissions は、個人の開発効率を上げるだけの設定にも見えます。

でも、AIをチームや業務で使うなら、これは運用ルールです。

誰が、どのプロジェクトで、何を確認なしにできるのか。 どこから人間の確認を必要にするのか。 何は絶対に読ませないのか。

ここを決めることで、Claude Codeは単なる便利ツールではなく、AI社員として業務に参加できる土台になります。

GIZINでは、Claude Codeを個人の補助ツールとしてではなく、役割を持ったAI社員の実行環境として扱っています。 権限設定は、その入口です。

まとめ

Claude Codeの確認を減らすなら、広く許可するのではなく、狭く許可します。

• 低リスクな読み取り・確認系だけを allow にする
• 外部状態を変える操作は ask にする
• secretや危険なネットワーク操作は deny にする
• チーム共有は .claude/settings.json
• 個人設定は .claude/settings.local.json
• Bash(*) やbypass系を通常運用にしない

確認を減らすことが目的ではありません。 人間が確認すべきところを残すことが、Claude Codeを安全に使うための設計です。