#ブラウザ操作

まず、かなり筋がいい発想だと思った。スクリーンショットを毎回食わせるやり方は、見た目はわかりやすいけれど、AI の視点では重いし遅いし、クリック位置もあいまいになる。そこを「見えている DOM を文字に落として扱う」に寄せたのは、地味だけど実用上かなり効くはずだ。 特に引っかかったのは、単なる圧縮ではなく、ボタンや入力欄に stable handle を振っている点だ。`e49 button "Add to cart"` みたいな形なら、モデルは「この文字の場所はどこだろう」と迷わずに済む。人間がブラウザの要素を開発者ツールで見ている感覚に近い。LLM にとっては、画像の中を探すよりずっと素直だと思う。 一方で、これがうまくいく場面はかなりはっきりしていそうだとも感じた。フォーム、検索結果、checkout のように、ページの構造がある程度はっきりしている画面には強い。でも、複雑なレイアウトや、見た目そのものが意味を持つ画面では、最後は screenshot fallback が必要になる。そこを最初から「画像は不要」と言い切らず、小さく残しているのは現実的だ。 あと、local で動

この記事を読んでまず思ったのは、「ブラウザ操作の話なのに、ブラウザを実際には起動しないのか」という少し拍子抜けする感じと、でもそのほうが筋が通っているのではないか、という納得感の両方でした。 AI エージェントにWebを触らせるとき、結局いちばん壊れやすいのは“画面の座標を当てにいく”やり方です。スクリーンショットを見て「このボタンはここだろう」と推測するより、ページの構造そのものを見て要素を指定するほうがずっと堅い。人間の感覚に寄せるより、機械が機械らしく扱える情報を使う。かなり自然な方向だと思いました。 一方で、名称だけ見ると誤解を招きやすいとも感じます。Browser Use という名前なのに、読者はつい「ブラウザを自動操作するツール」を想像します。でも実際には、記事が伝えているのは「見た目をなぞる」のではなく、「DOM や参照を手がかりにする」仕組みだということでした。ここは地味ですが大事で、AI に画面を“理解させる”のではなく、Webページの部品を“扱わせる”発想に近い。派手さはないけれど、実務ではこっちのほうが頼れる場面が多いはずです。 逆に気になったのは、これが本当にど

最初に思ったのは、「AIエージェントって、結局は道具が増えたときに本当に使えるものになるんだな」ということだった。Claude Code単体でもかなりいろいろできるのに、MCPサーバーを足すと急に“できることの質”が変わる、という書き方が印象に残った。 特に腑に落ちたのは、MCPサーバーが単なる便利機能ではなく、AIに外界との接続口を増やす仕組みだという点だ。本文では「頭脳に目と手足を追加する」と表現していて、かなり大げさに見えるけれど、ブラウザを開いてフォームを押したり、スクリーンショットを取ったりする話を読むと、たしかに比喩としては的確だと思う。テキストを返すだけのAIと、画面を見て操作できるAIでは、仕事の任せ方がまるで違う。 一方で、MCPサーバーは魔法ではなく、Bashで代替できることも多い、という冷静な書き方もよかった。こういう記事はつい「これで全部解決」と盛りがちだけど、ここでは「なくてもなんとかなる。ただし向いている仕事がある」と線を引いている。その距離感のほうが信頼できる。むしろ、全部をMCPで置き換える発想より、繰り返し多い作業やブラウザ操作みたいな、人間が面倒だと