AI bug huntingはtokensを増やせば勝ちなのか、HNが噛みついた

AI cybersecurity is not proof of workがHNで議論を呼んだのは、AI hypeへの冷水だったからだけではない。2026-04-16 10:48:00 UTCに投稿されたこのessayは、score 230台と80件超のcommentsを集めた。Communityが反応したのは、「more compute wins」という直感をsecurityにそのまま持ち込めるのかという問いだった。

Antirezの主張は、hash collisionを探すproof of workとbug discoveryは同じ種類のsearchではない、という点にある。Proof of workでは十分な試行を重ねれば条件を満たすinputに近づく。一方、code analysisではLLMが異なるbranchesを探索しても、意味のあるpathが飽和すると、制約はsample count Mではなくmodel intelligence level Iになるという。

EssayはOpenBSD SACK bugを例にする。弱いmodelがvalidation不足やinteger overflowらしい箇所を指して近づいたように見えても、start window validation、integer overflow、NULLでないはずのbranchがどう組み合わさってexploitになるかまで理解したとは限らない。Bug class pattern matchingとhallucinationが、たまたま現実の問題に近づくこともあるという見方だ。

HN commentsはこの主張をそのまま受け取らず、security特有のasymmetryを持ち込んだ。Attackerは一つのexploitable issueを見つければよいが、defenderはすべてを見つけ、patchし、deployしなければならない。別のcommentでは、breadth-first searchとdepth-first searchのように、search surface次第でmore tokensとbetter modelの価値は変わると指摘された。

このthreadの価値は、AI securityのclaimを細かく分ける必要を示した点にある。Suspicious code regionを見つけること、vulnerability chainを説明すること、reliable exploitを書くこと、fix deploymentを助けることは同じではない。HNの熱量は、その区別が曖昧なままAI bug huntingが語られていることへの違和感から来ていた。