WSL2でClaude CodeとPlaywright MCPを連携する秘訣 - ネットワーク接続問題を完全解決

建設業界の経営者が、コーディングスキルなしでClaude CodeとPlaywright MCPを使ったブラウザ自動化に成功しました。この事例は、生成AIが「プログラマーのツール」から「誰もが使える実務ツール」へと進化している証拠です。

特に注目すべきは、技術的な壁に直面しながらも、それを乗り越えた実践的な解決策です。WSL2環境でのネットワーク接続問題は、多くの開発者が遭遇する典型的な課題ですが、その解決法は意外にもシンプルでした。

問題の核心: ECONNREFUSED エラー

WSL2環境でClaude CodeとPlaywright MCPを組み合わせてブラウザ操作を自動化する際、最大の障壁となるのがネットワーク接続です。具体的には、WSL2からWindowsホスト上で動作するChrome（Chrome DevTools Protocol、ポート9222）への接続時に発生する`ECONNREFUSED`エラーです。

このエラーは単なる設定ミスではなく、WSL2のネットワークアーキテクチャに起因する構造的な問題です。WSL2は仮想化技術を使用しており、WindowsホストとWSL2インスタンスは異なるネットワーク空間に存在します。

実践的な解決策: WSLg + Linux版Chrome

投稿者が見出した解決策は、WSLg（WSL Graphics）環境内でLinux版のChromeを起動することです。この方法には以下の技術的メリットがあります:

WSLgはWindows 11やWindows 10の最新ビルドに標準搭載されており、GUIアプリケーションをWSL2上で直接実行できる機能です。この環境でChromeを動かすことで、ネットワークの複雑性を大幅に軽減できます。

従来手法との比較分析

**Selenium WebDriverとの違い**

従来のSelenium WebDriverベースの自動化と比較すると、Claude Code + Playwright MCPのアプローチには明確な差異があります:

**GitHub Copilotなど他のAIコーディングツールとの位置づけ**

GitHub CopilotやCursorといったAIコーディングツールは「コードを書く支援」に特化していますが、Claude Codeは「タスクの自動実行」により焦点を当てています。コードそのものを理解できない非エンジニアにとって、この違いは決定的です。

メリットと注意点の両面分析

**明確なメリット**

1. **技術障壁の大幅な低下**: プログラミング知識がなくても自動化を実現可能

2. **即座のフィードバック**: ブラウザの動作を目視確認しながら調整できる

3. **実務タスクへの即適用**: 定型的なWeb操作を自動化し、生産性を向上

**見過ごせない注意点**

1. **環境依存性**: WSL2、WSLg、Chrome DevTools Protocolという複数レイヤーの技術スタックへの依存

2. **エラーハンドリング**: 接続エラーが発生した際のトラブルシューティングには一定の技術理解が必要

3. **セキュリティ考慮**: デバッグポートの管理を誤ると、意図しないアクセスを許可する可能性

4. **実行速度**: GUI表示を伴うため、ヘッドレスモードより処理速度は遅い

適用範囲の考察

**最適な利用シーン**

**避けるべきケース**

アクション1: WSLg環境の確認と準備

# WSLのバージョン確認
wsl --version

# WSLgが利用可能か確認（GUI表示テスト）
wsl -d Ubuntu xcalc

このコマンドで計算機アプリが表示されれば、WSLg環境は正常です。表示されない場合は、Windows Updateで最新版に更新してください。

アクション2: Linux版ChromeのCDPモードでの起動

# Linux版Chromeのインストール（Ubuntu/Debian）
wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo apt install ./google-chrome-stable_current_amd64.deb

# デバッグポート有効化で起動
google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-debug

この状態で`localhost:9222`にアクセスできることを確認します。成功すれば、WSL2内からPlaywright MCPでの接続が可能になります。

アクション3: 接続テストとトラブルシューティング

# ポート9222が待ち受け状態か確認
netstat -tuln | grep 9222

# curlでDevTools Protocolのエンドポイントを確認
curl http://localhost:9222/json/version

正常であれば、Chromeのバージョン情報がJSON形式で返ってきます。この段階で接続エラーが出る場合は、Chromeの起動オプションやファイアウォール設定を見直しましょう。

この事例は、生成AIが専門的な技術を「誰でも使えるツール」に変えつつある現状を象徴しています。WSL2とCDP接続という技術的課題は依然として存在しますが、WSLg + Linux版Chromeという実践的な解決策により、非エンジニアでもブラウザ自動化の恩恵を受けられるようになりました。

重要なのは、完璧な技術理解ではなく、「どこでつまずくか」「どう回避するか」という実践知です。今回の投稿者のように、試行錯誤の過程を共有することで、コミュニティ全体の技術レベルが底上げされていきます。

この情報は @takayoshi さんの投稿を参考にしています。