この記事は、筆者が音声入力で話した内容を Claude Code で読みやすく整理したものです。
書いてある主張も検証結果も筆者自身のもので、公開前にすべて目を通しています。
Claude Code にブラウザを触らせる方法が、2026年に入って増えました。
Claude in Chrome と Playwright MCP、どちらを使えばいいのかは、自分の中でも去年と答えが変わっています。
この記事は、2026年8月時点で筆者がどう使い分けているかと、Playwright MCP の最小構成をまとめたものです。
忙しい人のための要約
どちらを入れるか決めるだけなら、この3点で足ります。
- Chrome の画面を見るだけなら、今は Claude in Chrome（Anthropic公式のChrome拡張機能）で足りる
- Playwright MCP（Microsoft製のブラウザ操作MCPサーバー）の出番は、Firefox や Safari など Chrome 以外のブラウザまで確認したいとき
- 導入は
claude mcp add playwright npx @playwright/mcp@latestの1行で終わり、導入のためにテストコードを書く必要はない
Chrome DevTools MCP をやめて、今どうしているか
2025年12月に書いたこと
去年の12月に、Playwright MCP と Chrome DevTools MCP の使い分けを記事にしました。
どちらも MCP（Model Context Protocol、AI と外部ツールをつなぐための共通の決まりごと）を通してブラウザを操作します。
Chrome DevTools MCP のほうは Google 製で、Chrome 専用です。
そこで出した結論は、通常のフロントエンド開発なら Chrome DevTools MCP で十分、他ブラウザ対応が必要なときだけ Playwright MCP を使う、というものでした。
8か月ほど経って、この推奨は変わっています。
Chrome DevTools MCP は、今は使っていません。
Chrome だけなら Claude in Chrome の出番
理由は単純で、Claude in Chrome に役割を奪われたからです。
Claude in Chrome は Anthropic が公式に出している Chrome 拡張機能で、claude --chrome で起動すると自分が普段使っているブラウザをそのまま操作してくれます。
ログイン状態が共有されるため、すでにサインイン済みのサービスにも入っていけます。
筆者は開発中の画面を見てもらうときにも、ブラウザを開かないと調べられない用事を頼むときにも、これをよく使っています。
Chrome の中で完結する話なら、MCP サーバーを別に立てる理由がなくなりました。
ただし、拡張機能のインストールと対象プランでのサインインが要るので、導入には少し条件があります。
その代わり標準機能なので、ログイン済みのセッションのような、Playwright MCP なら別途用意しないといけない前提を、面倒な事前設定なしにそのまま使えます。
それでも最初に試すなら Playwright MCP
とはいえ、Playwright MCP の出番は今も残っています。
基準は要約と同じ「見たいブラウザが Chrome だけかどうか」で、実際によく効くのは次の線引きです。
ログイン済みの既存サイトを見せたいときは Claude in Chrome、localhost で動かしている自作アプリを検証したいときは Playwright MCP。
そして、これから初めて AI にブラウザ確認を任せてみるなら、Playwright MCP から入るのをおすすめします。
Claude in Chrome は拡張機能のインストールとプラン条件があるぶん、最初の一歩としては手間が乗ります。
Playwright MCP なら、ターミナルで1行打てば終わり。
なお、2026年に入って公式から @playwright/cli という別の入り口も出ています。
そちらは記事の最後で。
Chrome だけ見ていると何を見落とすか
Playwright MCP を手放していない理由が、クロスブラウザ（Chrome だけでなく Firefox や Safari でも同じように動くかを確かめること）です。
「自分の環境では動いた」が通じないとき
手元で動いたからといって、使う人の環境でも同じように動くとは限りません。
個人開発でも、Chrome では問題なく見えていた CSS の flexbox（要素を横並びに並べるレイアウトの仕組み）が、後から自分のスマホの Safari で見たら崩れていた、ということがあります。
一部のブラウザだけで確認していると、特定のユーザーの環境でだけ動かない不具合を、見落としたまま公開してしまうことになります。
MDN のブラウザ互換性表の読み方
使おうとしている CSS や JavaScript の機能がどのブラウザで動くかは、MDN Web Docs の各ページ下部にある「Browser compatibility」の表で調べます。
たとえば ::-webkit-inner-spin-button という擬似要素（数値入力欄の上下ボタンの見た目を変える CSS）の表がこちらです。
2026年8月時点で、Firefox と Firefox for Android が No support になっています。
Chrome は 6、Edge は 79、Safari は 5 から対応しているので、Chrome で作業しているかぎり気づけません。
個別の機能名よりも、この表を見に行く習慣のほうを覚えておきたいです。
ブラウザの対応状況は動くので、去年の知識がそのまま通用するとは限りません。
この習慣を活かすためにも、実際に他のブラウザで確認できる Playwright MCP を入れておきます。
Playwright MCP を入れる
Playwright MCP は、Microsoft が公式に提供しているブラウザ自動操作の MCP サーバーです。
入れるとClaude Code が自分でブラウザを開けるようになります。
追加は1コマンド
claude mcp add playwright npx @playwright/mcp@latest
これで追加は終わりです。
テストコードを書いたり、ブラウザを別途インストールしたりする必要はありません。
接続を確認する
追加できたら Claude Code を起動して、/mcp で接続状態を見ておきます。
claude
> /mcp
1 server
Local MCPs
❯ playwright · ✔ connected
connected と出れば準備完了です。
connecting... のまま止まって見えることがありますが、2〜3秒待つと切り替わります。
どこまで許可するかを決める
初めてブラウザを操作させるとき、Claude Code は実行の前に確認を出します。
Tool use
playwright - Navigate to a URL(url: "https://www.google.com") (MCP)
Navigate to a URL
Do you want to proceed?
❯ 1. Yes
2. Yes, and don't ask again for playwright - Navigate to a URL
commands in /Users/username/Desktop/task-app
3. No
これはパーミッション（ツールを実行する前に許可を取る仕組み）による確認です。
外部に影響を与える操作の前に挟まります。
「2. Yes, and don't ask again for...」を選ぶと、そのプロジェクトの中では次回から確認が省かれます。
選んだ内容はプロジェクトの .claude/settings.local.json（そのプロジェクト専用の権限設定ファイル）に書き込まれます。
↓ .claude/settings.local.json に保存される許可設定の例
{
"permissions": {
"allow": [
"mcp__playwright__browser_click",
"mcp__playwright__browser_type",
"mcp__playwright__browser_fill_form"
]
}
}
allow には mcp__MCPサーバー名__ツール名 の形で1行ずつ積まれていきます。
ツール単位で管理されるので、まだ許可していない操作に進むとまた確認が出ます。
MCP の仕組みからこの許可設定まで順を追って手を動かしたい場合は、拙著『Claude Codeで作って学ぶ AI駆動アプリ開発入門』（技術評論社、2026年9月8日発売）の第7章で扱っています。
ブラウザ操作を指示してみる
ここからは対話モードでの指示だけです。
まず1つ動かしてみる
日本語で指示するだけです。
> Playwright MCP を使って Google のトップページを開いて
許可を求められたら Yes を選ぶと、ブラウザのウィンドウが開いてページが表示されます。
ここでは、ツール名をこちらで指定していません。
「開いて」という日本語から、Claude Code が Navigate to a URL を選び、URL も組み立てています。
もうひとつ、Claude Code はブラウザに表示されている内容をテキストとして読み取って返してきます。
一連の流れをまとめて指示する
1操作ずつ指示できるということは、まとめて渡すこともできます。
これが E2E テスト（End-to-End テスト）にあたります。
アプリをユーザーの視点で端から端まで、通しで確認するテストのことです。
まず開発サーバーを起動しておきます。
npm run dev
そのうえで、確認したい順番を並べて渡します。
> Playwright MCP を使って、タスク管理アプリの動作確認をしてください。
以下を順番に確認してください。
- タスクを1つ追加する
- 追加したタスクが一覧に表示されることを確認する
- ステータスを In Progress に変更する
クリックやフォーム入力はもちろん、セレクトボックスの操作も自動で実行されます。
ここで手に入るのは「テストコードを書かなくてよくなること」ではありません。
毎回自分の手でブラウザを開いて確かめていた作業が、そのまま置き換わることです。
他のブラウザで確認するには
ここまではすべて Chrome で動いています。
クロスブラウザの話に戻ると、Playwright MCP は --browser オプションで動かすブラウザを切り替えられます。
claude mcp add playwright -- npx @playwright/mcp@latest --browser firefox
途中の -- は、後ろのオプションを claude mcp add ではなく Playwright MCP 側に渡すための区切りです。
すでに同じ名前で追加してある場合は、claude mcp remove playwright で一度消してから入れ直します。
指定できるのは chrome / firefox / webkit / msedge の4つ。
webkit が Safari の描画エンジンにあたるので、Safari での見え方はここで確認します。
firefox と webkit は実機のブラウザではなく Playwright 専用のビルドを使うため、初回はダウンロードが必要です。
実際に firefox と webkit は動かしていて、Chrome で作った画面をそのまま別のエンジンに通せます。
Playwright CLI という選択肢
2026年に入って、Microsoft は MCP サーバーとは別に @playwright/cli というコマンドラインツールも公開しています。
公式ドキュメントの比較では、コーディングエージェント向けには CLI のほうが向いているとされています。
ただ、これを実際に計測した検証記事では、18セッションの計測で逆の結果も出ています。
| 操作 | Playwright CLI | Playwright MCP |
|---|---|---|
| 単純な読み取り | 15,863 | 15,808 |
| フォーム入力 | 60,808 | 30,707 |
| 複数ステップ | 201,683 | 16,182 |
単位はトークンの中央値で、操作が複雑になるほど差が開いています。
ただ、ブラウザでの確認はこのツールを使うと、Claude Code に明示的に渡しやすいぶん、慣れないうちは分かりやすいとも思っています。
まずは MCP で試して、使い込んでトークン消費が気になってきたら CLI を見に行く順番をおすすめします。
まとめ
2026年8月時点で、使い分けの基準は見たいブラウザが Chrome だけかどうかです。
Claude in Chrome は拡張機能とプランの用意が要る代わりに、ログイン済みのセッションをそのまま使える、標準機能ならではの良さがあります。
去年 Chrome DevTools MCP を勧めた身としては、選択肢が増えたぶん、「全部入れる」より、何を見たいかで選ぶほうが道具選びの判断が早くなったと感じています。
書籍『Claude Codeで作って学ぶ AI駆動アプリ開発入門』では、第7章で MCP の基本から Playwright MCP の操作まで、第8章では実際にアプリを作りながら E2E テストとデプロイまで進めます。
Xをフォローいただけると嬉しいです！
AI駆動開発（特に Claude Code）のノウハウや Tips をよく発信しています！