ECサイトの遅延・障害で「復旧待ち」だけにしない｜販売停止・告知・影響注文照合を決めるインシデント台帳

障害対応を「復旧作業」だけにしない

ECサイトの障害対応では、技術的な原因調査やベンダーからの復旧連絡を待つだけでは、販売・顧客対応・受注処理の判断が遅れます。とくに確認すべきなのは、次の4点です。

1. いま新規の注文を受けてよいか
2. 進行中の広告・メール・SNS誘導を止めるべきか
3. 購入者と購入検討者へ何を、いつ伝えるか
4. 復旧後に、注文・決済・在庫・出荷の不整合をどう見つけるか

消費者調査の報道では、ネットショッピング中のトラブルで窓口に問い合わせない回答者が63.4%とされています。問い合わせ件数が少ないことを、影響が小さい根拠にはできません。また、この数値は障害の発生頻度や個別店舗での離脱率を示すものではありません。障害中に何が起きたかは、注文一覧や決済記録などの業務データで確認する必要があります。

そこで有効なのが、障害の発見からクローズまでを1件のインシデント台帳として残す方法です。台帳は障害報告書ではなく、その場の判断と未完了タスクを共有するための運用表です。原因が確定していない初動でも記入を始めます。

まず障害箇所を5つに分けて記録する

「サイトが落ちた」という記録だけでは、販売停止の範囲も、復旧後に照合すべきデータも決まりません。最初に、影響を次の5区分で判定します。同時に複数区分が影響を受けることもあります。

Shopifyを利用している場合、Shopify Statusでは、Admin、Checkout、Storefront、API & Mobile、Third party servicesなど、コンポーネント別に状態と過去のインシデントを確認できます。確認日：2026年9月16日。表示障害があっても、管理画面やチェックアウトまで停止しているとは限らないため、コンポーネント単位で台帳へ記録します。

ecforceの公式サポートサイトには、管理画面遅延、購入ページへのアクセス不具合、API障害、決済エラーなどのお知らせがあります。BASEにも障害・メンテナンス情報の掲載区分があります（いずれも確認日：2026年9月16日）。利用中のカート、決済代行会社、外部アプリ・OMS・WMSそれぞれについて、公式の確認先URLを平時から台帳テンプレートに登録してください。

ここでの目的は、公式情報だけを待つことではありません。自社でも、PC・スマートフォン、ログイン前後、代表的な決済手段など、購入者に近い条件で再現を確認します。ただし、障害時にテスト注文を作ると受注・決済の照合を複雑にすることがあります。テスト環境、テスト用商品、テスト決済手段を使える場合を除き、無目的な注文操作は避け、実施した操作は必ず台帳に残します。

販売継続・限定販売・停止を判断する条件を先に決める

障害発生時に「全店を止めるか、何もしないか」の二択にすると判断が重くなります。販売状態を3段階にし、障害箇所ごとに切り替え条件を決めます。

継続：購入完了を確認でき、後続処理も維持できる

ストアフロントやチェックアウト、主要な決済、注文記録に異常がなく、外部連携に遅延があっても手動で補える場合は、販売を継続する選択肢があります。

ただし、「サイトが見える」だけでは継続判断に足りません。少なくとも以下を確認します。

• 注文完了画面または注文完了メールが正常に出るか
• 注文が管理画面または受注データに記録されるか
• 決済状態を確認できるか
• 在庫引当や出荷締切に影響する連携遅延がないか
• CSが購入者からの確認依頼を受けられるか

限定販売：流入または商品を絞り、影響拡大を抑える

一部の決済手段、特定端末、外部連携だけに不具合がある場合は、影響する広告キャンペーンや販売対象だけを止める判断があります。たとえば、注文は受けられるがOMS連携が止まっているなら、出荷能力と手作業で管理できる注文量を踏まえ、広告を一時停止しつつ自然流入だけを受ける設計です。

限定販売では、次を台帳に明記します。

• 停止するチャネル：リスティング広告、アフィリエイト、SNS広告、メール配信など
• 停止する商品・決済手段・配送地域
• 受注を継続する根拠
• 手作業で処理する上限と担当者
• 次回の再判定時刻

在庫が少ない商品、出荷締切が短い商品、予約・定期購入などは、連携遅延の影響が大きくなり得ます。一律の時間基準ではなく、自社の商材、出荷体制、広告費、代替導線の有無に合わせて基準を作ります。

停止：購入完了・決済・注文記録の整合性を担保できない

チェックアウトで注文確定できない、決済結果を確認できない、注文が欠落する可能性がある、在庫引当が機能せず過剰販売を防げない、といった場合は受注受付を停止します。広告や配信中のメール、SNSの固定リンクも同時に確認します。

受注停止は売上機会を失う対応ですが、成立状況が不明な注文を増やすコストや、購入者の混乱を抑える目的があります。停止する場合も、出荷作業まで止めるべきとは限りません。すでに受注・決済・在庫引当を確認済みの注文は、障害範囲と出荷システムの状態を確認したうえで、別途「出荷継続」「保留」を決めます。

一次告知は、原因ではなく確認済みの事実を伝える

原因未確定の段階で推測を書いた告知は、後で訂正の負担を増やします。EC-CUBE公式は、サイト閲覧不可などの障害時にサービス提供者の公式情報で状況を把握し、復旧見込みとともにトップページで告知することを案内しています。確認日：2026年9月16日。

一次告知では、原因の説明よりも、購入者が今取るべき行動を優先します。少なくとも次の項目を確定させます。

• 掲載時刻（例：○月○日 14:20時点）
• 起きている事実（ページ表示、購入手続き、注文確認など）
• 影響範囲（全ページか、一部機能か。未確認なら「確認中」）
• 購入操作を続けないでほしい条件
• すでに注文済みの顧客への案内
• 次回更新予定時刻
• 問い合わせ窓口

告知例は以下です。

現在、一部のお客さまにおいて購入手続きが完了しにくい事象を確認しています。原因および影響範囲を確認中です。購入完了画面または注文確認メールを確認できない場合は、同じ注文を繰り返さず、注文日時・商品名を添えてお問い合わせください。次回の状況更新は○月○日○:○○を予定しています。

この文面では、決済が完了しているかどうかを確認できていない段階で「注文は受け付けられていません」と断定していません。購入者に必要な行動と、次の更新時刻を示しています。

告知の掲載先は、障害範囲に応じて使い分けます。サイト内に表示できないなら、公式SNS、メール、サポートページなどを候補にします。ただしSNS投稿だけでは、すでにチェックアウトへ進んでいる購入者に届かない可能性があります。利用可能な画面、カートの告知機能、外部ページを事前に確認し、掲載先と更新担当を台帳に持たせます。

復旧後は「注文・決済・出荷」を別々に照合する

画面が復旧した時点は、障害対応の完了時点ではありません。障害開始から復旧宣言までの時間帯を対象に、少なくとも注文、決済、出荷・連携を別々に確認します。画面上の注文数だけで終えないことが重要です。

1. 対象時間帯と基準データを固定する

まず、台帳に記録した「最初の異常確認時刻」と「復旧確認時刻」を対象期間にします。公式の障害告知時刻だけでなく、自社で不具合を確認した時刻も残します。

次に、照合に使うデータと取得時刻を固定します。

• カート・受注管理の注文一覧
• 決済代行会社または決済サービスの取引一覧
• OMS・WMS・出荷管理の受注または出荷指示一覧
• 在庫引当・在庫変動の記録
• 障害中に作成した手動受付やCS記録

データの更新遅延があり得るシステムでは、復旧直後に一度照合して終えず、次回照合時刻も設定します。連携の再送や遅延反映がある場合、早すぎる確定は注文漏れと誤認する原因になります。

2. 不整合を4分類して担当を割り当てる

照合結果は、次のように分類すると処理を進めやすくなります。

返金、再決済依頼、再注文依頼は、決済状態と注文成立状況を確認してから実施します。障害時に購入者が複数回操作している可能性もあるため、氏名やメールアドレスだけで単純に重複扱いにせず、注文番号、決済取引ID、時刻、商品・金額を突き合わせます。

3. 購入者への個別連絡対象を抽出する

個別連絡は、障害告知を見た人だけを対象にしてはいけません。たとえば、決済済み未受注、受注済みだが出荷に影響、重複注文・重複決済の可能性がある注文など、照合結果から対象を抽出します。

連絡文には、確定事項、対応内容、購入者に求める操作の有無、回答期限を分けて記載します。未確定の状態で再注文を依頼すると重複の可能性があるため、注文・決済の確認中であれば、その旨と次回連絡時刻を伝えるほうが安全です。

そのまま使えるインシデント台帳の項目

スプレッドシート、チケット管理ツール、社内ドキュメントのいずれでも構いません。重要なのは、時系列、判断、照合結果を同じ案件番号で追えることです。

初動・販売判断シート

• インシデントID／起票者／発見日時
• 最初に確認した症状と再現条件
• 影響区分：ストアフロント／チェックアウト／決済／管理画面／外部連携
• 影響する端末、ページ、決済手段、商品、チャネル
• 公式情報の確認先、確認時刻、要点、次回確認時刻
• 自社確認の実施者、実施時刻、結果
• 販売状態：継続／限定販売／停止
• 広告・メール・SNS・外部モールの措置
• 出荷状態：継続／条件付き継続／保留
• 決定者、判断理由、次回再判定時刻

告知・CSシート

• 一次告知の掲載先、掲載時刻、掲載担当
• 告知に含めた影響範囲と次回更新時刻
• 更新履歴
• CS用の一次返信文
• エスカレーション条件（重複決済、注文確認不可、配送期限など）

復旧・影響注文照合シート

• 復旧確認時刻、確認者、確認条件
• 照合対象期間
• 注文一覧、決済一覧、OMS/WMS一覧の取得時刻
• 不整合分類、対象注文番号、決済取引ID
• 対応担当、対応内容、顧客連絡の要否
• 再照合予定と完了確認者
• 恒久対応候補と担当・期限

台帳は詳細な障害原因を記述する場所でもありますが、初動では空欄があって問題ありません。「未確認」「確認中」と記録し、誰がいつまでに確認するかを入れます。原因分析の完了を待たずに、販売・告知・照合を動かせることが、この台帳の役割です。

平時に30分で確認したい準備項目

障害時の判断を早めるには、ツール導入より先に連絡先と権限を確認します。次の項目を定期的に見直してください。

• カート、決済、OMS/WMS、配送、CDN・ホスティング、外部アプリの障害情報URL
• 各サービスの契約者、管理者、問い合わせ窓口、緊急連絡先
• 広告停止、サイト告知、受注停止、返金判断を実行できる担当者と権限
• テスト用商品・テスト注文の扱いと、テスト注文を除外する方法
• 注文、決済、出荷、在庫データを出力する手順
• サイトが表示できない場合の告知先と、告知ページの編集方法
• 商材ごとの出荷締切、在庫制約、手動処理の上限

障害のすべてを事前に防ぐことはできません。一方で、販売可否、告知、影響注文の照合をあらかじめ分離しておけば、「復旧したら終わり」ではなく、購入者と受注の状態を確認して通常運用へ戻す手順を作れます。まずは直近の小さな不具合やメンテナンスを題材に、台帳を一度書いてみると、連絡先・権限・照合データの不足を洗い出せます。

参考情報

• ECサイトの遅延・エラー発生時、6割以上が“静かに離脱”。別のECサイトで買い物は4割超【トラブル時の消費者調査】｜ネットショップ担当者フォーラム
• 消費者のWEBサイトの表示に関する調査｜MMD研究所
• Shopify Status｜Shopify
• お知らせ｜ecforce サポートサイト
• 障害・メンテナンス情報｜BASE ヘルプ
• ECサイト運営の仕事内容とは？業務の仕組みを図解＆必須スキルを解説｜EC-CUBE