最近行われたラスベガスでの大きなイベントで発表されたAmazonQの以下新機能を試してみました。
・ドキュメント生成
・UT自動作成

環境構築

言語、フレームワーク等の環境に縛りは無いですが、
今回は手っ取り早いSpringBootでRestAPI環境を構築して、検証を行います。

以下を参考にAmazonQでコード生成できるようにしてください。

getメソッドのAPIを作成します。
コードの生成をしてほしいので、「/dev」で依頼を出します。

/dev
AI want to create an API for retrieving inventory information. The request should include the store number, store name, product code, and product name. The response should include the store number, store name, region, product code, product name, inventory quantity, order quantity, and scheduled delivery date.

上記で実行すると、サマリと操作するファイルの一覧を出してくれました。

その次にフォルダ構成に提案

最後に提案内容を承認するか質問されるので、承認します。

ファイルが作成されます。特に待ち時間無くすぐに反映されました。

まだ何かある？と聞かれるので、はいを選択して、以下検証を実施します。

検証

ドキュメント生成

ドキュメントの生成を行うには「/doc」をテキストボックスに入力して、実行を押します。

今回は初回作成なので、以下を選択します。

めも
ドキュメントが作成済みの場合、
新規作成を選んでも、更新を選んでも、ルートディレクトリを選択していれば、
どちらでも大丈夫です。（最終的には差分を確認できる）

ドキュメント生成が必要なディレクトリを選択します。

ドキュメント生成中です。しばらく待ちます。

ReadMeファイルが作成されました。

※作成済みのreadmeがある場合、差分で表示してくれます。

承認するとプレビュー表示してくれました。

これはどういう線だ？こういうものなんですかね。。

実装方法の理由を質問してリファクタする

今回生成されたAPIがpostだったので、なぜpostにしたのか質問してみます。

解析対象のコードを右クリックし、「explain」を選択します。

このコードの意味を説明してくれます。

人間「なんでPOSTなん？」
Q　「ごめん、確かにそうだわ」

このままリファクタ案で書き換えようとすると、変更箇所を人間が理解して元コードを手動で除去する必要があります。
いっそファイルごと書き換えてもらいましょう。

気を利かせて色々提案してくれました。

/api/inventory - 一般的な在庫クエリ
/api/inventory/{storeNumber}/products/{productCode} - ストア内の特定の商品
/api/inventory/stores/{storeNumber} - ストア全体の在庫

よさそうなのでリファクタ案を取り入れてみます。

注意
「insert at cursor」の場合は、変更箇所を人間が理解して元コードを手動で除去する必要があります。
今回はファイル全てのリファクタ案を出し直してもらったので、一度元ファイルのコードを全削除してから、
「insert at cursor」します。

ファイルを書き換えて保存します。

構造が変わったので、ドキュメントも再度生成します。
「/doc」してこんな感じで選択していきます。

新規分は追加されましたが、ゴミが残っているので正しく作成し直してもらいましょう。

実態に合わせてくれました。

作成されたAPIを実行してみる

使い方を教えてもらいましょう。「how to use」と入力したのち、
使いたいAPI情報を入力します。

サンプルリクエストデータを実行すると以下の通り、データが取得できました。

UT自動作成

UT自動を作成するには「/test」をテキストボックスに入力して、実行を押します。

不明点あれば部分的に質問ができます。

作成されたUTを実行してみる

テストを実行してみましたが、失敗しました。

人間「できないぞ、なんでだ？」
Q　「ホントだ。必須になってないわ」

必須が正しいのか、指定なしを許容するのかは業務次第だと思いますので、
人間が正しい方を指定して、修正していきます。

最後に

今回は仕様をふわっと伝えたので、リクエストの必須チェックが中途半端に実装されてしまいましたが、
実装通りのUTではなく、あくまで仕様に沿った出力をしていたのかなと思うと、こっち方が優秀でバグ検出が上手くできそうではあるものの、
どこで検知するのが正しいのか、また、このように不確定な検出方法としていいのか、課題が残るので、
仕様依頼をきちんと行って（設計書を作成してみようかな）からもう一度検証してみようと思いました。