仕様駆動開発入門 (何を作るかを先に決めて渡す) | 目指せ Kiro マスター 05

AI エージェントに大きな仕事を頼むとき、何を作るかを先に決めて渡すための入門です。仕様を先に書くと人が手ですることが増えますが、その多くを Kiro の Spec が受け持ちます。3 つの文書 (requirements.md、design.md、tasks.md) の流れを、会議室の予約アプリを例に、実際の Kiro IDE と Kiro CLI の画面で追います。要件の書き方 (EARS)、要件の分析、性質のテスト、Bugfix Spec、Quick Spec、Plan mode の使い分けまで扱います。2026 年 11 月時点 (Kiro IDE 1.4、Kiro CLI 3.1)。シリーズ「目指せ Kiro マスター」の 05 (使いこなす) です。

Transcript

1. ⽬指せ Kiro マスター 使いこなす 仕様駆動開発⼊⾨ 何を作るかを先に決めて渡す 2026-11 時点 (Kiro IDE 1.4、Kiro CLI 3.1、Kiro Crew 0.12) 05 2026 年 11 ⽉ 稲⽥ ⼤陸 アマゾン ウェブ サービス ジャパン © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1
2. はじめに ⾃⼰紹介 稲⽥ ⼤陸 いなだ りく (いなりく) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 製造業のお客様を中⼼に⽀援 最近の取り組み AI 駆動開発ライフサイクルの推進 Kiro と AWS Amplify の情報発信 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. X @inada_riku Speaker Deck speakerdeck.com/inariku Zenn zenn.dev/inariku GitHub github.com/inariku 2
3. はじめに シリーズの中の位置 いまは 05 仕様駆動開発⼊⾨、次は 06 Steering と Hook はじめる 01–04 使いこなす 前に読む 01 Kiro ⼊⾨ 05–09 ⼿を離す 05 仕様駆動開発⼊⾨ 次に読む 10–12 会社に⼊れる 13–14 アップデート編 10 ⻑い仕事を任せる 13 Kiro を会社に⼊れる 2026.10 14 からの移⾏ Amazon Q Developer 2026.11 02 Kiro IDE ⼊⾨ 06 Steering と Hook 11 Kiro Crew ⼊⾨ 03 Kiro CLI ⼊⾨ 07 MCP と Powers 12 Kiro Crew の Bot 04 Kiro Web ⼊⾨ 08 カスタムエージェント 毎⽉増える Skill と 09 Kiro を使うコツ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 3
4. はじめに この資料で分かること ⼤きな仕事は Spec で 3 段に分け、各段で⼈が直してから進める 1 Spec は requirements.md、design.md、tasks.md の 3 つで、何を、どう、どの順で 作るかを残す。 2 仕事の形で、Feature Spec、Bugfix Spec、Quick Spec、Plan mode を選ぶ。 3 Kiro が EARS で書いた要件を⼈が直し、性質のテスト（IDE）で確かめる。 前に読むとよい資料: 01 Kiro ⼊⾨ 例題は会議室の予約アプリ。30 分単位で、同じ部屋の同じ時間は 1 件だけ。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 4
5. 1 なぜ仕様を先に書くか チャットだけで作ると 決めたことがチャットに埋もれ、あとから「なぜこうしたか」が分からなくなる 新⼈に⼝頭で仕事を頼むと、何を決めたかは 残らない。 エージェントとのチャットも同じ。 予約の画⾯を作って ちょうどの時刻は なぜ OK にした︖ 30 分単位にして 「30 分単位」「終わりちょうどは OK」と 途中で決めても、⻑い会話のあちこちに 散らばる。 あとから読む⼈は、最後の決定を会話から 探すことになる。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. ボタンの⾊を変えて 終わりちょうどは OK あとから読む⼈ 決めたことは 会話のあちこち イメージ図 5
6. 1 なぜ仕様を先に書くか 仕様駆動開発 仕様を先に書き、エージェントへの頼みと、確かめる基準の両⽅に使う 仕様（Spec） ① 頼みとして渡す コードを書く コード Kiro ② 確かめる基準にする ③ テストで テスト 確かめる 仕様は、⼈が読んで直せる Markdown の⽂書。Kiro では Spec と呼び、.kiro/specs/ に置く。 Kiro は⽂書の型と段ごとの承認（Quick Spec では省く）を持ち、コードとテストも書く。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 6
7. 1 なぜ仕様を先に書くか Spec の機能が受け持つこと ⼈が⼿ですることを、Kiro の Spec が受け持つ Spec の機能なしで⼈がすること（⾒⽴て） Kiro の Spec では くわしく ⽂書の型を⽤意する 3 つの⽂書を順に作る 8 枚⽬ 要件の番号をタスクに書き写す タスクが要件につながる 16 枚⽬ 要件を直したら設計とタスクも直す 頼むと設計を合わせ、Sync Files でタスクを⾜す 23 枚⽬ 要件から性質を考え、テストを書く 要件から性質を取り出し、テストを作る（IDE） 18 枚⽬ 左は⼀般論（この資料の⾒⽴て）。どちらでも、読んで直すのは⼈。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 7
8. 2 Spec の形 Spec の 3 つの⽂書 requirements.md、design.md、tasks.md の順に作り、前の⽂書が次の材料になる .kiro/specs/<名前>/ requirements.md design.md tasks.md 何を作るか どう作るか どの順で作るか ユーザーストーリーと 受け⼊れ基準 直して 承認 部品、データの形、 エラーの扱い、テスト 直して 承認 ⼩さなタスクと、 実装 つながる要件の番号 おばけは Kiro が書く所、紫は⼈が決める所 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 8
9. 2 Spec の形 始め⽅の選び⽅ IDE の最初の画⾯の 4 つから選ぶ。Plan mode だけは Spec の⽂書を作らない Feature Spec Bugfix Spec Quick Spec Plan mode 向く仕事 新しい機能 バグの直し よく分かった機能 15〜60 分の作業 作る⽂書 3 つの⽂書 bugfix.md など 3 つ 3 つを続けて作る なし（会話の中） 承認の段 段ごとに承認 段ごとに承認 なし（先に質問） 計画を承認 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 9
10. 2 Spec の形 要件からか、設計からか 何をしたいかが決まっていれば要件から、作り⽅が決まっていれば設計から始める 要件から Requirements-First requirements.md design.md tasks.md 実装 design.md requirements.md tasks.md 実装 何をしたいかが 決まっているとき 設計から Design-First 作り⽅が 決まっているとき 設計からは、性能の条件が厳しいときや、設計図を持ち込むときに向く。 始めるときに Kiro が聞く（既定は設定で決められる）。あとから変えられない。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 10
11. 3 例題で Feature Spec を通す 例題の頼み 「会議室を 30 分単位で予約したい。同じ部屋の同じ時間に 2 件⼊れない」と頼む IDE のチャットの最初の画⾯で Spec を選ぶ （右上）。ほかの 3 つも同じ欄にある。 頼みは短くてよい（右は 3 ⽂）。既存の コードなら、関係するファイルを # で付ける。 右下の Autopilot は変更ごとの承認を省く。 オンでも段ごとの承認は出た。初めてなら オフが向く。 例題は⼟台とテストの道具を⼊れたリポジトリ。 IDE と CLI で進めた。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 11
12. 3 例題で Feature Spec を通す 要件の書き⽅（EARS） 「WHEN … THE SYSTEM SHALL …」の形で、1 ⽂に 1 つの振る舞いを書く requirements.md の受け⼊れ基準は EARS（Easy Approach to Requirements Syntax）の形。WHEN が条件、SHALL が そのときの振る舞い。 1 ⽂に 1 つなので、テストにしやすい。下は例題の要件 3 で、断る条件は IF … THEN の形（1）。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 12
13. 3 例題で Feature Spec を通す 要件を直してから進む ⾜りない条件をチャットで⾜し、承認してから設計に進む Kiro が書いた要件を読み、⾜りないものを⾜す。 例題では「過去の時刻は断る」「予約者の名前」 「会議の件名」を⾜した。 右は、設計を作ったあとに件名を⾜したとき。上が⾃分の 答え、下が Kiro の返事と次の選択肢。 承認は、⽂書の右上の Continue か、チャットの次の 選択肢（Generate Tech Design など）を押す。 ⽂書の Review のボタンから、⾏にコメントを付けて まとめて送ることもできる。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 13
14. 3 例題で Feature Spec を通す 要件の分析 設計の前に、⽭盾、あいまいな⾔葉、抜けた条件を Kiro に探させる IDE では Analyze Requirements を選ぶ。 要件の全体から、⽭盾、あいまいさ、抜けた 境界を探す。 例題では要件 3.5「同時の申し込みは 1 件だけ保 存」の誤りを⾒つけた。A と B、B と C が重なっ ても、A と C は重ならない（右）。 Kiro の質問に答えると requirements.md が 直る。数分かかる。 Kiro CLI の /spec analyze_requirements の結果（抜粋） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 14
15. 3 例題で Feature Spec を通す 設計の⽂書 部品、データの形、エラーの扱い、テストの⽅針が書かれる 要件を承認すると、Kiro が design.md を書く。直したいときは、ここで直してから承認する。 下は例題の design.md の概要。今のコードを踏まえ、⼊⼒の判定を純粋な関数にまとめる、と書かれた。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 15
16. 3 例題で Feature Spec を通す タスクの⽂書 実装は、要件の番号とつながった⼩さなタスクに分かれる 例題の tasks.md では、各タスクの下に満たす要件の番号が書かれた（下の _要件: 1.1_）。 Run all tasks は必須のタスクだけ流す。任意の性質のテストは、タスクの段で必須にするか 1 つずつ流す。 既存のコードで済んでいるタスクは、Sync Files を押すと済みの印が付く。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 16
17. 3 例題で Feature Spec を通す タスクを流す まとめて流すと、依存のないタスクは同じ波に⼊り、並べて流れる 1 つだけ流すときは、tasks.md のタスクの 上の Start task を押す。 Run all tasks では、Kiro がタスクの依存を 調べ、依存のないものを同じ「波」にまとめて 波1 波2 波3 1.1 2.1 5.1 部屋の定数 ⼊⼒の判定 1.2 3.1 API 同時に流す。波は順に進む。 流し終えたら、変更とテストの結果を⾒てから コミットする（この資料のすすめ）。 時刻の関数 保存先 同じ波のタスクは同時に流れる © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. イメージ図 17
18. 4 要件をテストで確かめる プロパティベーステスト 性質のテストは、「どの 2 件も重ならない」のような決まりを、たくさんの⼊⼒で確かめる 例のテスト 性質のテスト ⼈が思いついた例を、1 件ずつ書く どの予約の組み合わせでも、 A 室 10:00〜10:30 と 10:15〜10:45 断る A 室 10:00〜10:30 と 10:30〜11:00 ⼊れる A 室と B 室の 10:00〜10:30 ⼊れる 同じ部屋の 2 件は時間が重ならない ⼊⼒を何百通りも作って試す 性質とタスクをつないで結果を⾒せる画⾯は IDE のみ。例題では CLI もテストのコードを書いた（19） © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 18
19. 4 要件をテストで確かめる 性質が破れたとき 反例は⼩さく縮めて⽰されるので、コード、テスト、要件のどれを直すかを決める 判定をわざと壊すと、性質 7（全件を 1 つずつ⽐べた結果と同じ）が破れ、fast-check が反例を縮めた。 先に 7:30〜8:00 が⼊り、5:30〜7:30 が断られた（数字はミリ秒）。要件 3.3 では受け付けるはず。 コードの誤りなら Kiro に直させ、 要件が違えば 要件を直す。 テストは Kiro CLI が 書いた。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 19
20. 5 ほかの Spec と、⻑く使うこつ Bugfix Spec 今の動き、正しい動き、変えない動きを書いてから直すので、ほかを壊しにくい 前のページで壊した判定を Bugfix Spec で直す。バグは、時刻がちょうど接する予約が断られること 下は Kiro CLI で作った bugfix.md の抜粋。tasks.md には、バグがある、直った、ほかは変わらない、を確かめるテスト が⼊る © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 20
21. 5 ほかの Spec と、⻑く使うこつ Quick Spec と Plan mode よく分かった機能は、Quick Spec で承認の段を⾶ばして 3 つの⽂書を⼀度に作らせる Quick Spec は最初にまとめて質問し、 3 つの⽂書を続けて作り、タスクの ⼀覧で⽌まる。 右は「部屋ごとの空き枠の数」を 作らせた例。 Plan mode は読むだけで調べて計画を 出し、承認で実装に移る。⽂書は 残らない。 誤字や 1 ⾏の直しは、Spec にせず チャットで頼む。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. Kiro CLI の Quick Spec の返事（抜粋） 21
22. 5 ほかの Spec と、⻑く使うこつ 仕様に書くこと ⼿順の細部より、判断とその理由、終わりの条件、作らないことを書く 判断とその理由 終わりの条件 作らないこと 例題では 例題では 例題では 終わりの時刻ちょうどの 「重なる予約は断る」を 繰り返しの予約と、 開始は許す。会議を続けて EARS で書く。その要件の キャンセル待ちは今回は ⼊れたいから テストが通ったら終わり 作らない 要件と設計を承認する前に、この 3 つがあるかを⾒て、なければ⾜す。設計では正しさの性質を読む。 この 3 つと性質を読むことは、この資料のすすめ。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 22
23. 5 ほかの Spec と、⻑く使うこつ Spec を⻑く使うには Spec はコードと同じリポジトリに置き、仕様が変わったら Spec から直す 同じリポジトリ（.kiro/specs/ とコード） ① requirements.md ② design.md ③ tasks.md ④ コードとテスト ⼈が直す Kiro に頼んで合わせる Sync Files でタスクを⾜す タスクを流して確かめる 仕様が変わったら、また ① から Spec は機能ごとに分け、コードと⼀緒にコミットし、チームで読む。例題は予約、空き枠、バグ直しの 3 つ。 #spec を付けると、⽂書を読ませて聞ける。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 23
24. 5 ほかの Spec と、⻑く使うこつ CLI と Web での Spec CLI は /spec new で始め、Web でも Spec を使える。性質のテストは IDE のみ 使えるもの IDE CLI Web ◦ ◦ ◦ 要件の分析 ◦ ◦ ― 性質のテスト ◦ ― ― CLI は /spec new に名前を付けて始める。何を作るかを聞かれ Plan mode ◦ ◦ ― （上）、次に Build a Feature、Fix a Bug、Quick Spec から選ぶ。 Feature、Bugfix、 Quick Spec Web（app.kiro.dev）では⼊⼒欄で Spec を選び、⽂書は Download で保存する。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 24
25. 5 ほかの Spec と、⻑く使うこつ まとめ 要件、設計、タスクを⼈が直してから進め、要件はテストで確かめる 1 Spec は requirements.md、design.md、tasks.md の 3 つで、何を、どう、どの順で 作るかを残す。 2 仕事の形で、Feature Spec、Bugfix Spec、Quick Spec、Plan mode を選ぶ。 3 Kiro が EARS で書いた要件を⼈が直し、性質のテスト（IDE）で確かめる。 次に読む資料 06 Steering と Hook: 決まりと確かめを置く 10 ⻑い仕事を任せる: 実装まで任せる © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 25
26. 付録 始め⽅の⽐べ 種類 Feature Spec 作る⽂書 requirements.md、design.md、 tasks.md 承認の段 段ごとに承認 Bugfix Spec bugfix.md、design.md、tasks.md 段ごとに承認 Quick Spec Feature Spec と同じ 3 つ なし（先に質問） Plan mode なし（計画はチャットの中） 計画を承認して実装へ Spec にしない なし（チャットで頼む） なし © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 向く仕事 新しい機能。要件か設計を 練りたい 原因が分からない、壊すと 困るバグ 範囲が分かった機能、試作 15〜60 分の、調べてから 作る作業 誤字や 1 ⾏の直し 26
27. 付録 例題の要件（抜粋） 要件 3: 重なる予約の拒否（受け⼊れ基準の 1〜3） IF 申し込まれた予約が、同じ部屋の保存済みの予約と重なるとき、THEN THE 予約システム SHALL 予約を保存せず、 時間が重なっていることを⽰すエラーを返す WHEN 申し込まれた予約の開始時刻が、同じ部屋の保存済みの予約の終了時刻と等しいとき、THE 予約システム SHALL その予約を重なりとみなさずに受け付ける WHEN 申し込まれた予約の終了時刻が、同じ部屋の保存済みの予約の開始時刻と等しいとき、THE 予約システム SHALL その予約を重なりとみなさずに受け付ける 性質 6（design.md の「正しさの性質」） どんな申し込みの列を ReservationStore に順に⼊れても、保存された予約は同じ部屋どうしで互いに重ならない（要 件 3.1 と 3.6） ⽂書の⻑さ: requirements.md 127 ⾏、design.md 333 ⾏、tasks.md 91 ⾏ © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 27
28. 付録 ⽤語 ⽤語 Spec（仕様） EARS 意味 機能やバグの直しを、要件、設計、タスクの⽂書にしたもの。 .kiro/specs/ に置く 要件の書き⽅の形。WHEN（条件）と SHALL（すること）で 1 ⽂に 1 つの振る舞いを 書く。IF … THEN もある 受け⼊れ基準 その要件が満たされたと⾔える条件。EARS の形で書かれる 性質（プロパティ） どの⼊⼒でも成り⽴つべき決まり。例「同じ部屋の 2 件は重ならない」 反例 性質を破る⼊⼒。性質のテストの道具がいちばん⼩さい形に縮める 波（wave） 依存のないタスクの組。同じ波のタスクは同時に流れる 承認 ⽂書を読んで次の段に進めること。Continue かチャットの選択肢を押す 任意のタスク Run all tasks では流れないタスク。性質のテストは既定で任意 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 28
29. 付録 出典と参考 kiro.dev のドキュメント「Specs」と、その下のページ（Feature Specs、Bugfix Specs、Quick Spec、Analyze Requirements、Correctness、Best practices） https://kiro.dev/docs/specs/ kiro.dev のドキュメント「Plan mode」「Built-in agents」「Autopilot」 https://kiro.dev/docs/specs/plan/ https://kiro.dev/docs/custom-agents/built-in/ https://kiro.dev/docs/ide/chat/autopilot/ kiro.dev のドキュメント「Upgrade from CLI 2.x」（What's new in V3） https://kiro.dev/docs/cli/v3/ kiro.dev の changelog「Parallel Task Execution, Quick Plan, and Requirements Analysis」（IDE 0.12、2026-05-06。当時は Quick Spec を Quick Plan と呼ん だ） https://kiro.dev/changelog/ide/0-12/ AWS ブログ「チャットから仕様へ : Kiro を⽤いた AI ⽀援開発の深掘り」（2025-09-11） https://aws.amazon.com/jp/blogs/news/from-chat-to-specs-deep-dive/ AWS ブログ「Kiro : コードは仕様と⼀致していますか︖」（2025-11-20） https://aws.amazon.com/jp/blogs/news/property-based-testing/ AWS ブログ「バグ修正と既存アプリの上に構築するための新しい Spec タイプ」（2026-02-19） https://aws.amazon.com/jp/blogs/news/specs-bugfix-and-design-first/ AWS ブログ「Kiro の Spec が速く、そしてスマートになりました」（2026-06-11） https://aws.amazon.com/jp/blogs/news/faster-smarter-specs/ kiro.dev のドキュメントは 2026-11-07 に読んだもの。画⾯は Kiro IDE 1.4.121 と Kiro CLI 3.1.0 で撮った。例題はこの資料のために作った会議室の予約アプリ。 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 29