---
title: "VS Codeで開発コンテナを作る（Create Dev Container）｜devcontainer.jsonの書き方・root実行・複数コンテナ"
url: "https://www.issoh.co.jp/tech/details/9565/"
published: 2025-10-29
updated: 2026-10-18
categories: ["Kubernetes・コンテナ"]
publisher: "株式会社一創"
---

# VS Codeで開発コンテナを作る（Create Dev Container）｜devcontainer.jsonの書き方・root実行・複数コンテナ

VS Codeの開発コンテナ（Dev Container）は、プロジェクトに置いた`.devcontainer/devcontainer.json`をもとにDockerコンテナを立て、その中でターミナル・デバッガ・拡張機能を動かす仕組みです。この記事では、開発コンテナを実際に作る手順に絞り、devcontainer.jsonの書き方、rootで動かす設定、ライフサイクルコマンドが走る順番と回数、Docker Composeでの複数コンテナ、VS Codeを使わずに作るDev Container CLIまでを扱います。

挙動の説明は、2026年10月18日時点の拡張機能Dev Containers 0.469.0の公式ドキュメントと、Dev Container CLI 0.89.0をColima上のDocker 29.5.2で実行した結果にもとづきます。開発コンテナの仕組みやDockerとの違い、導入メリットは[Dev Container（devcontainer）のメリットとは｜Dockerで開発環境を統一する仕組みと設定【2026年版】](/tech/details/3728/)で解説しています。

## まとめ：Create Dev Containerの要点

- 作り方の基本は、フォルダを開いてコマンドパレット（F1）で「Dev Containers: Add Dev Container Configuration Files…」を実行し、テンプレートを選んで「Dev Containers: Reopen in Container」で入る流れです。
- devcontainer.jsonの最小構成は`image`の1行です。ツールの追加は`features`、ビルドキャッシュを効かせたいならDockerfile、DBなど複数サービスはDocker Composeを使います。
- rootで作業したいだけなら`"remoteUser": "root"`で足ります。コンテナ全体の実行ユーザーまで変えるのは`containerUser`です。
- `postCreateCommand`は作成時に1回だけ、`postStartCommand`は起動のたび、`postAttachCommand`は接続のたびに走ります。依存の導入は`postCreateCommand`、起動ごとの初期化は`postStartCommand`に置き、サーバーの常駐プロセスはターミナルやタスクから起動します。
- VS Codeを閉じるとコンテナは停止し、削除はされません。設定を変えたら「Rebuild Container」で作り直します。
- Featuresの`:1`のようなメジャー指定は、そのメジャー内の最新に止まります。node featureは`:1`だと1.7.1で、最新の2.1.1は入りません。

## 開発コンテナを作る前提：Docker・拡張機能・対応環境

必要なのは、Dockerが動く環境とVS Codeの拡張機能「Dev Containers」（ID：`ms-vscode-remote.remote-containers`）の2つです。拡張機能は2026年10月18日時点の安定版が0.469.0（2026年9月8日公開）で、VS Code 1.101以上を要求します（[Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers)）。

[公式ドキュメントのシステム要件](https://code.visualstudio.com/docs/devcontainers/containers)は、WindowsとmacOSではDocker Desktop 2.0以上、LinuxではDocker CE/EE 18.06以上とDocker Compose 1.21以上を挙げ、Ubuntuのsnap版Dockerは非対応としています。Windowsコンテナイメージも対象外です。Windows 10 HomeはDocker Desktop 2.3以上とWSL 2バックエンドが要ります。WSL上のフォルダを開く手順は[WSLで開発環境を構築する手順｜.wslconfig調整とDocker連携・肥大化の対処](/tech/details/17354/)にまとめています。

Docker Desktop以外の選択肢について、[公式ドキュメントの代替手段のページ](https://code.visualstudio.com/remote/advancedcontainers/docker-options)は、macOSのColima（0.2.2以上を推奨）やRancher Desktopで拡張機能を使えると説明しつつ、Docker互換のCLI全般は公式サポートの対象外と書いています。拡張機能の設定`dev.containers.dockerPath`（既定は`docker`）は説明に「Docker (or Podman or WSLc)」とあり、PodmanなどのCLIへ差し替えられます。この記事の検証はDocker Desktopを入れずに、ColimaのDockerソケットへ`DOCKER_HOST`を向けて行いました。Colimaの導入は[Colimaとは？MacでDocker Desktopを外す導入手順と設定の落とし穴【0.10系】](/tech/details/17842/)、Apple製の軽量ランタイムは[Apple container（apple/container）とは？1.5系の使い方とDockerとの違い・compose代替とGUIの現状](/tech/details/7219/)を参照してください。Apple containerについては、0.469.0に「Attach to Running Apple Container…」が入っていますが、設定`dev.containers.experimentalAppleContainerSupport`（既定はfalse）を有効にして使う実験的な機能で、できるのは起動済みコンテナへの接続です。devcontainer.jsonからApple containerでコンテナを作る機能ではありません。

## 開発コンテナを作る手順：コマンドパレットの3つの入口

VS Codeから開発コンテナを作る入口は、手元のフォルダから作るか、リポジトリから直接作るかで分かれます。失敗したときの逃げ道も用意されています。

### 既存フォルダから作る：Add Dev Container Configuration Files

1. プロジェクトのフォルダをVS Codeで開きます。
2. コマンドパレット（F1）で「Dev Containers: Add Dev Container Configuration Files…」を実行し、言語やツールのテンプレートを選びます。続いてFeatures（追加ツール）の一覧が出るので、必要なものにチェックを入れます。
3. 生成された`.devcontainer/devcontainer.json`を確認し、「Dev Containers: Reopen in Container」を実行します。初回はイメージの取得とビルドが走ります。

設定を編集してから入る場合はこの順番、すぐ入りたい場合は「Dev Containers: Open Folder in Container…」でフォルダを選ぶと、テンプレート選択からコンテナ起動まで一度に進みます。ローカルの表示に戻すときは「Dev Containers: Reopen Folder Locally」です。0.469.0には「Add Dev Container Configuration Files using GitHub Copilot…」というコマンドもあり、テンプレート一覧から選ぶ代わりにGitHub Copilotに設定ファイルを作らせる入口になっています。

### リポジトリから直接作る：Clone Repository in Container Volume

「Dev Containers: Clone Repository in Container Volume…」は、リポジトリをホストのフォルダではなくDockerボリュームへクローンし、そのまま開発コンテナで開きます。リポジトリにdevcontainer.jsonが無ければテンプレートの選択に進みます。macOSやWindowsではバインドマウントよりファイルアクセスが速いことが公式ドキュメントに書かれている一方、ソースがホストのフォルダに無いので、ホスト側のエディタやGUIツールから直接は開けません。

### ビルドに失敗したとき：Reopen in Recovery Container

Dockerfileのビルドエラーなどでコンテナが立ち上がらないと、ダイアログに「Reopen in Recovery Container」が出ます。これを選ぶと、Dockerfileなどを編集するための復旧用コンテナに入れます。直したら「Rebuild Container」で作り直します。

## devcontainer.jsonの書き方：image・Dockerfile・features

### 最小構成はimageの1行

devcontainer.jsonは`.devcontainer/devcontainer.json`か、プロジェクト直下の`.devcontainer.json`に置きます。最小構成は`image`だけです。以下はポート転送と依存導入も加えた例で、プロジェクト直下に`requirements.txt`があることを前提とします。ファイルがない場合は`postCreateCommand`の行を削除してください。

```
{
  "name": "my-project",
  "image": "mcr.microsoft.com/devcontainers/python:3.14-trixie",
  "forwardPorts": [8000],
  "postCreateCommand": "pip install --user -r requirements.txt"
}
```

`forwardPorts`はコンテナ内のポートをホストの`localhost`へ通す設定、`postCreateCommand`はコンテナ作成後に1回だけ走るコマンドです。VS Code向けの拡張機能や設定は`customizations.vscode.extensions`と`customizations.vscode.settings`に書きます。

### Dockerfileに切り替える条件

公式ドキュメントは、`postCreateCommand`よりDockerfileのほうがDockerのビルドキャッシュが効いて再ビルドが速いと説明しています。ただしDockerfileはワークスペースをマウントする前に実行されるので、ソースツリー内のファイル（`requirements.txt`や`package.json`）はマウント経由では読めず、使うにはビルドコンテキストに含めて`COPY`で取り込む必要があります。OSパッケージや言語ランタイムはDockerfile、ソースを書き換えるたびに入れ直す`npm install`などは`postCreateCommand`、と分けるのが基準です。

```
{
  "name": "custom-build",
  "build": {
    "dockerfile": "Dockerfile",
    "context": ".."
  }
}
```

Dockerfileそのものの書き方は[Dockerfileとは｜書き方・主要命令・ベストプラクティスを解説【2026年版】](/tech/details/3315/)で扱っています。

### Featuresでツールを足す：メジャー版の固定に注意

Featuresは、Node.jsやGitHub CLI、Docker CLIなどを宣言だけでコンテナに入れる仕組みです。公式のFeaturesはGitHubの[devcontainers/features](https://github.com/devcontainers/features)にあり、2026年10月18日時点で`node`・`python`・`docker-in-docker`・`copilot-cli`など28種類です。

```
{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/devcontainers/features/node:2": { "version": "lts" }
  }
}
```

見落としやすいのが末尾の`:1`や`:2`です。これはFeature自体のメジャー版の指定で、そのメジャー内の最新に解決されます。`node:1`で作ったコンテナに対して`devcontainer outdated`を実行すると、次のように出ました。

```
Feature                              Current  Wanted  Latest
ghcr.io/devcontainers/features/node  1.7.1    1.7.1   2.1.1
```

`node:1`のままでは、2.0.0（2026年4月28日）で入った`npmVersion`オプションなど2系の変更は入りません。入るNode.js本体は`version`オプションで決まり、`"lts"`指定で24.22.0でした。Featureを足したビルドには、この環境で約2分かかりました。

Dev Container CLI 0.89.0でコンテナを作ると、`.devcontainer/devcontainer-lock.json`が自動で生成され、Featureの版とダイジェストが記録されました。VS Code側でロックファイルが既定で作られるようになった経緯は[VS Code 1.118の新機能｜codebase semantic index・devcontainer-lock.json・Copilot設定の変更点](/tech/details/12043/)で扱っています。チームで同じ版を使うなら、ロックファイルもリポジトリにコミットします。

## remoteUserとcontainerUserの違い：rootで動かす設定

公式イメージの多くは、`vscode`という非rootユーザー（UID 1000）で作業する設定になっています。主要イメージのうち`javascript-node`と`typescript-node`は`node`ユーザーです。パッケージを入れるだけなら、公式イメージには`sudo`が設定済みなので、ユーザーを変えずに`sudo apt-get install`で済みます。それでもrootで作業したい場合の設定は2つあり、効く範囲が違います。

[devcontainer.jsonリファレンス](https://containers.dev/implementors/json%5Freference/)の定義では、`remoteUser`はVS Codeなどのツールと、そこから起動するターミナル・タスク・デバッグの実行ユーザーで、コンテナ全体の実行ユーザーは変えません。`containerUser`はコンテナ内のすべての処理の実行ユーザーを上書きします。`mcr.microsoft.com/devcontainers/base:ubuntu`で3通りを作り、`devcontainer exec`で確かめた結果が次の表です。

| 設定                          | ターミナルのユーザー | PID 1のユーザー | 作ったファイルのUID |
| --------------------------- | ---------- | ---------- | ----------- |
| 指定なし（イメージ既定）                | vscode     | root       | 1000        |
| `"remoteUser": "root"`      | root       | root       | 0           |
| `"containerUser": "vscode"` | vscode     | vscode     | 1000        |

作業をrootで行いたいだけなら`remoteUser`で足ります。`containerUser`は、イメージの`USER`がrootで、起動するプロセスまで非rootにしたいときに使います。

```
{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "remoteUser": "root"
}
```

注意点はLinuxホストでのファイル所有者です。リファレンスによると、Linuxでは`updateRemoteUserUID`（既定はtrue）がコンテナ内ユーザーのUID/GIDをホストのユーザーに合わせ、バインドマウントの権限問題を防ぎます。CLIのソースを読むと、この処理は対象ユーザーがrootか数値UIDのときは飛ばされます。rootで作ったファイルはUID 0のままなので、Linuxホストではroot所有のファイルがワークスペースに残ります。macOSのColima（virtiofs）では、どの設定で作ったファイルもホスト側では自分のUID（501）に見えました。

## ライフサイクルコマンドの実行順と回数：初回・再接続・再作成

devcontainer.jsonには、コンテナの作成や起動のタイミングで走るコマンドが6つあります。リファレンスの説明だけでは「いつ・何回」走るかがつかみにくいので、6つすべてにユーザー名をログへ書き出すコマンドを入れ、Dev Container CLIで操作を変えて記録しました。表の「起動中に再接続」は起動中のコンテナに対する`devcontainer up`の再実行、「停止後に再起動」は`docker stop`後の`devcontainer up`です。

| コマンド                 | 実行場所 | 初回作成 | 起動中に再接続 | 停止後に再起動 | 作り直し |
| -------------------- | ---- | ---- | ------- | ------- | ---- |
| initializeCommand    | ホスト  | ○    | ○       | ○       | ○    |
| onCreateCommand      | コンテナ | ○    | －       | －       | ○    |
| updateContentCommand | コンテナ | ○    | －       | －       | ○    |
| postCreateCommand    | コンテナ | ○    | －       | －       | ○    |
| postStartCommand     | コンテナ | ○    | －       | ○       | ○    |
| postAttachCommand    | コンテナ | ○    | ○       | ○       | ○    |

「作り直し」は`devcontainer up --remove-existing-container`で、既存コンテナを消して作り直す操作です。所要時間は、イメージ取得を含む初回が56秒、再接続と停止後の再起動がそれぞれ4秒、作り直しが6秒でした（Intel MacのColima上）。`initializeCommand`だけがホストのユーザーで動き、残り5つはコンテナ内の`vscode`ユーザーで、作業ディレクトリは`/workspaces/<フォルダ名>`でした。

この表から、置き場所の判断は次のようになります。

- 依存パッケージの導入（`npm install`、`pip install`）は`postCreateCommand`。作り直しのたびに入り直し、再起動では走りません。
- DBマイグレーションやファイアウォール設定のように、コンテナ起動のたびに必要な初期化は`postStartCommand`。
- ホスト側で事前に作っておくファイル（`.env`の雛形など）は`initializeCommand`。再接続でも毎回走るので、何度実行しても結果が変わらない書き方にします。

公式ドキュメントは、`postCreateCommand`は終了するコマンドでなければならず、アプリの起動を入れるとコンテナが立ち上がらないと注意しています。サーバーを常駐させたい場合はここに書かず、ターミナルやタスクから起動します。VS Codeが接続を待つのは、リファレンス上の`waitFor`の既定である`updateContentCommand`までで、`postCreateCommand`は接続後に裏で走ります。

## 複数コンテナの作り方：Docker Composeでアプリとデータベースを組む

アプリとデータベースのように複数のサービスが要る場合は、`dockerComposeFile`でComposeファイルを渡し、VS Codeが入るサービスを`service`で指定します。`image`や`build`との併用はできません。

```
// .devcontainer/devcontainer.json
{
  "name": "app-and-db",
  "dockerComposeFile": "compose.yaml",
  "service": "app",
  "workspaceFolder": "/workspace",
  "shutdownAction": "stopCompose"
}
```

```
# .devcontainer/compose.yaml
services:
  app:
    image: mcr.microsoft.com/devcontainers/base:ubuntu
    volumes:
      - ..:/workspace:cached
    command: sleep infinity
  db:
    image: postgres:17-alpine
    environment:
      POSTGRES_PASSWORD: postgres
```

`command: sleep infinity`は、アプリ側のコンテナが即座に終了しないようにするための指定です。`..:/workspace`は`.devcontainer`の1つ上、つまりプロジェクトのフォルダだけを共有します。公式テンプレート（javascript-node-postgresなど）のComposeファイルにある`../..:/workspaces`は親フォルダごとマウントするため、隣の別プロジェクトまでコンテナから見えます。

この構成を`devcontainer up`で立ち上げると、初回は32秒、コンテナを作り直した2回目は6秒で2つのコンテナが起動しました。`app`から`db`というサービス名で名前解決でき、5432番ポートにも接続できましたが、起動直後の1回目は接続を拒否され、その後の再試行で通りました。`postCreateCommand`でマイグレーションを流すなら、Compose側に`healthcheck`を書いて`depends_on`の`condition: service_healthy`で待たせるか、コマンド内で接続を再試行させます。データベースのクライアントは`localhost`ではなく`db`をホスト名にします。

公式ドキュメントは、DBを`localhost`で扱いたい場合の手として、`app`に`network_mode: service:db`を付けてDBと同じネットワークに乗せる方法を示しています。Compose自体の書き方は[docker-composeとは？複数コンテナをymlで定義し一括管理する仕組みを解説](/tech/details/13282/)で解説しています。

## 言語別テンプレートと公式イメージのタグ

土台イメージは、`mcr.microsoft.com/devcontainers/`配下の公式イメージを使うのが手早い方法です。2026年10月18日にレジストリのタグ一覧から確認した主な指定は次のとおりです。

| 用途         | イメージ                          | タグの例                               |
| ---------- | ----------------------------- | ---------------------------------- |
| 汎用（Ubuntu） | devcontainers/base            | ubuntu / ubuntu24.04 / ubuntu26.04 |
| Python     | devcontainers/python          | 3.14-trixie / 3.13 / 3.12          |
| Node.js    | devcontainers/javascript-node | 24 / 26 / 24-trixie                |
| TypeScript | devcontainers/typescript-node | 24 / 26                            |
| Java       | devcontainers/java            | 17 / 21 / 25                       |
| Go         | devcontainers/go              | 1.26 / 1.27                        |

`base:ubuntu`のような版を書かないタグは、時期によって中身が変わります。2026年10月に取得した`base:ubuntu`はUbuntu 26.04.1 LTS（イメージのリリースv0.4.35、2026年10月9日）でした。24.04を前提にしたスクリプトがあるなら、`ubuntu24.04`のように版を書いて固定します。

Pythonのテンプレートを適用すると、既定の選択肢は`3.14-trixie`で、生成される`image`は`python:3-3.14-trixie`のように先頭にイメージ自体のメジャー版が付きます。テンプレートの説明には、ローカルのApple Silicon（arm64）では`-trixie`か`-bookworm`付きを選ぶよう書かれています。FlutterやGodotのように公式イメージが無い環境は、`base:ubuntu`にDockerfileでSDKを入れて作ります。

## コンテナの終了・再ビルド・削除

VS Codeのウィンドウを閉じたときの動きは`shutdownAction`で決まります。既定は、`image`やDockerfileの構成なら`stopContainer`、Docker Composeなら`stopCompose`で、どちらもコンテナを停止するだけで削除しません。次に「Reopen in Container」を実行すると同じコンテナが再起動するので、`postCreateCommand`は走り直しません。閉じても動かし続けたい場合は`"shutdownAction": "none"`にします。

VS Codeはdevcontainer.jsonやDockerfileを編集しても自動では再ビルドしません。変更を反映するのは次のコマンドです。

- 「Dev Containers: Rebuild Container」：コンテナを作り直します。手で入れたソフトウェアは消えるので、残したいものはDockerfileか`postCreateCommand`に書きます。
- 「Dev Containers: Rebuild Container Without Cache」：Dockerのビルドキャッシュを使わずに作り直します。ローカルで開いている状態からは「Rebuild Without Cache and Reopen in Container」です。

使い終わった開発コンテナは、コマンドパレットの「Dev Containers: Clean Up Dev Containers…」で選んで消せます。Docker側で消す場合は、`docker ps -a`で確認して`docker rm`・`docker rmi`を使います。Dev Containersが作ったコンテナには`devcontainer.local_folder`というラベルが付き、元のフォルダのパスが入っているので、`docker ps -a --filter label=devcontainer.local_folder`で絞り込めます。コンテナの起動・停止コマンドの使い分けは[Dockerコンテナ起動コマンドの使い分け｜run・start・execと起動しない時の対処](/tech/details/3935/)にまとめています。

## VS Codeなしで作る：Dev Container CLIの使い方

同じdevcontainer.jsonは、npmパッケージ`@devcontainers/cli`のコマンド`devcontainer`でも扱えます。CIで開発環境と同じコンテナを使いたいときや、VS Code以外のエディタを使う人がいるチームで役立ちます。2026年10月18日時点の最新は0.89.0（2026年8月31日公開）で、Node.js 20以上が必要です。

```
npm install -g @devcontainers/cli

# テンプレートからdevcontainer.jsonを作る（Add Dev Container Configuration Filesに相当）
devcontainer templates apply --workspace-folder . \
  --template-id ghcr.io/devcontainers/templates/python \
  --template-args '{"imageVariant":"3.14-trixie"}'

# コンテナを作って起動する（Reopen in Containerに相当）
devcontainer up --workspace-folder .

# コンテナ内でコマンドを実行する
devcontainer exec --workspace-folder . python --version

# Featureの更新状況を確認する
devcontainer outdated --workspace-folder .
```

`templates apply`はPythonテンプレートの場合、`.devcontainer/devcontainer.json`に加えて`.github/dependabot.yml`も生成しました。イメージだけを作る`devcontainer build`もあります。CIでビルドしたイメージをレジストリへ公開し、各メンバーのdevcontainer.jsonでそのイメージを参照すれば、手元で必要なビルド処理を減らせます。

## AIエージェントを開発コンテナで動かす：Claude Code・Copilot CLI・Codex

AIコーディングエージェントを開発コンテナに入れると、エージェントが実行するコマンドはホストではなくコンテナの中で動きます。ただし、マウントしたホスト側のファイルには書き込めますし、Dockerの通常のネットワークでは外部へも通信できます。触れるファイルはマウントの範囲で、通信先はファイアウォールなどで別に絞ります。

Claude Codeは、公式ドキュメント[Development containers](https://code.claude.com/docs/en/devcontainer)が導入方法を示しています。既存のdevcontainer.jsonに`"ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}`をFeatureとして足すだけで入り、末尾の`:1.0`はインストールスクリプトの版で、Claude Code本体は最新版が入って自動更新されます。同じページは、確認なしで実行する`--dangerously-skip-permissions`をCLIがroot起動では拒否すると書いており、`remoteUser`を非rootにしておくよう求めています。前の章でrootにしたコンテナでは、この使い方ができません。

より固めた例として、公式リポジトリの[.devcontainer](https://github.com/anthropics/claude-code/tree/main/.devcontainer)に参照実装があります。Dockerfile・devcontainer.json・`init-firewall.sh`の3ファイルで、`runArgs`に`--cap-add=NET_ADMIN`と`--cap-add=NET_RAW`を付け、`postStartCommand`でファイアウォールのスクリプトを実行し、`waitFor`を`postStartCommand`にしています。スクリプトは外向き通信を既定で拒否し、GitHubのIP範囲、`registry.npmjs.org`、`api.anthropic.com`、VS Codeのマーケットプレイスなど列挙した宛先だけを許可します。実行順の表のとおり`postStartCommand`は起動のたびに走るので、停止後に再起動してもファイアウォールが張り直されます。公式ドキュメントは、このスクリプトと2つの権限はClaude Code自体には不要で、ネットワーク制限を別の方法で行うならなくてよいとしています。Claude Code側の権限設定は[Claude Codeのパーミッションモードの違いと設定方法｜auto・acceptEdits・bypassPermissionsの使い分け](/tech/details/11246/)で扱っています。

GitHub Copilot CLIは、公式Featureの`ghcr.io/devcontainers/features/copilot-cli:1`（2026年10月時点で1.1.3）で入れられます。Copilot CLIの動作モードとインストールは[GitHub Copilot CLIのAutopilotとは｜使い方・止まる条件・料金と導入手順【2026年9月】](/tech/details/11137/)を参照してください。

OpenAIのCodexは、公式ドキュメント[Agent approvals & security](https://learn.chatgpt.com/docs/agent-approvals-security)に「Run Codex in Dev Containers」という節があります。ホストでLinuxのサンドボックスが動かない場合や、組織がコンテナでの開発に統一している場合に、Dev Containersを外側の隔離境界にする使い方です。コンテナ内では、Dev Containerの構成が`bwrap`に必要な権限を与えていればCodex自身のサンドボックスを有効のまま使い、コンテナを隔離境界とみなすなら`--sandbox danger-full-access`で二重のサンドボックスを作らない、の2択が示されています。後者について同じ節は、悪意のあるプロジェクトがコンテナ内のCodexの認証情報まで持ち出せると警告し、信頼できるリポジトリに限るよう求めています。

どの方法でも、バインドマウントしたワークスペースはエージェントが書き換えられます。未コミットの変更を消されないよう、作業前にコミットしておく運用は変わりません。チームで開発コンテナとCIの環境をそろえる体制づくりは、[DevOps・CI/CD導入支援](/service/system/devops/)でもご相談いただけます。

## 開発コンテナを避けたほうがよい場面

- iOSやmacOSのアプリをXcodeでビルドする開発：Dev ContainersのコンテナはLinuxで、公式の対応表もLinuxコンテナのみです。
- Windowsコンテナが前提の.NET Framework開発：公式ドキュメントがWindowsコンテナイメージを非対応と明記しています。
- Linuxホストで、ワークスペースのファイルをホスト側の別ツールからも触る運用で、rootで作業したい場合：前述のとおりUIDの合わせ込みが効かず、root所有のファイルが残ります。`remoteUser`は非rootのまま`sudo`を使うほうが安全です。

## よくある質問

### Create Dev Containerはどこから実行しますか？

VS Codeでフォルダを開き、コマンドパレット（F1）から「Dev Containers: Add Dev Container Configuration Files…」を実行してテンプレートを選び、「Dev Containers: Reopen in Container」でコンテナに入ります。拡張機能「Dev Containers」とDockerが必要です。

### 開発コンテナをrootで動かすには？

devcontainer.jsonに`"remoteUser": "root"`を書き、「Rebuild Container」を実行します。ターミナルやデバッガがrootで動きます。コンテナ全体の実行ユーザーを変えるのは`containerUser`です。Linuxホストではrootで作ったファイルがホスト側でもroot所有になります。

### VS Codeを閉じるとコンテナは消えますか？

消えません。既定の`shutdownAction`はコンテナの停止で、次に「Reopen in Container」を実行すると同じコンテナが再起動します。作り直すのは「Rebuild Container」を実行したときです。

### devcontainer.jsonを変えたのに反映されないのはなぜですか？

VS Codeは設定ファイルの変更で自動的に再ビルドしないためです。「Dev Containers: Rebuild Container」を実行します。`postCreateCommand`は作成時にしか走らないので、再起動だけでは追加したコマンドが実行されません。

### Docker Desktopが無くても開発コンテナは作れますか？

Docker互換の環境があれば動く場合がありますが、公式サポートの対象はDocker Desktop（Windows・macOS）とDocker CE/EE（Linux）です。この記事の検証では、Colimaのソケットを`DOCKER_HOST`に指定したDev Container CLI 0.89.0でコンテナの作成・接続・Compose構成まで動きました。

## 関連記事

- [Dev Container（devcontainer）のメリットとは｜Dockerで開発環境を統一する仕組みと設定【2026年版】](/tech/details/3728/)
- [VS Code 1.118の新機能｜codebase semantic index・devcontainer-lock.json・Copilot設定の変更点](/tech/details/12043/)
- [docker-composeとは？複数コンテナをymlで定義し一括管理する仕組みを解説](/tech/details/13282/)
- [Colimaとは？MacでDocker Desktopを外す導入手順と設定の落とし穴【0.10系】](/tech/details/17842/)
- [GitHub Copilot CLIのAutopilotとは｜使い方・止まる条件・料金と導入手順【2026年9月】](/tech/details/11137/)

---

出典: [VS Codeで開発コンテナを作る（Create Dev Container）｜devcontainer.jsonの書き方・root実行・複数コンテナ](<https://www.issoh.co.jp/tech/details/9565/>)（株式会社一創）