Windows

オーストラリア政府のサイバーセキュリティ機関ACSC（Australian Cyber Security Centre）が2026年5月、「ClickFix」と呼ばれるソーシャルエンジニアリング手法を悪用してVidar Stealerマルウェアを拡散するキャンペーンに対し正式な警告アドバイザリを発出した。攻撃者は侵害済みのWordPressサイトを踏み台にし、被害者を偽のCloudflare認証画面へ誘導してPowerShellコマンドを手動実行させるという巧妙な手口を使っている。 ClickFix攻撃の仕組み：「自分で実行させる」が防御を難しくする ClickFixは近年急速に普及しているソーシャルエンジニアリング攻撃手法だ。その特徴は、マルウェアを直接ダウンロードさせるのではなく、ユーザー自身に悪意のあるコマンドを実行させる点にある。 典型的な攻撃フローは以下の通りだ： 侵害済みWordPressサイト（または悪意のあるサイト）にユーザーが誘導される 偽のCloudflare認証画面または偽CAPTCHAが表示される 「確認のためにこの操作が必要です」と称してPowerShellコマンドをコピーするよう促される ユーザーがコマンドをPowerShellに貼り付けて実行するとVidar Stealerに感染する この手口が危険なのは、セキュリティソフトによる検知を回避しやすい点だ。ユーザー自身がコマンドを実行するため「正当なユーザー操作」として処理されてしまう。偽のCloudflare認証ページは精巧に作られており、一般ユーザーが本物と区別するのは困難な状況になっている。 Vidar Stealer：8年の歴史を持つ情報窃取マルウェア Vidar Stealerは2018年末から活動を続ける老舗のマルウェアだ。MaaS（Malware-as-a-Service）モデルで提供されており、技術力のない攻撃者でも容易に利用できる。標的にするデータは幅広い： ブラウザのパスワード・Cookie・オートフィル情報 暗号資産ウォレット（MetaMaskなど） システム情報全般 近年では機能強化版もリリースされており、感染後に実行ファイルを自己削除してメモリ上でのみ動作するなど、フォレンジック調査を困難にする機能が追加されている。 さらに厄介なのがC2（コマンド＆コントロール）通信の手法だ。TelegramボットやSteamのプロフィールページなどの公開サービスを「デッドドロップ（dead-drop）」として悪用し、攻撃者の本当のC2サーバーアドレスを取得する仕組みになっている。一般的なファイアウォールでは公開サービスへのアクセスを遮断しにくいため、この手口は検知を大幅に難しくする。 今すぐ確認すべき具体的な対策 ACSCは以下の対策を推奨しており、日本の組織にも直接適用できる。 PowerShell実行ポリシーの制限 PowerShellの実行ポリシーを AllSigned または RemoteSigned に設定し、署名のないスクリプトの実行をブロックする。一般ユーザーに不必要なPowerShell実行権限を与えないことが重要だ。グループポリシーで組織全体に適用することを推奨する。 アプリケーション許可リストの導入 Windows Defender Application Control（WDAC）やAppLockerを活用し、許可されていないアプリケーション・スクリプトの実行を防ぐ。完璧な許可リストの構築は工数がかかるが、まずPowerShellの制限だけでもClickFix攻撃の大部分を防げる。 WordPressサイト管理者向け対策 テーマとプラグインを最新バージョンに即時更新 使用していないテーマ・プラグインは即刻削除 ファイル変更の監視ログを有効化し、定期的にレビュー IoC（侵害指標）の確認 ACSCの公式アドバイザリにはIoCが掲載されている。SIEMやEDRにルールを追加し、既存の侵害がないか確認することを強く勧める。 実務への影響 ClickFix攻撃は2024年末から急増しており、日本でも同様の手法による攻撃が報告されている。特に懸念されるのは次の3点だ。 エンドユーザー教育だけでは防げない: 「怪しいリンクを踏むな」的なセキュリティ教育だけでは防ぎきれない。偽CAPTCHAは非常に本物に近く、「確認のためにコマンドを実行する」という操作自体が不自然に感じられない状況が作られている。技術的な制御との組み合わせが必須だ。 侵害WordPressサイトの連鎖リスク: 自社が直接攻撃されるのではなく、取引先や業界関連サイトが踏み台にされるケースが多い。自社WordPressサイトのセキュリティ強化は、自社だけでなくサプライチェーン全体の防御に繋がる。 テレワーク環境でのリスク増大: 社内ネットワーク外で業務するユーザーが増えた現在、エンドポイント保護とゼロトラストアーキテクチャの整備がますます重要になっている。VPNに依存した境界防御型の構成では、エンドポイントが侵害された後の横展開を止める手段が乏しい。 筆者の見解 ClickFix攻撃が厄介なのは、技術的な脆弱性ではなく「人間のクセ」を突いてくる点だ。「確認のためにこのコマンドを実行してください」という指示に、ユーザーは悪意なく従ってしまう。これは教育でカバーするには限界がある。 PowerShell実行の制限やアプリケーション制御は、管理者にとって実装の手間が伴う対策だ。特にIT環境が成熟していない組織では「今動いているからとりあえず」の運用が続きがちで、このような技術的制御が後回しにされる現実がある。 しかしVidar Stealerが奪うのは「ブラウザに保存されたパスワード全件」だ。業務システムのアクセス情報、クラウドサービスのセッションCookie、サービスアカウントの認証情報が一度に漏れる可能性を考えると、その被害は組織の機能停止レベルに達しうる。Non-Human Identity（NHI）管理の観点でも、サービスアカウントの認証情報が盗まれた場合の影響範囲は通常の人間アカウントより広くなりやすい。 ACSCのアドバイザリは、今週中にでもPowerShell実行ポリシーの現状設定を確認する動機として十分だ。完璧なゼロトラスト環境の構築は長期目標でいいが、「まず手軽にできる一手」から始めることが現実的で効果的な防御策になる。 出典: この記事は Australia warns of ClickFix attacks pushing Vidar Stealer malware の内容をもとに、筆者の見解を加えて独自に執筆したものです。

SentinelLabsが2026年5月に公開したレポートで、「PCPJack」と名付けられた新たなマルウェアフレームワークの存在が明らかになった。このワームは外部に露出したDocker・Kubernetes・Redis・MongoDB・RayMLなどのクラウドインフラを標的に侵入し、OpenAIやAnthropicのAPIキー、SSHキー、Slackトークンなど多数の認証情報を窃取する。その上、競合するクラウド脅威グループ「TeamPCP」の痕跡を完全消去しながら自らの勢力を拡大するという異例の動作が確認されている。 PCPJackとは何か PCPJackは、Linuxベースのクラウドシステムを標的とするマルウェアフレームワークだ。SentinelLabsの調査によると、TeamPCPの元アフィリエイトまたはメンバーが独自オペレーションを立ち上げた可能性が高いとされている。 TeamPCPは、AquaセキュリティのTrivyスキャナーやLiteLMM・Telnyx・SAPのnpmパッケージへのサプライチェーン攻撃で知られるクラウド特化型の脅威グループだ。PCPJackはTeamPCPの初期キャンペーン（2025年12月）と類似した手口を使うことから、この関連性が推測されている。 感染経路と動作機構 PCPJackはLinuxシステムに対し、シェルスクリプト「bootstrap.sh」を実行することで感染を開始する。主な動作フローは以下のとおりだ： 初期侵入: Docker・Kubernetes・Redis・MongoDB・RayMLなどの露出したサービスをスキャンし、既知の脆弱性を悪用してアクセスを取得 TeamPCP排除: 侵入直後、競合するTeamPCPのプロセス・サービス・コンテナ・ファイル・永続化アーティファクトをすべて削除 環境構築: 隠しワーキングディレクトリの作成、Pythonモジュールのダウンロード、メインオーケストレーター（monitor.py）の起動 認証情報窃取: クラウド環境・開発者システム・メッセンジャー・金融サービス等から認証情報を収集 横展開: SSHキーとクレデンシャルを使ってネットワーク内の他ホストへ侵入 永続化: systemdサービス、cronジョブ、Redis cronリライト、特権コンテナを利用 窃取した認証情報は、X25519 ECDH + ChaCha20-Poly1305で暗号化された後、2,800バイト単位に分割されてTelegramチャンネルへ送信される。 標的となる認証情報・サービス PCPJackが狙う認証情報の範囲は広い： クラウドAPI: OpenAI APIキー、Anthropic APIキー、DigitalOceanトークン 開発者ツール: SSHキー、GitHubトークン、Slackトークン データベース: MongoDB、Redis Webサービス: WordPress設定ファイル、Discord インフラ: Kubernetes設定、Dockerデーモン情報 悪用される脆弱性（CVE） PCPJackが利用する脆弱性は以下のとおり： CVE 対象 内容 CVE-2025-29927 Next.js ミドルウェアの認証バイパス CVE-2025-55182 React / Next.js Server Actionsのデシリアライゼーション欠陥 CVE-2026-1357 WPVivid Backup 未認証ファイルアップロード CVE-2025-9501 W3 Total Cache mfuncコメント経由のPHPインジェクション CVE-2025-48703 CentOS Web Panel Filemanagerのシェルインジェクション 実務への影響：日本のエンジニア・IT管理者が取るべき行動 即座に確認すべき事項 1. クラウドサービスの露出状況を確認する Docker APIポート（2375/2376）、Redis（6379）、MongoDB（27017）、Kubernetes API（6443）が外部に開放されていないか今すぐ確認する。セキュリティグループやファイアウォールルールを見直すこと。 ...

Microsoftが公式に公開したWindows 11のレジストリ設定を使うことで、Google ChromeとMicrosoft Edgeがユーザーに通知なくバックグラウンドで自動ダウンロードする約4GBのオンデバイスAIモデルを、IT管理者がブロックできるようになった。 ChromeとEdgeが「ひっそり」4GBをダウンロードしている実態 Googleはここ数年、Chrome内に「Gemini Nano」と呼ばれるオンデバイスの大規模言語モデル（LLM）を統合する取り組みを進めてきた。要約生成、文章作成支援、スマートリプライといったChrome組み込みのAI機能を支えるモデルで、クラウドではなくローカルで動作するのが特徴だ。Microsoft Edgeでも同様の動作が確認されている。 問題は、このモデルのサイズが約4GBに達しており、ユーザーへの明示的な通知なしにバックグラウンドで自動ダウンロードが実行される点にある。一般ユーザーはほとんど気づかない一方で、IT管理者の間からはストレージ消費・帯域幅使用・データポリシー整合性の観点から懸念の声が上がっていた。 公式レジストリ設定による制御 Microsoftはこの状況に対応し、Windows 11向けの公式レジストリ設定を提供した。ChromeやEdgeのエンタープライズポリシーに対応するレジストリキーを設定することで、大容量AIモデルの自動ダウンロードをブロックできる。 グループポリシーオブジェクト（GPO）またはMicrosoft Intuneを使った展開にも対応しており、企業全体のデバイスへの一括適用が可能だ。個別PCへのレジストリ直接編集だけでなく、既存のデバイス管理基盤から標準的な手順で制御できるのは実務上の大きなメリットとなる。 なぜこれが日本のIT現場で重要か 日本の企業環境では、以下の場面でこの設定が特に有効だ。 帯域幅の管理: 地方拠点や海外拠点など回線が細い環境、あるいはVDI・RDS環境では、端末1台あたり4GBのバックグラウンドダウンロードが積み重なると業務通信に支障をきたす可能性がある。特に大規模展開時は見えないところで相当な帯域を消費していることになる。 ストレージと資産管理: 標準構成PCのSSDが128〜256GB程度の組織では、予告なく消費される4GBはディスク管理とインベントリ管理の双方に影響する。 コンプライアンスとデータポリシー: オンデバイスとはいえ、透明性の不十分な状態でのモデルダウンロードは、社内情報セキュリティポリシーの審査対象になりうる。特に金融・医療・公共セクターでは、AI処理の透明性要件が厳しくなりつつある。 Intune経由でポリシーを展開できれば、IT部門が追加工数をかけずに全社員端末への制御適用が可能だ。 筆者の見解 「ブラウザが4GBのモデルをひっそりダウンロードしていた」という事実は、IT管理者の立場からすると看過できない。帯域幅・ストレージ・データポリシーのすべてにおいて問題をはらんでいる。 ただし、ここで大切なのは「禁止するかどうか」より「制御できるかどうか」という視点だ。禁止を強行しても、ユーザーは個人端末や別の手段を使い始め、むしろシャドーIT化が進む。IT部門が公式の制御手段を持ち、「管理された状態でAI機能を使える環境」を整えることが本筋だろう。 MicrosoftとGoogleが公式のポリシー設定を提供したこと自体は、エンタープライズ管理の観点から正しい方向だ。IT管理者としては、この設定を把握した上で、禁止一辺倒ではなく組織のニーズに合わせた適切な判断をしてほしい。「使わせない」ではなく「安全に使える仕組みを作る」——その姿勢が、AIが当たり前になったこれからの時代の基本スタンスになる。 出典: この記事は Official Windows 11 Registry mod blocks automatic download of 4GB AI model on Google Chrome の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Googleが数週間前から予告していたスクリーンレスフィットネスバンド「Fitbit Air」を正式発表した。Whoop対抗を明確に意識した製品で、同時にサブスクリプションサービス「Fitbit Premium」と「Health Coach」のブランド刷新も行われた。 Fitbit Airとは何か Fitbit Airは、従来のスマートウォッチとは一線を画す「スクリーンレス」設計のフィットネスバンドだ。画面を持たないことでバッテリー持続時間の延長と装着感の改善を実現し、24時間常時装着を前提としたデバイスとして設計されている。 競合として意識されているのは、米国のフィットネスウェアラブル市場で急成長を続ける「Whoop」だ。Whoopは同様にスクリーンを持たず、睡眠・回復・ストレインのトラッキングに特化したサブスクリプション型デバイスとして知られる。Fitbit AirはこのWhoopが切り開いた「スクリーンレス・サブスク型ウェアラブル」市場に、Googleブランドと既存のFitbitエコシステムを武器に参入する格好だ。 Fitbit Premium / Health Coachのブランド刷新 今回の発表と同時に、Googleはサブスクリプションサービスの名称を整理した。「Fitbit Premium」と「Health Coach」という2つのブランドが統合・リブランドされる。詳細なサービス内容の差異は今後明らかになるが、ユーザーにとっては利用中のサービス名称が変わる可能性があるため、設定画面やアプリの通知に注意が必要だ。 なぜこれが重要か ウェアラブルデバイス市場は「何でもできるスマートウォッチ」と「特定用途に特化した専門デバイス」の二極化が進んでいる。Apple WatchやGalaxy Watchがあらゆる機能を詰め込む方向性を取る中、WhoopやOura Ringのような「ミニマリスト型ウェアラブル」が特にヘルスコンシャスなユーザー層から支持を集めてきた。 Googleにとっては、Fitbitを2021年に買収して以来の製品戦略の転換点とも言える。これまでFitbitはスクリーン付きのトラッカーやスマートウォッチに注力してきたが、Fitbit Airによってより広いユーザー層——特に「健康管理はしたいが、スマートウォッチほど高機能なものはいらない」という層——へのアプローチが可能になる。 実務への影響 日本市場での展開に注目 Fitbit Airの日本展開時期・価格はまだ不明だが、競合のWhoopが日本市場でも存在感を持ちつつあることを考えると、Googleブランドの参入は市場を活性化する可能性がある。 IT管理者・企業担当者へのポイント ウェアラブルデバイスを従業員の健康管理プログラムや健保組合の取り組みに組み込んでいる企業では、今後のFitbit Premium（新ブランド）のプランや機能変更を確認しておくことを推奨する。特にGoogle Workspaceとの連携機能が拡充される可能性があり、企業向け健康管理ソリューションとしての活用余地が広がるかもしれない。 デバイス管理の観点 スクリーンレスデバイスはMDM（Mobile Device Management）の管理対象にはなりにくいが、収集する健康データのプライバシーポリシーと、Google/FitbitアカウントへのデータSyncについては、企業利用前にポリシー確認が必要だ。GDPRや個人情報保護法の観点からも、健康データの取り扱いは慎重に検討したい。 筆者の見解 健康トラッキングの文脈で面白いのは、「画面をなくす」という逆張りの設計思想だ。スマートフォン依存が問題視される中、通知を受け取らず、チェックしたくなる画面もない——これは単なる機能削減ではなく、デバイスとの付き合い方を根本的に見直した提案とも取れる。 Googleのウェアラブル戦略は、Fitbit買収後も一貫性が見えにくかった印象がある。しかしFitbit Airは、明確なターゲット（Whoopユーザー層）と明確なコンセプト（スクリーンレス・健康特化）を持つ製品として、久しぶりに「方向性のある製品」に映る。 筆者が注目するのは、GoogleのAI基盤がこのデバイスにどう統合されるかだ。単なるセンサー機器に留まるか、Googleの健康AI戦略のフロントエンドとなるかで、製品の評価は大きく変わる。サブスクリプションサービスの中身次第で、Whoopとの差別化軸が決まるだろう。「道のド真ん中を歩く」設計思想で言えば、過度な多機能化を避けてヘルストラッキング一本で勝負するこの方向性は、ある意味で正しいアプローチだと感じている。 出典: この記事は Google rebrands Fitbit Premium and Health Coach as it launches new Fitbit Air の内容をもとに、筆者の見解を加えて独自に執筆したものです。

翻訳サービス大手のDeepLが、100人以上の従業員を解雇し、「AIネイティブ企業」への転換を正式に発表した。Google翻訳の有力対抗馬として知名度を高めてきたDeepLが、自社の中核技術であるAIによって内部の人員を削減するという、皮肉とも取れる構造転換が現実となった。 DeepLとは——翻訳品質で差別化してきた技術企業 DeepLはドイツ・ケルンを拠点とする翻訳テクノロジー企業で、2017年のサービス開始以来、欧州語を中心とした高品質な機械翻訳で支持を集めてきた。特にビジネス文書や技術文書の翻訳精度は長年評価が高く、企業の多言語対応ツールとして日本国内でも広く採用されている。 2023年以降、大規模言語モデル（LLM）の台頭により翻訳市場全体が激変。OpenAIのGPT-4やGeminiなどのモデルが翻訳タスクでも実用水準に達したことで、専業翻訳AIとして戦うDeepLの立ち位置は大きく変わった。 「AIネイティブ」への転換とは何を意味するか 「AIネイティブ企業」への移行とは、単にAIツールを導入するということではなく、組織の意思決定・業務プロセス・人員構成そのものをAI前提で再設計することを意味する。 今回の100人超の解雇は、従来は人間が担っていた業務——品質保証、コンテンツレビュー、翻訳評価、一部のプロダクト運営——がAIに置き換えられたことの直接的な結果とみられる。 DeepLのような翻訳専業企業でさえ社内業務の相当部分をAIに移管できるとすれば、翻訳以外の産業においても、同様の構造変化は時間の問題と言える。 日本のIT現場への影響——「対岸の火事」ではない 日本でも法人向けにDeepL Proを導入している企業は多い。今回の動きがサービス内容を直接変えるわけではないが、より大きな問いを突きつけている。 影響を受けやすいポジション： 翻訳・ローカライズ担当者（社内外） コンテンツレビュー・QAチーム 多言語対応のカスタマーサポート 技術文書の多言語化を担う部門 実務での活用ポイント DeepL APIを利用している開発者・IT管理者は以下の点を今のうちに整理しておきたい。 1. サービス動向の注視 AIネイティブ化に伴いAPIの仕様・価格体系が変わる可能性がある。依存度の高い企業は変更通知の受け取り設定を確認しておこう。 2. 冗長構成への移行検討 DeepL単体に依存した多言語パイプラインは脆弱性になりうる。複数のLLM APIと組み合わせた構成を検討する時期だ。 3. 「人間-AI協働モデル」の方針を明文化する AI翻訳の出力をどのレベルまで人間がレビューするか、組織としての方針を曖昧なままにしない。判断の基準がないまま削減を進めると、品質管理がブラックボックス化する。 筆者の見解 DeepLという翻訳AIの会社が、自分たちが開発したAI技術によって社内の人員を削減する——この構造は、今後あらゆる業種で繰り返されるパターンの先行事例として記憶されるだろう。 仕組みを作れる少数の人間と、それを回すAIで組織は成立する時代になった。これは極論でも未来の話でもなく、今まさに起きていることだ。問題は、日本企業の多くがこの変化の速度を過小評価していることにある。「AIを使ってみよう」という段階の話ではなく、「人員構成そのものをAI前提で見直す」という意思決定が問われている。DeepLが今回示したのはその覚悟の一例だ。 ただし、すべてをAIに任せれば良いという単純な話でもない。AIの出力を評価・監査できる人材が組織内にゼロになった瞬間、品質管理はブラックボックスになる。最後の砦として人間の判断を残す設計——この視点を持たずにAIネイティブ化だけを進めると、後に高くつく失敗を招く可能性がある。 変化は止まらない。だが「何をAIに任せ、何を人間が担うか」を設計できる組織だけが、この転換を本当の意味で乗り越えられる。 出典: この記事は AI just took the jobs of over 100 people at DeepL の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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