設定リファレンス

This page is not available in the language you requested. You have been redirected to the English version of the page.
Link to this page copied to clipboard
Not for use with personal data

このページでは、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配布のみ。 要件については以下を参照してください。
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 互換バイナリを使用します。

analyzeigt ツールは、呼び出しごとに設定可能な 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 に準拠した修正を適用します
  • 変更を検証 - 修正が実際に問題を解決したことを常に確認します
  • 誤った自信を避ける - 専門家の指導なしにアクセシビリティの問題を解決する方法を知っていると仮定しません

任意ではあるが、これらの指示を提供することで、コードベース内のアクセシビリティ修正の品質と信頼性が大幅に向上します。