結論:今週は「全社員のPCに入っているソフト」の更新が4つ重なった。個人任せにせず、期限を切って一斉にやる
2026年6月第2週は、ほぼすべての企業PCに入っているソフトウェアの重要更新が4つ同時に走る、年に数回の「当たり週」だ。Windows月例パッチ(史上最多規模の修正)、Chrome(悪用済みゼロデイCVE-2026-11645)、Adobe Acrobat/Reader(APSB26-63・JPCERT注意喚起)、Zoomモバイル(ZSB-26010)——どれも対象は「一部のサーバー」ではなく「全社員の手元」である。
このうちChromeのCVE-2026-11645は実際に悪用が確認され、米CISAの悪用確認カタログ(KEV)に登録済みだ。細工されたWebページを開くだけで攻撃が成立し得るブラウザの穴であり、更新を個人任せにしている会社は、未更新の台数分だけ被害確率を抱え込む。
必要なのは高度な技術ではなく、「何を・いつまでに・誰が確認するか」を決めて全社に流す段取りだ。本記事はそのまま社内展開できるチェックリストとして使えるよう構成した。情シス1人、あるいは総務兼任の体制でも今週中に回し切れる。
押さえるべき1点:4つのうち優先度が最も高いのは「悪用済み」のChromeだ。悪用が確認されている脆弱性を最優先で塞ぐ——この原則だけは体制の大小にかかわらず変わらない。
今週の更新4点セット:対象と確認方法
| 対象 | 内容 | 確認・更新方法 |
|---|---|---|
| Windows | 6月の月例更新。史上最多規模の修正に加えBitLocker迂回のゼロデイを含む(解説記事) | 設定→Windows Update。WSUS/Intune配信の組織は配信状況を確認 |
| Chrome | CVE-2026-11645(V8の境界外読み書き・悪用確認済み・CISA KEV登録)。修正版149.0.7827.102/.103以降(解説記事) | アドレスバーに chrome://settings/help →自動更新→再起動 |
| Adobe Acrobat/Reader | APSB26-63。細工されたファイルにより任意コード実行のおそれ。JPCERTが注意喚起(AT-2026-0018) | ヘルプ→アップデートの有無をチェック。修正版はContinuous 26.001.21662/2024 Classic 24.001.30383 |
| Zoom | ZSB-26010(Workplaceモバイルクライアント・CVE-2026-53407/53408・CVSS 8.1)ほかZSB-26009 | アプリストアまたはクライアント内更新で最新版へ |
Chromeは6月8日の更新後、同じ週に2度目の更新も配信されており、「今週は1回更新したから終わり」と判断しないことが重要だ。バージョン確認は必ず実機の表示で行う。
Zoomの2件はモバイルクライアントが対象に含まれる点が見落としやすい。会社支給スマホはもちろん、私物端末の業務利用(BYOD)を認めている組織では、管理外の端末にも更新が必要になる。MDMで更新状態を可視化できていない組織は、この機会に体制を見直すとよい(MDM/BYOD管理ガイド参照)。
なぜ「個人任せ」が危ないのか
ブラウザもPDFリーダーもWeb会議アプリも自動更新機能を持つ。それでも個人任せが危ない理由は明確だ。
- 再起動されない:Chromeの更新はダウンロードされても、再起動するまで適用されない。何週間もブラウザを開きっぱなしの社員のPCは、更新済みに見えて未適用のままだ
- 保留される:「会議前だから後で」が積み重なり、未適用期間が伸びる。悪用済み脆弱性ではこの期間がそのままリスクになる
- 確認されない:適用率を誰も測っていなければ、「たぶん大丈夫」のまま放置される。攻撃者は未更新の1台を探せばよい
つまり問題はツールではなく運用だ。「全社一斉更新」を業務として指示し、期限と確認方法をセットで示すことが、コストゼロでできる最大の対策である。
全社一斉更新の実施チェックリスト(6ステップ)
そのまま社内アナウンスに転用できる形で示す。
- 対象の確定:今週の更新対象を4点(Windows/Chrome/Acrobat・Reader/Zoom)と明示する。会社支給PC・スマホに加え、BYOD端末のZoom・Chromeも対象に含める
- 期限の設定:悪用済みのChromeは即日〜24時間以内、残り3点は今週末までなど、優先度に応じた期限を切る。CISAは連邦機関にCVE-2026-11645の対処期限を6月23日と設定しているが、悪用済みである以上、民間でも前倒しが妥当だ
- 手順の配布:各ソフトの更新手順(上表)を1枚にまとめて配る。「chrome://settings/help を開いて再起動」のように、迷わないレベルまで具体化する
- 再起動の徹底:「更新したら必ず再起動(Chromeはブラウザ再起動、WindowsはOS再起動)」を明記する。ここが最も漏れる
- 適用確認:管理ツール(Intune/WSUS/資産管理)があれば適用率をレポートで確認する。なければ各部門長経由で「完了報告」を集める。完了報告の様式(バージョン番号を書かせる)まで指定すると精度が上がる
- 例外の管理:業務都合で更新できない端末は、理由・代替策・適用予定日を記録して放置しない。「例外リストが存在し、期限がある」状態を保つ
チェックの勘所:5の「適用確認」を省くと、このチェックリストは単なるお願いメールになる。確認手段が何もない組織は、まず資産管理・MDMの導入を検討事項に乗せるべきだ。今回のような「当たり週」は今後も必ず来る。
よくある質問(FAQ)
Q. 自動更新を有効にしているので、何もしなくてよいのではないか? A. 不十分である。自動更新はダウンロードまでで、適用には再起動が必要なものが多い。特にChromeのCVE-2026-11645は悪用済みであり、「いずれ適用される」では遅い。今回のような週は、再起動まで含めた一斉実施を業務として指示すべきだ。
Q. 4つ全部は手が回らない。どれを優先すべきか? A. 第一にChrome(悪用済み・KEV登録)、第二にWindows月例(ゼロデイ含む)、その後にAcrobatとZoomの順を推奨する。ただしAcrobatは「PDFを開くだけ」で攻撃が成立し得る種類の脆弱性であり、取引先からのファイル受領が多い職種(経理・営業・人事)では実質的な露出が大きい。1週間以内に4点すべて完了が目標だ。
Q. 更新の適用状況を確認する仕組みが社内にない。どうすべきか? A. 今週はまず部門長経由の完了報告で代替し、並行して資産管理ツールまたはMDMの導入を検討すべきだ。端末の更新状態を一覧できない状態は、今回のような一斉更新のたびに人手のコストを生み、漏れも残る。体制の選び方はMDM/BYOD管理ガイドにまとめている。
社内で今日確認する実務チェック
この記事のテーマを自社に当てはめるときは、次の順で確認する。第一に、対象製品・対象バージョン・対象サービスが資産台帳に載っているか。第二に、インターネットや不要な社内セグメントから到達できないか。第三に、更新・緩和・監視の担当者と期限が明確か。第四に、委託先やクラウド運用先が関係する場合、回答を口頭ではなくチケットやメールで記録しているか。第五に、対応後にバージョン・設定・ログで完了を確認したかである。
脆弱性対応で最も危険なのは、「使っているか分からない」「担当が分からない」「ベンダーに任せているはず」という状態だ。今回の記事を読んだ時点で対象有無を即答できないなら、それ自体が改善テーマである。個別のパッチ適用だけでなく、資産台帳、脆弱性通知の受信経路、緊急対応の承認権限まで点検したい。
GXOへ相談する前に整理しておくと早い情報
相談前には、対象製品名、バージョン、設置場所、外部公開の有無、管理者、保守契約、更新可能な時間帯、過去の障害履歴を分かる範囲でまとめる。すべて揃っていなくてもよいが、「分からない項目」が多いほど、最初の支援はパッチ作業ではなく棚卸しと露出確認から始めるべきである。
30日で整える脆弱性対応ロードマップ
初日から3日目までは、対象有無の確認と暫定緩和に集中する。資産台帳、EDR/MDM、クラウド管理画面、保守ベンダーへの照会を使って、対象製品がどこにあるかを洗い出す。対象が見つかった場合は、外部公開の停止、アクセス制限、管理画面のIP制限、監視強化など、更新前にできる緩和策を先に入れる。
4日目から10日目までは、更新・設定変更・影響確認を進める。業務影響が大きい製品では、検証環境で更新手順を確認し、失敗時の切り戻し手順を用意する。更新後はバージョン表示だけでなく、実際に脆弱な経路が閉じているか、ログに不審なアクセスが残っていないかを確認する。
11日目から30日目までは、再発防止に使う。通知を誰が受けるか、KEVやJPCERT/CCなどの情報をどう優先度付けするか、休日・夜間の緊急判断を誰が承認するかを決める。今回のような高リスク通知に対して、次回は「対象有無を24時間以内に答えられる」状態を目標にする。
よくある失敗パターン
第一の失敗は、CVE番号やCVSSだけを見て、対象資産の有無を確認しないことだ。スコアが高くても自社に対象がなければ対応は不要であり、逆にスコアが中程度でもKEV登録や悪用確認があれば最優先になる。優先順位は、CVSS、悪用状況、外部公開、権限条件、業務影響を組み合わせて決める。
第二の失敗は、更新完了を「ベンダーに依頼した」で止めることだ。更新後のバージョン確認、到達制限、ログ確認、再起動状態、冗長系への反映まで確認しなければ完了とは言えない。特にアプライアンスや管理基盤では、片系だけ更新されてもう片系が古いまま残ることがある。
第三の失敗は、今回だけの緊急対応で終わることだ。脆弱性情報は毎月出る。対応のたびに担当者探しから始まる組織は、次回も同じ遅れを繰り返す。今回の対応記録を使い、対象確認テンプレート、判断フロー、連絡先一覧、夜間休日の承認ルールまで更新することが重要である。
成果物として残すべきもの
公開記事を読んで終わらせず、社内には少なくとも4つの成果物を残したい。対象有無確認表、対応判断メモ、更新・緩和作業の証跡、再発防止タスクである。これらが残っていれば、監査や事故後説明でも「いつ、誰が、何を根拠に判断したか」を示せる。
また、委託先が関係する場合は、委託先回答をそのまま保存するだけでなく、自社として受け入れた判断も記録する。セキュリティ運用では、作業を委託できても説明責任は委託できない。
いつGXOに相談すべきか
- 情シスが1人または不在で、月例・緊急パッチの運用が回っていない
- 端末の更新状態を一覧で確認できる仕組み(資産管理・MDM)がなく、整備したい
- 今回のような緊急対応を外部の専門家に随時相談できる体制を持ちたい
GXOはセキュリティ診断でエンドポイント管理を含む自社の守りの現状評価を、セキュリティ顧問で月例・緊急パッチ運用の定常化と随時相談を提供している。→ パッチ運用・エンドポイント管理の相談はこちら
関連記事
- Windows月例パッチ史上最多200件|BitLocker迂回ゼロデイ2件
- Chrome今年5件目のゼロデイCVE-2026-11645がKEV登録|全社ブラウザ更新の進め方
- MDM/BYOD管理ガイド|Intune・Jamf・CLOMO比較と中小企業のデバイス管理戦略
- Check Point VPNに認証バイパス、悪用継続中
参考資料
- JPCERT/CC「Adobe AcrobatおよびReaderの脆弱性(APSB26-63)に関する注意喚起(AT-2026-0018)」(2026年6月10日)
- Zoom「Security Bulletin ZSB-26010/ZSB-26009」(2026年6月9日)
- Google「Chrome Releases: Stable Channel Update for Desktop」
- CISA「Known Exploited Vulnerabilities Catalog」
- Help Net Security「Google patches Chrome zero-day exploited in the wild (CVE-2026-11645)」(二次情報)
- Security NEXT「Zoom、「Workplace」モバイルアプリなどの脆弱性を解消」(二次情報)
本記事は2026年6月12日時点の公開情報をもとに作成。修正版のバージョン番号・対処期限は更新される可能性があるため、各ベンダーおよびJPCERT/CC・CISAの一次情報の最新版を必ず確認すること。
「全社のPC、更新されているか」を一覧で答えられる体制がありますか
月例・緊急パッチの運用設計、資産管理・MDMによる適用状況の可視化、緊急時の優先順位判断まで、情シス1人の体制でも回るパッチ運用の構築を支援します。
※ 営業電話はしません | オンライン対応可 | 今週の緊急対応の相談にも応じます