Windows

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はBuild 2026において、Windows Subsystem for Linux（WSL）の次世代バージョン「WSL 3」を発表した。最大の特徴はGPUおよびNPU（Neural Processing Unit）のほぼネイティブなパススルーサポートであり、Linuxコンテナ内からWindowsのNPUを直接呼び出してローカルAI推論を実行できるようになる。 WSL 3が変える開発者体験 これまでのWSL 2では、GPU仮想化（WSLg）によりLinux上でGPUを利用できるようになっていたが、NPUへのアクセスはWindowsネイティブアプリケーション専用だった。多くのAI推論ランタイムやMLフレームワークはLinux環境を前提としており、Windows PCのNPUを活用したい開発者はWindowsネイティブ環境か仮想マシンを使わざるを得ない状況が続いていた。 WSL 3ではこの壁が取り払われる。LinuxコンテナからWindows AI Engine（旧：Windows ML）を直接呼び出すことが可能になり、Copilot+ PCに搭載されたQualcomm SnapdragonやIntel Core Ultraシリーズ、AMDのAI対応NPUが、Linuxアプリケーションからそのまま利用できるようになる。 ローカルAI推論の実用性が大幅アップ この変更が実務で意味するのは、たとえば以下のようなユースケースだ。 LLM推論ランタイムの効率化: llama.cpp や ollama などのOSSツールをWSL上で動作させたまま、Windows側のNPUを活用して推論速度・消費電力を改善できる PythonベースのMLパイプライン: PyTorchやONNX RuntimeがNPUバックエンドを認識できるようになり、既存コードの変更を最小限にAI処理を高速化できる エッジAIの開発・テスト環境: 本番環境がLinuxでも、開発機がWindows Copilot+ PCであれば同等のNPUで動作検証ができる 開発者がLinux環境からWindowsのシリコン性能をフル活用できるという点は、特にAIアプリケーションを開発するエンジニアにとって大きな前進だ。 実務への影響 日本のエンジニア・IT管理者が注目すべきポイントは以下の通りだ。 Copilot+ PCへの投資対効果が高まる: NPUのメリットをLinux開発環境からも享受できるようになるため、開発者向けPCとしてのCopilot+ PCの評価が上がる可能性がある。調達・更新計画に組み込む価値が出てきた AI開発の「環境問題」が解消へ: 「本番はLinux、開発はMac」という構成に対するWindowsの弱点の一つが埋まりつつある。チームの標準環境をWindowsに統一する根拠が増えた WSL 2からの移行コストに注意: WSL 3はアーキテクチャ刷新版であり、既存のWSL 2環境との互換性や移行手順については正式ドキュメントが出次第確認が必要。焦って移行せず、まずプレビュービルドで挙動を確認することを推奨する 企業PCポリシーの更新が必要になる場面も: NPUパススルーにより、ローカルで高度なAI推論が走るようになる。データ分類・AI利用ポリシーを持つ組織では、WSL 3の展開前にセキュリティレビューをすることが望ましい 筆者の見解 WSL 3のNPUパススルー対応は、MicrosoftがWindowsをAI開発プラットフォームとして真剣に位置づけ直している証だと思う。WSLは登場以来、Linuxツールチェーンとの統合を着実に進めてきた数少ない「本当に動く」Microsoftの施策のひとつだ。 開発者がLinux環境を手放さずにWindowsハードウェアの性能を最大限に引き出せるようになるのは、AIの時代における「Windowsの使いどころ」を一段拡げる。特にCopilot+ PCのNPU性能はかなり本格的で、それを活かせる環境が整うなら、開発機としての選択肢として改めて検討する価値がある。 ここ数年、AI分野でMicrosoftのアプリケーション層（Copilotなど）への評価が割れることが多かった分、こういう開発者向けのインフラ強化は「そうそう、これをやってほしかった」と素直に思える。プラットフォームとしての地力は確かにある。その地力を開発者が実感できる形で届けてくれるアップデートが続くことを期待している。 WSL 3の一般提供時期と、各NPUベンダーのドライバー対応状況については引き続き注目していきたい。 出典: この記事は WSL 3 at Build 2026: Near-Native GPU and NPU Passthrough Brings Local AI to Windows の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

オーストラリア政府のサイバーセキュリティ機関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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。