SpecScore vs OpenSpec
どちらも仕様を Markdown でコードの隣に配置し、AI エージェントが読み取れるようにします。解決する課題は異なります。OpenSpec はスペックを整理してエージェントコマンドを生成します。SpecScore はスペックの内容を lint し、ライフサイクルを強制し、コードから要件へのトレーサビリティを提供します。
共通点
OpenSpec の優れた点
最も幅広いエージェント対応
OpenSpec は生成されたスキルファイルを通じて 29 の AI コーディングエージェントをサポートしています — Claude、Cursor、Copilot、Gemini、Windsurf、Cline など。お使いのエージェントがリストにあれば、設定不要で統合できます。
導入障壁の低さ
npm install -g @fission-ai/openspec && openspec init ですぐにスペックを書き始められます。覚えるスキーマも、必須のフロントマターもありません。特に既存のコードベースでの導入が簡単になるよう設計されています。
優れた変更デルタモデル
スペックの進化に対応する OpenSpec の ADDED / MODIFIED / REMOVED フォーマットは優れた設計です。各変更はプロポーザル、デルタスペック、タスクを含むフォルダで構成され、変更提案を構造化する方法を提供します。
機能比較
| 機能 | OpenSpec | SpecScore |
|---|---|---|
| スペックフォーマット | Markdown（フロントマターなし） | Markdown + YAML frontmatter |
| スペック linting | ファイル構造のみ | コンテンツ品質 — 曖昧な動詞、欠落した AC、未解決の参照 |
| 要件 ID | なし（タイトルで参照） | スラッグベース（REQ: slug-format） |
| 受け入れ基準 ID | なし | 機械可読な ID |
| ライフサイクルステータス | 暗黙的（ファイルの配置場所） | 強制 — Draft → Under Review → Approved → Implementing → Stable → Deprecated |
| コードからスペックへのトレーサビリティ | なし | specscore: アノテーション + Verifies: コミットトレーラー |
| サブフィーチャー | なし | あり（ネストされたディレクトリ） |
| 相互参照 | 公式なメカニズムなし | 依存関係、ソースアイデア、プラン参照 |
| CI 統合 | 基本的（openspec validate） | specscore lint 設定可能な重要度、pre-commit フック対応 |
| エージェント対応 | 29 エージェント | Claude Code を主軸に、CLI であらゆるエージェントに対応 |
| スキーマのカスタマイズ | あり（schema.yaml、fork/init） | 固定スキーマ（設計による一貫性） |
| 変更提案 | デルタモデル（ADDED/MODIFIED/REMOVED） | 変更リクエストアイデア + プロポーザル |
| ランタイム依存 | Node.js 20.19+ | なし — 単一の Go バイナリ |
| ライセンス | MIT | MIT |
SpecScore がさらに進んでいる点
検証はファイル構造にとどまらない
OpenSpec の validate はファイル構造を検査します — ファイルが存在するか、正しいセクションがあるか。SpecScore は2つの層でさらに踏み込みます：lint はコンテンツの関係性を決定論的に検証し — すべての要件に受け入れ基準があるか、相互参照が解決するか、ステータス遷移が妥当か — そして AI レビュー（/review、/score）が、どんなリンターにも捉えられないもの — 曖昧な基準や漠然とした動詞 — を捉えます。
$ specscore lint checkout/apply-discount.md ✗ R3 no acceptance criteria ✗ link "Related Feature: discount-tiers" not found
すべての要件に機械可読な ID
OpenSpec はタイトルで要件を参照するため、名前変更に弱い構造です。SpecScore はスラッグベースの ID（REQ: slug-format）と AC ID を割り当て、名前変更、リファクタリング、エージェント間の引き継ぎにも耐えます。
ライフサイクルは暗黙的ではなく強制的
OpenSpec ではスペックのライフサイクルはファイルの配置場所で決まります：specs/（現行）、changes/（提案中）、archive/（完了）。SpecScore ではライフサイクルは強制されるステータスフィールドです — Draft → Under Review → Approved → Implementing → Stable → Deprecated — lint で検証され、git フックや CI から specscore change-status で遷移します。
コードからスペックへの追跡
OpenSpec にはトレーサビリティの仕組みがありません。SpecScore にはコードコメント内の specscore: ソースアノテーションと Verifies: コミットトレーラーがあります。specscore code refs を実行すれば、「この要件を実装しているコードはどれか？」に対する確定的な答えが得られます。
ランタイム依存なし
OpenSpec は Node.js 20.19+ が必要です。SpecScore は単一の Go バイナリで、ランタイムも node_modules も不要です。Go、Rust、Python、Java のプロジェクトに Node を追加することなく動作します。
構成可能なアーティファクト階層
OpenSpec のスペックはドメインごとにフラットです。SpecScore は型付けされた階層を持ちます：アイデアはフィーチャーに昇格し、フィーチャーは要件と AC を含み、プランは AC を参照し、タスクはプランを参照します。すべての関係は CLI で機械的にナビゲートできます。
使い分けの指針
OpenSpec から始めるべき場合
- Cursor、Copilot、または Claude 以外のエージェントを使用していて、すぐに使える統合が必要な場合。
- 既存のコードベースに初めてスペックを追加する際に、摩擦をゼロにしたい場合。
- チームがスキーマの強制よりも柔軟性を重視する場合。
SpecScore を使うべき場合
- スペック品質の強制が必要な場合 — lint がエージェントがトークンを無駄にする前に曖昧さを検出します。
- コードからスペックへのトレーサビリティが必要な場合 — 「この要件を実装しているコードはどれか？」に確定的な答えが返ります。
- 多くのフィーチャー、サブフィーチャー、ライフサイクル遷移を持つ大規模システムを構築する場合。
- ランタイム依存をゼロにしたい場合 — 単一バイナリ、Node.js 不要です。
- CI にスペック品質ゲートが必要な場合 —
specscore lintは ESLint やgo vetと同様に、失敗時にゼロ以外の終了コードを返します。
相互に排他的ではありません。
SpecScore は OpenSpec の spec.md ファイルを lint できます。OpenSpec から始めたチームは、移行することなく SpecScore の品質レイヤーを追加できます — 既存のスペックを lint し、必要に応じてトレーサビリティを追加し、チームが成長したらライフサイクルを強制できます。
OpenSpec は優れた出発点です。SpecScore はガードレールです。
フィードバック
この比較は公開されているドキュメントとソースコードに基づいています。誤りや古い情報がありますか？ 修正issueを作成. 他のツールとの比較をご希望ですか？ リクエスト.