トレーニング
認定資格
Microsoft Certified: Azure Virtual Desktop Specialty - Certifications
Microsoft Azure で任意のデバイスの仮想デスクトップ エクスペリエンスとリモート アプリを計画、配信、管理、監視します。
このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
Dev Drive は、主要な開発者ワークロードのパフォーマンスを向上させるために使用できる、新しい形式のストレージ ボリュームです。
Dev Drive は、対象となるファイル システムの最適化を採用するために ReFS テクノロジに基づいて構築されており、ストレージ ボリュームの設定とセキュリティのより細かい制御 (信頼の指定、ウイルス対策の構成、アタッチするフィルターの管理制御など) が可能です。
一般的な開発操作の平均改善測定値については、ブログ投稿「Visual Studio のパフォーマンス向上のための Dev Drive と Dev Box」を参照してください。
新しい開発者ドライブを設定するには、Windows の [設定] を開き、[システム]>[ストレージ]>[ストレージの詳細設定]>[ディスクとボリューム] に移動します。 [Create Dev Drive]\(Dev Drive の作成\) を選択します。 既存のストレージ ボリュームを Dev Drive に変換することはできません。 Dev Drive の指定は、最初のフォーマット時にのみ行われます。
Dev Drive を設定する前に、前提条件が満たされていることを確認します。また、Dev Home のデバイス構成を使用しても Dev Drive を設定できます。
最新の Windows 11 リリースに更新する場合は、Dev Drive 機能を利用できるようになる前に、追加の再起動が必要になる場合があります。 ビジネス エンタープライズ環境で作業している場合、Dev Drive を有効にするには、セキュリティ管理者が Dev Drive セキュリティ ポリシー を構成する必要があります。
警告
Dev Drive は主要な開発者シナリオのみを対象としています。カスタム設定は引き続き、ビジネスまたはエンタープライズの作業環境のグループ ポリシー設定の対象となります。 Dev Drive のセキュリティ ポリシーを構成する方法の詳細について説明します。
次の 3 つのオプションを使用できます。
ディスク パーティションを作成するか Dev Drive を格納するために新しい VHD を作成するかを選択する際に考慮すべき利点とトレードオフがあります。
ディスク パーティションの作成: ディスク パーティションに Dev Drive を格納すると、通常、追加のレイヤーなしで物理ディスクを直接使用するため、パフォーマンスが向上します。 パーティションが物理ディスクに関連付けられているため、パーティションのサイズ変更は複雑でリスクが高く、移植性が低下する可能性があるため、パーティションされたディスクを使用する方が柔軟性が低くなります。
新しい VHD を作成する: 仮想ハード ディスク (VHD) に Dev Drive を格納すると、仮想ディスク レイヤーを管理するオーバーヘッドが原因でパフォーマンスが若干低下する可能性があります。 トレードオフとして、VHD は動的なサイズ変更 (ディスク領域を効率的に管理する必要がある場合)、データの移動、またはバックアップを柔軟に行うことができます。 VHD も移植性が高く、VHD ファイルを別のコンピューターまたはバックアップの場所に転送できます。 固定ディスク (HDD または SSD) 上で VHD がホストされる場合は、VHD をコピーして別のマシンに移動し、それを開発ドライブとして使用し続けることは推奨されません。
新しい VHD を作成するオプションを選択して Dev Drive を設定する場合は、次を決定する必要があります。
C:\
です。ただし、Dev Home を使用して Dev Drive を作成している場合は例外です。その場合、既定の場所は %userprofile%\DevDrives
です。 意図しない共有を回避するために、ユーザーごとのディレクトリ パスの場所を使用して Dev Drive を格納することをお勧めします。これらのオプションを選択するプロセスが完了すると、Dev Drive が作成されます。
既存のボリュームのサイズを変更するには:
サイズを変更するボリュームを選択します。
ボリュームの新しいサイズを選択します。 Dev Drive に必要な最小サイズである 50 GB の未割り当て領域が少なくとも必要です。 サイズを設定したら、[次へ] を選択します。
新しい空き領域に Dev Drive をフォーマットするために、[ラベル] (ドライブ名)、[Drive Letter](ドライブ文字)、[Size](サイズ) の割り当てを指定します。 最大サイズは、前の手順で割り当てた空き領域の量であり、Dev Drive の最小サイズは 50 GB です。
おめでとうございます。 これで、Dev Drive のサイズが変更されました。
既存のドライブ上の未割り当て領域を検索して使用するには、[システム]>[ストレージ]>[ディスクとボリューム] を開き、ページに目を通して、いずれかの記憶領域に [未割り当て] と表示されているかどうかを確認します。 [ボリュームの作成] を選択すると、[Create Simple Volume]\(シンプル ボリュームの作成\) (標準の NTFS ストレージ ボリューム) または [Create Dev Drive]\(Dev Drive の作成\) の選択肢が表示されます。 Dev Drive を作成する手順は上記と同じです。[ラベル] (ドライブ名)、[Drive Letter](ドライブ文字) を追加し、[Size](サイズ) の割り当てを確認する必要があります。
Windows 設定を使用する代わりに、コマンド ラインから Dev Drive ストレージ ボリュームを作成する場合は 2 つのオプションがあります。 いずれのオプションも、管理者としてコマンド ラインを開く必要があります。 ハード ドライブをフォーマットするには、管理者グループのメンバーである必要があります。 複数の開発者ドライブを作成する場合や、複数のコンピューターの管理者として使用する場合は、これらのコマンド ラインの書式設定方法が推奨されます。
Format D: /DevDrv /Q
Format-Volume -DriveLetter D -DevDrive
これらのコード サンプルでは、ターゲットにするドライブの場所に D:
を置き換える必要があります。 その他のオプションとコマンド パラメーターの詳細については、リンクを参照してください。
ストレージ ボリュームは、ディレクトリとファイルを使用して、特定の形式でファイル システムにデータを格納する方法を指定します。 Windows ではシステム ドライブに NTFS を使用し、ほとんどの非リムーバブル ドライブに既定で NTFS を使用しています。 Resilient File System (ReFS) は、Microsoft の新しいファイル システムであり、データの可用性を最大化し、さまざまなワークロードの大規模なデータ セットに対して効率的に拡張し、破損に対する回復性を備えたデータの整合性を提供するように設計されています。 拡大する一連のストレージ シナリオに対処し、将来のイノベーションの基盤を確立することを目指しています。
Dev Drive では ReFS が利用されているため、開発ワークロード専用のストレージ ボリュームを初期化できます。また、より高速なパフォーマンスを実現し、開発シナリオに合わせて最適化されたカスタマイズ可能な設定を使用できます。 ReFS には、主要な開発者シナリオのパフォーマンスを向上させるために、いくつかのファイル システム固有の最適化が含まれています。
Dev Drive でのセキュリティの処理方法の詳細については、こちらを参照してください。
Dev Drive は次を対象としています。
Dev Drive に開発者ツールと SDK をインストールする際の考慮事項: 開発者ツールと SDK は、通常、管理者またはユーザー単位の場所に配置されます。 これらの場所は、Windows での特定のセキュリティと分離の保証を提供し、Microsoft Defender の動作に影響を与えます。 ただし、多くのツールでは、Dev Drive を含め、インストール場所を柔軟に選択できます。
Dev Drive に開発者ツールまたは SDK をインストールする前に、システムと非同期スキャンに関連付けられているトレードオフを評価して、デバイスと組織のセキュリティ要件と一致していることを確認します。 Dev Drive に管理者またはユーザー単位のフォルダーを作成するオプションがあります。 さらに、Microsoft Defender パフォーマンス モード (非同期スキャンなど) がバイナリを処理するためのニーズを満たしていることを確認することが重要です。
注意
IT 管理者は、EOP 攻撃を回避するためのベスト プラクティスとして、マルチユーザー デバイス用のアクセス制御リスト (ACL) フォルダーをユーザーごとに作成する必要があります。
パッケージ キャッシュとは、インストールされているソフトウェアのファイルを格納するためにアプリケーションによって使用されるグローバル フォルダーの場所です。 これらのソース ファイルは、インストールされているソフトウェアを更新、アンインストール、または修復する際に必要です。 Visual Studio は、そのデータの大部分をパッケージ キャッシュに格納するアプリケーションの 1 つです。 環境変数を変更した後、新しい値を適用するには、開いているすべてのコンソール ウィンドウを再起動するか、デバイスを再起動する必要があります。
Npm キャッシュ (NodeJS): Dev Drive に npm キャッシュ ディレクトリを作成し (D:\packages\npm
など)、グローバル環境変数 npm_config_cache
をそのパスに設定します (setx /M npm_config_cache D:\packages\npm
など)。 コンピューターに NodeJS を既にインストールしている場合は、%AppData%\npm-cache
の内容をこのディレクトリに移動します。 (一部のシステムでは、npm キャッシュは %LocalAppData%\npm-cache
にあることがあります)。 詳細については、npm ドキュメントの npm-cache と npm config: cache を参照してください。
NuGet グローバル パッケージ フォルダー: NuGet グローバル パッケージ フォルダーは、dotnet、MSBuild、Visual Studio によって使用されます。 CopyOnWrite (CoW) ファイルシステムに、ユーザー固有の NuGet ディレクトリを作成します。 たとえば、 D:\<username>\.nuget\packages
と指定します。 次のいずれかの方法で、グローバル パッケージ フォルダーを既定の場所から新しく作成したフォルダーに変更します (グローバルにインストールされたパッケージを管理するため)。
グローバル環境変数 NUGET_PACKAGES
を該当のパスに設定します。 たとえば、 setx /M NUGET_PACKAGES D:\<username>\.nuget\packages
と指定します。
構成設定で、globalPackagesFolder
(PackageReference
を使用する場合) または repositoryPath
(packages.config
を使用する場合) を該当のパスに設定します。
RestorePackagesPath
MSBuild プロパティ (MSBuild のみ) を該当のパスに設定します。
global-packages フォルダーを確認するには、dotnet nuget locals コマンド dotnet nuget locals global-packages --list
を実行します。 復元により、パッケージが新しいパスにインストールされ、ダウンロードされます。 既定の NuGet グローバル パッケージ フォルダーは削除できます。 詳細については、NuGet ドキュメント「グローバル パッケージ、キャッシュ、および一時フォルダーを管理する」を参照してください。
注意
現在、Dotnet ツール コマンドでは、nuget パッケージのパスが考慮されないという既知の問題があります。 .NET チームは、.NET 10 の修正プログラムと 8.0 および 9.0 のサービス リリース更新プログラムを認識し、調査しています。
vcpkg キャッシュ: Dev Drive に vcpkg キャッシュ ディレクトリを作成し (D:\packages\vcpkg
など)、グローバル環境変数 VCPKG_DEFAULT_BINARY_CACHE
をそのパスに設定します (setx /M VCPKG_DEFAULT_BINARY_CACHE D:\packages\vcpkg
など)。 パッケージを既にインストールしている場合は、%LOCALAPPDATA%\vcpkg\archives
または %APPDATA%\vcpkg\archives
の内容をこのディレクトリに移動します。 詳細については、vcpkg のドキュメント「バイナリ キャッシュ」を参照してください。
Pip キャッシュ (Python): Dev Drive に pip キャッシュ ディレクトリを作成し (D:\packages\pip
など)、グローバル環境変数 PIP_CACHE_DIR
をそのパスに設定します (setx /M PIP_CACHE_DIR D:\packages\pip
など)。 コンピューターで pip パッケージと Wheel を既に復元している場合は、%LocalAppData%\pip\Cache
の内容をこのディレクトリに移動します。 詳細については、pip ドキュメントの「pip キャッシュ」と StackOverflow の「Linux で pip キャッシュのディレクトリを変更するには?」を参照してください。
Cargo キャッシュ (Rust): Dev Drive に Cargo キャッシュ ディレクトリを作成し (D:\packages\cargo
など)、グローバル環境変数 CARGO_HOME
をそのパスに設定します (setx /M CARGO_HOME D:\packages\cargo
など)。 コンピューターで Cargo パッケージを既に復元している場合は、%USERPROFILE%\.cargo
の内容をこのディレクトリに移動します。 詳細については、Cargo ドキュメントの「Cargo 環境変数」を参照してください。
Maven キャッシュ (Java): Dev Drive に Maven キャッシュ ディレクトリを作成し (D:\packages\maven
など)、グローバル環境変数 MAVEN_OPTS
を設定してそのパスに構成設定を追加します (setx /M MAVEN_OPTS "-Dmaven.repo.local=D:\packages\maven"
など)。 %USERPROFILE%\.m2\repository
の内容をこのディレクトリに移動します (これには、Maven が repository
フォルダーにダウンロードしてプロジェクトに使用する依存関係、プラグイン、その他の成果物のみが含まれます)。 詳細については、Maven ドキュメントと StackOverflow の「.m2 フォルダーの代替場所を指定する、または settings.xml を永続的に編集する方法は?」を参照してください。
Gradle キャッシュ (Java): 開発ドライブに Gradle キャッシュ ディレクトリを作成します (例: D:\packages\gradle
)。 次に、そのパスを指すようにグローバル環境変数の GRADLE_USER_HOME
を設定します。たとえば、コマンド ラインで setx /M GRADLE_USER_HOME "D:\packages\gradle"
を使用してシステム全体にその変数を設定します。 この変数を設定したら、Gradle は指定されたディレクトリ (D:\packages\gradle
) をキャッシュと構成ファイルに使用します。 既存の Gradle ファイルがある場合は、%USERPROFILE%\.gradle
のコンテンツをこの新しいディレクトリに移動します。 詳細については、Gradle のドキュメントを参照し、Gradle の構成とキャッシュ ディレクトリの管理に関するヒントについては、StackOverflow などのコミュニティ リソースを確認してください。
セキュリティと信頼は、プロジェクト ファイルを操作する際の重要な考慮事項です。 通常、パフォーマンスとセキュリティの間にはトレードオフがあります。 Dev Drive を使用すると、開発者とセキュリティ管理者の手でこのバランスを制御できます。その場合、追加するフィルターと、Microsoft Defender ウイルス対策スキャンの設定を選択する責任があります。
既定では、Microsoft Defender とサード パーティのウイルス対策フィルターの両方を含むウイルス対策フィルターが Dev Drive に追加されます。 Microsoft Defender ウイルス対策は、既定で Dev Drive の新しい "パフォーマンス モード" 設定に設定され、速度とパフォーマンスを考慮しながら、フォルダーの除外に代わる安全な代替手段を提供します。 保護レベルを上げるため、Microsoft Defender では、"リアルタイム保護モード" も提供されます。
追加のフィルターを必要とする製品または機能は、そのフィルターが Dev Drive に追加されない限りは機能しません。
警告
Dev Drive は、ウイルス対策フィルターが追加されていない状態で実行できます。 細心の注意を払ってください。 ウイルス対策フィルターを削除することはセキュリティ上のリスクであり、ストレージ ドライブが標準のセキュリティ スキャンの対象にならないことを意味します。 あなたは、ウイルス対策フィルターの削除に関連するリスクを評価する責任を負っています。これを行うのは、Dev Drive に保存されているファイルが悪意のある攻撃にさらされないことを確信している場合にのみにしてください。
Microsoft では、"信頼された" Dev Drive を使用する場合は、既定のパフォーマンス モード設定を使用することをお勧めします。
Dev Drive は、最初のフォーマット時にシステム レジストリに格納されたフラグを使用して "信頼済み" として自動的に指定され、可能な限り最高のパフォーマンスを既定で提供します。 "信頼済み" の Dev Drive とは、ボリュームを使用する開発者が、そこに格納されているコンテンツのセキュリティに高い信頼を置いていることを意味します。
Windows セキュリティに除外を追加する場合と同様に、開発者は、パフォーマンスを向上させるために格納コンテンツのセキュリティを管理する責任を負います。
"信頼済み" とマークされた Dev Drive は、Microsoft Defender がパフォーマンス モードで実行されていることを示すシグナルです。 Microsoft Defender がパフォーマンス モードで実行されていると、脅威の防止とパフォーマンスのバランスが維持されます。 リアルタイム保護は、他のすべてのストレージ ボリュームで引き続き有効になります。
フィルターをデタッチするセキュリティ上の考慮事項により、コンピューター間で Dev Drive を転送すると、ボリュームは特別なフィルター アタッチ ポリシーのない通常のボリュームとして扱われます。 ボリュームは、新しいコンピューターへのアタッチ時に "信頼済み" とマークされる必要があります。 「Dev Drive を信頼済みとして指定する方法」を参照してください。
"信頼されていない" Dev Drive には、"信頼済み" の Dev Drive と同じ特権は付与されません。 Dev Drive が "信頼されていない" 場合、セキュリティはリアルタイム保護モードで実行されます。 最初の作成時以外に Dev Drive に信頼を指定する場合は、注意が必要です。
Dev Drive を "信頼済み" として指定するには:
<drive-letter>
は、信頼を指定するストレージ ドライブの文字に置き換えます。 たとえば、fsutil devdrv trust D:
のように指定します。fsutil devdrv trust <drive-letter>:
Dev Drive が信頼済みになったかどうかを確認するには、次のコマンドを入力します。
fsutil devdrv query <drive-letter>:
コンピューター上の C: ドライブを Dev Drive として指定することはできません。 Visual Studio、MSBuild、.NET SDK、Windows SDK などの開発者ツールは、Dev Drive ではなく C: ドライブに格納する必要があります。
新しい Microsoft Defender ウイルス対策機能として、パフォーマンス モードが Windows 11 で使用できるようになりました。 この機能により、指定された Dev Drive に格納されているファイルに対する Microsoft Defender ウイルス対策スキャンのパフォーマンスへの影響が軽減されます。
パフォーマンス モードの詳細と、リアルタイム保護との比較の詳細については、「Microsoft Defender: パフォーマンス モードを使用した Dev Drive の保護」を参照してください。
パフォーマンス モードを有効にするには、Dev Drive を “信頼済み” として指定し、Microsoft Defender のリアルタイム保護を “オン” に設定する必要があります。
既定では、フィルター マネージャー によって、ウイルス対策フィルターを除くすべてのフィルターが Dev Drive でオフにされます。 ウイルス対策フィルターとは、FSFilter Anti-Virus
高度範囲 (320000-329999) にアタッチされているフィルターです。 FSFilter Anti-Virus
には、ファイル I/O 中にウイルスを検出して駆除するフィルターが含まれています。
Dev Drive にウイルス対策フィルターを追加しないように既定のポリシーを構成できます。そのためには、fsutil
を使用します。 注意: このポリシーは、システム上のすべての Dev Drive に適用されます。
fsutil devdrv enable /disallowAv
コマンド fsutil devdrv enable [/allowAv|/disallowAv]
には、次の 2 つのオプションがあります。
disallowAv
: Dev Drive にフィルター (ウイルス対策も) を追加しないことを指定します。 fsutil devdrv setfiltersallowed <Filter-1>
コマンドを使用すると、フィルターを再度追加できます。 (<Filter-1>
を目的のフィルターの名前に置き換えてください。)
allowAv
: 既定のウイルス対策フィルターによって Dev Drive を保護することを指定します。
ヘルプを表示するには、fsutil devdrv enable /?
コマンドを入力します。 /allowAv
と /disallowAv
のどちらも指定されていない場合、Dev Drive のウイルス対策ポリシーは構成されず、システムの既定値でウイルス対策フィルターによって Dev Drive が保護されます。
警告
フィルターを削除するときは細心の注意を払ってください。 ウイルス対策フィルターを削除することはセキュリティ上のリスクであり、ストレージが標準のMicrosoft Defender リアルタイム保護またはパフォーマンス モード スキャンの対象にならないことを意味します。 あなたは、ウイルス対策フィルターの削除に関連するリスクを評価する責任を負っています。これを行うのは、ファイルが悪意のある攻撃にさらされないことを確信している場合にのみにしてください。
フィルターの詳細については、「ファイル システム フィルター ドライバーについて」、「フィルター ドライバーのインストール」、「フィルター マネージャーの概念」、「ミニフィルター ドライバーの順序グループと高度を読み込む」を参照してください。
ビジネスまたはエンタープライズの環境で作業している場合、上のポリシーに加えて、Dev Drive に一部のフィルターを追加するように会社のグループ ポリシーが構成されている場合があります。 システム管理者は、許可リストを使用して、特定の Dev Drive またはすべての Dev Drive に追加のフィルターを加えることもできます。
システム管理者は、"Foo" というフィルター (FooFlt
と呼ぶ) を追加する場合があります。 このフィルターを有効にするのは、D:
としてマウントされた Dev Drive でのみの場合があります。 このフィルターは、E:
としてマウントした別の Dev Drive では必要ありません。 管理者は、システム提供のコマンド ライン ユーティリティである fsutil.exe を使用して、Dev Drive のフィルターの許可リストに変更を加えることができます。
上記のウイルス対策フィルター ポリシーに加えて、明確に [許可] に設定されているフィルターを追加できます。
次の例は、許可リストを使用して、コンピューター上のすべての Dev Drive でフィルターを許可済みに設定する管理者機能を示しています。
setfiltersallowed
コマンドを使用して Filter-01
と Filter-02
をすべての Dev Drive で許可するには、次のコマンドを使用します。
fsutil devdrv setfiltersallowed Filter-01, Filter-02
すべての Dev Drive のフィルター アタッチ ポリシーを表示するには、次のコマンドを使用します。
fsutil devdrv query
結果には、次の情報が表示されます。
Filter-01
フィルターと Filter-02
フィルターが許可されている。Dev Drive で Filter-03
のみを許可し、Filter-01
と Filter-02
のアタッチを許可しないようにこの Dev Drive の構成を変更するには、次のコマンドを使用します。
fsutil devdrv setfiltersallowed Filter-03
その他の関連コマンドについては、fsutil devdrv /?
を参照してください。
Dev Drive では、次のフィルターを使用できます。
シナリオ: 説明 | フィルター名 |
---|---|
GVFS: Windows のスパース参加リスト | PrjFlt |
MSSense: EDR センサーの Microsoft Defender for Endpoint | MsSecFlt |
Defender: Windows Defender フィルター | WdFilter |
Docker: 開発者ドライブからコンテナーを実行する | bindFlt、wcifs |
Windows パフォーマンス レコーダー: ファイル システムの操作を測定する | FileInfo |
リソース モニター: リソースの使用状況を表示します ディスクアクティビティでファイル名を表示するために必要 | FileInfo |
プロセス モニター - Sysinternals: ファイル システムのアクティビティを監視する | ProcMon24 |
Windows アップグレード: OS のアップグレード中に使用されます。 ユーザーが TEMP 環境変数を Dev Drive に移動する場合は必須 | WinSetupMon |
Windows Defender Application Control (WDAC): AppLocker ID サービスを使用した管理対象インストーラーの追跡 | applockerfltr |
WdFilter
は既定でアタッチされます。 次のコマンドは、これらの追加フィルターをすべて Dev Drive にアタッチする方法を示す例です。
fsutil devdrv setfiltersallowed "PrjFlt, MsSecFlt, WdFilter, bindFlt, wcifs, FileInfo, ProcMon24"
ヒント
特定のシナリオに必要なフィルターを決定するには、Dev Drive を "信頼されていない" ものとして一時的にマークする必要があります。 次に、シナリオを実行し、ボリュームにアタッチされているすべてのフィルターをメモします。 Dev Drive をもう一度 "信頼済み" として指定し、その Dev Drive の許可リストにフィルターを追加して、シナリオが成功することを確認します。 最後に、必要ないフィルターを一度に 1 つずつ削除し、シナリオが想定どおりに動作することを確認します。
ヒント
プロセス モニターのフィルター名は変更される場合があります。 フィルター名 "ProcMon24" を追加しても開発ドライブのファイル システム アクティビティが取得されない場合は、コマンド fltmc filters
を使用してフィルターを一覧表示し、プロセス モニターのフィルター名を見つけて、"ProcMon24" の代わりにその名前を使用します。
Windows 11 24H2 & Windows Server 2025 以降、Dev Driveでブロック複製がサポートされるようになりました。 Dev Drive は、ReFS ファイル システム形式を利用するため、ブロック複製サポートは、Dev Drive を使用してファイルをコピーするたびに、パフォーマンスが向上されることを意味します。 ブロックの複製を使用すると、ファイル システムは、基盤となる物理データに対してコストのかかる読み取りおよび書き込み操作を実行するのではなく、低コストのメタデータ操作としてアプリケーションに代わってファイル バイトの範囲をコピーできます。 これにより、複数のファイルが同じ論理クラスターを共有できるようになり、ファイルのコピーがより速く完了し、基盤となるストレージへの I/O が削減され、ストレージ容量が向上します。 詳細については、「ブロックの複製」を参照してください。
Dev Drive の使用を推奨しないシナリオがいくつかあります。 具体的な内容は次のとおりです。
Dev ドライブは Windows 11 システム設定 System
>Storage
>Disks & volumes
で削除できます。
Windows の [設定] メニューを開き、[ストレージ]、[ストレージの詳細設定]、[ディスクとボリューム] の順に選択すると、デバイス上のストレージ ボリュームの一覧が表示されます。 削除する Dev ドライブのストレージ ボリュームの横にある [プロパティ] を選択します。 ドライブのプロパティの [フォーマット] ラベルの下に、[削除] オプションがあります。
これで開発ドライブは削除されます。 ただし、Dev Drive が新しい VHD として作成された場合は、その VHD が使用していたストレージ領域を再使用するために VHD を削除する必要。 これを行うには、仮想ディスクを切断して、Dev Drive をホストしている VHD ファイルを削除できるように次の手順に従う必要:
Dev Drive に関してよく寄せられる質問には、次のようなものがあります。
Dev Drive の既定の設定は一般的な開発シナリオ用に最適化されていますが、カスタマイズしてストレージ ボリュームで実行されるドライバーとサービスを制御できます。 Dev Drive の設定をカスタマイズするには、[設定] メニューを開きます。 [システム]>[ストレージ]>[ディスクとボリューム]で、[プロパティ] に移動します。
重要
ビジネスまたはエンタープライズで作業している場合、Dev Drive は引き続きエンタープライズ設定によって管理されます。 そのため、会社のポリシーによっては、一部のカスタマイズが使用できない場合があります。
いいえ。コンピューターの C: ドライブにインストールされているアプリケーションやツールは、Dev Drive のファイルを利用できます。 ただし、開発プロジェクトの場合は、プロジェクト固有のディレクトリ、ファイル、パッケージ キャッシュを Dev Drive 内に格納することをお勧めします。 Dev Drive は、簡単に見つけられるように、エクスプローラーのクイック アクセスにピン留めできます。
はい。ReFS では NTFS よりもわずかに多くのメモリが使用されます。 少なくとも 8 GB のメモリ、理想的には 16 GB のメモリがあるコンピューターを使用することをお勧めします。
はい。 領域がある場合は、Dev Drive を必要なだけ作成できます。 ソフトウェア開発プロジェクトごとに個別の Dev Drive を使用すると、開発終了時にドライブを削除するだけで済みます。ディスクをもう一度パーティション分割する必要はありません。 ただし、Dev Drive の最小サイズは 50 GB なので注意してください。
Dev Drive が作成されると、新しいプロジェクトの作成時、または既存のプロジェクトを複製するときに、Visual Studio によって自動的に Dev Drive が認識され、既定でそのファイルパスが選択されます。 Visual Studio を使用する場合のパフォーマンスを最適化するには、プロジェクト コード、パッケージ キャッシュ、Copy on write
MS ビルド タスクを、以前他の場所に保存されていた可能性がある Dev Drive に移動することをお勧めします。 (Visual Studio ドキュメントで「ビルド出力ディレクトリを変更する方法」を参照してください。)%TEMP%
と %TMP%
envvar を開発者ドライブにリダイレクトすることも検討することをおすすめします。 これを行うには、Windows Update プロセスに必要な WinSetupMon
フィルターも追加する必要があります。 (「一般的なシナリオのフィルター」を参照してください)。 これらは多くのプログラムで使用されているため、生じ得る副作用に注意してください。 また、Dev Drive を使用した非同期のパフォーマンスを向上させるために、Microsoft Defender のパフォーマンス モードを使用することをお勧めします。 Microsoft Defender を完全にオフにすると、パフォーマンスが最大限に高まる可能性がありますが、これによりセキュリティ リスクが増大する可能性があります。この設定はシステム管理者が制御します。
詳細については、ブログ投稿「Visual Studio のパフォーマンス向上のための Dev Drive と Dev Box」を参照してください。
WSL 経由で実行されている Linux ディストリビューションから、Windows ファイル システムで実行される Dev Drive プロジェクト ファイルにアクセスできます。 ただし、WSL は VHD で実行されます。最適なパフォーマンスを得るには、ファイルは Linux ファイル システムに格納する必要があります。 WSL は Windows ファイル システムの範囲外であるため、WSL 経由で実行されている Linux ディストリビューションから Dev Drive のプロジェクト ファイルにアクセスするときにパフォーマンスが向上することはありません。
Windows ドライバーのドキュメント「MSFT_Volume class
」を参照してください。
Live Unit Testing を構成して使用する方法のガイダンスは、Visual Studio のドキュメントにあります。 ただし、ProjFS には依存関係があることに注意してください。 Live Unit Testing ワークスペースのルートを開発ドライブに移動し、許可されたフィルター リストに Windows Projected File System を追加する必要があります。 これを行うには、PowerShell で次のコマンドを使用します:
fsutil devdrv setfiltersallowed PrjFlt
はい。開発ドライブの VHD は、ホスティング ボリュームの BitLocker 暗号化に含まれます。 取り付けた VHD で BitLocker を有効にする必要はありません。
はい、Dev Drive を使用すると、効率を高め、Java 開発プロジェクトで作業するときのビルド時間を短縮できます。 ブログ記事「Dev Drive を使用して Windows での Java 開発を高速化する」を参照してください。
Dev Drive パフォーマンス モードは、特に Defender のリアルタイム保護に関連する Microsoft Defender ウイルス対策機能です。 Dev Drive で代替のウイルス対策プログラムを使用する場合は、パフォーマンス モードは適用されませんが、セキュリティ フィルタの許可リストを調整できます。これには、開発作業のパフォーマンスとセキュリティ間で適切なバランスを見つけるための Dev Drive が接続されています。 添付フィルター リストに変更を加えるときは、添付フィルターの機能を理解している必要があります。 一般的なシナリオをリルータするの説明を含むリストを検索します。
Dev Drive が取り付けられているが、その場所を忘れた場合は、次のメソッドを使用して見つけることができます。
Dev Home の Windows カスタマイズ機能で Dev Drive Insights を使用します。
DiskPart と「list vdisk」コマンドを使用して vhdx への完全なパスを表示します。1) コマンド ラインを開き、diskpart
と入力します。2) DiskPart が開いたら、list vdisk
と入力します。
Powershell と「Get-Disk | Select-Object FriendlyName,Location」を使用し、PowerShell を開いて、Get-Disk | Select-Object FriendlyName,Location
と入力します。
このドキュメントに問題がある場合、または追加の FAQ 案を投稿したい場合は、GitHub の Windows 開発ドキュメント オープンソース リポジトリにアクセスしてください。
Windows developer に関するフィードバック
Windows developer はオープンソース プロジェクトです。 フィードバックを提供するにはリンクを選択します。
トレーニング
認定資格
Microsoft Certified: Azure Virtual Desktop Specialty - Certifications
Microsoft Azure で任意のデバイスの仮想デスクトップ エクスペリエンスとリモート アプリを計画、配信、管理、監視します。