Mythos後の脆弱性運用は、「全部見る」時代から「誰が捨てる判断をするか」の時代に入った

1. 結論

私は、Mythosの登場よりも、米国の公的脆弱性データベース運営機関が全件詳細分析の運用を維持できなくなったことの方が、企業現場には重いと見ています。

理由は単純です。これまで多くの企業は、脆弱性対応の優先順位を外部の点数や公的データベースに依存してきました。

「CVSSが高いから対応する」「公的DBでCriticalだから急ぐ」「まだスコアが低いから後回し」「一覧に出ていないから様子見」

この運用が、もう危なくなりました。

2026年4月15日、米国の公的脆弱性データベース運営機関は、従来は全CVEに対して深刻度や影響製品などの詳細情報を付与することを目指していたが、今後は一定基準を満たすCVEを優先して詳細付与する方針に変えると公表しました。CVE提出数は2020年から2025年で263%増え、2026年第1四半期も前年同期比で約3分の1増えているためです。

つまり、現場の言葉で言えばこうです。

外部機関が全部を採点してくれる時代は終わり、企業が自分で「直す・待つ・監視する・受容する」を決めなければならなくなった。

山崎行政書士事務所のクラウド法務の視点では、これは単なるセキュリティ運用変更ではありません。取締役会、情シス、法務、SOC、委託先、開発会社、クラウド運用会社が、脆弱性を捨てる判断まで説明できる体制を作れという話です。

2. 私が現場で一番危ないと見るのは、「未採点の脆弱性」です

これから現場で増えるのは、こういう状態です。

CVE番号はある。でも、公的DB側の詳細分析がまだない。CVSSがない、またはベンダー側スコアだけ。影響製品の整理が粗い。悪用実績は不明。AIが危険と言っている。ベンダーは「調査中」と言う。SOCは「ログが足りない」と言う。事業部は「止められない」と言う。経営は「結局、危ないのか危なくないのか」と聞く。

この状況が一番危ないです。

なぜなら、誰も決めたがらないからです。

情シスは「根拠が足りない」と言う。法務は「通知義務があるか判断できない」と言う。開発部門は「再現できていない」と言う。委託先は「契約範囲外」と言う。経営層は「専門家に任せる」と言う。

その間に、攻撃者はAIで再現を試します。守る側は会議をします。攻撃する側は検証します。この差が現場を壊します。

3. 「全件対応」は、もう美徳ではなくなる

私は、これからの脆弱性対応で一番やってはいけないのは、機械的な全件対応だと考えています。

昔は、「見つかった脆弱性は全部直しましょう」と言うのが安全側に見えました。しかし、Mythos級のAIで検知数が増えると、それは逆に危険になります。

軽微な脆弱性に現場が追われる。パッチ適用で障害が出る。重要システムの確認が後回しになる。本当に悪用されている脆弱性への対応が遅れる。開発者が疲弊する。SOCがアラート疲れする。経営層への報告がノイズだらけになる。

現場では、脆弱性対応はただの作業ではありません。

影響確認。検証環境での再現。パッチ適用テスト。本番反映の承認。障害時の切り戻し。顧客影響確認。委託先調整。監査証跡。経営報告。

全部に人間が関わります。

だから、これから必要なのは「全部直す」ではありません。直す順番を決めることです。さらに言えば、直さないものを、なぜ直さないのか説明できることです。

4. 米国公的DBの変更は、日本企業の現場にそのまま刺さる

日本企業の多くは、脆弱性対応で外部データに頼っています。

公的DB。ベンダー通知。診断ツールのスコア。SOCからの通知。SIerの月次報告。EDRやCSPMの推奨事項。クラウドベンダーのセキュリティアラート。

これまでは、それらを見て「高い順に対応」でも、ある程度は回りました。

しかし、公的DB側が詳細付与を絞ると、現場ではこうなります。

診断ツールがスコアを出せない。SBOM管理ツールの優先順位が荒くなる。委託先から「判断できません」と返ってくる。監査で「なぜ対応しなかったのか」と聞かれる。取引先から「このCVEへの対応状況を出せ」と言われる。CVEはあるが、社内で影響有無を説明できない。

これは、クラウド法務の問題です。

なぜなら、脆弱性対応は技術だけでは閉じないからです。

契約上のSLA。顧客通知義務。委託先の修正義務。再委託先の報告義務。個人情報漏えい可能性。重要インフラ・金融・医療・製造の継続責任。取締役会への報告。監査証跡。

ここに全部つながります。

5. Mythosで本当に変わったのは、「発見」ではなく「処理量」です

私は、Mythosの能力を神格化しすぎる必要はないと思っています。ただし、現場に与える影響は非常に大きいです。

AI開発企業Aは2026年4月7日、Mythosを一般公開ではなく限定的な研究プレビューとして提供し、重要ソフトウェアの脆弱性発見・修正を目的とする枠組みを始めました。同社は、Mythosが重要インフラに関わるソフトウェアで数千件のゼロデイ脆弱性を特定したと説明しています。

また、2026年4月13日の英国側評価では、Mythosは専門家レベルのCTF課題で73%の成功率を示し、32ステップの企業ネットワーク攻撃シミュレーションでも10回中3回を完了し、平均22ステップまで進めています。ただし、その評価環境は現実の防御体制を完全に再現するものではないという限界も示されています。

私がここで見るのは、恐怖演出ではありません。見ているのは、処理量の爆発です。

人間なら見つけられなかったものをAIが見つける。人間なら数日かかった再現をAIが短縮する。人間なら見落とす依存関係をAIが拾う。人間なら優先順位づけに迷う量が、一気に流れてくる。

脆弱性の洪水です。

そして、企業側の処理能力は急には増えません。

セキュリティ担当者は増えない。開発者も増えない。テスト環境も増えない。予算も急には増えない。取締役会の理解も追いつかない。委託先の契約範囲も変わっていない。

ここに本当の危機があります。

6. 現場で起きる「脆弱性対応会議」の生々しい姿

私は、これから企業で次のような会議が増えると見ています。

セキュリティ部門が言います。「AIがこのOSSに重大な脆弱性の可能性を出しています」

開発部門が言います。「そのOSSは3年前に別の委託先が入れたもので、今の担当者は詳しくありません」

情シスが言います。「本番で使っているか、すぐには分かりません」

委託先が言います。「SBOMは契約成果物に含まれていません」

法務が言います。「顧客に通知すべきか判断材料が足りません」

監査が言います。「対応しないなら理由を残してください」

経営層が言います。「結局、事業を止める必要があるのか」

誰も悪くありません。でも、準備していなければ、ここで止まります。

これから必要なのは、会議ではなく、事前に決めた判断基準です。

7. 私なら、脆弱性の優先順位をこう決める

私は、単純なCVSS順では判断しません。現場で本当に見るべきなのは、次です。

外部公開されているか。認証なしで到達できるか。悪用コードが存在するか。既に悪用されているか。自社の重要システムに入っているか。個人情報・決済・医療・金融・認証に関わるか。クラウド管理権限に届くか。横展開に使われるか。バックアップやログを消せるか。代替統制があるか。パッチ適用で業務停止が発生するか。委託先が修正できるか。顧客契約上の通知義務があるか。規制・監査上の報告対象になり得るか。

これを見ないと、点数だけ高い脆弱性に振り回されます。逆に、点数は中程度でも、自社の構成では致命的なものを見落とします。

米国の公的DB運営機関も、2026年4月15日以降、既知悪用カタログに載るもの、連邦政府で使われるソフトウェア、重要ソフトウェアなどを優先して詳細付与するとしています。低優先のものでも重大影響を持つ可能性があり、利用者は個別に詳細付与を依頼できるとも説明しています。

この考え方は企業にも必要です。

自社版の優先順位基準を持つこと。これがない企業は、外部の採点が薄くなった瞬間に迷子になります。

8. Azure環境では、まず「悪用されたか確認できるログ」があるかを見る

脆弱性が見つかった後、必ず聞かれる質問があります。

「すでに悪用されていますか」

この質問に答えられない会社は多いです。

なぜか。

ログを取っていない。保存期間が短い。ログの種類が足りない。委託先がログを持っている。クラウドの診断設定が有効になっていない。Key Vaultのアクセスログがない。Entra IDの監査ログを見ていない。アプリログにユーザーIDがない。WAFログとアプリログがつながらない。Sentinelに取り込んでいない。KQLを書ける人がいない。

この状態でAIが脆弱性を見つけても、企業はこう言うしかありません。

「悪用有無は確認できません」

これは技術的に正直な回答ですが、経営・顧客・監査には重い回答です。

Azure環境では、私はまず次を見ます。

Entra IDサインインログ。監査ログ。Azure Activityログ。Key Vaultログ。Storageログ。WAFログ。Application Gatewayログ。Defenderアラート。Sentinelインシデント。Log Analyticsの保存期間。PIM昇格ログ。サービスプリンシパルの操作記録。GitHubまたはAzure DevOpsの監査ログ。

脆弱性対応は、パッチを当てることだけではありません。悪用有無を説明できる証跡を持つことです。

9. SBOMがない会社は、これから毎回詰まる

AIで脆弱性検知が増えると、SBOMの有無が実務を分けます。

SBOMがある会社は、影響範囲を検索できます。SBOMがない会社は、人に聞きます。

「このOSS、どこで使っていますか」「このライブラリ、製品Aに入っていますか」「このバージョン、まだ使っていますか」「委託先が入れたものですか」「コンテナに入っていますか」「サーバーレス関数に入っていますか」「昔のモジュールに残っていませんか」

これを毎回やるのは無理です。

SBOMは、形式だけ作っても意味がありません。現場で使えるSBOMには、次が必要です。

製品名。システム名。利用OSS。バージョン。配置場所。管理責任者。委託先。保守期限。更新方法。本番利用有無。顧客影響。代替統制。

私は、これからのクラウド法務では、SBOMを契約成果物に入れるべきだと考えます。委託開発で、何のOSSが入っているか分からない成果物を受け取るのは、もう危険です。

10. 委託契約が古いままだと、AI脆弱性時代に耐えられない

多くの委託契約は、AIで脆弱性が大量に見つかる時代を想定していません。

「脆弱性があれば対応する」「重大な不具合は協議する」「セキュリティに配慮する」

この程度では足りません。

私は、委託契約・SOWには少なくとも次を入れるべきだと考えます。

脆弱性通知を受けた場合の報告期限。AIで検知された脆弱性の扱い。再現検証の責任。修正期限。暫定回避策の提示義務。ログ提出義務。SBOM提出義務。再委託先への通知義務。CVE・公表前情報の秘密保持。顧客説明資料作成への協力。緊急パッチ時の費用負担。保守切れコンポーネントの扱い。

これを入れないと、事故時に必ず揉めます。

「それは保守契約外です」「追加費用です」「再委託先に確認中です」「ログは保存していません」「SBOMはありません」「AI検知なので正式な脆弱性とは言えません」

このやり取りをしている間に、攻撃者は動きます。

11. 取締役会が見るべき数字も変わる

取締役会に、CVE一覧をそのまま出しても意味がありません。経営層が見るべきなのは、技術一覧ではなく、判断に必要な数字です。

私は、取締役会向けには次を出します。

未対応のCritical相当件数。外部公開システムに関係する未対応件数。既知悪用ありの未対応件数。SBOMで影響確認できない件数。ログ不足で悪用有無を確認できない件数。保守切れ資産の件数。委託先回答待ち件数。例外承認している件数。修正期限超過件数。重要顧客影響の可能性がある件数。復旧不能・更新不能機器の件数。

これが経営資料です。

「脆弱性は多いです」では足りません。「どこに経営判断が必要か」を示す必要があります。

山崎行政書士事務所のクラウド法務では、技術チームが持っている脆弱性情報を、取締役会が読めるリスク報告に変換することが重要になります。

12. 企業が今すぐ整えるべき実務

私は、Mythos後の脆弱性運用として、企業に次を整えるべきだと考えます。

12.1 自社版の脆弱性優先順位基準

CVSSだけでなく、自社の公開範囲、データ重要度、悪用可能性、クラウド権限、委託先、業務影響で判断します。

12.2 SBOM・資産台帳

どのシステムに何が入っているか分からなければ、AIが出した脆弱性に対応できません。

12.3 Azureログ設計

悪用有無を確認できるログを、保存期間・閲覧権限・KQLとセットで整えます。

12.4 委託契約・SOWの見直し

AI検知脆弱性、SBOM、ログ提出、修正期限、再委託先対応、秘密保持を入れます。

12.5 例外承認台帳

すぐに直せない脆弱性は必ず出ます。その場合、誰が、どの根拠で、いつまで受容したかを残します。

12.6 取締役会向け脆弱性レポート

技術一覧ではなく、経営判断が必要な未対応リスクを出します。

12.7 顧客・取引先向け説明テンプレート

脆弱性影響、対応状況、暫定回避策、悪用有無、今後の予定を説明できる形にします。

13. 最終評価

私は、今回の変化をこう見ています。

Mythosが脆弱性を増やしたのではない。見えなかった脆弱性が、見えるようになった。しかし、人間の修正能力、契約、ログ、取締役会報告、委託先管理が追いついていない。

これが本質です。

米国の公的DBが全件詳細分析を維持できなくなったことは、世界中の企業に対してこう告げています。

外部の点数を待つな。自社で優先順位を決めろ。直さない判断も記録しろ。悪用有無をログで説明しろ。委託先に逃げられない契約にしろ。取締役会が分かる形で報告しろ。

山崎行政書士事務所のクラウド法務として、私はこのテーマを次の一文で整理します。

AI時代の脆弱性対応は、検知の問題ではない。検知された大量の脆弱性を、契約・規程・Azureログ・SBOM・委託先管理・取締役会報告で処理できる会社になることだ。

これができない会社は、AIで脆弱性が見つかるほど、かえって混乱します。これができる会社は、Mythos級AIを防御側の力に変えられます。