ホーム > 楽天店舗・RMS
楽天ソーシャルギフトの個人情報漏えい防止|店舗の確認事項

楽天ソーシャルギフトでは、通常注文と同じ帳票・メール・出荷処理を無条件に使ってはいけません。注文を機能対象として識別し、贈り主と受取人のそれぞれについて、誰に何の情報を見せてよいかをデータ項目単位で決めます。送り状、納品書、同梱物、通知、倉庫、外部システム、問い合わせを一連でテストします。
この記事では、注文識別、情報分離、帳票、メール、OMS・WMS、委託先、問い合わせ、本番前テスト、漏えい疑義時の初動を解説します。具体的な開示可能項目は推測せず、現行のソーシャルギフトガイドラインで確認してください。
ソーシャルギフトは互いの情報を知らずに贈れる仕組み
ソーシャルギフト機能は、贈り主と受取人が互いの個人情報を知らずにギフトを贈れる仕組みです。機能を利用する店舗には、個人情報の取り扱いに関する所定の条件が課される場合があります。条件には、個人情報に関するルール、漏えいの概要、原因、防止策の理解が含まれます。利用店舗は本記事だけで代替せず、現行のガイドラインと注意事項を必ず確認してください。
この機能の価値は情報の分離にあります。通常注文で問題がない帳票やメールでも、ソーシャルギフトでは相手方の情報を誤って開示する可能性があります。
最初に現行ルールと責任者を確認する
開始・継続前に、次を確認します。
- 利用条件・注意事項の確認状況
- ソーシャルギフトの現行ガイドライン
- 対応商品・店舗・サービス
- RMS上の注文識別方法
- 贈り主・受取人へ開示可能な項目
- 送り状・納品書・同梱物の条件
- メール・問い合わせの回答範囲
- 外部サービス・倉庫の対応条件
- 事故時の楽天窓口
個人情報責任者、受注責任者、倉庫責任者、システム責任者、事故対応責任者を決めます。
通常注文とソーシャルギフトを識別する
受注時に、ソーシャルギフトかどうかを担当者が見落とさない表示・フラグを確認します。現行RMSの項目名・値は公式案内で確認してください。
識別情報を、必要な範囲で後続工程へ引き継ぎます。
| 工程 | 識別に使う情報 | 完了条件 |
|---|---|---|
| 受注 | RMSの対象表示・注文種別 | 対象注文として登録 |
| OMS | 連携項目・フラグ | 通常注文と分離 |
| 倉庫 | 出荷指示・作業区分 | 専用帳票・梱包を適用 |
| 通知 | テンプレート区分 | 相手別に許可情報だけ表示 |
| 問合せ | 注文種別と本人区分 | 回答範囲を判定 |
フラグが外部システムへ渡らない場合、通常テンプレートを自動適用せず、手動確認・専用キュー等の安全策を設けます。
情報項目ごとに開示マトリクスを作る

「個人情報を出さない」という抽象ルールだけでは運用できません。贈り主、受取人、店舗、倉庫、配送会社が、どの情報を、どの目的で見られるかを項目単位で整理します。
| 情報項目 | 贈り主向け | 受取人向け | 店舗内部 | 倉庫・配送 | 根拠・条件 |
|---|---|---|---|---|---|
| 氏名 | 現行ガイドで確認 | 現行ガイドで確認 | 業務に必要な範囲 | 配送に必要な範囲 | |
| 住所 | |||||
| 電話・メール | |||||
| 注文・商品 | |||||
| メッセージ |
表の中身は、担当者の推測で埋めません。現行ガイドライン、RMS・問い合わせ回答を根拠にし、確認日と版を残します。
送り状を専用条件で確認する
送り状は配送に必要な情報を外部へ表示するため、誤開示が起きやすい場所です。
確認します。
- 依頼主・届け先欄へ誰の何が印字されるか
- 電話番号・住所・氏名の出力元
- 品名・記事欄・備考へ不要情報が入らないか
- 配送会社API・送り状ソフトの項目対応
- 再印刷・手書き修正時のルール
- 返品・転送・持戻り時の表示
- ラベル控え・廃棄・保管
通常注文用CSVの列対応を使い回さず、本番相当のテストラベルを実際に印刷して確認します。
納品書・領収書・同梱物を分ける
通常注文の納品書には、注文者氏名、住所、金額、ポイント、決済、購入履歴等が含まれる場合があります。ソーシャルギフトの荷物へ自動同梱すると、贈り主情報を受取人へ見せる可能性があります。
対象帳票を棚卸しします。
- 納品書・明細書
- 領収書・請求関連
- 注文確認・ピッキングリスト
- ギフトメッセージ
- 店舗カード・挨拶状
- 返品票・保証書
- クーポン・会員案内
- 外部サービスのチラシ
各帳票の表示項目、同梱先、必要性、テンプレート、印刷元を確認します。「金額を消したから安全」とせず、氏名・住所・連絡先等も見ます。
メール・通知の宛先と本文を確認する
注文受付、受取手続、発送、到着、キャンセル、問い合わせ等、機能に関係する通知を一覧化します。
| 通知 | 宛先 | 表示項目 | 送信条件 | テンプレート |
|---|---|---|---|---|
| 受付 | 現行仕様確認 | |||
| 受取関連 | ||||
| 発送 | ||||
| 取消・返金 |
贈り主向けメールに受取人情報、受取人向けメールに贈り主の非開示情報を差し込まないよう、変数とテンプレートを確認します。
手動メールでは、過去の通常注文テンプレート、転送履歴、署名、添付ファイルにも注意します。
OMS・WMS・CSV・APIの項目対応を監査する
RMSでは情報が分離されていても、外部システムへのCSV・API連携で、項目名や注文者・送付先の割当が変わる可能性があります。
連携台帳に残します。
- RMSの元項目
- 連携先の項目
- 利用目的
- 表示・出力先
- マスキング・除外
- 保持期間
- 再連携・エラー時の処理
- 仕様変更時の責任者
サンプル一件だけでなく、通常注文、ソーシャルギフト、複数商品、キャンセル、再送等のケースを比較します。
倉庫・委託先の作業を実地確認する
システム仕様書が正しくても、倉庫が通常注文と同じ帳票を再印刷したり、担当者が注文画面を見て手書きしたりすると漏えいします。
確認事項です。
- 専用キュー・作業区分が分かる
- ピッキング・検品・梱包で必要項目だけを表示する
- 送り状・納品書を対象テンプレートで出力する
- 手書き・再印刷・差し替えを二者確認する
- 不要な帳票を同梱しない
- 廃棄・控え・画面表示を管理する
- 誤出力・誤同梱時に即停止・報告する
再委託先や配送会社を含め、契約・教育・事故報告・削除を確認します。
問い合わせ時の本人区分と回答範囲を決める
電話・メール・チャットで、相手が贈り主か受取人かを確認し、本人確認と回答可能範囲を分けます。
問い合わせ例です。
- 贈り主から受取人の住所・受取状況を聞かれた
- 受取人から贈り主の住所・連絡先を聞かれた
- 配送会社から追加情報を求められた
- 家族・代理人から注文内容を聞かれた
- 返品・交換・再送で住所確認が必要になった
「注文番号を知っているから」だけで開示せず、現行ガイドラインの本人確認・回答範囲を使います。判断できない場合は責任者・楽天窓口へ上げます。
返品・再送・住所変更を例外処理にする
通常配送の例外は、情報分離を崩しやすい場面です。
- 受取期限切れ
- 住所不備・転送
- 配送事故・破損
- 返品・交換
- 再送・代替品
- キャンセル・返金
注文種別、誰の同意が必要か、どの住所を使えるか、誰へ何を通知するか、帳票をどう出すかを現行ルールで確認します。担当者が電話で得た住所を通常注文欄へ安易に上書きしません。
本番相当のテストケースを作る

最低限のケースです。
- 正常なソーシャルギフト
- 通常注文との同時処理
- 複数商品・複数SKU
- 受取手続の期限・未完了
- 住所不備・配送持戻り
- キャンセル・返金
- 破損・再送
- 贈り主・受取人双方からの問い合わせ
テスト注文の作り方は楽天の現行ルールを確認します。個人の実住所を安易に使わず、許可されたテストデータを用います。
画面・通知・現物を両側から確認する
テストでは、管理画面だけでなく、実際に届くものを確認します。
| 視点 | 確認対象 |
|---|---|
| 贈り主 | 画面、メール、注文履歴、問い合わせ回答 |
| 受取人 | 受取画面、メール、荷物、同梱物 |
| 店舗 | RMS、OMS、問い合わせ、返金 |
| 倉庫 | 指示、ピッキング、帳票、送り状 |
| 配送 | ラベル、通知、持戻り・転送 |
各画面をスクリーンショット、各帳票をPDF・写真で保存し、開示マトリクスと照合します。
変更時に回帰テストする
次の変更後は再テストします。
- RMS・ソーシャルギフト仕様
- OMS・WMS・配送API
- 送り状・納品書テンプレート
- 倉庫・配送会社・委託先
- メール・問い合わせツール
- 商品・ギフト包装・同梱物
- 返品・再送・キャンセル手順
変更申請に「ソーシャルギフト影響」を追加し、通常注文テストだけで本番反映しません。
漏えい疑義時の初動
誤った帳票・メール・荷物・回答で相手方情報を開示した可能性があれば、完全な調査結果を待たず初動します。
- 同じテンプレート・連携・出荷・通知を停止する
- ログ、メール、帳票、画面、荷物情報を保全する
- 個人情報責任者・経営・楽天の現行窓口へ連絡する
- 対象注文、相手、項目、件数、期間、取得者を特定する
- 回収・アクセス停止等の影響抑制を行う
- 法令上の報告・本人通知の要否を確認する
- 顧客対応を承認済み文面で行う
- 原因、再発防止、再開条件を記録する
誤送信取消、帳票回収依頼だけで漏えいなしと断定しません。閲覧・保存・転送の可能性を確認します。
個人情報事故全般は「楽天店舗の個人情報漏えい防止」も参照してください。
教育と権限を定期確認する
現行ガイドラインの確認だけで終わらず、自店舗のシステム・帳票・委託先へ落とした手順を教育します。
- 注文種別の識別
- 開示マトリクス
- 送り状・帳票・メール
- 問い合わせの回答範囲
- 例外処理
- 事故時の停止・報告
新人、繁忙期応援、外部倉庫、システム担当も対象です。権限は必要最小限にし、RMS・OMS・ファイル・メールの利用者を月次等で棚卸しします。
ソーシャルギフト個人情報チェックリスト
- 現行ガイドを確認した
- 通常注文とソーシャルギフトを識別できる
- 情報項目ごとの開示マトリクスを作った
- 送り状・納品書・同梱物を専用確認した
- 贈り主・受取人向け通知を分けた
- OMS・WMS・CSV・APIの項目を監査した
- 倉庫・委託先の実作業を確認した
- 問い合わせ・返品・再送の例外を決めた
- 両側の画面・通知・現物をテストした
- 漏えい疑義時の停止・保全・連絡を決めた
よくある質問
通常注文の納品書を金額だけ消して使えますか?
金額以外に氏名、住所、連絡先、注文情報等が含まれる可能性があります。現行ガイドで表示可能項目を確認し、専用テンプレートを本番相当テストしてください。
贈り主から受取人の住所を聞かれたら答えられますか?
自己判断で開示せず、現行ガイドラインの本人確認・回答範囲に従います。不明な場合は個人情報責任者と楽天の窓口へ確認してください。
外部倉庫を使っていても店舗で確認が必要ですか?
必要です。連携項目、帳票、再印刷、同梱、再委託、事故報告を店舗が確認し、本番相当テストを行います。委託で店舗側の統制が不要になるわけではありません。
情報漏えいの可能性を見つけたら何をしますか?
同じ出荷・通知・連携を止め、証拠を保全し、対象注文・項目・件数・期間を特定しながら、社内責任者と楽天の現行窓口へ直ちに連絡します。
店舗の「次の一手」を一緒に進めるなら
運営代行・ECコンサル・AIツールまで、現場を知るチームがワンストップで伴走します。
西尾 勝太株式会社ラクダ 代表
楽天SOY 2年連続受賞 / 楽天NATIONSリーダー店舗 / 楽天NATIONS AIエバンジェリスト
楽天市場の月商を5年で200万円→2億円に伸ばした現場の実践者。売れるECの方程式にAIを重ね、EC事業者の「次の一手」に伴走しています。



