はじめに：AIエージェントの台頭

近年AIの台頭で、人間の代わりにWebサイトを巡回、操作まで行うAIエージェントが次々と登場しています。

そのため、これまでのWebアクセシビリティ対応は主に人間を対象としたものでしたが、今後はAIエージェントも迷わずWebサイトを回遊し、目的のタスクを完了できる設計が重要になってきます。

そこで今回は、

  • 既存のアクセシビリティ対応はAIにもそのまま効くのか
  • AIエージェント特有の考慮すべき点

について整理しました。

AIエージェントがページを理解する仕組み

AIは何を見て操作しているのか

AIが画面を理解する仕組みは、アクセシビリティツリー解析（構造）とスクリーンショット解析（視覚）の2つの軸の組み合わせです。

画面のレイアウトや要素同士の位置関係をスクリーンショットで空間的に把握しつつ、「どこがクリックできるか」「今どんな状態か」などは裏側のアクセシビリティツリーを読み取って判断しています。

具体的には以下のような役割分担をしています。

  • アクセシビリティツリー解析
    役割：意味や状態の構造化データを正確にリストアップ
    弱点：CSSで強引に隠されているなど「コードと実際の見た目が乖離している部分」の判別が難しい点

  • スクリーンショット解析
    役割：空間的な位置関係の把握
    弱点：「ボタンっぽいが単なる画像」などを視覚だけで区別できない点

つまり、スクリーンリーダーが読み上げに使う「アクセシビリティツリー」が、AIにとっても重要な情報源になっています。

そのため、既存の人間向けのアクセシビリティ対応が、結果的にAIにとってもページ構造を正しく解釈し、操作するための手がかりとなります。

AIが要素を正確に認識するためのポイント

  • セマンティックHTML
    divタグで作られたボタンは、AIの解析ではただのテキストの箱にしか見えません。
    buttonタグやaタグを正しく使うことで、AIが正確に「クリック可能な要素」と認識できます。

  • 代替テキストによる意味の補足
    aria-label、altなどを正確に入れておけば、AIは画像から意味を推測（解析）する手間を省き、確実に素早く目的を理解できます。

  • 状態の明示
    aria-expanded="true" や aria-disabled="true" などの状態を示す属性は、AIが「次にとるべきアクション」を正確に決定するための重要な要素になります。

AIエージェント特有の考慮点

ここまでは「人間向けのアクセシビリティ対応はAIにも有効である」という話でした。

一方で、人間の補助ツールであるスクリーンリーダーと違って、AIエージェントは自ら思考・認知・決断を行います。
人間であれば文脈や経験から推測してカバーできる部分も、コードを絶対視するAIにとっては致命的なバグになり得ます。

ここからは、人間の認知を前提としないAI特有の考慮点について解説します。

HTMLと見た目の状態を正確に同期させる

見た目の変化とHTMLの状態が一致していないと、AIは無限ループなどの誤作動を起こす危険があります。
例えば、必須項目が埋まっていないときに送信ボタンを押せなくする状態の変化を実装するとします。

<!-- × CSSだけでクリックを無効にしている -->
<button class="btn-gray" style="pointer-events: none;">送信する</button>

<!-- ○ HTMLの属性で「無効」を宣言している -->
<button disabled="disabled">送信する</button>

CSSだけで実装した場合、スクリーンリーダーもAIエージェントも「クリックできるボタンだ」と勘違いする点は同じです。

しかし、この後の行動が違います。

人間（スクリーンリーダー）の場合
「送信ボタンを押したのに何も起きない」と混乱はします。しかし「もしかしてパスワードの文字数が足りないのかな？」などと推測し、フォームに戻って入力をやり直すことができます。
不便ではありますが、タスクを完了できる余地が残されています。

AIエージェントの場合
AIはコードを正確に信じて実行します。
「コード上は正常なはずなのに、なぜかクリックできない」となると、何度もクリックを試して無限ループに陥ったり、クリックしたと思ってそこでタスクを完了とみなしてしまうことがあります。

他にも、メニューが開いたことを伝えるaria-expandedなどの状態属性も同様です。人間なら視覚や文脈の変化から「開いたな」と推測することができますが、AIはコードが更新されないと「閉じている」と判断し続けます。

見た目の変化とHTMLの状態を正確に同期させることが、AIを迷わせないために重要になります。

エラーの「原因」をプログラム的に紐付ける

AIがフォームのエラーから自力で復帰するためには、どこをどう直せばいいのかをプログラム的に紐付けて伝える必要があります。

人間であれば経験から推測し、再入力することができます。AIエージェントの場合も、シンプルなフォームであれば正しく文脈を読んで推測してくれます。

しかし、例えば「姓」「名」の入力欄が横に並んでいて、その下に「※必須項目です」とエラーが出た場合、AIはどちらのエラーか迷い、誤った修正をしてしまうことがあります。

そこで、aria-describedbyなどの属性を用いて入力欄とエラーメッセージを明確に紐付けます。

<!-- エラーと原因を紐付ける -->
<div class="form-group-name"><!-- 姓：エラーなし -->
<input id="last-name" type="text" value="山田" placeholder="姓" aria-invalid="false" /><!-- 名：エラーあり -->
<input id="first-name" type="text" value="" placeholder="名" aria-invalid="true" aria-describedby="name-error" />

</div>
<span id="name-error" class="error-text">※必須項目です</span>

これにより、AIが自動で入力をやり直して再度ボタンを押す動作を、より高い精度で行えるようになります。

見えない要素に注意する

AIエージェントは特定のタイミングで取得した「スナップショット」を見て行動・決定をします。
そのため、スクロールによって後から読み込まれるような無限スクロールや遅延読み込みも注意が必要です。

人間は自然にスクロールして続きを探しますが、AIは「初期表示のDOMに存在しない＝このページには目的のものがない」と判断し、タスクを諦めてしまうことがあります。
そのため、重要な導線や要素は、初期DOM内に存在させておく配慮が必要です。

まとめ

人間向けのアクセシビリティ対応が「使いやすさの向上」を目的とするのに対して、AI向けの対応は「正しく解釈されるか」が重要になってきます。

AIに対応するためには、特別な実装が必要なわけではなく、セマンティックなHTMLを使い、aria属性を正しく使う。そんな「当たり前とされてきた基本の徹底」が、AIに対する最大の最適化になります。