Claude CodeをDockerで動かす｜隔離実行の目的・4つの方法・安全な運用の整理

Claude Codeは、ファイルの読み書きやコマンド実行をエージェント自身が行える分、実行環境の隔離をどう考えるかが早い段階で気になるポイントになります。特に--dangerously-skip-permissions（確認プロンプトを省略してコマンドを実行できるオプション）を使う場面では、ホスト環境への影響を心配する人も多いはずです。

この記事は、個人の開発環境でClaude CodeをDockerを使って隔離実行したいエンジニアや技術検証者向けに、隔離が何を防ぎ何を防がないかという考え方の整理から、Dev Container・Docker Compose・単一Dockerfileなど複数の実装方法の比較、OS別のつまずきどころ、最低限のセキュリティ設定、よくあるエラーの切り分け手順までをまとめたものです。読み終える頃には、自分の環境に合った方法でClaude Codeを動かせる状態になっているはずです。

なお、チーム全体の運用ルール統一や企業としての導入判断は本記事の範囲外です。

Claude CodeをDockerで動かす理由｜隔離実行が守る範囲と守らない範囲

Dockerでの隔離実行は、Claude Codeがホストのファイルシステムや認証情報へ直接アクセスすることを防ぐためのものであり、コンテナ内での誤動作そのものを防ぐわけではありません。

--dangerously-skip-permissionsを使うと、Claude Codeはファイルの変更やコマンド実行を確認なしに進められるようになります。これをホストOS上でそのまま使うと、意図しないファイル削除や、~/.sshや~/.awsのようなディレクトリに置かれた認証情報への意図しないアクセスが起こり得ます。コンテナに隔離すれば、こうした影響範囲をコンテナ内部に限定できます。

一方で、コンテナ隔離が防がないものも明確にしておく必要があります。たとえば、コンテナ内で誤って外部APIに不要なリクエストを送る、コンテナにマウントしたディレクトリ内のファイルを書き換える、といった動作はコンテナの中で完結してしまうため、隔離だけでは止まりません。何を防ぎ何を防がないかを分けて理解しておくことが、次の章で方式を選ぶ際の判断軸になります。

実行権限の扱いそのものについてはClaude Code運用ルールの考え方で詳しく整理しています。

Claude Codeを隔離実行する方法にはどんな選択肢があるか（4方式の比較）

Claude Codeの隔離実行には、Dev Container・Docker Compose・単一Dockerfile（docker run）・Claude Code公式の隔離機能という4つの選択肢があり、セットアップ工数と隔離レベルのバランスが方式ごとに異なります。

比較の軸は次の3つです。

セットアップ工数: 導入から動かせるようになるまでの手間
隔離レベル: ホスト環境からどこまで切り離されるか
向いている用途: どんな使い方に合っているか

方式	セットアップ工数	隔離レベル	向いている用途
Dev Container（VS Code連携）	中（`devcontainer.json`を1つ用意）	中〜高（コンテナ単位で隔離、VS Codeと統合）	日常的な開発作業をコンテナ内で完結させたい場合
Docker Compose	中（`docker-compose.yml`が必要）	中〜高（複数サービスを組み合わせる構成に向く）	DBやAPIサーバーなど周辺サービスと一緒に検証したい場合
単一Dockerfile / `docker run`	低（イメージ1つで起動）	中（設定次第で隔離レベルが変動しやすい）	一時的な検証や、最小構成で素早く試したい場合
Claude Code公式の隔離機能	環境依存（要公式ドキュメント確認）	環境依存（要公式ドキュメント確認）	公式のサポート範囲内で完結させたい場合

4つ目の「Claude Code公式の隔離機能」については、名称や提供状況、具体的な隔離方式（OSレベルのサンドボックス機構なのか、コンテナやmicroVMベースなのか）が変更される可能性があるため、この記事では断定を避けます。利用を検討する場合は、Anthropic公式ドキュメントで最新の仕様を確認してください。

日常的に使い続けるならDev Containerが扱いやすく、VS Codeとの連携も含めて情報が整理しやすい方式です。次の章では、このDev Containerを軸に具体的な手順を見ていきます。

最短でDev Container環境を作るにはどうすればよいか（実践手順）

Dev Container環境は、devcontainer.jsonを1つ用意し、VS Codeの拡張機能からコンテナを起動するだけで最短構築できます。

手順は次の順番で進めます。

VS Codeに拡張機能「Dev Containers」を導入する
プロジェクトのルートに.devcontainer/devcontainer.jsonを作成する
VS Codeで「Reopen in Container」を実行し、コンテナを起動する
コンテナ内のターミナルでclaudeコマンドを実行し、認証フローに従ってログインする

最小構成のdevcontainer.jsonは次のとおりです。

{
  "name": "claude-code-dev",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "postCreateCommand": "npm install -g @anthropic-ai/claude-code",
  "remoteUser": "vscode"
}

この構成はあくまで最小限のものです。Node.jsやPythonなど、実際に使う言語のイメージに差し替える、必要な拡張機能をcustomizationsに追加するといった調整は、プロジェクトの内容に応じて行ってください。網羅的な設定例を最初から詰め込むより、動く最小構成から始めて必要な分だけ足していく方が、トラブル発生時の切り分けもしやすくなります。

Claude Code自体のインストール手順や基本操作はClaude Codeの使い方ガイドで扱っています。

OS別のつまずきどころ｜原因の切り分け（Windows/Mac/Linux）

Dev ContainerでClaude Codeを動かす際のつまずきの多くは、Claude Code自体ではなくOSとDockerの組み合わせに起因します。

主な事象は次のとおりです。

Windows（WSL2経由）: ホストとコンテナ間でファイル同期に遅延が生じることがあります。プロジェクトをWindows側のパス（C:\Users\...）ではなく、WSL2のファイルシステム内に置くことで発生しにくくなります。
Windows（パス表記）: devcontainer.jsonやマウント設定にWindows形式のパス（バックスラッシュ区切り）をそのまま書くと、コンテナ内のLinux環境で解釈できずエラーになります。
Mac / Windows共通（Docker Desktop）: Docker Desktopに割り当てるメモリやCPUのリソース設定が少ないと、コンテナの起動や依存パッケージのインストールが極端に遅くなることがあります。
Linux: ホストとコンテナのユーザーIDが一致しない場合、マウントしたディレクトリ内のファイル所有者がずれ、後述する権限エラーの原因になります。

ここでは「これはOSやDockerの設定が原因で起きる事象である」という原因側の整理にとどめます。実際に発生したエラーへの対処手順は、原因を問わない切り分けフローとして次の章で扱います。

最低限おさえるべきセキュリティ設定

Dockerでの隔離実行を意味あるものにするには、非rootユーザーでの実行、認証情報の限定的なマウント、ネットワークアクセスの制限という3点を最低限おさえておく必要があります。

非rootユーザーで実行する: コンテナのデフォルトユーザーをrootのまま使うと、コンテナ内での操作範囲が意図せず広がります。devcontainer.jsonのremoteUserや、DockerfileのUSER命令で非rootユーザーを指定してください。
認証情報は必要な分だけマウントする: ホームディレクトリ全体をコンテナにマウントすると、~/.sshや~/.awsなど本来Claude Codeの作業に不要な認証情報までコンテナ内に持ち込まれます。Claude Codeの作業に必要なディレクトリだけを選んでマウントするか、認証情報は環境変数経由で渡す方法を検討してください。
ネットワークアクセスを絞る: 検証目的であれば、Dockerのネットワーク設定でコンテナの通信先を制限する、あるいは必要な場合のみ外部通信を許可する構成にすることで、意図しない通信のリスクを下げられます。

これらの設定がなぜ必要かという背景は、前述の「隔離実行が守る範囲と守らない範囲」の章で説明した内容が前提になっています。組織としてこれらのルールを標準化したい場合は、Claude Code法人導入のセキュリティガイドで個人設定を超えた検討ポイントを扱っています。

よくあるエラーにはどう対処するか（切り分け手順）

Dev Container環境でのエラーは、原因がOSかDev Container設定かMCP連携かを問わず、まず同じ順番で状況を確認することで多くの場合は原因を絞り込めます。前章のOS別の話とは違い、ここでは「発生した事象からどう調べるか」という手順に絞って整理します。

権限エラーが出る場合: コンテナ内のユーザーとマウント元ディレクトリの所有者が一致しているかを確認します。一致していない場合は、非rootユーザーのUID/GIDを調整するか、マウント元ディレクトリの所有者を変更します。
設定を変更したのに反映されない場合: devcontainer.jsonを変更した後は、コンテナの再ビルド（VS Codeの「Rebuild Container」）が必要です。単なる再起動では反映されません。
認証が失敗する場合: コンテナ内でのログインセッションが切れていないか確認し、claudeコマンドから再度ログインを試します。ホスト側の認証情報をそのまま引き継げない構成になっていないかもあわせて確認してください。
原因がまだ分からない場合: 最小構成のdevcontainer.json（本記事のH2-3で示したもの）で一度切り分け、そこから自分の設定を1つずつ足し戻すと、どの追加設定が原因かを特定しやすくなります。

チーム利用と個人利用の違い

個人の検証環境と違い、チームでdevcontainer.jsonを共有する場合は、設定内容の統一と認証情報の扱いをルール化する必要が出てきます。

たとえば、メンバーごとにマウント設定や環境変数がばらばらだと、同じコードベースでも動作結果が変わってしまうことがあります。また、認証情報をどのように各メンバーの環境に渡すかも、個人利用の延長では済まない論点になります。このあたりの深掘りはClaude Code企業導入ガイドで扱っています。MCP（外部ツールと連携するための仕組み）を使う構成でのガバナンスについては、Claude Code MCPガイドを参照してください。

まとめ

Claude CodeをDockerで動かす際は、まず隔離が何を防ぎ何を防がないかを理解した上で、Dev Container・Docker Compose・単一Dockerfile・公式機能のどれが自分の用途に合うかを選ぶことが出発点になります。個人の検証環境であれば、本記事で示した最小構成のDev Containerから始め、必要に応じて設定を足していくとつまずきにくいはずです。

自分の環境で一通り試してみて、チームでの運用ルール統一に関心が広がった場合は、前章で紹介した企業導入ガイドやMCPガイドが次のステップになります。一人で体系立てて追いたい場合は、AI駆動ラボ（月額1,980円からの学習コミュニティ）に講座があります。