はじめに：画面の向こう側の「声」を聞いていますか？
Webサイトやアプリケーションが視覚障害を持つユーザーに対して発する「声」、つまりスクリーンリーダーによる読み上げ体験は、音声UI設計やVUIデザインの観点からも非常に重要な要素です。
近年、開発現場では次のような課題が頻繁に聞かれるようになっています。
「AIにコードを書かせると爆速で開発できるが、品質チェックでQAチームから大量に差し戻される。特にアクセシビリティ周りで」
AIは魔法のようなツールとして広く活用されています。しかし、AIには決定的な弱点があります。それは、「見た目」は理解できても、「意味」を深く理解しているわけではないという点です。
画面上では完璧なボタンに見えても、スクリーンリーダーには「クリック可能な画像」としか伝わらない。あるいは、親切心（？）から大量のARIA属性を付与した結果、逆にユーザーを混乱させる饒舌すぎるインターフェースになってしまう。
これは、AIが「確率論」でコードを紡いでいるがゆえに起こる現象です。一方で、アクセシビリティ（特にWCAGなどの基準）は、厳格な「ルール」に基づいています。このギャップこそが、今の開発現場で起きている「AI時代のアクセシビリティ負債」の正体です。
この記事では、AIコーディングツールが生成するコードのアクセシビリティ品質を、実際の検証データに基づいてレビューします。そして、AIを「未熟だがポテンシャルのあるジュニアエンジニア」として扱い、正しく導くための具体的な手法をお伝えします。
「動けばいい」から「誰もが使える」へ。AIと共に、よりインクルーシブなコードを書くためのアプローチを見ていきましょう。
AI時代の「アクセシビリティ負債」：自動生成コードに潜むセマンティクスの罠
AIが生成したコードをそのまま本番環境にデプロイすることの危うさ。それは、セキュリティホールやパフォーマンスの問題だけではありません。目に見えない部分で、UIの「意味（Semantics）」が壊れている可能性があるのです。
見た目の再現性と意味論（Semantics）の乖離
私たちは普段、視覚情報に大きく依存してWebを利用しています。ボタンの形をしていればボタンだと認識し、見出しの大きさであれば見出しだと理解します。しかし、AIもまた、学習データに含まれる膨大な「視覚的実装」のパターンを模倣することに長けています。
ここで問題になるのが、DOM構造と視覚表現の乖離です。
例えば、AIに「モダンなカード型UIを作って」と依頼すると、<div>タグの入れ子構造にTailwind CSSのクラスを大量に付与した、美しいコンポーネントを生成してくれます。見た目は完璧です。しかし、そこには<article>や<h2>といった、コンテンツの構造を表すセマンティックなHTMLタグが欠落していることが多々あります。
スクリーンリーダーユーザーにとって、セマンティクスのないページは、情報の海を羅針盤なしで漂流するようなものです。見出しジャンプもできなければ、ランドマーク（ナビゲーションやメインコンテンツの区画）も認識できません。
「No ARIA is better than Bad ARIA」の原則再考
Webアクセシビリティには、「No ARIA is better than Bad ARIA（悪いARIAよりは、ARIAがない方がマシ）」という有名な原則があります。HTML標準の要素（ネイティブ要素）を使えば、ブラウザが自動的に正しいアクセシビリティ機能を提供してくれるからです。
しかし、AIはこの原則をしばしば無視します。学習データの中に、ARIA属性を誤用した古いコードや、場当たり的な修正コードが大量に含まれているためです。
よくあるのが、「divボタン」の生成です。
<!-- AIが生成しがちなコード（Bad） -->
<div role="button" onClick={handleClick} class="btn-primary">
送信
</div>
AIは「ボタンの役割（role）」が必要だと判断してrole="button"を付けますが、これだけでは不十分です。キーボード操作（EnterキーやSpaceキーでの実行）や、フォーカス管理（tabindex）が欠落していることがほとんどです。ネイティブの<button>タグを使えばこれらはすべて標準で付いてくるのに、AIはわざわざ複雑で不完全な実装を選んでしまうことがあります。
AIが陥りやすい「親切すぎる」属性過剰付与の問題
もう一つの厄介な傾向は、ARIA属性の過剰付与（Over-ARIA）です。
AIは文脈を補完しようとして、必要以上の情報を属性に詰め込む傾向があります。例えば、すべてのアイコンにaria-labelを付けたり、静的なテキストにまでaria-describedbyを紐付けたりします。
<!-- AIによる過剰な属性付与の例 -->
<button aria-label="送信ボタン" title="送信" aria-description="フォームの内容を送信します">
送信
</button>
これでは、スクリーンリーダーは「送信ボタン、送信、フォームの内容を送信します、ボタン」のように、冗長で重複した情報を読み上げることになります。音声UI設計やコンバーサショナルAIの観点から言えば、これは「うるさいUI」です。必要な情報だけを簡潔に伝えることが、良い音声体験の基本ですが、AIはそのバランス感覚をまだ持っていません。
【検証レポート】主要AIツールのARIA属性付与精度と傾向分析
では、実際に主要なAIコーディング支援ツールはどの程度の実力なのでしょうか？
同一のプロンプトを用いて、GitHub Copilot、ChatGPT、Claudeの最新モデルに、一般的なUIコンポーネント（モーダルダイアログ、アコーディオン、タブパネル）を実装させ、そのアクセシビリティ品質を検証した結果を見ていきましょう。
検証環境と対象ツール
- 検証対象: モーダルダイアログ（React + Tailwind CSS）
- プロンプト: 「ReactとTailwind CSSを使って、アクセシブルなモーダルコンポーネントを作成してください。開閉状態の管理と、背景クリックでの閉じる機能も含めてください。」
- 評価基準: WCAG 2.1 レベルAA準拠、WAI-ARIA Authoring Practices Guide (APG) パターンへの適合度
ツール別：ARIA属性の「幻覚（Hallucination）」パターン
検証の結果、各ツールの「癖」と、最新機能の活用有無による精度の差が浮き彫りになりました。
1. GitHub Copilot (VS Code拡張機能)
- 傾向: 「インライン補完は速いが、エージェント活用で真価を発揮」
- 評価: △（従来の使い方） → ◯（最新機能活用時）
- 詳細: 通常のインライン補完だけでは、学習データに含まれる古い慣習を引きずりやすく、
role="dialog"はあってもフォーカストラップ（Focus Trap）が抜けるケースが見られます。しかし、@workspaceコマンドやCopilot Edits（エージェントモード）を使用してプロジェクト全体のコンテキストを与えると、精度が劇的に向上します。単なる補完ではなく、エージェントに対話的に修正させるワークフローへの移行が、アクセシビリティ確保の鍵です。
2. ChatGPT (最新モデル)
- 傾向: 「論理的で正解に近いが、参照関係の整合性に注意」
- 評価: ◯
- 詳細: 推論能力が強化された最新モデルでは、「アクセシブルな」という指示に対して敏感に反応し、比較的きれいなコードを出力します。フォーカストラップやEscキーでのクローズ処理も実装してくることが多いです。しかし、ARIA属性の誤用（例：
aria-labelledbyのID参照先が存在しない、など）という「幻覚」が発生することがあります。コードとしては動くが、参照エラーが起きている状態です。
3. Claude (最新モデル)
- 傾向: 「仕様に忠実で説明的だが、過剰実装になりがち」
- 評価: ◎（ただし要調整）
- 詳細: 最新モデルにおいても、WAI-ARIAの仕様に最も忠実なコードを生成する傾向があります。特筆すべきは、コードの説明文の中で「なぜこのARIA属性が必要か」を解説してくれる点です。ただし、親切すぎる傾向があり、
aria-describedbyなどで過剰な説明を追加するケースが見られます。エンジニアが取捨選択（引き算）をする必要があります。
静的コンポーネント vs 動的インタラクション：エラー率の違い
静的な構造（フォームのラベル付けなど）に関しては、どのAIも高い精度を示しました。しかし、状態変化を伴う動的インタラクションになると、エラー率は跳ね上がります。
- アコーディオン: 開閉時の
aria-expanded属性の切り替えロジックが逆になっている（開いているのにfalse）。 - タブパネル: 矢印キーによるフォーカス移動（Roving Tabindex）の実装が複雑すぎてバグを含んでいる、あるいは全く実装されていない。
AIは「状態遷移」の時間軸を理解するのが苦手です。これが、音声UXとして致命的な「状態の不一致」を生む原因となります。
ベストプラクティス①：AIへの「コンテキスト注入」とプロンプト設計
AIの出力品質は、入力（プロンプトとコンテキスト）の質に依存します。「アクセシブルにして」という曖昧な指示ではなく、エンジニアが仕様を明確に定義してあげる必要があります。
WCAG基準を明示的に指定するプロンプトテンプレート
AIに対して、従うべきガイドラインを具体的に指示しましょう。以下は、推奨されるプロンプトの構成要素です。
【推奨プロンプトテンプレート】
以下の要件を満たす [コンポーネント名] を [フレームワーク名] で作成してください。
機能要件:
- [具体的な機能記述]
アクセシビリティ要件 (必須):
- 準拠基準: WCAG 2.1 Level AA に準拠すること。
- セマンティクス: 可能な限りネイティブHTML要素（
<button>,<input>,<dialog>など）を使用し、ARIA属性は補完的にのみ使用すること（No ARIA is better than Bad ARIA原則）。- キーボード操作: すべての機能がキーボードのみで操作可能であること（Tab順序、Enter/Space実行、Escキーでの閉じる動作など）。
- スクリーンリーダー: WAI-ARIA Authoring Practices Guide (APG) の [コンポーネント名] パターンに従い、適切なRoleとState (
aria-expanded,aria-selected等) を管理すること。
このように具体的な「参照規格」を渡すことで、AIの推論範囲を適切なドキュメントに絞り込むことができます。
デザインシステム・コンポーネント設計との連携
もしプロジェクトにデザインシステムやコンポーネントライブラリがある場合は、その定義ファイルやドキュメントをAI（特にCursorやGitHub Copilot Business/Enterpriseなど、コンテキストを読み込めるツール）に参照させることが重要です。
「プロジェクトの BaseButton コンポーネントを使用して実装して」と指示すれば、BaseButton 内ですでに実装されているアクセシビリティ機能を再利用でき、AIによる独自の不完全な実装を防ぐことができます。
「ARIAではなくHTML標準要素」を優先させる指示出し
プロンプトのコツとして、「ARIAを使って」と言うよりも、「セマンティックHTMLを使って」と強調する方が結果が良い傾向にあります。
「ARIAを使ってボタンを作って」と言うと、AIは高確率で <div role="button"> を作ります。
「セマンティックHTMLでボタンを作って」と言えば、<button> タグを使ってくれます。
言葉選び一つで、生成されるコードの品質（と、その後の修正コスト）が大きく変わるのです。
ベストプラクティス②：生成コードの「自動リンター」とCIパイプライン統合
どれほど優れたプロンプトを書いても、AIはミスをします。人間もミスをします。だからこそ、機械的なチェック機構が必要です。AI生成コードを「信頼せず検証する」ための自動化アプローチを紹介します。
eslint-plugin-jsx-a11yの設定と限界
React開発においてデファクトスタンダードとなっている eslint-plugin-jsx-a11y は必須です。これは、<img> タグの alt 属性忘れや、クリックイベントを持つ非対話要素などを静的に検出してくれます。
しかし、これだけでは不十分です。このプラグインは「属性が存在するか」はチェックできますが、「その属性値が文脈的に正しいか」までは判断できません。例えば、aria-label="ボタン" という無意味なラベルが付いていても、エラーにはなりません。
AI生成コード専用の静的解析ルールの策定
AI生成コード特有の問題に対処するために、より厳格なルール設定や、追加のツール導入を検討しましょう。
- Markuplint: HTMLの構造的な問題や、WAI-ARIAの仕様違反（許可されていない属性の組み合わせなど）をより詳細にチェックできます。
- axe-core (axe-linter): 定評のあるアクセシビリティ検証エンジンです。VS Code拡張機能として導入すれば、コードを書いているそばから問題を指摘してくれます。
チーム開発におけるアクセシビリティ・ゲートキーパーの自動化
CI/CDパイプライン（GitHub Actionsなど）にアクセシビリティチェックを組み込むことで、基準を満たさないコードのマージを防ぎます。
- ユニットテストでの検証:
jest-axeなどを使い、コンポーネントのテストケース内でアクセシビリティ違反がないかをアサートします。 - E2Eテストでの検証: CypressやPlaywrightに
axe-coreを統合し、実際のレンダリング結果に対して自動監査を走らせます。
「AIが書いたコードだから大丈夫だろう」ではなく、「AIが書いたコードだからこそ、厳重にテストを通す」という意識転換が必要です。
ベストプラクティス③：人間による「意味論的監査」とスクリーンリーダー検証
自動チェックツールで検出できるアクセシビリティエラーは、全体の約30%〜50%と言われています。残りの半分以上は、人間が実際に操作してみないと分からない「体験」の問題です。
ここが、エンジニアや設計者の腕の見せ所です。
AIが見落とす「文脈」と「順序」のレビューポイント
AIはコードの構文は理解しますが、ユーザーがどのような順序で情報を取得し、操作するかという「ストーリー」を持っていません。
レビュー時には以下の観点でコード（と実際の動作）を確認してください：
- フォーカス順序: Tabキーを押していった時、フォーカスは論理的な順序（左上から右下へ、または文脈に沿って）で移動するか？ 突然予期せぬ場所に飛ばないか？
- 隠された要素: モーダルが開いた時、背面のコンテンツは正しく隠蔽（
aria-hidden="true"またはinert）されているか？ スクリーンリーダーが裏側のコンテンツを読み上げてしまわないか？ - 状態変化の通知: フォームのエラーメッセージが表示された時、それは即座にスクリーンリーダーに通知されるか？（
role="alert"やaria-liveの活用）
スクリーンリーダー（NVDA/VoiceOver）での実地検証フロー
開発者自身がスクリーンリーダーを使ってテストすることは、最も強力なデバッグ方法です。
- Macユーザー: Command + F5 で VoiceOver を起動できます。
- Windowsユーザー: オープンソースの NVDA をインストールしましょう。
目を閉じて（あるいは画面を見ずに）、キーボードと音声だけでAIが作ったUIを操作してみてください。「何これ、操作できない！」「今どこにいるの？」と感じたら、それがユーザーの体験そのものです。
特にAIが生成した複雑なウィジェット（カレンダーやスライダーなど）は、この実地検証で問題が発覚することが多いです。
キーボード操作のみでのユーザビリティテスト
スクリーンリーダーを使わなくても、マウスを使わずにキーボードだけで操作するだけでも多くの問題を発見できます。
- すべてのインタラクティブな要素にTabキーで到達できるか？
- フォーカスリング（青い枠など）は視覚的に明確か？（AIが生成したCSSで
outline: noneになっていないか確認！） - EnterキーやSpaceキーでボタンやリンクを作動できるか？
これらは基本的な事項ですが、AIコードでは意外と抜け落ちているポイントです。
成熟度評価：組織の「AIアクセシビリティ・リテラシー」を測る指標
AIツールが普及した今、エンジニア個人のスキルだけでなく、組織としてどう品質を担保するかが問われています。開発チームはどの段階にありますか？
レベル1：AI出力を鵜呑みにしない（Awareness）
- エンジニアが「AIコードにはアクセシビリティ上の欠陥がある可能性がある」と認識している。
- 基本的なリンター（eslint-plugin-jsx-a11y）が導入されている。
レベル2：AIの誤りを修正できる（Correction）
- エンジニアが生成されたコードを見て、「ここはおかしい」と気づき、手動で修正できる。
- キーボード操作テストがレビュープロセスに含まれている。
レベル3：AIに正しい学習データを提供できる（Context）
- デザインシステムやガイドラインをAIに読み込ませ、組織の基準に沿ったコードを生成させている。
- CI/CDパイプラインで自動アクセシビリティテスト（axe, Cypressなど）が稼働している。
レベル4：組織独自のアクセシビリティ・ガードレール構築（Governance）
- AI生成コード専用の監査フローが確立されている。
- QAチームだけでなく、開発者自身がスクリーンリーダーを用いた検証を日常的に行っている。
- 「アクセシビリティ・ファースト」なプロンプトエンジニアリングがチーム内で共有されている。
多くの組織はまだレベル1か2の段階です。しかし、AIの進化と共に、開発プロセスもレベルアップしていく必要があります。
まとめ：AIは「優秀な助手」、監督するのはあなたです
AIによるコード生成は、開発効率を劇的に向上させました。しかし、そのスピードの裏で、アクセシビリティという「品質の最後の砦」が脅かされているのも事実です。
検証結果からもわかるように、GitHub CopilotやChatGPTは強力なツールですが、アクセシビリティに関してはまだ発展途上です。不正確なコードを出力したり、過剰な属性を付与したりすることがあります。だからこそ、開発者には、「コードの意味（セマンティクス）を監査する」という新しい役割が求められています。
- プロンプトで基準を示すこと
- 自動化ツールで足切りすること
- 自分の耳と手で体験を確認すること
これらを実践することで、AIが生み出すコードは「ただ動くコード」から「誰にでも優しいコード」へと進化します。
アクセシビリティは、専門知識が必要な難しい分野だと思われがちです。もし、プロダクトのアクセシビリティ診断や、AI導入に伴う品質保証プロセスの構築に課題を感じる場合は、専門家に相談することをおすすめします。
AIに使われるのではなく、AIを使いこなし、すべてのユーザーに最高の体験を届ける。その第一歩を、ここから踏み出しましょう。
AIコード生成 × アクセシビリティ監査の実践
AIコード生成とアクセシビリティ監査の実践においては、検証プロセスの実演や実際のコード診断などを通じて、継続的にスキルをアップデートしていくことが重要です。
コメント