外部サービス連携で、失敗・遅延・重複をどう扱うか

同じ会員、求人、商品、問い合わせ情報を複数のシステムで編集できると、どちらの値を採用するか判断できません。項目ごとに、登録元、正となる場所、更新方向、反映タイミングを決めます。

一方向同期でも、Web側で追加する公開状態や表示用の情報がある場合は、外部データと自社データを分けます。外部側の更新で自社側の補足まで消えないよう、所有する項目を明確にします。

同じ利用者や商品を判断する外部IDに加え、同じ連携処理が再送されたかを判断する識別子を持たせます。通信が途中で切れると、送信側は失敗と判断して同じ内容を再送する場合があります。

同じ処理を複数回受け取っても結果が一つになるよう、既に処理済みかを確認します。古いデータが後から到着して新しい値を戻さないよう、更新時刻や版も判断材料にします。

差分同期は処理量を減らせますが、一度取りこぼしたデータがそのまま残る可能性があります。全件同期は整合性を戻しやすい一方、件数が多いと時間と負荷が増えます。

日常は差分同期を行い、定期的または必要時に全件照合できる構成を検討します。処理件数、追加、更新、変更なし、除外、失敗を分けて記録します。

接続できない、時間切れ、認証エラーなどは通信上の失敗です。接続できても、必須項目不足、存在しない選択肢、文字数超過、関連先が見つからない場合はデータ上の失敗です。

通信エラーは時間を置いた再試行で直る場合がありますが、不正なデータを同じまま何度再送しても直りません。エラーの種類ごとに、自動再試行、運用担当者の確認、接続先への問い合わせを分けます。

百件のうち一件だけ失敗したとき、全件を止めるのか、正常な九十九件を進めるのかは業務によって異なります。重要なのは、成功した範囲と失敗した範囲を追えることです。

正常行だけ進める場合は、失敗データの識別子、理由、受信値、再処理状態を残します。複数システムをまたぐ処理では、単純なデータベースの巻き戻しだけでは元に戻らないことがあります。

外部連携が完了するまで時間がかかる場合、画面上で「完了」と表示すると誤解を招きます。受付済み、処理中、連携済み、確認が必要、再処理中など、利用者に必要な状態を整理します。

利用者には次の行動が分かる案内を出し、運用担当者には調査に必要な処理番号と状態を残します。連携先が停止しても、受付データを失わず後から送れる構成を検討します。

エラーをログへ残すだけでは、誰も気づかないことがあります。一定件数の失敗、連続した通信エラー、最終成功時刻の遅れ、認証期限など、通知する条件を決めます。

通知には、発生時刻、対象処理、件数、影響、再試行状況、確認先を含めます。一件ごとに大量通知すると重要な障害が埋もれるため、集約や優先度も検討します。

外部サービスのAPI仕様、認証方法、権限、利用上限は将来も同じとは限りません。アクセストークンやAPIキーを公開部分へ置かず、更新期限と保管場所、変更担当を決めます。

仕様変更の案内を誰が確認し、検証環境で何を試し、本番へいつ反映するかも連携の運用です。接続できなくなってから調べ始めるのではなく、バージョン、利用量、認証期限を定期確認へ含めます。

自動処理が失敗したとき、運用担当者が対象期間や対象データを限定して再実行できると復旧が早くなります。ただし、無条件の全件同期ボタンは負荷や重複の原因になります。

実行権限、対象範囲、事前確認、二重実行防止、処理中表示、結果履歴を用意します。再実行前に元データを修正する必要がある場合は、どちらのシステムで修正するかを案内します。

エラーが出ていなくても、一部の更新だけ欠けることがあります。最終成功時刻、処理件数、外部側と自社側の総数、更新時刻、代表データを定期的に照合します。

差異が見つかったときに、元データ、連携ログ、保存値、公開画面を順に追えるようにします。監視は接続の生存確認だけでなく、情報が正しく流れているかを確認するものです。