日本経済新聞社で約183万件の個人情報漏えい｜開発用クラウドに不正アクセス
日本経済新聞社は2026年10月16日、システム開発に利用しているクラウドサービスが第三者から不正アクセスを受け、約183万件の個人情報が漏えいしたと発表しました。
不正アクセスは10月7日未明から朝にかけて発生しました。
クラウドサービスへアクセスするための認証情報が何らかの手段で窃取され、その認証情報を利用してクラウド上へ不正アクセスされたとしています。
日本経済新聞社は、不正アクセスに使用された認証情報をすでに無効化しています。
日本経済新聞「日経、個人情報183万件漏洩 不正アクセスで」
日経183万件の情報漏えい、何が漏れた？実質的な個人情報は約15万件
「183万件」という数字だけを見ると非常に大きな情報漏えいに見えますが、内容は大きく2種類に分かれます。
| 情報の種類 | 件数 | 内容 |
|---|---|---|
| 個人情報 | 約15万件 | 氏名、メールアドレス、住所、電話番号、生年月日のいずれか |
| 識別子のみ | 約168万件 | 単体では個人を特定できない識別子 |
約15万件のうち、メールアドレスが含まれているものは約12万件です。
したがって今回の事案は、
「183万人分の氏名・住所などがすべて漏えいした」という意味ではありません。
この点は数字を見るうえで注意が必要です。
自分は日経183万件の情報漏えい対象？確認する方法は
日本経済新聞社は、漏えいが確認された個人情報の対象者には個別に通知するとしています。
2026年10月16日時点では、メールアドレスなどを入力して自分が対象か確認できる専用検索ページは公表されていません。
そのため現時点では、
- 日本経済新聞社からの個別連絡を確認する
- 登録しているメールアドレスの受信箱・迷惑メールフォルダを確認する
- 日本経済新聞社の公式サイトで続報を確認する
という対応になります。
なお、今回の発表だけでは「日経電子版を利用している人全員が対象」とは確認できません。
対象範囲については現在も精査が続いているため、公式発表以上に広げて考えないことが重要です。
日経の情報漏えいで補償はある？
2026年10月16日時点では、金銭補償、ポイント付与、お詫びの品などに関する発表は確認されていません。
また、日本経済新聞社によると、現時点では今回漏えいした個人情報が悪用された二次被害や、システム停止、データ改ざんなどの異常も確認されていません。
日本経済新聞社は10月11日に個人情報保護委員会へ報告しており、現在も侵害範囲や漏えいした個人情報を精査しています。
なぜ日経で183万件の情報漏えいが起きた？認証情報の窃取がポイント
今回、企業のDX・セキュリティ担当者が特に注目すべきなのが、不正アクセスの入口です。
日経の説明では、
クラウドサービスへアクセスするための「認証情報」が何らかの方法で窃取された
とされています。
つまり現時点では、クラウドサービスそのものが破られたと発表されているわけではありません。
何らかの方法で正規の認証情報を入手した第三者が、その情報を使ってクラウドへアクセスした構図です。
ただし、
- パスワードが盗まれたのか
- APIキーなどの認証情報だったのか
- アクセストークンなどが窃取されたのか
- 端末や開発環境が侵害されたのか
といった具体的な手法は現時点で公表されていません。
そのため、原因を特定の手口に断定することはできません。
「開発環境だから大丈夫」ではない｜DX担当者が日経の事案から学ぶこと
今回もう一つ重要なのが、不正アクセスされたのが「システム開発に利用していたクラウドサービス」だったという点です。
企業のセキュリティというと、本番システムや顧客向けサービスへ目が向きがちです。
しかし実際には、
- 開発環境
- テスト環境
- Gitリポジトリ
- CI/CD
- クラウド管理コンソール
- APIキー・シークレット
などにも重要なデータや本番環境へつながる認証情報が存在します。
DXが進むほど、「本番環境以外」のクラウドや開発ツールも企業の重要インフラになります。
DX・セキュリティ担当者が確認すべき5つの対策
1．認証情報を人や端末へ置きっぱなしにしない
クラウドのAPIキー、シークレット、サービスアカウントなどをソースコード、PC、共有フォルダなどへ直接保存すると、侵害時のリスクが大きくなります。
Secrets Managerなど専用の秘密情報管理機能を利用し、認証情報を集中管理することが重要です。
2．長期間有効な認証情報を減らす
一度盗まれた認証情報が長期間利用できれば、攻撃者がアクセスできる時間も長くなります。
短期間で失効する認証、定期的なローテーション、不要なキーの削除などを徹底する必要があります。
3．「誰がログインしたか」だけでなく「何を取得したか」を監視する
正規の認証情報を盗まれた場合、ログインそのものは正常なアクセスに見える可能性があります。
そのため、
- 通常とは異なる地域からのアクセス
- 大量データ取得
- 深夜帯のアクセス
- 普段利用しないAPI
- 異常な権限変更
など、ログイン後の挙動まで監視する必要があります。
4．開発環境にも「最小権限」を適用する
開発者だからといって、本番データやすべてのクラウドリソースへアクセスできる必要はありません。
「この認証情報が盗まれたとしても、どこまでしかアクセスできないか」 という視点で権限を設計することが重要です。
5．開発環境に本番個人情報を置く必要があるか見直す
テストやシステム開発で実データを利用すると、開発環境が侵害された場合にも個人情報漏えいにつながります。
可能であれば、
- ダミーデータ
- 匿名化データ
- マスキング済みデータ
を利用し、開発環境が持つ個人情報そのものを減らすことも重要です。
まとめ｜日経183万件漏えいが示す「クラウド認証情報」の重要性
今回、日本経済新聞社ではシステム開発用のクラウドサービスが不正アクセスを受け、約183万件の情報が漏えいしました。
そのうち、氏名・メールアドレス・住所・電話番号・生年月日のいずれかを含む情報が約15万件、単体では個人を特定できない識別子が約168万件です。
現時点では二次被害やシステム停止、データ改ざんなどは確認されていません。
一方、今回の事案で特に重要なのは、
クラウドサービスへアクセスするための「認証情報」が窃取されたことで、大規模な情報漏えいにつながった
という点です。
DX担当者にとって、クラウド導入はゴールではありません。
「認証情報が盗まれたとしても、被害をどこまで小さくできるか」まで設計することが、クラウド時代のセキュリティでは重要です。
参考情報・出典
※本記事は2026年10月16日時点の日本経済新聞社の公表内容をもとに作成しています。具体的な認証情報の種類、窃取方法、対象者の詳細、補償などについては今後追加情報が公表される可能性があります。