MLA-C01 Domain 1 完全攻略 — ML のためのデータ準備で 28% を取る

MLA-C01 の 4 ドメインで最大の配点を持つのが、Domain 1「Data Preparation for Machine Learning」の 28% だ。データフォーマットの選択、ストレージの使い分け、特徴量エンジニアリング、そしてバイアスとコンプライアンス。地味に見えるこの領域こそ、実務の ML プロジェクトで工数の大半を占め、試験でも最大の得点源になる。本記事は公式試験ガイドの Task 1.1〜1.3 に準拠し、Domain 1 の全出題範囲を「判断基準」のかたちで整理する。

試験全体の仕様と 4 ドメインの位置づけは AWS MLA-C01 完全攻略入門（2026-06-15 公開）で解説した。本記事はその Domain 1 深掘り編だ。

Domain 1 が最大配点 28% である理由

機械学習の教科書はモデルとアルゴリズムから始まるが、MLA-C01 はデータから始まる。この設計には実務的な必然性がある。本番の ML パイプラインで障害が起きる場所は、モデルそのものより、データの取り込み・変換・品質管理であることが圧倒的に多いからだ。

公式試験ガイドは Domain 1 を 3 つのタスクステートメントに分割している。

3 タスクに共通する出題の型は「要件文からツールと設定を逆引きさせる」ことだ。アクセスパターンを聞いてフォーマットを選ばせる。レイテンシ要件を聞いてストレージを選ばせる。チームのスキルセットを聞いて変換ツールを選ばせる。つまり Domain 1 の学習は、個々のサービス説明を読むことではなく、判断の分岐表を頭の中に作ることに等しい。

Task 1.1 — データフォーマット 6 種の使い分け

試験ガイドが名指しするフォーマットは Apache Parquet、JSON、CSV、Apache ORC、Apache Avro、RecordIO の 6 つ。それぞれの性格を一言で言い分けられることが最初の関門になる。

判断軸はアクセスパターンだ。「特定の列だけを大量に読む分析」なら列指向の Parquet か ORC。「レコード単位で次々に流れてくるデータ」なら行指向の Avro。「人が目で確認しながら少量を扱う」なら CSV。試験では「クエリコストを下げたい」「スキャン量を減らしたい」という表現が列指向フォーマットへの誘導になっていることが多い。CSV から Parquet への変換でストレージと読み取りの両方が効率化される、という流れは定番中の定番だ。

RecordIO だけは毛色が違う。これは分析用ではなく、SageMaker の組み込みアルゴリズムが学習入力として受け付けるバイナリ形式であり、「学習ジョブのスループットを上げるための形式」という文脈で登場する。また、試験ガイドは「検証済みフォーマットと非検証フォーマット」という区別にも触れている。スキーマが強制される形式はパイプラインの早い段階で型崩れを検出でき、スキーマレスな形式は柔軟だが品質チェックを別途仕込む必要がある。フォーマット選択は単なる性能の話ではなく、後工程のデータ品質管理の設計まで含めた判断だ、という視座を持っておくと応用問題に強くなる。

Task 1.1 — ストレージ選択は S3・EFS・FSx の三択から

コアのデータソースとして試験ガイドが挙げるのは Amazon S3、Amazon EFS、Amazon FSx for NetApp ONTAP だ。加えて、抽出元としては EBS・RDS・DynamoDB も登場する。

S3 はデータレイクの既定値であり、迷ったら S3 と考えてよい。耐久性・コスト・他サービスとの統合のすべてで基準点になる。地理的に離れた拠点から大容量をアップロードする要件には S3 Transfer Acceleration、ブロックストレージの I/O 性能要件には EBS の Provisioned IOPS という個別オプションが、試験ガイドにも明記されている。

EFS と FSx が選択肢に挙がるのは、複数の学習インスタンスから同一データへ同時にファイルアクセスしたい場面だ。Task 1.3 には「学習リソースへ読み込むためのデータ構成」として EFS / FSx が再登場する。S3 にあるデータをそのまま使うか、ファイルシステムに載せ替えて学習ジョブに食わせるか。データ量・反復回数・起動時間の要件から選ばせる問題を想定しておきたい。なお、AWS SAA-C03 高性能設計 完全攻略（2026-06-04 公開）で整理したストレージ選択の判断軸は、ここでほぼそのまま流用できる。

コスト・性能・データ構造から初期ストレージを決める、というスキル項目も明記されている。「とりあえず全部 S3 Standard」ではなく、アクセス頻度と構造（構造化・半構造化・非構造化）を聞いてから決める姿勢が問われる。

抽出元としての RDS と DynamoDB にも触れておく。ML の学習データは多くの場合、業務システムのデータベースに散らばっており、それらを 1 つのデータセットに統合する工程が必要になる。試験ガイドはこの「複数ソースのマージ」を明示的なスキル項目として挙げ、手段として AWS Glue と Apache Spark、そしてプログラミングによる結合を名指しする。リレーショナルな業務データ、NoSQL のイベントデータ、S3 のログ。出自の異なるデータを突き合わせるとき、結合キーの整合性と重複の扱いが品質を左右する——という Task 1.2 への伏線が、ここで張られている。

Task 1.1 — ストリーミング取り込みの登場人物

リアルタイムにデータが流れ込むユースケースでは、Amazon Kinesis、Apache Flink、Apache Kafka が試験ガイドの名指しメンバーになる。バッチとストリーミングの境界判断が最初の論点で、「日次で集計すればよい」ならバッチ、「秒単位で特徴量を更新したい」ならストリーミングだ。

ストリーミング変換の実行役としては AWS Lambda と Spark が挙げられている。軽量なレコード単位の整形なら Lambda、ウィンドウ集計のような重い処理なら Flink や Spark という役割分担を押さえる。取り込みと保存の容量・スケーラビリティ起因のトラブルシューティングもスキル項目に含まれており、「シャード数を増やす」「バッファリングで書き込みをまとめる」といった対処の方向性を理解しておくと、シナリオ問題で迷いが減る。

Kinesis と Kafka の選び分けは、技術の優劣ではなく運用体制の問題として出題される。AWS ネイティブでフルマネージドに寄せたいなら Kinesis、既存の Kafka 資産やエコシステムを活かしたいなら Kafka 系という整理が基本線だ。ML 文脈での落とし所は「ストリーミングで取り込んだデータを、リアルタイム特徴量としてどこに着地させるか」であり、後述する Feature Store のオンラインストアがその受け皿になる。取り込み・変換・着地を 1 本の流れとして語れるようになると、順序付け形式の問題がそのまま得点になる。

Task 1.2 — クリーニングと特徴量エンジニアリングの定番手法

Task 1.2 は手法の語彙が問われる領域だ。試験ガイドの列挙をそのまま地図にする。

• クリーニング: 外れ値の検出と処理、欠損値の補完、結合、重複排除
• 特徴量エンジニアリング: スケーリングと標準化、特徴量分割、ビニング、対数変換、正規化
• エンコーディング: one-hot エンコーディング、バイナリエンコーディング、ラベルエンコーディング、トークン化

このうち頻出の判断ポイントは 2 つある。第一にエンコーディングの使い分け。カテゴリ変数に順序がないなら one-hot、順序があるならラベルエンコーディング、カテゴリ数が膨大で one-hot では次元が爆発するならバイナリエンコーディングや別手法、テキストならトークン化。「カテゴリ数」と「順序の有無」という 2 軸で選ばせる問題は組み合わせ（matching）形式とも相性がよい。

第二に分布の補正。裾の長い分布には対数変換、スケールの異なる特徴量が混在するなら標準化や正規化。「どの前処理がこの症状に効くか」という症状 → 処方の対応付けで覚えると、順序付け形式で工程を並べる問題にも対応できる。

欠損値と外れ値の扱いにも、単純な「削除」以外の選択肢を持っておきたい。欠損が少数なら行の削除で済むが、欠損自体に意味があるケースや欠損率が高い列では、平均値・中央値などによる補完か、欠損フラグの特徴量化が候補になる。外れ値も同様に、計測ミスなら除外、実在する極端値なら対数変換やビニングで影響を抑える、と原因によって処方が変わる。「なぜその値がそうなっているか」を問うてから手法を選ぶ、という順序そのものが出題の急所だ。

Task 1.2 — 変換ツール 4 択: Glue / DataBrew / EMR / Data Wrangler

Domain 1 で最も差がつくのが、変換ツールの使い分けだ。機能が重なって見える 4 つを、利用者と運用形態で切り分ける。

試験の要件文には利用者像が埋め込まれている。「コードを書かないアナリストが」とくれば DataBrew、「定期的な ETL ジョブを自動化」とくれば Glue、「既存の Spark ジョブを最小変更で」とくれば EMR、「ML モデリングの前処理を SageMaker 内で完結」とくれば Data Wrangler。データ品質の検証には Glue Data Quality と DataBrew が、ガイドのスキル項目として明記されている点も押さえておく。

Feature Store — オンラインとオフラインの二層構造

SageMaker Feature Store は、特徴量を「作る」工程と「使う」工程の間に立つ共有基盤だ。公式ドキュメントが定義する二層構造の理解が出題の核になる。

オンラインストアは各特徴量の最新レコードだけを保持し、ミリ秒単位の低レイテンシ読み取りで本番推論時の特徴量参照を支える。一方のオフラインストアは全履歴を S3 上に Parquet 形式で蓄積し、モデル学習やバッチ推論、データ探索に使う。両方を有効にした場合は同期され、学習時と推論時で特徴量がずれる「トレーニング・サービング・スキュー」を防ぐ。この「最新値はオンライン、履歴はオフライン」という対比は、組み合わせ形式の出題にそのまま使える題材だ。

公式ドキュメントの細部も拾っておく。オンラインストアには標準（Standard）とインメモリ（InMemory）のストレージティアがあり、読み書きのパターンに応じて選択できる。オフラインストアへの書き込みは即時ではなく、バッファリングとバッチ化を経て 15 分以内に S3 へ反映される仕様で、テーブル形式は既定の AWS Glue 形式に加えて Apache Iceberg 形式を選べる。「オフラインに書いたはずのレコードがすぐクエリに出てこない」という挙動は不具合ではなく設計であり、リアルタイム参照が必要ならオンラインストアを使う——この切り分けが理解できていれば、Feature Store の出題はほぼ取れる。

実務文脈では、チーム間で特徴量定義を再利用できる点も Feature Store の存在理由になる。同じ「顧客の過去 30 日間の購買回数」をチームごとに別実装すると、定義の揺れがそのままモデル品質の揺れになる。特徴量を中央管理する発想は、Domain 4 の監視・再現性の議論にもつながっていく。

Ground Truth — ラベリングの 3 つの労働力

教師あり学習の前提となるラベル付きデータを作る仕組みが SageMaker Ground Truth だ。公式ドキュメントが定義する労働力（ワークフォース）は 3 種類ある。

注意すべき制約が 2 つ、公式に明記されている。Mechanical Turk を使う場合、入力データに個人を特定できる情報（PII）を含めてはならない。そして 3D 点群と動画フレームのラベリングジョブはプライベートとベンダーのみ対応で、Mechanical Turk には出せない。「医療画像のラベリングをどのワークフォースで行うか」という問いは、機密性の観点からプライベート一択になる——この種の消去法が本番での解き筋だ。

運用面では、Mechanical Turk の支払いが Ground Truth の請求に統合されており、別途 Mechanical Turk アカウントを作る必要がない点も公式に明記されている。ラベリングはデータ準備の中で最も人件費がかかる工程であり、「どこまで自動化し、どこから人に頼むか」という線引きそのものが設計判断になる。高品質なラベル付きデータセットを作るアノテーションサービスの知識は Task 1.2 の知識項目にも挙げられており、Ground Truth は Domain 1 の中で「ツールの名前を知っている」だけでは済まない、運用込みで問われるサービスだと考えておくべきだ。

Task 1.3 — バイアス指標とコンプライアンスで仕上げる

Domain 1 の最後のタスクは、データの「正しさ」を統計とガバナンスの両面から担保する領域だ。

統計面の主役は学習前バイアス指標で、試験ガイドはクラス不均衡（CI: Class Imbalance）とラベル比率差（DPL: Difference in Proportions of Labels）を名指しする。検出には SageMaker Clarify を使い、是正には再サンプリングや合成データ生成を充てる。選択バイアス・測定バイアスといったバイアスの発生源の語彙も問われる。さらに、予測バイアスを減らすためのデータセット分割・シャッフル・拡張（augmentation）が、モデリング準備のスキルとして挙げられている。

ガバナンス面では、暗号化・匿名化・マスキングの手法と、PII（個人特定情報）・PHI（保護対象保健情報）・データレジデンシー（保管地域要件）というコンプライアンス概念の含意が出題範囲だ。ここは AIF-C01 Domain 4+5 完全攻略（2026-06-12 公開）で扱った責任ある AI の議論と地続きで、AIF-C01 取得者なら復習で済む。MLA-C01 ではそれを「データ準備の工程に組み込めるか」という実装目線で問い直してくる。

頻出論点チェックリスト — 本番想定の自己診断

Domain 1 の仕上げとして、以下に即答できるかを確認してほしい。

• 列の一部だけ読む分析クエリに最適なフォーマットは（→ Parquet / ORC）
• スキーマ進化に強い行指向バイナリフォーマットは（→ Avro）
• 複数学習インスタンスからの同時ファイルアクセスに使うストレージは（→ EFS / FSx）
• 遠隔地からの大容量アップロードを高速化する S3 機能は（→ Transfer Acceleration）
• ノーコードでデータ品質ルールを適用するサービスは（→ DataBrew、Glue Data Quality）
• 推論時にミリ秒で特徴量を返す Feature Store の層は（→ オンラインストア）
• 機密文書のラベリングに選ぶワークフォースは（→ プライベート）
• クラス不均衡を検出する Clarify の学習前指標は（→ CI、DPL）

8 問中 6 問以上を根拠付きで即答できれば、Domain 1 は得点源になっている。逆に詰まった項目は、対応するタスクステートメントへ戻って埋め直すのが効率的だ。

学習の進め方としては、サービス名の暗記より先に「工程の地図」を固定することを勧める。取り込み（フォーマット・ストレージ・ストリーミング）→ 変換（クリーニング・特徴量・エンコーディング）→ 整合性（バイアス・暗号化・コンプライアンス）→ 学習リソースへの供給。この 4 段の地図に、本記事で挙げたサービスを配置していく。地図が先にあれば、初見のシナリオ問題でも「いまどの工程の話をしているか」から逆算してサービスを絞り込める。Domain 1 は範囲が広いぶん、この構造化の効果が 4 ドメインの中で最も大きい。

まとめ — データを制する者が MLA-C01 を制する

Domain 1 は配点 28% という数字以上に、Domain 2 以降の土台になる領域だ。フォーマットとストレージの判断軸、変換ツール 4 択の使い分け、Feature Store の二層構造、Ground Truth の 3 ワークフォース、そしてバイアス指標とコンプライアンス。いずれも「要件 → 選択」の分岐表として整理すれば、多肢選択でも組み合わせ形式でも同じ地図で戦える。

次のドメインはモデル開発（26%）。アルゴリズム選択と学習の改良、評価指標の使い分けへ進む前に、本記事のチェックリストで Domain 1 の取りこぼしを潰しておいてほしい。試験準備の全体設計は AWS MLA-C01 完全攻略入門（2026-06-15 公開）の 8 週間ロードマップを参照のこと。

参照

• MLA-C01 試験ガイド Domain 1（公式）
• Amazon SageMaker Feature Store（公式ドキュメント）
• SageMaker Ground Truth ワークフォース管理（公式ドキュメント）
• AWS Certified Machine Learning Engineer – Associate 公式ページ

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.