世界中で何十億台という端末が積んでいるデータ転送ライブラリ curl が、7月のあいだ脆弱性の報告を一切受け付けなくなった。作者の Daniel Stenberg はこれを「summer of bliss(至福の夏)」と名づけている。引っかかったのは理由のほうだ。AIが吐く出来の悪い報告に耐えかねて、ではない。報告はむしろ良くなった。良くなって、そのうえで増えた。それでも彼は窓口を閉じた。
ここには2025年の「AIスロップ問題」とは別の、もう一段先の話が入っている。
閉じたのは1月と7月で意味が違う
英語圏の見出しを並べると混乱する。「curl がバグバウンティを終了」というものと、「curl が7月の報告を停止」というものが混在していて、同じ出来事のように読めてしまう。実際は別々の判断だ。
curl の security チームがやったことを時系列で置くと、こうなる。
| 時期 | 何をしたか |
|---|---|
| 2026年1月 | HackerOne 上のバグバウンティ(報奨金制度)を終了。報奨金が「とりあえず投げる」動機になっていたため(BleepingComputer の報道) |
| 2026年3月 | GitHub 運用の試行を経て、HackerOne での受付に復帰 |
| 2026年7月1日〜8月3日 | 「summer of bliss」。報告の受付と処理そのものを1か月まるごと止める |
HackerOne は、脆弱性を見つけた人が開発者に非公開で報告し、対応状況をやり取りする定番のプラットフォームだ。1月にやめたのは、そのうえに乗っていた「報奨金」の部分。金銭のインセンティブが、雑な報告を大量生産させる燃料になっていたという判断だった。
7月に閉じるのは、報告チャネルそのものである。summer of bliss の告知によると、停止は7月1日 00:00 CEST から8月3日 09:00 CEST まで。HackerOne の投稿フォームは止まり、セキュリティ用のメールアドレスも「届いても処理しない」死んだ窓口になる。一方で GitHub の issue と pull request は通常どおり開いており、有償サポート契約者には期間中もフルにサービスが提供される。副作用として、次のリリース(8.22.0)は約2週間ずれて9月2日に後ろ倒しされた。
The curl maintainers will use this time of less pressure to take in some extra air and to enjoy the summer.
(curl のメンテナはこの重圧の少ない時間を使って、ひと息つき、夏を楽しむ)
告知本文が挙げる理由は、セキュリティ対策でも対AIでもなく、メンテナの休息だ。ここが大事で、7月の停止は Stenberg 自身の言葉としては反AI施策ではない。「AIがDDoSしている」という強い枠は、むしろ報道と彼の過去記事から来ている。
「量が2倍・4倍」でも人手は7人のまま
では何がそんなに重かったのか。数字は6月前半の別記事「The pressure」にある。2026年春以降、脆弱性報告は平均して1日1件を超え、2024年比で4〜5倍、2025年比でおよそ2倍のペースで届いている。しかも内容は「非常に詳細で長い」もので、質は明確に上がっている。
皮肉なのは、その大半が実際の脆弱性ではない点だ。記事執筆時点で確認済みの未処理案件は12件、2026年に公開される CVE は年間30本超が見込まれるが、深刻度はどれも LOW か MEDIUM で、HIGH は2023年10月を最後に出ていない。つまり届く山のほとんどは「バグではあるが脆弱性ではない」もの、あるいは誤検知で、それを1件ずつ人間が再現し、切り分け、必要なら修正し、開示を調整する。curl の security チームは報じられているところで7人程度。ツールは進化したが、受け手の人数は増えていない。
If we don't take care of them roughly at the same speed they arrive, the backlog just grows ... takes a mental toll.
(届くのとだいたい同じ速さで捌かないと、バックログはただ膨れていく……精神的にこたえる)
ここに、生成AI時代の非対称性がむき出しになっている。「それらしい成果物を生成するコスト」は限りなくゼロに近づいたが、「それを検証して取り込むコスト」は人間に固定されたまま下がっていない。 curl の件は攻撃でも悪意でもなく、むしろ善意の、質の高い報告の増加が引き起こしている。だからこそ厄介で、フィルタで弾けばいい話にならない。
実務のエンジニアなら、これがセキュリティ報告に限らないことにすぐ気づくはずだ。AIが生成する PR、issue、設計提案、レビュー依頼。どれも「作る側」は激安になり、「読んで判断する側」の負荷だけが積み上がる。フロー制御のないパイプラインに、上流だけ帯域を10倍にしたようなものだ。summer of bliss は、下流のメンテナが手動でバックプレッシャーをかけた、と読むのが一番しっくりくる。1か月まとめて受信を止めるのは、レートリミッタの実装としては雑だが、確実に効く。
Stenberg が本当に求めているもの
では報告する側はどうすればいいのか。停止告知の直前、6月29日に彼は「Do excellent vulnerability reports」という実践的なガイドを出している。これが今回いちばん持ち帰る価値のある一次情報だ。
面白いのは、そこに「AIを使うな」とは書かれていないこと。むしろ逆で、報告を書く人への要求はこう整理されている。
- Really? — 既知の仕様や意図された挙動を「脆弱性」と誤認していないか、まず疑う
- Report — 冒頭に「人間が書いた、何が問題でどんな悪さにつながるかの短い説明」を数文で置く
- Reproducer — security チームがそのままビルドして再現できる、自己完結したスクリプトかコードを付ける
- Patch — 不完全でもいいので修正案を出す。「目標に80%届いていれば十分に価値がある」
- Versions — どのバージョンで試したか、どこまで遡ると再現するかを特定する
- Collaborate — 投げっぱなしにせず、評価・修正・アドバイザリ作成まで付き合う
AIへの直接の言及は一箇所だけ。「見つけるのに、あるいは書くのに、AIを大量に使ったか少しだけ使ったかにかかわらず、あなたは 人間として コミュニケーションしなければならない」。要は、発見の手段は問わない。問われるのは、自分の見つけたものを自分で理解し、人間の言葉で伝えられるかだ。再現手順のない長文、書いた本人が中身を説明できない報告。AIで水増しされたそれが、受け手の時間をいちばん食う。
curl は極端な事例に見えて、実は生成AIが変えた力学の縮図だと思う。モデルの賢さがどうこうより、「生成が安く・検証が高い」という非対称が、受け手側の運用をじわじわ壊していく。curl は7人のチームが1か月休むという物理的な手段でそれに抵抗したが、より根本的には、生成の安さに見合う「検証の自動化」か「上流での自己検証の強制」をどこかで足さないと、同じ壁に各所がぶつかる。少なくとも自分がAIに何かを report/PR させる側に回るときは、Stenberg のチェックリストを相手に押しつける前に、自分で通しておきたい。