Test Design Audit（ELD統合版テスト設計監査）

ELDとの関係

本スキルはELD（Evidence-Loop Development）のGroundフェーズにおける テスト設計を体系化する。

ELD Loop: Sense → Model → Predict → Change → Ground → Record
                                              ↑
                                    test-design-audit

Law/Term → テスト条件への導出を行い、Evidence Ladderでの接地を保証する。

核心原則

生成AIの限界を理解する：AIは「それらしい網羅」を"生成"するのは得意だが、「何が未生成か」を"証明"するのは苦手。

対策：列挙前に「モデル化」と「監査」を挿入し、抜けを"見える化"する。

ELD的強化：Law/Termを要求の源泉とし、Evidence Ladderでカバレッジを階層化する。

抜け漏れの定義

現実には状態空間・入力空間・環境差分が巨大で"全組み合わせを全件テスト"は成立しない。 実務的な「抜け漏れがない」の定義：

1. 要求カバレッジ: スコープ内の要求（機能/非機能/制約/既知リスク）に対してテスト条件が対応づいている
2. 未知の明示: 未知（不明点）と仮定が明示され、未確定領域がテスト外になっていない

ワークフロー概要

Phase 0: コンテキストパック収集 + pce-memory活性化
    ↓
Phase 1: 要求の棚卸し（REQ-xxx）+ Law/Term対応付け
    ↓
Phase 2: モデル化（5つのモデル + Law/Term視点）
    ↓
Phase 3: カバレッジ基準策定 + Evidence Ladder
    ↓
Phase 4: テスト条件ツリー（TCND-xxx）+ Law Grounding
    ↓
Phase 5: 監査（複数視点 + Law違反チェック）
    ↓
Phase 6: テスト項目生成（TEST-xxx）+ Grounding Map連携
    ↓
Phase 7: トレーサビリティ検証 + Law/Term紐付け
    ↓
Phase 8: 差分運用 + pce-memory記録

---

Phase 0: コンテキストパック収集 + pce-memory活性化

AIに渡す情報を固定する。情報が散らばるとモデルが不安定になり抜けが増える。

ELD統合: pce-memory活性化

pce_memory_activate({
  q: "テスト対象機能 Law Term 既知バグ",
  scope: ["project", "principle"],
  allow: ["*"]
})

過去の知識（Law/Term、バグパターン、設計決定）を活性化し、テスト設計に反映する。

必須収集項目

カテゴリ	収集内容
システム概要	何をするシステムか
対象範囲	スコープ内/スコープ外の明示
ユースケース	主要ユーザーフロー
依存	外部API、決済、認証、Push、DB、OS機能
データ制約	入力バリデーション、桁、形式
権限・ロール	ユーザー種別とアクセス制御
非機能	性能、セキュリティ、可用性、監査ログ、アクセシビリティ
運用	障害時対応、監視、リリース、バックアウト
既知障害	過去のインシデント、ヒヤリハット
受入基準	Doneの定義

警告: ここが薄いとAIは「一般論のテスト」になり、固有リスクを取り逃がす。

---

Phase 1: 要求の棚卸し + Law/Term対応付け

目的: 要求を「テスト可能な形」に変換し、Law/Termと対応付ける。

ELD統合: Law/Term対応付け

要求をELDのLaw/Termに対応付けることで、テストの根拠を明確化する。

対応パターン	説明
REQ → Law	要求が既存Lawの検証に対応
REQ → Term	要求がTermの境界検証に対応
REQ → 新Law候補	新しいLawの発見（/eld-model-law-discoveryへ）

出力フォーマット

| REQ ID | 種類 | 要求概要 | 受入条件（観測可能） | Law/Term |
|--------|------|---------|-------------------|----------|
| REQ-001 | 機能 | ログイン機能 | 正しい資格情報でセッション発行 | LAW-auth-valid-credential |
| REQ-002 | 非機能 | レスポンス2秒以内 | 95%タイルで2秒以下 | LAW-response-time-sla |
| REQ-003 | 制約 | パスワード8文字以上 | 7文字以下でエラー | TERM-password |

種類の分類

• 機能（Functional）→ 多くの場合Law（Invariant/Pre/Post）に対応
• 非機能（Non-functional）→ Policy Lawに対応
• 制約（Constraint）→ Termの境界条件に対応
• 運用（Operational）→ Policy Lawに対応
• 法令・規約（Regulatory）→ S0 Lawに対応
• UX（User Experience）→ 新Law候補として検討

必須セクション

要求一覧とは別に「不明点・矛盾・仮定」セクションを設ける。これがないと仮定が埋め込まれたまま進む。

Law/Termが未定義の場合は (NEW-LAW) または (NEW-TERM) ラベルを付け、 /eld-model-law-card または /eld-model-term-card で定義する。

---

Phase 2: モデル化 + Law/Term視点

核心: テストは列挙ではなく、モデルから導出する。Law/Termを軸に整理する。

詳細テンプレートは references/model-templates.md を参照。

ELD統合: モデルとLaw/Termの対応

モデル	Law/Termとの対応
機能分解	各機能の不変条件（Invariant）をLaw化
状態モデル	状態遷移制約をLaw化、状態をTermとして定義
データモデル	エンティティをTerm化、整合性制約をLaw化
外部IFモデル	API契約をPre/Post条件としてLaw化
リスクモデル	失敗モードを「Law違反パターン」として整理

2-1. 機能分解（Feature Tree）+ Invariant

機能 → サブ機能 → 操作/イベント → 期待結果 → [関連Law]

各機能に関連するLaw（不変条件）を紐付ける。

2-2. 状態モデル（State Machine）+ 状態遷移Law

主要状態と遷移イベントを明確化。

例：未ログイン → ログイン中 → トークン期限切れ → 退会済み

Law化: 状態遷移制約（「退会済み→ログイン中」は不可など）

2-3. データモデル + Term定義

エンティティ、属性、制約、整合性、更新規則。PIIや秘匿データの扱い。

Term化: 主要エンティティをTerm Cardとして定義（境界、観測写像）

2-4. 外部IFモデル + Pre/Post条件

API一覧、リクエスト/レスポンス、エラーコード、リトライ方針、タイムアウト、冪等性。

Law化: API契約をPre条件（入力制約）/Post条件（出力保証）として明示

2-5. リスクモデル + Law違反パターン

失敗モード → 影響 → 検出方法 → 予防/緩和 → テスト観点

ELD観点: 各失敗モードを「どのLawが破られるか」で分類

---

Phase 3: カバレッジ基準策定 + Evidence Ladder

「何を満たすと網羅と言えるか」を明示。これがないとAIは"それっぽい数"で止まる。

詳細は references/coverage-criteria.md を参照。

ELD統合: Evidence Ladder

ELDの「証拠の梯子」を基準に、テストの深さを階層化する。

Level	検証内容	対象	テスト種別
L0	静的整合	全Law/Term	型チェック、Lint
L1	単体での成立	S0-S2 Law	ユニットテスト、Property-based test
L2	連携での成立	S0-S1 Law	統合テスト、E2Eテスト
L3	異常時の維持	S0 Law	失敗注入、Fuzz testing
L4	実運用での成立	S0-S1 Law	本番Telemetry、監視

重要: L0だけで完了扱いしない。S0 LawはL2以上必須。

Law Severity別の必須レベル

Severity	必須レベル	推奨レベル
S0（致命的）	L0 + L1 + L2 + L3	L4
S1（重要）	L0 + L1 + L2	L3 + L4
S2（中程度）	L0 + L1	L2
S3（低）	L0	L1

基本基準

基準	定義	Evidence Ladder
要求カバレッジ	全REQに対して少なくとも1つのTCND	-
Law接地カバレッジ	全Lawが必須レベルを達成	L0-L4
状態遷移カバレッジ	主要遷移（正常/異常）をすべて通す	L1-L2
入力空間カバレッジ	同値分割＋境界値（Termの境界）	L1
エラー網羅	外部IFの代表的失敗（timeout/5xx/4xx/不正payload）	L2-L3
品質特性カバレッジ	性能・セキュリティ・可用性・監査ログ・アクセシビリティ	L2-L4
環境カバレッジ	OS/端末/ネットワーク/言語/権限（必要な範囲）	L2

---

Phase 4: テスト条件ツリー作成 + Law Grounding

テスト項目を直接書かせず、まずテスト条件の木を作らせる。 Law/Termの接地（Grounding）を意識した構造にする。

ELD統合: Law Grounding視点

テスト条件をLaw/Termの接地レベル（Evidence Ladder）で分類する。

Feature A [LAW-xxx]
├── L1: ユニットテスト条件
│   ├── TCND-001: 基本フロー成功 [L1]
│   └── TCND-002: 境界値検証 [L1]
├── L2: 統合テスト条件
│   ├── TCND-003: 外部IF連携成功 [L2]
│   └── TCND-004: 状態遷移正常 [L2]
├── L3: 失敗注入テスト条件
│   ├── TCND-005: timeout時の回復 [L3]
│   └── TCND-006: 5xx応答時のフォールバック [L3]
└── L4: 運用観測条件
    └── TCND-007: Telemetry記録確認 [L4]

構造（ELD統合版）

Feature A [LAW-feature-a-invariant]
├── 正常系
│   ├── TCND-001: 基本フロー成功 [L1] [LAW-xxx]
│   └── TCND-002: オプション付きフロー [L2] [LAW-xxx]
├── 入力バリデーション [TERM-input-xxx]
│   ├── TCND-003: 必須項目欠落 [L1]
│   └── TCND-004: 形式不正（境界値） [L1]
├── 状態依存 [LAW-state-transition]
│   ├── TCND-005: 状態S1からの操作 [L2]
│   └── TCND-006: 状態S2からの操作 [L2]
├── 外部IF失敗 [LAW-external-if-contract]
│   ├── TCND-007: timeout [L3]
│   └── TCND-008: 5xx応答 [L3]
├── セキュリティ [LAW-security-xxx]
│   ├── TCND-009: 権限不足 [L2]
│   └── TCND-010: 不正操作 [L3]
├── 性能/負荷 [LAW-performance-sla]
│   └── TCND-011: 同時接続100件 [L2-L4]
└── 監査ログ [LAW-audit-trail]
    └── TCND-012: 操作記録確認 [L4]

必須ルール

• 各葉に TCND-xxx のIDを付与
• どのREQに対応するか（REQ-xxx）を必ず紐づける
• どのLaw/Termを検証するかを紐づける
• Evidence Ladderのレベル（L1-L4）を明示
• 不明点がある葉は (UNKNOWN) ラベルをつけて残す（消さない）

---

Phase 5: 監査 + Law違反チェック

核心: 生成AIを「批判側」に回す。役割を変えると見つかる抜けが増える。 ELD的追加: Law/Termの接地状況を監査する。

監査役プロンプト

あなたはテスト監査人（生成した本人ではない体）。
以下のテスト条件ツリーを監査し、抜け漏れの可能性を列挙せよ。
特に以下の観点で監査：
1. 全てのLaw/Termに対してテスト条件が存在するか
2. Law Severityに応じたEvidence Ladderレベルを満たしているか
3. Law違反時の動作がテストされているか

監査観点

詳細チェックリストは references/audit-checklist.md を参照。

必須観点:

• 要求カバレッジ欠落（REQに紐づかない/未対応REQ）
• Law/Term接地カバレッジ欠落（Law/Termに紐づかない/未接地）
• Evidence Ladder未達成（S0 LawがL2未満など）
• 状態遷移の未カバー
• エラー処理、復旧、冪等性、再試行、タイムアウト
• Law違反時の動作テスト欠落
• 競合（同時操作、二重送信）、順序逆転、遅延
• 権限/認可、ログ、監査、個人情報
• 互換性/環境差分
• テストデータ（境界値、相関制約）
• "未知/仮定"が放置されてテスト不能になっていないか

ELD統合: Law接地監査

/eld-ground-check を使用してLaw/Termの接地状況を検証:

/eld-ground-check LAW-xxx

結果:
✅ L0: 型チェック通過
✅ L1: Unit Test (3/3)
❌ L2: Integration Test なし
❌ L3: 失敗注入テストなし
⚠️ L4: Telemetry設定済み（未検証）

推奨アクション:
- L2: 統合テスト TCND-xxx を追加
- L3: timeout/5xx時の動作テストを追加

複数視点での監査（必須）

監査は最低2回、異なる視点で行う：

1. 1回目: QA視点（一般的な抜け漏れ）
2. 2回目: Law接地視点（ELD固有）
3. 3回目（推奨）: 以下から選択
   • 運用担当視点
   • セキュリティ担当視点
   • 性能担当視点
   • アクセシビリティ担当視点

---

Phase 6: テスト項目生成 + Grounding Map連携

ツリーの「葉」から生成する。葉IDがあるので抜けが追える。 ELD的追加: Grounding Mapと連携してLaw/Termの接地を保証する。

出力フォーマット（ELD統合版）

| TEST ID | TCND | REQ | Law/Term | Level | 前提条件 | 入力 | 期待結果 |
|---------|------|-----|----------|-------|---------|-----|---------|
| TEST-001 | TCND-001 | REQ-001 | LAW-auth | L1 | 未ログイン状態 | 有効なID/PW | セッション発行 |
| TEST-002 | TCND-003 | REQ-003 | TERM-password | L1 | - | 7文字PW | エラー表示 |
| TEST-003 | TCND-007 | REQ-004 | LAW-external-if | L3 | 外部API停止中 | 任意 | フォールバック動作 |

ELD統合: Grounding Map更新

テスト項目をGrounding Mapに反映:

# grounding-map.yaml
laws:
  LAW-auth-valid-credential:
    severity: S0
    verification:
      unit:
        - TEST-001  # ← test-design-auditから追加
        - TEST-002
      integration:
        - TEST-010
      runtime:
        - AuthService.validateCredential
    observation:
      telemetry:
        - auth.success_rate
      alert:
        - auth_failure_spike

ルール

• 各TESTは必ず1つ以上のTCNDに紐づく
• 各TESTは必ず1つ以上のLaw/Termに紐づく
• Evidence Ladderのレベルを明示
• 期待結果は観測可能な形（UI表示/状態/ログ/APIレスポンス）
• (UNKNOWN) はテストを捏造せず、質問・前提の形で残す

---

Phase 7: トレーサビリティ検証 + Law/Term紐付け

対応表の作成（ELD統合版）

| REQ ID | Law/Term | TCND | TEST | Level | ステータス |
|--------|----------|------|------|-------|----------|
| REQ-001 | LAW-auth | TCND-001, TCND-002 | TEST-001, TEST-002 | L1, L2 | カバー済 |
| REQ-002 | LAW-perf | - | - | - | **未対応** |
| REQ-003 | TERM-password | TCND-003 | TEST-003 | L1 | カバー済 |

ELD統合: Law/Term接地状況表

| Law/Term | Severity | 必須Level | 現在Level | TCND | ステータス |
|----------|----------|-----------|-----------|------|----------|
| LAW-auth | S0 | L0-L3 | L0-L2 | TCND-001,002 | **L3未達** |
| LAW-perf | S1 | L0-L2 | L0 | - | **未接地** |
| TERM-password | S1 | L0-L1 | L1 | TCND-003 | ✅ 達成 |

抜け検出

• 未対応 = REQに紐づくTCND/TESTがない → 抜け確定
• 未接地 = Law/Termに紐づくTCND/TESTがない → ELD的抜け確定
• Level未達 = 必須Evidence Ladderレベルに未到達 → 追加テスト必要
• TESTのみ存在 = REQ/Law紐づきなし → 探索テストか不要かを判断

---

Phase 8: 差分運用 + pce-memory記録

仕様変更時に再発しないための運用。 ELD的追加: 設計決定とパターンをpce-memoryに記録する。

手順

1. 仕様差分（REQの追加/変更/削除）を特定
2. Law/Term差分（新規Law/変更されたLaw）を特定
3. 影響範囲（どのFeature/State/Data/IF/Lawに波及するか）を分析
4. 影響のあるTCND/TESTだけを更新
5. 対応表を更新して「未対応REQゼロ」「未接地Law/Termゼロ」を維持
6. pce-memoryに記録

ELD統合: pce-memory記録

テスト設計で発見した知識をpce-memoryに記録:

pce_memory_upsert({
  text: "認証機能のテスト設計完了。LAW-auth-valid-credentialに対してL1-L2のテストを設計。L3（失敗注入）は次スプリントで対応予定。",
  kind: "fact",
  scope: "project",
  boundary_class: "internal",
  provenance: {
    at: "2024-01-15T10:00:00Z",
    actor: "test-design-audit"
  }
})

記録すべき内容

種類	内容	scope
テスト設計決定	カバレッジ基準の選択理由	project
未対応項目	意図的に除外した項目とその理由	project
発見したパターン	再利用可能なテスト条件パターン	principle
新Law/Term	テスト設計中に発見した暗黙の法則	project

---

最小セット（時間がない場合）

• (T1) 要求一覧（REQ-xxx）を作成し、不明点を明示、Law/Term対応付け
• (T2) 主要な観点（正常系・異常系・境界・セキュリティ）でテスト条件を作成、Evidence Ladder明示
• (T3) 監査を1回実施（Law接地視点を含める）
• (T4) トレーサビリティ表で未対応REQと未接地Law/Termを確認

---

出力物

• requirements.md: 要求一覧（REQ-xxx）+ 不明点・仮定 + Law/Term対応
• models/: 5つのモデル（Feature tree、状態、データ、外部IF、リスク）+ Law/Term視点
• coverage-criteria.md: このプロジェクトのカバレッジ基準 + Evidence Ladder
• test-conditions.md: テスト条件ツリー（TCND-xxx）+ Law Grounding
• audit-report.md: 監査結果（抜け候補と対応）+ Law接地監査
• test-cases.md: テスト項目一覧（TEST-xxx）+ Grounding Map連携
• traceability.md: 要求↔テスト対応表 + Law/Term接地状況表
• grounding-map.yaml: Law/Term → Test/Telemetry対応表（ELD共通）

---

ELD関連スキル

スキル	用途
/eld	ELD統合開発手法のメイン
/eld-model-law-discovery	新しいLawの発見
/eld-model-law-card	Law Cardの作成
/eld-model-term-card	Term Cardの作成
/eld-ground-check	Law/Termの接地状況検証
/eld-ground-evaluate	成果物評価

---

参照

• references/model-templates.md: モデル化テンプレート
• references/coverage-criteria.md: カバレッジ基準詳細
• references/audit-checklist.md: 監査チェックリスト
• references/eld-integration.md: ELD統合ガイド