この記事では、AIエージェント（人の代わりにWebサイトを操作するソフトウェア）が扱いやすいサイトを作り、実験段階のLighthouse Agentic Browsing（AI操作向けの監査機能）で検証する方法についてまとめています。
検索結果に表示されるだけでなく、AIがフォームに入力したり、メニューを開いたり、購入前の情報を探したりする時代に向けた新しい確認方法です。実際に触ってみると、最初の壁は「見た目がきれいなら問題ない」という従来の感覚を切り替えることでした。
まず結論：AIに操作される前提で、サイトを点検する
Chrome for Developersは、2026年6月22日にAIエージェントによるWebサイト操作向けのツールキットを公開しました。LighthouseにはAgentic Browsingカテゴリが追加され、アクセシビリティ（誰でも使いやすくする設計）、レイアウトの安定性、WebMCP（Webサイトの機能をAIから扱いやすくする仕組み）との統合などを確認できます。
大切なのは、AI向けに特別なデザインを作ることではありません。ボタンの役割が伝わる名前になっているか、画面が動いたあとも目的の操作を続けられるか、フォームの入力欄が正しく認識できるかを見直します。
ただし、Agentic Browsingは実験的な機能です。公開時点では情報提供を目的としたカテゴリで、通常のLighthouseのような0〜100のベンチマークスコアではありません。合格点だけを追うのではなく、改善点を探すチェックリストとして使うのが現実的です。
従来のLighthouse監査と何が変わるのか
従来のLighthouseは、表示速度、SEO（検索エンジンに内容を伝える対策）、アクセシビリティなどを数値や項目で確認する道具でした。人がページを見て評価する前に、機械的な問題を見つけるのが得意です。
Agentic Browsingでは、AIがサイト上で行動しやすいかという視点が加わります。たとえば、見た目はボタンでも名前が「こちら」だけだと、AIは何を実行するボタンなのか判断しにくくなります。反対に「資料をダウンロード」「予約日時を選ぶ」のような具体的な名前なら、次の操作につなげやすくなります。
| 確認する視点 | 従来の確認 | AIエージェント向けの確認 |
|---|---|---|
| ボタン | 色やコントラスト | 役割が名前から分かるか |
| レイアウト | 表示速度や見た目 | 読み込み後に操作対象がずれないか |
| フォーム | 入力欄が表示されるか | 項目名やエラー内容を認識できるか |
| 連携 | ページ単体の動作 | AIが機能を呼び出しやすい構造か |
WordPressサイトなら、まず問い合わせ、資料請求、予約など成果につながるページから確認すると効果的です。すべてのページを一度に直すより、訪問者が実際に行う操作を一つ選ぶ方が迷いません。
検証前に用意するもの
ここでは、実際に画面を見ながら進めるための準備を整理します。特別なコードを書く作業ではありませんが、実験的な機能を使うため、表示や手順が今後変わる可能性があります。
- 確認したいWebページ
- パソコン版のChrome
- Chrome DevTools for Agents（AIエージェントの操作を再現・記録・調査する開発者向け機能）
- ページ上で試す操作のメモ
操作のメモは、「トップページから料金ページを開く」「問い合わせフォームにテスト情報を入力する」のように書きます。先に目的を決めると、監査結果を見たときに改善の優先順位をつけやすくなります。
実際の使い方：LighthouseでAgentic Browsingを確認する
1. 対象ページを開いて開発者ツールを表示する
まずChromeで検証したいページを開きます。画面右上の三点メニューをクリックし、「その他のツール」から「デベロッパーツール」を選びます。キーボードでは、WindowsならCtrl＋Shift＋I、MacならCommand＋Option＋Iでも開けます。
右側または下側に開発者ツールが表示されたら、上部にある「Lighthouse」タブをクリックします。見つからない場合は、タブ列の右側にある「>>」をクリックして一覧から選びます。
2. Lighthouseの監査対象を選ぶ
Lighthouse画面では、監査するページの種類や実行条件を確認します。Agentic Browsingの項目が表示される環境では、そのカテゴリを選びます。通常のPerformance（表示性能）やAccessibilityと同時に選べる場合もありますが、最初は対象を絞ると結果を読みやすくなります。
画面にAgentic Browsingが表示されないときは、Chromeや開発者ツールのバージョン、実験的機能の提供状況を確認します。機能が全員に同じ形で提供されているとは限らないため、表示されないこと自体を設定ミスと決めつけないでください。
3. 監査を実行して結果を読む
カテゴリを選んだら、画面下部の「Analyze page load」または同じ意味の実行ボタンをクリックします。読み込みが終わるまでページを操作せずに待ちます。
結果では、アクセシビリティ、レイアウトの安定性、WebMCPに関係する項目などを確認します。警告が出たら、項目名、対象となったHTML（ページを構成する記述）、改善の説明を順番に読みます。数字を上げるより、「AIが次に何をすればよいか分からない場所」を探す意識が重要です。
4. Chrome DevTools for Agentsで操作を再現する
監査結果だけでは、実際の操作中に何が起きたか分からない場合があります。そこでChrome DevTools for Agentsを使い、エージェントが行う操作を再現します。
- 開発者ツール内、または利用できるDevTools for Agentsの入口を開きます。
- 操作の目的を「問い合わせフォームを開いて入力欄を確認する」のように短く指定します。
- エージェントがクリック、入力、画面遷移を進める様子を確認します。
- 操作が止まった場所で、画面の記録やデバッグ情報を開きます。
- ボタン名、見出し、入力欄のラベル、エラーメッセージを修正します。
実際に使うと、AIがページを完全に操作できるかどうかより、「どの段階で目的を見失ったか」が見えてきます。たとえば、メニューを開けても項目名が抽象的だったり、フォーム送信後の完了メッセージが分かりにくかったりします。
初心者がつまずきやすいポイントと対処法
最初に戸惑いやすいのは、監査結果に一般的な点数が出ないことです。これは不具合とは限りません。公開時点のAgentic Browsingカテゴリは、情報提供を目的とした実験的な機能です。結果を合否判定ではなく、改善候補の一覧として扱いましょう。
次に、AIが操作を失敗したからといって、すぐにAI側の問題だと考えないことです。人間なら雰囲気で分かるアイコンや、マウスを重ねると表示される説明は、AIに伝わりにくい場合があります。ボタンに具体的な文字を加え、入力欄には目的が分かるラベルを付けてください。
WordPressでは、テーマやプラグインの更新後にボタン名やフォーム構造が変わることがあります。修正したら、同じ操作をもう一度再現します。キャッシュ（ブラウザやサーバーに残る一時的な保存データ）が原因で古い画面が表示される場合は、キャッシュを削除してから確認します。
料金や無料プランはある？
今回確認できる公式情報では、Agentic BrowsingカテゴリやChrome DevTools for Agentsについて、独立した料金プランや有料・無料の区分は案内されていません。そのため、「完全無料で使える」「有料契約が必要」と断定するのは避けるべきです。
試す場合は、手元のChromeと開発者ツールで利用できる範囲を確認してください。表示される機能や提供条件が環境によって異なる可能性もあります。社内サイトで本格導入する場合は、実験機能であることを共有し、通常のアクセシビリティテストやユーザーテストも併用します。
この方法が向いている人・向かない人
向いているのは、問い合わせや予約などの導線を改善したいWeb担当者、WordPressサイトの使いやすさを確認したい制作者、AI検索やAI操作を見据えて準備したい人です。特に、アクセス解析で離脱が多いページを持っている場合は、操作のどこで迷うかを確認するきっかけになります。
一方、表示速度だけを測りたい人や、今すぐ安定した点数で比較したい人には向きません。実験的な機能なので、環境差や仕様変更があり得ます。通常のLighthouse、アクセシビリティチェック、実際のユーザーによる操作確認を組み合わせて判断してください。
注意点：AI対応だけを目的にサイトを作らない
AIが操作しやすいサイトは、人にとっても使いやすいサイトであることが多い一方、AI向けの記述だけを増やせばよいわけではありません。訪問者の個人情報を入力させるフォームでは、確認画面、利用目的、送信完了の表示を分かりやすくします。
また、WebMCPは提案中の標準に基づく実験的な機能です。導入を検討する場合も、重要な処理をAIの自動操作だけに任せず、権限確認や人による最終確認を残してください。
まとめ：今日からできる最初の一歩
AIエージェント対応のサイト検証では、見た目や表示速度だけでなく、「AIが次の操作を判断できるか」を確認します。LighthouseのAgentic BrowsingカテゴリとChrome DevTools for Agentsを使えば、監査と操作再現を組み合わせて改善点を探せます。
- 問い合わせや予約など、確認する操作を一つ決める
- ボタン名と入力欄のラベルを具体的にする
- LighthouseでAgentic Browsingの項目を確認する
- 操作を再現し、止まった場所を記録する
- 修正後に同じ手順で再確認する
まずは最も重要な1ページだけで十分です。実験段階の機能だからこそ、点数を追いかけるのではなく、訪問者が迷わず目的を達成できるかを確かめるところから始めましょう。
よくある質問
Agentic Browsingは通常のLighthouseスコアと同じですか？
同じではありません。公開時点では情報提供を目的とした実験的なカテゴリで、通常のLighthouseのような0〜100のベンチマークスコアではありません。改善箇所を見つけるために使います。
Agentic Browsingが画面に表示されない場合はどうしますか？
Chromeと開発者ツールのバージョン、実験的機能の提供状況を確認してください。提供条件によって表示されない可能性があるため、無理に設定を変更せず、通常のLighthouseやアクセシビリティ確認も進めます。
WordPressで最初に直すべき場所はどこですか？
問い合わせ、資料請求、予約など、成果につながるページから始めます。「こちら」「詳細」のような曖昧なリンク名を、目的が伝わる具体的な名前に変えると確認しやすくなります。
この機能は無料で使えますか？
公式情報では、独立した料金プランや無料プランの詳細は確認できません。利用できる機能や条件は、実際のChromeと開発者ツールの環境で確認してください。
参考・公式情報
📦 Amazonで関連商品を探す
