WindowsにnpmインストールしたPiが「fdのダウンロード失敗」になる原因と確実な解決策

WindowsへnpmでPi（coding agent）を入れて初回起動したら、「fd not found. Downloading...」の後に失敗して止まる。そんなトラブルは、環境が壊れているわけではなく“初回セットアップ時の解凍コマンド前提”がWindowsと噛み合っていないのが主因です。この記事では、エラーの意味、根本原因、すぐ直す手順、再発させない運用、そしてチームや業務PCでも通る対策まで一気に整理します。

• WindowsにnpmインストールしたPiが「fdのダウンロード失敗」になる原因と確実な解決策
  • 起きている現象：初回起動でfd取得に失敗する
  • 原因：Windows標準にない解凍コマンド前提で処理している
  • まず直す：最短で動かすワークアラウンド（Git Bashで初回起動）
    • 手順
  • ついでに押さえる：rgでも起きうる（既に入っていると気づきにくい）
  • 再現テストや復旧に使える：わざと未配置にして挙動を見る
  • 根治に近づける：Windowsで「展開手段」を用意する選択肢
  • チーム運用の落とし穴：初回セットアップを誰がどう踏むか
  • まとめ：エラーの正体は「Windowsの解凍コマンド前提」だった

起きている現象：初回起動でfd取得に失敗する

WindowsでnpmからPiを入れて、PowerShell（Windows Terminal）で pi を初めて実行すると、次の流れで止まることがあります。

• fd not found. Downloading...

• 直後に「Failed to download fd」「Binary not found in archive」などが出て起動できない

これは「fd（高速なファイル検索ツール）」が見つからないため、Piが自動でダウンロード＆展開して配置しようとしたが、展開に失敗して最終的に fd.exe を所定の場所に置けなかった、という状態です。

原因：Windows標準にない解凍コマンド前提で処理している

ポイントは「ダウンロードそのもの」ではなく「アーカイブの展開」です。初回起動時、Piは内部でツール（fdやrgなど）を自動取得し、.zip や .tar.gz を展開して実行ファイルを取り出します。

ところが、その展開処理が tar や unzip コマンドをシェルから叩ける前提になっている場合、Windows環境では失敗しやすくなります。Windowsは状況によって tar や unzip が標準で使えない（またはPATHにない）ことがあり、結果として展開が中途半端になり、「アーカイブ内にfd.exeが見つからない」という形のエラーに化けます。

つまり、エラーメッセージは「fd.exeがアーカイブに無い」と言っていますが、実際は 展開が成立していない／正しい展開手段が用意されていない可能性が高い、ということです。

まず直す：最短で動かすワークアラウンド（Git Bashで初回起動）

最も手堅い回避策は、Git Bashから一度だけPiを起動して初回セットアップを完了させる方法です。

手順

1. Windows Terminalを開く

2. プロファイルで Git Bash を起動（Git for Windowsが必要）

3. Git Bash上で pi を実行

4. fdの取得・展開が完了したら、以降はPowerShellで pi を実行してもエラーが出なくなる

理由はシンプルで、Git Bash環境には多くの場合 tar や unzip 相当のコマンドが揃っており、展開処理が成功しやすいからです。初回でfdが配置されれば、PowerShellからの起動でも「もうfdはある」状態になり、問題が表面化しません。

ついでに押さえる：rgでも起きうる（既に入っていると気づきにくい）

同様の取得対象に rg（ripgrep）が含まれるケースがあります。もし既にWindows側でrgをインストールしてPATHが通っていると、Piは「足りない」と判断せず、トラブルがfdだけに見えることがあります。

逆に言うと、PCを新しくした直後など“何も入っていない”環境ほど再現しやすいタイプの不具合です。

再現テストや復旧に使える：わざと未配置にして挙動を見る

「直ったか確認したい」「チーム向けに手順化したい」場合は、fd/rgの実体を一時的に退避して再現できます。たとえばユーザーディレクトリ配下のPi関連フォルダにある fd.exe や rg.exe をリネームしてから起動すると、Piは再び自動取得を試みます。

この方法は、復旧検証に便利な一方で、業務PCでは不用意に触ると混乱しやすいので、検証目的のときだけに絞るのがおすすめです。

根治に近づける：Windowsで「展開手段」を用意する選択肢

ワークアラウンドが最短ですが、毎回Git Bashを起動したくない場合は、Windows側で展開手段を恒常的に用意するのが効果的です。方向性は次のいずれかです。

• Git for Windowsを入れて、以後も必要ならGit Bashで初回だけ動かす

• tar/unzip相当が利用できる環境（例：MSYS2、WSLなど）を整える

• 企業端末なら、標準ツールとして展開コマンドを配布・PATH設定しておく

ただし、Windowsには環境差（標準tarの有無、PowerShellの挙動、実行権限、セキュリティ製品の干渉など）があるため、「このやり方なら100%」を狙うなら “Git Bashで初回起動”を手順として固定するのが現場では一番事故が少ないです。

チーム運用の落とし穴：初回セットアップを誰がどう踏むか

複数人でPiを導入すると、同じWindowsでも人によって再現したりしなかったりします。よくある差分は次の通りです。

• 既にrgやfdを別経路で入れていた（PATHが通っている）

• Git for Windowsが入っていて、たまたま展開コマンドが使えた

• セキュリティ設定でダウンロード後の実行ファイル配置がブロックされた

• 管理者権限の有無や、ホームディレクトリ配下の書き込み制限

おすすめは、導入手順に次の1行を入れることです。
「Windowsは初回だけGit Bashで pi を起動し、ツール取得を完了させる」
これだけで、個人差による“沼り”が激減します。

まとめ：エラーの正体は「Windowsの解凍コマンド前提」だった

• エラーはfdのダウンロードというより 展開処理の前提がWindowsと合っていないことが多い

• 最短の解決策は Git Bashで一度だけ起動して初回セットアップを完了させること

• rgも同様に影響しうるが、既に入っていると表面化しない

• チーム導入では「初回だけGit Bash」を手順化すると失敗しにくい

この手順でまず確実に動かし、その後に必要なら環境整備（WSLや展開手段の統一）へ進めるのが、最もコストが低く、再現性も高い進め方です。