Claude Code権限管理

問題: Claude Codeがすべてのファイル編集とコマンドで権限を要求してくることは、作業の流れを断ち切り、時間を無駄にする。

すぐできる改善策: Shift+Tabを押して権限モードをその場で切り替える:

# Shift+Tabを押して切り替え:
normal → auto-accept edits → plan mode → normal

Shift+Tabがターミナルと競合する場合は再バインドできる。これで設定ファイルに触れることなくフローをコントロールできる。モードをタスクに合わせれば、割り込みのサイクルが止まる。

すべての権限モード

Claude Codeには5つの権限モードが搭載されており、それぞれ異なる種類の作業向けに設計されている。3つのコアモードはShift+Tabでサイクルし、残り2つは設定に存在する。

通常モード（`default`）

通常モードは潜在的に危険な操作の前にプロンプトを表示する。確認ダイアログが表示されるのは以下の場合だ:

ファイルの編集と変更
ターミナルコマンドの実行
システム操作
ディレクトリの変更

速度よりもセキュリティ。以下の場合に使う:

本番コード
よく知らないコードベース
新しい技術を学ぶとき
高リスクな操作

自動承認モード（`acceptEdits`）

自動承認モードはセッションの残りの間、ファイル編集の権限プロンプトを省略する。Claude は承認済みの操作を直接実行する。

Shift+Tabを押してUIが「auto-accept edit on」と表示されるまで切り替えてオンにする。

最適な用途:

大規模なリファクタリングセッション
明確に定義されたプランに沿って作業するとき
調査とドキュメント作業
多くのファイルにわたる繰り返しの編集

プランモード（`plan`）

プランモードはClaude を読み取り専用操作にロックする。Claude は自由に分析できるが、ディスク上の何も変更されない。

以下に最適:

最初のコードベース探索
アーキテクチャ分析
複雑な機能の計画
コードレビューセッション

確認なしモード（`dontAsk`）

確認なしモードは/permissionsまたはpermissions.allowルールを通じてツールが既に事前承認されていない限り、あらゆるツール使用を自動拒否する。プロンプトなし。許可リストにないものはすべて静かに拒否される。

最適な用途:

人が確認するために周りにいないCI/CDパイプライン
既知の許可操作セットを持つロックダウン環境
厳格な事前構築された権限ポリシーに対してClaude を実行する場合

権限バイパスモード（`bypassPermissions`）

バイパスモードはすべての権限チェックをスキップする。Claude はプロンプトなしで任意のツールを実行する。

# CLIフラグの同等物:
claude --dangerously-skip-permissions

コンテナ、VM、またはClaude が永続的なダメージを与えられないエフェメラルなCIランナーのような完全に分離された環境の中でのみこれをオンにする。このモードの目的は、環境自体が安全境界となる場所での自動化だ。

警告: 管理者はマネージド設定のdisableBypassPermissionsModeを"disable"に設定することでこのモードを完全にオフにできる。組織がブロックしている場合、設定もCLIフラグも機能しない。

永続的なデフォルトモードの設定

セッションごとにモードをサイクルする代わりに、settings.jsonで好みのデフォルトを固定する:

{
  "defaultMode": "acceptEdits"
}

有効な値: default、acceptEdits、plan、dontAsk、bypassPermissions。この設定はセッションをまたいで維持されるので、常に望む場所から始められる。

/permissionsによる権限管理

JSONファイルを手動で編集する代わりに、組み込みの/permissionsコマンドがインタラクティブビューを開く:

# インタラクティブな権限UIを起動
/permissions

そこからできること:

現在どのツールが許可・拒否されているかを確認
特定のツールやパターンへのアクセスを付与
オフリミットにしたいツールをブロック
各ルールがどの設定ファイルから来ているかを確認
Claude Codeを再起動せずに変更を加える

権限ルールの構文

ルールはToolまたはTool(specifier)の形式に従う。これらはsettings.jsonのpermissionsオブジェクト内に存在する:

{
  "permissions": {
    "allow": ["Bash(npm run *)"],
    "deny": ["Bash(rm *)"],
    "ask": ["Bash(git push *)"]
  }
}

3つのルールタイプが動作を決める:

AllowルールはClaude が確認なしにツールを実行できるようにする
Askルールは使用するたびに確認を求める
Denyルールはツールを完全にブロックする

ルールは順番に評価される: 最初にdeny、次にask、次にallow。最初に一致したルールが優先されるので、denyは常にallowに勝つ。

ルール	効果
`Bash`	すべてのBashコマンドにマッチ
`WebFetch`	すべてのウェブフェッチリクエストにマッチ
`Read`	すべてのファイル読み取りにマッチ
`Edit`	すべてのファイル編集にマッチ

Bashワイルドカードパターン

Bashルールは*を使ったglobパターンを取る。ワイルドカードはルールのどこにでも置ける:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "Bash(git * main)",
      "Bash(* --version)",
      "Bash(* --help *)"
    ],
    "deny": ["Bash(git push *)"]
  }
}

単語境界のセマンティクス: *の前のスペースが重要だ。Bash(ls *)はls -laにマッチするがlsofにはマッチしない。Bash(ls*)は両方にマッチする。

シェルオペレーターの認識: Claude Codeはシェルオペレーターを認識する。Bash(safe-cmd *)のようなルールはsafe-cmd && malicious-cmdにはマッチしない。これによりチェーンコマンドの悪用が防がれる。

警告: コマンド引数を制限しようとするBashパターンは脆弱だ。Bash(curl http://github.com/ *)のようなルールはcurlをGitHub URLに限定しようとしているが、バリエーション（URLの前のオプション、異なるプロトコル、変数展開）をキャッチしない。本物のURLフィルタリングには、BashのネットワークツールをブロックしてドメインルールとともにWebFetchを使う。

ReadとEditのパターン

ReadとEditのルールはgitignoreスタイルのパスパターンを使い、4種類ある:

パターン	意味	例
`//path`	ファイルシステムルートからの絶対パス	`Read(//Users/alice/secrets/**)`
`~/path`	ホームディレクトリからのパス	`Read(~/Documents/*.pdf)`
`/path`	設定ファイルからの相対パス	`Edit(/src/*/.ts)`
`path`または`./path`	カレントディレクトリからの相対パス	`Read(*.env)`

重要: /Users/alice/fileのようなパターンは絶対パスではない。設定ファイルからの相対として解決される。真の絶対パスには//Users/alice/fileを使う。

gitignoreパターンでは、*は単一ディレクトリ内のファイルにマッチし、**は再帰的にマッチする。すべてのファイルアクセスを許可するには、括弧を完全に省略する: Read、Edit、またはWrite。

WebFetchドメインルール

Claude がフェッチできるドメインを制御する:

{
  "permissions": {
    "allow": ["WebFetch(domain:docs.anthropic.com)"],
    "deny": ["WebFetch(domain:internal.company.com)"]
  }
}

MCPツールパターン

サーバーまたはツールレベルでMCPサーバーアクセスを制御する:

ルール	効果
`mcp__puppeteer`	puppeteerサーバーの任意のツールにマッチ
`mcp__puppeteer__*`	上と同じ（ワイルドカード構文）
`mcp__puppeteer__puppeteer_navigate`	特定のnavigateツールのみにマッチ

タスク（サブエージェント）ルール

Task(AgentName)を使ってClaude が生成できるサブエージェントを制御する:

{
  "permissions": {
    "deny": ["Task(Explore)"]
  }
}

エージェント名にはExplore、Plan、Verifyが含まれる。--disallowedToolsCLIフラグも起動時に特定のエージェントを無効にできる。

フックによる権限の拡張

PreToolUseフックは権限システムの前に実行され、実行時にツール呼び出しを承認、拒否、または書き換えることができる。これにより静的なルールの上でプログラム的な制御が可能になる。

権限とサンドボックスの連携

権限とサンドボックスは2つの補完的なセキュリティレイヤーとして積み重なる（多層防御）:

権限はClaude が使えるツールとアクセスできるファイルまたはドメインを制御する。すべてのツール（Bash、Read、Edit、WebFetch、MCPなど）に適用される。
サンドボックスはその上にOSレベルの強制を追加し、Bashコマンドがファイルシステムとネットワークレベルで到達できる範囲を制限する。Bashコマンドとその子プロセスにのみ適用される。

最強の態勢のために両方を一緒に使う:

権限のdenyルールはClaude が制限されたリソースにアクセスしようとすること自体を阻止する
サンドボックスの制限は、プロンプトインジェクションがClaude の意思決定をバイパスしてもBashコマンドを定義された境界内に保つ
サンドボックスのファイルシステム制限はReadとEditのdenyルールを使う（個別のサンドボックス設定ではない）
ネットワーク制限はWebFetchの権限ルールとサンドボックスのallowedDomainsリストを組み合わせる

/sandboxコマンドでサンドボックスをオンにする。macOSではSeatbeltを使ってすぐに機能する。LinuxとWSL2では先にbubblewrapとsocatをインストールする。

マネージド権限設定

中央コントロールが必要な組織向けに、管理者はユーザーとプロジェクトが上書きできないマネージド設定ファイルを配布できる:

設定	効果
`allowManagedPermissionRulesOnly`	`true`のとき、マネージド設定の権限ルールのみが適用される。ユーザーとプロジェクトのルールは無視される。
`disableBypassPermissionsMode`	`"disable"`に設定すると`bypassPermissions`モードと`--dangerously-skip-permissions`CLIフラグがブロックされる。

マネージド設定ファイルの場所:

macOS: /Library/Application Support/ClaudeCode/managed-settings.json
Linux/WSL: /etc/claude-code/managed-settings.json
Windows: C:\Program Files\ClaudeCode\managed-settings.json

これらはシステム全体のパス（ユーザーホームディレクトリではない）で、管理者権限が必要だ。通常の設定ファイルと同じ形式を使うが、設定の階層で最高の優先度を持つ。

開発シナリオの戦略

初期開発（通常モードを使う）

新しいプロジェクトを始めるとき、または不慣れなコードを調べるとき:

すべての権限を手動で保つ
提案された変更をそれぞれレビューする
Claude がどのように問題に取り組むかを観察する
AIの判断に対する信頼を築く

アクティブな開発（自動承認を使う）

集中的なコーディングセッション中:

信頼できるファイルタイプに自動承認をオンにする
一般的なコマンド（npm、git status）を許可する
システム操作にはプロンプトを維持する
中断のないワークフローに乗る

コードレビュー（プランモードを使う）

既存のコードベースを分析しているとき:

安全のためにプランモードに切り替える
Claude がファイルに触れずに探索できるようにする
分析と推奨事項を作成する
実装する準備ができたときだけモードを切り替える

よくある権限の落とし穴

過剰な権限: 完全に分離されたコンテナまたはVMの中にいない限りbypassPermissionsモードは避ける。明示的なallowルールを持つdontAskモードがより安全な「ハンズオフ」オプションだ。

過少な権限: 100回目の「許可」クリックは目的を失わせる。繰り返し操作を事前承認するために/permissionsを使うか、アクティブな開発中はacceptEditsに切り替える。

モードの混乱: 作業を始める前に現在のモードを確認する。インジケーターはUIにある。常に同じ開始モードにしたい場合はsettings.jsonでdefaultModeを設定する。

包括的な権限: すべてのBashコマンドを許可しない。スコープを狭く保つためにBash(npm run *)のような特定のパターンを使う。そして覚えておく: denyルールは常にallowルールに勝つ。

脆弱な引数パターン: コマンド引数を制限するためにBashルールに頼らない（curlを特定のURLに固定するなど）。本物のURLフィルタリングにはWebFetchのドメインルールを使う。

次は何か

5つの種類の作業のための5つの権限モード。安全のためのdefault、生産性のためのacceptEdits、探索のためのplan、自動化のためのdontAsk、分離環境のためのbypassPermissions。タスクに合ったモードを選び、多層防御のためにサンドボックスを上に積み重ねる。

フックとPermission Hookで権限呼び出しを自動化する
より速いモード切り替えのためのカスタムキーバインディング
より速い反復のためのフィードバックループ
タスク追跡のためのTodoワークフロー
バージョン管理のためのGit統合
settings.jsonとより深いセットアップのための設定の基本