定期実行・自動化 2026年11月2日 8分で読めます

Claude Code permissions設定の見直し手順

Claude Code permissions設定の見直し手順

Claude Codeのpermissions設定、最後に見直したのはいつでしょうか。「勝手に何か実行されないか」と不安なまま、確認ダイアログで「はい」を押し続けていませんか？

この記事では、私が自分の権限設定を棚卸ししてわかったことと、allow・ask・denyの考え方、点検に使えるプロンプトを紹介します。

先に正直に書くと、この記事は「deny（禁止）ルールを入れて完璧に守れるようになった」という話ではありません。棚卸しで問題を見つけた段階で、deny設定はまだこれから試すところです。ただ、仕組みがわかっただけで「何が起きうるか」が見え、不安はかなり小さくなりました。

※仕様は2026年11月2日時点の公式ドキュメント（code.claude.com/docs/en/permissions、permission-modes）にもとづいています。私の環境はmacOS、Claude Code 2.1.268です。バージョンやOSで挙動が変わる可能性があります。

結論：Claude Codeのpermissions設定は「足す」より「棚卸し」から

一言で言えば、Claude Codeの権限設定で最初にやるべきことは、新しいルールを足すことではなく、すでに溜まっているルールを見ることでした。

理由はシンプルです。確認ダイアログで「Yes, and don’t ask again（今後は確認しない）」を選ぶと（表示文言はバージョンにより異なる場合があります）、許可ルールが自動で保存されていきます。公式ドキュメントによると、BashコマンドやWebFetchのドメインの許可は `.claude/settings.local.json` に記録されます（git管理下ならリポジトリのルート）。ファイル編集の承認は保存されず、そのセッション限りです。

つまり、何も設定していないつもりでも、許可は少しずつ増えているのです。

実際に棚卸ししてみた結果

ブログ制作用のフォルダで `.claude/settings.local.json` を数えてみました。

許可（allow）ルール：**222件**
そのうちBashコマンド：202件
禁止（deny）ルール：0件

一番驚いたのは、認証情報がそのまま書かれた許可ルールが3件あったことです。WordPressにcurlで投稿したときのコマンドが、パスワード入りの文字列ごと「今後は確認しない」で保存されていました。

このファイルは個人用でgitの共有対象ではありません。とはいえ、平文の認証情報が設定ファイルに残っているのは気持ちのいい状態ではありません。パスワードの再発行とルールの削除を検討しています。

「ワンクリックで許可」は便利ですが、何が保存されているかは自分で見ないとわからない。これが棚卸しの一番の収穫でした。

allow・ask・denyの関係を整理する

権限ルールは3種類あります。

**allow**：確認なしで実行してよい
**ask**：毎回確認する
**deny**：実行させない

ポイントは評価の順番です。公式ドキュメントでは「deny → ask → allow の順に評価され、最初に一致したものが結果になる」と説明されています。allowでdenyの例外を作ることはできません。

たとえば、`.env` ファイルを読ませたくない場合は、次のようなdenyルールを書きます（ドキュメント記載の書式）。


{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

追加するときは、既存のJSON全体を置き換えず、`permissions` の中の `deny` 配列に行を足す形にします。この例は起動したフォルダが基準なので、`.env.local` など別名のファイルは別途書く必要があります。

ただし注意点もあります。Read denyは組み込みのファイル読み取りツールなどには効きますが、Pythonスクリプト経由の読み取りのような間接的な方法まで防げるとは限りません。また公式ドキュメントは、Bashのルールについて「普段Claudeが生成する呼び出し方を対象にしたもので、プログラム周りのセキュリティ境界ではない」と書いています。`Bash(rm *)` を禁止しても、別の書き方の削除コマンドまで止められるとは限りません。denyは「事故を減らす仕組み」と考え、過信しないほうがよさそうです。

permissions設定の前に知っておきたいモードの違い

ルールとは別に「モード」があります。2026年11月時点で公式に載っている主なものは次の通りです。

**default（Manual）**：ファイル編集やコマンド実行など、承認が必要な操作で確認する（許可ルールに一致するものは除く）
**acceptEdits**：作業フォルダ内のファイル編集などを自動で承認する
**plan**：調べて提案するだけで、ソースファイルは編集しない
**auto**：裏側の分類器が、依頼内容に沿った操作かを判定しながら進める
**dontAsk**：通常なら確認が出る操作を自動で拒否する
**bypassPermissions**：ほとんどの確認を省略する（隔離環境向け）

CLIではセッション中に Shift+Tab で、使えるモードを切り替えられます。dontAskは切り替え候補に出ないため、起動時に `–permission-mode dontAsk` で指定します。

私はユーザー設定（`~/.claude/settings.json`。`~` はホームフォルダのこと）で、`permissions` の中の `defaultMode` を `auto` にしています。ここで知って驚いたのが、`defaultMode` に指定した `auto` と `bypassPermissions` は、プロジェクトの `.claude/settings.json` や `.claude/settings.local.json` では効かないという仕様です。公式ドキュメントによると、プロジェクト側で `auto` を指定するとユーザー設定の値ではなく組み込みの既定値が使われ、`bypassPermissions` を指定するとManualで始まります。プロジェクト側に書いて「自動になったはず」と思い込むと、期待と違う動きになります。

なお、autoモードは対応するバージョン・プラン・モデルが必要です。使えない場合は設定の問題ではなく条件を満たしていない可能性があるので、公式ドキュメントで確認してください。

自分の権限設定を点検するプロンプト

ここからは、読者の方が自分の環境で試せるプロンプトです。Claude Codeのチャット欄にそのまま貼れます。最初は「読むだけ」にしているのがポイントです。


Claude Codeの権限設定を点検したいです。まずは読み取りだけを行い、ファイルの変更・削除・上書き・外部送信はしないでください。

対象:
- ~/.claude/settings.json
- 起動フォルダと、git管理下ならリポジトリのルートにある .claude/settings.json と .claude/settings.local.json（存在する場合）

やってほしいこと:
1. allow / ask / deny のルール数をファイルごとに数える
2. permissions.defaultMode の値と、それがどのファイルに書かれているかを示す
3. パスワード・トークン・APIキーらしき文字列を含むルールがあれば、設定ファイルの全文は表示せず、ローカルで集計・伏せ字にしたうえで「どのファイルの何件目に何の種類があるか」だけ報告する
4. rm、git push、curl など影響の大きいコマンドを許可しているルールを一覧にする（秘密の値は伏せ字にする）
5. .env など秘密情報を含みそうなファイルに Read の deny がない場合は、追加候補を提案する

ルールの削除・上書きなど設定ファイルを変更する作業は、対象ルール一覧・変更前後の差分（秘密の値は伏せ字）・影響範囲・元に戻す方法を表示し、私が確認してから実行してください。
管理者設定や起動オプションなど確認できなかった設定があれば、その旨を書いてください。
不明点は推測せず、確認事項として列挙してください。

3番で「全文は表示せず、伏せ字に」と指定しているのは、回答の中に認証情報が不用意に再掲されるのを減らすためです。ただし、ファイルを読む以上、会話の記録に一切残らないとまでは言い切れません。本当に心配な値は、先にパスワードを再発行するほうが確実です。

点検後に設定を変えるときは、`/permissions` コマンドも役立ちます。公式ドキュメントによると、ルールの一覧と「どのsettingsファイルから来たか」を一覧で確認できます。

正直な所感と、まだわからないこと

権限の仕組みを理解してから、確認ダイアログの見え方が変わりました。以前は「とりあえず許可」でしたが、今は「これは今回だけでいいか」と考えるようになりました。それだけでも、任せるときの安心感はかなり違います。

一方で、まだわからないこともあります。

autoモードの分類器が、どこまで意図をくみ取ってくれるのか
222件のルールを整理したあと、どのくらいの頻度で見直すべきか
denyを入れたとき、普段の作業でどれだけ止まるのか

このあたりは、deny設定を入れて使ってみる予定なので、わかったら追記します。

まとめ

permissions設定は、ルールを足す前に「溜まったルールの棚卸し」から始める
「今後は確認しない」を選ぶと、BashやWebFetchの許可は `.claude/settings.local.json` に保存される
ルールは deny → ask → allow の順に評価される。ただしdenyは万能ではない
`defaultMode` の `auto` と `bypassPermissions` はプロジェクト設定に書いても効かない
点検はまず読み取りだけ。変更は差分を見てから実行する

「勝手に実行されないか」という不安は、仕組みを知ることでかなり小さくなります。まずは点検プロンプトで、自分の設定を一度のぞいてみてください。

[Claude Code settings.json設定を最適化する前に見直す4つのこと](https://maahsachi.com/2026/10/24/claude-code-settings-optimization/)（設定ファイルの優先順位やHooksの確認はこちら）
[Claude Codeメモリ機能の使い方とOFF設定方法](https://maahsachi.com/2026/04/15/claude-code-memory/)