AWS Kiroで遊んだ感想
趣味ぐらい人力でコードを書く文化的な営みをしたいと思うのですが、AI界の急速なアップデートに加えて社用でもAIニーズが高まり、AIのキャッチアップの場として趣味を割く様になりつつあります。不本意ではありますが、シンプルに革新的なアップデートが多く刺激的でもあります。
これまでは主にv0やClaude CodeベースでのVibe Codingを味わっていましたが、AWSからリリースされたKiroは一味違うとのことでちょっと遊んでみました。
Kiro
コンセプトからプロダクションまで、AI エージェントとの作業を簡素化した開発者体験を通じて開発を支援する AI IDE（統合開発環境）、Kiro の発表を嬉しく思います。Kiro は Vibe Coding “も” 得意ですが、それをはるかに超えています。Kiro の強みは、スペック (spec) やフック (hook) などの機能を使って、これらのプロトタイプをプロダクションシステムに移行することです。
Kiro自体はIDE（ランタイム内蔵している訳では無いので個人的にはエディタと思いますが）で、Kiroの後ろでSonnetが動く形で実装を支援してくれます。その支援のスタイルが上記の様に Vibe Coding で無く、プロダクションレベルで使える相当の物を作る Viable Code を目指す様になった、と言うのがKiroの独自点と認識しています。
要するに開発者の頭にあった仕様・設計をベースにプロンプトを叩きAIにプロトを作ってもらう Vibe な進め方から、Specsと言われる設計ドキュメントを作る部分から手堅くやろうぜ、と言うスタイルをAWS側から提示してもらった、と言うイメージです。
Kiroの所感
Vibe Coding のラフな感じが好みな身ゆえに最初はまどろっこしさを覚えていましたが、一通り利用した限りは結構良かったです。
段取りが明確化される安心感
Kiroが言うSpecsは設計書と言いつつ、実際はAIと一緒にAIに投げるプロンプトを作っているだけと思っています。プロンプト整備はいわゆるプロンプトエンジニアリングの領域で、AIから最適解を得るために各人が試行錯誤してプロンプトを練り上げていく様な段階と思いますが、Kiroの価値はプロンプトエンジニアリングの負荷を大幅に下げた点にあるんじゃないか、と感じました。
Specsは順に仕様（requirements.md）->設計（design.md）->タスク（tasks.md）を組み上げていきますが、AIに対して requirements.md と design.md を読んだ上で tasks.md をやってくれ、との指示を与えるための準備作業とも捉えられます。Kiroが良い点はこの3ドキュメントをチェックポイントに順々・段々に確認を取りながら作りたい物を定義していく・作りたい物が生み出されるためのプロンプトを作ることが出来る点で、最適プロンプトはどうあるべきかなー、と各人で思案する必要が無くなったと思います。自前でオレオレなプロンプトテンプレートを組み上げたり、みたいな負荷が無くなった、と言う感じですね。
Kiroが提供する機能と言うより、Kiroが提供するプロンプト整備の段取り自体（つまりAWS側で検討を重ねたプロンプトエンジニアリングのステップ）に価値があると感じます。Kiroがプレビュー期間を終えた上でも未来永劫無料なはずも無いので、今のうちに持ち帰りたい知見がここに詰まっています。
ウォーターフォール的一貫性が個人的には嬉しい
KiroはSpecsからプロダクトを作る点でウォーターフォール的V字モデルをなぞったフローを提示してくれていると思います。あくまで個人の所感なので異論ある気もしますが、今までSpecs相当を作り上げることにかかっていた労力をAIで大幅に下げる代わりに高速にV字をなぞる、駄目ならSpecsからアップデートしてスクラップビルドをする世界観なのかな、との認識です。
この世界観が一旦ウォーターフォールを雛形に初版として作った物なのか、AWS側が検討を深めた末の結論なのかは定かでは無いですが、後者なのかと推測すると一定の示唆がある様に思いました。ウォーターフォールのもっさり具合・柔軟性の無さを解消するためにアジャイルが生まれ、スコープの広さと深さをコントロールすることでいかに早く価値を提供するかを念頭に置くスタイルが市民権を得た先の世界として、「高速にスクラップビルド出来るならばウォーターフォールガンガン回すスタイルが有りでは？」との指針が提示された様なイメージです。
個人的にもウォーターフォールな進め方は結構好みです。特にビジネスとしてシステム開発を行う上では、メンテナンス時の拠所が欲しかったり非IT側の人と合意を取る様な場面が一定多いことを思うとドキュメントの整備ニーズは強く、ある種整備作業を強制出来るフローは安心感があります。加えてそのドキュメントをそのままインプットにAIに指示を与えられるのも良く、従来の設計書を人間が解釈してコーディングとの流れよりもドキュメント内容とアウトプットとの一貫性を保てる側面も良いなと感じます。
恐らくですが唯一アジャイル的、つまりインクリメンタルに積み上げるポイントがあるとすると、KiroのSpecsを作らせるために渡す最初のプロンプトだと思いました。プロンプトを作る->Specsが出来上がる->作らせてみる->微妙だなーとなれば初期プロンプト調整（ここがインクリメンタル）->Specs出し直す、みたいなフローイメージ。ちなみにSpecsを直で直す形でのインクリメンタルもあるとは思いますが、Specs生成の主動力がAIである以上、AIからのアウトプットを一貫させる意味でも初期プロンプト側を弄るに徹するのが良いのかな、と個人的には思っています。
プロンプトエンジニアリングの重要性は依然高い
Kiroはプロンプト設計を強力に支援してくれますが、直前で書いた様に KiroのSpecsを作らせるために渡す最初のプロンプト だけは人間が作らないといけないです。KiroにちゃんとしたSpecsを作らせる意味ではプロンプト作りには依然気合を入れないといけないですし、ここを怠った形で使うKiroは使用感微妙になるのでは、と思います。
Kiroと言うかAIモデルはなまじ利口なので、凄く雑なプロンプトを投げてもそれらしいアウトプットを出してきます。Kiroでやった限りではワードを拾った上で一般的な設計ポイント等を引っ張ってきた上でごりっとSpecsを作る様なイメージですが、正直全自動で何か作ってくれるうれしさよりもベクトルがズレた物が出来てしまうストレスの方が強く感じるポイントになると思います。人によってはAIが汲み取ってくれないー、みたいな感じで不満を抱くかもしれません。
私自身も冒頭の通りAI利用・プロンプトエンジニアリングのエキスパートと言う訳では無いので有効なことは言えませんが、プロンプト用のファイルに今今持っている情報・考えている指針みたいな情報を詰め込む作業は不可欠ですし、それを上手くAIに伝えるためのテンプレート化も練っていかなければいけないポイントだと思いました。Kiroは自身の考えを全部ぶち込んだ上で考慮が足りていなかった点をSpecsとして炙り出してくれる様な使い方をするのが一番建設的と言うか、AIと壁打ちする意味のある使い方と思います。
趣味で使うには微妙
結構良かったと言いつつ、趣味としてガンガン使いたいかと言うとちょっと堅苦しいです。趣味だとWebアプリケーションを作ることが多いですが、体験としてはv0の様なプレビューを見ながらの Vibe Coding をしていく方が趣味レベルではやっぱり楽しいです。かっちり作る必要が無い物であれば雰囲気でガシガシ作れる方がスピーディーですし、AIがノリで作ったUIから得られる着想もたくさんあったりします。要件ゆるふわで良いなら、ゆるふわに作るゆえの良さ・楽しさがある。
上述したプロンプト設計の土台になりそうな点を含め、社用の場で使っていきたい要素が多いよなーと思います。実際高速ウォーターフォールの世界と伝統的ウォーターフォールの中で鍛え抜かれたSIer等の猛者たちの親和性みたいなところはちょっと見てみたいところで、会社がリスク取って良いと言うなら自身でPM的にそういう案件をやってみても、と思ったりもします。
まとめ
趣味目線ではしっくり来なかったものの、一通り遊んだ限りは全然良いなーと認識を改めました。今Waitlistで待たされちゃう様なので即ダウンロードして遊べる感じは出来なくなっていますが、機会あれば弄ってみるのはオススメです。
Discussion