本記事は AWSアワード受賞者祭り 2日目②の記事です。
✨🏆 2日目① ▶▶ 本記事 ▶▶ 3日目 🏆✨

本ブログは下記のブログの続編となっています。併せてご覧いただけますと幸いです。

6. 開発～pull request(PR)の自動化
7. まとめ

6. 開発～pull request(PR)の自動化

では実際にチケットの内容を読み込み、PRを作成するまでの一連の流れを自動化しましょう！

再掲となりますが、各機能の相関図は下記の図の通りとなります。

プロンプトの入力
Notionへのチケット情報の問い合わせ
コーディング、ビルド・テスト
PRの作成

というような流れで自動化を行います。では自動化に取り組んでいきましょう！

プロンプトの入力

プロンプトはプロンプトファイルに記載済みなので、Amazon Q Chatに@DEV4 を入力するだけでプロンプトの入力ができます。

agentic codingをONにすることでエージェントコーディングを利用できます。エージェントコーディングを行うことで、ただプロンプトの内容を受け取ってレスポンスを返すだけではなく、AIエージェントが「プロファイリング」「長期記憶」「計画、振り返り」「ツール実行」といった要素を用いてコーディングを行ってくれるようになります。

また、2025年6月18日にAmazon Q Developer IDE上でLLMの選択ができるようになりました。今回はClaude Sonnet 4を利用することとしました。

※今回はコードの修正以外にも、テストケースの生成やPRの作成など様々なタスクを行うため、/devコマンドは使用しませんでした。/devコマンドを使用しないことにより、コードの実装の許可をせずとも自動的に反映されてしまう点は注意をしてください。

ブランチのチェックアウト

最初にチケットに対応する作業用ブランチを作成してもらいました。

shellスクリプトは実際に手動で実行させる必要があります。実行後、問題なく#4ブランチにチェックアウトができたことを確認できました。

チケットの内容確認

Notionに記載のチケットの内容を確認してもらいました。NotionのAPIをMCP経由でたたくことにより、チケットの情報を取得します。ページを取得したのちに、テーブル等の子要素に対しても情報を取得することができ、チケットの内容を読み込ませることができました。

コーディング

実装を修正してくれました。

今回の修正により14ファイルを生成しましたが、その一部をお見せします。

こちらのUserServiceクラスは、UserControllerクラスのハンドラーメソッドが受け取ったデータを処理するビジネスロジックを記載しています。

プロジェクトルールに則り、Service層はServiceパッケージに格納されており、さらにJavadocも記載されています。

他にも、コーディングルールの記載に準拠したIntegration Test(IT)やUnit Test(UT)の生成を行っていることを確認しました。

ビルド、UT/IT実行

実装が完了したら、ビルドに問題がないか、テストに問題がないかを自動的にチェックしてくれました。

エージェントコーディングの真価の一つである、「計画、振り返り」がここでとても生きました。最初はビルドが失敗したのですが、なぜ失敗したのかを分析し、原因となる実装の修正を行いました。

何回か実装の修正が行われましたが、ビルドおよびテストが成功する状態となりました！小規模なCIもできてしまうのがエージェントコーディングの魅力の一つかもしれません。

PRの作成

Notionのチケット上に修正結果のサマリを記載してもらいました。

さらに、下記のようにPRの作成も行うことができました。

このように、コミット、プッシュまでのGit操作はgitコマンドをたたくという手間がありましたが、チケットの内容から実装を修正して、PR作成までを自動化することができました！

7. まとめ

冪等性は担保されているのか？

今回の手法で冪等性が担保されているのかという観点で、タスク取得APIのチケットを作成してAmazon Q Developerエージェントにコーディングを2回行ってもらいました。そして、同一ブランチでコミットを分けて、PRを作成しました。

生成されたTaskControllerクラスのgetTasksメソッドをピックアップして差分を確認してみると、下記のようになりました。

Javadocの記載、@RequestMapping・@GetMapingアノテーションのパスの指定、例外のcatchについて修正されていました。パスに関してはチケットに記載していなかったため、記載することで解消できたかもしれません。一方で、Javadocの「タスク一覧を取得」「タスク一覧の取得」といった細かな差異は、コーディングルールでは制御しきれない部分であると感じました。

冪等性は今回の実験では担保されませんでしたが、コーディングルールやチケットの粒度を補強することによってある程度は冪等性を担保できると推測できます。

PR自動化の利用可能性

Amazon Q の/devのベストプラクティス*1に下記記載があります。

機能で、一度に 5 つ以上のファイルの更新を必要としないようにしてください。Amazon Q により大規模な変更をリクエストすると、機能実装の品質と管理性に影響する可能性があります。ファイル差分に多くのファイルへの変更が含まれている場合は、機能の説明の範囲を狭めてみてください。

ということで新規APIの作成で大量のファイルを修正するようなタスクに関しては、自動化により品質の低下が生じてしまうことが確認できました。その一方で、ストーリーポイントが1や2のような、変更箇所が少ないタスクは完全に自動化することもできるのではないかと感じました。

利点と課題のまとめ

利点
- プロンプトファイル、プロジェクトルールを整備することで実装からPR作成までの一連の流れを自動化することが可能
- API作成タスクの場合、PR作成までは10分程度だったため、実際の手動のコーディングよりはるかに短い時間でPRを作成可能
課題
- エージェントの思考によっては、既存実装にも影響を与えてしまう可能性がある
  - チケットに記載の該当箇所以外の修正は行わないよう、プロンプトエンジニアリングを行うことで解消する可能性がある
- プロジェクトルールを詳細に記載しないと、冪等性が担保されない可能性が高い
  - エージェントのその時の思考によってもコードが変更されてしまう

エージェントモードを利用してコーディングすることで、ビルドおよびテストの実行まで行っているため、起動ができること、自動生成したテストケースの成功に関しては保証されています。とはいえ、人間のチェックなしでコミット、PRの作成までを自動化するのは危険なのかもしれません。

最初はチーム内のコーディングルールをそのままプロジェクトルールに記載し、一度PRの自動化を行ってみましょう。その後、プロジェクトルールやプロンプトファイルの修正点を随時改善していくことで、期待通りのコーディングを行っていくよう、AIエージェントを育てるといった使い方をすることが良いのかなと感じました。

終わりに

今回はNotion上で管理したチケットからPR作成までの流れを自動化しました。プロンプトを管理し、チケット駆動開発に組み込むことで、プロンプトを考えるまでもなく、かなり簡単に、ある程度の品質を担保しながらコードを生成することができました。品質という点ではdevfileを利用してサンドボックス環境でテストを行ってもらうという方法もあります。/devコマンドを利用する際はぜひ検討してみてください。

個人開発にも利用できる方法だと思ったので、今後は個人開発でも取り入れていきたいと思います！

皆さんも、Amazon Q Developerを利用してチケット駆動開発を自動化してみましょう！

*1:Amazon Q Developer を使用した機能の開発 - Amazon Q Developer