次の時代の地図 #23：AI が下げた攻撃の値段、狙われる理由は「持っていること」に

10月9日からの1週間で、ソースネクストが最大2,251万件余り、バーガーキングを運営するビーケー・ジャパンが約1,118万件の会員情報の流出・漏えいを公表した。同じ週に、情報通信研究機構の分析チームと JPCERT/CC は、公開されているアプリを解析して裏側のサーバーを狙う手口と、攻撃者が AI を使って脆弱性の探索や API 経由の攻撃をしていた痕跡を、相次いで示した。

JPCERTコーディネーションセンター

@jpcert

·Follow

ブログ JPCERT/CC Eyes「連続不正アクセス事案の攻撃手法に関する調査」公開。調査の過程で攻撃者がAIを利用して既知の脆弱性のスキャンやAPI経由での攻撃などを実施していたことを確認しました。国内外のWebサービスなどに対する攻撃の状況を紹介しています。^KI blogs.jpcert.or.jp/ja/2026/10/web…

7:17 AM · Oct 15, 2026

451

Read 2 replies

AI が攻撃の値段を下げ、狙われる理由が、大きいから・有名だからというものから、データを持っているからというものへ移り始めている。選ばれた相手を時間をかけて狙う攻撃から、公開されているものを片端から調べる攻撃へ。アプリを公開し、データを持っているだけで、調べられる側に入る。

守る側の打ち手は欠かせない。ただし守る面が広がるほど守る費用は増え、攻める側の費用は下がり続ける。この差が開くほど、合理的な出口は堅く守ることに加えて、持たない設計と、見せずに確かめる設計になる。

暗号化して持てば済む、とも言い切れなくなっている。量子計算と AI による数学の進歩を理由に、いま使っている暗号に使用期限があることを前提に動くチェーンが出てきた。暗号化は時間を稼ぐ手段で、持たずに済ませる設計とは別物である。

前号 #22 は、信頼の置き場所が預ける・信じるから確かめるへ移る動きを、事故の損得で描いた。本号が描くのは、その移動を押す攻める側の変化である。

1週間に重なった千万件級の漏えいと、市場に出た費用

主要なものだけを、各社の公表に沿って置く。

ソースネクストは10月15日、会員情報を管理するシステムが不正アクセスを受け、最大22,519,960件の会員情報が流出した可能性があると発表した。同社の説明では、10月9日の午前から第三者が「会員情報取得 API」を不正に使って登録者の情報を取得しており、13日に封じ込めを終えた。項目はメールアドレス、パスワード、氏名、住所、電話番号、生年月日などで、登録状況によって異なる。

ビーケー・ジャパンは同じ15日、公式アプリの会員情報を管理するシステムに10月2日から7日にかけて不正アクセスがあり、会員情報約1,118万件が漏えいしたと公表した。原因は外部の専門機関と調べている段階にある。

ブックオフグループホールディングスは10月13日の第2報で、会員管理システムから外部に送られた会員データを6,427,735件、対象者を6,383,279人と確定した。対象者のうち212,371人は、すでに退会した会員だった。やめた客のデータも、システムの中に残っていた。

自治体向けの防災情報の一斉配信サービスを手がけるアルカディアも13日に不正アクセスを公表し、日本経済新聞によればメールアドレス最大約313万件が流出した可能性がある。共同通信によると、総務省は15日夕方の時点で、192の自治体から防災メールの配信停止や情報漏えいのおそれの報告を受けた。求人サイトのバイトルを運営するディップも10月9日、一部機能の仕様の不備を突かれ、最大3,885,771件のメールアドレスが漏えいしたと公表している。同じ週には、ほかの事業者からも不正アクセスの公表が続いた。

件数は、件・人・メールアドレスと単位が違い、同じ人が複数のサービスに登録している重なりもある。ここでは足し合わせない。

費用は市場にも出た。日本経済新聞によると、10月13日の東京市場で Sansan の株価は、利用者向けのオンラインコミュニティの会員情報の流出を嫌って、一時12.7%下げた。

当局の側では、個人情報保護委員会が10月7日、大規模な漏えいが続いていることを踏まえて事業者に注意喚起を出し、同じ日に改訂した不正アクセスの典型事例集に、新たに「API が悪用される事例」を加えた。2024年12月の初版では、事例は8つだった。

AI が下げた攻撃の値段 — 二つの公的な分析が示した手口

一つ目は、情報通信研究機構のサイバーセキュリティの共同拠点 CYNEX に置かれた分析チーム LETTICE が10月13日に出した注意喚起である。公開されている Android アプリを入手して解析し、接続先のサーバーや通信の仕組み (API) を調べ、その情報をもとに裏側のサーバーを仕様に合わせて攻撃する。LETTICE はこれを「A2B 攻撃 (App-to-Backend Attack)」と呼んだ。事業者から見れば、外に出していないつもりだったサーバーの内部仕様が知られてしまう。同様の問題は iOS アプリや Web サービスの API でも起こりうるという。そのうえで LETTICE は、AI の活用でアプリの解析や脆弱性の発見が効率化され、こうした攻撃がより多くのシステムに広がりうると注意を促した。

二つ目は、JPCERT/CC が10月15日に公開したブログである。国内の複数の組織で相次いだ不正アクセスについて、攻撃に使われた可能性のあるインフラを複数の組織と連携して調べた結果、攻撃者が AI を利用して、既知の脆弱性の探索や API 経由での攻撃などをしていたことを確認したと書いた。調べたサーバーには、Android アプリの配布ファイル (APK) と、アプリを解析する道具に関わるファイルが残っていた。攻撃者は APK を解析して API を特定し、その API に脆弱性がないかを調べていた。攻撃元のサーバーは、日本以外の地域向けの Web サービスにも攻撃をしていた。

二つの分析が示しているのは、攻撃者が AI を使っていたこと、そして AI で探索が効率化され広がりうることまでである。AI がひとりでに攻撃したわけではない。また、どの社の事案がどの手口によるものかは、公的な分析も名指ししていない。

それでも、手口の形ははっきりしている。公開アプリは誰でも手に入る。中身を読み解く手間が AI で下がれば、相手を選んで時間をかける理由が薄れる。公開しているもの、データを持っているものすべてを、順に調べていけばいい。狙う相手を選ぶ費用が下がったとき、標的の条件は大きさや知名度から、調べられる場所にデータがあるかどうかへ移る。

守る費用は守る面の広さで増える

守る側の打ち手は欠かせない。個人情報保護委員会は10月7日の注意喚起で、2027年4月に確定させる予定のガイドラインの見直しを先取りする形で、技術的な対策の手法の例を示した。アクセスできる人と権限の最小化、フィッシングに強いものを含む多要素認証、修正ソフトの適用による脆弱性への対応、認証やアクセスのログの保存と定期的な分析、侵入を検知する仕組み、侵害された機器の停止と隔離などである。FNN によれば、委員会の事務局長は確定を待たずに示したことを「極めて異例」と述べた。

JPCERT/CC の推奨は、アプリを作る側に向いている。API の認証に使う秘密鍵や長く有効な認証情報をアプリに埋め込まない。アプリの署名や難読化に頼らず、利用者の認証と、操作の対象や内容に応じた認可をサーバーの側で行う。回数の制限と異常なリクエストの監視を置き、正規のアプリ以外からのアクセスも想定する。

どれも正しい。ただ、これらの手当ては守る面の数だけ要る。公開しているアプリが一つ増えれば、読み解かれる API が増える。保管しているデータの種類が増えれば、漏れたときに失うものが増える。ログの保存も監視も、面の広さに比例して手間と費用がかかる。

一方で、攻める側の費用は面の広さにほとんど比例しない。公開アプリを一本読み解く手間が下がれば、十本でも百本でも同じ手順を回せる。守る側は全部の扉を閉め続けなければならず、攻める側は開いている扉を一つ見つければいい。この非対称は昔からあったが、探索の値段が下がるほど差は開く。

守る側も AI を使う。ログの分析や異常の検知に AI を入れれば、守る手間も下がる。攻撃と防御の両方に AI が入るので、AI が攻撃だけを有利にするという単純な図にはならない。それでも、守る費用が守る面の大きさで決まり、攻める費用がその大きさに縛られないという関係は、AI が両側に入っても変わらない。

もう一つの出口 — 持たない、見せずに確かめる

守る面そのものを小さくする道がある。

一つ目は、持たないことである。個人情報保護法は、利用する必要がなくなった個人データを遅滞なく消去するよう努めることを事業者に求めている。個人情報保護委員会は10月7日の注意喚起でこの条文をわざわざ引き、消去が徹底されずに漏えいがより深刻になった事例にも接していると書いた。ブックオフの第2報にあった退会者21万人分のデータは、その典型の一つに見える。前号で扱ったタイムズカーも、退会した人の運転免許証の情報と画像を7年間保管していた (前号 #22)。必要な期間を過ぎたデータを持ち続けなければ、攻撃がどれだけ安くなっても、そこからは何も持ち出せない。

二つ目は、見せずに確かめることである。年齢や資格のような条件だけを示し、元の書類は渡さない仕組みは、すでに実装の段階にある。欧州委員会の年齢確認の仕様はゼロ知識証明を必須の提示方法にし、Google はウォレットの年齢確認にゼロ知識証明を組み込んだ。仕組みの詳細は前号で書いた。

本号で加えたいのは、三つ目の視点である。API が返す情報を減らすことだ。個人情報保護委員会が新しく加えた「API が悪用される事例」は、原因として、管理の対象から漏れていた API、他の利用者のデータに届いてしまうパラメータ、そして応答に不要な情報が含まれていたことを挙げ、対策の例に「不要な情報をレスポンスに含めないように設計する」と書いた。会員番号を連番にせず、推測しにくい値にすることも挙げている。調べられても、持っていないもの、返さないものは漏れない。AI が API を読み解く速さが上がるほど、API が何を返すかの設計が効いてくる。

置き換えられないものもある。

法令で保存が義務づけられているデータは、持たない設計の対象にならない。委員会の注意喚起も、法令で保存期間が定められている場合を消去の努力義務から外している。

見せずに確かめる仕組みは、証明を出す側が乗らなければ始まらない。条件を示す証明は、免許や身分証を出す発行元の署名があって初めて意味を持つ。

そして、鍵の管理はこの仕組みの守備範囲の外にある。証明の仕組みを入れても、秘密鍵をアプリに埋め込めば、そこから破られる。ゼロ知識証明で漏えいがなくなるわけではない。減らせるのは、確かめるためだけに預かっていたデータの山である。

暗号化にも使用期限 — 量子と AI の数学を前提に動くチェーン

データを暗号化して持てば、持たない設計と同じ効果があるように見える。だが、暗号そのものに使用期限があることを前提に動き始めたチェーンがある。署名の方式をめぐるイーサリアムと Tron の議論は、10月12日の Deep Dive (耐量子署名、イーサリアムはハッシュで Tron は格子に) で書いた。今週はそこに二つの動きが加わった。

Starknet では10月15日、量子計算に耐える独立した Layer 1 になる方向を検討するかどうかを問う、7日間の投票が始まった。拘束力はなく、賛成が多ければ詳しい提案と次の投票へ進み、反対なら量子への対応は今の Layer 2 のまま続ける。提案は、Starknet が自分で管理する部分はまもなく量子に耐えられるようにできる一方、イーサリアムとの橋渡しやデータの置き場はイーサリアムの日程に縛られると理由を書いている。開発を担う StarkWare の最高経営責任者 Eli Ben-Sasson は10月8日、量子の脅威は考えているよりずっと近いかもしれないと書き、安全だと考えてきたものを AI が破るまでにどれだけ時間があるかと問いかけていた。

Sui では10月12日の開発用ネットワーク (devnet) のリリースで、米国の標準になった耐量子署名 ML-DSA-65 がアカウントの署名方式に加わった。翌13日、開発元 Mysten Labs の共同創業者 Kostas Chalkias は、devnet で初めての量子耐性の取引として、その記録を公開した。Sui 財団は8月の解説で、メインネットのアカウントでの対応を2027年1〜3月期の目標に置いている。同じ解説は、2026年7月に AI モデルが耐量子署名の候補の一つ HAWK の実効的な鍵の強さを約60時間で半分にしたと紹介し、余裕のある強さの設定を選んだ理由に挙げた。

ここで確認しておく。どのチェーンでも、量子計算や AI による暗号の破りは示されていない。動いているのは、破られる日が来る前に備える側である。

意味は、データを持つ事業者にもそのまま当てはまる。暗号化して持つことは、読まれるまでの時間を稼ぐ手段として欠かせない。だが、いつか読まれうる形で持ち続けることに変わりはない。今のうちに集めて後で解く、という攻め方は、量子の機械が完成する前から始められる。Sui 財団の解説も、署名について同じ型の脅威を挙げている。持たずに確かめる設計は、読まれる日が来ても読まれるものが無い状態を作る。暗号化と、持たない設計は、役割が違う。

この地図が向かう世界 — 明るい側と暗い側

ここからは見通しの話になる。攻撃の値段が下がり続ける世界は、二つの方向へ進みうる。

明るい側から書く。

一つ目は、事業者が持つデータの山が小さくなることである。漏えいのたびに失うものが大きい事業者ほど、退会者のデータ、確認が済んだ書類、使っていない項目を手放す理由が強くなる。消去を求める法の条文は昔からあった。違うのは、持ち続ける費用が、攻撃の値段が下がるたびに上がっていくことだ。

二つ目は、確かめる仕組みが標準になることである。年齢や資格を示すたびに書類を丸ごと渡すのではなく、問われた条件だけを答える。API も、聞かれたことにだけ最小限で答える。設計の初期値が、多めに持つ・多めに返すから、少なく持つ・少なく返すに入れ替わる。

三つ目は、攻撃が安くなっても、盗める物が少なくなることである。片端から調べる攻撃は、どこを開けても中身が無ければ割に合わない。攻撃の値段が下がることと、攻撃が儲からなくなることが、同時に進みうる。

次に暗い側を書く。

一つ目は、守る費用を払えない小さな事業者や自治体ほど、調べられる側に残ることである。今回の防災情報の配信サービスでは、一つの委託先への攻撃が192の自治体に及んだ。自前で守る力を持たない組織は、委託先にまとめて頼る。まとめて頼った先が破られれば、影響もまとめて広がる。

二つ目は、持たない設計が広がる前の移行期に、持ったままの事業者へ攻撃が集まりうることである。調べる攻撃は、開いている扉を探す。手放した事業者が増えるほど、まだ手放していない事業者が目立つ。

三つ目は、確かめる仕組みの担い手が、国と少数のプラットフォームに寄ることである。証明を出す発行元とウォレットを出す側に、誰がいつ何を証明したかの記録が集まりうる。米国の電子フロンティア財団 (EFF) は8月、年齢確認の証明の発行元が、証明が使われるたびに追跡できうると指摘した。データの山が事業者から消えても、別の場所に別の山ができるおそれがある。

四つ目は、攻撃と防御の両方に AI が入り、守る側の中にも力の差が出ることである。AI でログを読み、異常を見つけ、API の設計の穴を自分で先に探せる組織と、そうでない組織の差は、守る費用の差としてそのまま開く。

明るい側と暗い側は、どちらか一方だけが来るものではない。持つ量を減らす事業者が増える一方で、減らせない組織に攻撃が集まる。確かめる仕組みが標準になる一方で、その担い手が少数に寄る。どちらへ傾くかは、次の章に置く観測点で確かめられる。

この読みが崩れる条件、次に見るもの

崩れる条件は三つある。

ひとつ。漏えいの公表が一過性で収まる場合。今回の連続が特定の時期に集中した出来事にとどまり、同じ規模の公表が続かなければ、攻撃の値段が下がったという読みは弱くなる。

ふたつ。AI を使った攻撃の確認が、今回の事案から広がらない場合。JPCERT/CC と LETTICE の続報や、ほかの国の当局の分析で同じ型の手口が確認されなければ、片端から調べる攻撃への移行は、まだ一部の攻撃者の話にとどまる。

みっつ。事業者が保管するデータを減らさない場合。各社の再発防止策が監視の強化やシステムの点検だけで、持つ量や返す情報に触れなければ、持たない設計への移動は事故の後でも起きないことになる。

次に見るものは、日付のあるものから置く。

10月15日に始まった Starknet の7日間の投票の結果。Starknet のガバナンスのページで、独立した Layer 1 の検討へ進むかどうかが決まる。量子と AI を理由にした使用期限の前倒しが、投票で裏付けられるかを見る。

2027年4月、個人情報保護委員会がガイドラインの見直しを確定させる予定である。委員会の会議資料で、先取りで示した手法の例がどこまで残るか、不要なデータの消去や API の設計にどこまで踏み込むかを見る。

日付の無いものは、次の公表として置く。JPCERT/CC のブログと LETTICE の続報で、AI を使った手口がほかの事案でも確認されるか。ソースネクスト、ビーケー・ジャパン、ブックオフが出す原因の調査結果と再発防止策のお知らせで、退会者のデータの扱いや、保管する項目を減らす方針が入るかどうか。これが、守りの強化だけで終わるのか、持つ量に手を付けるのかを分ける。

前号で見たのは、信頼の置き場所が、途中の誰かから受け取った側の手元へ移り始める動きだった。今週見たのは、その移動を後ろから押す力である。攻撃の値段が下がるほど、持っていることそのものが狙われる理由になる。

🔗 一次ソース