設定リファレンス
このページでは、axe MCPサーバーが読み取る環境変数と、AIエージェントのための推奨カスタム指示について説明しています。これらは、 Dockerおよびnpmディストリビューションの両方に適用されます。これらの値をどこに配置するかについては、 クライアントセットアップガイドを参照してください。
設定オプション
axe MCPサーバーは、カスタマイズのためにいくつかの環境変数をサポートしています:
| 環境変数 | 説明 | デフォルト |
|---|---|---|
AXE_API_KEY |
認証のためのAPIキー( APIキーを参照)。互いに排他的に使用 AXE_ACCESS_TOKENします。 |
|
AXE_ACCESS_TOKEN |
OAuth 2.0ベアラートークンによる認証( OAuth 2.0を参照)。互いに排他的に使用 AXE_API_KEYします。 |
|
AXE_SERVER_URL |
組織のaxeアカウントポータルの基本URL。デフォルトの共有US SaaSインスタンスを使用しない場合のみ必要です。詳細は 以下 を参照。 | "https://axe.deque.com" |
AXE_CHROME_PATH |
Playwright管理のインストールの代わりに使用するChrome/Chromiumバイナリのパス。 npmディストリビューションのみ。 要件については 以下 を参照してください。 | |
BROWSER_TIMEOUT_MS |
ブラウザの操作がタイムアウトするまで待機するミリ秒数 | 30000 |
LOG_LEVEL |
Syslogプロトコルに従います Syslogプロトコル。対応する値は "debug"、 "info"、 "warn"、および "error" |
"info" |
AXE_SERVER_URL
デフォルト値(https://axe.deque.com)は、Dequeの共有US SaaSインスタンスを使用するほとんどのユーザーに適しています。 次のいずれかを使用する場合、インスタンスの基本URLを明示的に設定する必要があります: AXE_SERVER_URL インスタンスの基本URL:
- 地域のSaaSインスタンス (EU、オーストラリア、フランクフルトなど) プライベートクラウド
- のデプロイメント オンプレミス のインストール
- 組織がどのインスタンスを使用しているかわからない場合は、axeアカウントポータルにログインする際のURLを確認するか、管理者に問い合わせてください。 明示的に設定します に
に
Set AXE_SERVER_URL explicitly in the env あなたのMCPサーバー設定のブロックに。 クライアントセットアップガイド は、それを追加する具体的な場所を示す例を含んでいます。
AXE_CHROME_PATH
npm配布のみ。 これはDockerではサポートされておらず、常にバンドルされたブラウザを使用します。 AXE_CHROME_PATH がDocker配布の下で設定されると、サーバーは起動に失敗します。
デフォルトでは、npm配布はあなたがインストールしたChromiumビルドを使用します Playwrightを通じて。それをスキップし、代わりに既存のChrome/Chromiumバイナリのフルパスを設定します。 AXE_CHROME_PATH これによりPlaywrightのインストールを省略することができます。
- 値は、 実行可能なバイナリファイルでなければならず、
.appバンドルまたはディレクトリではありません。例えば、macOSでは、バンドル内のバイナリを指定してください:/Applications/Google Chrome for Testing.app/Contents/MacOS/Google Chrome for Testing。 - バイナリは起動し、
--versionに応答しなければなりません。サーバーはこのことを起動時に検証し、Unable to find specified chrome instanceもしできない場合はすぐに失敗します。 - ブランド化されたGoogle Chrome 137以降はサポートされません。 使用するのは、 テスト用Chrome または他のChromium互換バイナリです。
analyze と igt ツールも、呼び出しごとに chromePath 引数を指定でき、これが AXE_CHROME_PATH この呼び出しに関して優先されます。
AIエージェントの設定 (推奨)
あなたのAIコーディングエージェントがaxe MCPサーバーツールを正しく使用し、アクセシビリティのベストプラクティスに従うようにするには、カスタム指示を提供できます。これらの指示は、エージェントがアクセシビリティの問題を分析および修正するための正しいワークフローを理解するのに役立ちます。
指示を追加する場所
方法はクライアントによって異なります:
- VS CodeとGitHub Copilot - プロジェクトルートに追加します
.github/copilot-instructions.md - カーソル - 設定で「カーソルルール」に追加します
- クロードコード - プロジェクトルートの
CLAUDE.mdファイルに追加します - クロードデスクトップ - 設定でカスタム指示に追加します
- 他のMCPクライアント - カスタム指示の設定についてクライアントのドキュメントを参照してください
ワークフロー指示の例
以下は、エージェントに適応できる推奨テンプレートです:
# Accessibility Testing and Remediation Workflow
## MANDATORY WORKFLOW - DO NOT DEVIATE
When working with accessibility issues, you MUST follow this exact workflow:
### 1. Analysis Phase
When asked to analyze pages for accessibility issues, you MUST:
- Use the `analyze` tool to scan the page
- Do NOT manually identify accessibility issues
- Always provide the complete URL being analyzed
### 2. Authentication & Pre-Scan Setup
When the user's request involves credentials, form input, dismissing
overlays, or waiting for content before the scan, you MUST:
- Pass an ordered `before` array to the `analyze` tool using the
`click`, `fill`, and `waitFor` actions
- Resolve any references to env vars, `.env*` files, or local
configuration into literal strings BEFORE calling the tool — the
server treats `value` as a literal and will not expand `${VAR}`,
`$VAR`, or `{{VAR}}` syntax
- Use `fill` for secret values so the server's redaction protections
apply; never embed secrets in a `selector`, which appears in logs
and error messages
- ASK the user when the source of a credential or value is ambiguous;
do NOT guess or fabricate values
- Use ONLY selectors the user provided; if a step needs a selector
the user did not name, ASK rather than guess
- Use `waitFor` after any `click`/`fill` that triggers async UI
(route changes, late-rendered content) to deterministically gate
the next step or the scan — pick a selector that exists ONLY in
the post-interaction state (e.g., a logout button or dashboard
heading), never a generic one like `body` or `#app` that already
exists beforehand
### 3. Remediation Phase
When asked to remediate or fix accessibility issues, you MUST:
- Collect ALL violations from the analysis and pass them to the
`remediate` tool in a SINGLE batched call — do NOT call `remediate`
once per issue
- Give each issue a unique `id` so each result can be correlated
back to its input
- Provide the exact HTML element, rule ID, and issue description for
every issue in the batch
- Review the remediation guidance before making any code changes
- Apply fixes based on the remediate tool's recommendations
- Do NOT manually fix accessibility issues without first using the remediate tool
### 4. Verification Phase
After applying fixes, you MUST:
- Re-run `analyze` to verify all issues are resolved
- Confirm zero violations before considering the task complete
## Required Workflow Example:
1. analyze → Find violations
2. remediate → Pass ALL violations in one batched call to get fix guidance
3. Apply recommended fixes to code
4. analyze → Verify fixes
## Enforcement
- NEVER skip the remediate tool when fixing accessibility issues
- ALWAYS use both analyze and remediate tools as specified
- This workflow ensures proper accessibility best practices and complianceなぜこれが重要なのか
これらの指示は、エージェントが以下を保証します:
- Dequeの専門知識を活用する - 一般的なLLM知識の代わりに、何十年にもわたるアクセシビリティ評価データで訓練されたAIモデルを活用する
- ベストプラクティスに従う - 一貫したWCAG準拠の修正を適用し、一般的な解決策ではなくする
- 変更を検証 - 修正が実際に問題を解決したことを常に確認する
- 誤った自信を避ける - 専門家の指導なしにアクセシビリティの問題を解決できると仮定しない
任意ではあるが、これらの指示を提供することで、コードベース内のアクセシビリティ修正の品質と信頼性が大幅に向上します。
