AIスパムの急増で取り締まりへ：AppleとGoogleのバグ報奨金ルールが収束

低品質なAI生成の脆弱性報告が前例のない規模で急増したことを受け、AppleとGoogleのバグ報奨金ルールは同じ転換点に達している。

報道によれば、Appleはセキュリティポータルで研究者が維持できる有効な報告件数に上限を設けた。さらに、その上限に達した研究者には待機期間も導入した。現在公開されている同社のルールでは、無効な報告を繰り返した場合、より長期の停止や最終的なプログラムからの除外を科す可能性が示されている。

この比較が重要なのは、Googleがすでに、AI生成レポートの大量流入を受けてオープンソース脆弱性プログラムを厳格化していたためだ。GitHubも参加要件を引き上げ、報酬体系を再設計した。これらの動きは、脆弱性発見の自動化が、希少なリソースである専門家による人手レビューと衝突したことを示している。

この対立は、単純にAI対セキュリティ研究者という構図ではない。拡張可能な発見能力と、検証可能な証拠との対立だ。AIシステムはもっともらしい弱点を数百件提示できるが、セキュリティチームは依然として各主張を再現し、攻撃者がそこへ到達できるかを判断しなければならない。

この不均衡は、不穏な逆転を生む。AIは本来、防御側が重大な欠陥をより迅速に見つけるための支援役となるはずだった。しかし未検証の報告は、即時の対応に値するレポートを埋もれさせかねない。

Apple、セキュリティキューに新たな障壁

Appleの対応は提出量を対象としているが、公開ルールは検証と研究者の行動により直接的に焦点を当てている。

元の上限に関する報道によると、Appleは有効な脆弱性報告の件数上限と、その上限に達した研究者向けのクールダウン期間を導入した。研究者は、自身の作業が追加の処理枠に値する場合、より高い上限を申請できるとされる。

この運用上の制限は、Appleの現行Security Bountyガイドラインで公表されている制裁とは別のものだ。Appleは、研究者が不適格な発見を繰り返し提出した場合、報告の処理を180日間停止できるとしている。

停止期間が2回を超えると、プログラムから恒久的に除外される可能性がある。停止中、研究者は通常、報酬、アドバイザリーでのクレジット、通常の報告処理を受けられなくなる。

Appleはいくつかの限定的な例外を設けている。停止された研究者でも、該当するTarget Flagを取得した証拠、またはiOSもしくはmacOSの完全にパッケージ化された仮想化環境を含む証拠は提出できる。

Target Flagとは、エクスプロイトが指定されたセキュリティ境界に到達したことを証明するため、Appleのシステム内に配置された保護値である。これは理論上の主張を測定可能な証拠へと変換する。

Appleの報告ガイドラインは現在、有効な提出に必要な複数の要件を挙げている。報告には正確な説明、動作するエクスプロイトまたは信頼できる概念実証、そして簡潔な再現手順が必要だ。

同社は研究者に対し、AIツールで生成した長文の説明を避けるよう明示的に求めている。また、適切な検証を欠く理論上のAI発見は不適格に分類している。

これらの規定は、AI支援による研究を禁止するものではない。調査中にAIを用いることと、AIモデルの未検証出力をAppleのキューへ移すことの間に線を引くものだ。

Appleの別のプログラム規約も、この区別を補強している。同社は、繰り返されるスパム、虚偽の主張、またはレビューされていないAI支援による提出を理由に参加を終了できる。

この組み合わせにより、Appleは複数の執行レイヤーを得る。ポータル上の上限は同時に扱う量を制限し、180日間の停止は反復的な低品質行為に対処する。改善しない研究者に対しては、恒久的な除外も可能だ。

この違いは重要だ。上限だけでは品質を見極められないためである。慎重な研究者が、正当な複数の発見を同時に調査中である場合もある。一方、スパマーは報告件数が少なくても、多くの時間を消費させる可能性がある。

そのためAppleは、より強い証拠を例外として機能させている。信頼できるエクスプロイト、再現可能な挙動、対象の確認があれば、報告は件数制御を越えて進められる。

この変更は、有用な脆弱性発見の定義も狭める。疑わしいコードを見つけるだけでは、もはや十分ではない。研究者は、攻撃者がそのコードにどう到達するか、そして攻撃者がどのような制御、データ、権限を得るのかを説明しなければならない。

この基準は、経験豊富なバグハンターには馴染み深いものだ。変わったのは、AI生成による大量投稿への対応として、それを明示的に述べる必要が生じたことである。

AppleとGoogleの対応が今に至った理由

AppleとGoogleによる取り締まりは、経済的な非対称性を反映している。機械はセキュリティ上の主張を安価に生成できる一方、エンジニアはそれらを一件ずつ無効化しなければならない。

生成モデルはコードを走査し、安全でないパターンを説明し、攻撃シナリオを起草し、専門的に見える報告書を整形できる。しかし、これらの能力はいずれも、サポート対象の製品構成で脆弱性が実際に機能することを立証するものではない。

モデルは到達不能なコード内のバッファオーバーフローを特定するかもしれない。権限境界を誤解したり、存在しない関数を作り出したりすることもある。通常のソフトウェア不具合の影響を過大評価する可能性もある。

それでも各主張は、一見しただけでは信頼できそうに見える。セキュリティエンジニアは関連コードを調べ、テスト環境を構築し、挙動を再現し、現実世界での露出を評価しなければならない。

Googleは2026年3月、Open Source Software Vulnerability Reward Programを変更した際、まさにこの問題を説明した。同社は数週間のうちにAI生成レポートが大幅に急増したと述べている。

Googleは、幻覚によるトリガー条件、無視できるほど小さいセキュリティ上の影響、到達不能なコードパスにおける発見を確認した。そのため同社のOSSルール更新では、プログラムの一部についてより強力な証明が求められるようになった。

リポジトリのティアに応じて、受け入れられる証拠にはOSS-Fuzzによる再現やマージ済みのパッチが含まれる。OSS-Fuzzは、オープンソースソフトウェア向けのGoogleの継続的ファジングサービスだ。

Googleはその後、一部の下位ティア製品の脆弱性やその他のセキュリティ問題について、金銭的報酬と公開クレジットを廃止した。この変更は報告形式だけでなく、インセンティブ構造そのものを変えた。

Appleは異なる運用ルートを取った。報じられた上限は、1人の研究者に紐づく有効案件の数を制御する。文書化された方針では、繰り返される報告が理論的または無効なままである場合に、停止を科すとしている。

どちらのアプローチも、希少なトリアージ資源が尽きる前に摩擦を加える。洗練された文章が検証済みの脆弱性と同義だとは、いずれも見なしていない。

「slop」という言葉は、実際の仕組みを覆い隠しかねない。問題はAIが文章を書いたことではない。問題は、自動生成によって、かつては推測的な報告を抑制していた自然なコストが取り除かれることだ。

生成AI以前、説得力のある脆弱性報告を作成するには、相当な手作業が必要だった。研究者は通常、対象を調べ、想定外の挙動を引き起こし、再現可能な結果を記録しなければならなかった。

AIは、文書を作るコストを下げる一方で、証拠を作るコストを必ずしも下げない。その結果、見た目が技術的実体を上回る報告が増える。

報奨金制度はこの行動を増幅しうる。受理された提出が1件でも報酬を得られる可能性があれば、自動化システムは多数の推測的な試みを生み出せる。

提出者が追加の主張ごとに負担するコストは小さい。受け取る組織は、そのたびに専門家レビューのコストを支払う。

これは典型的なキューの問題だ。無効な到着件数がレビュー能力を上回る速度で増えれば、正当な案件は品質に関係なく待たされる。

レビュー担当者を増やすことは、部分的な答えにすぎない。経験豊富なプロダクトセキュリティエンジニアの採用は難しく、トリアージ業務は修正、脅威分析、インシデント対応と競合する。

自動トリアージは報告の優先順位付けに役立つが、別の検証レイヤーを導入することにもなる。分類器は、本物のエクスプロイトを拙く説明した非定型な報告を抑制する可能性がある。

したがってAppleとGoogleの対応は、人による検証を不可欠なチェックポイントとして扱っている。AIは発見を支援できるが、提出前に主張を証明する責任は人に残る。

真のトレードオフはアクセスとシグナルの間にある

より強いゲートはセキュリティチームを守りうるが、新たな研究者を不利にし、異例の発見を遅らせる可能性もある。

オープンなバグ報奨金プログラムは、企業の防御範囲を広げる。独立した研究者は、社内チームが見落とす可能性のある構成、コンポーネント、攻撃経路を検証する。

この開放性が機能するのは、参加に雇用、組織上の地位、ベンダーとの既存関係を必要としないからだ。強力な発見を1件持つ研究者は、既存のセキュリティ企業と同じキューに入ることができる。

提出上限はこの均衡を変える。レビュー能力を維持する一方で、アクセスを過去の報告品質や利用可能な枠に条件付けることになる。

正当な発見が複数同時に届く場合、そのリスクはより明確になる。大規模なプラットフォームを監査する研究チームは、集中的なプロジェクトの中で、多くの関連脆弱性を特定する可能性がある。

先行する案件が未解決のままであれば、新たな証拠が確かなものであっても、チームは有効報告の上限に達しうる。上限引き上げの申請は救済策となり得るが、その判断は依然としてプログラム運営者に委ねられる。

Appleには、自社のキューを守る正当な理由がある。同社のセキュリティプログラムは、大規模なデバイス基盤で利用される製品や一般向けサービスを対象としている。

同社によれば、報奨金の対象となるのは、最初に提出された完全かつ実行可能な報告のみだ。このルールにより、複数の研究者が同じ弱点を調べている場合、迅速な提出が重要になる。

そのため、上限は意図しない競争を生む可能性がある。研究者は、ユーザーへの影響が最も大きい問題ではなく、報酬を得る可能性が最も高い報告を優先するかもしれない。

Appleは、完全な証拠を重視することで、この圧力に対抗しようとしている。信頼できる再現を伴わない急ぎの報告は、先に届いたとしても不適格のままだ。

この方針に対する懐疑的な問いは、Appleが件数と悪用を一貫して区別できるかどうかだ。公開文書は報告を実行可能にする要件を説明しているが、すべてのトリアージ基準やエスカレーション判断を開示してはいない。

研究者はまた、無効なAIレポートがAppleのシステムにどれだけ流入しているかを独自に測定できない。同社は問題を説明しているが、詳細な月次内訳は公表していない。

この不在はAppleの対応を無効にするものではない。ただし、上限が適切な規模か、また処理時間を改善するかについて、外部からの評価を制限する。

ベンダーの対応時間をめぐる過去の懸念は、透明性を重要なものにしている。研究者は、沈黙が弱い報告、長期にわたる調査、あるいは無関係な提出で圧迫されたキューのどれを意味するのかを知る必要がある。

実装の悪いゲートは、責任ある開示を阻害しかねない。非公開で提出できない研究者は、報告を先延ばしにしたり、別の調整役に持ち込んだり、プロセスへの信頼を失った後に公表したりする可能性がある。

修正前の公開開示は、ユーザーのリスクを高めうる。Appleのルールでも、時期尚早な開示は報奨金の支払い対象外となる。

したがって同社は、受け入れる経路と適格性を維持する条件の両方を管理している。この仕組みは、研究者が迅速かつ具体的なフィードバックを受け取る場合に最も効果的に機能する。

最も擁護しやすい基準は、証拠に基づく摩擦だ。幻覚による発見を繰り返し提出する研究者は制限を受けるべきである。再現可能なエクスプロイトを持つ研究者には、明確なエスカレーション経路が必要だ。

AppleのTarget Flag例外は、その方向性を示している。評判だけでなく、検証可能な影響を優先するものだ。

とはいえ、Target Flagはすべての脆弱性カテゴリを対象にしているわけではない。単純なフラグベースの証明に適さない重要なロジック不備もあり、文脈に基づく判断が必要な報告もある。

単一のポリシーでこのトレードオフを解消することはできない。Appleはトリアージを保護できるほど積極的にフィルタリングしつつ、予想外の研究成果を取り込めるだけの開放性も維持しなければならない。

GoogleとGitHubが示す業界全体の転換

Appleだけが行動しているわけではなく、業界で形成されつつあるモデルは、自動検出の量よりも実証された影響を重視している。

Googleの2026年3月の更新は、最も明確な比較対象となる。同社はAIが脆弱性調査を加速できることを認める一方、調査の過程で研究者が出力を検証するよう求めている。

Googleは、AIが関与したというだけで報告を却下したわけではない。特定のリポジトリ階層について証明要件を引き上げ、価値の低いカテゴリへのインセンティブを縮小した。

同社のより広範なVulnerability Reward Programには現在、技術的な正確さ、応答性、事実の正確性といった報告品質の要素が含まれている。公開ルールでは、「AI slop」を品質上のマイナス要因として挙げている。

この表現は、脆弱性の申し立てだけを評価するのではなく、提出プロセス自体も評価する方向への転換を反映している。研究者は、対象を理解し、追加質問に裏付けをもって答えられることを示さなければならない。

GitHubは2026年7月に別の形態を採用した。公開バウンティプログラムを再編し、選ばれた研究者向けの恒久的な招待制トラックを設けた。

同社はまた、公開プログラムにHackerOne Signal要件を追加した。Signalは、研究者の報告が好意的な結果を得る頻度に基づく評判指標である。

GitHubによると、この要件は低労力かつAI生成の提出を減らすために設計された。7月27日以降に提出された報告は、改定後の仕組みに移行した。

GitHubの変更は、オープンプログラムが徐々に評判によるゲート付きへ変化していく様子を示している。新規研究者には、有用な実績を築くための機会が限定的に与えられる。

Appleのモデルは現時点では、第三者の評判スコアへの依存度が低いように見える。代わりに、報告基準、進行中ケースの上限、段階的に強化される制裁を組み合わせている。

3社は異なるコントロールを用いて、同じリソース配分の課題を解決しようとしている。

Googleは証拠要件を強化し、対象カテゴリを絞り込む。GitHubはアクセス、評判、報酬を調整する。Appleはキューの占有を制限し、無効な提出を繰り返す行為に罰則を科す。

これらのアプローチはシグナルを改善し得るが、それぞれ異なる排除リスクを伴う。証拠要件は成熟したツールを持つ研究者に有利となる。評判ゲートは既存の参加者に有利となる。上限は、初期のケースが速やかに完了する人に有利となる。

この傾向は大手テクノロジー企業にとどまらない。オープンソースのメンテナーも、ボランティアの時間を消費するAI生成の脆弱性主張を報告している。

こうしたプロジェクトでは不均衡がさらに深刻だ。人気ライブラリのメンテナーは数人しかいない一方、自動スキャナーは継続的に報告を生成できる。

バグバウンティプラットフォームは、検証されていないAI仮説に対するルールを厳格化して対応している。研究者が発見を提出する前に、手動テストと確認を求めるものもある。

この収束が明確にするのは、業界が機械支援によるセキュリティ研究を禁止しているのではないという点だ。説明責任を伴う人間の検証がない、機械生成の主張に対する報酬と注意を引き揚げているのである。

この区別は、将来のセキュリティエージェントを形作る。もっともらしい報告を生成するだけのツールは価値を失う。エクスプロイトを再現し、トレースを収集し、到達可能な攻撃経路を説明できるツールは有用性を維持するだろう。

競争上の機会は、証拠の自動化にある。セキュリティエージェントは、不審なコードを特定した時点で止まるべきではない。

テストケースを構築し、影響を受けるバージョンを確認し、前提条件を切り分け、結果として生じる権限またはデータ露出を記録すべきだ。その後、開示前に人間の研究者がその証拠を検証しなければならない。

したがって、AppleとGoogleの比較は単なるポリシーの話ではない。次世代の自動化セキュリティツールに必要な製品要件を定義している。

AIは実際の脆弱性を見つけられるが、証明は依然としてボトルネック

包括的なAI禁止に反対する最も強い根拠は単純だ。自動化システムはすでに、実在するセキュリティ上の発見に貢献している。

Googleは、Google DeepMindとProject Zeroが開発したエージェントであるBig Sleepなどのプロジェクトを通じて、AI支援による脆弱性研究を推進してきた。このプロジェクトは、モデルの推論と既存のセキュリティツールを組み合わせている。

この取り組みは、企業が全面禁止を避けている理由を示している。AIは大規模なコードベースを探索し、仮説を生成し、研究者が複雑な相互作用を調査するのを支援できる。

Appleのルールもこの区別を維持している。AI支援で開発されたすべての発見ではなく、適切な検証を伴わないAIの発見に言及している。

研究者はモデルを使ってソースコードを調査したり、報告書を改善したりできる。だが最終提出では、観測された挙動、期待される挙動、回避された仕組み、そして信頼できる攻撃結果を説明しなければならない。

信頼できる概念実証は引き続き中心的な要素である。概念実証とは、定義された条件下で脆弱性を示す最小限のテストである。

複雑な攻撃チェーンについて、Appleはコンパイル済み版とソース版、必要なペイロード、チェーンを実行するために必要なすべての要素を求めている。この要件は、説明上の確信より再現性を優先している。

Appleには、高品質な外部研究を維持する理由がある。以前のバウンティ更新で、同社は2020年に公開プログラムを開始して以来、800人超の研究者に総額3,500万ドル超を支払ったと述べている。

また、個人への報奨として50万ドルが複数回支払われたとも報告している。これらの数字は、外部からの提出がAppleのセキュリティプロセスにおける周辺的な要素ではないことを示している。

課題は、自動化が拡大するなかで、このチャネルを利用可能な状態に保つことだ。トリアージチームが捏造されたシナリオの反証に時間を使いすぎれば、プログラム全体の価値が下がる。

ただし、自動化トリアージを無謬のものとして扱うことはできない。異例のエクスプロイトは、レビュー担当者が想定しなかった境界をまたぐため、誤検知に見える場合がある。

モデルベースのフィルターは、従来型の報告構造を優遇する可能性もある。洗練されていない英語や馴染みのない手法を使う研究者は、有効な証拠があっても低いスコアを受けるかもしれない。

Appleは、報告には人間によるレビューを行い、AIは受信案件の優先順位付けを支援するとしている。この分担により、最終判断を完全に分類器へ委ねることなく、管理業務を減らせる。

詳細は依然として重要である。研究者は、自動化された優先順位付けが応答時間、適格性、あるいはキュー順序のみに影響するのかを知る必要がある。

偽陰性はスパムとは異なるリスクを生む。無効な報告が却下されれば研究者の時間が無駄になる。有効な報告が却下されれば、何百万台ものデバイスが露出したままになる可能性がある。

解決策は、生成されたすべての主張を受け入れることではない。強力な発見が初期の誤分類から回復できるよう、異議申し立て、エスカレーション、証拠基準を十分に明確にすることだ。

セキュリティチームは、件数削減だけでなく成果も測定すべきである。成功するポリシーは、重大な報告の検証までの時間を短縮しつつ、受理される高影響度の発見の数を抑制しないものであるべきだ。

研究者にも責任がある。モデルの出力を再現し、影響を受けるバージョンをテストし、前提条件を説明し、実験で裏付けられていない推測的な表現を削除すべきだ。

AI生成の文章は、不確実性を確実性のように見せることがある。人間によるレビューは、観測結果と仮定を分けることで、この傾向を逆転させなければならない。

有用な報告は、4つの具体的な問いに答えるべきだ。どの入力が挙動を引き起こすのか。どのサポート対象構成が影響を受けるのか。どのセキュリティ境界が破綻するのか。攻撃者は何を得るのか。

これらの答えが欠けている場合、文章を増やしても報告は改善しない。不足する証拠を見つけるためのコストが増えるだけだ。

AIバグ報告取り締まり後に注目すべき点

次の試金石は、厳格なルールが信頼できる研究者を遠ざけずに応答品質を改善できるかどうかだ。

最初のシグナルは、Appleの報告処理パフォーマンスとなる。初期レビューの時間が短縮されれば、無効な提出が重要な処理能力を消費していたというAppleの主張を裏付けることになる。

Appleは現在、キューの規模、却下理由、応答時間の中央値を網羅する詳細な公開ダッシュボードを提供していない。透明性が高まれば、ポリシーの効果を判断しやすくなる。

研究者は間接的な証拠を提供できる。受領確認の迅速化、より明確なステータス更新、長期化する案件の減少が報告されれば、コントロールが機能していることを示唆するだろう。

逆のパターンはAppleの説明を弱める。件数制限後も正当な報告が遅延するなら、ボトルネックは人員、社内調整、あるいは是正能力にある可能性がある。

2つ目のシグナルは、大量報告を行う研究者の扱いだ。Appleは上限引き上げのリクエストを認めていると報じられており、検証済みの発見を持つチームにとって重要な逃げ道となる。

こうしたリクエストに迅速な判断が下されるか、また承認が評判だけでなく証拠によって決まるかを注視すべきだ。

適切に機能する例外プロセスなら、本格的なチームは集中監査を継続できる。不透明なプロセスなら、進行中報告の上限は恣意的に感じられるだろう。

Googleは有用な外部ベンチマークを提供する。同社のより高い証明要件は無効な報告を減らすはずだが、下位層のオープンソースプロジェクトにおける参加も減らす可能性がある。

両プログラムが低価値のキュー流入を削減しながら強い発見率を維持できれば、AppleとGoogleのポリシーはより説得力のあるものに映るだろう。提出総数の減少だけでは、成功の証明にはならない。

3つ目のシグナルは、セキュリティツールベンダーとAIエージェントからもたらされる。市場には現在、洗練された脆弱性の推測ではなく、再現可能な成果物を生み出す明確なインセンティブがある。

有用なツールは、実行トレース、バージョン情報、テスト環境、エクスプロイトの前提条件を統合する。また、不確かな推論を確認済みの挙動として提示するのではなく、不確かであることを明示する。

プログラム運営者は、機械可読な提出スキーマによってこの移行を支援できる。必須フィールドでは、観測結果、推定される影響、環境の詳細、人間による検証手順を分けられる可能性がある。

標準化された証拠は、専門家の判断を置き換えることなく、自動化された振り分けを改善できる。また、大量提出の監査も容易になる。

より難しい問いは、攻撃者が開示ルールに縛られずに同じ自動化の恩恵を得るかどうかだ。攻撃者は、悪用前にベンダーへ脆弱性を証明する必要がない。

したがって、防御側は悪質な自動化に対して自動化そのものを拒絶することで対応することはできない。より優れたエージェント、より強力な検証パイプライン、そして信頼できる発見に対する迅速な人間のエスカレーションが必要である。

Appleの当面のポリシーは、バウンティプログラムの玄関口を守る。だが、機械規模での脆弱性発見という、より広範な課題を解決するものではない。

研究者にとって実務的なメッセージは明確だ。AIを使って探索空間を広げる一方、再現でき、技術的な質問に対して擁護できるものだけを提出すべきである。

エンジニアリングリーダーにとって、この教訓はバグバウンティを超えて広がる。外部で生成されたAI出力を受け入れるあらゆるワークフローには、証拠、説明責任、レビューコストに結び付いたゲートが必要である。

AppleとGoogleのポリシー転換は最終的に、フィルタリング後に何がエンジニアへ届くかで判断される。キューに入る報告は少なくなるだけなのか、それともより良い報告になるのか。

この違いが次の段階を導くべきだ。応答時間を追跡し、例外リクエストがどのように機能するかを見守り、自信に満ちた文章ではなく証拠を生み出すセキュリティエージェントに注目してほしい。