Windows

Microsoft（マイクロソフト）が、Teams（チームズ）サポートチームに寄せられる「最も対処が厄介な問題」のひとつについて、その原因と解決策を公式に説明した。多くのユーザーやIT管理者を長年悩ませてきたこの問題に、シンプルな修正方法があることが明らかになった。 「よくある、でも解決しにくい」Teamsの問題とは Microsoft Teamsのサポートチームが「最もフラストレーションを引き起こす」と表現する問題群の多くは、アプリのキャッシュ破損や設定ファイルの不整合に起因することが多い。具体的な症状としては： メッセージや通知が正しく表示されない プレゼンス（在席状況）が更新されない・誤った状態で表示される 会議への参加が遅くなる、または接続が不安定になる 再インストールしても問題が再現する これらの問題に共通しているのが「再起動しても直らない」という点だ。多くのユーザーがアプリを再起動しても改善せず、最終的にIT部門に問い合わせる流れになる。 Microsoftが説明する根本原因と修正手順 Microsoftのサポートチームが公式に示したのは、Teamsのキャッシュを手動でクリアするというシンプルな手順だ。ただし、単純に「キャッシュを削除」と言っても、正しい手順を踏まないと解決しない場合がある。 Windows版 Teams（新Teams）のキャッシュクリア手順 Microsoft Teamsを完全に終了する（タスクトレイのアイコンも右クリックで「終了」） Win + R でファイル名を指定して実行を開く %appdata%\Microsoft\Teams を入力してEnter フォルダ内の以下のサブフォルダを削除（フォルダ自体は残す）: Cache blob_storage databases GPUCache IndexedDB Local Storage tmp Teamsを再起動し、サインインし直す 新しいTeams（Teams 2.0）の場合は、アプリ上部の「…」メニューから設定を開き、「アプリのキャッシュをクリア」オプションを使う方法もある。 なぜ「再インストールだけでは直らない」のか 多くの場合、再インストールはアプリの実行ファイルだけを置き換えるため、ユーザープロファイルフォルダ内に残ったキャッシュや設定ファイルがそのまま引き継がれる。これがTeams問題の「再インストールしても再現する」という特性の原因だ。 特に企業環境では、複数のMicrosoftアカウントや条件付きアクセス（Conditional Access）ポリシーが絡み合うことで、キャッシュの不整合が発生しやすい。リモートワーク環境でネットワーク切り替えが頻繁に起きると、さらに問題が起きやすくなる。 IT管理者・エンジニアへの実務ポイント ヘルプデスク対応の効率化に直結する この手順をナレッジベースに登録しておくことで、一次サポートで解決できるケースが大幅に増える。「Teamsの動作がおかしい」と問い合わせが来た際に、まずキャッシュクリアを試してもらうトリアージフローを作成しておくと効果的だ。 エンドポイント管理（Intune等）での自動化 Microsoft Intuneを使って管理されている端末であれば、PowerShellスクリプトでキャッシュクリアを自動実行する仕組みを組み込むことも可能だ。問題が頻発するユーザーグループに対してスクリプトをプッシュ配布する運用も現実的な選択肢になる。 新Teamsへの移行完了を確認する 従来の「クラシックTeams（Teams 1.0）」はすでにサポートが終了している。まだ旧Teamsを使っている環境がある場合、今回のような問題以外にも多くの既知不具合を抱えたまま使い続けることになる。この機会に組織内の移行状況を確認することを勧める。 筆者の見解 Teamsは今や日本企業の多くで業務インフラの中核を担っている。その重要性が高まっているからこそ、「再起動しても直らない」「再インストールしても再現する」という問題は現場の生産性に直結するダメージを与え続けてきた。 Microsoftがこうした「サポート現場の定番問題」について公式に発信し、ナレッジを整理してくれることは、IT部門にとって素直に助かる動きだ。 とはいえ、本来であればキャッシュ破損がここまで頻繁に起きること自体、アプリの堅牢性として改善の余地がある。ユーザーが手動でキャッシュを削除しなければならない状況が「よくある問題」として定番化してしまっているのは、決して望ましい状態ではない。 MicrosoftはTeams 2.0への移行でアーキテクチャを刷新しており、この点の改善を期待している。ユーザーがアプリの内部構造を意識せずに使えるようになってこそ、真の「使いやすいコラボレーションツール」と言えるはずだ。Teamsが持つポテンシャルは本物だから、そこに見合った安定性を追求し続けてほしい。 企業のIT担当者は、今回の手順をヘルプデスクの標準フローに組み込みつつ、チケット数の推移を観察しておくと良いだろう。もしキャッシュクリアで解決しないケースが多発するようなら、ネットワーク設定や認証基盤側の問題を疑う必要がある。 出典: この記事は Microsoft explains simple fix for one of the most “frustrating” Teams issues の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月、Microsoftアカウント（個人向け）のSMSコード認証を段階的に廃止すると公式に発表した。SIMスワップ詐欺やフィッシングへの脆弱性を理由に、パスキー（Passkey）・Microsoft Authenticatorアプリ・副メールアドレスへの移行を強制する方針だ。 SMSが「もう安全ではない」理由 SMS認証は長年、二要素認証（2FA）の代名詞として広く使われてきた。しかし、その実態は構造的に脆弱だ。 通信経路の脆弱性: SMSは平文で携帯電話ネットワーク上を流れる。技術的に傍受が可能な経路が存在する SIMスワップ攻撃: 攻撃者が携帯キャリアを騙してあなたの電話番号を自分のSIMに移管させる手口。成功すれば、SMSの2FAコードはすべて攻撃者に届く フィッシング耐性ゼロ: 偽サイトに誘導してコードを入力させるだけで突破できる Microsoftのサポートドキュメントでは「SMS認証は現在、詐欺の主要な経路となっている」と明言している。これに基づき、個人向けMicrosoftアカウントのSMS認証およびSMS経由のアカウント回復を段階的に終了する。 パスキーとは何か パスキー（Passkey）は、FIDO2/WebAuthn標準に基づくフィッシング耐性の高い認証方式だ。パスワードやSMSコードの代わりに、デバイスに内蔵された生体認証ハードウェアで本人確認を行う。Windows環境では以下が使える。 Windows Hello: 顔認証（IRカメラ）または指紋スキャナー デバイスPIN: TPMチップと紐づいたローカルPIN パスキーの核心は秘密鍵がデバイスから出ない点にある。認証のたびに公開鍵暗号方式でチャレンジに署名するが、その秘密鍵はTPM（Trusted Platform Module）に閉じ込められている。リモートからの攻撃でこれを盗み出すことは原理的に不可能だ。 デバイスを紛失した場合は、iCloud キーチェーン（Apple）やGoogle パスワードマネージャーと同期したパスキー、または登録済みの副メールアドレスでアカウント回復が可能だ。 実務への影響 エンジニア・開発者への影響 移行において最も注意が必要なのは、自動化スクリプトやCIパイプラインでMicrosoftアカウントを使っている場合だ。SMS認証に依存したサービスアカウント的な使い方をしていると、移行後に認証が通らなくなる可能性がある。 対策として以下を今すぐ確認してほしい。 サービスアカウントはEntra ID（旧Azure AD）に移行する: 個人向けMicrosoftアカウントではなく、Entra IDのサービスプリンシパルやマネージドIDを使うべきだ。自動化ワークフローに個人アカウントを使っている場合は移行のタイミングだ Microsoft Authenticatorを今すぐ設定する: プッシュ通知による承認で手間が少ない。SMS廃止前に切り替えておくことで、移行時の混乱を避けられる 副メールアドレスの登録を確認する: SMS廃止後の重要な回復手段となる。アカウント設定から登録状況を必ず確認しておくこと IT管理者への影響 企業内でMicrosoftアカウントを使った個人端末（BYOD）管理をしている場合、ユーザーへの事前周知と移行支援が必要になる。「SMSで受け取っていたコードが届かなくなった」というヘルプデスク問い合わせが急増する可能性がある。移行期限の前に社内アナウンスと移行手順書の整備を進めておきたい。 筆者の見解 SMS認証の廃止は、セキュリティの観点から見ればむしろ遅すぎたくらいだ。SIMスワップ攻撃はすでに現実的な脅威として各国で被害が出ており、「電話番号は本人確認の手段にならない」という認識はセキュリティ業界では常識になっている。 パスキーへの移行は、ゼロトラストアーキテクチャの「デバイスと認証を紐づける」という方向性と完全に一致している。秘密鍵がデバイスのTPMから出ない設計は、フィッシングによる認証情報の盗用を根本から断ち切る。技術的には正しい判断だ。 ただし、心配なのは移行の届け方だ。今回のSMS廃止の告知が「サポートドキュメントにひっそり掲載」という形だったのは気になる。技術的に優れた判断を下すのと同じくらい、ユーザーへの丁寧な移行支援が重要だ。セキュリティを向上させる意図は正しい——あとはその「伝え方」と「サポート」で、Microsoftの本気度が問われる。パスキーが本当に「誰にでも使えるもの」になるよう、移行体験の磨き込みに力を注いでほしい。 出典: この記事は Microsoft is killing SMS codes for Microsoft account sign-in, aggressively pushes passkeys on Windows 11 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

SentinelOneの研究者が2026年5月、macOSを標的とするインフォスティーラー「SHub」の新亜種「Reaper」を発見した。Appleが2026年3月に実装したTerminalベースのセキュリティ対策を巧みに迂回し、AppleScriptを悪用してApple公式のセキュリティ更新ダイアログを偽装する手口が確認されている。Google Chrome・Firefox・Microsoft Edge・1Password・MetaMask・iCloudなど、日常業務でよく使うあらゆるデータが標的だ。 AppleのTerminal対策をわずか数ヶ月で迂回した新手法 従来のSHubは「ClickFix」と呼ばれる手口を使い、ユーザーに悪意あるコマンドをTerminalに貼り付けて実行させていた。Appleは2026年3月にmacOS Tahoe 26.4でTerminalへのコマンド貼り付け・実行をブロックする対策を追加した。 Reaperはこれを回避するため、macOSの正規機能であるapplescript:// URLスキームを利用する。このスキームを使うとmacOSのスクリプトエディタが起動し、悪意あるAppleScriptがあらかじめ読み込まれた状態になる。ユーザーが「実行」ボタンをクリックすると、Apple公式のXProtectRemediatorを引き合いに出した偽セキュリティ更新メッセージが表示され、curlでシェルスクリプトをダウンロードし、zshで静かに実行される仕組みだ。 悪意あるスクリプトのコマンド部分はASCIIアートの下に隠されており、静的解析を困難にしている。 感染前に実施される精密なターゲット偵察 Reaperは感染を試みる前に、訪問者のデバイスを詳細に調査する。 仮想マシン（VM）の利用有無 VPNの使用状況 インストール済みブラウザ拡張機能（パスワードマネージャー・仮想通貨ウォレット） これらのテレメトリデータはTelegramボット経由で攻撃者に送信される。分析環境や研究者のマシンへの感染を避けるための措置だ。また、感染実行前にロシア語キーボード・入力メソッドの使用を確認し、一致した場合はC2サーバーへ「cis_blocked」イベントを送信して処理を中断する——いわゆるCIS圏除外の実装だ。 窃取対象：ブラウザからウォレットアプリ本体まで Reaperが標的とするデータの範囲は広い。 ブラウザデータ: Google Chrome、Mozilla Firefox、Brave、Microsoft Edge、Opera、Vivaldi、Arc、Orion 仮想通貨ウォレット拡張機能: MetaMask、Phantom パスワードマネージャー拡張機能: 1Password、Bitwarden、LastPass デスクトップウォレットアプリ: Exodus、Atomic Wallet、Ledger Live、Electrum、Trezor Suite その他: iCloudアカウントデータ、Telegramセッションデータ、開発者向け設定ファイル さらに「Filegrabber」モジュールがデスクトップと書類フォルダを走査し、財務情報が含まれそうなファイル（2MB以下、PNGは6MB以下、合計150MB上限）を収集する。 ウォレットアプリが存在する場合はより悪質な攻撃が加わる。正規アプリのプロセスを強制終了し、コアファイルをC2サーバーからダウンロードした悪意あるapp.asarに丸ごと置き換える。Gatekeeperによる警告を回避するためxattr -crでファイルの隔離属性を削除し、アドホックコード署名で正規アプリに偽装する。 感染経路：偽WeChat・Miroインストーラー ユーザーへの初期誘導には、実在するアプリを模倣した偽インストーラーが使われた。qq-0732gwh22[.]com（WeChatを模倣）、mlcrosoft[.]co[.]com（Microsoftを模倣）、mlroweb[.]com（Miroを模倣）といったドメインが使用されている。Miro偽装ドメインは現在は正規サイトへリダイレクトされているが、WeChat偽インストーラーは依然として配信中だという。なお、WindowsおよびAndroid向けダウンロードボタンはDropboxにホストされた同一の実行ファイルを配信していることも確認されている。 実務への影響 日本のMac利用者、特に以下のような環境では直ちに注意が必要だ。 リモートワーク・副業エンジニア: 個人のMacを業務に使うケースが多く、ブラウザ内の認証情報や開発者設定ファイルが標的になりやすい。 仮想通貨・Web3関連業務: Reaperはウォレットアプリそのものを置き換える手口を持つため、資産喪失のリスクが直接的だ。 IT管理者への推奨事項: MDMポリシーでmacOSのスクリプトエディタ（Script Editor）の起動を制限することを検討する エンドポイントセキュリティ製品の導入・シグネチャ更新を徹底する ユーザー向け周知徹底：「AppleはWebサイトのダイアログ経由でシステムパスワードを要求しない」という一点を組織全体に浸透させる 筆者の見解 セキュリティ領域は正直、得意分野とは言いにくい。が、この攻撃手法の技術的な巧妙さには素直に驚かされる。 Appleが2026年3月にTerminal対策を追加してからわずか数ヶ月で迂回バリアントが登場した——これは「OSベンダーによるパッチとマルウェア開発者の攻防は終わらない」という冷静な現実を改めて示している。applescript://スキームを通じてScript Editorを悪用する手法は、macOSの正規機能を逆手に取った典型だ。Appleがこのスキームにも制限をかければ、攻撃者はまた別の正規機能を探してくる。いたちごっこの構造は変わらない。 一方で救いがあるとすれば、感染の最後のステップは依然として「ユーザーが実行ボタンをクリックする」という人の操作にある。技術的な回避策と同等に、ユーザー教育が有効に機能する余地がまだある。「Appleが公式セキュリティ更新をブラウザのダイアログで提供することはない」——この認識を組織のユーザー全員が持っているだけで、相当数の感染を防げるはずだ。 ゼロトラストの観点でも示唆は大きい。ウォレットアプリがapp.asarを丸ごと置き換えられてしまう脆弱性は、アプリ側の自己整合性検証の甘さでもある。認証・認可を人からNHI（Non-Human Identities）に移行する議論が進む中、アプリ自体の改ざん検知も同様に重要な課題として認識してほしい。 出典: この記事は SHub macOS infostealer variant spoofs Apple security updates の内容をもとに、筆者の見解を加えて独自に執筆したものです。

INTERPOLは2026年5月、中東・北アフリカ地域を対象にしたサイバー犯罪摘発作戦「Operation Ramz」の成果を発表した。フィッシング・マルウェア・オンライン詐欺に使われていたサーバー53台を押収し、200人超を逮捕。さらに13か国で382人を新たな容疑者として特定している。 作戦の規模と成果 今回の対象となったのは、アルジェリア・バーレーン・エジプト・イラク・ヨルダン・レバノン・リビア・モロッコ・オマーン・パレスチナ・カタール・チュニジア・UAE の13か国。押収した機器から回収した約8,000件の情報パッケージを解析した結果、少なくとも3,867人の被害者が確認されている。 INTERPOLは「この作戦はフィッシングやマルウェアの脅威の無力化に加え、この地域に深刻な経済的損害をもたらすサイバー詐欺の撲滅に焦点を当てた」と声明を出している。 各国で明らかになった犯罪の実態 各国で押収・摘発された事例は、サイバー犯罪の多様化と組織化を如実に示している。 カタール: 知らぬ間にマルウェア配布に利用されていた一般市民の端末を特定・保護した。 ヨルダン: 投資詐欺を組織的に運営するネットワークを解体。アジアから人身売買された15人の労働者が詐欺業務を強制実行させられていたことが判明し、主犯格2人を逮捕した。 オマーン: 機密データを含む脆弱なマルウェア感染サーバーを無効化した。 アルジェリア: フィッシングをサービスとして提供する「PhaaS（Phishing-as-a-Service）」プラットフォームを閉鎖し、容疑者1名を逮捕した。 モロッコ: フィッシング操作に関連する端末および銀行データを押収し、複数の容疑者が司法調査下に置かれた。 官民連携が解体の鍵 今作戦で注目すべき点は、INTERPOLが複数の民間サイバーセキュリティ企業と連携して悪意のあるインフラを追跡した点だ。Kaspersky・Group-IB・The Shadowserver Foundation・Team Cymru・TrendAI が協力し、法執行機関だけでは追いきれない技術的な追跡を担った。 こうした官民パートナーシップは、現代のサイバー犯罪捜査において不可欠な構造になりつつある。攻撃者がクラウドインフラや国境を越えた分散型インフラを使う以上、国家単独の法執行には限界がある。 今年3件目の大規模摘発——グローバルな取り組みが加速 Operation Ramz は、INTERPOLが今年（2026年）完了した3件目の大規模サイバー犯罪摘発作戦となる。 2月「Operation Red Card 2.0」: アフリカ16か国で651人逮捕。投資詐欺・モバイルマネー詐欺・偽ローンアプリが対象で、被害額は計4,500万ドル超。 3月「Operation Synergia III」: 72か国にわたる作戦で、悪意あるIPアドレス4万5,000件をシンクホール化、212台のデバイス・サーバーを押収し94人を逮捕。 5月「Operation Ramz」: 今回の中東・北アフリカを中心とした作戦。 一連の作戦を並べてみると、INTERPOLが地域を変えながら組織的にサイバー犯罪インフラを潰す戦略を取っていることがわかる。 実務への影響——日本のエンジニア・IT管理者が知っておくべきこと 「中東での話だから関係ない」と思ったら危険だ。今回押収されたフィッシング・マルウェアのインフラは、地理的な境界を問わず日本企業のユーザーを標的にできる。特に以下の点を日常業務に取り込んでほしい。 フィッシング対策の再確認: PhaaS（フィッシング・アズ・ア・サービス）の摘発が今回も含まれていた。攻撃者がサービスとして詐欺インフラを「レンタル」できる現在、攻撃の敷居は下がる一方だ。メールフィルタリング・多要素認証（MFA）・セキュリティ意識向上トレーニングは基本中の基本として維持すること。 インフラの可視化: 「知らぬ間にマルウェア配布に使われていた端末」がカタールで見つかったように、自社の端末・サーバーが攻撃インフラの一部として悪用されるリスクは現実にある。EDR（エンドポイント検出・対応）ツールの導入と、定期的なアウトバウンド通信のレビューが有効だ。 サプライチェーン・人的リスクの認識: ヨルダンの事例では、人身売買された労働者が詐欺業務を強制されていた。サプライチェーン上のパートナー企業の倫理的側面まで考慮に入れるセキュリティ評価が重要になっている。 官民連携の活用: Shadowserver Foundation のような非営利組織は、悪意あるインフラに関する情報を無償で提供している。自社のIPアドレスレンジを登録してアラートを受け取るだけでも、初動対応のスピードが変わる。 筆者の見解 サイバー犯罪に対する国際的な法執行の動きが、ここ数年で明らかに加速している。今回のOperation Ramzが示す最も重要な変化は、「技術力を持つ民間企業と法執行機関が組んで犯罪インフラを解体する」モデルが本格的に機能し始めたことだ。Kaspersky・Group-IB・Shadowserver といった組織が情報提供し、INTERPOLが法的執行力を行使するこの構造は、今後のサイバー犯罪対策の標準形になるだろう。 一方で、今回見えてきた課題も看過できない。PhaaS（フィッシング・アズ・ア・サービス）のようなサービス化が進むことで、技術力の低い攻撃者でも高度なフィッシングキャンペーンを展開できる状況が定着しつつある。サーバーをいくつ押収しても、インフラがクラウド上に瞬時に再構築できる現在、「摘発のイタチごっこ」から根本的に抜け出すには、攻撃インフラへの資金流入を断つ金融面でのアプローチが不可欠だと感じる。 日本のIT現場に目を向けると、セキュリティ対策がまだ「境界防御」の発想から抜け出せていない組織が多い。今回押収されたサーバーのような外部インフラが実際に自社ユーザーを狙っているとき、VPNベースの「内側は安全」という思想では対処しきれない。ゼロトラスト的な発想——すべての通信を検証し、最小権限で動かす——への移行を、今こそ本気で進めるべきタイミングだ。理論としてはわかっているはずの組織も、実際の移行が止まっているケースが多い。今回のような事例を「遠い国の話」で終わらせず、自社の設計を見直すきっかけにしてほしい。 出典: この記事は INTERPOL ‘Operation Ramz’ seizes 53 malware, phishing servers の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Linuxカーネルのrxgkモジュールに存在するローカル特権昇格脆弱性「DirtyDecrypt（別名：DirtyCBC）」の概念実証コード（PoC）が公開された。CVE-2026-31635として追跡されるこの脆弱性は4月25日にパッチ済みだが、まだ最新カーネルに更新していないシステムは依然リスクにさらされている。 DirtyDecryptとは何か DirtyDecryptは、Linuxカーネルのrxgkモジュール内、rxgk_decrypt_skb関数におけるCOW（Copy-On-Write）ガードの欠如によって引き起こされる脆弱性だ。このガードがないことで、ページキャッシュへの不正書き込みが可能となり、結果的に一般ユーザーがroot権限を取得できる。 ローカル特権昇格（LPE）のため、リモートから直接悪用することはできない。しかし、クラウドVM・マルチユーザーサーバー・コンテナエスケープ後といった「なんらかの手段でローカルアクセスを得た攻撃者」がいる状況では、root奪取につながる致命的な脆弱性となりうる。 セキュリティ研究チームのV12が2026年5月9日に独立発見・報告したものの、メンテナーから「パッチ済みの重複報告」と通知された経緯がある。 影響を受けるLinuxディストリビューション 本脆弱性の悪用には、カーネルのCONFIG_RXGK設定オプションが有効になっている必要がある。これはAFS（Andrew File System）クライアントのRxGKセキュリティサポートを有効化するオプションで、最新のアップストリームカーネルを積極的に追従しているディストリビューションに限られる。 現時点で影響が確認または懸念される環境： Fedora（PoCによる動作確認済み） Arch Linux openSUSE Tumbleweed Ubuntu LTS・Debian stable・RHEL・CentOS Streamなど、保守的なカーネルポリシーを持つディストリビューションは現時点では影響を受けない可能性が高い。 即時対応：パッチ適用が最優先 最善策はカーネルを最新版に更新することだ。 出典: この記事は Exploit available for new DirtyDecrypt Linux root escalation flaw の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月、Windows 11向け累積セキュリティ更新プログラム「KB5089549」の一部デバイスへのインストールが失敗する問題を公式に認め、回避策を公開した。 何が起きているのか 問題の根本原因は、EFIシステムパーティション（ESP）の空き容量不足だ。特にESPの空き容量が10MB以下のデバイスで顕著に発生する。 更新プログラム適用の流れとしては、インストール自体は最初のフェーズまで正常に進むものの、再起動フェーズの進捗が35〜36%付近でロールバックが始まる。ユーザーには「Something didn’t go as planned. Undoing changes.（問題が発生しました。変更を元に戻しています。）」というメッセージが表示される。 システムログには以下のようなエントリが残るため、原因特定の手がかりになる： SpaceCheck: Insufficient free space ServicingBootFiles failed. Error = 0x70 SpaceCheck: <値> used by third-party/OEM files outside of Microsoft boot directories エラーコードとして報告されるのは 0x800f0922 だ。 回避策：Known Issue Rollback（KIR）の活用 Microsoftは現時点で根本的な修正を開発中としており、当面はKnown Issue Rollback（KIR）と呼ばれるWindowsの機能を使った回避策を案内している。KIRは、Windows Updateを通じて配信された問題のあるアップデートをロールバックする仕組みだ。 企業の管理環境でIT部門がWindows Updateを制御している場合は、グループポリシーを手動でインストール・設定することで対応できる。設定後はデバイスの再起動が必要で、グループポリシーは問題の原因となっている変更を一時的に無効化する。 KIRグループポリシーの展開・設定手順はMicrosoftサポートサイトで公開されている。 今月のWindows Updateを巡る問題の連鎖 KB5089549は4月2026年のWindows 11アップデートが引き起こしていたBitLocker回復画面への強制起動問題の修正も含んでいた。しかし今度は別の問題が浮上した格好だ。 加えてMicrosoftは今月、以下の問題も対応・確認している： Windows Autopatchのバグ：管理ポリシーで制限されているはずのドライバー更新が、EU内のAutopatch管理デバイスに誤って展開されていた問題 4月のセキュリティ更新：脆弱なドライバーを使用するサードパーティ製バックアップアプリケーションで障害が発生する問題 更新プログラムが更新プログラムの問題を修正し、また別の問題を生む——こうした状況が続いている。 日本のIT管理者・エンジニアへの実務ポイント 影響確認の優先手順： 管理下のWindows 11デバイスのESP空き容量を確認する（diskpart や PowerShell で Get-Partition コマンドから確認可能） 10MB以下の空き容量しかないデバイスを優先的に特定し、KB5089549の適用を保留するか、KIRグループポリシーを事前に展開する エンドポイント管理ツール（Microsoft Intune、Microsoft Endpoint Configuration Manager等）を使っている場合は、展開リングの前段階（パイロットグループ）での動作確認を徹底する ESPの空き容量不足が発生しやすいケース： ...

Microsoft が提供した Windows 11 向け更新プログラム KB5089549 に、レジストリを悪用した特権昇格（Privilege Escalation）攻撃の手口が依然として有効であることが判明した。パッチ適用済みのシステムでも攻撃者にシステムを完全掌握される可能性があり、エンタープライズ環境では無視できないリスクとなっている。 何が起きているのか KB5089549 は Windows 11 向けに提供されたセキュリティ更新プログラムだが、本来修正されているはずの特権昇格経路が、レジストリを介した特定の手法では依然として塞がれていないことが研究者によって指摘された。 攻撃シナリオとしては、ローカルの一般ユーザー権限を持つ攻撃者が特定のレジストリキーを操作することで、SYSTEM 権限への昇格を実現できるというものだ。特権昇格攻撃は初期侵入後の「横展開」フェーズで悪用されることが多く、フィッシングやマルウェアによる初期アクセスを得た攻撃者にとって格好のステップとなる。 なぜこれが重要か パッチ適用だけでは不十分な現実 セキュリティ担当者にとって「パッチを当てれば安全」という前提が崩れることは非常に厄介だ。KB5089549 はすでに広く配布・適用されており、「適用済みだから大丈夫」と判断している組織も多いはずだ。しかしこうした残存脆弱性は、攻撃者から見れば「パッチ済みの隙間」として格好の標的となる。 ローカル権限から SYSTEM 権限へ——Active Directory 環境での波及リスク この攻撃で特に危険なのは、ローカルの一般ユーザー権限から始められる点だ。リモートからの侵入に成功した段階で（あるいは悪意ある内部者が存在した場合）、システムの完全制御を奪われるリスクがある。Active Directory 環境では、一台の端末が SYSTEM 権限で侵害されると、ドメイン全体への横移動につながりかねない。 実務への影響と対策ポイント 1. エンドポイント保護の多層化を再確認する パッチ管理だけに依存しない。EDR（Endpoint Detection and Response）ソリューションで異常なレジストリ操作を検知・ブロックする設定になっているか確認しよう。Microsoft Defender for Endpoint を利用しているなら、Attack Surface Reduction（ASR）ルールの有効化状況をチェックしたい。 2. 最小権限の原則を徹底する 特権昇格攻撃が怖いのは「昇格できる出発点がある」からだ。一般ユーザーアカウントに不要な権限が付与されていないか、Windows のローカル管理者グループに不要なアカウントが含まれていないかを棚卸しする良い機会だ。 3. Microsoft の続報・追加パッチを監視する こうした残存脆弱性には後日追加の修正が配布されることが多い。Windows Update の自動適用設定を確認し、セキュリティパッチが遅滞なく展開される運用体制を整えておこう。 4. イベントログ・SIEM 監視を強化する レジストリへの書き込みや変更は Windows イベントログで追跡可能だ。特に HKLM\SYSTEM 配下など、特権に関わるキーへの変更を監視するルールを SIEM に追加することを検討してほしい。 筆者の見解 「パッチを適用したのに脆弱性が残っていた」というニュースは、率直に言って残念だ。KB5089549 を適用した IT 管理者が安堵した直後に、この報告を目にする羽目になる——これは現場の信頼を損なう。 とはいえ、Microsoft には問題を修正する技術力も体制も十分にある。Windows 11 の TPM 2.0 必須化、Smart App Control、カーネルドライバーの署名強制といったセキュリティ基盤の方向性は正しいと思っているし、それだけにこういった「隙間」が残ることがもったいない。正面から勝負できる力があるのだから、修正のサイクルをもう一段速くしてほしいところだ。 ...

MicrosoftはWindows 11の2026年5月更新（May 2026 Update）にて、「Xbox Mode」をデスクトップPC・ノートPC・タブレットへ段階的に展開し始めた。以前は「Xbox Full Screen Experience」としてASUS ROG AllyやLenovo Legion Goといったハンドヘルドゲーミングデバイス向けに先行提供されていたが、今回の更新で一般のWindows 11環境にも広がる。 Xbox Modeとは何か Xbox Modeは、Windowsの上に「コンソールライク」なゲームインターフェースを重ねる機能だ。起動すると全画面表示に切り替わり、コントローラーだけで快適に操作できるUIが展開される。 主な特徴は以下のとおり： 統合ゲームライブラリ: Xbox Game Passのタイトルに加え、他のPCゲームストアのゲームも一画面で一元管理できる コントローラー最適化UI: マウス・キーボードが不要な、コンソール感覚の操作体験 Win+F11で即起動: ショートカットキー一発でWindowsデスクトップとXbox Modeを行き来可能 Windowsの開放性を維持: 閉じたエコシステムではなく、Windowsの柔軟性の上に重ねた形 段階的ロールアウト——すぐには届かない場合も 今回の展開は段階的ロールアウト（Staged Rollout）であり、市場・地域・ハードウェア要件によって受け取れる時期が異なる。 早期に入手したい場合は、「Windows Update」設定で「最新の更新プログラムをすぐに入手する」オプションを有効にし、2026年5月セキュリティ更新（プレビュー版）を手動で確認する方法が有効だ。インストール後は「設定」アプリの「ゲーム」セクションからXbox Modeを有効化できる。 なお、旧称の「Full Screen Experience」を強制的に有効化する方法も引き続き機能しており、段階的展開を待てないユーザーはこちらも選択肢となる。 ハンドヘルドからデスクトップへの戦略的拡張 Microsoftがこのモードをハンドヘルド向けに先行提供していた背景には、コンソールに近い操作体験をWindows上で実現する実験的側面があった。今回の一般PC展開は、その実験が一定の成熟を見せたと判断した結果と読み取れる。 「Xbox」ブランドをPCゲーム体験にも積極的に植え付けていく戦略の一環でもあり、PlayStation PCソフト展開やSteam Deckとの競合という業界トレンドへの明確な回答でもある。 日本のIT現場・ゲーマーへの影響 IT管理者目線では、Xbox Modeは管理対象デバイスへの影響がほぼないと考えてよい。Xbox ModeはWindowsのゲーミングレイヤーに限定した機能であり、IntuneやグループポリシーによるWindowsデバイス管理のフレームワークはそのまま機能する。 一方、PCゲーマーにとっては試す価値がある変化だ。複数のストアにゲームを分散管理していた人にとって、一元化されたライブラリUIは実用的な便利機能となる。特にXbox Game Passを契約しているユーザーなら、コンソールとほぼ同じ感覚でゲームを起動できるようになる点は大きい。 筆者の見解 正直に言えば、Windowsを細かく追うこと自体への関心は年々薄れてきている。それでもXbox Modeには、今回いくつかの意味で注目している。 Microsoftがこれまで「PCゲームはSteamに任せる」的な消極的姿勢を続けてきた中で、Windowsの上にゲーム専用UIを重ねるアプローチは、コンソールとPCの橋渡しとして理にかなった方向性だ。閉じたエコシステムを作るのではなく、Windowsの開放性を保ちながら体験を改善するという姿勢は評価できる。 ただし、今後の成否を決めるのは「Game Passコンテンツの充実度」と「他のPCストアとの統合精度」の2点だ。見せ方よりも中身——コンテンツの質と統合の深さ——に力を入れてほしいところだ。中途半端なまま放置されることが一番もったいない。 PCゲームの体験をここまで本気でXboxブランドで引っ張る覚悟があるなら、ぜひ最後まで本気でやりきってほしい。Microsoftにはその力がある。 出典: この記事は Xbox mode rolls out to Windows 11 PCs in May 2026 update, formerly Full Screen Experience の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

セキュリティ研究者「Chaotic Eclipse」が、Windowsの権限昇格ゼロデイ脆弱性「MiniPlasma」の概念実証（PoC）コードをGitHubで公開した。2026年5月のPatch Tuesdayを適用した完全パッチ済みのWindows 11 Pro環境でも動作が確認されており、標準ユーザー権限からSYSTEM権限への昇格が可能になる深刻な問題だ。 何が問題なのか MiniPlasmaが悪用するのは、Windowsの cldflt.sys（Cloud Filter ドライバー）に含まれる HsmOsBlockPlaceholderAccess ルーティンの不具合だ。このドライバーはOneDriveのオンデマンド同期など、クラウドストレージのプレースホルダー管理に使われているコンポーネントである。 具体的には、ドキュメント化されていない CfAbortHydration APIを通じたレジストリキーの生成処理に問題がある。適切なアクセスチェックなしに .DEFAULT ユーザーハイブ配下へ任意のレジストリキーを書き込める状態になっており、これを足がかりに権限昇格が実現する。 BleepingComputerの検証では、標準ユーザーとしてexeを実行するだけで、SYSTEM権限のコマンドプロンプトが開いたことが確認されている。 「修正済み」のはずが、なぜ今？ 実はこの脆弱性は新発見ではない。2020年9月、Google Project ZeroのJames Forshaw氏がMicrosoftに報告し、CVE-2020-17103として同年12月のPatch Tuesdayで修正済みとアナウンスされていた。 Chaotic Eclipse氏が再調査したところ、「パッチが当たっていない状態と同一の問題がそのまま残っていた」という。Forshaw氏が当時公開したオリジナルのPoCコードが修正なしで動作したと述べており、パッチが最初から機能していなかったのか、あるいは何らかの理由でサイレントにロールバックされたのかは不明としている。 Microsoftは本件について現時点でコメントを出していない。 Insider Preview Canaryでは動作しない 脆弱性アナリストのWill Dormann氏が独立した検証を行い、最新の公開版Windows 11では再現を確認した一方、Windows 11 Insider Preview Canaryビルドでは動作しないことも確認している。これはMicrosoftがCanaryチャンネルで何らかの対応を進めている可能性を示唆しており、正式なパッチが近い将来リリースされることへの期待材料となっている。 連続ゼロデイ公開の背景 MiniPlasmaはChaotic Eclipse氏による一連のゼロデイ公開の最新版だ。過去数週間で以下の脆弱性・ツールが公開されており、そのすべてが実際の攻撃への悪用が確認されている： 名称 概要 BlueHammer（CVE-2026-33825） Windowsローカル権限昇格 RedSun 権限昇格（CVE未採番でサイレント修正） UnDefend Windows Defender サービス妨害ツール YellowKey BitLockerバイパス（TPM-only構成に影響） GreenPlasma 権限昇格 Chaotic Eclipse氏はこれらの公開が「Microsoftのバグバウンティおよび脆弱性対応プロセスへの抗議」であると表明しており、Microsoftから個人的な脅迫を受けたと主張している。脆弱性開示の経緯として異例であることは確かだが、公開されたPoCが悪用されているという事実は変わらない。 日本のIT現場への影響 権限昇格の脆弱性は、それ単体では侵入の入口にはならない。しかし「初期侵害 → 権限昇格 → ラテラルムーブメント」という典型的な攻撃チェーンの中間ステップとして極めて有効であり、標準ユーザー権限でフィッシングマルウェアが実行された後の被害拡大を一気に加速させる。 特に日本企業では「一般ユーザーには管理者権限を与えていない」をセキュリティ対策として強調するケースが多い。しかしこの脆弱性が悪用されると、その境界線を突破できてしまうため、過信は禁物だ。 当面の対応指針： エンドポイントEDR・XDRの検知ルールを確認する — 権限昇格の挙動（標準ユーザープロセスからのSYSTEM権限プロセス生成）を検知できる構成になっているか見直す Windows Insider Preview Canaryでの修正を注視する — Canaryで動作しないことが確認されているため、公式パッチのリリースタイミングをMicrosoft Security Response Center（MSRC）で確認し、リリース次第優先適用する 最小権限の徹底を再確認する — 権限昇格脆弱性の被害を限定するうえで、日常業務における不要な権限の棚卸しは依然として有効な対策 BitLocker設定の見直し — YellowKeyとの組み合わせを考慮し、TPM-onlyのBitLocker構成を使っている端末はPINやネットワークアンロックの追加を検討する 筆者の見解 セキュリティネタは正直あまり好きなジャンルではないのだが、今回の件はWindowsを追う立場として看過できない。 ...

Linuxカーネルの生みの親Linus Torvaldsが、AIツールを使った質の低いバグレポートが急増しセキュリティチームを圧迫していると強く非難し、「ドライブバイコントリビューター（駆け込み貢献者）」に対して大きな変革を要求した。 AI生成バグレポートの洪水が開発を麻痺させる Linuxカーネル開発において、AIツールを活用した低品質なバグレポートが大量に流入し、セキュリティチームが限界に近づいている。Torvaldsはこの状況を深刻な問題として公式に取り上げ、強い言葉で改善を求めた。 かつてバグレポートを提出するためには、コードを深く読み込み、再現手順を確認し、環境情報を整理するという「コスト」があった。そのコストが貢献の品質を担保する自然なフィルターとして機能していた。しかしAIツールの登場により、コードを精読しなくても「それらしいレポート」を量産できる環境が生まれてしまった。 何が問題なのか AI生成バグレポートの主な問題点は以下の通りだ： 偽陽性の急増: 実際には存在しない問題を「バグ」として報告するケースが多発 文脈の無視: コードのロジックや設計意図を理解しない表面的なスキャン結果をそのまま提出 判断不能なレポート: レビュワーが読んでも実害の有無を判断できない低品質な内容 こうしたノイズが大量に流入することで、信号対雑音比（SNR）が下がり、本当に重要な脆弱性が埋もれるリスクが高まる。セキュリティチームのレビュー負荷は激増し、開発のスループット自体が落ちる悪循環に陥る。 ドライブバイコントリビューターとAIの組み合わせが生む構造問題 オープンソースコミュニティには「一度だけ貢献して去っていく」参加者が常に存在する。本来は健全な貢献の形のひとつだ。しかしAIツールがその参入コストをほぼゼロにしたことで、量的・質的なバランスが崩れた。 本物のセキュリティ研究者がコードを深く読み込んで提出するレポートと、AIがコード表面を自動スキャンして生成したレポートは、見た目は似ていても質は天と地ほど異なる。レビュワーはその差を見分けるためにさらに時間を割かなければならない。 実務への影響——日本のエンジニア・IT管理者が注視すべきこと エンタープライズ環境でLinuxを運用する日本のIT管理者にとって、この問題は対岸の火事ではない。 CVEの信頼性低下リスク: AI生成レポートが増えることで、脆弱性情報（CVE）の精度が下がる可能性がある。「CVEが出たから即パッチ」という判断にノイズが混じり込む パッチ優先順位の判断コスト増大: ノイズが多い中で本物のリスクを見極める作業が増え、セキュリティ担当者の工数が増加する パッチリリースの遅延懸念: レビューチームの疲弊は、正式なパッチリリースまでのリードタイムを延ばしかねない Linuxセキュリティアドバイザリの動向を、今後は例年以上に注視する必要があるだろう。 筆者の見解 AIがコードを「それらしく読める」ようになったことで参入コストが下がり、貢献者層が広がるのは本来歓迎すべき変化だ。しかしTorvaldsが声を上げているのは、「量が質を駆逐している」という本質的な問題があるからだ。 AIツールを使うことと、AIの出力を検証せずそのまま流すこととの間には、大きな差がある。生成結果を人間がレビューせず提出するのは、責任を放棄しているに等しい。ツールの出力は「下書き」であり「完成品」ではないという認識が、利用者側に求められる。 この問題はLinuxカーネルに限らない。GitHubやGitLabを使うあらゆるOSSプロジェクトで起きうる構造的な課題であり、今後はバグレポート提出プロセスへの「人間の関与を担保する仕組み」の整備が議論になるだろう。AI活用のルールを早期に設計しないと、オープンソース開発の文化そのものが変質するリスクがある。 AIを「量産ツール」として扱うのではなく、「思考を補助するツール」として使いこなす——その使い手としての成熟が、今まさに問われている。 出典: この記事は Linus Torvalds slams AI-generated bug reports for breaking Linux kernel development の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Windows 11の2026年5月累積更新プログラム（KB5089549）がC:\Windows直下に作成する「SecureBoot」フォルダについて、バグではなく意図的な動作であることを公式に認めた。多くのユーザーが突然出現したこのフォルダに困惑していたが、削除は不要だ。 なぜ今「SecureBoot」フォルダが作られるのか 背景には明確な期限がある。2011年以前に発行されたSecure Boot証明書が、2026年6月に自動失効するのだ。Secure Bootはスタートアップ時に未署名・不正なソフトウェア（マルウェア含む）の読み込みをUEFIファームウェアレベルでブロックする機能で、Windows 11の必須要件でもある。この証明書が期限切れになると、Secure Bootが正常に機能しなくなるリスクがある。 Microsoftはこの期限に向けて「Secure Boot 2023」という新しい証明書セットへの移行を推進しており、KB5089549はその準備の一環としてC:\Windows\SecureBootフォルダを対象デバイスに作成する。 フォルダの中身——7本のPowerShellスクリプト SecureBootフォルダには、Microsoft製の7本のPowerShellスクリプトが格納されている。これらはあくまでIT管理者向けのツールであり、単独では何も変更しない。 主要なスクリプトは以下の2本だ： Detect-SecureBootCertUpdateStatus.ps1 — 新しい2023証明書がインストール済みかどうかを確認し、JSON形式で結果を出力する Enable-SecureBootUpdateTask.ps1 — 証明書を実際に適用するWindowsスケジュールタスクが有効になっているかを確認・有効化する 注意点として、このフォルダはWindows 11 Homeを含む全エディションのデバイスに展開されている。Secure Boot 2023証明書がすでに適用済みの仮想マシンにも作成が確認されている。 一般ユーザーとIT管理者、それぞれがすべきこと 一般ユーザーはこのフォルダを触る必要はまったくない。Secure Boot 2023証明書は、対応ファームウェアを持つデバイスであればWindows Updateの累積更新適用と再起動（1〜2回）によって自動的に更新される。 IT管理者・企業環境では、このスクリプトが活用できる。特に大規模なフリートを管理している場合、Detect-SecureBootCertUpdateStatus.ps1でデバイスごとの証明書適用状況をJSONで収集し、Intune等の管理ツールと組み合わせて一括把握することが可能だ。 証明書の適用状況の確認方法 「Windows セキュリティ」アプリを開き、「デバイス セキュリティ」→「セキュア ブート」を確認する。 緑（問題なし）: Secure Boot 2023証明書が適用済み 黄（注意）: 対応中または部分適用 赤（警告）: 証明書の更新が必要、またはデバイスが非対応 見逃せないリスク——古いファームウェアのデバイス Microsoftは「対象デバイス」と表記しているが、これには重要な但し書きがある。ファームウェアが古いデバイスでは、Secure Boot 2023証明書の適用に失敗するケースが多数報告されている。Microsoftがこれらの非対応デバイスへの対応策を打ち出すかどうかは現時点では不明だ。 企業内に古いPC資産が残っている場合、2026年6月までに棚卸しを行い、非対応デバイスを特定しておく必要がある。 実務への影響——日本のエンジニア・IT管理者が今すぐやること フォルダの確認: C:\Windows\SecureBootが存在しても削除しない。将来の更新で活用される可能性がある ファームウェア更新の確認: PCメーカーのサイトでUEFI/BIOSの最新バージョンを確認し、必要であれば適用する 企業フリートの状況把握: Detect-SecureBootCertUpdateStatus.ps1をIntuneのリメディエーション機能等で一括実行し、対応状況をJSON収集する 期限（2026年6月）のカレンダー登録: 自動更新に任せるにしても、デッドラインを把握しておく ドキュメント更新: Microsoftは当初リリースノートにフォルダ作成の記述がなく、後から追記した。公式文書は常に「最新版」を参照する習慣を 筆者の見解 Secure Boot証明書の自動失効という期限があるにもかかわらず、Microsoftが当初のリリースノートにこの「SecureBoot」フォルダの説明を含めなかったのは、コミュニケーションとしてはもったいない対応だったと感じる。ユーザーや管理者が「謎のフォルダ」として混乱するのは当然であり、最初から「Secure Boot証明書更新準備のためのフォルダ」と明示しておくべきだった。 とはいえ、技術的な方向性は正しい。Secure Bootの証明書をWindowsUpdateと再起動で自動更新する仕組みを整え、IT管理者向けには診断スクリプトで状況を可視化できるようにする——このアプローチ自体はエンタープライズ運用の現実を踏まえた設計だと評価できる。 気になるのは、古いファームウェアのデバイスへの対応が明示されていない点だ。2026年6月の証明書失効は全デバイスに等しく訪れる。ファームウェアが更新できない古いPCが企業内に大量に存在する日本のエンタープライズ環境では、この問題が意外と深刻なケースも出てくるだろう。「Windows Securityアプリで確認できるから大丈夫」という案内だけでは、管理者が気づいたときには手遅れになるシナリオも否定できない。 Secure Bootはブート時のマルウェアをUEFIレベルでブロックする重要な防衛線だ。期限に間に合うよう、今のうちにデバイスの棚卸しを進めることをお勧めしたい。 ...

元Microsoft副社長のMat Velloso氏が、Microsoft 365の4億5,000万ユーザーのうちCopilotの有料シートに移行したのはわずか約1,500万人（採用率3.3%）にとどまると指摘し、Microsoftがインターネットやモバイルに続くAIの波をまた逃しつつあると警鐘を鳴らした。同時期、Windows 11でもCopilotの縮小が進んでいる。 Velloso氏とは何者か Mat Velloso氏は単なる元社員ではない。Microsoftで12年以上勤務し、WindowsのAIイノベーションを担当するパートナーディレクターとして活躍、4年間はSatya Nadella CEOのテクニカルアドバイザーを務めた人物だ。その後、Google DeepMindでGemini APIおよびGoogle AI Studioを担当し、現在はMetaのSuperintelligence LabsでVP of Productを務めている。 Microsoft・Google・Metaの三社でAI開発の最前線を見てきた立場からの発言だけに、業界内で大きな注目を集めている。 数字が語る厳しい現実 Velloso氏が示したデータは以下の通りだ。 Copilot有料採用率：3.3% — Microsoft 365の4億5,000万ユーザーのうち、Copilotの有料シートに移行したのは約1,500万人のみ Bing：検索シェアほぼゼロ — 巨額投資にもかかわらず、Googleからのシェアはほぼゼロのまま GitHub SLA：90%を下回る — AIコーディング革命の中心地であるはずのGitHubの信頼性が低下 NPU搭載PC：ユースケースが存在しない — OEMはNPU対応PCへ大規模投資したが、WindowsおよびOffice上で活用できるキラーユースケースが生まれなかった 特にNPUをめぐる状況は深刻だ。「NPUを搭載したのに使える機能が何一つない」という状態は、デバイスメーカーとエコシステム全体への信頼を揺るがす。Velloso氏は「OEMが投資したのに、誰も気にしていない」と端的に表現している。 Copilotの縮小とDevDiv幹部の退職 Windows 11ではCopilotをタスクバーに常駐させる形で普及を図ってきたMicrosoftだが、その方針が転換されつつある。タスクバーへの統合が縮小される動きは、ユーザーから「押しつけ」と受け取られた反省の表れとも見られる。 これと時期を同じくして、34年間Microsoftに在籍しDeveloper Division（DevDiv）を牽引してきたJulia Liuson氏の退職も発表された。DevDivはGitHub・Visual Studio・Azure DevToolsを統括する中核部門であり、このタイミングでの離脱は単なる偶然ではないとも見られている。 Velloso氏は一連の状況を総括し、Microsoftには「ファクトリーリセット」が必要だと述べた。 日本のIT現場への影響 Microsoft 365管理者・IT部門 3.3%という採用率は、日本企業のIT部門にとっても身に覚えのある数字かもしれない。Copilotライセンスを購入したものの活用が進んでいない組織は少なくないはずだ。 明日からできること： Microsoft 365 Admin Centerで組織内Copilotのアクティブ利用率を確認する 利用されていない理由をユーザーにヒアリングし、具体的な業務ユースケースを設定する 「とりあえず導入」の状態から「業務フローへの統合」へ移行する計画を立てる AI PC・NPU搭載端末の導入を検討中の組織 NPUの恩恵を受けるには、対応したソフトウェアとユースケースが不可欠だ。現時点で「NPU搭載」を導入の決め手にするのは時期尚早である可能性が高い。Windowsのロードマップとユースケースの成熟を見極めながら判断することを推奨する。 開発者・GitHub利用者 GitHub SLAの低下は、CIパイプラインや開発フローに直接影響しうる。ミッションクリティカルなワークフローではフェイルオーバー策や代替手段の検討も現実的な選択肢として視野に入れておきたい。 筆者の見解 Copilotが登場したとき、多くのMicrosoft利用者・支持者がワクワクしたはずだ。AzureのOpenAI統合をはじめ、Microsoftはプラットフォームとして本物の強さを示してきた。問題は、その強さがエンドユーザー体験にまだ転換できていないことだ。 3.3%という採用率は、「使いたくなる体験が設計できていない」ことをシンプルに示している。タスクバーに置くだけでは使われない。「これがないと仕事にならない」と感じさせる体験を作れてこそ、プラットフォームとしての価値になる。 「インターネット、モバイルに続く波を逃した」という表現は厳しいが、Microsoftにはまだ反転の余地がある。4億5,000万のM365ユーザーベース、Azureのインフラ、GitHubの開発者コミュニティ——これだけの資産を持つ企業が本気でユーザー体験の設計に向き合えば、状況は変わりうる。 「ファクトリーリセット」という言葉の本質は、「ユーザーが実際に使いたくなるものを作れ」というシンプルなメッセージだ。Microsoftにはそれをやり遂げる実力がある。WinHECの再開やユーザーフィードバック重視への転換など、変化の兆しは確かにある。その動きが本物かどうか、これから数四半期の製品とデータが答えを出すだろう。 出典: この記事は Former Microsoft VP says Microsoft missed the AI wave like the internet and mobile, as Copilot scales back in Windows 11 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Onyx BOOXが第2世代のE-Inkタブレット「BOOX Go Gen 2 Lumi」をリリースし、海外レビューサイトNeowinが詳細な評価記事を公開した。10インチのE-InkディスプレイにフルスペックのAndroid環境を組み合わせた本機は、ハードウェア・ソフトウェアともに高い評価を受けており、「電子書籍リーダーの枠を超えたAndroidタブレット」として注目されている。 E-Inkタブレットとは何か 一般的なタブレットが液晶（LCD）やOLEDを使うのに対し、E-Ink（電子ペーパー）ディスプレイは電子インクの粒子を制御して表示を作り出す技術だ。主な特徴は次のとおり。 目への負担が少ない：バックライトではなく反射光で表示するため、長時間閲覧でも眼精疲労が起きにくい 圧倒的なバッテリー持続時間：表示の書き換え時のみ電力を消費する構造のため、数日〜数週間の連続使用が可能 直射日光下でも視認性が高い：反射型ディスプレイの性質上、屋外での利用にも強い 従来のE-Inkには「画面書き換えが遅い」という欠点があったが、Go Gen 2 Lumiでは最新世代のE-Inkパネルを採用することでこの課題を大幅に改善している。 Go Gen 2 Lumi の主要スペックと特徴 ハードウェア面 本機の「Lumi」はフロントライト（前面照明）搭載を意味する。従来のE-Inkタブレットは暗所での視認性が課題だったが、フロントライトにより室内環境でも問題なく使用できる。10インチというサイズ感はA5判のノートに近く、スタイラスペンを使った手書きメモにも適している。 プロセッサーにはオクタコアSoCを採用し、Androidアプリの動作に必要な処理性能を確保している。USB-Cでの充電・データ転送にも対応しており、現代的なデバイスとしての使い勝手を維持している。 ソフトウェア環境 フルAndroid環境が動作するため、Kindle、Google Play Books、Notion、OneNoteといった主要Androidアプリがそのまま使用可能だ。BOOXが独自開発したアプリ最適化機能により、液晶向けに設計されたアプリでもE-Inkディスプレイ上での表示品質を高める工夫がされている。コントラストの自動調整やリフレッシュレートのアプリ別設定といった細かい調整機能は、長年E-Inkデバイスを手がけてきたOnyx BOOXならではの強みだ。 なぜこれが重要か 「画面疲れ」という現代の課題 デスクワークで1日8〜10時間、液晶画面を見続けるのが当たり前になった日本のITエンジニアや知識労働者にとって、目への負担軽減は切実な問題だ。E-Inkタブレットは「デジタル環境から離れずに眼精疲労を減らす」という、スマートフォンやPCとは異なるアプローチで注目を集めている。 特に以下のような職種・用途で需要が高まっている。 エンジニア・開発者：技術文書や仕様書の長時間閲覧 研究者・テクニカルライター：論文・原稿の執筆と参照の並行作業 コンサルタント・管理職：移動中の資料確認と会議メモ E-Inkタブレット市場の成熟 Kindle Paperwhiteのような読書専用端末が主流だった市場に、BOOXのようなAndroid搭載の汎用デバイスが本格参入したことで、E-Inkタブレットの利用シーンが大幅に拡張された。第2世代で前世代の課題だった動作のもたつきが改善されたことは、「面白いが実用一歩手前」だったカテゴリが実用段階に入ってきたことを示している。 実務での活用ポイント 知識ワーカーへの実践的提案 技術文書・PDFの精読専用端末として運用：O’Reilly、Manning等の技術書をOPDS経由で取り込む使い方は特におすすめ。目の負担なく長時間の読み込みが可能になる 会議・打ち合わせのメモ取り：スタイラスによる手書きメモはNotionやOneNoteにOCR同期でき、紙のノートと同等のインターフェースでデジタル管理できる コードレビューのリーディング端末：コードを書く用途には向かないが、GitHub PRのレビューや差分確認といった「読む作業」には十分なパフォーマンスがある 導入前に確認すべき注意点 動画コンテンツには不向き：E-Inkの特性上、YouTubeや動画会議はコマ落ちが発生する。動画視聴は別デバイスに委ねるべきだ 反応速度の期待値を調整する：最新世代でも液晶タブレットと同等のレスポンスは期待しない。「読む・書く」に特化した使い方で真価を発揮する アプリ互換性の事前確認：業務アプリによってはE-Ink環境での表示が最適化されていない場合がある 価格対効果 本機の価格帯は上位Androidタブレットと同等〜やや上の水準だ。「目の健康への投資」として考えれば、PC画面を長時間見続けた後にさらに資料を読む必要がある職種にとってはコスト正当化が立ちやすい。 筆者の見解 E-Inkタブレットに対して「面白いが実用一歩手前」という評価が長年続いていたのは、動作のもたつきとAndroidアプリのE-Ink最適化不足によるものだった。実際に初代世代を触ったときに感じた明確な壁は、多くの人が「買ったけど使わなくなった」という結果を招いていた。 Go Gen 2 Lumiのような第2世代デバイスが洗練されてきたことは、このカテゴリが「好き者向けのガジェット」から「真剣に使えるツール」へ転換しつつある証拠だと思う。フロントライト搭載で暗所の弱点を補い、処理性能の向上で動作のもたつきを改善した方向性は正しい。 ただし万人向けではない。自分の作業フローを意識的に設計できる人——「読む・書く作業をここに切り出す」という明確な意図を持てる人——にとって初めて真価を発揮するデバイスだ。「とりあえず買って使う」ではなく、「自分の作業の何割をここに移せるか」を先に問うてから購入を検討する順序が正解だと思う。 AI活用が進み、単純な情報処理はどんどん自動化されていく中で、人間の作業として残るのは「深く読む・深く考える・正確に判断する」という高次の認知作業だ。その文脈で目への負担を下げながら長時間の集中を支援するデバイスの価値は、今後むしろ上がっていくかもしれない。 出典: この記事は BOOX Go Gen 2 Lumi review: E-Ink Android tablet with stunning hardware and rich software の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

フィッシングキット「Tycoon2FA」が、Microsoft 365のOAuthデバイス認証フローを悪用した新たな攻撃手法を展開していることが、セキュリティ企業eSentireの調査で明らかになった。多要素認証（MFA）を有効にしていても被害を受ける可能性があるため、Microsoft 365を使う組織は早急な対策が求められる。 Tycoon2FAとは——摘発後も素早く復活したフィッシングキット Tycoon2FAは、サイバー犯罪者がサービスとして購入・利用できる「フィッシング・アズ・ア・サービス（PhaaS）」プラットフォームの一つだ。2026年3月に国際的な法執行機関による摘発を受けたにもかかわらず、新たなインフラ上にわずかな期間で再構築され、通常の活動水準に戻ったとAbnormal Securityが確認している。それだけでなく、研究者による検知を回避するための難読化レイヤーも強化されている。 今回の調査では、4月末にTycoon2FAがOAuth 2.0のデバイス認可グラントフローを悪用するキャンペーンを展開していることが観測された。Push Securityによれば、このデバイスコードフィッシング攻撃は2026年に入ってから37倍に増加しており、少なくとも10の異なるPhAaSプラットフォームが同手法に対応済みだという。 デバイスコードフィッシングの仕組み——なぜMFAが突破されるのか デバイスコードフィッシングは、テレビやゲーム機など「ブラウザでのログインが困難なデバイス」向けに設計されたOAuth 2.0の正規フローを悪用する。攻撃の流れを整理すると次のようになる。 攻撃者がデバイス認可リクエストを発行: 攻撃者自身がMicrosoftに対してデバイスコードを取得する フィッシングメールでコードを被害者に届ける: Trustifiのクリックトラッキング URLを含む請求書を装ったメールを送付する 多重リダイレクトで本物そっくりのページへ誘導: TrustifiのURL → Cloudflare Workers → 複数の難読化されたJavaScriptレイヤーを経て、偽のMicrosoftのCAPTCHAページにたどり着く 被害者が microsoft.com/devicelogin にコードを入力: ページ上に表示された「デバイスコードを入力してください」との指示に従い、被害者は本物のMicrosoftの認証ページでコードを入力してMFAを完了する OAuthトークンが攻撃者に発行される: Microsoftはトークンを攻撃者の管理するデバイスに発行し、メール・カレンダー・クラウドストレージへの無制限アクセスが成立する ポイントは、被害者が正規のMicrosoftドメイン（microsoft.com）上でMFAを完了している点だ。フィッシングページを疑って確認しても、最後の認証ステップは本物のMicrosoftのページで行われるため、違和感を覚えにくい。 Trustifiのクリックトラッキング悪用とアンチ解析機能 Trustifiは正規のメールセキュリティプラットフォームだが、今回の攻撃ではそのクリックトラッキング機能がリダイレクト中継として悪用されている。eSentireは攻撃者がどのようにTrustifiを利用しているかは特定できていないとしているが、正規サービスのURLを経由させることでメールセキュリティ製品のURLフィルタリングをかいくぐっている可能性がある。 また、Tycoon2FAのキットは研究者・自動スキャナーへの対策が徹底されている。Selenium・Puppeteer・Playwright・Burp Suiteの検出、セキュリティベンダーやVPN・サンドボックス・AIクローラー・クラウドプロバイダーからのアクセス遮断に加え、デバッガータイミングトラップも搭載。ブロックリストには現在230以上のベンダー名が登録されており、随時更新されている。分析環境と判断されたリクエストは、本物のMicrosoftページに自動リダイレクトされるため、解析自体が困難になっている。 実務への影響——日本のIT管理者がいま取るべき対策 MFAを設定済みだからといって安心できないのが今回の攻撃の厄介な点だ。eSentireは以下の対策を推奨している。 すぐに実施できる設定変更 OAuthデバイスコードフローを無効化する: 組織内でデバイスコードフローが必要なシナリオ（テレビ会議端末、ゲーム機など）がなければ、条件付きアクセスポリシーで urn:ietf:params:oauth:grant-type:device_code を明示的に制限する OAuthのコンセント権限を制限する: エンドユーザーが勝手にサードパーティアプリに広範なアクセスを許可できないよう、管理者承認を必須にする 継続的アクセス評価（CAE）を有効化する: トークンが盗まれた後のセッション継続を困難にする 準拠デバイスからのアクセスのみ許可する: Intune管理デバイス以外からのアクセスをブロックする条件付きアクセスポリシーを設定する 検出・監視の強化 Azure AD（Entra ID）のサインインログで device_code フローからの認証を監視する。通常業務では発生しないはずの端末からこのフローが使われていれば、侵害の可能性が高い。Microsoft Sentinel を使用している場合は、デバイスコードフローに関するKQLクエリを検出ルールとして追加することを検討したい。 筆者の見解 「MFAを設定しているから安全」という認識が多くの組織でまだ根強いが、今回の攻撃はその前提を真正面から崩しにきている。MFAはパスワード単体認証よりはるかに強固だが、「認証の仕組み自体を正規フローとして利用する」攻撃には無力だ。 筆者がゼロトラストを推進する立場から言えば、「デバイスを信頼するのではなく、デバイスの健全性を継続的に評価する」仕組みが本質的な防御になる。準拠デバイスポリシーとCAEの組み合わせは、まさにこの考え方の実装だ。設定にある程度の手間はかかるが、「とりあえずMFAだけ」よりはるかに実効性がある。 Microsoft 365はこうした高度な条件付きアクセス機能を提供しており、正しく使えば強力な防御基盤になる。Tycoon2FAのような攻撃が37倍に急増しているいま、その機能を「設定が面倒だから」と放置しておくのはもったいない。プラットフォームの実力を引き出す設定を積み重ねることが、現時点での最善策だ。 「禁止ではなく安全に使える仕組みを」というアプローチで言えば、デバイスコードフローを一律禁止するのではなく、必要な用途だけを明示的に許可する構成が理想だ。ゼロトラストの基本に立ち返り、アクセスの文脈（デバイス・場所・リスクレベル）を組み合わせた判断ができる環境を整えていきたい。 出典: この記事は Tycoon2FA hijacks Microsoft 365 accounts via device-code phishing の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

オープンソースデータベースプロジェクト「Turso」が、自社のバグバウンティプログラムを正式に廃止した。廃止の理由は技術的な限界でも予算不足でもなく、AIエージェントが大量に送りつけてくる無意味・無価値な「CRITICAL」脆弱性報告の洪水だ。 バグバウンティが機能しなくなった背景 TursoはlibSQL（SQLiteのフォーク）をベースにしたエッジ向けデータベースを提供するオープンソースプロジェクトだ。セキュリティ改善のためにバグバウンティプログラムを運営していたが、AI利用が普及するにつれて報告の質が急激に劣化した。 問題の核心は「AIスロップ（AI Slop）」と呼ばれる現象にある。報奨金目的のハッカーたちがAIエージェントにコードを丸投げして自動で脆弱性を探索させ、内容を精査せずそのまま「CRITICAL」として提出するようになった。報告書の体裁は整っているが、実際には的外れ・矛盾だらけ・存在しないコードパスへの言及など、価値ゼロのノイズが大半を占めていた。 開発チームの稼働は有限だ。AIが生成した粗悪なレポートを一つひとつ確認・返答・却下するだけで膨大な時間が失われる。本来のセキュリティ強化に向けるべきリソースが、フィルタリング業務に消えていくという本末転倒な状況に陥ったため、プログラム全体の廃止という判断に至った。 AIスロップ問題がセキュリティに与えるインパクト この現象はTurso固有の問題ではない。セキュリティコミュニティでは「AIを使った脆弱性ハンティングの民主化」が叫ばれる一方で、その副作用として報告品質の急落が各所で問題になりつつある。 バグバウンティプラットフォームの仕組み上、報告者は「とにかく数を出す」戦略が合理的に映る。AIエージェントを使えば1時間で数十件の「それらしい」レポートを生成できる。報奨金がもらえればラッキー、却下されても損失はゼロ、という非対称な構造がAIスロップを量産させている。 真剣に取り組む本物のセキュリティリサーチャーにとっても悪影響は大きい。レビューキューがAIゴミで埋まると、価値ある報告が埋もれてしまいトリアージ効率が著しく落ちる。 実務への影響——日本のエンジニア・IT管理者へ バグバウンティ運営側の視点 バグバウンティを運営している、または検討している組織は、報告フォームへのAI生成コンテンツ対策を今から設計に組み込む必要がある。具体的には： 報告書の最低品質基準を明文化する: 再現手順の動画提出必須、環境情報の詳細記載必須など、AIが苦手な「実証証拠」を要件にする 初回スクリーニングの自動化: 明らかに的外れな報告を人間のレビュー前に弾くルールベースフィルターを設ける 報奨金テーブルの見直し: 低品質報告のコスト（レビュー工数）を報奨金設計に織り込み、「数撃ち戦略」の費用対効果を下げる 開発者・セキュリティエンジニアの視点 AIを使って脆弱性を調査すること自体は悪くない。問題は「AIの出力をそのまま提出する」行為だ。AIが出した候補を人間が検証し、実際に再現できることを確認してから提出する——この一手間が、AIを「ノイズ生成機」から「調査補助ツール」に変える。 またSBOM（ソフトウェア部品表）の整備や依存ライブラリの継続監視など、受動的な脆弱性通知に頼らない自衛策の整備も改めて重要性が増している。 筆者の見解 AIを使った業務効率化に積極的な立場からすると、今回のTursoの判断は皮肉なケースに映る。自動化の恩恵を受けるべきセキュリティプロセスが、自動化の乱用によって機能不全に陥った。 根本にあるのはインセンティブ設計の問題だ。「報告数 × 採択確率 ＝ 期待報奨金」という計算をする人間にとって、AIエージェントは最適解として機能してしまう。これを防ぐには、技術的なフィルタリングだけでなく、構造そのものを変えなければならない。 Non-Human Identity（NHI）の管理や自動化推進の観点でも示唆がある。AIエージェントが外部に向けてアクションを起こす際のガバナンス——何を送信してよいか、品質チェックはどこが担うか——は、セキュリティ報告に限らず普遍的な課題だ。「AIが動ける仕組みを作る」と同時に「AIの出力を人間が検証するゲートをどこに置くか」を設計に組み込まなければ、似たような問題が別の文脈でも繰り返される。 バグバウンティというエコシステム全体が、AI時代の新しい設計に迫られているということだろう。Tursoの撤退を「AIに負けた」と見るのではなく、「次の仕組みを作るためのデータポイント」として業界が学ぶ機会にしてほしい。 出典: この記事は Turso retires bug bounty program because most “CRITICAL” issues are just AI slop の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、ブラウザ「Microsoft Edge」が内部メモリ上にパスワードを平文（暗号化されていない状態）で保持していた問題を公式に認め、修正を最優先課題として対応中であることを発表した。 メモリ上の平文パスワードとはどういう問題か 「平文でメモリに保存」とは、Edgeのプロセスが動作中にパスワードを暗号化せずRAM上に展開していた状態を指す。通常、認証情報はメモリ上でも暗号化された状態で扱うのがセキュリティのベストプラクティスであり、使用後は即座にメモリをゼロクリアすることが推奨されている。 この状態が続くと、以下のような攻撃シナリオが現実的なリスクになる。 メモリダンプ攻撃: ローカル管理者権限や特権プロセスからEdgeのメモリダンプを取得することで、保存済みパスワードが丸ごと読み取れる 悪意あるソフトウェアによる窃取: マルウェアがEDRをすり抜けてプロセスメモリを直接スキャンした場合に認証情報が流出するリスクがある クラッシュダンプへの混入: アプリケーションがクラッシュした際に生成されるダンプファイルにパスワードが含まれ、ダンプを回収できた攻撃者に悪用される可能性がある 実際のところ、この問題は以前からセキュリティ研究者の間で指摘されていた。Microsoftが正式に認め、優先修正として動いた意義は決して小さくない。 修正の方向性と技術的対処 Microsoftは具体的な実装手法を公開していないが、一般的な対処としては以下が考えられる。 Windows Data Protection API（DPAPI）によるメモリ上の暗号化: WindowsがネイティブにサポートするAPIで、ユーザーコンテキストに紐付いた鍵でメモリ上のデータを保護できる 使用後の即時ゼロクリア: パスワード入力や自動入力後にメモリ領域を即座にクリアし、平文データが残存しないようにする SecureString相当の管理: .NETではSecureStringという仕組みがあり、同様のアプローチをEdgeのC++実装に取り込む選択肢もある 修正版はEdgeの通常アップデートサイクルで配信される見込みだ。 実務への影響 — エンタープライズ担当者が今すぐやること アップデート管理の見直し EdgeはMicrosoft Updateを通じて自動更新されるが、グループポリシーや Intune でバージョンを固定している環境では手動対応が必要になる。修正バージョンがリリースされた後、以下を確認すること。 Intuneのデバイスコンプライアンスポリシー: 最低限必要なEdgeバージョンを条件付きアクセスのコンプライアンス要件に組み込む 古いEdgeバージョンの棚卸し: MicrosoftEdge/Update/ レジストリや Intune レポートで組織内のバージョン分布を把握する ASR（Attack Surface Reduction）ルールの活用: Microsoft Defender for Endpointの Block credential stealing from the Windows local security authority subsystem などのルールを有効化し、メモリベースの資格情報窃取を多層防御する Edgeパスワードマネージャーの利用状況を把握せよ 今回の問題はEdge組み込みのパスワードマネージャーを使っているユーザーに直接影響する。エンタープライズ環境では「なんとなくEdgeにパスワードを保存している」社員が相当数いるはずで、IT部門がそれを把握できていないケースも多い。 今回を機に、組織内のパスワード管理ポリシーを見直す絶好の機会だ。業務用パスワードは管理者が制御できるエンタープライズ向けパスワードマネージャーに集約し、Edgeのローカル保存は禁止する方向を検討したい。グループポリシーの PasswordManagerEnabled を無効化するだけで、組み込みマネージャーへの保存を禁止できる。 筆者の見解 2026年のブラウザがパスワードをメモリ上に平文で扱っていたというのは、Microsoft Defenderや Entra ID といった幅広いセキュリティ製品群を持つ同社としては「もったいない」と感じてしまう。セキュリティへの投資をあれだけ打ち出してきた会社が、ブラウザというエンドポイントの最前線でこの実装が残っていたのは素直に惜しい。 ただし、正直に認めて修正に動いた点は評価したい。「知らなかった」「問題ない」で押し切るベンダーより、誠実な対応を選んだMicrosoftの姿勢は信頼の回復につながる。 気になるのは、この問題がいつから存在し、なぜ今まで内部で検出されなかったかという点だ。外部の研究者に指摘されるまで気づかなかったとすれば、メモリ安全性に関する内部レビューフローに改善余地があることになる。MicrosoftはこれをEdge単体の修正で終わらせず、同様の実装が他製品に残っていないかを組織横断でレビューする機会にしてほしい。 ...

Broadcomは2026年5月、macOS向け仮想化ソフトウェア「VMware Fusion Pro 26H1」をリリースした。Apple Silicon（ARM）環境でのESXiゲストOSサポートの追加、Linux系ゲストOSの互換性拡張、そして深刻なセキュリティ脆弱性の修正が今回の主な変更点だ。 ARM ESXiゲストサポートが意味すること 今回の目玉機能は、Apple Silicon Mac上でVMware ESXiをゲストOSとして動作させる「ARM ESXサポート」だ。これはvSphereやESXiを扱うインフラエンジニアにとって重大なアップデートとなる。 これまでApple SiliconのMacユーザーがESXiの検証をしようとすると、x86ベースのマシンを別途用意するか、クラウド上に環境を構築するしかなかった。ARM ESXIゲスト対応により、M1/M2/M3/M4チップを搭載したMacBook ProやMac miniの上で、直接ESXiの動作検証やラボ環境構築が可能になる。 ただし注意点がある。ARM版ESXiはIntel版と完全に同じではなく、ゲスト側のARMネイティブ対応状況やNIC・ストレージドライバーの差異が存在する。あくまで「ラボ・検証用途」として捉えるのが現実的な使い方だ。 拡充されたLinuxゲスト互換性 26H1では、Linuxゲストの互換性リストが更新された。具体的に対応が強化されたのは以下のディストリビューションだ（Fusionのリリースノートに基づく）： Ubuntu 24.04 LTS（Noble Numbat）の正式サポート強化 Debian 13（Trixie）系列の追加対応 RHEL/AlmaLinux/Rocky Linux 9.x 系の最新マイナーバージョン追従 Kubernetesやコンテナ開発用途でmacOSをメインに使いながらLinux VMを日常的に動かしているエンジニアには、アップデートの恩恵を感じやすい変更だ。 重大なセキュリティ修正 今回のリリースで特に注目すべきは「major security fix」の存在だ。BroadcomのセキュリティアドバイザリによりCVEが割り当てられている場合、VMインスタンスの隔離境界に関わるホスト側への影響（VM Escape系）の可能性もある。 Fusion Proを業務環境で使っているユーザーは、セキュリティ修正の詳細をBroadcomのリリースノートで確認し、できるだけ早期にアップデートを適用することを強く推奨する。「VMはゲストだから安全」という発想はVM Escapeの脅威を考えれば成立しない。ホストOS同様の感度でパッチ適用を習慣にしたい。 実務への影響と活用ポイント インフラ・VMwareエンジニア向け: Apple Siliconが普及した現在、開発マシンがARMアーキテクチャに移行している組織では、「Mac上でESXiをテストしたい」というニーズは確実に増えている。ARM ESXiゲスト対応はそのギャップを埋める現実的な手段になる。vSphere環境の設計検証や新機能の事前確認に活用できる。 開発者向け: Docker Desktopと比較してもVMware Fusionはネットワーク構成の自由度が高く、複数VMでのネットワークトポロジー再現が得意だ。マルチノード構成の検証や、本番に近い環境でのテストが必要な場面ではFusionが有利なシーンも多い。 IT管理者向け: Fusion Proはライセンス形態がBroadcomの再編以降に変化しており、無料化された個人利用枠と有償の商用枠が整理されている。社内への展開を検討している場合は、最新のライセンス条件を確認した上で計画を立てることを勧める。 筆者の見解 VMware FusionはmacOS上の仮想化ソリューションとして、長年の実績を持つ信頼性の高いツールだ。BroadcomによるVMware買収後、価格体系や製品ラインアップが大きく変わったことで一時は混乱もあったが、Fusion Proの継続的な機能強化は歓迎できる。 ARM ESXIゲスト対応は、Apple Siliconへの移行が進む国内のIT現場でも実用的な価値がある。ただし、VMの検証環境はあくまで「道具」であって、本番相当の構成テストは相応のハードウェアで行うという基本は変わらない。 セキュリティ修正については、多くのエンジニアが「仮想マシン環境だから」と過信しがちな点でもある。ホストとゲストの境界は完全無敵ではない。パッチ適用の優先度はホストマシンと同等に扱うべきだというのが個人的な一貫したスタンスだ。アップデートを後回しにしないこと、これに尽きる。 出典: この記事は VMware Fusion Pro 26H1 released with support for more guest OSes の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

世界最高峰のハッキング競技会「Pwn2Own 2026」において、セキュリティ研究者たちがWindows 11、Microsoft Edge、Microsoft Exchangeに対するゼロデイ脆弱性の悪用に次々と成功し、多額の賞金を獲得した。AIアプリケーションも攻撃対象となり、現代のソフトウェアスタック全体に深刻な問題が潜んでいることが改めて浮き彫りになった。 Pwn2Ownとは何か Pwn2Ownは、Trend MicroのZero Day Initiative（ZDI）が主催する年次のハッキング競技会だ。参加者は「これまで公開されていないゼロデイ脆弱性」を使って対象製品の侵害を実演し、成功すれば数万〜数十万ドル規模の賞金を獲得できる。競技後はベンダーに脆弱性が報告され、パッチが提供されるという流れが確立されている。 単なるショーではなく、業界全体の「脆弱性発見サイクル」として機能している点が重要だ。研究者にとっては報酬と名声を得る場であり、ベンダーにとっては本番環境が狙われる前に脆弱性を修正できる機会になる。 今回の標的となったMicrosoft製品 今回のPwn2Own 2026では、Microsoft製品が複数の攻撃成功事例を記録した。 Windows 11 は依然としてハッカーの主要ターゲットであり続けており、権限昇格や任意コード実行につながるゼロデイが実証された。Microsoft Edge はChromiumベースのモダンブラウザーであるにもかかわらず、サンドボックス脱出を含む脆弱性が発見された。Microsoft Exchange は企業メールインフラの中核を担うにもかかわらず、リモートコード実行の可能性を示す脆弱性が実演されている。 さらに今回の特徴として、AIアプリケーションも攻撃対象に含まれており、急速に普及するAIツールのセキュリティ検証がいかに追いついていないかを示す結果となった。 ゼロデイが持つ意味――「今は安全」は幻想 ゼロデイ脆弱性とは、ベンダーが把握していない（あるいはパッチが存在しない）未公開の欠陥を指す。Pwn2Ownで実証されたということは、その脆弱性がMicrosoftに報告されて初めて修正プロセスが始まることを意味する。競技後にZDIからMicrosoftへ通知が行き、通常90日以内のパッチ提供が求められる。 つまり、現時点では「脆弱性は存在するが、パッチはまだない」という状態だ。 実務への影響――日本のIT管理者が今すべきこと Pwn2Ownの結果は「研究者の遊び」で終わらない。以下の対応を即座に検討すべきだ。 Windows Update の適用状況を確認する: ゼロデイが修正されたパッチがリリースされ次第、迅速に適用できる体制を整えておく。特にExchangeはオンプレミス運用の場合、更新が遅れがちな環境が多い。 Exchangeのオンプレミス運用を再評価する: Exchange Onlineへの移行が進んでいる場合、Microsoftがクラウド側でパッチを適用するため管理負荷は大幅に下がる。オンプレミスExchangeを引き続き運用している組織は、今回の結果を移行検討の材料として活用してほしい。 ネットワーク分離と最小権限の徹底: ゼロデイは防ぎきれない前提で動くことが重要だ。攻撃が成功してもラテラルムーブメント（横展開）を防ぐために、ネットワークセグメンテーションと最小権限の原則を徹底する。 AIアプリのセキュリティ評価: 社内で利用中のAIツールについて、セキュリティ評価なしに展開していないか確認する。今回の競技でAIアプリが攻撃対象に含まれたことは、その必要性を裏付ける。 筆者の見解 Pwn2Ownで毎年Microsoftの製品が実証されることは、もはや驚くに値しない。それよりも注目したいのは、Microsoftがこのサイクルに真剣に向き合い続けている点だ。報告された脆弱性に対して90日以内にパッチを提供する枠組みは機能しており、その点は正当に評価できる。 ただ、Exchangeのオンプレミス版が繰り返しターゲットになる現状は、もったいないという思いがある。Microsoftにはクラウドファーストへの移行を強力に後押しできるだけのブランド力とプラットフォームがある。それを活かしきれていないオンプレミスExchangeの延命策が、かえってユーザーのリスクを高めているように見える。 セキュリティは「今動いているから大丈夫」では通用しない。ゼロデイは「発見されていないだけ」の状態が続いているに過ぎない。今回のPwn2Ownの結果を受けて、特にオンプレミスインフラに依存している日本の企業には、クラウド移行やネットワーク設計の見直しを真剣に検討するきっかけにしてもらいたい。 出典: この記事は Windows 11, Microsoft Edge, and Exchange hacked at Pwn2Own の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Windows Hardware Engineering Conference（WinHEC）2026において、Driver Quality Initiative（DQI）を正式発表した。長年「クラッシュしなければ合格」とされてきたWindowsドライバーの品質基準を抜本的に見直し、バッテリー消耗・発熱・パフォーマンス低下も評価指標に加える歴史的な転換だ。 ドライバーが「静かにPCを壊していた」構造的問題 Windowsのドライバー品質評価は数十年にわたり、Windows Error Reporting（WER）のクラッシュデータにほぼ一任されていた。ブルースクリーン（BSOD）を引き起こさない限り、グラフィックス・Bluetooth・オーディオドライバーは「安定している」と判断され、数百万台のPCに配布されてきた。 しかしこのアプローチには深刻な盲点があった。クラッシュしなくても、ユーザー体験を静かに破壊するドライバーが堂々と認証を通過していたのだ。 高DPC（Deferred Procedure Call）レイテンシ: 最適化の甘いネットワークドライバーがCPUサイクルを独占し、オーディオのプチプチノイズやゲームのフレーム落ちを引き起こす Modern Standby中のバッテリー消耗: Wi-FiドライバーやストレージコントローラーがCPUの省電力ステート（C-state）への移行を妨害し、カバンの中でバッテリーを使い切ってしまう 原因不明の発熱: スリープしているはずなのにPCが熱くなり、取り出したら本体が触れないほど熱かった、という経験を持つ人も多いだろう これらはすべて、従来の基準では完全に「合格」だった。クラッシュしていないからだ。 WinHEC 2026が変えた「品質」の定義 DQIの「Quality Measures」ピラーでは、評価指標が大幅に拡張された。Microsoftが公式に示した新しい測定対象は次の通りだ。 評価軸 内容 安定性（Stability） 従来のクラッシュ・ハング検出（継続） 機能性（Functionality） ドライバーが設計通りに動作しているか パフォーマンス（Performance） DPCレイテンシや応答速度 電力・熱への影響（Power and Thermal Impact） Modern Standby中のバッテリー消耗と発熱 この変更により、クラッシュを一切引き起こさないドライバーでも、電力効率が悪いというだけで「低品質」として分類される。OEMメーカーにとっては、Windows認証を通過するだけでは不十分になるということを意味する。 Modern Standbyとは何か——問題の核心 Modern StandbyはWindowsのスリープ技術で、スマートフォンのように「画面を閉じても低電力で待機し、必要なときだけ一部コンポーネントを起動する」設計だ。メール受信やシステム更新などを行いながら、CPUはC-stateと呼ばれる深い省電力状態に入ることで消費電力を極限まで抑える。 問題は、Wi-Fiドライバーやストレージコントローラーが不適切な実装だと、CPUがC-stateに移行できなくなる点にある。CPUが「忙しい」ふりをしている間、発熱と電力消費が続く。「会議前にカバンに入れておいたノートPCが熱くなってバッテリーが空だった」という経験は、まさにこの問題の典型的な症状だ。 日本のエンジニア・IT管理者への実務的影響 法人PC管理者へ DQIはドライバーの品質スコアに基づいてWindows Updateの配信優先度を変更する可能性がある。企業環境では以下の点を押さえておきたい。 ドライバー管理ポリシーの見直し: Windows Update Business（WUfB）やIntune経由でドライバー更新を管理している組織では、DQIスコアが高いドライバーが優先配信されるようになる可能性がある モバイルワーカーへの恩恵: 外出先でのバッテリー消耗クレームは、DQI導入後のドライバー更新が積み重なることで徐々に改善されると期待できる 新規PC調達時の基準: 今後はWinHECのDQI認証状況をOEM選定の一指標として活用することも考えられる ドライバー開発者・ハードウェアベンダーへ 電力・熱のプロファイリングが必須工程になる。Windows Hardware Lab Kit（HLK）のテスト項目が拡張されることが予想されるため、開発・検証フローの見直しを早めに着手したい。特にModern Standbyの動作検証ツール（SleepStudy、powercfg /sleepstudy）を活用した定量評価が重要になる。 出典: この記事は Microsoft admits Windows 11 drivers were quietly killing your battery and performance without crashing, closes the loophole の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年5月14日、Windows 11においてタスクバーの位置変更（下部または左側）と縮小表示機能をWindows Insiderプログラムのテスターに提供開始した。同社はスタートメニューのサイズ変更やセクション非表示機能も開発中であり、Windows部門トップのPavan Davuluri氏は「パーソナライズとカスタマイズはWindowsのDNAにある」と宣言している。 Windows 11が「カスタマイズ」を取り戻す背景 Windows 11は2021年10月のリリース以来、ユーザーから根強い不満を受け続けてきた。タスクバーを移動できない、スタートメニューのサイズを変更できない、Recommendedフィードを非表示にできない——こうした「できて当然の操作」が封印されたまま約5年が経過した。 ソーシャルメディアでは「Microslop（マイクロスロップ）」という皮肉なハッシュタグが広まり、Windowsへの失望感が可視化された。これを受け、Satya Nadella CEOを含む経営陣が「Windowsファンを取り戻す」と公言。2026年3月にはWindows 11の品質向上を公式にコミットし、ようやく具体的な改善が動き出した。 今回提供される主な変更点 タスクバーの移動・縮小 Insider Preview向けに展開が始まったのは、以下の2機能だ。 タスクバーの位置変更: 従来の下部固定から左側への移動が可能になった。左側配置時は縦型タスクバーとなり、ワイドスクリーン環境での縦方向の作業領域を広げる効果がある タスクバーの縮小表示: アイコンサイズを小さくすることで、特に左側配置時に画面を有効活用できる ただし現時点では、左側移動時にスタートボタンやアイコンの整列がずれる、通知が新しい位置に追従しないといったバグが確認されている。Microsoftは一般公開前にこれらを修正する予定としている。 スタートメニューのカスタマイズ スタートメニューにも大きな変化が来る。 サイズ変更: 「小」「大」の2段階から選択可能（今後さらに細かい選択肢も検討中） セクションの非表示: アプリ一覧やおすすめ表示など、不要なセクションを個別にオフにできるようになる なお、Windows 10では標準だったスタートメニューのドラッグによるリサイズは廃止されたままで、今回は固定プリセットによる切り替えとなる。 実務への影響 エンジニアやIT管理者の観点では、これらの変更は主にユーザー生産性の向上とヘルプデスク負荷の軽減に貢献しうる。 マルチモニター環境や縦長ディスプレイを使うユーザーには、タスクバーの左側配置は実用的な変更だ。縦型タスクバーはコーディングや文書作成で縦スクロール量を減らす効果もあり、特に開発者には受け入れられやすい。 一般公開のタイミングはバグ修正の進捗次第だが、組織内にWindows Insiderプログラムに参加できる検証環境があれば、展開前のフィードバック収集に活用する好機でもある。グループポリシーでInsiderチャンネルを制御している場合は、Beta チャンネルへの一時的な切り替えも検討に値する。 筆者の見解 率直に言えば、「なぜ2021年に削除したのか」という疑問は今も残る。タスクバーの移動やスタートメニューのサイズ変更は、Windows 10時代には当然できた操作だった。それを削除したのはMicrosoft自身であり、ユーザーは5年近くその不便さと付き合い続けてきた。 とはいえ、今回の動きは正しい方向だ。「ユーザーが求めているものに耳を傾けて元に戻す」という判断は、決して簡単ではない。Davuluri氏の「フィードバックを読み、Windows Insiderと会い続けた」という言葉が、今回のように具体的な機能として結実したのは評価できる。 ただ、OSの差別化がアプリケーション層やAIサービス層に移っていく中で、「タスクバーの位置を変えられる」というUI改善がどこまでWindowsの競争力に直結するかは正直なところ疑問が残る。それでも、ユーザーの声を無視してAI機能を押し込む路線から、基本的な使いやすさを取り戻す路線へ転換した点は、Microsoftが本来持っている「ものを作る力」を思い出しつつあるシグナルとして受け取りたい。Copilotの話は一旦置いておいて、こういう地道な改善の積み重ねがWindowsへの信頼を少しずつ回復させていくはずだ。 出典: この記事は Microsoft admits customization is in Windows’ DNA, promises new Windows 11 controls の内容をもとに、筆者の見解を加えて独自に執筆したものです。