実プロジェクトで試してみた：Amazon Q Developerのリアル〜test機能編〜

はじめに

こんにちは、mickeyです。先日、あるプロジェクトで Java のバージョンアップ（Java 7 → Java 17）を進める中、近年注目を集めている Amazon Q Developer を実際に導入し、数ヶ月にわたって使用してみました。
本記事では、その中でも特に「テスト生成機能（/test 機能）」に焦点を当て、実プロジェクトに組み込んでみて得られた気づきや手応えを、リアルな体験としてお届けします。

Amazon Q Developerの「transform機能（Java 7 → 17）」については、以下の記事で深掘りしています。こちらもぜひご覧ください。

あわせて読みたい

大規模JavaアプリケーションのアップデートにAmazon Q Developerを適用してみた（transform編）

Amazon Q Developerのtest機能とは？

Amazon Q Developerのtest機能は、AIを活用してユニットテストの作成を自動化する機能です。この機能により、開発者は手動でのテストコード生成の手間を省き、コード品質の向上と開発効率の向上を実現することができます。

主な特徴としては以下が挙げられます。

• テストケースの自動識別
  プロジェクト全体の構造や既存コード、クラス間の依存関係などを静的に解析し、テストすべき箇所を自動で特定してくれます。これにより、どこを重点的にテストすべきか、どのパターンをカバーすべきかが明確になり、テスト漏れの防止にもつながります。
• モックとスタブの生成
  ユニットテストにおいて外部依存を切り離すために必要となるモックやスタブも、Amazon Q Developerが自動的に生成してくれます。たとえば、データベースアクセスやAPI呼び出しなどを含むクラスに対しては、適切なモックオブジェクトを生成し、開発者がテストロジックに集中できる環境を整えてくれます。

言語としては現在（2025年5月）、

• Java
• Python

の2言語が対応しています。

Q DeveloperのIDE導入方法＆テスト機能の使い方

今回、私たちはエディタとして Visual Studio Code（VSCode） を使用していました。
VSCode は Amazon Q Developer との連携も非常にシンプルで、拡張機能から Amazon Q をインストールし、AWS アカウントと紐づけるだけですぐに利用を開始することができました。

また、Amazon Q Developerでのテスト生成は、

① テストを生成したいファイルをVSCode上に表示させておく

② VSCodeのChat欄からコマンド /test を叩く

のみの操作でテスト生成を実行させることができました（もしくは、ファイル全体を強調表示→右クリックし、「Amazon Q」→ 「Generate tests」からでもテスト生成を実行可能です）。特にプロンプトエンジニアリング力を必要とせず、Chat欄からボタンを数回クリックするだけで実行できることが印象的でした。

使用時の体感と気づき

実際にプロジェクト内でテスト機能を試してみたときの結果と気づきは以下の通りです。

生成されたテストの網羅性は？

とあるファイルを例に取り、生成したテストを実際に眺めてみると、基本的に分岐網羅（C1）レベルを目指した構成になっており、以下のようなケースが自動生成されることがわかりました。

正常系

• 条件分岐の全パスを一度は通るケース
• 正しいパラメータでのリクエストを行うケース

異常系

• nullや空文字のパラメータを指定するケース
• 存在しないIDを指定するケース
• 処理途中で例外が発生するケース

今まで他の生成AIツールなども使ってきましたが、特にテストケースの作成においてこのパターンまで網羅できているのはあまり見たことがなく、かなり驚きでした。

上記の結果から、Amazon Q Developerのテスト生成の網羅性が非常に高いということがわかりました。

手修正は必要

しかしながら、生成されたテストコードをそのまま使うことができず、以下のような修正が必要となるケースもありました。

• 同一テストファイル内でのメソッドの命名に揺らぎがある（snake_caseとlowerCamelCaseが混在してしまっている）
• 存在しないライブラリをimportしてしまっている
• コンストラクタに渡している引数の数が、定義と合っていない
• 同一テストファイル内で@BeforeEach メソッドが重複して生成される

なので現状ですと、生成されたテストコードに対して「多少の修正工数は見込む必要がある」という前提が必要かもしれません。

※その他、テスト機能を使用していて気になった点は以下の通りです。

• 1度に生成できるのは1ファイルのみ
  すべてのファイルに対して逐次 /test 実行が必要。単体テストを複数作成しなければならない場面では少々煩雑でした。
• 進捗がわからない
  プロジェクト当初は進捗が分からず、テスト生成の経過などが分からず心理的負荷がありました。→後ほどアップデートが入ったことにより、プログレスバーが表示され視覚的に分かりやすくなりました！

実プロジェクトで削減できた工数は？

大まかな計算ですが、体感として以下のような工数削減が見られました。

特に「何をテストすべきか？」という観点を持った上でテストケースを作成してくれる点が非常に優れており、その点ではプロジェクトメンバー側でほとんど追加修正が不要なくらいまでの細かなロジックや例外系のケースも丁寧に拾い上げてくれた印象がありました。

まとめ

test機能において、Amazon Q Developerは「リポジトリの全体構造を見渡して、過不足なくテスト観点を洗い出す」という点で特に優れたツールであると感じました。自分の代わりに設計してくれる相棒のような位置づけで使うと特に真価を発揮すると思います。

おわりに

今回数ヶ月に渡り実プロジェクトで使用してみて、Amazon Q Developerは使用する生成AIツールとして確かな選択肢となりえることがわかりました。まだリリースから間もないこともあり、今後のさらなる進化にも期待大です！

mickey