GitHub と Amazon Q Developer が統合されたので、GitHub MCP経由で使ってみる

Last updated at 2025-05-07Posted at 2025-05-07

はじめに

GitHub と Amazon Q Developer が統合されたので、実際に触ってみました。どうやらGitHubにIssueを作成すると、Amazon Q Develperが勝手にコーディングからプルリクエストまで作業してくれるようです。

今回は、GitHub MCPにIssueを作ってもらい、Issueを元にAmazon Q Develperが作業すれば、いい感じになるのでは？というお試しになります。

2025/05/07時点でプレビュー機能になりますので、ご注意ください。

Amazon Q Develper とは

Amazon Q Develpeは、AWSが提供する開発アシスタントAIです。
今回で言うとコーディングの支援やコードレビューをしてくれます。

GitHubに統合されたAmazon Q Develperの機能

Amazon Q development agent
- Issueを作成し、タグに「Amazon Q development agent」と指定すると、AIエージェントがコーディングして、プルリクエストまで作成してます
Amazon Q code review agent
- プルリクエストが作成されると、AIエージェントが自動的にコードレビューを実施してくれます
- レビュー結果に返信する形でAIエージェントにコード修正をお願いすることもできます
Amazon Q transform agent (本記事では使わないです)
- Issueを作成し、タグに「Amazon Q transform agent」と指定すると、AIエージェントがコードに含まれるJavaのバージョンを上げてくれます

GitHub MCPとは

GitHub MCPは、MCPというプロトコルを使用しており、AIエージェントがGitHubを操作してくれます。(超ざっくり)

MCPについては下記の記事を参照

試してみる

今回はTODOを管理するWebシステムを作ろうとしてみます。

下記の環境で実施しました。

VSCode
GitHub Copilot
- モデルはClaude Sonnet 3.7を使用

1. 事前準備

GitHub Q Developer 統合の準備

下記を元に設定を行います。

GitHub MCPの準備

下記を元に設定を行います。

ちなみにVSCodeのsetting.jsonは、以下となります。

setting.json

{
  "mcp": {
    "servers": {
      "github": {
        "command": "npx",
        "args": [
          "-y",
          "@modelcontextprotocol/server-github"
        ],
        "env": {
          "GITHUB_PERSONAL_ACCESS_TOKEN": "GitHub APIキー"
        }
      }
    }
  }
}

2. プロンプトの作成

GitHub MCPに対応してもらいたい作業内容をマークダウンに書き溜めていきます。

ポイント

設計や開発ルールもIssue化し、期待するアウトプットは明確に
- 意図：Amazon Q Developerの作業内容を出来る限り具体的にしたかった
Issueの粒度を開発や設計ごとに分割
- 意図：役割分担を明確にしたかった。1つのIssueに情報を詰め込むと、情報過多でAmazon Q Developerが混乱しそうだったので...

# あなたの役割
- Webシステムを開発するプロジェクトのリーダーです
- Webシステムの開発に必要な情報を収集し、プロジェクトメンバーに指示を出します
- プロジェクトメンバーは、あなたの指示に従って、システムの設計や実装を行います
- あなたは、Webシステムの品質に責任を持ちます

# Webシステムの要件
## 使用技術
### インフラ
- AWS
- CDK
- AWSサービスは、基本的にはサーバレスアーキテクチャで実現する
### フロントエンド
- React
- TypeScript
### バックエンド
- Node.js
- TypeScript

## 機能要件
- 以下のユーザー認証を実現すること
    - ユーザーは、Webシステムからサインアップして、ユーザー登録できること
    - ユーザーは、ログインしてWebシステムにアクセスできること
    - ユーザーは、Webシステムからログアウトできること
- ユーザーはログイン後、以下の機能を利用できること
    - TODOを一覧で参照できること
    - TODOを新規追加できること
    - TODOは、複数件まとめて削除できること
    - TODOは、1件ずつ変更できること
    - TODOは、下記の情報を含むこと
        - TODOのタイトル
        - TODOの詳細
        - TODOのステータス

## 非機能要件
- デザインはマテリアルデザインとすること
- 簡素でシンプルなアーキテクチャとすること

# 依頼事項
下記の開発方法に従いWebシステムの要件を満たすWebシステムを完成させてください。

# 開発方法
GitHubのIssue駆動で開発します。下記の手順に従ってください。

## 1. リポジトリの作成
### リポジトリを作成する
- プライベートで作成すること
- 名前は任意とすること

### 「dev」ブランチを新たに作成する
- 最初は空の状態なので、README.mdを始めに追加してください

## 2. Issueの作成
後述する「Issueの作成ルール」に従って、Issueを作成してください。

# Issueの作成ルール
## 共通ルール
- Issueには必ず以下のラベルを指定してください
    - Amazon Q development agent
- 通知はオフに設定してください

## 設計用のIssueの作成
- 設計用のIssueを１つ作成してください
- 開発者のインプット情報となるため、できるだけ詳細に記載してください
- Issueには必ず以下の各種設計を記述してください

### アーキテクチャ設計
前述した「使用技術」からアーキテクチャ設計を行いIssueに記述してください。
#### フォーマット
- 使用技術
    - 使用するAWSサービスを記述してください
    - フロントエンド、バックエンドのライブラリやフレームワークを記述してください
- アーキテクチャ図
    - Mermaidでアーキテクチャ図を記載してください
- フロントエンド、バックエンド開発への要求事項や制限事項

### フロントエンド設計
フロントエンドの作業者に開発してもらうための設計を記載してください

#### 前提
- アーキテクチャ設計、バックエンド設計と整合性が取れるように設計してください

#### フォーマット
- 機能仕様
    - Webシステムの要件から詳細化して、フロントエンドが満たすべき機能仕様を記述してください
- 画面一覧
- 画面遷移
- 画面詳細仕様書
    - 画面毎の部品や部品の動作を記載してください
- バックエンドAPIへの要求事項

#### バックエンド設計
バックエンドの作業者に開発してもらうための設計を記載してください

#### 前提
- アーキテクチャ設計、フロントエンド設計と整合性が取れるように設計してください

#### フォーマット
- 機能仕様
    - Webシステムの要件から詳細化して、バックエンドが満たすべき機能仕様を記述してください
- DB定義書
- API仕様書

## 開発準備用のIssueを作成する
Issueに開発ルールを記載してください

### フォーマット
- インフラ
    - コーディングルール
    - 静的解析
    - 単体テスト
- フロントエンド
    - コーディングルール
    - 静的解析
    - 単体テスト
- バックエンド
    - コーディングルール
    - 静的解析
    - 単体テスト

## 開発用のIssueを作成する
### 作成するIssueの種類
- インフラ
- フロントエンド
- バックエンド
- CI/CD

### フォーマット
- インプット情報
    - 設計用のIssueのリンクを記載してください
- 役割
    - 担当領域(フロントエンド、バックエンド、インフラ)を記載してください
- 依頼事項
    - 設計用のIssueを参照し、設計に沿って開発を行う旨を記載してください
- 期待するアウトプット
    - ソースコード
        - devブランチを使用してください

3. GItHub MCPから、プロンプトを実行

VSCodeのGitHub Copilotから下記のプロンプトを実行します。

プロンプト.mdを元に作業してください

GitHub Copilotとのやり取りはこちら

プロンプト.mdの内容から、Webシステム開発のプロジェクトを進めるために作業を始めたいと理解しました。このドキュメントでは、GitHubでのIssue駆動の開発フローを実践するよう指示されています。まずはリポジトリの作成から始めましょう。

1. GitHubリポジトリの作成

GitHubにプライベートリポジトリを作成します。リポジトリの作成に成功しました。「todo-web-app」という名前のプライベートリポジトリが作成されました。

次に、「dev」ブランチを作成し、README.mdを更新します。リポジトリは正常に作成できましたが、「dev」ブランチの作成が失敗しました。これは、リポジトリが完全に空の状態であるためです。まずはメインブランチにREADME.mdファイルを追加してから「dev」ブランチを作成する必要があります。

まず、README.mdファイルの内容を作成し、リポジトリに追加しましょう：リポジトリの作成に成功し、README.mdファイルも追加できました。次に「dev」ブランチを作成しましょう。リポジトリと「dev」ブランチの作成が完了しました。リポジトリ名は「todo-web-app」で、最初のREADME.mdファイルも追加しました。

次に、プロンプト.mdに従って必要なIssueを作成していきます。まず設計用のIssueから作成します。

2. 設計用のIssueの作成

アーキテクチャ設計、フロントエンド設計、バックエンド設計を含む設計用のIssueを作成します。設計用のIssueを作成しました。このIssueには以下の内容が含まれています：

アーキテクチャ設計：
- 使用するAWSサービス（Cognito、API Gateway、Lambda、DynamoDBなど）
- フロントエンド技術（React、TypeScript、Material-UI）
- バックエンド技術（Node.js、TypeScript、AWS SDK）
- Mermaidで作成したアーキテクチャ図
- 開発要求事項と制限事項
フロントエンド設計：
- 機能仕様（認証機能、TODO管理機能）
- 画面一覧と画面遷移図
- 画面詳細仕様書（各画面のコンポーネントと動作）
- バックエンドAPIへの要求事項
バックエンド設計：
- 機能仕様（認証機能、TODO管理機能）
- DynamoDBのテーブル設計とインデックス
- 詳細なAPI仕様書（エンドポイント、リクエスト、レスポンス）

次に、プロンプト.mdに従って開発準備用のIssueを作成します。このIssueには開発ルールを記載します。開発準備用のIssueも作成できました。この「開発ルールと環境構築ガイドライン」というIssueには、以下の内容が含まれています：

インフラの開発ルール：
- AWS CDKのコーディング規則
- リソース命名規則
- 静的解析とテストの方針
フロントエンドの開発ルール：
- ファイル構造の推奨パターン
- 命名規則とコーディングスタイル
- React/TypeScriptの使用方針
- 静的解析とテスト手法
バックエンドの開発ルール：
- Lambda関数の構成方法
- コーディングスタイルと命名規則
- エラーハンドリングとDynamoDB操作のベストプラクティス
- テスト戦略
CI/CD設定：
- GitHub Actionsのワークフロー概要
- PR時の検証とデプロイプロセス
環境構築手順：
- ローカル開発環境のセットアップ方法
- AWS環境の準備手順

続いて、プロンプト.mdに従って、各開発領域（インフラ、フロントエンド、バックエンド、CI/CD）のIssueを作成していきます。まずはインフラ開発用のIssueから作成します：インフラストラクチャ開発タスクに関するIssueを作成しました。このIssueでは、AWS CDKを使用したサーバーレスアーキテクチャの構築に必要な項目を詳細に記載しています。次に、フロントエンド開発のためのIssueを作成しましょう。フロントエンド開発タスクのIssueも作成できました。このIssueでは、React、TypeScript、Material UIを使用したTODOアプリケーションの実装に必要な項目を詳細に記載しています。

次に、バックエンド開発のためのIssueを作成しましょう：バックエンド開発タスクのIssueも作成できました。このIssueでは、Node.js、TypeScript、AWS Lambdaを使用したバックエンドAPIの実装に必要な項目を詳細に記載しています。

最後に、CI/CD開発タスク用のIssueを作成しましょう：すべてのIssueの作成が完了しました。プロンプト.mdに従って、GitHubリポジトリとIssue駆動開発の準備が整いました。以下にこれまでに完了した作業の概要をご説明します：

1. リポジトリの作成と設定

リポジトリの作成
- リポジトリ名: todo-web-app
- 説明: サーバーレスアーキテクチャを使用したTODOアプリケーション
- プライベートリポジトリとして作成しました
README.mdの追加
- プロジェクトの概要、技術スタック、主な機能などを記載したREADME.mdを作成しました
devブランチの作成
- mainブランチからdevブランチを作成しました
- 今後の開発はこのブランチで行われます

2. Issue駆動開発のためのIssue作成

プロンプト.mdに指定されていた通り、以下のIssueを作成しました：

設計用Issue (#1) 「Webシステム設計：アーキテクチャ、フロントエンド、バックエンドの設計」
- アーキテクチャ設計（AWSサービス、Mermaid図）
- フロントエンド設計（画面一覧、画面遷移図、画面詳細仕様）
- バックエンド設計（API仕様、DB定義）
開発準備用Issue (#2) 「開発ルールと環境構築ガイドライン」
- インフラ、フロントエンド、バックエンドそれぞれのコーディングルール
- 静的解析のルール
- 単体テストのルール
- 環境構築手順
インフラストラクチャ開発タスク (#3)
- AWS CDKを使用したサーバーレスインフラの構築
- Cognito、API Gateway、Lambda、DynamoDB、S3、CloudFrontなどの設定
フロントエンド開発タスク (#4)
- React + TypeScript + Material UIによる画面実装
- 認証機能、TODO管理機能などの実装
バックエンド開発タスク (#5)
- Node.js + TypeScript + AWS Lambdaによるバックエンド実装
- 認証、TODO管理APIの実装
- DynamoDBとの連携
CI/CD構築タスク (#6)
- GitHub Actionsを使用したCI/CDパイプラインの構築
- PR検証、デプロイ自動化、環境管理

各Issueには「Amazon Q development agent」ラベルを適用し、設計用Issueや開発ルールへの参照リンクを含めています。

これらのIssueをもとに、開発チームは順次実装作業に取り掛かることができます。最初に設計Issue (#1) と開発ルールIssue (#2) を参照して、各開発タスク (#3～#6) に取り組むフローとなります。すべての開発作業はdevブランチで行われ、最終的にはmainブランチにマージされる予定です。

これでプロンプト.mdに記載されていた「リポジトリの作成」と「Issueの作成」のステップが完了しました。次のステップとして、これらのIssueに基づいて実際の開発作業に進むことができます。

4. GitHubから実行結果を確認

GitHubのIssueを確認すると期待通り作成されています。ここはGitHub MCPのお仕事です。

GitHubのリポジトリは公開しておくので、どんな内容になったかは以下を参照ください。

設計や開発ルールの確認

Issueの内容

流石のClaude Sonnet 3.7ということで、かなり具体的に書いてくれています。
アーキテクチャ図は、以下のようなMermaidで書いてもらっていますが、まあまあ分かりやすいです。

Pullリクエスト

設計の方は、期待値と異なり、フロントエンドが実装されちゃってます。(Readmeを更新してくれるのは嬉しいが...)

開発ルールの方は、特に指示してませんでしたが、開発ガイドラインとしてプルリクエストを作成してくれました。

インフラの確認

Issueの内容

無事にプルリクエストまでいってるようです。

Pullリクエスト

いくつか指摘があるようです。以下GitHub MCPにまとめてもらいましたが、セキュリティ系の指摘が多いですね。

カテゴリ	指摘内容	対策
セキュリティ	NoSQLインジェクションの可能性（JSON.stringifyの使用において）	JSON.stringify()の使用時に追加パラメータを設定し、安全なJSONシリアライズを実装する（JSON.stringify(appConfig, null, 2)）
セキュリティ	S3バケットが転送時の暗号化（SSL）を強制していない	S3バケット設定に「enforceSSL: true」を追加し、SSL接続を強制する
エラーハンドリング	リソース作成や構成の潜在的な失敗に対するエラーハンドリングが実装されていない	try-catchブロックを導入し、リソース作成処理をラップして適切なエラーロギングと例外処理を実装する

またCDKでインフラのコードを書いてもらいましたが、frontendのスタック作りすぎでは...?
恐らく、コードレビューの結果から自動的に修正してくれているのですが、修正前も残すようです。(プロンプトでルール決めた方がよいかも)

フロントエンドの確認

Issueの内容

無事にプルリクエストまでいってるようです。

Pullリクエスト

プルリクエストを見ても特に問題は起きていないようですね。

ソースコードを見てましたが、なんか全体的に使ってるOSSが古い...

Reactは19系使ってほしい
create-react-appでなく、Viteなどのツールを使ってほしい

多分、設計時のバージョン指定から古いかったようです。フロントエンドはOSSのアップデートが早いので、自身で定義してあげた方が良さそうです。

また、開発ルールで単体テストや静的解析を決めたつもりですが、テストコードまでは書いてくれませんでした。Issueで明示的に単体テストのコードを書いてとは言ってなかったので反省です。

バックエンドの確認

Issueの内容

バックエンドも無事にプルリクエストまでいってるようです。

Pullリクエスト

Pullリクエストは、結構、指摘が出ていますね。

以下GitHub MCPにまとめてもらいました。セキュリティ系の指摘が多いですね。コード品質とかは、実装するときに意識してほしいところですが...今後のAmazon Q Developerに期待という感じでしょうか。

カテゴリ	指摘内容	対策
セキュリティ	環境変数が設定されていない場合の空文字列フォールバックによる実行時エラーリスク	環境変数の存在確認と未設定時の明示的なエラー処理
セキュリティ	エラーハンドリングが一般的すぎて内部エラー情報が外部に露出する可能性	エラータイプに応じた例外処理と安全なエラーメッセージの実装
セキュリティ	ユーザー入力がサニタイズされずにログに記録される（ログインジェクション）	ログ出力前のユーザー入力サニタイズ
セキュリティ	エラー内容全体をログに記録することで機密情報が漏洩する可能性	構造化ログ記録と機密データのマスキング
セキュリティ	データベースクエリでの入力検証不足（NoSQLインジェクション）	入力検証とパラメータ化されたクエリの使用
アクセス制御	バッチ削除メソッドが実行前にTODOの所有権を確認していない	削除前のアイテム所有権確認バリデーション追加
エラーハンドリング	汎用的なエラーハンドリングによるユーザー向け情報の不足	エラータイプごとのカスタムエラーメッセージ
エラーハンドリング	エラーメッセージの詳細度とセキュリティのバランス問題	環境別（開発/本番）のエラー詳細度調整
コード品質	ユーザー入力やAPIリクエストの検証が不十分	すべての入力に対する適切なバリデーション実装
コード品質	エラーログの内容が標準化されていない	構造化されたロギング方式の採用

CI/CDの確認

Issueの内容

うーむ、技術的課題が発生して、Amazon Q Developerが止まっちゃってます。
課題の内容も教えてくれないので、どうしたものか。

Pullリクエスト

Amazon Q Developerが止まっちゃってるので、Pullリクエストはありませんでした。

まとめ

Amazon Q Developerを活用することで、プロンプトのみでプルリクエストまでの一連の作業を自動化できることが確認できました。ただし、Amazon Q Developerでエラー発生時の理由が明示されないというのは困りますね。

効果的だった点

開発効率の向上

プロンプト入力だけでプルリクエストまでの自動生成が可能
自動コードレビュー機能による品質担保できる

GitHub MCPが便利

Issueを１つずつ自分で作ってもいいですが、GitHub MCPが作ってくれたので楽ちん

反省点

プロンプトの明確化

単体テストコードなどのアウトプットはIssueに明示的に記載した方が良い
OSSライブラリは使用バージョンを明確に指定した方が良い

今後の展望

コーディングルールやデザインシステムといったノウハウ系を蓄積したい

AIが参照できるノウハウを蓄積しておけば、求める品質に近づけそう
プロンプトを毎回作るのもしんどいので、参照できるようにしたい

他のMCPサーバーを活用したい

アーキテクチャ図は「AWS Diagram MCP Server」の活用もあり
Amazon Q DeveloperがMCP使えれば、評価に「Playwright MCP Server」、デザインシステムの参照に「Figma MCP Server」を使えそう

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up