Kiroの仕様駆動開発を2案件回して辿り着いた運用設計

2026/04/15 Fusic Tech Liveの登壇資料

Transcript

1. ©Fusic Co., Ltd. 0 2026/04/15 Fusic Tech Live Kiroの仕様駆動開発を2案件回して辿り着いた運用設計 株式会社Fusic データソリューション部門 dobado 森優斗
2. ©Fusic Co., Ltd. 1 1. Fusicにおける仕様駆動開発の現状整理と、Kiroの仕様 駆動開発との違い 2. KiroのSpec(仕様)について解説 3. KiroのSpec以外の機能解説 4. Kiroに加えた、森のオリジナルルール 5. 仕様駆動開発でよくあること
3. ©Fusic Co., Ltd. 2 森 優斗 Mori Yuto ❖ I am - データソリューション部門 dobadoチーム所属 - ギターと作曲が趣味です ❖ Skills - AWS (Web) / SORACOM / Ruby on Rails / Next.js ❖ Comment - JAWSとかにたまにいます！ - 今度のTSKaigiに行きます！ 自己紹介 はじめに 株式会社Fusic @福岡 データソリューション部門 エンジニア @kotukotuganbad
4. ©Fusic Co., Ltd. 3 Fusicにおける仕様駆動開発の現状整理と Kiroの仕様駆動開発との違い 1
5. ©Fusic Co., Ltd. 4 受託案件A Fusic仕様駆動開発 受託案件B 受託案件C 受託案件D Kiro 仕様駆動開発 AI-DLC Fusicの中での「仕様駆動開発」の動き
6. ©Fusic Co., Ltd. 5 仕様駆動開発という言葉には、二つの意味が混在しています
7. ©Fusic Co., Ltd. 6 1) 仕様＝対外的な合意文書（要件定義書・仕様書）としての「仕様」 「仕様駆動」と言うと、顧客・ビジネス側との合意形成に使う仕様書を指すことも多い です。 2) 仕様＝SSoT（Single Source of Truth） 近年の 生成AI 文脈だと「仕様が真実で、コードは仕様の表現（生成物）に寄せる」と いう主張があります。 この意味では Kiro も同じ方向で、仕様→計画→タスクという流れで「生成AIによる生成 物とのブレを抑える」という考え方です。
8. ©Fusic Co., Ltd. 7 1) 仕様＝対外的な合意文書（要件定義書・仕様書）としての「仕様」 「仕様駆動」と言うと、顧客・ビジネス側との合意形成に使う仕様書を指すことも多い です。 仕様(合意文書) そのまま渡せる 合意文書を元に開発
9. ©Fusic Co., Ltd. 8 1) 仕様＝対外的な合意文書（要件定義書・仕様書）としての「仕様」 「仕様駆動」と言うと、顧客・ビジネス側との合意形成に使う仕様書を指すことも多い です。 仕様(合意文書) そのまま渡せる 合意文書を元に開発 Fusic仕様駆動開発
10. ©Fusic Co., Ltd. 9 2) 仕様＝SSoT（Single Source of Truth） 近年の 生成AI 文脈だと「仕様が真実で、コードは仕様の表現（生成物）に寄せる」と いう主張があります。 この意味では Kiro も同じ方向で、仕様→計画→タスクという流れで「生成AIによる生成 物とのブレを抑える」という考え方です。 合意文書 形を整えたら 渡せる 仕様を元に開発 仕様
11. ©Fusic Co., Ltd. 10 2) 仕様＝SSoT（Single Source of Truth） 近年の 生成AI 文脈だと「仕様が真実で、コードは仕様の表現（生成物）に寄せる」と いう主張があります。 この意味では Kiro も同じ方向で、仕様→計画→タスクという流れで「生成AIによる生成 物とのブレを抑える」という考え方です。 合意文書 形を整えたら 渡せる 仕様を元に開発 仕様 Kiro式 仕様駆動開発
12. ©Fusic Co., Ltd. 11 2) 仕様＝SSoT（Single Source of Truth） 去年のAWS Summitで高野さんがお話ししていた、Every thing as Code https://www.youtube.com/watch?v=BFiQUq6bGIo
13. ©Fusic Co., Ltd. 12 受託案件A Fusic仕様駆動開発 受託案件B 受託案件C 受託案件D Kiro 仕様駆動開発 AI-DLC Fusicの中での「仕様駆動開発」の動き
14. ©Fusic Co., Ltd. 13 KiroのSpec(仕様)について解説 2
15. ©Fusic Co., Ltd. 14 Kiro2種類あります
16. ©Fusic Co., Ltd. 15 Kiro2種類あります
17. ©Fusic Co., Ltd. 16 要するに AIが一貫性を持って保守性の高いコーディングをし続けてハッピー AI が勝手に解釈して暴走しない 設計・タスク化まで落として、実装を進めやすくする タスク実行・進捗追跡まで一体化する KiroのSpec(仕様)の目的
18. ©Fusic Co., Ltd. 17 仕様を元に開発 仕様(specs) Kiro式 仕様駆動開発 requirements.md = 要件定義書 何を作るか。 design.md = 設計書 どのように作るか。 task.md = 実装タスク どのように作業するか。
19. ©Fusic Co., Ltd. 18 仕様(specs) Kiro式 仕様駆動開発 specs/配下に 機能ごとに3つが存在する requirements.md = 要件定義書 何を作るか。 design.md = 設計書 どのように作るか。 task.md = 実装タスク どのように作業するか。 機能ごと！
20. ©Fusic Co., Ltd. 19 Kiro式 仕様駆動開発 requirements.md = 要件定義書 「何の機能か」を自然言語で記載。 Lambdaを使う、などの技術詳細は記 載しない。利用者が何ができるかの視 点がGood EARS記法で記載することで自然言語 の曖昧さをカバー。 EARS記法とは https://iret.media/181651
21. ©Fusic Co., Ltd. 20 Kiro式 仕様駆動開発 design.md = 設計書 「requirementsの内容をどのように 実装に落とし込むか」を記載。 Lambdaを使うなどの技術に踏込む アーキテクチャやコンポーネント設計、 テスト戦略など ADRの役割を担っている。どういっ た経緯でなぜそうしたかを残していく。
22. ©Fusic Co., Ltd. 21 Kiro式 仕様駆動開発 task.md = 実装手順 「designの内容からどのように手を 動かすのか」を記載。 非エンジニアが読んでも ? の領域 task.md と コード はほぼ1対1なので、 完了したら残さなくても良いのでは？ と森は考えている(後述) Devinに渡したい時は細かめにタスク を切ってプルリクエストの粒度を調整 するのがおすすめ
23. ©Fusic Co., Ltd. 22 Kiro式 仕様駆動開発 Specモード チャット欄で「Spec」モードから起動すると、requirements → design → task の順番で作成補助をしてくれます。壁打ちをしながらspecを定義していきます。結構 ちゃんと時間がかかる工程です。
24. ©Fusic Co., Ltd. 23 KiroのSpec以外の機能解説 3
25. ©Fusic Co., Ltd. 24 hooks 決まったプロンプトを実行する specs Kiroのメイン機能。機能単位ごとのドキュメント requirements.md = 要件定義書 design.md = 設計書 task.md = 実装タスク steering 操舵の意味。Kiroに読み込ませたいContextを定義 基本機能はSpec、Hook、Steeringの3つです
26. ©Fusic Co., Ltd. 25 Kiro式 仕様駆動開発 hooks 決まったプロンプトを実行する hooks/AI生成コード自動チェック.hook hooks/ 厳しいレビュー.hook 事前に定義しておいた厳し目のレビューを実行 レビューのhook実行して あぁ、これね 実装終わった！ 実装終わるたびに これやって AIがコード生成後毎回、lint formatとか実行
27. ©Fusic Co., Ltd. 26
28. ©Fusic Co., Ltd. 27 Kiro式 仕様駆動開発 steerings 操舵の意味。ルールなどを常にコンテキストに含ませる Claude Code/Cursorのrules、GitHub Copilotのcustom instructions に該当 steerings / 常に必須なルール.md 事前に、AIに守って欲しいルール(steering)を定義 steerings / フロントエンド開発時のルール.md フロントエンドでボタンを作る作業 task.md 常に必須ルールとフロントエンド ルールを前提情報としつつ実装 ルールが守られた生成物
29. ©Fusic Co., Ltd. 28
30. ©Fusic Co., Ltd. 29 Kiroに加えた、森のオリジナルルール 4
31. ©Fusic Co., Ltd. 30 使用してみて感じた Kiroの課題 1. 生成物がいたずらに増えて、レビューが届きにくくなる 2. Specの切り方がとても重要だが、Specを上から一覧できるものがない
32. ©Fusic Co., Ltd. 31 使用してみて感じた Kiroの課題 1. 生成物がいたずらに増えて、レビューが届きにくくなる 1. specsの各ファイルについては原則100行以内とする 2. 該当のspecsの実装が完了したタイミングでtask.mdを削除する 2. Specの切り方がとても重要だが、Specを上から一覧できるものがない 2. doc/requirement.mdを別途作成してspecの全体像を記録する
33. ©Fusic Co., Ltd. 32 Kiro式 仕様駆動開発 specの可読性についてはsteeringsで対応 specsの各ファイルについては原則100行以内 事前に、AIに守って欲しいルール(steering)を定義 該当のspecsの実装が完了したタイミングでtask.mdを削除する taskが全て完了した段階で taskを削除する task.md ルールを守って実装、spec/を管理 specの可読性がキープ
34. ©Fusic Co., Ltd. 33
35. ©Fusic Co., Ltd. 34 Kiro式 仕様駆動開発 プロジェクト全体の概要把握のためにdocs/ requirements.mdを作成。 hookやsteeringによって運用 docs/運用のためのhook specの実装が完了したら実行 specの内容をみて、機能の概要を記載する 機能ごとにspecのパスやBacklogのパスを記載 specの新規追加や更新について履歴を記載する docs/requirements.md 後からアサインする人、記憶をなくした私がHappy
36. ©Fusic Co., Ltd. 35 Kiro式 仕様駆動開発 docs/ requirements.mdはヒューマンライクなspecの地図 Githubのwikiとして育て続ける(workflow) AIライクなものではないので、 Kiroのコンテキストには含めない specの追加やバージョン更新 = 開発状況を俯瞰して把握できる ヒューマンライクなSpecの地図
37. ©Fusic Co., Ltd. 36 それぞれの立ち位置はこんな感じです。
38. ©Fusic Co., Ltd. 37 コード .kiro/spec Backlog 定義 docs/ requirements.md 仕様の合意形成 随時参照(MCP) 参照 実装 常に同期 (Refine, Hook) 更新
39. ©Fusic Co., Ltd. 38 コード .kiro/spec Backlog 定義 docs/ requirements.md 仕様の合意形成 随時参照(MCP) 参照 実装 常に同期 (Refine, Hook) 更新
40. ©Fusic Co., Ltd. 39 開発ルール、開発用doc、保守用docを管理 森(PM) Backlogで仕様を決める→spec定義 (Backlogへのリンクも記載) 開発ルールをsteeringに記載 copilot (レビュー補佐) 森 レビュー .kiroに沿って実装 doc等とずれてないかレビュー、 docとコードを合わせる プルリクエスト task.mdを削除 docs/requirementを更新 specのバージョン管理 .kiroに沿って実装 doc等とずれてないかレビュー、 docとコードを合わせる プルリクエスト copilot (レビュー補佐) task.mdを削除 docs/requirementを更新 specのバージョン管理 他エンジニア 他エンジニア レビュー
41. ©Fusic Co., Ltd. 40 開発ルール、開発用doc、保守用docを管理 森(PM) Backlogで仕様を決める→spec定義 (Backlogへのリンクも記載) 開発ルールをsteeringに記載 copilot (レビュー補佐) 森 レビュー .kiroに沿って実装 doc等とずれてないかレビュー、 docとコードを合わせる プルリクエスト task.mdを削除 docs/requirementを更新 specのバージョン管理 .kiroに沿って実装 doc等とずれてないかレビュー、 docとコードを合わせる プルリクエスト copilot (レビュー補佐) task.mdを削除 docs/requirementを更新 specのバージョン管理 他エンジニア 他エンジニア レビュー
42. ©Fusic Co., Ltd. 41 Devinには自分の目が行き届いたタスクをぽんと投げるだけ 相性がとても良いと感じてます。 Devinは「簡単かつ小さいタスク」でないと結局出戻りが多いという所感
43. ©Fusic Co., Ltd. 42 仕様駆動開発でよくあること 5
44. ©Fusic Co., Ltd. 43 稀によくあること集 想定される質問への回答集
45. ©Fusic Co., Ltd. 44 ん？これじゃダメじゃね？ 仕様(specs) requirements.md = 要件定義書 何を作るか。 ↓ design.md = 設計書 どのように作るか。 ↓ task.md = 実装タスク どのように作業するか。 ↓ コード実装
46. ©Fusic Co., Ltd. 45 requirements.md = 要件定義書 何を作るか。 ↓ design.md = 設計書 どのように作るか。 ↓ task.md = 実装タスク どのように作業するか。 ↓ コード実装 コードに合わせて同期して 仕様(specs)
47. ©Fusic Co., Ltd. 46 requirements.md = 要件定義書 何を作るか。 ↓ design.md = 設計書 どのように作るか。 ↓ task.md = 実装タスク どのように作業するか。 ↓ コード実装 仕様(specs) task完了時の自動レビュー PR時のレビュー ずれとるよ 本当だ、ありがとう
48. ©Fusic Co., Ltd. 47 spec/認証 もうspecあるし、実装も完了したけどどうしようかな やっぱりパスワード変更機能ほしい
49. ©Fusic Co., Ltd. 48 requirementsのバージョンをあげて中身を更新→designに経緯を追記
50. ©Fusic Co., Ltd. 49 design更新の例。これは他のspecの実装の際に不都合が生じたのでspecを更新したものです。
51. ©Fusic Co., Ltd. 50 specのバージョンをあげた際は全て、 doc/requirements.mdに残す。 経緯が全部載った「生きたドキュメント」になる。
52. ©Fusic Co., Ltd. 51 Q.人間もコードを書く？ A.コーディングの大半はAIが担い、一部を人間が書くのがちょうど良いと考 えています。基本AIに書かせてコア部分を人間が握る形です Q.生成物は全部レビューするの？ A.私は、まだ全部レビューするべきだと思っています。責任を取るものにな るので全部ちゃんと読みます。そのためにSpecの内容もヒューマンライク に寄せています。とにかくspecを削りたいという思想に駆られています。 Q.実装は効率化する？ A.わからないです。技術力によると思います。私はCDKの部分は速いけど、 フロントはめっちゃ時間かかります。仕様駆動をしたからと言って、短期的 に開発が効率化することはないと思います。運用保守まで長い目で見たらお 得な気がするってくらいです。型書いてるみたいな感覚。
53. ©Fusic Co., Ltd. 52 Q.品質はあがる？ A. レビュー次第だと思います。仕様のブレ、抜けに気づく機会が多いのはあ りますが、シンプルに生成物が増えるのでレビュー負荷が高いです。そのた めにspecを簡潔にかつ、task.mdを削除する運用をとってます。とにかく specを削りたいです。 Q.やってて楽しい？ A.私は全ての作業履歴をNotionにメモしながら仕事をする人間なので、もの すごく体に馴染んでいます。Kiroの考えがFusic仕様駆動に取り込まれなく ても、.kiroをgitignoreして続けると思います。
54. ©Fusic Co., Ltd. 53 本日の内容について Zenn書いてますので興味のある方はぜひ読んでください https://zenn.dev/fusic/articles/ae90127245999a
55. ©Fusic Co., Ltd. 54 Thank You ご清聴ありがとうございました！！ 気になる方はカジュアル面談お待ちしてます