🔖 キーワード索引

🔖 拡張キーワード索引（深掘り用）

以下のチップから関連する詳細セクションへジャンプできます。

🎨 直感で掴む

🎨 直感で掴む（拡張）：メタデータの 3 種類

図書館の世界では同じ枠組みを MARC レコード として 1960 年代から使ってきた。 データサイエンスの世界はこの 60 年前の知恵を再発見した形。

🎮 触って理解する

データカタログ検索シミュレーション — 同じ中身のデータでも、 メタデータの有無で「見つけやすさ」がどれだけ変わるかを体感します。 下の検索窓にキーワードを入れる（または課題ボタンを押す）と、 メタデータ充実カタログ と ファイル名だけのフォルダ の両方を同時に検索します。 さらに下のチェックリストでメタデータ項目を外すと、 その項目は検索対象から消え、 「発見可能性スコア」ゲージも下がります。

※ ここに登場する 8 個のデータセットはすべて 架空 の教材用サンプルです（実在の統計値ではありません）。

※ A と B の中身（テーマ）は同じ 4 種類。 違いは「説明書（メタデータ）が付いているか」だけ。 B は中身を 1 つずつ開いて確認しない限り、 単位も更新日も分かりません。

✅ メタデータ・チェックリストと発見可能性スコア

カタログ A に付与するメタデータ項目を On/Off できます。 外した項目は 検索対象から即座に消え、 ヒット件数が変わります。 スコアは項目の重み（タイトル20・説明20・列定義15・ライセンス15・単位10・出典10・更新日10）の合計です。

🎨 直感：メタデータは「荷札」

宅配便の箱（＝データ本体）に付いた 荷札（宛先・差出人・品名・取扱注意）がメタデータ。 荷札のない箱が 100 個届いたら、 全部開けて中身を確認するしかない — 上のフォルダ B がまさにその状態です。 「data_final_v2.csv」という名前は作った本人にしか意味がなく、 3 か月後には本人ですら分からなくなります。

⚠️ よくある落とし穴（体感版）

• メタデータの陳腐化 — 上のチェックリストで「更新日」を外すと分かる通り、 更新日不明のデータは「今も正しいのか」を判断できない。 データを更新したのにメタデータを直し忘れると、 嘘の荷札 になりさらに危険。
• 単位・定義の欠落 — 「単位」「列定義」を外した状態でもタイトルだけでヒットはするが、 見つけた後に「病床数は実数？ 人口10万対？」が分からず結局中身の精査が必要になる。 発見できること と 正しく使えること は別のメタデータ項目が支えている。
• 名前だけ一致の罠 — フォルダ B でも「気温」のようにファイル名に偶然キーワードが入っていればヒットするが、 単位（℃か℉か）も期間も不明。 ヒット＝使える、 ではない。

🚀 発展：カタログ・レジストリ・FAIR 原則

• データカタログ — 上のシミュレーションを組織全体で行う仕組み（DataHub, OpenMetadata, CKAN など）。 データエンジニアリング と データガバナンス の中核。
• スキーマレジストリ — 列定義（スキーマ）を一元管理し、 変更履歴と互換性を検証する仕組み。 「A1101 の意味が版によって変わる」ドリフト事故を防ぐ。
• FAIR 原則 — Findable / Accessible / Interoperable / Reusable。 上のゲージが高いほど F を満たす。 オープンデータ の品質基準であり、 再現性危機 への処方箋でもある。

📐 定義／数式

メタデータ（Metadata）：データを説明するデータ

📐 メタデータ標準語彙の主要候補

Dublin Core 15 要素を SSDSE-B-2026 で書く

📐 メタデータ標準の関係マップ（ASCII）

Dublin Core が「祖先」。 DCAT / schema.org / ISO 19115 など主要標準は DC を拡張・専門化する形で発展している。 自分のデータがどの分野（汎用／カタログ／Web／地理／統計）かを意識して標準を選ぶ。

🧪 LLM 時代のメタデータ活用

2023 年以降、 LLM の普及でメタデータの役割が大きく変わった。 単なる「データの説明」から、 「LLM が正しく検索・引用するための索引」へと進化している。

📊 メタデータ品質を測る KPI

これら 7 指標を レーダーチャート 化したものが「メタデータ成熟度マップ」。 各データセットがどの段階にあるかを可視化し、 改善優先順位を決める。

🔬 記号・用語の読み解き

🔬 数式を言葉で読み解く

$\text{Metadata}(D) = \{(\text{key}_i, \text{value}_i)\}$ は単純な辞書だが、 中身を整理すると 4 階層に展開できる。

1. データセット階層：ファイル全体の説明（タイトル、 著者、 出典）。 「これは何のデータ？」に答える。
2. カラム階層：各列の名前・型・単位・許容値域。 「この数字は何を測ったもの？」に答える。
3. 行階層（オプション）：行 ID・観測時刻・観測者・装置。 「いつ・誰が・どうやって測った？」に答える。
4. 値階層（オプション）：個別セルの信頼度・欠損理由・推定方法。 「この値は信頼できる？」に答える。

key-value という形式は単純だが、 何を key にするかで分析の質が大きく変わる。 「すべての SSDSE データセットが creator を持つ」と決めておけば、 ライブラリやカタログで横断検索が可能になる。 これが 標準語彙（DC, DCAT 等）の存在意義。

🧮 実値で計算してみる

🧮 SSDSE-B-2026 のメタデータを実値で抽出

実ファイル data/raw/SSDSE-B-2026.csv を pd.read_csv で読み込み、 メタデータを抽出した結果：

ファイル全体メタデータ

カラム別メタデータ（抜粋）

→ Null が一切ない（112 列全てで null 率 0.0）、 dtype の 92.9% (104/112) が整数型 — これは「観測値が全て整数で揃っており、 推計年でも欠損を 0 で埋めてある」きれいなデータの特徴。 実務データはここまできれいではないことが多いので、 メタデータでこれを把握できることに価値がある。

🧮 SSDSE シリーズのメタデータ比較表

SSDSE には A〜F の系列がある。 構造（縦持ち／横持ち、 単年／多年、 都道府県／市区町村）が異なるため、 メタデータも系列ごとに異なる。

→ 同じ「SSDSE」というブランドでも、 系列ごとに メタデータの記述項目が異なる。 A-B は都道府県、 C は都市、 D は個人。 用途別にスキーマを切り替える必要がある。 横断検索したい場合は、 共通の上位カタログ（DCAT 互換）でラップする。

🧮 数式に値を入れて手で計算する: メタデータ充実度

合成データで 100 テーブルのメタ項目充足率を計算する。

Step 1: 項目別充足

Step 2: 平均充足率

🐍 Python で再現

1
2
3
4

import numpy as np
r = np.array([0.70, 0.90, 0.40, 0.60, 0.50])
print(f"平均: {r.mean():.3f}")
print(f"最低 index: {r.argmin()} ({r.min()})")

📤 実行結果

💬 手計算 (Step 2) 62% と Python 出力が完全一致。

🐍 Python での実装例

SSDSE-B-2026 などの実データを使った最小コード（9行）：

1
2
3
4
5
6
7
8
9

import pandas as pd, json
df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])
meta = {
    'title': 'SSDSE-B-2026',
    'source': '独立行政法人統計センター',
    'rows': len(df), 'cols': len(df.columns),
    'columns': {c: str(df[c].dtype) for c in df.columns[:5]},
}
print(json.dumps(meta, ensure_ascii=False, indent=2))

💬 行数 564・列数 112・先頭 5 列の型は、表そのものから数えたので正確だが、title と source は手で書いた文字列で、データからは検証されない（ここでは SSDSE の作成・公開元である独立行政法人統計センターを書いたが、誤記してもコードは気づかない）。columns に並ぶのは A1101 などのコードだけで、skiprows=[1] で読み飛ばした 2 行目の「総人口」といった日本語名こそが一番欲しいメタデータになっている。564 行が 47 都道府県 × 12 年度（2012〜2023）であることも、対象期間として記録しておきたい。

※ data/raw/SSDSE-B-2026.csv は 統計センターの SSDSE 配布ページ から取得した実データを想定。

🐍 Python ①：SSDSE-B-2026 のメタデータ自動プロファイリング

🎯 このコードでやること：pandas で SSDSE-B-2026 を読み込み、 各列の dtype・null 数・unique 数・最小最大・分位点を一度に算出してメタデータ辞書を作る。

📥 入力データ：data/raw/SSDSE-B-2026.csv (cp932, 564 行 × 112 列)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

import pandas as pd
import json
from pathlib import Path

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])

# データセット全体のメタデータ
ds_meta = {
    'title': 'SSDSE-B-2026',
    'publisher': '独立行政法人統計センター',
    'license': '政府標準利用規約 2.0',
    'encoding': 'Shift_JIS',
    'n_rows': len(df),
    'n_cols': len(df.columns),
    'dtype_counts': df.dtypes.astype(str).value_counts().to_dict(),
    'primary_keys': ['SSDSE-B-2026', 'Code'],
    'temporal_coverage': f"{df['SSDSE-B-2026'].min()} - {df['SSDSE-B-2026'].max()}",
    'spatial_coverage': f"{df['Prefecture'].nunique()} 都道府県",
}

# カラム別メタデータ
col_meta = {}
for c in df.columns:
    s = df[c]
    col_meta[c] = {
        'dtype': str(s.dtype),
        'null_count': int(s.isna().sum()),
        'null_rate': round(float(s.isna().mean()), 4),
        'unique_count': int(s.nunique()),
    }
    if pd.api.types.is_numeric_dtype(s):
        col_meta[c].update({
            'min': float(s.min()), 'max': float(s.max()),
            'mean': round(float(s.mean()), 2),
            'std':  round(float(s.std()),  2),
        })

print(json.dumps(ds_meta, ensure_ascii=False, indent=2))
print('\n--- 最初の 3 列のメタデータ ---')
for k in list(col_meta)[:3]:
    print(k, ':', col_meta[k])

📤 実行結果：

💬 結果の読み方：1 ファイルで 112 列ぶんの構造的メタデータを 30 行のコードで完全自動抽出 できた。 dtype 内訳 (int64=104, float64=6, object=2) や null 率 0、 unique 数から「年は 12 ユニーク、 県は 47 ユニーク」という主キー構造が即座に確認できる。

🐍 Python ②：schema.org Dataset の JSON-LD で出力

🎯 このコードでやること：①で作ったメタデータを schema.org Dataset 標準（Google Dataset Search で検索される形式）に変換し、 HTML に埋め込める JSON-LD として出力。

📥 入力データ：①で作った ds_meta 辞書。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

import json

jsonld = {
    '@context': 'https://schema.org',
    '@type': 'Dataset',
    'name': ds_meta['title'],
    'description': '47 都道府県 × 12 年 × 112 指標の縦持ち CSV データ。 教育用標準データセット。',
    'url': 'https://www.nstac.go.jp/use/literacy/ssdse/B/2026/',
    'identifier': 'SSDSE-B-2026',
    'license': 'https://www.digital.go.jp/resources/data_policy/',
    'creator': {
        '@type': 'Organization',
        'name': ds_meta['publisher'],
        'url': 'https://www.nstac.go.jp/',
    },
    'temporalCoverage': ds_meta['temporal_coverage'].replace(' - ', '/'),
    'spatialCoverage': {'@type': 'Place', 'name': 'Japan'},
    'distribution': [{
        '@type': 'DataDownload',
        'encodingFormat': 'text/csv',
        'contentUrl': 'data/raw/SSDSE-B-2026.csv',
    }],
    'variableMeasured': [
        {'@type': 'PropertyValue', 'name': 'A1101', 'description': '総人口', 'unitText': '人'},
        {'@type': 'PropertyValue', 'name': 'A1301', 'description': '15歳未満人口', 'unitText': '人'},
        {'@type': 'PropertyValue', 'name': 'A4101', 'description': '出生数', 'unitText': '人'},
    ],
}

print(json.dumps(jsonld, ensure_ascii=False, indent=2))

📤 実行結果（実測・後半は省略）：

💬 結果の読み方：この JSON-LD を <script type="application/ld+json"> として HTML の <head> に置けば、 Google Dataset Search に登録される。 公的データを公開するなら必須の作法。 schema.org 準拠で各種データカタログ（DataHub, CKAN）も自動取り込み可能。

🐍 Python ③：DCAT 準拠の RDF/Turtle 出力

🎯 このコードでやること：同じメタデータを W3C DCAT（データカタログ語彙）の RDF/Turtle 形式で出力。 政府オープンデータの標準語彙。

📥 入力データ：ds_meta 辞書（① で作成）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

turtle = f"""@prefix dcat:    <http://www.w3.org/ns/dcat#> .
@prefix dct:     <http://purl.org/dc/terms/> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .
@prefix foaf:    <http://xmlns.com/foaf/0.1/> .

<https://www.nstac.go.jp/ssdse/B/2026> a dcat:Dataset ;
    dct:title       "{ds_meta['title']}"@ja ;
    dct:description "47 都道府県 × 12 年 × 112 指標の縦持ち CSV"@ja ;
    dct:issued      "2026-03-01"^^xsd:date ;
    dct:publisher   <https://www.nstac.go.jp/> ;
    dct:license     <https://www.digital.go.jp/resources/data_policy/> ;
    dct:temporal    [ a dct:PeriodOfTime ;
                      dcat:startDate "2012-01-01"^^xsd:date ;
                      dcat:endDate   "2023-12-31"^^xsd:date ] ;
    dct:spatial     <http://www.geonames.org/1861060/> ;
    dcat:theme      "統計" ;
    dcat:keyword    "都道府県", "人口", "経済", "教育" ;
    dcat:distribution [ a dcat:Distribution ;
                        dcat:downloadURL <data/raw/SSDSE-B-2026.csv> ;
                        dcat:mediaType   "text/csv" ;
                        dcat:byteSize    {ds_meta['n_rows'] * ds_meta['n_cols'] * 8} ] .
"""
print(turtle)

📤 実行結果（実測）：

💬 結果の読み方：DCAT/Turtle 形式は欧州 EU Open Data Portal や日本のデジタル庁が採用する 政府オープンデータの正式語彙。 RDF Triple Store にロードすれば SPARQL で「ライセンスが CC BY のデータセット一覧」「2020 年以降に公開されたデータ」など複雑検索可能。 byteSize は粗い見積もり（n_rows × n_cols × 8 byte）。

🐍 Python ④：メタデータの整合性検証

🎯 このコードでやること：データセットの「期待されるメタデータ」（スキーマ定義）と実データから抽出した実値を比較し、 不一致を検出する。 CI/CD で「データの形が変わったら即アラート」する用途。

📥 入力データ：期待スキーマ（YAML 風 dict）と実 DataFrame。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

expected = {
    'n_cols': 112,
    'min_rows': 500,
    'primary_keys': ['SSDSE-B-2026', 'Code'],
    'required_cols': {
        'SSDSE-B-2026': 'int64',
        'Code': 'object',
        'Prefecture': 'object',
        'A1101': 'int64',
        'A1301': 'int64',
    },
    'value_ranges': {
        'SSDSE-B-2026': (2010, 2030),
        'A1101': (100000, 20000000),  # 人口は 10 万〜2000 万
    },
}

errors = []
if len(df.columns) != expected['n_cols']:
    errors.append(f"列数不一致: 期待 {expected['n_cols']}, 実際 {len(df.columns)}")
if len(df) < expected['min_rows']:
    errors.append(f"行数不足: 期待 ≥ {expected['min_rows']}, 実際 {len(df)}")

for pk in expected['primary_keys']:
    if pk not in df.columns:
        errors.append(f"主キー欠落: {pk}")

for col, dt in expected['required_cols'].items():
    if col not in df.columns:
        errors.append(f"必須列欠落: {col}")
    elif str(df[col].dtype) != dt:
        errors.append(f"型不一致 {col}: 期待 {dt}, 実際 {df[col].dtype}")

for col, (lo, hi) in expected['value_ranges'].items():
    if col in df.columns:
        if df[col].min() < lo or df[col].max() > hi:
            errors.append(f"値域外 {col}: [{df[col].min()}, {df[col].max()}] not in [{lo}, {hi}]")

print(f'検証エラー数: {len(errors)}')
for e in errors:
    print('  ', e)
print('OK' if not errors else 'NG')

📤 実行結果：

💬 結果の読み方：SSDSE-B-2026 は期待スキーマを完全に満たしている（列数 112、 行数 564 ≥ 500、 主キー存在、 必須列の型一致、 人口値域内）。 実務ではこの検証を 毎日のデータパイプライン に組み込み、 「データ提供元が形式変更」「列名タイポ」「異常値混入」を CI で即検出する。 専用ライブラリ：pandera, great-expectations, dbt tests。

🐍 Python ⑤：YAML 形式で人間にも機械にも読める出力

🎯 このコードでやること：JSON は機械可読だが人間には読みにくい。 YAML 形式で出力すれば、 Git で diff も取りやすく、 README に貼り付けやすい。

📥 入力データ：①〜② で作成したメタデータ辞書。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

import yaml

dataset_yaml = {
    'dataset': {
        'name': 'SSDSE-B-2026',
        'version': '2026.0',
        'publisher': '独立行政法人統計センター',
        'license': '政府標準利用規約 2.0',
        'created': '2026-03-01',
        'shape': {'rows': 564, 'cols': 112},
        'keys': ['SSDSE-B-2026', 'Code'],
        'temporal': {'start': 2012, 'end': 2023},
        'spatial': '47 都道府県 (日本)',
    },
    'columns': [
        {'name': 'SSDSE-B-2026', 'type': 'int', 'unit': '年',
         'description': '観測年（西暦）', 'pk': True},
        {'name': 'Code', 'type': 'string', 'pattern': '^R[0-4][0-9]000$',
         'description': '都道府県コード (JIS X 0401)', 'pk': True},
        {'name': 'Prefecture', 'type': 'string',
         'description': '都道府県名（日本語）'},
        {'name': 'A1101', 'type': 'int', 'unit': '人',
         'description': '総人口（住民基本台帳）'},
        {'name': 'A1301', 'type': 'int', 'unit': '人',
         'description': '15歳未満人口（住民基本台帳）'},
        {'name': 'A4101', 'type': 'int', 'unit': '人',
         'description': '出生数（人口動態調査）'},
    ],
    'quality': {
        'completeness': '全列 null 率 0%',
        'consistency': '12 年 × 47 県 = 564 行で完備',
        'last_validated': '2026-05-24',
    },
}

print(yaml.dump(dataset_yaml, allow_unicode=True, sort_keys=False,
                default_flow_style=False, indent=2))

📤 実行結果：

💬 結果の読み方：YAML は dbt, great-expectations, OpenAPI, Kubernetes など多くのモダンツールで採用される設定形式。 git で行単位 diff が取れるため、 「いつ・誰が・どの列定義を変えたか」が履歴で追跡できる。 メタデータ管理 ≒ コードレビューになる。

🐍 Python ⑥：ydata-profiling 相当の自動レポート

🎯 このコードでやること：ydata-profiling と同じ「自動データプロファイル HTML レポート生成」を、 標準ライブラリだけで簡易再現。 各列の分布、 欠損、 警告を一気に出す。

📥 入力データ：DataFrame df (564 行 × 112 列)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

import pandas as pd

def profile(df, name='Dataset'):
    report = [f'# Data Profile Report: {name}']
    report.append(f'- shape: {df.shape}')
    report.append(f'- memory: {df.memory_usage(deep=True).sum() / 1024:.1f} KB')

    # 警告
    warnings = []
    for c in df.columns:
        s = df[c]
        if s.isna().mean() > 0.1:
            warnings.append(f'{c}: 欠損率 {s.isna().mean():.0%}')
        if pd.api.types.is_numeric_dtype(s) and s.nunique() == 1:
            warnings.append(f'{c}: 定数列（unique=1）')
        if pd.api.types.is_object_dtype(s) and s.nunique() == len(df):
            warnings.append(f'{c}: 全てユニーク（ID 列？）')

    report.append(f'\n## 警告 ({len(warnings)} 件)')
    for w in warnings[:5]:
        report.append(f'  - {w}')

    # 数値列サマリ
    num_cols = df.select_dtypes(include='number').columns
    report.append(f'\n## 数値列 ({len(num_cols)} 列) サマリ')
    desc = df[num_cols].describe().T[['mean','std','min','max']]
    report.append(desc.head(5).round(2).to_string())

    return '\n'.join(report)

print(profile(df, 'SSDSE-B-2026'))

📤 実行結果：

💬 結果の読み方：警告 0 件 = データ品質が極めて高い（欠損なし・定数列なし・ID 重複なし）。 これは SSDSE が「教育用」として整備された結果。 実務データではこのレポートで 30〜100 件の警告が出るのが普通で、 各警告をひとつずつ潰すのが前処理の第一歩。

📊 メタデータの粒度 4 階層

同じ「メタデータ」でも、 対象とする粒度で 4 階層に分けて整理すると見通しが良くなる。

①〜② は 必須。 ③〜④ は「データの素性まで追跡したい」場合に追加する。 公的統計や医療データでは ④ まで揃えるのが理想。

📜 セルフテスト：メタデータ理解度

1. メタデータの 3 種類は？（答：記述的、 構造的、 管理的）
2. Dublin Core の要素数は？（答：15）
3. FAIR 原則の 4 つを挙げる（答：Findable, Accessible, Interoperable, Reusable）
4. schema.org Dataset を HTML に埋め込む形式は？（答：JSON-LD）
5. 政府オープンデータの標準語彙は？（答：DCAT）
6. 地理空間メタデータの ISO 標準は？（答：ISO 19115）
7. OSS データカタログを 3 つ挙げる（答：DataHub, OpenMetadata, Amundsen, Atlas, CKAN ほか）
8. Python でメタデータ自動生成するライブラリは？（答：ydata-profiling, pandera, great-expectations）
9. SSDSE-B-2026 のエンコーディングは？（答：Shift_JIS = cp932）
10. メタデータの「陳腐化」を防ぐ仕組みは？（答：自動更新パイプライン、 CI 検証）

10 問中 7 問以上を即答できれば、 メタデータの基礎は確実に身についている。 残りは関連用語ページで補完できる。

📊 公的統計データ別メタデータ整備状況

→ 「データ取得 → メタデータ確認」の手順は 必ず必要。 e-Stat や OECD はメタデータ API が整備されているので、 データ取得時にメタデータも併取得するスクリプトを書くのが定石。

🛠 メタデータ運用ベストプラクティス 10 選

1. 1 リポ 1 データセット 1 README：データの隣に必ずメタデータ README を置く。 Git で履歴管理。
2. 標準語彙を採用：自作辞書ではなく Dublin Core / DCAT / schema.org を使う。 横断検索可能になる。
3. 自動生成を優先：手書きメタデータは陳腐化する。 ydata-profiling 等で「データから自動抽出」する部分を最大化。
4. CI に検証を組み込む：great-expectations でスキーマ検証、 メタデータ不整合は PR 段階で検知。
5. 意味的メタデータは人手：「この列が何を意味するか」は自動化できない。 ドメイン専門家が記述。
6. ライセンスは必ず明記：データ自身のライセンスと、 メタデータのライセンスを別建てで明記（CC0 推奨）。
7. 言語タグを使う：多言語の場合は "title"@ja, "title"@en のように IETF BCP 47 タグ。
8. バージョニング：データもメタデータも SemVer。 破壊的変更（列削除等）はメジャー番号上げ。
9. リネージ追跡：データ A → 加工 → データ B の系譜を記録。 dbt, DataHub が自動化。
10. 定期的に「メタデータ棚卸し」：四半期に一度、 全データセットのメタデータを点検。 古いものは削除 or アーカイブ。

⚠️ よくある落とし穴

⚠️ 深いメタデータの落とし穴

🌐 関連手法・派生・バリエーション

• Dublin Core／DCAT／schema.org／ISO 19115（地理）／FAIR原則／データカタログ

🌐 データカタログ製品の比較

🌐 メタデータ管理の進化史

🔗 関連用語（前提・並列・発展）

メタデータは「データを語るデータ」。 構造化データ・スキーマ・前処理と密接にリンクし、 データ品質と再現性の土台を支える。 以下を 3 区分で押さえる。

🧭 前提（先に押さえる基礎）

• CSV — 最も基本的な構造化フォーマット。 ヘッダ行がメタデータの一部。
• DataFrame — pandas の列名・dtype がインメモリのメタデータ。
• カテゴリ変数 — 取り得る水準のリストがメタデータとして必要。
• データクレンジング — メタデータが整っていないと品質評価・修復ができない。

↔ 並列（同列で対比すべき概念）

• JSON — 自己記述的なデータ表現。 構造そのものがメタデータを内包。
• スプレッドシート — メタデータ管理が弱い（コメント・色など非構造化）。
• 非構造化データ — メタデータの自動付与（タグ・キャプション）が課題。
• アノテーション — ラベル付け = メタデータ生成の典型例。

🚀 発展（応用・拡張）

• 📚 データエンジニアリング — メタデータ管理（Data Catalog, Lineage）を含む上位分野。
• Hadoop — 分散ファイルシステムでのメタデータ管理（NameNode）。
• ビッグデータ — 大規模化でメタデータカタログの重要性が増す。
• 再現性危機 — メタデータ（バージョン・乱数 seed）の欠落が再現性問題の核心。
• データガバナンス — 組織レベルでのメタデータ運用ルール。

🧪 FAIR 原則：メタデータが支える 4 つの柱

FAIR の 4 原則すべてを支えるのが メタデータ。 「データはあるのに使われない」のは、 ほぼ間違いなくメタデータ不足が原因。

🔭 実務 FAQ

📚 関連グループ教材

📚 メタデータを軸にたどる関連教材

メタデータは単独で学ぶより、 「データをどこに置き、 どう流し、 誰が責任を持つか」を扱うデータエンジニアリングの教材群の中で読むと位置づけがはっきりする。 このページの 5 階層（技術・スキーマ・ビジネス・運用・系譜）ごとに、 続けて読むページを挙げる。

• 技術・スキーマ階層：CSV（ヘッダ行と文字コードが最小のメタデータ。 SSDSE-B-2026 は cp932 で 2 行目が日本語の列名）、 JSON（型と構造を自分で記述する形式。 本ページの JSON-LD 出力の土台）
• ビジネス階層：データクレンジング（単位・定義が分からないと、 どの値が誤りかを判定できない）、 オープンデータ（出典・ライセンス・更新日が揃って初めて再利用できる）
• 運用・系譜階層：ETL・データウェアハウス・データレイク（どこから来てどう加工された値かを記録する場所）、 データエンジニアリング（これらをまとめた上位分野）
• 組織の階層：データガバナンス（メタデータを誰が書き、 誰が承認するかのルール）、 ナレッジグラフ（セマンティック階層を関係のネットワークとして表す）

🗂 スキーマ・リネージ・データカタログ — SSDSE-B-2026 のメタデータを取り出す

メタデータの 3 大要素は (1) スキーマ (columns/dtypes/PK)、 (2) リネージ (どこから来たか)、 (3) ビジネス用語との対応 (data catalog)。 ここでは SSDSE-B-2026 の生 CSV から pandas で機械可読なメタデータを抽出し、 great_expectations 風の制約を JSON で書き起こす流れを示す。 これは metadata 用語固有の手順で、 他用語ページのコードでは扱わない。

🎯 このコードでやること

SSDSE-B-2026 を読み込み、 各列の (1) 物理メタデータ (dtype, null 率, 値域) と (2) ビジネスメタデータ (日本語名 = 2 行目のヘッダ) を結合して、 「列カタログ」を生成する。 さらに「年度は 2012..2023」「地域コードは R + 5 桁（R01000..R47000）」「総人口は 1 以上」など期待値を JSON で出力する。

📥 入力データ (SSDSE-B-2026 抜粋、 2 行目に日本語ヘッダ)

🐍 Python 実装

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

import json
import pandas as pd

# 1 行目を英語列名、 2 行目を日本語ビジネス名として保持
raw = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', header=0)
business_names = raw.iloc[0].to_dict()        # {'A1101': '総人口', ...}
df = raw.iloc[1:].reset_index(drop=True)
# 数値カラムを推定（errors='ignore' は将来の pandas で廃止されるので使わない）
for c in df.columns:
    conv = pd.to_numeric(df[c], errors='coerce')
    if conv.notna().all():
        df[c] = conv

# 列カタログ生成
catalog = []
for c in df.columns:
    col = df[c]
    catalog.append({
        'physical_name': c,
        'business_name': business_names.get(c, ''),
        'dtype':         str(col.dtype),
        'null_ratio':    round(col.isna().mean(), 4),
        'n_unique':      int(col.nunique()),
        'min':           str(col.min()),
        'max':           str(col.max()),
    })

print(json.dumps(catalog[:3], ensure_ascii=False, indent=2))

# Great Expectations 風の制約
expectations = {
    'year':       {'between': [2012, 2023]},
    'code':       {'regex':   r'^R\d{5}$'},
    'A1101':      {'min': 1,  'business_name': '総人口', 'unit': '人'},
}
print(json.dumps(expectations, ensure_ascii=False, indent=2))

📤 実行例

💬 結果の読み方

• 物理メタデータ (dtype, null 率) とビジネス名 (人口, 年度) が結合された「列カタログ」が機械可読 JSON として吐き出される — これがデータカタログの最小構成。
• expectations は再現性のあるデータ品質契約。 great_expectations / pandera / dbt tests でそのまま実行できる形式。
• リネージは「SSDSE-B-2026.csv → (この notebook) → catalog.json」と矢印で残す。 元 URL (e-Stat) と取得日も JSON に持たせると監査可能になる。
• このメタデータがあると、 後段の分析者は「人口列の意味」「期待値域」「変更履歴」をコードを読まずに把握できる。 用語 metadata の存在意義そのもの。

🧮 メタデータ駆動の品質チェック (数式を言葉で読み解く)

期待値違反率を $$\text{violation\_rate} = \frac{1}{N}\sum_{i=1}^{N} \mathbb{1}[\,x_i \notin \mathcal{E}\,]$$ と定義する。 $\mathcal{E}$ は expectations で定めた集合 (例: year は 2012..2023)、 $\mathbb{1}[\cdot]$ は条件が真なら 1、 偽なら 0 を返す指示関数。 SSDSE-B-2026 では year 列に対し全 564 件が範囲内 → 違反率 0.000、 メタデータ契約が満たされている。

🗂 メタデータの 5 階層モデルを SSDSE-B-2026 で実装する

メタデータは単に「データを説明するデータ」ではなく、 役割と粒度の異なる 5 階層に分解して管理されるのが実務の標準である。 SSDSE-B-2026 (独立行政法人統計センターが公的統計から作成した都道府県別社会・経済データ、 47 都道府県 × 12 年度 = 564 行、 112 列) を題材に、 各階層が「具体的に何を記録するのか」「無いとどんな問題が起きるのか」を一覧化する。 これが揃わない限り、 後段の分析者は「この列は何を意味するのか」をコードや値の分布から推測する羽目になる。

📐 階層間の依存関係 (DAG)

[技術] ファイル存在 → [スキーマ] 列が読める → [ビジネス] 意味が分かる
                                           ↓
                       [運用] 鮮度を保証 → [系譜] 再現性を保証
                                           ↓
                               [セマンティック] 統合可能性
  

下位 (技術) が崩れると上位 (セマンティック) は全て無効になる。 例えば SSDSE-B-2026.csv のハッシュが変わったまま気付かなければ、 「人口」列に旧データが混ざり、 業務メタデータが嘘になる。 そのため 下位階層から順にチェックする pipeline を組むのが正解で、 great_expectations や dbt がこの順序を強制する。

⚖️ 階層別に「どこに保存するか」のベストプラクティス

このコードでやること: SSDSE-B-2026 を読み、 上記 5 階層を一括で抽出して catalog/metadata.json に書き出す。 ファイルのハッシュ・列の dtype と欠損の有無・業務名・更新頻度・系譜を 1 ファイルにまとめる「最小メタデータカタログ」の実装例。

📥 入力 (SSDSE-B-2026 抜粋):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

import pandas as pd, hashlib, json, datetime, pathlib
src = pathlib.Path('data/raw/SSDSE-B-2026.csv')
# 英字の項目コードを見出しにするので、2 行目（日本語名）を読み飛ばす
df_meta = pd.read_csv(src, encoding='cp932', skiprows=[1])
catalog = {
  'technical': {
    'filename': src.name,
    'encoding': 'cp932',
    'rows': len(df_meta),
    'cols': df_meta.shape[1],
    'sha256': hashlib.sha256(src.read_bytes()).hexdigest()[:16],
  },
  'schema': {c: {'dtype': str(df_meta[c].dtype),
                 'nullable': bool(df_meta[c].isna().any())}
             for c in ['A1101', 'A1303']},
  'business': {'A1101': '総人口 (10/1 現在、 人)',
               'A1303': '65歳以上人口 (10/1 現在、 人)'},
  'operational': {'frequency': 'yearly',
                  'last_updated': '2026-03-25',
                  'sla': '翌年 4 月末'},
  'lineage': ['e-Stat', 'download_ssdse.py', str(src)],
  'semantic': {'A1101': {'concept': 'Population',
                          'parent': 'Demographics'}},
}
pathlib.Path('catalog').mkdir(exist_ok=True)   # 保存先が無いと書けない
pathlib.Path('catalog/metadata.json').write_text(
    json.dumps(catalog, ensure_ascii=False, indent=2))
print(json.dumps(catalog['technical'], ensure_ascii=False, indent=2))

📤 実行例:

💬 表示しているのは技術層だけで、564 行・112 列・SHA-256 先頭 16 桁 0fdbe5f603bb8e1e が記録された。CSV が 1 バイトでも差し替わればこのハッシュが変わるので、「同じファイルを分析したか」を後から照合できる。スキーマ層は A1101 と A1303 の 2 列ぶんしか書いておらず、期待値域（range）もまだ入っていないので、残り 110 列と値域を埋めていくのが次の作業になる。

📊 SSDSE-B-2026 全列のメタデータ充足率を測定する

「メタデータがある」と「メタデータが十分」は別問題で、 実務では 充足率 (coverage) を KPI として測る。 SSDSE-B-2026 の 112 列について、 各メタデータ階層で「記録済み」と判定された列の割合を測定する仕組みを示す。 これがあれば「データカタログ整備プロジェクト」を定量的に管理できる。

📐 充足率の定義

階層 $l$ における充足率 $C_l$ を $$C_l = \frac{|\,\{c \in \text{Columns} \mid m_l(c) \neq \emptyset\}\,|}{|\text{Columns}|}$$ と定義する。 $m_l(c)$ は列 $c$ に対して階層 $l$ のメタデータが「空でない値で」登録されているかを表す。 例えば SSDSE-B-2026 の 112 列について「ビジネス名 (日本語の業務名称)」が記録された列が 101 列なら、 ビジネス充足率は $101/112 = 0.902$。

📋 充足率テーブルの記入例 (SSDSE-B-2026 の 112 列を対象にした場合)

⚠️ 下の表は「こう書く」という記入例です。 分母の 112 は SSDSE-B-2026 の実際の列数ですが、 各階層の充足列数はカタログ整備の途中経過を想定した仮の値で、 このページのコードから自動生成したものではありません。 自分のデータで測るときは、 次のコードのように catalog/metadata.json を実際に読んで数えてください。

「期待値域」が 47.3% しか埋まっていないのが最大のボトルネック。 ここを埋めれば great_expectations の自動チェックが大幅に効くようになる。 メタデータ整備プロジェクトはこの「充足率テーブル」を毎週更新するのが定石で、 進捗が一目で分かる。

このコードでやること: 上記の充足率テーブルを実際に計算する。 metadata.json の各階層キーが「空でない」列を数え、 全列数で割って coverage を出力する。 業務ダッシュボードに毎日載せる KPI として直接使える。

📥 入力 (catalog/metadata.json の構造例):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

import os
os.makedirs('catalog', exist_ok=True)  # 保存先のフォルダを作っておく

import json, pandas as pd
catalog = json.loads(open('catalog/metadata.json').read())
cols = catalog['columns']
fields = ['business', 'unit', 'source', 'range', 'lineage', 'concept', 'updated']
rows = []
for f in fields:
    filled = sum(1 for c in cols.values()
                 if c.get(f) not in (None, '', [], {}))
    rows.append({'階層': f,
                 '充足列': filled,
                 '全列': len(cols),
                 '充足率': f'{filled/len(cols):.1%}'})
report = pd.DataFrame(rows)
report.to_csv('catalog/coverage_kpi.csv', index=False)
print(report.to_string(index=False))

📤 出力の形（上の記入例の値を metadata.json に入れた場合。112 列）:

💬 充足率 KPI を毎週 plot すると、 メタデータ整備の進捗が経営層にも伝わる形になる。 「期待値域 47.3%（53/112 列）→ 90% へ」のような数値目標が立てられるのが、 メタデータを定量管理するメリット。 great_expectations や Soda Core もこの充足率を自動測定する機能を持つ。

📈 充足率の段階別運用 (DataOps 成熟度)

SSDSE-B-2026 は階層によって L2 〜 L4 が混在している状態で、 「期待値域」と「セマンティック」を L4 まで引き上げるのが次の目標。 これがメタデータ整備の現場で実際に起きている意思決定であり、 用語ページが教えるべき本質的なリアルである。

🔍 メタデータ理解度チェック (10 問) と現場 FAQ

用語の理解は「説明できる」ではなく「判断できる」が到達点。 以下 10 問は実務で頻出する判断場面を切り出したもので、 全問正解できるなら「メタデータ設計をリードできる」レベル。 SSDSE-B-2026 を題材にした具体問で、 抽象論ではなく操作可能な理解を確認する。

❓ 現場でよく出る FAQ

🖼 メタデータ階層モデルの可視化 (3 図)

本ページの議論を 3 枚の図に集約する。 図 1 は階層モデルの全体像、 図 2 は SSDSE-B-2026 112 列の充足率（記入例）、 図 3 は DataOps 成熟度の段階遷移マップ。 それぞれ別途 PNG として書き出し、 用語ページに直接埋め込んで意味の理解を助ける。

図 1: 5 階層は下位から上位への依存関係を持つ。 下層が崩れると上層は全て信頼できなくなる。

図 2: Range と Semantic が低い。 ここを 90% まで持ち上げるのが当面の整備目標。

図 3: 階層ごとに DataOps 成熟度が異なる現実。 SSDSE-B-2026 は技術階層 L4・期待値域 L2 と凸凹がある。

🛠 次のアクション

1. SSDSE-B-2026.csv をダウンロードして、 本ページのコードで catalog/metadata.json を実際に生成する。 sha256 と充足率が手元で再現できれば、 メタデータ階層モデルを実装したことになる。
2. great_expectations を導入し、 catalog の expectations セクションを great_expectations.yml に変換する。 充足率「期待値域 47.3%」を 80% まで引き上げる目標を立てる。
3. OpenLineage 仕様で lineage を JSON に出力し、 Marquez サーバに送信する。 これで「どの notebook がどの output を生んだか」が GUI で追跡可能になる。
4. DataHub / Amundsen / OpenMetadata のいずれかを docker compose で立ち上げ、 catalog.json を取り込む。 SSDSE-B-2026 の 112 列がブラウザで検索できるようになる。
5. data contract (data-contract-spec.org) の形式で データガバナンス ページの管理プロセスに統合する。 これで データ品質 や tidy データ の活動全体が「メタデータ駆動」になる。

関連用語: データガバナンス (組織体制)、 データ品質 (検査結果)、 tidy データ (構造化前提)、 データベース (永続化先)、 構造化データ (対象データ)、 外部キー (関係性メタデータ)、 一次データ (一次資料)、 データクレンジング (前処理段階)、 データリテラシー (利用者側スキル)、 データ利活用 (活用段階)、 PPDAC サイクル (分析プロセス)、 説明責任 (説明責任)、 透明性 (透明性)、 著作権 (権利情報)、 誤情報 (誤情報防止)。

📑 メタデータ標準仕様の俯瞰 (どの規格をいつ使うか)

メタデータには国際的・業界的な複数の標準仕様が存在し、 用途ごとに使い分けるのが実務の知恵である。 SSDSE-B-2026 のように政府統計を扱う場合、 公的データならではの規格 (DDI、 SDMX) も視野に入る。 主要な標準を整理する。

SSDSE-B-2026 の現実的な構成では、 「DCAT + pandera + OpenLineage + data contract」の 4 点セットが最もコスト対効果が高い。 DCAT で公開メタデータを表現し、 pandera で機械検査し、 OpenLineage で系譜を記録し、 data contract で内部の producer-consumer 契約を結ぶ。 DDI は研究機関向け、 SDMX は時系列が主流のドメイン向けと考えれば良い。 これらは互いに排他ではなく、 同じメタデータカタログから別形式で書き出すのが実装の定石になっている。

用語ページとしての結論: メタデータは「あれば良い」ではなく「無いと回らない」インフラである。 SSDSE-B-2026 のような小規模・公開データでも 5 階層モデルが効き、 充足率という KPI で管理でき、 標準規格で記述できる。 これが現代のデータサイエンスにおけるメタデータの位置付け。 用語の正確な理解は、 こうした多層的な構造とその運用を含めて初めて完成する。

補足として、 メタデータと「データそのもの」の境界は実は曖昧で、 状況によって入れ替わる。 たとえば SSDSE-B-2026 の「年次」列は普段はデータ本体だが、 「2012 年度から 2023 年度まで毎年分がそろっている」という情報を要約する文脈ではメタデータとして振る舞う。 同様に列名 A1101 もデータベースの行としてカタログに格納された瞬間にデータになる。 この相対性を理解しておくと、 「データカタログ自身のメタデータ (catalog of catalogs)」のような上位の抽象も扱えるようになり、 federated data governance などの先端トピックに繋がる。 メタデータ概念は階層的・再帰的な性質を持ち、 その認識が現場の柔軟な設計判断を可能にする。

最後に、 メタデータ整備が文化として根付くには、 単に技術導入だけでなく「列を追加するときは必ず meaning と unit を書く」というレビュー慣行が必要である。 SSDSE-B-2026 のような公的データは統計官の長年の蓄積で自然に達成されているが、 社内データでは PR テンプレートにメタデータ欄を組み込むなどの工夫が要る。 技術 (great_expectations) と運用文化 (PR レビュー) と組織体制 (データスチュワード制度) の三位一体が、 メタデータを生きた状態で保つ。 本ページの内容が、 読者の現場での実装と運用の出発点となることを期待する。

付記として、 メタデータ整備は「一度作って終わり」ではない。 SSDSE-B-2026 が毎年改訂されるように、 メタデータカタログ自体にもバージョン管理 (例: catalog/v2026.json と catalog/v2027.json) が必要になる。 git で履歴を残し、 過去の解釈に立ち返れるようにする。 「2024 年時点では A1101 が住民基本台帳ベースだったが、 2026 年から国勢調査ベースに変更された」のような変遷を辿れる状態こそ、 真に運用可能なメタデータ管理の到達点である。 これがメタデータの完成形であり、 用語の最終的な意味でもある。 加えて、 SSDSE-B-2026 のような長期改訂データでは、 年度ごとの差分を YAML diff として記録する運用が、 ガバナンスの最重要要件となる。

🏛 メタデータ標準仕様の徹底比較 — Dublin Core / DCAT / schema.org / DataCite / ISO 19115 / FGDC / DDI / PROV-O

メタデータを「現場ごとに勝手なキーで書く」と、 ２年後にデータセットが組織横断で再利用できなくなる。 国際的に流通している標準語彙を「目的」「対象ドメイン」「必須要素数」「採用例」で比較し、 SSDSE-B-2026 のような公的統計データに対してどれを採用すべきかを意思決定できる粒度でまとめる。 ここに挙げる 8 規格はいずれも RDF / JSON-LD で表現可能で、 機械可読性とリンクトデータとしての連結性を担保している。 単なる項目羅列ではなく、 各規格が解こうとしている課題（学術論文の引用か、 政府オープンデータの横串検索か、 地理空間メタデータの相互運用か）を読み取れるようにする。

公的統計の世界では、 統計局が公表する CSV ファイルの「題名」「公表時期」「単位」「対象期間」「精度」をどう表現するかが長年議論されてきた。 単に「データ名: SSDSE-B-2026」と書くだけでは、 隣接する SSDSE-C-2026 や SSDSE-D-2026 との関係、 改訂履歴、 県別の集計粒度、 都道府県コードの参照系（JIS X 0401）といった文脈が完全に失われる。 標準語彙は、 こうした文脈情報を「同じキー」「同じ値域」で記述するための合意書である。 規格を選ぶときに最も重要なのは「自分のデータが世界中の他のデータと並んだとき、 検索エンジンが拾える形になっているか」という観点である。 schema.org/Dataset は Google Dataset Search のクロール対象であり、 DCAT は EU Open Data Portal や data.gov の必須仕様である。 つまり「どの目録に載せたいか」が規格選択の出発点になる。

SSDSE-B-2026 のような都道府県別パネルデータを公開する場合、 まず DCAT 3.0 で「Dataset 単位」を記述し、 schema.org/Dataset を JSON-LD で同梱して Google Dataset Search にインデックスさせ、 内部の 130 変数は DDI Codebook で変数辞書を作成、 都道府県名と JIS コードの対応は ISO 19115 lite で空間メタデータを付け、 ETL の加工履歴は PROV-O で来歴を記録する、 という「重ね書き」が実務上のベストプラクティスである。 単一規格で全てを賄おうとすると必ず破綻するため、 「目的別レイヤ構造」を採用するのが鉄則である。

DCAT 3.0 では、 dcat:Catalog が複数の dcat:Dataset を持ち、 各 Dataset が複数の dcat:Distribution (CSV / JSON / Parquet 等のフォーマット別配信単位) を持つ。 この 3 階層モデルは、 例えば SSDSE-B-2026 が「2014 年版から 2026 年版まで」のシリーズ全体を Catalog として表現し、 各年版を Dataset、 各年版の CSV / Excel / PDF を Distribution として枝分かれさせられる、 という意味で公的統計の構造に極めて適合する。 これに対して schema.org/Dataset はフラットな構造のため、 シリーズ表現には isPartOf プロパティを使った相互参照が必要になる。

実装の落とし穴として最も多いのが「DCAT と schema.org を別ファイルで管理してしまい、 一方を更新したらもう一方が古くなる」というケース。 これを避けるには、 内部表現は DCAT (RDF Turtle / JSON-LD) に統一し、 schema.org/Dataset 形式は DCAT からの「派生ビュー」として SHACL ルールで自動生成する設計が望ましい。 W3C の DCAT-AP (Application Profile) や日本の DCAT-jp は、 こうした派生ルールを明文化したサブセット仕様であり、 政府機関の場合は最初から DCAT-AP を採用することで「将来の data.europa.eu や data.go.jp との連邦検索」に対応できる。

学術研究データの場合は DataCite が最重要である。 論文に添付したデータセットに DOI を付与する世界標準であり、 Zenodo / Figshare / Dryad などのリポジトリは全て DataCite Metadata Schema を採用している。 DataCite では relatedIdentifier プロパティを使って「この論文の Figure 3 を生成したデータセット」「この論文を再現するためのコード」といった関係を IsSupplementTo / IsDerivedFrom / IsCitedBy などの語彙で表現する。 SSDSE-B-2026 を使った研究論文を発表する場合、 二次データセットを Zenodo にアップロードし、 SSDSE-B-2026 を IsDerivedFrom で参照しておくと、 再現性が劇的に向上する。

ISO 19115 系の地理空間メタデータは、 SSDSE-B-2026 を国土地理院の都道府県境界データと結合して「地図に色を塗る」用途で必須となる。 ISO 19115 lite は MD_Metadata / MD_DataIdentification / MD_ReferenceSystem を中心に、 投影座標系（JGD2011）・分解能（市町村単位）・空間範囲（北緯 24-46 度、 東経 122-149 度）を機械可読に記述する。 GIS 系ツール (QGIS / ArcGIS / GeoServer) はこのメタデータを読み込んで地図投影を自動設定するため、 メタデータが欠けていると「地図が世界の真ん中に描画される」「都道府県境界がずれる」といった事故が起きる。 メタデータは「面倒な事務作業」ではなく「自動化を可能にするインフラ」だと理解することが重要である。

PROV-O は、 メタデータの中でも「加工履歴 (provenance)」を専門に扱う。 Activity (加工処理)、 Agent (実行者)、 Entity (データ) の 3 クラスで、 「誰が」「いつ」「どのデータから」「何を生成したか」を有向グラフで記述する。 ETL パイプラインで前段の SSDSE-B-2026 から欠損補完済みデータセットを作る際、 PROV-O で prov:wasGeneratedBy / prov:wasDerivedFrom / prov:wasAttributedTo を記録しておくと、 後から「この欠損補完値は誰が、 どのアルゴリズムで、 何時何分に生成したか」が完全に追跡可能になる。 これは AI 監査・GDPR 第 22 条の自動意思決定説明義務・EU AI Act の高リスク AI 文書化義務に直結する重要要件である。

🛠 データカタログ製品の機能徹底比較 — DataHub / Amundsen / OpenMetadata / Atlas / Marquez / Collibra / Alation / Informatica EDC

「メタデータを書いた」だけでは現場の検索体験は改善しない。 検索 UI・lineage 可視化・タグ管理・PII 自動検出・GitHub 連携・Slack 通知などをまとめて提供する「データカタログ製品」が必要になる。 OSS / 商用合わせて 20 を超える選択肢があり、 規模・予算・自社のクラウド戦略によって最適解が変わる。 ここでは代表的な 8 製品について、 機能・スケール特性・運用コスト・SSDSE-B-2026 のような行政公開データを掲載する場合の適合度を比較する。

予算ゼロで始めるなら DataHub / OpenMetadata / Amundsen の 3 択になる。 DataHub は GraphQL API が強力で大規模組織での横展開に強いが、 初期セットアップに Kafka / Zookeeper / Elasticsearch / MySQL / Neo4j の 5 種類のミドルウェアが必要で、 docker compose では 16 GB RAM 程度が必要になる。 OpenMetadata は Airflow を内蔵する代わりにアーキテクチャがシンプルで、 docker compose で 8 GB RAM でも動作する。 Amundsen は最もシンプルだが、 機能拡張に若干の制約がある。 SSDSE-B-2026 単体だけならどれでも十分だが、 「将来 e-Stat 全体を取り込みたい」というスケール志向なら DataHub、 「すぐに使い始めたい」なら OpenMetadata が現実解である。

商用ツールを選ぶ理由は主に 3 つある。 (1) 業務部門のユーザが SQL を書かずに glossary を整備したい、 (2) SOC 2 / ISO 27001 の取得が必要で自社運用がリスク、 (3) Tableau / Power BI / Snowflake などの BI / DWH と深く統合したい。 Collibra と Alation はこの 3 条件を全て満たす。 ただし有償の年間契約になるため、 利用者数と「探す時間がどれだけ減るか」を自組織の実測で見積もってから判断する。

運用面で見落としがちなのが「カタログ自身のメタデータ管理」である。 DataHub では ingestion recipe という YAML を Git 管理することで「どの DB の、 どのスキーマを、 どの頻度でクロールするか」自体をコード化できる。 これがないと「カタログにいつから何が取り込まれたか」が不明になり、 メタデータが信頼できなくなる。 SSDSE-B-2026 を取り込む recipe は約 30 行で書けるが、 これを GitHub の Pull Request 形式でレビュー → マージするフローにすることで、 「誰が何を公開可能にしたか」の監査ログが自然に積み上がる。

PII (Personally Identifiable Information、 個人特定可能情報) 自動検出は、 公開メタデータの最重要機能の一つである。 DataHub / OpenMetadata は ML モデル (presidio / spacy NER 等) を内蔵し、 列名・サンプル値・正規表現から「電話番号」「メールアドレス」「氏名」「住所」を自動的にタグ付けする。 SSDSE-B-2026 は集計値のみなので PII を含まないが、 行政では「住民基本台帳から作った中間データ」を取り込む際に PII 検出が必須となる。 検出ロジックは F1 スコア 0.85-0.92 程度で誤検出も発生するため、 「最終承認は人間」のワークフローを必ず組む。

lineage (来歴) の自動取得には OpenLineage という業界標準が登場している。 Marquez は OpenLineage のリファレンス実装、 DataHub / OpenMetadata も OpenLineage 互換のエンドポイントを持つ。 Airflow / dbt / Spark / Flink などのオーケストレータが OpenLineage event を emit することで、 「どのジョブが SSDSE-B-2026 を読み込み、 どの中間テーブルを生成し、 どのレポートに反映したか」が自動的にグラフ化される。 手動入力ゼロで lineage が育つため、 ETL 規模が大きい組織ほど OpenLineage 対応のオーケストレータを選ぶべきである。

⚖ メタデータと法規制・コンプライアンス — GDPR / 個人情報保護法 / EU AI Act / FAIR 原則 / Open Data Charter

メタデータは「親切心で書くもの」ではなく「法的義務として書かねばならないもの」になりつつある。 EU GDPR (一般データ保護規則)、 改正個人情報保護法（日本）、 EU AI Act、 米国 AI Bill of Rights、 OECD AI 原則、 FAIR データ原則、 Open Data Charter といった枠組みは、 いずれもメタデータの整備を直接または間接に要求している。 SSDSE-B-2026 のような行政データを扱う際にも、 「これは個人情報ではない」「公表時点で適切な処理がなされた」を機械可読に宣言することが、 二次利用者の安心と組織のリスク低減の両方に直結する。

FAIR 原則 (Wilkinson et al., 2016) は、 メタデータの設計指針として最も影響力のある枠組みである。 Findable (発見可能): データに永続的識別子 (DOI / ARK / Handle) を付与し、 検索エンジンに index される豊富なメタデータを併存させる。 Accessible (アクセス可能): 標準プロトコル (HTTPS / OAI-PMH / SPARQL endpoint) で取得可能で、 メタデータ自体は data が削除されても残る。 Interoperable (相互運用): 言語と語彙が形式化され、 他のメタデータと連結可能。 Reusable (再利用可能): 詳細な来歴と明示的なライセンスが付与されている。 SSDSE-B-2026 は (1) e-Stat の永続 URL、 (2) HTTPS 経由、 (3) JIS X 0401 を都道府県コードに採用、 (4) CC BY 相当の自由利用ライセンスで、 FAIR の 4 軸すべてに合格している。

EU AI Act は 2024 年 8 月発効、 2026 年 8 月以降全面適用の規制で、 高リスク AI システム (採用・信用評価・医療診断・教育評価など) に対して「訓練データのメタデータ」を厳格に要求する。 第 10 条はデータガバナンス、 第 11 条は技術文書、 第 12 条は記録保持を定めており、 訓練データの代表性・正確性・完全性・バイアスの欠如、 関連する場合のラベル付け、 関連する仮定の同定、 量とその他の特徴の評価などをすべて文書化することを求める。 SSDSE-B-2026 のような公的統計データを訓練に使うことは「代表性・完全性」の証明が比較的容易だが、 メタデータが不十分だと「都道府県別の差は人口比でバイアス補正したか」「2020 年版と 2026 年版の改訂を区別したか」などの監査質問に答えられず、 高リスク AI 認証 (CE marking) が取れなくなる。

GDPR 第 30 条の RoPA (Records of Processing Activities) は、 EU 居住者の個人データを処理する全組織に、 処理目的・データ主体カテゴリ・受領者カテゴリ・第三国移転・保存期間・技術的組織的セキュリティ対策を文書化することを義務付ける。 SSDSE-B-2026 自体は EU 居住者を含まない都道府県集計値だが、 EU の研究機関と共同で「SSDSE-B + EU 国別データ」を結合分析する場合、 EU 側で扱う段階で RoPA 対象となる。 メタデータに「データ主体: 日本国都道府県の住民集団 (個人特定不可)」「処理目的: 学術研究 (Art. 89)」「保存期間: 公開済みのため無期限」を機械可読に記述しておくと、 EU 側パートナーの RoPA 整備が劇的に簡単になる。

日本の改正個人情報保護法 (2022 年 4 月施行) は、 「仮名加工情報」(他の情報と照合しない限り特定の個人を識別できないように加工した個人情報) と「匿名加工情報」(復元不可能なまでに加工した情報) の作成プロセスを記録する義務を定めている。 SSDSE-B-2026 は集計値で個人を含まないため直接対象外だが、 個別の住民基本台帳から SSDSE 相当の集計を作る側 (統計局・自治体) は加工プロセスの記録義務がある。 ここで PROV-O によるメタデータ記述が極めて有効で、 「source: 住民基本台帳 (個人情報)」 → 「activity: 都道府県別 5 歳階級集計」 → 「output: SSDSE-B-2026 (集計値・個人情報非該当)」のような加工チェーンを機械可読に保持できる。

Open Data Charter (2015 年公表) は、 政府データの公開原則として 6 つを掲げる: (1) Open by Default、 (2) Timely and Comprehensive、 (3) Accessible and Usable、 (4) Comparable and Interoperable、 (5) For Improved Governance and Citizen Engagement、 (6) For Inclusive Development and Innovation。 メタデータ整備は (2)(3)(4) の必須条件である。 日本政府は 2017 年に同 Charter に署名しており、 SSDSE シリーズは Charter 準拠の代表例として国際的に紹介されている。 CC BY 互換の利用条件、 機械可読 CSV、 共通の都道府県コード体系、 メタデータの英文化 (SSDSE-B-2026 は日英バイリンガル) は全て Charter の各原則に対応する具体的な実装である。

最後に、 メタデータが「組織文化」を変える力について触れておく。 メタデータが整備されていない組織は、 結局のところ「特定の人に聞かないとデータが使えない」状態が常態化し、 ベテランが退職すると暗黙知が消える「データの墓場」が累積する。 メタデータカタログを公開し、 全員が編集できるようにし、 ビジネス用語の glossary を毎週レビューするようになると、 「データ部門の人が出張中でも分析が止まらない」「新入社員が初日から SSDSE-B-2026 を発見し、 仮説検証を始められる」という文化が育つ。 メタデータは技術的成果物であると同時に、 「データを民主化する」社会的装置でもある。 この視点を持って投資すれば、 単なるドキュメント作業に見えていた取り組みが、 組織の競争力そのものに直結する戦略投資に転化する。

補論として、 メタデータ整備とサプライチェーン・ガバナンスの関係を整理しておく。 NIST SP 800-161 (情報通信技術サプライチェーンリスクマネジメント) や EU CRA (Cyber Resilience Act) は、 ソフトウェア部品表 (SBOM、 Software Bill of Materials) の作成を半ば義務付けつつあるが、 同じ発想を「データ部品表 (DBOM、 Data Bill of Materials)」に拡張する動きが出てきている。 SSDSE-B-2026 を含む派生データセットを社外提供する際、 DBOM として「SSDSE-B-2026 (CC BY 4.0)」「e-Stat 県別人口 (政府標準利用規約 2.0)」「独自スクレイピング (社内利用限定)」などの構成要素を機械可読に列挙しておくと、 受領者は法務確認を即座に終えられる。 これはオープンソースの SBOM (CycloneDX / SPDX 形式) に相当する取り組みで、 PROV-O + DataCite の relatedIdentifier で実装できる。

サステナビリティとカーボンフットプリントの観点も無視できなくなっている。 大規模データ処理は CO2 排出と直結し、 EU の Corporate Sustainability Reporting Directive (CSRD) や日本の有価証券報告書サステナビリティ情報開示は、 「Scope 3 (バリューチェーン排出)」の一部として「クラウド利用の排出量」を求めている。 ここでメタデータに「処理に要した CPU 時間」「データセンタの所在地」「電力構成 (再生可能エネルギー比率)」を Green Software Foundation の SCI (Software Carbon Intensity) 仕様で記録する取り組みが進んでいる。 SSDSE-B-2026 を 47 都道府県 × 112 列 × 12 年度分まとめて回帰分析する場合、 「同等の解析に必要な CO2 換算 g」をメタデータに残しておけば、 後続研究の影響評価に直接活用できる。

アクセシビリティの観点では、 WCAG 2.2 / JIS X 8341-3 のアクセシビリティ基準もメタデータと連動する。 SSDSE-B-2026 を可視化したダッシュボードが視覚障害者のスクリーンリーダーで読み上げられるかは、 「列名に alt text 相当の説明」「数値型変数に単位」「グラフに代替テキスト」がメタデータに含まれているかで決まる。 メタデータが豊富なら、 スクリーンリーダー読み上げ用の表記、 高コントラスト表示の自動選択、 多言語化 (i18n / l10n) が自動的に派生できる。 メタデータは「アクセシブルなデータ社会」の土台であり、 SDGs の Goal 10 (人や国の不平等をなくそう) と直結する社会基盤投資である。

国際比較の観点で、 米国・EU・日本のメタデータ政策のスタンスを並べると違いが鮮明になる。 米国は OPEN Government Data Act (2018 年成立) で連邦機関に「Open by Default」を義務付け、 data.gov に約 30 万データセットが集積している。 EU は INSPIRE 指令と Open Data Directive (2019/1024) で「高価値データセット (HVD)」(地理空間・地球観測・統計・企業情報・モビリティ・気象) の無償公開と機械可読配布を義務化した。 日本は官民データ活用推進基本法 (2016 年成立) と公共データ WG が中心となり、 e-Stat と data.go.jp を統合運用している。 国によって法的位置づけや必須メタデータ項目が異なるため、 越境分析を行う際は受入国の規制を必ず確認する必要がある。

運用継続性 (BCP / DRP) の観点では、 メタデータ自体のバックアップ・冗長化が見落とされがちな盲点である。 メタデータカタログのデータベース (DataHub なら MySQL + Elasticsearch + Neo4j、 OpenMetadata なら PostgreSQL + Elasticsearch) が単一拠点に置かれていると、 災害時にデータの「実体」は残っても「文脈」が失われる。 推奨される構成は (1) メタデータ DB の毎日 snapshot を別地域オブジェクトストレージへ転送、 (2) DCAT-AP RDF 形式での export を毎週 git リポジトリに commit、 (3) 月次で「外部公開 DOI レコード」を Zenodo にミラーする 3 重バックアップ戦略である。 これにより、 SSDSE-B-2026 のような長期参照価値のあるデータでも、 「データはあるのにメタデータが消えた」という最悪のシナリオを防げる。

教育・人材育成の側面では、 メタデータ整備スキルを持つ専門職 (data steward、 metadata librarian、 ontology engineer) の需要が急増している。 米国議会図書館や欧州 CERN は専属メタデータ librarian を配置し、 民間でも Netflix / Uber / LinkedIn は metadata platform 専属チーム (数十人〜100 人規模) を構築している。 日本国内でも、 大学図書館の電子リソース管理に関わる「サブジェクト・ライブラリアン」、 大学共同利用機関の「データキュレーター」、 IPA 認定の「データ管理者」など、 関連職種が拡張しつつある。 SSDSE-B-2026 を授業教材として使う側 (高校・大学・データサイエンス系資格学校) も、 学習者にメタデータ作成演習を組み込むことで、 単なる分析スキルを超えた「データを設計し、 受け渡す」能力を育成できる。

将来展望として、 生成 AI 時代におけるメタデータの位置づけが大きく変わりつつある。 LLM (大規模言語モデル) はデータカタログの自然言語検索を劇的に変える可能性を持ち、 すでに DataHub / OpenMetadata は GPT 系モデルを使った「テーブル説明の自動生成」「列名から意味推定」「サンプル値からの型推論」を実装している。 一方で、 LLM の hallucination リスクから「自動生成した glossary をそのまま公開しない」「必ず人間レビューを挟む」ガードレールも必要になる。 SSDSE-B-2026 のような信頼できる公的データのメタデータは、 むしろ LLM の学習素材として高品質であり、 「人間が書いたメタデータ」と「AI が補完したメタデータ」を区別するフラグ (例: generated_by: "human" / "llm-assisted" / "auto") を新たな必須項目として導入する標準化議論が始まっている。

最後の補足として、 メタデータの「鮮度 (freshness)」を計測することが運用上の最重要 KPI となる。 一度作って放置されたメタデータは数ヶ月で実態と乖離し、 「メタデータカタログを見ても古い情報しか出ない」状態になる。 鮮度指標として、 (1) 最終更新日からの経過日数、 (2) ソース DB のスキーマ変更との同期率、 (3) glossary 用語の月間編集件数、 (4) ユーザの「このメタデータは古い」報告件数を毎月モニタリングする。 SSDSE-B-2026 は年次更新なので鮮度問題が顕在化しにくいが、 社内データのカタログ運用では「鮮度ダッシュボード」が組織的健康度の代表的指標になる。 メタデータは「静的な書類」ではなく「生き物」として継続的に育てるべきもの、 という観点で運用設計を組み立てるのが、 これからの 10 年で勝敗を分ける論点になる。

補遺として、 SSDSE-B-2026 のメタデータを実際の DCAT-AP 形式で記述する具体例を示しておく。 dcat:Dataset として「title=SSDSE-B-2026 教育用標準化データ」「publisher=独立行政法人統計センター」「issued=2026 年公表」「modified=2026 年初版」「accrualPeriodicity=年次」「spatial=日本国 47 都道府県」「temporal=2012 年度〜2023 年度」「theme=社会経済統計」「keyword=人口, 経済, 教育, 福祉, 環境」「accessRights=公開」「contactPoint=統計センターの問い合わせ窓口」を記述し、 dcat:Distribution として CSV / Excel / PDF それぞれに mediaType / byteSize / downloadURL / checksum (SHA-256) を付与する。 ここまでメタデータが揃えば、 ヨーロッパの open data portal や Google Dataset Search に自動登録され、 海外の研究者が SSDSE-B-2026 を発見し、 適切に引用しながら使う基盤が整う。 一見すると地味な作業に見えるかもしれないが、 これこそが「データを世界共有財として残す」最初の一歩であり、 本ページで述べてきたメタデータ思想の集大成である。 加えて、 こうした取り組みは長期的に「データの自由化」「研究の再現性」「市民の知る権利」「行政の透明性」を同時に底上げする社会的インフラ投資であることを忘れてはならない。 メタデータ整備は未来のデータ社会への種まきと表現できる。

🗺 概念マップ

メタデータを中心に、 記述メタ (説明文)・構造メタ (スキーマ)・管理メタ (所有者・更新日時)・統計メタ (列分布) の 4 区分と、 データカタログ・データリネージを整理した概念マップ。

SSDSE-B-2026 のメタデータは「変数名表」(総人口 A1101 / 年少人口 A1301 / 出生数 A4101 / 消費支出 L3221 など多数の指標) と「年次」「単位」のセットで構成される。 列名と単位の対応を辞書として保持すれば、 後続の集計で誤った単位混合を防げる。

🔗 隣接手法への橋渡し

メタデータは単独で扱う対象ではなく、 上流のデータカタログ (Data Catalog) 構築、 並列のスキーマ管理 + データリネージ、 下流のデータ品質モニタリングと組み合わせて、 データガバナンスの骨格を形成する。

• 上流 (前段処理): データソース定義 / スキーマ設計 — テーブル定義・カラム名・型情報の記述
• 並列 (代替/比較): データカタログ / リネージ — メタデータ管理の上位レイヤ
• 下流 (後段活用): 検索 / アクセス制御 — メタデータを基にした権限管理

SSDSE-B-2026 で言えば、 ファイル名 (SSDSE-B-2026.csv)・更新日 (2026-04)・列数 (35)・行数 (47)・各列の単位・出典 (各種統計年鑑) などをメタデータとして JSON-LD / Datasheets for Datasets 形式で記述するのが現場の標準。

🌳 手法選択フロー

メタデータ管理の手法選択は、 (1) スキーマが固定か変動か、 (2) 規模 (テーブル数) が大規模か、 (3) 規制要件 (GDPR / 個人情報) が厳しいか、 で決まる。 固定スキーマなら DB の COMMENT、 大規模なら DataHub / Amundsen / Apache Atlas。

1. 対象は構造化データか? はい → RDB のスキーマ・列コメント、 いいえ → JSON Schema / Avro
2. リネージ追跡が必要か? はい → OpenLineage / DataHub、 いいえ → README + dictionary
3. 機微情報を含むか? はい → 機密度タグ付け + IAM、 いいえ → 公開メタデータ

実務ではメタデータ自動生成 (テーブル名・型) + 手動補強 (説明文・所有者) のハイブリッドが定石で、 SSDSE-B-2026 のような単一 CSV なら README.md + datasheet.json で十分。

🧩 解説深化：単位という「見えないメタデータ」

このページ上部の「発見可能性（見つけられるか）」とは別角度で、 見つけた後に正しく計算できるか という切り口でメタデータを掘り下げる。 使用データは data/raw/SSDSE-B-2026.csv（2023 年・47 都道府県）の実測値。

🎨 直感：データは「ラベルの剥がれた缶詰」

⚠️ 落とし穴（重要）

🚀 発展：コード体系そのものがメタデータである

🔗 関連ページ

• 構造化データ — 行×列という器。 その各列に「何者か」を与えるのがメタデータ。
• 整然データ（tidy data） — 「1 列 1 変数」を守ると、 単位・型メタデータを列単位で一意に付けられる。
• 集約（aggregation） — 落とし穴③の「男＋女＝総」のような合計制約はメタデータが定義する。
• リレーショナルDB — 列コメント・型・制約という形でメタデータをスキーマに焼き込む仕組み。
• データガバナンス — メタデータ・カタログを組織横断で運用する上位レイヤ。
• データ辞書（data dictionary） — 各列の定義・単位・出典を一覧化した表。 本用語集では独立ページ未整備のため、 ここでは用語のみ示す。

数値は data/raw/SSDSE-B-2026.csv を pd.read_csv(encoding='cp932', skiprows=[1]) で読み、 df[df['SSDSE-B-2026']==2023]（および 2012–2023 の年次集計）から算出した実測値。 14086000 / 17.6 等は東京都、 気温レンジ・全国計は 47 都道府県の実値。