はじめに
AI駆動開発の事例について検索して調べて、メモ用としてまとめてみました！
簡単に箇条書きで書いたので、参考程度に見ていただければと思います。
(追加・修正予定)
モノタロウのAI駆動開発
Devin
- 受注管理システムのリプレースプロジェクトに参画
- 少人数チームでAPI移植やバグ修正・機能追加を5日間で実施し、高い生産性を発揮
- 複数リポジトリにまたがる開発対応を遂行
- プロジェクト構造のドキュメント化やナレッジグラフ生成ツールのプロトタイプを作成
- 大規模・長大なタスク指示への対応に課題があり、タスク分割の重要性を実感
- openhands(OSS版のDevin)はUIが貧弱、遅い、いいのがでない
- Devinを試験導入
- 要件の言語化が不十分だと変なPRを作る
- レビューの言語化・Devin教育することで改善、似たような案件をまわせるようになる
- AIを活用するための環境整備・改善のサイクルが重要
- 160人以上の開発者にアカウントを発行、2週間で160以上のPR
Github Copilot
Githubにアクセスできるすべての開発者が使える
セキュリティ
- 生成AIの活用には大きなメリットがあり、積極的に活用すべき
- 一方で、活用に伴う新たなリスクへの対応が重要
- モノタロウでは、情報セキュリティ担当が定めたLLM活用のガイドラインに基づき、安全性を確認したツールのみ使用
- AI駆動開発チームが提供するツールは、原則としてこのアセスメントを通過済み
- 中央集権的なチェック体制によりリスク増大を抑制
- 今後のリスク例：コード品質の低下、野良MCPサーバーによる情報漏洩、悪意あるプロンプトなど
- リスクとベネフィットのバランスを見極めながら、ルールやガイドライン、ガードレールを適宜整備していく必要がある
生成AIを活用したレガシーシステムの移植
リバースエンジニアリング
LLMを活用したリバースエンジニアリングによるドキュメント生成
LLMによるコード生成
- レガシーシステムは継ぎ足しの結果、仕様書がなく意図不明な「秘伝のコード」が多い
- 移植には現行仕様の把握が必要で、コードの意図を復元する作業が重い
- 調査工数削減のため、AIとロジックを組み合わせてコードを解析
- 静的解析 → 中間表現(JSON等) → LLMによる説明付加 → ドキュメント生成、という流れをLangGraphでワークフロー化
- コメント内の社内用語と変数名の対応づけなど、人手でしか読み取れない情報もLLMが得意
- ロジック解析＋LLM分析により、大規模コードも高精度にドキュメント化可能
- この仕組みにより、移植前の調査工数を約半減できる見込み
- ThoughtWorks事例を参考に、構文構造をナレッジグラフ化しLLMで全体像を把握させる試みにも挑戦中
コード生成
- リバースエンジニアリングで得たドキュメントとコードを基に、移植先システムの自動生成に取り組み中
- HTMLテンプレートやAPIコードの自動生成を実現
- 単純かつ反復的な作業の工数を大幅に削減可能
- Devin、Cline、Cursorのような汎用開発エージェントの時代も近いと感じる
- 一方で、現時点では自チームの課題に即した専用ワークフローの開発が有効
- これらのツール開発にもClineやCursorを積極的に活用中
参考: https://tech-blog.monotaro.com/entry/2025/04/24/091000
クラスメソッドのAI駆動開発
導入ツール
- Github Copilot: 全社導入
- Cursor: 全社導入
- Devin: 一部導入
- Windsurf: 一部導入
- Cline: 一部導入
Zennの実装でDevinを活用
- 一部の機能の7~8割はDevinが実装
- 既存コードのテストコードを実装
- 小さいタスクがDevinの効果を発揮
- DeepWiki/Searchでノウハウ共有
活用内容
提案
- 顧客ヒアリング：議事録を文字起こし
- 情報分析：競合をDeepResearchで調査
- 提案の整理：議事録からAIツールを使用して要件を整理
- プロトタイプを作成：提案の内容をベースにCursorとプロンプトでモック作成、デモ
設計/実装
- 全工程の作業にCursorを組み込み、AIを活用したプロセスの最適化
- 要件→設計書でOpenAPI形式などに変換
- 命名の案出し
- ドキュメントやコードのレビュー
- タスク分割が重要
タスクを細かく分割するために、プロンプトを考える・整備の手間がある
典型的な実装などが多い場合は有効
ライブラリ調査
- 実装で使えそうなライブラリ調査
- DeepResearchなどのサービスで調査
- DeepWiki上でOSSで実現可能か調査
Deep wiki
- Chatbotで処理フローなどを確かめる
- シーケンス図など確認可能
- Devin WikiならクローズドなソースでもWiki化して解析・質問可能
従来の開発
- 大規模PJではエキスパートだけが正しい結果を判断可能
- ビジネス側は情報取得するのにラグがある
将来の開発
- 1つのデータソースにすべてのコード・ドキュメントが集約
- データソースからAIを使用してユーザ(開発者・ビジネスなど)が情報収集
テスト
- 実装に合わせたテストコード生成
- CI/CDでCodeRabbit, PR-Agentの導入
- PRをAIがレビュー
運用/保守
- code2pronmtでリポジトリのコードをプロンプトに変換、Geminiで設計の生成・質問
正しいAIとの付き合い方
高品質なAIを使うことで、エンジニアのコーディングの質が下がってしまう可能性がある
人間がソフトウェアエンジニアを深く理解する必要性は変わらない