吉田真吾 (@yoshidashingo) です。
これだけは覚えて帰ってね💡
- Infrastructure Designは「論理コンポーネント」を具体的なクラウドサービスにマッピングする (9ステップ、3つの成果物)
- Code Generationは「計画→承認→生成」の2パートに分かれ、計画なしにコードを書かない (16ステップ)
- Build and Testは6種類のテスト戦略でシステム全体の品質を検証する (10ステップ)
- IaC (Infrastructure as Code) 、TDD (テスト駆動開発) /BDD (振る舞い駆動開発) 、CI/CD (継続的インテグレーション/継続的デリバリー) パイプラインと比較し、AI-DLCの品質保証設計を位置づける
CONSTRUCTIONフェーズの後半では、設計を物理インフラに落とし込み、コードを生成し、テストで品質を確認するまでの一連の流れを扱います。AI-DLCが「計画なしにコードを書かない」「テストに通らなければ次に進めない」という厳格な姿勢をどう設計しているのかが、今回の焦点です。
引用元：AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 | Amazon Web Services ブログ
前回の振り返り: Per-Unit Loopの後半へ
第5回では、CONSTRUCTIONフェーズの前半戦を解説しました。Per-Unit Loopの構造、Functional Designによる技術非依存のビジネスロジック設計、NFR Requirements / NFR Designによる非機能要件の「要件→パターン」への落とし込みを見てきました。
今回は、Per-Unit Loopの後半にあたるInfrastructure DesignとCode Generation、そしてループ完了後のBuild and Testを取り上げます。
Per-Unit Loop:
Functional Design → NFR Requirements → NFR Design → [Infrastructure Design] → [Code Generation]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
全ユニット完了後: ↑ 今回の範囲 ↓
[Build and Test]
^^^^^^^^^^^^^^^^
Infrastructure Design: 論理を物理に変換する
第5回で解説したNFR Designは「キャッシュが必要」「メッセージキューが必要」という論理コンポーネントを定義するところまででした。Infrastructure Designは、その論理コンポーネントを具体的なクラウドサービスや製品にマッピングするステージです。
9ステップと3つの成果物
Infrastructure Designは9ステップで構成され、3つの成果物をAIが生成します:
| # | 成果物 | 内容 |
|---|---|---|
| 1 | infrastructure-design.md | 論理コンポーネントから具体的なサービスへのマッピング |
| 2 | deployment-architecture.md | デプロイメントアーキテクチャの定義 |
| 3 | shared-infrastructure.md | 複数ユニットで共有するインフラの定義 (該当する場合のみ) |
質問カテゴリは「必要なものだけ」
Infrastructure Designの質問生成ステップには、仕様書に明確な指示があります:「カテゴリは必須チェックリストではなく、インスピレーションとして使え」。
たとえば、デプロイ環境、コンピュート、ストレージ、メッセージング、ネットワーキング、モニタリング、共有インフラの7カテゴリが例示されていますが、すべてを質問する必要はありません。メッセージングが不要なユニットにメッセージキューの質問を投げても意味がありません。ユニットの設計内容を分析して、実際に判断が必要な領域だけ質問する。
これは第3回で解説した「質問の質を重視する」思想の延長です。Requirements AnalysisやUser Storiesでは質問で曖昧さを潰していきましたが、Infrastructure Designでは「質問しない」判断も重視されます。
段階的具体化の最終段階
第5回で紹介した「要件→パターン→実装」の3段階は、Infrastructure Designで完結します。NFR Requirementsの「レスポンスタイム100ms以内」がNFR Designの「キャッシュパターン」を経て、Infrastructure Designで「Amazon ElastiCache (Redis)、r6g.large、クラスター構成」にまで落とし込まれます。論理コンポーネントが具体的なサービス名、インスタンスタイプ、構成に変わり、ここで初めて「何を使うか」が確定します。
Code Generation: 計画が先、コードは後
Infrastructure Designで技術選択が確定したら、いよいよコードを書く段階です。ただし、AI-DLCはいきなりコードを生成しません。コード生成計画を立て、承認を得てから生成する。
2パート・16ステップ
Code Generationは大きく2つのパートに分かれています:
Part 1: PLANNING (ステップ1〜9)
| ステップ | 内容 |
|---|---|
| 1 | ユニットのコンテキスト分析 |
| 2 | 詳細なコード生成計画の作成 |
| 3 | ユニット生成コンテキストの記載 |
| 4 | 計画文書の保存 |
| 5 | 計画のサマリー提示 |
| 6 | 承認プロンプトの記録 |
| 7 | 明示的な承認の取得 |
| 8 | 承認レスポンスの記録 |
| 9 | 進捗の更新 |
Part 2: GENERATION (ステップ10〜16)
| ステップ | 内容 |
|---|---|
| 10 | 計画の読み込み |
| 11 | 現在のステップを実行 |
| 12 | 進捗の更新 |
| 13 | 継続または完了の判定 |
| 14 | 完了メッセージの提示 |
| 15 | 明示的な承認の取得 |
| 16 | 承認レスポンスの記録 |
承認ゲートが2つあることに注目してください。ステップ7で「この計画でコードを書いていいか」を承認し、ステップ15で「書いたコードに問題はないか」を承認します。計画と成果物それぞれに対してチェックが入る構造です。
「計画が唯一の真実」ルール
Code Generationの仕様書には、太字で強調されたルールがあります:
- NO HARDCODED LOGIC: 計画に書かれていないことは実行しない
- FOLLOW PLAN EXACTLY: ステップの順序を変えない
- UPDATE CHECKBOXES: 各ステップ完了後に即座にチェックを入れる
- STORY TRACEABILITY: ユーザーストーリーとの対応を追跡する (どのコードがどの要件を実現しているかを辿れるようにする)
AIに「自由にコードを書け」とは言いません。「計画に書かれたことだけを、書かれた順序で実行しろ」と制約します。これは、AIが独自判断で実装範囲を広げたり、予定外の機能を追加したりする逸脱リスクを低減する設計です。
ただし、この「計画が唯一の真実」ルールにはトレードオフもあります。実装中に計画の前提が不適切だったと分かっても、計画を修正して再承認を得なければ対応できません。人間の開発者であれば「やりながら調整」が当たり前ですが、AI-DLCでは計画修正のオーバーヘッドが発生します。これは逸脱防止と柔軟性のバランスにおいて、逸脱防止を優先した設計判断です。
Brownfieldの「コピーファイル禁止」ルール
既存コードがあるBrownfieldプロジェクトでは、追加の重要ルールがあります:
- ファイルが存在するか確認してから生成する
- 存在する場合はそのファイルを直接修正する (
ClassName_modified.javaやClassName_new.javaのようなコピーは作らない) - 存在しない場合のみ新規作成する
- 生成後に重複ファイルがないか検証する
なぜここまで厳密に禁止するのでしょうか。AIがコードを生成する際、既存ファイルへの変更を避けて新しいファイルを作りがちであるという傾向が観察されているためです。人間なら「同じクラスが2つあるのはおかしい」と気づきますが、AIは指示がなければ重複を生み出しやすい傾向があります。AI-DLCはこのAI特有の傾向を、フレームワークレベルのルールで抑制する設計になっています。
コードの配置ルール
もう1つ、AI-DLCに特有の配置ルールがあります。アプリケーションコードはaidlc-docs/ではなくワークスペースルートに配置する。設計文書はAI-DLCの管理ディレクトリに格納しますが、実際に動くコードはプロジェクト本体のディレクトリ構造に従って配置します。
プロジェクトタイプによる使い分けも定義されています:
| プロジェクトタイプ | 構造 |
|---|---|
| Brownfield | 既存構造に従う (例: src/main/java/, lib/) |
| Greenfield (単一ユニット) | src/, tests/, config/ |
| Greenfield (マイクロサービス) | {unit-name}/src/, {unit-name}/tests/ |
| Greenfield (モノリス) | src/{unit-name}/, tests/{unit-name}/ |
Build and Test: 6つのテストでシステムを守る
Per-Unit Loopで全ユニットのInfrastructure DesignとCode Generationが完了したら、Build and Testステージに入ります。このステージはユニット単位ではなく、システム全体を対象にした検証プロセスです。
6種類のテスト戦略
Build and Testは10ステップで構成され、以下の6種類のテストを実行します:
| # | テスト種別 | 目的 | タイミング |
|---|---|---|---|
| 1 | ユニットテスト | 個々の関数・クラスの正しさを検証 | Code Generationで生成済み、ここで一括実行 |
| 2 | 統合テスト | ユニット間・サービス間の連携を検証 | Build and Testで新規生成 |
| 3 | パフォーマンステスト | 負荷・ストレス・スケーラビリティを検証 | NFR Requirementsの要件に基づいて実行 |
| 4 | エンドツーエンドテスト | ユーザーワークフロー全体を検証 | User Storiesのシナリオに基づいて実行 |
| 5 | コントラクトテスト | サービス間のAPI契約を検証 | マイクロサービス構成の場合に実行 |
| 6 | セキュリティテスト | 脆弱性・認証認可・入力検証をチェック | NFR Requirementsのセキュリティ要件に基づいて実行 |
ユニットテストだけがCode Generationの時点ですでに生成されています。統合テスト以降は、全ユニットが揃った後に初めて意味を持つテストであるため、Build and Testステージで生成・実行されます。
なお、パフォーマンステスト、コントラクトテスト、セキュリティテストはCONDITIONALステージの扱いです。たとえばマイクロサービス構成でなければコントラクトテストはスキップされ、NFR Requirementsでパフォーマンス要件が定義されていなければパフォーマンステストもスキップされます。6種類すべてが常に実行されるわけではなく、プロジェクトの特性に応じて必要なテストだけが実行されます。
5つの成果物
Build and Testは以下の5つの成果物をAIが生成します:
| # | 成果物 | 内容 |
|---|---|---|
| 1 | build-instructions.md | ビルド手順、前提条件、トラブルシューティング |
| 2 | unit-test-instructions.md | ユニットテストの実行手順と期待結果 |
| 3 | integration-test-instructions.md | 統合テストのシナリオとセットアップ手順 |
| 4 | performance-test-instructions.md | パフォーマンステストの設定と評価基準 |
| 5 | build-and-test-summary.md | 全テスト結果のサマリーと次ステップの判定 |
追加のテスト (コントラクト、セキュリティ、エンドツーエンド) が必要な場合は、それぞれの手順書が別途AIにより生成されます。
「Ready for Operations: Yes/No」
Build and Testのサマリーには、最後に明確な判定があります: Ready for Operations: Yes/No。Build and Testステージで実行するすべてのテスト (ユニットテストの再実行を含む6種類) が通れば「Yes」でOPERATIONSフェーズに進めます。1つでも失敗すれば「No」で、問題を修正して再実行します。
この「Go/No-Go判定」は、CONSTRUCTIONフェーズからOPERATIONSフェーズへのゲートとして機能します。テストが赤信号を出している状態では、次のフェーズに進まないよう設計されています。
このゲートには副作用もあります。全ユニットのコード生成が完了するまでテスト実行を待つため、ユニット単位のフィードバックが遅れます。TDDのようにコードを書いた直後にテストで検証するアプローチと比べると、問題の発見が遅くなりやすい設計です。ただし、ユニットテストについてはCode Generationの段階で先行して生成されており、システム全体の統合的な検証のみがこのタイミングになります。
既存手法との比較: コードと品質の系譜
今回取り上げる3つの手法 ― IaC、TDD/BDD、CI/CD ― はいずれもAI-DLCと競合するものではありません。それぞれが異なるレイヤーや時間軸を担っており、AI-DLCと補完関係にあります。その違いを具体的に見ていきましょう。
Infrastructure as Code: コードでインフラを定義する
Infrastructure as Code (IaC) は、インフラの構成をコードとして管理する手法です。概念の起源は1993年にMark BurgessがオスロでCFEngineを開発したことに遡ります。「Infrastructure as Code」という用語が広まったのは、2009年前後にAndrew Clay ShaferがVelocityカンファレンスで「Agile Infrastructure」を講演するなど、DevOpsコミュニティで使われ始めたころからです。Kief Morrisの著書『Infrastructure as Code』 (O'Reilly、初版2016年) が概念を体系化し、現在はTerraform (HashiCorp、2014年) やAWS CloudFormation (2011年) などのツールが主流となっています。
IaCの中心的な考え方を3つ挙げます:
| 原則 | 内容 |
|---|---|
| 宣言的記述 | 「この状態であるべき」を記述する。手順ではなく、望む結果を定義する |
| 冪等性 (べきとうせい) | 同じ操作を何度実行しても結果は同じ。Burgessが「収束演算子」 (冪等性を含むより広い概念) として概念化した |
| バージョン管理 | インフラ定義をGitで管理し、変更履歴の追跡・レビュー・ロールバックを可能にする |
AI-DLCのInfrastructure Designは、IaCとは異なるレイヤーで動いています:
| 観点 | IaC (Terraform等) | AI-DLC Infrastructure Design |
|---|---|---|
| 対象 | インフラの構築・構成管理 | インフラの選定・設計判断 |
| 成果物 | 宣言的な定義ファイル (.tf等) | infrastructure-design.md |
| 実行結果 | インフラが実際に構築される | 設計文書が生成される |
| 位置づけ | 実装 | 設計 |
AI-DLCのプロセスを通じて「ElastiCache (Redis)を使う」と決定し、IaCのTerraformコードがそのRedisクラスターを実際に構築します。AI-DLCのCode Generationステージで生成されるデプロイメントアーティファクトには、こうしたIaCの定義ファイルが含まれ得ます (ただし、現時点のAI-DLCはIaCの定義ファイル生成を明示的にサポートしているわけではなく、Code Generationの範囲はプロジェクトの設定に依存します) 。
TDD/BDD: テストで設計を駆動する
テスト駆動開発 (TDD) は、Kent Beckが1990年代後半にExtreme Programming (XP) の一部として開発し、2002年の著書『Test-Driven Development: By Example』で独立した手法として体系化したものです。Beck自身はTDDを「再発見」と呼んでいます。コンピューティングの黎明期から、プログラマーはコーディング前に入出力の仕様を定めていたからです。
TDDの核心はRed-Green-Refactorサイクルです:
- Red: まず失敗するテストを書く
- Green: テストを通す最小限のコードを書く
- Refactor: テストが通る状態を維持しながらコードを改善する
このサイクルを細かく繰り返すことで、テストが常に設計を駆動します。
振る舞い駆動開発 (BDD) は、Dan Northが2003年にJBehaveの開発を始め、2006年の記事「Introducing BDD」で正式に提唱した手法です。TDDの技術的プラクティスを引き継ぎつつ、「テスト」ではなく「振る舞い」の言葉でシナリオを記述します。2008年にAslak HellesoyがCucumberを開発し、Gherkin構文 (Given-When-Then) が標準化されました。
| 観点 | TDD | BDD | AI-DLC Build and Test |
|---|---|---|---|
| テストの起点 | 開発者が書くテストコード | ビジネスが語るシナリオ | 設計文書を基にAIが生成 |
| 記述言語 | プログラミング言語 | Gherkin (自然言語に近い) | Markdown＋コード |
| 設計との関係 | テストが設計を駆動 | シナリオが設計を駆動 | 設計が完了してからテストを生成 |
| 実行タイミング | コーディングと同時 | 要件定義からコーディングまで | 全ユニット完了後に一括 |
テーブルの「設計との関係」行に注目してください。TDD/BDDでは「テストやシナリオが設計を駆動する」のに対し、AI-DLCでは「設計が完了してからテストを生成する」。方向が逆です。TDDはテストを通じて設計を段階的に洗練していくアプローチであり、人間の開発者がコードの振る舞いを一つずつ確認しながら設計判断を積み重ねる文脈に最適化されています。一方、AI-DLCはAIが「設計文書を基に一括してコードとテストを生成する」文脈に最適化されています。
ここで注意すべきは、TDDとAI-DLCでは「設計」の指すスコープが異なることです。TDDが駆動するのは関数やクラスレベルの詳細設計 (メソッドのインターフェース、クラスの責務分割など) です。AI-DLCのFunctional DesignやNFR Designが扱うのは、それより上位のアーキテクチャレベルの設計です。したがって「どちらが優れているか」ではなく、異なるレベルの設計を異なるアプローチで駆動していると理解するのが適切です。
また、TDDには「テストを通す最小限のコードを書く」というインクリメンタルな性質があり、これにより設計の過剰な複雑化を防ぐ効果があります。AI-DLCの事前設計アプローチでは、この種のフィードバックは得られにくく、Build and Testの段階で初めて設計の問題が顕在化するリスクがあります。
CI/CDパイプライン: 変更を安全に届ける
継続的インテグレーション (CI) は、Grady Boochが1991年に用語を提唱し、Kent BeckがXPの文脈で1日に複数回の統合を推奨したことで普及しました。Martin Fowlerが2000年に発表し2006年に改訂したCI記事が業界標準の参照文献となっています。
継続的デリバリー (CD) は、Jez HumbleとDavid Farleyが2010年の著書『Continuous Delivery』で体系化しました。チェックインからリリースまでの全工程を自動化する「デプロイメントパイプライン」の概念を確立し、2011年のJolt Excellence Awardを受賞しています。
CI/CDパイプラインの核心は自動化されたフィードバックループです:
コード変更 → ビルド → ユニットテスト → 統合テスト → デプロイ → 受入テスト → リリース
↑ |
└──────────── フィードバック ←──────────────────────────────────────────┘
AI-DLCのBuild and Testとの対比を見てみましょう:
| 観点 | CI/CDパイプライン | AI-DLC Build and Test |
|---|---|---|
| トリガー | コード変更 (コミット/プッシュ) | 全ユニットのCode Generation完了 |
| 実行頻度 | 変更のたびに (1日数回〜数百回、チームや組織の規模による) | CONSTRUCTIONフェーズで1回 |
| テスト範囲 | 漸進的 (変更差分に対して実行) | 包括的 (システム全体を一括検証) |
| 失敗時の対応 | 開発者がコードを修正して再コミット | AIがコードを修正して再生成 (修正の品質はAIの能力に依存) |
| 目的 | 継続的な品質維持 | リリース前の品質確認 |
AI-DLCで生成されたコードが本番環境に入った後は、従来のCI/CDパイプラインで運用されます。AI-DLCのBuild and Testは「初回リリース前の品質ゲート」、CI/CDは「リリース後の継続的な品質保証」― 時間軸の異なるフェーズを担っています。
まとめ
第6回はCONSTRUCTIONフェーズ後半のInfrastructure Design・Code Generation・Build and Testについて説明しました。今回学んだことは以下です。
- Infrastructure Design (9ステップ) は、NFR Designの論理コンポーネントを具体的なクラウドサービスにマッピングします。「要件→パターン→実装」の3段階がここで完結します
- Code Generation (16ステップ) は計画と生成の2パートに分かれ、それぞれに承認ゲートがあります。「計画に書かれたことだけを実行する」というルールでAIの逸脱リスクを低減しますが、実装中の計画修正にはオーバーヘッドが伴います
- Build and Test (10ステップ) は6種類のテストでシステム全体を検証し、「Ready for Operations」のGo/No-Go判定を出します
- IaCはAI-DLCの設計判断の後工程として、インフラの構築・構成管理を担います
- TDD/BDDの「テストが設計を駆動する」に対し、AI-DLCは「設計がテストを駆動する」という逆の方向性をとります。ただし両者は「設計」のスコープが異なり (TDD=詳細設計、AI-DLC=アーキテクチャ設計) 、単純な優劣比較にはなりません
- CI/CDは「継続的な品質維持」、AI-DLCのBuild and Testは「リリース前の品質ゲート」と、異なる時間軸を担います
次回予告
第7回では、AI-DLC全体を貫く設計思想を俯瞰します。OPERATIONSフェーズの将来像、Adaptive Depth (複雑さに応じて深さを変える仕組み) 、aidlc-state.mdによる進捗管理と再開、audit.mdによる監査証跡、そして承認ゲートの設計原則を、GitOps、SOC2/ISO27001の監査、Stage Gate Processと比較しながら解説します。
