個人開発でKiroを4ヶ月使ってみた感想

こんにちは。
アプリケーションサービス部、DevOps担当の兼安です。

2025年7月にKiroが発表されてから数ヶ月が経過しました。
個人開発で今日までずっと使い続けてみたので、今回は2025年12月上旬時点の感想を一度述べたいと思います。
なお、Kiro autonomous agentとKiro powersには今回は触れませんので、ご了承ください。

Kiroとは
- Kiroの用語
Kiroの仕様駆動開発の感想
成果物が完成するまでに時間がかかりすぎる問題
品質の揺れ問題
スペックのファイルは設計書なのか
【追記】スペックのファイルをKiroではなくKiro CLIに実装してもらうのは有効か
まとめ

Kiroとは

KiroはAWS製のAI機能を備えたIDE（統合開発環境）です。
仕様駆動開発（Spec-Driven Development）の機能を有しており、要件を入力すると要件定義書、設計書、実装計画をファイルとして保存し、その上で実装を行うのが特徴です。

Kiroの用語

感想を述べる前に、本記事の中で出てくるKiroの用語をまとめておきます。
（フックは記事の中で触れてないので省略しました。）

用語	説明
スペック（Spec）	仕様駆動開発（Spec-Driven Development）を実現するための仕組み。 requirements.md、design.md、tasks.mdを作成して実装に入るスタイル。
ステアリング（Steering）	Kiroの動作や振る舞いを制御するプロジェクト固有のルール。コーディング規約などを定義する。
requirements.md	スペックのファイルの一つ。ユーザーが入力した要件を明確化し、受け入れ条件などと合わせてドキュメント化したもの。
design.md	スペックのファイルの一つ。 requirements.mdをもとに詳細な設計をドキュメント化したもの。
tasks.md	スペックのファイルの一つ。 design.mdをもとにした実装計画。

では、早速感想を述べていきます。

Kiroの仕様駆動開発の感想

私は個人開発でKiroを使用しており、そこでは以下のようなステアリング（Kiroに読み込ませるコンテキスト）を用意しています。
このステアリングは、個人開発で私が試行錯誤しているものです。
個人開発ではありますがプロダクト完成を目指してWBSを作っており、WBSのワークパッケージをKiroのスペックの入力として開発を進めています。

このスタイルでKiroの仕様駆動開発を使用した感想としては、一度ファイルが出力されて実装が進むので、単純なバイブコーディングと比較して進捗管理と作業の中断・再開がかなりしやすいです。
私のようなSIerにおけるチーム開発には合っていると思います。
ステアリングの充実度合いにもよるでしょうが、バイブコーディング「だけ」よりは品質の安定化の道が見えると感じています。

一方で大きく分けて2つの課題を感じています。
まず、バイブコーディングに比べると成果物が完成するまでにかなり時間がかかります。
次に、仕様駆動開発と言えどまだまだ品質の揺れに悩まされます。
品質の揺れに対しては今も悩んでおり、何度もステアリングを見直しています。

成果物が完成するまでに時間がかかりすぎる問題

成果物が完成するまでが長いのは、最初はプロセスが重厚だからだと思っていましたが、それだけではないようです。
バイブコーディングと比較して内部の動きがだいぶ違うのかなと感じます。
時間がかかりすぎる故か、tasks.mdに全部チェックが入ってるのに実は課題が残っている時があるのが辛いところです。
これに関しては、対処法として取り急ぎtasks.mdの「Update tasks」をクリックして、tasks.mdを最新化してみる方法があります。

「Update tasks」を行うと、残課題がtasks.mdにフィードバックされるので追加で対応をすることができます。

時間がかかりすぎる問題の本質は、Kiroに入力する要件の粒度が大きいか複雑なのだろうと思っています。
要件の粒度が大きかったり複雑だと、Kiroの処理途中でセッションが切れる・エラーが起きるなどが頻発するようになり、「目が離せない」状態になります。
私はWBSを作ってワークパッケージごとに投入していますが、Kiroとしては粒度が大きかったのでしょう。
とはいえ、正直なところ粒度を小さくしすぎると管理と投入作業が大変なので悩ましいところです。

品質の揺れ問題

Kiroが生成するコードについては、「実装スタイルが統一されてない時がある」・「テストが通らないことがある」と感じていました。
後者については要件の粒度が大きく、当初はテストファーストの指示もあまり入れていなかったので、多数の実装を行った後に最後にまとめてテストコードを書くような挙動をさせてしまったのもあるでしょう。
これについては、ステアリングにテストの方針を詳しく書くなど、その都度「学び」を反映させることである程度の改善が見られています。

Kiroは最初にステアリングを整備すれば、あとは仕様駆動開発を繰り返すだけというある種ウォーターフォール的なイメージを持っていましたが、それだけではダメだという感想を得ています。
いい感じで仕様駆動開発を回すためにはステアリングを育て続けないとダメなのでしょう。

スペックのファイルは設計書なのか

2つの課題を通して、Kiroのスペックに投入する要件は小さい方がいいと思っていますが、そうなってくるとスペックのファイルは設計書なのか？とも思います。
Kiroが実装しやすいことを意識した粒度にすると、それでできるrequirements.mdやdesign.mdは人間が認識しやすい単位なのだろうか？と感じるからです。
私の中ではスペックは仕様駆動開発の部品でしかなく、必ずしも人が読むための「納品物としての設計書」を兼ねる必要はないという気持ちになりつつあります。

【追記】スペックのファイルをKiroではなくKiro CLIに実装してもらうのは有効か

Kiroが実装に時間がかかりすぎる問題に対して、スペックのファイルだけKiroに作ってもらい、実装はKiro CLIにやってもらうことも試してました。
（時期的には、リニューアル前のAmazon Q Developer CLIを使って試した回数の方が多いです。）
結論としては、Kiro CLIの方が実装は速いですがKiroが本来想定していた内容と微妙にずれるようで、最後はKiroにタスク完了チェックをやらせないとスペックとの整合性に難が出るように感じました。
実際、KiroよりもKiro CLIの方がパワフルで速く、Kiroが詰まってしまった課題でも、Kiro CLIなら突破できることは多かったです。
ですが、速いということは何か理由があるのでしょう、完了したように見えてもKiroで改めて実装状況をチェックさせると、漏れや誤りがちょこちょこ見つかります。
仕様駆動開発をするなら、短期的な進捗を意識して捻じ曲げず、できるだけ貫いた方がよい気がしています。