SpecScore vs Kiro
仕様駆動開発（SDD）とは、AI エージェントがコードを書く前に、ソフトウェアが何をすべきかを文章にしておくことです。Amazon Web Services（AWS）の Kiro はエージェント型の開発環境です。エディタ、コマンドラインインターフェース（CLI）、ウェブアプリからなり、プロンプトを Kiro の仕様、すなわち要件・設計・タスクに変えます。それらの要件は EARS（要件構文への平易なアプローチ）を使います。「WHEN（何かが起きたとき）、THE SYSTEM SHALL（システムは何かをしなければならない）」という形の文です。SpecScore は仕様そのもののための オープンソースのフォーマットであり、ファイルを検査する CLI が付きます。継続的インテグレーション（CI）、つまり提案された変更のたびに走る自動検査は、フォーマットを壊した SpecScore の仕様を拒否できます。
共通点。
Kiro が得意なこと。
Kiro 自身のドキュメントを 2026年10月30日に読み、製品の説明に使いました。機能仕様のページには、2026年8月4日更新と記されていました。
決まった文型で書かれる要件
Kiro の仕様は振る舞いを requirements.md に、一つの EARS パターンで書きます。条件が成り立つ WHEN、システムは何かをしなければならない THE SYSTEM SHALL。ドキュメントの例は、不正なデータを含むフォームで、システムがフィールドの横に検証エラーを出す、というものです。この形は、あいまいな段落よりテストしやすいです。
プロンプトからタスクまでの一連の経路
機能仕様は、要件、設計（design.md）、タスク（tasks.md）と進みます。要件から始めることも、設計から始めることもできます。Quick Spec は三つを、間に承認の停止を挟まず通します。バグ修正用の仕様は別の経路です。ドキュメントは、tasks.md の依存グラフから、独立したタスクを波に分けて並列に実行することも説明しています。
製品の中にある検査
Analyze Requirements は IDE と CLI で使え、設計の前に、矛盾、あいまいさ、衝突する制約、抜けを探します。Correctness、つまりそれらの EARS の行から導くプロパティベーステストは、仕様の機能表において IDE のみに載っており、CLI、ウェブ、モバイルにはありません。
機能比較。
Kiro は仕様の草案を作る製品です。SpecScore は、リポジトリが検査できるフォーマットです。表はその役割を比べます。
| 機能 | Kiro | SpecScore |
|---|---|---|
| 主な役割 | 仕様の草案を作り、タスクを実装するエージェント型 IDE、CLI、ウェブアプリ | オープンな仕様フォーマット + CLI |
| 仕様ファイル | requirements.md（または bugfix.md）、design.md、tasks.md | Markdown と YAML の spec/ ツリー |
| 要件の構文 | EARS のパターン: WHEN … THE SYSTEM SHALL … | 要件 ID（REQ: slug）と Given/When/Then の受け入れ基準 |
| 仕様の検査 | IDE と CLI の Analyze Requirements。IDE のプロパティベーステスト。自前の CI 向けフォーマットリンターとしては説明されていません。 | CI の specscore spec lint。/score は別の、手動の AI 採点です。 |
| 動作する場所 | Kiro IDE、Kiro CLI、Kiro のウェブ。検査の一部は IDE のみです。 | 任意のリポジトリ — Go バイナリ一つ。Kiro のアカウントは不要 |
| ライセンス | Kiro のライセンス は、IDE と CLI が AWS カスタマー契約の下の AWS Content であるとしています。Kiro Crew は別の 公開リポジトリ です。 | CC BY 4.0 のフォーマット · Apache-2.0 の CLI |
| 価格 | 無料枠と有料プランがあります。数字は変わります。2026年10月30日に読んだ Kiro の料金 を参照してください。 | フォーマットにも CLI にも 料金はありません |
SpecScore が加えるもの。
フォーマットは、それだけで CI を失敗させる
Kiro の分析は Kiro の中で動きます。SpecScore の検査は一つのコマンドです。このリポジトリの dogfood ワークフロー は、すべてのプルリクエストと main で specscore spec lint を実行します。壊れた仕様は、壊れたテストと同じようにジョブを失敗させます。/score スキルは、AI のレビュアーで文言を採点します。その一回は手動であり、上のワークフローはそれを実行しません。
$ specscore spec lint features/apply-discount/README.md:0 [error] oq-section: Open Questions section not found features/apply-discount/README.md:0 [error] index-entries: Child directory not listed in index: refunds features/apply-discount/refunds:0 [error] readme-exists: README.md not found 3 violations found (3 errors)
仕様は一つの IDE に縛られない
Kiro の仕様は Markdown なので、製品がなくても読めます。それらを作り、実行するワークフローは Kiro のものです。SpecScore のツリーは、Claude Code、Cursor、Copilot、あるいはエージェントが何もない場合でも同じファイルです。CLI は lint のためにモデルを呼びません。
要件には ID が残る
Kiro のドキュメントは、トレーサビリティを、要件を実装まで追うこととして説明しています。書き換えを超えて残る安定した ID は説明していません。SpecScore は要件を REQ: slug として指し、受け入れ基準はそれ自身の ID で指します。
EARS と Given/When/Then は別の問いに答える
Kiro が文書化している EARS は、システムの振る舞いを一文にしたものです。SpecScore の受け入れ基準は、要件 ID に結び付いた Given/When/Then のシナリオです。散文の中に EARS の一文を書き、リンターが検査する SpecScore のファイルにはシナリオを残す、という併用ができます。 文型はEARS要件構文.
使い分けの指針。
Kiro を選ぶのは…
- プロンプトから要件、設計、タスクの草案を作り、そのタスクを実装する、AWS のエージェント型 IDE が欲しいとき。
- EARS の文と、IDE ではそれらから生成されるプロパティベーステストが欲しいとき。
- チームがすでに Kiro のエディタ、CLI、またはウェブアプリに揃えているとき。
SpecScore を使うべきなのは…
- エージェントのセッションが終わったあとも、Kiro を必要としないリポジトリで、仕様が CI において妥当であり続けなければならないとき。
- 要件 ID、ライフサイクルの状態、決定論的な lint の結果が必要なとき。
- フォーマットを オープンソース にし、検査器を単一のバイナリにしたいとき。
Kiro は草案を書ける。SpecScore は関門になれる。
ここにあるものは、Kiro のエディタに取って代わるものではありません。チームがプロンプトする場所が Kiro なら、草案は Kiro に任せてください。仕様がレビューされるファイルとして残らなければならないなら、その契約を SpecScore で書き、構造が壊れたときに specscore spec lint がプルリクエストを失敗させるようにします。二つのファイルは同じリポジトリに置けます。
セッションには Kiro を。CI のジョブが拒否できる成果物には SpecScore を。
出典。
下の公開ページは 2026年10月30日に読みました。価格、プラン名、リリースの線は変わります。
フィードバック
この比較は公開されているドキュメントとソースコードに基づいています。誤りや古い情報がありますか？ 修正issueを作成. 他のツールとの比較をご希望ですか？ リクエスト.