概要
- AIエージェントによる自動コード生成 の信頼性課題
- TDDや受け入れ基準 の重要性とAI時代の適用方法
- コードレビューやテストの限界 とAIによる自己検証の問題点
- Playwrightなどの自動検証ツール を活用したワークフロー提案
- Claude Skill「verify」導入例 と実践的な運用方法
AIエージェントによるコード自動生成の信頼性課題
- GastownやClaude Code などのツールを使い、夜間に自動でコード生成とブランチ作成を実施
- 生成されたコードの正当性や要件適合性 を人間が確認できない問題
- コードレビューの負担増大 と、AIコードレビューの限界
- AI同士でコードとテストを作ると、 同じ誤解や抜け を見逃しやすい
- 「自己承認マシン」 状態になり、根本的なミスを見逃すリスク
テスト駆動開発（TDD）の本質とAI時代の適用
- TDDの本質 は「先にテスト（受け入れ基準）を書き、後でコードを書く」こと
- AIの登場で「テストを書く時間がない」言い訳が無効化
- AIが高速にコード生成、 人間は「正しい動作」を先に定義 するだけで良い
- テスト＝正しさの定義 を事前に明文化する重要性
受け入れ基準（Acceptance Criteria）による自動検証ワークフロー
- フロントエンド開発例
- 仕様ファイルから 受け入れ基準（AC） を自動生成
- 例: 「ログイン成功時は /dashboard へリダイレクト」「エラーメッセージの表示」「バリデーション」「レート制限」など
- 各ACは 合格/不合格が明確 になるよう記述
- Playwright による自動ブラウザ操作でACごとに検証・スクリーンショット・判定レポート生成
- 仕様ファイルから 受け入れ基準（AC） を自動生成
- バックエンド開発例
- APIのステータスコードやレスポンス をcurl等で検証
- この仕組みの限界
- 仕様（spec）が間違っていれば誤った検証も合格
- ただし、 従来のコードレビューよりも統合バグや表示ミスを確実に検出
Claude Skill「verify」による自動受け入れテスト構築
- github.com/opslane/verify の導入
- 4段階ワークフロー
- Pre-flight（事前チェック） ：bashでサーバ・認証・specファイル存在を確認
- Planner（計画） ：Opusモデルがspecと変更ファイルを読み、検証方法を決定
- Browser agents（ACごとにPlaywright+Sonnet） ：各ACを並列で検証・スクリーンショット
- Judge（判定） ：Opusが証拠をまとめて合否・理由を判定
- 導入方法
- Claude Codeプラグインとしてインストール可能
- 各ステージは claude -p コマンド1回で完結、モデルやステージのカスタマイズ容易
- CI統合も可能
まとめ：AI時代の「正しさ」の担保方法
- 「何をもって完了とするか」 を事前に明確化することの重要性
- 受け入れ基準の作成は手間だが、抜け・誤解を減らす唯一の方法
- 基準なきAIコード生成は「出力を読んで祈るだけ」になり、本質的な信頼は得られない