NRIネットコム社員が様々な視点で、日々の気づきやナレッジを発信するメディアです

注目のタグ

    Amazon Q Developer IDEのプロンプト整備とMCP活用によるpull request作成自動化 ~事前準備編~

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


    1. はじめに

    皆さんこんにちは!入社2年目アプリケーションエンジニア、2025 Japan AWS Jr. Championの松澤武志です!つい先日より、C#の案件に携わることになったので日々C#の勉強をしています。

    今回は「AWSアワード受賞者祭り」ということで、Amazon Q Developer IDEについて、ブログを執筆いたします!ボリュームが多くなってしまったので2本に分割しました。両方ご覧いただけますと幸いです。

    本ブログの概要

    近年生成AIを利用したコーディング支援ツールを利用して、業務効率化を図る動きが活発になっています。しかし、プロンプトの入力を開発者に委ねる場合、プロンプトエンジニアリングの技量が開発者によって左右されてしまいます。したがって私は、プロンプトを管理することが生成AIコーディングにおいて重要であると考えました。Amazon Q Developer IDEでは、プロンプトファイルと呼ばれる、あらかじめ記載されたプロンプトファイルなど用いて、プロンプトを管理することができますので、本ブログではその利用方法をお伝えします。

    また、今回はチケット駆動開発における利用方法の一例として、Model Context Protocol (MCP)を用いることで、チケットの内容をプロンプトに組み込むということも試してみました。これにより、設計者→開発者→生成AIというコミュニケーションパスから、設計者→生成AIというコミュニケーションパスでコーディングを行うことができ、さらに開発者間での生成物の差異がなくなるのではないかと考えました。

    ということで、2025年6月13日にMCPが利用可能になった、Amazon Q Developerの統合開発環境(IDE)プラグインを用いて、プロンプトの整備とMCP活用によるコーディングからpull request(PR)までの自動化について実験してみました。


    2. Amazon Q Developer とは

    aws.amazon.com

    Amazon Q Developerとは、簡単に説明すると生成AIを活用したソフトウェア開発アシスタントサービスです。GitHub CopilotやCursorなどといったツールと似ていますが、AWSサービスと統合されており、AWS LambdaやAmazon SageMaker AI Studioなどにも利用できるといった面が強みとなっています。

    また、Amazon Q Developerは、プロジェクトルールにより、コーディングを行う際のルールを定めたり、プロンプトファイルを作成してプロンプトの管理・再利用を行うことができます。

    Amazon Q Developer はAWSコンソール上、統合開発環境(IDE)およびCLIにおいて利用することが可能です。さらに、2025年4月9日に日本語のサポートが開始されました。実際に日本語のプロンプトを入力すると、レスポンスが日本語で返ってきます。(Amazon Q Developer が IDE と CLI における多言語サポートを拡大 - AWS

    今回はSpring Bootアプリケーションの開発を行うという前提で、JetBrains社のIntelliJ IDEAにAmazon Q Developerプラグインをインストールします。次の章からは実際のプロンプトの操作法について記載します。


    3. Amazon Q Developerのプロンプト操作

    Amazon Q Chat

    Amazon Q Chatはチャット形式でAIと対話しながらプロンプトを入力できる機能です。インストール方法及び利用方法は、以前私が執筆した下記ブログをぜひ参照してください。

    tech.nri-net.com

    チャットコマンド

    各種コマンドを利用して様々な用途に適したエージェントコーディングの支援を受けることができます。

    • /dev:コードを生成
    • /transform:Java、.NETアプリケーションのモダナイゼーション
    • /doc:README.mdを生成・修正
    • /review:脆弱性やコード品質の問題を確認
    • /test:ユニットテストを自動生成

    プロンプトファイル

    プロンプトファイルは、プロンプトを記載するファイルです。プロンプトファイル自体はローカル環境の.aws\amazonq\prompts 上でマークダウン形式で保存されます。ただプロンプトを羅列するだけでなくマークダウン形式で記述可能なので、見出しを付けて構造化させた文章を記載したり、コードブロックを記載させてfew shot promptingを行うといった利用方法もあると感じました。またプロンプトファイルとして管理することで、プロンプト自体のレビューを行ったり、再利用できる点も魅力的です。

    利用方法

    1. Amazon Q Chat上で@を入力し、Promptsを選択します。

    2. Prompt nameにプロンプトファイル名を入力します。

    3. その後、IDE上でプロンプトファイルが表示され、プロンプトを記載することができます。

    4. プロンプトファイルを利用する際は、Amazon Q Chat上に「@プロンプトファイル名」を入力することで利用することができます。プロンプトファイルの前後に他の要素を入力しても問題ありません。

    プロジェクトルール

    プロジェクトルールは、プロジェクト内でコード生成を行う際に従うべきルールについて記述します。Javadocを記載することや、命名規則、パッケージ構成など、様々なルールをマークダウン形式で記載することができます。

    保存場所はproject-root/.amazonq/rules となっており、プロジェクト配下に保存することが可能です。

    コンテキスト

    チャット時にコンテキストを含めることができます。コンテキストを追加する機能として下記が提供されています。

    • @workspace
      • チャットに入力することで、ワークスペースコードの最も関連性の高いチャンクをコンテキストとして自動的に含めることができます。
      • 「Spring Bootアプリケーションの全体構成を確認する」であったり、「パッケージがコーディングルールに準拠しているか」などを確認するときに利用すると、適切な回答が得られます。
    • コンテキストのピン止め
      • @でサジェストされる項目(workspace、任意のフォルダ、任意のファイル、メソッド単位のコード)などをピン止めして自動的にコンテキストに含めることができる機能です。

    インラインコメント

    Amazon Q Chatとは異なるプロンプトの入力方法です。インラインコメントを記載することで、コメントに沿った実装をサジェストしてくれます。メソッドの作成など局所的なコーディングに利用するときに便利です。

    ※本ブログではインラインコメントは利用しません。


    4. Model Context Protocol (MCP)

    MCPはAIエージェントと外部サービスの連携を容易にするオープンプロトコルです。*1サードパーティの外部サービスの情報を利用して生成AIがレスポンスを行ったり、コーディングを行ったりすることができます。

    MCPの真価はAPIをたたくことによるインタラクティブな通信だと考えています。GETメソッドが利用できるように、POSTメソッドなど他のメソッドのAPIをたたくことも可能です。それにより、外部サービスの情報を更新できたりします。このAPIをたたくという機能のおかげで、GitHubの連携によるPRの作成も可能となっています。

    かなり最近のことですが、Amazon Q Developerの統合開発環境(IDE)では、2025年6月13日にMCPが利用可能となりました。本ブログではNotionとGitHubを連携させた例をご紹介します。


    5. 事前準備

    ここからは、実装からPR作成までを自動化する一連の実験を行うための、事前準備について記載していきます。一連の流れを可視化した図がこちらになります。

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

    というような流れで自動化を行います。そのために必要な事前準備を行います。

    チケットの起票

    今回は外部サービスとしてチケット管理をNotionで行うものとします。 Notion上でチケットのページを作成します。今回は「チケットNo.4-ユーザー検索APIの作成」というチケットを起票しました。Chat-GPTを用いてユーザー検索APIの仕様書を自動生成してもらいました。

    仕様書の項目はほかにもありますが、量が多いため割愛します。

    • レスポンス仕様
    • エラーレスポンス/エラーコード
    • DBのテーブルやカラムの詳細
    • シーケンス図

    など、他の項目も自動生成してくれました。

    プロンプトファイルの編集

    DEV.mdファイルに下記を実行するように、あらかじめプロンプトを記載します。

    1. ブランチのチェックアウト
    2. 実装修正
    3. ビルド、テスト確認
    4. PR作成
    1.ブランチのチェックアウト、2.実装修正、3.ビルド、テスト確認、4.pull request作成の順で必ず着手してください。
    
    # 1.ブランチのチェックアウト
    
    修正に着手する前に新規ブランチに必ずチェックアウトしてください。
    ブランチ名は下記のNotionの参照先チケットのチケット名の番号に#をつけた値としてください。
    すでに存在する場合はそのブランチにチェックアウトしてください。
    (例:チケットNo.1 の場合、#1)
    
    # 2.実装修正
    
    下記のNotionの参照先チケットの要件に従って実装を修正してください。
    https://www.notion.so/{チケットNo.4のリンク}
    
    修正後、`DEV4.md``.amazonq/prompts`のフォルダにコピーしてください。
    実装の修正が完了した場合、参照先チケットに、修正結果のサマリをマークダウン形式で記載して下さい。
    
    # 3.ビルド、テスト確認
    
    ビルドが成功すること、作成したUTおよびITのテストが成功することを確認してください。
    もし成功しない場合は修正を行ってください。
    
    # 4.pull Request作成
    
    修正が完了したら、下記ルールに従って、pull requestの作成を行ってください。
    
    - 変更結果はすべて一度にコミットするものとする。コメントはチケット名を記載する。
    - 修正内容のサマリをdescriptionに記載するようにする
    - pull requestの名前はチケット名と同じにする(例:チケットNo.1の場合、チケットNo.1)
    - 下記リポジトリ上で作成を行う
     https://github.com/18takeshi/TestAmazonQ/pulls
    

    今回はチケットNo.4のタスクを実行するようにします。もし別タスクを実行する際は、DEV4.mdをコピーしてチケットのリンクを変更するだけでプロンプトを再利用することが可能です。

    ※プロンプトファイルはプロジェクト配下とは別にローカル環境に作成されるため、そのままではGitによる管理ができません。したがって本ブログの実験では、.amazonq/pronptsというフォルダをプロジェクト内に作成し、プロンプトファイルを随時コピーすることでPRに含めるという運用をすることとします。

    プロジェクトルールの記載

    下記java-coding-rule.mdというプロジェクトルールを作成しました。

    プロジェクト内でJava言語のコーディングを行う際は下記ルールに従ってください。
    
    # 全般
    - Nestedクラスはテストファイル以外は利用してはいけません。
    - 1つのファイルに複数のクラスを記載しないようにしてください。
    - 1つの行に対して最長120字以内となるように記載してください。120字を超える場合は適宜次の行に記載するようにしてください。
    
    # JavaDocについて
    
    - 生成するすべてのメソッドおよびクラスに対してJavadocを記載してください。
    
    # 生成するファイルのパッケージについて
    
    Spring Bootアプリケーションで必要な各ファイルは下記のパッケージに
    `src\main\java\com\example\GeneratedByOpenApiGenerator`配下に下記パッケージを配置してください。
    それぞれのパッケージがない場合は新規作成してください
    
    ## パッケージ一覧
    
    - Controller:Controllerクラスを格納してください。
    - Service:Serviceクラスを格納してください。
    - Logic:Logicクラスを格納してください
    - Repository:Repositoryクラスを格納してください。
    - Response:Responseクラスを格納してください。
    - Request:Requestクラスを格納してください。
    - Enum:Enumが必要な際は格納してください。
    
    # 命名規則
    
    下記命名規則に従ってください
    
    ## クラスの命名
    
    各クラスのパッケージ名をクラス名のあとに記載してください
    ex) HogeControllerクラス(Controllerクラスに配置)
    
    # テストファイルの作成について
    
    テストファイルの種類は下記の2種類とします。
    
    ## Integration Test
    
    - JUnitを利用してください
    - 各Controllerクラスに対して、1つのControllerITクラスを作成してください
      - ex)「HogeController」クラスにGETメソッド「Huga」およびPOSTメソッド「piyo」が存在した場合
      - 「HogeControllerIT」クラスを作成し、「HugaTest」Nestedクラスおよび「piyoTest」Nestedクラスを作成してください
    - 各Nestedクラスに対して、テストケースを記載してください
    - テストケースは、各エラーが生じることの異常系テストおよび、各APIのユースケースを網羅させるようにしてください。
    - `src\test\java\com\example\GeneratedByOpenApiGenerator\IntegrationTest`配下に各ITクラスを格納してください。
    
    ## Unit Test
    
    - JUnitを利用してください 
    - 各Serviceクラスに対して1つのServiceUTクラスを作成してください。
    - ex)「HogeService」クラスにGETメソッド「Huga」およびPOSTメソッド「piyo」が存在した場合
      - 「HogeServiceUT」クラスを作成し、「HugaTest」Nestedクラスおよび「piyoTest」Nestedクラスを作成してください
      - 各Nestedクラスに対して、テストケースを記載してください。
    - テストケースは分岐網羅をカバーするように作成してください。
    - `src\test\java\com\example\GeneratedByOpenApiGenerator\UnitTest`配下に各ITクラスを格納してください。
    

    MCP設定

    今回はNotionとGitHubにそれぞれ連携するMCPサーバーを設定します。

    1. Notionの新しいインテグレーションを作成
      インテグレーションページ(https://www.notion.so/profile/integrations)にアクセスして「新しいインテグレーション」を作成します。

      インテグレーション名、ロゴ等を設定して保存を押します。*2

    2. APIアクセストークンを作成
      インテグレーションのページに遷移します。「内部インテグレーションシークレット」をコピーして控えます。

      また、「アクセス」タブからアクセスを行いたいNotionのワークスペースを指定します。

    3. Amazon Q Developer側でMCPの設定
      Amazon Q Chat上のMCPの編集ボタンを押して、+ボタンを押し、新規MCPサーバーを作成します。その後、各種項目を設定します。

      • Scope:任意
      • Name:任意
      • Transport:stdio
      • command:npx
        • MCPサーバーをnpx経由で起動する
      • Arguments:-y@notionhq/notion-mcp-server
        • 実行するmcpサーバーのパッケージ名
      • Environment variables
        • "OPENAPI_MCP_HEADERS": "{\"Authorization\": \"Bearer ntn_****\", \"Notion-Version\": \"2022-06-28\" }"
        • Notion APIに渡すHTTPヘッダーを記載
        • ntn_****は内部インテグレーションシークレットを指定
    4. 実行したいAPIを指定

      • Notionの場合、MCPサーバーで実行できるAPIは19種類となります。
      • APIの認可について「Ask」「Always Allow」「Deny」の3種類あります。AskはAPIをたたくときに毎度確認を行います。
      • 今回はすべてAlways Allowとしました。

    保存すると、MCPサーバーの設定が完了です!

    ちなみに、MCPサーバーの設定は.aws\amazonq 配下のmcp.jsonに保存されます。編集することによりMCPサーバーの設定変更が可能です。今回はGitHubとも連携させましたので、下記のようなmcp.jsonが作成されました。

    {
      "mcpServers": {
        "Notion": {
          "command": "npx",
          "timeout": 60000,
          "args": [
            "-y",
            "@notionhq/notion-mcp-server"
          ],
          "env": {
            "OPENAPI_MCP_HEADERS": "{\"Authorization\": \"Bearer 発行した内部インテグレーションシークレット\", \"Notion-Version\": \"2022-06-28\" }"
          }
        },
        "github": {
          "command": "npx",
          "timeout": 60000,
          "args": [
            "-y",
            "@modelcontextprotocol/server-github"
          ],
          "env": {
            "GITHUB_PERSONAL_ACCESS_TOKEN": "発行したアクセストークン"
          }
        }
      }
    }
    

    それでは次回のブログでは開発からPRの自動化を行いたいと思います!

    tech.nri-net.com


    *1:https://modelcontextprotocol.io/introduction

    *2:図上ではロゴを削除しています

    執筆者 松澤武志

    2025 Japan AWS Jr. Champion
    趣味でAWSをいじるネイティブアプリエンジニア(.NET/C#/Java/Angular)

    ・執筆記事一覧: https://tech.nri-net.com/archive/author/t-matsuzawa
    ・X:https://x.com/2357_takeshi
    ・Speaker Deck:https://speakerdeck.com/matsuzawatakeshi