ソフトウェア プログラミング 公開日 2026.04.04 更新日 2026.04.04

Dev Containersとは?ローカル開発を汚さない開発環境の作り方を初心者向けに解説

Dev Containers とは何か、なぜローカル開発を汚しにくくできるのか、最初の作り方とハマりやすい点を初心者向けに整理した記事です。

先に要点

  • Dev Containers は、開発環境をコンテナでそろえて、ローカルPCを汚しにくくするやり方です。
  • 中心になるのは devcontainer.json で、どのイメージを使うか、どんな拡張や設定を入れるかを定義します。
  • 便利なのは、`自分のPCだけ動かない` `ライブラリのバージョンが違う` `OS差で詰まる` を減らしやすいことです。
  • 初心者はまず、Docker を入れて、既存のイメージか最小の Dockerfile と `devcontainer.json` で 1 プロジェクト作るところから始めると入りやすいです。

ローカルで開発していると、このPCには Node.js 18 を入れて、こっちは Python 3.12 を入れて、さらに DB も立てて... という感じで、気づいたら手元の環境がかなり散らかることがあります。
しかも、チーム開発だと 自分のPCでは動くのに、他の人のPCでは動かない もかなり起きやすいです。

この記事では、2026年4月4日時点で Visual Studio CodeDev Containers ドキュメント、Create a Dev Container ガイド、containers.dev の概要と devcontainer.json リファレンスを確認しながら、Dev Containers とは何か、何が便利なのか、最初の作り方、初心者がハマりやすい点を整理します。
依存管理の比較から見たいなら、uvとは?pip・venv・Poetryとの違いを初心者向けに比較|何ができて何を選ぶべきか解説 もつながりやすいです。
Push や Pull Request ごとの自動テストまでつなげたいなら、GitHub Actionsとは?できること・最初の使い方を初心者向けに解説 もあわせて読むと流れが見えやすいです。

Dev Containersとは何か

Dev Containers は、コンテナを使って開発環境をそろえるための仕組みです。
VS CodeDev Containers 機能や containers.dev の仕様まわりでよく出てきます。

初心者向けにかなりざっくり言うと、アプリを動かすための開発環境を、手元のOSへ直接いろいろ入れずにコンテナ側へまとめるやり方 です。
そのため、ローカルPCを開発用の依存で汚しにくくなります。

何が便利なのか

ローカルPCを汚しにくい

言語やDBをコンテナ側に寄せることで、PC本体をきれいに保てます。

チームで環境が揃う

devcontainer.json をリポジトリに入れれば「自分のPCだけ動かない」を減らせます。

作り直しが簡単

コンテナが壊れてもリビルドするだけ。ローカルのコードはそのまま残ります。

ローカルPCを汚しにくい

いちばん分かりやすい利点はここです。 Node.js、Python、DB クライアント、OS パッケージなどを全部ローカルへ直接入れなくても、コンテナ側へ寄せやすくなります。

今このプロジェクトで必要なもの をコンテナ側へ閉じ込めやすいので、別プロジェクトと混ざりにくいです。

チームで環境をそろえやすい

開発で地味につらいのが、環境差です。

  • macOS では動く
  • Windows では詰まる
  • Linux ではバージョン違いが出る
  • 誰かのローカルだけ設定が増えている

Dev Containers では、このプロジェクトはこの環境で開く を定義ファイルで持てるので、チームで揃えやすくなります。

作り直しやすい

ローカルにいろいろ直接入れていると、環境が壊れたときに戻すのが面倒です。
一方、Dev Containers なら コンテナを作り直す 発想で戻しやすいです。

この 壊れてもやり直しやすい のは、実務でもかなり効きます。

何でできているのか

中心になるのは次の3つです。

つまり、Dev Containers は単独の新しいコンテナ技術というより、Docker ベースの開発環境を扱いやすくするための定義と仕組み と考えると分かりやすいです。

devcontainer.json は何をするのか

devcontainer.json は、開発環境の入口になる設定ファイルです。
たとえば次のようなことを書けます。

  • どのイメージを使うか
  • どの Dockerfile を使うか
  • どの Docker Compose 構成を使うか
  • どの拡張機能を入れるか
  • どのポートを開けるか
  • コンテナ作成後に何を実行するか

初心者向けには、このプロジェクトをどういう開発環境で開くかを書いた設計メモ くらいに考えると入りやすいです。

最初の作り方はどうするのか

いちばん入りやすいのは、VS Code で既存のテンプレートやイメージを使って始めるやり方です。
ただ、仕組みを理解しやすいように、ここでは最小構成で見ます。

手順1: Docker を入れる

まずは Docker が必要です。
Dev Containers はコンテナを前提にしているので、ここがないと始まりません。

手順2: .devcontainer/devcontainer.json を作る

最小例なら、こういう形です。

{
  "name": "sample-app",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:1-22-bookworm",
  "customizations": {
    "vscode": {
      "extensions": [
        "dbaeumer.vscode-eslint"
      ]
    }
  }
}

この例だと、既存のイメージを使って Node.js 開発環境を開く形です。
最初は自前の Dockerfile を書かず、イメージ指定だけで始めても十分です。

手順3: VS Code でコンテナとして開く

VS Code 側で Dev Containers: Reopen in Container を選ぶと、その設定を使って開発環境が立ち上がります。
ここでコンテナの作成、拡張機能の導入、必要なセットアップが走ります。

手順4: 必要なら Dockerfile へ広げる

依存が少し増えてきたら、自前の Dockerfile へ広げます。

FROM mcr.microsoft.com/devcontainers/base:ubuntu

RUN apt-get update && apt-get install -y git curl

そして devcontainer.json 側でこれを参照します。

{
  "name": "sample-app",
  "build": {
    "dockerfile": "Dockerfile"
  }
}

こうすると、このプロジェクトで必要な開発環境 を自分たちで少しずつ作り込めます。

複数サービスがあるときはどうするか

アプリ本体だけでなく、DB や Redis も一緒に立てたいことがあります。
このときは Docker Compose を使う形が分かりやすいです。

たとえば、

  • アプリ
  • PostgreSQL
  • Redis

のように複数コンテナが必要なときは、Compose でまとめて定義し、devcontainer.json からどの service を開発対象にするか指定します。

つまり、

くらいで考えると入りやすいです。

実務でどう役立つのか

実務では、Dev Containersローカルを汚さない だけでなく、チームの入口をそろえる のが大きいです。

たとえば新しく参加した人が、

  • README を読む
  • Docker を入れる
  • Dev Container として開く

だけで始められる状態に近づくと、オンボーディングがかなり楽になります。

特に次のような場面で相性がよいです。

  • Node.js や Python や DB が混ざる開発
  • OS 差で詰まりやすいチーム
  • 参加者のPCがばらばらなチーム
  • 依存関係が多く、ローカルへ直接入れたくない開発

初心者がハマりやすいところ

ローカルファイルは消えないが、コンテナは作り直せる

ここは大事です。
Dev Containers は 作業フォルダそのものが全部コンテナに閉じ込められる と誤解しやすいです。

実際には、ローカルのフォルダをコンテナ側から使う形が多いです。
そのため、ソースコードは手元にありつつ、実行環境だけコンテナで揃えるイメージに近いです。

Docker が重いことはある

便利ですが、Docker を使う以上、マシン負荷やディスク使用量は増えます。
古いPC やメモリが少ない環境だと、快適さは落ちることがあります。

何でも Dev Containers にすればよいわけではない

小さいスクリプトや単発検証なら、そこまで大げさにしなくてもよいことがあります。
逆に、依存が多い開発やチーム開発ではかなり効きます。

よくある誤解

よくある誤解

Dev Containers を使えば、環境差や不具合が全部消えるわけではありません。実際には Docker の理解、マウント、権限、ネットワーク、ボリュームの扱いなど、別の見どころも出てきます。

もう一つ多いのは、ローカルに何も入れなくてよくなる と思ってしまうことです。
実際には Docker やエディタ側の準備は必要ですし、場合によっては Git や補助ツールの考え方も必要です。

まとめ

Dev Containers は、コンテナを使って開発環境をそろえ、ローカルPCを開発依存で汚しにくくするやり方です。
中心になるのは devcontainer.json で、必要に応じて DockerfileDocker Compose を組み合わせます。

初心者が始めるなら、まずは既存イメージ + devcontainer.json の最小構成で 1 プロジェクト動かすところから入るのがいちばん分かりやすいです。
そのうえで、チーム開発や複数サービス構成へ広げると、かなり実務でも効きやすいです。

参考情報

あとで見返すならここで保存

読み終わったあとに残しておきたい記事は、お気に入りからまとめて辿れます。