Claude Codeのセキュリティは、操作を通すか決める「権限」、OS側でファイルや通信を制限する「sandbox」、読ませる資料や外部連携の「入力とデータ」の3つに分けると整理できます。作業フォルダを指定しただけでは、承認したBashコマンドのアクセス先をOSレベルで制限したことにはなりません。
操作と利用条件は公式資料をもとに説明しています。2026年11月5日確認。
Claude Codeのセキュリティで確認する3つの境界
Anthropicの公式セキュリティ文書は、権限による承認とsandboxによる隔離を分けて説明しています。業務で使う前に、何を守りたいかと、どの仕組みで制限するかを対応させます。
| 確認するもの | 役割 | 判断すること |
|---|---|---|
| 権限モード・許可ルール | 操作を自動で通すか、人へ確認するか、拒否するか | 誰が、どの操作まで任せるか |
| sandbox | Bashのファイルアクセス・ネットワークをOS側で制限 | 触れてよい場所と通信先はどこか |
| 外部入力・連携先のデータ | 読ませる資料の信頼性と情報の行き先を管理 | 資料内の指示を依頼として扱っていないか、外へ何を出すか |
例えば、資料の要約だけを任せる仕事と、コードの変更・テストを任せる仕事では、必要な操作が違います。最初に成果物と対象フォルダを決め、その仕事に必要な権限を当てはめます。許可を増やすことを出発点にしない方が、後から見直す理由も明確になります。
Claude Codeの権限とsandboxは役割が違う
Manual modeでは、読み取りから始め、編集やコマンド実行時に人が承認を判断します。Auto modeでは別の分類モデルが操作を審査しますが、明示したask・denyルールも適用されます。自分のセッションがどのモードで動いているかを、許可ルールと合わせて確認します。
Manual modeでの作業ディレクトリの境界は、ファイルツールが範囲外へ触れる際の確認です。承認したBashは、そのOSユーザーが書き込める場所へ書けます。コマンドが実際に触れるファイルや通信先を制限したい場合は、sandboxの設定を別に見ます。
画像を拡大 ↗ファイルとネットワークの境界を分ける、Claude Codeのサンドボックス構成図。
出典：Anthropic ↗この画像の見方
ファイルへのアクセスとネットワーク通信をそれぞれ制限する考え方を示しています。出典は2025年10月の公式解説です。
ルールの書き方と評価順は、Claude Codeの権限設定で説明しています。機密情報を外へ出さない設定の具体例は、情報漏洩対策の設定例と編集部の検証へ進めます。
Claude Codeの権限修正から分かる確認ポイント
2026年7月18日のv2.1.214では、許可の対象を広く解釈していた判定などが修正されました。過去の不具合を見ると、同じコマンド名でもパスやシェルの違いを確かめる理由が分かります。
| 対象 | 当時の問題・修正内容 | 自分の環境で確認する点 |
|---|---|---|
Edit(src/**)などの許可ルール | 入れ子の同名ディレクトリまで許可される問題を修正し、作業ディレクトリ基準の範囲に限定 | どのsrcを許可する意図だったか |
| Windows PowerShell 5.1 | 該当するコマンド経路で権限チェックを回避できる問題を修正 | 使用しているシェルと版 |
| Bashのファイルディスクリプタ・リダイレクト | 権限解析と実行時の解釈が食い違う場合、許可せず止める方向に修正 | 許可ルールと実際のコマンド形式 |
| 10,000文字を超えるBashコマンド | 確認プロンプトを出すように修正 | 長いBashコマンドを自動生成する手順があるか |
| Bash権限チェックで扱うzshの添字・修飾子 | 特殊な変数表記を単純な文字列と見なしていた解析を修正 | zshを使う自動処理があるか |
| Bash権限チェックで扱うhelp・manの呼び出し | 危険なオプションや置換を伴う場合の自動承認を修正 | コマンド名だけで安全と判断していないか |
| リモートセッション | ローカルでの確認前に処理が進む競合を修正 | 確認画面と処理の順序 |
変更表の出典：Claude Code公式リリース、v2.1.214。
とくにWindowsの記述は、PowerShell 5.1の該当経路についてのものです。「Windowsでは権限チェックがすべて機能していなかった」と広げて読むと、必要な調査範囲を誤ります。
Claude Codeのhookと権限ルールを分けて読む
hookは、操作の前後などに決めた処理を実行する仕組みです。v2.1.214では、hookのif:条件にある単一セグメントのdir/**の一致範囲が、作業ディレクトリ直下のdirへ変わりました。任意の階層を対象にする意図なら、**/dir/**を使います。
| 設定の種類 | 7月の変更履歴に記載された扱い | 見直し方 |
|---|---|---|
hookのif:にあるdir/** | 作業ディレクトリ直下のdirに一致 | 下位階層も対象なら、意図を確認して**/dir/**を検討 |
allowのEdit(src/**)等 | 意図しない入れ子の同名フォルダへの許可を修正 | 許可範囲が広がらないよう実際の対象を確認 |
deny・askのdir/** | このリリースでは従来の任意階層への一致を維持 | hookの移行と同じ理由で一括置換しない |
たとえば直下のsrc/だけを許可する設計なら、src/example.txtは許可範囲、nested/src/example.txtとother/example.txtは範囲外です。実際の結果が拒否か確認になるかは、現在のモードと他のルールにもよります。「hookが発火したか」「確認が出たか」「実ファイルが変わったか」を3列に分けて残すと、どの仕組みが効いたかを切り分けられます。既存のask・denyを機械的に書き換える試験にはしません。
同名のフォルダを置いた確認例
テスト専用フォルダで、次のように同じ名前のディレクトリを2か所に置くと、対象の違いを確認できます。中身は無害なサンプルファイルだけにしてください。
permission-check/
src/example.txt
nested/src/example.txt
other/example.txt作業ディレクトリをpermission-checkにしたとき、直下のsrcとnested/srcを分けて扱えるかを見ます。確認対象がhookの発火なのか、編集の許可なのかも分けて記録します。hookが発火したことだけで、権限ルールが意図どおりだとは判断しません。
Claude Codeのセキュリティを確かめるチェック項目
更新や設定変更の後は、許可したい操作と止めたい操作を対で確認します。編集部が勧める確認表は次のとおりです。実データの代わりに、テスト用のファイルを使って記録します。
| 項目 | 確認する内容 | 残す記録 |
|---|---|---|
| 実行環境 | 使用版、OS、シェル、CLI・IDEなどの利用画面 | どの環境で確かめたか |
| 許可した操作 | 対象ファイルだけを読める・変更できるか | パス、適用ルール、実際の差分 |
| 範囲外の操作 | 確認または拒否が期待どおりか | 表示と、範囲外のファイルが変わっていないこと |
| hook | 対象操作で発火し、失敗時に想定した扱いになるか | 発火記録、終了状態、操作の続行可否 |
| 外部連携 | 通信先・送る内容・接続アカウントが目的に合うか | 連携先、送信対象、結果 |
設定が効かない場合は、まず実際に読み込まれた設定と対象パスを調べます。「操作が通った」という結果だけでは、意図した許可ルールで通ったのか、別の広い許可で通ったのかが分かりません。逆に、確認画面が出ただけで終わらせず、拒否した後のファイルも確認します。
外部資料の指示と、依頼者の指示を混同しない
Webページやリポジトリ内の文章には、AIへ別の操作をさせようとする指示が含まれることがあります。プロンプトインジェクションへの対策では、外部資料を調査対象として扱い、そこに書かれた命令だけで権限や送信先を変えない運用が必要です。
権限の確認、sandbox、入力の扱いを組み合わせて、誤った指示が実行へ進む範囲を狭めます。あわせて、ログに何を残すか、成果物を誰が確認するか、問題が起きたときにどの作業を止めるかを決めます。データ保存や学習の条件は契約・管理設定の論点なので、操作の許可とは分けて確認してください。
Claude Codeのセキュリティでよくある質問
セキュリティ更新だけで、設定の確認は省けますか？
更新は製品の修正、設定は自分の環境で許可する範囲を決めるものです。この記事の7月の修正は具体例として残しています。導入時は現在の公式変更履歴と組織の更新方針に沿って版を選び、対象の操作を確認します。
dir/**をすべて**/dir/**に置き換えますか？
hook・allow・ask・denyは設定の意味と変更履歴が異なります。対象フォルダを確認し、それぞれの意図に合う範囲へ設定します。
コードレビューは権限チェックも代わりに行いますか？
コードの不具合を探すレビューと、エージェントが実行できる範囲の確認は別です。コードの修正と再確認に加え、実際の権限ルールも確認します。
