生のデータは、そのままではモデルが学習できません。欠損や外れ値を整え、カテゴリを数値に変え、スケールをそろえる——この「データ変換と特徴量エンジニアリング」は、モデルの精度を左右する最重要工程です。MLでは「アルゴリズムより前処理で決まる」と言われるほど。MLA-C01でも、どの変換を・どのAWSツールで行うかの判断が問われます。この記事では各技法とサービスの使い分けを、図とクイズで理解できるように解説します。全体像は シラバスマップ、前の記事は M1-1 取り込みと保存 をどうぞ。
なぜ特徴量エンジニアリングが重要なのか
モデルは「数値の表」しか学べません。文字のカテゴリ、欠けた値、極端な外れ値、桁の違う数値が混ざったままでは、うまく学習できません。逆に言えば、データを適切に整えるだけで精度が大きく上がる。だからこそ配点最大のドメイン1で、変換の知識が重視されます。工程は大きく「クレンジング→特徴量の加工→エンコーディング→スケーリング」です。
① データのクレンジング（欠損・外れ値・重複）
- 欠損値の補完（imputation）：空欄を平均・中央値・最頻値などで埋める。安易に行を削除すると貴重なデータを失うため、まず補完を検討
- 外れ値（outlier）の検出・処理：極端な値は学習を歪める。除外・上限/下限でのクリッピング・変換などで対処
- 重複排除（deduplication）：同一レコードの重複は偏りの原因。除去する
- 結合（combining）：複数ソースのデータを突き合わせて1つの学習テーブルにまとめる
② 特徴量の加工（スケーリング・変換）
数値特徴量は「桁・分布」をそろえると、多くのモデルで学習が安定します。
- 標準化（standardization）：平均0・分散1にそろえる（z-score）
- 正規化（normalization / min-max）：0〜1の範囲に収める
- log変換：右に大きく歪んだ分布（高額データなど）を、正規分布に近づける
- ビニング（binning）：連続値を「年代」などの区間に区切る
- feature splitting：日時を「年・月・曜日」に分けるなど、1列から有用な特徴を取り出す
③ カテゴリ変数のエンコーディング
「赤・青・緑」のような文字のカテゴリは、数値に変換（エンコーディング）しないとモデルに入れられません。ここで変換の仕方を間違えると、存在しない順序をモデルが学んでしまうので注意が必要です。
- ワンホット（one-hot）：カテゴリごとに0/1の列を作る。順序のない名義カテゴリに安全（色・都道府県など）。種類が多いと列が増える
- ラベル（label）：各カテゴリに整数を割り当てる。省スペースだが大小の順序を暗示するため、順序のあるカテゴリ向き
- バイナリ（binary）：整数を2進数で表し、ワンホットより少ない列で表現
- トークン化（tokenization）：テキストを単語/トークンに分割し、数値表現の入口にする
④ 変換ツールの使い分け（Data Wrangler／Glue／DataBrew）
同じ変換でも、誰が・どの規模で・どう連携するかでツールが変わります。
| ツール | 性格 | 向いている場面 |
|---|---|---|
| SageMaker Data Wrangler | ML前処理特化・GUI | Studio内で対話的に前処理し、学習パイプラインへ直結 |
| AWS Glue | サーバーレスETL（Spark） | 大規模データのコードベースETL・定常パイプライン |
| AWS Glue DataBrew | ノーコード・ビジュアル | アナリストがコードを書かずプロファイル＆クレンジング |
| EMR（Spark） | 大規模分散処理 | 既存Spark資産・超大規模なカスタム処理 |
| AWS Lambda | 軽量・イベント駆動 | ストリーミングデータのその場の軽い変換 |
ざっくり：SageMakerで完結したい＝Data Wrangler／大規模ETLをコードで＝Glue／非エンジニアがノーコードで＝DataBrew。
⑤ 特徴量を一元管理：SageMaker Feature Store
作った特徴量を毎回バラバラに計算すると、学習時と推論時で値がズレて精度が落ちる（training-serving skew）問題が起きます。SageMaker Feature Storeは特徴量を一元管理・再利用する仕組みで、2つのストアを持ちます。
- オンラインストア：低レイテンシで取得。リアルタイム推論で最新の特徴量を引く
- オフラインストア：S3に履歴を蓄積。学習やバッチで大量データを使う
- 両者で同じ特徴量定義を共有するので、学習と推論の一貫性が保て、特徴量の再利用も進む
⑥ データのラベリング（Ground Truth／Mechanical Turk）
教師あり学習には正解ラベルが要ります。SageMaker Ground Truthはマネージドのラベリングサービスで、人手によるアノテーションに加え、自動ラベリングでコストを抑えられます。作業者の調達にはAmazon Mechanical Turk（クラウドソーシング）を使えます。高品質なラベル付きデータセットづくりの土台です。
確認クイズ
Q1. あなたは需要予測モデルを開発しています。入力データには「都道府県」という、47種類あって大小の順序を持たない名義カテゴリの列が含まれます。これを線形回帰モデルに与えたいのですが、各カテゴリに0,1,2…と整数を振ると、モデルが数値の大小を順序として誤って学習してしまう懸念があります。最も適切なエンコーディングはどれですか。
Q2. あなたはデータサイエンティストとして、Amazon SageMaker Studio上でモデル開発を進めています。学習前のデータについて、欠損値の補完やエンコーディングなどの前処理を対話的に試行錯誤しながら設計し、完成した変換手順をそのままSageMakerの学習・推論パイプラインへ組み込みたいと考えています。最も適したツールはどれですか。
Q3. あなたが運用する不正検知システムでは、バッチで学習したモデルをリアルタイム推論エンドポイントで使っています。最近、学習時に使った特徴量の計算ロジックと推論時の計算がわずかにズレ、本番精度が劣化する事象が起きました。学習用の大量履歴と、低レイテンシなリアルタイム推論の両方で一貫した特徴量を使いたいと考えています。最も適切な仕組みはどれですか。
Q4. あなたはk近傍法（距離ベース）の分類モデルを構築しています。特徴量には「年齢（0〜100）」と「年収（0〜1000万）」が含まれ、両者は桁が大きく異なります。このまま学習すると、値の大きい年収ばかりが距離計算を支配し、年齢の影響がほとんど効きません。両特徴を公平に扱うために最も適切な前処理はどれですか。
よくある質問（FAQ）
Q. ラベルエンコーディングは使ってはいけないの？
A. 順序のあるカテゴリ（例：低・中・高）なら有効です。問題になるのは順序のない名義カテゴリ（色・地域など）に使い、存在しない大小関係を持ち込むケース。その場合はワンホットが安全です。
Q. Data WranglerとGlue、DataBrewはどう選ぶ？
A. SageMakerで学習まで一気通貫＝Data Wrangler、大規模ETLをコードで＝Glue、非エンジニアがノーコードで＝DataBrewが基本の指針です。
Q. Feature Storeは必須ですか？
A. 必須ではありませんが、学習と推論で特徴量を共有したい・チームで再利用したい場合に効果的です。特に学習と推論のズレ（training-serving skew）対策として有力です。
Q. 欠損値はとりあえず行ごと削除でいい？
A. 安易な削除は非推奨です。貴重なデータを失い、偏りを生むことがあります。まずは平均・中央値・最頻値などでの補完を検討しましょう。
まとめ
- 前処理はクレンジング→加工（スケーリング/変換）→エンコーディング。精度を大きく左右する
- 名義カテゴリはワンホット（ラベルは順序を暗示するので注意）、桁違いの数値は標準化/正規化
- ツールはData Wrangler（SageMaker直結）／Glue（大規模ETL）／DataBrew（ノーコード）で使い分け
- Feature Storeはオフライン/オンラインで特徴量を共有し、学習と推論のズレを防ぐ
- ➡ 次の記事：M1-3 データ整合性とバイアス対策（CI/DPL・SageMaker Clarify・暗号化/PII）※準備中
- ➡ 前の記事：M1-1 データの取り込みと保存 ／ シラバスマップ
※本記事はAWS公式試験ガイド(MLA-C01)および各サービスの公開ドキュメントに基づき、エンジニアKが作成しています。サービス仕様は更新されることがあるため、最新は必ずAWS公式でご確認ください。本サイトはAmazon Web Services, Inc.の公式サイトではありません。AWSは同社の商標です。
コメント