API連携の障害対策：リトライ設計とデータ不整合への備え方

API連携は、いつか必ず失敗します。連携先のサービスが一時的に止まる、通信がタイムアウトする、呼び出し回数の上限に達する、連携先が予告どおり仕様を変える。どれも珍しいことではなく、問題は「失敗するかどうか」ではなく「失敗したときに、データの不整合を残さずに回復できるかどうか」です。

障害対策の基本は四つあります。一時的な失敗は間隔を空けて自動で再試行すること（リトライ）、同じ処理が二度実行されても結果が変わらないように作ること（冪等性）、再試行しても回復しないものは記録して担当者に知らせること（通知と退避）、そして定期的に両方のシステムを突き合わせて食い違いを見つけて直すこと（再同期）です。この四つを組み合わせることで、障害が起きてもデータを守れる連携になります。

この記事は、システム連携の開発を発注する事業責任者や、すでに稼働している連携のトラブルに悩んでいる担当者に向けて書いています。連携で起きる障害の種類、リトライ設計の考え方、不整合を防ぐ仕組み、再同期と通知の設計、仕様変更への備え、障害時の運用手順までを順に整理します。

API連携で起きる障害の種類と影響

まず、連携でどんな障害が起きるのかを整理しておきます。障害の性質によって、適切な対処が違うからです。

この中で特に厄介なのが、最後の「処理結果が不明」のケースです。登録の依頼を送ったものの、応答を受け取る前に通信が切れた場合、連携先では登録が成功しているかもしれないし、していないかもしれません。何も考えずに再試行すると二重登録になり、再試行しなければ登録漏れになります。この問題への備えが、障害対策の設計の中心になります。

障害の影響は、連携している業務によって変わります。受注や在庫の連携が止まれば出荷や販売が止まり、請求の連携で二重登録が起きれば顧客への二重請求につながります。どの連携でどんな影響が出るかを把握して、対策の手厚さを決めます。

リトライ（再試行）設計の基本

一時的な障害の多くは、少し時間を置いて再試行すれば回復します。ただし、再試行の仕方を誤ると、かえって状況を悪くします。リトライの設計で決めることは次のとおりです。

何を再試行するか

再試行すべきなのは、一時的な障害と利用制限の超過です。データの不備や認証の失敗は、何度再試行しても回復しないため、すぐに退避や通知に回します。連携先が返す応答の種類（エラーの番号や内容）によって、再試行するかどうかを判定する仕組みを作ります。

間隔をどう空けるか

失敗した直後に何度も再試行すると、停止から回復しようとしている連携先にさらに負荷をかけることになります。再試行の間隔を、一回目は短く、二回目はその倍、三回目はさらに倍、というように徐々に延ばす方法が一般的です。複数の処理が同時に再試行して負荷が集中しないよう、間隔に少しばらつきを持たせる工夫もあります。利用制限の超過の場合は、連携先が「何秒後に再試行してよいか」を知らせてくることがあり、その指示に従います。

何回で諦めるか

再試行の回数と、諦めるまでの時間の上限を決めます。上限を超えたものは、後で説明する退避の仕組みに回して、担当者が確認できるようにします。上限を決めずに再試行を続けると、失敗したデータが溜まり続け、後続の処理まで遅れます。

冪等性：同じ処理が二度実行されても壊れない作り

再試行を安全に行うために欠かせないのが、冪等性（べきとうせい）という考え方です。冪等とは、同じ処理を何度実行しても、一度実行したときと結果が変わらない性質のことです。

たとえば「注文番号Aの注文を登録する」という処理を、結果が不明だったために二回実行したとします。冪等でない作りなら、注文が二件登録されてしまいます。冪等な作りなら、二回目は「注文番号Aはすでに登録済み」と判断して何もしないか、同じ内容で上書きするだけで、注文は一件のままです。

冪等にするための代表的な方法は次のとおりです。

• 一意の識別子で重複を判定する：登録するデータに、連携元の番号など一意の識別子を持たせ、同じ識別子のデータがすでにあれば新しく作らない。
• 連携先の重複防止の仕組みを使う：APIによっては、依頼ごとに一意の値を添えて送ると、同じ値の依頼を二度処理しない仕組みを提供している。決済のAPIなどでよく見られる。
• 「追加」ではなく「この状態にする」という指示にする：「在庫を一つ減らす」ではなく「在庫を十個にする」のように、結果の状態を指定する形にすると、何度実行しても結果が同じになる。ただし、同時に別の更新がある場合の扱いには注意が必要。
• 処理済みの記録を残す：受け取った通知や処理した依頼の識別子を記録し、同じものが再び来たら処理を飛ばす。Webhookの通知は、同じ内容が複数回届くことがあるため、この記録が特に重要です。

冪等性を確かめるテストも用意します。開発の段階で、同じ依頼を意図的に二度送る、Webhookの同じ通知を二度流す、といった確認を行い、データが一件のままであることを確かめます。こうしたテストは、正常な場合の確認だけでは見つからない問題を早い段階で明らかにしてくれます。

冪等性は、後から付け足すのが難しい性質です。連携の設計の最初の段階で、すべての登録・更新の処理について「二度実行されたらどうなるか」を確認しておきます。

データ不整合を防ぐ仕組み：退避・順序・正本

失敗したデータの退避

再試行の上限を超えたデータや、データの不備で処理できなかったデータは、捨てずに専用の置き場所に退避します。退避したデータには、元の内容、失敗の理由、発生日時、再試行の回数を記録しておきます。担当者は、この置き場所を見て原因を確認し、データを直して再処理します。退避の仕組みがないと、失敗したデータは記録の中に埋もれ、気づいたときには原因の調査が難しくなっています。

処理の順序

同じデータに対する更新が、順序を入れ替えて届くことがあります。たとえば「注文の作成」より先に「注文のキャンセル」が届くと、存在しない注文をキャンセルしようとして失敗し、後から届いた作成で注文が残ってしまいます。順序が重要な処理では、データごとに更新日時や版の番号を持たせ、古い更新で新しい状態を上書きしないようにします。順序どおりでないものは、少し待ってから処理し直す設計も有効です。

正本の明確化

双方向の同期では、両方で同時に更新された場合にどちらを優先するかが問題になります。項目ごとに正本を決めておけば、食い違いが起きたときにどちらを正しいとするかが明確になり、補正の判断が速くなります。連携の基本的な設計の進め方はAPI連携とは何かで解説しています。

再同期（照合と補正）の設計

リトライと冪等性で多くの障害は防げますが、それでも通知の取りこぼし、手作業での修正、想定外の不具合などで、両方のシステムのデータが少しずつずれることがあります。そこで、定期的に両方のデータを突き合わせて、食い違いを見つけて直す仕組み（再同期）を用意します。

再同期の設計で決めることは次のとおりです。

1. 照合の対象と頻度を決める：すべてのデータを毎回照合するのは負荷が大きいため、直近に更新されたデータを毎日、全件を週に一度、のように分けます。
2. 照合の基準を決める：件数、合計金額、各データの更新日時など、何が一致していれば正しいとするかを決めます。
3. 食い違いの扱いを決める：正本の内容で自動的に補正するか、担当者に確認を求めるかを、データの種類ごとに決めます。金額に関わるデータは、自動補正せずに確認を求めるほうが安全です。
4. 結果を記録する：照合の結果、見つかった食い違いの件数と内容、補正したかどうかを記録します。食い違いが急に増えた場合は、何らかの不具合の兆候として調べます。

再同期は、一定時刻に動く定期処理として作ることが多く、それ自体の失敗にも備える必要があります。定期処理の失敗の検知と安全な再実行については夜間バッチ・定期処理の設計で解説しています。

障害の検知と仕様変更への備え

障害を検知して知らせる仕組み

どれだけ自動で回復する仕組みを作っても、人が気づくべき障害は残ります。障害を早く知るための仕組みを用意します。

通知の条件を決める：一時的な失敗のたびに通知すると、通知が多すぎて重要なものが埋もれます。「再試行の上限を超えた」「一定時間、連携が一件も成功していない」「認証に失敗した」「退避したデータが一定数を超えた」など、人の対応が必要な場合に絞って通知します。

沈黙を検知する：失敗の通知だけでは、連携の処理そのものが動いていない場合に気づけません。「最後に成功した時刻から一定時間が過ぎた」ことを検知する仕組みを入れると、処理が止まっている状態を見つけられます。監視の考え方を連携にも当てはめることが大切です。

状況を確認できる画面を用意する：連携ごとの成功・失敗の件数、退避したデータの一覧、最後に成功した時刻を、担当者が一目で確認できる画面があると、通知を受けたときの初動が速くなります。

通知の受け手を決める：通知が届いても誰も見ていなければ意味がありません。連携ごとに一次対応の担当者と、その不在時の代わりを決めておきます。

連携先の仕様変更への備え

連携先のAPIは、自社の都合とは関係なく変わります。仕様変更で連携が突然止まる事態を防ぐために、次の備えをしておきます。

• 告知の確認を担当者の役割にする：連携先の開発者向けのお知らせや更新履歴を定期的に確認し、影響を判断する担当を決めます。
• 使っている版を記録する：連携ごとに、どの版のAPIを使っているかを記録し、提供終了の予定を把握します。
• 想定外の応答を検知する：返ってきたデータに想定した項目がない、形式が違う、といった場合に、処理を止めて通知する作りにします。黙って空の値で登録してしまうと、不整合が静かに広がります。
• 保守の契約で扱いを決める：仕様変更への追従を誰がいつまでに行うか、費用をどう扱うかを、保守の契約で決めておきます。

障害対策のチェックリスト

• 連携ごとに、止まった場合の業務への影響を書き出したか
• 再試行する障害と、再試行しない障害を区別しているか
• 再試行の間隔を徐々に延ばし、回数と時間の上限を決めたか
• すべての登録・更新の処理が、二度実行されても壊れない作りになっているか
• Webhookの通知の重複と順序の入れ替わりに備えているか
• 処理できなかったデータを退避し、担当者が確認・再処理できるか
• 定期的に両方のデータを照合し、食い違いを見つける仕組みがあるか
• 人の対応が必要な障害に絞って通知し、受け手を決めているか
• 連携の処理が止まっている状態（沈黙）を検知できるか
• 連携先の仕様変更の告知を確認する担当を決めたか
• 障害時の対応手順が文書になっているか

障害対策でよくある失敗とその避け方

再試行で二重登録が起きる：冪等性を考えずに再試行を入れた結果、タイムアウトのたびに同じデータが二件登録されるケースです。再試行を入れる前に、二度実行されたときの結果を必ず確認します。

通知が多すぎて無視される：一時的な失敗まですべて通知した結果、担当者が通知を見なくなり、本当に重要な障害を見逃すケースです。通知は人の対応が必要なものに絞り、それ以外は記録だけにします。

失敗したデータが消える：再試行の上限を超えたデータを記録せずに捨ててしまい、後から何が失敗したのか分からなくなるケースです。退避の置き場所を必ず用意します。

照合をしていない：日々の連携は動いているように見えても、少しずつずれが蓄積し、月末の締めで大きな食い違いが見つかるケースです。定期的な照合で、ずれを小さいうちに見つけます。

架空の例：請求データの二重登録

たとえば、販売管理から会計ソフトへ請求データを送る連携（架空の例）で、会計ソフト側の応答が遅れてタイムアウトし、再試行したところ同じ請求が二件登録されたとします。対策としては、請求番号を一意の識別子として会計ソフト側の項目に持たせ、登録の前に同じ番号のデータがないかを確認する作りにします。あわせて、毎日の照合で販売管理と会計ソフトの請求の件数と合計金額を突き合わせれば、万一の重複も翌日には見つけられます。

障害が起きたときの運用手順

障害対策は仕組みだけでは完結しません。障害が起きたときに、誰が何をするかを手順にしておくことで、対応の速さと確実さが変わります。手順には次の内容を含めます。

1. 通知を受けた担当者が、状況確認の画面で影響の範囲（どの連携が、いつから、何件）を確認する
2. 連携先の障害情報を確認し、原因が連携先か自社側かを切り分ける
3. 業務への影響が大きい場合は、関係部署に連絡し、必要なら手作業での代替手順に切り替える
4. 原因が解消したら、退避したデータを再処理し、照合で食い違いがないことを確認する
5. 原因と対応を記録し、再発防止の対策を検討する

こうした手順はRunbook（運用手順書）として文書にしておき、担当者が替わっても同じ対応ができるようにします。

手順は作っただけでは使えるようになりません。年に一度程度、連携先が止まったと想定して手順どおりに動けるかを確かめる机上の訓練を行うと、手順の抜けや、確認画面の使いにくさが見つかります。また、実際に障害が起きた後には、原因・影響・対応・再発防止策を短くまとめて関係者で共有します。責任を追及するためではなく、同じ障害を繰り返さないための振り返りとして行うことで、連携の仕組みも運用の手順も少しずつ強くなっていきます。障害の記録が蓄積すると、どの連携先が不安定か、どの時間帯に失敗が多いかといった傾向も見えてきて、次の改善の優先順位をつける材料になります。

よくある質問

Q. リトライを入れれば障害対策は十分ですか？

リトライは一時的な障害には有効ですが、それだけでは不十分です。二重登録を防ぐ冪等性、回復しないデータの退避、定期的な照合、障害の通知を組み合わせて、初めて不整合を残さない連携になります。

Q. 既存の連携に後から障害対策を追加できますか？

追加は可能です。まずは連携ごとの成功・失敗の記録と、止まっている状態の検知から始めると、効果が大きく工数も比較的小さく済みます。冪等性の確保は、既存の処理の作りによっては改修の範囲が広がるため、影響の大きい連携から優先して見直します。

Q. 照合はどのくらいの頻度で行うべきですか？

業務への影響と、データの量で決めます。在庫や請求のように食い違いの影響が大きいデータは毎日、影響の小さいデータは週に一度など、データの種類ごとに頻度を変えるのが現実的です。

Q. 連携先が止まっている間、業務はどうすればよいですか？

連携が止まっても業務を続けられるよう、手作業での代替手順を決めておきます。連携先の回復後に、退避したデータの再処理と照合で整合性を取り戻せる設計にしておけば、止まっている間の業務を無理に止める必要はありません。

Otsumuに相談できること

連携の件数が少なく、止まっても翌日に手で補える程度の業務であれば、失敗の記録と通知を整えるだけで十分なことが多く、大がかりな対策は必要ありません。ノーコードの連携ツールを使っている場合は、ツールが備える再試行や通知の機能を正しく設定するだけでも、障害への備えは大きく改善します。

一方で、受注・在庫・請求のように不整合が許されない連携がある、連携の失敗に気づくのが遅れて手作業の補正が常態化している、既存の連携の作りが分からず手を入れられない、といった状況では、連携全体を見直して設計できる相手と進めたほうが、確実に状況を改善できます。

Otsumuは自らも事業を手がける立場から、業務への影響に照らして対策の優先順位を決め、AIを活用した少人数・短期間の開発で、設計から運用・改善までを一気通貫で支援しています。システム同士の連携の開発と見直しはAPI連携開発で、稼働中のシステムの保守についてはシステム保守・運用で進め方を紹介しています。

既存の連携の弱点の洗い出しや、対策の優先順位の整理だけでもご相談いただけます。まずは30分の無料相談で、現在の連携とお困りの状況をお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01