Windows

MicrosoftがWindows 11に対し、CPUをより積極的に活用することで特定のシナリオにおける大幅なパフォーマンス向上を実現する改善を計画していると、Neowinが報じた。現行のスケジューラーが持つ「省電力寄り」の挙動を見直し、処理要求が高いシーンでCPUに「もっと働かせる」方向にチューニングするという内容だ。 CPUを「遠慮なく使う」方向へ 現行のWindowsは、電力消費やサーマル管理のバランスを取るため、CPUがフル性能を発揮するタイミングをある程度制限する設計になっている。特にノートPCや省電力設定では、本来の性能が十分に引き出されないケースがある。 今回の改善は、こうした「遠慮」を特定のシナリオに限って取り払い、CPUに積極的に高負荷で動作させることで、レスポンスタイムやスループットを向上させるアプローチだ。 現代のPCに搭載されるCPUは、IntelのPコア（パフォーマンスコア）＋Eコア（効率コア）のハイブリッド構成や、AMDの3D V-Cacheのように、アーキテクチャが複雑化している。Windows 11のスケジューラーはこれらに対応したHMP（Heterogeneous Multi-Processing）機構を持っているが、どのタスクをどのコアに割り当て、どのタイミングでブーストクロックを許可するかの判断ロジックには、まだ改善余地がある。 影響を受けるシナリオ 「特定のシナリオ」という表現が使われており、常時フルパワー動作になるわけではない点は重要だ。ゲームやクリエイティブ作業など、低レイテンシーや高スループットが求められる場面で、より素早くブースト状態に遷移させることが主な改善になると考えられる。 日常的な軽作業（ブラウジング、文書作成）への影響は限定的だろう。むしろ、恩恵を感じやすいのは以下のような場面だ： ゲームの初期ロードやシーン切り替え: CPUが素早く高クロックに達することでカクつきが減少 動画エンコードや圧縮処理: スループットが向上し処理時間が短縮 開発環境でのビルド・コンパイル: 並列処理の効率が上がりビルド時間が短縮 仮想化（Hyper-V、WSL2）: ホストOSのCPU管理が改善されることでゲストの応答性が向上 実務への影響 IT管理者・エンジニアの視点で注意すべき点がいくつかある。 電力・発熱の変化を確認する: CPUをより積極的に動かすということは、発熱と消費電力も増加しうる。特にノートPCや小型ファームウェアの開発機では、サーマルスロットリング（過熱による性能低下）が新たなボトルネックになる可能性がある。アップデート適用後は温度モニタリングツール（HWiNFO64等）で実測することを推奨する。 仮想環境・バッチ処理の再ベンチマークを: WindowsをホストとするHyper-V環境や、スケジュールされたバッチ処理は、CPU割り当てとスレッドスケジューリングの変化を受けやすい。本番適用前にステージング環境での検証を行うのが安全だ。 グループポリシーでの電力プラン管理: 企業環境でBitLocker・Intuneと組み合わせて電力プランを「バランス」に固定しているケースでは、このチューニングが期待どおりに効かない場合もある。Windows Updateのリリースノートを注意して読み、適用範囲を確認する。 筆者の見解 Windowsのパフォーマンスチューニングはここ数年、地味ながら着実に進んでいる領域だ。HETP（ハイブリッドコア最適化）の導入、Thread Directorとの連携改善など、ハードウェアの進化に追いつくための取り組みは継続的に行われてきた。今回の報告もその延長線上にある。 ユーザーが体感できるレベルのパフォーマンス改善は、Windowsの価値を支える基本中の基本だ。機能追加ばかりが目立つアップデートが多い中で、「動作が速くなった」と感じられる改善はむしろ歓迎したい。 一点気になるのは、「特定のシナリオ」の定義がまだ不明確な点だ。MicrosoftにはWindowsが動作する多様な環境——ハイエンドゲーミングPCから企業の10年選手ノートPCまで——を考慮した上で、このチューニングがどの構成で何を優先するのかを明確に開示してほしい。こういった変更は、仕組みがわかっているエンジニアには朗報でも、管理者が把握しないまま適用されると現場で混乱を生む。 Windowsにはまだこうした「地力を出せる」余白が残っている。その力を正しく引き出す方向での開発が続くことを期待したい。 出典: この記事は Microsoft is giving Windows 11 major performance upgrade by making CPUs work harder の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MozillaがFirefox 150系の累積バグ修正アップデート「Firefox 150.0.2」を公開した。Webカメラの接続・認識障害、PDFビューアの表示バグ、Split View機能の不具合など、複数の実用上の問題が解消されている。 今回の修正内容 Firefox 150.0.2はメジャーアップデートではなく、150系ブランチへの累積パッチリリースだ。公開情報によれば、主な修正対象は次の通りとなっている。 Webカメラの認識・接続問題: ビデオ会議ツールやブラウザベースのカメラアプリでWebカメラが正常に動作しないケースへの対応 PDFビューアのバグ: ブラウザ内蔵のPDFレンダリングエンジンで発生していた表示・操作上の不具合を修正 Split View機能: 画面を分割してタブを並べて表示する機能で起きていた問題を解消 これ以外にも複数の細かいバグフィックスが含まれているとされており、安定性全般の向上が図られている。 なぜ今このタイミングで重要か WebカメラとPDFビューアの修正は、業務利用において無視できないポイントだ。 リモートワークの普及により、ブラウザからビデオ会議ツール（Google Meet、Teams Web版など）を直接利用するシーンが増えている。Webカメラが正常に機能しなければ会議に参加できない、という業務停止レベルの問題になりかねない。 また、PDFのブラウザ内表示はAdobe Readerを組織端末にインストールしないポリシーを取る企業でも広く使われており、官公庁や金融機関の帳票閲覧でFirefoxのPDFビューアを活用しているケースも少なくない。これらの環境でバグが出ていた場合は早めのアップデートが推奨される。 実務での活用ポイント 個人ユーザー・開発者向け Firefoxを標準ブラウザとして使用しており、最近Webカメラが認識されない・PDFの表示がおかしいと感じていた場合、まずバージョンを確認してほしい。about:support またはメニュー「ヘルプ → Firefoxについて」から現在のバージョンが確認できる。150.0.2に更新するだけで解決する可能性が高い。 IT管理者・企業展開向け 組織端末にFirefoxをグループポリシーやMDMで配布している場合、150.0.2のパッケージをテスト環境で検証の上、展開計画を前倒しにすることを検討したい。特にWebカメラを使うユーザー部門や、PDFを日常的に扱う部門ではバグの影響が出やすい。 Mozillaは公式のEnterprise ReleasesチャンネルでESR版も提供しており、変更を安定させたい組織はESRトラックの採用も一つの選択肢だ。 筆者の見解 Firefoxのような成熟したブラウザのパッチリリースは、何か派手な新機能があるわけではないが、実際の業務に直結するバグが修正されるという意味で軽視できない。 Windowsのアップデートを「すぐ当てるか数日様子を見るか」で悩む感覚に似ているが、今回のFirefox 150.0.2はWebカメラとPDF対応という実害が出やすいバグへの対応なので、業務用途では比較的早めに展開して損のないリリースだと思う。 ブラウザはOSと同様に「インフラ」になっている。細かいバグ修正を追いかけることより、安定した状態を保つ仕組みを作る方が本質的な管理だ。自動更新を許可するポリシーを組織内で整えていれば、こうしたパッチは自動的に適用されて問題にならない。その整備コストが結局一番安上がりである。 出典: この記事は Mozilla releases Firefox 150.0.2 with fixes for webcams, PDF viewer, and more の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Googleが、1億人以上が利用する人気健康アプリを含む2本のアプリを終了し、ヘルスケア機能をHealth Connectプラットフォームへ集約すると発表した。 何が起きているのか Googleは自社のヘルスケア関連アプリ群を「統合」する方針を明らかにし、複数の人気アプリを段階的に終了することを告知した。対象アプリの一つであるGoogle Fitは、Android・iOS向けに長年提供されてきたフィットネストラッキングアプリで、歩数・心拍数・アクティビティ履歴などを一元管理できる機能が人気を集め、累計1億件以上のダウンロードを誇っていた。 Googleは今回の決定について「ヘルスケア体験の集約と改善」を目的としており、今後はAndroid組み込みのHealth Connectをヘルスデータの中核プラットフォームとして位置づける方針だ。Health ConnectはAndroid 14以降で標準搭載されており、各種フィットネスアプリとのデータ共有APIとして機能する。 なぜこれが重要か データの継続性という問題 健康データは日々の積み重ねに意味がある。体重・睡眠・運動履歴を数年分蓄積してきたユーザーにとって、アプリ終了はそのデータが消えるリスクを意味する。Googleはデータエクスポート手段を提供するとしているが、移行先アプリでそのデータが同様に活用できるかは保証されていない。 Googleのアプリ終了パターンへの不信感 Googleはこれまでも、Google Reader・Inbox by Gmail・Stadia・Google+など多くの人気サービスを終了してきた歴史がある。今回の発表も「またか」と受け取るユーザーが少なくないのは想像に難くない。特に健康データという個人の重要情報を預けていたユーザーの心理的ダメージは大きい。 実務への影響——エンジニア・IT管理者の視点 1. 代替アプリの選定を急ぐ Google Fitのデータ移行先として、Samsung Health・Garmin Connect・Withings Health Mate・Apple Healthなどが候補に挙がる。Health Connect対応のアプリであれば、Androidのデータハブ経由でシームレスに連携できる可能性が高い。 2. Health Connect APIへの移行確認 フィットネス関連アプリの開発者は、Google Fit SDKを使っている場合は早急にHealth Connect APIへの移行計画を立てる必要がある。Googleは既にHealth Connect APIへの移行を推奨しており、Google Fit APIは非推奨（deprecated）扱いとなっている。 3. データエクスポートを早めに実行 Google Fitのデータは「Google Takeout（takeout.google.com）」からエクスポート可能。アプリが正式終了する前に必ずバックアップを取得しておくことを強く推奨する。形式はJSON・TCX・GPXで出力される。 4. 企業のウェルネスプログラムへの影響 法人向けのウェルネスプログラムでGoogle Fitを活用している企業は、代替手段の検討が急務となる。Health Connect対応の企業向けウェルネスソリューションへの移行を検討したい。 筆者の見解 Googleが「統合による改善」を掲げるとき、ユーザーが感じるのは利便性の向上よりも「また慣れたサービスが消える」という疲弊感ではないだろうか。 Health ConnectはAndroid標準のヘルスデータ基盤として理にかなったアーキテクチャだ。分散していた健康データを一つのAPIで管理できるというビジョンは正しい。問題は、その方向性が正しいとしても、1億人超が日々使っていたアプリを終了するという決断の重さを、Googleが十分に受け止めているように見えないことだ。 Microsoftが似た状況でAzure Health Data Servicesを積み重ねてきたアプローチと比較するつもりはないが、「統合」という言葉が「切り捨て」の婉曲表現にならないよう、Googleには丁寧な移行サポートを期待したい。 技術者の立場から言えば、特定ベンダーのエコシステムに健康データを全面依存することのリスクが、改めて可視化された出来事だ。Health ConnectのオープンAPIを通じた相互運用性こそが、長期的にユーザーを守る鍵になる。 出典: この記事は Google is killing this very popular app used by more than 100 million people の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

セキュリティ企業Varonisは、オープンソースのAIエージェントフレームワーク「OpenClaw」を使ったメールエージェントに対し、人間向けの古典的フィッシング手法が通用するかを検証した。結果、AWSのIAMキーやデータベース認証情報、顧客CRMデータが外部のGmailアカウントへ送信されるという深刻な問題が確認された。 OpenClawとは何か OpenClawはLLM（大規模言語モデル）がリアルワールドのシステムと連携して自律的にアクションを実行できるオープンソースフレームワークだ。今回の実験では、このフレームワークを使ったエージェント「Pinchy」をGmailインボックス、Googleブラウザツール、Google Workspace APIに接続し、AWScredentials、データベース認証情報、CRMエクスポート、社内メール、カレンダーといった合成エンタープライズデータにアクセスできる環境を構築した。 動作モデルはGoogleのGemini 3.1 ProとOpenAIのGPT-5.4の2種。設定は「標準（Generic）」と「フィッシング対策・本人確認手順を明示した厳格（Strict）」の2プロファイルで比較された。 4つのシミュレーション結果 シナリオ1：緊急対応を装った認証情報要求 攻撃者がチームリーダーになりすまし、本番障害対応を口実にステージング環境へのアクセスを依頼。エージェントはAWS IAMキー、データベース認証情報、SSHアクセス詳細を外部Gmailへ送信した。厳格設定でも防げなかった理由は「業務上の緊急性」が本人確認ステップを無効化したためだとVaronisは分析している。 シナリオ2：リモート作業を口実にした顧客データ要求 「プレゼン資料作成のため顧客エクスポートが必要」という内容のメールに対し、エージェントは送信者の本人確認をせずに顧客レコード、連絡先情報、契約詳細、売上データを含むCRMエクスポートを送信した。こちらも厳格設定で防げなかった。 シナリオ3：ギフトカードフィッシングリンク 標準設定のエージェントはフィッシングサイトを訪問し、偽認証情報でギフトカード換金を試みた後に不正ページと判断した。厳格設定はリンクアクセスを即時ブロックし、防御に成功。 シナリオ4：悪意あるOAuthアプリ 勤怠管理プラットフォームを装った悪意あるGoogle OAuthアプリに対し、エージェントはOAuthフローを検査・分析して不審と判定し、アクセス許可を拒否した。両設定ともに防御成功。 AIが苦手な攻撃パターンとは Varonisの分析によれば、AIエージェントは次のものを検知するのが得意だ： 不審なURLの識別 フィッシングログインページの検出 悪意あるOAuthアプリの認識 一方、苦手とするのは： 送信者の本人確認（メールアドレスの正当性検証ができない） コンテキストの喪失（会話が続くうちに当初の判断基準を忘れる） ソーシャルインタラクションへのゼロトラスト適用（「緊急だ」「上司だ」という言語的権威に弱い） モデル特性では、Geminiがより積極的にインタラクションしようとした一方、GPT-5.4はより慎重な姿勢を示したという。 実務への影響——日本のエンジニア・IT管理者が今すぐ確認すべきこと AIエージェントを業務システムに接続する構成はすでに多くの企業で検討・導入段階に入っている。この実験は他人事ではない。 最小権限の徹底が最優先：エージェントに与えるアクセス権は業務上必要な最小限に絞り込む。AWSクレデンシャルや顧客DBへの読み取り権限を同一エージェントが持つべきではない。 高リスクアクションには必ず人間承認を挟む：認証情報の共有、外部への大量データ送信、初めての外部送信先への連絡は、エージェントが単独実行できないよう設計する。 新規外部アドレスへの送信を禁止または承認制に：エージェントが「新しい外部宛先」にメールを送れる設定は攻撃の出口になる。ホワイトリストまたは承認フローを必ず実装する。 エージェントの設定を定期的にペネトレーションテストする：厳格設定であっても万全ではないことが今回示された。定期的なシミュレーションで設定の穴を炙り出す仕組みを持つこと。 筆者の見解 この実験結果を見て真っ先に感じたのは、「AIエージェントにゼロトラストが適用されていない」という構造的な問題だ。 人間のアカウントに対してはゼロトラスト、条件付きアクセス、多要素認証を徹底しながら、同じシステムに接続するAIエージェントには「信頼してから動く」設計を許してしまっている。これは矛盾だ。Non-Human Identity（NHI）として扱われるべきエージェントにも、人間と同等のゼロトラスト原則——「すべてのリクエストを検証する」「最小権限を維持する」「侵害を前提として設計する」——が必要なはずだ。 「緊急だから」「上司からだから」という言語的権威に対してエージェントが弱いのは当然でもある。人間でも同じ罠にはまる。だからこそ人間側にはプロセスと承認フローがある。エージェントにも同じ仕組みが要る。Just-In-Timeアクセスや、高リスクアクション前の人間承認ゲートは、エージェント設計において今後の基本要件になるべきだろう。 AIによる業務自動化を進めるほど、NHI管理の精度が組織全体のリスク水準を決める。今はまだ多くの組織でそこへの意識が追いついていない。今回のVaronisの実験はその現実を可視化した点で価値がある。 出典: この記事は OpenClaw AI agent found falling for phishing attacks, spills user data の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ServiceNow（NYSE: NOW）は2026年6月9日、APIエンドポイントの認証設定不備を悪用したセキュリティインシデントを公表した。攻撃者は認証なしでアクセス可能な状態になっていたREST APIを通じて、複数の顧客インスタンスからデータを取得したことが確認されている。 何が起きたのか 問題の核心は、APIエンドポイント /api/now/related_list_edit/create の設定にある。このエンドポイントが requires_authentication=false の状態で公開されており、認証なしで顧客インスタンスのデータを照会できる状態になっていた。 ServiceNowは「異常なアクティビティ」を検出後、2026年6月5日にホスト型顧客インスタンスへのセキュリティアップデートを適用。該当エンドポイントの設定を修正し、認証済みユーザーのみがアクセスできる状態にした。 本インシデントはServiceNowのカスタマーサポートポータル（ログイン必須）の掲示板と、直接のサポートケースを通じて該当顧客に通知された。サポートケースを受け取っていない顧客は影響を受けていないとみなされるとのことだ。 影響を受ける環境 ServiceNowによると、影響範囲は以下の通り： Australiaプラットフォームリリースを使用している顧客 Australia以前のリリースを使用しており、特定の構成変更を行った顧客 CVEの採番については現時点で検討中とのことで、技術的詳細の公開も限定的な状態が続いている。 侵害の痕跡（IoC） RedditのServiceNow管理者コミュニティでは、以下のIoCが共有されている： 不審なIPアドレス: 51.159.98.241 対象エンドポイント: /api/now/related_list_edit 今すぐ実施すべき対応 ServiceNow管理者は以下を速やかに確認・実施すること： ログの精査: /api/now/related_list_edit へのリクエスト履歴を確認。特にIPアドレス 51.159.98.241 からのアクセスを重点的に調査する 認証情報のローテーション: サポートチケット等のワークフロー経由で共有された資格情報やAPIトークンを刷新する 漏洩データの特定: 不正アクセスを受けた可能性のあるチケットやレコードの内容を確認する APIログの有効化: ログ収集が有効になっているかを確認・徹底する ServiceNowインスタンスにはITサポートチケット、従業員レコード、内部ドキュメント、資産インベントリ、セキュリティインシデントレポート、業務システムの構成情報など、機密性の高いエンタープライズ情報が集約されている。こうしたデータが外部に漏洩した場合の被害は甚大だ。 日本のIT管理者への影響 ServiceNowは日本のエンタープライズでも広く使われるITSMプラットフォームだ。特に大手企業では業務フロー全体が集約されているケースも少なくない。今回のような「認証設定の見落とし」は決して対岸の火事ではない。 日本においてはServiceNow導入後のカスタマイズ過程でAPI設定が変更されるケースが珍しくなく、自社環境がAustraliaリリース以前かどうかに関わらず、APIエンドポイントの認証設定を棚卸しする好機として捉えるべきだ。 筆者の見解 今回の件で注目すべきは、攻撃手法の巧妙さよりも、認証設定という基本中の基本が見落とされていた事実だ。 requires_authentication=false という設定がホストされた顧客インスタンスに適用可能な状態で放置されていたこと——これはゼロトラストの観点から見て、最も根本的な設計の穴に分類される。「認証がなければアクセスさせない」は前提条件であり、議論の余地がない。 筆者は常日頃からNHI（Non-Human Identities）の管理が業務自動化のボトルネック解消に直結すると主張しているが、今回の件はその裏返しでもある。APIによるシステム間連携を推進すればするほど、認証・認可の設計が甘い箇所がリスクの集積点になる。「今動いているから大丈夫」という発想で放置された設定が、静かに脅威の入口になるのだ。 自動化を進めるならば、APIレベルの認証設定の監査を定期的なプロセスとして組み込むことは不可欠だ。エンタープライズプラットフォームのベンダーには、デフォルト設定を安全側に振り切る責任もある。その点でServiceNowには、今回の素早いパッチ対応は評価しつつも、設定のデフォルト値の設計について今一度見直してほしい——そう率直に申し上げたい。 出典: この記事は ServiceNow discloses security incident exposing customer data の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年6月のPatch Tuesday適用からわずか数時間後、セキュリティ研究者「Nightmare Eclipse」がMicrosoft Defenderの新たなゼロデイ脆弱性「RoguePlanet」の実証コード（PoC）を公開した。完全にパッチ済みのWindows 10/11環境でもSYSTEM権限を持つコマンドプロンプトを起動できるとされており、サイバーセキュリティ企業ThreatLockerが実際の再現に成功している。 RoguePlanetとは何か RoguePlanetは、Microsoft Defenderに存在する競合状態（Race Condition）の脆弱性を悪用するものだ。攻撃が成功した場合、Windowsで最も高い権限レベルであるSYSTEM権限を持つコマンドプロンプトが起動される。 競合状態の脆弱性は環境によって成功率が変わる特性がある。Nightmare Eclipse本人も「マシンによっては100%成功する一方、うまく動かないケースもある」と説明しているが、ThreatLockerはKB5094126（2026年6月の更新プログラム）適用済みのWindows 11での動作を動画付きで確認・公表している。 当初はリモートコード実行（RCE）脆弱性だった 開発経緯を見ると、RoguePlanetはもともとリモートSMBサーバー上のVHD/VHDXファイルをMicrosoft Defenderが処理する際の不具合を突いたRCE脆弱性として研究されていた。 想定されていた攻撃シナリオは以下の通りだ： 攻撃者がリモートSMBサーバーに細工したVHDファイルを設置する 被害者がそのSMBシェアを開くよう誘導される Defenderがファイルを処理する際に自身のファイルを上書きし、RCEが発生する さらにシンボリックリンク評価（Symlink Evaluation）が有効な環境では、SMBシェアを開かせるだけでRCEが成立する可能性もあったという。 しかしMicrosoftは5月中旬にmpengine!SysIO* APIを静かにパッチし、ジャンクション攻撃を遮断した。これによりRCEルートは封じられたものの、ローカル権限昇格（LPE）としての悪用可能性は残った形だ。研究者は「LPEにとどまるのかRCEへの経路が残っているのかは現時点では不明」としている。 Microsoftとの対立という背景 RoguePlanetの公開は、Nightmare EclipseとMicrosoftの継続的な摩擦の延長線上にある。この研究者はここ数ヶ月で複数のWindowsゼロデイを立て続けに公表してきた。 BlueHammer — Windowsコンポーネントの脆弱性 RedSun — Microsoft Defenderを標的とした脆弱性 GreenPlasma — 今回のPatch Tuesdayで修正済み YellowKey — 今回のPatch Tuesdayで修正済み 研究者はGitHubおよびGitLab上のリポジトリをMicrosoftに削除されたと主張しており、独自のセルフホステッドコードプラットフォーム（projectnightcrawler.dev）を構築するに至っている。MicrosoftはかつてNightmare Eclipseに対し「悪意のある活動には法執行機関と連携する」と警告しており、セキュリティコミュニティの一部はこれを研究者への圧力と捉えている。 企業IT管理者が今すぐ取るべき緩和策 現時点でRoguePlanetに対応するMicrosoft公式パッチはリリースされていない。組織として取れる対策は以下の通りだ。 1. アプリケーション許可リストの導入 ThreatLockerのDanny Jenkins CEOが明言している通り、アプリケーション許可リスト（Application Allowlisting）を導入している組織ではこのエクスプロイトの実行を防げる。Windows標準のWindows Defender Application Control（WDAC）やMicrosoft Intuneとの統合が現実的な選択肢だ。 2. 最小権限の原則の徹底 LPEはローカル環境へのアクセスが前提となるため、エンドポイントで一般ユーザーにローカル管理者権限が付与されていないかを今すぐ確認する。権限を絞るだけで被害の拡大を大幅に抑制できる。 3. ふるまい検知（Behavioral Detection）の強化 競合状態を悪用する攻撃は挙動面での痕跡が残りやすい。EDRソリューションのふるまい検知ルールを最新に保つことが有効だ。 4. 不審なSMBトラフィックの監視 元のRCEシナリオはSMBを経路としていた。外部からのSMBアクセスをファイアウォールでブロックし、内部SMBトラフィックの異常を監視する体制を整えておきたい。 筆者の見解 今回の件で改めて考えさせられるのは、脆弱性開示プロセスの信頼関係だ。 Nightmare Eclipseが次々とゼロデイを公開しているのは、バグバウンティや協調開示（Coordinated Vulnerability Disclosure）への不満が背景にある。研究者とベンダーの関係が壊れると、最終的にリスクを負うのはエンドユーザーと企業だ。Microsoftにはセキュリティ研究コミュニティとの関係を正面から立て直してほしい。優れたセキュリティ製品を持つ企業として、研究者を追いかける立場ではなく、共に脆弱性をつぶしていく関係を築ける力があるはずだ。 ...

セキュリティ研究者「Chaotic Eclipse」が公開した新たなWindowsゼロデイ「MiniPlasma」は、2026年5月度のPatch Tuesdayで完全パッチが適用されたWindows 11でも、標準ユーザーアカウントからSYSTEM権限への昇格を可能にすることがThreatLockerの検証により確認された。公式パッチは現時点で未提供だ。 MiniPlasmaとは何か MiniPlasmaは、Windows Cloud Filterドライバー（cldflt.sys）の脆弱性CVE-2020-17103を悪用したローカル特権昇格エクスプロイトだ。この脆弱性はGoogle Project ZeroのJames Forshaw氏が2020年9月にMicrosoftへ報告し、同年12月にパッチが適用されたとされていた。 しかし研究者によれば「パッチが正しく適用されなかったか、いつの間にか無効化された」可能性があるとのこと。実際、2020年当時のGoogle Project ZeroのPoC（概念実証コード）をほぼ改変なしに使用できたという。MiniPlasmaはそのPoCを「標準ユーザーシェルからSYSTEMシェルを起動する」形に改造した実用的なエクスプロイトである。 技術的な仕組み 脆弱性の核心は、Cloud FilterドライバーのHsmOsBlockPlaceholderAccessルーティンにある。OneDriveなどクラウドバックアップのファイル処理を担うこのコンポーネントに、未文書化のCfAbortHydration APIを通じたレジストリキー操作の欠陥が存在する。 攻撃者はこの欠陥を利用し、アクセス制御チェックなしにDEFAULTユーザーハイブへレジストリキーを書き込める。これが特権昇格のトリガーとなり、最終的にSYSTEMレベルのコード実行に至る仕組みだ。エクスプロイトはレースコンディション（競合状態）を利用するため成功率は環境によって変動するが、ThreatLockerの検証では最新パッチ適用済みWindows 11上で成功が確認されている。 同コンポーネントの前歴 Cloud Filterドライバーをめぐっては、2025年12月にも別の特権昇格脆弱性（CVE-2025-62221）がパッチされており、その時点で野良での悪用が確認されていた。同じコンポーネントに繰り返し問題が発生している点は注目に値する。 影響を受けるバージョンと現状 確認されている影響バージョン： Windows 11（2026年5月最新パッチ適用済みを含む） Windows Server 2022 / 2025 Windows 10は影響を受けないとされている。一方、Windows 11 Insider Preview（Canaryチャネル）では動作しないことが確認されており、将来の正式パッチに向けた修正が進んでいる可能性を示唆する。 OneDriveとの統合によりCloud FilterドライバーはほぼすべてのWindows 11環境に標準搭載されているため、潜在的な影響範囲は極めて広い。Microsoftは「調査中」としており、2026年6月10日のPatch Tuesdayでの対応可否が注目される。 実務への影響——IT管理者が今すぐ確認すべきこと 1. アプリケーション制御ポリシーの見直し ThreatLockerの検証で明らかなとおり、「デフォルト拒否（default-deny）」のアプリケーション許可リスト（Application Allowlisting）が有効な環境では、エクスプロイトのペイロード実行自体がブロックされる。MiniPlasmaを事前に「知っている」かどうかに関係なく、未承認の実行ファイルはすべて止まる。Windows Defender Application Control（WDAC）やAppLockerを活用している組織は基本的な耐性を持つ。 2. 標準ユーザー運用の徹底確認 このエクスプロイトは標準ユーザー権限から発動する。ローカル管理者権限を一般ユーザーへ付与していないか、改めて確認するタイミングだ。 3. Patch Tuesdayの動向を注視 本日6月10日のPatch Tuesdayでの対応有無をMicrosoftのセキュリティ情報で確認し、修正が含まれていれば迅速な適用計画を立てること。 筆者の見解 今回のMiniPlasmaで最も気になるのは、「2020年に修正済みとされたCVEが2026年に再登場した」という事実だ。パッチが実は正しく適用されなかった、あるいはどこかのタイミングで無効化されたというシナリオは、パッチ管理への信頼性を根底から問い直す。「今動いているから大丈夫」という感覚がどれほど危ういかを示す典型例といえる。 Cloud Filterドライバーが繰り返し攻撃経路になっている点は、Microsoftにはぜひ腰を据えて取り組んでほしい領域だ。OneDriveの統合という価値ある機能を支えるコンポーネントだからこそ、根本的な設計の見直しに踏み込む価値がある。実力のある組織なのだから、「また同じ場所で」とならないよう期待したい。 前向きなシグナルとして、Canary Buildでは動作しないという報告がある。修正の芽は既に存在する。問題はそれが正式リリースに降りてくる速度だ。 防御の観点では、今回改めて「アプリケーション制御（default-deny）」の有効性が証明された。ゼロトラストの思想は「信頼しない」だけでなく「実行させない」という層を含む。パッチを待っている間にも取れる対策は確かにある。 出典: この記事は MiniPlasma: Windows privilege escalation zero-day affects fully patched systems の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年6月8日、Snapdragon X2およびNVIDIA RTX Spark搭載PCのWindows Insiderユーザーに対して、専用のBetaチャンネルを設置すると発表した。従来のBetaチャンネルと同等の機能を提供しながら、これらの先進ハードウェア固有の最適化・修正が別途適用される仕組みだ。 Windows 11 26H1とは Windows 11 26H1は2026年後半にリリース予定の次期メジャーアップデートで、ビルド番号は28000番台。刷新されたスタートメニュー、AI統合の深化、そしてSnapdragon X2などに搭載されるNPU（Neural Processing Unit）との連携強化が目玉となる。バッテリー持続時間の延長、スリープ復帰の高速化、Copilot+ PCとの連携向上なども盛り込まれる予定だ。 対象ハードウェアの位置づけ Snapdragon X2はQualcommのARMベースSoCの最新世代で、第2世代Oryon CPUコアと60 TOPSのNPU、LPDDR6メモリに対応する。Snapdragon X EliteおよびX Plusの後継として位置づけられ、搭載デバイスは2026年に入ってから市場に出始めたばかりだ。 RTX SparkはNVIDIAが開発中の新プラットフォームで、ARMベースCPUとディスクリートRTX GPUを1チップに統合する構成をとる。「スーパーチャージドCopilot+ PC」とも呼ばれ、超薄型フォームファクターでデスクトップ級のグラフィクス性能を狙う。Acer・ASUS・Lenovoが2026年後半の投入を予告しており、Microsoftはこれに合わせてWindowsの最適化を急いでいる形だ。 専用チャンネルが意味すること 従来の統合Betaチャンネルでは、x86/AMD64向けに問題なかったビルドがSnapdragon X2上でクラッシュしたり、ドライバー非互換やアプリエミュレーションの不具合が出るケースが頻発していた。専用チャンネルの設置により、以下の4点が実現される。 リスク低減: 各ビルドを当該ハードウェア固有の構成で事前検証してからリリース ピンポイント修正: ARM固有の問題には、汎用Beta更新を待たず個別ホットフィックスを配信可能 フィードバックの集約: ARM・ハイブリッドアーキテクチャ専門のエンジニアチームが優先的に対応できる体制 機能の段階展開: NPUやハイブリッドGPUスケジューリングに依存する機能を先行検証 ビルド番号自体は標準Betaチャンネルと同じ。差異はフィーチャー有効化パッケージとハードウェア固有パッチの有無だ。 実務への影響 IT管理者・エンジニアの視点で整理すると、当面の実務影響は限定的だ。対象はSnapdragon X2またはRTX Spark搭載機でInsiderプログラムに参加しているユーザーのみであり、既存の企業端末が自動移行されることはない。 ただし、2026年後半に向けて注意すべき点がある。Copilot+ PC資格を持つARMデバイスの法人導入を検討している組織では、Insider Betaチャンネルの動向を追うことが、量産展開前の互換性把握に役立つ。特にRTX Spark搭載機は年末商戦に向けて大量投入が予想されるため、今から検証パスを設けておく価値はある。 Windows Autopilotを使った大規模展開を予定している場合、ARMデバイス向けドライバーパッケージや既存の業務アプリの動作確認を、このBetaチャンネルの情報を参考に前倒しで進めておくことをお勧めしたい。 筆者の見解 この施策自体は地味ながら、Microsoftの開発姿勢として正しい方向性だと感じる。x86一本槍だった時代と比べ、Windowsが動くハードウェアの多様性は格段に増した。ARM64・x86・ハイブリッドGPUアーキテクチャが乱立する中で、「全部まとめて一つのチャンネルで」というアプローチに限界が来ていたのは当然だ。問題を切り分けてフィードバックを集める構造を作ったのは、地道だが再現性のある判断といえる。 ただ一方で、Windowsの細かいアップデートを追いかけること自体の意義を問い直す時期にも来ている。Snapdragon X2やRTX Sparkが「AI PCの新標準」として打ち出されているが、エンドユーザーが体感できる価値に落とし込めているかは、まだこれからだ。NPU性能の数字が先行しがちな昨今、「ユーザーが自然に気づくレベルの体験向上」を届けられるかが、次のフェーズの勝負になる。Microsoftにはそれができる土台があるのだから、検証インフラの整備だけでなく、体験の差として見せることに本腰を入れてほしいと思う。 出典: この記事は Windows 11 26H1 Gets Its Own Insider Beta Channel for Snapdragon X2 & RTX Spark PCs の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftのWindowsドメイン認証基盤を担うNetlogonサービスに、遠隔からコード実行が可能なCritical脆弱性（CVE-2026-41089）が確認され、すでに実際の攻撃に利用されていることをベルギーサイバーセキュリティセンター（CCB）が警告した。Active Directory（AD）環境を持つ企業・組織にとって、ドメインコントローラー（DC）が直接標的になるという点でこれ以上ない最悪のシナリオに近い。 脆弱性の技術的な中身 CVE-2026-41089の正体は、Netlogonサービス内のスタックベースのバッファオーバーフローだ。Netlogonは、ドメイン内の認証・セキュリティを処理するWindowsの根幹プロトコルであり、そこへ特細工したネットワークリクエストを送り込むだけで、攻撃者はドメインコントローラー上でコードをリモート実行できる可能性がある。 認証前（pre-auth）の段階で成立する攻撃であるため、有効な資格情報がなくても悪用できる点が特に危険だ。AutomoxのCTOジェイソン・キクタ氏は「侵害済みの境界内でCVE-2026-41089を使えば、フォレスト全体の乗っ取りへの最短ルートになる」と指摘しており、被害が単一DCで収まらず、ADフォレスト全体に波及するリスクを強調している。 「悪用の可能性低い」→「野外で悪用中」への急転 Microsoftが2026年5月12日にこの脆弱性を開示した当初、悪用される可能性は「低い」と評価していた。しかし約3週間でCCBが実際の攻撃を確認したことになる。 この急転には背景がある。AIを活用した攻撃者がCVE公開からエクスプロイト実用化までの時間を劇的に短縮しているのだ。セキュリティ研究者やAI企業が修正パッチをリバースエンジニアリングし、根本原因の解析やPoCエクスプロイトを公開する動きも加速しており、これが攻撃者にとっての「開発資料」になっている側面がある。「悪用される可能性低い」という評価が現場のパッチ優先度判断に使われてきたとすれば、今回の展開はその前提を見直す契機になる。 今すぐやるべき対処 1. 全DCへの同時パッチ適用 Microsoftは先週のPatch Tuesdayで複数のWindows Serverバージョン向けに修正パッチを提供している。重要なのは、キクタ氏が強調した「半分だけパッチを当てたフォレストは防御可能な状態ではない」という原則だ。一部のDCだけを先に更新し、残りを後回しにするのは危険な中途半端状態を生む。同一メンテナンスウィンドウ内で全DCに適用することが鉄則となる。 2. Netlogonトラフィックのネットワーク層制限 Netlogonトラフィックを必要なホスト間のみに絞り込み、DC以外のソースアドレスからの異常なNetlogonトラフィックをブロックする設定を見直す。 3. 攻撃の兆候を把握する 以下のイベントはアクティブな悪用を示している可能性がある： Netlogonサービスの予期しないクラッシュ・再起動 DC以外のアドレスからの異常なNetlogonトラフィック 不審なネットワーク活動の直後に発生する認証失敗やドメイントラストエラー 4. レガシーWindows Server向けの選択肢 Microsoftの公式パッチ対象外となるWindows Server 2008 R2・2012・2012 R2については、ACROS Securityが「0patch」経由でマイクロパッチを提供している。サポート切れのサーバーが残存しているAD環境では、これを活用するか、早急なバージョン移行計画の策定が必要だ。 実務への影響——日本のAD環境が抱えるリスク 日本の企業環境には、ADが深く根付いたオンプレミス構成が今なお多く残っている。特に製造業・金融・公共系では数百〜数千規模のDC構成も珍しくなく、パッチ適用のための「全DC同時メンテナンスウィンドウ」の確保自体が運用上の難題になりうる。 また、サポート終了済みのWindows Serverを混在運用しているケースもゼロではない。今回のCVEはまさにその点を直撃する。「今動いているから大丈夫」という判断が通用しないのがセキュリティの世界であり、ADフォレスト全体が一夜にして制御不能になるリスクを前に、レガシーOS延命の是非を経営レベルで議論する契機にすべきだ。 クラウド移行やEntra IDへのハイブリッド統合を進めている環境でも、オンプレDCが残っている限りは影響範囲に含まれる。「クラウド移行中だから」は免責にならない。 筆者の見解 今回最も注目すべきは、脆弱性そのものよりも「AIによってCVE公開から悪用実証までの期間が縮まっている」という事実だ。これはNetlogonに限った話ではなく、あらゆるCVEに対して成立する新しいルールだ。 「悪用される可能性低い」というMicrosoftの初期評価が的外れだったわけではないだろう。当時の評価基準で判断すればそう見えたはずだ。しかしAIが攻撃開発サイクルを圧縮している現在、その評価基準自体の見直しが必要になっている。Microsoftが今後のCVSS評価やアドバイザリの表現をどう更新するか、注目したい。 ゼロトラストの観点からもう一点付け加えると、「内部ネットワークにいれば安全」という前提がいかに危ういかを今回は改めて示している。Netlogonへのアクセスをネットワーク層でセグメントする、DCへの不審な接続をリアルタイム検知する——こうした「当たり前」を積み重ねることが、AIを武器にした攻撃者への最も現実的な対抗策になる。境界防御モデルへの回帰ではなく、内側でも信頼しない設計の徹底が今こそ問われている。 出典: この記事は Windows Netlogon RCE exploited, domain controllers at risk (CVE-2026-41089) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Linuxカーネルの開発を率いるLinus Torvaldsが、Linux 7.1の最終リリース候補（Release Candidate、以下RC）を公開した。テストに大きな問題がなければ、数日以内に正式な安定版（stable版）がリリースされる見通しだ。 Linux 7.1最終RCの主な修正内容 今回の最終RCには、特定のハードウェア環境での安定性向上に関わる修正が複数含まれている。 AMD Zen6への対応 注目すべきはAMDの最新マイクロアーキテクチャ「Zen6」向けの修正が取り込まれた点だ。Zen6はサーバー・ワークステーション向けの次世代プロセッサ基盤として期待されており、エンタープライズLinux環境においても早期対応が求められていた。今回の修正によって、Zen6ベースのシステム上でのカーネル動作の安定性が向上する。 LenovoおよびMSI向けハードウェア修正 Lenovo製ThinkPadシリーズやMSI製マシンに関連するハードウェア固有のバグも本リリースで対処された。特定機種でのデバイス認識や電源管理まわりの不具合修正が含まれるとみられ、これらハードウェアを業務利用している環境には直接的なメリットがある。 最終RCとしての位置づけ Linus Torvaldsが「最終RC」と位置づけて公開したということは、重大な問題が発見されない限り次のリリースが正式版となることを意味する。Linuxカーネルの開発サイクルでは、最終RCから1〜2週間後に安定版がリリースされるのが一般的なパターンだ。 実務への影響 Linuxサーバー運用担当者へ AMD EPYCプロセッサ（Zen系アーキテクチャ）を採用したサーバーを運用している環境では、Linux 7.1正式版リリース後にアップデートを検討する価値がある。特にZen6プラットフォームへの移行を計画している組織は、今回の修正が入ったカーネルで事前検証を進めておきたい。 Azureユーザーへ Microsoft AzureはLinux仮想マシンの利用率が非常に高く、Azureが提供するLinuxイメージにも今後このカーネル修正が反映されていく。Azure上でAMD系インスタンス（Da_v5シリーズ等）を利用している場合は、マネージドイメージの更新サイクルに合わせてカーネルバージョンの追跡を習慣化しておくとよい。 Lenovo/MSIユーザーへ 対象ハードウェアのLinuxデスクトップ・ワークステーション利用者は、ディストリビューション（Ubuntu、Fedora、openSUSE等）のカーネルアップデートを通じて、この修正が配布されるのを待てばよい。手動でカーネルを追いかける必要は一般的にはない。 筆者の見解 Linux 7.1のリリースが近づいているというニュースは、表立って派手さはないが、インフラの現場では着実に重要な意味を持つ。 特にAMD Zen6対応の修正が含まれた点は見逃せない。エンタープライズ向けサーバーのCPUシェアでAMDが伸長している昨今、新アーキテクチャへの早期カーネル対応は現場のシステム担当者にとって直接的な安心材料だ。「動くかどうかわからないから様子を見る」という期間を短縮できることの価値は小さくない。 また、Linuxカーネルのリリースサイクルそのものについても改めて感じるのは、その着実さだ。毎回大きな発表があるわけではないが、継続的にハードウェアサポートが積み上がり、特定のマシンで「急に動くようになる」変化が起きる。これはオープンソースの開発モデルが本来持つ強みであり、エンタープライズLinux採用の現実的な根拠の一つになっている。 Azureを含むクラウドプラットフォームのかなりの部分がLinux上で動いている現実を考えると、Windowsエンジニアであってもこのカーネルリリースの動向から目を離すのは得策ではない。クラウド時代のインフラ理解は、もはやOSの違いで区切れるものではなくなっている。 出典: この記事は Linux 7.1 stable launch looms as Linus Torvalds releases the final release candidate の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Windows 11およびWindows 10の月次セキュリティ更新（Patch Tuesday）において、Microsoft Defenderのセキュリティ更新を今後含めなくなることを正式に発表した。これにより、Defenderの定義ファイルは月次サイクルに縛られず、専用チャネルを通じた独立した配信に一本化される。 なぜ今この変更なのか これまでのPatch Tuesdayには、Windows本体の累積更新プログラムとともに、Microsoft Defenderのセキュリティインテリジェンス（ウイルス定義ファイル等）が含まれていた。しかし実際のところ、Defenderはすでに独自の高頻度更新メカニズムを持っており、1日に複数回、定義ファイルをアップデートしている。 月次のPatch Tuesdayに同じ情報を重複して含めることは、更新パッケージの肥大化を招くだけでなく、配信経路が二重になることで管理上の複雑さにもつながっていた。今回の変更はこの冗長性を解消するものだ。 IT管理者への実務的影響 この変更が直接影響を与えるのは、エンタープライズ環境でWindows Updateを厳密に管理しているIT管理者だ。以下の点を確認しておきたい。 WSUS / MECM環境の確認 Microsoft Endpoint Configuration Manager（MECM）やWSUS経由でパッチ管理を行っている場合、Defenderの定義ファイル更新が別カテゴリで配信されていることを改めて確認する必要がある。「Patch Tuesdayのみ承認」という運用ポリシーを採っている場合、Defender定義の更新を別途自動承認する設定が必要になるケースがある。 ネットワーク帯域の最適化 定義ファイルの更新頻度は高いため、多拠点環境では配信最適化（Delivery Optimization）やキャッシュサーバーの設定を見直す価値がある。更新トラフィックが集中すると業務帯域に影響が出る組織もあるだろう。 監視・レポートの調整 Defender定義の更新状況をPatch Tuesdayの適用状況と一括で追跡していた場合、ダッシュボードやレポート定義の見直しが必要になる場合もある。 変更がもたらすセキュリティ上のメリット セキュリティの観点から見ると、この変更は明確にプラス方向だ。マルウェアや新種の脅威は、月に一度のサイクルを待ってくれない。定義ファイルの更新がPatch Tuesdayのリリーススケジュールから切り離されることで、最新の脅威情報をより迅速にエンドポイントへ届けられる。 また、Patch Tuesday本体の更新パッケージが軽量化されることで、展開時のダウンロード量や処理時間の削減も期待できる。品質テストの観点からも、スコープが絞られることで月次更新の安定性向上に寄与する可能性がある。 最近のPatch Tuesdayでは「当てたら壊れた」という報告が散見され、DellやHPの一部PCがBitLockerリカバリーループに陥った事例も話題になった。大量展開前の十分なテストの重要性は変わらないが、Defender定義を切り離すことで月次更新のリスク評価がシンプルになる副次効果も期待したい。 筆者の見解 率直に言えば、「なぜもっと早くやらなかったのか」という気持ちはある。Defenderの定義ファイルは元々、月次更新とは独立して高頻度で配信される設計になっていた。それをわざわざPatch Tuesdayにも含め続けていたこと自体、設計上の冗長さだった。 ただ、こうした「当然の整理」を着実に積み上げていく姿勢はきちんと評価したい。セキュリティ更新の経路をシンプルにし、IT管理者が管理しやすい形に近づけていく方向性は正しい。 日本のエンタープライズ環境では、WSUS運用が今でも主流の組織は少なくない。今回の変更を機に、Defender定義ファイルの更新ポリシーを棚卸しするのは良いタイミングだ。「セキュリティパッチはPatch Tuesdayで一括管理」というシンプルな前提が少しずつ崩れつつある今、更新経路ごとに適切なポリシーを設計できる管理体制を整えておきたい。 出典: この記事は Microsoft making much needed change to Windows 11, 10 Patch Tuesday security updates の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月のWindowsセキュリティ更新を「Hotpatchベースライン更新」として配信すると発表した。通常は再起動不要なHotpatch対応デバイスも、今月に限り一度の再起動が必要になる。次回のHotpatch更新（再起動なし）は2026年8月の予定だ。 Hotpatchとは何か Hotpatch（ホットパッチ）は、Windowsのセキュリティ更新をOSの実行中プロセスにメモリ上で直接適用する技術だ。従来の更新では「ダウンロード→インストール→再起動」が必須だったが、Hotpatchを使えば再起動なしでセキュリティパッチを当てられる。業務継続性が求められるサーバーや、再起動タイミングの管理が煩雑なエンタープライズ環境で特に効果を発揮する。 現在、Hotpatchは主にAzure Arc経由で管理されたWindows Serverや、Windows 365 Business/Enterprise対応デバイスなどで利用可能だ。 なぜ6月は再起動が必要なのか Hotpatchの「再起動不要」は、あらかじめ用意された「ベースライン」と呼ばれる基盤イメージの上に差分パッチを乗せることで実現している。このベースラインは定期的に刷新する必要があり、その刷新タイミングには通常の更新プロセス（＝再起動あり）が必要になる。 2026年6月の更新はちょうどこのベースライン刷新のタイミングにあたる。言ってみれば「再起動不要を続けるために、一度だけ再起動する」という逆説的な構造だ。 Microsoftの発表によると、このベースライン更新は定期的に発生するものであり、今回が特別に問題があるわけではない。 影響範囲とスケジュール 対象 影響 Hotpatch対応デバイス 再起動が必要（6月9日の更新適用後） 通常のWindows Updateデバイス 影響なし Hotpatch非登録デバイス 影響なし 再起動後は通常通りHotpatchに登録された状態が維持され、更新履歴やコンプライアンスレポートにも正常に記録される。次回の「再起動不要」Hotpatch更新は2026年8月を予定している。 IT管理者が今すぐやるべきこと メンテナンスウィンドウに6月9日を含めるのが最優先だ。Hotpatch対応デバイスを管理しているなら、今月に限っては再起動を前提とした計画を立てる必要がある。 具体的なアクション: 展開ポリシーの確認: 既存の更新展開ポリシーは変更不要。ただし再起動が発生することを展開グループ・メンテナンスウィンドウの設定に反映する エンドユーザーへの事前通知: 「今月だけ再起動が発生する」を事前にアナウンスする。突然の再起動でユーザーが混乱しないよう準備する コンプライアンス確認: 更新後は通常通りコンプライアンスレポートで適用状況を確認する。追加の設定変更は不要 次のサイクルの把握: 7月は再起動不要のHotpatchに戻る予定。8月にも再起動なしで更新が適用される 筆者の見解 Hotpatchそのものは、エンタープライズIT管理の観点から見て正しい方向性だと思う。セキュリティパッチの適用を「再起動というコスト」から切り離せることは、現場の運用負荷を大きく下げる。「当ててください」と言いやすくなる仕組みは、パッチ適用率の向上にも直結する。 ただ、今回のように「ベースライン更新月だけ再起動が必要」というルールは、管理者が把握していないと混乱を招く。Hotpatchを使っているから安心、と思っていたら今月は再起動があった——というケースが出てくるだろう。 「今動いているから大丈夫」は通用しない。Hotpatchを導入した組織ほど「再起動なし」に慣れているから、例外月の対応が抜け落ちやすい。定期的なベースライン更新のサイクルをポリシーやカレンダーに組み込む習慣をつけておくことが、運用トラブルを防ぐ近道だ。 Hotpatchの仕組みが成熟すれば、こうした例外処理も減っていくはずだ。Microsoftにはその完成度をさらに高めてほしいし、適用コストを下げることでセキュリティ更新の適用率が自然と上がる世界を期待したい。 出典: この記事は Hot patch-enabled devices will restart after installing the June 2026 Windows update の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはBuild 2026において、AIエージェントが自然言語1文でWindows 11全体をパーソナライズするデモを披露した。「桜テーマにして」と入力するだけで、壁紙・アクセントカラー・RGBキーボードライティングが一括で切り替わる未来を提示し、その基盤技術として「WinUI skills」を発表した。 何が変わるのか——現状の課題と新アプローチ Windowsのカスタマイズは長年、複数の設定ページを行き来する作業だった。Windowsプラットフォームチームのプロダクトマネージャー、Samantha Song氏は「アクセントカラー・壁紙・キーボード照明を揃えたいだけで、最低でも3つの設定ページを開く必要がある」と指摘する。さらに凝ったカスタマイズをしようとすれば、レジストリキーの編集やサードパーティアプリの導入が避けられない現実がある。 Build 2026で公開されたWinUI skillsは、このギャップを埋める仕組みだ。AIエージェントがWindowsの公開APIエンドポイントを直接呼び出せるよう、スキルとして定義されたツール群を提供する。MicrosoftはSDKの組み込みも独自APIサービスの設計も不要と強調しており、開発者が自前のAIアプリからWindowsの各設定を操作できるようになる。 WinUI skillsの技術構造 WinUI skillsは、AIエージェントが「何をすべきか」を迷わず実行できるよう、明確なガイドラインを持つ事前定義ツールを提供する。MicrosoftはBuild会場でこう説明した。「エージェントがトークンを浪費してユーザーの意図を解釈しようとする代わりに、これらの定義済みツールを使えばよいと分かっている」。 具体的なデモでは、「春の桜テーマにして」という1文の指示に対して、エージェントが適切な壁紙の選択・ピンク系アクセントカラーへの変更・Dynamic Lighting API（LampArray API）を通じたRGBキーボードのアニメーション設定までを自律的に実行した。WindowsはすでにDynamic Lightingのシステム統合を持っており、これらのAPIがエージェントから呼び出せる状態にある点が今回の重要なポイントだ。 以前もPower Automateを利用したCopilot連携でテーマ切り替えを試みた経緯があったが、そのアプローチは途中で断念された。今回はAPIエンドポイントの直接呼び出しを前提とした、より堅牢な実装となっている。 また、今回の発表にはClaude Codeを含む外部AIエージェントがWinUI 3ネイティブアプリの構築に使えるとの言及もあった。MCPサーバーとの接続やWindows APIエンドポイントの利用を、自然言語を通じて実現できるという内容だ。 実務への影響——エンジニア・IT管理者の視点から 現時点では「将来のデモ」の段階であり、一般ユーザーが即座に利用できるものではない。しかし実装が進めば、以下の場面でプラクティカルな価値が生まれる。 IT管理者向け展開の効率化: 展開後の端末に対して「社内ブランドのカラーとロゴ壁紙に統一して」といった指示で一括適用できれば、グループポリシーやIntuneスクリプトの補完手段として機能しうる。 アクセシビリティへの応用: コントラスト設定・フォントサイズ・カラースキームを一括調整するシナリオは、視覚的なニーズを持つユーザーにとって特に価値がある。個々の設定を探し回る負担を大幅に削減できる。 開発者向けアプリの可能性: WinUI skillsを組み込んだWindowsアプリであれば、ユーザーが望む環境を口頭で伝えるだけでUIが最適化される体験を実装できる。設定画面の設計コストを抑えられる点も見逃せない。 一方、エンタープライズ環境では、エージェントがシステム設定を変更できる権限管理を慎重に設計する必要がある。どのエージェントに、どの範囲のスキルを許可するか——この認可設計が今後の課題になるだろう。 筆者の見解 このデモは、Microsoftが「WindowsをAIエージェントのプラットフォームにする」という方向性を鮮明にした点で評価できる。単にCopilotをOSに貼り付けるのではなく、APIエンドポイントを整備して外部エージェントにも開放するアプローチは、理にかなっている。 ただし、正直に言えばWindowsのパーソナライズAIというテーマに、大きな期待を持てないのも事実だ。「桜テーマにして」が便利かどうか以上に、エンタープライズの現場で求められているのは設定の一括管理や展開の自動化であり、そちらへの本格的な統合をぜひ見せてほしい。 MicrosoftはWindowsのAPIエコシステムという、他社が簡単に真似できない強みを持っている。WinUI skillsはその強みを活かせる取り組みだ。派手な消費者向けデモにとどまらず、IT管理者や開発者が「これがあってよかった」と感じられるユースケースを積み重ねていくことが、長期的な信頼につながる。ポテンシャルは確かにあるのだから、あとは実装次第だ。 出典: この記事は Watch: Microsoft shows off how AI features can customize your Windows 11 entirely with one sentence の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがNVIDIA RTX Sparkチップを搭載した新型「Surface Laptop Ultra」を発表したにもかかわらず、2024年以来大々的に推進してきた「Copilot+ PC」というブランドラベルが発表イベントから完全に姿を消した。同社がこれまで発売した最も強力なAI特化型Windowsラップトップでありながら、自社のAIブランドを冠せないという、やや奇妙な状況が生まれている。 Surface Laptop Ultraとは Surface Laptop Ultraは、NVIDIAの「RTX Spark」プラットフォームを搭載し、ローカルAI演算能力として1ペタフロップを実現する製品だ。開発者ワークフロー、オンデバイスAI推論、クリエイティブ用途を主なターゲットとして位置づけており、スペック面では申し分ない。 ところが、発表イベントでMicrosoftが口にしたのは「RTX Spark」「ローカルAI」「オンデバイス推論」といったキーワードのみで、「Copilot+ PC」という言葉は一度も登場しなかった。同時に発表された「Surface RTX Spark Dev Box」にもCopilot+ PCバッジはない。意図的に外されたとしか考えられない構成だ。 Copilot+ PCブランドはなぜ傷ついたのか 2024年の華々しい幕開け 2024年5月、MicrosoftはCopilot+ PCを「これまでで最も速く、最もインテリジェントなWindows PC」として発表した。NPUで40 TOPS以上、16GB LPDDR5 RAM、256GB SSDというハードウェア要件を設定し、最初はQualcommのSnapdragon X Eliteチップ搭載機だけが対象だった。「Recall」（継続的スクリーンショットによるPCの「写真記憶」機能）、Cocreator、Auto Super Resolutionなど、Copilot+ PC専用として提供が予告された機能も話題を呼んだ。 Recallスキャンダルが与えた打撃 発表直後から、最大の目玉機能だったRecallはセキュリティ研究者から猛烈な批判を受けた。初期ビルドでは、スクリーンショットが暗号化されていないプレーンテキストファイルに保存されており、ローカルアクセス権があれば誰でもユーザーの行動履歴全体を閲覧できる状態だった。 Microsoftは急遽機能をプルバックし、オプトイン方式への変更、Windows Hello認証の追加、1年以上にわたる出荷延期を余儀なくされた。「Recall＝監視ツール」という印象がユーザーの間に植え付けられ、Copilot+ PCブランドはそのネガティブなイメージを引き摺ることになった。 ブランドの希薄化 さらに追い打ちをかけたのが、ブランドの普及による希薄化だ。AMDのRyzen AI 300シリーズ、IntelのCore Ultra 200Vが相次いでCopilot+ PCの要件を満たし、2024年末には「新品のプレミアムラップトップを買えばだいたいCopilot+ PC」という状況になった。「特別なAI PC」というポジションは消え去り、ブランドとしての差別化機能はほぼ失われた。 加えて、2025年はMicrosoftがCopilotをWindows 11、Edge、Office、メモ帳、ペイント、エクスプローラー、タスクバーと、あらゆる場所に詰め込んだ年でもあった。ユーザーの反発は強く、Copilotへの不満がCopilot+ PCブランドへのイメージにも影響した可能性は否定できない。 実務への影響 日本のエンジニア・IT調達担当者にとって、この変化は以下の点で注意が必要だ。 PC調達の判断基準を見直す: 要件定義に「Copilot+ PC」というラベルを含めている場合、その基準が実質的に形骸化していることを認識する。NPUのTOPS数、搭載VRAM、具体的なローカルAIワークロードへの適合性で評価する方が実態に即している Surface Laptop Ultraのターゲット理解: 開発者・クリエイター向けの高性能機として見るべき製品であり、一般ビジネスユーザー向けPCの後継として選定する製品ではない Recallの現状: 現在はオプトイン・Windows Hello認証必須で改修済み。「使えない機能」ではなくなっているが、企業導入前にはプライバシーポリシーと設定の確認が必須 ブランド名よりスペック: 今後も「Copilot+ PC」ロゴの有無より、NPU性能と対応ソフトウェアエコシステムで機器を評価する姿勢が重要になる 筆者の見解 Copilot+ PCブランドの扱いを見ていると、率直に言って「もったいない」という気持ちが強い。 ...

Verizon（ベライゾン）が発表した「2026 Data Breach Investigations Report（DBIR）」は、サイバー攻撃の主戦場がネットワーク層やエンドポイントからブラウザの内部へと明確に移行したことを示している。シャドーAI利用の4倍増加、認証情報窃取の急増、そして既存セキュリティ制御を100%すり抜けるブラウザ攻撃——日本のIT現場も対岸の火事では済まされない。 シャドーAIが「従業員の普通の行動」になった 2026 DBIRが示した衝撃的な数字の一つが、シャドーAI（組織が承認していないAIツールの業務利用）の急増だ。 前年比4倍増のペースで拡大し、DLP（データ損失防止）データセットにおける「悪意なきインサイダーアクション」の第3位にランクインした。 具体的な数字は以下の通りだ： 67% の従業員が、企業デバイスで個人アカウントを使ってAIサービスにアクセスしている 45% の従業員がAIツールの「日常的なユーザー」となっている AIへのプロンプト入力の50%超が個人アカウント経由で送信されている センシティブなプロンプトアップロードの**23%**が、企業のDLPポリシーやログ基盤の管轄外を経由している 従業員の多くは悪意を持ってデータを持ち出そうとしているわけではない。ただ「最速で使えるツール」として、個人ChatGPTアカウントに社内文書やソースコードを貼り付けているだけだ。しかしその行為が、企業の情報漏洩リスクを着実に積み上げている。 認証情報窃取：既存ツールが機能しない現実 2026 DBIRでは、侵害の**39%**が認証情報の悪用に関係していた。 ブラウザセキュリティ企業Keep Awareの観測データによれば、ブラウザベースの認証情報窃取は観測された脅威活動の約**41%**を占め、ブラウザ攻撃の首位に立っている。 そして最も深刻な数字がこれだ： **Microsoftをテーマにしたフィッシングサイトの63%**が、従業員がアクセスした時点でVirusTotalのいずれのベンダーにも検出されていなかった 観測された認証情報窃取の試みの**100%**が、ネットワークプロキシ・DNSフィルター・エンドポイントエージェントといった既存の非ブラウザ制御を素通りした ネットワーク層、DNS層、エンドポイント層——どの防御レイヤーも機能しなかった。攻撃を確実に検出できる唯一のポイントは、ブラウザの内部そのもの——ページがレンダリングされ、ユーザーの操作が実際に発生する場所だということだ。 ブラウザ拡張機能：高い特権、低いガバナンス 2026 DBIRはもう一つの見落とされやすい攻撃ベクターも指摘している。ブラウザ拡張機能だ。 企業環境では平均15%以上のユーザーが未承認のAI拡張機能をインストールしている。しかしAI拡張機能に限らず、拡張機能全般の問題はさらに広い。 ブラウザ拡張機能はページのコンテンツを読み取り・変更し、ブラウザのコンテキスト内からデータを外部送信することが技術的に可能だ。この高い特権レベルにもかかわらず、多くの企業でガバナンスが追いついていない現状がある。 実務への影響：日本のIT現場が今すぐ取るべきアクション 日本の企業においても、同様のリスクは確実に存在する。ChatGPTやMicrosoft Copilot、Geminiへの個人アカウントによる業務利用は、日本の職場でも急速に広がっている。 IT管理者・セキュリティ担当者へ まず実態を可視化する: 自社ネットワークでどのAIサービスが、誰の・どのアカウントで使われているかを把握することが最初の一歩。把握できていないリスクには対処できない 禁止より「公式ルートの整備」: 個人アカウント利用を禁止するだけでは効果がない。承認済みの企業アカウントを用意し、「公式ルートが一番便利」な状況を作ることが現実的な対策 ブラウザ拡張機能のインベントリ作成: 現在インストールされている拡張機能を把握し、未承認・高リスクなものをリストアップする ブラウザレベルのセキュリティ評価: 従来のネットワーク・エンドポイント対策に加え、ブラウザ内部での検出・制御が可能なソリューションの評価を検討する エンジニア・一般従業員へ 社内機密情報や顧客データを個人アカウントのAIツールに貼り付けない 使っているブラウザ拡張機能の権限を定期的に見直す フィッシングサイトはもはや見た目では判断できない。パスワードマネージャーと多要素認証（MFA）への依存度を高めることが現実的な防御になる 筆者の見解 2026 DBIRが示したデータは、セキュリティの戦場が変わったことをあらためてデータで証明した。ネットワーク層を守るだけでは不十分で、ブラウザという「見えにくい層」をカバーしなければならない——これはゼロトラストの文脈から見れば、想定の範囲内の展開ともいえる。「ネットワーク内にいるから安全」という前提が崩れた今、エンドポイントの次にブラウザが攻略対象になるのは必然だった。 シャドーAIについては、「禁止」で解決しようとするアプローチは機能しないと断言したい。45%が日常的に使っている状況で、ポリシーだけで止めようとするのは現実的ではない。承認済みの企業AIを用意して「そちらが一番便利」な状況を作ることが、本質的な対策になる。 認証情報窃取の試みの100%が既存制御を素通りしたという数字は強烈だ。ただし、これはブラウザセキュリティ製品のベンダーが提供したデータである点を頭に置いておく必要はある。それでも、ブラウザ層のガバナンスが手薄になっているという構造的な問題は、DBIRの独立したデータとも一致しており、無視できるものではない。 Non-Human Identity（NHI）の管理という観点からも、AIエージェントやサービスアカウントが業務に深く組み込まれていく中で、人間のアカウント管理と同等以上の厳密さが求められる場面が増えてくる。ブラウザを経由した情報漏洩リスクも、最終的にはアイデンティティ管理の問題に帰着する部分が大きい。 今すぐ全てのツールを入れ替える必要はないが、「今動いているから大丈夫」という判断だけは避けたい。 出典: この記事は What 2026 DBIR Confirms: Attacks Are Living in the Browser の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国の重要インフラを守るCISA（サイバーセキュリティ・インフラセキュリティ庁）、FBI、NSA、エネルギー省などの連邦機関が2026年6月、ガソリンスタンドや産業施設で使われる自動タンク計測装置（ATG: Automatic Tank Gauge）が900台超もインターネット上に無防備な状態で公開されており、現在進行形の攻撃を受けているとして共同勧告を発出した。 ATGシステムとは何か ATG（Automatic Tank Gauge）とは、地下の燃料タンクや化学物質タンクの液量・液温・漏洩を遠隔監視する電子計測装置だ。ガソリンスタンドでは在庫管理・環境規制対応・漏洩検知に不可欠なシステムで、コンビニチェーンや石油会社が広く導入している。産業施設では危険な化学物質の管理にも使われる、物理インフラの「神経系」とも言える存在だ。 発見された脆弱性と攻撃の実態 インターネット監視組織Shadowserverの調査では、2026年6月5日時点でグローバルに1,061台のATGシステムがポート10001/TCPで公開状態にあり、そのうち909台が米国内に集中していた。 確認された主な脆弱性は次のとおりだ： ハードコードされた認証情報（工場出荷時のパスワードが未変更） 認証バイパス SQLインジェクション OSコマンド実行 権限昇格 攻撃者はこれらの脆弱性を悪用してシステムに不正アクセスし、設定変更やコマンド実行攻撃を行っている。CISAの警告によれば、システムアラートを無効化された場合、燃料漏洩や機器故障のリスクが高まるだけでなく、タンクシステム自体に恒久的な損傷をもたらす可能性もある。 イラン系ハッカーによる先行侵害も確認済み 今回の共同勧告には具体的な侵害事例が背景にある。2026年5月のCNN報道では、イランのハッカー集団が複数のガソリンスタンドのATGシステムに侵入し、表示上の燃料残量の数値を改ざんしたことが判明した（実際の燃料量そのものは変更されていない）。イラン系ハッキンググループは以前から燃料管理システムや産業制御技術（ICS）を標的にしてきた前歴があり、米政府はこれらの事案との関連を精査している。 さらに同年4月には別の共同勧告で、Rockwell Automation製Allen-Bradley PLC（プログラマブルロジックコントローラ）への攻撃でイラン国家支援ハッカーが財務的損失と業務停止を引き起こしたと指摘。セキュリティ企業Censysの調査では、世界中でインターネット上に露出しているICSの74.6%が米国産という実態も明らかになっている。 推奨される対策 連邦機関は重要インフラ事業者に対し、以下を即時実施するよう求めている： ATGシステムへのインターネットからの直接アクセスを遮断する ファイアウォール・VPN・アクセス制御リストで管理されたアクセスのみに制限する デフォルトパスワードを強力な認証情報に変更する セキュリティアップデートを適用する 不正変更を検知するシステム監視を実装する 可能な範囲で多要素認証（MFA）を導入する 実務への影響 ATGシステムは日本のガソリンスタンドや化学工場にも広く導入されている。ベンダーが共通であれば同じ脆弱性を抱えている可能性があり、「対岸の火事」として見過ごすのは危険だ。 IT管理者・セキュリティ担当者がすぐ取れるアクションは明確だ： 資産台帳の棚卸し: OT（運用技術）領域の機器がインターネットに直接公開されていないか洗い出す 外部視点での自己診断: ShodanやCensysで自社のIPレンジを検索し、公開状態のATG・ICS機器がないか確認する ネットワーク分離の徹底: OTネットワークをITネットワークから完全に分離するか、厳格なマイクロセグメンテーションを実施する 筆者の見解 ATGに限らず、インターネットに露出したまま10年以上放置されているOT機器は世界中に無数に存在する。設計当時はネットワーク接続を前提としていなかった機器に、後からリモートアクセス用のポートを開けた結果がこの惨状だ。 ゼロトラストの観点から言えば、今回の勧告で推奨されている「VPNをかませばいい」は応急処置に過ぎない。本来あるべき姿は、OT機器がインターネットから絶対に到達できない位置に置かれ、アクセスが必要な場合のみJust-In-Timeでアクセス権が付与されるアーキテクチャだ。VPNは「とりあえず今すぐできること」として価値があるが、ゴールと混同してはいけない。 イラン系グループによる「表示値だけ改ざん」という手口は一見インパクトが小さく見えるが、安全上きわめて危険だ。漏洩検知システムが誤った数値を返せば、物理的な事故の検知が遅れる。「デジタルの改ざん → 物理的な被害」という連鎖は、今後のサイバー攻撃でますます重要なベクターになる。攻撃者が今回「実害なし」で止めたのは、能力の限界ではなく意図的な判断の可能性が高い。 日本のエンタープライズ環境では、ITとOTの境界が「なんとなくセグメントされている」状態が多い。今回の勧告を、自社OT環境を改めて棚卸しするいい機会として活用してほしい。 出典: この記事は Over 900 US gas station tank gauge systems exposed to attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国サイバーセキュリティ・インフラセキュリティ庁（CISA）は2026年6月5日、SolarWindsのファイル転送ソフトウェア「Serv-U」に存在する高深刻度の脆弱性（CVE-2026-28318）が攻撃者に積極的に悪用されていると警告を発した。パッチリリースからわずか数日での悪用確認という異例の速さで、早急な対応が求められている。 CVE-2026-28318とは何か Serv-UはWindowsおよびLinux向けのファイル転送ソフトウェアで、Managed File Transfer（MFT）やFTPサーバー機能を提供している。HTTP/HTTPS、FTP、FTPS、SFTPなど複数のプロトコルに対応しており、企業間の安全なファイル交換基盤として広く使われている製品だ。 今回の脆弱性は非制御なリソース消費（Uncontrolled Resource Consumption）に起因するもので、攻撃者がContent-Encoding: deflateを含む細工したPOSTリクエストを送信するだけで、Serv-Uサービスをクラッシュさせることができる。 特に危険なのは以下の点だ： 認証不要：ログイン済みアカウントを一切必要としない 低複雑度：攻撃の実行に高度な技術は要求されない ユーザー操作不要：被害者側の何らかのアクションを必要としない つまり、インターネットに露出しているServ-Uサーバーは誰でも攻撃できる状態にある。 被害規模の現状 インターネットインテリジェンスプラットフォームのShodanが追跡したところ、現時点でインターネット上に露出しているServ-Uサーバーは1万2,000台超に上る。セキュリティ監視機関のShadowserverも約3,100台を確認しており、パッチ適用済みの台数は把握できていない。 SolarWindsは2026年6月にServ-U 15.5.4 Hotfix 1をリリースして修正済みだが、すでに攻撃が確認されている以上、「まだ大丈夫」は通用しない。 即時緩和策（パッチ適用ができない場合） SolarWindsはパッチを即座に適用できない環境向けに、以下の暫定対策を推奨している： アクセス元を既知のIPアドレスのみに制限する Content-Encodingヘッダーを含むPOSTリクエストをすべてブロックする（Serv-Uはこの機能自体を必要としていない） この2点はファイアウォールやリバースプロキシのルールで実装可能なため、パッチ適用の準備中であっても今すぐ対応できる。 CISAのKEVカタログ追加と政府機関への命令 CISAはCVE-2026-28318をKnown Exploited Vulnerabilities（KEV）カタログに追加し、Binding Operational Directive（BOD）22-01に基づき、米連邦文民行政機関（FCEB）に対して2026年6月19日までのパッチ適用を義務化した。 ただしCISAはこの命令が適用される政府機関だけでなく、民間企業を含むすべてのネットワーク防御担当者に対しても早急な対応を強く求めている。「この種の脆弱性は悪意ある攻撃者の典型的な攻撃手段であり、連邦エンタープライズに重大なリスクをもたらす」とCISAは述べている。 Serv-Uは繰り返し狙われてきた Serv-Uは過去にも複数の重大な脆弱性が発見・悪用されており、SolarWinds製品全体では過去数年でCISAがKEVカタログに追加した脆弱性が11件にのぼる。 代表的な事例： 2021年：CVE-2021-35211（RCE）をClopランサムウェアグループが悪用し企業ネットワークに侵入。中国系ハッカーグループDEV-0322も同脆弱性をゼロデイとして利用 2024年6月：CVE-2024-28995（パストラバーサル）がGreyNoiseおよびRapid7によって積極的悪用と認定 この背景を踏まえると、Serv-Uは「価値ある標的」として攻撃者に認識されていることは明らかだ。 実務への影響 Serv-U利用企業がすぐ取るべきアクション： 優先度 アクション 最優先 Serv-U 15.5.4 Hotfix 1へのアップデート 即時 Content-Encodingを含むPOSTリクエストのブロック 即時 Serv-Uへのアクセスを既知IPに限定 確認 Shodan等でServ-Uがインターネット露出していないか確認 調査 ログを遡り不審なPOSTリクエストの有無を確認 Serv-Uのようなファイル転送サービスは社内外のデータ交換基盤として重要なポジションにある一方で、インターネットに直接露出させているケースも多い。「動いているから安全」という前提は危険であり、今すぐ露出状況と設定を確認することを強く勧める。 筆者の見解 Serv-Uの脆弱性が何度も繰り返し悪用されている現状を見ていると、「今動いているから大丈夫」という感覚が現場にどれだけ根付いているかがよくわかる。今回のCVE-2026-28318は認証すら不要で攻撃が成立する。つまり「うちのネットワークに侵入できるわけがない」という性善説的な前提が崩れたとき、一瞬でサービスを止められる設計になっている。 ファイル転送サービスがインターネット上に直接露出している構成自体、ゼロトラストの観点から見直しの余地がある。VPNすら不要にする方向でアーキテクチャを設計するならば、当然ファイル転送の経路も制御された接続のみにすべきだ。「外から直接Serv-Uに接続できる」状態は、そもそも設計として問題があると捉えるほうが正しい。 また、SolarWinds製品がCISAのKEVカタログに11件も掲載されているという事実は重い。特定のソフトウェアを使い続けることのリスクを、製品評価の文脈で改めて考える必要があるだろう。パッチ適用スピードと適用体制が整っているかどうか、今一度点検するいい機会だ。 出典: この記事は CISA: Hackers now exploit SolarWinds Serv-U flaw to crash servers の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは、PostgreSQL内部で長期実行・クラッシュ耐性のあるワークフローを直接定義・実行できる拡張機能「pg_durable」をオープンソースとして公開した。外部のジョブキューやワーカーサービスを別途用意することなく、SQLだけでバックグラウンドワークフローの信頼性を確保できる点が最大の特徴だ。 pg_durable とは何か 「Durable Execution（耐久実行）」とは、処理の途中でシステムがクラッシュや再起動しても、最後の成功ステップから自動的に再開できる実行モデルを指す。TemporalやAWS Step Functionsといった外部オーケストレーターがこの概念を広めてきたが、pg_durableはこれをPostgreSQL拡張機能として実装し、データベースの内側に丸ごと収めたのが革新的な点だ。 ワークフローはSQLで定義し、df.start() で起動する。実行エンジンはステップ間で自動的にチェックポイントを作成し、失敗・中断時には最後の成功ステップから処理を再開する。状態管理・リトライカウント・進捗追跡はすべて df.instances テーブルなどPostgresのテーブルに格納されるため、既存の認証モデルやバックアップの仕組みがそのまま使える。 今まで何をしていたか 多くのチームが現在取っている構成は次のようなものだ： pg_cron ＋ ジョブテーブル ＋ ステータスカラム ＋ ポーリングワーカー Airflow / Temporal / Step Functions などの外部オーケストレーターがPostgresをコールバック キュー ＋ ワーカー ＋ 状態テーブルでリトライと部分完了を管理 これらは、「クラッシュ後に途中まで完了した処理をどう扱うか」という問題に対して、アプリケーション側で複雑な状態機械を構築することで対処している。コードは複数のシステムに分散し、部分障害のバグが発生しやすい構造になっている。 主なユースケース pg_durableが特に力を発揮するシナリオは次のとおりだ： ベクター埋め込みパイプライン: テキストチャンク → 埋め込みAPI呼び出し → pgvectorへのupsert、という一連の処理を1ワークフローに データインジェストパイプライン: ステージング → 重複排除 → 変換 → 公開 の大規模バッチ処理 スケジュールドメンテナンス: 肥大化検知 → 承認待ち → 実行、のような人間の承認ステップを含むフロー ファンアウト集計: 複数クエリを並列実行して結果をJOINするパターン 外部API連携ワークフロー: エンリッチメント・分類・Webhookスタイルの呼び出しをSQLから Azure HorizonDB との連携 pg_durableはMicrosoftの新しいPostgreSQLクラウドサービス「Azure HorizonDB」に組み込み済みで、今すぐ試すことができる。「コンピュートをデータに近づける」というMicrosoftのアーキテクチャ方針の具体的な実装の一つとして位置づけられている。 実務への影響 日本のバックエンドエンジニア・インフラ担当者にとって、次のような場面での活用が考えられる： Airflowを使うほどではないが pg_cron では信頼性が足りない、という「中間の複雑さ」のジョブに最適なレイヤーになる AI/LLM活用で急増しているベクター処理パイプラインを、既存のPostgres環境に閉じた形で構築できる 外部オーケストレーターのライセンスコストやインフラ管理コストを削減できるケースがある 一方で、「任意のアプリケーションロジックをSQLステップにマップできない」「HTTP以外のSDKが必要な場合はラッパーが必要」など、現時点での制約も正直に把握しておく必要がある。すべての非同期ジョブをpg_durableに置き換えるべき、という話ではない。 ...

Microsoft が2026年6月4日にリリースした Microsoft Edge 149 において、長年提供してきた2つの主要機能「Collections（コレクション）」と「Sidebar（サイドバー）」が正式に廃止された。Copilot への機能集約を推進する Microsoft AI チームの方針によるもので、移行前にデータのバックアップを取っていなかったユーザーはコレクションのデータに一切アクセスできなくなっている。 Collectionsとは何だったのか Collections は、Microsoft Edge がChromiumベースに移行した初期から提供されていた、Web ブラウジング中に見つけた情報を整理・比較するためのワークスペース機能だ。 Microsoft は当初、ブックマーク（お気に入り）の代替として Collections を強力に推していた。単なる URL の保存にとどまらず、以下のような特徴があった： 視覚的な比較: 商品購入時に複数の候補を並べて比較 リッチコンテンツの保存: テキストだけでなく画像や価格情報なども保持 OneNote / Outlook へのエクスポート: 調査結果をそのまま Office アプリに持ち出せる メモ機能: 収集した項目に自分のコメントを追加 旅行計画やリサーチ業務での利用を想定していたこの機能は、Edge の「ただの Chromium クローンではない」という差別化の象徴でもあった。Microsoft 自身が「ブックマークフォルダは古いやり方。Collections が正しい情報整理だ」と強調して普及させてきた経緯がある。 Sidebar も同時に廃止 Collections と同様に、Sidebar（サイドバー） も Edge 149 をもって提供終了となった。 Sidebar は、Outlook・Bing などのミニアプリをブラウザ右側のパネルで利用できる機能で、メインのタブを切り替えずに別のWebサービスを操作できる点が評価されていた。フルスクリーンとの切り替えも容易で、マルチタスク環境では重宝されてきた。 なお、Sidebar の廃止によって Copilot が影響を受けるかどうかを懸念する声もあるが、Microsoft は「Copilot は引き続き利用可能。Sidebar の廃止によってむしろ Copilot の改善に集中できる」と説明している。Edge 149 では Copilot ボタンが「Chat」テキスト付きで拡張され、テキストチャットと音声チャットをボタンから直接選択できるようになっている。 アップデート前に必ずデータをバックアップ 既存の Collections データは、Edge 149 へのアップデート後は取り出せなくなる。 実際に、記事の情報源である Windows Latest がバックアップなしで Edge 149 へアップデートしたところ、Collections のアイテムに一切アクセスできなくなったことが確認されている。 ...

MicrosoftがWindows 11、Windows 10、およびWindows Server向けのISO インストールメディアに同梱されるMicrosoft Defenderの定義ファイルを新たに更新した。同社によれば、この更新はすべての新規Windowsインストール環境に展開される予定だという。 ISO インストールにおける「定義ファイルの陳腐化」問題 WindowsをISOイメージから新規インストールする際、Microsoft Defenderが参照するウイルス・マルウェアの定義ファイルは、ISOが作成された時点のものとなる。ISOイメージは一度作成されると長期間流通し続けるため、インストール直後の端末は数週間〜数ヶ月分の脅威定義が欠落した状態でネットワークに接続することになる。 Windows Updateが自動的に最新の定義ファイルをダウンロードするとはいえ、「インストール完了からUpdate適用完了まで」の数分〜数時間の間、端末はセキュリティ上の空白状態に置かれる。特にエンタープライズ環境のキッティング作業や、インターネット接続を制限された環境での展開では、このギャップが問題になりやすい。 今回のMicrosoftの対応は、この「初期インストール時のセキュリティギャップ」を公式に縮小するための施策だ。 実務への影響 IT管理者・展開担当者へのポイント ISOメディアの定期更新を習慣化する エンタープライズ環境でWindowsキッティングを行っている場合、展開用ISOイメージは古くなりがちだ。Microsoftが定期的にDefender定義ファイルを更新してISO向けに提供している以上、展開メディアも定期的にリフレッシュする運用に切り替えることを検討したい。 Windows Server環境での注意点 Windows Serverは特にISOからのクリーンインストールが多い。データセンターやクラウド基盤へのServer展開時、Defender定義ファイルが最新でない状態で一時的にでも外部通信が発生するシナリオは避けたい。今回の更新はServer ISOも対象としており、サーバー展開フローの見直しにも有効だ。 Microsoft Endpoint Configuration Manager（MECM）や Windows Autopilot との連携 大規模展開環境では、MECMやAutopilotとの組み合わせでDefender定義ファイルの配布を自動化している組織も多い。今回のISO側の更新はそうした仕組みを置き換えるものではなく、あくまで「初期状態の底上げ」として機能する。既存の自動化フローを維持しながら、ISOレベルの保護強化という恩恵を受けられる。 オフライン・エアギャップ環境での活用 インターネット接続が制限されたセキュアな環境では、Windows Updateによる定義ファイルの自動更新が期待できない場合がある。そうした環境においてISO同梱の定義ファイルが最新に近い状態であることは、特に価値が高い。 筆者の見解 セキュリティというのは「そこに穴があるうちは、それが使われる」という冷酷な世界だ。ISOインストール直後の短い空白期間を突く攻撃は現実に存在するし、エンタープライズの展開作業が増える時期——期初の新入社員向けキッティング、大規模マイグレーション——にはまとまった台数の端末が同時にリスク状態に置かれる。 Microsoftがこのポイントに手を入れたことは、地味ながらも正しい方向性だと思う。セキュリティの改善は派手なアナウンスになりにくいが、こうした「穴を塞ぐ」地道な取り組みこそが実際の被害を減らす。 Windows Defenderはかつて「おまけのセキュリティソフト」と見られていた時代があったが、いまやサードパーティ製品と比較しても引けを取らない水準まで成長した。ISOレベルでの定義ファイル管理まで手が届いているのは、プラットフォームとして一体でセキュリティを考えている証左といえる。 IT管理者の皆さんには、この機会に展開用ISOメディアのリフレッシュサイクルを見直してほしい。「去年作ったISOをずっと使い回している」という現場はまだ多い。最新の保護が最初から入った状態で展開できるよう、定期的なメディア更新を運用に組み込むことをお勧めしたい。 出典: この記事は Microsoft released new Defender update for Windows 11, 10, Server ISO installations の内容をもとに、筆者の見解を加えて独自に執筆したものです。