バックアップだけでは足りない。サイバー攻撃を受けたあとのEC生存戦略

サイバーセキュリティ対策が盛んに叫ばれています。
ファイアウォール、WAF、多要素認証、脆弱性診断 etc…
防御を固めることは、自社でECを運営する事業者にとって、もはや当たり前の投資です。

しかし・・・

「実際に攻撃を受けてしまった、その後」の備えは、できていますか。

防御は「起こさないための投資」です。しかし、どれだけ固めても、事故の確率をゼロにはできません。
だからこそ、防御と同じ重さで考えておきたいのが「起きてしまった後、どう事業を止めないか」というリカバリー（事業継続）の設計です。

サーバー障害は「連鎖」襲ってくる・・

自社運用のサーバーやデータベースがダウンした場面を、具体的に想像してみてください。

データのバックアップと復旧手順を用意しておくのは、基本中の基本です。ですが、本当に怖いのはデータそのものよりも、復旧までのダウンタイム中に「顧客との接点」がまるごと止まることです。

• メールサーバーが同じ環境にあれば、注文確認も、お詫びの一斉連絡も送れない
• データベースが止まれば、顧客リストを出力できない
• 電話で対応しようにも、手元に名簿がなければ誰にもかけられない

攻撃を受けた事実以上に、「連絡すらできず、顧客を放置してしまった」ことのほうが、信頼を大きく損ないます。
リカバリー設計とは、このマイナス連鎖をどこで断ち切るかを、あらかじめ対策しておくことです。

ポイントは3つ。販売基盤・販路・顧客接点を、それぞれ”自社サーバー1点”に依存させないことです。

1. 販売基盤 ─「自社運用」から「マネージド」へ

まず検討したいのが、EC基盤そのものをマネージド型（SaaS型）のプラットフォームに乗せることです。代表例、たとえば Shopify です。

Shopifyはサーバーの契約・運用を自社で抱えないASP／SaaS型のプラットフォームで、インフラの監視、負荷対策、セキュリティパッチ、障害対応はすべてプラットフォーム側が担います。
稼働率も年間99.9%以上の水準で運用されています。

つまり、「自社サーバーが落ちる」という事故のかなりの部分を、そもそも自社の管理範囲から外せるということ。中小事業者にとって、これは単なる乗り換えではなく、運用リスクとインフラ人材コストを構造的に軽くする選択肢になり得ます。

2. 販路・集客 ─ 入り口をひとつに集中させない

次に、Metaショップ（Facebook / Instagramショッピング） や Googleショッピング（Google Merchant Center Next） との連携です。

ただ、Metaは2025年に、Facebook / Instagram内で購入を完結させるアプリ内決済（ネイティブチェックアウト）を段階的に終了しました。現在これらは「商品を発見してもらい、購入は自社サイト（＝ECサイト）側で完結させる」ディスカバリー（集客）チャネルとして機能しています。Googleショッピングも、Merchant Center Nextの無料リスティングで商品露出を広げられます（Google広告アカウントは必須ではありません）。

したがってこれらは「自社サイトが落ちたときの”別の店舗”」ではありません。しかし、集客の入り口を検索・SNS・モールへと分散させておくこと自体が、特定チャネル依存のリスクを下げます。そして商品カタログを各所に同期しておけば、購入導線はマネージドなShopify側で受け止められる→販売基盤と販路の分散が、ここで噛み合います。

3. 顧客接点 ─ メールサーバーに依存しないSNSで連絡経路を持つ

リカバリー設計で最も見落とされがちなのが連絡経路です。

自社のメールサーバーが止まっても、Instagram DM、Messenger、LINE公式アカウントは生きています。
これらは自社インフラの外にあるため、サーバー障害の影響を受けません。

ECサイトのSNS連携・LINE連携は、集客施策としてだけ語られがちです。しかし重要な本質は、
平常時から顧客とつながっておくこと自体が、有事の連絡経路（リスクヘッジ）になるのです。

「サーバーが落ちてから連絡手段を探す」のでは遅い。
普段から複数の接点を育てておくことが、そのまま非常時の備えになります。

そして一歩先へ ─ クラウド型AIチャットボットで「止まらない顧客対応」

もう一段踏み込むなら、AIチャットボットが強力なアシストになります。
※クラウド型（マネージド）のAIチャットボット

平常時から顧客ごとのやり取り（会話履歴）を蓄積しておけば、AIが顧客ごとの文脈を踏まえた個別対応を、24時間止まることなく続けられます。自社サーバーが障害中でも、クラウド側のチャットボットが一次窓口として顧客対応を継続する—縮退運用によるフェイルオーバーです。

ただし、ここにも設計上の”重要ポイント”があります。会話履歴の置き場所です。

顧客履歴が自社サーバー内のDBにしか存在しなければ、サーバーが落ちた瞬間に、クラウド側チャットボットは参照すべきデータを失います。履歴ストアそのものが**単一障害点（SPOF）**になってしまうわけです。ここを外すと、この構想は成立しません。

だから実装に際しては、次のポイントを押さえる必要があります。

• 履歴を主系（自社サーバー）と独立したクラウドに保持・同期しておく（落ちても参照できる場所に置く）
• 縮退運用時のスコープを線引きする（回答・案内は継続、注文や予約などの書き込み系は制限、など）
• 個人情報の取り扱いとアクセス制御、およびプロンプトインジェクション対策（システムプロンプトの秘匿・権限のホワイトリスト化・入出力フィルタ）

「防御」ではなく「事業を止めない設計」として、AIチャットボットを位置づける。これで初めて、サイバーレジリエンス（回復力）は形になります。

まとめ

攻撃は、いつか受けるかもしれない前提で考える時代になりました。
だとすれば、問われるのは「受けた後、どれだけ早く、顧客を待たせずに立ち直れるか」です。

• 販売基盤は、マネージド（Shopify）で運用リスクそのものを手放す
• 販路・集客は、SNS・検索・モールへ分散させる
• 顧客接点は、メールサーバーに依存しない経路（LINE・DM）を平常時から育てる
• 顧客対応は、履歴をクラウドに持たせたAIチャットボットで止めない

これらは「攻撃されてから」ではなく、平常時にしか設計できません。

私たちは、Shopifyを軸としたEC構築、SNS・LINE連携、そしてRAG（履歴参照型）AIチャットボットの実装まで、ワンストップでご支援しています。「うちのECは、落ちたときにどうなるのか？」—その一度きりのシミュレーションから、ぜひご相談ください。

ご相談はお気軽に。現状のEC構成をお伺いし、リカバリー設計の”弱点”を可視化するところからご提案します。