こんにちは。エンジニアの濱田 (@hamakou108) です。
プロダクト開発に携わるみなさん、 AI エージェントを活用していますか？
今やプロダクト開発のあらゆる側面で AI エージェントが利用されるようになりましたね。 AI エージェントと協業するための新たな開発ワークフローもいくつも公開されるようになりました。
M&Aクラウドでは AWS の提唱する AI-DLC (v1) を導入し、実プロジェクトで運用しています。標準のワークフローでも機能するものの、しばらくすると「ここは自分たちの開発フローとマッチしないな」と感じる箇所が見つかってきました。本記事では、そうしたギャップを extensions という仕組みで埋めてきた話を紹介します。
AI-DLC とは？
AI-DLC (AI-Driven Development Life Cycle) は、 AWS が提唱するソフトウェア開発方法論です 1。 AI エージェントが要件・設計・コード・テストを起案し、人間が各ステップを検証して次へ進めます。 AWS はこの方法論を AI コーディングエージェント向けのワークフロールールとして OSS 公開しており、 Claude Code や Cursor など複数のエージェントで利用できます。当社では、このルール群を全文日本語訳し、エージェントとのやり取りや成果物の生成がすべて日本語で行われるようにしています。
なお、2026年7月22日に AI-DLC Workflows 2.0 が GA となりましたが、当社はまだ v1 を使っています。以下は v1 の話としてお読みください。
AI-DLC のワークフローは INCEPTION / CONSTRUCTION / OPERATIONS の3つフェーズと、各フェーズに含まれる複数のステージの二階層で構成されています。
エージェントはステージを順に実行し、各ステージの終わりに成果物を提示して人間の承認を待ちます。ステージごとに読み込むルールファイルが決まっており、その集まりが .aidlc-rule-details/ に置かれます。
実プロジェクトに通してみると、各ステージはおおむね滞りなく進むものの、「ここは自分たちの開発フローとマッチしないな」と感じる箇所が見つかってきました。
- ユニット (作業単位) の生成と合わせて、見積もりの算出や Jira チケットの作成も行いたい
- Bolt (ユニットよりも短い実装サイクル) の粒度はルールに定義されていないが、 1 PR の大きさに直結するため自分たちの基準を決めたい
- 特定のステップで同じ誤りを繰り返すため、作業単位ごとに振り返りを実施し、得られた学びをハーネスに反映させたい
.aidlc-rule-details/ 配下の本体ルールを書き換えることも可能ですが、 AI-DLC には本体を触らずに済ませるための仕組みが用意されています。
extensions の仕組み
.aidlc-rule-details/extensions/ 配下にサブディレクトリを作ってファイルを置くと、ワークフロー開始時に再帰スキャンされ、全フェーズに効く横断的な制約として読み込まれます。ステージ手順の中に組み込むのではなく、外から全ステージに被せる形です。
.aidlc-rule-details/
├── workflow.md
├── common/
├── inception/
├── construction/
├── operations/
└── extensions/ # ここに足す
├── security/
│ └── baseline/
│ └── security-baseline.md # 標準で同梱される拡張
├── project-planning/
│ └── project-planning.md
├── bolt-decomposition/
│ └── bolt-decomposition.md
├── retrospective/
│ └── retrospective.md
└── ...
横断的と言っても、各拡張がすべてのステージに関係するわけではありません。エージェントは各ステージで、そのステージの目的と成果物に照らして適用すべき拡張を選びます。ステージの完了時には、拡張ごとに準拠・非適用を根拠つきで報告します。
拡張は次のような構成の指示書として記述されます。書式を一から考える必要はなく、標準で同梱されている security-baseline 拡張を雛形として利用できます。
- 何を義務付ける拡張か
- どのような条件で拡張を適用するか
- エージェントが遵守する必要のあるルールは何か
- 各ルールが準拠されていることをどのように検証するか
- ルールが準拠されていない場合に次の作業をブロックするか
security-baseline 拡張から要点を抜き出すと、次のような構成です (原典は英語です。自社用に日本語訳したものを本記事用に簡略化しています)。
# ベースラインセキュリティルール ## 概要 すべての AI-DLC フェーズに適用される必須の横断的制約。任意のガイダンスではなく、 ステージが必ず遵守しなければならないハードな制約として扱う。 ## 適用性に関する質問 要件分析の確認質問に、次の質問が自動的に含まれる。 ```markdown ## 質問: セキュリティ拡張機能 このプロジェクトにセキュリティ拡張ルールを適用すべきですか？ A) はい — すべての SECURITY ルールをブロッキング制約として適用する B) いいえ — すべての SECURITY ルールをスキップする X) その他 ``` ## ルール SECURITY-01: 保存時および転送時の暗号化 **ルール**: すべてのデータ永続化ストアは、保存時暗号化の有効化と転送時暗号化の強制を備えなければならない。 **検証**: - 暗号化設定ブロックなしにストレージリソースが定義されていないこと - 暗号化されていないプロトコルを使用するデータベース接続文字列がないこと ## ルール SECURITY-02: ...
拡張を追加することで、 AI-DLC におけるエージェントの振る舞いをカスタマイズできます。
- 本体の特定ステージの手順を上書き
- ステージの途中にステップを挿入
- 生成するファイルを削減
ここからは、先に挙げた 3 つのギャップを埋めるために当社で追加した拡張を、それぞれ紹介します。
事例 1: project-planning
ユニット生成ステージに、受け入れ基準 (AC) の定義、相対見積もり、開発期間の算出、 Jira チケットの作成という 4 つのステップを足した拡張です。
標準のユニット生成が出力するのは、ユニットの定義と責務、依存関係マトリクス、ストーリーとユニットのマッピングです。これで CONSTRUCTION に進むために必要な情報は揃うものの、社内の開発企画として承認を得るには不足している情報や作業がいくつかありました。
そこで project-planning 拡張を追加し、ユニット生成時に追加で生成する情報や実施する作業をルールにしました。
- AC は各ユニットに 3 件から 10 件、テストで検証可能な記述であること
- 見積もりは楽観値・最頻値・悲観値から PERT 期待値を算出し、判断根拠とともに表で記録すること
- 開発期間は、確認会 (QA) の工数を開発ストーリーポイントの 10% として加算したうえで算出すること
見積もりのロジック自体は拡張に書いていません。リファレンスストーリーとの突き合わせから PERT 計算までは storypoint-estimation という skill が担い、拡張側には「ユニット生成ステージでこの skill を呼ぶ」という接続だけを置いています。見積もりは AI-DLC を使わない場面でも実施するため、ロジックを拡張に閉じ込めてしまうと再利用できなくなるからです。
事例 2: bolt-decomposition
CONSTRUCTION を Bolt 単位で進めるための作法を定義した拡張です。
Bolt は AI-DLC が提唱する、従来のスプリント (数週間) を置き換える短い実装サイクルです。ただし OSS 公開されているルール群には Bolt の定義が含まれておらず、粒度を判断する材料がありません。実際に分解を任せてみると、実装完了まで何日もかかる大きな塊になることもあれば、単独ではマージできない断片に割れることもあります。判断の材料が与えられていない以上、無理もありません。
そこで bolt-decomposition 拡張を追加し、 Bolt 分解の際に守らなければならないルールを書きました。
- 粒度を「0.5日から2日で動作する状態に到達する単位」とし、原則 1 Bolt = 1 PR であること
- UI や API を伴う Bolt は単独でデモ可能な増分を生むこと
- デモできない Bolt はテストと静的解析が通り単独でマージできること
事例 3: retrospective
Bolt などの作業単位を1つ完了するごとに Keep / Problem / Try の振り返りを実施し、 retrospective.md というファイルとして記録することを義務付けた拡張です。
AI-DLC を実践する中で、エージェントが生成するコードやドキュメントの品質が安定しないケースが見受けられるようになりました。標準ワークフローには振り返りのステップがないため、当初はメンバー各自の判断で AI に振り返りを実施するよう指示していましたが、実施するかどうかも、記録の粒度も担当者次第となっていました。得られた学びが次の作業に引き継がれず、同じ誤りが繰り返されることもありました。
そこで retrospective 拡張を追加し、振り返りの実施契機と Try の書き方をルールとして書きました。
- 1 つの作業単位を完了したら、次の作業単位に着手する前に振り返りを実施すること
- Try の各項目は、エージェントへの注意や決意ではなく、ハーネス (CI 、リポジトリの rules 、 AI-DLC 拡張、 CLAUDE.md) の変更として書くこと
- Try に書くのは、その記述が事前にあれば今回の Problem が防がれたと言えるものに限ること
Try はすべて提案に留め、振り返りの中でハーネスを変更しないようにしています。最初はハーネスの変更まで実施する形にしていましたが、的確とは言えないハーネス改善が行われることが多々あり、方針転換しました。 Try の提案内容の質向上が今後の課題です。
まとめ
AI-DLC v1 の標準ワークフローで自分たちの開発フローとマッチしない箇所を、本体を書き換えずに extensions として補完する事例を紹介しました。適切な拡張を追加することで、当社独自のワークフローを再現性高く実施できるようになったと感じています。一方、不適切な拡張は人間の作業工数や認知負荷を逆に増加させることもあり、うまくコントロールするのはなかなか難しいです。
なお AI-DLC v2 のリポジトリを見ると、拡張の仕組みは plugins という別の形式になっており、ここまでに書いた拡張はそのままでは適用できません。とは言え、エージェントに指示すれば労力を掛けずに移行可能だろうと楽観的に考えているところです。
AI-DLC を導入したものの標準のままでは回しづらいと感じている方にとって、この記事が参考になれば幸いです。
