情報漏洩の原因別対策7つ｜誤送付・VPN・API・アカウント・委託先・生成AI・侵入後

図1：情報漏えいの7つの原因別対策を、カードに整理したイメージ図（AI生成イラスト）

情報漏えいの対策は、誤送付なら確認手順の文書化、VPNなら機器の洗い出しとパッチ適用のように、原因ごとに対策が異なります。この記事は、情報漏洩の原因についての記事で記載した対策の選び方について、根拠（出所）と、自社で確認することをまとめた、対策の詳細がわかる記事です（2026年10月23日時点）。

なお、国家サイバー統括室（NCO）とIPA（情報処理推進機構）の10月9日の文書は、大量の個人情報や機微な情報を取り扱う事業者などに向けたものです。中小企業向けの資料に頼る箇所は、その旨を書いています。個別の事案は、各社・各機関が公式発表に書いた範囲だけを取り上げます。

原因別の対策は何がある？

図2：原因が起きる場所ごとに、対策の柱が違うことを、会社の断面図で示したイメージ図（AI生成イラスト）

本記事では、情報漏えい対策を、誤交付・誤送付、外部公開システム・VPN、API・Web・クラウド保存領域、アカウント・権限・認証、委託先・サプライチェーン、生成AIへの入力という6つの原因・リスク領域と、侵入後の被害拡大を抑える備えを加えた7つの観点に整理します。

以降は、この順に、各原因の根拠と自社で確認することを示します。

誤交付・誤送付はどう防ぐ？

書類の交付やメールの送信前に、宛先や内容を確認する手順を文書化します。確認方法として、送信者以外によるダブルチェック、送信前の確認表示、本人確認などを、業務の特性に応じて組み合わせます。

根拠・出所

対策の柱

• 確認手順の文書化：渡す書類や送るメールの確認項目を、手順書やチェックシートにする
• 宛先確認：送信者以外の人、または送信前の確認表示など仕組みで確かめる
• 事例の共有：ヒヤリハットや過去の誤送付を、会議や研修で共有する

自社で確認すること

• 書類や資料を渡す・送る前の確認手順が、文書になっているか
• 宛先を、送信者以外の人や仕組みで確認しているか
• ヒヤリハットや誤送付の事例を、共有する場があるか

親記事の6ステップでは、ステップ4（ヒューマンエラーを仕組みで減らす）にあたります。

外部公開システム・VPNの脆弱性への対策は？

外部公開システムとVPN機器を、外部事業者から借りている機器も含めて洗い出し、パッチ（修正プログラム）を適用するまでの担当を決め、侵害が疑われる場合に備えて、更新前に何を保存するかも決めます。

図3：外部公開システム・VPNの原因と、起きうること、対策の柱を示す3コマのイメージ図（AI生成イラスト）

根拠・出所

実際に起きた事案

侵入経路のデータ

IDの不正利用への対策は、アカウント・権限・認証の節で扱います。

公的機関が示す対策

更新前の証跡保全

更新前の証跡保全（調査用ログなどの保存）の呼びかけは、確認できた範囲では、特定の製品の脆弱性についてのものです。

いずれも特定の製品の件で、製品を問わない一般的な手順として公的機関が示した文書は、確認できていません。ほかの製品でも同様の対応が必要かは、各製品の開発元の案内を確認してください。

対策の柱

• 貸与機器を含むIT資産の洗い出し：外部公開システムとVPN機器を台帳で一覧にする
• パッチの適用：脆弱性情報の収集から適用までの担当と期限を決める
• 更新前の証跡保全：侵害が疑われる場合に、更新前に何を保存するかを決める（公的機関の呼びかけは特定の製品についてのもので、製品ごとの開発元の案内も確認する）

自社で確認すること

• 外部公開システムとVPN機器が、借りている機器も含めて台帳になっているか
• 脆弱性情報の収集からパッチ適用までの担当が、自社・委託先・グループ会社で決まっているか
• 侵害が疑われるときに、更新やパッチ適用の前に何を保存するかを決めているか

親記事の6ステップでは、ステップ1（持っているものを知る）とステップ2（入口を固める）にあたります。

API・Web・クラウド保存領域のアクセス制御不備を防ぐには？

API（システム同士をつなぐ窓口）を、非公開・内部向けのものも含めて一覧にし、ログイン後も「その人にそのデータを見る権限があるか」を毎回確認し、短時間の大量アクセスを制限し、クラウドの保存領域の閲覧設定を定期的に点検します。

図4：API・Web・保存領域の原因と、起きうること、対策の柱を示す3コマのイメージ図（AI生成イラスト）

根拠・出所

実際に起きた事案

次の2件は、公式発表に、APIの権限不備と、保存領域の設定不備が書かれた事案です。

公的機関が示す対策

PPC WARNINGの事例9「APIが悪用される事例」（2026年10月7日の改訂で追加）は、ログインした後にURLや会員IDなどの値を書き換えると、他のユーザーの情報を取得できた事案の型です。原因と対策例は次のとおりです。

報告事案を類型化したもので、個別の公表事案との対応は示されていません。

ほかの公的機関の記載は次のとおりです。

対策の柱

• APIの棚卸し：非公開・内部向けのAPI、スマホアプリが使うAPI、旧バージョン、検証環境も含めて一覧にする。使っていないAPIは、停止または制限する。公開しているアプリが使うAPIは、2026年8月以降のログに不審なアクセスがないかも確認する（NICTの推奨）
• 権限確認（認可）：リクエストごとに、そのユーザーがそのデータを見てよいかを確認する。SQLインジェクションやSSRFなどの脆弱性も点検する
• アクセス回数制限：短時間の大量アクセスを制限する
• 保存領域の閲覧設定の定期点検：閲覧できる範囲を、定期的に確認する手順を決める

自社で確認すること

• 非公開・内部向けも含めてAPIの一覧があり、定期的に棚卸ししているか
• 使っていないAPIや検証環境を、停止または制限しているか
• SQLインジェクションやSSRFなどの脆弱性を、点検したか
• 公開しているアプリについて、2026年8月以降のアクセスログ・APIログ・認証ログに、不審なアクセスがないか確認したか
• ログイン後にIDを書き換えても、他人のデータが返らないことを確認したか
• 短時間の大量アクセスを制限する仕組みがあるか
• クラウドの保存領域の閲覧設定を、定期的に確認する手順があるか

親記事の6ステップでは、ステップ1（持っているものを知る）とステップ2（入口を固める）にあたります。

アカウント・権限・認証はどう守る？

多要素認証（パスワード以外でも本人確認する仕組み）、最小権限（必要な範囲だけ権限を付与すること）、不要アカウントの無効化、SaaS連携アプリの検証、認証情報（APIトークンなど）の有効期限管理を組み合わせます。

根拠・出所

実際に起きた事案

民間企業の調査・観測

公的機関が示す対策

PPCの多要素認証の例示について

• PPCは、2026年10月7日の「大規模な漏えい等事案を踏まえた対応について」（別紙）で、多要素認証の導入を例示しています。ただし、ガイドラインの見直し予定の内容を先取りして示したもので、2026年10月23日時点で確定していません
• 多要素認証が法的に求められていると断定はできません。例示のすべてを講じなければ法違反になるとは限りませんが、現行の安全管理措置は必要です。PPC WARNINGは、対策が不十分な場合、安全管理措置（個人情報保護法第23条）などの違反と判断される可能性があるとしています

対策の柱

• 多要素認証：社外からのアクセス、管理者権限のログイン、重要なデータへのアクセスから優先する
• 最小権限：管理者権限と各アカウントの権限を、必要な範囲に絞って定期的に棚卸しする
• 不要アカウントの無効化：退職者・異動者・使っていないアカウントを速やかに無効化する。身に覚えのないアカウントや、無効化したはずのアカウントが有効になっていないかも確認する
• SaaS連携アプリの検証：利用中の外部サービスと連携アプリを一覧にし、承認と権限を確認する
• 認証情報（APIトークンなど）の有効期限管理：長期間有効なトークンを避け、漏えいが疑われるものは無効化・再発行できるようにする

自社で確認すること

• 社外から使うシステムと管理者権限のログインに、多要素認証を使っているか
• 管理者権限と各アカウントの権限を、必要な範囲に絞り、定期的に棚卸ししているか
• 退職者・異動者・使っていないアカウントを、速やかに無効化する手順があるか
• 身に覚えのないアカウントや、無効化したはずのアカウントが有効になっていないか確認したか
• 従業員が承認した連携アプリを、一覧で確認できるか
• APIトークンなどの認証情報に有効期限を設け、漏えいが疑われるときに無効化・再発行できるか

親記事の6ステップでは、ステップ2（入口を固める）にあたります。

委託先経由の漏えいへの備えは？

委託先の状況を契約の前後で把握し、渡す情報を必要最小限にします。

図5：委託先・サプライチェーンの原因と、起きうること、対策の柱を示す3コマのイメージ図（AI生成イラスト）

根拠・出所

実際に起きた事案

公的機関が示す対策

NCOは、自社だけでなく委託先を含むサプライチェーン全体で安全性を確保する観点が重要としています。攻撃者は比較的防御が弱い委託先を足掛かりに侵入し、標的の企業へ広げる手口を使うことがあるとして、委託先企業と「共に管理する」という認識で安全管理措置を講じることを求めています。次の4観点は、NCOが挙げた実施方法の例です。個人データの取扱いを委託する場合の委託先の監督（個人情報保護法第25条）は、これとは別に求められます。

公的機関の調査

対策の柱

• 委託先の状況把握：再委託先を含めて一覧にし、取扱状況を継続的に確認する。重要な委託先を洗い出し、定期的にリスクを評価する。クラウドサービスは、個人データの取扱いの委託に当たるかを確認し、当たる場合は委託先として扱う（当たらない場合も、安全性や設定を確認する）
• 契約：情報の取扱方法、アクセス権とログの管理、漏えい時の報告義務を定める
• 共有情報の最小化：渡す情報を必要最小限にし、業務終了後のデータ削除を確認する

自社で確認すること

• 委託先の一覧があり、再委託先も含まれているか
• 重要な委託先を洗い出し、定期的にリスクを評価しているか
• 利用中のクラウドサービスが、個人データの取扱いの委託に当たるかを確認しているか
• 委託契約に、情報の取扱方法、アクセス権とログの管理、漏えい時の報告義務を定めているか
• 契約後も、委託先の取扱状況を定期的に確認しているか
• 委託先に渡す情報を必要最小限にし、業務終了後の削除を確認しているか

親記事の6ステップでは、ステップ5（外部とAIのルールを決める）にあたります。委託先の洗い出しは、ステップ1（持っているものを知る）とも重なります。

生成AIへの入力による漏えいはどう防ぐ？

使ってよいAIサービスと入力してよい情報を決め、許可されたAIを実際に使える状態にし、従業員に教育します。

図6：生成AIへの入力の原因と、起きうること、対策の柱を示す3コマのイメージ図（AI生成イラスト）

根拠・出所

実際に起きた事案

• 閲覧の可能性：RIZAPは、運営事業者以外の第三者による閲覧と学習利用の可能性はないと確認したとしていますが、運営事業者の役職員による閲覧の可能性は9月3日時点で確認中としています。10月23日時点で続報は確認できていません
• RIZAPの再発防止策：許諾していない生成AIサービスの業務利用禁止の改めての周知、教育、アクセス権限と利用環境の点検、AIマネジメントシステムの導入検討

公的機関が示す対策・手引書

対策の柱

• ルール整備：使ってよいAIサービスと、入力してよい情報・いけない情報を文書にする
• 代替手段の提供：許可されたAIサービスを、従業員が使える状態にする
• 教育：利用ルールと、許可されたAIの使い方を従業員に伝える

自社で確認すること

• 使ってよいAIサービスと、入力してよい情報が、文書になって従業員に伝わっているか
• 許可されたAIサービスを、従業員が実際に使えるか（禁止だけになっていないか）
• 生成AIの利用ルールについて、従業員に教育しているか

親記事の6ステップでは、ステップ5（外部とAIのルールを決める）にあたります。

侵入後の被害拡大を抑えるには？

保有する個人データを減らし、バックアップを元の環境から切り離し、ログ（操作の記録）を保管しておきます。

図7：原因への対策と、侵入された場合の被害拡大を抑える備えを二つの層で示すイメージ図（AI生成イラスト）

根拠・出所

不要データの削除とログの保管

バックアップの切り離し

NCOは「バックアップデータについても適切に保護する」としています。バックアップの切り離しは、次の2つの資料に記載があります。

バックアップは、暗号化や削除に備えて復旧するための対策で、データの持ち出しそのものを止める対策ではありません。

対策の柱

• 不要データの削除：利用目的を終えた個人データを削除し、保有の必要性を確認する
• バックアップの切り離し：バックアップを、攻撃を受けた環境とは別の場所（オフラインを含む）に保存し、バックアップ自体も適切に保護する
• ログの保管：ログを一定期間保管して改ざんや不正消去から保護し、異常を確認する。検知したときの対応態勢も決める

自社で確認すること

• 利用目的を終えた個人データを削除する運用があり、保有データの必要性を確認しているか
• バックアップを、元の環境から分離した場所（オフラインを含む）に保存し、その保存先も保護しているか
• ログを一定期間保管し、改ざんや不正消去から保護しているか
• 保管したログで、不審なアクセスや大量データ取得などの異常を確認しているか
• 異常を検知したときの対応態勢（担当と手順）が決まっているか

親記事の6ステップでは、ステップ3（被害を広げない）にあたります。異常を検知したときの対応態勢は、ステップ6（体制を整える）とも重なります。

ランサムウェアの仕組みや被害の流れについて詳しく知りたい方は、ランサムウェア攻撃とは？で解説しています。

まとめ

情報漏えいへの備えは、誤送付、システムの脆弱性、APIのアクセス制御不備、アカウント管理、委託先、生成AIの利用といった原因への対策に加えて、侵入された場合の被害拡大を抑える備えが重要です。この記事では、これらを7つの観点で整理しました。

• 誤交付・誤送付：確認手順の文書化、宛先確認、事例の共有。PPCの年次報告では誤交付と誤送付が直接受付分の約74%（直接受付分の集計。病院・薬局の書類の誤交付を含む）
• 外部公開システム・VPN：貸与機器を含むIT資産の洗い出しとパッチ適用。更新前の証跡保全は特定の製品についての呼びかけ
• API・Web・クラウド保存領域：APIの棚卸し、認可の確認、アクセス回数制限、閲覧設定の定期点検
• アカウント・権限・認証：多要素認証、最小権限、不要アカウントの無効化、連携アプリの検証、認証情報の有効期限管理。PPCの例示は見直し予定の内容を先取りしたもの
• 委託先・サプライチェーン：状況把握、契約、共有情報の最小化。NCOの4観点は対策例
• 生成AIへの入力：ルール整備、代替手段の提供、教育。代替手段の根拠は手引書の著者の見解
• 侵入後の被害拡大：不要データの削除、バックアップの切り離し、ログの保管。バックアップの根拠は中小企業向け資料と警察庁

着手の順番は、IPAの10月9日の文書では、ログとアカウントの異常確認や未適用パッチの確認などの点検が先で、その後に対策です。各節の「自社で確認すること」を見て、できていない項目から点検を始めてみてください。

---

出典一覧

1. 「令和7年度 年次報告」 — 個人情報保護委員会
2. 「病院・診療所及び薬局における要配慮個人情報を含む個人データの漏えい等事案を踏まえた個人データの適正な取扱いについて（注意喚起）」（2024-09-25）
3. 「個人情報保護法 ヒヤリハット事例集」 — 個人情報保護委員会
4. 「ガバメントソリューションサービスへの不正アクセスによる職員等の個人情報の漏えいの可能性について」 — デジタル庁（2026-09-11）
5. 「当社が運営するアンケートサイト「infoQ」への不正アクセスによる個人情報漏えいに関するお詫びとお知らせ（第2報）」 — GMOリサーチ＆AI（2026-10-14）
6. 「WARNING〜不正アクセスによる個人データ漏えい防止のための注意喚起〜」 — 個人情報保護委員会（2024-12-11、2026-10-07改訂）
7. 「不正アクセスによる漏えい等の事案を踏まえた対応について」 — 内閣官房国家サイバー統括室（2026-10-09）
8. 「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」 — 情報処理推進機構（2026-10-09）
9. 「直近で相次いでいる国内組織における不正アクセスに関する注意喚起（JPCERT-AT-2026-0030）」 — JPCERT/CC（2026-10-08、2026-10-09更新）
10. 「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」 — 警察庁（2026-09）
11. 「国内で相次ぐWebシステムからの情報漏えい～ラックの観測から見える変化と、企業が今とるべき対策」 — 株式会社ラック（2026-10-15）
12. 「Critical Zero-Day Vulnerabilities Exploited in Citrix NetScaler ADC, Gateway」 — CISA（2026-09-27、2026-10-09更新）
13. 「Palo Alto Networks社製PAN-OS GlobalProtectのOSコマンドインジェクションの脆弱性（CVE-2024-3400）に関する注意喚起」 — JPCERT/CC（2024-04-13、2024-04-25更新）
14. 「連続不正アクセス事案の攻撃手法に関する調査」 — JPCERT/CC（2026-10-15）
15. 「【注意喚起】相次ぐ情報漏洩、その原因の一つは「アプリ解析からのサーバ攻撃」― AIで高度化する脆弱性探索、Androidアプリを手がかりにしたA2B攻撃に注意 ―」 — NICT CYNEX 脅威情報分析チーム LETTICE（2026-10-13）
16. 「【注意喚起】相次ぐ情報漏洩、その原因の一つは「アプリ解析からのサーバ攻撃」（詳細資料）」 — NICT CYNEX 脅威情報分析チーム LETTICE（2026-10-13）
17. 「株式会社トイポにおける不正アクセスに伴う当社お客さま情報の漏えいについて」 — JR九州フードサービス（2026-10-13）
18. 「当社サービスにおける個人情報漏えいのおそれに関するお知らせとお詫び」 — 株式会社HANOWA（2026-10-19、2026-10-20更新表示）
19. 「委託先への不正アクセスに起因するお客さまのシステム障害、情報漏えいに関するお詫び」 — 日本電気株式会社（2026-10-20）
20. 「Defending SaaS-based applications against ShinyHunters OAuth abuse」 — Microsoft（2026-07-13）
21. 「「中小規模事業者における個人情報等の安全管理措置に関する実態調査」の令和７年度調査結果について」 — 個人情報保護委員会事務局（2026-03-30）
22. 「当社における外部生成AIサービスへのお客様情報の誤ったアップロードに関するお詫びとお知らせ」 — RIZAP（2026-09-03）
23. 「生成AIサービスの利用に関する注意喚起等（別添1）」 — 個人情報保護委員会（2023-06-02）
24. 「生成AIおよびAIエージェントを安全に活用するための手引書（第1版）」 — IPA 産業サイバーセキュリティセンター 中核人材育成プログラム9期生（2026-07-31）
25. 「大規模な漏えい等事案を踏まえた対応について（注意喚起）」 — 個人情報保護委員会（2026-10-07）
26. 「中小企業の情報セキュリティ対策ガイドライン 第4.0版」 — 情報処理推進機構（2026-03-27）
27. 「サイバー攻撃の被害に係る企業・団体を対象としたアンケート調査結果及び対策」 — 警察庁（2026-01）