CSV取り込み機能の開発依頼｜エラーと再実行まで要件にする

CSV取り込み機能の開発要件は、「CSVをアップロードできること」だけでは見積もれません。受け付けるファイル、エラー時に登録する範囲、重複の判定、修正後の再実行までを一つの受入表にすると、開発会社は対象処理を見積もりやすくなり、発注者も納品時に完成を判定できます。

とくに先に決めたいのは、不正な行が混じったときに全件を取り消すか、正常行だけを登録するかです。同じ入力ファイルでも、この選択によって登録結果と再実行の手順が変わります。ただし、失敗単位だけを選んでも足りません。部分成功したファイルをそのまま再送したとき、登録済みの行をどう見分けるのでしょうか。そこまでつながった条件が、追加見積の前提になります。

CSV取り込みの開発要件は「読める」より「判定できる」で書く

CSVという名称から、開発側が列や文字コードを一意に推測できるとは限りません。2026年9月21日時点で、RFC 4180はCSVに単一の正式仕様がなく、実装ごとに幅広い解釈があることを前提に、一般的な形式を文書化しています。一般形式ではヘッダーは任意です。ヘッダーがある場合は後続レコードと同じフィールド数とし、ファイル内の各行も同じフィールド数にするとされています。また、text/csvの文字コードとヘッダー指定も任意のパラメーターです。

したがって、「一般的なCSVに対応」という要件では、見積もりにも受け入れにも使えません。発注者は、自社が正として渡すファイルと、業務を続けられる処理結果を決めます。技術的な実装方法は、その条件を満たす手段として開発会社と詰めます。列名と列順を固定するか、必須列が欠けたら拒否するか、定義外の列を無視するか拒否するかを明記してください。区切りや引用符を含む値の条件も、実際に出力元が作るサンプルファイルと合わせて渡します。

全体の発注条件から整理したい場合は、システム開発の要件定義チェックリスト｜外注前に決める10項目も併せて確認してください。CSV取り込みは、その中のデータ、例外処理、受け入れ条件を具体化する作業です。

見積依頼と納品確認に使う受入表

次の表は、顧客台帳へCSVを取り込む場合の運用上の提案です。公式資料が一律に定める必須仕様ではありません。これをたたき台に、自社の出力元と更新業務に合わせて「採用する条件」欄を書き換えます。未決の行には、決定者と決定時期を添えて見積依頼時に伝えます。

表の各行は連動します。たとえば既存データを上書きするなら、業務レコードの重複判定キーを誤ったときの影響も変わります。正常行だけを登録するなら、結果一覧に登録済みか未登録かがなければ、担当者は安全な再取込対象を選べません。受入表は、登録結果と次の操作を人が説明できる状態を作るためのものです。

形式エラーと業務エラーを分ける

2026年9月21日時点で、OWASPのInput Validation Cheat Sheetは、入力を受け取った後のできるだけ早い検証を示し、構造化項目の形式を確かめる構文検証と、業務文脈で値の正しさを確かめる意味検証の両方を求めています。この区別を受入表へ置き換えると、エラー表示と見積範囲が明確になります。

顧客台帳の例なら、列数が合わない、必須の顧客コードが空であるといったものは形式側の条件です。一方、入力された部門コードが既存台帳にない、状態の組合せを業務上認めない、顧客コードがすでに存在するといったものは業務側の条件です。どちらも「取り込めませんでした」だけで返すと、利用者は直す場所を判断できません。

受入条件には、検出する条件とともに、利用者へ返す行、列、理由を書きます。ファイル全体の問題はファイル単位で示す、といった違いも残します。エラーメッセージの文言を後工程で確定する場合も、修正すべき場所と理由を特定できることは納品条件に含めます。

全件取消か部分成功かで、再取込の対象が変わる

全件取消は、不正行があれば正常行も登録しない考え方です。この条件なら、修正版にはファイル全体を含めて再実行する運用を設計できます。部分成功は正常行を登録し、不正行を残す考え方です。この場合、修正版へ不正行だけを入れるのか、元の全行を入れても登録済みを識別できるようにするのかを決めなければなりません。どちらを採用するかはAWSの冪等性に関する解説から決まるものではなく、対象業務に応じて発注者と開発会社が合意する別の選択です。

迷う場合は、エラー後に担当者が実際に持てる情報から逆算します。登録済みの行を確実に判別できず、既存データの上書きも許さないなら、部分成功後の全行再送は重複エラーを生みます。結果一覧から未登録行を選び直せる業務では、部分成功を運用に組み込めます。結果確認と修正を誰が担うかまで決めたうえで、一つの方式を選びます。

この差は追加範囲の判断にも使えます。当初合意が全件取消なのに、納品段階で正常行だけ先に登録し、未登録行を一覧で返し、その一覧から再取込したいとなれば、失敗単位、結果管理、再実行条件が変わります。表示修正の範囲を超えるため、受入表の複数行を更新する要求として影響を確認します。見積項目の読み方や変更時の確認は、システム開発の見積もりの取り方と内訳｜妥当性の判断基準も参考になります。

再実行は操作と結果を一組で決める

2026年9月21日時点で、AWS Builders’ Libraryの再試行と冪等性に関する解説は、要求を再送・再試行しても追加の副作用が生じない操作を冪等な操作と説明しています。また、同じ呼出元から同じ一意な要求識別子で届く要求を重複として扱える契約を紹介し、同じパラメーターだけで重複を推定すると、同内容を意図的に複数回実行した場合と区別できないと説明しています。

この考え方からCSV取り込みの再実行条件を組み立てるなら、ファイル名や内容が同じというだけで再送と決めつけないことが要点です。同じ内容を別の機会に正当に登録する可能性があるからです。取込要求全体に付けるrequest identifier（要求識別子）を何にするか、同じ識別子の再送へ何を返すか、内容を修正したファイルを新しい取込として扱う条件は何かを決めます。さらに、利用者が前回の結果を確認できなければ、再送してよいか判断できません。

要求識別子と、顧客コードなどの業務レコード重複判定キーは別物です。前者はCSV取込要求全体の再送を識別し、後者はファイル内の行と既存台帳のレコードが同じかを判定します。要求識別子が一致しても各行を顧客コードとして扱うわけではなく、顧客コードが一致しても常に同じ取込要求とは限りません。この二つを一つの「重複チェック」にまとめず、受入表と見積項目を分けます。

納品時には二つの動作を確認します。一つは、同じ取込を再送しても二重登録されないこと。もう一つは、修正版を新しい取込として処理できることです。識別、結果確認、新規扱いの条件を一組にすると、重複を防ぎながら正当な新規取込を通せるか判定できます。

追加見積へ渡す前の最終確認

開発会社へ渡す資料には、受入表、出力元が作るサンプルCSV、列の意味、既存台帳との照合条件をそろえます。サンプルには、確認に必要な条件を表せるデータを用意し、個人情報などを含む実データの無条件な提供は避けます。未決事項には、決定者と決定時期を添えます。

確認の軸は次のとおりです。

• 文字コード、ヘッダー、列、区切り、引用符について、受け付ける条件と拒否する条件がある
• 形式エラーと業務エラーを分け、行・列・理由の返し方が決まっている
• 業務レコードの重複判定キーと、既存データを拒否・上書き・更新する条件が対応している
• 全件取消か部分成功かを選び、登録結果と修正対象を確認できる
• 取込要求の識別子を業務レコードの重複判定キーと分け、同じ取込の再送と修正版の新規取込を区別できる

部分成功したCSVを再送するときは、要求識別子で同じ取込要求かを判定し、各行の登録結果と業務レコードの重複判定キーで再取込の対象を決めます。その仕組みと前回結果の確認手段まで必要なら、見積範囲に含めます。そこまでの管理を求めない場合は、全件取消など業務で扱える条件を選び直します。納品時には、エラー後も担当者が登録結果を説明でき、重複登録を避けながら次の操作を選べることを、合意したサンプルCSVで確認します。

費用、期間、契約、法務・税務上の扱いは条件により異なります。記事の確認日とリンク先の一次情報を確認し、個別判断は専門家へご相談ください。

システム開発・発注ガイドへ戻る