Permissions — 確認を減らしつつ、危険な操作だけ止める

毎回すべてを確認すると作業が止まり、すべて自動にすると危険な操作まで通ってしまう。この章を読むと、どの操作を自動で許可し、どの操作は確認させるかを自分で決められるようになる。確認の回数を減らしながら、取り返しがつかない操作だけは止める設定を作る。

目次

---

1. Permissionsとは何か

Permissionsは、どの操作を自動で許可し、どの操作は確認させるかを、操作ごとに決めておく仕組みになる。

なぜこれが要るのかは、確認の頻度の選択肢を見ると分かる。「基本操作 — 指示を出し、変更を確認して承認する」の「確認モードを切り替える」で扱ったモードは、両極端になっている。

Manualで使っていると、同じ操作を何度も承認することになる。安全な操作まで毎回止まるのは煩わしい。かといってAutoにすると、見たい変更まで通り過ぎてしまう。

Permissionsは、その中間を作る。

「この操作はもう確認しなくていい」  → 許可しておく
「この操作は必ず確認したい」        → 確認させる
「この操作は絶対にさせたくない」    → 禁止する

操作ごとに決められるので、安全性を落とさずに確認の回数だけを減らせる。

---

2. Permissionsを設定するメリット

設定すると何が変わるのかを、3つに分けて示す。

メリット1:同じ承認を繰り返さなくなる

「基本操作 — 指示を出し、変更を確認して承認する」の「確認モードを切り替える」で「最初はManualを勧める」と書いたが、Manualのまま使い続けると確認が多すぎる。例外を足していくことで、Manualのまま実用的な速度になる。

安全な操作(ファイルの一覧表示など)を許可しておけば、確認画面はそのぶん減る。

メリット2:危険な操作が自動で止まる

許可と逆向きの効果になる。禁止しておいた操作は、こちらが疲れていても、見落としていても実行されない。

承認画面を見てその場で判断するのではなく、判断そのものを先に済ませておける。

メリット3:CLAUDE.mdでは止まらないものが止まる

これがPermissionsの最も大きな利点になる。

「CLAUDE.md — 会話をまたいで前提を引き継がせる」で扱ったCLAUDE.mdは、AIへの指示を文章で書くファイルになる。ここに「削除しないで」と書くことはできるが、確実に止まるわけではない。文章による指示だからである。

「設定ファイル — settings.json でツールの動作を決める」の「設定ファイルとは」で見た通り、設定ファイルの内容はAIの判断を経ずにClaude Code自体が読む。だからAIがどう判断しても結果が変わらない。

絶対に触られたくないものは、Permissionsで守る。 これが唯一確実な方法になる。

---

3. ルールの3種類

Permissionsに書くルールは3種類ある。

許可は利便性のため、禁止は安全のために使う。確認は、モードによっては自動で進んでしまう操作を、明示的に止めたいときに使う。

一人で使う場合、実際に書くのは許可と禁止の2つがほとんどになる。

---

4. 判定される順番

複数のルールが当てはまる場合、どれが採用されるかの順番が決まっている。

① 禁止(deny)   ← 最初に見る
     ↓ 当てはまらなければ
② 確認(ask)
     ↓ 当てはまらなければ
③ 許可(allow)

最初に当てはまったものが採用される。

広い禁止は、狭い許可に勝つ

ここが最も間違えやすい点になる。細かく書いた許可より、大まかに書いた禁止の方が強い。

禁止:「git コマンド全部」
許可:「git の状態確認だけ」
  ↓
結果:状態確認も禁止される

「全体を禁止して、一部だけ許可する」という書き方はできない。禁止したものは、例外なく禁止になる。

この性質は、事故防止の観点では都合がよい。禁止したものが、うっかり許可で穴を開けられることがない。

一方で、「基本は禁止、これだけ許可」という設計をしたい場合は、禁止を広く書かず、許可したいものを外して書く必要がある。

---

5. 作り方2パターン

作り方は2つある。日常的に使うのはボタンのほうで、設定ファイルを開くのは禁止ルールを書くときが中心になる。

5.1 ボタンで作る

確認画面には、承認・却下のほかに「今後は確認しない」という選択肢が出ることがある。

これを選ぶと、その操作が許可ルールとして自動で保存される。次回から同じ操作は確認なしで進む。

画像は準備中承認・却下と並んで「今後は確認しない」の選択肢が表示されている確認画面

日常的に使うのはこの方法になる。 同じ確認が何度も出てきたら押す、という運用で足りる。

どこに保存されるか

「設定ファイル — settings.json でツールの動作を決める」の「settings.json を実際に書く」で触れた通り、保存先はプロジェクトの .claude/settings.local.json になる。

自分で作った覚えのないファイルが増えるが、これが正体である。中身を見れば、自分が許可した操作の一覧が入っている。

保存されないものもある

すべての承認が保存されるわけではない。

ファイル編集の承認は保存されない。会話を変えれば、また確認が入る。

これは安全のための設計になる。ファイルの書き換えは影響が大きいため、恒久的な許可を簡単には作らせない仕組みである。

5.2 設定ファイルに書く

まとめて設定したい場合や、禁止ルールを作る場合は、設定ファイルに直接書く。

「設定ファイル — settings.json でツールの動作を決める」で扱った settings.json に、permissions という項目を書く。

{
  "permissions": {
    "allow": [
      "Bash(ls *)",
      "Bash(git status)"
    ],
    "deny": [
      "Bash(rm *)"
    ]
  }
}

形は決まっている。

• allow に、許可したい操作を並べる
• deny に、禁止したい操作を並べる
• それぞれ角括弧 [ ] で囲み、カンマで区切る

「設定ファイル — settings.json でツールの動作を決める」の「書くときの注意点」の決まり(コメント不可・末尾カンマ不可)はここでも同じである。

置き場所は同記事の「settings.json の置き場所」の通りで、そのフォルダだけに効かせたいならプロジェクト側、全部の作業に効かせたいならユーザー用に書く。

5.3 書き方の一覧

5.2 で書いた Bash(ls *) のような部分は、2つの要素の組み合わせになっている。

Bash(git status)
└┬─┘ └────┬────┘
 │        └ 対象  :どれに対してか
 └ ツール名:何をする操作か

前半で操作の種類を決め、後半でその範囲を絞る。 この2つが揃って1つのルールになる。

* は「ここから先は何でも」という意味になる。Bash(git *) と書けば、git status も git log も含めて、gitコマンド全部が対象になる。

対象を書かないと、そのツール全部が対象になる。 Bash とだけ書けば、コマンドの実行すべてが当てはまる。

丸暗記する必要はない。 ボタンで作ったルールを後から見れば、この書き方の実例が並んでいる。読めれば十分である。

---

6. 書いておいたほうがいいもの

2章「Permissionsを設定するメリット」で見た通り、確実に止められるのは禁止ルールだけになる。許可より先に、禁止から書く。

禁止しておくとよいもの

一般的に、次のようなものを禁止しておくと安心できる。

自分の作業内容に合わせて選べばよい。「これをされたら困る」と思うものを書くのが基準になる。

許可は先回りして書かない

逆に、許可ルールは事前に書かないほうがよい。

使う前に「これも許可しておこう」と並べると、実際には出てこない確認まで許可することになる。何を許可したのかも把握しにくくなる。

許可は 5.1「ボタンで作る」の方法で、確認が実際に煩わしくなってから足す。

効き方の確認

禁止ルールを書いたら、実際に止まるかを確かめておくとよい。禁止した操作を含む指示を出してみて、AIが実行できない旨を返せば効いている。

---

7. 最初の設定手順

何から手を付けるか迷う場合、次の順で進めるとよい。

手順1:禁止ルールを2つか3つ書く

作業を始める前に、触られたくないものだけを書く。

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

これだけでも、事故の大半は防げる。

手順2:許可はボタンで足していく

同じ確認が何度も出てきたときに、「今後は確認しない」を押す。実際に煩わしいと感じたものだけが溜まっていくので、無駄がない。

手順3:溜まったら見直す

しばらく使うと settings.local.json に許可が溜まってくる。ときどき開いて、身に覚えのないものや、もう必要ないものを消す。

許可を消しても困らない。また確認が出るようになるだけである。

---

次のページ

ここまでで、操作ごとに任せる範囲を決められるようになった。しかし、これは個々の操作に対する制御である。

大きな作業を任せるときは、別の心配が出てくる。「何をするつもりなのか」が分からないまま、いくつもの操作が続けて実行されることになるからである。

次の「Sub Agents — 別のAIに調べ物を任せ、会話を汚さない」では、役割の違う複数のAIに作業を分担させる仕組みを扱う。調べる担当と書く担当を分ける、といった使い方ができるようになる。

---

← ⑪ 設定ファイル ｜ 次:⑬ Sub Agents →