商品マスタ移行とは、旧システムに登録されている商品（品目）の一覧を、新しいCRMの商品モジュールへ移し替える作業です。見積・受注・発注の明細はすべて商品を参照するため、ここで1件の取り違えがあると、移行後の取引データがまとめてずれます。
当社は、中小の製造業（個別受注生産）で、旧販売管理システムからZoho CRMへの移行を支援しました。移行するデータは、旧システムから書き出したうえで、お客様に内容を確認していただいたCSVにしました。
ここで迷ったのが重複の扱いです。外注品のCSVは「商品名」「仕入先名」の2列で、同じ組み合わせの行がたくさん並んでいました。普通に考えれば重複です。しかし、旧システムのデータまで遡ると、その多くは別の商品でした。この記事では、なぜ「商品名＋仕入先名」で重複を消してはいけないのか、代わりに何をキーにするのか、投入前に何を確かめるのかを、チェックリストの形でまとめます。
SalesforceからZoho CRMへ移す場合の項目の洗い出しは、SalesforceからZoho CRMへ移行する前に確認すべきデータ項目で、移行する項目の対応付けの確かめ方はデータ移行のマッピング表でZoho CRMへの移行漏れを防ぐ方法で扱っています。この記事は、その中でも商品マスタの重複判定に絞った姉妹記事です。
なぜ「商品名＋仕入先名」で重複削除してはいけないのか
外注品：約4割は商品コードが違う別物
外注品のCSVで、同じ「商品名＋仕入先名」が複数行あった組み合わせは、多数ありました。旧システムのデータと突き合わせて、組み合わせごとに商品コード・規格・仕入伝票の数を数えたところ、次のように分かれました（移行準備の時点）。
| 分類 | 組み合わせに占める割合 | 扱い |
|---|---|---|
| 商品コードが1つだけ（同じ商品が伝票ごとに何度も出ている） | 約6割 | 本当の重複。1件にまとめてよい |
| 商品コードが2つ以上（規格や図面が違う別の商品） | 約4割 | 重複ではない。まとめてはいけない |
たとえば、ある外注品は同じ商品名・同じ外注先で非常に多くの行が並び、商品コードもほぼ同じ数だけ、規格もさまざまでした。図面ごとに別の商品として登録されていたのです。2列だけで重複削除すると、これが1件になります。
販売品：同名の商品は、すべて商品コードが違っていた
製造して販売する商品のCSVには、そもそも商品コードの列がありませんでした。同じ商品名が複数行ある名前は非常に多く、旧データで確かめると、そのすべてで商品コードが違っていました。「運賃」「値引」のような名前は、それぞれ多数の行が、すべて別のコードで登録されていました。材質や図面番号も行ごとにばらばらです。
別の商品を1件にまとめると何が起きるか
別の商品を1件にまとめると、次のことが起きます。
- 旧システムの見積・受注・発注の明細を移したときに、どの商品を指していたかが分からなくなる
- 規格・材質・図面の情報が1件分しか残らず、残りは失われる
- 連携先のシステム（生産管理など）が品目コードで商品を区別している場合、送る品目が足りなくなる
件数が減ってCSVがすっきりするので、重複削除は「正しい作業」に見えます。だからこそ、消す前に旧データまで遡って確かめる必要があります。
チェックリスト1：商品マスタの一意キーは何にするか
- 旧システムの商品コードを、CRMの「商品コード」項目に残すか
- 商品コードの項目を、重複を許可しない設定にできるか確かめたか（できなければ、チェックリスト4の読み戻しで代わりにする）
- 移行用CSVから商品コードの列が落ちていないか。落ちていれば旧データから付け直した版を作る
- 商品コードが空の行だけ、「商品名＋仕入先名＋規格」など複数の列の組み合わせで代わりのキーを作るか
- 本当の重複（同じ商品コードが伝票ごとに出ているだけ）は、商品コードで1件にまとめたか
今回は、旧システムの商品コード・仕入先コード・規格・伝票番号を残した「再生成版」のCSVを作り、これを取り込み用の土台にしました。お客様が確認した2列のCSVは捨てず、内容の確認結果として突き合わせに使います。
1つのコードだけでは一意にならない場合（区分ごとに同じコードが使われている場合など）は、区分とコードを組み合わせたキーにします。考え方は基幹CSV取込で得意先コードが重複したときの複合ユニークキーの設計で紹介しています。
チェックリスト2：仕入先名の表記ゆれはどう対応付けるか
外注品や原材料のCSVに出てくる仕入先名は、旧システムの表記のままでした。区分を表す記号が名前の末尾に付いていたり、営業所名の有無が違ったりします。CRMでは商品から仕入先をルックアップ（参照）で結ぶため、どの仕入先レコードに当たるかを1件ずつ決める必要があります。
- CSVに出てくる仕入先名を重複なしで洗い出したか
- 確認済みの仕入先マスタへの対応候補を、一致の根拠と点数つきで出したか
- 候補を信頼度別に分けたか
- 旧システムの仕入先コードが残っていれば、それも手がかりにしたか
- 変換候補表をお客様に確認していただき、確認済みのものだけを正式な変換表にしたか
今回の分け方は次のとおりです。
| 信頼度 | 割合（目安） | 内容 |
|---|---|---|
| 高信頼 | 約4割 | 表記をそろえると名前が完全に一致する |
| 候補あり | 約3割 | 名前の一部が一致する。営業所違いなどが混ざる |
| 旧コードから確認 | 約2割 | 名前では決まらず、旧仕入先コードで照合する |
| 追加確認 | 1割未満 | 手がかりが足りない |
点数の高い候補でも、自動では確定しませんでした。部分一致では、同じ会社の営業所と、経費用に別登録された同じ会社が並んで候補になることがあり、どちらが正しいかは業務を知っている人にしか決められないためです。重複の候補を出しても自動ではまとめない考え方は、Zoho CRMの重複チェックは自動マージしない設計にでも整理しています。
チェックリスト3：機械で決めないものを分けておく
データを見ただけでは決められないものがあります。これらは無理に決めず、「保留」として分け、お客様の判断を待ちました。
- 同じ名前で住所が違う取引先・仕入先：別拠点として残すか、同じ会社として統合するか
- 移行先に対応する種別がない区分（今回は経費の区分）：移行しないか、種別を追加するか
- CRMに同じ正式名称の仕入先が既に複数ある：どの仕入先レコードに紐付けるか（決まるまで該当の商品は投入しない）
- 商品名が空、単位が空、単位が選択リストにない行：登録するか、何を入れるか
- 登録不要とお客様が判断した行：除外した理由を残したか
今回は、不足項目を行ごとの質問票にしてお客様に記入していただきました。販売品で商品名が空だった行は、一部を登録し、残りを登録不要と判断していただいています。
チェックリスト4：投入前に読み戻し、投入可と保留に分ける
- 投入する行の商品コードで、CRMに既に同じコードがないかをCOQL（SQLに似た検索）で読み戻したか
- 読み戻しの結果で、投入可（READY）と保留（BLOCKED）にファイルを分けたか
- 既にCRMにある商品コードの行は、再投入しないか（更新するなら別の手順にする）
- 商品モジュールの項目定義を読み戻し、投入する項目が本番に存在し、型が合っているか確かめたか
最後の項目は、実際に引っかかりました。図面番号を入れるつもりだった項目が、本番ではチェックボックス型でした。単価の項目は本番の商品モジュールに存在しませんでした。サンドボックスや設計書ではなく、投入先の本番から項目定義を取ってから、投入データの形を決めます。
読み戻しの例です（項目名は一般的な名前です）。
select id, Product_Code, Product_Name from Products where Product_Code in ('01234567890', '01234567891') limit 200COQLは1回の問い合わせで返る件数に上限があります（当社が確認した時点の既定は200件）。投入する商品コードが多いときは、コードを小分けにして何度か問い合わせるか、limit と offset で送って最後まで読みます。一部だけ読んで「重複なし」と判断しないようにします。
チェックリスト5：ワークフローを起動させず、取り消し方を先に決める
- 商品の作成をきっかけに動くワークフロー（外部システムへの送信など）がないか確かめたか
- 移行の投入では、レコードAPIに
"trigger": []を付けて自動処理を起動させないか - 作成されたレコードのIDを応答から記録し、取り消すときは「そのIDだけを削除する」と決めたか
- 少数を投入して読み戻し、内容が合っていることを確かめてから全量へ進むか
- 件数が多い場合、レコードAPI（当社確認時点で1回100件まで）ではなく一括書き込みや画面のインポートを使うか
投入用のリクエストは、次のような形です。
{
"data": [
{
"Product_Name": "部品A",
"Product_Code": "01234567890",
"Product_Active": true,
"Type": "外注",
"Usage_Unit": "個",
"Specification": "規格の文字列"
}
],
"trigger": []
}公式ドキュメント（Insert Records）では、"trigger": [] を付けるとワークフローなどの自動処理を起動せず、キーそのものを送らないと関係する自動処理が実行される、と説明されています（当社が確認した時点）。逆に、仕入先を登録したら外部システムへも送りたい場合のように、移行の目的によってはワークフローを動かすこともあります。今回も、仕入先の登録では外部システムへの連携を兼ねてワークフローを起動させ、商品の追加投入では起動させませんでした。どちらにするかを、投入ごとに決めて記録しておきます。
まとめ
「商品名＋仕入先名」が同じ行は、重複に見えて別の商品であることがあります。理由は単純で、移行用に整えたCSVからは、旧システムで商品を区別していた商品コード・規格・図面が落ちているからです。
重複を消す前に旧データまで遡り、旧システムの商品コードを一意キーとして残します。仕入先名の対応付けや同名の取引先のように、データだけでは決められないものはお客様に判断していただきます。投入の直前には、本番から読み戻して投入可と保留に分け、自動処理を止めて、取り消し方を決めてから入れます。この順番を守れば、移行後に「どの商品の話か分からない」明細を生まずに済みます。
旧販売管理からZoho CRMへの移行全体の進め方を相談したい場合は、販売管理システムとCRMの統合構築サービスのページをご覧ください。
よくある質問
本当に重複している行もあるのでは？
あります。今回の外注品では、重複に見える組み合わせの約6割は、同じ商品コードの行が仕入伝票ごとに何度も出ていただけでした。これは1件にまとめて構いません。問題は、商品コードが違う行まで同じ基準で消してしまうことです。まとめてよいかは、商品コードで判断します。
旧システムの商品コードをCRMに持たせる項目はどれがよいですか？
Zoho CRMの商品モジュールにある「商品コード」項目を使うのが分かりやすい方法です。連携先のシステムが品目コードで商品を識別する場合も、同じコードを渡せます。重複を許可しない設定にできるかは項目によって異なるため、設定画面で確かめてください。設定できない場合も、投入前にCRMから読み戻して重複を確かめれば、同じ役割を果たせます。
仕入先名の表記ゆれは、あいまい一致で自動変換してはいけませんか？
候補を出すまでは自動で構いませんが、確定は人が行ってください。今回も、部分一致では同じ会社の営業所と経費用の登録が並んで候補になるなど、一致度だけでは選べない例がありました。信頼度で分けておくと、お客様が確認する量を減らせます。
数万件の商品をAPIで一度に入れてもよいですか？
当社が確認した時点の公式ドキュメントでは、Zoho CRMのレコードAPIで一度に作成できるのは100件までです。件数が多い場合は、一括書き込み（Bulk Write）や画面のインポートの方が運用しやすくなります。いずれの方法でも、少数で読み戻して確かめてから全量へ進めてください。
