Kiroの革新性とユースケース

 Kiroの革新性と ユースケース スペック駆動開発で「作り方」を言語化し、 プロトタイプから本番へ  10 min Presentation |  2025.12.23

AWS New Service Kiroとは？ AIネイティブIDE 従来の「コード補完」を超え、仕様策 定から実装までをAIが並走する、次世 代の開発環境です。   AWS発のAgentic IDE  VS Codeベース ＋ 互換性  中核機能: Spec & Hook  高度な生成能力  主なユースケース AIエージェントが「仕様・設計・実装」の全工程を並走し、開発者を強力に支援。 VS Codeをフォーク。既存の拡張機能や設定、プロジェクト資産をそのまま活用可能。 「Spec」で仕様を定義し、「Hook」で自動化タスクを実行。品質とスピードを両立。 チャットやエージェントが、コードだけでなくドキュメントやテストコードも生成。 新機能の爆速開発、大規模なリファクタリング、チームの品質ゲート整備に最適。

DEVELOPMENT MODES スペック駆動開発の全体像（Vibe vs Spec）  Vibe Coding  対話形式で直感的に開発を進めるスタイル 対話で素早くアイデアを試作・探索できる 実装の自由度が高く、プロトタイピングに最適 仕様書を経ないため、要件の追跡・再現性は弱め  RECOMMENDED  Spec モード 仕様を定義し、計画的に実装を進めるスタイル 「要件→設計→タスク」を文書化し、AIと合意 実装コードが要件に紐づき、監査・変更に強い チーム開発や本番環境への移行に適している Tips: 開発フェーズの途中でも、必要に応じて Vibe ⇄ Spec のモード切り替えが可能です。 

Specワークフローの全体像 自然言語のアイデアから実行可能なタスクまで、一貫したデータの流れ  要件定義 1  Requirements Phase requirements.md 「何を作るか」を定義 ユーザーストーリー 受け入れ基準 (EARS記法) 完了条件の明確化  Automated by Hooks 設計 2  Design Phase design.md  「どう作るか」を定義 技術アーキテクチャ データモデル / API仕様 シーケンス図 / フロー図 タスク化 Implementation Phase tasks.md  ドキュメントの変更を検知し、タスクの進捗、差分、テストケースを自動的に同期・更新。 「仕様と実装の乖離」を防ぎ、常に最新の状態を保つ仕組み。 「具体的手順」へ分解 実装順序と依存関係 テスト実装要件 UI/UX詳細仕様 3

 REPORT 体験レポート 使ってみてわかったこと 開発初心者が挑む スペック駆動開発の実践 開発経験の浅い初心者の私が、話題のAI IDE「Kiro」のSpecモードに挑戦。 AIに主導権を持たせる開発スタイルが、スキル不足をどう補うかを検証。  Specモードを中心とした検証記録 テーマ (Theme) 「ユーザーの要望に応じておすすめのグルメを紹介するアプリ」 要件定義書(requirements)から設計(design)、タスク計画(tasks)を生成し、実装 まで完走を目指す。   背景 (Context) 観点 (Perspective) ● 典型的な開発フローの追体験としての学び ● エラー時のAIサポート精度と、人間側に求められる知識

01  要件定義書の自動生成  明確な完了条件（受け入れ基準）  設計とタスクの連鎖的な生成  開発フローと用語の習得 LEARNINGS 開発の型を 実体験 開発初心者がKiroの「Specモード」を 通じて体験した、典型的な開発プロセ スの学び。  プロンプトからrequirements.mdを生成することで、曖昧なアイデアが構造化され、プ ロジェクトの全体像が一気に掴みやすくなった。 ユーザーストーリーごとに受け入れ基準 (Acceptance Criteria) が定義されるため、「何を もって完了とするか」がブレずに開発を進められた。 要件定義をベースに設計書 (design.md) と 実行タスク計画 (tasks.md) が生成される、 「整合性の取れたドキュメントリレー」を体験できた。 初心者にはハードルの高い「要件定義→設計→実装」という典型的な開発フローをAI先導 で追体験でき、開発用語やプロセスへの理解が深まった。

02学び②: つまずきと乗り越え方  Challenges   Solutions  つまずきポイント  Kiroでの解決策  環境構築のエラー  チャットへのログ丸投げ  実行ディレクトリのミス  高いLLM精度と解説力 Node.jsパッケージのインストール周りで依存関係のエラーが発 生。初心者にはエラーログの解読が困難。 カレントディレクトリの設定ミス（ cwd ）により、生成されたス クリプトが正しく動作しないケースがあった。   Kiroチャットにエラーログをそのまま提示するだけで、原因の切り 分けと修正コマンドを即座に提示してくれる。 単なる修正だけでなく「なぜエラーが起きたか」を丁寧に解説して くれるため、学習効果が高い。 PRACTICAL TIPS  エラー時は自分であれこれ悩まず、「実行コマンド」と「エラーメッセージ」をセットでチャットに貼るのが最短ルート。 また、プロジェクトルートとスクリプト実行場所の不一致はAI開発あるあるなので、最初にディレクトリ構造を伝えておくとスムーズ。 

03 RAG非搭載から見えた示唆 LEARNINGS AI開発におけるドメイン知識の重要性  OBSERVATION (観察) 情報の鮮度と専門性の欠如  要件を「グルメアプリ」としたが、RAG（外部知識検索）が構成に含 まれていなかったため、AIは学習済みデータのみに依存。結果、実在 しない店や古い情報が出力される可能性が残った。 CORE INSIGHT AI開発であっても、 専門知識と仕様の解像度が 最終的な精度を決定する。 「いい感じにグルメをおすすめして」という抽象的な指示だ けでは限界がある。AIに適切な文脈（コンテキスト）を与え るのは、やはり人間の役割である。  RECOMMENDATION (代替案・提言) 仕様書にこそ「知識」を込める 外部データの明示: 「Google Places APIを使用する」「独自の店舗DBを参照 する」等を要件に記述する。  専門用語の定義: 「評価指標」 「フィルタリング条件」など、ドメイン固有 のロジックを言語化して渡す。  段階的実装: まずはモックデータで構造を作り、後からRAGを組み込む戦略 をとる。 

まとめ と 次のステップ Kiroの「Specモード」で、AI開発のプロセスを進化させる  今日の要点    KiroはSpecとHookで「作る前に決 める」を仕組み化する次世代IDE 要件→設計→タスクがリンクするこ とで、開発の手戻りを防ぎ品質を確 保 初心者でも典型的な開発プロセスを AIと並走しながら実践可能  次の一歩    まずは自分の小さな機能（1画面程 度）でSpecモードを試してみる 必要なデータソースや専門用語を事 前に洗い出し、要件定義に反映させ る 依存関係やREADMEを整え、実行可 能な環境を準備する  Call to Action まずは今週、  1スプリント分の機能を Kiroだけで 完走してみませんか？ #builtwithkiro でシェアして 知見を共有しましょう