見つける速さに、直す速さが追いつかない
ソフトウェアの弱点、いわゆる脆弱性を探す作業は、これまで専門家の時間と経験に強く依存してきました。その前提が変わりつつあります。生成AIの開発企業Anthropicは2026年10月8日、オープンソースソフトウェア（OSS）の開発者向けに、AIによる脆弱性検査を無償で定期提供する「OSS Scanner」を発表しました。同日には、重要インフラとOSSの防御を支援する長期の取り組み「Anthropic Cyber Mission」も公表しています。
中小企業の経営者にとって、OSSの開発者向けサービスは遠い話に見えるかもしれません。しかし、自社の業務システム、ホームページ、クラウドサービスの多くは、OSSを部品として組み込んでいます。上流で見つかる弱点が増えれば、その修正は更新プログラムとして、IT委託先や製品ベンダーを経由して自社へ届きます。問われるのは、届いた修正を誰が受け付け、どの順で、いつまでに適用し、適用後に何を確かめるかという、ごく実務的な管理です。
発表が示した数字と、その条件
Anthropicの研究チームの説明によれば、同社は過去6か月、最新モデルで重要なOSSを検査し、2万9,000件を超える「脆弱性の候補」を見つけました。一方、人が確認して選別できたのは約6,000件にとどまり、検証する人手がボトルネックになっていると述べています。
https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source
OSS Scannerの出力は、人による確認や選別を経ず、モデルが生成したまま開発者へ送られます。各報告には再現手順、弱点の説明、可能な場合は修正案が付きます。同社は、速く頻繁に届けられる反面、誤った報告や無効な報告が含まれうると明記しています。初期版の検証では、重大度が緊急または高とされた97件を、開示報告を審査する専門の侵入テスト担当者が確認しました。85件（88%）が同社の開示基準を満たし、残る12件のうち11件は実在するものの既知の問題などとの重複で、誤検知は1件だったとしています。一方で開発者からは、重大度が過大に付けられる、プロジェクト固有の脅威の前提を誤解している、といった指摘もあったと記されています。利用した側の評価として、暗号ライブラリwolfSSLの担当者は、受け取った74件のうち2件を除いて有効で、5件がCVE（公開された脆弱性の識別番号）になったと述べています。
対象は、インフラや利用者の安全に重大な影響を持つOSSで、参加は開発者側の申請制です。自力で報告をさばく余力のないプロジェクトには、従来どおり人が確認した報告を届けるとしています。Cyber Missionの発表では、脆弱性を見つけることはかつてなく容易になった一方、検証・優先順位付け・修正はなお難しく、発見から修正まで数か月かかる例が多かったと振り返っています。
https://www.anthropic.com/news/anthropic-cyber-mission
なお、本稿は2026年10月13日時点の公表内容に基づいており、数値の多くは同社自身の評価で、第三者による検証結果ではありません。
「候補」と「確定」のあいだに工程がある
この発表から読み取るべき要点は、AIの検出性能の高さそのものよりも、候補と確定した脆弱性のあいだに、人が担う工程が厚く残っているという事実だと考えます。2万9,000件と6,000件の差は、まさにその工程の容量の差です。
候補が確定に変わるには、本当に再現するか、既知の問題と重複していないか、自社の使い方で実際に攻撃が成立するかを確かめる必要があります。重大度も、ソフトウェア単体での評価と、自社の環境での影響は一致しません。社外から接続できない機器の弱点と、インターネットに公開された受付フォームの弱点では、同じ「高」でも急ぐべき度合いが異なります。
発見の費用が下がると、管理側には二つの変化が起きます。届く修正の件数が増えること、そして攻撃側も高性能なAIで同じ弱点を探せるため、放置の危険が高まることです。発見が自動化されるほど、確定させて直す側の段取りが経営上の論点になります。
委託先からの修正を「検収」として管理する
多くの中小企業では、システムの保守を外部に委託しています。ここで提案したいのは、委託先から届く修正を、物品の納品と同じく検収の対象として扱うことです。要点は四つあります。
第一に受付です。委託先からの連絡、製品ベンダーの公表、公的機関の注意喚起を一か所の台帳で受け付け、対象システム、受付日、情報源を記録します。担当者のメールに埋もれたままでは、後から適用状況を説明できません。あわせて委託先には、対象のバージョン、修正の内容、影響する機能、事前試験の結果を提出物として求めると、後の判断が速くなります。
第二に優先度です。委託先が示す重大度をそのまま採用せず、外部公開の有無、扱う情報の重要性、業務停止の影響を加味して社内の区分を決めます。この判断は、システムを日常的に使う業務責任者と委託先の技術者が合同で行うのが適切です。
第三に期限です。区分ごとに適用期限を定め、期限内に適用できない場合は、代替策と延期理由を記録して責任者が承認します。製造業の設備制御のように止められないシステムでは、Cyber Missionの発表でも触れられているとおり修正が長く待たされることがあり、通信の遮断や監視の強化といった代替策の承認が実務の中心になります。
第四に適用後の確認です。修正を適用した担当者と、適用結果を確認する担当者を分け、更新後のバージョン、業務機能の動作、ログの異常の有無を証跡として残します。作業者と確認者を分ける職務分掌は、会計の承認手続きと同じ発想です。
契約と予算に織り込むべき点
検収の仕組みは、保守契約の条項と予算に裏付けられていなければ機能しません。現行の契約が、どの範囲の修正を月額の保守料で対応し、どこから別途見積りになるのかを確認しておく必要があります。修正の件数が増える局面で範囲が曖昧なままだと、対応の遅れか、想定外の追加費用のどちらかが生じます。
判断の材料として、仮の試算を示します。年商10億円、営業日240日の企業で、受注・出荷システムが3日停止し、その間の売上の半分が失われ、粗利率を25%と仮定します。1日当たり売上は約417万円、3日間の逸失売上は約625万円、失われる粗利は約156万円です。復旧費用や信用の毀損は含みません。年間の修正対応に追加で数十万円を払う判断は、この規模の損失と比べて検討できます。
会計上、修正対応の費用を保守費として処理するか、機能追加を伴う改修として資産計上を検討するかは、契約内容と作業の実態によって異なります。請求書の名目だけで決めず、作業内容の内訳を委託先から受け取っておくと、判断の根拠を残せます。
経営者が決めておく三つのこと
AIが脆弱性を探す速度は、今後も上がると見込まれます。Anthropic自身、2年後にはAIが防御側に有利に働くと予測する一方、当面は攻撃のコストが下がり、検証や修正は遅く人に依存したままだと述べています。予測が当たるかどうかにかかわらず、経営者が先に決められることがあります。
一つは、修正の受付台帳と責任者を置くこと。二つ目は、委託先の重大度を自社の区分に置き換える基準と期限を定めること。三つ目は、適用の延期を誰が承認し、適用後の確認を誰が行うかを明確にすることです。候補が大量に届く時代の安全は、検出の精度だけでなく、確定させて直し、直ったことを確かめる段取りによって決まります。