リモート開発に関する FAQ
この記事では、Visual Studio Code Remote Development 拡張機能のそれぞれについて、よくある質問を扱っています。それぞれの機能の設定と操作の詳細については、SSH、コンテナー、WSL の記事を参照してください。または、リモート環境で素早く作業を開始するための入門チュートリアルを試してみてください。
GitHub Codespaces に関する質問については、GitHub Codespaces ドキュメントを参照してください。
一般
Visual Studio Code Remote Development とは何ですか?
Visual Studio Code Remote Development 拡張機能パックを使用すると、コンテナー、リモートマシン (SSH 経由)、または Linux 用 Windows サブシステムで任意のフォルダーを開き、VS Code の全機能セットを利用できます。これは、コードの場所やホストに関係なく、VS Code が完全な IntelliSense (補完)、デバッグなどを含むローカル品質の開発エクスペリエンスを提供できることを意味します。
VS Code Remote Development は、ローカルでの編集と比較してどのような利点がありますか?
リモート開発の利点には、次のようなものがあります。
- ローカルで実行している OS とは異なる OS で編集、ビルド、またはデバッグできること。
- ターゲット展開環境と一致する環境で開発できること。
- 開発にローカルマシンよりも大規模または専門的なハードウェアを使用すること。
- クラウドや顧客サイトなど、別の場所に保存されているコードを編集できる機能。
- 競合を回避し、セキュリティを向上させ、オンボーディングを迅速化するために、開発者環境を分離すること。
ネットワーク共有やファイルの同期を使用する場合と比較して、VS Code Remote Development は、開発環境とツールに対するより優れた制御とともに、劇的に優れたパフォーマンスを提供します。
Remote Development 拡張機能は GitHub Codespaces とどのように関連していますか?
GitHub Codespaces は、VS Code と新しいブラウザーベースのエディターの両方からアクセスできる、マネージドクラウドホスト型開発環境を提供するサービスです。このサービスは、VS Code とブラウザーベースのエディターが、SSH サーバーや直接のネットワークルートを必要とせずに、セルフホスト型環境 (デスクトップまたはサーバー) にアクセスすることも可能にします。詳細については、GitHub Codespaces ドキュメントを参照してください。
Remote Development 拡張機能と Codespaces 拡張機能は技術と機能を共有していますが、Remote Development 拡張機能は個別にリリースされ、GitHub Codespaces とは独立して動作できます。
Remote Development 拡張機能はどのように機能しますか?
Visual Studio Code Remote Development は、「リモートサーバー」への特定のコマンドの実行を移動することで、ローカルの VS Code インストールが他のマシン (仮想または物理) 上のソースコードとランタイム環境と透過的にやり取りすることを可能にします。VS Code Server は、リモートエンドポイントに接続すると VS Code によって迅速にインストールされ、リモートワークスペース、マシン、ファイルシステムと直接やり取りする拡張機能をホストできます。
拡張機能の詳細については、リモート開発のサポートを参照してください。
Remote Development 拡張機能は、リモートマシン、VM、またはコンテナーへのアクセスをどのように保護しますか?
Visual Studio Code Remote Development は、セキュアシェルなどの既存のよく知られたトランスポートを使用して、トラフィックを認証および保護します。これらのよく知られたセキュアなトランスポートによって使用されるポート以外に、公開ポートを開く必要はありません。
注入される VS Code Server は、マシンにサインインするために使用したユーザーと同じユーザーとして実行され、VS Code とその拡張機能が許可なく不適切な昇格されたアクセス権を与えられないようにします。サーバーは VS Code によって開始および停止され、ユーザーまたはグローバルのログインスクリプトや起動スクリプトには接続されていません。VS Code はサーバーのライフサイクルを管理するため、実行されているかどうかを心配する必要はありません。
VS Code Server を単独でインストールまたは使用できますか?
いいえ。VS Code Server は Remote Development 拡張機能のコンポーネントであり、VS Code クライアントによって管理されます。エンドポイントに接続すると VS Code によって自動的にインストールおよび更新され、個別にインストールするとすぐに古くなる可能性があります。他のクライアントによる使用は意図されておらず、ライセンスも付与されていません。
VS Code Server の接続要件は何ですか?
VS Code Server のインストールには、ローカルマシンが次の場所へのアウトバウンド HTTPS (ポート 443) 接続を持っている必要があります。
update.code.visualstudio.com
vscode.download.prss.microsoft.com
デフォルトでは、Remote - SSH はリモートホストでダウンロードを試行し、接続が確立されたら VS Code Server をローカルでダウンロードしてリモートに転送するフォールバックを行います。この動作は、常にローカルでダウンロードして転送するか、またはローカルでダウンロードしないように、remote.SSH.localServerDownload 設定で変更できます。
Dev Containers 拡張機能は常にローカルでダウンロードし、コンテナーに転送します。
拡張機能: VSIX からインストール... コマンドを使用して、インターネット接続なしで拡張機能を手動でインストールできますが、拡張機能パネルまたは devcontainer.json
を使用して拡張機能をインストールする場合、ローカルマシンと VS Code Server は次の場所へのアウトバウンド HTTPS (ポート 443) アクセスが必要になります。
marketplace.visualstudio.com
*.gallerycdn.vsassets.io
(Azure CDN)
最後に、一部の拡張機能 (C# など) は download.microsoft.com
または download.visualstudio.microsoft.com
からセカンダリの依存関係をダウンロードします。その他の拡張機能 (Visual Studio Live Share など) には、追加の接続要件がある場合があります。問題が発生した場合は、拡張機能のドキュメントを参照してください。
サーバーと VS Code クライアント間の他のすべての通信は、拡張機能に応じて次のトランスポートチャネルを介して行われます。
- SSH: 認証されたセキュアな SSH トンネル。
- コンテナー: Docker の構成済み通信チャネル (
docker exec
経由)。 - WSL: ランダムなローカルポート。
VS Code 自体が必要とする場所のリストは、ネットワーク接続の記事で確認できます。
Remote - 拡張機能を使用しているときに、コンテナーツール拡張機能でローカルコンテナーが表示されないのはなぜですか?
デフォルトでは、コンテナーツール拡張機能はリモートで実行されます。これは場合によっては妥当なデフォルトですが、VS Code がリモート SSH ホスト、コンテナー、または WSL に接続されている場合、拡張機能がローカルコンテナーを表示しない可能性があることを意味します。
この問題を解決するには、次のいずれかの解決策を使用できます。
-
新しいローカルウィンドウを開き (ファイル > 新しいウィンドウ)、それを使用してローカルコンテナーを操作します。
-
Dev Containers 拡張機能をインストールし、ローカルコンテナーを表示する必要がある状況ではリモートエクスプローラーを使用します。
-
WSL のみ: WSL 2 用 Docker テクニカルプレビューを使用するか、WSL 1 で使用するように Docker Desktop を構成します。
-
Dev Containers のみ: Docker ソケットを転送し、Docker CLI (のみ) をコンテナーにインストールします。
-
extensionKind プロパティを使用して、拡張機能を強制的に
ui
にします。ただし、これにより一部のコマンドが機能しなくなる可能性があります。
Remote Development を使用するために、ホストにインストールする必要がある Linux パッケージまたはライブラリは何ですか?
Remote Development には、カーネル >= 4.18、glibc >=2.28、libstdc++ >= 3.4.25 が必要です。最近の x86_64 glibc ベースのディストリビューションが最もサポートされていますが、正確な要件はディストリビューションによって異なる場合があります。
musl ベースの Alpine Linux のサポートは Dev Containers および WSL 拡張機能で利用可能であり、ARMv7l (AArch32) / ARMv8l (AArch64) は Remote - SSH で利用可能です。ただし、一部の拡張機能のネイティブ依存関係により、x86_64 glibc 以外のディストリビューションでは機能しない場合があります。実験的な ARMv8l (AArch64) は VS Code Insiders のみで利用可能です。
詳細については、Linux でのリモート開発を参照してください。
古い Linux ディストリビューションで VS Code Server を実行できますか?
VS Code リリース 1.99 (2025 年 3 月) 以降、VS Code によって配布されるビルド済みサーバーは、glibc 2.28 以降をベースとする Linux ディストリビューションのみと互換性があります。これには、たとえば Debian 10、RHEL 8、Ubuntu 20.04 などが含まれます。
VS Code は、これらの必要なライブラリバージョンを持つ sysroot が提供されている場合、Remote - SSH 拡張機能経由で、VS Code でサポートされていない OS (glibc >= 2.28 および libstdc++ >= 3.4.25 を持たない OS) への接続を依然として許可します。このアプローチにより、お客様とその組織は、新しい Linux ディストリビューションへの移行により多くの時間をかけることができます。
VS Code バージョン | 基本要件 | 注 |
---|---|---|
>= 1.99.x | カーネル >= 4.18、glibc >=2.28、libstdc++ >= 3.4.25、binutils >= 2.29 | <なし> |
このアプローチは技術的な回避策であり、正式にサポートされている使用シナリオではありません。
この回避策のために環境を構成するには、次の手順に従います。
-
sysroot をビルドする
sysroot のビルドには Crosstool-ng を使用することをお勧めします。開始できる構成の例をいくつか示します。
次のコンテナーの例は、Crosstool-ng がインストールされた環境を持つためにも使用できます。
FROM ubuntu:latest RUN apt-get update RUN apt-get install -y gcc g++ gperf bison flex texinfo help2man make libncurses5-dev \ python3-dev autoconf automake libtool libtool-bin gawk wget bzip2 xz-utils unzip \ patch rsync meson ninja-build # Install crosstool-ng RUN wget http://crosstool-ng.org/download/crosstool-ng/crosstool-ng-1.26.0.tar.bz2 RUN tar -xjf crosstool-ng-1.26.0.tar.bz2 RUN cd crosstool-ng-1.26.0 && ./configure --prefix=/crosstool-ng-1.26.0/out && make && make install ENV PATH=$PATH:/crosstool-ng-1.26.0/out/bin
Crosstool-ng がインストールされ、関連する構成が準備された環境がある場合は、次のコマンドを実行して sysroot を生成します。
mkdir toolchain-dir cd toolchain-dir cp <path-to-config-file> .config ct-ng build
-
VS Code サーバーは、インストールプロセス中に patchelf を使用して、sysroot から必要なライブラリを使用します。
patchelf v0.17.x
はリモートサーバーでセグメンテーション違反を引き起こすことが知られています。patchelf >=v0.18.x
を使用することをお勧めします。
-
リモートホストに patchelf バイナリと sysroot をインストールします。
-
次の 3 つの環境変数を作成します。
これで、Remote - SSH 拡張機能を使用してリモートに接続できるようになりました。接続に成功すると、VS Code は接続がサポートされていないことを示すダイアログとバナーメッセージを表示します。
拡張機能パックではなく、個々の拡張機能をインストールできますか?
はい。Remote Development 拡張機能パックは、リリースされた最新のリモート機能すべてにアクセスするための便利な方法を提供します。ただし、常にマーケットプレイスまたは VS Code 拡張機能ビューから個々の拡張機能をインストールできます。
拡張機能の設定を確認および構成するにはどうすればよいですか?
Visual Studio Code の他の部分と同様に、Remote Development 拡張機能のそれぞれをその設定を通じてカスタマイズできます。Dev Containers を例にとると、拡張機能ビューで拡張機能を開き (⇧⌘X (Windows、Linux Ctrl+Shift+X))、機能の寄与に移動することで、すべての Dev Containers 設定のリストを確認できます。
WSL
WSL をターミナルとして使用することと比較して、拡張機能の利点は何ですか?
WSL は Windows 上で動作する Linux マシンと考えることができ、Windows のセットアップに影響を与えることなく、Linux 固有のフレームワーク/ツール (例: Python、Go、Rust など) をインストールできます。その後、VS Code と WSL 拡張機能を使用して、WSL にインストールされているもの (Windows にインストールされているものとは分離された) のコンテキストで開発できます。
たとえば、WSL に Go スタック (コンパイラ、デバッガー、リンターなど) をインストールできます。VS Code を Windows 上でのみ実行する場合、スマートな補完、デバッグ、定義への移動などの機能を取得するには、同じ Go スタックを Windows 上にもインストールする必要があります。そして、言語サービスは Windows 上で実行されているため、WSL に何があるのかを認識しません。
確かに、Windows から WSL のバイナリを実行したり、その逆も可能ですが、通常の VS Code 拡張機能はこれを行う方法を知りません。これが WSL でのデバッグをサポートし始めた方法ですが、すぐにすべての拡張機能を WSL を認識するように更新する必要があることに気付きました。
代わりに、VS Code の一部を WSL で実行し、Windows で実行されている UI が WSL で実行されている VS Code サーバーと通信するようにすることにしました。これが WSL 拡張機能が有効にするものであり、これにより、Go 拡張機能は残りの Go ツール (コンパイラ、デバッガー、リンター) とともに WSL で実行され、VS Code は Windows で実行されます。
このアプローチにより、スマートな補完などの言語機能は、Windows に何も設定することなく、WSL 内のものを対象に機能します。パスの問題を心配したり、Windows 上で異なるバージョンの開発スタックを設定したりする必要はありません。Linux にアプリケーションをデプロイする場合、Windows で豊富な編集エクスペリエンスを維持しながら、WSL インスタンスを実行環境のように見えるように設定できます。
拡張機能の作成者
拡張機能の作成者として、何をすべきですか?
VS Code 拡張機能 API はローカル/リモートの詳細を抽象化するため、ほとんどの拡張機能は変更なしで動作します。ただし、拡張機能は任意のノードモジュールまたはランタイムを使用できるため、調整が必要な状況があります。更新が必要ないことを確認するために、拡張機能 (特にコンテナー内) をテストすることをお勧めします。詳細については、リモート開発のサポートを参照してください。
ユーザーがリモートに接続している場合、拡張機能はローカルリソースまたは API にアクセスできますか?
VS Code がリモート環境に接続すると、拡張機能はUI拡張機能またはワークスペース拡張機能に分類されます。UI 拡張機能はローカル拡張機能ホストで実行され、UI またはパーソナライズ機能 (テーマなど) を提供でき、ローカルファイルまたは API にアクセスできます。ワークスペース拡張機能は、ワークスペースとともにリモート拡張機能ホストで実行され、ソースコード、リモートファイルシステム、およびリモート API に完全にアクセスできます。ワークスペース拡張機能は UI のカスタマイズに焦点を当てていませんが、エクスプローラー、ビュー、その他の UI 要素も提供できます。
ユーザーが拡張機能をインストールすると、VS Code は正しい場所を推測し、そのタイプに基づいてインストールしようとします。テーマやその他の UI カスタマイズなど、リモートで実行する必要のない拡張機能は、UI 側に自動的にインストールされます。その他はすべて、最も機能が豊富であるため、ワークスペース拡張機能として扱われます。ただし、拡張機能の作成者は、package.json
の extensionKind
プロパティでこの場所をオーバーライドすることもできます。
拡張機能が期待どおりに機能しない場合は、正しい場所で実行されているか、または異なる extensionKind
を持つべきかをチェックする手順があります。また、拡張機能の作成者がリモート開発と Codespaces について知る必要があることの詳細については、リモート開発のサポートも参照してください。
ライセンスとプライバシー
場所
VS Code Remote Development 拡張機能のライセンスは、こちらから確認できます。
Remote Development 拡張機能またはそのコンポーネントがオープンソースではないのはなぜですか?
Visual Studio Code Remote Development 拡張機能とその関連コンポーネントは、オープンな計画、問題、機能要求プロセスを使用していますが、現在はオープンソースではありません。これらの拡張機能は、GitHub Codespaces などの完全にマネージドされたリモート開発サービスとその関連拡張機能でも使用されているソースコードを共有しています。
詳細については、Visual Studio Code と 'Code - OSS' の違いおよびMicrosoft 拡張機能のライセンスの記事を参照してください。
Remote Development 拡張機能が接続できる場所に制限はありますか?
これらの拡張機能は、個人用および企業用の両方で、独自の物理マシン、仮想マシン、またはコンテナーに接続するために自由に使用できます。これらはオンプレミス、独自のプライベートクラウドまたはデータセンター、Azure、またはその他のクラウド/非クラウドホスティングプロバイダーにある可能性があります。ただし、これらの拡張機能または関連コンポーネントの上にパブリック製品やサービスを構築することはできません (次の質問を参照)。
VS Code Remote Development 拡張機能を使用して独自の製品またはサービスを構築できますか?
これらの拡張機能は、独自の内部またはプライベートサービスで使用できます。VS Code Remote Development 拡張機能またはその関連コンポーネント (例: VS Code Server) の上にパブリックまたは商用サービスを構築することはできません。Remote Development 拡張機能を拡張または操作する他の拡張機能を作成することはできません。ライセンスには「ソフトウェアをスタンドアロンまたは統合された提供物として提供したり、他のユーザーが使用するためにアプリケーションと組み合わせたりすることはできません」と記載されていますが、サービスと連携して拡張機能を使用する方法を文書化することはできます。
VS Code Server を再パッケージ化して、独自の公開サービス提供で再利用できますか?
いいえ。ライセンスには「ソフトウェアをスタンドアロンまたは統合された提供物として提供したり、他のユーザーが使用するためにアプリケーションと組み合わせたりすることはできません」と記載されており、これは VS Code Server の上にパブリック製品またはサービスを構築できないことを意味します。
拡張機能を X に使用できるかどうかについて質問があります。誰に尋ねることができますか?
イシューを提出してください。
GDPR と VS Code Remote Development
VS Code Remote Development 拡張機能は、Visual Studio Code 自体と同様に GDPR ポリシーに従います。詳細については、一般 FAQ を参照してください。
質問またはフィードバック
質問やフィードバックがありますか?
- ヒントとテクニックを参照してください。
- Stack Overflowで検索します。
- 機能リクエストを追加するか、問題を報告します。