AWS MLA無料問題集です。正解と解説を確認する際は右側のボタンを押下してください。
問題集の完全版は以下Udemyにて発売しているためお買い求めください。問題集への質問はUdemyのQA機能もしくはUdemyのメッセージにて承ります。Udemyの問題1から10問抜粋しております。
多くの方にご好評いただき、講師評価 4.5/5.0 を獲得できております。ありがとうございます。
特別価格： 通常2,600円 → 1,500円
講師クーポン適用で42%OFF
この資格を活かしたキャリア情報
MLA資格の取得後にどんなキャリアが開けるか、詳しくはこちら：
→ MLA合格者の転職市場価値と求人傾向
AWS資格全体のキャリア活用法：
→ AWS資格は転職・キャリアアップでどう活きる？資格別市場価値と実体験
講師クーポン【図解付き詳細解説】AWS MLA-C01完全攻略問題集 | 構成図＆グラフ解説付き
問題文：
全国の提携病院へ胸部X線画像の読影支援を提供する医療機器メーカーが、肺炎や結節を検出する診断支援モデルをAmazon SageMakerで開発しています。データサイエンスチームは毎週、新しい症例データを取り込んでモデルを再学習しており、1週間に十数本の新しいモデルバージョンが生まれています。学習データとモデルアーティファクトはAmazon S3に保存されています。
バージョンが増え続けるなか、チームはモデルを一元的に整理し、医師の承認が済んだバージョンだけを本番の読影支援サービスへ展開できる仕組みを求めています。運用の手間をできるだけ増やさずにこの要件を満たすには、どの対応が適切ですか。
選択肢：
A. 学習済みアーティファクトをAmazon S3にバージョン別のプレフィックスで保存し、承認状況は別途スプレッドシートで記録します。
B. SageMaker Model Registryへモデルを登録し、バージョンの区別を一意なタグだけに頼って管理します。
C. AWS CodeArtifactのリポジトリにモデルをパッケージとして格納し、バージョンごとのタグで区別して管理します。
D. SageMaker Model Registryでモデルグループを作成し、各モデルをバージョンとしてその配下に登録します。
正解：D
A. 学習済みアーティファクトをAmazon S3にバージョン別のプレフィックスで保存し、承認状況は別途スプレッドシートで記録します。
不正解 Amazon S3はモデルの実体の保存先にはなれますが、バージョンのカタログ化や承認ワークフローといったモデル管理の機能を提供しません。バージョニングを有効にしてもオブジェクト単位のバージョンIDが付くだけで、評価メトリクスや承認ステータスは保持できません。承認状況をスプレッドシートで人手管理する運用は、バージョンが増えるほど転記ミスや承認漏れが起きやすく、運用の手間も膨らみます。
B. SageMaker Model Registryへモデルを登録し、バージョンの区別を一意なタグだけに頼って管理します。
不正解 Model Registryには、関連するモデルをまとめるモデルグループと、各バージョンに付与される承認ステータスという仕組みが用意されています。登録直後のバージョンはPendingManualApprovalであり、Approvedへ変更したものだけを本番展開の対象にできます。タグだけに頼るとこの構造を活かせず、どれが承認済みかを一元的に把握できないため、管理の手間がかえって大きくなります。
C. AWS CodeArtifactのリポジトリにモデルをパッケージとして格納し、バージョンごとのタグで区別して管理します。
不正解 AWS CodeArtifactは、npmやMaven、pipなどのソフトウェアパッケージを保存・共有するためのマネージドリポジトリです。モデルのメタデータや承認ステータス、承認ワークフローを管理する機能はなく、タグでバージョンを区別できても、承認済みかどうかを一覧で把握できません。モデル管理に特化した仕組みが欠けています。
D. SageMaker Model Registryでモデルグループを作成し、各モデルをバージョンとしてその配下に登録します。
正解 SageMaker Model Registryは、モデルのバージョン管理やメタデータの保存、承認ワークフローの実装といった機能をまとめて提供するマネージドサービスです。モデルグループという単位で関連するモデルを束ね、その配下に各バージョンを登録することで、モデルを論理的に整理できます。インフラの管理が不要なため運用の手間は小さく、SageMakerの他の機能とも連携します。
全体的な説明
問われている要件
- 増え続けるモデルバージョンを一元的に管理すること
- 承認が済んだバージョンだけを本番へ展開すること
- 運用の手間を最小限に抑えること
- Amazon SageMakerのワークフローと統合すること
前提知識
SageMaker Model Registryについて
SageMaker Model Registryは、機械学習モデルのライフサイクル管理を支援するマネージドサービスです。モデルグループを使って関連するモデルを論理的にグループ化し、各モデルバージョンのメタデータやアーティファクト、承認ステータスを管理できます。モデルバージョンごとに説明や評価メトリクス、承認状態などの情報を保存し、承認ワークフローを実装することで本番への展開を制御できます。SageMaker PipelinesやSageMaker Experimentsとも統合されており、MLOpsの流れに組み込みやすくなっています。
AWS CodeArtifactとAmazon S3について
AWS CodeArtifactは、npmやMaven、pipなどのソフトウェアパッケージを保存・共有するためのマネージドリポジトリで、Amazon S3は汎用的なオブジェクトストレージです。いずれもモデルの実体を置く場所にはなれますが、バージョンのカタログ化や承認ワークフロー、SageMakerの他機能との連携といったモデル管理に特化した機能は提供していません。これらの汎用サービスだけでモデルを管理しようとすると、管理の手間が増えます。
モデル管理の運用オーバーヘッドについて
運用オーバーヘッドとは、システムを動かし続けるために必要な手作業や管理作業の量を指します。専用のマネージドサービスを利用すれば、インフラの管理やスケーリング、セキュリティパッチの適用といった作業をAWS側に任せられるため、運用の手間を減らせます。一方、汎用的なサービスを組み合わせて独自に実装する場合は、それらの作業を自社で行う必要があり、運用オーバーヘッドが増加します。
図による解説
アーキテクチャ図
モデルは「モデルグループ」という単位で束ね、その配下にバージョンを順に登録します。実験や学習で得られたモデルはグループへ新しいバージョンとして追加され、実体となるアーティファクトはS3に保存されたうえで各バージョンから参照されます。本番エンドポイントへは、承認ステータスが付いたバージョンだけを展開する運用が可能です。モデルの実体とその管理情報を分離し、承認という関門を挟みます。モデルをS3のフォルダ分けやパッケージリポジトリのタグだけで管理しようとすると、どのバージョンが承認済みか、どれが本番へ展開済みかを一覧できず、バージョンが増えるほど運用の手間が膨らみます。
解くための考え方
複数バージョンを一元管理し、承認済みだけを本番へ展開し、運用の手間は小さく抑えます。 SageMaker Model Registryは、モデル管理に特化したマネージドサービスです。モデルグループという単位でモデルを整理し、各バージョンのメタデータ管理や承認ワークフローの実装、SageMakerの他の機能との連携までを一元的に提供します。マネージドサービスであるため、インフラの管理やスケーリングといった運用作業が不要で、運用の手間も小さく済みます。 一方、Amazon S3のフォルダ分けやAWS CodeArtifactのタグで管理する方法は、モデルの実体を保存できても、バージョンのカタログ化や承認ワークフローを自前で用意する必要があります。バージョンが増えるほど管理の手間が膨らみ、承認漏れも起きやすくなります。 したがって、承認済みバージョンだけを本番へ展開しつつ運用の手間を増やさないには、SageMaker Model Registryとモデルグループを組み合わせるのが適切です。
参考資料
問題文：
ある企業のデータサイエンスチームが、翌日の需要量を予測するモデルをAmazon SageMakerで開発しています。気象データと実績データの組み合わせ方で予測精度が変わるため、特徴量やハイパーパラメータを変えながら1日に数十回の学習ジョブを連続で回しています。
ところが、ジョブを回すたびにEC2インスタンスのプロビジョニングと実行環境の読み込みに数分から十数分かかり、この起動待ちが実験サイクルの足を引っ張っています。学習ジョブのインフラストラクチャ起動時間を最小限に抑えるには、どの対応が適切ですか。
選択肢：
A. SageMaker managed warm poolsで、学習ジョブが使用したリソースを完了後も保持し、後続のジョブで再利用します。
B. 各学習ジョブでチェックポイントをAmazon S3に保存し、中断した場合に途中から再開できるようにします。
C. SageMakerの分散データ並列（SMDDP）ライブラリを使い、学習対象のデータを複数のインスタンスへ分散して並列に学習を実行します。
D. Amazon FSx for Lustreを学習データ用のファイルシステムとしてマウントし、学習時のデータ読み込みを高速化します。
正解：A
A. SageMaker managed warm poolsで、学習ジョブが使用したリソースを完了後も保持し、後続のジョブで再利用します。
正解 SageMaker managed warm poolsは、プロビジョニング済みのリソースを学習ジョブの完了後も保持し、構成が一致する後続の学習ジョブで再利用する機能です。保持時間は学習ジョブごとにKeepAlivePeriodInSecondsで指定し、IAMロール、インスタンスタイプ、インスタンス数、ボリュームサイズ、VPC設定が一致するジョブを続けて投入すれば、すでに起動しているインスタンスをそのまま使えます。インスタンスのプロビジョニングやコンテナイメージの読み込みに要する時間が大幅に短縮されるため、実験サイクルを速められます。
B. 各学習ジョブでチェックポイントをAmazon S3に保存し、中断した場合に途中から再開できるようにします。
不正解 チェックポイントは、学習ジョブが中断されたときに保存済みの状態から再開できるようにする仕組みです。短縮されるのは中断後の再学習時間であり、新しいジョブを始める際のEC2インスタンスのプロビジョニングや実行環境の読み込みといった起動時間は変わりません。そのため、起動待ちを減らす要件には向きません。
C. SageMakerの分散データ並列（SMDDP）ライブラリを使い、学習対象のデータを複数のインスタンスへ分散して並列に学習を実行します。
不正解 SMDDPライブラリは、学習データを複数のインスタンスへ分散し、勾配同期に使うAllReduceやAllGatherといった集合通信をAWSのインフラストラクチャ向けに最適化して、分散学習のスループットを高めるものです。効果が及ぶのは学習の実行フェーズであり、ジョブ開始時のインスタンスのプロビジョニングやコンテナイメージの読み込みに要する時間は変わらないため、起動待ちを減らす要件には向きません。
D. Amazon FSx for Lustreを学習データ用のファイルシステムとしてマウントし、学習時のデータ読み込みを高速化します。
不正解 Amazon FSx for Lustreは、大量の学習データを高いスループットで学習ジョブに供給するためのファイルシステムです。Amazon S3から学習データをインスタンスのボリュームへ毎回ダウンロードする手間は省けますが、EC2インスタンスのプロビジョニングやコンテナイメージの読み込みといったインフラストラクチャの起動時間そのものは変わりません。むしろファイルシステムの初期化や遅延ロードによるコールドスタートの分だけ待ちが生じることもあり、起動待ちを減らす要件には向きません。
全体的な説明
問われている要件
- 連続して実行する学習ジョブのインフラストラクチャ起動時間を最小限に抑えること
- 1日に数十回行う実験の回転を上げること
- 起動待ちの時間を減らし、予測モデルの改善サイクルを速めること
- 運用の手間を大きく増やさないこと
前提知識
SageMaker managed warm poolsについて
学習ジョブが終わったあとも、使用したリソースをプロビジョニング済みの状態で保持し続ける機能です。IAMロール、インスタンス数、インスタンスタイプ、ボリュームサイズ、VPC設定などの構成が前のジョブと一致する後続ジョブが送信されると、起動済みのリソースがそのまま再利用され、インスタンスの起動やコンテナイメージの読み込みに要する時間が大幅に短縮されます。保持時間は学習ジョブごとにKeepAlivePeriodInSecondsで指定し（1ジョブあたり最大3600秒）、条件が一致するジョブを連続して投入すればウォームプール自体は最大28日間まで維持できます。保持中のインスタンスには料金が発生するため、繰り返しの実験や連続実行するジョブが多いワークロードで効果を発揮します。
Amazon FSx for Lustreについて
Amazon FSx for Lustreは、機械学習の学習ジョブ向けに高いスループットでデータを供給できるファイルシステムです。学習データをジョブのたびにAmazon S3からダウンロードする必要がなくなり、学習中のデータ読み込みも高速になるため、データ入出力がボトルネックになるワークロードでは学習時間を短縮できます。ただし、EC2インスタンスのプロビジョニングやコンテナイメージの読み込みといったインフラストラクチャの起動時間には影響せず、ファイルシステムの初期化や遅延ロードに伴うコールドスタートが起きることもあります。
チェックポイントについて
チェックポイントは、学習ジョブの進行状況を定期的にAmazon S3へ保存し、ジョブが中断された場合に保存済みの状態から再開できるようにする仕組みです。中断後の再学習を省けるため、長時間の学習ジョブでは有効です。ただし、短縮されるのは中断後の再学習時間であり、新しいジョブを始める際のEC2インスタンスのプロビジョニングや実行環境の読み込みといった起動時間には影響しません。
SageMaker分散データ並列（SMDDP）について
データを複数のワーカーに分散し、各ワーカーでモデルのコピーを学習させることで、大規模な学習のスループットを高めるライブラリです。対象は学習の実行時間であり、ジョブごとの起動コストを下げる役割は持っていません。
解くための考え方
学習ジョブの開始時には、EC2インスタンスのプロビジョニングや実行環境の読み込みといった初期化処理が必ず発生します。ここに数分から十数分かかるため、1日に数十回ジョブを回すと、毎回同じ待ち時間が積み上がります。 managed warm poolsは、この初期化済みのリソースをジョブ完了後も保持し、構成が一致する後続ジョブに再利用させることで問題を解消します。インスタンスはすでに起動した状態なので、実験ごとの起動待ちが大きく減ります。 これに対し、Amazon FSx for Lustreが速くするのは学習データの供給であり、インスタンスのプロビジョニングやコンテナイメージの読み込みという起動処理そのものには影響しません。チェックポイントが短縮するのは中断後の再学習時間、SMDDPライブラリが速くするのは学習の実行フェーズであり、いずれもインフラストラクチャの起動待ちを減らすものではありません。 したがって、連続する学習ジョブの起動時間を最小限に抑えるには、SageMaker managed warm poolsが適切です。
参考資料
問題文：
ある企業が、サービス契約の解約（チャーン）を予測するモデルをAmazon SageMakerで開発しています。データサイエンスチームは毎週、新しい利用実績データでモデルを再学習し、十数本のモデル候補を作り出しています。
ガバナンス部門は、判定の妥当性と説明責任を担保するため、責任者の承認を得たモデルだけが本番の解約予測APIに展開される仕組みを求めています。モデルの登録後に人の承認を挟み、承認済みのモデルだけを本番へ展開するワークフローを実装するには、どのソリューションが適切ですか。
選択肢：
A. SageMaker PipelinesとModel Registryを組み合わせ、承認ステータスをAWS SDKで更新します。
B. SageMaker ML Lineage Trackingで、データの出所と変換履歴を追跡するエンティティを作成して管理します。
C. SageMaker Experimentsで実験の実行とパラメータ・メトリクスを記録し、その結果を使ってモデル登録時の承認を管理します。
D. SageMaker Feature Storeにモデルの特徴量を保存して共有し、その更新状況でデプロイの承認を管理します。
正解：A
A. SageMaker PipelinesとModel Registryを組み合わせ、承認ステータスをAWS SDKで更新します。
正解 SageMaker Pipelinesは、前処理から学習・評価・モデル登録までをパイプラインとして自動化し、SageMaker Model Registryと統合されたサービスです。登録ステップで作成したモデルバージョンは手動承認待ち（PendingManualApproval）の状態に置かれ、責任者がAWS SDKやコンソールから承認済み（Approved）へ更新した時点で初めてデプロイ側の処理が動きます。この承認ステータスが関門として働くため、未承認のモデルが本番の解約予測APIへ展開されることを防げます。
B. SageMaker ML Lineage Trackingで、データの出所と変換履歴を追跡するエンティティを作成して管理します。
不正解 SageMaker ML Lineage Trackingは、学習に使ったデータセットや前処理、学習ジョブといったアーティファクト間の関係と変換履歴を記録する機能です。監査や再現性の向上には役立ち、モデルパッケージやモデルデプロイもコンテキストやアクションとして系譜に現れます。しかし記録されるのはあくまで実行済みの事実であり、承認の関門を設けたり、未承認モデルのデプロイを止めたりする機能は持っていません。
C. SageMaker Experimentsで実験の実行とパラメータ・メトリクスを記録し、その結果を使ってモデル登録時の承認を管理します。
不正解 SageMaker Experimentsは、ML実験の実行やパラメータ・メトリクスの記録と比較を行うサービスです。複数の実験結果を比較して最良のモデルを選ぶ場面では役立ちますが、承認ワークフローを実装したり、未承認モデルのデプロイを制御したりする機能は備えていません。承認ベースの展開には使えません。
D. SageMaker Feature Storeにモデルの特徴量を保存して共有し、その更新状況でデプロイの承認を管理します。
不正解 SageMaker Feature Storeは、特徴量の作成・保存・共有・管理を簡素化する機能です。オンラインストアとオフラインストアで特徴量を扱いますが、モデルの承認ワークフローを実装したり、未承認モデルのデプロイを制御したりする機能は提供していません。特徴量の管理とモデルの承認は別の責務です。
全体的な説明
問われている要件
- モデルの登録後に人の承認を挟むワークフローを実装すること
- 承認済みのモデルだけを本番の解約予測APIへ展開すること
- 未承認のモデルが本番へ展開されないように制御すること
- 登録から承認までのプロセスを監査可能な形で管理すること
前提知識
SageMaker Pipelinesについて
MLワークフローをステップ単位で定義し、実行を自動化するマネージドサービスです。データの前処理から学習、評価、登録、デプロイまでの流れを1つのパイプラインとして扱え、条件分岐やパラメータの受け渡しもサポートしています。SageMaker Model Registryと統合されており、モデルバージョンの登録と承認ステータスの管理をパイプラインの中に組み込めます。
SageMaker Model Registryの承認ステータスについて
Model Registryでは、モデルバージョンごとに承認ステータスを管理します。モデルバージョンを作成した直後のステータスは手動承認待ち（PendingManualApproval）です。評価結果が基準を満たせば承認済み（Approved）、満たさなければ却下（Rejected）へ更新します。承認済みへの遷移がCI/CDによるデプロイ開始の引き金になるため、承認済みモデルだけが本番へ展開される制御が実現します。ステータスの更新はAWS SDKやコンソールから行えます。
SageMaker Experimentsについて
実行した実験のパラメータやメトリクスを記録し、後から比較・分析するためのサービスです。実験の管理と追跡が役割であり、モデルの承認ワークフローやデプロイを制御する機能はありません。
SageMaker ML Lineage Trackingについて
モデルの学習に使ったデータセット、前処理スクリプト、学習ジョブ、評価結果といったアーティファクト間の関係を記録し、再現性と監査性を高める機能です。アーティファクト、アクション、コンテキストといったエンティティと、それらを結ぶ関連付けで構成され、手動でエンティティを作成して情報を追加することもできます。ただし記録するのは実行済みの事実であり、承認ワークフローの実装や未承認モデルのデプロイ制御はできません。
SageMaker Feature Storeについて
特徴量（機械学習モデルへの意味ある入力）の作成、保存、共有、管理を簡素化する機能です。オンラインストアは低レイテンシーのリアルタイム推論向けに最新レコードを保持し、オフラインストアは学習やバッチ推論向けに履歴を保持します。あくまで特徴量の管理が役割であり、モデルの承認ワークフローやデプロイ制御の機能は提供していません。
図による解説
アーキテクチャ図
モデルを登録した直後にデプロイへ進めるのではなく、Model Registryの承認ステータスを関門として挟み込みます。SageMaker Pipelinesがデータ前処理・モデルトレーニング・モデル評価・モデル登録の各ステップを順に実行し、登録されたモデルバージョンは承認待ちの状態でModel Registryに置かれます。承認者がAWS SDKやコンソールでステータスを承認済みに更新して初めて、本番エンドポイントへの展開が可能になります。この関門を省いて登録とデプロイを直結させると、評価や人の確認を経ていないモデルまで本番に届いてしまうため、承認ステータスによる明示的な展開制御が不可欠です。
解くための考え方
SageMaker PipelinesはMLワークフローを自動化するサービスで、Model Registryと統合されています。パイプラインへ人の承認を挟めば、承認済みのモデルだけを本番へ展開できます。パイプラインの登録ステップでモデルバージョンを承認待ちのまま登録し、承認者がAWS SDKやコンソールから承認済みに変更したタイミングでデプロイが進むようにすれば、人の判断を経たモデルだけが本番に届きます。 SageMaker Experimentsは実験の記録と比較が役割で、承認やデプロイの制御機能はありません。SageMaker ML Lineage Trackingはデータの出所や変換履歴を追跡する機能で、事後の監査には役立っても、デプロイを制御する仕組みは持っていません。SageMaker Feature Storeは特徴量の保存・共有が役割で、モデルの承認ゲートにはなりません。 したがって、承認済みのモデルだけを本番へ展開するには、SageMaker PipelinesとModel Registryを使い、承認ステータスをAWS SDKで管理する構成が適切です。
参考資料
問題文：
ある航空会社が、お客様窓口に届く問い合わせの緊急度と振り分け先を分類するモデルをAmazon SageMakerで開発し、本番のリアルタイムエンドポイントに展開しています。公平性担当チームは、このモデルの判断が依頼者の居住地や会員ランクといった特定の属性に偏っていないかを点検する必要があります。
学習時と本番とでバイアスがどのように変化したかを、必要なときに都度実行できるオンデマンドのワークフローで監視したいと考えています。この要件を満たすには、どの対応が適切ですか。
選択肢：
A. SageMakerノートブックをその都度起動し、学習時と本番のデータから算出したバイアスを比べる手順にします。
B. AWS Glue Data Qualityにデータ品質のルールを登録し、その検出結果をバイアスの監視に用います。
C. バイアスの点検が必要になる都度、AWS Lambda関数からSageMaker Clarifyのジョブを起動する仕組みにします。
D. Amazon CloudWatchにしきい値付きのアラームを設定し、バイアスドリフトの超過を検知したら即時に通知する構成にします。
正解：C
A. SageMakerノートブックをその都度起動し、学習時と本番のデータから算出したバイアスを比べる手順にします。
不正解 SageMakerノートブックにバイアス比較のコードを用意して実行するのは技術的に可能で、Studioのノートブックジョブを使えばオンデマンド実行やスケジュール実行もできます。ただしこの方法では、学習時と本番のバイアスをどの指標でどう比較するかを自前で実装し、そのコードを保守し続けなければなりません。バイアスメトリクスの算出やベースラインとの比較を担うマネージドな仕組みを使わないため、運用の手間が大きくなります。
B. AWS Glue Data Qualityにデータ品質のルールを登録し、その検出結果をバイアスの監視に用います。
不正解 AWS Glue Data Qualityがルールで検査するのは、欠損値・重複・異常値といったデータそのものの品質です。役割はデータの品質保証にあり、機械学習モデルの予測バイアスや、学習時と本番の間でバイアスが変わる現象を監視する機能は備えていません。
C. バイアスの点検が必要になる都度、AWS Lambda関数からSageMaker Clarifyのジョブを起動する仕組みにします。
正解 SageMaker Clarifyは、モデルのバイアスや公平性の問題を定量化して検出するサービスです。Lambda関数を呼び出し元にすれば、点検が必要になったタイミングでその都度ジョブを実行できます。スケジュールやイベントをきっかけに起動できるため、リアルタイムエンドポイントのモデルを継続的に監視しつつ、運用の手間も小さく抑えられます。
D. Amazon CloudWatchにしきい値付きのアラームを設定し、バイアスドリフトの超過を検知したら即時に通知する構成にします。
不正解 Amazon CloudWatchは、メトリクスの収集・可視化・アラーム通知を担う監視サービスです。一方で、モデルのバイアスや公平性を数値として算出する機能は持たないため、学習時と本番の間でバイアスがどう変わったかは捉えられません。バイアスドリフトを監視するには、SageMaker Clarifyが計算するバイアスメトリクスが欠かせません。
全体的な説明
問われている要件
- リアルタイムエンドポイントに展開したモデルのバイアスドリフトを監視すること
- 必要なときに都度実行できるオンデマンドのワークフローにすること
- 手作業の分析に頼らず、バイアスメトリクスを自動的に検出すること
- 運用の手間を最小限に抑えること
前提知識
SageMaker Clarifyについて
機械学習モデルのバイアスや公平性の問題を検出するサービスです。前処理バイアスや後処理バイアスといったバイアスメトリクスを計算し、モデルの判断が特定の属性に対して不当に偏っていないかを評価できます。さらに、学習データと本番データの間のバイアスの変化を追うバイアスドリフト監視の機能も備えています。Clarifyジョブは処理ジョブ（バッチ処理）として動作するため、AWS Lambdaから呼び出せば、必要なタイミングで都度実行する監視が実現します。
AWS Lambdaについて
サーバーのプロビジョニングなしでコードを実行できるサーバーレスコンピューティングサービスです。スケジュールやイベントをきっかけに起動でき、SageMaker Clarifyジョブの呼び出し元として使えます。Amazon EventBridgeによるスケジュール実行にも対応しているため、定期監視にも展開できます。サーバー管理の手間がなく、運用負荷を抑えた監視構成が作れます。
Amazon CloudWatchについて
メトリクスの収集・可視化・アラーム通知を提供する監視サービスです。しきい値に基づくアラームやダッシュボードによる可視化には使えますが、モデルの公平性やバイアスを定量化するメトリクスを計算する機能はありません。バイアスドリフトの監視には、SageMaker Clarifyが計算するバイアスメトリクスが必要です。
AWS Glue Data Qualityについて
欠損値や重複、異常値など、データそのものの品質をルールとして定義し、整合性をチェックするサービスです。役割はデータの品質保証であり、モデルの予測バイアスを評価したり、学習時と本番の間での変化を監視したりする機能は持っていません。
SageMakerノートブックについて
データの探索やモデル開発、実験の実行に使うJupyter環境です。SageMaker Studioのノートブックジョブを使えば、ノートブックを即時実行したり、cron構文を含むスケジュールで繰り返し実行したりもできます。ただし、ノートブックの中でバイアスの算出ロジックを自作する運用では、指標の定義や比較処理を自前で保守し続けることになります。監視の仕組みとして安定して回すには、バイアスメトリクスの算出そのものをマネージドな機能に任せる構成が適しています。
解くための考え方
バイアスドリフト、すなわち学習時と本番の間でのバイアスの変化は、SageMaker Clarifyの専用機能で検出します。Clarifyはバイアスメトリクスをバッチジョブとして計算でき、AWS Lambdaから呼び出せば必要なときに都度実行できます。Amazon EventBridgeでスケジュールすれば定期監視にもなります。 Amazon CloudWatchはメトリクスの可視化とアラームが役割で、バイアスメトリクスの計算そのものは行いません。AWS Glue Data Qualityが評価するのはデータそのものの品質であり、モデルの監視は守備範囲の外です。ノートブックはスケジュール実行こそできますが、バイアスの算出ロジックを自前で実装・保守することになり、運用の手間が膨らみます。 したがって、バイアスドリフトをオンデマンドで監視するには、AWS Lambda関数からSageMaker Clarifyジョブを実行する構成が適切です。
参考資料
問題文：
全国に3,000台超の配送車両を保有する物流企業が、車両のGPSと荷台の温度センサーから収集した稼働履歴をAmazon S3に.csvファイルとして蓄積しています。このファイルは1日あたり数百万件に達しますが、センサーの不具合で一部の行と列にしか値が入っておらず、各列には見出しも付いていません。データサイエンスチームは、このデータを配送遅延を予測するモデルの学習に使える形へ整え、保存する必要があります。この作業を進めるために、以下のリストから正しい手順を選んで順序付けます。各手順は1回選択するか、まったく選択しないかのいずれかです。（3つ選択して順序付け）
・Amazon SageMakerバッチ変換ジョブを作成して欠損値の処理と特徴量の作成を行う
・処理済みのデータをAmazon S3に保存する
・Amazon AthenaでSQLクエリを実行してテーブル定義を確認する
・AWS Glueクローラーで稼働履歴をスキャンして列名とデータ型を推定する
・AWS Glue DataBrewで欠損値の処理と特徴量の作成を行う
選択肢：
A. Step 1: Amazon AthenaでSQLクエリを実行してテーブル定義を確認する Step 2: AWS Glue DataBrewで欠損値の処理と特徴量の作成を行う Step 3: 処理済みのデータをAmazon S3に保存する
B. Step 1: AWS Glue DataBrewで欠損値の処理と特徴量の作成を行う Step 2: AWS Glueクローラーで稼働履歴をスキャンして列名とデータ型を推定する Step 3: 処理済みのデータをAmazon S3に保存する
C. Step 1: AWS Glueクローラーで稼働履歴をスキャンして列名とデータ型を推定する Step 2: AWS Glue DataBrewで欠損値の処理と特徴量の作成を行う Step 3: 処理済みのデータをAmazon S3に保存する
D. Step 1: Amazon AthenaでSQLクエリを実行してテーブル定義を確認する Step 2: Amazon SageMakerバッチ変換ジョブを作成して欠損値の処理と特徴量の作成を行う Step 3: 処理済みのデータをAmazon S3に保存する
E. Step 1: AWS Glueクローラーで稼働履歴をスキャンして列名とデータ型を推定する Step 2: Amazon SageMakerバッチ変換ジョブを作成して欠損値の処理と特徴量の作成を行う Step 3: 処理済みのデータをAmazon S3に保存する
F. Step 1: AWS Glueクローラーで稼働履歴をスキャンして列名とデータ型を推定する Step 2: 処理済みのデータをAmazon S3に保存する Step 3: AWS Glue DataBrewで欠損値の処理と特徴量の作成を行う
正解：C
A. Step 1: Amazon AthenaでSQLクエリを実行してテーブル定義を確認する Step 2: AWS Glue DataBrewで欠損値の処理と特徴量の作成を行う Step 3: 処理済みのデータをAmazon S3に保存する
不正解 Amazon AthenaはS3内のデータへSQLクエリを実行するサービスであり、列構成を推定する機能はありません。Athenaを利用するには事前にスキーマを定義しておく必要があるため、列見出しのない.csvファイルから列構成を推定する作業には適していません。列構成の推定にはAWS Glueクローラーを使う必要があります。
B. Step 1: AWS Glue DataBrewで欠損値の処理と特徴量の作成を行う Step 2: AWS Glueクローラーで稼働履歴をスキャンして列名とデータ型を推定する Step 3: 処理済みのデータをAmazon S3に保存する
不正解 使うサービスの組み合わせは適切ですが、実行の順序が入れ替わっています。列見出しのない.csvは、どの列がGPS座標でどの列が温度かも、各列の型も分からない状態です。この段階では、どの列の欠損値をどう補完するかも、どの列から特徴量を作るかも決められません。まずAWS Glueクローラーで列名とデータ型を推定し、構造を確定させてから前処理へ進む必要があります。
C. Step 1: AWS Glueクローラーで稼働履歴をスキャンして列名とデータ型を推定する Step 2: AWS Glue DataBrewで欠損値の処理と特徴量の作成を行う Step 3: 処理済みのデータをAmazon S3に保存する
正解 列見出しのない.csvファイルから列の構成を把握するには、AWS Glueクローラーを使います。クローラーはS3内のデータをスキャンし、列名やデータ型を自動的に推定します。次に、AWS Glue DataBrewは欠損値の補完や特徴量の作成を視覚的な操作で行えるサービスです。最後に、処理済みのデータをS3へ保存することで、モデルの学習に使える形式でデータを準備できます。
D. Step 1: Amazon AthenaでSQLクエリを実行してテーブル定義を確認する Step 2: Amazon SageMakerバッチ変換ジョブを作成して欠損値の処理と特徴量の作成を行う Step 3: 処理済みのデータをAmazon S3に保存する
不正解 Amazon Athenaは列構成を推定する機能を提供しておらず、Amazon SageMakerバッチ変換ジョブも学習済みモデルが前提のため、モデルが存在しない学習データの準備段階には使えません。この組み合わせは、列見出しのない.csvファイルから列構成を推定し、データを前処理してモデルの学習に使える形へ整える作業には適していません。
E. Step 1: AWS Glueクローラーで稼働履歴をスキャンして列名とデータ型を推定する Step 2: Amazon SageMakerバッチ変換ジョブを作成して欠損値の処理と特徴量の作成を行う Step 3: 処理済みのデータをAmazon S3に保存する
不正解 最初にAWS Glueクローラーで列構成を推定する点は適切ですが、2番目の手順が成立しません。Amazon SageMakerバッチ変換ジョブは、登録済みのモデルを指定して大量の入力データへ推論を実行し、結果をS3へ書き出す仕組みです。ジョブを作成するAPIではモデル名の指定が必須のため、これから学習させるモデルしかないこの段階では起動できません。前処理にはAWS Glue DataBrewのような専用サービスを使います。
F. Step 1: AWS Glueクローラーで稼働履歴をスキャンして列名とデータ型を推定する Step 2: 処理済みのデータをAmazon S3に保存する Step 3: AWS Glue DataBrewで欠損値の処理と特徴量の作成を行う
不正解 3つの手順そのものは必要ですが、保存と前処理の順序が逆になっています。AWS Glueクローラーが行うのはスキーマの推定とAWS Glue Data Catalogへのメタデータ登録だけで、S3上の.csvの中身は書き換わりません。この時点で保存しても、センサーの不具合で値が欠けたままの生データが置かれるだけです。AWS Glue DataBrewで前処理を済ませ、その出力をS3へ保存する順にする必要があります。
全体的な説明
問われている要件
- 列見出しのない.csvファイルから列名とデータ型を推定すること
- 欠損値の処理と特徴量の作成を行うこと
- 処理済みのデータをモデルの学習に使える形式で保存すること
- 各手順を適切な順序で実行すること
前提知識
AWS Glueクローラーについて
AWS Glueクローラーは、データソースをスキャンして列名やデータ型などのスキーマを自動的に推定するサービスです。S3内の.csvファイルなどをスキャンし、検出したメタデータをAWS Glue Data Catalogへ登録します。組み込みのCSV分類子は、先頭行が見出しかどうかをヒューリスティックで判定し、見出しが検出できない場合はcol1、col2といった既定の列名を割り当てたうえで、各列の内容からデータ型を推定します。複数のファイルをまとめてスキャンし、共通のスキーマを推定することも可能です。
AWS Glue DataBrewについて
AWS Glue DataBrewは、欠損値の処理や特徴量の作成を視覚的なインターフェースで行えるサーバーレスのサービスです。コードを書かずに、欠損値の補完、データ型の変換、異常値の検出、特徴量の作成などを実行できます。250種類を超える組み込み変換を備えており、データの品質を高めてモデルの学習に適した形へ整えられます。処理後のデータはS3などへ保存できます。
Amazon Athenaについて
Amazon Athenaは、S3内のデータへ標準的なSQLクエリを実行するサーバーレスのクエリサービスです。事前に定義されたスキーマに基づいてクエリを実行しますが、スキーマを推定する機能はありません。Athenaを利用するには、AWS Glue Data Catalogへスキーマを登録するか、テーブル定義を用意する必要があります。そのため、列見出しのないデータからスキーマを推定する作業には適していません。
Amazon SageMakerバッチ変換ジョブについて
Amazon SageMakerバッチ変換ジョブは、学習済みのモデルを使って大量のデータへバッチ推論を実行するサービスです。モデルによる予測を実行し、結果をS3へ保存します。推論パイプラインの一部として入力データの前処理を行うこともありますが、いずれも学習済みモデルが前提となるため、モデルがまだ存在しない学習データの準備段階では利用できません。
データ準備の流れについて
モデルの学習に使うデータを準備する際は、適切な順序で各手順を進める必要があります。まずデータの構造を理解するために列構成を推定し、次に欠損値の処理や特徴量の作成を行い、最後に処理済みのデータを保存します。この順序を守ることで、効率的にデータを準備できます。
図による解説
アーキテクチャ図
列見出しのないCSVデータは、モデルの学習に使える形へ次の順で整えます。AWS GlueクローラーがS3の生データをスキャンして列名とデータ型を推定し、その結果をGlue Data Catalogへメタデータとして登録します。次にGlue DataBrewが、登録されたスキーマを参照しながら欠損値の補完や特徴量の作成を行い、処理済みデータをS3へ保存します。列構成の推定は前処理より先です。列の意味や型を把握しないまま欠損処理や特徴量作成を始めると、どの列をどう扱うかの判断ができず、後から作り直しが発生します。Athenaはクエリ実行サービスで列構成の推定機能はないため、最初の工程には使えません。
解くための考え方
列名とデータ型の推定が先です。AWS GlueクローラーはS3内のデータをスキャンしてスキーマを自動的に推定します。Amazon Athenaはスキーマを推定する機能がないため、この作業には適していません。 欠損値の処理と特徴量の作成は、その次です。AWS Glue DataBrewは視覚的な操作で前処理を行えます。Amazon SageMakerバッチ変換ジョブは学習済みモデルが前提のため、モデルがまだ存在しないこの段階では使えません。 最後に、処理済みのデータをS3へ保存します。「列構成の推定 → 前処理 → 保存」の順を守ると、データを効率よく準備できます。
参考資料
問題文：
ある旅行会社が、旅行プランを提案する生成AIアシスタントをAmazon Bedrock上で構築しています。アシスタントは、社内の旅程資料や宿泊施設情報のデータベースを参照しながら、顧客の要望に即した正確なプランを作成する必要があります。
担当のMLエンジニアは、設計に必要な生成AIの用語を整理するため、以下のリストから各説明に合う用語を選ぶことにしました。各用語は1回選択するか、まったく選択しないかのいずれかです。 用語：
・埋め込み（Embedding）
・検索拡張生成（RAG）
・温度（Temperature）
・トークン（Token）
説明：
・説明1: モデルがテキストを出力する際のランダムさを調整し、回答のばらつきを制御する設定値
・説明2: テキストを高次元の数値ベクトルに変換し、意味の近さを計算できるようにする表現
・説明3: 回答を作る前に社内のナレッジベースを引き、見つかった内容を質問に添えてモデルに渡す手法
選択肢：
A. 説明1: モデルがテキストを出力する際のランダムさを調整し、回答のばらつきを制御する設定値: 埋め込み（Embedding） 説明2: テキストを高次元の数値ベクトルに変換し、意味の近さを計算できるようにする表現: 検索拡張生成（RAG） 説明3: 回答を作る前に社内のナレッジベースを引き、見つかった内容を質問に添えてモデルに渡す手法: 温度（Temperature）
B. 説明1: モデルがテキストを出力する際のランダムさを調整し、回答のばらつきを制御する設定値: 埋め込み（Embedding） 説明2: テキストを高次元の数値ベクトルに変換し、意味の近さを計算できるようにする表現: 温度（Temperature） 説明3: 回答を作る前に社内のナレッジベースを引き、見つかった内容を質問に添えてモデルに渡す手法: 検索拡張生成（RAG）
C. 説明1: モデルがテキストを出力する際のランダムさを調整し、回答のばらつきを制御する設定値: 温度（Temperature） 説明2: テキストを高次元の数値ベクトルに変換し、意味の近さを計算できるようにする表現: 埋め込み（Embedding） 説明3: 回答を作る前に社内のナレッジベースを引き、見つかった内容を質問に添えてモデルに渡す手法: 検索拡張生成（RAG）
D. 説明1: モデルがテキストを出力する際のランダムさを調整し、回答のばらつきを制御する設定値: 温度（Temperature） 説明2: テキストを高次元の数値ベクトルに変換し、意味の近さを計算できるようにする表現: 検索拡張生成（RAG） 説明3: 回答を作る前に社内のナレッジベースを引き、見つかった内容を質問に添えてモデルに渡す手法: 埋め込み（Embedding）
E. 説明1: モデルがテキストを出力する際のランダムさを調整し、回答のばらつきを制御する設定値: トークン（Token） 説明2: テキストを高次元の数値ベクトルに変換し、意味の近さを計算できるようにする表現: 埋め込み（Embedding） 説明3: 回答を作る前に社内のナレッジベースを引き、見つかった内容を質問に添えてモデルに渡す手法: 検索拡張生成（RAG）
F. 説明1: モデルがテキストを出力する際のランダムさを調整し、回答のばらつきを制御する設定値: 検索拡張生成（RAG） 説明2: テキストを高次元の数値ベクトルに変換し、意味の近さを計算できるようにする表現: 埋め込み（Embedding） 説明3: 回答を作る前に社内のナレッジベースを引き、見つかった内容を質問に添えてモデルに渡す手法: 温度（Temperature）
正解：C
A. 説明1: モデルがテキストを出力する際のランダムさを調整し、回答のばらつきを制御する設定値: 埋め込み（Embedding） 説明2: テキストを高次元の数値ベクトルに変換し、意味の近さを計算できるようにする表現: 検索拡張生成（RAG） 説明3: 回答を作る前に社内のナレッジベースを引き、見つかった内容を質問に添えてモデルに渡す手法: 温度（Temperature）
不正解 3つの対応がいずれも誤っています。埋め込みはテキストの意味を高次元の数値ベクトルへ変換する表現であり、出力のランダムさを決める設定値ではありません。検索拡張生成（RAG）は質問に関連する内容をナレッジベースから探してプロンプトへ添える手法であり、テキストをベクトルへ変換する表現でもありません。温度は次に選ぶトークンの確率分布の形を変えるパラメータで、ナレッジベースを参照する仕組みではありません。
B. 説明1: モデルがテキストを出力する際のランダムさを調整し、回答のばらつきを制御する設定値: 埋め込み（Embedding） 説明2: テキストを高次元の数値ベクトルに変換し、意味の近さを計算できるようにする表現: 温度（Temperature） 説明3: 回答を作る前に社内のナレッジベースを引き、見つかった内容を質問に添えてモデルに渡す手法: 検索拡張生成（RAG）
不正解 ナレッジベースを引く手法を検索拡張生成（RAG）とする対応は正しいものの、残る2つが入れ替わっています。埋め込みの役割はテキストの意味を高次元の数値ベクトルへ写すことであり、出力のランダムさを調整する働きはありません。ランダムさを制御するのは温度で、値が低いほど確率分布が急峻になり、高いほど平坦になります。温度は数値ベクトルによる意味表現ではないため、意味の近さの計算には使えません。
C. 説明1: モデルがテキストを出力する際のランダムさを調整し、回答のばらつきを制御する設定値: 温度（Temperature） 説明2: テキストを高次元の数値ベクトルに変換し、意味の近さを計算できるようにする表現: 埋め込み（Embedding） 説明3: 回答を作る前に社内のナレッジベースを引き、見つかった内容を質問に添えてモデルに渡す手法: 検索拡張生成（RAG）
正解 出力のランダムさを調整するのは温度です。温度は次に選ぶトークンの確率分布の形を変えるパラメータで、値を下げると分布が急峻になって決まりきった回答に、上げると分布が平坦になって多様な回答になります。テキストの意味を高次元の数値ベクトルで表現し、意味の近い語がベクトル空間で近くに並ぶのが埋め込みです。ナレッジベースから見つけた内容を質問へ添えてモデルに渡すのが検索拡張生成（RAG）です。3つの説明と用語が正しく対応しています。
D. 説明1: モデルがテキストを出力する際のランダムさを調整し、回答のばらつきを制御する設定値: 温度（Temperature） 説明2: テキストを高次元の数値ベクトルに変換し、意味の近さを計算できるようにする表現: 検索拡張生成（RAG） 説明3: 回答を作る前に社内のナレッジベースを引き、見つかった内容を質問に添えてモデルに渡す手法: 埋め込み（Embedding）
不正解 出力のランダムさを温度とする対応は正しいものの、残る2つが入れ替わっています。検索拡張生成（RAG）はナレッジベースを引いて見つかった内容をプロンプトに組み込み、回答を事実に基づかせる手法であり、テキストの数値ベクトル表現ではありません。テキストを高次元ベクトルへ変換して意味の近さを計算できるようにするのは埋め込みであり、埋め込み自体がナレッジベースを参照するわけではありません。
E. 説明1: モデルがテキストを出力する際のランダムさを調整し、回答のばらつきを制御する設定値: トークン（Token） 説明2: テキストを高次元の数値ベクトルに変換し、意味の近さを計算できるようにする表現: 埋め込み（Embedding） 説明3: 回答を作る前に社内のナレッジベースを引き、見つかった内容を質問に添えてモデルに渡す手法: 検索拡張生成（RAG）
不正解 埋め込みと検索拡張生成（RAG）の対応は正しいものの、ランダムさに関する対応が誤っています。トークンはモデルが入出力を処理する際の最小のテキスト単位で、文字や単語、単語の一部に相当し、扱えるコンテキストの長さや生成する応答の長さを数える単位として使われます。出力のばらつきを決める設定値ではありません。ランダムさを制御するのは、次に選ぶトークンの確率分布の形を変える温度です。
F. 説明1: モデルがテキストを出力する際のランダムさを調整し、回答のばらつきを制御する設定値: 検索拡張生成（RAG） 説明2: テキストを高次元の数値ベクトルに変換し、意味の近さを計算できるようにする表現: 埋め込み（Embedding） 説明3: 回答を作る前に社内のナレッジベースを引き、見つかった内容を質問に添えてモデルに渡す手法: 温度（Temperature）
不正解 意味の近さを計算できる表現を埋め込みとする対応は正しいものの、残る2つが入れ替わっています。検索拡張生成（RAG）は社内のナレッジベースを参照して見つかった内容を質問に添える手法であり、出力のランダムさを調整する設定値ではありません。ランダムさを制御するのは温度ですが、温度は次のトークンの確率分布の形を変えるだけで、ナレッジベースを引いて回答の根拠を補う働きは持ちません。
全体的な説明
問われている要件
- 生成AIアシスタントの設計で使う用語の役割を理解すること
- テキストの意味表現、出力の制御、外部知識の活用に関する各用語の機能を把握すること
- 用語と説明を正しく対応付けること
前提知識
トークン（Token）について
トークンは、LLMがテキストを分割して処理する際の最小単位です。1つのトークンは、文字や単語、単語の一部を表します。例えば「沖縄2泊3日の旅」というテキストは、処理の際に複数のトークンへ分割されます。モデルが一度に扱えるコンテキストの長さや、生成する応答の長さの上限はトークン数で数えます。Amazon Bedrockでも、応答の長さの上限は返すトークン数を指定する推論パラメータで制御します。
埋め込み（Embedding）について
埋め込みは、テキストの意味を高次元の数値ベクトルで表現する技術です。テキストや画像、音声などのデータを意味を保った数値ベクトルへ変換し、意味の近いデータはベクトル空間の近い位置に配置されます。例えば「温泉」という単語は、「城」や「テーマパーク」といった同じ観光地の単語と近い位置に置かれます。実際の埋め込みは数百〜数千次元のベクトルです。意味の近さを計算できるため、顧客の要望と意味的に近い旅程資料を探す検索に使えます。
検索拡張生成（RAG）について
検索拡張生成（RAG）は、質問への回答を作る前に外部の知識ベースを参照し、見つかった内容をプロンプトに組み込む手法です。まずユーザーの質問に関連する内容を社内の旅程資料や施設情報から見つけ出し、その内容を質問と一緒にLLMへ渡すことで、事実に基づいた回答を生成します。モデルの学習データに含まれていない最新の情報を反映できるため、推測に頼った回答を減らせます。
温度（Temperature）について
温度は、LLMの出力のランダムさを制御する推論パラメータです。内部では次に選ぶトークンの確率分布の形を変えており、低い値は分布を急峻にして確率の高いトークンへ集中させ、高い値は分布を平坦にして確率の低いトークンも選ばれやすくします。その結果、値が高いほど出力は多様で創造的になり、低いほど一貫性が高く予測しやすい出力になります。Amazon Bedrockには温度のほかに、候補として見る上位何個かを決めるTop K、確率の上位何パーセントまでを候補にするかを決めるTop Pといった推論パラメータもあります。施設の営業時間や料金といった事実に基づく回答には低い温度が、旅行プランの文案を考えるような創造的な用途には高い温度が適します。
図による解説
図
意味の近さは、ベクトル空間での座標の近さとして表されます。「犬」「猫」「ペット」といった動物の言葉、「車」「バス」「電車」といった乗り物の言葉、「リンゴ」「バナナ」といった食べ物の言葉が、それぞれカテゴリ内で近い位置に集まり、異なるカテゴリの言葉どうしは離れた位置に配置されています。実際の埋め込みは数百〜数千次元のベクトルですが、ここでは理解しやすいように2次元へ射影しています。同じ性質を使えば、顧客の質問と旅程資料をそれぞれベクトル化して、表現の言い回しが違っても意味の近い資料を見つけ出せます。埋め込みを文字列の一致と混同すると、同義語や言い換えを含む資料を取りこぼし、アシスタントの検索精度が下がります。
図
温度という1つのパラメータが出力候補の確率分布を変え、回答の性格を決めます。低い温度（0.2）では確率が特定の候補に集中し（例では出力1に約7割）、一貫性が高く予測しやすい回答になります。高い温度（0.8）では複数の候補へ確率が分散し、多様な出力が得られます。施設案内や料金確認のように事実を答える用途では低い温度が、旅行のキャッチコピーを考えるような創造的な用途では高い温度が適します。同じモデルでも、設定値ひとつで回答の振れ幅が変わります。常に高い温度で運用すると事実確認の回答までぶれてアシスタントの信頼性が損なわれるため、用途に合わせた調整が必要です。
解くための考え方
トークンはモデルが入出力を処理する際の最小のテキスト単位、埋め込みはテキストの意味を数値ベクトルで表現する技術、検索拡張生成（RAG）は外部の知識を参照して回答の精度を高める手法、温度は出力のランダムさを制御するパラメータです。 説明1の「出力のランダムさを調整し、回答のばらつきを制御する設定値」は温度に、説明2の「テキストを高次元の数値ベクトルに変換し、意味の近さを計算できるようにする表現」は埋め込みに、説明3の「ナレッジベースを引き、見つかった内容を質問に添えてモデルに渡す手法」は検索拡張生成（RAG）に該当します。 したがって、説明1に温度、説明2に埋め込み、説明3に検索拡張生成（RAG）を対応させるのが正解です。
参考資料
問題文：
ある企業が、設備の故障を事前に予測する機械学習モデルをAWSで開発しています。学習データには、設備から収集したテレメトリログ、保守点検の作業履歴、オンプレミスのMySQLデータベースで管理している設備台帳のテーブルが含まれます。テレメトリログと作業履歴はAmazon S3に保存されています。また、故障事例は正常稼働の事例と比べて極端に少なくクラスに不均衡があり、稼働時間や温度などの特徴量の間には相互依存関係もあります。
データサイエンスチームは、複数のソースに散らばったデータを1か所に集めて、学習に使える形に整えたいと考えています。様々なデータソースからデータを集約できるAWSサービスはどれですか。
選択肢：
A. AWS Lake Formationでデータレイクを構築してデータを統合します。
B. Amazon DynamoDBへ各データソースのデータを保存します。
C. Amazon Redshiftへ各データソースのデータをロードし、分析用にまとめます。
D. Amazon Data Firehoseでテレメトリデータをストリーミング配信し、S3へ集約します。
正解：A
A. AWS Lake Formationでデータレイクを構築してデータを統合します。
正解 AWS Lake Formationは、様々なデータソースからデータを集約し、セキュアなデータレイクを構築するマネージドサービスです。ブループリントを使えば、JDBCで接続できるデータベースから全件または差分を取り込む処理を用意でき、S3上のファイルとあわせて1つのデータレイクへまとめられます。ワークフローが生成するAWS Glueのクローラーとジョブがスキーマ検出・カタログ化・変換を担うため、MLモデルの学習に使える統合された形式でデータを提供できます。
B. Amazon DynamoDBへ各データソースのデータを保存します。
不正解 Amazon DynamoDBは、キーによる読み書きを低レイテンシーで処理するNoSQLデータベースです。様々なデータソースからデータを自動的に集約する仕組みは備えておらず、S3のログファイルもオンプレミスのテーブルも、ソースごとに読み出してアイテム単位で書き込む処理を自前で作る必要があります。スキーマ検出やETL、データレイクとしてのメタデータ管理やアクセス制御も提供しないため、複数ソースの統合先には向きません。
C. Amazon Redshiftへ各データソースのデータをロードし、分析用にまとめます。
不正解 Amazon Redshiftは、ペタバイト規模のデータを高速に分析・クエリするデータウェアハウスです。Amazon AuroraやAmazon RDS、Amazon DynamoDBからのゼロETL統合、Amazon S3からの自動コピーといった取り込み手段は備えていますが、対応するソースは限られています。オンプレミスのMySQLの設備台帳やS3上の履歴ファイルを含む多様なソースをまとめて取り込み、スキーマ検出とカタログ化、統一的なアクセス制御まで担うデータレイク構築の機能はないため、ソースごとに抽出・変換の処理を別途用意する必要があります。
D. Amazon Data Firehoseでテレメトリデータをストリーミング配信し、S3へ集約します。
不正解 Amazon Data Firehoseは、ストリーミングデータをAmazon S3やAmazon Redshiftなどの宛先へリアルタイムに配信するフルマネージドサービスです。配信・ロードが役割であり、オンプレミスのMySQLテーブルやS3に保存済みの履歴ファイルなど、種類の異なるデータソースをまとめて取り込み、カタログ化・変換・アクセス制御まで行うデータレイク構築の機能は提供していません。
全体的な説明
問われている要件
- テレメトリログ、作業履歴、MySQLの設備台帳を1か所に集約すること
- 統合したデータをMLモデルの学習に使える形式で保存すること
- データソース間の統合とメタデータ管理を効率化すること
- セキュアなアクセス制御とガバナンスを実現すること
前提知識
AWS Lake Formationについて
様々なデータソースからデータを集約し、セキュアなデータレイクを構築するマネージドサービスです。取り込みにはブループリントとワークフローという仕組みがあり、JDBCで接続できるリレーショナルデータベースを全件取り込むデータベーススナップショット、前回からの差分だけを取り込む増分データベース、CloudTrailやElastic Load Balancingのログを取り込むログファイルの3種類が用意されています。MySQLはJDBC接続の対象で、AWS GlueのJDBC接続にVPCの設定を加えれば、ネットワーク経由で到達できるデータベースから取り込めます。ワークフローはAWS Glueのクローラー・ジョブ・トリガーを生成し、スキーマの自動検出とData Catalogへのメタデータ登録、ETLによる形式の統一までをまとめて実行します。データレイクのきめ細かいアクセス制御やセキュアなデータ共有も実現します。
Amazon Redshiftについて
ペタバイト規模のデータセットを対象に、列指向ストレージと並列処理で複雑なクエリを高速実行するデータウェアハウスです。分析基盤としては優秀で、Amazon AuroraやAmazon RDS、Amazon DynamoDBからのゼロETL統合や、Amazon S3からの自動コピーによる取り込みにも対応しますが、対象となるソースはこれらに限られます。オンプレミスのMySQLやS3上の多様な形式のファイルを含む複数のソースをまとめて取り込み、スキーマの自動検出とカタログ化、統一的なアクセス制御まで担うデータレイク構築の機能は持っていません。データを取り込むには、ソースごとに抽出・変換の処理を個別に用意する必要があります。
Amazon Data Firehoseについて
ストリーミングデータをAmazon S3やAmazon Redshift、Amazon OpenSearch Serviceなどの宛先へリアルタイムに配信するフルマネージドサービスです。逐次入ってくるデータの配信・ロードには向いていますが、オンプレミスのデータベーステーブルやS3に保存済みのファイルといった、性質の異なるデータソースをまとめて取り込み、カタログ化・変換・アクセス制御まで行うデータレイク構築の機能は提供していません。
Amazon DynamoDBについて
高パフォーマンスでスケーラブルなNoSQLデータベースです。アプリケーションのバックエンドデータストアとして使われますが、様々なデータソースからデータを自動的に集約する機能はありません。データを格納するにはソースごとに個別に読み書きする必要があり、データレイクの構築やデータ統合には適していません。
データレイクとデータ統合について
データレイクは、様々な形式とスキーマの大量のデータを保存する集中型のリポジトリです。構造化・半構造化・非構造化のデータをそのまま保管でき、MLモデルの学習や分析に使えます。データ統合は、散在するデータソースからデータを収集し、統合された形式で保存するプロセスで、ソースへの接続、変換、メタデータ管理、アクセス制御が含まれます。
図による解説
アーキテクチャ図
S3とオンプレミスに散らばる3種のデータを、Lake Formationが一元的な入口として集約し、カタログ化・変換・保存まで一気通貫で担います。S3のテレメトリログ・作業履歴と、オンプレミスMySQLの設備台帳が取り込まれ、Glueクローラーがスキーマを自動検出してData Catalogへ登録します。AWS GlueのETLで形式を揃えたデータはS3のデータレイクへ格納され、学習用の統合データセットになります。収集・カタログ化・変換・アクセス制御を1つのサービスに集約すると、データウェアハウスやNoSQLデータベースへソースごとに個別に詰め込む方式と違い、スキーマの一元管理と統一的なガバナンスが効き、学習に使える統合データセットになります。
解くための考え方
Amazon Redshiftはデータウェアハウスであり、大規模データの分析には向いていますが、自動で取り込めるのはゼロETL統合や自動コピーが対応するソースに限られ、オンプレミスのデータベースまで含めて集約する仕組みではありません。Amazon Data Firehoseはストリーミングデータの配信・ロードが役割で、バッチデータやデータベーステーブルの集約は担当外です。Amazon DynamoDBはNoSQLデータベースで、保存先にはなりますが、データを集約する仕組みは持っていません。 一方、AWS Lake Formationは、様々なデータソースからデータを集約してセキュアなデータレイクを構築するマネージドサービスです。S3のデータやオンプレミスのデータベースを取り込み、接続・変換・メタデータ管理・アクセス制御を自動化して、統合されたデータレイクを作成できます。 したがって、様々なデータソースからデータを集約できるAWSサービスは、AWS Lake Formationです。
参考資料
問題文：
ある企業が、設備に取り付けたセンサーから送られる振動や温度などのデータをAmazon S3に集約し、設備不具合の兆候を早期に捉えようとしています。各設備のセンサーは毎分値を送信しており、1日あたり数百万件の時系列データが蓄積されます。これまで保全担当者は固定のしきい値でデータを目視確認してきましたが、想定外の設備停止が相次ぎ、この方法では分布の揺らぎに伴う異常の予兆を取りこぼしてしまいます。
そこで同社は、蓄積済みの時系列データから異常を自動的に検出し、その結果を可視化する仕組みを、運用の手間を増やさずに導入したいと考えています。この要件を満たすソリューションはどれですか。
選択肢：
A. AWS GlueのETLジョブとして異常検出のロジックを実装し、Amazon QuickSightのダッシュボードで結果を表示します。
B. Amazon EMRのクラスター上で異常検出のロジックを実装し、Amazon QuickSightで結果を可視化します。
C. Amazon Data Firehoseでセンサーの時系列データをS3へ配信して蓄積し、そこから異常を抽出して結果を可視化します。
D. Amazon SageMaker Data Wranglerで時系列データの外れ値を自動判定し、結果をグラフで確認します。
正解：D
A. AWS GlueのETLジョブとして異常検出のロジックを実装し、Amazon QuickSightのダッシュボードで結果を表示します。
不正解 AWS Glueはデータの抽出・変換・ロードを担うサーバーレスのETLサービスで、データの変換や整形に向いています。AWS Glue Data Qualityには統計値の推移から異常を見つける異常検出がありますが、対象は行数や列の統計といったデータ品質のメトリクスであり、センサーの計測値そのものから設備異常の予兆を判定する機能ではありません。設備の異常判定はジョブの中に自ら記述する必要があり、可視化もQuickSightを別途組み合わせて実現するため、実装と管理の両面で運用の負担が増えます。
B. Amazon EMRのクラスター上で異常検出のロジックを実装し、Amazon QuickSightで結果を可視化します。
不正解 Amazon EMRはHadoopやSparkなどの分散処理フレームワークを実行するマネージドクラスタープラットフォームで、大規模なバッチ処理の実行には適していますが、異常検出の組み込み機能はありません。異常を判定するロジックを自前で実装してクラスター上で動かす必要があり、開発と運用の両面で大きな手間が発生します。
C. Amazon Data Firehoseでセンサーの時系列データをS3へ配信して蓄積し、そこから異常を抽出して結果を可視化します。
不正解 Amazon Data Firehoseは、ストリーミングデータをAmazon S3やRedshiftなどの宛先へリアルタイムで配信するフルマネージドサービスです。データを転送・蓄積することはできますが、異常を自動で検出する機能も結果をグラフ化する機能も備えていません。検出ロジックと可視化ツールを別途組み立てる必要があり、要件を効率的に満たせません。
D. Amazon SageMaker Data Wranglerで時系列データの外れ値を自動判定し、結果をグラフで確認します。
正解 Amazon SageMaker Data Wranglerは、データの前処理、特徴量エンジニアリング、分析、可視化を統合的に提供するサービスです。時系列データの異常検出機能を備えており、傾向・季節性・残差に分解したうえで外れ値を自動判定できます。検出結果はグラフで確認でき、処理結果はSageMakerの他の機能やS3へ直接出力できます。
全体的な説明
問われている要件
- 蓄積済みの時系列データから異常を自動的に検出すること
- 検出した結果を可視化すること
- 異常検出と可視化を統合して運用の手間を抑えること
前提知識
Amazon SageMaker Data Wranglerについて
Amazon SageMaker Data Wranglerは、データの前処理、特徴量エンジニアリング、分析、可視化を統合的に実行できるサービスです。視覚的なインターフェースでデータフローを構築でき、多数の組み込み変換を提供しています。分析機能のひとつに時系列データの異常検出があり、傾向と季節性からなる予測項と残差からなる誤差項に時系列を分解し、残差が平均から指定した標準偏差の数を超えた値を異常として自動判定できます。なお、分析はデータセットのサンプル（10万行）に対して生成されます。検出結果はグラフとして表示でき、処理済みのデータはSageMakerの他の機能やS3へ直接出力できます。Data WranglerはAmazon SageMaker Canvasに統合されており、SageMaker Canvasのデータ準備機能として同じデータフローと分析を利用できます。
Amazon Data Firehoseについて
Amazon Data Firehoseは、ストリーミングデータをAmazon S3やRedshiftなどの宛先へリアルタイムで配信するフルマネージドサービスです。センサーデータを途切れなく転送して蓄積することには向いていますが、異常検出の組み込み機能も可視化機能も備えていません。異常検出と可視化を実現するには、判定ロジックと可視化ツールを別途用意して組み合わせる必要があり、運用の手間が大きくなります。
AWS Glueについて
AWS Glueは、データの抽出・変換・ロード（ETL）を実行するサーバーレスのマネージドサービスです。PythonやScalaで変換ロジックを実装できます。AWS Glue Data Qualityには、過去の統計値の推移を学習して行数や列の統計の異常を検出する機能がありますが、これはデータ品質を監視するためのもので、センサーの計測値から設備異常の予兆を判定する用途の機能ではありません。設備の異常を検出するには判定ロジックをジョブとしてコーディングし、可視化用のQuickSightを別途組み合わせる必要があり、複数サービスの管理と実装の手間が増えます。
Amazon EMRについて
Amazon EMRは、HadoopやSparkなどの分散処理フレームワークを実行するためのマネージドクラスタープラットフォームです。異常検出の組み込み機能はなく、判定ロジックを自前で実装してクラスター上で動かす必要があります。この方法は開発と運用の両面で大きな手間が発生し、要件を効率的に満たせません。
異常検出と可視化の統合について
異常検出と可視化を統合的に実行するには、前処理、検出、可視化の各ステップを一元的に管理できる専用のサービスを使うのが効率的です。複数のサービスを組み合わせると、サービス間の連携やデータの受け渡し、ロジックの自前実装が必要になり、運用の手間が増えます。
図による解説
図
固定のしきい値で異常を判断するのではなく、正常なデータの分布そのものを判定の基準に置きます。設備の振動と温度は通常運転では狭い範囲に集まり、青い点のような正常値の群れを形成します。赤い点はその群れから大きく外れた異常値で、振動と温度のいずれか一方、あるいは両方が通常の範囲から逸脱した位置に現れます。Data Wranglerの異常検出は時系列を傾向・季節性・残差に分解し、残差が平均から設定した標準偏差の数を超えた値を外れ値として自動判定し、結果をグラフで示します。固定しきい値の目視では分布の揺らぎに伴う逸脱を見落としやすく、データの配信・蓄積やETL・バッチ処理に判定ロジックを自前で実装するやり方では運用の手間が増します。
解くための考え方
Amazon SageMaker Data Wranglerは、異常検出と可視化の機能を統合的に提供します。時系列データを傾向・季節性・残差に分解して外れ値を自動判定できるため、判定ロジックを自前で実装する必要がありません。検出結果はグラフとしてその場で確認でき、SageMakerの他の機能とも連携します。 一方、Amazon Data Firehoseはデータの配信・蓄積を担うだけで、異常検出も可視化も備えていません。AWS GlueやAmazon EMRにQuickSightを組み合わせる方法も、異常判定のロジックを自前で実装し、複数のサービスを管理する手間がかかります。 したがって、異常検出と可視化を自前ロジックなしで済ませるなら、Amazon SageMaker Data Wranglerを使います。
参考資料
問題文：
ある企業が、新規商品の価格を推定するモデルを開発しています。学習データには、地域やカテゴリ、グレードといったカテゴリカルデータと、数量や経過年数、距離といった数値データが混在しています。多くの機械学習アルゴリズムは数値の入力を前提としており、カテゴリカルデータはそのままではモデルに正しく反映できません。
そこでデータサイエンスチームは、カテゴリカルデータを数値データへ変換してモデルの精度を最大化したいと考えており、毎月数百万件にのぼる商品レコードをできるだけ手間をかけずに前処理する方法を探しています。最小限の運用オーバーヘッドでこの要件を満たすには、どのアクションが適切ですか。
選択肢：
A. SQLを自前で書き、カテゴリカル列を数値へ置き換える処理をAmazon Athenaで実行します。
B. Amazon SageMaker Data Wranglerの既製変換を使って、数値列をカテゴリカル列へ作り替えてからモデルに与えます。
C. 数値列を区間に区切るSQLをAmazon Athenaで組み、数値をカテゴリカル列へ落とし込みます。
D. カテゴリカル列を数値列へ置き換える工程を、コードを書かずにAmazon SageMaker Data Wranglerで組み立てます。
正解：D
A. SQLを自前で書き、カテゴリカル列を数値へ置き換える処理をAmazon Athenaで実行します。
不正解 Amazon Athenaは、Amazon S3上のデータを標準SQLで分析する対話型クエリサービスです。カテゴリカルデータを数値へ変換する既製の機能はなく、ワンホットエンコーディングなどをSQLで一から記述する必要があります。変換結果をその場で確かめる可視化の手段もなく、毎月数百万件のレコードへ適用するにはSQLの保守や実行管理まで自前で抱えるため、開発と運用の負担が大きくなります。
B. Amazon SageMaker Data Wranglerの既製変換を使って、数値列をカテゴリカル列へ作り替えてからモデルに与えます。
不正解 モデルの精度を最大化するには、ふつうカテゴリカルデータを数値データへ変換します。数値をカテゴリカルへ変換しても精度は上がらず、むしろ下がりかねません。多くのアルゴリズムは数値の方が効率よく処理できるため、カテゴリカルから数値への変換が標準的な手順です。変換の向きを逆にしても、今回の要件は満たせません。
C. 数値列を区間に区切るSQLをAmazon Athenaで組み、数値をカテゴリカル列へ落とし込みます。
不正解 モデルの精度を最大化するには、ふつうカテゴリカルデータを数値データへ変換します。数値をカテゴリカルへ変換しても精度は上がらず、むしろ下がりかねません。細かな差を潰してしまい、学習に使える情報が粗くなるためです。加えて、Amazon Athenaで変換する場合はSQLを自前で書く手間が伴います。
D. カテゴリカル列を数値列へ置き換える工程を、コードを書かずにAmazon SageMaker Data Wranglerで組み立てます。
正解 Amazon SageMaker Data Wranglerは、前処理と特徴量エンジニアリングを視覚的なインターフェースで進められるサービスです。カテゴリカルデータを数値へ変換する既製の機能を備え、ワンホットエンコーディングや序数エンコーディングなどを手軽に適用できます。変換結果をすぐに確認できるため運用の手間が小さく、SageMakerのほかの機能とも連携します。
全体的な説明
問われている要件
- カテゴリカルデータと数値データが混在する学習データを準備すること
- モデルの精度を最大化すること
- 最小限の運用オーバーヘッドで実現すること
- データ変換を効率的に実行すること
前提知識
カテゴリカルデータと数値データの変換について
機械学習モデルの多くは、数値データを直接処理できるように設計されています。カテゴリカルデータ（地域、カテゴリ、グレードなど）は、そのままではモデルが処理できないため、数値データへ変換する必要があります。主な変換手法には、ワンホットエンコーディング（各カテゴリを0または1の値を持つ新しい列へ変換）、序数エンコーディング（各カテゴリを0から始まる整数値へ割り当て）、ターゲットエンコーディング（カテゴリごとの目的変数の平均値を使用）などがあります。適切に変換することで、モデルの精度を向上させられます。
Amazon SageMaker Data Wranglerについて
Amazon SageMaker Data Wranglerは、データの前処理、特徴量エンジニアリング、可視化を統合的に実行できるサービスです。視覚的なインターフェースでデータフローを構築でき、多数の組み込み変換を提供しています。カテゴリカルデータを数値データへ変換する組み込み機能を備えており、ワンホットエンコーディングや序数エンコーディングなどの手法を簡単に適用できます。変換結果を即座に確認でき、SageMakerの他の機能と統合されています。現在はAmazon SageMaker Canvasに統合され、Canvas上のData Wranglerエクスペリエンスとして、視覚的なインターフェースに加えて自然言語による指示でもデータの探索と変換を行えます。カテゴリカルエンコードの組み込み変換としては、序数エンコード、ワンホットエンコード、類似度エンコードが用意されています。
Amazon Athenaについて
Amazon Athenaは、Amazon S3内のデータに対して標準SQLで分析するサーバーレスの対話型クエリサービスです。カテゴリカルデータを数値データへ変換する組み込み機能はなく、ワンホットエンコーディングなどの変換はCASE式や数式を使ってSQLで自前で記述する必要があります。変換結果をその場で確認する可視化の仕組みもなく、運用の手間が大きくなります。
データ前処理の運用オーバーヘッドについて
運用オーバーヘッドとは、システムを動かし続けるために必要な手作業や管理作業の量を指します。視覚的なインターフェースで変換を実行できるサービスを使えば、コーディング作業を減らし、変換結果を即座に確認できるため、運用の手間を削減できます。一方、変換ロジックを手動で実装する必要がある場合は、開発と運用の両面で大きな手間が発生します。
図による解説
図
モデルが直接扱えないカテゴリカル特徴量は、情報を変えずに数値の列へ置き換えます。変換前は「カテゴリ」という1列だったものが、ワンホットエンコーディングでは「カテゴリ_タイプA」などの列へ展開され、該当するカテゴリの列だけが1、それ以外は0になります。サンプル1がタイプA、サンプル2がタイプB、サンプル3がタイプCというように、各行の属性が0と1の行列として表現されます。序数エンコーディングのように各カテゴリを整数へ割り当てる手法もありますが、いずれも変換の方向はカテゴリカルから数値へです。逆に数値をカテゴリカルへ変換しても精度は上がらず、手書きのSQLで毎回実装すれば運用の負担も増します。
図
序数（ラベル）エンコーディングは、各カテゴリに整数を1つずつ割り当て、列を1本のまま数値へ置き換える手法です。列が増えないためメモリ効率は高くなります。ただし、タイプA が0、タイプB が1、タイプC が2という値は、モデルからは「タイプC はタイプA の2倍」「タイプB はその中間」という大小関係に見えます。順序に意味のないカテゴリにこの手法を使うと、存在しない順序をモデルに学習させてしまうため、その場合はワンホットエンコーディングを選びます。どちらの手法でも、変換の方向はカテゴリカルから数値へです。
解くための考え方
機械学習モデルの精度を最大化するには、通常はカテゴリカルデータを数値データへ変換します。モデルのアルゴリズムは数値データの方が効率的に処理できるため、カテゴリカルから数値への変換が一般的な手順です。数値データをカテゴリカルデータへ変換しても精度は上がらず、むしろ下がる恐れがあります。 Amazon SageMaker Data Wranglerは、カテゴリカルデータを数値データへ変換する組み込み機能を備えており、ワンホットエンコーディングや序数エンコーディングなどを簡単に適用できます。視覚的なインターフェースで変換を実行でき、結果を即座に確認できるため、運用の手間が小さく済みます。 一方、Amazon Athenaを使う方法は、ワンホットエンコーディングなどの変換をSQLで自前で記述する必要があり、変換結果の確認手段も自前で用意しなければなりません。この方法は運用の手間が大きく、要件を効率的に満たせません。 したがって、カテゴリカルから数値への変換を手書きSQLなしで行うなら、Amazon SageMaker Data Wranglerを使います。
参考資料
問題文：
ある企業が、各工程で計測したセンサーデータをAmazon S3に集約し、出荷前に不良ロットを予測するモデルを開発しています。毎日数百万件の検査記録が発生しますが、不良ロットは全体の数%にすぎず、不良（少数クラス）の学習データが良品（多数クラス）に比べて極端に少ないクラス不均衡が生じています。このまま学習を進めるとモデルは多数派の良品に偏り、不良をうまく予測できません。
そこで品質管理部は、モデルの学習を始める前にこのクラス不均衡を解消したいと考えています。最小限の運用努力でこの要件を満たすには、どのソリューションが適切ですか。
選択肢：
A. Amazon SageMaker AIの組み込みアルゴリズムで不均衡なデータセットをそのまま学習します。
B. AWS Glue DataBrewのクリーニング・正規化機能で少数クラスのオーバーサンプリングを行います。
C. Amazon SageMaker Data Wranglerのバランスデータ操作で少数クラスを増やして比率を揃えます。
D. Amazon QuickSightで不良ロットの分布を可視化して分析し、不均衡の状況を把握します。
正解：C
A. Amazon SageMaker AIの組み込みアルゴリズムで不均衡なデータセットをそのまま学習します。
不正解 Amazon SageMaker AIの組み込みアルゴリズムは、与えられたデータでモデルを学習するためのものであり、クラス不均衡を解消する前処理の機能は持ちません。不均衡は学習の前にデータを加工して解消すべき問題であり、アルゴリズムにそのまま渡しても少数クラスが増えるわけではなく、多数派への偏りは残ります。
B. AWS Glue DataBrewのクリーニング・正規化機能で少数クラスのオーバーサンプリングを行います。
不正解 AWS Glue DataBrewは、欠損値の処理や形式の統一など、データのクリーニングと正規化を視覚的に行うサービスです。多数のレシピアクションを備えますが、クラス不均衡を解消するオーバーサンプリングの機能はありません。少数クラスを増やして比率を揃えることはできず、データの品質向上には向いていても不均衡の解消には役立ちません。
C. Amazon SageMaker Data Wranglerのバランスデータ操作で少数クラスを増やして比率を揃えます。
正解 Amazon SageMaker Data Wranglerは、クラス不均衡を解消するためのバランスデータ操作を提供しています。この操作で少数クラスをオーバーサンプリングし、クラス間の比率を揃えられます。視覚的なインターフェースで設定を調整でき、SMOTEやランダムオーバーサンプリングなどの手法を選べるため、運用の手間が小さく済みます。作成した処理フローはそのままSageMaker AIの処理ジョブやパイプラインへエクスポートできます。
D. Amazon QuickSightで不良ロットの分布を可視化して分析し、不均衡の状況を把握します。
不正解 Amazon QuickSightは、データをグラフやダッシュボードで可視化して分析するビジネスインテリジェンス（BI）サービスです。不良の分布を把握することはできますが、クラス不均衡を解消するオーバーサンプリング機能は備えていません。可視化や分析を行うだけでは少数クラスは増えず、不均衡はそのまま残ります。
全体的な説明
問われている要件
- クラス不均衡の問題を解消すること
- モデルの学習を始める前にデータセットを調整すること
- 最小限の運用努力で実現すること
- 少数クラスを適切に処理すること
前提知識
クラス不均衡について
クラス不均衡とは、データセット内のクラスの分布が偏っている状態を指します。不良ロット予測のように、少数派のクラスが多数派に比べて極端に少ない場合に発生します。クラス不均衡が生じると、モデルは多数派に偏って学習し、少数派のクラスを適切に予測できなくなります。解消する主な手法には、オーバーサンプリング（少数クラスのサンプルを増やす）、アンダーサンプリング（多数クラスのサンプルを減らす）、合成サンプルの生成（SMOTEなど）があります。
Amazon SageMaker Data Wranglerについて
Amazon SageMaker Data Wranglerは、データの前処理、特徴量エンジニアリング、データバランシングを統合的に実行できるサービスです。クラス不均衡を解消するバランスデータ操作を提供しており、少数クラスをオーバーサンプリングしてクラス間の比率を揃えられます。視覚的なインターフェースで設定を調整でき、オペレータとしてランダムオーバーサンプリング、ランダムアンダーサンプリング、合成マイノリティオーバーサンプリング手法（SMOTE）を選択できます。SMOTEは数値特徴量の距離をもとに合成サンプルを内挿する手法で、列ベクトルを含むデータセットにはバランスデータ操作を適用できないという制約があります。現在このデータ準備機能はAmazon SageMaker Canvasに統合されており、Canvas上のData Wranglerとしてバランスデータ操作を含む変換を利用します。
Amazon QuickSightについて
Amazon QuickSightは、データをグラフやダッシュボードで可視化して分析するビジネスインテリジェンス（BI）サービスです。不良ロットと良品ロットの分布を可視化して状況を把握することはできますが、クラス不均衡を解消するオーバーサンプリング機能は備えていません。可視化や分析はあくまで現状把握のためのもので、少数クラスを増やして比率を揃える前処理ではありません。
Amazon SageMaker AIの組み込みアルゴリズムについて
Amazon SageMaker AIの組み込みアルゴリズムは、XGBoostや線形学習者（Linear Learner）など、代表的な機械学習タスク向けに最適化された実装をあらかじめ用意したものです。学習データを指定するだけでモデルを作成できますが、データそのものの不均衡を解消する前処理機能は提供していません。なお、組み込みのXGBoostには正例と負例の重みのバランスを制御するscale_pos_weightハイパーパラメータがあり、学習時の重み付けで不均衡に対処する余地はありますが、これはデータセットの比率を揃える前処理ではありません。学習前にデータ側で不均衡を解消したいという要件には、データ準備段階の機能が必要です。
AWS Glue DataBrewについて
AWS Glue DataBrewは、データのクリーニングと正規化を視覚的なインターフェースで実行するサービスです。欠損値の処理や形式の統一などに適していますが、クラス不均衡を解消するオーバーサンプリング機能はありません。データの品質向上や特徴量の作成には向いていますが、少数クラスを増やす専用の機能は提供していません。
図による解説
図
クラス不均衡の解消はモデル学習の前に行うデータ準備であり、専用のバランス機能によって初めて手間なく実現できます。変換前は少数クラス（不良ロット）が100件、多数クラス（良品ロット）が500件と大きく偏っており、このまま学習するとモデルは多数派の良品に寄って不良を見逃します。オーバーサンプリングでは少数クラスのサンプルを複製して500件へ増やし、クラス間の比率を揃えることで、モデルが少数派のパターンも学習できるようにします。可視化ツールで分布を眺めたり、学習アルゴリズムをそのまま使ったりしても少数クラスは自動的には増えません。比率の調整を手作業で行う運用は再現性に欠け、再実行や監査の面でも負担になります。
解くための考え方
少数クラスが極端に少ないまま学習すると、モデルは多数派に寄って不良を見逃します。少数クラスのオーバーサンプリングか、多数クラスのアンダーサンプリングで比率を揃えます。オーバーサンプリングは、少数クラスのサンプルを増やしてクラス間の比率を揃える手法です。 Amazon SageMaker Data Wranglerは、クラス不均衡を解消するバランスデータ操作を提供しています。少数クラスをオーバーサンプリングして比率を揃えられ、視覚的なインターフェースで設定を調整でき、SMOTEやランダムオーバーサンプリングなどの手法も選べるため、運用の手間が小さく済みます。 一方、Amazon QuickSightで分布を可視化・分析する方法は、状況の把握にはなってもクラス不均衡そのものは解消されません。SageMaker AIの組み込みアルゴリズムは前処理機能を持たず、AWS Glue DataBrewもオーバーサンプリング機能を提供していません。 したがって、学習前に少数クラスを手間なく増やすなら、Amazon SageMaker Data Wranglerのバランスデータ操作でオーバーサンプリングします。
参考資料
スポンサーリンク
以下スポンサーリンクです。
この記事がお役に立ちましたら、コーヒー1杯分（300円）の応援をいただけると嬉しいです。いただいた支援は、より良い記事作成のための時間確保や情報収集に活用させていただきます。