DAY35では、ECサイトで購入者へ表示する、販売者情報、商品価格、送料、支払時期、配送時期、返品条件を整理しました。DAY36では、購入者が注文するときにEC事業者へ渡す情報を扱います。

商品を1個発送するだけでも、氏名、郵便番号、住所、電話番号、メールアドレス、注文商品、購入金額、支払方法、配送状況、問い合わせ内容といった情報が動きます。これらはECシステムの中だけに保存されるとは限らず、ECカート→決済代行会社→在庫管理システム→物流倉庫→配送会社→メール配信システム→カスタマーサポートというように、複数の会社や担当者が、注文処理に必要な範囲で情報を取り扱います。

問題は、個人情報を持っていること自体ではありません。なぜ取得したのか、誰が見られるのか、どの会社へ渡すのか、どこへ保存されるのか、いつ削除するのか、漏れた場合にどう動くのかが決まっていないことです。個人情報保護法では、利用目的の特定、目的に沿った利用、安全管理措置、従業者・委託先の監督、一定の漏えい時の報告などが求められています。

ECで扱う情報の分類｜個人情報・個人データ・保有個人データ

個人情報とは、生存する個人に関する情報で、氏名などにより特定の個人を識別できるものや、他の情報と容易に照合することで特定の個人を識別できるものなどを指します。ECでは、氏名、住所、電話番号、メールアドレス、生年月日、会員番号、注文番号、配送先、問い合わせ内容が代表例です。注文番号だけでは誰の注文か分からなくても、EC管理画面で氏名や住所と結び付けられるなら、個人情報として扱う必要があります。

ECで扱う情報は、会員情報（氏名・メールアドレス・電話番号・住所・ログインID・登録日）、注文情報（注文番号・購入商品・数量・購入金額・注文日時・クーポン・ポイント利用）、配送情報（配送先氏名・住所・電話番号・送り状番号・配達状況）、決済情報（支払方法・決済結果・決済番号・返金状況・カードブランド・カード番号の一部）、問い合わせ情報（問い合わせ内容・返品理由・商品の写真・通話やメールの履歴）、アクセス・行動情報（閲覧ページ・検索履歴・クリック履歴・Cookie等の端末識別子・IPアドレス）に分類できます。購入履歴や閲覧履歴、Cookie等は、単独では個人情報に当たらない場合でも「個人関連情報」に該当することがあり、会員情報などと結び付いて特定の個人を識別できる場合は、個人情報として扱われる可能性があります。

個人情報は個人を識別できる情報全般です。個人データは、個人情報データベース等を構成する個人情報で、顧客番号で検索できる、氏名で注文履歴を表示できる、メールアドレスで会員を検索できるというように、検索できる状態で管理されている顧客情報です。保有個人データは、個人データのうち、事業者が開示、訂正、削除、利用停止等を行う権限を持つものです。本人は一定の場合に、自分の保有個人データの開示等を請求できます。初心者の段階では、細かな分類以前に、顧客に関する情報は勝手に見たり持ち出したりしないという共通ルールを設けることが重要です。

先に結論｜個人情報は6つの段階で管理する

個人情報の管理は、セキュリティソフトを入れるだけでは完了しません。①取得→②利用→③共有・提供→④保存→⑤削除・廃棄→⑥事故対応という段階で管理します。

個人情報保護委員会のガイドラインでも、取得、利用、保存、提供、削除・廃棄などの段階ごとに、取扱方法や責任者を定める考え方が示されています。

最初に利用目的を決める・知らせる

個人情報を取得するときは、何に使うのかをできるだけ具体的にします。商品の注文受付、代金決済、商品発送、配送状況の連絡、返品・交換・返金対応、問い合わせ対応、不正注文の確認、会員サービスの提供、本人が希望した案内の配信のように、本人がどのように情報を使われるか予測できる程度に具体化する必要があります。「事業活動に利用します」「サービス向上に利用します」「必要に応じて利用します」だけでは、広告に使うのか、配送に使うのか、第三者へ渡すのか判断しにくくなります。

個人情報の利用目的は、あらかじめ公表するか、取得後速やかに本人へ通知・公表する必要があります。プライバシーポリシー、会員登録画面、注文入力画面、問い合わせフォーム、メールマガジン登録画面などで確認できるようにします。本人からフォームなどの書面・画面を通じて直接取得する場合は、原則として利用目的をあらかじめ明示します。

取得する情報を絞り込む｜会員登録とゲスト購入

商品を発送するのに必要な情報は、一般的に氏名、住所、電話番号、メールアドレス、注文商品です。一方、通常の商品購入で、生年月日、性別、勤務先、家族構成、年収、SNSアカウントを必須にする必要があるかは再確認します。必要性が低い情報を集めるほど、管理項目と漏えい時の影響が増えます。取得項目ごとに、何のために必要か、必須か任意か、いつ削除するかを説明できる状態にします。

ECには、アカウントを作り住所・購入履歴を保存して次回購入で再利用する「会員購入」と、購入に必要な情報だけ入力し会員アカウントは作らない「ゲスト購入」があります。会員登録には利便性がありますが、購入後も顧客情報を継続して保持します。会員機能を設ける場合は、アカウントの削除方法、住所変更の方法、パスワード再設定、退会後に残す情報、購入履歴の表示期間を決めます。

商品の配送目的で取得したメールアドレスを、別途広告メールに使う場合は注意が必要です。注文確認・発送通知・返品連絡と、新商品のお知らせ・セール案内・関連商品の広告は目的が異なります。当初の利用目的を超えて個人情報を利用する場合は、原則として本人の同意が必要です。同じ会社内の別部署が利用する場合でも、当初の目的を超える利用であれば同様に確認が必要です。取引に必要なメールと広告・メールマガジンを分け、広告配信の停止方法も用意します。

決済情報の取り扱い｜カード情報は専門の決済システムに任せる

EC事業者が確認する情報には、決済結果（決済成功・失敗・審査中・返金済み）、決済管理情報（決済番号・決済日時・支払方法・カードブランド・カード番号の末尾）、カード情報（カード番号・有効期限・名義・セキュリティコード）という違いがあります。EC事業者が決済代行サービスを利用している場合、自社で完全なカード番号を保存せず、決済結果やトークンなどだけを受け取る構成があります。ただし、決済を外部委託しても、利用する決済事業者のセキュリティ対応や責任分担を確認する責任がなくなるわけではありません。

購入者から「決済できないのでカード番号をメールで送ります」と言われても、通常のメールやチャットでカード番号を受け取る運用は避けます。PCI DSSでは、保護されていないカード番号をメール、SMS、チャットなどで送信することを認めていません。カード情報を誤って受け取った場合は、放置・転送せず、安全に削除するか、対象システムを適切に保護する必要があります。購入者には、メールでカード番号を送らない、チャットへ画像を貼らない、電話メモに残さない、決済代行会社の画面を利用するといった安全な決済画面を案内します。カード裏面等に記載されたセキュリティコードは、決済承認後に保存することがPCI DSSで禁止されており、暗号化しても保存できません。問い合わせメール、紙の注文書、顧客メモ、通話記録、チャット履歴、スクリーンショットへ残さないようにします。

クレジットカード情報を自社で直接入力・保存する構成よりも、PCI DSSへ対応した決済代行事業者の決済ページへ遷移させる方法などを検討します。日本のクレジットカード・セキュリティガイドラインでも、EC加盟店のカード情報非保持化や、PCI DSSへの対応、ECサイト自体の脆弱性対策などが示されています。2025年4月以降は、EC加盟店にセキュリティ・チェックリストの対策実施が求められています。ただし、外部の決済画面を使っている＝自社ECサイトの対策は不要ではありません。不正な決済画面へ誘導する改ざんなどを防ぐため、自社サイト側の更新・監視も必要です。

委託と第三者提供の違い｜配送会社・倉庫への情報連携

商品を配送するためには、配送会社へ配送先氏名、住所、電話番号、商品・荷物情報を渡します。これは注文履行に必要な業務委託として整理されることがあります。個人データの取扱いを委託する場合、委託先は法律上の「第三者」に当たらない場合がありますが、委託元は委託先を必要かつ適切に監督しなければなりません。物流倉庫には、注文番号、商品SKU、数量、配送先氏名、住所、電話番号、配送方法など必要な情報だけを連携し、過去の全購入履歴、問い合わせ内容、生年月日、広告配信の同意状況など倉庫作業に不要な情報まで渡さないようにします。委託先とは、利用できる業務、アクセスできる担当者、再委託の有無、事故時の連絡期限、契約終了後の削除を確認します。

委託は、自社の業務を実行するために必要な範囲で個人データを渡すことで、配送、倉庫作業、メール配信、カスタマーサポート、システム保守が該当します。第三者提供は、別の事業者が自社の目的で個人データを利用するために渡す場合などです。個人データを第三者へ提供する場合は、法令上の例外を除き、原則としてあらかじめ本人の同意が必要です。「取引先だから」「グループ会社だから」だけで自由に渡せるわけではありません。

ECでは、意識しないまま多くのサービスへ情報が送られます。ECカート（会員・注文情報）、決済代行（決済情報）、物流倉庫（注文・配送情報）、配送会社（宛名・住所・電話番号）、メール配信（メールアドレス・配信履歴）、CSツール（問い合わせ・注文情報）、アクセス解析（閲覧・端末情報）というように、最低でもサービス名、利用目的、送信する情報、保存される国・場所、契約担当者、管理画面の利用者、解約時の削除方法を一覧にします。外国で個人データを取り扱う場合は、外国の個人情報保護制度等を把握したうえで、安全管理措置を講じる必要があります。

アクセス権限の設計｜見られる人を限定する

全従業員がすべての顧客情報を見られる必要はありません。出荷担当は商品・住所・配送方法、CS担当は注文・問い合わせ・返金状況、経理担当は売上・決済・返金情報、広告担当は集計・分析情報というように、担当ごとに必要な情報の範囲を分けます。個人情報保護委員会のガイドラインでは、担当者と利用できるデータベースの範囲を限定するアクセス制御や、利用者の識別・認証が安全管理措置として示されています。

全員が同じID、全員が同じパスワード、退職者もパスワードを知っているといった共通アカウントは避けます。共通アカウントでは、誰が見たか、誰が変更したか、誰がCSVを出力したかを確認できません。担当者ごとにアカウントを発行し、業務に必要な権限だけを付与します。個別ID、多要素認証、管理者権限の限定、アクセス履歴の確認、長期間未使用アカウントの停止といった対策を行います。

退職者のアカウントを放置すると、退職後も注文情報へアクセスできる可能性があります。退職・異動日には、EC管理画面、決済管理画面、倉庫システム、メール、チャット、クラウドストレージ、スプレッドシート、広告・分析ツールを確認します。退職予定を管理者へ連絡→担当業務を引き継ぐ→最終出勤日に権限停止→共有パスワードを変更→個人端末のデータを削除、という手順で進めます。

CSV・スプレッドシート・チャットでの取り扱い

EC管理画面から注文情報をCSVで出力すると、システムの外へ個人情報が複製されます。注文管理システム→CSVダウンロード→パソコンのダウンロードフォルダー→メール添付→スプレッドシートへコピー、というように複製が増えるほど、削除漏れや誤送信が起こりやすくなります。誰が出力できるか、何の目的で出力するか、保存場所、ファイル名、削除日、再共有の禁止を確認します。

スプレッドシートは便利ですが、共有設定を誤ると、リンクを知る人が閲覧できる状態になることがあります。一般公開になっていないか、組織外共有が必要か、閲覧者・編集者は誰か、コピー・ダウンロードが必要か、退職者が残っていないかを最低限確認します。顧客情報を扱うシート（氏名・住所・注文内容）と、集計用シート（日別売上・商品別数量）を分け、分析に氏名や住所が不要なら集計情報だけを使用します。

別の購入者の注文情報を送った、返品写真を違う相手へ送った、CSVを誤って添付した、宛先をCCに入れて一斉送信したといったメールの誤送信はECで起こりやすい事故です。個人情報保護委員会のガイドラインでも、個人データを含むメールを第三者へ誤送信した場合は、個人データの漏えいに該当する例として示されています。注文番号だけで自動生成する、送信前に宛先と添付を確認する、一斉配信は専用システムを使う、個人情報を本文へ必要以上に書かないといった対策を行います。社内チャットへ購入者の氏名・住所を全文貼付するのも避け、注文番号で確認できるなら「注文番号：ORDER-001　配送先変更あり　管理画面で確認してください」のように、注文番号と必要な要点だけを書きます。ただし、注文番号から顧客を特定できる環境では、注文番号も適切に管理します。ECサイトの動作確認で、実際の購入者情報をテスト環境へコピーすると管理対象が増えるため、テストには架空データを使用します。

4つの安全管理措置

個人情報はクラウド上だけにあるとは限りません。送り状、返品受付票、電話メモ、印刷した注文一覧、CSVを保存したパソコン、USBメモリーも管理対象です。ガイドラインでは、個人データを扱う区域への入退室管理、書類・媒体の盗難や紛失防止、持ち運び時に内容を容易に判別できない措置などが物理的安全管理措置として示されています。紙を使う場合は、施錠保管、机上へ放置しない、不要になったら裁断、持ち帰らない、印刷枚数を限定するといった対応を行います。

安全管理措置は4つに分けて考えます。組織的安全管理措置（責任者を決める、取扱ルールを作る、アクセス状況を点検する、事故時の連絡体制を作る）、人的安全管理措置（担当者を教育する、秘密保持を定める、退職時に権限を停止する）、物理的安全管理措置（書類を施錠する、パソコンを放置しない、USB・紙の持出しを制限する）、技術的安全管理措置（アクセス制御、ID・パスワード管理、不正アクセス対策、システムの更新、通信・保存の保護）です。事業規模、データの内容・量、漏えい時の影響などに応じて、必要かつ適切な対策を設計します。

保存期間と削除ルール

個人情報を永久に持ち続けると、不要なデータまで漏えいリスクを抱えます。未完了注文は取引完了まで必要、購入履歴は問い合わせ・法令・会計上の必要性を確認、返品記録は返品・保証対応に必要な期間、問い合わせは対応・再発防止に必要な期間、一時CSVは作業終了後に削除、退会アカウントは残す情報と削除する情報を分ける、というようにデータごとに期間を決めます。個人データは正確かつ最新の内容を保つよう努め、利用する必要がなくなった場合は遅滞なく消去するよう努めることが求められています。ただし、取引・会計・トラブル対応など別の理由で保存が必要な情報まで一律に削除するのではなく、保存根拠を整理します。

顧客情報は、EC本体、決済システム、倉庫システム、メール配信、CSツール、CSV、バックアップ、紙の注文書など複数の場所へコピーされている可能性があります。削除ルールには、削除対象、削除時期、削除担当者、委託先への削除依頼、バックアップ上の扱い、削除記録を含めます。

本人は、事業者が保有する一定の個人データについて、開示、訂正、利用停止等を請求できる場合があります。受付方法、本人確認方法、対象データの調査担当、回答期限の管理、回答方法、手数料の有無を決めた問い合わせ窓口を用意します。本人確認をせずに回答すると、別人へ個人情報を渡してしまう可能性があります。購入者が会員住所を変更した場合でも、過去の注文記録をすべて新住所へ書き換えるとは限らず、現在の会員住所（次回購入に使用）と過去注文の配送先（当時の取引記録）を分けます。注文後の配送先変更も、会員情報だけでなく、対象注文、倉庫への出荷指示、配送ラベルへ反映されたか確認します。

漏えい・滅失・毀損と報告対応

漏えいは外部へ情報が流出した状態（誤送信、不正アクセス、公開設定ミス、端末・書類の盗難）、滅失は情報を失った状態（データを誤って削除、書類を紛失、バックアップがない）、毀損は情報が意図せず変更されたり利用できなくなった状態（データ改ざん、ランサムウェアによる暗号化、復元キーの喪失）です。これらの考え方は、個人情報保護委員会のガイドラインで整理されています。

現行制度では、要配慮個人情報が含まれる、財産的被害のおそれがある、不正アクセスなど不正目的のおそれがある、1,000人を超える個人データが対象、といった事態が発生した、または発生したおそれがある場合に、個人情報保護委員会への報告と本人通知が必要になります。ECでは、カード・口座等に関係する情報や、不正アクセスによる注文情報の流出などに注意が必要です。

漏えいが発覚した場合の基本的な流れは、①責任者へ直ちに報告→②被害拡大を止める→③事実関係を調査→④影響範囲を特定→⑤報告対象か判断→⑥本人・委員会へ対応→⑦再発防止です。報告対象事態を知った場合、速報は速やかに行います。「速やか」の目安は個別事情によりますが、おおむね3〜5日以内とされています。確報は原則として知った日から30日以内、不正目的によるおそれがある事態は60日以内です。本人への通知も、状況に応じて速やかに行う必要があります。事故発生後に一から調べるのではなく、事前に連絡先と判断責任者を決めます。

実際のケースで考えてみよう｜100人分の注文CSVを誤送信した

EC担当者が、物流倉庫へ注文CSVを送ろうとしましたが、宛先を間違え、別の取引先へ送信しました。CSVには、注文番号、氏名、住所、電話番号、商品名、購入数量が含まれていました。

Step1〜2｜拡大を止め、責任者へ報告する

誤送信先へ連絡し、ファイルの削除を依頼し、転送・保存の有無を確認し、メール共有リンクを停止します。ただし、削除を依頼しただけで漏えいがなかったことにはなりません。担当者だけで処理せず、発生日時、発覚日時、送信者、送信先、対象人数、含まれる情報、暗号化・パスワードの有無、誤送信先の対応を記録し、個人情報管理責任者へ直ちに報告します。

Step3〜4｜影響範囲を確認し、報告対象か判断する

対象人数100人、対象期間8月1日〜8月5日、情報項目は氏名・住所・電話番号・購入商品、第三者の閲覧は確認中というように整理します。CSV以外の添付や、メール本文に情報が含まれていないかも確認します。100人であるため「1,000人を超える」には該当しませんが、不正目的によるものか、財産的被害のおそれがあるか、要配慮個人情報が含まれるかを確認する必要があります。報告義務の有無だけでなく、購入者への影響や二次被害を考えて対応を決めます。

Step5｜再発防止

CSV送信を廃止し倉庫システムへ直接連携する、外部共有リンクに期限を設定する、送信前の承認を設ける、出力項目を必要最小限に限定するなど、単に「今後は気を付けます」で終わらせず、情報を移動させる方法自体を変更します。

よくある失敗

個人情報管理を設計する12の質問

1. どの情報を取得していますか？フォーム、注文、決済、問い合わせに分けます。
2. それぞれ何のために必要ですか？利用目的を具体的にします。
3. 必須でなくてもよい項目はありませんか？取得項目を減らします。
4. どのシステムへ保存されますか？EC、倉庫、決済、メール等を一覧化します。
5. 誰が閲覧できますか？担当者ごとの権限を設定します。
6. CSVを誰が出力できますか？ダウンロード権限と削除日を決めます。
7. 委託先へ何を渡していますか？目的と必要性を確認します。
8. カード情報を自社で扱っていますか？決済画面、メール、電話対応を確認します。
9. 退職者の権限を止められますか？停止対象システムを一覧化します。
10. いつ削除しますか？データごとの保存期間を決めます。
11. 購入者から開示等を求められたら誰が対応しますか？本人確認と回答手順を作ります。
12. 漏えい時の責任者は誰ですか？休日・夜間も含む連絡方法を決めます。

やってみよう｜取得項目 要否診断＆安全管理 自己診断チェックリスト

会員登録や注文フォームで集めようとしている項目が、通常の商品購入で本当に必要かを確認できるほか、自社の安全管理の基本ができているかをチェックできます。入力内容はこのブラウザにのみ保存され、外部へは送信されません。

アウトプットワーク｜EC個人情報管理表を作ろう

現在利用している、または想定するECについて、個人情報の流れを整理してください。分からない内容は推測せず、ECカート、決済代行、物流倉庫、配送会社、メール配信、アクセス解析、社内権限、プライバシーポリシー、委託契約を確認してください。

理解度チェッククイズ

よくある質問

今回のまとめ

ECでは、商品を販売するだけで、氏名、住所、連絡先、購入履歴、決済・配送情報など、さまざまな情報を取り扱います。今回覚えておきたいポイントは、次の5つです。

1. 取得する情報と利用目的を具体的にする
2. 業務に必要な人・会社だけが情報を扱う
3. カード情報は安全な決済サービスで処理する
4. 保存場所・保存期間・削除方法を決める
5. 漏えい時の責任者と対応手順を事前に決める

基本的な流れは、取得項目を一覧化→利用目的を決める→取得画面で明示→保存システムを確認→担当者の権限を限定→委託先と契約・監督→CSV・紙・メールを管理→保存期間を設定→不要データを削除→開示・訂正等の窓口を整備→漏えい対応の訓練・見直し、という順です。大切なのは、個人情報を外へ漏らさないことだけではありません。取得する前から、利用、共有、保存、削除、事故対応までの流れを決め、必要な人だけが必要な情報を扱う状態を作ることが重要です。

獲得バッジ

文：横田和也／解決ドットコム編集部