【初心者向け】VS Code Dev Containerとは？使い方を解説

By /

【初心者向け】VS Code Dev Containerとは？使い方を解説

プログラミング学習や開発を始めたばかりの方にとって、「開発環境の構築」は最初の大きな壁となることがあります。OSの違い、必要なソフトウェアのバージョン、依存関係のコンフリクトなど、様々な問題に直面し、「コードを書く前に挫折しそう…」と感じた経験がある方もいるかもしれません。

また、チームで開発を行う際には、「私の環境では動くのに、あなたの環境では動かない」といった、いわゆる「Works on my machine（私のマシンでは動く）」問題に悩まされることも少なくありません。

このような開発環境に関する様々な課題を解決する強力なツールが、VS Codeの「Dev Container（開発コンテナ）」です。

この記事では、プログラミング初心者の方でも Dev Container の概念、メリット、そして具体的な使い方を理解できるよう、約5000語のボリュームで徹底的に解説します。

Dev Container をマスターすれば、開発環境の構築や管理が驚くほど楽になり、よりスムーズに開発に集中できるようになるはずです。ぜひ最後までお読みください。

1. 開発環境の課題：なぜ Dev Container が必要なのか？

Dev Container が解決しようとしている問題を理解するために、まずは従来の開発環境構築における典型的な課題をいくつか見てみましょう。

1.1. 複雑で時間のかかる環境構築

プロジェクトを開始する際、まず最初に行うのは開発に必要なツールやライブラリのインストールです。これは、プログラミング言語のランタイム（Python、Node.js、Javaなど）、ビルドツール、パッケージマネージャー、データベース、フレームワーク、各種コマンドラインツールなど、多岐にわたります。

  • OSごとの違い: Windows、macOS、Linuxなど、OSによってインストール方法やパスの設定などが異なります。
  • バージョンの問題: プロジェクトによっては特定のバージョンの言語やライブラリが必要になることがあります。古いプロジェクトを開くために古いバージョンをインストールしたり、複数のプロジェクトで異なるバージョンが必要になったりすると、管理が非常に煩雑になります。
  • 依存関係のコンフリクト: あるツールをインストールすると、他のツールが依存しているライブラリとバージョンが衝突し、予期せぬエラーが発生することがあります。
  • 手作業によるリスク: インストールや設定のほとんどが手作業で行われるため、手順を間違えたり、必要な設定を忘れたりするリスクが伴います。

これらの作業は初心者にとっては特にハードルが高く、多くの時間と労力を費やしてしまう可能性があります。

1.2. 「Works on my machine」問題と環境の不整合

チーム開発において、最もよくある問題の一つが「私の環境では問題なく動くのに、他の人の環境ではエラーになる」という現象です。これは、開発者それぞれのローカル環境が微妙に異なるために発生します。

  • OSやソフトウェアのバージョンの違い: 開発者AはmacOSでPython 3.9、開発者BはWindowsでPython 3.8を使っている、といった違いがあると、特定のライブラリの振る舞いが異なったり、互換性の問題が発生したりします。
  • インストールされているライブラリの違い: プロジェクトに必要なライブラリ以外に、開発者が個人的に使っている他のライブラリやツールが干渉する場合があります。
  • 環境変数の設定: パスやAPIキーなどの環境変数の設定ミスや違いが原因で、正しく動作しないことがあります。
  • バックグラウンドで動いているサービス: 開発者のローカル環境で起動しているデータベースやキャッシュサーバーなどが、プロジェクトの実行に影響を与えることがあります。

これらの環境の不整合は、デバッグに時間を要するだけでなく、チーム全体の開発効率を著しく低下させます。

1.3. 新規メンバーのオンボーディングコスト

新しいメンバーがプロジェクトに参加する際、まず行うべきことは開発環境のセットアップです。前述のような複雑な環境構築手順が必要な場合、新しいメンバーが開発を開始できるようになるまでにかなりの時間とサポートが必要になります。詳細な手順書を作成しても、OSや個別の環境差によって予期せぬ問題が発生することは避けられません。これは、プロジェクトへの参加を遅らせるだけでなく、教育コストの増加にもつながります。

1.4. 複数のプロジェクトでの環境管理

一人の開発者が複数のプロジェクトに関わることもよくあります。それぞれのプロジェクトが異なるバージョンの言語やフレームワークを要求する場合、ローカル環境でそれらを共存させるのは非常に困難です。バージョン管理ツール（例: pyenv, nvm, rbenvなど）を使っても、完全に分離することは難しく、切り替えの手間や設定ミスによるトラブルが発生する可能性があります。

これらの課題を解決するのが Dev Container

Dev Container は、これらの開発環境に関する様々な課題を一挙に解決する、または大幅に軽減するためのアプローチを提供します。開発環境をコンテナとして「隔離された箱」の中に構築することで、前述の問題を根本から解決することができます。

2. VS Code Dev Container とは？

では、具体的に VS Code Dev Container とはどのようなものでしょうか？

簡単に言うと、Dev Container は「開発に必要なツール、ライブラリ、ランタイム、設定など、開発環境全体を Docker コンテナの中に構築し、VS Code からそのコンテナ内に入って開発を行う仕組み」です。

VS Code には Dev Container の機能が統合されており、特定のファイル（devcontainer.json）をプロジェクトのルートに配置することで、そのプロジェクトを開く際に自動的に開発コンテナを起動し、VS Code がそのコンテナ内で動作するように接続してくれます。

2.1. コンテナとは？

Dev Container の核心にある技術は「コンテナ」です。特に、多くの場合は Docker というコンテナ技術が使われます。

コンテナを非常に簡単な言葉で説明すると、「アプリケーションとその実行に必要なすべてのもの（コード、ランタイム、システムツール、システムライブラリ、設定など）を一つにまとめて隔離された状態で実行できるようにした軽量な仮想化技術」です。

  • 仮想マシン (VM) との違い: VM は OS 全体（カーネルを含む）をエミュレートまたは仮想化するため、起動に時間がかかり、リソース消費も大きくなりがちです。一方、コンテナはホストOSのカーネルを共有し、その上でアプリケーションとその依存関係だけを隔離します。このため、VMよりもはるかに軽量で起動が速いのが特徴です。
  • 隔離性: コンテナは互いに隔離されています。一つのコンテナでインストールしたライブラリが、他のコンテナやホストOSに影響を与えることはありません。
  • ポータビリティ: コンテナイメージ（コンテナの設計図のようなもの）は、コンテナエンジン（Dockerなど）がインストールされていれば、どの環境でも同じように実行できます。

Dev Container は、このコンテナ技術を「開発環境」という目的に応用したものです。プロジェクトごとに専用の開発コンテナを用意することで、環境構築の課題を解決します。

2.2. Dev Container の構成要素

Dev Container 環境を構築・利用するために必要な主な要素は以下の通りです。

  1. VS Code: もちろん、これが中心となる開発エディタです。Dev Container 機能が組み込まれています。
  2. Docker Desktop (または互換性のあるコンテナエンジン): コンテナを作成し、実行するためのソフトウェアです。Windows, macOS, Linux に対応しています。
  3. devcontainer.json ファイル: プロジェクトのルートディレクトリまたは.devcontainerディレクトリ内に配置される設定ファイルです。どんなコンテナイメージを使うか、必要なツールをどうインストールするか、VS Code の設定や拡張機能をどうするか、ポートフォワーディングはどうするか、といった開発コンテナの仕様を定義します。
  4. Dockerfile (オプション): より複雑な環境を構築したい場合に、ベースとなるコンテナイメージをカスタマイズするためのファイルです。devcontainer.jsonから参照されます。
  5. プロジェクトのソースコード: 開発対象となる実際のコードです。通常、ホストOSのファイルシステム上にありますが、VS Code Dev Container の機能によってコンテナ内部からアクセスできるようになります。

VS Code が devcontainer.json ファイルを読み込み、指定されたコンテナイメージや Dockerfile を使って開発コンテナをビルド・起動し、そのコンテナに接続して開発作業を行う、というのが基本的な流れです。

3. Dev Container を使うメリット

Dev Container を使うことで得られる具体的なメリットはたくさんあります。初心者にとって特に嬉しい点も多いです。

3.1. 環境構築の手間を大幅に削減

これが最大のメリットかもしれません。新しいプロジェクトを始める際や、別のマシンで同じプロジェクトを開発する際に、ローカル環境にイチから開発ツールやライブラリをインストールする必要がなくなります。devcontainer.json があれば、VS Code が自動的にコンテナをビルド・起動してくれます。

特に、チームで開発を行う場合、プロジェクトリポジトリに devcontainer.json を含めておけば、新しいメンバーはリポジトリをクローンし、VS Code で開くだけで、すぐに開発可能な状態になります。オンボーディングにかかる時間が劇的に短縮されます。

3.2. 開発環境の統一と「Works on my machine」問題の解消

全ての開発者が同じ定義（devcontainer.json に記述された内容）に基づいて構築されたコンテナ内で開発を行うため、開発環境が統一されます。「OSが違うから」「ライブラリのバージョンが違うから」といった理由で発生する環境依存の問題がなくなります。これにより、デバッグの手間が減り、チーム全体の開発効率が向上します。

3.3. クリーンな環境での開発

コンテナは隔離されているため、開発に必要なものだけがコンテナ内に存在します。ホストOSや他のプロジェクトの環境に影響されることがありません。また、ホストOSの環境を開発ツールのインストールで汚すこともありません。常にクリーンで予測可能な環境で開発できます。

3.4. 複数のプロジェクトの環境管理が容易に

プロジェクトごとに異なる Dev Container を用意すれば、それぞれが完全に分離された開発環境になります。Node.js v14を使うプロジェクトとNode.js v16を使うプロジェクト、Python 3.8を使うプロジェクトとPython 3.10を使うプロジェクトなどを、ローカル環境を汚すことなく並行して開発できます。

3.5. 環境のポータビリティと再現性

devcontainer.json ファイルと Dockerfile (使用している場合) さえあれば、そのプロジェクトの開発環境は完全に定義されています。これを共有すれば、誰でも、どのマシンでも、何度でも、まったく同じ開発環境を再現できます。これは、過去のプロジェクトを再開する場合や、オープンソースプロジェクトに貢献する場合などにも非常に役立ちます。

3.6. VS Code とのシームレスな統合

Dev Container は VS Code の公式機能として強力に統合されています。コンテナ内でのファイルの編集、ターミナル操作、デバッグ、Git 操作、拡張機能の利用などが、ローカル環境で作業しているのとほとんど変わらない感覚で行えます。VS Code の使い慣れたインターフェースをそのままに、コンテナのメリットを享受できます。

3.7. 実験や学習が気軽にできる

新しい言語やフレームワーク、ツールを試したい場合でも、ローカル環境にインストールする前に Dev Container で試すことができます。不要になったらコンテナを削除するだけで、ホスト環境を汚す心配がありません。これは、初心者の方が様々な技術に触れてみるのに非常に適しています。

これらのメリットを考えると、特に複数の環境で開発する方や、チームで開発する方、そしてこれからプログラミング学習を本格的に始める方にとって、Dev Container は非常に有用なツールと言えるでしょう。

4. Dev Container を使うための準備

Dev Container を実際に使い始めるために必要なものを確認しましょう。

4.1. 必要なソフトウェア

  1. Visual Studio Code (VS Code): 最新版をインストールしてください。
  2. Docker Desktop または互換性のあるコンテナエンジン: Dev Container は基本的に Docker を使用します。お使いのOSに合わせて Docker Desktop をインストールしてください。Linux の場合は Docker Engine や Podman なども利用可能です。
    • Docker Desktop 公式サイト
    • インストール後、Docker が起動していることを確認してください。ターミナルで docker --version コマンドを実行してバージョンが表示されればOKです。
  3. Git: プロジェクトのソースコードを管理するために必要です。ほとんどの環境にはプリインストールされていることが多いですが、確認しておきましょう。

4.2. VS Code 拡張機能のインストール

VS Code Dev Container を使うためには、関連する拡張機能をインストールする必要があります。

  1. VS Code を開きます。
  2. 左側のアクティビティバーにある Extensions (拡張機能) アイコンをクリックします (Ctrl+Shift+X または Cmd+Shift+X)。
  3. 検索バーに Dev Containers と入力します。
  4. Dev Containers という名前の Microsoft が提供する拡張機能が表示されるので、「Install」（インストール）ボタンをクリックします。
    • この拡張機能は以前 Remote - Containers という名前でしたが、現在は Dev Containers に名称変更されています。

これで、VS Code が Dev Container を操作するための準備が整いました。

5. Dev Container の基本的な使い方 (実践)

実際に簡単なプロジェクトを使って Dev Container を使ってみましょう。ここでは、特別な言語環境が不要な簡単な例として、「Hello, Dev Container!」というテキストファイルを作成するだけのプロジェクトを考えます。

5.1. プロジェクトフォルダの作成

まず、適当な場所に新しいフォルダを作成します。例えば、my-dev-container-project という名前のフォルダをデスクトップなどに作成してください。

bash
mkdir my-dev-container-project
cd my-dev-container-project

このフォルダを VS Code で開きます。「ファイル」>「フォルダーを開く」を選択し、作成したフォルダを選びます。

5.2. Dev Container 設定の追加

VS Code でフォルダを開いたら、Dev Container の設定を追加します。

  1. VS Code のコマンドパレットを開きます。 (Windows/Linux: Ctrl+Shift+P, macOS: Cmd+Shift+P)
  2. Dev Containers: Add Dev Container Configuration Files... と入力し、表示されたコマンドを選択します。
  3. 様々な定義済みコンテナ設定のリストが表示されます。今回はシンプルな例なので、Show All Definitions... を選択します。
  4. さらに多くのリストが表示されます。ここでは、最も基本的な Ubuntu ベースのコンテナを選択してみましょう。Ubuntu と入力して検索し、Ubuntu を選択します。
  5. VS Code の機能の追加を尋ねられる場合がありますが、今回は特に何も選択せずに OK を押します。
  6. プロジェクトのルートディレクトリに .devcontainer という新しいフォルダが作成され、その中に devcontainer.json というファイルが自動的に生成されます。

VS Code の画面右下に「Folder contains a Dev Container configuration file. Reopen folder to develop in a container.」（このフォルダーには Dev Container の設定ファイルが含まれています。コンテナー内で開発するにはフォルダーを開き直してください。）という通知が表示されます。

5.3. コンテナでフォルダを開く

通知が表示されたら、「Reopen in Container」（コンテナーで再度開く）ボタンをクリックします。

もし通知を閉じてしまった場合は、再度コマンドパレットを開き、Dev Containers: Reopen in Container コマンドを選択しても同じことができます。

VS Code が Dev Container のビルドと起動を開始します。

  • 初回はコンテナイメージのダウンロードやビルドに時間がかかることがあります。画面右下に進行状況が表示されます。
  • ビルドが完了し、コンテナが起動すると、VS Code のウィンドウが自動的に再読み込みされます。

VS Code のウィンドウ下部のステータスバーを見てください。左端に >< のようなアイコンと共に、Dev Container: Ubuntu のように表示されているはずです。これは、現在 VS Code がコンテナ内部に接続して動作していることを示しています。

5.4. コンテナ内部での作業

VS Code がコンテナに接続した状態で、ターミナルを開いてみましょう。（「ターミナル」>「新しいターミナル」）

新しいターミナルが開くと、プロンプトがコンテナ内のユーザー名やホスト名になっています。例えば、vscode@<コンテナID> のような表示になっているはずです。

ここで、いくつかのコマンドを実行してみましょう。

  • pwd: 現在のディレクトリが表示されます。コンテナ内の /workspaces/my-dev-container-project のようなパスになっているはずです。このディレクトリは、ホストOS上のプロジェクトフォルダがコンテナ内部にマウントされたものです。
  • ls -a: ファイル一覧が表示されます。ホストOSで作成したプロジェクトフォルダの内容（devcontainer.json ファイルなど）が見えるはずです。
  • whoami: 現在のユーザー名が表示されます。vscode のようになっているはずです。（devcontainer.json の設定によります）
  • cat /etc/os-release: OSのバージョン情報が表示されます。これがコンテナ内のOSの情報です。ホストOSの情報とは異なるはずです。

これらのコマンドから、VS Code のターミナルがホストOSではなく、コンテナ内部で実行されていることがわかります。

5.5. ファイルの作成と確認

コンテナ内部でファイルを操作してみましょう。

VS Code のエクスプローラービューで、新しいファイルを作成します。例えば hello.txt というファイルを作成し、中に Hello, Dev Container! と記述して保存します。

次に、ホストOS側のファイルエクスプローラーで、プロジェクトフォルダ (my-dev-container-project) を確認してみてください。そこに hello.txt ファイルが作成されているはずです。

逆に、ホストOS側で another-file.md というファイルを作成し、VS Code で開いたコンテナ内からそのファイルが見えるか確認してください。エクスプローラーにもターミナル (ls) からも見えるはずです。

このように、VS Code Dev Container では、ホストOS上のプロジェクトフォルダがコンテナ内部にマウントされることで、ファイル共有が実現されています。コード編集はホストOS側のVS Codeで行い、その実行やビルド、デバッグなどはコンテナ内部の環境で行う、というシームレスな連携が可能になります。

5.6. コンテナの停止と再開

VS Code ウィンドウの左下ステータスバーにある Dev Container: Ubuntu の部分をクリックします。

表示されるメニューから、以下の操作ができます。

  • Reopen in Container: 一度コンテナを閉じて、再度同じコンテナで開きます。設定ファイルを変更した場合などに使用します。
  • Close Remote Connection: コンテナとの接続を閉じ、VS Code を通常のローカルモードに戻します。コンテナ自体は起動したままになります。
  • Stop Container: コンテナを停止します。コンテナを使い終わったときや、リソースを解放したいときに使います。
  • Rebuild Container: Dev Container の設定ファイル (devcontainer.json や Dockerfile) を変更した場合に、コンテナをゼロから再構築します。新しいツールやライブラリをコンテナに追加したい場合などに必要です。

コンテナを停止しても、プロジェクトフォルダ自体はホストOSに残っていますし、コンテナ内部で作成・変更したファイルも通常はホストOS側のファイルシステムに保存されています。ただし、コンテナ内部にだけ保存されたファイル（例えば /tmp 以下など、プロジェクトフォルダの外）は、コンテナを停止すると失われる可能性があります。

6. devcontainer.json ファイルの解説

Dev Container の動作をカスタマイズするための中心となるファイルが devcontainer.json です。先ほど自動生成されたファイルを見てみましょう。基本的な Ubuntu の設定ファイルは以下のようになっていることが多いです（バージョンによって多少異なります）。

“`json
// For format details, see https://aka.ms/devcontainer.json. For config options, see the
// README at: https://github.com/devcontainers/templates/tree/main/src/ubuntu
{
“name”: “Ubuntu”,
// Or use a Dockerfile to define dev container contents
“image”: “mcr.microsoft.com/devcontainers/base:ubuntu”,

// Features to add to the dev container. More info: https://containers.dev/features.
// "features": {},

// Use 'forwardPorts' to forward a port from the container to the host.
// "forwardPorts": [],

// Use 'postCreateCommand' to run commands after the container is created.
// "postCreateCommand": "uname -a",

// Configure tool-specific properties.
// "customizations": {},

// Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
// "remoteUser": "root"

}
“`

このファイルには、Dev Container の「設計図」が記述されています。主な設定項目を見ていきましょう。

6.1. name

json
"name": "Ubuntu",
この Dev Container の識別のための名前です。VS Code のステータスバーなどに表示されます。プロジェクト名や環境の目的を表す名前にすると分かりやすいでしょう。

6.2. image または dockerfile または build

json
// "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
"build": {
"dockerfile": "Dockerfile",
// See https://containers.dev/guide/build for details.
"context": ".",
"args": { "VARIANT": "ubuntu-22.04" }
}

ここで、開発コンテナの基となるコンテナイメージを指定します。以下のいずれかの方法を使います。

  • image: 既存のコンテナイメージを直接指定します。docker pull コマンドで取得できるイメージなら何でも指定できます。mcr.microsoft.com/devcontainers/base:ubuntu のように、Microsoft が提供する開発者向けのベースイメージを使うのが一般的です。言語やフレームワークごとの定義済みイメージ (mcr.microsoft.com/devcontainers/python, mcr.microsoft.com/devcontainers/javascript-node など) もあります。
  • dockerfile: プロジェクト内に Dockerfile を作成し、その Dockerfile を使ってコンテナイメージをビルドする場合に指定します。"dockerfile": "Dockerfile" のようにパスを指定します。これにより、ベースイメージに加えて、独自のカスタム設定（追加のパッケージインストール、環境変数設定など）を行うことができます。
  • build: Dockerfile を指定しつつ、ビルドに関する詳細な設定（ビルドコンテキスト、ビルド引数など）を行いたい場合に使います。上記例のように dockerfile と context を指定したり、ビルド時に渡す args を定義したりできます。これが最も柔軟性の高い方法です。

初心者の方はまず image で定義済みのイメージを使ってみるのが簡単です。慣れてきたら build と Dockerfile を使ってカスタマイズしていくのが良いでしょう。

6.3. features

json
"features": {
// "ghcr.io/devcontainers/features/github-cli:1": {
// "version": "latest"
// },
// "ghcr.io/devcontainers/features/common-utils:2": {
// "installZsh": true,
// "upgradePackages": true
// },
// "ghcr.io/devcontainers/features/node:2": {
// "version": "lts"
// }
}

features は、特定のツール、ランタイム、ライブラリなどを Dev Container に簡単に追加するための機能です。Docker Compose の build.args や Dockerfile に RUN apt-get install ... のように手動でコマンドを書かなくても、features の指定だけで必要なものがインストールされます。

features は、ghcr.io/devcontainers/features/<名前>:<バージョン> という形式で指定します。例：
* ghcr.io/devcontainers/features/python: Python をインストール
* ghcr.io/devcontainers/features/node: Node.js をインストール
* ghcr.io/devcontainers/features/java: Java をインストール
* ghcr.io/devcontainers/features/docker-in-docker: コンテナ内で Docker を実行できるようにする
* ghcr.io/devcontainers/features/git: Git をインストール (多くのベースイメージには含まれていますが)

それぞれの feature はオプション（バージョン指定など）を持つことができます。これは非常に便利な機能で、Dev Container の設定を簡潔に保つことができます。どんな features が利用可能かは devcontainers/features や devcontainers/templates リポジトリを参照すると良いでしょう。

6.4. forwardPorts

json
"forwardPorts": [3000, 5000],

コンテナ内部で実行されているアプリケーションのポートを、ホストOS側に転送（フォワード）するための設定です。WebサーバーやAPIサーバーをコンテナ内で実行する場合に必要になります。例えば、コンテナ内のポート3000で動いているWebサーバーに、ホストOSのブラウザから http://localhost:3000 でアクセスできるようになります。複数のポートを指定できます。

6.5. postCreateCommand

json
"postCreateCommand": "pip install -r requirements.txt",

コンテナが作成された後、VS Code がコンテナに接続する直前に一度だけ実行されるコマンドです。プロジェクトに必要なライブラリのインストール（例: Python の pip install -r requirements.txt、Node.js の npm install）、データベースの初期化など、環境構築の最終ステップで必要なコマンドを指定するのに便利です。

6.6. postStartCommand

postStartCommand は、VS Code がコンテナに接続した後、ターミナルが起動する前に毎回実行されるコマンドです。サーバーの起動やサービスの開始など、開発セッションが開始されるたびに実行したいコマンドを指定します。postCreateCommand と似ていますが、実行されるタイミングが異なります。

6.7. initializeCommand

initializeCommand は、Dev Container のビルドや起動プロセス全体が始まる前に実行されるコマンドです。例えば、必要なシークレットを取得したり、ビルドに必要なファイルを準備したりといった用途に使えます。postCreateCommand や postStartCommand よりも早い段階で実行されます。

6.8. customizations

json
"customizations": {
"vscode": {
"settings": {
"python.pythonPath": "/usr/local/bin/python",
"editor.formatOnSave": true
},
"extensions": [
"ms-python.python",
"esbenp.prettier-vscode"
]
}
}

Dev Container 環境に接続した際の VS Code の設定やインストールする拡張機能をカスタマイズする項目です。

  • settings: コンテナ内で有効になる VS Code の設定を JSON 形式で記述します。例えば、使用するPythonインタープリタのパスや、エディタのフォーマット設定などをプロジェクトごとに指定できます。これは、ローカルの VS Code 設定とは独立して管理されます。
  • extensions: コンテナ内で自動的にインストールされる VS Code 拡張機能の ID のリストです。プロジェクトに必要な言語サポートやリンター、フォーマッターなどの拡張機能を指定しておけば、新しいメンバーが環境をセットアップする際に個別に拡張機能をインストールする手間が省けます。

拡張機能の ID は、VS Code の拡張機能ビューで各拡張機能の詳細ページを開き、「歯車アイコン」>「拡張機能IDをコピー」で取得できます。

6.9. remoteUser

json
// "remoteUser": "root"

コンテナ内で VS Code が接続するユーザーを指定します。デフォルトでは、多くのベースイメージに含まれる非rootユーザー（例: vscode）が使用されます。これはセキュリティや権限管理の観点から推奨されます。必要に応じて root ユーザーで接続することも可能ですが、通常は非rootユーザーのままにするのが良いでしょう。

6.10. volumes

json
// "volumes": [
// "../local-data:/var/lib/mysql"
// ]

ホストOSのディレクトリやDockerボリュームを、コンテナ内の特定のパスにマウントする設定です。プロジェクトフォルダのマウントは VS Code が自動的に行いますが、データベースのデータディレクトリやキャッシュ、ログファイルなど、コンテナのライフサイクルを超えて永続化したいデータを管理する場合に volumes を指定します。上記例では、ホストOSのプロジェクトフォルダの親ディレクトリにある local-data を、コンテナ内の /var/lib/mysql にマウントしています。

6.11. その他の重要なプロパティ

他にも、プロジェクトやコンテナの種類に応じて様々な設定項目があります。

  • remoteEnv: コンテナ内で使用する環境変数を定義します。
  • containerEnv: Dev Container が起動する際にコンテナに渡す環境変数を定義します。
  • containerUser: コンテナを実行する際に使用するユーザーを指定します。remoteUser とは異なり、コンテナプロセス自体のユーザーです。
  • mounts: より詳細な方法でボリュームをマウントする場合に使います。
  • runArgs: Docker コンテナを実行する際の追加引数を指定します（例: --privileged）。
  • shutdownAction: VS Code ウィンドウを閉じたときにコンテナをどうするかを指定します (none, stop, kill).
  • waitFor: コンテナが起動した後、特定のサービスやファイルが準備できるまで待機する設定です。

これらの設定項目を適切に使うことで、どんなプロジェクトのどんな開発環境でも、Dev Container として定義し、再現可能な形にすることができます。

7. Dockerfile を使ったカスタム環境構築

devcontainer.json の image プロパティで定義済みのイメージを使うのが簡単ですが、プロジェクトによっては特定のツールやライブラリをコンテナにインストールする必要があります。このような場合は、devcontainer.json の build または dockerfile プロパティを使って Dockerfile を指定し、独自のコンテナイメージをビルドします。

Dockerfile は、コンテナイメージをビルドするための手順を記述したテキストファイルです。

7.1. Dockerfile の基本

簡単な Dockerfile の例を見てみましょう。

“`Dockerfile

ベースイメージを指定

FROM ubuntu:22.04

メンテナー情報 (任意)

LABEL maintainer=”Your Name your.email@example.com“

コンテナ作成時に実行されるコマンド (パッケージのアップデート、ツールのインストールなど)

ここで開発に必要なものをインストールする

RUN apt-get update && apt-get install -y –no-install-recommends \
python3 python3-pip \
git \
&& rm -rf /var/lib/apt/lists/*

デフォルトの作業ディレクトリを設定

VS Code はここを /workspaces/ にマウントする

WORKDIR /workspaces/my-python-project

デフォルトユーザーを作成 (非rootでの開発を推奨)

ARG USERNAME=vscode
ARG USER_UID=1000
ARG USER_GID=1000
RUN groupadd –gid $USER_GID $USERNAME \
&& useradd –uid $USER_UID –gid $USER_GID -m $USERNAME \
&& apt-get update && apt-get install -y sudo \
&& echo $USERNAME ALL=(ALL) NOPASSWD: ALL > /etc/sudoers.d/$USERNAME \
&& chmod 0440 /etc/sudoers.d/$USERNAME \
&& rm -rf /var/lib/apt/lists/*

非rootユーザーに切り替える

USER $USERNAME
“`

この Dockerfile は以下の手順でコンテナイメージを作成します。

  1. FROM ubuntu:22.04: Ubuntu 22.04 の公式イメージをベースとして使用します。
  2. LABEL: イメージに関するメタ情報を設定します。
  3. RUN apt-get update && apt-get install -y ...: パッケージリストを更新し、Python3 と pip、Git をインストールします。--no-install-recommends で不要な推奨パッケージをインストールしないようにし、最後の rm -rf ... で一時ファイルを削除してイメージサイズを小さくしています。
  4. WORKDIR: コンテナ内で作業ディレクトリとなる場所を指定します。VS Code は通常、このパスにプロジェクトフォルダをマウントします。
  5. ARG, RUN groupadd, useradd, sudo 設定: 非rootユーザー (vscode) を作成し、そのユーザーでコマンドを実行できるように sudo を設定しています。これは devcontainer.json の remoteUser がデフォルトで vscode に設定されている場合に合わせたものです。
  6. USER $USERNAME: 以降のコマンドを非rootユーザーで実行するように切り替えます。

7.2. devcontainer.json と Dockerfile の連携

この Dockerfile を使用する場合、devcontainer.json は以下のように記述します。

“`json
{
“name”: “Python Environment”,
“build”: {
“dockerfile”: “Dockerfile”, // 同じディレクトリにある Dockerfile を指定
“context”: “.”, // プロジェクトルートをビルドコンテキストとする
“args”: { // Dockerfile に渡すビルド引数
“VARIANT”: “ubuntu-22.04”, // Dockerfile側で使用していないが例として
“USER_UID”: 1000,
“USER_GID”: 1000
}
},

"features": {
    // Dockerfileでインストールしたが、featuresを使うとより簡単かも
    // "ghcr.io/devcontainers/features/python:1": {
    //     "version": "3.10"
    // }
},

"customizations": {
    "vscode": {
        "settings": {
            "python.defaultInterpreterPath": "/usr/local/bin/python"
        },
        "extensions": [
            "ms-python.python"
        ]
    }
},

// postCreateCommandでPythonの依存ライブラリをインストール
"postCreateCommand": "pip install -r requirements.txt",

"remoteUser": "vscode" // Dockerfileで作成した非rootユーザー

}
“`

このように、build.dockerfile で Dockerfile を指定し、postCreateCommand でコンテナ起動後に実行したいコマンド（例: Python の依存ライブラリインストール）を指定します。customizations で VS Code の設定や拡張機能を指定すれば、Python 開発に最適化された Dev Container 環境が完成します。

プロジェクトに requirements.txt (Python), package.json (Node.js), Gemfile (Ruby) などの依存ライブラリ管理ファイルがあれば、postCreateCommand でそれらをインストールするように設定するのが一般的です。

Dockerfile を使うことで、ベースイメージに加えて、OSレベルのパッケージや特定の構成（例: SSHサーバーの起動、特定の環境変数の設定）など、features だけでは難しい詳細なカスタマイズが可能になります。

8. 応用的な Dev Container の使い方

Dev Container はさらに様々な応用が可能です。いくつか例を見てみましょう。

8.1. 複数のサービスを持つプロジェクト (docker-compose)

Webアプリケーション開発など、プロジェクトが複数のサービス（例: Webサーバー、データベース、キャッシュサーバー）で構成されている場合、それらを全て単一の Dev Container 内に詰め込むのは管理が難しくなります。

このような場合は、Docker Compose を使って複数のコンテナを連携させた開発環境を構築し、そのうちの「メイン」となるコンテナを Dev Container として使用するのが一般的です。

devcontainer.json で dockerComposeFile と service プロパティを指定します。

“`json
// .devcontainer/devcontainer.json
{
“name”: “My Multi-Service Project”,
“dockerComposeFile”: [“../docker-compose.yml”], // docker-compose.yml へのパス
“service”: “app”, // docker-compose.yml で定義された、VS Code が接続するサービス名

"workspaceFolder": "/workspaces/my-multi-service-project", // コンテナ内の作業ディレクトリ

"customizations": {
    "vscode": {
        "settings": {},
        "extensions": []
    }
},

"forwardPorts": [8000, 5432], // WebサーバーとDBのポートを転送
"postCreateCommand": "cd /workspaces/my-multi-service-project && ./setup.sh", // 初期設定スクリプト実行
"remoteUser": "vscode"

}
“`

そして、プロジェクトのルートなどに docker-compose.yml ファイルを作成します。

“`yaml

docker-compose.yml

version: ‘3.8’

services:
app: # VS Code が接続するサービス (devcontainer.json の service で指定)
build:
context: . # プロジェクトルートをビルドコンテキストとする
dockerfile: ./.devcontainer/Dockerfile # アプリケーションコンテナの Dockerfile
volumes:
– .:/workspaces/my-multi-service-project:cached # プロジェクトフォルダをマウント
ports:
– “8000:8000” # Webサーバーのポート
depends_on:
– db # dbサービスが起動してからappサービスを起動

db: # データベースサービス
image: postgres:14
volumes:
– db_data:/var/lib/postgresql/data # DBデータを永続化
environment: # DB接続情報などの環境変数
POSTGRES_DB: mydb
POSTGRES_USER: user
POSTGRES_PASSWORD: password
ports:
– “5432:5432” # DBのポート

volumes:
db_data: # DBデータ用のDockerボリューム
“`

この構成では、VS Code は docker-compose.yml を読み込み、app サービスとして定義されたコンテナに接続します。この app コンテナからは db コンテナにアクセスできるようになります。データベースのデータは db_data という名前付きボリュームに保存されるため、コンテナを再起動してもデータは失われません。

Docker Compose を使うことで、より複雑なアプリケーション構成全体を Dev Container 環境の一部として管理できるようになります。

8.2. ボリュームのマウント

先ほどの Docker Compose の例でも出てきましたが、volumes は Dev Container において重要な役割を果たします。VS Code Dev Container は、デフォルトでプロジェクトフォルダをコンテナ内の /workspaces/<プロジェクト名> にバインドマウントします。これにより、ホストOS側の VS Code から直接コンテナ内のファイルを編集できます。

これに加えて、devcontainer.json の volumes プロパティや、Docker Compose の volumes セクションを使って、他のボリュームを追加でマウントできます。

  • バインドマウント: ホストOS上の特定のディレクトリをコンテナ内にマウントします。例: ../local-data:/var/lib/mysql。ホストOS側のファイルシステム構造に依存します。
  • 名前付きボリューム (Named Volumes): Dockerが管理するボリュームを作成し、それをコンテナ内にマウントします。例: db_data:/var/lib/postgresql/data。データの永続化に最適で、ホストOSの特定のパスに依存しません。Dockerによって管理されるため、パフォーマンスが良い場合もあります。

開発中に生成されるデータ（ログ、キャッシュ、データベースファイル、コンパイル済みバイナリなど）のうち、コンテナの再ビルドや停止・起動後も保持したいものは、適切にボリュームにマウントすることを検討しましょう。

8.3. 環境変数とシークレット

開発環境によっては、APIキーやデータベースの認証情報など、機密性の高い情報（シークレット）を環境変数としてコンテナに渡す必要があります。

  • .env ファイル: .devcontainer/.env ファイルを作成し、そこに環境変数を記述する方法が簡単です。devcontainer.json に remoteEnv や containerEnv で .env ファイルを参照するように設定できます。例：
    json
    // .devcontainer/devcontainer.json
    {
    // ... other settings
    "containerEnv": {
    "MY_API_KEY": "${localEnv:MY_API_KEY}" // ホストOSの環境変数を引き継ぐ場合
    },
    // もしくは、.envファイルを使う場合 (Docker Composeの方が一般的)
    // Docker Composeを使う場合は、docker-compose.ymlでenv_fileを指定するのが最も一般的
    }
    ini
    # .devcontainer/.env
    DATABASE_URL=postgres://user:password@db:5432/mydb
  • Docker Compose: docker-compose.yml ファイルの environment セクションや env_file セクションを使うのが一般的です。
    yaml
    # docker-compose.yml
    services:
    app:
    environment:
    NODE_ENV: development
    env_file:
    - ./.env # プロジェクトルートの.envファイルを読み込む
    .env ファイルは Git リポジトリに含めないように注意が必要です（.gitignore に追加）。

8.4. 既存プロジェクトへの Dev Container 導入

既に開発中のプロジェクトに Dev Container を導入する場合も、手順はほぼ同じです。

  1. プロジェクトルートに .devcontainer ディレクトリを作成します。
  2. devcontainer.json ファイルを作成します。VS Code のコマンドパレット Dev Containers: Add Dev Container Configuration Files... を使うのが便利です。プロジェクトの言語やフレームワークに合わせて適切な定義済みテンプレートを選択します。
  3. 生成された devcontainer.json を編集し、プロジェクトに必要な設定（依存ライブラリのインストールコマンド、VS Code 拡張機能、ポートフォワーディングなど）を追加します。必要であれば Dockerfile や docker-compose.yml を作成・編集します。
  4. VS Code でプロジェクトを開き、「Reopen in Container」します。
  5. コンテナ内でプロジェクトが正しくビルド・実行できるか確認します。足りないツールがあれば devcontainer.json や Dockerfile を修正し、「Rebuild Container」を繰り返します。

一度 Dev Container 環境が完成したら、その設定ファイルを Git にコミットし、チームメンバーと共有します。

8.5. GitHub Codespaces との連携

GitHub Codespaces は、GitHub が提供するクラウドベースの開発環境です。これは Dev Container の仕組みをベースにしており、リポジトリに devcontainer.json が含まれていれば、ブラウザ上やローカルの VS Code から、設定済みの開発環境をすぐに起動できます。Dev Container は、ローカル環境だけでなく、このようなクラウド環境でもシームレスに動作するための基盤となります。

9. トラブルシューティング

Dev Container の利用中に発生しやすい一般的な問題と、その解決策を見ていきましょう。

9.1. コンテナのビルドまたは起動に失敗する

  • Docker が起動しているか確認: まず、Docker Desktop (または使用しているコンテナエンジン) が正しく起動しているか確認してください。
  • Dockerfile や docker-compose.yml のエラー: docker build や docker-compose up が成功するか、単体で試してみてください。シンタックスエラーや参照ファイルのパス間違いなどが原因でビルドに失敗することがあります。VS Code の出力ウィンドウ（View > Output, そしてドロップダウンで Log (Dev Container) を選択）に詳細なエラーログが出力されているはずなので、確認しましょう。
  • ネットワーク問題: コンテナイメージのダウンロードやパッケージのインストールに失敗する場合、ネットワーク接続に問題があるか、ファイアウォールがDockerの通信をブロックしている可能性があります。
  • リソース不足: コンテナのビルドや実行にはメモリやCPUリソースが必要です。マシンのスペックが不足している場合、処理が遅くなったり失敗したりすることがあります。Docker Desktop の設定で利用可能なリソースを確認・調整してみてください。
  • 権限問題: 特に Linux 環境で Docker をルート権限なしで実行するための設定が正しく行われていない場合、コンテナの操作に失敗することがあります。

9.2. VS Code 拡張機能がコンテナ内で動作しない

  • 拡張機能がコンテナに対応しているか確認: 全ての VS Code 拡張機能がリモート環境 (Dev Container, Remote SSH, WSLなど) に対応しているわけではありません。拡張機能マーケットプレイスで、対応状況を確認してください。対応している場合でも、コンテナ内で動作させるための特別な設定が必要な場合があります。
  • devcontainer.json の extensions に追加したか確認: 自動インストールしたい拡張機能は customizations.vscode.extensions にリストアップする必要があります。
  • 拡張機能の依存関係不足: 拡張機能がコンテナ内の特定のツールやライブラリに依存している場合があります。Dockerfile や features を使って、必要な依存関係をコンテナにインストールしてください。

9.3. ファイルの権限問題

  • ホストOSとコンテナのユーザー/グループIDの不一致: プロジェクトフォルダがホストOSとコンテナ間で共有される際、ファイルを作成・変更するユーザーの権限によって問題が発生することがあります。ホストOSのユーザーID/グループIDとコンテナ内のユーザーID/グループIDを一致させるように Dockerfile や devcontainer.json (特に remoteUser と Dockerfile のユーザー作成部分) を設定すると、権限の問題を防ぎやすくなります。VS Code の Dev Containers: Rebuild Container コマンドを実行する際に表示されるログに、ホストOSのUID/GIDが表示されることがあります。
  • パーミッションエラー: コンテナ内部でファイル操作をする際に、ファイルやディレクトリのパーミッションが不適切でエラーになることがあります。chmod や chown コマンドを postCreateCommand や Dockerfile の RUN 命令で実行して、パーミッションを調整する必要があるかもしれません。

9.4. ポートフォワーディングがうまくいかない

  • devcontainer.json の forwardPorts 設定を確認: 転送したいポート番号が正しく設定されているか確認してください。
  • コンテナ内でアプリケーションが起動しているか確認: アプリケーションがコンテナ内の指定ポートで実際にリッスンしているか確認してください。コンテナのターミナルから curl localhost:<port> などで確認できます。
  • ファイアウォールの設定: ホストOSのファイアウォールが、コンテナからの接続や指定ポートへのアクセスをブロックしている可能性があります。
  • 競合するポート: ホストOS側で既に同じポート番号を使用しているアプリケーションがないか確認してください。

9.5. パフォーマンスの問題

  • ボリュームのマウントタイプ: バインドマウントはホストOSとコンテナ間でファイルシステム操作が頻繁に行われるため、特に多くのファイルがあるプロジェクトではパフォーマンスが低下することがあります。Docker Desktop の設定で、バインドマウントのパフォーマンス設定（ファイル共有など）を確認したり、可能であれば名前付きボリュームの利用を検討したりしてください。Docker Compose の volumes 設定で :cached や :delegated オプションを試すのも有効な場合があります。
  • コンテナのリソース制限: Docker Desktop の設定で、コンテナが使用できるCPUやメモリのリソースに制限がかかっているか確認してください。必要に応じて制限を緩和します。
  • 不要なプロセス: コンテナ内で不要なプロセスがリソースを消費していないか確認してください。

トラブルシューティングを行う際は、VS Code の出力ウィンドウ (Log (Dev Container))、Docker Desktop のログ、そしてコンテナ内部のターミナルで直接コマンドを実行してエラーメッセージを確認することが非常に重要です。

10. Dev Container を使う上でのベストプラクティス

Dev Container を効果的に活用するために、いくつかのベストプラクティスがあります。

  • devcontainer.json をバージョン管理する: devcontainer.json ファイルとその関連ファイル (Dockerfile, docker-compose.yml, .env など) は、プロジェクトの重要な設定の一部です。これらを Git でバージョン管理し、チームメンバーと共有することで、環境の再現性と一貫性が保たれます。
  • Dockerfile や features を活用する: 開発に必要なツールやライブラリのインストールは、手動ではなく Dockerfile や features を使って自動化します。これにより、誰でも同じ環境を再現できるようになります。
  • コンテナを軽量に保つ: 開発に必要なものだけをコンテナに含めるように心がけましょう。不要なパッケージやサービスを含めると、イメージサイズが大きくなり、ビルド時間や起動時間が長くなります。
  • 非rootユーザーで開発する: セキュリティのため、コンテナ内部では可能な限り非rootユーザー (remoteUser) で作業するように設定しましょう。
  • 依存ライブラリのインストールは postCreateCommand で行う: プロジェクト固有の依存ライブラリ（例: pip install -r requirements.txt）は、コンテナイメージのビルド時ではなく、コンテナ作成後の postCreateCommand でインストールするのが一般的です。これにより、コードの変更（例: requirements.txt の変更）があっても、コンテナイメージ自体を再ビルドする回数を減らし、開発サイクルを高速化できます。
  • VS Code 拡張機能と設定を customizations に含める: プロジェクト推奨の VS Code 拡張機能やワークスペース設定は customizations.vscode に記述します。これにより、新しいメンバーがプロジェクトを VS Code で開くだけで、最適な開発環境とエディタ設定が自動的に適用されます。
  • ボリュームの適切な使用: 永続化が必要なデータ（DBデータ、ログ、キャッシュなど）はボリュームにマウントします。一時的なファイルやビルド成果物は、特に理由がなければボリュームにマウントせず、コンテナ内部に置くことも検討します（ただし、コンテナを削除すると失われる点に注意）。
  • ドキュメントを作成する: Dev Container を導入したら、その使い方や、もし必要な手動手順があれば、プロジェクトの README ファイルなどに明確に記述しておきましょう。

これらのベストプラクティスに従うことで、Dev Container のメリットを最大限に引き出し、より効率的で快適な開発環境を構築できます。

11. まとめと次のステップ

この記事では、VS Code Dev Container がなぜ必要とされるのかという背景から、その基本的な概念、メリット、具体的な使い方、そして devcontainer.json の詳細、Dockerfile を使ったカスタマイズ、さらには応用的な使い方やトラブルシューティング、ベストプラクティスまで、初心者向けに幅広く解説しました。

Dev Container は、開発環境の構築と管理に関する多くの課題を解決し、特にチーム開発や複数のプロジェクトに関わる開発者にとって非常に強力なツールです。また、プログラミング学習者にとっても、環境構築の複雑さから解放され、コードを書くことに集中できるようになるという大きなメリットがあります。

最初から全ての機能を使いこなす必要はありません。まずは簡単なプロジェクトで Dev Container を使ってみるところから始めてみましょう。VS Code のコマンドパレットから定義済みのテンプレートを選んで devcontainer.json を生成し、「Reopen in Container」してみてください。それだけで、開発環境の構築がいかに簡単になるかを実感できるはずです。

そして、徐々に devcontainer.json の設定項目をカスタマイズしたり、Dockerfile を使って必要なツールを追加したり、Docker Compose で複数のサービスを連携させたりと、ステップアップしていくのがおすすめです。

Dev Container は、開発環境をコードとして管理し、再現可能にする「Infrastructure as Code (IaC)」の一歩とも言えます。この概念は、モダンなソフトウェア開発においてますます重要になっています。

ぜひ今日から Dev Container を試してみて、あなたの開発ライフをよりスムーズで快適なものにしてください！

次のステップとして:

  • あなたの現在のプロジェクト、またはこれから始める新しいプロジェクトに Dev Container を導入してみましょう。
  • devcontainer.json の様々な設定項目（特に features と customizations）を試してみてください。
  • もし必要であれば、Dockerfile を使って独自のコンテナイメージを構築する方法を学んでみましょう。
  • チーム開発を行っている場合は、チームメンバーに Dev Container の利用を提案し、環境の統一を図りましょう。
  • GitHub Codespaces を試して、クラウド上での Dev Container 体験をしてみてください。

この記事が、あなたの Dev Container 活用の一助となれば幸いです。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール