オイオイオイ書くわアイツ

ほうクソブログですか……たいしたものですね

AI にブラウザを操作させるの、楽しすぎ!!😄😄😄

はじめに

人工知能に仕事を任せる人のイラスト

人工知能に仕事を任せる人のイラスト」とかいうドンピシャの画像あってウケました。

人工知能に仕事を任せる人のイラスト | かわいいフリー素材集 いらすとや

AI 様とブラウザ

AI 様がパソコンを操作できると色々自動化できそうッスねという話がある。AGI とかいうカッケー呼び方もされている。
「パソコンを操作」とまでは行かずとも、個別のアプリケーションに対する操作を許されるだけも便利そう。特にブラウザ。
ブラウザ操作できればブラウザの上で動く Web アプリケーションも操作できる。強そうじゃないですか。
で、昨今 AI 様はブラウザを操作できるようになってきている。

browser-use が流行った

AI 様のブラウザ操作として最近(2024年後半くらい)browser-use が話題になった。
こいつは Playwright を基にして AI 様にブラウザ操作能力を与えている。「よしなに」力の高いプロンプトも詰まっている。
Playwright がバカ使いやすい影響もあってか、browser-use も結構イケるらしい。

github.com

browser-use を試す俺の動機

俺は業務で Web アプリケーションを作ったり Playwright を使ったりしている。
趣味で AI 様に LoL の負け試合の責任者を画像判定していただりもしている。
なんで、browser-use のお試しを通して AI 様と Web アプリケーションの関係性に想いを馳せると楽しそう。
そういう謎の自由研究を業務時間でやって良いと俺は思っており、業務時間が楽しいと得なんで、やる。

前提

そもそも browser-use はどのように使うんか

browser-use の利用はメチャ簡単。
Python 環境を用意して、下のようなコードを書くとサクッと動く。

from langchain_aws import ChatBedrock
from browser_use import Agent, Browser
from browser_use.browser.context import BrowserContextConfig
import asyncio


# ここら辺はよしなにやる
llm = ChatBedrock(
    model_id="anthropic.claude-3-sonnet-20240229-v1:0",
    model_kwargs=dict(temperature=0),
    region_name="us-east-1",
)

URL = ""

async def main():
    browser = Browser()
    async with await browser.new_context(
        config=BrowserContextConfig(
            cookies_file="", # 配列形式の JSON ファイルでテスト環境にアクセスするための権限情報を渡している
            browser_window_size={"width": 1920, "height": 1920},
            trace_path="./traces",
        )
    ) as context:
        agent = Agent(
            task = f"""""", # ここで AI 様にお願い申し上げる
            llm=llm,
            browser_context=context,
            use_vision=True,
            save_conversation_path="logs/conversation.json"
        )
        result = await agent.run()
    await browser.close()
    print(result)

asyncio.run(main())

browser-use が使うブラウザに対して認証情報を渡す部分( cookies_file のところ )は browser-use の example に詳しい。
task の中身によって動作が変わるよ、というのが本題。
なんで、以降は基本的に task の中身について言及していく。(つまり、わざわざコード全文を貼りたくない。)

Web アプリケーションの動作確認(俺の普段の業務)を実際に AI 様にお願いしてみる

弊社様のアプリケーションの機能紹介

俺は普段弊社様のアプリケーションをたくさん触る仕事をしている。
browser-use でこの仕事を自動化できないもんかと試したい。
が、弊社様のアプリケーションなんか人々は知らんと思う。「Google 検索を自動化してみましょう😄」とは全然話が違う。
なんで、代表的なアプリケーションである HERP Hire から、使用方法のわかりやすい以下の 2 つの機能を紹介しておく:

  • タイムライン機能
  • 評価依頼機能

採用業務、と聞くと「なんか面接とかしてその結果についてワヤワヤ社内でおしゃべりして是非を決める」みたいなやつが思い浮かぶ。
ざっくりいうと、タイムライン機能は ワヤワヤ社内でおしゃべりする ために、評価依頼機能は 是非を決める ために使う。

タイムライン機能

HERP Hire ではワヤワヤおしゃべりを各応募ごとにまとめられるようになっている。
A さんに関するおしゃべりは B さんの画面では出てこない。
下の画像では vu7or-1 という名前のテスト用の応募者を(テスト環境に)作り*1、その画面をスクショした。
ほんで、ここに「コメント入力」して「送信」すると、文章が永続化され、この画面を閲覧できる人々に内容が共有される。
送信したタイミングでメールなりなんなりで各ユーザーに通知が飛ぶなどの便利もある。
てかまあ Slack のチャンネルみたいなやつが応募者ごとに建てられるということです。

タイムライン機能を用いて応募者への所感を永続化する様子

評価依頼機能

ワヤワヤおしゃべりの後に構造化された方法で応募者に評価を下し、採用・非採用など決めます、というのが一般的な採用の流れっス。
全員が同じ形式で評価を出してくれる方が

  • 採用側は業務を進めやすい
  • 応募者側も公平な評価を受けやすい*2

などの良さがある。
そのような良さを醸すための機能が評価依頼機能や。

下の画像の様に、評価の形式を前もって定めておき(左)、その形式に則って評価を入力し(真ん中)、評価を共有できる(右)。
便利っすね。

評価依頼機能の簡単な利用例

動作確認(の自動化)のつらみ

で、俺は普段「開発中のアプリケーションの新バージョンにおいて "基本的な機能が壊れていないこと" を確かめてください!」などと言われている。
"基本的な機能" とは上の 2 つのような「大多数のユーザーの採用業務に必要な機能」のことで、上の 2 つ以外にもたくさんある。
原始的に "基本的な機能が壊れていないこと" を確かめ るには、ブラウザをポチポチしてアプリケーションを動かしてみると良い。
俺は毎日泣きながらブラウザをポチポチしている。これは嘘で、ブラウザのポチポチを Playwright で自動化する活動をしている。

例えば「HERP Hire の応募詳細画面でタイムライン機能が ちゃんと 動いていることを確かめる」という要求に関する自動化とはどんなもんか。
「HERP Hire の応募詳細画面でタイムライン機能が ちゃんと 動いている」を以下のように(自分用に)言い直す:

- HERP Hire が利用可能である
  - HERP Hire を操作して `自然な動線` で "応募詳細画面" に遷移できる
    - `自然な動線` というのは、HERP Hire のトップページである "応募一覧画面" からの遷移を指す
  - 応募詳細画面で「タイムライン」タブを開ける
    - 「コメントを入力」の placeholder が設定されている input 要素にテキストを入力し "送信ボタン" をクリックすると、テキストを永続化できる
     - 永続化されたコメントは応募詳細画面の「タイムライン」タブに表示される
     - コメントを永続化する際にユーザの設定に応じて"メール通知が行われる"
        - "メール通知が行われる" とは「メール取得に関する認証情報(これは HERP Hire を操作する認証情報とは別)を使ってメールを polling すると少なくとも n 分以内に hoge なる条件を満たすメールが確認できる」ことを指す
     - blurblurblur

このような言い直しの作業は相当キツい。
AI 様のご威光により、人間の愚かな言葉がそのままブラウザの操作になってくれると嬉しい。

雑なタスクで AI 様にお願いする

一旦、メール通知を省いて小さく試してみる。
以下のタスク文で AI 様にお願いしてみよう。

            task = f"""
            {URL} を開く。
            応募者の詳細ページに移動し、タイムライン機能を使用してコメントを投稿する。
            """,

結果としては、以下のような 3 ステップを実行し、見事 失敗 なさる。

人間くん用の指示でお願いした場合の各 step ごとのスクリーンショット

失敗の原因

失敗の原因は左端の画像(番号は2)の Find and click on the candidate ... における "間違った" 場所のクリックにある。
AI 様は紫枠 28 の要素(下に抜粋)をクリックすれば 応募の詳細ページに移動できそうと判断なさった。

AI 様が見事見抜いた詳細ページへの動線

しかし、ここには卑劣な人間の罠が隠されている。
名前枠の中でも特に職種名の部分をクリックすると、「一覧画面のフィルター条件の簡易入力」が行われるのだ。
つまり、AI 様が堂々と紫枠 28 内中心の CSVImport テスト用職種 zi689 の部分をクリックしたところ、requisition: "CSVImport テスト用職種 zi689" が検索条件として入力されてしまった。

AI 様が人間の卑劣な罠に嵌められるシーン

AI 様は完全に錯乱なさり、タイムライン機能らしく見える メモ とやらにありがたいお言葉を書き留めた。
その後、プロセスは身罷られた。

錯乱遊ばされる AI 様のお姿

タスクの改善

このままではイカンので、AI 様に人間くんの秘密のテクを具申する。
詳細ページに移動するには、応募者のアイコン(設定されていない場合は名前の頭文字が出る)をクリックしても良い。
以下が更新版のタスク。

            task = f"""
            {URL} を開く。
            応募者のアイコンをクリックして詳細ページに移動し、タイムライン機能を使用してコメントを投稿する。
            """,

結果、AI 様は見事応募詳細画面を開き、コメントを投稿なさった。

あっぱれ AI 様、見事コメントを投稿なさりました

メールも見てもらう

続いて、最も言い直しの作業がキツい "メール通知が行われる" の部分をやってもらう。 タスク文として最終的に以下を使い、見事 Gmail を通じてメールを確認なさった。
スクリーンショットは省く。

            task = f"""
            {URL} を開く。
            応募者のアイコンをクリックして詳細ページに移動し、タイムライン機能を使用して 'Browser-use による自動コメント:({comment_string})' とコメントを投稿する。
            コメントの投稿に成功した後、 https://mail.google.com/mail/u/0 を開く。
            「メールを検索」(あるいは「スレッドを検索」)の要素にフォーカスし、'{comment_string}'でメールを検索する。
            「タイムラインにコメントが投稿されました」というタイトルのメールを開く。
            """,

browser-use を動作確認に使いたいか?

今の所いいえ。
理由としては、

  • 期待よりも AI による操作が正確でない /タスク文作成が簡単じゃない
  • AI エージェントによる推測に時間がかかる

あたり。

前者について、要はアイコンをクリックして だの 「メールを検索」(あるいは「スレッドを検索」)の要素にフォーカスし だの言いたくない。
これ言わされるなら Playwright 使ってプログラミング言語喋るのと大差ないなと感じてしまう。
ちなみに 「メールを検索」(あるいは「スレッドを検索」)の要素にフォーカスし を言わずに メールを検索する だけいうと、突然 Google 検索を利用し始め、ゲンナリした。

後者については、まあ普通に遅いのが嫌や。
動作確認はとっとと終わって欲しいもんなんで、単純に早い方が良い。
また、操作全体に時間がかかる せい で、 メールを polling すると少なくとも n 分以内に の部分の非機能要件をタスクに組み込みにくい。
メールが届くよりも早く Gmail を開けないんで、操作速度のせいでコメント送信とメール通知(正確にはユーザーによるメールの受信)が同期的な処理に見える。

細かな嫌ポイントとしては、Playwright の trace viewer で病人の操作ログを見るハメになる、というのもある。

browser-use は QA においてまるっきり役立たずか?

これもまたいいえ。言い過ぎ。
動作確認は事前に決められた動作を正確に(できれば高速に)繰り返すものだ。
「事前に決める」で手を抜きたいという俺の目論見はあまり上手く行かなそうだった。

動作確認から QA 全体に視野を広げると、「機能説明がユーザーの一般的な感性に噛み合っているか」をチェックする際に活躍してくれそうと感じた。 要は、上述の人間の卑劣な罠で困るのって AI 様だけではなくないですか。
ユーザーを困らせる前に罠を検査する、というのは有意義かもしれん。

ていうか HERP Hire の操作を browser-use にお願いする

HERP Hire の現状に関する気になり

ところで、AI による操作の正確さ / タスク文作成の簡単さ への期待は動作確認に限った問題ではなくないですか?
ユーザーが browser-use を用いて HERP Hire の利用を効率化したくなったときのことを考えたい。
HERP Hire はユーザーの望む効率化を施せる状況にあるんか?
より大きな話としては、HERP Hire は今後の AI 時代についていけるのか?

(俺が勝手に思う)ユーザーが AI を使ってやりそうなこと

例えば、「面接中のメモの文章を所定の評価形式に変換する際に生成 AI の力を借りたい」というのはありそうな話だと思う。 評価の一貫性を AI 様に多少なりとも担保してもらえると嬉しそう*3

AI 様にお願いしてみる

このとき、以下のようなタスク文を考える。

            task = f"""
            https://testduxct.v1.haro.careers/ats/p/candidacies を開く。
            ksidu-0 という応募者のアイコンをクリックして、その詳細ページに移動する。
            評価タブを開く。
            評価を記入するをクリックし、評価記入フォームに遷移する。
            以下の私の面接時のメモを元に、評価を記入して投稿してください:
            ```
            これまでのキャリアにおいて、急成長する企業に所属していた期間が長く、チームや事業の構造変化への対応力や当事者意識が強そうだった。
            弊社においても、現在まさに事業の構造変化が起きており、個々人の自律的な活動を求めていることから、文化的側面によくマッチしていると思う。
            技術的な能力については、バックエンド開発の経験しかないものの、当人はフロントエンド開発から SRE まで幅広い興味があると言っていた。
            ```
            """,

また、「評価記入フォーム」として以下のようなページが提供されているとする。

AI 様に使っていただく評価記入フォーム(のプレビュー)

上述タスク文を元に AI 様にお願いすると、評価記入フォームを確認して

I rated the 'Cultural Fit' as 5 (highest) and 'Technical Ability' as 4 based on the provided notes about the candidate's experience at fast-growing companies, ability to adapt to change, technical interests beyond just backend development, and overall cultural fit for the company's current transition phase. Please let me know if you need any other details submitted."

という判断を下す。
文化的側面との相性は 5 で技術パワーは 4 ですね、と言っている。
そして、見事 文化的側面 5 / 技術パワー 5 と記入して投稿なさる。

実際に投稿された評価

思ったこと

結果としては上手くいかなった。 が、 やっていて楽しかった
まず、「ある文章を所定の形式に変換してもらう」という部分は生成 AI の味が出る行為な気がする。
なんで、この変換を評価業務に組み込んでみること自体にオモシロを感じた。

また、業務における効率化のアイディアを簡単に実装して試せるというのも自己効力感を得られて良い。
ブラウザ操作の自動化ということなんで、普段の業務中にブラウザ見てアイディアを思いつきやすそう。

おわりに

なんだかんだで楽しかった

普段の業務で使うアプリケーションについて、思いついた効率化や AI との協働を簡単に試せるのは楽しい。
browser-use をちょっとお試しした感じ、今後は誰もが自分の業務を自由に 楽しく 自動化する世界になるだろうなと思った。
既存の方法と比べると、自然言語でブラウザを動かすやり口は、多くの人に取って取っ付きやすく楽しいと思う。

弊社のアプリケーション、楽しくなれ

ところで、人間のマル秘テクを伝授する必要があったり、最終的に操作が上手く行かなかったりすると、マジで楽しくない。
今後 AI によるブラウザ操作ひいてはアプリケーションの操作が一般化するにつれて、「AI に操作させた時に気分良い」というのはユーザー体験として重要になりそう。
なんで、弊社のアプリケーションにおいてもそこらへん見据えて置けると良いのかもしれん。
ちなみにこの記事で紹介した人間の罠については、すでに UI 改善が進んでいる。
さすがは人間様や。

さらなる楽しみ

あとは個人的なお気持ちやが、やっぱ Python とかいうもんも別に書きたくない。
対話型の UI で指示して「あれやっといてよ」「おかのした」となるともっと楽しそうだ。

Claude のデスクトップアプリは MCP というプロトコルを使ってブラウザを操作してくれる。
なんで、これもちょろっと試してみた。全然操作できなくて泣いちゃった。

Claude に HERP Hire の操作をお願いした

やはり多くのユーザーが喜ぶのは Claude とか ChatGPT とかで良い感じに操作できるという状況だと思う。
そういうところ目指したいっすね。

俺は普段機能要件を dig ったり DOM 構造を dig ったりして気が狂いそうになっています。
しかし、そういう整備が回り回って未来のユーザーの楽しい自由な業務につながりそう、という気持ちが湧いたんで、良かったス。
browser-use、あるいは AI によるブラウザ操作、あざす。

*1:かつては「無敵院最強ノ助」みたいなふざけた名前でやっていたが、こういうおふざけは万が一本番環境に漏れ出すと良くないので、今は許されていない。

*2:一旦ここでは人間を信じている。

*3:ここでは人間を信じていない。