通販受注データのCSV連携方法と電帳法対応

◆監修・編集責任者　小園 将隆　2026年8月25日

B2B EC-COLUMN

通販の受注データのCSV連携とは

通販の受注データのCSV連携とは、自社ECやモールから出力した受注情報をCSV形式のファイルにまとめる連携方式です。基幹システムや販売管理システム、倉庫管理システム（WMS）へ受け渡す用途に使われます。手作業でのダウンロード・アップロードから、FTPS（ファイル転送のセキュリティ規格）による自動取得まで、実装の幅があります。

通販の受注データをCSVで連携する方法には、主に3つの型があります。手動アップロードは、担当者が受注CSVをダウンロードし、取り込み先システムへその都度アップロードする方法です。自動取得は、FTPSやAPIを介して一定間隔でファイルを取得し、取り込み処理まで自動化する方法です。API連携は、CSVというファイル形式を介さず、システム同士がリアルタイムでデータを受け渡す方法で、CSV連携とは別の連携方式に位置づけられます。

CSV連携がつなぐ業務範囲は、受注の受け付けから在庫引当、出荷指示、売上計上までの一連の流れです。この連携が滞ると、在庫の引当漏れや出荷遅延につながりやすくなります。データの受け渡し方式を選ぶ前に、まずどの業務がCSVを介してつながっているかを棚卸しすることが出発点になります。

手動アップロード・自動取得・API連携の違い

手動アップロードは初期コストを抑えられますが、取引件数が増えるほど担当者の作業時間が積み上がります。自動取得は定型的な受け渡しを省力化できる一方、取込先の項目仕様が変わった際には設定変更が必要です。API連携はリアルタイム性に優れるものの、双方のシステムが対応している必要があり、CSV連携よりも導入の初期検討事項が増えます。

受注から売上計上までつながる業務範囲

受注データのCSV連携は、受注確定後の在庫引当、出荷指示書の発行、出荷完了後の売上計上という一連の業務と連動します。どこかの工程でデータの受け渡しが止まると、後続の工程全体が滞留するでしょう。連携範囲を明確にしておくことで、障害時に影響が及ぶ範囲を把握しやすくなります。

CSV連携の4ステップ——出力・マッピング・取り込み・突合

受注CSV連携の作業は、大きく4つのステップに分かれます。それぞれのステップで実行者・入力・出力・確認方法を明確にしておくと、連携の途中で問題が起きた際に原因を特定しやすくなります。

1. 出力元（自社EC・モール管理画面）から受注CSVを出力します。実行者は受注担当者、入力は対象期間の指定、出力は受注データを含むCSVファイルです。出力後は件数が想定と一致しているかを確認しましょう。
2. 出力したCSVの列と、取り込み先システムが求める項目とのマッピング（対応付け）を決めます。文字コードや区切り文字の変換ルールもこの段階で確定するのが基本です。担当者はシステム管理者が兼ねることが多く、変換ルールの文書化が欠かせません。
3. 変換したCSVを取り込み先（基幹システム・販売管理システム・WMS）へインポートします。取り込み時にエラーチェック機能があるシステムでは、形式不備の行がここで検出されるでしょう。
4. 取り込み件数と出力元の件数を突合し、一致しない場合はエラー行を出力元へ戻して再処理します。この突合を省略すると、取り込み漏れに気づかないまま出荷指示が進んでしまいます。

自社の数字で確かめる

手動でのCSV連携は、取引件数が増えるほど確認・突合にかかる時間が積み上がります。自社の受注件数・取引先数の規模で、この作業にどの程度の時間がかかっているのかを一度数字で確かめると、次の判断軸が見えやすくなります。無料相談で要件を整理するのも一つの方法です。

受注CSVの項目設計と、つまずきやすい落とし穴

受注CSVで最低限そろえたい項目は、注文番号・受注日時・顧客情報・明細（商品コード・数量・単価）・配送先・決済区分・金額です。これらの項目が欠けると、取り込み先で売上計上や出荷指示に必要な情報が不足します。

文字コード・改行コード・区切り文字は、出力元と取り込み先で一致させる必要があります。UTF-8とShift_JISが混在すると文字化けが起こりやすく、改行コード（CR・LF・CRLF）の違いも取り込みエラーの原因になります。各モール・カートの出力仕様は提供元の公式ドキュメントで確認することが前提です。

先頭ゼロ落ち・桁あふれ・全角半角ゆれ

電話番号や郵便番号の先頭ゼロは、表計算ソフトで数値として開くと消えてしまう事故が起きやすい項目です。金額欄の桁あふれや、全角・半角の混在も、取り込み先での照合エラーにつながります。列の型（文字列・数値）をあらかじめ固定しておくことが、この種の事故を防ぐ出発点になります。

差分連携か全件連携か——重複取り込みの防止キー

受注データを差分連携する場合、注文番号のような一意のキーで重複取り込みを防ぐ設計が必要になります。全件連携では毎回全データを上書きするため重複は起きにくいものの、データ量が増えるほど処理時間が延びます。どちらを選ぶかは、取引件数と更新頻度に応じて決める事項です。

電子帳簿保存法の観点で受注CSVの保存を点検する

受注データのやり取りが電子取引に該当する場合、電子帳簿保存法上の保存要件が及びます。電子取引とは、契約書・領収書・請求書など通常紙で保存される情報を、電子メールやウェブサイト、クラウドサービスなど電子的方法でやり取りすることを指します^*3。モールやECの管理画面から受注CSVをダウンロードして基幹システムへ取り込む一連の流れも、この電子取引に該当する場合があります。

該当する場合に満たすべき要件は、真実性の確保と可視性の確保の2つです。真実性の確保では、タイムスタンプの付与や訂正・削除の記録が残る仕組み、あるいは訂正・削除の防止に関する事務処理規程の備え付けなどが求められます^*1。可視性の確保では、保存したデータを整然とした形式および明瞭な状態で、パソコン等の画面・書面に速やかに出力できることが求められます^*1。

検索機能の要件

可視性の確保には検索機能の確保も含まれます。具体的には、取引年月日・取引金額・取引先を検索条件として設定できることが第一点です。日付や金額の範囲を指定して検索できることが第二点、2つ以上の記録項目を組み合わせて検索できることが第三点です^*1。なお、個人事業者は前々年、法人は前々事業年度の売上高が5,000万円以下である場合、または電磁的記録を出力した書面を取引年月日その他の日付および取引先ごとに整理して提示・提出できるようにしている場合は、検索機能の確保そのものが不要とされています^*2。ただしこの場合も、税務調査の際に税務職員からのダウンロードの求めに応じられる状態にしておく必要があります^*2。自社が対象になるかどうかは、要件の細部を国税庁の一問一答原文で確認することが前提になります。

CSVという「文字の羅列」でも要件を満たせるのか

受注CSVはテキスト形式のデータであるため、それ自体は要件を満たすかどうかを左右しません。要件を満たすかどうかは、保存の仕組み（訂正・削除の履歴管理や事務処理規程の有無）と、検索機能をどのように確保するかという運用面にかかっています^*1。受注CSVをそのままフォルダに置いているだけでは、検索機能の要件を満たしていない可能性があります。該当する場合に何が必要になるかは、個別の状況によって判断が異なるため、所轄の税務署や税理士への確認が必要となる場合があります。

受注CSVは個人データを含む｜安全管理と漏えい時の対応

受注CSVには、氏名・配送先住所・電話番号といった個人データが含まれます。メール添付やUSBメモリで受け渡す場合は、宛先の誤りや媒体の紛失といったリスクを踏まえた運用ルールの検討が欠かせません。

授受・保管の方法を決める

受注CSVを受け渡す媒体、アクセス権限を持つ担当者の範囲、保管場所を事前に決めておくことが、個人データの安全管理の出発点になります。権限を持たない担当者がCSVを開ける状態は、意図しない持ち出しのリスクを高める要因です。

漏えい等が起きたときの報告と本人通知

個人データの漏えい等が発生し、個人情報保護委員会への報告対象となる事態に該当する場合、報告の期限が定められています。速報は発覚から3〜5日以内、確報は30日以内（不正の目的をもって行われたおそれがある場合は60日以内）です^*4。報告対象となる事態には4つの類型があります^*4。一つ目は要配慮個人情報が含まれる個人データの漏えい等、二つ目は不正に利用されることにより財産的被害が生じるおそれがある個人データの漏えい等です。三つ目は不正の目的をもって行われたおそれがある行為による漏えい等、四つ目は本人の数が1,000人を超える漏えい等です^*4。報告対象に該当する場合は、原則として本人への通知も必要になります^*4。

CSV連携を続けるか、EDI・APIへ進むかの判断軸

CSV連携は、取引先数が少なく、取引先ごとの形式差にも個別対応できる規模であれば、初期コストを抑えたまま運用できるでしょう。取引先数が増え、取引先ごとに異なる形式のCSVを個別に処理する負荷が積み上がってくると、限界が出やすくなります。

業界標準EDIという選択肢

小売・卸売業界には、流通BMS（流通ビジネスメッセージ標準）という業界標準の電子データ交換（EDI）規格があります。発注・出荷・受領・返品・請求・支払の6業務を対象に、基本形で8種の標準メッセージがXML形式で定義されている点が特徴です。現行の基本形バージョンは2018年11月公表のVer2.0です^*5。取引先が流通BMSに対応していれば、CSVの個別フォーマットに合わせる作業を減らせる可能性があります。

段階的な自動化の進め方——現行フローの棚卸しから始める

CSV連携をいきなり全面的にEDIやAPIへ切り替えるのは、現実的ではない場合が多くあります。まず現行フローを棚卸しし、どの工程が手作業で、どこに変換ルールが暗黙知として残っているかを明文化することが最初の工程になります。

並行稼働と突合期間の設け方

新しい連携方式を導入する際は、旧方式と並行稼働させ、一定期間データを突合して差異を確認する進め方が有効です。突合期間を設けずに切り替えると、取り込み漏れに気づかないまま本番運用に入ってしまうリスクがあります。

必要な知識と、内製・外部委託の切り分け

CSV連携の変換ルール設計を内製で行うには、複数領域の知識が必要になります。取り込み先システムの項目仕様、文字コード・区切り文字の実務知識、既存の受注フローの理解です。加えて、電子帳簿保存法や個人情報保護の要件を踏まえた運用設計も欠かせません。専門知識を持つ担当者を確保できない場合、変換処理の実装や移行設計の部分を外部パートナーに委ねる選択肢もあります。

まとめ：受注CSV連携を点検する3つの判断軸

本稿では、通販の受注データをCSVで連携する方法・項目設計の落とし穴・電子帳簿保存法の注意点を整理しました。要点を3つに集約すると次の通りです。第一に、CSV連携は出力・マッピング・取り込み・突合の4ステップで進み、各ステップの実行者と確認方法を明確にすることが事故防止の基本になります。第二に、文字コードや先頭ゼロ落ちといった項目設計上の落とし穴は、列の型と変換ルールを事前に固定することで防ぎやすくなります。第三に、受注CSVの授受・保存が電子帳簿保存法の電子取引に該当する場合は、真実性・可視性・検索機能の要件を点検する必要があります^*1。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

CSV連携とAPI連携はどちらを選ぶべきですか。

取引件数・取引先数の規模と、双方のシステムのAPI対応状況で判断します。取引先数が少なく初期コストを抑えたい場合はCSV連携、リアルタイム性を重視し双方がAPIに対応している場合はAPI連携が選択肢になります。

受注CSVの文字コードは何を指定すればよいですか。

出力元・取り込み先双方の公式ドキュメントで指定されている文字コードを確認し、UTF-8とShift_JISのどちらかに統一します。各モール・カートの仕様は提供元の公式ドキュメントで個別に確認する必要があります。

受注CSVをそのまま保存していれば電子帳簿保存法の要件を満たしますか。

該当する場合、CSVを保存しているだけでは要件を満たさない可能性があります。真実性の確保（訂正・削除の履歴管理や事務処理規程）が一つ、検索機能の確保がもう一つです^*1。検索機能は取引年月日・取引金額・取引先での検索、範囲指定検索、2項目以上の組み合わせ検索を指します。個別の判断は所轄の税務署や税理士に確認することをお勧めします。

取引先ごとにCSVの形式が違う場合はどうすればよいですか。

取引先ごとの形式差は、取り込み先システムの項目に合わせた変換ルールを取引先単位で用意することで対応します。取引先数が増えて個別対応の負荷が高くなった場合は、流通BMSなどの業界標準EDIへの移行が選択肢になります^*5。

受注CSVに含まれる個人データはどう管理すればよいですか。

受け渡す媒体・アクセス権限を持つ担当者の範囲・保管場所を事前に決めることが基本です。漏えい等が報告対象の事態に該当する場合は、速報3〜5日以内・確報30日以内（不正の目的による場合は60日以内）での報告と、本人への通知が必要になります^*4。

1. *1　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】Ⅱ 適用要件【基本的事項】」（常時更新）
2. *2　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】（PDF版）問21」（令和7年6月）
3. *3　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】Ⅰ 通則【制度の概要等】」（常時更新）
4. *4　出典：個人情報保護委員会「漏えい等の対応とお役立ち資料」（常時更新）
5. *5　出典：一般財団法人流通システム開発センター「流通BMS 標準仕様」（基本形Ver2.0＝2018年11月）