GoogleがOSS報奨金を停止、確かめる費用を出す側へ── AI で減ったのは報告を書く手間だけで、確かめる手間はいまも受け取る人が負っている。受け取る人を守るのは、入口で再現の証拠を求めることである

Google は 2026 年 10 月 1 日、脆弱性の報告に報奨金を払う窓口の一部を閉じ、AI などで作られた報告の大半が使えなかったと説明した。AI で報告がただ同然に書けるようになったとき、中身を確かめる手間は誰が負うのか。いまその手間を負っているのは、報告を受け取る少数の人である。Google は報告を送る人に証拠を求めて手間の一部を送る人に戻し始め、curl は報奨金をやめた。

01Google は、報告を確かめる人の時間が足りなくなって窓口を止めた

Google は、OSS VRP と呼ぶ報奨の窓口のうち、製品の脆弱性を受け付ける部分を閉じた。理由として Google 自身は、自動で作られた報告が大きく増え、その大半が有効でなかったと理由を書いている。TechCrunch と Help Net Security の二つの媒体が、規則の頁にあるこの説明を引いて伝えた。

報告を書く手間は、AI のおかげでほとんど要らなくなった。確かめるほうは、そうはいかない。報告が本物かを確かめる手間は、いまも一件ずつ人がかけている。確かめる人は、報告に書かれた不具合を自分の計算機で起こしてみるしかない。報告を AI で書いても、この試しの時間は短くならない。報告の急増と無効の多さという Google の二つの理由を合わせると、確かめる人の時間が足りなくなって窓口を止めたと私は読む。

2026 年には、curl、HackerOne、Nextcloud も報告の窓口を閉じた。伝えられた理由を見るかぎり、どの窓口でも、報告を送る人の手間は小さく、受け取る人の手間は大きいままだったと私は読む。

AI で作った報告や申請を受け取る人に、私は一つのやり方を勧めたい。受付の段階で、不具合を再現した証拠を添えるよう求めることだ。受け取る人は、届く件数を自分では決められない。それでも、何が添えてあれば読むかは、受け取る人が決められる。

02止まったのは製品の脆弱性の受付だけで、修正への報奨は続いている

Google の停止を読むときは、止めた範囲も一緒に見ておきたい。Google の規則の頁によれば、OSS VRP は 2026 年 10 月 1 日から製品の脆弱性の報告を受け付けない。

閉じたのは、そこだけだ。脆弱性を見つけた研究者は、Google のほかの報奨プログラムか、Patch Rewards Program に送るよう案内されている。Patch Rewards Program は名前のとおり修正に報奨を出す窓口で、いまも開いている。2027 年の第 1 四半期には、新しい方針を示すと約束した。再開は約束していない。

私がこの範囲を先に書くのは、誤解を防ぐためだ。「Google がバグ報奨金をやめた」という見出しだけを読むと、すべての窓口が閉じたように見える。実際に Google がやめたのは報奨の一部で、修正への報奨は続けている。

私が直接読めていない資料も、一つある。Google が X に出した投稿の本文だ。私は、停止の理由を TechCrunch と Help Net Security が引いた言葉のまま使う。

03ほかの三つの窓口でも、報告を読む少数の人が先に手一杯になった

報告の窓口を閉じたのは、Google だけではなかった。2026 年には、ほかにも三つの組織が窓口を閉じている。curl、HackerOne、Nextcloud だ。

curl は、ネットワークでデータを送るのに広く使われるオープンソースのソフトウェアである。curl の開発者 Daniel Stenberg は、2026 年 1 月 26 日のブログで報奨金をやめると告げ、1 月 31 日で打ち切った。脆弱性の報告を仲立ちする会社 HackerOne は、Internet Bug Bounty という窓口の受付を止め、Privacy Guides という媒体が 2026 年 4 月に、AI で報告が急に増えたことへの対応だったとこの停止を伝えている。Decrypt は 5 月、HackerOne とファイル共有ソフトの Nextcloud が、偽の報告の波を受けて報奨を止めたと報じた。同じ記事によれば、報告を仲立ちする別の会社 Bugcrowd では、3 月の 3 週間で届く報告が 4 倍を超えた。

三つの窓口では、どこでも少人数の保守者や担当者が報告を読んでいた。Bugcrowd では、報告が 3 週間で 4 倍を超えた。読む人の数は、それに合わせて増えはしない。表に挙げた理由から、私はどの窓口でも報告を読む人の時間が先に足りなくなったと読む。

ここで扱う範囲は、脆弱性の報告窓口に限る。ほかの業界の窓口で同じことが起きているかどうかは、ここに挙げた資料からは言えない。

04AI で報告を書く手間は減ったが、確かめる手間は減らなかった

curl の数字を見ると、確かめる人の時間が足りなくなった理由が分かる。Stenberg によれば、以前の curl では、届いた報告の 15% 超が本物の脆弱性と確かめられていた。2025 年からは、本物と確かめられた報告が 5% を下回った。三分の一以下である。本物でなかった報告にも、保守者は一件ずつ再現を試す時間を使っている。

報告を送る人は、AI に文面を書かせれば、すぐに送れる。報告が外れても、送った人が失うものは小さい。受け取る側は違う。報告を受け取る人は、書かれた手順を自分の計算機で試し、不具合が本当に起きるかを見る。文面がどれほど整っていても、受け取る人はこの試しを省けない。

Stenberg は、報奨金のせいで、罰をほとんど受けずに迷惑な報告を送れるようになったと書いた。報奨金が出る窓口では、当たりそうにない報告でも、送れば得をする見込みが少しはある。私の考えでは、報告を送る人が数を増やすのは、送る人にとっては理にかなった行動だ。増えた分の手間は、報告を受け取る人が負う。

一つ、確かめられていないことがある。Google は「自動の報告」と書いたが、AI で作られた報告が何割かは示していない。私は自動の報告の多くを AI によるものと見て読んでいる。割合は分かっていない。

05Google は再現の証拠を求め、curl は報奨金そのものをやめた

Google と curl は、報告を受け取る人の手間を減らすために、それぞれ違うやり方を選んだ。

窓口を止める半年前の 2026 年 3 月に、Google は一部の等級の報告に、より確かな証拠を求めると告げた。InfoWorld によれば、Google が求めた証拠は、OSS-Fuzz で不具合を再現した結果か、すでに取り込まれた修正パッチである。OSS-Fuzz は Google が公開している仕組みで、多くの計算機でファジングという試験を回し、オープンソースのソフトウェアの不具合を探す。ファジングは、わざと崩したデータを大量に読ませ、ソフトウェアが止まる所を探す試験だ。OSS-Fuzz で再現できた報告なら、保守者は一から試さずに済む。その分、手間は減る。

Google のやり方では、報告を送る人が、送る前に証拠をそろえる手間を負う。curl が報奨金をやめたので、外れそうな報告を送っても、送った人はお金をもらえない。やり方は違う。Google は確かめる手間の一部を送る人に移し、curl は確かめる件数そのものを減らそうとしている。どちらも、受け取る人の手間を減らす。

同じ 3 月、InfoWorld は、Google・Anthropic・AWS・Microsoft・OpenAI の 5 社が Linux Foundation に合わせて 1,250 万ドルを出すと伝えた。私はこの資金を、報告を受け取るオープンソースの側を外から支える試みとして読む。

06報告を受け取る人は、数を見ずに証拠を求め、ときには窓口を止めてよい

Google は証拠を求め、curl は報奨金をやめた。二つの例から、報告を受け取る人の仕事について、私は三つのことを読み取る。

届いた報告の数は、報告の質を示さない

Bugcrowd では 3 週間で報告が 4 倍を超え、curl では本物と確かめられた報告が 5% を下回った。報告が増えても、本物の欠陥が増えたとは言えなくなった。数は当てにならない。これまで報告の数で成果や危険を測ってきた組織は、別の測り方を探すことになる。AI のおかげで、報告を一件増やす手間がほとんど要らなくなったからである。

証拠は、報告を読む前の入口で求める

OSS-Fuzz の再現結果や修正パッチが付いているかどうかは、報告が届いた時点ですぐに分かる。証拠の無い報告を差し戻せば、保守者は証拠のある報告にだけ再現の時間を使える。受け取る人が報告を読み始めたら、確かめる手間はもう受け取る人にかかっている。だから証拠は、報告を読む前に求める。

窓口を止めることも、確かめる人の時間を守るやり方である

窓口を開け続けることだけが、責任の取り方ではない。Google は製品の脆弱性の受付を止めたが、ほかの窓口は残し、2027 年第 1 四半期に方針を示すと約束した。止める範囲と、次に方針を示す期日を書いてから止めれば、窓口の停止は投げ出しとは違うものになる。

07再開の条件も、資金で人手が足りるかも、まだ示されていない

2026 年には、窓口を止める、証拠を求める、報奨金をやめる、という三つのやり方が出そろった。その先は未定である。

Google が約束したのは、2027 年第 1 四半期に方針を示すことだけである。Google は、受付を再開するか、再開するならどの証拠を求めるかを書いていない。窓口ごとに求める証拠が違えば、研究者は送り先ごとに準備を変えることになるだろう。これは私の推測だ。窓口ごとの違いを数えた資料は、まだ無い。

資金の効き目も見えない。1,250 万ドルで報告を読む人がどれだけ増えるかを示した資料を、私は見つけられなかった。1,250 万ドルという額は 2026 年 3 月の InfoWorld の記載で、その後に足された分は確かめていない。

私が次に読むのは、Google が 2027 年に出す規則の文面である。私はその文面に、報告に添える証拠の条件が書かれているかを確かめたい。

AI で報告を書く手間は減ったが、報告を確かめる手間は、いまも受け取る人が負っている。Google は証拠を求めて確かめる手間の一部を報告を送る人に戻し、curl は報奨金をやめて外れそうな報告を送る理由を減らした。

AI で作った書類を受け取る仕事は、脆弱性の窓口のほかにもある。届く書類が増えたら、私は読む人を増やす前に、書類に添えてほしいものを書き出しておく。