KiroのSpecで「五目並べ」を作ってみる

Transcript

1. Kiro のSpecで「五目並べ」を作ってみる 2026.09.26 Satoshi Kaneyasu
2. 目次 の Spec 駆動開発（＝仕様駆動開発）とは Vibe Coding との対比 仕様駆動開発は何もルールがない場合の型である AI 駆動開発・仕様駆動開発における要件定義とは 要件定義の粒度はツールにも現れている Kiro の Spec のディレクトリ構成 Kiro の Spec でローカルルールの追加までやってみるとしたら Vibe で Steering を作る Spec で実装する Spec で一番見るべきは requirements.md Kiro に採用されている EARS 記法 Spec の design.md と tasks.md はどれぐらい時間をかけて見るべき？ 新規追加と修正は必ずコミット分けること まとめ Kiro
3. Kiro のSpec駆動開発（＝仕様駆動開発）とは 「何を作るか」を先に文書化し、それを正解として実装していく開発スタイルです。
4. Vibe Coding との対比 Vibe Coding 進め方 強み 弱み 会話しながら少しずつ すぐ動くものが見える 決めごとが会話に埋もれる 駆動開発 要件→設計→実装の順に固める 認識のズレが早期につぶせる 最初に考えるコストがかかる Spec
5. 仕様駆動開発は何もルールがない場合の型である 慣れた人なら Vibe の途中で「仕様書を書かせてからそれを基に実装して」と自然に誘導できます。 つまり Vibe でも仕様書を挟む進め方はできます。 問題は、それが属人的なスキルである点です。 全員がその進め方を知っているチームは作りにくい 仕様書を挟むタイミングも、粒度も、人によってバラバラになる 仕様駆動開発という「型」があると、チームで共通のやり方を持てます。 Kiro の Spec はその型をツールとして提供しています。
6. AI 駆動開発・仕様駆動開発における要件定義とは 要件とは「やりたいこと」ではありますが、 AI 駆動開発・仕様駆動開発における要件は 「売上を◦◦%あげたい」 というレベルではありません。 少なくとも 「売上を◦◦%あげるために、△△の効率をあげるため、□□を自動化する」 ぐらいの粒度が必要です。 実案件では 「□□を自動化するためのXX機能を作る」 レベルまで分解してAIに投入するのが現実的です。 これぐらいでないと出来上がるものが大きすぎて人の方がレビューしきれなくなります。
7. 要件定義の粒度はツールにも現れている 仕様駆動開発のツールにも、この傾向は現れています。 GitHub Spec Kit の場合は、 プロジェクトにおける要件定義フェーズで定めた各要件ごとに開発を回すイメージとなっています。 AWS AI-DLC の場合、一般的な要件定義を AI と一緒にやるような流れになっていますが、 「一緒にやる」でありざっくりしたものを入れればいい感じにやってくれる… というイメージではありません。 また、「一緒にやる」は開発者以外も含む関係者で画面を見ながらAIとやりとりするプロセスです。 ざっくりとした要件だとかなり時間がかかります。 このことからもAI駆動開発・仕様駆動開発における要件定義は「かなり小さい単位の要件」 でないと回らないと捉えた方がよいでしょう。
8. Kiro のSpecのディレクトリ構成 の仕様駆動開発は、機能をSpecという単位で開発します。 Spec は Spec ごとにディレクトリが分かれ、中に 3 つのファイルが生成されます。 Kiro （リポジトリルート） / ├── index.html └── .kiro/ └── specs/ 機能①：基本ゲーム │ ├── requirements.md # 何を作るか │ ├── design.md # どう作るか │ └── tasks.md # 何をするか（AIがここを順に実行） └── local-rules/ # 機能②：ローカルルール追加 ├── goboard/ # ├── requirements.md ├── design.md └── tasks.md つのファイルを順に承認していくことで、AIが tasks.md に沿って実装を進めます。 コードを書くのは最後だけ、それまでは「言葉で合意する」プロセスです。 3
9. Kiro のSpecでローカルルールの追加までやってみるとしたら 今日の Vibe ハンズオン（STEP 1〜5）を Spec に置き換えると、こう対応します。 ハンズオン STEP 1 ：目的の共有 STEP 2 ：実装方針の作成 STEP 3 ：最低限の実装 STEP 4 ：ローカルルールを足す 役割 Vibe Steering Steering 実装 実装 での対応 Vibe で Steering を作る Vibe で Steering を作る Spec （ goboard ）で実装する Spec （ local-rules ）で実装する Spec ・2 はプロジェクトの方針・ルールなので Steering に書くのが自然です。 Steering 自体は Vibe で会話しながら作るのがよいでしょう。 STEP 3 以降が Spec の出番です。 STEP 1
10. やり切った場合のディレクトリ構成 （リポジトリルート） / ├── index.html └── .kiro/ ├── steering/ │ └── product-overview.md └── specs/ ├── goboard/ │ ├── requirements.md │ ├── design.md │ └── tasks.md └── local-rules/ ├── requirements.md ├── design.md └── tasks.md # 目的・技術方針・禁止ワードなど（STEP 1・2 相当） ：基本ゲームの実装 # STEP 3 ：ローカルルールの追加 # STEP 4
11. Vibe で Steering を作る はプロジェクト全体に適用されるルール・方針です。 まず Vibe で会話しながら内容を決め、 に記録します。 プロンプトの例はこちらをご覧ください。 Steering .kiro/steering/product-overview.md
12. Spec で実装する Steering ができたら、Specで開発を進めていきます。
13. Spec で一番見るべきはrequirements.md は、 次の要素で構成されます。 requirements.md 要素 Introduction Glossary Requirements User Story Acceptance Criteria 何が書かれるか この機能の概要と目的。何のための機能かを一段落で示す 用語集。プロジェクト固有の言葉（例：GoBoard、活三）の定義をそろえる 要件の一覧。1件ごとに User Story と Acceptance Criteria を持つ 要件の目的。「誰が・何をしたい・なぜ」の形で書く 受入基準。その要件を満たしたと言える条件を EARS 記法で列挙する 言葉のニュアンスがずれていると、実装にもずれが生じます。 Glossary の説明に納得できるか・漏れがないか、を確認すると良いです。
14. User Story User Story と Acceptance Criteria は「誰が・何をしたい・なぜ」の形で書かれます。 （例：プレイヤーが石を置けるようにしたい。そうすることで手番を進められる） Acceptance Criteria は、 1 つの User Story につき複数列挙されます。 プレイヤーが空きマスをクリックしたとき THEN システムはそのマスに石を置く IF すでに石があるマスをクリックしたなら THEN システムはその操作を受け付けない WHEN 「何を作るか」が一つずつ明文化されているので、次の 2 点を確認します。 自分がやりたいことが書かれているか 何をもって完了と判断するか（受け入れ基準）が自分の認識と合っているか ここで認識がそろっていれば、実装後に「思ってたのと違う」が起きにくくなります。 OK ならば、 requirements.md の Continue で次に進めます。
15. Kiro に採用されているEARS記法 （Easy Approach to Requirements Syntax）は、 要件を曖昧さなく書くための5つの文型です。 2009 年にロールス・ロイス社の Alistair Mavin らが提唱し、 2019 年の IEEE 要件工学会議で「 10 年間で最も影響力のある論文」を受賞しています。 EARS
16. 5 つの文型 パターン 常時 イベント駆動 状態駆動 オプション機能 異常系 テンプレート システムは〜する 〜のとき、システムは〜する 〜の間、システムは〜する 〜がある場合、システムは〜する もし〜なら、システムは〜する 使う場面 常に成り立つこと 操作・出来事への反応 ある状態が続く間の動作 特定機能がある場合のみ 例外・エラーの場合
17. AI に開発させるうえでのメリット は曖昧な指示を推測で補います。 EARS の文型は「誰が・どの条件で・何をすべきか」を 1 文に収めるので、 推測で埋める余地が減ります。 また、1文が1つの動作に対応するため、そのまま確認（テスト）項目になります。 「実装できた」の判断基準が最初から明文化されている状態で作業を渡せます。 AI
18. ツール別のEARS対応状況 Kiro の Spec ツール GitHub Spec Kit （aws-samples） AWS AI-DLC （ awslabs 公式） AWS AI-DLC の扱い 公式採用。requirements.md の受け入れ基準が EARS ベース 標準では非採用。EARS 統合は Issue 提案中、拡張で対応可 ADR-020 として EARS を正式採用（ 2026 年 7 月） 標準として明示はなし。ワークフロー主体の方法論 EARS
19. のdesign.mdとtasks.mdはどれぐらい時間をかけて見る べき？ Spec 個人的には、半日から1日ぐらいかけて見るものと思っています。 時間がかかるものなので、レビューの挙げ方はチームで協議してください。 自分が説明できないものをレビューに挙げるのはマナー違反です。 Spec 駆動開発（仕様駆動開発）は、着実性を重視している手法で、 Vibe より何倍も時間がかかります。 故に、属人性の排除やスキルの補完を求めるのならともかく、 速さを求めること自体がちょっと違います。
20. 新規追加と修正は必ずコミット分けること で修正すると、修正の過程でUIが微妙に変わったりしませんでしたか？ AI は指示した箇所以外も割と豪快に直します。 意図していない変更が混入しやすいので、変更はレビューを通すのが基本です。 今回の五目並べで言うと、次のような進め方が安全です。 Vibe タイミング 基本ゲームが動いた時点 ローカルルールを追加するとき やること 一旦コミットして動作確認済みの状態を固める PR を切ってレビューを挟む に変更させる前に「何を変えるか」を確認し、 変更後も「意図しない箇所が変わっていないか」を確認する習慣が重要です。 AI
21. ローカルルール追加時に修正方法とリグレッションテストを 要件に入れる ローカルルールは既存のゲームロジックに影響します。 Spec で実装するなら、 requirements.md の段階で、 影響範囲を最小にする修正方法をとること、リグレッションテストの要件も入れます。 1. 2. 修正方法：既存のゲームロジックへの影響範囲を最小にする形で追加すること リグレッションテスト：既存の基本ルール（石を置く・手番交替・勝敗判定）が 従来通り動作することを受け入れ基準として明記すること 「影響範囲を最小にすること」「壊れていないこと」を要件として明文化することで、 AI がテストケースを生成する際の基準にもなります。
22. まとめ は「何を作るか」を先に固めてから実装する型。チームで共通のやり方を持てる プロジェクト全体の方針（技術スタック・テスト方針など）は Steering に、 機能ごとの要件は Spec に書く Spec で一番見るべきは requirements.md で「やりたいことが書かれているか」 「完了の判断基準が合っているか」を必ず確認する 新規実装と修正は必ずコミットを分け、変更は PR でレビューを挟む Spec