Windows

AlmaLinux Projectは、エンタープライズ向けLinuxディストリビューション「AlmaLinux」のバージョン10.2を正式リリースした。デスクトップ環境GNOME 49の採用、i686（32ビット）ユーザースペースパッケージの提供、コンパイラツールセットとデータベースパッケージの更新、そしてセキュリティ改善が主な変更点となっている。 AlmaLinuxとは——CentOS消滅後の「本命」プレイヤー AlmaLinuxは、Red HatがCentOSをCentOS Streamへ転換した2021年以降、企業向けLinux環境の有力な代替として急速に普及したディストリビューションだ。Red Hat Enterprise Linux（RHEL）との高いバイナリ互換性を維持しながら無償で提供されており、日本国内でもオンプレミスサーバーやクラウドVMの基盤OSとして採用が広がっている。バージョン10系はRHEL 10をベースとした最新ラインであり、今回の10.2はその安定マイナーアップデートにあたる。 主要な新機能・変更点 GNOME 49の採用 デスクトップ環境として最新のGNOME 49が搭載された。GNOMEはEnterpriseディストリビューションにおいても標準的なGUIとして利用されており、Wayland対応の成熟やアクセシビリティ機能の強化が進んでいる。サーバー環境では関係ないと思われがちだが、開発用ワークステーションや管理端末として使用するケースでは恩恵が大きい。 i686ユーザースペースパッケージの提供 32ビット（i686）向けのユーザースペースパッケージが利用可能になった。64ビット環境が主流となった現在でも、古いライブラリへの依存を持つ業務アプリケーションや組み込み連携ツールが存在する。こうしたレガシーソフトウェアとの互換性維持が求められる現場にとっては実用的な対応だ。 コンパイラ・データベースパッケージの更新 GCC等のコンパイラツールセットおよびPostgreSQL・MySQLなどのデータベースパッケージが最新版に更新された。Enterpriseディストリビューションはバージョン固定による安定性を優先する設計だが、マイナーリリースのタイミングで主要パッケージの刷新が行われるのは開発者・運用者にとって歓迎される変化だ。 セキュリティの改善 リリースノートでは「改善されたセキュリティ」が明記されている。具体的なCVE対応やカーネルレベルの変更については公式のリリースノートを精査する必要があるが、Enterpriseディストリビューションにおけるセキュリティアップデートは迅速な適用が原則だ。 実務への影響——日本のIT現場でどう動くか CentOS移行を済ませていないなら今すぐ動け　2024年にEOLを迎えたCentOS 7のサポート延長に依存しているシステムが日本国内にはまだ多数存在する。AlmaLinux 10.2はその移行先の有力候補の一つだ。Rocky LinuxやOracle Linuxとの比較検討を含め、自社のRHELバイナリ互換要件と照らし合わせて選択する価値がある。 コンテナ基盤OSとしても有効　AlmaLinuxはコンテナイメージとしてもDockerHub等で配布されており、RHEL互換の実行環境をコスト最小化で構築したい場合に採用しやすい。Podmanとの組み合わせによるRoot-lessコンテナ運用も実績が積み上がっている。 i686サポートはレガシー資産の棚卸し機会　32ビット互換パッケージが提供されるとはいえ、依存しているアーキテクチャと向き合う機会として活用したい。このアップデートを機に「いつまでi686に依存するか」を組織内で議論するきっかけにできる。 筆者の見解 AlmaLinuxはここ数年、安定したリリースサイクルと活発なコミュニティ運営によって信頼性を着実に積み上げてきた。今回の10.2も、派手さはないが「エンタープライズOSとして当然やるべきことを着実にやっている」リリースだと評価できる。 筆者が重要だと感じるのは、i686サポートの追加ではなく、それを「やらなかった選択肢もあった中であえて提供した」という姿勢だ。後方互換性の維持はコストを伴う。それを継続するということは、レガシー資産を抱えた現場を見捨てないという意思表示でもある。 エンタープライズLinux市場は今、RHEL・AlmaLinux・Rocky Linux・Ubuntu LTSが実質的な四強を形成しているが、日本では「とりあえずCentOSだった」という慣性がまだ引力を持っている。2026年という今このタイミングで動かなければ、次の更新機会は数年後になる。AlmaLinux 10.2のリリースは、そろそろ本腰を入れた移行計画を立てるための良い節目になるだろう。 出典: この記事は AlmaLinux 10.2 released with GNOME 49, i686 userspace packages and more. の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftのセキュリティリサーチチームがGPU搭載の高性能マシンを狙った精巧なクリプトジャッキングキャンペーンを発見した。SEOポイズニングによる検索順位の操作だけでなく、ChatGPTなどAIチャットボットの回答そのものを悪意あるダウンロードリンクで汚染するという新たな手口が確認されている。 「GPU持ちユーザー」を正確に狙い撃ちする入口 攻撃者が悪用するのは、高性能PCユーザーが日常的に使うユーティリティソフトのダウンロードページだ。具体的な標的となったソフトウェアは以下の通り： CrystalDiskInfo（ストレージ情報確認ツール） HWMonitor（ハードウェア監視ツール） Display Driver Uninstaller（GPUドライバー削除ツール） FurMark（GPUベンチマーク） K-Lite Codec Pack（マルチメディアコーデック） PDFgear（PDFツール） このラインナップは偶然ではない。ゲーマー、PC自作ユーザー、動画制作者、つまり「GPUを搭載したマシンを持っている人」が使うツールを意図的に選んでいる。攻撃者はマイニング収益を最大化するため、最初から高スペックマシンの持ち主を狙い撃ちにしている。 新たな攻撃ベクター：AIチャットボットの回答汚染 従来型のSEOポイズニングに加え、今回のキャンペーンで特筆すべき点がある。AIチャットボットへの質問に対する生成回答の中に、攻撃者が制御するドメインへのリンクが含まれていたという事例が報告されていることだ。 Microsoftの報告によれば、「ソフトウェアのダウンロード先を質問したユーザーが、AIアシスタントの回答内で悪意あるドメインを提示された」という。ユーザーは「AIに確認したから安全だ」という心理的バイアスを持ちやすく、検索結果よりも回答を盲信しやすい。この認知的盲点が新たな攻撃面として機能している。 感染後の攻撃チェーン：6重の永続化とプロセスホロウイング 悪意あるZIPファイルを実行すると、以下のステップで侵害が進行する。 Step 1：正規ツール＋悪意DLLの同梱 ZIPアーカイブには正規のユーティリティ実行ファイルと、その起動時に自動ロードされる悪意あるDLLが一緒に含まれている。ユーザーには正規ツールが動作して見えるため、感染を自覚しにくい構造だ。 Step 2：ScreenConnectによる永続的なリモートアクセス 悪意あるDLLはmsiexec.exeを通じて正規のリモート管理ツール「ScreenConnect」をインストールする。これにより攻撃者はいつでも被害マシンに接続できる状態が確立される。 Step 3：SimpleRunPE.exeによる6重の永続化 攻撃者はScreenConnect経由でSimpleRunPE.exeを投下する。このバイナリはWindowsの複数の自動起動ポイントに自身を登録し、さらに人気VLCプレイヤーを偽装したvlc.exeとしてコピーを作成する。 Step 4：Microsoft署名バイナリへのプロセスホロウイング マルウェアはInstallUtil.exe、MSBuild.exe、RegAsm.exe、RegSvcs.exeなどMicrosoftが正規署名したWindowsシステムバイナリのプロセスに自身を注入する。正規プロセスの皮を被ることで、セキュリティツールによる検出を回避する。 Step 5：多層的な検出回避 仮想マシン環境を検出すると実行を停止 40種類のセキュリティ解析ツールのプロセスを監視 Microsoft Defenderの除外リストに自身のパスを追加してAVスキャンを無効化 Step 6：GPU マイニングの実行 最終的にgminer、lolMiner、SRBMiner-MULTIのいずれかがダウンロード・実行される。いずれもGPUを活用した暗号資産マイニングソフトだ。 「量より質」の標的型設計 Microsoftはこのキャンペーンの設計思想として、「感染台数の最大化ではなく、1台あたりのGPUマイニング収益の最大化を目的とした精緻な設計」であると指摘している。GPU搭載マシンを的確に選別し、長期間にわたって確実にマイニングさせるためのメカニズムが多層的に組み込まれている。 実務への影響：日本のエンジニア・IT管理者へ 個人ユーザー・エンジニア向け： ユーティリティソフトのダウンロードは必ず公式サイトまたは公式GitHubリポジトリから直接行う。検索上位であることは安全の証明にならない AIチャットボットが提示するダウンロードリンクも例外ではない。必ずドメインを確認し、公式サイトと一致しているかを検証する ダウンロードしたZIPを展開する前に、含まれるファイル一覧を確認する。実行ファイルと無関係なDLLが同梱されていれば危険信号だ IT管理者・セキュリティ担当向け： ScreenConnectなどのリモート管理ツールの無許可インストールを検出・ブロックするポリシーを整備する msiexec.exeを経由した未知パッケージのインストールをSIEM/EDRでログ監視する Microsoftのレポートに含まれるIoC（侵害指標）をエンドポイント保護ソリューションに取り込む 高性能GPU搭載ワークステーションのGPU使用率を定常的に監視する（マイニングは高負荷が続く） 筆者の見解 今回の攻撃で最も注目すべきは、AIチャットボットが悪意あるリンクの配布経路として機能したという点だ。 SEOポイズニングは古典的な手口だが、AIの回答汚染は新しいフロンティアだ。「AIに確認したから安全」という感覚的な信頼が、まさにその脆弱性になってしまっている。攻撃者がこの心理的バイアスを狙っているとすれば、今後もこの手口は洗練されていくと考えるのが自然だ。 この脅威を発見・公開したのがMicrosoftのセキュリティリサーチチームであることは、素直に評価したい。Defender for Endpointをはじめとするエンドポイント保護の積み上げが、こうした発見につながっている。 ただひとつ言えるとすれば、AIが生成したリンクの安全性を担保する仕組みは業界全体でまだ十分に整備されていない。「AIが言ったから正しい」は、もはや通用しない時代に入っている。ゼロトラストは人間の認知にも適用すべき原則だ。AI の回答も、ダウンロードリンクも、「信頼しない、必ず検証する」という姿勢は変わらない。 出典: この記事は GPU mining malware spreads via SEO poisoning, AI chatbots の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftがSnapdragon X2搭載版Surface ProおよびSurface Laptopの2026年内発売を正式に確認した。ただし先行したのはIntel搭載のビジネス向けモデル（Surface Pro 12・Surface Laptop 8）であり、Snapdragon X2搭載コンシューマーモデルの具体的な発売時期は現時点でも未定のままだ。 先行発売されたのはIntel搭載ビジネスモデル 2026年5月、MicrosoftはSurface Pro 12とSurface Laptop 8をビジネス向けに発売開始した。価格はSurface Pro 12が1,499ドル〜、Surface Laptop 8が1,949.99ドル〜と、企業調達を強く意識したプレミアム価格帯に設定されている。 このラインナップは企業のIT管理部門・調達チームを直接の対象としており、コンシューマー市場への訴求は後回しにした構成だ。Microsoftは2026年4月に一度Surface製品の価格を引き上げており、今回のビジネス向けモデルはその改定後の新ラインナップとして位置づけられる。 Snapdragon X2が搭載される意味 Qualcomm製Snapdragon X2は、前世代Snapdragon XシリーズよりもさらにAI処理性能（NPU）とCPU効率が向上しており、Windows on Armエコシステムの本格拡大を牽引する中核チップだ。 Snapdragon X2搭載モデルにはOLEDディスプレイや触覚フィードバック（ハプティクス）の強化が搭載される可能性も報じられており、単なるチップ換装にとどまらないリフレッシュになるとの見方もある。バッテリー駆動時間や軽量化という点でもARMアーキテクチャの優位性は大きく、ビジネス用途でのモバイルワーク効率向上に直結する。 課題：コンシューマー向けの発売時期が全く見えない 最大の問題はタイミングの不透明さだ。MicrosoftはGizmodoの取材に対し「コンシューマー向けについては共有できる情報がない」と回答しており、具体的な月・予約開始時期・店頭在庫の確保時期について一切開示されていない。 一方、競合他社はすでに動いている。ASUSはSnapdragon X2搭載のZenBook A16をプレミアムARMラップトップ市場に投入済みであり、LenovoもARM製品の展開を加速させている。Microsoftがコンシューマー向けの発売を後ろ倒しにしている間に、競合が価格と利用体験の期待値を定めてしまうリスクは無視できない。 実務への影響：日本のIT管理者・エンジニアへ 企業IT担当者へ: Surface Pro 12・Surface Laptop 8はすでに調達可能な状態だ。IntelベースのためWindowsアプリケーション資産との互換性は最大限に確保されており、Microsoft Intuneをはじめとする既存管理ツールとの統合もそのまま使える。急ぎの端末調達が必要な場合は、今のIntelモデルを選ぶのが現実解だ。 エンジニア・開発者へ: Windows on Arm対応は着実に改善されているが、社内ツールやレガシーアプリがArmネイティブで動作するかの検証は依然として必要だ。Snapdragon X2搭載モデルを待つ場合は、2026年後半以降を見込んでおくのが無難だろう。 調達計画の立て方: 「年内に出る」という約束だけを根拠に調達を先延ばしにするのはリスクが高い。ビジネス要件が明確であれば現行Intelモデルで進め、Snapdragon X2モデルは次期調達サイクルで検討するというアプローチが現実的だ。 筆者の見解 SurfaceはWindowsエコシステムのリファレンスハードウェアとして、「こう使うべき」の手本を示す重要な役割を担っている。ビジネスモデル先行という判断自体は理解できる。調達サイクルが明確な企業顧客を最初に押さえるのは合理的な戦略だ。 ただ、Snapdragon X2コンシューマーモデルの発売時期が「2026年内のどこか」という粒度の情報しかない点は、もったいないと感じる。ASUSやLenovoがすでに市場に製品を並べている中で、リファレンス端末メーカーとしての存在感を示す絶好のタイミングが過ぎていく。 MicrosoftにはWindows on ArmとSnapdragon X2の組み合わせを本物のゲームチェンジャーにできる力がある。Surface ProがモバイルとPCの境界を再定義する製品になれるかどうか、コンシューマー向けの続報に期待したい。 出典: この記事は Microsoft confirms Snapdragon X2 Surface launch for 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月22日、Windows 11 Insider Programの大規模な再編を実施し、次期メジャーリリース「26H1」向けの実験的機能を含むビルド28020.2149を新設した「Experimentalチャンネル」で公開した。 Windows Insider Programの新チャンネル体制 従来のInsider Programは「Dev」「Canary」「Beta」「Release Preview」の4チャンネルで構成されていたが、Microsoftは2026年2月の予告通りに3チャンネルへ整理した。 Experimental: DevとCanaryを統合した新チャンネル。最先端の実験的コードや、正式リリースに含まれない可能性のある機能を2週間ごとに配布 Beta: 今後の機能アップデートを早期検証するための場。月1回程度の配布リズムに変更 Release Preview: Patch Tuesdayのタイミングに合わせてリリースされる、ほぼ安定版に近いビルド Microsoftのプログラムマネージャーは「Windowsの実際のビルド手法に合わせてInsiderプログラムを再構築している。Experimentalチャンネルにより、特定のリリースに縛られることなくプラットフォームのイノベーションをテストできる」と説明している。 ビルド28020.2149の注目機能 今回公開されたビルドには、将来のWindowsの方向性を示す2つの実験的機能が含まれている。 クラウド対応ファイルシステム（Cloud Aware Files） Windows Explorerに「Cloud Aware Files」と呼ばれる新しいオプションパネルが追加された。ローカルにキャッシュされたクラウドファイルの同期状態を詳細に表示し、右クリックメニューから「スケジュールダウンロード」や「指定日までオフラインで保持」といった粒度の細かい制御が可能になる。 まだ実験段階でクラッシュも発生するとのことだが、WindowsがクラウドストレージをOSネイティブの「一等市民」として扱う方向への明確なシフトを示している。 モジュラーデスクトップ「Fluid Shell」 内部プロジェクト「Fluid Shell」が初めて公開ビルドに登場した。デフォルトでは無効だが、ViveToolで隠し機能フラグを有効化することで、タスクバーやスタートメニューをフローティングパネルとして独立させた「合成可能なデスクトップ」を体験できる。従来のデスクトップとウィジェットボードのハイブリッドとも言える新しいUI体験だ。 実務への影響 IT管理者・エンジニア向け すぐに飛びつかなくてOK。Experimentalチャンネルは文字通り「実験場」であり、搭載された機能が最終製品に含まれる保証はない。本番環境に近いシステムを管理している場合は、Beta以上のチャンネルには近づかないのが賢明だ。 ただし、2〜3ヶ月後の動向を把握する意味はある。Cloud Aware FilesやFluid Shellが正式採用された場合、エンタープライズのファイルサーバー移行計画やデスクトップ展開ポリシーに影響を与える可能性がある。特にOneDrive Known Folder Moveやファイルサーバー移行を計画中の組織は、Cloud Aware Filesの進捗を注視する価値があるだろう。 開発者向け Fluid Shellに代表されるモジュラーなUI設計は、Windowsアプリ開発のあり方にも影響しうる。WinUI 3やWinAppSDKとの統合がどう進むかは未知数だが、将来的なアダプティブUI対応が求められるシナリオを想定しておくと良いだろう。 筆者の見解 Windows Insiderの動向を細かく追うことの価値は、以前より薄れているのが正直なところだ。しかし今回の再編は少し違う意味合いを持つと感じている。 3チャンネルへの整理は「Insiderプログラムの複雑さを解消する」という表向きの理由もあるが、それ以上にMicrosoftが「次世代Windows」の開発を本格化させているシグナルとして読める。Dev/Canaryの廃止は、これまでの細切れなフィードバック収集から「プラットフォーム全体の方向性検証」へのシフトとも言えるからだ。 Cloud Aware Filesは、「OneDriveのファイルが消えた」という根強い誤解——その多くはオフライン状態の管理不備が原因——を解消するアプローチとして理にかなっている。OSレベルで同期状態を可視化・制御できるようになれば、ユーザーの混乱も大幅に減るはずだ。 Fluid Shellについては、「また新しいUIか」という気持ちが正直なところではある。ただ、WindowsがPC・大型ディスプレイ・AR/VRデバイスなど多様なフォームファクターで動く未来を見据えると、モノリシックなデスクトップを脱却することは避けられない。コンポーザブルなシェルというコンセプト自体は正しい方向だと思う。Microsoftにはそれを形にできる技術力があるのだから、中途半端に終わらせずにやりきってほしい。 まだ「見せてもらった機能」に過ぎない段階だが、2026年後半の展開を見守りたい。 出典: この記事は Windows 11 May 22 Insider Builds: New Insider Channels, 26H1 & Future Platforms の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

カリフォルニア州議会が新法案「AB 1856」を推進している。これはLinuxをはじめとするオープンソースプロジェクトを、物議を醸している州の年齢確認法の適用対象から除外することを目的としたものだ。 何が問題になっているのか カリフォルニア州では未成年者保護を目的としたオンラインプラットフォームへの年齢確認義務化が進んでいる。この動き自体は理解できる政策意図があるが、法律の文言次第ではソフトウェアリポジトリや技術ドキュメント配布サイトまで対象に含まれてしまう可能性があった。 Linuxカーネルのソースコードを配布するサーバーや、各種オープンソースプロジェクトのホスティングサービスが年齢確認を求められる事態になれば、世界中の開発者が日常的に使うインフラへのアクセスに新たな摩擦が生じる。エンタープライズ環境でLinuxを活用している企業のエンジニアや、OSS開発に参加しているコントリビューターにとっては、本質的には関係のないコンプライアンス対応コストが突然発生することを意味する。 AB 1856 が目指すもの 新法案AB 1856は、こうした懸念に対処するため、OSSプロジェクトを年齢確認義務の例外とすることを明示的に規定しようとしている。Linuxのような基盤的なソフトウェアや、広く利用される開発ツール群が「有害コンテンツを配布するプラットフォーム」と同列に扱われないよう、立法レベルで保護線を引く試みだ。 オープンソースコミュニティ側からは以前より「年齢確認法が技術インフラに誤って適用されれば、開発者エコシステム全体に悪影響が及ぶ」という懸念が表明されていた。AB 1856はその声に応える形で提出されている。 実務への影響：日本のエンジニアが今知っておくべきこと 一見、日本のエンジニアには直接関係ない話に見えるかもしれない。しかし実際は無視できない問題だ。 OSSホスティングへのアクセス制限リスク：GitHub、GitLabを含む多くのプラットフォームがカリフォルニア州に拠点を置いている。法律の適用範囲が曖昧なまま運用されれば、これらのサービスが「念のため」年齢確認機能を全ユーザーに適用する可能性もゼロではない。 規制の連鎖波及：カリフォルニア州の立法動向は、他州や他国の規制設計に影響を与えることが多い。日本でも将来的に類似する議論が起きた際の先例として注目する価値がある。 エンタープライズLinux環境：Red Hat Enterprise LinuxやUbuntu ServerなどをオンプレまたはAzure上で動かしている環境では、ディストリビューターやパッケージリポジトリへのアクセスが何らかの制約を受ける事態は避けたい。AB 1856の成否は、こうしたサプライチェーンの安定性に遠回りで影響する。 当面の実践的対応：CI/CDパイプラインでOSSパッケージを直接外部リポジトリから取得している場合、プライベートミラーやキャッシュレイヤーを設けることで依存リスクを下げられる。これは法律問題とは無関係に、可用性・セキュリティ観点からも推奨される構成だ。 筆者の見解 法律の書き方ひとつで、日常的な開発インフラが規制の対象に巻き込まれる——今回の問題はその典型だ。未成年保護という目的自体に異論はないが、「プラットフォーム」の定義を広く取りすぎると、保護とは無関係な技術インフラまで不必要なコストを負う。 AB 1856のような除外規定を明示的に設けようとする動きは正しい方向性だと思う。技術的な実態を理解した上で立法しないと、善意の法律が想定外の場所でエンジニアの仕事の邪魔をする結果になる。 道のド真ん中を歩く観点から言えば、OSSインフラへの依存はもはや企業システムの前提条件だ。それが規制上のグレーゾーンに置かれている状況は、アーキテクチャ設計の観点からもリスク要因として認識しておくべきだろう。法案の行方にかかわらず、外部依存の冗長化は日頃から仕込んでおきたい。 出典: この記事は California lawmakers push new bill to exempt open-source projects from age verification law の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Copilot Studioの2026年5月アップデートで、PCやWebアプリをAIが自律的に操作する「Computer-using agents」が正式リリース（GA）となった。同時に、エージェント型自動化を一元管理する新ビジュアルワークフローデザイナーとリアルタイム音声機能も発表されている。 Computer-using agentsとは何か 従来の業務自動化ツールはAPIの存在を前提としていた。データ連携にはAPIエンドポイントが必要で、レガシーシステムや外部ベンダーポータルなどAPIを持たないシステムは、手動対応か脆弱なスクリプト頼みになりがちだった。 Copilot StudioのComputer-using agentsはこの制約を突破するアプローチだ。AIエージェントがWebブラウザやデスクトップアプリのUIを直接操作することで、APIがないシステムへの自動化を実現する。 今回GAになったことで、エンタープライズ用途に求められる機能も強化された。具体的には以下の3点が加わっている。 認証情報の安全な管理: クレデンシャルをより安全に取り扱う仕組みを追加 モデル選択の柔軟化: 自動化シナリオに応じて最適なAIモデルを選択可能 UI変更への耐性向上: 画面レイアウトが変わっても自動化が壊れにくい堅牢性を強化 さらにプレビューとして、Computer-using agentsをマルチステップのワークフローに組み込む機能も追加された。API連携・承認フロー・ビジネスロジック・UI操作を、1つの自動化システム内で組み合わせられるようになる。 新しいビジュアルワークフローデザイナー 今回のもう一つの柱が、リデザインされたワークフロービジュアルデザイナーだ（現在はEarly Release環境で利用可能）。 従来は複数のツールやサービスをまたいで自動化ロジックを構築する必要があったが、新しいデザイナーでは統一されたキャンバス上でエンドツーエンドのワークフローを設計できる。アクション・条件分岐・AI処理ステップがビジュアルで繋がるため、複雑な業務プロセスの全体像を把握しやすくなった。 特筆すべきは「エージェントノード」の概念だ。単純なif-thenロジックでは判断しきれない状況——複数の知識ソースを参照しながら推論が必要な場面——では、ワークフロー内にエージェントノードを配置してAIに判断を委ねられる。構造化された自動化の信頼性とAIの柔軟な推論能力を組み合わせる設計思想だ。 リアルタイム音声体験 5月アップデートではリアルタイム音声体験機能も追加された。Copilot Studioで構築したエージェントを音声インターフェースで利用できるようになり、カスタマーサポートや音声操作が自然なシナリオでの活用が期待される。 実務への影響 レガシーシステムを抱える日本企業への朗報 日本のエンタープライズIT環境では、数十年前に導入した基幹システムが現役で稼働しているケースが多い。これらのシステムはAPIを持たないことが多く、デジタルトランスフォーメーションの障壁となってきた。 Computer-using agentsのGAは、こうした環境に対する現実的な自動化手段として評価できる。全面的なシステム刷新なしに、AIがUIを介して既存システムを操作できる点は大きな実用価値がある。従来RPAが担ってきた領域に対して、より柔軟で保守しやすい選択肢が加わった形だ。 明日から使える実践ポイント 自動化候補のリストアップ: APIがなくて手動対応になっている業務プロセスを洗い出す。ベンダーポータルへの定型入力作業などが典型例 ガバナンス設計を先に: UI操作型の自動化は権限範囲と監査ログの設計を事前に行う 段階的な展開: まずシンプルで繰り返し性の高いプロセスから試験導入し、実績を積んでから複雑な業務へ拡張する ハイブリッド自動化の検討: 新ビジュアルデザイナーでエージェントノードとAPI連携を組み合わせ、全体最適な自動化アーキテクチャを描く 筆者の見解 MicrosoftがCopilot Studioを「エージェント・オーケストレーター」として明確に位置づけてきた方向性は、評価できる転換だと思う。サイドバーでの補助的な会話から、業務プロセスそのものを自律的に動かすシステムへ——この移行は、AIが本当に業務価値を生み出すための必然的な進化だ。 Computer-using agentsはとりわけ日本市場での活用余地が大きい。APIを持たないレガシーシステムが大手企業に多く残っている日本の事情を考えると、この機能の登場は現実的な意味を持つ。 ただし、GAになったからといって即座に本番展開できるわけではない。UI操作型の自動化はシステム変更への感度が高く、画面構成が変わるだけで止まるリスクがある。エンタープライズ展開にあたっては、変更管理プロセスと可用性要件を事前に整理した上で、段階的に検証を重ねることを強く勧めたい。 Microsoftにはこのビジョンを実装の品質で証明してほしい。特に日本語対応と国内レガシー環境での動作安定性は、日本市場での普及を左右する重要な要素になる。技術的なロードマップは整ってきた。あとはその実力を実際の現場で見せてほしい。 出典: この記事は What’s new in Copilot Studio: May 2026 updates — Computer-using agents and real-time voice の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月、Windows 11バージョン26H1向けのプレビュー累積更新プログラム「KB5089570」をリリースした。このアップデートでは、セキュリティ強化、Copilot+ PC向けAIコンポーネントの更新、そして企業向けのストアアプリ管理機能の3つが柱となっている。 バッチファイルの「セキュア実行モード」とは何か 今回の目玉のひとつが、バッチファイル（.bat / .cmd）の実行中改ざんを防ぐ「セキュアな処理モード」の新設だ。 従来のWindows環境では、バッチファイルはテキストファイルとして逐次読み込まれながら実行されるため、実行中にファイルを書き換えることで意図しないコマンドを注入できる脆弱性が指摘されてきた。このいわゆる「TOCTOU（Time of Check to Time of Use）」問題は、ローカルでの権限昇格や、スクリプトを起点にした横展開攻撃に悪用される可能性があった。 新しいセキュア実行モードでは、バッチファイルの実行開始時にスナップショットを取り、実行中の改ざんを検知・ブロックする仕組みが導入される。企業の運用スクリプトや自動化パイプラインが多い環境では、直接的なセキュリティ向上が期待できる。 Copilot+ PC：AIコンポーネントがv1.2604.515.0に更新 Copilot+ PC向けには、以下の3つのAIコンポーネントがバージョン1.2604.515.0に更新された。 画像検索（Image Search） — ローカル画像の意味的な検索精度向上 コンテンツ抽出（Content Extraction） — 文書・画像からの情報抽出改善 意味解析（Semantic Analysis） — コンテキストに基づいた文意理解の強化 これらはいずれもNPU（ニューラル処理ユニット）を搭載した対応PCのみで動作するオンデバイスAI機能だ。特にWindows Search強化の文脈で、ローカルファイルをより直感的に探せるようになる方向性が見えてくる。 エンタープライズ向け：プリインストールStoreアプリをポリシーで削除可能に 企業のIT管理者にとって実務的に嬉しいのが、プリインストールされたMicrosoft Storeアプリをグループポリシーまたはモバイルデバイス管理（MDM）ポリシーで削除できるようになった点だ。 これまで「削除できないストアアプリ」はエンドポイント管理の現場で長年のペインポイントだった。Intune + Windows Autopilotで展開した端末でも、ゲームやエンターテイメント系のプリインストールアプリが残り続けるケースがあり、IT部門からの要望が多かった。グループポリシーレベルでのコントロールが可能になれば、ゴールデンイメージの整理や標準化が一歩進む。 日本のIT現場への影響 セキュリティチームへ: バッチファイルのセキュア実行モードは、特に製造・金融・公共系など、レガシーな自動化スクリプトが大量に稼働している環境での採用価値が高い。ただし初期はプレビュー段階であり、既存スクリプトへの互換性影響がないか検証を優先したい。 Copilot+ PCへの投資を検討中の企業へ: AIコンポーネントの更新頻度が上がっていることは、プラットフォームとして継続的に成熟していることを示している。ただし現時点ではNPU搭載機種への買い替えが前提となるため、ROIを慎重に見極めるフェーズが続く。 エンドポイント管理担当者へ: StoreアプリのMDMポリシー削除は、IntuneによるWindows管理の標準化ワークフローに組み込める。26H1の正式リリース前に、テスト環境で動作確認しておく価値がある。 筆者の見解 バッチファイルのセキュア実行モードは、地味ながら正しい方向性の改善だと感じる。スクリプトによる自動化が浸透している現代の企業環境では、「実行中のスクリプトが改ざんされうる」という前提そのものを排除していく設計思想は理にかなっている。セキュリティ的な締め付けは使いにくさに直結するケースも多いが、今回のような「実行基盤そのものを堅牢化する」アプローチは、ユーザーの操作性を損なわずに守りを固めるものとして評価したい。 Copilot+ PCのAI機能については、更新が積み重なっている点は素直に評価できる。一方で、「どう変わったのか体感できるか」というエンドユーザー目線のフィードバックが、まだ企業現場からは上がってきにくい段階だ。オンデバイスAIの真価を示すためには、目に見えるUX改善のストーリーを丁寧に伝えていくことが今後の課題になるだろう。Microsoftには、この機能がなぜ手元のPCで動くべきなのかを、もっと具体的に伝えてほしいと思う。 Storeアプリのポリシー管理は、「当然あるべき機能がようやく来た」という印象が正直なところだ。エンタープライズ展開の現場からは長年の要望だっただけに、遅すぎたとも言えるが、整備されるならそれでいい。管理の自由度が上がるほど、IntuneによるWindows標準管理の適用範囲が広がる。 KB5089570はまだプレビュー段階だ。正式リリース前に検証環境での動作確認を推奨する。「数日様子を見る勇気も立派なセキュリティ判断」という考え方は、この時期のWindows Updateに対しては特に有効だ。 出典: この記事は KB5089570 Preview for Windows 11 26H1: New PC Features, AI Updates, Enterprise Controls の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft は 2026年5月26日、Windows 11 バージョン 24H2 および 25H2 向けのオプションプレビュー累積更新プログラム KB5089573（OS ビルド 26200.8524 / 26100.8524）をリリースした。毎月末恒例の「Cプレビュー」にあたり、来月の月例パッチに先行して品質向上と新機能を試験提供するものだ。 今回の主な新機能 Bluetooth LE Audio を使った「Shared Audio」 もっとも目を引く新機能が Shared Audio だ。1台の Windows 11 PC から、Bluetooth LE Audio のブロードキャスト技術を使って2人が同時に音声を受け取れる。対応するイヤホン・ヘッドフォンを2台ペアリングしておけば、タスクバーの「クイック設定」→「Shared Audio」から開始できる。 移動中の映画鑑賞や、隣に座って一緒に音楽を聴くといったシナリオを想定している。Bluetooth LE Audio（Auracast™）はここ数年で普及が進んでおり、対応デバイスも徐々に増えている。 Task Manager に NPU 使用率列が追加 AI 処理の主役として注目される NPU（Neural Processing Unit）の使用状況が、Task Manager から直接確認できるようになった。具体的に追加されたのは以下の列だ。 プロセス・ユーザー・詳細ページ: NPU・NPU エンジン列 詳細ページ: NPU 専用メモリ・NPU 共有メモリ列 パフォーマンスページ: GPU の一部として動作するニューラルエンジンの表示 プロセス・詳細ページ: AppContainer で実行中のアプリを示す「分離（Isolation）」列 いずれも列ヘッダーを右クリックして追加する形式だ。Copilot+ PC の普及にともない、「今どのアプリが NPU をどれだけ使っているか」が運用上の関心事になりつつある。このような可視化は現場の管理者にとって地味に助かる。 マルチアプリ カメラ共有 複数のアプリが同時にカメラストリームにアクセスできる Multi-App Camera 機能が追加された。Web 会議ツールとビデオキャプチャソフトを同時に使うといった場面での利便性向上を目的としている。また、カメラが正常動作しない際のトラブルシューティング向けに機能を簡略化した「Basic Camera モード」も用意された。エンタープライズ管理者はグループポリシー（コンピュータの構成 → 管理用テンプレート → Windows コンポーネント → Camera）でモードを制御可能だ。 ...

Microsoftのパワーユーザー向けツールキット「PowerToys」に、アイドル中のユーティリティプロセスを自動終了してRAMを解放する「低メモリモード（Close apps when inactive）」が追加される見通しだ。コミュニティ開発者によるプルリクエスト（PR #47487）がMicrosoft側のレビューを経て実装に向けて進行中であり、Color Picker・Text Extractor・Advanced Paste・Peekの4ツールが初期対応予定となっている。 なぜPowerToysはRAMを食うのか PowerToysの各ユーティリティは、ホットキーを押した瞬間に即座に起動できるよう、ヘルパープロセスやUIプロセスを常時バックグラウンドで待機させている。この設計によってレスポンスは快適になる反面、実際には数時間・数日にわたってまったく使わないツールがメモリを占有し続けるという問題が生じていた。 開発者が共有したスクリーンショットによれば、PowerToys.ColorPickerUIプロセスは何もしていないアイドル状態でも200MB超のRAMを消費していることが確認されている。PowerToysの主要ユーティリティをすべて有効にしている場合、その合計は相当な数字になる。 低メモリモードの仕組み 新機能の動作はシンプルだ。設定でモードを有効にすると、対象ユーティリティは非使用時にヘルパープロセスを完全に終了する。ホットキーを押したタイミングでプロセスをオンデマンドで再起動するため、初回の起動だけわずかに遅くなるというトレードオフがある。 実装面では、共有のlow_memory_modules設定マップとヘルパーAPIが追加される。各モジュールはこのAPIを通じてアイドル終了の挙動をオプトインできる設計になっており、モジュールごとに個別のスキーマフィールドを追加する必要がない合理的な構造だ。設定の変更はPowerToysランナーがキャッシュを更新して対象モジュールを再起動することで反映される。 UI上では、PowerToysの「General Settings」タブに新しい展開セクションが追加され、葉のアイコンが表示される。これはWindows 11タスクマネージャーの「効率化モード」アイコンと意図的に統一されたデザインだ。「Enable all」でまとめて有効化することも、ツールごとに個別にトグルすることもできる。また各ツールの設定ページにも同じトグルが表示され、「使用しないときはアプリを閉じてメモリを節約します。起動が遅くなる場合があります。」という説明と注意書きが添えられる。 実務への影響 エンジニアやIT管理者がPowerToysを実務で使う場合、注目すべきポイントは以下の通りだ。 RAM 8GB環境での恩恵が大きい: 16GB以上積んでいると体感しにくいが、サブ機やVM環境では効いてくる 常用頻度で判断する: Color PickerやPeekを1日に何十回も使うなら常駐の方が快適。たまにしか使わないならオフにするメリットが高い 初回起動遅延は許容範囲内の見込み: プルリクエストのコメントを見る限り、再起動コストはホットキーを押してから数百ミリ秒程度と想定されており、実用上の問題にはなりにくい 設定はツール単位で細かく管理できる: 頻度の低いText Extractorだけ有効にして、毎日使うColor Pickerは常駐のまま、という使い方が現実的 まだマージされた段階ではなく、正式リリースのバージョンは未定だが、GitHubのレビュー進行状況を見る限り、近いうちにstableチャンネルに乗ってくる可能性は高い。 筆者の見解 PowerToysはMicrosoftのOSSコミュニティとの協調が比較的うまくいっているプロジェクトの一つだ。今回の低メモリモードも、外部コントリビューターが問題を定義してPRを出し、Microsoft側がレビューと命名を洗練させるという形でまとまっている。このサイクルは健全だと思う。 個人的には、RAMが潤沢なマシンで使っていると「そこまで困っていない」という感覚が正直なところだ。ただ、「困っていないから改善しなくていい」ではなく、こうした地道な最適化を積み重ねるのがツールの信頼性を高める。200MB超のアイドル消費は、数字として見ると確かにもったいない。 一方で、PowerToysの個々の改善に目を向けるより、WindowsとAI・自動化ツールとの統合という大きな絵の中でMicrosoftが何をやるかの方が今は気になる。PowerToysはパワーユーザーにとって手放せないツールであり続けてほしいし、そのためにはこうした使い勝手の細かい改善を続けることが正しい方向だと思う。 出典: この記事は Microsoft’s PowerToys is getting a low memory mode that kills idle utilities hogging Windows 11 RAM の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Ubiquiti（ユビキティ）は2026年5月22日、ネットワーク機器管理OS「UniFi OS」に存在する最大深刻度の脆弱性3件を含む、計5件のセキュリティ修正を公開した。いずれも認証なしのリモート攻撃者が低い攻撃複雑度で悪用できるとされており、組織内にUniFiデバイスを抱えるIT管理者は即時対応が必要だ。 今回パッチが当たった5件の脆弱性 最大深刻度（CVSS v3スコア 10.0）に分類された3件は以下のとおりだ。 CVE-2026-34908（不適切なアクセス制御）: 認証なしで対象システムに不正な変更を加えることが可能。 CVE-2026-34909（パストラバーサル）: 基盤となるシステム上のファイルに不正アクセスでき、特定のアカウントを乗っ取る経路にもなりうる。 CVE-2026-34910（コマンドインジェクション）: ネットワーク到達性を持つ攻撃者が不正なコマンドを実行できる「入力値検証の不備」に起因する。 あわせて、クリティカル（重大）相当のコマンドインジェクション（CVE-2026-33000）と高深刻度の情報漏洩（CVE-2026-34911）も修正された。5件すべては脆弱性報奨制度プラットフォーム「HackerOne」経由で報告されており、現時点では野在中（In the Wild）での悪用は確認されていないと Ubiquiti は説明している。 「約10万台」がいまもインターネットに露出 脅威インテリジェンス企業 Censys の調査によると、インターネット上に直接公開された UniFi OS エンドポイントは現在約10万台に上り、そのうち約5万台が米国に集中している。修正済みバージョンに更新された台数は不明で、今なお多数のデバイスが攻撃にさらされた状態にある可能性が高い。 UniFiシリーズは家庭用ルーターから中規模エンタープライズのネットワーク機器まで幅広く使われており、UniFi Network・UniFi Protect（カメラ監視）・UniFi Access（入退室管理）・UniFi Talk（IP電話）など多様なアプリケーションを一元管理するプラットフォームだ。これらが乗っ取られれば、物理セキュリティを含む企業インフラ全体が危険にさらされる。 Ubiquiti機器は国家支援ハッカーに狙われてきた歴史がある Ubiquiti機器はすでに犯罪集団・国家支援グループ双方の標的となってきた実績がある。2024年2月にはFBIがロシア軍参謀本部情報総局（GRU）が利用していたUbiquiti EdgeOSルーターのボットネット「Moobot」を摘発。さらに2022年にはCISA（米サイバーセキュリティ・インフラストラクチャーセキュリティ庁）がUbiquiti AirOSの古い脆弱性を「積極的に悪用されている脆弱性カタログ」に掲載し、連邦機関に3週間以内の対応を命じた経緯もある。 安価で導入しやすい反面、こうした「標的にされやすい素性」を持つ製品群であることをあらためて認識しておく必要がある。 実務への影響——IT管理者がすぐやるべきこと 1. ファームウェアを今すぐ確認・更新する UniFi OS搭載のUDM（Dream Machine）シリーズ・UDR・UNVR等を管理している場合、UniFi Network Applicationのダッシュボードから「Console Settings → Updates」でバージョンを確認し、最新版を適用すること。 2. インターネット直接公開を見直す 管理コンソールをWAN側に直接開放している構成は最もリスクが高い。VPN（UniFi自身が提供するSite Magic等）やゼロトラストベースのリモートアクセスを経由してのみ管理画面に到達できるよう設計し直すべきだ。 3. ログ監視を強化する すでに侵害されていないかを確認するため、認証ログ・ファイルアクセスログを遡って確認する。異常な管理操作・不審なファイルアクセスがないか重点的にチェックしたい。 4. Censysや Shodan で自社の露出面を確認する site:censys.io や Shodan の product:UniFi 検索で自社IPレンジにヒットがないか確認することが第一歩になる。 筆者の見解 CVSS 10.0が3件同時というのは、なかなかインパクトのある開示だ。Ubiquiti製品はコストパフォーマンスの高さと管理UIの使いやすさで、スタートアップから中堅企業まで幅広く採用されている。だからこそ、今回のパッチ適用は「後回し」にできない。 気になるのは、インターネット露出している約10万台の機器のうち、どれだけが迅速にパッチを当てられるかだ。組織内のIT管理者が自分でコントロールできる環境にあればよいが、Ubiquiti製品はSIerが導入して以降ほぼ放置、という現場も決して少なくないはず。「今動いているから大丈夫」という感覚で数年間ファームウェアを更新していない機器が、この10万台の中に相当数含まれていると考えるのが現実的だろう。 セキュリティの本質はここだと思う——パッチが出ることより、それを当てられる体制があるかどうかが問われている。管理台帳を持ち、ファームウェアアップデートの適用サイクルを回せている組織はまだ少ない。UniFiのような「安くて便利な機器」ほど、導入後の管理体制が整いにくい傾向があり、そこを突かれると痛い。 ネットワーク機器の管理画面をインターネットに直接公開することは、もう「正当な運用」とは言えない時代だ。ゼロトラストの文脈では、管理プレーンへのアクセスは信頼済みのIDが確認された経路からのみ許可するのが原則であり、UniFiの設定もその方向で見直す機会にしてほしい。 出典: この記事は Ubiquiti patches three max severity UniFi OS vulnerabilities の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年5月の月例セキュリティ更新（Patch Tuesday）において、20製品ファミリーに影響する132件のCVEを修正するパッチをリリースした。CVSS基本スコアが満点の10.0に達する脆弱性を含む29件がCritical（緊急）評価を受けており、アドバイザリを含めると今月の対処件数は300件近くに上る。 今月のパッチを数字で整理する 規模感を把握するために主要な数字をまとめておく。 項目 件数 CVE総数 132件 Critical（緊急） 29件 Important（重要） 103件 CVSS 8.0以上 43件 CVSS 10.0 1件 30日以内に悪用されると予測 13件 公開済みゼロデイ 0件 実際の悪用確認 0件 Patch Tuesday前に修正済み 14件 脆弱性の種別では特権昇格（EoP）が59件で全体の約45% を占め最多。次いでリモートコード実行（RCE）が31件で、RCEの中でも約半数がCritical評価を受けているのが今月の特徴だ。 最優先で確認すべき脆弱性 CVE-2026-41103：Microsoft SSO Plugin for Jira & Confluence 特権昇格（Critical / CVSS 9.0以上） 今月、Microsoftが「30日以内に悪用される可能性が高い」と判断した唯一のCritical脆弱性がこれだ。対象はMicrosoft製のConfluence向けSAML SSOプラグインおよびJira向けSAML SSOプラグイン。 技術的な欠陥はCWE-303（認証アルゴリズムの誤った実装）に分類される。認証処理の実装ミスにより、攻撃者はバイパス経路を使って正規ユーザーとしてログインできてしまう。SSOという性質上、一度突破されると連携先システム全体への横断が容易になる点が深刻だ。 ConfluenceとJiraは国内でも広く使われているプロジェクト管理・ナレッジ共有ツールであり、Microsoft Entra IDと連携させている環境ではこのプラグインの更新を最優先に実施すること。 CVSS 10.0の脆弱性 今月はCVSS基本スコアが満点10.0という脆弱性も存在する。これはPatch Tuesday前にすでに修正済みとして対処されたものの一つだが、スコア10.0は「認証不要・複雑な操作不要・影響範囲は完全なシステム制御」を意味する最高危険度評価だ。Patch Tuesday前のサイレント修正が行われているということは、MicrosoftがPoCや悪用の存在を把握している可能性もある。自環境への適用状況を確認する価値は十分にある。 アドバイザリ145件という別の負荷 今月はパッチ本体の132件に加えて145件のアドバイザリも発行されている。多くはMicrosoft Edgeが取り込んでいるChromeプロジェクト由来のもので、Patch Tuesday数日前に先行修正済みだ。加えてAdobe Commerceに影響する13件のアドバイザリ（Adobe発行）も含まれており、Eコマース系の基盤を持つ組織は範囲が広がる点に留意が必要だ。 日本のエンジニア・IT管理者への実務ポイント 今週中に確認すること： Jira/Confluence環境のSSOプラグイン版数確認：Microsoft製SAMLプラグインを使用している場合は即座にアップデートを計画する。内部Wikiがそのまま侵害入口になりかねない CVSS 8.0以上の43件を第一優先に絞る：132件を全て同列で追うのは現実的でない。スコアと影響製品でトリアージし、EoP × Critical の組み合わせから着手する 先行修正済み14件の適用確認：CVSS 10.0のものを含む。WindowsUpdateの自動適用タイミングによっては未適用の環境が存在する可能性がある Windows Server担当者はAppendix確認：Windows Server専用の66件のCVEリストが別途まとめられており、AMD由来のアドバイザリも含まれている パッチ適用タイミングの判断： ...

Microsoft は2026年6月に迎える Secure Boot 証明書の移行期限について、Principal Security Engineer の Ardan White 氏らが登壇した「Ask Microsoft Anything（AMA）」セッションで詳細を公式に説明した。期限を無視しても PC は引き続き動作するが、セキュリティ保護が段階的に失われていくことが明らかになった。 Secure Boot とは何か、なぜ今変わるのか Secure Boot は、PC 起動時にファームウェアが UEFI ドライバー・EFI アプリケーション・OS のブートマネージャーの暗号署名を検証するセキュリティ機構だ。2011年以来、Microsoft の証明書がこの信頼の基盤を支えてきたが、その証明書が2026年に暗号的な有効期限を迎える。 これを放置すると、BlackLotus のようなブートキットマルウェアへの脆弱性が高まる。Microsoft はこれに対応するため2023年に新しい証明書を発行し、数年かけて段階的なロールアウトを進めている。UEFI ファームウェアに直接書き込む処理が伴うため、極めてデリケートな移行作業だ。 Secure Boot の鍵階層を理解する Secure Boot は以下の鍵の階層で成り立っている： キー 役割 PK（Platform Key） OEM が所有する最上位キー。KEK へのアクセスを制御 KEK（Key Exchange Key） 署名データベースを更新するためのキー DB（Signature Database） 信頼する証明書（2011年・2023年の Microsoft 証明書）を格納 DBX（Revoked Signature Database） 失効した署名のブラックリスト。新たなマルウェアが発見されると追加される 今回の移行はこの DB と DBX をマザーボードのファームウェアに書き込む処理であり、不用意に失敗すると起動不能になりかねない繊細な操作だ。 期限を無視するとどうなるか 今回の AMA で最も重要な情報がここだ。2026年6月の期限を無視しても、Windows 11 PC は引き続き正常に起動・動作する。 しかし、セキュリティは時間をかけて段階的に劣化していく。 ...

Discordが、ARMアーキテクチャを採用したWindowsデバイス向けのネイティブクライアントを正式リリースした。QualcommのSnapdragon X Elite/Plusを搭載したPCや、旧来のSnapdragon搭載Surfaceシリーズなど、Windows on ARM（WoA）デバイスのユーザーは、エミュレーションなしでDiscordを利用できるようになる。 これまでの課題：x86エミュレーションの限界 Windows on ARMデバイスは、ネイティブARMアプリが存在しない場合、x86（またはx64）アプリをエミュレーション層を通じて実行してきた。この仕組みは互換性の面では優秀だが、いくつかの根本的な問題を抱えている。 パフォーマンスの低下: 変換処理のオーバーヘッドにより、同じハードウェアでもネイティブ実行と比べてCPU使用率が高くなる バッテリー消費の増大: 変換処理の分だけ電力消費が増え、特にモバイルデバイスでの影響が大きい 起動時間の遅延: アプリの起動にかかる時間がネイティブアプリより長くなる傾向がある Discordのような「常時起動・バックグラウンド動作」が前提のアプリでは、この差が積み重なって体感に直結する。 ネイティブ化で何が変わるか ネイティブARMアプリ化により、以下の改善が期待できる。 レスポンスの向上: 通話への参加、メッセージ送受信、画面共有の開始など、日常的な操作がよりスムーズになる。 省電力: バックグラウンドで常時動作するDiscordのCPU使用率が下がり、バッテリー持続時間の改善に直接貢献する。特にComputex 2026で注目を集めているSnapdragon搭載の薄型軽量ノートPCとの相性が良い。 安定性の向上: エミュレーション層を排除することで、特定環境でのクラッシュや動作不安定が解消される可能性がある。 実務への影響——日本のIT現場での考察 リモートワーク・ハイブリッドワークが定着した日本のIT現場では、Discordは開発チームのコミュニケーションツールとして広く使われている。特に以下のユーザーには直接的な恩恵がある。 Snapdragon X搭載PCを業務利用しているエンジニア: 2024〜2025年に登場したSnapdragon X Elite/Plus搭載のCopilot+ PCを業務メインマシンとして使っているエンジニアにとって、DiscordのネイティブARM対応は実質的な生産性向上につながる。 モバイルワーカー: 外出先でバッテリーを気にしながら作業するケースでは、省電力化の恩恵が大きい。画面共有を伴うビデオ通話が多い場合は特に効果が出やすい。 IT管理者向けのポイント: 組織でWindows on ARMデバイスを展開している場合、Discordの自動更新でネイティブ版に移行するはずだが、MDMやグループポリシーでアプリ配布を管理している環境では、更新パッケージの変更に注意が必要だ。ARM版とx64版でインストーラーが分かれている場合は展開方法の見直しが必要になることがある。 筆者の見解 Windows on ARMの普及が「実用段階」に入ったことの証左として、今回のDiscordネイティブ対応は象徴的な出来事だと思う。 少し前まで「Windows on ARMはいつ使えるようになるんだ」という印象が正直なところだった。エミュレーション頼みで動くアプリが多く、メインマシンとして使うには不安が残る状況が続いていた。しかしSnapdragon X世代の登場とComputex 2026での盛り上がりを見ると、ARMエコシステムは本格的な転換点を迎えている。 主要アプリがネイティブ対応を進めることで、「ARM版Windowsを使う理由」を探すのではなく、「x86版Windowsを使い続ける理由」を探す時代に変わっていくかもしれない。Discordのような常時起動型のコミュニケーションツールこそ、ネイティブ化の恩恵が最もわかりやすく体感できる種類のアプリだ。 Windows on ARMへの移行を検討している方には、今がよいタイミングだと思う。エコシステムの成熟度は1年前と比べて大きく改善されており、主要ツールが一つひとつネイティブ対応を果たしていく流れは今後も続くだろう。 出典: この記事は Discord is now available natively on Windows on ARM の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米連邦捜査局（FBI）は2026年5月、Microsoft 365アカウントを標的にしたフィッシングサービス「Kali365」に関する公式警告（PSA）を発出した。このサービスはOAuth 2.0のデバイスコード認証フローを悪用し、多要素認証（MFA）を回避してセッショントークンを窃取する、2026年4月に登場した新手の脅威だ。 デバイスコード認証とは何か 問題の核心にあるのは、MicrosoftのOAuth 2.0「Device Authorization Grant」フローだ。これはスマートTV、会議室システム、プリンター、IoTデバイスのように入力手段が限られた機器でも、別デバイスを使って認証を完了させるための正規の仕組みとして設計されている。 ユーザーは http://microsoft.com/devicelogin にアクセスし、画面に表示された短いコードを入力する。入力が完了すると、元のデバイスに認証が委譲される——これが正規の利用ケースだ。 問題は、この「コードを入力してもらう」という操作がフィッシングに完全に流用できることにある。 Kali365の攻撃手順 攻撃者がKali365を使って行う手口は以下の通りだ。 攻撃者自身がデバイス認証フローを開始し、コードを取得する フィッシングメールやソーシャルエンジニアリングで、被害者に「このコードを入力してください」と誘導する 被害者がコードを入力し、MFAを完了すると——攻撃者にOAuthアクセストークンが発行される 攻撃者はパスワードもMFAコードも知らないままに、被害者のMicrosoft 365環境へフルアクセスを得る この手口の巧妙な点は、被害者が「正規のMicrosoftサイトで操作を完了した」と感じたまま侵害が成立することだ。MFAが「回避された」わけではなく「正規に完了させられた」という構造が、検知を難しくしている。 セキュリティ企業Arctic Wolfの調査によれば、攻撃者は侵害後のメールボックスに悪意のある受信トレイルールを作成して痕跡を隠蔽し、一部ケースでは被害者のMicrosoft環境に新たなデバイスを登録して持続的なアクセスを確保していた。 Kali365は「ビジネス」として運営されている Kali365がいっそう危険なのは、その組織的な事業モデルにある。Arctic Wolfの調査では、製品開発を担う管理者、他の攻撃者向けにサービスを販売するリセラー、そして実際にフィッシングを実行するアフィリエイトという3層構造で運営されていることが確認されている。 サービスとして提供される機能は以下の通りだ。 AIが生成するフィッシングルアー（文体・内容を被害者に合わせて自動生成） 自動化されたキャンペーンテンプレート 被害者のリアルタイム追跡ダッシュボード トークン取得機能 Cookie Linkモード（Adversary-in-the-Middleで認証済みセッションを傍受） Telegramで流通しており、技術スキルの低い攻撃者でも高度なフィッシング攻撃が実行できる。「フィッシングの民主化」が現実のものとなっている。 実務への影響と対策 FBIが推奨する対策は以下の3点だ。 1. Conditional AccessでデバイスコードフローをブロックまたはRestrictする Microsoft Entra IDのConditional Accessポリシーで、デバイスコード認証フロー（Authentication transfer）を制限できる。業務上不要であれば完全ブロックが望ましい。 出典: この記事は FBI warns of Kali365 phishing service targeting Microsoft 365 accounts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicが開発した、プロレベルのサイバー攻撃を自動生成できる制限付きAIモデル「Claude Mythos」が、開発支援ツール「Claude Code」に統合される準備に入ったことが明らかになった。Claude Codeの内部で同モデルへの参照が確認されており、一部ユーザーは公開版で一時的に有効化トグルを目撃している。 Claude Mythosとは何か Claude Mythosは2026年4月にAnthropicが早期プレビューとして発表した、セキュリティ特化型の最先端モデルだ。同社の現フラッグシップモデルであるOpus 4.7を大幅に上回るコード推論能力と自律性を持ち、「プロレベルのサイバー攻撃を自動的に生成できる」という点が最大の特徴である。 その能力の高さゆえ、Anthropic自身が「世界のデジタルインフラに深刻なリスクをもたらす可能性がある」と警告するほどだ。FirefoxなどポピュラーなアプリケーションのN-dayおよびゼロデイ脆弱性を攻撃者が大量悪用するリスクを考慮し、強力なガードレール（安全制御システム）が整備されるまで、公開を意図的に見送ってきた。 統合の兆候と現在の状況 今回、Claude CodeおよびClaude Securityの内部にclaude-mythos-1-previewというモデルIDへの参照が確認された。また、パブリック版のClaude Codeに有効化トグルが一時表示されたことを複数のユーザーが目撃しており、公開ロールアウトの準備が具体的に進んでいることを裏付けている。 現時点では全サブスクリプションティアで利用可能になるかどうかは不明だが、段階的な提供が始まるのは時間の問題とみられる。 Glasswingプロジェクト——防御側先行の戦略 Anthropicは並行して「Glasswing（グラスウィング）」と呼ばれるプロジェクトも推進している。これはMythos Previewを活用し、世界の重要ソフトウェアの脆弱性を事前に発見・修正する取り組みで、すでに50以上の組織パートナーと連携を開始している。 成果は驚くべき規模だ。Mythosはわずか最初の1ヶ月で、高危険度〜致命的な脆弱性を1万件発見している。この数字こそが、Anthropicが公開を慎重に進めてきた最大の理由でもある。 Anthropicはその狙いをこう説明する。「短期的には攻撃者が有利になる可能性がある。しかし長期的には、AIを活用して新しいコードが出荷される前にバグを修正できる防御側が有利になる」。 実務への影響 開発者・セキュリティエンジニア Claude CodeへのMythos統合が実現すれば、コーディング中にリアルタイムで脆弱性検出が行われる環境が整う。ペネトレーションテストのコストは長年、中小企業にとって高い壁だったが、そのハードルが大きく下がる可能性がある。ただし「AIが勝手に直す」ではなく、「AIが問題を見つけ、人間が判断・対処する」という分業の前提を崩してはならない。 IT管理者・CISO 攻撃者側もAIを活用し始めている現実を直視する必要がある。Glasswingのような取り組みが示すのは、AI駆動の脆弱性スキャンが「一部の研究機関だけが使えるもの」から「SaaSとして広く利用できるもの」へ移行しつつあるということだ。防御側もAI活用の体制を今から整えておくことが求められる。 筆者の見解 率直に言えば、セキュリティの話題は細かくなりがちで得意分野とは言えないが、このClaude Mythosの話は純粋に技術的な興味を引く。 Glasswingが1ヶ月で1万件の重大脆弱性を発見したという数字は、従来の人力ペネトレーションテストとは次元が異なる話だ。これはAIによるセキュリティが「補助ツール」の段階を超え、「主戦力」になり始めていることを意味する。 Anthropicがガードレール構築に時間をかけ、Glasswingで防御側に先に能力を渡してから一般公開に踏み切ろうとしているアプローチは、「禁止するより安全に使える仕組みを作る」という考え方と合致しており、現実的だと感じる。「まず出してみて問題が出たら対処する」では済まされないレベルの技術だからこそ、この慎重さは理にかなっている。 懸念するのは、日本企業がこの変化のスピードについていけるかどうかだ。AI活用の格差がそのままセキュリティ格差に直結する時代が到来しつつある。「今動いているから大丈夫」という判断が、ますます通用しなくなってきている現実と向き合う必要がある。 出典: この記事は Anthropic’s restricted Claude Mythos model may be coming to Claude Code の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Linuxカーネルの創始者Linus Torvaldsが、AIツールで生成されたコード修正がカーネルに不必要な肥大化をもたらしているとして、最新のリリース候補（RC）フェーズで強い不満を表明した。AIコーディング支援ツールの普及が、オープンソース開発の現場に新たな課題を生み出しつつある。 何が問題になっているのか Linuxカーネル開発には世界中から膨大な数のパッチが投稿される。その中にAIツールが生成したとみられる「形式的な修正」が増えており、Torvaldsはこれを「不要なコードチャーン（code churn）」と呼んで強く批判している。 コードチャーンとは、機能上の意味を持たない変更が繰り返されることを指す。たとえば、変数名の微妙なリネーム、コメントの言い換え、スタイルの機械的な統一といった変更だ。AIツールは「何かを直した」ように見える変更を生成するのが得意だが、その変更がカーネル全体の設計思想や保守性に貢献しているかどうかは別問題である。 Linuxカーネル開発の厳しい品質基準 Linuxカーネルは世界で最も広く使われているOSカーネルであり、その品質管理は非常に厳格だ。すべてのパッチはメンテナーのレビューを経て初めてマージされる。 このレビュープロセスは人間が担っており、投稿数が増えれば増えるほどメンテナーの負担は線形以上に増大する。AIが生成した「それっぽい修正」が大量に投稿されると、本当に重要なバグ修正や機能改善を見落とすリスクが高まる。Torvaldsが懸念しているのはまさにこの点だ。 AIコーディング支援の「量産病」 AIコーディング支援ツール（GitHub Copilot、Claude Code、Cursor等）の普及により、コードを書くコストは劇的に下がった。しかしこれは同時に、「考えないコード」を大量生成するコストも下がったことを意味する。 特にオープンソースプロジェクトへの貢献文脈では、AIが提案したコードを十分に吟味せずに投稿してしまうケースが増えている。貢献実績を積もうとする開発者がAIの出力をそのままパッチとして送り、メンテナーに精査のコストを押し付ける構図だ。 Torvaldsのような経験豊富なメンテナーには、AIが生成した変更の「においがする」という感覚があるとも言われる。ロジックは通っていても、文脈を無視した変更、過剰に丁寧なコメント、本質的でない整形……これらはAI生成コードの典型的な特徴だ。 日本のIT現場への影響 Linuxカーネルの話は「自分には関係ない」と思う読者もいるかもしれないが、この問題は日本の業務システム開発にも直結する。 コードレビューのコスト増大: AIが書いたコードが社内リポジトリに大量に投入されると、レビュアーの負担が増える。表面上は動くが保守性に問題があるコードが蓄積していく。 「生成したから終わり」の誤解: AIツールはコーディングの生産性を高めるが、「生成したコードの責任を持つ」のは人間だ。AIの出力を批判的に評価するスキルが、今後のエンジニアに不可欠となる。 Pull Requestの品質管理: OSSコントリビューションはもちろん、社内開発でも「意味のある変更かどうか」を判断する文化の醸成が急務だ。 実務での活用ポイント AIの出力は「ドラフト」として扱う: AIが提案した変更を無批判にコミットしない。「なぜこの変更が必要か」を自分の言葉で説明できなければ、投稿しない チェックリストを作る: AIが生成したパッチには「この変更は機能上の意味があるか」「既存の設計方針と整合しているか」「保守コストを増やしていないか」の3点チェックを義務づける レビューガイドラインを更新する: PR（プルリクエスト）のテンプレートに「AIツールを使用したか」「どのような意図でこの変更を加えたか」を明記するフィールドを追加することを検討する コントリビュータ教育を怠らない: OSSコミュニティに参加する開発者には、AIツールの正しい使い方についてのガイドラインを周知する 筆者の見解 Torvaldsの怒りは、ある意味で「AIが本当に普及し始めた証拠」でもある。ツールが普及するほど、使いこなせない人も使い始めるのは必然だ。 個人的には、AIがコードを書くこと自体は大歓迎だと思っている。少数の設計できる人間と、実際に動かすAIという組み合わせが理想的な姿だと考えているからだ。問題はAIの出力を「自分の判断」なしにそのまま流す行為であり、それはツールの問題ではなく使い手の問題だ。 Linuxカーネルのような厳格なコミュニティが「AIコード禁止」に向かうのではなく、「AI利用者への責任基準を明確にする」方向に進んでほしい。AIを使うな、ではなく、使うなら使いこなせ——その基準をコミュニティが定義していく動きが、今後ますます重要になるはずだ。 道のド真ん中を歩くとは、新しいツールを闇雲に礼賛するでも拒絶するでもなく、「何のためのツールか」を常に問い続けることだと筆者は考えている。 出典: この記事は Linus Torvalds loses patience with AI-generated code fixes bloating the Linux kernel の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Cloud Imperium Games（CIG）が開発中のSF RPG「Star Citizen」のクラウドファンディング総額が、ついに10億ドル（約1,450億円）の大台を突破した。ゲーム史上最高額のクラウドファンディングプロジェクトとなった本作は、直近の1億ドルをわずか半年で集めており、支援者の熱量が衰えていないことを示している。 10億ドルという前人未到の金額 Star Citizenは2012年にKickstarterでの資金調達からスタートし、その後はCIGの独自プラットフォームに移行して継続的に支援者を募ってきた。当初目標の50万ドルを大幅に超えてから10年以上が経つ今、累計調達額は節目となる10億ドルを超えた。 この数字が異様な理由は、単に「大きい」からではない。通常、クラウドファンディングは製品リリース前に資金を集め、リリースとともに終了する。しかしStar Citizenは未完成のまま10年以上にわたって継続的に資金を調達し続けているという、ほかに例のないビジネスモデルを確立している点が特筆に値する。 最後の1億ドルが半年で集まったという事実は、長期間の開発遅延にもかかわらず支援コミュニティがむしろ拡大していることを示唆している。 なぜこれが重要か Star CitizenはPC向けのSFシミュレーション・RPGとして開発されており、宇宙船の操縦から惑星表面での活動まで、膨大なスケールのオープンワールドを目指している。開発の長期化と「いつ完成するのか」という批判に晒されながらも、支援者からの資金調達は止まらない。 テクノロジーの観点から見ると、このプロジェクトはゲームエンジンの限界に挑む試みとして注目に値する。Lumenによるグローバルイルミネーション、Naniteによる高密度ポリゴン処理といったリアルタイムレンダリング技術の最先端を追いながら、サーバーメッシュ技術による大規模マルチプレイヤー環境の実現を目指している。 これはゲームの話ではあるが、大規模分散処理やリアルタイムシミュレーション、ストリーミングアセットといった技術課題はエンタープライズのクラウドコンピューティングとも無縁ではない。 実務への影響——クラウドファンディングモデルの示唆 IT業界やソフトウェア開発の観点からStar Citizenが示すことがある。 継続的なコミュニティ型資金調達の可能性: 完成品を売るのではなく、開発プロセスそのものに価値を感じるコミュニティを育成することで、長期的な資金流入が可能になる。SaaSのサブスクリプションモデルと発想は近いが、より強いファン心理が土台となっている。 「未完成品でも価値がある」という逆説: 通常、ソフトウェア開発では完成度の低い状態でのリリースはリスクとされる。しかしStar Citizenは開発途上の状態を積極的に公開し、そのプロセスに参加させることでコミュニティを維持している。Early Accessモデルの極端な例として参考になる。 日本市場への示唆: 国内のゲーム・ソフトウェア企業にとって、ファンダムを活用した長期的資金調達は選択肢の一つとなりえる。ただし、これほどの規模と熱量のコミュニティを構築するには相当のブランド力と信頼が前提となる点は留意が必要だ。 筆者の見解 Star Citizenを巡る状況は、技術開発のプロセスについて根本的な問いを投げかけている。「完璧な完成品」を目指して長期間開発を続けることと、「動く状態のものを早期にリリースして改善し続けること」——どちらが正解かは文脈によるが、Star CitizenはAAAゲーム開発において前者を極限まで推し進めた事例として歴史に残るだろう。 そして10億ドルという数字は、熱量のあるコミュニティが長期間にわたって開発を支え続けられることの証明でもある。ゲームに限らず、ソフトウェア開発における「コミュニティとの共創」という考え方は今後ますます重要になっていく。 完成はいつになるのかという問いへの答えはまだない。それでも支援者が集まり続けているという事実だけは、何かを語っている。 出典: この記事は Star Citizen crowdfunding reaches $1 billion, gaining the last $100 million in six months の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Epic Gamesが次世代ゲームエンジン「Unreal Engine 6（UE6）」を正式発表し、初公開となるデモ映像を世界に向けて披露した。Unreal Engine 5（UE5）のリリースから約4年——ゲームエンジン業界に再び大きな転換点が訪れた。 UE5が変えたゲーム開発の常識 UE6を正しく評価するためには、まずUE5がもたらした革命を振り返る必要がある。2022年にリリースされたUE5は、Nanite（仮想化ジオメトリシステム）とLumen（リアルタイムグローバルイルミネーション）という2つの中核技術によって、ゲーム開発の制約を根本から塗り替えた。 Naniteはポリゴン数の上限という長年の制約を事実上消滅させ、映画品質のアセットをそのままゲームエンジンに取り込むことを可能にした。Lumenはベイク済みライトマップへの依存を排し、動的に変化する照明環境をリアルタイムで表現することを実現した。これらは「改良」ではなく、開発ワークフローそのものを再設計する「変革」だった。 加えてWorld Partitionによる巨大なオープンワールドのストリーミング管理、MetaHumanによる高品質な人物キャラクター生成ツールなど、UE5はエンジン単体にとどまらないエコシステムとして進化してきた。 UE6が示す次のビジョン Epic Gamesが公開した初映像は、UE6が単なる「UE5の改良版」ではないことを強く示唆している。前バージョンで確立されたリアルタイムレンダリングの基盤の上に、さらなる没入感・物理シミュレーション精度・AIとの融合が期待される。 ゲームエンジンにおけるAIの役割は急速に拡大しており、手続き型コンテンツ生成（PCG）の精度向上、キャラクターのリアルタイム行動生成、開発者向けのコーディング支援統合など、UE6世代でのAI活用は開発生産性に直結する領域として注目される。 実務への影響——日本のゲーム・映像制作現場にとっての意味 Unreal Engineは今やゲーム開発だけでなく、テレビ・映画のバーチャルプロダクション（インカメラVFX）、建築ビジュアライゼーション、自動車・製造業のデジタルツイン分野にも広く使われている。特に日本では映像制作・イベント演出分野でのUnreal Engine採用が加速しており、UE6へのバージョンアップは直接的な業務影響をもたらす。 エンジニア・クリエイターへの実践的ヒント： UE5プロジェクトのUE6移行パスを早期に確認し、既存アセットの互換性を把握しておく UE6のシステム要件（特にGPUメモリ・ストレージ速度）は現行世代より高くなる可能性が高いため、ハードウェア計画に織り込む Nanite・Lumenのワークフローに慣れているチームはUE6への移行障壁が低い。UE5への移行を先送りにしているスタジオは今が好機 Epic GamesのFab（旧Unreal Marketplace） のアセットエコシステムがUE6対応になるタイミングを注視する またWindowsとの連携という観点では、DirectX 12 Ultimate・DirectStorage・Mesh Shaderといったマイクロソフトが推進するPC向けグラフィクスAPIとUnreal Engineの親和性は歴史的に高く、UE6世代でもWindowsプラットフォームが最適な動作環境のひとつであり続けるだろう。 筆者の見解 ゲームエンジン市場においてEpic GamesのUnreal Engineが果たしてきた役割は、単なるツール提供にとどまらない。オープンソース化されたエンジンコードの公開、無料ティアの拡充、そしてMetaHumanやFabといったエコシステムの整備は、業界全体の底上げという意味で評価できる。 興味深いのは、Unreal Engineがゲームの外側——製造業・建築・放送——に活躍の場を広げていることだ。「リアルタイム3Dレンダリングを誰でも使える技術にする」という方向性は一貫しており、UE6がその流れをさらに加速させるか否かが注目点になる。 日本のIT現場という視点では、ゲーム会社以外でのUnreal Engine採用がまだ限定的な組織も多い。UE6の発表を機に、デジタルツインや工場可視化・プレゼンテーション制作への活用を検討してみるのも一手だ。技術の民主化という波は、ゲーム業界から静かに、しかし確実に波及してきている。 出典: この記事は Epic Games unveils Unreal Engine 6, and its first footage is here の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftの正規通知用メールアドレス「msonlineservicesteam@microsoftonline.com」が詐欺師に悪用され、偽の公式メールとして大量のスパムが送信されていることが明らかになった。スパム対策の非営利団体Spamhausの報告によれば、この問題は少なくとも数ヶ月前から継続している。 何が起きているのか 今回悪用されているメールアドレス「msonlineservicesteam@microsoftonline.com」は、本来Microsoftが二段階認証コードや重要なアカウント通知を送信するために使用している公式の送信元アドレスだ。このアドレスから届くメールは多くのユーザーが信頼しているため、フィッシング攻撃の格好の踏み台になる。 TechCrunchの記者が受信した詐欺メールは、件名が「不正取引の警告」を装ったものや、「プライベートメッセージが届いています」として怪しいURLへの誘導を試みるものだった。メール自体の作りは粗雑だが、送信元アドレスが本物であるため、メールクライアントやセキュリティフィルターを通過してしまう。 現時点では、どのような手口で詐欺師がこの送信経路を利用できているかは不明だ。ただし、Spamhausは「自動通知システムがこれほどの自由度でカスタマイズを許可するべきではない」と指摘しており、Microsoftの通知基盤における設計上の問題を示唆している。 Microsoftの対応状況 TechCrunchが問い合わせた時点では、Microsoftは問い合わせを確認するにとどまり即座のコメントを控えた。記事公開後に提供された声明では、「フィッシング報告に対し積極的に調査・対処を進めており、検知・ブロック機能をさらに強化するとともに、利用規約に違反するアカウントを削除している」とコメントしている。 SpamhausはすでにMicrosoftに問題を通知済みとのことだが、数ヶ月間にわたって問題が継続している事実は、対処の速度に疑問を投げかける。 類似事例との比較 正規のメール送信基盤が悪用されるインシデントは今回が初めてではない。2023年にはドメイン登録サービスのNamecheapが同様の手口で悪用され、フィッシングメールの送信に使われた。2026年初頭には、フィンテック企業Bettermentが利用するプラットフォームが侵害され、暗号資産詐欺のメールが送信される被害も発生している。 ソーシャルメディア上では、Microsoft以外にも複数の企業の正規アドレスが同様に悪用されているとの報告があり、業界全体の課題として認識されつつある。 実務への影響——エンジニア・管理者が取るべき行動 この問題が日本のIT現場に示す教訓は明確だ。 送信元アドレスだけで真偽を判断しない: メールのFromアドレスが正規のものであっても、フィッシングである可能性は排除できない。ユーザー教育においては「送信元アドレスが本物でも疑う」という意識付けが今まで以上に重要になった。 URLをクリックする前に公式サイトへ直接アクセス: 不正取引の警告や重要な通知を受け取った場合、メール内のリンクをクリックせず、ブラウザで直接Microsoftアカウントの管理画面を開くことを徹底する。 メールセキュリティのDMARC/DMARKIレポートを活用: Microsoft 365の管理者は、DKIMおよびDMARCレポートを定期的に確認することで、自社ドメインが同様の悪用を受けていないか監視できる。 エンドユーザー向けフィッシング訓練の見直し: 「正規アドレスからでも詐欺メールが来る」という事例を訓練に組み込むことで、既存の教育コンテンツのアップデートが必要だ。 筆者の見解 技術的な観点から見ると、今回の問題は「自動通知システムに過度な柔軟性を持たせてしまった」設計課題が根本にある。Spamhausが指摘するとおり、本来ユーザーへの重要通知のみを送るべきシステムが、外部からの入力をそのまま流せる構造になっていたとすれば、それは通知基盤の設計段階で防ぐべきリスクだ。 Microsoftほどの規模と技術力を持つ企業であれば、こうした問題を数ヶ月間放置しない体制が作れるはず——そう思うからこそ、「もったいない」という感想が正直なところだ。同社はセキュリティへの投資を大幅に増やし、Secure Future Initiative（SFI）を掲げて取り組んでいる。それだけに、こういった通知基盤の設計上の脆弱性は、早期に塞いでほしい。 ゼロトラストの観点では、今回のインシデントは「送信元の信頼性だけに依存するアーキテクチャの限界」を改めて示している。送信元IPやドメインが正規であっても、コンテンツや行動パターンを多層的に検証する仕組みが必要だ。Microsoftが声明で言及した「検知・ブロック機能の強化」が具体的にどのような実装になるのか、今後の続報に注目したい。 利用者側としては、どれほど信頼できる送信元からのメールであっても、リンクを安易にクリックしない習慣を持つことが、今の時代における基本的な自衛策だ。 出典: この記事は Scammers are abusing an internal Microsoft account to send spam links の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月から10月にかけて、WindowsのSecure Boot信頼チェーンを支えるCA証明書（Certificate Authority）を2011年版から2023年版へ段階的に切り替える計画を進めている。コンシューマー向けには影響が限定的な一方、エンタープライズ環境ではカスタムブートローダーや独自署名チェーンを持つ組織が特に注意を要する。 なぜ今、証明書を刷新するのか Secure Bootは、PCの電源投入からOSカーネル起動までの過程で「署名済みのソフトウェアのみを実行する」ことを保証するUEFIの仕組みだ。その信頼の根拠となるのがUEFI CAと呼ばれるルート証明書であり、現在市場に流通している多くのPCには2011年発行の証明書が使われている。 2011年は15年以上前だ。当時設計された暗号強度やアルゴリズムが現代の脅威モデルに対して十分かという観点から、見直しの時期を迎えている。Microsoftは2023年に次世代のSecure Boot向け証明書を準備しており、今回の移行はその本格展開にあたる。 移行スケジュールと影響範囲 発表されたタイムラインは以下の通り： 2026年6月〜: 移行フェーズ開始。Windows Update経由で2023年版証明書への信頼設定が段階的に配布される 2026年10月: 移行フェーズ完了 影響を受けにくい環境：2024年以降に製造されたPCの多くはファームウェアレベルで2023年版証明書をすでに搭載しており、自動更新の対象外となる。これらの機器のユーザーはほぼ意識しなくて良い。 影響を受ける可能性がある環境： 2023年以前製造の古いハードウェア — 2011年版証明書のみを持つ機器は、更新後に信頼チェーンの再構築が必要になるケースがある カスタムブートローダーを持つエンタープライズ環境 — 独自のPXEブート、WinPEイメージ、署名ツールチェーンを運用している組織は構成の再評価が必要 Linux + Windowsのデュアルブート構成 — GNU GRUBなど独立したブートローダーを持つ環境では、過去の移行作業でも起動不能になる事例が報告されており注意が必要 エンタープライズ向け：今すぐやるべき確認リスト 2026年6月の本番展開まで時間はまだある。今のうちに動くことで、展開後の障害リスクを大幅に減らせる。 インベントリの確認 社内の機器が2011年版・2023年版どちらの証明書を搭載しているかを把握する IntuneのデバイスコンプライアンスレポートやMECM（SCCM）のハードウェアインベントリを活用して棚卸しを行う カスタム構成の再評価 BitLocker + カスタムPXEブートのような構成では、証明書チェーンの検証が必要 独自署名済みドライバーやブートローダーを持つ場合、新しいCAとの互換性を確認し、必要なら再署名を行う テスト環境での事前検証 移行フェーズ開始前に、代表的な機器構成でWindows Updateを適用してテストしておく 特に「更新を当てたら起動しなくなった」というシナリオを事前に潰しておくことが重要だ MDMポリシーの見直し IntuneのデバイスコンプライアンスポリシーでSecure Bootの有効化を要件としている場合、移行前後で評価結果が変わる可能性がある。ポリシーの動作確認を合わせて行う 筆者の見解 Secure Boot証明書の更新は地味なニュースに見えるが、PCのセキュリティ基盤の根幹に関わる正しい判断だと評価している。2011年のルート証明書を15年以上使い続けること自体がリスクであり、更新のタイミングとしてはむしろ遅いくらいだ。セキュリティの改善として着実に前進しており、この方向性は支持できる。 懸念するのはエンタープライズ側の準備体制だ。「今動いているから大丈夫」という判断は、こういう場面では通用しない。カスタムブートローダーや独自の署名チェーンを積み上げた複雑な環境ほど、更新後に静かに壊れるリスクがある。情報を追うよりも自分の環境で実際に検証することの価値を改めて感じる場面だ。 6月まで数週間ある。インベントリの把握とテスト環境での事前検証に、今から時間を割く価値は十分にある。 出典: この記事は Secure Boot Certificate Updates: 2011 to 2023 Trust Change (June–Oct 2026) | Windows Forum の内容をもとに、筆者の見解を加えて独自に執筆したものです。