# 本物のバグを隠さずにflakyなテストをquarantineする方法

> quarantineは、既知のflakyなテストをブロッキングパスから外してbuildを落とさないようにしつつ、修正のために可視化して追跡し続けます。

Source: https://latchkey.dev/ja/learn/ci-cd-concepts/how-to-quarantine-flaky-tests  
Updated: 2026-06-25

quarantineとは、既知のflakyなテストを削除せずにmergeをブロックするパスから引き離す規律です - こうしてbuildの信頼性を保ちながら、修正すべきテストとして記録に残しておきます。

テストが明らかにflakyだと分かったとき、悪い選択肢が3つ(無視する、削除する、mergeをブロックさせる)と、良い選択肢が1つあります: quarantineです。正しく行えば、coverageを失わずにノイズを取り除けます。

## 削除や永久retryではなくquarantineする理由

flakyなテストを削除すると、flakyでないときに提供していたcoverageを失います。一律のretryは本物の回帰を隠します。mergeをブロックさせ続けると、赤いbuildを無視するようチームを慣らしてしまいます。quarantineはその針の穴を通します: テストは依然として実行されレポートしますが、その結果はもはやmergeのgateにはなりません。

## quarantineの方法

- テストにタグを付け(例えば `quarantine`/`flaky` マーカー)、runnerが分離できるようにします。
- quarantineされたテストは、レポートはするがbuildを落とさない非ブロッキングのレーンで実行します。
- quarantineした瞬間に、そのテストに紐づく追跡チケットを起票します。
- テストを実行し続けて、どれくらいの頻度でまだflakyになるかのデータを収集します。

## 誠実さを保つ

quarantineは一時的で可視でなければ、死んだcoverageの墓場になってしまいます。テストがquarantineに留まれる期間に上限を設け、quarantineリストをdashboardに表示し、期限が切れたら修正か削除かの判断を必須にしましょう。flake管理の原則が当てはまります: ノイズは封じ込め、シグナルは決して黙らせないこと。

## 戻すか削除するか

根本の非決定性が修正されたら、テストをブロッキングスイートに戻し、多数の実行にわたって安定していることを確認します。決定論的にできず、かつ固有のものを何もテストしていないなら、意図的に削除しましょう - 永久にquarantineされた亡霊よりも、誠実な削除のほうがましです。

## FAQ

### What is How to quarantine flaky tests without hiding real bugs?

When a test is provably flaky, you have three bad options (ignore it, delete it, or let it block merges) and one good one: quarantine. Done right it removes the noise without losing the coverage.

### Why quarantine instead of delete or retry-forever?

Deleting a flaky test loses the coverage it provides when it is not flaking. Blanket-retrying hides genuine regressions. Letting it block merges trains the team to ignore red builds. Quarantine threads the needle: the test still runs and reports, but its result no longer gates the merge.

### Keep it honest?

Quarantine must be temporary and visible, or it becomes a graveyard of dead coverage. Cap how long a test may stay quarantined, surface the quarantine list on a dashboard, and require a fix-or-delete decision when the cap expires. The principle from flake management holds: contain the noise, never silence the signal.

### Promoting back or removing?

When the root nondeterminism is fixed, return the test to the blocking suite and confirm it is stable across many runs. If it cannot be made deterministic and tests nothing unique, delete it deliberately - an honest removal beats a permanently quarantined ghost.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt