CSV/EDI/API連携の設計ポイント｜差分更新・エラー再処理で運用が止まらない作り方

データ連携は「取り込めたら終わり」ではありません。実務で困るのは、失敗したときと差分が来たときです。
CSVで毎日取り込む、EDIで受注が飛んでくる、APIで在庫が更新される——このとき、重複登録・欠落・順序の逆転・文字コード崩れなどが必ず起きます。
本記事では、差分更新・冪等性（同じデータを複数回処理しても壊れない）・エラー再処理を軸に「運用が止まらない連携設計」を整理します。

1. まず決める：連携は「差分更新」が前提

連携が不安定になる最大要因は、毎回「全件洗い替え」や「上書き前提」で作ることです。
現場では、同じ取引先でも住所が更新されたり、同じ受注でも分納になったりします。差分更新が前提です。

• 外部キー：相手側の一意ID（取引先コード、SKU、注文番号など）
• 差分判断：更新日時、バージョン番号、ハッシュ（内容が変わったか）
• 削除扱い：削除フラグで扱う（物理削除は原則しない）

製品や取引先などマスタが絡む場合は、管理画面で更新運用を回す方法と同じく「誰が正（マスター）なのか」を先に決めないと、差分更新が破綻します。

2. 冪等性：二重取り込みで壊れない“保険”を作る

CSVは再送されます。APIはタイムアウトで再試行されます。バッチは途中で落ちます。
この現実に耐えるには、冪等性を設計に入れるのが必須です。

問い合わせや予約のステータスを連携で更新する場合は、ステータス設計と整合が取れているか必ず確認してください。ここがズレると「勝手に完了になった」などの事故になります。

3. エラー再処理：現場が自力復旧できる設計にする

連携の品質は「失敗時にどう復旧できるか」で決まります。よくある“ダメ設計”は、失敗するとログにしか残らず、開発者がいないと復旧できない状態です。

3-1. 再処理に必要な情報

• 失敗した行（CSVの行番号、APIのペイロード）
• 失敗理由（バリデーション、参照先なし、型不一致など）
• 再処理ボタン（その行だけ、またはそのバッチだけ再実行）
• “保留”の逃げ道（参照先マスタが後で来るケース）

問い合わせ管理のダッシュボードで「保留」や「差し戻し」を扱う考え方は、運用ルールの整理と同型で考えると分かりやすいです。連携エラーも「放置される」ことが最大の損失です。

4. 連携順序：マスタ→取引→ステータス の原則を崩さない

実務では、連携順序が崩れるとほぼ必ず詰まります。基本は次の順番です。

• マスタ：取引先、商品、拠点、担当者など
• 取引：見積、受注、予約、問い合わせなどの本体
• ステータス：進捗、分納、検収、請求などの更新

もし現場都合で順序が崩れるなら、“保留キュー”を設けて後追いで整合させる方が事故が少ないです。
この「保留の設計」は、問い合わせ分類やタグの考え方（タグを改善に活かす方法）と相性がよく、原因分析までつなげられます。

5. 業種別に“連携で詰まりやすい論点”を押さえる

5-1. 物流（3PL/倉庫）

入出庫・在庫・配送実績など、イベントが多くて更新頻度が高い領域です。
現場が止まるのは「入庫実績は来ているのに、参照する商品マスタが未整備」などの順序問題が多いです。
業務イメージを作るなら、物流向けWebシステム活用アイデアのように“現場イベントが連続する”前提から入ると、連携設計の落とし穴を早めに潰せます。

5-2. 卸売・商社

商品コードの表記ゆれ、先方固有コード、分納・直送・掛率など“例外条件”が多い領域です。
「標準化できるところ」と「例外として持つところ」を分けないと、連携はすぐにブラックボックス化します。
見積項目の前提整理は、卸売・商社（BtoB企業）向けWebシステム活用アイデアのような業務像から逆算すると、現実に寄ります。

6. 最後に：連携は“運用UI”があると成功率が上がる

連携の成否は、管理画面の作り込みに強く依存します。最低限、次が見えると運用が回ります。

• 最新取り込み日時／成功・失敗件数
• 失敗一覧（原因別にフィルタ）
• 再処理（単体・一括）と、その結果のログ
• 参照先不足（未登録マスタ）を一覧化して“やること”に落とす

インテンスでも、連携を「裏側のバッチ」だけで終わらせず、運用側が触れる画面を用意することで、復旧が早くなり“開発に依存しない運用”に寄せやすくなります。

まとめ

CSV/EDI/API連携は、差分更新・冪等性・エラー再処理を設計に入れて初めて実務に耐えます。
順序（マスタ→取引→ステータス）を崩さず、失敗時に現場が自力復旧できるUIとログを用意することで、連携はブラックボックスから“運用資産”に変わります。