6月25日、Search Engine Journalが「The Accessibility Tree Is How AI Agents Read Your Site & It's Breaking」と題した記事を公開した。AIエージェントがWebサイトをアクセシビリティツリー経由で読み取る仕組みと、そのツリーの品質が2026年に初めて悪化に転じた実態を詳しく紹介している。
ボットがWebトラフィックの過半数を占めた
2026年5月30日〜6月5日の週、Cloudflare RadarはHTMLコンテンツへのHTTPリクエストのうち57.2%が自動化されたボットによるものだと計測した。人間は42.8%に過ぎない。Cloudflare CEOのMatthew Princeはこの「逆転」を2027年と予測していたが、1年以上早く到来した。
このボットトラフィックの大半は単なるスクレイパーではない。実際のユーザーのためにページを操作するAIエージェントが占める割合が急増している。そしてそのAIエージェントが依存している構造が、6年間続いた改善傾向から逆転した。
AIエージェントはアクセシビリティツリーを読む
アクセシビリティツリーとは、ブラウザがDOMから構築する「ページの意味的な骨格」だ。スクリーンリーダー（視覚障害者向けの読み上げソフト）が20年間依存してきた仕組みであり、W3CのWAI-ARIA 1.2でも「UIの構造を表すアクセシブルなオブジェクトのツリー」として定義されている。
パイプラインは単純だ：HTML → DOM → アクセシビリティツリー → スクリーンリーダー／AIエージェント
数千ノードあるDOMは、見出し・リンク・ボタン・フォームフィールド・ランドマーク・画像の代替テキストなど「意味のある要素」だけに圧縮される。各ノードは以下の4つのプロパティを持つ。
| プロパティ | 内容 | 例 |
|---|---|---|
| Role（役割） | 要素の種類 | ボタン、ナビゲーション、リスト項目 |
| Name（名前） | 参照される呼び名 | 「もっと読む」というリンク、ラベルなしのアイコンボタンは名前なし |
| State（状態） | 現在の状態 | チェック済み、展開、無効、選択中 |
| Description（説明） | 名前以外の追加文脈 | ツールチップのような補足説明 |
エージェントはこのツリーを使って「何をクリックできるか」「どのフォームに何を入力するか」を判断する。
なぜスクリーンショットではなくアクセシビリティツリーなのか
エージェントがブラウザを操作する方法は主に3つある。
- アクセシビリティツリーのみ：MicrosoftのPlaywright MCPはビジョンモデルを使わず「構造化データのみで動作する」と明記している
- ビジョン優先：OpenAIのComputer-Using Agent（Operatorの基盤モデル）はスクリーンショットを主に使う
- ハイブリッド：アクセシビリティツリーをベースに、Canvasレンダリングなどツリーで捉えきれない部分に視覚モデルを補助的に使う
ツリーが好まれる理由は明快だ。スクリーンショットはトークンを大量消費し、ビジョンモデルが「どのピクセルがボタンか」を推測しなければならない。ツリーはコンパクトなテキストで、役割と名前が明示されている。
OpenAIもPublishers and Developers FAQの中で「ChatGPT AtlasはARIAタグを使ってページ構造とインタラクティブ要素を解釈する」と明言し、サイトをアクセシブルにすることを推奨している。スクリーンショット主体のエージェントを持つOpenAIでさえ、だ。
2026年、Webのアクセシビリティが初めて悪化した
WebAIM Millionは毎年、上位100万ホームページを対象にアクセシビリティを自動分析するプロジェクトだ。2026年2月版のレポートは厳しい数字を示した。
- 95.9%のホームページにWCAG（Webアクセシビリティ指針）の違反が検出。前年の94.8%から増加。WebAIMは「過去6年間の小さな改善傾向が逆転した」と表現している
- ホームページあたりの検出エラー数：56.1件（前年比10.1%増）
- ホームページあたりの要素数：1,437個（前年比22.5%増）
1年で要素数が22.5%増加するのは異常だ。要素が増えるほど構造が壊れる場所も増える。
最も多いエラーがツリーを無効化する
最頻出のアクセシビリティ障害は、エージェントにとってそのままデッドエンドになる。
| 障害の種類 | 影響ホームページ率 | エージェントへの影響 |
|---|---|---|
| 低コントラストのテキスト | 83.9% | ビジョン系エージェントにも見えない |
| alt属性なしの画像 | 53.1% | 画像が意味を持たない |
| フォームのラベルなし | 51% | 何を入力すべきかわからない |
| 空のリンク | 46.3% | 役割はあるが名前がない（案内板のないドア） |
| 空のボタン | 30.6% | 存在は見えるが何をするボタンかわからない |
| ドキュメント言語の未指定 | 13.5% | 誤った言語処理が適用される |
上位100万のホームページのうち46.3%に空のリンク、30.6%に空のボタンが存在する。エージェントにとってこれらは「見えているが使えないUI」だ。
WebAIMはレポートでこう述べている：
「これらわずかな種類の問題に対処するだけで、Web全体のアクセシビリティは大幅に改善する」
悪化の原因は「vibe coding」か
WebAIMはこの複雑性の増大を「サードパーティのフレームワークやライブラリへの依存増加、および自動化・AI支援コーディング（"vibe coding"）」に帰因している。
「vibe coding」とは、開発者がコードの細部を逐一確認せずAIに生成を委ねる開発スタイルを指す俗称だ。コードの量が増え、ページのデプロイが速くなる一方で、「この要素に名前と役割が正しく設定されているか」を確認する人間がいなくなっている構図がある。
WebAIMのデータが示す要素数の急増（前年比22.5%増）は、この仮説と整合する。AIが生成するコードはビジュアルとして破綻しないことを優先しがちで、アクセシビリティツリー上の正確性——ボタンに名前があるか、フォームにラベルが紐付いているか——は検証されないまま出荷されやすい。自動テストやaxe-coreのような静的解析ツールをCIパイプラインに組み込まない限り、この種の問題は人間のレビューでも見落とされる。
皮肉な構図だ。人間がAIを使って、AIが読めないWebを大量生産している。
ARIAの逆説：下手に付けると悪化する
ARIAはHTMLだけでは表現しきれない役割・名前・状態をアクセシビリティツリーに補完する属性セットだ。しかしWebAIMのデータは皮肉な事実を示す。ARIAが存在するページの平均エラー数は59.1件、存在しないページは42件だ。
間違ったARIA属性は「空白」を残さない。「自信を持って間違った情報」でツリーを埋める。エージェントにとって「正直な空白」より「誤情報の確信」の方がはるかに危険だ。
W3CのARIAの第一原則はこう定める：「必要なセマンティクスと動作がすでに組み込まれたネイティブHTML要素を使えるなら、要素を流用してARIAを追加するのではなく、ネイティブ要素を使え」。まずセマンティックなHTMLを書く。ARIAはその後の話だ。
自分のアクセシビリティツリーを確認する方法
ChromeのDevTools公式ドキュメントによれば、手順は2分で終わる。
- DevToolsを開き、Elementsパネルで要素を選択し、Accessibilityタブを開く → 計算されたロール・名前・状態が確認できる
- "Show accessibility tree"トグルをオンにすると、DOMツリーがページ全体のアクセシビリティツリー表示に切り替わる
コードで確認したい場合はPlaywrightのARIAスナップショットが使える。ページのアクセシビリティツリーをYAML形式で出力する機能で、Playwright MCPのようなエージェントが実際に受け取る構造にほぼ一致する。
確認のポイントはシンプルだ。ページ上の重要なアクションについて、ツリーに正しいロールと明確な名前を持つノードが存在するか。 「購入」ボタンがツリー上でアクセシブルな名前のないgeneric要素として現れているなら、エージェントはそのボタンを見つけても使えない。
詳細はThe Accessibility Tree Is How AI Agents Read Your Site & It's Breakingを参照していただきたい。
