はじめに
NTTドコモが、オンライン手続きサイト「ドコモオンラインショップ」と「My docomo」への不正アクセスにより、お客さま情報が流出したと公表しました。2026年11月5日の発表以降、11月6日、11月9日と続報が出ており、流出対象は最大約30万件。氏名や住所に加えて、全員分の「本人確認書類の番号」が含まれていたことが大きく報じられています。
今回の件で発注側の担当者に考えてほしいのは、2つの点です。1つは、報道によれば攻撃者が「システムの不具合」ではなく、複数のシステムが連動する正規の仕組みを悪用して情報を取得したとみられること。もう1つは、契約手続きのために預かった本人確認書類の番号や口座情報が、Webから到達できる範囲に残っていたことです。
この記事では、発注側を支援するコンサルタントの立場から、自社の会員サイトや手続きサイトで同じことを起こさないための仕組みとルールを考えます。
何が起きたのか
ドコモの公式のお知らせ（第2報：11月5日、第3報：11月6日、第4報：11月9日）と報道をもとに整理します。
- 発覚：2026年11月4日、ドコモオンラインショップとMy docomoへの外部からの不正アクセスを確認。11月5日午前1時5分頃から両サイトの各種手続きを停止
- 件数：対象は最大約30万件（報道では最大29万4,839回線、うち個人約20万4千件・法人約9万1千件）。あくまで上限の数字で、流出した範囲・件数は引き続き調査中とされています
- 流出した情報：すべての対象者について、氏名・生年月日・住所・連絡先・メールアドレス・本人確認書類の番号・携帯電話番号・契約内容など。一部の対象者については、勤務先や法人の名称・所在地、金融機関名・口座番号・口座名義なども含まれます。解約した利用者も対象です
- 含まれないとされる情報：報道によれば、マイナンバーは番号も画像も保存しておらず対象外。クレジットカード番号はマスキングされていたため流出していないとされています
- 原因：公式には「外部からの不正アクセス」で、侵入経路や流出範囲は調査中。会見の報道では、攻撃者が複数のシステムが連動する仕組みを悪用して利用者情報を機械的に検索・取得したとみられ、ドコモは定期的に脆弱性診断を実施していたものの、この攻撃経路は事前に特定できていなかったと説明しています
- 対応：11月9日午後からMy docomoの大部分の手続きを再開。ドコモオンラインショップは停止が続いています。見舞金の支払いを検討していると報じられています
また報道によると、11月4日朝から少量の探りとみられるアクセスがあり、日中に大量アクセスのアラート、夕方に経路を遮断して一度サービスを再開したものの、夜に再び不正アクセスの可能性を検知し、翌未明の全面停止に至ったとされています。
なぜこうしたことが起きるのか
「脆弱性がない」ことと「悪用できない」ことは別
一般的な脆弱性診断は、SQLインジェクションや認証の不備のように「作りの誤り」を探すものです。ところが、正規の機能を正規の手順で大量に呼び出されると、一つひとつのリクエストは正常に見えてしまいます。照会機能やシステム間の連携機能は、業務上は必要なものなので、作った側も「ここから情報が抜かれる」とは想定しにくいのです。
預かったデータは「業務の都合」で増え続ける
本人確認書類の番号は、契約時の確認や不正契約の調査で必要になることがあります。ただ、多くの組織では「いつまで」「どのシステムに」持つかが決められないまま、オンラインで参照できる場所に残り続けます。解約者のデータが残るのも同じ構造で、消す判断をする人がいないためです。
監視は「検知」までで、「止める判断」が決まっていない
アラートが鳴っても、売上や顧客対応への影響を考えると、サイト全体を止める判断は簡単ではありません。止める基準と権限が事前に決まっていないと、部分的な対処を重ねるうちに時間が過ぎていきます。
発注側コンサルとして考える、仕組みで防ぐための5つの手当て
ここからは、ニュースで報じられた対策の繰り返しではなく、発注側の立場で「自社で何を決めておくか」を整理します。
1. データの持ち方を「保有目的と期限」で棚卸しする
まず、会員・顧客データの項目ごとに「何のために持つか」「いつまで持つか」「Webから参照できる必要があるか」を一覧にします。特に本人確認書類の番号、口座情報、勤務先のような項目は、
- 確認が終わったら番号は残さず「確認済み」の記録だけにできないか
- 残す場合も、オンラインの業務系ではなく、アクセス経路を絞った別の領域に置けないか
- 解約後は何年で削除するか、誰がその削除を実行するか
を決めます。「持っていなければ漏れない」は、どんな技術対策よりも確実です。
2. 「機能の悪用」を前提にした要件を書く
要件定義やRFPには、機能要件だけでなく「この機能が悪用されたら何件まで取れてしまうか」という観点を入れます。具体的には、
- 1つのアカウント・1つの接続元あたりの照会回数や取得件数の上限
- システム間連携のAPIが、呼び出し元の正当性と照会範囲を確認しているか
- 通常と異なる大量照会を検知したら自動で遮断・減速する仕組み
を非機能要件として明記します。セキュリティ要件の書き方は、基幹システム刷新で見落としやすいセキュリティ要件の記事でも整理しています。
3. 診断の範囲に「業務ロジックの悪用」を含める
ベンダーに脆弱性診断を依頼するとき、Webアプリの定型診断だけで終わらせず、「正規ユーザーとして何ができてしまうか」を試すシナリオ型の診断を年に1回は入れます。発注側からは、重要データにつながる画面とAPIの一覧を渡し、「この経路で他人の情報が見えないか」「大量に取得できないか」を検証対象として指定するのがポイントです。
4. 「止める基準」と「再開の条件」を先に決める
インシデント対応の手順書に、次の3点を書いておきます。
- どの兆候が出たら、どの範囲（機能単位・サイト全体）を止めるか
- 止める判断を誰が、夜間・休日でも下せるか（担当役員の代行者まで）
- 再開するときの条件（経路の特定・対策・再発監視の体制）
今回の報道でも、一度再開した後に再び不審なアクセスが検知されています。再開の条件を事前に決めておくことは、判断を急ぐ現場を守ることにもなります。
5. 委託先との契約で「データ削除」と「ログ」を義務化する
手続きサイトの開発・運用を外部に委託している場合は、契約や仕様書に、データの保持期限と削除の実施報告、照会ログの保存期間、異常検知時の連絡時間を入れておきます。何も書かなければ、委託先は「消さない」「ログは最小限」を選びがちです。契約時点で書いておけば、追加費用の交渉ではなく「仕様どおりの対応」として求められます。
まとめ
- ドコモは、オンラインショップとMy docomoへの不正アクセスで、最大約30万件の顧客情報が流出したと公表。全員分の本人確認書類の番号が含まれ、一部は口座情報や勤務先も対象
- 報道によれば、正規の仕組みを悪用して機械的に情報を取得したとみられ、定期的な脆弱性診断では経路を特定できていなかった
- 発注側としては、①データの保有目的と期限の棚卸し、②悪用を前提にした要件、③業務ロジックを含む診断、④止める基準と再開条件、⑤委託契約での削除とログの義務化、の5点を自社で決めておきたい
侵入経路や流出範囲はまだ調査中のため、今後の続報で事実関係が変わる可能性があります。自社では「何を持っているか」の棚卸しから始めてみてください。
参考
- NTTドコモ「【お詫び】ドコモオンラインショップ、My docomoの緊急メンテナンス実施について（第2報）」（2026年11月5日）
- NTTドコモ「同（第3報）当社サーバーへの不正アクセスによるお客さま情報流出に関するお知らせ」（2026年11月6日）
- NTTドコモ「同（第4報）」（2026年11月9日）
- 日本経済新聞「ドコモの顧客情報流出、本人確認書類の番号も 見舞金の支払い検討」（2026年11月6日）
- 日本経済新聞「ドコモ、オンライン手続きを一部再開 通販サイトは停止を継続」（2026年11月9日）
- ITmedia NEWS「ドコモ不正アクセスで「本人確認書類の番号」も流出 見舞金検討」（2026年11月9日）
- サイバーセキュリティ.com「NTTドコモがオンラインショップ等への不正アクセスで最大29万4,839件の情報流出を公表」（2026年11月7日）
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント