enechainプロダクトデザインデスクの近藤（@add_kk）です。
今回は認証環境でも動く、WCAG・APCA両対応、AIによる意味的評価まで。デザイナーがClaude Codeと5日間で作ったアクセシビリティチェックツールの話です。
以前、WCAG 2.xとAPCAのコントラスト評価について書いた記事で、コントラストの「実感とのズレ」に向き合う話をしました。数値は合格でも読みにくい、という体験をデザイナーとして何度もしてきたからこそ書いた記事です。
ただ書いた後も、もやもやが残っていました。知識はある、でもチェックする仕組みがない。
axe DevToolsやLighthouseといった既存ツールでも、ブラウザで開いているページをその場でチェックすることはできます。PlaywrightやPuppeteerとaxe-coreを組み合わせて自動化する方法もありますが、認証フローの実装や環境構築のコストがかかり、デザイナーが自分で用意するには敷居が高い。結局「気になったときに手で確認する」運用から抜け出せていませんでした。
そんな課題感を持っていた頃、Vercel が Agent Browser をリリースしました。
きっかけ：Agent Browserを試したかった
Agent Browserは、AIがブラウザを実際に操作しながらタスクをこなせる仕組みです。人間がブラウザでページを開いて確認するのと同じように、ログイン・ページ遷移・画面の読み取りまでをAIが自動でやってくれるイメージです。
「これ、アクセシビリティチェックと相性いいのでは？」と直感的に思いました。
実際にブラウザを操作できるということは、認証フローを自動で通した後の画面も、VPN内のプロダクトも、そのままチェックできます。まさに自分が欲しかったものでした。
「試してみよう」と思ったら、Claude Codeを開いていました。
Claude Codeと一緒に作り始める
URLを入力するとWCAG・APCA・AIの3つの観点でアクセシビリティを評価し、100点満点のスコアとレポートを生成するツールです。メインのプロダクトデザインをこなしながら、隙間時間にClaude Codeと相談しながら開発を進め、最初の思いつきから約5日でここまで育ちました。
Agent Browserを使えば、認証フローの実装などを自分で書かずとも、ブラウザ操作をAIに任せられます。axe-coreはアクセシビリティチェックの業界標準ライブラリ。この2つの組み合わせが、最初のアイデアの核でした。
どんな進化をたどったかを振り返ると、こうなります。
| 追加した機能 | |
|---|---|
| 1日目 | axe-core + Claude APIによる2層評価、CLIのみ。その後Claude Code CLIに切り替えてAPIキーを不要にし、Web UIも追加 |
| 2日目 | 認証付きページへの対応（ログインと検証を分離、--headed / --headers オプション追加） |
| 3日目 | Notion貼り付け用のMarkdownコピー機能追加 |
| 4日目 | Claude Codeスキル版（/a11y-check）を追加。Notion書き出し・認証オプションもスキルに反映 |
| 5日目 | 100点満点スコア、AI総評コメント、APCAコントラスト評価を追加。axe-core + APCA + AIの3エンジン構成完成 |
CLIのみだったものがWeb UI → スキル版の3形態に、axe-coreだけだった評価エンジンがAPCA・AIを加えた3エンジン構成へ。ひとつ動くものを作っては「これも欲しい」を足していく進め方が自分には合っていました。
ツールの設計：3つの評価軸
育てていくうちに、3つの評価軸が揃いました。Agent Browserがページを開いてアクセシビリティツリーと色情報を取得し、それを3つのエンジンに渡す構成です。
Layer 1 — axe-core（WCAG自動チェック）
コントラスト比、見出し構造、フォームラベル、ARIA属性など、WCAG 2.x準拠のチェックを高速・決定論的に行います。業界標準のエンジンなので信頼性が高いものです。
Layer 2 — APCA checker
前回の記事で書いたように、WCAGのコントラスト比は「数値は合格でも読みにくい」ケースが起きます。APCAはフォントサイズ・ウェイトを考慮した、より知覚に即したコントラスト評価です。この実感があったからこそ、WCAGと並べてAPCAも評価軸に入れました。両方に対応したチェックツールはまだ少なく、並べて確認できるのはこのツールの特徴のひとつです。
Layer 3 — Claude AI（意味的評価）
altテキストの質、リンク名の適切さ、読み上げ順序など、ルールベースでは検出できない意味的・文脈的な問題を評価します。自動チェックは「altテキストが空かどうか」は検出できても「意味的に適切かどうか」は判断できません。ユーザー体験の観点で考えると、後者の方が重要なケースも多い。AIがその部分を担います。決定論的な評価では拾えない部分をAIが補う、という組み合わせです。
この3つの評価軸の結果を重大度で重み付けして、100点満点のスコアとして出力します。専門の異なるエンジンが並列で動いて、結果をひとつに統合する構成です。
以下、あるWebサイトの検証結果例です。
スコアはあくまで目安ですが、重み付けを何度か調整して表示するようにしました。
不合格、要確認項目は具体的なフィードバックが返されます。この部分のデザインはいかにもAIの生成したもののままですが、今回はあくまで確認のためのツールなので、あまりこだわりません。
使い方
Web UI（推奨） — ターミナルを開かなくても使えるよう、start.command というファイルを用意しました。ダブルクリックするだけでローカルサーバーが起動してブラウザで開きます。
Claude Code スキル — Claude Codeから直接呼び出せます。用途に応じてオプションを使い分けられます。
-notion <url>: 結果をNotionページに書き出し-standard apca: APCA基準で評価-skip-ai: AI評価をスキップして高速化
これからどう使いたいか
自社のデザインシステムと各プロダクトへの定期チェックに組み込んでいきたいと考えています。
評価基準の拡張
standards/ ├── wcag-2.2.md # WCAG 2.2（デフォルト） ├── wcag-2.1.md # WCAG 2.1 ├── apca.md # APCA コントラスト基準 └── custom-example.md # カスタム基準のテンプレート
現在はWCAG・APCAに対応していますが、standards/ ディレクトリに基準ファイルを追加することで他の基準にも対応できます。JIS X 8341-3やSection 508、WAI-ARIAへの対応はもちろん、Human Interface GuidelinesやMaterial Designのガイドライン準拠度チェックにも使える。ニールセンのヒューリスティクスを元にしたユーザビリティ評価への応用も面白い。アクセシビリティ専用ツールとして作り始めましたが、UI品質評価ツールとして育てていける余地があります。
改善フローへの組み込み
さらに先の構想として、このツールを起点にした自律的な改善フローも考えています。要対応項目が検出されたら、DevinやClaude Codeが自動で修正してPRを出す。「チェックして終わり」ではなく、検出から修正まで一気通貫で回す。そうすることで、アクセシビリティ対応のコストを大きく下げられます。
おわりに
これまでは、やりたいことに一番近いツールやプラグインを探すしかありませんでした。ピッタリのものがなければある程度は妥協し、運用でカバーしていました。
でも今は、自分たちの業務やフローに合わせてオーダーメイドで作れる時代です。エンジニアでなくても、アイデアがあれば形にできる。運用・手動でのカバーも最小にできます。
このツールはその一例に過ぎませんが、「作らなければ始まらない」という感覚を、デザイナーの方にも持ってもらえたら嬉しいです。
enechainでは開発メンバー以外も含めて全社でClaude Codeを導入して、AIの活用に全力で取り組んでいます。一緒にプロダクトと事業、会社を成長させていく仲間を募集していますので、興味のある方はぜひTech Recruit Portalをご覧ください。
