【ITニュース解説】Three CSV rows can mean one company: check the row unit before deduplicating
2026年10月21日に「Dev.to」が公開したITニュース「Three CSV rows can mean one company: check the row unit before deduplicating」について初心者にもわかりやすく解説しています。
ITニュース概要
CSV等のデータ処理では、1行が何を示すかを明確にせず重複排除や結合を行うと誤った結果になる。例えば「会社名+所在地+日時」で1行の単位を定義するなど、キーを慎重に設定し、小さなデータで確認してから全体を処理しよう。
ITニュース解説
システムエンジニアを目指す上で、データを扱う機会は非常に多く、その中でも特に基本となるのが「データの重複」という問題だ。この問題は一見単純に見えるが、実は奥深く、安易な対処は大きな間違いにつながることがある。特に、CSV(Comma Separated Values)形式のファイルを扱う際には、1行が何を表しているのかを事前にしっかりと理解することが非常に重要になる。
例えば、10,000行あるCSVファイルがあったとしても、それが必ずしも10,000個の異なる会社やアイテムを意味するわけではない。データセットを他のデータと比較したり、ファイル内の重複する情報を削除したりする作業(これを「重複排除」と呼ぶ)を行う前に、まず「このCSVの1行は、具体的に何という単位の情報を表しているのか」を明確に定義する必要がある。この定義が曖昧なままだと、後々データ処理の誤りや予期せぬ結果を招く原因となる。
具体的な例を見てみよう。もし、次のようなデータがあったとする。
entity_id,location_id,price_usd
example-a,site-1,20
example-a,site-1,20
example-a,site-2,30
このデータには全部で3行ある。しかし、ここで注目すべきは、entity_id が example-a という会社は1つしかない点だ。さらに、「会社と場所」の組み合わせで見ると、example-a と site-1 のペア、そして example-a と site-2 のペアの2種類が存在する。そして、example-a,site-1,20 という行が2回繰り返されていることがわかる。
この重複している「会社と場所」のペアは、なぜ2回現れているのだろうか。これは単なる入力ミスによる偶然の重複かもしれないし、あるいは、データのエクスポート時に本来記録されるべき「観測された日付」のような重要な情報が欠落しているために、別々の正規の記録が同じものに見えてしまっている可能性もある。もし後者であれば、それぞれの行は実際には異なる時点での情報を示しており、どちらか一方を削除してしまうと、大切な情報を失うことになる。
このことから、「1行の単位」を明示することがいかに重要かがわかるだろう。1行が「会社(エンティティ)」を表しているのか、「場所(ロケーション)」を表しているのか、「特定の時点での提供情報(オファー)」を表しているのか、それとも「特定の時点での観測結果」を表しているのか。これらを明確に定義する必要がある。
多くの場合、単一の識別子(例えば entity_id だけ)では、データの一意性を保証するのに不十分だ。より有用な「キー」(データを識別するための情報)は、複数の項目を組み合わせたものになることがある。例えば、(entity_id, location_id, observed_at) のように、会社ID、場所ID、そして観測日時を組み合わせることで、データの各行を一意に識別できるようになるかもしれない。この「キー」の候補を、まずは小さなサンプルデータで試してみることをお勧めする。大きなファイル全体を処理する前に、実際にそのキーが意図した通りに機能するかどうかを確認することが、後々の問題を防ぐ上で非常に効果的だ。
プログラムを使って重複するキーを特定することは可能だ。例えばPythonの collections.Counter のようなツールを使えば、(entity_id, location_id) のようなペアが何回出現するかを数え、重複しているペアを簡単に見つけ出すことができる。しかし、ここで重要なのは、重複しているキーを特定することと、どの行を削除するかを決定することは全く別の作業だということだ。
重複が見つかった場合でも、すぐにどの行かを削除するべきではない。元のファイルは必ず保存しておき、重複している行間の違いを注意深く調査する必要がある。そして、「どの情報を残し、どの情報を削除するか」というルールを、業務要件に基づいて明確に定義することが不可欠だ。もし、何も考えずにただ「最初の行だけを残す」といった安易な方法で重複を排除してしまうと、実はより新しい情報や、全く異なる製品に関する情報を誤って削除してしまう恐れがある。これはデータ損失につながり、非常に危険な行為だ。
データの結合(Join)処理を行う際にも、同様の注意が必要だ。複数のデータセットを結合して新しい情報を作り出す時、もし結合する両方のデータセットに同じ結合キー(データを紐付けるための共通の項目)が重複して含まれていると、結合結果として出力される行数が意図せず大幅に増えてしまうことがある。例えば、データAに商品IDが重複している行があり、データBにも同じ商品IDが重複している行がある場合、これらを結合すると、商品IDごとの組み合わせがすべて生成され、結果として予想をはるかに超える行数のデータができてしまうのだ。
出力された行数が増えたからといって、自動的にデータの網羅性が向上したと考えるのは間違いだ。実際には、無意味な重複情報が増えているだけかもしれない。これを防ぐためには、結合を行う前に、それぞれのデータセット内で結合キーが本当に一意であるかを確認することが非常に重要だ。そして、結合後に期待される行数と、実際に出力された行数を比較することで、意図しないデータ増加が発生していないかをチェックするべきだ。
データ処理の作業に取りかかる前に、常に小さな、目で見て確認できるようなサンプルデータを用いて、「1行が具体的に何を意味するのか」ということを明確に定義し、検証する習慣をつけよう。これは、大きなデータファイルを処理する際の潜在的な問題を早期に発見し、正確なデータ処理を実現するための、システムエンジニアとしての基本中の基本であり、非常に重要なスキルとなる。