# CIにおけるFlakyテスト: 原因、検出、封じ込め

> 何がテストをflakyにするのか、不安定さをどう検出するのか、そして本物のバグを隠さずにquarantineと制限付きretryでどう封じ込めるのか。

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

flakyなテストは同じコードでpassしたりfailしたりします。管理されないまま放置すると、不安定さはCIへの信頼を蝕み、やがて赤いbuildが何も意味しなくなります。

flakyなテストは非決定的です。その結果はテスト対象のコード以外の何かに依存します。これらは腐食的です。なぜならチームに失敗を無視するよう仕向けるからです - CIの目的とは正反対です。

## よくある原因

- race conditionとタイミングの前提(sleepベースの待機)。
- テストの順序への依存と共有された可変状態。
- 実際のネットワーク、時計、外部サービスへの依存。
- リソースの逼迫(遅く負荷のかかったrunnerがtimeoutを超過する)。

## 不安定さの検出

run全体にわたってテストごとのpass/failの履歴を追跡します。同じcommitでfailしてからpassするテストは、定義上flakyです。既知の良好なcommitでスイート全体を繰り返し再実行すると、最悪の要因が浮かび上がります。

## バグを隠さずに封じ込める

既知のflakyなテストをquarantineしてmergeをブロックしないようにし、根本の非決定性を修正するチケットを起票し、既知のflakyなテストにのみ制限付きretryを適用します。原則は、ノイズをretryし、決してシグナルをretryしないこと - 一貫して再現する失敗は常に表面化しなければなりません。

## FAQ

### What is Flaky tests in CI?

Flaky tests are nondeterministic: their result depends on something other than the code under test. They are corrosive because they train teams to ignore failures - the opposite of what CI is for.

### Detecting flakiness?

Track per-test pass/fail history across runs. A test that fails and then passes on the same commit is flaky by definition. Re-running the whole suite repeatedly on a known-good commit surfaces the worst offenders.

### Containing it without hiding bugs?

Quarantine known-flaky tests so they do not block merges, file tickets to fix the root nondeterminism, and apply bounded retries only to tests known to be flaky. The principle: retry the noise, never the signal - a consistently reproducing failure must always surface.

---

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