Windows

Windows 11の2026年5月累積更新プログラム（KB5089549）により、これまで一部のデバイスに限定されていた「Xboxモード」が、すべてのWindows 11搭載PCに正式展開された。コントローラー優先のフルスクリーンゲームダッシュボードがPCで利用可能になり、ハンドヘルドゲーミングPCにも対応する。 Xboxモードとは何か Xboxモードは、Windows PCをコンソールゲーム機のような操作感で使えるようにするUIレイヤーだ。Win + F11キーを押すと起動し、コントローラー操作を前提に設計されたフルスクリーンのゲームダッシュボードが表示される。 ダッシュボードからは次の操作が可能だ： Xbox Game Passのゲームライブラリの閲覧・起動 Microsoft Storeからのゲームインストール フレンドのオンライン状態の確認 アチーブメント・ゲーム統計の閲覧 対応デバイスはノートPC・デスクトップPC・タブレット、そしてAsus ROG AllyやLenovo LegionシリーズのようなハンドヘルドゲーミングPCまで幅広い。通常のデスクトップとの行き来はWin + F11で即座に切り替えられるため、作業中に瞬時にゲームモードへ移行するといった使い方ができる。 更新の適用方法 KB5089549はWindows Updateから通常通り配信されており、Windows 11を搭載したすべてのデバイスが対象となる。適用後は「設定 → ゲーム」からXboxモードの有効化状態を確認できる。 既存のXbox Game Passサブスクリプションがあれば追加費用は不要。ゲームダッシュボードはMicrosoftアカウントにサインインした状態で使うことで、実績・フレンドリスト・ゲームライブラリとシームレスに連携する。 ハンドヘルドPCへの最適化という意図 今回の展開で特に注目すべきは、ハンドヘルドゲーミングPCへの正式対応だ。Valve社のSteam DeckがSteamOSのコンソールライクなUIで高い評価を得てきたのに対し、Windows搭載のハンドヘルドPCはその操作感の差が長らく課題として指摘されてきた。 Xboxモードはその差を縮める存在になりうる。物理コントローラーを搭載するハンドヘルドPCにとって、コントローラー前提のUIが標準機能として用意されることは実用面で大きな意味を持つ。日本市場でもAsus ROG Ally XやMSI Claw、Lenovo Legion Goなど複数のWindows搭載ハンドヘルドが販売されており、このモードによりゲームプレイ体験の底上げが期待できる。 実務への影響 エンタープライズ・IT管理者の観点では、Xboxモードはコンシューマー向けの機能であり、業務用PCへの直接的な影響は限定的だ。ただし、以下の点は把握しておく価値がある： BYODデバイスのポリシー確認: 個人所有のWindows 11端末を業務に使用している環境では、Xboxモードの存在をポリシーの観点から整理しておくとよい グループポリシーでの制御可否: 企業向けに展開を制限したい場合、Intuneやグループポリシーを通じた制御オプションを確認しておきたい ハンドヘルドPC導入検討の参考情報: 可搬性の高い端末の導入を検討しているIT部門にとって、ゲームモードの有無が選定基準に加わるかもしれない 筆者の見解 XboxモードのPC全体への展開は、MicrosoftがPCゲームを「Xboxというブランドの傘下に統合する」戦略を着実に前進させている動きだ。SteamがPC向けゲームプラットフォームとして盤石な地位を確立している中で、Microsoft/XboxはGame PassとWindows、そしてXboxモードの組み合わせで独自の価値を打ち出そうとしている。 Windowsという巨大なプラットフォームを持つMicrosoftには、これを実行できるだけの底力がある。コントローラー最適化UIを全Windows PCに展開することで、ハンドヘルドゲーミングPCの普及トレンドにも対応できる。ここには「Windowsというプラットフォームの強みを活かした戦略」が見える。 一方で、汎用OSとしてのWindowsに特定用途向けのモードを積み重ねていく設計思想が、長期的にユーザーの体験をどう変えるかは引き続き注視したい。「Windows = 万能プラットフォーム」という強みを守りつつ、専用デバイスのような没入感を実現できるかが、今後のゲームエコシステムにおけるMicrosoftの評価を左右するだろう。やれる力はある。あとはどこまで丁寧に仕上げるかだ。 出典: この記事は Windows 11 Update Rolls Out Xbox Mode to All PCs の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

「Nightmare-Eclipse」と名乗る脅威アクターが2026年4月初頭から6週間にわたり、WindowsのDefenderやBitLockerを標的にした6件のゼロデイ脆弱性をGitHubに順次公開しており、Barracudaの調査でロシア系インフラを経由した実攻撃への悪用が確認されている。 Nightmare-Eclipseとは何者か 「Nightmare-Eclipse」（別名：Chaotic Eclipse、Dead Eclipse）は、GitHubとブログを拠点に活動する脅威アクターだ。セキュリティ研究者としての深いWindowsインターナルの知識を持ちながら、Microsoftへの個人的な恨みを唯一の動機として行動している点が際立っている。 本人は「Microsoftが合意を破り、自分を無一文のホームレスにした」と主張している。金銭目的でも国家支援でもなく、純粋な個人的報復だ。こうした動機の攻撃者は従来の脅威インテリジェンスの分類——ランサムウェア集団、国家支援APT——には収まらない。 6つのゼロデイ脆弱性の全貌 2026年4月初頭から5月時点で、以下の6件がGitHub上で公開されている： 名称 CVE パッチ状況 BlueHammer CVE-2026-33825 パッチ済み RedSun なし（サイレントパッチ） パッチ済み UnDefend 未割り当て 未パッチ YellowKey 未割り当て 未パッチ GreenPlasma 未割り当て 未パッチ MiniPlasma 未割り当て 未パッチ このキャンペーンで最も注目すべき点は、Microsoftのセキュリティ製品そのものを攻撃面として使っていることだ。DefenderやBitLockerを「回避する」のではなく、それ自体を経路や起点に変える手法は、Windowsに精通した内部者的な視点なしには設計できない。 実被害はすでに発生している Huntress Labsが2026年4月10日時点で実攻撃を確認。ロシア系インフラに紐づく侵害活動への悪用が観測されており、CISAのKnown Exploited Vulnerabilities（KEV）カタログにも追加された。Microsoftは緊急パッチサイクルを余儀なくされている。 この攻撃者はProof-of-Concept（PoC）コードをPatch Tuesdayの直後に公開するという意図的なタイミングを取っている。パッチ適用猶予期間を最大限に活用し、修正が展開される前の脆弱性ウィンドウを狙い撃ちにする戦略だ。 さらに、「デッドマンズスイッチ」の存在が予告されており、リモートコード実行（RCE）脆弱性を含む追加公開を示唆していた。最新のMiniPlasmaは予告なしにリリースされたが、これが沈静化なのか次のフェーズへの移行なのかは現時点では判断がつかない。 対象プラットフォーム 影響範囲は広い： Windows 10 / Windows 11 Windows Server 2016〜2025 コンシューマー端末から大規模なエンタープライズサーバーまで、Windowsエコシステムのほぼすべてがスコープに入る。 防御側が今すぐとるべき行動 Barracudaの分析を踏まえ、以下を優先して対処されたい： 1. CVE-2026-33825（BlueHammer）の即時パッチ適用 パッチが提供されている既知CVEは最優先で対処する。適用漏れがないか資産台帳と突合する。 2. BitLockerの構成強化と監視 攻撃者が明示的に標的にした以上、設定の見直しと異常アクセスの監視強化が急務。 3. エンドポイントに依存しない検知レイヤーの整備 侵害されたエンドポイント上のDefenderに頼らない、独立したネットワーク検知・IDコントロールの構築が有効。ゼロトラスト原則でいう「エンドポイントを暗黙的に信頼しない」の実装そのものだ。 4. 未パッチの4件の動向監視 UnDefend、YellowKey、GreenPlasma、MiniPlasmaは2026年5月時点で未パッチ。MicrosoftのMSRCおよびCISAの更新情報を継続的に追う体制を整える。 5. ロシア系IPレンジ・TORノードからの接続精査 既知の悪用インフラとの通信を可視化し、横展開の早期検知に活用する。 実務への影響 日本のエンタープライズ環境にとって、このケースが突きつける最も重要な教訓は「WindowsのネイティブセキュリティツールだけをDefenderとして扱うのは危険」という認識の更新だ。 Defenderが健在でも、UnDefendのような手法はDefender自体を経路に使う。BitLockerが有効でも、その実装を狙われる。単一レイヤーのエンドポイント防御に依存した設計が機能しなくなる攻撃手法が、今回明確に実証された形だ。 また、Patch Tuesday翌日に照準を合わせた公開戦略への対応として、パッチ適用サイクルの短縮化を検討する価値がある。「数日様子を見てから適用する」という判断が有効な場面もあるが、このような意図的なタイミング設計を持つ攻撃者に対しては、早期適用を原則とする局面だ。 ...

Microsoftは2026年5月15日、Windows Insider Programに「Experimental (Future Platforms)」という新チャンネルを設け、ビルド29591.1000を公開した。現行の安定版ビルドが26xxx台であることを考えると、この番号の跳躍は単なる小改訂ではなく、Windowsプラットフォームの抜本的な方向転換を示唆している。 「Future Platforms」チャンネルとは何か これまでのWindows Insider Programは「Dev」「Beta」「Release Preview」「Canary」の4チャンネル構成だった。今回登場した「Experimental (Future Platforms)」は、Canaryの29500シリーズの後継として位置づけられており、「現在進行中のWindowsプラットフォームの変更を開発サイクルの最初期段階で提供する」と説明されている。 注目すべきはビルド番号だ。現行のWindows 11最新安定版は26100台、Canaryチャンネルでも29500台が最新だった。そこへ29591という数字が登場した意味は小さくない。一般的にMicrosoftのビルド番号体系では、メジャーバージョンが変わると大幅な番号跳躍が起きる。Windows 10の10240からWindows 11の22000への移行がその典型例だ。今回の跳躍がWindows 12、あるいはWindowsカーネルの刷新を示すものであれば、IT業界にとって重大な変化点となる。 ただし公式リリースノートは「含まれる機能は将来のWindowsリリースでリリースされない可能性がある」と明記しており、あくまでコンセプト検証段階であることも示している。 今回のビルドに含まれる新機能 Windows Updateの柔軟性向上 企業のIT管理者が特に注目すべきは、Windows Updateに関する変更だ。今回のビルドでは以下の改善が加えられている。 OOBE（初期セットアップ）中にアップデートをスキップできる: 展開作業中に不意のアップデートが走って時間を取られる問題が緩和される アップデートの一時停止を何度でも延長可能: 従来は最大35日などの制限があったが、この制約が緩和される方向 シャットダウン・再起動時に「更新せずに終了」を常時選択可能: 「更新して再起動」を強要されるシーンが減る 適用前に更新内容をより詳しく確認できる: 何が変わるかを事前に把握した上でインストールを判断できる これらは「Windowsアップデートに振り回される」という長年の不満に応えるものだ。管理端末での検証フローを組んでいる現場にとっては朗報になりうる。 Bluetooth LE Audioによる「Shared Audio（共有オーディオ）」 一台のWindows 11 PCから、2台のBluetooth LE Audio対応デバイスへ同時に音声を送信できる機能が追加された。映画鑑賞や音楽を複数人で共有する際に、一台のPCから独立したイヤホン・ヘッドホン2台へブロードキャスト送信できる。 操作方法は「タスクバー → クイック設定 → Shared audio」から対象デバイスを2台選択するだけ。Bluetooth LE Audioはレイテンシーと省電力性能に優れた新世代規格であり、この活用はWindowsのコンシューマー向け体験を底上げするものだ。 ストレージ設定のUACプロンプト改善 設定アプリの「システム → ストレージ」を開いた際に表示されていたUAC（ユーザーアカウント制御）プロンプトが、ページ表示時ではなく「一時ファイルの表示」を選択したときにのみ出るよう変更された。細かい改善ではあるが、管理者権限の不必要な要求を減らすという原則に沿った修正だ。 日本のIT現場への影響 Windows Updateの柔軟化は、特に国内の大手企業・自治体のIT担当者にとって実務直結の改善だ。定期メンテナンスウィンドウ外にアップデートが走ることへの懸念は根強く、「スキップできる」「何度でも一時停止できる」という変更は展開管理の予測可能性を高める。 一方で「Future Platforms」という新チャンネル名が示す次世代Windowsへの移行は、企業の端末管理戦略に影響を与える可能性がある。Windows 11のサポート期限（2025年10月）に向けた移行計画を立てている組織は、次期バージョンの輪郭が見え始めたタイミングで、一度ロードマップを見直しておくことが賢明だ。 筆者の見解 「Future Platforms」というチャンネル名は、Microsoftが次世代Windowsの基盤づくりを本格化させていることの証左だろう。ビルド番号の大幅跳躍が単なる命名ルール変更ではなく、本当にアーキテクチャレベルの刷新を反映しているなら、それは歓迎すべきことだ。 今回含まれた機能自体は比較的地味だが、Windows Updateの改善は「正しい方向性」だと思う。更新を「強制」から「対話」へシフトしていくことで、ユーザーとシステムの信頼関係が少しずつ回復するはずだ。更新を恐れて先延ばしにする行動こそがセキュリティリスクになるのだから、更新しやすい環境を作ることは、機能追加と同等かそれ以上に重要な投資だ。 Shared Audioは正直なところコンシューマー向けの小技の印象が強いが、Bluetooth LE Audioという次世代規格の実装を進めているという意味では、地道ながら正しいインフラ整備だ。 「次世代Windows」の正体がまだ霧の中にある段階で、Insider Programを通じて継続的に実験的な変更をフィードバックしながら進める姿勢は、Microsoftが持つ最大の強みの一つだ。このプロセスがしっかり機能し、企業や開発者が安心して乗り移れるプラットフォームに仕上がることを期待したい。 ...

MicrosoftがVisual Studio Code（VS Code）の最新週次アップデートで、基本的なプロジェクト表示・操作に必要な組み込みツール群を強化し、開発者が長年悩まされてきた「セットアップの摩擦」を大幅に削減した。新しい環境を立ち上げるたびに延々と拡張機能をインストールしていた時代が、終わりを迎えようとしている。 これまでの「摩擦」とは何か VS Codeは「軽量なコアに拡張機能を積み重ねる」設計思想で急成長を遂げた。しかし現実の開発現場では、この柔軟性が逆に負担になるケースが続出していた。 新しいリポジトリをクローンするたびに「推奨拡張機能をインストールしますか？」のポップアップが現れ、シンタックスハイライト、Lint、ファイルプレビューなど「普通に見るだけ」の用途でも複数の拡張機能が必要だった。チームの新メンバーは初日をセットアップに費やし、CI環境では拡張機能の管理が別の運用コストになっていた。 組み込みツール強化で何が変わるか Microsoftは今回のアップデートで、基本的なプロジェクト操作に必要なツールをVS Code本体に統合した。その主な効果は次の3点だ。 即時利用可能なゼロ設定環境 リポジトリをクローンして開いた瞬間から、追加インストールなしで基本的な開発体験が得られる。extensions.json の管理や「あなたの環境だけ動かない」問題が大幅に減少する。 セキュリティリスクの低減 拡張機能マーケットプレイスからのインストールを最小化できるため、サプライチェーンリスクが下がる。特に日本のエンタープライズ環境では、セキュリティポリシーによって拡張機能インストール自体が制限されているケースも多く、組み込みツールの充実は直接的な恩恵をもたらす。 クラウド・コンテナ開発との相性向上 DevContainerやGitHub Codespacesを活用したクラウド開発では「最小セットアップ・最大機能」がコストと速度の両面で重要だ。組み込みツールの強化はこの方向性と完全に一致している。 実務での活用ポイント オンボーディングの即戦力化 新メンバーがリポジトリをクローンして即座に開発を開始できる体制を整えよう。プロジェクトの extensions.json を見直し、本当に必要な拡張機能だけを recommendations に残すことで、セットアップ時間をさらに短縮できる。 CI/CDパイプラインの簡素化 コードレビューやLintチェックをVS Code組み込みツールに依存する構成へ移行すると、パイプラインの追加パッケージインストールステップを削減できる可能性がある。devcontainer.json と組み合わせた標準化が特に効果的だ。 セキュリティポリシーが厳しい環境での対応 拡張機能マーケットプレイスへのアクセスが制限された環境では、組み込みツールに依存する開発フローを公式ドキュメントをベースに設計しておくと、監査対応もスムーズになる。 筆者の見解 VS Codeは今のMicrosoftが誇るべき最高の成功例のひとつだと思っている。派手な発表ではないが、毎週着実に積み重なる「開発者の地味な不満を拾い上げる」姿勢は本物だ。 「摩擦を減らす」という今回の改善は一見地味に見えるが、実務への影響は大きい。新しい環境を立ち上げるたびの「あの面倒くささ」を知っている開発者なら、この変更の価値がよくわかるはずだ。 ひとつ注目しておきたいのは、組み込みツールとサードパーティ拡張機能の境界線の問題だ。VS Codeが成功した理由の大部分は、活発な拡張機能エコシステムにある。組み込みツールの範囲が広がりすぎると、コントリビューターのモチベーションに影響が出る可能性もある。オープンな生態系を守りながら組み込みを強化するバランスをどう取るか、今後の方針は引き続き注視していきたい。 VS Codeがあらゆる開発者の「標準装備」として機能し続けるためにも、この地道な改善路線を一貫して続けてほしい。Microsoftにはその実力が十分にある。 出典: この記事は Microsoft just removed major “friction” from VS Code in its latest weekly update の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがOutlookにおける基本的なメール機能の不具合を公式に認め、現時点での回避策を案内した。日々の業務でOutlookを中心に動いている日本企業にとって、「当たり前にできるはず」の操作が突然使えなくなるこのような事態は、業務影響が無視できない。 何が起きているのか 今回のMicrosoftの公式アナウンスは、Outlookが持つ基本的かつ多くのユーザーが日常的に使っているメール機能の一つが、現在正常に動作していないというものだ。Neowinが報じたこの件では、Microsoftは障害の存在を認めつつ、修正が完了するまでの暫定的な回避策（ワークアラウンド）を共有している。 Microsoftは近年、クラシックOutlook（旧来のデスクトップアプリ）から「新しいOutlook for Windows」への移行を積極的に促している。この移行プロセスの中で、旧アプリでは当然のように使えていた機能が新しいOutlookで動作しないケースが散発的に報告されてきた。今回の件がどちらのバージョンの問題かは記事公開時点では確定情報がないが、移行期特有の品質リスクが表面化している可能性が高い。 回避策の活用と注意点 現時点でMicrosoftが提示しているアドレスは「修正の約束」ではなく「暫定対応」だ。実務で影響が出ている場合は、以下の点を押さえておきたい。 Microsoft 365 管理センターの「サービス正常性」を確認する: テナント管理者はリアルタイムで障害状況と公式回避策を確認できる。エンドユーザーからの問い合わせが来る前に把握しておくこと 回避策の展開はヘルプデスクに周知する: 一般ユーザーが自力で回避策を見つけるのは難しい。IT部門が先手を打ってFAQや簡易手順書を用意すると混乱を最小化できる 新旧Outlookの切り替えを一時的に検討する: 新しいOutlookへの移行途中のテナントであれば、影響範囲によっては一時的にクラシックOutlookへ戻す判断も選択肢に入る。ただし「戻す」判断は長期的な移行計画全体を見据えて慎重に Microsoft 365 ロードマップとMessage Centerを定期購読する: 事後対応ではなく、変更・障害情報を早期にキャッチするための仕組みを組織として持つことが重要 実務への影響 Outlookは日本企業のメールインフラのデファクトスタンダードであり、基本的なメール機能の障害はそのまま業務停止リスクに直結する。特に、フロントオフィスや営業部門のようにメールを主要コミュニケーション手段として使っているチームでは、「Outlookが使えない」というシンプルな問題が大きな業務影響を生む。 また、Microsoft 365の利点は「統合プラットフォームとして使うことで価値が出る」点にある。Teams・Outlook・SharePoint・Copilotが連携して動いてこそ真価を発揮するが、そのコアとなるOutlookが揺らぐと全体の連携品質も下がる。個々のアプリを別々に評価するのではなく、プラットフォーム全体の安定性として捉える視点が管理者には必要だ。 筆者の見解 Outlookのような、長年にわたって数億人が毎日使い続けてきたプロダクトで、基本的な機能が壊れるという事態は、率直に言ってもったいないと感じる。Microsoftには間違いなくその技術力があるのだから、こういった品質問題は「やろうと思えばできるはず」という期待とのギャップが大きく映る。 近年のMicrosoftは新しいOutlookへの移行を急ぐあまり、成熟した旧バージョンが担ってきた品質水準を新バージョンで再現するコストを過小評価しているように見える部分がある。ユーザーが「新しいUIになったら前よりも不便になった」と感じると、移行そのものへの反発が生まれ、長期的には製品全体への信頼低下につながる。 移行は避けられない方向性であり、新しいOutlookがいずれ安定した姿になることは期待している。ただ、その過程での品質管理の丁寧さが、ユーザーのMicrosoft 365全体への評価に直接影響することを、開発チームには改めて意識してほしいと思う。「基本機能が壊れている」というニュースが繰り返されると、せっかくのプラットフォームとしての総合力が霞んでしまう。 出典: この記事は Microsoft admits one of the most basic, useful Outlook features is broken の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが2026年5月、Microsoft 365 Copilotに大規模アップデートを展開した。目玉はOpenAIの最新モデル「GPT-5.5」の統合で、低遅延の「GPT-5.5 Instant」と多段階推論が可能な「GPT-5.5 Thinking」の2種類が利用できるようになる。さらにアプリランチャー「ワッフル（Waffle）」の復活、Researcher機能の強化、Copilot Notebooksの新機能追加など、企業向け生産性ツールとしての土台が大幅に底上げされた。 GPT-5.5モデルの統合——2種類の使い分けが鍵 今回追加されたGPT-5.5は、用途に応じた2種類のモデルが提供される点が特徴だ。 GPT-5.5 Instantは低レイテンシを重視した設計で、メール返信の下書き、会議要約の即時生成、日常的な文書作成といった「素早く答えが欲しい」シーンに最適化されている。レスポンス速度が重視される業務フローでストレスを大幅に軽減できる。 GPT-5.5 Thinkingは、複数ステップにわたる論理的推論を得意とするモデルだ。財務レポートの深い分析、複雑な調査タスク、多角的な比較検討が求められる作業で真価を発揮する。単純な要約に止まらず、「なぜそうなるのか」「どう判断すべきか」という思考プロセスを伴うアウトプットが可能になる。 この2モデルの並存は、「AIに何でもやらせる」という曖昧な活用から、「タスクの性質に合わせてモデルを選ぶ」という成熟した活用へのシフトを促す設計といえる。 ワッフルランチャー復活——ユーザーフィードバックの成果 Microsoft 365を長く使ってきたユーザーなら「ワッフル（Waffle）」と呼ばれるアプリランチャーを懐かしく思うだろう。格子状のアイコンからOutlook、Teams、OneDrive、SharePointなどへ素早くジャンプできるこの機能が、今回のアップデートで復活する。 廃止・変更された際には多くのユーザーから不満の声が上がっており、今回の復活はMicrosoftがユーザーフィードバックを製品に反映させた好例といえる。複数のM365サービスを横断して業務を進めるユーザーにとって、ナビゲーションの一貫性は生産性に直結する。 ResearcherとCopilot Notebooksの強化 Researcher機能は、大量のドキュメントやウェブ情報を分析して体系的にまとめる機能で、今回さらに精度と速度が向上した。調査担当者や意思決定者が多くの情報源を処理しなければならない場面で、より実用的なレベルに近づいている。 Copilot Notebooksは、AIとのやりとりや生成コンテンツをノートブック形式で管理できる機能で、新機能が加わった。長期的なプロジェクト管理、調査内容のまとめ、チームでの知識共有といったユースケースでの活用が広がりそうだ。 Windows 11タスクバーへのAIエージェント統合 今回のM365アップデートと並行して、Windows 11のタスクバーにAIエージェントをアプリとして表示する「Agents on Taskbar」機能も展開される。OSレベルでAIエージェントをネイティブに扱う方向性を明確に打ち出したかたちだ。 日本のIT現場への影響 日本企業のMicrosoft 365導入率は年々高まっており、TeamsとM365を中心とした業務フローが標準化されつつある。今回のアップデートが現場に与える影響として、以下の点に注目したい。 即時に活用できる実務例： 英語メールの日本語要約と返信案の生成（GPT-5.5 Instantが有効） 社内会議の文字起こしと議事録の自動生成 財務・プロジェクトレポートの多角的分析（GPT-5.5 Thinkingが有効） 大量のRFP・提案書からの要件整理 IT管理者が確認すべき点： GPT-5.5モデルへのアクセスはライセンスプランによって異なる可能性があるため、契約内容の確認が必要 Copilot Notebooksに蓄積されるデータのガバナンスポリシーを事前に整備すること 「Agents on Taskbar」はエンドポイント管理ポリシーとの整合性確認が求められる 筆者の見解 GPT-5.5 InstantとGPT-5.5 Thinkingという2モデルを用途別に選択できる設計は、方向性として正しいと思う。「AIにとりあえず聞く」から「目的に応じてツールを選ぶ」という使い方の成熟を後押しする仕組みだからだ。 ただ正直に言えば、「ようやくここまで来たか」という感覚もある。Copilotが登場した当初から、多くのユーザーが「速さが欲しいときと、深く考えてほしいときでは要件が違う」という声を上げ続けていた。その声が製品に反映されるまでに時間がかかりすぎた感は否めない。 ワッフルランチャーの復活も同様で、ユーザーの声を聞いて改善できる力はMicrosoftには十分ある。問題は、そのサイクルをもっと速く回せるかどうかだ。Copilotはまだ「生産性の最大化」という本来の目標に届いていないと感じているが、今回のGPT-5.5統合は実質的な前進であり、正面から勝負できる素地が着実に整いつつあることは認めたい。 日本の企業にとっては、今が「Copilotを使えるかどうか」ではなく「どう使うか」を本気で設計するフェーズだ。モデルの質が上がった今、組織としての活用戦略がなければ恩恵の半分も受け取れない。 出典: この記事は Microsoft 365 Copilot update adds GPT-5.5 models and more の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Appleは、App Storeにおけるセキュリティ実績の最新データを公開し、潜在的な不正取引として22億ドル（約3,300億円）超をブロックしたことを明らかにした。アプリの審査から決済監視まで多層的な防御がその背景にある。 App Storeが公開した主要な安全統計 Appleが毎年発表するApp Store安全性レポートは、エンドユーザーが目にすることのないバックエンドの防衛活動を数値化したものだ。今回の公開データで特に注目すべき点は以下の通りだ。 22億ドル超の不正取引を阻止: 決済段階で検知された潜在的な詐欺行為を、実際の被害が発生する前にシステム的にブロックした 不正アプリの審査拒否・削除: App Reviewプロセスを通じた事前スクリーニングに加え、公開後のアプリについても継続的な監視が行われている 偽レビューや不正アカウントの排除: マーケットプレイスの信頼性を保つための継続的な取り組みも報告されている なぜこれが重要か AppleのApp Storeはモバイルアプリ流通において世界最大規模のプラットフォームのひとつであり、日本においても多くの法人・個人ユーザーがビジネス用途でiOSアプリを日常的に利用している。このため、プラットフォームレベルのセキュリティ水準が企業のリスク管理に直接影響する。 特に企業内でのMDM（モバイルデバイス管理）運用を担うIT管理者にとっては、「App Store経由のアプリは一定の審査を通過している」という前提がゼロトラスト設計の信頼起点のひとつになっている。この前提が崩れれば、エンドポイントセキュリティ全体の再設計を迫られる可能性もある。 一方で、22億ドルという数字は「防いだ被害額」であると同時に、それだけの不正試行が存在していたという事実でもある。プラットフォームが大きくなるほど攻撃対象としての魅力も増す、という構造的なジレンマを改めて示している。 実務での活用ポイント エンドポイント管理担当者へ: Appleの審査が通過していても、マルウェアが後から埋め込まれる「バージョンアップ型攻撃」は過去に事例がある。MDMポリシーでのアプリ許可リスト管理と合わせて、App Storeの透明性レポートを定期的に参照し、自社利用アプリのリスクを定量的に把握する習慣をつけたい。 開発者・ISV向け: Appleのレビュープロセスは厳格で時間がかかると批判される一方、こうした数値がその意義を裏付けている。Appleのガイドラインへの準拠は単なる規約遵守ではなく、エンドユーザーへの信頼担保でもある。特に決済フローを持つアプリは、審査基準の変更を常にウォッチしておくことが欠かせない。 セキュリティ部門向け: Non-Human Identities（NHI）の観点でも注目すべき点がある。App Storeの不正取引の多くは、盗まれたApple IDや自動化されたボットによるものだ。自社のサービスアカウントやAPIキーも同様のリスクにさらされていると想定し、JIT（Just-In-Time）アクセスや短命トークンの活用を検討したい。 筆者の見解 Appleがこうした統計を年次で公開するスタンスは評価できる。数字を出すことで「うちのプラットフォームはこれだけ守っている」という説明責任を果たしているからだ。 ひとつ気になるのは、「防いだ」という数字の定義の曖昧さだ。「潜在的な不正取引」とはどこまでが確実な不正で、どこからが誤検知なのか。透明性レポートとして評価するなら、方法論の開示まで踏み込んでほしい。 セキュリティは「何を禁止したか」ではなく「どう構造的に安全にしたか」で語られるべきだ。その意味で、Appleのレイヤーごとの防御設計（審査・決済・アカウント）のアプローチは、プラットフォームセキュリティの教科書的な事例として参考になる。日本企業のシステム設計者にも、禁止ルールを積み重ねるのではなく、「使う側が一番安全な選択肢に自然に誘導される仕組み」を作るという発想の転換を促したい。 出典: この記事は Apple shares big numbers about fraud on the App Store の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ウクライナサイバー警察と米国法執行機関は、カリフォルニア州のオンラインストアのユーザーを標的にInfostealer（情報窃取）マルウェアを運用し、2万8000件以上のアカウントを侵害した18歳の男をウクライナ・オデッサで特定した。被害額は約72万1000ドル（約1億円超）に上る。 Infostealerで2万8000件を侵害した手口 2024年から2025年にかけて、容疑者はInfostealerマルウェアを使って被害者のデバイスに密かに感染させた。このマルウェアはブラウザのセッションデータ、ログイン認証情報、クッキー、セッショントークン、仮想通貨ウォレット、決済情報などを収集し、容疑者が管理するサーバーに送信する仕組みだ。 侵害されたアカウントは2万8000件に上り、そのうち5,800件が実際の不正購入に悪用された。被害総額は約72万1000ドル、チャージバックを含む直接損失は25万ドルに達している。 盗んだデータはオンラインリソースやTelegramボットを通じて処理・売買され、容疑者は仮想通貨で収益を受け取っていたとされる。ウクライナ警察は自宅2か所を捜索し、携帯電話・コンピュータ機器・銀行カード・電子記録媒体などを押収した。現時点では逮捕には至っておらず、当局はまだ起訴に向けた証拠を固めている段階だという。 最大の問題：セッショントークンでMFAが無効化される 今回の攻撃で技術的に最も重大なポイントは、セッショントークンの悪用だ。 セッショントークンは認証後にサーバーが発行するデータで、ブラウザがこれを保持することでログイン状態を維持する仕組みだ。これを盗まれると、攻撃者はパスワードを知らなくてもアカウントにアクセスできる。さらに深刻なのは、多要素認証（MFA）をすでに通過した後のセッションを乗っ取るため、MFA自体が意味をなさなくなる点だ。 「MFAを設定しているから安全」という前提が根底から崩れる攻撃手法であり、エンタープライズ環境でも決して他人事ではない。 実務への影響——日本のエンジニア・IT管理者へ MFAの導入だけで安心しないこと 今回の事件が示す教訓は明確だ。MFAは認証「時点」を守るが、認証後のセッションは別の話だ。以下の対策を組み合わせて初めて実効性のある防御になる。 セッションの有効期限を短く設定する：長時間有効なセッションはリスクを高める。サービスの利便性とのバランスを取りながら、適切な失効タイミングを設定する 継続的アクセス評価（CAE）の活用：Microsoft Entra IDのCAEは認証後もリアルタイムでセッションの正当性を評価し、異常を検知した際に即時失効できる。既にEntra IDを使っているなら積極的に有効化すべき機能だ 条件付きアクセスポリシーの強化：未知のIPアドレスや新しいデバイスからのアクセスに再認証を要求する設定を追加する デバイスコンプライアンスとの統合：管理対象デバイスからのアクセスのみ許可することで、マルウェアに感染した非管理デバイスからのトークン流用を防ぐ Infostealerは「誰でも使えるツール」になっている 今回の容疑者は18歳だ。特別に高度な技術を持つ攻撃者でなくても、マルウェア・アズ・ア・サービス（MaaS）として流通するInfostealerを購入して展開するだけで、数億円規模の詐欺を実行できる時代になっている。 「うちは有名な会社じゃないから狙われない」という認識はもはや通用しない。ECサイトや顧客情報を持つ中小規模のオンラインサービスも標的になりうる。エンドポイントへの感染経路（フィッシングメール、悪意あるダウンロード）を塞ぐセキュリティ意識教育と、EDRソリューションの導入は急務だ。 筆者の見解 セキュリティ分野は正直、得意ジャンルとは言いにくい領域だ。細かい議論が多すぎるし、規格やフレームワークの海に溺れることも多い。ただ、今回の事件は技術的に非常に興味深い構造を持っている。 注目すべきはセッショントークンによるMFAバイパスという構造的問題だ。「MFAを入れた＝安全」という思い込みは、今も多くの現場に根強く残っている。だが認証の「後」に発行されたセッションを奪われれば、MFAはあってないようなものになる。これはゼロトラストの文脈では「一度認証したら信頼し続ける」という旧来モデルの根本的な欠陥を突いている。 本来のゼロトラストは「継続的な検証（Continuous Verification）」が前提だ。Entra IDのCAEやMicrosoft Defenderのエンドポイント統合は、この方向性における正しいアプローチだと思う。こうした仕組みを組み合わせた多層防御こそが、アイデンティティ保護の核心になる。VPNで境界を守る時代から、セッション単位・アクセス単位で継続的に検証する時代への移行は、もはや「いつかやること」ではない。 今回の容疑者が18歳だという事実も、現実を直視させる。技術の民主化は、攻撃の民主化でもある。守る側が「うちはまだ大丈夫」と言っていられる時間は、思っているより短い。 出典: この記事は Ukraine identifies infostealer operator tied to 28,000 stolen accounts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月20日、Windows BitLockerを回避してドライブへのアクセスを可能にするゼロデイ脆弱性「YellowKey」（CVE-2026-45585）の緩和策を公開した。パッチリリース前ながら、実際の攻撃への悪用に備えた暫定対応として企業・個人への適用が推奨されている。 YellowKeyとは何か：BitLockerを「抜け道」で突破する手口 YellowKeyは、「Nightmare Eclipse」を名乗る匿名のセキュリティ研究者が先週公開したゼロデイ脆弱性だ。攻撃者はUSBドライブまたはEFIパーティション上に特別に細工された「FsTx」ファイルを配置し、Windows回復環境（WinRE）に再起動後、CTRLキーを押し続けるだけでBitLockerで保護されたストレージへの無制限アクセスを持つシェルを起動できるという。 この手法の厄介な点は、BitLocker自体の暗号アルゴリズムを破るのではなく、WinRE起動時の処理フロー（具体的にはTransactional NTFSの自動リカバリユーティリティ「autofstx.exe」）を悪用して保護をすり抜けるところにある。つまり、暗号強度の問題ではなく起動プロセスの設計上の盲点を突く攻撃だ。 一連のゼロデイ公開：研究者とMSRCの対立が背景 YellowKeyは単発の公開ではない。Nightmare Eclipseはここ数週間で以下の複数の脆弱性を連続して公開している： BlueHammer（CVE-2026-33825）：ローカル権限昇格（LPE）。すでに実際の攻撃で悪用中 RedSun：同じくLPE系。すでに攻撃悪用が確認 GreenPlasma：SYSTEMシェルを取得できる権限昇格 UnDefend：標準ユーザー権限からMicrosoft Defenderの定義ファイル更新をブロックできる脆弱性 研究者は、これらの公開が「過去にMSRC（Microsoft Security Response Center）へ報告した脆弱性の開示プロセスへの抗議」であると明言している。協調的脆弱性開示（CVD）のプロセスへの不満が引き金となった「報復型公開」とも言える事態だ。 Microsoftが示した具体的な緩和策 MicrosoftはCVE-2026-45585のアドバイザリにて、パッチ提供前の暫定対応として以下の2系統の措置を推奨している。 対策①：autofstx.exeの自動起動を無効化 WindowsのSession Managerレジストリキー内、BootExecute（REG_MULTI_SZ値）からautofstx.exeのエントリを削除する。これにより、WinRE起動時にwinpeshl.iniを削除するTransactional NTFSのリプレイ処理が実行されなくなり、攻撃の起点が断たれる。 併せて、CVE-2026-33825のアドバイザリに記載された手順に従い、WinREのBitLocker信頼関係を再確立する必要がある。 対策②：BitLockerの認証モードを「TPM+PIN」へ移行 現在「TPMのみ」モードでBitLockerを運用している場合、「TPM+PIN」モードへ変更することで、起動時に事前認証PINが必要となりYellowKey攻撃を実質的にブロックできる。 設定方法は以下の3通りが用意されている： PowerShell コマンドライン コントロールパネル まだ暗号化していないデバイスについては、Microsoft Intuneまたはグループポリシー経由で「起動時に追加の認証を要求する」オプションを有効化し、「TPM起動PINの構成」を「TPMと共に起動PINを要求する」に設定する。 実務への影響：日本のエンジニア・IT管理者がすべきこと 即時確認すべき環境として優先度が高いのは以下のケースだ： 物理アクセスが比較的容易な環境（共有スペースのPC、展示用端末、出張・テレワーク用ノートPC） BitLockerをTPMのみで運用している企業端末：エンドポイント管理ツール（IntuneやSCCM）でTPM+PIN移行の展開計画を立てる WinREが有効になっているサーバー：特に物理サーバーや共用ホスティング環境では確認が必要 Intuneを利用している環境では、エンドポイントセキュリティポリシーの「BitLocker」設定から一括展開が可能だ。まず小規模パイロットで動作を確認してからロールアウトする手順を踏むと安全だ。 なお、BlueHammerとRedSunはすでに実際の攻撃で使われていることも忘れてはならない。YellowKeyの緩和策適用と並行して、これらへのパッチ適用状況も合わせて確認しておきたい。 筆者の見解 今回の一連の出来事は、脆弱性開示の難しさを改めて突きつけている。研究者とベンダーの「協調的開示」は理想論として成立するが、その運用がどちらかにとって不誠実だと感じられれば、今回のような形で崩壊する。MSRCのプロセスに何らかの問題があったのかどうか、現時点では外部からは判断しかねる部分もあるが、これだけの規模で報復的な公開が続いているという事実は、Microsoftには真剣に受け止めてほしいところだ。 技術的な側面で言えば、TPMのみのBitLocker運用がいかに脆弱な前提に立っているかを、今回の脆弱性は鮮明に示している。物理アクセスさえできれば保護が崩れる構成は、ゼロトラストの観点からもアウトだ。「ドライブを暗号化しているから安心」ではなく、「誰がどのタイミングで認証するか」まで設計して初めてセキュリティが成立する。TPM+PINへの移行は今すぐ着手すべき作業であり、パッチ待ちの間の一時的な措置ではなく、恒久的なセキュリティ向上として位置づけるべきだと思う。 MicrosoftがCVEを発行して緩和策を素早く公開したこと自体は評価したい。正式パッチのリリースも迅速に行われることを期待したい。 出典: この記事は Microsoft shares mitigation for YellowKey Windows zero-day の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GitHubは2026年5月20日、同社の社員が悪意のあるVS Code拡張機能をインストールしたことにより、社内リポジトリ約3,800件が侵害されたことを公式に確認した。攻撃者グループ「TeamPCP」は盗み出したコードを5万ドル以上で売却すると宣言しており、開発者コミュニティに大きな衝撃を与えている。 何が起きたのか GitHubは5月19日〜20日にかけて、社員端末の侵害インシデントを検知・封じ込めた。原因は、その社員が「毒入り（Poisoned）」VS Code拡張機能をインストールしたことだ。GitHubは問題の拡張機能をVS Code Marketplaceから削除し、該当端末を隔離した上でインシデント対応を開始した。 現時点での調査によれば、侵害されたのはGitHub内部リポジトリのみであり、外部の顧客データへの影響は確認されていない。攻撃者側が主張している「約3,800リポジトリ」という数字は、GitHub自身の調査とも整合性があると公式に認めている。 犯行グループ「TeamPCP」とは 今回の侵害を主張しているのは「TeamPCP」というハッカーグループだ。サイバー犯罪フォーラム「Breached」にて「GitHubのソースコードと約4,000件のプライベートリポジトリ」へのアクセスを主張し、最低5万ドルでの売却を宣言している。 「これは身代金要求ではない。GitHubから金を脅し取るつもりはない。一人の買い手に売ったら手元のデータは削除する。買い手が見つからなければ無料で公開する」——この声明からは、金銭目的の計画的な売買スキームが伺える。 TeamPCPはこれまでにも、GitHub・PyPI・NPM・Dockerといった開発者向けコードプラットフォームを標的にした大規模なサプライチェーン攻撃に関与しているとされる。最近では「Mini Shai-Hulud」サプライチェーンキャンペーンにも関与しており、OpenAI社員2名も被害を受けたとされている。 VS Code拡張機能の危険性——繰り返す侵害の歴史 VS Code拡張機能は、Microsoftの公式ストア「VS Code Marketplace」から無料でインストールできる。その利便性の裏側に、過去から繰り返してきたセキュリティリスクが存在する。 2024年: 合計900万インストールを超えるVS Code拡張機能がセキュリティリスクにより削除 2024年: 10種の拡張機能が正規の開発ツールに偽装し、XMRig クリプトマイナーをインストール 2024年末: 攻撃者「WhiteCobra」が24種の暗号通貨窃取拡張機能を大量投入後、ランサムウェア機能を持つ拡張機能がマーケットプレースに侵入 2026年1月: AIコーディングアシスタントを装った悪意ある拡張機能2種（計150万インストール）が、中国のサーバーへ開発者システムのデータを送信 VS Code Marketplaceのエコシステムは世界最大規模の開発者向けプラグインストアだ。そのスケールゆえに、審査をすり抜けた悪意ある拡張機能が繰り返し発見される構造的な問題が続いている。 実務への影響——日本の開発者・IT管理者へ このインシデントが日本のエンジニアやIT部門に示す教訓は具体的だ。 開発者が今すぐできること: インストール前の確認を習慣化する: 公式マーケットプレース掲載でも安全ではない。開発元の組織・インストール数・更新頻度・ソースコードの公開有無を確認してからインストールする 定期的な棚卸しを実施する: インストール済みの拡張機能を3ヶ月に1回程度レビューし、使っていないものや出所が不明確なものは削除する AIコーディングアシスタントを装う偽物に注意: 2026年1月の事例でも明らかなように、生成AI系ツールへの偽装が増加傾向にある。著名な提供元（GitHubやMicrosoft公式等）との偽物を見分ける目を養う IT管理者・セキュリティ担当者向け: エンドポイント管理ポリシーで拡張機能を制御: Microsoft IntuneやGroup Policyを使い、事前承認済みの拡張機能のみインストールを許可するポリシーを検討する 開発者端末のEDR/XDRを強化する: GitHubが今回迅速に検知・封じ込めできたように、開発者端末こそエンドポイント保護の対象として位置づける 最小権限の原則を内部リポジトリにも適用する: 社員端末が侵害されても被害範囲を限定できるよう、開発者の内部リポジトリへのアクセス権を職務上必要な範囲に絞る 筆者の見解 今回のGitHub侵害で改めて浮かび上がるのは、サプライチェーン攻撃の対象が「コード」そのものから「開発者の日常ツール」へとシフトしているという現実だ。 VS Code拡張機能は、現代の開発者にとって空気のような存在になっている。便利さゆえにインストールのハードルが著しく低い。そこに攻撃者が目をつけるのは合理的な判断と言わざるを得ない。 セキュリティを「禁止」で解決しようとする組織は必ず失敗する。「VS Code拡張機能は全て禁止」では開発生産性が壊滅し、迂回策を取る開発者が続出する。重要なのは、公式に承認された拡張機能を使うのが最も便利な状況を組織として整備することだ。IT部門が事前承認済みのリストを維持し、それを使うことで摩擦なく仕事ができる仕組みにする——この方向性こそが現実的な答えだと筆者は考える。 今回の侵害が「内部リポジトリのみ」に留まった点は、GitHubのインシデント対応体制が機能した証左でもある。侵害を100%防ぐことは不可能という前提で、いかに早く検知して被害範囲を限定するかが問われている。同様の体制を持つ日本企業はまだ少数派だろう。 GitHubを使っている組織がFortune 100の90%に達しているという事実は、それ自体が攻撃者にとっての巨大なインセンティブだ。規模の大小に関わらず、開発者ツールのセキュリティを「本業ではない」として後回しにしてきた組織は、今すぐ向き合うべきタイミングにきている。 出典: この記事は GitHub confirms breach of 3,800 repos via malicious VSCode extension の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはWindows 11の検索機能を大幅に見直し、タスクバーの検索バーでローカルのファイルやアプリをBingなどのWeb検索結果より優先して表示する改善を段階的に展開中であることを公式に認めた。 何が変わるのか 長らくWindows 11の検索バーは「なんでもこなすオールインワン機能」として設計されており、ローカルのファイル検索と同時にBingのWeb検索結果も混在して表示してきた。この結果、たとえばアプリ名を検索しても関係のないWebページが上位に並ぶ、といったUXの問題が常態化していた。 MicrosoftはWindows InsidersのExperimental Channel向けBuild 26300.8493のリリースノートで、次のように明記している。 「ファイルやアプリが、コンテンツとしてより強い一致を示す場合に、Web候補より確実に上位に表示されるようにしました」 実際のテストでは、映画関連のファイル名を検索した際に、従来はBingで映画情報が上位に出ていたところ、ローカルに保存されたそのファイルが最初に表示されるようになったことが確認されている。また、タイポ（入力ミス）がある場合でもローカル結果が優先されるよう改善されており、日常的な検索精度が大きく向上する見込みだ。 今後のロードマップ 今回の変更はあくまでも始まりに過ぎない。Microsoftは2026年3月20日に公開したブログ記事の中で、Windows 11 2026品質改善の重点領域のひとつとしてSearchを挙げており、以下の改善を計画していることが明らかになっている。 ローカル結果とWeb結果を視覚的に区別する新UIの内部テスト中 タスクバー・スタートメニュー・エクスプローラー・設定アプリにまたがる一貫した検索体験の統一 より「高速」で「信頼できる」UIへの刷新 Settingsからの検索設定変更（現状はレジストリ操作が必要） なお、Web検索機能そのものが廃止されるわけではない。Bingとの統合は引き続き維持されるが、ユーザーの意図がローカルコンテンツにある場合はそちらを優先するという、当たり前のことが当たり前にできるよう修正される形だ。 実務への影響 IT管理者・エンジニアへのポイント 現状、企業環境でWindows SearchのWeb結果を無効化したい場合はグループポリシーまたはレジストリ編集が必要だが、今後はSettings UIでの制御が可能になる可能性がある。大規模展開時に構成の手間が減ることが期待できる。 また、エクスプローラーの検索精度向上も計画されているため、大量のファイルを扱う作業環境——開発・設計・法務など——での生産性改善にも直結する。Preview buildで先行確認したい場合は、Windows InsiderプログラムのCanaryまたはDevチャンネルへの参加が選択肢となる。ただし本番環境への早期適用は、例年通り不具合リスクを考慮して数週間様子を見るのが無難だ。 筆者の見解 正直に言えば、これは「なぜ今まで放置されていたのか」という性質の改善だ。ファイルを検索したいときにWebの映画情報が出てくるのは、UIとして根本的に筋が悪い。ユーザーの意図を優先するというのは検索エンジンの基本中の基本であり、それがOSのローカル検索でできていなかった事実は、長年のWindows Searchへの不満の根本にある。 ただ、今回Microsoftが「内部ベンチマークとして精度向上を設定している」と明言し、UIの一貫性・高速化・結果の可視化という複数の軸で改善を進めているのは、方向性として評価できる。Windowsの基盤部分の品質を地道に上げる取り組みは、派手ではないが長く使われるOSとして必要なことだ。 AI機能の華々しいアップデートが注目を集める一方で、こういった「地に足のついたUX改善」が積み重なることで、日常的な使い勝手は確実に向上する。Microsoftが正面から取り組んでほしい領域はほかにもあるが、まずはこの改善が予告通りに安定して届くことを期待したい。 出典: この記事は Microsoft says Windows 11’s Search will stop forcing web over your apps and local files in most cases の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月19日、同社のコード署名サービス「Azure Artifact Signing」を悪用してマルウェアに正規証明書を付与する「マルウェア署名代行サービス（MSaaS）」を運営していた脅威グループ「Fox Tempest」の活動を摘発・無効化したと発表した。 Azure Artifact Signingの悪用という巧妙な手口 Azure Artifact Signing（旧称：Trusted Signing）は、Microsoftが2024年に開始したクラウドベースのコード署名サービスだ。開発者が自分のプログラムをMicrosoftのインフラ上で簡単に署名できる仕組みで、正規の開発者にとっては利便性の高いサービスである。 Fox Tempestはこのサービスを不正に利用し、マルウェアにMicrosoft由来の正規コード署名証明書を付与することで、Windowsのセキュリティ機能やエンドポイント保護を回避していた。署名されたマルウェアはMicrosoft Teams、AnyDesk、PuTTY、Webexなどの正規ソフトウェアになりすまし、被害者がダウンロード・実行するよう誘導された。 特に巧妙だったのが「有効期間72時間の短命証明書」の活用だ。長期証明書は証明書失効リストに載るリスクがあるが、72時間以内に攻撃を完結させれば証明書が有効なまま悪用できる。グループは1,000件以上の証明書と数百のAzureテナント・サブスクリプションを量産することで、大規模かつ持続的な攻撃インフラを構築していた。身元確認をくぐり抜けるため、米国・カナダの盗用されたIDが利用された疑いがあるとされている。 関連するマルウェア・ランサムウェアの全容 今回摘発された活動は、複数の悪名高いマルウェアキャンペーンと関連していることが明らかになっている。 情報窃取系: Lumma Stealer、Vidar、Oyster（ローダー） ランサムウェア: Rhysida、Akira、INC、Qilin、BlackByte 攻撃に関与した脅威グループとして、INC Ransomwareメンバーを含む「Vanilla Tempest」、Storm-0501、Storm-2561、Storm-0249が特定されている。 典型的な感染チェーンは次の通りだ：偽のMicrosoft Teamsインストーラーを実行 → 悪意のあるローダーが起動 → 署名済みOysterマルウェアがインストール → 最終的にRhysidaランサムウェアが展開される。Windowsが「正規ソフトウェア」と認識することで、通常であればブロックされるはずのマルウェアが初期段階をすり抜けるという構造だ。 Microsoftの対応措置 Microsoftは今回、以下の措置を実施した。 1,000件超のコード署名証明書を失効処理 signspace[.]cloudドメインを押収 数百台の仮想マシンをオフライン化 犯罪プラットフォームへのアクセスをブロック ニューヨーク南部地区連邦地方裁判所に法的措置（Vanilla Tempestを共謀者として名指し） 押収されたドメインはMicrosoftの公式説明ページにリダイレクトされており、摘発の内容が一般公開されている。Microsoftのデジタル犯罪対策部門（DCU）が業界パートナーと連携して実施した今回の作戦は、インフラ破壊から法的措置まで包括的な対応となっている。 実務への影響：日本のエンジニア・IT管理者が今すぐ確認すべきこと エンドポイント保護の見直し コード署名だけを信頼の根拠にしてはいけない。今回の事件は、署名証明書が比較的容易に不正取得・悪用できることを改めて示した。Windows Defender / EDR製品の振る舞い検知を有効化し、署名済みファイルであっても動的解析を通過させる設定を確認したい。また、Microsoft TeamsなどのアプリケーションはMicrosoft StoreまたはIntuneを通じた組織配布経路からのみインストールを許可するポリシーの導入を検討すべきだ。 Azure環境のガバナンス 自社テナントでAzure Artifact Signingを利用している場合、証明書発行ログを定期的に確認する習慣をつけたい。また、不審なAzureテナントやサブスクリプションの作成を検知するためのMicrosoft Defender for Cloudのアラート設定も見直す価値がある。 ユーザー啓発 「Microsoftの署名があるから安全」という思い込みは今回で完全に否定された。エンドユーザー向けのセキュリティ教育において、この点を明確に伝える必要がある。 筆者の見解 今回の件を見て、「よくやった」と「なぜここまで見逃したのか」が同時に頭をよぎった。 コード署名という信頼の根幹をなすインフラを不正利用され、1,000件超の証明書が発行されるまで検知・停止できなかった事実は軽視できない。「Microsoftの署名 ＝ 安全」という前提が攻撃者に徹底的に利用された形であり、正直なところもったいないと感じる。Azure Artifact Signingの設計には、このような大量不正発行を早期に検知するための仕組みが不十分だったということだ。 その一方で、DCUが法的措置を含む大規模な摘発に踏み切ったことは素直に評価したい。インフラ破壊だけでなく、裁判所への提訴とVanilla Tempestへの共謀者認定まで踏み込んだ姿勢は、業界全体への抑止効果をもたらすはずだ。 今回の根本的な教訓は「署名ベースの信頼モデルには限界がある」という点に尽きる。ゼロトラストアーキテクチャの観点では、コード署名はあくまで信頼判断の「ヒントの一つ」であって、それだけで実行許可を与えてはいけない。振る舞い検知、最小権限の実行環境、ネットワーク通信の監視——これらを組み合わせた多層防御が今こそ不可欠だ。 Microsoftにはぜひ、今回の経験をサービス設計にフィードバックしてほしい。「次に同様の悪用が始まったら数日以内に止められる」というレベルの検知・対応品質向上を、応援する立場として強く期待している。 ...

AIアプリケーション向けのオープンソースベクターデータベース「ChromaDB」の Python FastAPI 実装に、CVSS スコア 10.0（最高深刻度）の脆弱性（CVE-2026-45829）が発見された。セキュリティ企業 HiddenLayer が2月に報告したこの欠陥は、インターネットに公開されたサーバーに対して、認証なしで任意コードを実行できるという深刻なものだ。 ChromaDB とはどんなミドルウェアか ChromaDB は、LLM（大規模言語モデル）推論の際に意味的に関連するドキュメントを高速に取得するための「ベクターデータベース」だ。RAG（Retrieval-Augmented Generation）アーキテクチャを採用するエージェント型AIアプリケーションで広く使われており、PyPI からの月間ダウンロード数は約1,400万件に達する。近年の生成AIブームを背景に、スタートアップから大企業まで多数のプロジェクトで採用が進んでいる。 脆弱性の仕組み——「認証は存在するが、場所が間違っている」 HiddenLayer の分析によれば、問題の本質は認証機能の欠如ではなく、認証チェックの実行順序が誤っている点にある。 攻撃者が細工したリクエストを送ると、ChromaDB は Hugging Face から悪意ある機械学習モデルを取得してローカルで実行する。認証チェックが走るのはその後であり、時点では手遅れだ。サーバーはリクエストを拒否して HTTP 500 を返すが、攻撃者のペイロードはすでに動いている。 HiddenLayer はこれを次のように端的に表現している。「認証は実装されているが、実行される順番が間違っている。認証が発火する頃には、モデルはすでにフェッチされ実行済みだ」 こうした「チェックより先に処理が走ってしまう」設計上の欠陥は、ミドルウェアレイヤーで発生すると被害範囲が広くなりやすく厄介だ。 影響範囲と現状 対象バージョン: ChromaDB 1.0.0〜1.5.8（Python FastAPI サーバー） 非対象: ローカル限定デプロイ / Rust フロントエンド使用環境 **インターネット公開インスタンスの約73%**が脆弱なバージョンを稼働中（Shodan 調査より） バージョン 1.5.9 がリリース済みだが、本脆弱性が修正済みかどうかは執筆時点で未確認 HiddenLayer はメール・SNS 経由で複数回連絡を試みたが、開発者から返答なし 実務での対応ポイント この脆弱性への対処は「ChromaDB を使っているかどうか」の確認から始まる。 即時確認すべき事項 公開 API の棚卸し: ChromaDB の Python API サーバーポートがインターネットや社内 LAN に無防備に開放されていないか確認する バージョン確認: pip show chromadb でバージョンを確認し、1.0.0〜1.5.8 なら対応が必要 Rust フロントエンドへの切り替え: 公開が必要な環境では、影響を受けない Rust 版フロントエンドへの移行を検討する ネットワークレベルの遮断: ファイアウォールや NSG で ChromaDB API ポートへのアクセスを信頼できるホストのみに絞る ML モデルアーティファクトの事前スキャン: trust_remote_code=True でモデルをロードすることは、未検査コードをそのまま実行するに等しい。ランタイム前のスキャンを運用フローに組み込む クラウド上でRAGシステムを構築・運用しているチームは今すぐデプロイ構成を見直したい。開発環境でローカルにのみ起動しているケースは対象外だが、Kubernetes や Docker で外部公開している場合は要注意だ。 ...

Microsoft は2026年5月7日、Microsoft 365 CopilotおよびMicrosoft EdgeのCopilot Chatに影響するCritical評価の情報漏洩脆弱性を3件公開し、同日中にクラウド側での修正を完了した。エンドユーザーや管理者による追加対応は不要とされているが、Copilotに付与されたデータアクセス権限の設計を見直す契機として受け止めるべき事案だ。 3件の脆弱性——何が起きていたのか 今回公開されたのはCVE-2026-26129、CVE-2026-26164、CVE-2026-33111の3件で、いずれも機密情報漏洩（Information Disclosure）を引き起こしうるインジェクション系の脆弱性だ。 CVE-2026-26129 はMicrosoft 365 CopilotのBusiness Chat機能が対象。ダウンストリームコンポーネントへの出力で特殊文字が適切に処理されない（CWEでいうインジェクション系）ことで、ネットワーク経由で機密情報が漏洩する可能性があった。 CVE-2026-26164 も同じくM365 Copilotを対象とし、CWE-74（インジェクション）に分類される。攻撃ベクターはネットワーク経由、特権不要・ユーザー操作不要という条件で、CVSS スコアは7.5（時間的スコア6.5）。機密性への影響は「高」と評価されている。Microsoftの社内研究者であるEstevam Arantesと独立研究者の0xSombraの連名で発見が報告された。 CVE-2026-33111 はMicrosoft Edgeに組み込まれたCopilot Chat機能に影響し、CWE-77（コマンドインジェクション）に分類される。CVSSスコアはCVE-2026-26164と同じく7.5/6.5で、攻撃プロファイルも同様。エンタープライズ環境でEdgeの展開が広がっていることを考えると、潜在的な影響範囲は無視できない。 Microsoftは「いずれも公開前の悪用は確認されていない」と明言しており、クラウド側のサービス層でパッチを適用済みだ。 なぜAIツールが情報漏洩リスクの新たな標的になるのか 今回の事案が単なるパッチ情報以上の意味を持つのは、Microsoft 365 Copilotというサービスの性質にある。 Copilotはユーザーの指示に応じてメール、ドキュメント、Teamsの会話、SharePointのファイルなど、組織内の膨大なデータを横断的に参照・要約する。つまり、単一エンドポイントへの攻撃が、従来のファイルサーバー侵害では得られなかった「横断的な情報収集」を可能にしてしまう構造になっている。 インジェクション系の脆弱性がAIの出力パイプラインに潜むと、攻撃者はCopilotが生成したレスポンスの中に細工された要素を混入させ、信頼境界を越えて機密情報を引き出せる可能性がある。メールの内容、社内の機密文書、制限付き記録などが、正規ユーザーに成りすました形で漏洩しうる。 日本の企業IT担当者がすべき対応 「クラウド側で修正済みだから終わり」で済ませてほしくない事案だ。具体的に確認しておくべき点を挙げる。 1. Copilotのアクセス権限を最小化する Copilotは設定次第で組織内のほぼすべてのデータにアクセスできる。「使いやすさ」優先でデフォルトのまま運用している場合、脆弱性が悪用されたときの影響範囲が最大化してしまう。SharePointの権限設計、センシティブなラベル付きコンテンツへのCopilotアクセス制御を今すぐ確認すること。 2. Microsoft Purview との連携を確認する Microsoft Purviewの機密ラベル（Sensitivity Labels）を正しく設定していれば、CopilotはラベルベースのDLP（データ損失防止）ポリシーに従って動作する。ラベル付けが不完全な環境では、攻撃面は広いままだ。 3. Edge の Copilot Chat の利用範囲を把握する CVE-2026-33111はEdge組み込みのCopilot Chatに関するものだ。エンタープライズ向けにEdgeを標準ブラウザとして展開している組織では、Copilot Chatの機能制限ポリシー（EnterpriseNewTabPageHideDefaultTopSites や Copilot 関連のグループポリシー）を整備しておくことを勧める。 4. 今後の同種脆弱性に備えた監視体制を構築する MicrosoftはクラウドCVEの透明性イニシアティブとしてこれらを公開している。同様の開示が今後も続く可能性が高い。Microsoft Security Response Center（MSRC）のフィードを定期的に監視し、Copilot関連の更新情報をキャッチアップする運用フローを確立しておこう。 筆者の見解 Microsoftが今回の脆弱性を「クラウドCVE透明性プログラム」として積極的に開示したこと自体は、正しいアプローチだと思う。悪用の事実なし、ユーザー対応不要、公開と修正を同日実施——この対応のスピードと透明性は評価に値する。 ただ、根本的な問いは別にある。「AIが組織データを横断的に集約・処理する」というアーキテクチャそのものが、インジェクション系脆弱性と組み合わさったとき、従来のエンドポイント侵害では得られなかったレベルの情報収集を攻撃者に提供してしまう——この構造的リスクに、われわれは真剣に向き合う必要がある。 Copilotにブロードなアクセス権を付与して「AIがなんでも答えてくれる」状態を作るのは、セキュリティの観点ではJust-In-Timeとは真逆の設計だ。「常時アクセス可能」が特権アカウント管理における最大リスクであるのと同じ原則が、AIエージェントにも適用される。Non-Human Identityとしての Copilot にどこまでアクセスを許可するか——この問いを真剣に設計フェーズで議論していた組織は、今回の件でもリスクを最小化できていたはずだ。 Microsoftには、Copilotの権限モデルと最小権限設計を、もっとわかりやすく・導入しやすい形でユーザーに提供してほしい。技術的には実現できる力がある会社なのだから、セキュリティを後付けではなくアーキテクチャの中心に置いた設計を見せてくれると、Copilot全体への信頼回復にも繋がるはずだ。 出典: この記事は Critical Microsoft 365 Copilot Vulnerabilities Expose Sensitive Information の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft（マイクロソフト）が、Teams（チームズ）サポートチームに寄せられる「最も対処が厄介な問題」のひとつについて、その原因と解決策を公式に説明した。多くのユーザーやIT管理者を長年悩ませてきたこの問題に、シンプルな修正方法があることが明らかになった。 「よくある、でも解決しにくい」Teamsの問題とは Microsoft Teamsのサポートチームが「最もフラストレーションを引き起こす」と表現する問題群の多くは、アプリのキャッシュ破損や設定ファイルの不整合に起因することが多い。具体的な症状としては： メッセージや通知が正しく表示されない プレゼンス（在席状況）が更新されない・誤った状態で表示される 会議への参加が遅くなる、または接続が不安定になる 再インストールしても問題が再現する これらの問題に共通しているのが「再起動しても直らない」という点だ。多くのユーザーがアプリを再起動しても改善せず、最終的にIT部門に問い合わせる流れになる。 Microsoftが説明する根本原因と修正手順 Microsoftのサポートチームが公式に示したのは、Teamsのキャッシュを手動でクリアするというシンプルな手順だ。ただし、単純に「キャッシュを削除」と言っても、正しい手順を踏まないと解決しない場合がある。 Windows版 Teams（新Teams）のキャッシュクリア手順 Microsoft Teamsを完全に終了する（タスクトレイのアイコンも右クリックで「終了」） Win + R でファイル名を指定して実行を開く %appdata%\Microsoft\Teams を入力してEnter フォルダ内の以下のサブフォルダを削除（フォルダ自体は残す）: Cache blob_storage databases GPUCache IndexedDB Local Storage tmp Teamsを再起動し、サインインし直す 新しいTeams（Teams 2.0）の場合は、アプリ上部の「…」メニューから設定を開き、「アプリのキャッシュをクリア」オプションを使う方法もある。 なぜ「再インストールだけでは直らない」のか 多くの場合、再インストールはアプリの実行ファイルだけを置き換えるため、ユーザープロファイルフォルダ内に残ったキャッシュや設定ファイルがそのまま引き継がれる。これがTeams問題の「再インストールしても再現する」という特性の原因だ。 特に企業環境では、複数のMicrosoftアカウントや条件付きアクセス（Conditional Access）ポリシーが絡み合うことで、キャッシュの不整合が発生しやすい。リモートワーク環境でネットワーク切り替えが頻繁に起きると、さらに問題が起きやすくなる。 IT管理者・エンジニアへの実務ポイント ヘルプデスク対応の効率化に直結する この手順をナレッジベースに登録しておくことで、一次サポートで解決できるケースが大幅に増える。「Teamsの動作がおかしい」と問い合わせが来た際に、まずキャッシュクリアを試してもらうトリアージフローを作成しておくと効果的だ。 エンドポイント管理（Intune等）での自動化 Microsoft Intuneを使って管理されている端末であれば、PowerShellスクリプトでキャッシュクリアを自動実行する仕組みを組み込むことも可能だ。問題が頻発するユーザーグループに対してスクリプトをプッシュ配布する運用も現実的な選択肢になる。 新Teamsへの移行完了を確認する 従来の「クラシックTeams（Teams 1.0）」はすでにサポートが終了している。まだ旧Teamsを使っている環境がある場合、今回のような問題以外にも多くの既知不具合を抱えたまま使い続けることになる。この機会に組織内の移行状況を確認することを勧める。 筆者の見解 Teamsは今や日本企業の多くで業務インフラの中核を担っている。その重要性が高まっているからこそ、「再起動しても直らない」「再インストールしても再現する」という問題は現場の生産性に直結するダメージを与え続けてきた。 Microsoftがこうした「サポート現場の定番問題」について公式に発信し、ナレッジを整理してくれることは、IT部門にとって素直に助かる動きだ。 とはいえ、本来であればキャッシュ破損がここまで頻繁に起きること自体、アプリの堅牢性として改善の余地がある。ユーザーが手動でキャッシュを削除しなければならない状況が「よくある問題」として定番化してしまっているのは、決して望ましい状態ではない。 MicrosoftはTeams 2.0への移行でアーキテクチャを刷新しており、この点の改善を期待している。ユーザーがアプリの内部構造を意識せずに使えるようになってこそ、真の「使いやすいコラボレーションツール」と言えるはずだ。Teamsが持つポテンシャルは本物だから、そこに見合った安定性を追求し続けてほしい。 企業のIT担当者は、今回の手順をヘルプデスクの標準フローに組み込みつつ、チケット数の推移を観察しておくと良いだろう。もしキャッシュクリアで解決しないケースが多発するようなら、ネットワーク設定や認証基盤側の問題を疑う必要がある。 出典: この記事は Microsoft explains simple fix for one of the most “frustrating” Teams issues の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月、Microsoftアカウント（個人向け）のSMSコード認証を段階的に廃止すると公式に発表した。SIMスワップ詐欺やフィッシングへの脆弱性を理由に、パスキー（Passkey）・Microsoft Authenticatorアプリ・副メールアドレスへの移行を強制する方針だ。 SMSが「もう安全ではない」理由 SMS認証は長年、二要素認証（2FA）の代名詞として広く使われてきた。しかし、その実態は構造的に脆弱だ。 通信経路の脆弱性: SMSは平文で携帯電話ネットワーク上を流れる。技術的に傍受が可能な経路が存在する SIMスワップ攻撃: 攻撃者が携帯キャリアを騙してあなたの電話番号を自分のSIMに移管させる手口。成功すれば、SMSの2FAコードはすべて攻撃者に届く フィッシング耐性ゼロ: 偽サイトに誘導してコードを入力させるだけで突破できる Microsoftのサポートドキュメントでは「SMS認証は現在、詐欺の主要な経路となっている」と明言している。これに基づき、個人向けMicrosoftアカウントのSMS認証およびSMS経由のアカウント回復を段階的に終了する。 パスキーとは何か パスキー（Passkey）は、FIDO2/WebAuthn標準に基づくフィッシング耐性の高い認証方式だ。パスワードやSMSコードの代わりに、デバイスに内蔵された生体認証ハードウェアで本人確認を行う。Windows環境では以下が使える。 Windows Hello: 顔認証（IRカメラ）または指紋スキャナー デバイスPIN: TPMチップと紐づいたローカルPIN パスキーの核心は秘密鍵がデバイスから出ない点にある。認証のたびに公開鍵暗号方式でチャレンジに署名するが、その秘密鍵はTPM（Trusted Platform Module）に閉じ込められている。リモートからの攻撃でこれを盗み出すことは原理的に不可能だ。 デバイスを紛失した場合は、iCloud キーチェーン（Apple）やGoogle パスワードマネージャーと同期したパスキー、または登録済みの副メールアドレスでアカウント回復が可能だ。 実務への影響 エンジニア・開発者への影響 移行において最も注意が必要なのは、自動化スクリプトやCIパイプラインでMicrosoftアカウントを使っている場合だ。SMS認証に依存したサービスアカウント的な使い方をしていると、移行後に認証が通らなくなる可能性がある。 対策として以下を今すぐ確認してほしい。 サービスアカウントはEntra ID（旧Azure AD）に移行する: 個人向けMicrosoftアカウントではなく、Entra IDのサービスプリンシパルやマネージドIDを使うべきだ。自動化ワークフローに個人アカウントを使っている場合は移行のタイミングだ Microsoft Authenticatorを今すぐ設定する: プッシュ通知による承認で手間が少ない。SMS廃止前に切り替えておくことで、移行時の混乱を避けられる 副メールアドレスの登録を確認する: SMS廃止後の重要な回復手段となる。アカウント設定から登録状況を必ず確認しておくこと IT管理者への影響 企業内でMicrosoftアカウントを使った個人端末（BYOD）管理をしている場合、ユーザーへの事前周知と移行支援が必要になる。「SMSで受け取っていたコードが届かなくなった」というヘルプデスク問い合わせが急増する可能性がある。移行期限の前に社内アナウンスと移行手順書の整備を進めておきたい。 筆者の見解 SMS認証の廃止は、セキュリティの観点から見ればむしろ遅すぎたくらいだ。SIMスワップ攻撃はすでに現実的な脅威として各国で被害が出ており、「電話番号は本人確認の手段にならない」という認識はセキュリティ業界では常識になっている。 パスキーへの移行は、ゼロトラストアーキテクチャの「デバイスと認証を紐づける」という方向性と完全に一致している。秘密鍵がデバイスのTPMから出ない設計は、フィッシングによる認証情報の盗用を根本から断ち切る。技術的には正しい判断だ。 ただし、心配なのは移行の届け方だ。今回のSMS廃止の告知が「サポートドキュメントにひっそり掲載」という形だったのは気になる。技術的に優れた判断を下すのと同じくらい、ユーザーへの丁寧な移行支援が重要だ。セキュリティを向上させる意図は正しい——あとはその「伝え方」と「サポート」で、Microsoftの本気度が問われる。パスキーが本当に「誰にでも使えるもの」になるよう、移行体験の磨き込みに力を注いでほしい。 出典: この記事は Microsoft is killing SMS codes for Microsoft account sign-in, aggressively pushes passkeys on Windows 11 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

SentinelOneの研究者が2026年5月、macOSを標的とするインフォスティーラー「SHub」の新亜種「Reaper」を発見した。Appleが2026年3月に実装したTerminalベースのセキュリティ対策を巧みに迂回し、AppleScriptを悪用してApple公式のセキュリティ更新ダイアログを偽装する手口が確認されている。Google Chrome・Firefox・Microsoft Edge・1Password・MetaMask・iCloudなど、日常業務でよく使うあらゆるデータが標的だ。 AppleのTerminal対策をわずか数ヶ月で迂回した新手法 従来のSHubは「ClickFix」と呼ばれる手口を使い、ユーザーに悪意あるコマンドをTerminalに貼り付けて実行させていた。Appleは2026年3月にmacOS Tahoe 26.4でTerminalへのコマンド貼り付け・実行をブロックする対策を追加した。 Reaperはこれを回避するため、macOSの正規機能であるapplescript:// URLスキームを利用する。このスキームを使うとmacOSのスクリプトエディタが起動し、悪意あるAppleScriptがあらかじめ読み込まれた状態になる。ユーザーが「実行」ボタンをクリックすると、Apple公式のXProtectRemediatorを引き合いに出した偽セキュリティ更新メッセージが表示され、curlでシェルスクリプトをダウンロードし、zshで静かに実行される仕組みだ。 悪意あるスクリプトのコマンド部分はASCIIアートの下に隠されており、静的解析を困難にしている。 感染前に実施される精密なターゲット偵察 Reaperは感染を試みる前に、訪問者のデバイスを詳細に調査する。 仮想マシン（VM）の利用有無 VPNの使用状況 インストール済みブラウザ拡張機能（パスワードマネージャー・仮想通貨ウォレット） これらのテレメトリデータはTelegramボット経由で攻撃者に送信される。分析環境や研究者のマシンへの感染を避けるための措置だ。また、感染実行前にロシア語キーボード・入力メソッドの使用を確認し、一致した場合はC2サーバーへ「cis_blocked」イベントを送信して処理を中断する——いわゆるCIS圏除外の実装だ。 窃取対象：ブラウザからウォレットアプリ本体まで Reaperが標的とするデータの範囲は広い。 ブラウザデータ: Google Chrome、Mozilla Firefox、Brave、Microsoft Edge、Opera、Vivaldi、Arc、Orion 仮想通貨ウォレット拡張機能: MetaMask、Phantom パスワードマネージャー拡張機能: 1Password、Bitwarden、LastPass デスクトップウォレットアプリ: Exodus、Atomic Wallet、Ledger Live、Electrum、Trezor Suite その他: iCloudアカウントデータ、Telegramセッションデータ、開発者向け設定ファイル さらに「Filegrabber」モジュールがデスクトップと書類フォルダを走査し、財務情報が含まれそうなファイル（2MB以下、PNGは6MB以下、合計150MB上限）を収集する。 ウォレットアプリが存在する場合はより悪質な攻撃が加わる。正規アプリのプロセスを強制終了し、コアファイルをC2サーバーからダウンロードした悪意あるapp.asarに丸ごと置き換える。Gatekeeperによる警告を回避するためxattr -crでファイルの隔離属性を削除し、アドホックコード署名で正規アプリに偽装する。 感染経路：偽WeChat・Miroインストーラー ユーザーへの初期誘導には、実在するアプリを模倣した偽インストーラーが使われた。qq-0732gwh22[.]com（WeChatを模倣）、mlcrosoft[.]co[.]com（Microsoftを模倣）、mlroweb[.]com（Miroを模倣）といったドメインが使用されている。Miro偽装ドメインは現在は正規サイトへリダイレクトされているが、WeChat偽インストーラーは依然として配信中だという。なお、WindowsおよびAndroid向けダウンロードボタンはDropboxにホストされた同一の実行ファイルを配信していることも確認されている。 実務への影響 日本のMac利用者、特に以下のような環境では直ちに注意が必要だ。 リモートワーク・副業エンジニア: 個人のMacを業務に使うケースが多く、ブラウザ内の認証情報や開発者設定ファイルが標的になりやすい。 仮想通貨・Web3関連業務: Reaperはウォレットアプリそのものを置き換える手口を持つため、資産喪失のリスクが直接的だ。 IT管理者への推奨事項: MDMポリシーでmacOSのスクリプトエディタ（Script Editor）の起動を制限することを検討する エンドポイントセキュリティ製品の導入・シグネチャ更新を徹底する ユーザー向け周知徹底：「AppleはWebサイトのダイアログ経由でシステムパスワードを要求しない」という一点を組織全体に浸透させる 筆者の見解 セキュリティ領域は正直、得意分野とは言いにくい。が、この攻撃手法の技術的な巧妙さには素直に驚かされる。 Appleが2026年3月にTerminal対策を追加してからわずか数ヶ月で迂回バリアントが登場した——これは「OSベンダーによるパッチとマルウェア開発者の攻防は終わらない」という冷静な現実を改めて示している。applescript://スキームを通じてScript Editorを悪用する手法は、macOSの正規機能を逆手に取った典型だ。Appleがこのスキームにも制限をかければ、攻撃者はまた別の正規機能を探してくる。いたちごっこの構造は変わらない。 一方で救いがあるとすれば、感染の最後のステップは依然として「ユーザーが実行ボタンをクリックする」という人の操作にある。技術的な回避策と同等に、ユーザー教育が有効に機能する余地がまだある。「Appleが公式セキュリティ更新をブラウザのダイアログで提供することはない」——この認識を組織のユーザー全員が持っているだけで、相当数の感染を防げるはずだ。 ゼロトラストの観点でも示唆は大きい。ウォレットアプリがapp.asarを丸ごと置き換えられてしまう脆弱性は、アプリ側の自己整合性検証の甘さでもある。認証・認可を人からNHI（Non-Human Identities）に移行する議論が進む中、アプリ自体の改ざん検知も同様に重要な課題として認識してほしい。 出典: この記事は SHub macOS infostealer variant spoofs Apple security updates の内容をもとに、筆者の見解を加えて独自に執筆したものです。

INTERPOLは2026年5月、中東・北アフリカ地域を対象にしたサイバー犯罪摘発作戦「Operation Ramz」の成果を発表した。フィッシング・マルウェア・オンライン詐欺に使われていたサーバー53台を押収し、200人超を逮捕。さらに13か国で382人を新たな容疑者として特定している。 作戦の規模と成果 今回の対象となったのは、アルジェリア・バーレーン・エジプト・イラク・ヨルダン・レバノン・リビア・モロッコ・オマーン・パレスチナ・カタール・チュニジア・UAE の13か国。押収した機器から回収した約8,000件の情報パッケージを解析した結果、少なくとも3,867人の被害者が確認されている。 INTERPOLは「この作戦はフィッシングやマルウェアの脅威の無力化に加え、この地域に深刻な経済的損害をもたらすサイバー詐欺の撲滅に焦点を当てた」と声明を出している。 各国で明らかになった犯罪の実態 各国で押収・摘発された事例は、サイバー犯罪の多様化と組織化を如実に示している。 カタール: 知らぬ間にマルウェア配布に利用されていた一般市民の端末を特定・保護した。 ヨルダン: 投資詐欺を組織的に運営するネットワークを解体。アジアから人身売買された15人の労働者が詐欺業務を強制実行させられていたことが判明し、主犯格2人を逮捕した。 オマーン: 機密データを含む脆弱なマルウェア感染サーバーを無効化した。 アルジェリア: フィッシングをサービスとして提供する「PhaaS（Phishing-as-a-Service）」プラットフォームを閉鎖し、容疑者1名を逮捕した。 モロッコ: フィッシング操作に関連する端末および銀行データを押収し、複数の容疑者が司法調査下に置かれた。 官民連携が解体の鍵 今作戦で注目すべき点は、INTERPOLが複数の民間サイバーセキュリティ企業と連携して悪意のあるインフラを追跡した点だ。Kaspersky・Group-IB・The Shadowserver Foundation・Team Cymru・TrendAI が協力し、法執行機関だけでは追いきれない技術的な追跡を担った。 こうした官民パートナーシップは、現代のサイバー犯罪捜査において不可欠な構造になりつつある。攻撃者がクラウドインフラや国境を越えた分散型インフラを使う以上、国家単独の法執行には限界がある。 今年3件目の大規模摘発——グローバルな取り組みが加速 Operation Ramz は、INTERPOLが今年（2026年）完了した3件目の大規模サイバー犯罪摘発作戦となる。 2月「Operation Red Card 2.0」: アフリカ16か国で651人逮捕。投資詐欺・モバイルマネー詐欺・偽ローンアプリが対象で、被害額は計4,500万ドル超。 3月「Operation Synergia III」: 72か国にわたる作戦で、悪意あるIPアドレス4万5,000件をシンクホール化、212台のデバイス・サーバーを押収し94人を逮捕。 5月「Operation Ramz」: 今回の中東・北アフリカを中心とした作戦。 一連の作戦を並べてみると、INTERPOLが地域を変えながら組織的にサイバー犯罪インフラを潰す戦略を取っていることがわかる。 実務への影響——日本のエンジニア・IT管理者が知っておくべきこと 「中東での話だから関係ない」と思ったら危険だ。今回押収されたフィッシング・マルウェアのインフラは、地理的な境界を問わず日本企業のユーザーを標的にできる。特に以下の点を日常業務に取り込んでほしい。 フィッシング対策の再確認: PhaaS（フィッシング・アズ・ア・サービス）の摘発が今回も含まれていた。攻撃者がサービスとして詐欺インフラを「レンタル」できる現在、攻撃の敷居は下がる一方だ。メールフィルタリング・多要素認証（MFA）・セキュリティ意識向上トレーニングは基本中の基本として維持すること。 インフラの可視化: 「知らぬ間にマルウェア配布に使われていた端末」がカタールで見つかったように、自社の端末・サーバーが攻撃インフラの一部として悪用されるリスクは現実にある。EDR（エンドポイント検出・対応）ツールの導入と、定期的なアウトバウンド通信のレビューが有効だ。 サプライチェーン・人的リスクの認識: ヨルダンの事例では、人身売買された労働者が詐欺業務を強制されていた。サプライチェーン上のパートナー企業の倫理的側面まで考慮に入れるセキュリティ評価が重要になっている。 官民連携の活用: Shadowserver Foundation のような非営利組織は、悪意あるインフラに関する情報を無償で提供している。自社のIPアドレスレンジを登録してアラートを受け取るだけでも、初動対応のスピードが変わる。 筆者の見解 サイバー犯罪に対する国際的な法執行の動きが、ここ数年で明らかに加速している。今回のOperation Ramzが示す最も重要な変化は、「技術力を持つ民間企業と法執行機関が組んで犯罪インフラを解体する」モデルが本格的に機能し始めたことだ。Kaspersky・Group-IB・Shadowserver といった組織が情報提供し、INTERPOLが法的執行力を行使するこの構造は、今後のサイバー犯罪対策の標準形になるだろう。 一方で、今回見えてきた課題も看過できない。PhaaS（フィッシング・アズ・ア・サービス）のようなサービス化が進むことで、技術力の低い攻撃者でも高度なフィッシングキャンペーンを展開できる状況が定着しつつある。サーバーをいくつ押収しても、インフラがクラウド上に瞬時に再構築できる現在、「摘発のイタチごっこ」から根本的に抜け出すには、攻撃インフラへの資金流入を断つ金融面でのアプローチが不可欠だと感じる。 日本のIT現場に目を向けると、セキュリティ対策がまだ「境界防御」の発想から抜け出せていない組織が多い。今回押収されたサーバーのような外部インフラが実際に自社ユーザーを狙っているとき、VPNベースの「内側は安全」という思想では対処しきれない。ゼロトラスト的な発想——すべての通信を検証し、最小権限で動かす——への移行を、今こそ本気で進めるべきタイミングだ。理論としてはわかっているはずの組織も、実際の移行が止まっているケースが多い。今回のような事例を「遠い国の話」で終わらせず、自社の設計を見直すきっかけにしてほしい。 出典: この記事は INTERPOL ‘Operation Ramz’ seizes 53 malware, phishing servers の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Linuxカーネルのrxgkモジュールに存在するローカル特権昇格脆弱性「DirtyDecrypt（別名：DirtyCBC）」の概念実証コード（PoC）が公開された。CVE-2026-31635として追跡されるこの脆弱性は4月25日にパッチ済みだが、まだ最新カーネルに更新していないシステムは依然リスクにさらされている。 DirtyDecryptとは何か DirtyDecryptは、Linuxカーネルのrxgkモジュール内、rxgk_decrypt_skb関数におけるCOW（Copy-On-Write）ガードの欠如によって引き起こされる脆弱性だ。このガードがないことで、ページキャッシュへの不正書き込みが可能となり、結果的に一般ユーザーがroot権限を取得できる。 ローカル特権昇格（LPE）のため、リモートから直接悪用することはできない。しかし、クラウドVM・マルチユーザーサーバー・コンテナエスケープ後といった「なんらかの手段でローカルアクセスを得た攻撃者」がいる状況では、root奪取につながる致命的な脆弱性となりうる。 セキュリティ研究チームのV12が2026年5月9日に独立発見・報告したものの、メンテナーから「パッチ済みの重複報告」と通知された経緯がある。 影響を受けるLinuxディストリビューション 本脆弱性の悪用には、カーネルのCONFIG_RXGK設定オプションが有効になっている必要がある。これはAFS（Andrew File System）クライアントのRxGKセキュリティサポートを有効化するオプションで、最新のアップストリームカーネルを積極的に追従しているディストリビューションに限られる。 現時点で影響が確認または懸念される環境： Fedora（PoCによる動作確認済み） Arch Linux openSUSE Tumbleweed Ubuntu LTS・Debian stable・RHEL・CentOS Streamなど、保守的なカーネルポリシーを持つディストリビューションは現時点では影響を受けない可能性が高い。 即時対応：パッチ適用が最優先 最善策はカーネルを最新版に更新することだ。 出典: この記事は Exploit available for new DirtyDecrypt Linux root escalation flaw の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月、Windows 11向け累積セキュリティ更新プログラム「KB5089549」の一部デバイスへのインストールが失敗する問題を公式に認め、回避策を公開した。 何が起きているのか 問題の根本原因は、EFIシステムパーティション（ESP）の空き容量不足だ。特にESPの空き容量が10MB以下のデバイスで顕著に発生する。 更新プログラム適用の流れとしては、インストール自体は最初のフェーズまで正常に進むものの、再起動フェーズの進捗が35〜36%付近でロールバックが始まる。ユーザーには「Something didn’t go as planned. Undoing changes.（問題が発生しました。変更を元に戻しています。）」というメッセージが表示される。 システムログには以下のようなエントリが残るため、原因特定の手がかりになる： SpaceCheck: Insufficient free space ServicingBootFiles failed. Error = 0x70 SpaceCheck: <値> used by third-party/OEM files outside of Microsoft boot directories エラーコードとして報告されるのは 0x800f0922 だ。 回避策：Known Issue Rollback（KIR）の活用 Microsoftは現時点で根本的な修正を開発中としており、当面はKnown Issue Rollback（KIR）と呼ばれるWindowsの機能を使った回避策を案内している。KIRは、Windows Updateを通じて配信された問題のあるアップデートをロールバックする仕組みだ。 企業の管理環境でIT部門がWindows Updateを制御している場合は、グループポリシーを手動でインストール・設定することで対応できる。設定後はデバイスの再起動が必要で、グループポリシーは問題の原因となっている変更を一時的に無効化する。 KIRグループポリシーの展開・設定手順はMicrosoftサポートサイトで公開されている。 今月のWindows Updateを巡る問題の連鎖 KB5089549は4月2026年のWindows 11アップデートが引き起こしていたBitLocker回復画面への強制起動問題の修正も含んでいた。しかし今度は別の問題が浮上した格好だ。 加えてMicrosoftは今月、以下の問題も対応・確認している： Windows Autopatchのバグ：管理ポリシーで制限されているはずのドライバー更新が、EU内のAutopatch管理デバイスに誤って展開されていた問題 4月のセキュリティ更新：脆弱なドライバーを使用するサードパーティ製バックアップアプリケーションで障害が発生する問題 更新プログラムが更新プログラムの問題を修正し、また別の問題を生む——こうした状況が続いている。 日本のIT管理者・エンジニアへの実務ポイント 影響確認の優先手順： 管理下のWindows 11デバイスのESP空き容量を確認する（diskpart や PowerShell で Get-Partition コマンドから確認可能） 10MB以下の空き容量しかないデバイスを優先的に特定し、KB5089549の適用を保留するか、KIRグループポリシーを事前に展開する エンドポイント管理ツール（Microsoft Intune、Microsoft Endpoint Configuration Manager等）を使っている場合は、展開リングの前段階（パイロットグループ）での動作確認を徹底する ESPの空き容量不足が発生しやすいケース： ...