本文へスキップ
grsytools.jp

提出前・共有前の実務チェック

作業メモ

CSVのキー列と重複を確認する考え方

CSVの重複確認は、どの列をキーにするかを決めないと始められません。取り込み先で上書きや衝突が起きる前に、キー列と列順を確認します。

ページ更新日:

キー列を決めてから重複を見る

同じCSVでも、顧客IDで見るのかメールアドレスで見るのかで重複の意味が変わります。

  • 一意であるべき列を選ぶ

    ID、商品コード、請求番号など、同じ値が複数行に出ると困る列をキーにします。

  • 表示名や説明文をキーにしない

    名前やタイトルは同じ値が自然に出るため、重複検出の基準には向かないことがあります。

次にやること

1. キー候補の列を残す

まず必要な列だけを残し、キー候補を見つけやすくします。

2. キー列の重複を検出する

一意であるべき列を選び、重複キーと重複行を分けて見ます。

3. 後続形式へ渡す

重複の扱いが決まったら、取り込み先に合わせて変換します。

  • CSV→JSON

    取り込み先がJSONの場合に変換します。

  • JSON→CSV

    戻し確認や表形式の共有に使います。

詰まりやすい場面

  • CSVをインポートする前にID重複を確認したいとき
  • キー列にすべき列が顧客ID、メール、商品コードのどれか迷うとき
  • 列数を減らしてから重複チェックへ進みたいとき

具体例と判断基準

よくある失敗例

  • 姓だけを顧客キーにする

    業務上の一意性がない列を選ぶと別人を重複扱いします。必要なら元システムで複合キーを作ります。

  • 001と1を同じにする

    IDを数値化すると先頭ゼロを失います。文字列として読み込み、変換前後を確認します。

  • 空キーを全部同じ顧客とみなす

    空値は重複修正より先に、欠損として別キューへ分けます。

入力・作業サンプル

  • 単一キー例

    `customer_id` が `001`,`001`,`002`,空値なら、001の2行を重複、空値を欠損として別確認します。

  • 複合キー例

    注文番号単独で一意でない場合は、元システムまたは表計算で `注文番号|明細番号` の検査列を作り、その列を選びます。

before

目視で同じ名前を削除し、どの行を残したか、空白や大文字小文字をどう扱ったか記録がない。

after

キー定義、正規化ルール、重複グループ、残す行、修正理由を記録し、修正後CSVを同条件で再検査する。

この順番で見る理由

重複の定義を決める前に削除すると、別レコードの誤削除や表記ゆれの見逃しが起きるためです。原本を保存してからキーを検査します。

迷ったときの判断基準

  • 正規化する

    前後空白や大文字小文字を無視する合意がある場合だけ、原値を残して正規化列を作ります。

  • 原値のまま見る

    コード・ID・全角半角に意味がある場合は勝手に正規化せず別値として扱います。

関連ツールを使う流れ

  1. 列準備: CSV列抽出でキーと確認列だけの作業用CSVを作れます。
  2. 重複検出: CSV重複キー検出でグループと該当行を出します。
  3. 再検査: 修正後に同じキー・同じルールで重複0件と空値を確認します。

重複候補を自動削除せず、残すレコードを業務上の正本と照合してください。

作業を止めて確認する条件

  • 一意キーを説明できない
  • 複合キーが必要なのに検査列を作れない
  • 文字コードや引用符崩れで列がずれている
  • どの行を正本として残すか判断できない

ツールを使わない判断

データベースに一意制約や監査可能な重複解消処理がある場合は、それを正本にし、CSVツールは投入前の確認に限定します。

対象外: 複合キーの自動生成、類似名寄せ、重複行の自動削除、データベース制約の代替。

最終チェックリスト

  • 原本CSVを保存した
  • キーと正規化ルールを明記した
  • 空値と重複を別に扱った
  • 残す行の根拠を記録し、修正後を再検査した

まず開くツール

各段階で最初に開くものだけを並べています。

CSV列抽出・並び替え

確認に必要な列だけを選びます。

CSV重複キー検出

重複キーと該当行を確認します。

CSV→JSON

取り込み先がJSONの場合に変換します。

必要なら見るページ

用語や周辺ツールが必要なときだけ使います。