Logspect Tech BlogPublicationへの投稿
🤖

cloudwatch‑mcp‑serverを使ってSession Managerの操作から監査レポート作ってみた

たむ
に公開
AWS
Security
Model Context Protocol
CloudWatch
LibreChat
tech

はじめに

AWSのSession Managerのログ分析がしづらく、悩んでいました。というのも、Session ManagerのログはLinux上でscriptコマンドを実行して取得した内容であり、制御シーケンス(^Mや\x1b[…]など)やメタタグ([[[ ... ]]]など)といったノイズが多く、どこで何が起きたのか判別しづらかったためです。
そのような中で、「cloudwatch-mcp-server(以下、MCPサーバ)」という仕組みがあることを知り、「これを使ってAIに分析させればよいのでは？」と考え、実際に構築して試してみました。

cloudwatch‑mcp‑serverとは

「AWS Labs」が提供するMCP(Model Context Protocol)サーバの一つで、Amazon CloudWatchのデータ(ログ／メトリクス／アラームなど)を、AIエージェントにとって扱いやすいようインターフェース化したものです。

主なポイント

  • MCPとは、LLM(大規模言語モデル)アプリケーションと外部データソース・ツールをつなぐ標準化されたプロトコル
  • cloudwatch‑mcp‑serverは、CloudWatchの「ログ」「メトリクス」「アラーム」などの観測データを、AIエージェントが自然言語で問い合わせしたり分析したりできるようにツール化したもの

主な機能(特徴)

  • アラームに基づくトラブルシューティング(アクティブなアラームの特定、関連メトリクス・ログの取得、履歴の分析)
  • ログ分析：指定時間内のロググループの異常値やメッセージパターン、エラーパターンの検出
  • メトリクス定義の理解支援：各メトリクスが何を表しているか・どの統計値を使うか等の説明
  • アラームの推奨設定：メトリクスに対して、閾値・評価期間・その他アラーム設定を提案

つまり、CloudWatchの観測データを、AIに頼って分析できるように整えてくれるミドルウェアになります。

今回は、このcloudwatch‑mcp‑serverを使用し、CloudWatchの「ログ」を分析するための環境を構築しました。

https://github.com/awslabs/mcp/tree/main/src/cloudwatch-mcp-server

ユースケース

CloudWatch Logsへ出力されたログからレポートを作成します。
CloudWatch LogsにSession Managerによる操作ログ(Session Activity Logs)を出力し、このログを使って、LLMにEC2操作の監査レポートを生成させたいと思います。

利用環境

本構築で用いた環境は以下のとおりです：

  • EC2(Amazon Linux)：LibreChatやMCPサーバ実行環境、ログの取得対象として用意
  • LibreChat：チャットインターフェースとして使用
  • cloudwatch‑mcp‑server：AIによる分析を実現するためのサーバ
  • Amazon Bedrock：LLMエンジンとして利用

各ソフトウェアのバージョンは以下のとおりです。

ソフトウェア バージョン
Amazon Linux 2023
Docker 25.0.8, build 0bab007
Docker Compose 2.39.2
Git 2.47.1
LibreChat 0.8.0-rc2
LLMモデル anthropic.claude-sonnet-4-5-20250929-v1:0

構成概要

stdioの構成とSSE(Server‑Sent Events)通信の構成で構築しました。

  • Systems ManagerのSession Manager機能を利用し、Session Activity LogをCloudWatch Logsへログとして出力
  • LibreChatにはTCP3080ポートでブラウザからアクセス
  • LLMとして、Amazon Bedrockを使用

stdioとSSEについてはこちらをご参照ください。

stdio構成

LibreChatとMCPサーバは同一コンテナとしてデプロイします。

SSE構成

LibreChatとMCPサーバは同一EC2内に別コンテナとしてデプロイします。

実装手順

1. 事前準備

EC2に割り当てるIAM ポリシーの作成

  • 下記のEC2インスタンスを用意し、ElasticIPを付与しておきます。
タイプ ストレージ
t3.medium 30GB
  • セキュリティグループに下記を設定します。
ルール プロトコル ポート 接続元
インバウンド TCP 3080 自身のグローバルIP
  • EC2に設定しているロールに下記のポリシーを追加します。
    Session Managerのログ(ロググループ名：/ssm/session-logs)以外は見せたくなかったため、権限を絞っています。
cloudwatch-mcp-server-policy
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ListOnly",
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogGroups",
                "logs:DescribeQueryDefinitions",
                "logs:StopQuery"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowReadOnlyOnSpecificLogGroup",
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogStreams",
                "logs:GetLogEvents",
                "logs:FilterLogEvents",
                "logs:StartQuery",
                "logs:GetQueryResults",
                "logs:ListAnomalies",
                "logs:ListLogAnomalyDetectors"
            ],
            "Resource": [
                "arn:aws:logs:ap-northeast-1:AWSアカウントID:log-group:/ssm/session-logs",
                "arn:aws:logs:ap-northeast-1:AWSアカウントID:log-group:/ssm/session-logs:*",
                "arn:aws:logs:ap-northeast-1:AWSアカウントID:log-group:/ssm/session-logs:log-stream:*",
                "arn:aws:logs:ap-northeast-1:AWSアカウントID:anomaly-detector:/ssm/session-logs*"
            ]
        },
        {
            "Sid": "DenyReadOnOtherLogGroups",
            "Effect": "Deny",
            "Action": [
                "logs:DescribeLogStreams",
                "logs:GetLogEvents",
                "logs:FilterLogEvents",
                "logs:StartQuery",
                "logs:GetQueryResults",
                "logs:ListAnomalies",
                "logs:ListLogAnomalyDetectors"
            ],
            "NotResource": [
                "arn:aws:logs:ap-northeast-1:AWSアカウントID:log-group:/ssm/session-logs",
                "arn:aws:logs:ap-northeast-1:AWSアカウントID:log-group:/ssm/session-logs:*",
                "arn:aws:logs:ap-northeast-1:AWSアカウントID:log-group:/ssm/session-logs:log-stream:*",
                "arn:aws:logs:ap-northeast-1:AWSアカウントID:anomaly-detector:/ssm/session-logs*"
            ]
        }
    ]
}

Session Managerによる操作をCloudWatch Logsへログ出力

  • Systems ManagerのSession Managerを使ってログインおよびコマンド実行し、その履歴および出力を CloudWatch Logsに出力するよう設定します。
    詳細はAWS公式ドキュメントをご参照ください。

2. LibreChatの初期設定

LibreChatのデプロイに必要な環境を準備します

LibreChatデプロイ
# 特権アカウントに昇格
sudo su -

# Docker、Gitのインストール
yum update -y
yum install -y docker git
systemctl enable docker
systemctl start docker

# LibreChatのクローン
git clone https://github.com/danny-avila/LibreChat.git

3. LibreChatの基本設定

LibreChatからBedrockに接続できるよう設定を行います。
envファイルを作成し、下記を記載します。

.env ファイルを作成
cd LibreChat
vi .env
.env
HOST=0.0.0.0
PORT=3080
UID=0
GID=0
MONGO_URI=mongodb://mongodb:27017/LibreChat
NO_INDEX=true
CONSOLE_JSON=false
DEBUG_LOGGING=true
DEBUG_CONSOLE=false
ALLOW_REGISTRATION=true
JWT_SECRET={予測不能なランダム文字列}
JWT_REFRESH_SECRET={予測不能なランダム文字列}
JWT_EXPIRY=1d
JWT_REFRESH_EXPIRY=7d
SESSION_EXPIRY=86400000
NODE_ENV=development
AWS_REGION=ap-northeast-1

#=================#
#   AWS Bedrock   #
#=================#
BEDROCK_AWS_DEFAULT_REGION=ap-northeast-1
BEDROCK_AWS_MODELS=jp.anthropic.claude-sonnet-4-5-20250929-v1:0
APP_TITLE=LibreChat on AWS

librechat.yamlに下記を記載します。

librechat.yamlファイルを編集
vi librechat.yaml
librechat.yaml
version: 1.2.1
 cache: true

interface:
 endpointsMenu: true
 modelSelect: true
 parameters: true
 sidePanel: true
 presets: true
 prompts: true
 bookmarks: true
 multiConvo: true
 agents: true

endpoints:
 bedrock:
  titleModel: "anthropic.claude-sonnet-4-5-20250929-v1:0"
  streamRate: 35
  availableRegions:
   - "ap-northeast-1"

docker-compose.ymlを修正

docker-compose.ymlファイルを編集
vi docker-compose.yml
docker-compose.yml
services:
 api:
  container_name: LibreChat
  ports:
   - "3080:3080"
  depends_on:
   - mongodb
  image: ghcr.io/danny-avila/librechat-dev:latest
  restart: always
  user: "${UID}:${GID}"
  extra_hosts:
   - "host.docker.internal:host-gateway"
  environment:
   - HOST=0.0.0.0
   - MONGO_URI=mongodb://mongodb:27017/LibreChat
  volumes:
   - type: bind
     source: ./librechat.yaml
     target: /app/librechat.yaml
   - ./images:/app/client/public/images
   - ./uploads:/app/uploads
   - ./logs:/app/logs
  env_file:
   - .env

 mongodb:
  container_name: chat-mongodb
  image: mongo
  restart: always
  volumes:
   - ./data-node:/data/db
  command: mongod --noauth

volumes:
 pgdata2:

4. MCPサーバ設定

cloudwatch-mcp-serverは、公式にはstdio(同一ホスト内のローカル通信)で動作させるモデルですが、今回はstdio方式とSSE方式を試しました。

cloudwatch‑mcp‑serverのデプロイ

LibreChatディレクトリ配下にデプロイします。

cd LibreChat
git clone https://github.com/awslabs/mcp.git　　　# LibreChatの配下にデプロイ

LibreChatディレクトリ構造は下記になります。

LibreChatディレクトリ構造
/root/LibreChat/
├── mcp/src/cloudwatch-mcp-server/             # クローンしたリポジトリ
│   ├── awslabs/
│   ├── docker-healthcheck.sh
│   ├── Dockerfile
│   ├── requirements.txt
│   ├── uv-requirements.txt
│   ├── uv.lock
│   ├── CHANGELOG.md
│   └── README.md
├── docker-compose.yml
├── librechat.yaml
└── .env

stdio方式の場合

  • stdio方式での設定方法は下記のとおりです。
    docker-compose.ymlを修正
docker-compose.ymlファイルを編集
vi docker-compose.yml

services配下のapiでコンテナへのボリュームマウントを追記します。

docker-compose.yml
services:
 api:
  #(省略)
  volumes:
   #(省略)
+   # コンテナへのボリュームのマウントを追記
+   - ./mcp/src/cloudwatch-mcp-server:/usr/src/app

librechat.yamlを修正します。

librechat.yamlファイルを編集
vi librechat.yaml

mcpServersとendpoints配下のagentsに設定を追記します。

librechat.yaml
# MCP サーバーの設定を追加
+mcpServers:
+ cwl-mcp:
+  name: "CloudWatch MCP"
+  type: "stdio"
+  command: "uvx"
+  args:
+   - "awslabs.cloudwatch-mcp-server@latest"
+  env:
+   AWS_REGION: "ap-northeast-1"
+  disabled: false
+  autoApprove: []

endpoints:
+ agents:
+  recursionLimit: 50
+  maxRecursionLimit: 100
+  disableBuilder: false

SSE方式の場合

  • SSE方式での設定を実施方法は下記のとおりです。
    ここでは、stdio方式との差分を記載しています。
    docker-compose.ymlを修正
docker-compose.ymlファイルを編集
vi docker-compose.yml

services配下のapiに依存関係を追加し、stdio方式で記載したボリュームのマウント設定は削除します。
MCPサーバは別のコンテナとして起動させるため、引き続きservices配下にcloudwatch-mcp-serverを追加します。

docker-compose.yml
services:
  api:
    #(省略)
    depends_on:
      - mongodb
+      - cloudwatch-mcp-server　# 追加
    #(省略)
  volumes:
   #(省略)
-   # コンテナへのボリュームのマウントを追記　　    #削除
-   - ./mcp/src/cloudwatch-mcp-server:/usr/src/app   #削除

+### MCPサーバ追加
+  cloudwatch-mcp-server:
+    container_name: cloudwatch-mcp-server
+    build:
+      context: ./mcp/src/cloudwatch-mcp-server
+      dockerfile: Dockerfile
+    ports:
+      - "8090:8090"
+    volumes:
+      - ./mcp/src/cloudwatch-mcp-server:/usr/src/app
+    working_dir: /usr/src/app
+    restart: unless-stopped
+    environment:
+      - AWS_REGION=ap-northeast-1

librechat.yamlを修正します。

librechat.yamlファイルを編集
vi librechat.yaml

mcpServersの設定を修正します。
typeをsseに修正し、docker-compose.ymlで設定したMCPサーバへの接続情報をurlに指定します。

librechat.yaml
# MCP サーバーの設定
mcpServers:
  cwl-mcp:
    name: "CloudWatch MCP"
-    type: "stdio"
+    type: "sse"
-    command: "uvx"
-  args:
-   - "awslabs.cloudwatch-mcp-server@latest"
+    url: "http://cloudwatch-mcp-server:8090/sse"
    env:
      AWS_REGION: "ap-northeast-1"
    disabled: false
    autoApprove: []

endpoints:
 agents:
  recursionLimit: 50
  maxRecursionLimit: 100
  disableBuilder: false

cloudwatch-mcp-serverディレクトリ配下のDockerfileを書き換えます。
SSEを可能にするため、Supergatewayを使用します。Supergatewayとは、stdioしか対応していないMCPサーバーを、SSEやWebSocketに変換し、ネットワーク経由で利用できるようにするツールです。
詳しく知りたい場合はGitHubをご確認ください。
Dockerfileでは、Stage1でPython仮想環境を作り、Stage2でNode.js+supergatewayと組み合わせてMCPサーバ用の本番コンテナを作っています。

Dockerfileファイルを編集
vi cloudwatch-mcp-server/Dockerfile
Dockerfile
# ---------- Stage 1: build Python venv with uv ----------
FROM public.ecr.aws/docker/library/python:3.13.5-alpine3.21 AS uv

WORKDIR /app

ENV UV_COMPILE_BYTECODE=1 \
    UV_LINK_MODE=copy \
    UV_PYTHON_PREFERENCE=only-system \
    UV_FROZEN=true \
    PIP_NO_CACHE_DIR=1 \
    PIP_DISABLE_PIP_VERSION_CHECK=1

COPY pyproject.toml uv.lock uv-requirements.txt ./

RUN apk update && \
    apk add --no-cache --virtual .build-deps \
      build-base \
      gcc \
      musl-dev \
      libffi-dev \
      openssl-dev \
      cargo

RUN --mount=type=cache,target=/root/.cache/uv \
    pip install --require-hashes --requirement uv-requirements.txt --no-cache-dir && \
    uv sync --python 3.13 --frozen --no-install-project --no-dev --no-editable

COPY . /app
RUN --mount=type=cache,target=/root/.cache/uv \
    uv sync --python 3.13 --frozen --no-dev --no-editable

RUN mkdir -p /root/.local


# ---------- Stage 2: runtime (Python + supergateway) ----------
FROM public.ecr.aws/docker/library/python:3.13.5-alpine3.21

ENV PATH="/app/.venv/bin:$PATH" \
    PYTHONUNBUFFERED=1

# Node.js/npmはsupergateway用
RUN apk update && \
    apk add --no-cache \
      ca-certificates \
      nodejs \
      npm && \
    update-ca-certificates && \
    addgroup -S app && \
    adduser -S app -G app -h /app

# supergatewayをインストール
RUN npm install -g supergateway

# venvをコピー
COPY --from=uv --chown=app:app /app/.venv /app/.venv

# ヘルスチェックスクリプト
COPY ./docker-healthcheck.sh /usr/local/bin/docker-healthcheck.sh

# 作業ディレクトリ(相対パス安定化)
WORKDIR /app

# 非root実行
USER app

# Healthcheck
HEALTHCHECK --interval=60s --timeout=10s --start-period=10s --retries=3 \
  CMD ["docker-healthcheck.sh"]

# supergatewayでCloudWatchMCPサーバをラップ
CMD ["supergateway","--stdio","awslabs.cloudwatch-mcp-server","--port","8090"]

コンテナを起動します。

コンテナ起動
# Docker Composeでサービスを起動
docker compose up -d

5. エージェント設定

WebブラウザでLibreChat(http://{グローバルIP}:3080)にアクセスし、新規登録からアカウントを作成します。

作成したアカウント(最初に作成されたアカウントが管理者となります)でログインし、画面右側のパネル(サイドバー)で[エージェントビルダー]を開きます。

プルダウンに作成 エージェントが表示されていることを確認し、下記の設定でエージェントを作成します。

項目 設定内容
名前 CloudWatch Logs Analytics AI Agent
説明 CloudWatch Logsを分析するAIエージェント
カテゴリ IT
指示文 指示のない限り、AWSへの情報取得は東京リージョンから行ってください。CloudWatch MCP でロググループを検索するときは、/ssm/session-logs以外は結果として返さないでください。
モデル jp.anthropic.claude-sonnet-4-5-20250929-v1:0
ツールを追加 cwl-mcp

名前、説明、カテゴリ、指示文を設定します。

指示文(システムプロンプト)は、CloudWatch Logsで取得する対象を日本リージョンに限定し、さらにSession Activity Logsが出力されているロググループのみに絞り込むよう設定しました。(/ssm/session-logsに分析対象となるSession Activity Logsが出力されています。)
EC2に設定したポリシー内のDescribeLogGroupsは、対象リソースを指定することができないため、基本的には全てのロググループ一覧が取得可能となるため、システムプロンプトで制限をすることにしました。

モデルを選択します。

ツール+アクションからツールを追加を押下し、エージェントツール画面からcwl-mcpをを追加します。

追加されたツール(cwl-mcp)横の下印をクリックして開き、CloudWatch Logsの解析に必要なツールを選択し、それ以外の選択は外します。

  • describe_log_groups
  • analyze_log_group
  • execute_log_insights_query
  • get_logs_insight_query_results
  • cancel_logs_insight_query

最後に作成ボタンを押下し、エージェントの作成は終了です。

新しいプロンプトを開き、左上のモデルの選択メニューのMy Agentsから先ほど作成したCloudWatch Logs Analytics AI Agentを選択します。

これでCloudWatch Logから情報を取得し、分析できるようになりました。

レポートの作成

実際にレポートを作成してみました。
まず、プロンプトに下記の指示を出します。

下記のフォーマットでレポートを作成し、Markdownで出力してください。
対象日2025/10/24、作業者はtamuraです。

AWS 本番作業報告書
作業者
作業日時
操作した EC2 インスタンス
作業概要
作業内容（時系列で）
まとめ
不審な操作の有無
備考

作成されたレポートは下記になります。私自身が作業した内容についてレポートを作成しました。
対象日となっている10/24は、本ブログに記載するために設定等を確認していましたので、その結果がレポートとして出力されています。

作成されたレポート

AWS 本番作業報告書

作業者

tamura

作業日時

2025年10月24日 15:16:36 ～ 18:41:24 (日本時間)

操作した EC2 インスタンス

  • インスタンスID: i-xxxxxxxxxx
  • プライベートIP: xxx.xxx.xxx.xxx
  • リージョン: ap-northeast-1 (東京)
  • OS: Amazon Linux 2023.7.20250527
  • 接続方法: AWS Systems Manager Session Manager

作業概要

LibreChatアプリケーションの環境確認とCloudWatch MCP Serverのコンテナ設定に関する調査・確認作業を実施しました。

作業内容（時系列）

セッション1: 15:16:36 - 16:01:32

時刻 操作内容
15:16:36 SSM Session Manager経由でEC2インスタンスに接続（ssm-user → root）
15:16:41 /root/LibreChat/ ディレクトリへ移動
15:16:44 ls -la でディレクトリ内容を確認
15:17:11 docker-compose.override.yml の内容を閲覧（moreコマンド）
15:17:24 docker-compose.yml の詳細確認（続き）
15:18:48 docker-compose.override.yml.example の内容を閲覧（catコマンド）
15:32:44 docker-compose.yml を再度確認（moreコマンドで全体をスクロール）
15:34:51 ls -la で再度ディレクトリ内容を確認
15:41:07 .env ファイルの内容を確認（AWS Bedrock設定、開発環境設定等）
16:01:32 待機状態（プロンプト表示のみ）

セッション2: 16:21:24 - 16:51:57

時刻 操作内容
16:21:24 新規セッション開始、rootユーザーに昇格
16:21:29 /root/LibreChat/ ディレクトリへ移動
16:21:33 ls -la でディレクトリ内容を確認（data-nodeが07:20に更新されていることを確認）
16:21:54 cloudwatch-mcp-server/ ディレクトリの内容を確認（lsコマンド）
16:22:30 cloudwatch-mcp-server/ の詳細リスト表示（llコマンド）
16:23:07 cloudwatch-mcp-server-sse/ の詳細リスト表示（main.py, tool_handler.pyなどを確認）
16:23:20 cloudwatch-mcp-server/ の詳細リスト再確認
16:23:30 cloudwatch-mcp-server/tests/ ディレクトリの内容を確認
16:30:54 cloudwatch-mcp-server/Dockerfile の内容を閲覧（moreコマンド、全49%）
16:30:56 Dockerfileの続きを閲覧（supergatetwayの設定等を確認）
16:51:57 待機状態

セッション3: 17:01:53 - 17:34:19

時刻 操作内容
17:01:53 新規セッション開始、rootユーザーに昇格
17:02:03 /root/LibreChat/ ディレクトリへ移動
17:02:08 docker-compose.yml の内容を全文表示（catコマンド）
17:07:05 librechat.yaml の内容を確認（MCP Server設定、Bedrock設定等）
17:13:31 cloudwatch-mcp-server/Dockerfile の全内容を表示（catコマンド）
17:34:19 待機状態

セッション4: 18:38:18 - 18:41:24

時刻 操作内容
18:38:18 最終セッション開始、rootユーザーに昇格
18:38:21 git -v でGitバージョン確認（git version 2.47.1）
18:38:37 docker -v でDockerバージョン確認（Docker version 25.0.8）
18:38:54 docker compose -v でDocker Composeの使用方法を確認
18:39:12 docker compose version でDocker Composeバージョン確認（v2.39.2）
18:40:10 cat /etc/os-release でOS情報確認（Amazon Linux 2023）
18:40:40 /root/LibreChat/.env ファイルの内容を再確認
18:41:24 作業終了

まとめ

本作業では、LibreChatアプリケーションのDocker環境におけるCloudWatch MCPサーバーの設定状況を中心に確認作業を実施しました。

主な確認項目

  1. Docker Compose設定: docker-compose.ymlおよびdocker-compose.override.ymlの構成確認
  2. MCP Server構成: cloudwatch-mcp-server と cloudwatch-mcp-server-sse の2つの実装を確認
  3. Dockerfile内容: supergatetwayを使用したCloudWatch MCP Serverのコンテナイメージ設定確認
  4. アプリケーション設定: librechat.yamlでのMCP Server接続設定（SSEモード使用）
  5. 環境設定: .envファイルでのAWS Bedrock設定（東京リージョン、Claude Sonnet 4.5使用）
  6. システム環境: Git, Docker, Docker Composeのバージョン確認

環境情報

  • OS: Amazon Linux 2023.7.20250527
  • Git: version 2.47.1
  • Docker: version 25.0.8, build 0bab007
  • Docker Compose: version v2.39.2
  • AWS Region: ap-northeast-1
  • Bedrock Model: jp.anthropic.claude-sonnet-4-5-20250929-v1:0

不審な操作の有無

なし

全ての操作は、設定ファイルやディレクトリ内容の確認（閲覧）のみであり、システムやファイルの変更・削除・追加は一切行われていません。権限昇格も正規の手順（sudo su -）で実施されており、すべての操作が適切に記録されています。

備考

  • すべての操作はAWS Systems Manager Session Manager経由で実行され、完全に監査ログに記録されています
  • 本作業は読み取り専用の調査・確認作業であり、システムへの変更は一切行われていません
  • data-nodeディレクトリのタイムスタンプが作業中に更新されているのは、MongoDBコンテナの通常動作によるものと推測されます
  • 4つのセッションすべてで同じ作業者（tamura）による操作が記録されています

報告日: 2025年10月24日
報告者: tamura

ハマったところ

構築／運用していて、特に苦労した点は以下の通りです。

  • cloudwatch‑mcp‑serverはSSE方式に対応していなかったため、Dockerfileファイルを置き換える必要がありました。
  • 日本リージョン(例：ap‑northeast‑1)のみ検索対象にしたかったのですが、設定ファイルにリージョンを指定しても、他のリージョンも検索対象になってしまいました。そこで、設定ファイルではなく、システムプロンプト側で東京リージョンから取得する旨を明示する必要がありました。(これはもっと良い指定方法があるかもしれない)
  • AIから分析指示をした際、分析対象期間を長期間にしてしまったため、膨大なデータが一度に対象となり、モデル側のコンテキストウィンドウの制限に引っ掛かってしまいました。結果、エラーが発生し分析が完了しないなど課題が出ました。

まとめ

CloudWatch Logs に出力されたSession Managerのログは、人間がそのまま眺めるには非常に見づらいものでした。
しかし、MCPサーバを使うことで、ログを直接ひたすら眺める代わりに、AIに分析を依頼できる環境が構築できたことは大きな収穫です。
パフォーマンスやコンテキストウィンドウの制限、リージョン指定の方法など運用上の課題があり、まだ正解は見出せていない箇所もあります。
今後は、ログ量を適切に区切る／システムプロンプトを精緻に設計する／MCPサーバのパラメータや運用設計をチューニングすることで、さらに使える仕組みに育てていきたいと思います。
コンテキストウィンドウの制限については、後日別の記事を書く予定ですので気になる方は見てみてください。

Logspect Tech Blog
Logspect Tech BlogPublication

ログスペクト株式会社の技術ブログ

Discussion