AI-DLC Workflow V1からV2へ：人間のボトルネックを解消する設計の進化
AI-DLCの概念は知ってるけど、AI-DLC Workflow V1とV2で何が違うの？という方に向けて、「なぜ変わったのか」を軸に全体像を解説します。シリーズ第1回。
Series: AI-DLC Workflow V2の解説 (31 articles)
- 1AI-DLC Workflow V1からV2へ：人間のボトルネックを解消する設計の進化 This article
1. はじめに
この記事はAI-DLC Workflow V2シリーズの第1回です。AI-DLC Workflow V1（以降V1）からAI-DLC Workflow V2（以降V2）への進化の全体像を俯瞰し、個々の設計要素の詳細は後続記事で深掘りしていきます。
読者の前提として、AI-DLCのコンセプトは既にご存知であることを想定しています。公式の説明を借りれば、AI-DLCは「ニーズに適応し、品質基準を維持し、プロセスの制御を人間に委ねるインテリジェントなソフトウェア開発ワークフロー」（V1 README ）です。この前提の上で、V1とV2で何が変わったのか、そしてなぜ変わる必要があったのかに焦点を当てていきます。
先に結論を述べると、V1→V2の本質は「全サイクルで人間が検証するモデル」から「AIとツールが自己検証し、人間は判断に集中するモデル」への転換です。では、その背景を順に見ていきましょう。
2. V1の価値と達成したこと
V2の話をする前に、V1が何を達成したのかを整理しておきます。V1はAI-DLC方法論の最初のオープンソース実装であり、以下の設計思想を実証しました。
設計思想
- 方法論ファースト — 特定のツールに依存せず、方法論としての独立性を保つ
- ツール非依存 — 複数のコーディングエージェントで動作する
- Human in the loop — 人間が全てのサイクルに関与し、品質を担保する
実装として達成したこと
- マルチプラットフォーム対応（Kiro、Amazon Q Developer、Cursor、Cline、Claude Code、GitHub Copilot、OpenAI Codex — ルールファイルをコピーするだけで動作する手軽さ）
- 3フェーズ構成（Inception、Construction、Operations）
- アダプティブなステージ選択（execution-planでEXECUTE/SKIP管理）
aidlc-state.mdによる進捗管理、audit.mdによる記録- 質問駆動の対話（structured questions in files）
V1は「AIエージェントに構造化されたワークフローを持たせる」というアイデアを実証し、多くのコーディングエージェントで利用可能にしました。これは大きな成果です。しかし、実際に使い込んでいくと、ある構造的な課題が浮かび上がってきました。
3. 浮かび上がった課題：人間がボトルネック
構造的な課題
V1の流れを改めて見てみましょう。AIが生成し、人間が検証し、フィードバックを返し、AIが修正し、人間が再検証する。全てのサイクルに人間が必要です。
エージェントの能力がいくら向上しても、検証を人間が一手に担っている限り、スループットは人間の処理速度で頭打ちになります。これは個人の能力の問題ではなく、アーキテクチャの問題です。
V1で解決できなかった5つの課題
V1を運用する中で、以下の5つの「方法論レベルで解決すべき課題」が明らかになりました。
- AIによるアウトプットの自己検証ができない — すべての出力を人間がチェックする必要がありました。明らかに正しいものも、判断が必要なものも、同じフローを通ります。
- 修正指示からの学習ができない — 「PEP8に従って」「Result型を使って」という指摘を、毎回、新しいセッションのたびに繰り返す必要がありました。
- ワークフロー途中でのスコープ調整ができない — 走り出した後に要件が変わっても、ワークフローのステージ構成を調整できませんでした。
- 並列実行の自律化ができない — ユニットの並列実施は可能でしたが、各ユニットの検証と、ユニット完了後の結合は人間が担う必要がありました。
- ルーティングと生成の分離ができない — LLMが「次に何をすべきか」の判断と「実際の作業」の両方を担っていたため、確率的な判断がワークフローの進行を左右していました。
ここで重要なのは、これらは「モデルやツールの進化を待てば解決する」類の問題ではないということです。AI-DLC Workflowの開発チームは、方法論で解決する道を選びました。
4. V2のアプローチ：2つのループ
2つのループへの分割
V2の核心は、「1つの大きなループ」を「2つの異なる性質のループ」に分割したことです。
- インナーループ: AIが生成し、コードベースのツールがチェックし、AIが検証する。人間は介在しません。問題があれば自己修正を繰り返し、収束できない場合のみ人間にエスカレーションします。
- アウターループ: 人間は判断のみに関与します。承認ゲート、設計判断、優先順位の決定 — つまり「人間にしかできないこと」に集中できます。
人間の労力が下がり続ける仕組み
ここにはもう一つ重要な設計意図があります。
AI Assisted（コード補完など）の登場で人間の労力は一段下がりましたが、そこで停滞しました。V1の導入でさらに一段下がりましたが、やはりプラトー現象（改善が一定のレベルで頭打ちになり、次の外的な変化が来るまで横ばいが続く状態）が起きます。モデルや新しいツールの登場を待つ形になるからです。
V2では、検証内容を段階的にエンコードし、AIが学習することで効果が積み重なっていきます。つまり、使えば使うほど改善が蓄積される構造です。言い換えれば、「良いAI/ツールは階段のように進んでは止まる。良い方法論は坂道のように進み続ける」ということです。
3つの担い手の役割分担
V2では「適切な仕事を適切な担い手に」という原則で、3つの担い手を明確に分離しています。
3つ目のポイントが特に重要です。ワークフローの順序付けや状態管理のように「正解が一意に決まる」処理を、なぜ確率的なLLMに任せるのか？ — V2はここに明確なNoを突きつけ、コードベースのツールが担います。
5. 2つのループを実現する設計要素
では、これらの設計思想がどのように実装に落とし込まれているのかを見ていきましょう。まず全体像を確認します。
ここでは各要素の概要のみを示します。詳細は後続記事で一つずつ掘り下げます。
5.1 コードベースのワークフロー制御
V1ではLLMがルールを読み解き、「次に何をすべきか」を判断していました。V2ではTypeScript製のCLIツール群がワークフローの進行を管理します。
LLMは「次に何をすべきか」を判断しません。ツールに問い合わせて、指示された1つのことを実行する。この分離により、ワークフローの進行が確率的なブレから解放されました。
具体的にどのような流れで動くのかを、以下の図で確認しましょう。
人間が
/aidlc で意図を伝えると、指揮者（コンダクタ）がステートマシンに問い合わせ、返ってきた指示に従ってリードエージェントの帽子をかぶり、必要に応じてサブエージェントやレビュアーに作業を振り分けます。全体を通して、フックが監査やツールを呼び出しています。5.2 14エージェントの体制
V2では11のドメインエキスパート、2つのレビュー専任エージェント、1つのアダプティブコンポーザーで構成される14エージェント体制を採用しています。
鍵となるのはレビュアーエージェントの存在です。生成エージェントとは別に、検証を専門とするエージェントが各ステージで品質チェックを行います。これにより「AIによる自己検証」が実現し、人間の検証負荷が構造的に軽減されます。
各ステージの内部構造は「生成 → 検証 → 学習」のループとして統一されています。
5.3 スコープ × 深度 × テスト戦略
V2では3つの軸でワークフローの形を制御できます。
- 9つの宣言的スコープ: enterprise、feature、mvp、bugfix、security-patch、infra、refactor、poc、workshopなど、プロジェクトの性質に応じたプリセット
- 3段階の深度: Minimal / Standard / Comprehensive（成果物の詳細度を制御）
- 3段階のテスト戦略: 深度とは独立にテストの厚みを制御
さらに、Adaptive Composerによって既存の9スコープに縛られないカスタムスコープを作成できます。タスクの記述から最適なEXECUTE/SKIPの組み合わせを提案し、承認されればそのままワークフローとして実行できます。また、ワークフロー途中でのスコープ再構成にも対応しており、「走り出してから要件が変わった」という状況にも方法論レベルで対応しています。
以下の図は、スコーピング（静的テンプレートの選択）と適応（Adaptive Composerによる動的生成）の2つのパスを示しています。
5.4 Construction ユニット並列実行
Construction（実装）フェーズでは、作業を「ユニット（Unit）」に分解し、ユニットの依存グラフに従って並列に実行します。互いに依存しないユニットは同じ並列バッチ（runtime batch）としてまとめられ、同時に走ります。各ユニットにレビュアーエージェントが付くため、人間を待たずに検証が回ります。人間はステージ単位の承認に関与し、実装の詳細はインナーループが処理します。
なお Bolt は、Delivery Planning（2.9）が記録する「どこまでを1つのまとまりとして届けるか」という計画上のデリバリスライス（Definition of Done・確信仮説・オーナーシップを伴う）であり、実行時の並列バッチとは別概念です。デフォルトの実行（stage-major）では、実行時の並列性と順序はユニット依存グラフが駆動し、
bolt-plan.mdは計画の記録（advisory）として扱われます。5.5 5層ルール＋学習ループ
V1の「毎回同じ指摘を繰り返す」課題を根本から解決する仕組みです。人間の修正指示を永続的なルールとして保存し、5つの層で管理します。
下の層ほど狭く、上の層を上書きできます。一度修正したことは二度と繰り返す必要がありません。使い込むほど各プロジェクト・各チームに最適化されていきます。
5.6 各コーディングエージェントへの専用組み込み
ここがV1とV2の配布・組み込み方式の最大の違いです。
- V1: 1つのルールファイルセットを各プラットフォームにコピーする方式。手軽だが、各プラットフォームの機能を活用しきれない
- V2: 単一のコア（
core/）から、各コーディングエージェントに専用設計された形でビルドする方式。フック、ツール、エージェント定義が各ハーネスのネイティブ機能として動作する
V2はKiro IDE / Kiro CLI、Claude Code、Codex CLI、opencodeに対応しています。Kiro IDE / Kiro CLIはClaude Opus 4.8に対応しており、弱いモデルではステージのスキップやゲートの省略が起こる場合があります。
6. V1 vs V2 比較表
ここまでの内容を一覧で整理します。
| 観点 | V1 | V2 |
|---|---|---|
| 対応プラットフォーム | マルチプラットフォーム（ルールコピー方式） | 各コーディングエージェントに専用組み込み（Kiro IDE/CLI, Claude Code, Codex CLI, opencode） |
| ワークフロー制御 | LLMがルールを解釈して進行 | LLMの判断に依存しない、コードベースのワークフロー制御 |
| 状態管理 | aidlc-state.md（LLMが読み書き） | aidlc-state.md + エンジンが自動管理 |
| 監査記録 | audit.md（単一ファイル） | 74イベント×19カテゴリ、シャード化、構造化 |
| セッション再開 | aidlc-state.mdを読んで再開（LLM依存） | エンジンが状態から自動復帰 |
| 検証 | 人間が全サイクルで検証 | AIレビュアー＋コードベースのツールで自己検証 |
| 学習 | なし | 5層ルールチェーン + 学習ループ |
| 並列化 | なし | Constructionでユニット依存グラフに基づくユニット並列実行 |
| スコープ調整 | execution-planで選択（変更は困難） | 9スコープ + Adaptive Composerでカスタムスコープ作成・途中変更可能 |
| エージェント体制 | LLMがルールに従い行動 | 14の明示的エージェント（11ドメイン＋2レビュー＋1コンポーザー） |
| ステージ構造 | 3フェーズ、アダプティブ選択 | 5フェーズ × 33ステージ、宣言的グリッド |
| 承認ゲート | 人間が全サイクルで関与 | 人間は判断のみ（インナーループは人間を介さず完結） |
7. まとめ
まとめ
V1→V2の進化の本質を一言でまとめると、「全サイクルで人間が検証する」モデルから「AIとツールが自己検証し、人間は判断に集中する」モデルへの転換です。
これはモデルの進化に賭ける戦略ではありません。方法論の設計で、人間のボトルネックを構造的に解消する戦略です。2つのループへの分割、コードベースのワークフロー制御、レビュアーエージェントによる自己検証、学習ループによる継続的改善 — これらが一体となって、「使えば使うほど人間の負荷が下がる」システムを実現しています。
参考資料
Series: AI-DLC Workflow V2の解説 (31 articles)
- 1AI-DLC Workflow V1からV2へ：人間のボトルネックを解消する設計の進化 This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article