Claude

Claude Codeのセキュリティ設定|権限ルール・サンドボックス・管理設定で守る実装手順【2026年10月】

AIの活用によるセキュリティの向上

Claude Codeはファイルの読み書きとシェルコマンドの実行までこなすため、セキュリティ対策は「何を許すか」を設定で決める作業になります。公式ドキュメントが用意している防御は、権限ルール(permissions)、OSレベルのサンドボックス、組織が配る管理設定(managed settings)の3層です。この記事では2026年10月時点の最新版v2.1.288系の仕様をもとに、3層それぞれが止められるものと止められないもの、.envや~/.sshを守る設定、他人のリポジトリでclaude -pを動かすときの注意点、学習利用と保存期間のプラン差を、コピーして使える設定例つきで整理します。

まとめ:Claude Codeのセキュリティは権限・サンドボックス・管理設定の重ね掛けで固める

1つの仕組みだけでは穴が残ります。権限ルールのRead拒否はgrep -rやPythonスクリプト経由の読み取りを止められず、サンドボックスの読み取り拒否はClaude自身のReadツールを止めません。秘密情報は両方に書いて塞ぐのが基本です。

チームで使うなら、managed-settings.jsonでサンドボックスを必須にし、bypassPermissionsを無効化してください。他人のリポジトリをclaude -pで処理するCIでは、信頼確認が出ないままhooksや.mcp.jsonのサーバーが動くため、--bareか--setting-sources userで読み込みを絞ります。ソースコードを学習に使わせたくない場合は、Team・Enterprise・APIの商用契約で使うのが確実です。

Claude Codeを守る3層の仕組みと権限ルール・サンドボックスの守備範囲の違い

どの層が何を止めるのかを取り違えると、設定したつもりで素通しになります。

v2.1.288系で対話セッションの既定になったauto modeの承認範囲

Claude Codeのセキュリティ解説によると、ターミナルとVS Codeの対話セッションは、組み込みの既定ではauto modeで始まります(開始モードはプランやdefaultModeの設定で変わります)。auto modeでは人の代わりに別の分類器モデルが操作を審査し、危険と判断したものを止めます。以前の既定だったManual mode(設定値はdefault)は読み取り専用で始まり、編集やコマンド実行のたびに確認を求める方式です。

auto modeでも、自分で書いたaskとdenyのルールは効きます。分類器の判断基準と「bash denied」が出たときの対処はClaude Code auto modeとは?既定化した自動承認の仕組みで、各モードの使い分けはClaude Codeのパーミッションモードの違いと設定方法で扱っています。

権限ルールとサンドボックスが止める操作と素通しする操作の比較

2つの層は、見ている対象が違います。権限ドキュメントとサンドボックスのドキュメントから、守備範囲を並べました。

操作の例 Read拒否ルール サンドボックスのdenyRead
Readツールでの読み取り 止める 止めない
Bashのcat .env 止める 止める
grep -r で検索 止めない 止める
Pythonが自分で開く 止めない 止める
MCPサーバーやhooks 対象外 対象外

権限ルールは、Claude Codeが「このコマンドはこのファイルを読む」と解釈できた場合にだけ働きます。cat・head・sedやリダイレクトは解釈できますが、ファイル名を書かずに読むgrep -r pattern .や、スクリプトの中で開く処理は対象外だとドキュメントは明記しています。逆にサンドボックスはOSがプロセスを縛る仕組みで、Readのような組み込みツールには届きません。片方だけでは漏れる経路が残ります。

settings.jsonの権限ルールで秘密情報と危険なコマンドを止める設定手順

権限ルールはプロジェクトの.claude/settings.jsonに置けばgitで全員に共有できます。

deny・ask・allowの評価順と広いdenyを狭いallowで崩せない仕様

ルールはdeny、ask、allowの順に評価され、最初に一致したものが結果になります。具体的なルールほど優先、という仕組みではありません。ドキュメントの例では、Bash(aws *)をdenyに入れると、allowにBash(aws s3 ls)があっても止まります。

設定ファイルの階層をまたいでも同じです。ユーザー設定でallowしてプロジェクト設定でdenyすれば、denyが勝ちます。この性質があるので、守りたいものはdenyに、確認を挟みたいものはaskに入れ、allowは「確認を省いてよい作業」だけに絞るのが安全な書き方です。

.envと鍵ファイルを読ませないdenyルールのパス記法と設定例

次の設定は、秘密情報の読み取りと外部への送信を止め、pushの前には必ず確認を挟む例です。プロジェクト直下の.claude/settings.jsonに置きます。

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(./secrets/**)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "allow": [
      "Bash(npm run test *)",
      "WebFetch(domain:docs.github.com)"
    ]
  }
}

パスの書き方には4種類あり、取り違えが多いところです。.envのようなファイル名だけの指定はgitignoreと同じ扱いで、どの階層の.envにも一致します。~/はホームディレクトリ、//で始めるとファイルシステムの絶対パスです。先頭がスラッシュ1本の/pathは絶対パスではなく、設定ファイルの置き場所が基準になります。ユーザー設定にRead(/secrets/**)と書くと~/.claude/secretsを指してしまうので注意してください。Readの拒否はEditとWriteにも及び、同じ場所への書き込みも止まります。

.claudeignoreを置いても効果は無く、中身はReadの拒否ルールへ移すよう案内されています。

curlの宛先を引数で絞るBashルールが破られる4つの書き方

「curlはGitHub宛てだけ許す」という意図でBash(curl http://github.com/ *)と書いても、権限ドキュメントは次の4つで外れると警告しています。

  • オプションをURLの前に置く(curl -X GET http://github.com/...)
  • プロトコルを変える(https)
  • 短縮URLからリダイレクトさせる(curl -L)
  • 変数に入れてから渡す(URL=...; curl $URL)

引数で宛先を絞るのはやめ、上の設定例のようにcurlとwgetをdenyにして、Webの参照はWebFetch(domain:...)の許可に寄せてください。ただしBashのdenyはコマンドの書き方と照合するだけで、フルパス指定やsh -cの中までは一致しません。通信先を確実に縛る必要があるなら、次章のサンドボックスのネットワーク許可リストと組み合わせます。コマンド単位の検査はClaude Code HooksのPreToolUseでも書けます。

サンドボックスでBashの読み書きと通信先をOSレベルで閉じる導入手順

サンドボックスは、Claudeが実行するBash・PowerShell・Monitorのコマンドと、その子プロセスをOSで囲います。仕組みはオープンソースのanthropics/sandbox-runtimeで公開されています。

SeatbeltとbubblewrapのOS別準備と/sandboxで有効化する手順

対応しているのはmacOS、Linux、WSL2です。macOSは標準のSeatbeltを使うので追加の導入はありません。LinuxとWSL2ではbubblewrapとsocatが必要になります。

# Ubuntu / Debian
sudo apt-get install bubblewrap socat

# Fedora
sudo dnf install bubblewrap socat

# Claude Codeを起動してから、セッション内でサンドボックスの設定画面を開く
/sandbox

Ubuntu 24.04以降は既定のAppArmorがbubblewrapの名前空間作成を止めるため、ドキュメントの追加手順が要ります。有効にすると、サンドボックス内で動くコマンドは確認なしで実行されるモード(auto-allow)が既定です。確認の回数は減りますが、denyルールやBash(git push *)のような中身を指定したaskルールは引き続き効きます。

既定で読める~/.sshと~/.awsをcredentialsで塞ぐ設定例

サンドボックスの既定では、書き込みは作業ディレクトリと一時ディレクトリに限られる一方、読み取りはマシンのほぼ全体に開いています。ドキュメントは~/.sshや~/.aws/credentialsも読めると明記しており、組み込みの拒否リストも無いと書いています。自分で列挙しない限り、鍵は読まれる前提で考えてください。

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

credentialsのdenyは、ファイルの読み取りを拒否し、環境変数をコマンド実行前に消します。どの設定階層からも追加でき、別の階層が足した拒否を取り消すことはできません。通信は手元のプロキシを通り、allowedDomainsは空から始まります。パッケージ取得に必要なドメインだけを足していく運用が前提です。

脱出口のdangerouslyDisableSandboxを閉じる厳格モード

サンドボックス内で失敗したコマンドは、ClaudeがdangerouslyDisableSandboxを付けて外で再実行しようとすることがあります。Manual modeなら「Bash command (unsandboxed)」という確認が出ますが、bypassPermissionsモードでは確認なしで走ります。またBash(curl *)のようなallowルールがあると、その再実行も承認されてしまう仕様です。

この脱出口は"allowUnsandboxedCommands": falseで閉じられます。/sandboxの画面では「Strict sandbox mode」と表示される設定です。サンドボックスが起動できないときに素のまま実行させないためには、"failIfUnavailable": trueも合わせて入れます。既定では、依存が足りないとサンドボックス無しで黙って動くからです。

他人のリポジトリとclaude -pで起きる自動実行と信頼確認の抜け道

手元の設定を固めても、リポジトリ側の設定ファイルが別の命令を持ち込むことがあります。外部から受け取ったコードを扱う受託開発やOSSのレビューでは、ここが一番の盲点です。

信頼ダイアログの前でもhooksとenvが動く仕様と.mcp.jsonの扱い

対話セッションでは、初めてのフォルダで起動すると信頼確認のダイアログが出ます。プロジェクトのpermissions.allowはこれを承認するまで使われません。ところが権限ドキュメントの表では、親フォルダだけを信頼した場合やclaude -pでの実行時に、設定ファイル内のhooks、envブロック、apiKeyHelperなどの補助コマンドは「使われる」と書かれています。

.mcp.jsonのサーバーはさらに差が大きく、対話セッションでは接続前に確認が出るのに対し、claude -pでは承認の有無にかかわらず確認なしで接続されます。claude -pとSDKのセッションは、そもそも信頼ダイアログを表示しません。悪意のあるリポジトリを-pで処理すると、仕込まれたフックがそのまま手元で実行されうるということです。

CIで未知のリポジトリを扱う際の–bareと–setting-sources併用

ドキュメントは、自分で書いていないリポジトリでclaude -pを走らせる前の対策を4つ挙げています。CIのジョブに組み込む形にすると次のとおりです。

# 1) プロジェクトの設定ファイルと.mcp.jsonを読まない
claude --setting-sources user -p "このリポジトリの変更点を要約して"

# 2) hooks・skills・サブエージェント・プラグイン・.mcp.jsonを読まない
#    (プロジェクトのenvブロックは適用されるので注意)
claude --bare -p "このリポジトリの変更点を要約して"

# 3) その実行だけhooksを止める(ユーザー設定に書くだけではプロジェクト側に上書きされる)
claude --settings '{"disableAllHooks": true}' -p "このリポジトリの変更点を要約して"

4つ目は、disabledMcpjsonServersに名前を書いて特定の.mcp.jsonサーバーを拒否する方法です。外部コードを扱うCIでは、1と2を組み合わせ、使ってよいMCPサーバーだけを--strict-mcp-config --mcp-config ./mcp.jsonで明示的に渡す構成をすすめます。--bareはOAuthのログインを読まずAPIキーで動くため、課金経路はClaude Codeの料金プラン比較の認証の優先順位の章で確かめてください。

チーム導入でmanaged-settings.jsonを配り個人の緩和を封じる組織の設定

個人のsettings.jsonは本人が書き換えられるため、組織のルールは管理設定で配ります。

managed-settings.jsonの3OS別配置パスとMDM配信の選び方

管理設定の配布ドキュメントによると、ファイルで配る場合の置き場所は次の3つです。ほかの階層や--settingsの値では上書きできません。

  • macOS:/Library/Application Support/ClaudeCode/
  • Linux・WSL:/etc/claude-code/
  • Windows:C:\Program Files\ClaudeCode\

ファイル名はmanaged-settings.jsonで、部署ごとに分けたい場合は同じ場所のmanaged-settings.d/に分割できます。旧来のC:\ProgramData\ClaudeCode\は読まれないので、以前の手順書で配った会社は置き場所を確かめてください。MDMを使う場合は、macOSなら構成プロファイルのcom.anthropic.claudecodeドメイン、WindowsならHKLM\SOFTWARE\Policies\ClaudeCodeのSettings値にJSONを入れます。こちらは起動時と30分ごとに読み直されます。端末管理の仕組みが無い組織は、claude.aiの管理画面から配るサーバー管理設定が手軽です。

bypassPermissionsとauto modeを無効化する管理設定の設定例

サンドボックスを必須にし、脱出口と確認スキップを閉じ、権限ルールを管理側だけに絞る最小構成です。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Read(//**/.env)",
      "Read(~/.ssh/**)",
      "Bash(curl *)",
      "Bash(wget *)"
    ]
  },
  "allowManagedPermissionRulesOnly": true,
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

allowManagedPermissionRulesOnlyを入れると、ユーザーやプロジェクトのallowルールは無視されます。開発者が自分でallowを足せなくなるため、日常で使うコマンドの許可は管理側で用意しておかないと、確認の嵐になる点に注意してください。auto modeも禁止したい場合は、permissionsの中に"disableAutoMode": "disable"を足します。この構成ではサンドボックスがリポジトリ側の緩和設定を受け付けなくなるため、例外として外で動かすツールはexcludedCommandsとして管理設定に書きます(v2.1.285以降の挙動)。プラグインの配布はClaude Codeプラグインの作り方と社内配布、監査ログはClaude CodeのOpenTelemetry設定で扱っています。

送信したコードの学習利用と保存期間が契約プランで30日と5年に分かれる条件

データ利用のドキュメントの記載を表にしました。

契約 学習利用 保存期間
Free・Pro・Max(許可) 使われる 5年
Free・Pro・Max(不許可) 使われない 30日
Team・Enterprise・API 使われない 30日
Enterprise+ZDR 使われない サーバー側に残さない

個人プランは設定ひとつで扱いが変わるため、会社のコードを個人契約で扱わせない運用ルールが要ります。見落としやすいのが手元の保存で、会話の記録は~/.claude/projects/に平文で30日残り、期間はcleanupPeriodDaysで変更可能です。また/feedbackで送った会話は5年保存されるため、社外秘を扱う端末ではDISABLE_FEEDBACK_COMMAND=1を管理設定のenvに入れておくと安心です。認証情報そのものはmacOSならキーチェーン、Linuxなら権限0600のファイルに保存されます。

Claude Codeのセキュリティ対策を入れない判断と過剰になる場面の線引き

全端末に一律で締めると、かえって使われなくなります。強さは扱うデータと端末で決めます。

ネイティブWindows端末にfailIfUnavailableを配ると起動しない問題

サンドボックスはネイティブWindowsでは動きません。そのためfailIfUnavailableを含む管理設定をWindows端末に配ると、Claude Codeは起動時に終了します。ドキュメントが示す回避策は、macOSとLinuxにだけファイルやMDMで配るか、Windowsの利用者にWSL2かコンテナ内で使ってもらうかの2つです。サーバー管理設定は組織の全員に効くため、OS別に分けたいならファイル配布を選んでください。

秘密情報を持たない個人の検証用リポジトリに組織と同じ厳格設定を求めない理由

秘密情報もクラウドの権限も持たない検証用リポジトリなら、auto modeとプロジェクトのdenyルールだけで十分です。allowManagedPermissionRulesOnlyまで掛けると、許可を自分で足せないため確認が増え、結局--dangerously-skip-permissionsで回避する人が出ます。締めすぎが抜け道を生む典型例です。

逆に、本番のクラウド認証情報が入った端末、顧客のソースコードを預かる環境、外部リポジトリを自動処理するCIでは、ここまでの3層をすべて入れてください。bypassPermissionsは、ドキュメントの警告どおりコンテナや使い捨てのVMの中に限って使います。AIエージェントにどこまで権限を渡すかの設計から相談したい場合は、一創のAIセキュリティ対策で現状確認から支援しています。

Claude Codeのセキュリティと情報漏えい対策についてよくある質問

社内導入の検討でよく出る質問に、2026年10月時点の公式ドキュメントで答えます。

Claude Codeに入力した社内のソースコードは学習に使われますか?

Team・Enterprise・APIなどの商用契約では、利用者が自分で提供を選ばない限り学習には使われません。Free・Pro・Maxでは、プライバシー設定で許可していると使われます。設定は利用者がいつでも変えられるため、会社のコードを扱うなら個人の設定に依存しない商用契約に寄せてください。

Claude Code Securityとこの記事の設定は何が違いますか?

Claude Code Securityは、AIがコードベースの脆弱性を探して修正案を出す製品です。この記事が扱うのはClaude Code自体に何を許すかという設定の話なので、目的が別です。製品の機能と料金、Codex Securityとの比較はCodex Securityとは?仕組み・料金・Claude Code Securityとの違いで、公開β版の概要はClaude Security公開β版の提供開始と機能概要で解説しています。変更差分だけを手早く確かめたいときは、セッション内の/security-reviewコマンドも使えます。

CLAUDE.mdに「.envを読まないで」と書けば十分ですか?

十分ではありません。CLAUDE.mdは行動を方向づける指示で、強制力はありません。権限ドキュメントも、CLAUDE.mdへの記載は「境界を強制しない」ので権限ルールやフックと組み合わせるよう書いています。.envを確実に守るなら、Read(.env)のdenyルールと、サンドボックスのcredentialsまたはdenyReadの両方を入れてください。

プロンプトインジェクションにはどう備えればよいですか?

Claude Code側には、Webページを別のモデルで要約してから渡す仕組みや、curl・wgetを既定で自動承認しない仕組みがあります。それでも公式は「完全に防げるシステムは無い」と明記しています。利用者側では、信頼できない文書を直接パイプで渡さない、外部のWebサービスを触る作業は仮想マシン内で行う、通信先をallowedDomainsで絞る、の3点を基本にしてください。

Claude Code自体の脆弱性を見つけたらどこへ報告しますか?

セキュリティ解説は、公開の場では開示せず、AnthropicのHackerOneプログラムから報告するよう求めています。再現手順を詳しく添え、修正されるまで公開を待つのが条件です。ベンダーの統制を社内審査で説明する資料はAnthropic Trust Centerにあり、SOC 2 Type 2の報告書やISO 27001の認証を確認できます。

関連記事

お気に入りに入れた記事の一覧

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.09.05 コラム eKYCとは?方式の違いと2027年4月の犯収法改正で変わる本人確認要件
  2. 2026.10.03 テックブログ AWS Snowconeとは:サービス終了後の現状とDataSync・Greengrassへの移行手順【2026年版】
  3. 2026.10.03 テックブログ foliumとは:Pythonで地図を作る使い方・タイルの注意点・1.0候補版の変更点【2026年版】
  4. 2026.01.22 テックブログ Xアルゴリズム最新(2026年9月)|おすすめの仕組みと公開コードの重み一覧
  5. 2026.10.03 コラム ワークフローシステムの通知機能の設計:承認を止めないリマインド・催促と宛先の絞り方

RELATED POSTS 関連記事

目次