Claude Codeのセキュリティ設定｜権限・sandbox・法人運用【2026年版】
Claude Codeを安全に使う要点は、プロンプトで「危険なことをしないで」と頼むことではありません。permissionsで許可を制御し、sandboxでOSレベルの境界を作り、機密情報と外部接続を明示的に遮断すること です。
この記事では、2026年8月15日時点のAnthropic公式仕様を基準に、個人開発から法人運用まで使える設定例を解説します。Anthropicの公式記載と、読者が安全なダミー環境で確認できる項目を分け、当サイトが実機で確認していない法人機能は「未検証」として扱います。
permissions.denyとsandboxの適用範囲を更新情報で確認する場合は、権限とsandboxの更新情報 も参照してください。
BlueAI法人資料テンプレートをWeb向けに再構成
結論：7つの防御を重ねる
denyを先に設計し、必要最小限だけallowする.env、秘密鍵、顧客データをパス単位で拒否するBashをsandbox内で動かし、外へ逃げる経路を閉じる
接続先ドメインを許可リストへ限定する
bypassPermissionsを通常運用で使わないMCP、プラグイン、フックをコードと同じように審査する
契約上のデータ利用・保持と、端末上の履歴を確認する
設定だけで100%安全になるわけではありません。コードレビュー、CI、バックアップ、資格情報管理と組み合わせて防御を重ねます。
まず脅威モデルを決める
Claude Codeはファイルを読み、編集し、シェルコマンドや外部ツールを実行できます。守る対象と侵入・誤操作の経路を先に整理します。
守る対象 主なリスク 主な対策 ソースコード 意図しない変更・削除 権限、Git、レビュー、バックアップ .env・秘密鍵モデル入力、ログ、外部送信 Read deny、sandbox、秘密情報管理 本番環境 DB更新、デプロイ、障害 資格情報分離、ネットワーク制限、承認 顧客・個人情報 契約外の処理、保持 データ分類、契約確認、入力禁止 開発端末 悪意あるコードや依存関係の実行 sandbox、最小権限、隔離環境 外部サービス MCPやフック経由の情報流出 接続先審査、許可リスト、監査
攻撃だけでなく、タイプミス、古い手順、誤った推論、悪意あるリポジトリ内の指示も想定します。
managed settingsの配送経路を分けて考える
managed settingsは、利用者のsettings.jsonより優先される組織ポリシーの仕組みです。ただし、配送経路によって必要な契約・管理権限・確認できる範囲が違います。Enterprise契約がなくてもfile-basedの設定ファイルは読めますが、管理コンソールの動作を再現したことにはなりません。
配送経路 公式に記載された場所・方法 このページでの扱い server-managed claude.aiの管理コンソール、またはClaude apps gatewayから認証時に配布Team / Enterpriseの管理コンソール、SSO、リモート更新は未検証。契約・アカウント条件は公式資料で確認する MDM・OSポリシー macOSのcom.anthropic.claudecode、WindowsのHKLM\SOFTWARE\Policies\ClaudeCodeなど MDM、Registry、端末全体への配布と改変耐性は未検証。管理者権限を持つ端末でのみ確認する file-based macOS:/Library/Application Support/ClaudeCode/managed-settings.json、Linux / WSL:/etc/claude-code/managed-settings.json、Windows:C:\Program Files\ClaudeCode\managed-settings.json Enterprise契約なしでも、権限のある使い捨て端末でファイルの読み込みと/status表示を確認できる
managed settingsの優先順位、配列のマージ、管理設定だけを許可するロックには例外があります。permissionsのdenyが別スコープのallowを上書きすること、sandbox.network.allowManagedDomainsOnlyはmanaged側の許可リストだけを使うことなど、設定キーごとの挙動は公式のSettings と公式のPermissions を確認してください。
公式仕様・ローカル確認・未検証の境界
公式仕様 ：managed settingsはユーザー・プロジェクト設定より高い優先順位で適用され、permissions.disableBypassPermissionsMode、allowManagedPermissionRulesOnly、sandboxの許可リストなどを組織側から設定できます。ローカルで確認可能 ：file-based設定をダミー環境へ配置し、/statusの設定ソース、deny・sandbox・bypass無効化の期待動作、設定を戻した後の状態を記録できます。このページで未検証 ：Anthropic管理コンソールからの配布、SSO / SCIM、リモート更新、Enterpriseの利用分析、MDMの改変耐性、クラウドプロバイダーやClaude apps gatewayの差異です。以下の手順を実施していない限り、「法人環境で検証済み」とは表記しません。
Enterpriseなしで行う安全なローカル確認
これは当サイトが実機で実行した結果ではなく、公式仕様を自環境で再確認するための手順です。実データ、本番資格情報、公開先を含む端末では試さないでください。
使い捨てのテスト端末または隔離環境を用意し、OS、Claude Codeのclaude --version、設定を置いた日時を記録する。既存のmanaged settingsがある端末は対象にしない。
管理者権限が必要なfile-basedパスへ、次のような最小設定を配置する。github.comへの通信も必須ではないため、ネットワーク確認をしない場合はallowedDomainsを空にしてよい。
Copy {
"permissions" : {
"disableBypassPermissionsMode" : "disable" ,
"allowManagedPermissionRulesOnly" : true ,
"deny" : [ "Read(./.env)" , "Read(./secrets/**)" ]
} ,
"sandbox" : {
"enabled" : true ,
"failIfUnavailable" : true ,
"allowUnsandboxedCommands" : false ,
"network" : {
"allowedDomains" : [ "github.com" ] ,
"allowManagedDomainsOnly" : true ,
"strictAllowlist" : true }
}
}
/statusで設定ソースを確認し、テストフォルダ内のダミーREADME.md、.env、secrets/だけを対象にする。Read deny、sandboxの利用不能時停止、許可外ドメインの拒否を記録する。bypassモードの無効化を確認する場合も、実データのないフォルダで起動が拒否または制限されることだけを確認し、処理を続けない。User / Project / Local設定で同じキーを変更しても、管理設定の制約を外せないことを確認する。確認できない、または設定ソースが表示されない場合は「未検証」と記録する。
復旧時は元のファイルを日時付きバックアップへ退避してから、テスト設定だけを管理者の手順で取り除く。/statusでmanaged sourceが消えたこと、ダミーフォルダに想定外の変更がないことを確認し、バックアップを保持する。広いパスへの削除コマンドは使わない。
記録には、設定ファイル全文（秘密情報なし）、OSとClaude Codeバージョン、/statusの表示、各操作の期待結果と実測結果、復旧後の状態を含めます。安全な一般設定の確認から始める場合は、安全スターター30分ラボ を使い、設定ファイルの意味はsettings.json用語集 で確認してください。
1. permissionsはdenyから設計する
Claude Codeの権限ルールは、deny → ask → allow の順に評価されます。広いdenyに狭いallowで例外を作ることはできません。
個人・小規模チーム向けの出発点は次の形です。
Copy {
"permissions" : {
"defaultMode" : "default" ,
"allow" : [
"Bash(npm run lint)" ,
"Bash(npm run test *)" ,
"Bash(git status)" ,
"Bash(git diff *)"
] ,
"ask" : [
"Bash(git commit *)"
] ,
"deny" : [
"Read(./.env)" ,
"Read(./.env.*)" ,
"Read(./secrets/**)" ,
"Read(./credentials/**)" ,
"Bash(git push *)"
] ,
"disableBypassPermissionsMode" : "disable"
}
} プロジェクトで共有する設定は.claude/settings.jsonへ置きます。個人だけの許可は.claude/settings.local.jsonへ保存されることがあります。/permissionsを実行すると、現在のルールと設定元を確認できます。
広すぎるallowを避ける
次のようなルールは、意図した範囲を超えやすいため注意が必要です。
Copy {
"permissions" : {
"allow" : [ "Bash(npm *)" , "Bash(git *)" ]
}
} npm *には依存パッケージの追加やスクリプト実行が、git *にはpushや履歴変更が含まれます。日常的に確認なしで実行したい具体的なコマンド だけを登録します。
CLAUDE.mdはセキュリティ境界ではない
CLAUDE.mdに禁止事項を書くことは有効ですが、これはモデルの行動を誘導する指示です。公式ドキュメントでも、権限を強制するのはpermissions、permission mode、hookなどであり、プロンプトではないと説明されています。
Copy ## セキュリティルール
- 本番環境へ接続しない
- 秘密情報を表示・記録・コミットしない
- データ削除と外部送信は事前に確認するこの記述に加え、同じ内容を強制設定で実装します。
2. 機密ファイルは明示的に拒否する
.gitignoreはGitの追跡対象を制御するファイルであり、Claude Codeの読み取りを禁止する境界ではありません。また、Claude Codeの公式な機密ファイル除外機能として.claudeignoreへ依存すべきではありません。
パスの拒否はpermissions.denyへ書きます。
Copy {
"permissions" : {
"deny" : [
"Read(./.env)" ,
"Read(./.env.*)" ,
"Read(./**/*.pem)" ,
"Read(./**/*.key)" ,
"Read(./secrets/**)" ,
"Read(~/Documents/customer-data/**)"
]
}
} Readの拒否は、同じパスへのEdit・Writeも止めます。ただし、PythonやNode.jsなどの任意プロセスが内部でファイルを読むケースまで完全には防ぎません。すべてのサブプロセスに強制するにはsandboxのファイルシステム制限を使います。
秘密情報の運用原則
リポジトリへ実値を置かず、.env.exampleにはダミー値だけを書く
個人キーを共有しない
本番資格情報を開発端末へ常駐させない
CIでは短命・最小権限の資格情報を使う
漏えいが疑われたら即時失効・ローテーションする
シークレットスキャンとコミット前チェックも併用します。
3. sandboxでBashを隔離する
permissionsはClaude Codeが行うツール呼び出しを制御します。sandboxは、Bashから起動されるスクリプトやサブプロセスをOSレベルで制限します。役割が異なるため、両方を使います。
組織でsandboxを必須にする設定例です。
Copy {
"sandbox" : {
"enabled" : true ,
"failIfUnavailable" : true ,
"allowUnsandboxedCommands" : false }
} 設定 効果 enabledBashをsandbox内で実行する failIfUnavailablesandboxを開始できなければ実行を止める allowUnsandboxedCommands: falsesandbox外での再試行を許可しない
failIfUnavailableを設定しない場合、依存関係不足や未対応環境で警告後にsandboxなしで実行される可能性があります。安全要件として必須ならtrueにします。
OSごとの対応
環境 組み込みsandbox macOS 対応 Linux 対応。bubblewrapとsocatが必要 WSL2 対応 Windowsネイティブ 非対応
Windows端末で同等の隔離が必要なら、WSL2、開発コンテナ、VMなどを選びます。
4. ネットワーク接続先を限定する
外部通信を制御する際、Bash(curl ...)の文字列パターンだけでは、オプション順、リダイレクト、変数、別コマンドなどを網羅できません。sandboxのネットワーク許可リストを使うほうが堅牢です。
Copy {
"sandbox" : {
"enabled" : true ,
"failIfUnavailable" : true ,
"allowUnsandboxedCommands" : false ,
"network" : {
"allowedDomains" : [
"github.com" ,
"api.github.com" ,
"registry.npmjs.org"
] ,
"strictAllowlist" : true }
}
} strictAllowlistを有効にすると、許可リスト外のホストは追加承認を促すのではなく拒否されます。組織ではmanaged settingsのsandbox.network.allowManagedDomainsOnlyも検討し、利用者側の設定で接続先を広げられないようにします。
注意点として、sandboxのドメイン設定はsandbox内のコマンドに適用されます。WebFetchなどのプロセス内ツールは、それぞれのpermissionルールも設定してください。
5. bypassPermissionsを通常運用で使わない
--dangerously-skip-permissionsは、bypassPermissionsモードで権限確認を省略するためのフラグです。ファイル変更やシェル実行の多くが、利用者の確認なしに進みます。
Copy claude --dangerously-skip-permissions日常の開発端末、本番資格情報がある端末、重要な未コミット変更がある環境では使わないでください。無人実行で必要な場合も、使い捨てのコンテナやVM、最小権限の資格情報、ネットワーク制限、バックアップを用意します。
組織ではmanaged settingsへ次を設定し、利用者が危険モードへ切り替えられないようにします。
Copy {
"permissions" : {
"disableBypassPermissionsMode" : "disable"
}
} まずはdefaultまたはdontAskモードと個別のallowルールで自動化できないか検討します。フラグの詳細は用語集 を参照してください。
6. MCP・プラグイン・フックを審査する
Claude Code本体の設定が安全でも、MCPサーバー、プラグイン、フックが広い権限を持てば境界は広がります。
導入前チェック
提供元とリポジトリは真正か
ライセンスと更新方針は確認できるか
読むファイル、環境変数、接続先は何か
書き込み、削除、外部送信が可能か
依存関係とインストールスクリプトは何をするか
バージョンを固定し、廃止・失効できるか
プロジェクト内の設定やフックは、信頼していないリポジトリでは実行しないでください。workspace trustを確認し、差分レビュー後に有効化します。
法人ではmanaged settingsを使い、承認済みMCPサーバー、マーケットプレイス、フックだけを許可します。詳しい導入設計は
関連記事 — 活用 Claude Codeの法人導入ガイド｜セキュリティ・権限・運用設計 Claude Codeを企業・チームへ導入する手順を解説。プラン選定、権限・サンドボックス、データ保持、MCP管理、監査ログ、KPI設計まで実務向けにまとめました。
にまとめています。
7. データ利用・保持・ローカル履歴を確認する
Claude Codeが扱うデータの条件は、利用プランと契約で確認します。Anthropic公式では、Team、Enterprise、APIなどCommercial Terms配下のデータは、顧客が明示的にオプトインしない限り生成モデルの学習に利用しないと説明しています。
一方、次の点は別々に確認が必要です。
確認対象 例 サーバー側の保持 標準保持期間、Zero Data Retentionの適用 モデル改善への利用 契約、組織設定、利用プラン ローカル履歴 ~/.claude/projects/の会話記録監視データ OpenTelemetryへ出す属性・イベント 任意フィードバック 送信時に共有される会話・診断情報
ローカルのセッション記録は既定で30日後にクリーンアップされ、cleanupPeriodDaysで調整できます。端末の暗号化、アカウント分離、退職時の消去も運用に含めます。
Copy {
"cleanupPeriodDays" : 14
} 最新条件はClaude Code公式のデータ利用ページ と自社の契約書面を確認してください。
個人開発向けの最小構成
最初は次の状態を目指します。
defaultモードを使う秘密ファイルをRead denyへ登録する
git pushと破壊的操作を自動許可しないsandboxを有効にする
作業前にgit statusとバックアップを確認する
変更後はテストと差分レビューを行う
設定例です。
Copy {
"permissions" : {
"defaultMode" : "default" ,
"allow" : [
"Bash(npm run lint)" ,
"Bash(npm run test *)" ,
"Bash(git status)" ,
"Bash(git diff *)"
] ,
"deny" : [
"Read(./.env)" ,
"Read(./.env.*)" ,
"Read(./secrets/**)" ,
"Bash(git push *)"
] ,
"disableBypassPermissionsMode" : "disable"
} ,
"sandbox" : {
"enabled" : true ,
"allowUnsandboxedCommands" : false }
} 環境によって必要なコマンドと接続先は異なります。コピー後、そのまま広い権限を足すのではなく、拒否ログと承認プロンプトを見て最小限ずつ調整してください。
法人運用向けチェックリスト
問題が起きたときの初動
秘密情報の表示、誤コミット、意図しない外部送信が疑われる場合は、原因調査より先に被害拡大を止めます。
セッションと自動処理を停止する
該当資格情報を失効・ローテーションする
push、デプロイ、外部接続を止める
Git差分、CI、監査ログ、端末履歴を保全する
影響したデータ・期間・送信先を特定する
permissionとsandboxの欠落を修正する
必要な社内報告・顧客連絡・法的対応を行う
履歴を消す前に、組織のインシデント対応手順に従って証跡を保全してください。
まとめ
Claude Codeの安全性は、単一の設定ではなく次の組み合わせで作ります。
permissions：Claude Codeが何を試せるか
sandbox：BashとサブプロセスがOS上で何へ到達できるか
managed settings：利用者が組織ポリシーを回避できないか
データ管理：何を入力でき、どこに何日残るか
レビューと監査：問題を検知し、戻せるか
まず機密ファイルと本番資格情報を分離し、denyとsandboxを設定してから便利なallowを増やしてください。
Claude Code の法人導入を、設計から実装まで支援します
権限・セキュリティ設計、既存開発フローへの導入、社内展開まで。まずは現在の課題をお聞かせください。
法人向け支援を見る 相談内容が未整理でも構いません
公式資料
レッスン 組織導入 — 60分 Claude Code セキュリティ｜組織導入の安全設計 Claude Code を組織で安全に運用する技術設計。データ送信先、permissions 制御、機密情報の除外、MCP の権限、監査ログ、SaaS / オンプレ / Bedrock 選定まで、情シス目線で実装解説します。
株式会社BlueAI||法人向けAI導入・内製化支援
