この記事は、Goodpatch Advent Calendar 2025 24日目の記事です。
グッドパッチでエンジニアリングマネージャーをしている大角です。グッドパッチでは2024年に「アクセシビリティ推進プロジェクト」を立ち上げ、社内の有志でさまざまな取り組みを行ってきました。今年のアドベントカレンダーでも色々な取り組みをご紹介しています。
- Webデザインアクセシビリティフィードバック入門
- みんなに寄り添うアクセシビリティ推進
- リンク先、「詳細はこちら」じゃダメなんです── PRが取り組むアクセシビリティ
- 2歩目のアクセシビリティ ── “はじめた” を文化に変える方法
この記事では、生成AIを活用してFigmaデザインのアクセシビリティレビューがどの程度できるか検証した内容を共有したいと思います。（Figmaプラグインもつくったので後述します）
アクセシビリティの難しさ
グッドパッチでは、これまで社内勉強会やコーポレートサイトのアクセシビリティ方針策定・検査など、アクセシビリティに関するさまざまな取り組みを行ってきました。一方で、実際の開発現場では、アクセシビリティに対応できていない部分もまだまだあります。では、実際の開発現場において、どのような課題があるのでしょうか。プロジェクトや人によって課題感は異なると思いますが、大きく３つの課題があるように思います。
理解が難しい
ウェブアクセシビリティの国際的なガイドラインとしてよく取り上げられるものにWCAG（Web Content Accessibility Guidelines）があります。WCAGは網羅的かつ具体的なガイドラインとして重宝されています。一方で、適合レベル、達成基準、具体的な改善方法などについては非常に専門的であるため、みんなが理解して対応するのはなかなか難しいものがあります。その結果、「大事なのは分かるけど、何をすればいいか分からない」という問題が起きます。
そのため、アクセシビリティに取り組む企業では、企業独自のアクセシビリティガイドラインを策定しており、理解しやすくしています。グッドパッチでも社内向けにアクセシビリティガイドラインを作成していますが、それなりに文量は多くなるため、一定のハードルがあります。
対応が難しい
アクセシビリティを理解していても、実際に業務の中で取り組むためにはそれなりの時間が必要です。ちゃんと対応するのであれば、時間をかけて対応すべき部分でもありますが、スケジュールや予算の都合でメンバーが対応したくても対応しきれないケースがあります。さまざまな事業課題がある中でリソースは限られているため、アクセシビリティを対応することの意義や事業的な価値を説明できなければ、優先度を上げることは難しくなります。
あとで修正が難しい
すでにリリースされているWebサイトやモバイルアプリについて、アクセシビリティ検査を実施すると重大な問題が見つかることもあります。しかし、そのタイミングで気づいても修正コストが高く、もはや手遅れな場合もあります。これはアクセシビリティに限った話ではなく、ソフトウェア開発において、あらゆる問題は後工程になればなるほど、修正に時間がかかります。
IBM found that the cost to fix an error found after product release was 4 to 5 times higher than if it’s uncovered during the design phase, and up to 100 more expensive than if it’s identified in the maintenance phase.
IBM は、製品リリース後に見つかったエラーを修正するコストは、設計段階で発見された場合の4～5 倍、保守段階で特定された場合の 100 倍も高くなることを発見しました。
引用元：What’s the True Cost of a Software Bug?
昨今では、生成AIを活用することでデザインや実装の時間を短縮できるようになりましたが、実際の制作現場ではテスト、レビュー、承認プロセスなどが必要になるため、結局のところ修正には時間がかかってしまいます。
結果的にアクセシビリティの品質課題を解決できなかったり、アクセシビリティに詳しい一部のメンバーに相談やレビューが集中することになります。そこで、AIを活用することで効率的にレビューと改善ができないかと考えました。
アクセシビリティのレビューにAIを活用する
最近は生成AIの話題が絶えず、情報洪水に疲れる部分もありますが、人力の課題を解決するためにAIを活用することは有効な手段です。たとえば、コードレビューをしてくれるAIツールとして、僕自身は普段の開発にClaude Code Actionを利用しています。AIによるレビューの良い点は、自身が気づかなかった観点や懸念点を教えてくれることです。これは特に自分の苦手分野を補うものとして役に立っています。
Claude Code ActionによるGitHubのPull Request レビュー
### 📝 プルリクエスト #8 レビュー このPRは、Figma Pluginに「API Key」フィールドを追加する実装です。 全体的に非常によく設計されており、セキュリティとユーザビリティの両方を考慮した実装になっています。 以下、詳細なレビューを提供します。 --- ✅ **優れた点** --- #### 1. アーキテクチャ設計 - **責任の分離**：API Key管理をクライアント側に移行し、バックエンドをステートレスに保つ設計は優れています - **動的クライアント生成**：`createAnthropicClient(apiKey)` パターンにより、ユーザーごとに異なるAPI Keyを使用可能 - **状態管理の一貫性**：既存の `figma.clientStorage` パターンに従い、一貫性のある実装 --- #### 2. セキュリティ対策 - **ローカル保存**：API Keyをサーバー側で保存せず、`figma.clientStorage` に保存する設計は適切 - **バリデーション**：`sk-ant-api03` 形式の検証を実装 - **エラーハンドリング**：無効なAPI Keyに対する明確なエラーメッセージ --- #### 3. アクセシビリティ - **適切なARIA属性の使用**：`aria-invalid`、`aria-describedby`、`aria-labelledby`、`aria-controls` を正しく使用 - **`useId()`の活用**：IDの衝突を避ける実装 - **`role="alert"` の設定**：エラーメッセージにアラートロールを設定
Figmaプラグイン「Accessibility Reviewer」をつくってみた
AIを活用してFigmaデザインのアクセシビリティをレビューするために個人の自由研究として「Accessibility Reviewer」というFigmaプラグインをつくってみました。
本プラグインを利用するためには、事前にClaude API Keyをご準備いただく必要がありますが、API KeyやFigmaの情報はサーバーに保存されないため、興味がある方はご自身の責任の範囲でお試しください。また、APIの利用は従量課金で1回のレビューあたり数円〜数十円かかります。
昨今では、Figmaを使わずに生成AIを活用して最初からコードを実装する機会も増えているため、HTMLを直接レビューする方が良いのでは？という話もあるのですが、以下の理由でFigmaプラグインをつくることにしました。
- コードのアクセシビリティ問題を指摘するツールはすでに多くある（ESLintのPluginやStorybookのaddonなど）
- コードでは判別できないアクセシビリティの問題も多い（情報の論理性や要素同士の関連性など）
- Figmaは現場でも多く利用されており、すぐに活用しやすい
- Figmaであれば、Webサイトに限定せず、モバイルアプリなどのデザインレビューにも使える
Figmaプラグインを使った検証
それでは、Accessibility Reviewerを使って、いくつかのサンプルをもとにレビューを行ってみたいと思います。レビューの題材として、「WebAIM: The WebAIM Million - The 2025 report on the accessibility of the top 1,000,000 home pages」を参考にアクセシビリティのよくある問題の上位３つを検出できるかテストします。
| No | WCAG の失敗種別 | ホームページの割合 |
|---|---|---|
| 1 | コントラストの低いテキスト | 79.1% |
| 2 | 代替テキストの欠如 | 55.5% |
| 3 | フォーム要素のラベル欠如 | 48.2% |
さらにテスト用として、上位３つの問題を意図的に含んだ架空のWebサイトを「Layermate」に生成してもらいました。このFigmaのデザインに対してAIによるレビューを行います。
1. コントラストの低いテキスト
Accessibility Reviewerを使ってレビューした結果、AIによって以下のようなフィードバックが得られました。
検出した要素
AIのフィードバック
⚠️ 課題 ヒーローセクションの説明テキストのコントラスト比が1.98:1で、WCAG AA基準（4.5:1）を満たしていません。ロービジョンのユーザーにとって読みにくい状態です。
💡ヒント テキスト色を #767676（4.54:1）、#696969（5.49:1）、または #595959（7:1、AAA基準も達成）に変更してください。
🔗 関連するWCAGの達成基準 1.4.3 コントラスト (最低限) [AA]
2. 代替テキストの欠如
Accessibility Reviewerを使ってレビューした結果、AIによって以下のようなフィードバックが得られました。
検出した要素
AIのフィードバック
⚠️ 課題 商品画像にプレースホルダーアイコンが使用されていますが、代替テキストの提供方法が不明確です。
💡ヒント 実際の商品画像を使用し、商品名と主要な特徴を含む適切な代替テキストを提供してください。例：「ミニマルウールコート - グレー、テーラードフィット」
🔗 関連するWCAGの達成基準 1.1.1 非テキストコンテンツ [A]
3. フォーム要素のラベル欠如
Accessibility Reviewerを使ってレビューした結果、AIによって以下のようなフィードバックが得られました。
検出した要素
AIのフィードバック
⚠️ 課題 メールアドレス入力欄にラベルが視覚的に表示されておらず、プレースホルダーのみに依存しています。プレースホルダーはラベルの代替にはなりません。
💡ヒント 入力欄の上部または左側に「メールアドレス」などの明確なラベルを追加してください。プレースホルダーは補助的な説明として使用してください。
🔗 関連するWCAGの達成基準 3.3.2 ラベル又は説明 [A]
その他のフィードバック
上記の３つ以外にも以下のようなフィードバックが得られました。全文だと長いため、課題の部分のみ抜粋します。
- 商品説明テキストのコントラスト比が1.67:1で、WCAG AA基準（4.5:1）を満たしていません。商品情報が読みにくく、購入判断に影響する可能性があります。
- フッターのリンクテキストのコントラスト比が3.74:1で、WCAG AA基準（4.5:1）を満たしていません。重要なナビゲーション情報が読みにくい状態です。
- 検索、ユーザー、カートアイコンのターゲットサイズが24×24pxで、WCAG AA基準の最低要件は満たしていますが、より大きなターゲットサイズ（44×44px以上）にすることでタッチ操作の精度が向上します。
一方で、キーボード操作、フォーカス順序、音声読み上げなどはFigmaデザインで評価するのは難しく、コードで動作する環境での確認が必要になりそうです。
実装上の工夫
詳細は別の場でご紹介できればと思いますが、最初はあまりAIのフィードバックの精度がよくなかったので、以下のような工夫を凝らしました。
- LLMに与えるプロンプトの土台を作成するために Claude Code Subagents を活用
- WCAGの適合レベル（A/AA/AAA）の達成基準に基づいてプロンプトをチューニング
- Figmaのノード情報だけでなく、スクリーンショットをLLMのコンテキストに付与
- カラーコントラストを事前に計算して、LLMのコンテキストに付与
- HTMLの仕様や実装よりも、Figma上で改善できるフィードバックを重視
上記の工夫によって、初期から比べるとかなり精度を改善することができました。それでもAIなので不正確なフィードバックを行うこともある点には注意が必要です。今回の検証を通じて、いかにLLMに与えるコンテキストが重要なのかを学ぶことができました。
おわりに
今回、AIを活用してFigmaデザインのアクセシビリティレビューを行ってみました。実際にいくつかのサンプルデータで検証を実施しましたが、思っていたよりも精度が高いフィードバックを得られました。AIによるフィードバックは簡単に実施できるため、普段の業務に取り入れやすくなります。そのため、早い段階でフィードバックを得ることで、作業効率や品質の改善が期待できます。
場合によってはAIにたくさんフィードバックされて「これ全部やらなきゃいけないの…？」という気持ちになるかもしれませんが、レビューの指摘を対応するかは作り手の判断に委ねられます。まずは課題を把握した上で改善が必要だと思うものをピックアップしても良いかと思います。
今回作成したFigmaプラグイン「Accessibility Reviewer」は、まだまだ改善の余地がありますが、AIによるフィードバックやアクセシビリティ向上にご興味がある方は、お試しいただけるとうれしいです。
Goodpatchではデザイン好きなエンジニアの仲間を募集しています。 少しでもご興味を持たれた方は、ぜひ一度カジュアルにお話ししましょう！
