Eval Harness Skill
AI 開発における「ユニットテスト」としてエバリュエーション（評価）を扱う、エバリュエーション駆動開発（EDD）を実装するためのフレームワーク。
哲学
EDD では、評価を以下のように定義します：
- •実装の前に期待される動作を定義する。
- •開発中に継続的に評価を実行する。
- •変更のたびにデグレ（機能退行）を追跡する。
- •信頼性の測定に pass@k メトリクスを使用する。
評価タイプ
機能評価 (Capability Evals)
Claude が以前はできなかったことができるようになったかをテストします。
markdown
[機能評価: フィーチャー名] タスク: Claude が達成すべき内容の説明 成功基準: - [ ] 基準 1 - [ ] 基準 2 - [ ] 基準 3 期待される出力: 期待される結果の説明
回帰評価 (Regression Evals)
変更によって既存の機能が壊れていないかを確認します。
markdown
[回帰評価: フィーチャー名] ベースライン: SHA またはチェックポイント名 テスト: - 既存テスト-1: 合格/不合格 - 既存テスト-2: 合格/不合格 - 既存テスト-3: 合格/不合格 結果: X/Y 合格 (以前は Y/Y)
グレーダー（採点）タイプ
1. コードベース・グレーダー
コードを使用した決定論的なチェック。
bash
# ファイルに期待されるパターンが含まれているか確認 grep -q "export function handleAuth" src/auth.ts && echo "PASS" || echo "FAIL" # テストが通るか確認 npm test -- --testPathPattern="auth" && echo "PASS" || echo "FAIL" # ビルドが成功するか確認 npm run build && echo "PASS" || echo "FAIL"
2. モデルベース・グレーダー
Claude を使用して、自由形式の出力を評価します。
markdown
[モデルグレーダー・プロンプト] 以下のコード変更を評価してください： 1. 提示された問題を解決しているか？ 2. 適切に構造化されているか？ 3. エッジケースは考慮されているか？ 4. エラーハンドリングは適切か？ スコア: 1-5 (1=悪い, 5=優れている) 理由: [説明]
3. ヒューマン・グレーダー
手動レビューが必要なものにフラグを立てます。
markdown
[手動レビューが必要] 変更点: 何が変わったかの説明 理由: なぜ人間のレビューが必要なのか リスクレベル: 低/中/高
メトリクス
pass@k
「k 回の試行のうち、少なくとも 1 回成功する確率」
- •pass@1: 初回の試行での成功率
- •pass@3: 3 回以内の試行での成功率
- •一般的な目標: pass@3 > 90%
pass^k
「k 回の試行すべてが成功する確率」
- •信頼性に対するより高い基準
- •pass^3: 3 回連続で成功すること
- •クリティカルパス（重要な処理）に使用
評価ワークフロー
1. 定義 (コーディング前)
markdown
## 評価定義: フィーチャー-xyz ### 機能評価 1. 新規ユーザーアカウントを作成できる 2. メール形式をバリデーションできる 3. パスワードを安全にハッシュ化できる ### 回帰評価 1. 既存のログインが引き続き機能する 2. セッション管理に変更がない 3. ログアウトフローが正常である ### 成功メトリクス - 機能評価において pass@3 > 90% - 回帰評価において pass^3 = 100%
2. 実装
定義された評価に合格するようにコードを書きます。
3. 評価の実行
bash
# 機能評価を実行し、合否を記録 # 回帰評価を実行 npm test -- --testPathPattern="existing" # レポートを生成
4. レポート
markdown
評価レポート: フィーチャー-xyz ======================== 機能評価: ユーザー作成: 合格 (pass@1) メール検証: 合格 (pass@2) パスワードハッシュ: 合格 (pass@1) 全体: 3/3 合格 回帰評価: ログインフロー: 合格 セッション管理: 合格 ログアウトフロー: 合格 全体: 3/3 合格 メトリクス: pass@1: 67% (2/3) pass@3: 100% (3/3) ステータス: レビュー準備完了
統合パターン
実装前
code
/eval define フィーチャー名
.claude/evals/フィーチャー名.md に評価定義ファイルを作成します。
実装中
code
/eval check フィーチャー名
現在の評価を実行し、ステータスを報告します。
実装後
code
/eval report フィーチャー名
完全な評価レポートを生成します。
評価の保存
プロジェクト内に保存します：
code
.claude/
evals/
feature-xyz.md # 評価定義
feature-xyz.log # 評価実行履歴
baseline.json # 回帰用のベースライン
ベストプラクティス
- •コーディング前に評価を定義する - 成功基準について明確に考えることを強制します。
- •頻繁に評価を実行する - デグレを早期に発見します。
- •pass@k を継続的に追跡する - 信頼性の推移を監視します。
- •可能な限りコードグレーダーを使用する - 確率的な評価よりも決定論的な評価を優先します。
- •セキュリティには人間によるレビューを - セキュリティチェックを完全に自動化してはいけません。
- •評価を高速に保つ - 遅い評価は実行されなくなります。
- •評価をコードと一緒にバージョン管理する - 評価は第一級の成果物です。
例：認証機能の追加
markdown
## 評価: 認証機能の追加 ### フェーズ 1: 定義 (10分) 機能評価: - [ ] ユーザーがメール/パスワードで登録できる - [ ] ユーザーが有効な資格情報でログインできる - [ ] 無効な資格情報が適切なエラーで拒否される - [ ] ページのリロード後もセッションが維持される - [ ] ログアウトでセッションが破棄される 回帰評価: - [ ] 公開ルートが引き続きアクセス可能である - [ ] API レスポンスに変更がない - [ ] データベーススキーマに互換性がある ### フェーズ 2: 実装 [コードを書く] ### フェーズ 3: 評価実行 実行: /eval check 認証機能の追加 ### フェーズ 4: レポート 評価レポート: 認証機能の追加 ============================== 機能: 5/5 合格 (pass@3: 100%) 回帰: 3/3 合格 (pass^3: 100%) ステータス: リリース可能