Dev Containersで開発環境を自動構築！オンボーディングを爆速化する実践術 Dev Containersで開発環境を自動構築！オンボーディングを爆速化する実践術

Setting up a development environment can swallow half a day of work, and joining an unfamiliar project often means wrestling with versions, dependencies, and undocumented setup steps. Dev Containers, a feature supported in Visual Studio Code, aim to remove that friction by defining the entire workspace in code, so a new contributor can clone a repository and start coding in minutes rather than hours. For teams that onboard people regularly or juggle several projects with conflicting requirements, the appeal is clear.

At its core, a Dev Container is a Docker container configured specifically for development. The setup is driven by a file named devcontainer.json, usually placed in a .devcontainer folder at the root of a repository. This file describes the base image, the tools and runtimes to install, the VS Code extensions to load, port forwarding rules, and commands to run after the container is created. When VS Code opens the project, the Dev Containers extension builds or pulls the container and reconnects the editor to it, so the language server, terminal, and debugger all run inside that isolated environment rather than on the host machine.

The practical benefit is consistency. Because the configuration is committed to the repository, every developer works against the same Node, Python, or Go version, the same linters, and the same system packages. This sidesteps the familiar "it works on my machine" problem and the dependency hell that appears when switching between projects with incompatible toolchains. It also keeps the host operating system clean, since project-specific tooling lives in the container instead of being installed globally.

A key part of the workflow is Dev Container Features, reusable units that add capabilities such as Docker-in-Docker, the GitHub CLI, or a specific language runtime with a single line in the configuration. Microsoft and the community maintain a catalog of these features and prebuilt templates, which lowers the effort needed to start from scratch. Teams can also point at a Dockerfile or a docker-compose.yml file when they need multiple services, for example an application container paired with a database, so the local setup mirrors a more realistic deployment.

The specification behind this is open. The Development Containers spec is published independently of VS Code, and a command-line tool called devcontainer allows the same configuration to be built outside the editor, which is useful for continuous integration. The same files power GitHub Codespaces, a cloud-hosted version that runs the container on remote infrastructure and streams it into a browser or local editor. This means a project that adopts Dev Containers locally is largely ready for cloud development as well, and contributors without a powerful laptop can still work comfortably.

There are prerequisites and trade-offs worth noting. A working Docker installation is required, typically Docker Desktop on Windows and macOS, where containers run inside a lightweight Linux virtual machine. That layer can add overhead, and large images may take time to build on first run, although caching and prebuilt images mitigate repeat costs. File system performance and resource limits sometimes need tuning, and Windows users often pair this approach with the Windows Subsystem for Linux for smoother results. Licensing for Docker Desktop also matters for larger organizations, so some teams use alternatives such as Podman or Rancher Desktop.

For onboarding specifically, the payoff is concrete. Instead of a wiki page of setup commands that drifts out of date, the environment definition is versioned alongside the code and reviewed through normal pull requests. A new hire installs Docker and the extension, opens the project, and the recommended extensions, environment variables, and post-create scripts run automatically. When the stack changes, the change is committed once and propagates to everyone.

Dev Containers fit into a broader trend toward declarative, reproducible environments, sitting alongside tools like Nix, Vagrant, and language-specific version managers. They are not a fit for every situation, particularly heavy desktop or GPU workloads, but for typical web and backend projects they offer a practical balance. Teams considering adoption are likely to benefit from starting with a community template, adding only the features they need, and treating the configuration as living documentation that keeps the whole team in step.