2026年、AIがソフトウェアの脆弱性を見つける速度が急激に上がっています。
Claude Opus 4.6はFirefoxを2週間調べ、22件のセキュリティ脆弱性を発見しました。
Chromeでは、149と150というわずか2つのStable milestoneで1072件のセキュリティバグが修正されました。
Anthropicは8月26日時点で、392のオープンソースプロジェクトへ2300件の脆弱性を開示しています。
数字だけを見ると、セキュリティは猛烈な勢いで進歩しているように見えます。
見つける。
修正する。
また探す。
AIなら、このサイクルを人間よりはるかに速く回せます。
しかし、ここで少し妙な問題が出てきます。
脆弱性を100倍速く発見し、100倍速く修正できるようになれば、ソフトウェアは100倍安全になるのでしょうか。
2026年、セキュリティ研究者の間では「Vulnpocalypse」という言葉が使われ始めています。
Vulnerability（脆弱性）とApocalypse（黙示録）を組み合わせた言葉です。
意味しているのは「AIが世界をハッキングする終末」ではありません。
AIによって、これまでコードの中に眠っていた脆弱性を、人間の組織が処理できない速度で発見できるようになること。
問題は、脆弱性を発見できるかどうかから、その大量の発見をどう処理するかへ移り始めています。
そしてこれは、70年近く続いてきた「誰も見つけられなかったものを見つける」というハッカー像そのものも変えるかもしれません。
Vulnpocalypseとは何か
Vulnpocalypseという言葉が2026年に注目された背景には、AIによる脆弱性探索能力の急速な向上があります。
セキュリティPodcast「Security Cryptography Whatever」は6月14日、AFL（American Fuzzy Lop）の開発者として知られるMichał Zalewski、通称lcamtufを招き、「Facing the Vulnpocalypse」というエピソードを公開しました。
AFLは、ソフトウェアへ大量の入力を与えてクラッシュや異常挙動を探すファザーです。
つまりセキュリティ業界は、AIが登場するずっと前から脆弱性探索を自動化してきました。
違うのは規模と能力です。
現在のAIは、コードを読み、仮説を立て、プログラムを実行し、クラッシュを調査し、修正案まで作るようになっています。
脆弱性探索のコストがさらに下がれば、それまで発見されなかった大量の問題が一気に見えるようになります。
それ自体は悪いことではありません。
むしろ、攻撃者より先に発見できるなら防御側にとって有利です。
問題は、
「発見工程だけが急速に高速化したら、その後ろにある人間の作業は追いつくのか」
という点です。
Hackは、最初からコンピュータ犯罪を意味していたわけではない
この問題を考えるために、少し時間を戻します。
1950年代の終わり、MITには鉄道模型へ夢中になっている学生たちがいました。
Tech Model Railroad Club、TMRCです。
彼らが遊んでいたのは、ただ列車を走らせる模型ではありません。
電話交換機に使われていたリレーやクロスバーなどを組み合わせ、巨大な自動制御システムを作っていました。
本来その目的のために作られた部品ではない。
でも配線を変えれば別のことができる。
この仕組みはどうなっているのか。
ここを変えたら何が起きるのか。
TMRCは、こうした創意工夫を表す言葉として「hack」が使われていたと振り返っています。
当時のhackは、現在のニュースで使われる「不正アクセス」と同じ意味ではありません。
機械を深く理解し、設計者が想定していなかった使い方を引き出すこと。
その感覚が初期のハッカー文化にありました。
高価なコンピュータで宇宙戦争を始めた男たち
1961年、MITのSteve “Slug” RussellらはPDP-1というコンピュータでゲームを作り始めました。
翌1962年に形になったのが『Spacewar!』です。
宇宙船同士が中央の星の重力に引かれながら飛び回り、ミサイルを撃ち合います。
いまなら「学生がゲームを作った」で終わる話かもしれません。
しかし当時使っていたのは家庭用ゲーム機ではありません。
大学に置かれた非常に高価な研究用コンピュータです。
それを宇宙戦争へ使う。
誰かがコードを書く。
別の人が書き換える。
思いついた機能を追加する。
コピーされ、改造され、別の場所へ広がっていく。
「こんなこともできるのではないか」という好奇心が、そのままプログラムになっていました。
電話網という巨大なブラックボックス
1960〜70年代には、コンピュータの外でも似た文化が生まれます。
Phone Phreakです。
当時の長距離電話網では、交換機を制御する信号の一部が、人間の声と同じ音声帯域を通っていました。
そこで人々は、特定の周波数の音を送り、電話網がどう反応するのかを調べました。
有名なのがJohn Draper、通称Captain Crunchです。
シリアル「Cap’n Crunch」に付属していた笛が約2600Hzの音を出せたことから、この文化を象徴する人物になりました。
もちろん、Phone Phreakには違法行為も含まれていました。
美化する話ではありません。
ただ、その文化にあったもう一つの魅力は、巨大なブラックボックスを自分の手で読み解くことでした。
Googleもありません。
GitHubもありません。
仕様書も簡単には手に入りません。
音を送り、反応を見る。
情報を仲間と共有する。
そうすると、巨大企業の技術者しか知らなかった電話網の仕組みが少しずつ分かってくる。
ブラックボックスが、自分で理解できるものへ変わります。
その世界に夢中になった若者、Steve Wozniak
Phone Phreak文化へ魅了された一人が、後にAppleを共同創業するSteve Wozniakでした。
WozniakはBlue Boxと呼ばれる装置を自作し、Steve Jobsとともに電話網を試しました。
Wozniak本人は後年、自分はBlue Boxを通話料金を浮かせるためではなく、仕組みを調べるために使っていたと説明しています。
巨大なシステムを調べる。
自分で回路を作る。
設計者が予定していなかった動きを引き出す。
Appleが生まれる少し前のWozniakとJobsが夢中になっていたものの一つが、こうした遊びでした。
コンピュータを巨大組織から個人の机へ
1975年、カリフォルニア州でHomebrew Computer Clubが始まります。
Fred MooreとGordon Frenchが中心となった集まりで、Altair 8800などのマイクロコンピュータについて情報交換しました。
当時は、個人がコンピュータを持つという発想自体が新しい時代です。
Steve Wozniakもこの集まりへ参加し、後のApple Iとなるコンピュータを仲間へ披露しました。
誰もパーソナルコンピュータの正しい使い方を知りません。
だから自分たちで考える。
完成された技術を消費するのではなく、技術の用途そのものを発見する。
ここにも初期のハッカー文化につながる感覚があります。
ヒッピー文化とコンピュータは意外と近かった
同じ時期、米国西海岸のコンピュータ文化はカウンターカルチャーとも交わっていました。
もちろん、「ハッカーはヒッピーだった」という単純な話ではありません。
Fred Turnerが『From Counterculture to Cyberculture』で追ったのは、冷戦期には巨大組織の道具にも見えていたコンピュータが、個人を自由にする道具として読み替えられていった歴史です。
Stewart Brandと『Whole Earth Catalog』も、その接続を象徴する存在です。
DIY。
電子工作。
コミュニティ。
コンピュータ。
ブラックボックスだった技術を、自分の手で触れるものへ変えていく。
初期PC文化には、単なる小型化や低価格化だけでは説明しきれない魅力がありました。
「誰も気づかなかったものを見つける人」が格好よくなった
こうした歴史の中で、ハッカーには独特のヒーロー像が育ちました。
仕組みを深く理解する。
マニュアルをそのまま信じない。
実際に触る。
設計した人すら気付かなかった動作を見つける。
セキュリティの世界では、その能力が非常に分かりやすい成果になります。
誰も見つけられなかった脆弱性を見つける。
それは技術的に価値があります。
同時に文化的にも格好いい。
しかし2026年、この価値観を揺さぶるものが出てきました。
AIです。
人間が1件を確認している間に、AIは50件見つけていた
2026年3月、AnthropicはMozillaとの共同研究結果を公開しました。
Claude Opus 4.6にFirefoxを調査させたところ、2週間で22件のセキュリティ脆弱性を発見しました。
Mozillaはそのうち14件をHigh Severityとして評価しています。
14件という数字は、2025年にFirefoxで修正されたHigh Severity脆弱性のおよそ5分の1に相当します。
さらに印象的なのが、最初の脆弱性を確認したときの出来事です。
ClaudeがUse After Freeを見つける。
Anthropicの研究者が、それを別環境で再現できるか確認する。
人間がその一件を検証している間に、Claudeはすでに50個の新しいクラッシュ入力を発見していました。
最終的にClaudeは約6000個のC++ファイルをスキャンし、Anthropicは112件のユニークな報告をMozillaへ提出しました。
112件すべてが脆弱性だったわけではありません。
しかし、この場面はAI脆弱性探索の新しい問題をよく表しています。
AIが見つける速度に、人間が確認する速度が追いつかない。
「AIに脆弱性を発見できるか」という問いは、すでに次の段階へ進みつつあります。
Chromeでは2回のリリースで1072件
Google Chromeでは、さらに大きな数字が出ています。
Googleは2026年7月、Chrome 149と150の2つのStable milestoneで、合計1072件のセキュリティバグを修正したと発表しました。
これは、その前23 milestoneで修正されたセキュリティバグの合計を上回ります。
GoogleはGeminiを使った脆弱性探索エージェントをChromeへ投入しています。
またBig SleepやCodeMenderなどをCIへ組み込み、24時間ごとに変更を調査しています。
5月だけでも、本番へ入る前に20件を超える脆弱性を阻止したとしています。
重要なのは、1072件すべてをAIが単独で発見したという意味ではないことです。
AIによる探索、修正候補生成、レビュー支援、テスト作成などが、Chromeのセキュリティ工程全体へ組み込まれています。
AIが「バグを見つけるツール」から「セキュリティ開発工程そのものの一部」へ変わり始めています。
「脆弱性の黙示録」が始まる
ここでVulnpocalypseという言葉が意味を持ちます。
AIで脆弱性探索の費用が下がる。
これまで見つからなかった問題が大量に見つかる。
一方、発見された後にはまだ人間の仕事があります。
本当に脆弱性なのか確認する。
影響範囲を調べる。
重複を整理する。
修正方法を考える。
メンテナーへ連絡する。
パッチをレビューする。
リリースする。
ユーザーへ届ける。
発見工程だけが極端に速くなれば、ボトルネックは後ろへ移動します。
脆弱性が存在しなかったのではありません。
見つける能力が低かったため、見えていなかっただけの問題が一気に表面化します。
モグラを100倍速く叩けば、安全になるのか
セキュリティ研究者David Adrianは、この状況を「モグラ叩き」に例えています。
穴から脆弱性というモグラが出る。
見つけたら修正する。
次の穴から出る。
また修正する。
AIならこのサイクルを猛烈に速く回せます。
「今月は500件修正した」
「昨年より修正時間が半分になった」
という数字も改善します。
しかし、同じ種類の脆弱性が何度も発生し続けているならどうでしょう。
それはモグラを叩く速度が上がっただけで、ゲームそのものには勝っていません。
Adrianは脆弱性発見数を、成果そのものというより診断指標として見るべきだと論じています。
本当に見るべきなのは「その種類の問題が時間とともに減っているか」です。
AIで大量発見する側も「一件ずつ直すだけでは足りない」と考えている
興味深いことに、この議論をしているのはAI脆弱性探索へ否定的な人だけではありません。
Anthropicで働くエンジニアAlex Gaynorも、2026年7月に「You can’t bug fix your way out of the vulnpocalypse」を公開しました。
彼が紹介しているのが、以前関わったVBScriptのコードベースです。
そこではSQL文が各ページで文字列連結によって作られており、大量のSQL Injectionが存在していました。
一件ずつ修正することもできます。
しかしGaynorらは別の方法を選びました。
安全にSQLを実行する共通関数を作る。
すべてのSQL実行をそこへ移す。
それ以外の方法でSQLを書けないよう、CIで強制する。
Gaynorによれば、この方法によって数千件規模の問題を短期間で修正し、同じ原因による再発も防ぎました。
これはモグラを一匹ずつ叩く方法ではありません。
モグラが出てくる穴そのものを塞ぐ方法です。
1件のバグではなく「その種類」を消す
David Adrianは、この方向を「invariant（不変条件）」という考え方で説明しています。
システムに、常に守られるべき条件を作る。
認証されていない処理から、このデータへ到達できない。
この権限を持たないコンポーネントから、この機能は呼べない。
この危険なAPIは通常の開発者から使えない。
そして、そのルールを「開発者が気を付ける」という約束だけにしません。
- プログラミング言語
- 型システム
- API
- 安全な抽象化
- 静的解析
- CI
- サンドボックス
- アーキテクチャ
へ組み込みます。
AIが脆弱性を見つけたときも、
「この行をどう直すか」
で終わらせない。
なぜ、この種類の危険なコードを書くことが可能だったのか。
同じ原因を持つ場所がほかにもないか。
次の人間やAIが同じコードを書こうとしたとき、そもそも書けないようにできないか。
そこまで戻ることが、AI時代にはより重要になります。
AIは防御側にとって悪いニュースなのか
ここまで読むと、AIによる脆弱性探索を止めればよいようにも見えます。
そうではありません。
見えない脆弱性より、攻撃される前に見つけられる脆弱性の方が良い。
AIは防御側にとって非常に強力な道具です。
問題は攻撃側も同じ技術を利用できることです。
Google Threat Intelligence Groupは2026年5月、AIで開発されたとみられるゼロデイエクスプロイトを使おうとした攻撃者を初めて確認したと発表しました。
一方、Google自身はBig SleepやCodeMenderを使って脆弱性を先に発見・修正しています。
つまり、AIは攻撃者だけの武器でも、防御者だけの武器でもありません。
「脆弱性を見つけられる能力」が広く安くなっていくこと自体が変化です。
AIによる攻撃能力がより一般的なモデルへ広がった場合の問題については、AIサイバー攻撃の民主化は迫るのか――「あと1年」警告を読むで詳しく整理しています。
Anthropicは2300件の脆弱性を開示した
この規模を実感できる数字が、AnthropicのCoordinated Vulnerability Disclosure Dashboardにあります。
2026年8月26日時点で、Anthropicは392のオープンソースプロジェクトへ2300件の脆弱性を開示しています。
把握している範囲では421件がすでに修正されました。
177件にはCVEが、285件にはGitHub Security Advisoryが発行されています。
一つの脆弱性が両方を持つ場合もあります。
さらに重要なのは、2300件がAIの発見総数ではないことです。
Anthropicのダッシュボードでは、2万6153件の発見から候補を絞り込み、外部セキュリティ企業やメンテナーによる確認を経て開示しています。
Anthropic自身も、人間によるトリアージとレビューがrate limiting step、つまり現在の律速段階になっていると説明しています。
AIが見つける。
人間が確認する。
メンテナーへ報告する。
修正する。
ユーザーへ更新を届ける。
発見が高速化すると、その後ろの工程が詰まります。
まさにVulnpocalypseです。
AIが脆弱性を「見つける」だけでなく「攻撃する」事例も出ている
さらに2026年には、脆弱性発見だけではなく、AIエージェント自身が実際のシステムへ侵入してしまう事例も確認されました。
OpenAIのサイバー評価では、隔離された環境で動いていたAIエージェント群が想定外の経路からインターネットへ接続し、Hugging Faceの本番環境まで侵入しました。
これは「AIが敵意を持った」という話ではなく、難しい課題を解こうと探索を続けた結果、許可されていない手段まで利用した事例です。
この事件については、OpenAIのAIがHugging Faceに侵入――AIエージェントは何をしたのかで、Reward Hackingや約1200体のエージェントによる情報共有まで詳しく追っています。
脆弱性を発見する能力と、その脆弱性を利用して行動する能力の境界も、以前ほど明確ではなくなっています。
70年前のハッカーに戻ってみる
AIが大量の脆弱性を見つけられるようになれば、人間のセキュリティ研究者の価値は下がるのでしょうか。
ここで1950〜70年代へ戻ってみます。
TMRCの学生は、何件のバグを見つけたかを競うために鉄道模型を改造したわけではありません。
Steve Russellたちも、CVEを取得するために『Spacewar!』を作ったわけではありません。
WozniakやHomebrew Computer Clubの人々も同じです。
目の前にある機械を理解したい。
中で何が起きているのか知りたい。
別の使い方ができないか試したい。
誰も考えていないものを作ってみたい。
設計者が想定していなかった挙動を見つけることは、その文化の一部でした。
しかし、それだけがhackではありませんでした。
だとすれば、AI時代のハッカーも「AIより先にバグを見つける人」である必要はないのかもしれません。
AIが1000件の異常を見つけたら、その1000件に共通する原因を探す。
なぜそんな異常が生まれる設計だったのかを理解する。
そして1001件目が生まれにくい仕組みを作る。
それも十分にハッカー的です。
「見つけた数」が価値だった時代の先へ
1950年代、電話交換機の部品を鉄道模型へ転用することはhackでした。
1960年代、高価なコンピュータに宇宙戦争をさせることは、それまでのコンピュータ像を変えました。
1970年代、Phone Phreakたちは巨大な電話網を自分の手で読み解き、Homebrew Computer Clubでは、まだ用途すら決まっていないパーソナルコンピュータで何ができるのかを探していました。
そこから半世紀以上。
いまAIが、人間が作ってきた巨大なコードベースを読み始めています。
ClaudeはFirefoxから2週間で22件の脆弱性を見つけました。
人間が最初の一件を確認している間に、50件の新しいクラッシュ候補が増えていました。
Chromeでは2つのリリースだけで1072件のセキュリティバグが修正されました。
Anthropicの開示件数は2300件に達しています。
発見できること自体は良いことです。
見えなかった危険が見えるようになります。
ただ、数字が大きくなるほど別の問いが残ります。
何件見つければ、セキュリティは「成功した」と言えるのでしょうか。
1万件。
100万件。
コードが増え続け、探索能力も高まり続けるなら、そのゲームには終わりがありません。
モグラを叩く速度なら、AIは人間よりずっと上手になるでしょう。
そのとき人間に必要なのは、もっと速いハンマーではないのかもしれません。
70年前のギークたちと同じようにシステムの中へ潜り込み、
「そもそも、なぜこんな動きができるようになっているんだ？」
と問い直すことです。
Vulnpocalypseの先で変わるのは、ハッカー文化が存在するかどうかではありません。
「発見」の値段が下がったあと、何をした人を優れたハッカー、優れたセキュリティエンジニアと呼ぶのか。
その基準の方が変わり始めています。
よくある質問
Vulnpocalypseとは何ですか？
Vulnerability（脆弱性）とApocalypse（黙示録）を組み合わせた言葉です。2026年には、AIなどによって既存ソフトウェアから大量の脆弱性を高速に発見できるようになり、従来のトリアージや修正体制では処理しきれなくなる問題を説明する言葉として使われています。
AIが脆弱性を大量に見つけるのは良いことではないのですか？
攻撃者より先に発見して修正できれば、防御側にとって有益です。問題は発見数や修正数だけを成功指標にしてしまうことです。同じ原因を持つ脆弱性が繰り返し生まれるなら、その原因を言語、API、CI、アーキテクチャなどのレベルで取り除く必要があります。
Chromeの1072件はすべてAIが見つけたのですか？
いいえ。Googleが発表した1072件はChrome 149と150で修正されたセキュリティバグの合計です。GoogleはAIを発見、修正候補生成、レビュー支援、テストなどへ広く導入していますが、1072件すべてをAIが単独発見したという意味ではありません。
Anthropicの2300件はすべてCVEですか？
いいえ。2026年8月26日時点で2300件の脆弱性がメンテナーへ開示されていますが、CVEが発行されたものは177件、GitHub Security Advisoryは285件です。一つの発見が両方を持つ場合もあります。
AIによって人間のセキュリティ研究者は不要になりますか？
現在の事例からそのようには言えません。AIは探索や修正候補作成を急速に自動化しています。一方、大量の発見から共通原因を見つけ、再発しないアーキテクチャや開発環境へ落とし込む仕事は、個々の脆弱性を見つける作業とは別です。
参考・参照元
- MIT Tech Model Railroad Club
- Anthropic「Partnering with Mozilla to improve Firefox’s security」
- Mozilla「Hardening Firefox with Anthropic’s Red Team」
- Anthropic「Coordinated Vulnerability Disclosure Dashboard」
- Google Chrome Security Team「Stronger with every update」
- Google Threat Intelligence Group「AI-powered threats and our latest defenses」
- Security Cryptography Whatever「Facing the Vulnpocalypse With lcamtuf」
コメント