pnpmのGlobal Virtual StoreでWindowsのENOENTエラーが発生する原因と対処法：重複パス問題を整理する

pnpmのGlobal Virtual StoreでWindowsのENOENTエラーが発生する原因と対処法：重複パス問題を整理する

pnpmでグローバルパッケージをインストールする際、Windows環境において「ENOENT: no such file or directory, mkdir」というエラーが発生し、処理が停止するケースが報告されています。特にenable-global-virtual-storeを有効化している場合、pnpmが内部で作成しようとするパスに絶対パスが重複して入り込み、存在しないディレクトリを参照してしまうことが問題の中心です。この記事では、Windows 11、OneDrive配下、アクセント文字を含むフォルダ名、pnpm v11系という条件が絡むこの不具合について、原因の見立てと実用的な回避策をわかりやすく整理します。

pnpmのグローバルインストールで起きたENOENTエラーとは

pnpmでpnpm add -gを実行したとき、通常であれば指定したパッケージはグローバル領域にインストールされ、コマンドラインから利用できる状態になります。しかし、特定のWindows環境では、グローバルインストール中にディレクトリ作成へ失敗し、ENOENTエラーで処理が止まることがあります。

今回の問題で重要なのは、単に「フォルダが存在しない」という一般的なエラーではなく、pnpmが作成しようとしているパスそのものが不正な形になっている点です。エラーメッセージには、C:\Users\...から始まる絶対パスが、さらに同じ絶対パスの下に連結されているような形で表示されます。

本来、Windowsの絶対パスはドライブレターから始まる単独のパスとして扱われるべきです。ところが、内部処理のどこかで絶対パスを相対パスのように結合してしまうと、C:\...\C:\...のような不自然な文字列が生まれます。この状態でmkdirを実行しても、OSは正しいディレクトリ構造として解釈できず、結果としてENOENTが発生します。

発生条件の中心はGlobal Virtual Storeの有効化

今回の不具合で特に注目されるのが、enable-global-virtual-storeという設定です。これはpnpmのグローバル領域でも仮想ストアの仕組みを利用するための設定であり、pnpmらしい効率的な依存関係管理をグローバルインストールにも適用する狙いがあります。

pnpmはもともと、パッケージを単純にコピーして展開するのではなく、コンテンツアドレス可能なストアやシンボリックリンクを活用して、重複を避けながら高速に依存関係を構築するパッケージマネージャーです。この設計は非常に強力ですが、パス解決やリンク作成の処理が複雑になりやすいという側面もあります。

ローカルプロジェクトでは正常に機能していた仕組みでも、グローバルインストール、Windowsのパス仕様、OneDrive配下の特殊なフォルダ名、さらに新しいv11系の実装が重なることで、想定外のパス結合が発生した可能性があります。

今回のエラーでは、グローバル仮想ストアが有効な状態でグローバルパッケージを追加しようとした際、pnpmがシンボリックリンクや関連ディレクトリを作成する過程で、同一の絶対パスを二重に含むディレクトリへアクセスしようとしています。

項目	内容
発生環境	Windows 11
pnpmバージョン	v11.0.1
関連設定	enable-global-virtual-store true
実行コマンド	pnpm add -g opencode-ai
主な症状	ENOENTによるグローバルインストール失敗
推定原因	絶対パスの重複結合による不正なmkdir対象
回避策の方向性	Global Virtual Storeを無効化する、パス環境を単純化する、pnpm更新を待つ

 

エラーメッセージから読み取れる問題の本質

ENOENTは、Node.jsやnpm系ツールを使っていると比較的よく見かけるエラーです。意味としては「指定されたファイルまたはディレクトリが存在しない」というものですが、原因は一つではありません。実際に必要なファイルが欠けている場合もあれば、権限やパス解決の不備によって存在しない場所を見に行っている場合もあります。

今回のケースでは、後者の可能性が高いといえます。なぜなら、エラー内に表示されるパスが明らかに不自然だからです。

たとえば、pnpmのグローバル領域がC:\Users\ユーザー名\AppData\Local\pnpm\global\v11\...である場合、その配下にnode_modules\.pnpmなどが作成されること自体は自然です。しかし、そこへ再びC:\Users\ユーザー名\AppData\Local\pnpm\global\v11\...という絶対パスが文字列として連結されている場合、それは正しいディレクトリ構造ではありません。

Windowsでは、パス区切りにバックスラッシュを使い、ドライブレターを含む絶対パスを扱います。この形式はUnix系OSのパスとは大きく異なります。そのため、クロスプラットフォーム対応のツールでは、パスの正規化、絶対パス判定、シンボリックリンク先の解決を慎重に行う必要があります。ここでわずかな処理漏れがあると、Windowsだけで再現する不具合が生まれます。

OneDrive配下とアクセント文字を含むフォルダ名の影響

今回の環境では、プロジェクトがOneDrive配下にあり、さらにÁrea de Trabalhoのようにアクセント文字を含むフォルダ名が使われていました。これはポルトガル語環境などでデスクトップに相当する場所として自然に現れるパスです。

この条件が直接の原因と断定できるわけではありません。しかし、WindowsにおけるOneDrive配下のフォルダは、通常のローカルディレクトリよりも挙動が複雑になることがあります。同期状態、仮想化されたファイル、パスの表示名、実体パス、権限、文字コードなどが絡むため、開発ツールのパス処理に影響を与えることがあります。

さらに、アクセント付き文字を含むパスは、現代のツールであれば基本的に問題なく扱えるべきものです。ただし、パッケージマネージャーの内部でパスを文字列として加工する場面が多い場合、エンコードや正規化の差によって不具合が表面化することがあります。

特に今回のように、グローバルインストール先そのものはAppData\Local\pnpmであっても、コマンドを実行したカレントディレクトリやプロジェクトの位置が内部処理に影響する可能性は残ります。グローバルインストールだからプロジェクトの場所は無関係、と単純には言い切れません。

なぜグローバルインストールでだけ目立つのか

pnpmはローカルプロジェクトの依存関係管理で広く使われています。一方で、pnpm add -gによるグローバルインストールは、通常のプロジェクトインストールとは異なるパスやリンク構造を使用します。

ローカルインストールでは、プロジェクト配下のnode_modulesとpnpmストアの関係が中心です。対してグローバルインストールでは、ユーザーのグローバル領域、実行可能ファイルの配置先、OSごとのPATH設定、シンボリックリンク、仮想ストアが絡みます。

つまり、グローバルインストールは見た目こそ単純なコマンドですが、内部では複数のパスをまたいで処理が行われています。Windowsではシンボリックリンクやジャンクションの扱いにも独自性があり、管理者権限や開発者モードの状態によっても挙動が変わることがあります。

そのため、新機能やv11系の変更点がグローバル仮想ストア周辺に入っている場合、ローカルでは問題が出ず、グローバルインストール時だけ失敗するという状況は十分に起こり得ます。

すぐ試せる回避策はGlobal Virtual Storeの無効化

実務上、最も現実的な回避策はenable-global-virtual-storeを無効にすることです。問題の発生条件がこの設定に強く結びついているため、グローバル仮想ストアを使わない従来の挙動へ戻すことで、インストールが成功する可能性があります。

操作手順は次の通りです。

1. ターミナルまたはPowerShellを開く

2. pnpm config set enable-global-virtual-store false --globalを実行する

3. 必要に応じて失敗したグローバルパッケージを再インストールする

4. pnpm add -g パッケージ名を再実行する

5. コマンドが利用できるか確認する

この方法は根本修正ではありませんが、ツールを今すぐ使いたい場合には有効です。特にopencode-aiのようにCLIとして利用したいパッケージをインストールする場面では、pnpm本体の修正を待つよりも、設定を戻して作業を継続するほうが実用的です。

パス環境を単純化することも有効

enable-global-virtual-storeを無効化しても問題が残る場合、作業ディレクトリやユーザー環境のパスを単純化することも検討すべきです。OneDrive配下やアクセント文字を含むフォルダで作業している場合、別の短いパスにプロジェクトを移して同じコマンドを実行すると、問題の切り分けがしやすくなります。

たとえば、C:\dev\projectのような短くASCII文字だけで構成された場所を使うと、パス処理に起因する不具合を避けやすくなります。これはpnpmに限らず、Node.js、Python、Rust、Goなどの開発環境でもよく使われる実践的な対策です。

もちろん、現代の開発ツールは多言語環境やクラウド同期フォルダに対応すべきです。しかし、実際のトラブルシューティングでは、まず条件を単純化して再現性を確認することが重要です。問題がC:\devでは起きず、OneDrive配下では起きる場合、ツール側のパス処理だけでなく、同期フォルダ特有の要素も調査対象になります。

pnpm v11系を使う場合の注意点

pnpm v11系は新しいメジャーバージョンであり、内部挙動や実験的な設定の扱いに変化が入っている可能性があります。メジャーバージョン直後は、通常利用では問題がなくても、特定のOS、特定の設定、特定のパス条件で不具合が見つかることがあります。

今回のようなグローバル仮想ストア関連の問題は、pnpmの性能や設計思想そのものを否定するものではありません。むしろ、pnpmが高度なリンク構造を使って効率化しているからこそ、パス処理のわずかな不整合が目立ちやすいという話です。

安定性を重視する環境では、v11系の最新機能をすぐに有効化するのではなく、必要な機能だけを使い、問題が出た場合に設定を戻せるようにしておくことが重要です。特にCI環境やチーム開発では、個人環境で問題なく動く設定が、別のメンバーのWindows環境で失敗する可能性があります。

グローバルインストールに依存しすぎない選択肢

近年のJavaScript開発では、グローバルインストールを避け、プロジェクト単位でツールを管理する流れも強くなっています。pnpmであれば、プロジェクトのdevDependenciesにCLIツールを追加し、pnpm execやスクリプト経由で実行する方法があります。

この運用では、ツールのバージョンをプロジェクトごとに固定できるため、環境差によるトラブルを減らせます。また、チーム内で同じバージョンのツールを使いやすくなり、グローバル領域の破損やPATH設定の問題にも影響されにくくなります。

ただし、今回のように特定のCLIを日常的に使う場合や、プロジェクトに依存しないユーティリティとして使いたい場合、グローバルインストールは依然として便利です。そのため、グローバルインストールを完全に避けるというより、トラブル発生時にローカル利用へ切り替える選択肢を持っておくのが現実的です。

Windowsユーザーが確認すべきポイント

Windowsでpnpmのグローバルインストールが失敗した場合、まずはエラーメッセージ内のパスをよく見ることが重要です。単にENOENTと表示されているだけで判断せず、どのディレクトリを作成しようとしているのか、同じパスが重複していないか、ドライブレターが途中に紛れ込んでいないかを確認します。

もしC:\...\C:\...のような形になっているなら、必要なフォルダを手作業で作れば解決する種類の問題ではありません。むしろ、手動でディレクトリを増やすことで環境がさらに分かりにくくなる可能性があります。

この場合は、pnpmの設定を確認し、enable-global-virtual-storeを無効化したうえで再実行するのが妥当です。また、pnpmのグローバルディレクトリやストアの場所を確認し、過去の失敗したインストール痕跡が残っている場合は、慎重に整理することも検討できます。

問題の本質は「存在しないフォルダ」ではなく「作ろうとしている場所の誤り」

今回のエラーを理解するうえで大切なのは、ENOENTを文字通りに受け取りすぎないことです。表示上は「そのようなファイルやディレクトリはない」という意味ですが、根本原因は「本来作るべきではない場所を作ろうとしている」ことにあります。

つまり、解決策は不足しているフォルダを探すことではなく、pnpmが不正なパスを組み立てないようにすることです。そのためには、問題を引き起こしている可能性が高い設定を無効化し、より単純なパス環境で再現確認し、必要に応じてpnpmの修正版へ更新する流れが有効です。

開発環境のエラーは、メッセージだけを見ると複雑に感じられます。しかし、今回のケースでは「絶対パスが重複している」という観点で見ると、問題の輪郭はかなり明確になります。

まとめ：pnpmのENOENTはGlobal Virtual Store設定を疑うべき

pnpm v11系のWindows環境でグローバルパッケージのインストールに失敗し、ENOENTとともに重複した絶対パスが表示される場合、enable-global-virtual-storeが大きな手がかりになります。特に、OneDrive配下やアクセント文字を含むフォルダで作業している場合は、パス処理に関連する不具合が表面化しやすい条件がそろっています。

最初に試すべき対応は、グローバル仮想ストアを無効化して再インストールすることです。それでも改善しない場合は、作業場所を短いASCIIパスへ移し、pnpmのバージョンやグローバルディレクトリの状態を確認します。

pnpmは高速で効率的なパッケージマネージャーですが、その強みであるリンク構造や仮想ストアは、OSごとのパス仕様に敏感です。Windowsで突然グローバルインストールが失敗したときは、単なるフォルダ不足ではなく、内部で生成されたパスが正しいかどうかを見ることが、解決への近道になります。