開発技術部の柴田です。 皆さんはKiroを使っていますか？
私はパブリックプレビュー初期から登録していましたが、本格的に使い始めたのは2025年9月になってからです。 そこから約1か月、試行錯誤しながら開発を進めてみた結果、「Kiroとどう付き合えば開発がうまく進むのか」が少し見えてきました。
本記事では、その経験をもとに初心者向けのノウハウを紹介します。
- ※ 本記事の内容は2025年9月〜2025年10月時点のKiroを元にしています。機能・料金体系は変更される可能性があります。
- ※ 筆者はAIアシスト開発を常に行っているわけではないためアンチパターンが含まれている可能性もあります。
Well-Architected Review支援チャットを作ってみた
題材に選んだのは「Well-Architected Reviewを支援してくれるAIチャットシステム」です。 どこまでKiroで実現できるか未知数だったため、PoCとして仕様は最初から盛り気味にしました。
- 指定ドキュメントからLLMがWell-Architected Reviewを実行し、改善案などをチャットで提案する
- 音声による双方向ストリーミングチャットに対応する
- Amazon BedrockとローカルLLMの切替機能があり
本記事の執筆時点ではすべてが完成したわけではありませんが、開発の途中で得られた気づきがいくつかありましたので、その中から特に役立ちそうな点を紹介します。
あいまいな仕様はコストの無駄
最初は「こんな感じのものが作れたらいいな」という曖昧な状態でKiroに依頼していました。 その結果、一気にVibeクレジット*1が消費されました。
KiroがSPECを作ったあと、タスク実装を進める中で「それは自分の意図と違う」というやり直しが何度も発生し曖昧な依頼＝クレジット消費の元凶であることを痛感しました。
KiroとSPECを決める段階で、ある程度Kiroからプロジェクトの構造や使用する言語などの提案もありますが、コーディング規約などにイメージしている物があるのであれば、自分でしっかりと伝えるのが重要です。
SPECに最低限書くべき内容
- 使用するフレームワーク・言語バージョン
- ディレクトリ構造（src/tests/libなど）
- コーディング規約
- テスト方針（カバレッジ基準・利用ライブラリなど）
普段の仕事であれば暗黙の了解で済む部分でも、Kiroには明記が必須です。 これらは他プロジェクトでも共通化しやすいため、組織でテンプレート化しておくのが良さそうです。
Kiroに任せたタスクが大きすぎてレビュー不能に
タスク分割もKiro任せにしていたところ、1タスクで生成されるファイルが多すぎてレビューしきれませんでした。 私はプログラミングは専門ではないこともあり、以下のルールを導入して一旦レビュー方針を割り切りました。
- テストコードの作成を必須にする
- テストカバレッジ80%以上で合格と判断する
- Steeringに
test-requirements.mdを用意して方針を明文化する task.mdの各タスクにも「必須テスト内容」を明記する
このルールを適用してからは、「必要なテストが書けているか」「カバレッジに問題がなさそうか」だけの確認で進められるようになりました。 今回は試しませんでしたが、テストの必須化はSPEC側で設定するのではなく、フック側で対応も可能だと思います。
SPECは分けるのが良い
ローカル部分の機能がある程度完成していたにも関わらず、UIだけがずっと改善されないという状況に陥りました。 そこでKiroとチャットしたところ、UI開発用に別のSPECが作成されました。
これは私にとって大きな気づきでした。 最初から仕様を盛り込んでいたためSPEC内の情報量が多く、Kiroがコンテクストを正しく把握できているのか疑問に感じることもありました。 SPECを分割することで、コンテクストを圧縮しつつ品質を維持できる可能性を感じました。
SPEC分割のメリット
- UIやAPIなど責務ごとに小さく開発できる
- 既存コードを参照できるので前の作業と矛盾しない
- 1リポジトリで複数SPECを並行開発できる
- 人間にとっても気にするべき情報が少なくなり負荷が低い
最初からこの発想を持っていれば、より効率よく進められたと思います。
SVGでUIを書かせると、仕様認識のズレを発見できる
UIの仕様策定では、SVG形式で画面構成を出力させる方法が非常に有効でした。
- 簡易なプロトタイピングとして使える
- 仕様と自分のイメージのズレが視覚的に確認できる
- テキストベースよりも誤解が減る
さらに、作成したSVGを design.md にリンクし、「実装したUIがSVG通りか」をテストで確認させることで、ある程度の実装時のズレも早期に発見できました。
ただし、ここは正直まだまだ見た目を合わせるということは難しく、SVGに合わせて修正しましたと言いながら全然見た目が違うこともあります。
この部分はもう少し実験が必要だと感じています。
今回はKiro主導でSVGを作成しましたが、実際のプロダクト開発では人間が作成したデザインから、SPECを作成させるといった応用ができると思います。
不要ファイルや中間生成物への対処
テスト準拠を徹底すると、以下のような不要ファイルが発生しました。
- テスト内容や結果のレポートファイル
- テストをまとめて実行するための専用スクリプトなど
これらはSteeringで制限したり、チャット経由で削除を指示していましたが、フックで自動削除させる運用の方が効率的だと感じました。
おまけ：タスク単位でgitコミットさせてみた
試験的に「タスク終了ごとに自動コミット」させてみました。 コミットメッセージには「実施タスク内容・対応範囲」を記載させるようにしたところ、Pull Requestにも流用できそうなレベルでした。
まとめ：Kiroと開発するなら「準備・分割・明示・確認」が鍵
今回の開発を通じて、SPECを作っている時点でKiroと人間の間には認識のズレが発生することを再認識しました。
例えば、私は「双方向リアルタイムの音声ストリーミング」を意図してSPECを定義したつもりでしたが、Kiroは「録音アップロード型のインターフェース」として実装してきました。
こうしたズレを減らすには次の4つが重要でした。
- 事前にしっかり準備する
- 大きなSPECは分割する
- 人間の期待を明示する
- 期待通りか確認する
普段の仕事でも同じですが、丸投げでは上手くいきませんので、しっかりとKiroに取って処理しやすい形で明示して、誤解が無いか確認するのが重要です。
まとめると以下の様になります。
こうすると失敗しやすい
- 仕様が曖昧なまま会話を始める
- SPECを1つにまとめて巨大化させる
- レビュー戦略を決めずに進める
こうすると上手く回る
- コーディング規約・開発ドキュメントをしっかり作る
- 大きなプロジェクトはSPECを分割して進める
- SVGなど視覚的な確認方法を取り入れる
- 繰り返し作業はフックで自動化する
*1:2025年10月時点ではVibeとSpecの区別はなくなっていますが、9月は分かれていました
