ミツモア Tech blog

「ミツモア」を運営する株式会社ミツモアの技術ブログです

AIをチームメンバーに迎えた話 — AI-DLCでプロワンの開発はどう変わるのか

はじめに

こんにちは、プロワンプロダクト部部長の仲井です。

先日、弊社開発メンバーと一緒に AWS が主催する「AI-DLC(AI-Driven Development Lifecycle)」のセミナーに参加してきました。「AI をコーディングの補助ツールとして使う」という段階を超えて、「AI をチームの一員として開発プロセスに組み込む」という世界観が紹介されたセミナーです。

本記事は、そのセミナーで学んだことと、実際にプロワンの機能を題材に手を動かしてみた感想・学び、そしてこれから私たちがどうしていくかについての記録です。なお AI-DLC をそのまま全部門に一律適用しようという話ではなく、各チームが自分たちの文脈で咀嚼して使うという前提で書いています。


そもそも AI-DLC とは何か

AI-DLC は、要件定義(Inception)→ 実装(Construction)→ 運用(Operations)という開発ライフサイクル全体で、AI をチームの一員として動かすアプローチです。

ポイントは、AI の使われ方が「個人の補助ツール」から「チームメンバー」に昇格していることです。

  • PdM、エンジニア、QA、デザイナーが 同じ場で AI と対話 しながら要件を具体化する
  • AI は 質問を投げてくるたたき台を作るドキュメントを更新する
  • 人間は 意思決定・優先度判断・Go/No-Go・最終品質 を担当する

従来の「PdM が仕様を書いて、エンジニアが受け取って実装する」という非同期のバトンリレーではなく、全員と AI が同期的に要件を磨く のが特徴的でした。


人間と AI の役割分担

セミナーで繰り返し強調されていたのがこの分担でした。

人間が担うこと

  • 意思決定
  • 優先度判断
  • Go/No-Go
  • 品質の最終責任

AI が担うこと

  • 要求のたたき台作成
  • 要素分解(Unit of Work)
  • 実装案の作成と確認
  • ドキュメント整備と更新

「判断」は人間、「生成と整理」は AI。シンプルだけれど、実際にやってみるとこの線引きを保ち続けることが意外と難しい、というのが後述する学びにつながります。


3 つのフェーズ

AI-DLC は大きく 3 つのフェーズに分かれます。

1. Inception(要件定義)

  • ビジネス意図の定義
  • ユーザーストーリー作成
  • AI に不明点を質問させ、チームで回答して明確化していく

ここが 一番重要で、一番時間をかける フェーズです。AI が「誰が使う?」「何を達成したい?」「この条件のとき挙動は?」と 10〜20 個の質問を投げてきて、人間が [Answer] タグに答えていく、というスタイルで進みます。

2. Construction(実装)

  • 技術設計のたたき台
  • 実装・テストコードの生成
  • レビューと修正の反復

Inception で要件が明確になっている前提なので、受け入れ基準からテストケースまで AI が生成してきます。

3. Operations(運用)

  • デプロイ
  • 運用ドキュメント
  • 最終仕様を反映したドキュメント整備

ドキュメント作成という、人間がどうしても後回しにしがちなタスクをきっちり AI が拾ってくれるのが嬉しいポイントでした。


プロンプト集(参考)

セミナーで紹介された代表的なプロンプトを、参考までに置いておきます。

Inception:ユーザーストーリー作成

役割:
あなたは経験豊富なプロダクトマネージャーです。

タスク:
aidlc-docs/inception/user_stories.md にユーザーストーリーを記述してください。
ユーザーストーリーのみに焦点を当て、それ以外は含めないでください。

制約:
- 独自の判断や決定は行わないでください
- 不明点は [Question] タグで質問し、[Answer] タグを空欄で用意してください
- 完了後、レビューと承認を求めてください

プロンプトを使うときに共通して効いたのが、「独自の判断や決定はしない」「不明点は質問して回答待ち」「承認を求めてから次へ進む」 を毎回入れ込むことでした。ここを省くと AI が勝手に先走り、気づけば別物が仕上がっている、ということになりかねません。


実際に作ってみた:プロワンのお知らせ機能

セミナーでは手を動かすパートがあり、「プロワンに運営からのお知らせ機能を追加する」というテーマで AI-DLC を一周まわしてみました。

大まかな流れはこんな感じです。

  1. プロンプトで「何を作りたいか」をインプット
  2. AI がプロワンの仕様を踏まえて詳細化の質問を投げてくる
    • ここがとにかく独特でした。AI があらゆる角度から人間に質問し、回答、承認、という流れをひたすら繰り返します
    • 必然的にレビュー量が膨大になり、相当な疲労 がたまります。一連のプロセスは PdM とエンジニアが同席して進めました
    • ただ、最初は漠然としていたアイデアが、壁打ちするうちに「作りたいもの」の輪郭がはっきりしていく感覚は斬新で面白かったです
  3. 承認したインプットをもとに、以下を生成
    • ユーザーストーリー
    • ペルソナ
    • 受け入れ条件
    • モックアップ
  4. これらをもとに技術設計とコード生成へ

実際に触ってみた感触としては、

  • PdM・エンジニア・AI が同じ場で会話しながら要件を詰めていくので、従来の役割分担型の開発と比べて認識ズレが圧倒的に起きにくい
  • 「さて、何から考えようか?」というゼロベースのプロジェクトでも、Inception フェーズをちゃんと回すだけで作りたいものが形になるので、PdM が一人で悩む時間・エンジニアと議論する時間が大幅に削減される
  • ただし、ここまで仕様を細かく整理しても、コード生成は意外と苦戦する。現時点では「適用できる機能開発の種類には限界がある」と感じました。リファクタや大規模開発には向かない というのが正直な所感です

学び

実践して得られた学びを、列挙しておきます。

AI は「補助ツール」ではなく「チームメンバー」として扱ったほうが効く

  • PdM だけでなく、エンジニア・QA・デザイナーも 同じ場で AI と対話 する(Mob Elaboration)
  • AI が不明点の質問、たたき台の生成、更新の一括反映を担い、人間が承認して進める

Mob Elaboration で、実装前の認識ズレを早期に潰せる

  • ドキュメントの非同期伝達よりも、同期的に要件を具体化できる
  • 要件の曖昧さを抱えたまま走り出すリスクが減る

段階的に進めるほど効果が出る

  • 多段階の問題を「一発」で解かせない
  • 大きい機能は Unit of Work に分割すると並行作業しやすい
  • 「計画 → 質問 → 回答 → 生成 → レビュー」のサイクルを短く回す

プロンプト設計とコンテキスト管理が成果を左右する

  • 「独自の判断や決定はしない」「不明点は質問して回答待ち」「承認を求める」を固定文言として入れる
  • コンテキストを詰め込みすぎない(入力が多いと出力が浅くなる)
  • 長いチャットは定期的に切り替えてコンテキストをリフレッシュ(Lost in the Middle 対策)
  • 既存コード・設計思想・規約を明示して、独自解釈や古い知識による実装を防ぐ

ボトルネックは「生成」ではなく「レビュー」になる

ここが一番強く感じたポイントでした。

  • 生成物が増えるほど判断頻度が上がり、レビュー負荷が想像以上に高い
  • 決裁を求められる機会が通常の開発プロセスよりずっと多い
  • Inception フェーズで誤った方向に倒すと、Construction 以降で全然違うところに着地する危険がある
  • レビュー時間を 先に確保 し、小さい単位で生成 → レビューを回すと破綻しにくい

「AI が速く書いてくれるから開発が速くなる」というより、「人間の 判断とレビューの設計 が開発速度を決める」時代に入った、というのが率直な実感です。

適用領域は選ぶ

  • 新規機能や切り出しやすい領域から始めると導入しやすい
  • 大規模リファクタや巨大な既存コードベースは、コンテキスト理解の制約で難易度が上がる
  • 既存コードの品質がそのまま AI の生成品質に影響する(お手本にされてしまう)ため、対象コードの状態も見極めが必要

レビューする人のスキルは依然として重要

質疑応答でも議論になったポイントです。

  • 自分で書いていないコードは記憶に残りにくく、古い知識でレビューしているとレビュー品質が落ちる
  • そのため、一定以上のドメイン知識と技術力を持った人がレビューする前提 でないと、このやり方は成立しにくい
  • 裏を返せば、AI-DLC の現場ではエンジニア・QA・デザイナーが 分担してドメイン知識を頭に入れる ことが重要になる

プロワンでの導入方針

以上を踏まえて、プロワン開発チームでは次のように進めていこうと考えています。

  • 全社一律で AI-DLC を導入するのではなく、各チームで取り組み内容を決める
  • 向いている領域(新規機能・切り出せるスコープ・中規模の開発)から スモールスタート で試す
  • Inception フェーズに ちゃんと時間をかける 運用にする
  • Mob Elaboration の形で PdM・エンジニア・QA・デザイナーが同席し、AI を交えて要件を詰める場を設計する
  • レビューのキャパを先に確保 する。生成を増やすより、レビューを回せる体制を整えるほうが効く
  • プロンプトには「独自判断しない/質問する/承認を求める」を固定で入れる

おわりに

「個人の補助ツール」としての AI と、「チームの一員」としての AI は、使ってみると全く別物でした。

印象的だったのは、AI に質問攻めにされながら要件を詰めていくあいだに、チーム全員の頭の中にある解像度が揃っていく 感覚です。従来の開発では、PdM が資料を作り、エンジニアがそれを読み込み、レビューでズレに気づく、というプロセスにそれなりのコストを払っていました。AI-DLC ではそれが前倒しで起きる代わりに、人間側が「判断とレビューを回す体力」を問われる 開発スタイルに変わります。

ただし、現時点では全ての開発に適用ができる完璧なソリューションではないという印象です。大規模リファクタや巨大な既存システムに対しては、まだ難しい。それでも、新規機能の立ち上がりや、要件が曖昧な状態からの具体化においては、これまでの開発プロセスとは明らかに違う速さと手応えがありました。

プロワン開発チームでは、今回の学びを起点にスモールスタートで試していきます。この記事が、同じように AI を開発プロセスに組み込もうとしているチームの参考になれば嬉しいです。

ミツモアで一緒に働きませんか?

ミツモアでは、生成AIを活用して圧倒的な生産性を生み出し、日本のGDPを向上させるという目標に向けて、一緒に働く仲間を募集しています。

少しでも興味をお持ちの方は、カジュアル面談からでも大歓迎です。ぜひお気軽にご応募ください!