先に結論:163件の全部を急ぐ必要はない。「当てる順番」を決める仕組みが勝負
2026年4月14日(米国時間の第2火曜)に公開されたMicrosoftの月例更新「Patch Tuesday」は、Microsoft製品だけで**163件のCVE(脆弱性)**を修正した。公開時点で判明している範囲では2025年10月に次ぐ規模で、いわゆる「大きい月」にあたる。この記事の要点を先に置く。
- 悪用が実際に確認されているのは1件だけ。 実環境で攻撃が観測されているのはCVE-2026-32201(SharePoint Serverのなりすまし)。ここが最優先の起点になる。
- もう1件のゼロデイは「悪用確認」ではなく「PoC公開済み」。 Microsoft Defenderの権限昇格 CVE-2026-33825(通称 BlueHammer) は、パッチ提供前に検証コードがGitHubに公開された「公開済みゼロデイ」で、公開時点では野生での悪用は確認されていない(後述のとおり、この違いは対応優先度を左右する)。
- CVSSが最も高いのはゼロデイではなくCritical。 IKE(IPsec VPNの鍵交換)の**CVE-2026-33824(CVSS 9.8・認証不要のRCE)**が最悪シナリオを持つ。VPNをインターネットに直接公開している中小企業はここが本命だ。
- 163件を「全部同じ緊急度」で扱うと必ず手が止まる。 中小企業に必要なのは全件即時適用ではなく、「悪用有無 → 公開有無 → 自社に該当資産があるか → 露出面か」で機械的に順位を付ける仕組みだ。
162件、163件、167件——数字は情報源によって割れる。だが経営判断として重要なのは「今月は何件だったか」ではない。毎月これが来ることを前提に、検証から適用までの体制を平時から回せているかである。この記事では、まず4月分の中身を一次情報で正確に押さえ、その後「件数に振り回されない中小企業のパッチ管理体制」の作り方まで踏み込む。自社の運用が属人化していると感じるなら、中小企業向けのセキュリティ運用を月額で伴走するパッケージがどこまでを肩代わりできるかも、判断材料として本文で触れる。
EMERGENCY RESPONSE
この脆弱性、貴社システムは影響を受けますか?
影響範囲の一次評価を無料で実施。致命的脆弱性は24時間以内にアラートし、パッチ適用・恒久対応まで伴走します。
この記事を読むべき人
- Windows/Microsoft 365を業務の中核に使っている年商1〜10億円規模の中小企業の経営者・事業責任者
- 情シスが専任1名、あるいは他業務との兼任情シスで、毎月のパッチ対応が「気合いと残業」で回っている会社
- SharePoint Server(オンプレ)、Active Directory、IPsec VPNのいずれかを自社で運用している会社
- 「パッチは配ったが、本当に全端末に当たっているか分からない」状態を放置している会社
- パッチ管理を内製で続けるべきか、外部に委託すべきか、判断軸が欲しい経営層
技術者向けの詳細な攻撃解析ではなく、「うちは何を、どの順で、誰が、いつまでにやるべきか」を決めるための判断材料として書いている。
4月Patch Tuesday 2026の全体像(一次情報ベース)
まず数字を正確に押さえる。ここでの数値はMicrosoft Security Response Center(MSRC)の更新ガイドと、それを検証したTenable・ZDI(Zero Day Initiative)・Sophos・Krebs on Securityの各分析を突き合わせたものだ。
横にスクロールして確認できます
| 項目 | 内容 |
|---|---|
| 公開日 | 2026年4月14日(米国時間の第2火曜) |
| Microsoft製品のCVE修正数 | 163件 |
| Critical | 8件 |
| Important | 154件 |
| Moderate | 1件 |
| 悪用確認済みゼロデイ | 1件(CVE-2026-32201 SharePoint) |
| 公開済み(PoC公開)ゼロデイ | 1件(CVE-2026-33825 Defender/BlueHammer) |
| 「30日以内に悪用の可能性が高い」と評価された件数 | 24件(ベンダー分析) |
「163件」なのか「167件」なのか — カウントの差を先に潰す
ニュースによって163・165・167・168と数字がばらつくのは、誤報ではなく数え方の違いだ。Microsoft自身が採番したCVEは163件だが、これにChromiumベースのMicrosoft Edge向けに再掲されたブラウザ系CVEや、Adobe等サードパーティの更新を加えると167〜168件、アドバイザリまで合算すると250件前後になる。Sophosは「163件+アドバイザリ88件」、ZDIは合算247件と整理している。
経営判断上のポイントはここだ。「今月は何件」の見出しの数字を追っても意味はない。 自社に関係するのは、そのうち「自社が使っている製品」「インターネットに露出している資産」に該当する数件〜十数件だけである。件数の大小に一喜一憂せず、後述の優先度フレームで自社分だけを抜き出す運用に切り替えるのが正解だ。
種類別の内訳(脆弱性の“質”を見る)
件数と同じくらい、どの種類の脆弱性が多い月かは運用判断に効く。4月分をベンダー集計で見ると次のような分布だった。
横にスクロールして確認できます
| 脆弱性の種類 | おおよその件数 | 中小企業への含意 |
|---|---|---|
| 権限昇格(EoP) | 94件 | 単体では侵入できないが、侵入後の“横展開・SYSTEM奪取”に使われる。エンドポイント更新が効く |
| リモートコード実行(RCE) | 20件 | 最も危険。特に認証不要・ネットワーク経由のものはサーバ側を最優先 |
| 情報漏えい | 20件 | 資格情報・設定値の窃取につながる |
| セキュリティ機能バイパス(SFB) | 12件 | BitLocker等「最後の砦」を無効化する系。物理紛失リスクと直結 |
| なりすまし/DoS/改ざん 等 | 17件 | フィッシングやサービス停止に悪用 |
権限昇格が全体の約6割を占めるのは近年の常態だ。これは「入口さえ塞げば安心」ではなく、万一侵入されても“上に上がれない・横に広がれない”状態を作るために、サーバだけでなく全端末を更新し切ることが重要だということを意味する。
最優先で見るべきゼロデイ2件 — ただし緊急度は同じではない
「ゼロデイ2件」と一括りにされがちだが、この2件は対応の緊急度がはっきり違う。ここを混同すると、限られた工数を配分ミスする。
CVE-2026-32201:SharePoint Server なりすまし(悪用確認済み・最優先)
横にスクロールして確認できます
| 項目 | 内容 |
|---|---|
| 影響製品 | Microsoft SharePoint Server(2016 / 2019 / Subscription Edition) |
| 種類 | なりすまし(Spoofing、XSS関連とみられる) |
| CVSS | 6.5 |
| 悪用状況 | 実環境での悪用を確認(MSRCが「exploited in wild」と明記) |
CVSSは6.5と“数字上は中程度”だが、すでに攻撃が観測されている点で本月の実質No.1だ。攻撃者は入力検証の不備を突き、ユーザー操作なしで正規の相手になりすまし、社内ポータルのデータを読み取り・改ざんできる。オンプレのSharePoint Serverを社内ポータルや文書管理に使っている企業は、当日〜数日以内の適用スケジュール確定が必要になる。
重要な補足:SharePoint Online(Microsoft 365のクラウド版)は本CVEの対象外だ。クラウド側はMicrosoftがインフラで対処するため利用者の作業は不要。ただしオンプレとOnlineを併用するハイブリッド構成では、オンプレ側の適用を忘れないこと。「うちはM365だから関係ない」と早合点して、実はオンプレSharePointが残っていた、という棚卸し漏れが典型的な失敗パターンだ。
CVE-2026-33825:Microsoft Defender 権限昇格「BlueHammer」(PoC公開済み)
横にスクロールして確認できます
| 項目 | 内容 |
|---|---|
| 影響製品 | Microsoft Defender |
| 種類 | 権限昇格(Elevation of Privilege) |
| CVSS | 7.8 |
| 悪用状況 | 公開済み(PoC公開)。4月3日にGitHubへ検証コードが公開。公開時点で野生での悪用は未確認 |
ここが原稿・報道で最も誤解されやすい点なので明確にする。BlueHammerは「悪用確認済み」ではない。 発見した研究者がMicrosoftの対応に業を煮やして先に検証コードを公開した「公開済みゼロデイ」であり、パッチ公開時点では実際の攻撃は観測されていない(TenableおよびKrebs on Securityが「publicly disclosed prior to a patch」と明記)。
ただしPoCが出回っている=悪用のハードルが劇的に下がっているのも事実だ。防御の要であるDefender自体が踏み台になる構図で、初期侵入に成功した攻撃者がSYSTEM権限を奪う“横展開の一歩”に使われうる。位置づけは「今すぐ火が出ているCVE-2026-32201の次」——悪用確認済みの1件を当てた直後に、48時間以内で押さえるべき第2優先だ。なお本件はDefenderの定義ファイル更新ではなく、Windows Update経由のエンジン更新で塞がれる。
判断のコツ:「悪用確認済み」>「PoC公開済み」>「未公開のCritical」の順で緊急度は下がる。ゼロデイという言葉に反応して全部を同じ最優先枠に入れると、本当に火が出ている1件への集中が薄まる。
Critical 8件 — 本命はゼロデイではなくIKEとTCP/IP
4月のCriticalは8件(ほかにChromium系Critical 2件)。中小企業が“自社に該当があれば最優先”で見るべきものを整理する。
横にスクロールして確認できます
| CVE | コンポーネント | 種類 | CVSS | 注記 |
|---|---|---|---|---|
| CVE-2026-33824 | IKE(IPsec VPN鍵交換) | RCE | 9.8 | 認証不要・ネットワーク経由。IKEv2有効の公開VPNは最悪シナリオ |
| CVE-2026-33827 | Windows TCP/IP | RCE | 高 | IPv6+IPsec有効時の競合状態。ワーム化(自己増殖)の懸念 |
| CVE-2026-33826 | Active Directory | RCE | 8.0 | ドメイン内の認証済みユーザーが悪用可、DC上でコード実行 |
| CVE-2026-32157 | リモートデスクトップ クライアント | RCE | — | 悪意あるサーバへ接続させられると危険 |
| CVE-2026-32190 | Microsoft Office | RCE | — | 文書開封を起点にした攻撃 |
| CVE-2026-33114 / 33115 | Microsoft Word | RCE | — | 同上、Word文書経由 |
| CVE-2026-23666 | .NET Framework | DoS | — | サービス停止 |
CVE-2026-33824(IKE, CVSS 9.8)— 公開VPNがあるなら本月の最優先候補
今月で最も高いCVSS。IKEはIPsec VPNの鍵交換に使うプロトコルで、VPNゲートウェイをインターネットに直接公開している環境では認証なし・操作なしでリモートコード実行が成立しうる。リモートワークでIPsec VPNを使う中小企業は、悪用確認済みのSharePointと並ぶ最優先として扱うべきだ。即時適用が難しい場合の暫定緩和は明確で、IKEが不要な系ではUDP 500/4500を信頼IPに制限またはブロックする(MSRCも一時緩和策として提示)。
CVE-2026-33827(TCP/IP)— “ワーム化”という言葉に反応する
IPv6とIPsecが有効なシステムの競合状態を突くRCEで、認証もユーザー操作も不要。ベンダー分析では「ワーム化しうる(wormable)」と評価されている。ワーム化する脆弱性は、1台が感染すると勝手にネットワーク内を広がるため、パッチ適用の“取りこぼし端末”が致命傷になる。適用率95%では足りず、残り5%が発火点になるタイプだと理解しておくべきだ。
CVE-2026-33826(Active Directory, CVSS 8.0)— ランサムの本丸
ADはほとんどの企業ネットワークの認証基盤で、ドメインコントローラー(DC)を奪われることはネットワーク全体の制御を奪われることと等しい。ランサムウェア攻撃グループはADの脆弱性を優先的に狙う。認証済みユーザーが必要という条件はあるが、フィッシングで一般社員の1アカウントを取られた時点で条件は満たされる。DCは“最初に守る/最初に当てる”資産として扱う。
その他の注目:BitLockerバイパスとブラウザ系ゼロデイ
- CVE-2026-27913(BitLocker セキュリティ機能バイパス/CVSS 7.7・Important):物理アクセスがある攻撃者が、暗号化されたディスクの内容を読み取れる。ノートPCの盗難・紛失時、BitLockerは「最後の砦」だが、その砦に穴が開く。モバイルワークを推進する会社ほど重い。CVSSは中程度でも、紛失インシデント時の情報漏えい直結度で優先度を上げるべき一件だ。
- ブラウザ系(Chromium/Edge):本月の合算には、Chromium由来で再掲されたブラウザ脆弱性が多数含まれる。中でもWebGPU「Dawn」のUse-After-Free CVE-2026-5281 は実際の攻撃で悪用が確認され、CISA KEVにも登録された事案だ。攻撃手口と対処はMicrosoft Edgeの緊急パッチとDawnゼロデイの解説記事で詳しく扱っている。ブラウザはWindows Updateとは別系統で更新が走るため、「OSは当てたがEdgeは古いまま」という盲点に注意したい。
なお、CWE(脆弱性の型)で見ると、今月はUse-After-Free(56件)と競合状態(34件)が過半を占めた。これは「メモリ破壊系」「タイミング攻撃系」が主戦場ということで、古いソフトを長く使い続ける環境ほど当たりやすいことを示す。EOL(サポート終了)製品を抱えたまま延命している会社は、パッチ以前に“載せ替えの計画”が別途必要になる。
GXOの優先度フレーム:163件を「自社の十数件」に絞り込む5つの問い
ここからがこの記事の本題だ。中小企業のパッチ対応が破綻する最大の原因は、「163件」という総数に呑まれて優先順位を付けられなくなることにある。GXOがセキュリティ運用の整理で使う考え方は、CVSSの数字だけを見るのではなく、次の5つを上から順に当てはめて“自社にとっての緊急度”を機械的に決めるものだ。
- 悪用されているか?(Exploited)— MSRCの「exploited in wild」やCISA KEV登録があるものは、CVSSの高低に関係なく最上位。今月ならCVE-2026-32201がこれ。CVSSは6.5でも最優先になる。
- PoC/技術詳細が公開されているか?(Publicly disclosed)— 検証コードが出回っているものは悪用が時間の問題。今月ならBlueHammer(CVE-2026-33825)。
- その製品を自社が使っているか?(Asset match)— SharePoint Serverが無ければCVE-2026-32201は自社の緊急度リストから外れる。資産棚卸しが無いと、この絞り込みが一切できない。ここが最初の失敗点。
- インターネットに露出しているか?(Exposure)— 公開VPN・公開Webサーバ・公開RDPは、内部限定の資産より一段緊急度を上げる。今月のIKE(CVE-2026-33824)は「公開VPNがあるか」で天と地。
- 認証・操作が不要か?(Attack complexity)— 認証不要・ユーザー操作不要のRCE(IKE、TCP/IP)は、条件付きのものより優先。
この5問を通すと、163件は「自社が今週中に必ず当てる数件」「今月中に当てる十数件」「通常運用で流す残り」に自動的に仕分けられる。CVSSの単純降順で並べるのは間違いだ——今月まさに、悪用確認済みのSharePointはCVSS 6.5で、悪用未確認のCriticalより下に沈んでしまう。「悪用有無 → 公開有無 → 資産該当 → 露出 → 攻撃難易度」の順で見るのが、限られた工数を正しく配る唯一の方法である。
今すぐ実行する3ステップ(暫定緩和込み)
ステップ1:悪用確認・公開済み・認証不要RCEを48時間以内に
上の5問で最上位に来た以下を、48時間以内の適用目標に置く。
横にスクロールして確認できます
| 優先度 | CVE | 対象 | 理由 |
|---|---|---|---|
| 最優先 | CVE-2026-32201 | SharePoint Server | 悪用確認済み |
| 最優先 | CVE-2026-33824 | IKE(公開VPN) | CVSS 9.8・認証不要RCE |
| 高 | CVE-2026-33827 | TCP/IP(IPv6+IPsec) | ワーム化懸念・認証不要RCE |
| 高 | CVE-2026-33825 | Defender(BlueHammer) | PoC公開済み・SYSTEM奪取 |
| 高 | CVE-2026-33826 | Active Directory | DC上のRCE・ランサム標的 |
手順は、(1) WSUSまたはIntuneで該当CVEを含むKB番号を特定、(2) テスト環境で主要業務アプリの起動確認、(3) 本番展開開始——の順。即時適用できない場合の暫定緩和を必ずセットで用意するのがプロの運用だ。IKEならUDP 500/4500の制限、公開SharePointならWAFやアクセス元IP制限、RDPなら公開停止・多要素の強制、といった“パッチが当たるまでの時間を稼ぐ”手当てを同時に打つ。SharePointの適用は再起動を伴うため、業務時間外のメンテナンスウィンドウを確保する。
ステップ2:残りのCritical・Importantを1週間以内に
- WSUS:自動承認ルールで「Critical」「Important」を即時承認する設定を確認する。
- Intune:Windows Updateリングで品質更新の延期日数を(対象リングは)0日に設定する。
- 手動管理:Microsoft Updateカタログから該当KBをダウンロードし、スクリプトで展開する。
展開後は、全端末のインストール状況(成功/失敗/保留)、再起動完了、業務アプリの互換性を確認する。「配布した」=「適用された」ではない。再起動が完了して初めてパッチは有効になる。
ステップ3:適用状況の可視化と“取りこぼし”の追跡
- WSUSレポートまたはIntuneコンプライアンスダッシュボードで適用率を週次確認する。
- 適用率が95%を下回る場合はアラートを設定し、未適用端末の原因を個別に潰す。
- 経営層向けに月次で「今月のリスクがどれだけ下がったか」を1枚で報告する。
前述のとおり、TCP/IPのようなワーム化系脆弱性では残り5%が発火点になる。95%で満足せず、100%に近づける追跡フローが要る。
件数に振り回されない:2026年の“実データ”が示す運用設計の勘所
「毎月増え続けている」という感覚論ではなく、一次情報で確認できる2026年の月次実績を並べると、運用設計に効くヒントが見える。以下はMSRCおよびTenable・Krebs on Security・ZDI・Splashtopの各集計を突き合わせた数値で、集計方法(Chromium再掲を含むか等)により±数件のブレはある。
横にスクロールして確認できます
| 月 | Microsoft CVE修正数(概数) | 悪用確認ゼロデイ | 備考 |
|---|---|---|---|
| 2026年1月 | 約113件 | — | Critical 8件 |
| 2026年2月 | 約55件 | 6件 | 悪用中ゼロデイが多発した月 |
| 2026年3月 | 約83件 | 1件 | |
| 2026年4月 | 163件 | 1件(+公開1件) | 公開時点で年内2番目の規模 |
| 2026年7月 | 570件超(再掲含め600件超の報道も) | 3件 | 年内最大級・記録的な月 |
ここから読み取れる、中小企業の運用設計に直結する示唆は次の3つだ。
示唆1:件数は「右肩上がり」ではなく“乱高下”する。 1月113件 → 2月約55件 → 3月約83件 → 4月163件と、月次件数は倍半分の幅で揺れる。つまり平均値に合わせて人員・工数を組むと、多い月に必ず溢れる。設計すべきは「平均を捌く体制」ではなく「スパイク(163件・570件超のような月)が来ても崩れない体制」だ。
示唆2:悪用中ゼロデイは“数”ではなく“予測不能なタイミング”で来る。 4月は悪用確認1件だったが、2月は同じ月に6件の悪用中ゼロデイが集中した。ゼロデイのたびに緊急体制を組み直すのではなく、「悪用確認CVEは検知から48時間で当てる」というSLAを平時から動かしておくことでしか、この予測不能性には対応できない。
示唆3:件数の総量より「自社に該当する製品」が決定要因。 163件でも570件でも、自社に関係するのはSharePoint・AD・VPN・Office・Edgeといった“いつもの顔ぶれ”だ。攻撃者が好むコンポーネント(SharePoint、Active Directory、IPsec VPN、TCP/IP、Defender、ブラウザ)を事前に「自社の重要資産」として指定しておけば、毎月の優先順位付けが機械化できる。
つまり、月次件数のニュースを追うことにはほとんど価値がない。価値があるのは、自社の資産台帳と、悪用確認CVE用の別建てSLA、そしてスパイク耐性のある運用フローを持っているかどうかだ。
中小企業のパッチ管理体制 — 役割・プロセス・KPIで“属人化”を解く
中堅・中小企業では専任のパッチ管理チームを置けないのが普通で、兼任情シスの数名が他業務の合間に回しているのが実情だろう。「人を増やす」前に、役割・プロセス・KPIの3点を設計することで、現有人員でも品質を上げられる。
役割:3ロールで責任を切り分ける
横にスクロールして確認できます
| ロール | 想定担当 | 主な責務 |
|---|---|---|
| パッチ責任者 | 情シス課長クラス(兼任可) | 月次の適用判断、ゼロデイ対応の意思決定、経営報告 |
| パッチ運用担当 | 情シス担当者 | WSUS/Intune運用、KB特定、テスト検証、本番展開 |
| 業務アプリ検証 | 各業務部門の代表者 | 主要業務アプリの動作確認、互換性問題の現場報告 |
全部を情シス担当1人に背負わせると、業務アプリの互換性検証が真っ先に形骸化する。「パッチを当てたら基幹の受発注が動かない」は中小企業で最も痛い事故のひとつで、これは技術ではなく“業務側で誰が動作確認するか”を決めていないことが原因だ。業務部門に検証担当を兼務で置き、毎月30分の確認時間を制度化するだけで事故率は下がる。
プロセス:月次サイクルを5フェーズで固定する
横にスクロールして確認できます
| フェーズ | タイミング | 内容 |
|---|---|---|
| 1. 情報収集 | 第2火曜の翌日 | MSRC・JPCERT/CC・ベンダー分析を収集 |
| 2. 優先度判定 | 翌日中 | 前述の5問フレームで自社の緊急度に仕分け |
| 3. テスト適用 | +2〜3日 | テスト環境で適用、業務アプリ動作確認 |
| 4. 本番展開 | +4〜7日 | リング1→2→3で段階展開 |
| 5. 適用率レビュー | 月末 | 適用率レポート、未適用端末の追跡、経営報告 |
「リング展開」は本番を3集団に分けて段階適用する手法だ。リング1(情シス端末・20台程度)→ リング2(一部部門・100台程度)→ リング3(全社)と広げれば、互換性問題が起きても影響を局所化できる。ゼロデイだけはこのサイクルの外に置き、テスト工程を最小化してでも48時間で当てる別ルートを用意する。
KPI:4指標で“回っているか”を可視化する
横にスクロールして確認できます
| KPI | 目安 | 測定 |
|---|---|---|
| ゼロデイ対応SLA | 悪用確認から48時間以内に95%以上へ適用 | Intueコンプライアンス |
| 月次パッチ適用率 | 適用開始から7日以内に95%以上 | WSUS/Intuneレポート |
| 未適用端末の解消 | 月末までに0台へ | 月次集計 |
| 業務影響インシデント | 月0件 | サービスデスク集計 |
KPIは「達成率を上げるため」だけでなく「未達の原因を特定するため」にある。適用率が80%で頭打ちなら、原因はリモート端末のオンライン時間不足、出張中端末、退職者用スペア端末などに切り分けられる。原因が分かれば手が打てる——KPIはそのための道具だ。
パッチ管理でよくある“失敗パターン”7つ
GXOがセキュリティ運用の相談で繰り返し見てきた、パッチ管理が破綻する典型を挙げる。自社に1つでも当てはまるなら、体制の見直しどきだ。
- 資産台帳が無い/古い。 どの端末・サーバに何が載っているか分からず、「該当するか」の判定ができない。優先度付け以前の問題。
- 「M365だから安心」の思い込み。 クラウドとオンプレの責任分界を混同し、オンプレSharePoint/Exchangeの適用が漏れる。
- サーバは当てるが端末は放置。 権限昇格が6割を占める現状で、エンドポイント更新を軽視すると“横展開され放題”になる。
- 暫定緩和を用意しない。 「パッチが当たるまで無防備」の時間を放置。IKEのUDP制限のような手当てを同時に打たない。
- 配布=完了だと思っている。 再起動未完了・失敗端末を追跡せず、適用率の実態を把握していない。
- ゼロデイと通常パッチを同じSLAで回す。 火が出ている1件が、月次サイクルの中に埋もれる。
- 経営に報告していない。 リスクが下がったかを可視化できず、必要な投資(人・ツール・委託)の承認が下りない。
これらは「知識」ではなく「仕組み」で解く問題だ。悪用確認済みの脆弱性を突かれて実際にインシデントが起きてしまった場合は、パッチ管理の改善論より先に初動が要る。その段階ならインシデント対応の初動を相談できる窓口に、封じ込め・原因調査・復旧の順で動いてもらうのが先だ。
発注前・外部委託の判断チェックリスト
パッチ管理を内製で続けるか、外部委託(マネージドサービス)に出すかを迷ったら、以下を上から確認する。1つでも「×」があり、かつ人を増やす予算が取れないなら、委託を検討する段階だ。
- 全端末・全サーバの資産台帳が最新化されており、OS・主要ソフトのバージョンが分かる
- SharePoint Server・Exchange・AD・VPNなどインターネット露出資産の一覧がある
- EOL(サポート終了)製品を把握し、載せ替え計画がある
- 悪用確認CVE用の48時間SLAが文書化され、実際に守れている
- テスト環境で業務アプリの互換性を検証できる(または検証代替手段がある)
- 適用率を週次で可視化し、未適用端末を個別追跡できている
- 業務部門に動作確認の担当と時間が割り当てられている
- 月次で経営層に「リスク低減の状況」を1枚で報告できている
- 暫定緩和(ポート制限・公開停止・多要素強制)を打つ手順がある
- インシデント発生時のエスカレーション先と初動手順が決まっている
委託先に必ず聞くべき5つの質問
外部委託を検討するなら、次を数字で確認する。曖昧な回答しか返ってこない委託先は避けたい。
- 悪用確認ゼロデイの適用SLAは何時間か。 その根拠と実績値も。
- 月次レポートの粒度は。 端末種別・リング別の適用率、未適用の理由まで出るか。
- テスト環境をどう用意するか。 自社の業務アプリ互換性をどう担保するか。
- 暫定緩和まで面倒を見るか。 パッチが当たるまでの手当ての提案があるか。
- インシデント時のエスカレーションは。 悪用を検知した際、誰がいつまでに何をするか。
こうした「体制ごと肩代わり」を月額で受けられるのが、脆弱性対応・EOL対応・棚卸をまとめた中小企業向けの月額セキュリティ運用パッケージのような伴走型サービスだ。単発のパッチ代行ではなく、資産棚卸しからSLA運用・月次報告までを継続で回せるかで選ぶとよい。
GXOに相談すべきタイミング
次のいずれかに当てはまるなら、自社だけで抱え込まず、第三者に体制ごと整理してもらう段階だ。
- 今月の163件で手が止まった。 「どれから当てるか」を毎回その場の判断で決めており、優先度フレームが仕組み化されていない。
- 悪用確認CVEに48時間で対応できない。 現有人員では、火が出ている1件にすら間に合わない。
- 属人化している。 特定の1人が抜けるとパッチ運用が止まる。
- 経営に説明できない。 リスクが下がっているか、投資対効果があるかを数字で示せない。
体制そのものを立て直すなら、リスク評価から優先順位付け、運用設計までを一体で見るセキュリティ体制の再構築が起点になる。継続的な月次運用を外に出したいなら前掲の月額パッケージ、すでに侵害が疑われる緊急時はインシデント対応の窓口——と、自社の“今いる段階”で入口を選べばよい。まず何から着手すべきかを整理したい場合は、予算別に「何を先にやるか」を示した中小企業のセキュリティ費用と優先順位の実践ガイドも判断材料になる。
よくある質問(FAQ)
Q1. 163件すべてを一括適用しても問題ないですか?
Windows Update経由のパッチはMicrosoftが互換性テスト済みで、通常の業務環境なら一括適用で問題が出るケースは稀です。ただし独自開発ツールやレガシー基幹システムとの互換性は、事前にテスト環境(またはリング1の情シス端末)で確認してください。万一問題が出ても、該当KBを個別にアンインストールすれば切り戻せます。
Q2. 「ゼロデイ2件」ですが、両方を同じ緊急度で当てるべきですか?
いいえ。悪用が実際に確認されているCVE-2026-32201(SharePoint)が最優先で、CVE-2026-33825(BlueHammer)は「PoCが公開されているが公開時点で悪用未確認」です。悪用確認済みを先に当て、その直後にBlueHammerを48時間以内で押さえる、という順序が合理的です。「ゼロデイ」という言葉で全部を同格扱いしないことが、限られた工数を正しく配るコツです。
Q3. WSUSもIntuneも無い小規模企業はどうすれば?
最低限、(1)各端末で「設定→Windows Update→更新プログラムのチェック」を手動実行、(2)更新後に必ず再起動、(3)自動更新が有効か確認、の3点を徹底してください。端末が10台を超えるなら、Microsoft 365 Business Premiumに含まれるIntuneの導入で管理工数を大きく減らせます。それも回らないなら、月額の外部運用に出すのが現実解です。
Q4. SharePoint Online(M365)もCVE-2026-32201の影響を受けますか?
いいえ。本CVEはオンプレのSharePoint Serverが対象で、SharePoint Online(クラウド版)はMicrosoftがインフラ側で対処するため利用者の作業は不要です。ただしオンプレとOnlineを併用するハイブリッド構成では、オンプレ側の適用を忘れないでください。
Q5. ゼロデイ対応の「48時間以内」が現有体制で守れません。どうすべき?
段階的に整えます。(1)対象を絞る——まずDC・公開SharePoint・公開VPNなど露出資産だけ48時間、端末は7日、と分ける。(2)テスト工程を簡略化——ゼロデイはリング1(情シス端末)での動作確認に留める。(3)外部委託——マネージドサービスへ移管する。まず(1)から始め、運用が安定したら次を検討するのが現実的です。
Q6. 内製で続けるべきか、外部委託すべきか、どこで線を引きますか?
判断軸は「悪用確認CVEに48時間で対応できているか」「業務アプリの互換性検証の品質を維持できているか」「月次でリスク低減を経営に報告できているか」の3点です。3つとも○なら内製で十分。1つでも×があり増員予算が取れないなら、委託を検討する段階です。委託先は本文の「聞くべき5つの質問」をSLAの数字で確認してから選んでください。
Q7. 毎月の件数はどう推移していますか?件数で危険度を測れますか?
2026年は月次件数が乱高下しています(1月約113件、2月約55件で悪用中ゼロデイ6件、3月約83件、4月163件、7月は570件超)。総件数と危険度は比例しません。危険度は「悪用が確認されているか」「自社に該当製品があるか」で決まります。件数のニュースを追うより、自社の資産台帳と優先度フレームを整えるほうが実利があります。
まとめ
横にスクロールして確認できます
| 項目 | ポイント |
|---|---|
| 4月のMicrosoft CVE修正数 | 163件(Critical 8/Important 154/Moderate 1) |
| 悪用確認済みゼロデイ | 1件:CVE-2026-32201(SharePoint Server なりすまし・CVSS 6.5) |
| 公開済みゼロデイ | 1件:CVE-2026-33825(Defender/BlueHammer・CVSS 7.8・PoC公開) |
| 最高CVSS | CVE-2026-33824(IKE・9.8・認証不要RCE)=公開VPNがあれば本命 |
| ワーム化懸念 | CVE-2026-33827(TCP/IP・IPv6+IPsec) |
| 最優先対応 | 悪用確認1件+認証不要RCE+PoC公開を48時間以内 |
| 全体展開 | 残りのCritical・Importantを1週間以内 |
| 運用設計 | 5問の優先度フレーム+ゼロデイ別建てSLA+スパイク耐性のある月次サイクル |
163件という総数は威圧的だが、「悪用有無 → 公開有無 → 自社資産 → 露出 → 攻撃難易度」の順で絞れば、自社が今週当てるべきは数件に収束する。そして毎月の対応を都度の力技で乗り切るのではなく、資産台帳・別建てSLA・リング展開という“仕組み”に落とし込むことが、中小企業のパッチ管理を持続可能にする唯一の道だ。件数の乱高下(2月55件、4月163件、7月570件超)が示すのは、平均に合わせた体制ではなくスパイクに耐える体制を作れ、という一点である。
参考資料(一次情報・二次情報の別を明記)
一次情報(公式)
- Microsoft Security Response Center(MSRC)「Security Update Guide — April 2026」 https://msrc.microsoft.com/update-guide
- NIST National Vulnerability Database(各CVEの詳細・CVSS) https://nvd.nist.gov/
- JPCERT/CC「2026年4月 マイクロソフトセキュリティ更新プログラムに関する注意喚起」 https://www.jpcert.or.jp/
- IPA(情報処理推進機構)「脆弱性対策情報」 https://www.ipa.go.jp/security/
二次情報(ベンダー・専門メディア分析。件数のカウント方法により数値に差があるため相互に突き合わせて記載)
- Tenable Blog「Microsoft's April 2026 Patch Tuesday Addresses 163 CVEs(CVE-2026-32201)」
- Zero Day Initiative「The April 2026 Security Update Review」
- Sophos「Microsoft addresses 163 CVEs, 88 advisories for April Patch Tuesday」
- Krebs on Security「Patch Tuesday, April 2026 Edition」
※ 本記事の件数・深刻度・悪用状況は上記の公開時点情報に基づく。CVSS値・悪用状況は変動しうるため、対応判断時は必ずMSRCの最新情報を確認すること。「悪用確認済み」と「公開済み(PoC公開)」は意味が異なる点に留意。







