この記事のポイント
- 2026年9〜10月、国内で個人情報漏えいの公表が相次ぎ、会員情報、本人確認書類、業務システムなど、対象は多岐にわたっています。
- 消費者の約7割が個人情報の提供に抵抗を感じており、そのうち35％は実際にサービスの利用をやめています。
- 見直すべき観点は、管理されていない「入口」、ログイン後の「権限」、一度の侵害で大量のデータに届く「構造」の3つです。
- 優先したい対策は、APIの認可テスト、強い認証と最小権限、保有データの削減、委託先の運用確認、AI利用範囲の明確化の5つです。
- まずは90日を目安に、システムと個人情報の棚卸しから着手することをおすすめします。
アプリに氏名や住所を登録し、本人確認のために身分証明書の画像を送る。こうした手続きは、すっかり日常の一部になりました。その一方で、預けた情報がどこに保存され、誰がアクセスでき、いつ削除されるのかを、利用者が把握するのは容易ではありません。
2026年9月から10月にかけて、日本では個人情報漏えいに関する公表が相次いでいます。企業に求められているのは、不正侵入を防ぐことに加え、侵入された場合の影響を小さくし、利用者が安心してサービスを使える仕組みを整えることです。
本記事では、最近の事例と消費者意識を整理したうえで、企業が優先して取り組むべき対策を解説します。
最近の事例が示す、漏えいリスクの広がり
2026年9月から10月にかけて公表された主な事案は、次のとおりです。
- 大手コンビニエンスストアの会員ID：不正アクセスにより、約215万件の氏名やメールアドレスなどが漏えい（10月8日公表）
- カーシェアリングサービス：約160万アカウント分の運転免許証画像などの本人確認書類が漏えい（9月29日公表）
- 法人向け一斉配信サービス：約313万件のメールアドレスなどが漏えいした可能性（推定値。10月14日には関連サービスにも調査対象が拡大）
- 政府のガバメントソリューションサービス（GSS）：VPN機器の脆弱性を悪用した侵入と、保守運用担当者のアカウントを使った不正アクセスにより、職員や業務関係者の情報約24.6万件が漏えいした可能性（9月11日公表。一般の方の個人情報は含まれないとされています。デジタル庁の発表）
これらは、対象データ、件数の単位、漏えいの確度がそれぞれ異なる事案です。同じ原因による事件として扱ったり、件数を単純に合計したりすることは適切ではありません。また、公表内容だけで個々の脆弱性や攻撃手法を断定することもできません。
ただし、消費者向けアプリ、本人確認書類、外部サービス、運用環境まで、点検すべき範囲が広がっていることは読み取れます。特に本人確認書類は、パスワードのように変更して対処することができないため、保管方法とアクセス権限をより慎重に設計する必要があります。
消費者の不安は、サービスの利用判断にも関わる
一般財団法人日本情報経済社会推進協会（JIPDEC）が2026年1月に国内の18〜79歳、1,449人を対象に実施したWeb調査では、約7割が個人情報の提供に抵抗を感じていました。抵抗を感じた人のうち35％は、実際にサービスの利用をやめたと回答しています（JIPDECの調査発表）。
この調査は9〜10月の事案より前に実施されたもので、最近の事案によって不安がどれだけ高まったかを示すものではありません。それでも、個人情報の扱いがサービスの利用判断に直結していることがわかります。
同調査では、企業への信頼を損なう原因として、外部からの攻撃（46.4％）よりも、人為的ミス（51.7％）、管理体制の不備（51.3％）、内部不正（50.2％）を挙げる人が多くなっています（調査報告書）。
利用者が企業に預けているのは、情報だけではありません。「必要な範囲で使い、適切に守ってくれる」という信頼でもあります。収集目的の明示、不要な入力項目の削減、事故発生時の具体的な支援までを、サービス品質の一部として捉える必要があります。
原因を考える鍵は、データへの「入口」と「権限」
JPCERT/CCは2026年10月8日の注意喚起で、最近の国内事案に見られる複数の攻撃パターンを示しています。既知の脆弱性や管理上の不備の悪用、スマートフォンアプリから見つけたAPIへの不正なリクエスト、BIツールの脆弱性の悪用などです。また、従業員向けの管理システムやBIツールといった社内向けのシステムも被害に遭っているとしています（JPCERT/CCの注意喚起）。
すべての事案が同じ手法によるものではありませんが、企業は少なくとも次の3つの観点を見直す必要があります。
1. 管理できていない「入口」が残っていないか
顧客向けサイトだけでなく、運用担当者向けの管理画面、BIツール、検証環境、VPN機器などの外部接続機器も確認の対象です。利用目的や管理責任者が曖昧なシステムは、更新や監視の対象から漏れやすくなります。
まず必要なのは、システムの一覧を作り、誰が管理し、どのデータにつながっているのかを明らかにすることです。
2. ログイン後の「権限」を適切に制限できているか
本人であることを確かめる「認証」と、アクセスしてよい情報を決める「認可」は、別の仕組みです。
たとえば、利用者Aとしてログインした状態で、利用者Bの情報を取得できないか。一般の利用者が、管理者向けの処理を実行できないか。こうした確認は、画面の表示だけでなく、サーバー側で行う必要があります。OWASP API Security Top 10でも、データや機能ごとの認可の不備が、APIの主要なリスクとして挙げられています。
なお、これは一般的な設計上の論点であり、前述の個別事案の原因を示すものではありません。
3. 一度の侵害で大量のデータに届く構造になっていないか
保守担当者のアカウントや外部サービスとの接続に広い権限が与えられていると、一つの侵害が大規模な被害につながるおそれがあります。
業務ごとに権限を絞る、重要なデータを分離する、作業に必要な時間だけアクセスを許可する。こうした設計が、被害の拡大を抑えるうえで重要です。
これから重視したい5つの対策
1. APIの安全性を、開発と運用の両方で確かめる
APIの一覧と権限ルールを整備し、他人のデータや別の顧客企業の領域にアクセスできないことをテストします。新機能を追加するたびに同じ確認を繰り返せるよう、テストを自動化しておくことが重要です。
「正しく使えるか」だけでなく、「許可されていない操作を確実に拒否できるか」を品質基準に組み込みます。
2. 強い認証と、必要最小限の権限を組み合わせる
米国のサイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は、フィッシングに強いFIDO/WebAuthnによる認証への移行を推奨しています（CISAの解説）。管理者や保守担当者など、重要なデータにアクセスできるアカウントから導入を検討する価値があります。
ただし、認証を強化しても、APIの認可の不備は解消されません。権限の見直し、操作ログの記録、不要になったアクセス権の削除を併せて進める必要があります。
3. 保存する個人情報と、その複製を減らす
必要な情報を必要な期間だけ持つことは、漏えい時の影響を小さくする有効な対策です。法令や契約上の保存要件を確認したうえで、利用目的を終えたデータを削除する仕組みを整えます。JPCERT/CCも、保存期間や利用目的を過ぎたデータを残さないよう呼びかけています。
本番環境だけでなく、テスト用データ、ログ、バックアップに個人情報が複製されていないかも点検しましょう。
4. 委託先の対策を、実際の運用まで確認する
IPAは、経済産業省と内閣官房国家サイバー統括室の方針に基づき、「サプライチェーン強化に向けたセキュリティ対策評価制度（SCS評価制度）」の運用準備を進めています。取引先を含めた企業のセキュリティ対策を、共通の基準で段階的に評価する仕組みです（IPAの制度説明）。
発注側としては、認証の取得状況やチェックシートに加え、誰がデータにアクセスするのか、異常をどう検知するのか、事故発生時にどう連絡するのかまで確認しておきたいところです。再委託先を含めた責任分担の明確化も欠かせません。
5. AIの利用範囲を、データ保護の設計に含める
IPAの「情報セキュリティ10大脅威 2026」では、「AIの利用をめぐるサイバーリスク」が組織向けの3位に初めて選ばれました（IPAの公表資料）。今回の事案の原因がAIだったことを示すものではありませんが、AIの業務利用が広がるなかで見過ごせないリスクです。
AIを利用する際には、入力してよいデータ、外部サービスでのデータの保存条件、AIが参照できる社内情報を明確にします。業務を自動で実行するAIエージェントについても、人と同様にアクセス権限と操作範囲を制限する設計が求められます。
最初の90日で何から着手するか
すべての対策を一度に導入する必要はありません。まずは個人情報にアクセスできる経路を把握し、影響の大きい箇所から改善します。以下は、企業ごとの状況に合わせて調整するための目安です。
最初の30日：棚卸しと優先順位づけ
- システムと保有する個人情報の棚卸し
- 公開範囲、既知の脆弱性、管理者権限の確認
- 成果の目安：システムごとの管理責任者と、優先して対応する箇所が明確になっている
31〜60日：認可の検証と不要データの削減
- APIの認可テストと、大量取得を検知する監視の導入
- 不要なデータの削除と、委託先の運用状況の確認
- 成果の目安：見つかった問題が修正され、対策が実際に機能している
61〜90日：事故を想定した訓練
- 漏えいを想定した演習と、バックアップからの復旧テスト
- 顧客への連絡手順の確認
- 成果の目安：検知から影響範囲の把握、顧客への連絡までを実際に行える
導入した製品の数よりも、危険な権限をどれだけ減らせたか、異常をどれだけ早く発見できるかを指標にすることが大切です。
まとめ：個人情報の扱いを、サービス品質として見直す
個人情報保護は、システム部門だけで完結する課題ではありません。何を収集するかを決める事業部門、システムを作る開発部門、委託先を選ぶ調達部門、利用者に説明する窓口部門が、それぞれ役割を担っています。
最初に確認したいのは、「誰が、何のために、どの情報へ、いつまでアクセスできるのか」という問いです。この問いに具体的に答えられる状態をつくることが、被害の抑制と利用者の信頼につながります。
SupremeTechは、ISO/IEC 27001やSOC 2に基づく管理体制のもと、Webサービスや業務システムの開発・運用を支援しています。個人情報を扱うシステムの権限設計やAPIの認可、データの保存状況を見直したいとお考えの際は、お気軽にご相談ください。
よくある質問
個人情報の漏えいを防ぐために、まず何から始めるべきですか？
システムと個人情報の棚卸しから始めるのが効果的です。どのシステムがどの個人情報を保有し、誰が管理し、どこからアクセスできるのかを一覧にすることで、優先して対策すべき箇所が明確になります。
認証と認可の違いは何ですか？
認証は「利用者が本人であるか」を確かめる仕組み、認可は「その利用者がどの情報や機能にアクセスしてよいか」を決める仕組みです。認証を強化しても、認可に不備があれば他人のデータを取得できてしまうため、両方の対策が必要です。
委託先のセキュリティ対策は、どこまで確認すべきですか？
認証の取得状況やチェックシートだけでなく、データにアクセスする担当者、異常の検知方法、事故発生時の連絡体制まで確認することをおすすめします。再委託先がある場合は、その責任分担も明確にしておく必要があります。
※本記事は2026年10月15日時点の公開情報に基づいています。調査中の事案には未確定の情報が含まれ、今後更新される可能性があります。