Microsoft 2026年8月更新、報道は394〜421件・公式データは790件｜件数の読み方

同じ月の同じ更新を報じて、媒体ごとに件数が違う。そして公式データを直接取ると790件だった。件数は「何を1件と数えたか」を伴わなければ、比較することも経営判断に使うこともできない。

2026年8月のMicrosoftセキュリティ更新について、複数のセキュリティ関連メディアがそれぞれ異なる件数を報じている。本稿執筆時点で確認できたものを、媒体名とともに挙げる。

**5つの数字はいずれも実在する。**一方で、**各媒体がどの範囲をどの時点で数えたかは、いずれの記事にも明示されていない。**したがって、どの数字が何を指しているのかを本稿から特定することはできない。

そこで、Microsoftが機械可読形式で提供している公式のCVRF（Common Vulnerability Reporting Framework）データを直接取得した。2026年8月分（文書名「August 2026 Security Updates」）に含まれる Vulnerability エントリは790件である。

最大で2倍の開きがある。

⚠️ **この開きが何によって生じたのかを、本稿は特定していない。**各媒体へ集計方法を確認したわけではないため、「数え方が違うだけ」とも「どれかが誤っている」とも断定しない。言えるのは、集計対象と取得時点が示されていない以上、これらの数字は互いに比較できないということである。

**本稿は、どの媒体の数字が正しいかを判定するものではない。**各媒体はそれぞれの集計方針の中で数えており、本稿が示せるのは「公式データを一次で取ると790件だった」という事実と、そのどちらの数字も、範囲の定義を伴わなければ社内の判断には使えないという点である。

本稿は個別の脆弱性の解説ではなく、毎月出てくるこの種の件数をどう扱うかを扱う。

この記事を読むべき人

• 毎月のセキュリティ更新の状況を経営層に報告している情報システム担当者
• 「今月は◯件も脆弱性が出た」という報告を受けて予算や人員を判断している経営者
• セキュリティ関連のニュースを社内共有しているが、対応の優先順位まで落とし込めていない会社
• ベンダーから「今月は大量の脆弱性が出ています」と言われて追加費用を提示された会社
• 脆弱性への対応体制を整えたいが、着手点が定まっていない会社

公式データを実際に数えるとどうなるか

MicrosoftはCVRF形式のデータをAPIで公開しており、月次の更新内容を機械可読な形で取得できる。2026年8月分を取得し、含まれる脆弱性エントリを深刻度別に集計した。

**ここで、集計そのものが本稿の主題を体現する結果になった。**同じデータから2通りの数字が出たのである。

CVRFでは、1つのCVEに深刻度の情報（Threat 要素）が複数ぶら下がることがあり、そのうち先頭の値が空になっている場合がある。どちらを採るかで内訳が変わる。

総数790は変わらないが、内訳は3か所ずれる。

**この表はMicrosoftが公式に発表した内訳ではない。**GXOが上記APIから取得したデータを、記載した2つの規則で集計したものである。再現するには、どのThreat要素を採用し、空欄をどう扱うかまで指定する必要がある。

そして、これがまさに本稿の論点である。**「深刻度別の内訳」という、一見客観的に見える数字ですら、集計規則を書かなければ再現できない。**自社で数えても、規則を書かなければ他人は同じ数字にたどり着けない。報道の件数についても、同じことが言えるはずである。ただし各媒体の規則は公開されていないため、確かめようがない。

なぜ数え方で倍近く変わるのか

件数がばらつく要因は、主に次の4つである。

要因1：深刻度でどこまで含めるか。 CriticalとImportantだけを数えるか、ModerateやLowも含めるかで、大きく変わる。上の表の規則Aで言えば、Critical＋Importantは504件、全体は790件である。

要因2：Microsoft以外が採番したCVEを含めるか。 MicrosoftのCVRF文書には、Chromiumベースの製品に関するものなど、他組織が採番し、Microsoftが自社製品の更新として取り込んだものも含まれ得る。これを「Microsoftが修正した脆弱性」に数えるかどうかで差が出る。

要因3：延長サポート（ESU）対象の製品を含めるか。 サポート期限を過ぎた製品向けの更新を別枠として扱う場合と、合算する場合がある。

要因4：再公開・更新されたエントリを含めるか。 過去に公表された脆弱性の情報が更新された場合、それを当月の件数に含めるかどうかで差が出る。

**以上は、件数に差が生じ得る要因として一般に考えられるものであり、今回の各媒体がどれに該当するかを示すものではない。**確認できるのは、記事の見出しに出るのは結果の数字だけで、集計方針は本文にも書かれていないという事実だけである。

件数を経営会議に持ち込むと何が起きるか

ここからが実務上の本題である。件数という指標を経営報告に使うと、次の3つの誤りが起きやすい。

誤り1：作業量の見積もりを誤る。 「790件」と聞けば、790回の作業が必要に見える。しかし実際には、1つの更新プログラムが多数のCVEをまとめて修正する。**適用作業の量を決めるのは、CVEの件数ではない。**主に効いてくるのは、適用すべき更新プログラムの数、対象となる端末・サーバの台数、対象製品とOSの種類、再起動の要否、事前検証の範囲、配布の方式、そして適用を見送る例外の扱いである。件数から作業量を推定することはできない。

誤り2：緊急度を誤る。 件数が多い月ほど危険という関係は成り立たない。**危険度を決めるのは件数ではなく、その中に「既に悪用されているもの」が何件あるかである。**2026年8月について言えば、後述のとおり、実際に悪用が確認されているものは限られている。

誤り3：予算要求の根拠が崩れる。 「今月は790件も出たので人を増やしたい」という説明は、次に件数の少ない月が来たときに反転する。**件数を根拠にすると、件数が減ったときに「じゃあ減らせるね」と返される。**セキュリティの体制は、件数の多寡ではなく、対応にかかる時間と、放置した場合の事業影響で説明する必要がある。

では何を見るべきか

件数の代わりに見るべき指標は3つある。

指標1：既に悪用が確認されているものが何件で、それは自社に該当するか。

2026年8月の更新に含まれるもののうち、米CISAのKnown Exploited Vulnerabilities（KEV）カタログに追加されたものとして、CVE-2026-68820がある。Windows の Ancillary Function Driver for WinSock（afd.sys）における解放済みメモリ使用（use-after-free）の脆弱性である。KEVカタログには2026年8月11日に追加され、是正期限は2026年8月25日とされている。

**790件のうち、KEVに載ったのはこの1件である。**この1件が自社環境に該当するかどうかが、今月の最初の判断になる。

指標2：自社が使っている製品に該当するものがあるか。

790件の大半は、自社が導入していない製品に関するものである。**まず必要なのは、自社の資産一覧と突き合わせて、該当する範囲に絞ることである。**この作業ができない状態——つまり資産一覧がない状態——では、何件出ようと判断のしようがない。件数の議論より先に、資産一覧の有無を確認するほうが実益が大きい。

指標3：公表から適用完了までに、自社は何日かかっているか。

これが体制の実力を最も端的に示す。先月の更新が、何日で全対象に適用され終わったか。この日数が測れていない会社は、今月の件数を議論しても改善につながらない。

今月の「1件」を自社に当てはめる手順

KEVに載った CVE-2026-68820 は、KEVカタログ上「Microsoft Windows Ancillary Function Driver for WinSock Use-After-Free Vulnerability」として登録されている。AFD（Ancillary Function Driver for WinSock）は、Windows上のアプリケーションがネットワーク通信を行う際に介在するカーネル側の構成要素である。

ここで押さえたいのは、これがサーバ専用の話ではなく、Windowsが動いている端末全般に関わる話だという点である。

多くの会社の資産一覧は、サーバとネットワーク機器までは書かれていて、**従業員が使っているノートPCが抜けている。**あるいは台数だけがあって、OSのバージョンや更新の適用状況が紐づいていない。この状態だと、今月の1件について「自社は該当するか」に答えられない。答えられないまま「790件も出た」という報告だけが上がる。

該当判定の手順は、実務上は次の3ステップになる。

**ステップ1：対象となるWindowsのバージョンと構成を、Microsoftのアドバイザリで確認する。**ここは要約記事ではなく一次で確認する。

**ステップ2：自社にそのバージョンの端末・サーバが何台あるかを出す。**資産管理の仕組みがあれば数分、なければここで止まる。止まった場合、それが今月の最大の課題である。

**ステップ3：適用済みと未適用を分け、未適用の台数と、その端末を誰が使っているかを出す。**社外に持ち出す端末が未適用のまま残っているかどうかで、優先度が変わる。

**この3ステップのどこで止まったかが、そのまま次に投資すべき箇所を示す。**ステップ2で止まるなら資産管理、ステップ3で止まるなら更新の配布・適用状況の可視化である。件数の議論からは、この示唆は出てこない。

日本の公的機関も同日に注意喚起を出している

海外メディアの件数を追う前に、日本の公的機関の発信を確認するほうが実務的である。

IPA（情報処理推進機構）は2026年8月12日に「Microsoft 製品の脆弱性対策について（2026年8月）」を公開している。IPAの重要なセキュリティ情報のうち、深刻度が「緊急」の区分で扱われている。

JPCERT/CC も同じ2026年8月12日に「2026年8月マイクロソフトセキュリティ更新プログラムに関する注意喚起」を公開している。

**この2つは、日本語で、日本の利用環境を前提に書かれている。**海外メディアの記事より情報の速度はわずかに遅いが、**社内共有の材料としては、こちらのほうが誤解が生じにくい。**特に、経営層への報告資料に引用する場合、出典が公的機関であることの意味は小さくない。

経営への報告を1枚にする

件数を並べる代わりに、次の5行で報告するほうが判断につながる。

**1行目：今月の更新のうち、自社が使っている製品に該当するものは何件か。**790件ではなく、自社に関係する件数を出す。

**2行目：そのうち、既に悪用が確認されているものは何件か。**2026年8月であれば、KEV収載の1件が自社に該当するかどうか。

**3行目：適用が完了した対象と、残っている対象。**台数ベースで示す。

**4行目：残っている対象について、いつまでに完了させるか。**期日を明示する。

5行目：期日までに完了できない場合、その間に取っている代替措置。

**この5行に「790件」という数字は登場しない。**登場する必要がない。経営が判断すべきは、残作業と期日と、間に合わない場合の措置だからである。

よくある質問

Q. 報道の件数が違うのは、どれかが間違っているということか。 A. そうとは限らない。**深刻度の範囲、他組織採番のCVEの扱い、延長サポート対象の扱い、再公開分の扱いという4つの条件のいずれかが違えば、集計結果は変わる。**どの記事も、自社の集計方針の中では正しい可能性がある。問題は方針が明示されないことにある。

Q. 公式データはどこで確認できるか。 A. MicrosoftはCVRF形式のデータをAPIで公開しており、月次で取得できる。本稿末尾に取得先を記載している。ブラウザで見る更新ガイドの画面は動的に生成されるため、件数を機械的に数える用途にはAPIのほうが適している。

Q. 790件のうち、実際に対応が必要なのは何件か。 A. 会社によって異なる。判断の基点は自社の資産一覧である。Windows端末とOfficeしか使っていない会社と、Azure上に複数のサービスを構築している会社では、該当範囲がまったく違う。「一般的に何件」という答えは存在しない。

Q. 資産一覧がない。まず何をすればよいか。 A. 完璧な一覧を目指す必要はない。**インターネットに面しているもの、業務が止まると困るもの、この2つに該当する資産だけを先に洗い出す。**これだけでも、毎月の更新情報を自社に関係するかどうかで振り分けられるようになる。

Q. ベンダーから「今月は脆弱性が大量に出たので追加作業が必要」と言われた。妥当か。 A. 件数だけを根拠にした説明であれば、確認したい点がある。**自社の資産のうち何台が対象で、更新プログラムはいくつで、作業時間の内訳はどうなっているか。**CVEの件数と作業量は比例しない。内訳の説明を求めることは、値切りではなく、正しい見積もりを得るための手順である。

Q. 毎月の更新をすべて適用するのは現実的ではない。どう絞るか。 A. 絞る基準を先に決めておく。実務で機能しやすいのは、インターネットからの到達性、悪用の確認有無、回避策の有無の3つを掛け合わせる形である。この基準を平時に文書化しておくと、毎月ゼロから議論せずに済む。

Q. KEVに載った1件だけ対応すればよいのか。 A. そうではない。**KEV収載は「今すぐ対応すべきもの」の目印であって、「これ以外は対応不要」という意味ではない。**残りは自社の基準に沿って計画的に適用していく対象になる。優先順位を付けることと、対象から外すことは違う。

Q. 経営層が件数の多さを気にして落ち着かない。どう説明するか。 A. 件数は自社と無関係な製品を大量に含んでいることを説明し、**自社に該当する件数と、そのうち悪用確認済みの件数に置き換えて示すのが早い。**数字を否定するのではなく、意味のある数字に差し替える。

脆弱性対応の基準づくりから相談したいとき

毎月の更新情報に振り回されている状態は、情報が多いことが原因ではなく、**自社に関係するかどうかを判定する仕組みがないことが原因である。**資産一覧と判定基準の2つが揃うと、月次の作業は大幅に軽くなる。

自社にどれだけの資産があり、そのうち何が外部に開いているのか。ここの把握から着手したい場合は自社資産の把握状況を確認するで対応している。毎月の情報の取捨選択と優先順位付けを社内で抱えきれない場合は、脆弱性情報の判定を外部に持たせるで外部に持たせる形も選択肢になる。

提示された脆弱性対応の見積もりや作業内容が妥当かどうか、社外の目で内訳を確認したい場合は脆弱性対応の見積もり内容を相談するで受け付けている。情報システムの体制そのものを整理したい段階であれば、情報システム体制の現在地を確認するで現在地の確認から始められる。

なお、悪用が確認された案件をどの順序で片付けるかという社内基準の作り方は、CISA BOD 26-04を日本企業向けに読むで別に扱っている。今月に限れば、期限の面で切迫しているのはCisco ASA/FTDのVPN脆弱性のほうである。こちらは是正期限が本日に設定されている。本稿は件数の読み方に絞っている。

参照した情報

• Microsoft Security Update Guide CVRF API（2026年8月分）: https://api.msrc.microsoft.com/cvrf/v3.0/cvrf/2026-Aug
• Microsoft Security Update Guide リリースノート（2026年8月）: https://msrc.microsoft.com/update-guide/releaseNote/2026-Aug
• IPA 重要なセキュリティ情報一覧: https://www.ipa.go.jp/security/security-alert/2026/index.html
• JPCERT/CC: https://www.jpcert.or.jp/
• CISA Known Exploited Vulnerabilities Catalog（JSON配信）: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json

文書名「August 2026 Security Updates」および Vulnerability エントリ790件は、上記CVRF APIから2026年8月14日に取得したデータに基づく。

本文の深刻度別内訳は、Microsoftが公式に発表した内訳表ではない。GXOが同データを次の2つの規則で集計したものである。規則A＝各CVEの Threat 要素のうち Type が3であるものの先頭の値を採用（Critical 110／Important 394／Moderate 206／Low 32／値が空48）。規則B＝同じく Type が3のもののうち空でない最初の値を採用（Critical 110／Important 395／Moderate 207／Low 32／値が空46）。**総数790は両規則で一致する。**取得時点のデータに基づくものであり、後日エントリが追加・更新された場合は数値が変わり得る。

本文の表に掲げた5件の出典は次のとおりである。**いずれも2026年8月11日のセキュリティ更新（同日公開）を扱った記事であり、本稿では2026年8月14日に各記事を取得して件数を確認した。**各記事の公開日時は媒体側の表示に従う。

• Cyber Security News（394件）: https://cybersecuritynews.com/microsoft-patch-tuesday-update-august-2026/
• The Hacker News（398件）: https://thehackernews.com/2026/08/microsoft-patches-398-flaws-including.html
• BleepingComputer（400件）: https://www.bleepingcomputer.com/news/microsoft/microsoft-august-2026-patch-tuesday-fixes-400-flaws-3-zero-days/
• CrowdStrike（415件）: https://www.crowdstrike.com/en-us/blog/patch-tuesday-analysis-august-2026/
• SecurityWeek（421件）: https://www.securityweek.com/august-2026-patch-tuesday-microsoft-fixes-421-cves-one-exploited-zero-day/

**5件の数字はいずれも実在することを確認したが、各社がどの集計条件を採用したかはいずれの記事にも明示されていない。**したがって本稿では、特定の数字と特定の集計条件の対応関係を断定しておらず、どの数字が正しいかの判定も行っていない。

CVE-2026-68820のKEVカタログへの追加日（2026年8月11日）および是正期限（2026年8月25日）については、KEVカタログのJSON配信（カタログバージョン2026.08.11）に記載された値を用いている。IPAおよびJPCERT/CCが2026年8月12日に注意喚起を公開している旨は、それぞれの公式サイトの掲載に基づく。

件数がばらつく4つの要因、経営報告の5行、見るべき3指標、および該当判定の3ステップは、GXOが報告実務の観点で組み立てたものであって、Microsoft・IPA・JPCERT/CCが示した基準ではない。個別の脆弱性の技術的詳細、修正プログラムの適用手順、および自社環境における該当判定については、本稿では扱っていない。