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

Embed

Start on current slide

Slide 1

Slide 1 text

©Fusic Co., Ltd. CONFIDENTIAL OSEKKAI × TECHNOLOGY AI-DLC 入門〜AIコーディングの本質は「コード」ではなく「構造」〜 AWS AI-DLCハンズオン 2026.03.12 清家史郎 @seike460

Slide 2

Slide 2 text

©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

Slide 3

Slide 3 text

©Fusic Co., Ltd. 今日お伝えすること 1. AIコーディングの現在地 - Vibe Codingの誘惑と限界 2. AI-DLC とは何か - AWSが提唱する開発ライフサイクル 3. INCEPTION フェーズ - WHATとWHYを構造化する 4. CONSTRUCTION フェーズ - HOWを設計して作る

Slide 4

Slide 4 text

©Fusic Co., Ltd. 今日お伝えすること ● 前半: AIコーディングの課題とAI-DLC 3フェーズの徹底解説 ● 後半: ハンズオンでINCEPTIONを体験

Slide 5

Slide 5 text

©Fusic Co., Ltd. AIコーディング、うまくいっていますか？ ● GitHub Copilot でコード補完 ● ChatGPT にアプリを作らせてみた ● Claude Code で一気に実装最初は楽しい。でも ...？

Slide 6

Slide 6 text

©Fusic Co., Ltd. Andrej Karpathy が名付けた「なんとなくAIに任せる」開発 Vibe Coding の誘惑 ● エラーが出たらエラーメッセージをコピペ ● 最初の一歩としては正しい。問題はここに留まること

Slide 7

Slide 7 text

©Fusic Co., Ltd. 「動いた！」→ 翌日壊れた Vibe Coding あるある ● 機能追加したら、関係ないところが壊れた ● 昨日のAIに聞いたことを、今日のAIは知らない ● 同じ質問を毎回している心当たり、ありませんか？

Slide 8

Slide 8 text

©Fusic Co., Ltd. AIはセッション間で文脈を忘れるなぜ壊れるのか（ 1）コンテキスト喪失 ● 昨日の設計意図を知らない ● プロジェクトの制約条件を理解していない ● 他のファイルとの依存関係が見えていない人間のチームメイトなら、プロジェクトの文脈を共有している。 AIにはそれがない。

Slide 9

Slide 9 text

©Fusic Co., Ltd. なぜ壊れるのか（2）要件の曖昧さ + 品質の不在構造があれば、速さと品質は両立できる。

Slide 10

Slide 10 text

©Fusic Co., Ltd. コードの問題ではない。AIに渡す「情報」の問題根本原因：足りないのは「構造」 ● 要件の構造化 → 何を作るのかを明確に ● 設計と文脈の構造化 → どう作るか・なぜそう作るかを明確に AIは優秀な実装者。でも、構造がなければ力を発揮できない。

Slide 11

Slide 11 text

©Fusic Co., Ltd. AI-Driven Development Life Cycle AI-DLC とは ● AWSが re:Invent 2025 で発表、OSSとして公開 ● ソフトウェア開発の進め方そのものを再構築する考え方

Slide 12

Slide 12 text

©Fusic Co., Ltd. 「ワークフローが仕事に適応する。その逆ではない。」 Adaptive Workflow Principle AIが以下を分析して、必要なステージだけ実行: ● ユーザーの意図と既存コードの状態 ● 変更の複雑さ・スコープ・リスクシンプルな変更はシンプルに。複雑な変更は包括的に。

Slide 13

Slide 13 text

©Fusic Co., Ltd. 3つのフェーズ

Slide 14

Slide 14 text

©Fusic Co., Ltd. AIが主導し、人間が検証・承認 Human-in-the-Loop ● 各ステージの完了時に人間の承認が必須 ● AIは次のステージに勝手に進めない ● 全てのやり取りが audit.md に記録される AIに丸投げではない。 AIと人間の共同作業。

Slide 15

Slide 15 text

©Fusic Co., Ltd. WHAT と WHY を決める INCEPTION フェーズ ● ALWAYS（青） Workspace Detection / Requirements Analysis / Workflow Planning ● CONDITIONAL（橙）残り4ステージはプロジェクトに応じて実行

Slide 16

Slide 16 text

©Fusic Co., Ltd. 実際にAI-DLCのINCEPTIONフェーズを体験するハンズオンで体験しよう ● 「構造化」の力を、自分の手で実感してください

Slide 17

Slide 17 text

©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を実行してください

Slide 18

Slide 18 text

©Fusic Co., Ltd. 最初に実行されるステージ Workspace Detection（ALWAYS） ● aidlc-state.md があれば前回セッションから再開 ● AIが最初にやることは「現状を理解する」こと

Slide 19

Slide 19 text

©Fusic Co., Ltd. 既存コードベースの理解（Brownfieldのみ） Reverse Engineering（CONDITIONAL）実行条件: 既存コードがあり、まだ分析されていない場合 AIが自動分析する内容 : ● ビジネストランザクションの概要 ● アーキテクチャドキュメント ● コード構造・技術スタック・依存関係

Slide 20

Slide 20 text

©Fusic Co., Ltd. 要件を構造化する（深度は適応的） Requirements Analysis（ALWAYS） 3つの深度レベル : ● Minimal: シンプルで明確なリクエスト → 意図分析のみ ● Standard: 通常の複雑さ → 機能・非機能要件を収集 ● Comprehensive: 複雑・高リスク → トレーサビリティ付き詳細要件 AIが質問し、人間が答え、要件書を自動生成する。

Slide 21

Slide 21 text

©Fusic Co., Ltd. AIが生成する質問ファイルの例 Requirements Analysis の実際チームで議論し、 [Answer]: タグで回答する。

Slide 22

Slide 22 text

©Fusic Co., Ltd. ユーザーストーリーとペルソナの生成 User Stories（CONDITIONAL）実行条件: ● 新しいユーザー向け機能 ● 複数のユーザータイプが関与 ● 複雑なビジネス要件

Slide 23

Slide 23 text

©Fusic Co., Ltd. 実行計画の作成 Workflow Planning（ALWAYS） ● 全ての先行コンテキストを読み込む ● どのフェーズをどの深度で実行するか決定 ● Brownfieldなら変更順序を考慮ユーザーが実行計画を確認し、ステージの追加・除外を指示できる。

Slide 24

Slide 24 text

©Fusic Co., Ltd. コンポーネント設計とビジネスルール定義 Application Design（CONDITIONAL） ● 新しいコンポーネントやサービスが必要な場合に実行 ● 技術スタックに依存しない「純粋なロジック設計」

Slide 25

Slide 25 text

©Fusic Co., Ltd. システムを作業単位に分解 Units Generation（CONDITIONAL）実行条件: ● 複数のサービスやモジュールが必要 ● 構造化された分解が有効な規模 Unit of Work: 独立して開発可能な論理的な作業単位 Unit → CONSTRUCTIONフェーズの Per-Unit Loop に入力

Slide 26

Slide 26 text

©Fusic Co., Ltd. aidlc-docs/inception/ ディレクトリ INCEPTION の成果物全てが構造化されたドキュメントとして永続化される。

Slide 27

Slide 27 text

©Fusic Co., Ltd. 7つのステージで「WHAT と WHY」を構造化 INCEPTION まとめ ● ALWAYS Workspace Detection → Requirements Analysis → Workflow Planning ● CONDITIONAL: 4ステージ + 全ステージで Human-in-the-Loop ● 深度レベル: Minimal / Standard / Comprehensive INCEPTIONが終わった時点で、「何を作るか」が明確になっている。

Slide 28

Slide 28 text

©Fusic Co., Ltd. HOW を決めて作る CONSTRUCTION フェーズ目的: 設計 → 実装 → テスト ● Per-Unit Loop 各Unitに対して設計→実装のサイクル（詳細は次のMermaid図） ● Build and Test（ALWAYS）全Unit完了後に統合テスト

Slide 29

Slide 29 text

©Fusic Co., Ltd. Per-Unit Loop の流れ

Slide 30

Slide 30 text

©Fusic Co., Ltd. ビジネスロジックの技術非依存設計 Functional Design（CONDITIONAL） ● 新しいデータモデルや複雑なビジネスロジックがある場合に実行 ● 成果物: ドメインモデル、ビジネスルール、データフロー技術スタックに依存しない「純粋なロジック設計」

Slide 31

Slide 31 text

©Fusic Co., Ltd. 非機能要件の分析と設計パターン適用 NFR Requirements + NFR Design （CONDITIONAL） ● 分析: パフォーマンス・セキュリティ・スケーラビリティ + 技術スタック選定 ● 設計: NFRパターン適用 → 論理コンポーネントへの組み込み

Slide 32

Slide 32 text

©Fusic Co., Ltd. インフラサービスへのマッピング Infrastructure Design（CONDITIONAL）実行条件: ● インフラサービスのマッピングが必要 ● デプロイアーキテクチャの設計が必要 ● クラウドリソースの指定が必要例: Lambda + API Gateway + DynamoDB の構成設計 Functional Design が「何をするか」 Infrastructure Design が「どこで動かすか」

Slide 33

Slide 33 text

©Fusic Co., Ltd. 2パート構成: Planning → Generation Code Generation（ALWAYS） ● 承認された計画に基づいて初めてコードを生成 ● 「計画なき生成なし」。 Vibe Codingとの決定的な違い

Slide 34

Slide 34 text

©Fusic Co., Ltd. 全Unitの統合テスト Build and Test（ALWAYS）全Unitの処理完了後に実行 : ● ビルド手順書の生成 ● ユニット / インテグレーションテスト手順 ● パフォーマンステスト手順（該当する場合）テスト手順書を生成し、人間が確認・実行する。

Slide 35

Slide 35 text

©Fusic Co., Ltd. Per-Unit Loop + Build and Test CONSTRUCTION まとめ ● ALWAYS: Code Generation / Build and Test ● CONDITIONAL: Functional Design / NFR / Infrastructure Design

Slide 36

Slide 36 text

©Fusic Co., Ltd. デプロイと運用（将来拡張領域） OPERATIONS フェーズ現在はプレースホルダー将来的に含まれる予定 : ● デプロイ計画と実行 ● モニタリングとObservability設定 ● インシデントレスポンス / メンテナンスワークフロー現時点では、 Build and Test が CONSTRUCTION フェーズで対応。

Slide 37

Slide 37 text

Slide 38

Slide 38 text

©Fusic Co., Ltd. 全フェーズに適用される共通ルール Common Rules: 品質の土台 ● session-continuity.md: セッション再開のガイダンス ● overconfidence-prevention.md: AIの過信防止 ● content-validation.md: コンテンツ検証ルール

Slide 39

Slide 39 text

Slide 40

Slide 40 text

©Fusic Co., Ltd. 複数のAIコーディングエージェントに対応対応ツール ● Kiro: IDEに組み込み済み ● Amazon Q Developer / Claude Code: ルールファイルを配置 ● Cursor / Cline / GitHub Copilot も対応

Slide 41

Slide 41 text

©Fusic Co., Ltd. 横断的なルール拡張 Extensions: セキュリティルール ● 全フェーズに横断的に適用 ● 各ステージ完了時にコンプライアンスチェック ● 非準拠はブロッキング（通過できない）セキュリティを「あとから」ではなく「最初から」組み込む。

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

©Fusic Co., Ltd. AI-DLCの考え方で開発したプロジェクト実践例: Zenithでの適用 ● Zenith: Developer Advocacy Navigator（登壇・執筆・アイデアの一元管理） ● INCEPTION→CONSTRUCTION: 14 Units of Work を3週間で完遂 ● 成果: 139テスト / tsc 0エラー / Biome 0エラー

Slide 46

Slide 46 text

Slide 47

Slide 47 text

©Fusic Co., Ltd. AI-DLC 3つのポイント ● 構造化が本質要件・設計・文脈を構造化すれば、AIは正しい方向に力を発揮する ● AIが主導、人間が検証 Human-in-the-Loop で品質を担保。AIに丸投げではない ● 適応的に実行必要なステージを必要な深度で。めんどくさいのは絶対ダメ

Slide 48

Slide 48 text

©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/