【第1回】Kiro 仕様駆動開発実践入門 — Kiroとspec駆動開発の基本概念をPythonプロジェクトで体験しよう

AIコーディングツールが乱立する中、ちょっと毛色の違うIDEが出てきたので調べてみた。AWSが作った Kiro というやつで、「仕様駆動開発（Spec-Driven Development）」をIDEのコア機能として組み込んでいるのが特徴です。

このシリーズは全4回で、Kiroを使ったspec駆動開発をPythonプロジェクトで実際にやってみることをゴールにしています。今回の第1回は「Kiroってそもそも何者か」と「spec駆動開発の概念整理」をメインに扱います。

第1回（この記事）：Kiroとspec駆動開発の基本概念を整理する
第2回：実際にPythonプロジェクトでspecを書いてみる
第3回：Hooksと自動化の設定をする
第4回：Steering・MCPと連携してチーム開発っぽく使う

この記事でわかること
Kiroって何？ざっくり整理
spec駆動開発（SDD）とは何か
1. requirements.mdの書き方：EARS記法
2. tasks.mdはただのTodoリストじゃない
Steering：エージェントへの「社内ルール」を渡す仕組み
Hooks：「ファイル保存したら自動でテスト書いといて」を実現する
「vibe coding」との違いを自分なりに整理してみた
とりあえずKiroを入れてPythonプロジェクトに向き合うための準備
まとめ

この記事でわかること

Kiroの基本構成と、従来のAI IDEとの違い
仕様駆動開発（SDD）の4段階フロー
Specs、Steering、Hooksの役割とそれぞれの使い方
vibe codingとの違いと使い分け
Pythonプロジェクト導入時のディレクトリ構造

Kiroって何？ざっくり整理

一言でいうと、AWSが作ったエージェント型IDEです。ベースはVS Code（Code OSS）なので、見た目や操作感はだいたいいつもの感じ。でもコア思想が「チャットでコードを書かせる」じゃなくて「仕様書を起点にエージェントが実装まで進める」というところが違う。

Amazon Q Developerの後継として位置づけられており、従来のAI補完ツールとは異なるアプローチを取っています。Q Developerのサポートは2027年4月30日で終了することが発表されています。

Kiroの主な構成要素はこの4つ。

Specs：仕様書ベースの開発フロー（今回の主役）
Steering：エージェントへの永続的な行動指針
Hooks：イベントドリブンな自動化トリガー
Agentic Chat：通常のAIチャット補完

Cursor や GitHub Copilot が「chat-to-code」に注力している一方、KiroはSpec-Drivenアプローチを採用し、実装を始める前に構造化された要件定義とアーキテクチャ設計を求めます。一見遠回りに見えるんですが、これが大きなプロジェクトになると効いてくるという話。

spec駆動開発（SDD）とは何か

Kiroが推す「spec駆動開発」の流れはシンプルです。

何を作るか自然言語で伝える
Kiroが requirements.md を生成する（ユーザーストーリー・受け入れ条件）
人間がレビュー・修正する
Kiroが design.md を生成する（アーキテクチャ・実装方針）
人間がレビュー・修正する
Kiroが tasks.md を生成する（細かいタスクリスト）
タスクを実行してコードが書かれる

この3つのファイル（requirements.md、design.md、tasks.md）は .kiro/specs/ 以下に格納されます。Gitで管理できるので、「なぜこの実装になったか」が仕様書レベルから追えるのが地味に便利なポイントです。

ちなみにspecにはFeature Spec（新機能）とBugfix Spec（バグ修正）の2種類があります。バグ修正では requirements.md の代わりに bugfix.md が使われます。バグ修正専用ファイルが用意されているのはちょっと気が利いている。

requirements.mdの書き方：EARS記法

requirements.mdはEARS（Easy Approach to Requirements Syntax）記法を採用しており、「WHEN [条件/イベント] THE SYSTEM SHALL [期待される動作]」のようなパターンで要件を記述します。

## Requirements

### Functional Requirements

1. WHEN ユーザーがAPIエンドポイントにリクエストを送ると
   THE SYSTEM SHALL レスポンスを200ms以内に返す

2. WHEN 入力値が不正なとき
   THE SYSTEM SHALL エラーメッセージをJSONで返す

3. WHEN 認証トークンが期限切れのとき
   THE SYSTEM SHALL 401ステータスとともに再認証を促す

最初は「こんな形式で書かなきゃいけないの？」と思いましたが、Kiroが自動生成してくれるので手で書くことはほぼないです。ただ、自動生成された内容をきちんとレビューする目は必要になります。

tasks.mdはただのTodoリストじゃない

tasks.mdが面白いのは、タスク間の依存関係をKiroが解析して、独立したタスクを並列実行してくれるところです。「Run all Tasks」を押すと、依存関係のないタスクを並行して実行するため、大半のfeature specで実装時間が大幅に短縮されます。タスクの実行状況もリアルタイムで更新されるので、長い処理を放置しておける。これはちょっと便利そう。

Steering：エージェントへの「社内ルール」を渡す仕組み

Steering filesというのは、エージェントが常に参照するコンテキストを定義したMarkdownファイルです。プロジェクトの規約・アーキテクチャ方針・チームの流儀をここに書いておくことで、毎回同じことをプロンプトに書かなくてよくなる。

.kiro/steering/ 以下に置いて、フロントマターでロードタイミングを制御できます。

---
title: Python Project Standards
inclusion: always
---

# コーディング規約

- Python 3.12以上を使うこと
- 型ヒントは必ずつける
- ログは structlog で出力する
- テストは pytest を使い、カバレッジ80%以上を維持する
- AWS SDK は boto3 を使う（botocore直接叩かない）

Steeringファイルのinclusionモードは always（常時読み込み）、auto（自動判定）、manual（明示的に呼ぶとき）といったオプションが用意されています。特定のファイル編集時に特定のSteeringを読み込む「File Match」のような仕組みもあり、コンテキストを効率的に使えます。

グローバルなSteeringファイルには「常にTypeScript strict modeを使う」「AWS CDKをCloudFormationより優先する」「すべてのLambda関数には構造化ログとcorrelation IDを付ける」といった内容を書いておく使い方が一般的です。

AGENTS.md形式もそのまま読み込めるので、Claude CodeやCursorで使っているコンテキストファイルをある程度流用できる可能性もあります。

Hooks：「ファイル保存したら自動でテスト書いといて」を実現する

Hooksは、IDEでイベントが発生したとき（ファイルの保存・作成・削除、ツールの実行前後、specタスクの前後など）にあらかじめ定義されたアクションを実行するトリガーです。例えば：

Pythonファイルを保存したら → 対応するテストファイルを更新する
specのタスクが完了したら → ドキュメントを自動生成する
ファイルを削除したら → 関連するimport文を整理する

設定できるイベントの種類は大きく分けてこのあたりです。

File events：PostFileCreate のように “Pre/Post + 対象” 形式のイベント（例：ファイル作成後）
Prompt/Agent events：preToolUse / postToolUse など
Spec Task events：specタスクの前後

Macなら Cmd + Shift + P でコマンドパレットを開き「Kiro: Open Kiro Hook UI」と入力すると設定画面が開きます。JSONファイルとして直接書くこともできます。

正直このHooks機能がKiroの中で一番「おっ」と思った部分で、これをうまく使えるかどうかで生産性がかなり変わりそう。

「vibe coding」との違いを自分なりに整理してみた

最近よく聞く「vibe coding」は、ざっくり言うと「気分でプロンプトを投げてコードを生成し続ける」スタイル。小さなスクリプトや試作品ならそれで全然いいんですが、ある程度の規模になってくるとコードが発散しがちで、後から「なんでこうなってるの？」が追えなくなる問題がある。

spec駆動開発の主な違いは、spec-drivenワークフローがSteeringと要件を常に最新の状態に保ち、コンテキストを維持し続ける点にあります。これによってプロセスがはるかに予測可能になり、チームでの協業もしやすくなります。仕様書をアプリケーションコードと同じリポジトリでバージョン管理することで、変更のトラッキングも容易になります。

ただ、小規模スクリプトや実験的なコードには明らかにオーバーヘッドが大きいです。KiroはSDD（Spec-Driven Development）を全作業に強制しているわけではなく、specを作成せずに通常のAI IDEとして（チャットやインライン補完として）使うことも可能です。ここは柔軟に使い分ける感じでよさそう。

とりあえずKiroを入れてPythonプロジェクトに向き合うための準備

kiro.devからダウンロードして、インストール自体はVS Codeに慣れていれば詰まることはないはずです（Mac, Windows, Linux対応）。コマンドラインから使いたい場合は kiro . でプロジェクトを開けます。

プロジェクトに導入するとこういうディレクトリ構造になります。

my-python-project/
├── .kiro/
│   ├── steering/
│   │   └── python-standards.md   # コーディング規約など
│   ├── specs/
│   │   └── feature-name/
│   │       ├── requirements.md
│   │       ├── design.md
│   │       └── tasks.md
│   └── hooks/
│       └── test-updater.json
├── src/
│   └── main.py
└── tests/
    └── test_main.py

.kiro/ ディレクトリごとGitに含めるのが推奨されます。仕様書もコードと同じリポジトリで管理する形になります。