2026-06-24_人とAIの責務分離に基づく開発プロセスの提案.pdf

Transcript

1. © DMM © DMM CONFIDENTIAL ⼈とAIの責務分離に基づく 開発プロセスの提案 ― BSDD: Boundary Spec Driven Development ― AIに⾃律的な実⾏を委ねるために，⼈は何を定義すべきか 1
2. © DMM 本発表の位置づけ • ここまでの発表では、LLMが参照する知識や情報を どのように扱うかが議論されてきました • 本発表では視点を変え、 ⽣成AIをソフトウェアの開発プロセスに組み込む際に ⼈が何を定義し、どこからAIに任せるべきかという 責務分離についてお話しします • LLMを実運⽤で使ううえでは、モデルやデータだけでなく、 AIに任せる範囲を開発プロセスとして明確にすることも重要です 2
3. © DMM 3 • 名前︓松井 ⾼宏 • 所属︓ DMM.com • 専⾨︓ AX推進 / AIプロダクト開発 • 研究テーマ：人とAIの協調・責務分離 ー ⾃⼰紹介 ー 昨年、DICOMO優秀論⽂賞を受賞 今年は、AIに⾃律実⾏を委ねる 開発プロセス （BSDD）を提案する
4. © DMM Agenda 1. 背景と課題 2. BSDD︓境界定義層 3. BSDD︓実⾏層 4. 評価と考察 5. 本研究のメッセージ 4
5. © DMM １章. 背景と課題 5 5
6. © DMM AI駆動開発の進展 • 2025年以降，⽣成AIにより⾃然⾔語から実装が可能になった（例︓Vibe Coding） • ⼀⽅，仕様がないまま実装が進むとAIが設計判断まで暗黙的に補完するため, 設計の妥当性を確認しにくくなる 6 自然言語 なぜこの項目や この画面にしたか？ AIが判断する範囲 暗黙的に補完
7. © DMM SDD（仕様駆動開発）とは • そこで仕様を先に定義し、AIに実装させるSDD（仕様駆動開発）が登場した • 実装前に要件・設計⽅針などの仕様を整理し，AIに実装させる⼿法である • これにより, 設計意図を明⽰し， AIが意図に沿って設計・実装しやすくなった 7 仕様として整理 ・要件 ・設計方針 ・実装方針 AIが判断する範囲 何を作るか どう作るか
8. © DMM SDD（仕様駆動開発）実運⽤の課題 • しかし実運⽤では, AIに期待通り設計・実装させようとすると 実装⽅針、テスト観点に加え, 細かな判断まで仕様として書き⾜しがちになる • その結果，仕様の記述量・範囲が拡⼤し，継続的な開発プロセスに組み込みにくくなる ＊仕様更新・レビュー・設計妥当性の確認負荷が⾼い 8 AI実装 人が書き足す 期待と異なる 仕様化 軽量な変更でも 1,000行規模
9. © DMM 課題︓仕様化の範囲の曖昧さ A) Vibe Coding 仕様がなく, ⼈が決めるべき判断までAIが補完してしまう B) SDD（仕様駆動開発） 仕様は構造化できるが、 期待通りに実装させようとするほど記述範囲が広がりやすい 9 本質は、仕様の有無ではなく、 ⼈が仕様として確定すべき範囲が曖昧なことにある
10. © DMM 研究⽬的 • 本研究では， ⼈が仕様として定義すべき範囲と AIに委譲すべき範囲を整理する開発プロセス Boundary Spec Driven Development︓境界仕様駆動開発（BSDD）を提案する 10
11. © DMM 本研究の新規性 • SDD（仕様駆動開発） 仕様を構造化し，AI実装につなげる • BSDD（境界仕様駆動開発） ⼈が定義すべき範囲とAIに任せる範囲の境界（ Boundary ）を扱う開発プロセス 11 ⼈が定義する 範囲 AIに任せる 範囲 例：画面項目やAPI契約は 人が決め， 設計・実装をAIに任せる
12. © DMM 本研究で扱う開発 12 • マイクロサービス型の開発 本研究では，プロダクト⽬的を起点に 複数サービス・開発ロールが連携するマイクロサービス型の開発を対象とする • 例︓フロントエンド，バックエンド，デザイン， インフラなどの複数のチームや開発単位が連携する開発 （サービス間で合意すべき仕様が重要になる開発）
13. © DMM ２章. 境界定義層 ⼈が定義する、システムの⾻格 13
14. © DMM 二層構造 14 • BSDDでは，プロダクト⽬的を起点に、開発プロセスを⼆層に分ける 1. 境界定義層（⼈）︓サービス間で合意すべき仕様を境界仕様として定義する層 2. 実⾏層（AI）︓ 境界仕様をもとにAIが各サービスの設計・実装⽅針を具体化する層
15. © DMM （A）境界定義層の全体フロー 15 1. プロダクト⽬的から要求を把握する 2. AIの⽀援により，サービス間で合意する 仕様を抽出・整理する 3. ⼈が境界仕様として確定、 実⾏層への⼊⼒とする 実行層の前に 人が責任を持って 合意すべき仕様を切り出す
16. © DMM （A）境界仕様の判断基準と代表例 16 • 境界仕様に含む項⽬は「サービス間で合意が必要な仕様か」の軸で判断する ※関係ロールとの合意も含む • 固定ルールではなく, 案件ごとの合意影響により変わる 境界仕様として含む例 • 背景・⽬的 • ユースケース • 画⾯WF・遷移 • API I/O • 外部連携データ 実行層へ委譲する例 • 内部設計 • 実装⽅針 • テストケース • タスクリスト • モデル内部構造 これら境界仕様は、サービス間で合意すべき対象を切り出した 「システムの⾻格」としての仕様である
17. © DMM （A）境界仕様の例 目的 → 価値・振る舞い 17 2.UseCase 各サービス間の振る舞いを合意 1.User Story Map どんな価値を実現するか合意 • 境界仕様の重要事項は図で構造化することで，認知負荷を下げ, 早期合意を図る
18. © DMM （A）境界仕様の例 画面・API契約 18 3.WireFrame（画面） 画面上の構成・入力項目を合意 4.API I/F（API契約） サービス間の入出力を合意 これらは複数サービスに影響するため境界仕様とする
19. © DMM 3章. 実⾏層 AIが具体化する、実装の進め⽅ 19
20. © DMM （B）実行層の全体フロー 20 l 実⾏層では, 境界仕様を起点としてサービスごとに実装を進める 1. AIは，各サービスごとに実⾏計画を⽴案し, ⼈が確認する 2. 承認後, AIは実⾏計画に沿って, コード⽣成からPRを並⾏して進める 成果物A 成果物B 境界仕様
21. © DMM （B）実行計画：実装の進め方を定める 21 • BSDDでは, 境界仕様をAIがそのまま実装するのではなく, 実⾏計画として「AIが扱いやすい実装単位」へと整理する （例︓API改修案件）レイヤーごとに実装⽅針・作業順序・検証⽅法を定める • 承認後, AIはこの計画を「実装地図」として実装からPR作成まで順に進める PR 実行計画例：API改修案件
22. © DMM （B）ハーネス：自律実行を支える 22 • ハーネスとは，近年注⽬される AIの⾃律実⾏を⽀える基盤技術である • BSDDでは，実⾏層において AIにプロダクト・サービス固有の 知識・制約・検証⽅法を与える • これによりAIは, 実⾏計画に沿って 安定して実装・検証を進めることが 可能となる
23. © DMM ４章. 評価と考察 責務分離により、何が変わったか 23
24. © DMM 結果１：人の確認工程を集約 24 • BSDDでは，⼈が確認すべき⼯程を境界仕様・実⾏計画・PRに集約した • 結果, それ以外の具体化はAIが進めるため, ⼈は重要な判断に集中できる
25. © DMM 結果２. 仕様記述範囲の集約 25 • 従来SDD︓AIに期待通り実装させるため，仕様が詳細化しやすい • BSDD︓⼈が記述する範囲をサービス間合意である境界仕様へと集約した BSDD 境界仕様 要件定義 基本設計 詳細設計 実装方針 テスト観点 内部設計 詳細設計 実装方針 テスト観点 内部設計 従来SDD 人が記述しがちな範囲 人の記述範囲 AIの具体化範囲
26. © DMM 結果２. 仕様記述範囲の集約 26 • 記述範囲を集約した結果，仕様記述量・仕様策定⼯数は削減できた • 境界仕様をもとに実装した結果, 観測範囲で重⼤障害等は発⽣していない • これらは初期的な確認であるが, 実運⽤への適⽤可能性を⽰すものである 項目 対象 従来SDD （中央値） BSDD （中央値） 削減率 仕様記述量 20件 1,213行 228行 84.5% 仕様策定工数 8件 4h 1h 75% 重大障害・RB 8件 ー 発生なし ー ※厳密な因果推定ではなく，初期的な適用可能性の確認である
27. © DMM 結論 27 • BSDDでは，⼈が合意すべき境界仕様を定義し，具体化をAIの実⾏層に委譲した • その結果，⼈の確認⼯程と仕様記述範囲は集約され， 設計意図を保ちながら, 開発プロセスを効率化できることを確認した • 本研究の意義は，⼈とAIの責務境界を定めることで ⼈が重要な判断に集中し, AIが具体化を担う開発プロセスを⽰した点にある • 今後は評価⽅法を厳密化し, 適⽤範囲を広げつつ再現性と有効性を検証する
28. © DMM 5章. 本研究のメッセージ 28
29. © DMM AI駆動開発において ⼈が定義すべきは システムの⾻格となる「境界仕様」である その先では AIが⾃律的に実⾏できる仕組みを整える これが、AIの⾃律性を⽀える ⼈とAIの責務分離である 29
30. © DMM 30 本研究が、AI駆動開発における ⼀つの指針となれば幸いです ご清聴ありがとうございました
31. © DMM APPENDIX 31
32. © DMM 評価時の適用方針 32 本評価では、⼈とAIの責務分離を維持するため、 以下の⽅針でBSDDに適⽤した 1. ⼈は、サービス間で合意すべき境界仕様の定義に集中する 2. サービス内で完結する具体化は、AIの実⾏層に委譲する 1・2を維持するため，⼈がAIの判断を代替し続けるのではなく， AIが安定実⾏できるよう，ハーネス（知識・制約・検証）を継続して整備する
33. © DMM 33 Q. BSDDは、ハーネスを決める取り組みで すか？ • ハーネス整備も含まれますが、主目的ではありません。 BSDDでは、人が決めることとAIに任せることを整理し、その実行を支えるものと してハーネスを位置づけています。 Q. BSDDにすると品質が下がりませんか？ • 品質を下げる考え方ではありません。仕様、実行計画、PRの確認は従来どおり重 視し、人が確認すべきポイントを明確にすることを目的としています。 Q. 各社のAI開発支援ツールとの違いは何で すか？ • 各社ツールは、AIの実行を支援するものです。BSDDは、その前段として、人が何 を決め、どこからAIに任せるかを整理する考え方です。 Q. 実装後にAIへコード要約させれば、仕様 は不要ではないですか？ • コード要約は実装結果の理解には有効です。ただし、事前に何を合意し、なぜそ う判断したかまでは残りにくいため、BSDDでは実装前に境界仕様を整理します。 Q. 境界仕様の判断は主観的になりません か？ • 判断基準として、サービス間合意が必要かを見ます。画面、API、ロール、データ、 業務ルールなど、複数の関係者に影響するものは境界仕様として扱います。 Q. どの開発に適用できますか？ • 主に、APIなどで複数サービスが連携するWeb開発を対象としています。 モノリスやゼロから作る開発への適用は、今後の検証対象です。 Q. AIが想定どおりに実装しない場合はどう しますか？ • 個別に人が実装を代替するのではなく、ルールや知識、スキルなどの実行基盤を 見直します。ただし、合意事項に関わるずれは、境界定義層に戻って確認します。 Q. データモデルなどは 境界仕様に含まれるのでは？ • 場合によります。業務上の概念・状態・API応答など，複数サービスに影響する内 容は境界仕様に含めます。一方，テーブル定義やモデル内部の詳細は， 原則として実行層でAIに具体化させます。その妥当性は、実行計画で確認します 補足：Q&A
34. © DMM 34 Q.単一サービスの開発には適用できま せんか？ • 適用できます。単一サービスでも，プロダクト目的・振る舞い・受入条件など，他 者と合意すべき内容が必要な場合は境界仕様として扱います。一方，単一サービス 内で完結する設計・実装の具体化は，原則として実行層でAIに委譲します。 Q. 品質評価は十分ですか？ • 現時点では初期評価として、境界仕様どおりの外部挙動になっているか、重大な障 害やロールバックが発生していないかを確認しています。内部品質、保守性、レビ ュー負荷、欠陥密度などは、今後さらに評価していく対象です。 Q. 今後、どのように評価を厚くします か？ • 欠陥密度、レビュー指摘数、レビュー工数、複雑度、変更容易性、リリース後障害 件数などを見ていく予定です。品質・保守性・運用品質への影響を、より多面的に 確認していきます。 Q. なぜサービス間合意を境界にするの ですか？ • 複数のロールやサービスに影響する内容は、人が責任を持って合意しておく必要が あるためです。そのため、サービス間合意を境界仕様の判断基準にしています。 Q. 境界仕様が不足していた場合はどう しますか？ • 外部挙動や関係者間の合意に影響する場合は、境界定義層に戻って確認します。 実行層だけで無理に調整しないようにします。 Q. 実行計画は詳細設計ではないのです か？ • 詳細設計ではなく、AIがどの単位で実装を進めるかを確認するための実装計画です。 人は、実装の進め方や分割単位が妥当かを確認します。 Q. ハーネスが未成熟でも使えますか？ • 使うことはできますが、効果は限定的です。 • AIが安定して実行できるようにハーネスの整備も重要になります。 Q. 評価の前提条件は何ですか？ • 仕様記述量は、同一20案件で従来SDD文書とBSDD境界仕様を比較しています。 工数や品質は、API 1本追加の実案件8件を対象に確認しています。 • なお、厳密な因果推定ではなく、実運用上成立するかを確認した初期評価です 補足：Q&A