aep-gen-eval

ジェネレーター／評価者パターン

エージェントが生成した成果物を公正に評価するための、再利用可能な設計パターンです。成果物を作成するエージェント（ジェネレーター）と、それを評価するエージェント（評価者）を分離します。エージェントは一貫して、自分の成果物を高く評価するためです。

「自らが制作した成果物の評価を求められると、エージェントは、その品質が人間の目には明らかに平凡であっても、自信たっぷりに称賛する傾向があります。」 — Anthropic、「長期間にわたるアプリケーション開発のためのハーネス設計」

このスキルには2つの用途があります。他のスキルが、このスキルの references/ ファイルを読み取り、採点、契約、プロトコル、復旧、所見の標準的な参照先として利用できます。また、/aep-gen-eval を直接呼び出すと、任意の成果物に対して完全な生成／評価ループを実行できます。

---

他のスキルでの利用方法

スキル	利用する内容	参照ファイル
/aep-build フェーズ5	採点フレームワーク＋評価プロトコル	scoring-framework.md、eval-protocol.md、recovery-ladder.md
/aep-launch	ブレインストーミング用の次元プリセット	scoring-framework.md（プリセットのセクション）
/aep-validate	エージェントプロンプト＋所見の形式	agent-contracts.md、findings-format.md、scoring-framework.md
/aep-build、/aep-dispatch、/aep-wrap、/aep-autopilot	失敗の分類体系、検証の段階／レシピ、会計	verification-economics.md

---

中核となる原則

ジェネレーターと評価者は別々のエージェントにします。 自己評価では、スコアが水増しされ、問題が正当化されます（上で引用した所見のとおり）。独立した評価者なら、ジェネレーターが見落としている点を見つけられます。

規模を拡大する場合： ジェネレーター／評価者は、_敵対的検証_の標準的な実例です。1つのタスクから個別に独立した確認を要する所見や主張が多数生じる場合、/aep-workflow はこの方式を拡張し、N 個の検証者／反証者へ分岐させます。各所見に対して、このスキルの採点フレームワークと所見の形式を再利用します。

---

参照ファイル

これらのファイルは、すべての利用者（/aep-build、/aep-validate、/aep-launch）が参照する、gen/eval の契約の正式な格納先です。ブランチで必要なファイルを読み込んでください。各ファイルは単独で完結しています。

ファイル	内容	読むタイミング
references/scoring-framework.md	評価次元の定義（1～5 段階）、重大な失敗のしきい値、評価次元のプリセット（UI、API、セキュリティ、データ、混合）、few-shot の例、アンチパターン	評価基準の設定、スコアリング作業、評価者の調整
references/agent-contracts.md	生成者と評価者の役割分担、プロンプトテンプレート（生成者、評価者、プロトコルチェッカー）、コンテキストの組み立てルール	評価エージェントの起動、プロンプトの組み立て
references/eval-protocol.md	Eval のリクエスト／レスポンス形式、検証用 JSON スキーマ、Eval ループ（リクエスト → レスポンス → 修正 → 再評価）、実行コンテキスト（Task サブエージェント、codex exec、tmux、ワークフロー）、needs-human ゲート記録	評価ループの実行、検証状態の追跡
references/recovery-ladder.md	2 ラウンドの復旧手順（同じ修正 → 再度根拠に基づいて検討 → 新しい生成者の起動／分解を提案する human gate）。ラウンド 1 後も blocking の指摘が残る場合に適用	ラウンド 1 後も blocking の指摘が未解決の場合
references/findings-format.md	重大度の分類（blocking／important／minor）、重複排除プロトコル、提示形式、変更履歴エントリの形式	複数のエージェントからの指摘の統合、結果の提示
references/verification-economics.md	バリデーター配置マトリクス、失敗の分類体系と分類権限、環境の事前確認、検証レベルとその 2 点に基づく導出、検証レシピ、計上センサー、改ざん検知可能な証拠クラス	FAIL の振り分け、検証の深さの導出、検証コストの算出／記録

---

単独での使用

直接呼び出すと、このスキルはあらゆる成果物に対して gen/eval ループを実行します。

ステップ 1：成果物を特定する

何を評価しますか？以下から選択してください。

• ドキュメント（製品コンテキスト、アーキテクチャ、設計ドキュメント）
• コードの変更（実装、PR の差分）
• OpenSpec の変更（提案、設計、仕様、タスク）
• 構造化ファイル（YAML、JSON 設定、移行計画）

ステップ 2：実行モードを選択する

モード	エージェント	使用するタイミング
Parallel	Generator と Evaluator を同時に起動	ドキュメント、デザイン、製品のコンテキスト — エージェントが独立して作業します
Sequential	Generator を先に起動し、その後 Evaluator が Generator の成果物を読む	コードレビュー — Evaluator が実装を確認する必要があります
Loop	Generator → Evaluator → 修正 → 再評価（最大 2 ラウンド）	開発中 — Generator がラウンド間に問題を修正できます

ステップ 3：評価軸を設定する

references/scoring-framework.md を読み、成果物に適したプリセット（UI 中心、API 専用、セキュリティ重視、データパイプライン、混合／フルスタック、製品／デザイン、またはドキュメント）を選択するか、カスタム評価軸を定義します。プリセットの表、重大な失敗のしきい値、少数例によるキャリブレーションは、すべてこのファイルに記載されています。

ステップ 4：エージェントを起動する

プロンプトのテンプレートについては、references/agent-contracts.md を読みます。次の内容を使ってテンプレートをカスタマイズします。

• 成果物の内容
• 技術的な制約
• 検証チェックリスト（Evaluator がコードベースに照らして確認すべき項目）

ステップ 5：結果を処理する

検出事項を統合、分類して提示するには、references/findings-format.md を読みます。その後、確認可能な次の 2 つの最終状態のいずれかに到達します。

• 修正を適用して再評価： Generator が修正を適用し、ブロッキングとなる検出事項が残っていない状態で、新たな評価ラウンドに成果物を通します。上限は 2 ラウンドです。ラウンド 2 の後も blocking の検出事項が未解決の場合は、references/recovery-ladder.md に従ってエスカレーションします。
• 検出事項を引き継ぐ： 統合した検出事項を名前付きのパス（例：<artifact-dir>/eval-findings.md）にファイルとして書き出し、後続の担当者が対応できるようにします。

---

設計上の決定

Gen/eval は、/aep-validate や /aep-launch に組み込むのではなく、リファレンスライブラリを兼ねる独立した呼び出し可能なスキルとしてパッケージ化されています。理由については、docs/decisions/gen-eval-rationale.md を参照してください。

---

次のステップ

Gen/eval の実行後は、評価した内容に応じて次の手順に進みます。

• 製品のコンテキスト → /aep-dispatch
• デザイン成果物 → /aep-launch
• コード → PR を作成するか、/aep-build を続行する
• ドキュメント → 公開または共有する