Windows

AMDは機械学習（ML）を活用したアップスケーリング技術「FidelityFX Super Resolution 4（FSR 4）」の対応ゲーム数が300タイトルを超えたことを公表し、同技術のプロフェッショナル向け派生製品「Radeon AI FSR PRO」を新たに発表した。 FSR 4とは何か——MLが変えたアップスケーリングの常識 FSRシリーズはAMDが開発するオープンソースのアップスケーリングフレームワークで、低解像度でレンダリングした映像を高品質に引き上げることでGPUへの負荷を大幅に削減する技術だ。旧世代のFSR 1はシャープネスフィルタ、FSR 2以降は時間的情報（Temporal）を組み合わせてきたが、FSR 4では機械学習モデルをアップスケーリングの中核に据えた点が最大の変化だ。 競合のNVIDIA DLSS（Deep Learning Super Sampling）が同様のML推論ベースのアプローチを取っており、AMDもいよいよその土俵に完全に乗り込んできたと言える。ただし、FSRはオープンソースであり、AMD以外のGPUベンダーでも動作する設計が維持されている。 300タイトル突破の意味 300本という数字は、単なる累積カウントにとどまらない意味を持つ。ゲームへのアップスケーリング統合には開発者側の実装コストがかかるため、対応タイトル数はエコシステムの活性度を示す指標になる。 NVIDIAのDLSSは長年の先行優位があったが、FSRはオープン性という差別化で開発者の採用障壁を下げてきた ML推論には専用ハードウェア（RDNAアーキテクチャのAI Accelerator）が必要で、古いRadeon GPUでは旧来のアルゴリズムにフォールバックする設計が維持されている 300タイトルという規模は、家庭用ゲームPCだけでなくゲームコンソール（Xbox）への影響も視野に入る Radeon AI FSR PRO——プロ用途への展開 「PRO」の名称は、AMDがゲーミング用途を超えた活用を想定していることを示す。映像制作・医療画像・CADビジュアライゼーションなど、高解像度レンダリングのコスト削減が求められるプロフェッショナル領域へのアプローチだ。 具体的なスペックや対応ソフトウェアの詳細はComputex 2026の発表を経て順次公開される見込みだが、すでにWorkstationグレードのRadeon PRO製品ラインとの統合が示唆されている。 実務への影響——日本のIT現場での着目点 映像・クリエイティブ業界： 映像制作・アニメ・CGスタジオではGPUレンダリングコストが常に課題だ。高品質な低解像度→高解像度変換が信頼性高く使えるなら、レンダリングファームの規模縮小につながりうる。 ゲーム開発スタジオ： FSR 4のオープンソース性は、ライセンスコスト0での導入を可能にする。特にインディー・中規模スタジオにとってアクセシビリティが高い。 エンタープライズ向けGPUサーバー： AIワークロードの推論処理にRadeonを使う場合、FSR PROで培われたML推論の最適化が他ワークロードにもフィードバックされる可能性がある。 ゲーマー・自作PC： RDNA 3以降のGPUを持つユーザーはFSR 4の恩恵を直接受けられる。ただし古いRDNA 2以前のカードではML推論非対応のフォールバックになるため、購入・更新の判断材料として明確に認識しておきたい。 筆者の見解 AMDのFSR戦略で一貫して評価できるのは、オープン性へのコミットメントだ。NVIDIAのDLSSはNVIDIA GPU専用という閉じたモデルだが、FSRはIntelのXeSSも含む幅広いGPUで動く設計を維持している。ゲームエンジン開発者やソフトウェアベンダーの視点では、この汎用性は非常に合理的な選択肢だ。 MLアップスケーリングという技術そのものは「ゲームのグラフィックスを綺麗にする」だけに留まらない。低解像度→高解像度への高品質変換は、監視カメラ映像の鮮明化、医療画像診断、衛星画像解析など産業応用の広がりがある。FSR PROの登場がその方向への布石だとすれば、AMDのロードマップはゲーミングGPUベンダーから「AI推論ハードウェア＆ソフトウェアプラットフォーム」への進化を意識したものに見える。 300タイトル対応という数字は、ひとつのエコシステム成熟のマイルストーンだ。今後、対応タイトル数よりも「どのAAA級タイトルでFSR 4が使われているか」の質の競争に移っていくだろう。日本のゲームスタジオがこの流れにどう乗るかも、今後注目したいポイントだ。 出典: この記事は As ML-powered FSR support reaches over 300 games, AMD announces Radeon AI FSR PRO の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft は2026年6月2〜3日にサンフランシスコ（Fort Mason）で開催した Build 2026 カンファレンスにおいて、Windows を AI エージェントの実行基盤として根本から再設計する「Windows Agent Framework」「WSL 3」「Azure Agent Mesh」「Windows Agent Store」の4つの主要機能を発表した。 Windows Agent Framework ——エージェントがWindowsの「市民権」を得る Build 2026 で最もアーキテクチャ的に意義深い発表が Windows Agent Framework だ。これは AI エージェントが Windows シェル、タスクスケジューラー、セキュリティモデルに直接統合できるようにする新しい API 群である。 従来、AI エージェントは Windows の「上に乗っかる」オーバーレイアプリとして動作していた。Windows Agent Framework では、エージェントはシステムレベルのサービスとして登録され、タスクバーへの表示、ファイルシステムイベントの受信、ビルトインのタスクスケジューラーを使ったバックグラウンドタスクのスケジューリングなどが可能になる。 IT 管理者にとって重要なのは、Intune と Microsoft Defender による管理・可視化が他のエンタープライズアプリケーションと同等に機能する点だ。社員デバイス上で勝手に動く「野良エージェント」を検出・制御できる仕組みが OS レベルで提供されることになる。 エージェントの実行レイヤーである Windows Agent Runtime は、2026年6月に Windows Insiders 向けプレビューとして提供開始。初期サポートはテキストベースのエージェントのみで、スクリーンを認識して GUI アプリと対話できるマルチモーダルエージェントは後続プレビューで対応予定だ。 WSL 3 ——「AIはLinuxのほうが得意」問題へのMicrosoftの答え 個人的に今回の発表で最も注目しているのが WSL 3 だ。現行の WSL 2 は Hyper-V 軽量 VM 上でフル Linux カーネルを動かす構成で、通常の開発作業には十分だが、AI ワークロードが Windows 側の GPU や NPU にアクセスしようとすると仮想化境界のオーバーヘッドが生じる問題があった。 ...

IntelがComputex 2026において、新世代サーバープロセッサー「Xeon 6+」を正式発表した。最大288個のEコア（効率コア）を搭載し、急増するAI推論ワークロードへの対応を主眼に設計された製品だ。 Xeon 6+とは何か Xeon 6+は、IntelのサーバーCPUラインナップに新たに加わるシリーズだ。最大の特徴は「Eコア（Efficient Core）」を大量搭載するアプローチにある。Eコアは単純処理の並列実行に優れ、従来のPコア（Performance Core）よりも電力効率が高い。同一の電力・冷却コスト内でより多くのAI推論タスクを同時処理できる点が最大の訴求ポイントだ。 最大288コアという数字は現行の競合製品と比較しても突出している。AI推論において重要なのは単一スレッドの速度ではなく、同時並行で何本のリクエストを捌ける「スループット」であるため、コア数の多さは競争力に直結する。 なぜEコア戦略なのか IntelはXeon 6でEコアとPコアの2バリアントを設定し、ワークロードの多様化に対応してきた。 Pコアモデル: レイテンシー重視。データベース処理や従来型サーバーアプリ向け Eコアモデル（今回のXeon 6+）: スループット重視。AI推論・バッチ処理・大量並列タスク向け Xeon 6+はこのEコア戦略を一段推し進めた製品だ。AIの「学習」はGPUクラスターが担うが、「推論」（ユーザーへの応答生成）はCPUで処理されるケースも多く、そのコストと速度がサービスの収益性に直結する。Xeon 6+はまさにその推論フェーズで真価を発揮する設計になっている。 AI時代のデータセンターインフラとしての意義 生成AIサービスの急拡大により、データセンターの設計思想が根本から変わりつつある。「少数の高性能コア」ではなく「大量のコアによる並列処理」が主流になる流れの中で、Xeon 6+はその方向性を明確に体現した製品といえる。 AzureをはじめとするクラウドプロバイダーはIntelとの連携が深く、今回の発表はAzureのAIインフラ強化にも間接的につながると見られる。日本企業がAzure OpenAI ServiceやAzure AI Foundryを活用する際の「処理の裏側」が底上げされることになる。 実務への影響 オンプレミス検討企業へ AI推論をオンプレミスで行いたい企業にとって、Xeon 6+は現実的な選択肢になり得る。GPUが高価・入手困難な状況では、大量のEコアでCPU推論を効率化するアプローチが費用対効果の面で有力になる場面がある。ただし、自社ワークロードがスループット型かレイテンシー型かを先に整理することが前提だ。 クラウド利用企業へ 直接購入するわけではないが、Azure・AWS・GCPのインフラ更新サイクルにXeon 6+が組み込まれることで、同コスト帯でより多くの推論リクエストを処理できるようになる。AI機能を大量展開するシステムを設計する際は、「裏側の性能向上」を前提として盛り込める時期に来ていると認識してよい。 サーバー調達担当者へ Xeon 6+の登場により、既存Xeon 6との価格競争が起きる可能性がある。今年後半にサーバー更新を予定しているなら、ベンダーとの交渉カードとして活用できる局面もあるだろう。 筆者の見解 AI時代のデータセンターは「CPUかGPUか」という単純な二択ではなくなった。推論に特化した大量コアのCPUが、GPUとの役割分担の中で確固たる地位を築きつつある。Xeon 6+の288コアという数字は、その流れの象徴だと思っている。 気になるのは、日本企業がこうした基盤技術の動向についていけているか、という点だ。AIのユースケース以前に、インフラの標準化すら進んでいない企業が依然として多い。ハードウェアの進化スピードに対して、意思決定のサイクルが明らかにかみ合っていない。 AIを「使う側」でいるのか「仕組みを作る側」でいるのかで、この先3〜5年の差は埋めがたいものになる。Xeon 6+のような基盤技術の動向を追うことは、その判断軸を持ち続けるための習慣として手放すべきではないと考えている。 出典: この記事は Computex 2026: Intel launches Xeon 6+ with up to 288 E-cores の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Intelは台湾で開催中のComputex 2026において、物理AI（Physical AI）およびロボティクスシステム開発における最大の技術課題のひとつを解決したと発表した。 「物理AIの壁」とは何か 物理AIとは、カメラ・LiDAR・各種センサーから得たリアル世界のデータをAIがリアルタイムに処理し、ロボットアームや自律走行システムなどの物理的なアクチュエーターを制御する仕組みだ。ChatGPTのような「デジタル空間のAI」とは根本的に異なる難しさがある。 最大の課題は、センサーデータの取得からAI推論、そして制御信号の出力までを数ミリ秒以内に完了させなければならない「クローズドループ遅延」の問題だ。クラウドに推論を委ねる方式では、どうしてもネットワーク遅延が発生する。製造ラインのロボットや外科手術支援システムでは、この遅延が致命的な制約となってきた。 Intelが今回の発表で打ち出したのは、この遅延問題をエッジでの高効率推論によって克服するアーキテクチャだ。センサー近傍での推論を実現し、クラウド依存を排除することで、実用レベルのレスポンス速度を達成できるとしている。 Computex 2026での発表の意義 NVIDIAがJetsonシリーズやIsaac ROSでロボティクス向けエッジAI市場を先行してきた中、Intelがこの領域に本格的に踏み込んできた形だ。同社はIntel Core UltraシリーズのNPU（Neural Processing Unit）をはじめとするエッジAI向けシリコンをこれまでも展開してきたが、今回の発表はロボティクス・物理AIという特定ユースケースを明確に意識した内容となっている。 「課題を解決した」というIntelの主張は、ロボティクス産業における競争構図を変えうる発言だ。エッジAIプラットフォームの選択肢が広がれば、ベンダーロックインのリスクが減り、システムインテグレーターや製造業者にとってのコスト最適化の余地も広がる。 日本の製造現場への実務影響 スマートファクトリーに直結する変化 日本の製造業において、ロボット導入は長年の課題だ。特に多品種少量生産に対応するフレキシブルな自動化ラインでは、リアルタイム処理能力が直接コストと品質に影響する。Intelの技術が成熟すれば、以下のシナリオが現実的になる。 協働ロボット（コボット）の安全応答高速化: 作業者との接触回避など安全系ロジックのレスポンスが改善 全数ビジョン検査の実用化: 高速な推論により、ライン速度を落とさずに全数品質検査が可能に 工場内完結型AIシステムの構築: クラウド連携の複雑さを排除し、工場内ネットワークだけで完結する構成が実現しやすくなる IT担当者・システム担当者が押さえるべき点 ロボティクス案件では今後「推論をどこで実行するか（エッジvsクラウド）」の設計判断が最重要事項になる IntelプラットフォームとNVIDIAプラットフォームの選択は、コスト・消費電力・ツールチェーンとの相性を総合的に評価する必要がある OpenVINOなど既存のIntelエッジAIツールチェーンとの継続性・移行コストは事前確認が必須 筆者の見解 Intelの今回の発表は、物理AIという成長分野における同社の本気度を示す点で注目に値する。ロボティクスは「AIがデジタルから物理世界へ出てくる」最重要フロンティアであり、ここでの技術優位は今後10年の産業競争を左右しうる。 ただし「課題を解決した」という主張は、ベンチマークと実環境の間にギャップがある場合も多いため、慎重に受け止めるべきだろう。実証済みの現場事例が積み上がるまでは、投資判断はPoC（概念実証）を経てからが堅実だ。 日本のものづくり現場にとって、エッジAIの高速化は「あれば便利」から「なければ競争に負ける」インフラになりつつある。Intelの発表が実装レベルで機能するなら、製造業DX推進の選択肢が確実に広がる。今こそPoC環境を構築し、実際の製造ラインで検証を始める好機といえるだろう。 出典: この記事は Computex 2026: Intel says it’s solved one of the biggest physical AI and robotics issue の内容をもとに、筆者の見解を加えて独自に執筆したものです。

IntelはComputex 2026において、データセンター向け新世代GPUプラットフォーム「Crescent Island」を正式発表した。最大480GBのVRAM（ビデオRAM）を搭載し、大規模AI推論・HPC（高性能計算）・データ集約型ワークロードを主なターゲットに据えた製品ラインナップとなっている。 Crescent Islandとは何か Crescent IslandはIntelのデータセンター向けGPUプラットフォームの新世代製品で、今回のComputex 2026での発表が初の公式お披露目となった。最大の特徴は最大480GBという大容量のVRAMだ。 なぜVRAMの容量がこれほど重視されるのか。大規模言語モデル（LLM）をはじめとするAIモデルは、パラメータ数が増えるにつれてメモリ消費量が指数的に増加する。GPT-4クラスのモデルをフル精度（FP32）でロードするだけで数百GBのメモリが必要となるケースがある。480GBというVRAMは、こうした大規模モデルの推論を1枚のカード、あるいは少枚数の構成で賄える可能性を示す数字だ。 HPC（High Performance Computing）の文脈でも、流体力学シミュレーションや気候モデリング、創薬分野での分子動力学計算では、データセット全体をGPUメモリに乗せることが計算速度の律速段階となる。大容量VRAMはこれらのワークロードでも直接的なパフォーマンス向上につながる。 競合状況と市場の文脈 現在、AI・HPCアクセラレーター市場はNVIDIAのH100/H200シリーズが圧倒的なシェアを持つ。AMDもMI300Xシリーズで対抗しており、MI300Xは192GBのHBM3メモリを搭載する。Intelがそのさらに上を行く480GBを投入してくる形だ。 IntelはかつてGaudi 2/3シリーズでAIアクセラレーター市場への参入を試みてきたが、NVIDIAのCUDAエコシステムの厚さに阻まれ、普及は限定的だった。Crescent IslandはそのGaudiシリーズからの進化形と見られているが、今回の発表ではソフトウェアスタック・エコシステム面の詳細はまだ明らかになっていない。ハードウェアスペックだけでなく、ソフトウェア対応の充実度が実際の普及を左右する。 実務への影響——日本のエンジニア・IT管理者に何が変わるか Crescent Islandの登場は、日本の企業IT・研究機関にとって以下の観点で注目に値する。 オンプレミスAI推論の現実味が増す 大容量VRAMを持つGPUの選択肢が増えることで、クラウドに依存せずに大規模モデルをオンプレミスで動かすコスト試算が変わってくる可能性がある。特にデータを外部に出したくない金融・医療・製造業での活用検討が現実的になる。 競争激化によるコスト低下への期待 NVIDIAほぼ一択だったアクセラレーター市場にIntelが本格参入することで、中長期的に調達コストへの下押し圧力が働く可能性がある。現在のH100調達難・高コストに悩む組織にとっては、代替選択肢の登場は歓迎材料だ。 ソフトウェア互換性の確認は必須 PyTorch・TensorFlowをはじめとするAIフレームワークでの動作実績、ROCm・oneAPIとの統合状況は必ず確認が必要。ハードウェアスペックだけで選定するとソフトウェア面で躓くのがアクセラレーター調達の典型的な落とし穴だ。 筆者の見解 Crescent Islandで印象的なのは、スペック上の数字の大きさよりも「Intelがここで本気を出してきた」というシグナルだ。GPUコンピューティング市場への参入を何度も試みてきたIntelが、480GBというインパクトのある数字を持ってComputexに出てきた意味は小さくない。 一方で、技術的に正直に言えば、スペックシートと実ワークロードでの性能は別物だ。VRAMが大きくても、メモリバンド幅・演算精度・ソフトウェアスタックの成熟度がボトルネックになれば絵に描いた餅になる。IntelがCUDA対抗のエコシステムをどこまで整備できるかが、普及の鍵を握っている。 AIインフラの文脈では「選択肢が増える」こと自体に価値がある。ベンダーロックインのリスクを分散し、調達の交渉力を持つためにも、IntelのGPUが実用に耐える水準に育ってくれることを期待したい。詳細なベンチマーク・エコシステム対応状況が出揃った段階で、改めて評価したいところだ。 出典: この記事は Computex 2026: Intel launches Crescent Island GPU with up to 480GB VRAM の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月29日、Build 2026においてWindows 12に関する発表・言及を一切行わないと正式に表明した。Windows 11をAI時代の中核プラットフォームとして継続強化する方針を明確にした上で、同時期に開催されるComputex 2026（台湾）でAI PCハードウェアの新局面を提示する見通しだ。 MicrosoftのBuild 2026公式声明 Microsoftはわずか数行の声明で、方向性を明確に示した。 「Build では最新のプラットフォーム イノベーションを開発者の皆さんと共有できることを楽しみにしています。今年のフォーカスはWindows 11に提供されるAI搭載エクスペリエンスとツールであり、Windows 12については議論しません。」 言葉を選んでいるように見えるが、実際には解釈の余地がない。Windowsの公式ソーシャルアカウントが台湾・南港展示館（Computex の主要会場）へのマップピンと「A new era of PC begins」というメッセージを投稿したことで、ハードウェア発表への期待感は高まっている。 なぜWindows 12ではないのか――戦略と技術の両面から エンタープライズの疲弊という現実 Windows 10からWindows 11への移行は、TPM 2.0要件やCPU互換性の壁から、多くの企業でいまだ完了していない。ここでWindows 12という新たなバージョン番号を持ち出せば、新たなハードウェア互換性ゲートが生まれ、IT部門は再びデプロイ計画の見直しを迫られる。「Windows as a Service」が目指してきた継続的な信頼関係を、みずから壊しかねない。 「バージョン番号」はもはや意味をなさない 技術的な観点では、Windows 12とWindows 11の大型アップデートの差は、ほぼ「マーケティングラベル」の問題に過ぎない。Windows 11のアーキテクチャは、モダンなコンポーザブルシェル、堅牢な仮想化基盤、後方互換性を維持しつつ進化できるドライバーモデルを備えている。カーネルの強化やUX刷新は、バージョンを上げずとも累積更新プログラムとして提供できる。あえて「12」と呼ぶことで生まれる混乱より、静かに実力を磨く方が合理的だ。 AI PCというハードウェアの切り札 Computex 2026でのティーザーが示す通り、Microsoftの「次の一手」はソフトウェアバージョンではなくハードウェアエコシステムだ。Copilot+ PC要件に代表されるNPU搭載デバイスの普及が進めば、Windows 11の機能アップデートが真の価値を発揮する土台が整う。この文脈では、「Windows 12」という看板よりも「AI PCとWindows 11の組み合わせ」の方が、開発者・OEMパートナーに対して説得力のある技術メッセージになる。 日本のIT現場への影響 エンタープライズ担当者へ: Windows 12への移行計画はいったん白紙に戻してよい。しばらくはWindows 11の24H2以降のフィーチャーアップデートに集中し、Copilot+ PC対応ハードウェアへの計画的なリプレースを進めることが現実的な戦略だ。 PC調達担当者へ: Computex 2026でNPU性能が強化されたAI PC新モデルが発表される可能性が高い。2026年後半以降の調達タイミングでは、NPU搭載有無と対応するAI機能セットを評価軸に加えることを推奨する。 開発者へ: Build 2026の焦点はWindows 11上のAI活用API・ツールチェーンになる。Copilot+ PC向けのAI推論APIや、自然言語インターフェースとの統合など、Windows 11ベースで動く機能群を先行して把握しておくことが重要だ。 筆者の見解 この発表には「なるほど」と思う部分がある。バージョン番号を振りかざして開発者やIT部門を振り回す時代は、Microsoftにとっても百害あって一利なしだったはずだ。「Windows 11をずっと進化させていく」という姿勢は、長期的な運用計画を立てやすくなるという意味で歓迎できる。 ただ、正直に言えば、Windowsそのものを細かく追う必要性は以前より薄れていると感じている。AIの主戦場がクラウドAPIとエッジのNPUに移る中で、OSのバージョン番号よりも「どのAIモデルをどのインフラで動かすか」の方が、現場の関心事になっている。 その意味で、Computex 2026でのAI PCハードウェア発表の方が注目に値する。Microsoftが本当に「AI PCの新時代」を切り開くつもりなら、NPU性能・電力効率・AIアクセラレーション対応のAPIスタック、この3点を競合と真正面から比較できる水準で出してきてほしい。Microsoftにはそれをやりきる技術力とエコシステムがある。今がその力を示す好機だ。 ...

WordPressの有料プラグイン「WP Maps Pro」に発見された重大脆弱性（CVE-2026-8732）が実際に悪用されており、認証なしで管理者アカウントを作成できる攻撃が確認されている。セキュリティ企業Defiantは過去24時間で3,600件超の攻撃試行をブロックしており、同プラグインを使用しているサイト管理者にはバージョン6.1.1への即時アップデートが強く求められる。 WP Maps Pro とは WP Maps Pro は、WordPressサイトにインタラクティブなマップや店舗ロケーターを組み込める有料プラグインだ。Google MapsやOpenStreetMapなど複数のマッププロバイダーに対応しており、不動産、旅行、店舗ディレクトリなど幅広い用途で使われている。Envato Marketでの販売数は15,800件を超えており、業務用サイトでの普及度は高い。 脆弱性の仕組み — 善意の「サポート機能」が攻撃経路に CVE-2026-8732の根本原因は、プラグインに組み込まれた「一時アクセス（temporary access）機能」にある。これはベンダーのサポートスタッフが顧客サイトにアクセスしてトラブルシューティングを行うための機能だ。 問題は、この機能が使うAJAXエンドポイントが認証なしのユーザーからもアクセス可能だった点にある。保護機構として使われていたnonceチェックは、フロントエンドのJavaScriptに公開されていたため、事実上無効だった。 攻撃者がこのエンドポイントに細工したリクエストを送ると、以下の処理が連鎖する： wp_insert_user() でランダムなユーザー名の管理者アカウントを作成 管理者ロールをハードコードで付与（メールアドレスも support@flippercode.com でハードコード） パスワードレスの「マジックログインURL」を生成・レスポンスに返す 攻撃者がそのURLにアクセスするだけで管理者としてログイン完了 パスワードも追加認証も一切不要という、極めてシンプルかつ致命的な攻撃経路だ。 管理者権限を奪取されると何が起きるか WordPressで管理者権限を奪取された場合の被害は広範囲に及ぶ： バックドアの設置 — 持続的なアクセスを確保するための悪意あるコードの埋め込み Webシェルの展開 — サーバー上で任意のコマンドを実行可能にする 悪意あるプラグインのインストール — さらなる攻撃基盤の構築 プライベートデータへのアクセス — 顧客情報、注文履歴、個人情報の窃取 サイトコンテンツの改ざん — フィッシングページへの置き換えやマルウェア配布 脆弱性のタイムライン 日付 出来事 2026年3月24日 研究者David BrownがWordfenceに報告 2026年5月16日 脆弱性検証後、開発元（Flippercode）へ通知 2026年5月20日 WP Maps Pro 6.1.1リリース（修正版） 2026年5月31日 24時間で3,600件超の攻撃試行をDefiantが観測・ブロック 報告から通知まで2ヶ月近くかかっている点も気になるところだが、修正自体は通知後4日で対応されている。 今すぐやること — 対処手順 WP Maps Proを使っているWordPressサイト管理者は、今すぐ以下を実施せよ。 プラグインをバージョン6.1.1以上に更新する — これが最優先 管理者アカウント一覧を確認する — 不審なアカウント、特に support@flippercode.com に紐づくものがいないか確認 アクセスログを遡って確認する — 不審なAJAXリクエストが記録されていないか調査（攻撃が先行していた可能性がある） Wordfenceなどのセキュリティプラグインを導入する — リアルタイムの攻撃検知のため 実務への影響 日本でもWordPressは業務用サイトや企業サイトで広く使われている。今回の脆弱性が改めて示す教訓は、「サポート用の特権機能」がいかに危険な攻撃面を生み出すかという点だ。 ...

Microsoftは、VS Code 1.122においてローカルAIモデルを用いた完全オフライン（エアギャップ）環境でのコーディング支援を正式サポートした。インターネット接続が制限された政府機関・金融機関・医療機関の開発者も、AIを活用した補完・提案機能を利用できるようになる。 エアギャップ対応とは何か これまでVS CodeのAIコーディング支援（GitHub Copilotをはじめとする各種拡張）は、クラウドAPIとの通信を前提としていた。ネットワークが厳格に遮断された「エアギャップ環境」では、こうした機能は事実上使用不可能だった。 VS Code 1.122では、OllamaやLM Studioといったローカル推論サーバー上で動作するオープンソースモデルをVS Codeに直接接続する仕組みが公式に整備された。プロンプトも補完候補も一切インターネットを経由しない。モデルの選択からエンドポイント指定まで、VS Codeの設定画面から完結できる。 モバイルデバイステスト機能も追加 1.122のもう一つの注目点は、エディタ内でWebアプリのモバイル端末テストが行える新機能だ。外部エミュレーターを別途用意せずとも、VS Code内から複数のモバイルデバイスの画面サイズ・操作感を確認できる。Chromeのデベロッパーツールに近い操作感で、フロントエンド開発のコンテキストスイッチを減らせる。 なぜこれが日本のエンタープライズに刺さるのか 日本の大手企業・官公庁では、情報セキュリティポリシーにより開発端末のインターネットアクセスが厳しく制限されているケースが多い。プロキシ経由にとどまらず、完全にクローズドなネットワーク上で開発が行われている現場は決して少なくない。 そうした組織の開発者はこれまで、クラウドベースのAIコーディング支援ツールをほぼ使えない状況に置かれていた。今回の公式対応は、こうした「取り残された開発者」に正規の選択肢を提供するものだ。特に恩恵が大きいのは次の業種だろう： 金融機関：基幹系・取引系システムの閉域開発環境 官公庁・防衛関連：省庁内ネットワーク、機密情報を扱う開発室 医療機関：電子カルテシステム等のネットワーク分離環境 実務での活用ポイント ローカルモデルの選び方 コーディング用途ならDeepSeek-Coder、Codestral、Qwen2.5-Coderといったコーディング特化モデルが実績を持つ。GPU性能が低い環境では量子化モデル（Q4_K_M等）を選択することでレスポンスが大幅に改善する。まずOllamaを導入し、ollama run deepseek-coder等でモデルを起動するところから始めるのが最短ルートだ。 VS Codeとの接続手順 OllamaまたはLM Studioをローカルマシンにインストールし、任意のモデルを起動する VS Codeの拡張機能（GitHub Copilot Chat またはContinue等）のエンドポイント設定でローカルURLを指定する Ollamaの標準は http://localhost:11434 — これを登録するだけで利用開始できる セキュリティレビューの観点では、モデル自体がオンプレミスで動作し通信が発生しない点を明示することで、社内の承認が通りやすくなる。 注意すべき品質差 ローカルモデルの提案精度はクラウドモデルと比べてまだ差がある。チームとして「このモデルの提案をどの程度信頼するか」という評価基準を事前に合わせておくことが重要だ。 筆者の見解 今回の対応で注目したいのは、MicrosoftがVS Code本体に公式機能として組み込んだという事実だ。OllamaとVS Codeの連携自体は以前から技術的に可能だったが、それはあくまで「非公式な設定」だった。公式サポートとなることで、企業のセキュリティ審査や調達フローを通りやすくなるという副次効果が生まれる。「サードパーティが非公式に対応している」と「ベンダーが公式にサポートしている」では、社内承認のハードルがまるで違う。 エアギャップ対応はAIコーディング支援ツールの成熟を示す一つのマイルストーンでもある。「AIはクラウドで使うもの」という暗黙の前提が崩れ始め、エッジでもオフラインでも同等の体験が提供される方向に進んでいる。 日本の規制の厳しい業界にとっては、「やっと来たか」というタイミングだろう。AI活用の恩恵を受けにくかった開発者層に、正規の経路で生産性向上の道が開かれる意義は小さくない。MicrosoftにはVS Code周辺のローカルAI体験をさらに磨いていってほしいところで、その力は十分にある。 出典: この記事は Microsoft just made it possible to use VS Code completely offline with local AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは米国ユーザーを対象に、ヘルスケア特化型AIアシスタント「Copilot Health」の正式提供を開始した。血液検査の数値解読や個人の健康記録の安全な管理を支援する機能を備え、Copilotプラットフォームの医療分野への本格展開が始まった。 Copilot Healthでできること Copilot Healthは、一般ユーザーが医療情報の壁に直面する場面を主なターゲットにしている。主な機能は次のとおりだ。 検査結果の解読: HbA1cやeGFRといった専門用語を含む血液検査レポートを、わかりやすい日常語で説明する 医療データの一元管理: 個人の健康記録（PHR: Personal Health Record）をセキュアに保持し、必要なタイミングで参照できる 受診前の整理支援: 症状や疑問をまとめてAIに問いかけ、「次回の受診で何を医師に聞くべきか」を事前に整理できる 医療情報は専門用語が多く、患者が自分自身の診断結果を正確に理解するのは難しい。AIがこのギャップを埋める役割を担うという方向性は、実用的かつ需要のある設計だ。 セキュリティとプライバシー：最も問われる領域 医療データは個人情報の中でも最高レベルの機密性を持つ。米国ではHIPAA（医療保険の携行性と責任に関する法律）への準拠が必須であり、Microsoftはこれを前提とした設計を行っているとみられる。 ただし、AIに医療データを渡す際は以下の確認を怠らないことを強く推奨する。 データがどのリージョンのサーバーで処理されるか 入力データがモデルの学習に使用されないか（Microsoft 365の商用テナントと同様の保護があるか） 通信・保存時の暗号化が適用されているか ゼロトラスト原則の観点から言えば、医療AIに対しても「常時信頼ではなく都度検証」のアプローチが不可欠だ。 日本のIT現場への影響 現時点でCopilot Healthは米国限定の展開だが、日本のエンジニアや管理者にとっても無関係ではない。 日本ではマイナンバーカードと健康保険証の統合が進み、電子処方箋・電子カルテの普及も加速している。患者が自分の医療データにAIを通じてアクセスするシナリオは、数年以内に現実のものになる可能性が高い。 実務上の視点から整理すると： 医療系SaaSを扱うエンジニア: MicrosoftのCopilot Health設計（HIPAAコンプライアンス対応、データフロー）は、国内の医療DXシステム設計の参考になる M365管理者: Copilotの適用範囲が業務系から個人ヘルスケアへと広がる流れを把握しておくと、将来の社内ポリシー改定に備えられる 情報セキュリティ担当者: 従業員が個人の医療AIサービスに業務端末からアクセスするケースを想定し、利用ガイドラインを事前に整備しておくことを勧める 筆者の見解 Microsoftが医療AIに踏み込んだことは、企業としての実力が素直に活かせる領域への展開だと思う。医療データのプライバシー管理、厳格なコンプライアンス対応、エンタープライズグレードのセキュリティ基盤——これらはMicrosoftが長年磨いてきた強みそのものであり、他のAIプレイヤーが簡単に追いつけない部分だ。 ひとつ率直に言えば、「また名前がCopilot」という点は気になる。Copilot Studioも、Copilot for M365も、Windows Copilotも、そして今度はCopilot Health。ブランドの傘が広がるたびに、ユーザーは「どのCopilotの話をしているのか」という混乱と付き合わされる。医療という真剣なコンテキストでこそ、製品の独自性を明確に伝えるネーミングと設計にしてほしかった、というのが本音だ。 とはいえ、M365エコシステムとの連携という強みをきちんと活かした製品に仕上がっているなら、正面から評価したい。日本展開と実際の医療現場での活用事例が出てくるのを楽しみにしている。 出典: この記事は Microsoft Copilot Health is now available to users in the US の内容をもとに、筆者の見解を加えて独自に執筆したものです。

JetBrainsが、Python開発者やデータサイエンティストに広く使われてきたIDEの提供を終了すると発表した。同社はここ数年でFleet（軽量エディタ）、Aqua（テスト専用IDE）、Code With Meなど複数製品の廃止を進めており、今回の決定はその延長線上にある。 DataSpell終了の背景 JetBrainsはデータサイエンス・機械学習向けに特化したIDE「DataSpell」を2021年に一般公開した。Jupyter Notebookとの統合、インタラクティブなデータ分析環境、Pythonインタープリタとの深い連携が特徴で、データサイエンティストからの評価は高かった。 しかし、JetBrainsの主力Python IDE「PyCharm Professional」が継続的な機能強化によってDataSpellの機能を取り込んでいった結果、DataSpell固有の優位性は薄れていった。JetBrainsは今回の廃止にあたり、DataSpellのすべての機能がPyCharm Professionalに統合・継承される形で引き継がれると説明している。 製品ラインナップ整理の全体像 過去数年のJetBrains製品廃止の動きをまとめると、以下のとおりだ。 Fleet（2024年廃止）: VS Codeに対抗した軽量エディタ。リモート開発・マルチ言語対応を売りにしていたが市場に定着できなかった Aqua（廃止済み）: E2Eテスト専用IDE。テストエンジニア向けのニッチな製品だった Code With Me（廃止済み）: リアルタイム共同コーディングツール DataSpell（今回）: Pythonデータサイエンス特化IDE 共通するパターンが見える。「特化型IDEをリリース → 主力IDEが機能追いつく → 特化型を廃止してProfessionalに統合」という周期だ。 既存ユーザーへの影響と移行パス DataSpellのサブスクリプションを契約しているユーザーは、同等のJetBrains製品への移行が提供される予定だ。実務的な移行先はPyCharm Professionalとなる。 PyCharm Professionalは現在、以下のデータサイエンス向け機能を備えている。 Jupyter Notebookのネイティブ編集・実行 Conda/venv/Poetry等の環境管理 DataFrameのインタラクティブビュー Matplotlibやseabornの出力インライン表示 データベース接続ツール DataSpellユーザーが日常的に使っていた機能のほとんどは、PyCharm Professionalで代替できる状態になっている。 実務への影響——日本のエンジニア・IT管理者にとっての意味 ライセンス管理者向け: JetBrains All Products Packを契約している組織は影響を受けにくいが、DataSpell単体ライセンスを購入・管理していた場合は、PyCharm Professionalへの切り替え申請と社内展開の更新が必要になる。 データサイエンティスト向け: 移行作業自体は軽微だが、DataSpellに慣れたワークフロー（特に起動時のプロジェクト構成やショートカット配置）は若干変わる。PyCharm Professionalでも同等の作業環境を構築できるが、初期設定に数時間は見ておきたい。 VS Code/Cursorへの乗り換え検討: 今回の廃止を契機に、無料で高機能なVS Codeや、AIコーディング統合が進む他エディタへの移行を検討するチームも出てくるだろう。特にデータサイエンス用途ではJupyter拡張が成熟しており、実用上の選択肢は広い。 筆者の見解 JetBrainsのここ数年の製品整理は、ある意味で正直な経営判断だと思う。特化型IDEを量産して広げすぎ、メンテナンスコストが分散し、どれも中途半端になるよりも、主力製品に機能を集約して品質を高める方が長期的にはユーザーのためになる。 ただ、ユーザーから見ると「また廃止か」という疲弊感は否めない。FleetはVS Codeへの対抗として期待された製品だったし、DataSpellもデータサイエンス界隈で着実なファンを持っていた。製品を出して廃止するサイクルが続くと、次の新製品への信頼感が積み上がりにくくなる。 AI統合という点では、PyCharm自体のAI支援機能（JetBrains AI Assistant）の充実がこれからの勝負所だ。データサイエンス領域はとりわけAIコーディング支援との相性が良い。特化型IDEの廃止で生まれたリソースを、PyCharm ProfessionalのAI機能強化に集中させるなら、今回の判断は将来に向けた布石として評価できる。製品を絞り込んだぶん、残った製品を確実に進化させてほしい。 出典: この記事は End of an era: JetBrains is killing this popular IDE used by Python devs の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはComputex 2026およびBuild 2026の開幕を来週に控え、「Windows 12」をめぐる各種憶測に対して公式見解を示すとともに、「PCの新時代（a new era of PC）」の始まりを発表すると予告した。 「Windows 12」の噂、なぜここまで拡散したのか 近年、技術メディアやリーク情報を扱うコミュニティでは「Windows 12」という呼称が独り歩きしていた。その背景には、Windows 11のリリースサイクルが従来より長期化していること、Microsoftが「AI PC」に向けた機能強化を断続的にアップデートで投入してきたこと、そしてCopilot+ PCという新カテゴリの登場がある。これらが積み重なり、「次の大型OSはいつか」という市場の期待感が高まっていた。 Microsoftは今回、こうした憶測を「整理（clarify）」する立場を取った。つまり否定でも全面肯定でもなく、発表のタイミングと文脈をコントロールするための先手を打った形だ。 「PCの新時代」——Computex・Build 2026での発表内容とは Microsoftが予告した「a new era of PC」というフレーズは、単なるOS世代交代以上の意味合いを持つ可能性がある。Computex 2026はIntel・Qualcomm・AMDが次世代チップを競うハードウェアの祭典であり、Build 2026はAI・クラウド・開発者向け機能が発表されるソフトウェアの場だ。この両者を同時期に狙ったMicrosoftの発表は、ハードウェアとソフトウェアを一体で見せる戦略と見るのが自然だ。 具体的に予想されるのは以下のような要素だ： AI PC統合の深化: NPU（ニューラルプロセッシングユニット）を前提としたオンデバイスAI機能の本格展開 Copilot+ PC向け新機能: Recall、Click to Do、Live Captionsなどの追加・強化 UI/UXの刷新: スタートメニュー、タスクバー、設定周りの再設計の可能性 開発者向け機能: WSL（Windows Subsystem for Linux）やDev Drive、GitHub Copilot連携の強化 日本のIT現場への影響 日本企業の多くはWindows 11への移行を進めている最中であり、「また新しいOSが来るのか」という懸念が生まれるのは自然だ。しかし、現時点で確認できることを整理しておこう。 IT管理者・情報システム部門へ Build 2026の発表内容を確認するまで、移行計画を大幅に変更する必要はない 「Windows 12」という呼称が正式に採用される保証はなく、機能アップデートという形で提供される可能性も十分ある Windows 10のサポート終了（2025年10月）は変わらない。この期限から目を離さないことが最優先 エンジニア・開発者へ Build 2026のセッションカタログとデモをリアルタイムで追うことを強く推奨する AI PC向けAPIや新しいWinUIコンポーネントが発表された場合、既存アプリのモダナイズ計画に影響する可能性がある オンデバイスAIを活用したアプリ設計の検討を今から始めておくと、発表後のキャッチアップが圧倒的に速くなる 筆者の見解 正直に言えば、Windowsの発表を以前ほど興奮して追いかけることは少なくなった。それでも今回の発表予告には、一定の期待を持って見ている自分がいる。 「PCの新時代」というフレーズは確かに大げさに聞こえる。Microsoftはこの手の大言壮語を繰り返してきた歴史があり、実際の中身が伴わなかったことも少なくない。しかし今回に限っては、AI PCというハードウェアの波、オンデバイス推論の現実的な性能水準の到達、そして企業向けセキュリティとコンプライアンスの統合という文脈が重なっており、「絵に描いた餅」に終わらない素地はある。 Microsoftには、総合プラットフォームとしての底力が確かにある。Azure・M365・Windows・Copilot Studioが連携するエコシステムは、単体スペックの比較では見えない価値を持つ。来週の発表が、その総合力を「使えるAI PC体験」として具現化できるものであってほしい。 セキュリティ面では特に注目している。Copilot+ PCのオンデバイス処理はデータを外部サービスに送らない設計であり、エンタープライズのコンプライアンス要件に沿いやすい。ここが本当に機能するなら、「AIは使いたいがクラウドには送れない」という日本企業の悩みに対する有力な答えになり得る。 実際の発表内容を見てから改めて評価したい。マーケティング言語ではなく、エンジニアが触れる機能とAPIで語ってほしい。それだけだ。 ...

OpenAIは、コーディング支援AIツール「Codex」のWindowsアプリをバージョン26.527へアップデートし、これまでMacユーザー限定だった「Computer Use（PC自律操作）」と「モバイルアクセス」の2機能をWindowsでも利用可能にした。 Computer Useとは——AIがPCを「使う」機能 Computer Useは、AIがユーザーのPC上でマウス操作・キーボード入力・画面認識を自律的に行える機能だ。コーディング支援の文脈では、コードを書くだけにとどまらず、IDEの操作、ブラウザでのドキュメント参照、コマンド実行まで一連の作業をAIが代行できる。 「コードを貼り付けてもらう」レベルを超え、「開発環境の中でAIが実際に手を動かす」段階に踏み込んだ機能と言える。これまでMac版のみに先行提供されていたが、今回のアップデートでWindows環境でも使えるようになった。 モバイルアクセス——移動中も指示出しが可能に もう一つの新機能はモバイルアクセスだ。スマートフォンからCodexにアクセスし、コーディングタスクの指示出しや進捗確認が行える。複雑な開発作業をスマホで完結させることは現実的でないが、「移動中に次のタスクを仕込んでおく」「作業状況を外出先から確認する」といった使い方は十分に実用的だ。 実務への影響 Windowsメイン環境のエンジニアにとってのメリット 日本のエンタープライズでは、まだWindowsを主要な開発環境として使うチームが多い。PC操作機能の解禁により、繰り返し作業の自動化や、セットアップ手順をAIに口頭で説明しながら実行させるといった利用スタイルが現実的な選択肢になってくる。 Computer Use利用時のリスク管理 PC操作機能は強力な半面、AIが誤操作した場合のリカバリを事前に考慮しておく必要がある。実務での初期導入は、影響範囲が限られた仮想マシンやコンテナ上から始めることを強く勧める。本番環境に直結した状態でいきなり使うのはリスクが高い。 エンタープライズのセキュリティポリシーとの整合性 AIにPC操作を許可するということは、どのアプリやデータへのアクセスを認めるかの管理が必要になることを意味する。ゼロトラスト原則に基づき、Codexに付与する権限は最小限に絞り、ログ取得と定期的な棚卸しをセットで運用するのが理想的だ。 筆者の見解 Mac先行・Windows後追いという流れは、開発ツールの世界でもはや定番になった。このリリースのたびに、開発者の主戦場がどちらに傾いているかを改めて実感させられる。 Computer Use機能が本当に成熟すれば、コーディングの前工程（要件調査・資料確認）から後工程（デプロイ・テスト監視）まで含めた自律サイクルが実現し得る。それはコーディング支援の枠をはるかに超えた話になる。 ただ、機能の充実よりも先に問われるべきは「エラー時の安全策とユーザーへのフィードバックが十分か」という点だ。AIが意図しない操作をしてしまったとき、どこまで被害を最小化できるかが実用性の分かれ目になる。 「使わせない」という判断は現実的に機能しない。「安全に使える仕組みを整える」方向で検討することが、結果的にリスクを下げる近道だ。 出典: この記事は OpenAI rolls out major Codex for Windows update with computer use and mobile access の内容をもとに、筆者の見解を加えて独自に執筆したものです。

HPは同社PCユーザーの約30%が依然としてWindows 10を使い続けていると明らかにした。Microsoftが精力的にWindows 11への移行を促しているにもかかわらず、PCメーカー大手の顧客の3人に1人がサポート終了済みのOSを使い続けているという、現場の実態が浮き彫りになった。 Windows 10サポート終了から7か月超——それでも3割が残留 MicrosoftはWindows 10のサポートを2025年10月14日に終了した。つまり今日（2026年5月末）時点で、すでにセキュリティ更新プログラムが届かない状態が7か月以上続いている。それでもなお、HP顧客の約3割が移行を完了していないという事実は、企業・個人を問わず「移行の壁」がいかに高いかを示している。 Windows 10のサポート終了は決して突然の話ではなかった。Microsoftは2021年の段階からWindows 11の提供を開始し、数年間にわたって移行を呼びかけてきた。にもかかわらずこの数字が残る背景には、いくつかの構造的な理由がある。 移行を妨げる3つの壁 1. ハードウェア要件の厳格化 Windows 11の最大の関門はTPM 2.0とCPU世代の要件だ。Core第7世代以前のIntel CPU、またはRyzen 1000番台以前のAMD CPUは原則として非対応となる。企業では3〜5年の標準サイクルで机上PCを運用しているケースが多く、更新タイミングが合わなければ機器ごとの入れ替えが必要になる。調達・予算・展開作業のすべてが伴うため、「今期はとりあえずWindows 10のまま」という判断が積み重なりやすい。 2. 業務アプリ・レガシーシステムとの互換性 特に日本のエンタープライズ環境では、古い業務システムや社内開発ツール、セキュリティ製品のサポート状況が移行の判断を左右する。移行前にすべての業務アプリを検証し、問題があれば代替調達するか、例外環境を整備する必要があるため、リソースが限られる中小企業では後回しになりがちだ。 3. 「まだ動いているから大丈夫」という惰性 「サポートが切れても使えるじゃないか」という感覚は根強い。しかし、サポート終了後のWindows 10はセキュリティパッチが届かないため、新たな脆弱性が発見されても修正されない。エンドポイントの一部が穴になると、ネットワーク全体のゼロトラスト設計も台無しになりかねない。 実務への影響——IT管理者が今すぐ確認すべきこと Windows 10残存端末のリスク評価を今すぐ実施する 管理対象端末のOSバージョン分布をMicrosoft Intune（エンドポイント分析）またはMicrosoft Defender for Endpointで確認する。Windows 10端末が残っている場合、そのエンドポイントはパッチ未適用のまま稼働しているリスクが高い。条件付きアクセスポリシーでコンプライアンス非対応端末をネットワークリソースから切り離すことも検討に値する。 移行ロードマップを3か月単位で引き直す 「いつかやる」では進まない。四半期ごとにWindows 10端末の削減目標を設定し、機器更新計画と連動させる。Microsoftが提供するWindows 11互換性チェックツール（PC Health Check）を活用して、更新可能な機器から先行して移行を進めると効率的だ。 拡張セキュリティ更新プログラム（ESU）の購入を検討する MicrosoftはWindows 10向けに有償のESU（Extended Security Updates）プログラムを提供している。2026年10月まで最大3年間、月額料金でセキュリティパッチを受け続けることができる。個人向けには30ドル（年額）、法人向けはデバイス台数・ライセンス形態によって異なる。完全移行までのブリッジとして活用を検討する価値はある。ただし、これはあくまで時間稼ぎであって、根本的な解決ではない。 筆者の見解 「30%が今もWindows 10」という数字は、正直なところ驚かない。むしろ「まだそんなものか」という感覚すらある。Windows 10は完成度が高く、多くのユーザーにとって「不満がない」OSだった。移行の動機が「メリットを感じるから」ではなく「サポートが切れるから仕方なく」では、意思決定のスピードが出ないのは当然だ。 MicrosoftはWindows 11への移行をこれだけ強力に推進してきた。それでも3割が残るということは、ハードウェア要件の設計に課題があったのではないかと思う。セキュリティ強化の方向性は間違いなく正しい——TPM 2.0の必須化もセキュアブートの標準化も、カーネルドライバーの締め出しと並んで意義のある変更だ。ただ、「正しいけれど急ぎすぎた」という印象は否めない。もう少し段階的なアプローチがあれば、移行率は今より高かったはずだ、ともったいなさを感じる。 いずれにしても、IT部門がやるべきことは明確だ。「まだ動いている」を根拠にWindows 10に居続けるのは、今となってはリスク管理の観点から正当化しにくい。移行コストと放置リスクを天秤にかければ、答えはほぼ決まっている。残存端末の棚卸しと具体的なロードマップの策定を、今週中にでも始めてほしい。 出典: この記事は HP: 30% of PC customers are still running Windows 10 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Teamsが新機能「Efficiency Mode（効率モード）」を近日中にロールアウトする。低スペックのハードウェアでもTeamsがスムーズに動作するよう、リソース管理をインテリジェントに最適化する仕組みだ。 Efficiency Modeとは何か Efficiency ModeはTeamsがバックグラウンドに回ったとき、あるいはリソースに余裕がない端末上で動作しているとき、CPUやメモリの消費を自動的に抑制する機能だ。Windows 11に実装されている「効率モード」プロセス管理と同様のアプローチをTeams自体に取り込んだ形と言えばイメージしやすいだろう。 具体的には、ミーティングに参加していない待機中の状態でバックグラウンド処理を絞り込み、通知の処理・同期・プレゼンス更新などを必要最低限に制限する。アクティブな会議やチャットには支障が出ないよう、フォアグラウンドに戻った瞬間にフル機能で動作する仕組みになっている。 なぜこれが重要か TeamsはMicrosoft 365環境の中核に位置するが、その代償として常駐プロセスによるリソース消費は長年の課題だった。特に以下の状況で問題が顕在化している。 Celeron・Atom系プロセッサ搭載の廉価ノートPC（教育現場や中小企業で多く使われている） 8GB以下のRAM構成（Teamsと他のOfficeアプリを同時起動するとすぐに逼迫する） バッテリー駆動のモバイル利用（バックグラウンドのTeamsが電池を食い続ける問題） 日本企業のPC更新サイクルは平均5〜7年と言われており、スペックに余裕のない端末が現役稼働しているケースは珍しくない。Efficiency Modeはそうした環境での実用性を底上げする施策として意味がある。 実務への影響——エンジニア・IT管理者が押さえるポイント 管理者側での対応 現時点でEfficiency ModeはTeamsクライアント側で自動的に機能する設計と見られる。Teams管理センター（TAC）でのポリシー制御が可能になる場合は、低スペック端末グループへの強制有効化を検討したい。 ユーザー体験への影響確認 バックグラウンド処理の制限により、プレゼンス更新のタイムラグや通知の若干の遅延が発生する可能性がある。展開後は「自分が離席中に見えているか」「通知は届いているか」を実際に確認してほしい。 端末調達の判断材料として Efficiency ModeがあるからといってRAM 4GBの端末を買い続けていい理由にはならない。あくまで「既存の低スペック端末での延命策」と位置づけ、新規調達ではRAM 16GB以上を標準とするスタンスは変えないほうがよい。 筆者の見解 Teamsのリソース消費問題は、MVPコミュニティでも長年語られてきたテーマだ。Efficiency Modeの登場そのものは歓迎している。ただ、「もっと早くできたはずでは？」という思いは正直ある。 Windowsのプロセスレベルの効率モードが先行して実装され、アプリ側がそれに追いついてきた形だが、TeamsはMicrosoftのフラッグシップ製品だ。OSの機能を自社製品にすばやく取り込む点では、もう少し機敏でいてほしいとは思う。 とはいえ、方向性は正しい。「重いから使わない」という選択肢が許されない業務環境でこそ、こうした最適化が効いてくる。特に1人1台端末が普及しつつある教育現場や、PC更新予算が厳しい中小企業において、実質的な恩恵は小さくない。 Teamsはコミュニケーション基盤としてすでに不可欠な存在だ。その土台をしっかり磨き込んでいく作業は地味に見えるが、現場で使い続けてもらうための本質的な投資だと思っている。今後もこうした「縁の下の力持ち」的な改善を積み重ねてほしい。 出典: この記事は Here is how Efficiency Mode will work in Microsoft Teams の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google は2026年5月、Chrome の新セキュリティ機能「Device Bound Session Credentials（DBSC）」の一般提供を開始し、全ユーザーへの展開を始めた。セッションクッキーをデバイスのTPMやSecure Enclaveに暗号的に紐付けることで、クッキーを盗み出されても攻撃者が悪用できない状態にする仕組みだ。 セッションクッキー盗難の何が問題か 多要素認証（MFA）が普及した今も、「クッキー窃取→アカウント乗っ取り」という攻撃手法は現役で使われ続けている。ブラウザがログイン状態を記憶するために保存するセッションクッキーを入手すれば、攻撃者はパスワードもワンタイムコードも不要でアカウントにアクセスできてしまうからだ。 代表的な情報窃取型マルウェアである Lumma や Rhadamanthys は、Google の OAuth 「MultiLogin」APIエンドポイントを悪用して期限切れのクッキーを再生する機能まで実装していた。これに対してGoogleはこれまで「マルウェアを除去せよ」「Enhanced Safe Browsingを有効にせよ」と呼びかけるしかなかった——DBSC以前は、クッキーが盗まれた時点でほぼ詰みだった。 DBSCの仕組み——鍵はハードウェアの外に出ない DBSCはセッションクッキーを特定デバイスのハードウェアセキュリティチップに暗号的に紐付ける技術だ。 Windowsの場合: TPM（Trusted Platform Module） macOSの場合: Secure Enclave セッション確立時にセキュリティチップが公開鍵・秘密鍵のペアを生成し、クッキーの暗号化・復号に使用する。秘密鍵はチップの外に一切出ないため、マルウェアがクッキーファイルを盗み出しても、対応する秘密鍵なしには使えない状態になる。 Googleは「事後検知から事前防止へのパラダイムシフト」と表現しており、「クッキーが盗まれること自体を防ぐ」のではなく「盗まれたクッキーを使えない状態にする」という設計思想がポイントだ。 展開状況と管理者が知っておくべき制約 DBSCは現在、以下のアカウントへ順次展開中だ。 Google Workspace 企業ユーザー Workspace Individual サブスクライバー 個人Googleアカウント利用者 管理者にとって重要なのは、Google Workspaceでは管理者がDBSCを無効化できない点だ。有効化はデフォルトで行われ、管理コンソールからのオプトアウトは提供されない。ユーザー体験に影響が出た場合でも、設定で戻す手段がないことを事前に把握しておく必要がある。 実務への影響——日本のエンジニア・IT管理者が押さえるべき点 1. TPMの搭載・有効化状況を確認する DBSCはTPM対応デバイスを前提とする。Windows 11がTPM 2.0を必須要件とした背景と整合しているが、古いPCや設定上TPMが無効になっている環境では効果が限定的になる可能性がある。BIOS/UEFIでTPMが有効になっているかを一度確認しておきたい。 2. InfoStealer対策はEDRと組み合わせて多層化する DBSCはクッキー盗難の「悪用」を防ぐが、マルウェアの侵入自体を防ぐわけではない。EDR（エンドポイント検知・対応）によるマルウェアの早期検知と組み合わせることで、多層防御が初めて完成する。 3. ログ監視の重点を移行する準備を クッキー再利用による不審なセッション異常が今後減っていく代わりに、攻撃者はフィッシングやクレデンシャルスタッフィングなど別の初期アクセス手段に移行する可能性が高い。セキュリティ監視の重点を「セッション系の異常」から「認証試行の異常パターン」にシフトさせる準備を始めたい。 4. サードパーティサービスへの普及は時間がかかる 現時点でDBSCが有効に機能するのはGoogleサービス向けに限られている。一般のWebサービスがDBSCのAPIを実装するまでの「過渡期」は相応の時間がかかるため、過信は禁物だ。 筆者の見解 「MFAを突破できるのだからMFAは意味がない」という言説がSNSでたびたび流れるが、これは正確ではない。問題の本質はMFAの弱さではなく、認証後のセッション管理の甘さにある。DBSCはその弱点を、既存のクレデンシャル管理フローを変えずにハードウェア層で塞ぐ設計だ。「禁止」ではなく「仕組みで安全にする」という方向性は、IT現場で機能する本物のセキュリティ対策の正道だと思う。 ゼロトラストの文脈で言えば、「デバイスの信頼性を認証フローに織り込む」という考え方はまさに原則に忠実だ。これまでデバイスの信頼性はネットワーク層やMDM（モバイルデバイス管理）で担保しようとしてきたが、DBSCはブラウザのセッション層でも同じ思想を実現した点が評価できる。 ただし懸念もある。Workspaceの管理者が無効化できない設計は、エンタープライズ環境でのトラブル対応を難しくする可能性がある。新機能の強制展開は互換性問題が出たときの退避策がないという意味でリスクでもある。Googleがこの点についてどう対応するか、引き続き注目したい。 出典: この記事は Google Chrome adds session cookie theft protection for all users の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

セキュリティ企業Flareのリサーチャーが、ダークウェブにおけるDDoS攻撃販売市場の実態調査を発表した。2023年と2026年のデータを比較した結果、高品質なDDoS攻撃サービス広告が約10倍に急増しており、サイバー犯罪の「製品化」が急速に進んでいることが明らかになった。 DDoS攻撃がSaaSモデルへ進化 以前のDDoS攻撃といえば、スクリプトキディが使い捨てのツールを使うか、フォーラムに散在するリーク済みコードを組み合わせるような「手作り感」があった。それが今や、月額プラン・API連携・リセラープログラム・カスタマーサポート付きの「商品」として流通している。 Flareが2023年1〜5月と2026年1〜5月のデータを比較したところ、以下のような変化が確認された。 指標 2023年 2026年 変化 高品質なDDoS攻撃サービス広告数 38件 364件 約10倍 ユニークな広告クラスター数 31 123 約4倍 関与するユニークアクター数 15 41 約3倍 観測ソース数 22 43 約2倍 攻撃パネル・ボットネット連携・Cloudflareバイパス機能・ゲームサーバー特化オプションなど、機能面でも成熟が見られる。文字通り「月額課金で攻撃力を借りる」時代になっている。 現実の被害規模は想像を超える 数字だけでなく、実際の攻撃規模も右肩上がりだ。Cloudflareは2025年に7.3 Tbpsの攻撃をブロックし、同年Q4には31.4 Tbpsという記録的な攻撃の緩和も報告している。 MicrosoftもAzureが2025年10月に15.72 Tbpsの攻撃を緩和したと発表。この攻撃は「Aisuru」ボットネットによるものとされており、攻撃インフラの大規模化・高度化を裏付けている。 なぜいま日本のIT現場に影響するのか DDoS攻撃の「製品化」が進むことで、以前は技術スキルが必要だった攻撃が誰でも購入できるようになる。参入障壁が下がると、攻撃者の層が広がる。競合への嫌がらせ、恐喝目的のランサム的DDoS、政治的動機による攻撃など、動機の多様化も同時に起きる。 日本企業にとっての脅威面では以下の点が特に重要だ： ECサイト・決済系サービス: 売上繁忙期を狙った攻撃が$5〜$10程度で「発注」できる時代になっている SaaS・API基盤: アプリケーション層を狙う攻撃手法が増えており、ネットワーク帯域だけ守れても不十分 ゲームサーバー特化オプション: オンラインゲーム・メタバース系サービスは専用攻撃手法の標的になりやすい 実務での防衛ポイント 1. CDN/DDoS緩和サービスの活用を前提設計に Cloudflare・Azure DDoS Protection・AWS ShieldといったマネージドDDoS緩和サービスは、今やオプションではなく基本インフラとして位置づけるべきだ。緩和サービスなしでテラビット級攻撃を自前で処理しようとするのは現実的でない。 2. レート制限とWAFの多層防御 アプリケーション層（L7）攻撃はログインページやAPIエンドポイントを集中的に狙う。IP単位のレート制限、ボット検知、WAFルールを組み合わせて縦深防御を構成する。 3. インシデント対応計画の事前整備 「攻撃を受けてから考える」では遅い。対応手順・エスカレーション先・ISPへの緊急連絡窓口を事前に整備し、定期的な机上訓練を実施する。 4. 脅威インテリジェンスの活用 Flareのようなダークウェブ監視サービスを活用することで、自社を標的にした攻撃サービスの出回りを事前に察知できる可能性がある。完全な防御はないが、早期警戒は対応時間を生む。 筆者の見解 この調査が示しているのは、サイバー犯罪の「民主化」がいかに速く進んでいるかだ。技術的ハードルが極端に下がったとき、脅威の広がり方は質より量になる。DDoS攻撃サービス広告が3年で10倍になったという数字は、攻撃者コミュニティの活発化を端的に表している。 ゼロトラストの文脈でいえば、DDoS対策も「境界で防ぐ」発想から脱却する必要がある。テラビット級の攻撃を自前の境界機器で止めようとするのは、ゼロトラストが目指す「信頼を前提にしない設計」と同じ方向性の話だ——大規模攻撃を前提として、緩和・分散・回復力の設計を最初から組み込む。 AzureのDDoS Protectionが15.72 Tbpsの攻撃を緩和できたのは、クラウドスケールの緩和インフラあってこそだ。こういう部分はクラウドプロバイダーの強みが素直に発揮される領域で、オンプレミスで同じことをやろうとするのはコスト・技術力ともに無理筋だと思う。 日本のエンタープライズで気になるのは、DDoS対策が「ネットワーク部門の問題」として矮小化されているケースがまだ多いことだ。アプリケーション層攻撃が増えている今、開発・インフラ・セキュリティが連携した設計レビューが欠かせない。攻撃者の側が成熟したサービスモデルで来るなら、守る側も同じくらい組織的に対応する必要がある。 出典: この記事は From $5 Attacks to Botnet-Powered Platforms: Inside the DDoS-as-a- Service Market の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

セキュリティ企業Push Securityは、ChatGPTのコンテンツ共有機能（chatgpt.com/s/）を悪用して偽のOpenAI障害ページを表示し、マルウェアをChatGPTデスクトップアプリに偽装して配布する「LLMShare」キャンペーンを発見した。 攻撃の仕組み — 正規ドメインを盾にした新手のフィッシング 攻撃者はGoogle広告経由でChatGPTを検索するユーザーをchatgpt.comの正規共有リンクへ誘導する。リンクを開くと、チャット会話ではなく「ただいまアクセスが集中しています。ウェブ版は一時的にご利用いただけません。デスクトップアプリをダウンロードしてください」という障害通知が表示される。 驚くべきは、この偽通知がChatGPT自身のHTMLレンダリング機能を使って生成されている点だ。攻撃者はカスタムHTMLとCSSをChatGPTのプロンプトでレンダリングし、それをchatgpt.com/s/リンクとして公開した。ユーザーのブラウザには「chatgpt.com」という正規URLが表示されている。 Push Securityによれば、ページには「コードを表示」「ChatGPTでリミックス」というコントロールが含まれており、コードを確認すれば偽物と判断できる。しかし、一般ユーザーがそこまで確認するケースはほぼない。 ダウンロード先でも二段構えの偽装 「ダウンロード」ボタンをクリックすると、openew[.]appというOpenAIを模したサイトに誘導される。このサイトはクローキング技術を採用しており、URLScanなどのセキュリティスキャンツールからアクセスした場合は無害なAR/VRサービスのページを表示する。ターゲットにのみマルウェアを見せる巧妙な設計だ。 macOS版とWindows版の両方が用意されており、Windows版はAny.Runでの分析で仮想マシン検出コマンドを実行することが確認されている。最終的なペイロードは不明だが、同様の手口を使った過去のキャンペーンではインフォスティーラーが配布されていた。 Claude Artifactsも同様の手口で悪用 Push Securityは、AnthropicのClaude Artifactsも同様に悪用されていることを確認している。こちらはClickFixスタイルの攻撃で、レンダリングされたアプリを使ってユーザーに悪意あるコマンドを実行させる手口だ。 AI共有機能の悪用は今回が初めてではない。今年初めにはClaudeのダウンロードを検索するユーザーをGoogle広告経由で悪意ある共有チャットに誘導する攻撃も確認されており、ChatGPT・Grok・Claude Artifactsと、AIプラットフォームの共有機能全体が攻撃ベクターとして定着しつつある。 実務への影響 — IT管理者とエンドユーザーへの注意点 エンドユーザーへ: ChatGPTをはじめとするAIツールのダウンロードは、必ず公式サイト（openai.com）から直接行う Google広告経由でAIツールを検索・ダウンロードしない chatgpt.com/s/ の共有リンクで障害通知やダウンロードを促す画面が表示されたら即座に離脱する IT管理者へ: DNSフィルタリングやWebプロキシでAIツールの公式ドメイン以外からのバイナリ取得をブロックするポリシーを設定する エンドポイント保護でOpenAI/Anthropic公式サイト以外からのAIツールインストールを制限する セキュリティ意識向上トレーニングで「正規URLでも安全ではない」ケースとして本件を具体例として活用する 筆者の見解 今回の手口で改めて浮き彫りになったのは、「URLの正規性≠コンテンツの安全性」という事実だ。chatgpt.comという完全に正規のドメインから偽の障害ページが配信される——従来の「URLを確認しろ」という啓発では対処できない時代に入っている。 この問題の本質は、AIプラットフォームが提供する「自由なHTMLレンダリング×公開共有リンク」という組み合わせにある。利便性のために設計された機能が、そのまま攻撃インフラに転用されている構図だ。OpenAI・Anthropicともに、共有コンテンツのレンダリング範囲や用途制限について早急に対策を講じる必要がある。 エンタープライズ環境では、AIプラットフォームへのアクセスを「禁止」するのではなく、公式ルートのみを通じてアクセスできる仕組みを整備することが重要だ。禁止アプローチは必ず迂回される。社員が正規の手段でもっとも便利に使える環境を作ることが、結果として攻撃面を狭めることにつながる。 AIツールの急速な普及とともに、こうした攻撃はさらに巧妙化・多様化するだろう。「ChatGPTが落ちているからアプリをダウンロードする」という行動は、AIを日常的に使うユーザーにとって自然な流れだ。技術の進化に合わせたセキュリティ教育の継続的な更新が、いまもっとも急ぎ対処すべき課題の一つだと考える。 出典: この記事は ChatGPT share links abused to host fake outage pages to deliver malware の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11に残存する旧来のダイアログボックスをすべてWinUI 3で書き直すプロジェクトを進行中であることを、同社のデザイン担当パートナーディレクターMarch Rogers氏がX（旧Twitter）上で公式に認めた。すでにファイルコピーダイアログの内部刷新は完了しており、次は「コモンファイルダイアログ」が対象になっているという。 何が変わるのか Windows 11には現在でも数十年前から使われているレガシーダイアログが多数残っている。ファイル操作時に表示されるコピー・移動・削除の進捗画面、ファイルを参照する際に開くコモンファイルダイアログなどが代表例だ。これらはWin32ベースのまま放置されており、WinUI 3で統一されたモダンUIとは見た目も動作も一致しない「ちぐはぐ」な状態が長年続いてきた。 今回Rogers氏はX上で「古いダイアログをWinUI 3で書き直すリストに沿って作業を進めている。ファイルコピーダイアログはすでに完成しており、コモンファイルダイアログもリスト入りしている」と明言した。この発言は、X上のユーザーがコミュニティメンバーとMicrosoft社員を巻き込んで「Runダイアログだけでなく他のレガシーUIも更新してほしい」と訴えたスレッドへの返答として登場した。 ダークモード対応はすでに先行中 ダイアログの完全WinUI化に先駆けて、Microsoftはここ数ヶ月でレガシーダイアログへのダークモード対応を段階的に展開してきた。ダークモードを有効にした状態でファイルのコピーや移動を実行すると、従来の白背景のダイアログが暗背景に切り替わっていることに気づくはずだ。ただしこれはあくまでダークモード対応であり、UIコンポーネント自体はまだWin32のままである点に注意が必要だ。 RunダイアログについてはすでにWinUI 3版がオプションとして提供が始まっており、今回の全ダイアログ刷新はその延長線上にある取り組みだといえる。 パフォーマンスへの懸念と現状 「WinUI化で遅くなるのでは？」という懸念は理にかなっている。実際、Windows 11初期のファイルエクスプローラーをWinUI化した際には、動作の重さが批判の的になった。しかしMicrosoftは継続的な最適化を重ね、2026年5月更新を含むWindows 11 25H2世代のファイルエクスプローラーは当初とは比較にならないほど高速化されている。WinUI自体の成熟が進んだ結果であり、今後のダイアログ刷新が同様の問題を抱えるリスクは以前より低いと考えられる。 実務への影響 エンドユーザー・IT管理者向け 直近でUIが劇的に変わるわけではない。刷新は段階的に行われ、Insider Previewチャンネルで先行確認できる ダークモードを使用している環境では、すでに一部ダイアログの見た目が変わっている。操作方法は変わらないため混乱は少ないはず コモンファイルダイアログはファイルを開く・保存するほぼすべての操作に関わるため、刷新後の使い勝手の変化には注意が必要。特にアクセシビリティや自動化スクリプトとの互換性を確認しておきたい 開発者向け コモンファイルダイアログ（IFileOpenDialog / IFileSaveDialog）をWin32 APIで呼び出しているアプリケーションは、将来的にWinUI版との挙動差異が生じる可能性がある ただしMicrosoftはAPIレベルの互換性を維持する方向で進めているとみられるため、すぐに対応が必要なケースは少ないだろう 筆者の見解 Windowsの細かいUI変化を追うことの意味は薄れてきていると感じつつも、今回の取り組みはその中では評価できるものだと思う。 数十年間手つかずだったダイアログ群をモダン化しようというのは、地味だが正しい方向の投資だ。一貫性のないUIは、使う側にとっての認知的コストを積み上げる。「なぜここだけ古いの？」という細かい疑問がユーザー体験を静かに蝕む——その課題に正面から向き合う姿勢は評価したい。 ただ、率直に言えば「なぜこれがいまごろ？」という気持ちも拭えない。Windows Vistaのころから指摘されてきた統一性の欠如に、2026年になって「ようやく着手」というのは、もったいない時間の使い方だった。MicrosoftにはWinUI 3を早期に成熟させて、こうした作業をもっと早いタイミングで終わらせられるだけの技術力があったはずだ。 とはいえ、遅くても着手するより着手しないよりはるかに良い。コモンファイルダイアログのWinUI化が完成すれば、Windowsのレガシー感はかなり薄れる。Runダイアログと合わせて、「使い続けることが恥ずかしくないOS」に近づく一歩として、完成を楽しみにしている。 出典: この記事は Microsoft is killing every ancient Windows 11 dialog box with a modern rewrite, and file copy is already done の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがAzure Entra IDの認証方式に重大な変更を加えると発表した。この変更は一部のユーザーおよびIT管理者のパスワードリセット（セルフサービスパスワードリセット／SSPR）へのアクセスに直接影響を及ぼす可能性があり、対応を後回しにしていた組織は早急な確認が必要だ。 何が変わるのか Microsoftは長らく「レガシー認証ポリシー」と「統合認証メソッドポリシー」の2つを並行運用してきた。今回の変更の核心は、この2本立ての構造を統合認証メソッドポリシーへ一本化していく方向性の強化だ。 これにより影響を受ける可能性があるのは主に次の2点だ。 1. SSPRでのMFA要件の厳格化 パスワードをリセットする際に要求される本人確認レベルが引き上げられる。従来は「秘密の質問」や「メールによるコード送信」だけで通過できたケースでも、今後はより強固な認証方法（Microsoft Authenticator、FIDO2キー等）が必要になる場合がある。 2. テナント全体のポリシー管理への移行 「ユーザーごとのMFA設定」という古い管理方式から、テナント全体で一元管理する条件付きアクセス（Conditional Access）ベースのポリシーへの完全移行が加速する。レガシーなユーザーごとMFA設定に依存している環境では、移行後に意図しないアクセス制限が発生するリスクがある。 なぜこれが重要か この変更が単なる「機能アップデート」でない理由は、アイデンティティがセキュリティの中心軸となった現代の構造そのものに関わるからだ。 エンドポイントやネットワーク境界での防御が形骸化しつつある今、「誰が」「いつ」「どのような条件で」リソースにアクセスできるかを正確にコントロールすることが最重要になっている。パスワードリセットというプロセスは攻撃者にとって「アカウントを乗っ取るための合法的な入口」であり、ここに脆弱性が残ると他のゼロトラスト施策がすべて無意味化する。 MicrosoftがSSPRの認証要件を引き締める方向性は、この文脈で理解する必要がある。 実務への影響と対応ポイント 日本のIT管理者・エンジニアが確認すべき事項を整理する。 即時確認事項 Entra ID管理センター → 認証方法 → 統合認証メソッドポリシーと従来のSSPR設定の現状把握 「ユーザーごとのMFA」が有効になっているアカウントの洗い出し（これがレガシー設定に依存している可能性が高い） SSPR登録状況レポートの確認（未登録ユーザーへの事前周知が必須） 移行時の注意点 ヘルプデスクへのリセット依頼が一時的に急増する可能性がある。変更前にコミュニケーション計画を立てること 条件付きアクセスポリシーのテストはレポートのみモードで必ず事前検証する 特権アカウント（グローバル管理者等）はSSPRではなくPrivileged Identity Management（PIM）との連携で管理するのが正解 特にハイブリッド環境（AD + Entra ID）への注意 オンプレミスのActive DirectoryとEntra IDをハイブリッド同期している環境では、パスワードライトバックの設定が影響を受ける場合がある。Entra ConnectまたはCloud Syncの設定も合わせて確認しておくこと。 筆者の見解 この方向性は正しい。パスワードリセットという「認証の抜け穴」を塞ぐのは、ゼロトラスト実装において避けて通れない作業だ。 問題は「変更の方向性」ではなく「移行の複雑さ」にある。日本の大規模エンタープライズ環境では、何年もかけて積み上げた複雑なレガシー設定が混在していることが多い。統合ポリシーへの移行は技術的には正しくても、現場への影響調査と段階的な移行計画なしに進めると「突然ログインできなくなった」というインシデントに直結する。 Microsoftには、こういった破壊的変更をするなら移行ツールの充実と猶予期間の明確化をセットで提供してほしい。実力のある製品だからこそ、現場を混乱させずに進化できるはずだ。管理者が振り回されるような変更の出し方は、せっかくの技術的な正しさを台無しにする。 まずはEntra ID管理センターの「認証方法」セクションを今すぐ開いて現状確認することから始めよう。後回しにしていいタスクではない。 出典: この記事は Microsoft is making a major change to Entra ID authentication の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年7月13日、macOSおよびiOS向けの「Office 2019 for Mac」「Office 2021 for Mac」を、ファイルの閲覧しかできない「閲覧専用モード（Reduced Functionality Mode）」に自動移行させることを確認している。一時購入（永続ライセンス）製品を対象とした今回の措置は、証明書の有効期限切れを技術的トリガーとしており、対象バージョンにアップデートしていないユーザーは7月13日以降、ファイルの編集・保存が一切できなくなる。 何が起きるのか——証明書失効という技術的トリガー Microsoft 365アプリ群はライセンス検証に電子証明書を使用している。この証明書が2026年7月13日に失効する。証明書更新済みの最低バージョン（macOS版は16.83、iOS版は2.93）に更新されているアプリは正常動作を継続するが、古いバージョンのまま使い続けている場合は、失効後すぐに「Reduced Functionality Mode」——ファイルの開閲覧のみ許可、編集・保存は不可——に入る。 なお、macOS側の最低要件はmacOS 12（Monterey）以降だ。macOS 11（Big Sur）以前のMacを使い続けているユーザーは、OSのアップグレードなしには対象バージョンへの更新自体ができない点にも注意が必要だ。 「使い続けられる」公約の削除——Microsoftが公式ページを書き換えた この件をより問題にしているのが、Microsoftによる公式サポートページの事後書き換えだ。 2023年4月に公開され、6月3日時点のInternet Archiveが保存したページには、次の文言があった: 「Office 2019 for Macのサポートは2023年10月10日に終了します。すべてのOffice 2019アプリは引き続き機能し続けることをご安心ください——Macからアプリがなくなることもなければ、データが失われることもありません」 ところが、2026年5月30日時点の同じURLには「May 15th, 2026」という新しい公開日付が付けられ、「continue to function（引き続き機能し続ける）」という記述が静かに削除されていた。代わりに「Microsoft 365またはOfficeのサポート対象製品からデータにアクセスできます」という文言が追加されており、サブスクリプション製品への誘導内容に変わっている。 Internet Archiveのキャプチャによってこの書き換えが発覚し、サンフランシスコのITコンサルティング企業「JimmyTech」が「Microsoftが約束を破った」と指摘。Hacker Newsでも大きな反響を呼んだ（ポイント458、コメント140件）。 対象ユーザーと今すぐ確認すべきこと 影響を受ける可能性があるのは、次の条件を満たすユーザーだ: Office 2019 for Mac または Office 2021 for Mac を永続ライセンスで購入済み アプリのバージョンが macOS版 16.83 未満（または iOS版 2.93 未満） macOS 12（Monterey）以降を使用中 今すぐ確認する手順: Word/Excel/PowerPointを開き、「Word」メニュー →「Wordについて」でバージョンを確認 バージョンが16.83以上であれば問題なし 16.83未満の場合は「ヘルプ」→「更新プログラムの確認」で最新版に更新する macOS 11以前のままでアップグレードが難しい環境では、Microsoft 365へのサブスクリプション移行を検討するか、LibreOfficeやGoogle Workspaceなどの代替手段を早めに評価しておくことを強くお勧めする。 実務への影響 法人利用のMac環境: Microsoft 365への移行が進んでいない部署、あるいはネットワーク制限でアップデートが制限されている環境では、7月13日に突然「編集できなくなった」という問い合わせが殺到するリスクがある。今のうちに資産管理ツールでOfficeのバージョン一覧を取得し、アップデートの適用状況を確認しておくべきだ。7月13日まであと6週間程度しかない。 ...