VS Codeのエージェントモードを拡張するには、を試してください！

Dev Containers のヒントとテクニック

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

Docker をインストールする別の方法

Dev Containers 拡張機能で Docker を使用するには、いくつかの方法があります。

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

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

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

カスタム指示を使用すると、特定のコーディングプラクティスや技術スタックに合致する応答を得るために、一般的なガイドラインやルールを記述できます。

dev containers でカスタム指示を使用すると、接続している dev container の種類 (インストールされている言語やツールチェーンの種類など) について、Copilot に詳細な情報を提供できます。これにはいくつかの方法があります。

  • "github.copilot.chat.codeGeneration.instructions" を devcontainer.json に直接追加する
    • Dev Container の作成と接続のプロセスをさらに容易にするために、dev container リソース (イメージやFeaturesなど) を公開しており、これらのファイルにはカスタム指示が含​​まれるようになりました。
    • こちらは、Python Feature のカスタム指示の例です。
  • ローカルで行うのと同じように copilot-instructions.md ファイルを使用する

Windows 用 Docker Desktop のヒント

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

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

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

  3. ファイアウォールが Docker による共有ドライブの設定を許可していることを確認してください。 Docker は 2 つのマシンローカル IP 間で接続するだけで済みますが、一部のファイアウォールソフトウェアはドライブ共有や必要なポートをブロックする場合があります。この問題を解決するための次の手順については、この Docker KB 記事を参照してください。

以下に、以前のバージョンの Docker for Windows に適用されたものの、現在は解決されているはずのヒントをいくつか紹介します。潜在的な回帰により奇妙な動作に遭遇した場合、これらのヒントは過去に問題を解決してきました。

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

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

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

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

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

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

この手順は、Docker Desktop の WSL 2 エンジンでは不要であることに注意してください。

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

Windows

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

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 push または sync 時にハングする問題の解決

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 でローカルウィンドウを開きます (File > New Window)。

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

  3. 次に、コンテナーエクスプローラーに移動し、Containers または Images ノードを展開し、右クリックして Remove Container / Image を選択します。

    Container Explorer screenshot

オプション 3: Docker CLI を使用して削除するコンテナーを選択する

  1. ローカルのターミナル/コマンドプロンプトを開きます (または VS Code のローカルウィンドウを使用します)。
  2. docker ps -a と入力して、すべてのコンテナーのリストを表示します。
  3. このリストから docker rm <Container 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 のIssue #935を参照してください。

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

macOS での Hyperkit の高い CPU 使用率

Docker for Mac には、高い CPU スパイクを引き起こす既知の問題があります。特に、ファイルの監視やビルド中に CPU 使用率が高くなります。dev container でほとんど何も実行されていないのに、アクティビティモニタで 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 ファイルを使用して、リモート dev container を作成/接続することもできます。

完了したら、ターミナル / 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 プロパティを使用すると、再構築後も dev container のユーザープロファイル (シェル履歴など) を保持できます。

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

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

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

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

拡張機能のヒント

多くの拡張機能は変更なしで動作しますが、特定の機能が期待どおりに動作しない原因となるいくつかの問題があります。場合によっては、別のコマンドを使用して問題を回避できますが、その他の場合は、拡張機能を変更する必要がある場合があります。リモート拡張機能のヒントセクションでは、一般的な問題とそれらを解決するためのヒントを簡単に参照できます。リモート拡張機能ホストをサポートするために拡張機能を変更する方法の詳細なガイドについては、リモート開発のサポートに関する主要な拡張機能記事も参照できます。

質問とフィードバック

問題の報告

Dev Containers 拡張機能で問題が発生した場合、問題を診断できるように、正しいログを収集することが重要です。Dev Containers 拡張機能のログは、Dev Containers: Show Container Log で取得できます。

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

注: Log (Extension Host) のみが表示される場合、これはローカルの拡張機能ホストであり、リモート拡張機能ホストは起動していません。これは、ログチャネルがログファイルが作成された後にのみ作成されるためであり、リモート拡張機能ホストが起動しない場合、リモート拡張機能ホストのログファイルは作成されず、出力ビューには表示されません。これは、問題に含めるのに役立つ情報です。

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

その他、さまざまなリモートリソースがあります

07/09/2025