アクセシビリティ検査を通すために記述したARIAは、実はAIエンジンにとっても明瞭な情報源です。スクリーンリーダーとAIエージェントがWebページを読む方法はよく似ています。人向けに美しく整えた画面を見るのではなく、HTMLをタグ、階層、名前から成る構造ツリーとして解析するからです。つまり、一度のアクセシビリティ対応で、視覚障害のあるユーザーを支援しながら、ChatGPT、Perplexity、Claudeなどのエンジンにもコンテンツを正確に抽出・引用してもらいやすくなります。GEOではよく語られる一方、実装時には見落とされがちなポイントです。
スクリーンリーダーとAIエージェントは、同じ構造ツリーを読む
通常のブラウザは、CSS、画像、アニメーションを組み合わせ、人の目で見るページを描画します。しかし、スクリーンリーダーの読み方は異なります。ブラウザが生成するアクセシビリティツリーを参照し、「ここはナビゲーション」「ここから本文」「これは『カートに追加』というボタン」と、構造を順に伝えます。AIエンジンのクローラーは、さらに簡略化された方法でページを読みます。その多くはJavaScriptを実行せず、元のHTMLからタグ、見出し階層、リンクテキスト、aria属性を抽出し、プレーンテキストに変換してからモデルへ渡します。両者に共通するのは、画像上の視覚的な手がかりではなく、構造とテキストを頼りにしている点です。
たとえば、<div>にクリックイベントを付けただけの擬似ボタン、altのない商品画像、文字サイズと太字だけで見出しらしく見せた段落は、人の目には問題なく映ります。しかし、スクリーンリーダーとAIエージェントから見ると、必要な情報が抜け落ちています。どれほど優れたコンテンツでも、抽出段階で構造が崩れれば、AIは意味を推測するしかありません。場合によっては、そのページ自体が読み飛ばされます。
まずはネイティブなセマンティックHTMLで土台をつくる
ARIAと聞くと、多くのチームはroleやaria-属性を大量に追加しようとします。しかし、順序は逆です。W3CのARIA利用に関する第一原則は明確で、ネイティブHTML要素で意味を表現できるなら、ARIAで置き換えるべきではありません。<button>は最初からボタン、<nav>はナビゲーション、<h2>は第2レベルの見出しとして設計されています。こうしたネイティブ要素には、意味と標準のキーボード操作が備わっており、クローラーとスクリーンリーダーの双方が認識できます。別途対応表を管理する必要もありません。ARIAは不足を補うためのものであり、土台そのものではありません。
一度の実装で双方に効く、4つの重点項目
エンジニアリングの工数を優先的に投じるなら、次の4項目です。いずれもアクセシビリティ監査で確認される項目であり、AIがコンテンツを抽出するときに重視するシグナルでもあります。
- ランドマーク構造：<header>、<nav>、<main>、<aside>、<footer>を使い、ページの骨格を明示します。AIクローラーは、これらのランドマークを手がかりに本文をナビゲーションやフッターの定型部分から切り分けます。メニューテキストを回答へ混在させず、本来のコンテンツだけを引用しやすくなります。
- 見出し階層：<h1>は1ページにつき1つとし、その下では<h2>、<h3>の階層を飛ばさないようにします。この見出しツリーは、AIが記事の構成を理解するための目次です。同時に、スクリーンリーダーの利用者が必要な箇所へ素早く移動するための基盤にもなります。
- 画像の代替テキスト：意味のある画像には、内容を説明するaltを設定します。装飾目的だけの画像はaltを空にし、読み飛ばせるようにします。特にインフォグラフィックの要点は、altまたは画像に隣接するテキストへ記載してください。そうしなければ、図中の数値は機械にとって存在しないも同然です。
- 操作要素の名前：すべてのボタンとリンクに、読み取り可能な名前を付けます。アイコンだけのボタンにはaria-labelでテキストを補い、そのアイコンで何ができるのかをAIエージェントにも伝えます。
最も見落とされやすい、アイコンボタンとリンクの名前
クライアントの技術監査で特に多く見つかるのが、画像だけで構成された操作要素です。ハンバーガーメニュー、ショッピングカート、検索の虫眼鏡、SNS共有ボタンなどは、SVGを<div>で囲んだだけで、テキストがまったくないケースも珍しくありません。この状態では、スクリーンリーダーは単に「ボタン」と読み上げるか、何も伝えません。AIエージェントにも、クリックはできるものの名前のないオブジェクトとして見えます。あるECクライアントでは、購入手続きのボタンがこの状態で、エージェント検証ツールは入口を見つけられませんでした。aria-labelで「購入手続き」と名前を付けると、同じボタンを視覚障害のあるユーザーと自動化エージェントの双方が認識できるようになりました。リンクも同様です。「詳しくはこちら」「ここをクリック」だけでは、画面上の文脈から切り離されたときにリンク先を判断できません。それぞれのリンクに、単独でも意味が通じる具体的なテキストを設定することが重要です。
動的要素では、「いま何ができるか」までAIエージェントに伝える
AIエージェントには、静的なコンテンツを読むだけでなく、メニューを開く、ページを切り替える、フォームを送信するといった実際の操作も求められるようになっています。こうした場面では、要素の名前だけでなく、現在の状態も必要です。ARIAの状態属性は、「このコンポーネントはいま開いているか」「どの項目が選択されているか」を機械が読める形で伝えます。これにより、エージェントは次に取るべき操作を判断し、直前の操作が反映されたかどうかも確認できます。
- aria-expanded：折りたたみメニュー、アコーディオン、ドロップダウンが開いているか閉じているかを示します。エージェントはこの属性を見て、先にクリックして開く必要があるかを判断します。
- aria-current：ページネーションやパンくずリストで現在位置を示し、エージェントが同じ階層を行き来し続けるのを防ぎます。
- aria-selectedとaria-checked：タブ、選択肢、チェックボックスなどの選択状態を示し、操作が反映されたかをエージェントが確認できるようにします。
- aria-live：フォームのエラーや読み込み結果など、リアルタイムで更新される領域をライブリージョンとして指定します。画面上の変化を、エージェントとスクリーンリーダーの双方が認識できるようになります。
検証：「見た目に問題がない」で済ませない
- curlまたはブラウザの「ページのソースを表示」を使い、サーバーが実際に返しているHTMLを確認します。JavaScriptの実行後にしか表示されないコンテンツは、多くのAIクローラーが読み取れません。
- ax DevToolsまたはLighthouseのアクセシビリティチェックを実行し、要素名の欠落、コントラスト不足、見出し階層の飛びなどを検出します。
- スクリーンリーダーも実際に一度は起動してください。MacではVoiceOver、WindowsではNVDAを使い、キーボードだけでページを移動しながら、どのように読み上げられるかを確認します。
- isitagentreadyのようなエージェント対応チェックを使い、AIエージェントが主要なコンポーネントを認識し、操作できるかを検証します。
アクセシビリティは、単なる追加のコンプライアンスコストではありません。視覚障害のあるユーザーのために実装したセマンティックタグは、AIエージェントにも読み取られます。一度のエンジニアリング投資から、2種類の価値を同時に生み出せる数少ない取り組みです。— Tenten GEO Technical Audit
ARIAやセマンティックマークアップを実装しただけで、検索順位が直接上がるわけではありません。しかし、AIエンジンがページを正確に理解し、コンテンツを抽出・引用できるかどうかは左右します。これはGEOの土台です。AIエージェントから自社サイトがどう見えているのか、重要なコンポーネントのどこが情報のない状態になっているのか分からない場合は、30分のGEO診断をご予約ください。実際の検証結果をもとに、改善すべき箇所を明らかにします。
