CSV/EDI/API連携は、「一度取り込めたら完成」ではありません。 実務で問題になりやすいのは、取り込みに失敗したとき、同じデータが再送されたとき、差分だけが後から届いたときです。
CSVで毎日取り込む、EDIで受注データが届く、APIで在庫や配送ステータスが更新される。 こうした連携では、重複登録、欠落、順序の前後、文字コードの違い、参照先マスタ不足などが起きます。 そのたびに開発者しか復旧できない状態だと、現場の業務が止まりやすくなります。
この記事では、差分更新・冪等性・エラー再処理を軸に、CSV/EDI/API連携を実務で運用しやすくする設計ポイントを整理します。
連携が扱いにくくなる原因の一つは、毎回「全件洗い替え」や「単純上書き」で設計してしまうことです。 現場では、同じ取引先の住所だけが変わる、同じ受注の一部だけが分納になる、商品マスタの販売状態だけが更新される、といった部分的な変更が頻繁に起きます。
そのため、連携では差分更新を前提に設計します。 外部キー、更新日時、バージョン番号、内容ハッシュなどを使い、何が新規で、何が更新で、何が処理済みなのかを判断できるようにします。
外部キー、更新日時、ハッシュを使い、新規・更新・処理済みを判定します。
同じデータを再処理しても、数量や金額が二重に反映されないようにします。
失敗理由を見て、対象行や対象バッチだけを再実行できるようにします。
| 設計項目 | 決める内容 | 決めない場合に起きやすい問題 |
|---|---|---|
| 外部キー | 相手先の取引先コード、商品コード、注文番号などを何で照合するか | 同じデータを新規として取り込み、重複登録が増える |
| 更新判定 | 更新日時、バージョン、ハッシュのどれで差分を見るか | 更新済みデータを再度処理したり、必要な更新を見落としたりする |
| 削除扱い | 物理削除ではなく、停止・無効・削除フラグとして扱うか | 過去の取引データと紐付けられなくなり、集計や確認が難しくなる |
製品や取引先などマスタが絡む場合は、管理画面で更新運用を回す方法と同じく、「どちらのシステムを正とするか」を先に決める必要があります。 商品名は基幹側、Web表示名はWeb側、販売停止フラグは基幹側、といったように項目単位で分けることもあります。
CSVは再送されることがあります。 APIはタイムアウト後に再試行されます。 夜間バッチは途中で止まることもあります。
そのため、同じデータが複数回来ても、結果が二重に反映されないようにしておく必要があります。 これが冪等性の考え方です。
CSV、EDI、APIからデータを受け取り、連携IDを付与します。
外部キーと連携種別で、処理済みデータか確認します。
変更がある項目だけを更新し、加算・減算の二重処理を防ぎます。
成功、失敗、保留、再処理対象をログとして残します。
特に注意したいのは、在庫数や請求金額のような「加算・減算」で扱う項目です。 同じデータを2回処理すると、在庫が二重に減ったり、金額が二重に加算されたりする可能性があります。 この場合は、イベントをそのまま足し引きするのではなく、外部側の最新状態を基準に更新する、または処理済みイベントIDを厳密に管理する必要があります。
問い合わせや予約のステータスを連携で更新する場合は、ステータス設計と整合が取れているか確認します。 外部連携によって、意図せず「完了」「キャンセル」「出荷済み」などへ変わらないよう、状態遷移のルールを明確にしておきます。
連携の品質は、成功時よりも失敗時に分かります。 失敗内容がログファイルにしか残らず、開発者がサーバで確認しないと復旧できない状態では、運用側の負担が大きくなります。
現場で確認・修正・再処理できる画面を用意しておくと、参照先マスタ不足や入力形式の不一致など、よくある失敗を日常業務の中で処理しやすくなります。
問い合わせ管理のダッシュボードで保留や確認中を扱う考え方は、運用ルールのまとめと同じように考えられます。 連携エラーも、未確認のまま残ることが一番の問題です。
連携順序が前後すると、処理が止まりやすくなります。 たとえば、受注データは届いているのに商品マスタが未登録、配送実績は届いているのに出荷データが存在しない、という状態です。
基本は、次の順序で処理します。
商品、取引先、拠点、担当者など、参照される情報を先に更新します。
受注、予約、問い合わせ、見積などの本体データを登録します。
出荷、検収、分納、キャンセル、請求などの状態を反映します。
参照先不足で保留にしたデータを、マスタ補完後に再処理します。
現場の都合で順序が前後する場合は、単純にエラーで止めるだけでなく、保留キューを用意します。 参照先マスタが後から届いた時点で、保留データを再処理できるようにしておけば、手入力での補正を減らせます。
商品コード P-8842 が未登録のため、受注3件を保留しています。
外部コード C-2190 と既存取引先の紐付けが必要です。
この保留の設計は、問い合わせ分類やタグの考え方（タグを改善に活かす方法）とも相性があります。 どの原因で保留が多いのかを集計できれば、マスタ整備や入力ルールの改善にもつなげられます。
CSV/EDI/API連携の注意点は、業種によって変わります。 物流、卸売、製造のように、マスタと取引データが多い業種では、例外条件をどこまでデータ構造に含めるかが重要になります。
物流では、入庫、出庫、在庫、検品、配送実績など、短い間隔でイベントが発生します。 更新頻度が高く、順序も前後しやすいため、参照先マスタ不足やステータスの行き違いが起きやすい領域です。
業務イメージを作るなら、物流向けWebシステム活用アイデアのように、現場イベントが連続する前提から入ると、連携設計で確認すべき点を出しやすくなります。
卸売・商社では、商品コードの表記ゆれ、先方固有コード、分納、直送、掛率、得意先別単価など、例外条件が多くなります。 標準化できる項目と、例外として保持する項目を分けないと、連携処理の中身が分かりにくくなります。
見積項目や取引条件の前提は、卸売・商社（BtoB企業）向けWebシステム活用アイデアのような業務像から逆算すると、画面とデータ連携の関係を考えやすくなります。
連携を裏側のバッチだけにしてしまうと、現場では何が起きているか分かりません。 最新取り込み日時、成功件数、失敗件数、保留件数、再処理結果を画面で確認できるようにしておくと、復旧の判断が早くなります。
インテンスでも、連携を裏側の処理だけで終わらせず、運用側が確認・保留・再処理できる画面を用意することを重視しています。 これにより、開発者への確認を待たずに、日常的なデータ不整合を現場で処理しやすくなります。
CSV/EDI/API連携は、データを取り込む処理だけでは不十分です。 差分更新、冪等性、エラー再処理を設計に含めて、はじめて実務で扱いやすい連携になります。
外部キー、更新日時、削除フラグ、更新元を決め、新規・更新・処理済みを判断します。
同じデータを複数回処理しても、数量・金額・ステータスが二重反映されないようにします。
失敗理由を画面で確認し、対象行や対象バッチだけを再実行できるようにします。
処理順序は、マスタ、取引データ、ステータス更新を基本にします。 順序が前後する場合は、保留キューを用意し、参照先がそろった後で再処理できるようにしておくと、手作業での補正を減らせます。
連携は、システムの裏側で自動的に動くだけのものではありません。 現場が状況を確認し、原因を判断し、必要な範囲だけ復旧できる運用UIまで用意することで、CSV/EDI/API連携は日常業務を支える仕組みになります。