Windows

Linuxデスクトップの最前線を走るKDE Plasmaが、Waylandの新しいフラクショナルスケーリングプロトコル「xx-fractional-scale-v2」のサポートを進めていることが、KDEチームの「This Week in Plasma」アップデートで明らかになった。HiDPIディスプレイが当たり前になった今、この対応はLinuxデスクトップ環境の実用性を大きく底上げする可能性がある。 Waylandとフラクショナルスケーリング、何が問題だったのか WaylandはX11を置き換えるべく開発が進む次世代ディスプレイサーバープロトコルだ。セキュリティ面やパフォーマンス面でX11を大きく上回るが、長年の課題の一つが「非整数倍スケーリング（Fractional Scaling）」の扱いだった。 4Kや高解像度ディスプレイでは200%（2倍）のスケーリングでは大きすぎ、100%（等倍）では小さすぎる、という場面が多い。150%や125%といった「非整数倍」での表示が求められるわけだが、既存の wp-fractional-scale-v1 プロトコルでは実装ごとに挙動がばらつき、アプリケーションによってはボケた表示やレイアウト崩れが生じるケースがあった。 xx-fractional-scale-v2が解決すること 新プロトコル「xx-fractional-scale-v2」は、この問題に正面から取り組む設計となっている。主な改善点は以下の通りだ。 クライアント側のレンダリング精度向上: アプリケーションが正確なスケール情報を取得できるようになり、自前でシャープな描画ができる コンポジター（KWin等）との連携強化: デスクトップ環境とアプリ間のスケール情報のやり取りが標準化され、実装差異が減る マルチモニター環境での整合性: 異なるDPIのモニターを混在させても、ウィンドウ移動時の再スケーリングがより自然になる KDEのコンポジターであるKWinがこのプロトコルに対応することで、KDE Plasmaアプリだけでなく、GTKアプリやElectronベースのアプリも恩恵を受けられる可能性がある。 実務への影響 — 日本のエンジニア・IT管理者にとって Linux開発環境を業務で使うエンジニアにとって、この変更は無視できない。特に以下のような場面で恩恵が大きい。 開発者向けワークステーション: 4Kモニターや高DPIラップトップでLinuxを使うエンジニアは増えている。IDEやコードエディターの表示がシャープになり、目の疲れ軽減にもつながる。 Dockerデスクトップ・WSL2 GUI: WSL2でLinux GUIアプリをWindows上で動かす構成では、Waylandプロトコルの動作品質がそのままユーザー体験に直結する。Windowsとのインターフェース層が改善されると、この構成の安定性も向上する可能性がある。 Linuxシンクライアント環境: 一部の日本企業では、セキュリティポリシー上Linuxシンクライアントを採用しているところがある。HiDPIディスプレイへの移行が容易になることは、運用コスト面でもプラスだ。 今すぐ試したい場合は、KDE Plasmaの開発版（nightly build）をFlatpakや各ディストリビューションのテストリポジトリから入手して動作確認するのが現実的なアプローチだ。本番環境への適用は安定版リリースを待つのが無難だろう。 筆者の見解 Waylandへの移行は「もうすぐ完成する」と言われ続けて久しいが、フラクショナルスケーリングの標準化という地味ながら本質的な問題にプロトコルレベルで取り組んでいる点は評価に値する。インフラの整備は派手さがないが、それがあってこそ上位レイヤーのアプリが正しく動く。 面白いのは、このような「ディスプレイスケーリングの標準化」という課題は、WindowsのHiDPI対応の歴史とも重なることだ。Windowsも長年、レガシーアプリのDPI非対応問題と格闘してきた。プラットフォームが変わっても、ディスプレイの高解像度化に追いつくのは一筋縄ではいかないということだろう。 KDEは以前から、Wayland対応において他のデスクトップ環境より積極的にプロトコルの拡張・実験を行ってきた。xx-fractional-scale-v2の採用もその延長線上にある。実用的なデスクトップを作るというコミットメントが、こういった地道な取り組みに表れている。引き続き、Plasma 6.x系の完成度が高まっていく過程を注目して見ていきたい。 出典: この記事は KDE is getting support for the xx-fractional-scale-v2 Wayland protocol の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Samsungが、長年Galaxy端末のデフォルトとして親しまれてきた「Samsung Messages」を廃止し、「Google Messages」へ完全移行する方針を発表した。単なるアプリの入れ替えに見えるが、この決定はAndroidエコシステムの構造変化を象徴する出来事として注目に値する。 Samsung Messagesとは何だったのか Samsung Messagesは、Galaxy端末に標準搭載されてきた純正SMSアプリだ。シンプルなSMS/MMSの送受信から始まり、長年にわたってGalaxyユーザーの「当たり前の存在」だった。しかし近年、Google MessagesがRCS（Rich Communication Services）への対応を積極的に進め、既読確認・高画質メディア送信・エンドツーエンド暗号化といった機能を取り込んだことで、Samsung Messagesとの機能差は急速に広がっていった。 なぜ今、廃止なのか SamsungがGoogle Messagesへの統合を選んだ背景には、いくつかの合理的な判断がある。 RCS普及の加速: Appleが2024年にiOS 18でRCSをサポートしたことで、RCSは事実上の次世代SMSとして確立されつつある。Google MessagesはAndroid陣営でのRCS推進役であり、Samsung独自実装を維持するコストよりも、Googleのエコシステムに乗っかる方が利用者体験を向上させやすい。 重複投資の排除: 同じメッセージング機能を二社が並行開発・保守するのは明らかに非効率だ。Samsungとしては、差別化の薄いコモディティ領域から撤退し、リソースをカメラやディスプレイ、Galaxy AIなど競争優位のある領域に集中させる判断は理にかなっている。 ユーザー体験の一貫性: GoogleとSamsungの間に存在した微妙な機能差や互換性の問題が解消されることで、エンドユーザーにとっては混乱が減る。 実務への影響——IT管理者・エンジニアが知っておくべきこと 日本のエンジニアやIT管理者にとって、この変更は以下の点で実務的な意味を持つ。 MDM管理の見直し: 企業向けにGalaxy端末を管理しているIT部門は、Samsung MessagesとGoogle Messagesでポリシーの適用方法が異なる場合がある。Samsung Knox経由での制御とGoogle管理の挙動の違いを事前に確認しておくことを勧める。特にSMS/MMSの送受信制限やデータ保持ポリシーを適用している環境では影響が出やすい。 RCS対応の機会: これを機に、社内コミュニケーションのRCS化を検討するのも一手だ。ただし、RCSはキャリア側の対応状況に依存するため、日本国内の主要キャリアのサポート状況を確認した上で判断してほしい。 移行タイミングの把握: SamsungはGalaxy端末ユーザーに対して移行期限を設けているため、BYOD（私物端末の業務利用）を許可している組織では、ユーザーへの事前周知が必要になる。移行後もSMSの送受信機能自体は継続されるため、業務影響は限定的と考えられるが、設定やデータ移行でのサポート問合わせが増える可能性はある。 セキュリティ面の確認: Google MessagesはRCSチャット使用時にエンドツーエンド暗号化を提供しているが、SMSは従来通り平文送信であることに変わりはない。機密情報を扱う業務では、引き続き専用のセキュアメッセージングツールを使用するポリシーを維持すべきだ。 筆者の見解 この動きを「Samsungの敗北」と見るのは単純すぎる。むしろ、重複した投資を整理してエコシステム全体を効率化するという、健全な判断だと評価したい。プラットフォームの全体最適という観点からも、機能が重複するアプリを並存させ続けるより、一本化して品質を上げる方が利用者にとって良い結果をもたらすことが多い。 一方で、自社アプリを終了してプラットフォーマーのアプリに委ねるという選択には、長期的なコントロールを手放すリスクも伴う。Samsungのような巨大メーカーですら、この種のトレードオフから無縁ではない。 より本質的な示唆は、メッセージングという機能が完全にコモディティ化したということだ。ユーザーが独自SMSアプリにブランドロイヤリティを感じる時代は終わった。今後は「どのメッセージングアプリか」よりも「どのプロトコルで通信しているか」が重要になる。RCSが本格普及すれば、メッセージングの土台はキャリアからインターネット層へと移っていく。その変化の加速を、今回の発表はあらためて教えてくれている。 出典: この記事は End of an era: Samsung is killing Samsung Messages in favor of Google Messages の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Next.jsを使ったWebアプリケーションを狙った、大規模かつ高度に自動化されたクレデンシャル窃取キャンペーンが確認された。Cisco Talosが今週公開したレポートによれば、「UAT-10608」と追跡される脅威クラスターが「NEXUS Listener」と呼ばれる専用フレームワークを駆使し、わずか24時間のうちに766ホストの侵害に成功している。 何が起きているのか——React2Shell（CVE-2025-55182）という「入り口」 今回の攻撃の起点となっているのが、CVE-2025-55182として採番されたReact2Shellという脆弱性だ。Next.jsアプリに存在するこの欠陥を悪用することで、攻撃者はシステム上でコマンドを実行できる状態を作り出す。 攻撃の流れはシンプルかつ効率的に設計されている。 インターネット上の脆弱なNext.jsアプリを自動スキャン React2Shellで初期侵入を確立 システムの一時ディレクトリに多段階クレデンシャル収集スクリプトを配置 収集した機密情報をHTTPポート8080経由でC2サーバー（NEXUS Listener）へ逐次送信 何が盗まれているのか——想像以上に広い収集範囲 Cisco Talosの研究者が実際にNEXUS Listenerの露出インスタンスへアクセスして分析した結果、収集対象は以下のとおりであることが判明した。 環境変数・シークレット: APIキー、データベース認証情報、GitHub/GitLabトークン SSHプライベートキー クラウドクレデンシャル: AWS・GCP・Azureのメタデータ、IAM認証情報 Kubernetesトークン Dockerコンテナ情報 コマンド履歴 プロセス・ランタイムデータ 特筆すべきは、これらが「あったら盗む」ではなく「ありそうな場所を全部狙う」という設計になっている点だ。AWSのインスタンスメタデータから始まりKubernetesのサービスアカウントトークンに至るまで、クラウドネイティブ環境で使われる機密情報のほぼすべてが収集対象に含まれている。 実務への影響——日本のエンジニア・IT管理者が今すぐ確認すべきこと この攻撃が厄介なのは、被害が侵入されたサーバー単体に留まらない点だ。盗まれたSSHキーは横移動（ラテラルムーブメント）に使われ、クラウドのIAM認証情報はアカウント乗っ取りを可能にし、GitHubトークンはサプライチェーン攻撃の扉を開く。さらにCisco Talosは、個人情報の漏洩によるプライバシー法規制上のリスクも指摘している。日本ではGDPR同等の個人情報保護法への対応が求められる組織も多く、他人事ではない。 今すぐ実施すべき対応策： React2Shellのセキュリティアップデートを即時適用する。 対象システムが特定できない場合、Next.jsを使ったアプリをすべてリストアップするところから始める 侵害の疑いがある場合はクレデンシャルをすべてローテーションする。 「たぶん大丈夫」で済ませてはいけない AWSを使っている場合はIMDSv2を強制する。 IMDSv1が有効なままだとメタデータエンドポイントへの不正アクセスリスクが残る コンテナ・クラウドロールの最小権限原則（Least Privilege）を徹底する。 広すぎる権限は、侵害されたときの被害を指数関数的に拡大させる WAF/RASPをNext.jsアプリの前段に配置する。 シグネチャベースの検知だけでは限界があるが、それでも攻撃コストを上げる効果は大きい シークレットスキャンを有効化する。 GitHubであればSecret Scanningが標準で使える。誤ってコードにクレデンシャルを書いてしまった経験は誰にでもある 筆者の見解 この種の攻撃を見るたびに思うのは、「防御の難しさ」より「そもそもの設計」の問題だということだ。Next.jsアプリのサーバー環境に、AWSのIAMクレデンシャルからKubernetesのサービスアカウントトークンまで、なぜそれほど多種多様な機密情報が置かれているのか。利便性を優先して一台のサーバーに何でも詰め込んでしまうと、一点突破で全部持っていかれる。 「Just-In-Time」なアクセス管理と最小権限の原則は、耳にタコができるほど繰り返されてきた話だが、今回の766ホストという数字は、それが実態に落とし込まれていないことを示している。常時発行されているクレデンシャルが多いほど、盗まれたときのダメージは大きい。環境変数に長期有効なAPIキーを何十個も持つ構成は、攻撃者にとって宝の地図をまるごと渡すようなものだ。 ゼロトラストの文脈で言えば、ネットワーク層・認証層・認可層の3層すべてで独立した防御を設計することが正道だ。どこか一層が突破されたとしても、次の層が機能していれば被害を最小化できる。今回のNEXUS Listenerのような自動収集ツールは今後さらに洗練されていく。一度壊れた信頼を取り戻すコストを考えれば、設計段階での投資は決して高くない。 出典: この記事は Hackers exploit React2Shell in automated credential theft campaign の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Fortinetが週末に緊急のセキュリティアップデートを公開した。FortiClient Enterprise Management Server（EMS）に発見された新たな重大脆弱性（CVE-2026-35616）が、すでに実環境での攻撃に悪用されていることが確認されたためだ。影響を受けるバージョンを運用中のIT管理者は、今すぐ対応が必要な状況だ。 脆弱性の概要：認証を完全に素通りされる CVE-2026-35616は、不適切なアクセス制御（Improper Access Control） に分類される脆弱性だ。攻撃者は認証なしで特細工されたリクエストを送信するだけで、サーバー上でコードやコマンドを実行できてしまう。 この脆弱性を発見したセキュリティ企業Defusedは、「プリオーセンティケーション APIアクセスバイパス」と説明している。つまり、ログイン前の段階で認証・認可の仕組みをまるごと迂回できるということだ。しかも同社は、Fortinetへの報告前にすでに攻撃者が悪用しているゼロデイであることを確認している。 影響を受けるバージョンと対処法 今回の脆弱性が影響するのは以下のバージョンだ： FortiClient EMS 7.4.5（ホットフィックス適用が必要） FortiClient EMS 7.4.6（ホットフィックス適用が必要） FortiClient EMS 7.2系は影響を受けない。 Fortinetは各バージョン向けのホットフィックスを公開しており、7.4.7でも修正が含まれる予定となっている。まずは現行バージョン向けのホットフィックスを優先して適用するのが現実的な対応だ。 なお先週も別の重大脆弱性（CVE-2026-21643）が同じFortiClient EMSで報告・悪用されており、同じくDefusedが発見している。短期間に連続して重大な脆弱性が出ている点は注目に値する。 被害規模：インターネット上に2,000台超が露出 インターネットセキュリティ監視組織のShadowserverによると、FortiClient EMSのインスタンスが2,000台超インターネットに露出した状態で確認されている。主な分布は米国とドイツとされているが、日本のエンタープライズ環境でも導入実績のある製品だけに、国内での被害は他人事ではない。 実務への影響 FortiClient EMSはエンドポイントのセキュリティポリシーを一元管理するサーバーだ。ここが侵害されると、管理下のすべてのエンドポイントに対して任意のポリシーを配布できてしまう可能性がある。被害が拡大するまでの時間が短く、侵害の痕跡も残りにくいタイプの脆弱性だ。 IT管理者がまず確認すべき事項を整理する： バージョン確認: FortiClient EMSのバージョンが7.4.5または7.4.6かどうかを即確認する ホットフィックスの適用: 対象バージョンであれば、Fortinet公式のリリースノートからホットフィックスを取得して適用する 外部露出の確認: FortiClient EMSの管理ポートがインターネットに直接露出していないかを確認する。管理系サーバーをインターネットに直接さらすのは、それ自体が設計の問題だ ログの確認: 脆弱性が悪用されるゼロデイ期間中に不審なAPIアクセスがなかったかをログで確認する 筆者の見解 ゼロトラストアーキテクチャを推進する立場からすると、今回の脆弱性が突いているポイントは示唆的だ。「認証を通らなければ安全」という前提が崩れたとき、その先に何の防御もなければ即座に終わりを迎える。 「管理サーバーはVPNの内側にあるから大丈夫」という感覚でいる環境も多いかもしれないが、ゼロトラストの観点では境界防御だけに頼ることは今や十分ではない。エンドポイント管理のような高権限サーバーへのアクセスには、ネットワーク層だけでなく認証層・認可層も多重に重ね、さらにJust-In-Time（JIT）アクセスのような「必要なときだけ権限を与える」仕組みを加えることが理想だ。 FortiClientはエンドポイントセキュリティの有力な選択肢として多くの現場で使われている。だからこそ、今回のような脆弱性が連続して発生することは残念だし、ユーザーとしては適切なパッチ適用サイクルを維持することが引き続き重要になる。「今動いているから大丈夫」は、こうした事態の前では通用しない。週末に緊急パッチが出た事実が、事の重大さを物語っている。 今すぐ自環境のバージョンを確認し、対象であれば業務時間を待たずに対応することを強く勧める。 出典: この記事は New FortiClient EMS flaw exploited in attacks, emergency patch released の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国で、交通違反の「督促通知」を装ったSMSフィッシングが新たな進化を遂げている。従来のリンク付きテキストメッセージから、裁判所通知の画像にQRコードを埋め込む手法へと切り替わり、セキュリティ研究者やフィルタリングシステムによる検知を意図的に回避しようとしている。 何が起きているのか 攻撃者は「ニューヨーク刑事裁判所」などの公的機関を名乗り、「未払いの交通違反がある。今すぐ支払わなければ法廷に出頭せよ」という内容のSMSを送りつける。メッセージには画像ファイルとして偽造された公式通知書が添付されており、その中にQRコードが印刷されている形をとっている。 QRコードをスキャンすると、まずCAPTCHA（人間確認）ページへ誘導される。これをクリアすると今度は州のDMV（車両管理局）を模倣したフィッシングサイトへリダイレクトされ、「未払い残高 $6.99」の支払い手続きを促す。最終的には氏名・住所・電話番号・メールアドレス・クレジットカード情報が盗まれる仕組みだ。 なぜ「画像＋QRコード」なのか この手法が巧妙なのは、セキュリティ対策の盲点を突いている点だ。 ① テキストリンクを含まない 多くのSMSフィルターやメールゲートウェイは、不審なURLを検出してブロックする。しかしQRコードは画像データであり、リンクとして認識されない。 ② CAPTCHAが自動解析を阻む 悪意あるURLを自動的にクロールして評価するサンドボックスや脅威インテリジェンスシステムは、CAPTCHAで足止めを食らう。人間が操作しなければ先に進めない構造にすることで、調査を困難にしている。 ③ 公的機関への擬態が心理的プレッシャーを生む 「裁判所」「法的措置」「最終警告」という言葉は、受信者に焦りを与える。冷静な判断を奪い、確認せずにQRコードをスキャンさせるための社会工学的な仕掛けだ。 日本への示唆——「対岸の火事」ではない この手口は米国固有の話ではない。日本でも宅配便の不在通知、ETC料金未払い、マイナンバー関連通知を装ったSMSフィッシング（スミッシング）はすでに広く観測されている。今後、同様の「QRコード画像添付型」が日本でも使われるのは時間の問題だろう。 特に注意が必要なのは、QRコードをスキャンする行為そのものがリスクという認識が、一般ユーザーにはまだ薄い点だ。URLを直接タップすることへの警戒心は高まっているが、「カメラをかざすだけ」のQRコードは無意識にスキャンしてしまいがちだ。 実務での対策ポイント エンドユーザーへの啓発として伝えるべきこと： 公的機関（裁判所・警察・行政）はSMSで支払いを求めない QRコードをスキャンする前に「誰から来たか」を一度立ち止まって確認する スキャン先のURLを確認し、公式ドメインでなければ閉じる（ny.gov-skd[.]org のような偽ドメインに注意） 少額請求（今回は$6.99、日本なら数百円程度）は心理的ハードルを下げるための罠 IT管理者・セキュリティ担当者として： モバイルデバイス管理（MDM）ポリシーで、業務端末でのQRコードスキャン先URLのフィルタリングを検討する エンドポイントのモバイルブラウザにも、フィッシング対策フィルターが有効かを確認する フィッシングシミュレーション訓練に「QRコード型」シナリオを追加する時期に来ている 筆者の見解 この事例を見て改めて感じるのは、攻撃者の方がセキュリティ対策の仕組みをよく理解しているという現実だ。テキストリンクが検出されるなら画像にする、URLスキャンが走るならCAPTCHAで止める——対策が進化するたびに、攻撃はその隙間を狙ってくる。 セキュリティの世界では「防御側は全部守らないといけないが、攻撃側は一点突破でいい」と言われる。だからこそ、技術的なフィルタリングだけに頼る発想には限界がある。ユーザーが「おかしいな」と感じて立ち止まれる習慣と知識を育てることが、結局は最も強固な防衛線になる。 組織のセキュリティ担当者としては、禁止や制限で固める方向に走りたくなる気持ちはわかる。しかし「QRコードスキャン禁止」のような硬直したポリシーは、業務での正当な利用まで阻害して形骸化する。「使える仕組みを安全に使える状態にする」という発想で、啓発と技術的補助を組み合わせるアプローチが現実的だと思っている。 今後、こうした攻撃がAI生成の精巧な偽通知画像と組み合わされれば、さらに見分けがつきにくくなる。攻撃手口の進化に対し、私たちの対策と啓発も継続的にアップデートし続けるしかない。 出典: この記事は Traffic violation scams switch to QR codes in new phishing texts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが「Copilot」という名前をつけた製品・機能の数が、ついに80種類に達したことが明らかになりました。アプリ、機能、プラットフォーム、ノートPCのカテゴリ名、そして物理的なキーボードキーまで——あらゆるものが「Copilot」を冠しています。この状況は、現場のIT管理者やエンジニアにとって決して他人事ではありません。 「80種類のCopilot」とは何か この数字を掘り起こしたのは、テクノロジーストラテジストのTey Bannerman氏です。「Microsoftのコパイロットとは何か」を誰かに説明しようとして説明できず、全種類をリスト化しようとしたところ、Microsoftの公式サイトや公式ドキュメントにさえ全リストが存在しないことが判明。製品ページ、ローンチアナウンス、マーケティング資料を横断的に調査してようやく地図を作り上げました。 80種類の内訳は大きく次のカテゴリに分類されます： スタンドアロンアプリ（Microsoft Copilot、Copilot+ PC向けアプリなど） Microsoft 365統合機能（Word・Excel・Teams・Outlook各Copilot） Azure・開発者向けプラットフォーム（GitHub Copilot、Azure AI Foundryのエージェント機能群） 業界特化型ソリューション（Security Copilot、Dragon Copilotなど） Copilot Studioおよびその派生（Copilotを作るためのCopilot） ハードウェアカテゴリ（Copilot+ PC、Copilotキー搭載キーボード） さらに今回の公開後、コミュニティから「Gaming Copilot」と「Microsoft Dragon Copilot」の存在が指摘され、即座に80へと更新されました。リストは現在進行形で増え続けています。 なぜこれが重要か——日本のIT現場への影響 日本のエンタープライズ環境では、Microsoft 365のライセンス体系はすでに相当複雑です。「Microsoft 365 Copilot」（月額約4,500円/ユーザー）と「Copilot（無料版）」の違いを正確に説明できる担当者は多くありません。そこへ80種類という現実が重なると、次のような問題が現場で発生します。 ライセンス購買の混乱 「Copilotを導入したい」という経営層の要望に対し、担当者がどのCopilotを指しているのか特定できない事態が起きています。Security CopilotとMicrosoft 365 Copilotでは価格も対象ユーザーも用途もまったく異なります。 サポート・トラブルシュートの困難 エラーが出たとき「Copilotの問題」とだけ書かれた問い合わせでは、どの製品・機能のことか確認するだけで時間を消費します。 社内教育コストの増大 新人や非IT部門のユーザーに「Copilotとは何か」を説明するドキュメントを作成しても、数ヶ月で情報が陳腐化する可能性があります。 実務での活用ポイント 1. 社内では「固有名詞」で呼ぶルールを徹底する 「Copilot」とだけ呼ぶのをやめ、「Microsoft 365 Copilot」「GitHub Copilot」「Security Copilot」と製品名を省略しない運用ルールを設けましょう。ドキュメントや社内チケットシステムへの記載も同様です。 2. 導入前に「どのCopilotか」を必ず確認するゲートを設ける 調達・承認フローに「対象製品の正式名称」を必須項目として追加するだけで、誤購入や重複契約を防げます。 3. Microsoft Learn / Tech Communityを製品名で検索する 「Copilot」単独では検索ノイズが多すぎます。目的の製品名をそのまま検索キーワードに使うことで、正確なドキュメントにたどり着けます。 4. Copilot Studioの位置づけを理解しておく 「Copilotを作るためのCopilot」であるCopilot Studioは、今後の自社エージェント開発の起点になり得ます。80種類の全体像を把握した上で、自社に必要なものだけに絞り込む判断軸として活用できます。 筆者の見解 正直に言えば、これは「命名の失敗」ではなく「命名戦略の迷走」だと思っています。 MicrosoftがAI機能を横断的にブランド統合しようとした意図は理解できます。ユーザーが「Copilotといえばマイクロソフト」とワンブランドで認識してくれれば理想的だったのでしょう。しかし80種類という数字は、その戦略が現場の認知コストを完全に無視した結果です。 Microsoftには、AzureとMicrosoft 365という世界最大規模のプラットフォームがあります。そのインフラの上でAI機能を展開できるポジションは、他社には簡単に真似できない強みです。だからこそ、「Copilotというブランドで全部押し通す」ような力技ではなく、機能の役割と対象が一目でわかる命名体系を整えてほしいと思うのです。 Microsoft Learnのドキュメントチームが日々追いつくのに苦労しているのも、Bannerman氏が独自調査なしにリストを作れなかったのも、すべて同じ根っこの問題です。「統合プラットフォームの全体最適」を掲げる企業が、製品名の体系だけはバラバラという状況は、もったいない。 Microsoftが持つリソースとユーザーベースであれば、この命名カオスを整理することは不可能ではないはずです。Copilotが「混乱のブランド」ではなく「信頼のブランド」として定着する日が来ることを、応援する立場から期待しています。 ...

Copilotが「フルEdge同梱」アプリとして再登場 Microsoftが Windows 11 向けに新しい Copilot アプリを展開し始めた。見た目は web.copilot.com とほぼ同一で、動作は滑らか。しかしその裏側を覗いてみると、なかなか驚くべき構成になっている。 アプリのインストールフォルダに 146.0.3856.97 というディレクトリが存在し、中身はほぼ完全な Microsoft Edge のインストールセット——msedge.exe、msedge.dll（315MB）、ffmpeg.dll、Vulkan/SwiftShader、WidevineCDM など、フル Chromium ブラウザエンジンが丸ごと格納されている。合計サイズは約 850MB だ。 仕組みとしては「Edge のフォーク版を WebView2 コンテナ内で専用アプリとして動かすハイブリッド構成」と整理できる。標準的な WebView2 や PWA であれば Windows 11 側に既にある Edge を共用するところを、Copilot は自前の Edge インスタンスを抱え込んで起動する形になっている。 メモリ使用量の現実 状態 RAM使用量 バックグラウンド（新版） 最大 500MB 操作時（新版） 最大 1GB 従来のネイティブ版 100MB 未満 単純比較で 10 倍以上のメモリを消費する計算だ。8GB 搭載マシンでは体感にも影響しうる数字である。 アーキテクチャ遍歴——4回目の設計変更 これが初めての方針転換であれば「戦略的な判断」で済む話だが、経緯を振り返るとそうとも言いにくい。 サイドバー統合型 Copilot（初期） PWA（Progressive Web App） WebView ベース ネイティブ WinUI アプリ（前バージョン） Edge 同梱ハイブリッド Web アプリ（今回）← ネイティブコードへの回帰から1年も経たないうちに、再び Web 技術主体の構成へ戻っている。インストール手順も Microsoft Edge インストーラーと同様の方式に変わり、Microsoft Store 経由でありながら「別ウィンドウで操作が必要」という警告が出る仕様になった。Microsoft Teams の配布方式と同じアプローチだ。 ...

クラウドで削除したらどこへ行くのか、がついに統一される 長年にわたって「地味に混乱を招いてきた」OneDriveの削除動作が、2026年5月に変わる。これまで、別のデバイスやWebブラウザーからOneDrive上のファイルを削除した場合、そのファイルがPC側のローカルごみ箱に送られることがあった。今後はこの挙動が廃止され、クラウド側で削除されたファイルはOneDriveのクラウドごみ箱のみに保持される仕組みに統一される。 Microsoftが発表したこの変更は、OneDriveの同期エンジンの根幹に関わるものだ。一見すると「ローカルの保護が薄くなった」ように映るが、実態は逆で、動作の整合性が高まったと見るべきだろう。 何がどう変わるのか 従来の動作 OneDriveの同期フォルダーに保存されたファイルを、Web UIや別のデバイスから削除した場合、同期によってローカルの実体ファイルも削除されるが、そのファイルはPC側のローカルごみ箱にも送られていた。つまり、ユーザーは次の2か所でファイルを復元できる状態だった。 OneDriveクラウドごみ箱（30日間保持） ローカルのごみ箱（ユーザーが明示的に空にするまで残る） 変更後の動作 2026年5月以降、クラウド側の操作で削除されたファイルはローカルごみ箱には送られない。復元先はOneDriveクラウドごみ箱のみとなる。ローカルで直接削除（Explorerで選んでDeleteキーを押す等）した場合は引き続きローカルごみ箱に送られる。 「ローカルの安全網がなくなる」は誤解 この変更を見て「危険になった」と感じる人もいるかもしれないが、それは誤解だ。OneDriveのクラウドごみ箱は、個人アカウントで削除後30日間、Microsoft 365 Business/Enterpriseでは最大93日間、ファイルを保持する。これは十分な猶予期間といえる。 むしろ整理すべきは「作り手の意図」だ。OneDriveはクラウドファーストのサービスとして設計されている。クラウドで削除したものはクラウドで管理する、という考え方は一貫しており、今回の変更はその設計思想への回帰だ。ローカルごみ箱を「第2の復元ポイント」として暗黙的に当てにしていた構成は、本来の使い方ではなかった。 実務への影響：IT管理者が今すぐやるべきこと エンドユーザーへの周知が最重要 最も対応が必要なのはエンドユーザーへの啓発だ。「ごみ箱に入ってるはず」と思ってローカルのごみ箱を確認して見つからず、パニックになるケースが増えることが予想される。「クラウドから消したらOneDriveのごみ箱を確認してください」 という一行の周知文でも、ヘルプデスクへの問い合わせを大幅に減らせる。 復元手順のドキュメント更新 社内のファイル復元手順書やFAQにOneDriveクラウドごみ箱の操作方法を追記しておこう。Web版OneDrive（onedrive.com）からごみ箱にアクセスする方法、OneDriveアプリから「ごみ箱を表示」する手順を具体的に示しておくと親切だ。 管理者はごみ箱の保持期間を確認 Microsoft 365管理センターでは、SharePoint/OneDriveのごみ箱保持期間を確認・変更できる。組織のデータ保全ポリシーと照らし合わせ、30日では不足するケースがないか確認しておきたい。コンプライアンス要件が厳しい業種では、Microsoft Purviewのアイテム保持ポリシーと組み合わせることで、さらに長期間の保護が実現できる。 筆者の見解 この変更の方向性は正しいと思う。OneDriveはずっと「クラウドが正」という設計で動いてきたのに、削除動作だけローカルにも副作用を出していたのは、明らかに設計の揺らぎだった。今回の統一化は、その揺らぎを解消するものとして歓迎したい。 ただし、今回改めて考えさせられるのは「OneDriveを正しく理解して使っているユーザーがどれだけいるか」という問題だ。同期フォルダーとクラウドストレージの違い、ファイルオンデマンドの仕組み、削除の伝播——これらをきちんと理解してOneDriveを運用している企業は、体感としてまだ少ない。 「作り手の意図を理解し、意図された使い方をする」。これはOneDriveに限らず、クラウドサービス全般に通じる原則だ。5月の変更を機に、自社のOneDrive利用実態を一度棚卸しする良いきっかけにしてほしい。管理者が能動的に動けるかどうかが、現場の混乱の大きさを左右する。 Microsoftがこうした地道な整合性改善を続けている点は、きちんと評価したい。派手さはないが、長く使われるプロダクトはこういった細部の積み重ねで成熟していく。 出典: この記事は Microsoft to stop sending cloud-deleted OneDrive files to local Recycle Bin の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年の秋、Windows 11に「26H2」と呼ばれる大型機能アップデートが届く。リリース形式はフル再インストールではなく「有効化パッケージ（Enablement Package）」——つまり機能はすでにOSに仕込まれており、スイッチを入れるだけで動き出す設計だ。企業の展開計画という観点でも見落とせない更新となる。 AIが検索体験を塗り替える「Ask Copilot」 最大の目玉は、タスクバーの検索ボックスをAI自然言語検索に置き換える Ask Copilot だ。従来のキーワード検索と異なり、「バッテリー設定を開いて」「ダウンロードフォルダを表示して」のような意図ベースの入力を解釈し、アプリ・ファイル・設定へのリンクを返す。重要なのはデフォルトでローカル処理という設計で、明示的に共有しない限りファイル内容がクラウドに送られることはない。 File Explorerにも変化が来る。右クリックメニューが再設計され、「パスのコピー」「圧縮」「回転」などの操作がグループ化されてスッキリする。さらにCopilotサイドパネルが統合され、対話形式でファイル操作を補助する機能がオプションで使えるようになる。 地味だが効く「UIリニューアル」 プロパティダイアログのダークモード対応は、パワーユーザーには長年の悲願だ。プロパティ画面だけが白く浮き上がるあの違和感がようやく解消される。Runダイアログ（Win+R）もWinUIベースに刷新され、視覚的にモダンになる。 通知エリアのカレンダーにはアジェンダビューが復活する。Outlookと同期して直近の予定を表示する機能で、以前のバージョンにはあったものの途中で消えた経緯がある。待っていた人には朗報だろう。 システム管理者に刺さる「Sysmon標準搭載」 見逃してほしくないのが Sysinternals Sysmon（System Monitor）の標準組み込みだ。これまではサードパーティツールとして別途導入が必要だったが、26H2からはOSに内蔵される。 Sysmonはプロセスの作成・ネットワーク接続・ファイル変更といったシステムイベントを詳細にログ出力するツールで、インシデントレスポンスやEDR連携の文脈で非常に重宝される。「まずSysmonを入れる」がセキュリティ担当者の常識だっただけに、標準化は実務負荷を下げる地味に大きな前進だ。 実務への影響——日本のIT現場が今から考えるべきこと 企業IT管理者へ 26H2は2026年秋のリリース後、コンシューマー向けに約24か月、エンタープライズ向けに約36か月のサポートが付く。サポートライフサイクルを意識したアップデート計画を今から立てておくと、来年の展開がスムーズになる。Copilot機能の多くはグループポリシーやIntuneで制御可能になるはずで、「とりあえず無効化してから検証」の流れを想定しておこう。 セキュリティ担当者へ Sysmonの標準搭載はSIEM連携やログ基盤の設計を見直す好機だ。標準搭載になることで「全端末にSysmonが入っている前提」でログ収集パイプラインを設計できる。ただし、設定ファイル（XML）のカスタマイズは依然必要になるため、SwiftOnSecurity等の既成テンプレートを参考にした設定策定を今のうちに進めておきたい。 一般ユーザー・開発者へ ダークモード統一やRunダイアログ刷新は「見た目だけ」ではなく、長時間作業での目への負担軽減に直結する。展開後に体験が変わる可能性があることを頭に入れておこう。 筆者の見解 26H2を見渡したとき、率直に言えば「やっと」と感じる部分と「そこが本丸か」と感じる部分が混在している。 Sysmonの標準搭載は本当に正しい判断だ。セキュリティの底上げをOSレイヤーで行う、この方向性は一貫して支持したい。ダークモードのプロパティ対応も、細かいが長年の宿題が片付いた実感がある。 一方、Ask Copilotには「今度こそ」という期待と、慎重な目線の両方を持っている。自然言語でOSを操作するアイデアは本来ワクワクするものだ。ただ、これが本当に「検索を超えた体験」になるかは、実際に触ってみるまで判断を保留したい。Microsoftにはその力があると思っているし、AI検索という文脈で世界標準になるポテンシャルもある。だからこそ、「それっぽい見た目」で終わらず、精度と信頼性で正面から勝負してほしい。 Windowsを細かく追い続けることの意味が問われる時代になった今、26H2のような「まとめてオン」形式のリリースは合理的な戦略だと思う。しかし、ユーザーが「使ってよかった」と感じるかどうかは機能の数ではなく、日常の摩擦をどれだけ取り除けるかにかかっている。今秋のリリースが、その答えを示してくれることを期待したい。 出典: この記事は Windows 11 26H2: All New Features Coming in Late 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「正規の認証画面」を踏み台にする攻撃が急増中 フィッシング対策の常識として「変なリンクは踏まない」「URLをよく確認する」と言われ続けてきた。しかしいま急増しているデバイスコードフィッシング（Device Code Phishing）は、その常識が通用しない。被害者が踏む先は本物のMicrosoftサインインページだからだ。 セキュリティリサーチ企業のPush Securityが発表したレポートによれば、このタイプの攻撃は今年に入ってから37.5倍に急増している。3月初頭の時点で15倍に達していたところ、わずか1ヶ月足らずでさらに跳ね上がった計算だ。 攻撃の仕組み——OAuth 2.0のデバイス認可フローとは まず攻撃の流れを整理しておこう。 OAuth 2.0には「デバイス認可グラント（Device Authorization Grant）」と呼ばれるフローがある。これはスマートテレビやプリンター、IoT機器のようにキーボード入力がしにくいデバイスが認証を行うために設計されたものだ。 デバイスが認証サーバーにリクエストを送り、「ユーザーコード」を受け取る ユーザーが別のデバイス（スマホやPCなど）でそのコードを入力する 認証が完了すると、元のデバイスにアクセストークンが発行される 攻撃者はこのフローを悪用する。 攻撃者がMicrosoftに対してデバイス認可リクエストを送り、ユーザーコードを取得する そのコードをメールやチャットで被害者に送りつけ、「認証のため入力してください」と指示する 被害者は本物の microsoft.com/devicelogin でコードを入力してサインインする 攻撃者の「デバイス」に有効なアクセストークンと更新トークンが渡される URLは正規のもの、認証もMFAを経由する場合がある——それでも乗っ取られる。これが従来型のフィッシング対策では防ぎきれない理由だ。 PhaaS化が加速——11種類ものフィッシングキットが確認 今回のレポートで特に深刻なのが、このテクニックの「商品化」だ。かつては国家系ハッカーや高度な攻撃者しか使いこなせなかったデバイスコードフィッシングが、今や初心者でも使えるPhaaS（Phishing as a Service）キットとして流通している。 最も主要なキットはEvilTokens。DocuSign・Office 365・SharePointなどのSaaS偽装ページを備え、アンチボット保護や回転するAPIエンドポイントまで実装している完成度だ。 Push Securityが追跡したキットはEvilTokensを含めて11種類に上る。特徴的なものをいくつか挙げると： VENOM — EvilTokensのクローンと見られる閉鎖型PhaaSキット SHAREFILE — Citrix ShareFile偽装で企業ユーザーを狙う DOCUPOLL — GitHub Pages上でDocuSign偽装フローを実行 PAPRIKA — AWS S3ホスト。Microsoft 365ブランドにOktaフッターを偽装 LINKID — Microsoft TeamsおよびAdobeを偽装したルアーを使用 すべてがSaaS系のブランドを使ったリアルな偽装、クラウドプラットフォームへのホスティング、アンチボット保護を備えている。もはや個人のハッカーがゼロから構築するものではなく、使いやすいSaaSとして提供されている実態がある。 実務への影響——日本のIT管理者が今すぐ確認すべきこと この攻撃が「うちには関係ない」とは言い切れない。Microsoft 365を使っている組織なら潜在的なターゲットだ。 条件付きアクセスで「デバイスコードフロー」を制限する Microsoft Entra ID（旧Azure AD）の条件付きアクセスポリシーで、デバイスコード認証フローをブロックまたは制限できる。IoTデバイスや業務上の必要性がない組織では、このフローを無効化することが最も直接的な対策だ。 FIDO2セキュリティキー・パスキーへの移行を加速する デバイスコードフィッシングはMFAをバイパスできる場合があるが、FIDO2ベースの認証はフィッシング耐性（Phishing-resistant）があり、このタイプの攻撃に対して有効だ。Entra IDの「認証強度」ポリシーでフィッシング耐性MFAを必須にすることを検討したい。 ユーザー教育のアップデート 「変なリンクを踏まない」だけでは不十分な時代になった。「誰かから渡されたコードを公式サイトに入力する」という行為自体にリスクがあることを、エンドユーザーに伝えておく必要がある。 継続的なトークン監視 攻撃が成功してしまった場合の早期検知のために、Entra IDのサインインログやMicrosoft Sentinelでの異常なトークン発行・利用の監視を設定しておくことも重要だ。 ...

4月14日（日本時間）に配信予定のWindows 11セキュリティアップデートには、派手さはないが毎日の操作感を着実に底上げする8つの機能改善が含まれている。大型機能アップデートではなく通常のセキュリティパッチと同時展開という形で、日常ユースに刺さる変更が届く。 注目の8機能を整理する タスクバーを上・横へ移動可能に 長年ユーザーから要望が出続けてきたタスクバーの位置変更が、ついにGUIから設定できるようになる。上部・左右への移動に対応し、Macライクなレイアウトや、縦長ディスプレイ利用者が恩恵を受けやすい横配置も選択できる。レジストリを直接編集していたユーザーには「やっと」という変更だろう。 1000Hz超リフレッシュレートのモニターサポート 高リフレッシュレートモニターは競技ゲーマーだけの話ではなくなりつつある。1000Hz以上の製品がコンシューマー市場に出始めたことを受け、OSレベルで正式サポートが入る。クリエイターやCADユーザーにもスムーズな描画体験として波及してくる分野だ。 Smart App Control——OS再インストール不要でリセット可能に これは実用上かなり重要な変更だ。Smart App Controlは未署名アプリや未知のアプリを事前にブロックするWindowsのセキュリティ機構だが、一度オフにすると「OS再インストールしないと有効化できない」という制約があった。今回の更新でこの制約が撤廃され、ポリシー設定から再有効化できるようになる。 Narrator × Copilot統合で画像の説明文を生成 スクリーンリーダー「Narrator」にCopilotを使った画像説明生成機能が統合される。視覚障害を持つユーザーへのアクセシビリティ向上という観点での意義は大きく、技術的なアプローチとしても興味深い。 そのほかの実用的な改善 ファイルエクスプローラーのパフォーマンス改善 設定アプリのナビゲーション改善 ウィジェットボードのカスタマイズ拡張 バッテリーセーバーの詳細設定追加 実務への影響——IT管理者・エンジニアへの実際的なヒント Smart App Controlの変更は企業環境で特に検討価値がある。 セキュリティポリシーを強化したい環境で「以前に無効化してしまったSACを戻したい」という場合、これまでは再インストールが唯一の手段だった。管理コストの観点でもこの変更はポジティブに評価できる。イントラネット展開環境では展開ポリシーと合わせて動作確認を優先的に行いたい。 タスクバー移動については、業務用PCの標準設定に影響する可能性がある。 エンドユーザーが自由に変更できるようになるため、ヘルプデスクへの「タスクバーが消えた」問い合わせが増えることも想定しておくと良い。グループポリシーで制限する選択肢も確認しておくことを推奨する。 4月14日配信予定とはいえ、いつものように数日様子を見る戦略も有効だ。 特にSmart App Controlの変更は既存のポリシー設定と干渉する可能性がゼロではない。先行ユーザーのフィードバックを確認してから展開判断するのは、今の時代において立派なリスク管理だ。 筆者の見解 率直に言って、このアップデートは「Windowsらしい地道な改善」の典型だ。タスクバーの位置変更がようやくGUIで完結するようになったことは、何年も待ち続けたユーザーにとって小さくない話だし、Smart App Controlの制約解除は明らかに正しい方向の変更だ。 特にSmart App Controlの改善は評価したい。セキュリティ機能を「設定ミスしたら再インストールしかない」という状況に置いておくのは、運用面での無用なハードルを作っていた。制限を設けることと、その制限が現場で機能しやすい設計にすることは両立するはずで、今回の変更はその方向に一歩踏み込んでいる。 NarratorへのCopilot統合については、アクセシビリティという文脈での活用は本来の使い方のひとつだと思う。AIを「使えるところに使う」というアプローチが適切に機能している例として素直に評価したい。 Windowsの細かい機能を追いかけることの優先度は以前より確実に下がっているが、それでも「基盤として安全で、使いやすいOS」であり続けることの意味は変わらない。今回のような実用的な積み重ねを、これからも地道に続けてほしいと思っている。 出典: この記事は 8 new Windows 11 features arriving in April that make everyday use a little easier の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「DoSだから少し待って」が命取りに 2025年10月に公開されたF5 BIG-IP APMの脆弱性（CVE-2025-53521）が、2026年3月に入り「リモートコード実行（RCE）が可能」と再分類された。当初はサービス拒否（DoS）扱いだったため、パッチ適用を後回しにした組織も少なくないだろう。しかし状況は一変している。認証なしのリモートコード実行——これはセキュリティ上の最高水準のリスクだ。 インターネット脅威監視団体のShadowserverによると、2026年4月時点でBIG-IP APMのフィンガープリントを持つIPが17,100件以上確認されており、そのうち1万4千台以上が依然としてCVE-2025-53521の攻撃にさらされた状態にある。米国土安全保障省のCISAが連邦機関に対し月曜日深夜までのパッチ適用を義務付けるほどの緊急事態にもかかわらず、だ。 BIG-IP APMとは何か、なぜ狙われるのか F5 BIG-IP APM（Access Policy Manager）は、組織のネットワーク・クラウド・アプリケーション・APIへのアクセスを一元管理するプロキシ製品だ。Fortune 50企業の48社を含む世界2万3千社以上が採用する、エンタープライズセキュリティの要衝といえる。 この製品の性質上、BIG-IP APMが侵害されれば組織全体のアクセス制御が崩壊する。過去にも国家支援型のAPTグループやサイバー犯罪集団が、BIG-IPの脆弱性を悪用して企業ネットワーク侵入・データ窃取・マルウェア展開を行ってきた。今回のRCE再分類を受けF5は、侵害の証拠（IOC）を公開するとともに「感染が確認された場合はシステムを一から再構築することを強く推奨する」と明言している。 特に注意が必要なのは、UCS（ユーザー設定バックアップ）ファイルだ。F5は「侵害後に作成されたUCSファイルにはマルウェアが混入している可能性がある」と警告しており、信頼できるソースからの設定再構築を求めている。侵害タイミングが不明な場合、バックアップ自体が汚染されているリスクがある。 日本企業へのリスク BIG-IP APMは日本の大手エンタープライズでも広く採用されている。金融・製造・通信など、アクセス管理基盤にF5製品を使っている組織は少なくない。今回の問題でとりわけ重要なのは以下3点だ。 1. 仮想サーバーにアクセスポリシーを設定しているか確認 今回の脆弱性は「仮想サーバーにアクセスポリシーが設定されている構成」で悪用可能とされる。自組織の構成がこれに該当するかを即座に確認すること。 2. ディスク・ログ・ターミナル履歴を精査 F5が公開したIOCを参照し、すでに侵害されていないかをチェックする。「今動いているから大丈夫」という判断は禁物だ。 3. パッチ未適用なら今すぐ適用 F5が修正済みバージョンを提供済み。オリジナルのCVEに対するパッチがRCEにも有効であることが確認されている。テスト後、速やかに適用する。 筆者の見解 セキュリティを生業にしているわけではないが、こうした「後になって深刻度が上がる脆弱性」の問題には構造的な課題を感じる。「DoSだからすぐには死なない」という心理は理解できる。しかし攻撃者はその猶予の間に足場を築く。今回のケースは、脆弱性の最初の開示情報だけで判断するリスクを端的に示している。 アクセス管理製品は「すべての扉の鍵束」を握っている。そこが侵害されれば、背後にある多層防御の多くが無意味になる。ゼロトラストアーキテクチャを整備していても、その認証・認可の入り口自体が突破されれば設計思想ごと崩れる。 日本の大エンタープライズでは、「ベンダーのサポート範囲外の古いバージョンが生き続けている」「本番への変更は四半期に一度の変更管理」という現場も珍しくない。残念ながらこの種のケースで「間に合わなかった」という話が後から出てくることは珍しくない。攻撃者はそのペースに合わせてくれない。 対応は複雑ではない。パッチを当て、IOCを確認し、疑わしければ再構築する。それだけだ。「今週末に」「来月の変更管理で」という判断が、どれだけのリスクを生んでいるかを、今一度チームで確認してほしい。 出典: この記事は Over 14,000 F5 BIG-IP APM instances still exposed to RCE attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが長らく物議を醸してきた「Windows Recall」の正式展開をついに開始した。2024年6月のCopilot+ PC発売時に華々しくデビューするはずだった機能が、セキュリティ・プライバシー上の問題から2度の延期を経て、ようやくWindows Insider向けにプレビュー提供が始まった。今回の展開では従来の反省を踏まえた設計変更が加えられているが、注目すべき点は技術的な改善だけではない。 Windows Recallとは何か Recallは、PCの画面を定期的にスクリーンショットとして保存し、AIを使って「あの時見ていたあのWebページ」や「先週編集していたあの資料」を自然言語で検索できるようにする機能だ。概念としては非常に魅力的で、「デジタル記憶の拡張」とも呼べるアプローチである。 処理はすべてデバイス上のNPU（Neural Processing Unit）で完結するため、クラウドにデータを送信しない点が特徴だ。ただし動作にはCopilot+ PCの認定を受けたハードウェアが必要で、最低16GBのRAM、256GBのストレージ、およびデバイス暗号化が有効であることが条件となる。現行の多くのビジネスPCでは動作しないことも念頭に置いておく必要がある。 2度の延期を経た改善点 最初の公開プレビュー当時、セキュリティ研究者たちが指摘したのは深刻な問題だった。パスワード、クレジットカード番号、社会保障番号といった機密情報が暗号化されていないテキストファイルとして保存されていたのだ。「AIが見てくれる便利な機能」のはずが、「攻撃者に全履歴を渡す機能」になりかねないと批判が殺到した。 今回の展開では、この反省が設計に反映されている： 完全オプトイン制：デフォルトは無効。自分で有効化しない限り、スクリーンショットは一切保存されない ローカル暗号化：スナップショットはデバイス上で暗号化。Microsoftもアクセス不可 Windows Hello認証：生体認証でのみアクセス可能。第三者が覗けない仕組み 一時停止機能：いつでもスナップショット保存を止められる また今回は「Click to Do」機能も同梱されており、スクリーンショット内の画像から背景削除や物体消去をPhotoアプリやPaintで直接実行できるなど、より実用的な連携が加わった。 対応言語と提供地域 現時点での対応言語は英語・中国語（簡体字）・フランス語・ドイツ語・日本語・スペイン語の6言語。日本語が含まれている点は、日本市場への正式展開を見据えた動きとして注目に値する。ただし欧州経済領域（EEA）向けの提供は今年後半に予定されており、GDPR対応の複雑さが影響していると見られる。 実務への影響——日本のエンジニア・IT管理者へ 導入前に確認すべき3点： ハードウェア要件の確認：現在の社内PCがCopilot+ PC認定を受けているか確認する。多くの既存機では動作しない MDM/Intune設定の見直し：Recallは管理者側でポリシー制御が可能。業務PCへの展開可否は組織のセキュリティポリシーと照らし合わせて判断すること 情報セキュリティルールとの整合性：画面を自動記録するという性質上、機密情報を扱う業務での利用可否を事前に整理する必要がある 特に、医療・金融・法務など機密度の高い業務環境では、たとえローカル暗号化であっても「スクリーンショットを自動保存する仕組みが動いている」という事実に対してコンプライアンス上の確認が必要になるケースがある。IT管理者は早期にポリシー検討を始めておくことを勧める。 個人・開発者向けには、日本語対応が確認できたらまずWindows Insiderプログラムで試してみる価値はある。AIによるPC操作履歴の検索は、実際に使ってみると「あれ、これはちゃんと便利かもしれない」と感じられる場面が出てくるはずだ。 筆者の見解 正直に言えば、このRecallには複雑な思いがある。 機能のコンセプト自体は面白い。「あの時見ていたあれを探したい」という体験は誰もが感じる課題であり、それをNPUとAIで解決しようという発想は正しい方向だ。デフォルト無効・ローカル暗号化・Windows Hello認証という今回の設計変更も、最初からこうなっていればよかったと思えるほど筋が通っている。 だが、ここまでの経緯が気になる。最初のプレビューで出た問題——パスワードや金融情報がそのまま平文で保存されていた——は、セキュリティの基本的な感覚があれば事前に防げたはずのものだった。「なぜ最初にそれをやらなかったのか」という問いに対して、明確な答えがないまま時間が過ぎてしまった。 Microsoftには、Windowsというプラットフォームと数億台のエンドポイントという圧倒的な強みがある。その規模でAI機能を展開できる企業は他にない。だからこそ、「3度目の正直」という言葉で片付けてほしくない出来事でもある。もったいないという気持ちが正直なところだ。 今後、Recallが日本市場で正式展開されたとき、ユーザーが「安心して使える」と感じられる実績をきちんと積み上げていくことが、信頼回復への唯一の道だろう。技術的な土台は今回で整いつつある。あとはその土台の上で、地道に実績を示してもらうことを期待したい。 出典: この記事は Third time lucky? Microsoft finally begins roll-out of controversial Recall feature の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが2026年4月第1週にリリースしたWindows 11向けオプションプレビュー更新プログラム「KB5079391」を、インストールエラーが相次いだとして配信を一時停止した。同社は原因の詳細や修正版のリリース時期を明示していないが、4月14日のPatch Tuesdayまでには正式版が提供される見込みとされている。 KB5079391とは何だったか KB5079391はWindows 11バージョン24H2および25H2を対象とした任意適用のプレビュー更新で、計29件の変更を含んでいた。主な内容は以下のとおり。 Smart App Controlの改善 ディスプレイパフォーマンスの向上 Windows Helloの指紋認証信頼性の強化 ARM64デバイス上でx64アプリを実行する際のWindows Recovery Environment安定化 生体認証サインインの信頼性向上 機能面では有益な変更が多く含まれていただけに、配信停止は残念な結果となった。 エラー0x80073712が意味すること 報告されたエラーコード「0x80073712」は「更新ファイルが見つからないか破損している」ことを示すもので、更新コンポーネントのキャッシュや配信ファイル自体に問題があった可能性が高い。MicrosoftはWindowsUpdate経由での提供を一時的に制限し、追加の影響が出るのを防ぐ対応を取っている。 繰り返す品質問題——2026年の記録 今回の件は決して孤立した事例ではない。ここ数ヶ月で見ても： 2026年1月: Patch Tuesday後にリモートデスクトップ接続障害、再起動ループ、Outlookクラッシュが発生。WindowsクライアントからServer 2019〜2025まで6件の帯外更新で対処 2026年3月: Patch Tuesday後、Teams・Edge・Microsoft 365でサインインが失敗する障害が発生。端末がオフラインと誤判定するバグが原因で緊急修正 2026年3月〜4月: Bluetooth接続問題やエンタープライズ向けセキュリティ脆弱性にも緊急対応 Windows担当チーフのPavan Davuluri氏は「高い基準を求め続けてくれてありがとう。Windowsはみなさんのものでもある。基盤を強化し、本当に重要なイノベーションを届けることにコミットする」とユーザーに約束しているが、その約束が試される状況が続いている。 実務への影響——今すぐできる対応 エンタープライズIT管理者向け Intune・WSUS・Windows Update for Business等の管理ツールで、KB5079391の配信状況を確認し、展開ポリシーが停止済み更新を誤って適用しようとしていないか確認する 既に展開キューに入っている場合は手動でブロックリストに追加することを検討 4月14日Patch Tuesday後、正式な累積更新として再リリースされる見込みのため、タイミングを待つのが現実的な対応 個人・SMB環境向け Windows Updateの「任意（オプション）」更新は、Patch Tuesdayの必須更新に統合されるまで待つのが原則として安全 今回のような障害情報はMicrosoftのKnown Issues一覧で確認できる。更新前に必ず参照したい エラー0x80073712が出た場合は、DISM /Online /Cleanup-Image /RestoreHealth コマンドで更新コンポーネントの修復を試みる価値がある 筆者の見解 Smart App Controlの改善やWindows Hello強化など、今回のKB5079391に含まれていた変更は方向性として正しいものが揃っていた。セキュリティ基盤の堅牢化はMicrosoftが継続して取り組むべき最重要課題であり、その姿勢自体は支持したい。だからこそ、品質管理で躓くのがもったいない。 更新の品質問題はもはや「たまにある話」ではなく、毎月の定例行事のようになってきているのが率直なところだ。1月、3月、4月と連続して緊急対応が発生している現状は、テストプロセスか配信インフラのどこかに構造的な課題があることを示唆している。 現場のエンジニアとしては「更新を即日当てず数日様子を見る」という選択が、もはや単なる慎重さではなく合理的なリスク管理になっている。これが当たり前になってしまっている現状は、Microsoftが本来目指している「信頼性の高いプラットフォーム」とは逆方向に進んでいる。 4月14日のPatch Tuesdayでこの問題が安定した形で解消され、今後の更新品質向上への足がかりになることを期待したい。Pavan Davuluri氏の「基盤を強化する」という約束を、ぜひ行動で示してほしい。Microsoftには、それができる技術力と組織力が間違いなくある。 出典: この記事は Microsoft pulls Windows update after installation failures の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

LinkedInを開いた瞬間、あなたのブラウザは静かにスキャンされている。インストールされている拡張機能、CPU数、メモリ量、画面解像度、タイムゾーン、バッテリー残量……。これはSFではなく、BleepingComputerが独自検証で確認した現在進行形の話だ。 何が起きているか 「BrowserGate」と名付けられたこの問題は、商業的LinkedInユーザーの団体「Fairlinked e.V.」が告発したもの。LinkedInはランダムなファイル名のJavaScriptをユーザーセッションに注入し、6,236個のブラウザ拡張機能の有無を検出しているという。 手法はシンプルかつ確立されたものだ。各拡張機能には固有のIDがあり、そのIDに紐づく静的リソース（画像やJSファイル）へのアクセスを試みることで、インストールされているかどうかを判定できる。Chrome DevToolsを開けば確認できるレベルの話なので、完全な「隠蔽」ではないが、一般ユーザーが気づくことはほぼない。 何のために使っているか 特に問題視されているのが競合製品の把握だ。LinkedInは自社の営業ツール（Sales Navigator等）と直接競合するApollo、Lusha、ZoomInfoを含む200以上の製品を監視対象に含めている。LinkedInはユーザーの氏名・企業・役職を把握しているため、「どの会社がどの競合ツールを使っているか」を高精度にマッピングできる。これは事実上、競合SaaSのカスタマーリストをユーザーのブラウザから無断で抜き取っているに等しい。 さらに収集されるデバイス情報（CPUコア数、メモリ容量、画面解像度、タイムゾーン、言語設定、バッテリー状態、オーディオ情報、ストレージ）は、組み合わせることでブラウザフィンガープリントを形成できる。これはCookieを削除しても追跡可能な識別手法だ。 BleepingComputerは競合ツール使用データの活用や第三者提供については独自検証できていない。ただ、Fairlinkedはこのデータが「利用規約違反ユーザーへの警告・制限に既に使われている」と主張している。 LinkedInの反論 LinkedInは拡張機能の検出自体は認めつつ、「メンバーのプライバシー保護とサイトの安定性のため」だと説明している。また告発者がコンテンツスクレイピング等によりアカウント制限を受けているとも述べており、報告書の信頼性を疑わせる姿勢を見せている。 とはいえ、拡張機能検出の対象には税務専門家向けツールや文法校正ツールも含まれており、「競合スクレイパーの検出」だけでは説明がつかない範囲の監視が行われていることは事実だ。 実務への影響 エンジニア・セキュリティ担当者へ 業務用PCでLinkedInを開く際のリスクを再認識する。インストールされている拡張機能から、社内で使用しているSaaSツールの種類が推測される可能性がある ブラウザプロファイルの分離を検討する。LinkedInなどSNS系は専用プロファイルで開き、業務用拡張機能との混在を避ける 社内ポリシーの見直し。「業務PCのブラウザ管理」にLinkedIn経由の情報漏洩リスクを追加すべきタイミングかもしれない フィンガープリンティング対策として、Privacy BadgerやuBlock Originといった拡張機能が有効だが、皮肉なことにそれらもLinkedInのスキャン対象に含まれている IT管理者へ 業務端末のブラウザ拡張機能管理は以前から重要だったが、この件はその理由に新たな側面を加えた。従来は「悪意ある拡張機能によるデータ漏洩」が主な懸念だったが、今後は「訪問先Webサービスによる拡張機能スキャン」も管理対象に含める必要がある。 筆者の見解 率直に言う。Microsoftへの失望が、またひとつ積み重なった。 LinkedInはMicrosoftが2016年に262億ドルで買収したサービスだ。そのLinkedInが、競合他社のユーザーリストをサイレントスキャンで構築し、違反者の摘発に使っているとしたら——これは「プライバシー保護のため」という説明とは到底相容れない。 セキュリティの文脈で言えば、このフィンガープリンティング手法は昔からあるし、技術的に「違法」とは言い切れない。LinkedInのTOS（利用規約）には収集に関する条項があるし、企業がユーザーのブラウザ環境を把握しようとするのは珍しいことでもない。 だがLinkedInはリアルアイデンティティと紐づいている点が決定的に異なる。Twitterやnoteでフィンガープリンティングされるのと、本名・所属会社・職種が紐づいた状態でフィンガープリンティングされるのでは、リスクの次元が違う。競合ツール使用状況のマッピングに至っては、もはや個人プライバシーを超えた企業競争上の情報収集と見るべきだ。 Copilotで散々やらかし、Recallで炎上し、そしてLinkedInでBrowserGate。Microsoftは「信頼されるテクノロジー企業」という看板をゆっくりと、しかし確実に外してきている。 対策としては、業務でLinkedInを使うならブラウザプロファイルを分離するのが現実的な一手。MicrosoftがEdgeとLinkedInを「統合」させていく方向に進むとすれば、その統合がどんな情報収集を内包するか——今後も目を離せない。 出典: この記事は LinkedIn secretely scans for 6,000+ Chrome extensions, collects data の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11の強制アップデートに踏み切った。Windows 11 24H2以前のバージョンを使っているPCは、ユーザーの意思にかかわらず最新リリースへと自動移行させられる流れが始まっている。「また強制か」という声も上がりそうだが、背景と実務的な意味を整理しておこう。 何が起きているのか MicrosoftはWindows Updateを通じて、サポートライフサイクルの終わりが近いバージョンのユーザーを自動的に最新のWindows 11へ移行させる「強制アップグレード」を順次展開している。今回対象となるのはWindows 11の旧バージョンを継続利用しているPC群だ。 この施策自体は突然のことではなく、Microsoftが長年繰り返してきた「サポート終了前の強制移行」ポリシーの延長線上にある。Windows 10に対してもかつて同様の手法が使われた。仕組みとしてはWindows Update経由での自動適用であり、ユーザーが意図的にアップデートを延期していても、一定の猶予期間を過ぎると強制的に処理が走る。 対象と影響範囲 強制アップデートの対象は、現時点でWindows 11の旧バージョン（24H2より前のビルド）を使っているコンシューマー向けデバイスが中心とみられる。企業環境では、Intune・WSUS・Windows Update for Business などの管理ツールを使えばアップデートのタイミングをコントロールできる。完全にシャットアウトはできないが、猶予期間を稼ぐことは可能だ。 重要なのは「強制」とはいっても即日適用されるわけではなく、段階的なロールアウトが前提であるという点。Microsoftは通常、パッチの品質問題が報告された場合にロールアウトを一時停止するセーフガードを持っている（実際には機能しなかったケースもあるが）。 実務への影響——エンジニア・IT管理者はどう動くべきか コンシューマー環境（個人PC） に関しては、率直に言って受け入れるのが現実的だ。最新バージョンへの移行を遅らせるための手間と、セキュリティパッチを最新に保つメリットを比較すれば、後者のほうが圧倒的に合理的である。 企業・組織環境 では以下の点を確認しておきたい： Intuneの機能更新ポリシー（Feature Update Policy）を設定しているか確認する。 設定していない管理対象デバイスは強制アップデートの対象になりうる Windows Update for Business のターゲットバージョン設定を再確認する。 古い設定のまま放置しているケースが意外と多い アプリ互換性テストのサイクルを見直す。 強制アップグレードが走る前に、主要業務アプリが最新Windows 11で動くか確認しておくこと エンドユーザーへの事前周知。 「突然再起動が走った」「デスクトップが変わった」という問い合わせを減らすための先手を打つ WSUSを使っているオンプレ環境は別途設定確認が必要だが、いずれにせよ「Microsoftの管理下にある以上、最終的には移行は避けられない」という前提でロードマップを組むのが正解だ。 筆者の見解 正直なところ、Windowsを細かく追いかける意味がどんどん薄れている。強制アップデートへの反発はわかるが、そもそも「古いバージョンをいつまでも使い続けたい」という発想自体が時代に逆行している。 セキュリティの観点からは、むしろ強制してでも最新に保たせるMicrosoftの姿勢は正しい。問題は「すぐ当てたら壊れた」という報告が増えていて、アップデートの品質が安定しないこと。Microsoftはここに本気でコミットしてほしい。強制するならそれ相応の品質保証をセットで出すべきだ。 企業のIT担当者へ一言言わせてもらうと、「Windowsのアップデート管理をちゃんとやってない」会社がまだ多すぎる。IntuneもWSUSも設定しっぱなし・放置はいい加減やめろ。強制アップグレードで現場が混乱するのは、ツールを正しく使ってこなかった結果でもある。 Microsoftへの失望は正直尽きないが、Windowsのプラットフォームとしての強さは依然として現実だ。文句を言いながらも、きちんと管理しながら付き合っていくしかない。それが今の正しい判断だと思う。 出典: この記事は Microsoft begins force-updating users to the latest Windows 11 version の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「Windows 11が重くて動かないからLinuxに逃げる」——そのつもりで調べたら、乗り換え先のLinuxディストロの方が要件が高かった。そんな皮肉な事態が現実になりつつある。 何が起きたか ある人気Linuxディストロが最低システム要件を大幅に引き上げ、Microsoft が定めるWindows 11の最低要件（RAM 4GB・ストレージ 64GB・TPM 2.0など）を上回る水準に達した。「Linuxは古いマシンでも動く軽量OS」という長年のイメージが、少なくともメインストリームのデスクトップ向けディストロに限っては過去のものになりつつある。 なぜ要件が上がっているのか Linuxディストロの要件引き上げには、いくつかの技術的背景がある。 モダンUIフレームワークの重量化：GNOMEやKDEといったデスクトップ環境は、ここ数年でWaylandへの完全移行を進めつつあり、GPU支援・アニメーション・高DPI対応などが標準になった。これらはメモリとGPU性能を以前より要求する。 セキュリティ機能の強化：セキュアブート対応・カーネル整合性チェック・メモリ保護機能などが有効化されると、それなりのハードウェアが必要になる。 64ビット専用化：32ビットアーキテクチャのサポートが切られ、古い低スペックマシンがそもそも対象外になっている。 「Windowsが重いからLinux」という逃げ道はもう機能しない 日本のIT現場でも、「古いPCにLinuxを入れて延命する」という運用は一定数存在する。特に学校・中小企業・非営利団体では、予算制約からWindows 11非対応のPCを生かし続けようとするケースがある。しかし今回のような要件引き上げが続くと、その選択肢は急速に狭まる。 現実的な代替としては次の選択肢が残る： 軽量ディストロへの移行（Linux Mint XFCE、Lubuntu、MX Linuxなど）：デスクトップ向けフラグシップ版でなければ、まだ低スペック対応のものは存在する Chrome OS Flex：Googleが提供する古いPC向けOS。管理ツールも整備されており企業向けにも現実的 仮想デスクトップ（VDI/クラウドPC）への移行：クライアント側スペックを問わない設計にシフトする ただし、どの選択肢も「古いPCを無償で延命できる万能解」ではなく、それぞれにコストと管理負担が伴う点を理解しておく必要がある。 実務での活用ポイント PC延命計画を立てている場合は要件を再確認：「Linuxなら動く」前提で計画している組織は、対象ディストロの最新最低要件を必ず確認せよ IT資産管理でスペック情報を最新化：RAM・CPU・GPU情報がないと今後の移行判断が困難になる 軽量ディストロのLTSバージョンを選ぶことで、要件変化の頻度を下げられる Windows 365やAVD（Azure Virtual Desktop）の費用対効果を再試算：クライアント延命コストと比較して意外に合理的なケースが増えている 筆者の見解 Linuxが「弱者の避難所」であり続けられた時代は終わったと思っている。それ自体は悪いことではない。Linuxがデスクトップとして本気でWindows・macOSと勝負しようとした結果として、要件が上がるのは自然な進化だ。 ただ、「古いPC延命のためにLinux」という幻想を今も信じているIT担当者には、現実を直視してほしい。軽量ディストロを適切に運用するのは、素のWindowsより管理コストが高いことも多い。タダより高いものはない。 一方でWindowsについていえば、TPM 2.0要件や最低スペック制限でWindows 11に移行できないPCをMicrosoftが大量に生み出したのは事実で、そのツケをLinuxコミュニティに押し付けてきた構図もある。今回の話は、その「受け皿」も消えつつあるというシグナルでもある。 結局のところ、ハードウェアを更新するか、クラウドに逃げるか、使うのをやめるか——この3択が本当の選択肢だ。「OS乗り換えで延命」という第4の選択肢には、もはやあまり期待しない方がいい。 出典: この記事は A popular Linux distro now has higher system hardware requirements than Windows 11 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米AIスタートアップPerplexityが、エージェント型AI機能「Perplexity Computer」を大幅強化した。Pro会員向けに提供されるこの機能、なんと米国連邦税申告書の自動作成と、税理士が作成した申告書のエラー検出まで対応するようになった。「税務はプロに任せるもの」という常識が、静かに崩れ始めている。 Perplexity Computerとは何か Perplexity Computerは、単なるQ&A型AIではなく、ユーザーの代わりに実際の「作業」を自律的にこなすエージェント型AIだ。ブラウザを操作したり、フォームを記入したり、複数ステップにわたるタスクを連続して実行できる。今回の税務対応では以下のことが可能になった： IRS申告書の下書き作成: 米国の連邦税申告書（Form 1040等）を自動でドラフト プロの申告書監査: 税理士・会計士が作成した申告書を読み込み、数千ドル（数十万円）規模のエラーや見落としを検出 節税機会の発見: 見逃しやすい控除や税優遇の適用漏れを指摘 Pro（月額20ドル）プランの機能として提供されており、アクセスしやすい価格設定も注目点だ。 なぜこれが重要か 税務申告は「専門家の領域」の代表格だった。法律知識、数値の正確性、最新の税制改正への対応——この3つが求められるため、一般人が自力でこなすには敷居が高く、税理士や会計士への依頼が常識だった。 だが今回のPerplexityの発表が示すのは、エージェント型AIが「知識×実行×検証」を自律ループで回せるようになったという事実だ。単に「答える」だけでなく、書類を読み込み、計算し、エラーを見つけ、修正案を提案する——これはまさに「仕事を代行する」AIだ。 税務という高度に規制された複雑な領域でこれが動くなら、他の専門職領域（法務書類、医療診断補助、財務分析）への展開も時間の問題だろう。 日本への示唆——直接適用は無理でも、流れは読め 現時点でこの機能は米国の税制（IRS）に特化しており、日本の確定申告や法人税申告には直接対応していない。しかし「対岸の火事」と思ったら大間違いだ。 日本のe-Tax・マイナポータル連携での確定申告自動化はすでに進んでいるが、「入力補助」レベルに留まっている。今後、日本語対応の税務エージェントが登場したとき、何が起きるかは明白だ。 IT管理者・エンジニア向けの実務ポイント： エージェント型AIの評価を今すぐ始めよ: Perplexity Computer、Microsoft Copilot、Google Geminiのエージェント機能を実際に触ってみる。来年の話ではない 社内の「専門家頼み」プロセスをリストアップせよ: 税務・法務・購買・採用——これらはすべてエージェントAI化の候補だ 「AIが下書き、人間がレビュー」モデルに移行せよ: 税理士への依頼方法そのものを再設計する時期に来ている 筆者の見解 正直に言う。これは来るものが来た、という感じだ。 私がいま一番気になっているのは「ハーネスループ」——エージェントが自律的にタスクを判断・実行・検証を繰り返すアーキテクチャだ。Perplexity Computerが税務申告でやっていることは、まさにそれだ。フォームを読む→計算する→エラーをチェックする→修正案を出す。このループが税務で動くなら、設計次第でどんな業務にも展開できる。 日本のIT業界はこの変化に気づいていない企業が多すぎる。「専門家の仕事はAIに奪われない」という幻想、そろそろ本気で捨てる時期に来ている。仕組みを作れる人間が少数いれば、あとはAIが回す——これが現実になりつつある。 「禁止ではなく安全に使える仕組みを」が私の基本スタンスだ。AIが下書きを作り、人間が最終確認する——そのモデルの方が、人間だけでやるより精度が高く、コストも低い。抵抗するより、乗りこなせ。 ただし一点だけ強調したい。税務申告書には所得・資産・家族情報など極めてセンシティブなデータが含まれる。Perplexityがそのデータをどう扱うか、プライバシーポリシーを必ず確認してほしい。「便利だから使う」の前に、「何を渡しているか」を把握するのは最低限のリテラシーだ。ゼロトラストの観点からも、外部AIサービスへのデータ送信ポリシーを社内で整備しておくことを強く勧める。 出典: この記事は Perplexity Computer can now draft IRS returns and audit tax professionals の内容をもとに、筆者の見解を加えて独自に執筆したものです。

悪意あるエクスポートファイル一つでシステムを掌握される ビジネスコミュニケーションツール「Stackfield」のデスクトップアプリ（macOS・Windows両対応）に、CVSSスコア9.6という極めて深刻なパストラバーサル脆弱性（CVE-2026-28373）が発見された。2026年4月3日に公開されたこの脆弱性は、バージョン1.10.2未満のアプリを使っているユーザー全員が対象となる。 Stackfieldは欧州を中心に利用されているセキュアビジネスチャットツールで、エンドツーエンド暗号化を売りにしている。それだけに、暗号化絡みの処理に深刻な穴が開いていたというのは皮肉としか言いようがない。 脆弱性の技術的詳細 パストラバーサルとは何か パストラバーサル（Path Traversal）とは、ファイルパスの検証が不十分な場合に ../../ などのシーケンスを使って意図されたディレクトリの外にアクセスする攻撃手法だ。今回の脆弱性はStackfieldのエクスポートファイルを処理する復号機能の中に存在する。 具体的には、エクスポートファイル内の filePath プロパティに対してサニタイズ・バリデーションが行われていない。攻撃者はここに細工されたパスを埋め込んだ悪意あるエクスポートファイルを作成することで、被害者のシステム上の任意の場所に任意の内容を書き込める。 攻撃に必要な条件 認証不要（PR:N）: 攻撃者はアプリ内で認証を必要としない ユーザーインタラクション必要（UI:R）: 被害者が悪意あるエクスポートファイルを開く必要あり 対象プラットフォーム: macOS・Windows両方 対象バージョン: 1.10.2未満のすべて CVSSが9.6という数字が示すとおり、「ファイルを開くだけでシステムを乗っ取られる」可能性があるクリティカルな問題だ。公開時点でPoC（実証コード）は確認されていないが、エクスポートファイルのフォーマットを解析すれば攻撃者が再現できるレベルの情報はすでに公開されている。 実務への影響とアクション IT管理者がまず確認すること 使用バージョンの確認: 組織内でStackfield Desktop App を使っているユーザーのバージョンを棚卸しする 即時アップデート: v1.10.2以降へのアップグレードを最優先で実施 エクスポートファイルの扱い: 社外から受け取ったStackfieldエクスポートファイルを不用意に開かないよう周知 エンジニア向け注意点 パストラバーサルはOWASP Top 10にも長年ランクインしている古典的な脆弱性だ。今回の教訓は「暗号化・復号処理においても入力値のバリデーションは必須」という当たり前のことを再確認させてくれる。自社アプリでファイルパスを扱っている箇所は、改めて見直す機会にしてほしい。 筆者の見解 セキュリティ関連の話は正直得意じゃない。細かいことを気にしすぎる人たちが集まる分野だし、個人的にはあまり好きではない。でも技術的な興味はある。 で、今回の件で言いたいのはこういうことだ。CVSSスコア9.6はガチのやばい数字。これを「いや、PoC出てないし様子見」で放置するのは、IT管理者として失格だと思う。アップデートは今すぐやれ。 もう一点、今回の脆弱性がエクスポートファイル経由なのがポイントだ。「信頼できるアプリの機能を通じた攻撃」というのがゼロトラストの観点では特に厄介で、「外から来たファイルだから怪しい」という直感がない人を簡単にだます。エンドポイントのファイル操作をモニタリングする仕組みがない組織は本当に危険だ。 VPNで「境界の中は安全」と信じ込んでいるような旧来のセキュリティモデルでは、こういった攻撃に全く歯が立たない。ファイルを開く、ファイルを書き込む——そのレベルの挙動まで監視できるゼロトラスト構成への移行をいい加減本気で考えてほしい。「今動いているから大丈夫」は通用しない、という話は何度でも言い続ける。 出典: この記事は Critical Path Traversal in Stackfield Desktop App (CVE-2026-28373) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが2026年4月1日、Windows 11デバイス向けの「ホットパッチ（Hotpatch）」更新をデフォルト有効化すると正式発表した。Intune管理環境では同日よりテナントレベルのオプトアウト設定が可能になっており、IT管理者は5月11日までに自組織の方針を確定させる必要がある。 ホットパッチとは何か ホットパッチとは、OSを再起動させることなくセキュリティパッチを適用できる技術だ。従来のWindowsアップデートは「ダウンロード→インストール→再起動」という流れが基本で、特に業務時間中の再起動は生産性への影響が大きかった。 ホットパッチはカーネルやシステムコンポーネントのコードをメモリ上でライブパッチする仕組みで、AzureのWindows Server仮想マシンでは以前から提供されていた技術をクライアントOSに展開したものだ。年4回の「ベースライン更新（要再起動）」と、その間を埋める「ホットパッチ月（再起動なし）」が交互に来るサイクルで運用される。 Intune管理者が把握すべき設定変更 2026年4月1日以降、IntuneのWindows Update設定画面に「ホットパッチの許可/ブロック」トグルが追加されている。デフォルトは有効（Allow）のため、特に何もしなければテナント配下の対応デバイスに順次ホットパッチが適用されていく。 5月11日がデッドラインである点に注意が必要だ。この日以降はMicrosoftがデフォルト設定を強制適用する可能性があるため、ブロックしたい場合は事前にポリシーを設定しておくこと。 対応要件は以下の通り： Windows 11 Enterprise（バージョン24H2以降） Intune管理下のデバイス MicrosoftまたはWindows 365のライセンス（Business/Enterprise Premium等） なぜこれが重要か パッチ適用の最大の障壁のひとつが「再起動のタイミング問題」だった。「今業務中だから後で」「今週は重要な案件があるから来週」という先送りが積み重なり、既知の脆弱性を放置したまま何週間も経過するケースは珍しくない。 ホットパッチはこの摩擦をほぼゼロにする。特にゼロデイ脆弱性のような緊急パッチを業務への影響なく当日中に展開できるのは、セキュリティ運用の観点から見て大きな前進だ。 また、VDI（仮想デスクトップ）環境やシフト勤務が常態化している製造・物流・医療現場では「全デバイスの再起動ウィンドウをどう確保するか」という調整コストが馬鹿にならなかった。この課題を構造的に解消できる。 実務での活用ポイント まずIntuneのレポートを確認する：「レポート → Windows Update → ホットパッチレポート」でどのデバイスが対応済みか、パッチ適用状況を可視化できる。導入前にベースラインを取っておくと後の比較が楽になる。 ベースライン更新月（再起動あり）を把握する：ホットパッチ月でも年4回は再起動が必要なベースライン更新が来る。メンテナンスウィンドウの設定は引き続き必要であり「再起動が完全になくなる」と勘違いしないよう社内への説明が重要だ。 段階的ロールアウトを使え：Inuneの更新リングを使ってパイロットグループから展開するのが鉄則。全社一斉適用は何かあったとき影響範囲が広すぎる。 ブロックが必要なケース：高度にカスタマイズされたカーネルドライバーや特殊な業務アプリケーションが存在する環境では、ライブパッチとの相性問題が起きる可能性がある。検証環境で先行確認してからのロールアウトを強く推奨する。 筆者の見解 セキュリティは正直あまり好きなジャンルではないが（細かい人が多すぎる）、この機能は技術的に純粋に正しい方向だと思う。 Windowsアップデートを巡って最近「すぐ当てたら壊れた」報告が増えていて、「数日様子を見る」という判断も立派なセキュリティリスク管理だという話をしてきた。ホットパッチはその葛藤に対して一つの答えを出している——「ベースライン更新は慎重に、でもその間のセキュリティパッチは再起動なしで速攻で当てろ」という棲み分けだ。これは合理的だ。 ただし正直に言う。Microsoftの最近のデフォルト有効化ラッシュには少し辟易している。「オプトアウトは5月11日まで」という期限設定はIT管理者への圧力に他ならず、大規模テナントほど検証時間が取れない。もう少し余裕を持たせてほしかった。 とはいえ、ホットパッチ自体の技術的価値は本物だ。Azure VMではすでに実績があり、概念自体は枯れている。Linuxのkpatchやkspliceと同等の仕組みをWindowsクライアントに持ち込んだという意味で、エンタープライズWindowsの成熟を感じる。 日本のIT現場ではまだパッチ管理をSCCMやWSUSで手動運用しているところが多い。この機能を使いこなすにはIntuneへの移行が前提になるが、その移行自体が「面倒だから後回し」になっている組織が多すぎる。ホットパッチを導入できる環境を整えること自体が、実は最大の課題かもしれない。 Microsoftへの期待が下がっている今でも、こういう地に足のついた改善は素直に評価したい。Copilotよりこっちを先にやれよとは思うけど。 出典: この記事は Securing devices faster with hotpatch updates on by default - Windows IT Pro Blog の内容をもとに、筆者の見解を加えて独自に執筆したものです。