コンテンツにスキップ

【比較】構造化・半構造化・非構造化の違い

概要

データは「どれだけ決まった形（スキーマ）に従っているか」によって、構造化・半構造化・非構造化の3種類に大別されます。構造化データは行と列の厳密な表形式、半構造化データはタグやキーで自分自身の構造を説明する（自己記述的な）形式、非構造化データは定まった内部構造を持たない生のデータです。

この3分類を理解すると、データをどのように収集・保存・分析すればよいかの判断に役立ちます。とくに重要なのは「半構造化 ≠ 非構造化」という点で、JSON や XML のように構造を説明するメタデータを持つものは半構造化に分類されます。

詳細比較

特徴 構造化データ (Structured Data) 半構造化データ (Semi-structured Data) 非構造化データ (Unstructured Data)
形式 行と列を持つ厳密な表形式 タグやキーなどで階層構造を持つ（自己記述的） 定まった形式がない
スキーマ 事前に定義された厳密なスキーマ（構造）を持つ 固定スキーマは持たないが、メタデータ（タグ・キー）で構造を持つ スキーマを持たない
柔軟性 低い（定義された形式に従う必要がある） 中程度（ある程度の構造を持ちつつ、変更も可能） 高い（様々な形式のデータをそのまま格納できる）
分析の容易さ 容易（SQLなどで簡単に扱える） 比較的容易（特定のパーサーやクエリ言語が必要） 困難（自然言語処理や画像認識などの高度な技術が必要）
格納場所 リレーショナルデータベース（RDB） NoSQLデータベース、Webサーバーなど データレイク、オブジェクトストレージなど

各データの詳細と具体例

1. 構造化データ (Structured Data)

コンピュータが最も理解しやすく、処理が容易なデータ形式です。

  • 定義: 厳密に定義されたデータモデル（スキーマ）に従い、行と列で構成される表形式で整理されたデータ。SQL で容易にクエリできます。
  • 具体例:
    • データベース:
      • リレーショナルデータベースのテーブル（例: MySQL, PostgreSQL, Oracle Database）
    • 業務データ:
      • 財務諸表（売上、費用、利益など）
      • 顧客リスト（顧客番号、氏名、住所、電話番号、購入履歴など）
      • 商品マスター（商品コード、商品名、価格、在庫数など）
      • 人事データ（社員番号、氏名、部署、役職、給与など）
      • 販売時点情報管理（POS）データ
    • その他:
      • ExcelやGoogleスプレッドシートで作成された表
      • Webサイトのアクセスログ（特定のフォーマットに整形されたもの）
      • アンケートの選択式回答（はい/いいえ、A/B/Cなど）

2. 半構造化データ (Semi-structured Data)

構造化データと非構造化データの中間的な性質を持ちます。データ自体に構造を説明するための情報（メタデータ）が含まれており、「自己記述的（self-describing）」とも呼ばれます。

  • 定義: 固定された表形式スキーマは持たないものの、タグやキー、インデントといったマークアップによって階層構造や意味を持つデータ。
  • 具体例:
    • マークアップ言語:
      • JSON (JavaScript Object Notation): Web APIでのデータ交換に広く利用される。 { "name": "Taro", "age": 30 } のような形式。
      • XML (eXtensible Markup Language): かつてデータ交換や設定ファイルで主流だった。 <person><name>Taro</name><age>30</age></person> のような形式。
      • YAML: JSONより可読性が高く、設定ファイルなどで利用される。
    • Web関連:
      • HTML: Webページの構造を定義する言語。<h1>や<p>などのタグで構造化されている。
    • 文書フォーマット:
      • Markdown (.md): 見出し (#) やリスト (*) などの簡易な記法で構造を持つテキスト。
    • その他:
      • 電子メール（From:, To:, Subject: といったヘッダー部分は構造化されているが、本文は非構造化）

3. 非構造化データ (Unstructured Data)

ガートナーや IDC は、企業で生成される新規データの約8〜9割が非構造化データだと推計しています。AIや機械学習の発展により、近年その活用が注目されています。

  • 定義: 特定のデータモデルや内部構造を持たない、そのままの形式のデータ。
  • 具体例:
    • テキスト:
      • 電子メールの本文
      • チャットの会話ログ（Slack, Teams, LINEなど）
      • Word, PDF, PowerPointなどのオフィス文書
      • Webサイトやブログの記事、ニュース記事
      • SNSへの投稿（X (旧Twitter)のポスト、Facebookの投稿など）
      • オープンアンケートの自由記述回答
      • 議事録
    • リッチメディア:
      • 画像ファイル（JPEG, PNG, GIF）
      • 音声ファイル（MP3, WAV, M4A）、会議の録音
      • 動画ファイル（MP4, MOV, AVI）、Web会議の録画
    • センサーデータ:
      • IoTデバイスから収集される連続的な生データ
      • 監視カメラの映像
      • 気象観測データ

これらの違いを理解することで、データをどのように収集、保存、分析すればよいかの判断に役立ちます。

よくある誤解

  • 「JSON や XML は非構造化データ」は誤り。 JSON・XML・CSV・YAML はタグやキーといったメタデータで自分の構造を説明する「自己記述的」なデータであり、半構造化に分類されます（IBM の定義でも semi-structured ＝ self-describing structure）。固定の表スキーマがないことと、構造が一切ないことは別物です。

  • 「非構造化データには構造（メタデータ）が一切ない」は不正確。 画像や動画にも撮影日時・解像度といったメタデータは付随し得ます。「非構造化」が指すのは中身（本文・画素・音声波形）が定型の内部構造を持たないことであり、付随メタデータの有無とは別の話です。

  • 「構造化データが世の中の大半を占める」は誤り。 ガートナー／IDC の推計では、企業の新規データの約8〜9割は非構造化データで、構造化データはむしろ少数派です。さらに非構造化データは構造化データの数倍の速度で増加しているとされます。

実務での選び分け

  • 集計・結合・厳密な整合性が必要 → 構造化データとして RDB に格納し、SQL で扱う。スキーマ設計が前提。
  • スキーマが変わりやすい／システム間でやり取りする → 半構造化（JSON/XML）で表現し、ドキュメント DB やメッセージとして扱う。パーサー／クエリ言語（JSONPath, XPath 等）を用いる。
  • テキスト・画像・音声・動画など中身が定型でない → 非構造化データとしてオブジェクトストレージ／データレイクに保存し、NLP・画像認識など AI/ML で価値化する。
  • 混在する（メールのヘッダー＋本文など） → 部分ごとに分類し、構造化部分はインデックス化、非構造化部分は全文検索や AI 処理に回す。

ひとことまとめ

データは「決まった形にどれだけ従うか」で構造化（厳密な表形式）・半構造化（タグやキーで自己記述する JSON/XML 等）・非構造化（定型構造を持たないテキストやメディア）に分かれ、半構造化と非構造化の混同が最も多い落とし穴です。

出典・参考