AWS DevOps Agent × MCP｜そのまま使えるMCPサーバの雛形を作ってみました

1. はじめに

製造ビジネステクノロジー部の平内（SIN）です。

AWS DevOps Agent は、AWSリソースの異常検知や根本原因分析を自動化する強力なツールです。このエージェントの調査能力をさらに拡張できる仕組みとして、Model Context Protocol（MCP）との連携がサポートされています。

MCPサーバーを接続することで、外部の監視ツールや、独自の運用データソースなど、AWSの標準サービス外のデータもエージェントの調査対象に組み込むことができます。

ただし、AWS DevOps AgentにMCPサーバーを接続するには、以下の要件を満たす必要があります。

• トランスポートプロトコルとして Streamable HTTP を使用
• 認証方式として OAuth 2.0認証フロー（クライアント認証情報フローまたは3LOフロー）または APIキー/トークンベースの認証 を使用

これらの要件を満たすMCPサーバーを一から構築するのは、少し手間がかかります。そこで今回は、CDKで簡単にデプロイできるMCPサーバの雛形を作成してみました。

https://github.com/furuya02/mcp-server-aws-devops

本記事では、この雛形の構成と使い方を解説します。なお、雛形として実装したMCPは、システムのメンテナンススケジュールを返すシンプルなものです。実際のプロジェクトでは、この雛形をベースに独自のツールを追加して拡張していただければと思います。

補足: AWS DevOps Agentは、2026年4月3日（日本時間）にGA（一般提供）されました。GA前は「プライベート接続未対応」という制約がありましたが、現在はプライベート接続も可能になっています。本記事は、インターネット経由でグローバルに接続するものです。

2. 構成

本プロジェクトでは、CDKデプロイ時のスイッチで2種類の認証方式を切り替えてデプロイできます。

(1) API Key 認証

API Key認証は、シンプルな構成で素早くデプロイできる方式です。

クライアントからのリクエストは、API Gatewayでx-api-keyヘッダーの値を検証し、有効なAPIキーを持つリクエストのみがLambda関数に転送されます。

作成されるAWSリソース:

(2) OAuth 2.0 認証（Client Credentials Flow）

OAuth 2.0認証は、よりセキュアな認証が必要な場合に選択する方式です。

クライアントは、まずCognitoからアクセストークンを取得し、そのトークンをAuthorizationヘッダーに含めてAPIを呼び出します。API GatewayのCognito Authorizerがトークンを検証し、有効なトークンを持つリクエストのみがLambda関数に転送されます。

作成されるAWSリソース:

3. 認証方式の違い

2つの認証方式の特徴を比較します。用途に応じて適切な方式を選択してください。

(1) 概要比較

(2) フローの比較

API Key認証のフロー:

OAuth 2.0認証のフロー:

OAuth 2.0認証では、クライアントは事前にCognitoからアクセストークンを取得する必要があります。このトークンには有効期限（デフォルト60分）があり、期限切れの場合は再取得が必要です。

(3) 選択の指針

API Keyを選ぶ場合:

• 開発・テスト環境での利用
• 内部システム間の連携
• シンプルさを優先したい場合

OAuth 2.0を選ぶ場合:

• 本番環境での利用
• セキュリティ要件が高い場合
• トークンの有効期限管理が必要な場合

4. 環境構築

(1) 前提条件

デプロイには以下の環境が必要です。

• Node.js 18以上
• Docker（Lambda関数のバンドリングに使用）
• AWS CLI（設定済み）
• pnpm（または npm）

(2) リポジトリのクローン

git clone https://github.com/furuya02/mcp-server-aws-devops.git
cd mcp-server-aws-devops
cd cdk
pnpm install

(3) デプロイ

API Key認証の場合

cdk deploy

OAuth 2.0認証の場合:

cdk deploy -c authType=oauth

デプロイが完了すると、以下のような出力が表示されます。

Outputs:
mcp-server-sample.ApiKeyId = xxxxxxxxxx
mcp-server-sample.AuthType = api-key
mcp-server-sample.GetApiKeyCommand = aws apigateway get-api-key --api-key xxxxxxxxxx --include-value --query 'value' --output text
mcp-server-sample.McpApiEndpoint = https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prd/mcp
mcp-server-sample.McpApiUrl = https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prd/
mcp-server-sample.McpFunctionArn = arn:aws:lambda:ap-northeast-1:xxxxxxxxxxxx:function:mcp-server-sample-mcp

✨  Total time: 81.19s

出力されたMcpApiEndpointがMCPサーバーのエンドポイントURLです。

5. 動作確認（API Key認証）

最初に「API Key認証」でデプロイした場合の動作確認方法を説明します。

(1) Lambda関数の確認

MCPの本体となるLambda関数（mcp-server-sample-mcp）がデプロイされ、API Gatewayのトリガーが設定されています。

トリガーは以下の4種類が設定されています。

(2) API Gatewayのリソース構成

API Gatewayには以下のリソースが作成されます。

MCP（Model Context Protocol）のStreamable HTTPトランスポートでは、POSTとGETの両方が必要です。

• POST /mcp: JSON-RPCリクエスト（initialize、tools/list、tools/call）の送信に使用
• GET /mcp: SSE（Server-Sent Events）ストリームの確立に使用

OPTIONSメソッドは、ブラウザが異なるオリジンからAPIを呼ぶ際のCORSプリフライトリクエストに応答するためのものです。CDKのdefaultCorsPreflightOptionsで自動設定されています。

(3) API Keyの確認

API Keyは使用量プランで関連付けされています。

APIキーの値は、デプロイ時に出力されたGetApiKeyCommandを実行して取得できます。

aws apigateway get-api-key --api-key <ApiKeyId> --include-value --query 'value' --output text

(4) Postmanでの確認

Postmanを使用してMCPサーバーの動作を確認できます。

ヘッダー設定:

リクエストボディ（ツール一覧取得）:

{
    "jsonrpc": "2.0",
    "method": "tools/list",
    "id": 1
}

レスポンスとして、登録されているツールの一覧が返されます。

(5) MCP Inspectorでの確認

MCP Inspectorを使用すると、ツールの一覧確認や実行テストをGUIで行えます。

Step 1: 接続設定

Step 2: Custom Headersの設定

1. Authenticationセクションを展開
2. Custom Headersの「+ Add」をクリック
3. 以下を入力

4. トグルがONになっていることを確認

Step 3: 接続

Connectボタンをクリックして接続します。接続に成功すると、Toolsタブでツール一覧（get_scheduleなど）が表示されます。

(6) AWS DevOps AgentへのMCPサーバー登録

MCPサーバーの登録は、AWS DevOps Agentのエージェントスペースで行います。

Step 1: エージェントスペースを開く

Step 2: MCPサーバーの追加

Step 3: 接続情報の入力

MCPサーバーのURLとAPI Keyを入力します。

Step 4: ツールの選択

「MCPサーバーツールを選択」の画面で、使用するツールをチェックします。サンプルではget_scheduleのみが提供されています。

Step 5: Webhookの設定（スキップ）

Webhookは今回使用しないので、そのまま進めます。

Step 6: 登録完了

これでMCPサーバーの登録が完了しました。

6. 動作確認（OAuth 2.0認証）

続いて「OAuth 2.0認証」でデプロイした場合の動作確認方法を説明します。API Key認証と重複する部分については省略します。

(1) Lambda関数

認証はAPI Gateway側で実施されるため、デプロイされるLambda関数は「API Key認証」のときと同じです。

(2) API Gateway

作成されるリソース（/mcpエンドポイントのPOST、GET、OPTIONSメソッド）は「API Key認証」の場合と同じですが、認証方式が異なります。

API Key認証との違い:

Cognito User Pools オーソライザー:

メソッドの認証設定:

認可スコープが設定されているため、クライアントはトークン取得時にmcp-server-sample-api/mcp.invokeスコープを含める必要があります。スコープが含まれていないトークンでアクセスすると、403 Forbiddenが返されます。

(3) Cognito

OAuth 2.0認証では、Cognitoに以下のリソースが作成されます。

ユーザープール:

アプリケーションクライアント:

クライアント認証情報フロー（client_credentials）は、サーバー間通信に適した認証方式で、ユーザーの介入なしにアクセストークンを取得できます。

リソースサーバー:

(4) Postmanでの確認

OAuth 2.0認証では、API Key認証と異なり、まずCognitoからアクセストークンを取得する必要があります。

Step 1: アクセストークンの取得

Cognitoのトークンエンドポイントにリクエストを送信してアクセストークンを取得します。

エンドポイント:

POST https://<cognito-domain>.auth.ap-northeast-1.amazoncognito.com/oauth2/token

ヘッダー:

ボディ（x-www-form-urlencoded）:

レスポンス例:

{
    "access_token": "eyJraWQiOiJ...",
    "expires_in": 3600,
    "token_type": "Bearer"
}

Step 2: MCP APIの呼び出し

取得したアクセストークンを使用してMCP APIを呼び出します。

ヘッダー:

ボディ:

{
    "jsonrpc": "2.0",
    "method": "tools/list",
    "id": 1
}

(5) MCP Inspectorでの確認

MCP Inspector v0.21.1は「public client」として設計されており、Client Credentials Flow（client_secretを使用する認証）には対応していません。そのため、事前にトークンを取得してCustom Headersに手動設定する方法で接続します。

Step 1: アクセストークンの取得

curlコマンドでCognitoからアクセストークンを取得します。

curl -s -X POST "https://<cognito-domain>.auth.ap-northeast-1.amazoncognito.com/oauth2/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -u "<client_id>:<client_secret>" \
  -d "grant_type=client_credentials&scope=mcp-server-sample-api/mcp.invoke"

レスポンスのaccess_tokenの値をコピーしておきます。

Step 2: MCP Inspectorで接続

Custom Headers:

注意: アクセストークンの有効期限は60分です。期限切れの場合はStep 1から再度トークンを取得してください。

(6) AWS DevOps AgentへのMCPサーバー登録

OAuth 2.0認証の場合、認証設定のみがAPI Key認証と異なります。

認証フローの選択:

「OAuthクライアント認証情報」を選択します。

認証情報の入力:

• クライアントID: Cognitoアプリクライアントから取得
• クライアントシークレット: Cognitoアプリクライアントから取得
• 交換URL: https://<cognito-domain>.auth.ap-northeast-1.amazoncognito.com/oauth2/token

7. AWS DevOps AgentでMCPサーバを利用した調査

MCPサーバーを登録したら、実際にAWS DevOps Agentで調査を行ってみましょう。

(1) スキルの登録

MCPサーバーを利用するには、エージェントスペースでスキルを登録し、呼び出しのルールを伝える必要があります。

「調査」開始時に必ず実行するとしておくことで、調査に毎回利用されるようになります。

(2) 調査の実行

調査を実行すると、エージェントが最初にMCPサーバーから情報を取得していることを確認できます。

サンプル実装では、get_scheduleツールがメンテナンススケジュール情報を返すため、エージェントは「システムのメンテナンス予定」を考慮した調査を行うことができます。

例えば、障害調査の際に「このタイミングでメンテナンス作業が予定されていた」という情報があれば、根本原因の特定に役立てることができます。

8. Lambda実装

最後に、MCPの本体として実装したLambda関数について紹介します。

(1) 使用ライブラリ

本プロジェクトでは、AWS Labs が提供する awslabs.mcp_lambda_handler ライブラリを使用しています。

pip install awslabs.mcp-lambda-handler

このライブラリは、Lambda上でMCPサーバーを構築するためのフレームワークで、以下の機能を提供します。

(2) 基本的な実装パターン

MCPサーバーの実装は非常にシンプルです。

from awslabs.mcp_lambda_handler import MCPLambdaHandler

# MCPサーバーを初期化
mcp = MCPLambdaHandler(
    name="service-operations-mcp",
    version="1.0.0",
)

@mcp.tool()
def get_schedule() -> str:
    """
    サービス運用のスケジュールを取得します。
    """
    # スケジュールデータを返す処理
    ...

def handler(event, context):
    return mcp.handle_request(event, context)

ポイント:

• 関数名がそのままツール名になる（snake_case）
• docstringの最初の段落がツールの説明（description）になる
• 型ヒントからinputSchemaが自動生成される

(3) サンプル実装の詳細

サンプルとして実装しているget_scheduleツールは、JSON形式のメンテナンススケジュール情報を返します。

{
  "schedules": [
    {
      "id": "maintenance-001",
      "start": "2025-04-01T00:00:00+0900",
      "end": "2025-04-01T02:00:00+0900",
      "title": "SSL Certificate Renewal",
      "description": "Renewing SSL certificates.",
      "status": "scheduled"
    },
    {
      "id": "maintenance-002",
      "start": "2025-04-05T02:00:00+0900",
      "end": "2025-04-05T04:00:00+0900",
      "title": "Security Patch",
      "description": "Applying security patches.",
      "status": "scheduled"
    }
  ],
  "timezone": "Asia/Tokyo",
  "last_updated": "2025-03-15T00:00:00+09:00"
}

実際のプロジェクトでは、このサンプルを参考に独自のツールを追加してください。例えば以下のようなツールが考えられます。

• 外部監視システムからのアラート情報取得
• チケット管理システムからのインシデント情報取得
• 独自のメトリクスデータベースからの情報取得

完全な実装コードは、GitHubリポジトリの cdk/lambda_python/index.py を参照してください。

https://github.com/furuya02/mcp-server-aws-devops/blob/main/cdk/lambda_python/index.py

(4) Lambda特有の考慮事項

Lambda上でMCPサーバーを運用する際の考慮事項をまとめます。

9. 最後に

本記事では、AWS DevOps Agent用のMCPサーバーをCDKで簡単にデプロイできるMCPサーバの雛形を作成してみましたが、作業を通じて、以下のような知見を得ることが出来ました。

• AWS DevOps AgentのMCPサーバー要件（Streamable HTTP、認証方式）を満たす実装方法
• API Key認証とOAuth 2.0認証の2種類の認証方式の実装と使い分け
• awslabs.mcp_lambda_handlerライブラリを使用したシンプルなMCPサーバー実装

作成したプロジェクトは、MCPサーバーの雛形として、最小限の構成で動作するサンプル実装です。

この雛形をベースに、実際のプロジェクトで拡張利用されると嬉しいです。

• 独自のツール追加（外部システムとの連携など）
• エラーハンドリングの強化
• ログ出力の最適化（本番環境では機密情報のフィルタリングが必要）

コードはGitHubで公開しています。ぜひご活用ください。

https://github.com/furuya02/mcp-server-aws-devops