Claude Codeのサンドボックスだけでは秘密情報を守れない — 権限ルール・巻き戻しまで含めた安全設定
対象読者: AIエージェントにファイルやコマンドを触らせるのが不安な入門者/権限ルールやサンドボックスで挙動を厳密に制御したい開発者
前提知識: Claude Code がインストール済みであること。それ以外の特別な知識は不要です
この記事でできること: 権限ルール・サンドボックス・巻き戻しの仕組みを理解し、秘密情報を守る最小限の設定を書ける
「AIにファイルやコマンドを触らせるのは、正直こわい。うっかり rm -rf されたら…」Claude Code を使い始めるとき、多くの人が最初にこう感じます。
Claude Code の安全装置は1つではなく何層もあり、重ねてリスクを下げます。ただしどの層も万能ではなく、特にサンドボックスは設定次第で境界が弱くなります。
見落としやすいのが、後半の「外に出させない:サンドボックス」で扱う**「書き込みは狭く、読み取りは広い」という非対称です。サンドボックスをオンにしても、~/.aws/credentials や SSH 鍵のような資格情報**(ログインやアクセスに使う鍵。本記事では秘密情報の一部として扱います)の読み取りは止まりません。
以下は2026年7月3日時点の Claude Code 2.1.199 が前提です(バージョンはほぼ毎日上がるので、番号が違っても読み替えてください)。
まず、これだけ
細かい仕組みは後回しでも、この4つで大きな事故はほぼ防げます。
-
defaultかplanモードで始める(最初から自動承認しない) - 秘密情報の deny を
.claude/settings.jsonに入れる(後述の「秘密情報を守る最小の deny」) - 作業を始める前に
git commitして、いつでも戻れる状態にしておく - macOS・Linux・WSL2 なら
/sandboxの状態を確認する
安全装置の全体像
安全装置は役割の違う層が重なり、操作をやる前に止める層と、万一のときあとから戻す層に分かれます。
権限ルール・保護パス・サーキットブレーカー(危険な操作を止める安全弁)は、何もしなくても最初から効いています。サンドボックスと auto mode は、自分でオンにして足す層です。これらは互いに独立して積み重なり、どれか1つに頼る必要はありません。
壊させない:権限ルール
Claude Code の権限(パーミッション)には「モード」と「ルール」があります。モードはセッション全体の基本姿勢で(plan は計画だけ、acceptEdits は編集を自動承認、など)、Shift+Tab で切り替えられます。基本の6モードは W1 で扱いました。
注意したいのは acceptEdits です。名前の印象より範囲が広く、ファイル編集だけでなく、作業フォルダ(や --add-dir で足したフォルダ)内の mkdir・touch・rm・rmdir・mv・cp・sed などのファイル操作コマンドも自動承認します(保護パスは対象外)。「編集だけ」のつもりが、確認なしにファイルが消えることもあります。
ルールの書き方
ルールは settings.json に書き、Tool(そのツール全部)か Tool(具体指定)(細かい一致)の形を取ります(Bash はコマンド実行、Read はファイル読み取りなど、Claude が使う道具の名前です)。
| ルール | 意味 |
|---|---|
Bash(npm run build) |
このコマンドと完全一致 |
Bash(npm run test *) |
前方一致(* は任意の位置に置け、複数の引数にまたがる) |
Read(./.env) |
カレントディレクトリの .env を読む |
WebFetch(domain:example.com) |
このドメインへの取得 |
評価の順番:deny → ask → allow
ルールには拒否(deny)・確認(ask)・許可(allow)の3種類があり、評価は必ず deny → ask → allow の順で、最初に一致したものが勝ちます。
一番大事なのは、広い deny は具体的な allow に勝つ点です。Bash(aws *) の deny があれば、より細かい Bash(aws s3 ls) の allow を足してもそのコマンドは実行されません。ルールの細かさ(specificity)は順番を変えません。
さらにこの評価は設定スコープをまたいでマージされます。PC 全体(ユーザー)にかける設定と、このプロジェクトだけの設定があり、ユーザー側の deny はプロジェクト側の allow では回避できません。
- 入門者の方: 誰かが引いた deny の線を、あとから allow でくぐることはできません。
- 開発者の方: 「なぜまだ止まるのか」を調べるときは、一番具体的なルールだけでなく全スコープの deny/ask を見ます。
秘密情報を守る最小の deny(コピペ可)
入門者の方に一番おすすめなのがこれです。置き場所は2種類あります。
-
このプロジェクトだけに効かせる → プロジェクト直下の
.claude/settings.json -
どのプロジェクトでも効かせる → ホームの
~/.claude/settings.json
ファイルがなければ新しく作って構いません(.claude フォルダごとでOK)。手で書くのが不安なら /permissions の画面から追加してもよく、保存先は同じ settings.json です。優先順位など詳しくは W1 にまとめました。下の内容だけで、.env や SSH 鍵の読み取りをブロックできます。
{
"permissions": {
"deny": ["Read(.env)", "Read(./secrets/**)", "Read(~/.ssh/**)"]
}
}
この deny が効くのは、Claude の内蔵 Read/Grep/Glob と、Claude Code が認識する Bash の読み取りコマンド(cat・head など)です。一方、Python や Node のスクリプトが自分でファイルを開くような任意のプロセスの読み取りは、この設定では止まりません。そこまで OS レベルで止めるには、後述のサンドボックス(sandbox.credentials)を併用します。
Read(.env) は現在のディレクトリ以下の .env に一致します(Read(**/.env) と同値)。親ディレクトリや別プロジェクトの .env は対象外で、ファイルシステム全体を対象にするなら Read(//**/.env) のように絶対ルート基準で書きます。
保護パス:設定ファイルは勝手に書き換えられない
権限ルールとは別に、保護パス(protected paths)という仕組みがあります。.git や .claude、シェルの設定ファイル(.bashrc・.zshrc など)といった大事なファイルを、bypassPermissions を除くどのモードでも勝手に書き換えさせません。Edit(.claude/**) のような allow ルールを書いても外れません——保護パスのチェックは allow より先に走ります。
代表的な保護対象(一部)です。
- ディレクトリ:
.git,.claude(.claude/worktreesを除く),.vscode,.ideaなど - ファイル:
.bashrc・.zshrc・.profileなどのシェル設定,.npmrc,.gitconfig,.mcp.jsonなど
つまり保護対象を無断で自動承認しない仕組みです。通常モード(default・acceptEdits・plan)では必ず確認が出るので、あなたが承認しない限り書き換わりません。例外は bypassPermissions で、この保護も外れます。
開発者向け:手書きの Bash 許可リストが危ういわけ
-
ワイルドカードの単語境界:
Bash(ls *)(スペースあり)はls -laに一致しますがlsofには一致しません。Bash(ls*)(スペースなし)は両方に一致します。 -
複合コマンドは分解される:
&&・||・;・|などでつないだ各コマンドは、それぞれ独立に一致が必要です。safe-cmd *の許可は、safe-cmd && other-cmdを許可しません。 -
URL をパターンで縛るのは安全境界にならない:
Bash(curl http://github.com/ *)のような指定は、フラグ順・httpsへの差し替え・リダイレクト・シェル変数などで簡単にすり抜けます。公式は、curl/wgetは deny で丸ごと止め、代わりにWebFetch(domain:...)の allow を使うことを勧めています。 - 一部のラッパー(
timeout,time,nice,nohup,stdbuf)は照合前に外されるので、Bash(npm test *)はtimeout 30 npm testにも一致します。一方npx・docker execなどは外されません。
Bash の文字列パターンだけで安全を担保しようとせず、実際の強制は次のサンドボックスに任せます。
外に出させない:サンドボックス
サンドボックス(sandbox)は、Bash ツールとそこから呼び出される子プロセスをOSレベルで隔離する仕組みです。権限ルールが「Claude が操作を試みるか」を制御するのに対し、サンドボックスは「試みても OS が範囲外へ出さない」層で、両者は重ねて使えます。
-
対応OS: macOS は標準機能(Seatbelt)で追加インストール不要。Linux と WSL2 は
bubblewrapとsocatが必要(apt/dnfで導入)。ネイティブ Windows・WSL1 は非対応です。 -
有効化:
/sandboxコマンドでパネルを開いて設定します。
書き込みは狭く、読み取りは広い
サンドボックスの範囲は、書き込みと読み取りで非対称です。
| 既定の範囲 | |
|---|---|
| 書き込み | 作業フォルダとそのサブフォルダ+一時フォルダ($TMPDIR)だけ。~/.bashrc や /bin/ は変更できない |
| 読み取り |
マシンほぼ全体(一部の拒否ディレクトリを除く)。~/.aws/credentials や ~/.ssh/ も既定で読める
|
⚠️ サンドボックスをオンにしただけでは、秘密情報は隠れません。 防げるのは「作業フォルダの外への書き込み」までで、読み取りは広く効いたままです。Bash コマンドから資格情報を読めなくするには、sandbox.credentials を足します。
{
"sandbox": {
"enabled": true,
"credentials": {
"files": [{ "path": "~/.aws/credentials", "mode": "deny" }],
"envVars": [{ "name": "GITHUB_TOKEN", "mode": "deny" }]
}
}
}
組み込みの資格情報ブロックリストはなく、自分で列挙したファイル・変数だけが守られます。ただし sandbox.credentials が効くのはサンドボックス化された Bash コマンドに対してだけです。内蔵 Read ツールが同じファイルを読むのは、権限ルールの permissions.deny(例: Read(~/.aws/credentials))で別途止めます。
ネットワークと、正直な限界
-
ネットワーク: 既定で許可ドメインはなく、新しいドメインへの初回アクセスで確認が出ます(
allowedDomains/deniedDomainsで設定)。ただし通信の中身までは検査しないので、許可ドメインを広げすぎないのが安全です。 -
除外が要るもの:
dockerはサンドボックスと相性が悪く、excludedCommandsでの除外が必要です。
なお bubblewrap などの依存が足りない環境や非対応環境では、サンドボックスは既定で警告を出したうえで、隔離なしにコマンドを実行します。常にサンドボックス経由を強制したいときは、次の設定を使います。
開発者向け:サンドボックスを厳格ゲートにする
隔離なし実行にフォールバックさせず、コマンドを必ずサンドボックス経由にする管理者向けの設定です。
{
"sandbox": {
"enabled": true,
"failIfUnavailable": true,
"allowUnsandboxedCommands": false
}
}
failIfUnavailable を true にすると、サンドボックスを起動できないときはコマンドを実行せずエラーにします。allowUnsandboxedCommands を false にすると、/sandbox の Overrides タブで「Strict sandbox mode」と表示され、コマンドは必ずサンドボックス経由(または excludedCommands に明示したもの)で実行されます。
開発者向け:TLS 非検査とドメインフロンティングのリスク
既定の内蔵プロキシは外向き通信の TLS を復号・検査せず、接続先をクライアントが名乗ったホスト名だけで判断します。そのため広いドメイン(例: github.com)を許可すると、理論上はドメインフロンティング(別の許可ドメインを装って実際は別の宛先へ迂回する手口)ですり抜けられる余地が残ります。allowedDomains は「通信の中身を見て止めるフィルタ」ではありません。Anthropic はより強い TLS 対応の隔離を「開発中の領域」としています。
勝手に進ませない:auto mode の審査役
auto モードは名前に反して「なんでも自動実行」ではありません。実際は**別の審査用モデル(classifier)**が実行前に一つひとつの操作をチェックする research preview(試験提供)で、依頼の範囲を超えて影響が広がる操作を既定でブロックします。以下は開発でよく使う操作なので、ピンとこなければ読み飛ばして大丈夫です。
既定で止める操作の例:
-
curl | bashのような取得即実行 - 本番へのデプロイやマイグレーション
-
mainへの push や force-push -
git reset --hardやterraform destroyのような破壊的な操作
既定で通す操作の例:
- 作業フォルダ内のローカルなファイル操作
- 宣言済み依存のインストール
.envを読んで、対応する API に送ること
⚠️ 最後の1つが要注意です。auto mode をオンにしても、既定では秘密情報は守られません。 サンドボックスと同じく、.env を守りたいなら deny ルールが別途必要です。
- 審査役が3回連続、または合計20回操作を止めると、auto mode は一時停止して通常の確認プロンプトに戻ります(この閾値は変更できません)。
- 会話で伝えた制約(例:「まだ push しないで」)は強い停止シグナルとして効きますが、ルールとして保存はされません。会話が長くなったときの要約(コンテキストの圧縮=compaction。自動または
/compactで起きる)で、その一文が失われることがあります。確実に守らせたいなら deny ルールにします。
なお最も緩い bypassPermissions でも、rm -rf / や rm -rf ~ のようなルート/ホーム直下の削除は必ず確認が出ます(モデルの誤りに対する安全弁)。この基本的なサーキットブレーカーは W1 で扱いました。auto mode は、それより広く新しい審査を上乗せする層です。公式もこれを「確認プロンプトは減らすが、安全を保証するものではない」research preview と位置づけています。
auto mode の対応モデル・プロバイダについて
対応するモデルやプロバイダ、既定でブロックされる操作のカテゴリは、バージョンごとに頻繁に増減します。数週間で古くなる情報なので、ここには一覧を載せません。最新の対応状況は公式の Permission Modes で確認してください。ブロック/許可の既定ルール全体は、claude auto-mode defaults で JSON として出力できます。
戻す:止める・巻き戻す、そして git
やってしまってからでも、取り戻す手段があります。
Esc で止める
実行中に Esc を押すと、その場で操作を中断できます。ここまでの作業は保持され、方向を修正して続けられます。中断であって、変更を元に戻すわけではありません。
Esc Esc / /rewind で巻き戻す
入力欄が空の状態で Esc を2回押すか、/rewind(別名 /checkpoint・/undo)と打つと、巻き戻し(rewind)メニューが開きます。プロンプトごとにチェックポイントが自動作成されていて、そこへ戻せます。選択肢は次のとおりです。
- コードと会話を両方戻す
- 会話だけ戻す(コードはそのまま)
- コードだけ戻す(会話はそのまま)
- ここから要約 / ここまで要約
- 何もしない
(入力欄に文字が残っているときの Esc Esc は下書きを消すだけで、巻き戻しメニューは開きません。)
巻き戻せないもの:本当の安全網は git
⚠️ 巻き戻しには重要な限界があります。Bash コマンドで変更したファイルは追跡されません。 Claude が Bash ツールで rm file.txt や mv old new を実行しても、巻き戻しでは元に戻せません。追跡されるのは組み込み編集ツール(Edit/Write)による変更だけです。
公式もチェックポイントを「ローカルな取り消し」、git を「恒久的な履歴」と表現しています。だからこそ、こまめな git コミットが本当の安全網になります(git が初めてなら、この機会に触れてみる価値があります)。
早見表
安全運用でよく使うコマンドをまとめます。
スラッシュコマンド
| コマンド | 用途 |
|---|---|
/permissions |
権限ルール(allow/ask/deny)をスコープ別に確認・追加・削除 |
/sandbox |
サンドボックスの切り替え・設定 |
/rewind |
巻き戻しメニューを開く |
/doctor |
インストールや設定を診断(f で自動修正) |
/add-dir <path> |
このセッションで参照できるフォルダを追加 |
CLI フラグ(起動時)
| フラグ | 用途 |
|---|---|
--permission-mode <mode> |
起動モードを指定(plan など) |
--add-dir <path> |
参照フォルダを追加して起動 |
--allowedTools / --disallowedTools
|
セッション限定の allow / deny ルール |
--settings <path> |
このセッションだけ設定を上書き |
--dangerously-skip-permissions |
bypassPermissions 相当(root/sudo では拒否) |
キーボードショートカット
| キー | 効果 |
|---|---|
Esc |
実行中の操作を中断(作業は保持) |
Esc Esc(空入力) |
巻き戻しメニューを開く |
Shift+Tab |
権限モードを循環(default → acceptEdits → plan。有効化した他モードも加わる) |
よくある誤解 / 守備範囲
| 誤解しやすい点 | 実際の守備範囲 |
|---|---|
| サンドボックス=秘密情報の境界 | 書き込みは狭いが読み取りは広い。資格情報も既定で読めます |
Read(.env) はどこの .env にも効く |
カレントディレクトリ以下のみ。親・別プロジェクトは対象外 |
sandbox.credentials で読み取りは全部止まる |
サンドボックス化された Bash 専用。内蔵 Read は permissions.deny で別途 |
| 巻き戻しで何でも戻せる | Bash で変えたファイルは戻せない → git コミット |
acceptEdits は編集だけ |
作業フォルダ内の rm・mv なども自動承認 |
まとめ
入門者の方へ
- 安全装置は何層も重なっています(モード・ルール・保護パス・サンドボックス・サーキットブレーカー・巻き戻し)。どれか1つに頼らなくて大丈夫です。
-
.git・.claude・シェル設定はbypassPermissions以外のどのモードでも保護され、あなたが承認しない限り書き換わりません。 -
Escで止まり、Esc Escで戻せます。ただし Bash で消したものは戻らないので、こまめな git コミットが本当の安全網です。
開発者の方へ
- 権限ルールは全スコープをマージし deny が最優先。想定外のブロックは全スコープを見ます。
- Bash の文字列パターンは安全境界になりません。複合コマンドやラッパーですり抜けるので、強制はサンドボックスに任せます。
-
サンドボックスも auto mode も、既定では秘密情報を守りません。 しかも守る対象が違い、内蔵 Read は
permissions.deny、サンドボックス化 Bash はsandbox.credentialsで両方を併用します。
次の一歩です。
- 入門者の方:
defaultのまま、必要なら plan モードで計画を確認し、git をこまめにコミット。巻き戻しの存在を知っておくだけでも安心が違います。 - 開発者の方: 上の secrets deny スニペットを
settings.jsonに入れ、対応OS(macOS/Linux/WSL2)なら/sandboxを試してみてください。
参考リンク
- Permissions — 2026-07-03 確認
- Permission Modes — 2026-07-03 確認
- Sandboxing — 2026-07-03 確認
- Security — 2026-07-03 確認
- Checkpointing — 2026-07-03 確認
- Interactive Mode — 2026-07-03 確認
- Commands Reference — 2026-07-03 確認
- CLI Reference — 2026-07-03 確認