Windows

Intelの次世代デスクトップCPU「Nova Lake-S」の仕様が流出し、AMD Zen 5を上回る可能性が示唆されている。特に注目されるのは大幅に拡張されたキャッシュ設計で、長らく続いてきたIntel対AMDの覇権争いに再び火がついた格好だ。正式発表前の情報ではあるが、その方向性はCPU市場の今後を占ううえで見逃せない。 Nova Lake-Sが狙う「巨大キャッシュ」戦略 流出した情報によると、Nova Lake-SはCPUキャッシュ（特にL3）を前世代から大幅に拡充する設計を採用するとみられている。キャッシュとはメインメモリよりもはるかに高速なCPU内蔵の一時記憶領域であり、容量が増えるほどメインメモリへのアクセス頻度が下がり、全体的なスループットが向上する。 AMDはZen 4世代で「3D V-Cache」と呼ばれる積層キャッシュ技術を投入し、ゲーミングや科学技術計算などのワークロードで劇的な性能向上を実現した。Intel Nova Lakeのアプローチはこれに対抗すべく、異なる手法で同様の効果を狙っているとみられる。 Arrow Lakeからの進化と競争環境 Nova Lakeは現行のArrow Lake（Core Ultra 200シリーズ）の後継にあたる。Arrow Lakeは消費電力の最適化に注力したアーキテクチャだったが、シングルスレッド性能では一部のシナリオでAMDに後れを取る場面もあった。Nova Lakeはその弱点を正面から補う構成を志向しているとの見方が強い。 なお、現時点での情報はあくまで未確認の流出仕様であり、正式発表ではない。リーク情報の精度にはばらつきがあるため、具体的な数値は参考程度にとどめておくのが賢明だ。 実務への影響——日本のIT管理者が押さえるべきポイント 開発機・ワークステーション選定への直接影響 AIモデルの推論処理、大規模コンパイル、動画編集など、CPUキャッシュ性能が生産性に直結するワークロードを扱う開発者や技術者にとって、Nova Lakeが約束する性能向上は選定の選択肢を広げる可能性がある。現在の調達サイクルと照らし合わせながら、発表タイミングを意識しておく価値はある。 競争激化による価格効果 IntelとAMDの競争が熾烈になるほど、両社の製品価格は妥当な水準に落ち着きやすくなる。IT部門の調達担当者にとって、競争環境の維持は実質的なコスト削減につながる。このこと自体を「良いニュース」と捉えておくべきだ。 サーバー市場への波及を中長期で注視 デスクトップ向けアーキテクチャの技術革新は、次世代サーバー向けCPU（XeonやEPYCの後継）にも波及する。データセンター向けCPUの調達計画を持つ組織は、Nova Lakeの正式発表後のベンチマーク情報を参考情報として収集しておくことを勧める。 筆者の見解 CPU競争の文脈では「どちらが優れているか」という二項対立で語られがちだが、筆者が重視するのはシンプルなことだ。「競争が続くこと自体が、ユーザーにとっての最大の果実」である。 Intelはここ数年、製造プロセスの遅れや世代ごとの性能停滞で厳しい評価を受けてきた。しかし今回の流出仕様が示す方向性は、技術的な正面突破を狙う姿勢が感じられる。元来、Intelには底力がある。正面からやり合えば十分に勝負になる力を持っているからこそ、この取り組みには素直に期待したい。 ただし、IT部門の実務判断においては、性能数値のみで飛びつくのは禁物だ。新しいアーキテクチャには、ドライバーの成熟度、管理ツールとの整合性、長期サポートの見通しといった「運用コスト」が必ずついてまわる。Nova Lakeが正式発表された際には、ベンチマーク数値と同等の比重で、エコシステムの安定性をトータルで評価することを強く推奨する。流出情報に一喜一憂するよりも、正式発表後に冷静に判断する姿勢が、実務では正解に近い。 出典: この記事は Alleged Intel “Zen 5 killer” Nova Lake specs suggest AMD’s hardest battle could be coming up の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GDC（Game Developers Conference）2026において、MicrosoftはWindows 11向け「Xbox Mode」の正式リリースを来月に予定していることを発表した。単なるゲーミング機能の追加にとどまらず、次世代Xbox構想「Project Helix」の礎を築く戦略的な一手として注目される。 Xbox Modeとは何か Xbox ModeはWindows 11上でコンソールライクなゲーミング体験を実現するための動作モードだ。有効化すると、バックグラウンドで動作する不要なプロセスやサービスを自動的に最小化し、GPU・CPU・メモリのリソースをゲームに集中させる。これにより、同一ハードウェアでも体感フレームレートや安定性が改善されることが期待される。 コンシューマー向けの見た目は「ゲームに最適化したモード」だが、その本質はOSレベルでのリソース管理ポリシーの切り替えだ。コンソール機が専用OSで高い最適化を実現しているのと同様の考え方をWindowsに持ち込もうとしている。 Project Helixが示す長期ビジョン Project Helixは、PCとXboxコンソールの体験を統合するMicrosoftの長期戦略の開発コードネームとされる。かつてのオリジナルXboxがWindowsベースの設計思想を持っていたことを元幹部が証言しているように、PCとコンソールの境界線を取り払うことはMicrosoftにとって「悲願」とも言える構想だ。 Game Pass、Xbox Play Anywhere、クロスプレイの整備と合わせると、Xbox ModeはそのProject Helixを実現するための「OS側の受け皿」として機能する。プラットフォームをまたいで同一タイトルを最適な環境でプレイできるエコシステムが、着実に形成されつつある。 日本のエンジニア・IT管理者への影響 ゲーミングと無縁に思えるかもしれないが、Xbox Modeの仕組みは企業IT視点でも興味深い。 リソース管理の応用可能性: 特定ワークロード向けにOSのバックグラウンドプロセスを絞り込む考え方は、高負荷な映像処理・データ分析・シミュレーション環境でも応用が効く。Windowsのリソース管理ポリシーがどこまで柔軟に設計されているかを知る上でも参考になる。 エンドユーザーへの影響を把握する: 企業の従業員がWindows Updateで自動的にXbox Modeを受け取るケースも想定される。有効化条件や影響範囲を事前に把握し、業務PCへの影響がないかを確認するのが賢明だ。 開発者向けAPI・SDK対応: ゲーム開発者はDirectX最適化やXbox GDK（Game Development Kit）との整合を見直す好機。Project Helixの方向性を踏まえてPC・コンソール両対応の開発フローを整備しておくことが、今後の工数削減につながる。 筆者の見解 Windowsの細かい機能アップデートを逐一追う意義が薄れている昨今、Xbox Modeは珍しく「腰を据えて見るべき動き」だと思っている。 理由はシンプルで、これは機能追加ではなくプラットフォーム戦略の具現化だからだ。PCとコンソール、Windowsとゲームエコシステムを統合する構想は、MicrosoftのAzure・M365・Surfaceにまたがる「統合プラットフォーム」思想と軸が一致している。部分最適の積み重ねではなく、全体として一貫したユーザー体験を設計しようとする意思が見える。 Project Helixが成熟すれば、「PCかコンソールか」という問いが意味を持たなくなる世界が来るかもしれない。ゲーマー視点だけでなく、エンタープライズにおけるデバイス管理・リソース最適化の文脈でも影響が出てくる局面が想定される。Microsoftにはこういったプラットフォーム統合を正面から形にできる技術力と規模がある。それを活かした展開に、今後も注目していきたい。 出典: この記事は Microsoft brings new “Xbox mode” to Windows 11 PCs next month — Prepares major gaming advancements that lay foundations for the next Xbox の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows Insider Programを大幅に再編する。これまでCanary・Dev・Beta・Release Previewの4チャンネルが存在していたが、2026年4月の発表により、主要チャンネルをExperimentalとBetaの2つに整理する方針が明らかになった。Insider参加者からの「チャンネルの違いがわかりにくい」というフィードバックが直接の契機だという。 チャンネル再編の全貌 Experimental チャンネル（旧 Dev + Canary） 旧来のDevチャンネルとCanaryチャンネルが統合され、Experimentalチャンネルに一本化される。位置づけは「まだ開発中の機能への早期アクセス」であり、登場した機能が最終的にリリースされるかどうかは保証されない。 Experimentalチャンネルには、さらにFuture Platformsというサブオプションが用意される。特定のOSバージョンに紐づかない、プラットフォーム開発の最先端ビルドを試したいユーザー向けの位置づけだ。一方、最新機能にいち早く触れたいInsiderには、製品版に近いビルドへの参加が推奨されている。 Beta チャンネル（大きく変わる点） 今回の発表で最も注目すべきはBetaチャンネルにおけるControlled Feature Rollout（段階的機能ロールアウト）の廃止だ。 これまでのBetaチャンネルでは、同じアップデートをインストールしていても、ユーザーによって有効になる機能が異なるケースがあった。Microsoftがフィーチャーフラグを使って一部ユーザーのみに新機能を展開する仕組みを採用していたためだ。 変更後は、Betaチャンネルでアップデートをインストールしたユーザー全員が、発表された機能を同じタイミングで受け取れるようになる。テスト環境の一貫性が高まり、コミュニティ内でのフィードバック共有がしやすくなるのは明確なメリットだ。 Experimental チャンネル向け「Feature flags」ページ Experimentalチャンネルのユーザーには、Windows Insider Program設定内にFeature flagsページが新たに追加される。Insider向けブログで発表済みの機能について、個別にオン・オフを切り替えられる仕組みだ。バグ修正やシステムレベルの変更はカバーしない場合があるとMicrosoftは説明しており、あくまで「表に見える新機能」のコントロールが主眼となっている。なお、このページの提供開始時期はまだ発表されていない。 Release Preview チャンネルは継続 Release Previewチャンネルは引き続き提供される。正式リリース直前のビルドを先行確認したい商用顧客やInsiderが対象で、Windows Insider Program設定の「詳細オプション」から有効化する手順に変更はない。内容自体に変更はないと明示されている。 実務への影響 IT管理者・検証担当者にとっての意味 Betaチャンネルで「同じアップデートを入れているのに機能の有無がバラバラ」という状況が解消されることで、社内での検証報告の精度が上がる。「私の環境では出た／出なかった」という差異が減り、チーム内でフィードバックを集約しやすくなる。 ただし実務での注意点もある。段階ロールアウトが廃止されるということは、Betaチャンネルに参加している全端末が同時に新機能を受け取ることを意味する。段階展開はリスク分散の手段でもあったため、Betaへの参加規模が大きい環境では、問題が一気に顕在化する可能性もある。検証機の台数や範囲は改めて見直しておきたい。 Release Previewチャンネルは、本番展開前のファイナルチェック用として引き続き活用できる。エンタープライズ環境でWindowsの展開サイクルを管理している担当者は、このチャンネルを主軸に置く運用方針で問題ない。 開発者・個人Insiderへの影響 ExperimentalチャンネルのFeature flagsは、特定機能だけを試したい開発者には便利な仕組みになりうる。一方で、フラグでコントロールできる範囲はあくまで「発表済みの表向きの機能」に限られる。低レイヤーの変更は引き続きブラックボックスだ。 筆者の見解 正直に言って、Windowsのチャンネル構成の細部を追うことに以前ほどの熱量はない。それでも今回の変更には素直に「わかりやすくなった」と感じる部分がある。 4チャンネルを2チャンネルに整理するという判断はシンプルで合理的だ。Dev/Canaryを統合してExperimentalにまとめたのは、利用者の混乱を減らすという意味で正しい方向だと思う。 Betaの段階ロールアウト廃止も、検証環境の一貫性向上という観点では歓迎できる。ただ、これを「テスト品質の向上」と読むか、「段階展開という安全策を外した」と読むかは立場によって変わる。Insider参加者の規模が大きい組織では、後者のリスクを意識しておく必要がある。 MicrosoftにはWindowsのテスト基盤を整える技術力も知見も十分にある。今回のようなプログラム設計の見直しを地道に重ねていくことが、最終的にはリリース品質への信頼につながる。「更新したら壊れた」という経験を繰り返してきた管理者の声に、こういった形で応えてくれるのは良いことだ。実際の品質改善として結果が出ることを期待したい。 出典: この記事は Microsoft Simplifies Windows Insider Program to Two Channels and Ends Gradual Feature Rollouts in Beta の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11の目玉AI機能として発表した「Recall（リコール）」が、波乱含みのリリースから約1年を迎えた。しかし現実は厳しく、全Windows 11 PCのうちRecallを有効化できる端末は10%未満にとどまっている。数字だけ見れば「普及率の問題」に映るが、その背景には今なお解消されていない根本的なセキュリティ上の懸念がある。 Recallとは何か、なぜ問題になったのか RecallはPC上のあらゆる操作をスクリーンショットとして継続的に記録し、AIが意味を解釈して後から自然言語で検索できる機能だ。「あのときブラウザで見ていたページを探したい」「数週間前に編集した書類の内容を知りたい」といったユースケースを想定している。 リリース直後から、セキュリティ研究者が重大な懸念を指摘した。PC上のすべての操作履歴が実質的に平文に近い形でローカルに蓄積されるため、マルウェアや攻撃者にとって「ユーザーの全行動ログ」という極めて価値の高い標的になり得るという点だ。Microsoftは機能の有効化にWindows Hello認証（顔認証・指紋認証）を必須にするなどの対策を講じたが、独立した研究者からは「暗号化の設計が不十分」「一度認証を突破すれば履歴データに容易にアクセスできる」との指摘が続いている。 Microsoft側は「脆弱性は存在しない」との立場を崩していない。しかしこの見解の乖離が1年経っても埋まっていないこと自体が、問題の根深さを物語っている。 なぜこれが重要か 日本のIT現場にとって、Recallは「まだ関係ない機能」ではない。企業が管理するWindows 11端末にもRecall対応ハードウェア（Copilot+ PC）が徐々に普及しつつある。デフォルトではオフとはいえ、ユーザーが誤って有効化するリスク、あるいは将来のポリシー変更でデフォルトが変わるリスクを、IT管理者は今から把握しておく必要がある。 とりわけ機密情報を扱う環境——金融、医療、法務、製造の設計部門など——では、業務中の画面操作がすべてローカルに記録され続けるという設計は、情報セキュリティポリシーと根本から矛盾しかねない。 実務での活用ポイント IT管理者向け Microsoft Intune（エンドポイントマネージャー）のポリシーでRecallを組織レベルで無効化するCSP（User Rights: DisableAIDataAnalysis相当の設定）の適用を検討する Copilot+ PC調達時に、Recall関連の設定がデフォルトでどうなっているかをベンダーに確認し、キッティング手順に組み込む 社内のデータ分類ポリシーにRecallの有効化可否を追加し、端末用途によって制御を変える設計を検討する エンジニア向け 開発端末でRecallを使う場合、APIキーやシークレットが画面上に表示される操作は記録対象になり得ることを意識する。ターミナルや認証フローを含む操作の扱いには注意が必要 ゼロトラストの観点で言えば、「ローカルに全操作ログが存在する」状態はラテラルムーブメント（横展開攻撃）の攻撃面を広げる。エンドポイントのEDR設定と組み合わせて考えるべき問題だ 筆者の見解 Recallは、構想自体は面白い。「PCの使用履歴をAIが意味のある形で整理して後から引き出せる」という方向性は、人間の認知限界を補う発想として本質的に正しいと思う。 だから余計にもったいない。設計の根幹にあるべき「この機能によってユーザーのセキュリティリスクが上がってはいけない」という原則が、リリース時点で不十分だったことは明らかだ。そして1年後もセキュリティ研究者との見解の乖離が解消されていないという状況は、設計レベルでの対話が十分にできていないことを示唆している。 企業向けのIT基盤をMicrosoftで統一しているユーザーとして、率直に言う。「脆弱性なし」と言い切るなら、その根拠を独立した第三者が検証できる形で示すべきだ。Microsoftにはその技術力も信頼の蓄積もある。正面から向き合える力があるのだから、研究者コミュニティとの対話を通じて設計の正しさを証明していく姿勢を見せてほしい。 導入率10%未満という数字は、ユーザーの判断が今のところ正常に機能していることを示しているとも読める。だが「あとで有効にすればいい」の積み重ねは、ある日突然セキュリティインシデントに転化する。IT管理者は今のうちに組織としての方針を定めておくことを強くお勧めする。 出典: この記事は One year after its rocky launch, Microsoft’s Windows Recall still raises security red flags の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ファイルエクスプローラーで「ダウンロードフォルダーを特大アイコン表示に設定したのに、Edgeから『フォルダーを開く』で開くと詳細表示に戻っている」——この現象に何年も悩まされてきた方は多いはずだ。Microsoftがついにこの長年の挙動を修正した。Build 26200.8313（KB5083631）がRelease Previewチャンネルに展開され、フォルダービューの一貫性が大きく改善された。 何が変わったのか 今回の修正により、ファイルエクスプローラーで設定したフォルダービューの設定——並び順、グループ化の有無、アイコンサイズ、レイアウト——が、フォルダーの開き方にかかわらず維持されるようになった。 これまでの挙動では、ファイルエクスプローラー上で「名前順・グループ化なし・特大アイコン」と設定したダウンロードフォルダーを、ブラウザや別のアプリから「フォルダーを表示」で開くと、設定が別の状態に戻ってしまうことがあった。毎回手動で直すのが当たり前になっている人も少なくないだろう。 なぜ今まで直らなかったのか 技術的な背景として、ファイルエクスプローラーはフォルダービューの設定を「Shell Bags」と呼ばれるレジストリの仕組み（BagsキーおよびBagMRUキー）に保存している。この設定は「フォルダーそのもの」ではなく、「どの経路でそのフォルダーにアクセスしたか」に紐付けられている点が問題だった。 ファイルエクスプローラー上から直接開く場合と、別のアプリから「Show in folder」などのシェル呼び出しで開く場合では、Windowsが内部的に異なるシェルコンテキストとして扱うことがあった。その結果、同じフォルダーでも異なる「Bag」が参照され、ビュー設定が食い違う——これが根本的な原因だ。バグではなく設計上の限界だったわけで、修正に時間がかかったのも納得できる。 その他の改善点 KB5083631にはビュー一貫性の修正以外にも実用的な改善が含まれている。 起動パフォーマンスの向上: エクスプローラーの立ち上がりが高速化 ダークモードの白フラッシュ軽減: 長年報告されていたダークモード時の一瞬の白画面が改善 対応アーカイブ形式の追加: uu、cpio、xar、nupkgが新たにサポート explorer.exe の安定性向上: ウィンドウを閉じる際の信頼性が改善 なお、モダンな検索バーのUIリニューアルはCanaryビルドで先行テスト中であり、正式展開時期は未定だ。 実務への影響 日常的にエクスプローラーを使う一般ユーザーはもちろん、複数のアプリケーション間でファイル操作を行う機会が多い開発者・エンジニアにとっても恩恵は大きい。 特に以下のシナリオで差を実感しやすい： ダウンロードマネージャーや開発ツールからのフォルダー参照: IDEやビルドツールの「出力フォルダーを開く」ボタン経由でエクスプローラーを開いても、設定通りのビューが保たれる 複数ウィンドウ・マルチタスク環境: 異なるアプリから同じフォルダーを開くたびにビューが変わるストレスがなくなる チームへの展開: 標準化したフォルダービューが意図した通り保持されるようになり、操作手順書やサポート対応が簡略化できる可能性がある Release Previewチャンネルでの提供が始まったことから、2026年5月中には通常のWindows 11環境への展開が見込まれる。企業環境で急いで適用する必要はないが、動作確認の優先度は低くて構わないだろう。 筆者の見解 正直に言えば、Windowsをかつてのように細かく追いかける意味は薄れてきている。しかし今回の修正は、地味ながら「これを直してほしかった」という声が長年上がり続けていたものだ。技術的にはShell Bagsの設計に起因する根深い問題だっただけに、修正コストは決して小さくなかったはずで、その判断と実行は素直に評価したい。 この種の「細かいけれど毎日引っかかるUI改善」は、Microsoftが本来得意としてきた領域だ。派手な新機能だけでなく、こういった積み重ねがプラットフォームとしての信頼につながる。正面から勝負できる地力はMicrosoftには間違いなくある。基本体験を着実に磨いてほしい——そう思う。 なお、「ちょっと様子を見てから適用する」判断も依然として有効だ。Windows Updateは数日待ってから適用する慎重さが、結果的にリスクを下げることも多い。焦って当てる必要はない。 出典: この記事は Windows 11 finally fixes inconsistent folder views in File Explorer の内容をもとに、筆者の見解を加えて独自に執筆したものです。

JavaScriptエコシステムの根幹を担うライブラリに、見過ごしてはいけない重大な欠陥が発見された。npmで週平均約5000万回ダウンロードされる protobuf.js に、任意コード実行（RCE）を可能にする脆弱性が存在することが明らかになった。しかもPoC（概念実証コード）はすでに公開されており、攻撃の敷居は決して高くない。 protobuf.jsとは何か Protocol Buffers（Protobuf）はGoogleが開発したバイナリシリアライズ形式で、マイクロサービス間通信やリアルタイムアプリ、クラウド環境でのデータ格納に広く使われている。protobuf.js はそのJavaScript/TypeScript実装であり、Node.jsベースのバックエンドや各種クラウドファンクションに深く組み込まれているケースが多い。「使ってるつもりのないライブラリ」として依存関係の奥底に潜んでいることも珍しくない。 脆弱性の仕組み 今回の脆弱性はGitHub Security Advisory ID GHSA-xq3m-2v4x-88gg として追跡されている（CVE番号は未採番）。アプリケーションセキュリティ企業Endor Labsが4月18日に詳細レポートを公開した。 問題の本質は 動的コード生成の不備 だ。protobuf.js はprotobufスキーマからJavaScript関数を生成する際、文字列を連結した上で Function() コンストラクタを通じてそのまま実行する設計になっている。ここでメッセージ名などのスキーマ由来の識別子をサニタイズしていないため、攻撃者が細工したスキーマを与えると任意のコードを生成関数に埋め込むことができる。 具体的な攻撃シナリオはこうだ： 攻撃者が悪意あるスキーマを用意する アプリケーションがそのスキーマを読み込む スキーマ処理時に埋め込まれたコードが実行される 環境変数・認証情報・内部データベースへのアクセスが可能になり、インフラ内の横展開（ラテラルムーブメント）にまで至る サーバーサイドだけでなく、開発者のローカルマシンが攻撃対象になるケースも想定されている。信頼できないスキーマをローカルでデコードする習慣がある開発環境は要注意だ。 影響バージョンと修正版 ブランチ 影響バージョン 修正版 npm反映日 8.x 8.0.0以下 8.0.1 2026-04-04 7.x 7.5.4以下 7.5.5 2026-04-15 脆弱性報告は3月2日、パッチのGitHub公開が3月11日、npmへの反映が4月4日（8.x）と4月15日（7.x）だ。npm反映まで最大6週間のラグがあった点は覚えておいてほしい。 修正の内容はスキーマ識別子から英数字以外の文字を除去するサニタイズ処理の追加だが、Endor Labsは「長期的には Function() に攻撃者が到達できる識別子を通さない設計に変えることが根本対策」と指摘している。現在のパッチは「有効だが暫定的」と見るべきだろう。 実務への影響 今すぐやること： npm list protobuf または npm ls protobufjs で直接・間接の依存を確認する 使用中なら 8.0.1 または 7.5.5 に即時アップグレード 直接依存でなくても推移的依存（transitive dependency）として含まれている可能性があるため、npm audit でのスキャンも実施する 中期的に取り組むこと： スキーマのロードを「信頼できない入力」として扱う設計に見直す。外部から受け取ったスキーマを動的に読み込む構成は本質的にリスクを持つ 本番環境では コンパイル済み・静的スキーマを優先する（Endor Labsも同様に推奨） 依存ライブラリの定期監査をCI/CDパイプラインに組み込む。今回のようにPoC公開後に初めて気づく状況は避けたい サプライチェーンリスクの観点： ...

MicrosoftがFintoolを買収し、Officeプロダクトグループへの統合を進めると発表した。Fintoolは財務データの分析・解釈に特化したAIツールを提供してきたスタートアップで、今回の買収によってExcelをはじめとするMicrosoft 365アプリに「財務AIエージェント」機能が組み込まれることが期待されている。 これはMicrosoftがCopilotブランドの外側でも、領域特化型AIを着実に取り込もうとしている動きとして注目に値する。 Fintoolとは何者か Fintoolは財務レポートや決算情報をAIで読み解き、自然言語で質問・分析できるツールとして一部の金融・投資プロフェッショナルの間で評価されていたサービスだ。単なるデータ可視化ツールではなく、決算短信や有価証券報告書のような非構造化テキストを含む財務情報を横断的に解析できる点が特徴だった。 ExcelにAIエージェントが統合されると何が変わるか これまでのExcel Copilotは「セル範囲を選択して要約して」「グラフを作って」といったUIアシスタント的な機能が中心だった。Fintoolの技術が統合されれば、以下のようなユースケースが現実的になってくる。 財務諸表の自動読み解き: PDFやWebから取得した決算情報をExcel上で直接解析し、前年比・業界比較などを自動生成 エージェント的な自律処理: 「Q2の営業利益率が低下した原因を調べて」という指示に対して、複数シートや外部データを横断しながら仮説を提示 CFO・経理担当者向けの自然言語インターフェース: 数式やVBAを知らなくても、財務分析の専門的な問いに答えられる環境 MicrosoftはこれをOfficeプロダクトグループ直轄で開発するとしており、Copilot Studioやその他の外部向けツールとしてではなく、Excelネイティブの機能として届けることを示唆している。 実務への影響——日本のエンジニア・IT管理者にとっての意味 日本企業における財務業務のIT化は、ERPやBIツール導入が進んでいる一方で、現場では依然としてExcelが中心だ。「Excelで管理する文化」は批判されることも多いが、現実的にはExcelがデータのハブになっているケースが大多数だろう。 その意味で、今回の機能強化は「Excelをやめる」ではなく「Excelのまま高度な分析ができる」という方向性で、日本の現場親和性は高い。 実務担当者として押さえておきたいポイントは以下の通りだ。 ライセンス要件の確認: 財務AIエージェント機能がどのCopilotライセンス層に含まれるかは現時点で未公表。M365 Copilotの上位SKUやアドオンになる可能性がある データガバナンスへの対応: 財務データをAIが参照する際のテナント境界・コンプライアンス対応は必須。Microsoft 365のデータ主権設定を今のうちに整備しておくことを勧める 経理・財務担当者へのキャッチアップ支援: ツールが来てから「使い方がわからない」とならないよう、IT部門が先行してユースケースを把握しておくと展開がスムーズになる 筆者の見解 正直なところ、ExcelはMicrosoftの中でいまも最強のプロダクトだと思っている。WordもPowerPointも侮れないが、「Excelなしではビジネスが回らない」という現場の重力は他の追随を許さない。 そのExcelに財務特化のAIエージェントを組み込む——この方向性は正しいと思う。汎用のCopilotに何でもやらせようとするよりも、領域に精通した専門AIをプラットフォームに乗せていく戦略のほうが、実務使用に耐えられるレベルに早く届く。Fintoolの買収はその具体的な一手だ。 課題があるとすれば、「機能が来ても使われない」というMicrosoft 365のCopilot機能全般に共通する展開の難しさだ。財務部門はIT部門とは文化が異なり、新しいツールへの抵抗感も強い場合が多い。技術的な統合の品質と同じくらい、「現場が自然に使い始めるUX」と「ITが安心して展開できるガバナンス」の両立がこの機能の成否を分けると見ている。 Microsoftはこういう縦深のある買収を積み重ねられる力を持っている。その力をプラットフォームの一貫性に注いでいけば、M365は「使い続ける理由のある環境」としての地位をさらに確固たるものにできるはずだ。 出典: この記事は Microsoft acquires Fintool to supercharge Excel with financial AI agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが2026年春の定例大型アップデートとして「Windows 11 April 2026 Update」を展開中だ。セキュリティパッチとしか認識されがちな月例更新とは異なり、今回はパフォーマンス最適化とユーザー体験（UX）の刷新が中心テーマとなっている。日常的に使うSettingsアプリやFile Explorerから、アクセシビリティ機能のNarratorまで、幅広い領域に手が入っており、地味ながら実務への影響は小さくない。 パフォーマンス最適化の中身 今回のアップデートで最も数字として明確なのが、メモリ使用量の最大15%削減だ。メモリ管理アルゴリズムを刷新し、典型的な利用シナリオでのRAMフットプリントを減らす設計になっている。これは特にメモリ搭載量が限られるエントリークラスのノートPCや、複数VDI（仮想デスクトップ）セッションを同時稼働させるエンタープライズ環境で効いてくる。 合わせてCPUスケジューリングも改良されており、フォアグラウンドアプリへの優先度割り当てが改善された。ブラウザで調べ物をしながらExcelを操作するような「並行作業」での応答性向上が期待できる。統合GPU（iGPU）を持つシステムでは、グラフィックスサブシステムの改善によりアプリのレンダリングも滑らかになるとされており、ハイエンドGPUを積んでいない法人PCでもメリットが出やすい。 UX改善：Settingsとファイル管理が中心 Settingsアプリは起動速度の大幅改善に加え、UI構造の再編成が実施された。「あの設定項目、どこにあるんだっけ」という状況が減るよう、よく使う設定へのアクセスが合理化されている。サポートデスクに問い合わせが来やすい設定変更のフローが短縮されれば、ヘルプデスクコストの削減にもつながる。 File Explorerではバグ修正が中心で、大量ファイルを含むフォルダのブラウジング時のパフォーマンスが向上した。加えてナビゲーション機能が拡張されており、深い階層のフォルダ構造を扱う際の使いやすさが増している。 スタートメニューの検索機能も改善対象となっており、アプリやファイルの発見速度が上がっている。「Windows検索で出てこないからデスクトップに全部並べる」という運用を改善する足がかりになりそうだ。 アクセシビリティ強化：Narrator × Copilot連携 今回の注目機能のひとつがNarrator（ナレーター）へのCopilotサポート追加だ。スクリーンリーダーにAI支援を組み合わせることで、画面読み上げの文脈理解精度が向上する。障害を持つユーザーへの配慮として正しい方向だし、多様性・包括性（DE&I）を重視する企業のIT調達方針にも合致する。 エンタープライズ向け管理機能の拡充 IT管理者にとって押さえておくべき変更がグループポリシーとWindows Update for Businessの強化だ。アップデート展開のスケジューリング柔軟性が増し、段階的なロールアウトの制御がより細かくできるようになる。また、Windows DefenderとMicrosoftのクラウドセキュリティサービスとの統合が改善されており、セキュリティ運用の負荷軽減が見込まれる。 実務への影響 展開判断のポイントとして、まず自組織のWindows Update for Businessポリシーを確認しておきたい。今回のアップデートはHome/Pro/Enterprise全エディションが対象で、順次配信される。Insiderプログラムや展開リングでの動作確認を先行させ、業務クリティカルな端末への適用は1〜2週間様子を見るのが現実的だ。「即適用して壊れた」という報告が増えている昨今、数日待つという判断もれっきとしたセキュリティ・安定性管理のひとつだ。 メモリ削減の恩恵を最も受けるのは、8GB RAM機・複数アプリ並行利用・VDI環境の3パターン。端末更改コストを先送りしたい組織には特に注目したい更新だ。 Narratorの強化は障害を持つ従業員へのIT環境整備という観点でも評価材料になる。アクセシビリティ対応をコンプライアンス要件として整理している組織は、リリースノートの該当箇所を確認しておこう。 筆者の見解 正直なところ、Windowsの個々の機能アップデートを詳細に追いかけること自体の意味は以前より薄れていると感じている。とはいえ、今回のアップデートは評価できる内容だ。メモリ効率の改善やCPUスケジューリングの最適化は地味だが確実に体験を底上げするものだし、Narratorの強化はアクセシビリティへの本気度が見える。 Microsoftはこういう「縁の下の力持ち」的な改善を積み重ねることができる組織だ。それだけの技術力と規模がある。だからこそ、UX改善の地道な積み重ねをもっと前面に出して評価されてほしいと思う。日本のIT現場では「Windowsアップデート＝セキュリティパッチ」という認識が強く、パフォーマンスやUXの改善は見落とされがちだ。今回のような変更を正しく評価して展開の意思決定に活かすことが、IT管理者の腕の見せどころでもある。 展開タイミングの判断については、組織規模や業務特性によって正解が異なる。大規模な段階的展開インフラを持たない中小企業は、MicrosoftのWindows Update for Business機能を使った展開リングの仕組みを今から整えておくと、今後のアップデート管理が格段に楽になる。 出典: この記事は Windows 11 April 2026 Update Brings Performance Boosts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年4月13日、Europolが主導する大規模なサイバー犯罪取り締まり作戦「Operation PowerOFF」の最新フェーズが実施された。21カ国が連携し、DDoS攻撃代行サービス（いわゆる「Booterサービス」）の利用者75,000人以上に警告を送るとともに、53のドメインを閉鎖。4名の逮捕と25件の家宅捜索令状の執行が確認されている。日本もこの作戦に参加しており、国際的なサイバー犯罪対策の枠組みに確実に組み込まれていることがわかる。 Booterサービスとは何か 「Booterサービス」とは、DDoS攻撃能力を月額・従量課金でレンタルできるプラットフォームのことだ。攻撃インフラの実体は、乗っ取られたルーターやIoT機器で構成されるボットネットである。利用者はターゲットのIPアドレスを入力するだけで、技術的な知識がなくても大規模なDDoS攻撃を仕掛けられる。 悪質なのは、一部のサービスが「ストレステストツール」を名乗って合法性を装っている点だ。しかし実態として、ターゲットのサーバーやネットワークの所有権確認が行われておらず、誰でも任意のサービスを標的にできる。これは事実上、攻撃ツールの販売にほかならない。 過去のOperation PowerOFFフェーズでは、主要インフラの解体と300万件以上の犯罪アカウント情報を含むデータベースの押収が行われており、今回はその蓄積データを活用した「利用者への直接警告」が大きな特徴となっている。 「予防フェーズ」への移行が重要な転換点 Europolは今回の作戦について、単なる摘発にとどまらず「予防フェーズ」への移行を明言している。具体的には以下の取り組みが進められる。 検索エンジン広告の活用: DDoSツールを探している若年層に向けて、違法性を訴える広告を表示 検索結果からの削除: 違法サービスを宣伝する100件以上のURLを検索インデックスから排除 オンチェーン警告: 違法決済に紐づくブロックチェーンアドレスへの警告メッセージ付与 この「取り締まり＋認知変容」の二段構えは、技術的なインフラ破壊だけでは再犯・模倣を防ぎきれないという現実認識から来ている。検索エンジン広告を使った啓発は特に興味深い——DDoS-for-hire を利用する層は、比較的ライトな動機（ゲームの対戦相手を落とす、元交際相手への嫌がらせ等）の若年ユーザーが多いとされており、そこへの予防的アプローチは理にかなっている。 日本のIT現場への影響 日本は今回の作戦参加国の一つとして明示されており、国内でもDDoS-for-hireの摘発・捜査が動いていることを意味する。IT管理者・セキュリティ担当者として押さえておくべきポイントを整理する。 インバウンド攻撃の変化を観察する: 今回の作戦によって既存のBooterサービスが複数閉鎖されたため、一時的に攻撃トラフィックが減少する可能性がある。ただし、残存するサービスへのトラフィック集中や、新サービスの立ち上げによる再活性化も十分ありえる。過信は禁物だ。 自社サービスのDDoS耐性を見直すタイミング: 攻撃インフラが洗い替えされるこの時期は、逆に防御側がインフラを整備する好機でもある。CDNレイヤーでの吸収、レート制限の適切な設定、クラウドプロバイダーのDDoS保護サービスの評価を今一度行っておきたい。 ログの保全期間を確認する: 今回の捜査では過去のデータベースが活用されている。自社がISPやクラウド事業者に対して、ログ保全の義務や協力体制を把握しているかどうかも確認しておくべきポイントだ。特にインシデントレスポンス計画（IRP）に「外部機関との連携フロー」が明記されていない組織は、この機会に整備を検討してほしい。 筆者の見解 セキュリティ分野は正直、細かい話が多くて得意領域とは言えない。だが今回の作戦は「技術的な摘発の次に何をするか」という問いに対して、一つの答えを示している点で注目に値する。 DDoS-for-hireの問題は、技術の民主化が持つ光と影の典型例だ。かつては国家レベルのリソースが必要だったDDoS攻撃が、月額数十ドルで誰でも実行できるサービスとして流通してしまっている。これを「禁止すれば解決する」アプローチだけで対処しようとしても限界がある。インフラを潰しても需要があれば別のサービスがすぐに生えてくる。 だからこそ、今回の「予防フェーズ」への移行は正しい方向だと思う。検索広告で「そのツール、使ったら犯罪ですよ」と先手を打つのは、禁止より使い始める前に意識を変える戦略だ。完全な解決策にはならないが、攻撃者の裾野をある程度狭める効果は期待できる。 ゼロトラストの文脈で言えば、DDoS対策もネットワーク境界の防御一本槍から、トラフィックの振る舞い分析・異常検知・自動遮断といった多層防御に移行していかなければならない。「今動いているから大丈夫」という発想でルーターのファームウェアを放置していると、気づかないうちに攻撃インフラの一部に組み込まれている——そういう時代だ。 国際的な連携が着実に深まっている点は素直に評価したい。日本が参加国として名前が挙がっていることも、数年前と比べれば大きな前進だ。ただ、こうした作戦の成果が日本国内の企業やエンジニアに届くまでの情報流通速度は、まだまだ改善の余地がある。英語メディアを追わないと情報が入ってこない状況が続いているのは、業界全体の課題として認識しておきたい。 出典: この記事は Operation PowerOFF identifies 75k DDoS users, takes down 53 domains の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Android 17の最終ベータ（Beta 4）がGoogleからリリースされた。正式リリースを目前に控えたこのバージョンには、モバイルプラットフォームの基盤を揺るがしかねない2つの重要な変更が含まれている——「積極的なメモリ管理」と「耐量子暗号（Post-Quantum Cryptography / PQC）」への対応だ。どちらも地味に見えて、実務への影響は大きい。 バックグラウンドアプリへの「退場勧告」が厳しくなる Android 17では、バックグラウンドで肥大化したアプリのプロセスをより積極的に終了させる新しいメモリ管理機構が導入された。長年のAndroidユーザーが体感してきた「なんか重くなってきた」という現象の原因のひとつ——バックグラウンドに居座り続けるアプリプロセス——への直接的なメスだ。 具体的には、端末のメモリ使用率が高まった際に、Low Memory Killer（LMK）の閾値を引き上げ、より積極的にバックグラウンドプロセスを回収する。ユーザー視点では「全体的にサクサクする」という恩恵がある一方、バックグラウンド常駐を前提に設計されたアプリは、より頻繁に再起動を余儀なくされる可能性がある。 開発者にとって重要なのは、「プロセスがいつ終了しても正しく再開できる設計」がこれまで以上に必須になるという点だ。ViewModel + SavedStateHandle の組み合わせ、あるいは WorkManager を活用した堅牢な状態管理は、もはや「できればやっておく」ではなく「やっていなければ問題が出る」レベルに引き上げられつつある。 耐量子暗号（PQC）の組み込み——「今じゃなくていい」が一番危ない もう一つの注目ポイントが、NIST標準化された耐量子暗号アルゴリズム、ML-KEM（旧称 Kyber）などのOS基盤への統合だ。 「量子コンピュータはまだ実用化されていないのに、なぜ今？」と感じる方も多いだろう。ここで理解しておきたいのが 「Harvest Now, Decrypt Later（今収穫して後で解読する）」 という攻撃手法だ。現在暗号化されたデータを大量に収集しておき、量子コンピュータが実用化された将来に一気に解読するという脅威は、すでにCISAや各国政府機関が現実の懸念として警告を発している。 医療記録、金融取引ログ、機密ビジネスデータ——「今は安全でも、将来解読されたら致命的」なデータを扱う組織にとって、PQC移行は単なる技術的好奇心ではなくリスク管理の問題だ。 AndroidがOS基盤レベルでPQCを組み込むことで、アプリ開発者はサードパーティライブラリに独自実装を頼ることなく、プラットフォーム標準のAPIを通じて耐量子暗号を利用できるようになる。これは実装の標準化・簡易化という観点でも大きな前進だ。 実務への影響 Androidアプリ開発者向け プロセス死の前提設計を徹底する: メモリ管理の積極化に備え、onSaveInstanceState や WorkManager を使った堅牢な状態保存を標準パターンとして確立しておく Beta 4でのテストを今すぐ: 最終ベータは安定版に限りなく近い。エミュレータまたは実機で自社アプリの動作確認を行う最後のチャンス PQC対応のロードマップ検討開始: 即時対応は不要でも、TLS 1.3 + ML-KEMハイブリッドモードへの移行計画を今から考え始めるタイミング エンタープライズIT管理者向け MDM（Intune / Jamf 等）の動作確認: メモリ管理の変更がMDMエージェントのバックグラウンド動作に影響する可能性がある。管理対象デバイスでの事前検証を推奨 インフラ全体のPQC移行計画を: Androidだけ先進化しても、バックエンドのTLS設定・VPN・証明書管理が古い暗号方式のままでは意味がない。エンドポイントと基幹インフラの暗号強度を整合させる観点で計画を立てる 筆者の見解 耐量子暗号への対応について言えば、「まだ先の話」と油断しているうちにリスクが積み上がる——ゼロトラストアーキテクチャへの移行と同じ構図がここにある。「今動いているから大丈夫」という安心感が最大の敵であることは、セキュリティの世界で繰り返し証明されてきた事実だ。 特に日本のエンタープライズ環境では、「基幹システムに触れたくない」という文化的な慣性が強く、PQC移行の着手が大幅に遅れるリスクがある。モバイルOSが先行してPQCを標準搭載することで、エンドポイントと基幹インフラの間に「暗号強度の不整合」が生じる可能性も出てくる。部分最適を積み重ねると全体として非効率で脆弱な状態になりかねない——全体最適の視点で、今から計画することが不可欠だ。 メモリ管理の改善については、即効性のある快適性向上という恩恵がある一方、技術的負債を抱えた「なんとなく動いていたアプリ」が炙り出される踏み絵にもなりうる。プロセスが突然終了しても正しく再開できる設計——モバイル開発の基本中の基本が、あらためて問われるタイミングだ。 Android 17の正式リリースは2026年第3四半期が予想されている。最終ベータが出た今こそ、本番対応の準備を始める「今」だ。 出典: この記事は Android 17’s final beta arrives with a killer new feature for bloated, laggy apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Windowsの防御を担うはずのMicrosoft Defenderそのものに、特権昇格の脆弱性が潜んでいた——しかもそのうち2件は、この記事を書いている時点でまだパッチが提供されていない。Huntress Labsの報告により、3件のゼロデイ脆弱性が実際の攻撃に使われていることが確認された。組織のWindows環境を守る立場のエンジニアや管理者にとって、対応を急ぐべき状況だ。 何が起きているか 今回の発端は、「Chaotic Eclipse」（別名 Nightmare-Eclipse）と名乗るセキュリティ研究者による、PoC（概念実証コード）の意図的な公開だ。MicrosoftのSecurity Response Center（MSRC）との調整プロセスに不満を持ったこの研究者が、4月初旬に3件分のエクスプロイトコードを相次いで公開した。 3件の脆弱性の概要は以下のとおりだ。 BlueHammer（CVE-2026-33825）——修正済み Microsoft Defenderのローカル特権昇格（LPE）脆弱性。4月の定例セキュリティ更新（Patch Tuesday）で対処済み。ただしHuntress Labsによれば、4月10日時点ですでに実攻撃に使われており、パッチ前から悪用が始まっていた。 RedSun——未修正 Defenderがクラウドタグ付きのマルウェアファイルを検知した際に、「検出した場所にそのファイルを再書き込みする」という奇妙な動作を悪用してシステムファイルを上書きし、SYSTEM権限を奪取する手法だ。Windows 10・Windows 11・Windows Server 2019以降のすべてが対象となる。4月のPatch Tuesdayを適用済みの環境でも影響を受ける点が厄介だ。 UnDefend——未修正 標準ユーザー権限でDefenderの定義ファイル更新を止められる脆弱性。これ単体では致命的ではないが、RedSunと組み合わせることで「検知を封じてから特権昇格」という流れが成立する。SSLVPN経由での侵害事例では、この2件が同一ホストで同時に使われていることが確認されている。 なぜこれが重要か DefenderはWindowsに標準搭載されており、追加コストなしで有効なセキュリティレイヤーとして機能している。その防御機構の内部ロジックが攻撃の踏み台になるという構造は、見逃せない。 特にRedSunの仕組みが象徴的だ。「マルウェアを検知したらファイルを元の場所に再配置する」という設計が攻撃ベクターになっている。セキュリティ機能の実装ミスが権限昇格の窓口を開いてしまう——これはネットワーク境界ではなく、エンドポイントの内部で起きていることだ。 また、SSLVPN経由での侵害という報告も示唆に富んでいる。ネットワーク境界を突破された後、端末内部での権限昇格に今回のゼロデイが使われている構図は、「VPNさえあれば安全」という旧来の前提がいかに脆いかを改めて示している。 実務への影響と今すぐできる対策 1. April Patch Tuesdayの適用状況を確認する BlueHammerの修正は4月の更新に含まれている。適用済みであれば1件は封じられている。MicrosoftのMUSE（Microsoft Update Catalog）やIntune/WSUS経由で未適用端末がないか確認しよう。 2. RedSun・UnDefendは「パッチなし」と理解した上で対策を立てる 現時点ではWorkaroundが公式に示されていない。多層防御の考え方で、エンドポイントへの初期侵入そのものを防ぐ層を厚くするしかない。具体的にはMFAの徹底、条件付きアクセスポリシーの強化、EDR/MDRによる異常な権限昇格の検知設定を見直すべきだ。 3. SSLVPNとネットワーク境界への過信を見直す 今回の攻撃ではSSLVPN経由の侵害が起点になっている。「VPN接続 = 信頼済み」とみなす設計は再検討する時期だ。ゼロトラストモデルへの段階的な移行——デバイスコンプライアンスチェック、Just-In-Timeアクセス、最小特権の徹底——が正しい方向性だ。 4. 「今は大丈夫」を根拠にしない Huntress Labsが観測したのは実際に侵害された環境だ。未修正の脆弱性は「いつか悪用されるかもしれない」ではなく「すでに悪用されている」という事実を出発点にリスク評価をし直してほしい。 筆者の見解 今回の騒動で改めて問われているのは、「脆弱性の責任ある開示」（Coordinated Vulnerability Disclosure）のあり方だ。Microsoftは公式声明でこのプロセスの重要性を述べているが、研究者側が「調整が機能しなかった」と判断してPoC公開に踏み切った背景は軽視できない。 MSRCは世界規模で膨大な報告を処理する組織だ。対応品質にばらつきが出ることは理解できる。ただ、その結果として未修正のゼロデイが実攻撃に使われる状況になっているとすれば、プロセスそのものを見直す理由は十分ある。Microsoftには、セキュリティ研究コミュニティとの関係をもう少し丁寧に扱う余地があるのではないか。開発力も影響力もある会社なのだから、そこで正面から勝負してほしいと思う。 RedSunの仕組みについては、率直に言って「設計として変だ」という研究者の指摘は的を射ている。検知したマルウェアを元の場所に書き戻す動作は、それだけ聞けば奇妙に映る。ただ、その実装判断の背景には何らかの理由があるはずで、修正対応の中でその説明もあってほしいところだ。 セキュリティに興味を持つエンジニアとして付け加えると、今回のような事案が積み重なるほど「境界型防御だけでは足りない」という当たり前の結論が強化される。端末内部での特権昇格を前提に、ゼロトラストアーキテクチャで「侵入後の動きを封じる」設計を日常業務に組み込むことが、現実的かつ持続可能な防御戦略だと考えている。 出典: この記事は Recently leaked Windows zero-days now exploited in attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows Defenderに深刻なゼロデイ脆弱性「BlueHammer（CVE-2026-33825）」が4月7日に公開された。非特権ユーザーがSYSTEM権限を取得できるローカル特権昇格（LPE）の脆弱性であり、完全にパッチを当てたWindows 10・Windows 11の両方が対象になる。さらに今回は孤立した1件ではなく、13日間で3つの関連エクスプロイトが連続公開されるという、これまでにない展開を見せている。 CVE-2026-33825「BlueHammer」の技術的な仕組み 脆弱性の根本原因は、Windows Defenderの脅威対処エンジン（Threat Remediation Engine）に存在するTOCTOU（Time-of-Check To Time-of-Use）競合状態だ。 Defenderがマルウェアを検出してファイルを削除・修復する際、ファイルパスを「チェックしたタイミング」と「実際に書き込むタイミング」の間に微妙なギャップがある。BlueHammerはこのギャップをついて、Defenderが高い特権で操作しようとしていたファイルパスをシンボリックリンクやジャンクションポイントで差し替え、任意のファイルを上書きさせる。結果として非特権プロセスからSYSTEMレベルのコード実行が可能になる。 CVSSスコアは7.8（High）。ローカルでの実行が前提なので「リモートコード実行に比べればまし」と思いたいところだが、社内不正アクセス・フィッシング成功後の権限昇格・サプライチェーン経由のコード実行など、現実のインシデントシナリオでは十分に悪用される攻撃ベクターだ。 「13日間・3エクスプロイト」が示す構造的リスク 今回の最大の論点は、BlueHammer単体ではなく、同時期に公開された3つのエクスプロイトの連鎖にある。 名称 内容 BlueHammer Defenderファイル修復ロジックを悪用したLPE UnDefend Defenderの更新機構を妨害し、保護能力を徐々に低下させる RedSun クラウドタグ付きファイルの処理を悪用した別経路のLPE 攻撃者がBlueHammerで昇格してUnDefendで防御を骨抜きにし、パッチ適用後でもRedSunで再昇格を狙える——というチェーンが成立する。3件をまとめてみると「Defender自体の設計に構造的な問題がある」と指摘せざるを得ない部分がある。セキュリティ製品のコアロジックに競合状態があるという事実は、修正パッチで完全に解消できる類の話ではないからだ。 影響範囲と対処方法 影響を受けるプロダクトは広い。 Windows 10（サポート中の全バージョン） Windows 11（サポート中の全バージョン） Windows Server 2016 / 2019 / 2022 / 2025 Microsoft Defender Antivirus（2026年4月更新以前） Microsoftは4月のPatch Tuesdayで修正パッチをリリース済みだ。優先度を「即時適用」に設定することを強く推奨する。 実務への影響 IT管理者がすぐ確認すべきこと Windows Updateの適用状況を確認する。Defender定義ファイルの更新とは別に、OS本体の4月Patch Tuesdayが必要。WUFBやWSUSで管理している場合、遅延設定が入っていないかチェックしよう。 PoCが公開済みである点を重視する。BlueHammerはコードが出回っており、ツールに組み込まれるまでの時間はそれほどかからない。「うちは内部ネットワークだから大丈夫」という判断は避けたい。内部でのLPEは、BECや内部犯行のシナリオで特に脅威度が上がる。 Defenderだけに依存しない多層防御を確認する。UnDefendの存在が示すように、エンドポイント保護が徐々に無効化されるシナリオが現実的になっている。EDR/XDRの死活監視や、Defender以外のセキュリティレイヤーが機能しているかを今一度点検する価値がある。 特権アカウントのアクセス制御を見直す。LPEが有効な状況では、非特権で動作しているプロセスや自動化スクリプトもSYSTEMに昇格できてしまう。常時付与された特権アカウントがある場合、Just-In-Time（JIT）アクセスへの移行を検討したい。 Windows Updateを「様子見してから当てる」は今回は有効ではない。PoCが出回っているゼロデイである以上、パッチリスクよりも未適用リスクの方がはるかに高い。 筆者の見解 Windowsのセキュリティ改善は、ここ数年で着実に前進してきた。Smart App ControlやカーネルドライバーのPKI要件強化など、アーキテクチャレベルで攻撃面を削る取り組みは正しい方向性だと思っている。 それだけに、今回の「13日間・3エクスプロイト連鎖」という事態は、もったいないと率直に感じる。Defenderは10億台以上のデバイスで動くセキュリティの要であり、そのコアロジックにTOCTOUという古典的な競合状態が存在していたという事実は、品質管理の観点から真剣に受け止めてほしい。 MicrosoftにはDefenderを本物の「プラットフォーム型セキュリティ基盤」として育てる力がある。Sentinelやエンドポイント管理との深い統合、リアルタイムな異常検知のインテリジェンス——そういう方向に本気で投資すれば、「Defenderだから安心」と言えるエコシステムが作れるはずだ。 今回の件を一過性のバグ修正で終わらせず、Defender全体の脅威対処エンジンを見直す契機にしてほしい。それができる組織力があると信じているからこそ、注目し続けている。 とにかくまず、4月Patch Tuesdayを当てよう。それが今できる最善の一手だ。 出典: この記事は BlueHammer & RedSun: Windows Defender CVE-2026-33825 Zero-day Vulnerability Explained の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは今週、Windows 11のDevチャンネルおよびBetaチャンネル向けにプレビュービルドを配信した。今回の更新はWindows Helloの改善、プライバシーコントロールの強化、設定アプリやファイルエクスプローラーの使い勝手向上が中心となっている。地味に聞こえるかもしれないが、実務に直結する変更が含まれており、IT管理者は要注目だ。 Windows Helloの改善——認証体験がより洗練される Windows Helloは、パスワードレス認証の中核を担うMicrosoftの生体認証フレームワークだ。今回のビルドではそのエクスペリエンスが改善されており、顔認証・PIN認証の安定性や設定フローの見直しが含まれているとされる。 Windows Helloはもともと正しい方向性の技術だが、企業導入においては「互換性のあるカメラを別途調達する必要がある」「古いPCでは顔認証が使えない」といったハードルもあった。ソフトウェア側が成熟するにつれ、こうした体験の差が埋まっていくのは歓迎すべきことだ。 プライバシーコントロールの強化——設定が探しやすくなる 設定アプリのプライバシー関連セクションが整理・強化された。Windows 11はリリース当初からプライバシー設定の項目が多く、どこで何を制御できるのか分かりにくいという批判があった。今回の改善はその問題に正面から向き合った変更とみられる。 IT管理者の視点では、エンドユーザーがプライバシー設定を自分で変更できてしまう範囲と、MDM（Intuneなど）で組織管理できる範囲のバランスが常に課題となる。設定UIが整理されることでユーザーの「誤操作」や「意図しない設定変更」が減るなら、管理側にも恩恵がある。 ファイルエクスプローラーの改善 ファイルエクスプローラーも継続的に改善が続いている。Windows 11世代でタブ機能やモダンUIが導入されて以来、細かい挙動の安定化と機能追加が続いている状況だ。具体的な変更内容はビルドノートで確認が必要だが、日常的に使うツールだけに小さな改善でも積み重ねの効果は大きい。 実務への影響 DevチャンネルとBetaチャンネルの違いを意識する Devチャンネルは最新の実験的機能が入るが安定性は保証されない。Betaチャンネルは次期安定版に向けた機能検証が主で、エンタープライズパイロット用途に向いている。今回の変更がいつ安定版（GAチャンネル）に降りてくるかを見極めながら、自社の展開計画に組み込む判断が必要だ。 Windows Updateのタイミング判断 ここ最近、Windows Updateを即時適用したら問題が出た、という報告が散見されるようになっている。数日様子を見てからパッチを当てる判断も、リスク管理の観点では十分に合理的だ。ただし「様子を見る」と「永遠に当てない」は別物。期間を決めて判断する運用フローを整えておきたい。 パスワードレス移行の機会として捉える Windows Helloの改善は、まだパスワードレス移行を進めていない組織にとって好機だ。Microsoft Entra IDとの組み合わせでパスワードレス認証を段階的に導入する際の第一歩として、まず対応ハードウェアの棚卸しから始めるとよいだろう。 筆者の見解 Windowsの細かいビルドを毎回深追いする意義は、正直なところ薄れてきていると感じている。リリースペースが上がった分、各ビルドの「重み」が下がっているからだ。 その中で今回のアップデートが評価できるのは、Windows Helloの改善やプライバシー設定の整理が「正しい方向への地道な積み上げ」だからだ。派手さはないが、こういう地道な改善こそがWindowsをエンタープライズで長く使い続けられるプラットフォームたらしめている。 パスワードレス認証の普及は、セキュリティの文脈でもユーザー体験の文脈でも避けて通れない流れだ。Microsoftにはこの分野で実績があるし、Windows Hello + Entra IDの組み合わせは実用上も十分な水準に達している。この方向性をさらに磨き込んでほしいと思う。エンドポイントのアイデンティティ管理は、ゼロトラストアーキテクチャの入り口に位置する最重要要素だからだ。 Windowsの更新は今後も続く。すべてを追うのではなく、自分の組織に影響のある変更を選び取る目を持つことが、これからのIT管理者には求められている。 出典: この記事は Windows 11 gets improved privacy controls, better Windows Hello, and more in new builds の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国のサイバーセキュリティ機関CISAが、Apache ActiveMQに存在する高深刻度の脆弱性（CVE-2026-34197）が実際の攻撃で悪用されていることを確認した。この脆弱性の最大の特徴は、13年間にわたって見過ごされてきたという点にある。パッチは2026年3月30日に提供されたが、既に攻撃者に悪用されている以上、対象システムを運用する組織は一刻も早い対応が求められる。 Apache ActiveMQとは——「縁の下の力持ち」が狙われた Apache ActiveMQはJavaベースのオープンソースメッセージブローカーで、アプリケーション間の非同期通信を担う。マイクロサービスアーキテクチャや企業内SOA基盤に広く使われており、日本の大企業でも「気づいたら使っていた」という形で稼働しているケースが少なくない。 今回のCVE-2026-34197は入力検証の不備に起因する。認証済みの攻撃者がインジェクション攻撃を通じて任意のコードをリモート実行できる。発見したHorizon3の研究者は、AIを活用した解析ツールを使ってこの欠陥を掘り起こした——人間の目が13年間見落としてきたものを、AIが別の角度から発見したというわけだ。 パッチ済みバージョンはActiveMQ Classic 6.2.3 および 5.19.4。これ以前のバージョンを使用しているシステムは即時アップデート対象と考えてほしい。 CISAがKEVカタログに追加、政府機関に4月30日までの対応を命令 CISAは今回の脆弱性を「既知の悪用済み脆弱性（KEV: Known Exploited Vulnerabilities）カタログ」に追加し、連邦政府の民間機関（FCEB）に対して4月30日までのパッチ適用を義務付けた。 脅威監視サービスShadowServerの調査では、インターネットに公開されたActiveMQサーバーが現時点で7,500台超確認されている。これらはすべて潜在的な攻撃対象だ。 Horizon3はログによる侵害確認方法も公開している。ActiveMQブローカーのログで以下のシグネチャを探すとよい： brokerConfig=xbean:http:// クエリパラメータを含む不審な接続 内部トランスポートプロトコル VM を使用した異常なブローカー接続 ActiveMQは繰り返し狙われてきた「常連ターゲット」 ActiveMQに対する大規模攻撃は今回が初めてではない： CVE-2023-46604: TellYouThePassランサムウェアグループがゼロデイとして悪用 CVE-2016-3088: これも実際の攻撃で確認済み Horizon3が指摘するように、「ActiveMQに対する攻撃手法とポスト・エクスプロイテーションの技術は攻撃者の間で広く知られている」。過去の悪用実績があるということは、攻撃のTTP（戦術・技術・手順）が体系化されているということでもある。今回の新たな脆弱性情報は、既存の攻撃ツールキットに組み込まれるのが早い。 実務への影響——日本の現場で今すぐ確認すべきこと 1. バージョン確認と即時更新 ActiveMQ Classic 6.2.3 / 5.19.4 未満のバージョンは即時更新対象。まず環境内のActiveMQインスタンスを洗い出すことから始めよう。コンテナや古いオンプレサーバーで「存在を忘れていた」インスタンスが潜んでいないか確認する。 2. インターネット露出の排除 7,500台超がインターネットに公開されているという数字は衝撃的だ。ActiveMQブローカーはそもそも外部から直接アクセスさせるべきではない。VPCやプライベートサブネット、ファイアウォールで外部からのアクセスを遮断しているか確認する。 3. ログ監視と侵害確認 上述のシグネチャを使った侵害確認を今すぐ実施してほしい。パッチ適用前に既に侵害されていた場合、パッチだけでは不十分だ。 4. 認証強化 「認証済み攻撃者」が前提の脆弱性だが、認証情報の漏洩（フィッシング、クレデンシャルスタッフィング等）と組み合わせると実質的に誰でも悪用できる。ActiveMQの認証設定を見直し、最小権限の原則が守られているか確認する。 筆者の見解 「13年間見過ごされていた」という事実に、私は正直ゾッとした。 ActiveMQのような枯れたミドルウェアは、「長く使われてきた＝安定している＝安全」という誤解が生まれやすい。しかし実態は逆で、「長く使われてきた＝長い間、潜在的な脆弱性が眠っていた可能性がある」だ。今動いているから大丈夫、という思考が最も危険な盲点になる。 興味深いのは、この欠陥がAIによる解析で発見されたという点だ。人間の研究者が13年間見落としてきたものを、AIが別の視点から引っ張り出した。これは防御側にとっての朗報だが、同時に攻撃側が同じアプローチで「まだ誰も気づいていない脆弱性」を大量発掘する時代が来ることを示唆している。セキュリティチームにもAIを活用した継続的な脆弱性スキャンの仕組みが必要になる。 ゼロトラストの文脈で言えば、今回の件はまさに「境界型セキュリティの限界」の典型例だ。ネットワーク境界で守っている気になっていても、内部の古いミドルウェアが足元を崩す。ネットワーク層・認証層・認可層の多層防御と継続的なアセット管理——「存在すら忘れていたActiveMQサーバー」を減らすことが、実は最も効果的な対策になる。 レガシー基盤と向き合い続けている日本の現場にとって、今回の件は「明日は我が身」の警告として受け止めてほしい。 出典: この記事は CISA flags Apache ActiveMQ flaw as actively exploited in attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

エンドポイント保護ツールを導入していれば安心——そんな前提が今また崩されつつある。セキュリティ企業Sophosが最近公開したレポートで、「Payouts King」と呼ばれるランサムウェアグループがQEMUという正規のオープンソース仮想化ツールを悪用し、感染端末の上に隠し仮想マシン（VM）を展開することでエンドポイントセキュリティを完全に回避している実態が明らかになった。 QEMUを「隠れ蓑」にする攻撃の仕組み QEMUはLinuxやWindowsの開発者に広く使われているCPUエミュレータ・システム仮想化ツールだ。その特性上、ホスト側のセキュリティソリューションはVM内部をスキャンできない。これを逆手に取ったのが今回の手口である。 攻撃者は感染端末に侵入後、TPMProfiler という名前のスケジュールタスクを作成し、SYSTEMユーザー権限でQEMU VMをひっそりと起動する。仮想ディスクはデータベースファイルやDLLファイルに偽装されており、一見すると正規ファイルと区別がつかない。 VM内部ではAlpine Linux 3.22.0が動作しており、以下のような攻撃ツール一式が搭載されている。 AdaptixC2 — コマンド＆コントロール（C2）フレームワーク Chisel — リバースSSHトンネリングツール BusyBox — 軽量Unixコマンドセット Rclone — クラウドストレージへのデータ持ち出しツール リバースSSHトンネルを通じてVM内から外部C2サーバーへの通信が確立されるため、ホスト側のネットワーク監視をも回避できる。QEMUによるVM悪用の手口は3AMランサムウェアやLoudMinerなど過去の事例にも見られるが、Payouts Kingはそれをより洗練させた形で組み込んでいる。 多彩な初期侵入経路——VPNからTeamsまで Sophosが追跡するSTAC4713キャンペーン（2025年11月以降観測）では、初期アクセスにさらされた状態のSonicWall VPN、およびSolarWinds Web Help Desk脆弱性（CVE-2025-26399）が悪用されている。 注目すべきは、より新しい攻撃手法としてMicrosoft Teamsを使ったソーシャルエンジニアリングが確認されていることだ。攻撃者はITスタッフを装って従業員に接触し、QuickAssist（Windowsに標準搭載のリモートサポートツール）をダウンロード・実行させる。これはかつてBlackBastaグループが多用した手口と一致しており、ZscalerのレポートによればPayouts KingはBlackBastaの元アフィリエイトメンバーによって運営されている可能性が高い。 侵入後はvssuirun.exeでVSSシャドウコピーを作成し、NTDS.dit・SAM・SYSTEMハイブといったドメイン認証情報の宝庫を抜き取る。暗号化にはAES-256（CTR）＋RSA-4096を採用し、大容量ファイルには断続暗号化（intermittent encryption）を使うことで処理速度を確保しながら検出を困難にしている。 実務への影響——日本のIT管理者が今すぐ見直すべきこと 1. 正規ツールの実行制御を強化する QEMU、Rclone、Chiselはいずれも正規の業務ツールとして使われることがある。これらを一律に禁止するのではなく、「誰が・どのマシンで・いつ」実行するかを管理する仕組みが必要だ。Windows Defender Application Control（WDAC）やAppLockerによるアプリケーション許可リスト管理を改めて見直してほしい。 2. Teams経由のソーシャルエンジニアリングに備える 「ITサポートからTeamsでメッセージが来たのでQuickAssistを起動した」という経路での侵害は、技術的な脆弱性ではなく運用上の隙を突いている。ヘルプデスクが正規の手順でどこからアクセス要求するかをユーザー教育として徹底しておく必要がある。 3. エンドポイントだけに頼らない多層防御の再確認 VM内部はエンドポイントセキュリティの視野外になる。ネットワーク層でのC2通信の検知（不審な外向きSSHトンネル等）、認証層でのドメイン認証情報の異常利用検知、そして認可層でのJust-In-Time特権管理を組み合わせることが、このような迂回攻撃への現実的な対抗手段になる。 4. VPNの露出面を縮小する STAC4713もSTAC3725もVPN装置の脆弱性を初期アクセスに使っている。SonicWall、Citrix NetScalerともにパッチの適用状況と公開ポートの棚卸しを早急に行ってほしい。 筆者の見解 この手口が示しているのは、「エンドポイントにエージェントを入れれば守れる」というモデルの限界だ。QEMUのような正規ツールをVM起動に使われると、プロセス監視ベースのEDRはその中身を見ることができない。攻撃者は常に「セキュリティツールが見ていない場所」を探しており、今回はそれが仮想化レイヤーだった。 ゼロトラストアーキテクチャの本質は「ネットワーク内にいるから信頼する」を廃止することにある。今回の攻撃でも、VM内からリバースSSHトンネルが外向きに張られた時点でネットワーク異常として検知できた可能性がある。ホスト側のEDRが無力化されても、ネットワークトラフィック分析・Identity保護・SIEM連携の組み合わせが機能していれば早期発見の余地はあった。 Teams経由のQuickAssist悪用については、正直なところMicrosoftには引き続き改善を期待したい。Quick Assistはエンタープライズ向けのセキュリティ制御オプションが強化されてきているが、「見知らぬ相手からのセッション要求を普通のユーザーがどう判断するか」という設計上の課題はまだ残っている。ユーザーが公式に提供された手段を最も安全に使える状況を整えてこそ、禁止に頼らない現実的なセキュリティが実現する。Microsoftがその方向でさらに踏み込むことを期待している。 エンドポイント一点に賭けるのは、もはや通用しない。多層防御の見直しを今すぐ始めてほしい。 出典: この記事は Payouts King ransomware uses QEMU VMs to bypass endpoint security の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftが一時「AIを絞る」と発表した直後に、AIエージェントのタスクバー統合を改めて確認した。矛盾しているように見えるが、実はそうではない。「不要なCopilotの入口を減らす」と「有用なエージェント体験を作る」は、両立しうる話だ。2026年4月17日にリリースされたWindows 11 Build 26200.8313（Release Previewチャネル）には、サードパーティエージェントに対応したエージェント型タスクバーが含まれている。 タスクバーに何が変わるのか タスクバー上のMicrosoft 365 Copilotアイコンにカーソルを合わせると、動作中のエージェントを監視・操作できるUIが表示される。現時点で目玉となるのが「Microsoft 365 Researcher」だ。ChatGPTやGeminiが提供するDeep Researchに相当する機能で、複数ステップにわたる調査タスクを自律的に実行する。さらに、OneDriveやMicrosoft 365にアップロードされた自社ファイルへのアクセスが可能なため、社内ドキュメントを参照したレポート生成が実現する。なお、この機能はMicrosoft 365 Copilotのサブスクリプションが必要だ。 MCPという「共通規格」の意味 注目したいのはアーキテクチャだ。今回のエージェント統合はModel Context Protocol（MCP）を基盤としている。MCPはAIモデルやエージェントが既存のアプリ・ファイル・OSと接続するための共通規格であり、開発者はMCPを介して自社エージェントをWindows 11のタスクバーに組み込める。OS側に用意されたAPIはWindows.UI.Shell.Tasksだ。 この設計は重要な意味を持つ。特定ベンダーのエージェントだけが動く閉じた世界ではなく、サードパーティが参加できるエコシステムとして構築されている。将来的にエンタープライズ向けの業務エージェントをタスクバーから直接起動できるようになれば、OSとビジネスプロセスの統合が一段と進む。 「任意有効化」という設計判断 もう一つ重要なのが、この機能がオプション扱いであることだ。自動有効化はせず、Copilotを使うよう促す通知も出さない。以前のWindowsのように機能を半強制的に押し込んで反発を招いたパターンとは明らかに異なるアプローチだ。 「Ask Copilot」という新しい検索体験では、@を使ってエージェントを呼び出せる。@を入力するとPC上で利用可能なエージェントの一覧が表示され、選択して実行できる。ただし、この機能のリリース時期はまだ確定していない。 実務への影響——IT管理者・エンジニアが考えるべきこと 企業のIT管理者へ 現時点ではRelease Previewチャネルの話だが、今のうちに「タスクバーにエージェントが表示された場合の運用ポリシー」を考えておく価値がある。オプション機能とはいえ、M365 CopilotライセンスのあるテナントではResearcherが使えるようになる可能性が高い。どのエージェントを許可するか、社内文書へのアクセス範囲をどう設計するかは、早めに議論しておきたい。 開発者・ISVへ MCPとWindows.UI.Shell.Tasks APIを使えば、自社サービスをWindowsのシェルレベルで統合できる。業務アプリとOSの境界が溶けていく流れは、アプリ開発の設計思想そのものを変える可能性がある。Microsoftが公開するAPI仕様は早めに追っておきたい。 エンドユーザーへ しばらくは「Release Preview → 一般公開」のサイクルを静観する時間がある。新機能は焦って有効化せず、職場のポリシーを確認してから利用を判断するのが賢明だ。 筆者の見解 Microsoftが「AIを絞る」と言いながらエージェントを追加する動きは、一見ちぐはぐに見える。しかし今回の発表を読むと、単なる揺り戻しではなく、実装の質を上げながら前進しようとしている意図が見える。任意有効化・MCP基盤・サードパーティ開放という3点は、以前の「とにかくCopilotを全面に出す」路線とは異なるアプローチだ。 MCPをOSレベルに組み込むというアイデアは技術的に面白い。エージェントがOSのシェルと統合されれば、ファイル操作・検索・外部サービス連携が一気通貫になる。Microsoftが持つWindowsのユーザーベースとエンタープライズの信頼を活かせば、ここは本来最も強く出られる領域のはずだ。 だからこそ、実装の丁寧さを維持してほしい。エージェントがOS上で動くということは、ユーザーのファイルや業務データに深くアクセスすることを意味する。セキュリティモデルの設計——どのエージェントに何を許可するか、企業管理者がどこまで制御できるか——が粗ければ、エコシステムが広がるほどリスクも拡大する。MCP統合の利便性と権限管理の堅牢さを両立できるかが、この機能の本当の評価軸になるだろう。 Windowsをプラットフォームとして再定義しようとする今の試みが実を結ぶかどうか、引き続き注視していきたい。 出典: この記事は Microsoft confirms AI agents are still coming to the Windows 11 taskbar as it prepares for public rollout の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ウクライナのCERT（CERT-UA）が2026年4月、地方政府機関や病院を標的にした新たなマルウェアファミリー「AgingFly」を特定した。このマルウェアの最大の特徴は、コマンドハンドラーをあらかじめ実行ファイルに内蔵せず、C2サーバーからC#ソースコードを受け取って実行時に動的コンパイルするという構造にある。ハッシュ・シグネチャベースの静的検知を大きく困難にする設計であり、遠い国の話として流せない技術的示唆を多く含んでいる。 攻撃チェーンの全貌 攻撃の起点は「人道支援のオファー」を装ったフィッシングメール。リンクをクリックすると、XSS脆弱性を突いて侵害された正規サイト、またはAIツールで生成された偽サイトへ誘導される。 被害者がダウンロードするアーカイブにはLNKショートカットが含まれており、HTA（HTMLアプリケーション）ハンドラーを起動。HTAはリモートリソースからさらなるHTAを取得・実行し、デコイフォームで注意をそらしながら、スケジュールタスクでEXEペイロードを正規プロセスにインジェクションする。その後、XOR暗号化されたTCPセッションでC2サーバーに接続し、AgingFly本体が展開される。 AgingFlyの技術的特徴——動的コンパイルによる検知回避 C#で実装されたAgingFlyは、リモートコントロール・コマンド実行・ファイル窃取・スクリーンショット・キーロガー・任意コード実行といった機能を持ち、WebSocket経由（AES-CBC暗号化）でC2サーバーと通信する。 注目すべきはコマンドハンドラーの動的コンパイルだ。従来のマルウェアは機能を実行可能ファイルに埋め込むが、AgingFlyはC2から受け取ったC#ソースコードをホスト上でその場でコンパイルして実行する。これにより： 初期ペイロードを小さく保てる 機能を必要に応じてオンデマンドで追加・変更できる ハッシュ・シグネチャベースの静的検知をほぼ無効化できる 一方で、この手法はC2への常時接続依存、実行時のフットプリント増加、コンパイル動作による挙動検知リスクという弱点も抱える。つまり、EDR（Endpoint Detection and Response）による行動監視は依然として有効な対抗手段だ。 認証情報窃取に悪用されるオープンソースツール AgingFlyの前段階では、オープンソースのセキュリティツールが認証情報窃取に流用されている： ChromElevator：Chromiumベースブラウザ（Chrome、Edge、Brave）の保存パスワードやCookieを管理者権限なしで復号・抽出できるツール ZAPiDESK：WhatsApp for Windowsのデータベースを復号してメッセージ等を取り出すフォレンジックツール さらに、C2サーバーのアドレスをTelegramチャンネルから取得するPowerShellスクリプト「SILENTLOOP」が使われており、Telegramを指令インフラの中継に使う手法は単純なC2ドメインブロックが効きにくい理由でもある。横展開にはRustScanポートスキャナー、Ligolo-ng・Chiselトンネリングツールが使われ、初期侵入後に素早く内部探索が進む。 実務への影響 日本の組織がこの攻撃パターンから学ぶべき点は3つある。 1. LNK / HTA / JSファイルの実行制限 CERT-UAが推奨する通り、グループポリシーやAppLockerでこれらのファイルタイプの実行を制限することが最も効果的な初期侵入対策の一つだ。メールやWebからのダウンロードに対して、ファイルタイプでの実行制御は今すぐ実施できる低コスト対策だ。 2. ブラウザ認証情報の保存を見直す ChromElevatorに代表される手法は、管理者権限なしでも実行可能という点が重大だ。エンタープライズ環境では認証情報を専用のシークレット管理基盤や条件付きアクセスと連携したパスワードレス認証に移行することを強く推奨する。 3. WhatsApp for Windowsを業務利用している環境への注意 業務コミュニケーションにWhatsAppを用いている組織は、そのローカルデータが標的になりうることを認識する必要がある。特に規制業種では業務チャットの管理ポリシーと保存場所の整備が急務だ。 筆者の見解 AgingFlyが示す最も重要なシグナルは、「静的検知の限界」だ。コマンドハンドラーを動的コンパイルするアプローチは、従来のシグネチャ型アンチウイルスをほぼ無力化する。「セキュリティ製品を入れてあれば大丈夫」という感覚では通用しない時代に確実になっている。 もう一点引っかかるのが、オープンソースツールの流用だ。ChromElevatorもZAPiDESKも本来はセキュリティ研究・フォレンジック目的のツールだが、それが攻撃インフラの一部として使われている。「今動いているから大丈夫」では済まない現実を改めて突きつけられる。 そして見逃せないのが、Telegramをインフラとして使うという点だ。正規のクラウドサービスを踏み台にする手法は、従来のネットワーク境界防御では根本的に検知が難しい。これこそがゼロトラストアーキテクチャが必要な理由の一つであり、「ネットワーク内にいるから信頼する」という前提の危うさを改めて示している。 最終的に防御側が強みにできるのは、行動ベースの異常検知と、認証・認可の厳格化だ。「常時アクセス権の付与」をやめてJust-In-Timeアクセスに移行し、初期侵入を阻止できなかった場合でも横展開を封じる多層防御の構築が、これからのセキュリティ運用の基本線になる。このウクライナでの攻撃事例を、自組織の設計を見直すきっかけにしてほしい。 出典: この記事は New AgingFly malware used in attacks on Ukraine govt, hospitals の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Nginx の管理UIとして広く利用されている「Nginx UI」に、認証なしでサーバーを完全乗っ取りできる致命的な脆弱性（CVE-2026-33032）が発見され、すでに実際の攻撃に使われていることが確認された。430,000件以上のDockerプル実績を持つ人気ツールだけに、影響範囲は決して小さくない。 何が起きているか——MCPエンドポイントが丸裸に Nginx UIはバージョン2系からAIワークフロー連携を想定してModel Context Protocol（MCP）をサポートしているが、その実装に根本的な設計ミスが含まれていた。/mcp_message エンドポイントに対してまったく認証が掛かっておらず、ネットワークさえ到達できれば誰でも特権的なMCPアクションを呼び出せる状態になっていた。 具体的な攻撃手順はシンプルで恐ろしい。 対象のNginx UIインスタンスにSSE（Server-Sent Events）接続を確立する MCPセッションを開き、返却される sessionID を取得する その sessionID を使って /mcp_message に任意のリクエストを送る これだけで、認証ヘッダー一切なしに12種類のMCPツール（うち7種は破壊的操作）が使い放題になる。Nginx設定ファイルの読み取り・改ざん・削除、悪意ある server ブロックの注入、設定リロードのトリガーまで、サーバー管理として想定されるあらゆる操作が外部から可能だ。 タイムラインと現在の状況 日付 出来事 2026年3月14日 Pluto Security AIが発見・報告 2026年3月15日 バージョン2.3.4で修正リリース 2026年3月末 CVE番号・技術詳細・PoCが公開 2026年4月第1週 バージョン2.3.6リリース（現在の最新安定版） 2026年4月15日 Recorded Futureが野外での積極的悪用を確認 Shodanによるスキャンでは現在も約2,600インスタンスが公開状態でインターネットに露出している。地域別では中国・米国・インドネシア・ドイツ・香港が多いが、国内のサーバーも無関係ではない。 なぜこれが重要か——AIプロトコルと特権操作の組み合わせ この脆弱性が単なる「Webアプリの認証バイパス」と根本的に異なる点は、MCPという「AI統合用プロトコル」が特権管理操作と直結していたことだ。 MCPはもともとAIエージェントがツールを呼び出すための通信規格として設計されている。便利だからこそ多機能で、だからこそ今回のように「便利なツール群」が認証なしで露出した場合のダメージが甚大になる。AIと連携できるサーバー管理ツールは今後も増えていくが、その認証・認可設計が追いついていないケースが続出する予感がある。 実務への影響——日本のエンジニア・IT管理者が今すぐやること 即時対応 nginx-ui --version でバージョンを確認する 2.3.6未満であれば即座にアップデートする（docker pull uozi/nginx-ui:latest または公式リリースページから） アップデートが即時困難な場合は、/mcp_message エンドポイントをファイアウォール・リバースプロキシのACLで一時的にブロックする 中期的な対策 Nginx UIをインターネットに直接公開しているなら、まずそれを止める。管理系UIはVPN・踏み台・Private Endpoint越しにアクセスする構成が正しい Docker Composeで動かしている場合、ポートバインディングを 127.0.0.1:80 のようにループバックに限定しているか確認する 設定変更のログを定期的にレビューするか、変更検知の仕組みを入れる 将来を見据えた設計 MCPや類似のAI統合プロトコルを導入する際は「エンドポイントごとの認証スコープ」を設計段階で明確にする。後付けは難しい 特権操作を行うAPIは必ずゼロトラスト原則で設計する。「内部ネットワークだから安全」という前提は捨てること 筆者の見解 今回の件で改めて感じるのは、「今動いているから大丈夫」という感覚がいかに危険かということだ。2,600インスタンスが公開されているということは、管理者の多くはそもそも自分のサーバーが外から見えていることすら把握していない可能性がある。 MCPという新しいレイヤーが特権操作に直結した今回の構造は、今後AIエージェント統合が進むにつれて似たようなパターンが各所に出てくる予兆だと思う。AIが「道具を使う」ために設計されたプロトコルは、そのまま「攻撃者が道具を使う」ための経路にもなりうる。設計段階でNon-Human Identity（NHI）として扱い、最小権限・Just-In-Timeアクセス・操作ログの3点をセットで考える習慣を今のうちに身につけておきたい。 ...

Windows 11のInsiderチャンネル（Dev / Experimental）向けに、ウィンドウのスナップ・リサイズ・閉じるボタンへのホバーなど、日常的なUI操作に触覚フィードバック（Haptic Feedback）を加える機能が段階的に展開されている。ビルド番号は 26300.8155 以降が対象で、対応するハプティクス対応トラックパッドを搭載したデバイスで利用可能だ。 どんな操作でフィードバックが来る？ 現時点でMicrosoftが公式に確認している対応アクションは次のとおりだ。 ウィンドウのスナップ（Snap Layouts） ウィンドウのリサイズ 閉じるボタンへのホバー PowerPoint上でのオブジェクト整列 Microsoftのデザイン担当パートナーディレクターであるMarch Rogers氏は「使ってみるまでは欲しいとわからない機能だ」とコメントしている。確かに、触覚フィードバックは実際に指先で感じてはじめてその価値が伝わるものだ。 ON/OFFの切り替えは 設定 > Bluetoothとデバイス > マウス > Hapticシグナル から行える。なお、今回の施策とは別に、Canaryビルドでは右クリックゾーンのサイズをカスタマイズできる新設定も追加されており、トラックパッド全体の操作性改善がMicrosoftの優先テーマになっていることが読み取れる。 「ハードウェアがなければ意味がない」という現実 この機能の最大の制約は、対応するハプティクス対応トラックパッドを搭載した端末が市場に少ないことだ。 AppleはMacBookのほぼ全ラインナップにForce Touchトラックパッドを標準搭載しており、ユーザーの「当然のもの」という期待値を作り上げてきた。一方、Windowsエコシステムにおいてハプティクス対応トラックパッドを積極的に採用してきたのはMicrosoft Surface Laptopくらいで、他のOEMは優先度を低く見ていた節がある。 直近の例を挙げると、Snapdragon X2 Elite Xtremeを搭載した ASUS Zenbook A16（約1,999ドル）でさえ、ハプティクス対応トラックパッドを省いている。価格帯からすれば搭載して当然という声もあるが、現状はそうなっていない。 Logitech MX Master 4のようなプレミアムマウスが独自のハプティクス機構を持っているケースもあるが、今回のWindows 11側の実装がそれらに対応するかどうかはまだ明らかにされていない。 実務への影響 現時点で多くのビジネスユーザーが使っているWindows PCは、この機能を体感できる環境に届いていない。実務観点でのチェックポイントを整理しておこう。 端末調達の判断材料に加える: 次の端末更改サイクルで比較検討する際、ハプティクス対応トラックパッドの有無を評価項目に追加しておくと、将来の機能拡張に備えられる。 Surface Laptopはこの点で先行: 手厚い触覚体験を求めるなら、現状はSurface Laptopが最も実用レベルに近い選択肢だ。 IT管理者はポリシー設計を: 組織によっては触覚フィードバックをOFFにしたいニーズもあるかもしれない。設定経路（Hapticシグナル）をポリシーで制御できるか今後確認しておきたい。 Insider / Experimental段階: 本番環境での使用にはまだ早い。一般提供（GA）後に展開を計画するのが現実的だ。 筆者の見解 この機能そのものの方向性は正しいと思っている。ウィンドウを「ピタッ」とスナップしたときに指先にクリック感が返ってくる体験は、操作の確実性と満足感を高める。UIの洗練という観点で、Microsoftがこういった細部に注目しているのは評価したい。 ただ、課題の本質はソフトウェアではなくエコシステムにある。どれほど優れたOS側の実装をしても、対応デバイスが市場に広まらなければ「知る人ぞ知る機能」のまま終わってしまう。MicrosoftはSurface Laptopで高水準の実装を見せているが、それをOEMパートナー全体に波及させる力をどこまで発揮できるかが問われている。 Windowsというプラットフォームの強みは多様なOEMと幅広い価格帯にあるが、ユーザー体験の統一感という点では課題を抱えやすい構造でもある。この機能が「一部のプレミアムモデルだけの話」にならないよう、OEMへの働きかけと、対応要件の明文化を期待したい。Microsoftにはその影響力があるはずだ。 出典: この記事は Windows 11 adds haptic feedback for snapping, resizing, and more but most laptops can’t use it yet の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2024年9月から多くのWindowsサーバー管理者を悩ませてきた「意図しないWindows Server 2025への自動アップグレード」問題が、Microsoft自身の修正によってついに解消された。対象はWindows Server 2019および2022で、ライセンスを持っていないServer 2025への予期せぬアップグレードが、一夜にして実施されるという深刻な事態が相次いで報告されていた。 何が起きていたのか Microsoftの説明によれば、Windows Updateの設定画面にServer 2025へのアップグレードを促すバナーが表示されていたことが発端だ。本来は「希望する管理者向けの案内」のはずが、サードパーティ製のアップデート管理ソフトウェアによる自動処理と組み合わさり、管理者の意図しないアップグレードが実行されるケースが続出した。 Microsoftは当初、サードパーティソフトウェアの設定ミスを原因として示唆したが、ソフトウェアベンダー側は「Microsoftのリリース手順上の問題であり、リリース速度とアップデートの分類方法に誤りがあった」と反論。責任の所在について異なる見解が示される展開となった。 修正完了と同時に、Microsoftは一時的に無効化していたWindows Updateのアップグレードオファー機能を再有効化。「Settings画面からのアップグレードオファーは解決済みであり、機能を再有効化した」と公式の更新情報で発表している。 実務への影響 この問題が日本の企業IT環境に与えた影響は小さくない。多くの企業ではWindows Server 2019や2022のサポート期間内で安定稼働を維持しており、計画外のメジャーアップグレードは業務停止リスクに直結する。特にライセンス上の問題（Server 2025のライセンスを持たない状態でのアップグレード）は、コンプライアンスの観点からも看過できない。 IT管理者がいま確認すべきポイント サーバーのOSバージョン棚卸し: 意図せずServer 2025にアップグレードされていないか確認する。winver や systeminfo コマンドで即座に確認できる Windows Update管理ポリシーの見直し: GPO（グループポリシー）やWSUS、Intune等でアップグレードオファーの自動受け入れを明示的に制限しているか再確認する サードパーティ製パッチ管理ツールの設定確認: 今回の問題を機に、Feature Updateの自動適用ポリシーが意図した設定になっているかを見直す 変更管理プロセスの強化: OSアップグレードは変更管理の承認プロセスを経る運用を徹底し、自動化の範囲を明確に定義する 修正後も、Windows Updateの管理は「任せきり」ではなく「制御された自動化」が基本だ。特にサーバー環境では、クライアントPCとは異なる慎重な更新戦略が求められる。 筆者の見解 今回の件で残念に思うのは、修正までに1年以上かかったという事実だ。報告が相次いでいた2024年9月から数えれば、影響を受けた組織にとってはずいぶん長い「待ち時間」だったことになる。 Microsoftには、Windowsサーバープラットフォームを長年支えてきた実力と信頼がある。だからこそ、「ライセンスのないOSバージョンに自動でアップグレードされる」というインシデントが起きたときの初動対応には、もっと速度と透明性があってほしかった。ベンダー側への責任転嫁ととられかねない初期のコミュニケーションも、エンタープライズの信頼という観点では傷跡を残した。 Windows Updateに関しては、「すぐに当てたら壊れた」という報告がクライアント・サーバー問わず増えている昨今、「数日様子を見る判断」が一種のベストプラクティスになりつつある。特に本番サーバーでは、展開速度よりも安定性を優先する設計が欠かせない。Microsoft自身も、そのような慎重な運用姿勢を前提とした品質保証プロセスを一層強化してほしいと思う。 インフラ基盤として日本の多くの企業が依存しているWindowsサーバーだからこそ、品質への高い期待が揺らがないよう、次のリリースサイクルでの改善を期待したい。 出典: この記事は Microsoft fixes bug behind Windows Server 2025 automatic upgrades の内容をもとに、筆者の見解を加えて独自に執筆したものです。