Amazonはなぜ「AWS Kiro」を標準IDEに指定したのか？ AIドリブン開発の最新事情を聞く

新規開発だけでなくレガシーマイグレーションのユースケースも

　AIアシスタントの「Amazon Q Developer」でも、仕様書を改訂すること自体は可能だった。しかしKiroは、仕様書とコードを常に最新の状態で維持できる点が異なる。モデルの選択も自由で、デフォルトのまま利用することもできれば、選択肢の中から好みのモデルに変更することもできる。

　Kiroには多くの適用領域が考えられると瀧澤氏は説明する。例として最初に挙げられたのが、簡単なモバイルアプリだ。自分専用のシンプルな機能を備えたアプリなら、「こんなことができたらいいな」を起点にコードも仕様書も書いてもらう。多くのユーザーが使用するプロダクトの場合は、仕様書側を変更すれば、コードを書かなくても機能を充実させられる。

　次に、複雑なCOBOLからJavaへの移行にも対応できる。今までは、変換ツールが出してきたコードすべてを人間がレビューしなければならなかった。しかしKiroであれば、仕様書を日本語でレビューできるため負担を軽減できる。「レガシーアプリケーションを塩漬けにしている日本企業の頭を特に悩ませているのは、仕様書とコードが一致していない問題だ。仕様書はほぼ確実に存在するが、事情があって、いつ更新したかがわからない場合が多い」と、瀧澤氏は指摘する。

　このような場合は、Kiroを2つ同時に利用することで移行が可能だと同氏は方法を紹介した。まず、1つ目のKiroに仕様書を読ませてJavaのコードを書いてもらう。そして、2つ目のKiroにはCOBOLのコードを読ませてJavaに変換してもらう。2つの仕様書を比較し、不備を見つけたら修正して完全な仕様書にしてもらう。それをもとにJavaのコードを再度書いてもらうと、理論的に正しいコードで移行できる。

　また、ファイル保存をトリガーにKiroがタスクを実行する「エージェント・フック」の設定も可能だ。たとえば、ファイルがサポートチームからの修正依頼ならば、Kiroがコード解析から始め、修正をするようなことも可能だという。さらに、Kiroではコンテキスト管理機能を利用して高度なこともできる。たとえば、MCPに対応している進捗管理システムであれば、MCPサーバー経由でKiroがそのシステムのタスクを実行できるのである。結果を人間が承認したら、次のタスクの実行に移るような使い方が可能だ。