8
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@YShiba92
in

【実機検証】AWS Observability Kiro Power を ECS Fargate 環境で試したら、AIが脆弱性スキャンと設定ミスを自動で見つけてくれた話

8
Last updated at Posted at 2026-03-17

免責事項
本記事は筆者個人の見解であり、所属組織の公式見解・開発体制・業務内容を示すものではありません。
記事内の技術的表現は、2026年3月時点の一般的な理解に基づくものであり、特定の製品・サービスの性能を保証するものではありません。
※環境名・ロググループ名・件数など一部の値は、検証内容を損なわない範囲で匿名化・丸め込みをしています。

はじめに

こんにちは！Dirbatoの社内技術横断支援組織Backbeatに所属している柴田です！
今回は、先月発表された以下のAWS ServiceUpdateの検証記事です。

2026年2月、AWS から 「AWS Observability as a Kiro Power」 というアップデートが発表されました。

Kiro IDE にワンクリックで 4 つの MCP サーバー（CloudWatch / Application Signals / CloudTrail / AWS Docs）を導入し、AI エージェントがオブザーバビリティ業務を支援してくれる

正直、「ログ見るだけなら CloudWatch コンソールでよくない？」と思っていました。

それが甘かったです。

実際に ECS Fargate を用意したテスト環境で検証したところ、AIエージェントが 脆弱性スキャンの痕跡 と 意図的に仕込んだ設定ミス を自動で発見してくれました。コンソールをポチポチしていたら気づかなかったと思います。
　※CloudTrail の生ログは読解コストが高く、手動分析にはそれなりの負荷があります。

本記事では、セットアップから4つのMCPサーバーの検証結果まで、実機ベースでまとめます。

:dart: こんな人に読んでほしい

  • Kiro IDE を使っていて、Observability 系の Power が気になっている人
  • CloudWatch / CloudTrail を日常的に使うインフラエンジニア
  • 「AI でオブザーバビリティ」って実際どうなの？と思っている人
  • ECS Fargate 環境のログ分析・セキュリティ監査を効率化したい人

:bulb: 要点サマリー

忙しい方向けに先に結論を。

MCP サーバー 一言評価
:white_check_mark: CloudWatch MCP 最も実用的。 ログの自動分類 + CVE 特定 + 対策提案まで自律的にやってくれる
:white_check_mark: CloudTrail MCP セキュリティ分析が秀逸。 段階的フォールバック + リスクレベル判定が実運用レベル
:warning: Application Signals MCP 未導入環境では「0件」で正常応答。導入ガイダンスの提示は適切　※私の環境ではApplication Signals未導入
:white_check_mark: AWS Docs MCP 文脈を踏まえたドキュメント検索が地味に便利。コンテキスト切替不要

:key: 最大の発見: コンソールでは見逃しがちな問題（脆弱性スキャンの痕跡、検証用に再現した構成ミス）をAIが自動検出

1. AWS Observability Kiro Power とは

2026年2月に発表されたサービスアップデートです。

  • 公式アナウンス: AWS What's New
  • Kiro IDE に 4つのMCPサーバー をワンクリックで導入
  • 8つのステアリングガイド（インシデント対応、アラート、パフォーマンス監視、セキュリティ監査、ギャップ分析等）が同梱
  • AIエージェントが CloudWatch・CloudTrail のデータに直接アクセスし、調査→分析→提案 まで自律的に実行

ポイントは「MCP サーバーを個別に入れる」のではなく、Power として統合的に導入される こと。ステアリングガイドによって、AIエージェントの調査戦略が「経験あるSREの調査プロセス」に近い動作になります。

2. セットアップ

2-1. 検証環境

項目 内容
OS Windows 10（WSL2 Ubuntu 24.04）
IDE Kiro IDE v0.11.34（Windows版）
AWS リージョン ap-northeast-1（東京）
検証対象 ECS Fargate クラスタ

2-2. Kiro IDE インストール

https://kiro.dev/downloads/ からWindows版をダウンロード・インストール。
VS Code ベースなので、操作感はほぼ同じです。

2-3. :rotating_light: ハマりポイント① — uvx が必要

Power インストール後、Output パネルにこんなエラーが出ました。

[warning] Log from MCP Server: 'uvx' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。
[error] Error connecting to MCP server: MCP error -32000: Connection closed

MCP サーバーは uvx（uv パッケージマネージャ）経由で起動するため、Windows 側に uv のインストールが必須です。

推奨
uv の導入は公式ドキュメントに従って実施してください。

企業端末では、社内承認済みの配布手段やセキュリティポリシーに従うことを推奨します。

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

WSL 側に uv が入っていても、Kiro IDE は Windows プロセスなので見えません。

2-4. :rotating_light: ハマりポイント② — 初回タイムアウト

uv を入れて再起動しても、今度は タイムアウト で失敗しました。

[warning] Log from MCP Server: Downloading scipy (35.6MiB)
[warning] Log from MCP Server: Downloading botocore (14.0MiB)
[warning] Log from MCP Server: Downloading numpy (11.9MiB)
...
[error] Error connecting to MCP server: MCP error -32001: Request timed out

初回起動時に MCP サーバーが大量の Python パッケージ（合計 100MB 以上）をダウンロードするため、Kiro の接続タイムアウトに引っかかります。

対処法: もう一度 Kiro IDE を再起動する。 2回目以降はキャッシュから読まれるので一瞬で接続されます。

2-5. 接続成功

再起動後、Output パネルで4つすべてに Successfully connected が表示されれば OK です。

[info] [cloudwatch-mcp-server] Successfully connected and synced tools and resources
[info] [cloudwatch-applicationsignals-mcp-server] Successfully connected and synced tools and resources
[info] [cloudtrail-mcp-server] Successfully connected and synced tools and resources
[info] [aws-documentation-mcp-server] Successfully connected and synced tools and resources

3. 検証結果

3-1. CloudWatch MCP Server — ログ分析で脆弱性スキャンを自動検出

プロンプト:

/ecs/test-container ロググループの直近1時間のログを表示して

AIエージェントの動き:

ここが面白いところです。単にクエリを投げるだけじゃなく、自律的に調査を進めてくれました。

  1. Log Insights クエリ実行 → 直近1時間にログなし（UTC/JST の差異）
  2. 自動的に時間範囲を拡大 → 再クエリ
  3. describe_log_groups で 8 ロググループのメタデータ取得 → データ量を確認
  4. さらに広範囲でクエリ → 約5万件をスキャン、ログ取得成功

「直近1時間にログがない」と分かったら、勝手に範囲を広げてくれる。これはコンソールだと「あれ、ログないな...時間変えよ...」を手動でやる作業です。

分析結果:

AI がログを自動分類し、3カテゴリに整理してくれました。

カテゴリ 内容
ELBヘルスチェック GET / → 200、30秒間隔（大半）
:rotating_light: 脆弱性スキャン PHPUnit RCE（CVE-2017-9841）を狙った自動スキャン
一般アクセス iPhoneからのアクセス（1件）

特に注目すべきは 脆弱性スキャンの自動検出 です。

GET /zend/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php → 404
GET /yii/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php → 404
GET /laravel/vendor/phpunit/... → 404
User-Agent: libredtail-http

AI が「これは CVE-2017-9841 を狙った自動スキャン攻撃です。すべて 404 で返しているので実害はありませんが、WAF の導入を検討してもよいかもしれません」とコメント付きで報告してくれました。

CVE 番号の特定、影響度の判定、対策の提案までワンショットです。

3-2. CloudTrail MCP Server — 設定ミスを自動で発見

プロンプト:

テスト環境のECS関連のCloudTrailイベントを直近24時間分表示して、
セキュリティ上の懸念がないか分析して

:rotating_light: ハマりポイント③ — IAM権限不足

最初は AccessDeniedException で失敗しました。が、AIエージェントの対応が秀逸でした。

  1. CloudTrail Lake → ListEventDataStores で AccessDenied
  2. CloudWatch Logs → CloudTrail ログのロググループなし
  3. Lookup Events API → LookupEvents で AccessDenied
  4. 必要なIAMアクションを具体的に提案 :arrow_down:

推奨
以下は検証時kiro powerからの提案されたIAM権限です。（そのまま環境適用は非推奨）

運用環境では、対象リソースの限定、条件キーの活用、専用のReadOnlyロール付与など、最小権限での設計を推奨します。
※ただし、CloudTrail の一部アクションは Resource: "*" 前提となる場合があります。

{
  "Effect": "Allow",
  "Action": [
    "cloudtrail:LookupEvents",
    "cloudtrail:ListEventDataStores",
    "cloudtrail:StartQuery",
    "cloudtrail:GetQueryResults"
  ],
  "Resource": "*"
}

ステアリングガイドに定義された データソース優先順位 に従って、Lake → CW Logs → Lookup API と段階的にフォールバックしてくれます。単に「権限がない」で終わらず、「これを追加すれば動く」まで教えてくれるのが良い。

権限追加後の分析結果:

50件のイベントを取得し、以下のセキュリティ分析を 自動実行 しました。

リスクレベル イベント 件数 分析内容
:red_circle: 重大 RegisterContainerInstance AccessDenied 49件 管理用ホスト相当のノードから、意図しないECS登録試行を複数回検知
:warning: 注意 ListServices 成功 1件 IAM ユーザーからの読み取り操作（正常）

AI の分析ポイント:

  • 意図しないECSエージェント起動: 管理用ホスト相当のノードに ECS エージェントが自動起動している。当該ホストが ECS クラスターに参加する必要はないので、設定ミスの可能性大　
    👉これは検証シナリオとして意図的に再現した挙動で、CloudTrail MCPが想定通り検出できることを確認できました。
  • 最小権限の原則への違反: 不要な書き込み操作を試みていること自体が問題
  • ノイズリスク: 7分間で49回の AccessDenied ログ。本当に重要なセキュリティイベントが埋もれる

これは検証用に分離したサブ環境で再現したシナリオでしたが、関連イベントまで横断的に検出できることを確認できました。

3-3. Application Signals MCP Server — 未導入環境での挙動

プロンプト:

テスト環境のApplication Signalsデータを表示して。APMの導入状況を確認したい

検証環境には APM を導入していないため、想定通り「サービス0件」の結果でした。

ただし、AI の対応は適切でした:

  1. ワイルドカード検索 → 0件
  2. 全サービス一覧 → 0件
  3. リージョンを変えて再検索 → 0件
  4. 原因候補の提示 + 次のアクション提案

Application Signals がまだ有効化されていない、OpenTelemetry/X-Ray SDK の計装がされていない、等

壊れるのではなく「何が足りないか」を教えてくれるので、導入検討のきっかけとしても使えます。

:warning: 注意点: Application Signals MCP のデフォルトリージョンが us-east-1 になっていました。東京リージョンで使う場合は明示的な設定が必要です。

3-4. AWS Documentation MCP Server — 文脈を踏まえたドキュメント検索

プロンプト:

ECS FargateでApplication Signalsを有効化する手順をAWSドキュメントから調べて

検証Cで「APM未導入」と分かったので、そのままドキュメント検索に繋げました。

AI が実行したこと:

  1. search_documentation で関連ドキュメントを5件ランキング
  2. メインドキュメント CloudWatch-Application-Signals-Enable-ECSMain.html を特定
  3. read_documentation で詳細手順を取得
  4. 追加ドキュメントからサイドカー方式の Step-by-Step 手順を取得

出力された回答:

  • Fargate ではサイドカー方式のみサポート と明確に回答
  • 4ステップの具体的手順を整理
  • 言語別（Java / Python / .NET / Node.js）の init コンテナイメージ一覧
  • コピー可能なタスク定義 JSON を生成
  • 「テスト環境のアプリケーション言語がわかれば具体的な設定を出せます」と追加質問

ブラウザに切り替えてドキュメントを探す手間がゼロになります。検証のコンテキスト（APM未導入のECS Fargate環境）を理解した上で最適なドキュメントを引いてくれるのが良い。

4. 総合評価

観点 評価 コメント
導入容易性 :star::star::star: ワンクリック導入だが、uvx・タイムアウト・IAM権限で3回つまずく
CloudWatch 連携 :star::star::star::star::star: 自律的な時間範囲調整 + ログ自動分類 + CVE 特定が秀逸
CloudTrail 連携 :star::star::star::star::star: 段階的フォールバック + 設定ミス発見 + リスクレベル判定が実用的
Application Signals 連携 :star::star::star: 未導入環境での挙動は適切。導入済み環境での検証が今後の課題
Docs 連携 :star::star::star::star: 検索精度・文脈理解が高い。長大ドキュメントの切り詰めが惜しい
MTTR 短縮効果 :star::star::star::star::star: コンソール手動調査と比較して、分析完了までの時間が大幅に短縮

5. 従来手法との比較

操作 従来（コンソール） Kiro Power
ログ検索 CW コンソール → ロググループ選択 → Insights クエリ作成 → 実行 → 結果解釈 自然言語で指示 → 自動クエリ → 自動分類・分析
CloudTrail 調査 CloudTrail コンソール → イベント履歴 → フィルタ設定 → 手動で1件ずつ確認 自然言語で指示 → 自動取得 → リスクレベル判定・推奨対応提示
ドキュメント参照 ブラウザで AWS ドキュメント検索 → 該当ページ探索 → 読解 IDE 内で質問 → 複数ドキュメント横断検索 → 要約回答

最大の違いは「分析まで自動でやってくれる」こと。コンソールだとログを取得するところまでは簡単ですが、「このログが何を意味するか」の解釈は人間の作業 でした。Kiro Power ではその部分まで AI が担ってくれます。

6. 導入時の注意点まとめ

これからセットアップする方向けにハマりポイントを整理します。

ハマりポイント 原因 対処法
'uvx' は認識されていません Windows 側に uv 未インストール uvを公式手順で導入（企業端末は社内承認済み手順を優先）
Request timed out（初回） 大量パッケージ DL 中にタイムアウト Kiro IDE を再起動（2回目はキャッシュで即接続）
AccessDeniedException CloudTrail / Application Signals の IAM 権限不足 必要最低限の IAM ポリシーを追加
Application Signals が us-east-1 参照 デフォルトリージョン設定 MCP サーバー設定でリージョンを明示的に指定

7. 所感

「SREの調査プロセス」に近い動作をする

単なる API ラッパーではないと感じました。ステアリングガイドによって、AI エージェントの調査戦略が方向づけられており、「まずログを見て、異常があればメトリクスを確認し、原因を特定して対策を提案する」 という、経験あるエンジニアの思考プロセスに近い動作をします。

異なるレイヤーの問題を相補的にカバー

今回の検証で発見した2つのセキュリティ課題:

  • CloudWatch MCP: アプリ層の脆弱性スキャン検出（CVE-2017-9841）
  • CloudTrail MCP: インフラ層の設定ミス検出（検証用に再現したECS登録試行）

この2つは異なるレイヤーの問題であり、4つのMCPサーバーを 統合して使う価値 が明確に感じられました。

新規参画者のオンボーディングにも

AWS コンソールの操作に慣れていなくても、自然言語で環境の状態把握ができます。Docs MCP との連携で「なぜこうなっているか」の学習も同時にできるので、新メンバーの立ち上がり期間の短縮 にも効果がありそうです。

おわりに

正直、「ログを見るだけなら CloudWatch コンソールでいいのでは」と思って検証を始めましたが、実際に動かしてみると 「分析→判断→提案」のサイクルが自動化される 体験は想像以上でした。

特に CloudWatch MCP と CloudTrail MCP の組み合わせは、セキュリティ監査やインシデント対応の初動として十分実用レベルです。

導入時の3つのハマりポイント（uvx、タイムアウト、IAM権限）さえクリアすれば、Kiro IDE ユーザーなら試す価値は確実にあります。

参考リンク:

8
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
8
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?