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

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

この記事には、さまざまな環境で Dev Containers 拡張機能を設定して実行するためのヒントとテクニックが含まれています。

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

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

  • ローカルにDockerがインストールされている場合。
  • リモート環境にインストールされた Docker。
  • ローカルまたはリモートにインストールされたその他の Docker 互換 CLI。
    • 他の CLI も機能する可能性がありますが、公式にはサポートされていません。Kubernetes クラスターへのアタッチには、適切に設定された kubectl CLI のみが必要です。

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

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

カスタム指示を使用すると、共通のガイドラインやルールを記述して、特定のコーディングプラクティスや技術スタックに一致する応答を得ることができます。

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

  • "github.copilot.chat.codeGeneration.instructions" を devcontainer.json に直接追加する
    • 私たちは、dev コンテナーの作成と接続のプロセスをさらに簡単にするために、dev コンテナーのリソース (イメージや 機能など) を公開しており、これらのファイルにカスタム指示を含めるようになりました。
    • こちらは、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. 「Linux Containers on Windows (LCOW)」モードから切り替えます。 デフォルトでは無効になっていますが、最近のバージョンの Docker は Linux Containers on Windows (LCOW) をサポートしており、Windows と Linux の両方のコンテナーを同時に使用できます。ただし、これは新機能であるため、問題が発生する可能性があり、Dev Containers 拡張機能は現在 Linux コンテナーのみをサポートしています。Docker タスクバー項目を右クリックし、コンテキストメニューから Switch to Linux Containers... を選択することで、いつでも LCOW モードから切り替えることができます。

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

以下は、以前のバージョンの Windows 用 Docker に適用されたが、現在は解決されているはずのヒントです。再発の可能性により奇妙な動作に遭遇した場合は、これらのヒントが過去に問題を解決してきました。

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

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

  3. Docker にサインインするには、Docker ID を使用してください (メールアドレスではない)。 Docker CLI は Docker ID の使用のみをサポートしているため、メールアドレスを使用すると問題が発生する可能性があります。詳細については、Docker の issue #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 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 プッシュまたは同期時のハングの解決

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: リモートエクスプローラーを使用する

Remote Explorer を選択し、削除したいコンテナーを右クリックして、Remove Container を選択することで、コンテナーを削除できます。

Remote Explorer screenshot

ただし、これによりダウンロードしたイメージはクリーンアップされず、システムを占有する可能性があります。

オプション 2: コンテナーツール拡張機能を使用する

  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 と入力して、コンテナーを削除します。
  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 使用率

macOS 用 Docker には、高い CPU スパイクを引き起こす可能性のある既知の問題があります。特に、ファイルを監視してビルドする際に高い CPU 使用率が発生します。dev コンテナーでほとんど何も実行されていないにもかかわらず、アクティビティモニターで com.docker.hyperkit の CPU 使用率が高い場合は、この問題に遭遇している可能性があります。更新と修正については、Docker の問題をフォローしてください。

SSH トンネルを使用してリモート Docker ホストに接続する

リモート Docker マシンまたは SSH ホスト上のコンテナー内で開発する記事では、リモート Docker ホストで作業する際の VS Code の設定方法について説明しています。これは、通常、Container Tools 拡張機能の settings.json 内の 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 プロパティを使用して、再ビルド後も dev コンテナー内のユーザープロファイル (シェル履歴などを保持するため) を永続化できます。

    "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) のみが表示される場合、これはローカルの拡張機能ホストであり、リモートの拡張機能ホストは起動していません。これは、ログファイルが作成された後にのみログチャンネルが作成されるため、リモートの拡張機能ホストが起動しない場合、リモートの拡張機能ホストのログファイルは作成されず、出力ビューには表示されません。これはそれでも問題に含めるのに役立つ情報です。

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

他にもさまざまなリモートリソースがあります

08/07/2025