AdMob の管理画面に深夜0時すぎにログインして、広告ユニットの eCPM が前日比で大きく下がっていないかを確認する——個人開発を続けていると、こういう「見るだけの作業」が地味に時間を取ります。私は2014年からスマートフォンアプリの個人開発を続けていて、累計5,000万ダウンロードを超えた今でも、メディエーションの一覧確認や入札ソースの優先度調整は手動でやっていました。
ブラウザエージェント系のツールがいよいよ実用域に入ってきたと感じたのは、2026年に入ってからです。今回、Gemini Computer Use と Claude in Chrome の両方を1週間、AdMob の同じ管理タスクに向けて並行運用してみました。この記事は、その記録です。どちらが優れているかという結論よりも、「どこに違いが出たか」を残しておきたいと思います。
1週間でやらせた3つのタスク
まず比較の前提を揃えるため、両エージェントに同じタスクを与えました。
ひとつ目は、新規アプリ向けの広告ユニット設定です。バナー・インタースティシャル・リワードの3種類を、命名規則に従って作成する作業を任せました。ふたつ目は、メディエーショングループに含まれている入札ソース（Meta Audience Network・AppLovin・Unity Ads など）の優先度一覧を取得して、CSV に書き出す作業です。3つ目は、過去7日間の eCPM を広告ユニットごとに見て、前週比で30%以上低下している項目を抽出する作業でした。
どれも「クリック数とドラッグ操作の組み合わせ」が必要なタスクで、純粋な API では完結しません。AdMob には Reporting API が用意されていますが、メディエーション設定の取得は API でカバーされない部分が多く、結局ブラウザ操作が必要になります。ここがエージェントの出番だと考えました。
Gemini Computer Use の挙動
Gemini 3.x Pro 系の Computer Use ツールは、Vertex AI 経由で使う形になります。computer_use ツールを宣言してプロンプトを送ると、モデルがスクリーンショットを見ながら座標ベースで操作を提案し、それをエージェント側のランタイム（Playwright や Chrome DevTools Protocol 上のラッパー）で実行する流れです。
実際に使って印象に残ったのは、画面の意味解釈が安定していることです。AdMob のサイドバーの「アプリ」→「広告ユニット」のような階層遷移を、ラベルの位置が変わってもブレずに追従してくれました。広告ユニットの作成画面では「フォーマット」「広告ユニット名」「Frequency capping」のフィールドを、私が日本語で指示しても英語で指示しても、適切に埋められたのが嬉しい誤算でした。
一方で、メディエーションの優先度一覧を CSV に出力させようとすると、テーブルをスクロールしながら少しずつ読み取る挙動になり、20行程度で1回失敗しました。原因は、テーブルが仮想スクロールで描画されている部分があり、スクロールアウトした行が DOM から消えるためです。Computer Use は「見たものから判断する」ため、これは仕組み上の制約です。最終的には「画面に表示されている範囲だけを順に書き出してください」と明示することで、安定して動きました。
eCPM の異常検知タスクでは、レポート画面で日付範囲を「過去7日 vs 前週」に切り替え、「Compare」モードでスクリーンショットを撮らせ、その差分を読み取らせる手順を採用しました。グラフ画像から数値を読み取る精度は十分実用に耐えるレベルで、誤検知は1週間で2件、見落としは0件でした。
Claude in Chrome の挙動
Claude in Chrome は、ブラウザの拡張機能として動くエージェントです。Chrome の拡張権限を使って DOM に直接アクセスできる点が、座標ベースの Computer Use とは構造的に違います。DOM が取れるということは、テーブル要素を element として直接読めるということで、先ほどの仮想スクロール問題はあっさり解決しました。
メディエーション優先度の取得タスクでは、Claude in Chrome が <tr> を辿って一覧を一気に取得し、CSV 形式で結果を返してきました。所要時間は Gemini Computer Use の約半分で、しかも仮想スクロールに引っかかりません。DOM が取れる環境では、明確にこちらの方が速いと感じました。
ただし、AdMob の一部の設定画面では、React が hydration している途中に Claude in Chrome が早く触り始めてしまい、クリックがイベントに紐づかず空振りすることが何度かありました。これは Web アプリ側の挙動による問題で、エージェントの責任ではないのですが、結果として「もう一度試してください」と言わなければならない場面がありました。Computer Use は人間と同じくスクリーンショットを見て進めるため、視覚的にロードが終わるまで待つ傾向があり、この点ではむしろ安定していました。
eCPM の異常検知では、Claude in Chrome は表示中の数値をそのまま DOM から取れるため、グラフ画像を経由せず正確な数字で判定できました。これは大きな利点で、誤検知は1週間で0件でした。
どちらをどう使うかの私なりの結論
1週間使ってみて、私の場合は「DOM が取れる管理画面では Claude in Chrome、それ以外は Gemini Computer Use」という使い分けに落ち着きました。AdMob 単体で見れば Claude in Chrome の方が速度と正確性で勝りますが、AdMob と Firebase Console と App Store Connect を横断する作業を考えると、Computer Use の汎用性が効いてきます。
このあたりは、宮大工だった祖父の道具箱を思い出しました。鉋（かんな）と鋸（のこ）はどちらも木を整えるための道具ですが、使う場面が違うだけで、優劣の問題ではありません。エージェントも同じで、手元のタスクと相手の Web アプリの作りで自然に選び分けるのが現実的だと感じています。
私が16歳のときに独学で HTML を書き始めた1997年、ブラウザは「人間が操作するもの」でした。30年近く経って、ブラウザの中で AI が代わりに動いてくれる時代になったわけですが、その AI に「何を任せて、何を自分で見るか」を決めるのは、結局のところ運営している人間の判断です。エージェントは魔法の杖ではなく、注意深く使い分ければ確実に時間を返してくれる道具だと、1週間運用してあらためて感じました。
次は AppLovin の管理画面と SKAdNetwork のレポート画面で、同じ比較をしてみる予定です。実運用で気づいたことがあれば、また続報を残しておきます。お読みいただきありがとうございました。