Claude Code はなぜ Docker を推すのか？初心者向け完全ガイド（2026年版）

Claude Code を入れたばかりで公式ドキュメントを開くと、最初のページから devcontainer、Docker、--dangerously-skip-permissions といった語が目に入ります。多くの人が最初に感じるのは「AI にコードを書いてほしいだけなのに、なぜコンテナを学ばないといけないの？」という疑問です。

これは Anthropic が初心者を意地悪にしているわけではありません。Claude Code が通常のコード補完と決定的に違うのは、提案するだけでなく、実際にマシン上でコマンドを実行し、複数ファイルを編集し、依存関係を取得し、テストを走らせる点です。 能力が強いほど、誤操作や権限逸脱のリスクも大きくなります。Docker の役割は、その能力に複製可能な「フェンス」を付けること——本機を守りつつ、チーム全員が同じ環境で動けるようにする——です。

本ガイドは初心者がついていける順序で書いています。まず「なぜ推奨されるか」→ 30 秒で Docker を理解 → 公式 devcontainer の接続方法 → 初回セットアップの手順 → 実は Docker が不要な場面まで。先に DevOps エキスパートになる必要はありません。

ひとことで：Claude Code が Docker を推す理由

核心は次の 3 点にまとまります。

• 隔離：コンテナ内で走るコマンドは、デフォルトではホストの ~/.ssh、クラウド認証情報、個人フォルダに触れません——明示的に mount しない限り。
• 再現性：.devcontainer/devcontainer.json に Node のバージョンや必要な CLI を書いておけば、同僚が clone してコンテナを再構築すれば、あなたと同じ環境になり「こっちでは動くのに」が減ります。
• セキュリティ基線：Anthropic は claude-code リポジトリ で参考 devcontainer を維持しており、デフォルト拒否の送信ファイアウォール（npm、GitHub、Anthropic API などのホワイトリストのみ許可）を備えています。これにより「無人 Agent 実行」がドキュメント上、説明可能な前提を持てます。

公式 Development containers ドキュメント も明快です。dev container は Docker 上で動き、エディタ（Cursor、VS Code、JetBrains など）がコンテナに接続し、ターミナルとビルドツールはコンテナ内で実行され、編集するファイルはローカルリポジトリにマップされます。 Claude Code の CLI もコンテナ内で動きます——「Docker 推奨」の意味は、すべての開発をコンテナに移すことではなく、AI エージェント用の作業区画を切ることです。

完全初心者向け：Docker とは何か？

まず Kubernetes やマイクロサービスは忘れてください。Claude Code 初心者に必要なのは、このたとえだけです。

Docker コンテナ = 軽量で捨てられる「ミニ PC」——OS のスライス、Node/Python、必要なツールが入った箱。本物の PC と CPU を共有しますが、ファイルシステムとネットワークは個別に設定できます。

仮想マシンより起動が速く、占有も小さい。本機に直接ソフトを入れるより、コンテナは削除してもゴミが残らない——Claude が 1 日に 10 種類の依存関係を試すときに特に重要です。

覚えるべき用語は 3 つだけです。

より一般的な Docker の概念は Docker 公式 Get started を参照。本記事は Claude Code の最短ルートに絞ります。

Anthropic 公式 devcontainer の中身

リポジトリ anthropics/claude-code の .devcontainer/ は飾りではなく、複製可能な安全開発テンプレートです。主なファイルの役割は次のとおり。

• devcontainer.json：ボリューム mount、環境変数、VS Code/Cursor 拡張、Claude Code を入れる Feature；
• Dockerfile：ベースイメージ（Debian/Ubuntu など）、開発ツール、非 root ユーザー；
• init-firewall.sh：デフォルト拒否の送信、ホワイトリストのみ許可——自作 Dockerfile で最も漏れやすい部分です。

ドキュメントは Claude Code Dev Container Feature 経由のインストールを推奨しています。devcontainer.json の例：

{
                  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
                  "features": {
                    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
                  },
                  "remoteUser": "node",
                  "mounts": [
                    "source=claude-code-config-${devcontainerId},target=/home/node/.claude,type=volume"
                  ],
                  "containerEnv": {
                    "DISABLE_AUTOUPDATER": "1"
                  }
                }

mounts で ~/.claude に名前付きボリュームを割り当てている点に注意。コンテナ再構築後もログイン状態とセッション履歴を保持でき、毎回認証し直す必要がありません。公式が独立セクションで説明する理由です。

すでに ECC（Everything Claude Code） のような設定集を使っているなら、devcontainer は「ハードウェア層」と考えてください。ECC が skills と hooks を、Docker が Claude コマンドの実際の実行先ファイルシステムを担います。

セキュリティ叙事：なぜコンテナ内で「権限確認スキップ」が語られるのか

Claude Code はデフォルトで bash 実行やファイル書き込みのたびに確認を求めます。CI や長時間の無人タスクでは --dangerously-skip-permissions を付ける人もいます。

公式の立場は明確：このフラグは hardened devcontainer 向けであり、デスクトップ本機向けではありません。 本機で確認をスキップすると、AI がユーザー領域を無制限に操作できる状態になり——ファイル削除、鍵まわりの読み取り、任意 URL への送信が可能です。コンテナ案は少なくとも次を実現します。

• ファイルシステム境界：プロジェクトディレクトリ + 必要な設定ボリュームのみ mount；
• ネットワーク境界：送信ファイアウォールで外部接続先を制限；
• ユーザー境界：非 root 実行、sudo 制限。

ただしコンテナは銀の弾ではありません。 ~/.aws や本番 DB の URL を .env に書いて mount すれば、AI は読めます。安全は mount 内容とリポジトリの信頼性次第。公式原文にも「Only use dev containers when developing with trusted repositories.」とあります。

実践：Docker で Claude Code を初めて動かす

以下は macOS / Windows（WSL2）で検証済みの手順です。Docker 全書を読む必要はありません。

ステップ 1：Docker エンジンをインストール

いずれか 1 つで十分。チーム内で統一するのが重要です。

• macOS：Docker Desktop（最も手軽）；Apple Silicon では Colima、OrbStack も一般的で、CLI は docker 互換；
• Windows：Docker Desktop + WSL2 バックエンド；
• Linux：Docker Engine または rootless Podman（devcontainer CLI の対応を確認）。

インストール後、ターミナルで docker --version と docker run hello-world を実行し、Hello from Docker が出れば OK です。

ステップ 2：プロジェクトと devcontainer 設定を用意

リポジトリルートに .devcontainer/ を作成。方法は次の 2 つ。

1. anthropics/claude-code から参考設定をコピーし、プロジェクト用に Dockerfile を調整；または
2. Cursor / VS Code で Dev Containers: Add Dev Container Configuration Files を実行し、公式ドキュメントに従って Claude Code Feature を追加。

手書きを避けたい場合は、本機に CLI を一度入れたうえで Claude Code に自然言語で依頼してもよいです。「Node 20 プロジェクト用の .devcontainer を生成。Claude Code Feature と pnpm を含めて」——生成後も mount 範囲とファイアウォール設定は必ず人間が確認してください。

ステップ 3：コンテナ内でプロジェクトを開く

Cursor / VS Code：コマンドパレットから Dev Containers: Reopen in Container。初回はイメージ構築に数分かかることがありますが、以降は増分起動が速くなります。プロンプトが変わり、which node がコンテナ内パスを指せば「箱の中」に入っています。

GUI エディタなしのターミナル派も可能です。

# プロジェクトルート、docker-compose.yml がある場合
                docker compose up -d
                docker compose exec dev bash
                claude

サービス名は compose ファイルに従います。devcontainer はこの流れを標準化したものです。

ステップ 4：コンテナ内で Claude Code が動くか検証

コンテナのターミナルで claude を実行し、小さなタスクを試します。例：「package.json の scripts を一覧し、説明して」。確認ポイント：

• ファイル変更がホストの Git ステータスに現れるか（bind mount が正常）；
• cat /etc/os-release がコンテナ OS を示すか（本機バージョンではない）；
• mount していないパスへのアクセスを Claude に試させ、拒否されるか。

3 点すべて期待どおりなら、隔離層は機能しています。以降、チームドキュメントに「Claude Code を使う前に Reopen in Container」と書けば、新人が Node バージョンを個別に揃える必要がなくなります。

実は Docker が不要な場面

公式推奨は強制ではありません。次の場面では本機直実行の方が楽です。

判断の口诀：「離席中も AI にコマンドを自動実行させてよいか？」 よい、かつリポジトリが信頼できる → コンテナ + mount を絞る；よくない → 本機の対話式で十分。

Mac ユーザー向け：Docker と Apple 開発の共存

Xcode と AI 支援フルスタックを Mac で並行する読者は多いです。実務では次の分担が一般的です。

• Xcode、シミュレータ、署名は macOS 本機；
• Node/Python サービス、Claude Code 長セッション、実験スクリプトは devcontainer；
• チームのバックエンド環境を揃えるときは docker-compose.yml をリポジトリに入れ、API をコンテナ内で結合テスト。

Apple Silicon で x86 イメージを走らせると遅いので、arm64 ベースを優先。Docker Desktop にはメモリ 4〜8GB 以上を割り当てると、dev server と Claude の並行実行で swap しにくくなります。

トラブルシューティング早見表

• Rebuild 後に Claude が再ログインを要求：~/.claude が名前付きボリュームに mount されているか確認。コンテナの書き込み層だけだと消えます。
• コンテナから npm / GitHub に届かない：init-firewall.sh のホワイトリストを確認。社内プロキシでは HTTP_PROXY も設定。
• ポート 3000 が開かない：devcontainer の forwardPorts または compose でポートマッピングを宣言。
• Permission denied：remoteUser がプロジェクトディレクトリに書き込めるか。Linux の bind mount では UID 整合が必要なことが多い。
• Docker Desktop が起動しない：Windows は WSL2、Mac は仮想化がセキュリティソフトにブロックされていないか確認。

よくある質問 FAQ

Claude Code と Cursor 内蔵 Agent の両方に Docker が必要？

いいえ。Cursor Agent はデフォルトで本機ワークスペースで動きます。Claude Code は独立 CLI で、公式が devcontainer を第一級でサポートしています。Cursor で編集 + コンテナターミナルで claude という併用も可能です。

devcontainer は VS Code 必須？

必須ではありません。仕様は VS Code 発祥ですが、Cursor、JetBrains、GitHub Codespaces が対応しています。純 docker compose + shell でも動きますが、Reopen in Container の便利さは失われます。

すでに OpenClaw の docker compose デプロイができる——これは重複？

重複しません。デプロイ用 compose は「サービス公開」、devcontainer は「開発時 Claude の実行場所」が目的です。考え方は似ていますが設定の意図が異なります。OpenClaw デプロイ経験は mount とネットワーク理解の助けになります。

コンテナ内の Claude Code はどう更新する？

公式 Feature は最新 CLI を入れ、コンテナ内では自動更新が有効なことが多いです。バージョン固定なら Dockerfile で pin するか、containerEnv で DISABLE_AUTOUPDATER を設定。

会社で Docker Desktop インストールが禁止されている

IT にリモート devcontainer ホスト、GitHub Codespaces、社内 K8s 開発空間があるか確認。Claude Code に必要なのは「隔離された Linux 環境」であり、必ずしもノート PC 上の Docker ではありません。

まとめ：Docker は宿題ではなく Claude Code の「シートベルト」

タイトルに戻ると：Claude Code が Docker を推すのはなぜか？

• AI プログラミング助手が提案だけでなく実行できるから；
• チームが再構築可能な同一環境を必要とするから——スクリーンショットで Node インストールを教える代わりに；
• Anthropic が無人モードをファイアウォール付きコンテナに閉じ込め、~/ 全体に放すのを避けたいから。

初心者を怖がらせる必要はありません。今日やることは 1 つ：小さなプロジェクトで Reopen in Container し、コンテナターミナルで一度 claude を叩き、コマンドがコンテナ内で走り、ファイル変更がホストに現れるのを自分の目で確認する。 ここまでできれば、ドキュメントを読んだだけの人より一歩先にいます。

その後 ECC や MCP を組むとき、Agent を VPS に載せるときも、Docker は AI 時代の「共通インストーラ」になっていく——Claude Code 公式は、それを誰より早く、明確にセキュリティガイドに書き込んだ側です。