Kiroで見直す開発プロセスとAI-DLC

登壇資料
JAWS-UG 茨城 #12 春の推しAWSサービスLTまつり！
https://jawsug-ibaraki.connpass.com/event/381293/

Transcript

1. JAWS-UG 茨城 #12 Kiroで見直す開発プロセスとAI-DLC（改訂 版） 2026-03-11 / 足立 和生 / アジアクエスト株式会社 JAWS-UG 茨城 #12 春の推しAWSサービスLTまつり！ ※このスライド、Kiroで作りました
2. 自己紹介 足立 和生 アジアクエスト株式会社 2025 Japan AWS Jr. Champion 2025 Japan All AWS Certifications Engineer 2026 AWS Community Builder（Dev Tools） 最近JAWS-UG配信部はいりました！ 好きなAWSサービス: Kiro, CDK 趣味: 長い距離を無限に走ること（去年は100km/日を2回走った） 2
3. 冒頭の問い 3
4. AIがコードを書く時代に、人間は何をレビューしていることになっているのか 今日はAI-DLCを礼賛しません むしろ、AI-DLCを題材に「AI時代の開発で本当に難しいもの」について考えます 便利な話もあまり出てこないかもです 4
5. 01 なぜ今AI-DLCが出てきたのか 5
6. 実装が速くなると、何が起きるか 実名と調査データが示すもの OpenAI チーム（公式ブログ）: エージェントがリポジトリ内の既存パターン（非最適なものも含めて）を複 製。毎週金曜日を「AIスロップ掃除」に費やしたが、スケールしなかった Mitchell Hashimoto（HashiCorp創業者）: エージェントは与えられたゴールを強く最適化する。だから問 題の切り方が悪いと、周辺への悪影響を出しやすい 出典: OpenAI Harness Engineering:https://openai.com/index/harness-engineering/ Zed blog:https://zed.dev/blog/agentic-engineering-with-mitchell-hashimoto 6
7. 実装が速くなると、何が起きるか（続） 調査データ 58% AIコーディングツール導入の最大障壁はセキュリティ不安 （Snyk調査） 90〜100% AI生成リポジトリで「コメント洪水」パターン（OX Security調査） 「自然言語で書いた」だけでは足りない → だから機械的な枠組みが必要になる 出典: Snyk research findings:https://snyk.io/news/research-reveals-genai-race-creates-ai-readiness-perception-gap/ OX Security research:https://www.ox.security/blog/ox-research-ai-code-not-inherently-less-secure-but-army-of-juniors-effect-undermines-software-security/ 7
8. 3つの圧力 1 コードを「書いて覚える」ルートがなくなる — AIが書くので人間が書く量が激減。従来の習熟経路が機能しに くくなる 2 生成量と人間の処理能力の速度差 — AIの生成速度は上がり続けるが、人間の読解速度は変わらない。 「読んで レビューする」体制はスケールしない 3 丁寧なレビュープロセスが競争を妨げる — 軽いプロセスを持つ組織の方が動きが速くなる。 「丁寧さ」の定義 を問い直す必要が出てくる 8
9. AI活用の3段階 段階 主役 人間の役割 強み 弱み AI支援 人間 AIを道具として使う 導入しやすい 局所最適で止まる AI丸投げ AI 出力を受け取る 速い 品質・理解・責任が崩れる AI-DLC 協働 仕様・制約・検証を設計 速度と整合性を両立 高いスキルと協働が必要 AI丸投げは個人開発・探索的試作では成立する場面がある しかしチーム・継続開発ではAI-DLCの考え方が必要になる 9
10. なぜ「AI丸投げ」だけでは足りないのか 仕様が曖昧だと 破綻 変更理由が追えない （なぜこうなったの かが消える） チームの理解が 消える 「誰が何を理解して いるか」が不明にな る 技術負債が見え ない 継続運用で負債が蓄 積しても検知できな い 持続可能でない コードは動いている が誰も説明できない 状態 10
11. 第1幕まとめ AI時代の開発は実装速度には価値がなくなり、意思決定と設計競争になった この問いに、AI-DLCはどう答えているのか AWSがオープンソースで公開したAI-DLCは、 「判断の設計」を体系化しようとした試みに見える 11
12. 02 AI-DLCとは何か — ガバナンス の枠組みとして 12
13. AI-DLCとは — 2つの柱 AI-DLC (AI-DRIVEN DEVELOPMENT LIFE CYCLE) AWSが2025年11月にブログ公開し、awslabs がworkflowをOSS公開した、AI主導開発の方法論 1. AIが実行し、人間が監視する AIが計画を作り、人間に意図確認を求め、重要な 決定は人間に委ねる 2. ダイナミックなチームコラボレーシ ョン AIがルーティン処理する一方、チームがリアルタ イムで意思決定に参加する 出典: AWS DevOps Blog:https://aws.amazon.com/blogs/devops/building-with-ai-dlc-using-amazon-q-developer/ GitHub aidlc-workflows:https://github.com/awslabs/aidlc-workflows 13
14. AI-DLCの3フェーズと14ステージ 公開WORKFLOW実装: 14ステージ相当（うちOPERATIONSはPLACEHOLDER） 種別 数 内容 ALWAYS 5 どんなプロジェクトでも必ず実行 CONDITIONAL 8 プロジェクト状態に応じてAIが実行/スキップを判断 PLACEHOLDER 1 現行実装では将来拡張用 シンプルなバグ修正 → ALWAYSの5ステージ中心で完結しうる 大規模システム構築 → CONDITIONALも含めて広く実行される INCEPTION（計画）→ CONSTRUCTION（実装）→ OPERATIONS（運用） 何を・なぜ作るか どう作り・検証するか 公開workflow実装では拡張枠に近い 出典: AWS DevOps Blog:https://aws.amazon.com/blogs/devops/building-with-ai-dlc-using-amazon-q-developer/ GitHub aidlc-workflows core workflow:https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-rules/aws-aidlc-rules/core-workflow.md 14
15. INCEPTIONフェーズ — 曖昧さを仕様に変える 質問ファイル方式（公式ルールに基づく例） 矛盾の検出 / 監査証跡 / 「なぜこう決めたか」の保存 # Requirements Verification Questions ## Question 1 このアプリケーションのプラットフォームは何ですか？ A) Webアプリケーション（ブラウザベース） B) モバイルアプリ（iOS/Android） C) デスクトップアプリ（Electron等） D) Web + モバイル両方 X) Other (please describe after [Answer]: tag below) [Answer]: A 出典: GitHub aidlc-workflows requirements analysis:https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-rules/aws-aidlc-rule-details/inception/requirements-analysis.md GitHub aidlc-workflows question format guide:https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-rules/aws-aidlc-rule-details/common/question-format-guide.md 15
16. CONSTRUCTIONフェーズ — 計画が先、コードは 後 PER-UNIT LOOP（公式ワークフローの要約） AIはいきなりコードを書かない → 計画を承認してからコード生成する フェーズ2: CONSTRUCTION（詳細設計、実装、テスト） ├─ ステージ7: 機能設計 [実行予定] ├─ ステージ8: NFR要件 [実行予定] ├─ ステージ9: NFR設計 [実行予定] ├─ ステージ10: インフラ設計 [実行予定] ├─ ステージ11: コード生成 [実行予定] └─ ステージ12: ビルドとテスト [実行予定] 出典: GitHub aidlc-workflows core workflow:https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-rules/aws-aidlc-rules/core-workflow.md 16
17. 承認ゲートと監査証跡 承認ゲート 14ステージ相当の枠組みのうち、12ステージで明 示承認を要求 Constructionの完了メッセージは2択（Request Changes / Continue to Next Stage） Requirements Analysis では条件付きで3択（Add User Stories を含む） 監査証跡（実際のログ） 原文のまま追記のみ（上書き・要約禁止） 2026-02-23T17:06:15+09:00 Phase: INCEPTION Stage: Workspace Detection User Input: "slackのクローンを 作りたい" 出典: GitHub aidlc-workflows core workflow:https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-rules/aws-aidlc-rules/core-workflow.md GitHub aidlc-workflows requirements analysis:https://github.com/awslabs/aidlc-workflows/blob/main/aidlc-rules/aws-aidlc-rule-details/inception/requirements-analysis.md 17
18. ルールファイルの構造 コード設計と同じ思想でルールが構造化されている 設計思想: DRY・関心の分離で管理 共通規約は common/ に置いて各フェーズから参照 aidlc-rules/ ├── core-workflow.md ← "憲法"（全体を統括） ├── common/（全ステージ共通・11ファイル） │ ├── overconfidence-prevention.md │ ├── question-format-guide.md │ └── content-validation.md ... ├── inception/（7ファイル） └── construction/（6ファイル） 18
19. なぜKiroなのか KiroはAI-DLC思想を「最も露骨に見せてくれる」ツール 優れているツールは他にもあるが、Kiroは観察対象として面白い Spec・Steering・Hooks・Powersというガバナンス構造が前面にでている 19
20. Kiroの核心 — Spec駆動開発 複雑な変更を構造化された成果物に落とし込む セッションが終わっても意図が消えない チームで「なぜこう作ったか」を共有できる .kiro/specs/my-feature/ ├── requirements.md # 何を達成するか（ユーザーストーリー形式） ├── design.md # どう実現するか（技術設計） └── tasks.md # 実装ステップ（チェックリスト形式） 出典: Kiro Specs:https://kiro.dev/docs/specs/ 20
21. KiroのSteering — 意図の永続化 会話をまたいで「規約・アーキテクチャ・標準」を永続化 src/api/ 以下のファイルを触るとき、自動でこのルールが適用される 「毎回説明し直さなくてよい状態」をファイルとして外部化する # .kiro/steering/api-conventions.md --- inclusion: fileMatch fileMatchPattern: "src/api/**/*.ts" --- # API規約 - エラーレスポンスは必ずErrorResponseType型を使う - 認証チェックはmiddleware層で行う 出典: Kiro Steering:https://kiro.dev/docs/steering/ 21
22. KiroのHooks — 自動化とガードレール KIRO IDE: ファイル保存・タスク前後・ツール前後 / KIRO CLI: EVENT HOOKS Kiro CLI の PreToolUse は終了コード 2 でブロック。 stderr の理由がLLMに返る それ以外の非ゼロ終了は警告扱い。それでも 「理由を教えて直させる」 ことはできる { "hook_event_name": "preToolUse", "tool_name": "shell", "tool_input": { "command": "rm -rf /important/data" } } 出典: Kiro Hook types:https://kiro.dev/docs/hooks/types/ Kiro CLI Hooks:https://kiro.dev/docs/cli/hooks/ 22
23. 第2幕まとめ — 何を統治しているのか 1 AI-DLCは「AIに開発を任せるフレームワーク」 2 同時に「AIと協働しながら、人間の判断権を守るためのガバナンス設計」 3 ガバナンスの対象は「AIの行動」だけでなく「責任の所在」と「意図の連続性」 Kiroはその思想を具体的なツールとして実装している ここで第3幕の問いを立てる — 「このガバナンスは本当に効くのか」 23
24. 03 その統治は本当に効くのか 24
25. 問い「そのレビューは本当に品質をあげているの か？」 1 AIは数秒でコードを書く 2 人間は数分で「見たことにする」 3 組織はその記録をもって「統制が機能している」と言う 問題は個人の怠慢ではない AIがコードを書く構造がそもそも、人間の理解能力を超えた速度差の上に置かれている 25
26. 問題1 — 自然言語仕様は制約として弱い 「書いた」のに「やらなかった」 「 any 型を使わないこと」と書いた → 型推論に失敗した箇所をすべて any で処理した 「既存のファイルを修正すること」と書いた → 似た名前の新しいファイルを作り、古いファイルを放置した 「セキュリティを考慮すること」と書いた → それだけでは足りない。Snyk調査では約58%が導入障壁として セキュリティ不安を挙げる 出典: Snyk research findings:https://snyk.io/news/research-reveals-genai-race-creates-ai-readiness-perception-gap/ 26
27. 自然言語の限界を超えるには 厳密性は自然言語ではなく機械（決定論的な拘束手段）に逃がす 機械（決定論的な拘束手段） テスト（テストは嘘をつけない） 型・スキーマ定義 リンター・静的解析 CI/CDパイプライン 自然言語の役割（対話と合意） 要件の対話 チームの合意形成 意図の記録 判断の根拠 27
28. 問題2 — 環境をどう設計するか（Harness Engineering） HARNESS ENGINEERING = エージェントが信頼できる仕事をする環境を設計すること 従来のエンジニア 「正しいコードを書く」 Harness Engineering時代 「エージェントが信頼できる仕事をする環境を設計 する」 モデルではなくシステム（環境設計）が重要 AI-DLCの「承認ゲート・監査証跡・質問ファイル」を流行りの語彙で言うとHarness Engineering 出典: OpenAI Harness Engineering:https://openai.com/index/harness-engineering/ 28
29. Hooksによる品質フィードバックループ 3つのHOOKパターン Safety Gates（PreToolUse） 危険なツール呼び出しをブロック → 終了コード 2 と理由を返す → AIが代替手段を検討 Quality Loops（PostToolUse） ファイル編集後にリンター自動実行 → 結果をコンテキストに注入 → AIが自己修正 Completion Gates（Agent Stop / Stop） 「完了」宣言時にテスト実行 → 失敗を返して再修正を促す 出典: Kiro Hook types:https://kiro.dev/docs/hooks/types/ Kiro CLI Hooks:https://kiro.dev/docs/cli/hooks/ 29
30. 問題3 — 人間が承認すれば本当に安全なのか 1 承認者が成果物を本当に理解できるとは限らない 2 AI生成物をレビューし続けると「承認疲れ（Approval Fatigue） 」が発生する 3 承認フローの隠れた役割：「正しさの保証」ではなく「責任の署名欄」 4 厳格な承認ゲートほど、通過儀礼（セキュリティシアター）になりやすい 2000行のPRを15分でレビューしてApproveするとき、何をレビューしたことになっているのだろうか・・・？ 30
31. 人間が問うべき問いを変える 問い 担い手 コードが仕様通りか AIとツール（テスト・型・リンター） 仕様そのものが正しいか 人間 「このコードは仕様通りか？」→「この仕様でよいのか？」 コードレビューをAIとツールに委ね、人間は「仕様そのものが正しいか」に注力する 31
32. 第3幕まとめ AIが間違えること自体は問題の本質ではない。人間がまだ詳細な仕様やレビューで制御できると思い込 みやすいことだ 問題1 — 自然言語仕様は制約として弱い 問題2 — 環境をどう設計するか 問題3 — 人間が承認すれば本当に安全なのか 32
33. 04 人間の役割の再定義 33
34. 全部読むのか、全部手放すのか ALL OR NOTHING ではない 全部読む 不可能（速度差が大きすぎる） 全部手放す 破綻しやすい（責任が宙に浮く） 人間の仕事は「どこで理解を諦め、どこで責任を引き受けるか」の境界線を設計すること 34
35. 人間が設計すべき4つの境界 1 何をAIに委ねるか — 実装・ドキュメント・初期テスト生成 2 どこに制約を置くか — リンター・型・CI・Hooks 3 何をテストで固定するか — 仕様・期待動作・制約 4 どこで人間が責任を持つか — 要件・価値判断・最終承認 「何を良しとするかを設計する人間」へ役割がずれていく 35
36. 明日から始めるAI-DLC（まずハーネスを作る） MINIMUM VIABLE HARNESS 1 リポジトリを清潔に保つ — 実行可能なアーティファクトだけ置く（余計なコンテキストを置かない） 2 決定論的ツールを入れる — 静的解析・リンター・型チェッカー 3 Hookを1つ作る — PostToolUseでリンター自動実行など 4 テストを厚くする — エージェントのミスが起きたらテストを追加 5 Specを残す — .kiro/specs/ or requirements.md 1枚から ハーネスへの投資は複利で効く。モデルが変わっても生きる 36
37. AI時代に必要なスキルセット 中心に据えるべき 価値判断力 — 要件妥当性の判断（人間にしか できない） ガードレール設計力 — Harness・Hooks・CI （機械に任せる部分を設計する） 補完するもの 問題設定力 仕様記述力 テスト設計力 ファシリテーション これらは新しいスキルではない — エンジニアリングの本質がずっとそうだったのに、実装の速さに隠れていただけ かもしれない 37
38. AI-DLCは過渡期の思想 具体的なツールや承認の儀式は、数カ月後に変わっているかもしれない しかし 「AIコーディングエージェントの責任境界や環境をどう設計するか」という問い自体は残る 2026年現在、私たちは人間からAIに主導権が移る過渡期にいる AI-DLCは、もう人間が全部は理解も制御もできない事実を認めた方が上手く行くのかもしれない 38
39. まとめ 39
40. Verification から Validation へ 担い手 Verification（仕様通りか） AIとツールに委ねる Validation（仕様でよいか） 人間が担う Harness設計（環境の設計） 人間が担う 1 AI-DLCはAIに丸投げする方法ではない 2 ガバナンスの枠組みだが、その統治も完全ではない（自然言語の弱さ・レビュー承認疲れ） 3 今から整えるべきは: Spec・テスト・CI/HooksなどのHarness設計 40
41. 最後の一言 How はAIに寄りやすくなる。だから人間は: What 何を作るか Why なぜそれが必要か 制約 何を守らなければならないか 優先順位 どれが重要か 品質基準 何を良しとするか 作ることが簡単になるほど、 「これを実現したら何が変わるのか」を言語化しておくのが大事 41
42. ありがとうございました Kazuki Adachi 𝕏 (Twitter): @k_adachi_01