AWS認定資格 WEB問題集＆徹底解説機械学習エンジニア アソシエイト（MLA）
AWSサービスの一つであるAmazon Lookout for Metricsはどんな内容なのでしょうか？また、AWS認定資格の機械学習エンジニア-アソシエイト(MLA)に合格するためには、サービスのどんなポイントを押さえておけばよいのでしょうか？
ここでは、そんなあなたの疑問に回答していきたいと思います
1. サービス概要
Amazon Lookout for Metricsは、売上・注文数・トラフィック・アプリの可用性といったビジネスや運用の時系列メトリクスを機械学習で監視し、想定外の変化（異常）を検出して、どの切り口（地域・商品など）で起きたかという原因の手がかりとともに通知するサービスでした。 季節性や曜日の変動を学習するため、固定しきい値の監視よりも誤報を減らしやすい点が特徴です。
現状（2026年10月時点）: 新規顧客の受付は2024年10月9日に終了し、既存顧客向けのサポートも2025年10月10日に終了しました。公式ドキュメントも撤去されています。 AWSは移行先として、Amazon CloudWatchの異常検出（メトリクスの異常検出アラーム、ログの異常検出）、Amazon OpenSearch ServiceのAnomaly Detection、Amazon QuickSightのML Insights、Amazon Redshift ML、AWS Glue Data Qualityの異常検出、Amazon SageMaker Canvasなどを案内しています。
MLA試験ガイドの対象サービス一覧には掲載が続いているため、既存の問題ではサービス名が登場します。役割（ビジネスメトリクスの異常検知）と、後継サービスへの読み替えの両方を押さえておきましょう。
2. 主な特徴と機能
2.1 検出器（Detector）
検出器はデータソースを定期的に読み込み、異常を探すリソースです。分析間隔は5分〜1日の範囲で選び、データの到着遅れに備えて待ち時間（遅延）も設定できました。 ライブデータで数回の間隔をかけて学習するほか、過去データを与えて学習を早めることもできました。
2.2 メジャーとディメンション
監視する数値をメジャー（例: 売上額）、切り口となる属性をディメンション（例: 国、商品カテゴリ）として指定します。 メジャーとディメンションの値の組み合わせ1つ1つが「メトリクス」として個別に監視されるため、「全体では普通だが特定の国だけ急落」といった異常を捉えられます。
2.3 重大度スコアと原因の手がかり
異常には、学習した通常パターンからどれだけ外れているかを示す重大度スコアが付きます。複数のメトリクスにまたがる異常はグループにまとめられ、どのディメンション値が異常に寄与したかが示されました。
2.4 アラートとフィードバック
一定以上の重大度の異常が見つかると、アラートでAmazon SNSトピックへ通知したり、AWS Lambda関数を起動したりできました。 検出結果に「関連あり／なし」のフィードバックを返すことで、以降の検出精度を調整できます。
2.5 データソースとバックテスト
Amazon S3、Amazon CloudWatch、Amazon Redshift、Amazon RDS、Amazon Athenaなどのデータを直接読み込めました。 過去データだけを使って検出器を試すバックテストモードで、本番運用前に検出の傾向を確認できました。
3. アーキテクチャおよび技術要素
- データソース（S3、CloudWatch、Redshift、RDSなど）とタイムスタンプ列、メジャー、ディメンションを定義する。
- 検出器の分析間隔を選び、必要なら過去データで学習を早める（またはバックテストで評価する）。
- 検出器が間隔ごとに新しいデータを読み、季節性を考慮して異常を判定し、重大度スコアを付ける。
- アラートの条件を満たした異常をSNSやLambdaへ送り、通知や自動調査を行う。
- 担当者が結果にフィードバックを返し、検出の精度を高める。
4. セキュリティと認証・認可
- IAMロール: 検出器がデータソースを読み、アラート先のSNS・Lambdaを呼び出すための権限をロールで付与していた。
- 暗号化: 検出器のデータはKMSキーで暗号化でき、S3などの入力データもSSE-KMSで保護する。
- ネットワーク: VPC内のRDSやRedshiftを読む場合は、サブネットとセキュリティグループを指定して接続していた。
- 監査: API操作はCloudTrailに記録される。
5. 料金形態
サポート終了前は、分析したメトリクス（メジャーとディメンション値の組み合わせ）の数に応じた月額の段階制課金でした。メトリクス数が多いほど単価が下がる体系です。 ディメンションを増やすと監視対象のメトリクス数が掛け算で増えるため、切り口の選び方がコストに直結しました。現在は新たに課金されるサービスではありません。
6. よくあるアーキテクチャ・設計パターン
- 収益指標の異常検知と自動調査（当時）: 検出器のアラートでLambdaを直接起動して調査ロジックを実行し、同時にSNSで関係者へ通知する。間にCloudWatchアラームやSQSを挟む必要はない。
- 季節性の大きいビジネス: 繁忙期を含む長期間の過去データで学習させ、セール期の急増を異常と誤検知しないようにする。
- 後継への移行（運用メトリクス）: CloudWatchの異常検出アラームで、通常の変動幅を外れた値を検知する。
- 後継への移行（ログ・検索データ）: OpenSearch ServiceのAnomaly Detectionでストリーミングや履歴データの異常を検知し、アラート機能で通知する。
- 後継への移行（BIダッシュボード）: QuickSightのML Insightsで、ダッシュボード上のメトリクスから外れ値を自動で見つける。
7. 設定・デプロイ手順（ハンズオン例）
サポート終了済みのため、現在は新たに構築できません。代表的な移行先であるCloudWatchの異常検出を例にします。
- 監視したいビジネス指標をCloudWatchのカスタムメトリクスとして発行する（ディメンションで地域や商品を区別）。
- CloudWatchコンソールでメトリクスを選び、異常検出バンドを表示して通常の変動幅を確認する。
- バンドから外れたら発報するアラームを作成し、通知先にSNSトピックを指定する。
- SNSからLambdaを起動して、詳細調査や関係者への連絡を自動化する。
8. 試験で問われやすいポイント
8.1 サービス選択
- Q: 売上や注文数などのビジネスメトリクスの異常を、ML の専門知識なしで自動検出したい場合は？
A: Amazon Lookout for Metrics（現在は後継のCloudWatch異常検出、QuickSight ML Insights、OpenSearch Anomaly Detectionなど）。 - Q: 産業機器のセンサーデータの異常検知は？
A: Lookout for Metricsではなく、旧Lookout for Equipment（現在はAWS IoT SiteWiseの異常検出）。 - Q: 独自の異常検知モデルを学習させたい場合は？
A: SageMaker AIの組み込みアルゴリズムRandom Cut Forestなどを使う。
8.2 アラートと連携
- Q: 異常検出をきっかけに、即座に調査処理を起動し関係者へ通知するには？
A: 検出器のアラートでLambdaを直接呼び出し、SNSトピックで通知する。CloudWatchアラームやSQS、CloudTrailを経由する構成は遠回り。 - Q: 特定の国や商品だけで起きた異常を見つけるには？
A: その属性をディメンションに設定し、組み合わせごとのメトリクスとして監視する。
8.3 精度の考え方
- Q: 大型セールなど毎年の急増を異常と誤検知させないためには？
A: 繁忙期を含む複数年分の過去データで学習させ、季節性とイベントのパターンを覚えさせる。繁忙期のデータを除外したり、しきい値を手で厳しくしたりするのは逆効果。
8.4 提供状況と後継サービス
- Q: Lookout for Metricsの提供状況は？
A: 2024年10月9日に新規受付終了、2025年10月10日にサポート終了。 - Q: 試験対策上の注意は？
A: 試験ガイドには掲載が残っているが、今後はCloudWatchの異常検出アラームやOpenSearchのAnomaly Detectionなど、後継の手段が正解として問われる可能性がある。「季節性を学習する異常検知」「異常時にSNS・Lambdaへつなぐ」という設計の考え方で判断できるようにする。