フォーマット
Markdown + YAML。テキストファイルを開けるエディタなら何でも対応。 書き始めるのに新しいツールは不要です。
仕様のあいまいさは、
エージェントが燃やすトークンだ。
次に、実装途中での確認の質問。次に、リリース後の修正。 次に、何度も説明し直すコンテキスト。
SpecScoreは、仕様のためのオープンでリント可能なファイル形式 — データに対するJSONのように。AIエージェントがクエリ・編集のために 呼び出すCLI付き — JSONに対するjqのように。
すでに書いている仕様のためのフォーマット。
SpecScoreはMarkdown + YAMLフォーマットで、機能、 要件、受け入れ基準を定義します。チームとAIエージェントの両方が 理解できる構造を提供し、リポジトリ内のファイルとして管理されます。
SpecScoreプロジェクトは、ライフサイクルに沿った3種類の アーティファクトで構成されます：アイデアは半ば形になった方向性を記録し、機能仕様は合意された振る舞いを確定し、プランは機能を順序付きのタスクに分解し、 各タスクはそれが満たす受け入れ基準を参照します。
なぜAIエージェントに関係するのか。構造が 機械可読であるため、AIエージェントはすべてのファイルを読む 代わりに、CLIを通じて仕様にクエリを送れます。「次に何に 取り組むべきか？」と尋ねれば、CLIがオープンな機能と 未解決の質問を返します。チームがレビューするのと同じ形を、 エージェントが読み込むコンテキストははるかに少なく。
仕様は階層的。だから仕様ツリーも階層的に。
機能が50個になるとフラットなリストはただの山積みになります。 SpecScoreはツリーをナビゲート可能に保ちます — 親はスコープを、 子はディテールを担い、ディレクトリの形はあなたのチームが すでに頭の中で扱っているプロダクトの形を映します。
オープンな問いは上に集約されます。どの深さにある未解決の問いも、すべての親のインデックスに 表面化します。リリースを止めているものが何かが、深く潜らずに ツリーの頂上から見えます。
ほとんどの仕様ツールはフラットなリストで足りると考えます。 実際、足ります — ある時点までは。SpecScoreは 「この機能はどこに住むのか？」が効いてくるその瞬間のために 作られています。
specscore-cli/spec/features/cli/spec/features/cli/
├── agent/
│ └── setup/
├── feature/
│ ├── change-status/
│ ├── deps/
│ ├── info/
│ ├── list/
│ ├── new/
│ ├── refs/
│ └── tree/
├── idea/
│ ├── change-status/
│ ├── new/
│ └── relocate/
├── spec/
│ └── lint/
│ ├── issue-rules/ ← サブサブ機能
│ └── plan-rules/
├── task/
│ ├── info/
│ ├── list/
│ └── new/
└── … トップレベル機能あと10件これがないと何が起きるか。
仕様がドリフトする。
ドキュメントの仕様、Slackのスレッド、PRのコードが 数週間にわたって静かに食い違い続けます。どのバージョンの 会話が正式なのか、誰にもわかりません。
解決策
リポジトリ内の1つの正式な仕様を、コードと一緒にバージョン管理。
specscore lintがCIでプッシュごとに実行され、git履歴が 監査証跡になります。仕様、スレッド、PRは同じレビュー対象のファイルを 共有するため、静かに食い違うことはできません。受け入れ基準が曖昧なまま。
「エラーを適切に処理する」は「トーストを表示してロールバックする」という意味のはずでした。 それとも「ログに記録してリトライする」？ エージェントは推測するしかありません。
解決策
リンターがコードを書く前に曖昧な基準を検出します。 具体的なオブジェクトや条件がない動詞はリントに失敗します。 警告を修正することで、「処理する」が実際に何を 意味するのかを書かざるを得なくなります。
エージェントが間違ったものを作る。
人間は補完し、質問し、確認します。AIエージェントはそうしません — 学習データで最も一般的だったパターンを実装します。コードは何か妥当なことをしているのでレビューを通ります。 ただ、あなたが意図したものとは違うのです。
解決策
構造化された入力。AIエージェントはREQ ID、AC ID、
GIVEN / WHEN / THENシナリオを決定論的に解析します — 補完の余地がありません。 プランは各タスクが満たすAC IDを引用する必要があるため、 何が作られたかを仕様と照合できます。曖昧な仕様には二重に払うことになる。
エージェントは曖昧な指示から何かを作り、あなたはそれが 間違っていることに気づき、4通りの言い方で指示をやり直す。 作りかけの機能も、やり直しのたびに、すべてトークンで 請求される。仕様が曖昧なほど、形になるまでの往復が増える。
解決策
エージェントを動かす前に仕様をリントする。
specscore lintが曖昧な動詞や欠けた受け入れ基準を 最初に弾くので、エージェントは推測でやり直すのではなく、 具体的な指示を一度で実装する。最も安いエージェント実行は、 やり直さずに済む実行だ。エージェントが仕様の再読み込みにコストを払う。
「この機能に何が依存しているか？」に答えるために、 AIエージェントは機能のREADME全体を読みます。次に親のインデックスを全部。 念のため兄弟の機能も。すべてのクエリが再パースです。 トークンが消え、レイテンシが上がり、請求額も上がります。
解決策
ファイル読み込みの代わりに構造化クエリ。
specscore feature treeは階層をYAMLで返し、feature depsは推移的な依存関係チェーンをたどり、feature infoはステータス、オーナー、未解決の質問を 1回の呼び出しで公開します。エージェントは散文ではなく グラフをナビゲートします。コードが仕様を忘れる。
6ヶ月後、ある関数をデバッグしていて、どの機能を実装しているのか 誰も覚えていません。コードと仕様のリンクは誰かの頭の中にあり、 その人は退職しました。導入したPRはアーカイブの中です。
解決策
ソースアノテーション。
// specscore: features/checkout/apply-discount/R1.AC-2のようなコメントがリンクを機械可読にし、リファクタリングを すべて生き延びます。specscore code depsは「このファイルはどの仕様を実装しているか？」に 1回の呼び出しで答え、リンターは削除された仕様への参照を検出します。ステータス変更が漏れる。
機能をREADMEでDraftからApprovedに変更しましたが、 親の機能インデックスにはまだDraftと記載されています。3週間後、 インデックスを読むエージェントはまだ検討中だと思います。 ステータスが2箇所に存在し、食い違っています。
解決策
specscore feature change-statusが機能のStatusフィールドを 書き換え、機能インデックスの行を1つのアトミック操作で再同期します — リント失敗で書き換えがロールバックされます。ステータスは1つの正式な 場所に存在し、インデックスはそのビューです。仕様が未知の事項を忘れる。
仕様は確定しているように読めます — 2ヶ月前に Slackスレッドで失われた「タイムゾーンはどうする？」という質問がドキュメントに反映されなかったことを思い出すまでは。 実装段階に入り、答えが何だったか誰にもわかりません。
解決策
すべてのSpecScore機能には必須のOutstanding Questionsセクションがあります。リンターはそれを省略した機能を拒否します — 空は問題ありません（
"None at this time."）が、 欠落は許されません。未解決の質問はドキュメント内で可視化され、 CLIからクエリ可能で、忘れることが不可能になります。
最も簡単な始め方：AIエージェント向けSpecStudio Skills。
SpecStudio SkillsはClaude Codeプラグインで、SpecScoreのライフサイクルを4つの スラッシュコマンドに変換します。一度インストールすれば、順番に実行するだけ — 生のアイデアから実行可能なプランまで。
$ /plugin marketplace add specscore/ai-marketplace $ /plugin install specstudio@specscore
Claude Codeautocomplete
> /specstudio: /specstudio:ideate Refine a raw idea into a SpecScore Idea /specstudio:specify Turn an approved Idea into a Feature spec /specstudio:plan Decompose a Feature into a Plan of tasks /specstudio:implement Execute the next task in a Plan
パブリックおよびオープンソースリポジトリは無料です。プラグインのソースはspecscore/specstudio-skills — MITライセンスです。
仕様を2つのパスで検査。
高速で決定論的なリンター、続いてより深い AI レビュー — どちらも、先ほど ご覧いただいた仕様に対して実行します。2つのパス、2種類の確実性。
リンターを実行。
決定論的$ 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
実行のたびに同じ結果。無料で高速、コミットごとに走ります。
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
人間のレビュアーのように、意味を読み取ります。
同梱されるもの。
リンター
Go製CLI。構造、参照、完全性を検証します。 失敗時はゼロ以外の終了コード — ターミナルでもCIでも動作します。
好きなツールを使ってください。
SpecScoreはリポジトリ内のファイルです。登録が必要なSaaSはありません。 オーケストレーターも不要です。Linear、Jira、GitHub Projects、フォルダ内の生のMarkdown、あるいはプロジェクト管理ツールなし でも使えます。フォーマットとリンターはチケットがどこにあるかを気にしません。
SpecScore との比較。
スペック駆動開発は競合の多い分野です。SpecScore が他の選択肢と比べて どこに立っているか — 正直にお伝えします。
CLIがお好みですか？
AIエージェントを使わない、またはCIパイプラインで仕様の検証が必要？ それならCLIがあります。60秒でインストール — アカウント不要、テレメトリなし、 Markdownの仕様があるどのディレクトリでも動作します。
$ curl -fsSL https://specscore.md/install/get-cli | sh> irm https://specscore.md/install/get-cli.ps1 | iexバイナリに同梱されるサンプル仕様をリントします：
$ specscore lint examples/checkout/apply-discount.md出力結果：
examples/checkout/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 1SpecScoreで構築。
Codegrapher
高速なコード探索と仕様↔コードの双方向リンクのためのコードグラフエンジン。
codegrapher.devDALgo
SpecScoreで仕様化されたGoデータアクセスレイヤー。
dal-go.github.ioinGitDB
SpecScoreで仕様化されたGitベースのバージョン管理データベース。
ingitdb.comRehearse
受け入れ根拠のレイヤー。仕様の受け入れ基準を実際に実行し、再利用可能なチェックでグルーコード不要。
rehearse.inkSpecScore Studio
SpecScore仕様の閲覧・編集用Web UI。
specscore.studio