
【資料公開】 目指せ!Amazon Q & KIRO マスターへの道にて「Amazon Q Developer CLI カスタムエージェントを活用して設計レビューエージェントを作ってみた」というタイトルで登壇しました!
はじめに
こんにちは、コンサルティング部の神野です。
2025年8月7日に開催された「目指せ!Amazon Q & KIRO マスターへの道」にて、「Amazon Q Developer CLI カスタムエージェントを活用して設計レビューエージェントを作ってみた」というタイトルで登壇させていただきました!和気あいあいとした雰囲気で楽しく発表させていただきました!運営の皆様ありがとうございましたー!!
(Q Dev Tシャツに応募していなかったのが悔しい・・・)
みなさん、Amazon Q Developer CLIの新機能「カスタムエージェント」は使っていますか?
先日公開したブログ記事「Amazon Q Developer CLIのカスタムエージェント機能を使ってモノレポでの設計書レビューを効率化してみた」では、モノレポ環境でフロントエンドとインフラのレビュー用エージェントを作成する方法をご紹介しました。今回は、設計レビューに特化したエージェントを作成した話をご紹介します!
本記事ではざっくりとした話になるので、設定の詳細については下記ブログをご参照いただけますと幸いです。
登壇資料
なぜカスタムエージェントがあると嬉しいのか
バックエンド・フロントエンド開発どちらも掛け持ちしていると「テーブル」という言葉だけでもHTMLテーブルなのかSQLテーブルなのかAIが迷ってしまうみたいなケースがあるかと思います。直近の記事でも触れた「Amazon Q Developerが質問に対して混乱して、適切に回答できない、意図とは異なるMCPサーバーを使用するなどの問題」がまさにこれです。
私も大量にMCPサーバーの設定をした際に使用するMCPサーバーを混同してしまうケースに直面したことがあります。
カスタムエージェント機能を使えば、コンテキストに応じて最適なAIアシスタントに切り替えられるので、この課題解決を図ります。
q chat --agent front-end
のように切り替えるだけで、そのタスクに特化したエージェントが使用できます。エージェントごとに必要なツールや権限も制限できるのも嬉しいですよね。
設計レビューエージェントを作ろうと思ったきっかけ
IDE上の/review
コマンドはコードレビューは、Amazon Q Detector Libraryを参照してセキュアコーディングを進めていく上で素晴らしい機能なのですが、コードのみが対応しています。設計書のような文書をレビューする場合は、コンテキストを読み取ってレビューするようなプロンプトが別途必要でした。
そこで、設計書レビューに特化したエージェントを作成することにしました。AWS Well-Architected Frameworkの6つの柱を簡易的に意識したプロンプト設計と、MCPサーバー連携で最新情報を取得できる構成にしています。
今回のエージェントの特徴は、AWS Well-Architectedの専門家として振る舞い、MCPサーバー経由でリアルタイムの情報を取得しながらレビューしてくれることです。価格情報や公式ドキュメントの情報を取得して評価してくれるのは嬉しいですよね。
カスタムエージェント設定ファイル構成
スライドでも触れましたが、設定ファイルは基本的にMCPサーバー設定+エージェント固有の設定という構成です。MCP設定に加えて、resources
でコンテキストファイルを指定したり、prompt
でエージェントの専門性を定義できるのが魅力かと思います。
tools
で利用可能なツールを指定し、allowedTools
でユーザー確認なしで実行できる信頼済みツールを指定します。レビュー用途なら基本的には読み取り系のツールを信頼しておけば、スムーズにレビューしてくれます。
MCPサーバーの設定は従来と同じですが、このエージェント専用のサーバーだけを有効化できるのがポイントです。今回は設計レビューに特化するため、AWS関連のMCPサーバーのみを設定しています。
resources
でレビュー基準となるガイドラインファイルを自動で読み込むことができます。ホームディレクトリに自社のAWSガイドラインを置いておけば、全プロジェクト共通でそのルールに基づいてレビューするなどのユースケースで便利そうだなと感じました。
agentSpawn
フックでエージェント起動時に自動でプロジェクト情報を収集できます。レビュー対象ファイルの一覧を事前に取得しておくことで、「どのファイルをレビューしますか?」といった質問の手間を省くことも可能かと思います。
プロンプトでエージェントの専門性を定義します。今回はWell-Architectedの6つの柱に従う簡易的なレビューと、MCPサーバーを必ず使用するよう指示しています。
自社のレビューガイドラインがある場合は、ここに盛り込むことでチーム全体で統一されたレビューができそうです。
実際にレビューしてみた:ECサイト設計書
スライドでも紹介したサンプルECサイトの設計書で、通常レビューとカスタムエージェントの比較を実際に行いました。簡単な構成ですが、あえて問題点を含む設計にしてあります。
ECサイトシステム設計書 - 基本的なAWS構成
[ユーザー] → [CloudFront] → [ALB] → [EC2] → [RDS]
主要構成:
- EC2: t3.medium × 2台
- RDS: MySQL db.t3.medium
- 想定: 同時接続1,000人、ピーク時5,000人
- コスト見積もり: $135/月
通常のレビューでは基本的な改善点は指摘されるものの、優先度が不明確で具体性が不足していました。何も指示していないのでそれはそうですよね。
事前に指示をしたカスタムエージェントでは40/100と数値評価で明確にスコアを出し、重大で即座対応が必要な問題を赤色でハイライトしてくれました。
##### AWS Well-Architected Framework準拠度: 40/100
重大なリスクを発見しました!
##### 🔴 即座に対応が必要な重大問題
1. **信頼性**: RDS Single-AZ構成
- データベース障害時にサービス全停止
- 99%可用性目標に対してリスクが高すぎる
2. **セキュリティ**: 内部通信暗号化なし
- ALB-EC2間、EC2-RDS間がHTTP/平文通信
- 機密データの盗聴リスク
3. **セキュリティ**: WAF未設定
- SQLインジェクション、XSS攻撃リスク
##### 🟡 改善推奨(次期リリースで対応)
- **パフォーマンス効率**: ElastiCache Redis導入でAPI応答時間50%改善見込み
- **運用上の優秀性**: CI/CD パイプライン構築でBlue/Green デプロイメント
- **信頼性**: Auto Scaling設定でCPU使用率70%でスケールアウト
##### 🟢 適切な設計
- VPC設計(Multi-AZ配置)
- CloudFront + S3の静的コンテンツ配信
- RDS自動バックアップ設定
##### 💰 コスト分析・修正
設計書の見積もり検証:
```
元の見積もり: $135/月 → 過小評価を発見
```
修正後のコスト見積もり:
- EC2 Multi-AZ + RDS Multi-AZ: **$190/月**
- Reserved Instance適用後: **$140/月**
- **年間$648の節約機会**
##### 🚀 段階的改善ロードマップ
- **Phase 1 (即座)**: RDS Multi-AZ化、WAF導入
- **Phase 2 (1-2ヶ月)**: ElastiCache、Auto Scaling
- **Phase 3 (3-6ヶ月)**: Reserved Instance、監視強化
スライドでも比較した通り、カスタムエージェントを使って自分が定めた指標やレビュー基準に従って「数値評価」「優先度の明確化」「具体的な実装提案」「コスト分析」などをクイックに実現可能になりました!明確にやりたいことやアウトプットの形式をかっちり決めたい、かつ複数人で同じ設定を使いたい場合はエージェント化すると便利そうですね。
専門性に特化した5つのレビューエージェントも作成しました。q chat --agent security-review
のように、目的に応じて簡単に切り替えられるのが便利ですね。
1エージェントに多くの役割を与えすぎると回答が浅くなる可能性もあるので、スコープを狭くして切り替えて使用するのも面白いかなと感じました。
実際に使ってみた感想・まとめ
今回はAmazon Q Developer CLIのカスタムエージェント機能を使って、設計レビューに特化したエージェントを作成しました!
MCPサーバーをたくさん設定するとAIがMCPサーバーの設定に混乱することがあったので、役割に応じてカスタムエージェントを切り替えられるのはより効果的な回答を得られるのでいいと思いました!
よく使う設定はカスタムエージェント化しておくとプロジェクトが切り替わっても汎用的に使えますし、設定はGitを活用してチームでも共有できるので、チームメンバーが同じエージェントを活用してレビューを生成AIで行いたい際に導入するのも有効だと思いました。
これからカスタムエージェントどんどん試していきます!!!
本記事が少しでも役に立ったら幸いです!最後までご覧いただきありがとうございましたー!