Acetyl:Tech
← ブログ一覧

「社内用だから大丈夫」が、いちばん危ない──10月の漏えい連鎖で見えた、3つの入口

情報漏洩セキュリティ不正アクセス委託先管理業務アプリリスク管理経営者向け中小企業

9月の終わりから、大きな会社の個人情報漏えいの発表が相次いでいます。タイムズカーで約660万アカウント、焼肉きんぐのアプリで約1,079万件、ブックオフで約638万人。

そして10月7日から9日までの3日間で、国の機関などから注意喚起が8本出ました。個人情報保護委員会、JPCERT/CC、警察庁、内閣官房の国家サイバー統括室、総務省、経済産業省、IPA、金融庁です。

ニュースを見た方から、こう聞かれます。

「大企業の話でしょう。うちみたいな会社にも関係あるの？」

あります。ただ、「パスワードを強くしましょう」という一般論の話ではありません。

各社の発表と注意喚起を突き合わせると、入口は3つに絞れます。アプリの中の鍵と、画面の裏のAPI。「社内用」の管理画面やBIツール。そして委託先。3つとも、「表には出していないつもり」の場所です。そして3つとも、中小企業にもそのままあります。

この記事では、まず何が起きたのかを各社の発表だけで整理し、注意喚起が何と言っているかを並べます。そのうえで3つの入口を、業者や担当者に聞ける質問の形にします。

うちも、取引先の業務アプリを作り、データに触れる「委託先」です。自分たちの側の話も書きます。

※ お断り：当ブログでは普段 Claude を推奨しており、自社の開発でも使っています。下で、AIを使った開発と鍵の漏えいの数字を引きます。Claude Code に不利な数字も、そのまま載せます。

何が起きたのか──各社の発表だけで整理する

主な事案を、各社が自分で出した発表から並べます。

公表日会社・サービス件数（発表の表現）会社が書いた原因・経路
9/25〜9/29タイムズカー約660万アカウント。うち運転免許証画像などの本人確認書類が漏えいしたアカウントが約160万件「Webシステムに対する外部からの不正アクセス」。手口は書かれていない（調査中）
10/5焼肉きんぐ公式アプリ（物語コーポレーション）10,788,963件アプリの「会員管理システム」への第三者からの不正アクセス。経緯は調査中
10/5大和証券約11万名分の可能性委託先のサーバーへの不正アクセス。「当社のシステムに対する不正アクセスは確認されておりません」
10/6ミスターマックス最大1,735,154人アプリとオンラインストアのサーバーに、「ソフトウェアの機能を不正に利用して」侵入
10/8第一興商約872万4千件のおそれ（従業員の情報約9万3千件を含む）委託先の従業員のPC1台がマルウェアに感染。「当社のシステムへの影響も確認されておりません」
10/8ローソンローソンID 2,155,345件「アプリ上で利用者本人に対し情報を表示するためのセキュリティ機構」が不正アクセスを受けた
10/9ブックオフ6,383,279人（10/13の第2報。会員番号ベースでは6,427,735件）会員管理システムへの不正アクセス。手口は「公表を差し控えます」
10/9skyticket（アドベンチャー）約1,464万件 ほか「一部の管理機能を不正に操作され」、そこからほかのサーバーとクラウドのデータへ
10/9JR東日本・ビューカード・JR九州メールアドレスなど。えきねっと約167万件（最大）、ビューカード約403万件、JR九州Web会員約130万件（最大）IDCフロンティアで起きた不正アクセスに伴い、メール配信に使っていた外部のサービスから漏えいした可能性
10/13銀のさら（ライドオンエクスプレス）最大 約650万件（確定ではない）データの保管を委託していたサーバーの運営会社が、ランサムウェア攻撃を受けた

件数の数え方は、会社ごとに違います。確定した数と「最大」「可能性」「おそれ」、件数と人数が混ざっているので、足し合わせることはできません。

また、JR各社が使っていたメール配信の大元（IDCフロンティア）は、10月14日の発表で、利用者の仮想サーバーから外部への流出はなかったと判断しています。JR各社の発表はそれより前の10月9日のもので、「可能性」としての公表です。

手口は、ほとんど公表されていない

表の右端を見てください。どうやって入られたのかを具体的に書いている会社は、ほとんどありません。 調査中か、「公表を差し控えます」です。

ブックオフの第2報は、その理由も書いています。「具体的なシステム構成、脆弱性、攻撃手法の詳細については、今後の不正アクセスを誘発するおそれがあるため、公表を差し控えます」。書けば、まだ塞いでいない同じ穴を、ほかの攻撃者に教えることになる。もっともな理由です。

これは今回に限った話でもありません。マクニカのセキュリティ研究センターが公開情報を集計したところ、Webシステムからの個人情報の漏えいの公表は、2024年が62件、2025年が84件、2026年は10月6日時点で119件でした。そのうち7月以降の81件では、65件（約8割）が、手口を分類できるだけの説明をしていません。

だから、「この会社は、この手口でやられた」とは、この記事では書きません。 書ける材料がないからです。

手口が分かるのは、2つの資料だけです。JPCERT/CCが10月8日に出した注意喚起と、マクニカの記事（伊藤忠サイバー&インテリジェンス、セキュアスカイ・テクノロジーの専門家との共同執筆）。どちらも、実際の事案対応やログの分析から、攻撃の「型」を書いています。

この型と、各社の発表に残った数少ない言葉を突き合わせたのが、この記事の3つの入口です。

注意喚起は、何と言っているか

10月7日から9日に出た8本を、要点だけ並べます。

日付出したところ誰に向けて要点
10/7個人情報保護委員会個人情報を扱う事業者安全管理措置の見直し案を先取りで提示（多要素認証、EDRなど。確定は来年4月の予定）。不要な個人データの消去。事例集「WARNING」に**「APIが悪用される事例」**を追加
10/8JPCERT/CC国内の組織攻撃の型を公表（9日の更新で4つに）。非公開のものを含むすべてのAPIにアクセス制御を。権限は最小限に、トークンには有効期限を
10/8警察庁企業・団体、個人、本人確認をする事業者ソフトウェアの更新、パスワードの強度、なりすましを防ぐ本人確認の徹底
10/9内閣官房 国家サイバー統括室大量の個人情報を扱う事業者と経営層「いつ攻撃を受けてもおかしくない」前提で。多要素認証。委託先は「委託先企業と共に管理する」
10/9総務省所管の事業者と関係団体統括室と同じ内容。委託先も含めた徹底
10/9経済産業省関係各位トップの主導、脆弱性への早期対応、ゼロトラストへの移行。被害を受けたら担当課へ一報
10/9IPA大量の情報や機微な情報を扱う事業者の経営者外部に公開しているアプリ・サービスの侵害と、アカウントの侵害が起点と推測。ログを直近1か月、次に3か月と段階的に確認。身に覚えのないアカウントがないか。「不要な情報は持たない」
10/9金融庁金融機関など委託先などのリスク管理も含めて点検。オンラインの本人確認で、画像に不自然な点がないか確認を徹底

このほか、デジタル大臣が10月6日の会見で、国民に向けて3つを呼びかけています。パスワードの使い回しをやめる。多要素認証を設定する。メールのリンクは開かず、公式サイトや公式アプリから入る。

読んでみると、ほとんどが「大量の個人情報を扱う事業者」に向けて書かれています。 中小企業に向けたものではありません。だから「うちには関係ない」と読めてしまう。

でも中身を分解すると、規模に関係なく当てはまる入口が3つあります。

3つの入口。①アプリの中の鍵と画面の裏のAPI——アプリを解析して鍵を特定する型、画面にない内部APIを攻撃する型（JPCERT/CC）。②「社内用」の管理画面・BIツール——skyticketは発表で「一部の管理機能を不正に操作され」と書いている。③委託先——大和証券と第一興商は、自社システムへの不正アクセスや影響は確認されていないのに、委託先から顧客情報が漏れた。3つとも、会社が持つお客さんの情報につながっている

入口1：アプリの中の鍵は、隠せない

まず、APIと鍵の話

スマホアプリや、ブラウザで開く業務画面は、それ自体がデータを持っているわけではありません。裏でサーバーに「このデータをください」「これを保存して」と頼んでいます。 この頼み口をAPIと呼びます。

APIを使うときには、たいてい合言葉を添えます。「このアプリからの頼みです」と示すための文字列で、これをAPIキー（鍵）と呼びます。

今回、型として書かれたこと

JPCERT/CCの注意喚起は、「API経由での不正な操作」として、こう書いています。

（a）一般公開しているスマートフォンアプリを解析しAPIのエンドポイントやキーを特定する （b）本来画面操作では実行できない内部APIに対する攻撃 （c）他のシステムの侵害で窃取したAPIキーを使用する

（b）の具体例には、ユーザーの権限の変更や、不正なアカウントの作成などが挙がっています。

つまり、アプリを分解して鍵やAPIの入口を突き止める、画面にボタンがない裏の機能を直接呼ぶ、よそで盗んだ鍵を使う、という型です。

マクニカの記事も、同じ動きを書いています。「スマホアプリを解析してAPIキーを取り出し、正規のアクセスに見える形でAPIを呼び出すケースもあります」。

なぜ、隠せないのか

エンジニアの間では、「画面側のコードに鍵がそのまま書いてあった」は定番の笑い話です。笑って済むのは、他人のアプリだからです。

アプリは、利用者のスマホやパソコンの上で動きます。 配った時点で、中身は相手の手元にある。OWASP（Webセキュリティの国際的なコミュニティ）は、アプリに書き込まれたAPIキーが無料の道具で取り出される例を、典型的な攻撃の筋書きとして挙げています。

「読みにくくしておけばいい」という対策（難読化）もあります。でもOWASPは、難読化などの保護で攻撃は難しくなるが「never impossible」——不可能にはならない、と書いています。マクニカも「コードを最小化・難読化していても、埋め込まれた認証情報は解析によって取得される可能性があります」と明記しています。

数字もあります。

調査対象結果
ウィーン大学などの研究チーム「Leaky Apps」（国際学会 ACM CCS 2025、査読あり）Android・iOSのアプリ 10,331本実際に使える認証情報が、65のサービスにまたがって416件
Cybernews（2025年3月。報道機関の調査チームで、査読はなし）iOSのアプリ 156,080本71%が少なくとも1つの秘密情報を含んでいた。アプリを分解せず、平文のまま見つかっている
Symantec（2022年9月）AWS（クラウド）の認証情報を書き込んだアプリ 1,859本77%が有効な鍵を含んでいた。47%は、クラウドの保管庫（S3）にある大量の非公開ファイルに完全にアクセスできる鍵を含んでいた

鍵は隠せない。守りはサーバー側に置く。上段（よくない作り）：画面側のコードに鍵が入っている→アプリを解析すると鍵が取り出せる→その鍵だけで、画面にない機能まで呼べてしまう。下段（守れる作り）：鍵はサーバー側にだけ置く→画面はサーバーに頼むだけ→サーバーが毎回「この人に、これを許してよいか」を確かめる

AIで作ると、どうなるか

AIに書かせる開発でも、鍵の扱いは問題になっています。

GitGuardian（秘密情報の漏えいを調べている会社）の2026年版レポートでは、Claude Code が関わったコミット（変更の記録）の3.2%に秘密情報が含まれていて、GitHub全体の1.5%より高かった。前年版では、Copilot を使っているリポジトリの6.4%で秘密情報が漏れていて、全体の平均（4.61%）より約4割高かった、としています。

ただし、GitGuardian 自身が、この数字を「道具の欠陥として単純に読むべきではない」「漏えいは人の作業の流れの中で起きる」と断っています。AIで作ったから漏れる、という因果を示した数字ではありません。

もう少し直接的な調査もあります。セキュリティ会社のEscapeが、AIでアプリを作るサービス（Lovable、Bolt.newなど）で公開されたアプリ5,600本以上を調べたところ、露出していた秘密情報は400件以上。「Supabaseのサービスキーのような鍵は、画面側のファイルから簡単に取り出せることが多かった」と書いています。

バイブコーディングの記事で、「動けばいい」で作ったものは半年後に誰が直すのか、と書きました。鍵の置き場所は、その典型です。鍵が画面側にあっても、アプリは問題なく動きます。 だから、誰も見ないまま公開されてしまう。

守りは、鍵ではなくサーバー側に置く

誤解のないように書いておきます。アプリに鍵が入っていること自体が、すぐにアウトとは限りません。 地図を表示するための鍵のように、見られる前提で作られている鍵もあります。

たとえばSupabase（データベースのサービス）の公式ドキュメントは、公開用の鍵について「誰でも読めるので、アクセスできるのは行単位の権限設定が許す範囲だけ」と書き、秘密の鍵については「ブラウザにも、配布するアプリにも、ソースコードの管理にも、絶対に置かない」と書いています。

つまり問題は、鍵が見えることではありません。その鍵だけで、何でもできてしまう作りです。

JPCERT/CCと個人情報保護委員会が求めているのも、そこです。

  • 非公開のものも含めて、すべてのAPIで「この人に、これを許してよいか」を毎回確かめる（本人かどうかの確認だけでなく、権限の確認まで）
  • APIや鍵の権限は必要最小限にし、有効期限をつける
  • ログイン、パスワードの再設定、検索などは、短い時間に何度も呼べないよう回数を制限する

今回、APIの不備を発表に明記した会社があります。JR九州フードサービス（10月13日、約26,900名）は、アプリの提供元の説明として「一部の API において、本来アクセスする権限を有しない第三者が他のユーザー情報を取得できる状態」と書いています。「この人がこのデータを見てよいか」の確認が抜けていたと読める書き方です。

うちの場合

うちが作るアプリでは、AIのAPIキーなどの秘密の鍵は、Cloudflare側（サーバー側）に置いています。 画面側のコードには入れていません。画面は自分たちのサーバーに頼むだけで、外のサービスを呼ぶのはサーバーです。

業者に聞く質問

人月の記事で、業者に聞く3つの質問を書きました。そこに、これを足してください。

  • 「アプリや画面のコードに、秘密の鍵は入っていますか。入っているなら、その鍵だけで何ができますか」
  • 「画面にボタンがない機能（管理用のAPI）にも、ログインと権限の確認はかかっていますか」

すぐに答えが出なければ、確認していないのかもしれません。その場で確認をお願いしてください。

入口2：「社内用」でも、URLで開けるなら公開している

狙われたのは、お客さん向けの画面だけではない

JPCERT/CCの注意喚起には、こうあります。「一般利用者向けのアプリのほか、BI（ビジネスインテリジェンス）ツールや従業員向け管理システムなど、管理・運用側で不特定多数の利用者からのアクセスを想定していないシステムが被害に遭い」。

社内の人しか使わないシステムでも、URLがあってインターネットから開けるなら、世界中の誰でも試せます。 ログイン画面が出るということは、ログインを試せるということです。

各社の発表にも、管理用の仕組みが出てきます。

  • skyticket：「一部の管理機能を不正に操作され」、そこからほかのサーバーとクラウドのデータに入られた（社内向けの画面だったかどうかまでは書かれていません）
  • スカラコミュニケーションズ（大和証券の委託先）：第三者が、問い合わせ管理サービスの「管理サイトに不正にログインし、不正なプログラムを設置」。同じサーバーで動いていた利用企業、最大5社に影響
  • NEXT STAGE（10月13日、最大約40,000件）：BIツール「Metabase」の脆弱性のリスクに触れ、アカウントを不正に使われて閲覧できる状態だった、と説明

マクニカは、こう書いています。脆弱性診断をしていても、「管理画面のように一般に公開されない機能は診断の対象から除外されがちです」。

表の画面には気を使うのに、裏の管理画面は「社内用だから」で後回しにする。 そこが入口になっています。

BIツールは、データベースの鍵を持っている

Metabaseは、社内のデータベースにつないで、売上のグラフや顧客の一覧を作るためのBIツールです。無料で使える版もあります。

今年8月に見つかった脆弱性（CVE-2026-72898）は、深刻度が最高の10.0で、ログインしていない第三者でも悪用できるものでした。Metabase社は8月6日に修正版を出し、同社のクラウド版が、まだ知られていなかったこの脆弱性で攻撃を受けた（いわゆるゼロデイ攻撃）と公表しています。アメリカのサイバーセキュリティ機関CISAは8月11日、実際に悪用が確認された脆弱性の一覧に加えました。

BIツールが怖いのは、つないでいるデータベースの鍵を、ツール自身が持っていることです。BIツールに入られると、その先のデータベースまで届きます。だからMetabase社は、更新したあとに「つないでいるデータベースの認証情報を変えてください」と書いています。

Metabaseを使っているなら、少なくとも次を確認してください（JPCERT/CCとMetabase社の情報から）。

  • 58.24、59.21、60.17、61.11、62.9、63.5 のどれか以上に更新されているか（それぞれの系列で、この番号より前の版が対象。58系より古い版は対象外）
  • すぐに更新できないなら、/api/session/reset_password への通信を止める
  • 外から開ける状態だったなら、更新したあとに、つないでいるデータベースのパスワードを変え、管理者アカウントとAPIキーを見直す

ログインの強さも、今回の基準で見る

国家サイバー統括室とIPAが求めているのは、多要素認証、推測されやすいパスワードの禁止、管理者権限を最小限にすること、使っていないアカウントの無効化です。IPAは、利用している外部サービスを洗い出して、身に覚えのないアカウントがないか確認するよう書いています。

マクニカが書いたとおり、社内向けの機能は診断からも外されがちです。ログインの作りも、同じ目で見直してください。

うちの場合

うちが作る社内ツールも、インターネットから開ける場所（Cloudflare）に置いて、ログインをかけています。だから、この入口は他人事ではありません。今回の注意喚起の基準——多要素認証、推測されにくいパスワード、使っていないアカウントの無効化——は、うちが作ったものにも、そのまま当てはまります。

担当者や業者に聞く質問

  • 「管理画面は、誰が、どこから開けますか。社外から開ける必要はありますか」
  • 「ログインは多要素認証ですか。辞めた人のアカウントは消えていますか」
  • 「BIツールは、何につながっていて、最新版ですか」

入口3：委託先から入られる

発表から一番はっきり見えたのは、ここ

手口がほとんど公表されていない中で、各社の発表から一番はっきり読み取れたのが、委託先です。

  • 大和証券：委託先のサーバーへの不正アクセスで、お客様情報が取られた形跡。「当社のシステムに対する不正アクセスは確認されておりません」
  • 第一興商：個人情報の取り扱いを委託している会社で、従業員のPC1台がマルウェアに感染。「当社のシステムへの影響も確認されておりません」
  • JR東日本・ビューカード・JR九州：IDCフロンティアで起きた不正アクセスに伴い、メール配信に使っていた外部のサービスから漏えいした可能性。IDCフロンティアは、影響を受けた利用者を「495の企業・自治体」としています
  • 銀のさら：データの保管を委託していたサーバーの運営会社が、ランサムウェア攻撃を受けた

大和証券と第一興商の発表には、同じ趣旨の一文があります。自社のシステムへの不正アクセスや影響は、確認されていない。それでも、自社のお客さんの情報が漏れた。

自分の会社の守りを固めても、預けた先から漏れれば、発表するのは自分の会社です。

中小企業の委託先も、たくさんある

中小企業も、多くの外のサービスに、お客さんの情報を預けています。会計ソフト、予約システム、メール配信、顧客管理、そして業務アプリを作った外注先。全部、委託先です。

国家サイバー統括室の注意喚起は、委託先について一番厚く書いています。

  • 委託先のセキュリティの状況を、再委託先も含めて把握する
  • 契約で、データの扱い方、アクセス権、ログの管理、漏えいしたときの報告義務を決めておく
  • 渡す情報は必要最小限にし、業務が終わったらデータを消してもらう

そのうえで、こう書いています。「『委託先企業と共に管理する』という認識の下で」。

うちの場合（委託先として）

うちも、取引先の業務アプリを作り、業務のデータに触れる委託先です。

取引先と一緒にAIの利用ルールを作り、顧客の情報は会社で契約したAIにだけ入れる、と決めています。受け取った資料に個人情報が入っていれば、AIに渡す前に伏せています。

それでも、うちが預かる側である以上、上の3つの質問は、うちにも向けてください。

委託先に聞く質問

  • 「預けたデータは、どこに、誰の権限で置かれていますか。その会社が、さらに外に預けていますか」
  • 「漏れたとき、何日以内に知らせてもらえますか。それは契約に書いてありますか」
  • 「取引が終わったら、データは消してもらえますか」

「うちは狙われない」について

最後に、一番よく聞く言葉について。

デジタル大臣が10月2日の会見で示した数字では、不正アクセスを含む、不正の目的で行われたおそれのある漏えい等が、令和6年度で7,604件（漏えい等の件数の39.9%）ありました。ニュースになる大企業の事案は、その一部です。

攻撃の動きについて、マクニカはこう書いています。「サイト全体を広く調べ、画面やAPIを通常通り動かしながら、情報を取得できる不備を探る動きが見られています」。

大企業だけの話ではない、と考えるほうが自然です。

この記事で、できないこと

  • どの会社がどの手口でやられたのかは、分かりません。 公表されていないからです。3つの入口は、注意喚起に書かれた型と、各社の発表の数少ない記述から組み立てたもので、個別の事案の原因を特定したものではありません
  • この記事でできるのは、点検の入口までです。 実際に穴があるかを確かめるのは脆弱性診断で、専門の業者の仕事です。うちは業務アプリを作る会社で、脆弱性診断の専門業者ではありません
  • 注意喚起の多くは、大量の個人情報を扱う事業者向けです。 中小企業が、その全部をそのままやる必要はありません。ただ、3つの入口の確認は、会社の規模に関係なくできます

まとめ

  • 9月の終わりから大きな会社の漏えいの発表が相次ぎ、10月7日〜9日に注意喚起が8本出た
  • 手口は、ほとんど公表されていない。 7月以降の公表の約8割は、手口を分類できる説明がない（マクニカ）
  • 注意喚起の型と各社の発表を突き合わせると、入口は3つ
    1. アプリの中の鍵と、画面の裏のAPI——鍵は隠せない。守りは、サーバー側の確認に置く
    2. 「社内用」の管理画面やBIツール——URLで開けるなら公開している。ログインの強さと更新を見る
    3. 委託先——自社で被害が確認されなくても、預けた先から漏れれば、発表するのは自分
  • 3つとも「表には出していないつもり」の場所で、中小企業にもそのままある

業者に、担当者に、委託先に。この記事の質問を、そのまま聞いてみてください。うちにも。

3つの入口を、一緒に確認します。 うちで作ったものも、他社が作ったものも、鍵の置き場所、管理画面の開き方、データの預け先を、一緒に確かめます。無料相談はこちら。

出典・参考

注意喚起

各社の発表

手口と対策

アプリの中の鍵に関する調査

関連記事

Read next

他の記事

AI・DXの導入、どこから手をつけるか迷ったら

Acetyl:Techが、あなたの会社で「本当に使われる形」まで設計します。まずはお気軽にご相談ください。

無料で相談する