はじめに

re:Invent 2025で、KiroのSpec-driven development（仕様駆動開発）を実践するCode talkセッションに参加しました。
観客からアイデアを募集してその場でアプリケーションを構築する、インタラクティブな形式で、エンタープライズ環境での使い方やJIRA連携など、実務に必要な詳細が議論されました。

今年のre:Inventではkiroを用いたCode talkが開催されました。筆者もこれが2件目のKiro Code talkでした。

ライブコーディングデモ

Kiroが解決する3つの課題

生成AIツールは進化してきましたが、実際には以下の課題がある、と語られました。

1. スケールの問題: 120万行のコード、150人の開発チームで、LLMが一貫した結果を出せるか？非決定性により、開発者ごとに異なる実装になる可能性
2. コントロールの問題: プロンプトで詳細を指定しない部分をLLMが勝手に決定。1000行のコードを書いた後で、想定と違うことに気づく
3. 品質の問題: 上記2つが、コード品質を低下させ、チーム内で一貫性がなくなる

Kiroの解決策は、ソフトウェア開発の第一原理に立ち返ること。要件定義→設計→プロジェクト計画→実装という従来のプロセスを生成AIに適用する、というものでした。

Spec-driven developmentの流れ:
プロンプト入力 → 要件ドキュメント生成 → 設計ドキュメント生成 → タスクリスト生成 → レビュー・修正 → 実装開始

これにより、大規模チームでも同じコンテキストで同じ結果を得られます。

Spec-driven developmentの実践デモ

フィットネスアプリを作成するデモが行われました。
最初にkiroに依頼するプロンプトは端的な1文の要件で始まりました。技術スタックや認証の有無などはSpec modeでは段階的に詳細化される、という話でした。

要件ドキュメント（requirements.md）の生成:

• 1文のプロンプトから、イントロダクション、用語集、7つのUser Storyと受け入れ基準を生成
• EARS形式（業界標準）に従い、人間が読める形式で記述
• この段階で開発者がレビュー・修正可能（デモでは「location」フィールドを追加）

設計ドキュメント（design.md）の生成:

• 技術スタック（React + TypeScript、Tailwind CSS）、データモデル、アーキテクチャを定義
• デモ中に音声文字起こしとAI分析機能が欠けていることに気づき追加
• 重要: Kiroは設計ドキュメントだけでなく、要件ドキュメントも自動更新（整合性を保つため）

タスクリスト（tasks.md）の生成:

• 18タスクを生成、MVP用とプロダクション用を区別（テストやドキュメントはオプション）
• 各タスクに進捗追跡とトレーサビリティを提供
• デモでは「スケートボード→自転車→車」のアプローチで段階的に構築

Agent Hooksによるエンタープライズ統合

Agent Hooksとは:
特定のイベント（File Save、File Createなど）発生時に自動実行されるイベント駆動型プロンプト。

JIRA統合の実装例:
多くの組織ではJIRAでUser Storyを管理しています。Kiroとの間でデータのズレを防ぐため、双方向の自動同期を実装：

1. JIRA → Kiro: JIRA MCP Serverで情報を取得し、Specを生成
2. Kiro → JIRA: Agent Hookでrequirements.mdの変更を自動的にJIRAに反映

これにより、複数の真実のソース（source of truth）を作らず、データを同期できます。Confluence、SharePoint、ローカライゼーションなどにも応用可能です。

聴講者からの質問と回答

Q1: Agent Steeringとは

質問:
Agent Steeringとは何か？

回答:
「Generate steering documents」を実行すると、既存コードベースから3つのファイルを自動生成：

1. Product.md: コードの自然言語サマリー（80万行のプロジェクトが何をしているか理解可能）
2. Tech.md: 技術スタック、エラーハンドリング戦略、テスト戦略、コマンド類
3. Roadmap.md: ディレクトリ構造、主要クラス・モジュール、Blast Radius（変更の影響範囲）

これらは.kiro/ディレクトリに保存され、チーム全体で共有されます。コンテキストウィンドウがいっぱいになっても、マークダウンファイルベースで再開可能です。

Q2: 決定性について

質問:
このプロセスはどれくらい決定的（deterministic）か？

回答:
LLMは非決定的ですが、より多くのコンテキストを提供することで一貫性を高められます。

• 「Webアプリを作って」×5回 → React、Python、Rails...（バラバラ）
• 「Reactアプリを作って」×5回 → すべてReact（一貫性↑）

Spec-driven developmentでは、要件・設計・タスク・Steeringファイルで詳細なコンテキストを提供し、チーム全体で共有するため、大幅に改善されます。

重要な補足: 実際のコード実装は毎回異なる可能性がありますが、要件は一貫しています。コードの詳細よりも、ビジネス要件と受け入れ基準に焦点を当てることが重要です。

Q3: Kiroの信頼性

質問:
Kiroはどれくらい信頼できるか？

回答:
ソースコードの理解は優秀で、エラーが発生しても自己修正能力を持ちます。

デモでの例：create-viteコマンドでエラー → 別の方法を試行 → それもエラー → 手動でファイル生成。LLMは本質的に「役に立ちたい」という性質があり、1つの戦略が失敗すると別の戦略を試します。開発者はいつでも介入・一時停止・再開が可能です。

Q4: 要件変更への対応

質問:
既にタスク実装後、要件ドキュメントを変更する必要がある場合は？

回答:
2つの方法があります：

1. プロンプトで指示: 「赤から青に変更」と指示すれば、Kiroが変更を適用
2. 手動編集 + Refineボタン: requirements.mdを直接編集後、「Refine」をクリック

Refineボタンは、要件の整合性チェック、設計への波及、タスクへの反映を自動で行います。下流への変更が自動的にトレースされます。

Q5: Specの定義と範囲

質問:
1つのSpecに何を含めるべきか？ベストプラクティスは？

回答:
Bounded Feature（境界のある機能）として扱うのが基本です。

• 未完了のSpec: 同じSpecに追加・修正OK
• 完了したSpec: 新しい変更や機能は新しいSpecを作成

補足:

• アートであり、サイエンスではない
• 明確な完了基準（Definition of Done）を持つ
• 長期間続くものではなく、期限付き
• 大きさの目安: フィボナッチ数で21以下が推奨

まとめ

観客参加型のデモで、Spec-driven developmentの実践的な使い方が示されました。要件→設計→タスク→実装の正しいプロセスを生成AIに適用し、Steering documentsで大規模コードベースの理解を共有、Agent Hooksでエンタープライズツールとの統合を実現しています。

特に印象的だったのは、「LLMは非決定的だが、適切なコンテキストを提供することで一貫性を高める」という点と、「コード実装の詳細よりも、ビジネス要件の一貫性が重要」という考え方でした。

以上でした！