AI実装による「レビューボトルネック」を解消する仕様駆動開発（SDD）/ ai-sdd-review-bottleneck

◆イベント名
Findy Team+　AI駆動開発の最前線：組織の疲弊を防ぐレビュー負荷経験の実践方法
https://jp.findy-team.io/event/live/review_load_260312/

◆発表タイトル
AI実装による「レビューボトルネック」を解消する仕様駆動開発

◆登壇者
株式会社ラクス　楽楽精算 iOSアプリ開発リーダー　平川 裕多

Transcript

1. AI実装による「レビューボトルネッ ク」を解消する仕様駆動開発（SDD） 2026.03.12 株式会社ラクス　 楽楽精算開発部 開発3課 平川裕多 @hirasan333
2. 2 【 ラクスの提供サービス一覧 】 ITサービスで企業の成長を継続的に支援します!
3. 本日のアジェンダ 1 現状の問いかけと直面した課題 2 アプローチの転換とSDD(OpenSpec)の導入 3 新・開発ワークフローと設計マージ 4 情報の圧縮によるレビュー効率化 5 導入成果とエンジニアの役割 © RAKUS Co., Ltd 1 AI実装による「レビューボトルネック」を解消する仕様駆動開発（SDD）
4. 問いかけと現状 AIで実装スピードは上がりました。 しかし、チーム全体の生産プロセスは「楽に」なりましたか？ © RAKUS Co., Ltd 2
5. 直面した課題（Before） AI実装の加速が生んだ「レビューボトルネック」 大量のAI生成コード確認（意図不明な実装の混入） 仕様の曖昧さに起因する手戻りリスク 「修正指示を出すより、自分で書いた方が早いのでは？」が脳裏に浮かぶ © RAKUS Co., Ltd 3
6. アプローチの転換点 AIエージェントへの指示出し（プロンプト）からの気づき 「〇〇関数を使って」「アーキテクチャはこのパターンで」... これ、実質『設計』を指示してる 【仮説】 指示（仕様）さえ完璧なら、実装は自動的に決まるはず。 © RAKUS Co., Ltd 4
7. コスト曲線 後工程になるほどに手戻りによるコストが増えていく 実装やテストで手戻りが発生した場合、設計修正の何倍もコストがかかる可能性が高い © RAKUS Co., Ltd 3 縦軸: 手戻りにかかるコスト 横軸: 要件定義から実装・テストへ進む工程
8. 解決策：OpenSpec × AI 仕様駆動開発（SDD）プロセスの導入 活用ツール： OpenSpec (OSS/Customized) Markdownベースの構造化された仕様書を、AIと対話的に作成・管理する。 © RAKUS Co., Ltd 5
9. 新・開発ワークフロー 設計をマージして確定させるプロセスへの移行 ※旧フローでは設計書をGoogleドキュメントで作成 実現したい機能 (PBI) 仕様書生成 (mdファイル) 設計レビュー 設計PRマージ AI実装 実装レビュー 実装マージ © RAKUS Co., Ltd 6
10. 設計マージの意味（再現性） 設計PRのマージ ＝ 「実装」のコモディティ化 仕様とタスクが確定していれば、実装フェーズは「誰がやっても（AIがやっても）同じ」状態になる。 実装時の迷いやブレをゼロにする。 © RAKUS Co., Ltd 7
11. 具体的な設計内容(spec.md) #### Scenario: メニュータップで一覧画面へ遷移する - **WHEN** ユーザーがメニュー(type == 10)で「サンプル」をタップする - **THEN** `SampleListView` が 表示される #### Scenario: 「サンプル」以外のメニュータップでは従来通りの画面へ遷移する - **WHEN** ユーザーがメニューで「サンプル」以外（`type != 10`）をタップする - **THEN** 従来通りの画面へ遷移する ### Requirement: 画面表示時に一覧をAPIから取得する `SampleListView` の表示時（`onAppear`）に、`SampleStore` を通じて `GET /sampleList` APIを呼び出し、サンプル一 覧を取得しなければならない（MUST）。 API呼び出し中は処理中状態（`isProcessing = true`）となり、インジケーターが表示される。 © RAKUS Co., Ltd 7
12. 具体的な設計内容(tasks.md) ## 6. SampleListView / SampleInputView の作成 - [ ] 6.1 `View/Sample/SampleList/SampleListView.swift` を新規作成する。`ListViewProtocol` に準拠し、 `@State` で `SampleListViewState` を保持する。`BaseNavigationView` でヘッダーを表示し、 `SampleListRowView` で各行を描画する - [ ] 6.2 サンプル行タップ時に `SampleInputView` へ遷移する `NavigationStack` + `navigationDestination` を実 装する - [ ] 6.3 `View/Sample/SampleInput/SampleInputView.swift` を新規作成する。タイトルのみ表示する空の画面とする © RAKUS Co., Ltd 7
13. OpenSpecによる仕様書作成詳細 spec.mdやtasks.md作成の流れ OpenSpec スラッシュコマンド PBIを元に ドラフト設計PR作成 既存コード探索 不明点質問 mdファイル作成 依頼者レビュー フィードバック修正 PR更新 レビュー依頼 © RAKUS Co., Ltd 6
14. なぜ効率的なのか？（情報の圧縮） レビュー対象の圧縮 Before (実装後) 大量のコードから論理を追う 10行以上の実装コードを確認 意図不明な実装が混入しやすい 実装時の手戻りリスク有り After (設計段階) 少ない情報量で論理を担保 1〜2行の仕様記述を確認 設計段階で誤りを潰せる 後工程の手戻りを防げる © RAKUS Co., Ltd 8
15. 実装フェーズでの確認事項 実装後のコードレビューはどう変わるか？ Q. ロジックの正当性は？ A. 設計で担保済みのためスムーズ Q. 実装後の確認ポイントは？ A. 仕様書通りか・ヌケモレはないか © RAKUS Co., Ltd 9
16. 成果と副次的効果 実装手戻りの減少、設計力強化 良い負荷 設計レビューはシニアの思考をメンバーに共有する場（ペア/モブ設計）となる。 議論ログの資産化 設計時の議事録がAIナレッジベースとして活用可能に © RAKUS Co., Ltd 10
17. 成果と副次的効果2 コンテキスト蓄積、並列化 コンテキスト更新が同時に可能 OpenSpecは実装後のアーカイブで、仕様書がドキュメントとして残る。 並列作業の足がかり 実装時点やることは詳細に決まっているため、必ず人がAIとペア実装する必要はない。 © RAKUS Co., Ltd 10
18. 課題 不確実性が高い作業には向かない やってみないとわからない作業は設計しにくく、タスクを小さくしたり設計時に調査が必要 機械的な検証（Linter/テスト）が効かない コードとは異なり、仕様書（自然言語）の段階ではLinterやテストによる自動検知不可 論理破綻やヌケモレの発見が人間のレビュー力に依存 © RAKUS Co., Ltd 10
19. AI時代こそ、人間は「設計」に還ろう AIは優秀だが指示（仕様）がなければ迷子になる。 設計PRをマージして、実装を「作業」化し、手戻りを防止。 急がば回れ（SDD）で仕様を固めることが、最短のリリースである。 © RAKUS Co., Ltd 11 株式会社ラクス 楽楽精算開発部 開発3課 平川裕多 @hirasan333