こんにちは、エデュケーショナルサービス課 AWS トレーナーの小倉です。
過去に弊社のブログで何回か紹介されている Distributed Load Testing (分散負荷テスト) on AWS ですが、2025/11/19 に MCP サーバーの機能が追加されています。MCP サーバーを利用することにより、自然言語で問い合わせを行い、負荷テストの実行結果を分析することができます。今回はこの MCP サーバーを使って分析をしてみます。
Distributed Load Testing (分散負荷テスト) on AWS とは、ソリューションの一つで、公開されている CloudFormation テンプレートを実行するだけで、負荷テストを実行できる環境を作ることができます。構築手順は以下のブログに書かれていて、本ブログでは主に以下のブログと MCP サーバーとの差分を説明していきます。
MCP サーバーの構築方法
MCP サーバーを利用するためには、CloudFormation 実行時のパラメータで、Deploy MCP Server を Yes に変更するだけです。

Deploy MCP Server を Yes にして CloudFormation を実行すると、アーキテクチャ図の左側の MCP Server (Optional) の部分が構築されます。
引用:Distributed Load Testing on AWS 実装ガイド アーキテクチャの概要
負荷テストを実施
テストシナリオを作成するときには、Test Type を Single HTTP Endpoint、JMeter、K6、Locust から選ぶことができます。

EC2 に負荷テストを実施するときに事前申請は不要です。ただ、大量のトラフィックを流した場合は制御される可能性があるとのことです。2023 年ごろまでは 1 Gbps 以上のトラフィックなら申請が必要と記載されていたので、 1 Gbps の通信であれば問題ないかと考えています。
MCP サーバーの利用方法
MCP サーバーを利用する方法は以下のサイトに記載されています。
今回は Kiro CLI で実行します。
1. DLT ウェブコンソールからエンドポイント URL とアクセストークンを取得
DLT ウェブコンソールの左メニューの MCP Server をクリックします。Copy Endpoint URL と Copy Access Token をそれぞれクリックし、テキストにコピーしておきます。Access Token には有効期限があり、Expires At に書かれている時間まで利用できます。

2. Kiro CLI の設定と実行
Kiro CLI のMCP サーバーの設定は、~/.kiro/settings/mcp.json に記述します。記述の仕方は以下です。
url に Endpoint URL、Authorization に Access Token を入力して保存します。
{
"mcpServers": {
"dlt-mcp": {
"type": "http",
"url": "https://dlt-mcp-server-xxxxxxxxxx.gateway.bedrock-agentcore.ap-northeast-1.amazonaws.com/mcp",
"headers": {
"Authorization": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
}
}
Kiro CLI を起動して、dlt-mcp が読み込まれるかを確認します。
dlt-mcp loaded が表示されていれば読み込まれています。
~$ kiro-cli ✓ dlt-mcp loaded in 0.67 s
表示されない場合は、Kiro CLI を起動した後に /mcp を実行することで読み込まれているかを確認できます。
読み込まれない場合は、mcp.json の記述に問題がある可能性がありますので、記述内容の見直しをしてみましょう。
> /mcp dlt-mcp ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ [2026:16:22]: ✓ dlt-mcp loaded in 0.67 s
調査したい内容を確認してみます。今回はドキュメントに記載されている内容を日本語にして確認してます。
■プロンプト list_scenarios を使って負荷テストを見つけます。次に、get_latest_test_run を使って最新のテストの基本的な実行データとパフォーマンス指標を表示します。結果が気になる場合は、get_test_run を使って詳細なパフォーマンス指標も取得します。
■実行結果
> 負荷テストのシナリオを取得して、最新のテスト実行結果を確認します。
Running tool DltMcpToolsLambda___list_scenarios with the param (from mcp server: dlt-mcp)
⋮ {}
> 利用可能な負荷テストシナリオが2つ見つかりました:
1. test (Copy) (ID: 2iPcnawnyK)
- 説明: test
- ステータス: complete
- 総テスト実行数: 1
- 開始時刻: 2026-01-06 10:57:38
2. test (ID: jCttQ1ZdO0)
- 説明: test
- ステータス: complete
- 総テスト実行数: 1
- 開始時刻: 2026-01-06 10:43:43
最新のテスト実行結果を取得します:
Running tool DltMcpToolsLambda___get_latest_test_run with the param (from mcp server: dlt-mcp)
⋮ {
⋮ "test_id": "2iPcnawnyK"
⋮ }
> ## 最新のテスト実行結果
### テスト1: test (ID: jCttQ1ZdO0)
テスト実行ID: ry3LYOD9TI
- **期間**: 2026-01-06 10:43:43 → 10:51:57 (約8分)
- **ステータス**: complete
- **総リクエスト数**: 497,170
- **成功**: 489,095 (98.4%)
- **エラー**: 8,075 (1.6%)
- **RPS**: 1,651.7
- **平均レスポンスタイム**: 150.6ms
- **平均レイテンシ**: 140.1ms
- **平均接続時間**: 0.1ms
- **平均帯域幅**: 2,237,975 bytes/sec
- **パーセンタイル**:
- P50: 141ms
- P90: 189ms
- P95: 214ms
- P99: 298ms
- P99.9: 535ms
- P100: 930ms
### テスト2: test (Copy) (ID: 2iPcnawnyK)
テスト実行ID: 165qN3Jp3C
- **期間**: 2026-01-06 10:57:38 → 11:09:57 (約12分)
- **ステータス**: complete
- **総リクエスト数**: 1,237,831
- **成功**: 769,814 (62.2%)
- **エラー**: 468,017 (37.8%) ⚠️
- **RPS**: 2,063.1
- **平均レスポンスタイム**: 496.3ms
- **平均レイテンシ**: 491.7ms
- **平均接続時間**: 39.2ms
- **平均帯域幅**: 582,099 bytes/sec
- **パーセンタイル**:
- P50: 230ms
- P90: 920ms
- P95: 1,030ms
- P99: 1,930ms
- P99.9: 3,979ms
- P100: 16,747ms
注目点: テスト2は高いエラー率(37.8%)と遅いレスポンスタイムを示しています。詳細な分析が必要な場合は、get_test_run で地域別の詳細データ
を取得できます。どちらのテストの詳細を確認しますか?
今回は負荷テストの結果が 2 つあったので、両方とも表示されました。このあとテスト 2 の詳細を確認してとプロンプトに記載したら、以下の結果が返ってきました。
■実行結果 > ## テスト2の詳細分析 ### テスト構成 - **テストID**: 2iPcnawnyK - **テスト実行ID**: 165qN3Jp3C - **テストタイプ**: simple - **期間**: 2026-01-06 10:57:38 → 11:09:57 (10分間) - **リージョン**: ap-northeast-1 - **タスク数**: 20 - **同時実行数**: 50 - **完了タスク**: 20/20 ### エンドポイント - **URL**: http://xx.xx.xx.xx/index.php - **メソッド**: GET ### パフォーマンス指標 総合結果: - **総リクエスト数**: 1,237,831 - **成功**: 769,814 (62.19%) - **失敗**: 468,017 (37.81%) - **スループット**: 2,063 req/sec - **転送データ量**: 349,259,454 bytes レスポンスタイム: - **平均**: 496.3ms - **標準偏差**: 480ms (高いばらつき) - **平均レイテンシ**: 491.7ms - **平均接続時間**: 39.2ms パーセンタイル分布: - P50: 230ms - P90: 920ms - P95: 1,030ms - P99: 1,930ms - P99.9: 3,979ms - P100: 16,747ms (最大) ### 🚨 エラー分析 エラー内訳: 1. NoHttpResponseException: 116,735件 - サーバーがHTTPレスポンスを返さない - 接続は確立されたがレスポンスなし 2. ConnectTimeoutException: 3件 - 接続タイムアウト ### 問題点と推奨事項 主な問題: 1. 高いエラー率 (37.81%) - NoHttpResponseExceptionが大量発生 2. 高い標準偏差 (480ms) - レスポンスタイムが不安定 3. 長い接続時間 (39.2ms) - テスト1の0.1msと比較して約390倍 4. P99.9以降の急激な悪化 - 一部リクエストが極端に遅い 推奨アクション: - サーバー側のリソース不足を確認 (CPU、メモリ、接続数制限) - アプリケーションログでエラーの根本原因を調査 - 同時実行数を下げてテストを再実行 - ターゲットサーバー (xx.xx.xx.xx) の健全性チェック - ネットワーク接続の安定性を確認
こんな感じで確認したいことを指示するだけで、負荷テストの結果を分析することができました。
まとめ
Distributed Load Testing (分散負荷テスト) on AWS の MCP サーバーを使ってみました。負荷テストの結果に対して、自然言語で問い合わせをして分析、推奨アクションの提案というのを簡単にできることが確認できました。本件に限らずですが、生成 AI の機能を活用することで、業務を効率よく進めるようにしていきましょう。
小倉 大(記事一覧)
アプリケーションサービス部エデュケーショナルサービス課 札幌在住
AWSトレーニングの講師をしています。
最近は7歳の息子と遊ぶのが楽しいです!
Twitter: @MasaruOgura