2026年9月、NTTドコモが約34万人分の契約者データ（電話番号・料金プラン名）を、利用者の同意を得ないまま米アマゾン・ドット・コムの日本法人（アマゾンジャパン）へ提供していたことが発覚しました。

サイバー攻撃や外部流出ではなく、「申込画面の設定ミスにより同意確認画面が表示されないままデータが連携されていた」という本件。
20年以上にわたりプライバシーマーク（Pマーク）構築・運用を支援してきたコンサルタントの視点から、個人情報保護法およびPマーク基準における問題点と、企業が学ぶべき教訓を徹底解説します。

 

1. 事案の概要と特徴

 

まずは問題の構造を整理します。
▶️ 対象人数：約34万人
▶️ 対象期間：2026年4月21日〜8月20日
▶️ 提供データ：電話番号、契約料金プラン名
▶️ 提供先：アマゾンジャパン合同会社
▶️ 発生原因：対象プランのオンライン申込画面において、第三者提供への同意を確認する画面が設定ミスで表示されていなかった
▶️ 現状：提供先でのデータ利用はなく削除完了。二次被害は確認されていない。

 

本件は不正アクセスによる漏洩ではなく、「ビジネスプロセス（システム）と法的要件のズレ」によって生じた不適切な個人データの移転です。

 

2. 個人情報保護法から見た法的論点

 

個人情報保護法の観点では、以下の2点が大きなポイントとなります。

① 第三者提供の制限（第27条第1項）
事業者間のデータ連携において、それが「委託（第27条第5項第1号）」であれば同意は不要ですが、本件はAmazonプライム特典等の付与に伴う事業者間連携であり、「第三者提供」に該当します。
原則として「あらかじめ本人の同意」を得る必要がありますが、同意確認画面が出なかったため、法第27条違反（無断提供）の懸念が生じます。

② 漏えい等報告・本人通知義務（第26条）
同意を得ない不適切なデータ提供も「不適正な取扱いに伴う漏えい・提供」に該当し得ます。
規律に該当する場合、個人情報保護委員会への速やかな報告と、対象者本人への通知が義務付けられます。

 

3. Pマークの基準及びJIS Q 15001から見た3つの不適合ポイント

 

Pマークの審査・運用基準とJIS Q 15001に照らすと、以下のプロセスに欠陥があったと考えられます。

🔴本人の同意取得の欠落  

● 要求事項：個人情報を第三者に提供する場合、あらかじめ本人に利用目的や提供先を明示し、同意を得なければならない。  

● 問題点：UI（画面）の設定ミスにより、同意取得プロセス自体がスキップされた状態でデータ連携処理が完了していた。

🔴安全管理措置・変更管理の不備

● 要求事項：システム構築・改修時には、セキュリティや運用の整合性を検証・テストしなければならない。

● 問題点：画面改修時のテスト（E2Eテスト）において、「画面が表示されるか」だけでなく「同意が得られていない場合にAPI送信が遮断されるか」の検証が漏れていた可能性が高い。

🔴委託先・連携先の管理と運用監視

● 要求事項：提供・受託の運用状況を定期的に監視・点検する。

● 問題点：4月21日の開始から8月20日の発覚まで約4ヶ月間、データ連携ログと同意ログの突合・モニタリングが行われていなかった点。

 

4. なぜ起きたのか？システムとPMSの「致命的なギャップ」

 

現場でよくある失敗パターンですが、「画面（フロント）」と「データ送信（バックエンド）」が独立して動いていたことが根本原因です。

【本来の安全な設計】
[申込手続き] ➔ [同意画面表示] ➔ [ユーザー同意判定] ➔ (YES) ➔ [Amazon連携API起動]

【今回の失敗パターン】
[申込手続き] ➔ [同意画面（非表示バグ）] ➔ [裏でデータ送信プログラムが自動実行]

 

「画面に表示させているから同意を取れているはず」という前提でバックエンドの送信プログラムを組んでしまい、画面が表示されなかった際のアボート（停止）処理や、「同意フラグ＝TRUE」を確認してから送信するガードレールがシステム側になかったことが原因と推察されます。

 

5. 企業が今すぐ実施すべき「3つの再発防止アクション」

 

今回の事例を「他山の石」とし、自社のPマーク運用・システム運用を見直すための実務アクションです。

１．「同意フラグ」と「送信ロジック」の完全連動
画面の表示・非表示に関わらず、データベース上に「本人の同意ログ（タイムスタンプ・同意フラグ）」が存在しない限り、外部APIやデータ抽出処理が動作しないシステム仕様に変更する。
２．システム変更時のE2E（エンドツーエンド）テストの徹底
画面改修や新プラン追加の際、「正常系（同意して進む）」だけでなく、「異常系（画面が出ない／同意しない）」の時にデータが送信されないかを自動テスト項目に組み込む。
３．「同意件数」と「データ連携件数」の自動突合（モニタリング）
日次または週次で、「取得した同意ログの数」と「外部へ送信したデータ件数」が一致しているかを監視する仕組みを導入する。 差異があれば即座にアラートが飛ぶ体制を作る。

 

ヒューマンエラーやシステム設定ミスは完全にゼロにはできません。
だからこそ、ミスが起きても権利侵害へ発展させない「二重三重の安全制御」を組み込むことが、Pマーク運用の真髄です。

 

 

自社のWebシステムに「同意なしでデータが流れ出る抜け道」がないか、今すぐ点検を行いましょう。