アクセシビリティツリー監査、AI検索時代の新必須SEO施策に浮上

アクセシビリティツリー監査、AI検索時代の新必須SEO施策に浮上

要点: Search Engine Landは2026年8月5日、AIエージェントがWebページを読み取る際に依存する「アクセシビリティツリー(AXツリー)」を監査するための10のSEOユースケースを公開しました。Googleは2026年6月、Chrome Lighthouseに「Agentic Browsing」カテゴリを追加し、「アクセシビリティツリーが正しく構築されているか」を検索・エージェント対応の合否基準に据えています。 背景には、Web全体のアクセシビリティ品質が6年ぶりに悪化しているという実測データがあります。AIによる自動巡回・自動操作が急拡大する一方で、サイト側の構造は追いついておらず、この"ズレ"がAI検索・エージェント経由の可視性を左右する新しいボトルネックになりつつあります。

最終更新日: 2026年8月6日

何が起きたのか

2026年8月5日: Search Engine Landが「10のSEOユースケース」を公開

Search Engine Landのテクニカルコンサルタント、John McAlpin氏は2026年8月5日、「10 SEO use cases for auditing your accessibility tree for AI search(AI検索のためのアクセシビリティツリー監査、10のSEOユースケース)」と題した記事を公開した。記事の副題は「HTMLの先へ——レンダリングの不具合、脆弱なサイト構造、AIの理解を妨げる要因を洗い出す実践的なワークフロー」というもので、単なる概念解説ではなく、実務者がすぐに手を動かせるチェックリスト形式で構成されているのが特徴だ。

記事が扱う「アクセシビリティツリー(Accessibility Tree、AXツリー)」とは、ブラウザがHTMLを解析した後に構築する、DOMの意味的なサブセットのことを指す。もともとはスクリーンリーダーなど支援技術のために20年近く前から存在してきた仕組みだが、装飾目的のdivやレイアウト用テーブル、CSSの背景画像といった「見た目だけの要素」を取り除き、機械可読な構造だけを残す点に特徴がある。ツリーに残る各ノードは「role(要素の種類。見出し・リンク・ボタン・ナビゲーションなど)」「name(識別テキストやaria-label)」「state(チェック済み・展開中・非表示などの状態)」「properties(その他の意味的情報)」という4つの情報を持つ。

McAlpin氏が指摘する最大のポイントは、この仕組みが「スクリーンリーダー利用者のための配慮」から「AIエージェントがサイトを操作するための実質的なAPI」へと役割を広げている点だ。ChatGPTのAtlasエージェントやMicrosoftのPlaywright MCPなど、Webページを自律的に読み取り操作するAIエージェントの多くが、生のHTMLをそのまま解釈するのではなく、まずアクセシビリティツリーを参照する設計になっている。理由は大きく2つある。第一に、スクリーンショットを画像認識モデルに読ませるより、構造化されたテキストであるアクセシビリティツリーの方が圧倒的にトークン効率が良いこと。第二に、画像から要素の役割を「推測」する必要がなく、role・name・stateとして明示的に取得できるため、誤操作のリスクが低く再現性が高いことだ。

Google Lighthouseが「Agentic Browsing」カテゴリを新設(2026年6月)

この動きを後押ししているのが、Googleの対応だ。johnmcalpin.com上の解説記事(2026年6月23日公開)によれば、Google Chromeの標準監査ツールであるLighthouseは2026年6月、新たに「Agentic Browsing(エージェンティック・ブラウジング)」という監査カテゴリを追加した。この監査の主要な合否指標が、まさに「Accessibility tree is not well-formed(アクセシビリティツリーが適切に構築されていない)」というものだ。

これは象徴的な出来事だといえる。これまでLighthouseのアクセシビリティ監査は、あくまで障害を持つユーザーへの配慮という文脈で語られることが多かった。しかし「Agentic Browsing」という名称そのものが示す通り、Googleはこの監査項目を「AIエージェントがそのページを正しく操作できるかどうか」の指標として明確に位置づけ直している。壊れたアクセシビリティツリーは、単にスクリーンリーダー利用者にとって使いにくいだけでなく、AIエージェントにとって「読めない・操作できないページ」であることを意味するようになった。

Web全体のアクセシビリティ品質は6年ぶりに悪化

一方で、土台となるWeb全体の状況は決して楽観できるものではない。Search Engine Journalが2026年6月24日に公開した記事「The Accessibility Tree Is How AI Agents Read Your Site & It's Breaking」(執筆: Slobodan Manic氏)は、WebAIMなどの実測データをもとに、Webアクセシビリティの品質が6年ぶりに悪化に転じたと報告している。

同記事が挙げる主な数値は以下の通りだ。

• 上位100万ホームページのうち**95.9%**でWCAG(Web Content Accessibility Guidelines)違反が検出された(前年の94.8%から悪化)
• 1ページあたりの平均エラー数は56.1件で、前年比**+10.1%**
• 1ページあたりの平均要素数は1,437個で、前年比**+22.5%**というペースで複雑化が進行
• コントラスト不足のテキストがあるページ: 83.9%
• 代替テキスト(alt属性)が欠落した画像があるページ: 53.1%
• フォームのラベルが欠落しているページ: 51%
• 空のリンク: 46.3%、空のボタン: 30.6%

さらに興味深いのは「ARIAのパラドックス」と呼ばれる現象だ。ARIA属性(スクリーンリーダー等に意味情報を伝えるための属性)を使っているページの平均エラー数は59.1件で、使っていないページの42件を上回っている。つまり「良かれと思って追加したARIA属性が、かえってツリーを壊している」ケースが少なくないということだ。W3Cが定める「ARIAの第一原則」は、可能な限りネイティブのHTML要素(<button>や<a>など)を使い、ARIA属性は本当に必要な場合の補完手段に留めるべきだと定めているが、この原則が現場で徹底されていない実態が浮き彫りになっている。

WebAIMはこの悪化の背景として、サードパーティ製フレームワーク・ライブラリへの依存度の高まりと、AIを使った自動コーディング(いわゆる"vibe coding")の普及を挙げている。AIにコードを書かせる機会が増える一方で、そのAIが生成するマークアップ自体がアクセシビリティ上の欠陥(divによる疑似ボタン、意味を持たない見出し階層など)を含みやすいという、皮肉な構造がある。

同じ時期に、Web上のトラフィック構成そのものも転換点を迎えている。Search Engine Journalの記事が引用するCloudflare Radarのデータによれば、2026年5月30日〜6月5日の週において、HTMLコンテンツへのHTTPリクエストのうち**57.2%がボット(自動化されたアクセス)**であり、人間による直接アクセス(42.8%)を初めて上回った。これは当初の予測より1年早いペースだという。アクセシビリティ品質の悪化と、ボットトラフィックの逆転現象が同時期に起きているという事実は、「人間中心に作られたWebサイトが、機械中心のアクセスに追いついていない」という構造的なギャップを裏付けている。

10のSEOユースケースの中身

McAlpin氏の記事は、この状況を踏まえて「では実務者は何を、どの順番で監査すればよいか」を具体的に示している。無料ツール「AXray Extractor」(McAlpin氏自身が開発)、Chrome DevToolsのアクセシビリティツリー表示機能、PlaywrightのariaSnapshot()関数などを使い分けながら、以下の10のユースケースを提示している。

1. 収益ページのエージェント対応度監査: 売上に直結する主要ページ(トップ10〜20ページ)を対象に、CTA・フォーム入力・ナビゲーションのランドマーク・メインコンテンツのランドマークが、正しいroleとnameを持って露出しているかを合否形式でチェックする。
2. JavaScriptレンダリングギャップの診断: JavaScript実行前後のアクセシビリティツリーを比較(AXray Extractorの「Capture JS Diff」機能を利用)し、スクリプトを完全に実行しないとAIエージェントから見えないコンテンツを特定する。クライアントサイドレンダリングのECサイトでは、商品グリッドやフィルター、ヘッダーがハイドレーション後にしか存在しないケースが多いと指摘されている。
3. WebMCP時代のコンバージョン経路監査: チェックアウト・リード獲得フォーム・会員登録といった収益フローを、ツリービュー上で一歩ずつ辿り、名前のないボタン・div実装のクリックハンドラ・ラベルのない入力欄・状態の不整合を洗い出す。エージェントがroleとnameとstateだけで取引を完了できるかを検証する。
4. 競合の"機械可読性"ベンチマーク: 同一テンプレートの競合サイト3〜5社のツリーを比較し、意味のあるノード数、名前付き/未名インタラクションの比率、ランドマークの有無、見出しの露出状況をスコア化して競争優位性を可視化する。
5. 見出し・ランドマーク階層の検証: 見出しレベルの飛び(H1→H3への飛躍)、重複、逆転、そして「視覚的には見出しだが実際はスタイル付きdivに過ぎない」ケースを洗い出す。意味のあるコンテンツブロックがmain・navigation・complementaryといったランドマーク内に適切に収まっているかも確認する。
6. アクセシブルネームによるアンカーテキストの是正: すべてのリンクのアクセシブルネームを一覧化し、「詳しくはこちら」のような汎用的な名前、アイコンのみで名前が空のリンク、aria-labelが可視テキストを不自然に上書きしているケースの3パターンを特定する。
7. 画像・alt属性のAI抽出対応監査: ツリーを画像ノードに絞り込み、意味のある画像に名前が付いていない、装飾目的の画像がツリーに露出している、「image」「photo123」のような無意味な説明文になっている、といった問題を洗い出す。空間的な文脈を含むalt属性、画像内テキストの可読性、<figure>・<figcaption>といった意味的マークアップの活用を推奨している。
8. CI/CDへのARIAスナップショット組み込み: PlaywrightのtoMatchAriaSnapshotアサーションを使い、ベースラインのツリーを記録した上で、デプロイによって名前が失われたり、ランドマークが消えたり、見出しが格下げされたりした場合にビルドを失敗させる。実装は概ね15行程度のコードで済むとされ、監査と監査の間に発生する"退行"を未然に防ぐ仕組みとして位置づけられている。
9. 移行・リニューアル前後のツリー差分比較: プラットフォーム移行やリニューアルの前後でアクセシビリティツリーを比較し、ランドマークの欠落や名前のないコントロールをローンチのブロッカーとして扱い、セクション順序の変更などはレビュー対象として扱う。「ツリー差分の確認」を移行チェックリストの標準項目に加えることを提案している。
10. SEO価値に基づく修正の優先順位付け: ツリーの不具合をテンプレート単位でグルーピングし、Google Search Consoleのクリック数・コンバージョン価値・AI引用の有無と突き合わせる。WCAGの重大度だけでなく、収益インパクトの大きいテンプレートから予算を配分する優先順位付けを提案している。

記事はあわせて、2025年だけで8,600件以上のアクセシビリティ訴訟が米国で提起されたという法的リスクの文脈にも触れており、アクセシビリティツリー監査が「AI検索対策」と「コンプライアンス対応」の両方を同時に満たす投資であることを強調している。

aiseo-llmo.com ユーザーへの影響

この一連の動きは、aiseo-llmo.comを利用するマーケター・SEO担当者にとって、これまでの「HTMLの見た目」中心の監査から「機械が読む構造」中心の監査への発想転換を迫るものだ。具体的な影響は以下の観点で整理できる。

第一に、AI Overviews・AI Mode・ChatGPT検索などへの引用可否そのものに関わる可能性がある。 これまでLLMO/GEO対策は「どんな情報を書くか」「どう構造化データを実装するか」といったコンテンツ面の議論が中心だった。しかし今回の動きは、その一歩手前にある「AIがそもそもページの構造を正しく読み取れているか」という土台部分に光を当てている。どれだけ優れたコンテンツを書いても、divによる疑似ボタンやJavaScriptハイドレーション後にしか見えないコンテンツが原因で、エージェントやクローラーがその情報にアクセスできなければ、引用の土俵にすら乗れない。

第二に、ECサイト・SaaS系のリード獲得サイトほど影響が大きい。 用例3(WebMCP時代のコンバージョン経路監査)が示す通り、チェックアウトやリード獲得フォームといった「収益に直結する場所」ほど、JavaScriptによる複雑なインタラクションが実装されがちで、アクセシビリティツリーが壊れやすい傾向がある。PerplexityのCometやChatGPT Atlas後継のブラウザエージェントのように、ユーザーに代わって購入・問い合わせ手続きを代行するエージェント型ブラウジングが普及するほど、この経路が壊れていることの機会損失は大きくなる。

第三に、"良かれと思って"実装したARIA属性が逆効果になりうる。 多くのサイト運営者は「アクセシビリティ対応=ARIA属性を追加すること」だと考えがちだが、前述の「ARIAのパラドックス」(ARIA使用ページの方がエラーが多い)が示す通り、誤った実装はむしろツリーを壊す原因になる。LLMO担当者が外部のライターやコーダーに実装を依頼する際、"とりあえずARIAを足す"という誤った対応を防ぐガイドラインが必要になる。

第四に、AIによる自動コーディング("vibe coding")の普及が新たなリスク源になっている。 サイト制作・改修の現場でAIコーディングツールの活用が広がるほど、意図せずアクセシビリティツリーを壊すマークアップが量産される可能性がある。皮肉なことに、「AIに書かせたコードが、別のAIエージェントに読まれる」という循環の中で、品質担保のための人間によるレビュー工程の価値がむしろ高まっている。

第五に、既存のLLMO投資(構造化データ、見出し設計、内部リンク)がすべて土台の上に成り立っているという事実が改めて浮き彫りになった。 schema.orgのマークアップやFAQ構造を丁寧に実装していても、その情報がアクセシビリティツリー上で正しく露出していなければ、AIエージェントにとっては「存在しないコンテンツ」と同じになりかねない。

今すぐできる対応策

以下のステップは、McAlpin氏の10のユースケースをもとに、aiseo-llmo.comユーザーが着手しやすい順に再構成したものだ。

ステップ1: まずは主要10〜20ページで現状把握

いきなりサイト全体を監査するのではなく、売上・問い合わせに直結する主要ページ(トップページ、主力サービス・商品ページ、料金ページ、問い合わせ・資料請求フォーム)を10〜20ページ選び、Chrome DevToolsの「アクセシビリティ」パネルでツリー構造を確認する。手順は次の通り。

1. 対象ページをChromeで開き、DevTools(F12)を起動
2. 「Elements」パネル右側の「Accessibility」タブを開く
3. 各インタラクティブ要素(ボタン・リンク・フォーム入力欄)を選択し、Role・Name・stateが正しく認識されているかを確認
4. <div onclick="...">のような、role・nameを持たない疑似ボタンがないかをチェック

無料ツールのAXray Extractorや、PlaywrightのCLIからpage.accessibility.snapshot()(またはariaSnapshot())を実行すれば、ページ全体のツリーをJSON/YAML形式で書き出し、機械的にチェックすることもできる。

ステップ2: JavaScriptレンダリング後の差分を確認する

クライアントサイドでレンダリングされる部分(商品一覧、フィルター、動的なFAQアコーディオンなど)は、JavaScript実行前後でツリーがどう変化するかを必ず確認する。実行前のツリーに主要コンテンツが存在しない場合、AIクローラーの設定によっては情報が取得できていない可能性がある。可能であればサーバーサイドレンダリング(SSR)やプリレンダリングを検討し、初期HTML段階で主要な文言・価格・仕様がツリーに露出するようにする。

ステップ3: マークアップの基本を見直す

• インタラクティブ要素には<button>・<a>・<select>などネイティブのHTML要素を優先し、divへのクリックハンドラの実装は避ける
• リンクのアクセシブルネームは「詳しくはこちら」のような汎用表現を避け、リンク単体で行き先が分かる文言にする(例:「LLMO料金プランの詳細を見る」)
• アイコンのみのリンク・ボタンには必ずaria-labelで内容を補う
• 見出しはH1→H2→H3の順序を守り、スタイルだけを目的にした見出しタグの流用(逆にレイアウト用divに見出しの役割を持たせる)を避ける
• 画像のalt属性には、単なる「画像」ではなく、空間的な文脈を含む具体的な説明を書く(例:「LLMOダッシュボードの引用率推移グラフ、7月から8月にかけて上昇」)
• アコーディオンやタブなど動的に開閉するUIには、aria-expandedなどの状態属性を正しく実装し、開閉状態がツリー上で分かるようにする

ステップ4: 継続的な監視をCI/CDに組み込む

一度直しても、その後のデプロイで再び壊れては意味がない。開発チームと連携できる場合は、PlaywrightのtoMatchAriaSnapshotをテストスイートに組み込み、ベースラインのツリーからの逸脱(ランドマークの消失、名前の欠落、見出しの格下げなど)を検知したらビルドを失敗させる仕組みを検討する。実装コストは大きくなく、McAlpin氏によれば概ね15行程度のコードで基本的な保護が可能だという。

ステップ5: Google Lighthouseの「Agentic Browsing」レポートを定期チェックする

Chrome DevToolsのLighthouseタブから「Agentic Browsing」カテゴリの監査を実行し、「Accessibility tree is not well-formed」の指摘が出ていないかを定期的に確認する。既存のパフォーマンス監査(Core Web Vitalsなど)と同じ運用リズムに組み込み、月次のSEOレポートに追加することを推奨する。

ステップ6: 優先順位はSEO・LLMOの成果指標で決める

すべての不具合を一度に直すのは現実的ではない。Google Search Consoleのクリック数・コンバージョン価値・AI検索での引用実績を軸に、影響の大きいテンプレート(商品ページテンプレート、サービス紹介テンプレートなど)から優先的に着手する。WCAGの重大度だけで優先順位を決めると、トラフィックの少ないページに時間を取られてしまうリスクがある点に注意したい。

よくある質問

Q1. アクセシビリティツリーとDOM(HTML構造)は何が違うのですか?

DOMはHTML文書全体の構造をそのまま表現したものですが、アクセシビリティツリーはそこから装飾目的の要素(レイアウト用のdiv、CSSの背景画像など)を取り除き、role・name・state・propertiesという意味情報だけを残した「意味的なサブセット」です。AIエージェントはこの軽量な構造を優先的に参照する傾向があります。

Q2. アクセシビリティ対応は障害者向け配慮であって、SEOやLLMOとは別物ではないですか?

従来はその認識が一般的でした。しかしGoogleが2026年6月にChrome Lighthouseへ「Agentic Browsing」カテゴリを追加し、アクセシビリティツリーの健全性をAIエージェント対応の合否基準に据えたことで、アクセシビリティ対応とAI検索対応(LLMO/GEO)は事実上、同じ土台を共有する取り組みになりつつあります。

Q3. 自社サイトのアクセシビリティツリーはどうやって確認すればよいですか?

最も手軽な方法は、Chrome DevToolsの「Elements」パネルにある「Accessibility」タブを開き、要素ごとのRole・Name・Stateを確認することです。サイト全体を機械的にチェックしたい場合は、無料ツールのAXray Extractorや、Playwrightのpage.accessibility.snapshot()(ariaSnapshot())でツリーをJSON/YAML形式に書き出す方法もあります。

Q4. ARIA属性をたくさん追加すればアクセシビリティは改善しますか?

必ずしもそうとは限りません。Search Engine Journalの分析では、ARIA属性を使用しているページの平均エラー数(59.1件)が、使用していないページ(42件)を上回る「ARIAのパラドックス」が報告されています。W3Cの原則でも、まずネイティブのHTML要素(<button>や<a>など)を使い、ARIAはそれで表現しきれない場合の補完として使うべきだとされています。

Q5. JavaScriptで動的に描画しているコンテンツは、AIエージェントから見えていますか?

保証はありません。クライアントサイドレンダリングに依存している商品一覧やフィルター、FAQアコーディオンなどは、JavaScriptの実行(ハイドレーション)が完了する前のツリーには存在しないことが多く、AIクローラーの設定次第では見落とされる可能性があります。JavaScript実行前後のツリー差分を比較し、必要に応じてサーバーサイドレンダリングを検討することが推奨されています。

Q6. すでにschema.org(構造化データ)を実装済みですが、それだけでは不十分ですか?

構造化データはAIに「この情報が何であるか」を伝える有効な手段ですが、その情報が掲載されているページ自体のアクセシビリティツリーが壊れていれば、エージェントがそこにたどり着けない、あるいは正しく解釈できない可能性があります。構造化データとアクセシビリティツリーの健全性は、いわば車の両輪の関係にあると考えるべきです。

Q7. 中小企業やリソースが限られたチームは、何から着手すべきですか?

McAlpin氏の記事も推奨する通り、まずは売上・問い合わせに直結する主要10〜20ページに絞って監査することが現実的です。トップページ、主力サービス・商品ページ、問い合わせ・申し込みフォームなど、コンバージョンに直結する箇所から着手し、見出し階層の是正やリンクのアクセシブルネームの見直しといった、開発工数の小さい施策から始めるとよいでしょう。

Q8. この対応は一度やれば終わりですか?

いいえ。サイトの更新やリニューアル、CMSやテーマの変更によって、一度直したアクセシビリティツリーが再び壊れることは珍しくありません。可能であればPlaywrightのtoMatchAriaSnapshotなどをCI/CDパイプラインに組み込み、デプロイのたびに自動でチェックする仕組みを構築することが望ましいとされています。

Q9. アクセシビリティ対応をしないと、法的なリスクもあるのですか?

Search Engine Landの記事は、2025年だけで米国において8,600件以上のアクセシビリティ関連の訴訟が提起されたと指摘しています。日本国内でも合理的配慮の提供義務化など、アクセシビリティに関する法制度の関心が高まっており、AI検索対応とコンプライアンス対応を同時に進める合理性は今後さらに高まると考えられます。

Q10. 今後、Googleや他のAI検索エンジンはこの分野でどう動くと予想されますか?

Lighthouseに「Agentic Browsing」カテゴリが新設された流れを踏まえると、今後はGoogle Search Consoleなど、より多くの実務者が日常的に触れるツールにも、同様のエージェント対応指標が組み込まれていく可能性があります。Perplexity・ChatGPTなど他のAI検索エンジンも、独自のエージェント機能(ショッピングエージェントやブラウザエージェントなど)を強化しており、アクセシビリティツリーの健全性は特定のプラットフォームに限らない「業界横断の共通言語」になっていくと見られます。

関連記事

• LLMO完全ガイド——AI検索時代の最適化戦略の全体像
• AI検索最適化(AIO/LLMO)完全ガイド
• セマンティックHTMLとAI検索最適化の関係
• 構造化データ実装でよくある失敗とAI引用への影響
• robots.txtとllms.txtの違い、SEOへの影響
• SearchBotとTrainingBot、許可・ブロックと引用適格性の関係
• Googleのエージェンティック・ブラウジング化とProject Mariner終了後のLLMO対策
• 用語集: クローラー
• 用語集: schema.org
• 用語集: llms.txt
• 用語集: JSON-LD
• 用語集: グラウンディング