データの種類を整理する意味
AIF-C01の学習を進めていると、「構造化」「非構造化」「ラベルありなし」「テキストや画像、時系列」といった言葉がまとめて登場します。ここを“用語の暗記”で乗り切ろうとすると、実務でも試験でも判断がブレやすくなります。逆に、データの種類が見分けられるようになると、次のような判断が一気にやりやすくなります。
- その課題は教師あり学習っぽいのか、教師なし学習っぽいのか
- 前処理で何が必要になりそうか（整形、特徴量、欠損、正規化、テキスト処理など）
- データの保管や分析で、AWSのどのサービスが自然か（S3、Glue、Athena、Redshift、Kinesisなど）
AIF-C01の試験ガイドや出題範囲でも、データの種類として「ラベルありなし、表形式、時系列、画像、テキスト、構造化と非構造化」などを説明できることが明記されています。
このあと、データの種類を「見た目」ではなく「性質」で整理し、最後にありがちな落とし穴までまとめます。
AIF-C01対策で評価の高いUdemy講座をまとめて確認できます。👇
セール時は1,500円前後で購入できることもあります。
構造化データ 半構造化データ 非構造化データの違い
まずは土台です。データは大きく「構造が強い順」に並べると理解が安定します。
構造化データ
表として扱えるデータです。列と型がだいたい決まっていて、SQLで扱いやすいのが特徴です。
- 例：売上テーブル、顧客マスタ、在庫、センサの集計結果（時刻・温度・湿度の列が固定）
構造化データは、欠損や外れ値はあっても「列の意味」が比較的固定なので、特徴量設計や品質チェックを設計しやすい反面、列定義が崩れると一気に壊れます。
半構造化データ
「表っぽいけど、列が固定ではない」領域です。JSONやログなどが典型です。
AWSでも半構造化を意識した機能が用意されています。たとえば Amazon Redshift は半構造化データ向けのサポート（SUPERデータ型や、S3上のデータを参照するRedshift Spectrum）を提供しています。
- 例：JSONイベント、アプリログ、IoTのメッセージ、可変な属性を持つクリックログ
半構造化は「あとから意味が増える」ことが多いので、データレイクに溜めて、必要に応じてカタログ化して分析する流れと相性が良いです。
非構造化データ
そのままでは表になりにくいデータです。テキスト、画像、音声、動画、PDFなどが入ります。
- 例：問い合わせ文章、レビュー、医療画像、監視カメラ映像、文書スキャン
非構造化は、モデルが直接扱える形（トークン、ベクトル、特徴量、埋め込みなど）に変換する工程が重要になります。ここで「何を入力にして、何を出力したいか」が曖昧だと、学習設計が迷子になりがちです。
AWSの保管と分析のイメージ
データの置き場所としては、まずAmazon S3を中心に考えるのが自然です。S3上に構造化・半構造化・非構造化をまとめて置き、AWS GlueのData Catalogでメタデータ化し、Amazon AthenaやRedshift Spectrumで直接クエリする、という整理はAWSのホワイトペーパーでも紹介されています。
ここまでのポイントは、「構造化＝表」「非構造化＝表じゃない」だけで終わらせず、半構造化という中間地帯を作っておくことです。ログやJSONが出てきた瞬間に判断がブレなくなります。
ラベルありなしが意味すること 教師ありとのつながり
次に「ラベル」です。ここは言葉としてはシンプルですが、実務でも試験でも混乱が起きやすいので、丁寧に整理します。
ラベルとは何か
ラベルは、ざっくり言うと正解データです。
入力データに対して「こう判断してほしい」という結果がセットになっている状態を指します。
- 例：メール本文 → 迷惑メールかどうか
- 例：画像 → 犬か猫か
- 例：過去の売上推移 → 翌週の売上（未来値）
ラベルがあると、教師あり学習の問題として扱いやすくなります。一方、ラベルがない場合は、クラスタリングや次元削減など教師なし寄りの考え方になりやすい、という整理が自然です（ただし、生成AIや自己教師ありなど例外もあるので、まずは“基本形”として押さえるのが大事です）。
ラベル付けはコストであり品質リスクでもある
ラベルはタダでは手に入りません。多くの場合、ラベル付けは人手や外注、または半自動化の仕組みが必要です。AWSでは、データのラベル付けを支援する仕組みとして Amazon SageMaker Ground Truth や Ground Truth Plus が提供されています。
ここで重要なのは、ラベルが付けば終わりではなく、ラベル品質がモデル品質を決めることです。たとえばGround Truthでは、ラベルの信頼スコアに関する注意点（スコアの解釈や比較の仕方など）が明確に書かれており、ラベル品質をどう扱うかが重要であることがわかります。
ラベルありでも失敗しやすい典型
ラベルがあるのに精度が出ないケースは、だいたい次のどれかに寄ります。
- ラベルの定義が曖昧（人によって判断が分かれる）
- ラベルにノイズが多い（誤ラベル、未確定ラベル）
- データの偏りが強い（片方のクラスが極端に少ない）
- 学習用と評価用の分け方が悪い（後述のデータリーク）
AIF-C01で重要なのは「ラベルがある＝教師あり」と短絡しないことです。ラベルの定義と品質まで含めて“使えるラベルか”を考えると、判断が安定します。
テキスト 画像 時系列の特徴とよくある勘違い
ここからは「モダリティ別」に整理します。AIF-C01の範囲でも、テキスト、画像、時系列といったデータタイプの説明が前提として扱われています。
テキストデータ
テキストは一見わかりやすいのですが、落とし穴は「表に入っているから構造化」と勘違いすることです。
たとえば、CSVに「問い合わせ本文」という列がある場合、全体は構造化に見えても、中身は非構造化です。
- 例：顧客ID、日時、本文、カテゴリラベル
→ IDや日時は構造化、本文は非構造化、カテゴリがラベル
この状態を正しく言えると、設計が一段ラクになります。「本文の列はそのままではモデルが扱えないので前処理が必要」という判断が自然に出ます。
画像データ
画像は典型的な非構造化です。ラベルは「画像全体に付く場合」もあれば、「画像内の物体位置（バウンディングボックス）」のようにより細かい形で付く場合もあります。
ラベル付けの設計が難しい分、Ground Truthのような支援が役立つ、という流れにつながります。
画像でありがちな勘違いは次の2つです。
- 画像が増えれば必ず良くなると思い込む
→ 同じような構図ばかりだと多様性が増えず、汎化しづらい - ラベル粒度を決めずに始める
→ 「犬か猫か」なのか「犬種まで」なのかで必要データ量が変わる
時系列データ
時系列は「時間の順序が意味を持つ」データです。ログ、センサ、株価、リクエスト数などが代表例です。
ここは試験でも混乱しやすいポイントで、表形式に見えるので構造化に分類されがちですが、**本質は“順序と依存”**にあります。
AWSの世界だと、ストリーミングとして取り込むなら Amazon Kinesis Data Streams が典型で、シャードやレコードといった概念で継続的にデータを扱います。
また、時系列を分析用途で保持・活用する文脈では、Kinesisから時系列DBへ連携する話も出てきます。
時系列の落とし穴は、データ分割をランダムにやってしまうことです。ランダム分割をすると未来情報が学習側に混ざり、評価が不自然に良くなる（データリーク）ことが起きます。時系列は基本的に「過去で学習して未来で評価」が筋なので、分割ルールを最初に決めておくのが大切です。
落とし穴とAWSでの扱い方 迷ったときの整理手順
最後に、AIF-C01の学習でも実務でも効く「落とし穴」を、AWSのサービス観点とつなげて整理します。ポイントは、サービス名を丸暗記するより先に、データの性質から自然に当てはめることです。
落とし穴 よくあるのはデータの取り違え
まず多いのが、データを次のどれか1つに決め打ちしてしまうミスです。
- 「CSVだから構造化」
- 「ログだから非構造化」
- 「S3にあるからデータレイク」
- 「ラベルがあるから教師ありでOK」
実際は、同じファイルでも列の中に非構造化が混ざることもありますし、ログも整形すれば半構造化としてクエリできます。AthenaがS3上の構造化・半構造化・非構造化を扱える例として挙げているように、形式は連続体です。
落とし穴 スキーマのズレは静かに壊れる
半構造化で頻発するのがスキーマドリフトです。JSONのキーが増えたり減ったり、同じキーでも型が変わったりします。
こういうときに「まずS3へ集約し、Glue Data Catalogでメタデータ管理し、AthenaやRedshift Spectrumで参照する」という整理は、変更に強い入口になります。
やることはシンプルで、次の順番で考えると迷いにくいです。
- まずは生データを壊さず保管する（S3に集約）
- 参照のためのメタデータを整える（Glue Data Catalog）
- すぐに試したい分析はクエリで当てる（Athena）
- 大規模で高速な集計が必要ならDWH側へ寄せる（Redshift、必要に応じてSpectrum）
落とし穴 データリークは評価を壊す
データリークは「気づきにくいのに効果が大きい」落とし穴です。代表例は次のとおりです。
- 学習データに答えが混ざっている（ラベルに直結する特徴が入る）
- 時系列で未来情報が混ざる（ランダム分割の副作用）
- 同一人物・同一端末のデータが学習と評価に跨る（ユーザー単位で分けるべき）
試験でも「推論方式（バッチ・リアルタイム）」や「データのタイプ」を説明する前提があるので、評価設計の筋が通っているかを意識して読むと、理解が深まります。
落とし穴 ラベル品質はモデル品質より先に崩れる
ラベル付けを外注したのに精度が出ない、という話は珍しくありません。理由はだいたい次です。
- 指示文が曖昧で、人によってラベルがブレる
- 例外ケースの扱いが未定義
- ノイズラベルが混ざっているのに気づけない
Ground Truthのドキュメントに、ラベルの信頼スコアの扱い方や、自動ラベル付けの仕組み・注意点が記載されているのは、まさにこの領域が重要だからです。
「ラベルはあるか」だけでなく、「ラベルは信用できるか」「定義は一貫しているか」を確認する癖がつくと、AIF-C01の理解が“実務寄り”になります。
落とし穴 ストリーミングは遅延と順序が別問題
時系列やイベントデータをKinesisで扱う文脈では、「リアルタイムっぽいから全部うまくいく」と思いがちですが、実際には次の観点を分ける必要があります。
- 遅延：どれくらい早く処理したいか
- 順序：順番が崩れたら困るのか
- 再処理：過去分をリプレイしたいか
- 保管：どこに永続化して分析するか
Kinesis Data Streamsはシャードやレコードといった単位でデータを継続的に扱う設計になっており、ここを理解しておくと「時系列＝表」ではないことが腑に落ちます。
迷ったときの整理手順
最後に、迷ったときのチェック手順を置いておきます。暗記ではなく、判断の型です。
- そのデータは表として自然に扱えるか
→ はい：構造化寄り、いいえ：非構造化寄り、途中：半構造化 - 正解がセットになっているか
→ はい：ラベルあり、いいえ：ラベルなし - 時間の順序が意味を持つか
→ はい：分割と評価は時系列前提で考える - すぐ分析したいのか、まず溜めたいのか
→ まず溜める：S3中心、すぐ分析：Athena、集計基盤：Redshift など
この型で整理できれば、サービス名を丸暗記しなくても、問題文から自然に方向性が見えるようになります。
なお、AIF-C01の学習を体系的に進めたい場合は、「データの種類→前処理→学習手法→評価」という順でまとまっている教材が相性が良いです。教材の一例として、UdemyのAIF-C01対策講座のようにハンズオンや用語整理がセットになっているものを選ぶと、理解の抜け漏れを減らしやすいと思います。
AIF-C01対策で評価の高いUdemy講座をまとめて確認できます。👇
セール時は1,500円前後で購入できることもあります。
まとめ
AIF-C01で登場するデータの種類は、用語としては多く見えますが、整理の軸はシンプルです。まず「構造が強いか弱いか」で、構造化・半構造化・非構造化を分けます。次に「正解が付いているか」で、ラベルありなしを見ます。そして「時間の順序が意味を持つか」で、時系列としての注意点が出てきます。テキストや画像は非構造化の代表で、表に入っていても中身は非構造化、という混在パターンがよく起きます。
落とし穴としては、スキーマのズレ、データリーク、ラベル品質のブレ、時系列の分割ミスが典型です。AWSでは、S3を中心にデータを集約し、Glue Data Catalogでメタデータを整え、AthenaやRedshift Spectrumで分析する流れが整理しやすく、ラベル付けはSageMaker Ground Truthのような支援もあります。
暗記で乗り切るより、「表として扱えるか」「ラベルはあるか」「順序が重要か」という判断の型を持っておくと、AIF-C01の問題文でも実務の設計でもブレにくくなります。
