1. 始めに
こんにちは。LIFULLでエンジニアをしている稲垣です。
2025年10月の3日間、AWSが提供する「AI駆動開発ライフサイクル（AI-DLC）Unicorn Gym」の研修に参加しました。この研修では、6つのチームに分かれて、AI-DLCを活用しながら実際のプロジェクト課題に取り組みました。
私たちのチームが取り組んだのは、「サポートが終了したサービスの新基盤への移行計画」です。具体的には、Amazon Linux 2のサポート終了（EOL: End of Life）への対応として、既存システムを新しい基盤へ移行する計画の策定に取り組みました。
このようなOSマイグレーションでは、以下のような課題に直面します：
- 取り組むべき手順や優先順位が不明確
- 移行オプションの調査と比較に数日かかる
- リスクの洗い出しが担当者の経験に依存し、見落としが発生しやすい
この記事では、これらの課題に対してAI-DLCがどのように解決策を提供してくれたのか、実際の開発プロセスと得られた学びを共有します。特に、AIがルーティンタスクを処理する間に、チームは問題解決や意思決定に集中できる「ダイナミックなチームコラボレーション」がどのように実現されたかをお伝えします。
2. 研修の内容とカリキュラム
AI-DLCとは
AI-DLC（AI-Driven Development Lifecycle）は、AIが開発プロセスを主導する開発手法です。単なるコード生成ツールにとどまらず、要件定義から設計、実装、テスト、運用まで、開発の各フェーズでAIがタスク分解や実装を主導し、人間がレビュー・承認を行います。今回の研修では、Amazon Q Developerを使用してAI-DLCを実践しました。
AI-DLCの開発フェーズ
AI-DLCは大きく3つのフェーズで構成されています：
Inception Phase（構想フェーズ） - 現状分析、技術選定、計画策定を行うフェーズ
Construction Phase（構築フェーズ） - 実装、テスト、ドキュメント作成を行うフェーズ
Operation Phase（運用フェーズ） - 本番環境へのデプロイとインシデント管理を行うフェーズ
私たちのチームの課題
研修では6つのチームがそれぞれ異なる課題に取り組みました。私たちのチームは「サポートが終了したサービスの新基盤への移行」という課題に挑戦しました。
この課題は、参加チームの中でも比較的珍しいものでした。AWSの担当者によると、「AI駆動開発ライフサイクル（AI-DLC）Unicorn Gym」では、これまで主にアプリケーション開発の課題が扱われてきましたが、OSマイグレーションという領域でAI-DLCを活用するのは初の事例とのことでした。
具体的には、以下の点でほかのチームとは異なる挑戦となりました：
- 活用事例が少ない：インフラ移行という領域でのAI-DLC活用は前例が少ない
- 技術的な複雑さ：既存システムの完全な理解と、複数のAWSサービスにまたがる変更が必要
- リスク管理の重要性：本番環境への影響を最小限に抑える慎重な計画が求められる
この特徴が、AI-DLCの新しい活用方法を模索する良い機会となりました。
私たちのチームの取り組みの流れ
今回の研修では、このAI-DLCのフェーズに沿って、OSマイグレーション計画を進めました。以下は、私たちのチームが実際に取り組んだ内容です。
Inception Phase（構想フェーズ）
- 既存システムの構成調査とAWSインフラの棚卸し
- 移行方法の比較検討と技術的制約の分析
- ユニット（AI-DLCで用いる作業単位）への分割と依存関係の整理
Construction Phase（構築フェーズ）
以下の作業を並行して実施（研修時間内では途中まで）：
- リスク管理台帳の作成と対応策の検討
- 技術調査レポートや運用手順書の作成
- ベースイメージの作成
私たちのチームの取り組みの流れ図
図1：私たちのチームの取り組みの流れ。（Inception PhaseからConstruction Phaseの途中まで実施）
3. AI-DLCを活用した開発プロセス
本章では、AI-DLCを実際どのように活用して開発を進めたかを紹介します。
AI-DLCの基本サイクル
AI-DLCでの開発は、以下のサイクルを繰り返します：
- AIにプランを作らせる
- 人がプランをレビュー
- AIがプランを修正
- AIがプランを実行
- 人が結果を確認
図2：AI-DLCの基本サイクル。このサイクルを繰り返して成果物を完成させる
当初の構想とAI-DLCによる方針転換
プロジェクト開始時、私たちはAmazon Linux 2のEOL対応として、Amazon Linux 2023へのOSリプレイスを検討していました。既存のAmazon EC2（仮想サーバー）環境を維持したまま、OSのみをアップグレードする方針です。この方針は、既存システムへの影響を最小限に抑えられるという理由から選択しました。
しかし、AI-DLCを活用して検討を進める中で、方針が大きく変わりました。AIが生成した技術調査レポートで複数の移行オプションを比較した結果、Amazon ECS（コンテナ実行基盤）へのコンテナ化が望ましいという提案がありました。
理由は以下の通りです：
- 環境の再現性（不変性）の向上により、デプロイやロールバックが容易になる
- 将来的なミドルウェアアップグレードの基盤となる
- 長期的な保守性と運用効率の向上が期待できる
コンテナ化という選択肢自体は、チーム内で漠然と認識していました。しかし、AI-DLCが生成したレポートを見るまでは、その具体的なメリットや実現可能性が明確ではありませんでした。AIが各オプションのメリット・デメリット、工数、コストを整理してくれたことで、チームでの議論が活性化しました。「環境の再現性（不変性）の向上」という観点や、「将来的なアップグレードの基盤」という長期的な視点は、AIの提案によって初めて明確になった部分です。
チームでの議論を経て、最終的にコンテナ化の方針で Construction Phaseを進めることに決めました。これは、AI-DLCが単なる作業支援ツールではなく、技術的な提案を行い、プロジェクトの方向性の決定に良い影響を与えてくれました。
図3：AI-DLCによる技術選定の変化。OSリプレイスからコンテナ化へ方針転換
Inception Phaseでの実践
Inception Phaseでは、現状分析と技術選定を行いました。
AIと人間の役割分担
AI-DLCでは、AIがルーティンタスクを処理することで、人間は問題解決や意思決定に集中できます。
AIが担当：
- 既存システムの構成情報の収集と整理
- 複数の移行オプション（OSリプレイス vs コンテナ化）の比較レポート生成
- 各オプションのメリット・デメリットの洗い出し
人間が担当：
- 移行方針の最終決定（ECSコンテナ化を選択）
- ビジネス要件との整合性確認
- 技術的な実現可能性の判断
Construction Phaseでの実践
Construction Phaseでは、計画策定とリスク管理を行いました。
AIと人間の役割分担
AIが担当：
- ユニットへの分割案の生成
- 依存関係図の作成
- リスク項目の網羅的な洗い出し
- リスク管理台帳の初稿作成
人間が担当：
- タスクの優先順位付け
- リスクの重要度評価と対応策の決定
- 実装スケジュールの調整
たとえば、依存関係図の生成では：
- 人間がシステム情報を提供
- AIがドキュメントを分析し、依存関係図を自動生成
- 人間が図をレビューし、不足部分を指摘
- AIがフィードバックを反映して修正
- チームが図を見ながら移行順序を議論
Mob Construction（いわゆるモブレビュー／モブ作業。チーム全体でのフィードバックと問題解決）の実践：
Mob Constructionは、AI-DLCにおけるチーム開発の手法で、AIが生成した成果物に対してチーム全員でレビューとフィードバックを行い、より良い解決策を議論する取り組みです。
リスク管理時には、AIが洗い出したリスクをチームでレビューしました。「このリスクは優先度が高い」「この対応策では不十分」などフィードバックを行い、チームでリスク対応策をブレインストーミングし、実装の優先順位を議論して決定しました。
AIがリスクの洗い出しや台帳作成を処理している間に、チームメンバーは技術的な実現可能性の議論、過去の経験からの知見共有、より効果的な対応策の検討に集中できました。これにより、作業効率が向上しただけでなく、チーム全体の技術力向上にもつながりました。
4. 直面した課題とAI-DLCでの解決
課題1：技術選定の複雑さ
Amazon Linux 2023への直接移行とECSコンテナ化、どちらを選択すべきか判断が難しい状況でした。
AI-DLCの活用：
- 複数の移行オプションを比較した技術調査レポートを生成
- 各オプションのメリット・デメリット、工数、コストを整理
- チームでの議論の材料として活用
結果：
長期的な視点でECSコンテナ化を選択する判断ができました。
課題2：リスク管理の網羅性
OSマイグレーションには多くのリスクが潜んでおり、見落としがないか不安でした。
AI-DLCの活用：
- 技術的なリスクを網羅的に洗い出し
- リスク管理台帳の初稿を作成
- リスク評価マトリックスを生成
結果：
30個以上のリスクを識別し、優先順位をつけて対応策を検討できました。
課題3：ドキュメント作成の負荷
移行計画書、技術調査レポート、運用手順書など、多くのドキュメントが必要でした。
AI-DLCの活用：
- ドキュメントの初稿を自動生成
- フォーマットの統一
- 情報の整理と構造化
結果：
ドキュメント作成の時間を大幅に削減し、内容のレビューと改善に時間を使えました。
5. 研修を通じて得られた気付きや学び
AI-DLCを使った開発スタイルについての気付きと今後の活用
AIは技術的な提案も行う
当初はOSリプレイスを検討していましたが、AI-DLCが生成した技術調査レポートでECSコンテナ化を提案され、最終的にその方針を採用しました。AIは単に指示されたタスクをこなすだけでなく、より良い選択肢を提示することもあると実感しました。
今後の業務では、新しいプロジェクトの技術選定時に、AIに複数のオプションを比較させることで、より客観的な判断材料を得られると考えています。
プロンプトの重要性
AIに何を依頼するか、どのようにコンテキストを与えるかで、成果物の質が大きく変わります。効果的なプロンプトを書くスキルが、今後ますます重要になると感じました。
今回の研修で効果的だったプロンプトの要素：
- 役割の明確化: 「あなたは熟練したクラウドエンジニアです」のように、AIに期待する専門性を明示
- 具体的なタスクの指定: 「aidlc-docs/inception/migration_plan.md ファイルにステップを記載してください」のように、成果物の形式と保存場所を明確に指定
- 作業プロセスの指示: 「計画を作成したら、私のレビューと承認を求めてください」のように、レビューのタイミングを明示
- 制約条件の設定: 「独自の判断や決定は行わないでください」のように、AIが勝手に判断しない範囲を明確化
日常業務では、ドキュメント作成や技術調査の際に、これらの要素を含めたプロンプトを作成することで、AIの支援を最大限活用できます。
レビューの重要性
AIが生成した内容をそのまま使うのではなく、必ずレビューして修正する必要があります。AIの提案を批判的に評価する能力が求められます。
コードレビューと同様に、AIが生成した成果物のレビューを習慣化することで、品質を担保しながら効率化を実現できます。
チーム開発での学び
役割分担の明確化
AIが得意なタスクと人間が得意なタスクを明確に分けることで、効率的に作業を進められました。
AIが得意なタスク：
- 情報の収集と整理（既存システムの構成情報、移行オプションの比較）
- ドキュメントの初稿作成（技術調査レポート、リスク管理台帳）
- 網羅的な洗い出し（リスク項目、依存関係）
- 定型的な作業（タスク分割、フォーマット統一）
人間がやるべきタスク：
- 最終的な意思決定（移行方針の選択、優先順位の決定）
- ビジネス要件との整合性確認
- 技術的な実現可能性の判断
- AIが生成した成果物のレビューと修正
- チーム内での議論とコンセンサス形成
この役割分担により、AIがルーティンタスクを処理する間に、人間は問題解決や意思決定に集中できました。
OSマイグレーションという課題から得た学び
活用事例が少ない領域でのAI活用
一般的な開発タスクではない領域でも、AI-DLCは有効に活用できることがわかりました。特に、複数の移行オプションを比較する技術調査レポートの生成や、30個以上のリスクを網羅的に洗い出す作業では、AIの支援が大きな価値を発揮しました。
段階的なアプローチの重要性
大きな移行プロジェクトを複数のユニットに分割し、依存関係を整理することで、リスクを管理しながら進められることを学びました。
6. まとめ
この研修を通じて、AIがルーティンタスクを処理する間に、チームは問題解決や意思決定に集中できる「ダイナミックなチームコラボレーション」を実践的に学ぶことができました。
また、OSマイグレーションという活用事例の少ない領域でも、AI-DLCは有効に活用できることを実証できました。
LLMは、単なるコード生成ツールではありません。AI-DLCという開発手法を通じて、LLMを開発のライフサイクル全体で活用することで、チームの生産性と創造性を高めることができます。今後の業務でも、この経験を活かして、より効率的で質の高い開発を実現していきたいと思います。
最後に、LIFULLではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。
