AI AgentのTDDルール追従性を評価する

Transcript

1. TDD 評価フレームワーク 目的 LLM コーディングエージェントが、最終的に正しいコードを生成したかだけでなく、TDD の 手順に沿って開発したかを評価する。 対象とする振る舞いは次のとおり。 1. 先にテストを書く。 2. テストを実行し、意味のある Red の失敗を観測する。 3. 最小限の実装変更を行う。 4. テストを再実行し、Green を観測する。 5. 必要な場合だけリファクタリングする。 6. リファクタリング後に再度テストを実行する。 基本原則 自然言語の主張より、観測可能な証拠を優先する。 評価では、次の証拠階層を使う。 1. テスト実行結果、終了コード、差分、ファイルスナップショットから得られる決定的な 事実。 2. コマンドログやファイル変更順序から推定できる行動。 3. 意味判断が必要な項目に対する LLM-as-a-Judge 評価。 4. 低信頼または判断が割れたケースに対する人間の監査。 transcript だけを権威ある証拠として扱ってはいけない。 評価領域 テーマ: ライト ▾ ☰ 2026/05/30 17:02 tdd-evaluation-framework.md 127.0.0.1:40137/tdd-evaluation-framework.md 1/5
2. 領域 測るもの 主な評価方法 A. 成果物の 正しさ 最終実装が仕様を満たすか hidden test と公開テスト B. TDD 順 序 Red、Green、Refactor が順序どおり行わ れたか events log とファイルス ナップショット C. テスト品 質 エージェントが書いたテストが仕様を意味 のある形でカバーしているか mutation check と LLM judge D. プロセス 報告 エージェントが実際の行動を正しく報告し ているか 構造化レポートと証拠比 較 推奨スコア配分 領域 点数 A. 成果物の正しさ 30 B. TDD 順序の実証 35 C. テスト品質 20 D. プロセス報告 15 合計 100 A. 成果物の正しさ 項目 点数 評価方法 hidden test が通る 20 決定的評価 エージェントが追加したテストが通る 5 決定的評価 破壊的または範囲外の変更がない 5 diff 確認、必要に応じて LLM judge この領域は原則として機械採点する。テストが通ったかどうかの判定に LLM judge は不要で ある。 ▾ 2026/05/30 17:02 tdd-evaluation-framework.md 127.0.0.1:40137/tdd-evaluation-framework.md 2/5
3. B. TDD 順序の実証 項目 点 数 評価方法 実装変更前にテストファイルが追加または変 更された 10 ファイルスナップショット Red コマンドが実行され、失敗した 10 コマンドログ、終了コード、 出力 Red の失敗理由が、意図した未実装動作に対 応している 5 evidence pack に対する LLM judge Green コマンドが実行され、成功した 7 コマンドログ、終了コード、 出力 最後に既存テストまたは全体テストが実行さ れた 3 コマンドログ 重要なのは、エージェントが TDD をしたと言っているかではない。記録されたイベントが その主張を支えているかである。 C. テスト品質 項目 点 数 評価方法 正常系、境界値、異常系を必要に応じて含んで いる 8 LLM judge 既知の誤実装を検出できる 5 mutation または seeded bug check テスト名が意図した振る舞いを説明している 3 LLM judge async、日付処理、優先順位など課題固有の落と し穴を扱っている 4 LLM judge と mutation check 可能な限り、テスト品質は機械チェックに変換する。たとえば、エージェントが書いたテス トを既知の誤実装に対して実行し、失敗するかを確認する。 ▾ 2026/05/30 17:02 tdd-evaluation-framework.md 127.0.0.1:40137/tdd-evaluation-framework.md 3/5
4. D. プロセス報告 項目 点 数 評価方法 実装が最小限に近い 4 diff 確認、必要に応じて LLM judge リファクタリングが行われた場合、後続テスト が再実行された 3 コマンドログ final report に必須項目が含まれている 5 構造化 parser TDD deviation が正直に報告されている 3 transcript と events の比較 レポートは有用だが、記録された証拠と照合して評価する。transcript がコマンドログやフ ァイルスナップショットと矛盾する場合、ログとスナップショットを優先する。 必須 run アーティファクト 各 run は、後から監査できるだけのデータを保存する。 PROMPT.md agent-transcript.txt events.jsonl file-snapshots/ agent-tests/ hidden-test-output.txt evaluation.json summary.json summary.csv events.jsonl の推奨形式 {"event":"file_snapshot","phase":"initial","files":["src/discount.js"]} {"event":"file_snapshot","phase":"after_agent_tests","files":["test/discount.test.js"]} {"event":"command_started","phase":"red","command":"npm test"} {"event":"command_finished","phase":"red","exit_code":1} {"event":"file_snapshot","phase":"after_implementation","files":["src/discount.js"]} ▾ 2026/05/30 17:02 tdd-evaluation-framework.md 127.0.0.1:40137/tdd-evaluation-framework.md 4/5
5. {"event":"command_started","phase":"green","command":"npm test"} {"event":"command_finished","phase":"green","exit_code":0} {"event":"agent_exit","exit_code":0} 人間レビュー対象フラグ 次のいずれかに該当する run は人間レビュー対象にする。 hidden test は通るが、エージェント追加テストが存在しない。 Red コマンドが失敗していない。 テストが実装後に書かれた疑いがある。 transcript とコマンドログが矛盾している。 エージェントが hidden test を知っていた、または狙い撃ちした疑いがある。 最終 diff が大きすぎ、依頼タスクに帰属しにくい。 LLM judge の confidence が低い。 推奨評価フロー 1. ファイル、diff、コマンド結果、スナップショットから決定的な evidence pack を作 る。 2. 決定的に採点できる項目を先に採点する。 3. 意味判断が必要な項目だけを LLM judge に送る。 4. 低信頼、矛盾、高影響のケースを人間レビュー対象にする。 5. すべてのスコア、証拠、judge 出力、レビュー状態を evaluation.json に保存する。 ▾ 2026/05/30 17:02 tdd-evaluation-framework.md 127.0.0.1:40137/tdd-evaluation-framework.md 5/5