AI駆動開発で仕様はどこまで書くべきか？ ― 人とAIの責務境界から考える開発プロセスの実践

AIエージェントに設計・実装を任せるため、詳細な仕様を先に定義する「仕様駆動開発」が注目されています。一方で、AIの出力を安定させようとするほど、設計判断や実装方針まで人が仕様に書く必要が生じ、仕様の作成・レビュー負荷が増えてしまいます。 本セッションでは、人が合意・管理すべき範囲を「境界仕様」として定め、その境界内での設計判断や実装をAIエージェントに委譲する開発プロセス「BSDD」を紹介します。20件の実案件への適用結果をもとに、責務境界の定め方、AIの自律実行を支える開発ハーネス、人が確認すべきポイント、導入によって得られた効果と実践上の課題を共有します。

Transcript

1. AI駆動開発で仕様をどこまで書くべきか？ - 人とAIの責務境界から考える 開発プロセスの実践 – 合同会社DMM.com プラットフォーム開発本部 松井高宏 Speaker Deck © DMM 1 CONFIDENTIAL
2. 自己紹介 • • • 松井 高宏｜合同会社DMM.com プラットフォーム開発本部 ユーザーレビュー基盤のバックエンド開発リーダー それと並走し、AI駆動開発の実践・改善・研究に取り組んでいます 業務の取り組み 研究・発表 ユーザーレビュー基盤: 開発・運用 ・人とAIの合意領域に関する研究（優秀論文賞） プロセス改善: AI駆動開発の導入 ・人とAIの責務境界モデルにおける提案（BSDD） © DMM
3. テーマ選定の背景 • • • AI駆動開発ではAI生成の仕様を起点に実装する「仕様駆動開発（SDD）」が広がっている AIを使うことで、詳細な仕様を短時間で大量に作成できる 一方で、仕様が増えるほど、人の理解・レビュー負荷も高くなる プロダクト目的から 仕様をAIが具体化 大量・詳細な仕様書 AI駆動開発では、仕様をどこまで書くべきなのか © DMM
4. 正確で詳細な仕様書は、良い仕様書か？ • 情報は、正確で詳しければよいわけではない 「目的に応じて、必要な情報を選び、抽象化することが重要」である • AIが生成する仕様書も同じで、何のために使うかによって、必要な情報と粒度を変わる 目的地にたどり着きたい 経路と目印を示した「案内図」 © DMM 土地の利用状況を把握したい 建物・道路・緑地を見渡せる「航空写真」
5. では、仕様はどこまで残すべきか？ • • • 仕様を詳しく書きすぎると、仕様が肥大化し、作成・レビュー負荷が高くなる 一方で、書かなさすぎると、必要な文脈がAIに伝わらず、意図しない実装につながる つまり、仕様には「多すぎても少なすぎてもよくない」というトレードオフがある どこまで仕様として決めるべきか？ © DMM 5
6. 今回の仕様駆動開発で工夫したこと • • • 仕様として残す範囲を、関係者で合意が必要な「骨組み」に絞った 振る舞いやAPIなど、関係者で合意すべき事項は人が確定する 内部設計・実装方針は仕様化せず、AIが具体化する 合意すべき 「骨組み」を仕様化 内部設計・実装は AIに委譲 仕様作成・レビュー負荷を抑えながら、意図しない実装も抑える © DMM
7. 関係者間で合意すべき「骨組み」だけを 仕様に残し、その先をAIに任せる。 BSDD（境界仕様駆動開発） シンポジウム発表を元に ①何を仕様として残したか ②その先をどうAIに任せたか を紹介します。 © DMM 7
8. SQiP シンポジウム AI駆動開発における人とAIの責務境界モデルの提案 ― 境界仕様に基づくBSDDの実践 ― 合同会社DMM.com ◦松井 高宏 E-mail： matsui-takahiro@dmm.com © DMM 8 CONFIDENTIAL
9. SQiP シンポジウム 1章. 研究背景と課題 AI駆動開発における仕様と責務境界の問題 © DMM 9
10. SQiP シンポジウム 背景：AI駆動開発とSDDの登場 • 生成AIにより，自然言語から設計・実装できる開発が広がった（Vibe Coding等） • しかし仕様を定めないと，画面項目やAPI設計まで，AIが補完し意図しない実装を招く • そこで，設計意図を事前に仕様化するSDDが登場した 仕様を定めない開発 都度指示 AIが実装 設計判断が見えにくい 意図しない実装 © DMM SDD（仕様駆動開発） 仕様 AIが実装 ◦ 設計意図を共有できる 認識ずれを抑える 10
11. SQiP シンポジウム 課題：仕様範囲の拡大 • SDDは設計意図を明示できる一方，期待どおり実装させると仕様が詳細化しやすい • 具体的には, 内部設計・実装方針まで人の記述範囲が広がる • 結果, 軽量な変更でも仕様が1,000行規模となり, 仕様作成・レビュー負荷が増大した 仕様 AIが実装 背景：人とAIでは前提や解釈を 完全には共有しきれず、その 差を埋めようとする側面がある 再実装 仕様を追記 © DMM 期待と異なる 11
12. SQiP シンポジウム 課題の本質：人とAIの責務境界の曖昧さ • 仕様を定めない開発：人が決めるべき設計までAIに任せ, 意図しない実装を招く • SDD：AIに任せられる事項まで人が仕様を書き, 作成・レビュー負担が増える 仕様を定めない開発 （Vibe Coding等） SDD（仕様駆動開発） AIに任せすぎる 人が書きすぎる 意図しない実装 作成・レビュー負担 共通原因：人とAIの責務境界が曖昧である では，人は何を決め，どこからAIに任せるべきか？ © DMM 12
13. 研究目的 SQiP シンポジウム • 人が確定する範囲と, AIに任せる範囲の責務境界を明確にする開発プロセス Boundary Spec Driven Development：境界仕様駆動開発（BSDD）を提案する 例：API契約のように合意が必要なものは人が確定し, 実装はAIに任せる © DMM 13
14. SQiP シンポジウム 補足１：サービス間合意が必要な開発 • マイクロサービス型の開発を対象とする • 複数のサービス・担当間で、実装前に合意すべき事項が発生する • 本研究では、この事前合意を「サービス間合意」と呼ぶ PO FE サービス 間合意 BE INF © DMM 14
15. 補足２： BSDDの新規性 • • SQiP シンポジウム SDD • 合意事項に加えて, 内部設計・実装方針まで人が仕様として記載 • そのため, 仕様作成・レビュー範囲が広がりやすい BSDD • 人とAIの責務境界を「サービス間合意が必要か」で判断 • 合意が必要な事項 → 人が決定 • 合意不要な内部設計・実装方針 → AIに委譲 → 人の仕様作成・レビュー範囲を縮小 © DMM 15
16. SQiP シンポジウム 2章. BSDDの提案：境界定義層 ① 何を仕様として残すか © DMM 16
17. 人とAIの責務を分けるモデル • SQiP シンポジウム プロダクト目的を起点として人とAIの責務を二層に分ける • 境界定義層（人）：サービス間で事前合意すべき仕様を「境界仕様」と定義する • 実行層（AI）：境界仕様をもとに, AIが設計・実装を具体化する © DMM 17
18. 境界定義層の全体フロー SQiP シンポジウム 境界定義層では、関係者がAIの候補をたたき台に、 合意すべき境界仕様を確定する 1 関係者で要求を持ち寄る 2 AIが境界仕様候補を抽出 3 関係者でレビュー・議論し、 境界仕様として確定 DMMGroup © DMM © DMM 17
19. SQiP シンポジウム 境界仕様の判断基準 • AIが案件の目的・要求から仕様候補を抽出し、2つの基準で記載範囲を判断する 1 2 判定例（API改修案件） この案件で定義すべき対象か？ NO：記載しない サービス間で合意が必要か？ YES：境界仕様 NO：実行層へ委譲 候補 ①定義 ②合意 判定 画面構成 NO − 記載しない API I/F YES YES 境界仕様 内部設計 YES NO 実行層 境界仕様に限定することで, 仕様作成の負荷・レビュー対象を縮小させる © DMM 19
20. SQiP シンポジウム BSDD適用例：一括削除機能の境界仕様 • 管理者が最大1万件の不適切なユーザーレビューを一括削除し，履歴を記録する機能に適用 • 前述の判定基準に基づき、AIが境界仕様候補を抽出 → 関係者が合意して境界仕様を確定 境界仕様 • • © DMM 削除作業の効率化 操作履歴の確保 構造・契約 振る舞い 目的・価値 • • 実行条件 処理の流れ • • • 画面構成 API契約 論理データモデル 20
21. 境界仕様の抜粋：振る舞い / 論理データモデル SQiP シンポジウム 振る舞い 論理データモデル 一括削除の実行条件と、FE・BE間の処理の流れを定義 削除履歴のモデルを定義 ＊重要事項は，UML + Draw.io等で構造化し，人とAIの双方が理解しやすい形で整理 © DMM 21
22. SQiP シンポジウム 境界仕様の抜粋：画面構成 / API契約 画面構成 削除操作と、削除結果・履歴の表示を定義 © DMM API契約 入出力・上限・主要エラー・履歴を定義 22
23. SQiP シンポジウム 3章. BSDDの提案：実行層 ② その先をどうAIに任せるか © DMM 23
24. SQiP シンポジウム 実行層のプロセス • 境界仕様を起点に, AIが主体となり実行計画〜実装・テスト〜PR作成を進める • 人はこれらの実行過程をAIに委ね，実行計画とPRで妥当性を確認する 境界仕様 © DMM AI 実行計画 実装・テスト PR作成 人 実行計画の確認 この間を AIが自律実行 PR確認 24
25. SQiP シンポジウム AIに自律実行させる仕組み • 実行層では、既存のハーネス及びループエンジニアリングの仕組みを採用 • 境界仕様と実行コンテキストを与え、AIはこれらをもとに設計・実装を具体化する 境界仕様 既存コード API/DB定義 開発ルール ① 実行計画 (=何を実現するか) ② 実装エージェント群 実行コンテキスト （=守るべき前提・制約） 修正・再検証 ③ CI・AIレビュー PR作成 OK © DMM 25
26. SQiP シンポジウム BSDD適用例：一括削除機能の実行フロー • 一括削除機能を例に、境界仕様からPR作成までの流れを示す 実行計画 境界仕様 PR 作業内容 エージェント 一括削除機能 PR1 API契約 • Open API • 削除上限 • 画面：結果・履歴 • API入出力 PR2 データ層 • DB・Domain PR3 BE機能 • Use Case・Handler PR4 FE実装 • Storybook PR5 API接続 • API Connect PR3の実行例 Use Case・Handler 実装・テスト CI ・AIレビュー + 実行コンテキスト 人が確認 © DMM PR作成 人が確認 26
27. SQiP シンポジウム ４章. 評価と考察 実案件への適用で何が変わったか a.仕様として残す範囲 → b.人が確認するポイント → c.定量結果 © DMM 27
28. SQiP シンポジウム a.仕様として残す範囲 • 従来は、内部設計や実装方針まで人が仕様として記述していました • BSDDでは、人が書く範囲を境界仕様に絞り、その先はAIが具体化しました 従来 BSDD 境界仕様 境界仕様 人が確定 詳細設計 実装方針 詳細設計 テスト観点 実装方針 内部設計 テスト観点 人が確定 内部設計 AIが具体化 © DMM 28
29. b.人が確認するポイント SQiP シンポジウム • BSDDにより人の確認ポイントは境界仕様・実行計画・PRの3点に集約された • これにより人は、重要な合意・判断に集中することができるようになった © DMM 29
30. SQiP シンポジウム c.評価結果（定量） • 仕様を境界仕様に絞った結果、仕様量・策定時間・実装時間はいずれも縮小した 観点 結果（従来SDDと比較） 仕様範囲 • 1,213行 → 228行（84.5％削減） 仕様策定 • 4h → 1h（75%短縮） 実装時間 • 8h → 6h（25%短縮） 運用（6ヶ月） • 重大事象（※）：観測0件 ※評価対象：仕様20案件／時間比較各8案件／運用8案件×6ヶ月 ※重大事象：本番障害・RB・再合意を要する仕様手戻り © DMM 30
31. SQiP シンポジウム 人が確認する仕様範囲を 境界仕様に絞ることで、 仕様作成・実装の負荷を削減できた また、境界仕様を起点に ハーネスで実行した場合でも、 評価では重大な問題は観測されなかった © DMM 31
32. SQiP シンポジウム 結論 • • BSDDでは, サービス間合意が必要な事項を「境界仕様」として人が確定する • 内部設計・実装方針は、実行層でAIが具体化する • 結果として、人が確認する仕様範囲を絞ることができた 本質は仕様を減らすことではなく、 人が決める範囲とAIに任せる範囲を分離することにある • 今後は適用範囲を広げ、他の開発形態でも有効性を検証する © DMM 32
33. 現在、大規模案件でもBSDDを適用しています 案件 • 画面：約10画面 • API ：約12本 • 関係者：約10名 仕様策定〜関係者合意 約 6 時間 成果物ベースでは 約1人月相当の仕様作成規模 現在：開発進捗 約50％、大きな手戻りなく進行中 © DMM
34. ＊実際の成果物をもとに、説明用に内容を一般化・簡略化しています。 © DMM 34
35. © DMM ＊実際の成果物をもとに、説明用に内容を一般化・簡略化しています。 35
36. ＊実際の成果物をもとに、説明用に内容を一般化・簡略化しています。 © DMM 36
37. 画面構成例 © DMM ＊実際の成果物をもとに、説明用に内容を一般化・簡略化しています。 37
38. AI駆動開発で仕様はどこまで書くべきか？ AIに生成させる仕様を、 人が合意・確認すべき「骨組み」に絞る。 その先はAIに任せる。 この考え方がBSDDです！ © DMM 38
39. DMM Developer Blog でも 本取り組みを紹介しています。 AI駆動開発を考える際の 一つの参考になれば幸いです ご清聴ありがとうございました DMM Developer Blog © DMM 39
40. 補足：Q&A Q. 境界仕様は外部設計と違うのですか？ • 外部設計の簡略版ではなく、 サービス間合意の要否で仕様範囲を再構成する点が特徴です。 Q. なぜ仕様を減らしても開発が成立した のですか？ • 必要な情報を削ったのではなく、合意事項だけを人が確定し、内部設 計・実装方針は実行層でAIが具体化したためです。 Q. 仕様を実行コンテキストへ移しただけ では？ • 単純な移管ではなく、既存コード・開発ルール・ドメイン知識を再利 用してAIが具体化します。 Q.なぜサービス間合意を境界にするのです か？ • 複数サービスに影響する事項は、人が事前に合意する必要があるため です。 Q.境界判断は主観的になりませんか？ • サービス間合意が必要かを判断基準としています。 Q.境界仕様が不足した場合は？ • 合意事項への影響を確認し、境界仕様を見直します。 Q.仕様を減らして品質は問題ないのです か？ • 初期評価では重大事象は観測されませんでした。 • 詳細な品質評価は今後の課題です。 Q. BSDDとハーネスの違いは？ • BSDDは人とAIの責務境界を決める考え方、 ハーネスはAIの実行を支える仕組みです。 © DMM 40
41. 補足：Q&A Q.どの開発に適用できますか？ • 本研究ではマイクロサービスの既存改修で評価しました。新規 開発やモノリスは今後の検証対象です。 Q. 品質評価は十分ですか？ • 現時点では初期評価です。本番障害・RB・仕様不足を確認し， 内部品質や保守性などは今後評価します。 Q.境界仕様が不足していた場合は？ • 合意事項に影響する場合は，境界定義層に戻して確認・修正し ます。 Q.実行計画は詳細設計ではないのですか？ • 詳細設計ではなく，AIが実装を進める単位・順序・担当を示す 実装計画です。 Q.ハーネスが未成熟でも使えますか？ • 適用は可能ですが，効果は限定的です。 • AIの安定した実行にはハーネス整備も重要です。 © DMM 41