9月26日、AWSが「AI best practices for AWS network operations with AI agents and MCP」と題した記事を公開した。この記事では、AIエージェントとModel Context Protocol（MCP）を活用してAWSネットワーク運用を自動化・高度化するためのベストプラクティスが詳しく紹介されている。
午前2時47分のインシデント：なぜエージェントが必要か
VPC間のトラフィックが突然ドロップし、3リージョンでCloudWatchアラームが連鎖発火する。オンコールエンジニアはフローログ、セキュリティグループ、NACL、Cloud WANセグメントを行き来しながら、数十リソースにまたがるネットワークパスを頭の中で繋ぎ合わせようとする。
AWSはこの状況を「3つの構造的障壁」として整理している。
- シグナル対ノイズ比：テレメトリの量がリアルタイムで人手処理できる限界を超えている
- マルチドメイン専門性：1件のインシデントが、ルーティング・ファイアウォール・DNS・ロードバランサーの同時知識を要求する
- 同一症状・異原因：TCPタイムアウトの原因はTGWのルート欠損かもしれないし、VPN不安定・NACLのルールギャップ・Network Firewallのルールかもしれない
AIエージェントはこれらに対して構造的な優位を持つ。複数サービスをまたいだテレメトリ相関を自動化し、すべてのデータソースを並列クエリして知識のギャップを埋め、根本原因の特定を「数時間から数分」に圧縮する。
スタック全体像：4つのレイヤー
記事が提示するAI NetOpsスタックは以下の4層で構成される。
- オーケストレーションエージェント（Kiro IDE、Amazon Bedrock AgentCore、AWS DevOps Agent）
- MCPサーバー群（AWS Network、CloudWatch、IAM、IaC、PCAP Analyzer、Knowledge Bases等）
- ガバナンスレジストリ（AWS Agent Registry）
- マルチアカウント・マルチリージョン対応ランタイム
エージェントの選択は用途で決まる。記事は以下の比較表を提示している。
| ディメンション | DevOps Agent | カスタム（Bedrock AgentCore） | IDEエージェント |
|---|---|---|---|
| 最適用途 | 本番インシデントの自動対応 | 組織固有のワークフロー | アドホックなトラブルシューティング |
| トリガー | CloudWatchアラーム（ゼロタッチ） | API呼び出し・イベントルール・手動 | エンジニアがプロンプトを入力 |
| セットアップ工数 | 最小 | 中程度 | 最小 |
| メモリ | 過去の調査から学習 | AgentCoreメモリがセッション横断で永続化 | ステートレス（セッション内のみ） |
| ガバナンス | Agent Space境界、IAM、監査証跡 | フルIAM、Observability、Agent Registry | 個人IAMクレデンシャル、中央監査なし |
※「IDEエージェント」列は、元記事の文脈ではKiro IDEを主な対象として説明されている。他のIDEやBedrockプラグインへの適用可否は元記事を直接参照されたい。
DevOps AgentはCloudWatchアラームが発火した瞬間から自動調査を開始する最速の選択肢だ。Dynatrace・Datadog・Grafana・PagerDutyなど主要な監視ツールとのWebhook連携にも対応している。
最も重要なユースケース：診断手順のコード化
記事が「最もインパクトの大きいユースケース」として筆頭に挙げるのが、診断ロジックの構造化だ。
エージェントにアドホックなツール呼び出しをさせるのではなく、ネットワークトリアージの手順をSKILL.mdファイルとして記述し、バージョン管理されたリポジトリに格納する。企業ガバナンスが必要な場合はAgent Registryに公開する。
SKILL.mdはKiro IDEが採用するエージェントスキル定義の仕組みで、マークダウン形式でツール呼び出し順序・停止条件・コンテキスト情報をエージェントに与えるものだ。元記事ではKiro IDEおよびBedrock AgentCoreベースのカスタムエージェントにおけるベストプラクティスとして紹介されている。
# Network Triage Skill
## Investigation Order
1. Check active CloudWatch alarms (cloudwatch_list_active_alarms)
2. Trace the network path (trace_network_path)
3. Query VPC flow logs for REJECT entries (query_vpc_flow_logs)
4. Inspect security groups and NACLs (get_security_group_rules)
5. Check TGW route tables (get_all_tgw_routes)
## Stop Condition
Halt at the first confirmed fault. Do not continue investigation after root cause is identified.
この「最初に確認できた障害で停止する」というストップ条件が重要だ。エージェントが不要なツール呼び出しを連鎖させず、トークン消費と調査時間を抑制する。
格納場所はエージェントタイプで異なる：DevOps Agentはコンソールでスキルを作成、カスタムAgentCoreエージェントはGitまたはS3に置いてプロンプトで参照、IDEエージェントはプロジェクトリポジトリに置く。
その他のコアユースケース
設定変更管理では3ステップを自動化する。変更前にsimulate_cloud_wan_route_changeで非対称ルーティングや経路消失リスクを検証し、変更中はリアルタイムでルート伝播を監視、変更後はPCAPキャプチャを取得してanalyze_tcp_retransmissionsでアラーム閾値以下の微細な劣化を検出する。
オペレーショナルインテリジェンスでは、単一メトリクスでは見えない障害を相関で検出する。「フローログのREJECT率増加」＋「同一時間帯のセキュリティグループのCloudTrail変更」を組み合わせて初めてポリシー変更が原因だと特定できる、という例が示されている。
実装のベストプラクティス
記事が強調する落とし穴をいくつか挙げる。
- IAMパーミッションの完全性：
logs:GetQueryResultsのような1つの欠落が、フローログ分析をサイレントに破壊する。推奨IAMポリシーを初日から全量デプロイすること。 - リソースタグの一貫性：タグなしの
tgw-attach-0abc123より、Environment=Production, Service=PaymentAPIが付いたアタッチメントの方が、エージェントが出せる調査コンテキストは劇的に豊かになる。 - プロンプトの精度：曖昧なプロンプトはエージェントに全データを引かせてトークンを浪費する。時間ウィンドウ・エンドポイント・スキップリストを明示したプロンプトが推奨されている。
- コスト管理：VPC Traffic MirroringはENI-時間課金のため、継続モニタリングではなく目的を絞った時間限定セッションのみで使う。
MCPサーバーの推奨構成については、元記事内でJSON設定とIAMポリシーのサンプルがaws-samplesのGitHubリポジトリとして紹介されている（リンク先は元記事が参照している外部リソースであり、内容は元記事公開時点のものを参照されたい）。
詳細はAI best practices for AWS network operations with AI agents and MCPを参照していただきたい。
