7
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【もう無理だよ…】免許証画像まで流出する時代に、エンジニアは何をすればいいのか

7
Last updated at Posted at 2026-10-06

はじめに

最近、個人情報漏えいのニュースが多すぎないでしょうか。

スマホを開くと、また誰でも知っている会社の名前が出ている。

そう感じているエンジニアも多いんじゃないかと思います。

ここ最近で特にインパクトが大きかったのがタイムズカーの件です。

運転免許証の画像まで漏えいしたことで、「口座を勝手に作られるのでは」という不安が繰り返し報じられています。

この記事では、2026年10月6日時点で確認できた公式発表を中心に、次の点を整理してみます。

  • 何が流出したのか
  • 相次ぐ漏えいの原因はどこにあるのか
  • AIは脅威なのか、味方になるのか
  • エンジニアとして何を考えればいいのか

事実とそこからの考察は分けて書くようにします。

タイムズカーで何が流出したのか

まず時系列です。

日付 公表内容
9月 25日 第1報。9時07分に不正アクセスを検知し、漏えいの可能性を公表
9月 28日 第2報。第三者による情報取得を確認。対象は約660万アカウント
9月 29日 第3報。運転免許証画像などの本人確認書類が漏えいしたのは約160万件

第3報では、漏えいが確認された書類の種類も明記されています。

要旨:本人確認書類が漏えいしたのは約160万件。運転免許証画像、現住所確認書類画像(公共料金の請求書など)、学生証画像、家族確認書類画像が対象。

参考:タイムズモビリティ「第 3 報」

氏名や住所、生年月日、電話番号なども対象で、クレジットカード情報は保有していないため含まれないとのことです。
パスワードは「復元できない形式」(ハッシュ化。元の文字列を直接復元するのではなく、ハッシュ値に変換して保存すること)で保管されていたと説明されています。ただしハッシュ化も万能ではなく、適切なソルト(ランダムな値)が使われているかなどが重要とされています。

気になるのは「免許証画像で口座を作られるのか」という点です。
同社のFAQには、この点に触れた回答がありました。

要旨:金融機関などの非対面の本人確認では、書類画像だけでなく本人の容貌画像との照合や本人名義口座での確認といった追加手続が使われる。ただし不正な申込みなどの可能性を完全に否定するものではない。

参考:タイムズモビリティ「ご質問と回答」(PDF)

つまり画像だけで即座に口座が作れるとは限りません。一方で、同社も不正な申込みなどの可能性を完全には否定していません。
住所や生年月日や電話番号まで揃っているので、詐欺電話やなりすましの材料にはなりやすいんじゃないでしょうか。

もう一つ見逃せないのが、退会後の保管です。

要旨:氏名・住所・生年月日は税法等に基づき7年間保管。運転免許情報と画像はなりすまし対策や問い合わせ対応のため7年間保管。

参考:タイムズモビリティ「ご質問と回答」(PDF)

保管には理由があったわけですが、結果として退会者のデータも漏えい対象に含まれています。
なお確認できた公表資料では、侵入経路には触れられていませんでした。

大手の被害が相次いでいる

タイムズカーだけではありません。
9月に公表された主な事案を、公表資料で確認できた範囲で並べます。

公表日 組織 影響規模 公表されている原因など
9月10日 さくらインターネット 最大136万563アカウント(閲覧・取得の可能性) 販売管理システムへの不正アクセス(2023年4月以降〜2026年3月の間)
9月11日 デジタル庁(GSS) 約24.6万件 VPN機器の脆弱性を利用して侵入
9月28日 タイムズカー 約660万アカウント 調査中
9月30日 ベネフィット・ワン 13,460名 システム改修時の条件設定の不備

このほか、Gyazoでユーザー関連データ約2,362万件、ムラウチドットコムで771万6,811件の個人情報の持ち出しが確認されたと報じられています。
ただしGyazoの件数は、メールアドレス未登録の匿名ユーザーも含みます。
件数を単純に足しても意味がないので、数字は規模感の目安として見るのがよさそうです。

参考:各社公表資料をまとめたもの

※この記事を書き終わってニュースを眺めていたら「ハッカーが楽天会員1億100万件の個人情報 販売を主張」なんてニュースまで飛び込んできました。

放置されていた事例

気になったのは、気づいていたのに直さなかった、あるいは長期間気づけなかったという事例です。

ベネフィット・ワンの発表には次のようにあります。

要旨:2025年6月の改修でプログラムの条件設定に不備が発生。2025年10月の社内調査で把握していたが、解消作業が適切に実施されなかった。2026年7月30日に利用企業の担当者からの連絡で判明した。

参考:ベネフィット・ワン「お知らせとお詫び」(PDF) / ITmedia NEWS

社内調査で不具合を認知してから、利用企業の担当者からの連絡によって本件が判明するまで、約9か月ありました。
ダウンロード機能を実際に使ったのは1社1名だけで、二次被害(流出後に起きる詐欺や悪用)は確認されていないとのことです。

さくらインターネットは、販売管理システムへの不正アクセスが2023年4月から2026年3月までの間に発生していたと公表しました。
一部の初期パスワードがハッシュ化されず、そのままの値で保存されていたことや、ログ管理体制が不十分だったことも明らかになっています。

参考:@IT「さくらインターネット、3 年続いた不正アクセス」 / ASCII.jp

本当の原因とは

「本当の原因」を一つに絞るのは難しいと思います。
ただ公表されている範囲だと、似た傾向が見えます。

デジタル庁の発表はわかりやすい例です。

要旨:6月25日に保守運用担当者のアカウントでの大量ファイルアクセスを検知。7月9日、VPN(インターネットなどを介して、社外から社内ネットワークなどへ安全に接続する仕組み)の脆弱性(プログラムや設定の弱点)を利用した侵入と判明。再発防止策に脆弱性管理方法の見直しなどを挙げている。

参考:デジタル庁「GSS への不正アクセスについて」

警察庁の統計でも、侵入経路が判明したランサムウェア被害の回答のうち、約5割がVPN機器でした。

要旨:2026年上半期のランサムウェア被害報告は123件で、半期として過去最多。侵入経路が判明した回答の約5割がVPN機器。

参考:警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」(PDF)

並べてみると、外から触れる機器の弱点、把握しているのに直らない問題、初期パスワードやログの管理、不要になったデータの保持が目立ちます。
どれも最新の攻撃手法というより、運用や管理体制の問題として捉えられる部分があります。

「何が動いているかを把握し、期限を決めて直し、不要なものは消す」というサイクルが、十分に回っていなかった可能性があるのではないでしょうか。

もちろんこれは公表資料から読み取った推測です。
タイムズカーのように原因がまだ見えていない事案もあります。

AIの脅威

次はAIの話です。
警察庁の報告では、脆弱性を探る不審なアクセスが次のように増えています。

要旨:警察庁のセンサーで検知した脆弱性探索などの不審アクセスは、2026年上半期に1日・1IPアドレス当たり1万3,687件。前年同期比50.7%増。

参考:JAPANSecuritySummit Update

同じ報告では、AIの悪用も主要な脅威として扱われています。
生成AIで作ったコードを組み合わせてランサムウェアを作った会社員が逮捕された事例のほか、高性能AIが悪用されるとサイバー攻撃が高速かつ大規模になる可能性も指摘されています。

朝日新聞の取材では、専門家が「攻撃者がAIを休みなく動かして、弱いサイトを探している可能性も否定できない」という趣旨の指摘をしています。
あくまで可能性の話で、確認された事実ではありません。

参考:朝日新聞(Yahoo!ニュース配信)

AIが弱点を見つける側に回ると何が変わるのか。
Anthropicが発表したProject Glasswingでは、未公開モデルのClaude Mythos Previewが、主要なOSとブラウザで1万件を超えるhigh/critical severityの脆弱性を見つけたとされています。
同モデルは、一般公開しない方針だと報じられています。

参考:Anthropic「Project Glasswing」 / VentureBeat

ここから読み取れるのは、弱点が見つかってから悪用されるまでの猶予が短くなる可能性があるということです。
AIによる脆弱性発見が高速化するほど、発見後の検証・修正・適用までの時間が重要になります。パッチ(弱点を直す修正プログラム)を数週間放置していた運用は、今後さらにリスクが高くなる可能性があります。

「自分の情報は自分で守って」という発言

2026年10月6日、古川俊治デジタル相が記者会見で次のように述べたと報じられています。

要旨:サイバー攻撃は企業や組織だけの問題ではない。国民一人一人の対策が被害の防止につながる。自分の情報は自分で守るという意識を持って被害防止に向けた取り組みに協力してほしい。

参考:ITmedia NEWS「相次ぐ不正アクセス受け、古川デジタル相がコメント 国民に3つのサイバー対策呼び掛け」

古川氏は流出情報には氏名や住所、電話番号、メールアドレスだけでなく、IDやパスワード、クレジットカードの情報、運転免許証などが含まれる場合があると指摘。
不正利用を防ぐため、次の3つの対策を求めたとされています。

  • パスワードの使い回しをやめる
  • 多要素認証を利用する
  • 不審なメールやSNSに注意する

参考:ITmedia NEWS「相次ぐ不正アクセス受け、古川デジタル相がコメント 国民に3つのサイバー対策呼び掛け」

この発言に対しては、SNSなどで「企業が管理している情報が流出しているのに、個人でどう守るんだ」といった反応も見られました。

また、デジタル庁自身も2026年7月に約24.6万件の個人情報流出を起こしている点も、議論の対象になっています。

参考:デジタル庁「GSS への不正アクセスについて」

ただ、大臣の発言の趣旨は「企業側の対策だけでは完全には防げないため、利用者側でもアカウント乗っ取りや二次被害を防ぐためにやれることはやってほしい」というものだと解釈できます。

パスワードの使い回しをしない、多要素認証を使う、不審なメールのリンクを開かないといった基本的な対策は、実際に効果があると考えられています。

個人情報が流出していない日本人はいないのか?

ここまで来ると「もう日本人の個人情報は全員流出しているのでは」という話です。
断言はできませんが、SNSでそんな書き込みをいくつも目にしました。

アカウント数は人数と同じではなく、同じ人が複数のサービスで重複しています。
さらに「可能性がある」という段階の数字も含まれます。
ですから「ゼロです」とも「全員です」とも言えないというのが正確なところです。

ただ、一度も対象になったことがない人のほうが少ない、という感覚を持つ人は多いかもしれません。
だとすると、「流出しない」ことを前提にするより、流出しても被害が広がりにくい状態にしておくほうが現実的です。

AIでシステム全体をチェックできるのか

では、AIにシステム全体をチェックしてもらえばいいのでしょうか。
ここは正直、「一部はできるけれど全体は難しい」んじゃないかと思います。

コード中の脆弱性候補を探したり、既知の脆弱性や不備を指摘したりする用途では、AIの活用が進んでいます。
ただ今回の事例を見ると、問題はそこだけではありません。

  • ベネフィット・ワンは、不具合を把握していたのに解消されなかった。検知の問題ではなく対応の問題
  • さくらインターネットは、ログ管理体制の不足が指摘されている。ログがなければAIでも追えない
  • 何を持っているかの一覧(資産の棚卸し)がなければ、そもそもチェック対象にできない
  • 退会者の免許証画像のように、持つべきかどうかは設計と運用の判断になる

もし自社にAIの診断ツールを入れるとしたら、気になるのは「どこまでの範囲にアクセスさせるのか」です。
診断のために広い権限を渡すこと自体が、新しいリスクになる可能性もあります。

エンジニアとして何を考え、何ができるのか

ここからは、エンジニアとして考えられることをいくつか挙げてみます。
あくまで一般論としての整理です。

1. 自社の資産を把握する

まずは「何を持っているか」を把握することです。

  • 外部に公開している機器やサービスの一覧
  • 内部システムと外部接続の経路
  • 保有している個人データの種類と量
  • データの保管場所と期間

これらが不明確なまま対策を打っても、穴が残りやすいです。

2. 脆弱性の修正期限を決める

見つかった脆弱性を「いつまでに直すか」を決める運用です。

警察庁の統計では、侵入経路が判明したランサムウェア被害の回答の約5割がVPN機器でした。
既知の脆弱性を放置している機器が外部に公開されていると、そこが入口になる可能性が高まります。

参考:警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」(PDF)

「重大な脆弱性は発見から 72 時間以内」「それ以外は 2 週間以内」など、期限を切る例もあります。

3. 初期パスワードとログの管理

初期パスワードがハッシュ化されず保存されていた事例がありました。

参考:@IT

  • 初期パスワードは必ず変更させる
  • パスワードはハッシュ化して保存する
  • 誰がいつ何にアクセスしたかのログを取る
  • ログは改ざんされない場所に保管する

これらは基本的な対策ですが、できていないケースもまだあります。

4. 不要になったデータの削除

「持たなければ漏れない」という考え方です。

タイムズカーの例では、退会者の免許証画像を7年間保管していました。
法令や不正対策のための保管でしたが、結果として漏えい対象に含まれています。

参考:タイムズモビリティ「ご質問と回答」(PDF)

  • 利用目的が終わったデータは速やかに削除する
  • 保管が必要なデータは暗号化する
  • 保管期間を定期的に見直す

設計の段階で「何を持たないか」を決めるのも一つの考え方です。

5. 把握済みの不具合を放置しない

ベネフィット・ワンの例では、不具合を把握してから外部発覚まで約9か月ありました。

参考:ベネフィット・ワン「お知らせとお詫び」(PDF)

  • 不具合の発見・報告フローを整える
  • 修正責任者と期限を明確にする
  • 修正が完了するまでの進捗を可視化する

「知っているのに直っていない」状態を減らす仕組みが求められます。

6. 多層防御の意識

一つの対策だけで守ろうとしないことです。

  • 侵入を防ぐ(ファイアウォール、WAF)
  • 侵入されても拡大を防ぐ(セグメンテーション、最小権限の原則)
  • 拡大されても検知する(ログ監視、IDS/IPS)
  • 検知後に素早く対応する(インシデント対応フロー)

AIで弱点が見つかりやすくなる時代は、「侵入を完全には防げない前提」でどう被害を最小化するかが重要になってきます。

7. 利用者への啓発とサポート

エンジニアが直接できることとして、利用者への啓発もあります。

古川デジタル相が挙げた3つの対策は、実際に効果があると考えられています。

  • パスワードの使い回しをやめる
  • 多要素認証を利用する
  • 不審なメールやSNSに注意する

参考:ITmedia NEWS「相次ぐ不正アクセス受け、古川デジタル相がコメント 国民に3つのサイバー対策呼び掛け」

サービス側で多要素認証をデフォルトで有効にする、パスワード管理ツールの利用を促すといった工夫も考えられます。

8. 継続的な学習と情報収集

サイバー脅威は日々変化しています。

警察庁は半年に一度、脅威情勢を公表しています。
こうした情報を定期的に確認し、自社の対策に反映させるのも重要です。

参考:警察庁「令和 8 年上半期におけるサイバー空間をめぐる脅威の情勢等について」(PDF)

また、自社の業界団体が提供するセキュリティガイドラインや、IPA(情報処理推進機構)の資料も参考になります。

参考:IPA「情報セキュリティ 10 大脅威 2026」

9. 依存ライブラリの脆弱性をチェックする

自社で書いたコードだけでなく、使っているライブラリやフレームワークの脆弱性も確認が必要です。

  • 依存関係を一覧化する(package.json、requirements.txt など)
  • 脆弱性情報を定期的に確認する(GitHub Security Advisories、Dependabot など)
  • 更新前に変更内容と互換性を確認する

「使っているだけ」のコードでも、脆弱性があれば攻撃の入口になります。

10. VPN 機器の設定と更新を徹底する

警察庁の統計では、ランサムウェアの侵入経路の約5割がVPN機器でした。

  • 常に最新のファームウェアに更新する
  • 不要なポートは外部に公開しない
  • 多要素認証を必須にする
  • 古いプロトコル(PPTPなど)は使わない

VPNは「外から中に入る入口」なので、ここが突破されると内部ネットワーク全体が危険に晒されます。

対策を踏まえて実際にどう動くか

上司やお客様に「個人情報漏えい対策はどうなってる?」と聞かれたら

ここまで読んで、「じゃあ実際に上司やお客様から『個人情報漏えい対策はどうなっているの?』と聞かれたら、何を答えればいいんだ」と思う人もいるかもしれません。

こういう質問に対して、いきなり「WAFを入れています」「脆弱性診断をしています」と答えるのは避けるべきでしょう。

なぜなら、個人情報漏えい対策は一つの製品や仕組みだけで説明できるものではないからです。

そんなときは、次のような順番で整理して答えると説明しやすくなります。

  • 何の個人情報を持っているか
  • どこに保管しているか
  • 誰がアクセスできるか
  • 外部から侵入されないために何をしているか
  • アクセスされた場合に検知できるか
  • 漏えいした場合にどう対応するか
  • 不要になった情報をいつ削除するか

例えば、

「個人情報については、保有しているデータと保管場所を整理したうえで、アクセス権限を制限しています。外部からの侵入対策として脆弱性管理やアクセス制御を行い、アクセスログも記録しています。万が一問題が発生した場合の対応手順も整理しています。また、不要になったデータについては保管期間を定めています」

くらいまで整理できていれば、単に「セキュリティ対策しています」と答えるより、かなり具体的になります。

さらに大事なのは、「何をやっているか」だけでなく「誰が、いつ、どう確認しているか」まで説明できることです。

例えば、

「脆弱性診断をしています」

だけではなく、

「診断で問題が見つかった場合は、重要度に応じて修正期限を決め、対応状況を管理しています」

まで言えると、対策が一時的なものではなく、継続的な運用になっていることを説明できます。

逆に、

「WAFがあるので大丈夫です」
「ウイルス対策ソフトを入れています」
「クラウドなので安全です」

のように、一つの製品やサービスだけを根拠にするのは避けたほうがいいです。

個人情報漏えい対策は、「侵入されない」だけではなく、「持っている情報を把握する」「アクセスを制限する」「異常を検知する」「被害を広げない」「不要な情報を持たない」まで含めて考えるものだからです。

そして、もし分からないことがあるなら、無理に「大丈夫です」と答えないことも重要です。

「現在確認中です」「その点は担当部署に確認します」と一度持ち帰り、実際の設定や運用状況を確認する。

個人情報漏えい対策について聞かれたときに一番怖いのは、実際には確認していないのに「対策しています」と答えてしまうことなのかもしれません。

もし明日、自分が担当するシステムで情報漏えいが起こったら

ここまで読んで、「対策は分かった。でも、もし本当に漏えいしたらどうするんだろう」と思った人もいるかもしれません。

では、少し嫌な想像をしてみます。

明日の朝、一本の電話がかかってきます。

「昨日から、身に覚えのないアクセスが増えているんですが……」

ログを見ると、見慣れないアクセスがあります。

さらに調べると、どうも個人情報を扱っているシステムにアクセスされた形跡がある。

この瞬間、エンジニアとして一番やってはいけないのは、焦って一人で全部なんとかしようとすることです。

「とりあえずサーバを止めよう」
「ログを消して、設定を直しておこう」
「原因が分かるまで黙っておこう」

こうした行動は、かえって状況を悪化させる可能性があります。

まず必要なのは、何が起きているのかを把握しながら、適切な人に連絡することです。

実際にその立場になったらストレスで正常な判断なんて出来ないかもしれません。

想像するだけでもストレスがかかる状況です。自分一人で判断せずにホウレンソウをしっかりと行いましょう。

自社のインシデント対応手順に従い、責任者やセキュリティ担当、必要に応じて法務や広報などにも連携します。

同時に、ログなどの証拠を不用意に消さないようにしながら、どのシステムが影響を受けているのかを確認していきます。

そして、最初から「○○件漏えいしました」と断定できるとは限りません。

実際には、

「不正アクセスの可能性を確認した」
「現在、影響範囲を調査している」
「現時点で確認できている事実はここまで」

という段階を踏むことになるかもしれません。

ここで重要なのは、分かっていないことまで分かったように話さないことです。

事故が起きると、「で、結局何が漏れたの?」と聞かれます。

でも、最初から全部分かるとは限りません。

むしろ、

「まだ分かりません。ただし、ここまでは確認できています」

と正確に伝えるほうが、後から説明が変わってしまうよりずっと安全です。

もちろん、実際の対応では会社のインシデント対応手順や法令、契約などに従う必要があります。

エンジニアだけで判断できないこともたくさんあります。

だからこそ、事故が起きてから初めて「誰に連絡すればいいんだっけ?」となるのではなく、平時から連絡先や対応手順を確認しておくことが大切です。

そして、たぶん一番怖いのは「漏えいしたこと」そのものだけではありません。

漏えいに気づいた後、何をしていいか誰も分からないことです。

システムを作るときは、「正常に動くこと」を考えます。

でも、本当に大事なのは、正常に動かなくなったときにどうするかまで考えておくことなのかもしれません。

さいごに

個人情報漏えいのニュースが続くと、どうしても「またか」という気持ちになります。

公式発表を読み比べていて、個人的に印象に残った点が二つあります。

一つは、7年間保管という判断です。
法令や不正対策のためという理由は筋が通っているように感じますが、情報を保管している限り漏えいの対象にもなります。
「持たなければ漏れない」という考え方を、設計の段階でどこまで織り込めるのかは考えさせられました。

もう一つは、原因が派手な攻撃だけではなかったことです。
把握済みの不具合や、長期間気づけなかった侵入のように、日常の運用の延長にある話が多く見えました。
これは特定の会社だけの問題ではなく、開発や運用に関わる人なら誰にでも起こりうる話なんじゃないでしょうか。

AIで弱点が見つかりやすくなる時代は、直す側にも同じ速度が求められるのかもしれません。
道具が変わっても、持っているものを把握して、直して、不要なものは消すという流れは変わらないんじゃないかと思います。

個人情報漏えいのニュースは一個人としてもエンジニアとしても「怖い」と素直に感じます。

しかし、「怖い」だけで終わらずに、このニュースをきっかけに今携わっているシステムのセキュリティについて、よりよく深く考えるきっかけにしたいと思います。

参考リンク

7
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?