Kiroの評判がよいのをちょくちょく見かけていたので、早いとこ使ってみたかったのですが、今年7月ぐらいからずっとウェイトリストで待たされっぱなしでした。
少し前になりますが、10/18にやっとウェイトリストそのものが終了してpublic preview状態になったのでAIコーディング環境として1か月ほど使い始めたところ、想像以上によかったので、課金も始めました。
参考: ウェイトリストは終了、今日から Kiro を始めましょう | Amazon Web Services ブログ
Amazon の Kiro を試してるけど、品質たけぇ。よぉ出来すぎてて他との差を感じるわ。 pic.twitter.com/sb8miwZcqb
— mattn (@mattn_jp) October 22, 2025
🔗 Kiroとは？
Amazonがリリースしている、AIコーディング専用IDEです。VS Codeをカスタマイズしているのは一目瞭然です。
「AI入りエディタ」という発想は割と前からあり、ClineやCursorと同じような路線ですが、これらは触ったことがありません。
🔗 Kiroの特徴
🔗 1. 特に設計に強い
要件から設計を起こし、設計からタスクリストを起こすという流れが基本です。
.kiro/spec/*の下に、要件・設計・具体的なタスクを生成するのを支援してくれます。あまり欲張らずに、作業やissueごとに3つのファイルを生成するぐらいの粒度がちょうどよさそうです。
以下の記事で紹介したSOWをさらに最適化した感じです
なお、requirement.mdはAIが確実に読み取れるよう、EARSという独自の記法で記述されます。こんなふうにWHENとTHE システム SHALLで書かれています。半端にローカライズされているのが愉快ですね。
#### 受け入れ基準
1. WHEN 仕様書の全機能を調査するとき、THE システム SHALL 各機能の実装状況を「完全実装」「部分実装」「未実装」の3段階で分類する
2. WHEN 実装状況を分析するとき、THE システム SHALL 各機能に対応するソースコードファイルを特定する
3. WHEN テストカバレッジを調査するとき、THE システム SHALL 各機能のテスト実装状況を評価する
4. WHEN 依存関係を分析するとき、THE システム SHALL 機能間の依存関係を明確にする
5. WHEN ドキュメントを調査するとき、THE システム SHALL 実装に関するTODO、FIXME、プレースホルダーを特定する
🔗 2. ルールや制約はステアリング（steering）として置く
他のAIで言うCLAUDE.mdやAGENT.mdに相当します。
このステアリングが強力なのがKiroの特徴です。ステアリングを育てたら他のプロジェクトにも共有すると、いろいろはかどると思います。
ステアリングについては以下の記事でかなり詳しく解説しているので、こちらを先に読んでおくとよいでしょう。
🔗 3. 背後はClaude Sonnet 4や4.5などが使われている
個人の感想ですが、私はClaude Codeに慣れていたので、知っているLLMの方が少し安心感があったりします。
Autoが推奨されていて、場合によっては動的にこれらよりも前のバージョンにひっそりと切り替わっていることもあるようです。
🔗 4. アイコンがかわいい
大事なことです。
意外にもまだ正式な名前がないらしく、中の人たちもGhostとか適当に呼んでいるらしい？
コーディング中にきょろきょろ動いているので、キョロちゃんと勝手に呼んでいます。
🔗 5. 課金
以下は10月時点のpublic previewの状況です。その後クレジット消費率が下げられたそうです。
- 最初の1か月分無料: 500クレジット
- 一日フルに使って50クレジット程度だったので10日は持ちそう: 切れた後で有料プランに乗り換えました
- 有料プラン
- Pro: 20ドル/月（1000クレジット: 20日分ぐらいなので営業日は持ちそう）
- Pro+: 40ドル/月（2000クレジット）
- Power: 200ドル/月（10000クレジット）
クレジットの消費がツールバーで見えるのもありがたいです🙏
🔗 参考: GItHubのspec-kitについて
Kiroの後にGitHubが出したspec-kitは、Kiroと似たようなことをエディタ抜きのCLIベースで、かつマルチLLM対応で行えると教わりました。こちらはまだ試していません。
Kiroはエディタと一体化、spec-kitはCLIに専念という感じで、どちらにするかは好みかもしれません。
🔗 使ってみて
🔗 1. 的確
自作のRailsアプリなどで使ってみた印象として、ideomaticなRailsコードを書かせている限りは、プロンプトで事細かに言葉を尽くして指示しなくても、インテリジェントにコーディングを進めてくれます（もちろんどんなAIであろうと、指示は文脈や主語をなるべく省略せずに的確に書くべきですが）。
少ない指示でどんどん進めてくれますし、勝手にプッシュとかデプロイもしないようです。特にテストコードをがんがん書き進めてくれるのは本当に助かります😂
設計についての相談も的確です。ChatGPTにクロスレビューさせた結果を食べさせてもちゃんとやってくれます。
日本語も問題なく使えます（特に縛りをかけてないせいか、回答は英語になったり日本語になったりしますが）。エディタなので、CLIのように日本語入力で手こずらずに済むのは助かります。
使っていれば、普通にコンテキストが途切れます。しかしtasks.mdが完備していていつでもタスクを再開できるので、tasks.mdベースで作業していれば、コンテキストが切れても別につらくありません。
🔗 2. レスポンスが速い
Claude の少し前のLLMを使っているせいなのか、レスポンスも速いのが特徴です。想像ですが、最新のLLMはアクセスが集中して遅くなりがちなので、あえてそうしているのかもしれません。なお、モデルの選定はAutoが推奨されているだけあって、モデルを手動で選んでも期待通りになるとは限らないようです。
あくまで印象ですが、KiroはLLMの性能にそれほど依存せず、むしろLLMを取り囲むKiroの設計全体で勝利しているように思えます。新しいLLMが出るたびに一喜一憂するより、LLMの性能以外の強みにフォーカスしたいですね。
🔗 Kiroを使うときのコツ
といいつつ、ほとんどはKiroに限らず通用する方法です。
🔗 1. ドキュメントや仕様・セットアップを整備してから開始する
ゼロから開始すると、セットアップや仕様作成のためにKiroのクレジットを消費することになります。
プロジェクトの要件などのドキュメントをできるだけ事前に揃えておき、たとえばRailsだったらrails newと基本的なセットアップ（不要な機能を外すなど）ぐらいは自分でやってから、Kiroに乗せる方がよさそうです。
参考: Ruby on Rails インストールガイド - Railsガイド
なお、Kiroのクレジット消費を減らすために、データ変換などの些細な作業は別のコーディングAIにやってもらったりしています。
🔗 2. フロントエンドの画面は特に慎重に設計しながら進める
これはAIコーディングに限らない話です。
フロントエンドの改修を言葉で的確に指示するのは、そもそもかなり大変です。
- 色合いをどうやって的確に説明するか？
- ボックス同士の間隔やボックスのパディングは、どの画面のどのボックスが対象なのか？
- レスポンシブの振る舞いをどう伝えるか？
- etc.
Kiroといえども、画面の微妙な修正指示は、よほど気を使わないと迷走しがちです。
たとえばRailsのビューなどの画面作りをたったか急ぎすぎると、divなどの構成がこちらの意図通りになっていなくて、その後の改修指示がKiroにうまく伝わらずに何度もやり直すはめになったりします。いわゆるVibeコーディングで起きがちな現象ですね。
特にアプリ構築の初期は、画面の編成やレスポンシブなどの設計を固め、画面更新のたびにその都度確認しながら慎重に進める方が、後になって手戻りを減らせるでしょう。
その意味で、レスポンシブなども含めたアプリの「デザインシステム」を、Kiroの力を借りて早いうちに確立しておくのがよいと思います。言い換えれば、画面改修を言葉やURLで適切に指示できるようにデザインシステムを整備するということです。
デザインシステムについては以下の記事をどうぞ。
🔗 3. ステアリングを育てるつもりで使う
上述したようにステアリングは強力です。
Kiroのステアリングを上手に育てれば、社内の他のプロジェクトと共有する価値が出てきます（他の人もKiroを使うならですが）。
ステアリングのルールや制約を刹那的に設定せず、今後も使えるよう意識しながら育てると後々役に立ちそうです。
🔗 4. chrome-devtools MCPと組み合わせる
私の場合、ベンダー依存の独自コマンドやMCPは極力使わないようにしていますが、chrome-devtoolsを入れておくと、KiroがChromeを起動して操作できるのが便利なので、これだけは使っています。
参考: Server Directory - Docs - Kiro
🔗 Kiroの惜しい点
Kiroは見ての通りVS Codeをカスタマイズしたような作りのIDEですが、そのせいなのか、インストールできないVS Code拡張が結構あります。有名なテーマすら拡張のリストで検索しても出てこなかったりします。
KiroはVSCodeと同じ拡張が使えるわけではなさそう｡WSLエクステンションを検索しても出てこない｡
コマンドプロンプトから kiro \wsl.localhostUbuntuhome みたいにすればWSLの中は開ける｡
TerminalのオプションでWSL内のディストリビューションを選択すれば､ターミナル内にWSL環境が開く｡… https://t.co/WrOgGDmrje pic.twitter.com/CFAgiVTA28— Rev 🏎 (@revsystem) July 14, 2025
あくまで想像ですが、Kiroは機能のバッティングを防ぐためにVS Code拡張のインストールを制限しているのかもしれません🤔
🔗 VS Code拡張を手動でインストールする
Copilotのオートコンプリートなどは以下の方法で無理やりインストールできました。
参考: Cursor や Windsurf や Kiro などでマーケットプレイスにある拡張機能を入れる方法 - 約束の地
しかしVS Codeのdevcontainer拡張は、上の方法でインストールしても動きません。これは痛い🫠
参考: Devcontainers · Issue #164 · kirodotdev/Kiro
最初のうちは、Railsアプリのdevcontainerを動かすだけのためにVS Codeを別途起動するという間抜けなことをやっていましたが、だんだん面倒になってきたので、最終的にRailsアプリをdevcontainer抜きで作り直してしまいました。
もっともDHHはRails World 2025のオープニングキーノートスピーチで「開発環境のDBはDocker化する価値がある（複数バージョンのDBを切り替えやすくなる）が、開発環境のRubyはDocker化せずにネイティブ実行の方がいい」みたいなことを言っていますね↓。Railsフレームワークに具体的に反映されるのかどうかは今のところわかりませんし、Kamalのデプロイは結局全体をDocker化することになりますが。
もちろん、Kiroがまったく迷走しないということではありません。私はコーディングAIが迷走したときは、真っ先に自分の出した指示やドキュメントや現行のコードに誤解を招く何らかの要素が含まれている可能性を考えますが、KiroはClaude Codeよりも迷走しにくいと感じられます（とはいうものの単に自分が以前よりもコーディングAIを使い慣れてきただけなのかもしれないので、なかなか断定的なことは言えませんが）。
たとえば、コーディングが進んだときにerbに冗長なロジックががっつり書かれていたことに気づいたことがありました。これはKiroが生成したコードをレビューした自分が甘かったと即座に反省し、erbのロジックを減らしたうえでバックエンドのコアコードに移動してもらうリファクタリングを行いました。リファクタリングの方針を極力具体的に指示したところ、Kiroはいそいそとそのための要件・設計・タスクを起こし、一発で期待通りにリファクタリングしてくれました。こういうときのKiroの動作は頼もしいですね。