Claude Codeを使ったAI駆動アプリ開発入門

パーミッションのルールを知ろう

Claude Codeは、CLI上で動くLLMによるAI開発支援ツールです。本連載は全5回を予定しています。実務経験1~3年程度のエンジニア向けに、対話モードでの会話の基本、コンテキストと@記法、スラッシュコマンドとパーミッションの基本を解説し、最後に学んだ知識を総動員してアプリ開発をハンズオンで体験します。なお本連載は2026年9月刊行の『Claude Codeで作って学ぶ AI駆動アプリ開発入門』から一部を抜粋・編集してお届けします。

第4回では、Claude Codeが勝手にファイルやフォルダを操作したり、削除したりしないための「パーミッション設定」について解説します。

パーミッション設定が必要な理由を知ろう

ここからは、Claude Codeの操作をより安全に制御する方法に目を向けていきましょう。

Claude Codeでは安全のため、シェルコマンドを実行する際や一部ツールの実行時には承認を求める仕組みがあります。

たとえばファイルやフォルダの一覧を表示するlsや、カレントディレクトリを表示するpwd、ファイル内容を確認するcatは読み取り専用のシェルコマンドであり、これらは承認せずとも自動実行されます。Claude Codeが読み取り専用の操作と認識し、安全なコマンドとして扱うためです。

一方で、ファイルを削除するrmや、ファイルを作成するtouch、他にもフォルダを作成するmkdir など、ファイルやフォルダを変更するシェルコマンドは承認を求められます。以下はClaude Codeにファイル削除を指示した際、シェルコマンドであるrmの実行への承認を求められた例です。

● Bash(rm /Users/username/Desktop/my-project/package.json)
    Running

  Bash command

    rm /Users/username/Desktop/my-project/package.json
    Delete package.json

  Do you want to proceed?
  › 1. Yes
    2. Yes, and always allow access to my-project/ from this project
    3. No

  Esc to cancel · Tab to amend · ctrl+e to explain

この例では、rmコマンドを実行する前に、「⁠Do you want to proceed?」という確認プロンプトが表示されます。このプロンプトでは、「⁠Yes」を選択するとrmコマンドが実行され、「⁠No」を選択するとrmコマンドが実行されません。また上から2つ目の「Yes, and always allow access to my-project/ from this project」を選択すると、そのプロジェクト内ではその後のrmコマンドの実行が自動で承認されるようになります。

なお、連載の第1回で紹介したAuto-Acceptモード(Shift+Tabで切り替え)は、ファイルの作成・編集のみを自動承認します。シェルコマンドの実行やWebアクセスなどは引き続き承認を求められます。

1つひとつの操作を自分の目で確認してから進められるため安心感があります。

ただ、開発を進めていくと「フォルダを作るだけなのに毎回確認が出る」「⁠安全なコマンドなのに承認を求められる」という場面が増えてきます。こんなときに、操作ごとに「許可する」「⁠禁止する」「⁠確認を挟む」を細かく設定できたら理想的です。それを実現するのがパーミッション設定です。パーミッション設定はJSON形式で記述し、設定ファイルとして永続化されるので、一度設定すればその後のセッションでも引き継がれます[1]。

パーミッションの仕組みを知ろう

Claude Codeは、シェルコマンドの実行やファイルの読み書きといった操作を「ツール」と呼ばれる機能単位で実行します。パーミッションとは、Claude Codeの各操作に対して「自動で許可」「⁠完全に禁止」「⁠毎回確認」を設定するルールです。

大きく「コマンド実行系(Bash⁠)⁠」⁠「⁠ファイル操作系(Read/Edit/Write⁠)⁠」⁠「⁠Web通信系(WebFetch⁠)⁠」の3グループがあり、具体的には以下の操作が制御対象になります。

パーミッション設定の対象となるツールと制御する操作
ツール 制御する操作 例
Bash シェルコマンドの実行 npm run test、rm -rf
Read ファイルの読み取り ソースコードの参照、.envの読み取り
Edit 既存ファイルの編集 コードの修正
Write 新規ファイルの作成 テストファイルの作成
WebFetch Webアクセス URLからの情報取得

実際にはMCPサーバーが提供するものなど、ほかにも制御対象となるツールがありますが、ここでは主にこの5つを扱います。

この中でもシェルコマンドに相当する「Bash」の実行を制御することはセキュリティ上、特に重要です。シェルコマンドはファイル削除や外部通信など影響範囲が大きい操作を実行できるため、次に紹介するルール設定で最も細かく制御したい対象になります。

3つのルールを覚えよう⁠:deny⁠、ask⁠、allow

パーミッションの制御には3つのルールを使います。それが「禁止・確認・許可」の3段階で、安全性と利便性をバランスよくコントロールできます。

2択(許可か禁止か)では「実行する前に毎回確認したい」という中間の操作に対応できませんが、実行の前に確認を挟むaskがその橋渡しをしてくれます。安全性に直結するdenyから順に解説します。

deny(禁止)

denyに指定した操作は、完全にブロックされます。Claude Codeがどのような理由をつけても、denyに設定された操作は実行されません。「⁠絶対に実行されたくない操作」をここで防ぎます。

ask(確認を強制)

denyで「完全ブロック」する操作が決まったら、次はaskです。denyほど危険ではないけれど、実行前に確認を挟みたい操作はaskに入れます。askに指定した操作は、毎回確認プロンプトが表示されます。実行するかどうかを自分で判断できるため、「⁠自動では実行させず、毎回自分の目で確認してから進めたい操作」に向いています。

allow(許可)

denyで「禁止⁠」⁠、askで「確認」の仕組みができました。最後のallowは、信頼できると判断した操作を自動化するためのルールです。allowに指定した操作は、確認なしで自動実行されます。毎回承認する手間が省けるため、開発の流れを止めたくない頻繁な操作に使います。

ルールの優先度⁠:Deny > Ask > Allow

同じ操作が複数のルールにマッチした場合、denyが最も強く、次にask、最後にallowの順で評価されます。allowに含まれている操作でも、askに該当すれば確認が入ります。

たとえば、Bash(git *)をallowに、Bash(git push --force *)をdenyに設定したとしましょう。この設定では、git statusは自動実行されますが、git push --force origin main はallow(Bash(git *))にもdeny(Bash(git push --force *))にも該当します。この場合、denyが優先されるためブロックされます。

「迷ったらdenyに入れておく」と覚えておけば、誤って危険な操作が実行されるのを防げます。

「安全に使う」ための考え方を身につけよう

ここからは、「⁠実際にどの操作をどのルールに当てはめるか」という判断の考え方を、典型的な例とともに見ていきましょう。

denyに入れるもの⁠:絶対に防ぐべき操作

主な判断の軸は「実行したら取り返しがつかない操作か」「⁠権限や機密情報に触れる操作か」の2点です。以下は代表的な例です。他にもプロジェクト固有の危険な操作(本番DBへのマイグレーション実行など)があれば、denyに追加しておきましょう。

denyに設定する操作例
操作 理由
rm -rf ディレクトリごと強制削除してしまう[2]
sudo root権限での実行は危険
.env ファイルの読み取り APIキーやパスワードが含まれている可能性がある

askに入れるもの⁠:確認を挟みたい操作

判断の軸は「完全にブロックするほどではないが、実行前に一度確認したい操作か」です。リモートへの変更や外部通信など、影響範囲が広いコマンドが候補になります。

askに設定する操作例
操作 理由
rm ファイル削除は念のため確認しておきたい(rm -rfはdenyで別途ブロック)
git push リモートリポジトリへの変更は影響が大きい
curl/wget 外部との通信は確認してから実行したい

allowに入れるもの⁠:自動化して効率を上げる操作

判断の軸は「頻繁に繰り返す操作で、かつ実行しても問題ないと判断できる操作か」です。毎回の確認を省くことで、開発の流れを止めずに済みます。

allowに設定する操作例
操作 理由
Edit/Write 開発の基本操作で頻繁に使う
Bash(npm test) / Bash(npm run *) 繰り返し実行するため確認を省いてサイクルを速くしたい
Bash(git status) / Bash(git diff) / Bash(git log) 変更確認・履歴確認は読み取り専用で安全
mkdir/touch/cp ファイルの作成やコピーは日常的に使う

ここで挙げたのはあくまで代表的な例です。プロジェクトの内容やチームの運用方針によって最適な設定は異なります。

「この操作はどのルールに当てはまるか」を考えながら、危険度と影響範囲を軸に自分のプロジェクトに合わせてカスタマイズしていきましょう。

settings.json で設定しよう

パーミッションの設定は、プロジェクトの.claude/settings.jsonに記述します。プロジェクトの中に.claude/というディレクトリを作り、その中にsettings.jsonファイルを作成します。

以下は、パーミッションの設定を書く際の例です。

.claude/settings.jsonに記述するパーミッション設定の例
{
  "permissions": {
    "allow": [
      "Bash(npm test)",
      "Bash(npm run *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(touch *)",
      "Bash(mkdir *)",
      "Bash(cp *)",
      "Edit",
      "Write"
    ],
    "deny": [
      "Bash(sudo *)",
      "Bash(rm -rf *)",
      "Read(.env*)"
    ],
    "ask": [
      "Bash(rm *)",
      "Bash(git push *)",
      "Bash(curl *)"
    ]
  }
}

この設定では、テスト実行や状態確認のコマンド、ファイル操作を自動承認しています。なお、ls・cat・pwdのような読み取り専用の基本コマンドはデフォルトで自動実行されるため、明示的に記述する必要はありません。sudoやrm -rfは完全にブロックし、ファイル削除やリモートへのpushには確認を挟むようにしました。

まずはこの設定をベースにして、プロジェクト固有のコマンド(dockerやnpm publishなど)を必要に応じて追加していくとよいでしょう。

settings.jsonの変更は保存した時点で即座に反映されます。ただし、初めて.claude/settings.jsonを作成した場合は、Claude Codeを一度終了して起動し直すことで確実に読み込まれます。

> /exit
claude

Bashパターンの書き方⁠:ワイルドカードマッチング

設定例の中でBash(npm test)やBash(rm -rf *)のような書き方が登場しています。この*の使い方にはルールがあります。

*はワイルドカード(任意の文字列にマッチする特殊文字)で、コマンドの先頭・途中・末尾のどこにでも配置できます。

たとえばBash(git push *)と書くと、git push origin mainやgit push --forceなど、git pushで始まるすべてのコマンドがマッチ対象になります。Bash(* --version)のように先頭に置いたり、Bash(git * main)のように途中に置くこともできます。

Read/Editのパス記法

ReadやEditの設定では、特定のファイルやディレクトリを指定できます。

.envファイルの読み取りをブロックする設定
"Read(.env*)"

この例では、.envで始まるすべてのファイルの読み取りをブロックしています。Claude Codeは通常プロジェクトルートから起動するため、ルート直下だけでなくsrc/.envのようなサブディレクトリのファイルも対象になります。

この設定により、.envや.env.localなどに含まれるAPIキーをClaude Codeが誤って読み取ることを防げます。

グローバル設定への発展

ここまでプロジェクトの.claude/settings.jsonに設定を書く方法を紹介しました。設定ファイルには、用途に応じた3種類があります。

パーミッション設定ファイルの種類とスコープ
ファイル スコープ チームと共有
.claude/settings.json プロジェクト される(Git管理対象)
.claude/settings.local.json プロジェクト(個人) されない
~/.claude/settings.json 全プロジェクト共通 されない

.claude/settings.local.jsonは、チームには共有したくない個人の設定(自分だけ許可したいコマンドなど)を書く場所です。このファイルは、Claude Codeが作成した際にグローバルなGit設定(~/.config/git/ignoreなど)へ自動でignore対象として登録されます。

ただし環境によっては自動設定が正常に動作しないことがあります。念のためgit statusでGit管理対象になっていないかを確認し、表示される場合はプロジェクトの.gitignoreに.claude/settings.local.jsonを追加しておきましょう。

~/.claude/settings.jsonには、どのプロジェクトでも共通して使いたいルール(たとえばrm -rfやsudo のdeny)を書けます。複数のプロジェクト間で同じ設定を何度も書く手間が省けます。

複数の設定ファイルが存在する場合、優先順位は次のとおりです(上ほど優先⁠)⁠。

  1. 管理者設定(組織のMDM管理など)
  2. Claude Code の起動オプション(--dangerously-skip-permissions など)
  3. .claude/settings.local.json(プロジェクト個人設定)
  4. .claude/settings.json(プロジェクト共有設定)
  5. ~/.claude/settings.json(グローバル設定)

設定を確認しよう

settings.jsonに設定を書いたら、実際に動くかどうか確かめておきましょう。

設定ミスがあると、ブロックしたはずのコマンドが実行されたり、パターンが合わずに意図しないコマンドまでブロックされたりすることがあります。

設定を書いたら、必ず正しく反映されているかを確認しましょう。

/permissions コマンド

対話モード内で /permissionsと入力すると、現在のパーミッション設定を確認・管理できます。

> /permissions

実行すると、Allow/Ask/Deny/Workspaceの4タブで構成された対話UIが表示されます。

/permissionsを実行したときのUI(Allowタブを表示中)
Permissions:  Allow   Ask   Deny   Workspace  (←/→ or tab to cycle)

Claude Code won't ask before using allowed tools.

 ⌕ Search

 › 1.  Add a new rule
   2.  Bash(cat *)
   3.  Bash(cp *)
   4.  Bash(echo *)

Press ⇅ to navigate · Enter to select · Type to search · Esc to cancel

矢印キーやTabキーでタブを切り替えると、各カテゴリのルール一覧を確認できます。リスト内のルールを選択すると、そのルールがどの設定ファイルから読み込まれているかを確認できます(.claude/settings.json のルールは「From shared project settings⁠」⁠、~/.claude/settings.json のルールは「From user settings」と表示されます⁠)⁠。

なお、このUIから「Add a new rule...」を選択すると、対話式で設定を追加・削除することもできます。

パーミッションルールの追加操作画面
パーミッションルールの追加操作画面

この方法なら自動でsettings.jsonファイルも作成されますので、手動で作成する手間が省けます。

まとめ

パーミッション設定では、deny(禁止⁠)⁠・ask(確認⁠)⁠・allow(許可)の3つのルールを使って、Claude Codeの操作権限を細かく制御できます。

設定は .claude/settings.jsonに記述し、/permissionsコマンドで正しく反映されているかを確認しましょう。パーミッション設定を活用することで、Claude Codeの操作を安全かつ効率よく管理できます。

最終回となる次回は、この連載で学んだことを総動員して本格的なWebアプリ開発に挑戦してみたいと思います。

おすすめ記事

記事・ニュース一覧