これは多くの静的解析ツールが簡単に見つけられるものだよ。それでも、20年以上も誰も見つけられなかったんだね（誰も実行しなかったか、見つけられなかったか、見つけたけど何百もの誤検知に埋もれてたか）。誰かがLLMでクールなことをするたびに、「それは簡単だった、重要じゃない、俺の親父でも寝てる間にできた」みたいな意見が出てくるのが面白い。

「隠れているわけじゃなくて、むしろ「誰も見ようとしなかった」って感じだね。」まあ、そうだね。見ようとする「誰か」が足りなかったんだ。OSSのバグを探すために時間をかけられる有資格者は限られているから、世界中でバグを見つける能力も限られていたんだ。少なくとも、そうだった。これらのモデルがバグを見つけて検証するのに十分な能力を持つようになってきたから、状況が変わってきているんだ。今やその限られたバグ発見能力が増えてきて、実際のバグが掘り起こされ始めている。今年は、モデルが能力を高め続ければ非常に面白いことになるだろうね。

…そして誤検知をレビューするのに3ヶ月かかった。

すでに起こったこと: https://arxiv.org/abs/2407.08708

バグの中には浅いものもあれば、自動化ツールの信頼性の低さから生まれた誤検知の寄せ集めもあるよね。

言及されてないけど、Claude Codeも1000個の誤検知バグを見つけて、開発者たちはそれを排除するのに3ヶ月かかったんだ。ソースは？どこにも見たことないよ。私の経験では、Claude Opus 4.6の脆弱性に対する誤検知率は20%を下回ってる。

PoCを書くようにすればよくない？

ここでの教訓は、Claude Codeが無駄だってことじゃなくて、正しい人の手にかかれば強力なツールになるってことだね。

静的/動的解析ツールは常に脆弱性を見つけてるよ。ある程度の規模のプロジェクトは、こういう退屈なスキャナーからの既知の問題が大量に溜まってる。問題は、それらを整理して優先順位をつけることなんだ。修正すべき問題が多すぎて、どれが悪用可能で実際にダメージを与えるのかを見極めるのは時間がかかる。古いバグをClaudeが見つけたからって感心する？まあ、ちょっとね…新しいスキャナーが導入されるたびに、他の人が見つけてない新しい発見があるから。

記事には、たくさんの誤検知を見つけたとは書いてないよ。まだテストが必要な大きなバックログがあるって言ってるだけ。「Linuxカーネルには、まだ検証してないから報告できないバグがたくさんある…」って。

今起こってることはそうじゃないよ。バグは後でLLM自身によってフィルタリングされることが多い。もし二次パイプラインがクラッシュや違反、悪用を再現できない場合、誤検知は人間の目に届く前に排除されることが多いんだ。本物の脆弱性がトリガーできるか確認するのは、見つけることに比べたら簡単な作業だから、この二次パイプラインはほぼ100%の成功率を持ってる。二次パイプラインを通過すれば、ほぼ確実に本物のバグだし、本物のバグがこの二次パイプラインを通らないことはほとんどない。LLMがどれだけ進化しても、それに反対する人たちはその有用性を否定し続けるだろうね。これは普通の人々の中では予想されることだけど、Hacker Newsで目に見えない人がたくさんいるのを見るのは変な感じ。

なるほど、反AI派の人たちは今やただのデタラメを言ってるだけなんだね。Willy Tarreau[0]とGreg Kroah-Hartman[1]によると、この傾向は最近かなり逆転したみたい。少なくとも彼らが見ているLinuxカーネルの報告によればね。curlの創始者、Daniel Steinbergも、その広範な移行の前に、LLMを使ったより洗練された脆弱性研究ツールが生成する報告を役立てていたらしい[2]。実際にそのツールを運用していた人は「彼らは低い誤検出率を持っている」と言ってた[3]。さらに、TFAで議論された脆弱性を見つけた人のトークでは、誤検出率についての言及はなかったし、ほとんどが無駄な情報だったから報告を精査する必要があったとも言ってなかった。彼がそれを礼儀でやっていたかどうかもわからないしね。彼は確か数百件しか見つけていないと言ってたはずで、「何千件」ではなかったよ。彼が言ったのは、「Linuxカーネルには、まだ検証していないから報告できないバグがたくさんある…無駄な情報を[Linuxカーネルのメンテナ]に送るつもりはないけど、これで彼らが見たことのない数百件のクラッシュがあることになる」とかそんな感じだった(TFA)。彼は明らかに、何千件も精査する必要はなかったし、これを見つけるのに数ヶ月もかけていないよ。[0]: https://lwn.net/Articles/1065620/ [1]: https://www.theregister.com/2026/03/26/greg_kroahhartman_ai_... [2]: https://simonwillison.net/2025/Oct/2/curl/p [3]: https://joshua.hu/llm-engineer-review-sast-security-ai-tools...

これがLLMを使ったファーストパーティの脆弱性研究のやり方じゃないよ。従来のツールに比べて、トリアージや高品質なバグを生み出すのに非常に価値があるから、PoCを生成してバグが到達可能であることを証明するように指示できるんだ。誤検出が多くなりがちなのは、従来の研究手法（ファジング、静的解析など）だからね。オープンな提出フィールド（PRやバグバウンティなど）がAIの無駄なスパムで問題を抱えているのは、LLMがスパムを生成するのが得意だからであって、プログラミングや脆弱性研究が下手だからではないよ。インセンティブが合えば、LLMは脆弱性研究において非常に優秀なんだ。

最近のフロントページの記事から、以前のスパム問題に触れていた部分: > 「今やこれらの報告のほとんどが正しいので、私たちはもっとメンテナを呼ばなければならなかった。」 https://news.ycombinator.com/item?id=47611921

過去6ヶ月で全てが変わった。コーディングLLMは、まあまあから超優秀になった。人々もそれを使うのが上手くなったしね。それに、誤検出率が高いのは、誤検出が高いコストを伴う場合（Linuxカーネルの脆弱性は非常に高価なミス）ではそれほど悪くない。誤検出を精査して排除する過程で、その結果は次世代のLLMのトレーニングセットに理想的には組み込まれることになり、将来的な誤検出率の低下に繋がるかもしれないね。

最近のここにある投稿は全部こんな感じ。「Communality.aiのスタートアップ創業者がAIは人に良いって言ってる」ってコメント欄では、AI好きの人たちが「もう仕事は終わりだ、いい時代が来た」って言ってる。

Claude Codeはクローズドソース（でも逆コンパイルされたソース）で動いてるんだよね。多分、あんまりうまくいかないと思う。オープンソースのライブラリがたくさん使われてたり、言語やパターンがめっちゃ人気だったりしない限りはね。Linuxカーネルみたいな人気のOSSの大きな利点は、ソースがトレーニングデータにたくさん含まれてること。しかも、いろんなバージョンがね。だから、ソースを再提供して「Xを見つけて」って言うのは、主にトレーニング中に既に見たことがあるものに焦点を当ててるだけで、新しい情報はあまりないんだよね。新しいコードがたくさん含まれてるクローズドソースプロジェクトを与えると、言語とその「直感」だけで動かなきゃいけないから、かなり難しい要求になる。

大量の新しいコードを貼り付けて、Claudeに「何を忘れた？バグはどこ？」って聞くのは、実際に私がCC/codexを使う主な方法なんだ。

「Codexがこれを書いたけど、何か変なところに気づいた？」

修正できるバグよりも、常にバグは多いよ。AIもパッチを当てられるけど、システムがテストしにくくて厳格な検証がないと、受け入れられないほどの回帰が発生する可能性が高いね。