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

1. 人とAIの責務分離に基づく 開発プロセスの提案 ― BSDD: Boundary Spec Driven Development ― AIに自律的な実行を委ねるために，人は何を定義すべきか © DMM 1 CONFIDENTIAL
2. ー 自己紹介 ー • 所属： DMM.com • 専門： AX推進 / AIプロダクト開発 • 研究テーマ：人とAIの協調・責務分離 昨年、DICOMO優秀論文賞を受賞 今年は、AIに自律実行を委ねる 開発プロセスを提案する © DMM 2
3. Agenda 1. 背景と課題 2. 境界定義層 3. 実行層 4. 運用原則 5. 評価と考察 © DMM 3
4. １章. 背景と課題 4 © DMM 4
5. AI駆動開発の進展 • 2025年以降，生成AIにより自然言語から実装が可能になった（例：Vibe Coding） • 一方，仕様がないまま実装が進むと成果物を見ても，設計意図を把握しにくい 自然言語 AIが判断した範囲 暗黙的に補完 © DMM なぜこの項目を表示したか？ なぜこのAPI応答にしたか？ 5
6. SDD（仕様駆動開発）とは • そこで仕様を先に定義し、AIに実装させるSDDという手法が登場した • 要件・設計方針などを定義し，AIが実装しやすい形に整理する • これにより実装前の設計意図を把握しやすくなった 仕様化 AIが判断した範囲 要件・設計 実装方針など © DMM 6
7. SDD（仕様駆動開発）の課題 • しかしAIに期待通り実装させようとすると詳細な判断まで仕様に書き足しがちになる • その結果，修正ループが発生し, 仕様は肥大化し，設計意図が把握しにくくなる 期待通りにしようと 詳細仕様化 AI実装 軽量な変更でも 1,000行規模 人が書き足す © DMM 期待と異なる 成果物 7
8. 課題：人とAIの判断範囲の曖昧さ A) Vibe Coding 仕様がない：人が決めるべき判断までAIが補完してしまう B) SDD（仕様駆動開発） 仕様が肥大化しやすい：AIに任せられる判断まで人が仕様に書いてしまう • 本質は, 人とAIの判断範囲が曖昧なことにある © DMM 8
9. 研究目的 • 本研究では， AI駆動開発における人とAIの責務境界を定める Boundary Spec Driven Development：境界仕様駆動開発（BSDD）を提案する © DMM 9
10. 本研究の新規性 • SDD（仕様駆動開発） 仕様を構造化し，AIに実装させる • BSDD（境界仕様駆動開発） 既存の設計要素をベースに人とAIの責務境界を構成した点にある （新しい設計記法ではない） AIの責務 人の責務 境界 © DMM 10
11. 本研究で扱う開発 • 本研究では， 複数のロール・サービスが関わるマイクロサービス型Web開発を対象とする • 例： プロダクトオーナー，テックリード， フロントエンド，バックエンド， デザイン，インフラなどが連携する開発 © DMM 11
12. ２章. 境界定義層 人が定義する、システムの骨格 © DMM 12
13. 二層構造 • BSDDでは，プロダクト目的を起点に、開発プロセスを二層に分ける。 A) 境界定義層（人）： 関係者間で決めるべき内容を境界仕様として確定する B) 実行層（AI）： 境界仕様から設計・実装方針を具体化する © DMM 13
14. （A）境界定義層の全体フロー 1. 目的を起点に関係者間で要求を把握 2. サービス横断で判断すべき内容を抽出する 3. 合意した内容を，境界仕様として確定する この境界仕様を，実行層への入力とする © DMM 14
15. （A）境界仕様の判定ルール • 判断軸は，「サービス間合意を要するか」である • 「成果物の種類」ではなく、「合意への影響」で判断する © DMM 境界仕様に 含める • • • 操作・表示・API応答に影響 複数ロールの合意が必要 監査・リカバリ等に影響 実行層へ 委譲する • • 単一サービス内で完結 既存ルールで判断可能 15
16. （A）境界仕様の基本構成 項目 • • 判定ルールに基づき， • 背景・目的 境界仕様に含める項目を整理する • ユースケース • 画面WF・遷移 • API I/O • 機能要件詳細 • 非機能要件 • 設計判断 • データモデル • 内部設計 • テストケース • タスクリスト 人が定義すべきは，詳細設計ではなく システムの骨格となる境界仕様である • ただし，境界仕様の範囲は固定ではなく， 合意への影響に応じて案件ごとに変動する 境界仕様 含む ▲ 合意影響時 は含む × 原則含めな い ※ 本表は，初期判断モデルとしての 提案であり，固定ルールではない。 © DMM 16
17. 3章. 実行層 AIが具体化する、実装の進め方 © DMM 17
18. （B）実行層の全体フロー ⚫ 実行層では，境界仕様をもとにサービス単位の作業へ分解する 1. AIは，サービスごとに実行計画を立案し, 人がその内容を確認する 2. 確認後，AIはコード生成からPRまでサービスごとに並行して進める 成果物A 成果物B © DMM 18
19. （B）ハーネス：AIの自律実行を支える仕組み • 実行層では AIに自律実行させるために 一般的なハーネスの考え方を用いる • ハーネスとは， AIに知識・制約・検証を与え， 実行計画に沿った実装を支える仕組みである © DMM 19
20. ４章. 運用原則 責務境界を維持する原則 © DMM 20
21. 責務境界を維持する原則 1. 人は境界仕様に集中する サービス間で合意すべきことを定義し， 具体化は実行層でAIに委譲する 2. AIが自律実行できる状態を整える ハーネスを継続的に整備し，AIの自律実行を支える © DMM 21
22. ５章. 評価と考察 責務分離により、何が変わったか © DMM 22
23. 人の確認ポイントの集約 • BSDDを適用した結果，人が判断すべきポイントは3点に集約された • これにより人は，開発プロセス上の確認点に集中し，設計意図を把握できる • 次に，この整理によって仕様書の記述範囲がどう変わったかを示す © DMM 23
24. 仕様記述範囲のBefore/After • 従来SDDでは，設計方針・実装方針・テスト観点まで人が仕様書に書き足していた • BSDDでは，人が仕様に書く対象を合意すべき境界仕様へ集約した 人の記述範囲 AIの具体化範囲 境界仕様 詳細設計 実装方針 テスト観点 内部設計 © DMM 詳細設計 実装方針 テスト観点 内部設計 24
25. 結論 • BSDDでは，人が合意すべき境界を定義し，具体化をAIの実行層に委譲した • その結果，人の確認ポイントは3点に整理され，仕様記述量・工数の削減も確認された • ただし本質は，仕様削減ではなく， 人が決める範囲とAIに任せる範囲を分離することにある • 今後は適用範囲を広げて再現性と有効性を検証する © DMM 25
26. 人が定義すべきは システムの骨格となる「境界仕様」である その先では AIが自律的に実行できる基盤を整える これが、AIの自律性を支える 人とAIの責務分離である © DMM 26
27. 本研究が、AI駆動開発における責務設計の 一つの指針となれば幸いです ご清聴ありがとうございました © DMM 27