こんにちは。ウォンテッドリーでバックエンドエンジニアをしている小室 (@nekorush14) です。2026年8月27日にJAWS-UG AI-DLC #02 にて「AI-DLCをチーム開発に適用しようとしている話」と題して LT 発表を行いました。今回はこの内容に加え、当日登壇後にご質問いただいたことも含めつつ、4〜5人規模の開発チームでどのようにAI-DLCを試行錯誤しながら組み込みんできたかを共有します。
JAWS-UG AI-DLC #02：AI-DLC勉強会 (2026/08/27 19:00〜)
目次
はじめに
コーディングエージェントの普及により、実装を任せることが当たり前になりつつあります。一方で、同じような指示を出しても生成物の粒度や設計の方向が揃わない場面が出てきます。
AI-DLC Workflows では、曖昧な要件を明確するフェーズ (Inception) から計画を立て実装し (Construction)、デプロイや監視を行う (Operation) 流れを順番に進めながら開発を進めます。
GitHub - awslabs/aidlc-workflows: AI-Driven Life Cycle (AI-DLC) adaptive workflow steering rules for AI coding agents
AI-DLC では Inception フェーズを開発メンバーだけではなく、ビジネス、QA、インフラなど関連するステークホルダー全てを集めてオフラインで認識を合わせるモブエラボレーションが特徴的です。
AI-Driven Development Life Cycle: Reimagining Software Engineering | Amazon Web Services
一方で、ウォンテッドリーでは機能開発や施策のビジネス背景などの情報を全て GitHub Issues で管理しており、エンジニア一人ひとりが PdM 的な立ち位置で Issue を立ててビジネス背景を考えて実装し、施策のモニタリングをすることがよくあります。Issue で仕様と設計を合意してから実装に入る進め方は、AI-DLC が用意している進め方と重複する箇所が出てきます。
また、LT の後にはどのようにチームへ導入したのかという点にも関心が寄せられました。本稿では、導入の判断軸とチーム適用の過程で直面した課題への対処を共有します。
どのようにチームに導入したか
AI-DLC Workflows 導入の狙いはチームのコーディングエージェントによる開発をより安定させることでした。AI-DLC Workdflows が定義する Phase、Stage、承認ゲートと生成されるドキュメントにより、コーディングエージェントの挙動が安定すると考えたためです。
導入の時点で、チームではコーディングエージェントに対するルールを AGENTS.md に集約しており、技術・アーキテクチャの意思決定を ADR として残す運用としていました。
小さく導入していつでも変えられる状況にする
AI-DLC Workflows を認知してから数週間で導入することにしましたが、初めに感じたのは想定以上に大規模な概念の導入であることでした。これまで各チームメンバーが独自の工夫で開発スピードと品質を担保しながら進めていたワークフローを単一のワークフローに固定することに見えるため、導入のハードルは高いように感じていました。実際、LT 登壇後にご質問いただいた方も同様の悩みをおっしゃられていました。
今回の導入を決めるにあたり1、2名のアーリーアダプターが使用感をチームに共有し、徐々にチーム全体に広めていくような段階を踏んでワークフローに馴染んでもらう戦略を取ることにしました。また、仮に導入後も馴染まないという場合は AI-DLC Workflows を使用しなくても良いことにしました。
これにより導入への心理的な障壁が軽減され、かつチームへの適用もスムーズに実施されていきました。
AI-DLC Workflows の導入から今回の LT 登壇まで2ヶ月程度の期間があり、期間中に AI-DLC Workflows の v2 も GA となりました。以降では v1、v2 を適用する中で発生したそれぞれの課題について共有します。
v1 で発生した課題と解決策
開発スピードの低下と固有ワークフローの逸脱
AI-DLC Workflows は v1 から導入しており、以下のような課題に直面しました。
v1 導入当初の所感として Stage (UserStory の作成、Reverse Engineering など個々の作業区分) が想定上に多数存在すると感じました。これにより、導入前の開発スピードが出せていませんでした。
この要因は以下の通りです。
- Issue を書いてから実装に入るため既に Inception 相当の Phase を通過していたにもかかわらず、Phase が実質的に重複して実行されていた
- AI-DLC が前提とする承認フローをそのまま適用してしまったためウォンテッドリーの開発スタイルとミスマッチになっていた
また、Issue や ADR で決定した事項が後続の作業で蒸し返され、再びコーディングエージェントに対して背景や決定事項を伝えたり、論点を整理したりする事象が発生していました。
チーム固有のワークフローも実行できるように仕向ける
これらの課題を解消するため、AGENTS.md に、チームが既に持っているワークフローと、状況に応じて飛ばしてよい Stage を明示するようにしました。また、ADR の生成もワークフローの中で実施させ、後続の作業で参照されるように仕向けました。細かい部分ですが、コーディングエージェントからの確認は AskUserQuestion ツールで受け取るように明示しました。
ADR を AI 向けのコンテキストとして書き残す運用は過去のブログで詳しく紹介しています。
/assets/images/24018795/original/photo-1522071820081-009f0129c71c?1781744582&w=1440)
人が方針を立て AI が自律的に回る開発ループを設計してチーム開発に組み込む | Wantedly Engineer Blog
これらの対策により、Issue で合意済みの内容に対応する Stage をスキップし、作業に必要な Stage だけを通せるようになりました。また、アーキテクチャの判断は ADR としてコーディングエージェントのコンテキストとなるため、同じ論点が蒸し返される場面も減っています。
v2 で見えてきた 2 つの課題
AI-DLC Workflows v2 では Scope の遷移と Audit の出力が Agent Hooks で決定的に動作するようになり、コーディングエージェントの確認もデフォルトで AskUserQuestion に相当するツールが使用されるようになりました (コーディングエージェントのハーネス実装によって名称は異なります)。Phase や Stage の単位で中断した作業の再開もやりやすくなっており、作業中にコーディングエージェントが得た知見を Knowledge として蓄積する仕組みも入っています。
GitHub - awslabs/aidlc-workflows at v2
一方で、どの Scope を選ぶかやワークフローを終えた後の挙動は、依然としてチーム側で決める必要があります。以降は v2.6.17 の時点で確認した内容です。
解きたい課題に対する Scope の選定基準がチームにない
Issue で意思決定を済ませた内容に対して Feature の Scope を選ぶと Ideation の Stage がひと通り回り、v1 と同じように開発スピードが落ちてしまいます。
上図は v2.6.121 の System Message
機能追加であっても Feature が要求する全 Stage が必要とは限らず、PoC の粒度がちょうど合う場面もあります。これらは標準で用意されている各 Scope の理解が浅いことで発生しているものと考えていて、現在もチーム内で試行錯誤的にどのスコープがどの作業に対して適切かの検討を進めています。
ワークフローを終えた後も Audit ログが追記され続ける
v2.6.17 では Audit ログの出力が無条件に行われるため、ワークフローを起動していない通常の対話セッションや完了済みの Intent に対して差分が発生する状態でした。開発を進める上で致命的な問題ではありませんが、開発速度を低下させる要因となるため、対応が必要と考えました。
今回の対応策として、AI-DLC Workflows の Agent hooks をラップした Agent hooks を用意し、Intent が Complete 状態のとき、または Intent 自体が存在しないときは Audit を出力しないようにしました。AI-DLC Workflows のリポジトリでも同様の事象が報告されており、v2.6.20 で解消しています。
[Bug]: `aidlc-log-subagent` gates on the audit shard existing rather than on workflow state - once a clone's shard is committed, every subagent completion in every session appends to the ledger, framework or not · Issue #710 · awslabs/aidlc-workflows
まとめ
今回は、AI-DLC Workflows を 4〜5 人規模のチームに導入した判断軸と、適用の過程で直面した課題への対処について共有しました。AI-DLC Workflows の導入をスムーズに進めるためには提供されているワークフローをチームが既に持っている意思決定の場と重複しない形式に組み直すことが有効です。
v2 には、カスタム Scope の定義と Stage の override という仕組みが用意されています。これにより、v1 では AGENTS.md に文章として書き出していたチーム固有のワークフローを Agent Hooks として構築された決定的なフローとして表現できます。
どの規模の変更にどのような Stage が必要かを見極めた上で、チームの開発スピードに合わせた Scope を定義し、開発スピードと品質を両立したチーム開発や組織への適用などを進めていきます。
参考文献
JAWS-UG AI-DLC #02：AI-DLC勉強会 (2026/08/27 19:00〜)
人が方針を立て AI が自律的に回る開発ループを設計してチーム開発に組み込む | Wantedly Engineer Blog
/assets/images/16907545/original/ec791cd3-ea53-45e2-bc6f-a1262b413594?1753696883)
/assets/images/7052304/original/49100b17-5866-4cec-b50b-a37ea73565e9?1638782149)
/assets/images/7053725/original/28d1b135-13b4-4f46-895f-d5f5fb5ae243?1624246858)
