フェーズ6: 検証

目的

実装されたコードが期待通りに動作することを、証拠に基づいて証明する。テストの実行結果を確認し、カバレッジを測定し、品質基準を満たしていることを宣言する前に検証を完了する。

Before / After

Before: 従来のやり方

• 「たぶん動く」という主観的な判断で完了宣言
• テストを実行しても結果を確認しない
• 一部のテストが失敗しているのに「OK」と報告
• 手動でブラウザを開いて目視確認

After: ツール活用後

• テスト実行結果のコマンド出力を直接確認してから完了宣言
• カバレッジ80%以上を数値で確認
• E2Eテストを Playwright で自動実行
• 品質ゲートを通過しないと先に進めない

レベル別アプローチ

Beginner

Claude Code の Bash ツールでテストを実行・確認。

# テスト実行
Claude Code > npm run test を実行して結果を報告して

# 型チェック
Claude Code > npx tsc --noEmit を実行して

# Lint
Claude Code > npm run lint を実行して

# ビルド確認
Claude Code > npm run build を実行してエラーがないか確認

手順:

1. Bash でテストスイートを実行
2. 結果の失敗数・成功数を確認
3. Bash で型チェック・Lint・ビルドを実行
4. 全て通過したことを確認してから完了

Intermediate

Superpowers の verification-before-completion と OMC の ultraqa を活用。

# Superpowers: verification-before-completion
# IDENTIFY → RUN → READ → VERIFY → THEN claim
# 「完了」を宣言する前に必ず検証コマンドを実行して結果を確認
# 24の失敗事例から学習されたゲート機能

# OMC: ultraqa（QA サイクル）
/oh-my-claudecode:ultraqa
# test → verify → fix → repeat の自動ループ
# 全テストが通るまで自動的に修正を繰り返す

# OMC: verifier エージェント
> 実装が完了したか検証して
# 完了の証拠を収集し、タスクが完全に終わっているか確認

# OMC: qa-tester エージェント
> E2Eテストを実行して
# ランタイムと手動のバリデーション

手順:

1. Superpowers verification-before-completion のゲートフローを実行
2. テストを実行し、出力を直接読んで結果を確認
3. OMC ultraqa で test → verify → fix の自動ループ
4. OMC verifier エージェントで完了証拠を収集
5. カバレッジ80%以上を確認

Advanced

OMC のチーム検証と ECC の包括的な品質ゲートを活用。

# OMC: team パイプラインの team-verify フェーズ
/team 3:executor "機能実装"
# team-plan → team-prd → team-exec → team-verify → team-fix
# チーム全体で検証と修正をループ

# ECC: quality-gate（品質ゲート）
/quality-gate
# リポジトリ全体または特定パスの品質チェック

# ECC: verify（検証ループ）
/verify
# build → test → lint → typecheck → security の連続検証

# ECC: verification-loop スキル
# 継続的検証: ビルド、テスト、Lint、型チェック、セキュリティ

# ECC: test-coverage（テストカバレッジ分析）
/test-coverage

# ECC: eval（評価基準での評価）
/eval

# OMC: visual-verdict（UI の視覚的検証）
/oh-my-claudecode:visual-verdict

手順:

1. ECC verification-loop でビルド→テスト→Lint→型チェック→セキュリティを連続実行
2. ECC quality-gate で品質ゲートを通過
3. OMC team-verify でチーム全体の検証
4. ECC test-coverage でカバレッジ80%以上を確認
5. OMC visual-verdict で UI の視覚的検証（該当時）

利用可能なコマンド・スキル

Claude Code 単体 {data-tool="claude-code"}

ツール	説明
Bash	テスト・ビルド・Lint の実行
NotebookRead	Jupyter Notebook の出力確認
LSP 診断	リアルタイムのエラー・警告検出

Superpowers {data-tool="superpowers"}

スキル	説明
verification-before-completion	IDENTIFY → RUN → READ → VERIFY → THEN claim ゲート
test-driven-development	RED-GREEN-REFACTOR サイクル
systematic-debugging	テスト失敗時の根本原因調査

OMC {data-tool="omc"}

スキル / エージェント	説明
/ultraqa	test → verify → fix → repeat の自動 QA ループ
verifier エージェント	完了証拠の収集と検証
qa-tester エージェント	ランタイムと手動のバリデーション
test-engineer エージェント	テスト戦略とリグレッションカバレッジ設計
/visual-verdict	UI変更の視覚的 QA
/team	team-verify → team-fix のループ

ECC {data-tool="ecc"}

スキル / コマンド	説明
/verify	検証ループの実行
/quality-gate	品質ゲートチェック
/test-coverage	テストカバレッジ分析
/eval	評価基準での評価
/e2e	Playwright E2E テスト生成
verification-loop スキル	継続的検証の自動化
eval-harness スキル	検証ループの評価と採点
e2e-testing スキル	Playwright E2E パターン
tdd-workflow スキル	TDD 手法（RED/GREEN/IMPROVE）

ベストプラクティス

1. 出力を直接確認する -- Superpowers verification-before-completion の核心。テストを実行しただけでなく、出力を読んで結果を確認してから完了宣言する
2. 検証は自動ループで -- OMC ultraqa や ECC verification-loop で、テスト失敗 → 修正 → 再実行を自動化する。手動での修正→再実行は非効率
3. カバレッジは数値で確認 -- 「十分なテスト」ではなく「80%以上」のように数値目標を設定し、ECC test-coverage で測定する
4. 段階的に検証 -- 単体テスト → 統合テスト → E2Eテストの順で実行。下位レベルで失敗しているのに上位テストに進まない
5. 視覚的検証も忘れずに -- UI変更がある場合は、OMC visual-verdict や ECC e2e で視覚的な検証を行う

よくある罠

「テストを実行しました」で終わり

テストを実行したことと、テストが通ったことは別。Superpowers は24の失敗事例から、「実行した」と「通った」を混同するパターンを学習している。

部分的な完了宣言

10個のテストのうち8個が通ったから「完了」と宣言するのは不正確。全テストが通るまで完了とは言えない。OMC ralph は「暗黙の部分完了を許さない」。

失敗テストの無視

test.skip や // @ts-ignore で失敗を隠すのは最悪のアプローチ。失敗しているテストは根本原因を調査し、修正する。

カバレッジの数字だけを見る

80%のカバレッジでも、重要なエッジケースがテストされていれば不十分。数値だけでなく、どのパスがテストされているかを確認する。

E2Eテストの省略

「手動で確認したから大丈夫」は不十分。Playwright で再現可能なE2Eテストを作成し、リグレッションを防ぐ。