Chrome DevTools MCPをAIコーディングのブラウザ検証に入れる前に決めたこと

Chrome DevTools MCP は AI エージェントに実ブラウザの状態を見せ、コンソールエラーやネットワークリクエストの確認、スクリーンショット取得などを自動化できる道具です。生成されたコードが「サーバー側では動くはずなのに、なぜかブラウザでは見えない」といった問題を、AIが自ら検証できるようになる点が売りです。公式ドキュメントを見ると、入力・出力・デバッグ・パフォーマンス分析まで多くのツールが揃っており、自動テストの最後の砦を AI に寄せる足がかりになりそうに見えます。ただし大事なのは「便利さと危険は同じツールの中に混在している」という現実です。Chrome DevTools の内容は MCP クライアントへ全て露出します。つまり AI エージェントが、ログイン済み Cookie や未公開環境のデータまで見てしまう可能性があります。ここを無視して普段使い Chrome をそのまま接続すると、ブラウザの個人情報がクラウド上のエージェントに読まれるだけでなく、変更まで許してしまう事態になります。

AIの鬼の視点は「運用設計を先に決めてから入れる」という徹底性です。実装側では --headless で UI なし動作、--isolated で使い捨てプロファイル、--no-usage-statistics で利用統計無効、--no-performance-crux で外部送信を止める、といったコマンドラインオプションで制御できます。さらに出力ディレクトリを明示的に制限し、スクリーンショットやトレースが作業フォルダ配下に落ちるよう設定する。これらを標準にしてから、初めて自動検証に組み込む流れが必要です。中小企業の実務では、Web アプリの修正をAIに任せるとき「最後に人間が見ればいい」では済みません。ブラウザ画面を AI 側へ見せるなら、何が見えて何が変わるかを把握したうえで導入する。その準備を抜かすと、便利さと共に思わぬ情報漏出まで一緒に入ってくることになります。