Claude Code パーミッションと安全設定ガイド｜初学者がまず設定すべき権限ルール

Claude Code は、ファイル変更・コマンド実行・Git 操作・外部 API 呼び出しなど、強力な操作を自動でこなしてくれる便利なツールです。しかし、設定を誤ると「気づいたら大事なファイルが消えていた」「うっかり本番ブランチに push されていた」といった事故にもつながります。

本記事では、Claude Code を安全に使いこなすためのパーミッション設定を、6つのモード・allow/ask/deny ルール・推奨初期設定（コピペで使える）まで、初学者向けに体系的に解説します。

📌 この記事で身につくこと

• 6つのパーミッションモードの特徴と使い分け
• allow / ask / deny ルールの書き方
• 絶対に避けるべき4つのアンチパターン
• 初学者向け推奨初期設定（コピペで使えるテンプレート）

---

🚨 なぜ安全設定が「最重要」なのか

Claude Code は人間の代わりにコマンドを実行する「エージェント」です。設定を誤ると、以下のような事故が起こり得ます。

• うっかり rm -rf（ファイルやフォルダを再帰的に強制削除する Unix コマンド。間違えると取り返しがつかない）で大事なファイルが消える
• レビューなしで main ブランチ（プロジェクトの本流。本番に近い、最も大事なブランチ）に直接 push（ローカルの変更をリモートサーバへ送る操作）されてしまう
• .env のシークレット（API キーやパスワードなど、外部に漏れてはいけない秘匿情報）が外部 API に送信されてしまう
• 他人のリポジトリ（コードの保管庫）に勝手に変更が加わってしまう

逆に言えば、これらは適切なパーミッション設定で防げます。Claude Code には、こうした事故を防ぐための仕組みが何重にも用意されており、それを正しく使いこなすのがこの章のゴールです。

---

🏚️ パーミッションシステムの全体像

個別のモードや設定の話に入る前に、Claude Code のパーミッションがどう動いているのか、全体像を理解しておきましょう。

Claude Code はツールの種類ごとに承認方針が異なる「ティア型」のシステムを採用しています。

ツール種別	例	承認	「常に許可」した時の挙動
読み取り専用	ファイル読み取り、Grep	不要	—
Bashコマンド	シェルコマンド実行	必要	そのプロジェクト・コマンド単位で永続的に許可
ファイル変更	Edit／Write	必要	そのセッション中のみ許可

つまり「読み取りはノーチェック、書き込みや実行は必ず承認が必要」が基本動作です。これに加えて、後述するモードやルールで動作をカスタマイズできます。

---

🎚️ STEP 1：6つのパーミッションモード

Claude Code には、「どこまで自分で判断して動いていいか」を決める 6段階のパーミッションモードがあります。これがもっとも重要な概念です。

6モード早見表

モード	確認なしでできること	主な用途
default	ファイル読み取りのみ	初学者、機密プロジェクト（推奨）
acceptEdits	ファイル編集 + 一部の FS（File System＝ファイル操作系）コマンド（mkdir＝フォルダ作成／touch＝空ファイル作成／mv＝移動・改名／cp＝コピー 等）	レビューしながら開発するとき
plan	ファイル読み取りのみ（編集禁止）	計画立案・コードベース探索
auto	ほぼ全部（裏で安全チェック付き）	長時間タスク（research preview）
dontAsk	事前に許可した操作のみ	CIパイプライン、固い環境
bypassPermissions	ほぼ全部（チェック無し）⚠️	隔離環境（VM/コンテナ）専用

各モードを詳しく

default モード（初学者はまずこれ）

もっとも慎重なモードです。ファイル編集やコマンド実行の前に、毎回「やっていいですか？」と確認してきます。Claude が予期しない動きをしたときも、必ず人間が止められる安心感があります。

初学者は最初の1〜2週間、必ずこのモードに固定してください。

acceptEdits モード（コーディングが中心の作業向け）

ファイル編集と mkdir・touch・mv・cp などの基本的なファイルシステムコマンドは確認をスキップし、それ以外のコマンド（ネットワーク・パッケージインストール等）は確認するモードです。

「コードを書いてもらう作業」が中心のとき、確認の煩わしさが減って効率が上がります。ただし慣れてからの利用を推奨します。

plan モード（読み取り専用・計画立案向け）

ファイルを絶対に編集しないモードです。「実装する前に計画を立てたい」「既存コードを安全に調査したい」といった場面で、間違ってファイルを書き換える事故を防げます。

新機能の設計・リファクタリング前の調査・コードレビュー時に重宝します。詳しくは実践ワークフロー集をご覧ください。

auto モード（research preview）

ツール呼び出しを自動で承認しつつ、裏で別のAIが安全性をチェックしてくれるモードです。「ユーザーの依頼内容と矛盾しないか」を判定してくれるため、長時間タスクを任せやすくなります。

現在は research preview（リサーチプレビュー：研究段階の試験的提供。仕様や提供条件が変わる可能性があります）としての提供のため、利用条件は変動する可能性があります。詳細は 公式ドキュメントを確認してください。

dontAsk モード（CI・固い環境向け）

事前に /permissions や permissions.allow で許可した操作以外は、すべて自動で拒否するモードです。CI/CD パイプラインや、決まった作業しかさせたくない環境で使われます。

bypassPermissions モード（隔離環境専用）

ほぼすべての確認をスキップする「最強モード」です。ただし、.git・.claude・.vscode・.idea・.husky ディレクトリへの書き込みのみは確認を求めます（リポジトリ破損やエディタ設定破壊を防ぐため）。

このモードは、必ず VM（Virtual Machine＝仮想マシン。1台の PC の中に独立した別の PC を作る技術）やコンテナ（Docker などで作る、ホストから隔離された軽量なアプリ実行環境）などの隔離環境でのみ使用してください。普段の作業マシンで使うと、Claude が予想外の操作をしたときに被害が広がります。

---

⌨️ STEP 2：モードの切り替え方

パーミッションモードは、状況に応じて柔軟に切り替えられます。切り替え方は3通りあります。

A. セッション中に切り替える（もっともよく使う）

セッション中に Shift+Tab を押すと、以下の順番で切り替わります。

default → acceptEdits → plan → (auto)

画面下部に現在のモードが表示されます。

• ⏵⏵ accept edits on → acceptEdits モード
• ⏸ plan mode on → plan モード

B. 起動時に指定する

claude --permission-mode plan

C. 永続的に設定する（毎回このモードで起動したい）

.claude/settings.json に以下を記述します。

{
  "permissions": {
    "defaultMode": "default"
  }
}

💡 注意：チャット内で「もう確認しないで」と Claude に頼んでも、モードは変わりません。必ず UI または設定ファイルで変更してください。

---

🛡️ STEP 3：allow / ask / deny ルール

モードに加えて、個別の操作（コマンド・ファイル・URL等）に対してルールを設定できます。これがパーミッション設定の本体とも言える機能です。

3つのルール種別

• allow：そのツールを確認なしで使える
• ask：そのツールを使う前に必ず確認を求める
• deny：そのツールの使用を絶対に拒否する

評価の優先順位

ルールは「deny → ask → allow」の順で評価され、最初にマッチしたルールが勝ちます。つまり、deny ルールは常に最強で、他のすべての設定を上書きします。

基本のルール構文

ルールは Tool または Tool(specifier) の形式で書きます。

ルール	意味
Bash	すべての Bash コマンドにマッチ
Bash(npm run build)	npm run build という完全一致のコマンドだけ
Bash(npm run *)	npm run で始まる任意のコマンド
Bash(git push *)	git push で始まる任意のコマンド
Read(./.env)	カレントディレクトリの .env ファイル読み取り
WebFetch(domain:example.com)	example.com への fetch リクエスト

実際の設定例

.claude/settings.json に以下のように記述します。

{
  "permissions": {
    "allow": [
      "Bash(npm test)",
      "Bash(npm run lint)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(sudo *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(git push --force *)",
      "Bash(git push origin main)"
    ]
  }
}

この設定は、「npm test や git status は確認なしで実行 OK、git push は毎回確認、rm -rf や sudo、.env の読み取りは絶対禁止」という意味です。

ファイルパスの書き方（4種類）

Read／Edit ルールでは、パスの書き方によって解釈が変わります。

パターン	意味	例
//path	絶対パス（ファイルシステムのルート起点）	Read(//Users/alice/secrets/**)
~/path	ホームディレクトリ起点	Read(~/Documents/*.pdf)
/path	プロジェクトルート起点	Edit(/src/**/*.ts)
path または ./path	カレントディレクトリ起点	Read(*.env)

⚠️ よくある誤解：/Users/alice/file は絶対パスではなく、プロジェクトルート起点です。絶対パスを表したいときは //Users/alice/file と書きます。

セッション中にルールを管理する

セッション中に /permissions コマンドを打つと、現在のルールを確認・編集できます。「これからは npm test を毎回許可してOK」のように、その場で allow ルールを追加できます。

⚠ 重要な仕様：deny ルールの限界

Read／Edit の deny ルールは、Claude Code 内蔵のファイルツールにしか効きません。Bash サブプロセス（Claude が裏で起動する別の Bash 実行環境）には適用されないため、Read(./.env) deny を設定していても、Bash で cat .env（ファイルの中身を表示するコマンド）は実行できてしまいます。

OS レベルで完全にブロックしたい場合は、Sandboxing 機能（サンドボックス：「砂場」の名のとおり、外に影響が出ない隔離空間でプロセスを動かす仕組み）を有効化するか、Bash 側でも Bash(cat .env) や Bash(cat .env*) を deny する必要があります。

---

📁 STEP 4：設定ファイルの場所と優先順位

設定ファイルはいくつかの場所に置けます。より具体的な場所が優先されるのがルールです。

場所	役割	Gitに含める？
.claude/settings.json	プロジェクト共有設定	✅ 含める
.claude/settings.local.json	個人専用のプロジェクト設定	❌ .gitignore
~/.claude/settings.json	全プロジェクト共通の個人設定	—

役割分担のコツ

• チームで共有したいルール（rm -rf 禁止、npm test 自動許可など）→ .claude/settings.json
• 自分だけの好み（個人ツールへのパス許可など）→ .claude/settings.local.json + .gitignore
• すべてのプロジェクトに適用したい個人ルール（自分のシェル設定の場所許可など）→ ~/.claude/settings.json

優先順位（より具体的なものが勝つ）

1. Managed settings（組織ポリシー、最強・上書き不可）
2. コマンドライン引数（一時的な上書き）
3. Local project settings（.claude/settings.local.json）
4. Project settings（.claude/settings.json）
5. User settings（~/.claude/settings.json）

どの階層であれ、deny で拒否されたものは他階層で許可しても通りません。これが「deny は最強」の所以です。

---

🚨 STEP 5：絶対に避けるべき4つのアンチパターン

これらはすべて「事故が起こる典型的な使い方」です。先に知っておくだけで、回避できます。

❌ アンチパターン1：本番マシンで --dangerously-skip-permissions

# 絶対にダメ
claude --dangerously-skip-permissions

これは bypassPermissions モードの別名で、ほぼすべての安全チェックを無効化します。隔離コンテナ・VM 以外では絶対に使わないでください。普段の開発マシンで使うと、Claude が予期せぬ操作をしたときに被害がローカル環境全体に及びます。

❌ アンチパターン2：本番DBの認証情報が読める状態で auto や acceptEdits モード

.env.production や credentials.csv が Claude Code から読める場所にある状態で、確認なしで動くモードを使うのは危険です。Claude が「データ確認のため」と判断して認証情報を読み取り、外部 API に送信してしまうリスクがあります。

.env* 系のファイルは、必ず deny リストに入れるのが基本です（前述の通り、Read／Edit と Bash の両方に deny を設定）。

❌ アンチパターン3：「確認がめんどくさいから」と早々に acceptEdits モードへ

Claude Code に慣れる前に確認をスキップしてしまうと、Claude が予想外のファイルを編集していたことに後で気づく、ということが起こりがちです。最低でも1〜2週間は default モードで運用し、Claude の挙動を観察してから判断してください。

❌ アンチパターン4：プロジェクト直下に機密ファイルがある状態で起動

secrets.json・credentials.csv・id_rsa などの機密ファイルをプロジェクト直下に置いたまま Claude Code を起動すると、コンテキストとして読まれてしまう可能性があります。機密ファイルは別ディレクトリに分離し、必要に応じて deny リストにも入れてください。

---

✅ STEP 6：初学者におすすめの安全な始め方（段階的アプローチ）

いきなり完璧な設定をする必要はありません。以下の段階的なアプローチで、自然にルールを育てていくのが現実的です。

第1〜2週：default モードで観察期間

default モードのまま使い、毎回の確認に慣れます。Claude が何を編集しようとしているかをしっかり目で見る練習期間です。

第3〜4週：信頼できるコマンドを allow に追加

よく使うコマンド（npm test、npm run build、git status など）を allow リストに追加していきます。確認回数を減らして快適な作業環境を構築します。

1ヶ月後：作業内容に応じてモードを切り替える運用に

「コードを書く時間は acceptEdits、設計するときは plan、それ以外は default」のような切り替え運用が定着します。Shift+Tab で簡単に切り替えられるので、状況に応じて使い分けましょう。

plan モードは積極的に活用

新機能の設計やリファクタリングの前に必ず plan モードを通すと、思わぬミスを防げます。「読み取り専用」なので、安心して Claude にコードベースを調査させられます。

---

🎯 推奨の初期設定（コピペで使えます）

以下を .claude/settings.json としてプロジェクト直下に配置すると、安全と利便性のバランスが取れた状態でスタートできます。

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(npm test *)",
      "Bash(npm run lint *)",
      "Bash(npm run build)",
      "Bash(npm run dev)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(ls *)",
      "Bash(cat *)",
      "Bash(grep *)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm install *)",
      "Bash(npm uninstall *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(sudo *)",
      "Bash(git push --force *)",
      "Bash(git push origin main)",
      "Bash(git push origin master)",
      "Bash(cat .env*)",
      "Read(.env)",
      "Read(.env.local)",
      "Read(.env.production)",
      "Read(.env.*)",
      "Read(**/secrets.*)",
      "Read(**/credentials.*)"
    ]
  }
}

このファイルをプロジェクトに置いて Claude Code を再起動すれば、すぐに反映されます。プロジェクトの状況に応じて、中身を調整してください。

---

🐳 STEP 7：自由に使いたいなら「隔離環境」を用意する

「いちいち確認するのが煩わしい」「auto や bypassPermissions を試したい」という方には、Devcontainer（VS Code がコンテナの中で開発できるようにする公式機能。「使い捨ての開発環境」をすぐ立てられる）や VM での運用が最適です。

ホストマシンと隔離されたコンテナの中なら、bypassPermissions モードで動かしても被害が箱の中に閉じ込められます。Anthropic 公式が devcontainer のリファレンス実装を提供しているため、それを使うのが一番確実で早い方法です。

OS レベルでさらに強固に隔離したい場合は、Sandboxing 機能を併用すると、Bash の挙動も含めて制限できます。

---

🧠 まとめ：3つの安全原則

1. 最初は default モードを徹底する。確認の手間は、慣れるための授業料と考える
2. .env 系と破壊的コマンドは必ず deny リストに入れる。これだけで重大事故の8割は防げる
3. Shift+Tab で柔軟にモードを切り替える習慣をつける。コードを書く時間は acceptEdits、設計するときは plan……のように使い分けると、安全と効率を両立できる

📘 公式ドキュメント：Configure permissions

---

🎮 Claude Code 解説シリーズ・全記事一覧

シリーズの他の記事もどうぞぉ……気になるところから読んでねぇ。

📘 01. Claude Code 用語集（初学者向け・全23語）
🚀 02. インストールと初回起動ガイド
📝 03. CLAUDE.md 完全ガイド
🛠️ 04. 実践ワークフロー集
🛡️ 05. パーミッションと安全設定ガイド
⚡ 06. スラッシュコマンド & スキル完全ガイド
🔌 07. MCP・Hooks活用ガイド
🎭 08. サブエージェント・並列作業ガイド
🏆 09. プロのベストプラクティス完全集
🎨 10. Claude Code × 3DCG活用ガイド
🧊 11. Claude Code × Blender 導入ガイド