Claude Codeに作業を頼むたび、ファイルの読み取りやコマンドの実行で権限確認が出て止まる。画面の下半分が確認ダイアログで埋まって、作業のテンポが何度も途切れる。DevContainerという仕組みを使うと、Claude Codeが動く場所を独立した空間に隔離できる。権限確認が大きく減り、手元のファイルも守りやすくなる。
この記事でやること
Windows上でDevContainerを1つ作り、その中でClaude Codeを起動して動作を確認するまでを案内する。
ざっくり次の流れで進める。
devcontainer.jsonを1つ書く- VS Codeからコンテナを起動する
- コンテナ内でClaude Codeを動かす
- 動作確認する
やらないこととして、Dockerの仕組みの詳しい解説や、複数コンテナを組み合わせた構成は扱わない。まずは最小構成を1つ確実に動かすことに集中する。
前提条件とDevContainerの全体像
始める前に、手元の環境が揃っているか確認しておく。
- WSL 2が有効 — 管理者権限でPowerShellを開き、
wsl --statusを実行して既定のバージョンが2になっていればOK - 仮想化が有効 — タスクマネージャーの「パフォーマンス」タブに「仮想化: 有効」と表示されていれば問題ない
- Docker Desktopがインストール済みで起動している —
docker --versionでバージョンが返ってくれば動いている - VS Codeがインストール済み — 拡張機能「Dev Containers」を追加で入れておく(拡張機能タブで「Dev Containers」と検索してインストール)
- Claude Codeを使えるアカウントまたは認証手段がある — 初回起動時にコンテナ内で認証するため、ログイン済みかどうかよりも、認証できる状態かを確認しておく
Docker Desktopをインストールした直後は、PCの再起動が必要なことがある。再起動後にDocker Desktopを起動し、左下に「Engine running」の表示が出ていることを確認してから次に進むとスムーズだ。
前提条件が揃っているなら、DevContainerの仕組みだけ押さえておけばいい。
DevContainerは、VS Codeの中で動く「独立した作業部屋」のようなものだ。普段のWindows環境とは切り離された空間で、指定したフォルダだけを読み書きできる。Claude Codeにとってのメリットは2つ。ファイルアクセスの範囲が限定されることと、権限確認が減ること。
全体の階層をざっと見ると次のようになる。
Windows
└── Docker Desktop
└── VS Code
└── DevContainer(Ubuntu + Node.js)
└── Claude Code
Docker Desktopが土台になり、その上でVS Codeがコンテナを動かす。Claude Codeはコンテナの中で動く。ただし、VS Codeで開いた作業フォルダはコンテナに共有されるため、そのフォルダ内のファイル変更はWindows側にも反映される。作業フォルダの外にあるファイルへ触りにくくなる、という理解が近い。
手順:DevContainerを作ってClaude Codeを動かす
メインルートは1本だけ。番号順に進めれば、迷わず確認しやすい。
Step 0: 作業用フォルダを用意する
どこでもいいので、作業用のフォルダを1つ作る。例えばエクスプローラーでC:\Users\ユーザー名\devcontainer-testを作る。
Step 1: フォルダをVS Codeで開く
VS Codeを起動し、「ファイル → フォルダーを開く」で先ほどのフォルダを開く。中身は空で構わない。
Step 2: .devcontainer/devcontainer.jsonを作成する
VS Codeのエクスプローラーで.devcontainerフォルダを作り、その中にdevcontainer.jsonを新規作成する。次の内容を貼り付ける。
{
"name": "claude-code-dev",
"image": "mcr.microsoft.com/devcontainers/base:ubuntu",
"features": {
"ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
},
"remoteUser": "vscode"
}
このテンプレートのポイントを3つ挙げておく。
"image"で、ベースとなるUbuntu環境を指定している"features"で、Anthropic公式のDevContainer Featureを使ってClaude Codeを自動インストールしている"remoteUser"で、コンテナ内の操作ユーザーを指定している
Step 3: コマンドパレットからコンテナを起動する
Ctrl + Shift + Pでコマンドパレットを開き、「Dev Containers: Open Folder in Container…」と入力して選ぶ。現在開いているフォルダがコンテナ内で開き直される。
Step 4: コンテナがビルドされるのを待つ
初回はDockerイメージのダウンロードが走る。ネットワークの状況によっては5〜10分かかることもあるが、これは異常ではない。プログレスバーが動いていればそのまま待つ。
ここで「止まったかな?」とキャンセルして再度実行すると、最初からやり直しになって余計に時間がかかる。バーが動いている限りは待つのが一番早い。
ビルドが終わると、VS Codeの左下に「Dev Container: claude-code-dev」と表示が変わる。これがコンテナ接続の合図だ。
Step 5: コンテナ内でClaude Codeを起動する
VS Codeのターミナル(Ctrl + @)を開き、次のコマンドを実行する。
claude
初回起動時は認証画面が出る。コンテナ内からブラウザを開けない場合、ターミナルに表示されたURLをWindows側のブラウザに貼り付けて認証を完了させる。認証コードもターミナルに表示されるので、ブラウザ側に入力する。
Claude Codeのプロンプト(>)が表示されれば起動成功。
動作確認と次のステップ
ターミナルのプロンプトがvscode@xxxxx:/workspaces/devcontainer-test$やvscode ➜ /workspaces/devcontainer-testのように表示され、ユーザー名がvscodeになっていればコンテナ内で動いている。VS Codeの左下も「Dev Container: claude-code-dev」となっているはずだ。
次に、Claude Codeが応答することを確かめる。プロンプトで簡単な依頼を1つ試してみよう。
> 「Hello World」と表示するPythonスクリプトを作って
ファイルが作られて実行結果が返ってくれば、動作確認は完了。
ここまでで、DevContainerの中でClaude Codeが動く最小構成が1つできた。
初めてDevContainerを使う場合は、この段階で--dangerously-skip-permissionsなしでも十分試せる。普段のClaude Codeとの違いを感じるために、いくつか作業を頼んでみてほしい。権限確認が出る回数がローカル環境とどう変わるか、自分の目で確かめられる。
権限確認が減る実感ができたら、次はclaude --dangerously-skip-permissionsを試してみる。コンテナ内であれば、ファイルアクセスが開いたフォルダに限定されているため、安心感が違う。
この最小テンプレートで1つコンテナを動かし、自分の目で動作を確かめてみてほしい。動くことが確認できれば、あとはdevcontainer.jsonを書き換えて好みの環境に育てていける。公式のDevContainerリファレンスやAnthropicのDevContainer Featureの配布ページも併せて見ると、カスタマイズの幅が広がる。
+α:コンテナのさらに便利な使い方
DevContainer内では、Claude Codeが見えるファイルの範囲が変わる。
開いた作業フォルダ(ここではdevcontainer-test)だけがコンテナにマウントされる。フォルダの外にあるC:\Users\ユーザー名\DocumentsなどのWindows領域には、Claude Codeからアクセスできない。
この隔離された環境でclaude --dangerously-skip-permissionsを使うと、権限確認の回数が大きく変わる。
実際に試した体感では、次のような違いが出る。
| 環境 | 5つの操作を頼んだ時の権限確認回数(体感) |
|---|---|
| ローカル(権限確認あり) | 3〜4回 |
| DevContainer内(権限確認あり) | 1〜2回 |
| DevContainer内+`–dangerously-skip-permissions` | 0回に近い ※通常操作での体感。保護されたパスや特殊な操作では確認が出る可能性がある |
ローカルでは、ファイルの読み取りやコマンド実行のたびに確認プロンプトが出る。DevContainerに入るだけでもファイルアクセスが限定されるため、確認回数が減る。--dangerously-skip-permissionsを組み合わせると、通常のファイル編集やコマンド実行では権限確認が大きく減る。ただし、保護されたパスへの書き込みでは確認が残る場合があり、安全チェックを完全に任せられる状態になるわけではない。
ただし--dangerously-skip-permissionsは名前の通り「権限確認をスキップする」オプションで、コンテナ隔離があったとしても万能ではない。信頼できるリポジトリで使うのが前提になる。初めはオプションなしで試して、権限確認が減る実感ができてから使うのがいい。
コンテナ隔離は安全寄りの工夫だが、完璧な防御ではない。ネットワーク通信はコンテナからも出られるため、外部へのデータ送信を完全に防ぐには追加の設定が必要になる。とはいえ、ファイルアクセスの範囲を限定できるだけでも、ローカルで直に動かすより安全な状態になる。
+α:うまくいかない時の対処法
環境構築でよく遭遇するエラーをいくつか挙げておく。
Docker Desktopが起動していない
docker: error during connect: This error may indicate that the docker daemon is not running.
PCを再起動した直後によく出る。Docker Desktopを手動で起動して、「Engine running」の表示を待ってから再度コンテナを開く。
WSL 2が無効になっている
管理者権限のPowerShellで次のコマンドを実行する。
wsl --install
インストール後はPCの再起動が必要になる。
コンテナのビルドが失敗する
ネットワークの問題か、ディスク容量不足の可能性が高い。Docker Desktopの設定でディスクの割り当て容量を確認する。プロキシ環境下ではDocker Desktopのプロキシ設定も見直す必要がある。
コンテナ内でClaude Codeがインストールされていない
Featureによる自動インストールが失敗した場合、ターミナルで手動インストールを試す。
npm install -g @anthropic-ai/claude-code
VS Codeがコンテナを認識しない
Dev Containers拡張機能が入っているか確認する。入っているのに認識しない場合は、VS Codeを一度閉じて開き直すと直ることがある。
どのエラーでも、VS Codeの出力パネル(「表示 → 出力」)で「Dev Containers」を選ぶと詳しいログが見れる。エラーメッセージをそのまま検索すれば解決策が見つかりやすい。
