ECトラブルの記録・復旧・再発防止｜障害対応台帳の作り方

ネットショップで商品情報が反映されない、注文が取り込まれない、購入完了画面が開かないといった問題が起きると、まず操作をやり直したくなります。しかし、複数人が別々に設定を変えたり、結果が分からない送信を繰り返したりすると、原因の把握と復旧が難しくなることがあります。

ECトラブルの記録では、原因を最初から断定するよりも、確認できた症状、影響、実施した変更、次の担当を残すことが大切です。本記事は、特定企業の事故や対応実績ではなく、EC運営で使う障害対応台帳の設計例です。

最初に影響範囲と担当を決める

「サイトがおかしい」を、誰が、どの画面で、何をすると、何が起きるかに分けます。管理画面だけの問題か、購入者にも影響するか、特定商品だけか、すべての注文かを確認します。影響が未確認の範囲は、そのまま未確認として残します。

同時に、全体の判断をする人、調査・変更をする人、社内外へ連絡する人を決めます。少人数なら兼務して構いませんが、誰も把握しない設定変更を避けるため、現在の担当は一か所で確認できるようにします。Googleのインシデント管理に関する資料でも、役割の整理、状況を更新する記録、明確な引き継ぎが扱われています。

購入・決済・出荷などに影響する場合は、調査の完了を待たず責任者へ共有します。個人情報の漏えいやアカウントの不正利用が疑われる場合は、一般的な表示崩れと同じ扱いにせず、社内の情報管理担当やサービス提供会社へ速やかに相談してください。

台帳は症状・変更・復旧を分ける

長文のチャットを全部転載する必要はありません。現在の状況を上に、時刻順の変更履歴を下にまとめると、途中から参加する人も確認できます。原因欄が空でも、症状と影響が記録されていれば調査を始められます。

エラー画面だけでなく前後の状態を残す

エラーが出た直前に行った操作、最後に正常だった時点、同じ条件で成功する対象を確認します。ブラウザや端末、ログイン権限、対象ページ、更新したファイルなど、原因の切り分けに必要な差分を記録します。関係のない顧客データを大量に取得する必要はありません。

画面の撮影やログの共有では、氏名、住所、注文内容、APIキー、パスワード、セッション情報などを含まない範囲へ絞ります。原本が必要な場合はアクセスを制限した保管先へ置き、一般共有の台帳には参照だけを残します。公開記事や社外資料に、業務画面をそのまま転用しないでください。

サポートへ問い合わせる際は、発生日時、対象機能、期待と実際の差、再現条件、試したことをまとめます。「直りません」という連絡を繰り返すより、どの操作まで確認したかを揃える方が調査を進めやすくなります。

結果が曖昧な操作は再送前に確認する

注文登録や出荷依頼でタイムアウトした場合、画面に完了が出なくても、サービス側では処理済みの可能性があります。同じ操作を繰り返す前に、注文IDや処理履歴を読み取り、作成・更新が行われたか確認します。読み取りもできないときは、担当者や提供会社へ確認し、重複を増やさない判断が必要です。

暫定対応として設定を変える場合も、権限のある人が対象範囲、期待する結果、戻し方を確認して実施します。一度に多数の設定を変更すると、どれが影響したか分からなくなります。セキュリティ機能の全面無効化や、検証していない削除を一般的な解決策にしないでください。

原因調査と顧客への連絡は別の作業です。原因が不明でも、確認できた影響と次の連絡予定は伝えられます。復旧見込みを根拠なく断言せず、分かっていることと確認中のことを分けます。

復旧は購入から出荷まで必要な工程で判定する

トップページが開いても、決済、受注取込、在庫更新、出荷通知のどこかが止まっている場合があります。障害が影響した工程に応じて、入口から後続処理まで確認します。実注文や実決済を使う確認は、テスト方法と取消・返金を含め、責任者の承認を得て行います。

• 元の操作が期待した結果になるか。
• 同じ処理の重複や、止まっていた処理の未完了が残っていないか。
• 在庫、注文状態、追跡、通知などの後続データが整合しているか。
• 一時的に止めた連携や変更した設定を、必要な状態へ戻したか。
• 社内と購入者に必要な案内が行われたか。

記録の状態は、対応中、暫定復旧、復旧確認済み、再発防止対応中など、自社で判断できる範囲に分けます。「一度動いた」と「原因まで解消した」を同じ完了状態にしないことがポイントです。

再発防止は注意喚起だけで終わらせない

振り返りでは、担当者を責めるのではなく、判断に必要な情報、確認項目、権限、監視、引き継ぎに不足がなかったかを調べます。Googleの振り返りに関する資料でも、責任追及ではなく学びと再発防止につなぐ考え方が説明されています。

「次から気を付ける」だけでなく、公開前チェックへ項目を追加する、変更できる人を限定する、停止を検知する方法を用意するなど、実施できたか確認できる対策にします。対策ごとに担当、期限、確認方法を残し、障害が収まった後も完了まで追います。

少人数なら、まず一つの対応台帳と連絡先一覧から始めます。制作会社、倉庫、システム会社が分かれている場合は、それぞれの受付窓口・対応範囲・連絡条件も整理します。毎月、同じ症状が繰り返されていないか、長期間保留の対策がないかを確認してください。

まとめ

個別のエラーの切り分け例は、WooCommerceで501エラーが出たときの確認手順も参照できます。本記事の台帳は、特定のエラー番号に限らず、調査の経緯と復旧確認を共通の形で残すために使います。

ECの障害対応台帳は、エラーを集めるだけのものではありません。症状、影響、担当、変更、復旧確認、再発防止をつなぎ、次の人が安全に判断できる状態を残します。原因が分からない段階でも事実を記録し、復旧と恒久対策を分けて管理することから始めましょう。