AWS認定資格 WEB問題集&徹底解説
機械学習エンジニア–アソシエイト
問題文と選択肢
- Amazon SageMakerのプロダクションバリアント機能を使用して、既存モデルと新しいモデルにトラフィックを分割する。各モデルがサービスするユーザーグループに対して、クリック率、コンバージョン率、セッションあたりの売上などのビジネス指標をAmazon Kinesis Data Streamsで収集し、Amazon CloudWatchでモニタリング後、Amazon QuickSightで分析する
- 新しいモデルを専用のAmazon SageMakerエンドポイントとしてデプロイし、既存モデルのエンドポイントとは別に稼働させる。Amazon SageMaker Model Monitorを利用して、両モデルの推論時間、メモリ使用量、モデルドリフトなどの技術的なメトリクスを比較し、より優れたモデルを選択する
- 新しいモデルを既存モデルの代替として全面的に本番環境にデプロイする。数日間にわたり、顧客フィードバックや売上データの変動を広範囲にわたって監視し、問題が発生した場合は直ちに既存モデルにロールバックする
- AWS Lambda関数を使用して、ウェブサイトの特定のリクエストに対して、新しいモデルと既存モデルの両方から予測を取得する。これらの予測結果を少数の社内ユーザーが手動で比較し、よりパーソナライズされた推薦を提供していると判断されたモデルを本番に導入する
A. Amazon SageMakerのプロダクションバリアント機能を使用して、既存モデルと新しいモデルにトラフィックを分割する。各モデルがサービスするユーザーグループに対して、クリック率、コンバージョン率、セッションあたりの売上などのビジネス指標をAmazon Kinesis Data Streamsで収集し、Amazon CloudWatchでモニタリング後、Amazon QuickSightで分析する
1 つの SageMaker エンドポイントに複数のプロダクションバリアントを登録し、バリアントの重みでトラフィックを分割すれば、実際の本番トラフィックを既存モデルと新モデルに同時に振り分けることができる。これがマネージドな A/B テストの標準構成。
そのうえでクリック率・コンバージョン率・セッションあたりの売上といったビジネス指標を Kinesis Data Streams で収集し、CloudWatch で監視、QuickSight で分析することで、「新モデルにビジネス上の価値があるか」をデータに基づいて客観的に判断できる。
重みは API で動的に変更できるため、新モデルが良ければ徐々に比率を上げ、悪ければ即座に 0% に戻せる(低リスク)。要件をすべて満たす唯一の選択肢。
B. 新しいモデルを専用のAmazon SageMakerエンドポイントとしてデプロイし、既存モデルのエンドポイントとは別に稼働させる。Amazon SageMaker Model Monitorを利用して、両モデルの推論時間、メモリ使用量、モデルドリフトなどの技術的なメトリクスを比較し、より優れたモデルを選択する
2 つのエンドポイントに分けて稼働させるだけでは、同一条件の顧客トラフィックを統制して振り分ける仕組みがないため、そもそも公正な A/B 比較にならない。
さらに SageMaker Model Monitor が扱うのはデータ品質・モデル品質・バイアス・特徴量の寄与度といったモデル監視の指標であって、推論レイテンシーやメモリ使用量といった技術メトリクスの比較も、売上・エンゲージメントの評価も本来の役割ではない。
本問の要件は「ビジネス上の価値の検証」であり、技術メトリクスがいくら良くても導入判断の根拠にはならない。
C. 新しいモデルを既存モデルの代替として全面的に本番環境にデプロイする。数日間にわたり、顧客フィードバックや売上データの変動を広範囲にわたって監視し、問題が発生した場合は直ちに既存モデルにロールバックする
新モデルを全面的に切り替えるのは A/B テストではなく、単なる一括デプロイ(ビッグバン切り替え)。比較対象となる既存モデルの結果が同時期に取れないため、売上の変動がモデルのせいなのか、季節要因やキャンペーンのせいなのか切り分けられない。
加えて全顧客が新モデルの影響を受けるため、性能が悪化した場合のビジネスインパクトが最大化する。
「効率的かつ信頼性の高い検証」という要件に真っ向から反する。
D. AWS Lambda関数を使用して、ウェブサイトの特定のリクエストに対して、新しいモデルと既存モデルの両方から予測を取得する。これらの予測結果を少数の社内ユーザーが手動で比較し、よりパーソナライズされた推薦を提供していると判断されたモデルを本番に導入する
Lambda で両モデルの推論を取得し、少数の社内ユーザーが手動で目視比較する方法は、評価がレビュアーの主観に依存し客観性を担保できない。
実際の顧客の行動(クリック・購入)を測っていないため、顧客エンゲージメントや売上への影響という要件をそもそも評価できない。
数千万件規模の推薦を人手で比較することは現実的でなく、スケーラビリティにも欠ける。
構成図
本番の顧客リクエスト
▼
SageMaker エンドポイント
├─ バリアント1: 既存モデル(重み 90%)
└─ バリアント2: 新モデル (重み 10%)
▼ 推薦結果
Web サイト ──行動イベント──▶ Kinesis Data Streams ──▶ CloudWatch(監視)
└──▶ QuickSight(分析)
モデルの A/B テスト=1 エンドポイント内のプロダクションバリアントでトラフィック分割。評価軸は技術指標ではなくビジネス指標。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| 実際の顧客に対する効果を、既存モデルと比較して測定したい | 同一エンドポイント内のプロダクションバリアントで本番トラフィックを分割するのが定石。全面切り替えでは比較対象が同時に存在しない →選択肢(A)は候補/選択肢(C)を消す |
| 顧客エンゲージメントや売上といったビジネス指標で評価する | Model Monitor が扱うのはデータ品質・モデル品質などのモデル監視指標。技術メトリクスではビジネス価値を判断できない →選択肢(B)を消す |
| 客観的に評価し、データに基づいて意思決定する | 少数の社内ユーザーによる手動比較は主観的で、顧客の実際の行動を測れない →選択肢(D)を消す |
| 効率的かつ信頼性が高く、リスクを抑えた検証 | バリアントの重みは動的に変更可能で、悪化すれば即座に旧モデルへ戻せる。全面切り替えは影響範囲が全顧客に及ぶ →選択肢(A)が正解 |
| 収集した指標の可視化・分析 | 行動イベントを Kinesis Data Streams で収集 → CloudWatch で監視 → QuickSight で分析という流れが自然 →選択肢(A)が正解 |
ひっかけポイント
- 選択肢 B の SageMaker Model Monitor は「モデルの劣化を監視する」サービスであって、A/B テストのビジネス評価基盤ではない。名前に Monitor とあるため「比較にも使えそう」と感じさせるのが罠
- 「エンドポイントを分けて両方動かす」は一見 A/B テストに見えるが、トラフィックを統制して振り分ける仕組みがないため公正な比較にならない。A/B テストは「1 エンドポイント × 複数バリアント」が基本形
- 選択肢 C の「問題があれば即ロールバック」は安全そうに聞こえるが、全顧客に新モデルを当ててから気付く構成であり、リスク低減にも比較検証にもなっていない
- 評価指標が技術指標(レイテンシー・メモリ)かビジネス指標(CVR・売上)かを必ず読み分ける。本問は「ビジネス上の価値」と明記されている
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「新モデルへ段階的にトラフィックを移し、指標が悪化したら自動で切り戻したい」 | SageMaker のブルー/グリーンデプロイ(カナリア・リニア)+ CloudWatch アラームによる自動ロールバックが正解軸に。 |
| 「本番トラフィックを新モデルにも複製して流し、応答は返さずに挙動だけ確認したい」 | シャドーテスト(シャドーバリアント)が正解に。顧客への影響ゼロで新モデルを検証する手法。 |
| 「デプロイ後、入力データの分布が学習時からずれていないか監視したい」 | SageMaker Model Monitor(データ品質・モデル品質の監視)が正解軸に浮上する。 |
| 「ユーザーごとに常に同じモデルが当たるようにして A/B テストしたい」 | 推論リクエストでTargetVariant を明示指定する(またはアプリ側でユーザーをグループ固定する)方式が問われる。 |
- Amazon SageMakerのプロダクションバリアント機能を使用して、既存モデルと新しいモデルにトラフィックを分割する。各モデルがサービスするユーザーグループに対して、クリック率、コンバージョン率、セッションあたりの売上などのビジネス指標をAmazon Kinesis Data Streamsで収集し、Amazon CloudWatchでモニタリング後、Amazon QuickSightで分析する
- 新しいモデルを専用のAmazon SageMakerエンドポイントとしてデプロイし、既存モデルのエンドポイントとは別に稼働させる。Amazon SageMaker Model Monitorを利用して、両モデルの推論時間、メモリ使用量、モデルドリフトなどの技術的なメトリクスを比較し、より優れたモデルを選択する
- 新しいモデルを既存モデルの代替として全面的に本番環境にデプロイする。数日間にわたり、顧客フィードバックや売上データの変動を広範囲にわたって監視し、問題が発生した場合は直ちに既存モデルにロールバックする
- AWS Lambda関数を使用して、ウェブサイトの特定のリクエストに対して、新しいモデルと既存モデルの両方から予測を取得する。これらの予測結果を少数の社内ユーザーが手動で比較し、よりパーソナライズされた推薦を提供していると判断されたモデルを本番に導入する