最近ずっと気になってたKiroをようやく触れたので、まとめておきます。
Vibe Codingはもう当たり前になってきたけど、「とりあえずAIに投げてみたら動いたけど何が起きてるか全然わからん」みたいな経験、わりとある。自分もClaude APIやCursorで似たような状況になったことが何度かあって、それが微妙にずっと引っかかってた。KiroはそこにアプローチしてるIDEらしいので試してみることにした。
この記事でわかること
- Kiroとは何か・何が他のAI IDEと違うのか
- インストールと初期設定の流れ
- 仕様駆動開発（SDD）の実際の動き方
- Spec / Hook / Steering / Powersの使い分けイメージ
- Pythonプロジェクトで試したときの所感
Kiroとは何か
KiroはAWSから発表されたAgentic IDEで、「仕様駆動開発」を支援するツールです。見た目はほぼVS Codeで、拡張機能もある程度引き継ぎができるようです。でも中身の思想が全然違う。
一言でいうと、「AIにいきなりコードを書かせない」ことを設計の軸に置いたIDEです。
一般的なVibe Codingでアプリケーションを構築する場合、プロンプトを都度与えることで所望するアプリを作ることはできますが、最終的に構築されたアプリケーションの詳細が把握できなくなることがあります。そのような課題を解決するために、AIエージェントがただコーディングを行うのではなく、開発者の与えたプロンプトから要件定義・設計・タスクの実装を行った後でコーディングを行います。
2025年11月17日に一般提供（GA）を開始しました。re:Invent 2025でも目立っていたらしく、Kiroハウスという展示ブースまであったとか。正直最初は「またAWSが新しいの出したか」くらいの温度感だったけど、使ってみると考え方がわりと面白かった。
インストールと初期設定
kiro.dev/downloads/ からインストーラーをダウンロードでき、macOS・Windows・Linuxに対応しています。
Mac（Apple Silicon）の場合は .dmg をダウンロードして普通にインストールするだけ。数分で終わる。
ログイン方法はいくつか選択肢がある：
- Googleアカウント
- GitHubアカウント
- AWS Builder ID（個人用）
- AWS IAM Identity Center（企業用）
個人で試すなら GitHub か Builder ID が楽。AWSアカウントがなくても使えるのは地味にありがたい。
VS Codeから設定を引き継ぐ「Import from VS Code」オプションがあって、これを使うとテーマや一部設定をそのまま持ってこれる。ただVS Codeの公式マーケットプレイスにしか存在しない拡張機能は自動移行されない場合があるので、そのへんは手動で確認が必要。Cursorから乗り換えようとしてた人は注意。
料金プランについて
KiroはFree〜Powerの4プラン（Free/Pro/Pro+/Power）を提供しています。
Freeプランで月50クレジットまで利用可能で、初回サインアップ時には500ボーナスクレジット（30日間有効）が付与されるとされています。まず試してみるだけなら十分な量なので、とりあえずFreeで始めるのがおすすめ。
クレジットの消費はタスクの複雑さによって変わる。シンプルなチャットなら1クレジット未満、Specタスクの実行みたいな重い処理だと1クレジット以上かかるらしい。使い方によっては思ったより減るのが早い。
仕様駆動開発（SDD）の流れ
Kiroの一番の特徴がこれ。仕様駆動開発はKiroのコアキラーフィーチャーで、自然言語の指示から3段階のプロセスを経てコードを生成します。
具体的には次の3ファイルが自動生成される：
- requirements.md ― ユーザーストーリーと受け入れ基準（EARS記法）
- design.md ― 技術アーキテクチャ・シーケンス図・実装方針
- tasks.md ― チェックリスト形式の実装タスク一覧
各フェーズの間に人間のレビューゲートが入ります。AIが暴走してコードを量産するのではなく、エンジニアが仕様を確認・修正してから次のフェーズに進む仕組みです。これが普通のVibe Codingと根本的に違うところ。
実際にPythonプロジェクトで試す
今回は「Pythonで天気情報を取得してターミナルに表示するCLIツール」を作るシナリオで試してみた。
Specモードで以下のようなプロンプトを入れる：
外部の天気APIを使って、都市名を引数で渡すと
現在の気温・天気・風速をターミナルに表示するPython CLIツールを作ってください。
エラーハンドリングも含めてください。しばらくすると requirements.md が生成される。こんな感じの内容になる：
# Requirements
## User Stories
- WHEN ユーザーが都市名を引数として渡した場合
THE SYSTEM SHALL 外部APIから現在の気象データを取得する
- WHEN APIリクエストが成功した場合
THE SYSTEM SHALL 気温・天気・風速をフォーマットして表示する
- WHEN 不正な都市名または接続エラーが発生した場合
THE SYSTEM SHALL 分かりやすいエラーメッセージを表示する
これがEARS（Easy Approach to Requirements Syntax）記法。「〜の場合、システムは〜する」という構造で要件を書くやつ。自然言語のプロンプトをEARS記法のユーザーストーリーと受け入れ条件に自動変換し、「何を作りたいか」を構造化された要件として残せます。
内容を確認して「Move to design phase」をクリックすると、次に design.md が生成される。アーキテクチャの概要やどのライブラリを使うか、データフローなどが書かれてくる。
さらに「Move to implementation phase」を押すと tasks.md が出てきて、実装をタスク単位に分解してくれる。あとはそのタスクを上から順番に「Start task」で実行していく感じ。
実装フェーズにおいて、実行環境にpipコマンドが見つからないエラーが発生した際、Kiroが自律的にpython -m pipへの切り替えを提案・実行し、ユーザーの介入なしにトラブルシューティングを完遂したという事例もあるようで、環境依存のエラーもある程度自分でさばいてくれるっぽいです。実際に試してみて、ここは「たしかに」と思った部分。
Spec以外の3つの機能
Kiroの中核は「Spec」「Hook」「Steering」「Powers」の4レイヤーで構成されています。
Steering（ステアリング）
Steeringは、.kiro/steeringディレクトリにドキュメントを置くことで、プロジェクト固有のルールやコーディング規約をAIに永続的に記憶させることができます。これによりプロジェクト全体で一貫したコーディングを維持しやすくなります。
Kiroの画面では「AGENT STEERING」という欄があり、product（プロダクト機能に関するルール）、structure（ディレクトリ構造など）、tech（技術スタックやライブラリ）の3つの観点でルールや標準を定義できるようです。
Pythonプロジェクトで使うなら、こういうのをSteeringに書いておくと良さそう：
# tech.md（Steeringファイルの例）
## 技術スタック
- 言語: Python 3.12
- パッケージ管理: uv
- フォーマッター: ruff
- テスト: pytest
## コーディング規約
- 型ヒントを必ず付ける
- 関数は単一責任の原則に従う
- エラーは例外クラスを定義して使う
これを最初に定義しておくことで、AIが毎回「どのライブラリ使えばいいですか？」と聞いてくる手間が省ける。地味に効く。
Hook（フック）
Hookは、IDE内のイベントでテスト生成やリント等を自動実行する機能です。例えば「ファイルを保存したら自動でpytestを走らせる」「新しいファイルを作ったらdocstringのテンプレを追加する」みたいな自動化ができる。
GitHub Actionsの on: push みたいな発想に近い。IDE内のアクションをトリガーにしてAIエージェントに作業をさせる感じです。GitHub Actionsを書き始めたときも同じ「イベント→アクション」の考え方でなんとか理解できたので、そのアナロジーで捉えると入りやすいかもしれません。
Powers（パワーズ）
PowersはMCP（Model Context Protocol）拡張にあたる機能で、外部ツールやサービスとの連携を担います。MCP対応はKiroの注目ポイントのひとつで、AWS系サービスとの連携が得意なのはやはりAWSが作ってるからというところ。
使ってみた正直な感想
良かったところ：
- 「なんで今こんなコードになってるのか」がmdファイルを見ればわかる
- 途中でコンテキストが飛んでも、仕様書があるので再開しやすい
- Pythonでのエラー対処が思ったより自律的
微妙だったところ：
- Specを丁寧に作ろうとすると、最初の要件定義で時間がかかる
- デフォルトの応答が英語なので、Steeringで日本語化の指示を入れる必要がある
- まだCursorに比べると補完の速度感が違う
Kiroの仕様駆動開発を実践したら、結果的にバイブコーディングになったという話もあって、正直笑った。仕様を作る段階でエンジニア側のドメイン知識や設計センスが問われるので、「Kiroを使えばなんでも解決」ではない。仕様書の質 = アウトプットの質、という関係は変わらない。
仕様駆動開発（SDD）で「正しいものを正しく作る」には、AIにいきなりコードを書かせず、要件→設計→タスクの3フェーズで仕様を固めてから実装するKiro独自のアプローチが必要です。この「正しいものを」の部分は人間がちゃんと考えないといけない。AIはあくまで「正しく作る」を担ってくれる。
Cursorとどう使い分けるか
自分はCursorをメインで使ってきたので、どっちを使えばいいか少し悩んだ。今の段階での個人的な整理：
- Kiro向き：新規プロジェクト、設計から詰めたいとき、チームで仕様を共有したいとき
- Cursor向き：既存コードの修正・リファクタ、小さい機能追加、とにかく速く動かしたいとき
どっちかに絞るより、フェーズで使い分けるのが現実的かなと思っている。Kiroで仕様を固めて、細かい実装はCursorで、みたいな運用も全然ありな気がする。
まとめ
Kiroはまだ自分自身も使い始めたばかりで、「これが正解」とは言えないけど、少なくとも仕様駆動という考え方はAI開発においてわりと重要な視点だと感じた。プロンプトを投げるだけでなく、設計の文脈をちゃんと持ちながら開発できる環境というのは、長期のプロジェクトほど効いてくる気がする。
次は実際にLambdaと組み合わせたプロジェクトで使ってみたい。
参考になったらクリックしてもらえると嬉しいです!
