hacomonoの もんちゃん こと 門田（かどた）です。
加齢に伴って腰のことを気にし始め、良い椅子を求め、グダグダと悩んだあげくに結局立って作業することに落ち着きました。財布の紐が固い。
最近の目覚ましい AI の進化を見ていると、開発速度も品質も生産性も、これから一気に上がっていくんだろうなと強く感じます。実際、日々の作業効率はかなりの勢いで上がっています。
ただその一方で、じゃあもう全部 AI でいいね〜人がやることはもうないね〜と言えるほど単純でもない、とも感じています。
開発の現場には、今でも人が見たほうがいいこと、人が判断したほうがいいことが思っている以上にたくさん残っているからです。
プロダクト開発で AI を使う場面が増える中、アクセシビリティチェックにも AI を取り入れやすくなってきました。特に開発フローの中に組み込めるツールや、実装ルールを再利用できる仕組みが整ってきたことで、「まず自動で検知する」という段階はかなり現実的になっています。
今回は、AI を活用してアクセシビリティチェックを効率化するという話と、
そのうえで「過剰なアクセシビリティ」を目指しすぎないことについて書きます。
そして AI が見ているアクセシビリティと、実際の人間が感じるアクセシビリティの違いにも触れていければと思います。
AI でアクセシビリティチェックを仕組み化する意味
アクセシビリティの改善は重要ですが、現場ではよく次のような壁にぶつかります。
アクセシビリティに限った話ではないですが。
- チェック観点が属人化する
- レビュー担当によって指摘の粒度が変わる
- 毎回同じ観点を人力で確認している
- 開発終盤でまとめて問題が見つかる
このとき AI は、アクセシビリティそのものを"判断しきる存在"というより、チェック観点を安定供給する存在として非常に有効です。
たとえば Claude Code の Skill に、プロダクトで重視する観点をあらかじめ持たせておけば、コンポーネント実装や画面レビューのたびに、同じ基準で確認しやすくなります。
つまり、アクセシビリティに関する Skill を作ると、AI に対して毎回ゼロから
「見出し構造を見て」
「フォームラベルを見て」
「キーボード操作も意識して」
と説明しなくてよくなります。
レビュー観点を"個人の記憶"から"チームの資産"へ移せるわけです。
Claude Code の Skill でやるとよさそうなこと
Claude Code の Skill 活用で価値が出やすいのは、次のような領域です。
1. 実装レビューの観点を固定する
例えばですが Skill に以下のような観点を持たせます。
- 画像に代替テキストが必要か
- フォーム要素に適切なラベルがあるか
- ボタンやリンクの名前が文脈上わかるか
- 見出しレベルが飛んでいないか
- ARIA を足しすぎていないか
- キーボードで操作できる設計になっているか
こうした観点は、W3C の評価ツールガイドラインでも自動評価ツールで検出可能な領域として整理されています。ただし W3C はあくまで評価を支援するものとして位置づけており、ツールが万能であるとはしていません。評価の種類や目的に応じて使い分ける必要がある、という前提です。
この点は後のセクションでも改めて触れますが、AI によるチェックを導入するうえで忘れてはいけないポイントです。
2. プロダクト固有の判断基準を覚えさせる
一般論だけでは対応しきれない場面もあります。
たとえば BtoB SaaS では、管理画面特有の複雑なテーブル、絞り込み UI、モーダル、日付入力など、プロダクトごとの"つまずきポイント"があります。
ここで Skill に、
- 自社デザインシステムのコンポーネント仕様
- よくある実装ミス
- 過去のレビューで頻出した指摘
- 「この画面ではここを優先する」という判断軸
を持たせると、AI のレビューがかなり実務寄りになります。
一般論をベースにしながら、自社特有の判断基準も明確に言語化して Skill に含めておくと、新しく加わったメンバーにも「なぜこの観点を重視するのか」が伝わりやすくなります。
3. PR レビューや実装前チェックの中に自然に入れる
アクセシビリティは、後からまとめて確認しようとすると一気に重くなります。
実装が固まってから問題が見つかると、構造の見直しや文言修正、場合によっては画面設計の調整まで必要になり、手戻りが大きくなるからです。
一方で、実装中や PR レビューの段階で拾えるものを先に拾っておけば、修正コストはかなり抑えられます。
ラベルの付け忘れやボタン名の曖昧さといった基本的な問題でも、早く気づけるだけで十分価値があります。
Skill を使う意義は、こうした確認をあとで頑張るものではなく、普段の開発フローの中で自然に行うものに変えられることです。
SKILL例
--- name: a11y-check description: コンポーネントや画面のアクセシビリティチェックを実行する。 argument-hint: "[file-path | pr-number]" --- # アクセシビリティチェック ## 方針 - ルール違反の最小化ではなく、**利用者のつまずきの最小化**を優先する - ネイティブ HTML で表現できるものに ARIA を足す提案はしない - AIが判断すべき「構造の問題」と、人間が判断すべき「体験の問題」を分けて報告する ## ワークフロー 1. 対象ファイルを読み込む（パス指定 or PR差分） 2. [ルールファイルのパス]を読み込む 3. 対象に応じて追加ルールを読み込む 4. チェック実行、結果を3段階で報告 ## 出力フォーマット ### 必ず修正（実利用に影響あり） → AIが検出できる、実際にユーザーが困る構造的問題 ### 確認推奨（状況により対応） → 文脈次第で問題になりうるもの ### 人間レビューへの申し送り → AIでは判断できない体験面の観点 # 共通アクセシビリティルール ## チェックの原則 1. ネイティブ HTML を最大限活用する 2. 実利用に影響がある問題を優先する 3. 過剰な対応を推奨しない --- ## 必ず修正 - `<input>` に紐づく `<label>` がない - 情報を持つ `<img>` に `alt` がない - クリックイベントが `<div>` に付いている - アイコンのみのボタンに名前がない - 見出しレベルが飛んでいる - エラー状態が色のみで示されている ## 確認推奨 - `:focus` スタイルが `outline: none` で消されている（代替のフォーカスインジケータがあるか） - `v-show` でコンテンツを非表示にしている（支援技術から隠す必要があるなら `v-if` を検討） - テーブルのヘッダーが `<th>` でない ## やりすぎ注意（これらは指摘しない） - `<button>` に `role="button"` を付ける（ネイティブ要素は暗黙的にロールを持つ） - 可視テキストがあるボタンに `aria-label`（読み上げが二重になる） - すべてのフォーム要素に `aria-describedby`（ラベルで伝わるなら説明は不要） - あらゆる動的領域に `aria-live`（通知が多すぎると逆にノイズになる） ## 人間レビューへの申し送り観点 - ラベルの文言は本当にわかりやすいか - 画面遷移やフォーカス移動の流れは自然か - エラー発生時にユーザーが迷わず復帰できるか - 操作全体を通してストレスを感じないか
AI と人間、それぞれの得意領域
AI が得意なのは、主に次のような領域です。
- ラベルの欠落
- 代替テキストの未設定
- 要素のロール不整合
- 見出し構造の不自然さ
- 明確な実装ミス
- ルールベースで検出できる WCAG 違反候補
つまり AI は基本的に、構造・属性・ルール・整合性を見るのが得意です。
逆に、苦手なのはこういう領域です。
- この説明文は本当に理解しやすいか
- 画面遷移の流れは自然か
- 読み上げ順は利用者にとって納得感があるか
- フォーカス移動はストレスなく追えるか
- エラー表現は不安なく復帰できるか
- そもそもこの体験設計は使いやすいか
ここには、文脈と経験と感情が入ってきます。そして、この部分はまだ人間のほうが強いです。
つまり、
- AI は仕様をチェック
- 人間は体験をチェック
するのが理想的な役割分担と言えます。
もちろん最近では AI も文脈理解が強くなっており、UI の意味やユーザー意図まである程度推測できるようになっています。
ただ、それでも利用者の感覚やストレスまで完全には代替できません。
だからこそ「過剰なアクセシビリティ」に走らない
「過剰なアクセシビリティはいらない」と言うのは、アクセシビリティそのものを軽視しようという話ではありません。
むしろ逆で、本当に役立つアクセシビリティに集中するために、形式的すぎる対応を減らそうという提案です。
現場ではときどき、AI や自動チェックで大量に指摘が出た結果、次のような状態になります。
- とにかく ARIA を足す
- 読み上げさえ通ればよいと考える
- 例外文脈を無視してルールを適用する
- 実利用では困らない軽微な指摘に時間を使う
- UI 全体のわかりやすさより、警告ゼロを優先する
でも、それは本当にアクセシビリティでしょうか。
たとえば、意味が十分伝わる UI に対して説明を盛りすぎると、スクリーンリーダー利用者にはむしろ冗長になります。
ARIA も、ネイティブ HTML で表現できるものに無理に足すと、かえって複雑さや誤解を生むことがあります。
アクセシビリティは、チェック項目の数ではなく、実際に使えるかどうかで考えるべきです。
だから私は、AI を使うからこそ次の姿勢が大事だと思っています。
「ルール違反を最小化することより、利用者のつまずきを最小化することを優先する」
この順番を間違えると、AI 導入は「より面倒にする装置」になってしまいます。
そうではなく、AI は本質に集中するために、機械で片付くところを機械に任せる装置であるべきです。
実務ではどう進めるとよいか
実際の運用は、かなりシンプルでよいと思っています。
まず Claude Code の Skill に、チームとして重視するアクセシビリティ観点を持たせる。
次に、コンポーネント実装・PR レビュー・画面レビューの各段階で、その Skill を使って機械的に拾える論点を先に出す。
その上で、人間のレビューでは「ルール違反」ではなく「使いづらさ」に集中する。
この分担にすると、レビューがかなり健全になります。
AI は漏れなくチェックし、人間は深くチェックする。
この組み合わせがちょうどいいのではないでしょうか。
まとめ
AI を用いたアクセシビリティチェックは、間違いなく有効です。
Claude Code の Skill のように、観点を再利用できる仕組みと組み合わせれば、チェックはもっと継続的で実務的になります。
ただし、そこで目指すべきなのは、
「すべての指摘をなくすこと」ではなく、「人が使いやすい状態に近づけること」。
AI が見つけるのは問題の候補であり、人間が見つけるのは体験の本質です。
だからこそ、AI を導入した先で必要なのは、アクセシビリティを過剰に形式化することではなく、
"本当に困ること"を見極める判断を、人間側に残しておくことだと思います。
使いやすさに絶対的な正解はありません。ただ、AI で一般的な基準を押さえたうえで、「自分が使う側だったらどう感じるか」をサービスに反映していくこと。まずはそこを大事にしたいと思っています。
