2026.09.08 11:18 (更新: 2026.09.08)

「AIが脆弱性見つける時代」のWindows更新運用をトリアージから作り直す

Hirokazu Yoshida

シニアセキュリティスペシャリスト / サイバーセキュリティスペシャリスト

こんにちは、ひろかずです。

フロンティアAIによって脆弱性の検出が急増している状況を踏まえて、脆弱性管理の運用を見直すアプローチを共有します。

忙しい人向けのまとめ

Microsoftの2026年8月月例更新は、公開日である2026年8月11日時点で421件のCVEを修正し、うち62件がCritical、1件（CVE-2026-68820）は悪用済みでした。6月206件・7月570件に続く水準であり、単発の異常値ではありません。
Microsoftは7月9日の公式ブログで、エージェント型スキャン基盤「MDASH」による脆弱性発見を工程に組み込み、「今後の各リリースでより多くの更新が含まれる」と事前に予告しました。件数増加は意図された恒常的な変化です。
8月の悪用済みゼロデイのCVSSは7.0・深刻度は「重要」止まりで、62件のCriticalより下に沈む位置にありました。CVSS降順のトリアージは、この規模では優先度判断を誤らせます。
この状況に対して、筆者は「全件を読み、検証してから配る」運用を廃し、悪用有無（KEV・Exploitedフラグ）で例外を抽出し、残りは更新リングの段階配信に自動で流す2レーン運用への切り替えを提案します。
経営層・監査への説明は、件数ではなく「悪用済みは即時、残りはN日以内」という2段SLAの遵守率と適用完了率に置き換えます。

何が起きているの？

月例400件超は「事故」ではなく予告された状態

2026年8月のMicrosoft月例セキュリティ更新（Patch Tuesday）は、公開日である8月11日時点で421件のCVEを修正しました。うち62件がCritical、ゼロデイは3件（公開済み2件・悪用済み1件）でした。製品別では、Windows、Office、SharePoint Server、Azureを含む幅広いMicrosoft製品が対象です。ここで挙げた件数はすべて公開日時点のものです。MSRCのSecurity Update Guideは公開後もCVEの追加と改訂が続くため、後日参照すると数字は一致しません。実際、本稿の執筆時点では公開済みフラグの立つCVEが3件（CVE-2026-62832・CVE-2026-69414・CVE-2026-72971）に増えています。月例の件数を引用するときは、必ず基準日と集計元を添えてください。

悪用済みの1件はWinSock用Ancillary Function Driver（afd.sys）の解放後使用によるローカル権限昇格、CVE-2026-68820です。

421件という数字だけなら「たまたま多い月」と読めます。しかし、6月7月の傾向を見ると8月の421件は、前月比で見れば「減った月」ですらあります。

6月の月例は206件で当時の過去最多（これまでの記録は2025年10月の175件）を更新
7月は570件、ZDIの集計では621件に達する。

この急増には、公式の説明が事前に出ていました。MicrosoftはWindows担当EVPのPavan Davuluri名義で7月9日にブログを公開し、マルチモデルのエージェント型スキャン基盤「MDASH」を、Windowsの重要バイナリを走査する専用クラウド基盤上で運用していること、そして「AIが防御側の問題発見を助けるにつれ、顧客は各セキュリティリリースでより多くのセキュリティ更新を目にするようになる」ことを予告しました。

件数の増加は脆弱性発見のAI化をベンダー自身が意図した結果だ、というのがMicrosoftの立場です。品質低下の兆候ではありません。Rapid7も8月のリリース解説で「Patch Tuesdayが2026年以前の件数水準に戻ると考える理由はない」と述べています。

件数はもう戻らないので。運用側の前提を変える段階に入っています。

CVE急増で、従来の優先順位付けが通用しなくなる

人手を増やしても追いつかない

421件のCVE一覧を毎月読み、1件ずつ影響評価して適用可否を判断する。この運用は人手を増やしても追いつきません。より深刻なのは、件数の多さが優先度判断そのものを狂わせる点です。

8月に実際に悪用されていたCVE-2026-68820のCVSSスコアは7.0で、Microsoftの深刻度評価も「重要（Important）」でした。 CVSS降順に並べて、スコアが高いものから対応する運用では、この1件は62件のCriticalの下、63番目以降になります。

米国国土安全保障省のサイバーセキュリティ・インフラセキュリティ庁（CISA）は、修正プログラムが公開された8月11日に、このCVEをKEV（悪用が確認された脆弱性カタログ）へ登録しました。また、CISAが発する拘束力のある運用指令BOD 26-04は、外部公開の有無・KEV掲載の有無・攻撃の自動化可能性・技術的影響の4条件で対応期限を決めています。KEV掲載の脆弱性は3日（条件によりフォレンジック調査を伴う）または14日、KEV非掲載でも外部公開資産なら3日から14日、それ以外は60日または次期システム更新時です。CVE-2026-68820にKEVが定めた期限は、登録から14日後の8月25日でした。スコアの高い順に検証していたら、本当に急ぐべき1件の期限が先に来てしまいます。

全件を最優先で対応するのも違う

Fortraのリサーチャーが6月に指摘したとおり、206件のうち公開済みは3件、悪用確認は0件でした。実際にKEVへ登録されるMicrosoft製品のCVEは、2024年1月から2026年8月までの32か月で111件、月平均3.5件（中央値3件）にとどまります。つまり「本当に例外扱いすべき件数」は昔からほとんど増えておらず、母数だけが増えている状況です。

本記事の主旨

本記事では、個々のCVEを読む運用をやめ、(1) 悪用有無（KEVとベンダーのExploitedフラグ）、(2) 自社の露出（該当コンポーネントの利用有無・外部公開有無）の2軸で例外だけを抽出し、残りの数百件は自動の段階配信で対応する形に組み替える方式を提案します。

よくある誤解

「Criticalから順に対応すれば安全」

8月の悪用済みゼロデイはImportant・CVSS 7.0でした。深刻度ラベルとKEVは別の信号であり、悪用有無を先に見ない限りCriticalの山に埋もれます。

「件数が多い月はパッチ品質が落ちているはずだから待つべき」

Microsoftは発見の加速と並行して、SUVP等の検証プログラムやAIによる修正検証への投資を増やすと説明しています。品質リスクは、個別KBの既知の問題（Known Issues）の確認とリング後段の停止手順で吸収します。待って回避するものではありません。

「全パッチを社内検証してから配るのが丁寧な運用」

月400件超の全数検証は物理的に不可能で、検証待ちの数週間はそのまま攻撃可能期間になります。悪用済みCVEには数日単位の対応期限が切られる時代です。

「EDRを入れているから適用が遅れても検知で拾える」

CVE-2026-68820は、端末への永続化を確立した攻撃者がSYSTEM権限を奪取し、EDRの可視性を無効化するために実際に悪用されました。カーネル権限昇格は、検知側の可視性そのものを損ないます。EDRはパッチ遅延の代替案になりません。

実務で問題になりやすいポイント

パッチを「配る仕組み」ではなく「例外を捌く仕組み」の不在

更新リングやWSUSの承認フローは存在するのに、悪用済みCVEが出たときに月例サイクルの外で緊急配信する手順が決まっていなければ、KEV登録済みの1件も通常の「第2リング・14日遅延」に乗ります。

リング設計の形骸化

導入時に作った「全社1リング・遅延7日」のまま数年経過し、先行リングに入っているのが情シスの数台だけ、という構成は珍しくありません。しかし、この構成では先行リングで問題を検知し、後段の配信を止めるという段階配信の目的を果たせません。

Windows以外のソフトウェアやサーバーへの対応

8月はOfficeだけで98件、SharePoint Serverで30件が修正されています。 Windows Updateのリングは整備されていても、Microsoft 365 Appsの更新チャネルやオンプレSharePointのパッチ計画が別担当・別サイクルで放置されている構成は、対応の穴になりやすいです。

技術的・運用的な確認ポイント

トリアージ方法の変更

まず、CISA KEVへの登録有無、MicrosoftのExploited／Exploitation More Likelyフラグ、公開済み（Publicly Disclosed）フラグの3つを一次フィルタにします。

Microsoft Security Update Guide（MSRC）では、各種フラグを個々の脆弱性情報内で確認する必要があります。そこで、PowerShellの公式モジュールで情報を抽出し、CISA KEVカタログと突合します。

サンプルのPowerShellスクリプトを掲載するので参考にしてください。

動作確認環境
- macOS 26.6.2
- PowerShell 7.6.5
Get-MsrcPriorityCves.ps1
💡
使い方
- pwsh ./Get-MsrcPriorityCves.ps1 -MonthId 2026-Sep
出力ファイル
- MSRC-Priority-YYYY-MMM.csv（他にも出ますが、基本的にはこれを見ればいいです）
見るべきポイント
- Category — 最初に見る列。緊急（KEV掲載 or Exploited=Yes）/ 優先調査（PubliclyDisclosed=Yes or Exploitation More Likely）
- InKEV / KevDueDate — CISA KEV 掲載の有無と、米政府機関向けの修正期限。実際に悪用が確認されている証拠なので、緊急度の裏付けとして最も強い
- Exploited — MSRC が悪用を検知しているか
- LatestSoftwareRelease — 名前に反してバージョン番号ではなく、最新版に対する悪用可能性評価です（Exploitation Detected / More Likely / Less Likely / Unlikely の4段階。評価対象外は N/A）。MSRC の列名をそのまま使っているため紛らわしい点です
- KevRansomwareUse — ランサムウェアでの使用実績
⚠️
サンプルスクリプトは、2026/09/08時点での動作を確認していますが、将来にわたっての動作を保証しません。サンプルスクリプトの利用とその結果の判断は、ご自身の責任で行ってください。

#!/usr/bin/env pwsh
#Requires -Version 7.0
<#
.SYNOPSIS
    MSRC月次CVRFデータとCISA KEVを突合し、対応優先度別にCVEをCSV出力する。
.DESCRIPTION
    分類条件:
      緊急     : CISA KEVに存在する OR MSRCの Exploited が Yes
      優先調査 : PubliclyDisclosed が Yes OR Exploitability assessment が Exploitation More Likely
.EXAMPLE
    pwsh ./Get-MsrcPriorityCves.ps1 -MonthId 2026-Aug
#>
[CmdletBinding()]
param(
    # 対象月 (例: 2026-Aug)。省略時は当月。月例公開前は前月を明示指定すること
    [ValidatePattern('^\d{4}-(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)$')]
    [string]$MonthId = (Get-Date).ToString('yyyy-MMM',
        [System.Globalization.CultureInfo]::InvariantCulture),

    # 出力先ディレクトリ
    [string]$OutDir = $PWD.Path,

    [string]$KevUrl = 'https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json'
)

$ErrorActionPreference = 'Stop'

# ---- 1. モジュールの確認・導入 -------------------------------------------
if (-not (Get-Module -ListAvailable -Name MsrcSecurityUpdates)) {
    Write-Host '[*] MsrcSecurityUpdates モジュールをインストールします (CurrentUser)...'
    Install-Module -Name MsrcSecurityUpdates -Scope CurrentUser -Force
}
Import-Module -Name MsrcSecurityUpdates

# ---- 2. MSRC CVRF ドキュメント取得 ----------------------------------------
# Get-MsrcCvrfDocument の -ID は /Updates の一覧から動的 ValidateSet を生成するため、
# 一覧にまだ載っていない月は API を叩く前に「引数が不正」として弾かれる。
# ここでは同じ REST API を直接呼び、公開の有無は HTTP 応答で判定する。
$apiUrl     = if ($global:msrcApiUrl)     { $global:msrcApiUrl }     else { 'https://api.msrc.microsoft.com/cvrf/v3.0' }
$apiVersion = if ($global:msrcApiVersion) { $global:msrcApiVersion } else { 'api-version=2023-11-01' }

function Invoke-MsrcApi {
    param([Parameter(Mandatory)][string]$Path)

    $params = @{
        Uri         = '{0}/{1}?{2}' -f $apiUrl, $Path, $apiVersion
        Headers     = @{ 'Accept' = 'application/json' }
        TimeoutSec  = 120
        ErrorAction = 'Stop'
    }
    # モジュールがプロキシ設定を持っていれば引き継ぐ
    if ($global:msrcProxy)           { $params.Proxy           = $global:msrcProxy }
    if ($global:msrcProxyCredential) { $params.ProxyCredential = $global:msrcProxyCredential }
    Invoke-RestMethod @params
}

Write-Host "[*] MSRC CVRF ($MonthId) を取得中..."
try {
    $document = Invoke-MsrcApi -Path "cvrf/$MonthId"
} catch {
    $reason = $_.Exception.Message

    # /Updates の索引はドキュメント公開に遅れて追随する (実際 2026-Aug / 2026-Sep は
    # 索引未登録のまま取得できた)。したがって索引の最新月を「取得可能な最新月」として
    # 提示してはならない。あくまで参考値として添えるだけにする。
    $indexLatest = $null
    try {
        $monthIds = @((Invoke-MsrcApi -Path 'Updates').value.ID |
            Where-Object { $_ -match '^\d{4}-[A-Za-z]{3}$' } |
            Sort-Object { [datetime]::ParseExact($_, 'yyyy-MMM', [cultureinfo]::InvariantCulture) })
        if ($monthIds) { $indexLatest = $monthIds[-1] }
    } catch { }

    $prev = ([datetime]::ParseExact($MonthId, 'yyyy-MMM', [cultureinfo]::InvariantCulture)
        ).AddMonths(-1).ToString('yyyy-MMM', [cultureinfo]::InvariantCulture)

    $msg = "MSRC CVRF ($MonthId) を取得できませんでした: $reason"
    $msg += "`n月例公開 (Patch Tuesday) 前などで未公開の可能性があります。"
    if ($indexLatest) {
        $msg += "`n参考: /Updates 索引の最新月は $indexLatest (索引は公開に遅れるため、これより新しい月を直接取得できる場合があります)。"
    }
    $msg += "`n前月を試す場合: pwsh ./Get-MsrcPriorityCves.ps1 -MonthId $prev"
    throw $msg
}

$release = $document.DocumentTracking.CurrentReleaseDate
if ($release) { Write-Host "[*] CVRF 公開日: $release" }

# ---- 3. Exploitability Index を取得し CVE 単位で重複排除 -------------------
$index = Get-MsrcCvrfExploitabilityIndex -Vulnerability $document.Vulnerability |
    Sort-Object -Property CVE -Unique

# 実プロパティ名の防御的チェック(モジュール更新で名称が変わった場合に検知)
$expected = 'CVE', 'PubliclyDisclosed', 'Exploited', 'LatestSoftwareRelease'
$actual   = ($index | Select-Object -First 1).PSObject.Properties.Name
$missing  = $expected | Where-Object { $_ -notin $actual }
if ($missing) {
    Write-Warning "想定プロパティが見つかりません: $($missing -join ', ')"
    Write-Warning "実際の列名: $($actual -join ', ')"
    throw 'プロパティ名を確認し、スクリプトを修正してください。'
}
Write-Host "[*] Exploitability Index: $($index.Count) 件のCVE"

# ---- 4. CISA KEV 取得 ------------------------------------------------------
Write-Host '[*] CISA KEV カタログを取得中...'
$kev = Invoke-RestMethod -Uri $KevUrl -TimeoutSec 120
$kevMap = @{}
foreach ($v in $kev.vulnerabilities) { $kevMap[$v.cveID] = $v }
Write-Host "[*] KEV: $($kev.count) 件 (catalogVersion: $($kev.catalogVersion))"

# ---- 5. 突合・分類 ---------------------------------------------------------
$result = foreach ($row in $index) {
    $inKev      = $kevMap.ContainsKey([string]$row.CVE)
    $exploited  = $row.Exploited -eq 'Yes'
    $disclosed  = $row.PubliclyDisclosed -eq 'Yes'
    $moreLikely = $row.LatestSoftwareRelease -like '*More Likely*'

    $category = if ($inKev -or $exploited)          { '緊急' }
                elseif ($disclosed -or $moreLikely) { '優先調査' }
                else                                { $null }
    if (-not $category) { continue }

    $kevEntry = if ($inKev) { $kevMap[[string]$row.CVE] }
    [PSCustomObject]@{
        Category              = $category
        CVE                   = $row.CVE
        Title                 = $row.Title
        PubliclyDisclosed     = $row.PubliclyDisclosed
        Exploited             = $row.Exploited
        LatestSoftwareRelease = $row.LatestSoftwareRelease
        OlderSoftwareRelease  = $row.OlderSoftwareRelease
        InKEV                 = $inKev
        KevDateAdded          = $kevEntry.dateAdded
        KevDueDate            = $kevEntry.dueDate
        KevRansomwareUse      = $kevEntry.knownRansomwareCampaignUse
    }
}
$result = $result | Sort-Object -Property Category, CVE

# ---- 6. CSV 出力 (utf8BOM: macOS版Excelでの文字化け防止) --------------------
$allCsv = Join-Path $OutDir "MSRC-Priority-$MonthId.csv"
$result | Export-Csv -Path $allCsv -NoTypeInformation -Encoding utf8BOM

foreach ($cat in @{ '緊急' = 'Urgent'; '優先調査' = 'Investigate' }.GetEnumerator()) {
    $subset = $result | Where-Object Category -eq $cat.Key
    if ($subset) {
        $path = Join-Path $OutDir "MSRC-$($cat.Value)-$MonthId.csv"
        $subset | Export-Csv -Path $path -NoTypeInformation -Encoding utf8BOM
    }
}

# ---- 7. サマリ -------------------------------------------------------------
Write-Host ''
Write-Host "===== $MonthId 突合結果 ====="
Write-Host ("緊急     : {0} 件 (KEV掲載 or Exploited=Yes)" -f
    @($result | Where-Object Category -eq '緊急').Count)
Write-Host ("優先調査 : {0} 件 (PubliclyDisclosed=Yes or Exploitation More Likely)" -f
    @($result | Where-Object Category -eq '優先調査').Count)
Write-Host "出力先   : $allCsv"

この方式であれば、8月の精査対象はCVE-2026-68820（悪用済み）とCVE-2026-62832（公開済み・User Profile Serviceの権限昇格・CVSS 7.8）などの数件に絞れます。 CVSSは絞り込んだ後の順位付けにだけ使います。

更新リング設定の見直し

次に、通常パッチは個別の手動承認を前提とせず、更新リングによる段階的な自動配信を既定とします。Intuneの更新リング（またはAutopatchグループの展開リング）で、先行（遅延0〜3日）→一般（7日前後）→保守系（14日前後）の段階配信を構成し、先行リングで問題が出たら後段を一時停止する運用に統一します。

緊急レーンの設置

悪用済みCVEを含む品質更新プログラムについては、Intuneの迅速化ポリシー（Expedite policy）を使い、通常の更新リングで設定した延期期間を迂回する手順と、その発動基準（KEV登録・Exploitedフラグ）をあらかじめ決めておきます。この仕組みが対象にできるのはWindowsの品質更新だけです。Microsoft 365 Appsやオンプレサーバー製品には、各製品側の緊急適用手順を別に用意しておきます。

適用完了率の確認

更新管理で確認するのは、配信が終わったかどうかではありません。端末への適用が完了したかどうかです。Windows Autopatchでは、Windows品質更新の概要ダッシュボードの「% with the latest quality update」で、最新の品質更新を適用済みの端末割合を確認できます。

未適用端末は品質更新ステータスレポートで特定し、オフライン、更新エラー、再起動待ちなどの原因を解消します。月次報告には、全社およびリング別の適用完了率、未適用台数、例外理由を記録してください。

対応方針の比較表

方針	例外（悪用済みCVE）への速度	通常パッチの速度	運用負荷	向いている組織	主なリスク
全件手動承認（WSUS型）	遅い（人手依存）	遅い	非常に高い	ほぼ推奨せず	月400件超で承認が形骸化・遅延が常態化
更新リングのみ（段階自動配信）	リング設定次第	速い	中	Intune導入済みの中堅規模	緊急レーン未整備だと悪用済みCVEも遅延に乗る
更新リング＋迅速化の2レーン	延期を迂回（完了時間は端末状態に依存）	速い	中	本記事でおすすめする構成	発動基準・合格基準の文書化を怠ると属人化
Autopatch（展開リング自動運用）	速い	速い	低〜中	ライセンス要件を満たす組織	機能更新の制御方式が固定される点の事前確認が必要

見直し時のチェックリスト

毎月のトリアージ一次フィルタがKEV・Exploited・Publicly Disclosedの3指標を基にしている（CVSS降順ではない）
更新リングが2段以上に分かれ、先行リングに実利用者（各部門の代表端末）が含まれている
先行リングの合格基準（確認するアプリ・操作・期間）が文書化されている
悪用済みCVEを含む品質更新について、延期期間を迂回して適用を開始する緊急レーンの手順と発動基準がある
再起動の期限・猶予設定が構成され、適用完了率（配信率ではない）をレポートで追っている
Microsoft 365 Apps・Edge・オンプレSharePoint／Exchangeの更新が、Windowsと同じトリアージ基準・SLA・報告サイクルに載っている（配信機構は製品ごとに別でよい）
（先行リングで、更新プログラムに起因する可能性が高く、全社展開すると影響が拡大する問題を検知したときに）リング後段を一時停止する判断者と手順が決まっている
適用できない例外機（レガシーアプリ依存等）の台帳と、ネットワーク分離などの代替統制がある

経営層・監査部門への説明ポイント

経営層への説明

パッチ運用の大変さは訴えません。前提の変化として以下三点を伝えます。

Microsoftが自社ブログでAIによる発見増と更新件数の恒常的増加を公式に予告したこと
2026年の月例件数が206→570→421件と推移していること
それでも悪用が確認される件数は月数件にとどまること。

この3点から、増員して全件を人が精査する体制よりも、「悪用済みはXX時間以内・その他はN日以内」という2段SLAと自動配信基盤への投資が合理的である、という結論に繋ぎます。

監査部門への説明

説明するのは、すべてのCVEを人が個別に検証したかどうかではありません。リスクに応じた対応基準が定義され、その基準どおりに運用されたことです。提示する証跡は以下4点です。

脆弱性区分ごとの対応期限を定めたSLA
月次の適用完了率と未適用理由
緊急レーンの発動、および配信停止・再開の判断記録
例外端末と代替統制を記載した台帳

この4点から、悪用済みの脆弱性を期限内に処理し、通常更新を段階的に展開し、未適用端末と例外を継続管理していることを示します。統制の有効性は、SLAの遵守率、適用完了率、例外管理、判断記録の妥当性で評価できる、と説明します。

実務担当者が次に取るべき対応ステップ

事前準備

トリアージ基準とSLAを決める
- KEV掲載またはExploited＝Yesを「緊急」、Publicly Disclosed＝YesまたはExploitation More Likelyを「優先調査」とする
- 緊急・優先調査・通常の区分ごとに、評価開始と適用完了の期限を定める
対象製品と資産情報を整理する
- Windows、Microsoft 365 Apps、Edge、オンプレミスのSharePoint ServerやExchange Serverについて、利用製品、バージョン、外部公開の有無、担当者を一覧化する
ライセンスと適用情報の閲覧方法を確認する
- Windows Autopatchの前提条件で、契約中のライセンス、Windowsエディション、管理方式、デバイス登録状態が要件を満たすか確認する
- Microsoft Intune管理センターの「レポート」→「Windows Autopatch」→「Windows 品質更新プログラム」（英語UIでは Reports > Windows Autopatch > Windows quality updates）を開けることを確認する
- Windows品質更新の概要ダッシュボードで「% with the latest quality update」を確認し、品質更新ステータスレポートで未適用端末と更新状態を確認できるよう、閲覧権限と担当者を決める
通常配信の更新リングを整備する
- 先行・一般・保守系のリングを構成し、先行リングには各部門の代表端末と主要な業務アプリを含める
- 先行リングの合格基準、後段リングの停止条件、停止・再開の判断者を決める
緊急レーンと記録様式を用意する
- 更新リングの延期期間を迂回する手順、発動権限、対象端末への連絡方法を定める
- SLA、適用完了率、発動・停止・再開の判断、例外端末と代替統制を記録する様式を用意する

月例公開後の運用

月例公開日に優先CVEを抽出する
- MSRCの月次データとCISA KEVを突合し、事前に定めた基準で「緊急」「優先調査」を抽出する
当日中に自社への影響を判断する
- 該当製品・バージョンの利用状況と外部公開の有無を確認し、緊急レーンを発動する対象と対応期限を確定する
先行リングから段階的に配信する
- 合格基準を満たしたら後段リングへ展開する。更新に起因する重大な問題を検知した場合は後段を停止し、判断理由を記録する
SLA期限まで適用完了を追う
- 適用完了率を確認し、未適用端末のオフライン、更新エラー、再起動待ちなどの原因を解消する
月次報告を作成する
- 対象製品全体のSLA遵守率、適用完了率と未適用理由、緊急レーンおよび配信停止・再開の判断記録、例外端末と代替統制をまとめ、経営層・監査部門へ報告する

まとめ

パッチの洪水は止まりません。今日やるべきことは2つです。現在悪用が確認されているCVE-2026-68820の適用完了を確認すること、そして来月のPatch Tuesdayを「KEVとExploitedフラグで例外を抜き、残りをリングに流す」手順で迎えられるよう、緊急レーンと合格基準を今月中に文書化することです。

この記事が誰かの役に立てば幸いです。

FAQ

Q1. なぜ2026年に月例パッチの件数が急増したのですか？

Microsoftが「MDASH」と呼ぶエージェント型スキャン基盤をWindowsの重要バイナリに適用し、脆弱性発見を工程に組み込んだためです。同社は2026年7月9日の公式ブログで、今後の各リリースで更新件数が増えると予告しています。

Q2. CVSSスコアの高い順に対応すれば十分ですか？

不十分です。2026年8月に実際に悪用されていたCVE-2026-68820はCVSS 7.0・深刻度「重要」で、62件のCriticalより低い位置にありました。悪用有無（KEV・Exploitedフラグ）を先に確認し、CVSSは補助指標として使ってください。

Q3. KEVとは何ですか？

KEV（Known Exploited Vulnerabilities）とは、米CISAが実際の悪用を確認した脆弱性を登録・公開するカタログです。米連邦機関には対応期限が課され、民間でも優先順位づけの一次信号として広く使われています。

Q4. 全パッチを検証してから配布するべきではないのですか？

月400件超の規模では全数検証は成立せず、検証待ち期間がそのまま攻撃可能期間になります。自社で過去に問題が出た観点に絞った合格基準を先行リングで確認し、問題時に後段を止める設計への転換を推奨します。

Q5. 更新リングとWindows Autopatchはどう使い分けますか？

更新リングはポリシーを自分で設計・運用する方式、Autopatchは展開リングの生成・運用を自動化する方式です。バージョン固定など細かい制御要件があるなら手動設計、運用負荷の削減を優先するならAutopatchが候補になります。利用可否はライセンスとデバイス登録形式に依存するため、契約内容の確認が先です。

Q6. EDRを導入済みなら、パッチ適用を急ぐ必要は下がりますか？

下がりません。悪用済みのカーネル権限昇格はSYSTEM権限取得後にエンドポイント防御の無効化に使われる類型であり、EDRの可視性自体が損なわれるおそれがあります。パッチと検知は補完関係にあります。

Q7. Windows以外（Office・SharePoint等）はどう扱えばよいですか？

2026年8月はOfficeだけで98件、SharePoint Serverで30件が修正されており、Windowsと同等の管理対象です。ただし更新リングと迅速化ポリシーはWindowsの品質更新専用の仕組みで、Microsoft 365 Appsは更新チャネル、オンプレ製品は各製品のパッチ計画と、配信機構は別立てになります。統合すべきなのは配信機構ではなく、トリアージ基準・SLA・適用完了率の報告です。

タグ