この記事は、 KENTEM TechBlog アドベントカレンダー2025 1日目、12月1日の記事です。

はじめに

こんにちは！新卒2年目でバックエンドを担当しているK・Mです。
気づけば今年も残り1か月ですね。振り返ってみると、私はGitHub Actionsを触り始めたのをきっかけにCI/CDへ興味が広がり、そこからコンテナの世界にハマった1年でした。

今回は、そんな私が個人開発で手放せなくなったDev Containerを紹介します！

Dev Containerとは？

Dev Containerとは読んで字のごとく、開発専用のコンテナです。Docker等のコンテナ技術を使って開発環境を丸ごとコンテナ化しています。
これによって以下のようなメリットを享受できます。

簡単に開発環境を作成できる
開発環境を分離できる
開発環境をほぼ完全に統一できる

順にみていきます。

簡単に開発環境を作成できる

例えば Python の開発環境を作りたい場合、以下の devcontainer.json を置くだけでOKです！

{
  "name": "Python Dev Container",
  "image": "mcr.microsoft.com/devcontainers/python:3.11",
}

ここで使用しているmcr.microsoft.com/devcontainers/python:3.11は、Microsoft が公式に提供している 開発用途に最適化されたDocker イメージです。
Python のコンテナとしては alpine や debian（bookworm）ベースのものも利用できますが、Dev Container 用の公式イメージは VSCode や Dev Containers 拡張との相性が良く、セットアップが簡単というメリットがあります。

また、本番環境をコンテナで運用しているチームであれば、本番と同じ Dockerfile をそのまま Dev Container に流用して、開発環境と本番環境を揃えるといった使い方もできます。

# ==== base image（共通）====
FROM python:3.11-slim AS base

# ==== runtime（本番環境用）====
FROM base AS runtime
WORKDIR /app
COPY requirements.txt .
CMD ["python", "main.py"]

{
  "name": "my-app-dev",
  "build": {
    "dockerfile": "../Dockerfile", //devcontainer.jsonからDockerfileまでのパス
    "context": ".." //ビルドコンテキストが必要な場合は追加
    "target" : "base"  //上記のようにDockerfileをマルチステージングビルドにしてる場合はtargetを設定
  },
  "remoteUser": "vscode"
}

開発環境の分離

Dev Container を使うと、「開発専用のPCをもう1台用意する」くらいの感覚で環境をきれいに分離できます。 Node ならnode_modules、Python ならvenvを使ってプロジェクトごとに環境を分けることもできますが、Dev Container は OSレベルでユーザースペースごと隔離されるため、ツール同士のコンフリクトが起きにくいのが大きなメリットです。（※VMほど完全に独立しているわけではありませんが、開発用途としては十分に環境を分離することができます！）
また、セキュリティ面でも恩恵があります。

npm のサプライチェーン攻撃のようなケース
AIツールが誤って怪しいスクリプトを実行するケース

こういった“事故りがちなトラブル”も、多くの場合はコンテナ内部で完結し、ホスト環境への影響を最小化できるため安心感があります。

開発環境をほぼ完全に統一できる

リポジトリに .devcontainer/devcontainer.json を置くだけで、チーム全員が同じ環境を簡単に手に入れられます。
特に便利なのが VSCode 拡張機能の統一です。次のようにvscodeセクションのextensionsに拡張機能の識別子を書くだけで、Dev Container 起動時に必要な拡張機能が自動インストールされます。

{
  "name": "dev",
  "image": "mcr.microsoft.com/devcontainers/python:3.13",
  "customizations": {
    "vscode": {
      "extensions": [
        "GitHub.copilot",
        "ms-python.python",
        "ms-python.vscode-pylance",
        "shd101wyy.markdown-preview-enhanced",
        "ms-python.black-formatter",
        "charliermarsh.ruff",
        "ms-azuretools.vscode-docker",
        "mhutchie.git-graph",
        "github.vscode-github-actions"
      ],
}

プロジェクトオンボーディング時に「なんか知らんけど動かない」が激減するのはめちゃくちゃ助かります。

Dev Containerのクイックスタート

　Dev Containerを早速動かしてみたいと思います！なお、実行環境は以下の通りです。

コンテナ実行環境：Docker
エディタ：VSCode
拡張機能：Dev Containersをインストール

1. コンテナの実行環境起動

Dev Containerはただコンテナを動かしているだけなので、コンテナの実行環境が必要です。今回はDockerを使用しているのでDocker Desktopを立ち上げます。
こちら私だけかもしれませんが、よく起動を忘れてDev Containerを立ち上げようとしてエラーが出てきて焦ります。普段動いているDev Containerが動かなかったらDockerの立ち上げ忘れを疑いましょう。

2. devcontainer.json作成

コンテナの実行環境を立ち上げたら、自分が開発を行いたいワークスペースのルートに.devcontainerディレクトリを作成します。
後はその中に先ほどお見せしたようなdevcontainer.jsonを配置します。

3. 起動

あとはこれを起動します。といってもVSCodeのDev Containersの拡張機能が優秀で、この時点で右下にこんな感じのトーストが出てくるので、「コンテナーで再度開く」を押したら起動できます。

トーストが消えちゃっても、ctrl + shift + pでコマンドパレットから「Dev Containersを使用して開始する」があるので、こちらを押せば問題ないです。

Podmanでの実行方法

今回Dockerを使って説明しましたが、私は個人開発ではPodmanを使用しています。Podmanで実行する場合は、dev containerの設定ファイルを開いてパスをdockerからpodmanに変更するだけで使用できます。

個人的によく使う設定やimage

1. featureでnodeを入れておく

昨今はgemini cliやcodex、claude codeのようなAIエージェントをCLIで動かす方も多いと思いますが私もその一人です。この二つはnode必須なのでfeatureにnodeを入れて、postCreateCommandで各cliをインストールしましょう。

{
  "name": "dev",
  "image": "mcr.microsoft.com/devcontainers/python:3.13",
  "feature" : { "ghcr.io/devcontainers/features/node:1" : {"version" : "18"} },
  "postCreateCommand" : "npm install -g @openai/codex"
}

2. GitHub Actionsのローカル実行環境を作る

GitHub Actionsをローカルで実行したい場合もあるかと思います。よくactが使用されているかと思いますが、actをDev Containerと同時採用するとDocker in DockerやDocker outside of Dockerになってしまいます。私は個人開発で常にDev Containerを使っており、これを避けるためにwrkflwを使用します。wrkflwはRust環境があれば動くTUIツールなので、featureにRustを入れて使うことができます。

{
  "name": "python-rust-devcontainer",
  "image": "mcr.microsoft.com/devcontainers/python:3.13",
  "features": {
    "ghcr.io/devcontainers/features/rust:1": {
      "version": "latest"
    }
  },
  "postCreateCommand": "cargo install wrkflw",
  "remoteUser": "vscode",
  "customizations": {
    "vscode": {
      "extensions": [
        "ms-python.python",
        "ms-python.vscode-pylance",
        "github.vscode-pull-request-github",
        "github.vscode-github-actions",
        "mhutchie.git-graph"
      ]
    }
  }
}

GitHub Copilotの設定も書き換える

GitHub Copilotを使う方はこんな感じでvscode内にsettingを書いて設定してあげるとデフォルトで使うことができます。settingは、VSCodeのsetting.jsonをリモート用に書き換える場所で、特に何も記載が無ければホスト側のsetting.jsonと同じ設定がされます！なのでローカルと同じ設定でよいという方は拡張機能を入れるだけでいいのですが、環境によってenableを書き換えたい場合はこちらで設定します。

{
 // image等は省略
  "customizations": {
    "vscode": {
      "extensions": [
        "github.copilot",
        "github.copilot-chat",
      ],
      "settings": {
        "github.copilot.enable": {
          //txtとmdではcopilotの補完を効かなくする
          "*": true,
          "plaintext": false,
          "markdown": false
        },
        "github.gitAuthentication": true
      }
    }
  }
}

まとめ

今回はDev Containerについて紹介しました。私はこれによって、自分の個人用PCのローカルPCには一切言語環境をインストールせずに、日々の実験に勤しめています。ただ、ここまでメリットのみを述べてきましたが、Docker in/outside of Dockerに直面してしまうというデメリットもあります。
Docker in/outside of Dockerの対策として、ghcr.io/devcontainers/features/docker-in-dockerやghcr.io/devcontainers/features/docker-outside-of-dockerといったfeatureを導入するといった回避策もありますが、Dockerの一部機能が使えないこともあります。（Docker MCP Gatewayを触ろうとしたのですが、現状全くうまく行っていません・・・😿）　
こちらについては今後も調査をしていき、ベストプラクティスを見つけていきたいなと思います！