外部連携は、つながった時点ではうまく見えても、運用が始まると例外や変更が必ず出てきます。CSVは手軽でも運用ルールが曖昧だとミスが増えやすく、APIは自動化しやすい反面、失敗時の扱いを決めていないと原因調査が難しくなります。EDIのように形式が固い連携でも、実際にはコード体系のずれや例外値の処理で止まりやすい場面があります。
壊れにくい連携にするには、項目の対応表だけでなく、失敗時の隔離、再送、二重処理対策までを最初から同じ設計の中に入れておく必要があります。本記事では、CSV、EDI、APIのどれにも共通して重要になる考え方を整理します。
どの方式でも共通して必要なのは、「値の意味をそろえること」「失敗したデータを見つけられること」「やり直せること」です。
下は、外部連携の管理画面を想定した例です。左側で項目対応表を確認し、右側で受信、保留、再送の流れを追えるようにしています。マッピングと運用状況を分けずに見られると、止まった理由を確認しやすくなります。
| 送信側 | 受信側 | 変換 |
|---|---|---|
| order_date | 受注日 | YYYY-MM-DD → Y/m/d |
| customer_code | 取引先コード | 前後空白削除 |
| status | 受注状態 | 01/02/03 → 仮受付/確定/取消 |
| memo | 備考 | 改行整形、文字数制限あり |
連携事故の多くは、値の意味が違う、例外値が処理できない、コードがずれる、といった理由から起こります。対応表は項目名の対応だけで終わらせず、値の意味まで定義しておく方が安全です。
| 確認項目 | 見落としやすい点 | 先に決めたいこと |
|---|---|---|
| 必須条件 | 相手側では任意でも、自社側では必須になることがあります。 | 欠けていた時にエラーにするか、保留にするかを決めます。 |
| 日付・時刻 | タイムゾーンや時刻の有無でずれやすくなります。 | 保存形式と表示形式を分けて整理します。 |
| コード値 | 同じように見えて意味が違う場合があります。 | 対応表を項目ごとに持つ方が安全です。 |
| 空値・例外値 | 空欄、0、未定の意味が違うと後で判定がぶれます。 | 値ごとに扱いを固定しておきます。 |
連携は必ず失敗する前提で設計した方が安定します。正常系だけで考えると、例外が発生した時に担当者が直接データを書き換えたり、同じ連携を何度も回したりして、別の事故につながりやすくなります。
特に、保留キューを持たずに失敗データをそのまま取り込み直す運用は、原因追跡が難しくなりやすいため注意が必要です。
Webhookは便利ですが、同じ通知が複数回届く前提で作らないと二重処理が起きやすくなります。再送と冪等性、つまり同じ処理を繰り返しても結果が変わらない仕組みをセットで考える必要があります。
受信後に一度キューへ入れ、検証と本処理を分ける方が詰まりにくくなります。
イベントIDや外部IDで処理済み判定を持つと、重複事故を抑えやすくなります。
連携テストは、正常に流れることの確認だけでは足りません。実際の運用では、空欄、桁超え、未知コード、取消データ、再送などの方が問題になりやすくなります。
| テスト項目 | 見たいこと | 理由 |
|---|---|---|
| 空値・未定値 | エラーか保留か | 人の判断が必要なデータを分けられるか確認しやすくなります。 |
| 未知コード | 落ち方と通知方法 | 相手側の仕様変更に早く気づきやすくなります。 |
| 重複イベント | 二重登録されないか | Webhook連携では特に重要です。 |
| 再送・取消 | やり直しが可能か | 運用で止まらない仕組みに近づけやすくなります。 |
外部連携では、自動化を進めるほど便利に見えますが、条件が複雑な領域では人の判断を残した方が安定することがあります。例えば次のような場面です。
この場合は、正常系だけ自動化し、例外は保留キューに入れて確認する方が、全体として扱いやすくなります。
外部連携は、つながることより、止まった時に見つけられること、やり直せることの方が重要です。マッピング表、例外の隔離、再送、二重処理対策までを最初から入れておくと、運用時の負荷をかなり抑えやすくなります。
まず見直しやすいのは、項目対応表に型や例外値まで書かれているか、再送の手段があるか、重複処理を防ぐキーがあるかの3点です。そこから整えていくと、CSV、EDI、APIのどの連携でも崩れにくい形に近づけやすくなります。