AIが脆弱性を見つける時代の更新運用 OSS・SBOM・OT対策の進め方

Anthropicが2026年10月8日に発表した「Anthropic Cyber Mission」は、制度の中身より先に、情シスの仕事に響く一文があります。脆弱性は見つけやすくなったが、確かめて直すのは難しいままだ、という認識です。制度そのものの紹介はニュースの記事に任せ、この記事では「修正の知らせが増える前提で、情シスは何を変えるか」を公式の原文と日本の公的資料で整理します。

同じ発表は、ほかのメディアでも扱っています。Anthropic、サイバー防衛構想を発表 インフラと共有コードが対象(TECHNOVA)は発表の中身を、Anthropic、Cyber Verification Program を拡大(YOBITSUGI AI メディア)は同じ週に出た別の制度を扱っています。日本での提供は、発表には書かれていません。この記事は制度への参加を勧めるものではなく、自社の運用を見直す材料です。

公式が認めている「見つけるのは速く、直すのは遅い」

発表の「Why we're doing this」の節に、次の記述があります。

The cost of exploiting vulnerabilities has dropped, while verifying, disclosing, and fixing them is slow and still depends on people. In Glasswing, we often saw months pass between a vulnerability being found and being fixed.

訳すと、悪用にかかる費用は下がった一方、確認・公表・修正は遅く、いまも人に頼っている。Glasswingでは、見つかってから直るまでに数か月かかることがよくあった、という内容です。

同じ節で、Anthropicは「2年後にはAIが防御側に有利に働く」という見通しを示しています。ただし「近い将来はそうならないかもしれない」とも書いています。守る側に楽な時期がすぐ来るとは言っていません。

日立製作所も同じ見方を、2026年10月9日のリリースに書いています。AIの進展で、脆弱性の公開から悪用までの時間が大きく縮まっている、という趣旨です。

OSS Scannerの報告は、人の確認なしで届く

OSS Scannerの報告について、発表は次のように書いています。

The reports are model-generated and sent without human review. That means maintainers receive them faster, but it also means that some will contain inaccuracies, such as a wrong severity rating. We expect a true-positive rate above 90%, and will work to improve the true positive rate and fix quality over time.

人の確認なしで送る。重大度を間違えるものもある。正しい指摘の割合は90%を超える見込み。この3点が原文です。90%超は同社の見込みで、実績の数字ではありません。

使う側に起きる変化を、この原文から推測できる範囲で整理します。公式は、使っているOSSの修正が何件増えるとは書いていません。ただし、見つける側が速くなり、報告の確認を省く経路ができれば、保守者から出る修正の知らせは増えやすくなります。これは編集部の見立てです。

情シスが受け止めること:重大度の確かめ方と更新の段取り

重大度は、自社の使い方で変わる

IPAのCVSS v3概説は、脆弱性の評価を3つに分けています。開発元や公表する組織が付ける基本評価、時間とともに変わる現状評価、そして利用者ごとに変わる環境評価です。環境評価について、IPAは次のように書いています。

この基準による評価結果は、脆弱性に対して想定される脅威に応じ、ユーザ毎に変化します。ユーザが脆弱性への対応を決めるために評価する基準です。

誰かが付けた重大度は出発点で、最後の優先順位は自社の使い方で決める、ということです。インターネットに公開しているか、社内だけか。止めた時の影響はどれくらいか。この2点は、情シスが一番よく知っています。

確かめる先と、更新の決めごと

AIの報告に書かれた重大度だけで動かず、製品の開発元の公式な案内で確かめます。国内の製品なら、IPAとJPCERT/CCが運営する脆弱性情報サイトJVNや、IPAのJVN iPedia(脆弱性対策情報データベース)に載るかも見ます。

更新の決めごとは、次の4つを文書にしておくと動きやすくなります。

数字は自社で決めます。公式な基準は発表にありません。

自社が使っているOSSを知る:SBOMは「最小限から」でよい

修正の知らせが増えても、自社がそのOSSを使っているかが分からなければ動けません。部品の一覧を持つ考え方が、SBOM(ソフトウェア部品表)です。IPAの手引きは、SBOMを「ソフトウェアコンポーネントやそれらの依存関係の情報を含む機械処理可能な一覧リスト」と説明しています。

経産省の手引きが示す範囲の考え方

経済産業省は2024年8月29日に、SBOMの導入に関する手引のver2.0を公表しました。読者は、ソフトウェアを供給する会社と調達する会社の両方です。ver2.0で加わったのは3点です。

• 脆弱性を管理する一連の手順で、SBOMを使う具体的なやり方
• 効果とコストを見て、導入が妥当な範囲を考えるための枠組み(SBOM対応モデル)
• 委託先との契約でSBOMについて決めておく事項(要求事項、責任、コスト負担、権利など)

中小企業の情シスにとって使いやすいのは、2つめと3つめです。全部の機器を一度に一覧にするのではなく、守る範囲を決めて始められます。委託して作らせたシステムなら、納品物にSBOMを含めるかを契約で決められます。

完璧を目指さない

IPAの中核人材育成プログラムの卒業プロジェクトが作った「SBOM 導入・運用の手引き」(2024年12月)は、運用の姿勢を次のように書いています。

SBOM 運用・管理においては、運用開始直後から完璧を目指さず、まずは必要最低限のレベルを獲得し、その後よりよい SBOM 運用に向けて改善を行うことが重要である。

この手引きは、本書の内容はIPAの意見を代表せず著者の見解に基づく、とも断っています。公的機関の見解ではなく、実践の知見として読むものです。

同じ手引きは、現実の限界も書いています。SBOMのツールを使っても、検知漏れや誤検出が起きることがあり、出力の確認が欠かせません。また、SBOMで分かるのは「どの部品に脆弱性があるか」まで。対応するかどうかや優先順位の判断には大きな効果を発揮せず、特定できる脆弱性が増えるため、対応する人手が足りなくなるおそれがある、とも書いています。

つまり、一覧を作ること自体が目的ではありません。一覧の先に、先ほどの更新の決めごとがあって初めて意味が出ます。

中小企業が最初にやる範囲は、編集部の整理では次の3段階です。

1. 自社で開発・運用している業務システムのうち、外部に公開しているものだけ、使っているOSSの名前と版を書き出す。
2. 買ったパッケージや委託で作ったシステムは、提供元に部品の一覧を出せるか聞く。
3. 一覧が出ない相手は、脆弱性の連絡の方法と、更新を案内する頻度を確認して台帳に残す。

工場や設備がある会社:保守先に聞くこと

発表のCritical Infrastructure Defense Programは、電力網、水道、交通網のOTと政府システムの防御を対象とします。OTは、設備の制御や監視に使う技術です。創立のパートナーとして、Accenture、Booz Allen、CrowdStrike、Deloitte、Dragos、Hitachi、Insane Cyber、Nozomi Networks、Palo Alto Networks、PwC、Rockwell Automationの名前が挙がっています。

日立製作所は2026年10月9日のリリースで、創設パートナーとして参画すると発表しました。リリースによれば、日立はワーキンググループなどでOTの知見を共有し、得られた知見をHMAX Cyberの高度化や制御システムなどのOT製品の強化に生かす方針です。個別の製品への反映時期は書かれていません。日立の発表の読み方は日立製作所、Anthropicのサイバー防衛に参画、情シスはOT契約を確認にまとめています。ここでは繰り返しません。

OTは「止めて直せない」前提で考える

発表は、OTについて次のように書いています。

With operational technology, a fix may have to wait until it can be applied safely to running machinery …

動いている機械に安全に適用できるまで修正を待つことがある、という意味です。原文はこのあと、まれに数十年かかる場合もあると続けています。日立のリリースも、止められないインフラでは、システム停止を伴うパッチ適用などの対策を容易に実施できない、と書いています。

事務所のパソコンと同じ感覚で、すぐ更新とはいきません。そこで、設備の保守や工事を頼んでいる会社に、更新の手順を前もって聞いておきます。

取引先・保守の会社に聞くこと

JPCERT/CCは、中小の製造業が工場で産業用IoTを導入する場合のガイド「工場における産業用IoT導入のためのセキュリティ ファーストステップ」を公開しています。経営者向けの章と、現場の担当者向けに、外部の事業者との役割・業務分担や、調達時に実施したい対策を扱う章があります。同じJPCERT/CCの「J-CLICS」は、制御システムの対策状況を確かめるチェックリストで、構築・運用・保守に関わる全員が無料で使えます。

これらを土台に、編集部が整理した保守先への質問は次のとおりです。公的資料の項目そのものではない点に注意してください。

発表も、重要インフラの守りにはAIでは直せない難しさが多いと認めています。AIの活用を理由に、保守先の運用の確認を省かないでください。

OSSを公開・保守している会社:申し込み制を前提に

自社でOSSを公開している会社は、OSS Scannerの対象に当たる場合があります。ここは公式の書き方のままに整理します。

• OSS Scannerは、申し込んだプロジェクトだけが対象のopt-in(申し込み制)です。
• 申し込むのは、プロジェクトの中心の保守者です。GitHubのリポジトリにPR(変更の提案)を出して申し込みます。Anthropic側が中心の保守者であることを手動で確認します。
• 申し込んでいないプロジェクトには、人が確認した上で伝える従来の通知(CVD、協調的な脆弱性開示)が続きます。発表は「For others, we will continue to share human-verified disclosures under our CVD policy.」と書いています。
• 申し込んだ後で止める場合は、設定ファイルに停止の指定を書くか、プロジェクトの設定を削除します。止めると、従来のCVDの報告だけになります。
• サービスの対象は、確認済みの重大な報告に追いつける体制のあるプロジェクトです。公式ページは、すでに報告が多くて手が回らないプロジェクトが多いと認めています。

公開の扱いも、申し込む前に読んでおく点です。OSS Scannerの公式ページは、人の確認がない報告には90日の公開猶予を付けない、と書いています。人が確認した報告は、確認したと通知した日から90日後に、CVDの方針で公開することがあります。将来、重大度が高い報告に猶予を付ける場合は、事前に知らせ、抜けられるようにする、とも書いています。

申し込むかどうかの判断材料は、報告を誰が読み、何日で一次判断するかです。公式は、報告に追いつける体制のあるプロジェクト向けのサービスと書いています。体制が決まる前に申し込むかは、各プロジェクトの判断です。

今日からできること

1. 更新の窓口と基準を文書にする。 先の表の4項目を、1枚にまとめて上司と共有します。数字は自社で決めます。
2. 外部に公開している機器とサービスの一覧を作る。 使っているOSSの名前と版まで書けば、SBOMの最初の一歩になります。
3. 重大度は2か所で確かめる。 開発元の案内と、自社の使い方に合わせた評価(IPAのCVSS概説の環境評価の考え方)の両方を見ます。AIが付けた重大度だけで優先順位を決めません。
4. 設備の保守先に、上の質問表を送る。 回答を期限つきで求め、返事がなかった項目を台帳に残します。
5. OSSを公開しているなら、報告を読む人を決めてから、申し込むかを決める。 申し込まないなら、従来のCVDの窓口が最新かを確認します。

制度への参加や契約の変更を急ぐ必要はありません。まず、知らせが来た時に動ける状態をつくります。