AI生成テストの検出力検証

実装コードとテストを同じ AI が同じ文脈で生成すると、実装に埋め込まれた仕様の誤認を、テストがそのまま正解として検査します。テストは全件通過し、通過したという事実が確認を省く理由になります。以下ではこの状態を共連れと呼びます。

要求事項そのものは第5章 5.8.4に規定済みです。本ページは、その充足を機械で確認する実装を示します。

エージェントを分けることでは解決しません

共連れへの対処として、実装を書くエージェントと検証を書くエージェントを分ける構成が提案されます。エージェントを分けたことだけを根拠に、独立を確保したとみなしてはなりません。同一のモデルを用いる限り、事前学習の知識という共通の原因が残るためです。

本標準は、「独立」を人と組織の単位でだけ使います。エージェント・順序・入力を分けて得られるのは分離です(第3章 3.5.4)。第5章 5.8.4 は、実装と検証の切り離しを分離の段階(弱・中・強)で定め、最も強い段階だけを組織的な独立として定めます。

分離は、エージェントを分けることではなく、順序と入力によって成立します。

何を分けるか	分離への寄与
エージェント・セッション	補助。文脈の混入を防ぐにとどまる(文脈の分離)
生成の順序(テストを先に生成する)	本体。実装を読んでからテストを書く経路を断つ
テスト生成への入力(実装コードを渡さない)	本体。追認の材料を与えない(入力の分離)
受入基準の定義者(人間が事前に定める)	本体。仕様の側を機械から切り離す

どこまでを求めるかは、変更のリスク区分で決まります。段階の定義と適用の正本は第5章 5.8.4 です。

リスク区分	分離の段階	エージェント・セッション	順序と入力	受入基準の定義者
R3	弱	分ける	求めない	求めない
R2	中	分ける	テストを先に生成し、実装を渡さない	求めない
R1	強	分ける	同上	人間が事前に定め、テストの十分性を判定する
安全関連ソフトウェア	最強(組織的な独立)	分ける	同上	同上。加えて、検証の担当者を実装の責任者から組織的に独立させる

本ページの機械検査は、最初の表の3つの本体を前提に置きます。前提を欠いた状態で検出力だけを測っても、測っているのは追認の精度です。

何を機械で確認するか

2つの手続を置きます。目的が異なるため、片方で他方を代替できません。

手続	確認すること	捕捉できる欠陥
変異試験	テストが実装の変更に反応するか	中身のないアサーション、到達するだけのテスト
受入基準とテストの突合	合意した基準に対応するテストが存在するか	検査されていない受入基準

この検査が共連れそのものを解決しない理由

変異試験は、テストが実装から乖離した変更を検出できるかを測る手続です。実装が仕様と乖離していることは測れません。実装が誤っており、テストがその誤りを正確に検査している場合、変異試験のスコアは高く出ます。

したがって、共連れの本体である仕様の誤認に対する防壁は、機械検査ではなく次の2つです。

人間が事前に定義した受入基準(第6章テンプレ1)
受入基準と実装挙動の一致を確認する独立レビュー(G-6 判定基準1)

変異スコアの高さを、仕様適合の根拠として提示してはなりません。この誤用を放置すると、共連れの検知を目的に導入した仕組みが、共連れを追認する記録になります。

変異試験の適用

全件を対象にしません

変異試験は、テストスイートを変異体の数だけ繰り返し実行します。実行時間は対象の規模に対して線形以上に増え、PR ごとの機械判定(G-5)へ無条件に載せると開発の往復時間を損ないます。

適用範囲を次のとおり限定します。

リスク区分	適用	実行の契機
R1(第3章 3.8.1。事後の取り消しを前提にできない変更)	必須	当該範囲を変更した PR
R2	定期実行	週次。PR の合否条件にしない
R3	任意	適用しない場合も記録を要しない
安全関連ソフトウェア	附属書F F.6による	同附属書の規定が優先する

R1 においても、対象は当該 PR が変更した範囲へ限定します。リポジトリ全体を対象にすると、実行時間が判定期限を超えます。

閾値を外部の固定値から取りません

変異スコアの合格水準は、言語・テスト基盤・対象の性質によって現実的な到達点が変わります。外部で見かける値を初期値として持ち込まないでください。

較正の手順は次のとおりです。

#	手続
1	対象範囲で変異試験を実行し、合否条件を設けずに3か月分のスコアを記録する
2	記録した分布の下位四分位を初期の合格水準として置く
3	生存した変異の類型を棚卸しし、テストの観点へ反映する
4	反映後の分布で水準を更新する。引き下げは記録を要する

手続2と4を自動化しません。実績の分布が水準へ直結すると、水準を上げないための調整が生じます。較正に共通する歯止めはフェーズ6(運用メトリクス)によります。

スコアを目的化させない措置

変異スコアを合否条件に置くと、生存した変異を殺すためだけのアサーションが増えます。実装の出力をそのまま期待値に書き写す記述は、スコアを上げますが検出力を上げません。

次の2点を併せて運用します。

合否は変異スコアの絶対値ではなく、生存した変異の類型で判定する。境界条件・異常系・状態遷移に関する生存を差し戻しの対象とする
生存した変異の一覧を差し戻しの根拠として記録に残す。スコアだけを記録した回は、判定の根拠を再現できない

期待値を実装の出力から自動生成する記述は、変異試験の前提を壊します。テストの記述規約でこれを禁じます。

受入基準とテストの突合

対応関係を機械が読める形で持つ

受入基準ごとに識別子を与え、テストの側から参照します。参照の様式は言語ごとの慣習によりますが、機械的に抽出できる位置に置くことを要求します。

describe('AC-012 在庫が不足する場合は注文を受け付けない', () => {
  // ...
});

CI では次を検査します。

#	検査	失敗時の扱い
1	仕様書の受入基準のうち、対応するテストが存在しないものが 0 件	G-5 を通過させない
2	テストが参照する識別子のうち、仕様書に存在しないものが 0 件	同上
3	対応が存在する受入基準について、当該テストが実行され通過している	同上

検査1と2を分ける理由は、片方だけでは識別子の消滅を検出できないためです。仕様側の項目を削除しただけの変更は、検査2でのみ落ちます。

突合を AI に行わせません

受入基準とテストの対応判定を、AI の読解に委ねてはなりません。対応の有無は識別子の一致という観測可能な事実で判定します。

理由は第4章 AI 品質指標の扱いと同じ構造です。判定に推定を含めると、偽陰性が「対応済み」という記録として残り、記録の意味が失われます。

AI に担わせてよいのは、識別子を欠いたテストの候補を提示する支援までです。提示は差し戻しの理由になりません。

CI への組み込み

# .github/workflows/gate-g5.yml(抜粋)
  mutation:
    if: contains(github.event.pull_request.labels.*.name, 'risk-r1')
    runs-on: ubuntu-latest
    timeout-minutes: 30
    steps:
      - uses: actions/checkout@v4
      - name: 変更範囲に限定した変異試験
        run: npx stryker run --mutate "$(git diff --name-only origin/main...HEAD | grep '\.js$' | tr '\n' ',')"
      - name: 生存した変異の一覧を保存
        uses: actions/upload-artifact@v4
        with:
          name: mutation-${{ github.event.pull_request.number }}
          path: reports/mutation/
  traceability:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: 受入基準とテストの突合
        run: node scripts/check-traceability.mjs --spec "specs/**/*.md" --tests "tests/**/*.spec.js"

実行時間の上限を明示的に置く。上限を超えた場合は対象範囲の限定が不足している
リスク区分の付与は第4章による。ラベルの自己申告に依存させる場合、付与漏れは R1 として扱う

生存した変異の一覧は、出荷判定(G-7)のエビデンス集約へ渡します(CI/CD ゲート構成)。

検査の結果を反映する経路

測定した結果を、テストの観点と自動検査へ戻す経路を持たない運用は工数の純増です。第5章 5.6.2の欠陥注入と同じ規律を適用します。

観測	反映先
特定の類型の変異が繰り返し生存する	テストの記述規約、およびテスト生成時の指示資産(第3章 3.11.3)
受入基準に対応するテストの欠落が繰り返す	仕様書テンプレートの様式検査
実装の誤りが独立レビューで見つかった	受入基準の記述粒度。変異試験の設定を変えても捕捉できない

3行目が重要です。共連れによる欠陥を検知したときの是正先は、テストの自動化ではなく仕様の側です。