Windows

OpenAIが、研究機関・大学向けに特化した新サブスクリプション「ChatGPT for Science」をウェブビルド上でひそかにテストしていることが、コードリークによって明らかになった。公式アナウンスは数週間以内と見られており、科学研究の現場にAIが本格的に組み込まれる時代が近づいている。 現行プランと「ChatGPT for Science」の位置づけ 現在OpenAIはChatGPTのサブスクリプションとして、個人向け・Teams・エンタープライズの3段階を展開している。 プラン 対象 Personal 誰でも利用可 Teams 会社ドメイン＋最低3ユーザー必要 Enterprise 法人格を持つ組織が対象 新たにテストされている「ChatGPT for Science」は、認定を受けた研究機関や大学に利用資格が限定される見通しだ。通常の個人向けプランとは異なり、「誰でも購入できる」形にはならない可能性が高い。 GPT-Rosalindとの関係——すでに「研究特化AI」は動いている OpenAIがサイエンス領域に力を入れているのは今回が初めてではない。同社はすでにGPT-5.5アーキテクチャをベースとしたGPT-Rosalindを発表している。これは単なる汎用モデルにサイエンス向けプロンプトを当てたものではなく、エンタープライズ規模のライフサイエンス研究に向けて根本から設計された特化モデルだ。 GPT-Rosalindへのアクセスは「トラステッドアクセス展開」と呼ばれる厳格な管理下に置かれており、現時点ではNovo Nordiskのような大手製薬企業や公益目的の認定研究機関のみが利用可能。ChatGPT Enterpriseと同等以上のセキュリティ・ガバナンス要件が課されている。 ChatGPT for Scienceは、GPT-Rosalindのこうした機能を、ごく限られたパートナーではなくより広い研究機関に解放するための仕組みになり得ると見られている。通常サブスクリプションよりも科学的発見・研究文献に深く根ざしたグラウンディングを持つプランとして設計される見込みだ。 実務への影響——日本の研究機関・大学IT担当者が今から動くべきこと GPT-Rosalindの前例が示す通り、OpenAIは研究用途の高機能モデルへのアクセスに、エンタープライズグレードのセキュリティ体制と組織の正当性証明を要求してきた。ChatGPT for Scienceでも同様の条件が課される公算が高い。今から準備を進めた組織が半年後に差をつけることになる。 今すぐ整備しておくべき基盤 SSO・IdP連携の整備（Microsoft Entra IDやOktaとの統合） 研究データの外部送信に関する倫理審査・契約の整備（個人情報保護・研究倫理の観点からの事前確認） 利用者管理の可視化——誰が、どの研究目的で使っているかをITが把握できる状態 パイロット導入の設計——文献検索・仮説生成・論文要約など繰り返し業務への試験的組み込み AIの研究ワークフローへの組み込みは、研究者の生産性を根本から変える可能性がある。体制整備なしに「購入だけした」状態は、かえって管理リスクを増やすだけだ。研究支援部門とIT部門が連携して活用フローを設計しておくことが先決となる。 筆者の見解 「研究専用AI」という切り口は、サブスクリプション追加以上の意味を持つ。科学研究の再現性・信頼性が社会的に問われている中、AIが研究プロセスのどこに介在するかは、倫理的にもガバナンス的にも慎重に設計される必要がある。OpenAIがGPT-Rosalindで採用した「トラステッドアクセス」の考え方——要するに誰でも使えるにはしない——は筋が通っている。 そのうえで気になるのは、日本の大学・研究機関が実際にこのプランを使いこなせる体制にあるかどうかだ。契約・倫理審査・データガバナンスのいずれも追いついていない組織は、「使えるはずなのに使えない」状況に陥りやすい。研究現場でAIが本格活用される局面は確実に来る。今から動き始めた組織がその波に乗れる。アナウンスを待ってから動くのでは遅い。 出典: この記事は Leak confirms OpenAI is testing a ChatGPT for Science subscription の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11向け「新Outlook」のオフライン状態でのファイル添付機能を2026年4月より全ユーザーへ展開した。2025年10月からのテスト期間を経てのリリースだが、なぜこれほど時間がかかったのか——その答えは新Outlookの根本的なアーキテクチャにある。 新Outlookの正体：Edgeブラウザを内包したウェブアプリ 新OutlookはWindowsネイティブアプリではない。実体はWebView2コンテナ内でOutlook.comを表示するウェブアプリだ。タスクマネージャーで確認すると、OutlookのプロセスにはEdgeブラウザを支えるService WorkerやWebGPUと同じコンポーネントが並んでいる。 平たく言えば「Edgeタブの中でOutlookを開いている」状態に近い。 この設計自体が技術的に誤りとは言い切れない。Progressive Web App（PWA）の仕組みを活用すれば相応のオフライン機能も実装できるし、クロスプラットフォーム展開やウェブ技術の継続的な進化を取り込みやすい利点もある。 問題は、Outlookがカジュアルなウェブメールではなくエンタープライズ向けの高度なクライアントだという点だ。 オフライン対応の現状と仕組み 2025年にメール閲覧とカレンダーのオフライン閲覧が実装され、今回ようやくオフラインでのファイル添付が加わった。 技術的な仕組みはこうだ。WebView2アプリはローカルディスク上のUser Data Folder（UDF）にキャッシュデータを保存する。オフライン時に作成したメールや添付ファイルはLocalStorageデータベースに一時保存され、ネットワーク復帰後に自動送信される。 注意点として、新OutlookはOutlook ClassicやMail & Calendarアプリよりも多くのディスクスペースを消費する。オフライン機能を積極的に活用するほどローカルストレージへの負荷が増加する点を把握しておきたい。 オフライン添付機能を有効にするには、Outlookの設定で「全般」→「オフライン」→「ファイル添付を含める」をオンにする。 今後の改善ロードマップ オフラインメールの保存期間は現在180日間が上限だが、1年または2年への拡張が予定されており、「Settings > General > Offline > Days of email to save」から設定できるようになる見込みだ。 その他にも複数の機能強化が予告されている。 全アカウント統合受信トレイ（複数メールアカウントのメールを1画面で確認） メールのマージ機能（スレッドを束ねて整理） 機能ロードマップは着実に前進しているが、Outlook Classicと比較したとき、起動速度（新Outlookはメール表示まで10秒以上かかる場合がある）や操作性の差は依然として大きい。 実務への影響 移行判断は慎重に 現時点でOutlook Classicからの強制移行タイムラインはMicrosoftから明示されていないが、企業環境では事前検証と社内展開計画の策定を早めに進めておくことを推奨する。 特に以下のユーザー層は新Outlookとの相性を入念に確認したい。 頻繁にオフラインで作業する出張族・現場担当者 大容量添付ファイルを日常的に扱う業種（設計・映像・製造等） COM/VBAアドインに依存したカスタマイズ済みOutlook環境（新Outlookではサポート外） ストレージ管理を事前に 新OutlookがオフラインデータのキャッシュとしてUDFを活用する点は把握しておきたい。オフライン保存期間を延ばす設定を有効にする場合は、対象端末のディスク空き容量を事前に確認することを強くお勧めする。端末管理ポリシーでローカルストレージに上限を設けている環境では、UDFの保存先パスも意識する必要が出てくる。 筆者の見解 新OutlookがWebView2でウェブアプリをラップする方向性を選んだ背景には、クロスプラットフォーム対応、継続的なウェブ技術との同期、開発リソースの効率化という意図が読める。中長期の戦略として理屈は通る。 ただ、Outlookは何百万もの企業ユーザーが毎日の仕事を委ねているツールだ。オフライン状態でファイルを添付する機能——それはOutlookの旧バージョンから当然のように提供されてきた機能であり、それが2026年になってようやく「全ユーザーに展開」されるという事実は、エンタープライズ製品として率直に「もったいない」と思う。 Microsoftには、統合プラットフォームとしてのエコシステム全体を活かして最終的な完成形に辿り着く技術力と資産がある。今後予告されている機能追加のロードマップを見れば、方向性は間違っていない。新Outlookが「使えるツール」として評価される日が来ることを期待しつつ、当面のエンタープライズ展開判断はClassicの動向を横目に見ながら慎重に進めるのが賢明だろう。 出典: この記事は Microsoft still can’t make Windows 11’s New Outlook work offline because it refuses to go native の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Windows Defenderのゼロデイ脆弱性「RoguePlanet」（CVE-2026-50656）に対するパッチを現在開発中であることを公式に認め、セキュリティアドバイザリを公開した。完全パッチ適用済みのWindows 10・11でも悪用可能であり、パッチ提供時期は未定のまま攻撃リスクがさらされている。 RoguePlanetとはどんな脆弱性か RoguePlanetはMicrosoft Malware Protection Engine——Defenderのコアエンジン——に存在するレースコンディション（競合状態）の脆弱性だ。攻撃者がこれを悪用すると、SYSTEM権限でコマンドプロンプトを起動できてしまう、いわゆる「特権昇格（EoP）」の脆弱性である。OSの最上位権限を乗っ取られることを意味し、その先の攻撃展開は無制限に広がる。 この脆弱性を発見・公開したのは「Nightmare Eclipse」と名乗るセキュリティ研究者。2026年6月のPatch Tuesday当日に、PoC（概念実証コード）を自前のGitリポジトリで公開した。GitHubやGitLabは以前MicrosoftからのリクエストでリポジトリをBanされたとして、自ホスティングに切り替えている。 レースコンディション脆弱性ゆえの「不規則性」 レースコンディション系の脆弱性は確率的な挙動をとる。Nightmare Eclipse本人も「一部のマシンでは100%成功したが、別のマシンでは不安定だった」と述べており、環境依存性が高い。 ただし特に注目すべきは、リアルタイム保護が有効でも無効でも機能するという点だ。「Defenderを有効にしているから安全」という思い込みは今回には通じない。セキュリティ製品そのものが攻撃ベクターになるという皮肉な状況であり、管理者はDefenderの状態だけで安全を判断しないよう気をつけたい。 MicrosoftはCVE-2026-50656として正式にIDを割り当て、「高品質なセキュリティアップデートを提供するために取り組んでいる」とアドバイザリで述べているが、リリース時期の明言はない。 研究者とMicrosoftの長期的な対立 RoguePlanetは孤立した事例ではない。Nightmare Eclipseはここ数ヶ月で、BlueHammer・RedSun・GreenPlasma・MiniPlasma・YellowKey・UnDefendと、WindowsコンポーネントやDefender・BitLocker関連のゼロデイを次々と公開してきた。その背後にあるのは、Microsoftのバグバウンティ制度と脆弱性開示プロセスへの強い不満だ。 Microsoftはこれに対し「顧客に実害をもたらす悪意ある活動」への法的措置も辞さないと警告。セキュリティ研究者コミュニティの間では、この表現が研究者個人への脅しと受け取られ、批判を集めた。 なお、GreenPlasma・MiniPlasma・YellowKeyの3件は6月のPatch Tuesdayで修正済み。RoguePlanetはその後に開示されており、修正が未適用のまま残っている状況だ。 日本のIT管理者が今できること パッチが存在しない以上、完全な防御は不可能だが、攻撃の連鎖を断ち切るための対策は存在する。 Defenderの定義・エンジンを最新状態に維持する: 本脆弱性のパッチではないが、エンジン更新に関連する変更が含まれる可能性がある 最小権限の原則を徹底する: SYSTEM権限が奪われた後の横展開を防ぐため、アカウント分離・ネットワーク分離を強化する EDR/SIEMの検知ルールを見直す: 不審なSYSTEMプロセス生成やコマンドプロンプトの異常起動を検知できるルールが入っているか確認する パッチリリース即展開の体制を整備する: Defenderは自動更新が基本だが、組織ポリシーで遅延設定している場合は展開プロセスを前倒しで見直しておく 特に大規模環境では「パッチが出てから考える」では遅い。今のうちにDefender関連パッチの緊急展開フローを確認しておきたい。 筆者の見解 技術的に見て、Defenderのコアエンジンにレースコンディションが存在したという事実は興味深い。セキュリティ製品は高度に複雑なソフトウェアであり、こういった脆弱性がゼロになることは現実的にはありえない——そのこと自体は理解できる。 ただ、Nightmare Eclipseが次々とゼロデイを公開し続けるという異例の展開は、Microsoftのバグバウンティ制度の設計に根本的な問題があることを示唆している。研究者を「顧客への脅威」として法的に牽制するよりも、正当な報告に対して適切な評価と報奨を行う仕組みを整える方が、長期的には顧客保護につながるはずだ。Microsoftにはその実力があるからこそ、もったいないと感じる。 Defenderは世界中の何億台ものWindowsデバイスを守る要だ。その信頼性を高めるためにも、セキュリティ研究者コミュニティを敵に回すのではなく、協調関係を築く方向に舵を切ってほしい。今からでも遅くはないと思っている。 出典: この記事は Microsoft working on Defender patch for RoguePlanet zero-day の内容をもとに、筆者の見解を加えて独自に執筆したものです。

セキュリティ企業Aikido Securityは2026年6月、JetBrainsマーケットプレイスに公開されていた15本の悪意あるIDEプラグインを発見した。これらのプラグインはOpenAI、DeepSeek、SiliconFlowなどのAI APIキーをユーザーの設定から密かに窃取する仕組みを持ち、累計約70,000回インストールされていた。 何が起きたのか Aikido Securityの調査によると、今回発見された15本のプラグインは7つのベンダーアカウントから公開されており、AIコーディングアシスタント、コードレビューツール、Gitユーティリティなど、開発者が日常的に使うカテゴリを装っていた。 プラグイン自体は「宣伝通りに動作する」ため、ユーザーが不審に思うきっかけが少ない。窃取が発生するタイミングは、ユーザーがプラグイン設定画面にAPIキーを入力して「Apply」ボタンをクリックした瞬間だ。その際、APIキーがHTTP経由でハードコードされたIPアドレス（39.107.60.51）に送信される。 最初のプラグインが公開されたのは2025年10月。2026年6月10日時点でも新しいプラグインが追加されており、8ヶ月以上にわたって継続的に活動していた。 「無料で使えるAPI」という罠 このキャンペーンには単なるAPIキー窃取以上の仕組みが潜んでいる。 プラグインには有料プランが組み込まれており、ユーザーが少額の寄付（ドネーション）を支払うと、サーバー側からAPIキーが「提供」される仕組みだ。Aikido Securityはこの点について、「無料ユーザーから収集したAPIキーを有料ユーザーに再配布している可能性がある」と指摘している。 正規のAIサービス運営者が、制限なしで動くAPIキーを外部に配布する理由はまったく存在しない。この「おかしな気前の良さ」こそが、攻撃者が他人のクレデンシャルを横流ししているという証左だ。 対象となった主要プラグイン 最もダウンロード数が多かったのは以下の2本だ： DeepSeek AI Assist（プラグインID: ord.cp.code.ai.kit）— 27,727回 CodeGPT AI Assistant（com.my.code.tools）— 25,571回 その他、DeepSeek系ツールやAI FindBugs、AI Git Commitorなど計15本が確認された。BleepingComputerによる独自検証では、本記事執筆時点においても一部プラグインがJetBrainsマーケットプレイスから削除されていないことが確認されている。 実務への影響——今すぐやること 被害確認の手順 JetBrainsのIDEを使用している開発者は以下を確認してほしい。 インストール済みプラグインの棚卸し: 上記15本のプラグインIDと照合する APIキーの即時無効化と再発行: 該当プラグインを使用していた場合、OpenAI・DeepSeek・SiliconFlowの管理コンソールでAPIキーを直ちに無効化する 使用量の監査: 窃取されたAPIキーが不正利用されていないか、過去の利用ログを確認する 組織レベルの対策 チームでAPIキーを管理している場合、以下も検討すべきだ： 開発者が個人でAPIキーをIDEプラグインに直接入力する運用を見直す APIキーにはレートリミットや用途スコープの制限を設定する 可能であればサーバーサイドのAPIプロキシを経由させ、開発者マシンにフルキーを渡さない構成にする プラグインの信頼性評価 今後の予防策として、JetBrainsマーケットプレイスでプラグインをインストールする前に： ベンダーの公式サイト・GitHubが存在するか確認する 公開から日が浅い（数週間〜数ヶ月以内）プラグインは慎重に扱う ソースコードが公開されていないプラグインへのAPIキー入力を避ける 筆者の見解 セキュリティの話題はあまり得意ではないが、今回の件は技術的に興味深いポイントがいくつかある。 まず、このキャンペーンが「ちゃんと動くプラグイン」として実装されていた点だ。機能しないマルウェアはすぐ排除されるが、機能しながら裏で動く脅威は検出が難しい。開発者が「使えるツール」と認識している時点で、疑いのトリガーが発動しない。 もう一つは、AIサービスのAPIキーが「換金性の高いクレデンシャル」として明確に狙われるようになったという現実だ。OpenAIやDeepSeekのAPIキーは即座にコストに換算できるアセットであり、この種の攻撃は今後も増加していくとみるべきだろう。 Non-Human Identity（NHI）の管理という観点からも、APIキーは「機械のIDカード」に相当するアセットだ。その管理をプラグインベンダーの善意に委ねる設計は、そもそも構造として脆弱と言える。「APIキーは環境変数や秘密管理サービスで管理する」という原則が、IDEのプラグイン設定にも同様に適用されるべき時代になっている。組織のセキュリティポリシーに「AIサービスAPIキーの管理ルール」が含まれていない企業は、今回の件を契機に整備を検討してほしい。 JetBrains側の対応の遅さも気になる。BleepingComputerの取材に対して回答がなかったという事実は、マーケットプレイスの審査・監視体制に課題があることを示唆している。npmやPyPIと同様に、IDEプラグインマーケットプレイスも悪意あるコードの配布経路になりうることが、今回で改めて証明された。プラットフォームを提供する側の責任として、審査の強化と迅速な対応を期待したい。 出典: この記事は Malicious JetBrains Marketplace plugins steal AI API keys from developers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

リード ESETのリサーチャーが、中国系APTグループ「Earth Lusca」（別名：FishMonger、Aquatic Panda）によるWindows向けバックドア「SprySOCKS」の新変種を発見した。2023〜2024年にかけて、台湾・タイ・パキスタン・ホンジュラスの政府機関を対象とした標的型攻撃に使われていたことが確認されている。 Earth Luscaとはどんる脅威グループか Earth Luscaは中国との関与が高い信頼度で疑われる国家支援型の脅威アクターで、外交・テクノロジー・通信分野の政府機関を長年にわたり標的にしてきた。これまでSprySOCKSのLinux版が同グループによって展開されてきたことはセキュリティコミュニティに広く知られていたが、今回のESETの調査によって、Windowsエコシステムにも攻撃の矛先を広げていたことが明らかになった。 同グループは「Red Dev 10」「TAG-22」などの別名でも追跡されており、複数のセキュリティベンダーが観測を続けている。 2つのWindows変種：WIN_DRV と WIN_PLUS 今回発見されたWindows版SprySOCKSには、用途が異なる2つの変種が存在する。 WIN_DRV：カーネルレベルのステルス機能搭載 より高度なのがWIN_DRVだ。「RawWNPF」という名のカーネルドライバーをメモリに直接ロードする機能を持ち、これにより次のような「見えなくなる」能力を獲得する： プロセスの隠蔽：Windows API操作によりタスクマネージャー等から姿を消す ネットワーク接続の隠蔽：不審な通信を外部から見えなくする ファイルの隠蔽：ディレクトリ一覧に表示されない レジストリエントリの隠蔽：永続化用のキーを隠す さらに巧妙なのが通信手法だ。受信TCPトラフィックを検査し、特定の細工されたパケットだけをSprySOCKSバックドアにリダイレクトする。これによってバックドアが実際にリッスンしているポートをネットワークトラフィック上に露出させることなくC2通信が可能になる。 ドライバーのロードには「DriverLoader（fsdiskbit.sys）」が使われており、GitHubの「PastDSE」プロジェクトから流出した証明書で署名されている。いわゆるBring Your Own Vulnerable Driver（BYOVD）の応用だ。 WIN_PLUS：シンプルだが機能的なバックドア WIN_PLUSはWIN_DRVよりシンプルな構造ながら、実用的な機能を備えたバックドアだ。Windows Print Processor（VSPMsg）として自身を登録することで持続性を確保する。 両変種に共通する主な機能は以下のとおり： TCP・UDP・WebSocketでの通信 30種類以上のC2コマンドのサポート システム情報の収集、プロセス・サービスの管理 ファイルの列挙・作成・削除・アップロード・ダウンロード・実行 SOCKSプロキシ機能（クライアント・サーバー双方として動作可能） キーストローク・クリップボード内容・アクティブウィンドウタイトルのログ記録 UEFIブートキットの可能性も ESETのテレメトリデータには、CVE-2023-24932（Secure Bootの脆弱性）を悪用するUEFIブートキットコンポーネントの痕跡も確認されたという。この脆弱性はかつて「BlackLotus」UEFIマルウェアがゼロデイとして利用したことで知られている。 現時点でBlackLotusとの直接的な関連を示す強固な証拠はないとESETは慎重に述べているが、Secure Bootレイヤーまで攻撃が及ぶ可能性は見逃せない。 偶然の一致かもしれないが、このレポートが公開されたのは、2026年6月24日に旧来のSecure Boot証明書が失効するタイミングと重なっている。 実務への影響：日本のエンジニア・IT管理者へ 今回の報告が示す脅威は、日本の政府機関・重要インフラ事業者にとっても無縁ではない。以下の対策を実務として検討してほしい。 1. カーネルドライバーの監視強化 脆弱な証明書を使ったドライバーのロードを検出するため、Microsoft Defender for Endpoint（MDE）の「Attack Surface Reduction（ASR）」ルールを有効化し、WDAC（Windows Defender Application Control）でドライバー署名ポリシーを厳格化する。 2. Windows Print Spoolerの権限制限 WIN_PLUSはPrint Processorとして偽装して永続化する。印刷機能が不要なサーバー・端末ではSpoolerサービスを無効化する（これはPrintNightmare以来の定番対策でもある）。 3. スケジュールタスクとIFEOの定期監査 WIN_DRVはスケジュールタスクとImage File Execution Options（IFEO）を利用して永続化する。定期的にこれらのエントリを棚卸しする自動化スクリプトを仕込んでおくと早期検出につながる。 ...

米国司法省（DOJ）は2026年6月13日、非同意AI生成ヌード画像を公開していたウェブサイト「CFAKE.com」および「SOCFAKE.com」のドメインを差し押さえたと発表した。2025年5月に成立したTAKE IT DOWN法に基づく初の公式ドメイン差し押さえ事例とみられる。 CFAKE・SOCFAKEとは何だったのか これらのサイトは、政治家・女優・アスリート・ジャーナリスト・王族など複数国の著名女性を被写体にした、AI生成の性的ディープフェイク画像・動画を大量に公開していた。DOJの声明によると、対象には複数国のファーストレディや王族も含まれていた。 ディープフェイクとは、既存の写真・動画・音声から本人が実際には行っていない行動や発言を「したかのように」見せるAI生成メディアの総称だ。近年は生成AIの精度向上に伴い、非同意ポルノ（NCII: Non-Consensual Intimate Imagery）の生成ツールとして悪用されるケースが急増している。 国際連携捜査の全容 今回の捜査はイタリア郵便・サイバーセキュリティ警察が米当局に情報提供したことで始まった。イタリアは2025年10月に被害申告を受理し、国内でのアクセス遮断命令を取得しながら捜査を継続。その後、証拠が米国経由でフランスに共有され、フランス検察が独自に捜査を展開。2026年6月10日にはフランス・ニースで容疑者が逮捕され、関連する暗号資産も押収された。 ドメイン差し押さえには米国土安全保障省捜査局（HSI）ニュージャージー支局、DOJコンピュータ犯罪・知的財産部門、フランス国家警察、パリ検察局、イタリア郵便・サイバーセキュリティ警察が参加した。まさに多国間連携の成果だ。 TAKE IT DOWN法とは 2025年5月にトランプ大統領が署名したTAKE IT DOWN法（47 U.S.C. § 223）は、本人の同意を得ない性的画像・ディープフェイクの公開を連邦犯罪として定めた法律だ。特に注目すべき条項が、48時間以内の削除義務だ。被害者からの申告を受けたオンラインプラットフォームは、48時間以内に当該コンテンツを削除しなければならない。 超党派で支持されたこの法律は、メラニア・トランプ大統領夫人が「Be Best」活動の一環として推進したことでも知られる。 違反者には罰金または禁固刑、もしくはその両方が科せられる。 実務への影響——日本のエンジニア・IT管理者にとっての意味 プラットフォーム事業者は対岸の火事ではない。日本でもユーザー投稿型コンテンツを扱うサービスは多い。TAKE IT DOWN法は米国法だが、サービスが米国ユーザーを対象とする場合、あるいは将来的に日本でも類似法制が整備された場合、同等の削除対応義務が生じうる。48時間以内の削除を確実に実現するインシデント対応フローと通報受付窓口の整備は、今から取り組んでおく価値がある。 AI生成コンテンツのリスク管理は技術的課題だ。生成AI機能をサービスに組み込む際は、悪意ある利用（NCII生成・なりすまし・フィッシング）を想定した入力バリデーションとコンテンツフィルタリングが不可欠になっている。「使えないようにする」禁止アプローチではなく、正規用途を便利にしながら悪用の検出・遮断を組み込む設計が求められる。 暗号資産の押収は収益化阻止の観点から重要。今回フランス当局が運営者の暗号資産を押収した点は見落とせない。違法コンテンツビジネスの収益モデルを断つアプローチが国際的に定着しつつある。 筆者の見解 セキュリティ系の話題は正直好みではないが、今回の摘発は純粋に技術・法制度・国際連携の三つが噛み合った好例として評価したい。 注目したいのは48時間削除義務という設計思想だ。「禁止する」のではなく「通報されたら48時間以内に対応しなければ違法」という仕組みにすることで、プラットフォームに構造的な責任を負わせている。これは「禁止より仕組みを作れ」という考え方に近く、実効性の高いアプローチだと思う。 一方で課題もある。有名人を対象にした大規模サイトは摘発しやすいが、一般人を標的にした小規模なケースや分散型プラットフォームへの対応はまだ十分ではない。法整備と技術的な検出手段が追いつくまでの間、被害は続く。 日本では現時点でTAKE IT DOWN法に直接相当する法律はないが、プロバイダ責任制限法の改正議論が続いており、類似の方向性が検討されている。日本のIT事業者も「法律が通ってから考える」ではなく、今のうちに対応フローを整えておくのが現実的な判断だろう。 国際連携捜査の精度が上がり、暗号資産追跡技術が成熟してきた今、「どこかのサーバーに置けば大丈夫」という時代は終わりつつある。それ自体は良い変化だ。 出典: この記事は DOJ seizes CFAKE, SOCFAKE deepfake nude sites under TAKE IT DOWN Act の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月のPatch Tuesday更新プログラム（KB5094126）において、Secure Boot 2023証明書の配布対象を大幅に拡大し、これまでの段階的ロールアウトから一気に大多数の家庭向けWindows 11・Windows 10 PCへの自動適用フェーズへと移行した。2011年発行の旧証明書は2026年6月24日を皮切りに順次失効を迎えるため、IT管理者にとっては対応の残り時間が急速に縮まっている。 Secure Bootとは何か、なぜ今更新が必要なのか Secure BootはPC起動時にUEFIファームウェアがOS・ブートローダーの電子署名を検証し、改ざんや不正なコードの実行を防ぐ仕組みだ。ルートキットやブートキットといった、OSが起動してから動くセキュリティソフトでは検出困難なマルウェアをブートプロセスの段階で遮断できる。Windows 11のシステム要件として必須化されており、すべての対応PCでデフォルト有効になっている。 この信頼の根幹を支える証明書（KEK：Key Enrollment Key）が2011年発行のものを使い続けていた。証明書には有効期限があり、2026年6月24日から10月にかけて旧証明書が段階的に失効する。その前に後継の「Secure Boot 2023」証明書へ切り替えなければ、将来的なセキュリティ更新がブートレベルで受け取れなくなるリスクがある。 Microsoftは2年近くかけてファームウェア互換性データを収集し、問題が起きないと確認できたPCから順に配布を進めてきた。今回の6月更新でMicrosoftが診断データを持つ大多数の家庭向けPCが「高信頼カテゴリ」に分類され、自動適用対象となった。 一般ユーザーがやること——Windows Securityアプリで状態確認 大多数の一般ユーザーは何も手動でやる必要はない。Windows Updateが有効になっていれば、バックグラウンドで証明書が更新される。ただし、自分のPCが更新済みかどうかの確認は推奨する。 2026年4月更新以降のWindows 11では、Windows Securityアプリ内でSecure Boot証明書のステータスを直接確認できる。 「Windowsセキュリティ」を開く 「デバイスのセキュリティ」→「セキュア ブート」セクションを確認 表示されるアイコンの意味は以下のとおり： アイコン 意味 対応 🟢 緑のチェックマーク 更新済み 対応不要 🟡 黄色の警告 適用待ち（互換性データ収集中） Windows Updateを有効にして待つ 🔴 赤のアラート ファームウェア非互換 PC製造元のBIOS/UEFIアップデートを適用 黄色の場合、焦る必要はない。Microsoftがその機種のファームウェア互換性を確認でき次第、自動的に適用される。 赤の場合は深刻度が上がる。HP・Dell・Lenovo・ASUSなどPC製造元のサポートページで対象機種のBIOSアップデートを確認し、ファームウェアを更新した後、Windows Updateを再実行すれば証明書の適用が試みられる。 IT管理者・企業フリートへの影響 企業環境では話が変わってくる。 KEK失効のタイムラインは容赦ない。6月24日が最初の失効日であり、その後10月にかけて追加の失効が続く。対応が遅れたデバイスは将来のセキュリティパッチの適用でエラーが出る可能性がある。 フリート管理の観点では以下を確認したい： Windows Updateを一時停止・ブロックしている端末が対象外になっていないか。グループポリシーやWSUSで更新を制御している環境では、KB5094126の配布状況を意図的に確認する必要がある 古いBIOSのまま放置されているPCが赤アイコンになっていないか。特に5年以上前の法人向けPCは要注意。MicrosoftのIntune・Endpoint Analyticsを活用すれば、フリート全体のSecure Bootステータスを一覧で把握できる BitLockerとの組み合わせでUEFIアップデート後に回復キーが要求されるケースがある。事前に回復キーのバックアップを確認しておくこと BIOS更新を伴う対応が必要な機種は、アップデート前にADまたはAzure AD上で回復キーを確認・エクスポートしておくのが安全策だ。 実務での活用ポイント 今すぐやること: 管理下の主要PCでWindows Securityアプリを開き、Secure Bootのアイコン色を確認する IT管理者向け: Intuneのデバイス準拠ポリシーにSecure Bootチェックを追加し、赤アイコン端末を自動検知するレポートを設定する BIOSアップデート前の必須確認: BitLocker回復キーのAD/Entra ID保存を確認。更新後の回復画面でパニックにならないための予防措置 Windows UpdateをWSUSで管理している環境: KB5094126を承認・配布済みか確認する。非承認のまま放置するとこの更新が届かない 筆者の見解 Secure Boot証明書の更新は、地味だが正しい方向の取り組みだと思っている。2011年発行の証明書を使い続けること自体が時限爆弾だったわけで、段階的に互換性を検証しながら配布してきたMicrosoftの慎重さは評価できる。派手さはないが、こういう地道なセキュリティ基盤の整備こそWindows の信頼性を支えている。 ...

Linuxカーネル開発チームが安定版「Linux 7.1」を正式リリースした。本バージョンでは、NTFSドライバーの完全な書き直し、次世代IntelおよびAMDプロセッサー向けの大規模パフォーマンス最適化、そして重要なハードウェアバグ修正が一括して取り込まれている。 NTFSドライバー全面刷新：Windows連携が本格強化 最大の注目点はNTFSドライバーの完全再設計だ。NTFSはWindowsが標準採用するファイルシステムであり、Linuxからの利用シーンは以下のように幅広い。 デュアルブート環境: WindowsとLinuxを切り替えながら同じパーティション上のファイルにアクセスするユーザーにとって、安定性向上は直接的な恩恵になる 企業のデータ移行: WindowsファイルサーバーからLinuxへの移行プロジェクトで、NTFSボリュームの読み書きが従来より確実になる WSL（Windows Subsystem for Linux）連携: WSLはWindowsのNTFS上でLinuxが動作する独特なアーキテクチャを持つため、カーネルレベルのNTFS改善がWindows開発者環境にも間接的に波及する可能性がある 従来の実装は長年にわたり改善が重ねられてきたが、Windowsの最新機能への追従で後手に回る局面もあった。7.1で採用された新ドライバーはより近代的なアーキテクチャで構築されており、安定性・パフォーマンス・互換性の三拍子が揃った設計になっているとされる。 次世代Intel・AMD向けパフォーマンス最適化 Linux 7.1では次世代IntelおよびAMDプロセッサーへの最適化が大規模に実装された。新しいCPU命令セットへの対応拡張、メモリ帯域幅の効率化、電力管理アルゴリズムの改善などが含まれる。 サーバー・データセンター環境では、カーネルレベルの最適化が実ワークロードのパフォーマンスに直結する。Azure・AWS・Google Cloud上でLinux VMを運用している企業にとっては、カーネルアップグレードによる性能向上がそのままクラウドコスト削減につながる可能性を持つ。 現時点では「次世代チップ向け」の最適化であるため、恩恵を得られるのは新しいハードウェアを持つ環境に限られるが、それらのチップが普及し始めたタイミングにカーネルの準備が整っているという意味で、先行投資的な価値がある。 重要なハードウェアバグ修正も同梱 「vital hardware bug fixes」と表現されている修正群も本リリースに含まれる。具体的な詳細は個別のパッチノートを確認する必要があるが、ハードウェアレベルの安定性修正は実運用環境において見逃せない変更だ。特に特定のハードウェア構成で問題が報告されていた場合、このリリースで解決される可能性がある。 実務への影響 インフラ・クラウド担当者へのポイント： クラウドインスタンスのカーネル更新タイミングを把握する: Ubuntu・RHEL・Debianなど各ディストリビューションへの7.1系の取り込みスケジュールを確認し、社内標準イメージの更新計画を立てておく NTFSアクセスが絡む作業の再評価: WindowsファイルサーバーからLinuxへのデータ移行作業や、デュアルブート環境での運用を行っているチームは、7.1以降のドライバー挙動を検証環境で早めに確認することを推奨する 新規サーバー調達の参考に: 次世代Intel・AMD向け最適化が入ったことで、新規ハードウェア選定時にLinuxカーネルとの親和性を検討する根拠が一つ増えた ディストリビューションごとにバックポートの方針やサポートポリシーが異なるため、自社が使うディストリビューションのリリースノートを追うのが確実だ。 筆者の見解 NTFSドライバーの全面刷新は、地味に見えて実務上は大きな変化だ。WindowsとLinuxの境界がかつてより曖昧になっている現代では、ファイルシステムの互換性は開発者にとっても運用担当者にとっても日常的な摩擦源だった。その摩擦を減らす取り組みは、どちらの陣営のユーザーにとっても歓迎できる。 パフォーマンス最適化については、「今は関係ない」と思って素通りするのは早計だ。新しいIntel・AMDチップは1〜2年以内に市場に出そろい、気づけば手元のサーバーに入っているものだ。カーネルがそれに対応していなければ、ハードウェアの能力を半分も引き出せない状態が続くことになる。 日本のエンタープライズでもクラウドやオンプレ問わずLinuxを基盤とするシステムが着実に増えている。「Linuxはサーバー担当が見るもの」という時代から、アプリ開発者やクラウドアーキテクトもカーネルの変更を把握しておく時代に変わった。このリリースはその意味でも、チェックリストに入れておく価値のある更新だと思う。 出典: この記事は Linux 7.1 arrives with an NTFS overhaul and major hardware performance boosts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Claude CodeやCopilot、Cursorなどのコーディングエージェントが実務に普及するなか、ベンダーが競うように宣伝する「200万トークン対応」「1Mコンテキスト」といった数字を、そのまま信じるのは危険だ——そう警告するエンジニアの知見が、Hacker Newsで大きな反響を呼んでいる。 「スマートゾーン」と「ダムゾーン」という概念 コンテキストウィンドウを語るうえで、今や欠かせないフレームワークが「スマートゾーン（smart zone）／ダムゾーン（dumb zone）」だ。LLMはコンテキストの冒頭部分では鋭い注意力を発揮するが、ある閾値を超えると急速に精度が低下し、「5分前に指示したことを忘れたような」挙動を見せ始める。その閾値はモデルのアーキテクチャによって多少異なるが、おおむね 100kトークン付近 とされている。 重要なのは、モデルが対応する最大トークン数がいくら増えても、この閾値はほとんど動かないという点だ。Anthropicが2Mトークンの対応を謳っていても、Googleが超大容量コンテキストを発表しても、Attentionメカニズムの根本的な限界が解消されているわけではない。 研究が裏付ける「コンテキスト劣化」 これは感覚論ではなく、研究によっても裏付けられている。MicrosoftとMIT等が共同で発表した評価ベンチマーク RULER や、Chromaによる 「Context Rot（コンテキスト劣化）」レポート では、コンテキストウィンドウが埋まるにつれてモデルのパフォーマンスが段階的に劣化することが定量的に示されている。 「広告上の数値」と「実際に使えるコンテキスト量」の間には、大きなギャップがある。これはLLMを道具として使うエンジニア全員が把握しておくべき事実だ。 コーディングエージェントが直面するリスク コーディングエージェントは、使っていると想像以上のスピードでトークンを消費する。ファイルを数個読み込み、デバッグを少しやり取りして、テスト結果を貼り付ければ、あっという間に100kトークンに達する。その時点で、セッションの後半部分にある指示や文脈は事実上「捨てられている」に等しい状態になる。 Claude Codeには「オートコンパクト（auto-compact）」機能があり、セッションが長くなると自動的に履歴を要約して引き継ぐ仕組みがある。これは一定の効果があるが、要約を生成するのはすでにダムゾーンに入ったモデル自身であるという根本的な問題は残る。「何もしないよりはマシ」だが、それ以上ではない。 実務での活用ポイント：コンテキストを「予算」として扱う 元記事の著者が実践する方法は、コンテキストウィンドウを「使い切るもの」ではなく「節約すべき予算」として設計することだ。具体的には以下のアプローチが有効だ。 1. 新規セッションに仕様書を渡す 長いセッションを続けるのではなく、自分で重要情報をまとめたスペック文書（仕様書・引き継ぎメモ）を書き、それを新しいセッションの冒頭に渡す。オートコンパクトによる自動要約より、人間が「何を次のセッションに持ち越すか」を判断した手動要約のほうが信号品質が高い。 2. 小さな成果物（アーティファクト）に情報を逃がす obra/superpowersやmattpocock/skillsのようなプロジェクトは、PRD・計画書・スキル定義・サブエージェントへの引き継ぎなど、名前のついた小さな成果物にエージェントのワークフローを分割する設計思想を持つ。セッション内に情報を詰め込むのではなく、読み出せるファイルとして外に出すことで、常に「スマートゾーン」の状態で作業を継続できる。 3. ファイル読み込みを慎重に行う 「全ファイルをコンテキストに渡す」ではなく、「今のタスクに本当に必要な部分だけを読み込む」。必要最小限の情報でエージェントを動かすことがスマートゾーン維持の基本だ。 実務への影響 このフレームワークは、AIツールの選定基準を変える可能性がある。「コンテキストが大きいほど良い」という単純な評価軸から、「実効コンテキスト内でどれだけ正確に動作するか」「オーバーフロー時の設計がどうなっているか」という評価軸への転換が求められる。 日本企業でもコーディングエージェントの導入が加速しているが、長時間デバッグセッションや大規模コードベースの読み込みを前提とした使い方では、後半の指示が無視されるリスクがある。CI/CDパイプラインへの組み込みや、エージェントを使った自動化設計において、セッション設計そのものがエンジニアリングの対象になる時代だ。 筆者の見解 ベンダー各社が「コンテキストウィンドウの大きさ」を競うように発表してきた流れには、正直なところ「それは本質じゃない」と感じていた。ユーザーが必要なのは大きな数字ではなく、その範囲内で確実に動作することだ。 今後の改善に期待したいのは、ダムゾーン問題への対処だ。オートコンパクトのような機能は正しい方向性だが、あくまで応急処置に過ぎない。根本的には、アーキテクチャレベルでの解決——たとえばRAGとエージェントの統合強化や、より賢いメモリ管理機構——が求められるはずで、各社がそこに本腰を入れ始めているのは良い兆候だ。 エンジニアとしての実践的な結論は一つ：「コンテキストを使い切ろうとするな。情報はファイルに書き出せ」。これはAIエージェントの時代における、新しい設計の鉄則になりつつある。 出典: この記事は Don’t trust large context windows の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月のPatch Tuesday（KB5094126）でWindows 11に「Low Latency Profile」と呼ばれるCPUブースト機能を展開した。オンライン上で「CPUが壊れる」「発熱が増える」といった懸念が広がっているが、Windows Latestによる複数回の実機検証では、いずれの懸念も事実無根であることが確認された。 Low Latency Profileとは何か Low Latency Profileは、スタートメニュー・Windows Search・アクションセンター（クイック設定）を開く瞬間に、CPUクロックを最大ターボ周波数まで1〜3秒間瞬間的に引き上げるスケジューラーレベルの機能だ。Windows 11 24H2および25H2を対象に、6月の累積更新プログラムで全展開が始まっている。 以前から「レース・トゥ・スリープ（Race to Sleep）」という考え方がある。CPUが低クロックでダラダラ処理するよりも、高クロックで素早く処理を終えてアイドル状態に戻った方が消費電力が低い場合があるという概念だ。Low Latency Profileはまさにこの原理を活用している。 「CPUクロック」と「CPU使用率」の違いが鍵 オンライン上の誤解の多くは、「CPUクロック周波数（MHz/GHz）」と「CPU使用率（%）」を混同していることに起因する。 CPUクロック周波数: 1秒間に処理できるサイクル数。高いほど命令を速く実行できる CPU使用率: 実際にどれだけ処理負荷がかかっているかの割合 Low Latency Profileが行うのは「クロックを瞬間的に上げること」であり、「処理負荷（使用率）を上げること」ではない。検証では、スタートメニューを開くたびにCPUクロックが4GHz〜4.5GHzまで跳ね上がる一方、CPU使用率はバックグラウンドアプリによる20〜30%のまま変化しなかった。連続してスタートメニューを開いてもこの傾向は変わらなかった。 実機検証の結果 HWiNFOとタスクマネージャーを常時起動し、バッテリー残量も継続監視しながら複数セッションにわたって検証が行われた。テスト環境は、画面録画ソフト・100以上のEdgeタブ・WhatsAppなどが常駐するという高負荷な実環境に近い状態だった。 結果は以下の通り： CPUへのダメージ: 確認されず 発熱（サーマルスロットリング）: 確認されず バッテリー消耗の増大: 確認されず 体感速度の改善: スタートメニュー・検索バーの応答速度に明確な向上あり また、6月更新では2文字入力からWindows Searchが機能するようになるなど、Low Latency Profileと合わせてシェル全体の使い勝手が向上している。 実務への影響 エンジニア・IT管理者向けのポイントをまとめる。 バッテリー駆動ノートPCでも安心して適用可能：「レース・トゥ・スリープ」の原理が正しく機能している限り、発熱・電力消費の増大は起きない。モバイルワーカーの多い環境でも、この更新を敬遠する必要はない。 低スペック端末への恩恵が大きい：開発機など高スペック機では「もともと速かった」ため差が分かりにくいが、ミドルレンジ以下の業務PCや古いエンドポイントでは体感が顕著に改善する可能性がある。 Windows Update適用判断：今回のKB5094126は機能更新を含む月例更新だ。「すぐに当てたら壊れた」という事例が増えているのは事実であり、数日様子を見てから展開するのも立派な判断だ。ただし今回のLow Latency Profile自体の安全性については、複数の独立した検証で問題なしとされている。 Intune/グループポリシーでの制御：現時点でMicrosoftが個別にオフにするポリシーを提供しているかは公式ドキュメント要確認だが、KB5094126自体の除外は従来のWindows Update管理ツールで対応可能だ。 筆者の見解 Windows Latestの検証は丁寧で、HWiNFOとタスクマネージャーを組み合わせた実環境テストは信頼できる。今回の機能自体は技術的に筋が良い。CPUとOSスケジューラーの設計を知っている人間には「なぜもっと早くやらなかった」と感じる内容だ。実際、検証記事でも「なぜ何年も前にやらなかったのか」という問いが立てられている。 スタートメニューがもたつく問題はWindows 10の頃から指摘され続けてきた。ユーザーエクスペリエンスの根幹であるシェルの応答速度を、こうしたスケジューラーレベルで地道に改善していく姿勢は評価したい。派手さはないが、実際に使う人間の体験に直結する改善だ。 Microsoftには、こういう「地に足のついた改善」をもっと積み重ねてほしいと思う。大きなビジョンも重要だが、「今日のPC体験をどう良くするか」という地道な取り組みが、長期的なプラットフォームへの信頼につながる。実力は十分にあるのだから、それを証明し続けることを期待している。 出典: この記事は Tested: Windows 11’s new CPU boost doesn’t damage your CPU, drain your battery, or cause heat の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

米アイオワ州デモインにあるSaydel Community School District（セイデル統合学区）の元上級ITサポート専門家、エゼキエル・ディーン・ポッター被告（34歳）が、退職後も学区のシステムに不正アクセスし続けたとして連邦コンピュータ詐欺罪（CFAA違反）で有罪を認め、2026年6月11日に禁固21ヶ月・保護観察3年・59,668ドル（約900万円）の賠償支払いを命じる判決を受けた。 21ヶ月間にわたる「元従業員テロ」の全貌 ポッター被告は2022年5月から2023年4月まで学区に在籍していた。退職後も認証情報を返却・無効化することなく保持し続け、以下のような攻撃を繰り返した。 退職直後〜初期段階 学区のFacebookページを削除 Apple School Managerアカウントを標的に、ユーザーアカウント・パスワード・電話番号・請求情報・デバイス管理サーバーデータを一括削除 Appleとの復旧作業が完了するまでの約1週間、学区内のMacBook・iPadのMDM（モバイルデバイス管理）が機能停止 2025年1月——攻撃がエスカレート GoogleアドミンアカウントからSchoogyy（スクーロジー）学習管理システム（LMS）に侵入し、ITスタッフのアカウントを削除。約2時間にわたり教師がLMSにアクセス不能に 翌週、別のアドミンアカウントから現役・元スタッフ9名のGmailアカウントを削除。対象にはITディレクターと教育長も含まれていた Googleからセキュリティ警告が届くとVPNサービスに切り替えて証拠隠滅を図った 捜査の糸口となった「USB ドライブ」 連邦捜査官は、ポッター被告が別の職場（Casey’s Store Support CenterおよびThe Printer Inc.）で業務していた際のIPアドレスを一部の攻撃と紐付けることに成功した。 TPI退職後、ポッター被告は元同僚に「デスクのUSBドライブを回収して消去してほしい」と依頼した。しかし元同僚はそのUSBドライブを捜査機関に提出。解析の結果、Saydel学区のアカウントとサービスのユーザー名・パスワードが記録されたスプレッドシートが発見され、決定的証拠となった。 実務への影響――日本のIT管理者が今すぐ確認すべきこと この事件が示す脅威は「悪意ある外部攻撃者」ではなく「かつてアクセス権を持っていた内部関係者」だ。日本の学校・自治体・中小企業でも同様のリスクは日常的に存在する。 退職者アクセス管理の即日チェックリスト 退職当日に全クレデンシャルを無効化する手順はあるか？　アカウント無効化の責任者と実施タイミングを明文化する。「あとで対応」は致命的 Apple School Manager・Google Workspace・Microsoft 365など外部SaaSの管理者権限は棚卸しされているか？　オンプレミスのActive Directoryだけ無効化して、SaaS側に残存アクセスが生き続けるケースは非常に多い VPN・GoDaddy・学習管理システムなど「その他のサービス」にも個別アカウントが存在しないか？　サービスごとにバラバラに発行された認証情報は見落としがち 管理者アカウントの操作ログは取得・監視しているか？　本件ではGoogle側から送られたセキュリティ警告が存在したにもかかわらず、攻撃を21ヶ月間止められなかった USB等の持ち出し媒体の管理ポリシーはあるか？　証拠となったUSBドライブが手渡しで共有されていた点は、情報管理体制の課題を浮き彫りにしている ツールより先に「プロセス」を整備する 高額なSIEMやEDRを導入しても、退職者の認証情報が無効化されていなければ意味がない。技術的対策の前提として「人事・IT・法務が連携した退職フローの整備」が最優先事項だ。 筆者の見解 この事件を読んで、改めて「Just-In-Time（JIT）アクセス」の考え方の重要性を実感した。ポッター被告が21ヶ月間攻撃を継続できた根本原因は、退職後も有効なクレデンシャルが残り続けたという、アクセス管理の基本的な失敗にある。 「常時アクセス権の付与は特権アカウント管理における最大のリスク」というのはゼロトラストの基本原則だが、教育機関や中小規模の組織では「担当者が変わってもアカウントが引き継がれる」「退職フローに認証情報の無効化が含まれていない」というケースが珍しくない。 また、Googleからセキュリティ警告が届いていたにもかかわらず攻撃が継続した点は看過できない。アラートは鳴っていた。問題はそのアラートを受け取った後の対応プロセスが存在しなかったことだ。「ログは取っているが見ていない」「警告メールが誰のInboxにも入っていない」という状況は、規模を問わず多くの組織で起きている。 日本の教育機関・自治体においても、GIGAスクール構想でiPad・Chromebookが大量導入された結果、Apple School ManagerやGoogle Workspaceの管理が「ITに詳しい先生1人」に依存しているケースは少なくない。その1人が退職・異動した場合、今回と同様のリスクが生まれうる。 技術よりも先にプロセスを作る。退職者のアクセス管理という「地味だけど最重要」な業務フローを、今日の業務の中で一度見直してみてほしい。 出典: この記事は Ex-school district employee jailed for hacks on former employer の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがJune 2026 Patch Tuesdayとして2026年6月9日にリリースしたWindows 11累積更新プログラムKB5094126（Build 26200.8655）が、HP EliteBookをはじめとする複数機種で起動不能（Black Screen of Death / BitLocker回復ループ）を引き起こしていることが確認されている。とくに数百台規模でHP端末を管理している企業の担当者から「展開後ほぼ全台が起動不能になった」という深刻な報告が相次いでいる。 KB5094126の概要——200件超の脆弱性を修正する重要パッチ KB5094126は今年最大級のアップデートと位置付けられており、約200件のセキュリティ脆弱性（うち33件がCritical、5件がゼロデイ）を修正する。新機能としては待望の「Low Latency Profile」なども含まれ、重要度は極めて高い。 ただし、更新は延期設定をしていないPCにはバックグラウンドで自動インストールされる。企業環境でWUfBやWSUSの制御下に置いていない端末は自動適用されているケースがあるため、まず対象範囲の確認が必要だ。 何が起きているのか——BSoDとBitLocker回復ループ 影響を受けたPCでは以下のような症状が報告されている： 起動時にBlack Screen of Death（エラーコード：0xc0430001）が表示される BitLocker有効環境ではBitLocker回復画面に遷移し、回復キー入力後も再起動ループに陥る 起動できた場合でもイベントビューアにTPM-WMI エラーが大量記録される 代表的なメッセージ：The secure boot update failed to update Boot Manager (2023) due to the error: insufficient disk space. 技術的な根本原因：EFIパーティションの容量不足 KB5094126はSecure Boot関連のファイルや証明書、Boot ManagerおよびEFI領域に書き込みを行う。MicrosoftはこのアップデートでSecure Boot証明書の更新を多くのPCに対して有効化したと明言している。 問題が起きやすいのは、旧来の100MBサイズのEFIパーティションを持つ端末だ。現在の推奨は500MB〜1GBだが、数年前に展開されたPCイメージは100MBで作られているものが多く、そこにSecure Bootファイルを書き込む容量が足りなくなる。 とくにHPデバイスが多く影響を受けているのは、HPがEFIパーティション内にEFI\HP\DEVFWとしてBIOS/ファームウェア回復ファイルを格納しているため、パーティションがさらに圧迫されているからだ。 影響が確認されている機種（現時点）： メーカー 機種 HP EliteBook 840 G10 HP ProBook 460 G11 / HP 460 G11 HP Engage One Pro 15.6 G2 AiO POS ...

Microsoft は2026年6月12日、Windows 11 Insider Preview ビルドを Beta・Experimental・Experimental Future Platforms・Release Preview の4チャネルへ同時展開し、再起動UIの統合、受信トレイアプリへのリリースノート追加、Windows Search の刷新という三本柱の改善を届けた。これだけ広範なチャネルへの同時ロールアウトは近年でも珍しく、Microsoftが次の公開リリースに向けてテスト周期を加速させているシグナルとも読める。 再起動UIの統合——長年の「混乱の元」が解消へ 今回の目玉は、何年もユーザーを悩ませてきた再起動まわりのUI整理だ。従来のWindowsでは、更新プログラムの適用後にスタートメニューの電源ボタンへ「更新して再起動」「更新してシャットダウン」の両選択肢が並び、「どちらを押したら今すぐ再起動されるのか」が直感的にわかりにくかった。 新しい統合ダイアログはこの問題にシンプルに対応する。再起動が必要な更新がある場合、電源メニューとWindows Updateの設定画面が単一のインテリジェントなダイアログに集約される。このダイアログはユーザーの過去の行動を学習し、「業務終了時に常にシャットダウンを選ぶ」パターンがあれば、その選択肢を優先表示するように動く。また、カウントダウンタイマーと「1時間後に再起動」ワンクリックオプションも追加され、再起動スケジューリングの煩わしさが軽減された。 特に大きいのは文言の改善で、「更新を完了してからPCをシャットダウンします」という明確な説明が入るようになった点だ。Betaチャネルのテスター報告では、アクティブアワー（使用中の時間帯）の尊重もより積極的になったという。 受信トレイアプリにリリースノートが登場 もう一つの変更として、メモ帳や電卓などOSに同梱された「受信トレイアプリ」のアップデート時にリリースノートが表示されるようになった。これまでこれらのアプリは更新されても変更内容が不透明で、「いつ何が変わったのか」をユーザーが追いにくかった。地味な改善だが、IT管理者がアプリ動作変更の影響を把握しやすくなる点では意義がある。 Windows Searchのインデクサーを刷新 Windows Searchもこのビルドで大きく手が入った。インデクサーが書き直され、バックグラウンドでのディスクアクセス（スラッシング）が抑制されるとともに、コンテキストを踏まえた検索結果の精度向上が図られている。以前から「検索が遅い」「ディスクがうるさい」という不満は根強かったため、実際にどこまで改善されるか次第では歓迎されそうだ。 x86とARM両対応の同時展開 「Experimental Future Platforms」チャネルの存在も興味深い。このチャネルはSnapdragon X EliteやIntel Lunar Lakeなど次世代SoC向けの調整が進んでいると見られており、今回の再起動UI・Search改善がARMとx86の双方で同時にテストされていることを示している。Microsoftが主要なUX変更をアーキテクチャ横断で一気に固めようとしている姿勢が伝わってくる。 実務への影響 企業のIT管理者にとって最も実用的な変化は、再起動ダイアログのアクティブアワー尊重の強化だ。ユーザーが業務中に「うっかり再起動を始めてしまう」ケースが減れば、ヘルプデスクへの問い合わせも一定数減ることが期待できる。一方で、現時点はInsider Previewであることを忘れずに。本番環境のPCに適用するのは安定版での一般提供（GA）を待つのが基本だ。 Windows Updateを取り巻く環境では「すぐ当てたら壊れた」という報告も増えている。Insider情報として技術動向をウォッチしつつ、本番展開は動作実績が確認されてから判断する——この原則は変わらない。 筆者の見解 UIの小さな混乱を地道につぶしていく作業は、実は軽視できない。「更新してシャットダウン」か「更新して再起動」かを間違えることで発生するサポート問い合わせや、再起動タイミングの誤解によるデータ損失リスクは、企業規模で見ると無視できないコストだ。今回の統合は、Microsoftがユーザー体験の基礎部分をきちんと見直していることを示しており、その点は素直に評価したい。 ただし率直に言えば、Windowsの細かなUI変更を逐一追う必然性は年々薄れている。それよりも実際の業務でどう使い、どんな成果が出るかを積み重ねる時間の方が価値ある投資だ。このInsider Buildが示す「地道な改善の積み重ね」がGAに届いたとき、実務の現場でどれだけ空気が変わるか——それが本当の評価軸になる。Microsoftにはその積み重ねを着実に本番に届けることを期待したい。 出典: この記事は Windows 11 June 2026 Insider Builds Unify Restart and Upgrade Search の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11 Insider Programに「Experimental (Future Platforms)」という新チャネルを設け、ビルド29610.1000を2026年6月12日に公開した。まだ市販されていない将来のハードウェアプラットフォーム向けのWindows対応を先行試験することが主目的だ。 「Future Platforms」チャネルとは何か これまで「Canary 29600 Series Channel」と呼ばれていたチャネルが、順次「Experimental (Future Platforms)」という名称に移行する。単なるリネームではなく、Microsoftが次世代シリコン——新しいプロセッサアーキテクチャや特殊なハードウェア構成——への対応準備を、一般市場に出回る前から先行して進めていくという意思表示と見てよい。 このチャネルはビルドが不安定であることが前提であり、ドキュメントが限られた状態でリリースされることもある。含まれる機能が製品版に採用されない可能性もあり、あくまで「コンセプト試験と早期フィードバック収集」が目的だ。多くの機能はControlled Feature Rollout（CFR）技術を用いて段階的に展開される。 ビルド29610.1000の変更内容 今回のビルドで修正された内容は4点。 信頼性の改善 前ビルド適用後に一部Insiderで発生していた「KERNEL_SECURITY_CHECK_FAILURE」によるグリーンスクリーン（Windowsの重大エラー）が修正された。カーネルレベルのセキュリティチェックに関わるクラッシュだけに、安定性への影響は大きい。 ストレージ表示のパフォーマンス改善 「設定 > システム > ストレージ > 詳細ストレージ設定 > ディスクとボリューム」で大容量ボリュームの情報を参照する際の応答速度が改善された。大容量NAS接続環境や多数のパーティションを持つ開発機での操作感が向上する。 Windows Defenderの誤通知修正 最新フライト適用後にWindows Defenderが有効であるにもかかわらず「無効」と誤表示する通知が出ていた問題を修正。セキュリティ状態の誤報は管理者を不必要に混乱させるため、優先度の高い修正だ。 クイック設定の重複表示修正 クイック設定に「省エネモード」が二重表示される問題も解消された。 実務への影響 エンタープライズ環境のIT管理者にとって、このInsiderチャネル自体は直接の実務対象ではない。ただし「Future Platforms」という名称が示すように、MicrosoftがどのようなハードウェアとWindowsを共進化させようとしているかを把握する手がかりになる。 ARM系プロセッサや次世代NPU搭載デバイスへの対応強化が進む中、将来の調達計画や社内標準機種の選定に影響してくる可能性がある。Insider Programのチャネル構成が整理・再編されることで、「どのリスクを取ってどの段階の機能を試すか」という判断軸も明確になる。早期評価を行う検証担当者は、チャネル移行のタイミングを確認しておくとよい。 筆者の見解 正直なところ、今回のビルドで注目すべきは個別の修正内容よりも「Future Platforms」というチャネル名そのものだと思っている。Windowsを細かく追う意義が以前より薄れているのは事実だが、こういった舞台裏の準備は地味ながら重要だ。 次世代シリコンへの先行対応は、Microsoftがハードウェア多様化の波に着実に追いつくための取り組みだ。ARMやカスタムシリコンへの対応実績はあるし、この方向性は正しい。ただ、その先に見えてくる「ユーザー体験の革新」がまだ見えにくい——そこはもったいないと感じる部分だ。ポテンシャルはある。正面から勝負できる力を持っているからこそ、準備を形に変えていく段階が楽しみでもある。 Windows Updateの運用については以前から「慌てて当てるな、数日様子を見るのも立派な判断だ」と言ってきたが、Insiderチャネルでカーネルレベルのグリーンスクリーンが出るケースが続いているのを見ると、安定版ユーザーはなおさら焦る必要はない。安定を優先しつつ、次世代ハードウェア対応の動向は引き続き注目しておきたい。 出典: この記事は Windows 11 Insider Experimental (Future Platforms) Preview Build 29610.1000 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月のWindows 11更新から、「セキュリティパッチ適用済み（最新状態）」と「新機能が有効化済み」を公式に分離する新サービシングモデルを導入する。Controlled Feature Rollout（CFR）と呼ばれるAI駆動の段階展開メカニズムが、デバイスごとの機能有効化タイミングを制御し、IT管理者と一般ユーザーの両方にとって「最新状態」の意味が変わることになる。 Windows 11サービシングモデルの変革 これまでのWindows Updateは、シンプルな「最新の状態です」というメッセージを表示してきた。しかし6月以降は、このステータスが持つ意味が大きく変わる。 インストール済みの更新プログラムには2つの独立したステージが存在するようになる： インストールステージ: セキュリティパッチ・品質修正・機能ペイロードの適用 有効化ステージ: CFRによる機能のオンオフ切り替え つまり、デバイスが全更新プログラムをインストール済みであっても、Microsoftのクラウドベースシステムが「準備完了」の判定を下すまで、新機能は有効化されない。 Controlled Feature Rollout（CFR）とは何か CFRは今回初めて導入された仕組みではない。Microsoftは数年前からこのメカニズムを活用してきた。機械学習モデルを使って「スムーズな体験が見込まれるデバイス」を特定し、数週間〜数ヶ月かけて段階的に展開を広げていく。 変遷をたどると、Windows 10時代の「Current Branch for Business」による展開遅延から始まり、2019年の「Semi-Annual Channel」移行、そして2022年のWindows 11「Moments」（年次アップデート間の小規模機能追加）までCFRが段階的に活用されてきた。今回の変更で、すべての機能がCFRゲートの対象となる。この仕組みはMicrosoft EdgeやGoogle Chromeがリモートで機能フラグを切り替える手法と同様のアプローチだ。 企業IT管理者への影響 今回の変更は、IT管理者にとっては管理の精度が上がるポジティブな変化だ。 メリット： 機能の有効化タイミングをセキュリティパッチとは独立してコントロール可能 問題発生時のロールバックや一時停止の判断が明確化 段階展開の粒度が増し、大規模障害のリスクを低減 課題： エンドユーザーへの説明コストが増加 「最新状態なのに同僚にはある機能が自分にはない」という問い合わせが増える可能性 Windows Updateの状態表示が複雑化し、ヘルプデスクの負担増 実務での活用ポイント エンジニア・IT管理者向け： CFRが公式分離されることで、IntuneやWindows Update for Businessを使った管理ポリシーの再整備が必要になる。今から準備しておきたいポイントを挙げる。 更新リングの再設計: セキュリティパッチリングと機能展開リングを分けて管理する構成を検討する テレメトリ設定の確認: CFRの判定はデバイスのテレメトリデータに依存する。テレメトリを制限している組織では機能展開が遅延する可能性があり、設定の見直しが必要になる ユーザー向け案内の準備: 「最新状態」と「機能有効化」は別物であることをヘルプデスクチームに周知し、問い合わせ対応フローを整備する パイロット運用の設計: 少数の検証端末でセキュリティパッチのみを先行適用し、安定確認後に機能展開を広げる運用が現実的になる 筆者の見解 正直に言えば、この変更はWindowsサービシングの方向性として悪くない。 「更新を当てたら壊れた」という話はここ数年で本当に増えた。セキュリティパッチと機能展開を公式に分離することは、その懸念に正面から応えるアプローチだ。更新プログラムを躊躇なく適用できる環境づくりは、セキュリティ態勢の底上げにも直結する。 ただ、一般ユーザーにとっての混乱は避けられないだろう。「最新状態です」と表示されているのに、なぜ隣の同僚のPCには新機能があるのか——このギャップを直感的に理解できるUIの整備は、Microsoftに引き続き期待したいところだ。機能の有効化ステータスを可視化する専用の画面や、展開予定タイムラインの開示があれば、現場の混乱は大きく減らせる。 変化するサービシングモデルを「面倒が増える」と受け取るか、「管理の選択肢が増えた」と捉えるかで、組織の対応は大きく変わる。IT管理者としては、このモデルを最大限に活かす管理設計に今から備えておきたい。 出典: この記事は Windows 11 June 2026 Servicing Change: How Controlled Feature Rollout Separates ‘Up to Date’ from ‘Feature Enabled’ の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年6月、Windows 11 25H2のインストールメディアをビルド26200.8655に静かに更新した。Media Creation Tool（MCT）から作成するUSBメモリやISOファイルに、6月10日のPatch Tuesdayで配信されたセキュリティ修正と品質改善がすべて組み込まれており、クリーンインストール直後に大量のアップデートをダウンロードする手間が省けるようになった。 何が変わったのか 今回の「メディアリフレッシュ」とは、Windowsのインストールメディアそのものに最新の累積アップデートを焼き込む作業だ。従来、MCTで作成したUSBメモリは初期ビルドのまま配布されることが多く、インストール直後にWindows Updateが何GBもの差分を落とし、複数回の再起動を要求するという状況が日常だった。 新しいビルド26200.8655には以下が含まれている： 2026年2月〜6月分のPatch Tuesdayセキュリティ修正（カーネル・ネットワークスタック・グラフィクスサブシステム等の脆弱性対応） Secure Boot証明書の失効更新（KB5036210）——BootkitマルウェアBlackLotusへの対抗措置として、脆弱なブートマネージャーを初期状態からリボークする Intel・AMDプロセッサ向けマイクロコードアップデート（サイドチャネル攻撃対策） File Explorerの表示不具合やマルチモニター時のスタッタリング等の品質修正 ITエンジニア・管理者への実務的な意味 クリーンインストール運用の効率化 PCの初期セットアップを複数台まとめて実施するIT管理者にとって、メディアのベースラインが古いことは「見えないコスト」として蓄積する。1台あたり30〜60分かかっていたWindows Update待ちが、最新メディアを使うことで大幅に短縮できる。 とくに企業のPC入れ替え・オンボーディング作業が集中する時期には、このリフレッシュの恩恵が現れやすい。 Secure Bootの重要性 BlackLotusが示したように、Secure Bootの証明書失効が古いままのメディアからインストールすると、セットアップ完了直後から「保護されていない状態」が生じる。KB5036210の同梱は、この空白時間を潰す意味で正しい判断だ。 Secure Bootを「デフォルトで有効化する方向」に持っていくための地道な施策として評価できる。 メディアの取得方法 Microsoftの公式ダウンロードページからMCTを再ダウンロードするだけで自動的に最新ビルドが作成される。すでにUSBメモリを手元に持っている場合は、作り直しを推奨する。既存メディアのビルド番号は、ブート後のwinverまたはインストールISOのプロパティで確認できる。 実務での活用ポイント 展開用ゴールデンイメージの更新タイミングとして活用: 毎月のPatch Tuesdayの翌週にMCTを再実行し、ゴールデンISOを刷新するサイクルを確立すると、差分更新の手間が最小化できる USB作成後にビルド番号を必ず記録: 複数のUSBが混在する現場では、インストール後にwinverで確認するよりも、ラベルや管理台帳にビルド番号を記しておくほうが確実 Secure Boot有効化の社内標準化をこの機会に: 新しいメディアはSecure Boot前提の構成がより整合的になっている。まだSecure Bootをオフにしている端末が残っていれば、棚卸しのきっかけにしたい 筆者の見解 Windowsの細かい動向を毎回追うことの意義が問われる時代になったとはいえ、メディアリフレッシュのような地味な改善は着実にIT現場の生産性に効いてくる。こういう「裏方の丁寧な仕事」こそ、Microsoftが積み上げてきた運用品質の真骨頂だと思っている。 とくにSecure Bootの証明書失効をメディアに同梱する動きは、セキュリティを後付けではなくデフォルトに組み込むという正しい方向性だ。ゼロトラスト的な発想でいえば、「インストール直後が最も無防備な瞬間」を潰していくこのアプローチは評価したい。 欲を言えば、このメディアリフレッシュのタイミングと内容を、もう少し明示的にアナウンスしてほしい。今回も「静かに更新」されており、IT管理者が気づかず古いメディアを使い続けるケースは十分に起こりうる。Microsoftには、こういう地道な改善をもっと堂々と伝える発信力が必要だと感じる。良いものを作っているのだから、正面から伝えてほしい。 出典: この記事は Windows 11 June 2026 Media Refresh: New USB Install Baseline 25H2 (26200.8655) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11 Insiderプログラムにおいて、Beta・Experimental・Release Previewの全チャンネルを対象に1日で計7本のビルドをリリースした。これはInsiderプログラム史上最多の同日リリース数であり、現在進行中のチャンネル再編の複雑さを象徴している。 7本のビルド——何がどこに？ 今回同時リリースされたビルドは以下の通りだ。 チャンネル バージョン ビルド番号 Experimental (Future Platforms) — 29610.1000 Experimental 26H1 28120.2302 Experimental 25H2 26300.8687 Beta 26H1 28020.2298 Beta 25H2 26220.8680 Release Preview 26H1 28000.2333 Release Preview 24H2/25H2 26100.8728/26200.8728 3つのチャンネルそれぞれに複数バージョンが存在するこの構成は、正直わかりにくい。本質的に今回の更新で最も重要な変更が含まれているのは 25H2系のビルド群であり、26H1のビルドはその25H2で既出の機能を後追い移植しているにすぎない。 注目の新機能5選 1. Windows Updateの再起動が月1回に（Experimentalチャンネル） ドライバー・.NET・ファームウェアの更新を毎月の「Patch Tuesday」に集約することで、再起動を月1回に削減する仕組みが試験中だ。業務PCでのアップデート運用を担うIT管理者にとって、最も実用的な変更と言える。 2. Windows Searchがタイポに強くなる（Experimentalチャンネル） 「utlook」と打っても「Outlook」を検索できるようになるなど、タイプミスや文字抜け・文字追加への耐性が向上。Windows Settingsの検索精度もランキング改善により向上する。 3. Bluetooth接続の改善（Release Preview 25H2/24H2） Apple AirPodsのペアリング表示が高速化し、Beats Studio Proのマイク信頼性も改善。スリープ復帰後のBluetooth再接続速度も向上する。BYOD環境で個人用イヤホンを業務に使う場面が増えた昨今、実務への影響は小さくない。 4. Widgetが静かになる（Beta 25H2、Release Preview） ホバーで自動展開しなくなり、通知バッジの挙動も整理される。加えて、低メモリデバイスでのメモリフットプリントが削減される。「Widgetの通知がうるさい」という声は日本のユーザーからも多く聞こえており、実用改善だ。 5. アクセシビリティ強化（各チャンネル） 画面全体に色フィルターを重ねる「スクリーンティント」機能（目の疲れ軽減）、拡大鏡のズームプリセット追加、さらに音声アクセス・音声入力がフランス語・ドイツ語・スペイン語に対応した。日本語は今回未対応だが、グローバル展開の足固めが進んでいる。 「26H1はARMの踏み台」という重要な注意点 Microsoftはすでに明言しているが、Windows 11 26H1は次バージョン（26H2）へのインプレースアップグレードに対応しない。これはARM Siliconを搭載した新型PCに初期搭載する「ターゲット向けリリース」という位置づけだからだ。 企業のPC展開計画を担うIT管理者は、26H1の扱いに注意が必要だ。26H1搭載の新型ARMデバイスを調達する場合、将来の更新パスが通常と異なることを把握した上で管理設計を行うべきだ。 実務への影響——日本のIT管理者が今知っておくべきこと Windows Update運用の変化に備える: 再起動を月1回に集約する機能はExperimentalチャンネルで試験中であり、実際の一般提供まで数カ月かかる見込みだ。ただし方向性が固まってきたため、社内のパッチ管理ポリシーを「週次再起動前提」から「月次集約前提」へと段階的に検討し始める時期に入っている。 ...

MicrosoftがWindows 11 Insider ExperimentalチャネルにBuild 26300.8687を配信し、ファイルエクスプローラーのタブ機能を大幅強化するとともに、Windows Updateの統合ページ化と高速検索エンジンの刷新を実施した（2026年6月12日）。 ファイルエクスプローラーのタブ、ようやく「使える」レベルへ 2022年にタブ機能が導入されて以来、「あって便利だが物足りない」という声が絶えなかったファイルエクスプローラーのタブが、本Buildで大きく進化した。 並べ替えとミドルクリック対応 ドラッグ＆ドロップによるタブの並べ替えがついに可能になった。ブラウザでは当たり前のこの操作が、Windowsの基本機能に実装されるまでに約4年かかったことになる。タブの右クリックメニューには「他のタブを閉じる」「右のタブをすべて閉じる」「新規ウィンドウに移動」が追加。さらにフォルダをミドルクリックすると新しいタブで開く機能も実装された。ブラウザユーザーにはおなじみの操作で、毎日の作業でのクリック数を大幅に削減できる。 タブ永続化——再起動しても作業環境が戻る 最も実用的な変更が「タブの永続化」だ。サインアウト前に開いていたタブを、再起動後に復元できるようになった。フォルダオプションの新設定でオン/オフを切り替えられる。複数ウィンドウ・数十タブの環境でも動作が安定しているという。毎日の作業開始時に決まったフォルダを開くルーティンが不要になり、作業の継続性が向上する。 プロセス分離——クラッシュの連鎖を防ぐ 技術的にとりわけ重要なのが「タブのプロセス分離」だ。従来、すべてのタブはexplorer.exeの単一プロセスで動作していた。本Buildからは、設定を切り替えることで各タブをサンドボックス化された独立プロセスで実行できる。 デフォルトはパフォーマンス優先の単一プロセスのままだが、任意で有効化できる。効果は明確で「ネットワーク共有フォルダへのアクセスで1タブがハングしても、Explorerウィンドウ全体がクラッシュしない」という長年の問題が解消される。企業環境でのNASやファイルサーバー利用時に特に恩恵がある。Microsoftはこの変更が「将来の拡張サポートへの布石」とも述べている。 その他の改善 タブにカスタム背景色を設定できるようになった。本番フォルダと検証フォルダを色で区別するといった用途に使える。メディアファイルを含むフォルダのタブには音声再生中のインジケーターも表示される。 Windows Updateが一本化——バラバラだった更新管理を統合 「品質更新プログラム」「機能更新プログラム」「ドライバー更新」「オプション更新」と分散していたWindows Updateの各セクションが、ついに1つのページに統合された。 新しい「更新履歴」ペインには、累積更新・機能更新・ドライバー・定義ファイルのすべてが時系列で一覧表示される。各エントリにはKBナンバー、説明、インストール状況が明示され、更新の種類別フィルタリングやKBナンバーでの検索も可能だ。 依存関係の処理も改善され、更新確認時に対象更新をまとめてスキャンし一括インストールする流れとなり、再起動の回数が削減される。 検索の大幅高速化——ライブインデックスとクラウド統合 Windowsの検索機能は長年「信頼できない」との評価が定着していた。Build 26300.8687ではライブコンテンツインデックスとクラウド統合を導入し、この課題に取り組む。ライブインデックスはファイルの変更をリアルタイムで追跡するため、作成直後のファイルでも即座に検索結果に表示される。クラウド統合によりOneDriveのファイルもローカルファイルと同列で検索できるようになる。 実務への影響 IT管理者・エンジニア向け ファイルサーバーやNASを多用する環境では、プロセス分離によりExplorerの安定性が向上する Windows Updateの一本化で、更新状況の確認やKBナンバーの追跡が簡略化される。パッチ管理業務の工数削減に直結する 検索のリアルタイム化により、大量のログファイルや設定ファイルを扱う作業環境での生産性向上が期待できる 一般ユーザー・パワーユーザー向け タブ永続化により、毎朝の「フォルダを開き直す」作業が不要になる タブの色分けで複数プロジェクトの同時管理がしやすくなる タブのミドルクリック展開はブラウザユーザーには即戦力となる操作感だ 本Buildは段階的展開のため、すべてのInsiderに同時配信されるわけではない。一般提供（GA）は2026年内の予定とされている。 筆者の見解 Windowsの個別機能を細かく追いかけることへの熱量は、正直かつてほどではなくなってきている。だからこそ、今回の変更は「追う価値がある」と感じた数少ないアップデートだ。 ファイルエクスプローラーのタブは「あれば便利」という段階から「ないと困る」という段階へ移行する可能性がある。中でもプロセス分離は評価したい点だ。企業の現場では「Explorerがフリーズして業務が止まった」というトラブルが今でも発生している。根本からアーキテクチャを変える対応は地味だが正しいアプローチで、こういう積み重ねが長期的な安定性の土台になる。 Windows Updateの統合は、遅れたとはいえ「なぜ最初からこうしなかったのか」という改善で、管理者がずっと待っていたものだ。Microsoftにはこうした「使い手の視点で当たり前を整える」作業をもっと続けてほしい。派手な新機能よりも、地道な改善が長期的な信頼を積み上げる。 これらの機能が予定通り2026年内に一般提供されれば、日常業務での実際の体感が変わる可能性がある。Experimentalチャネルで試せる立場の方には、ぜひ実際に触って検証することをお勧めしたい。 出典: この記事は Windows 11 Insider Build 26300.8687: Explorer Tabs, Unified Updates, Better Search の内容をもとに、筆者の見解を加えて独自に執筆したものです。

YouTuberで修理権（Right-to-Repair）活動家のルイ・ロスマン氏が、Samsung 990 Pro SSDの保証プロセスが詐欺的だとして、Samsungに対する法的措置に踏み切ることを表明した。正規の交換品を受け取れなかったと主張するロスマン氏は、これを単なる個人の問題としてではなく、消費者保護全体の問題として社会に問いかけている。 ルイ・ロスマンとは ルイ・ロスマン氏はニューヨーク拠点の修理専門家であり、135万人以上のチャンネル登録者を持つYouTuberだ。MacBookやiPhoneのロジックボード修理の技術解説で知られる一方、AppleやMicrosoftを含む大手メーカーの「修理妨害」政策に対して声を上げ続けてきた。彼の訴えは米国のRight-to-Repair法制化運動にも影響を与えており、単なるコンテンツクリエイターを超えた消費者権利の実践的な旗手として広く認知されている。 Samsung 990 Pro SSDをめぐる問題 Samsung 990 ProはPCIe 4.0接続で最大7,450MB/sの読み取り速度を誇るフラッグシップNVMe SSDだ。2023年末にはファームウェアの不具合によって残り寿命（TBW）が実際より速く消耗されるとの報告が相次ぎ、一部ユーザーが保証交換を求める事態となった。 今回ロスマン氏が問題視しているのは、保証申請そのものの不誠実な運用だ。同氏によれば、正規の保証条件を満たしているにもかかわらず、Samsungは不当な手続きを設けて実質的に交換を拒否したという。彼はこの一連の対応を「warranty scam（保証詐欺）」と断言し、法的手段に訴える姿勢を動画で公表した。 実務への影響 保証書を購入前に読む習慣を 特にSSD・メモリ・サーバー向けNVMeストレージを大量購入する法人においては、保証条件・除外事項・RMA（Return Merchandise Authorization）プロセスを事前に精査することが不可欠だ。「保証付き」の表示だけで安心するのではなく、実際に保証を行使できる条件が自社の利用形態と合致しているかを確認する必要がある。 ログと通信記録の保全が交渉力になる 機器の故障状況、購入証明、メーカーとの通信履歴をスクリーンショットやログとして残しておくことが、保証交渉において決定的な差を生む。ロスマン氏は動画という強力な記録手段を持っているが、一般のエンジニアでも問い合わせメールの文面や受付番号の保存は徹底したい。 法人調達は国内正規代理店を優先する グレー品や個人輸入品では保証対応のフローが国内と大きく異なる。法人環境での大量導入には、国内認定代理店を通じて購入し、保証が国内で完結する体制を整えることをすすめる。Samsung以外にもWD Black SN850XやKIOXIA（旧東芝）など信頼性の高い選択肢があるため、複数メーカーを比較検討する余地は十分にある。 筆者の見解 今回のロスマン氏の行動が興味深いのは、「怒っているだけ」ではなく意図的に「事例として記録し、法廷へ持ち込む」という点だ。一般の消費者が大企業の保証運用の不備と戦うのは労力と時間を要する孤独な作業だが、影響力のある人物が証拠を公開しながら法的手続きに踏み込むことで、他の被害者の声を集め、業界慣行に圧力をかけるきっかけになる。 日本においても、精密機器や家電の保証対応は「お上が言うなら」と泣き寝入りしてしまうケースが少なくない。グローバルで同一製品を販売するメーカーに対しては、他国の訴訟でも相応の影響力を持ちうるため、この動向は注視に値する。 ハードウェア選定においては「スペックと価格」だけでなく、「保証期間内に問題が起きたときメーカーが誠実に対応するか」も重要な評価軸だ。購入後のサポート品質まで含めて評価する視点が、長期的な運用コストの最小化につながる。今回の件を、自社の調達基準を見直す契機にしてほしい。 出典: この記事は Louis Rossmann suing Samsung over “990 Pro SSD warranty scam” の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows ServerにDNS over HTTPS（DoH）の正式サポートを追加した。数か月間プレビュー段階にあった本機能がついに本番環境向けに提供され、大規模なネットワーク改修を伴わずにDNSトラフィックの暗号化が実現できるようになった。 DNS over HTTPSとは何か DNS（Domain Name System）はドメイン名をIPアドレスに変換する、インターネットの「電話帳」に相当する基盤技術だ。しかし従来のDNSクエリは平文（暗号化なし）で送信されるため、通信経路上の第三者がどのサイトにアクセスしているかを容易に把握できる。 DNS over HTTPS（DoH）はこのクエリをHTTPS（TLS）で暗号化し、通信内容を保護するプロトコルだ。Webブラウザ向けには数年前から普及が進んでいたが、Windows ServerのDNSサーバー機能として標準サポートされるのは今回が初めてとなる。 何が変わるのか 今回の正式GA（一般提供）で押さえておくべきポイントは以下の通りだ。 DNSトラフィックの暗号化: クエリ内容がHTTPS経由で保護され、通信経路での盗聴・改ざんが困難になる 既存ネットワーク構成への影響が小さい: 大規模なネットワーク改修を伴わずに導入できる点をMicrosoftは強調している 社内DNSにも適用可能: 外部DNSサービスだけでなく、オンプレミスのWindows Server DNSでも暗号化通信が実現できる 実務への影響 ゼロトラストアーキテクチャを推進している組織にとっては特に意味のある強化だ。ゼロトラストの基本原則は「内部ネットワークだから安全」という前提を捨て、すべての通信を検証することにある。IDやエンドポイントをどれだけ強化しても、DNSが平文のままでは通信先ドメインの一覧が経路上で丸見えになる穴が残る。 日本の大企業や官公庁では、ゼロトラスト移行の文脈でネットワーク全体の可視化・制御を強化しているフェーズの組織が多い。Windows Server 2025以降を利用している環境であれば、追加のネットワーク機器投資なしにこの穴を塞げる可能性がある。 IT管理者が確認すべき項目: 利用中のWindows ServerバージョンでDoHが利用可能かを確認する ファイアウォールやプロキシルールで、HTTPS（443ポート）経由のDNS通信が許可されているかを確認する クライアント側（Windows 11）でもDoHが有効になっているか確認する（クライアントとサーバーの両方を揃えるのが理想） DoH導入後のDNSトラフィック可視性の変化を事前に把握し、既存のセキュリティ監視フローへの影響を検討する 筆者の見解 ゼロトラストが注目されて久しいが、「認証強化した」「EDR入れた」で終わり、DNSは従来のまま放置している組織は今も多い。そういった意味で、Microsoftがこの機能をWindows Server標準機能に組み込んだことは評価に値する。セキュリティ製品を別途調達しなくても、OS標準でDNS暗号化を実現できる選択肢が増えることは、現場の導入ハードルを下げる上で重要だ。 ただし誤解のないように補足しておきたい。DoHはあくまでDNS通信の暗号化であり、DNSフィルタリング（悪意のあるドメインのブロック）の代替機能ではない。従来のDNSトラフィックを監視してセキュリティインシデント検知に役立てているチームは、DoH導入によって可視性が下がるケースがあるため、設計段階での十分な検討が必要になる。 インフラの土台レイヤーを丁寧に固めていくこの方向性は正しい。複雑な実装をOSが吸収してくれれば、現場への展開障壁は大きく下がる。セキュリティの底上げが「買い物」ではなく「設定」で完結できる領域が増えることを、継続して期待したい。 出典: この記事は Windows Server gets DNS over HTTPS (DoH) support の内容をもとに、筆者の見解を加えて独自に執筆したものです。