何が起きたか
Appleが、バグバウンティ（脆弱性報奨金）プログラムの受付方法を変更しました。1者が提出できる件数に上限を設け、社内セキュリティポータル経由の提出には30日間のクールオフ期間を課します。上限を超えて提出したい場合は、個別に申請を出す必要があります。
Financial Timesの取材によれば、この変更はAIを活用した脆弱性報告が大量に押し寄せたことへの対応です。AIはプログラム上の問題を発見・指摘する用途で確かに機能しますが、その結果として提出量が審査チームの処理能力を超えてしまいました。さらに深刻なのは、人間のセキュリティ研究者が見つけた本物のバグが、AI由来の大量の報告に埋もれてしまいかねない点です。
なぜ重要か
バグバウンティは「広く開かれた受付口」であることが価値の源泉でした。誰でも報告でき、価値ある報告に報奨金を払う。この設計は、報告のコストが人間の時間で担保されていたからこそ成立していました。AIによって報告の生成コストがほぼゼロに近づいた瞬間、開かれた受付口はそのままボトルネックに変わります。
つまりこれは「AIが脆弱性を見つけられるか」という話ではなく、「発見のコストが下がったとき、その後段にある人間の検証工程がスケールしない」という構造問題です。生成側は指数的に速くなり、査読側は線形のままです。
Appleだけの話ではない
同様の見直しは他社にも及んでいます。Googleは今年、バグバウンティプログラムを刷新し、AIが容易に見つけられる小粒なバグより、解決が難しい問題に対して高額な報奨を払う方針を明確にしました。
Appleは「量の制限」、Googleは「報酬設計による難易度への誘導」と、アプローチは異なりますが、狙いは同じ方向です。AIが安く供給できる領域から、人間の専門性でしか到達できない領域へ、インセンティブを移す。上限とクールオフは応急処置に見えますが、審査リソースを守る現実的な手段でもあります。
💼 事業会社視点：これは自社にどう効くか
この構図は、外部からの入力を広く受け付けているすべての事業に当てはまります。日本企業でいえば、問い合わせフォーム、応募・エントリー、相見積もり依頼、レビュー投稿、代理店からの申請、そして自社のセキュリティ報告窓口です。AIによって「送る側のコスト」が消えた以上、無制限の受付は遠からず機能不全を起こします。
SaaS事業者は、サポートチケットや機能要望チャネルの流量設計を今のうちに見直すべきです。ECでは、レビュー・返品申請・不正検知アラートの検証工数が同じ経路で膨らみます。受託開発会社にとっては、顧客から「AIで脆弱性を洗い出した」というリストを渡され、その一次切り分けを無償で背負わされるリスクが現実的です。契約段階で、指摘の再現性検証を誰がどこまで担うかを定義しておく必要があります。
経営者が今決めるべきは、人手を増やすかどうかではありません。Appleが上限とクールオフで量を絞り、Googleが難易度の高い発見に報酬を寄せたように、「量を制限する仕組み」と「質の高い提出に報いる設計」の両輪を、自社の受付チャネルごとに設計し直すことです。窓口ごとに、月間の処理可能件数と優先順位の基準を数値で持っておくと判断が早くなります。