未踏IT 2025 Demo Day Design as CodeによるSpec-Driven Developmentの実現

未踏ITのDemo Day（成果報告会）で、未踏ITのプロジェクト期間で開発したソフトウェア設計をコード化して検証可能にするライブラリ goat と、goatを用いた設計特化AI Agentの YAGI について発表しました。

Transcript

1. Design as Code による Spec-Driven Developmentの実現 戸田朋花 (Honoka Toda) 株式会社CyberAgent / 株式会社AbemaTV
2. 技術スタック Golang, Kubernetes, AWS, GCP 株式会社CyberAgent / 株式会社AbemaTV hono0130__ hono0130 戸田朋花 ( Honoka Toda ) 得意領域 バックエンド、クラウドインフラ
3. Design as Code - 設計にパラダイムシフトを -
4. ソフトウェア設計の抱える課題 4 設計手法が標準化されていない 設計の検証手段がない 実装との統合が難しい 設計という行為が曖昧で不完全である
5. 現状の設計がもたらす課題 5 設計資料 作成 実装中に 仕様ミス 発覚 実装修正 資料 陳腐化
6. 現状の設計がもたらす課題 6 設計意図と異なる実装による手戻り 統一されてない設計による高い認知負荷 ヒューマンエラーによるミス、曖昧な設計による認識齟齬 人/プロジェクト単位で設計資料が異なる（Excel？PPT?）
7. 流行りの仕様駆動開発(SDD)、 実現できてますか？ 7
8. 仕様駆動開発(SDD)とは 8 SDD は AI が機能開発できる詳細度の仕様(=spec) を 先に明文化してから実装をAIに任せる開発手法 </> Spec Code AI
9. ソフトウェア開発におけるSDDの現実 9 仕様(=spec)は自然言語によるドキュメントにすぎない 正確性の検証は人間のレビュー頼り </> Spec Code AI Specが不正確であれば当然実装も不正確になる
10. ソフトウェア開発におけるSDDの現実 10 仮に Spec が正しかったとしても Spec と実装が一致しているかの検証も難しい </> Spec Code AI ?
11. これらの問題の解決策 Design as Code 11 形式手法 goat 設計をコード化し、検証可能に！
12. 本プロジェクトで 開発したもの - goat -
13. goat とは 13 設計を記述するためのライブラリ Go言語を用いて設計を記述 設計の正しさをモデル検査により検証可能
14. goat のコアバリュー 14 コードを書くような設計体験 設計の正しさの検証 設計と実装の統合 設計を開発サイクルの一部として統合する
15. 15 stateA stateB Event Event stateA stateB Event SteteMachine StateMachine Queue goatによるシステムのモデリング ユーザーはStateMachineとEventを定義してシステムを 表現する
16. システムを構成する サーバー/コンテナ等を表現する 複数の状態を持つことができる 16 goatによるシステムのモデリング StateMachine Event 起動中 停止中 Event Event Event Queue サーバー/コンテナ間の リクエスト/レスポンス等を表現する Queueを介して非同期で送受信する
17. 17 設計記述の流れ 1. StateMachineやEventのスキーマを定義する 2. StateMachineが満たすべきルールを定義する 3. StateMachineの振る舞いを定義する
18. 検証できることの例 - どの状態でも常に成り立つこと - 商品在庫は負の値にならない - P が起きたらいつか Q が起きること - リクエストを送ったら、いつかレスポンスが返る　 - 何度でも繰り返し起きること - 定期レポートが毎週届き続ける - いつか安定して、以降ずっと成り立つこと - 障害が起きても、いつか正常な状態に戻って安定する 18
19. 実装との統合を実現する機能 19 goatの記述からルールベースで スキーマファイルを生成可能 スキーマ生成 e2eテストの生成 ユーザーが指定したリクエストから 仕様を元に計算したレスポンスを 満たすことを確認するテストを ルールベースで生成可能
20. 20 その他機能 goatの記述からルールベースで mermaidによるシーケンス図を生成可能
21. 21 goat が実現すること Before After → 設計が標準化されていない Goによる構造化された記述 設計の検証手段がない モデル検査による自動検証 実装との統合が難しい 生成されたスキーマ・テスト が利用可能 goat によって設計の抱える課題が緩和される
22. Design as Code によるSDDの実現
23. （再掲）仕様駆動開発(SDD)とは 23 SDD は AI が機能開発できる詳細度の仕様(=spec) を 先に明文化してから実装をAIに任せる開発手法 </> Spec Code AI
24. 今までのSDD 24 自然言語による仕様は人間/AIの解釈の違いによる意味 のブレによって伝達ミスを生みやすい 自然言語による 仕様 AI 人間 という 機能を持つ A という 機能を持つ A’
25. 今までのSDD 25 自然言語による仕様は正しさの検証が人間にもAIにも 難しく誤った仕様による手戻りリスクがある 自然言語による 仕様 AI 人間 レビューした結果 正しそう？
26. Design as Code × SDDの可能性 26 コードで表現された仕様が生成AIと人間の間を繋ぐ 厳密な仕様として機能するのでは？ コードによる 仕様 AI 人間 </>
27. Design as Code × SDDの可能性 27 コードによる仕様の意味は構文から確定するため 人間/AIの間で解釈のズレが起きにくい AI 人間 コードによる 仕様 </> という 機能を持つ A という 機能を持つ A
28. Design as Code × SDDの可能性 28 コードによる仕様は機械的に検証可能なので 正しい設計が何かAIにも理解できる AI </> </> 検証が通れば 正しい 検証が通らなければ 正しくない
29. 本プロジェクトで 開発したもの - YAGI PoC-
30. YAGI の PoC 開発 30 要件定義・設計特化のAI Agent YAGI のPoCを開発した CLI型のAI Agent 設計フェーズでのAI活用支援 Spec-Driven Development の実現
31. YAGI の PoC 開発 31 YAGI では対話を通じて実現したいシステムの Design Docs と goat による設計が作成される Design Docs 1. 背景 2. 目標と非目標 3. 設計 4. 検討された代替案 自然言語による設計 コードによる設計
32. YAGI の PoC 開発 32 要件の整理から始め、設計と検証のFBループを回して 曖昧さのない設計ドキュメントを作成する YAGI User goat Design Docs 検証による FBループ 生成 生成 指示 SDDで利用する仕様
33. SDD を実現する AI Agent の開発 33 YAGI による成果物を元に実際の実装に入ることで SDD を実現する </> Code Coding Agent goat Design Docs </> e2eテスト 生成
34. YAGI の PoC 開発 34 YAGIでは以下のフェーズを辿って設計を進める - Requirements Phase - 要件の整理 - Schema Phase - goatで表現するシステムのスキーマの定義 - Spec Phase - goatで表現するシステムの振る舞いの定義 - Rule Phase - goatで表現するシステムのルールの定義 - Documentation Phase - 自然言語による設計
35. デモ 35 以下のテーマでYAGIのデモを行う 会議室予約システムの設計 - 課題 - メール等で会議室予約をした結果、予約の競合が発生している - 要件 - リアルタイムの空き情報取得 - 予約の作成・キャンセル - 二重予約防止 - 非目標 - 外部カレンダーとの連携
36. デモ 36 - Requirements Phase - 要件の整理 - Schema Phase - goatで表現するシステムのスキーマの定義 - Spec Phase - goatで表現するシステムの振る舞いの定義 - Rule Phase - goatで表現するシステムのルールの定義 - Documentation Phase - 自然言語による設計
37. デモ - Requirements Phase 37
38. デモ - Schema Phase 38
39. デモ 39 - Requirements Phase - 要件の整理 - Schema Phase - goatで表現するシステムのスキーマの定義 - Spec Phase - goatで表現するシステムの振る舞いの定義 - Rule Phase - goatで表現するシステムのルールの定義 - Documentation Phase - 自然言語による設計
40. デモ - Rule Phase 40
41. デモ 41 - Requirements Phase - 要件の整理 - Schema Phase - goatで表現するシステムのスキーマの定義 - Spec Phase - goatで表現するシステムの振る舞いの定義 - Rule Phase - goatで表現するシステムのルールの定義 - Documentation Phase - 自然言語による設計
42. デモ - Spec Phase 42
43. デモ 43 - Requirements Phase - 要件の整理 - Schema Phase - goatで表現するシステムのスキーマの定義 - Spec Phase - goatで表現するシステムの振る舞いの定義 - Rule Phase - goatで表現するシステムのルールの定義 - Documentation Phase - 自然言語による設計
44. デモ - Documentation Phase 44
45. 今後の課題 45 実際に使っていただいて改善していくことが課題 https://github.com/goatx/goat goatはOSSとして公開中です↓ 感想・FB等をXでぜひお願いします！！ hono0130__