趣味でも現場でも使える！Kiro活用体験談から学ぶ、生成AIを活用した新しい開発の形

Transcript

1. 趣味でも現場でも使える！ クラウドゼミナール：ToyoStar☆ Kiro活⽤体験から学ぶ、新しい開発の形
2. 若者にクラウドを広め、⽇本のクラウドリテラシーを⾼めたい！ ⽇本の未来をもっとワクワクするものにしたい そのために、ITの⼒、特にパブリッククラウドの活⽤が有⼒な⼿段 の⼀つであると私たちは考えています。 でも、クラウドって難しそうだし、どこから学べばいいかわからな い…。 そんな⼤学⽣に向けて、私たち若⼿エンジニアが、少し先を ⾏く先輩としてクラウドの学びをサポートします！ 「クラウドって⾯⽩い！」そう思える⼈を増やしたい。 ⼀緒に学ん で、⽇本の未来をもっと盛り上げていきましょう！ 私たちについて
3. ⼤学⽣＆若⼿エンジニア向けの無料クラウド勉強会 主な活動内容 • そもそもクラウドって何？ • どういうところで活⽤されているの？ • どうやって学べばいいの？ IT勉強会プラットフォーム 「Conppass」上で定期開催 https://connpass.com/user/ToyoStar/open/ というような⽅を対象として、クラウド‧AWS を超基本から学べる勉強会を開催しています。
4. 新潟出⾝‧SIer勤務3年⽬のエン ジニアです! 普段はAWS上のAPI‧バッチアプ リケーションの設計や実装を⾏っ ています。 ⼀緒にクラウドについて勉強しま しょう! ⾃⼰紹介 河本 瞬 品⽥ 遵詞 間世⽥ 秀 SIer勤務2年⽬のITエンジニアです 主に基幹システム‧インフラ構築 業務に従事しています。 私⾃⾝も学び続ける⽴場ですが、 皆さんと⼀緒に成⻑していけるよ うな講義を⽬指しています。 Shun Kawamoto Junji Shinada Shu Maseda 某SIer勤務3年⽬のエンジニア。社 内AWSシステムの運⽤を⾏ってい ます。 好きなAWSサービス：AWS Transit Gateway 成⿂になるべく奮闘中。
5. 本⽇のテーマ AWS Kiro
6. IT開発⼿法 Kiro業務活⽤体験談 アジェンダ 1 3 Kiroサービス紹介 2 - ウォータフォールのV字モデル - 従来の⽣成AIを持ちいた開発の課題 - 仕様駆動開発とは - Spec/Vibeモード - Hooks, Steering - 要件定義からアプリ開発
7. IT開発⼿法 Kiro業務活⽤体験談 アジェンダ 1 3 Kiroサービス紹介 2 - ウォータフォールのV字モデル - 従来の⽣成AIを持ちいた開発の課題 - 仕様駆動開発とは - Spec/Vibeモード - Hooks, Steering - 要件定義からアプリ開発
8. IT開発⼿法の全体像 反復思考 アジャイル開発 フェーズ思考 ウォータフォール開発 継続的デリバリ DevOps, CI/CD ⼯程を厳格に分割する。 後戻りしないことを前提で 最初から仕様を作り込む ⼤規模な開発に向く 短いサイクルで開発とリ リースを⾏う。柔軟性とス ピード感のある開発⼿法 変化の激しい領域で有意。 開発（dev）と運⽤（Ops） を統合し、テストやデプロ イを⾃動化してリリース頻度 を⾼める。
9. IT開発⼿法の全体像 反復思考 アジャイル開発 フェーズ思考 ウォータフォール開発 継続的デリバリ DevOps, CI/CD ⼯程を厳格に分割する。 後戻りしないことを前提で 最初から仕様を作り込む ⼤規模な開発に向く 短いサイクルで開発とリ リースを⾏う。柔軟性とス ピード感のある開発⼿法 変化の激しい領域で有意。 開発（dev）と運⽤（Ops） を統合し、テストやデプロ イを⾃動化してリリース頻度 を⾼める。
10. ウォータフォールのV字モデル 開発に必要な工程を段階的に区切って、順番に進行していく。工程ごとに品質を管理できるため、最 終的に高い品質が期待できることが特徴。
11. ウォータフォールのV字モデル 工程 概要 ① 要件定義 システムに求められる機能・性能・制約条件を整理し、関係者間で合意する ② 基本設計 画面や外部インターフェースなど、システムの外部仕様を設計する ③ 詳細設計 プログラム構造やデータ処理方式など、内部仕様を具体化する ④ 実装 設計内容に基づいてソースコードを作成する ⑤ 単体テスト プログラム単位で正しく動作するかを確認する ⑥ 結合テスト 複数のプログラムを連携させ、処理やデータ連携を確認する ⑦ システムテスト システム全体として要件を満たしているかを検証する ⑧ 受入テスト ユーザーが業務観点で確認し、システムを受け入れる ウォーターフォール開発は、「開発手順が極めてシンプルでわかりやすい」手法。 以下の手順を上から順番に実施していく。
12. アジャイル開発との⽐較 アジャイル開発：「ビジネスは変化するもの 」という考えを前提とした開発手法 　　　　　　　　 開発途中の仕様変更に強い 観点 ウォーターフォール開発 アジャイル開発 作業工程 初めに開発内容を全て決め、段階的に詳 細化・開発する 短期間で繰り返し開発を行う 柔軟性 一度決めた開発内容は変更しにくい 開発内容を柔軟に変更しやすい テスト テスト工程ですべて行う 高頻度で行う レビュー 実物確認はプロジェクトの終盤となる 実物をすぐに確認できる 発注者のかか わり方 要件定義工程などで集中的にかかわる 深いコミットメントが求められる
13. ウォータフォール開発は継続して利⽤されている アジャイルが台頭した現在でも、ビジネスとしてのシステム開発 では • 契約・監査・社内統制に耐える正式ドキュメント が必要である。 • メンテナンスや人員交代時の拠り所（要件・設計・テストの鎖）が強く求められる。 • 工程ごとに成果物を整備することを “強制できる ”フローは、リスク管理上の安心感 がある。 このため、ウォータフォール開発は依然有効 であり、実務では多く使われている
14. 生成AI開発の課題 Vibe Coding の中心と限界
15. Vibe cording Vibe Coding （雰囲気コーディング） とは 従来のように開発者がコードの細部まで手書きするの ではなく、AIに自然言語で要件やアイデアを伝え、 AIが その指示に基づいてコードを生成する手法 開発者は、細かい文法や構文を意識せず、設計や意 図、全体の「雰囲気（ vibe）」をAIに伝えることで開発す ることができる メリット 爆発的な初速、試作の容易さ、学習コストの低下
16. 従来のVibe cordingの限界 課題 内容 判断の前提が残らない 「この機能はなぜこの構成なのか？」という問いに答える情報が存在しない。 （開発者との対話そのものが設計プロセスに） 要件が曖昧なまま進行 受け入れ条件が定義されず、完成品が期待に沿っているかを検証できない。 実装とドキュメントの乖離 コードはあるが、設計書や要件定義が存在しない、または古いまま。 設計書が存在しても開発中にどんどん仕様からズレていく。 チームでの保守が困難 開発の意図が属人化し、他メンバーが手を加えることが難しくなる 具体例 「商品ページにレビュー機能を追加して」と指示すれば、それらしい UIとAPIは出力され得る。 しかし仕様の共有がなく、異常系・アクセス制御・監査・性能の検討が薄いままテスト不備でリリースされるリスク がある。 結論：プロダクションレベルでは難度が高い。
17. ウォータフォール開発とVibe Cording 「作業から2週間もたつと、AIに何をさせたのか、人間も AIも分からなくなってしまう」 • Vibe Cording：意図・雰囲気 → AIがコード生成（作りながら考える） • ウォーターフォール：仕様・設計を事前に固定（考えてから作る） ➡ 生成コードの根拠・再現性が弱い
18. ウォータフォール開発とVibe Cording 「作業から2週間もたつと、AIに何をさせたのか、人間も AIも分からなくなってしまう」 • Vibe Cording：意図・雰囲気 → AIがコード生成（作りながら考える） • ウォーターフォール：仕様・設計を事前に固定（考えてから作る） ➡ 生成コードの根拠・再現性が弱い 意図（vibe）を保ったまま、ウォーターフォールが求める“仕様”に落とし込みたい！
19. ウォータフォール開発とVibe Cording 「作業から2週間もたつと、AIに何をさせたのか、人間も AIも分からなくなってしまう」 • Vibe Cording：意図・雰囲気 → AIがコード生成（作りながら考える） • ウォーターフォール：仕様・設計を事前に固定（考えてから作る） ➡ 生成コードの根拠・再現性が弱い 意図（vibe）を保ったまま、ウォーターフォールが求める“仕様”に落とし込みたい！ AWS Kiroの『仕様駆動開発』
20. IT開発⼿法 Kiro業務活⽤体験談 アジェンダ 1 3 Kiroサービス紹介 2 - ウォータフォールのV字モデル - 従来の⽣成AIを持ちいた開発の課題 - 仕様駆動開発とは - Spec/Vibeモード - Hooks, Steering - 要件定義からアプリ開発
21. Kiroとは？ - 仕様駆動開発の実現 AWSが2025年11⽉18⽇に一般提供開始した Visual Studio Codeベースの統合開発環境です。 最大の特徴：仕様駆動開発 従来の「ブラックボックスな AI開発」から 設計プロセスが追跡可能な「透明な開発」へ
22. 現在利⽤可能なモデル 現在、Anthopic社のClaude Modelが利⽤可能です。 • Sonnet 4, 4.5/ Opus 4.5 ◦ 複雑なコーディングや要求の厳しいタスク向け • Haiku 4.5 ◦ ⾼速かつ低コスト / Sonnet 4相当の性能
23. Vibe と Spec - 2つの開発モード
24. Vibe と Spec - 2つの開発モード
25. Steering - プロジェクトの知識を永続化 プロジェクト全体のコーディング規約、パターン、標準を Markdownファイルで定義し、Kiroの動作に組み込みます。 Steeringファイルの例 • product.md ◦ システムを定義し Kiroに目的とビジネスコンテキストを理解させる • tech.md ◦ プロジェクトで使用する技術を定義し Kiroに「どの技術で実装するか」を理解させる • structure.md ◦ ファイル構成と命名規則を定義し Kiroに「どこに何を配置するか」を理解させる
26. Steering - プロジェクトの知識を永続化 Steeringファイルの先頭に読み込みモードを設定できます。 inclusion:alwaysとすることで 毎指⽰実⾏時の最初にプロンプトを読み込ませることができます。
27. Agent Hooks - ワークフローの⾃動化 ファイルの保存‧作成‧削除などのイベントをトリガーに AIエージェントが⾃律的にタスクを実⾏する機能 活用例 • セキュリティスキャン 保存をトリガーに、 APIキー漏洩やパスワードなどを自動チェックさせる • 画像最適化チェック 画像ファイル追加時、サイズが大きすぎないかチェックさせる • ドキュメントの更新 APIを追加したら、自動的に APIドキュメントを更新させる
28. MCP - 外部ツールとの統合 Kiroと外部サービス‧ツールを統合するためのMCP機能も完 MCPサーバ例 • AWS Documentation MCP AWS公式ドキュメントを参照し、最新情報で回答 • Git MCP リポジトリの読み取り、コミット履歴の分析 • PostgreSQL MCP スキーマ分析やクエリの生成
29. MCP - 外部ツールとの統合 Kiroと外部サービス‧ツールを統合するためのMCP機能も完備 MCPサーバ例 • AWS Documentation MCP AWS公式ドキュメントを参照し、最新情報で回答 • Git MCP リポジトリの読み取り、コミット履歴の分析 • PostgreSQL MCP スキーマ分析やクエリの生成
30. チーム開発でどのようにKiroを活⽤するか？
31. プラン体系 プラン 料金 クレジット どのような人向けか？ Free $0 50 Kiroを試してみたい方 Pro $20 1,000 個人開発者 Pro+ $40 2,000 大規模開発 Power $200 10,000 常時Kiroを使用する方 クレジットとはKiro独自の利用体系 • プロンプトの複雑さに応じて小数点単位で消費 • 簡単な編集やプロンプトであれば 1 クレジット未満の消費 • タスクは複雑さに応じて異なる速度でクレジットを消費
32. まとめ
33. IT開発⼿法 Kiro業務活⽤体験談 アジェンダ 1 3 Kiroサービス紹介 2 - ウォータフォールのV字モデル - 従来の⽣成AIを持ちいた開発の課題 - 仕様駆動開発とは - Spec/Vibeモード - Hooks, Steering - 要件定義からアプリ開発
34. デモンストレーションの流れ 要件定義 (requirements.md) 設計 (design.md) 実装 (tasks.md) ‧要件⼊⼒ ‧要件追加 ‧ステアリングファイルの追加 ‧設計開始 ‧⼈からの指摘を追加する”脱バイブコーディング” ‧ステイアリングファイルの追加 ‧ログイン画⾯だけ… の完成イメージをお⾒せ
35. 場⾯設定 ‒ 映画館の予約システム ※主にログインまわりを対象として 以下でシステム要求&要件を作成 ⼩規模映画館の予約システムを作成 ‧映画予約画⾯がある ‧映画スクリーンは1つ ‧席は10列×A列〜J列 ‧システムに⼊る際に会員登録が必要 ‧インフラはAWSに乗せる ‧同時使⽤⼈数は最⼤100⼈ ‧データベースのトランザクションを担保するため、RDBを使⽤
36. 要件定義 ‒ 対象アプリケーションの要件を⼊⼒ Kiroへのインプット Kiroのアウトプット
37. 要件定義 ‒ 対象アプリの要件定義書を確認 Kiroのアウトプット ✔ 要件を広げて言語化してくれる
38. 要件定義 ‒ 要件の追加を⾏う Kiroへのインプット Kiroのアウトプット ✔ 後からの要件追加に対応 ✔ 「要件」が足りていない … ことは人間側で判断することが必要
39. 要件定義 ‒ さらに⾮機能要件を追加 ! OWASPに基づくセキュリティ対策を追加
40. 要件定義 ‒ OWASPに基づく⾮機能要件を追加 https://github.com/ueno1000/secreq/tree/master ✔ アプリケーション層のセキュリティ要件が まとめられている (PDF, Excel形式) ✔ mdに変換を行っておく
41. 要件定義 ‒ ⾮機能要件の追加例として、セキュリティ要件を追加 Kiroへのインプット Kiroのアウトプット ✔ 変換後の OWASP資料をインプットに
42. 設計の前に… ‒ tech.mdを作成して技術的⽅針をKiroに与える Kiroへのインプット Kiroのアウトプット “steering”ファイル作成から進む tech.mdには技術的方針を記載する
43. 設計 ‒ ⼗分に要件を確認した後、設計段階に移⾏ Kiroへのインプット Kiroのアウトプット
44. 設計‒ ⽣成された設計書を確認 Kiroのアウトプット ✔ アプリケーション構成図を mermaid形式で出力
45. 設計 ‒ アプリケーション基盤(共通関数等)の設計を追加依頼する Kiroへのインプット Kiroのアウトプット ✔ デフォルトではバイブに近くなると考えられる ので、ソースの品質を保ちたい場合は 基盤設計をしましょう。
46. 実装 ‒ 設計書をもとに実装タスクに分解 Kiroへのインプット Kiroのアウトプット ✔ tech.mdに記載の技術仕様をうまく反映
47. 実装の前に要件変更 ‒ デザインシステムの導⼊
48. 実装の前に要件変更 ‒ デザインシステムの導⼊ おおむねこのようなデザイン
49. 実装の前に要件変更 ‒ デザインシステムの導⼊ ✔ デザイン庁のシステムはオープンソース化されいている
50. 実装前の要件変更 ‒ 要件の追加に対応 Kiroへのインプット Kiroのアウトプット ✔ 参考となるデザインシステムを git cloneし、 デザイン (Reactコンポーネント )を輸入
51. tips 実装の前に… ‒ コーディング規約について整理し、 hooksでチェック Kiroへのインプット Kiroのアウトプット
52. 実装 ‒ 実装タスクを順に実施 Kiroへのインプット ✔タスクをを順に実施 (セキュリティ対策の一つ、SQLインジェクション対策 をライブラリ使わずに個別実装し始めたので 適宜指摘しつつ…)
53. 実装 ‒ ログイン画⾯の完成イメージ ✔ tasks.mdに沿って実装したログイン画面 ✔ デザインシステムを踏襲していると思われる
54. クロージング
55. クロージング 最後にアンケートにご協力をお願いいたします（所要時間 2分程度） 本日はご参加いただきありがとうございました！！ よければXのフォローもお願いします！ @ToyoStar_cloud