axe DevToolsとは：拡張機能の使い方とaxe-core CI連携、自動検出の範囲と手動確認の切り分け

axe DevToolsは、米Deque Systemsが提供するアクセシビリティ検査ツールです。ブラウザの開発者ツールに「axe DevTools」タブを足す拡張機能が入口で、中で動いているのはオープンソースの検査エンジンaxe-core。この記事では、拡張機能の使い方と無料版・Pro版の違い、axe-coreをCLIとPlaywrightでCIに載せる設定、そして自動チェックで検出できる範囲と手動確認が必要な項目の切り分けを、2026年11月時点の公式情報から整理します。

まとめ：axe DevToolsで自動検出できる範囲と手動確認に回す項目の線引き

axe DevToolsの価値は、機械で判定できる違反を短時間で、誤検知をほとんど出さずに洗い出せる点にあります。無料の拡張機能でもページ全体のスキャンと修正方法つきのレポートまで使えるため、まずはこれで十分です。

ただし自動で見つかるのは一部だけ。Deque自身がaxe-coreのREADMEで示す見積もりは「平均でWCAGの問題の57%」です。キーボード操作の順序、代替テキストの中身の妥当性、読み上げの意味の通り方は、手で確かめるしかありません。

実務の型は3段で組みます。手元では拡張機能、プルリクエストではaxe-coreをCIで自動実行、残りは手動の検査表で消し込む。違反の件数だけでなく「要確認（incomplete）」の件数も合格条件に入れること。ここを外すと、緑のまま未判定が積み上がります。

axe DevToolsの正体：axe-coreを積んだ拡張機能と無料版・Pro版の機能差

名前が似た製品が多いので、まず構成要素を分けておきます。

拡張機能・axe-core・axe Monitorの3つを混同しないための整理

Dequeのaxe製品は大きく3層です。最下層がGitHubで公開されているaxe-coreで、Mozilla Public License 2.0で配布されるJavaScriptライブラリ。その上に開発者が手元で使う拡張機能axe DevToolsが載り、さらに本番サイトを定期巡回して監視する別製品axe Monitorがあります。

判定ロジックは共通で、どの入口から走らせても同じaxe-coreのルールが効きます。拡張機能で出た違反がCIでも同じルール名で出るのはこのためです。巡回監視の機能と導入判断はaxe Monitorとは？Dequeのサイト巡回型アクセシビリティ監視ツールの機能・対応規格・導入判断で扱っています。

2026年11月時点の版：拡張機能4.140.0とaxe-core 4.14系の対応関係

Chromeウェブストアの掲載では、拡張機能の版は4.140.0、更新日は2026年10月29日、利用者は40万人です。エンジン側はnpmレジストリ上のaxe-coreが4.14.0（2026年10月5日公開）で、Playwright連携の@axe-core/playwrightとCLIの@axe-core/cliも同じ4.14.0に揃っています（いずれも2026年11月2日時点）。

拡張機能とCIで結果を突き合わせるときは、axe-coreのマイナー版を揃えてください。ルールの追加や判定の修正はマイナー版で入るため、版がずれると「拡張機能では0件、CIでは2件」という食い違いが起きます。Pro版にはaxe-coreの版を選ぶ設定があり、この食い違いを潰せます。

無料版でできることとPro版で増える機能：部分スキャンとIGTの差

Deque公式の拡張機能ドキュメント（日本語版）によると、無料版はフルページスキャンと、問題ごとの詳細レポート（ハイライト、CSSセレクタ、ソースコード、修正方法、ルールのヘルプ）まで使えます。Pro版で増えるのは次の機能です。

• 部分ページスキャン（コンポーネント単位の検査）
• インテリジェントガイドテスト（IGT）
• テストの保存・エクスポート・共有
• ユーザーフロー分析
• 自動カラーコントラスト解決とaxe-coreの版選択

実務での差が大きいのは上の2つです。IGTは、表・キーボード・モーダルダイアログ・フォームなど、自動では判定できない領域を質問形式で案内する機能。手動確認の手順を人に依存させないための仕組みと捉えると、Pro版を買う理由がはっきりします。対応ブラウザはChromeとEdgeで、Firefoxは制限版です。

Chrome拡張機能をインストールしてフルページスキャンを実行する手順

手元での使い方は数分で覚えられます。迷いやすいのは結果の読み方のほうです。

開発者ツールのaxe DevToolsタブからスキャンを始める4つの操作

1. Chromeウェブストアの掲載ページから拡張機能を追加する
2. 検査したいページで開発者ツールを開く（WindowsはCtrl＋Shift＋I、macOSはCmd＋Option＋I）
3. 「axe DevTools」タブを選ぶ（タブが多いと「その他のタブ」に隠れる）
4. 開始画面で「フルページスキャン」を押す

サインインは必須ではなく、無料版の範囲ならそのまま結果が出ます。スキャンは「いま画面に描画されている状態」だけが対象です。モーダルやアコーディオンは開いた状態と閉じた状態で2回走らせてください。

結果画面の4分類と、影響度criticalからminorまでの読み方

公式のスキャン手順ページでは、結果は「自動の問題」「ガイド付きの問題」「要確認」「ベストプラクティス」に分かれます。影響度は4段階で、axe-coreのAPIではcritical・serious・moderate・minorの値になります。

直す順番は影響度順で構いません。ただし「要確認」を後回しにしないこと。背景画像やグラデーションの上の文字のように、axe-coreが確信を持てず判定を保留したものがここに入ります。違反ではないので件数表示が目立たず、放置されやすい区分です。色の判定が保留される条件と始末の付け方はWebアクセシビリティのコントラスト比：4.5対1と3対1の適用範囲・CSS実装・自動検証の落とし穴で詳しく扱っています。

ベストプラクティス区分の違反をWCAG適合の判定から分けて扱う

ベストプラクティスは、WCAGの達成基準には必ずしも該当しないが体験を良くする慣行です。heading-order（見出しレベルの飛び）やregion（ランドマーク外のコンテンツ）がここに入ります。

報告書でこの区分をWCAG違反と同じ表に並べると、「適合していない」という誤った結論になります。発注者向けの報告ではWCAG由来の違反と分けて書き、改善提案として扱ってください。

axe-coreをCLIとPlaywrightで動かし、拡張機能と同じ検査をCIに載せる

拡張機能は人が開いたページしか見ません。回帰を止めるには同じエンジンをCIで回します。

@axe-core/cliで複数URLを検査し、違反があれば終了コード1で止める

最短の入口はCLIです。axe-core-npmのCLIのREADMEに沿うと、次の手順で動きます。

npm install -g @axe-core/cli
npx browser-driver-manager install chrome

axe https://example.com https://example.com/contact \
  --tags wcag2a,wcag2aa,wcag21a,wcag21aa \
  --include "main" \
  --load-delay=2000 \
  --save axe-result.json \
  --exit

--exitを付けると、いずれかのルールが不合格のとき終了コード1で終わり、CIのジョブが落ちます。--load-delayはミリ秒単位の待機で、描画が遅いSPAで要素が出る前に検査が終わる事故を防ぐための指定です。ログインが要る画面や操作後の状態はCLIでは作れないため、次のPlaywright連携に進みます。

Playwrightと@axe-core/playwrightで状態を作ってから検査する

Playwright公式のアクセシビリティテストのページは、AxeBuilderでページを検査する書き方を示しています。モーダルを開いた状態で検査し、違反と要確認の両方を失敗条件にする例です。

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('お問い合わせモーダルにWCAG AAの違反が無い', async ({ page }) => {
  await page.goto('/contact');
  await page.getByRole('button', { name: '相談する' }).click();

  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa'])
    .include('[role="dialog"]')
    .analyze();

  expect(results.violations).toEqual([]);
  expect(results.incomplete).toEqual([]);
});

導入はnpm install -D @axe-core/playwrightだけです。withTagsで検査範囲をWCAGのA・AAに絞ると、ベストプラクティス区分がCIを落とすことはありません。既知の問題で一時的に止めたい箇所はexcludeやdisableRulesで外せますが、外した理由をコードコメントに必ず残しましょう。Playwright自体の仕組みはPlaywright（プレイライト）とは？仕組み・できること・Seleniumとの違いを解説を参照してください。

結果オブジェクトの4配列とタグ指定でCIの判定範囲を固定する

axe-coreのAPIドキュメントでは、結果はpasses・violations・incomplete・inapplicableの4配列です。inapplicableは対象要素が無く走らなかったルールで、「表のルールが通った」のではなく「表が無かった」ことを意味します。

タグはWCAGの版とレベルの組で指定します。WCAG 2.2で追加された基準を測るつもりでwcag22aaを足しても、該当ルールはtarget-sizeの1本だけで、しかもルール一覧には「既定で無効」と明記されています。2.2対応を自動検査だけで証明することはできません。

自動チェックで検出できる範囲と、手動確認が必要な項目の切り分け表

ここが導入判断の中心です。自動で拾えるものと拾えないものを、達成基準の単位で分けます。

axe-coreのルール105本の内訳と、要確認に回るルールの多さ

ルール一覧を数えると、WCAG 2.0のA・AAが60本、2.1が3本、2.2が1本、ベストプラクティスが27本、AAAが3本、実験的ルールが6本、非推奨が5本で、合計105本です（2026年11月2日時点）。そのうち64本は、判定を確定できない場合に「要確認」を返す可能性があります。

READMEは「バグを除き偽陽性はゼロ」と宣言しています。裏返せば、確信が持てないものは違反に数えず要確認へ送る設計です。偽陽性ゼロと検出漏れゼロは別物で、この設計の帰結として、自動検査の結果は「見つかったものは確実に直す」「見つからなかったものは何も保証しない」と読む必要があります。

自動で判定できる項目と、人の目と操作でしか判定できない項目の区別

傾向ははっきりしています。「属性があるか」「値が仕様上正しいか」は自動、「その中身が利用者にとって正しいか」は手動です。手動側の優先順位を付けるなら、キーボードだけで全操作を終えられるかを最初に確かめてください。ここが壊れていると他の項目を直しても使えません。読み上げの実機確認はWebアクセシビリティのスクリーンリーダー対応：NVDA・VoiceOverでの実機検証と読み上げ順序の設計で手順をまとめています。

57%という検出割合を発注や報告の数字に使うときの前提と注意点

57%はDequeが自社の検査データから示した平均値で、個別のサイトでの検出率を保証する数字ではありません。フォームと動的UIが多い業務システムでは手動側の比率が上がり、静的なコーポレートサイトでは下がります。

報告書に「自動検査で違反0件」とだけ書くと、残りが未検査であることが読み手に伝わりません。自動検査の対象ページ数・タグ・axe-coreの版を書き、手動で確認した項目と未確認の項目を並べて示しましょう。自動・手動・当事者検証の3層で診断を組む考え方はWebアクセシビリティ診断の進め方：自動・手動・当事者検証の三層設計と外注の判断基準で扱っています。

axe DevTools Pro・axe Monitor・無料版の採用条件と見送り判断

最後に、どれを使うかを条件で言い切ります。

無料版とaxe-coreのCI組み込みだけで足りる開発体制の条件

次の条件がそろうなら、有償製品は不要です。検査対象が自社で開発しているWebアプリで、CIにPlaywrightなどのE2Eテストが既にある。手動確認の担当者がWCAGの達成基準を読める。この場合は、手元の無料拡張機能と、E2EにAxeBuilderを足すだけで回ります。Dequeの料金ページは2026年11月2日時点で価格の数値を掲載しておらず、Pro版は無料トライアル、Bundleは営業への問い合わせです。費用を見積もれない製品を最初から組み込む必要はありません。

Pro版を選ぶ条件と、axe Monitorまで要るサイト規模の目安

Pro版が効くのは、手動確認をアクセシビリティの専門家でない開発者やQA担当に任せる体制です。IGTが質問形式で確認手順を固定してくれるため、担当者による判定のばらつきを抑えられます。部分ページスキャンで、デザインシステムのコンポーネントを1つずつ検査したい場合も向いています。

axe Monitorは対象が違い、CMSで編集者が日々ページを増やす数百ページ規模の公開サイト向けです。開発の外で増えるコンテンツはCIを通らないので、巡回監視でしか拾えません。

自動チェックの結果だけで規格への適合を対外的に宣言してはいけない場面

見送るべき場面も明記します。JIS X 8341-3やWCAG 2.2のAA適合を対外的に表明する場合、axe DevToolsの結果だけを根拠にしてはいけません。要確認と手動項目が残ったままの「違反0件」は、適合の証明になりません。規格側の達成基準とレベルの構成はWCAGとは？最新版2.2の4原則・達成基準86件とAA適合の範囲で確認できます。

公共・金融・医療など適合表明が契約条件になる案件や、手動確認の担当者を社内で立てられない場合は、自動検査を土台にしたうえで手動診断を外部に頼むほうが早く終わります。検査範囲の決め方から相談したい場合は、Webアクセシビリティ対応で対応範囲を確認してください。

axe DevToolsでよくある質問｜検出率・料金・Lighthouseとの違い

導入時によく挙がる疑問を5つ取り上げます。

axe DevToolsは無料でどこまで使えますか？

拡張機能の無料版で、ページ全体のスキャンと、問題ごとのハイライト・CSSセレクタ・修正方法・ルールのヘルプまで使えます。部分ページスキャン、IGT、テストの保存やエクスポートはPro版の機能です。エンジンのaxe-coreはMPL 2.0のOSSなので、CLIやPlaywrightでの自動実行は無料のまま組めます。

Lighthouseのアクセシビリティスコアとaxe DevToolsの結果は何が違いますか？

Lighthouseのアクセシビリティ監査も内部でaxe-coreのルールを使っていますが、使うのは一部のルールで、結果を重み付けした点数に変換します。axe DevToolsはルールごとの違反と要確認を要素単位で返すため、修正作業にはこちらが向きます。スコアの仕組みはLighthouseのSEOスコア・Best Practicesの配点と見方｜5カテゴリの採点基準【v13.5.0】、CIでの点数判定はLighthouse CIの使い方｜lighthouserc・assertの判定とGitHub Actions連携【@lhci/cli 0.15.1】を参照してください。

axe DevToolsの画面は日本語で使えますか？

日本語での表示に対応しています。公式ドキュメントによると、拡張機能の設定の「外観」で表示言語を選べ、Deque公式のドキュメントにも日本語版も用意されていますが、ルールのヘルプページなど一部の説明は英語のまま表示されることがあるため、チームで共有する検査表はルール名（image-altなど）を併記しておくと照合しやすくなります。

ログインが必要な画面もaxe DevToolsで検査できますか？

拡張機能は、ブラウザでいま開いているページをそのまま検査するので、ログイン後の画面も対象にできます。CIで自動化する場合はCLIではなくPlaywright側で、ログイン処理を済ませてからAxeBuilderを実行する手順です。認証状態をテスト間で使い回す設定にしておくと、検査対象の画面を増やしても実行時間が伸びにくくなります。

WCAG 2.2の新しい達成基準はaxe DevToolsで検査できますか？

自動ではほとんど検査できません。axe-coreのルール一覧でWCAG 2.2に対応するのはターゲットサイズのtarget-size1本だけで、既定では無効です。フォーカスが隠れない、ドラッグ操作に代替がある、認証で記憶力テストを強いないといった2.2の追加基準は、手動確認の検査表に加えてください。Pro版のIGTを使う場合も、どの基準を案内してくれるかを導入前に確かめておくと安全です。

関連記事

• Webアクセシビリティ診断の進め方：自動・手動・当事者検証の三層設計と外注の判断基準：自動検査を診断全体のどこに置くかの設計。
• Webアクセシビリティのコントラスト比：4.5対1と3対1の適用範囲・CSS実装・自動検証の落とし穴：要確認に回りやすい色の判定の始末。
• Webアクセシビリティのスクリーンリーダー対応：NVDA・VoiceOverでの実機検証と読み上げ順序の設計：自動検査で拾えない読み上げの確認手順。
• axe Monitorとは？Dequeのサイト巡回型アクセシビリティ監視ツールの機能・対応規格・導入判断：公開サイトを巡回監視する同社の別製品。
• WCAGとは？最新版2.2の4原則・達成基準86件とAA適合の範囲：axeのタグが指す達成基準とレベルの全体像。