実際に僕が使っているのは、Gemini Web での画像生成操作だ。Gemini のインターフェースは更新頻度が高くて、セレクタが変わりやすい。固定セレクタで書いたスクリプトは数週間で壊れる。Computer Use はその点、画面を見て「テキスト入力フォームがここにある」と判断するので、UIが多少変わっても動き続ける。

# Claude Code の Computer Use 経由で操作する場合のイメージ
# 実際の処理は claude -p で呼び出す
env = {k: v for k, v in os.environ.items() if k != "ANTHROPIC_API_KEY"}
result = subprocess.run(
    ["claude", "-p", f"Gemini Webを開いて「{prompt}」で画像を生成して保存して"],
    env=env,
    capture_output=True,
    text=True
)

ただし、速度は遅い。1回の操作に数十秒かかる。スクリーンショットを撮って、Claude が解釈して、アクションを決めて、実行する——このループを何回も回すから仕方ない。頻度が高い処理には向かない。

Playwright が向いている場面

Playwright は逆で、「同じ操作を高速・安定して繰り返す」ことが得意だ。

セレクタさえわかれば、ミリ秒単位で動く。ヘッドレスモードなら画面も出ない。launchd でバックグラウンド実行しても安定している。

今のパイプラインだと、note のコメント自動返信と X への投稿で使っている。

# note_comment_reply.py の一部
async def reply_to_comment(page, comment_url, reply_text):
    await page.goto(comment_url)
    await page.wait_for_selector(".commentForm textarea", timeout=10000)
    await page.fill(".commentForm textarea", reply_text)
    await page.click(".commentForm button[type='submit']")
    await page.wait_for_load_state("networkidle")

このスクリプトは engage_launcher.sh から1時間おきに叩かれている。1回あたり5件処理して終了。ヘッドレスで動くので、MacBook が他の作業をしていても邪魔にならない。

セレクタが壊れたときは即死する。これがデメリットだ。note がUI更新したら、セレクタを調べ直して修正する必要がある。壊れるのは月に1〜2回あるかどうかだが、エラーログが来たときに気づく仕組みを作っておかないと投稿がサイレントに止まる。

3段階フォールバックという折衷案

X のモニタリングスクリプト（x_monitor_claudeai.py）で、両方の良いところを使う構成を試した。

async def fetch_tweets(self):
    # 1段階目: X API v2（Bearer Token があれば）
    if self.bearer_token and self.bearer_token != "your_bearer_token_here":
        tweets = await self._fetch_via_api()
        if tweets:
            return tweets

    # 2段階目: Playwright スクレイピング
    tweets = await self._fetch_via_playwright()
    if tweets:
        return tweets

    # 3段階目: モックデータ（開発・テスト用）
    return self._get_mock_tweets()

API が使えるなら API、使えなければ Playwright、それも壊れたらモック——という順序で試す。X API は有料プランが必要で、まだ Bearer Token を取得していない。なので今はほぼ Playwright が動いている。

フォールバック構成のメリットは、「どれかが動けばいい」という余裕が生まれることだ。API の利用規約が変わっても、Playwright が動いていればパイプラインは止まらない。

実測で見えた差

2週間くらい両方を本番で動かしてみた感触をまとめると:

Computer Use は1操作あたり30〜90秒かかる。Playwright は0.5〜3秒。速度は圧倒的に Playwright が速い。

安定性は面白くて、Computer Use の方が長期的には安定していた。Playwright は UI 変更に弱いが、Computer Use は多少の見た目の変化には強い。

コストは Computer Use の方が高い。スクリーンショットのトークン消費が積み上がるので、頻繁に叩く処理には使いたくない。

処理   | Computer Use | Playwright
-------|-------------|------------
速度   | 30〜90秒    | 0.5〜3秒
安定性 | UI変更に強い | セレクタ依存
コスト | 高（トークン）| 低（ほぼ無料）
開発速 | 速い         | セレクタ調査が必要

今の構成でどう使い分けているか

整理すると、こういう判断基準で使い分けている。

「1日何回呼ばれるか」を最初に確認する。launchd で1時間おきに動くなら Playwright 一択だ。Computer Use は費用対効果が悪すぎる。

「セレクタが安定しているか」を次に見る。Gemini のような更新頻度が高いサービスは Computer Use にする。note や X はセレクタが比較的安定しているので Playwright で書く。

「初期実装の速さ」を優先したいなら Computer Use から始めて、後で Playwright に書き直す、という順序もありだった。「どこをクリックすればいいか」を調べる時間を省けるので、プロトタイプ段階では Computer Use が早い。

まとめ

頻度高い・速度が必要・コスト抑えたい → Playwright

UI が複雑・セレクタ不明・更新頻度高いサービス → Computer Use

どちらも使える場面は、まず Playwright で試してみて、壊れるようなら Computer Use に切り替えるのが現実的だと思う。

僕のパイプラインは今、Playwright がメインで Computer Use がサブになっている。Gemini Web の操作だけ Computer Use で、それ以外は全部 Playwright だ。この構成に落ち着くまで、3〜4回は全部書き直した。最初から正解にたどり着いた人はいないんじゃないかと思う。

試して壊して、また直す。それの繰り返し。✨

心理学で、人間関係をちょっとラクにする。

同じことができるのに、なぜ2つあるのか

Claude Code（Computer Use）が向いている場面

Playwright が向いている場面

3段階フォールバックという折衷案

実測で見えた差

今の構成でどう使い分けているか

まとめ

関連記事

心理学で、
人間関係を
ちょっとラクにする。