
「顧客情報が流出した」というニュースを見ると、「うちのネットショップは大丈夫だろうか」と心配になりますよね。カートや制作会社に任せている場合は、自分たちがどこまで確認すればよいのか、分かりにくいこともあると思います。まずは、普段の受注・発送・顧客対応で扱う情報から、一緒に整理していきましょう。
ECサイトのセキュリティ対策では、システムの更新に加えて、日々の業務で情報をどう扱っているかも大切です。管理画面のアカウント、ダウンロードした顧客CSV、外注スタッフの権限、物流会社へ渡す配送データまで、顧客情報の流れに沿って確認する必要があります。
まずは「顧客情報がどこにあるか」「誰が扱えるか」「誰が保守するか」の3点を整理しましょう。この記事では、店長・EC担当者が店舗で見直すことと、カート会社・保守会社へ確認することを分けて解説します。
※事例・制度は2026年10月6日時点で確認した公表情報に基づきます。本記事の点検は運用上の見直しであり、技術的な安全性を保証するものではありません。
- 1 まず確認|ECサイトのセキュリティ対策12項目
- 2 なぜECサイトで個人情報が漏えいするのか
- 3 モール・クラウド型カート・自社構築で管理範囲は違う
- 4 顧客情報はどこにある?受注から発送までの流れを点検
- 5 管理画面とスタッフのアカウントを守る
- 6 顧客CSV・メール・配送データの漏えいを防ぐ
- 7 カート・サイト・外部連携の安全性を確認する
- 8 決済・会員アカウントの不正利用にも備える
- 9 制作会社・運営代行・物流会社に確認したいこと
- 10 個人情報漏えい・不正アクセスが疑われたときの対応
- 11 今日・今週・継続して取り組む対策
- 12 ECサイトのセキュリティでよくある質問
- 13 まとめ|顧客情報の流れと管理責任を整理しよう
- 14 EC運営の管理体制を整理したい方へ
- 15 参考・出典
まず確認|ECサイトのセキュリティ対策12項目
まずは次の12項目を見て、自社の状況を確認してみてください。すぐに答えられない項目は、「分からない」と記録して構いません。「対応済み・未対応・要確認」を分け、確認する人を決めておくと、点検しただけで終わらず改善につなげやすくなります。
| 番号 | 点検項目 | 最初の作業 | 確認する人 |
|---|---|---|---|
| 1 | 顧客情報の保存先が分かる | カート・受注管理・CSV・メール・共有フォルダを一覧にする | EC担当者 |
| 2 | 管理画面と業務メールを保護している | 利用可能な多要素認証とパスワードの使い回しを確認 | EC担当者・IT担当 |
| 3 | IDを担当者別に管理している | 共用IDと退職者・契約終了先のアカウントを確認 | 店長・管理者 |
| 4 | 顧客情報の権限を絞っている | 閲覧・CSV出力・削除の権限を業務に合わせる | 管理者・サービス会社 |
| 5 | 更新と保守の担当が決まっている | システム・機器の担当、期限、緊急連絡先を確認 | IT担当・保守会社 |
| 6 | 不要な外部連携が残っていない | アプリ・プラグイン・APIキーを棚卸しする | EC担当者・保守会社 |
| 7 | 会員ページの情報を適切に制限している | 自社管理範囲の注文履歴・APIの検証状況を確認 | 開発・保守会社 |
| 8 | 顧客CSVを安全に扱っている | 保存先、受け渡し方法、共有範囲、削除ルールを確認 | 受注・発送担当 |
| 9 | 委託先のデータ管理を把握している | 権限、再委託、保管、事故時の連絡を確認 | 委託管理担当 |
| 10 | 保管期間を決めている | 必要な保存と不要な複製を分ける | EC担当者・管理部門 |
| 11 | 異常の検知と復旧に備えている | ログ、通知先、バックアップ、復元手順を確認 | IT担当・保守会社 |
| 12 | 事故時の連絡体制がある | 責任者、相談先、報告・顧客対応の担当を決める | 経営者・関係担当 |
店舗の権限では変更できない項目もあります。分からない項目を推測で「対応済み」にする必要はありません。利用中のサービス会社へ確認し、回答と確認日を残しておきましょう。
なぜECサイトで個人情報が漏えいするのか
直近の公表事例では、原因が調査中のものもある
タイムズカーは2026年9月28日の公表で、約660万件のアカウントに関する情報が漏えいしたと報告しています。対象には退会済みの人や入会が完了していない人も含まれ、翌日の第3報では、本人確認書類が漏えいしたアカウントが約160万件と説明しています。確認した資料では侵入原因の詳細は調査中であり、特定のシステムやパスワード管理が原因だったと断定はできません。[1][2]
一方、デジタル庁が2026年9月に公表したGSSの事案では、VPN機器の脆弱性を悪用した侵入が原因と説明されています。公表済みの脆弱性について、修正プログラムを適用する前に悪用されたとされています。[3]
いずれもECサイトそのものの事例ではありません。ただ、EC担当者にとっても、保管する情報を増やしすぎないことや、サイト以外の接続機器まで保守範囲に含めることを考えるきっかけになります。
EC運営では「サイトへの侵入」と「情報の扱い」を両方確認する
ECで備えるべきリスクには、システムの脆弱性(攻撃に悪用されるおそれのある弱点)、管理アカウントの乗っ取り、アクセス制御の不備などがあります。さらに、顧客CSVの誤共有やメールの誤送信など、日常業務の情報の扱いにも注意が必要です。
例えば、会員が自分の注文履歴を見る機能には、ログインの確認だけでなく、他人の注文情報を閲覧できない制御が必要です。IPAも、認証に加えて利用者ごとの認可制御が必要だと説明しています。認証は「誰かを確認すること」、認可は「その人に何を許可するかを決めること」です。[4]
こうした問題を、EC担当者だけで判断するのは難しいこともあります。店舗が確認できる運用上の問題と、開発・保守会社の検証が必要な問題を分けると、誰に何を相談すればよいかが見えてきます。
モール・クラウド型カート・自社構築で管理範囲は違う

「カート会社に任せているから、どこまで自分たちで管理するのか分からない」という場合は、まず役割分担を確認しましょう。利用するシステムによって、店舗側で対策できる範囲は変わります。以下は基本的な整理なので、実際の担当範囲は契約内容とサービス仕様に照らして確認してください。
| 運営方式 | 店舗が確認すること | サービス・保守会社へ確認すること |
|---|---|---|
| 楽天・Amazonなどのモール | 店舗アカウント、スタッフ権限、取得した注文データ、外部連携 | 提供される認証・権限機能、異常時の窓口 |
| クラウド型カート | 管理画面、メール、CSV、外部アプリ、店舗が追加した設定 | 基盤の保守範囲、ログの確認方法、店舗側の担当範囲 |
| 自社構築・WordPress等 | 上記に加え、保守契約と更新体制 | サーバー・CMS・プラグイン・開発部分の更新と診断 |
クラウド型サービスを利用していても、店舗側が管理する情報や設定は残ります。IPAのECガイドラインも、SaaS型サービス(事業者が提供するシステムをインターネット経由で利用する方式)の利用時に自社の責任範囲で行う対策があると説明しています。[5]
「制作を依頼したこと」と「現在も保守を依頼していること」も分けて確認しましょう。納品後の更新や緊急対応が、契約に含まれているとは限りません。
顧客情報はどこにある?受注から発送までの流れを点検

何から始めるか迷ったら、顧客情報の保存先を確認するところから始めてみましょう。カートの会員情報だけでなく、受注管理サービス、倉庫への配送データ、問い合わせメール、返品対応の添付ファイルも対象にします。
発送用CSVを毎日ダウンロードしている場合、カートと受注管理サービスが安全でも、担当者のパソコンに複製が残ります。複数スタッフが同じ作業をしていれば、同じ顧客情報が何か所にも保存されることがあります。
いきなり複雑な管理台帳を作る必要はありません。まずは普段使っている表計算ソフトなどに、次の5項目を記録してみてください。
- 保存先:どのシステム・端末・フォルダにあるか
- 内容:氏名・住所・電話番号・購入履歴など、何が入っているか
- 権限:誰が閲覧・取得できるか
- 用途:受注・発送・顧客対応など、何に使うか
- 保管:いつまで残し、誰が削除するか
必要な取引記録と、作業のために作った一時的な複製は分けて考えます。保存期間は業務や法令上の必要性を確認して決め、顧客情報を一律に削除しないようにしましょう。
管理画面とスタッフのアカウントを守る
共用IDを見直し、業務に必要な権限へ絞る
店長、発送スタッフ、外注担当者が同じIDを使っていると、担当者ごとの権限調整や操作の確認が難しくなります。サービスが対応している場合は個別IDを発行し、担当業務に応じて顧客情報の閲覧やCSV出力を制限しましょう。
「商品登録を依頼する人に、全顧客のCSV出力権限まで必要か」と考えると見直しやすくなります。利用中のプランで細かい権限設定ができない場合は、その制約を把握して作業方法を検討してください。
退職、異動、外注契約の終了時には、アカウントだけでなく共有フォルダや連携サービスの権限も確認しましょう。日々の業務に追われると後回しになりやすいので、引き継ぎのチェック項目に入れておくと見落としを減らせます。
管理画面と業務メールをセットで保護する
多要素認証は、パスワードに加え、認証アプリやセキュリティキーなど別の要素で本人確認する仕組みです。利用できるサービスでは設定し、復旧コードなども適切に管理しましょう。
IPAのクラウド利用向け資料も、安全なパスワード、ID・パスワードの非共有、提供される追加認証の利用を挙げています。パスワード再設定に使う業務メールも、管理画面と一緒に保護してください。[6]
「アカウント停止」「未払い」といったメールから、慌ててログインしない運用も重要です。管理画面は保存済みの正規URLから開き、不審な連絡は別の連絡手段で確認します。
確認する人:店長・アカウント管理者
最初の作業:利用者と権限を一覧にし、追加認証の設定状況を確認する。
顧客CSV・メール・配送データの漏えいを防ぐ
必要なデータだけを、必要な相手へ渡す
配送会社や倉庫へ渡すデータに、発送に不要な顧客属性や過去の購入履歴まで含まれていないか確認しましょう。共有する情報を減らすことは、業務上の扱いやすさと、事故時の影響範囲の見直しにつながります。
| 見直したい運用 | 改善例 |
|---|---|
| 顧客CSVを毎回デスクトップに保存 | 承認した業務用保存先に集約し、作業用ファイルの削除手順を決める |
| 誰でも開けるリンクで発送データを共有 | 指定した相手のみアクセスできる方法を使い、必要に応じて期限を設定 |
| 外注先へ全顧客の一覧を渡す | 担当作業に必要な対象者・項目だけを渡す |
| 個人のメールや私用クラウドでやり取り | 会社が管理する受け渡し方法へ統一する |
受注や発送が忙しいときほど、確認を個人の注意力だけに任せないことが大切です。メール送信では、宛先、添付ファイル、対象者、共有権限を確認する手順を決めましょう。共有リンクを使えば安全になるわけではなく、アクセスできる相手の設定まで確認する必要があります。
確認する人:受注・発送・顧客対応担当
最初の作業:普段のCSV出力と受け渡しを実際にたどり、保存先と共有範囲を確認する。
カート・サイト・外部連携の安全性を確認する
更新を誰が行うか、緊急時に誰へ連絡するか
公開時に安全性を確認していても、その後に弱点が見つかる場合があります。IPAは、ECサイトの公開前の脆弱性診断や、運用中のセキュリティパッチ適用を対策として示しています。[7]
技術的な更新作業を、ご自身で無理に行う必要はありません。EC担当者がまず把握しておきたいのは、更新の担当者、保守対象、サポート期限、緊急時の連絡先です。VPNなどの保守用機器や業務端末も、管理範囲から抜けていないか確認します。
使わないアプリ・プラグイン・API連携を残さない
外部アプリやAPI連携には、注文情報や顧客情報を取得する権限が付いていることがあります。利用目的、担当者、取得する情報を一覧にし、使わなくなった連携を見直しましょう。
削除する前には、受注・在庫・発送に影響しないか確認します。侵害が疑われる場合は通常の整理として削除せず、証拠保全を含めて専門事業者へ相談してください。
確認する人:IT担当・制作会社・保守会社
最初の作業:保守対象と外部連携の一覧を作り、担当不明の項目をなくす。
決済・会員アカウントの不正利用にも備える
個人情報漏えいと、盗まれたカードによる不正注文、顧客アカウントの乗っ取りは、関連していても同じ問題ではありません。個人情報の扱いを見直すことに加えて、決済会社やカートが提供する不正利用対策も確認しましょう。
本人認証、ログイン保護、不審な注文への対応などは、サービスや契約によって異なります。何が提供され、何を店舗側で設定・判断するのかを確認してください。まずは利用中のサービスの公式案内で、設定できる機能と店舗側の対応範囲を確認しましょう。
制作会社・運営代行・物流会社に確認したいこと
委託先へ何を聞けばよいか迷うこともありますよね。「セキュリティは大丈夫ですか?」という質問だけでは、実際の管理方法までは分かりません。下の質問例から、自社の業務に関係するものを選んで確認してみましょう。
| 確認先 | 質問例 |
|---|---|
| 制作・保守会社 | 更新、脆弱性への緊急対応、ログ保管は誰が担当しますか? |
| カート・受注管理会社 | 顧客情報の閲覧やCSV出力を、担当者ごとに制限できますか? |
| 運営代行会社 | 利用するアカウントと、契約終了時の権限停止・データ返却または削除の手順は? |
| 物流・発送代行会社 | 配送データはどこで、誰が、いつまで保管しますか? |
| 各委託先 | 再委託の扱いと、事故が疑われた場合の連絡・調査協力はどうなっていますか? |
回答はメールや管理表に残し、未対応項目には担当者と期限を付けましょう。すぐに対応できない項目があっても、担当不明のままにしないことが大切です。契約で決めた内容が実際の作業でも守られているか、定期的に確認していきます。
個人情報漏えい・不正アクセスが疑われたときの対応

社内連絡、封じ込め、証拠保全を並行して進める
異常を見つけたときは、一人で原因を突き止めようとせず、まず社内責任者と保守会社へ連絡しましょう。必要に応じて専門事業者の支援を受け、対応した内容と時刻も記録します。不正な通信やアカウントの遮断、該当機能の停止など、被害拡大を防ぐ対応と、ログ・操作履歴などの保全を並行して進めてください。
慌てて端末やサーバーを初期化したり、ファイルをすべて削除したりすると、調査が難しくなることがあります。発覚日時、異常の内容、実施した対応、影響したシステムを記録し、調査担当者と連携しましょう。
カード情報への影響が疑われる場合は、決済代行会社などにも連絡し、必要な対応を確認します。
報告・本人通知は、人数だけで判断しない
個人情報保護法上、個人データの漏えい等の報告対象には、要配慮個人情報を含む場合、財産的被害のおそれがある場合、不正目的による漏えい等の場合、1,000人を超える場合などがあります。漏えいのおそれの段階でも対象になる場合があり、少人数だから報告不要とは限りません。[8]
報告対象事態を知った後、速報は速やかに、目安として概ね3~5日以内。確報は、その事態を知った日から原則30日以内、不正目的で行われたおそれのある事態では60日以内です。対象となる本人への通知も原則として必要で、状況に応じて速やかに行います。例外や窓口を含め、公式案内で確認してください。[9]
顧客への説明では、確認できた事実、対象情報、現在の対策、注意点、問い合わせ先を示します。調査が終わっていない段階で「被害はありません」と断定せず、未確認事項と続報の更新日も明記しましょう。
今日・今週・継続して取り組む対策
- 今日:アカウントと顧客情報の保存先を確認する。
- 今週:未確認の権限・保守範囲・委託先の管理について回答を得る。
- 継続:入退社、契約終了、外部アプリ導入時に点検し、定期的に棚卸しする。
すべてをEC担当者一人で解決する必要はありません。点検表に担当者と期限を付け、システム側の確認は保守会社へ、社内ルールは責任者へつなぎましょう。自分で対応することと、確認を依頼することを分けるだけでも、次の作業が明確になります。
緊急性の高い脆弱性や不審なアクセスは、定例点検まで待たずに対応してください。
ECサイトのセキュリティでよくある質問
HTTPS対応なら個人情報は流出しませんか?
HTTPSは通信を保護する仕組みです。管理アカウントの乗っ取り、サーバー内の情報への不正アクセス、顧客CSVの誤共有まで防ぐものではありません。通信、保管、アクセスを分けて確認します。[10]
クラウド型カートを使っていれば店舗側の対策は不要ですか?
不要ではありません。基盤の保守をサービス会社が担当していても、店舗のID、スタッフ権限、CSV、外部アプリ、業務メールには、店舗側で管理する範囲があります。[5]
バックアップがあれば個人情報漏えいにも対応できますか?
バックアップは、データ消失や業務停止からの復旧に備える対策です。すでに持ち出された情報を取り戻すものではありません。保護と検知に加え、復元できるかまで確認しましょう。[11]
WAFを導入すれば、ほかの対策は不要ですか?
不要にはなりません。WAF(Webサイトへの攻撃通信を検知・遮断する仕組み)は対策を補助しますが、プログラムの弱点や権限の不備が解消したことを保証しません。自社の管理範囲について、保守・改修・診断と組み合わせて考えます。[5]
まとめ|顧客情報の流れと管理責任を整理しよう
ECサイトのセキュリティ対策では、サイト本体と、受注・発送・顧客対応で扱う情報の両方を見る必要があります。管理画面だけを確認して終わらせず、CSV、メール、外部アプリ、委託先まで点検しましょう。
まずは「情報の保存先」「扱える人」「保守の担当者」を整理してみてください。分からない項目はそのままにせず、関係者へ確認していきましょう。店舗の運用で改善できる部分を進め、技術的な診断や事故調査が必要な部分は専門事業者へつなぐ。その役割分担を明確にすることが、顧客情報を守るための出発点です。
EC運営の管理体制を整理したい方へ
「担当者ごとに作業方法が違う」「外注先との役割分担があいまい」といったEC運営のお悩みは、無料相談でお聞かせください。現在の業務や困っていることを伺い、運用を見直す際の優先順位を一緒に整理します。
技術的な脆弱性診断や、漏えい事故の調査・緊急対応が必要な場合は、保守会社やセキュリティ専門事業者へ連絡してください。
参考・出典
事例・制度の確認日:2026年10月6日。公表内容や案内が更新される場合があるため、個別の対応は各公式ページで確認してください。