ども！Chrome DevTools MCP でブラウザを触らせる話を続けて書いている龍ちゃんです。 先日、 Chrome DevTools MCP でのセットアップとログインの通し方 を書きました。あそこまで終われば、あとは普段どおりブラウザを触るだけです。その続きを触っていて、ふと思ったんですよね。これ、マニュアル作りにも使えるんじゃないの？って。 今回はそこだけ切り出して試した回です。マニュアルの本文を書かせる話や、書いた本文を仕上げるところまでは別問題なので、ここでは扱いません。 マニュアルで貼る図の手間を少し軽くする 話です。 手順書のスクショ、撮った後の手間がわりと重かった 手順書やマニュアルを作るときのいつもの流れって、大体こうですよね。 手順ごとに画面を出してスクショを撮る 画像編集ソフトで枠や矢印を描き足す PNG として保存して、名前を付ける 数えると3手です。しかも手順の数だけ、これを繰り返すことになります。 複数の対象を1枚で示したいときは、ここにもう一手増えます。①②③の番号を、ひとつずつ位置を決めながら打ち込む作業です。上の3手には数えていませんが、対象の数だけ確実に増えていく作業で、地味に手間がかかっていたところでした。 今回やったのは、この3手と番号の位置決めをまるごと「この欄を①、この欄を②、このボタンを③で囲って撮って」の一言に畳めるかという話です。画面を出すところは人が普段どおり操作するので数に入れていません。そこはどちらのやり方でも同じですからね。 結論として以下のような図がプロンプトだけで作れます。渡した指示の中身はこのあと説明しますが、まずは出てきた結果からです。 入力欄2つとボタン、合わせて3箇所を一言で囲んで、番号まで振ってもらえました。 どう指示したら、枠つきの1枚が出てくるのか 例に使うのは自分で作っているアプリの画面です。Azure上に公開しているのでブラウザ経由でアクセスを行います。 指示は2段に分けています。ひとつは自分のアプリでしか通じない指定、もうひとつはどの画面でも変わらない骨組みです。 まずアプリ側の指定です。ここは読んでいる人が自分のものに差し替えるところですね。 開く画面: Azure に置いた自作アプリ（フォーム画面 / 一覧画面） 対象の呼び名: 「タイトル」「ジム」— 画面に出ている文字でそのまま指す ここから先は、どの画面に対しても同じ骨組みです。対象を枠で囲むだけの、シンプルなものです。 1. 対象のタブを決めて、前面に出す 2. ウィンドウの寸法を固定する（1400x900） 3. 対象を囲む枠を、重ねたレイヤーとして1枚描く - 対象そのものの style / outline / border には触らない - 枠は viewport 座標で描く（描いてから撮るまでにスクロールしない） 4. 撮る 5. 枠のレイヤーを消す この骨組みで一番効いているのは、 元の画面を動かさないこと です。対象の border を直接書き換えると、その分だけ幅が増えてレイアウトが動きます。撮りたいのは普段どおりの画面なので、枠を足したせいで並びが変わったら元も子もないんですよね。なので枠は、画面の上に透明なレイヤーを1枚かぶせて、そこに描いています。消すときもレイヤーごと外すだけなので、消し忘れも起きにくい作りです。 枠がうまく出ないときは、この「元の画面に触らない」が守られているかを先に見てもらうのが早いです。 なお、ここに載せたのは骨組みだけです。実際に保存したものは初版で227行あって、枠の座標や番号の置き場を詰めるところが長い部分です。これだけを貼っても、同じ絵までは出ません。 人が言うのは1行で、長い部分はぜんぶあちら側にあります。 Chrome DevTools MCP そのものの細かい仕様は、 公式ドキュメント に譲ります。 この骨組みだけで、どこまで通るか試しました。まずは入力欄が空のフォームです。 この1枚は、対話で組み立てながら撮った回です。「タイトルの欄を囲って」と指しては、出てきた枠を見て直して、を何度か繰り返しています。一言で撃てるようになったのは、このあとですね。 さらに、フォームとはまったく性質の違う画面でも試しました。一覧に並んだカードを1枚だけ囲うパターンです。 こちらで言ったのは、これだけです。 ジムのカードを囲って撮って 対話で作った指示を、追加なしで撃っただけです。入力欄でもカードでも、同じ指示で枠が出てきました。 番号や矢印の位置、どこまで指示で決められるのか 位置や見た目まで指示で決められるのか、実際に試したのがここからです。 複数の対象を1枚で示すとき、番号バッジをどこに置くかって、直感的には二択ですよね。対象の上に重ねるか、対象の外に出して引き出すか。まずはこの2つを試しました。 試しに実験を行いました。実際に投げた言葉はこうです。 フォーム: キッカーを①、タイトルを②、生成ボタンを③で囲って撮って 一覧　　: オーロラを①、ブログを②、ジムを③で囲って撮って 番号の置き場（このときは指示の側で決め打ちにしていた）: A 対象に重ねる（枠の左上） B 対象の外に出して引き出す（枠の外・左右は自動で反転） 言った順が、そのまま①②③になります。手順書の番号は手順そのものなので、並べ替えは機械に任せていません。 重ねる案は、対象の中の文字を潰しました。①のバッジが HOW TO の頭を隠して IOW TO に見えてしまいます。 外に出す案は、フォームなら読めましたが、一覧では壊れました。カードの隙間は隣どうしの共有スペースなので、番号バッジが隣のカードの枠に乗ってしまい、どちらの番号なのか読めなくなります。 どちらも、置き場を「対象に重ねる（左上）」「外に出して引き出す」と決め打ちで指示に書いていたのが敗因です。そこで指示を書き換えました。 6通りの置き方を試し、「バッジが文字を覆う面積 ＋ 別の対象の枠やバッジに乗る面積 × 4」が 最小のものを選ぶ。0 になった時点で打ち切る。 置き場を決めずに、「どう選ぶか」だけを書いたわけですね。置き場を探す仕事のほうを機械に渡して、人は「何を避けたいか」だけを書く、という分担です。 結果、フォームでは右上、一覧では左上が選ばれました。どちらも覆った文字は0件です。さっき見てもらったフォームの絵は、この右上に置かれた番号だったんですね。同じ考え方で一覧に撃ったのがこちらです。 同じ指示のはずなのに、置き場が変わっているわけですね。とはいえ賢いのは機械側ではなくて、「どこに置くか」を決めずに「どう選ぶか」を書いた指示のほうです。置き場を固定して渡していたら、さっきの没案2枚のどちらかが出てきていました。 もちろん、同じ画面で毎回まったく同じ位置に出したいなら、置き場を指定してしまうほうが早いです。一度撮って位置が決まっているなら、それで足ります。壊れたのは、確かめないまま固定を別の画面へ持ち回ったときでした。 番号に加えて、矢印も同じ指示の中で足せました。上の発話に「③に矢印も」と一言足すだけです。 更新のたびに、同じ絵を撮り直せるのか 指示は最初から書き上げたわけではなくて、チャットで一緒に試しながら詰めていったんですよね。狙った枠や番号が出るまでやり取りを重ねて、固まったところでそのプロンプトを書き出して保存しておいた、という順番です。Chrome も Claude Code のセッションも立ち上げ直してから、保存したその指示をもう一度撃ってみました。出てきたのは同じ絵です。番号と矢印まで入れた絵も、当て直して撮り直せば同じものが出てきます。 ただ、機械で確かめられるのは、画面上に文字として存在しているものだけです。背景画像に焼き込まれた文字までは判定できないので、番号がそこに乗っていないかは、最後は自分の目で見て確認しています。 機械が見えている範囲と見えていない範囲を、図にするとこんな境目になります。AI側に画像を読み込ませて判断することも可能ではあるんですが、違和感を見つけるのは人間のほうが早いので人間をループに組み込んだほうが早いです。 もちろん、画面のほうが変わったら指示も直すことになります。欄が増えたり並びが変わったりすれば、囲む対象を言い直すわけですね。ここはマニュアルを更新するときに本文を直すのと同じで、 直す対象に指示が1つ加わる という話です。 で、自分の仕事のどこで使えるのか まとめると、手順書用のスクショで一番手間だった「撮った後に枠と番号を入れ直す」ところが、プロンプトに畳まりました。冒頭で「マニュアル作りにも使えるんじゃないの」って思ったところ、番号や矢印まで含めて使えるところまでは確認できた、という結果です。 割り切ったところも書いておきます。押した瞬間の画面はこの撮り方では取れません。ボタンを押した直後に出る完了表示みたいな、寿命の短い表示は間に合いません。逆に手順書が欲しい絵って「これから押す場所」なので、押す前に撃つ形とは相性がいいです。 なので、そういった瞬間的な表示とかに関しては「Playwright」か「画面録画」で切り出すのが楽かなって思います。 あと、配れるコマンドの形にはしていません。使うなら、上の骨組みを下敷きに自分の対象サイト向けの指示を書いて、狙った絵が出るまで詰めて、サイトごとに専用のプロンプトファイルとして保存しておく形になります。僕がやったのもその順番でした。 まずは自分がよく撮る画面1つで、「この欄を①で囲って撮って」って言ってみるところから試してみてください。 ではまた！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Chrome DevTools MCPで学ぶ、手順書用スクショの枠・番号自動化 first appeared on SIOS Tech Lab .

はじめに 株式会社 mediba でフロントエンドエンジニアをしている中畑です。 弊社では Nuxt.js から Next.js への技術リプレイスプロジェクトが進行中です。この記事では、 Claude Code を活用した技術リプレイスの現状と課題をお伝えします。 ! 要約 ハーネス(ルール・コンテキスト・フィードバック・スキル)を整備し、開発フローをスキル化して Claude Code による技術リプレイスを進めている 移植精度の向上や高速化、属人化の防止というメリットがある一方、技術負債の移植や開発者の「理解負債」というデメリットが生じている 現行システムに実際に触れる、モッ

もう入っている 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本打って、「自分のブログのトップを開いて、構造を取ってみて」と頼んでみる。テキストが返ってきたら、そこから先は渡せます。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Chrome DevTools MCP を Windows に入れる。ログインだけ人がやる first appeared on SIOS Tech Lab .