Playwright の Flaky テストを原因特定するプロンプト
いつ使うか
ローカルでは通るのに CI で時々落ちる、3回に1回 timeout する——典型的な flaky テスト。「リトライ回数を増やす」で誤魔化す前に、待機戦略・セレクタ・状態リセットの観点から構造的に潰したい時に使う。
プロンプト本文 (コピペして使う)
あなたは Playwright のエンジニアです。以下の flaky なテストを「原因の構造分類→修正案」の順で分析してください。
## 観察された挙動
- 失敗頻度: <例: 5回中1回>
- 失敗時のエラー: <例: Timeout 30000ms exceeded waiting for selector>
- 失敗時のスクリーンショット/トレース: <貼れるなら>
## テストコード
```ts
<該当テスト関数を貼る>
```
## 分析フレーム (該当するものに○)
1. **暗黙の待機不足** (waitForLoadState / locator の auto-waiting で済むか)
2. **セレクタ脆弱性** (nth-child / text= の揺れ / aria 不在)
3. **状態リーク** (前テストの cookie/localStorage が残る)
4. **アニメーション競合** (CSS transition 中にクリック)
5. **ネットワーク不確実性** (mock 不足、外部 API 待ち)
6. **タイムゾーン/ロケール** (Date 依存テストの timezone)
7. **並列実行衝突** (DB 共有、ポート衝突)
## 出力
1. 一次原因の特定(上記分類のどれか + 根拠)
2. 修正コード(before/after の diff 形式)
3. 再発防止のための追加 assertion 1つ
4. CI 側で増やすべきトレース設定(--trace=retain-on-failure 等)
## 禁止
- test.setTimeout を伸ばすだけの対処
- expect(...).toBeVisible({ timeout: 60000 }) のような長時間待機での隠蔽効くポイント
- 7つの原因カテゴリを先に提示すると、AI の分析が漠然としない
- 禁止事項を明示すると、Timeout を伸ばすだけの誤魔化し回避策が出てこない
- 修正後の追加 assertion を要求すると、同じ flaky が再発しにくい
よくある質問
- Cypress や Vitest の flaky テストにも使えますか?
- 7 つの原因カテゴリ (待機不足/セレクタ脆弱性/状態リーク/タイミング依存/外部依存/環境差分/並行実行) はテストフレームワーク非依存の概念なので、Cypress や Playwright Test 以外でも適用可能です。「Playwright のエンジニアです」の部分を該当ツール名に置き換えてください。
- スクリーンショットが貼れない場合はどうしますか?
- CI のログから失敗時のセレクタ・エラーメッセージ・直前の操作 (action) の 3 点を最低限抜き出して貼れば、原因カテゴリの仮説立ては機能します。
- Timeout を伸ばすだけの提案が返ってきます
- プロンプトの「禁止事項」セクションに「retry 回数を増やすだけの提案・timeout 値を伸ばすだけの提案は不可」と明示してください。それでも返る場合は「禁止事項に違反しているので再生成して」と返すと修正されます。
このプロンプトを実戦で使った所感や改善案があればぜひフィードバックを。姉妹サイト ai-pick.tech では AI x SNS集客の運用ノウハウを公開しています。