コーディングエージェントをChromeに接続する

推奨セットアップ： LaunchRepoで最良の結果を得るには、ClaudeやCodexのデスクトップアプリではなく、ターミナルでClaude Code CLIまたはCodex CLIを使うことを強くおすすめします。これは推奨するワークフローであり、異なる権限や中断のない実行を保証するものではありません。

Chromeのリモートデバッグを経由したChrome DevTools MCPを使います。必要なのは、最新のNode.js LTSリリース、npm、Google Chromeです。記録を保存するのはローカルダッシュボードで、Chromeを操作するのはエージェントです。まずはワーカー1つで始め、ランの間はMCP接続を開いたままにしてください。ブラウザ拡張機能を経由する接続方式や、ほかのブラウザ操作用インテグレーションは使わないでください。

構成を選ぶ

• Chrome 144以降： 自動接続はWindows、macOS、Linuxで使えます。
• macOS： ターミナルの権限を確認してください。
• 自動接続が使えない、または別のワーカーが必要な場合： macOS、Windows、Linux用の専用プロファイルを使います。
• 申請の前に： 接続テストを実施します。

node --version、npm --version、chrome://versionを確認してください。Windowsでは、Windowsネイティブ版のNode/npmとChromeを使います。WSLを使う場合は、別途接続の設定が必要です。

既存のChromeに接続する

1. Chrome 144以降でchrome://inspect/#remote-debuggingを開き、リモートデバッグを有効にします。この設定項目が見当たらない場合は、利用が許可されている範囲で、下記の専用プロファイルを使ってください。
2. エージェントのMCP設定にChrome DevTools MCPを登録します。次の汎用的なJSONの例はmacOS/Linux向けです。エージェントによっては、設定形式が異なる場合があります。

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--autoConnect", "--no-usage-statistics", "--no-performance-crux"]
    }
  }
}

Windowsでは、"command": "cmd"と次の引数を使います。

["/c", "npx", "-y", "chrome-devtools-mcp@latest", "--autoConnect", "--no-usage-statistics", "--no-performance-crux"]

3. 害のないブラウザ操作を1つ実行させ、意図したウィンドウに表示されるChromeの接続確認を承認します。その後、下記のテストを実施してください。

初回の呼び出し時にパッケージがダウンロードされます。セットアップが済んだら、テスト済みのバージョンに固定してください。公式の設定ドキュメントとクライアント別の設定も参照してください。

専用プロファイル：OSを選ぶ

共有フォルダや同期フォルダの外にある、プライベートワークスペースから実行してください。プロファイルにはログイン情報が含まれるため、Gitの管理対象から除外しておきます。必要なアカウントへのログインは、あなた自身で行ってください。Chrome 136以降では、これらのデバッグ用フラグを使うにはデフォルト以外のプロファイルが必要です。

macOS

mkdir -p .browser/chrome
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
  --remote-debugging-address=127.0.0.1 \
  --remote-debugging-port=9222 \
  --user-data-dir="$PWD/.browser/chrome" about:blank

Windows PowerShell

$launchrepoChrome = @(
  "$env:ProgramFiles\Google\Chrome\Application\chrome.exe",
  "${env:ProgramFiles(x86)}\Google\Chrome\Application\chrome.exe",
  "$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe"
) | Where-Object { Test-Path $_ } | Select-Object -First 1
if (-not $launchrepoChrome) { throw 'Locate Google Chrome first' }
New-Item -ItemType Directory -Force '.browser/chrome' | Out-Null
$launchrepoProfile = (Resolve-Path '.browser/chrome').Path
Start-Process -FilePath $launchrepoChrome -ArgumentList "--remote-debugging-address=127.0.0.1 --remote-debugging-port=9222 --user-data-dir=`"$launchrepoProfile`" about:blank"

Linux

launchrepo_chrome=$(command -v google-chrome || command -v google-chrome-stable)
if [ -z "$launchrepo_chrome" ]; then
  echo "Install or locate Google Chrome first."
else
  mkdir -p .browser/chrome
  "$launchrepo_chrome" \
    --remote-debugging-address=127.0.0.1 \
    --remote-debugging-port=9222 \
    --user-data-dir="$PWD/.browser/chrome" about:blank
fi

Chromeを起動したターミナルは開いたままにしてください。MCPの引数にある--autoConnectを--browserUrl=http://127.0.0.1:9222に置き換えます。この2つは決して併用しないでください。ポートはローカルに限定し、トンネルで外部に公開することは絶対に避けてください。待ち受け状態は、macOSではlsof -nP -iTCP:9222 -sTCP:LISTEN、Linuxではss -ltnp 'sport = :9222'、WindowsではGet-NetTCPConnection -State Listen -LocalPort 9222 | Select-Object LocalAddress, OwningProcessで確認できます。許容されるのはループバックアドレスだけです。別のプログラムがポートを使っている場合は、空いているポートを選び、両方の設定を更新してください。無関係なブラウザを強制終了したり、使用中のプロファイルのロックファイルを削除したりしないでください。

macOSの権限

MCPを起動しているアプリ（Terminal、iTerm、またはエディタやエージェントのアプリ）を確認します。macOSが保護されたChromeのファイルへのアクセスを拒否する場合：

1. システム設定 → プライバシーとセキュリティ → フルディスクアクセスを開きます。
2. 実際にMCPを起動しているホストアプリを + ボタンで追加し、認証してから有効にします。
3. アプリを完全に終了してから開き直し、再接続してテストをやり直します。

これは権限の確認であり、CDPに共通する必須要件ではありません。接続が機能しているなら、必要以上に広いアクセス権を与えないでください。CDPのみの接続であれば、通常はアクセシビリティ、オートメーション、画面収録の権限は必要ありません。Chromeの接続承認はこれとは別のもので、再起動後に改めて求められることがあります。

接続をテストする

エージェントに、新しいタブでhttps://example.comを開き、ページのタイトルとメインの見出しを読み取り、そのタブを特定するよう依頼します。そのウィンドウを自分の目で見ていてください。MCPのプロセスが動いているだけでは、何の証明にもなりません。次に、対象のディレクトリにログインし、実際にログインしている先のアカウントを確認します。OAuthが成功しただけでは、ログインできたことの証明にはなりません。メールボックスも、取り決めた権限の範囲内で確認します。

続けて、同じタブでエージェントにnavigator.webdriverを評価させてください。値はfalseでなければなりません。trueの場合、MCP設定に--autoConnect（専用プロファイルなら--browserUrl）が欠けており、Chrome DevTools MCPが独自の自動化用Chromeを起動しています。この状態ではCloudflare Turnstileなどのボット検査が「確認中」のまま止まり、解けるチャレンジが表示されません。設定を直し、エージェントのセッションを再起動してからテストをやり直してください。ステルス用のフラグやスクリプトでこの値を隠さないでください。

onboarding.jsonやSESSION.mdに保存するのは、合否と機密性のないメモだけにしてください。Cookie、認証リンク、ブラウザ操作の記録はコピーしないでください。CAPTCHAと二要素認証はあなた自身で完了させます。送信（Submit）がタイムアウトした場合は、再試行する前にプラットフォーム側の状態を確認してください。意図しないウィンドウが動いたら、作業を止めて接続を確認します。このテストを行わない限り、ここに書いた手順があなたのOSとエージェントの組み合わせで動作することは保証できません。

2つのワーカーとウィンドウの後片付け

ランプランナーは、申請10件、ワーカー最大2つから始めます。各ワーカーには、それぞれ別の担当プラットフォーム、Chromeプロファイル、ポート、MCP接続が必要です。たとえば、.browser/worker-1はポート9222、.browser/worker-2はポート9223を使います。それぞれ個別にテストしてください。ホストがワーカーごとに別々の接続を割り当てられない場合は、ワーカーは1つにします。

申請ごとに専用のウィンドウを用意します。申請の確認が取れたら証跡と結果を保存し、そのウィンドウと、その申請のために開いたログイン用・認証用のタブだけを閉じます。個人用のウィンドウ、共有の受信トレイ、ダッシュボード、未保存のフォーム、人への引き継ぎ中の画面は開いたままにしてください。MCPでウィンドウを閉じられない場合は、その申請のタブを閉じ、オーナーが行う必要のある残りの後片付けを記録します。プロファイルは削除せずに残しておきます。最後のウィンドウを閉じたことでMCPの接続が切れた場合は、再接続してください。次のステップはオンボーディングガイドで説明しています。