SpecScore が
検証するもの。
SpecScore は機能、要件、受け入れ基準のためのオープンな Markdown フォーマットで、2つのバリデーターが検査します：決定論的なリンターと AI レビューです。それぞれが 何を捉え、どこで自動チェックが止まるのかをご紹介します。
$ specscore lint checkout/ ✓ 24 requirements — structure, references, IDs valid ✓ no index drift · no broken links · no slug collisions 0 problems exit 0
1つではなく、3つの層。
SpecScore は層ごとに検証します — 最も安く、最も確実なものから先に。リンターは決定論的です — 高速、無料、コミットごとに走ります。AI レビューは確率的です — より深く、トークンを消費し、 リンターが届かないものを捉えます。人間の判断が3つめの層です： 最初の2つが閉じられない隙間には、やはり人が必要です — 今日、どのツールも それを確実に閉じることはできないからです。2つの自動化された層は、重複では なく補完し合います：リンターは AI が根拠を示せないものを捉え、AI は リンターが届かないものを捉えます。
各バリデーターが検査するもの。
CLI リンター
決定論的実行のたびに同じ結果、LLM なし、コストなし。ここで合格すれば、 それは意見ではなく事実です。
$ specscore lint apply-discount.md ✓ R1 has acceptance criteria ✓ R2 has acceptance criteria ✗ R3 no acceptance criteria ✗ link "Related Feature: discount-tiers" not found ✗ section "Open Questions" missing 3 problems exit 1
- 参照整合性 — リンクが解決し、ID が一意である
- 構造の取り決め — 必須セクション、frontmatter の形
- ステータスの整合性とインデックスのずれ
- slug の衝突
- メタデータ項目のプレフィックスの妥当性（例：
Related Ideas:）
AI レビュー＆スコア
非決定論的人間のレビュアーのように意味を読み取ります — そして人間と同じく、 完全には再現できません。
> /score apply-discount.md Grade: B — ready with edits AC-2 vague trigger — name the actor and event AC-3 no error path for an expired code prose reads clean; criteria need tightening
- 検証可能な Given/When/Then の形で書かれた AC
- アーティファクト内部の一貫性
- 曖昧な、またはプレースホルダーの内容
- 人間のレビュアーにとっての読みやすさ
- 作成者が対応でき、重要度が示されたフィードバック
- A〜F の準備度評価
捉えられないもの。
魔法のバリデーターはありません。それぞれがどこで止まるのか — あなた自身の 判断がどこでまだ働かなければならないのかを、正確にお伝えします。
CLI リンター
- 深い階層をまたぐ暗黙の矛盾
- 仕様とコードのずれ （
specstudio:recapの登場とともに改善中） - 受け入れ基準の意味的な正しさ
- 名前が実際に意味をなしているか
- 要件が掲げた課題を解決しているか
AI レビュー＆スコア
捉え方にばらつきがある- 実行ごとの完全な再現性 — 判定は許容範囲内で揺れることがある
- 明示的な相互チェックなしに、大きなツリー全体にまたがる矛盾
- 要件が本当に課題を解決しているか — 明白な抜けは指摘するが、ドメイン固有のものは見落とす
- 基盤となる LLM から受け継いだバイアス
- 絶対的な確実性をもった意味的な正しさ
- ルーブリックが重み付けしないもの全般
- 1
リンターはここまで届く
構造、参照、整合性。安く確実 — しかし意味には盲目です。
- 2
AI はここまで届く
アーティファクト内部の意味、明確さ、一貫性。より深く — しかし 確率的で、大きなツリーには弱いです。
- 3
ここはあなた次第
システム全体を横断する判断 — 今日どのツールも確実にはできない 仕事なので、やはり人間のレビュアーが必要です。これは見落とされた 穴ではなく、現在できることの正直な境界です。
どちらのツールも救ってくれないケース
実在する、深い仕様ツリーを思い浮かべてください。機能 A はX を要求します。機能 B は Y を要求します。 機能 C は Z を要求します。そして機能 D が、ひそかに B と矛盾する何かを要求します — ただし A も同時に有効なときに限って。 リンターは4つの妥当で、きれいにリンクされた文書を見て、合格させます。 AI レビューはアーティファクトを1つずつ読むので、4つすべてを読み込んで 三者間の相互作用に気づく理由がありません。
どちらの層もこれを確実には捉えられません — そして私たちは そうでないふりをするつもりはありません。 まさにこの種の矛盾こそ、 3つめの層が存在する理由です。SpecScore の役割は、隙間をレビューする人が 矛盾を見つけられるよう、ツリーを十分にたどりやすくすること です — オープンクエスチョンは階層を上へ伝播し、関連する要件は1つの クエリの先にあります — ツールがすでに見つけたと主張することではありません。