企業の情報漏洩事故は、不正アクセスや共有設定の誤り、委託先での情報管理など、さまざまな経路で発生します。自社の対策を見直すには、事故の原因や影響状況だけでなく、管理上の課題を確認することが重要です。本記事では、2026年に公表された事例をもとに、ファイル管理やアクセス権限の点検項目と、対策の優先順位を解説します。
※事例の記載は2026年10月時点の各公表主体の発表に基づきます。原因が調査中の事項や可能性として示された内容は、公表主体が確認した事実と区別しています。
Contents
2026年に公表された企業の情報漏洩事例
【事例1】カーシェアリング事業者｜Webシステムへの不正アクセス
2026年9月25日、カーシェアリング事業者のWebシステムで第三者による不正アクセスが確認されました。9月29日の公表では、運転免許証画像などの本人確認書類が漏洩したアカウント数は約160万件とされています。
【事例2】チケット販売事業者｜管理システムへの不正アクセス
2026年9月、チケット販売事業者の電子チケット払戻し情報を管理するシステムが不正アクセスを受け、顧客の個人情報が漏洩しました。9月29日の公表によると、対象は計1,463件で、メールアドレスや氏名、一部の振込先口座情報などが含まれます。
【事例3】IT情報サービス事業者｜システムの脆弱性を悪用した不正アクセス
2026年9月14日、IT情報サービス事業者は、システムの脆弱性を悪用した不正アクセスの調査結果を公表しました。取引先向けサービスの担当者情報1,137件（対象者1,132名）が不正取得された可能性があるとし、脆弱性の修正やアクセス制御の見直しなどを実施しています。
情報漏洩事例から見える管理上の課題
ニュースを読んでも自社の対応に結び付かない理由は、多くの場合、次の3点にあります。
- 事故の「手口」だけを見て、自社の「管理の前提」と照らしていない：手口は事例ごとに異なりますが、どのファイルが・どこに・誰の権限で置かれていたかという前提は、自社にも置き換えて確認できます
- 報道と公表資料、事実と推定が混ざったまま判断している：報道段階の情報には推測が含まれることがあり、それを前提に対策を決めると優先順位を誤ります
- 確認する観点が担当者ごとに違う：同じニュースを読んでも、情シスはアカウント、法務は委託契約、現場は共有リンクと、見る場所がばらばらになりがちです
事例から学ぶべきことは「同じ事故が起きないか」よりも、自社のファイル・権限・アカウント・委託先の管理状態を、共通の観点で棚卸しできているかです。この記事では、その観点を点検表にまとめています。
情報漏洩事例の公表資料を確認するポイント
情報漏洩事例を確認する際は、当事者企業・団体の公式発表を基本資料とし、制度や対策指針については官公庁・公的機関の公表情報を参照します。第三者の調査報告は原因分析を補う資料となります。報道記事やSNSは事象を知る手掛かりとして利用し、重要な事実は一次資料と照合します。
公表資料は第1報・第2報・最終報告と更新されることがあります。どの版の資料を、いつ確認したかを残しておくことが、社内報告の正確さにつながります。
情報漏洩の原因・管理上の課題を6つの類型で整理
個別事例を横断して見る際は、手口ではなく「どの管理の前提が崩れたか」で分類すると、自社の点検項目に置き換えやすくなります。以下は事例を整理するための分類枠の例です。特定の類型の発生件数や増減を示すものではありません。
| 類型 | 崩れた前提の例 | 自社で確認する観点 | 関係する部門 |
| 共有設定の誤り | 社外に公開するつもりのないファイルが閲覧可能になっていた | 外部共有リンクの公開範囲・有効期限、共有状態の棚卸し | 情シス・各部門 |
| 権限の過剰付与 | 業務上不要な人がアクセスできる状態だった | フォルダ単位の権限、異動・退職時の権限見直し | 情シス・人事 |
| 大量ダウンロード・持ち出し | 通常と異なる量のファイル取得に気付けなかった | 操作記録の取得と確認の運用、持ち出しルール | 情シス・リスク管理 |
| 委託先・取引先経由 | 委託先に渡したデータの管理状態を把握していなかった | 受け渡し方法、委託先の保存場所と削除の確認 | 調達・法務・各部門 |
| 保守・共用アカウント | 管理されていないアカウントが残っていた | 保守用・共用アカウントの一覧化と利用状況 | 情シス |
| 保存場所の分散 | 機密ファイルが個人の端末や管理外の場所に保存されていた | 機密情報の保存場所の規定と実態の差 | 情シス・各部門 |
事例を読むたびにこの表のどこに当てはまるかを記録していくと、ニュースが「他社の話」で終わらず、自社の点検観点として蓄積されます。
横断分析の進め方
- 公表資料を収集し、記録シートに出典と確認日を記入する
- 記載内容を「事実」「推定」「調査中」に分ける
- 事実と推定から「崩れた前提」を抜き出し、類型表に当てはめる
- 類型ごとに、自社で同じ前提が成り立っているかを点検表で確認する
- 点検結果から対応の優先順位を決め、担当部門と期限を割り当てる
情報漏洩対策の点検表｜ファイル管理・認証・委託先管理
類型整理を自社の業務に落とし込むための点検表です。「現状」欄には事実を、「根拠」欄には確認方法（設定画面、台帳、ヒアリングなど）を書きます。さらに、認証、脆弱性管理、不審なアクセスの監視も点検対象に加えます。
| No. | 点検項目 | 確認方法の例 |
| 1 | 機密情報を保存してよい場所が規定され、実態と一致しているか | 規程と実際の保存先の照合 |
| 2 | 外部共有中のファイル・フォルダを一覧で把握できるか | 共有状態の棚卸し |
| 3 | 外部共有に公開範囲や有効期限のルールがあるか | 共有ルールと運用の確認 |
| 4 | フォルダごとのアクセス権限が業務上必要な範囲になっているか | 権限設定のサンプル確認 |
| 5 | 異動・退職時に権限とアカウントが見直されているか | 人事異動との照合 |
| 6 | 保守用・共用アカウントが一覧化され、利用者が特定できるか | アカウント台帳の確認 |
| 7 | ファイルの閲覧・ダウンロード等の操作記録を確認できる状態か | 記録の取得範囲と確認担当の確認 |
| 8 | 委託先・取引先とのファイル受け渡し方法が決まっているか | 受け渡し手段の実態調査 |
| 9 | 委託先に渡したデータの保存・削除状況を確認しているか | 契約・確認記録の確認 |
| 10 | ファイルの版が管理され、最新版と旧版の取り違えを防げるか | 版管理の運用確認 |
| 11 | 重要なシステムや管理者アカウントに多要素認証を導入しているか | 認証設定・適用対象の確認 |
| 12 | システムやソフトウェアの脆弱性を把握し、対応しているか | 資産台帳・更新履歴の確認 |
| 13 | 不審なログインやアクセスを検知・調査できるか | 監視設定・ログ保存状況の確認 |
「現状」を正直に書くことが、点検表の価値を決めます。できていない項目が見つかること自体は問題ではなく、優先順位を付ける材料になります。
Fleekdriveで対応できるファイル管理・情報漏洩対策
Fleekdriveは、企業向けオンラインストレージとして、ファイル共有、アクセス権限管理、操作履歴の記録、バージョン管理などの機能を提供しています。ファイル配信ではパスワード、ダウンロード回数、公開期間を指定でき、監査オプションでは不審な操作の検知にも対応します。詳細は「ファイル共有」「ユーザ・アクセス管理」「セキュリティ」の各機能ページで確認できます。利用条件や設定範囲はプラン・オプションによって異なるため、自社の要件と照合して検討してください。
また、ツールの導入だけで点検表の項目が満たされるわけではありません。保存場所の規定、共有ルール、異動時の手順といった運用側の整備と組み合わせて検討することが前提です。
実施優先順位
点検で複数の課題が見つかった場合は、影響範囲、悪用される可能性、現在の管理状態、対応の緊急性を踏まえて優先順位を決めます。機密情報が外部から閲覧できる状態や不正利用が疑われるアカウントがある場合は、着手のしやすさにかかわらず緊急対応を検討します。
| 優先度 | 判断の目安 | 該当する管理・点検内容 |
| 1:すぐ着手 | 外部から閲覧可能な状態が残っている、または管理者不明のアカウントがある | 外部共有の把握・公開範囲の管理、保守用・共用アカウントの管理 |
| 2:短期で整備 | 権限の過剰付与や異動・退職時の手順に漏れがある | アクセス権限の適正化、異動・退職時の権限見直し |
| 3：計画的に整備 | 保存場所や委託先管理、操作記録の確認体制について、ルールや運用手順が十分に整備されていない状態。ただし、機密情報の外部公開や不正利用が疑われる場合は、優先度を引き上げる | 保存場所の管理、操作記録の確認、委託先との受け渡し・データ管理 |
| 4:継続改善 | 版管理など、業務効率と併せて見直す項目 | ファイルの版管理 |
判断の分岐
- 外部共有の状態を一覧で把握できない場合 → まず棚卸しを優先し、他の対策は棚卸し結果を見て決める
- 一覧で把握できるが、ルールがない場合 → 共有ルールの策定と既存共有の見直しを並行する
- ルールはあるが守られていない場合 → 運用の負担が原因かを現場に確認し、仕組み側で補えるかを検討する
よくある質問
企業の情報漏洩事例から、自社では何を確認すべきですか？
まず機密情報の保存場所、外部共有の設定、アクセス権限、アカウント管理、委託先とのデータ受け渡し、認証や脆弱性管理を確認します。事故原因や影響範囲は事例ごとに異なるため、公式発表で確認できる事実と推定を区別し、自社のリスクを整理することが重要です。
報道で知った事例を社内資料に使ってもよいですか。
発生を知るきっかけとしては有用ですが、社内で対策を判断する根拠には、当事者企業や公的機関の公表資料を優先することをおすすめします。引用する場合は出典と確認日を記録し、推定と事実を分けて記載してください。
原因が「調査中」の事例は分析に使えませんか。
公表主体が確認した事実の部分は点検観点に使えます。原因が推定や調査中の段階では、断定せずに「予防的な点検の観点」として扱い、続報で内容を更新する運用にすると安全です。
点検表の項目はすべて実施する必要がありますか。
自社の業務や保有する情報によって、優先すべき項目は異なります。まずは外部から閲覧可能な状態や管理者不明のアカウントなど、影響が大きく着手しやすい項目から始め、段階的に範囲を広げてください。
Fleekdriveで情報漏洩対策に必要なファイル管理を行えますか？
Fleekdriveでは、ファイル共有、ユーザ・アクセス権限管理、操作履歴の記録、バージョン管理などを行えます。ファイル配信時の公開期間設定や監査オプションによる不審な操作の検知にも対応します。ただし利用条件はプラン・オプションによって異なり、社内の運用ルールやアカウント管理体制の整備も必要です。
まとめ
企業の情報漏洩事例から自社の対策を見直すには、公表された事故の原因や影響範囲を確認し、同様のリスクが自社にないかを点検することが重要です。外部共有、アクセス権限、アカウント、委託先に加え、認証や脆弱性管理も確認しましょう。課題は影響範囲と緊急性に応じて優先順位を決め、担当者と期限を設定します。ファイル共有や権限管理の基盤を見直す場合は、Fleekdriveの機能と自社の管理要件を照らし合わせて検討できます。
