はじめに 業界調査（2024〜2026年） によると、SAP のネットワーク障害は企業に平均で1時間あたり10万ドルのコストをもたらすと推定されています。それにもかかわらず、従来のトラブルシューティングでは依然として複数のツールをまたいで2〜4時間の手作業が必要です。 Kiro-CLI と AWS Model Context Protocol (MCP) Servers（Agent Toolkit の一部） は、この状況を変えます。このエージェント型 AI アプローチにより、数十個の CLI コマンドを暗記する代わりに自然言語を使って、複雑な SAP ランドスケープ全体のネットワーク接続性の問題を数分で診断・解決できます。 今日、SAP のネットワーク運用チームの作業を遅らせている課題は3つあります。 複雑なネットワーク診断：複数の AWS サービスに関する深い知識が求められ、インシデント対応に何時間も上乗せされます。 時間のかかる接続性分析：VPC Flow Logs、ルートテーブル、セキュリティグループを手作業で突き合わせると、私たちの経験ではインシデントあたり運用チームに2〜4時間かかることがあります。 断片化したネットワークヘルス監視：複数のネットワーク境界が存在する RISE with SAP のデプロイメントで顕著です。 本記事では、以下の方法を学びます。 MCP Server と Kiro-CLI を組み合わせて SAP のネットワークトラブルシューティングを簡素化する。 自然言語コマンドで自動ネットワークヘルスチェックを実行する。 複雑な CLI 構文を平易な英語のクエリに置き換えて診断を効率化する。 実例を用いて、よくある5つの SAP ネットワーク問題を解決する。 接続が AWS アカウント境界をまたぐ RISE with SAP 環境を監視する。 次の図は、RISE with SAP on AWS のデプロイメントにおける MCP Server と Kiro-CLI のユースケースシナリオを示しています。 図1. RISE with SAP 環境における MCP Server と Kiro-CLI の連携を示すアーキテクチャ図 Kiro-CLI とは？ Kiro-CLI は、AI 支援によるトラブルシューティングをコマンドラインのワークフローに直接もたらします。複雑な VPC Flow Log のクエリ構文を暗記する代わりに、「SAP アプリケーションサーバーで拒否されたすべてのネットワークトラフィックを見せて」といった質問をするだけで、Kiro がそのリクエストを正しい CLI コマンドに変換して実行します。 SAP 管理者やネットワークエンジニアにとって、この変換こそが中核機能です。Kiro-CLI は会話形式のリクエストを、VPC・サブネット・セキュリティグループの構成にまたがる正確なネットワークコマンドに変換します。単一のコマンドにとどまらず、関連するコマンドも提案するため、ドキュメントを探すことなく包括的なネットワーク分析を実行できます。また、何らかの障害が発生した場合には、複雑なネットワーク問題に対するステップバイステップの修復ガイダンスを返します。さらに、構成変更を適用する前にその影響を説明してくれるため、少数の専門家に依存するのではなく、チーム全体が時間をかけてネットワークの専門知識を蓄積できます。 SAP ネットワーク診断のための MCP Servers マネージドな AWS MCP Server が、本ブログで使用するネットワーク機能を提供します。これは、すべての AWS API アクセスを単一のエンドポイントに集約し、AWS CloudTrail による監査を組み込んでいます。次の表は、各サーバーを適用可能なユースケースに対応付けたものです。 Kiro-CLI と MCP Servers の連携 Kiro-CLI は自然言語インターフェイスであり、MCP Servers は AWS 環境に手を伸ばす「手」です。リクエストを入力すると、Kiro-CLI が意図を解釈し、適切な MCP Server のツールを選択し、サーバーがユーザーに代わって基盤の AWS API を呼び出します。結果は平易な英語で読むことができ、Kiro-CLI がコンテキストを保持するため、同じセッション内でフォローアップの質問ができます。セットアップは30〜60分の一度きりの作業で、その後はすべての診断がひとつのプロンプトで完了します。 大まかには、2つを連携させるには3つのステップがあります。コマンドラインツールをインストールし、使用する MCP Servers を登録し、環境に到達できることを確認します。まず、macOS・Linux・Windows それぞれのプラットフォーム手順に従って Kiro-CLI をインストール します。次に、Kiro-CLI の構成ファイルに MCP Servers を登録し、単一のマネージド AWS MCP Server を構成します。最後に、「list my VPCs」のようなシンプルな読み取り専用プロンプトを実行し、本格的な診断を試みる前に Kiro-CLI が認証してアカウントに到達できることを確認します。 その効果は、CLI の複雑さから平易な英語への移行です。次の比較は、ネットワークエンジニアが通常入力する手作業のアプローチと、それに相当する Kiro-CLI のリクエストを示しています。 従来の CLI（「ビフォー」） Kiro-CLI（「アフター」） aws ec2 describe-flow-logs –filter … の後に aws logs start-query –log-group-name … –query-string ‘fields … | filter action=”REJECT” …’、続いて get-query-results をポーリングし、describe-security-groups の出力を手作業で相互参照する 「過去12時間で SAP アプリケーションサーバーに対して拒否されたすべてのネットワークトラフィックを見せて。どのセキュリティグループルールがブロックしているかも教えて。」 正確なフラグ構文、ロググループ名、CloudWatch Logs Insights のクエリ言語を思い出し、3〜4個のコマンドにまたがって手作業で相関を取る必要があります。 一文で済みます。Kiro-CLI が適切な MCP Server ツールを選択し、クエリを実行し、相関の取れた回答を返します。 このメンタルモデルを踏まえ、次のセクションでは初回実行の前に必要なものを正確に列挙します。 前提条件 初回実行の前に、おおよそ30〜60分を確保し、AWS ネットワーキングと SAP Basis 管理に関する中級レベルの知識があることを確認してください。作業はインフラストラクチャ、監視、ツール、IAM 権限、セキュリティの5領域に分かれます。以下のチェックリストは飛行前点検のように扱ってください。ほとんどの SAP ランドスケープはインフラと監視の項目をすでに満たしているため、実際のセットアップ時間は Kiro-CLI のインストールと MCP Servers の登録に費やされます。 インフラストラクチャ： AWS Launch Wizard for SAP を使用して高可用性構成でデプロイした SAP S/4HANA。該当する場合は Amazon VPC ネットワーキング と AWS Transit Gateway を構成します。 VPC Flow Logs を有効化します。 監視： VPC Flow Log ストリームを受け取るように構成した ロググループ付きの Amazon CloudWatch を有効化します。別途、 Transit Gateway flow logs を有効化します。 ツール ： Kiro-CLI をインストール します。その後、 AWS MCP Server を構成します。 IAM 権限 ：CloudWatch ネットワーク監視、VPC Flow Log アクセス、Transit Gateway 監視、AWS Systems Manager の実行。最小権限アクセスを適用します。 セキュリティ： ネットワーク構成変更のために AWS CloudTrail を有効化し、ネットワークトラフィックの暗号化を実装し、Kiro-CLI のセキュリティベストプラクティスを確認します。 ユースケース1：SAP ネットワークヘルスチェック SAP 環境が複数の VPC とアベイラビリティーゾーンにまたがると、手作業のネットワーク検証は大きなボトルネックになります。構成の不備があるコンポーネントは可視性のギャップを生み、チームは1つずつヘルスを検証するのに何時間も浪費させられます。単一の自然言語プロンプトで、すべてのコンポーネントにわたる包括的なヘルスレポートを同時に生成できます。 サンプルプロンプト Perform a comprehensive network health check for our SAP S/4HANA 2023 system. Analyze VPC Flow Logs, security group configurations, and network performance metrics. Generate a complete health report including executive summary, performance metrics, and security analysis. 出力（要約） === SAP S/4HANA 2023 Network Health Report === Network Uptime: 100% (last 24 hours) Accepted Connections: 225,301 | Rejected: 4,676 (blocked by SG rules) Overall Health Score: 96.6 / 100 Avg Latency (app-to-DB): 1.2 ms | Peak Bandwidth: 68% | Packet Loss: 0.00% SAP App Server <-> DB Layer: HEALTHY RISE with SAP endpoints: REACHABLE | Transit Gateway attachments: ACTIVE Scorecard: Connectivity 98 | Security 96 | Performance 95 | Redundancy 98 Forecast: No capacity constraints projected for next 30 days 要点 単一コマンドでの可視化： ひとつのプロンプトで、エグゼクティブ向けヘルススコアカード、セキュリティ体制の分析、30日間のキャパシティ予測を生成します。これは以前は複数のツールと手作業の相関付けを必要とした作業です。 セキュリティ検証を標準装備： セキュリティグループ違反がゼロであること、そして拒否された4,676件の接続試行を確実にブロックしていることが、即座の監査証跡になります。 プロアクティブなキャパシティ洞察： 30日間の予測により、運用チームは飽和イベントに反応するのではなく、事前に計画を立てる時間を得られます。 図2. ネットワークヘルスチェックの出力 — マルチ AZ の SAP インフラストラクチャ状態（スコア：96.6/100） ユースケース2：RISE with SAP — 504 Gateway Timeout RISE with SAP 環境の Application Load Balancer (ALB) で発生する 504 Gateway Timeout を解決するには、ネットワーク・セキュリティ・アプリケーションのいずれの障害かを迅速に切り分ける必要があります。分離された複数のコンソールをまたぐ手作業の検証は、クリティカルな SAP 環境には遅すぎます。Kiro-CLI はこの多層検査を自動化し、何時間もかかる診断の探索を単一コマンドの実行に変え、根本原因を数秒で提示します。 サンプルプロンプト Troubleshoot the 504 Gateway Timeout error on our RISE with SAP system. The ALB health checks are failing. Analyze network connectivity, security group configurations, and application health on port 44300. 出力（要約） === RISE with SAP Connectivity Troubleshooting Report === Step 1: Target 10.0.1.45:44300 - Status: UNHEALTHY Reason: sg-0a1b2c3d blocking ALB health check source on /sap/public/ping Step 2: SAP ICM service: RUNNING | Port 44300 from within VPC: YES Step 3: VPC routing: CORRECT | TGW attachment: ACTIVE | NACLs: No blocks Root Cause: sg-0a1b2c3d missing inbound rule from ALB SG (sg-alb-9x8y7z) on 44300 Fix: Add inbound rule - Source: sg-alb-9x8y7z | Port: 44300 | Protocol: TCP Resolution: ALB health check -> HEALTHY | 504 errors resolved 要点 構造化された3ステップ診断： Kiro-CLI は、正確な根本原因を特定する前に、ALB ターゲットのヘルス、アプリケーションのヘルス、ネットワークインフラストラクチャという各潜在原因を体系的に排除します。 アプリケーションとネットワークの切り分け： 出力は SAP ICM サービスが正常であり、ポート 44300 が VPC 内から到達可能であることを確認し、問題がアプリケーションではなく単一のセキュリティグループルールにあることを特定します。 図3. 504 Gateway Timeout — SAP ICM プロセスの根本原因調査と解決 ユースケース3：クロス AZ レイテンシー診断 クロス AZ レイテンシーは、MRP や期末決算といったクリティカルな SAP バッチジョブを運用上のボトルネックに変えてしまいます。本記事の例のシナリオでは、バッチサーバーの配置ミスによってパフォーマンスが約10倍低下しています。これを解決するのに、Amazon CloudWatch メトリクスや配置データをめぐってチーム間で何時間も責任を押し付け合う必要はありません。レイテンシーがサプライチェーンや財務決算を遅延させるのを止めるには、即座の可視性が必要です。 サンプルプロンプト Analyze cross-AZ network latency for our SAP S/4HANA system. Identify which application servers are communicating cross-AZ to the HANA database. Compare measured latency against SAP recommended thresholds and recommend optimizations for performance-critical batch jobs. 出力（要約） コンポーネント AZ レイテンシー（24時間平均） SAP しきい値ステータス HANA Primary DB us-east-1a — — App Server 1 us-east-1a（同一 AZ） 0.18 ms ✓ GOOD (<0.3 ms) App Server 2 us-east-1b（クロス AZ） 0.92 ms ✗ BELOW AVG (>0.7 ms) App Server 3 us-east-1c（クロス AZ） 0.85 ms ✗ BELOW AVG (>0.7 ms) 根本原因：App Server 2（u-6tb1.metal）の C-state 構成がデフォルトのままであり、レイテンシーを 0.7 ms から 0.92 ms に押し上げています。この例では processor.max_cstate=1 を設定することでレイテンシーが約 0.15 ms に低減しました。バッチサーバーグループ ZBATCH には現在 App Server 2 と 3 が含まれており、ここで測定した MRP およびバックフラッシュのジョブで RFC 実行が4〜8倍遅くなっていました。 要点 即座の根本原因特定： 大型のメタルインスタンスにおける C-state のチューニングは、このシナリオで最も効果の大きい単一の修正でした。インフラストラクチャを変更することなくレイテンシーを約5倍低減しました。 インフラ変更不要の修正が利用可能： バッチサーバーグループ ZBATCH を同一 AZ の App Server 1 に再割り当てするには SAP の構成更新だけで済み、バッチジョブのパフォーマンスを即座に改善できます。 SAP しきい値によるベンチマーク： SAP Note 1100926 のしきい値（≤0.7 ms）に照らして測定することで、生のレイテンシー数値を実行可能な合否基準に変換します。 図4. クロス AZ レイテンシー — アプリケーションサーバーから HANA へ、パフォーマンス最適化の推奨事項付き ユースケース4：セキュリティグループのドリフト検出 1つのセキュリティグループの削除が、SAP ランドスケープ全体を静かに麻痺させることがあります。こうした変更は明確なエラーメッセージをほとんど発生させないため、チームは壊れた箇所を見つけるためだけに、複数の AWS サービスをあてもなく探し回って貴重な時間を浪費します。 サンプルプロンプト Our SAP application servers lost RFC connectivity to the central instance after last night's maintenance window. Analyze VPC Flow Logs for rejected traffic on SAP ports, identify which security group changes caused the issue, and recommend the fix. 出力（要約） === SAP Security Group Drift Analysis === Rejected Traffic (last 12 hours): Port 3200 (SAP Dispatcher): 12,847 packets | Source: 10.0.2.0/24 Port 3300 (SAP Gateway): 3,221 packets | First rejection: 02:14:00 UTC CloudTrail Attribution: Change: 2024-09-15 02:12:33 UTC | SG: sg-0abc1234 (sap-central-instance-sg) Action: RevokeSecurityGroupIngress User: arn:aws:iam::123456789012:user/network-admin Removed: TCP 3200-3399 inbound from 10.0.2.0/24 Root Cause: Cleanup script mistook SAP dispatcher/gateway rule for legacy rule Fix: Add inbound rule - Ports 3200-3399 | Source: 10.0.2.0/24 | Protocol: TCP Security Validation: Internal subnet only ✓ | No internet exposure ✓ 要点 数秒での確定的な原因特定： 拒否されたトラフィックのタイムスタンプを CloudTrail イベントと相関させることで、正確なユーザー、正確なタイムスタンプ、削除された正確なルールを特定でき、何時間もの当て推量を排除します。 安全な修復： 推奨される修正は適用前にセキュリティのベストプラクティスに照らして検証されるため、過度に緩いルールが導入されることはありません。 プロアクティブな保守体制： メンテナンスウィンドウのたびにこのクエリを実行すれば、ユーザーが障害を報告する前にドリフトを検出でき、リアクティブな対応をプロアクティブなガバナンスに変えられます。 図5. RFC 接続障害 — セキュリティグループのドリフト診断フローと根本原因分析 ユースケース5：ネットワークキャパシティ予測 SAP のネットワーク飽和は一夜にして起こるものではありません。オーガニックなビジネス成長がユーザーアクティビティを押し上げ、より負荷の高いデータベースクエリがパイプラインに重い負担をかけるにつれて、静かに蓄積されていきます。これらの複合要因が障害を引き起こすまで待つことは、ネットワーク管理を完全にリアクティブなものにします。60日分の過去スループットを分析し、実際の成長率をインスタンスの上限に対して予測することで、この流れを逆転できます。運用に支障をきたす30〜60日前に、正確なネットワーク制約を特定できます。 サンプルプロンプト Analyze network capacity trends for our SAP production VPC over the last 60 days. Identify any components approaching capacity limits and forecast when we will need to scale. Focus on instance bandwidth, Transit Gateway throughput, and NAT Gateway utilization. 出力（要約） コンポーネント 現在のピーク 上限 使用率 予測される超過 HANA DB (x2idn.32xlarge) 42 Gbps 50 Gbps 84% 38日 — 対応が必要 App Server 1 (r6i.8xlarge) 8.1 Gbps 12.5 Gbps 65% ✓ 11か月 — 対応不要 Transit Gateway (SAP Prod) 38 Gbps 50 Gbps 76% 57日 — 45日以内に計画 NAT Gateway 32 Gbps 100 Gbps 32% ✓ 12か月以上 — 対応不要 コストを考慮した推奨事項： [緊急 — 30日] HANA DB を x2idn.metal（100 Gbps）に移行するか、トラフィック最適化を適用する（構成のみの場合は月額0ドルに対し +2,340ドル/月）。 [計画 — 45日] 負荷分散のために2つ目の TGW アタッチメントを追加する。 [監視] すべてのコンポーネントに対して使用率80%のしきい値で CloudWatch アラームを設定する。 要点 プロアクティブな検出： HANA DB の帯域幅超過に対する38日前の事前警告により、緊急対応ではなく計画的なメンテナンスが可能になります。 データ駆動のタイムライン： 実際の60日間のトラフィックパターンから算出した成長率により、キャパシティ計画チームは正確で説明可能な予測を得られます。 コストを考慮した優先順位付け： インフラのアップグレードとゼロコストの構成変更の両方の選択肢が提示されるため、予算の制約に応じて選択できます。 図6. ネットワークキャパシティトレンド（60日間）とスケーリング要件を含む予測 コストに関する考慮事項 主なコスト要因は、スキャンした GB 単位で課金される Amazon CloudWatch Logs Insights のクエリと、VPC Flow Log のストレージです。したがって、支出は保持するログデータ量とクエリの実行頻度に応じて増減します。 デプロイメント階層別の月額コスト概算 月額コストの概算はデプロイメントの規模によって異なります。次の表は代表的な3つの階層を示しています。 階層 月額コスト概算 プロファイル Basic $25〜$35 単一 VPC、開発/テストワークロード、低いクエリ量 Development $60〜$80 マルチ AZ の SAP ランドスケープ、中程度の監視、時折のユースケース実行 Enterprise $150〜$250 マルチ VPC の本番 SAP、高頻度のヘルスチェック、全ユースケースの自動化、CloudTrail 監査ログ 実際の VPC Flow Log 量とクエリ頻度に基づくコスト見積もりには AWS Pricing Calculator をご利用ください。 まとめ Kiro-CLI と AWS MCP Servers を組み合わせることで、SAP のネットワークトラブルシューティングを、何時間もの断片的な手作業から、自然言語で駆動する数分の診断へと変革できます。本記事の数値や出力は、外部でベンチマークした結果ではなくリファレンスデプロイメントからの説明用の例であり、実際の結果はランドスケープの規模やログ量によって異なります。5つの実世界のユースケースを通じて、このアプローチが以下を実現する様子をご覧いただきました。 単一のプロンプトによる包括的なネットワークヘルスチェックとスコアリング。 RISE with SAP の 504 エラーに対する体系的な根本原因分析。 SAP Note 1100926 （SAP S* ユーザー ID が必要）のしきい値に照らしてベンチマークしたクロス AZ レイテンシー診断。 CloudTrail の相関を用いたセキュリティグループドリフトの確定的な原因特定。 コストを考慮した推奨事項付きのプロアクティブな60日間ネットワークキャパシティ予測。 次のステップ：実装ロードマップ このセクションでは、ゼロから動作する SAP ネットワークトラブルシューティング環境を構築するために必要なすべて、すなわち見込むべき総時間、必要なダウンロードとドキュメント、そして運用開始後に専門性を深める場所をまとめます。まずは以下の時間見積もりから始めてください。 初回のフル実行にはエンドツーエンドでおおよそ2〜3時間を見込んでください。継続利用はクエリあたり数分で済みます。 フェーズ アクティビティ 所要時間の目安 セットアップ Kiro-CLI をインストールし、AWS マネージド MCP Servers を構成する 30〜60分 セットアップ SAP VPC で VPC Flow Logs と CloudWatch ロググループを有効化する 20〜30分 セットアップ 最小権限の IAM 権限を適用し、CloudTrail を有効化する 15〜20分 初回実行 ユースケース1を実行してネットワークヘルススコアのベースラインを確立する 10〜15分 導入 残りのユースケース（2〜5）を運用 runbook に追加する 30〜45分 継続運用 自然言語プロンプトによるクエリごとの診断 数分 必要なドキュメントとダウンロード 開始前に以下のリンクを揃えておいてください。最初の3つはインストールと構成を、残りはインフラストラクチャ、監視、しきい値、コスト見積もりのためのリファレンス資料です。 Kiro-CLI — インストールガイド マネージド AWS MCP Server（Agent Toolkit の一部） VPC Flow Logs を有効化する VPC Flow Logs を CloudWatch Logs に送信する Transit Gateway Flow Logs AWS CloudTrail を有効化する AWS Launch Wizard for SAP（HA デプロイメント） SAP Note 1100926 — レイテンシーしきい値（SAP S* ユーザー ID が必要） AWS Pricing Calculator — 月額コストの見積もり この先へ — さらに深く ベースラインが整ったら、同じ Kiro-CLI と MCP Server の基盤からさらに価値を引き出す5つの方法を紹介します。 運用に組み込む： 最もよく使うプロンプトをチームの runbook にまとめ、メンテナンスウィンドウのたびに自動的に実行して、セキュリティグループのドリフトを早期に検出します。 アラートを自動化する： 使用率80%のしきい値で CloudWatch アラームを設定し、キャパシティ予測をプロアクティブなスケーリングチケットに変えます。 カバレッジを拡大する： 同じ MCP + Kiro-CLI のパターンを隣接領域（IAM、コスト、オブザーバビリティの MCP Servers）に拡張し、統一された自然言語の運用コンソールを実現します。 マネージドに移行する： 単一エンドポイントアクセスと大規模での CloudTrail 監査の組み込みのために、マネージド AWS MCP Server を実装します。 クレジットと謝辞 本ブログは、AWS の SAP on AWS チームおよび AWS Network Specialist チームの貢献により作成されました。AWS マネージド MCP Servers と Kiro-CLI プロダクトチームのサポートに特に感謝します。 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

2段階認証でフィッシングを完全に防ぎきれない理由 AiTMフィッシングによる認証情報のリアルタイム窃取 フィッシングは、偽のログイン画面にパスワードを入力させる攻撃だけではありません。利用者と正規のサービスの間に攻撃者が入り、入力内容をリアルタイムで中継する「AiTM（Adversary-in-the-Middle）フィッシング」という手法があります。

本記事は 2026 年 10 月 13 日に公開された “ AI-powered anomaly detection for AWS Systems Manager Session Manager logs using Amazon Bedrock ” を翻訳したものです。 運用エンジニアや開発者がマネージドノード上で AWS Systems Manager Session Manager のセッションを開始すると、実行したコマンドはすべてトランスクリプト（セッション中のコマンドとその出力の記録）に残ります。そのコマンドの 1 つ 1 つは、日常的な作業であることもあれば、セキュリティインシデントの最初の兆候であることもあります。数百台のノードが毎日数千件のコマンドを記録する規模になると、セキュリティオペレーションセンター (SOC) のチームがこれらのトランスクリプトを手作業で確認することはできません。1 日分のセッションの操作を解析するだけで何時間もかかり、被害が出るまで脅威に気付けないというセキュリティ上の死角が生まれます。目指すのは、分析の精度を保ち、コストを抑えながら、これらのトランスクリプトをほぼリアルタイムで分析することです。 以前のブログ では、生成 AI を使って Amazon FSx for Windows File Server の監査ログから異常を検知する方法を紹介しました。このブログでは、同じアプローチを Session Manager のトランスクリプトに適用します。 Amazon Bedrock 、 AWS Lambda 、 Amazon Simple Storage Service (Amazon S3)、 Amazon Bedrock AgentCore を使って、異常検知とセッション要約のソリューションを構築する方法を説明します。セキュリティアナリストは、セッションの分類結果を自動で受け取れます。不審なコマンドにはアラートが上がり、セッションの履歴は自然言語で問い合わせられます。 ソリューションの概要 このソリューションは 2 つのモジュールで構成されます。Module 1 は、セッションが終了するたびにそのセッションを自動で分析し、Suspicious または Critical に当たるものにフラグを立てます。Module 2 では、SOC チームがセッションの履歴を、必要なときに普段の言葉で問い合わせられます。2 つを組み合わせることで、自動検知と人の手による調査の両方をカバーします。 アーキテクチャ ソリューションのアーキテクチャ。Module 1 は、Session Manager の各トランスクリプトを Amazon Bedrock で自動的に分析し、SOC にアラートを送れます。Module 2 では、アナリストが Amazon Bedrock AgentCore を通じてセッションの履歴を自然言語で問い合わせられます。 Module 1 の流れ オペレーターが、マネージドノード（Amazon EC2、オンプレミス、ハイブリッド）で Session Manager のセッションを開始します。 セッション中、AWS Systems Manager (SSM) Agent はコマンドを Amazon CloudWatch Logs へリアルタイムにストリーミングし、トランスクリプトファイルをディスクに書き込みます。 セッションが終了すると（exit の入力、アイドルタイムアウト、明示的な終了など、終了の方法は問いません）、SSM Agent は完全なトランスクリプトを Amazon Simple Storage Service (Amazon S3) に自動でアップロードします。 S3 の PutObject イベントが AWS Lambda 関数を呼び出します。 Lambda 関数はトランスクリプトを読み取り、AWS Systems Manager からセッションのメタデータを取得して、その内容を Amazon Bedrock に送って分析させます。 Lambda 関数は、AWS CloudTrail でそのセッションの StartSession イベントも検索し、セッションを開始した IAM プリンシパルと送信元 IP アドレスを特定して、その両方をアラートに含めます。 Amazon Bedrock の基盤モデルがセッションを自動で分類し、構造化された分析結果を返します。 Lambda 関数は要約を Amazon DynamoDB に保存し、セッションが Suspicious または Critical の場合は Amazon Simple Notification Service (Amazon SNS) にアラートを発行します。 Module 2 の流れ SOC アナリストが、Amazon Bedrock AgentCore ハーネスに自然言語で質問を送ります。 ハーネスは質問を解釈し、AgentCore ゲートウェイを通じて Lambda 関数を呼び出します。 Lambda 関数は、DynamoDB で要約を検索するか、CloudWatch Logs Insights のクエリを実行してセッションの生データを取得します。 ハーネスは、AI による文脈の説明と推奨事項を添えて結果を返します。 モデルによるセッションの分類 モデルは、各セッションを次の 3 つのカテゴリのいずれかに分類します。 分類 説明 アクション Normal 想定どおりのパターンに沿った日常的な操作 要約を DynamoDB に保存する Suspicious 調査が必要な、通常と異なるコマンドやパターン 要約を保存し、Amazon SNS を通じて SOC にアラートを送る Critical ポリシー違反や悪意のある操作の明確な兆候 要約を保存し、直ちに SOC にアラートを送る 訳注: Suspicious と Critical は、いずれも同じ Amazon SNS トピックに通知されます。通知のされ方に差はなく、件名に分類が入るだけです（サンプルの CloudFormation テンプレートで確認。2026-10-14 時点）。差があるのは分類の基準で、認証情報へのアクセスを試みた段階が Suspicious、認証情報の抽出や永続化の設置まで行われた段階が Critical です。 モデルが検知するパターンには、次のようなものがあります。 認証情報へのアクセス : /etc/shadow、AWS の認証情報、SSH キーの読み取りの試行 権限昇格 : SUID バイナリの列挙、許可されていない sudo の使用、権限の変更 データの持ち出し : 外部への HTTP リクエストと、機密ファイルへのアクセスの組み合わせ 偵察 : ネットワークのスキャン、ホストの列挙、プロセスの一覧取得 永続化 : crontab の変更、サービスの作成、authorized_keys の変更 防御の回避 : 履歴の削除、監査ログの改ざん、セキュリティサービスの無効化 注 : モデルは、入力されたコマンドだけでなく、セッションのトランスクリプト全体を確認します。コマンドの出力、操作の順序、セッション全体の文脈も考慮します。この動作は、「SessionAnalyzerFunction」Lambda 関数の分類用プロンプトで制御できます。このプロンプトを編集すれば、各カテゴリの基準を調整したり、独自のルールを追加したり、運用要件に合ったカテゴリを定義したりできます。 前提条件 このソリューションをデプロイする前に、以下のものがそろっていることを確認してください。 AWS CloudFormation スタックをデプロイする権限を持つ AWS アカウント AWS Systems Manager Agent (SSM Agent) がインストールされたマネージドノード（Amazon EC2 インスタンス、またはハイブリッドアクティベーションしたサーバー）が少なくとも 1 台 Amazon Bedrock の基盤モデル（Claude Haiku 4.5、または任意のモデル）へのアクセス。手順は Amazon Bedrock 基盤モデルへのアクセスの追加または削除 を参照してください。 注: マネージドノードは、Session Manager を使えるようにセットアップしておく必要があります。つまり、SSM Agent がインストールされ、必要な権限を持つ IAM ロールがノードに付与され、Systems Manager と Amazon S3 のエンドポイントにネットワークで到達できる状態です。最近の Amazon EC2 の Amazon Linux と Windows の AMI には、SSM Agent があらかじめ含まれています。オンプレミスのノードの場合や、ネットワークとセットアップの手順全体については、 Session Manager のセットアップ を参照してください。 ウォークスルー 次の手順では、AWS CloudFormation テンプレートを使ってソリューションをデプロイし、その後オンデマンドの問い合わせ用インターフェイスを設定します。 ステップ 1: CloudFormation スタックのデプロイ このブログの GitHub リポジトリ から CloudFormation テンプレートをダウンロードします。 AWS CloudFormation コンソール を開きます。 スタックの作成 を選び、 新しいリソースを使用 (標準) を選びます。 テンプレートファイルのアップロード を選び、ダウンロードしたテンプレートを選択して、 次へ を選びます。 スタック名 に ssm-session-anomaly-detection と入力します。 パラメータ を設定します。 Alert notification endpoint : セキュリティアラートの送信先メールアドレスを入力します。 Alert notification protocol : 既定の email のままにするか、使いたいプロトコルを選びます。 Bedrock model for session analysis : 既定の global.anthropic.claude-haiku-4-5-20251001-v1:0 のままにするか、使いたいモデルを入力します。 注 : デプロイする前に、Amazon Bedrock コンソール（または aws bedrock list-foundation-models ）で、このモデル ID が現在も提供されていて、お使いのリージョンで有効になっているかを確認してください。 RolePermissionAutomationSchedule : 既定の rate(30 minutes) のままにします。 次へ を選び、IAM リソースが作成されることを承認して、 次へ を選びます。 送信 を選びます。 スタックは次のリソースを作成します。 図 2. デプロイ後の CloudFormation スタックの出力。トランスクリプト用バケット、要約用テーブル、アラート用トピック、2 つの Lambda 関数、AgentCore のハーネスとゲートウェイなど、主要なリソースが一覧で表示される。 ステップ 2: SNS サブスクリプションの確認 スタックの作成が完了したら、メールの受信トレイで Amazon SNS からのサブスクリプション確認メールを探します。 Confirm subscription を選ぶと、アラートの配信が有効になります。 ステップ 3: 自然言語でのソリューションへの問い合わせ (Module 2) AgentCore ゲートウェイと AgentCore ハーネスは、CloudFormation スタックがすでに作成しています。この 2 つと、クエリを実行する Lambda 関数との接続も済んでいます。作成や設定の作業は必要ありません。 ハーネスを開くには、次の手順を実行します。 Amazon Bedrock AgentCore コンソール を開きます。 ナビゲーションペインで ハーネス を選びます。 SSMSecurityAnalyst という名前のハーネスを開きます。完全な名前は、スタックの出力の AgentCoreHarnessArn に表示されています。 このハーネス (SSMSecurityAnalyst) は、DynamoDB からセッションの要約と CloudWatch から生ログを読み取ります。質問ごとに適切なツールを選び、セキュリティ上の懸念点を指摘します。次の節で実際に試します。 ソリューションのテスト デプロイが終わったら、2 つのモジュールの動作をテストします。 Module 1 のテスト: 自動分析 1. Session Manager のセッションを開始します。 aws ssm start-session --target <your-instance-id> 2. 一般的なコマンドをいくつか実行します。 #whoami #df -h #uptime #exit 3. 30 秒ほど待ってから、DynamoDB テーブルでセッションの要約を確認します。 aws dynamodb scan --table-name SSMSessionSummaries-ssm-session-anomaly-detection \ --filter-expression "itemType = :t" --expression-attribute-values '{":t":{"S":"SUMMARY"}}' \ --query "Items[].{Session:sessionId.S,Classification:classification.S,Summary:summary.S}" --output table このセッションは Normal に分類されるはずです。 4. 別のセッションを開始し、不審なコマンドを実行します。 #cat /etc/shadow #find / -perm -4000 -type f 2>/dev/null | head -5 #curl http://example.com #history -c #exit 注 : これらのデモ用コマンドは、まずテスト用のアカウントで実行してください。 5. 30 秒後、もう一度 DynamoDB を確認します。このセッションは Suspicious に分類され、アラートのメールが届くはずです。 出力 SNS のメールによるアラート通知のスクリーンショットです。 1. Critical なセッションのアラート 図 3. Critical なセッションに対する Amazon SNS のメールアラート。重大度がより高いセッションでも同じ形式のアラートが届く。この例では、ユーザーがパスワードファイルにアクセスし、セキュリティログの無効化を試みている。 2. Suspicious なセッションのアラート 図 4. Suspicious なセッションに対する Amazon SNS のメールアラート。分類、セッション ID、対象のノード、わかりやすい言葉で書かれた要約、判定の根拠になったフラグ、推奨事項が表示される。 Module 2 のテスト: オンデマンドの問い合わせ AgentCore ハーネスのプレイグラウンドで、次のような質問を試してください。 「過去 24 時間の Suspicious なセッションをすべて表示して」 「ユーザー jsmith は今週何をした？」 「/etc/shadow へのアクセスを試みたセッションを探して」 「今日のすべてのセッションについて、セキュリティの状況を要約して」 「過去 24 時間の Critical と Suspicious のセッションをすべて挙げて、重大度の順に並べて」というプロンプトの実行例 図 5. アナリストがセッションの履歴について自然言語で質問し、Amazon Bedrock AgentCore ハーネスが回答している。 多層的なセキュリティアプローチ このソリューションは、多層的なセキュリティ戦略の一部として使うと最も効果を発揮します。 レイヤー ソリューション カバー範囲 1 CloudWatch Logs のログ異常検出 ロググループに対する、機械学習で作ったベースラインによる異常検出 2 Amazon GuardDuty Runtime Monitoring 41 種類の脅威を対象にしたリアルタイムの検知 3 このソリューション (Bedrock + Lambda) セッションの要約、AI による分類、自然言語での問い合わせ クリーンアップ 継続的な料金の発生を避けるため、次の手順でリソースを削除します。 AWS CloudFormation コンソール を開きます。 作成したスタックを選択します。 削除 を選びます。 スタックを削除すると、リソースも自動的に削除されます。 まとめ Session Manager は、チームが実行するすべてのコマンドを記録します。規模が大きくなると、トランスクリプトは 1 日に数千件にもなります。そのすべてを読める SOC チームはなく、その隙間に実際のインシデントが潜みます。 このソリューションを使えば、その隙間を埋めやすくなります。セッションが終了すると、Amazon Bedrock がトランスクリプトを確認し、Normal、Suspicious、Critical のいずれかに分類します。短い要約は DynamoDB に保存されます。Suspicious と Critical のセッションについては、ユーザーと送信元 IP を明記したメールが送られます。さらに詳しく調べたいときは、AgentCore ハーネスがわかりやすい言葉で質問に答え、セッションの履歴を代わりに検索します。 強みは文脈を踏まえられることです。curl コマンドが単独で実行されたなら、日常的な操作です。しかし、/etc/shadow を読み取り、履歴を消したあとに実行された同じコマンドは、そうではありません。モデルはセッション全体を見て判断するため、ルールベースのチェックでは見落とすパターンも捉えられます。 数分で使い始められます。CloudFormation テンプレートをデプロイし、Session Manager のログの出力先をトランスクリプト用のバケットに設定すれば、分類結果が届き始めます。 著者について Rohan Vashi AWS の Technical Account Manager で、DevOps、CloudOps（モニタリングとオブザーバビリティを含む）、生成 AI を専門としています。エンタープライズのお客様と協力して、安全でスケーラブルなソリューションを構築しています。運用上の優秀性と AI/ML による自動化に重点を置き、クラウドの導入とエージェント型 AI への取り組みを支援しています。AWS Certified Solutions Architect – Professional と AWS Certified Generative AI Developer – Professional の認定を保有しています。組織がクラウドのオブザーバビリティにどう取り組むかを変えるようなソリューションを作るのが好きです。 翻訳はソリューションアーキテクトの村田が担当しました。