Windows

Microsoftは、デスクトップおよびモバイル向けMicrosoft Edgeの安定版（Stable Channel）アップデートサイクルを、現行の4週間から2週間へ短縮すると発表した。これにより、セキュリティ修正や新機能がエンドユーザーに届くまでの時間が半分になる。 何が変わるのか Edge安定版はこれまでChromeと同じ4週間サイクルで更新されてきた。今回の変更により、2週間ごとに新しいメジャーバージョンが降ってくることになる。デスクトップ（Windows / macOS / Linux）とモバイル（iOS / Android）の両方が対象だ。 企業向けに提供されているExtended Stable Channel（現在は8週間サイクル）についても、4週間サイクルへの変更が見込まれている。この点は特に企業IT管理者が注目すべきポイントだ。 更新サイクル短縮のメリット セキュリティパッチの到達が早くなる: ゼロデイ脆弱性が発見されてから修正版が届くまでの最大待機時間が半減する 新機能・改善の反映が早い: Canary → Beta → Stable のパイプラインが短縮され、開発速度が体感しやすくなる Chromiumベースエンジンの最新化: Blink / V8 エンジンのアップデートも早期に取り込まれ、Webの互換性問題が長期化しにくくなる 企業IT管理者への影響 消費者向けには純粋なメリットだが、企業環境では注意が必要だ。 現在4週間のテスト・検証サイクルを組んでいる組織は、スケジュールを見直す必要がある。特に以下のシナリオに影響が出やすい： 社内Webアプリケーションやイントラネットの動作検証 グループポリシー（ADMX）や設定カタログを使ったEdge管理 MAM/MDMで管理しているモバイルデバイスの更新ポリシー MicrosoftはIntune・Microsoft Endpoint Managerを通じたアップデート制御手段を提供しており、Extended Stable Channelへの移行や更新の一時延期（Update Policy）を活用することで、急な変更に対応できる。MicrosoftのEdge管理ドキュメントを今一度確認しておくことを強く勧める。 実務での活用ポイント Microsoft Intune の「ブラウザー更新」ポリシーを見直す: Update Channel と Update Policy の組み合わせで更新を段階的にロールアウトできる Extended Stable Channelの採用を検討する: 変更後も4週間サイクルが維持される見込みのため、検証コストが高い環境ではExtended Stableが現実解になる Canary/Beta環境を社内に1台確保する: 2週間先の変更を先行確認し、問題を早期に発見するバッファを持つ Webアプリの自動テストを整備する: 更新頻度が上がるほど、手動確認コストは指数的に増える。CI/CDによるブラウザー互換性テストの自動化が現実的な防衛策だ 筆者の見解 セキュリティパッチを早く届けるという方向性は、間違いなく正しい。脆弱性が公開されてから4週間もパッチ待ちというのは、ゼロトラストの観点でも、エンドユーザー保護の観点でもギリギリだった。2週間への短縮は歓迎したい動きだ。 ただ、Windowsアップデートでも毎月「当てたら壊れた」報告が後を絶たないように、頻度が上がるほど現場の運用コストは増す。特にリソースが限られた中小企業のIT担当者にとって、「とにかく速くなった」は手放しで喜べない話でもある。 MicrosoftにはEdgeの管理ツールをさらに使いやすくする努力を続けてほしい。更新サイクルを短縮するなら、それに見合った管理・検証の仕組みをセットで提供するのが筋だ。ブラウザーは今やOSと並ぶインフラ。変化の速度に管理の仕組みが追いついていてこそ、現場も安心して更新を受け入れられる。 2週間サイクルへの移行タイミングについては、Microsoftから正式なアナウンスが出次第、詳細を確認してほしい。 出典: この記事は Microsoft about to radically change how often your Edge browser updates の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

フランス政府のデジタル行政局（DINUM）は2026年6月、政府職員向け暗号化メッセージングプラットフォーム「Tchap」が侵害を受け、825,000人以上の登録ユーザーのうち約9%にあたる73,467人のアカウント情報が流出したと発表した。 Tchapとは——フランス政府の「公式Slack代替」 Tchapは、DINUMとフランスのサイバーセキュリティ機関ANSSI（国家情報システムセキュリティ局）が2018年に共同開発した、公務員向けの分散型インスタントメッセージングプラットフォームだ。Matrixプロトコルをベースに構築されており、2025年8月には全公務員の業務コミュニケーション標準ツールに指定された。Google PlayストアではすでにDL数が50万を超えており、月間アクティブユーザーは30万人を超えていた。 国産のセキュアメッセンジャーを政府主導で構築・運用するというアプローチは、デジタル主権の観点から注目されていただけに、今回の侵害は大きなダメージだ。 何が盗まれたか 攻撃者はソーシャルエンジニアリングによって侵害済みユーザーアカウントを入手し、そこを足がかりにプラットフォームへアクセスしたと主張している。DINUMによると、盗まれたとされるデータには以下が含まれる： 約650,000件のメッセージ 73,000件超のアカウント情報（氏名・メールアドレス・所属組織・アバター画像） ミーティングリンクおよびデバイスメタデータ PowerShellスクリプトにハードコードされたLDAP認証情報 13.5GB超のドキュメントおよびメディアファイル 致命的だった設計上の盲点 DINUMの説明によれば、プライベートな会話はエンドツーエンド暗号化されており内容は保護されていた。問題は公開チャットルームだ。 設計上、公開チャットルームのメッセージは暗号化されていない。このため攻撃者は、公開チャットルームで共有されたすべてのデータ——氏名、メールアドレス、所属組織——にアクセスできてしまった。 「暗号化メッセージングアプリ」というブランドイメージと、「公開チャットは暗号化されていない」という現実のギャップ。技術的には仕様通りかもしれないが、ユーザーの認識と実態の乖離が被害を広げた。 さらに見逃せないのが、PowerShellスクリプトへのLDAP認証情報ハードコードだ。シークレット管理という基本的な対策が徹底されていなかったことが、被害拡大の一因となった可能性がある。 日本のIT現場への影響 1. 「暗号化」の適用範囲を精査する Slack、Teams、その他のコラボレーションツールにおいて、E2EE（エンドツーエンド暗号化）が適用されるのはどのメッセージか？パブリックチャンネル、ゲスト参加者との会話、ファイル共有はどうか？ツール選定・評価時に暗号化スコープを必ず確認する習慣を持とう。 2. コード・スクリプト内の認証情報を一掃する Azure Key VaultやAWS Secrets Managerなどのシークレット管理サービスを活用し、PowerShellスクリプトや設定ファイルへの認証情報ハードコードを根絶する。GitHubではgit-secretsやGitHub Secret Scanningを有効化し、コミット段階で検出する体制を整えたい。 3. 単一アカウント侵害の影響範囲を設計段階で制限する 今回は1つの侵害済みアカウントがプラットフォーム全体への入口となった。最小権限の原則とJust-In-Time（JIT）アクセスにより、単一アカウントの侵害が横展開しないアーキテクチャを設計することが重要だ。 4. 業務チャットツールもゼロトラストの対象として評価する 「社内ツールだから安全」という前提はゼロトラストの考え方とは相容れない。メッセージング基盤も他のSaaSと同様にリスク評価とアクセス制御の対象として扱い、異常なアクセスパターンを検知する仕組みを持つ。 筆者の見解 今回の件でまず気になるのは、PowerShellスクリプトにLDAP認証情報がハードコードされていたという点だ。2018年開発のツールとはいえ、政府とサイバーセキュリティ機関が共同で作ったプラットフォームで、NHI（Non-Human Identity）管理の基本が守られていなかったのはもったいない。組織的なセキュリティ成熟度の底上げなしに、いくら上位レイヤーで暗号化を施しても、足元を突かれることになる。 「公開チャットは暗号化しない」という設計判断そのものを責めるつもりはない。Matrixプロトコルの仕様上、合理的なトレードオフはある。ただ、「暗号化メッセンジャー」を全公務員の標準ツールに指定するなら、その制約をユーザーが正確に理解できるような周知が必要だったはずだ。 「今動いているから大丈夫」は通用しない——この原則は今回も証明された。73,000人という数字が、その代償を静かに示している。日本の政府・自治体も同種のツール評価を行っているはずで、この事例は他人事ではない。 出典: この記事は Over 73,000 French govt employees affected in Tchap messenger breach の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftの傘下スタジオPlayground Gamesは、人気レーシングゲーム「Forza Horizon 6」において、プレイヤーのセーブデータと進行状況が消去されるという深刻なバグを公式に認め、声明を発表した。 何が起きているのか Forza Horizon 6のプレイヤーから、それまで積み重ねてきたゲームの進行状況――解除した車両、獲得したイベント報酬、カスタマイズ設定など――が突然すべて失われるという報告が相次いだ。Playground Gamesはこれらの報告を受け、バグの存在を正式に確認する声明を公表した。 現時点では、バグの発生条件や影響を受けたプレイヤーの規模についての詳細は明らかにされていない。修正パッチのリリース時期についても、調査中とのことで具体的なスケジュールは示されていない状況だ。 なぜこれが重要か Forza Horizonシリーズはスポーツ・カーシムの中でも国内外に根強いファンを持つ人気タイトルであり、Xbox Game Passの目玉コンテンツの一つでもある。数十時間をかけて積み上げた進行状況が一瞬で消えるという体験は、プレイヤーにとって単なる不便ではなく、ゲーム自体への信頼を根本から損なう問題だ。 より構造的な問題として注目したいのが、Xboxのクラウドセーブ（Xbox Live クラウドセーブ）の信頼性だ。Microsoftはクラウドへの自動バックアップをXbox/PCゲームの標準機能として位置づけており、「ハードウェアが壊れてもセーブは守られる」というのが売り文句だった。しかし今回のバグは、クラウドセーブ側にも問題が及んでいる可能性が示唆されており、その前提を揺るがしかねない。 PC・Xboxプレイヤーへの実務的なアドバイス 現時点でプレイヤーが取れる対策は限られているが、以下の点を意識しておくとよい。 修正パッチが適用されるまではゲームを起動しない選択肢も検討する: バグが活性化するタイミングが不明な以上、起動そのものがリスクになり得る Xbox公式サポートページとPlayground GamesのSNSを定期的に確認: パッチリリースの告知が最初に出る場所はここ PC版（Microsoft Store / Steam）のセーブデータフォルダのローカルバックアップを手動で取得する: 自動クラウドセーブに頼り切らず、手動バックアップの習慣を持つことが重要 ゲームに限らず、「クラウド同期＝完璧なバックアップ」という思い込みは危険だ。クラウド同期はあくまで「最新状態の複製」であり、バグによって壊れたデータも同期されてしまう点を常に意識しておく必要がある。 筆者の見解 Playground Gamesは実力のあるスタジオだ。Forza Horizonシリーズはオープンワールドレーシングというジャンルを定義した作品群であり、その品質への信頼は長年かけて築かれてきたものだ。だからこそ、今回のセーブデータ消失バグは「もったいない」という気持ちが正直なところだ。 リリース直後の大型タイトルでバグが出ること自体は珍しくない。問題は、セーブデータという「プレイヤーとゲームの信頼関係の結晶」を守れなかった点にある。Microsoftがクラウドインフラを持ち、Xbox Game Passという規模の配信基盤を抱えているからこそ、このレベルの問題は発生前に防ぐ技術的な余力があるはずだ。QA工程でのセーブデータ整合性テストが十分だったかどうか、今後の開示を待ちたい。 迅速な修正パッチのリリースと、影響を受けたプレイヤーへのセーブデータ復元サポートが提供されることを期待したい。Playground GamesとMicrosoftには、その能力がある。 出典: この記事は Playground Games confirms Forza Horizon 6 save wipe bug の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米メイン州司法長官が運営するデータ侵害開示ポータルに、VRChatとDiscordを名乗る虚偽の侵害通知が無審査のまま公開され、両社がそれぞれ事実無根と否定した。公的機関が運営する開示制度そのものが偽情報の拡散に利用されるという異例の事態が明らかになった。 何が起きたか メイン州司法長官のデータ侵害開示データベースには、企業がセキュリティインシデントを市民に通知するための制度が設けられている。ところが今回、この制度の根本的な欠陥が突かれた。提出された情報は一切の事前検証なしに即時公開されるという運用だ。 偽の通知として確認されたのは以下の2件。 VRChat：240万人規模の虚偽通知 最初に発覚したのはVRChatを名乗る通知だ。「5月10〜12日のハッキングにより、240万人超のユーザーデータが流出した」と記載され、漏洩したとされる情報の種類も詳細に列挙されていた。 VRChatのユーザー名 メールアドレス VRChat+サブスクリプション状況 ログイン履歴（デバイス・ハードウェアID・IPアドレス含む） SteamまたはMetaのユーザーID 通知文はフォレンジック調査の経緯、実施した対策、ユーザーへの推奨アクションまで盛り込まれており、一見すると正規の通知と見分けがつかない完成度だった。しかし、VRChatのコミュニティ責任者チャールズ・タッパー氏は「この通知はVRChatが提出したものではなく、記載された従業員と連絡先も実在しない。システムやデータが侵害されたという根拠はまったくない」とBleepingComputerに明言した。 Discord：1,000万人規模の虚偽通知 同週にはDiscordを名乗る通知も出現し、1,000万人への影響が主張された。こちらは連絡先にGmailアドレスが使われ、電話番号はプレースホルダー（仮番号）のまま。侵害発生日が2024年7月9日で発見日が2025年8月8日、さらにユーザー通知日が「2000年1月1日」と明らかに不整合な日付が並ぶなど、偽物の痕跡が随所に見受けられた。 制度上の根本的な欠陥 メイン州司法長官室はBleepingComputerの取材に対し、次のように認めた。 「提出者がフォームに入力した情報はそのままサイトに掲載される。侵害に関する独自の事前調査は行っていない」 つまり、誰でも任意の企業名・従業員名・侵害内容を入力するだけで、公的機関の公式データベースに記載できるという状態だ。同長官室は今回の虚偽通知について「意図的な虚偽申告の事例は把握していなかった」とも述べており、制度設計の段階でこのリスクが想定されていなかったことが窺える。 実務への影響 日本のIT担当者・セキュリティ担当者が今回の件から得るべき教訓は二つある。 1. 公的機関の開示情報も一次確認が必要 米国では各州のAG（Attorney General）ポータルがデータ侵害の一次情報源として広く参照される。しかし今回の件が示すように、公的機関の掲載情報であっても「企業公式サイトからの一次声明」「セキュリティリサーチャーの独立確認」と照合するプロセスが欠かせない。自社の取引先や利用サービスに関する侵害報道を受けた際は、ポータル掲載内容だけで判断せず、当該企業のプレスリリースやセキュリティアドバイザリを必ず確認する習慣をつけたい。 2. 偽情報に基づく対応コストの現実 今回、VRChatとDiscordはそれぞれ社内調査・広報対応・当局への削除申請といったコストを強いられた。偽の侵害報告が増加すれば、実際の脅威への対応リソースが圧迫される「オオカミが来た」状態が常態化しかねない。これはインシデント対応計画において、情報の信憑性評価フローを明示的に定義しておくことの重要性を示している。 筆者の見解 この問題の本質は技術的な話ではなく、制度設計の話だ。「誰でも入力できて即公開」という仕組みは、透明性と利便性を高めようとした善意の設計だったはずだが、そこに悪意を持って踏み込まれると脆い。 セキュリティの世界では「今動いているから大丈夫」は通用しないと常々感じているが、今回はそれが公的機関の運用にも当てはまる事例だった。事前検証なし・即時公開という運用が「これまで問題がなかった」のは、単に誰も悪用しなかっただけのことだ。 最低限の対策として、企業が登録した公式ドメインや連絡先と提出者情報を突き合わせる程度の自動チェックは導入できるはずだ。完璧な検証は難しくとも、今回の偽Discord通知のように「Gmailアドレス」「プレースホルダーの電話番号」「2000年1月1日の通知日」といった明白な異常値は機械的に弾けた。制度の信頼性を守るためにも、この程度の仕組みは早急に整えてほしいところだ。 日本でも個人情報保護委員会への報告義務など、類似の開示制度は存在する。今回のケースを対岸の火事と見るのではなく、自国の制度に同様の脆弱性がないか確認しておく価値はある。 出典: この記事は Maine breach portal abused to publish fake data breach disclosures の内容をもとに、筆者の見解を加えて独自に執筆したものです。

九州電力株式会社は2026年6月、サーバーバックアップ用に使用した外付けストレージデバイスを紛失したと発表した。そのデバイスには顧客名・住所・電力使用量など1,090万件を超える顧客情報が格納されており、九州7県（福岡・佐賀・長崎・熊本・大分・宮崎・鹿児島）の総人口約1,260万人のうち実に86%に相当する規模の情報流出リスクが生じている。 何が起きたか 九州電力のIT担当者は、サーバーストレージの容量不足への対処として、2026年4月27日に外付けストレージデバイスへのバックアップ作業を実施した。バックアップ完了後、デバイスは複数の物理的なセキュリティ層で保護されているとされたサーバー室内のキャビネットに保管された。 ところが5月26日、担当者が回収しようとしたところ、キャビネットの鍵が開いた状態になっており、デバイス自体が消えていた。 紛失したデバイスに含まれていたデータは以下のとおり： 顧客氏名 サービス提供住所（電力供給先の住所） 電力使用量データ 電話番号 小売電気事業者名 その他関連情報 同社は銀行口座情報やクレジットカードデータは格納されていなかったと明言している。 事後対応と現状 紛失発覚後、九州電力はサーバー室に入室歴のある全関係者（57名）への聞き取り調査を実施。しかし現時点でデバイスは発見されていない。6月4日には不正持ち出しを疑い警察へ届け出ており、個人情報保護委員会および経済産業省にも報告済みだ。 経済産業省は九州電力に対し、2026年7月8日までに事件の詳細と再発防止策の報告を求めている。同社は引き続き被害を受けた顧客に個別通知を行う予定としている。 実務への影響——日本のエンタープライズが今すぐ確認すべきこと この事案が示す最大の教訓は「物理セキュリティはデジタルセキュリティと同じ重みで管理せよ」という点だ。いくらファイアウォールやEDRを強化しても、生データが入ったデバイスが物理的に持ち出せる環境では意味がない。 IT管理者が今日から見直すべき具体的なポイントを挙げる： 1. 外付けストレージは必ず暗号化する デバイスが紛失・盗難にあっても、暗号化されていれば情報の悪用リスクは大幅に下がる。BitLockerやVeraCryptなど、OSレベルの暗号化を標準化する。 2. 媒体管理台帳の徹底 USBメモリ・外付けHDDなどの可搬媒体は、貸出・返却を記録する台帳管理を義務づける。「誰がいつ持ち出し、いつ返却したか」の証跡がなければ、紛失時の原因特定ができない。 3. 物理アクセス制御の見直し サーバー室への入室履歴をICカード等で記録し、アクセス権限を最小化する。57名がアクセス可能という状況は、ゼロトラストの観点から見てもリスクが高すぎる。人数ではなく「誰が本当に必要か」を問い直す時期だ。 4. バックアップ設計の再考 「容量が足りないから外付けHDDを使った」という経緯自体が、バックアップ設計の問題を示している。クラウドストレージやNLEによるバックアップ自動化で、可搬媒体への依存を減らすべきだ。 筆者の見解 セキュリティは正直なところ得意分野ではないのだが、この事案には技術的に気になる点がいくつもある。 最も気になるのは「複数の物理的セキュリティ層で保護されていた」にもかかわらず鍵が開いていたという事実だ。これは運用ルールが形骸化していた可能性が高い。鍵の管理手順、施錠確認フロー、そのどこかに「やってるつもり」のギャップがあったのではないか。 日本の大手エンタープライズに多いのが、ゼロトラストへの移行を進める一方で、旧来の「社内に入ればOK」的な物理セキュリティ感覚が残っているケースだ。ネットワーク層では最新の認証を導入しているのに、物理アクセスの管理はアナログのまま、という「悪魔合体」状態になっている現場を筆者もいくつか見てきた。 Just-In-Timeアクセスの考え方はデジタルの世界だけの話ではない。物理的なサーバー室へのアクセスも、必要なときに必要な人だけが入れる仕組みにしなければ、どれだけ論理セキュリティを磨いても意味がない。 今回の九州電力の対応は、発覚後に警察への届け出・監督官庁への報告・個別顧客通知という手順を踏んでおり、開示姿勢は評価できる。問題が起きたときに隠蔽するより、正面から向き合う姿勢は正しい。あとは再発防止策の中身が問われる。7月8日の経産省への報告がどういう内容になるか、注目したい。 この事案を他人事にせず、自社の可搬媒体管理・物理アクセス制御を今週中に棚卸しするのが、IT担当者として取れる最善の行動だ。 出典: この記事は Japanese energy firm loses drive with data of 10.9 million clients の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GitHubは2026年6月、GitHub Copilotのネイティブデスクトップアプリケーションの技術プレビューを、Copilot Pro・Pro+・Max・Business・Enterpriseの全有料プランユーザーへ一斉開放した。従来のウェイトリスト制を廃止し、即日アクセス可能にしたこの動きは、AI支援コーディングの次のステージを明確に示している。 IDE拡張との決定的な違い これまでのGitHub CopilotはVS CodeやJetBrains IDEのプラグインとして動作し、あくまで「エディタの中」で完結していた。今回のデスクトップアプリはその枠組みを根本から変える。 スタンドアロンのワークスペースとして動作するこのアプリは、複数プロジェクトをまたいだファイル操作、ターミナルコマンドの実行、依存パッケージのインストール、さらには他のアプリケーションの操作まで、自然言語の指示だけで実行できる。 具体的なイメージとしては、「Reactプロジェクトを新規作成して、Tailwind CSSを設定し、基本的な認証フローも追加して」と一言伝えると、プロジェクト構造のスキャフォールディング、ターミナル起動、コマンド実行、ボイラープレートコードの生成までを連続して実行する——そういった体験が想定されている。 「エージェントネイティブ」とは何か GitHubが強調する「エージェントネイティブ開発」は、AIが「提案する存在」から「実行する存在」へと役割を変えることを意味する。 具体的には以下のような作業を、開発者の監督のもとで自律的にこなす： デバッグと修正: エラーを検出し、原因を特定して修正コードを適用 クロスリポジトリのリファクタリング: 複数リポジトリにまたがる変更を一括実行 テストコードの生成と実行: テストケースを書き、実際に走らせて結果を確認 バージョン管理の自動化: ブランチ作成・コミット・プルリクエスト開設まで一連の流れを処理 状態管理と権限制御を備えた設計により、複数ステップのワークフローをチェーンできる点が、従来のチャットベースのCopilot ChatやIDEプラグインとの本質的な違いだ。 対象プランと利用条件 技術プレビューが開放されるのは以下のプラン： プラン 対象 Copilot Pro 個人開発者・フリーランス Copilot Pro+ 上位機能が必要なパワーユーザー Copilot Max 高使用量の上位プレミアムユーザー Copilot Business 管理機能付きの中小チーム Copilot Enterprise セキュリティ・コンプライアンス要件のある大企業 無料プランユーザーは現時点では対象外だが、GitHubはプレビューのフィードバックを受けて拡張を検討するとしている。プラットフォームはWindowsとmacOSに対応、Linuxは今後のプレビュー進捗に応じて追加予定だ。 日本の開発現場への影響 日本のエンジニアにとって、この動きが持つ意味は大きく2点ある。 1. 開発ツールチェーンの見直し機会 VS Codeに統合されたCopilotで十分だったチームも、デスクトップアプリを試すことでエージェント型ワークフローの感触を掴める。特にCI/CDパイプラインとの連携や、複数マイクロサービスをまたぐリファクタリングなど、従来は人手が多くかかっていた作業への適用可能性を検証できる。 2. AI開発支援ツールの「次の評価軸」の把握 コード補完の精度という初期の評価軸は、すでに多くのツールがクリアしている。今後の差別化は「どこまで自律的にタスクをこなせるか」「どこで人間に確認を求めるか」という信頼設計にシフトしつつある。デスクトップアプリはその評価のよい試金石になる。 有料プランに加入している企業のエンジニアであれば、すぐに技術プレビューへのアクセスが可能だ。まずは既存プロジェクトの小規模タスクで挙動を確認し、チームの開発フローに組み込めるかを検証することから始めるのが現実的なアプローチだろう。 筆者の見解 GitHub Copilotがエージェント型へと進化する方向性は、理にかなっている。IDEプラグインとして始まった段階ではコード補完の精度が主な関心事だったが、開発者が本当に時間を費やしているのは「コードを1行書く」ことではなく、「プロジェクト全体の整合性を保ちながら変更を反映する」というより上位の作業だ。その部分をAIが担えるようになることは、開発者の働き方を根本から変えうる。 GitHubはMicrosoftのエコシステムの中でも、近年とくに積極的にAI開発投資を続けている部門のひとつだ。Copilot自体が誕生した経緯を考えると、今回のデスクトップアプリはその延長線上にある自然な発展といえる。プレビューの段階でウェイトリストをなくして有料ユーザー全員に開放した判断も、機能の自信の表れと読める。 ただ、エージェントが「どの操作を自律実行し、どの操作で人間の確認を挟むか」という判断の透明性は、今後のプレビューフィードバックを通じてぜひ丁寧に設計してほしい。特に企業環境では、AIが意図せず本番ブランチに触れたり、予期しない外部通信を行ったりしないことへの信頼が導入の鍵になる。正面から勝負できる技術的な地盤はある。あとはその信頼をどう積み上げるかだ。 エージェントネイティブ開発というコンセプトは業界全体が向かっている方向であり、早期に試して感触を掴んでおくことは、開発チームにとって損のない投資になると思う。 出典: この記事は GitHub Copilot Desktop App Preview Opens to Paid Users: Agent-Native Development Shift の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは、Windowsカーネルが持つTCP/IP処理スタックのバグを突くリモートコード実行（RCE）脆弱性「CVE-2026-45657」を、2026年6月のPatch Tuesdayで修正した。認証不要・ユーザー操作なしでSYSTEM権限をリモートから取得できるという、今月の更新プログラムの中で最も深刻な脆弱性の一つだ。 CVE-2026-45657 の概要 本脆弱性はWindowsカーネルのTCP/IP処理に起因する。攻撃者は特別に細工したネットワークパケットを送信するだけで、対象マシンのSYSTEM権限でコードを実行できる。 特に危険なのは以下の3点が重なっていることだ： 認証不要（Unauthenticated）: ドメイン参加もログインも不要 ゼロクリック（Zero-click）: 被害者が何かを開いたり操作したりする必要がない SYSTEM権限取得: OS最高権限でコードが実行される この組み合わせは「ワーム可能（Wormable）」な脆弱性の典型パターンだ。2017年に猛威を振るったWannaCry（MS17-010/EternalBlue）と同様の性質を持ち、ネットワーク越しに次々と感染を広げる攻撃が理論上成立する。 技術背景：カーネル空間で起きるメモリ破壊 Windowsカーネルは独自のTCP/IPスタックをカーネル空間で実装している。今回の欠陥は特定形式のパケットを受け取った際にメモリ破壊が発生する点にある。処理がカーネル空間内で完結するため、ユーザー空間の保護機構（DEP・ASLR等）を経由せずにSYSTEM権限が直接得られてしまう。 Microsoftは今回のCVEを最高深刻度の「Critical（緊急）」と評価している。 実務への影響——日本のIT管理者がいま取るべき行動 1. パッチを速やかに適用する ワーム可能なCriticalというカテゴリを踏まえると、通常の「数日様子を見てから」という判断は今回は避けたい。検証期間を短縮してでも、今月のPatch Tuesdayを最優先で展開することを推奨する。 WSUSやMicrosoft Intuneで管理している環境は、承認ステータスを速やかに「インストール済み」に変更しよう。 2. 緊急緩和策：ネットワーク到達性の最小化 パッチ適用までのブリッジとして： インターネット側から不要なTCPポートへの直接アクセスをファイアウォールでブロック DMZやインターネット公開セグメントにあるWindowsサーバーを最優先で保護 ゼロトラストアーキテクチャ採用済みの環境では、ネットワーク到達性を最小化できているはずであり相対的に被害範囲が限定されやすい 3. VPNゲートウェイが Windows Server の場合は要注意 VPNゲートウェイ自体がWindowsサーバーで動いている場合、そのゲートウェイが踏み台になりうる。VPN接続で「内側に入れた」状態でこの脆弱性を踏まれると、内部ネットワーク全体に攻撃が波及するリスクがある。 4. サーバーを最優先、クライアントはその次 インターネットやDMZに面したWindows Serverを最優先でパッチ適用する。エンドユーザーのWindowsクライアントは二番手だが、モバイル勤務端末が直接インターネットに接続している場合は同様に急ぐべきだ。 筆者の見解 セキュリティ分野は細かいことが多くて得意ではないと感じることが多いが、こういったカーネルレベルの脆弱性は技術的に純粋に興味深い。TCP/IPスタックに潜むゼロクリックRCEというのは、OSの根幹に触れるリスクであり、ここは真剣に向き合わなければならない。 Microsoftが6月のPatch Tuesdayで修正を提供したことは評価できる。セキュリティパッチの提供体制は近年着実に改善が続いており、その点は素直に認めたい。 一方で、「すぐ当てたら壊れた」という報告が最近増えているのも事実であり、今月のPatch Tuesdayが副作用を生じないかは数日間の報告を注視したい。ただし今回に限っては、ワーム可能なCriticalという重さを踏まえると、副作用リスクよりも未適用リスクの方が明らかに大きい。 今回の脆弱性は「ゼロトラストへの移行を急ぐ理由」をまた一つ追加した。ネットワーク境界防御だけに頼るモデルでは、TCP/IPスタックへの直撃型攻撃に対して根本的に防御しにくい。「VPNで内側に入れば安全」という考え方は、こういった事例のたびに陳腐化していく。Just-In-Timeアクセスやマイクロセグメンテーションへの投資は、こうした深刻な脆弱性が出るたびにその必要性が証明される。 出典: この記事は CVE-2026-45657: Critical Windows Kernel RCE Patch Guide (June 2026) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

セキュリティゲートウェイ製品「Ivanti Sentry」に最大深刻度（CVSSスコア10.0）のOSコマンドインジェクション脆弱性（CVE-2026-10520）が発見され、Ivantiがパッチを公開した翌日にはすでに実攻撃での悪用が確認された。 Ivanti Sentry とは 旧称「MobileIron Sentry」として知られるIvanti Sentryは、モバイルデバイスと社内バックエンドシステム間のトラフィックを保護するセキュリティゲートウェイアプライアンスです。世界40,000社以上が利用するエンタープライズIT管理ソリューションの一部であり、特にモバイルデバイス管理（MDM）環境において重要な役割を担っています。 脆弱性 CVE-2026-10520 の詳細 CVE-2026-10520はOSコマンドインジェクションの弱点に起因する最大深刻度（CVSS 10.0）の脆弱性です。インターネットに露出しているSentryゲートウェイに対して、認証なしでroot権限によるコード実行が可能になります。 Ivantiは2026年6月にパッチを提供しており、以下のバージョンが対象です： Sentry R10.5.2 Sentry R10.6.2 Sentry R10.7.1 「悪用の証拠なし」翌日に実攻撃を確認 問題の深刻さは、Ivantiがパッチ公開時に「悪用の証拠はない」と発表したにもかかわらず、翌日にはセキュリティ非営利組織 Shadowserver が実際の攻撃を観測したことです。 Shadowserverは次のように警告しています。「公開されたPoC（概念実証コード）をもとにした大量の悪用試みを確認している。自社スキャンでは19件の脆弱なインスタンスを発見し、少なくとも2件にはバックドアが仕込まれていた。しかし残りもすべて侵害済みとみられる。パッチを当てていない場合、ほぼ確実に侵害されている。」 なお、スキャンからブロックリスト化されているインスタンスも多く存在するため、実際の被害範囲はさらに広い可能性があります。 Ivanti はなぜ繰り返し狙われるのか Ivanti製品の脆弱性はハッカーにとって魅力的なターゲットです。企業ネットワークへの入口として機能するため、侵害後に機密データを窃取しやすいためです。 過去の事例を振り返ると： CISA（米サイバーセキュリティ・インフラセキュリティ庁）がIvanti製品全体で 34件の脆弱性を「実際に悪用されている」と認定 そのうち 12件はランサムウェア攻撃でも利用 政府機関を含む世界中の組織が複数のゼロデイ悪用により被害を受けた実績あり CISAは先月も米連邦機関に対しIvantiシステムへの緊急パッチ適用を命令 Ivantiは世界7,000社以上のパートナーネットワークを持つ大手ベンダーであり、その製品が狙われ続けているという現実は、エンタープライズ向けゲートウェイアプライアンス全体に共通するリスクとして捉えるべきです。 実務への影響——日本のIT管理者が今すぐやること インターネットに露出したSentryインスタンスがある場合、今すぐパッチを適用してください。 「まだ被害が出ていない」という期待は禁物です。 緊急対応チェックリスト： バージョン確認: R10.5.2・R10.6.2・R10.7.1 以降かどうかを確認 露出面の確認: Sentry管理ポータルがインターネットから直接アクセス可能になっていないか確認 侵害痕跡の調査（IoC確認）: バックドアが仕込まれていないか、ログとシステムファイルを精査 ネットワーク分離: パッチ適用まではインターネットからのアクセスを遮断 特に日本企業では、MobileIronブランド時代から導入されているレガシー環境も多く、バージョン管理が行き届いていないケースが散見されます。資産管理台帳との照合も合わせて実施することを強く推奨します。 筆者の見解 セキュリティが専門かと問われれば正直に「そうでもない」と答えます。ただ、こうした事例を見るたびに感じることがあります。 今回最も気になるのは、「悪用の証拠はない」という公式発表の翌日に実攻撃が確認されたという事実です。これはIvantiだけの問題ではなく、最大深刻度の脆弱性にもかかわらずPoC公開後の対応タイムラインが機能していないという、業界全体の課題を示しています。「今動いているから大丈夫」という油断が最大のリスクになる典型例です。 こうした攻撃が繰り返される背景には、インターネットに露出したゲートウェイが多すぎるという構造的な問題もあります。ゼロトラストアーキテクチャへの移行が進めば、そもそも「公開されたゲートウェイに直接アクセスできる」という前提が崩れます。VPNやゲートウェイ系製品が集中的に狙われる現状は、境界型セキュリティモデルの限界を改めて示していると感じます。 特に日本の大企業では、旧来のセキュリティモデルとゼロトラストの取り組みが混在し、どちらとも言えない状態になっているケースが目立ちます。今回のような事例を、アーキテクチャ全体を見直すきっかけとして活用してほしいと思います。 出典: この記事は Max severity Ivanti Sentry vulnerability now exploited in attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

英ノッティンガム大学は2026年6月11日、サイバー犯罪グループ「ShinyHunters」が学生記録システムに不正アクセスし、現役学生と卒業生を合わせた45万4,600人超の個人情報が流出したことを正式に認めた。 何が起きたのか ノッティンガム大学は英国のトップ20、世界トップ100に名を連ねる公立研究大学で、スタッフ7,000人・学生46,000人以上を抱える。同大学は声明の中で「著名なサイバー犯罪グループが学生記録システムにアクセスし、大量のデータが取得された」と認め、英国の情報コミッショナーオフィス（ICO）および詐欺通報窓口「Action Fraud」への報告済みであることも明らかにした。 ShinyHuntersはダークウェブの漏洩サイトで犯行を主張し、証拠として文書のアーカイブを公開。漏洩が確認された情報は以下の通りだ： 氏名・自宅住所・電話番号 メールアドレス・IPアドレス・生年月日 パスポート番号 民族情報・障害情報（特に機微度が高い） 学籍情報・学費・支払い情報 クレジットカード・決済情報 同大学はマレーシア・中国のキャンパスも持ち、それら含む40GB超のデータが窃取されたとされる。侵害通知サービス「Have I Been Pwned」の独自分析でも同様の被害規模が確認されている。 本命はOracle PeopleSoft——世界100社超に拡大する組織的キャンペーン 今回の攻撃は単独事件ではない。BleepingComputerの調査によれば、ShinyHuntersはOracle PeopleSoftのクラウド・オンプレミスインスタンスを標的とした世界規模のキャンペーンを展開しており、すでに100以上の組織からデータを窃取していることが判明している。 Oracle PeopleSoftは、人事・財務・給与・サプライチェーン・調達・キャンパス管理といった大規模業務を支える基幹ソフトウェアスイートだ。大学・医療機関・政府機関・大企業など、大量の個人情報を集中管理する組織で広く導入されている。 ShinyHuntersによれば、攻撃にはゼロデイと既知の脆弱性を組み合わせた「ガジェットチェーン」が使われており、インスタンスの設定状況によって攻撃の成否が変わるという。Oracleはコメントを返していないが、アクティブに悪用されているゼロデイが存在する可能性は高く、状況を注視する必要がある。 なお英国では先週、オックスフォード大学のキャリアプラットフォームもShinyHuntersに侵害されており、5月のCanvas LMS侵害に続く同大2件目の被害となっている。英国の高等教育機関が集中的に狙われている状況だ。 日本のIT現場への影響 Oracle PeopleSoftは日本の大学・企業・官公庁でも幅広く稼働している。 今回の攻撃が特定組織のみを狙ったものではなく、PeopleSoftインスタンス全体を対象とした組織的キャンペーンである点が最大の脅威だ。 IT管理者として今すぐ確認すべき事項をまとめる： PeopleSoftのバージョンとパッチ状況の即時確認: ゼロデイが含まれる可能性がある。最新セキュリティパッチの適用状況を確認し、Oracleのセキュリティアドバイザリの監視を強化する 外部アクセスログの遡及調査: 不審なAPIアクセスや認証試行がないか確認する。ShinyHuntersのキャンペーンは数ヶ月単位で継続している可能性がある 機微情報の保存範囲を把握する: 民族情報・障害情報・パスポート番号といったセンシティブデータの格納場所とアクセス制御が適切かを確認する インシデント報告フローの整備: 日本では個人情報保護委員会への報告義務がある。漏洩が疑われた際の報告フローを今のうちに確認・整備しておく 筆者の見解 ShinyHunters自身が「すべてのシステムで攻撃が通るわけではなく、設定次第」と述べている点が今回の核心だ。裏を返せば、適切に設定されたインスタンスは防げている可能性があるということでもある。 ゼロトラストの観点からすれば、PeopleSoftのような基幹システムに対してもネットワーク層・認証層・認可層の3層で防御を組み、「外から侵入できても横移動できない設計」を徹底することが求められる。今の時代、VPNで外からのアクセスを一括遮断するだけでは不十分であることを、今回の侵害は改めて示している。 ゼロデイ＋既知脆弱性の「ガジェットチェーン」という手口は、単純なパッチ管理だけでは防ぎきれない構造的な問題を示している。「今動いているから大丈夫」という感覚は、今回の被害を受けた組織も持っていたはずだ。日本のOracle PeopleSoft運用組織は、自分のインスタンスの設定と監視体制を今一度見直してほしい。 民族情報や障害情報まで含む今回の漏洩は、プライバシー被害の深刻度という意味でも極めて重大だ。技術的な対処と並行して、影響を受けた学生への迅速かつ誠実な情報提供が求められる。 出典: この記事は Nottingham University data breach affects over 450,000 students の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月のPatch Tuesdayにおいて、Windows Server 2025向け累積更新プログラムKB5094125をリリースし、4月の更新後に一部デバイスがBitLocker回復モードで起動するという既知問題を解消した。Windows 11 23H2向けにはKB5093998が対応する。 何が起きていたのか BitLockerはWindowsのストレージ暗号化機能で、ハードウェア変更やブートコンポーネントの更新が検出されると、不正アクセスを防ぐために自動的に回復モードへ移行する仕組みを持つ。今回の問題では、2026年4月のセキュリティ更新（Patch Tuesday）をインストールした後、一部のWindows Server 2025デバイスが初回再起動時にBitLocker回復キーの入力を要求するという現象が発生した。 Microsoftは当初「回復キーの入力は初回のみで、グループポリシー設定が変更されなければ以降の再起動では発生しない」と説明していたが、IT管理者にとって突然の回復画面は運用上の混乱を招く。 影響を受けた条件 この問題は非常に特定の条件が重なった場合のみ発生する。Microsoftが公開した情報によると、以下のすべての条件を満たすデバイスが対象となる。 OSドライブでBitLockerが有効になっている グループポリシー「ネイティブUEFIファームウェア構成のTPMプラットフォーム検証プロファイルを構成する」が設定されており、検証プロファイルにPCR7が含まれている（またはレジストリキーで手動設定されている） システム情報（msinfo32.exe）でSecure Boot StateのPCR7バインディングが「Not Possible」と表示されている Secure Boot署名データベース（DB）にWindows UEFI CA 2023証明書が存在し、2023署名済みWindows Boot Managerがデフォルトとして設定される条件を満たしている デバイスがまだ2023署名済みWindows Boot Managerで起動していない これらの条件はすべて企業の管理環境特有の構成であり、個人デバイスへの影響は極めて低いとMicrosoftは説明している。 技術的な根本原因 問題の核心はTPMのPCR7（Platform Configuration Register 7）の取り扱いにある。PCR7はSecure Bootの状態をTPMが記録するレジスタで、BitLockerはこの値を使ってブート環境の整合性を検証する。 今回の更新ではブートファイルの更新処理が行われ、不整合なPCR7設定を持つデバイスで意図しないBitLocker回復がトリガーされた。修正版では、互換性のないグループポリシー設定を持つデバイスに対して2023署名済みBoot Managerのインストールを抑止する仕組みが追加された。影響を受けたデバイスではシステムイベントログにイベントID 1032が記録される。 今すぐできないIT管理者向けの回避策 今月の更新をすぐに展開できない環境向けに、Microsoftは以下の暫定対応策を案内している。 KB5082063以降の更新インストール前に、問題のグループポリシー設定を削除する BitLockerのバインディングがPCR7プロファイルを使用するよう設定を見直す グループポリシーを削除する前に展開が必要な場合は、Known Issue Rollback（KIR）を適用して2023 Boot Managerへの自動切り替えを抑止する 実務への影響 日本のエンタープライズIT管理者にとって、今回の修正はいくつかの実務的な示唆を持つ。 まず、BitLockerグループポリシーの棚卸しを。今回影響を受けたのは「推奨されない設定」とMicrosoftが明示した構成だ。PCR7を含む検証プロファイルの設定が本当に必要かどうか、セキュリティポリシーを見直す好機だ。 次に、Patch Tuesday前の検証環境整備。本番環境へ適用する前に少数の検証機で動作確認するプロセスが重要性を増している。BitLockerが有効な環境では、回復キーの保管状況（Active Directory / Microsoft Entra IDへのバックアップ状態）も合わせて確認しておきたい。 また、イベントログの活用を。今回はイベントID 1032で影響を把握できる。MicrosoftがこのようなIDを公開している場合は、監視ルールに追加しておくと迅速な対応につながる。 なお、BitLocker関連の問題は今回が初めてではない。2024年8月には7月の更新後に全Windowsバージョンで同様の問題が発生し、2025年5月にはWindows 10向けの緊急更新がリリースされるケースがあった。繰り返すパターンとして認識しておく必要がある。 筆者の見解 セキュリティは正直なところ得意分野ではないが、BitLockerとTPMの仕組み自体は技術的に面白い。今回の問題を読み解くと「推奨されない設定」が原因とはいえ、その設定を企業ポリシーとして長年運用してきたIT部門を一方的に責めるのは酷だとも思う。 気になるのは、Microsoftが4月のPatch Tuesdayで問題を認識してから修正までに2ヶ月を要した点だ。エンタープライズ環境でBitLockerの回復が発生すると、深夜対応や拠点ごとのリモート支援など現場負荷は甚大になる。Microsoftほどの技術力があれば、もう少し早い対応ができたのではないかと感じる。もったいない。 とはいえ、根本原因の説明とKIRという暫定回避策の提供、そしてイベントIDによる診断情報の公開は評価できる。透明性の面ではしっかり仕事をしている。 繰り返しになるが、BitLockerとTPMの設定は「作り手の意図した使い方」に沿うのが一番安全だ。カスタムPCR検証プロファイルを独自に組んでいる環境は、この機会に設計意図を再確認しておいてほしい。セキュリティの細部は面倒くさいが、ここを怠ると今回のように突然の痛みを伴う。 出典: この記事は Microsoft fixes BitLocker recovery bug on Windows Server 2025 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは、Windows 11のローカルAI機能「Language Model API」について、これまでCopilot+ PC専用としていた制約を緩和し、NVIDIA GeForce RTX 30シリーズ以降のGPU（VRAM 6GB以上）を搭載した一般的なPCでも開発者向けに利用可能にすると発表した。 Copilot+ PCの「NPU縛り」は技術的必然ではなかった Copilot+ PCは2024年6月に正式登場した、MicrosoftによるAI対応PC規格だ。「16GB RAM・SSD・40 TOPS以上のNPU（Neural Processing Unit）」が条件とされており、Windows RecallやClick to Do、テキスト生成・画像生成といったローカルAI機能はこの規格に縛られていた。 今回の発表が明らかにしているのは、重要な事実だ——NPU限定という制約は、技術的な必然性ではなくマーケティング上の判断だった。GPUはNPUよりAIモデルの実行性能が高いにもかかわらず、Copilot+ PCブランドの価値を維持するためにGPUでの動作を意図的に制限していたのである。 Microsoftは公式GitHubドキュメントの更新を通じて静かに確認した内容は次の通りだ。「Language Model API on GPU（実験的）」として、RTX 30以降・VRAM 6GB以上のGPUを搭載したCopilot+ PC以外のWindows 11マシンでも、開発者がローカルLLM機能を利用できるようになる。 Phi SilicaとWindows AI APIの仕組み このAPIを支えているのは、Microsoftが開発した小型言語モデル「Phi Silica」だ。対応アプリがAPI呼び出しを行うと、Windows UpdateがPhi Silicaモデルをダウンロードし、ローカルGPU上で推論を実行する仕組みになっている。 現時点でAPIを通じて利用できる主なAI機能は以下の通りだ。 テキスト要約（TextSummarizer） 文章のリライト（TextRewriter） テキストからテーブルへの変換（TextToTableConverter） テキスト生成・画像生成（Windows.AI系API） なお現状はあくまでも開発者向けの実験的機能であり、一般ユーザーがすぐにRecallやClick to Doをそのまま使えるようになるわけではない。しかし、エンドユーザー向け機能の拡張への足がかりであることは間違いない。 実務への影響——既存GPUマシンを活かせ 日本のエンジニア・IT管理者にとって、この変更が意味するのは大きく2点だ。 既存GPUマシンの再活用が進む 社内のNVIDIA RTX 30/40シリーズ搭載ワークステーションやゲーミングPCは、Copilot+ PC非対応であっても、今後はWindowsローカルAI機能の開発・評価に使える可能性が高まった。新たなPC調達を待たずに、手元の環境でAI機能の検証を始められる。 Windows向けAIアプリ開発の裾野が広がる Windows AI APIを活用したアプリ開発において、テスト環境の確保が容易になる。開発チーム全員がCopilot+ PCを持っていなくても、RTX 30以降のGPUがあれば検証できる環境が整いつつある。 ただし、法人向けPC管理においてはPhi Silicaモデルのダウンロード（Windows Update経由）がネットワークポリシーやデータガバナンスに影響する可能性がある。エンタープライズ環境では事前の影響評価と、必要に応じたWindows Updateの制御設定見直しを推奨する。 筆者の見解 Copilot+ PC専用というNPU縛りが、技術的な必然性ではなくブランド戦略の産物だったことが今回ではっきりした。GPUの方が性能が高いにもかかわらず制限をかけていたのは、率直に言って「もったいない」判断だったと思う。Microsoftが持つWindows・GPUエコシステム・AI技術の組み合わせは本来もっと競争力があるはずで、人工的な制約がその実力を抑えてきた面は否定できない。 今回の緩和は正しい方向への一歩だ。ローカル推論が広がれば、プライバシーを重視する企業ユーザーにとっても選択肢が増える。Phi Silicaの品質が今後どこまで向上するか、そしてWindows AI APIを使ったサードパーティアプリがどれだけ出てくるかが、Windowsプラットフォームのローカルモデル活用が「本物の価値」を持てるかの分岐点になるだろう。Microsoftが正面から実力勝負できる環境を自ら整えていくことを期待したい。 ...

AIアプリケーション開発プラットフォーム「Langflow」に存在する高深刻度のパストラバーサル脆弱性（CVE-2026-5027）が、インターネット上に公開されたサーバーに対する実際の攻撃に悪用されていることが、セキュリティ研究機関VulnCheckのハニーポット観測で確認された。 Langflowとは Langflowは、AIアプリケーション・AIエージェント・RAG（Retrieval-Augmented Generation）システム・MCPワークフローを、ドラッグ&ドロップのビジュアルインターフェイスで構築できるオープンソースプラットフォームだ。従来のコーディング不要でAIワークフローを組み立てられることから、AI開発チームの間で急速に普及しており、GitHubでのスター数は14万9,000件超、フォーク数は9,200件を超える人気プロジェクトである。 脆弱性の詳細：CVE-2026-5027 今回問題となっているCVE-2026-5027は、Langflowのファイルアップロード機能に存在するパストラバーサル（ディレクトリトラバーサル）脆弱性だ。 具体的には、POST /api/v2/files エンドポイントが、マルチパートフォームデータの filename パラメータを適切にサニタイズ（無害化）していない。攻撃者は ../ のようなパストラバーサル文字列を利用することで、サーバーのファイルシステム上の任意の場所にファイルを書き込むことが可能になる。 この脆弱性を発見したTenableによれば、問題はさらに深刻だ。Langflowはデフォルトで未認証の自動ログインが有効になっており、認証情報なしで脆弱なエンドポイントに到達できる。つまり、たった1回の未認証リクエストで有効なセッショントークンを取得し、そのまま攻撃を実行できてしまう。 発見から修正までの経緯 2026年初頭: TenableがLangflowチームに脆弱性を報告（返答なし） 2026年3月27日: 2ヶ月以上経過しても返答がなかったため、Tenableが脆弱性を公開 2026年3月30日: Snyk Securityが修正版を確認 langflow-base パッケージ v0.8.3 で修正 Langflowアプリケーション本体は v1.9.0 で修正 修正版リリース後も積極的な悪用が続いており、VulnCheckはハニーポットで脆弱なインスタンスへのテストファイル書き込みを検出している。Censysのスキャンでは約7,000台のLangflowインスタンスがインターネットに公開されていることが確認された（ただしこの数値は過去12ヶ月の履歴を含む）。 相次ぐLangflowへの攻撃 今回のCVE-2026-5027は、Langflowを狙った攻撃の連続の中の1件に過ぎない。2026年に入ってから、CVE-2026-0770、CVE-2026-21445、CVE-2026-33017と複数の脆弱性が立て続けに悪用されている。 さらに2025年には、米国CISA（サイバーセキュリティ・インフラセキュリティ庁）がCVE-2025-3248の積極的悪用を警告しており、VulnCheckはイランの脅威グループ「MuddyWater」による活動が現在も継続していると報告している。 日本の現場への影響：今すぐ確認すべきこと AI開発ツールが急速に普及している今、社内のAIチームや開発部門がLangflowを使用していないかを確認し、以下の対応を即座に実施することを強く推奨する。 即座に実施すべき対応: バージョン確認と更新: Langflowを使用している場合は、本日リリースされた最新版 v1.10.0 への更新を速やかに実施する インターネット露出の確認: LangflowインスタンスがパブリックなIPアドレスに公開されていないか確認する。Censysのスキャンで7,000台が露出していることからも、想定以上に公開されているケースが多い 認証設定の見直し: デフォルトの未認証自動ログインが有効になっているインスタンスは、認証を必須に変更する ファイルシステムの監査: すでに攻撃を受けていないか、サーバー上に不審なファイルが作成されていないか確認する 特に、PoC（概念実証コード）の公開後わずか数週間で積極的な悪用が始まった点は、AIツールを標的とした攻撃サイクルが非常に速くなっていることを示している。 筆者の見解 AIアプリ開発ツールの脆弱性管理は、これからのIT部門の必須課題になると感じている。 LangflowのようなノーコードAIプラットフォームは、エンジニアでない担当者でもAIワークフローを構築できるとして急速に普及した。しかし、「導入の手軽さ」を実現するための設計判断——今回で言えば「デフォルトで認証なしでアクセスできる」——が、セキュリティ上の重大なリスクを引き起こすのは、AIツールに限らず繰り返されてきたパターンだ。 「デフォルトで安全」（Secure by Default）の原則は今やセキュリティの基本中の基本だが、AI開発ツール界隈ではまだ十分に根付いていない。利便性を優先するあまり、本番環境でそのまま使われてしまう危険なデフォルト設定が放置されている状況は、早急に改善されるべきだろう。 加えて、開発チームが脆弱性報告に2ヶ月以上無応答だったという事実は、オープンソースプロジェクトのセキュリティレスポンス体制として見過ごせない問題だ。エンタープライズ用途で採用する際は、機能の豊富さだけでなく、開発チームのセキュリティ対応能力も評価基準に加えることをお勧めしたい。 AIツールの採用が加速する今だからこそ、「便利なものを素早く使い始める」という姿勢と「それを安全に運用するための仕組みを整える」という姿勢の両立が、IT部門の腕の見せどころになっている。 出典: この記事は Path traversal flaw in AI dev platform Langflow exploited in attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月、Windows 11のInsider PreviewビルドにおいてWindows Updateの一時停止を「無制限」に延長できる機能を正式導入した。あわせて次期バージョン「26H1」向けの新ブランチ（BetaおよびExperimental）が切り出され、Insider Programのチャンネル構成も刷新されている。 Windows Updateの一時停止、回数制限がついに撤廃 従来のWindows 11では、Windows Updateの一時停止は最大35日間（7日間×5回）という上限が設けられていた。今回のInsider Previewビルドでは、この回数制限が撤廃され、ユーザーが必要に応じて何度でも一時停止を延長できるようになった。 この変更はコンシューマー向けのWindows 11 Home／Proエディションに適用されると見られており、企業向けのWindows Update for Business（WUfB）やIntune管理ポリシーとは別の文脈での変更となる点に注意が必要だ。 26H1向け新ブランチ構成 Insider Programのチャンネル構成も以下のように整理された。 チャンネル 位置づけ Canary 最速・最不安定。実験的機能を最初にテスト Dev 開発初期フェーズ Beta（新設） 26H1向けの安定化済みビルド Experimental（新設） 26H1の実験的機能専用 BetaとExperimentalを26H1向けに分離したことで、「安定性重視のフィードバック」と「最先端機能のテスト」を明確に切り分けている。26H1の一般提供は2026年後半が想定されており、これに向けた品質安定化プロセスが本格始動した形だ。 実務への影響 個人・家庭ユーザー 最も恩恵を受けるのはコンシューマー向けユーザーだ。業務PCを自宅で兼用しているケース、ゲーミング環境、クリエイティブ作業中など「今すぐ再起動したくない」「この時期に大型更新は避けたい」という場面で、選択の自由度が大幅に高まる。 中小企業のIT担当者 個人向けライセンス（Home／Pro）を社内で使っている中小企業では、この変更が社員のPC管理に影響する場合がある。エンドポイント管理ツールを導入していない環境では、社員が自分の判断で更新を長期保留するリスクも生まれる。運用ガイドラインの見直しを検討する価値があるだろう。 検証・テスト担当者 新しいBeta／Experimentalチャンネルの分岐は、26H1の機能評価を行うIT担当者にとって管理しやすい構成だ。安定したフィードバックと最先端機能のテストを別々のマシンで並行させる運用が組みやすくなる。 筆者の見解 Windows Updateをめぐっては「すぐ当てたら壊れた」という報告が後を絶たず、特に品質問題が注目された時期以降、「いつ当てるか」の判断がIT担当者の頭を悩ませてきた。今回の一時停止無制限化は、その状況に対してMicrosoftが一定の現実を認めた形とも受け取れる。 ただし、この変更を「更新を避け続けるための機能」と捉えるのは危険だ。正しい使い方は「リリース直後の数日間は様子を見て、問題がなければ当てる」という判断の余地を確保することであり、セキュリティパッチを無期限に先送りすることではない。この機能を正しく活用できるかどうかは、ユーザーのリテラシーにかかっている。 26H1については、Canaryで見えてきた変更がエンドユーザーの目に見えるレベルで届くのかどうか、BetaとExperimentalチャンネルの動向を引き続き追っていきたい。Microsoftには、Insider Programで集めたフィードバックを品質向上に着実につなげてほしい。その力は十分に持っているはずだから。 出典: この記事は Microsoft Releases Windows 11 Insider Builds With Unlimited Update Pause Extension and New 26H1 Branch の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftのCopilot担当EVP（エグゼクティブ・バイスプレジデント）であるJacob Andreou氏が、「約束を果たせない場所からCopilotを削除することが不可欠だ」とX（旧Twitter）に投稿し、すぐに削除するという一幕があった。投稿は消えても言葉の重みは消えない——これを機に、Microsoftは2年以上続けてきた「Copilotをあらゆる場所に」路線を、静かに、しかし確実に巻き戻し始めている。 何が変わったのか——具体的な変更点 2026年3月、Windows & Devices 部門プレジデントのPavan Davuluri氏が「Windowsの品質へのコミットメント」と題したブログを公開し、AI機能の整理縮小を宣言した。これは言葉だけでなく、実際のプロダクトに反映されつつある。 Snipping ToolとPhotoアプリから「Ask Copilot」ボタンが完全削除 メモ帳（Notepad）の右上に鎮座していたカラフルなCopilotロゴを撤去。生成AI機能自体は残るが、名称は「Writing Tools（ライティングツール）」に変更 Xboxでは、Xbox CEOのAsha Sharma氏がモバイル版Copilotの段階的終了とコンソール版の開発停止を公表 特徴的なのは、機能そのものを消すのではなく「Copilotというブランド」を前面に出すのをやめている点だ。Microsoftは今、AIを「見えない存在」にしようとしている。 なぜこれが起きたのか——「Everything Copilot」戦略の蹉跌 2023年末にCopilotが登場した当初、反応は概ね好意的だった。しかし、OpenAIへの多額の投資回収を急ぐ中でMicrosoftが選んだ手段は、Copilotブランドを全製品に貼り付けることだった。 Office 365は「Microsoft 365 Copilot」に改名され、Windowsのタスクバーにはアイコンが強制配置、Edgeも同様に飲み込まれた。ユーザーの選択の余地なく「使わされる」AIは、当然のように反発を招いた。「Microslop」という揶揄まで定着し、ブランドイメージが傷ついた。 歴史は繰り返す——2001年のTablet PC、2010年のWindows Phone UIといった「鳴り物入りで始まり、静かに収束した」製品群と同じ構図だ。 日本のエンジニア・IT管理者への実務的影響 短期的には「朗報」と受け取ってよい。 企業IT部門がCopilotの有効・無効をグループポリシーで管理している場合、今後は管理対象の機能が整理されて見通しがよくなる可能性が高い。 注意すべき点として、機能名称が「Writing Tools」等に変わることで、エンドユーザー向けマニュアルや研修資料の更新が必要になるケースがある。特に「Copilot」という名前で社内展開を説明している環境では、名称変更が混乱を招かないよう事前周知を検討したい。 また、Copilot+ PCの文脈でのAI機能（Recall等）はこの整理とは別の動きであり、引き続き注視が必要だ。Windowsのローカル推論機能はブランド整理の対象外とみられる。 筆者の見解 正直に言えば、この方向転換は遅すぎたくらいだと思っている。ただ、遅くても向きを変えたことは評価したい。 気になるのは削除されたAndreou氏のポスト——「約束を果たせない場所からは削除すべき」という言葉自体は正しい。それをなぜ削除したのかが象徴的だ。本当の問題は技術ではなく、「失敗を認めるコスト」に今も耐えられない社内文化の方かもしれない。 MicrosoftにはAzure AIやM365の企業向けサービスで積み上げてきた本物の実力がある。コンシューマー向けWindowsのUIにブランド名を押し込んで薄まらせる必要など、本来はないはずだ。AIを「見えない基盤」に落とし込み、ユーザーが自然に恩恵を受ける形——それがいま目指そうとしている方向なら、筆者は応援したい。 Copilotがいつか最前線の選択肢として名前を呼ばれる日が来ることを、今も期待している。今回の整理がその第一歩であってほしい。 出典: この記事は Windows 11 pulls back AI as Microsoft plans to remove Copilot where it doesn’t meet its promise の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoDaddyが提供するWordPress一括管理プラットフォーム「ManageWP」を標的にしたフィッシングキャンペーンが確認された。Googleの広告枠（スポンサード検索結果）に偽のManageWPログインページを表示し、管理者の認証情報と二要素認証（2FA）コードをリアルタイムで窃取するという高度な手口だ。セキュリティ企業Guardio Labsが調査・公開した。 ManageWPとは何か、なぜ狙われるのか ManageWPは、複数のWordPressサイトを単一のダッシュボードから一元管理できるサービスだ。Webエージェンシーやフリーランスの開発者、企業が「クライアントのサイトをまとめて管理する」ために使うツールで、WordPress.orgの統計によれば関連プラグインは100万サイト以上で有効化されている。 攻撃者にとってManageWPのアカウントは「マスターキー」に相当する。Guardio Labsの主任研究員Nati Talによれば、1アカウントが数百サイトを管理しているケースも珍しくない。つまり1件の認証情報窃取で、数百サイトへの同時侵害が可能になる。 2FAも突破するAitM（Adversary-in-the-Middle）の仕組み 今回の攻撃が従来のフィッシングと大きく異なる点は、リアルタイムの中間者（AitM）プロキシを採用していることだ。 通常のフィッシングは「偽サイトでID/パスワードを入力させて盗む」だけだが、AitMでは偽サイトが本物のManageWPとの通信を中継する。被害者がIDとパスワードを入力すると、攻撃者はそれを即座に本物のサービスへ送信。すると本物のサービスから2FAコードが被害者のスマートフォンに届く。被害者が偽サイトで2FAコードを入力すると、攻撃者はそのコードも中継して認証を完了し、有効なセッションを奪取できる。 入力した認証情報はTelegramチャンネルに送信される仕組みで、攻撃者のC2（コマンド＆コントロール）パネルにはドロップダウン操作のコマンドシステムが備わっており、対話型・オペレーター主導のフィッシングフローを実現している。 「Google検索の上位」というトリガー 攻撃のエントリポイントは、Googleで「managewp」と検索したときに表示されるスポンサードリンク（広告枠）だ。正規の検索結果より上位に偽サイトが表示されるため、ブックマークをしていないユーザーや「Googleで検索してURLを探す」習慣のあるユーザーが騙されやすい。 Guardio LabsはC2インフラへの侵入に成功し、200名以上の被害者を確認。現在は被害者への通知活動も進めている。 また、コード内にロシア語の免責事項が埋め込まれていたことも判明。「違法行為には責任を負わない」「教育・研究目的での利用を想定」「ロシア国内システムへの使用禁止」といった内容で、コモディティキットではなくプライベートなフィッシングフレームワークと見られている。 実務への影響——Webエージェンシーとサイト運営者が今すぐすべきこと ManageWPユーザーへの即時対応: ログインURLは必ずブックマークからアクセスする。検索結果（特に広告枠）から飛ばない Googleスポンサードリンクのアイコン（「スポンサー」表示）を常に確認する習慣をつける 不審なログインがないか、アカウントのアクティビティログを確認する パスワードを即座に変更し、既存セッションをすべて無効化する IT管理者・セキュリティ担当者向け: AitM攻撃は2FAを突破するため、「2FAを設定しているから安全」という前提を捨てる パスキー（FIDO2）やハードウェアキーなど、フィッシング耐性のある認証方式への移行を検討する 社内でManageWPを使っているチームに対して、今回の手口を周知徹底する Google広告経由の偽サイトは広告費さえ払えば誰でも上位表示できるという構造的問題を認識し、重要サービスのURLは必ずブックマーク管理するポリシーを設ける 筆者の見解 AitM攻撃そのものは目新しい技術ではない。ただし今回注目すべきは、「Googleの広告インフラを悪用する」という手口の再現性の高さだ。GoogleはAd Policiesで偽装広告を禁止しているが、現実には検知が後手に回ることが多い。「検索エンジンのトップに出るから信頼できる」という感覚的な安心感が、攻撃者にとって最大の武器になっている。 ManageWPのような「多サイト一括管理」ツールは、業務効率の観点からは非常に合理的な選択だ。しかしそれは同時に、「一点突破で大規模被害が出る」攻撃面の拡大でもある。エージェンシーや管理受託業者がこうしたツールを使う場合、認証の堅牢性を通常の業務ツール以上に高める必要がある。 AitMへの根本的な対策はパスキー（FIDO2）への移行だ。フィッシングサイトにいくら正確なパスワードと2FAコードを入力させても、パスキーはオリジン（ドメイン）バインドされているため中継が機能しない。「2FAを設定しているから大丈夫」という安心感はもう通用しない——そのアップデートを今すぐ組織に伝えてほしい。 WordPressエコシステムは日本でも大量のサイト運営基盤として使われている。今回の200件という被害数は公表値に過ぎず、実態はさらに広い可能性がある。ManageWPに限らず、複数サービスを一括管理する「ハブ系ツール」のログインURLは今日中にブックマーク登録し、検索経由でのアクセスをやめることを強く勧めたい。 出典: この記事は Hackers abuse Google ads for GoDaddy ManageWP login phishing の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ValveがSteam ControllerのCAD設計データを一般公開し、MOD（改造）愛好家によるハードウェアカスタマイズが正式に解禁された。利用は非商用目的に限られ、保証は失効するが、3Dプリンターや工作機械を使った自作パーツへの換装が現実的な選択肢となった。 CADデータ公開の概要 Valveが公開したのはSteam ControllerのCAD（Computer-Aided Design）設計ファイルで、コントローラーの外装・内部構造を正確に再現したデータセットだ。これを使えば、3DプリンターやCNC加工機を持つメーカー系ユーザーがオリジナルのグリップ形状、ボタンカバー、内部ブラケットなどを自作できる。 Valveは公開にあたり、いくつかの条件を明示している： 非商用利用に限定: 作成したMODパーツを販売・頒布することは認められていない 保証は無効: 改造した時点でValveの製品保証は失効する 自己責任での利用: 改造によるハードウェア破損や安全上の問題はユーザー側の責任 こうした条件はオープンソースハードウェアの世界では一般的なアプローチだが、ゲームコントローラーメーカーがここまで踏み込んだ設計情報を公開するのは珍しい。 なぜこれが重要か Steam Controllerは2015年に発売された独自設計のコントローラーで、2019年に製造終了となっている。既存のユーザーにとっては「修理部品が入手できない」という長年の課題があった。今回のCADデータ公開は、この問題をコミュニティ主導で解決する道を開くものだ。 より広い視点で見ると、この動きはハードウェアの「Right to Repair（修理する権利）」の文脈とも重なる。近年、米国欧州を中心に消費者が自分のデバイスを修理・改造できる権利を法制化しようとする動きが活発化しており、Valveの今回の判断はその流れに沿った自発的な対応とも言える。 実務での活用ポイント メーカー・ハードウェアエンジニアへの示唆 今回のケースは、製品ライフサイクル終了後のコミュニティサポートモデルとして参考になる。製品終了後もCADデータを公開することで、ユーザーコミュニティが保守を引き継ぐエコシステムを形成できる。IoTデバイスや産業用機器の設計者も、同様のオープン化戦略を検討する価値がある。 3Dプリント・Makerコミュニティ向け FDM・SLA対応の3DプリンターがあればCADデータから直接造形可能 Fusion 360やSolidWorksなどのCADツールでの改造設計に活用できる Thingiverse・Printablesなどのプラットフォームで派生デザインの共有が期待される（ただし非商用範囲に注意） 日本の電子工作・ゲームハードウェアコミュニティ 日本国内でも秋葉原系のハードウェアMODコミュニティや、大学のFabLabなどでこのデータが活用されそうだ。ゲームコントローラーのアクセシビリティ改造（障害を持つユーザー向けカスタマイズ）にも応用できる可能性がある。 筆者の見解 Valveのこの判断は、ハードウェアメーカーとしての誠実さを感じさせる。製品を終了させてユーザーを「使い捨て」にするのではなく、コミュニティに設計の主導権を渡すアプローチは、長期的なブランドへの信頼につながる。 Windowsエコシステムを長年見てきた立場から言えば、ソフトウェア側のオープンソース文化に比べて、ハードウェアのオープン化はまだまだ遅れている。Valveのような事例が増えることで、「製品終了＝ゴミ箱行き」という消費型のサイクルに少しずつ変化が生まれると期待したい。 ただし現実的なハードルもある。CADデータを活かすには3Dプリンターや基本的な工作スキルが必要で、一般ユーザーには敷居が高い。今後、コミュニティが「普通の人でも使いやすい改造キット」を派生させていけるかどうかが、この取り組みの真の評価軸になるだろう。 出典: この記事は You can now mod your Steam Controller through Valve’s CAD files の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが、日常のメール操作における「ちょっとしたミス」を取り消しやすくするOutlookの新機能を開発中であることが明らかになった。今回の改善により、これまでカバーされていなかったより多くのシナリオで、誤送信のリカバリーが可能になるとされている。 何が変わるのか Outlookにはこれまでも「送信取り消し（Recall）」や「元に戻す送信（Undo Send）」といった機能が存在していたが、対応できるシナリオには制限があった。たとえば、受信側が既に開封している場合や、組織外のユーザーへ送信したケース、Exchange以外のメールサーバーを介したメールなどは、従来の取り消し機能では対処が難しかった。 今回Microsoftが準備しているのは、こうした「これまで諦めるしかなかったシナリオ」を拾い上げる改善だ。具体的にどのシナリオが新たに対象になるかはまだ詳細が公開されていないが、日常的なビジネスシーンでのミス対処という観点で、実用性の向上が期待される。 なぜこれが重要か ビジネスメールの誤送信は、情報漏洩インシデントの中でも件数として上位に入る問題だ。宛先の間違い、添付ファイルの誤り、下書き段階のメールを誤って送信してしまうケースなど、どれだけ経験を積んだビジネスパーソンでも避けられないヒューマンエラーである。 日本では、メールセキュリティ製品として「誤送信防止ゲートウェイ」を導入している企業が多く、送信前に一定時間（5〜30秒程度）の保留を行うことで誤送信を防ぐ仕組みが普及している。しかしこれはオンプレミス的な発想であり、Microsoft 365への移行が進む中で、クライアント側・プラットフォーム側での誤送信対策がより重要になっている。 Outlook本体にこうした機能が組み込まれることで、サードパーティ製品に頼らずとも一定の誤送信リカバリーが可能になるという点は、IT管理者にとっても注目に値する動きだ。 実務での活用ポイント Outlookユーザー（エンドユーザー）向け 現時点でもOutlookには「送信取り消し」オプションが存在する。設定から遅延送信（ルール設定）を活用することで、誤送信後のバッファ時間を確保できる 本機能が正式リリースされた際は、どのシナリオが対象かを公式ドキュメントで確認し、対応範囲を正しく理解した上で使うこと。「万能の取り消しツール」ではない点に注意 IT管理者向け Exchange OnlineおよびMicrosoft 365の環境では、メッセージトレースやコンプライアンスセンターと組み合わせることで、誤送信後の対処をより包括的に行える 社内の誤送信防止ポリシーをゼロベースで見直す機会と捉えてほしい。「サードパーティ製品が必要か」「Outlook標準機能でどこまでカバーできるか」を整理しておくと、将来的なコスト最適化につながる 筆者の見解 正直なところ、誤送信リカバリーは「あって当然」の機能であり、今さら感は否めない。GmailのUNdo Send（送信取り消し）は2015年に正式機能化されており、設定から最大30秒の取り消しウィンドウを設定できる。Outlookがここを本格的に強化するのは遅かったとは思うが、「より多くのシナリオへの対応」という方向性は正しい。 MicrosoftのOutlookは、Microsoft 365エコシステムの中心にあるアプリケーションだ。TeamsやSharePoint、OneDriveとの連携も含めて、単体の生産性ツールとしてではなく統合プラットフォームの一部として機能している強みがある。こうした「地味だが本当に必要だった」改善を丁寧に積み重ねることは、長期的なユーザー信頼の積み上げに直結する。 日本の企業では、誤送信インシデントが情報セキュリティ報告書の常連上位に登場し続けている。メールというインフラが変わらない以上、プラットフォーム側での安全網の拡充は歓迎したい。詳細の発表を待ちつつ、実際の対象シナリオを見極めてから評価したい。 出典: この記事は Microsoft is bringing a much-needed feature to Outlook の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月、Windows 11の最新プレビュービルド（Build 26300.8346）で、Windows 10に存在した「小さいタスクバー」機能のテストを開始した。2021年のWindows 11リリース時に削除されたこの機能が、約5年越しに正式復活へ向けて動き出している。 Windows 10にあった「あの機能」がやっと戻ってくる Windows 10では、タスクバーの高さを自由にリサイズできる機能が標準で用意されていた。ところが2021年にWindows 11がリリースされた際、Microsoftはこの機能を削除。初期ビルドではドラッグ＆ドロップ機能まで廃止されたため大きな反発を招き、後者はユーザーの声を受けて復活したものの、タスクバーのリサイズ機能は今日まで戻ってこなかった。 最新プレビュービルドでは、タスクバーを縮小した際に表示されるウィジェットボタンの新しい小型デザインなど、実装の痕跡がすでに確認されている。また、タスクバーを画面端に移動できる「ムーバブルタスクバー」も並行して開発が進んでおり、Windows 10に存在したタスクバー関連の機能が一気に復活しつつある。 現在の「小さいタスクバーボタン」との違い Windows 11には現在、[設定]→[個人用設定]→[タスクバー]→[タスクバーの動作] に「タスクバーボタンを小さくする」トグルが存在する。ただしこれはボタンのアイコンを縮小するだけであり、タスクバー自体の高さは変わらない。 今回テストされているのは、タスクバー全体をリサイズできる機能だ。タスクバーの端にカーソルを合わせてドラッグすることで、Windows 10のように高さを調整できるようになる見込み。ドキュメントには専用の設定項目への参照も確認されており、完成度の高い実装が期待できる。 18項目に及ぶ大規模アップデートの一環 このタスクバー機能の復活は単独の話ではなく、Microsoftが進めるWindows 11の大規模テストの一部だ。同社は2026年3月に「Windows 11が方向を見失っていた」と公式に認め、最大18項目にわたる大幅な改善計画を発表した。 具体的にはパフォーマンス向上、広告の削減、ファイルエクスプローラーの高速化などが含まれており、2026年4月のオプションアップデート（Build 26200.8328）ですでに一部の改善が展開されている。「約束だけして終わる」ではなく、実際にプレビュービルドで変化が確認できるのは注目に値する。 実務への影響 企業のIT管理者にとって、この変更は基本的に対応不要だ。タスクバーのリサイズは個人設定の問題であり、セキュリティや業務アプリの動作に影響しない。 ただし、GPO（グループポリシー）でタスクバー表示をカスタマイズしている環境では、新しい設定オプションが追加されるタイミングで既存ポリシーとの整合性を確認しておくと安心だ。プレビュー段階から動作を把握しておくことで、本番展開時の混乱を防げる。 エンドユーザー視点では、特にマルチモニター環境や小型ディスプレイを使う開発者に恩恵が大きい。タスクバーを縮小することで垂直方向の表示領域が増え、コーディングや資料作成の作業効率向上が見込める。 筆者の見解 正直に言えば、「2021年に削除して5年後に戻す」というのはMicrosoftが実に得意なパターンだ。ドラッグ＆ドロップ機能もそうだったし、今回のタスクバーリサイズもそう。最初から残しておけばこんなに時間がかからなかった、と思うのは自分だけではないはずだ。 ただ、今回は少し違う点がある。Microsoftが公式に「方向を見失っていた」と認めたこと、そして言葉だけでなく実際にプレビュービルドで変化が確認できること。この2点は過去の「約束して終わり」とは異なる動きに見える。 Windowsというプラットフォームには、まだ膨大なユーザーベースと企業の信頼がある。ユーザーの声に真摯に向き合い、「使いやすいOS」という原点に立ち戻ろうとしているなら、それは素直に歓迎したい。「タスクバーを小さくしたい」という要望は些細に見えて、毎日作業するエンジニアにとっては積み重ねの話だ。5年かかったとはいえ、その声が届いたということは評価できる。今がWindows 11にとっての本当の分岐点かもしれない。 出典: この記事は Microsoft finally begins testing Windows 10-like smaller taskbar for Windows 11 after removing it in 2021 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Palo Alto Networks は2026年5月7日、PAN-OS のユーザーID認証ポータル（Captive Portal）に存在するゼロデイ脆弱性 CVE-2026-0300 が、国家支援とみられる脅威アクターによって約1ヶ月にわたって悪用されていると警告した。インターネットに公開されたPA-Series・VM-Seriesファイアウォールが対象であり、パッチはまだリリースされていない。 脆弱性の概要：認証不要でrootを奪取 CVE-2026-0300 はバッファオーバーフロー起因のリモートコード実行（RCE）脆弱性だ。攻撃者は認証なしにroot権限でコードを実行できる。CVSSスコアは「Critical」相当であり、インターネット側に公開されているCaptive Portalが有効なファイアウォールが攻撃対象になる。 Palo Alto Networks の脅威インテリジェンス部門 Unit 42 は攻撃クラスターを CL-STA-1132 と命名して追跡している。同社の報告によれば、攻撃の流れは次のとおりだ： 4月9日 — PAN-OSデバイスへの悪用試行開始（失敗） 約1週間後 — RCE 成功。シェルコードが注入される 侵害直後 — ログ消去工作（クラッシュカーネルメッセージ削除、nginx クラッシュログ削除、コアダンプファイル削除）を即座に実施 ログを素早く消去する動きは、攻撃者がインシデントレスポンスを熟知しており、痕跡を最小限に抑えることを最優先としていることを示している。 使用ツール：EarthWorm と ReverseSocks5 侵害後、攻撃者はオープンソースのネットワークトンネリングツール EarthWorm と ReverseSocks5 を展開した。 EarthWorm：SOCKS v5 サーバーを構築し、制限されたネットワーク上で隠蔽された通信チャネルを確保する ReverseSocks5：ターゲットからコントローラーへのアウトバウンド接続を使ってNATやファイアウォールを回避する EarthWorm はこれまで Volt Typhoon、APT41、CL-STA-0046、UAT-8337 など複数の中国語圏の脅威グループが使用してきた実績がある。今回の攻撃についても同様の国家支援グループとの関連が強く示唆されている。 被害規模：日本を含むアジアが最多 インターネット脅威監視機関 Shadowserver の調査では、インターネット上に公開された PAN-OS VM-Seriesファイアウォールが5,400台以上に上ることが確認されている。 地域 公開台数 アジア 2,466台（最多） 北米 1,998台 アジアが最多というデータは、日本企業にとって無関係な話では済まない。アジア向け分がすべて日本というわけではないが、Palo Alto Networks の国内シェアの高さを考慮すれば、日本国内にも相当数の対象ファイアウォールが存在すると考えるべきだ。 対応状況と推奨される緩和策 パッチは2026年5月13日（水）に初回リリース予定。それまでの間、Palo Alto Networks は次の緩和策を「強く」推奨している： ...

米国司法省は2026年5月、北朝鮮のIT工作員が米国企業にリモート就職するのを支援した「ラップトップ農場」の運営者2名——Matthew Isaac KnootとErick Ntekereze Prince——にそれぞれ禁固18ヶ月の実刑判決を下した。被害を受けた企業は約70社にのぼり、経済的損失と事後対応コストの合計は数百万ドル規模に達している。 「ラップトップ農場」とは何か 「ラップトップ農場（Laptop Farm）」とは、他人名義で受け取った業務用ノートPCを自宅に並べ、北朝鮮のIT工作員が米国在住の正規社員を装ってリモートワークできるよう環境を整える犯罪インフラのことだ。 具体的な手口はシンプルかつ巧妙だ。 企業が採用したと思っている「Andrew M.」などの架空人物名義でノートPCを受け取る そのPCにリモートデスクトップソフトウェアを不正インストールする 北朝鮮側の工作員が海外から当該PCにアクセスし、米国在住社員として業務をこなす 給与は全額、北朝鮮政府の管理するルートを通じて送金される Knootはナッシュビルの自宅でこの農場を2022年7月〜2023年8月の約1年間運営。被害企業が支払った給与は25万ドル超。さらに事後の監査・システム修復コストが50万ドル超発生した。 PrinceはIT企業「Taggcar Inc.」を隠れ蓑に、2020年6月〜2024年8月の4年間にわたって少なくとも3名の北朝鮮工作員を複数の米国企業に潜り込ませた。給与総額は94万3,000ドルを超え、修復コストは100万ドル超に上った。 FBIが警告し続ける「見えない脅威」 FBIは少なくとも2023年から北朝鮮ITワーカーの米国企業侵入について繰り返し警告を出している。推定では、北朝鮮は毎年数千人規模のIT工作員を抱え、盗まれたアイデンティティを使って数百社に就職させているとされる。 今回の2名は今年に入って8人目の有罪確定者だ。昨年7月にはアリゾナ州在住のChristina Marie Chapmanが自宅で309社向けのラップトップ農場を運営した罪で禁固102ヶ月（約8年半）の判決を受けており、司法当局の摘発が本格化していることがわかる。 実務への影響——日本企業のリモート採用リスク これは米国だけの問題ではない。リモートワークが定着した現在、採用・受け入れプロセスに物理的確認が欠如していれば、どの国の企業も同様のリスクにさらされる。 IT部門・情報セキュリティ担当者がすぐ確認すべきポイント： PC配送先の住所確認: 会社支給PCの配送先が本人の居住実態と一致しているか。転送サービスや法人住所への配送は要注意 初回ビデオ通話での本人確認: 採用面接時と業務開始後の顔・背景・声が一致するか定期確認 IPアドレス・接続元の監視: 日本在住のはずの社員が海外IPから常時ログインしていないか リモートデスクトップソフトウェアの管理: MDMで管理されていない第三者製RDPツール（AnyDesk等）のインストールを検知・ブロックする 給与受取口座の実在確認: 口座名義と採用時の本人確認書類の突合 特にフリーランスや業務委託での採用増加に伴い、正社員採用ほど厳密な本人確認が行われないケースが増えている。発注側の管理強化が急務だ。 筆者の見解 この事件を「米国の話」として読み飛ばすのは危険だと思う。 リモートワークの普及は働き方の自由度を大きく広げた一方、採用・就業管理のプロセスに「物理的な確認」がなくなるという構造的な空白を生んだ。北朝鮮のようなステートアクター（国家支援型攻撃者）は、その空白を組織的・継続的に突いている。 日本企業の多くは「海外の話」「大企業の話」と感じるかもしれないが、グローバルな業務委託やオフショア開発が一般化している今、リモート人材の本人確認プロセスがどこまで整備されているかを見直す良い機会だ。 ゼロトラストの文脈でいえば、「ネットワークに繋がっているから社員」という前提はとうに崩れている。接続元・デバイス・アイデンティティの3点を継続的に検証するアーキテクチャを整備することが、このような「内部侵入」への根本的な対処になる。 セキュリティの話は細かくてとっつきにくい部分も多いが、「今動いているから大丈夫」という感覚が一番危ない。この摘発劇が日本国内のリモートワーク管理の見直しを促すきっかけになれば、報道する価値は十分にある。 出典: この記事は Americans sentenced for running ’laptop farms’ for North Korea の内容をもとに、筆者の見解を加えて独自に執筆したものです。