1-5. グラフの質を左右する！データ前処理の基本
投稿者：Yukina Matsumoto
なぜ「データの前処理」が可視化に不可欠なのか
前回、目的に応じたグラフの選び方を学びました。
これでグラフづくりに取り掛かれる、と言いたいところですが、ちょっと待ってください。
実は、本格的な分析をやる前に必ずやっておくべき 重要なステップがあります。
それが データの前処理 です。
データの前処理とは、データを分析に適した状態に整える作業 のことを指します。
では、なぜこのステップが不可欠なのでしょうか？
グラフ選択と前処理はセット
グラフは伝えたいことを形にする道具ですが、本格的にグラフを作る前に生データの概要を把握する必要があります。
これは 探索的データ分析（EDA） とも呼ばれる手法です。
- 箱ひげ図を描いたら、ポツンと離れた点があった → 外れ値の発見
- 棒グラフを描いたら、「Web」と「WEB」が別の棒になった → 表記ゆれの発見
- 折れ線グラフを描いたら、ある日だけ急に0になった → 欠損値の疑い
このように、可視化自体が、データの前処理の方針を決める役に立つのです。
私たちが実際に扱うデータは以下のようなものが多いと思います。
- アンケート結果
- 売上データ
- 顧客情報
- ウェブサイトのアクセスログ
- センサーデータ
これらのデータには、以下のようないわゆる「汚れ」が含まれていることが多いです。
- 欠損値（空欄）
- 外れ値（他の多くのデータから極端に 離れた値）
- 重複データ
- 表記ゆれ
また、点在しているデータを一カ所にまとめたり、必要な形式に変換したりする必要もあります。
しかし、それを怠ると以下のような問題が発生するリスクがあります。
- 誤った分析結果：欠損値や外れ値がそのままだと、平均値や割合が実態と大きく乖離する
- グラフの歪み：データの不整合が原因で、グラフが正確に情報を伝えられなくなる
- 意思決定のミス：不正確なデータに基づく意思決定は、ビジネスの判断を誤らせる可能性がある
こういった事態にならないよう、探索的データ分析をして前処理の方針を決め、データを整えるのです。
この記事ではどのような前処理の方法を選択すべきか、判断できるような基礎力を身につけることを目指します。
分析の目的やデータの性質に応じて、最適な前処理の方法を選択できる力 を養いましょう。
この記事で得られること
- 欠損値・外れ値・重複・表記ゆれなどの基本的なデータの「汚れ」とその影響を理解できる
- 前処理の具体例を通じて、目的に応じた前処理の方法を判断できるようになる
前提の置き方
本記事では、ExcelやBIツールでの分析を想定し、特定のツール操作ではなく「共通 して必要な考え方」に焦点を当てます。
また、扱うデータは売上やアンケートなどの行と列で構成される「構造化データ」を前提とします。
前処理は「作業」ではなく「判断」
前処理において本質的に大事なのは、実際の作業ができることよりも 「データをどのように整えるべきか」という判断ができること です。
作業自体はツールの機能で簡単にできますが、どのように前処理すべきかはケースバイケースで異なるからです。
- どの値を信用するか
- どの単位・粒度・表記で見るか
- 何を捨てて、何を残すか
- どのように連携・変換するか
これらの判断は、データ分析の目的や取り扱うデータ、可視化の仕様などによって正解が異なります。
そのため、分析目的・データの種類・業務上の制限・可視化の方法などを踏まえたうえで、最適な前処理の方法を考える力 が重要です。
どのように前処理をするか？
ここからは具体例を通じて、前処理の方法をどのように判断するのかを体験しましょう 。
日別の売上推移を可視化する場合を考えます。
1. 分析の目的と可視化の仕様
目的
- 年始のバーゲン期間の日別の売上推移 を確認したい
可視化の仕様
- 折れ線グラフで 日別の純売上（売上 − 返金） を表示する
- 今回は 個人向け（BtoC）の推移 を見たい（法人の大型受注でグラフが潰れるのを避ける）
- 日単位の合計を見る（取引明細レベル→日別集計へ）
- 欠損がある日は「0円」と誤解されないよう、別途件数を残して注記できる形にする
2. 前処理前のデータ（生データ）
例として、ECの取引ログ（注文・返金が混在）を考えます。
| 取引ID | 取引日時 | 種別 | チャネル | 顧客種別 | 金額 | 通貨 | ステータス | 備考 |
|---|---|---|---|---|---|---|---|---|
| T0001 | 2025/01/01 09:12 | 売上 | WEB | 個人 | 12800 | JPY | 確定 | |
| T0002 | 2025-01-01 23:50Z | 売上 | web | 個人 | 5400 | 円 | 確定 | タイムゾーン混在 |
| T0003 | 2025/01/02 10:05 | 売上 | 店舗 | 個人 | JPY | 確定 | 金額未連携 | |
| T0004 | 2025/01/02 10:05 | 売上 | 店舗 | 個人 | 6100 | JPY | 確定 | 送信リトライ |
| T0005 | 2025/01/02 18:20 | 売上 | Web | 法人 | 980000 | JPY | 確定 | 大口受注 |
| T0006 | 2025/01/03 11:40 | 返金 | WEB | 個人 | -3000 | JPY | 確定 | 返品返金 |
| T0007 | 2025/01/03 12:10 | 売上 | WEB | 個人 | 7200 | JPY | キャンセル | |
| T0008 | 2025/01/04 08:15 | 売上 | 店舗 | 個人 | 6100 | JPY | 確定 | |
| T0009 | 2025/01/04 20:30 | 売上 | 店舗 | 個人 | JPY | 確定 | 金額未連携 |
3. 前処理の内容
前処理は「作業の手順」ではなく、目的に照らした判断 から組み立てます。
日付・時刻の扱い
- 判断
- 日別推移が目的なので、日時は「日付」に丸める。
- 業務基準である日本時間に揃える。
- 処理
- タイムゾーンを業務の基準にそろえ、
YYYY-MM-DDに変換して日付列を作る - 例：
2025-01-01 23:50Zは日本時間では2025-01-02 08:50になるので、日付は2025-01-02とする
- タイムゾーンを業務の基準にそろえ、
表記ゆれの統一
- 判断
- チャネル別の内訳は今回見ないが、最低限「同一値が別カテゴリ扱い」になるのは避けたい（将来の分析にも効く）
- 処理
- チャネルを
WEB / web / Web→WEBのように統一する。 - 通貨も
JPY / 円をJPYに統一する
- チャネルを
金額欄の欠損値
- 選択肢
- ① 欠損行を除外
- ② 0で埋める
- ③ 別データ（決済/受注明細）で補完
- ④ 欠損を残して別指標で可視化
- 今回の判断
- 目的が「純売上（金額）の推移」なので、欠損を0で埋めると“売上0円の日”と誤解 されやすい。
- 今回、
T0003の金額未連携は入力ミスであり、後続のT0004が確定レコードとして連携されていた（担当に確認済み）。 - ただし、
T0009は原因不明で未解決の欠損として残っていた。 - よって、欠損行（
T0003とT0009）は純売上集計から除外し、未連携件数を別途残す 方針とする。
- 処理
- 「未連携件数」列を追加し、金額が空欄の行は
未連携=1とし、純売上集計の対象から外す（可能なら後続で補完）
- 「未連携件数」列を追加し、金額が空欄の行は
金額の外れ値
- 選択肢
- ①そのまま含める
- ②入力ミスとして除外
- ③上限を設けて丸める
- ④系列を分ける（BtoC/BtoBなど）
- 今回の判断
- 目的が「BtoCの推移」なので、法人（大口）は 母集団が違う とみなし、BtoC集計から除外する
- 処理
顧客種別=個人のみにフィルタして日別純売上を作る
返金・キャンセル
- 判断
- 今回は純売上（売上 − 返金）なので、返金はマイナスとして含める。
- 返金の場合は金額がマイナスで入力されているため、そのまま合算する。
- キャンセルは売上未成立なので除外する
- 処理
種別=返金のマイナス金額は含め、ステータス=キャンセルは集計対象外にする
4. 処理後のデータ（可視化用データ）
日別推移の折れ線グラフで使うのは「日付×純売上」です。ただし、欠損の影響を透明化するため、未連携件数も残します。
| 日付 | 純売上（個人） | 未連携件数 |
|---|---|---|
| 2025-01-01 | 12800 | 0 |
| 2025-01-02 | 11500 | 1 |
| 2025-01-03 | -3000 | 0 |
| 2025-01-04 | 6100 | 1 |
5. この前処理が「正解」になる理由
- 日別推移という目的に対して、タイムゾーンと日付の粒度をそろえたため、日跨ぎによる見かけの増減 を避けられる
- 欠損を0埋めせず、未連携件数を残したため、「売上が落ちた」のか「データが欠けた」のか を区別できる
- 外れ値（法人の大口）を母集団の違いとして分離したため、BtoCの折れ線が “潰れて読めない”問題 を回避できる
- キャンセルを除外したため、純売上が 過大計上 されにくい
前処理の判断チェックリスト
上の具体例では「目的→判断→処理→可視化用データ」の流れで前処理を組み立てました。
ここでは、どんなデータでも使い回せるように 判断ポイントだけをチェックリスト化 しました。
1. 目的・仕様を先に固定する
- 何を答えたいか（傾向把握／比較／要因探索／予測など）
- 指標の定義（例：売上なのか、純売上なのか、税・送料・値引き・返金をどう扱うか）
- 対象範囲（例：BtoCだけ／全体／特定チャネルだけ など）
- 粒度（例：日別・週別・月別、顧客別・商品別 など）
2. データの全体像の把 握
- 行数・期間・更新頻度（「本当にその期間のデータがあるか」）
- 一意キー（取引IDなど）があるか／重複が起きうる構造か
- 欠損の量と偏り（特定の日・チャネルだけ欠けていないか）
- 集計するときに落ちる行（キャンセル、無効フラグなど）があるか
3. 表現・型・単位の確認
- 日付・時刻：タイムゾーン混在の有無、日付境界がズレないか
- 数値：数値列が文字列になっていないか、桁・通貨・単位の混在がないか
- カテゴリ：表記ゆれ（全角半角、大文字小文字、別名）がないか
4. 欠損値の扱い
- 欠損は“情報がない”状態で、0は“値が0”なので意味が違う
- 欠損を除外・補完・別指標で可視化のどれを選ぶかは、目的で決める
- 例：金額推移が目的なら、0埋めは「売上0円」と誤解されやすい
- 例：件数推移が目的なら、金額欠損でも件数は集計対象にできる（ただし注記が必要）
- 欠損を集計から外すなら、未連携件数など“データ品質の指標”を一緒に残す
5. 外れ値の扱い
- 外れ値の候補が出たら、まず原因を切り分ける
- 入力ミス（桁違い、単位違い）
- 例外業務（大口受注、特殊キャンペーン）
- 母集団が違う（BtoBとBtoCが混在 など）
- 対応は「除外」「修正」「丸める」「系列を分ける」のいずれか（目的に合わせて選ぶ）
6. 重複・多重計上の扱い
- 重複排除のキーとルール（例：最新を採用、同一IDは1件のみ）を決める
- 集計前後で、件数・金額が“常識的”な範囲かを確認する
7. ビジネスルール・ドメイン知識の確認
- キャンセル・返金・返品・交換の扱いは、指標定義に直結する
- 「何を純売上と呼ぶか」をチーム内で言葉にして揃える
その前処理を選んだ理由を説明できるようになろう
ここまで具体的な前処理の方法を学んできましたが、やはり一番大切なのは、なぜその前処理を選択したのかを論理的に説明できることです。
欠損値を平均値で埋めるのか、その行を捨てるのか。
また、外れ値を削除するのか、残すのかなど、処理の内容は分析目的やデータの性質によって異なります。
理由を説明しようとすると、以下のような点が自然と露呈します。
- 目的と処理がずれていないか
- 他の選択肢を検討しているか
- 都合のいい処理をしていないか
そのため、言葉で説明できるようになるには、思考が整理できている必要があります。
そして、思考が整理できると必然的に判断の質も向上します。
加えて、再現性や属人化防止の観点からも、理由を言語化することをおすすめします。
処理の選択理由が言語化されていれば、人に共有するのが容易になります。
その結果、レビューの質が向上したり、他の人に作業を引き継いだりしやすくなるからです。
選択理由の説明フォーマット
選択理由を説 明するための型を用意しました。
はじめのうちは、以下の型に当てはめてその処理を選択した理由を説明できるようにしてみてください。
慣れるとスムーズに判断できるようになるでしょう。
例）日別売上推移を可視化する場合
- 目的：日別の売上推移を把握したい
- 仕様：折れ線グラフで日単位の合計売上を見る
- 対象：売上金額列の欠損値
- 選択：欠損行を除外し、日別に合算した
- 理由：欠損を含めると日別合計が定義できないため
他にこんなことにも注意しよう
工数とのトレードオフ
前処理は重要な工程ですが、時間がかかることも事実です。
そのため、完璧な前処理を目指すのか、スピード重視でざっくり進めるのかのバランスを見極めることも重要です。
それこそ分析の目的やデータの性質に合わせて判断しましょう。
- 品質優先：経営判断に関わる重要なレポートでは、1件のミスも許されないため厳密にチェックする。
- スピード優先：ざっくりとした傾向を数分で把握したいだけなら、明らかな外れ値だけ を除いて先に進む。
設計時からデータの扱いを考慮する
あとで分析をすることが決まっていて新たにデータを収集・管理する場合、最初からデータの扱い方を考慮して設計することが理想です。
データベースやテーブルの定義、データの型や表記ルールなどを決めておくと、データ収集後の前処理を大幅に減らせます。
また、入力方法もなるべく手入力を減らしたり、選択肢から選ぶ形式にしたりすることで、データの「汚れ」を防げます。
もちろん、既存データの分析や仕様による制約がある場合は難しいと思います。
しかし、アプリ開発などで将来的に分析する可能性のあるデータを扱う場合は、設計段階から意識してみてください。
まとめ：前処理は判断力が鍵
今回はデータ前処理の基本について学びました。
前処理の作業自体はツールに任せることもできます。
しかし、 どのように処理するべきか、その処理が適切かどうかは人間が判断する必要があります。
最初のうちは説明フォーマットを使 って選択理由を言語化する練習をしながら、判断力を鍛えていきましょう。