Amazon Q Developer CLI カスタムエージェントを活 用して設計レビューエージェントを作ってみた 目指せ！Amazon Q & KIRO マスターへの道 2025/08/07 クラスメソッド株式会社 神野雄大 

自己紹介 推しスーパーはLAMUです 神野 雄大（Jinno Yudai） 所属 クラスメソッド株式会社 クラウド事業本部 コンサルティング部 ソリューションアーキテクト 資格 • 2025 Japan AWS Top Engineers • 2025 Japan All AWS Certifications Engineers 得意分野 • アプリケーション全体の設計・開発 • IoT 2 

早速ですがKiroちゃん可愛いよね。 

だけど今日はAmazon Q Developerちゃんについて話します・・・ 

みなさん Amazon Q Developer は使っていますか？？ 

最近面白いアップデートがありました！！ 

Amazon Q Developer のアップデート紹介 2025年7月30日 NEW! https://aws.amazon.com/jp/about-aws/whats-new/2025/07/amazon-q-developer-cli-custom-agents/ Amazon Q Developer CLI カスタムエージェント カスタマイズ可能なエージェントを CLI 内で作成 ✅ 特定のタスクに特化（コードレビュー、トラブルシューティングなど） ✅ 設定ファイルで以下を定義可能： ✅ エージェントが使用できるツール ✅ エージェントの動作を導くプロンプト ✅ タスク実行に必要なコンテキスト ✅ 7 

何が嬉しいの？？ 

例で考えてみる！ 

複数プロジェクトを掛け持ちする開発者の悩み 朝のスタンドアップでの一コマ... 「今日はフロントエンドのデザイン実装と、バックエンドのAPI開発と、インフラのコ スト最適化をやります」 でも実際は... 9:00 Figmaでデザインチェック → Amazon Q に「テーブルの実装方法は？」 10:00 DBスキーマ設計 → Amazon Q が HTMLテーブルの実装を提案... 11:00 「あれ？今どのプロジェクトのコンテキストだっけ？」 10 

同じ「テーブル」でも意味が違う問題 コンテキストスイッチングの混乱 デザイナーと話すとき → HTMLテーブル（UIコンポーネント） DBAと話すとき → SQLテーブル（データベース） 従来のAmazon Q Developerでは... AIが「どのテーブル？」を推測する必要があった → 期待した回答が得られないことが多々... 11 

カスタムエージェントが解決する コンテキストに応じて最適なAIアシスタントに切り替え # フロントエンド開発モード q chat --agent front-end → Figmaツール、React設定、デザインガイドが自動でロード # バックエンド開発モード q chat --agent back-end → PostgreSQLツール、Python設定、API仕様書が自動でロード → もう「どのコンテキストだっけ？」とか「プロンプトに明確に書かないと・・・」 と悩む必要なし！ 12 

セキュリティも考慮された設計 プロジェクトごとに適切な権限管理 フロントエンド： fs_write を信頼（UIコンポーネント生成OK） バックエンド： db_write は都度確認（本番DB保護） セキュリティレビュー：読み取り専用でセキュアに分析 事故防止にも貢献 設定ファイルで権限を明示的に定義 → 意図しない操作を防止 13 

設計レビューエージェントを作ろうと思ったきっかけ 

これまでのAmazon Q Developerを活用したレビュー 体験 IDE上で/review コマンドの活用 # セキュアコーディングの文脈でのコードレビュー /review セキュリティ観点: 脆弱性チェック、OWASP対応 コード品質: 可読性、保守性の向上 設計レビュー: アーキテクチャ・非機能要件の考慮不足 コンテキスト: プロジェクト固有ルールの適用困難 コードはビルトインコマンドでレビューできるがドキュメントなどはプロンプトやコ ンテキストを工夫する必要がある。 15 

ここでカスタムエージェントの活用を考える 設計書レビューに特化したエージェントを作成して、レビューに特化させてみる！！ 16 

design-reviewエージェントを作ってみた 

作成したdesign-reviewエージェントの特徴 目的 AWS非機能要件を中心とした設計書ドキュメントレビューの効率化 主要機能 AWS Well-Architected Framework準拠: 5つの設計原則に基づく包括的なレビュー MCP経由でリアルタイム情報取得: AWS公式ドキュメント、ナレッジベース、価格 情報 18 

カスタムエージェント設定ファイル構成 設定ファイルの基本構成 { "name": "エージェント名", "description": "エージェントの説明", "mcpServers": { /* MCP連携設定 */ }, "tools": [ /* 利用可能ツール */ ], "allowedTools": [ /* 許可するツール */ ], "resources": [ /* 静的ファイル */ ], "hooks": { /* 起動時処理 */ }, "prompt": "エージェントの振る舞いを定義" } 各設定項目の役割 基本情報: name , description でエージェントを定義 MCPサーバー連携: mcpServers でMCPサーバーの設定 権限制御: tools , allowedTools で操作可能範囲を制限 コンテキスト: resources , hooks で必要な情報を自動取得 振る舞い: prompt でエージェントの専門性を設定 19 

ツール権限制御：安全性を確保 tools と allowedTools の使い分け { "tools": ["*"], "allowedTools": [ "fs_read", "fs_write", "report_issue", "use_aws", "@aws-docs", "@aws-knowledge", "@aws-pricing" ] } 権限制御の仕組み tools: ["*"]: 有効なツールを指定。ここでは全ツールを有効へ。 allowedTools: 許可する操作を限定（許可することで承認が不要に） 主要ツールの分類 分類 ツール例 用途 ファイル操作 fs_read , fs_write 設計書読み込み・結果出力 AWS連携 use_aws AWS CLI実行 MCP連携 @aws-docs , @aws-knowledge 外部サービス呼び出し 20 

MCPサーバー設定：外部サービス連携 mcpServers に設定可能です。従来のMCP Serverの設定と一緒です。 mcpServers の設定パターン { "mcpServers": { "aws-docs": { "command": "uvx", "args": ["awslabs.aws-documentation-mcp-server@latest"] }, "aws-knowledge": { "command": "npx", "args": ["mcp-remote", "https://knowledge-mcp.global.api.aws"] }, "aws-pricing": { "command": "uvx", "args": ["awslabs.aws-pricing-mcp-server@latest"], "env": { "FASTMCP_LOG_LEVEL": "ERROR", "AWS_REGION": "ap-northeast-1" } } } } command: 実行コマンド（ uvx , npx など） args: サーバー指定（パッケージ名やURL） env: 環境変数（ログレベル、リージョンなど） 21 

リソース設定：コンテキストファイルの自動取得 resources の設定パターン { "resources": [ "file://~/.aws/amazonq/aws-nonfunctional-review-preferences.md", "file://~/.aws/amazonq/aws-well-architected-pillars.md", "file://**/*.md", "file://**/*.json", "file://**/*.yaml", "file://**/*.yml" ] } 活用例 設計ガイドラインの自動読み込み プロジェクト固有の設定書を常時参照なども可能！ 22 

フック設定：起動時の自動処理 agentSpawn で定義することで、起動時にコマンドを実行することができてコンテキストに含めることが可能です。 hooks の設定パターン { "hooks": { "agentSpawn": [ { "command": "find . -name '*.md' -o -name '*.json' -o -name '*.yaml' -o -name '*.yml' | head -10", "description": "レビュー対象ファイルの確認" }, ] } } agentSpawnフックの活用 用途 コマンド例 効果 状況確認 find . -name "*.md" 対象ファイルの一覧を認識 23 

プロンプト設計：エージェントの専門性を定義 WAを意識した簡易的なプロンプトを書いてみます。自社のガイドラインとかあればそこに従うようなプロンプト を書くのもレビューとしては便利かなと思います。 prompt の構成要素 あなたはAWS非機能要件を専門とする設計書レビューエキスパートです。 レビュー観点（AWS Well-Architected Framework準拠）: 1. **運用上の優秀性**: 運用の自動化、監視、継続的改善 2. **セキュリティ**: IAM、暗号化、ネットワークセキュリティ 3. **信頼性**: 可用性、障害復旧、Multi-AZ、Auto Scaling 4. **パフォーマンス効率**: レスポンス時間、スループット 5. **コスト最適化**: 適切なサイジング、価格モデル 6. **持続可能性**: 環境への影響最小化、エネルギー効率、リソース最適化 **MCP活用指針:** - AWS公式ドキュメントで最新のベストプラクティスを確認 - AWSナレッジベースで類似事例を検索 - AWS価格情報でコスト見積もりの妥当性を検証 具体的で実行可能な改善提案を提供してください 24 

MCPサーバー連携のメリット リアルタイムAWS情報取得 EC2インスタンス状況 Lambda関数設定 IAMポリシー詳細 VPC設定情報 セキュリティ向上 最新のリソース状態を反映 ベストプラクティスとの自動比較 設定ドリフトの検出 25 

実際にレビューしてみた：ECサイト設計書 レビュー対象 ECサイトシステム設計書 - 基本的なAWS構成 [ユーザー] → [CloudFront] → [ALB] → [EC2] → [RDS] 主要構成 EC2: t3.medium × 2台 RDS: MySQL db.t3.medium 想定: 同時接続1,000人、ピーク時5,000人 コスト見積もり: $135/月 26 

通常レビューの結果（エージェントなし） 基本的な改善点は指摘されるが... 良い点 システム概要と要件が明確 AWSサービスの選択が適切 基本的なセキュリティ考慮あり 改善が必要な点 スケーラビリティとパフォーマンス 高可用性の不備 セキュリティの強化 運用・監視の改善 データベース設計、CI/CDパイプライン、災害復旧 27 

design-reviewエージェントの結果 ① AWS Well-Architected Framework準拠度 40/100 - 重大なリスクを発見 即座に対応が必要な重大問題 1. 信頼性: RDS Single-AZ構成 データベース障害時にサービス全停止 99%可用性目標に対してリスクが高すぎる 2. セキュリティ: 内部通信暗号化なし ALB-EC2間、EC2-RDS間がHTTP/平文通信 機密データの盗聴リスク 3. セキュリティ: WAF未設定 SQLインジェクション、XSS攻撃リスク 28 

design-reviewエージェントの結果 ② 改善推奨（次期リリースで対応） パフォーマンス効率 ElastiCache Redis導入: API応答時間50%改善見込み 運用上の優秀性 CI/CD パイプライン構築: Blue/Green デプロイメント 信頼性 Auto Scaling設定: CPU使用率70%でスケールアウト 適切な設計 VPC設計（Multi-AZ配置） CloudFront + S3の静的コンテンツ配信 RDS自動バックアップ設定 29 

design-reviewエージェントの結果 ③ コスト分析・修正 設計書の見積もり検証 元の見積もり: $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、監視強化 30 

エージェント有無での比較 通常レビュー 一般的な改善点リスト 優先度が不明確 具体的な実装方法なし コスト分析なし 数値評価なし design-reviewエージェント 数値評価: 40/100 優先度明確: 分類 具体的提案: Multi-AZ、WAF設定 コスト修正: $135→$190→$140 実装ロードマップ: 3段階計画 感想：専門性を持たせてレビューするのにいいなと思いました！後は気軽に色々な役割に切り替えられるのも魅力 的だと思いました。 31 

他にも作成したエージェント群 専門性に特化した5つのレビューエージェント こんなのも作ってみました。1つずつの役割を明確にして与えて切り替えるのも手ですよね。 エージェント 専門分野 特徴 design-review 設計書全般 Well-Architected準拠 security-review セキュリティ 脅威分析・コンプライアンス cost-review コスト最適化 リアルタイム価格・削減提案 performance-review パフォーマンス ボトルネック検出・最適化 operations-review 運用・監視 自動化・SLA設計 使い分けの例 q chat --agent security-review # セキュリティ特化 q chat --agent cost-review # コスト最適化特化 q chat --agent performance-review # パフォーマンス特化 32 

まとめ 

実際に使ってみた効果・感想 MCPサーバーいっぱい設定すると使うAI側が混乱して、適切な判断をしてくれない 時があったので、役割に応じてカスタムエージェントを切り替えられるのはより 効果的な回答を得られるのでいいと思った。 よく使う設定はカスタムエージェント化しておくとプロジェクトが切り替わっても 汎用的に使えるし、設定はチームでも共有できるのでレビューなどに導入するの に使えると思った。 カスタムエージェントガンガン試していきます！！！ 34 

最後までご清聴いただきありがとうございました ー！！ 35 

参考までにレビュー結果の原文も載せています。 36 

参考：通常レビューの原文（エージェントなし） このECサイトシステム設計書をレビューしました。全体的に基本的な構成は整っていますが、いくつかの改善点があります。 良い点 • システム概要と要件が明確に定義されている • AWSサービスの選択が適切 • 基本的なセキュリティ考慮がされている • コスト見積もりが含まれている 改善が必要な点 1. スケーラビリティとパフォーマンス • ピーク時5,000同時接続に対してt3.medium×2台では不足する可能性 • Auto Scalingの設定が記載されていない • ElastiCacheの導入を検討すべき（セッション管理とキャッシュ） 2. 高可用性の不備 • RDSのMulti-AZ構成が明記されていない • データベースの読み取りレプリカの検討が必要 • 単一障害点の排除が不十分 37 

参考：通常レビューの原文（続き） 3. セキュリティの強化 • WAFの導入が記載されていない • VPCエンドポイントの活用 • セキュリティグループのより詳細な設定 • 暗号化設定（RDS、S3）の明記 4. 運用・監視の改善 • CloudWatch Logsの設定 • アラーム設定の詳細化 • X-Rayによる分散トレーシング • Systems Managerによる運用自動化 5. データベース設計 • インデックス設計の記載が不足 • パーティショニング戦略 • 接続プール設定 6. CI/CDパイプライン • CodePipeline、CodeBuild、CodeDeployの活用 • Blue/Greenデプロイメントの検討 38 

参考：通常レビューの原文（続き） 7. 災害復旧 • バックアップ戦略の詳細化 • 復旧手順の明記 • クロスリージョンバックアップの検討 推奨する追加検討事項 1. Amazon ECS/EKSの検討 - コンテナ化によるスケーラビリティ向上 2. Amazon API Gateway - APIの管理とスロットリング 3. Amazon SQS/SNS - 非同期処理とメッセージング 4. AWS Secrets Manager - 認証情報の安全な管理 この設計書は基本的な要素は含まれていますが、本格的な商用環境での運用を考慮すると、上記の改善点を検討することをお勧めします。 39 

参考：design-reviewエージェントの原文 ① 総合評価 AWS Well-Architected Framework準拠度: 40/100 設計書を詳細に分析した結果、基本的なアーキテクチャは理解されているものの、重大な可用性・セキュリティリスクが複数発見されました。 重大な問題（即座に対応必要） 1. 信頼性: RDS Single-AZ構成 問題: RDSがSingle-AZ構成でSingle Point of Failure • データベース障害時にサービス全停止 • 99%可用性目標に対してリスクが高すぎる 改善提案: RDS Multi-AZ構成への変更 db.t3.medium → Multi-AZ対応 自動フェイルオーバー（1-2分） 追加コスト: 約2倍だが可用性大幅向上 2. セキュリティ: 内部通信暗号化なし 問題: ALB-EC2間、EC2-RDS間がHTTP/平文通信 • 機密データの盗聴リスク • コンプライアンス要件違反の可能性 40 

参考：design-reviewエージェントの原文 ② 3. セキュリティ: WAF未設定 問題: Webアプリケーション攻撃に対する防御なし • SQLインジェクション、XSS攻撃リスク • DDoS攻撃への脆弱性 改善提案: AWS WAF + Shield Standard導入 OWASP Top 10対策ルール レート制限設定 地理的ブロッキング 改善推奨（次期リリースで対応） 4. 運用上の優秀性: 手動デプロイ 問題: GitHubから手動デプロイ、運用効率が低い 改善提案: CI/CD パイプライン構築 AWS CodePipeline + CodeDeploy Blue/Green デプロイメント 自動テスト統合 5. パフォーマンス効率: キャッシュ戦略なし 問題: データベース負荷が高く、レスポンス時間に影響 改善提案: ElastiCache Redis導入 41 

参考：design-reviewエージェントの原文 ③ 6. コスト最適化: Reserved Instance未検討 問題: On-Demand価格で見積もり、コスト効率が悪い 改善提案: Reserved Instance活用 1年契約で約40%コスト削減 月額$135 → $81（$54削減） 年間$648の節約 7. 信頼性: Auto Scaling未設定 問題: ピーク時（5,000同時接続）への対応が不明確 改善提案: EC2 Auto Scaling設定 Target Tracking Policy CPU使用率70%でスケールアウト 最小2台、最大8台 適切な設計 • VPC設計（Multi-AZ配置） • セキュリティグループの基本設定 • CloudFront + S3の静的コンテンツ配信 • RDS自動バックアップ設定 42 

参考：design-reviewエージェントの原文 ④ コスト最適化提案 現在の見積もり検証 設計書の$135/月は過小評価の可能性があります。 修正後の月額コスト見積もり: EC2 (t3.medium × 2): $67.2 RDS Multi-AZ (db.t3.medium): $80.0 ALB: $22.0 WAF: $5.0 + $1.0/ルール CloudFront: $10.0 S3: $5.0 合計: 約$190/月 Reserved Instance適用後: 約$140/月 43 

参考：design-reviewエージェントの原文 ⑤ 段階的改善ロードマップ Phase 1 (即座に実施) 1. RDS Multi-AZ化 2. WAF導入 3. 内部通信HTTPS化 Phase 2 (1-2ヶ月後) 1. ElastiCache導入 2. Auto Scaling設定 3. CI/CD パイプライン構築 Phase 3 (3-6ヶ月後) 1. Reserved Instance移行 2. 監視・アラート強化 3. 災害復旧計画策定 44 

参考：design-reviewエージェントの原文 ⑥ 次のアクション 1. 緊急: RDS Multi-AZ設定とWAF導入の技術検証 2. 重要: セキュリティ要件の詳細定義 3. 推奨: AWS Well-Architected Review実施 この改善により、可用性99.9%以上、セキュリティ強化、運用効率向上を実現できます。 45