日本経済新聞社の開発用クラウドから、183万件の個人情報はなぜ漏れたのか

1はじめに

2026年10月16日、株式会社日本経済新聞社は、システム開発に利用するクラウドサービスが不正アクセスを受け、同日時点で約183万件の個人情報が漏えいしたと発表しました。クラウドサービスにアクセスするための認証情報が何らかの手段で窃取され、10月7日の未明から朝にかけて不正アクセスを受けたといいます。日経は不正アクセスに使われた認証情報を無効にしました。

10月21日には、日経BPが、このうち約80万件が自社のサービスの利用者の情報だったと発表しました。テレビ東京とBSテレビ東京も、自社のサービスの利用者の情報が含まれている可能性があると公表しています。

KEYRINGでは、この事案を速報「株式会社日本経済新聞社、開発用クラウドの認証情報が盗まれ個人情報約183万件が漏えい」で取り上げました。このレポートでは、日経と日経BPの発表、テレビ東京の発表、個人情報保護委員会やJPCERT/CCの資料、報道をもとに、次の問いに答えます。

• 何が、いつ、どの順番で起きたのか
• 何が、どこまで漏れたのか。どの会社の利用者に及んだのか
• 「認証情報の窃取」とは何で、何が公表されていないのか
• 日経で続いた不正ログインと、同じ手口の過去の事故から何が分かるか
• 企業は認証情報をどう管理すればよいのか

2不正アクセスから公表、続報までの経緯

不正アクセスは10月7日の未明から朝にかけて起き、日経は4日後の11日に個人情報保護委員会へ報告しました。公表は16日です。日経が不正アクセスにいつ気づいたかは公表されていません。公表の当日から、グループ各社の発表が続きました。

10月26日時点で、日経から10月16日の発表に続く第2報は出ていません。16日の発表は「被害状況の把握や原因究明を急ぐ」としており、原因の詳細は調査中です。

3何が、どこまで漏れたのか

約183万件のうち、氏名などの個人を特定しやすい情報を含むのは約15万件です。残る約168万件は「単体では個人を特定できない識別子のみ」とされています。

日経は「識別子」が具体的に何かを説明していません。一般に、会員番号や、サービスの内部で利用者を区別するための番号を指します。単体では個人を特定できなくても、同じ識別子を使う別のデータと突き合わせると、個人に結びつく場合があります。日経は、識別子のみの約168万件を個人情報として数えた理由を説明していません。

件数は「16日時点」のもので、日経は侵害を受けた範囲や漏えいした個人情報を精査しているとしています。今後の発表で件数が変わる可能性があります。

4グループ各社の利用者への影響

日経BPは、自社のサービスの利用者の情報が含まれていたと発表しました。テレビ東京・BSテレビ東京と日経HRも、自社の利用者の情報が含まれる可能性があると発表しています（日経HRは報道による）。

日経BPの発表は、日経が16日に発表した漏えいに、日経BPの利用者の情報が約80万件「含まれている」としています。テレビ東京は、問い合わせを日経の専用窓口に一本化し、「正確かつ一貫したご案内を行うため」と説明しています。一般に、グループで共通の基盤を使う場合は、漏えいしたときの窓口と通知の流れも、グループで1本にまとめておく必要があります。

5認証情報があれば、クラウドには入れる

日経の発表の中心は「クラウドサービスにアクセスするための認証情報が何らかの手段で窃取された」という一文です。認証情報は、クラウドに「この利用者は正規の利用者だ」と示すための鍵です。鍵が本物であれば、クラウドの側からは、正規の利用者と第三者を見分けにくくなります。

クラウドサービスで使われる認証情報には、大きく分けて、人がログインするときに使うもの（IDとパスワード、多要素認証のコードなど）と、プログラムがクラウドの機能を呼び出すときに使うもの（アクセスキー、APIキー、トークンなど）があります。日経はどちらが盗まれたかを公表していません。

この形の攻撃では、ソフトウェアの脆弱性がなくても侵入が成り立ちます。守る側にとっての論点は、鍵を盗まれないこと、盗まれても鍵だけでは入れないこと、入られてもすぐ気づいて鍵を止められること、の3つです。日経は鍵を無効にしたと発表していますが、いつ無効にしたか、不正アクセスにどう気づいたかは明らかにしていません。

開発用の環境と個人情報

漏えいしたのは「システム開発に利用するクラウドサービス」の上に保管されていた個人情報です。日経は、開発用のクラウドに利用者の個人情報を置いていた理由や、それが本番のデータの写しなのかどうかを公表していません。日経の開発環境の設定や運用についても公表されていません。個人情報保護委員会は10月7日の注意喚起で、不要になった個人データの消去を改めて求めています。

6分かっていること、分かっていないこと

10月26日時点で、日経の発表は10月16日の1本と、問い合わせフォームに関するお知らせです。原因の中心にあたる部分は、まだ公表されていません。

どの種類の認証情報が、どの経路で盗まれたかによって、再発を防ぐ対策は大きく変わります。社員のパソコンがウイルスに感染して保存されたパスワードが盗まれたのか、ソースコードや設定ファイルにアクセスキーが書かれていたのか、別のサービスの侵害で鍵が漏れたのか。どれも過去に例がある経路ですが、日経の事案がどれに当たるかは分かりません。

7同じ手口の過去の事故

盗まれた、あるいは漏れた認証情報が原因となった事案は、国内外で繰り返し起きています。公表された原因がはっきりしている2つの例を並べます。

トヨタの例は、プログラムが使う鍵（アクセスキー）がソースコードと一緒に外に出た例です。鍵は約4年9か月にわたって公開された状態でした。Snowflakeの例は、人が使うIDとパスワードが端末から盗まれ、多要素認証がないまま何年も使える状態にあった例です。どちらも、鍵が漏れたこと自体より、漏れた鍵が長く有効なままで、鍵だけで入れる状態だったことが問題でした。トヨタの件では、第三者のアクセスは確認されていません（否定もできないとしています）。

8認証情報をどう守るか

日経がどの認証情報を盗まれたかは公表されていないため、ここでは、クラウドを使う企業が一般に確かめるべき点を、人のログインとプログラムの鍵に分けて整理します。根拠には、クラウド事業者の公式文書と、国内の公的機関の注意喚起を使います。

人のログイン：多要素認証と、フィッシングに強い方式

パスワードだけで入れるアカウントは、パスワードが漏れた時点で守れなくなります。Snowflakeの例では、侵害されたアカウントに多要素認証が設定されていませんでした。AWSは、IAMのベストプラクティスで、人の利用者にはフェデレーション（社内の認証基盤との連携）を通じた一時的な認証情報を使わせること、多要素認証を求めることを挙げています。

多要素認証にも強さの差があります。ワンタイムパスワードは、偽のサイトに入力させてその場で使う手口（リアルタイムフィッシング）で破られることがあります。パスキーは、端末の中の秘密鍵で署名する方式で、鍵はサイトのドメインに結びつくため、偽のサイトでは使えません。サーバーの側に盗まれて困る秘密を置かない点も特徴です。個人情報保護委員会の10月7日の注意喚起は、組織の外からのアクセスや管理者の権限でのアクセスに、フィッシングに強いものを含む多要素認証を入れる例を示しました。

ただし、パスキーを設定していても侵入された例があります。10月7日に報じられたネット広告会社の事案では、侵入の起点となったGoogleのアカウントに、複雑なパスワードに加えてパスキーとセキュリティキーによる2段階認証を設定していましたが、入られました。具体的な侵入経路や認証を突破された経緯は特定できていないとされています。ログインの方式を強くするだけでなく、端末の管理と、ログイン後の不審な操作の検知を組み合わせる必要があります。

プログラムの鍵：書かない、長く持たない、すぐ止められる

アクセスキーやAPIキー、トークンは、プログラムが人の代わりにクラウドを操作するための鍵です。人のログインと違って多要素認証をかけにくいため、鍵そのものの扱いが防御の中心になります。

開発の環境：本番の個人情報を持ち込まない

認証情報を守っても、鍵が漏れたときに届く先に個人情報がなければ、漏えいは起きません。開発や試験に本番のデータが必要な場合は、氏名やメールアドレスを置き換えたデータを使う、必要な期間が過ぎたら消す、といった運用が考えられます。個人情報保護委員会は10月7日の注意喚起で、不要になった個人データの消去を求め、クラウド上のデータを消すときは事業者が用意する方法や暗号化消去など、容易に復元できない手段をとる例を示しています。

9日経がこれまでに公表した不正ログイン

日経は、2025年11月から2026年10月までの約1年で、本件を含めて5件の不正ログインや不正アクセスを公表しています。いずれも、正規のアカウントや認証情報が第三者に使われた事案です。それぞれの関係は公表されていません。

2025年11月のSlackの件では、日経は原因を具体的に公表しました。社員が個人で持つパソコンがウイルスに感染し、そこからSlackの認証情報が流出した、という経路です。業務用のサービスの認証情報が、会社の管理の外にある端末に残ると、会社は感染に気づけません。

その後の4件では、侵入の経路は公表されていません。10月4日の2件は、いずれも第三者が正規のアカウントにログインした事案で、日経はパスワードを変更したと発表しています。

10法律が求める報告と、国の注意喚起

個人情報保護法は、不正アクセスなど不正の目的をもって行われたおそれがある漏えいや、本人の数が1,000人を超える漏えいが起きたとき、事業者に個人情報保護委員会への報告を義務づけています。報告は、発覚から速やかに（概ね3〜5日以内）出す速報と、30日以内（不正の目的のおそれがある場合は60日以内）の確報の2段階です。

日経は不正アクセスから4日後の10月11日に報告しています。報告の期限は「発覚日」から数えますが、日経が不正アクセスに気づいた日は公表されていません。

報道機関の個人情報と、報告の義務

個人情報保護法には、報道機関が報道の目的で取り扱う個人情報について、義務の適用を除く規定があります。日経自身、2025年11月のSlackの件の発表で「報道・著述目的の個人情報は漏洩時の報告義務などの個人情報保護法の適用を受けません」と書いたうえで、事案の重要性と透明性を考え、任意で報告したと説明しました。今回漏えいしたのは、日経やグループ各社のサービスの利用者の情報です。日経は今回の報告が義務によるものか任意かを書いていませんが、10月11日に報告したことは明記しています。

10月に相次いだ国の注意喚起

個人情報保護委員会は10月7日、相次ぐ漏えいを受けて「大規模な漏えい等事案を踏まえた対応について（注意喚起）」を公表しました。報道によると、2027年4月に見直す予定のガイドラインから対策例を先取りし、認証では、組織外のネットワークからのアクセス、管理者の権限でのアクセス、重要な個人データへのアクセスに、フィッシングに強いものを含む多要素認証を入れる例を示しました。アクセスのたびに場所や時間、端末の状態を評価して可否を決める仕組みや、許可した端末からだけ個人データに入れるようにする方法も挙げています。

10月8日にはJPCERT/CCが注意喚起を公開し、内閣官房国家サイバー統括室、総務省、IPAも注意喚起を出しました。総務省は、迅速な脆弱性対応、多要素認証などの認証の強化、漏えいした情報の悪用を防ぐ対策を、委託先も含めて徹底するよう求めています。JPCERT/CCの注意喚起は、別のシステムの侵害で盗んだAPIキーを使う手口も報告しています。

11利用者と企業が取るべき対応

日経は、漏えいが確認された人に個別に知らせるとしています。テレビ東京によると、通知は10月21日以降に日経から順次届く予定です。利用者が確かめることを、日経と各社の案内に一般的な備えを加えて整理します。

クラウドを使う企業が確かめること

企業向けの確認項目は、公開された情報と公的機関の注意喚起をもとにKEYRING編集部が整理したものです。関連する事案は、原因別の一覧「認証情報の漏れ」「不正アクセス」でも読めます。

12提言

今回の事案では、窃取された正規の認証情報でクラウドに入られ、開発用の環境に置かれていた個人情報が持ち出されました。日経BPの利用者の分が含まれていたほか、テレビ東京などもその可能性を発表しています。クラウドを使う企業に向けて、4つの提言をまとめます。

提言は、公開された情報をもとにKEYRING編集部が考えたものです。

用語集

認証情報

システムに正規の利用者であることを示すための情報。IDとパスワード、アクセスキー、APIキー、トークンなど

アクセスキー

プログラムがクラウドの機能を呼び出すときに使う鍵。人のログインと違い、多要素認証をかけにくい

トークン

認証の結果として発行され、一定の期間、本人の代わりに使える文字列

識別子

サービスの中で利用者を区別するための番号など。本件では、日経は単体では個人を特定できないものとしている

多要素認証

パスワードに加えて、スマートフォンへの確認など別の要素も使ってログインする方式

パスキー

端末の中の秘密鍵と指紋や顔の認証でログインする方式。鍵がサイトに結びつくため、偽のサイトでは使えない

情報窃取型マルウェア

感染した端末から、保存されたパスワードやログイン中の情報を抜き取る不正なプログラム

シークレット管理

鍵やパスワードを、ソースコードとは別の安全な保管場所で管理し、必要なときだけ取り出す仕組み

プッシュ保護

GitHubの機能。鍵などの秘密情報を含む変更が、リポジトリに届く前に止める

漏えい等報告

個人情報保護法にもとづき、一定の漏えいが起きたときに事業者が個人情報保護委員会へ行う報告。速報と確報の2段階

参考文献

• 日本経済新聞社「不正アクセスによる個人情報漏洩について」2026.10.16
• 日本経済新聞「日経、個人情報183万件漏洩　不正アクセスで」2026.10.16
• 日本経済新聞社「情報漏洩などに関するお問い合わせフォーム変更のお知らせ」2026.10.23、10.26 追記
• 日本経済新聞社「お問い合わせフォームのメンテナンス完了と復旧のお知らせ」2026.10.26
• 日本経済新聞社「お知らせ：最新情報」一覧2026.10.26 閲覧
• 日本経済新聞社「サイバー攻撃による情報漏洩、不審メールの送信について」2026.10.04
• 日本経済新聞社「不正ログインによる情報漏洩について」2026.10.04
• 日本経済新聞社「米国子会社での不正ログインについて」2026.05.07
• 日本経済新聞社「業務用チャット『スラック』への不正ログインと情報流出について」2025.11.04
• 日経BP「【重要なお知らせ】日本経済新聞社への不正アクセスに伴う当社サービス利用者の個人情報の漏えいについて」2026.10.21
• テレビ東京・BSテレビ東京「当社グループサービス登録者情報に関するお知らせ」（PDF）2026.10.16
• 山陽新聞デジタル（ORICON NEWS配信）「テレ東、日経の情報漏えいの影響巡り対応状況を説明」2026.10.20
• ITmedia NEWS「日経新聞、不正アクセスで183万件の個人情報流出　開発用クラウドの認証情報盗まれ」2026.10.16
• ITmedia NEWS「日経新聞への不正アクセスで日経BPの利用者情報も約80万件漏えい　テレ東などにも影響か」2026.10.23
• INTERNET Watch「日経新聞社、クラウドサービスへの不正アクセスで約183万件の個人情報漏えい」2026.10.16
• トヨタ自動車「お客様のメールアドレス等の漏洩可能性に関するお詫びとお知らせについて」2022.10.07
• Google Cloud（Mandiant）「UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion」2024
• AWS「Security best practices in IAM」2026.10.26 閲覧
• GitHub Docs「プッシュ保護」2026.10.26 閲覧
• Passkey Central（FIDO Alliance）「パスキーのセキュリティ」2026.10.26 閲覧
• ITmedia NEWS「Google広告の代理店アカウントに不正アクセス　顧客アカウントからカジノ広告無断配信　パスキー設定も侵入許す」2026.10.07
• 個人情報保護委員会「漏えい等の対応とお役立ち資料」2026.10.26 閲覧
• 個人情報保護委員会「大規模な漏えい等事案を踏まえた対応について（注意喚起）」の公表2026.10.07
• ITmedia NEWS「漏えい相次ぐ中、保護委が対策を緊急例示　強い多要素認証やEDR導入、不要な個人データの消去など」2026.10.08
• 総務省「不正アクセスによる情報漏えい等の事案を踏まえた対応について（注意喚起）」2026.10
• JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」2026.10.08 公開、10.23 更新

このレポートは2026年10月26日時点の公開情報にもとづきます。日本経済新聞社が新たな発表を出した場合は、内容を更新します。