MLA-C01 Vol1｜データ準備・特徴量エンジニアリング【D1ドメイン112問対策】

1. はじめに — D1「データ準備・特徴量エンジニアリング」とは

本記事は「AWS MLA-C01試験対策」シリーズの Vol1 です。
まだ全体像をつかんでいない方は、4ドメインの俯瞰とサービスマップを解説した Vol0 ロードマップ を先にお読みください。

ここから扱うのは試験の第1ドメイン、D1「データ準備（Data Preparation）」 です。
公式試験ガイドにおける出題比率は 28% で、65問換算なら約18問、4ドメインのなかで 最大の比重 を占めます。
機械学習（ML）の世界には「Garbage In, Garbage Out（ゴミを入れればゴミが出る）」という言葉があります。
どれほど高度なアルゴリズムを使っても、入力データの質が悪ければ良いモデルは生まれません。
だからこそ AWS は、データをどう取り込み・整形し・特徴量へ変換するかという D1 を最重視しているのです。

1-1. D1の出題範囲を一望する

D1 は範囲が広く、初学者がもっとも迷子になりやすいドメインです。
しかし問われるテーマは大きく次の6つに整理できます。
本記事はこの6テーマを順番に解説していきます。

2. データ準備パイプラインの全体像

個々のサービスを学ぶ前に、まず「データがどこを通ってモデルに届くのか」という流れを頭に入れましょう。
全体像が見えていれば、各サービスが「パイプラインのどの工程を担うのか」を見失わずに済みます。

典型的なMLデータパイプラインは、おおむね次の5工程で構成されます。

1. 取込（Ingestion） — データベース・ログ・IoT・外部APIなどから生データを集めます。バッチ転送なら AWS Glue や DMS、リアルタイムなら Kinesis を使います。
2. 蓄積（Storage） — 集めたデータを Amazon S3 を中心としたデータレイクに貯めます。ここで列指向フォーマット（Parquet）に変換しておくと後工程が速くなります。
3. 変換（Transform / ETL） — Glue や Athena で結合・集計・クレンジングを行い、分析しやすい形に整えます。
4. 特徴量化（Feature Engineering） — SageMaker Data Wrangler で欠損値補完やエンコーディングを行い、再利用可能な特徴量を SageMaker Feature Store に登録します。
5. 学習へ供給（Serving to Training） — 整った特徴量を SageMaker Training ジョブへ渡し、モデル学習を始めます。

この5工程は ML ワークフローの「最初の半分」にあたり、D1 の出題はすべてこのどこかに位置づけられます。
以降の章では工程順に各サービスを掘り下げます。

2-1. バッチ処理とストリーミング処理の使い分け

D1 を貫く重要な対比軸が 「バッチ」か「ストリーミング」か です。
両者は取り込むデータの性質によって選び分けます。

• バッチ処理 — 一定量・一定間隔でまとめて処理する方式。日次の売上集計や過去ログの一括変換など、リアルタイム性が不要な場面に向きます。Glue や Athena が担います。
• ストリーミング処理 — 発生したデータを途切れなく即座に処理する方式。IoTセンサー、クリックストリーム、不正検知のように 鮮度が価値を持つ 場面に向きます。Kinesis や MSK が担います。

設問では「リアルタイムに」「数秒以内に」といった表現があればストリーミング、「日次で」「定期的に」とあればバッチ、と読み解くのがコツです。

3. データ形式と最適なストレージ選択

3-1. なぜ S3 がMLデータの中心なのか

Amazon S3（Simple Storage Service）は、容量無制限・高耐久（99.999999999%）のオブジェクトストレージで、AWS における データレイクの標準基盤 です。
SageMaker をはじめ Glue・Athena・Kinesis のほとんどが S3 を入出力先として扱うため、「MLデータはまず S3 に置く」が鉄則になります。

3-2. Parquet・ORC vs CSV/JSON — 列指向の威力

D1 で最頻出の論点が ファイル形式の選択 です。
ここで鍵になるのが「行指向」と「列指向」の違いです。

• 行指向（CSV / JSON） — 1レコードを横一列に並べて保存します。人間に読みやすく、書き込みが簡単ですが、特定の列だけを読みたいときも全行を走査するため非効率です。
• 列指向（Parquet / ORC） — 同じ列の値をまとめて保存します。「年齢の平均」のように一部の列だけ集計する分析クエリで、必要な列だけを読めるため高速かつ低コストです。

Parquet と ORC はどちらも列指向で、試験では「列指向フォーマット」としてほぼ同等に扱われます。
細かな違いより「行指向（CSV）→ 列指向（Parquet/ORC）へ変換するとクエリが速くなる」という構図を押さえましょう。

3-3. パーティショニングと圧縮

S3 のデータは、s3://bucket/year=2026/month=06/day=16/ のように パーティション を切っておくと、Athena が不要なパーティションを読み飛ばせます（パーティションプルーニング）。
さらに Snappy（高速）や GZIP（高圧縮）で圧縮すれば、ストレージ料金とスキャン量の両方を抑えられます。
「日付でパーティション + Parquet + Snappy」はML向けデータレイクの定番構成です。

4. ETL・データパイプライン — Glue・Athena・Lake Formation

S3 にデータが貯まったら、次は分析・学習しやすい形に整える ETL（Extract / Transform / Load） です。
D1 では Glue・Athena・Lake Formation の役割分担が頻出します。

4-1. AWS Glue — サーバーレスETLの主役

AWS Glue は、サーバーを管理せずに ETL を実行できるフルマネージドサービスです。
試験では次の3つの構成要素を区別できることが重要です。

さらに Glue DataBrew は、コードを書かずにGUIで250種類以上の変換を適用できる ノーコードのデータ準備ツール です。
「プログラミング不要でデータクレンジングしたい」というシナリオでは DataBrew が正解になります。

もう一つ覚えておきたいのが Glue ジョブブックマーク（Job Bookmark） です。
これは前回までに処理した位置を記憶し、新しく追加されたデータだけを差分処理（増分処理） する機能です。
「毎日追加されるログを重複なく ETL したい」という増分パイプラインのシナリオで頻出します。

4-2. Amazon Athena — S3を直接SQLで照会

Amazon Athena は、S3 上のデータに対して サーバーレスで標準SQL を実行できるサービスです。
事前にデータベースへロードする必要がなく、Glue Data Catalog のスキーマを使って S3 を直接クエリします。
課金は スキャンしたデータ量 に対して発生するため、前述の Parquet 化・パーティショニングがそのままコスト削減に直結します。

4-3. AWS Lake Formation — データレイクの権限統制

AWS Lake Formation は、データレイクの構築と きめ細かなアクセス制御 を担うサービスです。
「特定の列（例: 給与）を一部のユーザーにだけ隠す」「行レベルでアクセスを制限する」といった、IAM だけでは難しい テーブル/列/行レベルの権限管理 を実現します。
「データレイクで列単位のアクセス制御をしたい」と問われたら Lake Formation です。

5. ストリーミングデータ取込 — Kinesis・MSK

バッチ処理だけでなく、IoTセンサーやクリックストリームのように 絶え間なく流れてくるデータ をリアルタイムに取り込む場面も出題されます。
ここで主役になるのが Amazon Kinesis ファミリーと Amazon MSK です。

5-1. Kinesis 三兄弟の使い分け

Kinesis には用途の異なる3サービスがあり、その違いが頻出します。

判断の軸はシンプルです。
「とにかくS3へ確実にロードしたい」なら Firehose、「低レイテンシで自前処理したい」なら Data Streams、「ストリームを集計・分析したい」なら Flink です。
「最小の運用でストリーミングデータを Parquet 形式で S3 に保存したい」という典型シナリオでは、形式変換とバッファリングを自動で行う Firehose が正解になります。

5-2. Amazon MSK — Kafka 互換が必要なとき

Amazon MSK（Managed Streaming for Apache Kafka）は、OSS の Apache Kafka をフルマネージドで提供するサービスです。
「既存システムが Kafka を使っている」「Kafka のエコシステム（Kafka Connect等）を活かしたい」という場合に選択します。
新規でAWSネイティブに組むなら Kinesis、Kafka資産があるなら MSK、という整理で十分です。

6. 特徴量エンジニアリング — Data Wrangler と Feature Store

データが整ったら、いよいよモデルが学習しやすい 特徴量（feature） に変換します。
特徴量エンジニアリングとは、生データをモデルの精度が上がる形へ加工する工程の総称です。

6-1. SageMaker Data Wrangler — 前処理の統合環境

SageMaker Data Wrangler は、SageMaker Studio 上で データの取込・可視化・前処理・特徴量化をGUI中心で行える ツールです。
300種類以上の組み込み変換を持ち、欠損値補完・エンコーディング・スケーリングをコードほぼ無しで適用できます。
作成した処理フローはそのまま SageMaker Processing ジョブや Pipeline に組み込めるため、「試行錯誤した前処理を本番パイプラインへ展開する」流れがスムーズです。

6-2. SageMaker Feature Store — 特徴量の一元管理

SageMaker Feature Store は、作成した特徴量を 保存・共有・再利用 するための専用ストアです。
試験では2つのストアの違いが重要です。

Feature Store の最大の価値は 「学習時と推論時で同じ特徴量計算ロジックを使える」 ことです。
これにより、学習では正規化していたのに推論では忘れた、といった 学習/推論スキュー（training-serving skew） を防げます。
「複数チームで特徴量を共有・再利用したい」「学習と推論の特徴量の一貫性を保ちたい」というシナリオでは Feature Store が答えになります。

7. 前処理テクニック — 欠損値・外れ値・エンコーディング・スケーリング

ここからは、特徴量エンジニアリングの中核となる 具体的な前処理手法 を整理します。
試験では「このデータにはどの処理が適切か」という判断が問われます。

7-1. 欠損値（Missing Values）の扱い

データに空欄があると多くのアルゴリズムは学習できません。対処は主に次の通りです。

• 削除 — 欠損が少なく、その行/列を捨てても情報損失が小さい場合。
• 補完（Imputation） — 平均値・中央値・最頻値で埋める基本手法。数値は中央値、カテゴリは最頻値が定番です。
• モデルによる予測補完 — KNN などで他の特徴量から欠損値を推定する高度な手法。

7-2. 外れ値（Outliers）の扱い

極端に大きい/小さい値はモデルを歪めます。
箱ひげ図やIQR（四分位範囲）、Zスコアで検出し、除去 するか クリッピング（上限・下限で頭打ち） します。
ただし「異常検知」が目的の場合、外れ値こそが価値ある情報なので安易に消してはいけません。目的に応じた判断が問われます。

7-3. カテゴリ変数のエンコーディング

「赤・青・緑」のような文字カテゴリは、数値に変換しないとモデルが扱えません。

One-Hot は分かりやすい反面、カテゴリ数の多いデータでは列が爆発します。その場合は Target Encoding などを検討します。

7-4. スケーリング（特徴量の尺度合わせ）

「年齢（0〜100）」と「年収（0〜1000万）」のように 桁が違う特徴量 をそのまま使うと、距離ベースのアルゴリズム（KNN・SVM）や勾配降下法が大きい値に引きずられます。

• 標準化（Standardization） — 平均0・標準偏差1に変換。外れ値に比較的頑健で、汎用的に使われます。
• 正規化（Normalization / Min-Maxスケーリング） — 0〜1の範囲に収める。値の範囲を揃えたいときに使います。

なお決定木系（XGBoost・ランダムフォレスト）はスケールの影響を受けにくいため、スケーリング不要という点も覚えておくと得点源になります。

8. データ不均衡への対処

不正検知や疾病診断のように、陽性データが極端に少ない タスクでは、何もしないとモデルが多数派ばかり予測してしまいます。
（例: 99%が正常な取引データでは、全件「正常」と答えるだけで正解率99%になってしまい、肝心の不正を見逃します。）
この クラス不均衡（class imbalance） への対処は D1 の頻出論点です。

主な対処法は次の4つです。

9. データラベリング — Ground Truth

教師あり学習には「正解ラベル」が必要ですが、大量データへの手作業ラベル付けは大きなコストです。
ここで使うのが Amazon SageMaker Ground Truth です。

• SageMaker Ground Truth — 人間（自社・Mechanical Turk・外部ベンダー）によるラベリングを管理するサービス。自動ラベリング（active learning） 機能で、機械が確信できるデータは自動分類し、難しいものだけ人間に回すことでコストを削減できます。
• Ground Truth Plus — ラベリング作業そのものを AWS の専門チームに丸ごと委託 できるマネージドサービス。自前でワーカーを管理したくない場合に選びます。

「ラベリングコストを抑えつつ品質を保ちたい」なら自動ラベリング付きの Ground Truth、「運用ごと任せたい」なら Ground Truth Plus、という使い分けです。

10. データのプライバシー — PII検出と保護

最後は、個人情報（PII: Personally Identifiable Information）の取り扱いです。
氏名・住所・クレジットカード番号などをそのまま学習データに含めると、コンプライアンス違反や情報漏えいのリスクになります。

「S3に保存された大量データからPIIの場所を発見したい」なら Macie、「テキスト本文からPIIを検出・除去したい」なら Comprehend が答えになります。
検出後は、暗号化（KMS）・マスキング・トークン化で保護するのが基本方針です。

11. まとめ — Vol2「モデル開発」へ

本記事では、MLA-C01 の最大ドメイン D1「データ準備・特徴量エンジニアリング」を、パイプラインの流れに沿って体系的に整理しました。

データという土台が整えば、次はいよいよモデルを「作り・測り・改善する」工程です。
Vol2「モデル開発・評価・チューニング」（D2/26%・公開中） では、SageMaker 組み込みアルゴリズムの選択、自動モデルチューニング（AMT）、評価指標、Clarify によるバイアス検出を解説します。

知識をインプットしたら、必ず問題演習でアウトプットしましょう。
CertTrend LMS には MLA-C01 の出題範囲を網羅した 400問のオリジナル問題 を収録し、D1 の各論点を本番形式で診断できます。
正答理由だけでなく すべての誤答がなぜ誤りか を AWS 公式ドキュメントに基づいて解説しているため、「わかったつもり」を確実に解消できます。