axe MCPサーバー バージョン1.5.0 リリースノート

リリース日

2026年8月27日

概要

このv1.5.0リリースでは、インテリジェントガイドテスト（IGT）が劇的に小さなレスポンスを返すようになり、コードエージェントがそれを読むために支払うトークンのコストを削減します。また、IGTをanalyzeツールにを導入し、1回の呼び出しで同じページに対してaxeスキャンとIGTを実行できるようになりました。さらに、v1.4.0で追加されたスクリーンショットにそれをディスクに保存するオプションを拡張し、長いOAuthセッションを継続させるを再起動せずに維持します。

新機能

analyzeツールのインテリジェントガイドテスト

analyzeツールは、axeスキャンの直後に同じコール内で同じページに対して自動インテリジェントガイドテストを実行するigtTools配列をオプションで受け入れます：

{
  "url": "http://localhost:3000",
  "igtTools": ["keyboard"]
}

ページをスキャンしてキーボードIGTを実行するには、以前は2つの別々のツールコールが必要でした——2回のブラウザ起動、2回のナビゲーション、そして同じ状態に到達するための2回のbeforeステップが必要でした。今では、ページの準備を行う全ての作業が一度実行され、両方に引き継がれます。キーボードIGTが現在サポートされています。

igtToolsを省略したコールは変更されませんので、既存のプロンプトとエージェント指示はそのまま機能し続けます。IGTはAIクレジットを消費しますが、axeスキャンは消費しません。

レスポンスの形状と完全な使い方についてはインテリジェントガイドテストをご覧ください。

スクリーンショットをディスクに保存できるようになりました

v1.4.0で導入されたscreenshotパラメータは、画像をインラインのみで返していました。今では、キャプチャをファイルに書き込むこともできます：

{
  "url": "http://localhost:3000",
  "screenshot": { "saveTo": "/Users/me/Desktop/home.png" }
}

これにより、インライン画像をレンダリングしないMCPクライアントでもキャプチャにアクセスできるようになります。inline: falseと組み合わせることで、インライン画像ブロックを完全にスキップし、次のターンでエージェントが支払うはずだった画像入力トークンなしでスクリーンショットを取得できます。

完全なオプションとDockerボリュームの要件についてはスクリーンショットをディスクに保存するをご覧ください。

中断のないOAuthセッション

OAuthアクセストークンは短命のため、数時間稼働したエージェントセッションはトークンを失効し、失敗し始めるでしょう——唯一の回復方法は新しいトークンを取得し、サーバーを再起動することでした。

新しい@deque/axe-auth runコマンドはその崖を取り除きます。MCPクライアントをサーバーコマンドとしてそれに向け、起動してサーバーを監督しながら、その期間中ずっとアクセストークンを新鮮に保ちます。リフレッシュトークンはあなたのマシンを離れることはなく、macOS、Windows、Linuxの両方のディストリビューションで機能します。

設定については長時間セッションを維持するをご覧ください。

変更点

小さなIGTレスポンス

IGTレスポンスは、エージェントが実際に必要とするフィールドに絞られた各処理済み要素を返すようになりました。多くのインタラクティブな要素があるページでは、これらのペイロードはモデルのコンテキストウィンドウを乱すほど大きくなっていました。報告された問題と要素の数は変更されていません。

スタンドアロンigtツールは非推奨

現在analyzeが直接IGTを実行するで、スタンドアロンigtツールは非推奨とされています。完全に機能し、以前と同じ結果を返しますが、将来のリリースで削除される予定です。

今日、取るべき行動はありません。 If you maintain カスタムエージェント指示 that name the igt tool, update them to call analyze with igtTools instead.

バグ修正

• インテリジェントガイドテストが静かに停止しなくなりました。 ブラウザ拡張機能が応答を停止すると、エラーもログの説明もないままMCPクライアントが諦めるまで、実行が停止してしまうことがありました。これが、対応可能なメッセージとともにすぐに失敗するようになりました。
• APIキーの検証が制限の多いネットワークでもより信頼性の高いものになりました。 検証はサーバーの他の部分とは異なるネットワーク経路を使用していたため、Dequeへの他のリクエストはすべて成功する企業ネットワークで障害が発生する可能性がありました。現在では他のすべてと同じ経路を使用しています。もしまだAPIキーのエラーとして接続の問題が報告される場合は、トラブルシューティングを参照してください。