Windowsのエクスプローラーは、ファイル操作画面からだけでなく、［ファイル名を指定して実行］、コマンドプロンプト、PowerShell、ショートカットからexplorer.exeを呼び出せます。現在のWindows 11で最も安定して使えるのは、フォルダーの完全パスを渡して開く方法です。/select,で特定項目を選択表示する使い方も広く残っていますが、/n、/e、/root、/separateなど旧来のスイッチは、現行File Explorerの公開された安定契約として一律に保証されているわけではありません。手作業の便利技と、業務アプリからの正式なShell APIを区別して使います。
基本はexplorer.exeにパスを渡す
explorer.exe "%USERPROFILE%\Documents"コマンドプロンプトでこの例を実行すると、現在のユーザーのDocumentsをエクスプローラーで開きます。パスに空白が含まれても一つの引数になるよう、二重引用符で囲みます。既に同じ場所を表示しているウィンドウやタブがある場合、Windowsの設定や版によって既存画面が使われることがあります。「必ず新しいプロセス、新しいウィンドウ、新しいタブになる」と決めつけず、必要な結果が対象フォルダーの表示であることを確認します。
［Windows］キーと［R］キーで［ファイル名を指定して実行］を開き、同じコマンドを入力しても実行できます。PowerShellでは環境変数の書き方が異なるため、explorer.exe "$HOME\Documents"のように指定します。cmd.exe用の%USERPROFILE%とPowerShell用の$HOMEを混ぜないでください。手順書には実行するシェルを明記します。
現在の場所と親フォルダーを開く
explorer.exe .
explorer.exe ..ピリオド一つは現在のフォルダー、二つは親フォルダーを表す相対パスです。開発作業中に現在位置をエクスプローラーで確認する用途には便利ですが、ショートカット、タスクスケジューラ、別プロセスから実行すると基準位置が変わることがあります。自動化ではcdまたはGet-Locationで現在位置を記録し、可能なら検証済みの完全パスを渡します。相対パスがどこを指すか不明な状態でユーザーへ配布しません。
特定のファイルを選択した状態で開く
explorer.exe /select,"%USERPROFILE%\Documents\sample.txt"/select,は、指定したファイルまたはフォルダーを親フォルダー内で選択した状態にするために使われてきた構文です。コンマと対象パスの位置、引用符に注意します。対象が存在しない、アクセスできない、パスが誤っている場合は、期待した選択にならないことがあります。実行前に対象の存在と種類を確認し、結果を「ウィンドウが開いた」だけでなく「目的の項目が選択されている」まで確認します。
複数の項目を同時選択したい、アプリから確実に選択状態を作りたい場合は、文字列コマンドを組み立てるより、Windows ShellのSHOpenFolderAndSelectItemsを使う設計を検討します。このAPIはフォルダーを開いて指定項目を選択する目的が明確です。アプリ実装では戻り値、存在しない項目、権限、UIスレッド、複数選択を適切に処理します。エンドユーザー向けバッチと製品コードでは求められる安定性が違います。
ドライブ、UNC共有、ネットワークの場所を開く
explorer.exe "D:\"
explorer.exe "\\server.example\share"ドライブのルートやUNC共有もパスとして渡せます。ただしネットワーク共有が切断中、DNSでサーバーを解決できない、VPNが未接続、資格情報が期限切れ、アクセス権がない場合は、エクスプローラーが長時間待つことがあります。実行前に社内ネットワークへ接続しているかを確認し、パスワードをコマンド行へ埋め込みません。共有先を開く処理にユーザー入力を使う場合は、許可されたサーバーと共有名に限定します。
「応答しない」ように見えても、到達不能な共有を待っているだけの場合があります。同じコマンドを連打すると複数の待機が発生します。ローカルのDocumentsがすぐ開くかと比較し、ネットワーク側だけ遅いなら共有、VPN、名前解決、資格情報を調べます。組織の共有へアクセスできない場合、ファイアウォールを無効にしたり資格情報を公開したりせず、サーバー名、時刻、接続経路、表示メッセージを管理者へ伝えます。
WSLのLinuxファイルを開く
Windows Subsystem for Linuxを利用している場合、File Explorerのアドレスバーに\wsl$を入力するか、Linux側のシェルからexplorer.exe .を使って現在のLinuxディレクトリを開く方法が公式に案内されています。ディストリビューション名を含むネットワーク形式のパスは、WSLが起動し対象ディストリビューションを利用できることが前提です。LinuxファイルをWindowsアプリから直接編集する場合は、WSLの公式ファイルシステム経路を使い、ディストリビューションの内部データ領域をWindows側から直接変更しません。
explorer.exe .このコマンドをWSLのシェル内で実行すると、WSLが現在位置に対応するWindows向けパスを解決します。同じ文字列をWindowsのコマンドプロンプトで実行すれば、Windows側の現在位置を開くため意味が変わります。実行場所を手順に明記してください。大容量ファイルや多数の小さいファイルをネットワーク形式の経路越しに扱うと性能が異なるため、開けることと高速であることを分けて評価します。
特殊フォルダーとShell名前空間
File Explorerは通常のファイルパスだけでなく、PC、ネットワーク、ごみ箱などShell名前空間の項目も扱います。古い記事ではGUIDを含むshell:::形式や各種shell:名が多数紹介されていますが、公開範囲、利用者のWindows版、ポリシー、ローカライズによって動作が異なるものがあります。個人の一時操作で使う場合も、現行端末で確認したものに限定し、業務自動化の永続的な契約として大量に埋め込みません。
アプリからDocumentsなど既知フォルダーを開く場合、表示名を文字列連結するのではなく、WindowsのKnown Folder APIやShell APIで場所を解決します。ユーザーのDocumentsがOneDriveや組織のポリシーでリダイレクトされていると、C:\Users\名前\Documentsという固定値が正しくない場合があるからです。対話用の例では環境変数を使い、製品コードでは対応APIを選びます。
旧来の/n、/e、/root、/separateをどう扱うか
古いWindows向け資料には、/nで新しいウィンドウ、/eでツリー表示、/rootで表示範囲を限定、/separateで別プロセス、と説明した例があります。しかしWindows 11のFile Explorerはタブ、Home、新しいナビゲーションを備え、古い画面構成を前提にした結果と一致しないことがあります。現行の公式サポートで保証されるFile Explorer操作と、互換性のため残っている可能性がある旧構文を混同しないでください。
特に/rootは、Windows Shellの「ルート付きビュー」を作る古いショートカット技法と関係します。Microsoft Learnにはショートカットファイルでルート付きビューを開く資料がありますが、すべての環境で一般ユーザー向けの標準オプションとして推奨されているわけではありません。旧システムを保守するために使うなら、対象Windowsビルド、実行結果、置き換え方法をテストし、将来のFile Explorer更新で挙動が変わる前提で管理します。
新しいウィンドウや別プロセスを要求しすぎない
エクスプローラーの［オプション］には、フォルダーウィンドウを別のプロセスで開く設定がある版がありますが、これは障害の分離や安定性に関係する設定で、すべての呼び出しを必ず独立プロセスにする高速化スイッチではありません。タブや既存ウィンドウの再利用もWindows側のUI設計に含まれます。自動処理では「新規ウィンドウが何枚開いたか」ではなく、「利用者が対象を見つけられるか」を要件にします。
ショートカットで使うときの設定
デスクトップのショートカットから特定フォルダーを開くなら、リンク先にexplorer.exe "完全パス"を指定し、作業フォルダーとリンク先を区別します。共有ショートカットでは、個人名を含む固定パスを避け、利用者ごとに解決できる場所か、全員が同じ共有へ権限を持つかを確認します。アイコンや表示名に「経理共有」など目的を書き、同名のローカルフォルダーと区別します。ショートカット配布後も共有移転や権限変更時に更新できる所有者を決めます。
スクリプトでパスを安全に渡す
ユーザー入力をそのままexplorer.exeの引数へ連結しません。完全パスへ正規化し、許可されたルート配下か、対象が存在するか、ファイルかフォルダーかを検証します。引用符を付けるだけでは、意図しないネットワーク先、特殊なShell項目、極端に長いパスを防げません。ログには入力値と解決後パスを分けて残し、ユーザー名や機密共有名を公開ログへ出さないようにします。
Web URLを開く目的でFile Explorerを経由させるのではなく、Windows ShellのShellExecuteなど、既定アプリで対象を開くための正式な仕組みを使います。MicrosoftのShell Launch文書は、ファイル、フォルダー、URIを関連付けられたアプリで開く考え方を示しています。アプリからの起動では戻り値と失敗を処理し、ユーザーが入力したURIのスキームを制限します。単にコマンドが短いという理由でExplorerの未公開挙動へ依存しません。
よくある失敗の切り分け
- 別の場所が開く：相対パスの基準、環境変数、引用符、ショートカットの作業フォルダーを確認します。
- ファイルが選択されない：対象の存在、完全パス、
/select,のコンマと引用符を確認します。 - 共有を開くと固まる：ローカルパスと比較し、VPN、DNS、権限、共有の稼働状態を確認します。
- WSLの場所が開かない：実行したシェル、ディストリビューションの起動状態、公式のWSL経路を確認します。
- 新規ウィンドウにならない：タブと既存ウィンドウ再利用を前提にし、旧来スイッチへ依存しない要件へ見直します。
実務での使い分け
一回だけ特定フォルダーを開くならexplorer.exe "完全パス"、手作業で特定ファイルの場所を示すなら/select,を現行端末で確認して使います。複数項目の選択や製品機能としての起動ならSHOpenFolderAndSelectItems、関連付けられたアプリで対象を開くならShellの正式な起動APIを検討します。旧来オプションは、既存システムの互換性確認には役立っても、新規設計の中心には置きません。
問い合わせ時は、Windowsのエディションとビルド、実行したシェル、完全なコマンドの機密部分を伏せた形、対象がローカル・共有・WSLのどれか、実際に開いた場所、エラー全文を記録します。同じパスをアドレスバーへ直接入力した結果も比較します。この情報があれば、Explorerの呼び出し構文、パス解決、ネットワーク、権限のどこで失敗したかを切り分けられます。
コメント
コメント一覧 （2件）
Windows11の “新しいタブで開く” のオプションを知りたい。
私のw11 PCでエクスプローラーのドキュメントが表示されてなくてー、困っていましたがー、こちら様のサイトに掲載されてあった
cmd＝explorer /n,C:\Usersを使ってみたところー、無事にすんなりと表示されましたー。助かりましたー。ありがとうございましたー。