「再実行したら処理が通ったので、障害対応は完了です」。
その後、同じ操作で二重登録が見つかると、もう一度利用部門に説明し、データを確認することになります。
バグ対応では、業務を安全に再開できたかと再発の条件を減らせたかを別々に追うと、復旧後の作業が埋もれにくくなります。
はんちゃん（SE）チャー、再実行したら正常終了になったんだけど、二重登録されていないか心配で。チケットはもう閉じていいのかな？
チャーはんちゃん、まず受信側の記録と照らし合わせて、欠落や重複がないか確かめるニャ。復旧できたらその結果を残して、原因調査と修正は担当と期限を決めて追おう。
暫定対応・恒久対応・再発防止をどう分ける？
現場で呼び方は異なります。
この記事では、復旧や被害拡大防止のために当面行う処置を「暫定対応」、確認した原因に手を入れる修正を「恒久対応」、同種の事故を減らすためにテストや運用も見直す活動を「再発防止」と呼びます。
恒久対応は再発防止策の一部です。
| 対応 | 達成したいこと | 架空例 |
|---|---|---|
| 暫定対応 | 影響拡大を止め、安全な範囲で業務を再開する | 自動再試行を停止し、処理済みと未処理を照合する |
| 恒久対応 | 確認した原因が同じ条件で障害につながらないようにする | 同じ受付番号の再送で重複登録されない仕組みに修正する |
| 再発防止 | 同種の欠陥を作り込む、または見逃す可能性を減らす | 応答タイムアウト時のテスト追加と、他の連携処理の点検を行う |
ベターな対処｜復旧を急ぐときも、再実行の前に処理済みか確認する
架空の注文連携で、送信元に「タイムアウト」と表示されたとします。
応答が届かなくても、受信側では登録が完了している場合があります。
発生時刻、対象の受付番号、エラー、直近の変更を記録し、受信側の処理履歴や結果を照合します。
受信側の状態が分からない間は再実行を保留し、承認された手順と連絡経路に従います。
照合で未処理と確認でき、再送の安全性を確認できた範囲だけを、承認のもとで処理します。
復旧後は、正常終了の表示に加えて、対象データの件数、欠落と重複の有無、後工程で使えることを確認します。
利用部門への報告には、業務再開の可否、残る制約、次の連絡予定を含めます。
現場の想定例｜送信100件・受信100件でも内訳が合わない
架空の注文連携で、送信予定は100件、受信側の登録も100件だったとします。ただし、受付番号を照合すると、1件が二重に登録され、別の1件は未登録でした。
この場面では、合計件数に加えて、受付番号ごとに未登録・1件登録・重複登録を分けると、調査対象がはっきりします。後工程に渡ったデータがあるなら、その影響も確認します。
未登録分の再送と、重複分の訂正は別作業として扱います。受信側の担当と対象を突き合わせ、業務側の承認を得たうえで処理し、照合結果を復旧記録に残します。
目指したい対応｜原因・修正・確認結果を対応づける
時系列を作り、原因の仮説を検証する
「受信側で登録」「送信側で応答待ちが終了」「同じ番号を再送」「受信側で再登録」のように、記録を見ながら時系列を整理します。
検証環境で、登録は完了した状態で応答が返らない状況を再現し、再送したときに二重登録になるか確認します。
再現できない場合は、観測した事実と仮説を分け、追加で必要なログや監視を決めます。
発生を防ぐ修正と、発見を早める策を分ける
同じ受付番号の再送が原因と確認できた例では、受信側でその番号が処理済みなら二重に登録されないようにします。
実装では受付番号の一意性の範囲、処理結果を返す方法、同時に同じ番号を受け取る場合も検討します。
重複を検知する監視は発見を早める策なので、修正後も別の目的で役立ちます。
修正後は、初回は1件登録される、応答が失われたあとに再送しても1件のまま、異なる番号は別々に登録される、といった条件を試します。
リリース後は対象の運用サイクルに合わせて結果を確認します。
月次処理なら、次回の月次処理で件数を照合するところまで担当と期限を決めます。
コピーして使える記録欄
影響範囲／復旧の確認結果／未確定事項／恒久対応の担当と期限／修正前後のテスト結果／暫定措置の解除条件／運用後の確認日
記入例（架空）
影響・復旧結果｜受付番号を照合し、重複1件と未登録1件を特定。承認後に訂正・再送し、各番号が1件ずつあることを確認。
恒久対応｜連携の保守担当が次回リリースまでに、同じ受付番号で再送しても二重登録されないよう修正する。
テスト・解除条件｜応答なしの後に再送しても1件のままと確認し、承認後に自動再試行を再開。次回の定期処理で再照合する。
注意点｜復旧済みと対策完了を記録上で分ける
復旧を記録したら、恒久対応を元の障害記録にひも付けます。
対策の担当・期限・暫定措置の解除条件・テスト結果を残します。
原因が未確定なら調査を続ける条件を、対策を延期するなら残るリスクと見直し日を明記します。
セキュリティ事故の疑いがある場合は、組織の対応手順に従って連絡し、必要な記録の保全を優先します。
まとめ｜次に起きたときも同じ復旧作業をするか考える
復旧後に「同じ条件でもう一度起きるか」を確認し、起こり得るなら残作業に名前と期限を付けます。
障害記録には、まず「復旧の確認結果」と「再発防止の確認結果」を分けて書ける欄を作ってみてください。
チャーこちらも読んでみてニャ。🐈
参考資料
IPAの教訓集では、障害事例から原因・対策・効果などを整理しています。別冊Ⅱには時系列で事象を整理し、原因と対策を検討する事例があります。この記事の注文連携は架空の例です。
IPA「情報処理システム高信頼化教訓集 ITサービス編」（2019年2月28日発行）
同 別冊Ⅱ「障害分析手法」（いずれも2026年11月8日確認）