もう入っている Chrome を、そのまま触らせる
Chrome DevTools MCP は、いま普段使っている Chrome をそのまま使います。自動化用のブラウザを別に落とす手順が要らないので、入れるのはコマンド1本です。動かしてみると立ち上がってくるのは見慣れた Chrome とほぼ同じ画面で、そこの安心感が大きかったですね。
そうなると素朴な問いが1つ残ります。ブラウザも触らせたいけど、ログインが要る画面はどうするのか。先に環境を作って、そこから順に書きます。
先に1つだけ前提があります。Node.js が入っていることです。この後のコマンドで使う npx は Node.js に同梱されているので、まっさらな Windows では叩けません。確かめたのは v22.15.0 です。
Node.js の入れ方そのものはこの記事では扱いません。普段から開発している人なら手癖で終わる話ですし、そうでない人は Claude に「Windows に Node.js を入れたい」と聞けば、いまの環境に合った手順を出してくれます。ここに書いてもすぐ古くなるところなので、そちらに任せます。
入れ方そのものに新しいところは何もないので、公式の Get started も並べておきます。Gemini CLI や Codex、JSON で設定を書く形はそちらにまとまっています。Claude Code についてはプラグイン経由の入れ方（/plugin marketplace add ChromeDevTools/chrome-devtools-mcp → /plugin install chrome-devtools-mcp@chrome-devtools-plugins）も案内されていて、そちらは MCP に加えて Skills も一緒に入ります。この記事は素の MCP 登録だけで進めます。
特別な事情がない方は！Skillsも一緒に入れておいたほうがいいから公式を見ようね！
この前提を踏まえて、入れるのはコマンド1本です。
claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latestこれだけです。オプションは1つも要りません。打ったディレクトリ限定で登録されるので、どこでも使いたいなら --scope user を足します。
追加したら Claude Code のセッションを一度開き直します。開き直さないとツールが生えません。入っているかはこれで見えます。
$ claude mcp list
Checking MCP server health…
chrome-devtools: npx -y chrome-devtools-mcp@latest --user-data-dir=C:\Users\<ユーザー名>\.chrome-automation-profile --viewport=1400x900 --screenshot-format=webp --screenshot-quality=70 --screenshot-max-width=1400 - ✔ Connected
僕の環境はオプションを足しているので長いですが、素の登録ならもっと短く出ます。見るのは末尾の ✔ Connected だけです。ただしこれで分かるのはサーバーの疎通までで、実際に動くかは1回 list_pages を呼ばせるまで分かりません（この話は最後にもう一度出てきます）。
今回は Windows で完結させています。WSL2 や devcontainer からホストの Chrome を叩く構成は扱いません。
入ったので、何が取れるのかを先に見ておきます。自分のブログの公開ページを開いて、構造をテキストで取ってみます。
navigate_page(pageId=1, type="url", url="https://<自社ブログ>/")
→ Successfully navigated to https://<自社ブログ>/.
## Pages
1: SIOS Tech Lab - エンジニアのためになる技術トピックス (https://<自社ブログ>/) [selected]
take_snapshot を呼ぶと、ページの構造がテキストで返ってきます。要素に番号（uid）が振られているので、座標を推定しなくても操作できるんですよね。
uid=1_0 RootWebArea "SIOS Tech Lab - エンジニアのためになる技術トピックス" url="https://<自社ブログ>/"
uid=1_1 banner
uid=1_218 StaticText "© 2026 SIOS Tech Lab All rights reserved."
使い分けは1行で足ります。操作するためならスナップショット、人に見せる・見た目を判断するためならスクリーンショットです。
ブラウザ操作なら、だいたい一通りできる
ここまでスナップショットとスクリーンショットしか出していませんが、道具はもっとあります。公式のツール一覧を数えると、2026年9月の時点で57個ありました。ブラウザ操作に関わることなら、だいたい一通りできると思っていいです。
まずユーザー操作のほう。クリック、テキスト入力、フォームの一括入力、ドラッグ、ファイルのアップロード、キーの送信、ダイアログの応答。タブの開閉と切り替え、画面サイズやデバイスのエミュレーションもあります。人が画面でやっていることは、だいたい指示に置き換わります。
うれしいのはここからです。F12 で開く開発者ツールのタブで見ていたものは、だいたいそのまま取れます。ネットワークのリクエスト一覧とヘッダ（Cookie も入ります）、パフォーマンスのトレースから Core Web Vitals（LCP・INP・CLS）、コンソールのメッセージ。画面の見た目ではなく数字が返るので、そのまま AI に読ませて判断させられるんですよね。
いま議論中の話も1つおまけで書いておきます。ヘッド付きの Chrome を触らせても、OS のマウスカーソルは動きません。入力は CDP のレイヤで注入されるので、隣で見ている人にはエージェントがどこをクリックしたのか分からないんですよね。そこで「ゴーストカーソルを重ねて見せる」提案が上がっていて、実装まで済んだ PR も1本ありましたが、ページに DOM を挿し込む形は避けたいというメンテナのコメントが付いて、いまは意見を集めている段階です（2026-09-07 に確認）。この辺はすぐ動くので、気になる人は issue を直接見てください。
動くのは、普段使いとは別のプロファイル
オプション無しで動くのは、chrome-devtools-mcp が自前の場所に専用のプロファイルを作ってくれるからです。これは試してみるとわかりますが、Chrome 136 以降、既定のプロファイルのままだとリモートデバッグの指定が無視されるんですよね。理由は公式のリンクで。
要するに普段使いの Chrome とは別のプロファイルで動く、という前提が最初から満たされているわけです。
置き場所を自分で決めたいときだけ、--user-data-dir で渡します。僕がそうしているのは、後から中を見られるようにしておきたかったからです。ほかにも画面サイズやスクリーンショットの形式を指定するオプションがありますが、最初は1つも要りません。要るようになったら公式のオプション一覧で必要なものだけ拾ってください。
専用のプロファイルには、本物のログイン状態がそのまま乗ります。フォルダごと別の PC にコピーしても、そのままでは使えない作りになっています（ここは自分では試していません）。ただこれを「安全」とは読まないでほしくて、守れているのは持ち出しだけで、同じ PC の中からは触れてしまうんですよね。だから普段使いのプロファイルと分かれているのは、動かすための条件であると同時に、被害を閉じ込める線でもあるんだと思っています。
ログイン画面に来たら、エージェントはどうするのか
ここからが本題です。僕の前提は1つで、ID とパスワードはエージェントに渡しません。認証が要る画面を触らせたいときも、そこだけは人が打つ。その前提で指示を先に書いておきます。
実際に投げたプロンプトの末尾がこれです。
前提: ログインは人がやる — 認証画面が出たら止まって依頼する。そう書いておくと、エージェントは認証フォームを見つけた時点で入力を試さずに止まります。止まったときの出力がこれです。
ここで止まります。**手動ログインをお願いします。**
ブラウザは `<自社ブログ>/wp-login.php` を開いた状態です（`pageId=1`、入力前の1枚は取得済み）。
お願いしたいこと:
1. その Chrome ウィンドウで**ログインしてください**（ID/パスワードは私は一切触りません）
2. ⚠️ ログイン後、**管理画面のまま置いておいて構いません** — 私は管理画面をスナップショットも
スクショもせず、公開ページへ直接 navigate して戻します
3. 終わったら「**終わった**」と言ってください。それを合図に再開します
止まり方として効いているのは3つあると思っていて。頼みごとが1つに絞られていること（ログインして、だけ。他の判断を人に投げていない）、やらないことを明言していること（ID・パスワードには触らない、管理画面は撮らない）、再開の合図を先に決めていること（人が次に何を言えばいいか迷わない）です。
ただしこれは規約であって、強制ではありません。フォームに入力するツール自体は生きているので、絶対に触らせたくないなら、ツールの許可設定の側で落とすことになります。
画面はこれ1枚だけで、空欄のフォームです。エージェントはここに一度も触っていません。
人が返した合図は「ログインした」でした。依頼したのは「終わった」だったんですけど、今回はこれでも再開できています。
再開の1手目は list_pages にします。これも指示に先に書いておく一行です。ブラウザを開き直すと番号が振り直されることがあって、そのときは MCP 自身が「再起動されたので番号が変わった」と教えてくれます。古い番号のまま呼ぶと失敗するので、1手目は取り直しにしておくと安全なんですよね。
ついでに、採番の確認はそのまま「いま何が開いているか」の確認にもなります。
list_pages()
→ ## Pages
1: ダッシュボード ‹ SIOS Tech Lab — WordPress (https://<自社ブログ>/wp-admin/) [selected]
ログインすると管理画面に入れます。ただ今回は中を見ていなくて、タイトル行がテキストで出ているだけで、そのまま公開ページへ戻しました。
戻した先で撮ったのがこれです。さっきと同じ URL、同じ位置で、上端に管理バーが増えているだけです。
これで受け渡しが成立しています。人が担ったのはログインだけで、その前後はエージェントが動いているんですよね。
ひとつ気をつけどころがあります。認証の先へ入るということは、そこから先はログインした人の権限で動くということです。読める範囲も押せるボタンも、認証した自分と同じになります。ID とパスワードを渡していないことと、任せた範囲が狭いことは別なので、管理者のアカウントで入るのか、要る権限だけのアカウントで入るのかは、触らせる前に決めておいたほうがいいです。
なお、ここで書いているのは自分たちのサイトでの話です。他社のサービスを自動で操作させてよいかは規約の話が別に要るので、この記事では扱いません。
毎回ログインし直すことになるの？
プロファイルに何が乗るのか、認証を誰が担うのか。ここまでの2つは、最後に1つの問いでつながります。ログインした状態は、どこまで残るのか。ここは層が2つあるので分けて書きます。
1つは、プロファイルに乗る Google アカウントのサインインです。こちらは残っていて、閉じて開き直しても入ったままでした。確かめたのは約8分後、約28時間後、いちばん長いところで約6日2時間後です。
もう1つは、そのサイトが自前で持っているセッションです。今回の自社ブログはこちら側で、ブラウザを閉じたらログインし直しになりました。ウィンドウを普通に閉じて（強制終了はしていません）、約25秒後に開き直しても、管理バーは消えていました。
なぜ残るのか、なぜ残らないのかは追っていません。ログイン状態がどこに保存されるかで変わるところなので、どちらも振る舞いだけ書いています。
残らないなら残るようにしたい、と思うところですが、サイト側の認証情報を自分で取り出して保存する方向へは行っていません。保存した時点でそれが流出の対象になりますし、次からは人が一度も通らずに入れてしまうからです。最後の防壁となる人間の手作業が、丸ごと無くなるんですよね。動かしているあいだはブラウザを見ておいて、挙動に違和感があったり、なんかヤバいなと思ったらパスワードを変える、くらいは構えておくといいと思います。
ただ、Google のサインインだけは自分で保存しなくても残ります。人が毎回通るのはサイト側のログインのほうだけで、そのプロファイルは Google に入れる状態のまま置いてある、と思っておいたほうがいいです。
大事なのは、残らなくても認証の切り分けは成立しているということです。見返りは「次から要らなくなる」ではなく、今この1回、人が触るのはログインだけで済むということなんですよね。
じゃあ次は何を渡せるのか
冒頭の問いを回収すると、ログインが要る画面はどうするのか、答えは人が1回入って、その先を渡す、です。
渡せる仕事はまだあります。list_network_requests で通信を、list_console_messages でコンソールを取れるので、「この画面のここが遅い」「エラーが出ていないか」をそのまま調べさせられるんですよね。
ここで使い分けを1つ。開発の現場では、僕は Playwright のほうを使っています。テストを書く場所ですし、同じ手順を何度も回すならコードで持っておくほうが確実なので。入口はPlaywright MCP で始めるブラウザ自動化に書きました。Chrome DevTools MCP が効くのは、日常のちょっとした動作を1回やらせたいときです。わざわざ環境を作るほどではない、でも手でやるのは面倒、くらいの仕事ですね。正直、Windows に Playwright の環境を入れるのが面倒でずっと手が止まっていた、というのも僕の側の事情としてはあります。
反復するならやはり Playwright を書いたほうがいいです。楽なのは着手であって、運用ではないので。
最初の一歩は1つだけです。claude mcp add を1本打って、「自分のブログのトップを開いて、構造を取ってみて」と頼んでみる。テキストが返ってきたら、そこから先は渡せます。
