検索ブランド相談室 | 検索と評判の専門メディア
無料相談

企業の情報漏えいが相次ぐのはなぜ？ 5年前との比較で見えたAI時代の“守る場所”の変化

部署：広報・PR担当者部署：経営者・責任者レベル：実践 公開日 2026.10.09　更新日 2026.10.18
企業のPCや業務用端末が並ぶオフィス写真に、情報漏えいで守る場所が変わったことを伝えるコピーを重ねたアイキャッチ

［独自調査］ Report ID: SBR-2026-037

公開日：2026年10月9日　著者：菊地 将

要旨

2021年に情報漏えいを公表した116社と、2026年に公表した106社を比較。Web・EC・会員サイトで起きた割合は55％から34％に下がり、社内システムやSaaS・クラウドなどWeb以外は34％から57％に増えました。情報漏えいが起きる場所がWebサイトから社内システムやクラウド、外部サービスへ広がった実態が明らかになりました。

監修: 菊地 将（リブランディング株式会社）

企業による情報漏えい・不正アクセスの公表が相次いでいます。顧客情報の流出、アカウントの乗っ取り、委託先への不正アクセスなどが連日のように報じられ、「なぜ今、これほど情報漏えいが目立つのか」と感じている担当者は多いはずです。AIの普及で、情報漏えいの起き方そのものが変わったのではないか、という疑問もあるでしょう。

そこで、2021年と2026年に日本の民間企業が公式に公表した情報漏えいを、同じ基準で比較しました。あわせて、情報漏えいを公表した企業のWebサイトと技術構成も、100項目あまりにわたって外から調べています。

分かったのは、情報漏えいが起きた場所と原因の構成が、5年前から大きく変わっていたことです。Web・EC・予約・会員サイトで起きた情報漏えいの割合は55％から34％に下がり、社内システム、委託先、SaaS・クラウド、メール・アカウントなどWeb以外の場所は34％から57％に上がりました。AIそのものが情報を漏らしているというより、AI時代に企業のデジタル活用の範囲が急速に広がり、守るべき場所が増えたことが、いまの情報漏えいの構造に影響している可能性が高いと考えられます。この記事では、4つの調査の結果を順に示し、最後に自社で点検したい6つの項目を整理します。

結論：情報漏えいの起きる場所は、Webサイトから会社のデジタル環境全体へ広がった

いま相次いでいる企業の情報漏えいを、Webサイトの脆弱性や人的ミスだけで捉えるのは難しくなっています。4つの調査から分かったことは、次のとおりです。

  • Webサイトと技術構成の調査：メール、通信、CMS、ソフトウェア情報、外部サービスなどを広く比べても、情報漏えいを公表した企業だけが外から見て明確に弱いとは言えませんでした。
  • 情報漏えい・セキュリティ事故の原因の調査：公式発表に書かれた原因は、認証、委託先、社内ツール、トークンの管理など、Webサイトの外から見えない場所にありました。
  • 情報漏えいが起きた場所の比較：Web・EC・予約・会員サイトの割合は55.2％から34.0％に下がりました。社内システム、委託先が運用するシステム、SaaS・クラウド、メール・アカウントなどを合わせた割合は、33.6％から57.5％に上がっています。
  • 原因の構成の比較：脆弱性の悪用（26.7％→11.3％）と誤送信・誤操作（12.9％→3.8％）の割合が下がり、委託先・SaaS・取引先起因（9.5％→19.8％）が上がりました。

この4つを重ねると、AI時代の情報漏えいは、AIが直接漏らすというより、AIを含む急速なデジタル化で、企業が使うシステム、サービス、アカウント、データの置き場が増え、従来の管理体制では守る範囲が広がりすぎていることが背景にある可能性が高いと言えます。したがって企業に必要なのは、AIだけを禁止することでも、Webサイトだけを守ることでもありません。会社が使うデジタル環境全体を、管理の対象として捉え直すことです。

調査対象と方法：2021年の116社と2026年の106社を比較

この節では、結果を読む前提として、何をどのように比べたのかを示します。今回の調査では、情報漏えいの変化を「実際に何が起きたのか」と「企業のWebサイトに共通する特徴があるのか」の2つの側面から検証しました。

まず、2021年と2026年に公表された情報漏えい事案を比較し、発生場所と原因の変化を調べました。さらに、2026年に情報漏えいを公表した企業と比較企業のWebサイトを調査し、公開されている技術構成に違いがあるかを確認しました。

比較したのは、日本国内の民間企業が個人情報の漏えい、またはそのおそれを公表した事案です。2021年は1〜12月、2026年は1月から10月上旬までに初めて公表されたものを対象にしました。調査期間が異なるため、年間の発生件数ではなく、発生場所と原因の構成比を比較しています。対象の規模は、次の表のとおりです。

項目 2021年 2026年
対象企業数 116社 106社
独立した事案の数※ 109件 101件

※同じ委託先で起きたセキュリティ事故に複数の企業が巻き込まれた場合は、1件として数えています。

企業や委託先などの公式発表（公式サイトの保存版を含む）を確認できた事案を対象とし、原因は公式発表に記載された内容を分類しました。続報は別の事案として数えていません。

Webサイトの調査は、2026年10月に実施しました。情報漏えいを公表した企業64社（トップページを取得できた61社）と、同業種などから選んだ比較企業195社（同194社）の公開サイトを、同じ方法で観測しています。

Webサイトと技術構成を比べても、情報漏えいを公表した企業だけが弱いとは言えなかった

最初に確かめたのは、情報漏えいを公表した企業のWebサイトに、外から見て分かる弱さがあるかどうかです。調べたのは、メールの送信元認証、HTTPS通信の設定、CMS、ソフトウェアやバージョン情報の露出、旧ライブラリの痕跡、外部ドメインや第三者スクリプトの数、フォームの設置、お知らせの更新頻度など、100項目あまりです。メールやHTTPSの設定だけでなく、サイトを動かしている技術構成と外部サービスの使い方まで、広く見ています。

比較は2段階で行いました。まず、同業種などから選んだ企業と比べました。次に、業種に加えて、IR（投資家向け情報）・採用ページの有無やサイト内リンク数など、Webサイトの特徴が近い企業とも比べています。2段階にしたのは、情報漏えいを公表した企業にはIRページを持つ割合が49％と、比較企業の13％より高く、サイトの大きな企業が多かったためです。

次の表は、主な観測項目の割合を3つのグループで並べたものです。左から順に、情報漏えいを公表した企業、同業種などから選んだ比較企業、業種とサイトの特徴が近い比較企業です。

観測項目 情報漏えいを公表した企業（61社） 同業種などから選んだ比較企業（194社） 業種・サイト規模が近い比較企業
メールの送信元認証（SPF）を設定している 90％ 93％ 96％
メールの送信元認証（DMARC）を設定している 77％ 63％ 78％
なりすましメールの受信拒否・隔離まで設定している（DMARC） 25％ 13％ 27％
ブラウザに安全なHTTPS接続を要求する設定（HSTS） 43％ 24％ 47％
他サイトの枠内への表示を制限する設定 48％ 26％ 45％
不正なスクリプトの読み込みなどを制限する設定（CSP） 18％ 13％ 19％
情報セキュリティの認証制度（ISMS）に関する記載がある 18％ 6％ 11％
WordPressを使っている 39％ 68％ 54％
CMSの種類が判別できない、または独自開発 44％ 20％ 34％
ソフトウェア名やバージョンの手掛かりをサーバー情報から読み取れる 77％ 97％ 94％
バージョン情報が外から分かる 23％ 50％ 34％
古いライブラリの痕跡がある 52％ 66％ 79％

同業種などから選んだ比較企業と単純に比べると、情報漏えいを公表した企業のほうが各種の設定を入れている割合が高く見えます。ところが、サイトの特徴が近い企業と比べると、メールの送信元認証、安全なHTTPS通信を徹底する設定、他サイトの枠内への表示制限、不正なスクリプトの制限といった設定の差はほぼなくなりました。情報セキュリティの認証制度に関する記載はやや高いままですが、差は誤差の範囲でした。

CMSやソフトウェアの情報では、特徴が近い企業と比べても、公表企業のほうがバージョン情報を外から読み取れる割合や、古いライブラリの痕跡が見つかる割合が低い傾向でした。外部ドメインの数（中央値は公表企業4、比較企業6）や、第三者のスクリプトを読み込むドメインの数（同1、2）も、公表企業のほうが少ない結果です。問い合わせ窓口（84％と85％）、資料請求（23％と25％）、会員登録（5％と7％）への導線の有無はほぼ同じで、お知らせの更新頻度にも大きな差はありませんでした。

ここから言えるのは、広くWebと技術構成を比較しても、情報漏えいを公表した企業だけが外から見て明確に弱いとは言えなかった、ということです。むしろ、バージョン情報の露出や古いライブラリの痕跡、外部ドメインや第三者スクリプトの数では、公表企業のほうが少ない傾向でした。外部サービスを多く使っている企業ほど情報漏えいを起こす、という関係も見えていません。

原因は、外から観測できる場所の外にあると考えるほうが自然です。そこで次に、各社が公表した原因そのものを読み、どこに問題があったのかを調べました。

情報漏えいの原因は、Webサイトの外から見えない場所にあった

調べたのは、2026年に各社が公表した情報漏えい・セキュリティ事故の原因です。公式発表を読むと、原因は認証情報、秘密情報の管理、社内ツールの公開状態、委託先の作業手順といった、外から見えない場所に書かれていました。次の表は、事案の種類ごとに、公式発表に書かれた原因をまとめたものです。

事案の種類（2026年） 公式発表に書かれた原因
EC運営企業 従業員にEC運営会社を装うフィッシングメールが届き、偽サイトでスタッフアカウントの認証情報を入力。二段階認証が設定されておらず、パスワードも十分な強度ではなかったと公表
ソースコード管理で起きた事例（2件） GitHubのアクセストークンが設定ファイルに直接書かれた状態で運用され、第三者に取得・利用された（個人情報がリポジトリ内に保存されていた）。別の企業では、GitHubの認証情報が漏えいし、第三者がリポジトリをコピーした
社内のデータ分析ツールで起きた事例 インターネットに直接公開されていた社内のデータ分析ツールの既知の脆弱性に対し、修正プログラムの適用が間に合わず侵入された
Web保守の委託先で起きた事例 委託先のバックアップ作業後、ファイルがWebサーバーに残り、URLを直接指定すると認証なしでダウンロードできた
委託先の管理システムで起きた事例（3社が公表） 委託先の問い合わせ管理システムの管理サイトに第三者が不正ログイン。3社がそれぞれ、同じ委託先で起きたセキュリティ事故として公表した
会員向けの機能で起きた事例 設定上の不備で、登録ユーザー間でユーザー情報が相互に閲覧できる状態だった
生成AIへの情報入力で起きた事例 従業員が、個人で使っている外部の生成AIサービスに、データ集計作業中、対象データを誤ってアップロードした

表の事案はいずれも、コーポレートサイトのヘッダー設定やCMSの種類を見ても分かりません。実際の原因は、認証、委託先、SaaS、社内ツール、トークンなど、Webサイトを外から見ただけでは分からない場所に多く存在しました。

前の節で、外から観測したWebの設定には、情報漏えいを公表した企業の特徴が見えませんでした。この節の結果は、その理由を示しています。論点が、ID、トークン、委託先、社内ツールといった「会社が使うデジタル環境の管理」にあったからです。では、こうした場所での情報漏えいは、5年前と比べて広がっているのでしょうか。次に、情報漏えいが起きた場所を2021年と比べました。

5年前より、情報漏えいが起きた場所はWebから社内システムやSaaSへ広がった

調べたのは、情報漏えいが起きたシステムの種類です。2021年の116社と2026年の106社について、同じ基準で分類して比べました。まず図で全体の傾向を見て、そのあとに表で内訳を確かめます。

2021年と2026年の情報漏えい発生場所を比較。Web・EC等の割合は55.2％から34.0％に減少し、社内システムやSaaSなどWeb以外は33.6％から57.5％に増加

公式発表を確認できた企業を比較すると、Web・EC・会員サイトでの情報漏えいの割合は低下し、社内システムやSaaSなどWeb以外の場所の割合が上昇しています。

次の表は、図の内訳です。右端の「差」は、2026年の割合から2021年の割合を引いたものです。四捨五入前の値で計算しているため、表示された割合どうしの差と0.1ポイントずれる行があります。

情報漏えいが起きた場所 2021年（116社） 2026年（106社） 差
Web・EC・予約・会員サイト 55.2％（64社） 34.0％（36社） −21.2ポイント
社内システム（社内ネットワーク、ファイルサーバーなど） 6.0％（7社） 14.2％（15社） +8.1ポイント
SaaS・クラウド 9.5％（11社） 15.1％（16社） +5.6ポイント
メール・アカウント 5.2％（6社） 10.4％（11社） +5.2ポイント
委託先が運用するシステム 10.3％（12社） 13.2％（14社） +2.9ポイント
VPN・ネットワーク機器 0.9％（1社） 1.9％（2社） +1.0ポイント
コード管理・API 1.7％（2社） 1.9％（2社） +0.2ポイント
生成AI 0％（0社） 0.9％（1社） +0.9ポイント
端末・媒体・紙・店舗 10.3％（12社） 5.7％（6社） −4.7ポイント
判別できない 0.9％（1社） 2.8％（3社） +2.0ポイント

Web・EC・予約・会員サイトの割合は、55.2％から34.0％へ21.2ポイント下がりました。一方、社内システム、委託先、SaaS・クラウド、メール・アカウント、VPN・ネットワーク機器、コード管理・API、生成AIを合わせた割合は、33.6％（39社）から57.5％（61社）へ23.9ポイント上がっています。増え方が目立つのは、社内システム、SaaS・クラウド、メール・アカウントです。

SaaS・クラウドでの情報漏えいが2026年に初めて現れたわけではありません。2021年にも、クラウド型の営業管理・顧客管理システムの設定不備により、第三者がアクセスできる状態になった事案が複数公表されています。変わったのは、こうした場所が占める割合です。Webサイトも、情報漏えいが起きる場所のひとつであり続けています。2021年、2026年とも、EC運営企業で、サイトの脆弱性を足掛かりに決済アプリケーションが改ざんされたと公表した事例があります。

5年前は半数強がWeb・EC・会員サイトで起きていましたが、2026年にはその割合は3分の1に下がり、会社が使うデジタル環境の複数の場所に分散しています。

では、こうした場所の変化は、原因の構成にも表れているのでしょうか。次に、原因を2021年と比べました。

脆弱性・誤操作の割合は下がり、委託先・SaaS起因は増えた

調べたのは、各社の公式発表に基づく情報漏えいの主な原因です。同じ分類で並べると、構成比は次のとおり変わりました。

情報漏えいの主な原因を2021年と2026年で比較。脆弱性の悪用と誤送信・誤操作の割合が下がり、委託先・SaaS・取引先起因の割合が上がったことを示す図

情報漏えいの主因の構成比を比較すると、脆弱性の悪用と誤送信・誤操作の割合が低下する一方、委託先・SaaS・取引先起因の割合は上昇しています。

次の表は、図の内訳です。「原因を公表していない」事案も、1つの区分として含めています。右端の「差」は四捨五入前の値で計算しているため、表示された割合どうしの差と0.1ポイントずれる行があります。

原因（各社の発表に基づく主因） 2021年（116社） 2026年（106社） 差
脆弱性の悪用 26.7％（31社） 11.3％（12社） −15.4ポイント
委託先・SaaS・取引先起因 9.5％（11社） 19.8％（21社） +10.3ポイント
認証情報・アカウント侵害 10.3％（12社） 14.2％（15社） +3.8ポイント
誤送信・誤操作 12.9％（15社） 3.8％（4社） −9.2ポイント
設定不備・誤公開 12.1％（14社） 4.7％（5社） −7.4ポイント
マルウェア・ランサムウェア 1.7％（2社） 4.7％（5社） +3.0ポイント
開発・システム不具合 5.2％（6社） 5.7％（6社） +0.5ポイント
内部不正 1.7％（2社） 1.9％（2社） +0.2ポイント
紛失・盗難 0.9％（1社） 0.9％（1社） +0.1ポイント
原因を公表していない 19.0％（22社） 33.0％（35社） +14.1ポイント

原因を公表した事案だけで比べても、委託先・SaaS・取引先起因は11.7％から29.6％へ、脆弱性の悪用は33.0％から16.9％へと、同じ方向に変化しています。

認証情報・アカウント侵害は10.3％から14.2％へ動いたものの、企業数が少なく、誤差の範囲です。2021年にも認証情報の事案は一定数ありました。APIキーやアクセストークン、GitHubなどのコード管理が関わった事案は、2021年も2026年も各2社です。2021年には、外部のコード検査ツールの侵害をきっかけに、GitHub上のソースコードへアクセスされた事案もありました。

原因を公表していない事案の割合は、2021年の19.0％から2026年の33.0％に上がっています。公表の姿勢や、公式発表を確認できた事案の集まり方の違いも影響していると考えられ、原因の分からない情報漏えいが実際に増えたかどうかは読み取れません。

これらを整理すると、脆弱性の悪用と誤送信・誤操作の割合は下がり、委託先・SaaS・取引先起因の割合は上がっており、原因の構成そのものが5年前から変化していたことになります。この3つは、差が偶然とは言いにくい変化でした。認証情報・アカウント侵害は一定数が続いており、2026年に急に現れた原因ではありません。

情報漏えいの発生場所がWebサイト以外へ広がるとともに、委託先やSaaSなど、自社で直接管理しにくいサービスが原因となる事案の割合も増えています。Webサイトの対策だけでは対応できない原因が、相対的に大きくなっています。ここまでの4つの調査結果を重ねたとき、AI時代との関係はどう読めるのでしょうか。

AI時代の情報漏えい対策は、なぜWebサイトを守るだけでは不十分なのか？

ここまでの4つの調査結果は、AI時代の情報漏えいを読むうえで、次のように整理できます。

  • 100項目あまりのWebサイトと技術構成を調べても、情報漏えいを公表した企業だけが外から見て明確に弱いとは言えませんでした。
  • 実際の原因は、認証、委託先、SaaS、社内ツール、アカウント、トークンなど、Webサイトの外にありました。
  • 守るべき場所はWebサイトの外へ分散していると考えられるため、Webサイトだけを見ていては全体をつかめません。
  • 脆弱性や誤操作の割合が下がり、委託先・SaaS・取引先起因の割合が上がっているため、自社だけで完結しない管理が求められます。
Webサイト中心のセキュリティ管理と、社内システム、SaaS、委託先、アカウント、コード管理、生成AIを含むデジタル環境全体の管理を比較した概念図

この変化は、AIの普及を含む企業のデジタル化によって、利用・管理するシステム、サービス、アカウント、データの置き場が増えたことが背景にあると示唆しています。SaaS、クラウド、社内システム、外部サービス、外部委託、多数のアカウント、コード管理、API、データ連携、生成AI。業務で使うデジタル環境が増えるほど、守るべき場所そのものが増えます。

統計的に因果関係を証明したものではありませんが、情報漏えいが起きた場所の変化と原因の構成の変化は、同じ方向をそろって指しています。

海外の調査も、同じ方向を示しています。Verizonの2026年版報告では、第三者が関わる漏えいが前年より60％増えて全体の48％に達しました。会社の端末でAIを日常的に使う従業員（会社が許可したものか否かを問わない）の割合も、前年の15％から45％に上がっています。

IBMが2026年7月に公表した報告では、調査対象の20％超の組織がAIモデルやAIアプリケーションを標的にした漏えいを経験していました。主な原因は、周辺のAPI・アプリ・プラグインの弱点（27％）やAIの処理基盤のクラウド設定の誤り（27％）でした。AIの利用そのものより、AIにつながる周辺のシステムの管理が問われています。

ただし、これらの海外調査と今回の国内の調査は、調査の対象と集め方が違うため、単純には比べられません。たとえばVerizonの調査で最も多い侵入経路はソフトウェアの脆弱性の悪用（31％）ですが、今回の国内の事案では脆弱性の悪用の割合が下がっています。そのうえで、委託先・外部サービスの関与が重要になっている点は共通しています。

生成AIへの情報入力による漏えいも、補足として確認できています。ある企業では、従業員が個人で利用していた外部の生成AIサービスに、業務で扱う個人情報を誤ってアップロードした事案が公表されています。業務の委託元である健康保険組合と共済組合も、同じ事案を別に公表しています。ただし、AIとの関係はこうした直接の事例にとどまらず、企業が守るべきデジタル環境の広がりという構造の側にあると読むのが適切です。

情報漏えいは、システム上の問題だけでは終わりません。事故の公表をきっかけに顧客や取引先の不安が広がり、SNSや口コミサイトなどで企業の情報管理への疑問が生じることもあります。一度広まった情報は、検索結果や生成AIの回答を通じて、その企業を調べる人の目に触れ続ける可能性があります。情報漏えい対策は、顧客情報を守ると同時に、企業の信用や評判を守るための取り組みでもあります。

会社が使うデジタル環境全体を点検する6項目

この節では、実際に起きた原因に照らして、自社で点検したい項目を6つに整理しました。情報漏えいを公表した企業がこれをしていなかったという意味ではありません。

企業の情報漏えい対策で点検したい6項目を整理した図。IT資産の棚卸し、多要素認証、委託先管理、脆弱性対応、トークン・生成AIの管理、ログ・初動対応を示す

次の表は、点検項目ごとに、確認する内容と、それに対応する事案の例を並べたものです。

点検項目 確認する内容 対応する事案の例
①IT資産・SaaS・委託先・公開システムの棚卸し 外部に公開しているサイト・システム、使っているSaaS、個人情報を預けている委託先を一覧にし、管理者を決めているか 委託先の管理サイトへの不正ログイン、休眠・旧環境、予約・会員サイトの脆弱性
②管理者アカウントと多要素認証 メール、VPN、クラウド、SaaS、管理画面の管理者アカウントで、パスワード以外の確認（多要素認証）を必須にしているか。フィッシングを報告する窓口があるか フィッシングによる認証情報の入力（二段階認証未設定の公表あり）
③委託先・SaaSの管理 誰にどのデータを預け、誰がアクセスできるか。情報漏えいが起きたときの連絡期限と窓口が契約で決まっているか 同じ委託先で起きたセキュリティ事故が3社に及んだ事案、Web保守委託先のバックアップ残存
④パッチ・脆弱性・古い環境 利用製品とバージョン、修正の適用期限、社内用ツールの公開状態、バックアップや休眠環境の公開有無 社内のデータ分析ツールの既知の脆弱性、ECの決済アプリ改ざん
⑤トークン・GitHub・生成AI ソースコードや設定ファイルにパスワード・トークンが書かれていないか。外部の生成AIに入れてよい情報のルールがあるか GitHubのトークン直書き、個人利用の生成AIへのアップロード
⑥ログ・監視・初動 重要なシステムのアクセス記録を保存し、不審なログインや大量取得に気づけるか。情報漏えいが疑われたとき、停止・調査・通知を誰が判断するか 外部からの連絡で情報漏えいを知った事案が複数

これらは、公的機関の指針とも方向が合っています。米国のCISAは多要素認証の導入を、米国のNISTはサイバーセキュリティフレームワーク2.0で資産の把握と管理を取り上げ、サプライチェーンのリスク管理、パッチ管理、インシデント対応についても、それぞれ指針を示しています。日本ではIPAの「中小企業の情報セキュリティ対策ガイドライン」が、経営者が取り組む項目を整理しています。

各項目は「はい／いいえ／分からない」で確認できます。「分からない」と答えた項目は、それ自体が棚卸しの対象です。

まとめ

5年前より、情報漏えいが起きる場所は社内システム、SaaS・クラウド、メール・アカウントなどへ広がり、原因も委託先・SaaS・取引先起因が増えました。Webサイトを外から調べても、情報漏えいを公表した企業だけが弱いとは言えませんでした。

守るべき場所が広がった以上、会社が使っているSaaS、クラウド、社内システム、アカウント、委託先、コード、生成AIまで管理の対象に含める必要があります。まず、使っているものを一覧にし、管理者アカウントの多要素認証を確認することから始められます。前の表の①と②にあたる項目です。

参考文献・データ元

この記事で参照した情報を確認できます。

‹ 親記事: 口コミ・風評対策の全体像｜取り組むべき5つの領域と、まず押さえておきたい基礎知識

関連記事

関連テーマ

AIO SEO MEO 採用改善 オウンドメディア集客

関連記事

資料ダウンロードはこちら