セキュリティは存在する。でも守れてはいない。
――システムの穴、人の過信。その両方に私たちの情報は預けられている。
「個人情報が流出しました」
またかと思う。
けれどその「またか」は本来かなり異常なことなのではないだろうか。
私たちは、住所や電話番号、本人確認書類まで預けた相手から、
後になって「守れませんでした」と告げられることに慣れ始めている。
2026年1〜9月、国内の組織が公表したサイバー攻撃による情報漏えい事案は454件。前年同期の304件から49％増えた。10月13日まででは485件となり、すでに2025年通年の432件を上回っている。
ＭＭ総研の調査による数字だ。ただし漏えいの可能性がある事案やその後の調査で漏えいが確認されなかった事案も含む。「485件すべてで流出が確定した」という数字ではない。[1]
それでもこれだけの組織が情報の安全を疑われる事態を公表している。
しかも私たちの日常に近いサービスばかりだ。
4つの事案だけで、約3,178万件。
東京商工リサーチが10月7日に公表した記事には、KDDIのISP向けメールシステムから1,223万1,954件のメールアドレス、「焼肉きんぐ」の公式アプリから1,078万8,963件の会員情報が漏えいしたとある。[2]
9月に公表されたタイムズカーの不正アクセスでは、約660万アカウントの情報が第三者に取得された。情報の内容は対象者によって異なるが、氏名や住所、運転免許情報などが含まれる。本人確認書類の画像を含むものも約160万アカウントあったと報じられている。[3][4]
10月8日にはローソンが「ローソンID」の情報215万5,345件の漏えいを公表した。別の「ローソンアプリ予約」でも26件の漏えいが確認されている。[5]
KDDI、焼肉きんぐ、タイムズカー、ローソンID。
この4つの公表値を単純に合算すると約3,178万件になる。
タイムズカーが概数なので、合計も概数で示す。
これは全国の総数ではない。
メールアドレス、会員情報、アカウントという異なる単位の合計で、同じ人の重複もあり得る。「約3,178万人が被害に遭った」という意味ではない。ローソンアプリ予約の26件はこの合計に含めていない。
それでもたった4つの事案でこの規模だ。
車を借りる。食事をする。買い物をする。
そのために渡した情報が利用者の知らないところで蓄積され、
ある日まとめて持ち出される。
私たちは便利なサービスを使いたかったのであって、
自分の情報をいつまでも保管してもらいたかったわけではない。
「ザル」なのは穴が残ったまま使われていることだ。
問題にしたいのは単に管理体制が曖昧だという話ではない。
プログラム、ネットワーク機器、API、入力フォーム、実行環境、利用者の端末に入るアプリ。さらに、クラウドの設定、認証情報、外部の部品や開発環境まで。
システムには別々に検査し対処しなければならない入口がある。
その中にはすでに危険性が知られ対策も示されているものがある。
それでも穴が残り情報を預かるサービスとして動いている。
私が「ザル」と呼びたいのはこの状態だ。
全事業者が何もしていないと言いたいのではない。未知の欠陥と修正可能な既知の欠陥を同じ「防げなかった」で片付けるべきではないということだ。
個人情報保護委員会の令和7年度年次報告には、対応方法が公開済みの脆弱性の放置、推測されやすい認証情報、データベースの不適切なアクセス設定などが実際の原因として記されている。[6]
以下は先ほど挙げた企業の侵入原因を断定するものではない。IPA、OWASP、JPCERT/CCなどの公開資料を基に穴が生まれる場所を整理したものだ。
① 入力フォームと、その入力を処理するプログラムの穴
問い合わせ、検索、ログイン、ファイルのアップロード。
利用者にとっては普通の入力欄だ。しかし入力された内容を安全に処理できなければデータベースへの不正な操作や、意図しない命令の実行につながり得る。SQLインジェクションやOSコマンド・インジェクションはその代表例だ。
表示処理の不備で利用者のブラウザ上に不正なスクリプトが動くXSSや、本人の意図しない操作を受け付けるCSRFもある。IPAはこれらの原因と対策を公開している。[9]
「入力欄でエラーになるから安全」とは限らない。
画面での入力チェックと、サーバー側で危険な処理を防ぐことは別である。
② APIの穴――ログインできることと他人の情報を見てよいことは違う
APIはアプリとサーバーなどがデータをやり取りする窓口だ。
ここで必要なのは利用者が誰かを確認する「認証」だけではない。その人が要求した情報を見たり変更したりしてよいかという「認可」も必要になる。
本人としてログインしていても他人の情報は見えてはいけない。
一般利用者が管理者の機能を使えてもいけない。
この確認が抜けたAPI、必要以上の情報を返すAPI、使われなくなったのに公開されたままの古いAPI。OWASPはこうした問題を主要なAPIリスクとして整理している。[10]
ログイン画面がある。それだけではその先のデータは守れない。
③ VPN、ルーター、ファイアウォールなど、機器そのものの穴
守るために導入した機器にもソフトウェアが入っている。そのソフトウェアに脆弱性があれば機器自体が侵入口になり得る。
購入して設置すれば終わりではない。使用中の製品とバージョンを把握し、修正の必要性を確認し更新や交換まで行う必要がある。
米CISAは実際の攻撃で悪用が確認された脆弱性をKEVカタログとして公開している。[11]
危険な欠陥はすべてが未知なのではない。
すでに攻撃に使われていると分かっている欠陥もある。
④ JavaやPerl、その周囲で動く部品の穴
「Javaだから危険」「Perlだから安全」という単純な話ではない。
言語の実行環境、利用しているライブラリやフレームワーク、その上に書かれたコード。それぞれに欠陥が入り得る。
問題は採用した技術より、何をどのバージョンで使いどの欠陥が残っているかを把握しているのかだ。
自分たちで書いたコードだけ点検してもその下で動く部品まで安全になったことにはならない。[9][11]
⑤ 利用者側のアプリを信用しすぎる穴
スマートフォンやPCに配られたアプリは解析や改変の対象になり得る。
画面に管理機能を出していない。アプリの操作では他人の情報を要求できない。内部の通信方法は普通の利用者には分からない。
それらはサーバーが不正な要求を拒否できることの代わりにはならない。
OWASPのモバイル向け基準もリモートサービスの認証・認可をサーバー側で強制する必要を示している。[12]
JPCERT/CCの今回の注意喚起には公開アプリの解析を起点としたAPIへの攻撃も記されている。[8]
「公式アプリから来るはずだから信用する」という設計は、危うい。
さらに端末内の保存情報や通信の保護も別途必要だ。利用者の端末が侵害された場合の問題とその端末からサーバーの不備を突かれる問題は分けて考えなければならない。[13]
⑥ クラウド、管理画面、バックアップに残る穴
本番の画面を守っていても別の場所に置いたコピーが公開されていればそこから漏れ得る。
管理用の機能、開発・検証用の環境、設定ファイル、バックアップ。通常の利用者には見えない場所も点検対象である。
JPCERT/CCは管理不備を利用した設定ファイルやバックアップファイルの窃取の可能性、管理・運用側のシステムの被害についても注意を促している。[8]
「普段使う画面には問題がない」と「情報への入口を管理できている」は別の話だ。
⑦ パスワード以外の「鍵」が漏れる穴
システム同士の接続にはAPIキーやアクセストークンなどの認証情報が使われる。
これらがソースコードや設定ファイル、作業ログなどに残り、必要以上の権限を持ったまま流出すれば正規の接続に使う鍵が攻撃者に渡ることになる。
OWASPはこうした秘密情報の保管、アクセス管理、監査、更新などを扱う指針を公開している。[14]
利用者のパスワードだけを強くしても裏側の鍵が漏れる穴は塞がらない。
⑧ 外部の部品と、開発・更新の経路にある穴
サービスは外部のライブラリやAPI、ソフトウェアを作成・配布する仕組みにも依存している。
その接続先や更新経路が侵害されたり過大な権限が残っていたりすれば、本番のログイン画面とは別の場所から影響が及び得る。
OWASPは依存関係の悪用、開発・配布環境の認証情報や権限の不備なども、独立したリスクとして整理している。[15]
完成した画面だけ見ていてもシステム全体の穴は見えない。
そして情報を預かる側の「人」が、穴を開ける。
ここまでの話だけではまだ足りない。
プログラムを直してもその情報を扱う企業の人間が不用意にファイルを開き、端末を持ち出し、外部の機器をつなぐ。あるいは危険を知りながら対策を先送りする。
ここにはコードの欠陥とは区別して問うべき人為的な問題がある。
一般利用者の注意不足の話ではない。顧客の情報を預かった企業の従業員、管理者、経営者、委託先が、その情報をどう扱っているかという話だ。
以下は運用上の危険の例であり先に挙げた個別企業でこれらが起きたと断定するものではない。
外部のファイルを「仕事の資料だから」と信用する。
取引先名義のメール、共有リンク、請求書、ダウンロードした資料。業務に必要そうに見えることと安全であることは別だ。
不審な添付ファイルの実行や偽サイトへの入力がマルウェア感染や認証情報の窃取につながることは警察庁も注意喚起している。[16]
必要なのは「怪しいものを開くな」という掛け声だけではない。確認方法、検査の仕組み、不審なときの相談先が、実際の業務の中に用意されているかだ。
顧客情報の入ったPCを、外へ持ち出す。
持ち出し自体が直ちに不適切なのではない。
問題は必要のない顧客データまで保存した端末を暗号化や持ち出し管理が不十分なまま持ち歩くこと。紛失や盗難、画面ののぞき見に備えず使うこと。個人端末や私用アカウントへ業務情報を移してしまうことだ。
IPAも持ち出す情報の削減、端末や外部媒体の暗号化、ルールの運用確認を挙げている。[17]
端末を渡した後に「本人が気をつけるだろう」で済ませるなら、企業は情報の保管場所を把握できているとは言い難い。
外部Wi-Fiにつなぎ、「VPNだから大丈夫」と考える。
Wi-Fiを使っただけで情報が漏れるわけではない。
HTTPSや適切なVPNには通信を保護する役割がある。
しかしその保護には範囲がある。
偽の接続先やログイン画面を信用する。ファイル共有を有効にしたまま使う。端末の更新を怠る。公共の場所で機密情報を画面に出す。
こうした問題までVPNが一括して解決してくれるわけではない。IPAも公衆Wi-Fi利用時の共有設定や、公共の場所での画面・会話への注意を求めている。[18]
VPNは接続している人や端末を無条件に安全にする装置ではない。
通信を暗号化してもその端末が感染していたり、認証情報が盗まれていたりすればそれぞれ別の対処が必要になる。
外部メディアを、「ちょっと使うだけ」で接続する。
USBメモリや外付けストレージは便利な運搬手段であると同時に、情報を持ち出す経路にも感染したデータなどを持ち込む経路にもなる。
すべてのUSBが危険という話ではない。利用の承認、検査、保存できる情報、紛失時の対応が決まっていないことが問題だ。
IPAは感染したPCや外部媒体の社内接続によって、感染を広げるおそれを指摘している。[17]
外で使った端末を社内へ戻すときも同じだ。持ち出すときだけ管理して戻すときは無条件に信用するのでは境界に穴が残る。
人為的な穴は、誤操作だけではない。
誤送信、公開範囲を間違えた共有リンク、アカウントの貸し借り、退職者や契約終了後の委託先に残る権限。
さらに意図的な情報の持ち出しも考えなければならない。
「社員だから」「長年の取引先だから」という信頼と、その人が何件の情報を取得できるべきかは別の話だ。
仕事に必要な範囲を超えて取得できる。大量に持ち出しても気づけない。その状態を信用だけで埋めることはできない。
ランサムウェアを降ってきた災害のように説明してはいけない。
ランサムウェアについても、人や企業の運用を抜きにして語ることはできない。
ただし「社員が怪しいメールを開いたから感染するもの」と理解すると、実際の入口を見誤る。
警察庁は現在の手口として、VPN機器などから未修正の脆弱性、漏えいした認証情報、弱いパスワード、設定不備を悪用して侵入するものが多いと説明している。[16]
つまり従業員がファイルを開かなくても侵入され得る。
一方で修正を適用するか、認証を強化するか、不要な接続を閉じるか、誰に管理権限を与えるかは企業側が管理すべき事項だ。
技術的な穴と人為的・組織的な管理の穴は、別々に存在するだけでなく重なって被害を広げる。
すべての被害を企業の過失と決めつけることはできない。しかし「ランサムウェアという高度な攻撃だった」で管理の検証を終えることもできない。
入口は何だったのか。既知の問題への対応はされていたのか。侵入後、なぜ重要な情報まで到達できたのか。異常を検知して止める仕組みは働いたのか。
ここを調べずに原因を語ったことにはならない。
「社員教育を徹底します」だけで穴は塞がるのか。
教育は必要だ。情報を扱う本人の責任もある。
それでも教育を受けた人が間違えることはある。急いでいることもだまされることもある。
その一回で大量の顧客情報に被害が及ぶなら、本人の注意力に預けすぎている。
端末や外部媒体の利用を管理する。不要な管理権限を渡さない。持ち出せる情報を絞る。不審な動きを検知する。問題があれば接続や権限を止める。
現場の従業員だけでなく、それらを実施する予算、担当者、権限、確認の機会を用意する側にも責任がある。
私が問いたいのは誰か一人がうっかりしたかどうかだけではない。
その「うっかり」や過信、先送りが、そのまま情報流出へつながる状態を企業が残していなかったか。
システムの穴を塞ぐことと人の行動によって開く穴を塞ぐこと。その両方がなければ情報を守る仕事は成り立たない。
穴があることと穴を残してよいことは違う。
ここまで挙げたものは、すべてのシステムに必ず存在する欠陥ではない。しかし、架空の心配でもない。対策や検査の対象として公に整理されている種類の問題だ。
それなのに事故の説明が「不正アクセスを受けました」で止まると、利用者には何も分からない。
未知の欠陥だったのか。既知の欠陥だったのか。修正は提供されていたのか。適用されていなかったなら代わりにどんな防御をしていたのか。
APIの権限確認が抜けていたのか。アプリ側の制限だけに頼っていたのか。そもそも点検対象に入っていない機器や古いシステムがあったのか。
この違いは大きい。
更新すると業務が止まる。古いシステムなので検証が必要だ。委託先との調整に時間がかかる。
そうした事情はあるだろう。だが修正まで時間が必要なら、公開範囲を狭める、機能を止める、アクセスを制限するなど別の対処が問われる。[8]
直せない事情は何もせず使い続けてよい理由にはならない。
すべての穴を一瞬で塞げるとは思わない。それでも何が残っていてどこまで危険で、いつ対処するのかを把握せずに情報を預かることは別の問題だ。
利用者には穴のある場所が見えない。
画面はきれいだ。ログインもできる。通信も暗号化されている。プライバシーポリシーも掲載されている。
その見た目から裏側の機器が更新されているかAPIに権限確認の抜けがないか、古いプログラムが公開されたままかを利用者は判断できない。
暗号化された通信でもその接続先の処理に穴があれば情報は守りきれない。
利用者が強いパスワードを設定し、怪しいリンクを避けていても、事業者側の穴を利用者自身が塞ぐことはできない。
だから「お客様もお気をつけください」だけでは対策の説明にならない。
預かった側にしか見えない穴は預かった側が点検し塞ぐしかない。
攻撃に使える詳細を公開する必要はない。しかし、原因の分類、影響範囲、修正の完了状況、その確認方法については、利用者が判断できる説明が必要だと思う。
規程どおりだった。それでも大量に漏れた。
そして穴を塞ぐ責任と合わせてもう一つ問いたいことがある。タイムズカーの事件後の対応だ。
10月16日、同社は本人確認書類の画像について保存ルールを変更すると公表した。
それまでは会員期間中に加えて退会後も7年間保有していた。変更後は登録確認が完了したら即時削除する。すでに保有している画像も、10月末までに削除するという。[7]
同社は従来の保存目的として不正利用が疑われる事案への対応、問い合わせ対応、本人確認業務などを説明している。理由も社内ルールもあった。
ここが重要だ。
ルールがなかったのではない。ルールに従ってリスクが蓄積されていた。
保存には業務上の理由があっただろう。しかしその利便性と本人確認書類を長期間持ち続ける危険はどのように比較されていたのだろう。
事件後に登録確認後の削除へ切り替えられると判断した。
ならばその判断を事件前にできなかったのはなぜか。
これは「最初から全部消せばよかった」と後知恵で責めたいのではない。
保存する理由は審査されても保存し続ける危険は同じ重さで審査されていたのか。
その問いだ。
「いつか使うかもしれない」は企業にとっての便利さである。
その間ずっと漏えいの危険にさらされるのは情報を渡した本人だ。
企業はシステムを復旧できる。利用者は自分を交換できない。
サービスが再開すれば企業にとっては一つの区切りになる。
しかし情報を渡した側にとって話はそこで終わらない。
パスワードは変えられる。メールアドレスも負担を引き受ければ変えられる。
では氏名は。生年月日は。住所や本人確認書類に含まれる情報は。
同じようには取り替えられない。
システムを復旧したことと外部へ出た情報を回収できたことは別だ。
「現時点で二次被害は確認されていない」という説明も、将来にわたって使われないという保証ではない。ただしそこから逆に必ず二次被害が起きると決めつけることもできない。
利用者に残るのはその不確実さである。
怪しい連絡が来たとき何を信用してよいか。どこまで自分の情報が知られているか。今後何に気をつけ続けなければならないか。
企業が情報を持つことで得る便利さと、漏れたときに本人が背負う負担は、同じ場所にはない。
データを集める設計を考えるときこの非対称を抜きにしてよいのだろうか。
「セキュリティ対策をしています」は何を意味するのか。
認証がある。暗号化がある。監視がある。規程がある。
それぞれに意味はある。漏えいが起きたという事実だけですべての対策が無意味だったとは言えない。
しかし対策の名前を並べても私の情報がどこまで守られるかは分からない。
誰かが一つのアカウントを乗っ取ったら、何人分の情報に届くのか。
大量の情報を取得する動きがあったらどこで止まるのか。
委託先のアクセス権は契約が終わったら消えるのか。
退会した私の情報はいつどこから削除されるのか。
こちらが知りたいのはそういうことだ。
JPCERT/CCが10月に公表した注意喚起でも、APIのアクセス制御や権限の最小化、大量アクセスの制限、不要なデータを残さないことなどが対策として挙げられている。APIとはアプリなどが裏側のシステムとやり取りする窓口のことだ。[8]
画面に鍵のマークがあっても、その裏で何ができるのかまで制御されていなければ十分ではない。
対策が「ある」という説明から何ができなくなっているのかという説明へ。
私はそこに基準を移すべきだと思う。
AIに仕事を渡すなら情報を集める発想も変えなければならない。
ここからは私自身の見方だ。
AIエージェントに仕事を任せるとき、メールも、ファイルも、顧客情報も、まとめて見られれば便利だと考えたくなる。
ただ仕事を進めるための権限は間違えたときに影響を与えられる範囲でもある。
人間なら一件ずつ行う作業を自動処理なら大量に実行できる。その速さは正しい処理にも誤った処理にも働く。
だからAIを使うかどうかの前に、どの情報を何のためにどの期間だけ渡すかを決める必要がある。
一つの仕事に必要な範囲だけ見せる。閲覧と変更を分ける。外部送信は別の判断にする。異常な動きがあれば止める。仕事が終わったら権限を戻す。
AIが賢くなるほど何でも渡してよくなるとは私は思わない。
むしろ任せられる仕事が増えるほど、渡さないものを決める設計が重要になる。
セキュリティは壊れ方まで含めて設計するものだ。
まず既知の穴を放置しないこと。プログラムも機器もAPIも、点検し、修正し、その結果を確認すること。ここを飛ばして「侵入される前提」を語ってはいけない。
同時に一つ破られただけで何百万件もの情報へ進める状態を残さないことも必要だ。
持たなくてよい情報を持たない。必要な情報も、保有期間を決める。一つの権限で全部を扱えないようにする。異常を見つけ、止め、調べ、復旧できるようにする。
そしてその仕組みが実際に働くか確かめ続ける。
壊れる可能性を認めることは責任を諦めることではない。
壊れたときに誰が何を失うのかまで考えることが設計の責任なのだと思う。
「セキュリティなんてあってないようなものだ」
利用者がそう感じてしまう現実を知識不足の一言で片付けることはできない。
対策は存在している。それでも大量の情報が外へ出ている。ならば私たちが求めるべきなのは対策をしているという宣言を増やすことではない。
プログラムや機器、APIに残る穴を把握して塞ぐ。端末の持ち出し、外部ファイルやメディアの利用、人の権限と行動も管理する。修正までの間も危険な入口を開けたままにしない。そのうえで預かる情報と触れられる範囲を減らすことだ。
私は便利なサービスを使いたい。
そのために渡した自分の情報がいつまでもどこかに残り漏れる日を待つような社会にはしたくない。
情報を集められることと預かる資格があることは同じではないのだ。
出典・集計について
2026年10月18日確認。公表後の調査によって数値や内容が更新される場合があります。全国の漏えい総数・重複を除いた被害人数を示す記事ではありません。事実の記述と、それを踏まえた筆者の意見を分けています。
[1] ＭＭ総研「サイバー攻撃による情報漏えい、2026年は4年前の約1.9倍に」（2026年10月14日）
[2] 東京商工リサーチ「上場企業『個人情報漏えい』、過去最悪ペース」（2026年10月7日）
[3] Impress Watch「タイムズカー、660万件の情報漏えい 住所や免許情報など」（2026年9月28日）
[4] ITmedia NEWS「タイムズカー、退会後も7年間保管していた免許証画像を全削除へ」（2026年10月16日）
[5] ローソン「第三者による不正アクセスに伴う個人情報漏えいに関するお詫びとお知らせ」（2026年10月8日、13日追記）
[6] 個人情報保護委員会「令和7年度年次報告」
[7] タイムズモビリティ「タイムズカーWebシステムへの不正アクセスに関する対応について・第4報」（2026年10月16日）
[8] JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（2026年10月8日、9日更新）
[9] IPA「安全なウェブサイトの作り方」
[10] OWASP API Security Top 10 2023
[11] CISA Known Exploited Vulnerabilities Catalog
[12] OWASP MASVS-AUTH-1
[13] OWASP Mobile Application Security Verification Standard
[14] OWASP Secrets Management Cheat Sheet
[15] OWASP Top 10 CI/CD Security Risks
[16] 警察庁「ランサムウェア被害防止対策」
[17] IPA「日常における情報セキュリティ対策」
[18] IPA「テレワークを行う際のセキュリティ上の注意事項」
