仕様駆動開発（SDD）とは？AIに渡す仕様書テンプレートと進め方

仕様駆動開発（Spec-Driven Development、SDD）とは、コードを書く前に「何を作るか」を文書にし、その文書を AI への指示の基準にして実装を進めるやり方です。 会話の流れに頼らず、要件・設計・タスクを Markdown のファイルとしてリポジトリに置くので、AI に渡す内容が毎回そろい、人も後から読み返せます。

この記事では、コピペできる3文書のテンプレート、架空の備品貸出アプリの記入例、受け入れ条件を書く EARS 記法の書き方表、文書どうしの対応を確かめるスクリプト、似たやり方との違い、Spec Kit と Kiro のコマンドとファイル構成をまとめます。設計書を AI に書かせるプロンプトではなく、仕様書の書式と受け入れ条件の書き方に絞っています。

確認環境（確認日 2026-10-06）：Ubuntu、Python 3.11.15、uv 0.8.17、Spec Kit の CLI（specify-cli 1.0.13）。記入例の3文書は、掲載した Python スクリプトで書式と対応を確かめています。Spec Kit は初期化コマンドを実行して、作られたファイルを確かめました。Kiro は公式ドキュメントの記載をまとめています。プロンプトはひな形で、モデルの出力例は載せていません。

この記事の結論

• 要件・設計・タスクの3文書を Markdown で先に書きます。
• AI には1タスクずつ実装させます。 1タスク＝1コミットにすると、確認と差し戻しが小さく済みます。
• 受け入れ条件は EARS 記法で1文ずつ書き、番号を付けます。 設計・タスク・テストからその番号を指します。
• 3文書の対応は機械的に確かめます。 対応するタスクがない受け入れ条件は、スクリプトで見つかります。

仕様駆動開発の早見表

似たやり方との違いと選び方

仕様駆動開発と TDD は競合しません。受け入れ条件1つをテスト1本にすると、仕様駆動の文書と TDD のテストがそのままつながります。

どの規模から仕様駆動にするかの目安です。

受け入れ条件を書くEARS記法の書き方表

EARS（Easy Approach to Requirements Syntax）は、要件を決まった語順の1文で書く記法です。考案者の Alistair Mavin 氏のサイトでは、基本の形を「While（前提の状態）, when（きっかけ）, the（システム名）shall（システムの応答）」とし、次の型を示しています。Kiro の公式ドキュメントも、要件の書式として「WHEN［条件・イベント］THE SYSTEM SHALL［期待する動き］」を挙げています。

キーワード（WHEN、IF、THE SYSTEM SHALL など）を英大文字のまま残すと、人にも AI にも区切りが見つけやすく、後で示すスクリプトでも確かめられます。すべて日本語で書く場合も、語順（条件 → システムは → 応答）をそろえます。

直す前と後

受け入れ条件を書くときの確認点です。

• 1文に応答は1つ。 「〜し、〜し、〜する」が3つ以上続いたら分けます。
• 数と文言を書く。 上限、日数、表示する文をそのまま書きます。
• うまくいかない場合を IF で書く。 正常な流れ1つにつき、IF の条件を1つ以上探します。
• 番号を付ける。 「AC-要件番号-連番」の形にすると、設計・タスク・テスト名から指せます。

3文書のテンプレート（コピペ用）

リポジトリの specs/機能名/ の下に3つのファイルを置く想定です。

要件のテンプレート（requirements.md）

# 要件：{機能名}

## 1. 目的
{誰の、どんな困りごとを、どう変えるか を2〜3文で}

## 2. 範囲
- 含む: {今回作るもの}
- 含まない: {今回作らないもの。理由や時期も}

## 3. 用語
| 用語 | 意味 |
|---|---|
| {用語} | {この文書での意味} |

## 4. 要件と受け入れ条件

### R-01 {要件の名前}
{役割}として、{したいこと}。{理由}のため。

- AC-01-1: WHEN {きっかけ}、THE SYSTEM SHALL {応答}
- AC-01-2: IF {望ましくない事象}、THEN THE SYSTEM SHALL {応答}

### R-02 {要件の名前}
{役割}として、{したいこと}。{理由}のため。

- AC-02-1: WHEN {きっかけ}、THE SYSTEM SHALL {応答}

## 5. 決めていないこと
| 番号 | 内容 | 決める人 | 期限 |
|---|---|---|---|
| Q-1 | {内容} | {名前} | {日付} |

設計のテンプレート（design.md）

# 設計：{機能名}

## 1. 方針
- 構成: {アプリとデータベースの数、配置}
- 言語とフレームワーク: {版まで}
- 要件にない機能は作らない。迷ったら requirements.md の「決めていないこと」に足す

## 2. データ
| テーブル | 列 | 型 | 制約 | 対応する要件 |
|---|---|---|---|---|
| {テーブル} | {列} | {型} | {制約} | {R-01 や AC-01-1} |

## 3. 画面と API
| 番号 | メソッドとパス | 役割 | 対応する受け入れ条件 |
|---|---|---|---|
| IF-1 | {GET /…} | {役割} | {AC-01-1} |

## 4. エラーの扱い
| 場面 | 応答 | 表示する文 | 対応 |
|---|---|---|---|
| {場面} | {ステータスコード} | {文言} | {AC-01-2} |

## 5. テストの方針
- 受け入れ条件1つにつき、テストを1本以上書く。テスト名に AC の番号を入れる
- {日付や乱数など、固定して渡すもの}

## 6. 採らなかった案
| 案 | 採らなかった理由 |
|---|---|
| {案} | {理由} |

タスクのテンプレート（tasks.md）

# タスク：{機能名}

進め方：上から順に1つずつ。1タスク＝1コミット。終わったら [x] にする。

- [ ] T-01 {作業の名前}
  - 触るファイル: {パス}
  - 対応: {AC-01-1, AC-01-2}
  - 完了の条件: {通るべきテスト、確かめるコマンド}
- [ ] T-02 {作業の名前}
  - 触るファイル: {パス}
  - 対応: {AC-02-1}
  - 完了の条件: {…}

タスクの大きさは「触るファイルが2〜3個、対応する受け入れ条件が1〜3個」を目安にします。これより大きいと確認に時間がかかり、差し戻しの範囲も広がります。

記入例：架空の備品貸出アプリ

社員が共有の備品を借りて返す、架空の Web アプリです。人名・数値はすべて架空の例です。

要件の記入例

# 要件：備品貸出アプリ（貸出申請と返却）

## 1. 目的
社員が共有の備品（プロジェクター、三脚など）を借りる・返す手続きを、表計算の台帳から Web アプリに移す。

## 2. 範囲
- 含む: 備品の一覧表示、貸出申請、返却登録、返却期限を過ぎた貸出の一覧
- 含まない: 備品の購入申請、棚卸し、メール通知（次の版で検討）

## 3. 用語
| 用語 | 意味 |
|---|---|
| 備品 | 貸出の対象になる物。備品IDで区別する |
| 貸出 | 1人の社員が1つの備品を借りている状態。返却日が空なら貸出中 |
| 返却期限 | 貸出日から7日後の日付 |

## 4. 要件と受け入れ条件

### R-01 貸出申請
社員として、空いている備品を借りたい。会議の準備をすぐ始められるようにするため。

- AC-01-1: WHEN 社員が貸出中でない備品に貸出を申請したとき、THE SYSTEM SHALL 貸出を登録し、返却期限を貸出日の7日後に設定する
- AC-01-2: IF 申請された備品が貸出中である、THEN THE SYSTEM SHALL 貸出を登録せず、「この備品は貸出中です」と表示する
- AC-01-3: WHILE 社員が貸出中の備品を3件持っているあいだ、THE SYSTEM SHALL その社員の新しい貸出申請を受け付けない

### R-02 返却登録
社員として、借りた備品を返したことを記録したい。次の人が借りられるようにするため。

- AC-02-1: WHEN 社員が自分の貸出に返却を登録したとき、THE SYSTEM SHALL 返却日に当日の日付を記録し、備品を貸出可能に戻す
- AC-02-2: IF 返却が登録済みの貸出に再び返却が登録された、THEN THE SYSTEM SHALL 記録を変更せず、「返却済みです」と表示する

### R-03 期限切れ一覧
管理者として、返却期限を過ぎた貸出を一覧で見たい。声をかける相手が分かるようにするため。

- AC-03-1: WHEN 管理者が期限切れ一覧を開いたとき、THE SYSTEM SHALL 返却日が空で返却期限が当日より前の貸出を、返却期限の早い順に表示する
- AC-03-2: WHERE 管理者の権限を持つ利用者である場合、THE SYSTEM SHALL 期限切れ一覧へのリンクをメニューに表示する

### R-04 共通
- AC-04-1: THE SYSTEM SHALL すべての日付を日本時間の YYYY-MM-DD 形式で表示する

## 5. 決めていないこと
| 番号 | 内容 | 決める人 | 期限 |
|---|---|---|---|
| Q-1 | 返却期限の延長を認めるか | 総務 佐藤（架空） | 2026-10-20 |

設計の記入例

# 設計：備品貸出アプリ（貸出申請と返却）

## 1. 方針
- 構成: Web アプリ1つ＋リレーショナルデータベース1つ
- 言語とフレームワーク: Python 3.11、Web フレームワークは既存の社内標準に合わせる
- 要件にない機能は作らない。迷ったら requirements.md の「決めていないこと」に足す

## 2. データ
| テーブル | 列 | 型 | 制約 | 対応する要件 |
|---|---|---|---|---|
| items | id | 整数 | 主キー | R-01 |
| items | name | 文字列(100) | 必須 | R-01 |
| loans | id | 整数 | 主キー | R-01 |
| loans | item_id | 整数 | items.id を参照 | R-01 |
| loans | employee_id | 整数 | 必須 | R-01 |
| loans | loaned_on | 日付 | 必須 | AC-01-1 |
| loans | due_on | 日付 | 必須（loaned_on の7日後） | AC-01-1 |
| loans | returned_on | 日付 | 空なら貸出中 | AC-02-1 |

同じ備品の貸出中の行は1件まで（returned_on が空の行に対する一意制約）。対応：AC-01-2

## 3. 画面と API
| 番号 | メソッドとパス | 役割 | 対応する受け入れ条件 |
|---|---|---|---|
| IF-1 | GET /items | 備品の一覧と貸出状況 | AC-01-1 |
| IF-2 | POST /loans | 貸出申請 | AC-01-1, AC-01-2, AC-01-3 |
| IF-3 | POST /loans/{id}/return | 返却登録 | AC-02-1, AC-02-2 |
| IF-4 | GET /loans/overdue | 期限切れ一覧（管理者のみ） | AC-03-1, AC-03-2 |

## 4. エラーの扱い
| 場面 | 応答 | 表示する文 | 対応 |
|---|---|---|---|
| 貸出中の備品に申請 | 409 | この備品は貸出中です | AC-01-2 |
| 貸出中が3件ある社員が申請 | 409 | 貸出は3件までです | AC-01-3 |
| 返却済みの貸出に返却 | 409 | 返却済みです | AC-02-2 |
| 管理者でない利用者が期限切れ一覧を開く | 403 | 権限がありません | AC-03-2 |

## 5. テストの方針
- 受け入れ条件1つにつき、テストを1本以上書く。テスト名に AC の番号を入れる
- 日付は固定した「今日」を渡して判定する（実行日に左右されないようにする）

## 6. 採らなかった案
| 案 | 採らなかった理由 |
|---|---|
| 貸出状況を items の列で持つ | 履歴が残らず、AC-03-1 の一覧を作れない |

タスクの記入例

# タスク：備品貸出アプリ（貸出申請と返却）

進め方：上から順に1つずつ。1タスク＝1コミット。終わったら [x] にする。

- [ ] T-01 プロジェクトの土台を作る（テストが1本通る状態）
  - 触るファイル: pyproject.toml, tests/test_smoke.py
  - 対応: AC-04-1
  - 完了の条件: テストコマンドが成功する。日付を YYYY-MM-DD にする関数とそのテストがある
- [ ] T-02 items と loans のテーブルを作る
  - 触るファイル: migrations/001_init.sql
  - 対応: AC-01-1, AC-01-2
  - 完了の条件: 同じ備品の貸出中の行を2件入れるとエラーになるテストが通る
- [ ] T-03 貸出申請（IF-2）を実装する
  - 触るファイル: app/loans.py, tests/test_loans.py
  - 対応: AC-01-1, AC-01-2, AC-01-3
  - 完了の条件: 3つの受け入れ条件それぞれのテストが通る
- [ ] T-04 返却登録（IF-3）を実装する
  - 触るファイル: app/loans.py, tests/test_return.py
  - 対応: AC-02-1, AC-02-2
  - 完了の条件: 2つの受け入れ条件それぞれのテストが通る
- [ ] T-05 期限切れ一覧（IF-4）を実装する
  - 触るファイル: app/overdue.py, tests/test_overdue.py
  - 対応: AC-03-1, AC-03-2
  - 完了の条件: 並び順と権限のテストが通る

対応表（タブ区切り）

受け入れ条件・設計・タスクの対応を表計算ソフトで管理したいときの形です。

受け入れ条件  型   設計の該当箇所 タスク テスト名の例
AC-01-1 イベント    loans.due_on, IF-2  T-02, T-03  test_ac_01_1_due_is_7_days_later
AC-01-2 望ましくない事象    一意制約, IF-2, エラー409  T-02, T-03  test_ac_01_2_item_already_loaned
AC-01-3 状態  IF-2, エラー409    T-03    test_ac_01_3_limit_three_loans
AC-02-1 イベント    loans.returned_on, IF-3 T-04    test_ac_02_1_return_sets_date
AC-02-2 望ましくない事象    IF-3, エラー409    T-04    test_ac_02_2_already_returned
AC-03-1 イベント    IF-4    T-05    test_ac_03_1_overdue_sorted
AC-03-2 オプション   IF-4, エラー403    T-05    test_ac_03_2_admin_only_link
AC-04-1 常時  方針  T-01    test_ac_04_1_date_format

書式と対応をスクリプトで確かめる

3文書は人が読んで合意するものですが、「受け入れ条件が型に合っているか」「どのタスクにも対応していない条件がないか」は機械的に確かめられます。次のスクリプトは、上の記入例の書式（AC-番号、対応: の行）を前提にしています。

# check_spec.py  受け入れ条件の書式と、タスクとの対応を確かめる（標準ライブラリのみ）
# 使い方: python3 check_spec.py specs/lending
import re
import sys
from pathlib import Path

folder = Path(sys.argv[1])
req = (folder / "requirements.md").read_text(encoding="utf-8")
tasks = (folder / "tasks.md").read_text(encoding="utf-8")

EARS = [
    ("イベント", r"^WHEN .+、THE SYSTEM SHALL .+"),
    ("状態", r"^WHILE .+、THE SYSTEM SHALL .+"),
    ("オプション", r"^WHERE .+、THE SYSTEM SHALL .+"),
    ("望ましくない事象", r"^IF .+、THEN THE SYSTEM SHALL .+"),
    ("常時", r"^THE SYSTEM SHALL .+"),
]
VAGUE = ["適切に", "なるべく", "すばやく", "使いやすく", "など"]

criteria = dict(re.findall(r"^- (AC-\d+-\d+): (.+)$", req, re.M))
problems = 0
print(f"受け入れ条件: {len(criteria)}件")
for ac, text in criteria.items():
    kind = next((name for name, pat in EARS if re.match(pat, text)), None)
    vague = [w for w in VAGUE if w in text]
    if kind is None:
        problems += 1
        print(f"  NG {ac}: EARS の型に合っていません → {text}")
    elif vague:
        problems += 1
        print(f"  NG {ac}: あいまいな語があります {vague}")
    else:
        print(f"  OK {ac}: {kind}")

covered = set()
for line in re.findall(r"^\s+- 対応: (.+)$", tasks, re.M):
    covered.update(re.findall(r"AC-\d+-\d+", line))
for ac in sorted(set(criteria) - covered):
    problems += 1
    print(f"  NG {ac}: 対応するタスクがありません")
for ac in sorted(covered - set(criteria)):
    problems += 1
    print(f"  NG {ac}: タスクにありますが、要件にありません")

n_tasks = len(re.findall(r"^- \[[ x]\] T-\d+", tasks, re.M))
print(f"タスク: {n_tasks}件／問題: {problems}件")
sys.exit(1 if problems else 0)

記入例に対して実行した結果です。

$ python3 check_spec.py specs/lending
受け入れ条件: 8件
  OK AC-01-1: イベント
  OK AC-01-2: 望ましくない事象
  OK AC-01-3: 状態
  OK AC-02-1: イベント
  OK AC-02-2: 望ましくない事象
  OK AC-03-1: イベント
  OK AC-03-2: オプション
  OK AC-04-1: 常時
タスク: 5件／問題: 0件

下書きの段階の文書（受け入れ条件 AC-02-1 と AC-04-1 があいまいで、AC-04-2 を足したのにタスクがなく、タスク側に存在しない AC-05-1 が書かれている状態）に対して実行すると、次のように見つかります。

$ python3 check_spec.py specs/draft
受け入れ条件: 9件
  OK AC-01-1: イベント
  OK AC-01-2: 望ましくない事象
  OK AC-01-3: 状態
  NG AC-02-1: EARS の型に合っていません → 返却したら適切に処理する
  OK AC-02-2: 望ましくない事象
  OK AC-03-1: イベント
  OK AC-03-2: オプション
  NG AC-04-1: あいまいな語があります ['など']
  OK AC-04-2: イベント
  NG AC-04-2: 対応するタスクがありません
  NG AC-05-1: タスクにありますが、要件にありません
タスク: 5件／問題: 4件

問題があると終了コードが 1 になるので、コミット前の自動チェックにそのまま使えます。あいまいな語の一覧（VAGUE）は、チームでよく出る語に合わせて足してください。

AIに渡すプロンプトと進め方

各段階で、文書のファイルを読ませてから頼みます。

段階1：要件の抜けを探させる

specs/lending/requirements.md を読んでください。コードはまだ書かないでください。
次の3点を、受け入れ条件の番号を付けて挙げてください。
1. うまくいかない場合（IF の条件）が書かれていない要件
2. 数・日数・表示する文が決まっていない受け入れ条件
3. 互いに矛盾している、または同じことを言っている受け入れ条件
決める必要がある点は、質問の形で最大5つにまとめてください。文書は私が直します。

段階2：設計案を作らせる

specs/lending/requirements.md をもとに、specs/lending/design.md の案を書いてください。
- 章立ては「方針／データ／画面と API／エラーの扱い／テストの方針／採らなかった案」
- データ・API・エラーの各行に、対応する受け入れ条件の番号（AC-xx-x）を必ず書く
- 要件にない機能は足さない。必要だと考えたものは、文書の末尾に「提案」として分けて書く
- どの設計にも現れない受け入れ条件があれば、最後に一覧で示す

段階3：タスクに分けさせる

requirements.md と design.md をもとに、specs/lending/tasks.md を書いてください。
- 1タスクは、触るファイル2〜3個、対応する受け入れ条件1〜3個まで
- 各タスクに「触るファイル／対応／完了の条件」を書く
- 先に終わっている必要があるタスクが上に来る順に並べる
- すべての受け入れ条件が、どれかのタスクの「対応」に入っていること

段階4：1タスクずつ実装させる

specs/lending/ の3文書を読み、tasks.md の T-03 だけを実装してください。
- 「触るファイル」に書かれたファイル以外は変えない
- 対応する受け入れ条件ごとにテストを書き、テスト名に AC の番号を入れる
- 文書と合わない点に気づいたら、実装を止めて質問する（文書は書き換えない）
- 終わったら、テストの実行結果と変更したファイルを報告し、tasks.md の T-03 を [x] にする

実装の途中で仕様を変えたくなったら、先に requirements.md か design.md を人が直し、それから同じタスクをやり直させます。 コードだけを直すと、次のタスクで AI が以前の文書を読んで元に戻すことがあります。

Spec KitとKiroのコマンドとファイル構成

仕様駆動開発を支える道具の例として、公式の情報で確認できた範囲をまとめます。どちらも、この記事の3文書と同じ「要件 → 設計（計画） → タスク」の流れです。

Spec Kit

公式リポジトリの README にある導入手順は次のとおりです（Python 3.11 以上と uv が必要）。

uv tool install specify-cli
specify init my-project --integration copilot
cd my-project

specify-cli 1.0.13 で、連携先を claude にして初期化したところ、次のファイルが作られました（主なもの）。ひな形は CLI に同梱されていて、初期化にネットワーク接続は使われません。

my-project/
├── .specify/
│   ├── memory/constitution.md          # プロジェクトの原則
│   ├── templates/
│   │   ├── spec-template.md            # 仕様のひな形
│   │   ├── plan-template.md            # 実装計画のひな形
│   │   ├── tasks-template.md           # タスクのひな形
│   │   ├── checklist-template.md
│   │   └── constitution-template.md
│   ├── scripts/bash/                   # create-new-feature.sh など
│   └── workflows/speckit/workflow.yml
└── .claude/skills/
    ├── speckit-constitution/SKILL.md
    ├── speckit-specify/SKILL.md
    ├── speckit-plan/SKILL.md
    ├── speckit-tasks/SKILL.md
    ├── speckit-implement/SKILL.md
    └── …（省略）…

初期化の完了メッセージに表示されたコマンドです。

同梱の計画のひな形には、機能ごとの文書の置き場所が次のように書かれています。

specs/[###-feature]/
├── plan.md              # /speckit-plan の出力
├── research.md
├── data-model.md
├── quickstart.md
├── contracts/
└── tasks.md             # /speckit-tasks の出力

仕様のひな形（spec-template.md）は、優先度付きのユーザーストーリー、Given・When・Then 形式の受け入れシナリオ、FR-001 のような番号付きの機能要件、SC-001 のような成功基準、という構成でした。タスクのひな形は「- [ ] T001 説明」の形で、並行して進められるタスクに [P]、対応するユーザーストーリーに [US1] のような印を付けます。

Kiro

Kiro の公式ドキュメントでは、spec を「機能の開発や不具合の修正を形式化する、構造化された成果物」と説明しています。

道具を使うか、Markdown だけで始めるか

確かめて分かったこと

• Spec Kit のコマンド名は、今回入れた版では /speckit-specify のようにハイフン区切りでした。 版によって表記が変わることがあるので、初期化後に表示されるメッセージで確かめるのが確実です。
• Spec Kit の初期化は、ひな形が CLI に同梱されているためネットワーク接続なしで完了しました。 ひな形の内容は入れた CLI の版に対応します。
• Spec Kit の仕様のひな形は Given・When・Then 形式、Kiro の要件は EARS 記法と、受け入れ条件の書式が道具によって違いました。どちらも「条件 → 応答」を1文にする点は同じです。
• 「など」の1語でも、あいまいさの検査にかかりました。 「日付などを見やすく」のような文は、対象を全部書き出すと EARS の型に収まります。
• 受け入れ条件を1つ足しただけで、対応するタスクがない状態になりました。 文書を直したら、その場で対応の確認を回すと取りこぼしが出ません。
• タスク側に存在しない番号を書いても、人の目では気づきにくいものです。 両方向（要件→タスク、タスク→要件）で確かめると見つかります。

よくある質問

Q. 仕様駆動開発（SDD）とは何ですか？ A. コードの前に要件・設計・タスクを文書にし、その文書を基準に AI へ実装を頼むやり方です。文書はリポジトリに置き、実装より先に更新します。

Q. 仕様駆動開発とバイブコーディングの違いは何ですか？ A. 先に文書を書くかどうかが違います。バイブコーディングは対話しながら形にし、仕様駆動開発は合意した文書から実装します。試作はバイブコーディング、残すものは仕様駆動、と使い分けられます。

Q. 仕様駆動開発と TDD の違いは何ですか？ A. 先に書くものが、文書かテストかの違いです。受け入れ条件1つをテスト1本にすれば、両方を同時に使えます。

Q. 仕様書はどこまで細かく書けばよいですか？ A. 受け入れ条件を読んだ2人が同じテストを書ける細かさが目安です。数・日数・表示する文・うまくいかない場合の応答を書きます。

Q. 途中で仕様が変わったときはどうしますか？ A. 先に文書を直し、対応の確認を回してから、影響するタスクをやり直させます。コードだけを直すと、文書と食い違ったままになります。

まとめ

• 仕様駆動開発は、文書を先に書き、それを AI への指示の基準にするやり方です。
• 要件・設計・タスクの3文書を Markdown でリポジトリに置きます。
• 受け入れ条件は EARS 記法で1文ずつ、番号付きで書きます。
• AI には1タスクずつ実装させ、1タスク＝1コミットにします。
• 3文書の対応はスクリプトで確かめます。 問題があれば終了コード 1 で止まります。
• 仕様を変えるときは、コードより先に文書を直します。

参考・出典

• GitHub「Spec Kit」公式リポジトリ（README） https://github.com/github/spec-kit
• Kiro 公式ドキュメント「Specs」 https://kiro.dev/docs/specs/
• Kiro 公式ドキュメント「Feature Specs」 https://kiro.dev/docs/specs/feature-specs/
• Kiro 公式ドキュメント「Steering」 https://kiro.dev/docs/steering/
• Alistair Mavin「EARS」 https://alistairmavin.com/ears/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。