AWS DevOps Agent × MCP サーバーでインシデント調査ナレッジを蓄積してみた
どうも、こんにちは kaz です。
ついにDevOps AgentがGAになりましたね！
さっそく触ってみましたが、これは従来の運用を変える可能性を秘めるサービスだと思います（プレビュー期間では触ってませんでした）。
試す中でDevOps Agentが調査したナレッジを蓄積できたらいいなと思い、そのための方法を考えてみたので紹介します。
はじめに
DevOps Agentはさまざまなメトリクスやログなど関連するデータをもとに調査を行ってくれます。
調査時の内容を眺めているとわかるのですが、よく調査してくれているのでせっかくならその調査結果から得られる知見を蓄積したいと思いました。
また、MCPサーバーを構築してみたかったので、この機会に作ってみるか！と思ったのもあります。
ただ、DevOps Agent標準では以下の機能があるのでこちらでも代替できそうです。
- 同リソースにおける調査結果の「リンク」機能
- インシデントを未然に防ぐのに役立つ「Prevention（予防）」機能
やってみた
ここからは実際にDevOps Agentで調査したナレッジを蓄積する方法の紹介をします。
今回紹介するスキルとMCPは以下のリポジトリにあるので、よかったら参考にしてください。
※GitHubクローンとDevOps Agentスペースが作成されている前提で進めます
MCPサーバーのデプロイ
まずは下準備としてMCPサーバーをデプロイします。
参考までにこのMCPサーバーの構成を載せておきます。
MCPはAWS CDK(Python)で構成されているので以下のコマンドでデプロイできます。
cd mcp-server
# 仮想環境セットアップ
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
# CDKブートストラップ（初回のみ）
cdk bootstrap
# デプロイ
cdk deploy
およそ2分程度でデプロイが完了します。
ここで出力される McpEndpointUrl と ApiKeyId を控えます
次に、APIキーの値を取得します。
aws apigateway get-api-key --api-key <ApiKeyId> --include-value --query value --output text
ここで出力される APIキーの値を控えます
MCPサーバー登録
DevOps AgentのAgent SpaceからMCPサーバーを登録します。
［ソースを追加］をクリックします。
［登録］をクリックします。
名前と説明は任意で、エンドポイントURLには先ほど控えた McpEndpointUrl を入力します。
認証フローは［APIキー］を選択
APIキー名は任意です。
APIキーヘッダーには x-api-key を入力し、APIキー値には先ほど控えたAPIキーの値を入力します。
最後に確認して問題なければ［追加］をクリックします。
正常に登録ができるとサーバーツールの選択画面になるので search_knowledge と save_knowledge を有効化し、［保存］をクリックします。
これでMCPサーバーの登録は完了です（登録後にウェブフック設定が表示されますが、今回は使用しません）。
スキルのアップロード
次にスキルをアップロードします。
スキルはskillsディレクトリにあるので、以下のコマンドでZIPファイルを作成します。
cd ../skills
zip -r incident-investigation.zip incident-investigation/
次にZIPファイルをアップロードするために［オペレーターアクセス］をクリックします。
［スキルを追加］をクリックします。
［スキルをアップロード］からZIPファイルをアップロードします。
アップロード時のエージェントタイプは「一般」でOKです。
正常にアップロードができるとスキルの一覧画面に表示されます。
これでスキルのアップロードは完了です。
テストシナリオの作成
あとはテストシナリオを作成します。
ちょうどいいシナリオがなかったので、aws-samplesからお借りしました。
このシナリオはCloudWatchアラームが発火した際にDevOps Agentへ自動で調査依頼を送るサーバーレス構成のサンプルです。
意図的にLambdaエラーを発生させ、アラーム検知からWebHook経由でDevOps Agentがインシデント調査を開始するまでの一連の流れを作れます。
セットアップについてはリポジトリ内の README.md に記載されているので、そちらを参考にしてください。
動作確認
いよいよ動作確認です。
さきほどのテストシナリオを使って動作確認を行うため、以下のコマンドから始めていきます。
ステップ1: エラー生成Lambdaを呼び出す
エラー生成Lambdaをトリガーして、意図的に障害を発生させます。
# エラー生成Lambdaの関数名を取得
FUNCTION_NAME=$(aws cloudformation describe-stack-resources \
--stack-name DevOpsTestScenario \
--query "StackResources[?LogicalResourceId=='ErrorGeneratorFunction'].PhysicalResourceId" \
--output text)
# 関数を呼び出す
aws lambda invoke \
--function-name $FUNCTION_NAME \
--payload '{}' \
response.json
> {
> "StatusCode": 200,
> "FunctionError": "Unhandled",
> "ExecutedVersion": "$LATEST"
> }
# レスポンスを確認
cat response.json
{"errorType":"AuthorizationErrorException","errorMessage":"User: arn:... is not authorized to perform: SNS:Publish on resource:... というエラーが出力されればOKです。
ステップ2: CloudWatchアラームを確認する
CloudWatchアラームが発火していることを確認します。
# CloudWatchアラームの名前を取得
ALARM_NAME=$(aws cloudformation describe-stacks \
--stack-name DevOpsTestScenario \
--query "Stacks[0].Outputs[?OutputKey=='LambdaErrorAlarmName'].OutputValue" \
--output text)
# アラームの状態を確認
aws cloudwatch describe-alarms \
--alarm-names "$ALARM_NAME" \
--query "MetricAlarms[].[AlarmName,StateValue,StateReason]" \
--output table
以下のような結果が出力されれば成功です。
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| DescribeAlarms |
+---------------------------------------------------+--------+--------------------------------------------------------------------------------------------------------------+
| DevOpsTestScenario-LambdaErrorAlarm-xxxxxxx | ALARM | Threshold Crossed: 1 datapoint [1.0 (01/04/26 00:33:00)] was greater than or equal to the threshold (1.0). |
+---------------------------------------------------+--------+--------------------------------------------------------------------------------------------------------------+
ステップ3: WebHookエグゼキュータの呼び出しを確認する
WebHookエグゼキュータLambdaのログを確認し、トリガーされたことを確認します。
# WebHookエグゼキュータLambdaの関数名を取得
WEBHOOK_FUNCTION_NAME=$(aws cloudformation describe-stack-resources \
--stack-name DevOpsTestScenario \
--query "StackResources[?LogicalResourceId=='WebHookExecutorFunction'].PhysicalResourceId" \
--output text)
# 最近のログを確認
aws logs tail /aws/lambda/$WEBHOOK_FUNCTION_NAME --follow
結果が長いので省略しますが、以下のようなログが出力されれば成功です。
- 「Webhookリクエストを送信中」と表示されるログエントリ
- HTTPレスポンスステータス（200または202）
ステップ4: DevOps Agentのオペレーターアクセスから調査結果を確認する
インシデントレスポンスダッシュボードに調査結果が1件表示されてます。
確認してみると「Lambda関数ErrorGeneratorFunctionでエラー発生」という調査結果の中で incident-investigation スキルが使用されていることがわかります。
なお、スキル説明に記載された内容によってエージェントが調査に適用すべきかを判断します。
そして Knowledge-mcp を使用して過去のナレッジを検索してくれてます！
当然ながら過去のナレッジがないので検索結果は0件です。
そのあとはスキルの調査手順に従って調査を行い、必要に応じてナレッジを蓄積します。
（1回目ではナレッジが蓄積されなかったので再実行して確認してます）
DynamoDBを見てみるとナレッジが蓄積されてますね！
まとめ
今回はDevOps Agentで調査したナレッジを蓄積する方法を紹介しました。
なんといってもDevOps Agentの魅力はその手軽さだと思います。
さらに、SkillやMCPを設定できるため調査の幅が広がり、より深い調査が可能になる点も魅力ですね。
また、今回はMCP(API Gateway + Lambda + DynamoDB)を使いましたが、S3 Vectorsにナレッジをベクトル化して蓄積するのもいいかもしれません。
まだまだおもしろい使い方があると思うので、色々試してみようと思います！
