spec-driven-eval

仕様駆動実装の評価

PRD に照らして、仕様駆動開発（SDD）の取り組みをケースごと（受け入れ基準ごと）に評価し、実装とテストを個別に採点したうえで、比較可能な最終評価にまとめます。ベンチマーク向けに設計されており、異なる SDD フレームワークで同じ PRD を評価した場合も、同じ取り組みを 2 回評価した場合も、比較可能で再現性のある数値を算出できます。

2 つの対象、2 つの問い

この評価では、互いに独立した 2 つの問いに答えます。それぞれ別個に不合格となるため、判定も分けて扱います。

1. フレームワークは要件をどれだけ適切に尊重し、抽出できているか？ — PRD を順守し、範囲内にとどまっていたか（尊重: Final の実装側 + スコープ S）、そして PRD で明示されず、暗に示された要件をノイズなく表面化できたか（抽出: 抽出 E）？
2. ハーネスは要件がすべて実装されることをどれだけ確実にできているか？ — テストスイートは、認められたすべての要件が実際に実装されていることを証明できるか（T + エンジニアリングゲート G）？

「すべて実装済み」の定義を明確にする関連付け: ハーネスは、認められた要件の完全な集合 = PRD acceptance criteria ∪ valid E-additions に対して責任を負います。フレームワークが抽出した有効な要件をハーネスがテストしていない場合、それはフレームワークの不備ではなく、ハーネスの不備（T）です（抽出の評価点は E に残ります）。抽出によって検証対象が定まります。

採点はチェックリスト方式です。各基準を、file:line 形式の証拠に裏付けられた、原子的な二値（達成／未達）チェックに分解します。評価を再現可能にするために二値分解を採用しています。段階評価／リッカート尺度（「これは 3 か、4 か？」）は評価者間の不一致の主な原因ですが、二値チェックによって評価者間の一致度をおおむね人間の水準まで高められます。部分点は達成したチェックの割合から算出し、段階的な尺度で判断することはありません。

使用する場面

• 「この PRD をケースごとに評価／採点して、最終評価を出してください」
• 「このストーリー／機能は 100% 実装されていますか？」
• 同じ PRD に対する複数の仕様駆動型実装のベンチマーク
• 受け入れ基準に照らした実装およびテストカバレッジ（ユニット + E2E）の監査

必要な入力

1. PRD（プロダクトの意図を示す正本）— ユーザーストーリーの受け入れ基準を評価単位とします。
2. 実装（本番コード）。
3. テスト（ユニット + E2E）。
4. SDD から派生した成果物 — spec.md と tasks.md（洗練された AC、要件 ID、派生要件）。抽出 E 軸とスコープ S 軸に必要です（これらの軸では、PRD に照らしてこれらの成果物を評価します）。存在しない場合でも Final／T は実施しますが、E／S は n/a — 派生仕様なし と報告します。「期待される」内容の判断基準は引き続きPRDであり、派生仕様は尊重と抽出の評価対象です。

差分の範囲を特定する。 採点の前に、git を使って、この実装で変更されたファイルを特定します。この差分の範囲は、ステップ 4 および 8 で file:line 形式の証拠を探す主な対象範囲です。

git diff <base>..<head> --name-only   # branch or PR
git diff --name-only HEAD             # uncommitted changes
git status --short                    # include untracked new files

差分の範囲をレポートに記録します。その範囲外の証拠も有効ですが（例：既存ファイルが変更されていた場合）、チェックが差分に含まれないファイルに依拠するときは、その旨を記載してください。これは、ベースの選択が間違っている可能性を示します。

---

クイックスタート

この評価を最初から最後まで実施するのが初めてですか？ 貼り付けて使えるプロンプト付きの 4 チャットセッションの流れ（ベースラインの固定 → 計画 → 実装 → 評価）については、quickstart.md を参照してください。実際の進め方が必要なときはそちらを読み、このファイルの残りの部分では採点方法を説明します。

---

コアのルール（最初にお読みください）

以下の5つのルールは、すべての採点に適用されます。採点結果を監査可能かつ再現可能にするためのものです。

1. 証拠がなければゼロ。 MET とするチェックにはすべて、file:line（または file:startLine-endLine）形式で証拠を記載する必要があります。証拠が見つからない場合、そのチェックは UNMET です。推測や、意図を繰り返した PRD の記述を根拠に加点してはいけません。
2. ゼロ判定の前に検索する（偽陰性を防止）。 「見つからない」ことを理由にチェックを UNMET とする前に、スコープ設定の手順で特定した差分対象ファイルから検索を始め、実際に実行した検索を記録してください。その後、試した grep/glob の検索語と、追加で調べたファイル／ディレクトリも記録します。UNMET と採点するチェックでは、場当たり的にリポジトリ全体を grep しただけでなく、差分対象における振る舞いの欠如を確認する必要があります。UNMET は「検索した結果、実際に存在しなかった」という意味であり、「調べなかった」という意味ではありません。検索内容が示されていない場合、そのチェックは UNMET ではなく、まだ採点されていません。
3. データ形状も含め、経路を最初から最後まで読む。 シンボル名が一致するだけでは不十分で、実際のコード／テスト経路を追跡した場合にのみ、チェックを MET とします。出力／返却／永続化されるアーティファクトについては、呼び出し箇所だけでなく、構築されたペイロードオブジェクトそのものを調べてください。emit(...)／return ... が存在しても、ペイロードに指定されたフィールドが含まれている証明にはなりません（「論理積ルール」を参照）。振る舞いを実行するテストでも、それをアサートしない場合、検証チェックを満たしません。
4. ベンチマークでは、評価者と作成者を分ける。 実装を比較する採点では、評価を行うモデルはコードを作成したモデルとは別のものにしてください。LLM の評価者は、自身の出力を過大評価する傾向があります（自己選好バイアス）。同じモデルの場合は、前提条件にその旨を記載し、判断が微妙なチェックは UNMET としてください。
5. 評価者は評価対象を読み取り専用にする。 不合格のゲートを修正するためであっても、「手助け」のためであっても、些細な型エラーであっても、評価対象のコードを決して変更してはいけません。不合格のゲートは不合格のままとし、✗ を記録して Adjusted Final を適用し、必要な修正をレポートの修正リストに記載してください。評価中に対象を変更するとベンチマークが汚染され（採点結果がフレームワークの出力を測定しなくなり）、差分対象も無効になります。誤って修正を適用した場合は、それを元に戻し、元の状態を採点してください。

再現性のルール

評価は安定していなければなりません。同じ PRD と同じコミットであれば、実行や評価者が異なっても同じ Final になる必要があります。以下をすべて守ってください。

1. AC リストとチェックリストを固定します（最も大きな評価ブレの原因です）。 AC の列挙とチェックの粒度は、一度だけ決定して固定します。どちらも I、T、Story_score の分母に影響するためです。
   • 安定した要件 ID を持つ spec.md が存在する場合、AC リストと ID は固定済みです。記載どおりに使用し、再分割や統合はしないでください。
   • 各 AC の二値チェックリストを一度だけ作成し、<spec-folder>/evaluations/_ac-baseline.md に保存します（ID ＋ AC の原文 ＋ I チェックと T チェック）。その PRD のすべての実装を、同一のチェックリストで評価します。
   • 1 つの AC は、テスト可能な意図の表明 1 つです。1 つのチェックは、観測可能な原子的な yes/no の命題 1 つです。異なる動作を 1 つのチェックにまとめたり、1 つの動作を複数のチェックに分割したりしないでください。
2. 優先度は PRD に基づき、暗黙に推定しないでください。 PRD に明記された P0/P1/P2 ラベルを使用します。ストーリーにラベルがない場合は、レポートでその優先度を ASSUMED として示し、Assumptions に記載してください。推定した優先度によって 3/2/0 の重みが暗黙に変わることがあってはなりません。
3. 丸めるのは最後に一度だけです。 計算では完全な精度を保ち、レポートに示す AC_score、Story_score、Final のみを小数点以下 2 桁に丸めてください。評価バンドの割り当てには、丸め後の Final を使用します。
4. 計算はスクリプトで行い、手計算しないでください。 ロールアップ（Σw、各 Story_score、Final、Adjusted Final）は、AC ごとの I/T の分数と優先度の重みテーブルを入力として受け取るスクリプト（例：node -e / python3 -c）を実行して計算する必要があります。スクリプトの出力をレポートに貼り付けてください。暗算や手計算は絶対にしないでください。分母（Σw）を手で合計するのは、評価バンドが気づかないうちにずれる既知の失敗パターンです。Σw はレポートに示した同じ優先度テーブルから、スクリプト内で導出する必要があります。リテラルとして直接入力してはいけません。
5. 整合性のセルフチェック（k = 3）。 チェックリストを低温度または温度 0 で、独立して 3 回評価します。数値を計算する前に、各チェックについて MET/UNMET の多数決を取ってください。k=3 の多数決により、低コストで確率的な判定の揺らぎを大半取り除けます。3 回の評価でチェックの判定が異なる場合、そのチェックは境界的です。多数決の判定を採用して、その旨を記録してください。不一致が続く場合は、チェックの文言が曖昧です（Calibration を参照してベースラインで明確化してください）。

---

スコアリングモデル

スコアリング単位：二値チェックに分解した受け入れ基準（AC）

対象範囲内の各 AC について、固定済みチェックリストには、原子的なチェックが 2 種類含まれます。それぞれ MET（1）/UNMET（0） として採点します。

実装チェック（I チェック） — AC が主張する、観測可能な動作ごとに 1 つ設定します。実際のコードがその動作を実行している場合にのみチェックを MET とし、根拠となる file:line を示します。動作として観測可能な節（AC に記載された動詞：creates / returns / rejects / persists / grants / defaults-to）のみを含めます。非機能的な仕上げ（文言、ログ記録）はチェックに含めません。スコアに影響しないよう、別途記録してください。

AC をチェックに分解する際（ベースラインを固定するときに一度だけ実施）、動詞だけでは把握できない要素も捉えるため、以下の両方のルールを適用します。 接続詞 / ペイロードフィールドのルール。 AC が複数の項目を列挙する場合 — "and"、","、"with [field]"、"including" で結合されている — 特に、出力/返却/永続化される成果物の主語またはペイロードにおいて — 名前が挙げられた各フィールドまたはエンティティを、それぞれ独立した I チェックとして扱います。親メソッドが呼び出されていることの確認で止めてはいけません。名前が挙げられた各フィールドについて、file:line で構築される実際のデータオブジェクトを開き、そのフィールドがそこに存在することを検証します（呼び出し地点ではなく、ペイロードの形状に対してスコアリングします）。 例：「ユーザー および トライアル終了日に関連付けられたトリガーを出力する」→ 2 つの I チェック：(1) トリガーのペイロードが userId を持つ、(2) トリガーのペイロードが trialEndsAt を持つ。ペイロードオブジェクトがそのフィールドを省略している場合、emit(...) に到達していることを確認してもチェック (2) を満たすことには なりません。

選言 / プロダクト選択のルール。 AC が選択肢を提示する場合（「A または B」、「一時停止またはキャンセル」、「即時または期間終了時」）、解釈を 一度だけ決定し、ベースラインに固定します（解釈自体は実行ごとに変わってはなりません）：

• 独立したパス — 両方が別々に到達可能な振る舞いである場合（例：「即時 または 期間終了時にキャンセル」）：パスごとに 1 つの I チェック、それぞれ独立して MET/UNMET。
• プロダクト制御 / 設定可能 — AC が選択をプロダクト主導として位置づける場合（例：「プロダクトが選択する振る舞いを適用する：一時停止またはキャンセル」）：2 つの I チェック — (1) 推奨/デフォルトの振る舞いが実装されている、および (2) 代替の振る舞いが コード変更なしで 到達可能である（設定キー / フラグ / 環境変数）。もう一方への切り替え手段なしに一方のオプションをハードコードしている ⇒ チェック (2) は UNMET。たまたまもう一方のオプションに到達する別の機能（例：ユーザー起点のキャンセル）は (2) を満たしません — それは 同じ プロダクト制御の決定点でなければなりません。
• 「プロダクトが選択する」 自体が 実行時設定可能 と 設計時に選択 の間で曖昧な場合は、PRD/仕様の文言に照らして解決し、解決した解釈をベースラインに記録します。AC が選択を実行時/プロダクト制御として位置づける場合にのみ、非デフォルトパスの到達可能性を要求します。

配線 / イングレスのルール（非同期で配信される副作用）。 観測可能な副作用がインバウンドイベントを通じて非同期に配信される場合（例：Stripe webhook → ハンドラー → 永続化されたステータス）、振る舞いの I チェックに 加えて、専用の 配線 I チェック を追加します：エントリエンドポイントが実際に インバウンドイベントを受信し、検証し、タイプ別にハンドラーへディスパッチする こと。これは、ハンドラーが正しい状態を生成するという T-outcome テストとは別のものです：完全にテストされたハンドラーが、死んでいる、未登録の、または誤ってルーティングされたエンドポイントの背後に置かれていても、配線チェックには失敗します。これがなければ、正しいが到達不可能なハンドラーが満点を獲得してしまいます（T-outcome のエントリポイント中立性が開く盲点 — テストが HTTP をバイパスできるということは、他の何か がルートの存在を証明しなければならないということです）。配線 I チェックは、イベントタイプをハンドラーにマッピングするコントローラー/ルートに対してスコアリングし（シグネチャ/真正性の検証 + ディスパッチ）、ハンドラーの内部に対してスコアリングしません。観測可能な効果がインバウンドの非同期イベントを経由して到着するすべての AC に対して、配線 I チェックを固定します。

I = (# I-checks MET) / (# I-checks)

テストチェック（T チェック） — 要求されるレベルにおける検証チェック。要求されるレベルはポリシーによって固定され、AC ごとに判断されるものではありません：

• 純粋 / ビジネスロジック ⇒ unit 必須
• 観測可能な HTTP / コントラクト / 永続化の副作用 ⇒ e2e / integration 必須
• 両方を含む AC ⇒ 両方必須

T-outcome — 永続化 / 非同期の副作用（アウトカムベース、エントリポイント中立）。 AC が 結果として生じる状態 を主張する場合 — 「結果として〜になる / 永続化される / 表示されるステータス / 変更を反映する / ステータスを更新する」という表現 — 検証チェックは呼び出しではなく 実際に結果として生じた状態 に対して行います。これらのチェックに T-outcome というラベルを付けます（単純な同期レスポンスの T-e2e とは別です）。ポリシーは 4 つの部分からなります：

• 実際の結果を検証します。 MET とするには、実際のインフラに対して、実際に永続化された状態（実際の DB 行）または実際に返されたペイロードを検証する必要があります。結果の状態を検証せず、処理経路を実行するだけのテストは UNMET です（コアルール 3）。
• エントリーポイントは実装側の選択です（エントリーポイントに依存しません）。 任意のエントリーポイントから実際のコンポーネントを実行し、結果の状態を検証します。HTTP エンドポイントを使う方法と、実際の DB に対してハンドラー／キューコンシューマー／サービスメソッドを直接呼び出す方法があります。非同期（即時に ACK を返してから処理する）設計では、HTTP→キュー→ワーカーの全経路を通してテストする必要はありません。ハンドラーの完了を待ち、永続化された行を検証すれば十分であり、同等です。キュー／非同期アーキテクチャが HTTP 経由でエンドツーエンドに実行されていないことを理由に減点してはいけません。問うべきなのは、実際の結果の状態が検証されているかどうかであり、テストがどの入口を通ったかではありません。
• モックのみの除外（適用範囲を厳密に限定）。 モックされたリポジトリ／ステートマシンのメソッドが呼び出されたこと（expect(save).toHaveBeenCalled()／expect(transition).toHaveBeenCalledWith(...)）を検証しても、証明されるのは呼び出しであり、永続化された結果ではありません。そのため、「結果になる／永続化される／表示されるステータス」の確認では UNMET です（ただし、Robustness の R には含められる場合があります）。この除外が適用されるのは結果の確認だけです。適用範囲を広げすぎてはいけません。 命題が「外部 API を呼び出す」である確認（例：「即時キャンセルで StripeClient.cancel が呼び出される」「Stripe にサブスクリプションを作成する」）は、主張されている内容そのものが呼び出しであるため、スパイ／モックで正しく検証できます。この場合、モックのみでも問題ありません。除外は適用されません。
• 最低レベルの下限。 必要なレベルは下限であり、厳密に一致させるものではありません。 より高いレベルのテスト（単体テスト必須の命題を対象とする E2E／統合テスト）でも、実際の成果物に対して具体的な命題（例：名前が指定されたペイロードフィールド、デフォルト値）が実際に検証されていれば、その命題を満たします。単体テスト必須の確認が E2E／統合テスト内でしか検証されていないことだけを理由に、UNMET と判定してはいけません。

必要なレベルごとに、次のような二値の確認項目を定めます：このレベルで主要な動作が検証されている（実行されただけでは不十分で、検証されている場合のみ MET）、関連する否定ケース／エラーケースが検証されている、副次的な各条項が検証されている。モックされた外部システム（例：nock 経由の Stripe）では外部側の動作を証明できないため、観測可能なローカルの契約に基づいて確認項目を定め、その制約を記載します。

結合ルールは T チェックにも適用されます。名前が指定された各ペイロードフィールドには、それぞれ独立した検証項目が必要です。成果物が出力／返却されたことだけを検証し、フィールドの存在／値を検証していないテストは、そのフィールドの確認では UNMET です（emit が呼び出されたことの検証は、ペイロードに trialEndsAt が含まれることの検証とは異なります）。

T = (# T-checks MET across all required levels) / (# T-checks)

I と T はどちらも細分化された値になりますが、その基礎となる各要素は、証拠に裏付けられた二値の Yes／No です。これにより、結果を再現可能にできます。「軽微か、重大か」という判断はありません。各条項には独自の確認項目があるか、ないかのどちらかであり、その判断はベースラインで固定されています。

AC ごと、ストーリーごと、最終

AC_score    = 0.6 * I + 0.4 * T
Story_score = mean(AC_score over the story's ACs)      # ACs equally weighted by default
Final       = Σ(w_s * Story_score) / Σ(w_s)            # weighted by story priority

ストーリーの優先度の重み w_s：

優先度	重み	根拠
P0	3	MVP の中核
P1	2	MVP に近い機能／ローンチ
P2 / 対象外	0	評価対象外。ロードマップの準備状況として別途報告

実装／テストの比率 0.6／0.4 は、「まず動くソフトウェアを作り、テストで実証する」ことを反映しています。この重みと P0／P1／P2 の重みはベンチマーク全体を通じて固定してください。変更すると比較可能性が損なわれます。

評価グレード

最終スコア	評価
≥ 0.90	仕様を完全に満たす
0.75–0.89	優れている（軽微な不足あり）
0.60–0.74	部分的（重大な不足あり）
0.40–0.59	不十分
< 0.40	非常に不十分

バイアスへの対処

LLM の評価者には十分に記録されたバイアスがあります。以下を明示的に抑制してください。

• 冗長性／量のバイアス — コードやテストが増えても、I や T が上がることは決してありません。カウント対象となるのは、AC 条項に対応するチェックのみです。余分なテストは R／D（以下を参照）に加算し、評価には決して反映しません。
• 自己優遇バイアス — 基本ルール 4（評価者 ≠ 作成者）を参照してください。
• アンカリング — 直前に評価した実装ではなく、凍結されたベースラインと references/reference.md の較正用アンカーに照らして評価してください。

評価点に加えて報告する項目（Final には含めない — 比較可能性を維持）

• 堅牢性指標 R — PRD のケースを超える追加テストを、High=1.0／Med=0.5／Low=0.25 の重みで合計します。防御的な品質を示します。Final を引き上げることはありません。
• スコープ遵守度 S — pass／partial／fail。トレーサビリティ原則：構築されたすべての動作は、承認された情報源（PRD の受け入れ基準 → Final、または有効な E の追加）に追跡できることに従います。構築された動作ごとに、次の 3 つを確認します。
  • PRD の境界 — PRD の明示的な対象外リストにある機能を構築した場合 ⇒ fail。
  • 独自の構築 — PRD の AC にも有効な E の追加にも追跡できない（追跡不能／独自に作り出した）機能を構築した場合 ⇒ fail。
  • 計画との乖離 — spec.md／tasks.md で承認された動作をコードが構築していない（または未完成／不整合のままにしている）場合 ⇒ partial。 すべて適切に追跡できる場合 ⇒ pass。不合格／一部不合格となった動作を file:line とともに報告してください。フレームワークが仕様に反映した有効な要件を、対象外であるため正しく構築しなかった場合は、適切な判断であり、S の減点対象にはなりません。 E の下で「保留中の有効要件」として記録してください。
• エンジニアリングゲート G — build、lint、unit、e2e。各ゲートは、実際に実行した ✓／✗、または明示的な not-run（理由を記載。例：e2e のインフラが利用できない）でなければなりません。実行せずにゲートを合格と報告してはなりません。build ゲートは評価者の裁量を排除するため、機械的に固定します。ベンチマークごとにプロジェクトの標準ビルドコマンド（リポジトリで説明されているビルドスクリプト）を一度選び、ゲートをそのコマンドの終了コードが 0 であることと定義します。それ以外の要素は判定に影響しません。すべての実行で同じゲートを使えるよう、レポートに正確なコマンドを記録してください。変更箇所に触れていないコードで発生する既存の無関係なツールチェーン障害（例：変更していないマイグレーション経路で既知の型チェックエラーが発生する場合）は、評価対象外の注記として記録するものであり、✗ ではありません。build の判定には影響せず、Adjusted Final も発生させません。既知の注記としてレポートに記録しますが、build の判定は固定されたビルドコマンドの終了コードのみに従います。not-run の前に試行すること：実際の試行が記録された場合に限り、ゲートを not-run と報告できます。コマンドを実行するか、前提条件を確認するコマンド（例：e2e インフラ用の docker ps）を実行し、そのエラー出力を証拠として貼り付けてください。試行なしの理由は有効ではありません。その場合、ゲートは採点されていない状態のままです。これは、検索なしでは UNMET とできないことと同じです（基本ルール 2 をゲートに適用）。確認済みの不合格ゲート（✗）のみが Adjusted Final = Final × 0.5 を発生させます。 not-run のゲートは加点も減点もできず、既知の盲点として報告します。比較のため、未調整の Final も引き続き報告します。不合格ゲートを評価者が修正しては決してなりません（基本ルール 5）。✗ を記録して調整し、修正内容を列挙してください。
• テスト分布 D — すべての機能テストを 3 つの階層のいずれかに分類し、テストスイートに占める件数と割合を報告します。テスト作業がどこに投入されたかを示します。Final を引き上げることはありません。以下を参照してください。

ティア D 別のテスト分布（併記して報告）

追加されたすべての機能テスト（各 it／テストケース。it.each の各行は個別にカウント）を、必ずいずれか1つのティアに分類します。この分類では、テストチェックと堅牢性の各ステップで実施済みの作業を再利用するため、低コストで再現可能です。

ティア	定義	対応先
Necessary（主要なハッピーパス）	P0/MVP の AC の主要な成功パス、またはそのパスの動作に必要な依存関係を検証します。	P0 のメインフローで MET となった T チェック
Secondary（重要）	AC に対応しますが、P0 の主要パスではありません。P1 の AC、エッジケース／負のケース／エラーパス、副次的な条項、セキュリティ／認可、重複／冪等性／重複排除、ステータスをトリガーとするイベント発行などが該当します。	Necessary ではない、MET となった T チェック
Nice-to-have	どの AC にも対応しません。防御的／網羅的なカバレッジ（列挙型のマッピング、不明なステータス、リポジトリ／インフラの内部処理、ヘルパーメソッド）、または E2E で実証済みのパスと重複する単体テストのカバレッジが該当します。	Robustness R の追加分

目安： AC に対応するテストは Necessary と Secondary に分かれます。Robustness R のインベントリは Nice-to-have ティアに該当します。テストは必ずいずれか1つのティアに分類し、重複してカウントしないでください。

D は、機能テスト総数に対する ティア → 件数 → % の表と、テスト構成に関する1行の所見として報告します。健全なテストスイートでは、すべての P0 の主要パスが少なくとも1つの Necessary テストでカバーされます。Necessary が少なく Nice-to-have が多いテストスイートは、コアが実証されていないまま堅牢性だけを追求している兆候です。逆に、防御的なテストがない場合は脆弱です。D は記述的な指標であり、Final に影響しません。

---

要件抽出 E — フレームワークによる要件の抽出能力（併記して報告し、Final には組み込まない）

E では、SDD から生成された spec.md／tasks.md を PRD と照合します。上級エンジニアなら要求する暗黙の要件をフレームワークが明らかにできているか、またその抽出が適切で、幻覚や矛盾する追加がないかを評価します。これは SDD フレームワークの「単なる書き写しを超えた価値」です。評価対象はコードではなく、仕様アーティファクトです。R／S／D と同様に Final と併記して報告するため、忠実度の評価を比較可能な状態に保てます。

二値チェックリストによるサブ指標は3つです。

E_recall — 抽出すべき要件を見つけられたか？

以下の固定された暗黙要件カテゴリのルーブリックを実施します。各カテゴリについて、対応済み（spec.md:line を引用）、見落とし、または 該当なし（PRD／ドメインに照らして無関係）を記録します。このルーブリックは PRD に依存せず再利用できるため、PRD ごとにゴールドラベルを付けなくても再現可能な再現率を得られます。

E_recall = Addressed / (Addressed + Missed)        # N/A excluded

#	カテゴリ	次の条件に該当する機能では、要件が期待されます…
1	入力の検証と範囲	ユーザー入力／外部入力を受け付ける（範囲、形式、必須フィールド）
2	エラーの分類とメッセージ	呼び出し元が区別する必要のある形で失敗する可能性がある（型付きエラー、コード）
3	認証／認可	エンドポイントを公開する、またはユーザー所有データを扱う
4	冪等性と重複排除	再試行または再実行される可能性がある（決済、一度だけ作成するリソース）
5	並行処理と競合状態	共有状態に対する書き込みが交錯する、または確認後に実行する処理がある
6	データのライフサイクルと整合性	状態を永続化する（トランザクション、部分的な失敗時のロールバック、保持期間）
7	可観測性	本番環境で動作する（ログ、メトリクス、失敗の追跡可能性）
8	制限、ページネーション、レート	リストを返す、または高頻度で呼び出される可能性がある
9	外部依存関係の障害	サードパーティを呼び出す（タイムアウト、再試行、サーキットブレーカー、フォールバック）
10	状態遷移の整合性	ライフサイクル／ステータスマシンがある（不正な遷移を防ぐガード）

ルーブリックはドメインごとに拡張できますが、ベンチマークごとに固定し、すべてのフレームワークに同一のリストを適用してください。フレームワークを直接比較するベンチマークでは、プール再現率も報告してください。すべてのフレームワークで有効と認められた追加項目を1つの判定済みマスターリストに統合し、そのリストに対する各フレームワークの再現率を算出します。

E_precision — シグナルは適切ですか、それとも過剰に作り込まれていますか？

追加要件台帳を作成します。spec.md／tasks.md にある要件のうち、PRD の行にたどれないものをすべて列挙します。それぞれを二択で判定し、根拠を1行で示し、spec.md:line を記載します。

判定	意味
妥当・必須	PRD が示唆する実際の不足点です（例：「trialDays > 30 を拒否する」）
妥当・防御的	合理的な堅牢化です（可観測性、リトライ、型付きエラーなど）
無効	捏造された要件、PRD に反する要件、または明示的な対象外リストへのスコープクリープです

E_precision = (Valid-necessary + Valid-defensive) / total additions

妥当な追加要件を、ほかの箇所（ハーネスの分母と S のトレーサビリティ）で参照する valid E-additions セットにします。妥当な追加要件ごとに、実装済みまたは保留のいずれかを記します（妥当な要件の保留は適切な規律を示します。S を参照してください）。

E_justified — 追加要件には妥当な根拠がありますか？

E_justified = additions carrying an explicit rationale/traceability / total additions

個々にはもっともらしい追加要件でも、根拠がなければ問題の兆候です。E_recall／E_precision／E_justified の3つすべてを報告してください。優れたフレームワークでは、3つすべてが高くなります。つまり、暗黙の要件を見つけ、余計なものをほとんど追加せず、追加した内容に根拠を示せています。

---

キャリブレーション（PRDごとに一度実施し、ベンチマークを信頼する前に行います）

チェックリストは各 AC の意味に関する仮説です。評価者間で判断が一致するよう、キャリブレーションしてください。

1. 基準を確認します。 references/reference.md には、チェックリストの具体例が記載されています。明らかに達成・未達の例をそれぞれ少なくとも1つと、判定および理由を示した境界事例を1つ確認してください。採点する前に読み、達成／未達の境界を把握します。
2. 判定の一致度を確認します。 重要度の高いベンチマークでは、チェックリストを人手でラベル付けされた基準（または2つ目の判定モデル）と照合してレビューします。判定が20％を超える項目で一致しない場合、チェックリストの表現が曖昧すぎます。_ac-baseline.md の曖昧なチェック項目を明確にし、再実行してください。不一致を「平均化して解消」してはいけません。運用上の定義を修正してください。
3. 境界事例にこそ価値があります。 人間や判定者の意見が分かれるチェック項目を見つけたら、判定が確定した内容を references/reference.md の基準事例に追加してください。

---

プロセス

このチェックリストをコピーし、進捗を記録してください。

FRAMEWORK — respect & extract requirements
- [ ] 1. Locate PRD, spec.md/tasks.md. Run git diff to identify changed files (diff surface). Use the diff surface as the primary search scope for implementation and test evidence throughout steps 4 and 8
- [ ] 2. Enumerate stories + ACs; tag priority; mark out-of-scope items
- [ ] 3. Build/load the frozen binary checklist per AC (I-checks + T-checks) → _ac-baseline.md
- [ ] 4. Score I-checks MET/UNMET with file:line evidence (record searches before any UNMET)
- [ ] 5. Elicitation E: run the category rubric (E_recall) + added-requirement ledger (E_precision, E_justified) → freeze the `valid E-additions` set
- [ ] 6. Scope S: trace every built behavior (PRD-boundary / rogue-build / plan-drift)

HARNESS — ensure they are all implemented
- [ ] 7. Define the sanctioned set = PRD ACs ∪ valid E-additions; ensure each has a T-check
- [ ] 8. Score T-checks MET/UNMET with file:line evidence (unit + e2e per fixed level policy)
- [ ] 9. Inventory extra tests → Robustness Index R
- [ ] 10. Classify every feature test into tiers → Test Distribution D (counts + %)
- [ ] 11. Run/record Engineering Gates G (✓/✗/not-run)

ROLL-UP
- [ ] 12. Repeat the scoring steps three times (k=3); take majority verdict per check
- [ ] 13. Compute I, T, AC/Story/Final; apply bands; Adjusted Final only if a gate is ✗
- [ ] 14. Emit the report (see references/reference.md template): Final + E + S + R/G/D + ranked gaps + fixes

ステップのルール：

• ステップ 1 — 根拠を調査する前に、差分の範囲を特定します。評価対象に合ったベース（ブランチの先端、最後のコミット、または作業ツリー）を選びます。

git diff <base>..<head> --name-only   # for a branch/PR
git diff --name-only HEAD~1           # for the last commit
git diff --name-only HEAD             # for uncommitted changes
git status --short                    # for untracked new files

ファイル一覧をレポートに記録します。ステップ 4 と 8 では、この一覧を最初に調査するパスの集合として使用します。

• ステップ 2 — PRD の明示的な対象外／非目標セクション（PRD で使われている見出し名は問いません）に記載された対象外項目は、w=0 とします。存在しないことは欠陥ではありません。採点しないでください。
• ステップ 3 — 既存の _ac-baseline.md がある場合は再利用します。ない場合は作成し、この PRD の今後すべての実行における契約として扱います。チェック項目には、観察可能な振る舞いの条項のみを含めます。
• ステップ 5 — E で評価するのはコードではなく spec.md／tasks.md です。台帳に記載された有効な追加要件が、ステップ 6 と 7 で使用する valid E-additions の集合を定義します。有効な追加要件ごとに、実装済み／保留中のいずれかを記録します。
• ステップ 6 — トレーサビリティ：PRD の AC も有効な E 追加要件もない実装済みの振る舞いは、勝手な実装（fail）です。有効な追加要件が対象外として保留されていても、減点対象にはなりません。
• ステップ 7 — テストハーネスの分母は、**承認済みの集合（PRD の AC ∪ 有効な E 追加要件）**です。抽出された有効な要件にテストがない場合は、E の未達ではなく T の未達です。
• ステップ 8 — 二値のみ：MET（証拠あり）または UNMET（調査したが見つからない）。チェックごとの部分的な値は使いません。
• ステップ 9 — 追加テストはプラスの評価材料ですが、カバレッジ不足の代わりにはなりません。R が高くても T が低ければ、評価は低いままです。
• ステップ 10 — 各テストをちょうど 1 つの階層に分類します。件数の合計は、機能テストの総数と一致する必要があります。この機能で追加されていない既存テストは除外します（別途記録してください）。
• ステップ 11 — ゲートは、実際に実行した場合に限り ✓／✗ とします。それ以外は、試行時の証拠（コマンド＋エラー出力。「Probe-before-not-run」を参照）を添えて not-run とします。インフラが利用できないと思い込まず、確認してください（例：docker ps、またはプロジェクトのドキュメントに記載されている e2e スイートの実行要件）。ゲートが失敗しても、対象コードを修正してはいけません（コアルール 5）。
• ステップ 12 — k=3 で多数決を取ります。3 回の実行で結果が異なったチェックがあれば記録します。
• ステップ 13 — 計算過程を示します。各チェック集合について MET／合計を列挙し、I と T を再計算できるようにします。集計はスクリプトで実行し、その出力を貼り付けます（再現性ルール 4）。Σw や Final を手計算してはいけません。

---

出力

reference.md のテンプレートに従って、Markdown レポートを作成します。レポートでは2 つの対象を分け、次の内容を含める必要があります：AC ごとの実装チェックリスト表（I チェック、MET／UNMET、証拠）；Elicitation E ブロック（カテゴリ別ルーブリックの再現率表＋追加要件台帳と判定 → E_recall／E_precision／E_justified）；Scope S のトレーサビリティ判定；要件ごとの unit／e2e テストチェックリスト表（承認済みの集合 = PRD の AC ∪ 有効な E 追加要件に対する T チェック）；追加テストの一覧；テスト分布 D 表（階層ごとの件数＋％）；算出した Final（ゲートが ✗ の場合は Adjusted Final も）；R／G／D；優先順位付きのギャップ一覧；1.00 に到達するための具体的な修正。

.specs／spec フォルダーがある場合は、レポートを <spec-folder>/evaluations/<priority>-<story-slug>-<timestamp>.md に保存します。ない場合は、レポートをインラインで提示します。<timestamp> は UTC 時刻を YYYYMMDDTHHMMSSZ 形式（例：20260606T143012Z）で指定し、書き込み時にシステムクロックから取得します（date -u +%Y%m%dT%H%M%SZ）。タイムスタンプによりレポートのファイル名が一意になるため、同じストーリーを複数のエージェントが並行して評価しても、互いのファイルを上書きすることはありません。各実行で個別のファイルが生成されます。同じ秒に衝突する可能性が残る場合（多数の並行実行時）は、短い run id を追加します：<priority>-<story-slug>-<timestamp>-<run-id>.md。

注：タイムスタンプを付けるのはレポートのファイル名だけです。固定された _ac-baseline.md には意図的にタイムスタンプを付けません。これはすべての実行が比較可能な状態を保つために読み込む、単一の共有アーティファクトです。実行ごとに別ファイルを作成してはいけません。

実施例

完全な適用評価（請求サービスの例における P0「カードなしで無料トライアルを開始する」）では、各 AC の二値チェックリストと file:line 形式の証拠に加え、評価基準のアンカーを示しています。reference.md を参照してください。その構成と厳密さに倣ってください。

アンチパターン

• 二値チェックを数えるのではなく、「0.75 くらいに感じる」といった連続的な判断で I／T を採点する。
• 凍結済みのベースラインを再利用せず、実装ごとに AC リストやチェックリストを再導出する（比較可能性が損なわれます）。
• 実施した検索を示さずにチェックを UNMET とする。または file:line 形式の証拠なしに MET とする。
• git diff を実行して差分の範囲を限定する前に、証拠を探してコードベース全体を検索する。これにより検索の信頼性が損なわれ、「見つからない」という確信が過度に高まります。
• 本番コードの処理経路を最初から最後まで読まずに、実装にクレジットを与える。
• AC で必要とされるカバレッジに、追加のテストや防御的なテストを含める。または、コードやテストの量が増えれば評価が上がるようにする。
• Engineering Gate を実行せずに合格と報告する。または、ゲートが not-run の場合に Adjusted Final を適用する。
• 記録された試行（コマンドとエラー出力）なしにゲートを not-run とする。プローブなしの「インフラが利用できない」は、捏造された証拠です。
• 赤判定のゲートを緑にするため、評価対象のコードを修正する。評価者は対象を読み取り専用で扱います。赤判定は ✗ と採点し、修正内容はレポートに記載してください。
• スクリプトを実行して出力を貼り付ける代わりに、ロールアップ（Σw、Final）を手計算する。
• スコープ外の機能がないことを減点する。
• E や S を Final に含める。主要な評価点は「与えられた PRD への忠実度」のみを表す必要があり、そうしないと比較可能性が損なわれます。
• フレームワークが抽出し、スコープ外として適切に延期した有効な要件を減点する（これはスコープの失敗ではなく、適切な規律です）。
• PRD のみを基準にハーネスの完全性（T）を採点する。分母は認可された集合（PRD の AC ∪ 有効な E の追加要件）です。
• E における要件の量を評価する。幻覚やスコープクリープによる追加は E_precision を下げるものであり、スコアを上げるものではありません。
• 同じ PRD の実装間で重み（0.6/0.4、P0/P1/P2）を変更する。