Claude Code・Codexを安全に動かす爆速サンドボックス構築ガイド

こんな悩み、ありませんか？

Claude CodeやCodexにコードを書かせるだけでなく、実際に実行まで任せたい。でも「うっかりファイルを消される」「ネットワーク経由で余計な通信をされる」といった不安があって、結局は自分の手元の開発環境でそのまま実行させてしまっている——そんな方は多いのではないでしょうか。

コード実行のたびに内容を目視確認するのは安心ですが、正直かなり面倒です。AIに任せる意味が薄れてしまいます。

この記事でできるようになること

この記事では、Dockerを使った軽量なサンドボックス環境を用意し、その中でClaude Code・Codexにコードを実行させる手順を紹介します。ホスト環境に影響を与えず、かつ仮想マシンのような重い起動を伴わない「爆速」な環境を、コピペで動かせるレベルの具体的なコマンドとともに解説します。

Dockerの基本操作（docker buildやdocker run程度）が分かれば十分です。もし初めて触るという方は、Docker Desktopをインストールしてコマンドが通ることだけ確認しておいてください。

手順1：作業用ディレクトリを用意する

まずはサンドボックス専用のディレクトリを作ります。ここにDockerfileと、AIに触らせたいプロジェクトファイルを分けて配置します。

mkdir -p ~/claude-sandbox/project
cd ~/claude-sandbox

projectフォルダの中にAIが読み書きするコードを置きます。ホスト側の他のディレクトリとは分離されているので、うっかりミスの影響範囲がここに閉じます。

Windows環境でのセットアップについてはこちらも参考にしてください → WSL Containersとは何か？Windows上でLinuxコンテナを動かす新機能の導入手順まとめ

手順2：サンドボックス用のDockerfileを作る

次に、実行環境そのものを定義するDockerfileを作成します。最小限のパッケージだけを入れ、rootユーザーで実行しないことが安全性のポイントです。

FROM node:20-slim

# root権限での実行を避けるため専用ユーザーを作成
RUN useradd -m sandbox
WORKDIR /workspace

# 必要最小限のパッケージのみ導入
RUN apt-get update && apt-get install -y --no-install-recommends git curl \
  && rm -rf /var/lib/apt/lists/*

USER sandbox

ベースイメージはnode:20-slimのように軽量なものを選ぶと、ビルドも起動も速くなります。Pythonが必要な場合はpython:3.12-slimに置き換えてください。

手順3：イメージをビルドする

Dockerfileがあるディレクトリで、以下を実行します。

docker build -t claude-sandbox .

初回はベースイメージのダウンロードがあるので少し時間がかかりますが、以降はキャッシュが効くのでビルドは数秒〜十数秒で終わります。ここが速い理由の一つです。

手順4：コンテナを起動してClaude Codeを動かす

作ったイメージからコンテナを起動し、その中でClaude Code・Codexのコマンドを実行します。ホスト側とやり取りするのはマウントしたディレクトリだけに絞るのが基本です。

docker run --rm -it \
  -v "$(pwd)/project:/workspace" \
  --memory=1g \
  --cpus=1 \
  claude-sandbox bash

--rmをつけることで、コンテナを終了した瞬間に自動で削除されます。--memoryと--cpusでリソースの上限も決めておくと、暴走したプロセスがホストを圧迫する心配がありません。

コンテナのシェルに入ったら、その中でClaude Code・CodexのCLIをいつも通り起動します。実行結果はマウントした/workspaceにしか反映されないため、ホストの他のファイルには一切触れられない状態でコードを動かせます。

コンテナ起動はVMのブートを伴わないため、待ち時間はほぼゼロで済みます。これが「超爆速」と言われる最大の理由です。

Claude Codeの実践活用例をこちらで詳しく解説しています → Claude Codeと論文を書いたら「良い論文」はできた——ただし過程には落とし穴が多かった

手順5：ネットワークを制限してさらに安全にする

何も指定しなければコンテナは自由に外部通信ができてしまいます。完全に通信を止めたい場合は、起動時に次のオプションを追加するだけです。

docker run --rm -it \
  --network none \
  -v "$(pwd)/project:/workspace" \
  claude-sandbox bash

一方で、パッケージのインストールなど一部の通信は許可したいケースもあります。その場合は--network noneにせず、専用のブリッジネットワークとプロキシ（tinyproxyなど）を組み合わせて、許可したいドメインだけを通す構成にする方法があります。ここは正直、最初は設定が少し面倒に感じる部分です。まずは--network noneで完全に遮断しておき、必要になったタイミングで許可リストを追加していく進め方がおすすめです。

APIキーなどのシークレットは、Dockerfileに直接書き込まないことが重要です。.envファイルにまとめて--env-fileオプションで渡すか、本番運用ではDocker Secretsのような仕組みを使うと安全です。

docker run --rm -it \
  --network none \
  --env-file .env \
  -v "$(pwd)/project:/workspace" \
  claude-sandbox bash

手順6：使い終わったら破棄する

--rmをつけていれば通常は自動で消えますが、イメージ自体を作り直したい場合や、動かし忘れたコンテナを一括で片付けたい場合は次のコマンドが便利です。

docker rm -f $(docker ps -aq --filter ancestor=claude-sandbox)
docker rmi claude-sandbox

実行環境を毎回きれいな状態から作り直せるのも、Dockerサンドボックスの大きな利点です。

つまずきやすいポイントと対処

また、マウントしたディレクトリの権限エラーもよく起こります。コンテナ内のユーザーIDとホスト側のファイル所有者が食い違っていると、書き込みができないというエラーが出ます。個人的にはこのやり方が楽でした——docker run実行時に--user $(id -u):$(id -g)を付け加えて、ホスト側のユーザーIDをそのままコンテナに渡す方法です。

まとめ

Claude CodeやCodexにコード実行まで任せたいなら、Dockerによる使い捨てサンドボックスは手軽で効果的な選択肢です。軽量なベースイメージ・--rmでの自動破棄・--network noneでの通信遮断という3つを押さえておけば、まずは十分な安全性が確保できます。

最初から完璧な構成を目指さず、まずは通信を全部遮断した状態から始めて、必要な分だけ穴を開けていくのが安全な進め方です。手を動かしながら、自分のプロジェクトに合った落としどころを見つけていってください。