こんな新技術が出たらしい
2025年9月某日、Chrome DevTools MCP という面白そうなツールの公開プレビューが開始されました。
ざっくり申しますと、Gemini CLIとかClaude CodeとかCursorとかのAIコーディングアシスタントが、Chromeブラウザを直接操作できるようになるツールなんだとか。
これまでのAIコーディングアシスタントたちは、その名の通り「こんなコード書けばいいよ」とか「このコマンド実行すれば」のような、コードの中、エディタの中の住人でしたよね。
が、そうです、お察しの通り、Chrome DevTools MCPというパワーを手に入れることで、AIコーディングアシスタントたちがブラウザを自身で操作できるのだ！
今までの、Seleniumでの自動操作をAIに日本語であれこれ言うだけで実行してくれると言うイメージがわかりやすいかもしれません。
ざっくり、こんなことができるんだとか。
- パフォーマンス分析情報
- 高度なブラウザデバッグ
- 信頼性の高い自動化
なんとなんと、おもしろそう。血湧き肉躍るので早速試してみました。
実際にやってみた
肝心の「どんなことを試すのか」ですが、
今回は、Gemini CLIからGoogle Cloudのコンソールを操作してみることにしました。
使ったもの
- Chrome DevTools MCP: AIがブラウザ操作するためのサーバー
- Gemini CLI: Googleの対話型AIツール
- Google Cloud: 操作してもらう対象
セットアップ
基本的に、Gemini CLIとChrome DevTools MCPのセットアップは、鬼のように簡単です。
体感3秒で終わります。F1レース並みです。
今回は、簡単にですが、手順を載せておきます。
Gemini CLI
まずは、Gemini CLIのセットアップ。
インストールは以下のコマンドで終わりです。
npm install -g @google/gemini-cli
初回実行時のみ、認証方法を聞かれます。
認証方法は以下の3つ。
- Googleアカウントでログイン
- Gemini APIキーを使用
- Vertex AI（Google Cloud）を使用
今回は、お試しなので、Googleアカウントでログインしました。
モデル利用の無料枠もありますし。おすし。
Chrome DevTools MCP
お次は、Chrome DevTools MCPのセットアップ。
好きなディレクトリに以下のファイルを作成するだけ。
.gemini/settings.json
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": [
"chrome-devtools-mcp@latest",
"--browserUrl=http://localhost:9222"
]
}
}
}
ハマったところ
基本的なセットアップは上述の通りウルトラ簡単だったんですが、一つだけハマりました。
問題：
Google Cloud コンソールへの認証できない
Chrome DevTools MCPが起動するChromeは、セキュリティ上の理由で隔離されたプロファイルで動作するんですが…
これがGoogleアカウントの認証を弾いてしまいます。
悲しいかな、手動で試してみても「ログインできませんでした」というページが表示されます。
うぐ、セキュリティ万全ですね。万歳。
解決方法：
手動でデバッグモード付きのChromeを起動、からの、そこで先にGoogle Cloudにログインしておく
※注意※
つまり、普段使いのアカウントをGeminiに操作させると言うことなので、
この設定で試すことは自己責任でお願いします。
デバッグポート付きでChrome起動
--remote-debugging-port=9222 \
--user-data-dir=/tmp/chrome-debug-mcp
というか、これ以外でなにか良さげなやり方ご存知なら教えてください。
泣いて感謝します。一生、崇め奉ります。
検証1：日本語でCloud Run作ってもらう
まずは正攻法な、人間の言葉でお願いしてみました。
プロンプト：
ブラウザのGoogle CloudコンソールからCloud Run サービスをデモコンテナを使用して作成してください。
gcloudなどのコマンドは一切使用しないこと。
結果：
百聞は一見にしかず。
一見したとて、すこしイメージし辛いと思いますが…、上記の動画の動作、全て自動で行なっています。
ボタンのクリック、リソース名の入力、オプションの選択などですね。
ちなみに、Gemini CLI上では以下のようなログをタスクを達成するまで、延々と頑張ってくれます。
✦ Cloud Runの「サービスの作成」ページに移動できました。これは大きな進歩です。次に、デモコンテナの選択を含むサービスの詳細を
入力する必要があります。利用可能な要素を確認するためにスナップショットを撮ります。
╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ take_snapshot (chrome-devtools MCP Server) {} │
│ │
│ ... first 36 lines hidden ... │
│ uid=5_33 link "ワーカープール、5/4" │
│ uid=5_34 StaticText "ワーカープール" │
│ uid=5_35 link "ドメイン マッピング、5/5" │
│ uid=5_36 StaticText "ドメイン マッピング" │
│ uid=5_37 button "Cloud Run リリースノートを確認" │
│ uid=5_38 button "Cloud Run のナビゲーション メニューを切り替える" description="Cloud Run ナビゲーション │
│ メニューを非表示（視覚的な変更のみ）" pressed pressed="true" │
│ uid=5_39 link "サービスリスト ページに戻る" │
│ uid=5_40 heading "サービスの作成" level="1" │
│ uid=5_41 button "コマンドラインを表示" │
│ uid=5_42 StaticText │
│ "サービスは固有のエンドポイントを公開し、受信リクエストを処理するため、基盤となるインフラストラクチャを自動 │
│ 的にスケールします。サービス名とリージョンは後で変更できません。" │
│ uid=5_43 StaticText "Artifact Registry" │
│ uid=5_44 StaticText "Docker Hub" │
│ uid=5_45 radio "既存のコンテナ イメージから 1 つのリビジョンをデプロイする" checked checked="true" │
│ uid=5_46 StaticText "GitHub" │
│ uid=5_47 radio "リポジトリから継続的にデプロイする（ソースまたは関数）" checked │
│ uid=5_48 StaticText "Functions" │
│ uid=5_49 radio "インライン エディタで関数を作成する" checked │
│ uid=5_50 StaticText "コンテナ イメージの URL" │
│ uid=5_51 textbox "コンテナ イメージの URL" description="サンプル コンテナでテスト $PORT（デフォルト: │
│ 8080）で HTTP リクエストをリッスンし、ローカル状態に依存しないでください。 コンテナの構築方法 │
│ 外部の新しいウィンドウが開きます" │
│ uid=5_52 button "選択" │
│ uid=5_53 button "サンプル コンテナでテスト" │
│ uid=5_54 LineBreak " │
│ " │
│ uid=5_55 StaticText "$PORT" │
│ uid=5_56 StaticText "（デフォルト: 8080）で HTTP │
│ リクエストをリッスンし、ローカル状態に依存しないでください。" │
│ uid=5_57 link "コンテナの構築方法 外部の新しいウィンドウが開きます" │
│ uid=5_58 StaticText "コンテナの構築方法" │
│ uid=5_59 image "外部の新しいウィンドウが開きます" │
│ uid=5_60 heading "構成" level="2" │
...
✦ 「サービスの作成」ページにいます。以下の手順を実行します。
1. デモコンテナを選択: 「サンプル コンテナでテスト」（uid=5_53）というボタンがあるので、これをクリックします。
2. サービス名を入力: 「サービス の名前」（uid=5_62）というテキストボックスに「my-demo-service」と入力します。
3. リージョンを選択: 「リージョン」（uid=5_64）はデフォルトの「europe-west1 (ベルギー)」のままにします。
4. 「作成」をクリック: 「作成」（uid=5_125）ボタンをクリックします。
まず、「サンプル コンテナでテスト」（uid=5_53）をクリックします。
╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ ✓ click (chrome-devtools MCP Server) {"uid":"5_53"} │
│ │
│ ... first 38 lines hidden ... │
│ uid=6_34 StaticText "ワーカープール" │
│ uid=6_35 link "ドメイン マッピング、5/5" │
│ uid=6_36 StaticText "ドメイン マッピング" │
│ uid=6_37 button "Cloud Run リリースノートを確認" │
│ uid=6_38 button "Cloud Run のナビゲーション メニューを切り替える" description="Cloud Run ナビゲーション │
│ メニューを非表示（視覚的な変更のみ）" pressed pressed="true" │
│ uid=6_39 link "サービスリスト ページに戻る" │
│ uid=6_40 heading "サービスの作成" level="1" │
│ uid=6_41 button "コマンドラインを表示" │
│ uid=6_42 StaticText │
│ "サービスは固有のエンドポイントを公開し、受信リクエストを処理するため、基盤となるインフラストラクチャを自動 │
│ 的にスケールします。サービス名とリージョンは後で変更できません。" │
│ uid=6_43 StaticText "Artifact Registry" │
│ uid=6_44 StaticText "Docker Hub" │
│ uid=6_45 radio "既存のコンテナ イメージから 1 つのリビジョンをデプロイする" checked checked="true" │
│ uid=6_46 StaticText "GitHub" │
│ uid=6_47 radio "リポジトリから継続的にデプロイする（ソースまたは関数）" checked │
│ uid=6_48 StaticText "Functions" │
│ uid=6_49 radio "インライン エディタで関数を作成する" checked │
│ uid=6_50 StaticText "コンテナ イメージの URL" │
│ uid=6_51 textbox "コンテナ イメージの URL" value="us-docker.pkg.dev/cloudrun/container/hello" │
│ description="サンプル コンテナでテスト $PORT（デフォルト: 8080）で HTTP │
│ リクエストをリッスンし、ローカル状態に依存しないでください。 コンテナの構築方法 │
│ 外部の新しいウィンドウが開きます" │
│ uid=6_52 button "選択" │
│ uid=6_53 button "サンプル コンテナでテスト" focusable focused │
│ uid=6_54 LineBreak " │
│ " │
│ uid=6_55 StaticText "$PORT" │
│ uid=6_56 StaticText "（デフォルト: 8080）で HTTP │
│ リクエストをリッスンし、ローカル状態に依存しないでください。" │
...
ログを見たままですが、
スナップショット（HTMLの要素/スクショ）を取得し、「さて、そこから何しようかな」ということを繰り返してくれるため、
ちょくちょく思考の時間が発生します。
しかし、専門用語とか設定パラメータとか全然指定してない、ゆるゆるすぎる指示ですが…
Geminiが「あー、なる、こういうことがしたいんだな」と理解して、いい感じに設定してくれます。多謝。
検証2：公式ドキュメント通りにCloud Storage作ってもらう
基本的な操作がらくらくできることが分かったので、今度はもう一つ気になったことを試してみました。
最近、ドキュメント駆動開発が盛り上がってますし、エンジニア界隈でこんな会話が日夜行われていませんか。
- 「これからはAIがドキュメント読んで作業する時代」
- 「手順書の品質が直接生産性に影響する」
- 「AIが理解できるドキュメントが重要」
ドキュメント！ドキュメント！ドキュメント！ということで、
Google Cloud公式ドキュメントを渡して「この通りにやって」って言ったらどうなるか試してみました。
先ほどの、ゆる雑指示よりも遥かに細かくステップなどの記載があるので、成功待った無し！ですが…
プロンプト：
以下の操作してください。
https://cloud.google.com/storage/docs/creating-buckets?hl=ja#console
結果：
やっぱり、百聞は一見にしかず。
こちらも、検証1と同様、上記の動画の動作、全て自動で行なっています。
はい。やっぱり、お察しの通りできました。
これ、ブラウザを介したシステムテストなどもテスト仕様書渡して、やってくれるのでは………！
ということで、やはりドキュメント諸々も「人間向け」から「AI向け」に書く時代に突入していくんですね。
曖昧な表現や「いい感じに設定」みたいな暗黙の前提はNO！
AIが迷わないレベルの明確さが求められるってことですね。新時代だ。
使ってみた感想
改めて冷静に考えると、「CLIからブラウザを日本語で操作できる」時代って映画すぎませんか。
あとは、これ、正直、Cursorからも繋げてみたい気がむんむんしてます。
え、フロントエンドのコード書く時に、
スクショわざわざ貼らなくてもいいかもしれないかもしれないかもしれない。
パフォーマンスのデータを渡して…、ということもわざわざやらなくてもいいかもしれないかもしれないかもしれない。
他試したことの中で、Google Cloudの利用料金の分析などもやってもらいましたが、
もっとプロンプトやフローを作り込むと様々な人の幸せに繋がる予感がありました。
また、最初にも記述した通り、現時点でChrome DevTools MCPは、公開プレビュー版です。ご注意くださいませ！
とはいえ、どんどんいけいけGOGOでChromeを操作しまくってやりましょう！
Views: 0
