Claude でアクセシビリティチェックはどこまで自動化できるか

ウェブアクセシビリティのチェックを、有料の自動チェックツールを使わずに Claude だけでどこまで回せるかを検証しました。独自チェックリストの 67 項目のうち 50 項目は、人を介さずに合否まで確定できました。残る 17 項目は無理に自動化せず「要確認」として切り分けています。この記事では、組み合わせた手段と手順、判定できた範囲、人が見るべき限界を順に紹介します。

---

アクセシビリティ対応が求められる背景

2024 年 4 月 1 日に障害者差別解消法が改正され、これまで国や地方公共団体に義務付けられていた「合理的配慮の提供」が、民間事業者にも義務化されました。合理的配慮とは、障害のある人から申し出があったときに、過重な負担のない範囲で対応することです。

その前提となる「環境の整備」として求められているのが、ウェブアクセシビリティ対応です。環境の整備は法律上は努力義務ですが、企業が取り組む必要性は年々増しています。ウェブアクセシビリティは、障害の有無や年齢、利用環境にかかわらず、あらゆる人がウェブの情報やサービスを利用できることと、その到達度を指します。

恩恵を受けるのは、視覚・聴覚に障害のある人や色覚特性のある人だけではありません。加齢で視力や聴力が低下した人、けがや病気で一時的に目や耳が使えない人、暗い場所や騒がしい場所で使っている人など、誰にでも起こりうる状況も含まれます。

WCAG 2.2 とレベル AA

基準として国際的に使われているのが、W3C の WAI が公開している WCAG（Web Content Accessibility Guidelines）です。すべての達成基準は、知覚可能・操作可能・理解可能・堅牢の 4 原則に基づいています。

最新版は 2023 年に勧告された WCAG 2.2 です。WCAG 2.2 は 2025 年に ISO/IEC 40500:2025 として国際規格化され、国内規格の JIS X 8341-3 も 2026 年度中に改正版が発行される見込みです。WCAG は後方互換性があるため、2.2 に適合すれば 2.1・2.0 にも適合します。

達成基準には A・AA・AAA の 3 つの適合レベルがあり、上位のレベルに適合するには下位の基準もすべて満たす必要があります。

今回の検証は、WCAG 2.2 のレベル AA を対象にしています。

人手中心のチェックで膨らんでいたコスト

これまでのチェックでは、チェックリストの項目を 1 ページずつ確認していました。有料の自動チェックツール（axe DevTools など）も併用していましたが、ツールで確認できるのは一部で、半分以上の項目は目視でのチェックが必要でした。人員・時間・ツール費用のいずれも大きなコストになっていました。

チェックリストにも苦労がありました。当初はウェブアクセシビリティ基盤委員会（WAIC）が公開しているチェックリストを使っていましたが、達成方法の説明が専門的で、何をどう確認すればよいかを読み解くのに時間がかかりました。チェックする人によって解釈がずれることもあり、そのたびにメンバー間で認識を合わせる時間を取っていました。

そこで他社が公開しているチェックリストも参考に、確認方法を平易な日本語で書いた独自チェックリストを作りました。読み解く時間は減りましたが、人がチェックすることには変わりありません。ページ数が増えたりページが複雑になったりするほど、チェックの時間は伸びていきました。

チェック以外にかかる作業

チェックそのもの以外にも、次の作業が発生します。

• 対象ページの抽出: クライアントからページ一覧をもらえない案件では、サイトを巡回して人力で洗い出す
• 結果レポートの作成: テンプレートに沿って結果をまとめる
• 対応指示書の作成: 修正が必要な箇所ごとに修正方針と具体的な対応例を書き、開発者に渡す

特に対応指示書はすべて人が一から書いていたため、ページ数や修正箇所が多いほど記入量が増え、書く人の大きな負担になっていました。

検証の条件と、組み合わせた 4 つの手段

こうした背景から、「従来の自動チェックツールを使わずに、Claude で効率よく精度の高いチェックを実現できるか」を検証しました。担当している案件でちょうどアクセシビリティ改修があったため、その改修のチェックと再チェックに Claude を使っています。

チェックには、機械的な検査から意味の判定まで、性格の違う 4 つの手段を組み合わせました。

6 つのステップを Claude のスキルにする

これらを一連の流れとして自動で実行できるよう、Claude のスキルとして作成しました。スキルを作るときは、デジタル庁の「ウェブアクセシビリティ導入ガイドブック」も参考にしています。WCAG の公式文書には書かれていない、画像の代替テキストの文字数の目安のような実務寄りの情報が載っているためです。

当初は結果を Google スプレッドシートに出力したかったのですが、うまくいかなかったため Excel（xlsx）での出力に切り替えています。

67 項目中 50 項目を自動で判定できた

独自チェックリストの 67 項目のうち、約 75% にあたる 50 項目は、ツールによる検査・ブラウザの実操作・Claude の読解によって、人を介さずに「合格・不合格・対象外」まで確定できました。

残る 17 項目は、スクリーンリーダーの実際の聞こえ方のように、人にしか最終判断できない領域です。ここは無理に自動化せず、明確に「要確認（目視判定推奨）」として報告するようにしました。

Claude が出力したチェックリストには、項目ごとに適合結果とその判定根拠が備考欄に記録されます。対応指示書も、人が書いていたものと同じ形式で、修正方針から HTML/CSS の修正例まで書かれた状態で出てきます。修正項目の中には、従来の自動ツールと人の目視の両方で見落としていた箇所を Claude が拾ったケースもありました。

意味の理解が要る項目も判定できた

これまで人が判断する前提だった、文言の意味を読まないと判定できない項目も、Claude が読解して判定できました。

• リンクテキスト: すべてのリンクを読み、リンクテキスト単体で遷移先が分かるかを判定する
• 見出し・ラベル: 内容を的確に表しているかを判定する
• ページの言語: 本文の言語と lang 属性が一致しているかを確認する
• 代替テキスト: 画像の alt が意味のない値になっていないかを判定する

たとえば「詳細はこちら」のようなリンクや、URL をそのままリンクテキストにしているケースはよく見かけます。これらはアクセシビリティの観点では不合格で、リンク先が何かを判断できるテキストに書き換える必要があります。この判断を Claude 側で確定できました。

Claude in Chrome で操作系の項目も確定できた

当初は「要確認」に分類していた項目の多くも、Claude in Chrome でブラウザを操作し、その結果をコードで観測することで確定できました。

特にキーボード操作は、これまで使っていた自動ツールではチェックできず、目視で確認していた項目です。Claude in Chrome がキーボードで操作し、ショートカットキーの設定有無まで確認してくれたことで、この部分の手作業がなくなりました。

自動化の限界と、人が見るべき項目

一方で、兆候は自動で確認できても、最終判断に人の目や耳が要る項目は残りました。技術的な制約や、実害を避けるために人が確認すべき項目もあります。

1. スクリーンリーダーの読み上げ: 読み上げの不自然さは Claude も指摘できますが、最終確認は実機で行います
2. 320px 幅・200% ズーム時の表示: Claude in Chrome では環境の制約で再現できず、到達できる幅で確認するにとどまります
3. 点滅・光過敏性: 点滅の頻度は計測できますが、人への影響は目視で判断します
4. 動画・音声の代替: 字幕や代替テキストが内容と一致しているかは、人が見聞きして照合します
5. 決済・契約の実送信: 問い合わせフォームや EC サイトの購入・決済画面は、確認画面の表示までにとどめます

最後の項目は特に注意が必要です。Claude in Chrome は購入や送信の手前まで操作を進められるため、本番環境で実際に送信させると、実データの登録や情報漏洩につながるおそれがあります。フォーム周りはアクセシビリティだけでなく UX の観点も絡むため、人が自分で操作して点検する価値もあります。

検証課題への答えと、人と Claude の役割分担

「従来の自動チェックツールを使わずに、Claude で効率よく精度の高いチェックを実現できるか」という課題に対しては、実現できると判断しました。

ただし 1 画面あたりの所要時間は、ページの難易度やチェックする人の慣れによって変わります。1 時間で済む画面もあれば、複雑な画面では半日以上かかることもありました。

この結果から、判定と記録は Claude、最終判断と対応は人という役割分担にしています。

自動化で得られたもの

自動化によって、次の変化がありました。

• 工数・コストの削減: 手作業の確認の多くを自動化し、人が見るべき範囲を「要確認」の 17 項目に絞り込めた
• 担当者によるブレの解消: 判定のルールがスキルに統一されているため、誰がチェックしても結果が変わらない
• 修正への着手が早くなる: 不合格の指摘に HTML/CSS の修正例が付いた指示書が出るので、開発者がすぐ修正に取りかかれる
• ほかの業務への応用: 機械判定・実操作・AI の文脈理解の組み合わせは、ブラウザで行う QA テストなどにも使えそう

これまで人力でやっていた作業を振り返ると、手間のかかり方に改めて驚くほどでした。

運用で気をつけること

自動化にあたっては、次の点に気をつけています。

1. 結果を過信しない: Claude の判定にも誤りはありえます。結果の責任は使う人と組織にあるため、最終確認は人が行います
2. 自動化できる範囲には限界がある前提で運用する: 判定できない項目がある前提で、検出ロジックを継続的に見直します
3. 認証情報を扱わせない: パスワードなどの認証情報は Claude に入力させず、認証と決済の操作は人が行います
4. 本番環境で送信しない: フォームの送信を伴う確認は、検証環境や開発環境で行います

社内のほかの手法と統合して展開する

社内の別案件でも、別のメンバーが Claude を使ったアクセシビリティチェックに取り組んでいます。手法が同じか違うかはまだ分かっていないため、まず話を聞き、双方の良い点を取り入れて手法を統合する予定です。そのうえで判定ロジックや出力形式を見直して精度と効率をさらに高め、誰が担当しても同じ品質でチェックできる手順として、ほかの案件にも展開していきます。

スクリーンリーダーの読み上げのように今は人が確認している項目も、Claude の精度が上がれば、いずれ人の確認を通さずに済むようになるかもしれません。それまでは、人が見るべき項目を明確に切り分けたうえで、Claude に任せられる範囲を広げていきます。

アクセシビリティ要件を含めたデザインと実装を AI 駆動で進める取り組みとして、AIDD デザインを提供しています。アクセシビリティ対応のチェック体制や、AI を活用したデザイン・開発の進め方にお悩みの方は、お気軽にご相談ください。