AI-DLC(AI-Driven Development Life Cycle) with Kiro

2026/02/25 品川会#3 登壇資料
AWSの提唱するAI-DLC(AI-Driven Development Life Cycle)の概要とGithubリポジトリで試した所感です。

Transcript

1. Copyright © 2026 AsiaQuest Co.,Ltd. All Rights reserved 2026/02/25 品川会 ⾜⽴和⽣ / Kazuki Adachi AI-DLC(AI-Driven Development Life Cycle) with Kiro
2. 今⽇のゴール 2 • AI-DLC（AI-Driven Development Life Cycle）とは何かを理解する • 従来の開発⼿法や「単なるAI⽀援」との決定的な違いを把握する • 直⾯する課題と、それを乗り越えるための対策を知る • 明⽇から現場で"AI駆動開発"を試すための第⼀歩を持ち帰る
3. まずはじめに AsiaQues t Copyright © 2026 AsiaQuest Co.,Ltd. All Rights reserved 3 「AIのおかげでコードを書くのは何⼗倍も速くなった。 じゃあ、開発全体の時間は速くなったのか…？」
4. 自己紹介 ⾜⽴ 和⽣(あだちかずき) @k-adachi-01 ▼ 所属 アジアクエスト株式会社 ▼肩書き 2025 AWS Jr. Champion 2025 All AWS Certifications Engineer ▼現在の業務 建設会社様向けのIT⽀援や顧客折衝 業務ではAWSを触っていない（⾮エンジニア！） ▼趣味 ⾛ること（トレイルランニング、ウルトラマラソン）
5. AI開発の3つの段階 6
6. ①AI⽀援（AI-Assisted） 7 AIを開発プロセスの⼀部に利⽤: ・関数単位やクラス単位の補完 ‧従来の開発にそのまま使える ‧⼈間がコントロールできる
7. AI⽀援（AI-Assisted）の限界 7 • 局所的な最適化: 関数単位やクラス単位の補完には強いが、アーキテクチャ全体を⾒据えた設計はできな い。 • コンテキスト供給の負担: AIが良いコードを書くためには、⼈間が常に詳細な⽂脈（コンテキスト）を与え続ける必 要がある。 • 主導権は依然として⼈間: ⼈間の認知的な負荷や思考速度がボトルネックのまま。
8. ②AI丸投げ（AI-Managed） 7 AIを開発のすべてをお任せ: ・いわゆるVibe Coding ‧AIの性能をフルに本領発揮 ‧開発スピードが段違いにあがる
9. AI丸投げ（AI-Managed、Vibe Coding）の限界 8 • 要件のブレがバグを増幅: 曖昧な指⽰（Vibe）で動かすと、AIの幻覚（ハルシネーション）により意図しない巨⼤な コードの塊が⽣成される。 • ブラックボックス化: 「なぜ動いているのかわからない」コードが量産され、保守や障害対応が不可能になる。 • 責任の所在の消失: AIは最終的なビジネス要件に対して責任を取ることができない。
10. ③AI-DLC（AI-Driven Development Life Cycle） 9 AI-DLC（AI-Driven Development Life Cycle）とは： • AWSの提唱するAIネイティブな開発⼿法 • 開発ライフサイクル全体でAIが会話をリード • AIを実⾏の「主導者（Driver）」に据えつつ、 ⼈間が「仕様」と「ガードレール」で制御する
11. 3フェーズの紹介―Inception, Construction, Operation 16 1 Inception（構想‧仕様定義） ⼈間がビジネス要件を定義し、AIが解釈可能な「構造化された仕様書」を作成する。 2 Construction（構築‧実装） 仕様書をもとに、AIエージェントが⾃律的にコードとテストを⽣成‧修正する。 3 Operation（運⽤‧改善） 稼働後のログやエラーをAIが分析し、次のInceptionに向けた改善案を提⽰する。
12. 課題と対策 18
13. 根本的な問題―LLMの⾮決定性 19 • LLM（⼤規模⾔語モデル）は確率的モデル： 全く同じ仕様書（Spec）を作成しても、出⼒されるコードが毎回同じになるとは限らな い。 • システム開発における「⾮決定性」の恐怖： 既存の機能に影響を与えず、安全にコードを更新‧維持できるか（再現性）の担保が極め て難しい。
14. レビュー負荷の爆増―⼈間の認知資源がボトルネックに 20 • AIは数秒で数百⾏、数千⾏のコードを⽣成する。 • ⼈間がその「他⼈が書いた（しかもAIが書いた）⼤量のコード」の意図を汲み取り、正し さを⽬視で確認するのは⾮現実的。 • 結果として、レビュー待ちのPR（Pull Request）が⼭積みになり、プロジェクト全体が停 滞する。
15. ⼈間が承認すれば「安⼼」なのか？―厳しすぎるスキル要件 22 「最終確認は⼈間が⾏うから安全」という主張の落とし⽳。 • AIのコードを正しくレビューするには、AI以上のアーキテクチャ理解と経験を持つシニア エンジニアが必要。 • ジュニアエンジニアがAIを使って⽣成したコードを、シニアエンジニアが時間をかけてレ ビューする構造になり、本末転倒になるリスク。
16. 実際に試してみた 25
17. AWSの公開しているOSS―ai-dlc-workflows 27 • AWSが試験的に公開しているAI-DLCの実装例。 • 構成要素： KiroのSteeringファイルとしてAI-DLCのワークフローを定義 • 狙い： Issueの発⾏から、要件定義、実装、PRの作成までをエージェントが⾃律的に進めるエン タープライズ向けワークフローの模索。 https://github.com/awslabs/aidlc-workflows
18. どのように開発が進むか？ 28 AI-DLCパイプラインでの開発の流れ： 1 Inception: ⼈間がIssueに「やりたいこと（What）」をざっくり書く。AIが詳細な要件仕 様（Markdown等）に落とし込み、⼈間に確認を求める。 2 Construction: 承認された仕様をもとに、AIエージェントがコードベースを解析し、実装 ‧テストコードを記述。PRを作成。 3 Operation: デプロイ後、監視ツールのアラートをAIが受領し、修正のIssueを⾃動起票。
19. どのように開発が進むか？ 28 ai-dlc-workflowのフォルダの中⾝：
20. 実際に触ってみた所感 30 • 予想以上に動く： 適切な仕様書さえあれば、CRUD機能やAPIのモックなどは⼀瞬で組み上 がる。 • 仕様書の品質が全て： 曖昧な⽇本語や⽭盾した指⽰は、容赦なくバグとして実装される （Garbage In, Garbage Out）。 • 「コードを直す癖」からの脱却が⾟い： 意図と違うコードが出た時、⼿でサクッと直した くなる誘惑（これをするとAIとコードの同期が取れなくなる）に耐える必要がある。
21. 個⼈開発での限界―AI-DLCの真価はコラボレーション 31 • ⼀⼈で開発している場合、認識の齟齬は起きない • 真価が発揮されるのはチーム開発： ‧PdMが書いた仕様書（Markdown）をそのままAIが実装する。 ‧「誰が読んでもわかる仕様」が常に最新の状態で維持される。 ‧属⼈化の排除と、オンボーディングコストの劇的な低下。
22. まとめ 33
23. AI-DLCはAIが開発の実⾏を主導するアプローチ 34 もはやAIは「開発を助けてくれる補助ツール」ではありません。 • 開発の「How（どう実装するか）」はAIの仕事へ。 • ⼈間は「What（何を作るか）」と「Why（なぜ作るか）」の定義に全⼒を注ぐ。 • 仕様こそがソースコードとなり、コードは単なるビルド成果物へと変化していく。
24. 最後に伝えたいこと 36 AIが開発を主導する世界で⼈間の役割とは？ 倫理的な判断、ビジネス価値の創出、 そして「AIに対する最終的な責任を背負うこと」。 そのための「技術スキルを磨き続けること」。