AI駆動開発フローの実態と課題

Transcript

1. © ASSIGN Inc. All Rights Reserved. 株式会社アサイン AI駆動開発フローの実態と課題 2025年10月16日
2. © ASSIGN Inc. All Rights Reserved. 坂井 禎拓（さかい ちひろ） 自己紹介 新卒：株式会社ワークスアプリケーションズ （2020年4月〜2022年8月） SEとして会計ERPの開発 現在：株式会社アサイン（ 2022年9月〜） フルスタックエンジニア 2024年8月〜『ASSIGN TECH』の事業責任者 株式会社アサイン エンジニア・新規事業責任者 2 x：@chihiroski
3. © ASSIGN Inc. All Rights Reserved. 1. AI駆動開発の目的 2. 目指すべきAI駆動開発の状態 3. AI駆動開発フロー ◦ 開発フロー全体像 ◦ 各フロー（要件定義・設計・実装・PR）説明 4. 課題と今後の改善策 ◦ 課題1：作業スコープの肥大化 ◦ 課題2：実装者のセルフレビュー負荷 アジェンダ 3
4. © ASSIGN Inc. All Rights Reserved. 1：AI駆動開発の目的
5. © ASSIGN Inc. All Rights Reserved. AI駆動開発の目的 5 AI駆動開発の前に、何を目的とするか
6. © ASSIGN Inc. All Rights Reserved. AI駆動開発の目的 6 AIが「自律的に」プロダクトを向上し続ける
7. © ASSIGN Inc. All Rights Reserved. 「自律的」がポイント Claude Code・Codexを使えば一定のAI駆動開発は可能 しかし人間の作業が一定以上残り続ける 意識して人間の作業をAIに委譲し、非同期的にプロダクトを向上させる → AIが「自律的」にプロダクトを向上し続ける AI駆動開発を実施 7
8. © ASSIGN Inc. All Rights Reserved. 目標とするAI駆動開発とは？ 8 自律的にプロダクトを向上し続ける AI駆動開発ってなんだ？
9. © ASSIGN Inc. All Rights Reserved. 2：目指すべき AI駆動開発の状態
10. © ASSIGN Inc. All Rights Reserved. 一口にAI駆動開発と言っても取り組むイメージがバラバラ • 成果物の品質や粒度が統一されず、チームの開発フローに組み込みづらい • ベストプラクティスの移り変わりが激しく、手法を統一しづらい • 目先のツールや手法に振り回され、フローに定着させられない 認識のブレ 10
11. © ASSIGN Inc. All Rights Reserved. 理想とする AI駆動開発の像を定める そしてチームで認識を揃える 共通認識を持つ 11
12. © ASSIGN Inc. All Rights Reserved. 我々が目標とするAI駆動開発 12 レベル4のAI駆動開発
13. © ASSIGN Inc. All Rights Reserved. 自動運転レベルを参考にAI駆動開発レベルを定める 13 引用：自動運転移動サービスを推進する国の取り組みと展望（経済産業省）
14. © ASSIGN Inc. All Rights Reserved. AI駆動開発レベル • レベル1　支援：GitHub Copilotのインラインサジェスト • レベル2　部分自動化：一昔前の単一ファイルのみ修正するCursor • レベル3　条件付自動化：プレーンなClaudeCode、常時手離し実装不可 • レベル4　高度自動化：ドメイン・ルールを把握したエージェント • レベル5　完全自動化：人はほとんど介入不要 14
15. © ASSIGN Inc. All Rights Reserved. AI駆動開発レベル • レベル1　支援：GitHub Copilotのインラインサジェスト • レベル2　部分自動化：一昔前の単一ファイルのみ修正するCursor • レベル3　条件付自動化：プレーンなClaudeCode、常時手離し実装不可 • レベル4　高度自動化：ドメイン・ルールを把握したエージェント • レベル5　完全自動化：人はほとんど介入不要 15 → 目指す → AIが完全にレビューを担わない限り難しい
16. © ASSIGN Inc. All Rights Reserved. レベル4の効果 • 開発スループットの向上 ◦ レベル3と異なり命令と修正の往復が減少する ◦ ボトルネックが承認に集約されることでフロー全体が瞬時に流れる • コード品質の改善 ◦ レベル3では同じ指摘や禁止事項が繰り返される ◦ 各ルール、お作法、修正すべきAIの癖を渡すことで品質が安定する チーム全員でアウトプットの認識が揃う • 「この部分がレベル3のままなので改善しよう」 • 「レベル4のためにこれを試してみよう」 16
17. © ASSIGN Inc. All Rights Reserved. 3：AI駆動開発フロー
18. © ASSIGN Inc. All Rights Reserved. • ツール ◦ Claude Code、Codex、Cursor ◦ Jira MCP、Notion MCP、Figma MCP 等 • 取り組み ◦ 仕様駆動開発（SDD） ◦ 要件定義、設計、開発、PRの4フロー AI駆動開発フロー 18
19. © ASSIGN Inc. All Rights Reserved. • 仕様駆動開発の課題 ◦ ドキュメントが多く重要度の優劣をつけられない ◦ 参照元・参照先が不明確 ◦ ディレクトリ構成だけでは全体像がわかりずらい • 取り組み ◦ miroで全体フローを書き出し依存関係を可視化 AI駆動開発フロー 19
20. © ASSIGN Inc. All Rights Reserved. 20
21. © ASSIGN Inc. All Rights Reserved. 21
22. © ASSIGN Inc. All Rights Reserved. 22 要件定義 設計 開発 PR
23. © ASSIGN Inc. All Rights Reserved. • 要件定義 • 設計 ◦ バックエンド ◦ フロントエンド • 実装 ◦ バックエンド ◦ フロントエンド • PR AI駆動開発フローを解説 23
24. © ASSIGN Inc. All Rights Reserved. 要件定義 24 • 成果物 ◦ PRD、DesginDoc ◦ モック • 特徴 ◦ V0等でモック作成 ▪ ペルソナに当て早期に検証 ▪ モック→PRDを修正 ◦ 設計でも利用 ▪ PRD/DesignDocは後続の設計フェーズでも参 考ファイルとして利用 凡例 ・実線：同一コンテキスト ・点線：別コンテキスト
25. © ASSIGN Inc. All Rights Reserved. 設計 - バックエンド 25 • 成果物 ◦ API設計書、DB設計書、API詳細設計書、全体設 計書 • 特徴 ◦ 作成順序 ▪ API→DB→データフロー ◦ API設計書 ▪ 全工程で5回参照される重要な資料 ◦ 全体設計書 ▪ 後述する実装時のドキュメントに活用 凡例 ・実線：同一コンテキスト ・点線：別コンテキスト
26. © ASSIGN Inc. All Rights Reserved. 設計 - フロントエンド 26 • 成果物 ◦ 画面仕様書、全体設計書、分割方針書、スコープ 別仕様設計書 • 特徴 ◦ 画面仕様書 ▪ コンポーネントの位置・動き等を記述 ◦ スコープ別仕様設計書 ▪ 実装時に活用する重要な資料 凡例 ・実線：同一コンテキスト ・点線：別コンテキスト
27. © ASSIGN Inc. All Rights Reserved. 実装 - バックエンド 27 • 成果物 ◦ コード、テスト • 特徴 ◦ 仕様駆動開発 ▪ 全体設計書・API・DB設計書等を参照して自 律的に開発 ◦ テスト駆動開発 ▪ 不確実性をコントロール 凡例 ・実線：同一コンテキスト ・点線：別コンテキスト
28. © ASSIGN Inc. All Rights Reserved. 実装 - フロントエンド 28 • 成果物 ◦ コード、テスト • 特徴 ◦ スコープ別設計方針書をもとに実装 ▪ スコープを絞ることでコンテキストウィンドウを 節約し精度向上 ◦ 参照ファイルが多い ▪ 設計、コーディングルール、プロジェクトルー ルなど ▪ バックエンドよりもコンテキスト多い 凡例 ・実線：同一コンテキスト ・点線：別コンテキスト
29. © ASSIGN Inc. All Rights Reserved. PR 29 • 成果物 ◦ PR • 特徴 ◦ Jira MCPで課題背景取得 ▪ なぜこのPRが必要か追記 ◦ インラインコメント ▪ コードをピンポイントで説明 ◦ Claude Code Github Actions ▪ 一次レビュー 凡例 ・実線：同一コンテキスト ・点線：別コンテキスト
30. © ASSIGN Inc. All Rights Reserved. 4：課題と今後の改善策
31. © ASSIGN Inc. All Rights Reserved. • 事象 ◦ 1スコープ=1PR想定でも変更ファイルが膨張（特にフロント） ▪ コンテキスト圧迫でauto-compactが発生し精度低下 ▪ レビュアーが辛い • 原因 ◦ 分割用のプロンプト・ルールが甘い、精査できていない • 対応方針 ◦ 全体設計書→スコープ別設計書の分割ルールを改善 ◦ 暗黙知で分割していたものを言語化 課題1: 作業スコープの肥大化 31
32. © ASSIGN Inc. All Rights Reserved. • 事象 ◦ 実装後の実装者のチェックが大変 ▪ 確認するコード量が膨大 ▪ 受入品質・基準を満たしていな記述が数十箇所以上 • 原因 ◦ コーディング規則が抽象的 ◦ 方針のみではなく、何をすべきでないのか明確な禁止事項を明記 • 対応の方向性 ◦ 都度ドキュメントにFBして改善していく 課題2: 実装者のセルフレビュー負荷 32
33. © ASSIGN Inc. All Rights Reserved. • 暗黙知の言語化・コンテキスト追加 ◦ ルール・ノウハウを文章化 • ドキュメント改善 ◦ 品質改善箇所・参照頻度高いドキュメント • コンテキストウィンドウ管理 ◦ サブエージェントでコンテキスト退避 • AI駆動開発の継続的改善 ◦ フローの定期的な更新と改善の仕組み化 改善策の方向性 33
34. © ASSIGN Inc. All Rights Reserved. 我々が目指すAI駆動開発 34 AIで自律的にプロダクトを向上し続ける開発 → 「レベル4のAI駆動開発」を目指す
35. © ASSIGN Inc. All Rights Reserved. ご清聴いただきありがとうございました 35