💻 6月3日の MS Build で開催される VS Code Live に参加しましょう。

Dev Containersのヒントとコツ

この記事では、さまざまな環境でDev Containers拡張機能をセットアップして実行するためのヒントとコツを紹介します。

Dockerをインストールする代替方法

Dev Containers拡張機能でDockerを使用する方法はいくつかあります。以下を含みます。

  • Dockerがローカルにインストールされている。
  • リモート環境にインストールされたDocker。
  • ローカルまたはリモートにインストールされた、その他のDocker準拠のCLI。

詳細は、代替のDockerオプションに関するドキュメントをご覧ください。

AIチャットの応答のカスタマイズ

カスタム指示（Custom instructions）を使用すると、共通のガイドラインやルールを記述して、特定のコーディング慣行や技術スタックに合わせた応答を得ることができます。

デブコンテナでカスタム指示を使用すると、接続しているデブコンテナのタイプ（インストールされている言語やツールチェーンの種類など）についてCopilotにより多くの情報を提供できます。これを実現する方法はいくつかあります。

  • devcontainer.jsonに直接 "github.copilot.chat.codeGeneration.instructions" を追加する
    • デブコンテナの作成と接続のプロセスをさらに容易にするために、デブコンテナのリソース（イメージや機能（Features）など）を公開しており、現在これらのファイルにカスタム指示を含めています。
    • Python機能におけるカスタム指示の例は、こちらにあります。
  • ローカルと同じように、copilot-instructions.md ファイルを使用する

Windows向けDocker Desktopのヒント

Windows向けのDocker Desktopは、ほとんどのセットアップで正常に動作しますが、問題を引き起こす可能性のあるいくつかの「落とし穴」があります。これらを回避するためのヒントを紹介します。

  1. Windows 10 (2004以降) での新しい Docker WSL 2 バックエンドの使用を検討してください。 Docker DesktopのWSL 2バックエンドを使用している場合、これを使用してWSL内およびローカルのフォルダーを開くことができます。コンテナはWindowsとWSL内でも共有され、この新しいエンジンはファイル共有の問題の影響を受けにくくなっています。詳細は、クイックスタートを参照してください。

  2. 「Windows上のLinuxコンテナ (LCOW)」モードをオフにします。 デフォルトでは無効になっていますが、最近のバージョンのDockerは、WindowsコンテナとLinuxコンテナを同時に使用できるようにするLinux Containers on Windows (LCOW)をサポートしています。ただし、これは新しい機能であるため、問題が発生する可能性があり、Dev Containers拡張機能は現在Linuxコンテナのみをサポートしています。Dockerタスクバーの項目を右クリックし、コンテキストメニューからSwitch to Linux Containers...（Linuxコンテナに切り替える...）を選択することで、いつでもLCOWモードから切り替えることができます。

  3. ファイアウォールがDockerによる共有ドライブのセットアップを許可していることを確認してください。 Dockerはマシンの2つのローカルIP間でのみ接続する必要がありますが、一部のファイアウォールソフトウェアがドライブ共有や必要なポートをブロックする場合があります。

以下は、古いバージョンのDocker for Windowsに適用されていたヒントですが、現在は解決されているはずです。デグレード（先祖返り）の可能性による奇妙な動作に遭遇した場合は、過去にこれらのヒントで問題が解決したことがあります。

  1. ドライブを共有する際は、ADドメインアカウントまたはローカル管理者アカウントを使用してください。AAD（メールベースの）アカウントは使用しないでください。 AAD（メールベースの）アカウントには、Dockerの案件#132および案件#1352でドキュメント化されている既知の問題があります。どうしてもAADアカウントを使用する必要がある場合は、ドライブの共有専用に、マシン上に別のローカル管理者アカウントを作成してください。このブログ記事の手順に従って、すべてをセットアップしてください。

  2. ドライブ共有の問題を避けるため、パスワードは英数字のみにしてください。 Windowsでドライブの共有を求められた際、マシン上で管理者権限を持つアカウントのユーザー名とパスワードの入力を求められます。ユーザー名またはパスワードが正しくないという警告が表示される場合、パスワードに含まれる特殊文字が原因である可能性があります。たとえば、!、[、] は問題を引き起こすことが知られています。解決するには、パスワードを英数字に変更してください。詳細は、Dockerのボリュームマウントの問題に関するこの案件を参照してください。

  3. Dockerへのサインインには、（メールアドレスではなく）Docker IDを使用してください。 Docker CLIはDocker IDの使用のみをサポートしているため、メールアドレスを使用すると問題が発生する可能性があります。詳細は、Dockerの案件#935を参照してください。

問題が解決しない場合は、Windows向けDocker Desktopトラブルシューティングガイドを参照してください。

Docker Desktopでのファイル共有の有効化

VS CodeのDev Containers拡張機能は、ソースコードがDockerと共有されているフォルダーまたはドライブ内にある場合にのみ、ソースコードをコンテナに自動的にマウントできます。共有されていない場所からデブコンテナを開いた場合、コンテナは正常に起動しますが、ワークスペースは空になります。

なお、このステップは、Docker DesktopのWSL 2エンジンを使用している場合は不要です。

Dockerのドライブおよびフォルダー共有設定を変更するには

Windows

  1. Dockerタスクバーの項目を右クリックし、Settings（設定）を選択します。
  2. Resources（リソース） > File Sharing（ファイル共有）に移動し、ソースコードが配置されているドライブにチェックを入れます。
  3. ローカルファイアウォールが共有アクションをブロックしているというメッセージが表示される場合は、次の手順についてこのDockerナレッジベース記事を参照してください。

macOS

  1. Dockerメニューバーの項目をクリックし、Preferences（環境設定）を選択します。
  2. Resources（リソース） > File Sharing（ファイル共有）に移動します。ソースコードが含まれるフォルダーが、リストされている共有フォルダーのいずれか以下にあることを確認します。

コンテナ内でのGitの改行コードの問題の解決（多数のファイルが変更されたと表示される問題）

WindowsとLinuxではデフォルトの改行コードが異なるため、改行コード以外の違いがないにもかかわらず、Gitが多数の変更されたファイルを報告することがあります。これを防ぐには、.gitattributes ファイルを使用するか、Windows側でグローバルに改行コードの変換を無効にすることができます。

通常、リポジトリに .gitattributes ファイルを追加または変更することが、この問題を解決する最も信頼性の高い方法です。このファイルをソース管理にコミットすることで、他のメンバーの助けになり、リポジトリごとに適切に動作を変えることができます。たとえば、リポジトリのルートにある .gitattributes ファイルに以下を追加すると、CRLFを必要とするWindowsバッチファイルを除き、すべてが強制的にLFになります。

* text=auto eol=lf
*.{cmd,[cC][mM][dD]} text eol=crlf
*.{bat,[bB][aA][tT]} text eol=crlf

これはGit v2.10以降で動作するため、問題が発生する場合は最新のGitクライアントがインストールされていることを確認してください。CRLFを必要とするリポジトリ内の他のファイルタイプをこの同じファイルに追加できます。

常にUnixスタイルの改行コード（LF）をアップロードしたい場合は、input オプションを使用できます。

git config --global core.autocrlf input

改行コードの変換を完全に無効にしたい場合は、代わりに以下を実行します。

git config --global core.autocrlf false

最後に、これらの設定を反映させるために、リポジトリを再度クローンする必要がある場合があります。

Docker Compose使用時にコンテナ内でGitをセットアップするのを避ける

この問題の解決方法については、メインのコンテナ記事にあるコンテナとのGit認証情報の共有を参照してください。

コンテナからのGitのプッシュまたは同期がハングアップする問題の解決

SSHを使用してGitリポジトリをクローンし、SSHキーにパスフレーズが設定されている場合、リモートで実行するときにVS Codeのプルおよび同期機能がハングアップする可能性があります。

この問題を回避するには、パスフレーズのないSSHキーを使用するか、HTTPSを使用してクローンするか、コマンドラインから git push を実行してください。

不足しているLinuxの依存関係に関するエラーの解決

一部の拡張機能は、特定のDockerイメージに見つからないライブラリに依存しています。この問題を解決するいくつかの方法については、コンテナに関する記事を参照してください。

Docker Desktopでのコンテナの高速化

デフォルトでは、Docker Desktopはマシン容量のわずかな一部しかコンテナに割り当てません。ほとんどの場合これで十分ですが、より多くの容量を必要とする処理を行う場合は、メモリ、CPU、またはディスクの使用量を増やすことができます。

まず、使用していない実行中のコンテナを停止してみてください。

これで問題が解決しない場合は、実際にCPU使用率が問題なのか、それとも他の原因があるのかを確認することをお勧めします。これを簡単に確認する方法は、Resource Monitor拡張機能をインストールすることです。コンテナにインストールすると、ステータスバーにコンテナの容量に関する情報が表示されます。

Resource use Status bar

この拡張機能を常にインストールしておきたい場合は、settings.json に以下を追加します。

"dev.containers.defaultExtensions": [
    "mutantdino.resourcemonitor"
]

コンテナにマシンの容量をより多く割り当てる必要があると判断した場合は、次の手順に従います。

  1. Dockerタスクバーの項目を右クリックし、Settings（設定） / Preferences（環境設定）を選択します。
  2. Advanced（詳細）に移動し、CPU、メモリ、またはスワップを増やします。
  3. macOSでは、Disk（ディスク）に移動して、Dockerがマシン上で消費できるディスク容量を増やします。Windowsでは、これは他の設定と一緒に「Advanced（詳細）」の下にあります。

最後に、コンテナがディスクへの負荷が高い操作を行っている場合、または単にレスポンス時間を短縮したい場合は、コンテナのディスクパフォーマンスの向上でヒントを参照してください。VS Codeのデフォルト設定は、利便性と普遍的なサポートのために最適化されていますが、さらに最適化することが可能です。

未使用のコンテナとイメージのクリーンアップ

Dockerからディスク容量不足を報告するエラーが表示された場合、通常は未使用のコンテナやイメージをクリーンアップすることで解決できます。これを行うにはいくつかの方法があります。

方法1：リモートエクスプローラーを使用する

コンテナを削除するには、リモートエクスプローラーを選択し、削除したいコンテナを右クリックしてRemove Container（コンテナの削除）を選択します。

Remote Explorer screenshot

ただし、これではダウンロードしたイメージはクリーンアップされないため、システムが雑然とする可能性があります。

方法2：Container Tools拡張機能を使用する

  1. VS Codeでローカルウィンドウを開きます（ファイル > 新規ウィンドウ）。

  2. まだインストールされていない場合は、拡張機能ビューからContainer Tools拡張機能をインストールします。

  3. その後、Containerエクスプローラーに移動し、Containers（コンテナ）またはImages（イメージ）ノードを展開して右クリックし、Remove Container / Image（コンテナ/イメージの削除）を選択します。

    Container Explorer screenshot

方法3：Docker CLIを使用して削除するコンテナを選択する

  1. ローカルのターミナル/コマンドプロンプトを開きます（またはVS Codeのローカルウィンドウを使用します）。
  2. すべてのコンテナのリストを表示するには、docker ps -a と入力します。
  3. このリストからコンテナを削除するには、docker rm <コンテナID> と入力します。
  4. 未使用のイメージをすべて削除するには、docker image prune と入力します。

docker ps では削除したいコンテナを特定するのに十分な情報が得られない場合、次のコマンドを実行すると、VS Codeによって管理されているすべての開発コンテナと、それらを生成するために使用されたフォルダーが一覧表示されます。

docker ps -a --filter="label=vsch.quality" --format "table {{.ID}}\t{{.Status}}\t{{.Image}}\tvscode-{{.Label \"vsch.quality\"}}\t{{.Label \"vsch.local.folder\"}}"

方法4：Docker Composeを使用する

  1. ローカルのターミナル/コマンドプロンプトを開きます（またはVS Codeのローカルウィンドウを使用します）。
  2. docker-compose.yml ファイルがあるディレクトリに移動します。
  3. docker-compose down と入力して、コンテナを停止して削除します。複数のDocker Composeファイルがある場合は、-f 引数を使用して追加のDocker Composeファイルを指定できます。

方法4：実行中ではないすべてのコンテナとイメージを削除する

  1. ローカルのターミナル/コマンドプロンプトを開きます（またはVS Codeのローカルウィンドウを使用します）。
  2. docker system prune --all と入力します。

Debian 8を使用するイメージのDockerfileビルド失敗の解決

Debian 8/Jessieベースのイメージ（旧バージョンの node:8 イメージなど）を使用するコンテナをビルドするときに、次のエラーが発生することがあります。

...
W: Failed to fetch http://deb.debian.org/debian/dists/jessie-updates/InRelease  Unable to find expected entry 'main/binary-amd64/Packages' in Release file (Wrong sources.list entry or malformed file)
E: Some index files failed to download. They have been ignored, or old ones used instead.
...

これはDebian 8が「アーカイブ」されたことが原因の既知の問題です。より新しいバージョンのイメージ（多くの場合、Debian 9/Stretchへのアップグレードによる）では通常、この問題が解決されています。

このエラーを解決する方法は2つあります。

  • 方法1：そのイメージに依存するコンテナをすべて削除し、イメージを削除してから、もう一度ビルドを試みます。これにより、この問題の影響を受けない、アップデートされたイメージがダウンロードされるはずです。詳細は未使用のコンテナとイメージのクリーンアップを参照してください。

  • 方法2：コンテナやイメージを削除したくない場合は、apt または apt-get コマンドを実行する前に、この行を Dockerfile に追加します。これにより、Jessieに必要なソースリストが追加されます。

    # Add archived sources to source list if base image uses Debian 8 / Jessie
RUN cat /etc/*-release | grep -q jessie && printf "deb http://archive.debian.org/debian/ jessie main\ndeb-src http://archive.debian.org/debian/ jessie main\ndeb http://security.debian.org jessie/updates main\ndeb-src http://security.debian.org jessie/updates main" > /etc/apt/sources.list

メールアドレスを使用した際のDocker Hubサインインエラーの解決

Docker CLIはDocker IDの使用のみをサポートしているため、サインインにメールアドレスを使用すると問題が発生することがあります。詳細は、Dockerの案件#935を参照してください。

回避策として、メールアドレスではなくDocker IDを使用してDockerにサインインしてください。

macOSにおけるHyperkitの高CPU使用率

Docker for Macには、CPUの一時的な高負荷を引き起こす既知の問題があります。特に、ファイルの監視やビルドを行うときに高いCPU使用率が発生します。デブコンテナでほとんど何も行われていないにもかかわらず、アクティビティモニタで com.docker.hyperkit のCPU使用率が高い場合は、この問題が発生している可能性があります。アップデートや修正については、Dockerの案件を追跡してください。

SSHトンネルを使用したリモートDockerホストへの接続

リモートのDockerマシンまたはSSHホスト上のコンテナ内での開発に関する記事では、リモートのDockerホストを使用する際のVS Codeのセットアップ方法について説明しています。多くの場合、settings.json の Container Tools拡張機能 の containers.environment プロパティ、または環境変数 DOCKER_HOST を ssh:// または tcp:// のURIに設定するだけで済みます。

ただし、SSH構成の複雑さやその他の制限により、お使いの環境でこれが機能しない状況に遭遇することがあります。その場合、フォールバックとしてSSHトンネルを使用できます。

フォールバックオプションとしてSSHトンネルを使用する

SSHトンネルをセットアップして、リモートホストからローカルマシンにDockerソケットを転送できます。

次の手順を実行します。

  1. OpenSSH互換のSSHクライアントをインストールします。

  2. ユーザーまたはワークスペースの settings.json で、Container Tools拡張機能 の containers.environment プロパティを以下のように更新します。

    "containers.environment": {
    "DOCKER_HOST": "tcp://:23750"
}

  3. ローカルのターミナル / PowerShellから次のコマンドを実行します（user@hostname は、リモートのユーザー名とサーバーのホスト名 / IPアドレスに置き換えてください）。

    ssh -NL localhost:23750:/var/run/docker.sock user@hostname

これで、VS Codeはリモートホスト上の任意の実行中のコンテナにアタッチできるようになります。また、専用のローカルな devcontainer.json ファイルを使用して、リモートデブコンテナを作成または接続することもできます。

完了したら、ターミナル / PowerShellで Ctrl+C を押してトンネルを閉じます。

注意： ssh コマンドが失敗する場合、SSHホスト側で AllowStreamLocalForwarding を許可する必要がある場合があります。

  1. SSHホスト上（ローカルではなく）のエディター（Vim、nano、Picoなど）で /etc/ssh/sshd_config を開きます。
  2. 設定 AllowStreamLocalForwarding yes を追加します。
  3. SSHサーバーを再起動します（Ubuntuでは、sudo systemctl restart sshd を実行します）。
  4. 再試行します。

ユーザープロファイルの永続化

mounts プロパティを使用すると、デブコンテナの再ビルド間でユーザープロファイル（シェルの履歴など）を永続化できます。

    "mounts": [
        "source=profile,target=/root,type=volume",
        "target=/root/.vscode-server,type=volume"
    ],

上記のコードは、まず /root にマウントされた profile という名前付きボリュームを作成します。これは再ビルド後も維持されます。次に、/root/.vscode-server にマウントされた匿名ボリュームを作成します。これは再ビルド時に破棄され、VS Codeが拡張機能やドットファイルを再インストールできるようにします。

コンテナの高度な構成のヒント

以下のトピックに関する情報については、高度なコンテナ構成に関する記事を参照してください。

拡張機能のヒント

多くの拡張機能は変更なしで動作しますが、特定の機能が期待どおりに動作しなくなる問題がいくつかあります。回避策として別のコマンドを使用できる場合もあれば、拡張機能自体の修正が必要な場合もあります。リモート拡張機能のヒントセクションでは、一般的な問題と解決のヒントについてクイックリファレンスを提供しています。また、リモート拡張機能ホストをサポートするための拡張機能の変更に関する詳細なガイドについては、拡張機能の主要な記事であるリモート開発のサポートを参照してください。

質問とフィードバック

問題の報告

Dev Containers拡張機能で問題が発生した場合は、問題の診断に役立つ適切なログを収集することが重要です。Dev Containers拡張機能のログは、Dev Containers: Show Container Log（コンテナログの表示）で取得できます。

リモートで他の拡張機能を使用する際に問題が発生している場合（たとえば、リモートコンテキストで他の拡張機能が適切に読み込まれない、またはインストールされない場合）、Remote Extension Host（リモート拡張機能ホスト）の出力チャネル（Output: Focus on Output View（出力: 出力ビューにフォーカス））からログを取得し、ドロップダウンからLog (Remote Extension Host)（ログ (リモート拡張機能ホスト)）を選択すると役立ちます。

注意：Log (Extension Host)（ログ (拡張機能ホスト)）のみが表示される場合、それはローカルの拡張機能ホストであり、リモート拡張機能ホストは起動していません。これは、ログファイルが作成された後にのみログチャネルが作成されるためです。したがって、リモート拡張機能ホストが起動しない場合、リモート拡張機能ホストのログファイルは作成されず、出力ビューにも表示されません。これ自体も、問題（Issue）に含めるべき有用な情報です。

リモートに関する質問とフィードバックのリソース

他にもさまざまなリモート向けのリソースを用意しています。

5/28/2026
© . This site is unofficial and not affiliated with Microsoft.