AI・テクノロジー

Googleがオープンソースバグ報奨金を凍結――AI生成の偽脆弱性報告「AIスロップ」急増とバグバウンティの構造的危機

Googleが2026年10月1日付でオープンソース脆弱性報奨金（OSS VRP）の製品バグ受付を2027年まで一時凍結しました。LLMが生成した動かないPoCやハルシネーションによる虚偽報告（AIスロップ）が殺到し、審査体制が破綻した背景と、バグバウンティ制度が直面する構造的危機を徹底解説します。

claude

• 12 min read
Share

「誰でもコードの欠陥を見つけて報告すれば、最高3万1337ドルの報奨金が支払われる」――オープンソースソフトウェアの安全を善意と技術力で支えてきたGoogleの代表的プログラムが、突如として門戸を閉ざしました。

Googleは2026年10月1日付で、同社のオープンソース脆弱性報奨金プログラム「OSS VRP（Open Source Software Vulnerability Reward Program）」における製品脆弱性報告トラックの新規受付を一時停止（Pause）したと発表しました。再開に向けた方針のアップデートは「2027年第1四半期」とされており、少なくとも今後数ヶ月間にわたり主要な報告窓口が完全に凍結されます。

停止の直接の引き金となったのは、大規模言語モデル（LLM）や自律型エージェントを用いて大量生成された、いわゆる「AIスロップ（AI slop＝AIが撒き散らす低品質なゴミ情報）」の爆発的な急増です。実在しない関数を指摘するハルシネーション（幻覚）や、実行しても何も起きない捏造されたPoC（概念実証コード）を抱えた報告書が審査キューを埋め尽くし、世界最高峰のエンジニア集団であるGoogleのトリアージ体制すらも機能不全に追い込みました。

しかし、この事態はGoogle一社の問題にとどまりません。すでにcurlプロジェクトやLinuxカーネルの現場でも同様の疲弊が表面化しており、1990年代のNetscapeに端を発する「オープンな受信トレイと成果報酬」に基づくバグバウンティモデルそのものが、AI時代における根本的な構造破壊に直面しています。

本記事では、Google OSS VRP凍結の正確な事実関係と対象範囲を整理した上で、なぜ自動化ツールが防御側のコストを破綻させたのかという経済的メカニズム、オープンソース界全体に波及する危機の連鎖、そして2027年に向けたバグバウンティ再設計のシナリオを多角的に解説します。

1. 何が起きたのか：Google OSS VRP凍結の事実関係と対象範囲

1.1 2026年10月1日の公式発表と停止の背景

Googleは2026年10月1日、公式X（旧Twitter）および同社セキュリティポータルにおいて、OSS VRPの一部受付を一時停止することを告知しました。同社は声明の中で、次のように理由を明かしています。

「この一時停止は、自動化された提出物（automated submissions）の著しい急増によるものであり、その大部分は有効なものではありません（the vast majority of which are not valid）」

TechCrunchやTom's Hardwareなどの報道によると、Googleのセキュリティエンジニアおよびオープンソースメンテナは、ここ数ヶ月間、毎日のように送りつけられる無効な報告の検証に追われ、本来対処すべき本物の脆弱性の調査や修正作業に深刻な遅延が生じていたとされます。

プログラムの今後に関する更新は「2027年第1四半期」に示される予定であり、短期間のトラブルシューティングではなく、制度自体の根本的な見直しを伴う長期の一時停止となります。

1.2 OSS VRPの歴史と「自己規律型エコシステム」の歩み

OSS VRPは、2022年8月にGoogleが鳴り物入りで開始したプログラムです。Log4jの深刻な脆弱性（Log4Shell）などを契機にオープンソースサプライチェーンの安全性が世界的な課題となる中、Googleが管理・支援する重要なOSSプロジェクトのセキュリティ向上を目的として創設されました。

対象には、Googleが主導するGo言語（Golang）、Angular、Protocol Buffers、Bazel、Fuchsiaなどの著名なプロジェクトが含まれ、報奨金の支払額は脆弱性の深刻度に応じて100ドルから最大3万1,337ドル（約460万円、ハッカー文化のLEET表記『31337＝ELEET』に由来）に設定されていました。

このプログラムが2022年の発足から数年間にわたり健全に機能していた背景には、「高い参入障壁」による自然な自己規律がありました。成熟した大規模コードベースから悪用可能な脆弱性を探し出すには、深いアーキテクチャ理解、リバースエンジニアリング技術、そして手作業での緻密なPoC作成が不可欠だったためです。提出されるレポートの母数は自ずと限られ、トリアージ担当者も1件1件を丁寧に対話・検証することが可能でした。

1.3 凍結された範囲と維持された範囲

今回の停止措置は、見出しだけを見ると「Googleのバグ報奨金が全停止した」と受け取られがちですが、実際には対象範囲が厳密に切り分けられています。

トラック／プログラム 2026年10月1日以降のステータス 詳細と対象
OSS VRP：製品脆弱性報告 一時停止（Frozen） Go、Angular、Protobufなどのソースコード内のバグ報告。2027年Q1まで新規受付不可。
OSS VRP：サプライチェーン報告 継続（Active） ビルドパイプラインの侵害、CI/CDの設定不備、依存パッケージの改ざん等の報告。
OSS VRP：10月1日以前の提出分 継続処理（Processing） 凍結前に提出された既存レポートは通常通り順次審査・支払いが行われる。
Cloud VRP（製品バグ） 継続（Active） Google Cloud製品に関連する一部の公開リポジトリは、Cloud VRP経由で受付を継続。
Chrome VRP / Android VRP 継続（Active） ブラウザやOS本体を対象とする基幹VRPは別枠で運用継続。

停止されたのは、一般のセキュリティ研究者が最も頻繁に利用していた「リポジトリのコードを読んでバグを指摘し報酬を得る」という王道ルートです。なぜこの主要ルートが、AIの登場によって真っ先に崩壊してしまったのでしょうか。

2. なぜ制度は破綻したのか：「AIスロップ」とコストの非対称性

2.1 「AIスロップ」とハルシネーション報告の解剖

現在セキュリティ現場を疲弊させているのは、高度なサイバー攻撃ではなく、LLMによって自動生成された粗悪なレポート群――すなわち「AIスロップ（AI Slop）」です。

攻撃者（または報奨金目当てのスクリプトキディ）は、オープンソースのGitHubリポジトリ全体をクローンし、コード要約プロンプトとともにLLM APIへ流し込みます。「このコードに含まれる潜在的な脆弱性をCVEフォーマットで出力し、CVSS深刻度スコアとPoCを作成せよ」といった指示を与えるだけで、数分で数十件のレポートが自動出力されます。

こうして生成されたレポートには、人間の目を欺く巧妙な特徴と、現場のエンジニアを激怒させる致命的な欠陥が同居しています。

  1. 存在しない関数・APIへの言及（幻覚）: LLMは過去のバージョン、別言語の同名ライブラリ、あるいは全く異なるプロジェクトの知識を混同し、「このAPIを呼び出すとメモリ破壊が起きる」と自信満々に主張します。しかし、対象のリポジトリにはそのようなAPI自体が存在しません。
  2. モックや構文エラーだらけの偽PoC: レポートには一見それらしいPythonスクリプトやcurlコマンドが「PoC（実証コード）」として添付されています。しかし実行してみると、インポートしたライブラリが存在しなかったり、ダミーのprint("Vulnerable!")を出力するだけの無意味なスクリプトだったりします。
  3. 到達不可能なデッドコードやテストコードの過大評価: 本番環境では決して呼ばれない単体テスト用のモックコードや、すでに非推奨となって隔離された内部処理を指して、「緊急（Critical）のバッファオーバーフロー」と騒ぎ立てます。

2.2 コストの極端な非対称性：数セントの生成 vs 数時間の検証

この問題が破滅的なのは、「提出者側のコスト」と「防御者側のコスト」の間に天と地ほどの非対称性が存在する点にあります。

flowchart LR
    subgraph Submitter["提出者（AIスロッパー）"]
        A["リポジトリ取得"] --> B["LLM APIで一括走査"]
        B --> C["未検証レポート自動生成"]
        C --> D["大量自動送信（数千件）"]
    end

    subgraph CostSubmitter["提出側コスト"]
        D --- E["コスト: 数セント / 時間: 数分<br>インセンティブ: 当たれば数万ドル"]
    end

    subgraph Receiver["受信側（Googleエンジニア / メンテナ）"]
        F["レポート読解"] --> G["コードベース照合"]
        G --> H["環境構築とPoC実行"]
        H --> I["反論作成・無効クローズ"]
    end

    subgraph CostReceiver["受信側コスト"]
        I --- J["コスト: 数時間 / 人月大幅浪費<br>結果: 精神的摩耗・本物のバグ見逃し"]
    end

    Submitter -->|大量送信| Receiver

提出者側は、OpenAIやAnthropic、ローカルモデルのAPIを回すだけであり、1件のレポートを作成する費用は数円から数十円、作業時間はほぼゼロです。そして、仮に1,000件送信して999件が無効でも、たった1件が審査をすり抜けて承認されれば、数十万〜数百万円の報酬が手に入ります。つまり提出者側にとって、バグ報告は「元手のほぼかからない宝くじ」と化しています。

対照的に、Googleのトリアージエンジニアやメンテナ側の負担は甚大です。責任あるベンダーである以上、届いた報告が「本当に脆弱性ではない」と証明する責任は受取側にあります。レポートを読み、該当するコミット履歴を確認し、安全な検証環境を立ち上げてPoCを走らせ、動かない理由を突き止め、報告者に対して角が立たないよう技術的な根拠を添えて「無効（Invalid）」としてクローズしなければなりません。

1件の無効レポートを処理するのに30分から2時間を要するとすれば、1日数百件の報告が届くだけで専任チーム全体のキャパシティは完全にパンクします。Googleは2026年初頭にガイドラインを改定し、「実環境での影響（real-world impact）」の提示を義務付けるなど防衛線を張りましたが、生成AIの圧倒的な物量作戦の前にはルール改定だけでは防ぎきれなかったのが実情です。

3. オープンソース界全体に広がる悲鳴：curl、Linux、そしてプラットフォームの苦悩

GoogleのOSS VRP凍結は、孤立した事件ではありません。オープンソースエコシステム全体が、ここ1〜2年で全く同じ「AI公害」に晒され、悲鳴を上げてきました。

3.1 curlプロジェクト（Daniel Stenberg氏）の決断

インターネットの通信基盤として世界中のシステムに組み込まれている「curl」の創始者兼主任開発者、ダニエル・ステンバーグ（Daniel Stenberg）氏は、早くからこの問題に警鐘を鳴らし続けていました。

curlはかつてHackerOne上でバグ報奨金プログラムを運営していましたが、LLMの普及に伴い、AIが生成した架空の脆弱性報告が殺到しました。ステンバーグ氏は自身のブログで、毎週末のように「存在しないバッファオーバーフロー」や「無害な挙動を深刻なセキュリティ欠陥と偽る報告」の対応に追われ、無給のメンテナが疲弊しきっている現状を痛烈に告発しました。

結果として、curlはバグ報奨金プログラム自体の終了を決断せざるを得なくなりました。ステンバーグ氏は「報奨金という金銭的インセンティブがある限り、AIを使ってゴミを投げつけるスパマーを止めることはできない」と語り、善意のコミュニティが破壊された無念さを表明しています。

3.2 Linuxカーネルメンテナの疲弊とカーネルサイクルの遅延

世界最大のオープンソースプロジェクトであるLinuxカーネルでも、同様の深刻な事態が進行しています。Phoronix等の報道によると、Linuxのネットワーキングサブシステムのメンテナたちは、AIツールによって自動生成されたパッチやバグ報告の津波に飲み込まれています。

一見すると綺麗にフォーマットされたC言語のパッチコードですが、詳細にレビューするとエッジケースでメモリリークを引き起こしたり、カーネルの設計思想を根本から無視した壊れた変更が含まれていたりします。メンテナがこれら粗悪な投稿の確認と却下に追われた結果、正規の開発者から提出された重要なセキュリティ修正や機能改善のトリアージが遅れ、パッチの適用が次のカーネルリリースサイクルへ延期されるという実害が発生しています。

3.3 バグバウンティプラットフォーム（HackerOne / Bugcrowd）の防衛線

世界的なバグバウンティプラットフォームであるHackerOneやBugcrowdも、この問題に対処するため行動規範（Code of Conduct）を相次いで改定しています。

  • 「完全自動生成・未検証」の報告の禁止: AIツールを調査の補助として使用することは許可するものの、人間が実際に動作を確認し、再現性を担保した上で提出することを義務付け。
  • アカウントペナルティの強化: 低品質なAIレポートを乱発する提出者に対し、評価スコア（Reputation）の剥奪やアカウント停止措置を実施。

しかし、プラットフォーム側の対策にも限界があります。提出者が「これは私が手作業で見つけたバグだ」と主張した場合、AI生成であることの完全な立証は極めて困難です。フィルタリングの網をすり抜けたレポートは、最終的に各プロジェクトのエンジニアの受信トレイへ到達し、そこで人間が時間を消費して破棄するほかないのが現状です。

4. 皮肉なパラドックス：AIによる脆弱性発見の進展と「トリアージの崩壊」

この問題の根底には、テクノロジー業界が直面する痛烈なアイロニー（皮肉）が存在します。それは、「AIによる脆弱性発見」という技術自体は、歴史上類を見ない大成功を収めているという事実です。

4.1 Google自身の「Big Sleep」と実在ゼロデイの発見

皮肉なことに、AIを使ったオープンソースの脆弱性発見において世界をリードしてきたのは、ほかならぬGoogle自身です。

Googleの脆弱性調査チーム「Project Zero」とGoogle DeepMindの共同プロジェクトである自律型エージェント「Big Sleep（旧Project Naptime）」は、LLMを活用して実際のオープンソースコードを自律的にファジング・解析し、2025年から2026年にかけてSQLiteなどの重要OSSにおいて、人間が長年見落としていた実在のゼロデイ脆弱性を20件以上発見しました。

さらに、米国防高等研究計画局（DARPA）が主催するサイバーセキュリティ競技会「AIxCC（AI Cyber Challenge）」では、最先端のAIシステムが数十万行のコードから脆弱性を数分で特定し、自動的に修正パッチを生成する能力を実証しています。

4.2 壊れたのは「技術」ではなく「インセンティブ構造」

つまり、技術としての「AIによるコード解析・脆弱性検出」は本物であり、サイバー防衛の未来を切り拓く決定的なツールです。問題の本質は技術そのものにあるのではなく、以下の3つの要素が最悪の形で噛み合ってしまった「経済的インセンティブ設計の破綻」にあります。

【破綻の3要素】
1. 参入自由なオープン受信トレイ（誰でもアカウントを作れば提出可能）
2. 成果報酬型のインセンティブ（1件当たれば数千〜数万ドルの大金）
3. 限界費用ゼロの生成ツール（誰でも数クリックでレポートを量産可能）

かつてはこの3要素の間に「高い技術的ハードル」という自然の防波堤が存在していました。しかし、汎用LLMがその防波堤を完全に消し去った結果、オープンなバグ報奨金制度は「スパム送信者にとって最も割のいいギャンブル」へと変貌してしまったのです。

5. 2027年に向けた再設計：オープンなバグバウンティは死んだのか

Googleが「2027年第1四半期にアップデートを公表する」と約束したことは、従来のバグバウンティモデルが不可逆な転換点を迎えたことを意味しています。かつてのような「誰でも自由にレポートを送り、ベンダーが手作業で確認する」という素朴なオープンモデルに戻ることは二度とないでしょう。

業界関係者の間では、2027年の再開に向けて以下のような構造的改革案が議論されています。

5.1 想定される4つの防衛アーキテクチャ

  1. 厳格なレピュテーションゲート（信用実績制）: 新規アカウントが自由にOSS VRPへ直接レポートを提出することを禁止し、過去に実在の脆弱性報告で一定以上の実績・スコアを持つリサーチャー、あるいは身元確認（KYC）を完了した組織にのみ提出権限を付与する仕組みです。
  2. サンドボックスによるPoC自動検証パイプライン: レポート提出時に、指定されたフォーマットのDockerfileやテストスクリプトの添付を義務付けます。Google側のCI/CDパイプラインが隔離されたサンドボックス環境で自動的にPoCを実行し、脆弱性の再現がプログラム的に確認（Pass）されない限り、トリアージエンジニアの画面にすら表示されない完全自動フィルタリングです。
  3. デポジット（審査保証金）とペナルティ制度: レポート提出時に一定のデポジット（預託金）やトークンを要求し、有効な脆弱性と認定されれば報奨金とともに全額返還、明らかなAIスロップや無効報告の場合はデポジットを没収する経済的抑止策です。
  4. 招待制・事前選抜型プライベートプログラムへの移行: 一般公開のパブリックバウンティを全廃し、実績のあるトップリサーチャーのみを招待するプライベートバウンティ形式へ完全に舵を切る選択肢です。

5.2 独立系リサーチャーと初学者の登竜門喪失という代償

しかし、これらの対策はいずれも「トレードオフ（代償）」を伴います。

バグ報奨金制度の最大の功績は、世界中の名もなき学生、独学のプログラマー、新興国のセキュリティリサーチャーが、自らの腕一本で巨大テック企業に実力を認められ、公正な対価を得られる「開かれた登竜門」として機能していた点にありました。

参入障壁が高まり、実績や身元確認、厳格な自動テストが義務付けられれば、悪質なスパマーを排除できる一方で、セキュリティ業界の次世代を担う若手や独立系ホワイトハッカーの参入機会が奪われることになります。AIスロップがもたらした最大の被害者は、手作業で丹念にコードを読み、真摯に脆弱性を報告してきた誠実なリサーチャーたちなのかもしれません。

6. よくある質問（FAQ）

Q1: Googleのすべてのバグ報奨金プログラムが停止されたのですか？

いいえ、停止されたのはオープンソースを対象とする「OSS VRP」の製品脆弱性報告トラックのみです。AndroidやGoogle Chrome本体、Google Cloudなどの基幹製品を対象とする各VRPは別枠で継続して運用されています。また、OSS VRP内でもサプライチェーン攻撃に関する報告や、2026年10月1日以前に提出された既存の報告は引き続き処理されます。

Q2: 「AIスロップ（AI Slop）」とは具体的にどのようなバグ報告を指しますか？

LLMなどの生成AIを使って自動量産された、低品質かつ事実無根のバグ報告を指します。具体的には、対象のコードベースに実在しない架空の関数やAPIを指摘する「ハルシネーション（幻覚）」、文法エラーやダミーコードで実際には動作しない「捏造されたPoC（実証コード）」、本番環境では決して実行されないテストコードを大げさに危険視する報告などが含まれます。

Q3: AIを使って脆弱性を探すこと自体が禁止されたのですか？

いいえ、AIツールを用いた解析やリサーチそのものが禁止されたわけではありません。Google自身も「Big Sleep」などのAIエージェントを用いてOSSの脆弱性を発見しています。問題視されているのは、人間による動作検証や裏付けを一切行わず、LLMの出力をそのまま未検証で大量送信するスパム行為です。

Q4: curlやLinuxなど他のオープンソースプロジェクトでも同様の問題は起きていますか？

はい、全く同様の問題が業界全体で深刻化しています。通信ライブラリ「curl」はAI生成レポートの殺到により開発者が疲弊し、バグ報奨金プログラムを完全に終了しました。また、Linuxカーネルのネットワーキング開発現場でも、粗悪なAIパッチやバグ報告の確認に追われ、正規のセキュリティ修正のリリースが遅れる事態が発生しています。

Q5: 2027年以降、バグ報奨金制度はどう変わると予想されますか？

「誰でも自由にメールを送れば人間が審査してくれる」という旧来のオープンモデルは事実上終焉を迎えると見られています。2027年以降は、提出実績に基づく「レピュテーション（信用）ゲート制」、専用コンテナ環境でPoCが自動再現されることを必須とする「自動検証パイプライン」、あるいは実績者のみを対象とする招待制プライベートプログラムへの移行が進むと予想されます。

7. まとめ：自動化の逆襲を乗り越える新しいセキュリティガバナンス

Google OSS VRPの凍結は、生成AIの急速な普及がもたらした「自動化の逆襲」を象徴する歴史的事件です。

かつてオープンソースとバグバウンティの文化は、「善意のコントリビューター」と「高い技術的ハードル」という暗黙の前提の上に成り立っていました。しかし、生成AIという強力なレバレッジが一般大衆に渡ったことで、善意の制度は「コストゼロの宝くじ発券機」へとハックされ、受け手側の善意とリソースを食いつぶしてしまいました。

この事態が私たちに突きつけている教訓は明確です。「防御の自動化」を進めると同時に、「受け口（インバウンド）のガバナンス」もAI時代に合わせてゼロから再設計しなければならないということです。

機械がバグを探し、機械がコードを修正する未来が訪れようとしている今、人間とコミュニティの時間を守るための新しいプロトコルと信頼の設計が、すべてのテック企業とオープンソースプロジェクトに問われています。

参考ソース

関連記事