CSV一括登録・更新の設計｜差し戻しが起きない入力ルールと検証フロー

CSV取り込みは「現場が自力でメンテできる」強い手段ですが、設計が甘いと事故の温床になります。
典型は、列の意味が曖昧・表記揺れ・必須漏れ・更新対象の判定ミス・取り込み後に気づく誤登録です。
この記事では、CSVを“運用として回す”ために必要な仕様を、データ定義から検証・差し戻しまで整理します。

1. CSVで“何を”メンテするのかを先に限定する

CSVで何でもできるようにすると、誰も使えなくなります。
まず「CSVでメンテする対象」を限定します。例は次のとおりです。

• 向いている：商品マスタ、拠点マスタ、担当者、価格表、カテゴリ、予約枠の定義
• 慎重に：ステータス付きの取引データ（受注・問い合わせ・予約本体）
• 向かない：履歴（監査ログ）、請求・決済の確定情報

“慎重に”の領域は、ステータス運用（ステータス設計）やログ（権限・ログ）と衝突しやすいからです。
たとえば「問い合わせをCSVで一括で完了にする」は可能でも、説明責任が崩れます。

2. キー設計：新規・更新を判定する“唯一の軸”を決める

CSVの事故で多いのは、更新対象がズレることです。
そのため、更新判定のキーは、現場が理解でき、かつ一意である必要があります。

• 商品：型番/品番（関連：型番検索UX）
• 拠点：拠点コード（関連：拠点検索）
• 担当者：社員番号/担当コード（関連：割当ロジック）
• 価格表：適用開始日＋条件キー（関連：料金テーブル更新）

3. 列定義：必須/任意を“取り込み仕様”として固定する

CSVは、フォームよりも入力の自由度が高い分、必須/任意の基準がブレると破綻します。
考え方はフォーム設計（必須・任意の基準）と同じで、
「後工程で詰まるなら必須」「なくても業務が回るなら任意」に寄せます。

また、選択肢がある列は「自由入力」にせず、コード化・正規化します。
カテゴリや種別を自由入力にすると、集計（レポート）が死にます。

4. 検証（バリデーション）は“取り込み前”に返す

取り込み処理が途中で止まるのは最悪です。理想は「全行検証→エラー一覧返却→修正→再アップ」です。
エラー文言は、フォームのエラー設計（文言と位置）と同じく、
「どの行のどの列が、何が原因で、どう直せば良いか」まで返します。

• 行番号（CSVの行）
• 列名（ヘッダ名）
• 入力値（問題の値）
• エラー理由（形式・未定義コード・必須欠落など）
• 修正例（期待する形式）

「一部だけ成功、一部失敗」も実務では必要ですが、最初は“全体を安全に”運用できる形を優先したほうが事故が少ないです。

5. 取り込み履歴・戻し（ロールバック）の考え方

CSVは一気に大量更新が走るため、「やっぱ戻したい」が必ず起きます。
最低限、次の情報は履歴として残します。

• 誰が（アカウント）
• いつ（取り込み日時）
• 何を（対象テーブル/種別）
• 件数（新規/更新/スキップ/エラー）
• 元ファイル（ダウンロードできるなら最強）

権限・ログは 権限・ログ設計 と整合し、
少なくとも「CSV取り込みは管理者のみ」「履歴閲覧は閲覧権限でも可」など、運用に合わせて線引きします。

業種別の典型

卸売・商社（品番・価格・ロット）

価格表や在庫情報の更新が多く、CSVが主役になりやすい領域です。
業務像は 卸売・商社（BtoB企業）向け を前提に、
ロット・納期・分納条件（関連：商社の見積項目）がCSV列に反映される設計が現実的です。

自動車販売・整備・タイヤショップ（価格表・作業メニュー）

タイヤサイズ、作業工賃、持込可否、部品種別など“更新頻度が高いマスタ”が多いです。
業務像は 自動車販売・整備・タイヤショップ向け を前提に、
工賃表の更新はCSV、予約枠は画面で調整（関連：時間枠設計）など、役割分担を決めると運用が回ります。

インテンスとしても、CSVは「自由に編集できる」より「事故らない」設計を優先したほうが、長期運用で得になります。

まとめ

CSV取り込みは、仕様が“運用そのもの”です。
対象を限定し、更新キーを固定し、必須/任意とコード体系を揃え、取り込み前検証で差し戻し可能にする。
さらに履歴と権限を固めれば、CSVは現場の武器になります。