開発中に一件のデータを送受信できれば、接続自体は確認できます。しかし本番運用では、接続先の停止、通信の遅延、認証期限、想定外の値、大量データ、同じ通知の再送などが起こります。
外部サービスは自社サイトと同じタイミングで動き、同じ方法で復旧できるとは限りません。
私たちが外部連携を確認するとき、一件の送受信に成功しても「完成」とは考えません。むしろ確認したいのは、その先です。失敗をどう検知し、利用者への影響をどう抑え、後から正しい状態へどう戻すかまでを完成条件にします。
最初に、どこを正とするかを決める
同じ会員、求人、商品、問い合わせ情報を複数のシステムで編集できると、どちらの値を採用するか判断できません。項目ごとに、登録元、正となる場所、更新方向、反映タイミングを決めます。
一方向同期でも、Web側で追加する公開状態や表示用の情報がある場合は、外部データと自社データを分けます。外部側の更新で自社側の補足まで消えないよう、所有する項目を明確にします。
一件を識別するキーと、処理を識別する番号を分ける
同じ利用者や商品を判断する外部IDに加え、同じ連携処理が再送されたかを判断する識別子を持たせます。通信が途中で切れると、送信側は失敗と判断して同じ内容を再送する場合があります。
同じ処理を複数回受け取っても結果が一つになるよう、既に処理済みかを確認します。古いデータが後から到着して新しい値を戻さないよう、更新時刻や版も判断材料にします。
全件同期と差分同期の役割を分ける
差分同期は処理量を減らせますが、一度取りこぼしたデータがそのまま残る可能性があります。全件同期は整合性を戻しやすい一方、件数が多いと時間と負荷が増えます。
日常は差分同期を行い、定期的または必要時に全件照合できる構成を検討します。処理件数、追加、更新、変更なし、除外、失敗を分けて記録します。
通信の失敗と、データの失敗を分ける
接続できない、時間切れ、認証エラーなどは通信上の失敗です。接続できても、必須項目不足、存在しない選択肢、文字数超過、関連先が見つからない場合はデータ上の失敗です。
通信エラーは時間を置いた再試行で直る場合がありますが、不正なデータを同じまま何度再送しても直りません。エラーの種類ごとに、自動再試行、運用担当者の確認、接続先への問い合わせを分けます。
部分失敗の状態を残す
百件のうち一件だけ失敗したとき、全件を止めるのか、正常な九十九件を進めるのかは業務によって異なります。重要なのは、成功した範囲と失敗した範囲を追えることです。
正常行だけ進める場合は、失敗データの識別子、理由、受信値、再処理状態を残します。複数システムをまたぐ処理では、単純なデータベースの巻き戻しだけでは元に戻らないことがあります。
利用者への表示と、内部の処理状態を分ける
外部連携が完了するまで時間がかかる場合、画面上で「完了」と表示すると誤解を招きます。受付済み、処理中、連携済み、確認が必要、再処理中など、利用者に必要な状態を整理します。
利用者には次の行動が分かる案内を出し、運用担当者には調査に必要な処理番号と状態を残します。連携先が停止しても、受付データを失わず後から送れる構成を検討します。
失敗を担当者へ知らせる
エラーをログへ残すだけでは、誰も気づかないことがあります。一定件数の失敗、連続した通信エラー、最終成功時刻の遅れ、認証期限など、通知する条件を決めます。
通知には、発生時刻、対象処理、件数、影響、再試行状況、確認先を含めます。一件ごとに大量通知すると重要な障害が埋もれるため、集約や優先度も検討します。
接続仕様と認証の変化も運用へ含める
外部サービスのAPI仕様、認証方法、権限、利用上限は将来も同じとは限りません。アクセストークンやAPIキーを公開部分へ置かず、更新期限と保管場所、変更担当を決めます。
仕様変更の案内を誰が確認し、検証環境で何を試し、本番へいつ反映するかも連携の運用です。接続できなくなってから調べ始めるのではなく、バージョン、利用量、認証期限を定期確認へ含めます。
手動同期と再実行を安全に用意する
自動処理が失敗したとき、運用担当者が対象期間や対象データを限定して再実行できると復旧が早くなります。ただし、無条件の全件同期ボタンは負荷や重複の原因になります。
実行権限、対象範囲、事前確認、二重実行防止、処理中表示、結果履歴を用意します。再実行前に元データを修正する必要がある場合は、どちらのシステムで修正するかを案内します。
定期的に、両側の件数と代表データを照合する
エラーが出ていなくても、一部の更新だけ欠けることがあります。最終成功時刻、処理件数、外部側と自社側の総数、更新時刻、代表データを定期的に照合します。
差異が見つかったときに、元データ、連携ログ、保存値、公開画面を順に追えるようにします。監視は接続の生存確認だけでなく、情報が正しく流れているかを確認するものです。
この方法が向いているケース
- 会員や顧客情報を外部システムから同期する
- フォームや応募情報をCRMへ送る
- 商品、求人、物件などを定期取得する
- 決済や通知など外部処理の結果を受け取る
- 複数のCMSや業務システムで公開状態を揃える
連携を減らした方がよいケース
更新頻度が低く、件数も少なく、担当者が安全に確認できる場合は、手動取込や管理画面更新の方が保守しやすいことがあります。
外部サービスに必要なAPIや契約がない場合も、画面操作の自動化で無理につながず、CSVや確認工程を含む別の受け渡しを検討します。
運用チェック
- 項目ごとの正となるシステムと更新方向を決めたか
- データと連携処理の識別子を分けたか
- 重複受信や古いデータの再送を防げるか
- 全件同期と差分同期の役割を決めたか
- 通信エラーとデータエラーを分けたか
- 部分失敗と再処理状態を追えるか
- 最終成功時刻や連続失敗を通知できるか
- 対象を限定して安全に再実行できるか
- 両側の件数と代表データを定期照合しているか
