fieldtest

Fieldtest

このスキルを使って、アプリをコードとしてだけでなく、実際に描画されたソフトウェアとして評価します。出力はブラウザーで確認した証拠に基づいている必要があります。具体的には、訪問したルート、ビューポートサイズ、試した操作、コンソール／ネットワークのシグナル、利用可能な場合はスクリーンショット、再現可能な所見を記録します。

References

包括的なフィールドテストを実施する場合、開発 URL を解決する場合、ペルソナの視点を選ぶ場合、またはレポートのトーンと重要度を調整する場合は、references/browser-session.md を読み込みます。

返された画像、検索結果、生成コンテンツ、またはサンプル集を評価する場合は、references/output-quality.md を読み込みます。コントロールが動作しても、その出力が有用であるとは限りません。

Start

呼び出されたら、次の手順を実行します。

1. fieldtest スキルを使用していることを伝えます。
2. モードを特定します。
   • レポートのみの QA
   • QA と修正
   • ルート、機能、またはリグレッションの重点確認
   • レスポンシブ／モバイル監査
   • ペルソナに基づくブラウジング
3. ユーザーが URL を指定していない場合は、コードベースから開発サーバーを検出します。
4. アプリが起動しておらず、適切な開発コマンドが明確な場合は、それがローカルで、データを変更せず、広範な dev:all や本番環境に接続するコマンドではないことを確認してから起動します。候補となるアプリやコマンドが複数ある場合は、簡潔な質問を 1 つします。
5. ホスト環境に最適なブラウザーツールを選びます。第一級のローカルブラウザーが利用できる場合、機能の劣るブラウザー経路を標準として選ばないでください。

データを書き込む操作や外部への影響を伴う操作の前に、アプリの設定と実行環境から、実際に使われるデータベース、ストレージ、アカウント、操作の送信先を特定します。localhost が示すのはフロントエンドであり、接続先のサービスではありません。必要な設定のみを確認し、認証情報は伏せ、利用可能な場合は使い捨ての送信先を使用します。送信先が不明な場合は未確認のままです。閲覧の許可は、データの投入やリモートへの書き込みを許可するものではありません。実際の送信先に対して、ホスト側の承認ルールを適用します。

ユーザーが明示的に問題の修正を求めない限り、既定ではレポートのみとします。

Browser Tool Selection

利用可能な中で最も優れたブラウザーを使い、必要に応じて Playwright に切り替え、静的解析のみの結果はフィールドテストが未完了であることを明確に示します。完全なフォールバック手順は references/browser-session.md にあります。

ローカルのウェブアプリでは、ブラウザー対応ツールが利用できる場合、シェルだけの確認でフィールドテストを済ませないでください。このスキルの目的は、実際に描画された動作を評価することです。

Context Scan

アプリ全体を監査することなく、意図を理解するのに十分なコードベースの情報を読み取ります。

• package.json と、ワークスペースから委譲された package.json ファイル
• next.config.*、vite.config.*、astro.config.*、playwright.config.* などのフレームワーク設定
• app/**/page.*、pages/**、src/routes/** などのルートファイル
• git log --oneline -10 と git status --short を使った最近の変更
• 存在する場合は、デザイン、プロダクト、ブランド関連のドキュメント
• AGENTS.md など、アプリ固有の指示

ポートの検出のために .env* を読む場合は、PORT、HOST、フレームワーク固有の開発サーバー変数など、ローカル URL の解決に必要なキーだけを確認します。レポートで秘密情報を引用したり要約したりしないでください。

次の内容を、短い固定コンテキストとしてまとめます。

• 目的
• 主なユーザーフローの候補
• 技術スタック
• 開発 URL
• 接続先と、テスト対象の操作に許可された影響
• 対象ルート
• ペルソナまたはテストの視点

ブラウジング中はこの要約を使用し、生のファイル内容を長時間記憶にとどめないでください。

ブラウザーセッション

証拠に基づいて作業します。

1. 対象の URL を開き、ページが実際に読み込まれたことを確認します。
2. コンソールエラーと明らかなネットワーク障害を確認します。
3. 操作する前に、最初に受ける印象を記録します。
4. 主要なフローを実行します。
5. 安全な範囲で、空、無効、読み込み中、またはエラーの状態を少なくとも 1 つ発生させます。
6. 近隣のルートや重要なセカンダリルートに移動します。
7. タスクの範囲が広い場合や、見た目に関するタスクの場合は、モバイルとデスクトップの幅でレスポンシブ動作を確認します。
8. 主要なコントロールについて、キーボード操作とアクセシブルネームの基本を確認します。

非同期フローでは、A の完了前に B を試し、読み込み中、失敗、最終状態を観察します。遅れて届いた応答で B が置き換わってはならず、無関係な更新によって A が再実行されたり、現在のエラーが消去されたりしてはなりません。アプリが別の製品に組み込まれている場合は、実際のホスト上で表示と操作を確認します。単独のブラウザーデモで確認できるのは、そのデモに限られます。

破壊的な操作、支払い、メール送信、注文、公開、本番環境への変更については、ユーザーが明示的に許可した場合に限り実行します。必要な許可がない場合は、確認を求めます。

録画

ブラウザーツールが録画に対応している場合、実地テスト全体では、主要なフローの短いクリップ（約 30 秒）を撮影します。内容がわかるファイル名を付けます。読者がクリップだけで検証結果を確認でき、クリップに問題があるように見える場合にのみコードを開けばよい状態にします。録画は任意です。ツールで録画できない場合は省略します。

測定の規律

ここに挙げるルールはすべて、かつて確信を持って誤った数値を返した測定に基づいています。

• 測定のたびに、ビューポートと URL を確認します。 innerWidth+"x"+innerHeight と location.href を読み取り、指定した値と異なる場合はリセットして再試行します。誤ったサイズやページで得た数値は報告しません。誤った測定値も証拠として受け取られてしまいます。
• どこを見るべきかを指示するのではなく、計測ツールに不具合を見つけさせます。 すでに答えがあると思っている場所を対象にした確認では、自分の見立てを覆せません。予想外の結果が出る可能性のある測定を優先し、事前に、どの結果なら自分の見立てが覆るのかを明確にします。
• 欠陥を捉えられる状態だったことを証明してから、記録内容を評価します。 比較する 2 つの領域の色味がたまたま近いスクリーンショットでは、その境界について何も証明できません。事前条件（コントラスト、状態、データの有無）を確認し、満たされない場合はその記録を採用しません。
• ページが宣言した内容を測るゲートでは、何も宣言していないページを検出できません。 「宣言された内容が正しい」ことを確認するたびに、「宣言漏れがない」ことも確認します。
• 最初に表示された状態ではなく、完了状態を待ちます。 要素が現れた時点で終了するポーリングは、表示開始を測定しています。一定時間のスリープでは、その時点までに描画された内容を測定しているだけです。完了を示す条件が満たされるまで待ちます。
• プログラムによるクリックは、タップではありません。 プログラムによるクリックは、ヒットテスト、ポインターイベント、オーバーレイを回避するため、指では届かないコントロールでも操作できたり、実際には操作できるコントロールで失敗したりします。ツールの実際のクリックを使い、その操作で起きるはずの変化を確認します。
• 読み取った値は、都合よく解釈できてしまいます。拒否基準を設けた値なら、信頼できます。 しきい値は頭の中ではなく、ドライバースクリプトに設定します。

ペルソナ別の視点

ユーザーからペルソナの指定があれば、それに従います。指定がなければ、最も関連性の高い視点を選びます。

• 初めて使うユーザー：わかりやすさ、方向づけ、ラベル、次の手順、エラーからの復旧。
• デザイナー：階層、間隔、タイポグラフィ、独自性、操作性。
• オペレーター：繰り返し行うワークフロー、情報密度、テーブル、フィルター、一括操作、ステータスの明瞭さ。
• デモのプレゼンター：ストーリー、信頼性、印象的な瞬間、デモ中の危険要因。
• レスポンシブ監査担当者：モバイルでの適合性、はみ出し、ターゲットサイズ、ビューポートごとのレイアウト。

ペルソナに沿ったブラウジングを、曖昧な好みのコメントに終わらせてはいけません。指摘には、引き続き証拠と影響を示す必要があります。

Findings

ブラウザーで確認できた証拠に裏付けられる場合に限り、問題を報告してください。些細な印象を長く列挙するより、数を絞って重要な問題を報告してください。

各問題には、次の項目を含めてください。

• 重大度または優先度
• ルート／画面
• 発生したこと
• 重要である理由
• 再現手順
• スクリーンショットのパス、録画のパス、コンソールメッセージ、ネットワークステータス、画面上の状態などの証拠
• コード調査で裏付けられる場合は、考えられる原因
• 推奨する修正

意味のある問題がない場合は、その旨を明確に述べ、何をテストしたかを記載してください。

Fix Mode

ユーザーが修正を依頼した場合：

1. ブラウザーで問題を再現します。
2. 関連する最小限のコードパスを調査します。
3. 範囲を絞って編集します。
4. 関連するチェックを実行します。
5. ブラウザーでルートまたはフローを再テストします。

ツールで録画できる場合は、対象のフローについて修正前と修正後のクリップを撮影し、レポートに両方のパスを記載してください。

ユーザーがコード監査も明示的に希望していない限り、再現できていない推測上の問題は修正しないでください。

Output

完全なレポートには、次を使用してください。

## Fieldtest Report

Target: [URL]
Mode: [report-only QA | QA plus fixes | focused route/feature/regression | responsive/mobile audit | persona browsing]
Lens: [persona/lens]
Browser: [tool used | static inspection only, not browser-verified]
Viewports: [sizes tested]
Recordings: [clip paths, or none]

## Findings

### High

### Medium

### Low

## What Was Tested

## Residual Risk

対象を絞った確認では、対象、手順、結果を含めたうえで、出力を短くしてください。

Completion Check

完了する前に、次の点を確認してください。

• アプリが実際にブラウザーで読み込まれた
• テストした URL とビューポートサイズが明記されている
• ツールが利用できる場合、コンソールとネットワークの問題を確認した
• 問題に再現手順または具体的な証拠が含まれている
• 確認範囲に、調査したケースと未確認のケースが明記されている。読み込んだケースや撮影したケースは、目視確認済みとして数えない
• 破壊的な操作は、確認なしに実行していない
• 修正を行った場合は、ブラウザーで再テストした
• ツールで録画できる場合は録画を撮影した。できない場合は、その旨を明記した