AIエージェントにも読みやすいWebサイトの設計

AIエージェント向けの特別なSEOページを作る前に、同じページを人間、検索エンジン、支援技術、ブラウザエージェントがそれぞれ理解できる状態にします。

Google Searchの生成AI機能に関するガイドは、通常のSEO、クロール可能性、独自性を土台として扱い、AI専用の文章分割やファイルを必須にしていません。一方、web.devのエージェント フレンドリーなウェブサイトのガイドは、エージェントがスクリーンショット、HTML、アクセシビリティツリーを組み合わせてサイトを理解すると説明しています。

この二つを合わせると、実装の問いは「AIに引用される書き方」ではなく、「目的、関係、状態、次の操作が、視覚とHTMLの両方で追えるか」です。BUILD ORBITでは、このNoteをエージェント対応の専用UIではなく、既存のアクセシビリティ・静的HTML・品質ゲートを別の観測軸から読み直すためのownerとします。

先に結論：三つの表現を同じ意味にそろえる

エージェントがページから受け取る情報は、一つの読み取り経路に限られません。人間向けの見た目を捨てるのではなく、画面、DOM、アクセシビリティツリーの役割をずらさないことが先です。

どれか一つだけを最適化すると、別の経路で意味が抜けます。たとえば、見た目はボタンでもDOMがただのdivなら、位置は分かっても操作の種類やキーボード責任は伝わりません。逆に、HTMLが整っていても、画面上で結果の変化が見えなければ、操作が完了したかを確認しにくくなります。

1. AI検索とエージェント操作を分ける

検索結果に表示されることと、エージェントがページ上で操作できることは同じ課題ではありません。

• Google SearchのAI機能：Search indexに入り、検索結果のsnippetを表示できる技術条件と、通常の有用で独自性のあるコンテンツが前提です。
• ブラウザエージェント：ページを読み、目的に合うリンクや入力を見つけ、必要なら操作の結果を確認します。
• 支援技術：role、名前、状態、読み上げ順を使って、同じページを別の方法で利用します。

このため、llms.txtやAI専用schemaを足すことをエージェント対応の完了条件にしません。Google Searchでは、専用ファイルや「chunk化」を足すことが掲載や順位を保証しないと説明されています。エージェント向けに書いた隠しテキストを増やすより、実際に表示される本文、リンク、入力、状態を整えます。

2. 操作の種類をHTMLへ残す

エージェントが次の一手を選ぶには、要素の見た目だけでなく、何をすると何が変わるかが必要です。

移動はa、状態変更はbutton

別ページへ移動する要素はa、ページ内の表示や状態を変える要素はbuttonにします。クリックイベントをdivやspanへ付けると、画面では動いても、DOMとキーボードの契約が弱くなります。どうしても標準要素が使えない場合だけroleやtabindexを検討し、まず責任に合うHTML要素がないかを探します。

リンクの文言も「こちら」ではなく、移動先で得られるものを書きます。「公開前チェックリストを読む」「静的HTMLのPatternを確認する」のように、目的と遷移先を一緒に置くと、検索後の読者にもエージェントにも次の選択が伝わります。

入力の目的と単位を結び付ける

入力欄は、見た目の近さだけで意味を伝えません。labelと入力要素を関連付け、必要ならforとidを明示します。複数選択はfieldsetとlegend、数値は単位と許容範囲、結果は見出しと説明を持たせます。

BUILD ORBITのBuild Simulatorでは、目的、更新頻度、記事量、インタラクション密度などの条件をlabel付きのselectやinputで受けています。結果は単なる色やカードの変化ではなく、プロファイル名、理由、先に作るページ、避ける実装、品質ゲートとしてテキストに出します。これはエージェント専用の実装ではなく、人間が入力を見直せる構造です。

状態変化をテキストでも伝える

操作後に変わったものは、色、位置、アニメーションだけに閉じ込めません。aria-expanded、aria-pressed、aria-currentなどの状態属性と、見出しや説明文を組み合わせます。非同期で結果が変わる部分は、必要な範囲をaria-liveで通知し、エラーは原因と復旧方法を近くに置きます。

状態をすべて読み上げればよいわけではありません。初期表示と変更後の差分、現在位置、次の操作が分かる範囲に絞り、同じ内容を何度も送らないことも重要です。

3. BUILD ORBITの実装を三つの経路で照合する

このサイトには、エージェント対応のために追加した専用機能はありません。既存の実装を、三つの経路で同じ意味になるか確認できます。

ここでいう照合は、AIエージェントの成功率を測ったbenchmarkではありません。ローカルのソース、生成HTML、自動検証が同じ責任を指しているかを見る、BUILD ORBIT内の観察です。

4. 発見・理解・操作・復旧の順で監査する

エージェント対応の確認を、単語の追加ではなく目的達成の順序にします。

最初に「このページは誰のどの判断を助けるか」を一文で固定し、最後にその判断が完了したかを確認します。入力やUIの数を増やすことが目的ではありません。人間が途中で迷う場所は、エージェントにとっても次の行動を選びにくい可能性があります。

5. 見た目を変えずに改善できる範囲

エージェント対応を理由に、既存のvisual systemを作り直す必要はありません。BUILD ORBITでは、次の順に既存のHTML、データ、検証へ戻します。

1. 既存の見出し、リンク、入力、表に不足している名前と状態を確認する。
2. JavaScriptが生成している意味のうち、目的、条件、次のリンクを静的HTMLへ戻せるか確認する。
3. 操作結果、エラー、更新、無効値の復旧を、視覚以外のテキストでも確認できるようにする。
4. direct URL、no-JS、キーボード、主要viewport、axe、生成物を確認する。
5. それでも足りない独立した目的がある場合だけ、既存のレイアウトとコンポーネントを再利用して拡張する。

CSS、色、font、カード、Orbit、Blueprint、motion、breakpointを変えることを、agent-friendlyの条件にしません。スクリーンショット経路があるからといって、視覚的な文章や演出へ機械向けの説明を重ねる必要もありません。

6. このNoteの責任範囲

このNoteが扱うのは、AIエージェントを対象にしたサイトの意味・操作・復旧の読み取りやすさです。次の項目は別のownerへ戻します。

• Google Searchでのindex、canonical、sitemap、通常SEO： AIサイトの公開前チェックリストと品質ゲート。
• 静的HTMLとIslandの切り分け、URL state、dist/upload： 静的ホスティングNoteとStatic-First Enhancement。
• WebMCPの採用判断、ツールの責任分割、確認・権限・評価・fallback： WebMCPを静的サイトへ足す前に決めること。
• 具体的な構成の採用・回避条件： Build SimulatorとDesign Patterns。
• 事実、解釈、確認日、未確認範囲の分離： MethodologyとCase Studies。

AIエージェントの読み取りや操作が改善したかを、このローカル監査だけで断定しません。検索順位、AI Overviewへの掲載、引用数、agent task success rateは、別の実測環境と対象範囲が必要です。ここでPASSと書けるのは、ソースと生成物に意味が残っていること、ローカルの検証が通ったことまでです。

公開前に使う短いチェックリスト

• h1、冒頭の結論、対象外条件、次の行動が初期HTMLにある。
• 移動はa、状態変更はbuttonで、リンク文から目的が分かる。
• 入力のlabel、単位、範囲、現在値、エラーが関連付いている。
• 表の行・列見出し、見出し階層、landmark、現在地がDOMに残っている。
• 操作結果は色やmotionだけでなく、テキストと必要な状態属性でも分かる。
• no-JS、無効値、直接URL、戻る・進む、404からの復旧が成立する。
• axe / E2E / build / SEOのPASSを、本番公開やagent引用の証明と書いていない。
• AI専用ファイル、隠し文、特殊schemaを足す前に、人間向けの意味と導線を確認した。

最後の判定は一つです。「エージェントに見せるためのページ」ではなく、人間が読み、支援技術が解釈し、ブラウザエージェントが必要なら操作できるページになっているか。実装をリリース工程へ戻すときはMethodへ、既存の品質確認へ戻すときは品質ゲートへ進みます。

よくある質問