Amazon Q developerにおけるプロジェクトルールの実装例

はじめに

Visual Studio CodeなどのIDEAmazon Qを使ってなんらかの処理をさせたい時、プロジェクトルールやコーディング規約など生成させるコードなどになんらかのルールを強制させたいことがあります。これを実現する機能が以下の公式ドキュメントで書かれているプロジェクトルールです。

docs.aws.amazon.com

ここでは、私が実際に使っているプロジェクトルールを紹介します。なお、このプロジェクトルールですが、日々試行錯誤を重ねています。今日時点のものが完成形ではなく、日々修正等を積み重ねていることはご了承ください。

ルールの確認・作成

上記の公式ドキュメントにもありますが、プロジェクトルールはプロジェクトルート/.amazonq/rulesフォルダにMarkdownファイルを作成することで完了します。1つのファイルで完結させる必要もなく、複数のファイルに分割しても良いです。

Visual Studio CodeではAmazon QのChatウィンドウにてRulesがあるのでそれをクリックしたら現在のルールの確認や新規ルールの作成などが行えます。

ルールの作成

Markdownでルールを書くことができるとは言っても、何を書くか悩んで手が止まってしまうことがままあります。わかりやすいものとしてはコーディングルールかなと思います。

コーディングルール

生成AIでコードを生成させるとき、コーディングルールなどで指示をあらかじめ与えておくとそれに従ったコードを生成してくれます。例えば、こんなルールを使っています。

プロジェクト内でJava言語のコーディングを行う際は下記ルールに従ってください。

# 全般

- 1つのファイルに複数のクラスを記載しないようにしてください。
- 1つの行に対して最長100字以内となるように記載してください。100字を超える場合は適宜次の行に記載するようにしてください。
- deprecatedとなっているクラスやメソッド、アノテーションは使わないようにしてください。

# JavaDocについて

- 生成するすべてのメソッドおよびクラスに対してJavadocを記載してください。

# 設定ファイル

- 設定ファイルはproperties形式としてください。YAML形式は使わないでください。

# 生成するファイルのパッケージについて

Spring Bootアプリケーションで必要な各ファイルは下記のパッケージに
`src\main\java\com\example\springaiapp`配下に下記パッケージを配置してください。
それぞれのパッケージがない場合は新規作成してください

## パッケージ一覧

- Controller:Controllerクラスを格納してください。
- Service:Serviceクラスを格納してください。
- Repository:Repositoryクラスを格納してください。

# 命名規則

以下の命名規則に従ってください

## クラスの命名

各クラスのパッケージ名をクラス名のあとに記載してください
例:HogeControllerクラス(Controllerクラスに配置)

# テストファイルの作成について

テストファイルの種類は下記とします。

## Unit Test

- JUnitを利用してください
- テストケースは分岐網羅をカバーするように作成してください。

# フォーマット

- フォーマットは[Google Java Style Guide](https://google.github.io/styleguide/javaguide.html)に従ってください
- コードを生成した場合、Gradleの`spotlessApply`タスクを実行してフォーマットを修正してください

あまり目新しいところはないかと思います。設定ファイルをproperties形式にしているのは、grepをするときに探しやすいかなと思って指示しています。

deprecatedとなっているものを使わないようにと指示していますが、実際にはあまりうまく判断できない感じがします。

一般的な注意事項

一般的な注意事項として、以下の内容を.amazonq/rules以下に保存しておいています。

# 基本

- 日本語で応答してください
- 必要に応じて、ユーザに質問を行い要求を明確にしてください
- GitHubへアクセスが必要な場合は、GitHub CLIの`gh`コマンドを使ってください

# 作業の定義

それぞれの作業を以下のように定義します。

- 「設計」と指示された場合、指示されたことに対して以下のことを実施してください
    - `docs/designs``YYYYMMDD-連番-design.md` という名前のファイルを作成し、記載してください
        - ファイル名の中にある`YYYYMMDD`は`date`コマンドなどを使って現在の日付を正しく取得するようにしてください
        - ファイル名の中にある`連番`は2桁0埋めの1から始まる番号としてください
    - この段階でコードは絶対に書かないようにしてください
    - この段階では、指示されたことに対してAPIエンドポイント設計やテーブル設計、作成・更新が必要なコードについて考えファイルに出力してください。
- 「設計レビュー依頼」と指示された場合、以下のことを実施してください。
    - 同時に指示された`docs/designs`内の`YYYYMMDD-連番-design.md`という名前のファイルの内容をもとにGitHub上でIssueを作成してください
        - Issueのタイトルは指示された内容を30文字以内にまとめたもの、Issueの内容は指示された内容としてください
        - `docs/designs` に作成する`YYYYMMDD-連番-design.md`にはGitHub Issueの番号も追記するようにしてください
    - GitHub Issueの番号を使って、`feature-GitHubのIssueの番号`というgitのブランチを作成してswitchしてください
- 「実装」と指示された場合、 `docs/designs` に記載された内容に基づいて実装してください

# `docs`ディレクトリの内容

- `docs/designs/*.md` : 設計資料

イメージとしては、①何かやりたいことに関する設計と②実装を順番通りに進める形です。

YYYYMMDDは特に指定しないと適当な日付を設定するので「dateコマンドなどを使って〜」と具体的に取得方法を指示しています。GitHubへのアクセスもghコマンドを使用するように具体的に指示していますが、MCP Serverでもよいかもしれません。

プロンプト

この内容を踏まえて、プロンプトには

  • XXXなことを実現するために設計してください
  • docs/designs/YYYYMM-連番-design.mdの内容をもとに実装してください

といった感じで指示を出します。

改善案

とりあえずこんな感じでJavaアプリの開発を進めているのですが、いくつか改善案もあります。

  • 実装時にpull requestの作成を指示する
  • Issueのフォーマットについて指示する
  • GitHub Issueを参照して調査や計画が実行できるようにする
  • deprecatedなものを使わないでと言っているが使うことがある。後の調査でも使っていないと言い張る

ただ、これらのプロンプトエンジニアリングは凝り始めるといつまでもやってしまいそうなので、どこかで区切りを持った方が良いかなとも思います。