このテストはフレイキーですか、それとも本物のバグですか？

フレイキーテストとは、誰も何も修正していないのに失敗した後にリトライで成功したテストのことであり、本物のバグとは、何度リトライしても変わらない理由で失敗するものです。Verdict System LLC の Nexus Studio は、すべてのリトライを記録することでこれらを区別します。リトライで成功した失敗には FLAKY、実際の問題には BREACHED、失敗自体に一貫性がない場合には BREACHED_FLAKY と判定します。リトライによって欠陥が成功（グリーン）に変わることは決してありません。

執筆：Nexus Studioチーム（Verdict System LLC）。2026年10月7日。

フレイキーテストとは何ですか？

フレキー（不安定）なテストとは、実行ごとの結果が一致しないテストのことです。コードやテストに変更がないにもかかわらず、ある試行では失敗し、別の試行では成功します。Nexus Studioにおいて、この言葉には1つの明確な意味があります。FLAKYとは、一度失敗した後に再試行で成功し、何も自己修復（ヒール）されなかったテストを指します。アプリケーションまたはテストのいずれかが不安定であり、何も修正されていません。

自己修復ステップがセレクターの修復を試みて失敗した場合であっても、すべての試行で発生する完全な失敗はフレキーではありません。以前のバージョンのエンジンでは、このようなケースをFLAKYとして記録していました。チームはFLAKYを「テスト自体に問題がある」と解釈して見過ごしてしまい、その結果、破損したアプリケーションがノイズとして本番環境にリリースされてしまっていました。現在のエンジンではそのような処理は行われません。

再試行は本物のバグを隠してしまうのでしょうか？

隠してしまう可能性があり、その理由は状態の数にあります。「成功」と「失敗」の2つの状態しかない場合、再試行で成功すると赤（失敗）の実行が緑（成功）に変わり、アプリケーションの間欠的な不具合が見えなくなってしまいます。これは見つけるのが最も困難でコストがかかるバグの1つです。赤の表示がネットワークの一時的な瞬断やブラウザのクラッシュも意味するようになると、チームは失敗の原因を読み解く代わりに再実行するようになり、テストスイート全体の信頼性が失われていきます。

Nexus Studioは再試行の事実を可視化し続けます。一度失敗した後に成功したテストは、SECUREとはみなされません。CI上では終了コード0で終了するためビルドを失敗させることはありませんが、レポートおよび履歴（History）にはFLAKY（条件付きの成功）として表示されます。チェックの詳細な順序については、14の判定がどのように決定されるかをご覧ください。

FLAKY、BREACHED、BREACHED_FLAKYの違いは何ですか？

FLAKY: 失敗した後に再試行で成功し、修復は行われませんでした。失敗した試行のraw-data.jsonを確認し、次に履歴（History）の傾向を確認してください。終了コード0で終了します。
BREACHED: テストが1回の試行で失敗し、環境やハーネスのパターンではそのエラーを説明できません。アサーションが失敗しています。これがバグ報告に該当し、終了コード1で終了します。
BREACHED_FLAKY: 以前の再試行の後に最後の試行でもテストが失敗し、環境やハーネスのパターンでは説明がつきません。失敗自体に一貫性がありません。バグを報告する前に各試行を比較してください。終了コード1で終了します。

これらと隣接する2つの判定が、状況を正確に保ちます。AUTO_RECOVERは自己修復によってセレクターが置き換えられて成功した状態であり、作成者が指定したロケーターが無効になっているため、クリーンなテストではありません。初回の試行でタイムアウトのみで失敗し、再試行で成功したテストは、不安定さではなくレイテンシー（遅延）を示しているため、SECUREとなります。

失敗がBREACHEDまたはBREACHED_FLAKYに判定される前に、分類エンジンは決められた順序で他の要因（ハーネスエラー、クラッシュ、ブロック、ホストへの接続不能、タイムアウト）を除外します。これらのいずれでも説明がつかない失敗のみが、不具合の検出結果となります。そのため、タイムアウトやCAPTCHAがバグ報告として届くことはありません。

再試行はどのようにカウントされますか？

エンジンは実行の試行回数を読み取ります。再試行回数が0より大きく、かつ成功したテストは、セレクターが修復されていない限りFLAKYとなり、修復された場合はAUTO_RECOVERとなります。再試行回数が0より大きく、環境要因による説明がつかないまま失敗またはタイムアウトしたテストは、BREACHED_FLAKYとなります。クリーンな成功には、再試行回数が0であり、セレクターの修復が行われていないことが必要です。

FLAKYとは試行結果が一致しなかったことを意味し、それ以外の意味はありません。再試行回数が0回の、単一の試行における失敗がフレキーと判定されることは決してありません。履歴（History）の各行にはretry_attemptとattemptsも記録されるため、カウント情報は実行データとともに保持されます。

各判定にはどのような証拠（エビデンス）が残されますか？

FLAKY: screenshot.png、metadata.json、raw-data.json です。このフォルダーには失敗した試行の raw-data.json が保持されるため、リトライによって失敗が隠れた場合でもログが残ります。これはデフォルトで有効になっている「Keep evidence of a FLAKY / AUTO_RECOVER pass」設定に準拠しています。
BREACHED_FLAKY: report.md、metadata.json、raw-data.json、screenshot.png であり、失敗時のビデオはデフォルトで保持されます。
BREACHED: 同じファイル群であり、ビデオはデフォルトで保持されます。

判定結果はエビデンスフォルダー名（たとえば [BREACHED] で終わる名前など）に含まれます。Evidence ページでは、1 つの失敗したテストをすべてのファイルにわたって追跡します。

History はどのようにして結果が反転するテストを見つけ出しますか？

History は、テストごと、およびブラウザやデバイスごとに、判定結果、リトライ回数、エラーシグネチャを含む実行あたり 1 行のレコードを保持します。それらの行から、セッション、日、週ごとの傾向（Regressed、Recovered、Still broken、Slower）を表示します。グリーン、レッド、そして再びグリーンになるテストは、再実行の中に埋もれて消えてしまうことなく、そこに表示されます。

Evidence Locker および Patrol のリスクランキングは、結果の反転、失敗、または時間の消費の頻度によってテストを順序付けします。また、履歴データに対するロジスティック回帰からの予測リスクも表示され、データが少ない場合は EWMA にフォールバックします。1 回や 2 回の実行ではパターンを特定できないため、5 回未満の実行では flaky と判定されるものはありません。

限界

リトライこそが FLAKY と SECURE、そして BREACHED_FLAKY と BREACHED を分けるものです。リトライを無効にすると、断続的な失敗は BREACHED になります。
FLAKY は試行結果が一致しなかったことを示します。理由は示されません。アプリケーション側にあるのか、テスト側にあるのか、原因を見つけ出す作業は依然として人間が行う必要があります。
分類はエラーテキストを読み取るため、403 や Forbidden などの単語を含むカスタムアサーションメッセージは、環境の問題として読み取られる可能性があります。判定結果に疑問がある場合は、metadata.json を開いてください。
5 回未満の実行では、History もリスクランキングも flaky と判定することはありません。

次のステップ

Evidence ページには失敗したテストが残すすべてのファイルが表示され、How Nexus Studio decides 14 test verdicts ではチェックの順序を解説しています。30-day trial では、ご自身のテストで同じエンジンを実行できます。

ご自身のマシンで最初にチェックを実行するには、本当のバグと不安定なテスト（フレイキーテスト）を見分けるには？に実行可能な例があります。