SNS運用を自動化しませんか?
ThreadPostなら、投稿作成・画像生成・スケジュール管理まで全てAIにお任せ。
終わりの始まり。DOMを捨てるAIたち
ブラウザが直接AIを内蔵した。スクショだけでWebを操作するオープンソースAIが出た。
HTMLの構造を気にしない時代が来た。DOM解析の時代が終わる。
Web開発の前提が根底から覆る。スクレイピングも、E2Eテストも、SEOも変わる。
これは単なるツールのアップデートではない。AIが「人間と同じ目」でWebを見るようになった事実だ。
開発者は戦い方を変える。
構造解析か、視覚認識か。分断されるWeb自動化の最前線
Webの読み方が二極化している。一つは、究極の視覚認識アプローチだ。
公開されたWebエージェント「MolmoWeb」は、DOMを一切読まない。
ソースコードを見ず、人間と同じようにブラウザのスクリーンショットだけを見る。
そこから次にクリックすべき場所を判断する。
性能は高い。40億から80億パラメータのモデルで動く。
巨大な非公開モデルを軒並み打ち破った。
Webサイトの裏側のコードは毎日変わるが、見た目は変わらない。
スクショに頼る方が壊れにくい。
彼らは3万6000回以上の人間のブラウジング操作を記録した。
さらに220万枚のスクリーンショットとQ&Aのペアを作った。
これを学習させることで、視覚情報だけでWebを操作できるAIが生まれた。

一方で、真逆のアプローチも進化している。最新のクローリングツールは、DOM解析を洗練させている。
HTMLをダウンロードし、JavaScriptを実行して動的コンテンツを描画する。
不要な要素を削ぎ落とし、LLMが読みやすいMarkdownに変換する。
構造化されたデータ抽出においては、この手法が最速だ。
抽出のDOM解析か、操作の視覚認識か。Web自動化の世界はこの二つのパラダイムで割れている。
さらにブラウザ自身の進化がある。世界最大のシェアを持つブラウザが、AIを標準搭載した。
検索結果と閲覧中のWebページを左右に並べて表示する。
ユーザーは開いている複数のタブやPDFをAIに投げ込める。
ブラウザそのものが、ユーザーの文脈を理解するエージェントになりつつある。
※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。
開発者から見た「視覚ベースWeb」の衝撃
衝撃だ。これまで開発者は、いかに綺麗なDOMを書くかに心血を注いできた。
クラス名を整理し、セマンティックなHTMLタグを使った。
だが、AIがスクショで画面を理解するなら、裏側のコードがどれだけカオスでも関係ない。
しんたろー:
DOM解析ベースのスクレイピングにはウンザリしていた。相手のサイトがReactやNext.jsでクラス名をランダム生成するたびに、セレクタが壊れる。スクショでボタンを認識してくれるなら、あの不毛なイタチごっこから解放される。
視覚ベースのエージェントは、Webの操作を変える。これまでの自動化は、特定の要素のIDやXPathを指定していた。
これからは「画面右上の青いログインボタンを押して」という指示で動く。
AIはスクショを撮り、視覚的に青いボタンを探し、座標をクリックする。
デザインが崩れない限り、裏側の実装がVueからSvelteに変わろうがAIは動じない。
この堅牢性は、自動化ツールを開発する上でメリットだ。

ブラウザがAIを内蔵したことの意味も大きい。これまでは、ユーザーがChatGPTやClaudeの画面にURLをコピペしていた。
これからは、ブラウザが勝手に開いているタブの文脈を読み取る。
僕らが作るWebアプリも、この「ブラウザAI」に読まれることを前提にする。
普段、僕はClaude Codeを使って開発をしている。CLIから直接コードを書かせるツールだ。
Claude Codeは今のところターミナル上で動くが、将来的には視覚情報をネイティブに扱うようになる。
例えば「このURLの画面崩れを直して」と指示する。
Claude Codeがブラウザを立ち上げ、スクショを撮る。
視覚的に崩れている箇所を特定し、該当するコンポーネントのコードを修正する。
しんたろー:
Claude Codeにフロントエンドの修正を頼む時、現状だとDOMの構造をテキストで説明しないといけない。これがめんどくさい。視覚認識モデルが完全に統合されたら、URL投げるだけで「あ、ここズレてますね」って直してくれるようになる。早くそうなってほしい。
視覚認識モデルの軽量化も進んでいる。80億パラメータのモデルで、巨大な商用APIに勝てる。
ローカルのGPUでも実用的なWeb操作エージェントが動く。
クラウドのAPI料金を気にせず、自分のPC上でAIにブラウザを操作させ続けられる。
これは個人開発者にとって武器になる。
ここまで読んだあなたに
今なら無料で全機能をお試しいただけます。設定後は完全放置でプロ品質の投稿を毎日生成。
実務でどう動く?セレクタ依存からの脱却とUI設計の見直し
開発への影響は大きい。「AIに見られること」を意識した設計が必須になる。
まず、自動化ツールやスクレイピングを作る場合。データの「抽出」だけが目的なら、DOM解析ツールを使うのが正解だ。
Markdownへの変換や、不要なノードの削除機能は強力だ。
しかし、「操作」が絡むなら話は別だ。ログイン、フォーム入力、動的なポップアップの処理。
これらをDOMのセレクタに依存して実装するのはやめる。
視覚的な要素をベースに操作するハイブリッドなアプローチを取り入れる。
次に、自分がWebサービスを作る場合。これまではGoogleの検索クローラーに向けてSEO対策をしていた。
これからは、ユーザーのブラウザに内蔵されたAIに向けて最適化する。
AIは開いているタブの情報を統合して回答を作る。AIが「文脈として理解しやすい」コンテンツ構造が求められる。

具体的にやるべきことは以下の通りだ。
- 視覚的なコントラストを明確にする
- ボタンやリンクのラベルを人間にもAIにも分かりやすくする
- 画像には必ず意味のあるキャプションをつける
- 論理的な見出し構造を維持する
- 構造化データ(Schema.org)を正しく埋め込む
しんたろー:
ThreadPostのUIを作るときも、最近は「これAIが見て『投稿ボタン』って分かるかな?」って考えるようになった。奇をてらったアイコンだけのボタンとか、視覚認識AIからするとただの謎の模様になりかねない。人間にとって分かりやすいUIが、AIにとっても一番使いやすい。
AIが複数タブの情報を比較する。あなたのサービスが、競合他社のサービスと同時にAIに読み込まれる。
その時、AIが「こちらのサービスの方が優れている」と判断できる明確な情報が必要だ。
料金表、スペック、機能の比較。これらをフワッとしたキャッチコピーではなく、明確なデータとして提示する。
AIは事実と数字だけを見る。
よくある質問(FAQ)
Q1: Web自動化において、DOM解析とスクリーンショット認識のどちらを選ぶべきか?
データ抽出が目的であれば、DOM解析が高速かつ正確だ。最新のツールを使えば、不要なHTMLを削ぎ落としてLLM向けのクリーンなMarkdownを生成できる。しかし、ログインや複雑なフォーム入力、動的なUI操作を伴うエージェント開発であれば、視覚情報を用いる手法が壊れにくい。サイトの仕様変更に対する耐性が高いからだ。用途に応じてこれらを組み合わせるハイブリッドな設計が、今後のWeb自動化の標準になる。
Q2: ブラウザのAI化は、自作WebアプリのSEOにどう影響するか?
単なるキーワード最適化の時代は終わる。ブラウザ内蔵AIは、ユーザーが開いている複数のタブやPDFの文脈を統合して回答を生成する。AIが情報を要約・抽出する際に「文脈として理解しやすいコンテンツ」が重要になる。論理的な見出し構成、明確な画像キャプション、そしてAIが回答を生成する際に参照しやすい構造化データ(Schema.org)の整備が重要になる。
Q3: Claude Codeを使って視覚ベースの自動化ツールは作れるか?
作れる。Claude Codeを使って、Pythonベースの軽量な視覚認識モデルを組み込んだスクリプトを生成させる。現状のClaude Code自体はCLIベースだが、コードを書かせる能力は高い。画面のスクショを撮り、軽量モデルに座標を判定させ、自動操作ツールでクリックさせる。この一連のパイプライン構築をClaude Codeに指示すれば、プロトタイプが動く。
まとめ:AIが「人間と同じ目」を持つ時代の戦い方
ブラウザがAIを内蔵し、オープンソースモデルがスクショだけでWebを操作する。
DOMの構造に依存したハックは通用しなくなり、視覚的に明確で論理的なUIが勝つ時代になった。
Webの「読み方」が変わる今、あなたの開発するツールはAIにどう認識されるべきか。
その戦略を、議論していこう。

この記事が参考になったら、ThreadPostを試してみませんか?
投稿作成・画像生成・スケジュール管理まで、全てAIにお任せできます。
ThreadPostをもっと知る
ThreadPost 代表 / SNS自動化の研究者
ThreadPost運営。Claude Codeで1人SaaS開発しながら、海外AI最新情報を開発者目線で発信中。
@shintaro_campon