グラレコ
はじめに
AI-DLC Workflows v2（awslabs/aidlc-workflows）は、AWS Labs が公開している、AIコーディングエージェント向けの開発ワークフローのルールセットです。公式の定義はこうです。
AI-DLC (AI-Driven Development Life Cycle) is a methodology for structuring AI-assisted software development into repeatable, traceable phases.
（AI-DLC は、AI支援のソフトウェア開発を、反復可能で追跡可能なフェーズへと構造化するための方法論です）
「5フェーズ32ステージ・14エージェント・9スコープ」という数字が先に目に入りますが、この記事ではその数字の内訳ではなく、なぜこういう形になっているのかを扱います。
設計思想を先に押さえておくと、個々の仕様が「そういう理由でそうなっているのか」と繋がって読めるようになります。手を動かす前に全体像を掴んでおきたい方向けです。
この記事で扱うこと
- 何を解決しようとしているのか（断片化とハーネス中立）
- 「Small Mob, Broad Agents」 — なぜ細かい専門家を並べないのか
- 二層構造のオーケストレーション — 順番を決めるのはAIではない
- 走らせると実際に何が画面に出るのか
- 成果物がどこに残るのか（space と intent）
- 独立した3つの軸（スコープ・深さ・テスト戦略）
🧩 何を解決しようとしているのか
出発点は、AI支援開発の断片化です。
エージェントに開発を任せるとき、ツールごとに設定ファイルの置き場所も書き方も違います。Claude Code なら CLAUDE.md、Cursor なら .cursor/rules/、Kiro なら .kiro/steering/。同じ「うちのやり方」を、ツールを変えるたびに書き直すことになります。
AI-DLC Workflows は、これを ハーネス中立（harness-neutral） な1つのコアで解こうとしています。方法論とルールを1か所に置いて、各ツール向けの形に配布する方式です。
対応しているのは Claude Code、Kiro CLI、Kiro IDE、Codex CLI、opencode などです。ドキュメントには「既存の CLI ツールの内側で、1つのコアからネイティブに動く」と書かれています。
もう1つ、繰り返し強調されているのが人が判断を持つことです。ウェルカムバナーの文面がそのまま設計方針になっています。
AI-DLC is an adaptive methodology that structures AI-assisted software development into repeatable, traceable phases while keeping you in control at every decision point.
（AI-DLC は、AI支援のソフトウェア開発を反復可能で追跡可能なフェーズへと構造化する適応的な方法論であり、あらゆる意思決定の場面であなたが主導権を持ち続けます）
「自律実行」を謳うフレームワークが、同じ文の後半で「あなたが主導権を持つ」と書いている。この両立のさせ方が、以降の設計に出てきます。
👥 設計思想 — Small Mob, Broad Agents
v2 でいちばん興味深かったのが、エージェントの配役の考え方です。ドキュメントは 「Small Mob, Broad Agents（小さなモブ、広いエージェント）」 という言葉で説明しています。
普通に考えると、32ステージあるなら、ステージごとに専門エージェントを置きたくなります。でもこのフレームワークは、そうしていません。
Rather than recreating waterfall handoff chains with dozens of narrow specialists, the approach employs eleven broadly capable agents that participate across multiple stages, each carrying context forward to eliminate handoffs.
（ウォーターフォールの引き継ぎの連鎖を数十の狭い専門家で再現するのではなく、複数のステージにまたがって参加する11の広い能力を持つエージェントを採用し、それぞれがコンテキストを持ち越すことで引き継ぎをなくす）
理由は明確です。ドキュメントには「エージェントが少なければ引き継ぎが少ない。エージェントの境界はすべて、情報が失われうる地点だ」と書かれています。
そして、この考え方の元になっているのが人間のチームです。
a mob of 3-5 people covers an entire feature, each bringing broad skills rather than a single narrow specialty
（3〜5人のモブが1つの機能全体をカバーし、それぞれが単一の狭い専門性ではなく広いスキルを持ち寄る）
モブプログラミングの発想を、そのままエージェントの配役に写し取っています。
実際の配役を見ると、この思想が数字に出ています。aidlc-architect-agent は9ステージに関与し（最多）、aidlc-developer-agent は3つのフェーズにまたがります。1人が広く持つ設計です。
一方で、aidlc-compliance-agent と aidlc-devsecops-agent は「支援のみ（support only）」で Lead を持ちません。横断的にチェックする役なので、主導ではなく脇に付く形です。
配役の全体像はこうなっています。
| 区分 | 数 | 役割 |
|---|---|---|
| ドメイン専門家 | 11 | 各自が領域全体を、複数ステージにまたがって担当 |
| 品質ゲートレビュアー | 2 | 要件・UX の妥当性、技術設計の健全性を審査 |
| コンポーザー | 1 | どのステージを実行し、どれを飛ばすかを提案 |
（14体それぞれの名称と担当領域は詳細編にまとめました）
⚙️ 二層構造 — 順番を決めるのはAIではありません
もう1つ、設計として押さえておきたいのがオーケストレーションの構造です。ここは誤解しやすいところだと思います。
ドキュメントの説明では、決定論的なエンジンが次の手を決め、conductor（/aidlc セッション）がそれを実行して次を要求するという往復になっています。
ここが重要なところで、どのステージを次に実行するかを決めているのはLLMではありません。エンジン側です。エンジンが状態を管理し、5フェーズ32ステージの定義を読み、エージェントのペルソナをロードし、各ステージで承認ゲートを提示します。
LLM が担うのは、渡されたステージの中身を実行する部分です。順番の決定と実行が分離されています。
この分離があるおかげで、「同じ入力なら同じ順番で動く」が保証されます。逆に言えば、LLM に自由な進行を任せない設計を意図的に選んでいるわけです。
ステージの実行の仕方も一律ではなく、4種類あります。
| モード | 数 | 内容 |
|---|---|---|
| Inline | 28 | エンジンと同じセッション内で実行（うち3つは自動、25は対話つき） |
| Subagent | 2 | サブエージェントに委譲 |
| Pipeline | 1 | 2段の連結（スキャン → 統合） |
| Mob | 1 | 複数エージェントの協働 |
Mob になっているのは 2.4 User Stories の1つだけです。Lead が起草して、design / developer / quality が協働します。ストーリーの定義は視点を混ぜたほうが良い、という判断だと読めます。ここも「Small Mob」の思想がそのまま出ている箇所です。
🖥️ 走らせると、実際に何が見えるのか
設計の話が続いたので、実際の画面を見ておきます。以下は公式ドキュメントに掲載されている出力例です。
まず起動します。
/aidlc Build a REST API for inventory management
スコープの確認から始まります
Initialization の3ステージ（作業場所の作成、プロジェクトの検出、状態の初期化）が自動で走った後、最初に出るのがこれです。
─── Scope Detection ───────────────────────────────────────────
Detected scope: feature (Standard depth, Standard test strategy)
▸ Approve scope? [Yes / Change scope / Change depth / Change test strategy]
>
スコープ・深さ・テスト戦略の3つが並んで出ます。 そしてそれぞれ個別に変更できます。ここが「3つの独立した軸」という設計が最初に顔を出す場面です。
自然文の「Build a REST API...」からは特定のキーワードが拾えなかったため、既定の feature が選ばれています。
ステータスラインで現在地が分かります
進行中は、こういう表示が出ます。
[AIDLC] IDEATION > Intent Capture [▓▓▓▓▓░░░░░] 4/7 -- product
読み方は、フェーズ（IDEATION）＞ ステージ（Intent Capture）、進捗バー、4/7（そのフェーズの何番目か）、そして末尾の product がいま動いているエージェントです。
32ステージのどこにいて、誰が担当しているかが1行で分かるようになっています。
答え方を選べます
ステージが始まると、対話モードを聞かれます。
▸ Choose interaction mode:
(1) Guide Me — agent asks structured questions
(2) Edit File — write directly to the artifact
(3) Chat — freeform discussion
3つとも最終的には同じ質問ファイルに収束するので、途中で切り替えても回答は失われません。
ゲートで成果物を確認します
ステージが終わると、何ができたかの表と選択肢が出ます。
# Intent Capture & Framing Complete
| Artifact | Contents |
|----------|----------|
| intent-capture.md | Problem statement, target users, success criteria |
| intent-capture-questions.md | 5 questions, all answered |
▸ How would you like to proceed?
(1) Approve — Continue to Market Research
(2) Request Changes — Provide revision feedback
承認すると進捗が出ます。
Progress: 4/32 overall | 1/7 IDEATION stages complete. Next: Market Research
4/32 になっているのは、Initialization の3ステージ＋今のステージで4つ目という数え方です。
この一連の流れが、32ステージのあいだ繰り返されます（条件付きのステージはスコープに応じて自動で飛ばされます）。
🎚️ 独立した3つの軸
さきほどスコープ確認の画面に3つ並んでいたのが、v2 の調整の仕組みです。それぞれ独立して指定できます。
| 軸 | 決めるもの | 選択肢 |
|---|---|---|
| スコープ | 32ステージのうち、どれを実行するか | 9種類（bugfix 7 〜 feature/enterprise 32） |
| 深さ | 成果物をどこまで詳しく書くか | 3段階（Minimal / Standard / Comprehensive） |
| テスト戦略 | テストをどれだけ書くか | 3段階（Minimal / Standard / Comprehensive） |
スコープが既定の深さを与え、深さが既定のテスト戦略を与えますが、それぞれ上書きできます。
/aidlc --scope bugfix --depth standard
/aidlc --depth standard --test-strategy minimal
分けてある実用的な意味は、公式が workshop スコープで示しています。深さは Standard、テストは Minimal という組み合わせで、理由が添えられています。
Full artifacts for learning, but fast Nyquist testing to keep pace
（学習のために成果物は完全に揃えるが、ペースを保つためテストは速い Nyquist で）
研修では成果物を学習材料として揃えたいが、テストを大量に書かせると時間が足りない。2軸が分かれていないと、この組み合わせは表現できません。
そして、この3軸があることで README が言う次のことが成立します。
The same engine runs a throwaway proof-of-concept and a regulated enterprise rollout — it just runs more of the stages, in more depth.
（同じエンジンが、使い捨ての概念実証と規制対象のエンタープライズ展開の両方を走らせる。ただ、より多くのステージを、より深く実行するだけだ）
32ステージという数字は「全部やれ」という要求ではなく、選択肢の総数だということです。
📁 成果物はどこに残るのか
もう1つ、全体像として押さえておきたいのが記録の構造です。2つの概念があります。
| 概念 | 定義（公式） |
|---|---|
| intent | "a single run of the AI-DLC lifecycle, scoped to one task."（1つのタスクに絞られた、AI-DLC ライフサイクルの1回の実行） |
| space | "one team's complete world: its own memory/, knowledge/, codekb/, and intents/."（1つのチームの完全な世界。独自の memory / knowledge / codekb / intents を持つ） |
ディレクトリの形はこうなっています。
my-project/
├── .claude/ ← ハーネスのエンジン（他は .kiro/ や .codex/）
├── aidlc/ ← AI-DLC の出力すべて
│ ├── active-space ← いまのスペース（gitignore）
│ └── spaces/
│ └── default/
│ ├── memory/ ← 守らせる決まり（org / team / project / phases）
│ ├── knowledge/ ← 参照する資料
│ ├── codekb/ ← リポジトリごとのコード知識
│ └── intents/
│ ├── active-intent ← いまのインテント（gitignore）
│ ├── intents.json ← 全インテントの登録簿
│ └── <YYMMDD>-<label>/ ← 1回の実行の記録
│ ├── aidlc-state.md
│ ├── audit/
│ └── （フェーズ・ステージごとの成果物）
ほとんどの人は、自動で作られる default スペース1つだけを使い、スペースの管理を意識することはないとドキュメントに書かれています。複数チームで方法論を分けたいときだけ増やす想定です。
一方 intent は日常的に増えます。作業中に無関係な別の作業を始めようとすると、AI-DLC がそれを「新しい、無関係な作業」だと認識して、2つ目の intent を並べて始めることを提案してくれます。切り替えは /aidlc intent <slug> で、それぞれ独立して状態を保ちます。
命名に工夫があります
intent のディレクトリは <YYMMDD>-<label> という形式です。ここに小さな設計が入っていました。
the
<YYMMDD>is a compact UTC date so records sort chronologically; the<label>is a short, human-readable name. Identity itself is carried by a UUIDv7 in the registry, not the dir name（
<YYMMDD>は UTC の短縮日付で、記録が時系列に並ぶようにするため。<label>は短い人間が読める名前。同一性そのものは登録簿の UUIDv7 が持っており、ディレクトリ名ではない）
ディレクトリ名は「人間が読むため」に割り切って、機械的な同一性は別に UUIDv7 で持つ。だから同じ日に同じラベルの作業が2つあっても衝突しません。
git 管理の境界も設計されています
これは実務で効くと思いました。
| 対象 | |
|---|---|
| コミットされる |
memory/、knowledge/、codekb/、intents.json、各 intent の aidlc-state.md、audit/、成果物 |
| gitignore | カーソル（active-space、active-intent）、ランタイムの一時ファイル（runtime-graph.json、.aidlc-*、.aidlc-sessions/） |
チームで共有する資産（決まりごと・資料・記録）はコミットされ、「いま自分がどこを見ているか」という個人の状態は共有されません。 全員が同じリポジトリで別々の intent を進められるようになっています。
監査記録がクローンごとに別ファイル（<host>-<clone>.md）になっているのも同じ発想で、複数人が同時に作業しても git のコンフリクトが起きません。
🔄 v1 から何が変わったか
簡潔に整理しておきます。v1 は main ブランチ、v2 は v2 ブランチとして共存しています。
| v1 | v2 | |
|---|---|---|
| フェーズ | 3（Inception / Construction / Operations） | 5（前に Initialization・Ideation、後ろに Operation を実装） |
| ステージ | 通し番号なし |
32（0.1〜4.7） |
| エージェント | 役割の分割なし | 14（Small Mob, Broad Agents） |
| 調整 | ステージ条件（ALWAYS / CONDITIONAL）＋計画時の EXECUTE/SKIP | 9スコープ ＋ 深さ ＋ テスト戦略の3軸＋コンポーザー |
| 学習 | なし | 学習ループ（人の修正が次回から効く） |
| 起動 | 「Using AI-DLC, ...」と自然文 |
/aidlc <説明> などのコマンド |
増えた部分を設計思想から見ると、前後に伸びているのが特徴です。前に「そもそもやるべきか」（Ideation）、後ろに「動かし続ける」（Operation）が付きました。開発の工程だけでなく、その前後まで面倒を見る方向に広がっています。
📝 まとめ
設計思想の面から見ると、v2 は3つの判断でできていると思いました。
① エージェントは少なく、広く持たせる。 32ステージあるからといって32の専門家を置かない。引き継ぎの境界がそのまま情報損失点になるからです。人間のモブプログラミング（3〜5人が1機能をカバーする）を写し取った形になっています。
② 順番を決めるのはAIではない。 決定論的なエンジンが次のステージを決め、LLM はその中身を実行する。この分離があるから「同じ入力なら同じ順番」が保たれます。自律性を上げるために、進行の決定権はむしろ機械側に固定してあります。
③ 調整は3つの独立した軸で行う。 どのステージを（スコープ）、どこまで詳しく（深さ）、どれだけテストして（テスト戦略）。この3軸が分かれているから、同じエンジンで使い捨ての試作から規制対応まで扱えます。
32ステージという数字を最初に見ると「重い」と感じますが、それは選択肢の総数です。実際に走るのは、バグ修正なら7つ。 「網羅的に用意したうえで、今回必要な分だけ選ぶ」 という組み立て方だと理解すると、印象がかなり変わりました。
一方で、この規模のルールセットを入れる価値があるかは、プロジェクト次第だと思います。承認ゲートと監査記録がそのまま要件になる現場では効きますが、少人数で速く回している場合はゲートの数がそのまま手間になります。判断するには一度動かしてみるのが早いので、まずは bugfix の7ステージを1周してみるのがおすすめです。
📚 参考
公式（v2 ブランチ）
-
awslabs/aidlc-workflows（v2 ブランチ） — 本体。MIT-0、執筆時点のバッジは
2.5.53 - docs/guide/00-introduction.md — 公式の定義、Small Mob / Broad Agents、オーケストレーションループ、ハーネス中立
- docs/guide/02-your-first-workflow.md — 初回実行の画面出力（本記事に引用した4つの例）
- docs/guide/03-spaces-and-intents.md — space と intent の定義、ディレクトリ構造、git 管理の境界
- docs/guide/05-scopes-and-depth.md — 9スコープ、深さ、テスト戦略
- docs/guide/06-agents.md — 14エージェントの配役
v1（main ブランチ）
- awslabs/aidlc-workflows（main = v1） — 3フェーズ構成