Claude Codeのセキュリティ設定｜denyで機密ファイルを守る手順

Claude Codeのセキュリティ設定は、settings.json の permissions.deny に Read(./.env) のような拒否ルールを書くことから始めます。機密ファイルを読ませない、危険なコマンドを止める、bypassPermissions を使えなくする、という3つはどれも permissions の中で書け、書いたルールとその出所は /permissions で一覧できます。ただし拒否ルールはClaude Codeが認識できる操作にしか効かないため、確実に止めたい適用範囲はOSレベルのサンドボックスと組み合わせます。以下、書き方と、公式が明記している「効かない範囲」を順に整理します。

Claude Codeのセキュリティ設定はどのファイルに書くのか

公式ドキュメントでは、設定ファイルは次の4種類に分かれています。セキュリティ設定をどこに書くかで、誰に効くかが変わります。

スコープ	ファイル	効く範囲
User	~/.claude/settings.json	自分の、この端末のすべてのプロジェクト
Shared project	.claude/settings.json	そのフォルダで作業する全員（Gitにコミットした場合）
Project local	.claude/settings.local.json	自分の、このプロジェクトだけ
Managed	managed-settings.json など	組織が配布した全員

同じキーが複数のファイルにあるときの設定優先順位は、上から順に「Managed、コマンドラインの --settings、Project local、Shared project、User」です。

ただし権限については、この順番より次の性質が効きます。permissions.allow のようなリストはファイル間で結合され、どの層で拒否されたツールも他の層では許可できません。ユーザー設定の deny はプロジェクト設定の allow を止め、その逆も同じです。拒否は足し算で強くなり、許可で穴は開けられない、と覚えておけば十分です。各ファイルの全体像はsettings.jsonの全体像を扱った記事にまとめています。

また公式は、権限ルールは「モデルではなくClaude Codeが強制する」と明記しています。CLAUDE.md に「.envは読まないで」と書いても許可の範囲は変わらないので、止めたいものはルールで書きます。

.envや鍵ファイルを読ませないdenyルールの書き方

公式の設定リファレンスには、次の例がそのまま載っています。.env と .env.*、secrets ディレクトリ、認証情報ファイルの読み取りを拒否し、curl も止める設定です。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Bash(curl *)"
    ]
  }
}

この Read の拒否ルールは、読み取りを止めるだけではありません。公式によると、一致したファイルはファイル探索や検索結果からも外され、同じパスへの Edit と Write（新規作成を含む）もブロックされます。

書くときに迷いやすい点が4つあります。

1. .claudeignore は効かない。 公式は「効果がない」とし、中身を Read の拒否ルールへ移すよう案内しています。

2. NotebookEdit は Read の拒否で止まらない。 変更させたくないパスには Edit の拒否ルールも足します。また Write(...) や Glob(...) の形のパスルールは参照されないため、Edit(path) と Read(path) で書きます。

3. 先頭のスラッシュの意味が直感と違う。 パスの書き方は4種類あります。

書き方	意味	例
//path	ファイルシステムのルートから	Read(//**/.env)
~/path	ホームディレクトリから	Read(~/.zshrc)
/path	設定ファイルの置き場所を基準にした相対	Edit(/src/**/*.ts)
path または ./path	カレントディレクトリからの相対	Read(*.env)

ユーザー設定に Read(/secrets/**) と書くと、プロジェクトの secrets ではなく ~/.claude/secrets/** を指します。全プロジェクトに効かせる拒否ルールは // か ~/ で始めます。なお Read(.env) のようなファイル名だけのルールは、配下のどの深さの .env にも一致します。

4. ! の例外は同じファイルの中だけ。 deny に Read(*.env) に続けて Read(!sample.env) を書けば sample.env だけを除外できますが、他のファイルの拒否は打ち消せません。

denyルールが届かない範囲はどこか

公式は、Read と Edit の拒否ルールが効く範囲を次のように限定しています。

• 効く: Claudeの組み込みファイルツール、Bash内の cat head tail sed tee のようにClaude Codeが認識するファイル操作コマンド、> file のようなリダイレクト先
• 効かない: ファイル名を指定せずに読むコマンド（そのファイルがあるディレクトリで実行する grep -r pattern . など）、PythonやNodeのスクリプトが自分でファイルを開く場合

セキュリティ設定のBashのルールにも同じ性質があります。Bash(curl *) を deny に入れても、/usr/bin/curl https://example.com や sh -c 'curl https://example.com' には一致しません。公式はこうしたルールを、Claudeが普段書く形を止めるもので「セキュリティ境界ではない」と位置づけています。

確実に止めたい範囲は、OSが強制するサンドボックスで囲みます。

• サンドボックスは既定でオフ。セッション内で /sandbox を実行するか、設定ファイルで sandbox.enabled を true にすると有効になる
• macOSは組み込みのSeatbeltを使う。LinuxとWSL2は bubblewrap と socat が必要。ネイティブのWindowsではサンドボックスなしで動くため、WSL2の中で使う
• 囲むのはシェルコマンドだけで、ファイルツール、MCPサーバー、フックは外で動く。既定の読み取り範囲には ~/.ssh や ~/.aws/credentials も含まれる

ファイルツールは権限ルール、シェルコマンドはサンドボックス、という分担です。公式も、プロンプトインジェクションで判断がすり抜けられてもサンドボックスの制限は残るとして、併用を勧めています。設定の詳細はサンドボックス設定の記事、コンテナでの隔離はDockerの記事を参照してください。

危険なコマンドを止めるallow・ask・denyの組み方

permissions には allow（確認なしで実行）、ask（確認を求める）、deny（実行しない）の3つのリストがあります。ただし bypassPermissions モードでは確認自体が省略され、allow も意味を持ちません。評価順は deny、ask、allow の順で、最初に一致したものが結果を決めます。ルールの具体性は順序を変えないため、Bash(aws *) を deny に入れると、より狭い Bash(aws s3 ls) を allow に書いても通りません。

公式の例は、npmスクリプトとgit commitは確認なしで通し、git push で始まるコマンドは拒否する構成です。

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

ただし git -C . push のような別の書き方の push は、このルールに一致しません。allow を書くときの規則は次のとおりです。

• * はサブコマンドの後に置く。Bash(git log *) は git log だけを許可するが、Bash(git *) はすべてのgitコマンドを許可する
• && や | でつないだ複合コマンドは、サブコマンドごとに照合される。Bash(safe-cmd *) を許可しても safe-cmd && other-cmd は通らない。逆に deny と ask は、どれか1つのサブコマンドが一致すれば適用される
• npx や docker exec のような実行ランナーは剥がされない。Bash(devbox run *) は run の後のどんなコマンドにも一致するので、Bash(devbox run npm test) のように内側まで書く

MCPサーバーのツールは、1つなら mcp__<サーバー名>__<ツール名>、サーバー全体なら mcp__<サーバー名>__* で指定します。deny の mcp__* は全MCPツールを止めますが、allow に mcp__* と書いても警告付きで無視されます。MCPの仕組みはMCPの記事を参照してください。

bypassPermissionsを使わせないにはどうするか

bypassPermissions は確認をスキップするモードで、.git や .claude への書き込みも確認なしで通ります。公式は、インターネットにつながっていないコンテナやVMのような隔離環境だけで使うよう警告しています。

誤解されやすいのは、このモードでも deny は効く点です。公式は deny が bypassPermissions を含むどのモードでもブロックすると明記しており、拒否ルールはモードに関係なく残る歯止めになります。

このモード自体を使えなくするには、次のように書きます。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

設定すると --dangerously-skip-permissions フラグも拒否されます。管理設定に置くのが典型ですが、どのファイルからでも効くので、自分のユーザー設定に入れて自分を締め出すこともできます。

なお、プロジェクト設定やローカル設定の permissions.defaultMode に bypassPermissions を書いても効きません。モードごとの違いは権限モードの記事で扱っています。

他人のリポジトリを開くとき設定のどこを確認すべきか

プロジェクトの .claude/settings.json に書かれた permissions.allow と permissions.additionalDirectories は、そのフォルダのワークスペース信頼ダイアログを承認するまで適用されません。ダイアログには付与されるルールとディレクトリが表示されるので、承認前に確認できます。deny と ask は信頼の前から効きます。

注意が要るのは claude -p やSDKの実行です。信頼ダイアログが出ず、設定ファイル内のフック、env ブロック、apiKeyHelper のようなヘルパーは、信頼していないフォルダでも使われます。自分が書いていないリポジトリで実行する前の対策として、公式は次を挙げています。

• --setting-sources user を付けて、プロジェクトの設定ファイルと .mcp.json を読まない
• --settings '{"disableAllHooks": true}' を付けて、その実行だけフックを止める。ユーザー設定に書くだけでは、優先度の高いプロジェクト設定に false へ戻されうる

共有設定の allow ルールが仲間の環境で効かないのも、この仕組みです。各メンバーが信頼するまで確認が出続けます。

設定が効いているかどう確認するか

書いたルールが効いているかは、次の順で確かめます。

1. セッション内で /permissions を開く。すべての権限ルールと、各ルールがどの settings.json から来たかが一覧で出る
2. /status を開き、Statusタブの Setting sources 行で、どの設定ファイルが読み込まれたかを見る
3. 一覧に出ないルールがあれば、ターミナルで claude doctor を実行する。セッションを起動せずに、読み取り専用で設定診断の結果を表示する

permissions の編集は、設定ファイルの監視により再起動なしで実行中のセッションへの設定反映が行われます。

うまくいかないときは、次の2つをまず疑います。

• ルールの書式が間違っている: 個々のルールが不正なら「Settings Warning」としてそのルールだけが読み飛ばされ、ファイルの残りは有効のまま。claude doctor で確認する
• 「今後確認しない」を選んだのに毎回聞かれる: BashコマンドやWebFetchのドメインのように承認が永続保存される場合、その選択は .claude/settings.local.json に allow として保存されるが、プロジェクトや管理設定に同じ対象の ask ルールがあると ask が優先される

チーム全体に同じ制限を強制するには

セキュリティ設定で組織として外せない制限には管理設定（managed settings）を使います。管理設定はユーザー設定やプロジェクト設定から上書きできず、その deny は --allowedTools でも外せません。allowManagedPermissionRulesOnly を使えば、権限ルールの出どころを管理設定だけに絞れます。

逆向きの例外もあります。permissions.blockReadsOutsideWorkingDirectories（v2.1.257以降）は、true にするとどのモードでも作業ディレクトリ外の読み取りをファイルツールが拒否するキーで、管理設定が false でも、どの層の true も尊重されます。

管理設定の配布方法や何を強制すべきかの判断は企業向けのセキュリティガイドに、個人利用で何が危ないかの整理は個人向けのセキュリティリスクの記事にまとめています。

設定を終えたら何を確認しておくか

• 機密ファイルを Read(...) で拒否し、変更も禁じたいパスには Edit(...) も足した。ユーザー設定では ~/ か // で始めた
• 危険なコマンドを deny か ask に入れ、allow の * はサブコマンドの後に置いた
• 拒否ルールが届かないシェル経由の操作を、サンドボックスで囲むか判断した
• disableBypassPermissionsMode を設定するか決めた
• /permissions でルールと出所を、/status で読み込まれた設定ファイルを、claude doctor で不正な設定がないかを確かめた

本文で触れたキーのうち permissions.blockReadsOutsideWorkingDirectories はv2.1.257以降が必要です。対応バージョンは公式の設定リファレンスの該当キーに記載されています。

Claude Codeの設定や運用を継続して学びたい場合は、月額1,980円から参加できる学習コミュニティ「AI駆動ラボ」もあります。