Chrome DevTools (MCP) がパブリックプレビューだった頃から、自分のアプリ事業のサイト側のチューニングや、Antigravity から動かしている拡張機能の動作確認に少しずつ使ってきました。2026 年 5 月 19 日に Chrome DevTools for agents 1.0 として安定版に格上げされ、Antigravity 2.0 にバンドルされたタイミングで、自分の運用全体を一度組み替えました。
ここでは、累計 5,000 万ダウンロードを超える壁紙系・癒し系アプリの事業を 2014 年から個人で続けてきた立場から、Antigravity 2.0 と Chrome DevTools for agents をどう接続し、Lighthouse 監査・拡張機能のデバッグ・メモリ分析・自動接続をどんな運用ルールで回しているかを残しておきます。「動く状態を一気通貫で作る道具」としての側面と、「人間が判断を残すべき場所」の境目をどう設計したかが中心です。
何が「安定版」になったのか：MCP 同居の正味の変化
プレビュー期から触っていた方には繰り返しになりますが、要点だけ整理します。
名前が Chrome DevTools (MCP) から Chrome DevTools for agents 1.0 に変わりました
インストール経路は npm 単体、Antigravity 2.0 にバンドル、Gemini CLI / Claude Code の内部コマンド導入、の三系統
エージェント向けの Lighthouse 監査 が公式 API として固まり、レポートをそのまま JSON で受け取れるようになりました
メモリ分析 専用ツールが追加され、メモリリークの検出と特定までエージェント側で完結します自動接続 で、既に開いているブラウザインスタンスにエージェントを乗り入れさせる挙動が安定しましたWebMCP プロトコルが拡張され、ページ上の JavaScript が露出したツールと直接やりとりできるようになりました
プレビュー時代に一番不安定だったのは「Lighthouse 監査の途中でセッションが落ちる」「自動接続後に拡張機能のホットリロードが効かない」あたりで、1.0 でようやくその辺りが安心して任せられるようになりました。runningLightSpeed: fast を有効にした状態でも、レポートの取り回しで止まることがほぼ無くなった印象です。
接続経路を 3 つだけに絞る：npm / Antigravity 2.0 / Claude Code
接続経路を散らかすと、後で「どこから繋いだやつだっけ」とエージェントが迷子になります。私の運用では次の 3 つにだけ寄せました。
1. Antigravity 2.0 内蔵経路（GUI 寄りの作業）
Antigravity 2.0 を起動して agy を立てると、Chrome DevTools for agents は既に MCP サーバーとして登録された状態で見えます。/mcp を叩いて状態確認、/skills で公開されているエージェントスキル（アクセシビリティ監査、パフォーマンス監査など）を確認、/permissions を request-review のままにしてから、まず一度ブラウザ起動を伴う簡単なタスク（後述）を流すのが落ち着いた手順です。
# 単発でブラウザ操作を任せるサニティチェック agy run "open https://example.com, run a quick accessibility scan, summarise the top three issues" 2. Claude Code 経路（コーディング寄りの作業）
Claude Code から繋ぐ場合は、内部コマンドで一発です。
claude mcp install chrome-devtools-for-agents claude mcp ls Claude Code のスキル経由でこの MCP を呼ぶ運用が、私には一番合っていました。アプリ側のフロント実装をいじりながら、レンダリング結果をエージェントに見させる前提のループを作りやすいからです。
3. npm 直接導入（CI 統合・スクリプト経路）
CI から呼びたい場合は npm で単体導入します。
npm install -g @google/chrome-devtools-for-agents chrome-devtools-for-agents --version 私の場合、AdMob 周りの実装変更を本番リリースする前のスモークテストで、Lighthouse のスコアと Web Vitals を CI で取り、しきい値割れを検出したらエージェントに分析させる、というラインだけここに乗せています。
Lighthouse 監査をエージェントに任せる：何を渡し、何を判断させるか
Lighthouse 自体は前からあったので、エージェントに任せて得られる本当の付加価値は「しきい値割れに対する原因仮説を、コードベースの文脈と組み合わせて出してくる 」点にあります。これを生かせる設定がコツです。
しきい値テーブルを最初に渡す
私が用意しているのは、サイト種別ごとの最低ラインをまとめた JSON です。アプリのランディングページとブログ系で重みが違うので、エージェントに「どの軸を優先するか」を最初に渡しておきます。
{ "landing" : { "performance" : 0.85 , "accessibility" : 0.95 , "best-practices" : 0.95 , "seo" : 0.95 , "lcp_ms" : 2500 , "cls" : 0.1 }, "blog" : { "performance" : 0.75 , "accessibility" : 0.95 , "lcp_ms" : 3500 , "cls" : 0.1 } } 監査をプロンプトで呼ぶときのテンプレート
エージェントへの依頼は、判断軸を含めて短く渡すと結果が読みやすくなります。
Run a Lighthouse audit against {{URL}} with the "{{profile}}" threshold table.
If any axis is below the floor, identify the top 3 likely root causes
based on the actual rendered HTML and the network waterfall, and propose
the smallest change set that brings each axis back above the floor.
Do not propose framework changes.
最後の "Do not propose framework changes" は、AI に任せると一足飛びにフレームワークやレンダリング方式の総入れ替えを提案してきがちなので、自分の運用では明示的に封じています。1997 年に独学で HTML を書き始めて、宮大工だった両祖父の影響もあってか、「土台を一度に替えない」癖が強いタイプです。土台を替えるかどうかは人間が決めます。
数字の読み方を 1 つだけ
LCP は監査一発で見るより、デバイスエミュレーションを変えて 2〜3 回回し、ばらつきの分布を見るほうが本番に近い感触になります。emulation: { device: "moto-g-power" } を Antigravity 2.0 のジョブ設定に入れておくと、私のアプリ事業のターゲット端末層に近い実測値が出ます。
デバイス・位置情報・ネットワークのエミュレーションを CI に組み込む
エージェント側からのエミュレーション制御が安定したので、CI でも実用になりました。私が組んでいる「リリース前の 30 秒スモーク」は次のような感じです。
# .github/workflows/web-vitals-smoke.yml （抜粋） - name : Vitals smoke (mobile / Tokyo / Slow 4G) run : | chrome-devtools-for-agents emulate \ --device "moto-g-power" \ --geo "tokyo" \ --network "slow-4g" \ --capture vitals.json https://example.com - name : Hand off to agent for triage run : | agy run "@vitals.json: triage regressions against thresholds.json; \ open a GitHub issue per regression with the smallest patch suggestion" ここで重要なのは、エージェントに直接 PR を作らせない ことです。Issue 起票までで止めて、本人がコードを見て決める。これも宮大工の祖父の影響かもしれませんが、刻みは機械でも、組むのは人間という感覚で運用しています。
拡張機能の開発・デバッグをエージェント側に寄せる
1.0 で個人的に一番ありがたかったのは 拡張機能の操作 です。インストール・再読み込み・アクションのトリガーまでエージェントから走るようになり、私が使っている自作の AdMob デバッグ用拡張機能のリグレッションテストが楽になりました。
拡張機能テストのプロンプト構造
Load the unpacked extension at ./dist/, click the toolbar action,
verify the popup shows the latest "test-ad" entry, then reload the
extension and confirm the badge resets. Capture screenshots before
and after each step.
このスクリーンショット指示が地味に効きます。エージェントは状態遷移を文字で説明したがるのですが、拡張機能の不具合の 7 割は描画タイミングの不一致 なので、画像をエビデンスに残す方が後で見返しやすいのです。Antigravity 2.0 の artifacts パネルに残せば、/fork で別の仮説を試すときに比較が一瞬で済みます。
よくつまずく点と回避策
症状 私が踏んだ原因 回避策
アクションを叩いてもポップアップが出ない service_worker が休眠していて起動に時間がかかるプロンプト先頭で wait until service worker is alive (max 3s) を明示 再読み込み後にバッジが更新されない 同じタブのストレージが古い --clear-extension-storage を有効にしたエミュレーション設定で実行認証が必要なサイトで拡張機能が動かない デフォルトは新規ブラウザインスタンスで認証が引き継がれない 自動接続 で既存ブラウザに乗り入れさせる
自動接続を使うべきとき・使ってはいけないとき
自動接続は便利ですが、運用を間違えると本人のブラウザ環境を巻き込みます。私は以下の基準で使い分けています。
使う ：
認証が必要なダッシュボードや管理画面のデバッグ（AdMob 管理画面、App Store Connect、Search Console など）
拡張機能のリアル端末風挙動の確認
セッション付き API のフロント側の見え方を確認したいとき
使わない ：
Lighthouse の基本スコア取得（個人ブラウザの拡張機能や Cookie がノイズになる）
競合サイトの調査（自分のクッキーが混入する事故が起きやすい）
リリース前スモーク（再現性を CI 環境に閉じたい）
Antigravity 2.0 の設定で、自動接続用の専用プロファイル を permissions.allow 側に登録しておくと、誤って普段使いブラウザに乗り入れる事故を減らせます。私は --profile chrome-agent-only を必ず付けるルールにしました。
メモリリーク追跡：エージェントに任せられる範囲と限界
メモリ分析ツールはとても便利ですが、ここは「ヒントを取りに行く道具 」として運用しています。具体的なリークの原因特定は最終的に人間がやる。これは、累計 5,000 万ダウンロード規模の壁紙アプリで、メモリ問題を AdMob の初期化順序のせいで踏んだことが何度かあって、原因の真の在り処は機械が見えにくい領域にあることが多かった経験から来ています。
私が使っているプロンプトテンプレート
Open {{URL}}, perform 50 cycles of {{user_action}}, then run the memory
analysis tool. Compare retained sizes between snapshots N=10 and N=50.
Surface the top 5 detached DOM nodes and their constructors. Do not
attempt a fix; produce a hypothesis report with evidence anchored to
the snapshots.
「直そうとしないで、仮説と根拠だけ出して」と明示的に書くのがポイントです。エージェントは仮説のまま止まるのが苦手で、勝手にコードを書き換えに行きがちです。
体感での効きどころ
DOM ノードのリーク：エージェント側の検出精度が非常に高い。私の場合、3 件中 3 件本物
イベントリスナーの剥がし忘れ：半々の精度。addEventListener の文字列検索と合わせて判定する
WebGL コンテキストのロスト：ほぼ判別不能。これは人間が WEBGL_lose_context を疑う
エージェントのレベル設計を Chrome DevTools 側にも反映する
Antigravity 2.0 の /permissions には 3 段階の自律レベルがありますが、Chrome DevTools for agents をつないだ瞬間、「ブラウザ上での操作」が一気に増えます。ここの権限を一括で always-proceed にすると、誤クリックで本番ダッシュボードのトグルが切り替わる事故が起きるので、私は次の三軸で見直しました。
読み取り系 （DOM 取得、Lighthouse 監査、メモリ計測）→ always-proceed書き込み系 （フォーム入力、拡張機能のリロード）→ request-review危険操作 （自動接続による既存セッションでのクリック、ストレージ書換）→ strict
この三層は、私の Android アプリのリリースフローで使っている「読み取りエージェント」「書き込みエージェント」「リリースエージェント」のレイヤと、ほぼ同じ構造にしました。手元の運用と頭の中の判断軸が揃うと、後で別プロジェクトに同じ設計を持ち込みやすくなります。
個人開発に組み込むときの落とし所
最後に、累計 5,000 万ダウンロードの事業を一人で回している立場で、無理なく続く運用ラインを書いておきます。
Chrome DevTools for agents の 読み取り系 はほぼ自動運用に寄せていい
書き込み系 は必ず request-review を残す。スピードよりも誤操作の安心代を優先するLighthouse は CI の中で回し、人間は「しきい値割れだけ見る」フローにする
拡張機能のリグレッションは、画像エビデンスを artifacts に必ず残す
自動接続用のプロファイルを分離します。普段のブラウザは絶対に混ぜない
メモリ分析は「仮説生成ツール」と割り切る。最終判断は人間
2019 年の晩秋に吉祥寺駅の上空で見た光の輪の体験以来、自分は「直感が確信に変わる瞬間」を作品制作の核にしてきました。技術側の運用にも同じ感覚があって、エージェントに何を任せ何を残すかは、最終的には「自分が読んで納得できる粒度かどうか」で決まると感じています。Chrome DevTools for agents 1.0 は、その納得感を保てる粒度の道具に育ったと思っています。
CLI 単体の感触をまだ掴んでいない方は、先に agy の入門記事のほうから入ると、ここで書いた運用設計がスムーズに繋がります。