セキュリティインシデント徹底検証｜2026年9月の国内34件の原因と、同じ穴をClaude Codeで探した実測

2026年9月のセキュリティインシデント一覧：34件で何が起きたのか？

2026年9月1日から10月4日までに公表・続報が出た国内のセキュリティインシデントは、主なものだけで34件ありました。交通・物流・金融・小売・研究機関・Webサービスと業種は問わず、規模は数十人から2,000万件超までさまざまです。外部からの攻撃だけでなく、設定変更やメールの誤添付による事案も含みます。

下の表は、各組織が公表した件数（「確認」と「可能性」を区別）と、2026年10月4日時点で公表されている原因の要約です。件数の単位はアカウント・人・件・予約とばらばらで、同じ委託先の事案もあるため、合計はしていません。

出回っている要約には、公式発表と違う点もありました。タイムズカーの「約160万件」は画像の枚数ではなく本人確認書類が漏えいしたアカウント数で、Unni の日本の対象者は日本語の告知に約4.8万名と書かれています。LEAN BODY の約44万はアカウント数（退会者を含み、人数はこれより少ない）で、Gポイントの約7万件は会社の説明では個人を特定できない番号です。

原因は何だったのか？事案ごとに分かっていること

34件のうち、組織が原因の種類まで公表したのは14件、「脆弱性」とだけ書いたのが3件、攻撃の種類だけを公表したのが2件、残る15件は未公表・調査中です。公表された原因の中身は、既知の脆弱性の修正の遅れ、委託先・予約基盤の侵害、実装や設定変更の不備、人為ミスでした。以下、公式発表と、報道・専門家・外部観測で指摘されている点を分けて書きます。

1つの既知脆弱性から複数社へ：BIツール Metabase

今回もっとも多くの組織に被害が広がったのは、BIツール（社内のデータを集計・可視化するツール）Metabase の脆弱性です。CVE-2026-72898 は、認証なしで使えるパスワードリセット用の窓口から任意のSQLを注入され、管理者権限を奪われる脆弱性で、深刻度はCVSS 10.0です。開発元は2026年8月6日に修正版を出した時点で、すでに悪用を確認していました。

• LEAN BODY：公式発表でツール名をMetabaseと明記し、「当該ツールの脆弱性情報を定期的に確認し、必要な更新を実施することができなかったこと」も要因だった可能性が高いとしています。最初の不正アクセスは8月11日（修正版の公開から5日後）、修正版への更新は9月9日でした（LEAN BODY、9月15日）
• VOISING：ツール名は非公表ですが、「BIツールに存在した既知の脆弱性に対する修正の適用が、脆弱性情報の公開から攻撃までの時間軸に間に合わなかった」と書いています。侵入は8月10日でした（第四報、9月30日）。セキュリティブログの piyolog は、Metabase の同じ脆弱性が悪用された可能性が高いと推測しています
• ApplyNow（吉野家・はなまる・井筒まい泉ほか）：採用管理のSaaSを提供するApplyNowで「データ分析ツールの脆弱性を悪用した第三者による不正アクセス」が8月9日〜9月7日に起きました（吉野家HDほか、9月30日）。ツール名は公表されていませんが、時期と言い回しはLEAN BODYと重なります。同じSaaSを使っていた8市（富士・福山・大阪・島田・入間・一宮・橿原・所沢）も職員採用の受験者情報の被害を公表しています（piyologのまとめ）

吉野家・はなまるのデータは、2024年6月に契約を終えたあともApplyNow側に残っていました。吉野家HDは「契約終了に伴い応募者の情報が同データベースから消去されるものと認識」していたが、実際の運用は違ったと書いています。社内向けの分析ツールがインターネットから届く状態だったこと、修正が数日〜1か月遅れたこと、消えているはずのデータが残っていたことの3つが重なった事案です。

サポート終了の部品が動いていた：タイムズカー

タイムズカーは10月4日時点で原因を公表しておらず、外部専門機関がフォレンジック調査中です。会社は「2週間程度を目処に」詳細を案内するとしています。

外部からの指摘として、ITジャーナリストの山口健太氏は、タイムズカーのWebサイトに2010年ごろに使われ現在はサポートが終了したフレームワーク「Seasar」「Teeda」の名前が見え、読み込んでいるjQueryは2008年公開の1.2.6だったと書いています（Yahoo!ニュース エキスパート、9月29日）。当研究所もInternet Archiveに保存された10月1日時点の会員向け問い合わせ画面で、Teedaの名前空間と「org/seasar/teeda」のJavaScriptの読み込みを確認しました。Seasarプロジェクトは多くのプロダクトについて2016年9月26日をもってEOL（サポート終了）としており、Teedaはその例外に入っていません。

ただし、サポート終了の部品が動いていたことと、それが侵入口だったことは別の話です。会社は原因として認めておらず、Teeda固有の既知の脆弱性も公的なデータベースでは確認できませんでした。言えるのは「サポートが終わった部品を10年近く使い続ける運用だった」というところまでです。退会した会員の免許証画像なども、税法やなりすまし対策を理由に7年間保管していたと会社はFAQで説明しています。

自社の実装・設定・変更の不備

• ベネフィット・ワン：外部からの攻撃ではなく、2025年6月の改修でアンケート結果のダウンロード機能に生じた「プログラムの条件設定不備」が原因です。2025年10月の社内調査で把握しながら解消されず、2026年7月30日に利用企業1社1名からの連絡で表に出ました（9月30日）
• チケプラ：9月28日に負荷を軽くする目的で行った「Webページのキャッシュに関する設定変更」で、ログイン後の画面が別の利用者に表示されました。不正アクセスではありません
• 集英社：「CMSの設定の不備に起因するAPI認証情報を狙った攻撃を受け、特権ユーザーアカウントが不正に作成され」たと、原因の連鎖を公表しています（9月28日）。公表された時刻から計算すると、受信者からの通報（9月9日14:53）の後も約2時間、不正なアクセスが続いていました
• Unni（カンナムオンニ）：相談履歴を照会するAPIへの不正アクセスで、翌日には別の経路から再侵入されました。対策として「認証プロセスの強化」「権限検証ロジックの再整備」を挙げており、APIの認可の不備を突かれたとみられます【推定】
• 手間いらず：本体は手法の公表を控えていますが、取引先の穴吹エンタープライズが、手間いらずからの報告として「過去に提供されていたインストール型サービスを構成する機能の一部にセキュリティ上の問題」があったと公表しました。提供を終えた古い製品の機能が、外から使える状態で残っていたとみられます
• JAEA：原因は未公表です。共同通信は「何者かが利用者IDを作りサイトにログインした後、不正な方法で登録情報をダウンロードしていたとみられる」と報じました。対象の「JRR-3 RING」はメールアドレスだけで利用者登録できる仕組みで、報道どおりなら、自分で作ったアカウントから他人のファイルを取れる認可の不備があった可能性があります【推定】

委託先・予約基盤の侵害

• LEGOLAND Japan：ホテルの予約プラットフォームを運営するAmadeus IT Groupへの不正アクセスで、1,557件の予約の連絡先が対象になりました。公式サイトの予約リンクはAmadeus傘下TravelClickの予約エンジンを指しており、海外のホテルも同じ時期に同じ基盤の事故を宿泊客に通知しています
• キューサイ：保管・配送の委託先ニチレイ・ロジスティクス九州が、7月13日のニチレイグループへのサイバー攻撃の影響を受けたものです。ニチレイについては、ランサムウェアグループRansomHouseがリークサイトで犯行を主張したとITmediaが報じ、日本ハッカー協会の杉浦隆幸氏はITmediaの番組で、公開情報からサポート切れのOSや古いPHP、開いていたFTPを弱点の候補に挙げています（侵入経路として確認されたものではありません）。ニチレイは侵入経路を開示していません
• 手間いらず（前出）：宿泊施設30前後が影響を告知しており、予約内容を使ったWhatsAppなどでの詐欺メッセージが先に表面化しました

人為ミス：＠cosme、京都サンガF.C.

＠cosmeは、従業員が外部のファイル転送サービスで個人情報を含むファイルを受け渡した際、公開設定の不備でURLを知る人なら誰でも見られる状態が約20分続きました。京都サンガF.C.は、取引先へのメールにファンクラブ会員の情報ファイルを誤って添付し、11名に送信しました。どちらもサイバー攻撃ではありません。

「脆弱性」までは公表：Gyazo、ムラウチドットコム、オズモール

Gyazoは「画像アップロードサーバーに存在した脆弱性を悪用し、第三者が当社のシステム上で任意のコマンドを実行」し、データベースに到達されたと公表しています（第一報）。脆弱性の種類やCVE番号は公表されていません。セキュリティ企業BreachLockの創業者兼CEOであるSeemant Sehgal氏は、アップロード用のサーバーが数億件のデータを持つデータベースに近かった点を「内部の分離の弱さ」を示すものだと指摘しています（eSecurity Planet）。なお、Internet Archiveの記録では、アップロード用サーバーの前段のWebサーバーは事件の約3か月前に更新されており、サポート切れのソフトを放置していた形跡は見当たりませんでした。

ムラウチドットコムは「Web システムの一部に存在していた脆弱性を悪用されたことを起点として不正アクセスを受け、その後、複数のシステムへ不正にアクセスされた」、オズモールは「当該脆弱性への対策を実施」とだけ書いています。どちらも製品名や脆弱性の種類は公表されていません。

原因が未公表の事案で分かっていること

• セイコーマート：アプリのサーバーを経由して会員情報のサーバーへ到達されました。最初の異常は9月24日夜の不正な退会処理1件で、手法は「警察および関係機関と連携」を理由に開示を差し控えています
• ヤマト運輸・佐川急便・日本郵便：3社とも原因は調査中で、同一犯や共通の手口を示す公式発表・報道は確認できませんでした。佐川急便のスマートクラブは2025年8月と10月にもリスト型攻撃を受けていますが、会社は今回とは別の事案としています
• 三井不動産：「一部のシステムに係る資格情報が不正に利用され」たと公表しています。どのシステムの資格情報が、どう盗まれたかは書かれていません
• ニッポンレンタカー：9月26日の41名と10月1日の55名は「異なる手法」と書いています。1件目では対象者にパスワードの再設定を求めています
• 東京メトロ：配信停止中のメールアドレスを保管したサーバーに「国外からと思われる」アクセスがあり、「委託先を含めた原因の調査」を進めています
• 京王グループ：ランサムウェアであることは公表済みで、侵入経路・漏えいの有無は調査中です。10月3日時点でリークサイトへの掲載は確認できませんでした
• 第一生命・イープラス・らしんばん・ロート製薬・Gポイント・あいの風とやま鉄道・クオカード：原因の記載は「第三者による不正アクセス」程度か、調査中です。あいの風とやま鉄道では、利用者が意図しない予約の取り消しや、利用者が行っていない予約まで確認されています

共通する穴は何か？34件を原因で分けると

原因が公表された事案を並べると、AIでなければ突けない新しい穴はありませんでした。目立つのは、インターネットに出ていた社内ツールの修正の遅れ、委託先に残っていたデータ、設定変更の検証不足です。未公表の15件の原因が分かれば分布は変わりますが、少なくとも公表された範囲では「以前から指摘されてきた穴」がそのまま突かれています。

当研究所の見解として、34件から読み取れる共通点は次の4つです。

攻撃にAIは使われているのか？

攻撃側がAIを使っていることは、AnthropicやGoogleの脅威レポートが実例と数字で示しており、今回の事案の背後でもAIや自動化が使われている可能性は高いと考えます。ただし、被害組織や警察が「AIが使われた」と確認・公表した例は、2026年10月4日時点ではまだありません。分かっている範囲でいえば、AIは新しい種類の穴を生んだのではなく、基本の穴を見つけて突くまでを速く・安くしています。

Anthropic：作戦の過半数をAIが実行・統括、手口は「おなじみ」

Anthropicが2026年9月に公表した脅威レポートは、2025年12月〜2026年8月に遮断した悪用事例をまとめたものです。掲載した作戦の過半数はAIが直接実行または統括していたとしたうえで、攻撃そのものは見慣れた手口だったと書いています。

「このレポートのどの作戦も、防御側が見たことのない全く新しい手法には依存していなかった。攻撃そのものはおなじみのもので、盗まれた認証情報、パッチ未適用の境界機器、露出したサービス、SQLインジェクション、フィッシングだった」

"None of the operations in this report depended on some entirely novel technique that defenders have never seen." "The attacks themselves are familiar, involving stolen credentials, unpatched edge devices, exposed services, SQL injection, and phishing."

Anthropic — Detecting and countering misuse of AI: September 2026

同じレポートには、ShinyHuntersの関係者とみられる攻撃者が180万本のAndroidアプリを解析してハードコードされた鍵を集めた事例や、盗んだ開発者トークン1つからクラウドの管理者権限まで約3時間で到達した事例が載っています。人間は「攻撃対象の設定と持ち出したデータの確認」に残っていた、とも書かれています。

Metabase：「相当なLLMの能力が必要だった」

LEAN BODYなどが被害を受けたBIツールMetabaseの開発元は、8月3日に自社のクラウドがゼロデイ（修正前の脆弱性）で攻撃された件について、攻撃の複雑さとコードベースへの理解の深さから「相当なLLMの能力が必要だったと考えている」と書きました。攻撃初期のリクエストには、LLMのガードレールを回避しようとした形跡のあるUser-Agentが使われていたといいます（Metabase公式ブログ、2026年8月27日）。

「この攻撃の複雑さ、必要とされた当社コードベースの知識、2つの入れ子の依存関係の挙動から、この攻撃には相当なLLMの能力が必要だったと考えている」

"Due to the complexity of this attack, the required knowledge of our codebase, and the behavior of two nested dependencies (Toucan2 and Honey SQL), we believe this attack required significant LLM capabilities."

Sameer Al-Sakran（Metabase）— August 2026 Security Vulnerability: What happened?

これはMetabase自身への最初の攻撃についての見立てで、国内の被害組織を攻撃した者と同じか、その攻撃にAIが使われたかは分かっていません。修正版と攻撃手法が公開された後は、AIがなくても同じ穴を大量に探せます。ただ、ゼロデイの発見から武器化までにAIが使われ、その脆弱性が数日のうちに日本の複数の組織に届いた、という流れは今回の事案でもっともAIに近い接点です。

速くなったのは「公開から悪用まで」

• Google傘下のMandiantは、脆弱性が悪用されるまでの平均時間を推計マイナス7日としています。修正版が出る前の悪用が日常的になっているということです。一方で同じ報告は「2025年は侵害がAIの直接の結果だった年ではない」とも書いています（M-Trends 2026）
• VulnCheckによると、2026年上半期に悪用が確認された脆弱性の23.43%は、CVEの公開日以前に悪用の証拠がありました（State of Exploitation 1H-2026）
• Google Threat Intelligence Groupの集計では、悪用された脆弱性は2025年の月平均10.5件から、2026年1〜8月は月平均18件に増えました（2026年10月1日）
• 警察庁の令和8年上半期の報告では、脆弱性を探す不審なアクセスが前年比50.7%増え、ランサムウェアの被害報告は半期で過去最多の123件、侵入経路はVPN機器が約5割でした。AIについては「サイバー攻撃がより高速かつ大規模に行われるリスクが懸念される」という書き方です（警察庁）

当研究所の見解では、今回の一連の事案にも攻撃の自動化やAIの利用が含まれている可能性は高いと考えます。ただ、公表された原因を見る限り、突かれたのは「AIでなければ見つからない穴」ではありません。サポート切れのソフト、修正の遅れ、設定や権限の不備、古い機能の放置といった、以前から指摘されてきた穴です。AIによって変わったのは、それが見つかって突かれるまでの時間で、「基本の穴を塞ぐ」締め切りが前倒しになったと捉えるのが実態に近いはずです。

基本の穴は、AIでどれだけ見つかるのか？Claude Codeで実測

公表・指摘された原因と同じ種類の穴を架空のコードに8つ仕込み、Claude Code（Anthropic製のAIコーディングツール）にレビューさせました。3モデルとも7〜8件を見つけ、1回あたり約7〜47円、約24〜68秒でした。古いライブラリは npm audit が5.5秒・無料で54件の既知脆弱性を挙げました。守る側にとって安く速いということは、ソースコードや公開アプリを手に入れた攻撃者にとっても同じです。

検証の条件

• 対象：架空の「配送問い合わせサービス」（Node.js / Express。server.js 104行、config.js 16行、package.json）。実在のサービスとは無関係で、鍵はダミーです
• 仕込んだ穴：認証なしで鍵と環境変数を返すデバッグ用URL、SQLの文字列連結、連番の照会APIが認証なしで氏名・住所・電話を返す、照会APIに回数制限がない、CSV一括ダウンロードで他社のIDを指定できる、署名鍵とクラウドの鍵の直書き、既知脆弱性のある古いライブラリ
• 問題のない処理（ログイン、自分の住所の変更など）も混ぜました
• 指示の要点：「本番公開前のセキュリティレビューとして、個人情報の漏えいにつながる問題点を重大度順に、ファイル・行・悪用されると何が起きるか・修正方法つきで挙げる」
• 環境：Claude Code v2.1.288、各モデル1回、2026年10月4日実施。リポジトリ外の空のフォルダで実行し、プロジェクト固有の設定の影響を避けました

claude -p --model claude-sonnet-5-5 --effort medium --max-turns 3 --output-format json < prompt.txt

結果

同じ package.json に npm audit をかけると、5.5秒で11パッケージ（critical 1・high 7・low 3）、計54件の既知脆弱性が出ました。直接依存の5つ（mysql2 2.3.0、jsonwebtoken 8.5.1、axios 0.21.1、lodash 4.17.15、express 4.17.1）がすべて該当し、mysql2 には遠隔からコードを実行される critical の脆弱性が含まれていました。

想定と違った点

• Haiku 4.5 は、照会APIが「連番で総当たりできる」ことは指摘しましたが、回数制限が無いことには触れませんでした。修正案も番号のランダム化か認証の追加までで、大量取得を止める仕組みは出てきませんでした
• Opus 5.5 は mysql2 の修正版を「3.9.8 以降」と答えましたが、npm audit で確認すると 3.22.0 未満に残る high の脆弱性があり、修正版は 3.24.5 でした。モデルが学習した時点より後に出た脆弱性情報は、AIのレビューだけでは拾えません。Sonnet 5.5 は「CVE番号は私の記憶に基づくため要確認」と自分で注記していました
• 3モデルとも、仕込んでいない妥当な指摘も出しました。トークンに有効期限がない（3モデル）、ログインの試行回数に制限がない（Sonnet・Opus）、CSVに数式を仕込める（Sonnet・Opus）などです

この検証は、ソースコードをAIに渡した「守る側の条件」です。攻撃者は通常ソースコードを持たないので、そのまま攻撃側の能力とは読めません。ただし、公開アプリを分解して鍵を探す手口は前節の Anthropic のレポートに実例があります。AIのコードレビューを社内で回すときの注意点はClaude Codeの必須セキュリティ8選、権限の絞り方は権限設定のガードレールにまとめています。

自社では何から確かめればよいか？

公表された原因をそのまま点検項目にすると、次の5つになります。どれも新しい技術は要らず、「やると決めて、期限を切る」ことが中心です。自社でシステムを開発していない士業事務所や中小企業は、委託先・SaaS事業者にこの5点の管理状況を確認するのが現実的な第一歩です。

このうち2・3・5は、前節のようにAIのコードレビューと依存関係のチェックを組み合わせると、初回の洗い出しを短時間で済ませられます。ただし、AIの知識には期限があるので、最新の脆弱性情報は npm audit や公式の勧告で確かめてください。Claude Code そのものの安全な使い方はClaude Codeとは（入門ガイド）でも説明しています。

まとめ