Claude Code 権限の“はしご”：厳しめから安全に allow を広げる5段

導入した初日に、僕は欲張って Bash(git *) を allow に入れました。git status も git diff も確認なしで通って、最高に速い。三日くらいは気分がよかったです。

四日目の夜、Claude が git reset --hard を「確認なし」で実行しました。git で始まるコマンドを全部 allow にしていたんだから、当然です。半日分の作業が消えました。バックアップで戻せたけど、あのときの胃の落ち方は今でも覚えています。

ここで僕が学んだのは、権限は「広げてから絞る」と必ず事故るということ。順番が逆なんです。最初は窮屈なくらい ask と deny で固めて、検証して安全だと分かった操作だけを、一段ずつ allow に昇格させる。階段というより、片足ずつ確かめながら登るはしごです。今日はその5段の登り方と、「次の段に足をかけていい条件」を書きます。

この記事の要点

• 権限は厳しめスタート（ask/deny 多め）→ 信頼が積み上がった操作だけ allow に昇格が鉄則。逆順は事故る。
• 昇格の判断は「賢いか」ではなく**「検証コマンドがあるか」「戻せるか」**。この2つだけで段を決める。
• 5段ラダー：①読み取りのみ → ②検証コマンド → ③限定パスの編集 → ④コミット系 → ⑤deploy は確認付き。push・force・本番DB・課金・.env は最後まで deny。
• 各段に**昇格条件（プロモーション基準）**を置く。「○日無事故」「検証が緑」を満たして初めて次へ。
• 設定の網羅リファレンスは 権限設定リファレンス、mode と sandbox の運用判断は 承認とsandboxの線引き に。この記事は「緩め方の段階」だけに集中。

設定ファイルの書式そのもの（Bash パターンの :*、gitignore 形式のパス指定など）は姉妹記事に任せます。ここで覚えてほしいのは、登る順番と、各段の昇格条件です。

なぜ「広げてから絞る」は必ず事故るのか

allow を先に広く取ると、危ない操作はもう走り終わっています。事故ってから「あ、ここ deny し忘れてた」と気づく。冒頭の僕がまさにこれでした。後追いの deny は、火が出てから消火器の場所を探すのと同じです。

逆向きに登ると、未知の操作はデフォルトで止まります。Claude Code の評価順は deny → ask → allow で、最初に当たったルールが勝つ。つまり明示的に allow していない操作は、ask に落ちて毎回あなたに聞きにきます。最初は確認が多くてうっとうしい。でもそのうっとうしさが、未検証の操作を本番に流さない安全弁です。

もうひとつ大事な前提。deny / ask を強制するのは Claude Code 本体であって、モデルではありません。 CLAUDE.md に「push 禁止」と書いても、それは Claude の「やろうとすること」を変えるだけで、許可の境界は動きません。境界を動かすのは permissions ルール・permission mode・PreToolUse フックの3つだけ。だからラダーは「お願い」ではなく settings.json の allow/ask/deny で物理的に組みます。

そして昇格の判断軸は、たった2つに絞れます。

• 戻せるか？ 5分後に git checkout で消せる操作は速くしていい。push・deploy・送信・課金は取り消せないから最後まで遅く。
• 検証コマンドがあるか？ 編集を許すかどうかは「編集が危険か」ではなく、編集のあと何で検証するかで決まる。npm run build や npm test が緑になる仕組みがあるなら、編集は段を上げていい。なければ ask に残す。

この2軸を頭に入れて、5段を順に見ていきます。

5段ラダーの全体像

まず地図を貼ります。各段で「やること」と「次へ進む合図（昇格条件）」をセットで持つのがコツです。

段	この段で allow にする	触らせない（ask/deny のまま）	次の段への昇格条件
Lv0 読み取り	Read Glob Grep	編集・実行すべて ask	リポジトリ構造を Claude が誤解せず説明できた
Lv1 検証	git status git diff build test lint	編集は ask のまま	検証コマンドが手元で緑になると確認した
Lv2 限定編集	Edit/Write を 特定パスだけ ask→（成熟後）allow	auth・billing・CI 設定は ask	そのパスの編集を5回連続でレビューし破綻ゼロ
Lv3 コミット	git add git commit を ask（成熟後 allow）	git push はまだ ask	コミット粒度と差分が毎回想定どおりだった
Lv4 deploy	deploy は allow にせず確認付き	push・force・本番DB・課金	（ここから上は基本的に上げない）

最終段で deny に残すもの	理由
git push --force 系	履歴が壊れて他人の作業を巻き込む。取り返しがつかない
rm -rf 系・git reset --hard	一発で消える。冒頭の僕の事故がこれ
.env secrets/** の読み取り	秘密情報をモデルの文脈に載せない
本番DBへの書き込み・課金・メール送信	押した瞬間に外の世界が変わる

ポイントは、**右に行くほど「昇格に時間をかける」**こと。Lv0→Lv1 は同じ日に上げていいけど、Lv2 の allow 化は数日〜1週間、Lv3 は2週間くらい様子を見ます。そして Lv4 から上は、原則として allow に上げません。「確認付きで実行」が最終形です。

Lv0〜Lv1：今日のうちに上げていい段

最初の2段は、戻せる操作しかありません。ここで時間をかける必要はないので、初日に上げます。

Lv0（読み取りのみ）。Read Glob Grep だけを allow。Claude にリポジトリを読ませて、「このプロジェクトの構成を3行で説明して」と聞いてみてください。的外れな説明が返ってくるなら、まだ読ませ方が足りないか、CLAUDE.md が薄い。ここで構造を正しく掴めたら、Lv1 へ。

Lv1（検証コマンド）。git status git diff と、build・test・lint を allow に足します。これらは何回回しても戻せるので怖くない。むしろここを速くしておくのが、後の段を安全にする伏線です。なぜなら Lv2 以降で編集を許すかどうかは「検証で緑にできるか」で決まるから。先に検証を allow にしておけば、Claude は自分で npm test を回して確かめながら直せます。

この段までの settings.json はこうなります。

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Bash(npm run build)",
      "Bash(npm run lint)",
      "Bash(npm run test:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)"
    ],
    "ask": [
      "Edit",
      "Write",
      "Bash(npm install:*)"
    ],
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(secrets/**)",
      "Bash(rm -rf *)",
      "Bash(git push --force:*)",
      "Bash(git reset --hard:*)"
    ]
  }
}

注目してほしいのは、まだ編集を一切 allow にしていないこと。Edit Write は ask です。それでいて deny には、上の段に登っても絶対に外さない破壊系・秘密系を最初から並べてあります。deny は「念のため広めに」で損しません。allow に上げる日が来ない前提で先に塞いでおく。

Lv2：編集を「パス限定」で開ける段

ここが一番悩む段です。多くの人がいきなり Edit を丸ごと allow にして事故ります。Edit をカッコなしで書くと全ファイルの編集にマッチするので、.github/workflows/ も package.json も触り放題になる。

正しいのは、編集を「許す/許さない」の二択にせず、パスで段階を切ることです。

1. まず編集対象を、安全な順に並べる。記事・ドキュメント → UI コンポーネント・テスト → 設定ファイル → auth/billing/CI、の順で危険度が上がる。
2. 一番安全なパス（例：site/src/content/**）だけを Edit/Write の ask に出す。最初から allow にはしない。
3. そのパスの編集を5回くらい連続でレビューして、想定外の書き換えがゼロだったら、そのパスだけを ask から allow に昇格させる。
4. auth・billing・migration・CI 設定（.github/workflows/** など）は、最後まで ask か deny に残す。ここは戻せない影響が大きすぎる。

つまり Lv2 の中にも小さなラダーがある、ということです。「安全なパスだけ ask → 無事故なら allow → 危険なパスは据え置き」。

{
  "permissions": {
    "allow": [
      "Edit(site/src/content/**)",
      "Write(site/src/content/**)"
    ],
    "ask": [
      "Edit(src/components/**)",
      "Edit(src/**/*.test.ts)"
    ],
    "deny": [
      "Edit(.github/workflows/**)",
      "Edit(.env)",
      "Edit(.env.*)"
    ]
  }
}

acceptEdits mode を使えば、編集だけを一時的に自動承認しながらレビューできます。Shift+Tab で default → acceptEdits → plan を切り替えられるので、「いまは編集を速く回したい」セッションだけ acceptEdits に入る、という使い分けが便利です。mode と sandbox の細かい判断は 承認とsandboxの線引き にまとめてあります。

Lv3〜Lv4：取り消せない操作は登り切らない

最後の2段は、考え方が前半と変わります。ここは「allow に上げる」のではなく「どこで止め続けるか」を決める段です。

Lv3（コミット系）。git add git commit は、ローカルで完結するので比較的安全です。git commit までは ask にして、コミット粒度と差分が毎回想定どおりだと確認できたら allow に上げてもいい。ただし git push は別。push した瞬間にリモートが変わり、他人の作業に影響します。push は最後まで ask に残すのが僕のおすすめです。

Lv4（deploy）。deploy・publish・本番反映は、allow にしません。「確認付きで実行」が最終形です。npx wrangler pages deploy のようなコマンドは ask に置き、Claude が「deploy します」と言ったときに、ビルドが通っているか・差分が想定どおりか・戻す手順があるかを人間が見てから Enter。ここを自動化したい誘惑が一番強いけど、取り消せない操作を自動化するのは、補助輪を外す場所を間違えているのと同じです。

そして全段を通じて、deny は固定です。force push・rm -rf・reset --hard・.env 読み取り・本番DB書き込み・課金は、どの段に登っても外さない。disableBypassPermissionsMode を "disable" にしておくと、うっかり --dangerously-skip-permissions（= bypassPermissions mode）で起動して全部すり抜ける事故も防げます。これは managed 設定に置くとチーム全体で外せなくなります。

deny はチーム共有の .claude/settings.json に、個人の allow 追加は .claude/settings.local.json に分けるのも効きます。権限ルールはスコープをまたいでマージされ、どこか1か所で deny されたら他のどのレベルでも allow できないので、チームの deny を個人設定で外せなくなります。

僕がラダーで失敗した3つ

正直に書きます。順番を守れるようになるまで、何度かやらかしました。

ひとつ目は、冒頭の Bash(git *) を一気に allow。git で始まれば reset --hard も push --force も通る。広い allow を置くなら、危険な形を deny で先に潰す。これを学んでからは、allow を広げる前に必ず deny を点検するようになりました。

ふたつ目は、昇格を「なんとなく」でやったこと。「もう慣れたし allow でいいか」で Edit を全パス開けたら、Claude が package.json の依存を書き換えてビルドが壊れました。昇格条件を「○回無事故」と数で決めてからは、感覚で上げなくなりました。

みっつ目は、deny を後回しにしたこと。最初は allow だけ書いて「危ないのは気をつければいい」と思っていた。気をつけられるわけがないんです。忙しい日は反射で Enter を押す。deny を最初に全部置いてからは、プロンプト側で何を言われても本体が止めてくれるようになりました。

よくある質問

Q. 全部 ask で始めれば、ラダーなんて要らないのでは？ 全 ask は安全ですが、毎回判断が必要で続きません。読まずに反射で承認する癖がつくと、ask があっても無いのと同じです。戻せる操作（読み取り・検証）は allow に上げて速くし、戻せない操作だけ ask に残す。メリハリをつけるのがラダーの目的です。

Q. どのくらいの期間で次の段に上げていい？ 時間ではなく回数と検証結果で判断してください。Lv0→Lv1 は同日でOK。Lv2 の allow 化は「そのパスの編集を5回連続でレビューして破綻ゼロ」。Lv3 は2週間ほど様子を見る。Lv4 は原則上げない。「○日経ったから」ではなく「○回無事故だったから」です。

Q. チームで使うとき、各自が勝手に allow を広げない？ deny はチーム共有の .claude/settings.json に、個人の allow 追加は settings.local.json（gitignore 対象）に置きます。権限はマージされ deny が最優先なので、チームの deny を個人設定で外せません。disableBypassPermissionsMode を managed 設定に入れれば、抜け道もふさげます。

Q. sandbox を使えば allow を全開にしていい？ いいえ。sandbox は Bash が触れる範囲を OS レベルで狭める仕組みで、許可の境界とは別物です。しかも native Windows では動きません（macOS / Linux / WSL2 のみ）。sandbox は「もう一枚の壁」であって、ラダーの代わりにはなりません。詳細は 承認とsandboxの線引き に。

Q. 設定の書式（:* とパス指定）が難しい。 Bash の :* はサブコマンドにマッチさせる書き方、パスは gitignore 形式でアンカーが4種類あります。ここは網羅リファレンスの 権限設定リファレンス と 権限監査チェックリスト を見るのが速いです。この記事は「どの順で上げるか」に絞っています。公式の定義は Claude Code 公式ドキュメント（permissions） が一次情報です。

実際に試した結果

冒頭の git reset --hard 事故のあと、僕は「allow を増やす」発想をやめました。代わりに見るのは、いま自分が何段目にいるかです。

新しいリポジトリを触るときは、必ず Lv0 から。読み取りだけで構造を確かめ、検証コマンドを allow にし、編集は安全なパスだけ ask に出す。退屈なくらい遅い立ち上がりです。でも、この順番にしてから、戻せない操作が勝手に走ったことは一度もありません。

面白いのは、ラダーを意識するとClaude への信頼の持ち方が変わることです。「このAIは賢いから任せる」ではなく、「この操作は検証で緑になったから一段上げる」。判断が感覚から記録に変わる。だから次のリポジトリでも、同じ昇格条件を使い回せます。

権限設計は、賢いAIを信じる技術ではありません。転んでも半日分の作業が消えない順番で、一段ずつ登る技術です。まずは Lv0 から。最初の数日は窮屈ですが、それが一番速い登り方でした。

もっと深く設計したい人は、書式は 権限設定リファレンス、mode と sandbox の運用判断は 承認とsandboxの線引き へ。自分のチームの運用に落とし込みたいなら 研修・相談 でも受け付けています。