Claude Codeの権限設定入門｜毎回の確認を減らしつつ危険な操作を防ぐ

Claude Codeの確認をすべて許可すると、意図しない変更や外部送信まで通す恐れがあります。一方、毎回確認すると自動化が止まりがちです。答えはどちらか一方ではありません。基本は、繰り返す安全な操作だけを狭く許可し、秘密情報、公開、削除などは拒否または都度確認に残すことです。

この記事では、権限の3つの指定方法と権限モードの違い、設定ファイルの置き場所、秘密ファイルの守り方、そして設定後に必ずやる動作試験まで、初心者が手を動かせる順番で説明します。

権限設定の考え方は「全部許可」ではなく「安全な反復だけ先に通す」

権限設定は、家の鍵の渡し方に似ています。掃除をお願いする人には、玄関と掃除道具置き場の鍵だけ渡します。金庫の鍵まで渡す必要はありません。仕事に必要な最小限だけを渡す、という考え方です。

これはセキュリティの世界で「最小権限(さいしょうけんげん)」と呼ばれる原則です。米国のNISTは、利用者やその代理で動くプロセスに、割り当てられた仕事に必要な最小限のアクセス権だけを与える原則と定義しています(least privilege - NIST CSRC)。

Claude Codeに当てはめるときは、操作を3段階に分けて考えます。

1. 読む: ファイルの閲覧、差分の確認。
2. ローカルで変える: 手元のファイル編集、検査コマンドの実行。
3. 外や共有先へ影響を出す: git push、デプロイ、公開、削除、インストール。

最初に確認なしへ回してよい候補は、1と2の一部だけです。具体的にはlint(=書き方の検査)、決められたテスト、限定したフォルダの文書編集などです。3の「外へ影響する操作」は、慣れてからも人の確認に残します。

なお、許可を考える前に作業フォルダを確定させてください。起動位置が曖昧なまま許可を増やすと、意図しない場所で権限が効きます。Claude Codeで作業フォルダを間違えない基本も参考になります。

allow・ask・denyと権限モードを混同しない

権限の指定には2つの層があります。個別の操作ごとのルール(allow・ask・deny)と、セッション全体の方針(権限モード)です。まず操作ごとのルールから見ます(Configure permissions - Anthropic公式)。

設定	一致した操作の扱い	向いている例
allow	確認なしで実行する	lint、決められたテスト
ask	実行のたびに確認する	依存関係の追加、外部通信
deny	実行を拒否する	秘密ファイルの読み取り、git push

判定順は deny、ask、allow です。最初に一致したルールが使われます。つまり、広めの許可があっても、秘密ファイルを deny へ入れておけば拒否が優先されます。

逆向きの例外は作れません。Bash(git *) を拒否すると、Bash(git status) を許可しても拒否が先に適用されます。だから拒否範囲は必要以上に広げず、対象を具体的に書きます。

現在のルールと、そのルールがどの設定ファイルから来たかは、Claude Code内で次を実行すると確認できます。

/permissions

次に権限モードです。モードはセッション全体の「確認の出し方」を決めます(Choose a permission mode - Anthropic公式)。

モード(設定値)	動き	向いている場面
Manual(default)	許可していない操作は毎回確認する	最初の既定。まずここから
acceptEdits	ファイル編集の確認を自動で承認する	編集の中身を差分で追える作業
plan	調査と計画だけ行い、変更しない	構造の把握、方針の相談
auto	確認を減らすが、安全の保証ではない	慣れた反復作業(過信しない)
dontAsk	未承認の操作を自動で拒否する	CIなど、入力待ちを作れない環境
bypassPermissions	確認と安全チェックを大幅に省く	隔離されたコンテナやVM専用

注意点が2つあります。第一に、auto は安全を保証しません。公式も、機密性の高い操作でレビューの代わりに使わないよう明記しています。止めたい操作があるなら、モード任せにせず、明示的な ask か deny で停止線を作ってください。提供条件や動きはバージョンで変わり得るので、使う時点の公式案内で確認してください。

第二に、bypassPermissions は日常の作業PCでは避けます。公式は、ホスト(=あなたのPC本体)へ被害を出せない隔離環境だけで使うよう案内しています。

設定はLocalで試し、秘密はdenyへ置く

設定ファイルの置き場所は主に3つです(Claude Code settings - Anthropic公式)。

置き場所	ファイル	誰に効くか
個人全体(User)	~/.claude/settings.json	自分の全プロジェクト
チーム共有(Project)	.claude/settings.json	リポジトリを使う全員
自分だけ(Local)	.claude/settings.local.json	このリポジトリの自分だけ

Windowsでは ~/.claude は %USERPROFILE%\.claude のことです。初回はLocalから試すのが安全です。失敗しても自分にしか影響しません。

重要な仕様が1つあります。権限ルールは設定ファイル同士で置き換わらず、合体します。別のファイルにある拒否ルールも生きたまま残ります。「allowに入れたのに拒否される」の多くはこれが原因です。

ファイルの許可は「読む」と「編集する」を分け、秘密は拒否に置きます。例を示します。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Edit(docs/**)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

パスの書き方は、* が1階層、** が複数階層に一致します。docs/** は作業フォルダ直下の docs 以下すべてが対象です。

ここで境界を1つ正直に書きます。Read の拒否は、Claude Codeの組み込みファイルツールに効く仕組みです。Bashから起動した別のプログラム(PythonやNodeなど)がファイルを読むことまで、OSのレベルで一律に止めるものではありません。より強い壁が必要なら、サンドボックス(=隔離された実行環境)を重ねます。

それでも秘密を deny に置く価値は大きいです。秘密が一度でもリポジトリに入って外へ出ると、GitHub公式の案内では、まずそのパスワードやトークンを失効・交換する必要があります。履歴から消す作業には、共同作業者との調整や履歴の書き換えなど多くの副作用が伴います(Removing sensitive data from a repository - GitHub Docs)。事故の後始末は、事前の拒否ルール1行よりはるかに高くつきます。秘密を依頼文やログへ貼らない運用はAIコーディングで秘密を漏らさない方法にまとめています。

コマンドは中身を確認して名前単位で許可し、保存後に試す

Bashはツール全体ではなく、繰り返す具体的なコマンド単位で許可します。

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)"
    ],
    "ask": [
      "Bash(npm install *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

Bash(npm run lint) は完全一致、Bash(npm run test *) は引数付きにも一致します。末尾の空白付き * は語の区切りとして働くため、Bash(ls *) は ls -la に一致しても lsof には一致しません。また、&& や ; でつないだ複合コマンドは、各部分がそれぞれ権限判定を受けます。

ただし、名前だけで安全と判断しないでください。npm run は package.json の scripts に書かれた任意のコマンドを実行します。同じ名前の pre と post が付いたスクリプトも自動で順番に動きます(Scripts | npm Docs)。つまり npm run test という名前でも、中身は何でもあり得ます。allow へ移す条件は「package.json を開いて、そのスクリプトと関連するpre・postの中身を確認済みであること」にしてください。

git push を拒否に置くのは、これが手元で完結する検査と違い、リモート(=共有先のサーバー)の参照を更新するコマンドだからです。--prune や --mirror のように、リモート側の削除や広範囲の更新につながるオプションもあります(Git - git-push Documentation)。チームで意図して頻繁に共有する環境なら、deny ではなく ask にして人の目を1回挟む選び方もあります。

保存したら、本番作業の前に次の順で試します。

1. /status を実行し、編集した設定ファイルが読み込まれているかを見る。JSONが壊れていると設定は反映されません。
2. /permissions で、意図したルールと出所(どのファイル由来か)を確認する。
3. 許可した検査コマンド(例: lint)を依頼し、確認なしで動くことを見る。
4. .env を読むよう依頼し、拒否されることを見る。
5. git push を依頼し、拒否(または確認)になることを見る。

期待と違ったら、壊れたJSON、空白と * や ** の書き方、別の設定ファイルに残る強い deny、の順で切り分けます。なお、毎回同じ検査を自動で走らせたい場合は、権限とは別の仕組みであるClaude Code Hooksで検品を自動化する方法が使えます。権限は「実行してよいか」、Hooksは「いつ実行するか」の担当です。無人で動かす予定があるなら、Claude Codeを非対話で自動実行する前の確認事項も先に読んでください。

よくある質問

allow に入れたのに確認や拒否が出るのはなぜですか

同じ操作に一致する deny や ask が、別の設定ファイルに残っている可能性が高いです。権限ルールはファイル間で合体し、deny、ask、allow の順で評価されます。/permissions で一致ルールと出所を確認してください。

.claude/settings.json と .claude/settings.local.json の違いは何ですか

前者はリポジトリでチーム共有するProject設定、後者はそのリポジトリで自分だけが使うLocal設定です。試行中の許可はLocalで検証し、チームでも再現できると確認した狭いルールだけProjectへ移します。

Bash(npm run test *) を許可すれば、必ずテストだけが動きますか

保証できません。npm run は package.json に書かれた任意のスクリプトを動かし、同名の pretest と posttest も順に実行されます。許可する前に package.json を開き、そのスクリプトが実際に何を呼ぶかを確認してください。

Read の拒否だけで .env を完全に保護できますか

できません。拒否は組み込みの読み取りツールには効きますが、Bashから起動した別プログラムの読み取りまで止めるOSの壁ではありません。Edit 側の拒否も併せて書き、強い隔離が必要ならサンドボックスやコンテナを重ねてください。

確認を全部なくすために bypassPermissions を使ってもよいですか

日常の作業PCでは避けてください。このモードは確認と安全チェックを大幅に省くため、公式は、インターネット接続のないコンテナやVMなど、ホストへ被害を出せない隔離環境だけで使うよう案内しています。無人実行で入力待ちを作りたくないだけなら、未承認の操作を自動拒否する dontAsk と狭い allow の組み合わせを先に検討します。仕様は変わり得るので、使う時点の公式案内で確認してください。

まとめ

権限設定のゴールは、確認ゼロではありません。「安全な反復は流れ、危険な操作は止まる」状態です。次の3つから始めてください。

• .claude/settings.local.json に、内容を確認済みのlint・テストだけを allow で書き、.env と secrets を deny に置く。
• git push・インストール・削除・公開は ask か deny に残し、モード(auto など)に停止を任せない。
• 保存したら /status と /permissions で読み込みを確認し、「許可・確認・拒否」を1件ずつ試してから本番作業に入る。

公式一次情報

確認日: 2026-07-26

• Configure permissions - Claude Code Docs: allow・ask・denyの意味、deny→ask→allowの評価順、Bashのワイルドカード、Read・Editのパス規則、サンドボックスとの役割分担が書かれている。
• Claude Code settings - Claude Code Docs: User・Project・Localの置き場所と共有範囲、権限ルールがスコープ間で合体すること、/statusでの読み込み確認が書かれている。
• Choose a permission mode - Claude Code Docs: Manual(default)・acceptEdits・plan・auto・dontAsk・bypassPermissionsの用途と、bypassを隔離環境に限る案内が書かれている。
• Scripts | npm Docs: package.jsonのscriptsは任意のコマンドを定義でき、npm runで同名のpre・postスクリプトも順に実行されることが書かれている。
• Git - git-push Documentation: git pushはリモートの参照を更新するコマンドであり、—pruneや—mirrorなど広い影響を持つオプションがあることが書かれている。
• Removing sensitive data from a repository - GitHub Docs: 秘密が漏れたらまず失効・交換が必要で、履歴からの除去には多くの副作用があることが書かれている。
• least privilege - Glossary | NIST CSRC: 最小権限の定義(仕事に必要な最小限のアクセス権だけを与える原則)が書かれている。