VS Code Dev Containers(リファレンス日本語ver)

#DevContainers

Posted at 2025-06-22

VS Code Dev Containers 完全ガイド

概要
はじめに
システム要件
インストール
クイックスタートの選択
クイックスタート1: 開発コンテナを試す
クイックスタート2: 既存フォルダをコンテナで開く
クイックスタート3: GitリポジトリやPRを独立したコンテナボリュームで開く
ワークスペースの信頼
devcontainer.jsonファイルの作成
Dev Container Features
開発コンテナイメージのプリビルド
ボリュームの検査
拡張機能の管理
ポートの転送または公開
ターミナルの起動
コンテナでのデバッグ
コンテナ固有の設定
コンテナの管理
Dotfileリポジトリでのカスタマイズ
既知の制限事項
高度なコンテナ設定
devcontainer.jsonリファレンス
質問やフィードバック
次のステップ

概要

Visual Studio Code Dev Containers拡張機能を使用すると、コンテナを本格的な開発環境として使用できます。フォルダをコンテナ内で（またはコンテナにマウントして）開き、Visual Studio Codeの全機能セットを活用できます。プロジェクト内のdevcontainer.jsonファイルが、明確に定義されたツールとランタイムスタックを持つ開発コンテナにVS Codeがアクセス（または作成）する方法を指示します。このコンテナは、アプリケーションの実行や、コードベースでの作業に必要なツール、ライブラリ、ランタイムを分離するために使用できます。

ワークスペースファイルはローカルファイルシステムからマウントされるか、コンテナにコピーまたはクローンされます。拡張機能はコンテナ内でインストールおよび実行され、ツール、プラットフォーム、ファイルシステムへのフルアクセスを持ちます。これにより、異なるコンテナに接続するだけで開発環境全体をシームレスに切り替えることができます。

これにより、VS Codeは、ツール（またはコード）の場所に関係なく、完全なIntelliSense（補完）、コードナビゲーション、デバッグを含むローカル品質の開発体験を提供できます。

Dev Containers拡張機能は、2つの主要な操作モデルをサポートしています：

フルタイム開発環境：コンテナをフルタイムの開発環境として使用
実行中のコンテナへのアタッチ：実行中のコンテナにアタッチして検査

注意: Dev Containers拡張機能は、オープンなDev Containers仕様をサポートしており、誰でもあらゆるツールで一貫した開発環境を設定できます。詳細はdev container FAQおよび仕様サイトcontainers.devをご覧ください。

はじめに

注意: dev containersを素早く起動して実行する方法については、入門編のDev Containers tutorialをご覧ください。

システム要件

ローカル/リモートホスト

Dev Containers拡張機能でDockerを使用する方法は以下のとおりです：

ローカルにインストールされたDocker
リモート環境にインストールされたDocker
その他のDocker準拠CLI（ローカルまたはリモートにインストール）

他のCLIも動作する可能性がありますが、正式にはサポートされていません。なお、Kubernetesクラスターへのアタッチには、適切に設定されたkubectl CLIのみが必要です。

代替Dockerオプションドキュメントで詳細を確認できます。

ローカルまたはリモートホストでDockerを設定する具体的な方法：

Windows

Docker Desktop 2.0+ on Windows 10 Pro/Enterprise
Windows 10 Home (2004+)には Docker Desktop 2.3+ とWSL 2バックエンドが必要
Docker ToolboxおよびWindowsコンテナイメージはサポートされていません

macOS

Docker Desktop 2.0+

Linux

Docker CE/EE 18.06+ および Docker Compose 1.21+
Ubuntu snapパッケージはサポートされていません

リモートホスト

1 GB RAMが必要ですが、少なくとも2 GB RAMと2コアCPUを推奨

コンテナ

サポートされるコンテナ：

x86_64 / ARMv7l (AArch32) / ARMv8l (AArch64) Debian 9+、Ubuntu 16.04+、CentOS / RHEL 7+
x86_64 Alpine Linux 3.9+

その他のglibcベースのLinuxコンテナも、必要なLinux前提条件があれば動作する可能性があります。

インストール

開始するには、以下の手順に従ってください：

1. Dockerのインストールと設定

お使いのオペレーティングシステム用にDockerをインストールし、以下のパスまたは代替Dockerオプション（リモートホスト上のDockerやDocker準拠CLIなど）を使用してください。

Windows / macOS

Docker Desktop for Windows/Macをインストール
Windows上でWSL 2を使用している場合、WSL 2バックエンドが有効になっていることを確認：
- Dockerタスクバーアイテムを右クリックして「Settings」を選択
- 「Use the WSL 2 based engine」をチェック
- 「Resources > WSL Integration」でディストリビューションが有効になっていることを確認
WSL 2バックエンドを使用していない場合：
- Dockerタスクバーアイテムを右クリックして「Settings」を選択
- 「Resources > File Sharing」でソースコードが保存されている場所を更新
- トラブルシューティングについてはヒントとコツを参照

Linux

お使いのディストリビューション用のDocker CE/EE公式インストール手順に従う
Docker Composeを使用する場合は、Docker Composeの手順も実行
ターミナルで以下を実行して、ユーザーをdockerグループに追加：
```
sudo usermod -aG docker $USER
```
変更を有効にするため、一度サインアウトして再度サインイン

2. Visual Studio Codeのインストール

Visual Studio CodeまたはVisual Studio Code Insidersをインストールします。

3. Dev Containers拡張機能のインストール

Dev Containers拡張機能をインストールします。VS Codeで他のリモート拡張機能と一緒に作業する予定がある場合は、Remote Development拡張機能パックのインストールを選択できます。

Gitで作業している場合の設定

以下の2つのヒントを検討してください：

Windows環境とコンテナ内の両方で同じリポジトリを使用する場合：一貫した行末を設定してください。詳細はヒントとコツを参照
Git認証情報マネージャーを使用してクローンする場合：コンテナは既に認証情報にアクセスできるはずです。SSHキーを使用する場合は、共有を選択することもできます。詳細はコンテナとのGit認証情報の共有を参照

クイックスタートの選択

このドキュメントには3つのクイックスタートが含まれています。ワークフローと興味に最も適したものから始めることをお勧めします：

クイックサンプルリポジトリで開発コンテナを試したい場合：クイックスタート1: 開発コンテナを試すをチェック
既存のローカルクローンプロジェクトに開発コンテナを追加したい場合：クイックスタート2: 既存フォルダをコンテナで開くをチェック
リポジトリの独立したコピーで作業したい場合（PRのレビューやローカル作業に影響を与えずにブランチを調査するなど）：クイックスタート3: GitリポジトリやPRを独立したコンテナボリュームで開くをチェック

クイックスタート1: 開発コンテナを試す

最も簡単な開始方法は、サンプル開発コンテナの1つを試すことです。コンテナチュートリアルでは、DockerとDev Containers拡張機能の設定を説明し、サンプルを選択できます。

注意: VS CodeとDockerが既にインストールされている場合は、open in dev containerを使用できます。詳細とリポジトリへの追加方法については、開発コンテナガイドの作成をご覧ください。

クイックスタート2: 既存フォルダをコンテナで開く

このクイックスタートでは、ファイルシステム上の既存のソースコードを使用して、フルタイム開発環境として使用する既存プロジェクト用の開発コンテナを設定する方法について説明します。以下の手順に従ってください：

手順1: フォルダを選択してコンテナ設定を開始

VS Codeを起動
コマンドパレット（F1）または「quick actions」ステータスバーアイテムから「Dev Containers: Open Folder in Container...」コマンドを実行
コンテナを設定するプロジェクトフォルダを選択

ヒント: フォルダを開く前にコンテナの内容や設定を編集したい場合は、代わりに「Dev Containers: Add Dev Container Configuration Files...」を実行できます。

手順2: 開発コンテナの開始点を選択

開発コンテナの開始点を選択します。以下のオプションがあります：

フィルタリング可能なリストからベースDev Containerテンプレートを選択
既存のDockerfileまたはDocker Composeファイルを使用（選択したフォルダに存在する場合）

注意: Alpine Linuxコンテナを使用する場合、拡張機能内のネイティブコードのglibc依存関係により、一部の拡張機能が動作しない可能性があります。

リストは、開いたフォルダの内容に基づいて自動的にソートされます。

追加のFeaturesでdev containerをカスタマイズできる場合があります。詳細は下記をご覧ください。

表示されるdev container Templatesは、Dev Container仕様の一部であるファーストパーティおよびコミュニティインデックスから取得されます。仕様の一部としてdevcontainers/templatesリポジトリでTemplatesのセットをホストしています。各Templateの内容を確認するには、そのリポジトリのsrcフォルダを参照してください。

dev container CLIを使用して、独自のdev container Templatesを公開および配布することもできます。

手順3: 設定ファイルの追加とビルド

コンテナの開始点を選択後、VS Codeは開発コンテナ設定ファイル（.devcontainer/devcontainer.json）をプロジェクトに追加
VS Codeウィンドウがリロードされ、開発コンテナのビルドが開始
進行状況通知でステータス更新を提供
開発コンテナを初回に開く時のみビルドが必要。初回の成功後は、フォルダを開くのがはるかに高速

手順4: コンテナへの接続

ビルド完了後、VS Codeは自動的にコンテナに接続します。

これで、プロジェクトをローカルで開いた時と同様に、VS Codeでプロジェクトとやり取りできます。今後、プロジェクトフォルダを開くと、VS Codeは自動的に開発コンテナ設定を検出して再利用します。

ヒント: リモートDockerホストを使用したい場合は、リモートSSHホスト上のフォルダをコンテナで開くのセクションを参照してください。

このアプローチでローカルファイルシステムをコンテナにバインドマウントすることは便利ですが、WindowsとmacOSでパフォーマンスオーバーヘッドがあります。ディスクパフォーマンスを向上させるいくつかの技術を適用するか、代わりに独立したコンテナボリュームを使用してリポジトリをコンテナで開くことができます。

WindowsでWSL 2フォルダをコンテナで開く

Windows Subsystem for Linux v2 (WSL 2)を使用し、Docker DesktopのWSL 2バックエンドを有効にしている場合、WSL内に保存されたソースコードで作業できます！

WSL 2エンジンが有効になったら、以下のいずれかを選択できます：

WSL拡張機能を使用して既に開いたフォルダから「Dev Containers: Reopen in Container」コマンドを使用
コマンドパレット（F1）から「Dev Containers: Open Folder in Container...」を選択し、ローカル\\wsl$共有（Windowsサイドから）を使用してWSLフォルダを選択

残りのクイックスタートはそのまま適用されます！詳細はWSL拡張機能のドキュメントをご覧ください。

リモートSSHホスト上のフォルダをコンテナで開く

LinuxまたはmacOS SSHホストを使用している場合、Remote - SSHとDev Containers拡張機能を一緒に使用できます。Dockerクライアントをローカルにインストールする必要さえありません。

手順：

Remote - SSH拡張機能のインストールおよびSSHホスト設定手順に従う
オプション：パスワードを複数回入力する必要がないよう、サーバーへのSSHキーベース認証を設定
SSHホストにDockerをインストール（ローカルにDockerをインストールする必要はありません）
Remote - SSH拡張機能のクイックスタートに従ってホストに接続し、そこでフォルダを開く
コマンドパレット（F1、⇧⌘P（Windows、Linux Ctrl+Shift+P））から「Dev Containers: Reopen in Container」コマンドを使用

残りのDev Containersクイックスタートはそのまま適用されます。詳細はRemote - SSH拡張機能のドキュメントをご覧ください。このモデルがニーズに合わない場合の他のオプションについては、リモートDockerホストでの開発記事もご覧ください。

リモートTunnelホスト上のフォルダをコンテナで開く

Remote - TunnelsとDev Containers拡張機能を一緒に使用して、リモートホスト上のフォルダをコンテナ内で開くことができます。Dockerクライアントをローカルにインストールする必要さえありません。これは上記のSSHホストシナリオと似ていますが、Remote - SSHの代わりにRemote - Tunnelsを使用します。

手順：

Remote - Tunnels拡張機能のはじめに手順に従う
トンネルホストにDockerをインストール（ローカルにDockerをインストールする必要はありません）
Remote - Tunnels拡張機能の手順に従ってトンネルホストに接続し、そこでフォルダを開く
コマンドパレット（F1、⇧⌘P（Windows、Linux Ctrl+Shift+P））から「Dev Containers: Reopen in Container」コマンドを使用

残りのDev Containersクイックスタートはそのまま適用されます。詳細はRemote - Tunnels拡張機能のドキュメントをご覧ください。このモデルがニーズに合わない場合の他のオプションについては、リモートDockerホストでの開発記事もご覧ください。

既存のワークスペースをコンテナで開く

ワークスペースが.code-workspaceファイルのあるフォルダのサブフォルダへの相対パスのみを参照している場合（またはフォルダ自体）、VS Codeマルチルートワークスペースを単一のコンテナで開く同様のプロセスに従うこともできます。

以下のいずれかを実行できます：

「Dev Containers: Open Workspace in Container...」コマンドを使用
コンテナ内に.code-workspaceファイルを含むフォルダを開いた後、「File > Open Workspace...」を使用

接続後、.devcontainerフォルダがまだ表示されていない場合は、その内容を簡単に編集できるようワークスペースに追加することをお勧めします。

また、同じVS Codeウィンドウで同じワークスペースに複数のコンテナを使用することはできませんが、別々のウィンドウから複数のDocker Compose管理コンテナを同時に使用できます。

クイックスタート3: GitリポジトリやPRを独立したコンテナボリュームで開く

ローカルクローンリポジトリをコンテナで開くことはできますが、PRレビューや作業に影響を与えずに他のブランチを調査するために、リポジトリの独立したコピーで作業したい場合もあります。

Repository Containersは、ローカルファイルシステムへのバインドの代わりに、独立したローカルDockerボリュームを使用します。ファイルツリーを汚染しないことに加えて、ローカルボリュームはWindowsとmacOSでパフォーマンスが向上するという利点があります。（これらのタイプのボリュームを他のシナリオで使用する方法については、高度な設定のディスクパフォーマンスの向上記事を参照してください。）

例えば、「try」リポジトリの1つをRepository Containerで開く手順：

手順1: リポジトリクローンコマンドの実行

VS Codeを起動
コマンドパレット（F1）から「Dev Containers: Clone Repository in Container Volume...」を実行

手順2: リポジトリの指定

表示される入力ボックスに以下のいずれかを入力してEnterを押します：

microsoft/vscode-remote-try-node（または他の「try」リポジトリ）
Git URI
GitHubブランチURL
GitHub PR URL

ヒント: プライベートリポジトリを選択した場合、認証情報マネージャーの設定やSSHキーをSSHエージェントに追加することをお勧めします。詳細はコンテナとのGit認証情報の共有を参照してください。

手順3: 開発環境の選択

リポジトリに.devcontainer/devcontainer.jsonファイルがない場合、以下から開始点の選択を求められます：

フィルタリング可能なリストからの開始点
既存のDockerfileまたはDocker Composeファイル（存在する場合）

注意: Alpine Linuxコンテナを使用する場合、拡張機能内のネイティブコードのglibc依存関係により、一部の拡張機能が動作しない可能性があります。

リストは開いたフォルダの内容に基づいて自動的にソートされます。表示されるdev container Templatesは、Dev Container仕様の一部であるファーストパーティおよびコミュニティインデックスから取得されます。

手順4: ビルドと接続

VS Codeウィンドウ（インスタンス）がリロードされ、ソースコードをクローンし、開発コンテナのビルドを開始
進行状況通知でステータス更新を提供
手順2でGitHub pull request URLを貼り付けた場合、PRが自動的にチェックアウトされ、GitHub Pull Requests拡張機能がコンテナにインストールされます

ビルド完了後、VS Codeは自動的にコンテナに接続します。この独立した環境で、コードをローカルでクローンした場合と同様にリポジトリソースコードで作業できます。

注意: Dockerビルドエラーなどでコンテナの起動に失敗した場合、表示されるダイアログで「Reopen in Recovery Container」を選択して「リカバリコンテナ」に入ることができます。これにより、Dockerfileや他のコンテンツを編集できます。クローンしたリポジトリのあるdockerボリュームを最小限のコンテナで開き、作成ログを表示します。修正が完了したら、「Reopen in Container」を使用して再試行してください。

ヒント: リモートDockerホストを使用したい場合は、リモートSSHホスト上のフォルダをコンテナで開くのセクションを参照してください。

ワークスペースの信頼

Visual Studio Codeはセキュリティを重視し、ソースや元の作成者に関係なく、安全にコードを閲覧・編集できるようサポートします。ワークスペース信頼機能では、プロジェクトフォルダで自動コード実行を許可するか制限するかを決定できます。

Dev Containers拡張機能はワークスペース信頼を採用しています。ソースコードを開いて操作する方法に応じて、さまざまなタイミングで編集または実行するコードを信頼するかどうかの決定を求められます。

コンテナでフォルダを再度開く

既存プロジェクト用の開発コンテナを設定するには、ローカル（またはWSL）フォルダを信頼する必要があります。ウィンドウがリロードされる前に、ローカル（またはWSL）フォルダを信頼するよう求められます。

このフローには以下の例外があります：

最近のエントリをクリックした場合
「Open Folder in Container」コマンドを使用すると、信頼がまだ与えられていない場合、ウィンドウのリロード後に信頼を求められます

既存のコンテナにアタッチ

既存のコンテナにアタッチする場合、アタッチすることがコンテナを信頼することを意味するという確認を求められます。これは一度だけ確認されます。

ボリュームでリポジトリをクローン

コンテナボリュームでリポジトリをクローンする場合、リポジトリをクローンすることがリポジトリを信頼することを意味するという確認を求められます。これは一度だけ確認されます。

ボリュームの検査

ボリュームの検査は制限モードで開始され、コンテナ内のフォルダを信頼できます。

Dockerデーモンのリモート実行

これはDockerデーモンが実行されているマシンを信頼することを意味します。追加の確認プロンプトはありません（上記のローカル/WSLケースのリストのみ）。

devcontainer.jsonファイルの作成

VS Codeのコンテナ設定はdevcontainer.jsonファイルに保存されます。このファイルはデバッグ設定のlaunch.jsonファイルに似ていますが、開発コンテナの起動（またはアタッチ）に使用されます。コンテナの実行後にインストールする拡張機能や、環境を準備するためのpost-createコマンドも指定できます。dev container設定は.devcontainer/devcontainer.jsonの下に配置されるか、プロジェクトのルートに.devcontainer.jsonファイル（ドット接頭辞に注意）として保存されます。

コマンドパレット（F1）から「Dev Containers: Add Dev Container Configuration Files...」コマンドを選択すると、必要なファイルが開始点としてプロジェクトに追加され、ニーズに合わせてさらにカスタマイズできます。このコマンドでは、フォルダの内容に基づいてリストから事前定義されたコンテナ設定を選択したり、既存のDockerfileや既存のDocker Composeファイルを再利用したりできます。

devcontainer.jsonを手動で作成し、任意のイメージ、Dockerfile、またはDocker Composeファイルのセットを開始点として使用することもできます。以下は、事前構築されたDevelopment Container imagesの1つを使用する簡単な例です：

{
  "image": "mcr.microsoft.com/devcontainers/typescript-node",
  "forwardPorts": [3000],
  "customizations": {
    // VS Code固有のプロパティを設定
    "vscode": {
      // コンテナ作成時にインストールする拡張機能のIDを追加
      "extensions": ["streetsidesoftware.code-spell-checker"]
    }
  }
}

注意: ベースイメージの内容に基づいて、追加の設定がコンテナに既に追加されています。例えば、上記でstreetsidesoftware.code-spell-checker拡張機能を追加しましたが、それは一部であるため、コンテナには"dbaeumer.vscode-eslint"も含まれます。これはmcr.microsoft.com/devcontainers/typescript-nodeを使用してプリビルドする際に自動的に発生し、プリビルドセクションで詳しく説明されています。

devcontainer.jsonファイルの作成について詳しくは、Development Containerの作成をご覧ください。

Dev Container Features

開発コンテナ「Features」は、自己完結型で共有可能なインストールコードと開発コンテナ設定の単位です。名前は、それらの1つを参照することで、開発コンテナにより多くのツール、ランタイム、またはライブラリ「Features」を迅速かつ簡単に追加して、自分や共同作業者が使用できるという考えに由来しています。

「Dev Containers: Add Dev Container Configuration Files」を使用すると、GitやAzure CLIのインストールなど、既存の開発コンテナ設定をカスタマイズするスクリプトのリストが表示されます：

リビルドしてコンテナで再度開くと、選択したFeaturesがdevcontainer.jsonで利用可能になります：

"features": {
  "ghcr.io/devcontainers/features/github-cli:1": {
    "version": "latest"
  }
}

devcontainer.jsonで直接"features"プロパティを編集する際はIntelliSenseを取得できます：

「Dev Containers: Configure Container Features」コマンドを使用すると、既存の設定を更新できます。

VS Code UIでソースされるFeaturesは、中央インデックスから提供されており、これに貢献することもできます。現在のリストとFeaturesの公開・配布方法の学習については、Dev Container仕様サイトをご覧ください。

「常にインストールされる」Features

dev containerで常にインストールされる拡張機能を設定できるように、dev.containers.defaultFeaturesユーザー設定を使用して、常にインストールしたいFeaturesを設定できます：

"dev.containers.defaultFeatures": {
  "ghcr.io/devcontainers/features/github-cli:1": {}
}

独自のFeatureの作成

独自のDev Container Featuresを作成・公開することも簡単です。公開されたFeaturesは、サポートする任意のパブリックまたはプライベートコンテナレジストリからOCI Artifactsとして保存・共有できます。現在公開されているFeaturesのリストはcontainers.devで確認できます。

Featureは、少なくともdevcontainer-feature.jsonとinstall.shエントリポイントスクリプトを含むフォルダ内の自己完結型エンティティです：

+-- feature
| +-- devcontainer-feature.json
| +-- install.sh
| +-- (other files)

dev container CLIを使用して独自のパブリックまたはプライベートFeaturesを公開する手順については、feature/starterリポジトリをチェックしてください。

Featuresの仕様と配布

FeaturesはオープンソースのDevelopment Containers仕様の重要な部分です。Featuresの動作とその配布に関する詳細情報を確認できます。

開発コンテナイメージのプリビルド

プロジェクトを開発コンテナで開くたびにコンテナイメージを作成・ビルドするのではなく、必要なツールを含むイメージを事前にビルドすることをお勧めします。プリビルドイメージを使用すると、コンテナの起動が高速化され、設定が簡素化され、特定のバージョンのツールにピン留めしてサプライチェーンセキュリティを向上させ、潜在的な破損を回避できます。GitHub ActionsなどのDevOpsまたは継続的インテグレーション（CI）サービスを使用してビルドをスケジュールすることで、イメージのプリビルドを自動化できます。

さらに良いことに、プリビルドイメージにはDev Containerメタデータを含めることができるため、イメージを参照すると設定が自動的に引き継がれます。

Dev Container CLI（またはGitHub Actionなどの他の仕様サポートユーティリティ）を使用してイメージをプリビルドすることをお勧めします。これは、dev container Featuresを含むDev Containers拡張機能の最新機能と同期が保たれているためです。イメージをビルドしたら、コンテナレジストリ（Azure Container Registry、GitHub Container Registry、Docker Hubなど）にプッシュして直接参照できます。

ワークフローでdev containersを再利用するために、devcontainers/ciリポジトリのGitHub Actionを使用できます。

詳細については、イメージのプリビルドに関するdev container CLI記事をご覧ください。

メタデータの継承

イメージラベルを介してプリビルドイメージにDev Container設定とFeatureメタデータを含めることができます。これにより、これらの設定は直接参照される際、参照されるDockerfileのFROM内、またはDocker Composeファイル内で自動的に取得されるため、イメージが自己完結型になります。これにより、Dev Container設定とイメージ内容の同期が取れず、単純なイメージ参照を通じて同じ設定の更新を複数のリポジトリにプッシュできます。

このメタデータラベルは、Dev Container CLI（またはGitHub ActionやAzure DevOps taskなどの他の仕様サポートユーティリティ）を使用してプリビルドする際に自動的に追加され、devcontainer.jsonおよび参照されるDev Container Featuresからの設定が含まれます。

これにより、イメージのプリビルドに使用する別のより複雑なdevcontainer.jsonを持ち、1つ以上のリポジトリで劇的に簡素化されたものを持つことができます。イメージの内容は、コンテナを作成する時にこの簡素化されたdevcontainer.jsonコンテンツとマージされます（マージロジックについては仕様を参照）。しかし最も簡単には、設定を有効にするためにdevcontainer.jsonでイメージを直接参照するだけです：

{
  "image": "mcr.microsoft.com/devcontainers/go:1"
}

代わりにイメージラベルに手動でメタデータを追加することもできます。これらのプロパティは、Dev Container CLIを使用してビルドしなかった場合でも取得されます（ビルドした場合でもCLIで更新できます）。例えば、このDockerfileスニペットを考えてみてください：

LABEL devcontainer.metadata='[{ \
  "capAdd": [ "SYS_PTRACE" ], \
  "remoteUser": "devcontainer", \
  "postCreateCommand": "yarn install" \
}]'

ボリュームの検査

時々、使用しているDocker名前付きボリュームを検査または変更したい状況に遭遇することがあります。devcontainer.jsonファイルを作成または変更せずに、コマンドパレット（F1）から「Dev Containers: Explore a Volume in a Dev Container...」を選択してVS Codeでこれらの内容を操作できます。

Remote Explorerでボリュームを検査することもできます。ドロップダウンで「Containers」が選択されていることを確認すると、「Dev Volumes」セクションが表示されます。ボリュームを右クリックして、ボリュームの作成時期、どのリポジトリがクローンされたか、マウントポイントなどの作成情報を検査できます。また、dev containerで探索することもできます。

Docker拡張機能がインストールされている場合、Docker ExplorerのVolumesセクションでボリュームを右クリックして「Explore in a Development Container」を選択できます。

拡張機能の管理

VS Codeは拡張機能を2つの場所のいずれかで実行します：ローカルのUI/クライアントサイド、またはコンテナ内。テーマやスニペットなどのVS Code UIに影響する拡張機能はローカルにインストールされますが、ほとんどの拡張機能は特定のコンテナ内に存在します。これにより、コンテナ内の特定のタスクに必要な拡張機能のみをインストールし、新しいコンテナに接続するだけでツールチェーン全体をシームレスに切り替えることができます。

拡張機能ビューから拡張機能をインストールすると、正しい場所に自動的にインストールされます。拡張機能がインストールされている場所は、カテゴリグループ化から判断できます。「Local - Installed」カテゴリとコンテナ用のカテゴリがあります。

注意: 拡張機能の作成者で、拡張機能が正しく動作しない、または間違った場所にインストールされる場合は、詳細についてSupporting Remote Developmentをご覧ください。

リモートで実際に実行する必要があるローカル拡張機能は、「Local - Installed」カテゴリで「Disabled」と表示されます。「Install」を選択してリモートホストに拡張機能をインストールしてください。

「Local - Installed」タイトルバーの右側にあるクラウドボタンを使用して、拡張機能ビューに移動し「Install Local Extensions in Dev Container: {Name}」を選択することで、ローカルにインストールされたすべての拡張機能をDev Container内にインストールすることもできます。これにより、コンテナにインストールするローカルインストール拡張機能を選択できるドロップダウンが表示されます。

ただし、一部の拡張機能では、コンテナに追加ソフトウェアをインストールする必要がある場合があります。問題が発生した場合は、詳細について拡張機能のドキュメントを参照してください。

devcontainer.jsonに拡張機能を追加

拡張機能IDのリストを追加するためにdevcontainer.jsonファイルを手動で編集することもできますが、拡張機能ビューで任意の拡張機能を右クリックして「Add to devcontainer.json」を選択することもできます。

拡張機能のオプトアウト

ベースイメージまたはFeatureで、dev containerにインストールしたくない拡張機能が設定されている場合、マイナス記号付きで拡張機能をリストアップしてオプトアウトできます。例えば：

{
  "image": "mcr.microsoft.com/devcontainers/typescript-node:1-20-bookworm",
  "customizations": {
    "vscode": {
      "extensions": ["-dbaeumer.vscode-eslint"]
    }
  }
}

「常にインストールされる」拡張機能

任意のコンテナに常にインストールしたい拡張機能がある場合は、dev.containers.defaultExtensionsユーザー設定を更新できます。例えば、GitLensとResource Monitor拡張機能をインストールしたい場合は、次のように拡張機能IDを指定します：

"dev.containers.defaultExtensions": [
  "eamodio.gitlens",
  "mutantdino.resourcemonitor"
]

高度：拡張機能をローカルまたはリモートで強制実行

拡張機能は通常、ローカルまたはリモートのいずれかで実行するように設計・テストされており、両方ではありません。ただし、拡張機能がサポートしている場合は、settings.jsonファイルの特定の場所で強制実行できます。

例えば、以下の設定ではDocker拡張機能をローカルで実行し、Remote - SSH: Editing Configuration Files拡張機能をデフォルトの代わりにリモートで実行するよう強制します：

"remote.extensionKind": {
  "ms-azuretools.vscode-docker": [ "ui" ],
  "ms-vscode-remote.remote-ssh-edit": [ "workspace" ]
}

"workspace"の代わりに"ui"の値は、拡張機能をローカルUI/クライアントサイドで強制実行します。拡張機能のドキュメントに特に記載されていない限り、拡張機能を破損させる可能性があるため、通常はテスト目的でのみ使用してください。詳細については、優先拡張機能の場所のセクションをご覧ください。

ポートの転送または公開

コンテナは分離された環境であるため、コンテナ内のサーバー、サービス、その他のリソースにアクセスしたい場合は、ホストにポートを「転送」または「公開」する必要があります。これらのポートを常に公開するようにコンテナを設定するか、一時的に転送するかのいずれかを選択できます。

常にポートを転送する

devcontainer.jsonのforwardPortsプロパティを使用して、アタッチ時またはコンテナでフォルダを開く際に常に転送したいポートのリストを指定できます。

"forwardPorts": [3000, 3001]

ウィンドウをリロード/再度開くだけで、VS Codeがコンテナに接続する際に設定が適用されます。

一時的にポートを転送する

devcontainer.jsonに追加しなかった、またはDocker Composeファイルで公開しなかったポートにアクセスする必要がある場合は、コマンドパレット（F1）から「Forward a Port」コマンドを実行して、セッション期間中に新しいポートを一時的に転送できます。

ポートを選択後、通知でコンテナ内のポートにアクセスするために使用すべきlocalhostポートが表示されます。例えば、ポート3000でリッスンしているHTTPサーバーを転送した場合、localhost上のポート4123にマッピングされたという通知が表示される場合があります。その後、http://localhost:4123を使用してこのリモートHTTPサーバーに接続できます。

後でアクセスする必要がある場合は、同じ情報がRemote Explorerの「Forwarded Ports」セクションで利用できます。

転送したポートをVS Codeに記憶させたい場合は、設定エディター（⌘,（Windows、Linux Ctrl+,））で「Remote: Restore Forwarded Ports」をチェックするか、settings.jsonで"remote.restoreForwardedPorts": trueを設定してください。

ポートの公開

Dockerには、コンテナ作成時にポートを「公開」する概念があります。公開されたポートは、ローカルネットワークで利用可能にするポートとよく似た動作をします。アプリケーションがlocalhostからの呼び出しのみを受け入れる場合、ローカルマシンがネットワーク呼び出しに対して行うのと同様に、公開されたポートからの接続を拒否します。一方、転送されたポートは、実際にアプリケーションに対してlocalhostのように見えます。それぞれ異なる状況で有用です。

ポートを公開するには：

appPortプロパティを使用

devcontainer.jsonでイメージまたはDockerfileを参照している場合、appPortプロパティを使用してホストにポートを公開できます。

"appPort": [ 3000, "8921:5000" ]

Docker Composeポートマッピングを使用

ポートマッピングをdocker-compose.ymlファイルに簡単に追加して、追加のポートを公開できます。

ports:
  - "3000"
  - "8921:5000"

いずれの場合も、設定を有効にするためにコンテナを再ビルドする必要があります。コンテナに接続している際に、コマンドパレット（F1）で「Dev Containers: Rebuild Container」コマンドを実行することでこれを行えます。

ターミナルの起動

VS Codeからコンテナでターミナルを開くのは簡単です。フォルダをコンテナで開いたら、VS Codeで開くターミナルウィンドウ（Terminal > New Terminal）は、ローカルではなく自動的にコンテナ内で実行されます。

同じターミナルウィンドウからcodeコマンドラインを使用して、コンテナ内で新しいファイルやフォルダを開くなど、多数の操作を実行することもできます。code --helpと入力して、コマンドラインから利用可能なオプションを確認してください。

コンテナでのデバッグ

フォルダをコンテナで開いたら、アプリケーションをローカルで実行する場合と同じ方法でVS Codeのデバッガーを使用できます。例えば、launch.jsonで起動設定を選択してデバッグを開始（F5）すると、アプリケーションはリモートホストで開始され、デバッガーがアタッチされます。

VS Codeのデバッグ機能を.vscode/launch.jsonで設定する詳細については、デバッグドキュメントを参照してください。

コンテナ固有の設定

VS Codeのローカルユーザー設定は、dev containerに接続している際も再利用されます。これによりユーザー体験の一貫性が保たれますが、ローカルマシンと各コンテナの間でこれらの設定の一部を変更したい場合があります。幸い、コンテナに接続した後、コマンドパレット（F1）から「Preferences: Open Remote Settings」コマンドを実行するか、設定エディターで「Remote」タブを選択することで、コンテナ固有の設定を設定することもできます。これらは、コンテナに接続する際にローカル設定を上書きします。

デフォルトのコンテナ固有設定

settingsプロパティを使用して、devcontainer.jsonでコンテナ固有設定のデフォルトを含めることができます。これらの値は、コンテナが作成されるとコンテナ固有設定ファイル内に自動的に配置されます。

例えば、これを.devcontainer/devcontainer.jsonに追加すると、Javaホームパスが設定されます：

// ツール固有のプロパティを設定
"customizations": {
  // VS Code固有のプロパティを設定
  "vscode": {
    "settings": {
      "java.home": "/docker-java-home"
    }
  }
}

これはデフォルトを確立するだけなので、コンテナが作成された後も必要に応じて設定を変更できます。

コンテナの管理

デフォルトでは、フォルダを開く際にDev Containers拡張機能はdevcontainer.jsonで言及されているコンテナを自動的に開始します。VS Codeを閉じると、拡張機能は接続していたコンテナを自動的にシャットダウンします。devcontainer.jsonに"shutdownAction": "none"を追加することで、この動作を変更できます。

コマンドラインを使用してコンテナを管理することもできますが、Remote Explorerを使用することもできます。コンテナを停止するには、ドロップダウンから「Containers」を選択し（存在する場合）、実行中のコンテナを右クリックして「Stop Container」を選択します。終了したコンテナの開始、コンテナの削除、最近のフォルダの削除も可能です。詳細ビューから、ポートを転送したり、既に転送されたポートをブラウザで開いたりできます。

イメージをクリーンアップしたり、コンテナを一括削除したりしたい場合は、さまざまなオプションについて未使用のコンテナとイメージのクリーンアップをご覧ください。

Dotfileリポジトリでのカスタマイズ

Dotfilesは、ファイル名がドット（.）で始まるファイルで、通常はさまざまなアプリケーションの設定情報を含んでいます。開発コンテナは幅広いアプリケーションタイプをカバーできるため、これらのファイルをどこかに保存して、コンテナが起動して実行された後に簡単にコピーできると便利です。

一般的な方法は、これらのdotfilesをGitHubリポジトリに保存し、ユーティリティを使用してクローンして適用することです。Dev Containers拡張機能には、独自のコンテナでこれらを使用するための組み込みサポートがあります。このアイデアが初めての場合は、存在するさまざまなdotfilesブートストラップリポジトリをご覧ください。

使用するには、VS Codeのユーザー設定（⌘,（Windows、Linux Ctrl+,））に次のようにdotfiles GitHubリポジトリを追加します：

またはsettings.jsonで：

{
  "dotfiles.repository": "your-github-id/your-dotfiles-repo",
  "dotfiles.targetPath": "~/dotfiles",
  "dotfiles.installCommand": "install.sh"
}

この時点以降、コンテナが作成される際にdotfilesリポジトリが使用されます。

既知の制限事項

Dev Containers制限事項

Windowsコンテナイメージはサポートされていません
マルチルートワークスペースのすべてのルート/フォルダは、下位レベルに設定ファイルがあるかどうかに関係なく、同じコンテナで開かれます
Linux用の非公式Ubuntu Docker snapパッケージはサポートされていません。お使いのディストリビューション用のDocker公式インストール手順に従ってください
Windows上のDocker Toolboxはサポートされていません
SSHキーにパスフレーズがある場合のGitリポジトリクローンでVS Codeのプルおよび同期機能がリモート実行時にハングする可能性があります。パスフレーズなしのSSHキーを使用するか、HTTPSを使用してクローンするか、コマンドラインからgit pushを実行して問題を回避してください
ローカルプロキシ設定はコンテナ内で再利用されません。適切なプロキシ情報が設定されていない限り（例：グローバルHTTP_PROXYまたはHTTPS_PROXY環境変数）、拡張機能が動作しない可能性があります
**ssh-agentがバージョン <= 8.8で実行され、SSHクライアント（任意のプラットフォーム）がバージョン >= 8.9で実行される場合のOpenSSHバージョン間の非互換性**があります。回避策は、wingetまたは[Win32-OpenSSH/releases](https://github.com/PowerShell/Win32-OpenSSH/releases)のインストーラーを使用して、Windows上のOpenSSHを8.9以降にアップグレードすることです（`ssh-add -l`は正しく動作しますが、`ssh `は`: Permission denied (publickey)`で失敗します。これは、SSHを使用してリポジトリに接続する際のGitにも影響します）

Containersに関連するアクティブな問題のリストについては、こちらをご覧ください。

Docker制限事項

WindowsまたはMacのDockerトラブルシューティングガイドを参照し、詳細についてはDocker Support Resourcesを参照してください。

Docker拡張機能制限事項

WSL、Remote - Tunnels、またはRemote - SSHウィンドウからDockerまたはKubernetes拡張機能を使用している場合、DockerまたはKubernetesビューで「Attach Visual Studio Code」コンテキストメニューアクションを使用すると、利用可能なコンテナから2回目の選択を求められます。

拡張機能制限事項

現時点では、ほとんどの拡張機能は変更なしでDev Containers内で動作します。ただし、場合によっては、特定の機能で変更が必要な場合があります。拡張機能の問題に遭遇した場合は、問題を拡張機能作成者に報告する際に言及できる一般的な問題と解決策の要約をご覧ください。

さらに、Alpine サポートは利用可能ですが、拡張機能内のネイティブコードのglibc依存関係により、コンテナにインストールされた一部の拡張機能が動作しない場合があります。詳細については、LinuxでのRemote Development記事をご覧ください。

高度なコンテナ設定

以下のトピックに関する情報については、高度なコンテナ設定記事をご覧ください：

devcontainer.jsonリファレンス

devcontainer.jsonリファレンスの完全版があり、開発コンテナをカスタマイズし、実行中のコンテナへのアタッチを制御するためのファイルスキーマを確認できます。

質問やフィードバック

ヒントとコツまたはFAQをご覧ください
Stack Overflowで検索してください
機能リクエストを追加するか問題を報告してください
他の人が使用できるDev Container TemplateまたはFeatureを作成してください
Development Containers仕様をレビューしてフィードバックを提供してください
ドキュメントまたはVS Code自体に貢献してください
詳細については貢献ガイドをご覧ください

次のステップ

実行中のコンテナにアタッチ - 既に実行中のDockerコンテナにアタッチ
Development Containerの作成 - 作業環境用のカスタムコンテナを作成
高度なコンテナ - 高度なコンテナシナリオの解決策を見つける
devcontainer.jsonリファレンス - devcontainer.jsonスキーマを確認

補足情報

日本語コミュニティリソース

VS Code公式日本語ドキュメントやコミュニティフォーラムでDev Containersに関する情報交換が可能
DockerやKubernetesの日本語学習リソースも豊富に利用可能

よくある質問（日本語環境向け）

Q: 日本語ファイル名やパスを含むプロジェクトでも動作しますか？
A: はい、UTF-8エンコーディングをサポートしているため、日本語ファイル名やパスでも問題なく動作します。

Q: Windows上で日本語IMEは正常に動作しますか？
A: VS Code自体の日本語入力サポートがそのままコンテナ環境でも利用できます。

Q: タイムゾーンの設定はどうすれば良いですか？
A: devcontainer.jsonで環境変数TZ=Asia/Tokyoを設定することで日本時間に設定できます。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

VS Code Dev Containers(リファレンス日本語ver)

VS Code Dev Containers 完全ガイド

目次

概要

はじめに

システム要件

ローカル/リモートホスト

Windows

macOS

Linux

リモートホスト

コンテナ

インストール

1. Dockerのインストールと設定

Windows / macOS

Linux

2. Visual Studio Codeのインストール

3. Dev Containers拡張機能のインストール

Gitで作業している場合の設定

クイックスタートの選択

クイックスタート1: 開発コンテナを試す

クイックスタート2: 既存フォルダをコンテナで開く

手順1: フォルダを選択してコンテナ設定を開始

手順2: 開発コンテナの開始点を選択

手順3: 設定ファイルの追加とビルド

手順4: コンテナへの接続

WindowsでWSL 2フォルダをコンテナで開く

リモートSSHホスト上のフォルダをコンテナで開く

リモートTunnelホスト上のフォルダをコンテナで開く

既存のワークスペースをコンテナで開く

クイックスタート3: GitリポジトリやPRを独立したコンテナボリュームで開く

手順1: リポジトリクローンコマンドの実行

手順2: リポジトリの指定

手順3: 開発環境の選択

手順4: ビルドと接続

ワークスペースの信頼

コンテナでフォルダを再度開く

既存のコンテナにアタッチ

ボリュームでリポジトリをクローン

ボリュームの検査

Dockerデーモンのリモート実行

devcontainer.jsonファイルの作成

Dev Container Features

「常にインストールされる」Features

独自のFeatureの作成

Featuresの仕様と配布

開発コンテナイメージのプリビルド

メタデータの継承

ボリュームの検査

拡張機能の管理

devcontainer.jsonに拡張機能を追加

拡張機能のオプトアウト

「常にインストールされる」拡張機能

高度：拡張機能をローカルまたはリモートで強制実行

ポートの転送または公開

常にポートを転送する

一時的にポートを転送する

ポートの公開

appPortプロパティを使用

Docker Composeポートマッピングを使用

ターミナルの起動

コンテナでのデバッグ

コンテナ固有の設定

デフォルトのコンテナ固有設定

コンテナの管理

Dotfileリポジトリでのカスタマイズ

既知の制限事項

Dev Containers制限事項

Docker制限事項

Docker拡張機能制限事項

拡張機能制限事項

高度なコンテナ設定

devcontainer.jsonリファレンス

質問やフィードバック

次のステップ

補足情報

関連リンク

日本語コミュニティリソース

よくある質問（日本語環境向け）