Claude Codeの権限設定に迷ったことはないだろうか。settings.json を開いて Allow / Deny / Ask を並べはじめると、「この操作はどっちにすべきか？」という問いに何度もぶつかる。公式ドキュメントを読んでも「何をAllowにするか」の判断基準は書いていない。機能の使い方はわかっても、設計の判断ができない状態だ。
この記事では「任せる / 確認する / 拒否する」の3段階で権限設計の意思決定を整理するフレームを紹介する。筆者が実際に運用している blog-agents（5つのサブエージェントで記事を自動生成するシステム）の設定を実例として使いながら、各エージェントの権限がどんな判断で決まったかを解説する。
「機能を知っている」と「何をAllowにするか」は別の問題
Claude Code の権限機能は3種類に整理できる。permissions の Allow / Deny / Ask、Auto Mode の動的分類器、Hooks による PreToolUse 判定 だ。これらの仕組みを知った上で、なお困るのが「で、うちのケースはどれを使えばいいのか」という問いだ。
「Bash コマンドの実行は Ask にする」という判断は理解できる。でも「コードフォーマットを自動実行するのはいいが、git push はまずい。では git commit は？」という粒度の判断が積み重なるうちに、設定ファイルが複雑になっていく。
問題は権限の機能ではなく、その操作を何の水準で扱うかの判断基準がないことだ。
「任せる / 確認する / 拒否する」の3段階
筆者が使っている意思決定フレームは、操作を3段階に振り分けることだ。
| 段階 | 意味 | Claude Code での対応 | 典型例 |
|---|---|---|---|
| 任せる | 自動実行、結果だけ確認 | Allow / Auto Mode | ファイル読み取り、テスト実行、コードフォーマット |
| 確認する | 実行前に承認 | Ask（デフォルト） | ファイル書き込み、Bash実行、git commit |
| 拒否する | 一切実行しない | Deny / hard_deny | 本番DB書き込み、rm -rf、秘密鍵の書き出し |
この3分類を設ける理由は、「全部任せる」と「全部確認する」という二択では必ず破綻するからだ。
「全部確認する」設定で運用を始めると、1日に数十回、場合によっては100回近い承認プロンプトが出る。しばらくするとほとんどのプロンプトを確認せずに「はい」と押すようになる。承認の形式だけが残り、実質ゼロ査定になる。
「全部任せる（dangerously-skip-permissions）」は逆のリスクで、意図しないファイル削除やコマンド実行に気づかないまま進む。監査ログも残らない。
3段階に分けることで「重要な確認だけに集中できる」状態を設計できる。
信頼度を決める3つの問い
何を「任せる」に置き、何を「確認する」に置き、何を「拒否する」にするかは、次の3つを問えば決まる。
失敗したときの被害は取り戻せるか
不可逆な被害が起きる操作は「拒否する」か「確認する」に置く。データが消えた、秘密鍵が漏れた、本番サーバーに不正コマンドが走った。そういう事態は取り返しがつかない。反対に、ファイル編集や git 未 push の変更は git revert で戻せる。可逆性が「任せる」の基準になる。
確認ボタンを押すコストはどのくらいか
毎回の確認を求める操作は、その頻度が高いほど「承認疲れ」を生む。1日50回以上出る操作なら、Ask より Allow の設定を真剣に検討した方がいい。承認疲れは「大切な確認を流す」リスクを高める。Auto Mode はこの判断を動的に処理する仕組みで、「常に Ask」と「常に Allow」の中間地点として機能する。
AIの判断がどの範囲で完結するか
「コードベース全体の文脈を読まないと正しく判断できない」操作は、AI の判断精度が不安定になりやすい。単一ファイルの中で完結するコードフォーマット、既存テストの実行、ファイルの読み取りは「任せる」に置きやすい。複数ファイルをまたいだリファクタリングや、依存関係のある設定変更は「確認する」に置く判断が合理的だ。
blog-agents の5エージェントに見る権限の設計
実際の権限設計を見た方がわかりやすいので、筆者の blog-agents を題材にする。このシステムは「researcher → writer → tone-checker → plagiarism → audit」という5つのサブエージェントが直列で動き、テーマを与えると記事が生成されてWordPressに投稿される。
各エージェントの allowed-tools は次のように設定している。
researcher
allowed-tools: Read, Write, Glob, Grep, WebSearch, WebFetch, Skillネット検索と research/ ディレクトリへの書き込みが主な仕事なので、WebSearch / WebFetch / Write が必要だ。Edit は不要。一度書いたリサーチファイルを自分で書き直す設計にはしていないため。
writer
allowed-tools: Read, Write, Edit, Glob, Grep, Skill記事を書くだけなので Bash も WebFetch も必要ない。WebFetch を外しているのは、リサーチ段階で得た情報だけをもとに書く役割だからで、writer が独自にネット検索し始める設計は意図していない。
tone-checker
allowed-tools: Read, Edit, Glob, Grep, Skill既存の記事ファイルを修正する役割なので、Write（新規作成）は不要。Edit だけで十分だ。最小権限の原則をそのまま実装している。
plagiarism
allowed-tools: Read, Edit, Glob, Grep, WebSearch, WebFetch出典の一次確認が仕事なので WebSearch / WebFetch は必須。Bash は不要。記事の盗作チェックにコマンド実行は関係ない。
audit
allowed-tools: Read, Write, Edit, Bash, Glob, Grep, Skillこのシステムの中で Bash が許可されている唯一のエージェントだ。WordPress REST API への投稿（curl / Python 実行）と、articles/drafts/ から articles/published/ へのファイル移動（mv）が必要なため。
5つを並べると「Bash を持つかどうか」が信頼度の明確な区切りになっている。audit が唯一 Bash を持つのは「公開ボタンを押す」最後の責任を担う役割だからで、それ以外のエージェントはローカルファイルの読み書きの範囲に収めている。役割と権限の範囲が対応している。
Skill の allowed-tools 設計については別記事で詳しく扱っているので参考にしてほしい。
3段階を実装する機能の組み合わせ
意思決定フレームを実際の設定に落とすには、3つの機能を使い分ける。
permissions の allow / ask / deny は操作の種類を静的に振り分ける基本設定だ。settings.json に直接書くか、Managed Settings で組織全体に配布するかを選べる。
Auto Mode は「常に Allow」と「常に Ask」の中間として動的分類器を動かす設定だ。「予期しない外部通信」「不可逆な破壊的操作」を危険パターンとして検知し、それ以外は自動実行する。細かい操作レベルで Ask/Allow を設定しきれないときに有効で、全体の承認回数を減らしながら重要な確認を維持できる。
PreToolUse Hooks は「機能では表現しきれないパターン」を補う。たとえば git push --force origin main は Bash コマンドの一種だが、これだけを deny にしたい場合は Hooks で command の内容をチェックする hook を書く。Hooks の実例については別記事に詳しい。
3つを階層的に使うことで、「任せる / 確認する / 拒否する」のほとんどのケースを実装できる。
EMの委任構造と同じ問題を解いている
AIへの権限設計に頭を使うとき、エンジニアリングマネジメントの委任問題と同じ構造をたどっていることに気づく。
EMがメンバーに仕事を委任するとき、誰に何を任せるかの判断には「この人の判断精度はどの範囲で信頼できるか」という問いがある。ジュニアエンジニアには細かく確認しながら進める仕事を渡し、シニアには「やっておいて」と完全委任できる仕事を渡す。委任の水準は役割と実績によって決まる。
Claude Code の権限設計も同じ問いを解いている。「このエージェントがこの操作を行うとき、どのくらいの頻度で判断を信頼できるか」——その答えに応じて Allow / Ask / Deny を設定する。
ただし人への委任と違うのは、AIへの委任は「役割を設計する側」が明示的に権限の境界を書かなければならない点だ。人は文脈を読んで「これは確認した方がいい」と自己判断するが、AIは設定された境界の通りに動く。設計の責任は人間にある。
権限設計を「Claude に何を任せるか」という意思決定として捉えると、機能の使い方よりも先に解くべき問いが見えてくる。その答えが出た後、permissions / Auto Mode / Hooks の設定は自然に決まる。
まとめ
Claude Code の権限設計で迷うのは、機能を知らないからではなく、「何をどの水準で扱うか」の判断基準がないからだ。
「任せる / 確認する / 拒否する」の振り分けに迷ったとき、私はいつも同じ問いに戻る。失敗が不可逆かどうか。確認の頻度が承認疲れを生んでいないか。AIの判断がどの範囲で完結するか。この3問を順に当てはめると、たいていの操作の置き場所は決まる。
手元のプロジェクトで「1日10回以上 Ask が出る操作」を一つ探してほしい。それを Allow に移してよいか、上の問いで判断してみる。権限設計の見直しはそこから十分だ。
コメント