Windows 11で「Daemon failed to start（socket creation error）」が出る原因と回避策：agent-browserを動かす実践手順

Windows 11で agent-browser を使おうとすると、起動直後に「Daemon failed to start（socket creation error）」や「.sock が作れない／つながらない」といったエラーで止まることがあります。結論から言うと、これは“ブラウザ操作そのもの”より前段の デーモン起動とIPC（プロセス間通信）の方式がWindowsと噛み合っていないことが主因になりやすいタイプの不具合です。
この記事では、いま起きている現象を最短で切り分け、Windows 11環境でも作業を前に進めるための現実的な回避策を、優先順位つきでまとめます。

Windows 11で「Daemon failed to start（socket creation error）」が出る原因と回避策：agent-browserを動かす実践手順

まず症状を整理：このエラーは何が起きている？

agent-browser は内部でデーモン（常駐プロセス）を立ち上げ、CLI（Rust製のネイティブバイナリ）からデーモンへ命令を送ってブラウザを操作します。
ここで問題になるのが、デーモンとCLIが通信する“入口”です。

エラーメッセージに …\.agent-browser\default.sock や *.sock が出る
→ Unixドメインソケット（Linux/macOSで一般的）前提のパスをWindowsで扱おうとして失敗している可能性が高い
「socket creation error」
→ ソケットファイル作成・ディレクトリ作成・権限・パス長・ウイルス対策ソフトのブロックなど、作成段階で弾かれているパターンが多い

さらに、Windowsではプロセス起動時の パスのエスケープ（cmd.exe経由） が絡むと、デーモンの起動自体がコケて「起動できない」になります。結果として、ブラウザを開く前に止まります。

最優先の対処：最新版に上げて“前提条件”を揃える

不具合を踏むと切り分けが難しくなるので、まずは環境の前提を整えます。

1) agent-browserを最新版へ

2026年2月にかけて設定機構やエラーハンドリング、IPC周りの改善が継続的に入っています。まずは最新版へ更新し、再現条件を減らしてください。

グローバル導入なら npm install -g agent-browser（環境に合わせてパッケージ名が異なる場合はインストール手順に従う）
その後 agent-browser install --with-deps を実行（Chromiumや依存導入）

2) Node.jsはLTS系で揃える

Windowsで「新しすぎるNode」や特殊なインストール形態（複数バージョン混在）だと、起動・パス解決が壊れやすいです。まずはLTS（v20/v22系）で固定して挙動を確認するのが無難です。

ここが本丸：Windowsで.sockが絡むときの切り分け

エラーに .sock が出る場合、次の3つを上から順に潰すと早いです。

1) “ソケット保存先”を掃除して再試行

古いPID/ソケット/ポート情報が残っていると、再起動時に詰まります。

C:\Users\<あなた>\.agent-browser\ 配下を確認
default.sock やセッション名っぽいファイルが残っていたら退避／削除して再実行

※ まずは安全のためフォルダごとバックアップしてから整理すると安心です。

2) Windows Defender／企業向けEDRを一時的に疑う

ソケットや実行ファイル生成を“怪しい挙動”としてブロックする構成が現場ではよくあります。
とくに AppData 配下やユーザーディレクトリでの生成・実行が厳しい端末だと、作成はできても接続直前に落とされることがあります。

可能なら agent-browser の実行ファイルと ~\.agent-browser\ を許可対象に（社内PCは情報システムのルール優先）
一時的にリアルタイム保護を切って再現確認（許される範囲で）

3) パス長・記号を避ける（地味に効く）

Windowsはパス長や引用符の扱いで事故りがちです。
ユーザー名に記号がある／深いディレクトリで実行している場合、短いパスの作業ディレクトリ（例：C:\work\ab\）へ移動して試すだけで改善することがあります。

動かすことを最優先する回避策：CDPモードで“既存Chromeに接続”

デーモン起動やソケットが不安定なら、発想を変えて 「先にChromeを起動し、agent-browserは接続するだけ」 に寄せると前に進めることがあります。

手順（ローカルChromeに接続）

Chrome（またはChromium）をリモートデバッグ付きで起動
- 例：--remote-debugging-port=9222
agent-browser connect 9222
以降は snapshot や tab などを実行

ポイントは、ブラウザ起動・プロファイル・権限の面倒をChrome側に寄せられることです。
また、ポートが分からない／固定したくない場合は 自動検出（auto-connect） を使う設計も用意されています。

それでもWindowsが厳しいとき：3つの現実解

WindowsでのIPC不具合が解消されるまで、業務を止めないための“現実解”も用意しておくのが得策です。

1) WSL2で動かす（ただし権限に注意）

WSL2でLinuxとして動かすとUnixソケット前提が通りやすい一方、ソケット作成ディレクトリの権限で詰まることがあります。
ホーム配下（Linux側の ~）で実行し、/mnt/c などWindows側マウント領域は避けるのがセオリーです。

2) クラウドブラウザに逃がす（provider利用）

ローカル環境依存を捨てて、クラウド側のブラウザに接続する方式もあります。
ネットワーク条件やキー管理は必要ですが、「Windowsローカルのソケット地獄」からは抜けられます。

3) Playwright等に一時退避して用途を満たす

「今すぐスクショ」「フォーム送信」「巡回」など目的が明確なら、Playwrightの直接利用で要件を満たし、agent-browserは改善待ちにする判断も合理的です。
特にCIや自動化の締切がある場合は、代替手段を先に確保しておくと強いです。

再発防止のチェックリスト（最短で効く順）

作業ディレクトリは短いパスへ（深い階層・日本語・記号を避ける）
~\.agent-browser\ を定期的に整理（古い.sock/ポート情報の残骸を残さない）
Node.jsはLTS固定（複数バージョン混在を避ける）
セキュリティソフトのブロック可能性を常に疑う
うまくいかない日はCDP接続・クラウド・代替自動化へ即スイッチ

まとめ：原因は“あなたの手順ミス”ではなく、Windows×IPCの相性問題が中心

Windows 11での「Daemon failed to start（socket creation error）」は、ほとんどの場合 デーモンとCLIの接続方式（ソケット／起動パス） がWindows環境と衝突して起きます。
大事なのは、正面突破に固執せず「最新版へ」「キャッシュ掃除」「短いパス」「CDP接続」「クラウド退避」という逃げ道を複数持ち、作業を止めないことです。

この手順で切り分ければ、少なくとも「何を試したら状況が変わるか」がはっきりし、無駄な試行錯誤を大幅に減らせます。