はじめに
前回は、MLA 試験で押さえておきたい補足キーワードとして、
- Time-series cross-validation
- AWS X-Ray
- Inference Pipeline
- L2 regularization
- SMOTE
- Bayesian Optimization
- Hyperband
などを整理しました。
今回は、さらに実戦的な補足として、
AWS MLA 試験で混乱しやすいポイント をまとめて整理します。
AWS の機械学習系試験では、単語の意味を知っているだけではなく、
問題文の状況を読んで、
この場面ではどのサービスを選ぶべきか
この要件ならどの構成が合っているか
この指標を重視する理由は何か
を判断する必要があります。
特に混乱しやすいのは、以下のようなテーマです。
- 推論方式の違い
- 監視系サービスの違い
- Drift 系用語の違い
- Precision / Recall / F1 の使い分け
- 不均衡データへの対応
- MLOps 系サービスの違い
- セキュリティ系サービスの違い
- コスト最適化の選び方
本記事では、これらを試験対策目線で、シンプルに整理します。
🎯 対象読者
- AWS Certified Machine Learning Engineer - Associate を勉強している方
- 各サービスの違いが混乱しやすい方
- 問題文を読んだときに、どれを選べばよいか迷いやすい方
- 推論、監視、MLOps、セキュリティ、コストをまとめて復習したい方
- これまでのシリーズを読んだあと、試験前に要点を整理したい方
🧩 まず結論：試験では「キーワード」と「要件」を結びつける
AWS MLA 試験では、サービス名を単独で覚えるよりも、
問題文のキーワードと選択肢を結びつける ことが重要です。
たとえば、以下のような判断です。
| 問題文のキーワード | 考える候補 |
|---|---|
| 低レイテンシー、即時応答 | Real-time Endpoint |
| 大きなファイル、処理に時間がかかる | Asynchronous Endpoint |
| 大量データを一括予測 | Batch Transform |
| 入力データの分布変化 | Model Monitor / Data Drift |
| API 操作履歴を監査 | CloudTrail |
| リクエスト経路や遅延箇所を追跡 | X-Ray |
| モデルバージョン管理 | Model Registry |
| 特徴量の再利用 | Feature Store |
| ML ワークフロー自動化 | SageMaker Pipelines |
| 保存データの暗号化 | KMS |
| インターネットを経由しない AWS サービス接続 | VPC Endpoint |
| Training コスト削減、中断許容 | Spot Training |
つまり、試験対策では
用語の意味
+
どの場面で使うか
をセットで覚えることが大切です。
1. 推論方式の違い
まず混乱しやすいのが、SageMaker の推論方式です。
Day 11 でも整理しましたが、試験前にはもう一度、短く覚え直す価値があります。
代表的な推論方式は以下です。
- Real-time Endpoint
- Serverless Endpoint
- Asynchronous Endpoint
- Batch Transform
⚡ Real-time Endpoint
Real-time Endpoint は、
リクエストに対してすぐに予測結果を返す推論方式 です。
Real-time Endpoint = 低レイテンシーで即時応答
向いている場面
- Web API として使う
- ユーザーが画面上で結果を待っている
- すぐに予測結果を返したい
- レイテンシーが重要
- 継続的にリクエストがある
例
ユーザーがローン申請
↓
即時にリスク判定
↓
画面に結果を返す
🧩 Serverless Endpoint
Serverless Endpoint は、
少量または不定期アクセスのリアルタイム推論に向いている方式 です。
Serverless Endpoint = 少量・不定期アクセス向けのリアルタイム推論
向いている場面
- リクエストが少ない
- アクセスが不定期
- 常時稼働コストを抑えたい
- インスタンス管理を減らしたい
注意点
コールドスタートに注意
非常に低いレイテンシーが常に必要な場合は、Real-time Endpoint の方が向いていることがあります。
🕒 Asynchronous Endpoint
Asynchronous Endpoint は、
推論処理に時間がかかる場合や、大きな入力を扱う場合に向いている方式 です。
Asynchronous Endpoint = 大きな入力・長い処理を非同期で実行
向いている場面
- 大きな画像や動画を処理する
- 推論に時間がかかる
- すぐに結果を返す必要がない
- 結果を S3 に保存すればよい
例
500MB の動画をアップロード
↓
モデルで分析
↓
数分後に結果を S3 に保存
📦 Batch Transform
Batch Transform は、
大量データをまとめてオフライン推論する方式 です。
Batch Transform = 大量データを一括予測
向いている場面
- S3 上の大量データをまとめて処理する
- 夜間バッチで全顧客をスコアリングする
- リアルタイム応答が不要
- Endpoint を常時起動したくない
例
S3 に 100万人分の顧客データ
↓
夜間に Batch Transform
↓
結果を S3 に保存
🧠 推論方式の覚え方
| 要件 | 選ぶ候補 |
|---|---|
| すぐ結果が必要 | Real-time Endpoint |
| アクセスが少ない・不定期 | Serverless Endpoint |
| 大きな入力・処理が長い | Asynchronous Endpoint |
| 大量データをまとめて予測 | Batch Transform |
覚え方は以下です。
すぐ返す → Real-time
たまに使う → Serverless
大きくて時間がかかる → Async
まとめて処理 → Batch
2. 監視系サービスの違い
次に混乱しやすいのが、監視系サービスです。
特に以下は名前や役割が似ているように見えます。
- Model Monitor
- CloudWatch
- CloudTrail
- X-Ray
しかし、それぞれ見ているものが違います。
👀 Model Monitor
Model Monitor は、
モデルの入力データや予測結果を監視するための仕組み です。
Model Monitor = モデルが本番で変な状態になっていないかを見る
見るもの
- 入力データの分布
- 予測結果の分布
- Data Drift
- データ品質
- 欠損値や異常値
- モデル品質の低下
試験キーワード
data drift
model quality
data quality
monitor deployed model
compare production data with baseline
📊 CloudWatch
CloudWatch は、
メトリクス、ログ、アラームを確認するためのサービス です。
CloudWatch = システムの状態やログを見る
見るもの
- CPU 使用率
- メモリ関連の指標
- Endpoint の呼び出し回数
- エラー数
- レイテンシー
- Training Job のログ
- アラーム
試験キーワード
metrics
logs
alarms
latency
error rate
monitor system performance
📜 CloudTrail
CloudTrail は、
AWS アカウント内で誰がどの API 操作をしたかを記録するサービス です。
CloudTrail = 誰が何を操作したかを見る
見るもの
- 誰が SageMaker Job を作成したか
- 誰が S3 バケットにアクセスしたか
- 誰が IAM Role を変更したか
- 誰が KMS key を使ったか
- 誰が Endpoint を削除したか
試験キーワード
audit
API call history
who performed an action
compliance
governance
🧭 AWS X-Ray
X-Ray は、
分散アプリケーションのリクエスト経路や遅延箇所を追跡するサービス です。
X-Ray = リクエストがどこを通って、どこで遅くなったかを見る
見るもの
- リクエストが通ったサービス
- 各サービスでの処理時間
- 遅延のボトルネック
- サービス間の呼び出し関係
試験キーワード
distributed tracing
trace request path
latency bottleneck
which service caused delay
🧠 監視系サービスの覚え方
| サービス | 何を見るか |
|---|---|
| Model Monitor | モデルの入力・出力・ドリフト |
| CloudWatch | メトリクス・ログ・アラーム |
| CloudTrail | 誰が何を操作したか |
| X-Ray | リクエスト経路と遅延箇所 |
覚え方は以下です。
Model Monitor = モデルを見る
CloudWatch = システムを見る
CloudTrail = 操作履歴を見る
X-Ray = リクエスト経路を見る
3. Drift 系用語の違い
Day 12 では Data Drift を整理しました。
試験対策としては、関連する Drift 系用語もまとめて押さえると理解しやすくなります。
代表的には以下です。
- Data Drift
- Concept Drift
- Model Drift
🌊 Data Drift
Data Drift は、
本番で入力されるデータの分布が、学習時のデータ分布と変わること です。
Data Drift = 入力データの分布が変わる
例
学習時：20〜30代ユーザーが多い
本番後：60代以上のユーザーが多い
入力データそのものの傾向が変わっている状態です。
🔁 Concept Drift
Concept Drift は、
入力データと正解ラベルの関係が変わること です。
Concept Drift = 入力と答えの関係が変わる
例
以前は、安い商品ほどよく売れていたとします。
以前：価格が安い → 売れやすい
しかし、ブランド志向が強くなり、価格が高くてもブランド品が売れやすくなったとします。
現在：ブランド力が高い → 売れやすい
この場合、単に入力データの分布が変わっただけでなく、
「何が結果に影響するか」という関係そのものが変わっています。
📉 Model Drift
Model Drift は、
時間の経過とともにモデルの性能が低下していくこと を指すことがあります。
Model Drift = モデルの性能がだんだん悪くなる
原因は Data Drift の場合もあれば、Concept Drift の場合もあります。
つまり Model Drift は、結果として見える性能低下のイメージです。
🧠 Drift 系の覚え方
| 用語 | 意味 |
|---|---|
| Data Drift | 入力データの分布が変わる |
| Concept Drift | 入力と正解の関係が変わる |
| Model Drift | モデル性能が時間とともに低下する |
覚え方は以下です。
Data Drift = データが変わる
Concept Drift = ルールが変わる
Model Drift = 性能が落ちる
4. Precision / Recall / F1 の使い分け
分類モデルの評価指標も、試験でよく混乱します。
特に重要なのは以下です。
- Precision
- Recall
- F1 Score
- Accuracy
🎯 Precision
Precision は、
モデルが Positive と予測したもののうち、本当に Positive だった割合 です。
Precision = Positive と言ったものがどれだけ正しかったか
重視する場面
False Positive を減らしたいときです。
例：スパムメール判定
正常なメールを誤ってスパムにすると困ります。
正常メールをスパム扱いしたくない
↓
False Positive を減らしたい
↓
Precision を重視
🔍 Recall
Recall は、
本当に Positive のものを、どれだけ見つけられたか です。
Recall = 見逃さずに見つけられたか
重視する場面
False Negative を減らしたいときです。
例：病気のスクリーニング
病気の人を見逃すと危険です。
病気の人を見逃したくない
↓
False Negative を減らしたい
↓
Recall を重視
⚖️ F1 Score
F1 Score は、
Precision と Recall のバランスを見る指標 です。
F1 Score = Precision と Recall のバランス
重視する場面
- クラス不均衡がある
- Precision も Recall も両方大事
- Accuracy だけでは判断しにくい
📊 Accuracy
Accuracy は、
全体のうち正しく予測できた割合 です。
Accuracy = 全体の正解率
ただし、不均衡データでは注意が必要です。
たとえば、
正常：99%
異常：1%
のデータで、すべて正常と予測しても Accuracy は 99% になります。
しかし、異常を1件も見つけられていないため、良いモデルとは言えません。
🧠 評価指標の覚え方
| 重視したいこと | 指標 |
|---|---|
| 誤検知を減らしたい | Precision |
| 見逃しを減らしたい | Recall |
| Precision と Recall のバランス | F1 |
| 全体の正解率 | Accuracy |
覚え方は以下です。
誤検知が困る → Precision
見逃しが困る → Recall
両方大事 → F1
不均衡データでは Accuracy だけに注意
5. 不均衡データ対策
不均衡データとは、クラスの数に大きな偏りがあるデータです。
たとえば、
正常取引：99%
不正取引：1%
のようなケースです。
このようなデータでは、モデルが多数派クラスばかり予測してしまうことがあります。
🔁 Oversampling
Oversampling は、
少数クラスのデータを増やす方法 です。
Oversampling = 少数クラスを増やす
単純にコピーする方法もありますが、同じデータを増やしすぎると過学習しやすくなります。
🔽 Undersampling
Undersampling は、
多数クラスのデータを減らす方法 です。
Undersampling = 多数クラスを減らす
データ量を減らせる一方で、有用な情報を捨ててしまう可能性があります。
🧬 SMOTE
SMOTE は、
少数クラスの合成サンプルを作る方法 です。
SMOTE = 少数クラスの新しいサンプルを合成する
単純コピーではなく、少数クラスの近いサンプル同士の間に新しいデータを作ります。
⚖️ Class Weight
Class Weight は、
少数クラスの誤分類に大きな重みを与える方法 です。
Class Weight = 少数クラスを間違えたときのペナルティを大きくする
データ自体を増減させず、モデル学習時の重みを調整します。
🎚 Threshold Adjustment
Threshold Adjustment は、
分類の判定しきい値を調整する方法 です。
たとえば、通常は 0.5 以上なら Positive と判定するとします。
予測確率 >= 0.5 → Positive
しかし、Recall を上げたい場合は、しきい値を 0.3 に下げることがあります。
予測確率 >= 0.3 → Positive
これにより Positive と判定される件数が増え、見逃しを減らせる場合があります。
🧠 不均衡データ対策の覚え方
| 方法 | 考え方 |
|---|---|
| Oversampling | 少数クラスを増やす |
| Undersampling | 多数クラスを減らす |
| SMOTE | 少数クラスの合成データを作る |
| Class Weight | 少数クラスの誤分類を重く見る |
| Threshold Adjustment | Positive 判定のしきい値を調整する |
覚え方は以下です。
データを増やす → Oversampling / SMOTE
データを減らす → Undersampling
学習の重みを変える → Class Weight
判定基準を変える → Threshold Adjustment
6. MLOps 系サービスの違い
MLOps 系サービスも混乱しやすいです。
特に以下はセットで覚えると分かりやすいです。
- Feature Store
- Model Registry
- SageMaker Pipelines
- Model Monitor
🧱 Feature Store
Feature Store は、
特徴量を管理・再利用するための仕組み です。
Feature Store = 特徴量を管理する
キーワード
features
reuse features
online store
offline store
training-serving skew
📦 Model Registry
Model Registry は、
モデルのバージョンや承認状態を管理するための仕組み です。
Model Registry = モデルを管理する
キーワード
model version
approval status
approved model
model package
model package group
🔁 SageMaker Pipelines
SageMaker Pipelines は、
機械学習ワークフローを自動化・管理するための仕組み です。
Pipelines = ML の流れを管理する
キーワード
workflow
automation
processing
training
evaluation
condition step
register model
👀 Model Monitor
Model Monitor は、
本番デプロイ後のモデルを監視するための仕組み です。
Model Monitor = デプロイ後のモデルを見る
キーワード
data drift
monitor production data
baseline
model quality
data quality
🧠 MLOps 系の覚え方
| サービス | 何を管理するか |
|---|---|
| Feature Store | 特徴量 |
| Model Registry | モデルバージョン |
| Pipelines | ML ワークフロー |
| Model Monitor | 本番モデルの状態 |
覚え方は以下です。
Feature Store = 入力を管理
Model Registry = モデルを管理
Pipelines = 流れを管理
Model Monitor = 運用後を監視
7. セキュリティ系サービスの違い
セキュリティ系も試験でよく出ます。
代表的には以下です。
- IAM
- KMS
- VPC Endpoint
- Security Group
- CloudTrail
👤 IAM
IAM は、
誰が何をできるかを制御する仕組み です。
IAM = 権限管理
キーワード
least privilege
role
policy
permissions
access control
🔑 KMS
KMS は、
暗号化キーを管理するサービス です。
KMS = 暗号化キー管理
キーワード
encrypt data at rest
customer managed key
S3 encryption
key management
🔌 VPC Endpoint
VPC Endpoint は、
インターネットを経由せずに AWS サービスへ接続する仕組み です。
VPC Endpoint = AWS サービスへプライベート接続
キーワード
private connection
avoid public internet
access S3 from private subnet
🧱 Security Group
Security Group は、
リソース単位で通信を制御する仮想ファイアウォール です。
Security Group = 通信の入口・出口を制御
キーワード
inbound rules
outbound rules
allow traffic
network access
📜 CloudTrail
CloudTrail は、
AWS API 操作履歴を記録するサービス です。
CloudTrail = 監査ログ
キーワード
audit
API activity
who did what
compliance
🧠 セキュリティ系の覚え方
| 要件 | 選ぶ候補 |
|---|---|
| 誰が何をできるか制御 | IAM |
| 保存データを暗号化 | KMS |
| 公開インターネットを避ける | VPC Endpoint |
| 通信を制御 | Security Group |
| 操作履歴を監査 | CloudTrail |
覚え方は以下です。
権限 → IAM
暗号化 → KMS
プライベート接続 → VPC Endpoint
通信制御 → Security Group
操作履歴 → CloudTrail
8. コスト最適化の選び方
最後に、コスト最適化です。
ML ワークロードでは、コストを下げるために何を選ぶべきかがよく問われます。
🏋️ Training コストを下げたい
Training コストを下げたい場合は、以下を考えます。
| 方法 | 説明 |
|---|---|
| Spot Training | 中断を許容できる学習でコスト削減 |
| Early Stopping | 改善しなくなったら学習を止める |
| チューニング回数削減 | 無駄な trial を減らす |
| 適切なインスタンス選択 | 過剰スペックを避ける |
| 小さいデータで検証 | 最初から大規模に実行しない |
試験キーワード
reduce training cost
interruptible
checkpoint
managed spot training
🌐 Endpoint コストを下げたい
Endpoint コストを下げたい場合は、利用パターンを見ます。
| 利用パターン | 候補 |
|---|---|
| アクセスが少ない・不定期 | Serverless Endpoint |
| 負荷が変動する | Auto Scaling |
| リアルタイム性が不要 | Batch Transform |
| 常時アクセスがある | Real-time Endpoint + Auto Scaling |
📦 大量データを安くまとめて処理したい
大量データを一括処理したい場合は、Batch Transform が候補です。
大量データ
S3 入出力
夜間バッチ
リアルタイム不要
⚡ 低レイテンシーが必要
低レイテンシーが必要な場合は、Real-time Endpoint が候補です。
real-time prediction
low latency
immediate response
API
この場合、コストを下げたいからといって Batch Transform を選ぶのは不適切です。
要件として即時応答が必要だからです。
🧠 コスト最適化の覚え方
| 要件 | 選ぶ候補 |
|---|---|
| Training を安くしたい | Spot Training |
| 中断してもよい | Spot Training |
| 少量・不定期アクセス | Serverless Endpoint |
| 大量データの一括推論 | Batch Transform |
| 低レイテンシー推論 | Real-time Endpoint |
| 負荷に応じて台数調整 | Auto Scaling |
覚え方は以下です。
訓練を安く → Spot
少量アクセス → Serverless
大量オフライン → Batch
低遅延オンライン → Real-time
負荷変動 → Auto Scaling
9. よくあるひっかけパターン
ここでは、試験で混乱しやすいひっかけパターンを整理します。
ひっかけ 1：監視したいと言われたら全部 CloudWatch ではない
「監視」と書かれていても、何を監視したいのかを見る必要があります。
| 監視したいもの | 選ぶ候補 |
|---|---|
| モデルの入力分布 | Model Monitor |
| システムメトリクス | CloudWatch |
| API 操作履歴 | CloudTrail |
| リクエスト経路 | X-Ray |
監視 = CloudWatch と決めつけない
ひっかけ 2：推論と書かれていても Endpoint とは限らない
推論と書かれていても、リアルタイム性が必要かを確認します。
| 要件 | 選ぶ候補 |
|---|---|
| すぐ返す | Real-time Endpoint |
| 大きなファイル | Async Endpoint |
| 大量データ一括 | Batch Transform |
| たまに使う | Serverless Endpoint |
推論 = Endpoint と決めつけない
ひっかけ 3：Accuracy が高くても良いモデルとは限らない
不均衡データでは、Accuracy が高く見えても、少数クラスを見つけられていないことがあります。
不均衡データでは Accuracy だけに注意
この場合は、Precision、Recall、F1、AUC などを見る必要があります。
ひっかけ 4：コスト最適化でも要件を犠牲にしない
コストを下げたいからといって、必要なレイテンシーを満たせない構成を選んではいけません。
たとえば、即時応答が必要な場面で Batch Transform を選ぶのは不適切です。
コストより先に要件を確認する
ひっかけ 5：Clarify は Bias を自動で消すものではない
SageMaker Clarify は、Bias や Explainability を確認するための機能です。
Clarify = 検出・説明を支援する
自動的にすべての Bias を取り除く機能ではありません。
☁️ AWS 試験での見られ方
試験では、以下のような読み方をすると選択肢を絞りやすくなります。
Step 1：何をしたいのかを見る
推論したいのか
監視したいのか
学習したいのか
セキュリティを強化したいのか
コストを下げたいのか
Step 2：制約条件を見る
低レイテンシーが必要か
大量データか
リアルタイムか
インターネット経由を避けたいか
中断を許容できるか
承認フローが必要か
Step 3：該当サービスを選ぶ
低レイテンシー → Real-time Endpoint
大量オフライン → Batch Transform
モデル監視 → Model Monitor
API 監査 → CloudTrail
プライベート接続 → VPC Endpoint
中断可能 Training → Spot Training
このように、問題文の要件から逆算すると選びやすくなります。
👨💻 実務目線で見ると
実務でも、今回の整理はそのまま役立ちます。
実務では、単に「このサービスを使う」と決めるのではなく、
以下を確認してから設計します。
- 予測結果はすぐ必要か
- データ量はどれくらいか
- モデルはどれくらいの頻度で更新するか
- 本番後に何を監視するか
- 誰がモデルを承認するか
- データはどこに保存されるか
- 通信経路は安全か
- コストは継続的に許容できるか
AWS の機械学習では、モデル精度だけでなく、
運用、セキュリティ、コスト、監視まで含めて設計すること が重要です。
🧠 ここは特に覚えたいポイント
覚え方 1
推論方式は、即時性・入力サイズ・データ量で選ぶ
覚え方 2
Model Monitor はモデル、CloudWatch はシステム、CloudTrail は操作履歴、X-Ray はリクエスト経路
覚え方 3
Data Drift はデータ、Concept Drift は関係、Model Drift は性能低下
覚え方 4
Precision は誤検知を減らす、Recall は見逃しを減らす、F1 はバランス
覚え方 5
Feature Store は特徴量、Model Registry はモデル、Pipelines は流れ、Model Monitor は運用後
覚え方 6
IAM は権限、KMS は暗号化、VPC Endpoint はプライベート接続、CloudTrail は監査
覚え方 7
Spot は Training コスト、Serverless は少量推論、Batch は大量オフライン、Auto Scaling は負荷変動
✅ まとめ
今回は、AWS MLA 試験で混乱しやすいポイントをまとめて整理しました。
重要なポイントは以下です。
- 推論方式は、Real-time、Serverless、Async、Batch の違いを要件で判断する
- 監視系サービスは、Model Monitor、CloudWatch、CloudTrail、X-Ray の役割を分けて覚える
- Drift 系用語は、Data Drift、Concept Drift、Model Drift の違いを整理する
- Precision は誤検知を減らしたいとき、Recall は見逃しを減らしたいときに重要
- 不均衡データでは Accuracy だけに頼らず、F1 や Recall などを見る
- MLOps 系サービスは、Feature Store、Model Registry、Pipelines、Model Monitor の役割を分けて覚える
- セキュリティでは、IAM、KMS、VPC Endpoint、Security Group、CloudTrail の役割を整理する
- コスト最適化では、Training、Endpoint、Batch、Serverless、Auto Scaling を要件に応じて選ぶ
試験では、サービス名だけを暗記するよりも、
問題文の要件から、どのサービス・指標・構成が合うかを判断する力 が重要です。
今回の内容は、試験直前の総復習にも使いやすい補足整理として活用できます。
📌 シリーズ補足まとめ
これで、Day 1 から Day 20 までで、機械学習の基礎、SageMaker、MLOps、監視、セキュリティ、コスト、そして試験で混乱しやすいポイントまで整理できました。
全体の流れとしては、以下のように理解すると分かりやすいです。
機械学習の基礎
↓
評価指標
↓
データ前処理
↓
SageMaker の学習・推論
↓
監視とドリフト
↓
Feature Store / Pipelines / Model Registry
↓
Clarify
↓
セキュリティ
↓
コスト最適化
↓
試験で混乱しやすいポイント整理
AWS MLA 試験対策では、この流れを意識しながら、公式問題やサンプル問題で
「この問題はどのテーマを聞いているのか」を見抜けるようにしていくことが大切です。