Windows

Microsoftは2026年5月、Microsoft Teamsの会議中UIが「過密（crowded）」になっており誤操作の原因になっていると公式に認め、誤った画面共有を防ぐための大規模なUI刷新を発表した。 なぜ今、Teamsの会議UIが問題になっているのか Teamsは長年にわたって会議機能を次々と追加してきた結果、会議コントロールバーが複雑化し、「Share（共有）」「Leave（退出）」「Raise hand（挙手）」といった重要操作ボタンが密集配置されてしまっていた。 Microsoftは管理センターへの投稿で次のように認めている：「会議コントロールと共有パネルは過密状態になっており、Share、Leave、Raise handといった影響の大きい操作間での誤クリックや、意図しないコンテンツの誤共有を引き起こしています」 誤退出や誤挙手はまだ取り返しがつくが、意図せぬ画面共有はそうもいかない。給与明細や社外秘資料、プライベートなウィンドウが全参加者に丸見えになる——そんなインシデントが実際に起きてきた背景がある。 何が変わるのか——刷新の主要ポイント 1. 会議コントロールのセンター整列と再配置 マイク・カメラ・共有オプションをグループ化してセンター配置に変更。Leaveボタンを誤タップされにくい位置に移動し、利用頻度の低い機能は新設の「More」メニューに集約される。また、ドラッグ＆ドロップによってコントロールバーの項目を自分好みに並べ替え、ピン留めできるようになる。 2. 共有パネルのリデザイン——事前プレビューと2段階確認を追加 新しい共有パネルでは、画面・ウィンドウの一覧をサムネイルプレビュー付きで表示し、選択した画面の大きなプレビューを確認できる。「Content only」「Standout」「Reporter」「Side-by-side」などのプレゼンテーションモードを選んだうえで、最後に「Share」ボタンを押す2段階確認フローが導入される。 これにより、うっかり共有ボタンを押しただけで機密資料が全員に表示される事故を構造的に防げる。 3. 展開スケジュール フェーズ 時期 ターゲットリリース（早期展開テナント） 2026年7月 一般展開（GCC・GCC High含む） 2026年8月 国防省（DoD）環境 2026年10月 機能はデフォルトでオンになる予定で、管理者側での特別な有効化作業は基本的に不要とのこと。 実務への影響——日本のエンジニア・IT管理者にとっての意味 誤画面共有のリスクが構造的に解消される点が最大の恩恵だ。特に大人数の商談や重要な役員会議での誤共有はインシデントに発展しかねず、情報セキュリティポリシー上の問題にもなる。 IT管理者としては以下の点を事前に把握しておきたい： デフォルトオンで展開されるため、ユーザーへの事前周知が重要。7〜8月のUIリニューアルに向けて「Teams会議の画面が変わります」という社内アナウンスを準備しておくと混乱を最小化できる GCC・GCC High環境も8月対象。政府機関・教育機関向けコンプライアンス環境を運用する管理者は、該当テナントの展開タイミングに注意が必要 カスタマイズ可能なコントロールバーを活用し、組織でよく使う機能を前面に出した標準レイアウトをTeamsポリシーで統一設定することも検討に値する エンドユーザー向けには、「新しいShareパネルは一手間増えるが、それが誤共有防止の仕組みだ」と事前に説明しておくとスムーズに移行できる。 筆者の見解 正直に言えば、「これ、もっと早く気づけたのでは」という思いはある。「Share」ボタンと「Leave」ボタンの近接配置については、ユーザーコミュニティで以前から指摘されてきた問題だ。機能を追加するたびにUIの整合性を検証するサイクルが、どこかで弱くなっていたのだろう。 とはいえ、今回の対応には評価したい部分がある。Microsoft自身が「UIが過密で誤操作の原因だ」と公式に認めたこと、そして「確認ステップ」という構造的な安全策を組み込んだことは正しい方向性だ。言い訳せずに問題を認め、改善策を具体的に示す姿勢は素直に好感が持てる。 Teamsはビジネスコミュニケーション基盤として企業に深く根ざしており、こうした「使いやすさの地道な改善」が積み重なることで現場の信頼につながっていく。2026年8月の展開が実際にどう受け入れられるか、引き続き注目したい。 出典: この記事は Microsoft admits Teams UI is crowded and causes embarrassing accidental screen shares, confirms a fix の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft が Windows 11 24H2 以降において、ノートPCのふたを閉じたり電源ボタンを押したりスタートメニューから「スリープ」を選んだりした際に音声再生が停止する仕様変更を静かに実施していたことが明らかになった。 何が変わったのか Windows 11 23H2 以前では、ノートPCのふたを閉じても音楽やポッドキャストの再生は継続されていた。Spotify で音楽を流しながら作業を中断してふたを閉じても、再生は止まらなかった。 しかし Windows 11 24H2 または 25H2 に更新したPCでは、この動作が変わっている。ふたを閉じた瞬間に再生が一時停止し、PCが復帰すると即座に再開する仕様だ。 Microsoft は公式ドキュメントでこの変更を認めており、次のように説明している： 「Windows 11 バージョン 24H2 以降、電源ボタンの押下・ふた閉め・スタートメニューから明示的にスタンバイに入った場合、音声再生はサポートされない。音声再生がサポートされるのは、アイドル状態からスクリーンオフになる場合のみ。」 音声が継続されるケースとされないケース 整理すると、音声再生の可否は次のとおりだ： 状態 音声再生 アイドルによる自動スクリーンオフ 継続される ふた閉め 停止される 電源ボタン押下 停止される スタートメニュー → スリープ 停止される 重要な点として、AC電源接続中でも DC（バッテリー駆動）でも、明示的スタンバイ時の音声停止は同様に適用される。Bluetooth スピーカーも内蔵スピーカーと同様の制限を受ける。 Modern Standby とは何か Modern Standby（旧称: Connected Standby）は、スマートフォンのような「常時接続型スリープ」を実現する機能だ。従来の S3 スリープ（ハードウェアレベルで完全停止）とは異なり、スリープ中も一部のネットワーク通信やバックグラウンド処理を維持できる。 メリットは即時復帰とメール・通知のリアルタイム受信。一方でデメリットとして、S3 スリープと比べてバッテリー消費が多いと長年批判を受けてきた。今回の変更は、このトレードオフを改善するための地道な取り組みの一環だ。Microsoft は加えて、Modern Standby 中の予期しない「ウェイクアップ」や過剰なバッテリー消費を防ぐポリシーも最近追加している。 従来の動作に戻す方法 どうしてもふたを閉じたまま音声を継続したい場合は、ふたを閉じたときの動作を「スリープ以外」に変更すればよい。 設定手順： コントロールパネル → 電源オプション → 「カバーを閉じたときの動作の選択」 「カバーを閉じたとき」を「何もしない」に変更 ただし、この設定は Modern Standby による省電力効果を損なう可能性があるため、常用は推奨しない。また、Modern Standby 非対応の旧世代ノートPC（S3 スリープを使うデバイス）では今回の変更の影響を受けない。 ...

Microsoftは2026年5月15日、Windows 11 Insider Experimentalチャンネル向けにプレビュービルド26300.8493を公開した。今回のビルドで最も注目すべきは、Windowsカーネルがサードパーティのクロス署名ドライバーをデフォルトで信頼しなくなるというセキュリティポリシーの大幅な変更だ。 カーネルドライバー信頼ポリシーの刷新——何が変わるのか これまでWindows 11では、Microsoftのルート証明機関（CA）でクロス署名されたサードパーティ製ドライバーであれば、カーネルレベルで動作することが許可されていた。今回のビルドから、この扱いが根本から変わる。 信頼されるドライバーの条件（新ルール）: Windows Hardware Compatibility Program（WHCP）認定を取得したドライバーのみ、デフォルトで信頼 クロス署名のみのサードパーティドライバーは、デフォルトでは信頼されない WHCPとはMicrosoftが運営するハードウェア互換性認証プログラムであり、ドライバーの品質・セキュリティ・安定性が審査される。認定を受けたドライバーはMicrosoftが署名を行うため、クロス署名とは別物だ。 この変更により、カーネルレベルへの不正アクセスを試みるルートキットや悪意あるカーネルドライバーの侵入経路が大幅に絞られる。これはSmart App Controlや「カーネルドライバー締め出し」の流れと完全に一致した施策だ。 タスクバーの大幅刷新——位置変更・小型化が正式機能へ セキュリティ以外では、長年のユーザー要望だったタスクバーのカスタマイズ機能が拡張された。 タスクバーの位置変更: 設定 > 個人用設定 > タスクバー > タスクバーの動作から、下・上・左・右の4か所を選択可能に ツールチップ・フライアウト・アニメーションは選択した位置から表示される 小さいタスクバーアイコンや「アイコンを結合しない」設定も引き続き利用可能 タッチジェスチャー対応・検索ボックス・「Copilotに質問」の対応は開発中 小型タスクバー: タスクバーの動作 > タスクバーボタンを小さく表示するで常時有効化可能 アイコンサイズとタスクバーの高さが両方縮小し、画面領域を有効活用できる 特に小型デバイスでの作業効率向上に貢献 Widgetsのバッジカラー変更: 通知バッジの色が従来の「常に赤」から、Windowsのアクセントカラーと一致するように変更 「何か緊急事態が起きている」という視覚的プレッシャーを軽減する意図 ウィジェットをほとんど使わないユーザー向けに、タスクバーバッジを自動的にオフにする実験も進行中 Windows検索ボックスの改善: ローカルのファイルやアプリが、Web候補より確実に上位に表示されるよう改善 実務への影響——日本のエンジニア・IT管理者が今すぐ確認すべきこと このドライバーポリシー変更は、Insiderビルドでの先行テスト段階ではあるが、将来の正式リリースに向けて企業環境での影響確認は今から始めるべきだ。 確認すべきポイント: 利用中のサードパーティ製ドライバーのWHCP認定状況を確認する セキュリティソフト（EDR含む）、ネットワークアダプター、産業機器ドライバー等はリスクが高い ベンダーに問い合わせ、WHCP認定版への更新スケジュールを確認する 古いハードウェアを抱える環境は特に注意 製造業・医療・官公庁など、長期運用が前提の環境では非認定ドライバーが多く残っている可能性がある Experimentalチャンネルでの動作検証を早期に実施しておくべき ポリシー変更はデフォルト設定の話 企業GPOやWindowsカーネル設定で信頼ポリシーをカスタマイズできる仕組みは残ると予想されるが、公式ガイダンスを待って判断すること タスクバーの位置変更機能は業務端末への影響を評価する 既存の業務アプリがタスクバー位置を前提に設計されている場合、表示崩れの可能性がある 筆者の見解 カーネルドライバーのデフォルト非信頼化は、Microsoftが長年取り組んできたカーネル保護の集大成とも言える方向性だ。ルートキット対策としての効果は高く、この施策自体は明確に正しい。「ゼロトラストはネットワークだけの話ではない」という原則をOSレベルで体現した変更として評価できる。 一方で、企業の現場で問題になるのは「理念の正しさ」より「移行コスト」だ。WHCP認定を取得していないドライバーをいまだに使い続けているシステムが、日本の製造業・医療・官公庁には少なくない。正式リリースまでの猶予期間をどう使うかが、IT管理者にとっての現実的な課題になる。 Microsoftはこういった変更を「Experimentalチャンネルで十分に時間をかけてテストする」スタイルを採るようになってきており、その姿勢は正しい。あとは企業向けの移行ガイダンスと、ベンダーのWHCP認定取得支援をどれだけ丁寧に整備できるかにかかっている。強化の方向性は応援したい。問題が起きるとしたら技術の話ではなく、現場への伝え方の話だ。 出典: この記事は Windows 11 Insider Experimental Preview Build 26300.8493 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Mozillaは公式ブログにて、Intel第13世代（Raptor Lake）および第14世代（Raptor Lake Refresh）搭載システムでFirefoxが突然クラッシュする事象の原因を詳細に解説した。根本原因はFirefox自体のバグではなく、Intel CPUのハードウェアレベルの安定性問題にあることが明らかになった。 Intel Raptor Lakeの「隠れた時限爆弾」 Intelの第13・14世代Core プロセッサー（開発コード名：Raptor Lake）には、製造段階に起因するとされる電圧制御の不具合が存在する。具体的には、eTVB（enhanced Thermal Velocity Boost）機能が不正な高電圧リクエストをCPUコアに送り続けるという問題で、これによりCPUが仕様外の状態で動作し、演算ミスや不意の停止を引き起こす。 Intelは2024年8月にマイクロコードアップデート（第13世代向け：0x125、第14世代向け：0x129）を公開して対処したが、アップデートを適用していないシステムでは依然として問題が発生しうる。 なぜFirefoxが特に影響を受けるのか Mozillaの調査によると、FirefoxはそのJavaScriptエンジン（SpiderMonkey）やレンダリングエンジン（Gecko）がCPUの演算処理を高頻度かつ並列的に行う設計であるため、Raptor Lakeのわずかな演算ミスが致命的なクラッシュとして表面化しやすいという。 一般的なオフィスアプリケーションでは演算ミスが気づかれないままスルーされる場合もあるが、ブラウザのJITコンパイラ（実行時コンパイル）はCPUの計算結果を厳密に使用するため、わずかなビットエラーがプロセス全体の異常終了に直結する。 Mozillaは現象を特定するため、クラッシュレポートの統計解析を実施。第13・14世代CPU搭載ユーザーから寄せられたクラッシュが異常な頻度を示しており、特定のハードウェア世代への集中が統計的に有意であることを確認した。 影響範囲と確認方法 影響を受けるのは主に以下の環境： CPU: Intel Core i-13000シリーズ（第13世代）、Core i-14000シリーズ（第14世代） 症状: Firefoxの突然のクラッシュ、特に複数タブを開いている状態やJavaScript負荷が高いサイト閲覧中 マイクロコード未適用のシステム: BIOSアップデートが行われていないPCが特に危険 自分のCPUがどの世代かは、Windowsであれば「タスクマネージャー → パフォーマンス → CPU」で確認できる。また、BIOSのバージョン確認は msinfo32.exe から「BIOSバージョン/日付」を参照する方法が簡単だ。 実務への影響——IT管理者が今すべきこと 1. マイクロコードアップデートの展開を急ぐ 企業環境で第13・14世代Intel CPUを導入済みの場合、BIOSアップデートの展開が最優先だ。各PCメーカー（Dell、HP、Lenovo等）はすでにIntelのマイクロコード修正を含むBIOSアップデートを公開済みであるため、管理コンソール（SCCM、Intune等）からのリモート展開を検討したい。 2. Firefoxを社内標準ブラウザとして利用している場合 ヘルプデスクへの「Firefoxが落ちる」という問い合わせが増えている場合、Firefoxの問題ではなくハードウェア起因である可能性を念頭に置く。安易に「Chromeに変えてください」で済ませてしまうと、根本問題が放置されたまま他のアプリケーションにも影響が波及しかねない。 3. 新規調達時の注意点 中古PC市場や既存在庫での第13・14世代CPU搭載機を調達する場合、受け入れ時にBIOSバージョンを必ず確認し、マイクロコードアップデート適用済みであることを検証する手順を導入することを推奨する。 4. 一時的な回避策 すぐにBIOSアップデートが適用できない環境では、Firefoxの設定でハードウェアアクセラレーションを無効化する（設定 → 一般 → パフォーマンス → ハードウェアアクセラレーションのチェックを外す）ことでクラッシュ頻度を下げられる場合がある。ただしこれは根本解決ではない。 筆者の見解 Mozillaの今回の対応は、ソフトウェアベンダーとして模範的だと思う。「うちのブラウザの問題です」と言いたくなるプレッシャーがある中で、きちんとハードウェア起因であることを調査・公開した誠実さは評価したい。 それよりも問題なのは、このIntel Raptor Lakeの不具合がいまだに多くの現場で放置されているという現実だ。2024年8月にマイクロコードパッチが出てからすでに相当の時間が経過しているが、BIOSアップデートが展開されていない企業PCは日本でも相当数あるはずだ。「今のところ大きなトラブルが起きていないから」という判断は、今回のFirefoxクラッシュのように突如として問題が顕在化するリスクを抱えたままにしておくことを意味する。 ゼロトラストやエンドポイントセキュリティを強化しても、CPUレベルで演算ミスが起きているハードウェアの上で動かしているのでは基盤が揺らいでいる。ファームウェア管理は地味だが、インフラの基礎体力に関わる重要な作業だ。「今動いているから大丈夫」は今後も通用しないことをあらためて思い知らされる事例だった。 出典: この記事は Mozilla explains Firefox crashes on Intel 13th, 14th Gen Raptor Lake systems の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Windows 11の2026年5月累積更新プログラム（KB5089549）により、これまで一部のデバイスに限定されていた「Xboxモード」が、すべてのWindows 11搭載PCに正式展開された。コントローラー優先のフルスクリーンゲームダッシュボードがPCで利用可能になり、ハンドヘルドゲーミングPCにも対応する。 Xboxモードとは何か Xboxモードは、Windows PCをコンソールゲーム機のような操作感で使えるようにするUIレイヤーだ。Win + F11キーを押すと起動し、コントローラー操作を前提に設計されたフルスクリーンのゲームダッシュボードが表示される。 ダッシュボードからは次の操作が可能だ： Xbox Game Passのゲームライブラリの閲覧・起動 Microsoft Storeからのゲームインストール フレンドのオンライン状態の確認 アチーブメント・ゲーム統計の閲覧 対応デバイスはノートPC・デスクトップPC・タブレット、そしてAsus ROG AllyやLenovo LegionシリーズのようなハンドヘルドゲーミングPCまで幅広い。通常のデスクトップとの行き来はWin + F11で即座に切り替えられるため、作業中に瞬時にゲームモードへ移行するといった使い方ができる。 更新の適用方法 KB5089549はWindows Updateから通常通り配信されており、Windows 11を搭載したすべてのデバイスが対象となる。適用後は「設定 → ゲーム」からXboxモードの有効化状態を確認できる。 既存のXbox Game Passサブスクリプションがあれば追加費用は不要。ゲームダッシュボードはMicrosoftアカウントにサインインした状態で使うことで、実績・フレンドリスト・ゲームライブラリとシームレスに連携する。 ハンドヘルドPCへの最適化という意図 今回の展開で特に注目すべきは、ハンドヘルドゲーミングPCへの正式対応だ。Valve社のSteam DeckがSteamOSのコンソールライクなUIで高い評価を得てきたのに対し、Windows搭載のハンドヘルドPCはその操作感の差が長らく課題として指摘されてきた。 Xboxモードはその差を縮める存在になりうる。物理コントローラーを搭載するハンドヘルドPCにとって、コントローラー前提のUIが標準機能として用意されることは実用面で大きな意味を持つ。日本市場でもAsus ROG Ally XやMSI Claw、Lenovo Legion Goなど複数のWindows搭載ハンドヘルドが販売されており、このモードによりゲームプレイ体験の底上げが期待できる。 実務への影響 エンタープライズ・IT管理者の観点では、Xboxモードはコンシューマー向けの機能であり、業務用PCへの直接的な影響は限定的だ。ただし、以下の点は把握しておく価値がある： BYODデバイスのポリシー確認: 個人所有のWindows 11端末を業務に使用している環境では、Xboxモードの存在をポリシーの観点から整理しておくとよい グループポリシーでの制御可否: 企業向けに展開を制限したい場合、Intuneやグループポリシーを通じた制御オプションを確認しておきたい ハンドヘルドPC導入検討の参考情報: 可搬性の高い端末の導入を検討しているIT部門にとって、ゲームモードの有無が選定基準に加わるかもしれない 筆者の見解 XboxモードのPC全体への展開は、MicrosoftがPCゲームを「Xboxというブランドの傘下に統合する」戦略を着実に前進させている動きだ。SteamがPC向けゲームプラットフォームとして盤石な地位を確立している中で、Microsoft/XboxはGame PassとWindows、そしてXboxモードの組み合わせで独自の価値を打ち出そうとしている。 Windowsという巨大なプラットフォームを持つMicrosoftには、これを実行できるだけの底力がある。コントローラー最適化UIを全Windows PCに展開することで、ハンドヘルドゲーミングPCの普及トレンドにも対応できる。ここには「Windowsというプラットフォームの強みを活かした戦略」が見える。 一方で、汎用OSとしてのWindowsに特定用途向けのモードを積み重ねていく設計思想が、長期的にユーザーの体験をどう変えるかは引き続き注視したい。「Windows = 万能プラットフォーム」という強みを守りつつ、専用デバイスのような没入感を実現できるかが、今後のゲームエコシステムにおけるMicrosoftの評価を左右するだろう。やれる力はある。あとはどこまで丁寧に仕上げるかだ。 出典: この記事は Windows 11 Update Rolls Out Xbox Mode to All PCs の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

「Nightmare-Eclipse」と名乗る脅威アクターが2026年4月初頭から6週間にわたり、WindowsのDefenderやBitLockerを標的にした6件のゼロデイ脆弱性をGitHubに順次公開しており、Barracudaの調査でロシア系インフラを経由した実攻撃への悪用が確認されている。 Nightmare-Eclipseとは何者か 「Nightmare-Eclipse」（別名：Chaotic Eclipse、Dead Eclipse）は、GitHubとブログを拠点に活動する脅威アクターだ。セキュリティ研究者としての深いWindowsインターナルの知識を持ちながら、Microsoftへの個人的な恨みを唯一の動機として行動している点が際立っている。 本人は「Microsoftが合意を破り、自分を無一文のホームレスにした」と主張している。金銭目的でも国家支援でもなく、純粋な個人的報復だ。こうした動機の攻撃者は従来の脅威インテリジェンスの分類——ランサムウェア集団、国家支援APT——には収まらない。 6つのゼロデイ脆弱性の全貌 2026年4月初頭から5月時点で、以下の6件がGitHub上で公開されている： 名称 CVE パッチ状況 BlueHammer CVE-2026-33825 パッチ済み RedSun なし（サイレントパッチ） パッチ済み UnDefend 未割り当て 未パッチ YellowKey 未割り当て 未パッチ GreenPlasma 未割り当て 未パッチ MiniPlasma 未割り当て 未パッチ このキャンペーンで最も注目すべき点は、Microsoftのセキュリティ製品そのものを攻撃面として使っていることだ。DefenderやBitLockerを「回避する」のではなく、それ自体を経路や起点に変える手法は、Windowsに精通した内部者的な視点なしには設計できない。 実被害はすでに発生している Huntress Labsが2026年4月10日時点で実攻撃を確認。ロシア系インフラに紐づく侵害活動への悪用が観測されており、CISAのKnown Exploited Vulnerabilities（KEV）カタログにも追加された。Microsoftは緊急パッチサイクルを余儀なくされている。 この攻撃者はProof-of-Concept（PoC）コードをPatch Tuesdayの直後に公開するという意図的なタイミングを取っている。パッチ適用猶予期間を最大限に活用し、修正が展開される前の脆弱性ウィンドウを狙い撃ちにする戦略だ。 さらに、「デッドマンズスイッチ」の存在が予告されており、リモートコード実行（RCE）脆弱性を含む追加公開を示唆していた。最新のMiniPlasmaは予告なしにリリースされたが、これが沈静化なのか次のフェーズへの移行なのかは現時点では判断がつかない。 対象プラットフォーム 影響範囲は広い： Windows 10 / Windows 11 Windows Server 2016〜2025 コンシューマー端末から大規模なエンタープライズサーバーまで、Windowsエコシステムのほぼすべてがスコープに入る。 防御側が今すぐとるべき行動 Barracudaの分析を踏まえ、以下を優先して対処されたい： 1. CVE-2026-33825（BlueHammer）の即時パッチ適用 パッチが提供されている既知CVEは最優先で対処する。適用漏れがないか資産台帳と突合する。 2. BitLockerの構成強化と監視 攻撃者が明示的に標的にした以上、設定の見直しと異常アクセスの監視強化が急務。 3. エンドポイントに依存しない検知レイヤーの整備 侵害されたエンドポイント上のDefenderに頼らない、独立したネットワーク検知・IDコントロールの構築が有効。ゼロトラスト原則でいう「エンドポイントを暗黙的に信頼しない」の実装そのものだ。 4. 未パッチの4件の動向監視 UnDefend、YellowKey、GreenPlasma、MiniPlasmaは2026年5月時点で未パッチ。MicrosoftのMSRCおよびCISAの更新情報を継続的に追う体制を整える。 5. ロシア系IPレンジ・TORノードからの接続精査 既知の悪用インフラとの通信を可視化し、横展開の早期検知に活用する。 実務への影響 日本のエンタープライズ環境にとって、このケースが突きつける最も重要な教訓は「WindowsのネイティブセキュリティツールだけをDefenderとして扱うのは危険」という認識の更新だ。 Defenderが健在でも、UnDefendのような手法はDefender自体を経路に使う。BitLockerが有効でも、その実装を狙われる。単一レイヤーのエンドポイント防御に依存した設計が機能しなくなる攻撃手法が、今回明確に実証された形だ。 また、Patch Tuesday翌日に照準を合わせた公開戦略への対応として、パッチ適用サイクルの短縮化を検討する価値がある。「数日様子を見てから適用する」という判断が有効な場面もあるが、このような意図的なタイミング設計を持つ攻撃者に対しては、早期適用を原則とする局面だ。 ...

Microsoftは2026年5月15日、Windows Insider Programに「Experimental (Future Platforms)」という新チャンネルを設け、ビルド29591.1000を公開した。現行の安定版ビルドが26xxx台であることを考えると、この番号の跳躍は単なる小改訂ではなく、Windowsプラットフォームの抜本的な方向転換を示唆している。 「Future Platforms」チャンネルとは何か これまでのWindows Insider Programは「Dev」「Beta」「Release Preview」「Canary」の4チャンネル構成だった。今回登場した「Experimental (Future Platforms)」は、Canaryの29500シリーズの後継として位置づけられており、「現在進行中のWindowsプラットフォームの変更を開発サイクルの最初期段階で提供する」と説明されている。 注目すべきはビルド番号だ。現行のWindows 11最新安定版は26100台、Canaryチャンネルでも29500台が最新だった。そこへ29591という数字が登場した意味は小さくない。一般的にMicrosoftのビルド番号体系では、メジャーバージョンが変わると大幅な番号跳躍が起きる。Windows 10の10240からWindows 11の22000への移行がその典型例だ。今回の跳躍がWindows 12、あるいはWindowsカーネルの刷新を示すものであれば、IT業界にとって重大な変化点となる。 ただし公式リリースノートは「含まれる機能は将来のWindowsリリースでリリースされない可能性がある」と明記しており、あくまでコンセプト検証段階であることも示している。 今回のビルドに含まれる新機能 Windows Updateの柔軟性向上 企業のIT管理者が特に注目すべきは、Windows Updateに関する変更だ。今回のビルドでは以下の改善が加えられている。 OOBE（初期セットアップ）中にアップデートをスキップできる: 展開作業中に不意のアップデートが走って時間を取られる問題が緩和される アップデートの一時停止を何度でも延長可能: 従来は最大35日などの制限があったが、この制約が緩和される方向 シャットダウン・再起動時に「更新せずに終了」を常時選択可能: 「更新して再起動」を強要されるシーンが減る 適用前に更新内容をより詳しく確認できる: 何が変わるかを事前に把握した上でインストールを判断できる これらは「Windowsアップデートに振り回される」という長年の不満に応えるものだ。管理端末での検証フローを組んでいる現場にとっては朗報になりうる。 Bluetooth LE Audioによる「Shared Audio（共有オーディオ）」 一台のWindows 11 PCから、2台のBluetooth LE Audio対応デバイスへ同時に音声を送信できる機能が追加された。映画鑑賞や音楽を複数人で共有する際に、一台のPCから独立したイヤホン・ヘッドホン2台へブロードキャスト送信できる。 操作方法は「タスクバー → クイック設定 → Shared audio」から対象デバイスを2台選択するだけ。Bluetooth LE Audioはレイテンシーと省電力性能に優れた新世代規格であり、この活用はWindowsのコンシューマー向け体験を底上げするものだ。 ストレージ設定のUACプロンプト改善 設定アプリの「システム → ストレージ」を開いた際に表示されていたUAC（ユーザーアカウント制御）プロンプトが、ページ表示時ではなく「一時ファイルの表示」を選択したときにのみ出るよう変更された。細かい改善ではあるが、管理者権限の不必要な要求を減らすという原則に沿った修正だ。 日本のIT現場への影響 Windows Updateの柔軟化は、特に国内の大手企業・自治体のIT担当者にとって実務直結の改善だ。定期メンテナンスウィンドウ外にアップデートが走ることへの懸念は根強く、「スキップできる」「何度でも一時停止できる」という変更は展開管理の予測可能性を高める。 一方で「Future Platforms」という新チャンネル名が示す次世代Windowsへの移行は、企業の端末管理戦略に影響を与える可能性がある。Windows 11のサポート期限（2025年10月）に向けた移行計画を立てている組織は、次期バージョンの輪郭が見え始めたタイミングで、一度ロードマップを見直しておくことが賢明だ。 筆者の見解 「Future Platforms」というチャンネル名は、Microsoftが次世代Windowsの基盤づくりを本格化させていることの証左だろう。ビルド番号の大幅跳躍が単なる命名ルール変更ではなく、本当にアーキテクチャレベルの刷新を反映しているなら、それは歓迎すべきことだ。 今回含まれた機能自体は比較的地味だが、Windows Updateの改善は「正しい方向性」だと思う。更新を「強制」から「対話」へシフトしていくことで、ユーザーとシステムの信頼関係が少しずつ回復するはずだ。更新を恐れて先延ばしにする行動こそがセキュリティリスクになるのだから、更新しやすい環境を作ることは、機能追加と同等かそれ以上に重要な投資だ。 Shared Audioは正直なところコンシューマー向けの小技の印象が強いが、Bluetooth LE Audioという次世代規格の実装を進めているという意味では、地道ながら正しいインフラ整備だ。 「次世代Windows」の正体がまだ霧の中にある段階で、Insider Programを通じて継続的に実験的な変更をフィードバックしながら進める姿勢は、Microsoftが持つ最大の強みの一つだ。このプロセスがしっかり機能し、企業や開発者が安心して乗り移れるプラットフォームに仕上がることを期待したい。 ...

MicrosoftがVisual Studio Code（VS Code）の最新週次アップデートで、基本的なプロジェクト表示・操作に必要な組み込みツール群を強化し、開発者が長年悩まされてきた「セットアップの摩擦」を大幅に削減した。新しい環境を立ち上げるたびに延々と拡張機能をインストールしていた時代が、終わりを迎えようとしている。 これまでの「摩擦」とは何か VS Codeは「軽量なコアに拡張機能を積み重ねる」設計思想で急成長を遂げた。しかし現実の開発現場では、この柔軟性が逆に負担になるケースが続出していた。 新しいリポジトリをクローンするたびに「推奨拡張機能をインストールしますか？」のポップアップが現れ、シンタックスハイライト、Lint、ファイルプレビューなど「普通に見るだけ」の用途でも複数の拡張機能が必要だった。チームの新メンバーは初日をセットアップに費やし、CI環境では拡張機能の管理が別の運用コストになっていた。 組み込みツール強化で何が変わるか Microsoftは今回のアップデートで、基本的なプロジェクト操作に必要なツールをVS Code本体に統合した。その主な効果は次の3点だ。 即時利用可能なゼロ設定環境 リポジトリをクローンして開いた瞬間から、追加インストールなしで基本的な開発体験が得られる。extensions.json の管理や「あなたの環境だけ動かない」問題が大幅に減少する。 セキュリティリスクの低減 拡張機能マーケットプレイスからのインストールを最小化できるため、サプライチェーンリスクが下がる。特に日本のエンタープライズ環境では、セキュリティポリシーによって拡張機能インストール自体が制限されているケースも多く、組み込みツールの充実は直接的な恩恵をもたらす。 クラウド・コンテナ開発との相性向上 DevContainerやGitHub Codespacesを活用したクラウド開発では「最小セットアップ・最大機能」がコストと速度の両面で重要だ。組み込みツールの強化はこの方向性と完全に一致している。 実務での活用ポイント オンボーディングの即戦力化 新メンバーがリポジトリをクローンして即座に開発を開始できる体制を整えよう。プロジェクトの extensions.json を見直し、本当に必要な拡張機能だけを recommendations に残すことで、セットアップ時間をさらに短縮できる。 CI/CDパイプラインの簡素化 コードレビューやLintチェックをVS Code組み込みツールに依存する構成へ移行すると、パイプラインの追加パッケージインストールステップを削減できる可能性がある。devcontainer.json と組み合わせた標準化が特に効果的だ。 セキュリティポリシーが厳しい環境での対応 拡張機能マーケットプレイスへのアクセスが制限された環境では、組み込みツールに依存する開発フローを公式ドキュメントをベースに設計しておくと、監査対応もスムーズになる。 筆者の見解 VS Codeは今のMicrosoftが誇るべき最高の成功例のひとつだと思っている。派手な発表ではないが、毎週着実に積み重なる「開発者の地味な不満を拾い上げる」姿勢は本物だ。 「摩擦を減らす」という今回の改善は一見地味に見えるが、実務への影響は大きい。新しい環境を立ち上げるたびの「あの面倒くささ」を知っている開発者なら、この変更の価値がよくわかるはずだ。 ひとつ注目しておきたいのは、組み込みツールとサードパーティ拡張機能の境界線の問題だ。VS Codeが成功した理由の大部分は、活発な拡張機能エコシステムにある。組み込みツールの範囲が広がりすぎると、コントリビューターのモチベーションに影響が出る可能性もある。オープンな生態系を守りながら組み込みを強化するバランスをどう取るか、今後の方針は引き続き注視していきたい。 VS Codeがあらゆる開発者の「標準装備」として機能し続けるためにも、この地道な改善路線を一貫して続けてほしい。Microsoftにはその実力が十分にある。 出典: この記事は Microsoft just removed major “friction” from VS Code in its latest weekly update の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがOutlookにおける基本的なメール機能の不具合を公式に認め、現時点での回避策を案内した。日々の業務でOutlookを中心に動いている日本企業にとって、「当たり前にできるはず」の操作が突然使えなくなるこのような事態は、業務影響が無視できない。 何が起きているのか 今回のMicrosoftの公式アナウンスは、Outlookが持つ基本的かつ多くのユーザーが日常的に使っているメール機能の一つが、現在正常に動作していないというものだ。Neowinが報じたこの件では、Microsoftは障害の存在を認めつつ、修正が完了するまでの暫定的な回避策（ワークアラウンド）を共有している。 Microsoftは近年、クラシックOutlook（旧来のデスクトップアプリ）から「新しいOutlook for Windows」への移行を積極的に促している。この移行プロセスの中で、旧アプリでは当然のように使えていた機能が新しいOutlookで動作しないケースが散発的に報告されてきた。今回の件がどちらのバージョンの問題かは記事公開時点では確定情報がないが、移行期特有の品質リスクが表面化している可能性が高い。 回避策の活用と注意点 現時点でMicrosoftが提示しているアドレスは「修正の約束」ではなく「暫定対応」だ。実務で影響が出ている場合は、以下の点を押さえておきたい。 Microsoft 365 管理センターの「サービス正常性」を確認する: テナント管理者はリアルタイムで障害状況と公式回避策を確認できる。エンドユーザーからの問い合わせが来る前に把握しておくこと 回避策の展開はヘルプデスクに周知する: 一般ユーザーが自力で回避策を見つけるのは難しい。IT部門が先手を打ってFAQや簡易手順書を用意すると混乱を最小化できる 新旧Outlookの切り替えを一時的に検討する: 新しいOutlookへの移行途中のテナントであれば、影響範囲によっては一時的にクラシックOutlookへ戻す判断も選択肢に入る。ただし「戻す」判断は長期的な移行計画全体を見据えて慎重に Microsoft 365 ロードマップとMessage Centerを定期購読する: 事後対応ではなく、変更・障害情報を早期にキャッチするための仕組みを組織として持つことが重要 実務への影響 Outlookは日本企業のメールインフラのデファクトスタンダードであり、基本的なメール機能の障害はそのまま業務停止リスクに直結する。特に、フロントオフィスや営業部門のようにメールを主要コミュニケーション手段として使っているチームでは、「Outlookが使えない」というシンプルな問題が大きな業務影響を生む。 また、Microsoft 365の利点は「統合プラットフォームとして使うことで価値が出る」点にある。Teams・Outlook・SharePoint・Copilotが連携して動いてこそ真価を発揮するが、そのコアとなるOutlookが揺らぐと全体の連携品質も下がる。個々のアプリを別々に評価するのではなく、プラットフォーム全体の安定性として捉える視点が管理者には必要だ。 筆者の見解 Outlookのような、長年にわたって数億人が毎日使い続けてきたプロダクトで、基本的な機能が壊れるという事態は、率直に言ってもったいないと感じる。Microsoftには間違いなくその技術力があるのだから、こういった品質問題は「やろうと思えばできるはず」という期待とのギャップが大きく映る。 近年のMicrosoftは新しいOutlookへの移行を急ぐあまり、成熟した旧バージョンが担ってきた品質水準を新バージョンで再現するコストを過小評価しているように見える部分がある。ユーザーが「新しいUIになったら前よりも不便になった」と感じると、移行そのものへの反発が生まれ、長期的には製品全体への信頼低下につながる。 移行は避けられない方向性であり、新しいOutlookがいずれ安定した姿になることは期待している。ただ、その過程での品質管理の丁寧さが、ユーザーのMicrosoft 365全体への評価に直接影響することを、開発チームには改めて意識してほしいと思う。「基本機能が壊れている」というニュースが繰り返されると、せっかくのプラットフォームとしての総合力が霞んでしまう。 出典: この記事は Microsoft admits one of the most basic, useful Outlook features is broken の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが2026年5月、Microsoft 365 Copilotに大規模アップデートを展開した。目玉はOpenAIの最新モデル「GPT-5.5」の統合で、低遅延の「GPT-5.5 Instant」と多段階推論が可能な「GPT-5.5 Thinking」の2種類が利用できるようになる。さらにアプリランチャー「ワッフル（Waffle）」の復活、Researcher機能の強化、Copilot Notebooksの新機能追加など、企業向け生産性ツールとしての土台が大幅に底上げされた。 GPT-5.5モデルの統合——2種類の使い分けが鍵 今回追加されたGPT-5.5は、用途に応じた2種類のモデルが提供される点が特徴だ。 GPT-5.5 Instantは低レイテンシを重視した設計で、メール返信の下書き、会議要約の即時生成、日常的な文書作成といった「素早く答えが欲しい」シーンに最適化されている。レスポンス速度が重視される業務フローでストレスを大幅に軽減できる。 GPT-5.5 Thinkingは、複数ステップにわたる論理的推論を得意とするモデルだ。財務レポートの深い分析、複雑な調査タスク、多角的な比較検討が求められる作業で真価を発揮する。単純な要約に止まらず、「なぜそうなるのか」「どう判断すべきか」という思考プロセスを伴うアウトプットが可能になる。 この2モデルの並存は、「AIに何でもやらせる」という曖昧な活用から、「タスクの性質に合わせてモデルを選ぶ」という成熟した活用へのシフトを促す設計といえる。 ワッフルランチャー復活——ユーザーフィードバックの成果 Microsoft 365を長く使ってきたユーザーなら「ワッフル（Waffle）」と呼ばれるアプリランチャーを懐かしく思うだろう。格子状のアイコンからOutlook、Teams、OneDrive、SharePointなどへ素早くジャンプできるこの機能が、今回のアップデートで復活する。 廃止・変更された際には多くのユーザーから不満の声が上がっており、今回の復活はMicrosoftがユーザーフィードバックを製品に反映させた好例といえる。複数のM365サービスを横断して業務を進めるユーザーにとって、ナビゲーションの一貫性は生産性に直結する。 ResearcherとCopilot Notebooksの強化 Researcher機能は、大量のドキュメントやウェブ情報を分析して体系的にまとめる機能で、今回さらに精度と速度が向上した。調査担当者や意思決定者が多くの情報源を処理しなければならない場面で、より実用的なレベルに近づいている。 Copilot Notebooksは、AIとのやりとりや生成コンテンツをノートブック形式で管理できる機能で、新機能が加わった。長期的なプロジェクト管理、調査内容のまとめ、チームでの知識共有といったユースケースでの活用が広がりそうだ。 Windows 11タスクバーへのAIエージェント統合 今回のM365アップデートと並行して、Windows 11のタスクバーにAIエージェントをアプリとして表示する「Agents on Taskbar」機能も展開される。OSレベルでAIエージェントをネイティブに扱う方向性を明確に打ち出したかたちだ。 日本のIT現場への影響 日本企業のMicrosoft 365導入率は年々高まっており、TeamsとM365を中心とした業務フローが標準化されつつある。今回のアップデートが現場に与える影響として、以下の点に注目したい。 即時に活用できる実務例： 英語メールの日本語要約と返信案の生成（GPT-5.5 Instantが有効） 社内会議の文字起こしと議事録の自動生成 財務・プロジェクトレポートの多角的分析（GPT-5.5 Thinkingが有効） 大量のRFP・提案書からの要件整理 IT管理者が確認すべき点： GPT-5.5モデルへのアクセスはライセンスプランによって異なる可能性があるため、契約内容の確認が必要 Copilot Notebooksに蓄積されるデータのガバナンスポリシーを事前に整備すること 「Agents on Taskbar」はエンドポイント管理ポリシーとの整合性確認が求められる 筆者の見解 GPT-5.5 InstantとGPT-5.5 Thinkingという2モデルを用途別に選択できる設計は、方向性として正しいと思う。「AIにとりあえず聞く」から「目的に応じてツールを選ぶ」という使い方の成熟を後押しする仕組みだからだ。 ただ正直に言えば、「ようやくここまで来たか」という感覚もある。Copilotが登場した当初から、多くのユーザーが「速さが欲しいときと、深く考えてほしいときでは要件が違う」という声を上げ続けていた。その声が製品に反映されるまでに時間がかかりすぎた感は否めない。 ワッフルランチャーの復活も同様で、ユーザーの声を聞いて改善できる力はMicrosoftには十分ある。問題は、そのサイクルをもっと速く回せるかどうかだ。Copilotはまだ「生産性の最大化」という本来の目標に届いていないと感じているが、今回のGPT-5.5統合は実質的な前進であり、正面から勝負できる素地が着実に整いつつあることは認めたい。 日本の企業にとっては、今が「Copilotを使えるかどうか」ではなく「どう使うか」を本気で設計するフェーズだ。モデルの質が上がった今、組織としての活用戦略がなければ恩恵の半分も受け取れない。 出典: この記事は Microsoft 365 Copilot update adds GPT-5.5 models and more の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Appleは、App Storeにおけるセキュリティ実績の最新データを公開し、潜在的な不正取引として22億ドル（約3,300億円）超をブロックしたことを明らかにした。アプリの審査から決済監視まで多層的な防御がその背景にある。 App Storeが公開した主要な安全統計 Appleが毎年発表するApp Store安全性レポートは、エンドユーザーが目にすることのないバックエンドの防衛活動を数値化したものだ。今回の公開データで特に注目すべき点は以下の通りだ。 22億ドル超の不正取引を阻止: 決済段階で検知された潜在的な詐欺行為を、実際の被害が発生する前にシステム的にブロックした 不正アプリの審査拒否・削除: App Reviewプロセスを通じた事前スクリーニングに加え、公開後のアプリについても継続的な監視が行われている 偽レビューや不正アカウントの排除: マーケットプレイスの信頼性を保つための継続的な取り組みも報告されている なぜこれが重要か AppleのApp Storeはモバイルアプリ流通において世界最大規模のプラットフォームのひとつであり、日本においても多くの法人・個人ユーザーがビジネス用途でiOSアプリを日常的に利用している。このため、プラットフォームレベルのセキュリティ水準が企業のリスク管理に直接影響する。 特に企業内でのMDM（モバイルデバイス管理）運用を担うIT管理者にとっては、「App Store経由のアプリは一定の審査を通過している」という前提がゼロトラスト設計の信頼起点のひとつになっている。この前提が崩れれば、エンドポイントセキュリティ全体の再設計を迫られる可能性もある。 一方で、22億ドルという数字は「防いだ被害額」であると同時に、それだけの不正試行が存在していたという事実でもある。プラットフォームが大きくなるほど攻撃対象としての魅力も増す、という構造的なジレンマを改めて示している。 実務での活用ポイント エンドポイント管理担当者へ: Appleの審査が通過していても、マルウェアが後から埋め込まれる「バージョンアップ型攻撃」は過去に事例がある。MDMポリシーでのアプリ許可リスト管理と合わせて、App Storeの透明性レポートを定期的に参照し、自社利用アプリのリスクを定量的に把握する習慣をつけたい。 開発者・ISV向け: Appleのレビュープロセスは厳格で時間がかかると批判される一方、こうした数値がその意義を裏付けている。Appleのガイドラインへの準拠は単なる規約遵守ではなく、エンドユーザーへの信頼担保でもある。特に決済フローを持つアプリは、審査基準の変更を常にウォッチしておくことが欠かせない。 セキュリティ部門向け: Non-Human Identities（NHI）の観点でも注目すべき点がある。App Storeの不正取引の多くは、盗まれたApple IDや自動化されたボットによるものだ。自社のサービスアカウントやAPIキーも同様のリスクにさらされていると想定し、JIT（Just-In-Time）アクセスや短命トークンの活用を検討したい。 筆者の見解 Appleがこうした統計を年次で公開するスタンスは評価できる。数字を出すことで「うちのプラットフォームはこれだけ守っている」という説明責任を果たしているからだ。 ひとつ気になるのは、「防いだ」という数字の定義の曖昧さだ。「潜在的な不正取引」とはどこまでが確実な不正で、どこからが誤検知なのか。透明性レポートとして評価するなら、方法論の開示まで踏み込んでほしい。 セキュリティは「何を禁止したか」ではなく「どう構造的に安全にしたか」で語られるべきだ。その意味で、Appleのレイヤーごとの防御設計（審査・決済・アカウント）のアプローチは、プラットフォームセキュリティの教科書的な事例として参考になる。日本企業のシステム設計者にも、禁止ルールを積み重ねるのではなく、「使う側が一番安全な選択肢に自然に誘導される仕組み」を作るという発想の転換を促したい。 出典: この記事は Apple shares big numbers about fraud on the App Store の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ウクライナサイバー警察と米国法執行機関は、カリフォルニア州のオンラインストアのユーザーを標的にInfostealer（情報窃取）マルウェアを運用し、2万8000件以上のアカウントを侵害した18歳の男をウクライナ・オデッサで特定した。被害額は約72万1000ドル（約1億円超）に上る。 Infostealerで2万8000件を侵害した手口 2024年から2025年にかけて、容疑者はInfostealerマルウェアを使って被害者のデバイスに密かに感染させた。このマルウェアはブラウザのセッションデータ、ログイン認証情報、クッキー、セッショントークン、仮想通貨ウォレット、決済情報などを収集し、容疑者が管理するサーバーに送信する仕組みだ。 侵害されたアカウントは2万8000件に上り、そのうち5,800件が実際の不正購入に悪用された。被害総額は約72万1000ドル、チャージバックを含む直接損失は25万ドルに達している。 盗んだデータはオンラインリソースやTelegramボットを通じて処理・売買され、容疑者は仮想通貨で収益を受け取っていたとされる。ウクライナ警察は自宅2か所を捜索し、携帯電話・コンピュータ機器・銀行カード・電子記録媒体などを押収した。現時点では逮捕には至っておらず、当局はまだ起訴に向けた証拠を固めている段階だという。 最大の問題：セッショントークンでMFAが無効化される 今回の攻撃で技術的に最も重大なポイントは、セッショントークンの悪用だ。 セッショントークンは認証後にサーバーが発行するデータで、ブラウザがこれを保持することでログイン状態を維持する仕組みだ。これを盗まれると、攻撃者はパスワードを知らなくてもアカウントにアクセスできる。さらに深刻なのは、多要素認証（MFA）をすでに通過した後のセッションを乗っ取るため、MFA自体が意味をなさなくなる点だ。 「MFAを設定しているから安全」という前提が根底から崩れる攻撃手法であり、エンタープライズ環境でも決して他人事ではない。 実務への影響——日本のエンジニア・IT管理者へ MFAの導入だけで安心しないこと 今回の事件が示す教訓は明確だ。MFAは認証「時点」を守るが、認証後のセッションは別の話だ。以下の対策を組み合わせて初めて実効性のある防御になる。 セッションの有効期限を短く設定する：長時間有効なセッションはリスクを高める。サービスの利便性とのバランスを取りながら、適切な失効タイミングを設定する 継続的アクセス評価（CAE）の活用：Microsoft Entra IDのCAEは認証後もリアルタイムでセッションの正当性を評価し、異常を検知した際に即時失効できる。既にEntra IDを使っているなら積極的に有効化すべき機能だ 条件付きアクセスポリシーの強化：未知のIPアドレスや新しいデバイスからのアクセスに再認証を要求する設定を追加する デバイスコンプライアンスとの統合：管理対象デバイスからのアクセスのみ許可することで、マルウェアに感染した非管理デバイスからのトークン流用を防ぐ Infostealerは「誰でも使えるツール」になっている 今回の容疑者は18歳だ。特別に高度な技術を持つ攻撃者でなくても、マルウェア・アズ・ア・サービス（MaaS）として流通するInfostealerを購入して展開するだけで、数億円規模の詐欺を実行できる時代になっている。 「うちは有名な会社じゃないから狙われない」という認識はもはや通用しない。ECサイトや顧客情報を持つ中小規模のオンラインサービスも標的になりうる。エンドポイントへの感染経路（フィッシングメール、悪意あるダウンロード）を塞ぐセキュリティ意識教育と、EDRソリューションの導入は急務だ。 筆者の見解 セキュリティ分野は正直、得意ジャンルとは言いにくい領域だ。細かい議論が多すぎるし、規格やフレームワークの海に溺れることも多い。ただ、今回の事件は技術的に非常に興味深い構造を持っている。 注目すべきはセッショントークンによるMFAバイパスという構造的問題だ。「MFAを入れた＝安全」という思い込みは、今も多くの現場に根強く残っている。だが認証の「後」に発行されたセッションを奪われれば、MFAはあってないようなものになる。これはゼロトラストの文脈では「一度認証したら信頼し続ける」という旧来モデルの根本的な欠陥を突いている。 本来のゼロトラストは「継続的な検証（Continuous Verification）」が前提だ。Entra IDのCAEやMicrosoft Defenderのエンドポイント統合は、この方向性における正しいアプローチだと思う。こうした仕組みを組み合わせた多層防御こそが、アイデンティティ保護の核心になる。VPNで境界を守る時代から、セッション単位・アクセス単位で継続的に検証する時代への移行は、もはや「いつかやること」ではない。 今回の容疑者が18歳だという事実も、現実を直視させる。技術の民主化は、攻撃の民主化でもある。守る側が「うちはまだ大丈夫」と言っていられる時間は、思っているより短い。 出典: この記事は Ukraine identifies infostealer operator tied to 28,000 stolen accounts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月20日、Windows BitLockerを回避してドライブへのアクセスを可能にするゼロデイ脆弱性「YellowKey」（CVE-2026-45585）の緩和策を公開した。パッチリリース前ながら、実際の攻撃への悪用に備えた暫定対応として企業・個人への適用が推奨されている。 YellowKeyとは何か：BitLockerを「抜け道」で突破する手口 YellowKeyは、「Nightmare Eclipse」を名乗る匿名のセキュリティ研究者が先週公開したゼロデイ脆弱性だ。攻撃者はUSBドライブまたはEFIパーティション上に特別に細工された「FsTx」ファイルを配置し、Windows回復環境（WinRE）に再起動後、CTRLキーを押し続けるだけでBitLockerで保護されたストレージへの無制限アクセスを持つシェルを起動できるという。 この手法の厄介な点は、BitLocker自体の暗号アルゴリズムを破るのではなく、WinRE起動時の処理フロー（具体的にはTransactional NTFSの自動リカバリユーティリティ「autofstx.exe」）を悪用して保護をすり抜けるところにある。つまり、暗号強度の問題ではなく起動プロセスの設計上の盲点を突く攻撃だ。 一連のゼロデイ公開：研究者とMSRCの対立が背景 YellowKeyは単発の公開ではない。Nightmare Eclipseはここ数週間で以下の複数の脆弱性を連続して公開している： BlueHammer（CVE-2026-33825）：ローカル権限昇格（LPE）。すでに実際の攻撃で悪用中 RedSun：同じくLPE系。すでに攻撃悪用が確認 GreenPlasma：SYSTEMシェルを取得できる権限昇格 UnDefend：標準ユーザー権限からMicrosoft Defenderの定義ファイル更新をブロックできる脆弱性 研究者は、これらの公開が「過去にMSRC（Microsoft Security Response Center）へ報告した脆弱性の開示プロセスへの抗議」であると明言している。協調的脆弱性開示（CVD）のプロセスへの不満が引き金となった「報復型公開」とも言える事態だ。 Microsoftが示した具体的な緩和策 MicrosoftはCVE-2026-45585のアドバイザリにて、パッチ提供前の暫定対応として以下の2系統の措置を推奨している。 対策①：autofstx.exeの自動起動を無効化 WindowsのSession Managerレジストリキー内、BootExecute（REG_MULTI_SZ値）からautofstx.exeのエントリを削除する。これにより、WinRE起動時にwinpeshl.iniを削除するTransactional NTFSのリプレイ処理が実行されなくなり、攻撃の起点が断たれる。 併せて、CVE-2026-33825のアドバイザリに記載された手順に従い、WinREのBitLocker信頼関係を再確立する必要がある。 対策②：BitLockerの認証モードを「TPM+PIN」へ移行 現在「TPMのみ」モードでBitLockerを運用している場合、「TPM+PIN」モードへ変更することで、起動時に事前認証PINが必要となりYellowKey攻撃を実質的にブロックできる。 設定方法は以下の3通りが用意されている： PowerShell コマンドライン コントロールパネル まだ暗号化していないデバイスについては、Microsoft Intuneまたはグループポリシー経由で「起動時に追加の認証を要求する」オプションを有効化し、「TPM起動PINの構成」を「TPMと共に起動PINを要求する」に設定する。 実務への影響：日本のエンジニア・IT管理者がすべきこと 即時確認すべき環境として優先度が高いのは以下のケースだ： 物理アクセスが比較的容易な環境（共有スペースのPC、展示用端末、出張・テレワーク用ノートPC） BitLockerをTPMのみで運用している企業端末：エンドポイント管理ツール（IntuneやSCCM）でTPM+PIN移行の展開計画を立てる WinREが有効になっているサーバー：特に物理サーバーや共用ホスティング環境では確認が必要 Intuneを利用している環境では、エンドポイントセキュリティポリシーの「BitLocker」設定から一括展開が可能だ。まず小規模パイロットで動作を確認してからロールアウトする手順を踏むと安全だ。 なお、BlueHammerとRedSunはすでに実際の攻撃で使われていることも忘れてはならない。YellowKeyの緩和策適用と並行して、これらへのパッチ適用状況も合わせて確認しておきたい。 筆者の見解 今回の一連の出来事は、脆弱性開示の難しさを改めて突きつけている。研究者とベンダーの「協調的開示」は理想論として成立するが、その運用がどちらかにとって不誠実だと感じられれば、今回のような形で崩壊する。MSRCのプロセスに何らかの問題があったのかどうか、現時点では外部からは判断しかねる部分もあるが、これだけの規模で報復的な公開が続いているという事実は、Microsoftには真剣に受け止めてほしいところだ。 技術的な側面で言えば、TPMのみのBitLocker運用がいかに脆弱な前提に立っているかを、今回の脆弱性は鮮明に示している。物理アクセスさえできれば保護が崩れる構成は、ゼロトラストの観点からもアウトだ。「ドライブを暗号化しているから安心」ではなく、「誰がどのタイミングで認証するか」まで設計して初めてセキュリティが成立する。TPM+PINへの移行は今すぐ着手すべき作業であり、パッチ待ちの間の一時的な措置ではなく、恒久的なセキュリティ向上として位置づけるべきだと思う。 MicrosoftがCVEを発行して緩和策を素早く公開したこと自体は評価したい。正式パッチのリリースも迅速に行われることを期待したい。 出典: この記事は Microsoft shares mitigation for YellowKey Windows zero-day の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GitHubは2026年5月20日、同社の社員が悪意のあるVS Code拡張機能をインストールしたことにより、社内リポジトリ約3,800件が侵害されたことを公式に確認した。攻撃者グループ「TeamPCP」は盗み出したコードを5万ドル以上で売却すると宣言しており、開発者コミュニティに大きな衝撃を与えている。 何が起きたのか GitHubは5月19日〜20日にかけて、社員端末の侵害インシデントを検知・封じ込めた。原因は、その社員が「毒入り（Poisoned）」VS Code拡張機能をインストールしたことだ。GitHubは問題の拡張機能をVS Code Marketplaceから削除し、該当端末を隔離した上でインシデント対応を開始した。 現時点での調査によれば、侵害されたのはGitHub内部リポジトリのみであり、外部の顧客データへの影響は確認されていない。攻撃者側が主張している「約3,800リポジトリ」という数字は、GitHub自身の調査とも整合性があると公式に認めている。 犯行グループ「TeamPCP」とは 今回の侵害を主張しているのは「TeamPCP」というハッカーグループだ。サイバー犯罪フォーラム「Breached」にて「GitHubのソースコードと約4,000件のプライベートリポジトリ」へのアクセスを主張し、最低5万ドルでの売却を宣言している。 「これは身代金要求ではない。GitHubから金を脅し取るつもりはない。一人の買い手に売ったら手元のデータは削除する。買い手が見つからなければ無料で公開する」——この声明からは、金銭目的の計画的な売買スキームが伺える。 TeamPCPはこれまでにも、GitHub・PyPI・NPM・Dockerといった開発者向けコードプラットフォームを標的にした大規模なサプライチェーン攻撃に関与しているとされる。最近では「Mini Shai-Hulud」サプライチェーンキャンペーンにも関与しており、OpenAI社員2名も被害を受けたとされている。 VS Code拡張機能の危険性——繰り返す侵害の歴史 VS Code拡張機能は、Microsoftの公式ストア「VS Code Marketplace」から無料でインストールできる。その利便性の裏側に、過去から繰り返してきたセキュリティリスクが存在する。 2024年: 合計900万インストールを超えるVS Code拡張機能がセキュリティリスクにより削除 2024年: 10種の拡張機能が正規の開発ツールに偽装し、XMRig クリプトマイナーをインストール 2024年末: 攻撃者「WhiteCobra」が24種の暗号通貨窃取拡張機能を大量投入後、ランサムウェア機能を持つ拡張機能がマーケットプレースに侵入 2026年1月: AIコーディングアシスタントを装った悪意ある拡張機能2種（計150万インストール）が、中国のサーバーへ開発者システムのデータを送信 VS Code Marketplaceのエコシステムは世界最大規模の開発者向けプラグインストアだ。そのスケールゆえに、審査をすり抜けた悪意ある拡張機能が繰り返し発見される構造的な問題が続いている。 実務への影響——日本の開発者・IT管理者へ このインシデントが日本のエンジニアやIT部門に示す教訓は具体的だ。 開発者が今すぐできること: インストール前の確認を習慣化する: 公式マーケットプレース掲載でも安全ではない。開発元の組織・インストール数・更新頻度・ソースコードの公開有無を確認してからインストールする 定期的な棚卸しを実施する: インストール済みの拡張機能を3ヶ月に1回程度レビューし、使っていないものや出所が不明確なものは削除する AIコーディングアシスタントを装う偽物に注意: 2026年1月の事例でも明らかなように、生成AI系ツールへの偽装が増加傾向にある。著名な提供元（GitHubやMicrosoft公式等）との偽物を見分ける目を養う IT管理者・セキュリティ担当者向け: エンドポイント管理ポリシーで拡張機能を制御: Microsoft IntuneやGroup Policyを使い、事前承認済みの拡張機能のみインストールを許可するポリシーを検討する 開発者端末のEDR/XDRを強化する: GitHubが今回迅速に検知・封じ込めできたように、開発者端末こそエンドポイント保護の対象として位置づける 最小権限の原則を内部リポジトリにも適用する: 社員端末が侵害されても被害範囲を限定できるよう、開発者の内部リポジトリへのアクセス権を職務上必要な範囲に絞る 筆者の見解 今回のGitHub侵害で改めて浮かび上がるのは、サプライチェーン攻撃の対象が「コード」そのものから「開発者の日常ツール」へとシフトしているという現実だ。 VS Code拡張機能は、現代の開発者にとって空気のような存在になっている。便利さゆえにインストールのハードルが著しく低い。そこに攻撃者が目をつけるのは合理的な判断と言わざるを得ない。 セキュリティを「禁止」で解決しようとする組織は必ず失敗する。「VS Code拡張機能は全て禁止」では開発生産性が壊滅し、迂回策を取る開発者が続出する。重要なのは、公式に承認された拡張機能を使うのが最も便利な状況を組織として整備することだ。IT部門が事前承認済みのリストを維持し、それを使うことで摩擦なく仕事ができる仕組みにする——この方向性こそが現実的な答えだと筆者は考える。 今回の侵害が「内部リポジトリのみ」に留まった点は、GitHubのインシデント対応体制が機能した証左でもある。侵害を100%防ぐことは不可能という前提で、いかに早く検知して被害範囲を限定するかが問われている。同様の体制を持つ日本企業はまだ少数派だろう。 GitHubを使っている組織がFortune 100の90%に達しているという事実は、それ自体が攻撃者にとっての巨大なインセンティブだ。規模の大小に関わらず、開発者ツールのセキュリティを「本業ではない」として後回しにしてきた組織は、今すぐ向き合うべきタイミングにきている。 出典: この記事は GitHub confirms breach of 3,800 repos via malicious VSCode extension の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年5月10日週、Windows 11のDev Channelビルドに「低遅延モード（Low Latency Mode for Gaming and Media）」を追加し、同時期にXbox向けCopilotアプリを静かに削除した。ゲーマーには朗報、AI機能はひっそり縮小という対照的な動きが重なった週となった。 Windows 11の「低遅延モード」とは何か Dev Channelビルドに新たに追加されたこの機能は、Windowsの音声・入力パイプラインを最適化し、複数のバッファリング段階をバイパスする。設定場所は 設定 > システム > 電源 > 詳細な電源設定 の中に追加された新しいトグルだ。 有効にすると、主に以下の変化が起きる： Windowsオーディオスタックが低バッファモードで動作する 重要なスレッドが高性能コアに固定される Valorant・Apex Legendsなどの競技タイトルで入力遅延が最大40%削減されたという報告がある ウィンドウドラッグやデスクトップアニメーションのレスポンスも向上する NVIDIA Reflixのようなサードパーティ製ツールと近い効果を、OS標準機能として提供しようとするアプローチだ。 注意すべきトレードオフ Microsoft自身も「ハイブリッドグラフィックス搭載システムでは特に安定性が損なわれる可能性がある」と明記しており、実験的機能であることを強調している。 報告されているトレードオフは次の通りだ： バッテリー消費の大幅増加：Surface Laptop 6では通常11時間のバッテリーが6時間強に低下したというテスター報告がある。CPUを常時高クロックで動作させ、省電力の C-state 遷移を部分的に無効化するためだ。 安定性の問題：古いゲームやブラウザベースのビデオ会議ツールで予期しないクラッシュが発生したという報告も出ている。 現時点では実験的な機能であり、いかなる保証もない。秋予定のフォールアップデート（開発コード名：Hudson Valley）での正式採用が見込まれる。 XboxからCopilotが静かに消えた 同週、Xboxのサポートページが更新され、「XboxのCopilotアプリはサポートが終了し、コンソール向けMicrosoft Storeから削除されました」という一文が加えられた。公式ブログによるアナウンスはなく、Insider向けリリースノートに数行記されただけのひっそりした終幕だった。 Xbox向けCopilotは2025年12月に全ユーザー向けに展開されたばかり。ゲームプレイ中にAIサイドバーを呼び出し、攻略ヒントを聞いたりメディア再生を操作したりできる機能として登場したが、わずか数ヶ月での撤退となった。 実務への影響 ゲーマー・競技プレイヤーへ 低遅延モードを今すぐ試したい場合は、Windows Insider Programへの参加が必要になる。ただし、安定性のリスクを承知の上で試すことになる。特にハイブリッドグラフィックス（Intel + NVIDIA構成など）を使うノートPCでは慎重な評価が必要だ。 安定版での採用を待つのが現実的な選択肢で、秋のHudson Valleyアップデートが一つの目安になる。 IT管理者・企業向け バッテリー消費が倍近く増える可能性があるため、モバイルワーカーのデバイスへの展開は安定版リリースまで見送るのが無難 グループポリシーやMDMへの影響は現時点で未明であり、本番環境への適用は時期尚早 Xbox端末を業務用途で管理している場合、Copilot前提のワークフローがあれば見直しが必要 筆者の見解 今回の一連の動きは、Microsoftが現実と向き合い始めているサインとして読める。 「低遅延モード」は技術的に正しい方向性だ。OSスケジューラーのレベルで入力遅延を削減するアプローチは、Windowsが本来持つ強みを活かしたものであり、AIブームの陰で「パフォーマンスに真剣に向き合う」姿勢を示したことは評価に値する。 XboxからのCopilot撤退も、ある意味では誠実な判断だ。PC向けに設計されたテキストベースのアシスタントがコントローラー操作のリビングルーム環境と噛み合わないのは想像に難くない。「やってみて合わなかった、やめよう」という判断は悪いことではない。 ただ、もったいないと感じるのは、良い変更も悪い変更も「こっそり」行われていることだ。低遅延モードは公式発表なし、Copilot削除もブログなし。Microsoftの技術的な実力と規模を考えれば、もっとオープンに「これはうまくいかなかった」「これは新しい方向性だ」と言える余地があるはずだ。そうしたコミュニケーションの積み重ねがユーザーの長期的な信頼につながる。 秋のHudson Valleyアップデートで低遅延モードが安定した状態で正式採用されれば、ゲーミングPCとしてのWindows 11の訴求力は一段上がる。その日を楽しみに待ちたい。 出典: この記事は Windows 11 Gets a ‘Low Latency’ Boost — Key May 10, 2026 News の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはWindows 11の検索機能を大幅に見直し、タスクバーの検索バーでローカルのファイルやアプリをBingなどのWeb検索結果より優先して表示する改善を段階的に展開中であることを公式に認めた。 何が変わるのか 長らくWindows 11の検索バーは「なんでもこなすオールインワン機能」として設計されており、ローカルのファイル検索と同時にBingのWeb検索結果も混在して表示してきた。この結果、たとえばアプリ名を検索しても関係のないWebページが上位に並ぶ、といったUXの問題が常態化していた。 MicrosoftはWindows InsidersのExperimental Channel向けBuild 26300.8493のリリースノートで、次のように明記している。 「ファイルやアプリが、コンテンツとしてより強い一致を示す場合に、Web候補より確実に上位に表示されるようにしました」 実際のテストでは、映画関連のファイル名を検索した際に、従来はBingで映画情報が上位に出ていたところ、ローカルに保存されたそのファイルが最初に表示されるようになったことが確認されている。また、タイポ（入力ミス）がある場合でもローカル結果が優先されるよう改善されており、日常的な検索精度が大きく向上する見込みだ。 今後のロードマップ 今回の変更はあくまでも始まりに過ぎない。Microsoftは2026年3月20日に公開したブログ記事の中で、Windows 11 2026品質改善の重点領域のひとつとしてSearchを挙げており、以下の改善を計画していることが明らかになっている。 ローカル結果とWeb結果を視覚的に区別する新UIの内部テスト中 タスクバー・スタートメニュー・エクスプローラー・設定アプリにまたがる一貫した検索体験の統一 より「高速」で「信頼できる」UIへの刷新 Settingsからの検索設定変更（現状はレジストリ操作が必要） なお、Web検索機能そのものが廃止されるわけではない。Bingとの統合は引き続き維持されるが、ユーザーの意図がローカルコンテンツにある場合はそちらを優先するという、当たり前のことが当たり前にできるよう修正される形だ。 実務への影響 IT管理者・エンジニアへのポイント 現状、企業環境でWindows SearchのWeb結果を無効化したい場合はグループポリシーまたはレジストリ編集が必要だが、今後はSettings UIでの制御が可能になる可能性がある。大規模展開時に構成の手間が減ることが期待できる。 また、エクスプローラーの検索精度向上も計画されているため、大量のファイルを扱う作業環境——開発・設計・法務など——での生産性改善にも直結する。Preview buildで先行確認したい場合は、Windows InsiderプログラムのCanaryまたはDevチャンネルへの参加が選択肢となる。ただし本番環境への早期適用は、例年通り不具合リスクを考慮して数週間様子を見るのが無難だ。 筆者の見解 正直に言えば、これは「なぜ今まで放置されていたのか」という性質の改善だ。ファイルを検索したいときにWebの映画情報が出てくるのは、UIとして根本的に筋が悪い。ユーザーの意図を優先するというのは検索エンジンの基本中の基本であり、それがOSのローカル検索でできていなかった事実は、長年のWindows Searchへの不満の根本にある。 ただ、今回Microsoftが「内部ベンチマークとして精度向上を設定している」と明言し、UIの一貫性・高速化・結果の可視化という複数の軸で改善を進めているのは、方向性として評価できる。Windowsの基盤部分の品質を地道に上げる取り組みは、派手ではないが長く使われるOSとして必要なことだ。 AI機能の華々しいアップデートが注目を集める一方で、こういった「地に足のついたUX改善」が積み重なることで、日常的な使い勝手は確実に向上する。Microsoftが正面から取り組んでほしい領域はほかにもあるが、まずはこの改善が予告通りに安定して届くことを期待したい。 出典: この記事は Microsoft says Windows 11’s Search will stop forcing web over your apps and local files in most cases の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月19日、同社のコード署名サービス「Azure Artifact Signing」を悪用してマルウェアに正規証明書を付与する「マルウェア署名代行サービス（MSaaS）」を運営していた脅威グループ「Fox Tempest」の活動を摘発・無効化したと発表した。 Azure Artifact Signingの悪用という巧妙な手口 Azure Artifact Signing（旧称：Trusted Signing）は、Microsoftが2024年に開始したクラウドベースのコード署名サービスだ。開発者が自分のプログラムをMicrosoftのインフラ上で簡単に署名できる仕組みで、正規の開発者にとっては利便性の高いサービスである。 Fox Tempestはこのサービスを不正に利用し、マルウェアにMicrosoft由来の正規コード署名証明書を付与することで、Windowsのセキュリティ機能やエンドポイント保護を回避していた。署名されたマルウェアはMicrosoft Teams、AnyDesk、PuTTY、Webexなどの正規ソフトウェアになりすまし、被害者がダウンロード・実行するよう誘導された。 特に巧妙だったのが「有効期間72時間の短命証明書」の活用だ。長期証明書は証明書失効リストに載るリスクがあるが、72時間以内に攻撃を完結させれば証明書が有効なまま悪用できる。グループは1,000件以上の証明書と数百のAzureテナント・サブスクリプションを量産することで、大規模かつ持続的な攻撃インフラを構築していた。身元確認をくぐり抜けるため、米国・カナダの盗用されたIDが利用された疑いがあるとされている。 関連するマルウェア・ランサムウェアの全容 今回摘発された活動は、複数の悪名高いマルウェアキャンペーンと関連していることが明らかになっている。 情報窃取系: Lumma Stealer、Vidar、Oyster（ローダー） ランサムウェア: Rhysida、Akira、INC、Qilin、BlackByte 攻撃に関与した脅威グループとして、INC Ransomwareメンバーを含む「Vanilla Tempest」、Storm-0501、Storm-2561、Storm-0249が特定されている。 典型的な感染チェーンは次の通りだ：偽のMicrosoft Teamsインストーラーを実行 → 悪意のあるローダーが起動 → 署名済みOysterマルウェアがインストール → 最終的にRhysidaランサムウェアが展開される。Windowsが「正規ソフトウェア」と認識することで、通常であればブロックされるはずのマルウェアが初期段階をすり抜けるという構造だ。 Microsoftの対応措置 Microsoftは今回、以下の措置を実施した。 1,000件超のコード署名証明書を失効処理 signspace[.]cloudドメインを押収 数百台の仮想マシンをオフライン化 犯罪プラットフォームへのアクセスをブロック ニューヨーク南部地区連邦地方裁判所に法的措置（Vanilla Tempestを共謀者として名指し） 押収されたドメインはMicrosoftの公式説明ページにリダイレクトされており、摘発の内容が一般公開されている。Microsoftのデジタル犯罪対策部門（DCU）が業界パートナーと連携して実施した今回の作戦は、インフラ破壊から法的措置まで包括的な対応となっている。 実務への影響：日本のエンジニア・IT管理者が今すぐ確認すべきこと エンドポイント保護の見直し コード署名だけを信頼の根拠にしてはいけない。今回の事件は、署名証明書が比較的容易に不正取得・悪用できることを改めて示した。Windows Defender / EDR製品の振る舞い検知を有効化し、署名済みファイルであっても動的解析を通過させる設定を確認したい。また、Microsoft TeamsなどのアプリケーションはMicrosoft StoreまたはIntuneを通じた組織配布経路からのみインストールを許可するポリシーの導入を検討すべきだ。 Azure環境のガバナンス 自社テナントでAzure Artifact Signingを利用している場合、証明書発行ログを定期的に確認する習慣をつけたい。また、不審なAzureテナントやサブスクリプションの作成を検知するためのMicrosoft Defender for Cloudのアラート設定も見直す価値がある。 ユーザー啓発 「Microsoftの署名があるから安全」という思い込みは今回で完全に否定された。エンドユーザー向けのセキュリティ教育において、この点を明確に伝える必要がある。 筆者の見解 今回の件を見て、「よくやった」と「なぜここまで見逃したのか」が同時に頭をよぎった。 コード署名という信頼の根幹をなすインフラを不正利用され、1,000件超の証明書が発行されるまで検知・停止できなかった事実は軽視できない。「Microsoftの署名 ＝ 安全」という前提が攻撃者に徹底的に利用された形であり、正直なところもったいないと感じる。Azure Artifact Signingの設計には、このような大量不正発行を早期に検知するための仕組みが不十分だったということだ。 その一方で、DCUが法的措置を含む大規模な摘発に踏み切ったことは素直に評価したい。インフラ破壊だけでなく、裁判所への提訴とVanilla Tempestへの共謀者認定まで踏み込んだ姿勢は、業界全体への抑止効果をもたらすはずだ。 今回の根本的な教訓は「署名ベースの信頼モデルには限界がある」という点に尽きる。ゼロトラストアーキテクチャの観点では、コード署名はあくまで信頼判断の「ヒントの一つ」であって、それだけで実行許可を与えてはいけない。振る舞い検知、最小権限の実行環境、ネットワーク通信の監視——これらを組み合わせた多層防御が今こそ不可欠だ。 Microsoftにはぜひ、今回の経験をサービス設計にフィードバックしてほしい。「次に同様の悪用が始まったら数日以内に止められる」というレベルの検知・対応品質向上を、応援する立場として強く期待している。 ...

AIアプリケーション向けのオープンソースベクターデータベース「ChromaDB」の Python FastAPI 実装に、CVSS スコア 10.0（最高深刻度）の脆弱性（CVE-2026-45829）が発見された。セキュリティ企業 HiddenLayer が2月に報告したこの欠陥は、インターネットに公開されたサーバーに対して、認証なしで任意コードを実行できるという深刻なものだ。 ChromaDB とはどんなミドルウェアか ChromaDB は、LLM（大規模言語モデル）推論の際に意味的に関連するドキュメントを高速に取得するための「ベクターデータベース」だ。RAG（Retrieval-Augmented Generation）アーキテクチャを採用するエージェント型AIアプリケーションで広く使われており、PyPI からの月間ダウンロード数は約1,400万件に達する。近年の生成AIブームを背景に、スタートアップから大企業まで多数のプロジェクトで採用が進んでいる。 脆弱性の仕組み——「認証は存在するが、場所が間違っている」 HiddenLayer の分析によれば、問題の本質は認証機能の欠如ではなく、認証チェックの実行順序が誤っている点にある。 攻撃者が細工したリクエストを送ると、ChromaDB は Hugging Face から悪意ある機械学習モデルを取得してローカルで実行する。認証チェックが走るのはその後であり、時点では手遅れだ。サーバーはリクエストを拒否して HTTP 500 を返すが、攻撃者のペイロードはすでに動いている。 HiddenLayer はこれを次のように端的に表現している。「認証は実装されているが、実行される順番が間違っている。認証が発火する頃には、モデルはすでにフェッチされ実行済みだ」 こうした「チェックより先に処理が走ってしまう」設計上の欠陥は、ミドルウェアレイヤーで発生すると被害範囲が広くなりやすく厄介だ。 影響範囲と現状 対象バージョン: ChromaDB 1.0.0〜1.5.8（Python FastAPI サーバー） 非対象: ローカル限定デプロイ / Rust フロントエンド使用環境 **インターネット公開インスタンスの約73%**が脆弱なバージョンを稼働中（Shodan 調査より） バージョン 1.5.9 がリリース済みだが、本脆弱性が修正済みかどうかは執筆時点で未確認 HiddenLayer はメール・SNS 経由で複数回連絡を試みたが、開発者から返答なし 実務での対応ポイント この脆弱性への対処は「ChromaDB を使っているかどうか」の確認から始まる。 即時確認すべき事項 公開 API の棚卸し: ChromaDB の Python API サーバーポートがインターネットや社内 LAN に無防備に開放されていないか確認する バージョン確認: pip show chromadb でバージョンを確認し、1.0.0〜1.5.8 なら対応が必要 Rust フロントエンドへの切り替え: 公開が必要な環境では、影響を受けない Rust 版フロントエンドへの移行を検討する ネットワークレベルの遮断: ファイアウォールや NSG で ChromaDB API ポートへのアクセスを信頼できるホストのみに絞る ML モデルアーティファクトの事前スキャン: trust_remote_code=True でモデルをロードすることは、未検査コードをそのまま実行するに等しい。ランタイム前のスキャンを運用フローに組み込む クラウド上でRAGシステムを構築・運用しているチームは今すぐデプロイ構成を見直したい。開発環境でローカルにのみ起動しているケースは対象外だが、Kubernetes や Docker で外部公開している場合は要注意だ。 ...

セキュリティ企業Varonis Threat Labsは、Microsoft Copilot Personalを標的にした新たな攻撃手法「Reprompt」を詳細公開した。正規に見えるMicrosoftのリンクをクリックするだけで、Copilotが攻撃者のサーバーから指示を受け取り、被害者の機密データを自動的かつ段階的に外部へ送り出すという仕組みだ。Microsoftはすでにパッチを適用済みで、Microsoft 365 Copilot（エンタープライズ向け）は本攻撃の影響を受けないと明言している。 Repromptの仕組み——3つの技術の組み合わせ ① qパラメーター注入（P2P injection） 多くのAIプラットフォームは、URLのqパラメーターにテキストを含めることでプロンプトを自動実行できる機能を持つ。copilot.microsoft.com/?q=Hello にアクセスすれば「Hello」という入力が自動的に送信されるイメージだ。Repromptはこの仕組みを悪用し、攻撃者は任意の指示をURLに埋め込んで被害者に踏ませる。ChatGPTやPerplexityでも同様の問題が過去に報告されており、AI系サービスで広く見られる挙動だ。 ② 二重リクエスト技術 Copilotには、初回リクエストで直接データを外部に漏えいさせる動作を防ぐガードレールが組み込まれている。しかしRepromptは「同じ操作を2回繰り返すよう指示する」という単純な方法でこの保護をすり抜ける。ガードレールが初回リクエストにしか適用されない設計上の隙を突いた手法だ。 ③ チェーンリクエスト技術 最も巧妙なのがこの部分だ。最初の指示が実行されると、攻撃者のサーバーが前の応答内容に基づいて次の指示を動的に生成する。「今日アクセスしたファイルを要約して」→「そのファイルの中の個人情報を列挙して」→「連絡先を外部URLに送信して」という連鎖が、ユーザーが何もしないまま静かに進行する。クライアント側の監視ツールでは、初回プロンプトしか見えないため流出の全体像を把握できない。 実務への影響 今回の攻撃がエンタープライズ向けMicrosoft 365 Copilotに影響しない点は重要な事実だが、個人アカウントで業務データにアクセスしている社員がいる組織では対岸の火事ではない。「自宅PCからMicrosoftの個人アカウントで業務ファイルを開いている」という状況はよくある話だ。 IT管理者が取るべき実務上の対応は以下の通り： ブラウザとOSのアップデートを即時適用する（パッチはリリース済み） 従業員への注意喚起：見慣れたMicrosoft.comのURLであっても、送られてきたリンクは慎重に扱う 個人アカウントと業務アカウントの分離ポリシーを改めて徹底する ゼロトラスト観点からの定期監査：Copilotのセッションログをどこまで取得・監視できるか確認する 筆者の見解 Repromptが興味深いのは、プラグインやコネクターといった拡張機能を一切使わず、AIプラットフォームのデフォルト機能だけで完結している点だ。これは「外部連携を切ればAIは安全」という発想が根本的に誤っていることを示している。 ゼロトラストの観点からすると、AIアシスタントに付与された「ユーザーのデータにアクセスできる権限」そのものが攻撃面になる。Just-In-Time（JIT）アクセスの考え方をAIエージェントにも適用し、必要なタイミングにのみ必要なスコープだけを与える設計が求められる。今後、Non-Human Identity（NHI）管理とAIエージェントの権限設計は不可分のテーマになるだろう。 Microsoftがパッチを迅速に対応した点は評価に値する。ただ、qパラメーターのような「便利な設計」が攻撃面になるケースはAI系サービス全般に共通する課題だ。Copilotには実力があるのだから、こういった脇の甘さを一つひとつ潰して、エンタープライズでも個人向けでも安心して使える環境を整えてほしい。応援している分だけ、期待値も高い。 出典: この記事は Reprompt: The Single-Click Microsoft Copilot Attack that Silently Steals Your Personal Data の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft は2026年5月7日、Microsoft 365 CopilotおよびMicrosoft EdgeのCopilot Chatに影響するCritical評価の情報漏洩脆弱性を3件公開し、同日中にクラウド側での修正を完了した。エンドユーザーや管理者による追加対応は不要とされているが、Copilotに付与されたデータアクセス権限の設計を見直す契機として受け止めるべき事案だ。 3件の脆弱性——何が起きていたのか 今回公開されたのはCVE-2026-26129、CVE-2026-26164、CVE-2026-33111の3件で、いずれも機密情報漏洩（Information Disclosure）を引き起こしうるインジェクション系の脆弱性だ。 CVE-2026-26129 はMicrosoft 365 CopilotのBusiness Chat機能が対象。ダウンストリームコンポーネントへの出力で特殊文字が適切に処理されない（CWEでいうインジェクション系）ことで、ネットワーク経由で機密情報が漏洩する可能性があった。 CVE-2026-26164 も同じくM365 Copilotを対象とし、CWE-74（インジェクション）に分類される。攻撃ベクターはネットワーク経由、特権不要・ユーザー操作不要という条件で、CVSS スコアは7.5（時間的スコア6.5）。機密性への影響は「高」と評価されている。Microsoftの社内研究者であるEstevam Arantesと独立研究者の0xSombraの連名で発見が報告された。 CVE-2026-33111 はMicrosoft Edgeに組み込まれたCopilot Chat機能に影響し、CWE-77（コマンドインジェクション）に分類される。CVSSスコアはCVE-2026-26164と同じく7.5/6.5で、攻撃プロファイルも同様。エンタープライズ環境でEdgeの展開が広がっていることを考えると、潜在的な影響範囲は無視できない。 Microsoftは「いずれも公開前の悪用は確認されていない」と明言しており、クラウド側のサービス層でパッチを適用済みだ。 なぜAIツールが情報漏洩リスクの新たな標的になるのか 今回の事案が単なるパッチ情報以上の意味を持つのは、Microsoft 365 Copilotというサービスの性質にある。 Copilotはユーザーの指示に応じてメール、ドキュメント、Teamsの会話、SharePointのファイルなど、組織内の膨大なデータを横断的に参照・要約する。つまり、単一エンドポイントへの攻撃が、従来のファイルサーバー侵害では得られなかった「横断的な情報収集」を可能にしてしまう構造になっている。 インジェクション系の脆弱性がAIの出力パイプラインに潜むと、攻撃者はCopilotが生成したレスポンスの中に細工された要素を混入させ、信頼境界を越えて機密情報を引き出せる可能性がある。メールの内容、社内の機密文書、制限付き記録などが、正規ユーザーに成りすました形で漏洩しうる。 日本の企業IT担当者がすべき対応 「クラウド側で修正済みだから終わり」で済ませてほしくない事案だ。具体的に確認しておくべき点を挙げる。 1. Copilotのアクセス権限を最小化する Copilotは設定次第で組織内のほぼすべてのデータにアクセスできる。「使いやすさ」優先でデフォルトのまま運用している場合、脆弱性が悪用されたときの影響範囲が最大化してしまう。SharePointの権限設計、センシティブなラベル付きコンテンツへのCopilotアクセス制御を今すぐ確認すること。 2. Microsoft Purview との連携を確認する Microsoft Purviewの機密ラベル（Sensitivity Labels）を正しく設定していれば、CopilotはラベルベースのDLP（データ損失防止）ポリシーに従って動作する。ラベル付けが不完全な環境では、攻撃面は広いままだ。 3. Edge の Copilot Chat の利用範囲を把握する CVE-2026-33111はEdge組み込みのCopilot Chatに関するものだ。エンタープライズ向けにEdgeを標準ブラウザとして展開している組織では、Copilot Chatの機能制限ポリシー（EnterpriseNewTabPageHideDefaultTopSites や Copilot 関連のグループポリシー）を整備しておくことを勧める。 4. 今後の同種脆弱性に備えた監視体制を構築する MicrosoftはクラウドCVEの透明性イニシアティブとしてこれらを公開している。同様の開示が今後も続く可能性が高い。Microsoft Security Response Center（MSRC）のフィードを定期的に監視し、Copilot関連の更新情報をキャッチアップする運用フローを確立しておこう。 筆者の見解 Microsoftが今回の脆弱性を「クラウドCVE透明性プログラム」として積極的に開示したこと自体は、正しいアプローチだと思う。悪用の事実なし、ユーザー対応不要、公開と修正を同日実施——この対応のスピードと透明性は評価に値する。 ただ、根本的な問いは別にある。「AIが組織データを横断的に集約・処理する」というアーキテクチャそのものが、インジェクション系脆弱性と組み合わさったとき、従来のエンドポイント侵害では得られなかったレベルの情報収集を攻撃者に提供してしまう——この構造的リスクに、われわれは真剣に向き合う必要がある。 Copilotにブロードなアクセス権を付与して「AIがなんでも答えてくれる」状態を作るのは、セキュリティの観点ではJust-In-Timeとは真逆の設計だ。「常時アクセス可能」が特権アカウント管理における最大リスクであるのと同じ原則が、AIエージェントにも適用される。Non-Human Identityとしての Copilot にどこまでアクセスを許可するか——この問いを真剣に設計フェーズで議論していた組織は、今回の件でもリスクを最小化できていたはずだ。 Microsoftには、Copilotの権限モデルと最小権限設計を、もっとわかりやすく・導入しやすい形でユーザーに提供してほしい。技術的には実現できる力がある会社なのだから、セキュリティを後付けではなくアーキテクチャの中心に置いた設計を見せてくれると、Copilot全体への信頼回復にも繋がるはずだ。 出典: この記事は Critical Microsoft 365 Copilot Vulnerabilities Expose Sensitive Information の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...