こんにちは。
アプリケーションサービス部、DevOps担当の兼安です。
今回はKiro IDEの話で、簡単な感想記事です。
はじめに
先日ベクトルデータベースの技術検証記事を書いたのですが、この時の技術検証はKiro IDEをフル活用して書いています。
検証用コードはこちらです。
GitHub - satoshi256kbyte/vector-db-benchmark · GitHub
検証作業は無事やり切れたのですが、なんだか色々反省点を見つけたので今日はそのことを書いていきます。
最近のKiro IDE
本題に入る前にKiro IDEについて触れておきます。
今年に入り、タスク一括実行機能などが追加されたり、要件を入力すると要件定義を先に書くかあえて技術設計を先に書くかを選べるようになったりと確実にUIと使い勝手が向上しています。
すべてのタスクを一括実行：リリースを見送り続けていた機能をついに公開 | Amazon Web Services ブログ
バグ修正と既存アプリの上に構築するための新しい Spec タイプ | Amazon Web Services ブログ
UI以外の部分では、tasks.mdで自然とチェックポイントを挟んでくれるようになりました。
これにより以前感じていた最後に一気にテストするような動きが緩和されています。
私個人は、このチェックポイントだけでは物足りないので、フック機能で一つタスクを消化した時にコミット・プッシュをさせることにしています。
これにはpre-commitに仕込んでおいたリンターや自動テストを強制的に通させる意味も込めていて、チェックが後回しになる現象をより強く防止するようにしています。
フック機能についてはこちらをご覧ください。
Kiro の AI エージェントフックで開発ワークフローを自動化する | Amazon Web Services ブログ
想定していた技術検証の流れ
ここから本題に入ります。
先述のブログ記事でやりたかったことは、「3種類のベクトルデータベースのデータ投入・検索時間を計測する」だったので、以下のような流れを想定していました。
- IaCで3種類のデータベースを作成する
- データ投入プログラムを作る
- 検索プログラムを作る
- プログラムを実行して計測する
1〜3を3段階のスペック駆動開発することで、検証環境が完成するだろうと思っていました。
ですが、結果としてスペックは7つになり、途中途中で追加のバイブコーディングで軌道修正するなど、予想は大きく外れることになってしまいました。
所要時間は想定の倍程度かかっています。
なぜこうなったのか？を考えたところ、原因は大きく2つあると考えました
- 設計を自分で書いていないので指示が適当になっている
- 欲が出て余計な要件を入れてしまっている
設計を自分で書いていないので指示が適当になっている
今回、データ投入プログラムはバルクインサートを後から追加。
AWS Lambda関数のデプロイツールを後からAWS SAMに変更ということを行なっています。
その他、ちょこちょことバイブコーディングで微調整を行なっています。
私が普段のように自分で設計・実装していたならば、バルクインサートもAWS SAMも最初から入れていたでしょう。
要件の入力が甘かったといえばそれまでですが、なぜ甘かったかを考えてみます。
要件定義・設計書を自分で書く場合、自分で手を動かし・レビューを挙げ指摘をもらい・時には紙に印刷して体裁をチェックします。
この過程で思考と設計が洗練されていきます。
今回、スペック駆動開発の要件入力においては、いろいろな工程を飛ばして指示しかしていないので、熟慮が足らない指示とレビューになっていたのだと思います。
欲が出て余計な要件を入れてしまっている
検証において、テスト実行スクリプトを作らせたのですが、後から考えればこれ必要だったかなあと思います。
作るにしてももうちょっとシンプルでよかった気がします。
当初実行スクリプトまではイメージしてなかったのですが、あった方が楽だろうと追加してしまいました。
これが意外と作成に時間がかかってしまい、余計なことをしてしまったなと反省しています。
結局のところ、自分が作らない上相手が人でないので、欲を出して気軽に追加してしまったのです。
欲を出した結果、成果物ができるのが遅れるという形で自分に跳ね返ってきました。
自分も間違える、AIも間違える
最近、Kiroに限らず、AIも結構間違えるなとよく思います。
例えば、言語のバージョンが微妙に古いのを指定することがあります。
Pythonだと3.11をよく使おうとしますが、本記事執筆時点（2026年3月）でPythonの最新の安定版は3.14なのでこれは正解とは言い難いです。
また、油断すると過剰品質になる傾向も感じます。
一番よく感じるのはフロントエンド周りで、シンプルな画面なのに過剰なアクセシビリティが実装されて、その結果自動テストが重くなるという現象を散見します。
これに関しては私にアクセシビリティに関する知識が不足しているので最低限のアクセシビリティというものを指示できていないという側面もあります。
自分もよく間違えます。
浅慮な指示を出してしまいましたが、幸いスペックを3段階にしていたので都度リカバリーすることでやり切ることができました。
一発の指示で全部やり切ろうとするとリカバリーは無理だったかもしれません。
月並みなことしか言えませんが、自分も間違える・AIも間違えるという前提で小さく指示を出すのがベターと改めて認識しました。
兼安 聡(執筆記事の一覧)
アプリケーションサービス部 DS3課所属
2025 Japan AWS Top Engineers (AI/ML Data Engineer)
2025 Japan AWS All Certifications Engineers
2025 AWS Community Builders
Certified ScrumMaster
PMP
広島在住です。今日も明日も修行中です。
X(旧Twitter)
