最近は、毎日のように情報漏えいのニュースを目にするようになりました。見聞きするのは「何万件の情報が漏れた」という結果が中心ですが、その中身を知れば、何が起きているのか、なぜそうなったのかという背景まで理解できます。そこで、2026年9月1日から10月14日までの約1か月半に発表された国内の漏えいを集めて全体の傾向を見たうえで、原因が比較的詳しく発表された3件を取り上げました。発表に書かれていない部分も多いため、同じ種類のインシデントで一般にどういうことが起こり得るかを補いながら解説します。あわせて、その攻撃に AI が使われていたのかも考えます。
国内の情報漏えい（2026年9月〜10月）の概要
この約1か月半（2026年9月1日〜10月14日）に、企業や自治体が自ら発表した国内の漏えいは318件ありました。「漏えいのおそれ」「調査中」と発表したものも含みます。この318件は、漏えいが発生した組織ごとに数えた数字で、本記事では「発生ベース」と呼びます。同じ侵害から広がったものをまとめ、侵害の事案ごとに数え直すと166件になります。こちらを「事案ベース」と呼びます。
2つの数字がずれるのは、1つのサービスが侵害されると、そのサービスを使っていた企業や自治体のそれぞれで漏えいが発生するためです。最も大きかったのは、自治体の防災メールなどを一斉配信するアルカディアのサービス「SpeeCAN RAIDEN」で、アルカディア自身と、利用していた自治体と消防の74者が漏えいのおそれを発表しました（アルカディアの発表）。発生ベースでは75件、事案ベースでは1件です。以下、断りがない限り事案ベースの166件で数えます。
規模別の内訳
166件を、発表された漏えいの規模で分けると次のようになります。規模は、漏えいした（おそれを含む）対象の数として発表された数字のうち、最も大きいものです。人数で発表するところもあれば、顧客情報の件数やアカウントの数で発表するところもあるので、桁の目安として見てください。
100万件以上は14件で、最大は画像共有サービス Gyazo のユーザーデータ約2,362万件でした。一方で、3割にあたる52件は件数を発表していません。調査が終わっていないものと、件数を出さないと決めたものの両方が含まれます。
発生箇所
漏えいがどこで起きたかは、事案ベースと発生ベースで大きく変わります。
事案ベースでは、委託先や SaaS（インターネット経由で使う業務サービス）、クラウドで起きた侵害は22%です。これが発生ベースでは56%に上がります。件数としては自組織で起きるものが多い一方で、1件の侵害が数十の組織に広がるのは委託先・SaaS・クラウドの側です。宮崎県は委託先の NECネッツエスアイの先でアルカディアのシステムが使われていて、自社が直接契約していない会社の侵害で、漏えいを発表することになりました。
原因の全体像
手段の内訳
手段の分類には、漏えいの集計に広く使われている枠組み VERIS を使いました。1件のインシデントが複数の手段で起きることもあるため、発表に書かれた手段をすべてカウントしています。たとえば、盗まれた VPN（社外から社内ネットワークにつなぐ仕組み）のアカウントで侵入され、ランサムウェア（ファイルを暗号化して身代金を要求するウイルス）に感染した場合は、不正侵入とマルウェアの両方をカウントします。
最も多いのは外部からの不正侵入で、166件のうち106件、6割強を占めます。次がミスの39件で、誤送信や設定の誤りが中心です。一方で、ランサムウェアと明記したものは9件にとどまりました。国内の発表は「不正アクセス」とだけ書くことが多く、不正侵入106件のうち58件は手段が分かりません。
初期侵入の手段
攻撃によるインシデント122件のうち、初期侵入（Initial Access。攻撃者が最初にシステムへ入り込む段階）について、攻撃方法の詳細を発表したのは53件、43%でした。
攻撃方法が分かる53件では、盗まれた認証情報（IDとパスワード）の利用が25件、脆弱性（ソフトウェアの欠陥）の悪用が21件で、この2つが中心です。ただし規模で分けると顔ぶれが変わります。漏えい規模が10万件以上の32件では、脆弱性の悪用が11件、仕様の不備を突かれたものが4件あるのに対して、盗まれた認証情報は3件だけでした。認証情報が盗まれた例は、大学のメールアカウントがフィッシングで乗っ取られるような、規模の小さいインシデントが中心です。漏えい規模が100万件以上の14件には、ミスや内部不正を手段とするものが1件もありません。大きな漏えいは、外部から公開システムの欠陥を突かれて起きています。
代表的な3つのインシデント
ここからは、規模や広がりが大きく、原因が比較的詳しく発表された3件を取り上げます。旅行予約サイトの skyticket、企業のコミュニティサイトを提供する SaaS の Commune、自治体とガス会社向けの IT サービス会社である両毛システムズです。3件とも、初期侵入の細部までは発表されていません。発表に無い部分は、同じ種類のインシデントで一般にどう起きるかを補って説明します。補った部分は、その事例で実際にそうだったとは限りません。
事例1 skyticket（アドベンチャー）
アドベンチャーは10月9日、経路の違う3件の不正アクセスを分けて発表しました（アドベンチャーの発表）。経路①は管理機能を不正に操作され、そこから他のサーバーとクラウド上のデータに入られたもの、経路②は業務管理システムの脆弱性を悪用されたもの、経路③はバスの予約完了ページがログインしなくても表示できる状態で、第三者に機械的に閲覧されたものです。
仕組みが最もはっきりしているのは経路③です。予約完了ページは、氏名、生年月日、連絡先、乗車便、同行者といった予約の中身をそのまま表示する確認画面です。サーバーは、/bus/complete?id=123456 のような URL の番号で予約をデータベースから取り出して表示しています。開いた人が予約者本人かどうかを確かめていなければ、番号を 123457、123458 と変えるだけで他人の予約が次々に開け、プログラムで繰り返せば大量に集められます。氏名や連絡先と、いつどの便に乗るかがそろえば、本物の予約に見せかけた詐欺メールやフィッシングに使えます。この種の欠陥は IDOR（Insecure Direct Object Reference）と呼ばれ、認証（あなたは誰か）ではなく認可（あなたはそのデータを見てよいか）の確認が抜けたものです。ログインせずに開けるページ自体は珍しくありませんが、その場合は推測できない長いランダムな文字列を URL に使うのが普通です。
被害が最も大きかった経路①は、管理機能に入った手段も、そこから広がった手段も発表されていません。一般に、管理機能が起点になる形は3つあります。管理者の ID とパスワードを盗まれる認証の突破、一般利用者の画面から管理用の機能を呼べてしまう認可の欠陥、そして管理機能が受け取ったデータをサーバーが命令として実行してしまう脆弱性です。
3つ目は、たとえば管理画面にあるバナー画像のアップロード機能で起きます。サーバーは、アップロードされたファイルを Web から見える場所に保存し、URL を開いた人に返します。このとき、ファイルの中身が本当に画像かを確かめていないと、攻撃者は画像の代わりに、サーバー上で動くプログラムをアップロードできます。保存先の URL を開くと、サーバーはそのファイルを画像として返すのではなく、プログラムとして実行してしまいます。こうして置かれたプログラムを Webシェルと呼び、攻撃者は以後、それを通じてサーバー上で任意のコマンドを実行できます。今回の166件でも、Gyazo は画像アップロードサーバーの脆弱性で任意のコマンドを実行されています。サーバーの設定ファイルには、データベースのパスワードやクラウドのアクセスキーが入っていることが多く、それを読み出せば、正規のアプリケーションと同じ権限で他のサーバーやクラウドのデータに入れます。これが横展開（Lateral Movement）の典型的な形で、経路①の「管理機能から他のサーバーとクラウドへ」という書き方とも矛盾しません。
経路②の業務管理システムは、製品名も脆弱性の種類も出ていません。一般には、修正パッチが出ている脆弱性を更新しないまま使っているところを狙われる例が多く、今回の166件でも、分析ツール Metabase の脆弱性が公表されていたなかで侵入された NEXT STAGE の例があります。
対策は経路ごとに異なります。経路③はサービス提供者の問題で、表示する前に本人の予約かを確かめることです。ログインしている会員なら、ログイン中の会員番号と予約の持ち主が一致するかをサーバー側で照合します。メールのリンクのようにログインなしで開かせる場合は、連番の予約番号の代わりに推測できない長いランダムな文字列を URL に使い、有効期限を設けるか、予約番号に加えて登録した電話番号やメールアドレスの入力を求めます。経路①には、業務に要らない管理機能をインターネットに公開しないこと、管理者のログインに多要素認証を設定すること、サーバーに置くクラウドのアクセスキーの権限を必要な範囲に絞ることが有効です。経路②は、使っている製品の脆弱性情報を確かめ、更新を先延ばしにしないことです。
事例2 Commune（コミューン）
Commune は、企業がファンや顧客と交流するコミュニティサイトを作るための SaaS です。10月5日18時ごろから不正アクセスを受け、10月6日にコミューンが検知して全コミュニティを停止しました。コミューンは、攻撃者がシステムの不備を突いて非公開コミュニティの招待リンクを不正に取得し、一般会員として登録したほか、管理者になりすまして会員情報を閲覧・取得したと発表しています（コミューンの発表）。この発表の対策の欄を見ると、「ログイン用の署名鍵の更新」という項目があります。署名鍵の中身を書いたのは利用企業のちとせグループで、攻撃者が「全コミュニティ共通のログイン用の署名鍵」を入手していたと発表しています（ちとせグループの発表）。
署名鍵は、ログインした利用者に発行する証明書（トークン）が本物であることを示すための鍵です。多くの Web サービスは、ログインに成功した利用者に「この人は会員番号○○の管理者である」と書いたトークンを発行し、以後の操作のたびにそれを受け取って誰の操作かを判断します。サーバーはトークンに秘密の鍵で署名を付け、受け取るたびに署名を確かめます。逆に言えば、署名鍵を持っている人は、パスワードを知らなくても管理者と書いたトークンを自分で作れます。正規のログインを経ずに管理者の権限を得る、権限昇格（Privilege Escalation）です。鍵をどう入手したのかは発表されていません。一般には、ソースコードや設定ファイルに鍵が直接書かれていて外部から読めた、推測しやすい短い文字列を鍵にしていた、別の脆弱性で設定を読まれた、といった形で漏れます。
被害が24の利用企業・団体に広がったのは、鍵が全コミュニティで共通だったためです。SaaS では、1つのシステムを複数の利用企業（テナント）で共有するのが普通で、テナントごとに鍵を分けるかどうかは設計で決まります。鍵が1つなら管理は楽ですが、1つ漏れれば全テナントの管理者になれます。コミューンは10月7日にも、停止中に残っていた通信経路から不正な登録と閲覧を受けています。多数のテナントを抱えるサービスでは、すべての経路を一度に確実に遮断するのが難しいことが分かります。
対策の多くはサービス提供者の仕事で、署名鍵をテナントごとに分けること、鍵をソースコードや設定ファイルに直接書かず、クラウドの鍵管理サービスなどで管理すること、管理者の操作には追加の確認を求めることです。利用企業の側にできるのは、SaaS に登録させる会員情報を必要な項目に絞ることと、事業者がテナントをどう分けているかを契約の前に確かめることです。
事例3 両毛システムズ
両毛システムズは、自治体やガス会社のシステムを受託している IT サービス会社です。8月12日、外部の第三者が VPN のアカウントを悪用して社内ネットワークに侵入し、一部のファイルサーバーでランサムウェアを実行しました。異常に気づいたのは2日後の8月14日未明で、きっかけは死活監視（サーバーやサービスが動いているかを定期的に確かめる監視。英語では health check）でした（両毛システムズ第3報）。サーバーの停止をきっかけに異常が確認された、という書き方で、侵入そのものを検知したとは書かれていません。
VPN アカウントをどう入手されたのか、多要素認証を設定していたのかは発表されていません。一般に、VPN のアカウントが悪用される経路は4つあります。VPN 機器の脆弱性を突かれて機器に保存された認証情報を抜き出される、退職者や保守業者のアカウントが残っていて使われる、フィッシングや情報を盗むマルウェアで従業員の ID とパスワードを取られる、推測しやすいパスワードを外から何度も試される、の4つです。機器の脆弱性の場合、修正パッチを適用しても、すでに抜かれた認証情報を変えなければ使われ続けます。どの経路でも、多要素認証があれば ID とパスワードだけでは入れません。
VPN を通った攻撃者がファイルサーバーまで届いたことから、社内のネットワークが分けられておらず、VPN の利用者がファイルサーバーに直接届く作りだった可能性があります。社内でも通信のたびにユーザーとその権限を確かめる「ゼロトラスト」は、こうした横展開を防ぐための考え方です。
漏えいのおそれがあるのは、両毛システムズの社内に残っていた委託元のファイルでした。大東ガスは、自社の顧客情報システムは両毛システムズの社内ネットワークと分離されていて侵入されていないとしつつ、過去に業務で扱った顧客情報を含むファイルが同社の社内に「残存」していたと説明しています（大東ガスの発表）。委託業務では、作業のために委託元のデータを受け取ることがよくあります。作業が終わったあとに消す決まりが無い、または消したことを確認するプロセスが無いと、ファイルは委託先に残り続けます。委託元が自社のシステムをいくら分けて守っていても、委託先に預けたデータは委託先のセキュリティで守られることになります。
委託先の側の対策は、VPN に多要素認証を設定すること、使っていないアカウントを消すこと、VPN の利用者が届く範囲を必要なサーバーに絞ることです。委託元の側では、委託先に預けたデータの一覧を持ち、業務が終わったら削除したことを確かめる手順を契約に入れておくことが、自社のシステムを守るのと同じくらい意味を持ちます。
対策
3つの事例から言える対策
3件で初期侵入に使われたのは、外から触れる管理機能、テナント共通の鍵、VPN のアカウントでした。どれも、侵入されたあとに本来は届くことのない場所まで届いています。利用者として取り組める対策をまとめると次のようになります。
| 対策 | 事例との対応 |
|---|---|
| 外部から触れるシステムを洗い出し、業務に要らない管理機能は公開しない | skyticket 経路① |
| VPN、管理者、外部公開システムに多要素認証を設定する | 両毛システムズ、skyticket 経路① |
| 使っていないアカウントを無効にし、退職者や委託先のアカウントを消す | 両毛システムズ |
| ソフトウェアと VPN 機器を更新し、公表された脆弱性を確かめる | skyticket 経路②、両毛システムズ |
| サーバーやアカウントが届く範囲を、業務に必要な範囲に絞る | skyticket 経路①、両毛システムズ |
| 委託先や SaaS に預けたデータの一覧を持ち、業務が終わったら削除を確かめる | 両毛システムズ、Commune |
| どのログを、どれだけ残すかを決めて取る | 3件とも |
公的なガイドライン
何から始めるかを決め、初期の対策を立てるには、国内の公的なガイドラインが使えます。
| ガイドライン | 発行 | 最初に使う部分 | 今回の事例との対応 |
|---|---|---|---|
| 中小企業の情報セキュリティ対策ガイドライン 第4.0版（2026年3月） | IPA | 情報セキュリティ6か条、付録3「5分でできる！情報セキュリティ自社診断」（25項目）、付録7「中小企業のためのクラウドサービス安全利用の手引き」（15項目） | 付録7の No.13 は、サービスの利用を終えたときのデータの扱いを確認する項目で、両毛システムズの件に当たる |
| 直近で相次いでいる国内組織における不正アクセスに関する注意喚起（2026年10月） | JPCERT/CC | 対策の一覧 | 「業務上必要のないサービスや機能（管理機能など）がインターネットに公開されている場合、公開を停止する」。BI ツールや従業員向け管理システムも点検の対象に挙げる |
| 不正アクセスによる漏えい等の事案を踏まえた対応について（2026年10月9日） | 国家サイバー統括室 | 委託先管理と、不要なアカウント・システムの項目 | 「再委託先を含む管理状況を把握する」「業務終了後の委託先でのデータ削除を徹底する」 |
| 不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について（2026年10月9日） | IPA | アカウントと保有情報の点検 | 「作ったはずのないアカウントが存在しないか」の確認と、VPN サービスを含む外部サービスの洗い出し |
| 情報セキュリティ10大脅威 2026 | IPA | 組織向けの順位 | 1位ランサムウェア、2位サプライチェーンや委託先を狙った攻撃、3位に「AIの利用をめぐるサイバーリスク」が初めて入った |
最初の一歩としては、IPA の自社診断で全体を確かめ、クラウドや SaaS を使っていれば付録7のチェックシートを、委託先にデータを預けていれば国家サイバー統括室の委託先管理の項目を当てるのがよいと考えています。
その攻撃は AI によって実行されたのか
166件の発表から AI との関わりを確認できるのは2件でした。1つは RIZAP で、従業員が個人で使っていた外部の生成 AI サービスに、疾患の情報を含むデータを誤ってアップロードしました（RIZAP の発表）。もう1つは攻撃の側で、Commune の利用企業ちとせグループが、「複数のIPアドレスから短時間に大量の操作を同時に行うもの」だったことから、「AI等を用いて自動化された攻撃であったと推定されます」と書いています。
ただし、原因が特定されていないからといって、攻撃に AI が使われていないことを意味するわけではありません。実際には、攻撃者は AI を使っていると考えるのが自然です。事例で見た IDOR を見つけるには、URL の番号を変えて応答を比べる作業を何度も繰り返す必要があります。設定ファイルに書かれた鍵や、更新されていない製品を探すのも同じ種類の作業です。Claude Code のようなコーディングエージェントは、こうした欠陥を開発の段階で見つけるためにも使われていて、同じ力は攻撃者の側でも使えます。
商用の AI モデルには、悪用を防ぐガードレール（安全のための制御）が組み込まれています。ただし、重みが公開されたオープンウェイトのモデルは、微調整（ファインチューニング）によってこの制御を外すことができます。米国の AI 評価機関 CAISI の評価では、DeepSeek R1-0528 は、よく知られた手法で制限を外した悪意ある要求の94%に応じました（米国の比較対象のモデルは8%。NIST CAISI）。
実際の攻撃でも、この使い分けが報告されています。Palo Alto Networks の Unit 42 は2026年7月、攻撃者が欧米のモデルも試したものの、提供側の制御によって攻撃への利用を抑えられたとみられ、安全対策の少ない DeepSeek をオープンソースのエージェント基盤に組み込んで自律的な攻撃に使った事例を報告しました（Unit 42）。CrowdStrike も10月7日、韓国の金融機関を狙った攻撃で、自律型の侵入試験ツール ARTEX の中核に DeepSeek が使われていたと報告しています（CrowdStrike）。
Verizon の年次報告書 DBIR 2026年版は、AI の影響は今のところ既知の手法の自動化と規模の拡大にとどまると見ています（Verizon 2026 Data Breach Investigations Report、p.28）。言い換えれば、今回の166件のような既知の欠陥を、AI でより速く、より多く突けるようになっているということです。発表に AI が出てこなくても、攻撃に AI を使える環境は整いつつあると考えています。
まとめ
昨今のセキュリティインシデントが AI によって実行されたのか、という問いに、公式の情報から答えることはできません。ただ、今回の漏えいの原因になった認可の欠陥、漏えいした認証情報や鍵、更新されていない製品は、どれも AI が攻撃を得意とする領域です。そのうえ、ガードレールのないモデルを攻撃に使う例も報告されています。
代表的な3件では、被害の大きさを決めたのは、初期侵入そのものより、侵入されたあとにどこまで届いたかでした。初期侵入を完全に防ぐことはできません。AI によって欠陥が見つかる速さが上がるほど、外から触れる管理機能や使っていないアカウントを減らし、サーバーや鍵が届く範囲を分け、委託先に預けたデータを消しておくことが、被害を小さくする現実的な手になると考えています。
ProFab では、生成 AI の社内導入と、その利用ルールや環境づくりを支援しています。AI を安全に使える体制を整えたい方は、お問い合わせからご連絡ください。
