データベースのエッジレプリケーションで知られる Turso が、自社の bug bounty プログラムを正式に廃止した。理由は「AI が生成した、もっともらしいが実在しない脆弱性報告」の洪水である。HackerOne 文化が前提としてきた「善意の外部研究者」というモデルが、LLM の登場でついに経済的に破綻し始めた象徴的なケースだ。
何が起きたか
Turso は公式ブログ We are retiring our bug bounty program で、外部研究者からの脆弱性報告に対する報奨金プログラムを終了すると発表した。背景にあるのは、ChatGPT などの LLM を使って機械的に生成された「AI slop」と呼ばれる低品質な脆弱性レポートの急増である。
報告の体裁は整っている。CVSS スコアらしき数値、再現手順、影響範囲、修正案までもっともらしく書かれている。しかし実際にコードを追うと、参照している関数が存在しなかったり、libSQL のフォークでは到達不能なコードパスを攻撃ベクタとして主張していたりと、トリアージに時間を吸われるだけで実態がない。
これは Turso 単独の現象ではない。2024年末から curl のメンテナ Daniel Stenberg が「AI 生成のゴミ報告で時間を奪われている」と繰り返し警告しており、Python Software Foundation の Seth Larson も同様の問題提起を行っている。bounty を出している側はさらに深刻で、「報告を読まない」という選択肢が取れないため、運営コストが青天井に膨らむ。
なぜこのニュースが重要か
これは「脆弱性報告だけの話」ではなく、非対称コスト構造を持つあらゆる外部受付窓口に同じ崩壊が来る という予兆である。
bug bounty は構造的に、報告側の生成コストと受信側の検証コストが釣り合っていることが前提だった。人間が脆弱性レポートを1本書くのに数時間かかるなら、受信側もそれを数時間かけて検証するのは合理的だ。ところが LLM は1本あたり数セント、数秒で「それっぽいレポート」を量産できる。受信側の検証コストは変わらないので、コスト比は一気に1000倍以上に開く。
同じ非対称性は、
- カスタマーサポートの問い合わせフォーム
- ATS(採用管理)への求人応募
- App Store / Google Play のレビューと不正報告
- GitHub Issues / Pull Request
- 行政の意見公募(パブリックコメント)
すべてに存在する。GitHub では既に、AI 生成と思しき低品質 PR が OSS メンテナの時間を奪っており、Curl の Stenberg は HackerOne に対し「AI 報告には専用フラグを」と要求している状況だ。
エンジニア視点・技術深掘り・実装影響
実装側で取るべき防御は、単純な reCAPTCHA では不十分だ。LLM の出力は CAPTCHA を通過した人間が貼り付ければ通ってしまうし、ヘッドレスブラウザ + LLM の組み合わせは reCAPTCHA v3 のスコアリングでも区別が難しい。
現実的な設計パターンとしては以下が浮上している。
1. Proof of Work / Proof of Identity の組み込み
Cloudflare の Turnstile や、より強力には Privacy Pass(RFC 9576) ベースの匿名トークンで、「同一の検証済みアイデンティティが裏にいる」ことだけを保証する。GitHub アカウントの作成日数・コントリビューション履歴を要求するのも同じ系統だ。Turso の今後の運用も、信頼済みの研究者リストとの私的なやりとりに切り替える方向だと読める。
2. 報告側にコストを負わせる設計
bug bounty に「supporting commit hash」「再現用の最小 Docker イメージ」「失敗するテストケースの PR」を必須化する。LLM でも生成可能だが、実際に動くものを出させると幻覚率が桁で下がる。これは SWE-bench のような評価セットでも観測されている傾向だ。
3. トリアージ側こそ LLM で武装する
皮肉だが、受信側も Claude や GPT-5 系で一次フィルタを通すのが現実解になる。プロンプトとしては「このレポートが参照している関数・行番号が、添付のリポジトリに実在するかをまず検証せよ」と命じ、ripgrep や ast-grep の呼び出しをツール経由で実行させる。実在しない関数を引用している時点で reject、というルールだけでも AI slop の大半は落ちる。
# 最小限の幻覚検出パイプライン例
rg -n "$CLAIMED_FUNCTION" --type rust libsql/ || echo "HALLUCINATED"
経営者・読者として次に取るべき動き
短期的には、自社が運営する外部窓口を棚卸しし、「報告側の生成コスト < 受信側の処理コスト」 になっている箇所を特定することだ。サポート窓口、採用、苦情窓口、SNS の DM — どれもすでに AI 洪水の射程に入っている。
中期的には、フォームの入口に「誰が入力したか」を担保するレイヤー を必ず挟む設計に切り替える。OAuth による外部 ID 連携、ドメイン確認済みメール、KYC 軽量版、あるいは少額のデポジット(信頼できる報告者には返金)など、選択肢は揃いつつある。
そして長期的には、bug bounty に限らず「無料で大量に受け付けて、社内で頑張って捌く」モデルそのものが終わる前提で業務設計をやり直す必要がある。Turso の決断は撤退ではなく、LLM 以後の窓口設計の最初の現実解 であり、来年には多くの企業が同じ判断を迫られるはずだ。
動画でも詳しく
動画は記事冒頭の埋め込みからフル尺で視聴できます。