test-suite-curation

テスト A とテスト B はまったく同じ行をカバーしているため、疲れたエンジニアが B を削除します。そして 3 週間後、B だけが丸め処理の正しさを検証していたため、本番環境に不具合が混入します。カバレッジが同じだからといって、冗長とは限りません。このスキルは、回帰テストスイート全体を一つのコーパスとして監査し（人手では誰も行わない冗長性分析です）、感覚ではなく根拠に基づいてテストを削減します。また、あらゆる削除を破壊的変更として扱い、猶予期間、担当者による承認、監査人に説明できる記録を必須とします。

クイックリンク

目的	移動先
各テストが固有にカバーする行／分岐を確認する	カバレッジのフィンガープリント
「同じカバレッジ」なら「どちらかを削除」と判断してよいか確認する	カバレッジ同一性の落とし穴
コピー＆ペーストされた類似テストを見つける	類似テストのクラスタリング
一度も失敗しないテストと常に不安定なテストを見つける	CI 履歴の分析
冗長、不要、価値が低い、維持のいずれかを判断する	削減の判断ルール
フラットなテストスイートを smoke／core／extended に分割する	階層化
指摘したテストを安全に削除する	破壊的変更の安全対策
「何を、なぜ削除したか」の記録を作成する	監査記録

確認事項

まず、プロジェクトルートにある .agents/qa-project-context.md を確認し、すでに回答されている項目は省略してください。そのうえで、次の点を確認します。

• 使用言語とテストランナーは何ですか？ pytest+coverage.py、Jest/Vitest+Istanbul、Go、JUnit など、スタックによってテストごとのコンテキスト取得方法が異なります（ミューテーションテストツールも同様です）。
• CI のテスト結果履歴はありますか？ ある場合、どのくらいの期間を遡れますか？ JUnit／Datadog／Trunk の履歴がなければ、一度も失敗しないテストや不安定なテストのシグナルは分析できず、カバレッジとクラスタリングのみを利用できます。
• テストスイートの規模と現在の実行時間はどのくらいですか？ これにより、階層化の目標（例：smoke を 5 分未満にする）や、テストごとのカバレッジを 1 回の実行で取得できるか、分割実行が必要かが決まります。
• ビジネスリスクのマップ／重要な経路はありますか？ 階層化も「維持」という判断も、どちらもそれに左右されます。ない場合は、まず risk-based-testing を実行してください。
• 削除を承認するのは誰ですか？ CODEOWNERS ファイルはありますか？ 削除は破壊的変更です。このスキルが何かを削除する前に、承認者を明確にする必要があります。
• 許容できる観察期間はどのくらいですか？ テストを恒久的に削除する前に、スキップ状態で隔離して実行し続ける期間です（デフォルト：2 スプリント／2 リリース）。

---

中核となる原則

1. カバレッジの一致は冗長性を意味しません。 同じ行を実行する2つのテストでも、オラクル、入力、エッジケースが異なり、まったく違うことを検証している場合があります。行カバレッジや分岐カバレッジで分かるのは、コードが実行されたことだけであり、何が検証されたかは分かりません。あるテストが別のテストを包含していることを示す唯一の証拠は、残したテストが同じ不具合を検出することです。これはカバレッジの差分ではなく、ミューテーションテストによって証明します。

2. エージェントの強みはコーパス全体の分析であり、削除の権限ではありません。 エージェントは、4,000件のテストのフィンガープリントを作成し、類似したテストをクラスタリングし、CIの履歴と相互参照する作業を数分で行えます。これは人間が手作業では行わない作業です。それこそがエージェントの価値のすべてです。ただし、エージェントは提案し、人間が承認します。コーパス規模の分析を、コーパス規模の自動削除に決して発展させてはいけません。

3. 削除は破壊的な操作であり、実際に元に戻せるようにする必要があります。 「Gitの履歴に残っている」は復旧計画ではありません。まず隔離し（skip/xfailにするか、非推奨スイートに移動します）、定めた期間にわたって観察し、すり抜けた不具合がないか確認してから、承認を得て削除します。安全策となるのは猶予期間であり、コミットログではありません。

4. それぞれの扱いを区別します。 冗長、古い、価値が低い、はそれぞれ異なる状態であり、それぞれに異なる対応が必要です。これらをひとまとめにして「削除」に分類すると、本当に必要なカバレッジを失うことになります。一度も失敗したことがないテストと、失敗しようのないテストは同じではありません。

5. 直感ではなく証拠を、テストごとに記録します。 削除するテストごとに、カテゴリ、そのテストを置き換えるテスト、カバレッジの差分、承認者、復元方法を記した行を残します。その行を埋められないなら、テストを削除してはいけません。

---

1. カバレッジのフィンガープリント作成（テストごと）

誤った方法は、ファイルごとの割合しか分からない、単一の統合された--covレポートです。どのテストがどの行をカバーしたかは分からないため、どのテスト同士が重複しているかも分かりません。必要なのは、テストごとの（動的）コンテキストです。

pytest / coverage.py — 動的コンテキストを使って、各行を実行したテストを記録し、分岐カバレッジを有効にします。

pytest --cov=src --cov-branch --cov-context=test

--cov-context=testを指定すると、pytest-covはpytestの各テストIDと実行フェーズ（setup、run、teardown）ごとに、coverage.pyのコンテキストを切り替えます。 パラメーターIDも個別に保持されます。フィンガープリントを比較する前に、各テストの3つのフェーズを統合してください。フィクスチャの帰属を調べるため、フェーズごとの生データも保持します。Coverage.pyのdynamic_context = test_functionは関数のコンテキストを記録しますが、pytestのフェーズやパラメーターを同様に識別することはできません。実行されたアークを区別するには、--cov-branchを追加します。結果は.coverageに書き込まれます。

次に、.coverageのSQLite DBからcontextsテーブルを読み取り、テストごとのフィンガープリントを作成します。各テストについて、カバーした(file, line)と(file, branch-arc)の組み合わせを正確に集めます。これらの集合から、次の項目を算出できます。

• 一意にカバーされる行 — 1つのテストだけがカバーする行や分岐です。そのテストを失うと、そのカバレッジは完全に失われます。これらのテストはしっかり役割を果たしているため、保護してください。
• 包含関係 — テストAのカバー集合がテストBのカバー集合を包含します。冗長性の候補にはなります（ただし、§2を参照してください。これは証明ではありません）。

.coverageからコンテキストを取得するSQL、テストごとの行・分岐の集合を作成して一意にカバーされる範囲と包含関係を算出するPythonコード、およびJS/Vitest+Istanbulの--coverageに相当する方法（テストごとのレポーターを使ったcoverage-final.json）については、references/coverage-fingerprinting.mdを参照してください。

テストファイルごとの行数でテストを順位付けしないでください。また、全体のカバレッジ率が低いという理由だけでテストを削除しないでください。1行だけのテストが、重要な分岐を守る唯一のテストである場合もあります。

---

2. カバレッジ一致の落とし穴（最も重要なルール）

これは、このスキルで最も重要なルールです。テストごとのデータでテスト A とテスト B がまったく同じ行をカバーしていると分かった場合、単純に「重複しているので、片方を削除しよう」と結論づけがちです。しかし、それは誤りです。注意すべき点は次のとおりです。

カバレッジが一致していても、テストのアサーション、入力、オラクルが同じだとは証明できません。 2 つのテストが同じ行をカバーしながら、一方は HTTP ステータスをアサートし、もう一方はレスポンス本文をアサートしていることがあります。また、異なるエッジケースの入力を渡している場合もあります。一方は同じ行をカバーしつつ異なる値をアサートし、もう一方は同じ行をカバーしつつ異なる状態を確認していることもあります。カバレッジが測るのは実行であり、検証ではありません。

B が実際に冗長かどうか、つまり A が B の障害検出能力を本当に包含しているかを調べるには、ミューテーションテストを実行します。

• Python では mutmut（3.6.0 以降）または cosmic-ray、JS/TS では StrykerJS（9.x）、Java/JVM では PIT、Rust では cargo-mutants を使用します。
• ミューテーションテストでは、カバー対象のコードに障害（ミュータント）を注入します。変更後のコードでテストが失敗すれば、そのテストはミュータントを「殺した」ことになります。A が B の殺すミュータントをすべて殺すなら、A は B の障害検出能力を実際に包含しているため、B は削除候補として妥当です。A が見逃すミュータントを B が殺すなら、B は A が検出できない種類の欠陥を捕らえています。カバレッジが同じでも、B は残してください。

判断手順： カバレッジが一致 → 候補としてフラグを付ける → ミューテーションテストで確認する → その後に限り削除を提案する。アサーションが異なり、ミューテーションテストの結果も異なる場合は、両方を残し、削除しないでください。疑わしい行だけを対象にミューテーションテストを実行し、キルセットを比較するための mutmut/Stryker の設定については、references/mutation-confirmation.md を参照してください。

---

3. 類似テストのクラスタリング

目的は、同じファイル内のすべてのテストをフラグ付けすることなく、コピー＆ペーストされたテストを見つけることです。ファイル名でテストをグループ化してもクラスタリングにはなりません。類似性について何も分からないからです。組み合わせて使える、妥当なシグナルは 2 つあります。

1. AST（抽象構文木）の類似性。 各テストを AST に解析し、識別子名とリテラルを正規化で取り除いてから、構造を比較します。トークン／ツリーの類似度指標（正規化したトークンシャードに対する Jaccard 係数、AST n-gram に対するコサイン類似度、またはツリー編集距離）を使います。AST に基づく比較では、完全一致の文字列比較や生の diff では妨げになる書式や変数名の違いを無視できます。類似性の指標として、生の行番号を使わないでください。

2. カバレッジプロファイルのシグネチャ。 §1 のとおり、各テストにはすでに、カバー対象の行／分岐の集合である実行プロファイルがあります。カバレッジのシグネチャと AST の両方がほぼ同一のテストは、類似テストである可能性が高い候補です。どちらか一方だけでは不十分です。

調整可能な類似度しきい値（例：凝集型／階層型クラスタリング。設定可能なしきい値で区切ります。まずは約 0.85 から始め、許容できる誤検出の度合いに応じて調整してください）でクラスタリングします。出力するのはクラスタであり、削除対象ではありません。

各クラスタは人によるレビューに回します。 エージェントがクラスタ全体を自動で削除することはありません。コピー＆ペーストされたテストは、重要なアサーションが 1 つだけ異なることがよくあるためです。各クラスタについて、メンバー、ペアごとの類似度、カバレッジプロファイルの重複度を提示し、どれを（もしあれば）統合するかを人が判断できるようにします。

AST の正規化、シャード／Jaccard およびツリー編集による類似度関数、調整可能なしきい値を使った凝集型クラスタリングについては、references/clustering.md を参照してください。

---

4. CI 履歴の分析

テスト結果の履歴（JUnit XML アーカイブ、または履歴をすでに保存しているプラットフォーム：Datadog Test Optimization、Trunk Flaky Tests、BuildPulse、CircleCI test insights）を解析します。各テストについて、成功率／失敗率と反転率（連続する実行で成功↔失敗に切り替わる頻度）を計算します。分析結果は 2 種類あり、それぞれ意味が大きく異なります。

一度も失敗しないテスト（対象期間中に失敗が 0 回／成功率 100％）。一度も失敗していないテストをすべて削除するのが、安易なやり方です。それは誤りです。一度も失敗していないからといって、削除すべき、あるいは役に立たないとは限りません。テストが一度も失敗しないことが多いのは、変更頻度が低く、リスクも低い安定したコードを守っているからです。つまり、誰も触れないコードなので、テストも失敗しません。この期間における不具合検出のシグナルが弱いというだけで、価値がないわけではありません。対応方針は、削除せずに調査することです。テスト対象コードの変更頻度とリスクを確認します。単に回帰が起きていないだけで、重要なパスをカバーしているなら、そのテストは残します。

常に不安定なテスト。不安定さは単一の実行結果では判断できません。実際の定義は、同じ SHA／同じコミットで結果が異なることです。つまり、同じコードで成功と失敗の両方が発生しています。実行結果をコミット SHA でグループ化し、同じ SHA で両方の結果が出ているテストを見つけて検出します（Trunk と BuildPulse には、この機能が標準で備わっています）。「CI を整理するために、不安定なテストを削除する」というのが、安易なやり方です。それは誤りです。不安定なテストが、実際のパスをカバーする唯一のテストである可能性もあります。対応方針は、隔離して不安定さを修正し、CI を整理するために削除しないことです。隔離すると、すぐに CI のノイズを減らせます。一方で、根本原因は引き続き修正します。個々の不安定なテストの実行時隔離と自己修復については、test-reliability を参照してください。

JUnit XML の集計スクリプト、同一 SHA での不安定さを調べるクエリ、Datadog／Trunk API からのデータ取得方法については、references/ci-history-mining.md を参照してください。

---

5. 削除判断のルール

「重複しているように見える」ものをすべて削除するのはやめましょう。失敗カテゴリはそれぞれ異なる状態を示すため、カテゴリごとに異なる対応が必要です。

カテゴリ	定義（テストの状態）	対応方針
重複	別のテストに包含されている — 同じ行をカバーし、残すテストが同じミュータントを検出する（§2）	統合または削除 — ただし、ミューテーションによる検出チェックで包含が確認された後に限る。まず隔離する
旧式	削除済みの機能、デッドコード、またはすでに存在しないパスをテストしている	削除 — テスト対象のコードはすでに存在しません。対象が本当に存在しないことを確認してから削除します
価値が低い	一度も失敗しておらず、かつ単純（ゲッター、何もしない処理、意味のあるアサーションがない）	隔離／レビューに回す — 価値が低いことは、価値がないことを意味しません。削除する前に確認します
維持	独自の対象をカバーする、不具合を検出する（不具合検出の実績がある）、またはリスクの高いパスを守る	維持 — カバレッジが重複していても保護します

基本方針は、カテゴリごとに異なる対応をすることです。redundant => merge/delete-after-mutation-check、obsolete => delete、low-value => quarantine/review、keep => keep。フラグが付いたすべてのテストに単一の一律ルールを適用することは、カバレッジを失うアンチパターンです。「重複」と「価値が低い」は、どちらも rm で直接削除するのではなく、隔離を経由することに注意してください。

---

6. ティア分け（スモーク／コア／拡張）

フラットなテストスイートをティアに再編することは、実行速度順に並べることではありません。スモークはファイル内の先頭からN件のテストではなく、無作為抽出でもありません。また、各テストの実行速度だけを基準にティア分けしてはいけません。次の2つの証拠に基づいてティア分けします。

1. ビジネスリスク／クリティカルパス — リスクマップ（risk-based-testing）に基づきます。収益、認証、データの整合性、主要なユーザージャーニーを守るテストは、実行速度にかかわらずスモーク／コアに分類します。
2. 欠陥検出の履歴 — 実際に実際のバグを検出したテスト（CIの履歴と関連するバグチケットを調べ、欠陥を修正したコミットで失敗したテストを特定します）。回帰バグを検出してきた実績のあるテストは、その実績に基づいて上位のティアに分類します。

ティア	目標	選定の根拠
スモーク	高速で、すべてのプッシュ時に実行し、数分で完了する、クリティカルパスのみ	最もリスクの高いパス＋欠陥を検出した実績のあるテスト。すべてのコミットのゲートにできる速度
コア	PRごと／マージ時のゲート	すべてのクリティカルおよび高リスクのカバレッジ。スモークより広範
拡張	全件／夜間／低速／リリース前	その他すべて。網羅的で、実行時間が長く、エッジケースを含む

実行時間をティア分けの基準にすることはできますが、二次的なタイブレーカーとしてのみ使用し、主要な基準にはしません。 実行時間や所要時間は同点の場合に使いますが、ティアを決める基準にはなりません。リスクが同程度のテストでは、スモークにはより高速なものを優先します。ティアはマーカー／タグとして設定します。たとえば、@pytest.mark.smoke／@pytest.mark.extended、Jest／Vitestのタグ、JUnitのカテゴリを使用すれば、ファイルを移動せずに pytest -m smoke でティアを選択できます。マーカーの方式と欠陥検出履歴のクエリについては、references/tiering.md を参照してください。

---

7. 削除の安全策（猶予期間）

600件のテストを削除するよう求められた場合、安易なエージェントは600個のファイルを rm するPRを1つ作ります。テストの一群を1つのPRですべて削除してはいけません。また、テストファイルを rm してはいけません。 削除は破壊的な操作です。必ず段階を踏んでください。

1. 削除の前に隔離し、直接削除しないでください。 対象のテストをスキップ扱いにする（@pytest.mark.skip(reason="curation-2026-Q2, see audit row")、xfail、Jestの .skip を使用する）か、リポジトリ内に残る quarantine/／deprecated/ スイートに移動します。テストは実行されなくなりますが、見える状態で残り、すぐに復元できます。
2. 人による承認が必須です。 テストディレクトリの CODEOWNERS に指定された承認者、またはPRで明示されたレビュアーが承認する必要があります。「冗長なテストならレビュー不要」ということはありません。§2で確認されるまでは、冗長性はあくまで仮説です。
3. 観察期間を定めてください。 対象のテスト群を隔離した状態でテストスイートを実行し、猶予期間を設けます。デフォルトは2スプリント／2リリースです。その間、すり抜けた欠陥を監視します。隔離したテストで検出できたはずの事象がないか、本番環境のインシデントやバグチケットを確認してください。この期間中に欠陥がすり抜けた場合、そのテストは冗長ではありません。復元してください。
4. その後に限り、各テストを§8の監査行に紐づけて、小さな単位で削除します。
5. 復元できる状態にしてください。 隔離場所とコミットを記録し、どのテストも1ステップで復元／リバートできるようにします。Gitの履歴は最低限の備えであり、復旧計画ではありません。

隔離用マーカー、テストパス用のCODEOWNERSの記述例、すり抜けた欠陥の監視チェックリストについては、references/destructive-safety.md を参照してください。

---

8. 監査記録

削除の妥当性を将来のエンジニアや監査担当者に示す成果物は、削除したテストの件数ではありません。それぞれに実質的な根拠を記載した、**テストごとの記録（削除したテスト1件につき1行）**です。「重複したテストを600件削除した」というだけでは監査できません。

各行には次の項目を記載します。

• テスト ID／パス — 削除したもの。
• カテゴリと理由 — 重複／旧式／価値が低い、ならびに具体的な根拠（「包含されている。残すテストが同一のミューテーションセットを検出する」など）。
• 置き換え先 — そのテストを網羅／置き換える、残す（置き換え先となる）テストの ID（重複の場合）。つまり、包含するテストが網羅している、または置き換え先のテストが置き換えていることを示します。
• カバレッジの差分 — 削除後にカバーされなくなる行／分岐（削除前／削除後）。理想的には、§1 で証明されたとおり、純損失はゼロです。
• 承認 — 承認者の名前、PR／コミットの SHA、承認日。
• 復元方法 — 隔離場所と、元に戻すための1行コマンド。

削除とともにバージョン管理できるよう、コミット済みの CSV／Markdown テーブル（例：docs/test-curation-log.md）として保存します。列の完全なスキーマと記入例については、references/audit-record.md を参照してください。

---

アンチパターン

1. 「カバレッジが同じだから、片方を削除する」

最も大きな損害につながる間違いです。同一の行カバレッジが証明するのは、その行が 実行された ことだけであり、アサーションが一致することではありません。削除を提案する前に、ミューテーションテスト（§2）で包含を確認してください。

2. 2つの良好なシグナルを、削除してよいという合図と捉える

18か月間一度も失敗しておらず、別のテストに完全にカバーされている（同じ行をカバーしている）テストは、「削除しても確実に安全だろう」と考えられがちな典型例です。しかし、それだけでは十分ではありません。自動的に削除せず、検証を続けてください。テストが一度も失敗していないのは、価値がないのではなく、コードが安定していることを示している可能性があります。多くの場合、それはリスクや変更が少ないという意味であり、そのテストが冗長だという意味ではありません。また、別のオラクルがこのテストに固有である可能性もあります（このテストだけが確認する別のアサーション、入力、エッジケースなど）。ミューテーションに関する問いを確認してください。他方のテストは、このテストが行うことをアサート／捕捉／検出するでしょうか。その確認後にのみ、隔離して猶予期間中は様子を見てから削除します。どちらのシグナルも必要ですが、それだけで十分ではありません（以下の§9／§2／§7）。

3. テストごとのコンテキストなしで、カバレッジを一括計測する

コンテキストを指定せずに --cov=src を実行すると、ファイルごとの割合しか得られず、テストごとの重複を特定できません。--cov-context=test を使用し、.coverage DB からテストごとのコンテキストを確認してください。

4. ファイル名が近いという理由で類似テストをまとめる

ファイル名が近いことは、類似していることを意味しません。調整可能なしきい値を使って、AST の類似度とカバレッジプロファイルのシグネチャに基づいてクラスタリングし（§3）、クラスタは人が確認するようにしてください。クラスタ全体を自動削除してはいけません。

5. 失敗したことのないテストや不安定なテストを削除する

失敗したことがないテスト → 調査する（変更頻度の低いコードである可能性が高い）。削除してはいけません。不安定なテスト → 隔離して修正する。CI の整理を目的に削除してはいけません。不安定さとは、単一の失敗ではなく、同じ SHA で結果が食い違うことです。

6. フラグが立ったテストすべてに同じ処置を適用する

重複、旧式、価値が低いテストには、それぞれ異なる対応が必要です（§5）。すべてを1つの「削除」区分にまとめると、実際のカバレッジが損なわれます。

7. 実行速度（または「先頭から N 件」）だけで優先度を決める

スモークテストはリスクと不具合検出の履歴に基づくものであり、最も速いテストや先頭から N 件を選ぶものではありません。実行時間は、優先度を決める軸ではなく、同順位の場合の判断材料です（§6）。

8. 大規模な一括削除 PR

隔離も承認も観察期間もなく、600件のテストを1つの PR で rm すること。必ず、隔離 → 承認 → 観察 → 小分けにして削除、の順に進めてください（§7）。

9. 「Git の履歴にあるから、削除してよい」

Git の履歴は復旧計画ではありません。誰も、削除したテストが検出したはずの不具合を監視してくれません。実際の安全策となるのは、隔離期間と、リリース後に発覚した不具合の監視です。

---

検証

誰かが何かを削除する前に、監査が実際に成立していることを証明してください。まずは最小限の確認から始めます。

• テストごとのコンテキストが取得されています。 .coverage のコンテキスト名を調べ、パラメーター ID を保持したまま、|setup、|run、または |teardown で終わる pytest テスト ID を確認します。集約した ID を収集済みテストと比較し、欠落しているケースを調査してください。アプリケーションコードを測定していないテストには、コンテキストがない場合があります。フェーズは別々なので、生のコンテキスト数はテスト数ではありません。
• カバレッジの一致だけを根拠に削除していません。 redundant の各行について、監査ログの mutation_check 列に値（yes + 実行 ID）が記入されています。grep -c 'redundant' docs/test-curation-log.md の結果は、mutation_check が空欄でない行数と一致します。
• 最初に行うのは削除ではなく隔離です。 git log --diff-filter=D --name-only -- tests/ | grep test_ を実行しても、隔離 PR で削除されたテストファイルが表示されません。対象のテストはスキップまたは xfail にするか、tests/quarantine/ の下に移動し、引き続き収集可能な状態にしてあります（pytest --collect-only -m skip または同等のコマンドで一覧表示できます）。
• ティアが正しく選択されます。 pytest -m smoke --collect-only はリスク検出／不具合検出用のテスト群だけを返し、スモークの予算内で実行されます。pytest -m "smoke or core or extended" --collect-only はすべてのテストを網羅します（タグのないテストはありません）。
• 監査記録が完全です。 redundant の行に superseded_by、coverage_delta、mutation_check の空欄はありません。純損失ゼロを主張する削除では、すべての coverage_delta が 0 lines / 0 branches です。

---

完了条件

• --cov-context=test／--cov-branch、または Istanbul の同等機能を使って、テストスイートのテストごとのカバレッジフィンガープリントを作成し、テストごとに一意にカバーされる行を算出している。
• すべての「冗長」候補に、残すテストが同じミュータントを検出できることを証明するミューテーションテストの結果が添付されている。カバレッジの一致だけを根拠に削除を提案していない。
• AST とカバレッジプロファイルの類似性から、明示したしきい値に基づいて近似重複クラスターを生成し、人によるレビューに回している。クラスターを自動削除していない。
• CI 履歴を調査し、一度も失敗していないテスト（処置：調査）と同じ SHA で不安定なテスト（処置：隔離／修正）を特定している。いずれのカテゴリも、これらのシグナルだけを根拠に削除していない。
• 対象となった各テストには、{redundant, obsolete, low-value, keep} のうちちょうど 1 つを割り当て、対応する処置を適用している。
• リスクと不具合検出履歴を入力として、マーカー／タグでティア（smoke/core/extended）を割り当てている。pytest -m smoke（または同等のコマンド）でティアを選択できます。
• 隔離期間を経て、承認者の氏名／CODEOWNERS の承認記録が残され、観察期間中に流出した不具合がなかった場合を除き、テストを削除していない。
• コミット済みのテストごとの監査記録があり、削除ごとにカテゴリ、置き換え先、カバレッジ差分、承認者 + SHA + 日付、復元方法を記載した行がある。

---

関連スキル

• ai-qa-review — 個々のテストが 適切に書かれているか（問題の兆候、弱いアサーション、テスト可能性）を評価します。このスキルはテストを そもそも存在させるべきか を判断し、ai-qa-review は既存のテストが適切かを判断します。整理後、残すテストに ai-qa-review を実行してください。
• coverage-analysis — プロジェクトレベルのカバレッジしきい値、ギャップ分析、ミューテーションテストの設定を管理します。このスキルは冗長性の判断にテストごとのカバレッジを使用します。ラチェットや CI のゲートについては、こちらを参照してください。
• test-reliability — 不安定な 単一の テストが失敗した際に、実行時の自己修復と隔離を行います。このスキルは CI 履歴全体から不安定なテスト群を 特定し、test-reliability はそのうち 1 つずつ 修正します。
• risk-based-testing — このスキルの「keep」の処置とティア分けの基盤となるリスクマトリックスを作成します。リスクマップがない場合は、まずこちらを実行してください。
• qa-project-context — 共通の依存関係です。ここでのあらゆる判断を左右するスタック、ランナー、リスクマップ、所有権を扱います。

参考ファイル（references/ 内）

• coverage-fingerprinting.md — .coverage の SQLite コンテキストクエリ、テストごとの行／ブランチセットの構築、固有カバレッジと包含関係の計算、および JS/Istanbul におけるテストごとの同等処理。
• mutation-confirmation.md — 疑わしい行に対象を絞った mutmut/cosmic-ray/StrykerJS の設定、および包含関係を確認するためのキルセット比較。
• clustering.md — AST の正規化、Jaccard／コサイン／ツリー編集による類似度、および閾値を調整できる凝集型クラスタリング。
• ci-history-mining.md — JUnit-XML の集計、同一 SHA のフレーク検出クエリ、Datadog/Trunk API からのデータ取得。
• tiering.md — smoke/core/extended 用のマーカー／タグ方式、および欠陥検出履歴クエリ。
• destructive-safety.md — 隔離マーカー、テストパス用の CODEOWNERS、および見逃された欠陥の監視チェックリスト。
• audit-record.md — 削除ログの全列スキーマと、記入例の行。