ログインしてあるブラウザをAIエージェントに渡す

ログインの手間はAIに任せられない

※本記事は、当方ブログ記事の要約です。全文についてはブログまでお越しください。
kimi-webbridge について


「この画面の動作確認、自動化できませんか」という相談を受けることがあります。毎月同じ画面を開いて、同じ項目を入力して、表示がおかしくないか目で確かめる。手間だし、見落としも出る。自動化したくなるのは当然です。

ところが、ここで壁にぶつかることがあります。確認したい画面が、ログインの向こう側にある
という壁です。

パスワードだけでは済まなくなった

最近の業務システムは、IDとパスワードを入れただけでは入れません。スマートフォンの認証アプリに通知が飛んできて承認する。メールに届いた6桁のコードを入力する。会社が発行した証明書が入った端末でないと弾かれる。いわゆる多要素認証（MFA）です。

セキュリティとしては正しい。困るのは自動化する側です。プログラムに「スマホの通知を承認しておいて」とは頼めません。仮に工夫して突破できたとしても、それはセキュリティのために作った仕組みを自分で骨抜きにしているわけで、あまり筋がよくない。

結果として、「ログインが必要な画面の自動確認」は諦められがちでした。

順番を入れ替える

今回ブログで取り上げた Kimi WebBridge
は、この問題に別の角度から答えています。発想はシンプルで、ログインは人間がやる
。そのうえで、ログインが終わったブラウザだけをAIに渡す。

流れにするとこうなります。

1. 人が普段どおりChromeを開き、IDとパスワードを入れる
2. スマホで承認し、届いたコードを入力してログインを完了する
3. その「ログイン済みのブラウザ」を、AIから操作できる状態にする
4. AIが画面を読み、必要な入力や確認を行う

ポイントは、AIにパスワードも認証コードも渡していないことです。渡しているのは「すでに開いている画面を操作する権限」だけ。本人確認は最後まで人間が担当します。

例えるなら、鍵は自分で開けて、部屋に入ってからの作業を手伝ってもらう。鍵そのものは預けない、という形です。

画面が見えるかどうかは、決定的に違う

ここは、Web開発の現場では絶対に軽視できません。PlaywrightのようなヘッドレスブラウザのE2Eテストは、基本的に画面の外、メモリ上のブラウザで実行されます。テストは通っても、その瞬間に人間の目の前で画面が動いているわけではありません。何が表示され、どの要素が操作され、どんな状態になったのかは、後からスクリーンショットやtraceを確認することになります。


続きは当方ブログ記事までお越しください。