Slide 1

Slide 1 text

ゆるWeb勉強会@札幌 #31 最近のお気に入りツール・フレームワーク紹介 AI-DLC の紹介 AI-Driven Development Life Cycle 2026.08.22 / クラスメソッド いわさ 1

Slide 2

Slide 2 text

自己紹介 岩浅 貴大(いわさ) クラスメソッド株式会社 ソリューションアーキテクト X: @Tak1wa Blog: DevelopersIO 2

Slide 3

Slide 3 text

今日話すこと フレームワークとしての AI-DLC 2. ツールとしての AI-DLC 1. 3

Slide 4

Slide 4 text

1. フレームワークとしての AI-DLC 4

Slide 5

Slide 5 text

AI-DLC = AI-Driven Development Life Cycle が提唱するAI駆動開発のフレームワーク 「人間が主導して AI に手伝わせる」のではなく 「AI が主導して人間が承認する」開発フロー AWS 5

Slide 6

Slide 6 text

駆動開発って何? AI 駆動開発(AI-Driven Development)。 年に Gartner が戦略的テクノロジートレンドの1つとして挙げたのが初出とさ れる。 当時は自動テストや AutoML の話で、LLM 以降で意味が大きく変わった。 今は「AIを使って開発すること」を広く指す言葉になってる。 AI-DLC はその中の1つ。 AI 2019 6

Slide 7

Slide 7 text

駆動開発でよくある困りごと AI 設計判断の経緯が残らない。なぜこの実装になったか追えない チーム開発だと各メンバーのやり方がバラバラで揃わない 途中で方針変更すると整合性が壊れる AI に任せきりにすると想定外のものが出てくる 7

Slide 8

Slide 8 text

なぜ AI-DLC が生まれたか の主張 従来の開発プロセスは人間が計画して人間が作る前提で設計されてる AI を補助として足しても、計画・レビュー待ち・すり合わせ等の 人間の作業がボトルネックのまま残る AI を中心に据えて、開発フロー自体を作り直す必要がある Raja SP (AWS Principal) 8

Slide 9

Slide 9 text

経緯 時期 できごと 年 月 AWS DevSphere(バンガロール)で Swami Sivasubramanian が紹介 2025年7月 Raja SP が DevOps Blog で方法論を公開、OSS 化(v1) 2026年7月 v2 GA 2025 7 9

Slide 10

Slide 10 text

AI-DLC AI の本質 が計画を作り、質問し、実装する。人間は判断に集中する 従来(人間リード + AI補助) AI-DLC(AIリード + 人間承認) 人間が要件を書く AI が質問して要件を引き出す 人間が設計を考える AI が設計案を出して人間が承認 人間がコードレビューを依頼して待つ AI が書いた直後に自動チェックが走る 人間がプロジェクト計画を立てる AI がタスクの複雑度を見てプロセスを提案 人間のボトルネックだった部分を AI に移した。 ただし最終判断は常に人間(承認ゲート)。 10

Slide 11

Slide 11 text

フェーズと承認ゲート 3 は開発を3つのフェーズで回す 1. Inception — 何を作るか決めて設計する 2. Construction — 作ってテストする 3. Operations — デプロイして運用する 各フェーズの節目に承認ゲート(Approve / Edit / Reject)。 Intent(作りたいもの1件)を Bolt(時間〜日単位)で1周回す。 AI-DLC 11

Slide 12

Slide 12 text

Mob パターン のブログで出てくるもう1つの重要な概念 Mob Elaboration — AI が出した要件・設計案に対して、チーム全員でリアルタ イムに質問・検証する Mob Construction — AI がコードを書く過程で、技術的判断をチームがリアル タイムに下す 従来の「書いてからレビュー」ではなく「作りながらチームで判断する」。 Raja SP 12

Slide 13

Slide 13 text

その他のフレームワーク上の概念 タスクに応じた軽重 — 全てのタスクに同じ工程を適用しない。 バグ修正と新機能開発では必要なプロセスが違う 学びの引き継ぎ — 各サイクルで得た知見を蓄積して、 次のサイクルではより良い前提で始められるようにする 13

Slide 14

Slide 14 text

2. ツールとしての AI-DLC awslabs/aidlc-workflows 14

Slide 15

Slide 15 text

awslabs/aidlc-workflows で OSS として公開されてる AI-DLC のフレームワークを実際に動かすためのツール群 Kiro IDE, Claude Code, Cursor, Codex CLI など複数のハーネス(実行環境)に 対応 中身(ステージ定義・ツール・プロトコル)は全ハーネス共通。載せ方だけ違 う GitHub 15

Slide 16

Slide 16 text

インストール(Kiro IDE) git clone https://github.com/awslabs/aidlc-workflows.git cd aidlc-workflows && git checkout v2 # 3行コピーするだけ cp -R dist/kiro-ide/.kiro/. your-project/.kiro/ cp -R dist/kiro-ide/aidlc/. your-project/aidlc/ cp dist/kiro-ide/AGENTS.md your-project/AGENTS.md プロジェクトを Kiro で開けば完了。 前提: bun(JS ランタイム)が PATH に通ってること。 16

Slide 17

Slide 17 text

ツールの実体(Kiro IDE の場合) プロジェクトに以下が配置される ワークフローを司るスキル(指揮者) .kiro/hooks/aidlc-*.json — 監査ログ・承認ゲート・状態同期のフック .kiro/agents/ — 14体のエージェント定義 .kiro/tools/ — 状態管理・オーケストレーションの TypeScript ツール aidlc/ — ワークスペース(成果物・記録・ルールが育っていく場所) .kiro/skills/aidlc/SKILL.md — Claude Code だと .claude/ 以下、Cursor だと .cursorrules 等。中身は同じ。 17

Slide 18

Slide 18 text

Kiro IDE での例 左: フック・スキル・エージェント一覧 / 中央: 成果物(Markdown) / 右: チャットでワークフロー実行中 18

Slide 19

Slide 19 text

フレームワーク → ツールの対応 フレームワークの概念 ツールでの実現 3フェーズ(Inception, Construction, Operations) 5フェーズ・33ステージに細分化 承認ゲート 各ステージ末尾の Approve / Edit / Reject Mob Elaboration / Construction 14体のエージェントが分業で担当 Bolt(短いサイクル) Intent 単位のワークフロー実行 学びの引き継ぎ team.md / project.md への自動追記 タスクに応じた軽重 スコープ(express / mvp / feature / compose) 19

Slide 20

Slide 20 text

フェーズ・33ステージ 5 ブログの3フェーズをツールでは5つに細分化。各フェーズの中にステージが並ぶ 何をするか 0 Initialization(初期化) 環境準備 1 Ideation(着想) 何を作るか決める 2 Inception(立ち上げ) 設計を固める 3 Construction(構築) 作ってテストする 4 Operation(運用) デプロイして回す # フェーズ 各ステージの終わりに承認ゲート(Approve / Edit / Reject)。 20

Slide 21

Slide 21 text

ステージ(抜粋 1/2) 各フェーズの中の具体的な作業単位。全33個。担当エージェントが決まってる フェーズ ステージ 何するか 担当 intent-capture 何を作るか明確化 product Ideation scope-definition スコープ決め product rough-mockups ラフ画面案 design practices-discovery チームのやり方を確認 pipeline-deploy domain-design ドメイン設計 architect Inception contract-design API契約定義 architect user-stories ユーザーストーリー product 21

Slide 22

Slide 22 text

ステージ(抜粋 2/2) フェーズ ステージ 何するか 担当 nfr-requirements 非機能要件定義 architect code-generation コード生成 developer Construction build-and-test ビルド&テスト quality ci-pipeline CI構築 pipeline-deploy deployment-execution デプロイ pipeline-deploy Operation observability-setup 監視セットアップ operations feedback-optimization フィードバック改善 operations 抜粋。全33ステージの詳細は stage-graph.json に定義されてる。 22

Slide 23

Slide 23 text

スコープ ワークフロー開始時に「どこまで丁寧にやるか」を選ぶ スコープ ステージ数 使いどころ express 10 バグ修正、小さい API mvp 23 運用は後回し。動くもの優先 feature 33 全部やる compose 可変 AI が複雑度を見て自動で決める 23

Slide 24

Slide 24 text

スコープとステージの関係(抜粋) ステージ intent-capture 実行 scope-definition - domain-design - contract-design - build-and-test 実行 実行 ci-pipeline - deployment-execution - observability-setup - code-generation compose express を選ぶと AI が1個ずつ判定する。 mvp feature 実行 実行 実行 実行 実行 実行 実行 実行 実行 実行 実行 実行 実行 実行 実行 24

Slide 25

Slide 25 text

成果物 aidlc/spaces/default/intents/260820-aws-lambda-api-gateway-r/ ├── ideation/ ← 何を作るか決めた記録 ├── inception/ ← 設計の記録 │ └── practices-discovery/ │ ├── evidence.md ← 判断根拠 │ └── team-practices.md ← チームの決めごと ├── construction/ ← 実装の記録 ├── audit/ ← 監査ログ(全イベント) └── aidlc-state.md ← 今どこにいるか 全部 Markdown。git diff で見れる。 25

Slide 26

Slide 26 text

学びが次に引き継がれる ステージ終了時に AI が「今回学んだこ と」を提案 承認すると team.md や project.md に追 記 次回のワークフローではルールとして読 み込まれる 例: 「trunk-based で十分」「CI/CD は過剰」と 学んだ → 次回はこの前提で動く 26

Slide 27

Slide 27 text

まとめ 駆動開発にも色々なやり方がある AI-DLC はその中の1つ。AI がリードして人間が承認する開発フレームワーク Kiro, Claude Code, Cursor など色々なエージェントにセットアップできる AI駆動開発やりたいけど具体的に何すればいいか迷ってる方は試してみても AI 27

Slide 28

Slide 28 text

ご清聴ありがとうございました 28

Slide 29

Slide 29 text

参考リンク Gartner "Top 10 Strategic Technology Trends for 2019" — gartner.com The Manifesto for AI-Driven Development — ai-driven-development.org Raja SP "AI-Driven Development Life Cycle: Reimagining Software Engineering" — AWS DevOps Blog "Amazon AWS introduces AI-Driven Development" — aboutamazon.in awslabs/aidlc-workflows — github.com AI-DLC Workflows v2 GA — DevelopersIO AI-DLC Kiro IDE ハーネスガイド — github.com (v2 branch) 29