Glasswingの7ヶ月間の実際の成績はどうだったのか？

VulnCheckの第三者トラッキングによると、442件のCVEがあり、月平均で約63件です。これは今年の全CVEの約0.5％に相当し、そのうちわずか2件が実際に悪用されています。Anthropicのレポートによると、37,966件の報告、217件の修正、7,349件の公開があり、撤回や重複したものも修正数を上回っています。これら二つの数字は、起動時に「数千件の高リスクおよび重大な脆弱性」があるという主張と異なります。

なぜcurlの検証結果が重要なのか？

これは、メンテナーがAIの脆弱性報告を一つずつ検証し、その結果を公開する珍しい例です：45件の報告書のうち34件が検証され、「脆弱ではない」と判断された19件、低リスクと確認された6件、評価待ちの9件で、偽陽性率は55.9％です。一方、Anthropicの自己評価では真の偽陽性率は94.2％です。二つの基準が同じではないため、検証の負担がメンテナーに転嫁されている問題が明らかになりました。

この報告は完全に信頼できるのでしょうか？

できません。VulnCheckはAnthropicと競争関係にある脆弱性情報提供会社であり、HNのコメントセクションではその結論が自社のビジネスモデルと一致していることが指摘されています。また、記録の80.6％の発見内容は公開されておらず、その質については外部から知ることができません。これはサバイバー分析に属します。合理的な解釈としては、二つの数字がそれぞれ異なる基準で示され、交差する部分で判断が下されるというものです。一方的な有罪判決は行われません。

Hot Tracking 041｜37,966件の脆弱性報告、修正は217件のみ

何が起こったか

背景。2026年4月7日、AnthropicはProject Glasswingを開始し、公式声明では「数千の高度に危険なおよび深刻な脆弱性を特定し、オープンソースのメンテナーに対して責任を持って情報を開示している」と発表した。開始時の反応は非常に大きく、HN 1541▲/836💬が公開され、5月22日には561▲が初めて更新され、6月2日には180▲が拡張された。5月にはAnthropicが独自のリグレットを立ち上げ、不定期にバッチ更新を行っていた。10月8日にはOSS Scannerという自動スキャンサービスを公開し、29,000以上の候補脆弱性を発見したと述べたが、実際には約6,000件のみ人工的に確認されており、「ボトルネックは人工検証能力にある」と説明した。また、完全な検証を受け取るよう要求したメンテナーに対して、5,000件近くの未検証報告書を送付した。「完全なモデル生成、人工検証なし、三分法」がAnthropicの公式声明である。

監査。VulnCheckは4月17日から追跡を開始し、Anthropicの独自リグレットよりも早かった。その方法は、オープンソースリポジトリAnthropic Credited CVEsをメンテナンスし、CVE記録、GHSA、Linuxカーネルコミット、Anthropicの独自リグレットを交差比較し、人工的にアナウンスを監査することだった。これはVulnCheckが追跡結果を公開する初めてではない。4月15日の最初の観察から、連続してリグレット観察（6月9日）、利用状況報告（7月28日）、そして最新の段階対照（9月8日）を公開している。今回は7ヶ月間の5回目の更新である。7ヶ月間の結果（以下すべてVulnCheckの追跡声明による）：Anthropicに帰属するCVEは合計442件で、月平均約63件であり、今年の全93,450件のCVEの約0.5％を占めている。442件のうち2件のみが実際に悪用されており（0.45％、CVE-2026-61500とCVE-2026-26980、VulnCheck KEVと比較）、もう一つの比較では、VulnCheckが追跡した442件は、Anthropicの独自リグレットで修正された件数（217件、Anthropic自身の報告）の2倍を超えている。

メンテナーの確認。11月6日頃、ブログ公開の3日前に、curlのメンテナーDaniel StenbergがAnthropicから45件の脆弱性報告を受け取ったと発表した。Anthropic自身は1件を中危、その他はすべて低危と評価していた。DanielはGitHubへの転送速度を「チームへの負荷を軽減する」ために遅らせ、今週中にすべて公開する計画だとした。既に公開された34件の検証結果：19件は「脆弱性ではない」とマークされ、6件が低危と確認され、9件が評価待ちとなり、偽陽性率は55.9％、確認率は17.6％で、すべて低危であった。これは初めてではない。今年5月にDanielは、5件のMythos findingsが最終的に1件の脆弱性のみと確認されたと書いていた。現在までに、Anthropicからこの監査報告に対する前向きな返答は見られていない（HNおよびブログには返信記録がない）。

リグレット監査：発見数の急増、修正の停滞

Anthropicが自ら報告した数値を時間順に並べると、問題が自ずと明らかになります。5月にリリース時：23,019件の findingsがあり、自称の真偽率は90.8%でした。11月2日の最新更新では：37,966件の findingsがあり、217件のみが修正済みとされ、7,349件（19.4%）が公開されています。

09月8日から11月2日までの約2ヶ月間の変化を再検討すると（すべてAnthropicが自ら報告したもの）：総finding数は26,153件から37,966件に（+11,813）増加し、公開済みの数は2,736件から7,349件に増加しました。修正済みの数は202件から217件に（+15）増加し、撤回された数は245件から419件（+174）に増加し、重複した数は2件から1,670件（+1,668）に増加しました。累計で見ると、重複した項目は1,654件（4.4%）で、修正済みの数の約7.5倍です。重複が急増するのは偶然ではありません。VulnCheckは9月の更新で警告していました。報告が長期間にわたって蓄積されるほど、他者が先に発見し、同じ脆弱性を修正する確率が高くなります。2ヶ月後、この予測が正しかったことが証明されました：発見側の能力は最大限に活用できたが、修正側には追いつかず、その間に蓄積されたのが重複と撤回です。

発見数は2ヶ月で約半分増加しましたが、修正数はわずか15件しか増加していません。撤回と重複の増加量は修正の増加量よりも大きいです。VulnCheckが指摘している問題はここにあります：撤回と重複は修正よりも多いが、自称の真偽率は90.8%から94.2%（09月8日時点では91.4%、+2.8ポイント）まで上昇しました。この報告書には「3分の1が合格しない」というフィードバックのループが欠けており、「脆弱性ではない」と判断された報告は計算に含まれていません。さらに、VulnCheckは報告書に公開済みの数を過大評価するバグがあることも発見しました（「disclosed」フィルターで再現可能）。

深刻度も一致していません。VulnCheckの9月の発見によると、Claudeは報告書内の91.5%のfindingを深刻/高リスクと評価していますが、メンテナーは51.3%しか認めていません。同じ報告書でも、機械の自己評価とメンテナーの判断の間には40ポイントの差があります。

検証負担の転嫁：OSS Scannerからcurlまで

2番目の批判の焦点は数値ではなく、プロセスです。Anthropicは、各発見を3分の1しか評価しないことを明確にしており、10月8日にはOSS Scannerを自己サービスモードに変更しました。メンテナーが自らスキャンを申請し、結果を3分の1に分類します。OSS Scannerがリリースされた後、29,000件の候補脆弱性のうち約6,000件のみが人工的にレビューされ、約5,000件の検証されていない報告書は、完全な受け取りを要求したメンテナーに直接送信されました。Anthropicの説明によると、これらの報告書は完全にモデル生成であり、人工的なレビューや3分の1の評価は行われていません。発見側の能力は最大限に活用できたが、検証側には追いつかず、そのギャップは誰が埋めるのでしょうか？curlのケースが答えを提供しています：メンテナーが自ら埋めます。ここにはAnthropic自身の論理があります：自己サービススキャンを導入する根拠は、「もし自称の真偽率が高いとすれば、メンテナーが自ら3分の1に分類することに問題はない」というものです。curlの55.9%の偽陽性率は、前提が成り立たないことを示しており、自己サービスモードのコストは実際にはメンテナーの労働時間によって支払われています。

Danielが45件の報告を受け取った後の行動は注目に値する：GitHubへの公開速度を遅らせて「チームへの影響を減らす」ために、一つ一つの報告を確認し、低リスク・中リスクの問題をすべてissueとして公開した。VulnCheckのコメントはこうだ：メンテナーは「ペースをコントロール」して自分のチームを守る必要があり、これ自体が負担であることを示している。一方、curlが全てを公開するのは透明性を示すためである。

ここで批判の境界を明確にする必要がある：本文もVulnCheckも「AIによる脆弱性発見が効果的」という点を否定していない：VulnCheckは自らAIが有効なツールであると繰り返し述べており、442件のCVEも実際に記録されている。批判されるのは二つの点だ：発見量の記述が現実との乖離があること、および検証コストがオープンソースメンテナーにシステム的に転嫁されていること。

行動と言動の監査：約束された成果と実際の状況の不一致

一つ一つの要素が正しい。第一の要素は、発表時の約束である。開始時に「数千の高リスクおよび深刻な脆弱性」と述べたが、7ヶ月後VulnCheckの報告では442件のCVEであり、年間の約0.5％に過ぎず、そのうち2件のみが実際に悪用されている。数千件と442件の間で、公開されている7,349件の発見をすべてCVEとして計算しても、「発見からCVEへの換算」が必要であり、curlが提供する換算率は17.6％であり、すべてが低リスクである。

第二の要素は、品質の約束である。「責任を持って情報を公開する」というのは、公開される情報の品質も含む：自己評価による真の陽性率は94.2％（Anthropicの自己申告）に対し、curlがメンテナーによって検証された偽陽性率は55.9％（メンテナーの報告）である；Claudeの自己評価では91.5％が深刻/高リスクであり、メンテナーは51.3％のみを認めている。二つの数字は一致しない。

第三の要素は、対応の方法である。報告書はバッチで更新されるだけで、フィードバックの仕組みが欠けている。監査結果が発表されてから本文が掲載されるまで、公式からの肯定的な反応はなかった。開始時の1541▲の勢いと、監査報告書の35▲の冷淡さの間に、公式からの補完的な発言はなかった。ペース自体が注目に値する：三度の公式発表の際には声が大きくされたが、第三者による7ヶ月間の対照に対しては、本文が掲載されるまで沈黙が続いている。

VulnCheckの元の報告では、証拠が発表時の主張と一致しないと述べられている：証拠は発表時の主張と一致しない。本文もこの基準を維持している：「有罪」または「偽造」とは言わず、「一致しない」とだけ記述する。同時に、両方を制限する必要がある：VulnCheckには競争上の利益があり、その結論には広告の疑いがある（HNユーザーのjrfloが指摘している）；そして、報告書に含まれる80.6％の未公開の発見の品質は外部から知ることができず、公開されている19.4％を全て推測することはできない。これはサバイバルアナリシスであり、HNユーザーのdfeeの注意喚起が正しい。本文は一方的な有罪判決を行わない。

コメント欄の反応はどうか

HNの投稿は35▲で、わずか6件のコメントがある。量は少ないが、方向性は記述に値する。四つの方向に分けて述べる。

一つ目は、「狼が叫んだ」方向である。ユーザーのfnyは、過去1年間に災害級の悪用が一切なかったことが最も明らかな兆候だと言っている：もし数千の高リスク脆弱性が実際に発見されていたら、実際の悪用数はこのようにはならないはずである。

二、サバイバー・バイアス・ロード。ユーザー dfeeの注意：公開されている findings はわずか19.4％であり、本文で分析されているのはその19.4％のみです。残り80％が不正なものなのか、修正されていないのかは不明であり、結論を出す際には慎重に行う必要があります。ユーザー hologramofhamの同様の疑問：記事は公開されている19.4％のデータに基づいて大げさな結論を出していますが、この割合自体も別のことを示している可能性があります。公開されていない部分には、公開に適さない機密な発見があるかもしれません。公開されたデータだけでは、これら二つの可能性を区別することはできません。

三、利益衝突・ロード。ユーザー jrfloは、VulnCheckの結論がそのビジネスモデルと高度に一致していると指摘しています。脆弱性情報を販売する企業は、他社の脆弱性報告の質が悪いと批判し、それが広告の疑いがあるとしています。

四、検証時点までに、AnthropicはHNやブログで回答していません。

一般ユーザーが行える三つのこと

AI生成の脆弱性報告を受け取ったら、まず自分の手順を踏む。 もしあなたがメンテナーまたはセキュリティ責任者であれば：報告書の深刻度のラベルをそのまま信じないでください。機械の自己評価では91.5％が深刻/高リスクとされていますが、メンテナーは51.3％しか認めていません。ラベルの過剰な使用には実証例があります。curlの方法を参考にしてみてください：大量受信、ペースをコントロールし、個別に検証し、結論を公開する。
パッチを適用する前に、実際の利用状況を調べる。 442件のCVEのうち、わずか2件が実際に悪用されています（0.45％）。優先順位を決める際にはKEVのカタログとGHSAの記録を参照し、限られた修復時間を実際に攻撃された穴に費やしましょう。
次の二つのポイントに注意する。 一つはcurlが今週中に全ての45件の報告書を公開した後の完全な偽陽性率です。もう一つはAnthropicが回答するかどうか、そして報告システムが3分の1のフィードバックを補完するかどうかです。どちらかのポイントで動きがあれば、本文をv2にアップグレードします。

結論

適切な声明：本文では「Glasswingの失敗」や「データの改ざん」とは書かれていません。すべての数字は二つの基準で示されています。442、2、0.5％、55.9％、17.6％、91.5％対51.3％はVulnCheckが追跡したりメンテナーが検証したりした基準です。23,019、37,966、217、7,349、94.2％はAnthropic自身が報告した基準です。批判の対象は「AIによる脆弱性の発見」ではなく、発見量の記述と実際の修復の乖離、および検証の負担がオープンソースメンテナーに転嫁されていることです。VulnCheckの競争利益と公開されていないfindingの不確実性を両方の制限で本文に記載し、一方的な断定はしません。

チェック自体が定性よりも価値があります：報告システムが信頼されるためには、自己評価の真の偽陽性率を高くすることではなく、メンテナーが検証結果を戻す分母となるメカニズムが必要です。48時間のウィンドウ内（11月9日のブログ公開、11月10日のHN掲載の二つのポイント）、Anthropicが回答したりcurlが全量の検証結果を公開した場合、それは本文に更新されます。

参考文献

VulnCheckブログ「7ヶ月後、Glasswingが不十分な結果でメンテナーを圧倒する」（Patrick Garrity、2026年11月9日公開、全文200件の検証済み；第一手の情報源ですが、競合他社の立場に注意してください）。
Anthropicの公式声明：Project Glasswingの開始告知（2026年4月7日）、レジャーボードの公開（5月にリリース、11月2日の最新更新）、OSS Scannerの自述（2026年10月8日；「完全なモデル生成、人のチェック不要または3分」が公式の言葉）。
curlのメンテナーDaniel Stenbergの公開発言（約2026年11月6日から；45件の報告書、34件の検証結果がメンテナーの第一手の情報源）。
Hacker Newsの記事50447074（2026年11月10日に掲載、執筆時35▲/6💬、Algoliaのスナップショット；コメントはすべて引用し、ユーザー名は保持）。
HNの歴史的な人気データ（4月7日の投稿1541▲/836💬、5月22日の更新561▲、6月2日の拡張180▲、すべて過去のスナップショットの情報源）。

署名：永亮