Claude CodeのAxe Accessibilityプラグインでアクセシビリティ検査を回す

Axe Accessibilityは、Deque Systemsが公開しているClaude Code向けのプラグインです。UIを変更するたびに「検査、修正、再検査」を回すよう、エージェントに手順を教えます。Axe MCP Serverの接続設定もまとめて入ります。

マーケットプレイスのページでは、エージェントがアクセシビリティを組み込み、テストし、修正するところまでを作業の流れの中で済ませる道具と説明されています。現在の中心は、Axe MCP Serverによる「スキャン、修正、再確認」の流れとキーボードのガイド付きテストです。

ここでは導入に必要なもの、3つのコマンド、監査の回し方、費用とデータの扱いを順に説明します。

導入前に用意するもの

先に確認したいのは契約です。プラグイン自体はMITライセンスですが、Axe DevTools for Webの契約が要ります。READMEによると、BundleプランにAxe MCP Serverへのアクセスが含まれます。契約がないと、ツールは認証に失敗します。

ランタイムは配布形態で決まります。

npmを選ぶ場合の落とし穴は、Chromiumです。同梱の設定が走らせる npx はブラウザを取得しません。入れ忘れると、スキャンはすべて「Chromium is not installed」で失敗します。

READMEが示す入れ方は、サーバーが依存するPlaywrightのバージョンを明示するものです。

npx -y playwright@1.62.1 install chromium

バージョンを付けずにPlaywrightを入れると最新版が解決され、サーバーが対応しない版のChromiumが入ることがあります。それでも失敗したら、エラーメッセージに出るインストールコマンドを、表示どおりに実行します。メッセージには、いま動いているサーバーが期待する版が書かれているためです。

OAuthで認証する場合は、どちらの配布でもNode.js 22 LTS以降が必要です。設定が npx -y @deque/axe-auth@1.6.0 を実行するからです。

プラグインを入れる

Claude Codeの内蔵マーケットプレイスから探す場合は、/plugin で検索して入れます。READMEは、公式プラグインディレクトリに載れば、Claude Codeがそれを claude-plugins-official として全ユーザーに見せると説明しています。

ディレクトリ経由で見つからないときは、リポジトリ自体がマーケットプレイスを兼ねているので、次の2行で入ります。

/plugin marketplace add dequelabs/axe-accessibility
/plugin install axe-accessibility

手元で試すだけなら、claude --plugin-dir /path/to/axe-accessibility でローカルのコピーを読み込めます。マーケットプレイスの仕組み自体はClaude Codeのプラグインとマーケットプレイスの解説にあります。

同梱されるスキル3本とMCPサーバー

中身は4つです。

.mcp.json には、認証方式を問わないAxe MCP Serverの定義が入っています。npm配布を scripts/start-axe-mcp-server.sh から起動し、サーバーは axe-mcp-server@1.6.0、認証CLIは @deque/axe-auth@1.6.0 に固定されています。Dockerはコマンドの形が違うため、この設定のままでは使えません。Dockerで使うなら mcp-setup が別の形で書き出します。

バージョンを固定する理由はREADMEに書かれています。npxで起動するパッケージをすべて固定版にしておけば、ユーザーが入れるものがディレクトリの審査を受けたものと一致します。スキルが記述するレスポンスの形(たとえばガイド付きテストの結果は data.igt にツール名をキーとして入る)も、サーバーの版と揃います。

サーバーとスキルの記述がずれた場合は、サーバーが優先されます。サーバーは起動時にツールの説明と入力スキーマを組み立てるので、analyze の最新の引数は説明文に出ます。スキルはそれを正とするよう、エージェントに指示しています。

プラグインが他のMCPサーバーを抱える場合の挙動は、プラグイン同梱のMCPサーバーの解説で確認できます。

認証を決める

認証は2通りです。mcp-setup の中で選びます。

APIキーは、Axe Account Portalの「API Keys」で「Axe MCP Server」向けに発行します。プラグインを有効にするときにClaude Codeが入力を求め、あとから /plugin の管理画面で変えられます。値はシステムのキーチェーンに保存され、settings.json には入りません。

OAuth 2.0は、次のコマンドでブラウザを開くPKCEフローです。トークンはOSのキーチェーンに保存され、自動で更新されます。

npx -y @deque/axe-auth@1.6.0 login

同梱の .mcp.json は、OAuthにログイン済みならそのアクセストークンを、そうでなければAPIキーのオプションを渡します。サーバーは両方が同時にあると拒否するため、トークンがあるときはAPIキー側が外されます。OAuthを使う人は、APIキーのオプションを空にしておきます。

注意点が1つあります。0.3.1より前にシェルへ AXE_API_KEY を設定して使っていた場合、いまの同梱設定はシェルの値を読みません。プラグインのAPIキーオプションに入れ直します。社内のプライベートクラウドやオンプレミスの環境では、AXE_SERVER_URL で接続先を変えます。

最初の監査を回す

READMEのクイックスタートは3手順です。

手順2の all は、手順1の対象ファイルをまとめて作る指定です。生成物は、おおよそ次のような趣旨になります(READMEが述べる「検査、修正、再検査を毎回の変更で回す」という要件に沿った例で、実際の出力そのものではありません)。

## アクセシビリティ
- UIを変更したら、完了前に analyze を実行する
- 違反があれば、同じスキャンの全件を1回の remediate にまとめる
- 修正を適用したあと、analyze で再確認する
- ガイド付きテストは、依頼があったときだけ実行する

mcp-audit が回す流れは、検査、バッチ修正、適用、再検査です。再検査に使う analyze 単体はAIクレジットを使わないため、何度繰り返してもAIクレジットは減りません(認証と利用量の計測は行われます)。

費用はremediateとガイド付きテストにかかる

AIクレジットを消費するのは、remediate とガイド付きテストの2つです。analyze のみなら消費しません。

remediate は、バッチに含めた問題の数に応じて課金されます。呼び出し1回あたりではありません。1回のスキャンで出た問題は、1回の呼び出し(最大25件)にまとめて送る決まりです。割引ではなく仕様上の形なので、費用は件数に比例します。

プラグインのガイダンスは、ルール単位でまとめず、問題の全インスタンスを送るようエージェントに求めます。同じルールでも要素ごとに必要な修正が違うからです。極端に大きなスキャンでは、修正を始める前にユーザーに確認します。

ガイド付きテストは、静的なスキャンでは代わりにならないものです。種類は3つあります。

• キーボード: フォーカス順、フォーカストラップ、フォーカスの見え方
• インタラクティブ要素: アクセシブルな名前、ロール、状態
• モーダル: ダイアログの意味づけ、フォーカスの扱い、閉じ方

エージェントは、これらが扱う内容をユーザーが頼んだときにだけ実行します。既定では動きません。

確定の指摘と確率の指摘を分けて読む

サーバーのバージョン1.4.0以降、analyze はAdvanced Rulesの指摘を結果に混ぜます。スクリーンショット、コンピュータビジョン、LLMを使う検査で、axe-coreでは拾えないもの(見出しに見えるだけの文字、役に立たない代替テキスト、グラデーションや画像の上のコントラスト)を見つけます。

各問題には isAdvanced というフラグが付きます。

スキャンごとに advancedRules の引数で強さを変えられます。値は precise、balanced、thorough、disabled(または90%、70%、50%の別名)です。サーバー全体の既定は環境変数 AXE_ADVANCED_RULES で決めます。引数なので、「advanced rulesをthoroughにして検査して」「advanced rulesを無効にしてスキャンして」と頼めば、プラグインのガイダンスがエージェントに引数を渡させます。

結果には、実際に適用された設定が advancedRules のブロックで返ります。source が org_policy_locked なら、組織の固定ポリシーが上書きを拒否した状態です。tier_locked や unavailable なら、アカウントでAdvanced Rulesが有効になっておらず、何を渡してもAdvancedの指摘は出ません。その場合、サーバーは公開スキーマから advancedRules を外すので、引数が見えないこと自体が契約の範囲を示します。

どのデータが外に出るか

プラグイン自体は設定と指示だけで、単独では何も収集も送信もしません。データはAxe MCP Server経由でのみ出ます。サーバーはローカルで動き、ローカルのChromiumで渡したURLを開くので、ページの読み込みは手元で済みます。

Deque側へ送られるのは、認証と契約・クレジットの確認に必要な情報に加えて、次のとおりです。

• Advanced Rules: ページの文脈とスクリーンショット
• ガイド付きテスト: 対象要素のマークアップと要素のスクリーンショット
• remediate: バッチに含めた問題の詳細

advancedRules を無効にし、igtTools を渡さなければ、AI処理のためのページ内容は送られません。それでも認証と利用量の計測のためにAPIとは通信します。

認証が要る画面や社内ページをスキャンすると、そのページの内容がDequeへ送られます。AIに処理させたくないページでは、selector で範囲を絞り、advancedRules: "disabled" にし、igtTools を渡さない、という3点で抑えます。ガイド付きテストはAdvanced Rulesとは別のオプトインなので、片方を無効にしてももう片方は止まりません。

つまずいたときの切り分け

使いどころの見立て

このプラグインは、検査を人の手作業から外して、変更のたびに自動で走らせる用途に向きます。mcp-generate-instructions で指示をリポジトリに残しておけば、プラグインを入れていない同僚のエージェントも同じ手順を踏みます。

一方で、費用は件数に比例し、契約も別途要ります。まずは自分の開発サーバーに mcp-audit を1回かけ、remediate が何件になるかを見るのが、導入の判断材料としては手堅い進め方です。

Claude Codeで依存関係の安全性を同じようにプラグインで検査したい場合は、Sonatype Guideプラグインの導入も同じ型で使えます。