CSV取込の要件は、正常なファイルを登録できることだけでなく、誤りを含むファイルをどう止め、利用者がどう直し、再実行したときに何が起きるかまで決めます。行ごとの検証と保存の順番が曖昧だと、一部だけ登録されたことに気づかず同じデータを再登録する恐れがあります。取込の単位と再実行の扱いを先に定義してください。
ファイルと項目の約束を明確にする
区切り、文字コード、見出し行、列の順番、日付の形式、改行を含む値の扱いを決めます。表計算ソフトで開いて保存すると、先頭のゼロや日付の表記が変わる場合があります。識別番号を文字として扱うかなど、データの意味に応じた条件を明示します。見た目が同じでも値が違う場合があることに注意してください。
列が足りない、余分な列がある、同名の見出しがある場合の動作も要件に含めます。見出しで対応付ける方式なら、順番が変わってもよいかを決めます。利用者が使うひな形には、必須項目、許される値、空欄の意味、入力例を示し、古いひな形が残った場合の扱いも確認します。
検証の順序とエラー区分
ファイルを読めるか、列が揃っているか、各値の形式が正しいか、業務上登録できる値かを分けて検証します。例えば日付として読めても、締め済みの期間への登録が認められない場合があります。形式の検証と業務条件の検証を同じ「入力エラー」でまとめると、何を直せばよいか伝わりません。
関連する番号が存在するか、登録する権限があるか、同じ番号がファイル内で重複していないかも確認します。空欄を削除とみなすのか、変更しないという意味にするのかは更新取込で重要です。既存の値を意図せず消さないよう、追加と更新を区別し、利用者に結果を予測できる説明を用意します。
全体停止か部分成功かを選ぶ
一件でも誤りがあれば全件を保存しない方法と、正しい行だけを保存する方法があります。どちらが適するかは業務のまとまりによります。複数行が一つの伝票を作る場合、明細の一部だけ保存すると不整合になるため、行ではなく伝票を単位に判定する設計を検討します。
部分成功を認めるなら、保存済みと未保存を明確に分け、再実行で保存済みの行をどう扱うかを決めます。同じファイルを再送した際に重複するのか、既存値を更新するのか、未保存だけ扱うのかを仕様にします。「エラーを直してもう一度」と表示するだけでは、利用者が安全な再実行方法を判断できません。
エラー表示の記入例
エラーには、行や対象の識別子、列名、理由、修正のヒント、保存の有無を示します。ファイルに機密情報がある場合は、画面やログに値をそのまま出す範囲にも注意します。内部の処理文やデータベースの詳細を利用者へ見せるのではなく、修正に必要な情報として整理してください。
想定例として、顧客番号が未登録の明細が含まれる場合を考えます。「顧客番号を確認してください」とだけせず、対象行と列、参照する顧客一覧、先に登録が必要かを伝えます。ひな形の項目表には「列名」「必須条件」「形式」「業務条件」「空欄の意味」「エラー時の対応」を記入すると説明を揃えられます。
実行結果と復旧を確かめる
取込後は、対象件数、成功、失敗、保留の区別を表示し、登録結果を一覧から確認できるようにします。実行の識別子、日時、実行した人、使ったひな形の版などを記録すると問い合わせに対応しやすくなります。記録を残す範囲と保存期間は、扱う情報と運用に応じて決めてください。
試験には、空のファイル、列の不足、文字の混在、重複、存在しない参照先、処理途中の失敗を含めます。通信が切れた際に利用者へ結果が届かなくても、処理が完了している場合があります。再送前に結果を確認できるか、途中状態をどう扱うかを検証します。大量取込を想定するなら、処理中の表示と重複実行の防止も確認します。
よくある疑問
取込前のプレビューは必要でしょうか。更新や削除を伴う場合、変更の見込みを確認できると誤操作を発見しやすくなります。ただし、プレビュー後に元データが変わる可能性もあるため、実行時にも必要な条件を検証します。
エラーのある行を自動で補正してよいでしょうか。意味が確定する表記の統一と、業務内容を推測する補完は分けます。顧客や数量を推測で直さず、利用者が確認できる形で戻してください。補正する場合も、何を変えたかを結果として示すことが、誤登録を避けるために重要です。
関連サービスと基礎資料
システム・アプリ開発の対象範囲もご確認いただけます。
本記事の手順・確認項目は一般的な検討のための提案です。AIを使って草案を作成し、構成・表現の点検を行っています。個別の契約・運用条件は実際の環境に合わせて確認してください。