Windows

Microsoftは2026年7月のWindowsセキュリティ更新プログラムで、Active DirectoryドメインコントローラーがKerberos認証において脆弱な暗号方式RC4を許容する「Auditモード」を完全に廃止した。これにより、情報漏えいの脆弱性CVE-2026-20833への対応は最終段階である「強制適用フェーズ」に入り、サービスチケットの発行はAESベースの暗号化が事実上必須となる。 Auditモードとロールバック設定の消滅 Kerberos認証では、ドメインコントローラー上のKDC(Key Distribution Center)がサービスチケットを発行する際、伝統的にRC4-HMACとAES(128/256)の両方の暗号方式に対応してきた。しかしRC4はパスワードハッシュから直接鍵を導出する古い方式で、オフラインでの解析(いわゆるKerberoasting)に対する耐性が低い。 Microsoftはこの弱点を段階的に締め出すため、これまで「Auditモードでまず影響を可視化し、問題があればレジストリキー(RC4DefaultDisablementPhase)でロールバックできる」という猶予期間を設けてきた。今回の7月更新ではこのAuditモードとロールバック設定そのものが削除され、Enforcementモードのみが残る。RC4をどうしても使わざるを得ない場合は明示的な設定変更で維持できるが、その構成はCVE-2026-20833に対して脆弱なままになる。 影響を受けやすい環境 影響が出やすいのは、レガシーな業務アプリケーション、Windows以外のKerberos実装(Linux/Unix系サーバーやネットワーク機器、複合機など)で、RC4を明示的に指定しているケースだ。これまでAuditモードで警告が出ていても放置していた環境は、7月更新の適用と同時にサービスチケット要求が失敗し、認証エラーとして表面化する。 実務への影響 日本企業の多くは長年運用されてきたActive Directory環境に、更新が止まった古いアプライアンスや自社開発の基幹システムを抱えている。今回のように「猶予期間そのものがなくなる」変更は、こうした資産ほど直撃しやすい。 対応の勘所は3つ。まず、セキュリティイベントログのイベントID 4769(Kerberosサービスチケット要求)を確認し、Ticket Encryption Typeフィールドが0x17(RC4-HMAC)になっているアカウントを洗い出すこと。次に、それらのサービスアカウントやアプリケーションがAESに対応できるか個別に検証すること。最後に、本番環境へのパッチ適用前に、検証環境で非Windows実装との相互運用性を必ず確認することだ。ロールバックの逃げ道が消えた以上、事前検証の重要性は格段に上がっている。 筆者の見解 RC4の締め出しという方向性自体は、Windowsのセキュリティ強化施策の中でも一貫して正しい判断だと思う。Smart App Controlやカーネルドライバーの締め出しと同じで、地味だが効く改善だ。サービスアカウントという「人間ではないID(Non-Human Identity)」が、パスワード管理も棚卸しもされないまま何年も同じ暗号設定で動き続けているケースは、ゼロトラストの観点から見ても最大級のリスクだ。「今動いているから触らない」という発想が一番危ない、というのはSID重複問題などでも繰り返し学んできたはずの教訓のはずだ。 ただ、応援する立場から一つ苦言を呈するなら、Auditモードという猶予期間が長く続いたことが、逆に「そのうちまた延期されるだろう」という油断を組織側に生んでしまった面は否めない。せっかく何年もかけて移行期間を用意したのだから、棚卸しが済んでいないアカウントを事前に可視化し、管理者に直接アラートを送るような支援ツールをもっと手厚く用意してほしかった。正面から勝負できるだけの技術力と影響力を持っているのだから、移行の「最後の一押し」こそ丁寧にやってほしいところだ。 出典: この記事は Enforcement phase for Kerberos RC4 protections begins with the July 2026 Windows security update の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft(マイクロソフト)は2026年7月8日、月例セキュリティ更新「Patch Tuesday」で過去最多となる569件のCVE(共通脆弱性識別子)を公開した。この中でも仮想化基盤の運用担当者が特に注意すべきなのが、Hyper-VのVMSwitchコンポーネントに存在するUse-After-Free(解放後使用)型の脆弱性「CVE-2026-57092」だ。 VMSwitchのUse-After-Freeが招く権限昇格リスク VMSwitchはHyper-V環境で仮想マシン(VM)間、およびVMとホスト間のネットワーク通信を仲介する中核コンポーネントだ。Use-After-Freeは、解放済みのメモリ領域への参照が残ったまま使い続けてしまうバグで、攻撃者がそのタイミングを制御できると、解放された領域に任意のデータを送り込んで実行フローを乗っ取ることができる。 CVE-2026-57092の場合、ゲストOS内で低い権限しか持たない攻撃者が、このバグを突いてホスト側で権限を昇格させられる可能性がある。マルチテナントで複数の顧客のVMを同じHyper-Vホスト上に同居させているクラウド事業者やホスティング事業者にとっては、「VMの中は隔離されているはず」という前提そのものが崩れる、影響度の大きい脆弱性だ。 570件近い脆弱性の陰で見過ごされやすい 今回のPatch Tuesdayは569件中56件がCritical(緊急)、510件がImportant(重要)と、6月の198件を大きく上回る過去最大規模になった。Microsoftは事前に、脆弱性の発見を高速化する「MDASH(multi-model agentic scanning harness)」という複数AIモデルによるエージェント型スキャン基盤の運用を開始したと発表しており、「今後のセキュリティリリースでは更新件数がさらに増える」と予告していた。今回の記録的な件数は、その予告通りの結果と言える。 これだけの件数が一度に公開されると、個々の脆弱性の技術的な深刻度が埋もれてしまいがちだ。CVE-2026-57092のようにハイパーバイザーの権限境界に関わる脆弱性は、件数の多さに紛れて見落とされないよう、優先度を上げて確認する必要がある。 実務への影響 Hyper-Vは単体のWindows Serverだけでなく、Azure Stack HCIやAzure Local、S2D(Storage Spaces Direct)クラスタなど、日本企業のオンプレミス仮想化基盤でも広く使われている。VM内からホストへの権限昇格が可能になれば、同一ホスト上の他社・他部門のVMへの横展開や、ホスト管理者権限の窃取につながりかねない。 実務担当者は以下を優先して対応したい。 Hyper-Vホストの棚卸しと、VMSwitch関連パッチの適用状況の即時確認 マルチテナント環境(ホスティング事業者・社内共用基盤)では優先度を最高に設定 パッチ適用前にステージング環境での動作確認を行いつつも、権限昇格系の重大CVEは「様子見」の対象から外し、迅速に適用する Hyper-Vホストへのアクセス権をJust-In-Timeで付与し、常時付与された管理者権限を持つアカウントを洗い出す 筆者の見解 Windows個別の機能追加を逐一追う優先度は下がっている一方、こうしたハイパーバイザーレベルの脆弱性は話が別だ。仮想化基盤はネットワーク層・認証層・認可層という多層防御の一番土台にあたる部分であり、ここが崩れると上に積んだゼロトラストの仕組みも意味をなさなくなる。VM間分離を過信せず、ホストへのアクセス権をJust-In-Timeで最小化しておくことが、こうした脆弱性が出た際の実害を左右する。 569件という数字自体は驚くが、MicrosoftがAIエージェントによるスキャン基盤(MDASH)で脆弱性発見を加速させたと公表している点は素直に評価したい。指摘される脆弱性が増えるのは短期的には運用負荷の増加に見えるが、見つからずに放置されるより遥かにましだ。あとは、これだけの件数を運用現場が実際に検証・適用しきれるかという別の課題が残る。件数を増やす仕組みを作ったなら、優先度付けや影響範囲の可視化までセットで提供してほしい。そこまでやり切ってこそ、AIを使った脆弱性発見の取り組みが本当に現場の役に立つ。 出典: この記事は Use-After-Free vulnerability CVE-2026-57092 in Hyper-V’s VMSwitch (Microsoft’s July 2026 Patch Tuesday) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Outlook Classic（旧来のデスクトップ版Outlook）を含む全バージョンのOutlookに、Copilotを使った「メール下書き作成」機能を強制的に有効化すると発表した。管理ポータルの告知によれば、対象はOutlook Classic、New Outlook、Web版、モバイル版のすべてで、2026年末までにOutlook Classicへの展開が完了する見込みだ。機能を使いたくないユーザーは、自らオプトアウトするか、有効化後に手動で無効にする必要がある。 Outlook Classicにも年内展開 New Outlookでは既に展開が始まっているか、数週間以内に届く見込み。一方Outlook Classicは、機能追加がほぼ止まりバグ修正中心になっていたにもかかわらず、Copilot搭載のコンポーズボックスが年末までに既定でオンになる。管理者側の作業は不要で、ユーザーは新規メール作成や下書き編集の際、コンポーズボックス内からCopilotを呼び出し、文章の書き直しや拡張ができるようになる。 なお、この新しいCopilot搭載コンポーズ機能はMicrosoft 365 Copilotライセンスを必要とし、通常のMicrosoft 365サブスクリプションより高額だ。そしてMicrosoftの新しい料金ページは、Microsoft 365 Copilotライセンスを新標準として前面に押し出しており、Copilotなしの従来サブスクリプションを見つけにくくしている。既にMicrosoft 365 Copilotへアップグレード済みの組織では、この機能は自動的にオンになる。 なお政府機関向け環境(GCC High・DoD)では、New Outlookが9月からロールアウトされるが、Outlook Classicの強制置き換えは行わず、既定オフ・オプトインのまま管理者がポリシーとレジストリキーで制御できる状態が維持される。同時にMicrosoftは、添付ファイルと紛らわしいと不評だった「Meeting Insights」機能を廃止し、Copilotによる要約に置き換える方針も明らかにしている。 実務への影響 日本企業の多くは、COMアドインやVBAマクロとの互換性、あるいは単に慣れの問題からOutlook Classicを使い続けている。今回の変更は「機能追加」ではなく「既定オン」という形で来るため、IT管理者は年末までにグループポリシーまたはCloud Policyサービスで、Copilotコンポーズ機能の可否をあらかじめ決めておく必要がある。特にMicrosoft 365 Copilotライセンスを持たない組織では機能自体が表示されないはずだが、ライセンス保有ユーザーが混在する環境では、意図せず一部の社員だけに機能が現れる状況も想定される。情報漏洩や誤送信のリスクを避けるためにも、展開前の周知と、必要なら無効化の手順書を準備しておきたい。またNew Outlookへの移行計画がある組織は、この機会にCOMアドインからWebアドインへの移行スケジュールを見直す好機でもある。 筆者の見解 Copilotの企業向け展開はここ数年、機能の中身よりも「どう既定値を動かすか」で語られることが多くなっている。今回も、Outlook Classicの新機能追加をほぼ止めておきながら、Copilotだけは強制的に既定オンにするという判断には違和感がある。しかも料金ページでCopilotライセンスをさりげなく標準扱いにする見せ方は、応援する立場から見ても正直あまり褒められたやり方ではない。ユーザーが自分の意思で選べる余地をきちんと残してこそ、Copilotは「使われる機能」になっていくはずだ。 メールの下書き支援そのものは使いどころが分かりやすく、素直に実用性を評価しやすい機能だと思う。だからこそ、既定オンで押し付けるのではなく、管理者にもエンドユーザーにも透明性のある形で選ばせてほしい。正面から評価されるだけの実力を伸ばせる領域のはずなので、こうした細かい見せ方でユーザーの不信を買うのはもったいない。 出典: この記事は Microsoft to force enable Copilot in Outlook Classic, even though it wants you on New Outlook の内容をもとに、筆者の見解を加えて独自に執筆したものです。

セキュリティ研究者「Nightmare Eclipse」（別名Chaotic Eclipse）が2026年7月16日、Microsoft Windowsの未修正の権限昇格脆弱性「LegacyHive」の実証コード（PoC）を公開した。Windowsのユーザープロファイル管理を担う「User Profile Service」に存在する欠陥で、管理者を含む他ユーザーのレジストリハイブを読み込めてしまう。公開のタイミングは2026年7月のPatch Tuesday直後だった。Microsoftは本記事の取材に対し「報告された脆弱性を認識しており、有効性と影響範囲を調査中」とコメントしている。 LegacyHiveの仕組み User Profile Serviceは、ユーザーのサインイン時に個々のレジストリハイブ（NTUSER.DATやUsrClass.datなど）をロードする役割を持つ。LegacyHiveは、この読み込み処理の権限チェックに不備があり、標準ユーザー権限のプロセスから他ユーザーのハイブ（管理者アカウントのものを含む）をマウントできてしまう。 興味深いのは、今回のPoCが「あえて弱体化」されている点だ。研究者自身の説明によれば、元の欠陥は認証情報なしで任意のハイブを読み込めたが、公開版では「別の標準ユーザーの認証情報」と「対象ユーザー名（管理者アカウントでも可）」を要求するよう制限を加えている。任意ハイブの読み込みは依然として可能だが、悪用にはひと手間必要になるよう調整したという。過去にNightmare Eclipseが公開したBlueHammer、RedSun、UnDefend（いずれも実際の攻撃で悪用済み）、GreenPlasma、RoguePlanet、YellowKey、GreatXMLと合わせると、Microsoft製品を狙ったゼロデイ公開はすでに7件を超える。 実務への影響 LegacyHiveはリモートから直接侵入できる脆弱性ではなく、あくまで「すでに端末上で標準ユーザー権限を得ている攻撃者」が管理者権限に昇格するためのものだ。つまりフィッシングや別の初期侵入手段とセットで使われて初めて脅威になる。パッチが未提供の現状、IT管理者は以下を優先したい。 EDR/XDRでUser Profile Service周りの異常なレジストリハイブ操作を検知対象に追加する ローカル管理者権限の常時付与を洗い出し、Just-In-Time（JIT）昇格に切り替える 共有端末・VDI環境ではプロファイル分離設定を再確認する Microsoftからの正式パッチ公開後は速やかに適用しつつ、まず数日程度は不具合報告がないか様子を見る判断も選択肢に入れる 筆者の見解 正直に言うと、セキュリティの脆弱性情報を一件一件細かく追いかけるのはあまり得意な方ではない。ただ、こうした特権昇格の欠陥がどこで起きているかには技術的にとても興味がある。今回のLegacyHiveも本質は「常時付与された高い権限が、想定外の経路で奪われる」という話で、これはゼロトラストの文脈でずっと言い続けている「常時アクセス権の付与こそが特権アカウント管理における最大のリスク」という原則そのものだ。ローカル環境であっても、管理者権限を常時持たせず、必要な時だけJITで昇格させる仕組みにしていれば、この種のバグの実害はぐっと小さくなる。 Microsoftを応援する立場から率直に言えば、同じ研究者から立て続けにゼロデイを公開され続けている状況はもったいない。OSの根幹であるプロファイル管理・ハイブ読み込みまわりの権限モデルは、そろそろ抜本的に見直す価値があるはずだ。ここを正面から作り直せる技術力があるのはMicrosoft自身がいちばんよく分かっているだろうし、今回のような報告が積み重なるほど、腰を据えた見直しへの期待も強くなる。 出典: この記事は Nightmare Eclipse Drops ‘LegacyHive’ Windows Zero-Day の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは7月上旬、Windows 11 Insiderプログラムのビルドに複数の新機能を投入した。中でも注目は、起動不能に陥ったPCをUSBメディアなしで完全復元できる「Cloud Rebuild（クラウドリビルド）」だ。故障したPCがWindows Updateのサーバーから直接OSイメージとドライバーをダウンロードし、ゼロから作り直せるようになる。同時に、タスクバーを画面の上下左右どこにでも配置できるカスタマイズ機能や、月例更新プログラムの再起動を1回に集約する取り組みも公開された。 Cloud Rebuildとは何か Windows 11には従来から「このPCを初期状態に戻す」というクラウドリセット機能があるが、これはあくまでWindows回復環境（WinRE）が正常に起動できることが前提だった。回復パーティションが壊れていたり、そもそもOSがまったく起動しない状態では、結局USBの回復メディアを作って持ち歩くしかなかった。 Cloud Rebuildはこの「詰み」の状態を想定した機能だ。ファームウェア（UEFI）レベルのネットワーク機能を使ってWindows Updateのサーバーに接続し、OSイメージとドライバー一式を直接取得して端末を再構築する。既存のOS環境やローカルの回復パーティションに依存しないため、理論上はストレージがほぼ壊れていても復旧の糸口になる。 タスクバーの配置自由化 Windows 11はデザイン刷新のタイミングでタスクバーを画面下部に固定し、Windows 10まで可能だった上下左右への移動を封じていた。今回のInsiderビルドでは、この制限を緩め、上下左右どこにでも配置できるテストが始まっている。移行組のユーザーや、縦型・ウルトラワイドモニターを使う層には歓迎される変更だろう。 月次更新の再起動を1回に集約 これまで月例更新では、サービシングスタックの更新と累積更新が別々に適用され、再起動が複数回発生することがあった。これを1回にまとめる取り組みも同時に公開されており、地味だが体感できる改善だ。 実務への影響 IT管理者にとって一番効くのはCloud Rebuildだろう。リモートワーカーや拠点分散型の組織では、起動不能機のために回復USBを常備・郵送する運用が発生しがちだが、それを減らせる可能性がある。ヘルプデスクの現地訪問コストや、退避すべきUSBメディアの管理負担が下がる方向性は素直に評価できる。 月次更新の再起動集約は、夜間メンテナンス枠を厳密に管理している日本企業の情シスにとって地味に助かる話だ。再起動1回で済むなら、変更管理のスケジュール調整も楽になる。 ただし現時点ではあくまでInsiderプレビュー機能であり、正式リリースまでに仕様が変わる、あるいは提供中止になる可能性もある。今の段階でCloud Rebuildを前提にした復旧手順を本番運用のランブックに組み込むのは時期尚早で、あくまで「こういう選択肢が増えそうだ」という理解に留めておくのが妥当だ。 筆者の見解 Windows Insiderの細かい機能を逐一追いかける意味は正直薄れてきていると感じているが、Cloud Rebuildのような「復旧・信頼性」まわりの改善は数少ない、今のWindowsで本当に価値がある変化だと思う。Smart App Controlやカーネルドライバーの締め出しなど、ここ最近のセキュリティ・堅牢性方向の改善と同じ文脈で評価していい話だ。 Windows Updateについては「すぐ当てたら壊れた」という報告が増えていて、企業側の判断が年々難しくなっている。適用を焦らず数日様子を見る判断も立派なセキュリティ判断だと考えているが、Cloud Rebuildのようなセーフティネットが用意されれば、「万が一壊れても復旧できる」という安心感が生まれ、結果的に更新適用の判断自体がしやすくなる。派手な機能ではないが、地に足のついた改善として素直に歓迎したい。 出典: この記事は Microsoft rolls out 6 helpful new Windows 11 Insider features for early July, including one built to protect your PC from disaster の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国土安全保障省（DHS）が受けたサイバー攻撃は、実は今回が「初検知」ではなかった。英Neowinの報道によれば、DHSは同じ攻撃の兆候を過去に2度も見逃し、3度目にしてようやく本格的な対応に乗り出していたことが明らかになった。国家機関や州組織を狙うサイバー攻撃が世界的に相次ぐ中、警戒すべき事例がまた一つ増えたことになる。 「2度見逃す」という異常事態 Neowinの報じたところでは、今回DHSが対応した攻撃は、世界各地の国家機関・州組織を狙う一連のサイバー攻撃の最新事例に位置づけられる。注目すべきは攻撃そのものの巧妙さ以上に、「同じ兆候を2度スルーしてから、3度目でようやく重大インシデントとして扱った」という組織側の対応プロセスにある。侵入経路や攻撃者像については現時点で限定的な情報しか公開されていないが、この「見逃しの繰り返し」自体が、多くの組織に共通するセキュリティ運用の構造的な弱点を浮き彫りにしている。 なぜ重大な兆候が「誤検知」扱いされてしまうのか 大規模組織のセキュリティ運用現場では、日々大量のアラートが発報される。SOC（Security Operation Center）のアナリストは、その大半を過去の経験則から「よくある誤検知」と判断して流している。これは合理的な行動だが、裏を返せば「本物の攻撃も、統計的にはノイズに埋もれる」ということでもある。加えてネットワーク層・ID層・アプリケーション層など監視対象がサイロ化されていると、単体では小さく見える兆候同士の相関が取れず、「点」のまま放置されがちだ。DHSのように大規模かつ多数のシステムを抱える組織では、この構造的リスクがより顕著に表れやすい。 実務への影響 ― 日本のIT管理者への教訓 日本の官公庁・大企業でも他人事ではない。特に以下の3点は今すぐ点検する価値がある。 アラートの「握りつぶし基準」を定期的に見直す — 過去に誤検知だった兆候パターンが、今後も誤検知であり続ける保証はない。攻撃者は検知ルールを学習して回避してくる。 常時アクセス権を持つアカウントを棚卸しする — Just-In-Time（JIT）でのアクセス権付与に切り替えるだけで、初動の異常検知が格段にしやすくなる。常時アクセス権は「攻撃者にとっても常時使い放題の権限」だと忘れてはならない。 人間以外のID（NHI: Non-Human Identities）を可視化する — サービスアカウントやAPIキーなど、人が介在しない経路からの侵入は見逃されやすい。ここを自動的に監視できていないと、今回のDHSのように「気づいたときには2周目」ということになりかねない。 筆者の見解 正直に言うと、セキュリティ運用の細かい話は得意分野ではない。それでも技術的な関心は強く持っている領域で、今回の件は象徴的だと感じる。潤沢な予算と専門人材を抱えているはずの国家機関ですら、同じ兆候を2度見逃す。この事実は「うちは大丈夫」と思っている日本の組織にこそ突き刺さるはずだ。 筆者はゼロトラスト推進派であり、VPNのような「境界に依存した安心感」はもう卒業すべきだと考えている。今回のようなケースを見るたびに思うのは、結局のところボトルネックは常に人間の判断だということだ。常時アクセス権を減らし、NHIまで含めて自動的に検知・遮断できる仕組みを作らない限り、「アラートを見逃す組織」はこれからも増え続けるだろう。DHSの今回の件を対岸の火事にせず、自組織のアラート運用を見直すきっかけにしてほしい。 出典: この記事は DHS dismissed hack attack twice before sitting up and taking notice の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Windows Subsystem for Linux（WSL）の内部アーキテクチャを刷新し、Linuxカーネルのリソース管理機構であるcgroupのバージョンをv1からv2に切り替えた。この変更によりWSLの安定性は向上する見込みだが、一部のワークロードでは後方互換性が失われることも明らかになっている。 cgroup v2移行の技術的な意味 WSL2は、Hyper-Vベースの軽量な仮想マシン上で実際のLinuxカーネルを動かす仕組みだ。複数のディストリビューションを同時に起動できるのは、カーネルのcgroup機能でプロセスグループごとにCPU・メモリ・I/Oを分離管理しているからにほかならない。 これまでWSLが使ってきたcgroup v1は、リソースの種類ごとに別々の階層（コントローラー）を持つ複雑な構造で、ディストリビューションの起動・終了処理で競合やハング、メモリの解放漏れが起きやすいという課題を抱えていた。cgroup v2は単一階層に統合されたシンプルな設計で、こうした不安定要因を構造的に減らせる。Microsoftが安定性向上を優先してこの移行に踏み切ったのは筋が通っている。 一方でcgroup v2は、v1前提で書かれた古いsystemdやコンテナランタイムと相性が悪い。具体的には、cgroup v2への対応が入る前のsystemdや、対応が不十分なDocker Engineを使っている環境では、コンテナやサービスの起動に失敗する可能性がある。 実務への影響 WSL2を開発環境やDocker Desktopのバックエンドとして使っているエンジニア、それを管理するIT部門にとっては見過ごせない変更だ。 更新前にディストリビューション内のsystemdバージョン（systemctl --version）とDocker Engineのバージョンを確認する Docker Desktopを使っている場合は最新版へのアップデートを済ませてからWSLの更新を反映する 複数の開発者PCを抱えるチームでは、一斉更新ではなく数台での動作確認を挟んでから展開する Windows Update全般に言えることだが、「当てたら壊れた」という報告が出てから数日様子を見るのも、立派なセキュリティ・安定性判断だ。特に開発環境が止まると業務影響が大きいWSLのような基盤コンポーネントほど、この判断が効いてくる。 筆者の見解 個人的には、この手の「地味だが本質的な」改善こそもっと評価されるべきだと思っている。WSLは日本のエンジニアの間でもLinux開発環境の定番になっており、cgroup v1由来の不安定さに悩まされてきた人は少なくないはずだ。 派手な新機能よりも足回りの安定性を優先する判断は、正面から評価したい。ただし移行に伴う互換性リスクの周知はもう一段丁寧であってほしい——Docker DesktopやsystemdのバージョンとWSLの対応関係を、公式ドキュメントでもっと明示してもらえると、現場での更新判断がずっと楽になる。Windowsの基盤技術としてWSLが正面から評価される機会が増えることを期待している。 出典: この記事は Microsoft makes Windows Subsystem for Linux more stable with architecture tweak の内容をもとに、筆者の見解を加えて独自に執筆したものです。

過去最大の570件、その内訳とは Microsoftは2026年7月のPatch Tuesdayで、月例更新としては過去最大となる570件の脆弱性を修正した。近年のPatch Tuesdayは月100件台後半から300件台で推移することが多く、570件という数字は明らかに異例の規模だ。対象製品も広範囲に及び、Windows本体だけでなく、Active Directory Federation Services（AD FS）やSharePoint Serverといった、企業のID基盤・情報共有基盤の中核を担う製品も含まれている。 今回とりわけ注意すべきは、悪用が既に確認されているゼロデイ脆弱性が2件、詳細が一般に公開済みのゼロデイが1件（BitLockerのバイパスに関するもの）含まれている点だ。ゼロデイとは、修正プログラムが提供される前から悪用が可能、あるいは実際に悪用されている脆弱性を指す。攻撃者はパッチが行き渡る前の「窓」を狙って攻撃を仕掛けてくるため、通常の月例パッチ以上にスピード感のある対応が求められる。 AD FS・SharePoint Serverが名指しされる理由 AD FSは社内外の認証を橋渡しするフェデレーション基盤であり、SharePoint Serverは組織の文書・情報共有の中心にある。どちらも侵害されれば影響範囲が組織全体に及びやすく、かつ多くの企業でインターネットに公開された形で運用されている。管理者向けパッチの適用が後回しにされがちな「地味だが重要」な製品でもあり、今回のアドバイザリで名指しされたことは、攻撃者がこの種の基盤を明確に狙っていることの裏返しと見るべきだろう。 BitLockerバイパスについては、ディスク暗号化という「最後の砦」を回避する手法が公開されている状態を意味する。リモート攻撃の入り口にはなりにくいが、端末の紛失・盗難時の情報保護という観点では見過ごせない。 実務への影響 日本のIT管理者にとっての優先順位は明確だ。 悪用済みゼロデイ2件は最優先で緊急適用。 WSUSやIntuneのリング配信を待たず、対象製品が明確なら検証を最小限にして先行適用する「ブレークグラス」対応が妥当。 AD FS・SharePoint Serverは棚卸しを。 特にインターネット公開しているフェデレーションサービスやSharePoint Serverがあれば、パッチ適用状況とバージョンを即座に確認する。オンプレミス版はサポート切れ・更新遅延が起きやすいため、この機会に構成そのものの見直しも検討したい。 BitLockerバイパスは端末紛失リスクの高い組織で優先度を上げる。 TPM+PIN構成やIntuneのコンプライアンスポリシーで、パッチ以外の防御層も併せて点検する。 その他の一般的な修正は、いつも通り数日のステージング検証を経てから展開してよい。 570件すべてを同じ緊急度で扱う必要はない。 筆者の見解 570件という数字だけを見ると身構えてしまうが、これはMicrosoftの検出・修正体制がそれだけ広い範囲をカバーしている証でもある。数の多さそのものより、「どれが今すぐ必要な対応で、どれは通常のサイクルで良いか」を切り分ける判断力の方が重要だ。 実際、最近は「パッチをすぐ当てたら別の不具合で環境が壊れた」という報告も増えており、闇雲な即時適用が必ずしも正解とは限らない。今回のように悪用済みゼロデイが明確になっているケースは即時対応が筋だが、そうでない大多数の修正については、数日様子を見てから展開する判断も立派なセキュリティ判断だと考えている。Microsoftにはこの優先順位の切り分けを、今後のアドバイザリでもっと分かりやすく打ち出してほしい。せっかく脆弱性の検出・開示体制は世界トップクラスなのだから、現場が迷わず動ける情報の出し方まで含めて、正面から評価される存在であってほしいと思っている。 また、AD FSのようなID基盤が繰り返し標的になる状況を見るにつけ、パッチ適用だけに頼らない防御も改めて重要だと感じる。常時アクセス権を減らしJust-In-Timeで必要な時だけ権限を渡す設計にしておけば、仮に一つの脆弱性を突破されても被害の広がりを抑えられる。パッチは後追いにならざるを得ない以上、平時からの権限設計こそが本当の防御線になる。 出典: この記事は Record-Breaking Microsoft Patch Tuesday Update: 570 Vulnerabilities Fixed, Including 3 Zero-Days の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11に標準搭載されているセキュリティ機能「Microsoft Defender」の最新アップデートに、攻撃者がPCのディスク容量を意図的に満杯にできてしまう不具合があると報告されている。海外メディアNeowinが伝えたもので、悪用されればディスクの空き容量が枯渇し、アプリの起動失敗やシステムの不安定化、最悪の場合はOSの正常な動作継続が困難になるおそれがある。 何が起きているのか Defenderはマルウェアの検出時、疑わしいファイルを隔離（Quarantine）したり、スキャンログを記録したりする挙動を持つ。今回報告されている不具合は、細工されたファイルや特定の操作をトリガーにこの隔離・ログ処理が異常な形で繰り返され、コピーやログが際限なく生成され続けることでディスク容量を食い潰す、というものとみられる。いわゆる「リソース枯渇型」の不具合で、情報を盗み出したり権限を奪ったりする侵入型の脆弱性とは性質が異なり、サービス妨害（DoS）に近い挙動だ。 セキュリティソフト自身が持つ「守るための処理」が逆手に取られる構図は目新しいものではなく、アンチウイルス製品では過去にも類似の報告が繰り返されてきた。今回の件も、Defenderのアップデートで新たに導入・変更された処理が想定外の入力に対して脆弱だった、という典型的なリグレッションの一種と考えられる。 実務への影響 日本の企業でWindows 11とMicrosoft Defenderを使っている環境は非常に多く、他人事ではない。特に以下の点は実務でチェックしておきたい。 即座の全展開を避ける: Intune・WSUS・Configuration Managerなどでリング展開（一部端末→段階拡大）の運用をしている場合、Defenderのプラットフォーム更新やエンジン更新もその対象に含め、一斉配信を避ける ディスク容量の監視アラート: サーバー・エンドポイント問わず、ディスク使用率の急増を検知するアラートを仕込んでおけば、この種の不具合が発生した際の被害を最小化できる 修正パッチの適用状況を追う: Microsoft側が修正版を出し次第、検証環境で確認してから本番展開するフローを徹底する 筆者の見解 正直に言うと、Windows Updateまわりは最近「すぐ当てたら壊れた」という報告も増えていて、判断が難しくなってきている。今回のようにセキュリティ機能そのもののアップデートが新たな問題を持ち込むケースが出てくると、その傾向はなおさら顕著になる。 だからこそ、リリース直後に全台へ即時適用するのではなく、数日様子を見てから展開する、という判断は決して臆病なのではなく、立派なセキュリティ判断だと考えている。Defenderのような基盤コンポーネントで足元をすくわれるような不具合が出るのはもったいない話で、Microsoftには基盤の品質でこそ正面から勝負してほしいという期待を込めて、あえて厳しめに見ておきたい。 段階的ロールアウトや監視体制の整備は、こうした不確実性を前提にした「道のど真ん中」の運用であり、特別なことではなく当たり前に備えておくべき基本動作だ。今回の件を機に、自組織のパッチ適用フローを見直すきっかけにしてもよいだろう。 出典: この記事は New Microsoft Defender update can let hackers totally fill your Windows 11 PC disk space の内容をもとに、筆者の見解を加えて独自に執筆したものです。

セキュリティ企業Group-IBは2026年7月、Android向けリモートアクセス型トロイの木馬（RAT）「RedHook」の新版が、Androidの無線デバッグ機能（Wireless ADB）を悪用してシェルレベルの権限を取得する新手口を採用していると報告した。従来はUSBケーブル経由のADB接続が前提だったが、新版はスマートフォン単体で完結し、PCへの接続を一切必要としない点が特徴だ。 Wireless ADBとは何か ADB（Android Debug Bridge）はGoogleが提供する開発者向けデバッグインターフェースで、PCからコマンドラインでAndroid端末を操作できる。Android 11以降で追加されたWireless ADB（無線デバッグ）は、USBケーブルなしで同じ操作をWi-Fi経由で行える機能だ。 RedHookの攻撃手口 RedHookは「アクセシビリティサービス」の権限をユーザーからだまし取ることで、設定アプリを自動操作し、開発者向けオプションを有効化、Wireless Debuggingをオンにする。さらに画面に表示されるペアリングコードを自ら読み取り、ループバックアドレス（127.0.0.1）経由で端末自身のADBサービスに接続することで、UID 2000というシェル権限（一般アプリより強力だがroot権限ではない）を取得する。この手口は端末がroot化されていなくても成立するため、大半のAndroid端末が対象になり得る。 シェル権限を得たRedHookは、開発者やパワーユーザーに人気の正規ツール「Shizuku」ベースのフレームワークをlibmx.soとして展開し、UID 2000の特権APIを呼び出す。これにより追加の権限付与、保護された設定の変更、アプリのサイレントインストール／アンインストールなどを、ユーザーに気づかれることなく実行できる。 53種類のコマンドと執拗な永続化 Group-IBの解析によると、RedHookはC2サーバーからの指示で53種類のコマンドを実行できる。画面ストリーミングやスクリーンショットの取得、タップ・スワイプ・長押しなど操作の自動化、連絡先・SMS・アプリ一覧の収集、偽の認証ダイアログのオーバーレイ表示、カメラの起動などが含まれる。 永続化の作り込みも念入りだ。無音の音声再生でプロセス優先度を引き上げ、WakeLockでCPUスリープを防ぎ、互いを監視して片方が終了すればもう片方が再起動させる2つのサービスを常駐させる。加えて5分おきのウォッチドッグアラーム、端末再起動後の自動復帰、メモリ逼迫時に強制終了されにくくするoom_score_adjの調整まで実装されている。 配布経路は、政府機関や金融機関を装ったメッセージ・電話で被害者を偽のGoogle Playサイトへ誘導する、典型的なソーシャルエンジニアリングだ。 実務への影響 日本企業でもBYOD端末や個人スマートフォンから会社のTeams・Outlook・OneDriveにアクセスするケースは珍しくない。RedHookのようなRATがアクセシビリティ権限を奪えば、資格情報の窃取や画面内容の盗み見を通じて、そのまま社内システムへの侵入口になりかねない。 IT管理者が明日からできる対策は次の通りだ。 Google Playストア以外からのアプリインストールを禁止し、Play Protectを有効化する Intune等のMDMで開発者向けオプション／USBデバッグの有効化状態を検知し、該当端末をコンプライアンス違反としてConditional Accessでブロックする アクセシビリティサービスの権限要求が出た際は「なぜこのアプリがこの権限を必要とするのか」を疑う文化を社員に浸透させる 銀行や行政機関を名乗る電話・SMSからアプリインストールへ誘導する手口には特に警戒するよう周知する 筆者の見解 今回の手口で一番怖いのは、root化なしでも「シェル権限」という強力な足場を作れてしまう点だ。これは企業の特権アカウント管理でいう「常時アクセス権」の危うさと同じ構造だと感じる。一度アクセシビリティ権限という鍵を渡してしまえば、あとは開発者オプションのON/OFFもペアリングもすべて自動でやられてしまい、人間が気づいて止める機会はほとんどない。 ゼロトラストの発想はネットワークの外側だけでなく、端末そのものにも当てはめるべきだ。EntraのConditional AccessやIntuneのコンプライアンスポリシーで「開発者オプションが有効な端末には社内リソースへアクセスさせない」といった制御を組んでおけば、今回のような手口が成立してしまった場合でも被害をそこで止められる。ユーザーを禁止事項で縛るのではなく、正規の手順を踏んだ端末だけが快適に使える仕組みを用意しておくことが、結局いちばん効く。今回の事例はそれをあらためて教えてくれている。 出典: この記事は RedHook Android malware now uses Wireless ADB for shell access の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AnthropicはClaude Fable 5（最新の最上位モデル）について、Pro・Max・Team・プレミアムEnterpriseシートといった有料プラン契約者への「追加課金なし提供」の期限を、2026年7月19日午後11時59分59秒（太平洋時間）まで再延長したと発表した。あわせて、Claude Codeの週次利用上限を50%引き上げる措置も同日まで延長される。 何が起きているか 今回の延長は今年に入って3度目だ。当初Anthropicは「Fable 5の無料提供は7月7日まで」としていたが、それを7月12日まで延長し、今回さらに7月19日まで延ばした形になる。 仕組みとしては、週次のサブスクリプション利用上限のうち最大50%分をFable 5に充てることができ、特別な申請や有効化操作は不要。他のClaudeモデルと同じ利用量プールを共有する形で消費される。ただしAnthropicは「Fable 5は他モデルよりも利用量の消費ペースが速い」と明言しており、上限に達した後は（1）従量課金のクレジットを使って利用を続けるか、（2）他モデルに切り替えて残りの利用枠内で作業を続けるか、の二択になる。 対象となるのはClaude on the Web、Claude Mobile、Claude Desktop、Claude Cowork、Claude Code、Claude Design、Claude for Microsoft 365、Claude for Teams、Claude Tagと幅広い。Claude Codeで利用するにはバージョン2.1.170以降が必要な点は要注意だ。なお、Freeプラン、Enterpriseの標準シート、従量課金Enterprise、API利用はこの無料提供の対象外となっている。 Anthropicは「Fable 5が恒久的に有料プランから外れるわけではなく、計算リソースが十分確保でき次第、標準提供に戻す」ともコメントしている。つまり今回の延長は「サービスの縮小」ではなく「本来の提供形態に戻すタイミングの先送り」という位置づけだ。 実務への影響 Claude Codeを業務で使っている日本のエンジニアにとっては、追加コストなしで最上位モデルを使える期間が単純に1週間延びたという朗報だ。ただし実務上押さえておくべきポイントが3つある。 1つ目はバージョン確認。Claude Codeでの利用にはv2.1.170以降が必須のため、CIやローカル環境のバージョンを一度チェックしておきたい。2つ目は消費ペースの把握。Fable 5は上限消費が速いため、大きめのタスクをまとめて投げる前に、Claudeの設定画面で週次利用状況を確認する習慣をつけておくと、想定外に上限へ到達して作業が止まる事態を避けられる。3つ目はモデル切り替えの運用。上限到達後は自動的に他モデルへフォールバックする設定ではないため、チームで「上限到達時はどのモデルに切り替えるか」をあらかじめ決めておくと、作業の中断を最小限にできる。 筆者の見解 延長が3回続いているという事実は、単なる「太っ腹なキャンペーン」というより、AI業界全体で計算資源（GPU/アクセラレータ）の確保が引き続きボトルネックになっていることの表れだと見ている。最上位モデルを無料開放するには相応の計算コストがかかるはずで、それを何度も延長できているのは、ユーザー獲得競争の激しさとリソース調達の綱引きが同時に起きている証拠だろう。 個人的なスタンスとしては、こうした「いつまで無料か」というニュース自体を逐一追いかけるより、使える期間にとにかく手を動かして自分なりの判断軸を作る方が建設的だと考えている。上限に達した後にどのモデルへ切り替えても業務が回る体制を作っておくことの方が、期限を気にし続けることより価値が高い。次に上限へ達したときにどう動くかを決めておく——それが今回のニュースから拾うべき一番の実務的な教訓だ。 出典: この記事は Claude Fable 5 stays free for paid users until July 19 as Anthropic buys more time の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11に標準搭載される数々のアプリと、あらゆる場面に顔を出すCopilotに対して、現場のIT管理者たちが堪忍袋の緒を切らしている。米ニュースサイトNeowinは、Reddit最大級のシステム管理者コミュニティ「r/sysadmin」に投稿された複数の投稿を取り上げ、Windows 11やMicrosoft製品への不満が「圧倒的な支持」を集めていると報じた。 Redditで噴出した「現場の声」 記事が紹介するのは、実際に企業のIT基盤を運用する管理者たちの生々しい声だ。ある投稿者は、あるセキュリティパッチを適用したところ業務上最も重要な社内アプリが動かなくなったと報告している。厄介なのは、そのパッチをアンインストールするとRDS(リモートデスクトップサービス)環境でのOffice 365認証が壊れてしまうことだ。つまり「業務アプリが使えない」か「Office 365製品全般が使えない」かの二択を迫られたことになる。この投稿には、「あらゆる場面にCopilotを押し込んでくることの方が大事らしいね」という皮肉のコメントが多数寄せられた。 別の投稿者は、WindowsAppsやappx形式のアプリケーション管理に日々振り回されている苦労を訴え、「この際だからMicrosoft Storeという仕組みは丸ごとゴミ箱に捨ててほしい。エンタープライズの現場には、この設計思想を学んでいる時間などないのだから」と痛烈に批判した。これらの投稿はいずれもr/sysadmin内で大量の支持(upvote)を集めており、Neowinは一部の管理者の愚痴ではなく、業界に広く共有された実感だと指摘している。 実務への影響 日本のIT管理者にとっても他人事ではない構図だ。特に重要なのは、パッチ適用とOffice 365認証が絡んだ障害の再現性が高いという点だろう。RDSやAVD(Azure Virtual Desktop)環境でOffice 365・Microsoft 365 Appsを稼働させている組織は、月例更新プログラムを本番環境へ即時展開する前に、Windows Update for Businessの「デプロイメントリング」機能を使って段階的に適用範囲を広げる運用を改めて見直したい。 appx/Microsoft Store管理についても、Win11Debloatのような非公式スクリプトに頼るのではなく、IntuneやWinGetによる公式なアプリ管理・削除ポリシーを整備しておくのが望ましい。実はMicrosoft自身もこの問題を意識してきており、Windows 11のプレインストールアプリを管理者が正式に削除できる「キルスイッチ」機能を最近のビルドで追加し始めている。こうした公式な仕組みが整備されるほど、非公式ツールへの依存や「野良デバッグ」的な運用から脱却できる。 筆者の見解 正直なところ、この記事に並ぶ現場の声には既視感しかない。Windows 11のプレインストールアプリや、Officeスイートのあちこちに割り込んでくるCopilotの存在感は、日々Windows環境を管理している立場からすると「またか」という感覚だ。Microsoftを応援する立場から率直に言えば、こういう摩擦をいつまでも放置しているのはもったいない。エンタープライズの信頼を積み上げてきたブランドなのだから、現場から悲鳴が上がる前に、appxやMicrosoft Storeの設計をもっと管理者フレンドリーにできたはずだ。 一方で、救いもある。プレインストールアプリを公式に削除できる仕組みをMicrosoftが用意し始めているのは、正しい方向への一歩だ。「禁止するのではなく、公式にサポートされた形で安全に使える(あるいは削除できる)仕組みを提供する」というアプローチこそ、エンタープライズ運用では最も現実的な解決策になる。Windows Updateについても、「当てたら壊れた」という報告が後を絶たない以上、リリース直後に即座に全展開するのではなく、数日様子を見てから段階的に適用するという判断は、臆病さではなく立派なセキュリティ判断だと筆者は考えている。Microsoftには、現場の不満を「またか」で終わらせず、次のWindows 11アップデートで具体的な改善として見せてほしい。 出典: この記事は IT admins feel overwhelmingly “sick of” Microsoft and Windows 11 “garbage” apps, products の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Coreutils for Windowsとは Microsoftが、WSL（Windows Subsystem for Linux）を使わずにLinux風のUNIXコマンドをWindows上でネイティブ実行できる「Coreutils for Windows」を公開した。ls、cp、mv、rm、catといった、Linux・macOS・WSLで日常的に使うコマンド群を、単一のマルチコールバイナリとしてWindowsに移植したものだ。findやxargsを含むfindutilsと、GNU互換のgrepも同梱されている。WinGet（winget install Microsoft.Coreutils）またはGitHubから入手でき、動作にはPowerShell 7.4以降が必要になる。 RustベースのuutilsコアutilsとGNU互換性 技術的に興味深いのは、実装の土台がRustで書かれた「uutils/coreutils」であることだ。これはGNU coreutilsのクロスプラットフォーム再実装プロジェクトで、すでに一部の最新Linuxディストリビューションにも採用が進んでいる。C言語で書かれた従来のGNU coreutilsに対し、Rustは言語レベルでメモリ安全性を保証するため、バッファオーバーフローのような古典的な脆弱性のクラスをそもそも作り込みにくい。基盤となるOSコマンド群をメモリ安全な言語で置き換える流れは、Microsoftがここ数年Windowsカーネルやドライバー領域で進めてきた方向性とも一致している。 地味だが効いている設計：DOSコマンドとの共存 もう一点評価したいのが、既存のCMDスクリプトへの配慮だ。DOS由来のsortやfindは/switch形式の独自オプション構文を持つが、Coreutils for WindowsはこれをUNIX風のsort・findと衝突させず、両方を使い分けられる形で共存させている（詳細は公式ドキュメントの「Shell conflicts」を参照）。新機能を追加する際に既存の挙動を壊さないという、地味だが手堅い設計判断だ。 実務への影響 日本のエンジニア・IT管理者にとっての意味は明確だ。これまでLinux由来のシェルスクリプトやCI/CDパイプラインをWindows環境に持ち込むには、WSLを都度起動するか、Git BashやCygwinのような別レイヤーを挟む必要があった。Coreutils for WindowsはOS標準の一部としてこれをネイティブに解決する。WSLの仮想化コストを避けたい軽量なスクリプト、Windows専用ビルドエージェント上でのLinux風パイプライン処理、社内標準化されたバッチ処理のポータビリティ向上などに直接効いてくる。導入はWinGet一発なので、社内の標準イメージやDevContainer定義に組み込むハードルも低い。 筆者の見解 Windows単体のニュースを逐一追う意味は以前より薄れてきていると感じているが、この機能は素直に良い仕事だと思う。奇をてらわずGNU coreutils互換という「王道」を選び、Rustによるメモリ安全性という地に足のついた技術的裏付けを持ち、しかも既存のDOSコマンドを壊さない後方互換性への配慮まで行き届いている。まさに「道のド真ん中を歩く」設計判断で、派手さはないが実務で長く使われるタイプの機能だ。 派手なAI関連の発表と比べると地味に見えるかもしれないが、開発者の日常的な生産性に直結するのはむしろこうした基盤整備だ。Microsoftにはこの手堅さを、もっと目立つ形でアピールしてほしい。良い仕事をしているのだから、正面からもっと評価されて良いはずだ。 出典: この記事は Coreutils for Windows overview の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft(マイクロソフト)が自社検索エンジンBingの検索結果に、Google Chromeへの乗り換えを検討するユーザー向けに自社ブラウザEdgeを推奨する比較パネルを表示していることが、SNS上での投稿をきっかけに明らかになった。「Chrome」で検索すると表示されるこのパネルは、Rewards(リワード)・VPN内蔵・AIパーソナライゼーション・「Microsoft recommended」の4項目すべてでEdgeにチェックマークを、Chromeにはバツ印をつけている。しかし実際に中身を検証すると、いずれも説得力に乏しいことがわかった。 Bingに現れた「Edge推し」パネルの正体 X(旧Twitter)に投稿されたスクリーンショットは38万回以上表示され、返信の多くは否定的な反応で埋まった。「Edgeの存在意義はChromeをダウンロードするためだけ」という定番の皮肉に加え、「Microsoftが最近まともに出したものはVS Codeだけだ」という辛辣なコメントも見られた。実際にBingで「chrome」を検索すると同じパネルが表示され、下部の「Get started」ボタンを押しても空白ページに飛ぶだけという、お粗末な実装だった。さらに皮肉なことに、そのすぐ下にはFirefoxのダウンロードリンクがスポンサー枠として表示されており、Chrome検索の主役をEdgeとFirefoxが分け合う格好になっていた。 4つの「根拠」を検証する Rewardsは、もうEdge専用の特典ではない。 MicrosoftはBingへのサインインをGoogleアカウントやAppleアカウントでも可能にしたと明らかにしており、Microsoftアカウントなしでも参加できる。ChromeでBingを既定の検索エンジンに設定するだけで同じ特典を得られてしまう。5月には現金100万ドルとメルセデス・ベンツ3台を賞品に据えた総額200万ドル規模のスイープステークスまで実施した一方、実際に交換できるクーポンは品切れが常態化しているという。 「VPN内蔵」は、実はVPNと呼べる代物ではない。 Edge Secure Networkはあるプライバシー研究者によって「Cloudflareのインフラ上で動くHTTP CONNECTプロキシに過ぎず、Edge内の通信しかトンネリングしない」と指摘されている。OS全体の通信を保護したり接続先の国を選べたりする本来のVPNとは異なり、月5GBの上限があり、NetflixやHuluは対象外とされる。 AIパーソナライゼーションの優位性も、以前ほど自明ではない。 サティア・ナデラCEOは2023年時点でMicrosoftのAI活用がGoogleを慌てさせたと語っていたが、その差は3年経った今ほど明確ではなくなっている。 「Microsoft recommended」は、そもそも比較項目として成立していない。 自社が自社製品を推奨するのは当然であり、これは中立的な判断基準ではなく単なる自己言及にすぎない。 実務への影響 日本の企業でもEdgeはWindows標準ブラウザとして、Intuneやグループポリシーで既定ブラウザに設定されているケースが多い。今回の一件は、そうした導入判断とは切り離して考える必要がある。IT管理者にとってEdgeを選ぶ本来の理由は、Entra ID条件付きアクセスとの連携、IEモード(レガシー社内システム対応)、Microsoft Defender SmartScreenとの統合といったエンタープライズ管理上の実利であり、Bingの検索結果に出てくるようなマーケティング施策とは無関係だ。むしろ今回のニュースは、エンドユーザーに「これはOSベンダーによる誘導であり、機能の優劣を保証するものではない」と説明する材料として使える。特に「無料VPN」を謳う機能を業務のセキュアアクセス用途と誤解しているユーザーがいれば、月5GBの上限や暗号化範囲の限定を正しく伝え、本来のリモートアクセス手段(条件付きアクセスやゼロトラストの枠組み)と混同させないことが重要だ。 筆者の見解 正直に言って、これはMicrosoftらしくないやり方だと思う。EdgeはChromiumベースになって以降、パフォーマンスやエンタープライズ管理機能では十分にChromeと勝負できるところまで来ている。それなのに、自社の検索エンジンの結果画面で歪んだ比較パネルを出してユーザーを誘導するようなやり方は、正面から機能や使い勝手で勝負する自信のなさの表れに見えてしまう。もったいない話だ。Windowsのセキュリティ強化やSmart App Controlのような堅実な改善は評価しているだけに、こうした小手先の訴求で信頼を削るのはやめてほしいというのが率直な感想だ。ユーザーは、禁止や誘導ではなく「公式に提供されたものが素直に一番便利だ」と感じられれば自然とそちらを選ぶ。今回のような無理押しは、その逆を行っている。Edgeには正面から勝負できる実力があるはずなので、次はそちらで語ってほしい。 出典: この記事は Microsoft has run out of reasons to push Edge over Chrome, so one of the four is just Microsoft recommended の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Exchange Online（Outlook）のメッセージ回収（Message Recall）機能を拡張し、自社テナントの外——取引先や関連会社など「信頼された組織」宛てに送ったメールも回収できるようにする。新機能「Cross-tenant Message Recall」は2026年8月中旬から順次ロールアウトが始まり、9月中旬までに全世界の環境へ展開される予定だ。 何が変わるのか Exchange Onlineのメッセージ回収機能は、長らく「同一テナント内」でしか機能してこなかった。送信者と受信者が同じMicrosoft 365組織に属していれば、未読の誤送信メールを受信者のメールボックスから削除できたが、組織の境界を一歩でも越えると回収は不可能だった。これは長年、ユーザーから最も多く寄せられる不満の一つだったという。 今回の「Cross-tenant Message Recall」はこの壁を取り払う。ただし無条件ではない。回収を許可するかどうかの主導権は受信側の組織にある。A社がB社宛てのメールを回収したい場合、B社側の管理者が事前にA社のテナントを「許可リスト」に登録しておく必要がある——これが記事タイトルにある「catch（落とし穴）」の正体だ。 設定方法とロールアウト時期 管理者はExchange Online PowerShellから制御する。 クロステナント回収そのものを有効化 Set-CrossTenantRecallConfiguration -CrossTenantRecallEnabled $true 回収を許可する送信元テナントを許可リストに追加 Set-CrossTenantRecallConfiguration -AllowedSenderTenantIds @{Add=“テナントID1”,“テナントID2”} 機能は既定で無効になっており、少なくとも1つの外部テナントを許可リストに登録しない限り動作しない。展開はWorldwide（標準マルチテナント）、GCC、GCC High、DoDの各環境が対象で、対応プラットフォームはWindows・Mac・Web・iOS・Androidとなっている。 実務への影響 日本企業の多くはグループ会社や合弁事業ごとに複数のMicrosoft 365テナントを分けて運用している。持株会社と事業会社、あるいはM&Aで統合前の旧テナントが並存しているケースも珍しくない。これまでは「別テナント宛てに誤送信したら回収不能」で泣き寝入りするしかなかったが、この機能が使えるようになれば、グループ内のテナント同士が相互に許可リストへ登録し合うだけで、社内メール同様の安全網を社外にも広げられる。 IT管理者にとっての実務ポイントは3つ。 許可リストの棚卸しを今から準備する：取引先すべてを無条件に許可するのではなく、グループ会社や恒常的に機密情報をやり取りする相手に絞って設計すべきだ。 回収そのものの制約は変わらない：相手が既にメールを開封済みなら、従来通り回収はできない。「回収機能があるから誤送信しても安心」という誤解が広がらないよう、社内啓発は引き続き必要だ。 クロステナントアクセスポリシーとの整合：B2Bコラボレーションや条件付きアクセスで既に信頼関係を設定している相手であれば、許可リストの追加も運用上の負荷は小さいはずだ。既存のテナント間信頼設定と合わせて棚卸しするとよい。 筆者の見解 メッセージ回収が「同一テナント内限定」だったことには、正直ずっと違和感があった。今の企業はM&Aやグループ経営でテナントが分かれているのが当たり前で、社外への誤送信こそ本当に困る場面のはずだ。その意味で、今回の機能追加はようやく実態に追いついた、待望のアップデートだと感じる。 面白いのは、この機能が「禁止」ではなく「安全に使える仕組み」として設計されている点だ。外部への誤送信をゼロにはできないという前提に立ち、代わりに「相手が許可した送信元からの回収だけを受け付ける」という明示的な信頼関係——ホワイトリスト方式——で安全性を担保している。暗黙の信頼に頼らず、必要な範囲だけを明示的に許可するという設計思想は、ゼロトラストの考え方そのもので素直に評価したい。 Microsoftには、こうした地道だが実務に効く改善を今後も着実に積み重ねてほしい。派手なAI機能の発表も結構だが、現場のエンジニアやIT管理者が本当に困っている「痒いところ」を埋める仕事こそ、正面から勝負できる領域のはずだ。 出典: この記事は Exchange Online receiving one of its “most requested” features next month の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは現地時間7月14日、月例セキュリティ更新プログラム「Patch Tuesday」を公開する。事前予測では修正件数は100〜140件程度とみられ、記録的だった6月の206件からは落ち着くものの、2026年を通じて続く高水準は変わらない見通しだ。さらに同日は、レガシー暗号方式「RC4」を使ったKerberos認証を強制的に無効化する第2フェーズの完了期限とも重なり、ドメイン参加環境で認証エラーが多発するリスクが警告されている。 6月の206件から本来のペースへ、それでも高水準は続く 6月のPatch TuesdayではWindows 11向けに116件、Windows 10向けに104件を含む合計206件のCVEが公開され、Office・SharePoint Server・Visual Studio・.NETなど開発ツール群にも修正が及んだ。これだけの規模にもかかわらず、緊急パッチにあたるOOB(Out-of-Band)リリースは今月発生しておらず、Windows Server 2016の更新不具合修正や、ごみ箱に内部ファイル名が表示される軽微な表示バグへの対応にとどまっている。 もう一つの山場——Kerberos RC4強制廃止の完了期限 7月14日は、老朽化した暗号方式RC4を用いたKerberos認証を段階的に排除する取り組みの第2フェーズが完了する期限でもある。ドメインコントローラーやレガシーアプリケーションでRC4依存が残っている環境では、この期限を境に認証エラーが顕在化する可能性が高い。パッチ適用と認証方式の見直しという2つの作業が同じタイミングで発生するため、IT管理者にとっては負荷の高い1週間になりそうだ。 RoguePlanetゼロデイとランサムウェアに悪用されるBlueHammer 研究者Nightmare-Eclipseが新たに公表したゼロデイ「RoguePlanet」(CVE-2026-50656)は、Microsoft Defenderに存在するレース コンディション型の権限昇格の脆弱性で、GitHub上のPOC(概念実証)コードを使うとSystem権限のシェルを取得できるという。Defenderを標的とした脆弱性報告はここ最近続いており、緊張関係が続いている。加えてCISAは、既に修正済みの脆弱性「BlueHammer」がランサムウェアの攻撃に悪用され始めていると発表しており、次の攻撃対象になる前にパッチ適用状況を再確認しておく必要がある。 Windows 11 26H2がInsiderへ、Windows 10 ESUは無償で1年延長 Microsoftは、次期機能更新版「Windows 11 26H2」をWindows Insiderの開発チャネルで提供開始したと発表した。24H2・25H2と同じサービスチャンネルに属するため、Enablement Package(有効化パッケージ)による軽量な更新が可能で、OS丸ごと入れ替えが必要な23H2以前からの移行に比べて負荷が小さい。なお26H1は同じサービスチャンネルには含まれず、カーネルも異なるため、別途の更新経路が用意される予定だ。また、コンシューマー向けWindows 10の無償ESU(拡張セキュリティ更新プログラム)提供が2027年10月まで1年延長されたが、企業向けは一部例外を除き引き続き有償サブスクリプションが必要となる。 CVE個別追跡はもう限界か——業界全体の潮目 脆弱性発見にAIが本格活用され始めたことで、パッチ管理業界全体の前提が揺らいでいる。Adobeは、月1回だった定例セキュリティリリースを月2回体制に切り替えると発表した。直前にはColdFusionの6件の脆弱性(最大CVSS 10.0)をまとめて修正したばかりで、Adobe自身も「月1回の公開サイクルではもはや攻撃者に追いつけない」と説明している。同様の動きはGoogleにも見られ、Chrome 150では433件ものセキュリティ修正が一度に行われた。AppleもOSの更新頻度を年間を通じて増やす方針へと転換しつつある。もはやCVEを1件ずつ追跡管理する手法自体が現実的でなくなりつつあり、現場では「個別のCVEを追うより、ベンダーの最新リリースを可能な限り早く当てる」という運用へのシフトが進んでいる。 実務への影響 日本企業のIT管理者にとって、今回のPatch Tuesdayは単なる「月例パッチ」以上の重みを持つ。まずKerberos RC4廃止の期限は、レガシーな業務システムやドメインコントローラーを多く抱える大企業ほど影響が大きい。事前に自環境でRC4依存の有無を棚卸ししておかないと、パッチ適用日当日に認証障害という形で表面化しかねない。また、CVE個別追跡が限界を迎えつつあるという指摘は、日本の現場にもそのまま当てはまる。四半期ごとの棚卸し型のパッチ管理では、もはやこのペースについていけない。WSUS・Intune・Azure Update Managerなどを使った自動適用の比率を上げ、「重大な脆弱性を手動で選別してから当てる」運用から、「まず当てて、問題が起きたものだけ手動対応する」運用へと発想を転換すべき局面に来ている。 筆者の見解 CVEを1件ずつ真面目に追いかける時代はもう終わりつつある、というこの記事の指摘には強く同意する。情報を追いかけること自体を目的化しても、脆弱性の発見ペースにAIが本格的に使われ始めた以上、人間が全件を精査して優先順位をつけるやり方は遠からず破綻する。ここは「まず当てる、問題が起きたら対処する」という運用に振り切る勇気が必要な局面だと思う。 Kerberos RC4の強制廃止についても、方向性としては正しい。認証層に古い暗号方式を残しておくこと自体が最大のリスクであり、常時アクセス可能な弱い認証経路をなくしていく取り組みはゼロトラストの発想そのものだ。とはいえ、実際にこの期限で認証障害を出す企業が一定数出てくるだろうことも予想がつく。Microsoftには、廃止の判断自体は応援したいが、影響を受ける環境の可視化ツールやロールバック手順の周知にもう一段の力を入れてほしい。せっかく正しい方向に舵を切っているのだから、現場が混乱せずについていける形で進めてもらいたいところだ。 出典: この記事は July 2026 Patch Tuesday forecast: Is CVE tracking still practical? の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年7月9日、Teamsに7つの新機能をロールアウトすると発表した。プライベートチャンネルでのアプリ対応、Teamsイベント向けの新しい表示レイアウト、クラウドファイル検索の強化などが含まれる一方、ミーティングを最小化した状態でも挙手やリアクションができるようにする新機能については、不具合修正のためロールアウトを一時停止したことも明らかにした。 プライベートチャンネルでもアプリが使えるように これまでTeamsの「プライベートチャンネル」では、ボットやメッセージ拡張機能、タブといったアプリ機能が制限されていた。共有チャンネルでは利用できたこの機能が、ようやくプライベートチャンネルにも解禁される。2026年1月から段階的に展開されてきたが、6月末以降に対象ユーザーが大きく拡大し、7月末までに全ユーザーへの展開が完了する見込みだ。 Teamsイベントは「話者中心」レイアウトへ ウェビナーやライブイベント機能「Teams イベント」にも変更が入る。従来は画面共有時に発表者の映像が小さくなりがちだったが、新しい「Speaker-focused（話者中心）」レイアウトでは、発表者の映像と共有コンテンツの両方を強調する表示に切り替えられる。主催者は「参加者に表示する内容の管理」から設定できる。 ファイル共有・ダウンロード周りの改善 添付ファイルピッカーに「クラウドファイルを添付」という新しい選択肢が加わり、SharePoint上のファイルを検索して直接添付できるようになる。また、チャットやチャネルの画像を右クリック（またはホバー）すると新しい「クイック共有」ボタンが表示され、既存の閲覧権限を維持したまま画像リンクをコピーできる。地味だが、ダウンロードマネージャーの刷新（通知の扱い改善、保存先の分かりやすさ向上）も含め、日常業務で効いてくる改善が多い。 一時停止されたマルチタスキング改善機能 一方で注目されていたのが、ミーティングウィンドウを最小化した状態でも、フルウィンドウを開かずに挙手やリアクションができるようにする機能だ。会議をしながら他の作業を並行して行う「マルチタスキング」の使い勝手を大きく改善するはずだった機能だが、一部ユーザーからの評判が芳しくなく、Microsoftはバグ修正のため展開を一時停止したという。 実務への影響 日本企業のTeams管理者にとって、まず確認すべきはプライベートチャンネルでのアプリ許可だ。共有チャンネルとは別に、テナントやチームの管理者ポリシーでアプリ利用を制御している場合、想定外のアプリが利用可能になる、あるいは逆に必要なアプリが使えないといった問い合わせが増える可能性がある。展開は7月末までに段階的に進むため、ロールアウト時期のばらつきをあらかじめ社内に周知しておくと混乱を防げる。 クラウドファイル検索やクイック共有は、SharePoint・OneDrive中心のファイル運用を徹底している組織ほど恩恵が大きい。逆に言えば、ローカル保存やメール添付での共有が残っている現場では、この機会にファイル共有ルールを整理する良いタイミングとも言える。 筆者の見解 Teamsはここ数年、数週間おきに機能を積み重ねる開発スタイルを続けている。クラウドサービスとして継続的に改善し続けること自体は正しい姿勢だ。ただ、今回のように目玉機能を一度出してからロールバックする場面がたびたび見られるのは気になるところだ。ユーザーの反応を見て素早く引っ込める判断力自体は評価できるが、そもそも社内テストの段階でもう少し磨き込んでから世に出してほしいと感じる。 Teamsはビジネスチャットのデファクトスタンダードと言える立場にあり、正面から勝負できる実力を十分に持っているはずだ。だからこそ、一つひとつの機能を丁寧に仕上げて出せば、もっと安心して新機能を使えるプラットフォームとして評価が上がるはずだと思う。今回一時停止されたマルチタスキング改善機能も、完成度を高めたうえで戻ってくることを期待したい。 出典: この記事は Microsoft Teams just added 7 new features, but paused the one that fixed multitasking in meetings の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国の自動車保険会社AssuranceAmericaは、2026年3月に発生した不正アクセスにより、顧客ら698万8886人分の個人情報が流出したことを明らかにした。同社はメイン州司法長官府への届け出で被害規模を公表し、対象者への通知レターを近く発送するとしている。 何が起きたのか AssuranceAmericaは9,500以上の独立系代理店ネットワークを通じて、米国14州で自動車保険・賃貸保険・商用自動車保険を提供する保険会社だ。同社は2026年3月17日、社内システムで不審な挙動を検知した。調査の結果、その前日にあたる3月16日に従業員1名を狙った攻撃が発生しており、これが侵入の起点になっていたことが判明した。 攻撃者は同社のIT環境の一部に不正アクセスし、データファイルをコピーして持ち出していた。流出した情報には、氏名、連絡先、自動車保険の契約・口座情報、運転者・車両情報、保険金請求関連情報、そして運転免許証番号が含まれる。クレジットカード番号や社会保障番号への言及は今回の届け出にはないが、保険契約情報と免許証番号の組み合わせは、なりすまし被害につながりやすい情報セットだ。 被害範囲の特定には3ヶ月以上を要した。同社は「流出したファイルの性質と、確認すべき範囲の大きさから、ファイルの精査が完了したのは6月15日だった」と説明している。検知から通知までに約4ヶ月を要したことになる。 対応としては、侵害された認証情報の無効化、不正セッションの強制切断、影響を受けたシステムの隔離、法執行機関への通報、パスワードのリセット、監視・検知ツールの強化、従業員向けセキュリティ教育の追加を実施したとしている。オーソドックスで一通りそろった対応であり、特段の問題は見当たらない。 なお先月には、米保険大手Aflacの日本法人（アフラック生命）子会社のシステムが侵害され、438万人分の顧客情報が流出したことも公表されている。保険業界は個人情報・医療情報・金融情報が一体で蓄積される業種であり、攻撃者にとって費用対効果の高い標的になり続けている。 実務への影響 日本のIT管理者にとって注目すべきは、侵入の起点が「従業員1名」だったという点だ。ネットワーク境界の防御をどれだけ固めても、正規の資格情報を持つ1アカウントが乗っ取られれば、そこから水平展開されてしまう。典型的なID侵害（Identity Compromise）のパターンであり、境界防御だけに頼るモデルの限界を改めて示す事例といえる。 特に代理店ネットワークのような分散型の組織構造を持つ企業では、外部委託先や代理店経由のアクセス経路も含めて「誰が」「いつ」「何に」アクセスできるかを常時把握する仕組みが欠かせない。常時有効な広範な権限を持つアカウントが1つでも残っていれば、それが最初の突破口になり得る。Just-In-Time（JIT）でのアクセス許可、多要素認証の徹底、異常なセッションを即座に検知する仕組みは、もはや大企業だけの課題ではない。 保険・金融業界に限らず、顧客の個人情報や契約情報を大量に保持する業種であれば、同種の攻撃はいつ自社に向いてもおかしくない。Aflacの事例と合わせて、自社が保有するPII（個人を特定できる情報）の棚卸しと、それを扱うアカウント・アプリケーションのアクセス権を見直す機会にしたい。 筆者の見解 正直に言うと、セキュリティのニュースを追うのはあまり好きではない。似たような手口、似たような後手の対応が繰り返されるからだ。ただ今回のケースには、技術的に見て考えさせられる点がある。侵入の起点が「従業員1名」という、ごくありふれた形だったことだ。 こうした事例を見るたびに思うのは、常時有効な広い権限を持つアカウントを減らし、必要なときだけ必要な範囲でアクセスを許可する仕組み（Just-In-Time）を徹底することの重要性だ。VPNや境界防御に頼るモデルは、正規の認証情報を持つ1アカウントが乗っ取られた瞬間に意味を失う。「今動いているから大丈夫」ではなく常にアクセスを検証するゼロトラストの考え方が、こうした事件のたびに正しさを証明していく。 もう一つ気になるのは、人間のアカウントだけでなく、自動化されたプロセスやサービスアカウントといった非人間アイデンティティ（NHI）の管理だ。業務の自動化が進むほど、人間以外が保持する権限の総量は増えていく。そこを適切に棚卸しできない組織は、結局「便利だから」という理由で常時アクセス権を配りすぎてしまう。セキュリティは細かい話の積み重ねで好きになれないという人は多いだろうが、こうした基本の徹底こそが、690万人分もの情報が流出するような事態を防ぐ一番の近道なのだと思う。 出典: この記事は AssuranceAmerica data breach exposes records of 6.9 million drivers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、AIエージェントを安全に実行する管理型クラウドPC環境「Windows 365 for Agents」を発表した。Microsoft Entra・Intune・Defender・Purview・Agent 365と統合し、人間の従業員に適用してきたのと同じセキュリティ統制を、業務を代行するAIエージェントにも拡張できる仕組みだ。 Windows 365 for Agentsとは何か 本番運用フェーズに入ったAIエージェントは、ローカルPCや共有仮想マシン、管理の行き届かないクラウド環境で動くことが多く、ID管理・ポリシー適用・監査の一貫性を保つのが難しかった。Windows 365 for Agentsはエージェント専用の「Cloud PC」を用意することでこれに応える。人間向けのWindows 365と同様、Entra参加・Intune登録済みの管理対象デバイスとしてエージェントを稼働させる発想だ。 セキュリティの核となる仕組み 核となるのが、エージェントごとに割り当てられる独立ID(Agent ID)だ。人間のアカウントとは切り離され、エージェントの「雇用」と同時にEntraに一意のIDが自動発行される。操作はすべて特定のエージェントに紐づき権限を厳密にスコープでき、Entra Conditional Accessと組み合わせればコンプライアンス要件を満たしたCloud PCからしかリソースにアクセスできないよう強制できる。 Cloud PC自体は隔離された企業管理下の環境で稼働し、人間との混在によるアカウント越境や権限昇格リスクを構造的に排除する。Entra参加・Intune登録済みのため、人間の従業員と同じセキュリティベースラインとコンプライアンスポリシーをプロビジョニング時点から適用できる。ネットワークの出入り口にはID主導型のセキュアWebゲートウェイMicrosoft Entra Global Secure Access(GSA)が入り、Webフィルタリングや脅威対策をエージェント通信にも適用する。 さらにMicrosoft Agent 365との統合でガバナンスと可視性を確保する。Windows 365 for AgentsはAgent 365上でMCP(Model Context Protocol)サーバーとして公開され、テレメトリはMicrosoft DefenderのAIエージェントインベントリや脅威検知、Microsoft PurviewのDSPM for AI・DLPに流れ込む。エージェントが「何にアクセスし何を扱ったか」を人間と同じ枠組みで追跡できる。 実務への影響 日本企業の多くはRPAやローカルスクリプトの延長線上でAIエージェントの実験的導入を進めてきたが、実運用フェーズでは「誰が」「どの権限で」「どこから」エージェントを動かしたか説明できないことが監査や内部統制上の大きな穴になる。Windows 365 for Agentsのような専用実行基盤は、この説明責任のギャップを埋める現実的な選択肢だ。 IT管理者にとって重要なのは、新しい管理体系をゼロから作らなくてよい点だ。既存のConditional AccessポリシーやIntuneのコンプライアンスベースライン、Purviewの機密ラベル・DLPルールをそのままエージェントにも適用拡張できる。人間向けに整備してきたゼロトラスト基盤への投資が、そのまま活きる設計だ。なおEntra・Intune・Defender・Purview・Agent 365には個別のライセンス要件があり、導入前にコストと契約範囲の確認は必須だ。 筆者の見解 エージェントのID(Agent ID)を人間から切り離して管理する設計思想は、Non-Human Identity(NHI)管理の実践そのものであり、素直に評価したい。NHIを統制できなければ「人間が確認しないと動かせない」ボトルネックが残り、自動化は掛け声だけで終わる。エージェントに個別のライフサイクル管理とロールベースアクセス制御を与える方向性は、AI活用を本気で広げるうえで避けて通れない一歩だ。 ネットワーク層でも、Global Secure AccessによってID主導のゼロトラストをエージェント通信にまで広げた点は評価できる。境界防御やVPN頼みのモデルはとっくに限界を迎えており、常時稼働する非人間の通信こそID・デバイス・ネットワークの3層で見る発想が要る。 一方で気になるのは、エージェント専用Cloud PCの権限が「常時オン」のまま運用されないかという点だ。特権アカウント管理では常時アクセス権の付与こそ最大のリスクであり、Just-In-Timeでの権限昇格が本来あるべき姿。エージェントが増えるほど常時稼働する高権限アカウントがなし崩し的に量産される懸念は残る。権限をタスク単位で必要最小限かつ時間制限付きに絞り込む仕組みまで踏み込めるかが次の見どころだ。 とはいえ、既存の統合プラットフォームにそのまま乗せられる設計は、部分最適の寄せ集めになりがちなエージェント基盤の中では正攻法だと思う。Microsoftを応援する立場から言えば、この分野は正面から勝負できる強みのはずで、あとは企業がどこまで安全に、現場の負担なく使い倒せるかにかかっている。 出典: この記事は Windows 365 for Agents: A secured execution environment for AI agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年7月8日（現地時間）、Windows標準のセキュリティ機能であるMicrosoft Defenderのゼロデイ脆弱性「RoguePlanet」（CVE-2026-50656）を修正した。完全にパッチ適用済みのWindows 10・Windows 11環境でも、レースコンディション（競合状態）を突くことでSYSTEM権限のコマンドプロンプトを起動できるというもので、セキュリティ研究者「Nightmare Eclipse」がMicrosoftの脆弱性開示プログラムへの不満から、正式な修正提供前に検証コード（PoC）を自らホストするGitリポジトリで公開していた。 RoguePlanetの正体 ― Defender自身の「隙」を突く攻撃 RoguePlanetは、Defenderのスキャン処理に潜む競合状態を悪用する。成功率は環境依存で「マシンによっては100%成功するが、別のマシンでは失敗しやすい」とNightmare Eclipse自身が説明している。注目すべきは、リアルタイム保護の有効・無効に関わらずPoCが動作した点だ。防御機能そのものが攻撃の足がかりになるという、皮肉な構図である。 Microsoftは6月16日時点で修正作業に着手していることを認めていたが、Nightmare Eclipseを発見者として公式にクレジットはしていない。今回の修正は、通常のPatch Tuesdayとは別系統である「Microsoft Malware Protection Engine」（バージョン1.1.26060.3008）の更新として配布された。Defenderのシグネチャ更新と同じ経路で自動配信されるため、多くの環境では気づかないうちに適用されている可能性が高い。 研究者との根深い対立 今回の開示は単発ではない。Nightmare Eclipseはここ数カ月、BlueHammer、RedSun、GreenPlasma、MiniPlasma、YellowKey、UnDefendと、Defender・BitLocker・Windowsコンポーネントにまたがる複数のゼロデイを次々と公開してきた（GreenPlasma・MiniPlasma・YellowKeyは6月のPatch Tuesdayで修正済み）。 背景にはMicrosoftのバグバウンティ・脆弱性開示プロセスへの不満がある。Nightmare EclipseはGitHub・GitLabでホストしていたPoCリポジトリをMicrosoftに削除されたと主張し、以降は自前のGitサーバーで公開する方針に転じた。さらにMicrosoftは「顧客に実害を与える悪意ある行為」への法的措置も辞さないとする声明を出しており、セキュリティ専門家の間ではこれが実質的に研究者本人への警告と受け止められている。 実務への影響 日本のIT管理者にとって重要なのは、この修正がWindows Updateの通常サイクルではなく、Malware Protection Engineの自動更新で配布されている点だ。多くの環境では自動適用済みだが、次のコマンドで現在のエンジンバージョンを確認しておきたい。 Get-MpComputerStatus | Select-Object AMEngineVersion, AntivirusSignatureVersion WSUSやIntune、SCCMでDefenderの更新配信を制御している場合、シグネチャ更新だけでなくエンジン本体の更新もブロックされていないか確認する価値がある。またNightmare Eclipseの開示ペースからすると、Defender・BitLocker関連のゼロデイは今後も続く可能性が高く、継続的なウォッチをお勧めする。 筆者の見解 セキュリティ分野は正直、得意というより「技術的に気になるから追いかけている」領域に近いが、今回は技術面よりガバナンス面で考えさせられた。 Defenderは全Windows環境に標準搭載される、いわば最後の砦だ。その防御機構自体に競合状態の欠陥が見つかり、しかも「保護が有効でも無効でも突破できる」というのは、単一レイヤーを過信せず、ネットワーク・認証・認可の多層防御を前提に設計すべきだという普段の主張を改めて裏付ける事例だと感じる。 一方でMicrosoftの対応には、応援する立場から見てももったいなさを感じる部分がある。研究者との関係がこじれてPoCが正式パッチ前に公開されてしまう状況は、脆弱性開示プログラムの運用に改善の余地があることを示している。法的措置をちらつかせる姿勢よりも、研究者が正規のルートを使いたくなるような公正で迅速な開示プロセスを整えることの方が、結果的にユーザーを守ることにつながるはずだ。Microsoftほどの規模とブランド力があれば、業界標準となる開示プログラムを作れる力は十分にあるのだから、そこは正面から向き合ってほしい。 出典: この記事は Microsoft patches RoguePlanet Defender zero-day vulnerability の内容をもとに、筆者の見解を加えて独自に執筆したものです。