設定リファレンス
このページでは、axe MCP Server が読み取る環境変数と、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配布のみ。 要件については以下を参照してください。 | |
AXE_ADVANCED_RULES |
高度なルールプリセットは、このサーバーが実行するすべてのスキャンに適用されます。"precise"、"balanced"、"thorough"、"disabled"、またはそれに相当するパーセンテージ形式のいずれかです。以下を参照してください。 |
組織のaxe設定のデフォルト |
AXE_SCREENSHOT_DIR |
analyzeツールがscreenshot.saveを使用して明示的なsaveToパスが指定されていない場合にスクリーンショットを書き込むディレクトリ。以下を参照してください。 |
あなたのOSの一時ディレクトリ |
AXE_TOKEN_REFRESH_PORT |
サーバーがリスンするループバックポートは、更新されたOAuthアクセストークンを受け入れるためのもので、長いセッションがトークンの有効期限切れでも再起動せずに持続します。トークンリフレッシュ変数を参照してください。 | |
AXE_TOKEN_REFRESH_SECRET |
トークンプッシュを認証する共有シークレット。トークンリフレッシュ変数を参照してください。 | |
AXE_TOKEN_REFRESH_HOST |
トークンリフレッシュリスナーがバインドするネットワークインターフェース。トークンリフレッシュ変数を参照してください。 | "127.0.0.1" |
BROWSER_TIMEOUT_MS |
ブラウザの操作がタイムアウトするまで待機するミリ秒数 | 30000 |
LOG_LEVEL |
Syslogプロトコルに従います。サポートされている値は"debug", "info", "warn", "error"です |
"info" |
AXE_SERVER_URL
デフォルト値(https://axe.deque.com)は、Deque の共有 US SaaS インスタンスを使用しているほとんどのユーザーに適しています。次のいずれかを使用している場合、AXE_SERVER_URLをインスタンスの基礎 URL に設定する必要があります:
- (EU、オーストラリア、フランクフルトなど)(EU、オーストラリア、フランクフルトなど)
- オンプレミス デプロイメント
- 明示的に設定します インストール
に
MCP サーバー構成の env ブロックに AXE_SERVER_URL を明示的に設定します。クライアントセットアップガイド にはそれを正確に追加する場所を示す例が含まれています。
AXE_CHROME_PATH
npm配布のみ。 これは Docker ではサポートされていません。Docker は常にバンドルされたブラウザを使用するため、AXE_CHROME_PATH が Docker 配布に設定されている場合、サーバーは起動に失敗します。
デフォルトでは、npm 配布はPlaywrightを通してインストールした Chromium ビルドを使用します。AXE_CHROME_PATH を既存の Chrome/Chromium バイナリの完全なパスに設定して、その代わりにそれを使用し、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より優先されます。
AXE_ADVANCED_RULES
このサーバーが実行するすべてのスキャンに高度なルールの信頼プリセットを設定し、組織のaxe設定のデフォルトを上書きします。ただし、管理者がユーザーに設定変更を許可している場合に限ります。
受け入れられる値は"precise"(または"90%")、"balanced"(または"70%")、"thorough"(または"50%")、および"disabled"です。値は大文字小文字を区別しません。
{
"env": {
"AXE_ADVANCED_RULES": "thorough"
}
}未認識の値サーバー起動失敗は、デフォルトに黙ってフォールバックするのではなく、次のようになります:
Invalid Advanced Rules value: "high". Expected one of: 'precise' (90%), 'balanced' (70%), 'thorough' (50%), 'disabled'.analyzeツールは、advancedRules引数をコールごとに受け入れることもでき、これがそのコールに対してAXE_ADVANCED_RULESよりも優先されます。管理者が設定をロックしている場合、どちらも無視され、組織のプリセットが優先されます。完全な優先順位ルールとadvancedRules応答ブロックについては、高度なルールを参照してください。
AXE_SCREENSHOT_DIR
Sets the directory the analyze tool writes screenshots into when a call passes screenshot.save without an explicit path. It has no effect on calls that set screenshot.saveTo, which always wins, and none on calls that don't save at all.
{
"env": {
"AXE_SCREENSHOT_DIR": "/Users/me/axe-screenshots"
}
}相対パスはサーバーの作業ディレクトリを基準として解決されます。デフォルトはオペレーティングシステムの一時ディレクトリです。
Dockerディストリビューションの下では、このパスはコンテナ内にあります。 ボリュームをマウントしてファイルがホストに届くようにします - サーバーはマウントが存在するかどうかを検出しないため、存在しない場合、スクリーンショットはコンテナとともに破棄されます。
トークンリフレッシュ変数
これらはOAuth 2.0のみに適用され、実行中のサーバーが新たに更新されたアクセストークンを受け入れることができるようにし、トークンを超えたセッションが再起動せずに済むようにします。リスナーはデフォルトではオフで、AXE_TOKEN_REFRESH_PORTおよびAXE_TOKEN_REFRESH_SECRETが設定されている場合にのみ開始されます。
通常、これらを手動で設定することはありません。@deque/axe-auth runがサーバーを監視し、それらを提供します — ポートを選択すれば、シークレットが生成されます。
| 環境変数 | 説明 | デフォルト |
|---|---|---|
AXE_TOKEN_REFRESH_PORT |
トークンリフレッシュリスナーがプッシュを受け入れるポート。リスナーを有効にするために必要です。 | |
AXE_TOKEN_REFRESH_SECRET |
各プッシュを認証する共有シークレット。リスナーを有効にするために必要です;axe-auth runが生成しない限り、値を固定することはありません。 |
|
AXE_TOKEN_REFRESH_HOST |
リスナーがバインドするインターフェース。Dockerの下で0.0.0.0に設定され、公開されたポートはコンテナのインターフェースに転送され、ループバックには転送されません。 |
"127.0.0.1" |
リフレッシュトークンはサーバーに送信されません — 短命のアクセストークンのみが渡され、共有シークレットがエンドポイントを守ります。完全なDockerおよびnpm設定については長時間のセッションを維持するを参照してください。
AIエージェントの設定 (推奨)
あなたのAIコーディングエージェントがaxe MCPサーバーツールを正しく使用し、アクセシビリティのベストプラクティスに従うようにするには、カスタム指示を提供できます。これらの指示は、エージェントがアクセシビリティの問題を分析および修正するための正しいワークフローを理解するのに役立ちます。
指示を追加する場所
方法はクライアントによって異なります:
- VS CodeとGitHub Copilot - プロジェクトのルートに
.github/copilot-instructions.mdを追加します - カーソル - 設定の「カーソルルール」に追加します
- クロードコード - プロジェクトのルートにある
CLAUDE.mdファイルに追加します - クロードデスクトップ - 設定でカスタム指示に追加します
- 他のMCPクライアント - カスタム指示設定についてはクライアントのドキュメントを参照してください
Claude Codeでは、axe Accessibilityプラグインがこれらのファイルを書き込むことができ、/axe-accessibility:mcp-generate-instructionsがワークフローをCLAUDE.md、.github/copilot-instructions.md、カーソルルール、またはAGENTS.mdに生成してマージします。
ワークフロー指示の例
以下は、エージェントに適応できる推奨テンプレートです:
# 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 に準拠した修正を適用します
- 変更を検証 - 修正が実際に問題を解決したことを常に確認します
- 誤った自信を避ける - 専門家の指導なしにアクセシビリティの問題を解決する方法を知っていると仮定しません
任意ではあるが、これらの指示を提供することで、コードベース内のアクセシビリティ修正の品質と信頼性が大幅に向上します。
