開発現場において、Webアクセシビリティ対応は順調に進んでいるでしょうか。IT企業経営者およびCTOとしてシステム受託開発やAI導入支援に携わる中で、技術とビジネスの狭間における最適解を常に模索しています。
「法対応が必要なのはわかっているけれど、全ページを目視チェックするのは現実的じゃない」
「自動チェックツールを入れたけど、エラーが多すぎて開発者が疲弊している」
現場からは、このような声をよく耳にします。特に2024年4月の改正障害者差別解消法の施行以降、品質保証（QA）チームへのプレッシャーは増すばかりです。そこで多くの現場が期待を寄せるのが、マルチモーダルLLM（大規模言語モデル）を活用した自動診断です。
しかし、技術的な観点から誠実にお伝えしなければならないことがあります。「AIに任せればすべて解決する」という考えは、現時点ではリスクを伴います。LLMは万能ではなく、事実と異なる出力（ハルシネーション）をすることや、単純な計算を間違えることもあります。過度な最新技術の押し付けは、現場の混乱を招きかねません。
だからこそ、ここで提案したいのは「ルールベースとLLMのハイブリッド構成」です。既存の堅実な技術と最新のAIを組み合わせることで、初めて実用的な「工数削減」と「品質担保」が両立します。今回は、誤検知リスクを制御しながら、診断工数を大幅に削減するための具体的なツール開発・実装ガイドをお届けします。
なぜ従来の自動チェックだけでは「法対応」として不十分なのか
まず、なぜ今までのやり方では不十分なのか、技術的なボトルネックを構造的に整理しておきましょう。
ルールベース診断（Axe等）の検知率30%の壁
Webアクセシビリティ診断には、axe-coreのような優れたルールベースのエンジンが存在します。これらはHTMLの構造を解析し、「<html>タグにlang属性があるか」「<img>タグにalt属性があるか」といった構文レベルのチェックを高速に行います。
しかし、一般的な傾向として「自動チェックツールで検知できるアクセシビリティの問題は、全体の約30%に過ぎない」と言われています。
なぜなら、ルールベースエンジンは「属性が存在するか」は判定できても、「その属性値が適切か」までは判断できないからです。例えば、商品画像に対して alt="画像1234.jpg" という代替テキストが設定されていても、ルールベースでは「合格」と判定されます。しかし、スクリーンリーダーを利用するユーザーにとって、この情報は全く役に立ちません。これは意味的（セマンティック）なエラーです。
マルチモーダルLLMが埋める「文脈理解」のギャップ
ここで登場するのが、画像とテキストを同時に理解できるマルチモーダルLLMです。ChatGPTやClaudeなど、視覚機能を備えたAIは、人間と同じようにWebページのスクリーンショット（視覚情報）とHTMLコード（構造情報）を照らし合わせることができます。
「この画像は赤いスニーカーが写っているのに、altテキストが『青い帽子』になっているのはおかしい」
「このボタンは『送信』というラベルだが、見た目は『キャンセル』のようなグレーアウトしたデザインで誤解を招く」
こういった文脈に依存する判断こそ、LLMの独壇場です。これまで人間が目視で行っていた「意味のチェック」をAIが肩代わりすることで、残りの70%の領域にアプローチできるようになります。
なお、APIをシステムに組み込んで運用する際は、モデルのライフサイクルと移行に注意を払う必要があります。例えばOpenAI APIでは、GPT-4oやGPT-4.1などのレガシーモデルが廃止され、より高度な画像理解や長文脈の推論が可能なGPT-5.2が新たな標準モデルへと移行しています。AnthropicのAPIでも、コーディングやPC操作性能が大幅に向上し、100万トークンの長文コンテキストに対応したClaude Sonnet 4.6が最新の標準モデルとして提供されています。
古いモデルに依存したまま運用を続けると、APIの提供終了によって突然システムが停止するリスクがあります。これを防ぐためには、定期的に公式ドキュメントのリリースノートを確認し、APIリクエスト時のモデル指定（例：model="gpt-5.2" や model="claude-sonnet-4-6"）を最新版へ更新する移行プロセスを開発フローに組み込んでおくことが重要です。
また、最新モデルは単に精度が向上しているだけでなく、タスクの複雑度に応じて推論の深さを自動調整する「Adaptive Thinking」機能なども提供されています。こうした最新機能を活用することで、より高度な文脈理解が求められるアクセシビリティ要件の判定にも柔軟に対応できます。
改正障害者差別解消法が求める「合理的配慮」と技術的限界
法律が求めているのは、単にHTMLの文法が正しいことではなく、障害を持つユーザーが「情報にアクセスでき、利用できること」です。これを技術用語で言えば、Syntax（構文）ではなくSemantics（意味）とExperience（体験）の保証です。
従来のツールだけで「チェック済み」としてリリースすることは、法的なリスク管理としても不十分になりつつあります。一方で、すべてのページを人間がチェックするのはコスト的に不可能です。このジレンマを解消する現実的なアプローチが、AIによる意味解析の自動化なのです。
開発・導入前のフィージビリティ検証：LLMは診断に使えるか？
「早速LLMを組み込もう」と走り出す前に、システム全体を俯瞰し、冷静なフィージビリティ（実現可能性）検証を行いましょう。技術的な実現可能性だけでなく、コストと精度のバランスをシビアに見極める必要があります。
主要モデルのアクセシビリティ診断能力比較
最新のベンチマークや技術検証の結果に基づき、主要なマルチモーダルモデルの特性を比較します。なお、AIモデルの進化は非常に速いため、選定時は常に公式ドキュメントで最新の提供状況を確認してください。
OpenAIモデル（ChatGPTおよび最新モデル）:
視覚情報の理解度と推論能力のバランスが優れています。特に複雑なUIのコンテキスト理解において、誤検知が比較的少ないのが特徴です。2025年以降、ChatGPTは標準的なモデルとして定着しましたが、現在はより高度な推論能力を持つChatGPT系（または最新の上位モデル）への移行が進んでいます。用途に応じて、コスト効率の良いChatGPTと、高精度な最新モデルを使い分ける設計が有効です。Claude（Anthropic）:
コードの理解と日本語のニュアンスに極めて強いモデルです。かつて主流だったClaudeのAPI提供は2025年に終了しており、現在はClaude 3.7 SonnetやSonnet 4.5といった次世代モデルが利用可能です。これら最新モデル（特にSonnet 4系以降）はコーディング性能が大幅に向上しており、アクセシビリティ修正コードの提案において非常に質の高いHTML/CSSを出力します。Gemini（Google）:
Geminiは、圧倒的な長文コンテキストウィンドウ（入力可能な情報量）が強みです。ページ全体のHTMLソースコードを丸ごと読み込ませて解析する場合などに有利ですが、UIの細かい視覚的ニュアンスの判定では、OpenAIやClaudeと比較検討が必要です。
現時点での推奨は、診断ロジックにはOpenAIの最新モデル、またはClaudeの最新Sonnetモデル（Sonnet 4.5等）を採用することです。特に具体的な修正案（コード）を生成させるフェーズでは、Claudeシリーズの優位性が目立ちます。
ハルシネーション（嘘の指摘）のリスク評価
LLM最大のリスクはハルシネーション（幻覚）です。「存在しないアクセシビリティ違反を指摘する」ことが頻繁に起こります。例えば、十分なコントラスト比があるのに「見にくい」と判定したり、正しく実装されているARIA属性を「間違っている」と言ったりします。
これを防ぐためには、「客観的な数値計算（コントラスト比など）はLLMにやらせない」という割り切りが重要です。計算はプログラム（ルールベース）で行い、LLMはあくまで「意味の解釈」や「文脈の判断」に徹する。この役割分担がシステム構築の要になります。
コスト対効果の試算（APIコスト vs 人件費削減）
API利用料はモデルの高性能化に伴い変動しますが、QAエンジニアの人件費と比較すれば依然として圧倒的に安価です。
例えば、1ページの目視チェックに専門家が30分かかるとします。時給換算で数千円のコストです。一方、LLMのAPIコールは数十円〜数百円程度で収まるケースが大半です。たとえAIの指摘を人間がダブルチェックするフロー（Human-in-the-loop）を入れたとしても、「明らかな問題箇所の洗い出し」をAIが済ませてくれるだけで、人間の作業時間は大幅に短縮できるという試算になります。
また、最新モデル（Claude Haiku 4.5やChatGPTの軽量版など）を一次フィルタリングに利用することで、コストをさらに抑制しながらカバレッジを広げる戦略も有効です。
実践：誤検知を最小化する「ハイブリッド診断ツール」のアーキテクチャ
ここからは具体的な実装の話に入ります。推奨される「ハイブリッド診断ツール」のアーキテクチャは、以下のようになります。
DOM解析とスクリーンショット解析の役割分担
システムを2つのレイヤーで構成します。
- レイヤー1：ルールベース解析（Axe-core等）
- 役割: 構文エラー、必須属性の有無、コントラスト比の計算など、白黒はっきりつく項目の判定。
- 特徴: 高速、正確、コストゼロ。
- レイヤー2：マルチモーダルLLM解析
- 役割: 画像の代替テキストの適切さ、見出し構造の意味的整合性、フォームラベルの分かりやすさ、キーボード操作の直感性など、文脈依存の判定。
- 特徴: 柔軟、定性的、APIコスト発生。
まずレイヤー1で全ページをスキャンし、機械的に判定できるエラーを洗い出します。その後、レイヤー2でLLMがスクリーンショットとDOMの一部（アクセシビリティツリーなど）を参照し、意味的な診断を行います。最後に両者の結果を統合（マージ）してレポートを出力します。
LLMへの入力プロンプト設計：WCAG基準をどう指示するか
LLMに「アクセシビリティをチェックして」と漠然と頼むのは避けるべきです。WCAG 2.2の具体的な達成基準をコンテキストとして与える必要があります。
プロンプトの構成例（概念）:
役割: あなたはWebアクセシビリティの専門家です。
タスク: 提供されたスクリーンショットとHTML要素を分析し、WCAG 2.2 達成基準 1.1.1 (非テキストコンテンツ) に基づいて評価してください。
入力データ:
- 画像: [ページのスクリーンショット]
- 対象要素:
<img src="banner.jpg" alt="セール実施中">
制約事項:- 画像内の文字情報がalt属性に含まれているか確認してください。
- 画像が装飾目的（意味を持たない）場合は、altが空であることが適切です。
- 推測ではなく、事実に基づいて判定してください。
出力形式: JSON形式（判定結果、理由、改善案）
このように、判定基準を限定し、Chain-of-Thought（思考の連鎖）を促すことで、精度は劇的に向上します。
診断結果の信頼度スコアリング機能の実装
LLMの出力には「確信度（Confidence Score）」を含めると運用が円滑になります。LLM自身に「この指摘にどれくらい自信があるか」を5段階で評価させます。
- スコア5（確実）：明らかなエラー（例：重要な画像にaltがない）。
- スコア1（不確実）：好みの問題かもしれない微細な指摘。
システム側で「スコア4以上のみをレポートに含める」といったフィルタリングを行うことで、開発者へのノイズ（過剰な指摘）を減らすことができます。
運用フローへの組み込みと品質保証（Assurance）
ツールを作って終わりではありません。導入後の運用まで見据え、開発プロセスにどう組み込むかが成功の鍵です。
CI/CDパイプラインでの自動実行とブロッカー設定
GitHub ActionsなどのCI/CDパイプラインに診断ツールを組み込みます。ただし、最初から「エラーがあったらデプロイを止める（ブロックする）」設定にするのは避けましょう。AIの誤検知でリリースが止まると、開発チームの業務フローを阻害してしまいます。
最初は「警告（Warning）」モードで運用し、レポートをSlackなどに通知するだけに留めます。チームがAIの指摘に慣れ、チューニングが進んだ段階で、重大なエラー（ルールベースで検知されたものなど）のみをブロッカーに設定するのが実務的です。
「Human-in-the-loop」：AIの指摘を人間が確定するプロセス
完全自動化を目指さず、「AIが下読みし、人間が最終判定する」フローを構築します。
実務の現場で導入されるツールの一例として、AIが検出したエラー一覧をWeb画面で表示し、QA担当者が「採用（Accept）」か「棄却（Dismiss）」ボタンを押せるようにする仕組みがあります。この「棄却」データは非常に重要です。これを蓄積し、次回のプロンプト改善（Few-shotプロンプティングの事例として利用）に活かすことで、ツールは組織固有の基準に合わせて最適化されていきます。
開発者へのフィードバックループと修正提案の自動化
指摘だけされても開発者は対応に苦慮します。「どう直せばいいか」までセットで提供することが重要です。
LLMの強みはコード生成です。エラー指摘と同時に、「修正後のコードスニペット」を自動生成して提示します。開発者はそれをコピー＆ペーストして微調整するだけで済むため、修正工数が大幅に下がります。これにより、アクセシビリティ対応がスムーズな業務プロセスへと改善されます。
ケーススタディ：内製ツール導入によるBefore/After
実際にこのハイブリッド手法を適切に導入した場合、以下のような業務プロセス改善の効果が期待できます。
診断時間の短縮効果とカバレッジの向上
- Before: QAエンジニア2名が、主要な20ページを目視チェックするのに毎回約3日（24時間）かかっていたとします。リリース頻度が高まる中、チェックが追いつかず、多くのページが未チェックのままリリースされるリスクがありました。
- After: ハイブリッド診断ツールを導入することで、AIが全ページの一次スクリーニングを短時間で完了させることが可能になります。QAエンジニアはAIが指摘した箇所の確認と、複雑な操作系のチェックのみに集中できるようになり、全体の所要時間は大幅に短縮されます。
結果として、診断工数は大きく削減され、チェック対象ページも全ページへと拡大することが見込めます。
アクセシビリティ専門家不足の解消
社内にWCAGの詳細を知る専門家が少なく、属人化が課題となっているケースは少なくありません。しかし、ツールが「なぜこれがWCAG違反なのか」という解説付きでレポートを出してくれるため、開発者が診断結果を見ながら自然とアクセシビリティの知識を身につけるようになります。ツールが教育プラットフォームとしての機能も果たし始めるのです。
リリース判定基準への適用事例
運用開始から一定期間が経過し、診断の精度が安定した段階で、「レベルA（最低限の基準）の違反ゼロ」をリリースの必須条件（Quality Gate）に設定する運用も可能です。AIによる常時監視があることで、意図しない品質低下（リグレッション）を確実に防げるようになり、チーム全体に「品質への自信」が生まれます。
まとめ
Webアクセシビリティ診断におけるAI活用は、もはや「実験」の段階を超え、「実務」のフェーズに入っています。
重要なのは、「AIかルールベースか」ではなく「AIとルールベース」というハイブリッドな思考です。そして、AIを「審判」ではなく「優秀なアシスタント」として位置づけ、最終的な品質責任は人間が持つという設計思想（Human-in-the-loop）を忘れないことです。
もし、手動チェックの限界を感じているなら、まずは小さくプロトタイプを作って検証することをおすすめします。数枚のスクリーンショットをAIモデルに入力してみるだけでも、その実用性に気づくはずです。
アクセシビリティ対応は、法令順守のためだけではありません。すべてのユーザーに使いやすいプロダクトを届けることは、ビジネスの成長そのものです。テクノロジーの力で、その障壁を構造的に解決していきましょう。
コメント