「見つける」より「直す」が詰まる ── 6〜12か月の猶予に企業がやるべき脆弱性対応
Anthropic CEO ダリオ・アモデイは2026年5月5日のイベントで、AIによる脆弱性発見が急加速する中、パッチ適用に「6〜12か月」の猶予があるという見立てを示したとCNBCが報じた。同社は別途、数千件規模の高・重大深刻度の脆弱性を特定しながらも「保守者によって完全に修正されたものは1%未満」と自ら述べている。つまり企業に問われているのは、発見の速さではなく修正の速度と優先付けの質だ。本稿では、Anthropicおよび業界の指摘を踏まえた一般的な打ち手を整理する。
なぜ「修正」が詰まるのか
Anthropicが2026年5月26日に公表したProject Glasswingの進捗報告によれば、1,000超のオープンソースプロジェクトから23,019件の問題が検出され、うち6,202件が高・重大深刻度と分類された。発見はほぼ自動化できるが、修正はそうではない。OSSパッケージには複雑な依存関係があり、1つのライブラリを更新すると上位コンポーネントとの互換性が崩れるリスクがある。加えてOSS保守者の多くはボランティアであり、報告を受けてから対応できるまでに数日から数週間を要するのが現実だ。Anthropic自身も「脆弱性を見つける相対的な容易さに比べ、修正の難しさが大きな課題だ」と述べている。AIが発見を加速するほど、修正待ちの「露出ギャップ」は広がる。この構造的な非対称性こそが、現在の脅威の本質だとの見方がある。
猶予期間にやるべき打ち手 6項目
- 到達可能性で優先順位を付ける: 脆弱性の件数は膨大になりえるため、深刻度スコアだけで並べると実際の対応が追いつかない。実行環境から実際に到達・悪用可能かどうか、そして現実の攻撃キャンペーンで標的とされているかどうかを組み合わせた優先順位付けが、業界では有効とされている。「高深刻度」でも外部から到達不能な脆弱性と、到達可能でかつ既存の攻撃ツールが存在するものとでは、対応の緊急度が本質的に異なる。
- 緊急パッチ運用フローの整備: 月次の定例パッチサイクルは、外部に露出しているシステムの緊急対応には適していない。重大な脆弱性が公開された際に、承認権限・テスト省略の判断基準・展開手順をあらかじめ文書化し、定期的な演習で実効性を確認しておくことが望ましいと考えられる。フローが未整備だと、脆弱性の認識から修正完了まで組織的な遅延が生じやすい。
- ソフトウェア部品表（SBOM）とOSS依存の可視化: 自社製品や社内システムが依存するOSSコンポーネントを把握していなければ、脆弱性報告を受けても影響範囲を素早く特定できない。SBOMを整備し、新たな脆弱性情報と突き合わせる仕組みを持つことが、対応速度を上げる基盤になる。OWASP LLM Top 10でも依存関係のリスク管理は繰り返し言及されている。
- 修正不能資産への代替制御: レガシーシステムや保守者の対応を待つOSSなど、すぐにパッチを適用できない資産は必ず存在する。そうした資産については、ネットワーク分離・WAFルールの追加・アクセス制御の強化といった補償的制御（コンペンセーティングコントロール）を明文化し、修正が完了するまでの暫定措置として管理することが一般的に推奨されている。「修正できない」と「制御しない」は別の話だ。
- 実行時（ランタイム）での検知・遮断: 静的なシグネチャベースの検知は、AIで生成された新規エクスプロイトに対して後手に回りやすい。実行時の振る舞い検知・EDR・ネットワーク異常検知といった多層の防御を組み合わせ、未知のエクスプロイトに対してもある程度対応できる体制を整えることが、業界では有効と見られている。Anthropic CEOの危険な瞬間警告が示すように、攻撃側が先行する局面では検知の速度が被害の規模を左右しうる。
- 攻撃面の棚卸し: シャドーIT・設定ミス・廃止忘れのAPIエンドポイントなど、管理台帳に載っていない外部露出資産は、脆弱性管理の対象外となりやすい。外部からの視点（アタックサーフェスマネジメント）で定期的に自社の露出を点検し、把握していない資産を発見するプロセスを定例化することが、修正以前の前提として重要だと考えられる。
「見つけた」ではなく「直した」を数える。
Omamori AI の結論
- 事実: Anthropicの開示およびProject Glasswing報告（2026年5月26日）によれば、AIによる脆弱性発見の規模は急拡大しているが、完全修正された脆弱性は1%未満にとどまるとされる。発見と修正の速度差が、攻撃側に有利な窓を生んでいる。
- 判断軸: 「何件見つかったか」ではなく「到達可能で悪用リスクの高いものを何件・何日以内に修正できるか」を組織の対応指標として設定する。脆弱性の総数を追うことと、実際のリスクを減らすことは別の問いだ。
- 打ち手: 到達可能性トリアージ・緊急パッチフロー・SBOMの三つを優先的に整備する。修正できない資産への代替制御を文書化し、ランタイム検知と攻撃面の定期棚卸しを組み合わせることで、修正ボトルネックの影響を部分的に緩和できると考えられる。いずれも確定標準ではなく、組織の環境・リスク許容度に応じた判断が必要だ。
経営者視点で考えるべきこと
脆弱性対応は、情報システム部門の「件数消化」として管理されがちだが、本質は優先順位付けと修正テンポの経営問題だ。Bloombergは2026年5月19日、Mythosを受けて規制当局が米銀のサイバー攻撃耐性テストを延期させたと報じた。これは金融規制当局が、この問題を制度的なリスクとして認識し始めたことを示唆する。予算と人員の配分において、脆弱性の「発見ツール」の導入と同等かそれ以上に、修正を実行するエンジニアリング体制・承認フロー・テスト環境に投資する必要がある。FSBとAnthropicの会合（2026年5月・PYMNTS報道）が象徴するように、サイバーリスクは金融安定上の論点にもなりつつある。経営層が「何件見つかったか」ではなく「修正完了までの平均日数」を問う文化が、組織の実質的なリスク低減につながると考えられる。
