2026年6月、JAWS-UG 名古屋で話した LT の登壇資料です。
「AIに任せればコードはどんどん書ける。でも“確かめる(レビュー)”は追いついてる?」
——そんなモヤモヤから始まった、開発段階でセキュリティレビューを自分から回してみた検証の記録です。
Kiro で書いた設計書(requirements / design / tasks)を、AWS Security Agent(プレビュー)の Design Review にかけてみたら、設計書がそのまま AI レビューの“採点基準”になりました。書く → レビュー → 指摘を設計書に書き戻す、をぐるっと回すほどレビューが賢くなっていく。私はこれを“育つレビュー”と呼んでいます。
実際、最初は情報不足で評価すらされなかった5つの領域が、設計書に要件を書き足しただけで全部“合格(COMPLIANT)”に変わり、[Requirement N] という評価軸つきの指摘が 0 件から 9 件に。さらにスコープを 4.8 倍に広げても、指摘の密度はむしろ下がりました。「直したつもりが素通り」「直したファイルが実は動いていない」——AIと分業するからこそ起きる落とし穴も、設計書とコードの突き合わせで拾えています。
【今日の持ち帰り3つ】
・「情報不足」は責められてるんじゃなく、「設計書に書け」のサイン
・指摘は直して終わりにせず、spec / steering に“書き戻す”
・Kiro で“設計書”を書くこと = AI レビューに“採点基準”を渡すこと
設計書は“作るための紙”だけじゃない。書いた瞬間に、AIと一緒に“確かめる力”が育ちはじめます。
同じように現場で試した方がいたら、ぜひ感想ください。
「本当のAmazon Quick & Kiroの現時点を教えちゃうぜスペシャル」
https://jawsug-nagoya.connpass.com/event/395706/