AIDDで開発プロセスを再設計する — AI駆動開発の試行錯誤から得た学び

こんにちは。LINEヤフー株式会社ショッピングSBUの新堂です。Yahoo!ショッピングでは、AIDD（AI Driven Development）の推進メンバーとともに開発プロセスの再設計に取り組んでいます。

Yahoo!ショッピングはコンポーネント100以上、リポジトリ3,000超、27年の歴史を持つサービスです。この規模のシステムに手を加えるには、影響範囲の調査から要件整理、関係者への承認まで、開発着手前の準備だけで多大な工数がかかっていました。加えて、各システム担当者のドメイン知識への依存も大きな課題でした。この状況を変えるために、AIに設計工程そのものを任せるAI-DLC（AI-Driven Development Lifecycle）の導入を決めました。

しかし、導入には大きく2つの壁がありました。既存の承認フローや品質基準を維持したまま導入すること、そしてAIにこの大規模システムの関係性を理解させたうえで設計させることです。本記事では、AWS社が提唱するAI-DLCをベースにAIDDを構築し、これらの課題に取り組んだ過程を紹介します。

1. 設計工数とドメイン知識の壁

Yahoo!ショッピングでは、システム横断の開発案件に対して段階的な承認フローが設けられています。案件が立ち上がると、まず全体方針のレビュー、次に詳細設計のレビューを経て、ようやく開発に着手できます。

既存の開発フロー（導入前）

特に工数がかかっていたのが、各段階の承認に向けた要件と設計情報の整理です。機能・非機能要件やシステム構成を事前に練り上げる必要があります。しかし、Yahoo!ショッピングのシステムは巨大かつ複雑で、要件の洗い出しは担当者のドメイン知識に強く依存していました。プロジェクトマネージャーやテックリードが主導しようにも知識の壁が厚く、確認事項を一つつぶすにも多大な調整コストがかかっていました。

目指したのは、ドメイン知識の壁を下げ、誰もが設計工程を推進できる状態です。

2. AI-DLC導入の壁

2025年7月、AWS EBC（Executive Briefing Center）にてAI-DLCの紹介を受け、ワークショップを実施しました。AI-DLCとは、コーディング補助ではなく、企画から運用まで開発ライフサイクル全体をAIエージェントが支援するアプローチです。AIが要件の整理や設計の分解を行い、人間はレビューと意思決定に集中します。これまでドメイン知識を持つ有識者に頼っていた工程をAIが担うことで、「有識者がやればできる」から「詳しくなくてもある程度できる」への転換を目指すものです。

AI-DLC導入タイムライン

2025年8月から9月にかけて、開発分野に絞ったトライアルを実施しました。課題はあったものの一定の成果が出たため、その後、企画設計フェーズへの適用を試みました。しかし、グリーンフィールド（新規構築）を前提とした手法をブラウンフィールド（既存システム）にそのまま適用するのは難しく、特にAIに渡すべきコンテキストの量と複雑さが想定を大きく超えていました。この過程で、手法そのものではなく、AIに渡す情報基盤に根本的な課題があることが見えてきました。

3. AI-DLC導入で浮き彫りになった情報基盤の課題

AI-DLCを本格導入しようとして気づいたのは、AIに渡すべきドメイン知識がそもそも整理されていないという問題でした。ドキュメントは各システムに存在していましたが、形式や保存先、情報の粒度がバラバラでした。また、システム間の関係性を網羅した資料はなく、各プラットフォーム内に閉じた構成図がある程度でした。AIにコンテキストとして渡そうとしたことで、こうした情報基盤の課題が改めて浮き彫りになりました。

この課題を受けて、AI-DLCの導入を一度立ち止まり、まずAIが扱える形で情報基盤を整備し直すことにしました。AIに正確な出力を求めるには、正確なコンテキストを渡す必要があるためです。

ドメイン知識のAI Ready化

設計フェーズに応じた情報粒度の整理

私たちはまず、AIに渡す情報を2つの軸で整理しました。1つは設計フェーズに応じた粒度です。全体設計の段階ではシステム全体の構成や関係性、詳細設計ではソースコードレベルの仕様が必要です。もう1つはドメインごとの分類で、商品検索やカートといった機能領域ごとに情報をまとめました。

そのうえで、ユビキタス言語の定義、C4モデルによるシステム構成図、リポジトリや各システムの担当者情報を整備し、MCP（Model Context Protocol）サーバーとして実装しました。リリーススケジュールやAPIドキュメントなど、Yahoo!ショッピングの構造を決定づける情報をAIに直接提供できるようになり、ハルシネーションを抑制し、より精度の高い出力を得られるようになりました。

MCPサーバーの構成図

既存のドキュメントの再構成に加え、これまでドキュメント化されていなかった情報も新たに作成しました。AIの出力精度は渡す情報の質に左右されるため、ここを省略するわけにはいきませんでした。こうして情報基盤が揃ったことで、ようやくAI-DLCの本格的な適用に進める土台が整いました。ここからは、AI-DLCをLINEヤフーの開発体制に合わせて再設計したプロセスをAIDDと呼び、その具体的な設計を紹介します。

4. AIDDを既存プロセスに組み込む

ドメイン知識の基盤が揃い、AIDDのInceptionフェーズが機能するようになりました。Inceptionフェーズとは、ビジネス意図を要件・ユーザーストーリー・作業単位に分解する流れです。

AIDD導入後の開発フロー

このフェーズを、セクション1で触れた承認フローに合わせて2段階に分けました。Phase 1（全体設計承認）では要件分析・ユーザーストーリー・ワークフロー計画を経て、全体設計の承認資料を出力します。ここで一度シニアエンジニアによるレビューを実施します。全体設計の段階で方針を誤ると後続の手戻りが大きくなるため、この時点で合意を取ることが重要です。

その承認を得て初めてPhase 2（詳細設計承認）に進みます。Phase 2では改修対象の作業リポジトリを絞り込み、処理フローを含む詳細なアプリケーション設計とユニット分解を行います。最後に詳細設計承認会用の資料を生成し、再びレビューを実施します。

AIDDでは、AWSのAI-DLCをそのまま適用するのではなく、Yahoo!ショッピングの開発体制に合わせた独自の設計を加えています。

レビュー負荷の軽減

組織への定着に向けて実施したワークショップ（セクション5）を通じて、AIの出力量が多くレビュー負荷が高いという声が挙がりました。そこで、レビュー負荷を下げるための工夫を2つ取り入れました。

質問の回答担当を明示する設計：ビジネス要件は企画担当、システム要件はエンジニア、UX観点はデザイナーと振り分けることで、各担当者が自分の専門領域のみに集中してレビューできるようにしました。
質問時の情報先埋め：AIがレビュアーに質問する際、必ずMCPサーバーから取得した情報をもとに候補を先に提示したうえで確認を求める設計にしました。情報がない状態で質問しないことで、エンジニアは候補の過不足を補正することに集中できます。取得する情報の粒度はフェーズに応じて変わり、Phase 1ではシステム構成図レベル、Phase 2ではAPI仕様やデータフローといった詳細な情報を段階的に引き出します。

カスタマージャーニーの独自追加

AWSのAI-DLCにはカスタマージャーニーの工程は含まれていませんが、Yahoo!ショッピングのデザイナーが普段の業務で実践しているデザインの考え方や進め方を落とし込み、Inceptionフェーズの中にカスタマージャーニー生成の工程を独自に組み込みました。AIがユーザーストーリーの行動分岐からシナリオを推定して提案し、デザイナーがレビューする流れです。これにより、デザイナーの観点を含んだ設計資料を生成できるようになり、将来的にはこの成果物を入力としたデザインモックの自動生成も視野に入ります。

こうした設計のもとで、AIDDの生成物からレビュー用の仕様書を自動生成することで、承認準備の工数を大幅に削減しました。以下は、AIが出力した設計資料の一例です（サンプルデータを使用しており、一部をぼかしています）。セクション3で整備したドメイン知識が反映され、システム間の関係性を踏まえた設計が出力されるようになりました。

AIが出力した設計資料の一例（左：詳細はぼかしています、右：テキストはサンプルに置換しています）

一方で、AIの出力には誤りや考慮漏れが含まれる可能性があるため、各段階でのシニアエンジニアによるレビューはより重要になります。この「AI生成・人間レビュー・段階的承認」というサイクルを回すことで、AIエージェントによる生産性と、大規模システムに求められる品質を両立させています。

また、AIDDのプロンプトを独自のAgent Skillsとして定義し、フェーズごとにMCPツールを強制することで出力を安定させました。すべての機能をスキル化し、コマンド実行のみで完結する設計にしています。これにより、プロジェクトマネージャーが自ら設計からレビュー資料の生成までを完結できる環境を実現しました。

5. 組織への定着：ワークショップの実施

仕組みを整えても、現場で使われなければ定着しません。エンジニア以外のメンバーにとっては、GitHubやAgent Skillsの実行に不慣れな場合もあり、ツールの導入だけでは定着しないと考えました。

そこで、オフラインのワークショップを計4回、各3〜4時間で実施しました。ワークショップではAIDDの説明だけではなく、実際の案件を題材にしたハンズオンを中心に進めました。その結果、「実務で使っていくイメージが湧いた」という声をいただき、早期の定着につながりました。

また、実際に手を動かしてもらうことで、設計時には想定していなかった箇所で詰まるケースも見つかり、プロンプトやフローの改善につなげることができました。セクション4で述べたレビュー負荷の軽減も、こうしたワークショップでの声をもとに進めた改善です。今後も新たな仕組みを取り入れ、既存のフローを改善する際には、ワークショップで実際の利用者の声を集め、改善に反映するサイクルを回していく考えです。

6. 導入の成果

セクション1で掲げた「ドメイン知識の壁を下げ、誰もが設計工程を推進できる状態」は、AIDDの導入によって実現に近づいています。実際に企画職が自らAIDDを実行し、起案から全体設計承認までを主導できるようになりました。これまでシステム担当者のドメイン知識に依存していた設計工程が、情報基盤とAgent Skillsによって誰でも推進できる形に変わっています。

定量面では、企画工数が導入前の約2ヶ月から1ヶ月ほどに短縮されました。ドメイン知識の構造化やAIDDによる設計資料の自動生成など、複数の取り組みが重なった結果です。

おわりに

AIDDは「AIにコードを書かせる」話ではなく、開発ライフサイクル全体を再設計する取り組みです。この過程で得た学びを3つ共有します。

AI Ready化が前提条件：ドメイン知識の構造化なしにAIDDは機能しません。その整備の過程で、組織として十分に向き合えていなかった課題も見えてきます。
承認フローとの統合：AIのスピードと品質を両立するには、既存のレビューフローや品質を保つ仕組みをAIDDのフローに組み込むことが重要でした。
現場での体験が定着の鍵：ツールの導入だけでは不十分で、実際の案件を題材にしたハンズオンが浸透と改善の両方につながりました。

現在はオペレーション領域への拡大、テスト工程へのAIDDアプローチ、デザインモック自動生成の検証にも取り組んでいます。この試行錯誤が、AI駆動開発の導入を検討されている方の参考になれば幸いです。