データ辞書｜データ要求・収集・利用条件

このページはプロモーション（広告）を含みます。

データ要求・収集・利用条件（中級・読む30分＋演習40分）

この授業のゴール

• データ辞書の欄（項目名・説明・型・単位・許容値・欠損の意味・出所・責任者・個人情報の区分・利用制限）の役割を説明できる
• 業務の表について、初めて見る人がそのまま使える水準のデータ辞書を書ける
• データ辞書から品質規則を作り、範囲外・許容値外・型違い・重複・遅延を検出できる
• 再送・遅延・型変更・権利不明といった異常系の扱いを辞書に書ける

仕事でどう使うか

データ辞書は、表の各項目が何を意味し、どんな値を取り、どこから来たかを書いた「取扱説明書」です。L01〜L04で決めた単位・定義・出所・利用条件を、1つの表にまとめる場所でもあります。

前提

次の内容を使います。

• 型（整数・小数・文字列・日付）と欠損 → 数値・カテゴリ・日時・欠損、型・日付・式
• 主キー（1行を特定する列の組み合わせ）→ テーブルと1行の単位
• 単位・基準・操作的定義 → 測定単位と定義
• 出所・責任者・利用条件 → 出所と利用条件

本文と演習の Python で使う関数は、登場するたびに説明します。

身近な状況：引き継いだ表の列名が読めない

みどり商店のデータ担当が異動し、後任者に次の表 daily_stock.csv が引き継がれました。

後任者は次の疑問に答えられず、問い合わせに2日かかりました。

• q は販売数か、発注数か、在庫数か。単位は個か、ケース（箱）か。
• so は品切れ（stockout）の時刻らしい。空欄は「品切れなし」か「記録なし」か。
• flg の1は何を表すのか。（答え：店舗の改装で休業した日。だから q が0）
• d は日本時間の日付か。何時で締めているか。
• このデータを社外に出してよいか。誰に聞けばよいか。

もし flg=1 の意味を知らずに分析していたら、休業日の販売数0を「需要0」として扱い、需要を低く見積もっていたはずです。

この情報が最初から1枚の表に書かれていれば、2日の問い合わせは不要でした。その表がデータ辞書です。

直感的な説明：地図の凡例と、家電の取扱説明書

地図には凡例があります。青い線は川、点線は県境、というように、記号の意味が書かれています。凡例がなければ、同じ地図でも読み方が人によって変わります。

列名は地図の記号と同じで、q だけでは意味が決まりません。データ辞書は表の凡例です。

もう1つは取扱説明書のたとえです。家電の説明書には「使える電圧は100V」「水に濡らさない」のような使ってよい範囲が書かれています。データ辞書にも、取ってよい値の範囲（販売数は0以上の整数、品切れ時刻は9〜22時）を書きます。範囲を書いておけば、範囲から外れた値（販売数−3、品切れ時刻25時）を自動で見つけることができます。

つまりデータ辞書には2つの役割があります。

1. 人のため：初めて見る人が、問い合わせなしで正しく使えるようにする。
2. 検査のため：書かれた規則と実際のデータを照らし合わせ、異常を見つける。

正確な定義：データ辞書の欄と、品質規則

• データ辞書：表の各項目について、意味・型・単位・許容値・欠損の意味・出所・責任者などを書いた文書。
• スキーマ：表の構造（列名・型・主キーなど）の定義。データ辞書はスキーマに、意味や業務上の規則を加えたもの。
• 品質規則：データが満たすべき条件。データ辞書の型・許容値・主キー・鮮度の欄から作る。

表全体について書くこと

項目ごとに書くこと

必要に応じて、個人情報の区分（個人を特定できる、仮名、含まない）や派生の式（他の列から計算した列なら、その計算式）の欄も加えます。

辞書から作る品質規則の例

異常系の扱いも辞書に書く：実務のデータでは、次のことが必ず起きます。

段階付き例題：引き継いだ表のデータ辞書を作る

冒頭の daily_stock.csv について、データ辞書を作ります。

ステップ1（入力：サンプルと聞き取りメモを集める）

• サンプル行（先頭の数十行）と、各列の値の種類・最小値・最大値・欠損数を確認する。
• 前任者と販売部に聞き取る。メモ：「q は販売数、単位は個」「so は品切れ時刻、空欄は品切れなし」「flg=1 は休業日」「d は日本時間」。

ステップ2（処理：列名をわかりやすくし、1列ずつ欄を埋める）

元の店舗コード 1 は文字列 S01 に変換する、と変換規則も書きます。数値のままだと 1 と 01 が別物になったり、先頭の0が消えたりするからです。

ステップ3（処理：表全体の情報と規則を書く）

• 主キー：(store_id, item_id, date)。
• 休業日（closed_flag=1）の sales_qty は0だが、需要の分析では除く、と注記する。
• 品質規則：主キー重複なし、sales_qty ≥ 0、stockout_hour は9〜22または欠損、closed_flag は0か1。

ステップ4（出力と意味）

できた辞書を前任者と販売部に見せて確認し、表と同じフォルダに置きます。これで後任者は、flg=1 の日を需要0と誤解することがなくなります。さらに、規則を使った自動検査（次の節）で、毎朝届くデータの異常を見つけられるようになります。

操作して理解する：辞書の規則で、型変更・再送・遅延を見つける

システム更新の後に届いたデータを、辞書の規則で検査します。

使う関数：

• pd.to_numeric(列, errors='coerce')：数値に変換し、変換できない値（「12個」など）を NaN（欠損）にします。
• df.duplicated(subset=[列のリスト], keep='last')：指定した列の値が同じ行のうち、最後の行以外を True にします。再送で後から届いた行を残したいときに使います。
• pd.Timedelta(days=1, hours=9)：1日と9時間の長さ。日付に足すと「翌日9:00」になります。

import pandas as pd

# システム更新後に届いたデータ。sales_qty に文字が混ざり、同じ行が再送されている
raw = pd.DataFrame({
    'store_id':  ['S1', 'S1', 'S1', 'S2', 'S2'],
    'date':      ['2025-06-01', '2025-06-02', '2025-06-02', '2025-06-01', '2025-06-02'],
    'sales_qty': ['120', '135', '135', '12個', '90'],
    'loaded_at': ['2025-06-02 06:00', '2025-06-03 06:00', '2025-06-03 07:30',
                  '2025-06-02 06:00', '2025-06-04 06:00'],
})

# (1) 型の規則：sales_qty は整数。数値に変換できない値を NaN にして数える
raw['qty_num'] = pd.to_numeric(raw['sales_qty'], errors='coerce')
print('型違反:', raw['qty_num'].isna().sum(), '件 →', raw.loc[raw['qty_num'].isna(), 'sales_qty'].tolist())

# (2) 主キーの規則：store_id × date は1行。再送された重複を数える
dup = raw.duplicated(subset=['store_id', 'date'], keep='last')
print('再送による重複:', dup.sum(), '件')

# (3) 鮮度の規則：翌日 9:00 までに届く
due = pd.to_datetime(raw['date']) + pd.Timedelta(days=1, hours=9)
late = pd.to_datetime(raw['loaded_at']) > due
print('遅延到着:', late.sum(), '件 →', raw.loc[late, ['store_id', 'date']].values.tolist())

出力：

型違反: 1 件 → ['12個']
再送による重複: 1 件
遅延到着: 1 件 → [['S2', '2025-06-02']]

3つの規則で、3種類の異常が見つかりました。

• 型違反：S2の6/1の販売数が「12個」という文字。数値に変換できないので保留表に移し、POS担当者に連絡します。勝手に12と読み替えると、他の行にも同じ問題があったときに気づけません。
• 再送：S1の6/2が2回届いています。辞書の規則「到着時刻が新しいほうを採用」に従い、keep='last' で後の行を残します。
• 遅延：S2の6/2は、期限の6/3 9:00ではなく6/4 6:00に届きました。この日を使った翌日の発注判断は、データなしで行われたことになります。遅延の頻度を記録すると、鮮度の要求（必要な問いとデータ）を満たせているかがわかります。

値を変えて試しましょう。'12個' を '12' に直すと型違反は0件になります。S2の loaded_at を '2025-06-03 08:00' にすると遅延は0件になります。

発展：機械が読める辞書、カタログ、変更の管理

機械が読める辞書：表計算ソフトの辞書は人には読みやすいですが、検査のコードと二重管理になりがちです。実務では、辞書をJSONやYAML（設定を書くための文字の形式）などで書き、そこから検査のコードを自動で作ることがあります。たとえば次のように書きます。

schema = {
    'sales_qty':     {'type': 'int', 'min': 0, 'nullable': False, 'unit': '個'},
    'stockout_hour': {'type': 'int', 'min': 9, 'max': 22, 'nullable': True,
                      'null_means': '品切れなし'},
}

辞書と実データのずれ：辞書は作った時点では正しくても、システム更新で実データが変わります。毎回のデータ取り込みで辞書の規則を自動検査し、違反が出たら辞書かデータのどちらが正しいかを確認します（「品質テスト」（有料版））。

変更の管理：項目の追加・型の変更・定義の変更は、辞書の版として記録します。「2025-04-01版から sales_qty に社員割引を含む」のように、変更日と内容を書きます。古い版のデータと新しい版のデータを混ぜて比べるときに必要です（「スキーマと互換」（有料版））。

限界：辞書の規則で見つかるのは「書いた規則に反する値」だけです。許容範囲内でも間違っている値（120個を誤って102個と入力）は見つかりません。他のデータとの照合（POSの合計と会計の売上を比べる）を組み合わせます。

よくある失敗

失敗1：項目名を日本語に言い換えただけの辞書

誤った辞書：

なぜ誤りか：「売上」が税込か税抜か、取消を含むか、「数量」が個かケースか、「日付」が何時締めかがわかりません。L02で見たとおり、これらの違いで値が大きく変わります。言い換えだけの辞書は、問い合わせを減らしません。

直し方：少なくとも、説明（含める・除く条件）・型・単位と基準・許容値・欠損の意味を書きます。「この辞書だけを見て、別の人が同じ集計を再現できるか」を確認の基準にします。

失敗2：欠損の意味を書かない

誤った例：stockout_hour の欠損の意味を書かずに渡した。受け取った分析者は欠損を「記録漏れ」と考え、欠損の行（実は品切れなしの日）をすべて除いた。

結果として、品切れした30日だけで需要を分析することになり、需要を大幅に低く見積もりました（品切れ日の平均68.7個、品切れでない日の平均155.1個。収集方法とバイアス の demand.csv）。

なぜ誤りか：欠損には「該当なし」「未測定」「記録漏れ」「対象外」など複数の意味があり、意味によって正しい扱いが逆になります。

直し方：辞書に「欠損の意味」の欄を必ず作り、1つの列に複数の意味の欠損が混ざる場合は、理由を表す別の列（例：stockout_status＝なし／あり／不明）を設けます。

失敗3：許容値を書かず、異常な値を見逃す

誤った例：sales_qty の許容値を書かなかったため、次の値がそのまま分析に入った。

10行の平均が120個のところに9999が1行入ると、平均は $(120 \times 9 + 9999) \div 10 = 1107.9$ 個になります。

なぜ誤りか：許容値がないと、何が異常かを判断する基準がありません。

直し方：辞書に許容値（0以上、上限の目安）を書き、範囲外の値は保留表に移して理由を確認します。テストデータは「テスト用の店舗コード」などで区別できるよう、辞書の説明にも書きます。

失敗4：辞書を作ったまま更新しない

誤った例：システム更新で store_id が S01 から 1 の形式に変わったが、辞書は古いまま。新しいデータと古いデータを store_id で結合したところ、6月以降のデータがどの店舗とも一致せず、6月以降の販売が0件に見えた。

なぜ誤りか：辞書と実データがずれると、辞書は誤った情報源になります。結合キーの形式の変更は、エラーにならずに結果を0件にするので気づきにくいです。

直し方：データを取り込むたびに辞書の規則（store_id は S01〜S15）で検査し、違反が出たら取り込みを止めて確認します。形式を変えた場合は辞書の版を上げ、変換規則（1 → S01）を書きます。

まとめ

• データ辞書は表の取扱説明書。表全体（1件の単位・主キー・鮮度・出所・責任者・利用条件）と、項目ごと（説明・型・単位・許容値・欠損の意味）を書く。
• 欠損の意味は「該当なし」「未測定」「記録漏れ」などで扱いが逆になるので、必ず書く。
• 辞書の型・許容値・主キー・鮮度から品質規則を作り、取り込むたびに自動で検査する。
• 再送（後着を採用）・遅延（未着として記録）・型変更（保留表へ）・権利不明（取り込まない）の扱いを辞書に決めておく。
• 辞書は版を付けて更新する。規則で見つからない範囲内の誤りは、他のデータとの照合で確かめる。

用語

データ辞書（data dictionary）

表の各項目の意味・型・単位・許容値・欠損の意味・出所・責任者などを書いた文書。

スキーマ（schema）

表の構造（列名・型・主キーなど）の定義。

品質規則（data quality rule）

データが満たすべき条件。主キーの一意性、型、範囲、欠損、鮮度など。

再送（redelivery / resend）

同じデータが2回以上届くこと。主キーの重複として現れる。

コードブック（codebook）

研究データの変数の意味や値のコードを説明する文書。データ辞書とほぼ同じ役割。

よくある質問

なぜデータ辞書を作る必要があるのですか？ 列名をわかりやすくすれば十分では？

列名をわかりやすくしても、単位（個かケースか）、基準（税込か税抜か）、欠損の意味、許容値、出所、利用条件までは表せません。これらがないと、担当者が変わるたびに問い合わせが発生し、誤解による分析ミスも起きます。

データ辞書とデータ要求表はどう違うのですか？

データ要求表（必要な問いとデータ）は「判断のために、どんなデータが必要か」を書いた依頼書です。データ辞書は「実際に受け取った（または作る）表の各項目が何を意味するか」を書いた説明書です。要求表をもとにデータを集め、辞書で中身を確定させます。

どこで失敗しやすいですか？

欠損の意味と、システム更新による変化です。欠損が複数の意味を持つことを書かない、型や形式が変わったのに辞書を更新しない、という失敗が多いです。取り込むたびに辞書の規則で自動検査すると防げます。

辞書を作る時間がないときは、どこから書けばよいですか？

優先順位は、(1) 1件の単位と主キー、(2) 分析に使う列の単位・基準・欠損の意味、(3) 出所・責任者・利用条件、の順です。分析に使わない列は後回しにしてかまいません。ただし、使わない列も「使わない」と書いておくと、後の人が迷いません。

条件が変わって項目が増えたり定義が変わったりしたらどうしますか？

辞書の版を上げ、変更日・変更内容・変更前後の比較方法を書きます。古いデータと新しいデータを並べて比べる分析では、版の変わり目に注意します（「スキーマと互換」（有料版））。

仕事では、辞書の内容を誰が確認・承認しますか？

項目の意味や業務規則は、そのデータの責任者（データオーナー）や、実際にデータを入力・出力する業務の担当者に確認します。分析者が推測で書いた部分は「推測」と明記し、確認が取れたら更新します。

確認問題

次に学ぶこと

次は 不足と追加収集 で、データ要求表とデータ辞書を見比べて足りないデータを見つけ、追加収集の計画を立てます。

型・欠損の基礎は 数値・カテゴリ・日時・欠損、主キーは テーブルと1行の単位 に戻って確認できます。データ辞書の規則を使った品質検査は 「品質次元と基準」（有料版）、「品質テスト」（有料版） で本格的に学びます。