AIにChrome/Edge/Firefox/WebKit(Safari代替)を操作させる完全ガイド!VS Code・Playwright MCPによる自動化

皆さん、こんにちは。okamoです。

2026年10月15日、OpenAI が「ChatGPT の Computer Use 機能を Chrome 向けに拡張し、開いている複数のタブを参照しながら回答したり、Work モードでタブを横断した作業をこなしたりできる」と発表しました。

このニュースを見て真っ先に感じたのは、「これ、VS Code の Copilot Chat なら前からできていたよね?」ということでした。実は VS Code には統合ブラウザツールが標準で入っており、さらに Playwright MCP を追加すれば、Chrome / Edge / Firefox / WebKit(Safari 相当)の4ブラウザを、全く同じ操作感で AI エージェントに触らせることができます。

「AI にブラウザを操作させるなんて難しそう」と思っている方も多いかもしれませんが、前提ツールの導入から設定まで、手順さえ知っていれば驚くほど簡単に導入できます。特に WebKit を動かせる利点は大きく、Windows 環境にいながらにして iPhone や Mac の Safari で起きがちな表示崩れの予兆を早期にキャッチ できます。

この記事では、AI によるブラウザ操作のセットアップ手順から現場でぶつかる Basic 認証の突破術まで、画面キャプチャを交えて詳しく解説します。


この記事でわかること

  • winget を使った Node.js(npx)の導入と mcp.json の基本構成
  • VS Code Copilot Chat だけで完結する「ブラウザツール」の使い方と限界
  • Playwright MCP を導入し、Chrome / Edge / Firefox / WebKit の4ブラウザを切り替えて操作する方法
  • 「ログインだけ人間が担当し、AI がセッションを引き継ぐ」という安全な共同作業スタイル
  • Basic 認証サイトで AI が白紙ページに直面したときの3つの回避策

この記事の内容は 2026年10月時点の検証環境にもとづいています。


1. 前提環境をつくる

まずは AI からブラウザ操作ツールを呼び出すための下準備を進めましょう。Playwright MCP は npx コマンド経由で起動するため、Node.js のランタイム環境が必要です。

1-1. Node.js(npx)を winget でインストールする

Windows 環境であれば、パッケージマネージャーの winget を使うのが最も手軽で確実です。PowerShell を管理者権限で開き、以下のコマンドを実行します。

winget install OpenJS.NodeJS.LTS

インストールが完了したら、環境変数を反映させるために PowerShell ウィンドウを一度閉じて再度開き、バージョンが表示されるか確認してください。

node -v    # 例: v24.x.x
npx -v     # 例: 11.x.x

補足: 複数の Node.js バージョンを切り替えたい場合は nvm-windows(nvm4w)を利用しても問題ありません。今回の検証環境も nvm4w 上の Node.js 24 系を使用しています。 なお、npx は初回実行時に対象パッケージを自動ダウンロードするため、初回のサーバー起動時のみ少し時間がかかります(2回目以降はキャッシュが効いて即座に起動します)。

1-2. VS Code と Copilot の準備

開発環境として以下を揃えます。

  • VS Code 本体(検証時のバージョン: 1.142.0)
  • 拡張機能: GitHub Copilot および GitHub Copilot Chat(ログイン済みであること)

VS Code 内部で動く「統合ブラウザ(Integrated Browser)」は本体標準の機能であるため、追加の拡張機能を別途入れる必要はありません。

1-3. mcp.json の基本構文

VS Code で Model Context Protocol (MCP) を利用する設定は、プロジェクトのワークスペース直下にある .vscode/mcp.json に記述します(PC全体で使い回したい場合はユーザー設定側の mcp.json でも可)。

最小構成は以下の通りシンプルです。

{
  "servers": {
    // ここに利用したいツール(サーバー)を定義していく
  }
}

npx で立ち上げる MCP サーバーの場合、command に "npx" を指定し、args に実行するパッケージ名や引数を指定します。ファイルを保存すると VS Code 上にサーバー起動用の UI が表示されます。

ここで1つ大きな注意点があります。MCP サーバーは設定ファイルを保存しただけでは自動起動しません。手動で「起動(Start)」ボタンを押して立ち上げる必要があります。初見で最も引っかかりやすいポイントなので覚えておきましょう。


2. まずは VS Code Copilot Chat のブラウザツール(初心者向け)

2-1. 何ができるのか

まずは外部ツールの設定不要で、VS Code 単体で使える標準のブラウザ機能から見ていきましょう。 Copilot Chat の入力欄で「この URL のページを開いて内容を確認して」と指示を出すだけで、エディタ内部に統合ブラウザが立ち上がり、AI が DOM やテキストツリーを直接解析し始めます。

検証サイトについて: 本記事のキャプチャ画面は、検証用に用意したテストサイト(https://test.okamomedia.tokyo/)を使用しています。記事一覧・詳細・ログイン・コメント投稿の機能を備えた軽量メディアです。タイトルがプレースホルダー(【要書き換え】)のままですが、動作検証には十分な構成です。

VS Code のエディタ内にブラウザが表示されている様子

上記の画面のように、VS Code のメインペインにブラウザ画面がレンダリングされ、右側のチャットパネルで AI がページの構造や H1 タグの文言をリアルタイムに読み取り、報告してくれます。指示できるアクションは非常に直感的です。

  • 指定 URL のページを開く
  • ページ内容をアクセシビリティツリー(テキスト情報)として取得・把握する
  • リンクやボタンを探索してクリックする
  • 入力フォームにテキストを流し込む
  • ページをスクロールして隠れた要素を確認する
  • 現在のビューをスクリーンショットで確認する

2-2. 実際にやってみた

実際に Copilot Chat に対して以下のステップをチャットで依頼してみました。

  1. 「トップページを開いて」
  2. 「ページの一番下までスクロールして」
  3. 「新着一覧の中から気になる記事を1本選んでクリックして」

人間がマウスを握ることなく、自然言語のやりとりのみで AI が画面内のリンクを識別し、記事詳細画面へとページ遷移を完了させました。

2-3. できること・できないことの比較

項目VS Code 統合ブラウザツール
導入コストゼロ(VS Code に標準搭載)
操作対象VS Code 統合ブラウザ(Electron 内包)のみ
ページの読み取り◎(テキストツリーとして高速に解析)
操作(クリック・入力・スクロール)◎
スクリーンショット△ チャット内に返るだけでファイル保存不可
ログイン操作○(人間が直接触ることも、AIに打たせることも可能)
Basic 認証❌ 認証ダイアログが出ず白紙になる
リクエストヘッダの制御❌ 不可

2-4. 開発者を悩ませる「Basic 認証白紙問題」

ローカル開発中の Web アプリやステージング環境など、Basic 認証が掛けられたサイトを VS Code の統合ブラウザで開こうとすると、画面全体が真っ白なまま停止します。コンソールには HTTP 401 Unauthorized が静かに出力されるだけです。

これは VS Code 側の既知の不具合・制限(Electron の認証ダイアログハンドリングが未実装)によるものです。

最も厄介なのは、内部的に読み込みが失敗しているにもかかわらず、AI 側には「正常にページを開きました」と成功ステータスが返ってしまうことです。AI は平然と「ページを開きました」と答え、画面は真っ白。この落とし穴にハマると原因究明に多大な時間を奪われます(回避策は第4章で解説します)。


3. Playwright MCP でブラウザを4種類に増やす(中級者向け)

標準ツールの制約を超え、本格的なクロスブラウザ検証や自動テストを行いたい場合は Playwright MCP を導入します。Claude Code や Kiro、OpenCode などの自律型エージェントツールを使っている方でも、同一の設定資産をそのまま流用できます。

3-1. Playwright MCP の強み

Playwright は、ブラウザ自動操作のデファクトスタンダードです。Playwright MCP を挟むことで、AI は指定された本物のブラウザをバックグラウンドまたは画面付きで自在に操作できるようになります。

最大の魅力は、操作対象のブラウザエンジンを自在に切り替えられる点です。

オプション指定起動する実ブラウザ
--browser=chromePC にインストール済みの Google Chrome
--browser=msedgePC にインストール済みの Microsoft Edge
--browser=firefoxPlaywright 同梱の専用 Firefox ビルド
--browser=webkitPlaywright の WebKit(Safari と同等の描画エンジン)

3-2. インストールと設定ファイルの作成

.vscode/mcp.json に Google Chrome 用の設定を追記します。

{
  "servers": {
    "chrome": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--browser=chrome",
        "--ignore-https-errors",
        "--config",
        "${workspaceFolder}/playwright-mcp.chrome.json"
      ]
    }
  }
}

続いて、ワークスペース直下に詳細設定ファイル(playwright-mcp.chrome.json)を作成します。

{
  "browser": {
    "contextOptions": {
      "viewport": { "width": 1440, "height": 900 },
      "locale": "ja-JP"
    }
  },
  "timeouts": { "navigation": 60000 },
  "outputDir": "docs/screenshots/chrome"
}

設定時の重要ポイント:

  • --config の後には必ず設定ファイルパスを指定する(引数なしだとエラーになります)
  • outputDir を指定すると、AI が撮影したスクリーンショットが画像ファイルとしてローカルに保存されるため、エビデンス残しに最適です
  • viewport(画面解像度)を統一しておくことで、複数ブラウザ間でのレイアウト崩れの精密な比較が可能になります

3-3. 人間と AI のタスク分担 — 「ログインは人間、作業は AI」

Playwright MCP はユーザープロファイルを永続化するため、「人間が手動で認証を通過したブラウザセッションを、そのまま AI が引き継ぐ」というセキュアな運用が可能です。

  1. AI に「サイトのログイン画面を開いて」と指示(実ブラウザが立ち上がる)
  2. 人間がその画面で ID・パスワード入力や 2段階認証(Passkey/SMS/認証アプリ)を突破する
  3. ログイン完了後、チャットで「ログインできたよ」と合図する
  4. AI がセッション確立済みの画面を読み込み、目的の作業を再開する

ログイン後の画面(AIがアカウント名とメニューを読み取れた)

上の画像のように、人間が認証を済ませたことで右上にユーザーアイコンが表示され、AI はアカウント権限を認識できています。マスターパスワードを AI のプロンプトに晒すリスクが一切ありません。

AIがコメントを投稿し、反映まで確認した状態

引き継ぎ後、AI に「テストコメントを投稿してみて」と指示を出した結果がこちらです。フォームへの入力から送信ボタンの押下、リロード後のコメント一覧への反映確認まで、人間が何もしなくても自律的に完了させてくれます。

注意: プロファイルはブラウザごとに分離されているため、Chrome でログインしても Edge 側には反映されません。また、作業中に MCP サーバーを再起動するとセッションが破棄される点に留意してください。

3-4. Microsoft Edge を追加する

Windows ユーザーであれば標準搭載されている Edge を追加設定してみましょう。mcp.json の servers に以下を追加します。

"edge": {
  "command": "npx",
  "args": [
    "@playwright/mcp@latest",
    "--browser=msedge",
    "--ignore-https-errors",
    "--config",
    "${workspaceFolder}/playwright-mcp.edge.json"
  ]
}

Edge で記事ページを表示した状態

上の画像は Edge 経由で記事詳細ページを読み込ませた様子です。Chrome と Edge は同じ Chromium レンダリングエンジンのため、文字の描画位置やページ全体の高さ(レンダリング結果)も完全に一致することが確認できました。

3-5. Firefox を追加する

Gecko エンジンを搭載する Firefox も同様に組み込めます。

"firefox": {
  "command": "npx",
  "args": [
    "@playwright/mcp@latest",
    "--browser=firefox",
    "--ignore-https-errors",
    "--config",
    "${workspaceFolder}/playwright-mcp.firefox.json"
  ]
}

Firefox と後述の WebKit を利用する場合、初回のみブラウザバイナリのダウンロードが必要です。

npx playwright install firefox webkit

Firefox でトップページ最下部までスクロールした状態

上記は Firefox 専用ビルドを立ち上げ、トップページの最下部(フッター領域)までスクロールさせてページ構造を確認した状態です。Chromium 系とは異なるフォントレンダリングの差異なども AI 越しに素早く確認できます。

3-6. Safari の代替として WebKit を使う(Windows 開発者の必須テク)

Web 制作やアプリ開発で最も頭を悩ませるのが「iPhone や Mac の Safari だけで起きるレイアウト崩れ・CSS バグ」です。しかし Windows 版 Safari は開発が終了しており、実機がないと検証が困難でした。

そこで Playwright の WebKit を利用します。Safari と同一のレンダリングエンジンを Windows 上で直接 AI に走らせることが可能です。

"webkit": {
  "command": "npx",
  "args": [
    "@playwright/mcp@latest",
    "--browser=webkit",
    "--ignore-https-errors",
    "--config",
    "${workspaceFolder}/playwright-mcp.webkit.json"
  ]
}

WebKit で表示したトップページ

上記は WebKit でトップページを描画させたキャプチャです。User-Agent も macOS の Safari(Version/26.6 Safari/605.1.15 など)を名乗るため、Safari 特有のフレックスボックスの挙動不整合やスクロールバーの重なりなどを、開発の初期段階で AI に検知させることができます。

3-7. ツール機能比較まとめ

項目VS Code 標準ブラウザPlaywright MCP
操作可能ブラウザ内蔵 Electron のみChrome / Edge / Firefox / WebKit
環境構築不要(即利用可)mcp.json 設定+サーバー起動
スクリーンショット保存❌(チャット表示のみ)✅(ローカルファイル保存)
ログイン状態閉じるまで✅(永続プロファイル)
ヘッダ制御・認証情報❌ 不可✅(柔軟に設定可能)
Basic 認証❌ 白紙化✅(完全対応)
エラー通知白紙でも「成功」と誤認明確に失敗ステータスを返却

4. Basic 認証を突破する3つのアプローチ

ステージング環境などで多用される Basic 認証への対処法を比較・解説します。

4-1. 各アプローチの比較結果

方式トップページ遷移API・サブリソース取得資格情報の漏洩リスク推奨度
① 素の URL を渡す❌ 白紙・停止❌ 失敗なし登用不可
② URL に資格情報を埋め込む✅ 成功❌ 必ず壊れる⚠️ 高い(URL露出)非推奨
③ ローカルリバースプロキシ✅ 成功✅ 成功なしVS Code ツールの最適解
④ Playwright httpCredentials✅ 成功✅ 成功なし最優秀(MCP 利用時)

4-2. 【推奨】Playwright MCP の httpCredentials 設定

Playwright MCP を使っている場合、これが最も美しく安全な解決策です。個別設定ファイル(例:playwright-mcp.chrome.json)に認証情報を定義します。

{
  "browser": {
    "contextOptions": {
      "viewport": { "width": 1440, "height": 900 },
      "httpCredentials": {
        "username": "user",
        "password": "passwd",
        "origin": "http://127.0.0.1:4096"
      }
    }
  }
}

origin を指定することで、指定ホスト以外へ誤って資格情報が送信される事故を防止できます。

httpCredentials で認証し、サブリソースの fetch も成功した状態

画面キャプチャの通り、HTML 本体の描画だけでなく、SPA で頻繁に行われるバックグラウンドの fetch('/api/whoami') によるデータ通信まで緑色のチェックが付き、正常に成功していることがわかります。

4-3. 【VS Code 標準ツールの解】Node.js プロキシの中継

VS Code の標準統合ブラウザツールを使いたい場合は、ヘッダを自動注入する簡易中継プロキシをローカルに立ち上げます。

// scripts/basic-auth-proxy.js
const http = require('http');
const AUTH = 'Basic ' + Buffer.from('user:passwd').toString('base64');

http.createServer((req, res) => {
  const headers = { ...req.headers, host: '127.0.0.1:4096', authorization: AUTH };
  const upstream = http.request(
    { hostname: '127.0.0.1', port: 4096, method: req.method, path: req.url, headers },
    (r) => {
      res.writeHead(r.statusCode, r.headers);
      r.pipe(res);
    }
  );
  req.pipe(upstream);
}).listen(3100, '127.0.0.1');
node scripts/basic-auth-proxy.js

プロキシを起動した状態で、AI にはプロキシの URL を開かせます。

プロキシ経由でサブリソースの fetch も成功した状態

ブラウザツールがプロキシを通過する際に適切な Authorization ヘッダが付与されるため、サブリソースを含め正常に通信が成立します。

4-4. 【非推奨】インライン URL 方式(http://user:pass@host)

ネット上のフォーラムでよく紹介される「URL に直接 ID とパスワードを含める形式(http://user:passwd@xxxxxx.com/)」は、現代の Web アプリケーション開発では絶対に採用してはいけません。

インラインURL方式ではトップレベルは通るが fetch が失敗する

キャプチャの赤字エラーに注目してください。最初の HTML 表示自体は一見パスしますが、JavaScript 内で相対パス宛てに発行された fetch() リクエストが以下のブラウザセキュリティ例外によって確実にクラッシュします。

Failed to execute 'fetch' on 'Window': Request cannot be constructed from a URL that includes credentials: /api/whoami

ブラウザ履歴やログに平文パスワードが残るセキュリティリスクに加え、React や Next.js、Vue などの SPA ではほぼ確実に画面機能が壊れてしまうため、必ずプロキシ方式か httpCredentials を採用してください。


5. 参考リンク


おわりに

「AI にブラウザを操作させる」と聞くと、大掛かりなインフラが必要な技術に思われがちですが、実際には VS Code と Playwright MCP を組み合わせるだけで、今すぐローカル環境で実践できる身近な開発手法 です。

特に Chrome や Edge にとどまらず、Firefox や Safari 代替となる WebKit までを手元の Windows 環境で AI に操作してもらえます。「ログインのような機密操作は人間が担い、その後の巡回や確認は AI に任せる」という安全なワークフローを構築し、日々の開発・検証業務をどんどん効率化していきたいですね!