Browser Subagent に自サイトを操作させて気づいた、エージェントに優しいフロントエンドの条件

個人開発で運営しているサイトの動作確認を Antigravity の Browser Subagent に任せてみたところ、人間なら迷わない操作で立て続けに詰まりました。テーマ切替ボタンを見つけられない。決済後のトースト通知を読み取れずに「結果が確認できません」と報告してくる。無限スクロールの一覧では、存在するはずの記事を「見つからない」と結論づけてしまう。私自身が書いたフロントエンドなのに、エージェントから見ると思った以上に「読めない」画面だったわけです。

I/O 26 で Chrome は agentic web 対応として15項目の更新を発表し、エージェントがブラウザを操作する前提の Web 設計が現実の話になってきました（Chrome for Developers で順次公開されています）。今回は、自サイトをエージェントに操作させて見つかった具体的な失敗と、その修正から整理した実践チェックを共有します。

エージェントは「見た目」ではなく「構造」を読んでいる

Browser Subagent の挙動を観察して最初に腑に落ちたのは、エージェントが頼りにしているのはピクセルの見た目以上に、アクセシビリティツリーと DOM 構造だということです。スクリーンショットも併用しますが、操作対象の特定は「ロールと名前を持つ要素」が基本になります。

つまり、スクリーンリーダーにとって使いにくいサイトは、ほぼそのままエージェントにとっても使いにくいサイトです。逆に言えば、アクセシビリティ対応として知られてきた施策の多くが、そのまま agentic web 対応になります。人間用の UX とエージェント用の UX は9割まで同じで、残り1割が「状態の機械可読化」だ、というのが私の現時点での整理です。

挙動の観察方法は Antigravity の Browser Sub-Agent が SPA を空ページと誤認する原因と待機戦略でも書いた手順と同じで、エージェントの操作ログと自分の目視を突き合わせていきます。

実際に詰まった3つのポイントと直し方

アイコンだけのボタンは死角になる

最も多かった失敗が、アイコンのみのボタンです。月のアイコンだけのテーマ切替ボタンは、エージェントから見ると「名前のない button 要素」でしかありません。

// Before: エージェントには「無名のボタン」にしか見えない
<button onClick={toggleTheme}>
  <MoonIcon />
</button>
 
// After: 名前と状態を持たせる
<button
  onClick={toggleTheme}
  aria-label="ダークモードに切り替え"
  aria-pressed={isDark}
>
  <MoonIcon aria-hidden="true" />
</button>

aria-label で「何をするボタンか」、aria-pressed で「今どちらの状態か」を載せるだけで、エージェントは確実にこのボタンを発見し、押した結果まで検証できるようになりました。修正後は同じタスクの成功率が体感で別物になっています。

消えるトーストは「読まれる前に消える」

決済完了やコピー完了を3秒で消えるトーストだけで伝えていたのも、エージェントには厳しい設計でした。エージェントの観察サイクルは人間の視線より遅いことがあり、読み取る前に DOM から消えます。

私は「一時的な通知＋永続的な状態表示」の二段構えに直しました。トーストは残しつつ、処理結果をページ内の role="status" を持つ要素にも反映させます。

// 結果はトーストだけでなく、残る場所にも書く
<p role="status" data-state={purchaseState}>
  {purchaseState === "completed" ? "購入が完了しました" : ""}
</p>

role="status" はスクリーンリーダー向けのライブリージョンですが、エージェントにとっても「処理結果を確認しに行く場所」として機能します。

無限スクロールには「全件への別経路」を用意する

無限スクロールの一覧でエージェントが記事を見つけられなかった問題は、スクロールを繰り返させるのではなく、ページネーション付きの一覧や検索ページという「別経路」を案内する方が確実でした。私のサイトでは全記事一覧とカテゴリページがすでにあったので、フッターからの導線を明示しただけで解決しています。クロール効率の観点でも、この構造は元々 SEO の定石と一致します。

チェックリスト — 自サイトをエージェント対応にする最小セット

修正を終えて整理した、私が新しい画面を作るときに確認している項目です。

操作可能な要素はすべて「ロール＋アクセシブルネーム」を持つ（button に aria-label、リンクテキストは「こちら」禁止）
状態は属性で公開する（aria-pressed / aria-expanded / aria-checked、独自状態は data-state）
フォームの input には name と label を必ず対応づける
処理結果はトーストだけでなく role="status" の永続表示にも書く
無限スクロールだけに依存せず、ページネーションか検索の別経路を持つ
JS 描画完了前の「空の main」を返さない（ローディング中であることを示す要素を置く）

最後の項目は SPA 全般の落とし穴で、E2E テストの安定化とも同根です。Antigravity Browser Sub-Agent による E2E テスト自動化で扱ったセレクタ設計（data-testid の付与）も、そのままエージェント対応として効きます。

ボットを全部歓迎する話ではない

エージェント対応を進めると「スクレイパーにも優しくなってしまうのでは」という不安が出ます。私はここを「操作のしやすさ」と「アクセス制御」は別レイヤーの問題として切り分けています。レート制限・認証・robots.txt の方針はこれまで通り維持した上で、正当にたどり着いたユーザー（人間でもエージェントでも）には構造の読める画面を返す、という整理です。検証には Chrome DevTools のエージェント向け機能も使えます。詳しくは Chrome DevTools for agents 1.0 が安定版に — Antigravity 2.0 同梱で何が変わったかにまとめています。

エージェント経由の訪問はまだ少数ですが、I/O 26 の方向性を見る限り、この比率は片道で増えていくはずです。まずは自分のサイトの最重要動線（購読・購入・問い合わせ）を Browser Subagent に一度操作させて、どこで詰まるかを観察するところから始めてみてください。想像より早く、直すべき場所のリストが手に入ります。