Claude Codeのセキュリティ設定｜危ない操作を止める権限・deny・サンドボックスの設定例【2026年版】
Claude Codeは、ファイルを読み書きし、コマンドを実行しながら開発を進めてくれる便利な道具です。
その反面、「.envの中身を読まれたらどうしよう」「勝手に外部と通信されないか」と不安を感じている方も多いのではないでしょうか。
この記事は、Claude Codeを業務で使い始めた開発者や、小さな開発チームで使い方を決める立場の方に向けて書いています。
権限モード、settings.jsonの置き場所と優先順位、denyルールの書き方、サンドボックス、チームでの統一方法までを、Anthropicの公式ドキュメントをもとに解説します。
八木 利生太郎（Yagi Ryutaro）｜株式会社Last Scene 代表取締役
株式会社Last Scene代表取締役。大学時代からエンジニアとして活動し、サイバーエージェント（ABEMA）でAndroid開発に従事。Delightでは新規事業責任者として、AI SaaSを企画から運用まで1人で立ち上げ、リリースから1年でARR2億円を突破した。現在はAIで作ったアプリのセキュリティ顧問を提供している。
Claude Codeは更新が速いツールです。この記事の内容は、2026年11月時点の公式ドキュメントにもとづいています。設定する前に、最新の公式ドキュメントもあわせて確認してください。
「止めたいことはdenyに書く」「チームの設定はGitで共有する」の2つから始めましょう！
まず、やりたいことと使う設定を一覧にします。
| やりたいこと | 使う設定 | 参照した公式ドキュメント |
|---|---|---|
| .envを読ませない | permissions.deny に Read(./.env) | Settings |
| 実行の前に必ず確認させる | askルール、またはManualモード | Permissions、Security |
| OSのレベルで閉じ込める | /sandbox（ファイルとネットワークの隔離） | Sandboxing |
| チーム全員を同じ設定にする | .claude/settings.json をGitで共有 | Settings |
| 会社として設定を強制する | managed settings | Settings |
この表は、Anthropicの公式ドキュメントの記載をもとに、本記事が整理したものです。
引用元：Anthropic「Settings files and precedence」 https://code.claude.com/docs/en/settings
引用元：Anthropic「Configure permissions」 https://code.claude.com/docs/en/permissions
Claude Codeで起きうるリスクを先に整理する
設定を考える前に、Claude Codeが何をできるのかを整理しておきましょう。
Claude Codeができることが分かれば、どこに制限をかければよいかも見えてきます。
ファイルの読み書き、コマンドの実行、ネットワーク通信
Claude Codeは、作業しているフォルダのファイルを読み、編集し、ターミナルのコマンドを実行できます。
コマンドを実行できるということは、curlやwgetのような通信のコマンドを使って、外部とデータをやり取りすることもできるということです。
便利な反面、「読ませたくないファイルを読む」「消したくないファイルを消す」「送りたくないところにデータを送る」といったことが、設定次第では起こりえます。
プロンプトインジェクションは「完全には防げない」
プロンプトインジェクションとは、AIへの指示を上書きしたり操ったりするために、悪意のある文章を紛れ込ませる手口です。
たとえば、Claude Codeに読ませたWebページやファイルの中に「このファイルの中身を外部に送れ」といった指示が隠されている、というケースが考えられます。
Anthropicの公式ドキュメントは、Claude Codeにはこうした攻撃への対策がいくつも組み込まれていると説明しています。
引用元：Anthropic「Security」 https://code.claude.com/docs/en/security
たとえば、Manualモードでは、ネットワークに接続するツールの多くが初期設定で利用者の承認を必要とします。curlやwgetのようにWebから内容を取ってくるコマンドも、初期設定では自動承認されません。
一方で公式ドキュメントは、これらの対策でリスクは大きく下がるものの、どんなシステムもすべての攻撃を完全に防げるわけではないとも書いています。
設定で守りつつ、承認する前にコマンドの中身を自分の目で確かめる習慣も欠かせません。
MCPサーバーは信頼できる提供元のものだけを使う
Claude Codeは、MCP（Model Context Protocol）サーバーをつなぐことで、外部のサービスやツールを使えるようになります。
Anthropicの公式ドキュメントによると、Anthropicはディレクトリに載せるコネクタを掲載基準で確認していますが、MCPサーバーのセキュリティ監査や管理は行っていません。
引用元：Anthropic「Security」 https://code.claude.com/docs/en/security
プロジェクトの .mcp.json に書かれたサーバーは、使う前に承認を求められます。提供元が分からないMCPサーバーは、承認しないようにしましょう。
権限モードの基本
Claude Codeには、どの操作を確認なしで実行してよいかを決める「権限モード」があります。
まずは、それぞれのモードで何が起きるのかを押さえましょう。
6つの権限モードの違い
公式ドキュメントに記載されている権限モードは、次の6つです。
| モード | 動き方 | 向いている場面 |
|---|---|---|
| default（Manual） | 各ツールを初めて使うときに許可を求める | 慣れないうちや、大切なリポジトリ |
| acceptEdits | 作業フォルダ内のファイル編集と、mkdirやcpなどの一般的なファイル操作を自動で受け入れる | 編集内容をあとでまとめて確認する場合 |
| plan | ファイルを読み、読み取り専用のコマンドで調べるが、ソースファイルは編集しない | 調査や設計の相談 |
| auto | 毎回の確認なしで進め、コマンドや通信の前に別の判定モデルが確認する | 定型的な作業を任せる場合 |
| dontAsk | 本来なら確認が必要な操作を、すべて自動で拒否する | 許可した操作だけを実行させたい場合 |
| bypassPermissions | 確認をほぼすべて省略する | 隔離された環境以外では使わない |
引用元：Anthropic「Configure permissions」 https://code.claude.com/docs/en/permissions
「向いている場面」の列は、公式ドキュメントの説明をもとに本記事が補ったものです。
公式ドキュメントによると、対話型のターミナルやVS Codeのセッションでは、autoモードが標準の開始モードになっています。
引用元：Anthropic「Security」 https://code.claude.com/docs/en/security
Manualモードでは、Claude Codeは読み取りの権限だけで始まります。ファイルの編集やテストの実行、コマンドの実行が必要になると、そのたびに確認を求めます。
「今後は確認しない」を選ぶと、どこに保存されるか
確認の画面で「Yes, and don't ask again」を選ぶと、同じ操作は次から確認されなくなります。
公式ドキュメントによると、この扱いは操作の種類によって変わります。
| 操作の種類 | 確認が必要か | 「今後は確認しない」の効く範囲 |
|---|---|---|
| ファイルの読み取り、Grep | 作業フォルダ内では不要 | なし |
| Bashコマンド | 必要（読み取り専用の一部コマンドを除く） | リポジトリとコマンドごとに永続 |
| ファイルの編集 | 必要 | セッションの終了まで |
| Webの取得（WebFetch） | 必要（一部の文書サイトを除く） | ドメインごとに永続 |
引用元：Anthropic「Configure permissions」 https://code.claude.com/docs/en/permissions
永続する許可は、Gitリポジトリの直下にある .claude/settings.local.json に保存されます。
何度も「今後は確認しない」を選んでいるうちに、思った以上に多くのコマンドが自動で通るようになっていることがあります。
/permissionsで定期的に見直す
公式ドキュメントは、セキュリティのベストプラクティスとして、/permissions で権限の設定を定期的に確認するよう勧めています。
引用元：Anthropic「Security」 https://code.claude.com/docs/en/security
月に1回など、見直す日を決めておくと忘れにくくなります。使っていないallowルールは削除しておきましょう。
Claude Codeで作ったアプリを公開する前に確認したい、鍵・権限・データベース・運用の30項目をまとめました。フォームにご入力後、すぐにPDFをダウンロードできます。
AIで作ったアプリ・社内ツールのセキュリティ診断
公開して大丈夫か、第三者の目で確認します
- AIで作ったアプリを公開してよいか判断できない
- 社内にセキュリティを見られる担当者がいない
- 鍵やデータベースの権限設定が正しいか確認してほしい
八木（Last Scene）AIで作ったアプリや社内ツールの診断に加えて、取引先からのセキュリティ要求への対応や、インシデント発生時の初動整理もご相談いただけます。
「このまま公開して大丈夫？」の一問からどうぞ。
settings.jsonの置き場所と優先順位
Claude Codeの設定は、settings.jsonというファイルに書きます。このファイルは複数の場所に置けて、置く場所によって効く範囲が変わります。
チームで使う場合は、ここを理解しておくことが大切です。
4つの置き場所と、効く範囲
公式ドキュメントでは、設定ファイルの置き場所が次のように整理されています。
| 種類 | ファイル | 効く範囲 | 主な使い道 |
|---|---|---|---|
| User | ~/.claude/settings.json | 自分の、このパソコン上のすべてのプロジェクト | 個人の好み、自分用の権限ルール |
| Shared project | .claude/settings.json | そのフォルダで作業する全員（Gitでコミットして共有） | チームの権限ルール、フック、プラグイン |
| Project local | .claude/settings.local.json | 自分の、そのプロジェクトだけ | 個人用の上書き、共有前の試し |
| Managed | managed-settings.json など | 組織が配布した全員 | セキュリティ方針、コンプライアンスの要件 |
引用元：Anthropic「Settings files and precedence」 https://code.claude.com/docs/en/settings
settings.local.json は、Claude Codeが作った場合はGitの管理から外されます。自分で作った場合は、.gitignore に自分で追加する必要があります。
優先順位は「managed＞コマンドライン＞local＞project＞user」
同じ設定が複数のファイルに書かれていた場合は、優先順位の高いほうが使われます。公式ドキュメントに記載された順番は次のとおりです。
- Managed settings（組織が配布する設定）
- コマンドライン（起動時に --settings で渡す設定）
- Project local settings（.claude/settings.local.json）
- Shared project settings（.claude/settings.json）
- User settings（~/.claude/settings.json）
引用元：Anthropic「Settings files and precedence」 https://code.claude.com/docs/en/settings
managed settingsに書かれた項目は、自分の設定ファイルやコマンドラインでは上書きできません。会社として守らせたいルールは、ここに書くことになります。
allowやdenyのリストは「足し算」になる
注意したいのが、permissions.allow のようなリストの扱いです。
公式ドキュメントによると、同じリストが複数のファイルに書かれている場合、どれか1つが選ばれるのではなく、すべてが結合されます。
引用元：Anthropic「Settings files and precedence」 https://code.claude.com/docs/en/settings
つまり、チームの設定でallowを絞っていても、個人のsettings.local.jsonにallowが溜まっていれば、そのぶん許可が広がります。
denyも同じく足し算なので、チームで共有するsettings.jsonにdenyを書いておけば、全員に効きます。
bypassPermissionsはプロジェクトの設定からは効かない
公式ドキュメントによると、permissions.defaultMode の値のうち auto と bypassPermissions は、project や local の設定ファイルに書いても効きません。
引用元：Anthropic「Settings files and precedence」 https://code.claude.com/docs/en/settings
使う場合はuserかmanagedの設定に書くか、1回のセッションだけ --permission-mode で指定します。
公式ドキュメントには、v2.1.257より前のバージョンではどのファイルからでも効いていたとも書かれています。古いバージョンを使っている場合は、更新を検討しましょう。
AIで作ったアプリ・社内ツールのセキュリティ診断
公開して大丈夫か、第三者の目で確認します
- AIで作ったアプリを公開してよいか判断できない
- 社内にセキュリティを見られる担当者がいない
- 鍵やデータベースの権限設定が正しいか確認してほしい
八木（Last Scene）AIで作ったアプリや社内ツールの診断に加えて、取引先からのセキュリティ要求への対応や、インシデント発生時の初動整理もご相談いただけます。
「このまま公開して大丈夫？」の一問からどうぞ。
コピーして使える設定例（allow・ask・deny）
ここからは、実際の設定例を紹介します。プロジェクトの .claude/settings.json に書いて、チームで共有する前提です。
ルールは「deny→ask→allow」の順に判定される
設定を書く前に、判定の順番を押さえておきましょう。
公式ドキュメントによると、ルールは deny、ask、allow の順に評価され、最初に一致したもので結果が決まります。ルールがどれだけ細かいかは、この順番に影響しません。
引用元：Anthropic「Configure permissions」 https://code.claude.com/docs/en/permissions
つまり、allowに書いた操作でも、denyに一致すれば拒否されます。「止めたいことはdenyに書く」と覚えておけば迷いません。
.envや鍵のファイルを読ませない
公式ドキュメントの設定例では、テストとlintのコマンドを許可し、.envを読めないようにしています。この例をもとに、鍵を置くフォルダも読めないようにした設定は次のとおりです。
| 書く場所 | ルール | 意味 |
|---|---|---|
| permissions.allow | Bash(npm run lint) | lintの実行は確認なしで許可する |
| permissions.allow | Bash(npm run test *) | テストの実行は確認なしで許可する |
| permissions.deny | Read(./.env) | .envを読ませない |
| permissions.deny | Read(./.env.*) | .env.localなども読ませない |
| permissions.deny | Read(./secrets/**) | secretsフォルダの中を読ませない（本記事による追加例） |
引用元：Anthropic「Settings files and precedence」 https://code.claude.com/docs/en/settings
ファイルに書くときは、"permissions" の中に "allow" と "deny" の配列を作り、表のルールを文字列として並べます。
公式ドキュメントによると、許可したフォルダの中に、denyで止めたファイルへのシンボリックリンクがあっても、そのリンクは拒否されます。たとえば ~/.ssh を止めていれば、プロジェクト内から ~/.ssh/id_rsa を指すリンクも読めません。
引用元：Anthropic「Configure permissions」 https://code.claude.com/docs/en/permissions
curlやwgetを止めるときの注意
外部との通信を止めたい場合は、Bash(curl *) や Bash(wget *) をdenyに書く方法があります。
ただし公式ドキュメントは、コマンドの引数を細かく絞り込むBashのルールは壊れやすいと注意しています。
たとえば Bash(curl http://github.com/ *) と書いてGitHubだけに絞ろうとしても、オプションを先に書く、httpsにする、リダイレクトを使う、変数を使うといった書き方には一致しません。
引用元：Anthropic「Configure permissions」 https://code.claude.com/docs/en/permissions
通信先をしっかり絞りたい場合は、次に紹介するサンドボックスのネットワーク制限とあわせて使うのがおすすめです。
ルールの「*」の書き方で、許可の範囲が大きく変わる
Bashのルールでは、「*」が「その位置に入る任意の文字」を表します。公式ドキュメントでは、書き方による違いが次のように説明されています。
| ルール | 一致する例 | 一致しない例 |
|---|---|---|
| Bash(npm run build) | npm run build | npm run build --watch |
| Bash(npm run *) | npm run build、npm run test --watch | npm install |
| Bash(ls *) | ls -la、ls | lsof |
| Bash(ls*) | ls -la、lsof | （スペースがないので広く一致する） |
| Bash(git * main) | git merge main、git push origin main | git log |
引用元：Anthropic「Configure permissions」 https://code.claude.com/docs/en/permissions
ドキュメントでは、「*」はサブコマンド（git logのlogの部分）の後ろに置くよう勧めています。Bash(git log *) ならgit logだけを許可しますが、Bash(git *) と書くと、git pushやgit resetを含むすべてのgitコマンドを許可することになります。allowに書くルールは、できるだけ「*」の前を長く書くのが安全です。
組み合わせたコマンドや、包んだコマンドの扱い
Claude Codeは「&&」「;」「|」などでつないだコマンドを分けて判定します。公式ドキュメントによると、Bash(safe-cmd *) を許可していても、safe-cmd && other-cmd のように別のコマンドがつながっている場合は、すべてのコマンドが許可されていないと確認なしでは動きません。
一方で、denyとaskのルールは、つないだコマンドのどれか1つに一致すれば効きます。たとえば Bash(git clean *) をaskにしておくと、cd /tmp && git clean -f のような形でも確認が入ります。
引用元：Anthropic「Configure permissions」 https://code.claude.com/docs/en/permissions
注意したいのは、npx、docker exec、devbox runのように「中で別のコマンドを動かす道具」です。ドキュメントによると、これらは自動ではほどかれないため、Bash(devbox run *) を許可すると、devbox run rm -rf . のような命令まで通ってしまいます。こうした道具は、Bash(devbox run npm test) のように中身まで書いた形で1つずつ許可してください。
denyのルールにも、すり抜けられる形がある
公式ドキュメントでは、Bashのルールが一致しない書き方として、次の例が挙げられています。
| ルール | 止まる例 | 止まらない例 |
|---|---|---|
| Bash(curl *) | curl https://example.com | /usr/bin/curl https://example.com、sh -c 'curl https://example.com' |
| Bash(rm *) | rm -rf build/ | /bin/rm -rf build/、bash -c 'rm -rf build/' |
| Bash(git push *) | git push origin main | git -C . push origin main |
引用元：Anthropic「Configure permissions」 https://code.claude.com/docs/en/permissions
つまり、denyはコマンドの「書き方」で止める仕組みで、どう書かれても止まるとは限りません。ドキュメントでも、確実に止めたい場合は後で説明するサンドボックスのネットワーク制限と組み合わせるよう勧めています。
MCPのツールをまとめて止める
MCPのツールは「mcp__サーバー名__ツール名」という名前で扱われます。公式ドキュメントによると、denyとaskには "mcp__*" のような書き方ができ、すべてのMCPツールを一度に止められます。
一方、allowで「*」を使う場合は、"mcp__github__get_*" のように、先頭に具体的なサーバー名を書く必要があります。サーバー名の部分に「*」を使ったallowのルールは無視されます。MCPは「読み取りのツールだけをallow」にして、書き込みのツールは毎回確認する形にしておくと安心です。
引用元：Anthropic「Configure permissions」 https://code.claude.com/docs/en/permissions
CLAUDE.mdに書いた禁止事項は「お願い」にすぎない
公式ドキュメントでは、権限のルールはモデルではなくClaude Code自体が強制するもので、プロンプトやCLAUDE.mdに書いた指示は「Claudeが何をしようとするか」に影響するだけで、何が許されるかは変えない、と説明されています。「.envを読まないで」とCLAUDE.mdに書くだけでは不十分で、止めたいことは必ずdenyに書きましょう。
引用元：Anthropic「Configure permissions」 https://code.claude.com/docs/en/permissions
なお、ドキュメントによると、.claudeignoreというファイルを置いても効果はありません。読ませたくないファイルは、Read(./secrets/**) のようなdenyのルールに移してください。
allowはフォルダを信頼したあと、denyとaskはすぐに効く
他人のリポジトリをダウンロードして開くときも、設定が関係します。
公式ドキュメントによると、プロジェクトの .claude/settings.json に書かれたallowルールは、そのフォルダの「ワークスペースの信頼」ダイアログを承認したあとでないと効きません。
引用元：Anthropic「Configure permissions」 https://code.claude.com/docs/en/permissions
ダイアログには、そのフォルダが許可しようとしているルールが一覧で表示されます。一方、denyとaskは制限するだけのルールなので、この影響を受けません。
知らないリポジトリを開いたときは、信頼ダイアログに表示されるallowルールを確かめてから承認しましょう。
どのコマンドを許可し、どこから止めるかは、使い方とリポジトリの中身で変わります。Claude Codeの設定や、作ったアプリの安全性について、LINEで気軽にご相談いただけます。
AIで作ったアプリ・社内ツールのセキュリティ診断
公開して大丈夫か、第三者の目で確認します
- AIで作ったアプリを公開してよいか判断できない
- 社内にセキュリティを見られる担当者がいない
- 鍵やデータベースの権限設定が正しいか確認してほしい
八木（Last Scene）AIで作ったアプリや社内ツールの診断に加えて、取引先からのセキュリティ要求への対応や、インシデント発生時の初動整理もご相談いただけます。
「このまま公開して大丈夫？」の一問からどうぞ。
サンドボックスでOSのレベルの制限をかける
権限のルールは、Claude Codeが「どのツールを使ってよいか」を決めるものです。
サンドボックスは、それに加えて、実行されたコマンドが「どこまで手を伸ばせるか」をOSのレベルで制限する仕組みです。
/sandboxで有効にする
公式ドキュメントによると、サンドボックスは初期設定では無効になっています。
有効にするには、セッションの中で /sandbox を実行するか、~/.claude/settings.json などの設定ファイルで sandbox.enabled を true にします。
引用元：Anthropic「Sandboxing」 https://code.claude.com/docs/en/sandboxing
ファイルとネットワークを隔離する
サンドボックスの中で動くコマンドは、ファイルとネットワークの両方で制限を受けます。
ファイルについては、初期設定で書き込めるのは作業フォルダとその下のフォルダなどに限られます。
ネットワークについては、サンドボックスの中のコマンドはネットワークに直接つながりません。LinuxやWSL2では、ネットワークにつながっていない別のネットワーク名前空間で実行されます。
引用元：Anthropic「Sandboxing」 https://code.claude.com/docs/en/sandboxing
dev containerや仮想マシンで丸ごと隔離する
さらに強く隔離したい場合は、Claude Code全体をdev container（開発用のコンテナ）の中で動かす方法もあります。
公式ドキュメントは、信頼できない内容を扱う場合に、サンドボックスのランタイムやdev containerの中でClaude Codeを動かすことを勧めています。
外部のWebサービスとやり取りする場合などは、スクリプトやツールの実行に仮想マシン（VM）を使うことも挙げられています。
引用元：Anthropic「Security」 https://code.claude.com/docs/en/security
bypassPermissionsのように確認を省くモードを使うのであれば、こうした隔離された環境の中だけにしましょう。
サンドボックスの主な設定項目
サンドボックスは、/sandboxの画面だけでなく、settings.jsonの "sandbox" の中でも設定できます。公式ドキュメントに出てくる主な項目は次のとおりです。
| 設定 | 内容 | 使いどころ |
|---|---|---|
| enabled | サンドボックスを有効にする | まずtrueにする |
| network.allowedDomains | 通信してよいドメインの一覧。最初は空 | npmのレジストリなど、必要な先だけ足す |
| network.deniedDomains | 通信させないドメイン | 特に止めたい先がある場合 |
| filesystem.allowWrite | 作業フォルダ以外で書き込みを許す場所 | ツールが決まった場所に書く必要がある場合 |
| filesystem.denyRead | 読ませない場所 | ~/.sshや~/.awsなど鍵のある場所 |
| allowUnsandboxedCommands | サンドボックスの外での再実行を許すか | falseにすると、外での実行を認めない |
| failIfUnavailable | サンドボックスが使えないときに起動を止めるか | 会社で必須にする場合はtrue |
引用元：Anthropic「Sandboxing」 https://code.claude.com/docs/en/sandboxing
サンドボックスで気をつけたい3つの点
- 読み取りは広く許されている：ドキュメントによると、初期状態では ~/.ssh や ~/.aws/credentials を含め、マシンの大部分を読めます。鍵のある場所はdenyReadに加えてください
- ReadやWebFetchには効かない：サンドボックスが制限するのはBashで動くコマンドです。Claude Code自身のRead・Edit・WebFetchは、権限のルールで制限します。denyReadに書いてもReadツールは止まらないため、Readのdenyルールも必要です
- 使えないときは制限なしで動く：必要な部品がない環境では、初期設定のままだとサンドボックスなしでコマンドが動きます。failIfUnavailableをtrueにすると、その場合は起動を止められます
引用元：Anthropic「Sandboxing」 https://code.claude.com/docs/en/sandboxing
また、サンドボックスの中で失敗したコマンドを、Claudeがサンドボックスの外で再実行しようとすることがあります。ドキュメントでは、allowUnsandboxedCommandsをfalseにするとこの再実行ができなくなり、画面上では「Strict sandbox mode」と表示されると説明されています。
hooksで、危ないコマンドを独自のルールで止める
denyのルールでは書ききれない条件がある場合は、hooks（フック）を使います。hooksは、Claude Codeがツールを使う前後などに、自分で用意したスクリプトを動かす仕組みです。
PreToolUseでツールの実行前に確かめる
公式ドキュメントによると、PreToolUseのフックは、ツールの実行前に動き、実行を止めることができます。ドキュメントの例では、Bashのうち rm で始まるコマンドのときだけスクリプトを動かし、rm -rf が含まれていれば拒否しています。
| 設定の項目 | 例 | 意味 |
|---|---|---|
| hooks.PreToolUse.matcher | "Bash" | Bashツールのときに動かす |
| hooks.type | "command" | スクリプトを実行する |
| hooks.if | "Bash(rm *)" | rmのコマンドのときだけ動かす |
| hooks.command | ${CLAUDE_PROJECT_DIR}/.claude/hooks/block-rm.sh | 動かすスクリプトの場所 |
引用元：Anthropic「Hooks reference」 https://code.claude.com/docs/en/hooks
スクリプトは、Claude Codeから渡される情報（実行しようとしているコマンドなど）を読み取り、拒否する場合はpermissionDecisionに "deny" を返します。また、ドキュメントによると、スクリプトが終了コード2で終わると、その操作は止められます。スクリプトには chmod +x で実行の権限を付けておきます。
引用元：Anthropic「Hooks reference」 https://code.claude.com/docs/en/hooks
hooksを使う場面の例
- 本番のデータベースにつながるコマンドを、決まった人の環境以外では止める
- 「*」を含む削除のコマンドなど、ルールでは許可しにくいものを個別に判定する
- 実行されたコマンドを記録に残す（PostToolUseを使う）
ただし、hooksは自分で書いたスクリプトがそのまま動く仕組みです。リポジトリに入っているhooksは、中身を読んでから使ってください。
チームや会社で設定を統一する方法
1人で使うぶんには自分の設定で十分ですが、チームで使う場合は全員の設定をそろえる必要があります。
公式ドキュメントのチーム向けのベストプラクティスをもとに、統一の方法を紹介します。
.claude/settings.jsonをGitで共有する
いちばん手軽なのは、プロジェクトの .claude/settings.json に権限のルールを書き、Gitでコミットする方法です。
公式ドキュメントも、承認済みの権限の設定をバージョン管理で共有することを、チームのベストプラクティスとして挙げています。
引用元：Anthropic「Security」 https://code.claude.com/docs/en/security
denyは足し算で全員に効くので、「.envを読ませない」「通信のコマンドを止める」といった最低限のルールは、ここに書いておきましょう。
managed settingsで会社として強制する
社員が自分の設定で上書きできないようにしたい場合は、managed settingsを使います。
managed settingsは、managed-settings.jsonというファイル、MDM（端末管理）のポリシー、claude.aiの管理画面から配布するサーバー管理の設定のいずれかで届けられます。
引用元：Anthropic「Settings files and precedence」 https://code.claude.com/docs/en/settings
自分にどのmanaged settingsが効いているかは、/status を実行すると「Setting sources」の行で確認できます。
ログインできる組織を制限する
会社のアカウント以外でClaude Codeにログインされると、会社の管理が届かなくなります。
公式ドキュメントによると、管理者はmanaged settingsに forceLoginOrgUUID を設定して、特定の組織のアカウントでしかログインできないようにできます。
引用元：Anthropic「Authentication」 https://code.claude.com/docs/en/iam
ログインの情報は、macOSでは暗号化されたキーチェーンに保存されます。Linuxでは ~/.claude/.credentials.json に、本人だけが読み書きできる権限（0600）で保存されます。
会話の記録とデータの扱いを確認する
Claude Codeに渡したコードやプロンプトがどう扱われるかも、会社として確認しておきたい点です。
公式ドキュメントによると、Team・Enterpriseプランや、APIなどの商用の条件で使う場合、Anthropicは顧客が提供を選ばない限り、送られたコードやプロンプトを生成モデルの学習に使いません。
Free・Pro・Maxなどの個人向けプランでは、モデルの改善にデータを使うかどうかを利用者が選べ、設定がオンの場合は学習に使われます。
引用元：Anthropic「Data usage」 https://code.claude.com/docs/en/data-usage
また、セッションの記録は初期設定で30日間、~/.claude/projects/ の下に暗号化されないテキストとして保存されます。保存期間は cleanupPeriodDays で変えられます。
法人プランの違いやデータの扱いは、Claudeの法人利用で詳しく解説しています。
/security-reviewで変更をチェックする
設定とは別に、Claude Codeが書いたコードそのものの確認も大切です。
公式ドキュメントでは、今のブランチの変更に対してセキュリティの確認を実行する /security-review が紹介されています。
引用元：Anthropic「Security」 https://code.claude.com/docs/en/security
チームの使い方として、OpenTelemetryのメトリクスで利用状況を監視する方法や、ConfigChangeフックでセッション中の設定変更を記録・ブロックする方法も挙げられています。
チームで最低限そろえたい設定のチェックリスト
- .claude/settings.json に、.envや鍵のファイルを読ませないdenyを書いてGitで共有した
- 通信のコマンドをどう扱うか（denyにするか、askにするか）をチームで決めた
- 個人の settings.local.json に溜まったallowを、月に1回 /permissions で見直している
- 提供元が分からないMCPサーバーは承認しないルールにした
- 会社として強制したい項目は、managed settingsで配布した
Claude Codeのような権限の考え方を、自社の業務用AIエージェントにも取り入れたい場合は、開発のご相談を承っています。
使い方別の設定パターン
どこまで設定を絞るかは、使い方によって変わります。ここでは3つのパターンに分けて、考え方の目安を紹介します。
以下のパターンは、公式ドキュメントの機能をもとに本記事が整理した目安です。会社の方針やリポジトリの中身に合わせて調整してください。
パターン1：個人で試しに使う場合
個人の検証用のリポジトリで使う場合は、Manualモードかautoモードで始め、~/.claude/settings.json に最低限のdenyを書いておけば十分なことが多いです。
最低限のdenyとは、.envや鍵のファイルを読ませないルールです。すべてのプロジェクトに効くように、userの設定に書いておきましょう。
本番のデータベースの接続情報や、会社のアカウントの鍵は、検証用のパソコンに置かないのがいちばん確実です。
パターン2：小さなチームで開発する場合
数人のチームで同じリポジトリを使う場合は、プロジェクトの .claude/settings.json にdenyとaskを書き、Gitで共有します。
テストやlintのように毎日使うコマンドはallowに入れ、通信やデプロイのコマンドはaskにしておくと、確認の手間と安全のバランスが取りやすくなります。
あわせて、サンドボックスを有効にすることもチームのルールとして決めておくと安心です。
パターン3：顧客のデータや本番環境を扱う場合
顧客の個人情報や、本番環境の鍵に触れる可能性がある場合は、さらに一段強い対策を考えましょう。
具体的には、managed settingsでdenyやログインできる組織を強制する、dev containerの中でClaude Codeを動かす、本番の鍵を開発用のパソコンに置かない、といった方法です。
| パターン | 主な設定 | あわせて決めたいこと |
|---|---|---|
| 個人で試す | userの設定にdeny、Manualまたはauto | 本番の鍵を置かない |
| 小さなチーム | .claude/settings.jsonにdenyとask、サンドボックス | 月1回の/permissionsの見直し |
| 顧客データや本番環境 | managed settings、forceLoginOrgUUID、dev container | 誰が設定を管理するか |
万が一、鍵が漏れたかもしれないと気づいた場合は、まず鍵を無効にして作り直すことが先決です。対応の流れは、AIで作ったアプリの公開前セキュリティチェックリストでも紹介しています。
計算例：確認の回数と、許可の広がり方
設定をゆるくしすぎない理由を、簡単な計算例で考えてみます。以下の数字は説明のための仮の例です。
「今後は確認しない」を毎日2回選んだ場合
1日に2回、別々のBashコマンドで「今後は確認しない」を選んだとします。
1か月に20日作業すれば、40個のコマンドが確認なしで実行できる状態になります。Bashコマンドの許可は、リポジトリとコマンドごとに永続するためです。
40個のうち、通信やファイル削除につながるものが1つでも混ざっていれば、それはチームの設定で止めたつもりの操作を、個人の設定で許してしまうことになります。
※本計算例は説明のための仮定の数字であり、実際の件数は使い方によって異なります。
見直しの頻度を決める
この例から分かるのは、許可は「使っているうちに増えていく」ということです。
最初に厳しく設定するだけでなく、/permissions で定期的に減らす運用まで決めておきましょう。
よくある質問
autoモードは安全ですか
autoモードでは、コマンドや通信の前に、別の判定モデルが依頼内容に沿った操作かを確認します。毎回の確認がないぶん作業は速くなります。
ただし、どんな仕組みも完全ではないと公式ドキュメントも書いています。大切なリポジトリでは、denyルールやサンドボックスと組み合わせて使いましょう。
bypassPermissionsは使ってもよいですか
確認をほぼすべて省くモードなので、使うのはdev containerや仮想マシンなど、隔離された環境の中に限るのが安全です。
なお、bypassPermissionsは project や local の設定ファイルに書いても効きません。userかmanagedの設定、または --permission-mode で指定します。
引用元：Anthropic「Settings files and precedence」 https://code.claude.com/docs/en/settings
CursorやCodexでも同じ考え方で使えますか
設定の書き方は道具ごとに違いますが、「読ませたくないファイルを止める」「通信やコマンドの実行に確認を入れる」「チームで設定を共有する」という考え方は共通です。
具体的な設定方法は、それぞれの公式ドキュメントで確認してください。
設定が効いているかは、どう確かめればよいですか
/status を実行すると、どの設定ファイルが読み込まれたかを確認できます。
書き間違いなどで受け付けられなかった設定は、claude doctor を実行すると一覧で表示されます。
引用元：Anthropic「Settings files and precedence」 https://code.claude.com/docs/en/settings
CLAUDE.mdに「.envを読まないで」と書けば十分ですか
十分ではありません。公式ドキュメントでは、CLAUDE.mdやプロンプトの指示はClaudeの行動に影響するだけで、何が許されるかは権限のルールで決まると説明されています。読ませたくないファイルは、Read(./.env) のようなdenyのルールに書いてください。
引用元：Anthropic「Configure permissions」 https://code.claude.com/docs/en/permissions
curlをdenyにすれば、外への送信は止められますか
完全には止められません。公式ドキュメントでは、Bash(curl *) のdenyは /usr/bin/curl や sh -c で包んだ形には一致しないと説明されています。外への通信を確実に絞りたい場合は、サンドボックスのnetwork.allowedDomainsで通信先を限定してください。
引用元：Anthropic「Configure permissions」 https://code.claude.com/docs/en/permissions
サンドボックスとdenyは、どちらか一方で足りますか
役割が違うため、両方使うのがおすすめです。サンドボックスはBashで動くコマンドをOSのレベルで制限し、denyはClaude Code自身のReadやWebFetchなども含めて制限します。公式ドキュメントでも、denyReadはReadツールを止めないと説明されています。
引用元：Anthropic「Sandboxing」 https://code.claude.com/docs/en/sandboxing
まとめ｜止めたいことはdenyに書き、チームで共有する
Claude Codeは、ファイルの読み書き、コマンドの実行、通信ができる強力な道具です。だからこそ、最初に設定を整えておくことが大切です。
ルールは deny、ask、allow の順に判定され、allowやdenyのリストは複数のファイルで足し算になります。
チームでは .claude/settings.json にdenyを書いてGitで共有し、会社として強制したい項目はmanaged settingsで配布しましょう。
まずは「.envを読ませないdeny」を1行書くところから始めましょう！
AIで作ったアプリを公開する前の確認項目は、AIで作ったアプリの公開前セキュリティチェックリストでまとめています。
生成AIを社内で使うときの情報漏洩対策は、生成AIの情報漏洩対策を、AIエージェントの開発費用はAIエージェント開発の費用を参考にしてください。
どの段階で外部の専門家に相談するべきかは、セキュリティ顧問が必要なタイミングで解説しています。
株式会社Last Sceneは、Claude Codeの使い方の見直しから、作ったアプリの公開前診断、公開後の見守りまで、セキュリティ顧問として伴走しています。
「チームの設定をどこまで絞ればよいか分からない」という段階でも、気軽にご相談ください。
Claude Codeの設定から、作ったアプリの公開前診断、公開後の見守りまで、セキュリティ顧問として伴走します。まずはオンライン30分の無料診断からどうぞ。
AIで作ったアプリ・社内ツールのセキュリティ診断
公開して大丈夫か、第三者の目で確認します
- AIで作ったアプリを公開してよいか判断できない
- 社内にセキュリティを見られる担当者がいない
- 鍵やデータベースの権限設定が正しいか確認してほしい
八木（Last Scene）AIで作ったアプリや社内ツールの診断に加えて、取引先からのセキュリティ要求への対応や、インシデント発生時の初動整理もご相談いただけます。
「このまま公開して大丈夫？」の一問からどうぞ。
