Claude CodeをDevContainerで安全に動かす完全実装 — sandbox設計と認証情報の遮断

要点

Claude CodeをDevContainer / Docker sandbox内で動かすと、ホストマシンの認証情報や本番接続から物理的に隔離できます。--dangerously-skip-permissions などの強力なフラグを使う際の前提条件として、また企業導入で「Claude Codeが予期せぬ操作をしないことを保証したい」要件で重要な構成です。

本記事は次の3点を扱います。

1. なぜsandboxが必要か(リスクの整理)
2. DevContainerによる実装(VS Code / Cursorで開けるテンプレート)
3. Docker sandboxによる独立実装(CI / 自動化向け)

なぜsandboxが必要か

Claude Codeは Bash ツールでホストの任意コマンドを実行できます。これが強力さの源泉である一方、次のリスクを内包します。

• 認証情報の漏洩: ~/.aws/credentials ~/.ssh/ ~/.gnupg/ 等が見える環境で動かすと、エージェントが意図せずこれらを参照する可能性
• 本番接続の誤操作: kubectl / psql 等のコマンドが本番に向いている環境で DROP TABLE などが入ると致命的
• ホストのファイル削除: rm -rf 系の誤実行
• gitのdestructive操作: force push / branch -D / reset --hard

Claude Codeが期待通りに動かない10シナリオで扱った落とし穴のうち、シナリオ4(危険コマンドの誤実行)の最終防御がこのsandbox設計です。Hookによるブラックリストはバイパスされうるため、コンテナ境界で物理的に隔離するのが最も堅い解です。

DevContainer実装(VS Code / Cursor向け)

.devcontainer/devcontainer.json を置くと、VS Code / Cursorが起動時にコンテナ内で開発環境を立ち上げます。Claude Code自体もコンテナ内で動かせば、エージェントが触れる範囲はコンテナ内に限定されます。

最小構成例

{
  "name": "Claude Code Sandbox",
  "image": "mcr.microsoft.com/devcontainers/typescript-node:20",
  "features": {
    "ghcr.io/devcontainers/features/git:1": {}
  },
  "postCreateCommand": "npm install -g @anthropic-ai/claude-code",
  "customizations": {
    "vscode": {
      "extensions": [
        "anthropic.claude-code"
      ]
    }
  },
  "remoteEnv": {
    "ANTHROPIC_API_KEY": "${localEnv:ANTHROPIC_API_KEY}"
  },
  "containerEnv": {
    "NODE_ENV": "development"
  },
  "mounts": [
    "source=${localWorkspaceFolder},target=/workspace,type=bind"
  ]
}

設計のポイント

• mounts は最小限に: ~/.aws ~/.ssh 等をbind mountしない。Claude Codeに見せないことが最大の防御
• API keyは remoteEnv で渡す: ホスト側のenvを取り込む形にすれば、コンテナimageに焼き込まなくて済む
• postCreateCommandで claude-code をinstall: imageに焼かないことで、バージョン更新が容易
• extensions でClaude Code公式拡張を自動インストール

~/.aws を意図的に渡す場合

クラウド本番に接続するスクリプトをClaude Codeに走らせたい場合、読み取り専用の制限プロファイルだけ渡します。

"mounts": [
  "source=${localEnv:HOME}/.aws,target=/root/.aws,type=bind,readonly"
]

加えて ~/.aws/credentials 内で本番profileを渡さない(別ディレクトリに退避するか、コンテナ用の最小権限profileのみ)構成にします。

Docker sandbox実装(CI / 自動化向け)

CIでClaude Codeを走らせる場合や、複数のセッションを完全に独立させたい場合は、専用Dockerfile + 起動スクリプトで立てます。

Dockerfile例

FROM node:20-bookworm-slim
 
# 必要最低限のツールだけインストール
RUN apt-get update && apt-get install -y --no-install-recommends \
    git \
    jq \
    curl \
    ca-certificates \
    && rm -rf /var/lib/apt/lists/*
 
# Claude Code をグローバルインストール
RUN npm install -g @anthropic-ai/claude-code
 
# 非 root ユーザーで動かす
RUN useradd -m -s /bin/bash claude && \
    mkdir -p /workspace && \
    chown claude:claude /workspace
 
USER claude
WORKDIR /workspace
 
# entrypoint で claude-code を起動
ENTRYPOINT ["claude-code"]

起動スクリプト例

#!/bin/bash
# scripts/run-claude-sandbox.sh
 
set -euo pipefail
 
REPO_PATH="$(git rev-parse --show-toplevel)"
 
docker run --rm -it \
    --name claude-sandbox \
    --network bridge \
    --cap-drop=ALL \
    --cap-add=NET_BIND_SERVICE \
    --read-only \
    --tmpfs /tmp \
    --tmpfs /home/claude/.cache \
    -v "$REPO_PATH:/workspace:rw" \
    -e "ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY" \
    claude-sandbox:latest \
    --dangerously-skip-permissions

セキュリティオプションの意図

• --read-only: コンテナのroot filesystemを読み取り専用に。Claude Codeが任意のファイルを書き換える経路を限定
• --tmpfs /tmp --tmpfs /home/claude/.cache: 一時書き込み領域だけmemory上に。再起動で消える
• --cap-drop=ALL: Linux capabilitiesを全破棄。CAP_SYS_ADMIN 等の特権を渡さない
• -v $REPO_PATH:/workspace:rw: 作業対象ディレクトリのみ書き込み可。それ以外のホストファイルは見えない
• --network bridge: ネットワーク隔離。本番DBが同じネットワーク上にあっても見えない構成にする(必要に応じて --network none で完全遮断)

比較: 3つのアプローチ

認証情報の扱い(三段階の隔離)

DevContainer / sandboxを組んでも、API keyを渡し方を間違えると意味がありません。

段階1: Anthropic API keyの渡し方

段階2: その他の認証情報

~/.aws ~/.ssh ~/.gnupg 等はデフォルトでマウントしない。必要に応じて readonly + 最小権限profileのみ渡す。

段階3: ネットワーク

本番DB / 内部APIへの接続はコンテナのnetwork policyで遮断します。--network none で完全遮断、または専用networkに隔離して本番hostに到達できない構成にします。

チーム導入時の運用ガイド

複数人が同じDevContainer設定を使う場合の追加考慮点:

1. .devcontainer/ をgit管理に: 全員が同じ設定で動かす
2. 開発者ごとのsecretsは個別に: .env.local 等をgit ignoreに追加、各自が用意
3. CIでも同じimageを使う: ローカル / CIの挙動差を最小化
4. 破壊的操作のレビュー基準をCLAUDE.mdに: sandboxがあっても運用ルールは別途必要

まとめ

DevContainer / Docker sandboxは、Claude Codeの能力を失わずに安全性を底上げできる強力な手段です。--dangerously-skip-permissions を安全に使う前提環境としても、企業導入の必須条件としても、設計を初期に詰めておく価値があります。本記事のテンプレートを叩き台に、自分のプロジェクトの認証情報構成や本番接続要件に合わせて調整してください。

関連記事としてHooks実例カタログのレシピ3(危険Bashコマンドのブロック)と組み合わせると、コンテナ境界 + Hookブラックリストの二重防御になります。