Anthropicは、Claudeによる脆弱性報告の進捗を公開しています。企業が見るべきなのは発見数だけでなく、利用中のソフトウェアに関係するか、修正版が出たか、自社へ適用できたかという次の工程です。
「AIが何千件もの脆弱性を見つけた」というニュースを見ても、自社で何をすればよいかはすぐには分かりません。発見されたことと、対策が届いたことの間には、いくつもの確認作業があるためです。
Anthropicは2026年11月2日19時30分UTC、日本時間11月3日4時30分に、脆弱性の協調的開示を追跡するダッシュボードを更新しました。680のオープンソースプロジェクトへ累計5,087件を報告し、同社が把握する開発元（上流）での修正済みは629件としています。公式ダッシュボード
この記事では、この数字を「AIが安全にした件数」と読み替えず、情報システム担当者や開発チームが自社の対応を考えるための読み方を整理します。個別の脆弱性を悪用する方法ではなく、対策を完了させる側の話です。
この記事でわかること
- 今回の更新：報告先・修正状況・識別情報を追う公開データが更新されました。
- 数字の意味：候補、報告、識別子、上流修正は異なる段階を表します。
- 自社の対応：利用製品と影響を照合し、担当者と適用確認をつなぎます。
- 評価の注意：累計数や把握済みの修正数だけで、製品の危険度を決めないようにします。
ダッシュボードは、発見後に何が起きたかを追うもの
脆弱性の協調的開示とは、見つかった問題を対象プロジェクトの管理者へ伝え、修正のための時間を設けたうえで詳細を公開していく進め方です。今回のページは、Claudeを使った発見から報告までの状況と、公開可能になった指摘を確認できるようにしています。
Anthropicは、すべての候補がそのまま報告されるわけではなく、人による選別・検証が処理量を制約していると説明します。また、報告には外部のセキュリティ企業を介する経路と、Anthropicから直接伝える経路があります。報告件数をすべて第三者が検証済みの件数とみなすことはできません。
公開の詳細には、まだ修正前の情報を無制限に開示しないための区別もあります。台帳に記録があっても、すぐに対象プロジェクトや問題の内容が読めるとは限りません。用語と公開方法の説明を合わせて読むと、数字を取り違えにくくなります。
報告件数が減った理由と、数字から結論にしないこと
10月2日の旧スナップショットでは報告6,157件でしたが、11月2日の更新では5,087件になりました。公式の説明によると、別の指摘と重複するものを台帳で重複とし、一部の撤回済み指摘とともに集計から外したためです。減少分を「修正が完了した件数」と読み替えることはできません。過去値と比較するときも、集計対象の見直しを含むことを明記します。
更新時点の主要な数値と、業務判断での注意点を並べます。いずれも今回の数日間だけで新たに見つかった件数ではありません。
| 公表値 | 読み取れること | 読み取れないこと |
|---|---|---|
| 680プロジェクト、報告5,087件 | 開発・管理側へ報告した累計の規模 | 自社が利用する製品すべてへの影響 |
| 上流修正済み629件 | Anthropicが把握する修正の状況 | 各利用企業で更新が適用済みか |
| CVE 230件、GHSA 503件 | 発行された識別子の内訳 | 合計733件がすべて別々の問題か |
CVEとGHSAは脆弱性情報を識別するための番号などです。一つの指摘に両方が付く場合があるため、足した値を独立した脆弱性の数として使うと重複を含みます。また、修正版が公開されても、利用者が更新しなければ旧版は残ります。
「報告が多いから、その製品は他より危険」「修正済みが少ないから、残りはすべて放置されている」といった判断もできません。調査対象の広さ、報告した時期、修正状況の把握、公開までの時間をそろえずに比較することになるからです。
自社で確認するなら、件数より先に利用製品を照合する
公開データを実務へ移す最初の作業は、全件を読むことではありません。自社のサービスや端末で使うソフトウェアと、公開された情報が関係するかを調べることです。以下は編集部が提案する進め方です。
1．製品名だけでなく、どこで何版を使っているかを出す
同じライブラリでも、外部公開サービス、社内検証用の環境、すでに停止したシステムでは扱いが違います。製品名、バージョン、利用場所、担当チームをそろえます。直接導入していなくても、購入した製品や開発用ツールに部品として含まれていないか、保守担当へ確認が必要な場合があります。
一覧を作れない段階では、AIに「影響なし」と結論を出させない方がよいでしょう。「未確認」と「非該当」を別に残すだけでも、調査漏れを後で拾いやすくなります。
2．指摘の番号から、提供元の修正情報へ進む
自社に関係しそうな対象を見つけたら、公開されているCVEやアドバイザリー、対象プロジェクトの修正案内を確認します。影響する版、問題が成立する条件、更新先を、運用している環境と照らし合わせます。
AIには資料の候補集めや項目整理を手伝わせても、似た製品名だけで適用対象を決めさせないようにします。報告書には原本へのリンクと確認日を付け、担当者が条件を読み直せる状態にします。
3．修正版の公開と、自社の対策完了を別々に記録する
上流プロジェクトの修正を見つけたら、利用中の製品で更新可能か、検証が必要か、保守ベンダーの対応待ちかを確認します。実際の更新後には、必要な機能が動くことと、対象バージョンへ変わったことを確かめます。
担当が不明なまま「修正待ち」に置くと、提供元が対応した後も社内で止まるおそれがあります。少なくとも次に確認する人と、判断を見直すきっかけを決めておきましょう。
AIを使った調査でも、台帳の一行に判断根拠を残す
対応表には、番号と深刻度だけでなく、自社での判断を残す欄を作ると役立ちます。以下は編集部の記録例で、Anthropicの画面にこのまま存在する項目ではありません。
| 記録項目 | 残す内容 |
|---|---|
| 利用箇所 | 対象サービス、実行環境、製品・部品のバージョン |
| 根拠 | 提供元のURL、対象条件、確認日 |
| 現在の判断 | 要調査、該当、非該当、更新準備中、適用確認済み |
| 次の行動 | 担当者、確認期限、判断を変える条件 |
たとえば、AIが「修正済み」と抽出したときには、それが上流での修正なのか、自社の検証環境への適用なのかを確認します。報告先の違う状態を一つの「完了」にまとめないことが重要です。
AIへの依頼も「全部対応して」より、「公開された資料から対象条件と修正先を抽出し、不明な項目は不明のまま残す」のように範囲を絞る方が、担当者が結果を点検しやすくなります。脆弱性の発見から修正までを広く知るには、AIエージェントとセキュリティ管理の記事も参考になります。
実務上の注意：深刻度と、自社の優先順位は分ける
ダッシュボードでは評価主体によって深刻度を確認できます。AIによる評価と、検証側・管理者側の評価が必ず同じになるとは限りません。自社の優先順位を決める際は、業務への影響や外部から到達できる範囲など、担当者が把握する事情も必要です。
公開済みの情報を調べることと、システムへ侵入試験を行うことも別です。許可のない対象で挙動を試したり、機密の構成情報を未承認のAIサービスへ送ったりせず、必要な調査は社内のセキュリティ手順に沿って進めてください。
まとめ：AIの発見を、自社の対策完了につなぐ
今回の更新は、AIが見つけた問題の多さだけでなく、報告・検証・修正へ進む工程を見る材料になります。企業では、利用製品との照合、根拠の確認、担当者の割当、更新後の確認までをつなげることが大切です。
まずは自社で管理する一つのサービスについて、利用バージョンと担当者が分かるかを確認しましょう。新しい脆弱性情報が届いたときに、誰が何を調べるかが決まっている状態を作ることが、実際の対策を早めます。
よくある質問
5,087件は今回の更新期間に発見された件数ですか？
いいえ。ダッシュボード更新時点の累計報告数です。今回数日間に見つかった件数や、すべて公開済みの詳細情報の件数とは異なります。
上流で修正済みなら、自社は何もしなくてよいですか？
自社で影響する版を使っているか、更新が反映されているかを確認する必要があります。修正版の公開と、自社の適用完了は別の状態です。
AIが出した深刻度をそのまま対応順に使えますか？
優先順位の参考にはなりますが、それだけでは決められません。提供元の条件と自社の構成・業務影響を照合し、担当者が判断します。
出典・参考情報
- Anthropic：Coordinated vulnerability disclosure dashboard（2026年11月2日19:30 UTC更新）
- Anthropic：About this dashboard
- Anthropic：Snapshot archive
2026年11月4日時点の公開情報を基にしています。数値は提供元が把握・公表した範囲です。台帳項目と手順は編集部の提案であり、個別システムへの影響判定は行っていません。
運営元について
AXメディアは、株式会社ジーズ AX事業部が運営しています。AX事業部では、AI研修・AIエージェント開発・ローカルLLM開発・補助金／助成金の活用支援を提供しています。
