2025年3月17日、GoogleはChromeのセキュリティを強化するため、Chrome 136以降のバージョンでリモートデバッグ機能の仕様を変更すると発表しました[1]。この変更により、開発者やQAエンジニアが日常的に利用してきたデバッグや自動化のワークフローに大きな影響が出ています。
1.1. 仕様変更の核心
変更点:
--remote-debugging-portまたは--remote-debugging-pipeを使用してリモートデバッグを有効にする際、既定のユーザーデータディレクトリ（普段使いのプロファイル）では機能しなくなりました。必須要件: これらのスイッチと同時に、
--user-data-dirを使用して既定以外のカスタムディレクトリを指定する必要があります。
この変更の背景には、マルウェアがリモートデバッグポートを悪用してユーザーのCookieや認証情報を窃取する攻撃が増加したことがあります。カスタムディレクトリを強制することで、プロファイルの暗号化キーが分離され、既定プロファイルのデータが保護される仕組みです。
1.2. このガイドの目的
本ガイドは、この仕様変更に対応し、開発や自動化の生産性を維持するための実用的かつ包括的な解決策を提供することを目的とします。以下の内容を含みます。
- 技術的検証: 回避策として噂されたシンボリックリンクや企業ポリシーの有効性を検証します。
- 2つの推奨アプローチ: 用途に応じた最適な解決策（カスタムプロファイルとChrome for Testing）を提示します。
- ツール別設定ガイド: VS Code, Selenium, Playwright, Puppeteerでの具体的な設定方法を解説します。
- 実用的なスクリプト: 競合を回避し、ワンクリックでデバッグ環境を起動するスクリプトを提供します。
2. 技術検証：回避策は存在するのか？
仕様変更の発表後、コミュニティではいくつかの回避策が議論されました。当方でこれらの手法を調査・検証した結果を報告します。
1. シンボリックリンク/ジャンクションによる回避
検証結果: 不可能
根拠
- 実際の失敗報告: GitHub issue #1520でJoeDo氏がシンボリックリンクを試行し失敗を報告
- 成功事例の不在: 2025年4月〜10月の期間、コミュニティ全体で成功報告なし
- Chrome 137での強化: Chrome 137 Betaでシンボリックリンクを含むパスで拡張機能が読み込めない問題が報告（Issue #417931738）
- 実装推測: Chromeはパスの正規化（canonicalization）を行い、シンボリックリンクを解決して実際のパスを判定していると推測される
技術的考察
シンボリックリンク: /tmp/chrome-debug -> ~/Library/Application Support/Google/Chrome/Default
↓
Chrome内部でパス解決: realpath() または類似の関数
↓
実際のパス取得: ~/Library/Application Support/Google/Chrome/Default
↓
既定プロファイル判定: 既定パスと一致 → リモートデバッグ拒否
結論
シンボリックリンク/ジャンクションでの偽装は技術的に不可能
2. Enterprise Policyによる上書き
検証結果: 不可能
確認したポリシー
RemoteDebuggingAllowed
- URL: https://chromeenterprise.google/policies/#RemoteDebuggingAllowed
- 対応バージョン: Chrome 93以降
- 機能: リモートデバッグ機能自体の有効/無効を制御
- 設定値:
true:--remote-debugging-port/--remote-debugging-pipeの使用を許可false: リモートデバッグを完全に禁止
重要な制限
If this policy is set to Enabled or not set, users may use remote debugging by specifying --remote-debugging-port and --remote-debugging-pipe command line switches.
含意: ポリシーで許可しても、Chrome 136以降は非既定user-data-dirが必須
他の関連ポリシーの確認結果
Chrome Enterprise Policy List（Chrome 141時点）を確認したが、以下のようなポリシーは存在しない:
RemoteDebuggingAllowedForDefaultProfileRemoteDebuggingUserDataDirRestrictionEnabledAllowRemoteDebuggingWithDefaultProfileRemoteDebuggingDefaultProfileException
公式告知との整合性
2025年3月17日の公式ブログでは:
- Enterprise環境での例外措置について一切言及なし
- 「問題があればcrbug.comに報告」という記載のみ
- ポリシーによる回避策の提案なし
結論
Enterprise Policyによる既定プロファイルでのリモートデバッグ許可は不可能
3. その他の回避手段の検証
3-1. プロファイル全体のコピー
検証結果: 技術的には可能だが実用性に問題あり
動作確認
- GitHub issue #1520でmaghazouani氏が成功を報告
- 既定プロファイルを別ディレクトリにコピーし、
--user-data-dirで指定
実装例（macOS）
# 新しいデバッグ用フォルダを作成
mkdir -p ~/chrome-debug-profile
# 既定プロファイルから全てコピー
cp -R ~/Library/"Application Support"/Google/Chrome/Default \
~/chrome-debug-profile/Default
# 起動
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
--remote-debugging-port=9222 \
--user-data-dir=~/chrome-debug-profile
問題点
- 容量: user-data-dirは数ギガバイトになる可能性
- ディスク消費: コピー後のファイルがシステムに残る
- 同期問題: コピー後の変更は元のプロファイルに反映されない
- Cookie/ログイン状態: 暗号鍵の違いにより引き継げない可能性が高い
- メンテナンス: 定期的な再コピーが必要
評価
一時的な回避策としては可能だが、長期運用には不適
公式ブログの推奨（2025年3月17日）
For browser automation scenarios, we recommend using Chrome for Testing which will continue to respect the existing behavior.
含意: Chrome for Testingは既定プロファイルでもリモートデバッグ可能
回避手段の可否まとめ
| 検証項目 | 結果 | 理由 |
|---|---|---|
| シンボリックリンク/ジャンクション | ❌ 不可能 | Chromeがパスを正規化して検出するため。 |
| Enterprise Policyによる上書き | ❌ 不可能 | 該当するポリシーが存在しないため。 |
| プロファイル全体のコピー | ⚠️ 可能だが非推奨 | 容量、同期、暗号鍵の問題で実用性が低いため。 |
唯一の道は、公式に示された「非既定ディレクトリの使用」というルールに従うことです。
3. 推奨アプローチ：用途に応じた最適な解決策
検証結果を踏まえ、用途に応じて以下の2つのアプローチを推奨します。
アプローチA：通常版Chrome + カスタム--user-data-dir
- 最適な用途: 開発・デバッグ（例: VS Codeでのフロントエンド開発）
- 概要: 普段お使いの通常版Chromeを、デバッグ時のみ専用のカスタムプロファイルで起動します。
| 利点 | 欠点 |
|---|---|
| ✅ 軽量: 新規プロファイルは数MBで、すぐに作成可能。 | ❌ 設定の分離: Cookie, ログイン状態, 拡張機能は引き継がれない。 |
| ✅ クリーンな環境: キャッシュや拡張機能の影響を受けない。 | ❌ 初回の手間: デバッグ対象のサイトへの再ログインが必要。 |
| ✅ 安全: 普段使いのプロファイルと完全に分離される。 | |
| ✅ 公式推奨: VS Codeなどのドキュメントでも推奨されている手法。 |
アプローチB：Chrome for Testing
- 最適な用途: 自動化テスト（例: Selenium, Playwright, Puppeteer）
- 概要: Googleがテストと自動化専用に提供する、バージョン固定可能なChromeの派生版です[4]。
| 利点 | 欠点 |
|---|---|
✅ Chrome 136制限の対象外: --user-data-dirなしでもリモートデバッグ可能。 | ❌ 日常利用は非推奨: 自動更新がなくセキュリティリスクがある。 |
| ✅ バージョン固定: テストの再現性を完全に保証。 | ❌ 手動更新: セキュリティパッチ適用のために手動での更新が必要。 |
| ✅ ChromeDriver完全同期: ドライバのバージョン互換問題を解消。 | |
| ✅ CI/CDに最適: 冪等性のあるテスト環境を構築可能。 |
どちらを選ぶべきか？
| 用途 | 推奨アプローチ | 理由 |
|---|---|---|
| Webサイトやアプリの開発・デバッグ | アプローチA | 軽量で、普段のブラウジング環境と安全に分離できるため。 |
| E2Eテスト、CI/CDでの自動化 | アプローチB | バージョン固定によるテストの信頼性と再現性が不可欠なため。 |
4. 最小摩擦での移行：実用スクリプトとワークフロー
「普段使いの環境に近い状態」を維持しつつ、必要な時だけスムーズにデバッグ環境へ移行するためのワークフローとスクリプトを提案します。ここでは**アプローチA（カスタム--user-data-dir）**を日常の開発で使うことを想定しています。
クロスプラットフォーム起動スクリプト
このワークフローを実現するためのスクリプトです。お使いのOSに合わせて保存し、実行権限を与えてください。
- Windows用 (
start-chrome-debug.bat): start-chrome-debug.bat - macOS/Linux用 (
start-chrome-debug.sh): start-chrome-debug.sh
これらのスクリプトは、ポートやプロセスの競合を自動で検知・解消し、安全にデバッグセッションを開始できます。
5.3. 既定プロファイルに近い環境を作るには？（設定・拡張の移行）
カスタムプロファイルは最初は空の状態ですが、以下の手順で普段の環境に近づけることができます。
- 初回起動: 上記スクリプトで一度デバッグ用Chromeを起動し、プロファイルディレクトリを作成します。
- 拡張機能のインストール: デバッグに必要な拡張機能（React DevTools, Vue.js devtoolsなど）をChromeウェブストアから手動でインストールします。
- 設定の同期（非推奨）: Googleアカウントで同期することも可能ですが、デバッグ環境と通常環境を完全に分離するという観点からは推奨されません。必要な設定のみ手動で行うのが安全です。
注意: Cookieやログイン情報は、プロファイルの暗号鍵が異なるため、ファイルをコピーしても引き継ぐことはできません。デバッグセッションごとに、必要なサイトへの再ログインが必要です。
6. まとめと最終提言
Chrome 136以降の仕様変更は、セキュリティを目的とした不可逆的なものであり、従来のワークフローの見直しが必須です。本ガイドで検証した結果、シンボリックリンクやポリシーによる回避策は存在せず、公式に示されたアプローチに従うのが唯一の道です。
参考文献
[1] Harris, W. (2025, March 17). Changes to remote debugging switches to improve security. Chrome for Developers Blog. https://developer.chrome.com/blog/remote-debugging-port
[2] Chrome >= v136 no longer supports being driven over CDP while using the default --user-data-dir profile. (2025, April 29). GitHub Issue #1520, browser-use/browser-use. https://github.com/browser-use/browser-use/issues/1520
[3] Chrome Enterprise Policy List & Management. (n.d.). Chrome Enterprise. Retrieved October 14, 2025, from https://chromeenterprise.google/policies/#RemoteDebuggingAllowed
[4] Bynens, M. (2023, June 12). Chrome for Testing: reliable downloads for browser automation. Chrome for Developers Blog. https://developer.chrome.com/blog/chrome-for-testing