はじめに
プロダクト UI / UX 開発における品質向上において、様々な組織が検討を重ねていると思います。
- デザインレビューをどのように実施するのか
- WCAG 2.2 に準拠したアクセシビリティ改善
上記の課題を解決すべく、アクセシビリティ改善をふまえたデザインレビュー自動化プロセスを検証してみました。
直面した課題
課題① : コンパクトになっていったデザインレビューの文化
これまでのデザインレビューは、まとまった機能を開発する際に、PdM とエンジニア、そしてデザイナーが同期的に Figma を確認をするプロセスをとっていました。
また、開発プロセスに AI ツールが組み込まれたことで、エンジニアが UI を作り、デザイナーがレビューするというケースも増えています。
上記の背景がある中で、加えて事業スピードが加速していることもあり、担当者間のみのデザインレビューを行うことが増えています。
これはリソースや開発規模に合わせた的確な粒度という前向きな考え方もありますが、レビューの質が属人的になるなどの課題も抱えている状態でした。
スピードと品質のどちらの側面もトレードオフにできない状況の中で、下記の AI を活用した記事を拝見し、デザインレビュープロセスを見直し効率化したいと考えました。
課題② : アクセシビリティ改善へのアプローチ
アクセシビリティ改善においても、プロダクトの品質向上のために取り組んでいます。
法人・個人向けプロダクトを開発する中で、ユーザーの皆様に快適にご利用いただくため、UI とデザインシステム構築においての意思決定の判断の観点として取り入れています。
既にご利用いただいているプロダクトへの影響範囲を鑑み、慎重に進めている改善施策の 1 つです。
アクセシビリティ規格は WCAG 2.2 日本語版公式ドキュメントにおいて定められています。
しかし、WCAG 2.2 の膨大な基準を確認するのは時間がかかり、見落としも発生しがちです。
具体的には以下のような課題を抱えていました。
デザイナーとエンジニアが直面する課題
- WCAG 基準の理解が困難：膨大な基準の中から該当項目を見つけるのに時間がかかる
- コントラスト比の測定が手間：外部ツールで確認する必要がある
- 実装時の判断に迷う：複数の改善案がある場合、どれを選択すべきかわからない
そこで検証：自動化されたアクセシビリティチェックプロセス
アーキテクチャ概要
今回検証したプロセスは、以下の 4 つのフェーズで構成されています。
- 事前準備と情報収集
- 技術的検証
- 改善提案の作成
- Figma アノテーション作成
基本的な使用ツール
- Figma Dev Mode MCP：コンポーネント情報の取得
- html.to.design MCP：アノテーションの作成と配置
- WCAG 2.2：アクセシビリティ基準
実装詳細
Phase 1: 事前準備と情報収集
まず、Figma 上の検証対象のコンポーネントを特定し、適用する WCAG 2.2 日本語版公式ドキュメントの基準を決定します。
今回は「知覚可能の中の判別可能」に焦点を当て、以下の達成基準を対象としました。
- 達成基準 1.4.1：色の使用
- 達成基準 1.4.3：コントラスト（最低限）
- 達成基準 1.4.4：テキストのサイズ変更
- 達成基準 1.4.10：リフロー
- 達成基準 1.4.11：非テキストのコントラスト
- 達成基準 1.4.12：テキストの間隔
- 達成基準 1.4.13：ホバー又はフォーカスで表示されるコンテンツ
Phase 2: 技術的検証
Figma コンポーネント情報の取得
Figma Dev Mode MCPを使用して、コンポーネントの詳細情報を取得します。
1. get_image: コンポーネントの画像取得
2. get_code: コンポーネントのコード情報取得
3. get_variable_defs: 使用されている色変数の取得
コントラスト比の自動計算
取得した色情報を基に、WCAG 2.2 準拠のコントラスト比計算を実行します。
この時点で、Figma のコンポーネントのコントラスト比の課題の抽出ができました。
Phase 3: 改善提案の作成
得られた結果を基に、今度は改善提案を作成します。
まず課題を優先度に分けて分類しました。
優先度の分類
- 🔴 緊急：WCAG AA 基準不合格（コントラスト比 4.5:1 未満）
- ⚠️ 重要：改善推奨（フォーカス状態の不備など）
- 💡 推奨：追加改善（AAA 基準への対応など）
具体的な改善提案
次に、各問題に対して以下の情報を含む改善提案を作成します。
- 現在の問題点：値による客観的な評価
- 推奨する改善方法：具体的な色コードや実装方法
- 改善後の予測値：WCAG 基準との照合結果
上記のプロセスを入れることで、課題と改善点を整理しました。
Phase 4: Figma アノテーション作成
html.to.design MCP の活用
最後に、課題と改善点をふまえたデザインレビューとして可視化するため、html.to.design MCP を使用したアノテーションの自動作成を検証しました。
レビューを HTML として構造化し、Figma のキャンバスに直接配置します。
div class="annotation priority-high">
div class="title">🔴 Primary Button 色調整div>
div class="problem">
strong>現在の問題点strong>br>
青色 #347ae2 のコントラスト比が 4.18:1 で
WCAG AA 基準（4.5:1）を満たしていません。
div>
div class="solution">
strong>改善方法strong>br>
#347ae2 → #1d4ed8br>
コントラスト比: 5.74:1 (WCAG AA 基準クリア)
div>
div>
項目別アノテーションの作成
以下のように項目別にアノテーションを分割します。
- 緊急対応項目
- 重要な改善項目
- Figma コメント用テキスト
- 作業の優先順位とサポート情報
この時ただ情報を提示するだけではなく、レビューを見た人が作業しやすいように、わかりやすい言葉遣いと情報を整理してもらうようにプロンプトに組み込みました。
検証結果
実際のアノテーションサンプル
ボタンコンポーネントサンプルを用意して検証をしてみました。
プロンプト入力だけで、以下「左」のアノテーションを Figma に出力することができました。
「右」の Figma Dev モードのアノテーションと比較すると、視覚的にも見やすく、何を優先して作業すべきか整理されています。
改善案のパターン出しまでしてくれているので、デザイナーにとっての作業もスムーズになります。
WCAG のアクセシビリティに準拠したデザインレビューを検証から分析・伝達結果の出力まで自動化することが実現できました。
コントラスト比の算出
整合性の確認
しかしここで、算出されたコントラスト比を鵜呑みにして良いのか疑問が湧きました。
そこで、Stark のアクセシビリティチェックプラグインを利用し差分を確認することにしました。
例として、Disabled ボタンのコントラスト比をアクセシビリティチェックプラグインと比較したところ、Stark の出力が 1.7:1 に対して、AI 出力が 1.7:1 と同数値であり、整合性があることがわかりました。
また、透明度を使用した場合のコントラスト比の計算は微差がありました。
透明度 25% のボタンコンポーネントへの評価を例にあげると、Stark の出力が 1.94:1 に対して、AI 出力が 1.8:1 と微妙なずれがありました。
微妙なずれはあったものの、コントラスト比の判断として申し分ないレベルの差分となっていました。
最終的にはレビューをする人の責任のもと、アクセシビリティチェックツールを併用しつつ数値の整合性の確認をすることが大事であると感じました。
整合性の理由
前述の ＠Docs という機能により、WCAG2.2 の公式ドキュメントをふまえて、相対輝度の計算式を適用することができたため、差分がほぼない状態で値を算出することができました。
（参考：相対輝度 (relative luminance) – WCAG 2.2 日本語版公式ドキュメント）
数値としてだけではなく、人間の視覚やモニター特性をふまえた計算により、人間が目で視るコントラスト比を算出してくれています。
まとめ
効果
このプロセスにより、デザイナーやエンジニアにとって以下のような改善に繋がりそうだと感じました。
- 確認コストの削減：WCAG 基準の参照の手間の削減
- 品質の担保：客観的な数値による根拠のある改善提案
- 再現性の確保：同程度の品質検証を実行可能
- 見落としの防止：自動化によりアクセシビリティチェック項目を確実に検証
チーム全体にとっても、統一された基準による品質管理によって一貫性の確保ができ、プロセスをワークフロー化することで属人化を防止することができるメリットがあると感じました。
今後の展開
今回のような検証の再現性を上げ、チームメンバーが誰でも活用できるワークフローに落とし込んでいくことが次のステップだと感じています。
デザインレビューにおいて効率化・自動化をより拡張させていくことも検討したいと考えています。
- CI/CD パイプラインとの統合：プルリクエスト時の自動検証
- デザインシステム全体の一括検証：複数コンポーネントの並行処理
- レポート機能の追加：検証結果の履歴管理と傾向分析
アクセシビリティ改善は一度対応すれば終わりではなく、継続的な改善が必要です。
ゆくゆくは WCAG 3 も公開されるため、内容を適合させていくことも重要です。
自動化されたプロセスを導入することで、品質の高いデザインシステムを持続的に運用できるようになります。
あらゆる方に快適に利用していただけるように、これからもプロダクトの品質向上と改善に取り組んでいきたいと思います。
参考リンク
最後に
キカガクではデザイナーを積極的に採用募集しております。下記よりご応募をお待ちしております。
AI 、プロダクト開発、デザイン組織、デザインシステム、教育ドメインに関心があるデザイナーと一緒に働けることを楽しみにしています！
HERP
Wantedly
関連記事
Views: 0
