パーミッションモデルとセキュリティ

学ぶこと

Claude Code のセキュリティは一つのスイッチではありません。次の制御を組み合わせます。

1. セッションの基準を設定する権限モード
2. 特定のツール呼び出しに対する allow、ask、deny ルール
3. 保護パスと組織ポリシー
4. Bash と子プロセスに対する任意の OS レベル sandbox
5. ツール実行の前後に決定的なチェックを行う hooks

このセッションでは、特に Auto モードと権限 bypass の違いを理解し、制御を意図的に選ぶことに集中します。

権限モード

UI ラベル	設定値	通常の承認なしで実行	用途
Manual	default（manual エイリアス）	読み取り	機密性の高い、または不慣れな作業
Edit automatically	acceptEdits	読み取り、ファイル編集、一般的なファイル操作	レビュー済みのローカル反復
Plan	plan	読み取りと読み取り専用の調査	実装前の設計
Auto	auto	バックグラウンド安全チェックを通過した操作	信頼できる方向性、少ない中断
Don’t ask	dontAsk	事前承認済み操作と組み込み読み取り専用操作	制限された CI と scripts
Bypass permissions	bypassPermissions	ほぼすべて	分離されたコンテナと VM のみ

Manual / default

Manual は現在の UI ラベルで、default は settings、hooks、SDK 統合で使われる設定値です。v2.1.200 以降、CLI では manual エイリアスも使えます。

作業ディレクトリ内の読み取りは通常そのまま実行され、ファイル編集と読み取り専用ではない Bash コマンドは通常確認されます。ユーザーが副作用を確認できるため、最も安全な汎用の開始点です。

claude --permission-mode default
# v2.1.200+
claude --permission-mode manual

Plan / plan

Plan モードは読み取り専用の調査と設計に使います。Claude はファイルを読み、組み込みの読み取り専用 shell コマンドを使えますが、ソースファイルを編集しません。読み取り専用ではない shell コマンドは計画中でも確認されます。

claude --permission-mode plan

Plan モードは「すべての読み取りを承認する」という意味ではありません。実装前のチェックポイントを作り、計画をレビューする、改善を続ける、承認して実行モードを選ぶ、という選択ができます。

Auto / auto

Auto モードは通常の権限プロンプトを減らしますが、バックグラウンド安全チェックを残します。明示的なルールや安全なローカル操作で決まらないものは、別の分類器が評価します。deny と ask ルールは適用され続け、要求を超える操作、未知のインフラを対象にする操作、悪意あるコンテンツに誘導されたように見える操作はブロックされる場合があります。

claude --permission-mode auto

Auto モードは確認疲れを減らしますが、安全を保証せず、機密性の高い操作のレビューに代わるものではありません。利用可否はアカウント、モデル、provider、組織設定に依存します。

Don’t ask / dontAsk

dontAsk は権限入力を待ちません。通常なら確認する呼び出しは拒否されます。事前承認済み操作、組み込み読み取り専用 Bash コマンド、適用可能な hook が承認した呼び出しだけを実行します。

claude --permission-mode dontAsk

人間の入力を待つと停止してしまい、許可範囲が事前定義された CI や scripts に適しています。

Bypass permissions / bypassPermissions

Bypass モードは通常の権限プロンプトと安全チェックを飛ばします。重要な認証情報がなく、host や production systems に損害を与えられない、分離されたコンテナまたは VM でのみ使ってください。

claude --permission-mode bypassPermissions
# 同等の従来フラグ：
claude --dangerously-skip-permissions

dangerous フラグは Auto モードではありません。一部の circuit breaker や外部から必須とされた consent プロンプトは残りますが、bypass モードには prompt injection や意図しない操作に対する一般的な保護がありません。

ルール：Deny、Ask、Allow の順

ルールは permissions.allow、permissions.ask、permissions.deny に置きます。

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(npm test *)",
      "Read(/docs/**)",
      "WebFetch(domain:docs.example.com)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(~/.ssh/**)",
      "WebFetch(domain:paste.example)"
    ]
  }
}

ルールは Tool または Tool(specifier) 構文を使い、deny → ask → allow の順で評価されます。詳細度はこの順序を変えません。Bash(aws *) が deny されていれば、より狭い Bash(aws s3 ls) の allow で通すことはできません。

/permissions で有効なルールを確認・編集できます。allow pattern は狭く保ち、Bash 全体より Bash(npm test *) を選びます。

権限と Sandbox は別の制御

権限は Claude Code がツールを呼び出せるかを決めます。Sandbox は有効にした場合、Bash コマンドとその子プロセスに OS レベルのファイルシステム・ネットワーク境界を適用します。

モデルが Bash コマンドを提案
        ↓
権限モード + ルール + hooks
        ↓ 許可
任意の OS sandbox 境界
        ↓
OS が副作用を実行またはブロック

Sandbox は権限モードと自動的に同一になるものではなく、別に設定します。また、一つの権限ルールだけで任意の Python や Node 子プロセスによるファイル読み取りを止められると考えてはいけません。脅威モデルに信頼できないコードや prompt injection が含まれる場合は両方の層を使います。

Sandbox がコマンドを自動許可する場合でも、明示的な deny ルールは適用されます。保護パスも bypass 以外の各モードで特別に扱われます。bypass では保護パスのチェックの大部分が省略されます。

Hooks と組織ポリシー

PreToolUse hook は実行予定の操作を調べ、実行前にブロックできます。production target の拒否や承認済みコマンド wrapper の強制など、決定的な要件に適しています。Hooks は権限ルールを補完しますが、一致する deny や ask を上書きしません。

組織はユーザーやプロジェクトが上書きできない managed settings を配布できます。どの設定スコープからの deny も優先されるため、プロジェクトの allow で組織の deny を上書きできません。

モードの選び方

編集前に理解する必要がある？          → plan
各副作用を確認したい？                → default / Manual
ローカル編集は信頼し、コマンドは確認？ → acceptEdits
安全チェックを残して確認を減らす？     → auto
allowlist 型の非対話 CI が必要？       → dontAsk
完全に分離された使い捨て環境？         → bypassPermissions

永続的な人間のチェックポイントには ask または deny ルールを使います。「push しないで」という会話上の指示は Auto の分類器に役立ちますが、コンテキスト圧縮で失われる可能性があります。権限ルールの方が強い境界です。

セキュリティチェックリスト

• ワークフローを進められる最小権限モードから始める。
• 自律環境から secrets と production credentials を除外する。
• 狭い allow pattern を使い、公開・デプロイには明示的な ask を追加する。
• 絶対に触れてはいけないパスとコマンドに deny を追加する。
• 信頼できないコードを実行するときは sandbox を有効にする。
• MCP servers、取得したコンテンツ、repository instructions を prompt-injection の可能性がある入力として扱う。
• Claude の完了宣言だけでなく、tests、diff、deployment state など実際の効果を検証する。

公式ソース

• 権限モードの選択
• 権限の設定
• Sandboxing
• Hooks リファレンス

最終確認：2026-07-20。