AI-DLC 入門 〜AIコーディングの本質は「コード」ではなく「構造」〜 / Introduction to AI-DLC: The Essence of AI Coding Is Not “Code” but “Structure”

Fusic社内AI-DLCハンズオン

Transcript

1. ©Fusic Co., Ltd. CONFIDENTIAL OSEKKAI × TECHNOLOGY AI-DLC 入門 〜AIコーディングの本質は「コード」ではなく「構造」〜 AWS AI-DLCハンズオン 2026.03.12 清家史郎 @seike460
2. ©Fusic Co., Ltd. 自己紹介 はじめに 清家 史郎 (@seike460) SHIRO SEIKE 株式会社Fusicプリンシパルエンジニア/エバンジェリスト AWS User Group Leaders AWS Community Builder Serverless 2025 Japan AWS Top Engineers JAWS Days 2026 実行委員長 OSEKKAI × TECHNOLOGY
3. ©Fusic Co., Ltd. 今日お伝えすること 1. AIコーディングの現在地 - Vibe Codingの誘惑と限界 2. AI-DLC とは何か - AWSが提唱する開発ライフサイクル 3. INCEPTION フェーズ - WHATとWHYを構造化する 4. CONSTRUCTION フェーズ - HOWを設計して作る
4. ©Fusic Co., Ltd. 今日お伝えすること • 前半: AIコーディングの課題とAI-DLC 3フェーズの徹底解説 • 後半: ハンズオンでINCEPTIONを体験
5. ©Fusic Co., Ltd. AIコーディング、うまくいっていますか？ • GitHub Copilot でコード補完 • ChatGPT にアプリを作らせてみた • Claude Code で一気に実装 最初は楽しい。でも ...？
6. ©Fusic Co., Ltd. Andrej Karpathy が名付けた「なんとなくAIに任せる」開発 Vibe Coding の誘惑 • エラーが出たらエラーメッセージをコピペ • 最初の一歩としては正しい。問題はここに留まること
7. ©Fusic Co., Ltd. 「動いた！」→ 翌日壊れた Vibe Coding あるある • 機能追加したら、関係ないところが壊れた • 昨日のAIに聞いたことを、今日のAIは知らない • 同じ質問を毎回している 心当たり、ありませんか？
8. ©Fusic Co., Ltd. AIはセッション間で文脈を忘れる なぜ壊れるのか（ 1）コンテキスト喪失 • 昨日の設計意図を知らない • プロジェクトの制約条件を理解していない • 他のファイルとの依存関係が見えていない 人間のチームメイトなら、プロジェクトの文脈を共有している。 AIにはそれがない。
9. ©Fusic Co., Ltd. なぜ壊れるのか （2）要件の曖昧さ + 品質の不在 構造があれば、速さと品質は両立できる。
10. ©Fusic Co., Ltd. コードの問題ではない。AIに渡す「情報」の問題 根本原因：足りないのは「構造」 • 要件の構造化 → 何を作るのかを明確に • 設計と文脈の構造化 → どう作るか・なぜそう作るかを明確に AIは優秀な実装者。でも、構造がなければ力を発揮できない。
11. ©Fusic Co., Ltd. AI-Driven Development Life Cycle AI-DLC とは • AWSが re:Invent 2025 で発表、OSSとして公開 • ソフトウェア開発の進め方そのものを再構築する考え方
12. ©Fusic Co., Ltd. 「ワークフローが仕事に適応する。その逆ではない。」 Adaptive Workflow Principle AIが以下を分析して、必要なステージだけ実行: • ユーザーの意図と既存コードの状態 • 変更の複雑さ・スコープ・リスク シンプルな変更はシンプルに。複雑な変更は包括的に。
13. ©Fusic Co., Ltd. 3つのフェーズ
14. ©Fusic Co., Ltd. AIが主導し、人間が検証・承認 Human-in-the-Loop • 各ステージの完了時に人間の承認が必須 • AIは次のステージに勝手に進めない • 全てのやり取りが audit.md に記録される AIに丸投げではない。 AIと人間の共同作業。
15. ©Fusic Co., Ltd. WHAT と WHY を決める INCEPTION フェーズ • ALWAYS（青） Workspace Detection / Requirements Analysis / Workflow Planning • CONDITIONAL（橙） 残り4ステージはプロジェクトに応じて実行
16. ©Fusic Co., Ltd. 実際にAI-DLCのINCEPTIONフェーズを体験する ハンズオンで体験しよう • 「構造化」の力を、自分の手で実感してください
17. ©Fusic Co., Ltd. PlanModeにしてから実行 実際にやりましょう ▪Claude Code /aws-aidlc-inception /aws-aidlc-construction ▪Codex $aws-aidlc-inception $aws-aidlc-construction ▪その他のIDEなど .claude/commands/aws-aidlc-inception.md を読んでinceptionを実行してください
18. ©Fusic Co., Ltd. 最初に実行されるステージ Workspace Detection（ALWAYS） • aidlc-state.md があれば前回セッションから再開 • AIが最初にやることは「現状を理解する」こと
19. ©Fusic Co., Ltd. 既存コードベースの理解（Brownfieldのみ） Reverse Engineering（CONDITIONAL） 実行条件: 既存コードがあり、まだ分析されていない場合 AIが自動分析する内容 : • ビジネストランザクションの概要 • アーキテクチャドキュメント • コード構造・技術スタック・依存関係
20. ©Fusic Co., Ltd. 要件を構造化する（深度は適応的） Requirements Analysis（ALWAYS） 3つの深度レベル : • Minimal: シンプルで明確なリクエスト → 意図分析のみ • Standard: 通常の複雑さ → 機能・非機能要件を収集 • Comprehensive: 複雑・高リスク → トレーサビリティ付き詳細要件 AIが質問し、人間が答え、要件書を自動生成する。
21. ©Fusic Co., Ltd. AIが生成する質問ファイルの例 Requirements Analysis の実際 チームで議論し、 [Answer]: タグで回答する。
22. ©Fusic Co., Ltd. ユーザーストーリーとペルソナの生成 User Stories（CONDITIONAL） 実行条件: • 新しいユーザー向け機能 • 複数のユーザータイプが関与 • 複雑なビジネス要件
23. ©Fusic Co., Ltd. 実行計画の作成 Workflow Planning（ALWAYS） • 全ての先行コンテキストを読み込む • どのフェーズをどの深度で実行するか決定 • Brownfieldなら変更順序を考慮 ユーザーが実行計画を確認し、ステージの追加・除外を指示できる。
24. ©Fusic Co., Ltd. コンポーネント設計とビジネスルール定義 Application Design（CONDITIONAL） • 新しいコンポーネントやサービスが必要な場合に実行 • 技術スタックに依存しない「純粋なロジック設計」
25. ©Fusic Co., Ltd. システムを作業単位に分解 Units Generation（CONDITIONAL） 実行条件: • 複数のサービスやモジュールが必要 • 構造化された分解が有効な規模 Unit of Work: 独立して開発可能な論理的な作業単位 Unit → CONSTRUCTIONフェーズの Per-Unit Loop に入力
26. ©Fusic Co., Ltd. aidlc-docs/inception/ ディレクトリ INCEPTION の成果物 全てが構造化されたドキュメントとして永続化される。
27. ©Fusic Co., Ltd. 7つのステージで「WHAT と WHY」を構造化 INCEPTION まとめ • ALWAYS Workspace Detection → Requirements Analysis → Workflow Planning • CONDITIONAL: 4ステージ + 全ステージで Human-in-the-Loop • 深度レベル: Minimal / Standard / Comprehensive INCEPTIONが終わった時点で、「何を作るか」が明確になっている。
28. ©Fusic Co., Ltd. HOW を決めて作る CONSTRUCTION フェーズ 目的: 設計 → 実装 → テスト • Per-Unit Loop 各Unitに対して設計→実装のサイクル（詳細は次のMermaid図） • Build and Test（ALWAYS） 全Unit完了後に統合テスト
29. ©Fusic Co., Ltd. Per-Unit Loop の流れ
30. ©Fusic Co., Ltd. ビジネスロジックの技術非依存設計 Functional Design（CONDITIONAL） • 新しいデータモデルや複雑なビジネスロジックがある場合に実行 • 成果物: ドメインモデル、ビジネスルール、データフロー 技術スタックに依存しない「純粋なロジック設計」
31. ©Fusic Co., Ltd. 非機能要件の分析と設計パターン適用 NFR Requirements + NFR Design （CONDITIONAL） • 分析: パフォーマンス・セキュリティ・スケーラビリティ + 技術スタック選定 • 設計: NFRパターン適用 → 論理コンポーネントへの組み込み
32. ©Fusic Co., Ltd. インフラサービスへのマッピング Infrastructure Design（CONDITIONAL） 実行条件: • インフラサービスのマッピングが必要 • デプロイアーキテクチャの設計が必要 • クラウドリソースの指定が必要 例: Lambda + API Gateway + DynamoDB の構成設計 Functional Design が「何をするか」 Infrastructure Design が「どこで動かすか」
33. ©Fusic Co., Ltd. 2パート構成: Planning → Generation Code Generation（ALWAYS） • 承認された計画に基づいて初めてコードを生成 • 「計画なき生成なし」。 Vibe Codingとの決定的な違い
34. ©Fusic Co., Ltd. 全Unitの統合テスト Build and Test（ALWAYS） 全Unitの処理完了後に実行 : • ビルド手順書の生成 • ユニット / インテグレーションテスト手順 • パフォーマンステスト手順（該当する場合） テスト手順書を生成し、人間が確認・実行する。
35. ©Fusic Co., Ltd. Per-Unit Loop + Build and Test CONSTRUCTION まとめ • ALWAYS: Code Generation / Build and Test • CONDITIONAL: Functional Design / NFR / Infrastructure Design
36. ©Fusic Co., Ltd. デプロイと運用（将来拡張領域） OPERATIONS フェーズ 現在はプレースホルダー 将来的に含まれる予定 : • デプロイ計画と実行 • モニタリングとObservability設定 • インシデントレスポンス / メンテナンスワークフロー 現時点では、 Build and Test が CONSTRUCTION フェーズで対応。
37. ©Fusic Co., Ltd. OSS で公開されたワークフロールール awslabs/aidlc-workflows
38. ©Fusic Co., Ltd. 全フェーズに適用される共通ルール Common Rules: 品質の土台 • session-continuity.md: セッション再開のガイダンス • overconfidence-prevention.md: AIの過信防止 • content-validation.md: コンテンツ検証ルール
39. ©Fusic Co., Ltd. 同じステージでも深度が変わる Depth Levels: 適応的な深度 • 変更の複雑さに応じて深度が適応的に変わる
40. ©Fusic Co., Ltd. 複数のAIコーディングエージェントに対応 対応ツール • Kiro: IDEに組み込み済み • Amazon Q Developer / Claude Code: ルールファイルを配置 • Cursor / Cline / GitHub Copilot も対応
41. ©Fusic Co., Ltd. 横断的なルール拡張 Extensions: セキュリティルール • 全フェーズに横断的に適用 • 各ステージ完了時にコンプライアンスチェック • 非準拠はブロッキング （通過できない） セキュリティを「あとから」ではなく「最初から」組み込む。
42. ©Fusic Co., Ltd. たった3ステップで始められる セットアップ方法
43. ©Fusic Co., Ltd. アプリケーションコードとドキュメントの分離 aidlc-docs ディレクトリ構造
44. ©Fusic Co., Ltd. 全てのやり取りを記録 audit.md: 完全な監査証跡 いつ、誰が、何を決定したか。全て記録される。
45. ©Fusic Co., Ltd. AI-DLCの考え方で開発したプロジェクト 実践例: Zenithでの適用 • Zenith: Developer Advocacy Navigator（登壇・執筆・アイデアの一元管理） • INCEPTION→CONSTRUCTION: 14 Units of Work を3週間で完遂 • 成果: 139テスト / tsc 0エラー / Biome 0エラー
46. ©Fusic Co., Ltd. Vibe Coding vs AI-DLC
47. ©Fusic Co., Ltd. AI-DLC 3つのポイント • 構造化が本質 要件・設計・文脈を構造化すれば、AIは正しい方向に力を発揮する • AIが主導、人間が検証 Human-in-the-Loop で品質を担保。AIに丸投げではない • 適応的に実行 必要なステージを必要な深度で。めんどくさいのは絶対ダメ
48. ©Fusic Co., Ltd. 参考リンク • AWS公式ブログ : aws.amazon.com/jp/blogs/news/ai-driven-development-life-cycle/ • awslabs/aidlc-workflows: github.com/awslabs/aidlc-workflows • Kiro / Amazon Q Developer: kiro.dev / aws.amazon.com/q/developer/