AI駆動開発における人とAIの責務境界モデルの提案 ― 境界仕様に基づくBSDDの実践 ―

Transcript

1. AI駆動開発における人とAIの責務境界モデルの提案 ― 境界仕様に基づくBSDDの実践 ― 合同会社DMM.com ◦松井 高宏 E-mail： matsui-takahiro@dmm.com © DMM 1 CONFIDENTIAL
2. 自己紹介と研究テーマの着想 松井 高宏 合同会社 DMM.com ／プラットフォーム開発部門 バックエンド開発リーダー • • ユーザーレビューを管理する共通基盤を開発・運用 AI駆動開発の導入と開発プロセス改善を推進 ユーザーレビューの表示例 実務上の問題意識 実際の開発で生成AIを活用する中で、仕様が肥大化する問題に直面した © DMM 2
3. 1章. 研究背景と課題 AI駆動開発における仕様と責務境界の問題 © DMM 3
4. 背景：AI駆動開発とSDDの登場 • 生成AIにより，自然言語から設計・実装できる開発が広がった（Vibe Coding等） • しかし仕様を定めないと，画面項目やAPI設計まで，AIが補完し意図しない実装を招く • そこで，設計意図を事前に仕様化するSDDが登場した 仕様を定めない開発 都度指示 AIが実装 設計判断が見えにくい 意図しない実装 © DMM SDD（仕様駆動開発） 仕様 AIが実装 ◦ 設計意図を共有できる 認識ずれを抑える 4
5. 課題：仕様範囲の拡大 • SDDは設計意図を明示できる一方，期待どおり実装させると仕様が詳細化しやすい • 具体的には, 内部設計・実装方針まで人の記述範囲が広がる • 結果, 軽量な変更でも仕様が1,000行規模となり, 仕様作成・レビュー負荷が増大した 仕様 AIが実装 背景：人とAIでは前提や解釈を 完全には共有しきれず、その 差を埋めようとする側面がある 再実装 仕様を追記 © DMM 期待と異なる 5
6. 課題の本質：人とAIの責務境界の曖昧さ • 仕様を定めない開発：人が決めるべき設計までAIに任せ, 意図しない実装を招く • SDD：AIに任せられる事項まで人が仕様を書き, 作成・レビュー負担が増える 仕様を定めない開発 （Vibe Coding等） SDD（仕様駆動開発） AIに任せすぎる 人が書きすぎる 意図しない実装 作成・レビュー負担 共通原因：人とAIの責務境界が曖昧である では，人は何を決め，どこからAIに任せるべきか？ © DMM 6
7. 研究目的 • 人が確定する範囲と, AIに任せる範囲の責務境界を明確にする開発プロセス Boundary Spec Driven Development：境界仕様駆動開発（BSDD）を提案する 例：API契約のように合意が必要なものは人が確定し, 実装はAIに任せる 研究課題 © DMM RQ1 RQ2 RQ3 人が確定する仕様 範囲はどのように 変化したか 実運用上で 開発プロセス として成立するか どのような 問題が生じ どう見直したか 7
8. 本研究で扱う開発 • • マイクロサービス型の開発 • 複数のサービスが連携して、一つの機能を実現する開発を対象とする • PO・FE・BE・INFなど、異なる開発ロールがそれぞれの責務を担う PO サービス間合意 • このような開発で発生する事前合意を、 本研究では「サービス間合意」と呼ぶ FE サービス 間合意 BE INF © DMM 8
9. 本研究の新規性 • • SDD • 合意事項に加えて, 内部設計・実装方針まで人が仕様として記載 • そのため, 仕様作成・レビュー範囲が広がりやすい BSDD • 人とAIの責務境界を「サービス間合意が必要か」で判断 • 合意が必要な事項 → 人が決定 • 合意不要な内部設計・実装方針 → AIに委譲 → 人の仕様作成・レビュー範囲を縮小 © DMM 9
10. 2章. BSDDの提案：境界定義層 人が合意すべき事項を仕様として確定する © DMM 10
11. 人とAIの責務を分けるモデル • プロダクト目的を起点として人とAIの責務を二層に分ける • 境界定義層（人）：サービス間で事前合意すべき仕様を「境界仕様」と定義する • 実行層（AI）：境界仕様をもとに, AIが設計・実装を具体化する © DMM 11
12. 境界定義層の全体フロー 1. 人：目的を起点に関係者間で要求を把握 2. AI：目的・要求からサービス横断で必要な候補を抽出 3. 人：候補をレビュー・議論し，境界仕様として確定 この境界仕様を，実行層への入力とする 人：要求把握 AI：仕様候補を抽出 人：境界仕様を確定 © DMM 12
13. 境界仕様の判断基準 • AIは, 案件の目的・要求から判定基準に基づき境界仕様候補を抽出する 判定例（API改修案件） ①この案件の 定義対象か？ NO 記載しない 候補 YES ②サービス間 合意が必要か？ YES ①定義 ②合意 判定 画面構成 NO − 記載しない API I/F YES YES 境界仕様 内部設計 YES NO 実行層 NO 境界仕様 実行層 人が確定 AIが具体化 人の確定範囲を境界仕様に限定し, 仕様作成の負荷・レビュー対象を縮小させる © DMM 13
14. BSDD適用例：一括削除機能の境界仕様 • 管理者が最大1万件の不適切なユーザーレビューを一括削除し，履歴を記録する機能に適用 • 前述の判定基準に基づき、AIが境界仕様候補を抽出 → 関係者が合意して境界仕様を確定 境界仕様 • • © DMM 削除作業の効率化 操作履歴の確保 構造・契約 振る舞い 目的・価値 • • 実行条件 処理の流れ • • • 画面構成 API契約 論理データモデル 14
15. 境界仕様の抜粋：振る舞い / 論理データモデル 振る舞い 論理データモデル 一括削除の実行条件と、FE・BE間の処理の流れを定義 削除履歴のモデルを定義 ＊重要事項は，UML・図等で構造化し，人とAIの双方が理解しやすい形で整理 © DMM 15
16. 境界仕様の抜粋：画面構成 / API契約 画面構成 削除操作と、削除結果・履歴の表示を定義 © DMM API契約 入出力・上限・主要エラー・履歴を定義 16
17. 3章. BSDDの提案：実行層 AIが仕様を実装可能な作業へ展開する © DMM 17
18. 実行層のプロセス • 境界仕様を起点に, AIが主体となり実行計画〜実装・テスト〜PR作成を進める • 人はこれらの実行過程をAIに委ね，実行計画とPRで妥当性を確認する 境界仕様 © DMM AI 実行計画 実装・テスト PR作成 人 実行計画の確認 この間を AIが自律実行 PR確認 18
19. 実行層の構成例：Harness Engineeringを活用 • 境界仕様と実行コンテキストをもとにAIが内部設計・実装方針を具体化 • 境界仕様で「実現内容」を定め、実行コンテキストでは「AIが守る前提・制約」を与える 境界仕様 既存コード API/DB定義 開発ルール ① 実行計画 (=何を実現するか) ② 実装エージェント群 実行コンテキスト （=守るべき前提・制約） 修正・再検証 ③ CI・AIレビュー PR作成 OK 合意が必要な事項は人が決定 内部設計・実装方針は実行層でAIが具体化 © DMM 19
20. 実行層の構成例：一括削除機能の開発フロー • 一括削除機能を例に、境界仕様から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作成 人が確認 20
21. ４章. 品質確保の考え方 BSDDではどこで品質を確保するか © DMM 21
22. 境界定義層：人の確認する仕様を境界仕様に絞る • • 従来：SDDで詳細な仕様を人が確認しようとすると, 重要な合意事項が埋もれやすい BSDD：サービス間で合意が必要な事項だけを境界仕様として確認・確定する SDD適用時 要求定義 基本設計 実装方針 テスト観点 重要な合意事項 認識ずれが後で発覚 BSDD 境界仕様 重要な合意事項 関係者で合意・確定 重要な合意事項を境界仕様に限定し、仕様段階での認識ずれを早期に発見する © DMM 22
23. 実行層：人の確認ポイントを実行計画・PRに絞る • • 従来： AIに実装を委譲しても人の確認点が明確でない場合, 実装上の問題を見逃しやすい BSDD：実行計画とPRを人の確認点とし, 実行中の検証はCI・AIに委ねる 境界仕様 実行 実行計画 実装・テスト 検証 PR 自動検証 （CI・AI） PR確認 （人） 確認・検証 実行計画の確認 （人） 人の確認を要所に集中させ、実装上の問題を早期に検出する © DMM 23
24. ５章. 評価と考察 提案したBSDDを実案件で評価する © DMM 24
25. 評価方法 • BSDDによって, 人の仕様範囲・開発負荷・運用がどう変化したかを評価する RQ 評価観点 RQ1 人の仕様範囲 • 同一20案件 • 人が確定する仕様範囲・仕様量 RQ2 開発負荷・運用 • • 従来 SDD／BSDD 各8件 BSDD 8件×各 6ヶ月 • • 仕様策定時間／実装時間 障害・RB・重大な手戻り RQ3 問題と見直し • BSDDの試行運用 • 発生した問題と見直し © DMM 評価対象 評価内容 25
26. 評価：RQ1 ― 仕様範囲・RQ2 ― 開発負荷と運用 RQ RQ1 評価観点 結果 仕様範囲 （同一20案件） • 境界仕様に限定 仕様行数：1,213行 → 228行（84.5％削減） 開発負荷 （従来 SDD／BSDD 各8件） • • 仕様策定時間（〜確定）4h → 1h（75%短縮） 実装時間（〜PRマージ）8h → 6h（25%短縮） 運用 （BSDD 8案件×各 6ヶ月） • 重大事象（※）：観測0件 RQ2 ※本番障害・RB・再合意を要する仕様手戻り 合意事項に絞り、仕様作成負荷・レビュー対象を縮小 負荷を削減しつつ運用上の重大事象は観測されず © DMM 26
27. 評価： RQ3 ― 問題と見直し 試行段階で実行コンテキストの追加と境界仕様の見直しを行った 問題 対応 ①AIの知識が不足 ②人の境界判断が不十分 ① 不足したルール・知識を 実行コンテキストに追加 ②サービス間への影響を確認し、 境界仕様を再定義 AI側に不足する知識は実行コンテキストへ追加し、 人側の境界判断に不足があれば境界仕様を見直す © DMM 27
28. 研究課題への回答（RQ1〜RQ3） RQ1 仕様範囲の変化 RQ2 成立性 RQ3 問題と見直し 人が確定する仕様を 境界仕様に限定 開発時間を削減し 実運用可能性を確認 試行段階を通じて 責務境界を調整 BSDDの実運用上の初期的な成立性を確認 © DMM 28
29. 今後の展開 • 本実践は, マイクロサービス機能の既存改修を対象に評価した • 今後は，新規開発やモノリス構成など, 異なる開発形態も検証する。 • 合わせて, 品質評価指標も拡張し, 評価も厳密化する 今後の検証 今回の対象 • © DMM 検証範囲 • 適用範囲 • 評価方法 マイクロサービスの機能改修 既存改修（ブラウンフィールド） 新規開発（グリーンフィールド） モノリス構成 品質評価指標の拡張・厳密化 29
30. 結論 • 「サービス間合意の要否」を基準に, 人とAIの責務境界を設定 • 合意が必要な事項は境界仕様として人が確定 • 内部設計・実装方針を実行層でAIが具体化 → 仕様作成負荷・レビュー対象を縮小し, 実装時間も短縮 • 本研究の意義は，AI駆動開発において 「人が重要な合意・判断に集中し、それ以外をAIに委譲する責務分離プロセス」 を示した点にある 人が決めるべきことを決め，AIに任せるべきことを任せる。 © DMM 30
31. 補足：Q&A Q. 境界仕様は外部設計と違うのですか？ • 外部設計の簡略版ではなく、 サービス間合意の要否で仕様範囲を再構成する点が特徴です。 Q. なぜ仕様を減らしても開発が成立した のですか？ • 必要な情報を削ったのではなく、合意事項だけを人が確定し、内部設 計・実装方針は実行層でAIが具体化したためです。 Q. 仕様を実行コンテキストへ移しただけ では？ • 単純な移管ではなく、既存コード・開発ルール・ドメイン知識を再利 用してAIが具体化します。 Q.なぜサービス間合意を境界にするのです か？ • 複数サービスに影響する事項は、人が事前に合意する必要があるため です。 Q.境界判断は主観的になりませんか？ • サービス間合意が必要かを判断基準としています。 Q.境界仕様が不足した場合は？ • 合意事項への影響を確認し、境界仕様を見直します。 Q.仕様を減らして品質は問題ないのです か？ • 初期評価では重大事象は観測されませんでした。 • 詳細な品質評価は今後の課題です。 Q. BSDDとハーネスの違いは？ • BSDDは人とAIの責務境界を決める考え方、 ハーネスはAIの実行を支える仕組みです。 © DMM 31
32. 補足：Q&A Q.どの開発に適用できますか？ • 本研究ではマイクロサービスの既存改修で評価しました。新規 開発やモノリスは今後の検証対象です。 Q. 品質評価は十分ですか？ • 現時点では初期評価です。本番障害・RB・仕様不足を確認し， 内部品質や保守性などは今後評価します。 Q.境界仕様が不足していた場合は？ • 合意事項に影響する場合は，境界定義層に戻して確認・修正し ます。 Q.実行計画は詳細設計ではないのですか？ • 詳細設計ではなく，AIが実装を進める単位・順序・担当を示す 実装計画です。 Q.ハーネスが未成熟でも使えますか？ • 適用は可能ですが，効果は限定的です。 • AIの安定した実行にはハーネス整備も重要です。 © DMM 32