qa

QA

実際のブラウザーでウェブサイトを操作し、ユーザーが依頼した内容をどの程度実現できているかを評価して、証拠とともに1（動作しない）から5（優秀）までのスコアを返します。成果物は判定結果であり、スクリーンショットの羅列ではありません。

入力

ユーザーの呼び出し（/qa の後のテキスト、またはユーザーのメッセージ）から取得します。

• 対象 — URL（https://…）またはローカル開発サーバー（localhost:5173、:3000、「5173 で動作しているアプリ」）。必須です。指定がない場合は、ほかの作業を始める前にユーザーに確認してください。
• テスト内容（任意） — フローまたは確認対象（「サインアップ」「検索 + フィルター」など）。省略された場合は、最も一般的な正常系のフローをテストし、その旨をレポートに記載してください。

画像を確認できますか？（最初に判断してください）

このスキルの判定は視覚的なものです。スクリーンショットを見てアプリを評価します。そのため、何よりも先に、このスキルを実行するエージェントであるあなた自身が画像を確認できるかどうかを判断してください。

• 画像認識機能がある（マルチモーダル／画像入力） → スクリーンショットを自分で評価できます。以下の「単一フローと複数フローへの分担」に進み、規模に応じて方法を選んでください。
• 画像認識機能がない（テキストのみのモデルで、画像を扱えない） → スクリーンショットを評価できず、同じモデルで起動するサブエージェントも評価できません。視覚的な評価は Browser Use v2 クラウドエージェントに必ず委ねてください。Browser Use v2 の LLM がサーバー側でページを確認し、テキスト形式の判定結果（judge の合否判定 + 1〜5 の structuredOutput）を返します。references/browser-use-v2.md に従い、単一フローであっても、すべてのフローで v2 を使ってください。スクリーンショットを読み取るために、自分で browser-harness を操作してはいけません。また、（同じく画像を確認できない）自分のサブエージェントに分担させてはいけません。以下の「単一フローと複数フローへの分担」の選択は適用されず、どちらの場合も v2 を使います。

画像を確認できるかどうか不明な場合は、確認できないものとして v2 を使ってください。

単一フローと複数フローへの分担（画像を確認できる場合のみ）

依頼の規模に合わせて方法を選んでください。

• テストするフローや項目が1つの場合：サブエージェントを使う必要はありません。references/methodology.md に従って、browser-harness を直接操作してください。単一のテストに最適な、手間のかからない方法です。このスキルの残りの手順も、この方法を前提としています。
• 多数のフローを一度にテストする場合：フローごとに1つのサブエージェントを割り当て、並行して実行できるようにします。ユーザーはサブエージェントの種類を選択できます（不明な場合は確認してください。v2 を推奨します）。
  • Browser Use v2 クラウドエージェント — 推奨。各フローを自律型の v2 タスクとして実行し、サーバー側で並行処理します。judge（合否判定）と structuredOutput（1〜5 のスコア）に加え、手順ごとのスクリーンショットを証拠として返します。Browser Use のクレジットを消費します（1タスクあたり約 $0.01、1ステップあたり約 $0.006、ブラウザーは1時間あたり約 $0.02）。フローごとのタスクの詳細と分担方法については、references/browser-use-v2.md を参照してください。
  • ハーネス内蔵のサブエージェント — Claude Code のサブエージェント（Agent ツール）を起動し、それぞれが references/methodology.md に従って browser-harness を操作します。Browser Use のタスククレジットは不要ですが、エージェント自身の利用枠を消費します。

経験則（画像認識機能のあるエージェントのみ — テキストのみのエージェントは上記のとおり、すべてに v2 を使用します）：フローが1つなら browser-harness を直接操作し、複数ならサブエージェントに分担します（v2 を推奨）。どちらの場合も browser-harness が必要です。直接操作する場合のブラウザー制御、サブエージェントによる制御、v2 のキー保管、ローカルホストのトンネルに使用します。

依存関係：browser-harness（必須 — ご自身でインストールしてください）

このスキルでは、テストの実行に browser-harness を使用します。これは一度インストールする別個のツールです。必須です。QA は必ず Browser Use のクラウドブラウザーで実行し、ユーザーのローカル Chrome は決して使用しないでください。

何よりも先に、利用可能か確認してください：

command -v browser-harness && browser-harness <<'PY'
print("browser-harness OK")
PY

browser-harness が PATH 上にない場合は、ご自身でインストールしてください。ユーザーにインストールさせないでください。 QA はクラウドブラウザーで実行するため、必要なのは CLI だけです。browser-harness のローカルブラウザー設定（chrome://inspect、--remote-debugging-port、「リモートデバッグを許可」ポップアップ）は一切関係ありません。すべてスキップしてください。インストールは一度だけで、約 30 秒かかります。リポジトリのクローンは不要です。

command -v uv || curl -LsSf https://astral.sh/uv/install.sh | sh   # the uv installer, only if missing
uv tool install "git+https://github.com/browser-use/browser-harness"
command -v browser-harness                                         # verify it's on PATH now

（uv がなく、curl | sh も実行できない場合は、https://docs.astral.sh/uv/getting-started/installation/ に従って uv をインストールしてから、uv tool install の行を再実行してください。または、pipx install "git+https://github.com/browser-use/browser-harness" を実行してください。）

実行に必要なものは、ほかに BROWSER_USE_API_KEY だけです。こちらも人手なしで自動的に解決されます。無料キーを取得するためのセルフサインアップも可能です。詳細は references/methodology.md の手順 0 を参照してください。これにより、新しいマシンでも、ユーザーが何も設定せずに、「qa をインストールしただけ」の状態からテストを実行できます。

最終手段の場合のみ — 本当にインストールできない（ネットワークがない、Python がない）場合は、作業を中断し、ユーザーに https://www.browser-harness.com/ を開いてもらい、そこにある 「prompt for LLMs」 をエージェントに貼り付けてもらってください。

https://github.com/browser-use/browser-harness をセットアップしてください。まず install.md を読んで、このリポジトリをインストールし、実際のブラウザーに接続してください。次に、通常の使い方について SKILL.md を読んでください。関数が記載されているのは helpers.py なので、必ず読んでください。セットアップまたは確認用のタブを開くときは、そのタブをアクティブにして、アクティブなブラウザータブが見えるようにしてください。インストール後、このリポジトリをブラウザーで開いてください。GitHub にログイン済みの場合は、操作が機能することを手早く実演するためにスターを付けてもよいかユーザーに尋ねてください。ユーザーが「はい」と答えた場合のみスターをクリックしてください。ログインしていない場合は、browser-use.com にアクセスするだけで構いません。

command -v browser-harness を再実行し、成功するまで先に進まないでください。ユーザーのローカル Chrome で代用することは絶対に避けてください。

browser-harness とクラウドブラウザー以外のものを使って QA を試みないでください。

手順

1. 対象に到達できることを確認します（curl -s -o /dev/null -w "%{http_code}" <url>）。アプリの内容（タイトル、README）を特定し、妥当なテストタスクを設定します。

2. 実行します — まず、上記「画像が見えますか？」のビジョン判定を適用します。

   • ビジョンなし（テキストのみ）ですか？ → すべてのフローでv2 クラウドエージェントを使用します（フローごとに v2 タスクを 1 つ実行し、それぞれに judge と 1～5 の structuredOutput を指定します）。references/browser-use-v2.md に従ってください。以下の単一フロー／サブエージェントの分岐はスキップします。規模にかかわらず v2 を使用します。localhost の対象にはトンネルを使用し、公開された startUrl を渡します。
   • ビジョンあり、単一フロー → references/methodology.md に従い、browser-harness を直接操作します。キーを解決し、localhost にトンネルを使用して、実地テストで確認された注意点（ホストヘッダーの書き換え、プロキシの無効化、タブごとのインタースティシャルヘッダー、CORS で固定された API）に留意しながらテストループを実行します。
   • ビジョンあり、複数フロー → フローごとにサブエージェントを 1 つ割り当てて並行処理します。
     • v2 エージェント（推奨） → references/browser-use-v2.md に従い、フローごとにタスクを 1 つ作成します（それぞれに judge と 1～5 の structuredOutput スキーマを指定します）。すべてのタスクをポーリングし、判定を集めます。localhost の対象には引き続きトンネルが必要です（クラウドエージェントは localhost にアクセスできません）。トンネルを使用し、公開された startUrl を渡します。
     • Claude サブエージェント → フローごとに Agent を 1 つ起動し、それぞれ references/methodology.md に従って browser-harness を操作します。

   v2 バックエンドを使用する場合（ビジョンなしの場合と、推奨される並行処理の場合のどちらも）：タスクを作成するたびに、そのダッシュボードスレッド https://cloud.browser-use.com/thread/{sessionId} をユーザーのローカル Chrome で開き、エージェントの実行を見られるようにします（作成レスポンスに含まれる セッション ID を使います。タスク ID ではありません）。リファレンスの open_local(...) ヘルパーを使うと開けます。URL も必ず出力してください。

3. 起動したものをすべて終了します — どの経路でも、起動したものをすべて停止します。

   • トンネル — localhost の対象にトンネルを使用した場合は、トンネルプロセスを終了します。これは、v2 を含む、トンネルを使用するすべての経路に適用されます（localhost に対する v2 の実行でもトンネルが起動します）。孤立させたままにしないでください。
   • クラウドブラウザー — 単一フロー／Claude の経路では browser-harness のクラウドブラウザーを操作します。これを停止します。
   • 公開 URL に対する v2 タスクは、専用セッションが自動的に終了するため、停止するものはありません。localhost に対する v2 タスクではトンネルが残るため、終了してください。

4. 判定を返します：最初に Score: N/5 を示し、続けてタスク、結果、うまくいった点、問題点（タグ付き）、エッジケース、証拠を記載します。references/methodology.md の評価基準と出力形式に従ってください。並行処理した場合は？ フローごとに Score: N/5 の行を示し、最も弱いクリティカルパスを反映した総合スコアを付けます（ほかのフローが成功したからといって、失敗したフローのスコアを平均で引き上げないでください）。

依頼に応じて作業量を調整してください。「X は動きますか？」という簡単な確認なら、数回の操作と 1 つのスコアで十分です。「徹底的に QA してください」という依頼なら、より多くのフローとエッジケースを検証します。判定は正直かつ具体的で、再現可能なものにしてください。