⛳
Amazon Q Developer CLIにAWS Knowledge MCP Server設定してみた

2025/10/04に公開
AWS
Model Context Protocol
Amazon Q
Amazon Q CLI
tech
 はじめにAWS Knowledge MCP ServerがGAとなった。
https://aws.amazon.com/jp/about-aws/whats-new/2025/10/aws-knowledge-mcp-server-generally-available/
Amazon QはAWSドメインエキスパート能力を持つので、改めてAWS Knowledge MCP Serverを連携する必要があるのか疑問に思ったので調査してみました。

 検証の背景AWS更新でAmazon Qはこのように紹介されている。
Amazon Q と会話を開始して、AWS の新しい機能を詳しく確認し、リソースを確認するとともに、請求書を分析して、ソリューションを設計しましょう。Amazon Q は、AWS Well-Architected パターン、ドキュメント、ソリューション実装などの領域におけるエキスパートです。
Amazon QはAWSドメインエキスパートであると説明されているので、AWSに関する疑問や支援をQにやってもらうと捗りそうなのは想像がつく。
AWS Knowledge MCP Server enables MCP clients and agentic frameworks supporting MCP to anchor their responses in trusted AWS context, guidance, and best practices.
いや、Amazon Q DがAWSドメインエキスパートなんだし、これは他のエージェント向けの話？

調べててもよくわからないので、実際に使ってそのメリットを実感しよう！となったわけです。

 環境構築まず、AWS公式のナレッジMCPサーバサイトを参考にMCPを設定していきます。
ご使用のクライアントがMCPのHTTPトランスポートをサポートしていない場合、またはセットアップ中に問題が発生した場合は、fastmcpユーティリティを使用してstdioからHTTPトランスポートへのプロキシを行うことができます。このカテゴリに該当するクライアントには、KiroやQ CLIなどがあります。以下はfastmcpユーティリティの設定例です。
Q CLIはリモートMCPサーバサポートを発表したはずなのですが、この説明だとFastMCPじゃないとダメそうなので、指示に従ってFastMCPで設定しました。
vi ~/.aws/amazonq/mcp.json
公式サイトのFastMCPの設定をそのままコピー
{
  "mcpServers": {
    "aws-knowledge-mcp-server": {
      "command": "uvx",
      "args": ["fastmcp", "run", "https://knowledge-mcp.global.api.aws"]
    }
  }
}
その後qコマンドでQ CLIを立ち上げると、無事MCPサーバが読み込まれて設定できていることが確認できました。

 検証まずMCPサーバを設定する前のQ CLIにAuroraのモニタリングについて質問してみました。
> Aurora for PostgreSQLのモニタリングダッシュボードやアラートを設計したい。何を設定すればいいのかわからないので、ベストプラクティスを教えてください。

> Aurora PostgreSQLのモニタリングとアラート設計について、重要なメトリクスとベストプラクティスを説明します。

## 監視すべき主要メトリクス

パフォーマンス関連
• DatabaseConnections - 接続数の監視
• CPUUtilization - CPU使用率
• FreeableMemory - 使用可能メモリ
• ReadLatency / WriteLatency - 読み書きレイテンシ
• ReadThroughput / WriteThroughput - スループット
• ReadIOPS / WriteIOPS - IOPS

可用性関連
• DatabaseConnections - 最大接続数に対する使用率
• ReplicaLag - リードレプリカの遅延
• AuroraReplicaLag - Auroraレプリカの遅延

ストレージ関連
• VolumeBytesUsed - ストレージ使用量
• VolumeReadIOPs / VolumeWriteIOPs - ボリュームIOPS

## 推奨アラート設定

クリティカル（即座に対応が必要）
CPUUtilization > 80% (5分間継続)
DatabaseConnections > 最大接続数の90%
ReadLatency > 200ms または WriteLatency > 100ms
FreeableMemory < 使用可能メモリの10%


警告（監視が必要）
CPUUtilization > 60% (10分間継続)
DatabaseConnections > 最大接続数の70%
ReplicaLag > 30秒
ReadLatency > 100ms または WriteLatency > 50ms


## CloudWatchダッシュボード構成例

概要ダッシュボード
• CPU使用率（時系列）
• 接続数（時系列）
• レイテンシ（読み書き別）
• スループット（読み書き別）

詳細ダッシュボード
• IOPS（読み書き別）
• メモリ使用量
• ストレージ使用量
• レプリカ遅延

## 実装のベストプラクティス

アラート通知
• SNSトピックを使用してSlack/メール通知
• 重要度別に通知先を分ける
• アラート疲れを避けるため閾値を適切に設定

ダッシュボード設計
• 役割別（開発者/運用者）にダッシュボードを分ける
• 時間範囲を複数用意（1時間/1日/1週間）
• 異常値を素早く特定できるよう色分けを活用

監視の自動化
• CloudFormationやTerraformでアラート設定を管理
• 定期的な閾値の見直しとチューニング
• ログ分析と組み合わせた包括的な監視

これらの設定により、Aurora PostgreSQLクラスターの健全性を効果的に監視できます。環境や要件に応じて閾値を調整してください。
さすがAWSのAI、それらしい提案してくれる。

MCP連携後は
>  Aurora for PostgreSQLのモニタリングダッシュボードやアラートを設計したい。何を設定すればいいのかわからないので、ベストプラクティスを教えてください。

> Aurora PostgreSQLのモニタリングとアラート設計について、重要なメトリクスとベストプラクティスを説明します。

## 監視すべき主要メトリクス

パフォーマンス関連
• DatabaseConnections - 接続数の監視
• CPUUtilization - CPU使用率
• FreeableMemory - 使用可能メモリ
• ReadLatency / WriteLatency - 読み書きレイテンシ
• ReadThroughput / WriteThroughput - スループット

可用性関連
• AuroraReplicaLag - レプリカラグ
• DatabaseConnections - 接続可能性
• EngineUptime - エンジン稼働時間

ストレージ関連
• AuroraVolumeBytesLeftTotal - 残り容量
• VolumeReadIOPs / VolumeWriteIOPs - IOPS使用量

## 推奨アラート設定

## 具体的なアラート閾値の推奨設定

Critical（緊急）
• CPUUtilization > 80% (5分間継続)
• DatabaseConnections > 最大接続数の90%
• FreeableMemory < 100MB
• AuroraReplicaLag > 30秒

Warning（警告）
• CPUUtilization > 70% (10分間継続)
• DatabaseConnections > 最大接続数の75%
• ReadLatency / WriteLatency > 200ms
• FreeableMemory < 500MB

## ダッシュボード設計のベストプラクティス

レイアウト構成
1. 概要セクション - 全体的な健全性指標
2. パフォーマンス - CPU、メモリ、接続数
3. レイテンシ - 読み書き応答時間
4. スループット - IOPS、ネットワーク
5. レプリケーション - ラグ、可用性

重要なポイント
• WRITERとREADERロール別にメトリクスを分離
• Performance Insightsメトリクスも併用
• 時系列グラフは最低1時間、理想的には24時間表示
• アラーム状態を視覚的に表示

## 実装例（CloudWatch Alarm）

bash
# CPU使用率アラーム
aws cloudwatch put-metric-alarm \
  --alarm-name "Aurora-CPU-High" \
  --alarm-description "Aurora CPU utilization is high" \
  --metric-name CPUUtilization \
  --namespace AWS/RDS \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --dimensions Name=DBClusterIdentifier,Value=your-cluster-name \
  --alarm-actions arn:aws:sns:region:account:topic-name

# 接続数アラーム
aws cloudwatch put-metric-alarm \
  --alarm-name "Aurora-Connections-High" \
  --alarm-description "Aurora connection count is high" \
  --metric-name DatabaseConnections \
  --namespace AWS/RDS \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --dimensions Name=DBClusterIdentifier,Value=your-cluster-name


## 追加の監視ツール

• **Performance Insights** - クエリレベルの詳細分析
• **Enhanced Monitoring** - OS レベルメトリクス
• **Database Activity Streams** - セキュリティ監査
• **DevOps Guru for RDS** - 異常検知とML分析

これらの設定により、Aurora PostgreSQLの包括的な監視体制を構築できます。
ナレッジMCPサーバを設定することで、より具体的な設定例まで推奨してくれるようになりました。

ただ、なぜかもうすぐEoLのPerformance Insightを提案してきたので、ツッコミを入れると、いやいやそんなはずは・・・あ、確かにマネコンで使えなくなるね・・・。みたいな反応示してきて可愛かった。API生きるとか微妙なのでこういう反応だったのかもしれません。
そもそも、普段Claude Code使っていると、Web検索で情報補完し精度の高い回答をしてくれるのですが、Q CLIはMCPを設定しないと外部からナレッジを収集しないよう設計されているようでした。
確かに、AWSの公式ブログでは、Amazon Q CLIのMCP(Model Context Protocol)サポートについて以下のように説明されており、MCPを使うことで初めて外部データソースを取得すると説明がありました。
https://aws.amazon.com/jp/blogs/news/extend-the-amazon-q-developer-cli-with-mcp/
開発者は MCP サポートを使用して外部データソースを Amazon Q Developer CLI に接続し、よりコンテキストを意識した応答を得ることができます。MCP ツールとプロンプトを Amazon Q Developer CLI に統合することで、事前構築された幅広い統合リストや、stdio をサポートするあらゆる MCP サーバーにアクセスできるようになります。
これはアクセス先を制限することでセキュリティとかソースの質とかを気にしているのかな？と思ってQ CLIに質問したところ、推測ですが似たような回答を返してきました。
> Amazon Q CLIがWeb検索機能を標準搭載していない理由について、公式ドキュメントには明確な設計ポリシーの記載がありません。

ただし、Q CLIの設計思想から推測できる要因をいくつか挙げることができます：

## 現在のQ CLIの設計アプローチ

専門性重視のツール構成
• AWS特化のツール（use_aws）
• ローカル開発環境との統合（fs_read、fs_write、execute_bash）
• AWS公式ドキュメント検索（aws___search_documentation、aws___read_documentation）

信頼性とセキュリティ重視
• 各ツールに詳細な権限設定が可能
• 実行前の確認プロンプト機能
• ローカル環境への影響を制御可能

## Web検索機能がない理由（推測）

1. 情報の信頼性
• AWSに特化した正確な情報提供を優先
• 公式ドキュメントからの確実な情報取得

2. セキュリティ考慮
• 外部への不要な通信を避ける
• 企業環境での利用を想定した設計

3. 専門性の維持
• AWS開発者向けツールとしての明確な位置づけ
• 汎用的な検索よりも専門的なAWSサポートに集中

## 代替手段

Q CLIでは以下の方法で外部情報にアクセス可能：
• AWS公式ドキュメント検索
• MCP（Model Context Protocol）サーバーによる拡張
• カスタムツールの追加

設計ポリシーの詳細については、公式ドキュメントに明記されていないため、より具体的な情報が必要でしたら、GitHubのissueで直接開発チームに質問
することをお勧めします。

参考リンク:
• [Built-in Tools](https://github.com/aws/amazon-q-developer-cli/blob/main/docs/built-in-tools.md)
• [Contributing Guidelines](https://github.com/aws/amazon-q-developer-cli/blob/main/CONTRIBUTING.md)
execute_bashツールがあるので、curlなどのコマンドを使って外部データソースにアクセスは可能なんですが、精度の高い情報を取得するのはちょっと難しい印象でした。
改めてQ CLIが持つツールを眺めると、AWSの開発・運用に限定・特化した機能を持っていることがわかります。

 まとめQ CLIはAWSの開発・運用に特化しており、外部データソースを絞っているので、安全で質の高い回答が得られると思います。確かな情報源を使ってより精度を高めたい・機能を拡張したければAWSの提供するMCPを設定する、そういった使い方を提案しているのだと感じました。
はじめに

検証の背景

環境構築

検証

まとめ

Discussion
