Windows

Linuxカーネルの生みの親であるLinus Torvaldsが、開発者メーリングリストで注目すべき観察を共有した。AIコーディングツールの普及によってカーネルへのパッチ提出量が劇的に増加しており、これを「新たな日常（new normal）」として受け入れる姿勢を示したのだ。あの慎重なTorvaldsが現状追認とも取れる発言をしたという事実は、業界全体のパラダイムシフトを示すシグナルとして受け止めるべきだろう。 AIがLinuxカーネル開発を変えつつある Torvaldsの観察によれば、最近の開発サイクルでパッチサイズが急増している。AIコーディングアシスタントの普及により、個々の開発者が生成できるコード量が飛躍的に拡大したことが主な要因だ。 従来のLinuxカーネル開発では、熟練した開発者が1つのパッチセットに何週間もかけて吟味・調整するのが通常だった。しかし今や、AIツールが補助することでコードを生成するスピード自体が変わった。「1人の開発者が書けるコード量」という前提が、根本から崩れ始めている。 カーネルメンテナーへの新たな課題 パッチ量の増加は一見「活発な開発」の証にも映るが、裏には構造的な課題がある。カーネルメンテナーはレビューする量が増えることになり、品質管理の負荷が高まる。Torvaldsはこの傾向を止めることはできないと判断しながらも、品質基準は決して緩めていない。 Linuxカーネル開発が持つ特有の厳しさは、この状況での防壁として機能している。どんなパッチも複数のメンテナーによるレビューを経なければマージされない。AIが生成したコードだろうと手書きコードだろうと、品質基準は変わらない。「AIで量産したコードをそのまま送りつけても通らない」という構造的な歯止めが、今のところは機能している。 なぜこれが日本のIT現場にとって重要か 日本の企業システムの多くはLinuxを基盤として動いている。クラウドインフラ（Azure・AWSいずれもLinuxベース）から組み込みシステムまで、その影響範囲は広大だ。カーネル開発のペースが上がれば、新機能やセキュリティ修正の供給速度も変わる可能性がある。 また、Linuxカーネルという「最も保守的で厳格なオープンソースコミュニティ」がAIの影響を現実のものとして認めたという事実は、業界全体への強いメッセージでもある。 実務への活用ポイント エンジニア向け: AIツールを使ったコード生成が主流になりつつある今、問われるのは「どれだけコードを書けるか」から「どれだけ良いコードをレビューできるか」へと移行している。AIが書いたコードの品質を見抜く目、すなわちレビュースキルが今後の差別化要因になる。自分の書くコード量を増やすより、レビュー力を磨くことに時間を投資するべきフェーズだ。 IT管理者向け: Linuxカーネルの更新頻度やパッチ量が増加傾向にあるとすれば、パッチ適用プロセスの自動化・効率化を今のうちに整備しておくことが重要だ。RHEL・Ubuntu・SUSEといったディストリビューションがこの変化にどう対応するかにも注目しておきたい。アップストリームの変化速度が上がれば、ディストリビューション側の検証・バックポート体制にも影響が波及する。 筆者の見解 Torvaldsの「AIによるコード増加を新たな日常として受け入れる」という姿勢は、現実を直視した正直な判断だ。そしてこれは、Linuxカーネルだけの話ではない。 AIアシストによって1人の開発者が1日に書けるコード量は、文字通りケタが変わった。問題は「量が増えること」自体ではなく、その量に人間のレビューが追いつくかどうかだ。Linuxカーネルのように「マージ前に必ず人間がレビューする」という構造が守られているうちは品質の歯止めが効く。しかし、そのレビュー文化を持たない組織がAIで量産したコードをそのままデプロイすれば、技術的負債が爆発的に膨らむリスクがある。 重要なのは「AIが書いたか人間が書いたか」ではなく、「コードの責任を誰が持つか」の明確化だ。仕組みを作れる少数の人間が品質の門番として機能し、生産量はAIが担う——その役割分担を意識的に設計できる組織だけが、この変化の恩恵を受けられる。 Linuxカーネルはその設計を数十年前から持っていた。我々の組織はどうだろうか。AIで生産量だけを増やし、品質管理の仕組みを後回しにしていると、あっという間にレビューボトルネックが顕在化する。Torvaldsの発言は、そのことを改めて問いかけているように聞こえる。 出典: この記事は Linus Torvalds declares massive AI-fueled code surges as the new normal for Linux の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11のファイルエクスプローラーに、待ち望まれていた使い勝手の改善が届こうとしている。右クリックメニューへの「更新（Refresh）」「印刷（Print）」ボタンの復活、そしてファイルサイズ表示の刷新だ。現在はWindows 11の実験的ビルド（Build 26300.8376）でテスト中で、近く一般向けにも展開される予定となっている。 何が変わるのか 右クリックに「更新」ボタンが帰ってくる Windows 11ではWinUIで書き直されたモダンコンテキストメニューが導入されたが、その際に「更新」「印刷」をはじめとした従来の右クリックオプションが姿を消した。アドレスバーから更新できるという説明は理屈の上では理解できるものの、ワイドディスプレイで複数ウィンドウを扱いながら作業しているとき、右クリックその場で更新したい場面は誰にでも訪れる。 「レガシーコンテキストメニュー」はShift+右クリックや「その他のオプションを表示」から呼び出せるが、2ステップ余分にかかるのは積み重なると小さくない負担だ。今回の変更でこの手間がなくなる。印刷オプションも同様に、モダンメニューから直接呼び出せるようになる。 ファイルサイズが「人間が読める形式」に Details viewでのファイルサイズ表示がKB固定から改善される。現状では、5KBのファイルも8GBのISOも一律「KB表示」に統一されており、8GBのファイルは「8,388,608 KB」と表示されてしまう。変換に慣れている人なら問題ないが、一般ユーザーや現場の新人メンバーには不親切な仕様だ。これが改善され、ファイルサイズに応じてKB／MB／GBと適切な単位で表示されるようになる。右側の詳細ペインにも同様の改善が適用される点も見逃せない。 アドレスバーとその他の改善 このビルドにはほかにも実用的な改善が含まれている： アドレスバーのパス入力強化：ダブルバックスラッシュや引用符付きパス（"C:\Users"）にも対応。UNCパスや、コマンドラインから貼り付けたパスをそのまま入力できるようになる 名前変更したファイルの確実な反映：リネーム後のファイルが正しく・確実に表示されるよう改善 アドレスバーのドロップダウン：候補選択時に正しく閉じるよう修正 キーボードショートカット・ナビゲーション：コンテキストメニューを含むフライアウト操作がよりスムーズに 実務への影響 ヘルプデスク対応の簡素化：「右クリックで更新できない」という問い合わせは、Windows 10から移行したユーザーから今でも届く。モダンメニューに更新ボタンが追加されることで、この種の混乱が大幅に減るはずだ。展開部門にとっては地味ながら確実なコスト削減につながる。 ファイルサイズの視認性向上：バックアップ確認やストレージ整理など、大量のファイルを扱う作業でGB単位のファイルがGB表示されることの恩恵は大きい。「KB換算して頭の中で変換する」という無駄な認知負荷がなくなる。 UNCパス対応強化：ネットワーク共有フォルダ（\\server\share）を日常的に扱う企業環境で、スクリプトやコマンドからコピーしたパスをそのままアドレスバーに貼り付けられるようになる点は地味に便利だ。特に管理者操作の手順書を整備している現場では、入力ミスのリスク軽減にもなる。 展開時期は「数週間以内」とのこと。Canaryビルドを使っていない場合は、通常のWindows Updateを通じて届く予定だ。 筆者の見解 正直に言えば、「更新ボタンが右クリックにない」というのはWindows 11のUI刷新時から多くのユーザーが指摘してきた問題で、それが解決までに数年かかったのは「もったいない」という気持ちが拭えない。UIを一新するときに使い慣れた操作の一部を削るのは大胆な判断だが、それに見合う代替体験が用意されていなければ、ユーザーは毎日小さなストレスを積み重ねることになる。 とはいえ、こうして着実に使い勝手の改善を積み重ねているのは素直に評価したい。ファイルサイズのKB固定表示のように「なぜそうした？」という設計判断が散見されてきたのは事実だが、Microsoftにはこの種の問題を丁寧に直していく底力がある。今後のFile Explorerがクラウドストレージ連携や検索性能も含めてどう進化するか、引き続き注目していきたい。 Windowsそのものを細かく追いかける意味が以前より薄れてきた時代でも、日々の仕事のベースとなるUIの改善は、地味ながら確実に生産性に影響する。「当たり前を当たり前に直す」改善を粛々と続けることが、長期的なプラットフォームへの信頼につながる。こういう姿勢を、これからも継続してほしい。 出典: この記事は Microsoft brings Refresh & Print back to Windows 11 File Explorer right-click, plus readable file sizes for Details view の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがVisual Studio向けCopilotに「AIサブエージェント（AI Subagents）」機能を近日実装すると発表した。単一のAIが質問に答えるだけの従来モデルから、複数のエージェントが役割を分担しながら協調してタスクを処理する多段階モデルへ——この転換は、長年Windowsプラットフォームで開発をしてきたエンジニアにとって、IDE体験の本質を変えるかもしれない動きだ。 サブエージェントとは何か——単なる「賢いCopilot」との違い AIサブエージェントとは、大きな指示を複数の専門的なエージェントに分解して処理するアーキテクチャだ。たとえば「このクラスをリファクタリングしてテストも書いて」という指示に対し、従来のCopilotは一つのAIが全体を一気に回答しようとしていた。 サブエージェント方式では、コード解析担当のエージェント、リファクタリング実装担当、テスト生成担当が順番に（あるいは並行して）処理を引き継ぐ。複雑なタスクでも精度が落ちにくく、各ステップを確認しながら進められるのが特徴だ。IDEに統合された形で提供されるという点が、Microsoftならではのアプローチといえる。 展開範囲と今後のロードマップ 発表によれば、Visual Studioを皮切りに、Visual Studio CodeおよびJetBrains IDEへの展開も計画されている。特にVS Codeはすでに世界中の開発者が使う主要な開発環境であり、ここにサブエージェント機能が搭載されれば影響は非常に大きい。 JetBrains IDEへの対応は、Microsoft製IDEに縛られない幅広い開発者層をCopilotエコシステムに引き込む戦略とも読める。GitHub Copilotの普及実績を考えると、この展開戦略は理にかなっている。 実務への影響——明日から何が変わるか サブエージェントが実際に使えるようになると、以下のようなシナリオで開発効率が変わってくるだろう。 大規模リファクタリングへの対応 現状のCopilotでは、複数ファイルにわたる変更を一度に指示すると品質が不安定になりがちだった。サブエージェント方式で各ステップを分担すれば、変更の一貫性と精度が向上することが期待できる。 テスト駆動開発（TDD）との相性 「仕様を読んで → テストを書いて → 実装して」というTDDのサイクルをエージェントが自律的に回せるようになれば、テストカバレッジの向上にも貢献するかもしれない。 コードレビューの自動化 差分を解析するエージェントと改善案を提案するエージェントを組み合わせることで、レビュープロセスを一部AIに委ねる運用も現実味を帯びてくる。 ただし注意点がある。エージェントが多段階で自律的に動くということは、意図しない変更の連鎖が起きやすいということでもある。実際に使い始める際は、小さなタスクから試して挙動を把握し、変更内容を都度確認するワークフローを確立してから使い方を広げていくことを勧める。「AIが動いているから大丈夫」という過信は禁物だ。 筆者の見解 この方向性は正しいと思う。補完・提案ツールとしての「現行Copilot」から、複雑なタスクを自律的にこなす「開発パートナー」への進化——これこそ、CopilotがIDEに組み込まれた存在として目指すべき姿のはずだ。 率直に言えば、「近日公開」と「実際に使い物になるもの」の間には、これまでのCopilot関連発表を見ていると距離を感じることがあった。Microsoftにはこの領域で正面から勝負できる体力とブランドがある。だからこそ、「発表通りの機能が、きちんと使える形で届いてほしい」と思う。もったいないことをしてきた局面があった分、今回はそれを挽回するチャンスでもある。 Visual StudioはWindowsプラットフォームで長年使われてきた開発者の相棒だ。そこに本当に機能するAIエージェントが組み込まれれば、日本のエンタープライズ開発現場にも確実に波及する。使えるものを届けてくれることを、心から期待している。 出典: この記事は AI Subagents ‘Coming Soon’ to Visual Studio Copilot の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11のタスクバーとWindowsサーチに、AIエージェントを直接組み込める新機能が登場した。2026年4月17日、リリースプレビューチャンネルのビルド26200.8313で先行実装され、5月の月例セキュリティ更新とともに段階的に展開される予定だ。Microsoftは単にAI機能を追加するだけでなく、開発者が自社エージェントをWindowsのシェルに統合できるインフラを整えつつある。 AIエージェントがタスクバーに宿る 本機能は、AIエージェントをWindowsの中核UIである「タスクバー」と「Windowsサーチ」から直接操作できるようにするもの。最初に対応するのはMicrosoft 365 Researcherで、タスクバーのCopilotアイコンにカーソルを合わせるだけでエージェントの進捗確認や管理が行える。 ユーザー視点では、ドキュメントの要約・構造化レポートの生成・OneDriveやMicrosoft 365に保存したファイルの分析といった複数ステップのタスクを、専用アプリを開かずに起動・監視できるようになる。Windowsサーチでは「@」ショートカットで互換エージェントを呼び出せる「Ask Copilot」体験も加わっている。 技術の核：MCPとWindows.UI.Shell.Tasks API この統合を支える技術として注目すべきはModel Context Protocol（MCP）だ。MCPはAIエージェントがWindowsアプリケーション・システムファイル・クラウドサービスに対して標準化された方法で接続するためのプロトコルで、手動のデータ転送なしに関連コンテキストをエージェントに提供できる。 開発者向けにはWindows.UI.Shell.Tasks APIが公開されており、サードパーティ製のAIエージェントもMicrosoft製エージェントと並んでタスクバーやサーチに表示できる設計になっている。これにより、AIエージェントの統合がWindowsの「一等席」に格上げされた形だ。 なお本機能はデフォルトでは無効。AIツールを使わないユーザーには影響なく、オプトインで利用する設計になっている点も重要だ。 実務への影響 開発者・ISVにとって MCPはすでに各種AIエージェントフレームワークで採用が進んでいるオープンなプロトコルだ。今回のWindows統合により、MCP準拠のエージェントをWindowsのタスクバーに組み込むルートが正式に開かれた。 自社製品にAIエージェント機能を持つISVにとっては、Windows.UI.Shell.Tasks APIへの対応を検討する価値がある。「アプリ内にAI」ではなく「Windowsシェルに常駐するAI」という設計軸が生まれた意味は大きく、既存製品のポジショニング見直しにも影響するかもしれない。 IT管理者にとって タスクマネージャーでAIプロセスのリソース使用量を個別に管理できる点は、エンタープライズ環境での展開を考えると見逃せない。「どのAIエージェントがどれだけCPUやメモリを消費しているか」が可視化されることで、パフォーマンス問題の切り分けが格段に楽になる。 デフォルト無効という設計も、段階的展開を好む企業IT部門には歓迎材料だ。グループポリシーやMicrosoft Intuneによる制御がどこまで効くか、今後の詳細仕様の発表に注目しておきたい。 筆者の見解 「AIを使うためにアプリを開く」から「AIがOSの一部として常駐している」へ——この方向性そのものは正しいと思う。 特筆すべきはMCPという業界横断のオープンプロトコルを採用した点だ。独自プロトコルで囲い込みに走らず、サードパーティが参加しやすい設計を選んだことは、Windowsをエコシステムとして育てる意志の表れと読める。 一方で気になるのは、今回の第一弾がMicrosoft 365 Researcherというこれまたやはり自社製品であることだ。つまり実質的にはMicrosoftファミリーのさらなる深化であり、サードパーティ統合が本当に活性化するかどうかはこれからの話。「API公開」が単なるアナウンスで終わらず、実際のエコシステム形成につながるかどうかが真の問いだ。 Windowsはまだ数十億台のデバイスで動いており、その「タスクバー」を取りにくる意義はどのAIベンダーにとっても無視できない。Microsoftにはそのリアルエステートを存分に活かせる正念場がある。MCPをうまく活用した本物の統合エコシステムに育てていけるか、今後の展開を見守りたい。 出典: この記事は Microsoft adds AI agent support to Windows 11, rolling out in April 2026 - Pureinfotech の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2024年末、ドイツ史上最大規模のサイバー犯罪マーケットプレイス「Crimenetwork」が当局に摘発された。ところがその数日後、新たな管理者が同名の新インフラを立ち上げ復活。しかし今回、法執行機関の対応は以前より格段に速かった。この事案は、ダークウェブ犯罪インフラの「不死性」と、それに対抗する国際連携の進化を同時に示す好例だ。 Crimenetworkとはどんな存在だったか 2012年から運営されていたCrimenetworkは、登録ユーザー10万人を抱えるドイツ最大のオンライン犯罪市場だった。不正アクセスツール、盗まれた認証情報、各種違法物質、フィッシングサービスなど、サイバー犯罪に必要な「素材」がワンストップで揃う闇のマーケットとして機能していた。 2024年12月、フランクフルト検察庁、サイバー犯罪対策中央局（ZIT）、連邦刑事警察局（BKA）の合同作戦によってプラットフォームが押収され、管理者の一人が逮捕。2026年3月には元の運営者に懲役7年10カ月と1000万ユーロ超の没収命令が下された（未確定）。 驚異の「数日リブート」と即時再摘発 問題はその後だ。旧版の摘発から「数日」というあり得ないスピードで、別の人物が新しいインフラを構築し、同じ名称で再出発した。新版は短期間で22,000人のユーザーと100社以上のベンダーを獲得し、少なくとも360万ユーロ（約6億円）の収益を上げたとされる。 今回の再摘発では、欧州逮捕状（European Arrest Warrant）が活用され、スペイン・マヨルカで35歳のドイツ人男性が特殊部隊によって身柄を確保された。押収資産は約19万4,000ユーロ（約3,200万円）。さらに大量のユーザーデータとトランザクション履歴が取得されており、この情報をもとにした連鎖的な捜査が進むとみられる。 なぜこれが重要か——「インフラ摘発」の限界と進化 犯罪マーケットプレイスは、本質的にソフトウェアとデータの組み合わせだ。物理的な拠点を必要としないため、サーバーを変えれば数日で復活できる。AlphaBay、Hansa、Hydraなど、歴代の大型摘発の後にも「後継」が現れてきた歴史がある。 一方で今回注目すべきは、法執行機関側の対応速度と国際連携の精度が明らかに向上している点だ。新版がわずか数カ月で解体されたのは、BKAが旧版から入手したデータと捜査ネットワークを即座に転用できたからだと考えられる。ダークウェブ上でも「前歴情報」は残る。 実務への影響——日本企業のデータは今も取引されている こうした市場の存在は、遠い海外の話ではない。 認証情報の流出確認を習慣化する: 日本企業の社員アカウントやVPN認証情報が、こうした市場で売買されているケースは珍しくない。Have I Been Pwned などのサービスや、セキュリティベンダーが提供するダークウェブモニタリング機能を活用し、自社ドメインの認証情報流出を定期的に確認することが基本的な衛生管理として機能する。 「摘発されれば安全」ではない: Crimenetworkの再起動が示すように、特定のマーケットが消えても代替はすぐ現れる。特定の脅威プラットフォームの消滅に安堵するのではなく、「盗まれた認証情報が流通することを前提とした」多層防御の設計が求められる。 NHI（Non-Human Identity）管理の重要性: サービスアカウント、APIキー、自動化スクリプトの認証情報も取引対象だ。これらは人間のアカウントより見落とされやすく、かつ検知が遅れる。NHIのライフサイクル管理と最小権限原則の徹底は、この種の脅威に対する実効性の高い対策となる。 Just-In-Timeアクセスの導入: 常時有効な特権アカウントは、流出した場合の被害が最大化する。アクセスを必要なときだけ付与し、使用後は自動的に失効させる仕組みが、盗まれた認証情報の悪用を大幅に抑止する。 筆者の見解 今回の事案で印象的なのは、犯罪側の「再起動速度」よりも、当局側が「次の管理者」に対しても即座に動けた点だ。旧版の摘発時に取得したデータと捜査基盤が、新バージョンへの対応をここまで加速させた。法執行機関のサイバー犯罪対応は、インフラ戦争としての性格を強めている。 もっとも、根本的な構造——犯罪サービスへの需要と、匿名インフラの低コスト構築可能性——は変わっていない。個別マーケットの摘発は必要だが、それだけで犯罪エコシステム全体を止めることはできない。 日本の企業セキュリティの観点では、「こういうマーケットが存在し、自社のデータが流通している可能性がある」という現実認識から出発することが大事だ。セキュリティを「禁止と制限」で固めるアプローチは限界があり、流出を前提とした検知・対応の仕組み作りにシフトする時機はとっくに来ている。ダークウェブの犯罪インフラが数日で再起動できるなら、こちらの検知・対応体制も同じ速度で機能しなければ意味がない。 出典: この記事は Police shut down reboot of Crimenetwork marketplace, arrest admin の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google広告の「公式に見えるスポンサー枠」と、AIサービスの「共有チャット機能」という2つの信頼されたインフラを組み合わせた、新たなマルバタイジングキャンペーンが確認された。ターゲットはmacOSユーザー。「正規URLが表示されていれば安全」という直感がもはや機能しない現実を、あらためて突きつける事例だ。 攻撃の仕組み：2段階の「信頼の借用」 今回の攻撃は、セキュリティエンジニアのBerk Albayrak氏（Trendyol Group）が発見し、BleepingComputerが追跡・検証した。構造はシンプルだが、その巧妙さは際立っている。 第1段階：Google広告で入口を偽装する 「Claude mac download」などのキーワードを検索すると、スポンサー広告として正規のAIサービスドメインが表示される。しかしクリックすると、攻撃者が用意した共有チャットページへ誘導される。表示URLと遷移先が異なるという、マルバタイジングの古典的な手口だ。 第2段階：本物のプラットフォーム上に罠を仕掛ける 誘導先がフィッシングサイトではなく、正規のAIサービス上の「共有チャット」ページという点が今回の核心だ。攻撃者は「公式インストールガイド」を装ったチャットを作成・公開し、ユーザーにTerminalを開かせて悪意あるコマンドを貼り付けさせる。URLバーには本物のドメインが表示されているため、ブラウザの警告もユーザーの目視確認も機能しない。 マルウェアの動作：洗練された標的選別 実行されたシェルスクリプトは、単純な感染ツールではなく、かなり作り込まれた設計を持つ。 CIS地域の除外: キーボードロケールを確認し、ロシア語・CIS地域設定の場合は即座に終了（cis_blocked ステータスを静かに送信） 被害者プロファイリング: 外部IPアドレス、ホスト名、OSバージョン、キーボードロケールを収集して攻撃者サーバーへ送信 ポリモーフィック配信: リクエストごとに異なる難読化ペイロードを返し、ハッシュベースの検知を無効化 メモリ実行: スクリプトはメモリ上で動作し、ディスク痕跡を最小化 osascript 利用: macOS標準のスクリプトエンジンを経由してリモートコード実行を実現 最終的な目的は MacSync インフォスティーラー の実行であり、ブラウザの認証情報・Cookie・macOSキーチェーンの内容が外部へ持ち出される。 実務への影響 IT管理者が取るべき対策 企業内でMacを使う社員が「業務ツールをGoogle検索でダウンロードする」という行動パターンは日常的だ。今回の攻撃は公式ドメインの表示と正規プラットフォームの信頼を二重に利用しており、ユーザー教育だけでは限界がある。以下を組み合わせた多層防御が現実解だ。 MDMによるエンドポイント管理: 管理外アプリのインストールを制限し、Terminalの使用ポリシーを整備する GateKeeper・Notarizationの確認: macOS標準のセキュリティポリシーが正しく機能しているか定期確認を DNSフィルタリング: 既知の不審ドメインへの通信をネットワーク層でブロック EDRの振る舞い検知: シグネチャベースでは検知できないポリモーフィック型には、振る舞い検知が有効 エンジニアが持つべき習慣 「ドキュメントに書いてあるコマンドをTerminalに貼り付ける」という行為そのものが攻撃ベクターになりえる時代だ。特に以下のパターンは立ち止まって確認したい。 curl | bash 形式のワンライナー Base64エンコードされたコマンド 見慣れないドメインへのアクセスを含むスクリプト 筆者の見解 この攻撃の完成度には正直、舌を巻く。自前でフィッシングサイトを用意するのではなく、信頼されたプラットフォームの正規機能を踏み台にするという発想は、現代のゼロトラスト的思考と皮肉にも呼応している——悪い意味で。 「URLが本物ならば安全」という直感は今やほとんど機能しない。ネットワーク層やURL評価だけでなく、コマンドの内容そのものを検証する層が必要な時代に入っている。ゼロトラストの本質は「何も信頼しない」ではなく「すべてを継続的に検証する」ことだが、今回の事例はその原則をエンドユーザーの操作レベルにまで適用しなければならないことを示している。 macOSは「Windowsより安全」というイメージが根強いが、インフォスティーラーをはじめとするMac向けマルウェアの洗練度は近年急速に上がっている。日本のIT現場でもMacの業務利用が増えている中、「Macだから大丈夫」という油断は禁物だ。 AIツールが急速に普及し、「AIサービスのインストール方法を検索する」という行動パターン自体が攻撃者に狙われるようになった。新しいツールが登場するたびに、攻撃者もその普及曲線に乗って仕掛けてくる。インフラ面の対策を進めながら、地道にユーザー啓発も続けていく——それが現時点での現実的な答えだ。「今動いているから大丈夫」が通用しないのは、セキュリティの世界では昔から変わらない真実である。 出典: この記事は Hackers abuse Google ads, Claude.ai chats to push Mac malware の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Copilot+ PCという規格が登場して以来、「本当にAI処理性能が変わるのか」と疑問を持ってきたエンジニアは多いはずだ。GEEKOMが2026年版としてアップデートしたミニPC「A9 Max 2026 Edition」は、そんな懐疑派をも振り向かせる可能性を秘めた製品だ。86 TOPS（毎秒兆回演算）というNPU性能を、ペットボトルほどのサイズに詰め込んだ。 Copilot+ PCとは何か——40 TOPSの壁を大きく超えた Microsoftが定めたCopilot+ PC認定の最低要件はNPU性能40 TOPSだ。GEEKOM A9 Max 2026 Editionはその倍以上となる86 TOPSを達成している。搭載するのはAMDのRyzen AIプロセッサーで、CPUとGPU、そして専用NPUが統合されたSoC（System on Chip）構成だ。 NPUがなぜ重要か。従来のAI処理はCPUかGPUに頼っていたが、専用回路であるNPUは電力効率が桁違いによい。バッテリー駆動のノートPCでAI機能を常時使っても熱暴走しないのはNPUの恩恵だ。ミニPCの場合は熱設計の余裕が大きいとはいえ、専用NPUによる処理オフロードはファン回転数の抑制にも寄与する。 Red Dot受賞の「デザイン」——機能美か、それとも飾りか 本機はRed Dot Design Award 2026を受賞している。ミニPCにデザイン賞が与えられることは珍しくないが、実際のところ業務用途では「ディスプレイの裏にマウントして見えなくなる」ケースが大半だ。ただ、Red Dot受賞が示すのは見た目の美しさだけではない。放熱設計・ポート配置・組み立て精度といった工業設計全体の評価でもある。この点は実用性に直結する。 ポート構成は現代の業務要件を満たす水準で、USB4対応のType-Cポートが含まれているため、Thunderbolt対応の外部ディスプレイや高速ストレージとの接続も問題ない。 実務での活用ポイント ① 小規模拠点・工場・受付端末としての採用 ミニPCの最大の強みはTCO（総所有コスト）の低さではなく、設置自由度にある。スペースの限られた工場の制御盤近くや、ホテルのフロントカウンター下、会議室のディスプレイ背面といった場所に収まる。Copilot+ PC要件を満たしているため、Windows 11の「Recall」「Cocreator」といったAI機能を将来的にフルで使える下地がある。 ② 開発・検証用マシンとしての価値 ローカルLLM（小規模言語モデル）の推論をNPUにオフロードして試験する用途に適している。86 TOPSあれば、Microsoft Phi-4のような比較的軽量なモデルをそこそこのスピードで動かせる。クラウドAPIのコスト検証の前段階として、ローカルで動作確認する開発フローとの相性がよい。 ③ IT管理者視点：展開・管理の標準化 WindowsのAutopilot展開と組み合わせれば、初期セットアップをほぼゼロタッチで完結できる。同一型番で統一すればドライバー管理が簡単になる。中小企業のPC調達でCopilot+ PC認定済みの選択肢が増えることは、将来のAI機能導入に向けたハードウェア基盤整備として評価できる。 筆者の見解 Copilot+ PCという規格そのものは正しい方向だと思っている。「AI機能のためにハードウェア要件を明確に定義する」アプローチは、ユーザーが「どれを買えばいいか分からない」問題を解消する手立てになる。かつてIntel「Evo」の認定プログラムが薄型軽量ノートの品質底上げに貢献したのと同じ役割を、Copilot+はAI PCで担おうとしている。 ただし率直に言えば、現時点でCopilot+ PCの「AI機能」がエンドユーザーの日常業務を劇的に変えている場面には、まだほとんど出会えていない。Recallは段階的な展開が続いており、多くのユーザーには「NPUが速い」と言われてもピンとこないのが実情だ。 GEEKOM A9 Max 2026 Editionの86 TOPSは、その意味でスペックシート上の数字として終わらせてしまうにはもったいない。Microsoftが本来やろうとしていた「ローカルAI処理で常時稼働するパーソナルアシスタント」が現実になったとき、このクラスのハードウェアが真価を発揮する。 ミニPCという形態は、日本の「スペースファースト」な職場環境に特に向いている。物理的に小さいことへの評価が他国より高い市場で、Copilot+ 認定のミニPCが選択肢として増えてきたこと自体は歓迎したい。問題はハードウェアではなく、そのスペックを活かすソフトウェアとサービスが追いついてくるかだ。そこに期待しながら、引き続き注目していきたい。 出典: この記事は GEEKOM A9 Max 2026 Edition review: a tiny but powerful AI Mini PC with 86 TOPS の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoft Edgeがエンタープライズユーザー向けにパスキー（Passkey）のクロスデバイス同期機能を提供開始する。個人向けのパスワードレス認証は以前から整備が進んでいたが、企業環境における「複数デバイス対応」という壁がようやく崩れる。フィッシング耐性が高く、利便性も損なわない次世代認証が、いよいよ職場レベルで普及フェーズに入ろうとしている。 パスキーとは何か、なぜ今重要か パスキーはFIDO2/WebAuthn規格に基づく認証方式で、公開鍵暗号を使ってパスワードを完全に置き換える。ユーザーはPINや生体認証（指紋・顔認証）でデバイスをアンロックするだけでログインが完了し、パスワードそのものをサーバーに送ることはない。 最大の特徴はフィッシング耐性だ。パスキーは登録されたドメインに厳密に紐付いており、偽サイトには一切反応しない。「それっぽいURLに騙されてパスワードを入力してしまった」という攻撃シナリオがそもそも成立しなくなる。これは理論上の話ではなく、設計レベルで攻撃ベクターを潰しているという意味で根本的な解決策だ。 Enterprise向けクロスデバイス同期の何が変わるのか 個人ユーザー向けにはすでにパスキー同期の仕組みが存在していた。問題は企業環境特有の複雑さだ。 複数のPCを使い回すシーン（共有端末、フロア変更、出張など） 新デバイスへの移行時に毎回パスキーを再登録する手間 IT管理者による一元的なポリシー適用の難しさ これらが障壁となり、企業レベルのパスワードレス移行は思うように進んでこなかった。EdgeのEnterprise向けパスキー同期はこのギャップを埋める。MicrosoftアカウントまたはEntra ID（旧Azure AD）に紐付けた形でパスキーを同期させることで、社員がデバイスを変えても再登録なしでシームレスにログインできるようになる。 実務への影響——IT管理者・エンジニアへのヒント IT管理者へ： IntuneやGroup Policy経由でパスキー使用を強制するポリシー設計が現実的になる段階に来ている パスワードリセット対応のヘルプデスクコストが大幅に削減できる可能性がある MFAとの組み合わせを段階的移行計画として整理しておくとスムーズ エンジニアへ： 社内Webアプリ側もWebAuthn対応が必要。未対応のレガシーシステムのリストアップを今から始めるべき Entra IDのパスワードレス認証ポリシーと組み合わせることで効果が倍増する Edgeを標準ブラウザとして管理している環境なら、追加コストなしで恩恵を受けられる 筆者の見解 この機能は正しい方向への投資だと評価している。ゼロトラストの文脈で言えば、「デバイスを信頼するのではなく、アイデンティティを信頼する」という原則とパスキーは完璧に整合している。VPNで社内ネットワークに繋いでいれば安全、という旧来のセキュリティモデルはもう限界を超えている。パスワードという人間側の弱点を「設計として排除する」アプローチは理にかなっている。 「禁止ではなく、安全に使える仕組みを」という観点でも、パスキーは優れた答えだ。複雑なパスワードポリシーを従業員に強制するより、そもそもパスワードを使わせない設計の方が、セキュリティと利便性を同時に高められる。IT部門が「禁止のガードレール」を増やすのではなく、「便利で安全な公式の道」を整備する発想と一致している。 MicrosoftがEntra IDとEdgeのエコシステムを一体で強化しているのは評価できる——あとは、その強さをユーザーが実感できる形で届けきれるかどうかだ。パスワードレス移行は技術的には準備が整ってきた。残るボトルネックは、組織側の移行計画と現場への浸透だろう。今がその計画を本気で立てる時期だと思う。 出典: この記事は Microsoft Edge is finally bringing passkey syncing to enterprise users の内容をもとに、筆者の見解を加えて独自に執筆したものです。

パスワードの終わりが、静かに始まっている Microsoftが「World Password Day（世界パスワードデー）」に合わせて、パスワードレスサインインとパスキー（Passkey）の採用を強力に推し進めている。「パスワードはもう十分ではない」という同社のメッセージは、単なるマーケティングではなく、現実の脅威状況を直視した宣言だ。フィッシング、クレデンシャルスタッフィング、ブルートフォース——これらの攻撃の大部分がパスワードを起点としている。そのパスワードをゲームから外すことが、認証セキュリティの根本的な改善につながる。 パスキーとは何か——仕組みをざっくり理解する パスキーはFIDO2/WebAuthn標準に基づく認証技術で、ざっくり言えば「公開鍵暗号を使ったパスワード不要のログイン」だ。 ユーザーがパスキーを登録すると、デバイス側に秘密鍵、サービス側に公開鍵が保存される。ログイン時は、デバイスの生体認証（顔・指紋）やPINで秘密鍵を使った署名を生成し、サービス側がそれを公開鍵で検証する。この仕組みには二つの大きなメリットがある。 フィッシング耐性: 秘密鍵はデバイスの外に出ないため、偽サイトに誘導されても認証情報を盗まれない。 サーバー漏洩リスクの排除: サービス側に保存されるのは公開鍵のみ。仮にデータベースが漏洩しても、攻撃者は何もできない。 MicrosoftはすでにMicrosoftアカウントへのパスキーサポートを実装しており、今回の発表はその普及加速と、エコシステム全体でのパスワードレス推進を意図したものだ。 Microsoftが今これを推す背景 World Password Dayは毎年5月の最初の木曜日に設定されているが、ここ数年で各社のスタンスが「パスワードを強化しよう」から「パスワードをなくそう」へと明らかにシフトしている。 Apple、Google、Microsoftの三社がFIDOアライアンスを通じてパスキーの相互運用性を推進してきた結果、主要なOS・ブラウザでのサポートが揃いつつある。iCloud Keychain、Google パスワードマネージャー、Windows Helloいずれもパスキーを扱える環境が整っている。 インフラが揃ったいま、Microsoftが「普及のアクセル」を踏むタイミングとして今年のWorld Password Dayを選んだのは、ある意味必然的な流れだ。 日本企業・IT管理者が今すぐ確認すべきこと パスキー推進の波は、日本のエンタープライズ環境にも確実に押し寄せてくる。特に以下の点を早急に確認しておきたい。 Entra ID（Azure AD）のパスワードレスポリシー確認 Microsoft Entra IDはFIDO2セキュリティキーやWindows Helloによるパスワードレス認証をすでにサポートしている。認証方式ポリシーでパスキー（FIDO2）が有効になっているか確認し、パイロット展開を検討する価値がある。 条件付きアクセスとの組み合わせ パスキー単体でなく、条件付きアクセスポリシーと組み合わせることで「デバイス準拠 × フィッシング耐性のある認証」という二重の保証が得られる。ゼロトラストアーキテクチャの観点からも、これが現時点でのベストプラクティスだ。 ユーザー教育の準備 技術的な移行より、ユーザーへの説明が実は一番のハードル。「指紋やPINでログインできる」という体験の良さを先に伝えることで、抵抗感を大幅に下げられる。 レガシーアプリのプロトコル対応確認 Basic認証やNTLM認証に依存した古いアプリがある場合、パスワードレス移行の障害になる。棚卸しを先に済ませておくことが重要だ。 筆者の見解 セキュリティの話は得意分野ではないが、このトピックは別だ——パスキーはゼロトラストの文脈で語るべき、構造的に正しいアプローチだと思う。 VPNで境界を守るという発想がすでに時代遅れであるように、「強いパスワード＋MFA」で終わりという発想もそろそろ限界に来ている。パスキーはフィッシング耐性という点で、従来のMFAより一段上の保証を与えてくれる。これは「より複雑なパスワードルール」ではなく、ゲームのルールそのものを変える話だ。 Microsoftがこの方向で本気を出しているのは、素直に評価したい。Entra IDのパスワードレス機能は実際に使えるレベルに仕上がっており、エンタープライズ向けの展開フローも整備されてきている。「やる力はある」ということは証明されつつある。 問題は普及スピードだ。日本の大企業の現場では、FIDO2対応のセキュリティキー購入の稟議、レガシーシステムの改修、ヘルプデスクへの問い合わせ増加への対応——そういったコストが積み重なって「まだパスワードでいい」という判断が続きやすい。 だが、これは「いつかやる」ではなく「どこまで先送りできるか」の問いに変わりつつある。フィッシング攻撃が年々巧妙化し、AIを使った標的型攻撃が当たり前になる時代に、パスワードを守り続けることのコストは静かに上昇し続けている。 移行の第一歩として、まず自社のMicrosoftアカウントと個人のスマートフォンでパスキーを試してみることをお勧めする。技術を自分で体験してから導入を検討する、それが一番の近道だ。 出典: この記事は Microsoft says passwords are no longer enough as it pushes passkeys の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windowsエンジニアなら一度は使ったことがあるはずの「Sysinternals」が、大規模なアップデートを受けた。新しいトラブルシューティング機能の追加、操作性の改善、そしてLinuxサポートの拡充が一気に実施された。地味なアップデートに聞こえるかもしれないが、日々の現場診断に関わる話として、しっかり押さえておきたい内容だ。 Sysinternalsとは何者か Sysinternalsは、Mark RussinovichとBryce Cogswell両氏が1990年代に開発した、Windowsの内部動作を可視化するためのユーティリティ群だ。Microsoftが2006年に買収して以降も、実質的にMark Russinovich（現Microsoftテクニカルフェロー）が継続的に保守している。Process Explorer、Process Monitor（Procmon）、Autoruns、TCPView、Sysmonなど30本以上のツールで構成されており、Windowsプラットフォームのトラブルシューティングや、セキュリティフォレンジックの現場で長年使われ続けている定番中の定番だ。 今回の主な更新内容 新しいトラブルシューティング機能 各ツールに、これまでの診断作業でよくあった「もう一歩踏み込みたい」という要望に応える形で機能が追加された。プロセスとリソースの相関分析、イベントのフィルタリング精度向上など、現場での調査効率を直接底上げする改善が中心だ。 Linux対応の本格化 特筆すべきはLinuxサポートの拡充だ。ProcmonやProcDumpのLinux版はすでに存在していたが、今回の更新でその対応範囲と精度がさらに向上した。Windowsだけを監視すれば良かった時代はとうに終わり、Azure上のLinux VM、WSL2環境、コンテナなどが混在するハイブリッド構成が当たり前になっている今、同じツールセットとメンタルモデルでLinuxも診断できる意義は大きい。 操作性の改善 UIの使い勝手も手が入った。大量のイベントが流れる現場で、いかにノイズを減らして本質的な情報を掴むかという視点での改善で、長時間の調査セッションでの疲労軽減に直結する。 実務への影響：日本のエンジニアが知っておくべきこと Sysmonの活用が改めて重要に Sysinternalsの中でセキュリティ用途に特化したSysmon（System Monitor）は、エンドポイントの詳細なイベントログをWindowsイベントログに記録する。SIEMやMicrosoft Sentinelと組み合わせることで、ゼロトラスト環境における振る舞い検知の精度が格段に上がる。今回の更新でSysmonもブラッシュアップされているなら、導入済み環境でのバージョン更新は早めに検討したい。 Linux診断をSysinternalsで統一できるメリット WindowsエンジニアがLinuxのトラブル対応を求められるケースは増えている。Linuxネイティブのstraceやlsofを覚え直すのは現実的ではない場面で、Procmon for Linuxのような使い慣れたインターフェースで診断できるのは実務的なメリットだ。 Autorunsとセキュリティ運用 Autorunsはマルウェアの永続化ポイントを可視化する用途でも使われる。インシデント対応の初動確認ツールとして組み込んでいるセキュリティチームも多い。更新版では疑わしいエントリの特定精度が上がっている可能性があり、インシデントレスポンス手順書に組み込んでいる場合は動作確認を行っておくと良い。 ライセンスは無料、でも管理は必要 Sysinternalsツールは無料で使えるが、組織として利用する際は使用許諾条件の確認と、バージョン管理の仕組みを整えておくことが望ましい。更新のタイミングで全端末への展開が揃っていないと、診断結果の比較に支障が出る。 筆者の見解 Sysinternalsは、Microsoftが持つ「職人的な技術資産」の代表格だと思っている。華やかなAIデモや大型サービス発表とは全く異なるポジションだが、実際の現場で使い続けられているツールの重みは別格だ。Mark Russinovichというエンジニアが、MicrosoftフェローになってもなおSysinternalsを磨き続けているのは、正直なところ頭が下がる。 Linuxサポートの拡充という方向性は正しい。クラウド時代のインフラはWindowsだけでは到底完結しない。ここでWindowsツールを「Windows専用」のままにしておかず、Linux環境にも展開してきたことは、エンタープライズの現実に向き合った判断だ。この姿勢は素直に評価したい。 ただ、正直に言うと「もっとできるはず」という気持ちもある。ハイブリッド環境の診断ツールとして、Windows・Linux・コンテナを統一的に可視化するプラットフォームへと発展させる余地はまだ十分にある。Sysinternalsには、そこまで届くポテンシャルがあると思っているからこそ、次の一手に期待している。 Windowsプラットフォームへの依存が薄れつつある今だからこそ、こういった地に足のついたツール群を丁寧に育て続けることには意味がある。使い続けてきたエンジニアとして、この更新は素直に歓迎したい。 出典: この記事は Sysinternals tools receive major updates の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows ドライバー開発の現場に、待望のアップデートが届いた。Microsoft が Windows Driver Kit（WDK）の最新リリースで、Visual Studio 2026 の本番環境向け正式サポートを宣言した。地味に見えて、ドライバー開発者にとっては非常に重要なニュースだ。 WDK と Visual Studio 2026 の正式対応とは Windows Driver Kit（WDK）は、Windows デバイスドライバーを開発するために必要な開発キットだ。ハードウェアベンダーやドライバー開発者は、このWDKとVisual Studioを組み合わせて使うことが基本となる。 これまでVisual Studio 2026はリリースから時間が浅く、WDKとの組み合わせは試験的サポートやプレビュー段階にとどまっていた。今回の更新でようやく本番環境での使用が公式に認められたことになる。 今回のアップデートの主なポイントは以下の通りだ。 Visual Studio 2026 の本番サポート: 正式なプロダクション環境でのドライバー開発が可能に ワークフロー安定性の向上: ビルドプロセスやデバッグ環境の信頼性が改善 最新開発環境への追従: VS 2026 の新機能を活用したドライバー開発が正式対応 実務への影響 ハードウェアベンダーへの影響 日本国内でも多くのプリンターメーカー、産業機器メーカー、周辺機器ベンダーが Windows ドライバーの開発・保守を行っている。これまでVisual Studio 2026への移行を控えていた開発チームも、今回の正式サポート宣言を受けて移行計画を立てやすくなった。 注意点として、WDKはVisual Studioのバージョンと密接に結びついているため、開発環境の一括アップグレードを検討する際は WDK のバージョンとの整合性を必ず確認してほしい。バージョンの食い違いはビルドエラーや予期しない動作につながる。 CI/CD パイプラインへの組み込み ドライバー開発においても CI/CD パイプラインは一般化しつつある。今回のワークフロー安定性の改善は、ビルドサーバー環境での自動ビルド・テストをより確実に行えることを意味する。GitHub Actions や Azure Pipelines でドライバービルドを自動化しているチームは、最新WDKとVS 2026の組み合わせへの移行を具体的に検討する価値がある。 旧バージョンからの移行タイミング Visual Studio 2022 で長らく安定した環境を維持してきたチームも多いだろう。今回の正式サポートは移行の「号砲」となるが、急ぐ必要はない。ドライバー開発は品質と安定性が命であり、移行は本番デプロイの前に十分な検証期間を設けることを強く推奨する。 筆者の見解 正直に言えば、WDKのアップデートは「地味なニュース」に見える。派手なAI機能の発表とは無縁の、職人的な開発ツールの話だ。 しかし筆者はこういったアップデートこそ、Microsoftのプラットフォームとしての強さの源泉だと考えている。Windows エコシステムが30年以上にわたって広大なハードウェアとの互換性を維持してこられたのは、こうした地道な開発者サポートの積み重ねがあったからだ。 ドライバー開発のような低レイヤーの世界は、一度壊れると全体に影響が波及する。だからこそMicrosoftは慎重にサポートサイクルを管理し、「本番環境への正式対応」という言葉に重みを持たせている。この姿勢は変わらず評価したい。 最近のMicrosoftを見ていると派手な発表が多い一方で、こうした地に足のついた開発者サポートも変わらず続けられている。エコシステムを長期的に健全に保つ上で、こういった堅実な取り組みは非常に重要だ。ドライバー開発者の皆さんは今回のリリースノートをしっかり確認し、計画的な移行を進めてほしい。 出典: この記事は Microsoft announces official support for Visual Studio 2026 with latest WDK release の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftが2026年5月に展開を予定しているOutlook（新バージョン）およびOutlook Classicの新機能群が明らかになった。今回の更新では、新旧Outlook間の移行時に長らく課題となっていたカレンダー機能の互換性問題が大幅に改善されるほか、チームのカレンダーをナビゲーションペインで一覧できる機能など、日常業務の効率化に直結するアップデートが揃っている。 6つの新機能を詳しく見る 1. オートマップされたカレンダーのサポート 新OutlookにおけるオートマップカレンダーのサポートはMicrosoft 365ロードマップに2024年から掲載されていたが、複数回の延期を経て今月ようやく一般展開が始まる。 Exchange環境では管理者が共有カレンダーやリソースカレンダーを他のメールボックスに自動追加（オートマップ）する設定が広く使われている。Outlook Classicではこれが当然のように機能していたが、新Outlookへ切り替えた途端にそれらのカレンダーが消えてしまうという問題が報告されており、移行を躊躇する大きな理由のひとつになっていた。この問題が解消されることで、組織内の移行促進に弾みがつく可能性がある。 2. ナビゲーションペインへのチームメイトカレンダー自動表示 新Outlookの左ナビゲーションペインに、同僚・部下・上司のカレンダーが自動的に表示されるようになる。同一組織内のアカウントであればMicrosoft以外のアカウントでも機能するとされており、「メールを書きながら相手の空き時間を即座に確認する」という実務フローがよりスムーズになる。まずWebクライアントから展開開始となる。 3. カレンダーグループ・イベントの複数選択 Outlook Classicでは当然使えていたカレンダーグループの複数選択機能が、新Outlookでも利用可能になる。カレンダーの一括選択・解除に加え、カレンダー上での複数イベント選択（開く・コピー＆ペースト・削除・カテゴリ設定）も対応する。「新Outlookに切り替えたら使えていた機能が消えた」というフラストレーションを抱えているユーザーには待望の対応だ。 4. 非連続日付の選択 カレンダーのミニ月表示でShiftキークリックやCtrlキークリックによる非連続日付選択が可能になる。特定の複数日をまとめて指定してアクションを取る操作が直感的に行えるようになる。こちらはWebクライアントへの展開となる。 5. Outlook ClassicへのCopilotインサイト展開 新Outlookではすでに利用可能だった「メール本文内のテキストを選択してCopilotに質問する」機能が、Outlook Classicにも展開される。まだ新Outlookへの移行が完了していない環境でも、AI支援機能を段階的に体験できるようになる。 6. メールのソート機能強化・カレンダーイベント表示形式の追加 メール検索時に活用できるソート機能の強化と、カレンダーイベントの新しい表示フォーマットの追加も予定されている。詳細な仕様は月内に公開される見込みだ。 実務への影響：日本のIT現場で押さえておくべきこと 移行評価を再開するタイミングかもしれない 日本企業のExchange環境では、会議室やプロジェクトチームの共有カレンダーをオートマップで配布している組織は多い。これが新Outlookで機能しないことはヘルプデスクへの問い合わせ増加や、移行計画の先送りを招いてきた。今月のアップデートでこれが解消されるなら、新Outlookへの移行評価を再開する現実的な理由が生まれる。 チームカレンダー機能とプライバシー設定の整備 ナビゲーションペインへのチームメイトカレンダー自動表示は、マネージャーや人事担当者が特に恩恵を受けるだろう。一方で、自動表示されることで意図しない情報が見えてしまうリスクもある。カレンダーの共有設定（空き時間のみ公開か詳細まで公開かのレベル）を組織として整備しておくことが前提条件となる。展開前に設定ポリシーを確認しておきたい。 ClassicとNewの共存期間を意識した計画を CopilotインサイトをClassicへ追加展開する動きは、まだ移行していないユーザーへの配慮とも取れる。ただし「ClassicでもAI機能が使えるなら移行しなくていい」という誤解を生まないよう、組織としての移行ロードマップと期限を明確にしておくことが重要だ。新Outlookの機能が今後も充実していく以上、Classicの延命は限界がある。 筆者の見解 今回のアップデートは、派手さはないが実用性の高い内容が揃っている、というのが率直な印象だ。 オートマップカレンダーの問題は2024年にロードマップへ掲載されてから2年近く放置されてきた。この機能の不在が新Outlook移行の足かせになっていた現場は少なくないはずで、「なぜもっと早く対応できなかったのか」という思いは正直ある。とはいえ、ようやく解消されることは素直に歓迎したい。 Microsoftの強みは、OutlookとTeams、Exchange、Entra IDを含むエコシステム全体の統合にある。チームメイトカレンダーの自動表示は、その統合の恩恵をより自然な形でユーザーに届けようとする方向性の表れだと思う。単体機能の競争ではなく、「チームで使うから価値が出る」という体験を積み重ねていく姿勢は、Microsoftが持つべき本来の強みそのものだ。 Copilotインサイトについては、機能としての有用性は認める。ただし、AIの支援機能は使いどころと使い方が合えばこそ価値が出る。「展開したから使われる」ではなく、組織として「何のためにこの機能を活用するか」を考えてから導入することを勧めたい。 今月のアップデートを機に新Outlookへの移行評価を再開する価値は十分にある。ただし「できるから切り替える」ではなく、「組織の使い方に合っているかを検証してから切り替える」という順番を崩さないようにしたい。Outlookは業務の中心にあるツールだけに、慎重さと前向きさの両方が求められる判断だ。 出典: この記事は Microsoft confirms new features coming to Outlook and Outlook Classic in May 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft Teamsの会議録画をめぐる混乱が、ずいぶん長い間続いている。「録画を有効にしたはずなのに参加者が録画できない」「管理センターの設定を変えたのになぜ反映されない？」——こうした問い合わせは、IT管理者の間で今も後を絶たない。Microsoftはこのほど、この複雑なポリシー構造を改めて公式に説明し、あわせてTeams Premiumが提供する録画関連機能との違いを整理した。 なぜこれほど混乱するのか：「2層」の設計 Teamsの録画ポリシーが混乱を招く最大の理由は、「誰が録画できるか」という1つの問いに対して、少なくとも2つの独立した設定が絡み合っているからだ。 第1層：管理者ポリシー（Teams管理センター） テナント全体やユーザーグループ単位で録画の可否を制御する。AllowCloudRecording が True になっていなければ、そもそも誰も録画できない。これは多くの管理者が把握しているレイヤーだ。 第2層：会議オーガナイザーによる設定 管理者が録画を許可していても、会議のオーガナイザーは「誰が録画できるか」をさらに絞り込める。主な設定値は2種類だ： オーガナイザーと共同オーガナイザーのみ（デフォルト値） 全員（参加者全員が録画可能） ここが多くの管理者が見落とすポイントだ。管理者が「録画を全社に許可した」と思っていても、会議レベルでオーガナイザーのみに絞られていれば参加者は録画ボタンすら表示されない。 Teams Premiumが加わるとさらに複雑に Teams Premiumでは「インテリジェント リキャップ（Intelligent Recap）」という機能が利用できる。これは通常の録画とは完全に別の機能であり、AIによるチャプター自動生成・話者識別・アクションアイテム抽出などを含む。 管理者が見落としやすいのは、標準録画とIntelligent Recapで適用されるポリシーが異なる可能性があるという点だ。録画は許可しているがTeams Premiumライセンスを持たないユーザーにはIntelligent Recapが表示されず、「自分だけ機能が違う」という混乱を生む。今回のMicrosoftの説明は、このTeams Premiumとの境界線を改めて明確化したものでもある。 実務への影響：管理者が今すぐ確認すべきこと この問題は日本のTeams管理者にとっても他人事ではない。特に以下のシナリオで誤解が生じやすい： 「全社員が録画できる」はずなのにできない：管理者ポリシーと会議ポリシーの両方を確認する。Teams管理センターの「会議ポリシー」→「録音とトランスクリプト」セクションで WhoCanRecord の値を確認せよ Teams Premiumの一部機能しか表示されない：ライセンスのアサイン状況と、管理センターでの機能ポリシーの紐付けを確認する 外部参加者の録画可否：外部（フェデレーション）ユーザーの録画権限は別途ポリシーで制御される。デフォルトでは無効なことが多い 実務的なアドバイスとして、会議ポリシーの既定値を変更する前に、現在の設定が何を意図して設定されたものかを確認することを強く勧める。誰かが過去に「問題を回避するため」に設定を変えていることはよくある話だ。 筆者の見解 正直に言えば、Teamsの録画ポリシーはもう少し整理できたはずだ、という気持ちはある。管理者ポリシーと会議オーガナイザーポリシーが独立していること自体は理にかなっている——細かい制御ができるというのは企業向け製品として正しい設計だ。しかしUIやドキュメントがその複雑さに追いついていなかった。 「録画を有効にした＝みんな録画できる」という誤解を管理者が何年も持ち続けてきたということは、設定画面の説明が不親切だったということでもある。複雑さを売りにするのではなく、複雑さを隠しつつ高度な制御を実現するUIこそが本来の姿だろう。Teamsにはその実力が十分にあるのだから、それが正しく伝わらないのはもったいない。 今回の公式説明は遅ればせながらも歓迎したい。混乱が続いていたところに公式の整理が入ることで、現場の管理者が楽になる。こうした地道なドキュメント整備の取り組みを、Microsoftにはぜひ継続してほしい。 出典: この記事は Microsoft explains extremely confusing Teams meeting recording policy の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ファッション大手ZARAを擁するInditexグループのデータベースに不正アクセスが発生し、19万7,400人分の個人情報が流出したことが、Have I Been Pwned（HIBP）の分析により明らかになった。今回の侵害を引き起こしたのはZARA自身のシステムではなく、かつて連携していた外部技術プロバイダーだ。「自社は万全」という安心感の裏側に巨大なリスクが潜んでいたこのケースは、日本企業にとっても決して対岸の火事ではない。 何が起きたのか HIBPの分析によると、流出データには以下が含まれる。 ユニークなメールアドレス（197,400件） 購入履歴・注文ID・商品SKU 地理的ロケーション情報 サポートチケット内容（問い合わせ元マーケット含む） Inditexは「氏名・電話番号・住所・認証情報・支払い情報（クレジットカード等）は含まれていない」と説明しており、顧客の直接的な金銭被害や不正ログインリスクは限定的とみられる。ただしメールアドレスと購入履歴・サポート履歴の組み合わせは、標的型フィッシングやソーシャルエンジニアリングの材料として十分すぎる情報量だ。 攻撃の手口：Anodot認証トークンの悪用 今回の攻撃で注目すべきは侵入経路だ。犯行グループ「ShinyHunters」は、クラウドデータ監視サービスAnodotの認証トークンを不正取得し、そこからBigQueryインスタンスにアクセスして140GBのアーカイブを窃取したと主張している。 Anodotのようなデータ分析・監視ツールは、BigQueryやSnowflake、Redshiftといったデータウェアハウスと幅広く連携するため、サービスアカウントに強力な読み取り権限が付与されていることが多い。この「機械のアカウント（Non-Human Identity / NHI）」が長期間にわたって有効な認証情報を保持し続けることが、攻撃者に格好の標的を提供している。 ShinyHuntersはこの手法で数十社のデータを窃取したと述べており、Microsoft Entra・Okta・Google SSOを標的にしたビッシング（音声フィッシング）キャンペーンとの関連も指摘されている。Salesforce、Microsoft 365、Google Workspace、Slack、Zendesk、Dropboxなど、多くのSaaSサービスが連鎖的に標的にされている点は見逃せない。 「委託先リスク」という本質的な問題 Inditexが強調するように、Inditex自身のシステムは侵害されていない。しかし過去に連携していたベンダーが保持していたデータが盗まれた。これがいわゆる「サードパーティ・サプライチェーン攻撃」の典型だ。 日本企業でも同様のリスクは広く存在する。 SaaSツールに付与したサービスアカウント・APIキーの棚卸しが未実施 契約終了後もアクセス権限が残存するベンダーアカウント 監視ツール・分析ツールへの過剰な権限付与 「いつ誰が作ったかわからないトークン」の長期放置 認証情報には有効期限がないものも多く、適切にローテーション・失効処理しなければ、何年も経ってから攻撃のエントリポイントになりうる。 実務への影響：NHI管理と最小権限の徹底 今回の事例から、エンジニアやIT管理者が直ちに着手すべきポイントを整理する。 1. NHIの棚卸し サービスアカウント、APIキー、OAuthトークン、クラウドIAMロールをすべて一覧化する。特に「誰が作成したか不明なトークン」は最優先で精査する。 2. 最小権限原則の適用 データ分析・監視ツールへのアクセス権は読み取り専用に限定し、BigQueryのデータセットレベルで権限を絞る。不要なリソースへのアクセスは即時削除する。 3. 認証情報のローテーションと有効期限設定 長寿命なAPIキーを廃止し、OAuth 2.0のアクセストークンのような短期トークンに切り替える。Just-In-Time（JIT）アクセスモデルの採用も有力な選択肢だ。 4. ベンダー契約終了時のアクセス権限失効プロセスの確立 委託終了後に認証情報が残存しないよう、オフボーディング手順を文書化・自動化する。「取引終了＝即時アクセス権剥奪」が原則であるべきだ。 5. サプライチェーン全体のセキュリティ評価 主要ベンダーへのSOC 2レポート要求やセキュリティアンケート実施を定期化し、委託先のセキュリティ体制を継続的に評価する。 筆者の見解 今回のZARA侵害が示すのは、「自社のセキュリティ」だけを固めても意味がないという厳しい現実だ。Inditexはおそらく自社インフラのセキュリティに多大な投資をしていたはずだ。しかし、過去に連携していたベンダーに残存していた認証情報が、侵害のエントリポイントになった。 NHI管理は地味なタスクだが、実は業務自動化の根幹でもある。サービスアカウントやAPIトークンの管理が甘ければ、自動化推進のボトルネックになるだけでなく、セキュリティホールにもなる。「常時アクセス権の付与はリスク」という原則は、人間のアカウントだけでなく機械のアカウントにも等しく適用されなければならない。 ゼロトラストを本当に実現するには、人のIDだけでなく「アクセスするすべてのもの」をID管理の対象にする必要がある。ShinyHuntersが今回利用した手法は、まさにその盲点を正確に突いている。残念ながら多くの日本企業でも、機械アカウントの管理は後回しにされているのが現状ではないか。今回のZARAの事例を、自社のNHI棚卸しを始めるきっかけにしてほしい。 出典: この記事は Zara data breach exposed personal information of 197,000 people の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）が2026年5月8日、Ivanti Endpoint Manager Mobile（EPMM）に存在する高危険度の脆弱性 CVE-2026-6973 を「悪用が確認された脆弱性リスト（KEV）」に追加し、連邦政府機関に対して日曜日深夜（日本時間2026年5月11日午後1時）までの修正を義務付けた。たった4日間という異例の短さが、この脆弱性の深刻さをよく物語っている。 CVE-2026-6973 — 何が起きているのか この脆弱性は、オンプレミス版 EPMM 12.8.0.0 以前に存在するリモートコード実行（RCE）の欠陥だ。攻撃者が管理者権限を持っている場合、対象システム上で任意のコードを実行できる。「管理者権限が前提なら大した問題ではない」と感じた人がいれば、それは危険な誤解だ。 Ivantiは「現時点では非常に限定的な悪用に留まっている」と述べているが、セキュリティ調査組織 Shadowserver の調査では、インターネットに露出した EPMM アプライアンスが800台以上存在することが確認されている。攻撃者にとっては、管理者アカウントへの侵害という初期ステップさえ踏めれば、あとは組織のエンドポイント全体を掌握できる状態だ。 修正版は 12.6.1.1、12.7.0.1、12.8.0.1 として提供されており、Ivantiは同時に管理者権限を持つアカウントを洗い出し、認証情報のローテーションも推奨している。 「管理者権限前提」は安全ではない この脆弱性の本質的な怖さは、「管理者権限があれば悪用できる」という構造にある。一見すると攻撃ハードルが高いように見えるが、現実はそう単純ではない。 Ivanti EPMMのようなMDM製品の管理者アカウントは、組織内のエンドポイント全体を掌握できる強大な権限を持っている。このアカウントが常時有効な状態で放置されているケースは決して少なくない。仮に管理者アカウントが以前の侵害——たとえば今年1月に悪用された CVE-2026-1281 や CVE-2026-1340 ——で漏洩していれば、今回の脆弱性の悪用ハードルは一気に下がる。 Ivantiは「1月に認証情報をローテーションした組織はリスクが大幅に低下している」と明言している。裏を返せば、ローテーションを後回しにした組織は今この瞬間も危険に晒されているということだ。 「オンプレ製品のみ」が示すもの 今回の脆弱性が影響するのはオンプレミス版のみで、クラウド版「Ivanti Neurons for MDM」には影響しない。この一文には、単なる注意書き以上のメッセージが含まれている。 オンプレミス製品はパッチ適用のタイミングを組織自身がコントロールできる半面、脆弱性発見から修正適用までの時間は、攻撃者に与えられた猶予でもある。クラウド型であれば、ベンダー側が迅速に対処できる部分も多い。 日本のIT現場では、コンプライアンス要件や既存システムとの統合を理由にオンプレミスMDMを維持しているケースが多い。その選択自体を否定するつもりはないが、「オンプレを選んだ以上、パッチ適用を即座に実行できる体制が常にセットになっているか」は真剣に問い直す価値がある。 実務への対応チェックリスト Ivanti EPMMを利用しているIT管理者は今すぐ以下を確認してほしい。 バージョン確認: 12.8.0.1、12.7.0.1、12.6.1.1のいずれかに更新済みか 管理者アカウントの棚卸し: Admin権限を持つアカウントをすべてリストアップ。不要なものは削除または無効化 認証情報のローテーション: 特に1月のCVE悪用後に実施していない場合は即刻対応 アクセスログの精査: 管理者権限での不審なアクセスがなかったか確認 露出面の見直し: EPMMアプライアンスが不必要にインターネットに露出していないか確認。ゼロトラストネットワークアクセス（ZTNA）による保護も検討を CISAの指令は米国連邦機関向けだが、民間企業においても「CISAが4日以内を命じた脆弱性」は最優先対応の目安として活用できる。 筆者の見解 今回の件で改めて痛感したのは、管理者権限を「常時オン」で運用することの危うさだ。 MDM製品の管理者アカウントは組織の全端末に絶大な権限を持つ。にもかかわらず、それが「必要なときだけ有効にする（Just-In-Time アクセス）」ではなく、24時間365日アクティブな状態で放置されているケースが多い。今回のような「管理者権限があれば悪用可能」という脆弱性が出るたびに、この設計の危うさが繰り返し露わになる。 「最小権限の原則」は理念としては広く知られている。だが実務でちゃんと実装できている組織は、日本においてまだ少数派だと感じる。「今動いているから大丈夫」という現状維持バイアスが、次の侵害の種を静かに育てている。 オンプレミス vs クラウドの議論は「どちらが優れているか」ではなく、「選んだ方式のリスクを自社でどれだけ管理できるか」が本質だ。オンプレを続けるなら、パッチ適用の迅速化と特権アカウント管理の厳格化は絶対条件。Shadowserverが追跡する800台超の露出アプライアンスの中に、日本の組織のものが含まれていないことを願うばかりだ。 出典: この記事は CISA gives feds four days to patch Ivanti flaw exploited as zero-day の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

セキュリティ企業が攻撃される——これは単なる皮肉では済まない、業界全体の信頼基盤に関わる重大な現実だ。世界53,000社以上にサイバーセキュリティ製品を提供するTrellixが、自社のソースコードリポジトリへの不正アクセスを受けたことを認めた。データ恐喝グループ「RansomHouse」が犯行を主張しており、ダークウェブのリークサイトにスクリーンショットを証拠として公開している。 Trellixとはどんな企業か Trellixは2022年に、McAfee EnterpriseとFireEyeが統合して誕生した国際的なサイバーセキュリティ企業だ。Fortune 100企業を多数顧客に持ち、185カ国・3,500名以上の従業員を擁する。その企業が攻撃されたという事実は、「セキュリティベンダーなら安全」という幻想を改めて打ち砕く出来事だ。 インシデントの経緯 Trellixは5月1日に侵害を公式確認した。声明によれば「ソースコードリポジトリの一部への不正アクセスを確認。法執行機関への通知と共にフォレンジック専門家と協力して対応中。ソースコードのリリース・配布プロセスへの影響、ならびにソースコードの悪用は現時点で確認されていない」としている。 RansomHouseの主張によると、侵害は4月17日に発生しデータが暗号化されたという。同グループはアプライアンス管理システムのスクリーンショットを恐喝ポータルに公開したが、現時点でその真正性は独立して確認されていない。 RansomHouseの脅威プロファイル RansomHouseは2022年にデータ恐喝オペレーションとして活動を開始したサイバー犯罪グループだ。当初はデータ窃取と恐喝が中心だったが、その後ツールキットを着実に高度化させている。 注目すべきは2つの独自ツールだ： 「Mario」: 2つの異なる鍵でファイルを二重暗号化する独自ツール。復号をより困難にする設計 「MrAgent」: VMware ESXiハイパーバイザー上への暗号化ツール展開を自動化するツール ESXiを標的とする点が特に危険だ。多くの企業が仮想化基盤にESXiを採用しており、ここが侵害されると複数VMが一括で暗号化・停止させられる。単一のエントリーポイントから広範な被害が生じる典型的なパターンだ。 日本との関係——ASKULも被害者 日本の読者に見過ごせない点がある。RansomHouseの最近の高プロファイル攻撃に、日本の大手EC企業アスクル（ASKUL）が含まれているのだ。このケースでは顧客情報74万件を含む大量データが窃取された。 RansomHouseは日本企業をターゲットとした実績を持つグループであり、対岸の火事として見ることはできない。 なぜセキュリティベンダーのソースコード漏洩が深刻か 一般ソフトウェアのソースコード漏洩とは次元が違う。セキュリティ製品のコードが攻撃者の手に渡ると： 検出ロジックの解析: どのように脅威を検出しているかが分かれば、検出を回避するマルウェアの開発が容易になる 脆弱性の先取り: 製品自体のバグや設計上の欠陥を事前に把握できる 正規フォーマットの悪用: 正規の署名・形式を模倣した偽装マルウェアの作成に活用される可能性がある Trellixが「悪用は確認されていない」と述べているが、その確認には構造的な限界がある。攻撃者が静かにコードを解析し、数ヶ月後の別の攻撃に活かすシナリオは排除できない。 実務への影響——IT管理者が今すぐ確認すべきこと Trellixユーザー向け 公式リリースの整合性検証（ハッシュ値・署名確認）を通常より厳格に実施する Trellixからのアドバイザリーを定期的にモニタリングし、推奨パッチを速やかに適用する 製品の異常な挙動や予期しない通信がないか監視を強化する セキュリティ体制全般の見直し VMware ESXi環境の保護強化: 管理インターフェースへのアクセス制御とネットワーク分離を今一度見直す。MrAgentのような攻撃ツールが存在する以上、ESXiへの不要な外部露出は即時排除すべきだ ソースコードリポジトリのアクセス管理: 最小権限・多要素認証・アクセスログの監査を徹底する。今回のような侵害は、リポジトリへのアクセス権が適切に管理されていれば被害を局限できた可能性がある セキュリティツールを「信頼の証」として扱わない: ゼロトラストの原則は「セキュリティ製品自体にも適用する」という意識が今まさに必要だ 筆者の見解 今回の事件で改めて突きつけられるのは、「守る側が守られていない」という厳しい現実だ。 セキュリティベンダー自身が攻撃される構図は、製品選定における「この会社なら安全だろう」という暗黙の前提を根底から揺るがす。だからといって虚無的になる必要はない。むしろ本来あるべき姿に立ち返るきっかけだと受け取りたい。 重要なのは「あらゆる組織・製品は侵害されうる」という前提でセキュリティを設計することだ。これはゼロトラストアーキテクチャが本質的に目指していることと一致する——「信頼しない、常に検証する」。この姿勢はセキュリティツールの選定や運用にも同様に当てはまる。 一つのツールへの過度な依存を排除し、ネットワーク層・認証層・認可層の多層防御を構築する。それが「今動いているから大丈夫」という危険な慢心を防ぐ唯一の道だ。 RansomHouseはASKUL、そしてTrellixを標的にした。次の標的が誰かという問いに「うちは大丈夫」と答えられる根拠を、今すぐ洗い出しておくべき時期に来ている。 出典: この記事は Trellix source code breach claimed by RansomHouse hackers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

NVIDIAは2026年5月、クラウドゲーミングサービス「GeForce NOW」のアルメニア地域パートナーが運営するインフラにおいてデータ漏洩が発生したことを公式に認めた。NVIDIA自身のネットワークへの直接的な影響はなかったとされているが、今回の事件が投げかける問いは単なるゲームサービスのインシデントにとどまらない。「信頼したブランドの裏側で、別の組織がデータを管理していた」という構図は、クラウドサービス全般に共通する構造的リスクとして受け止める必要がある。 何が起きたのか 2026年3月20〜26日の間、GeForce NOWのアルメニア地域オペレーター「GFN.am」が運営するシステムが不正アクセスを受け、利用者の個人情報が外部に流出した。 流出した可能性のある情報は以下のとおりだ。 氏名（Googleアカウント利用者の場合） メールアドレス 電話番号（モバイルキャリア経由で登録した場合） 生年月日 ユーザー名 2FA/TOTPの有効・無効状態 GFN.amはパスワードは流出していないと声明で説明しており、2026年3月9日以降に登録したユーザーは対象外としている。ハッカーフォーラムにこの漏洩情報を投稿した脅威アクターはShinyHuntersを名乗り、数百万件のユーザーレコードをビットコインまたはモネロで10万ドルで販売すると提示した。ただし、このアクターはShinyHuntersの模倣犯（インポスター）である可能性が高いとされており、投稿はすでに削除されている。 アライアンスパートナーモデルの構造 GeForce NOWには、NVIDIAが直接運営するケースと、地域パートナー（アライアンスパートナー）が独自に運営するケースの二形態がある。アルメニアのGFN.amはアゼルバイジャン・グルジア・カザフスタン・モルドバ・ウクライナ・ウズベキスタンにも対応しており、独立した認証システム・顧客データベース・課金プラットフォームを自社で管理している。 ユーザーから見れば「NVIDIAのサービスを使っていたはず」であっても、実際には別の組織が管理するインフラ上にデータが置かれていた、という構図になる。今回の被害はまさにそこで発生した。 実務への影響 日本のIT管理者・エンジニアにとって、今回の事件から得るべき教訓は主に二点ある。 1. サードパーティリスク評価は「書面の確認」だけでは不十分 クラウドサービスを導入する際、ベンダー本体のセキュリティ認証だけでなく、地域パートナーや下請けが管理するシステムのセキュリティ水準も評価対象に含める必要がある。SLA（サービスレベルアグリーメント）にサードパーティの管理基準を明記する条項の整備は、もはや「できれば望ましい」ではなく必須の作業だ。 2. 2FAの有効・無効状態も立派な機密情報 パスワードが流出していなくても、2FA/TOTPの有効・無効状態が漏洩すると、攻撃者にとって有用な情報になる。2FAが無効なアカウントをリスト化して標的を絞り込む用途に使われるためだ。多要素認証の設定状況自体も、保護すべき情報として扱う意識が求められる。 筆者の見解 今回の事件を「NVIDIA本体は無傷だったから大した話ではない」で終わらせてしまうのは、本質を見誤ることになる。 アライアンスパートナーモデル自体は、地域の法規制対応や低コスト展開という観点から合理的な選択だ。だが、パートナー側のセキュリティ水準がベンダー本体と乖離していた場合、そのギャップがそのままリスクになる。ユーザーはブランドを信頼して契約したにもかかわらず、実質的に別組織のセキュリティ管理下に置かれる—この非対称性が今回の問題の核心だ。 この構図はクラウドゲーミングに限らない。日本市場でも、SaaSやIaaSを「地域パートナー経由」で提供するケースは少なくない。委託先を含めたサプライチェーン全体のセキュリティ管理体制を問い直せていない組織は、想像以上に多いのではないか。 ゼロトラストの文脈でいえば、「信頼済みパートナーだから安全」という前提こそが最大の盲点になりうる。委託先も含めた全インフラを「信頼しない」前提でモニタリングする体制—これが今後のクラウド活用における基本姿勢になるだろう。「今動いているから大丈夫」は、もはや通用しない。 出典: この記事は NVIDIA confirms GeForce NOW data breach affecting Armenian users の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AI開発プラットフォームのHugging Faceで、OpenAIの公式プロジェクトに偽装した悪意あるリポジトリが約24万4,000回のダウンロードを記録しながらトレンド1位に到達し、Windowsユーザーへ情報窃取マルウェアを配布していた事実が判明した。npmやPyPIで何年も繰り返されてきたサプライチェーン攻撃が、いよいよAIモデルの世界でも本格化している。 偽装の手口――「本物そっくり」のリポジトリ セキュリティ企業HiddenLayerの研究者が2026年5月7日に発見したのは、Open-OSS/privacy-filterという名称のリポジトリだ。OpenAIが公開している正規の「Privacy Filter」プロジェクトをタイポスクワッティング（類似名称による偽装）し、モデルカードの説明文まで原文をほぼそのままコピーして本物らしさを演出していた。 問題のloader.pyは、AIモデルを読み込むための正規コードに見せかけながら、裏ではSSL検証を無効化し、Base64エンコードされたURLを復号して外部サーバーに接続。PowerShellコマンドを含むJSONペイロードを取得・実行する仕組みが組み込まれていた。 攻撃チェーンと窃取対象 実際の攻撃の流れを整理すると次のようになる。 loader.pyが不可視ウィンドウでPowerShellを実行 バッチファイル（start.bat）をダウンロードして特権昇格を実行 最終ペイロード（sefirah）を取得し、Microsoft Defenderの除外リストに自動登録 Rust実装のインフォスティーラーが起動 マルウェアが狙う情報は幅広い。ChromiumやGeckoベースのブラウザに保存されたパスワード・Cookie・セッショントークン、Discordトークンとローカルデータベース、暗号資産ウォレットとシードフレーズ、SSH・FTP・VPN設定ファイル（FileZillaを含む）、マルチモニターのスクリーンショットなど、実務端末に存在しうる重要資産がほぼ網羅されている。盗み取ったデータはrecargapopular[.]comに送信される。 さらにこのマルウェアは、VM検出・サンドボックス検出・デバッガー検出など複数のアンチ分析機能を内蔵しており、自動解析システムによる検知を積極的に回避する設計だ。 「244,000 downloads」の重さ HiddenLayerは、244,000というダウンロード数が人為的に水増しされている可能性を指摘している。リポジトリに「いいね」した667アカウントの多くも自動生成と見られる。それでも、Hugging Faceのトレンド1位に到達したという事実は、「人気があるから安全」というソーシャルシグナルへの信頼がいかに容易に操作できるかを示している。 また調査の過程で、同じローダーインフラを使用する別リポジトリも複数発見された。npmエコシステムでWinOS 4.0インプラントを配布するタイポスクワッティングキャンペーンとの重複も確認されており、組織的な攻撃グループが複数の攻撃ベクターを並行展開している可能性がある。 実務への影響 開発者・MLエンジニア向け リポジトリ名・組織名の差異を確認する習慣を: OpenAIではなくOpen-OSSという微妙な違いを見逃さない 実行前にソースコードを必ず読む: AIモデルのサンプルコードであっても、loader.pyの類は実行前に内容を確認する 未知のリポジトリはサンドボックスで検証: Hugging Faceから取得したモデルは隔離環境で動作確認してから本番利用へ IT管理者・セキュリティ担当者向け Microsoft Defender除外リスト変更をアラート対象に: 今回の攻撃はDefenderの除外機能を悪用する。除外リスト変更イベント（Event ID 5007等）の監視を整備する Hugging FaceへのアクセスをEndpoint DLPでポリシー化: 業務端末からの無制限アクセスを見直し、承認済みリポジトリのみに絞る NHI（Non-Human Identity）のシークレットを定期ローテーション: SSH鍵やFTPパスワードが漏洩した際の被害を最小化するため、シークレットローテーションの自動化を整備する 感染が疑われる場合は、端末の再イメージング、全保存認証情報のローテーション、暗号資産ウォレットとシードフレーズの差し替え、ブラウザセッションの無効化が必要だ。 筆者の見解 正直なところ、セキュリティ系は得意なジャンルではない。それでも今回の件は技術的に非常に興味深いと感じた。 AIツールが「インフラ化」しつつある今、Hugging FaceはnpmやPyPIと同等のサプライチェーンリスクを持つプラットフォームになりつつある。npmのタイポスクワッティング事件は何年も前から繰り返されてきたが、同じ問題がAIモデルの世界でも起きるのは時間の問題だった。そしてその「時間」が来た。 注目したいのは攻撃の精巧さだ。Pythonファイルに正規のAI処理コードを混在させてサンドボックスをすり抜け、PowerShellを不可視ウィンドウで実行してDefender除外まで自動設定する。これだけの手順を踏んでいることからも、標的が開発者やMLエンジニアという「権限を持ったユーザー」であることは明白だ。彼らの端末には、ビジネスに直結する認証情報が集中している。 「トレンド入りしているから安全」「多くの人がダウンロードしているから大丈夫」という心理的バイアスは今や危険だ。エンゲージメント指標が簡単に操作できる時代において、ソーシャルシグナルは信頼の根拠にならない。AIエコシステムを活用する組織には、コードを読むという当たり前の習慣をAIモデルにも適用することが、今すぐ求められている。 出典: この記事は Fake OpenAI repository on Hugging Face pushes infostealer malware の内容をもとに、筆者の見解を加えて独自に執筆したものです。

人気ダウンロードマネージャー「JDownloader」の公式Webサイトが攻撃者によって改ざんされ、2026年5月6日から7日の間に同サイトからWindowsまたはLinux向けインストーラーをダウンロードしたユーザーは、マルウェアに感染した可能性がある。開発チームは事態を確認後、サイトを一時オフラインにして調査を進めた。JDownloaderは10年以上の歴史を持ち、世界中で数百万人が利用するフリーのダウンロード管理ツールだ。その公式サイトが狙われたという事実は、ソフトウェアのダウンロードというごく日常的な行為にひそむリスクを改めて浮き彫りにする。 何が起きたのか 攻撃者はJDownloaderの公式サイトが利用しているCMS（コンテンツ管理システム）の未パッチの脆弱性を悪用。認証なしにWebサイトのアクセス制御リスト（ACL）やコンテンツを変更できる状態を作り出し、正規のダウンロードリンクを悪意のある第三者のペイロードへのリンクに差し替えた。 開発チームの報告によれば、攻撃者がアクセスできたのはCMSが管理するWebコンテンツの範囲のみで、サーバーのファイルシステムやOS層への侵入は確認されていない。いわゆる「サプライチェーン攻撃」と呼ばれる手法だが、ソースコードや開発パイプラインへの侵害ではなく、配布インフラ（公式Webサイト）を狙った点が今回の特徴だ。 攻撃の手口——配布インフラへの直接介入 Windowsの「Download Alternative Installer」リンクとLinuxのシェルインストーラーリンクが書き換えられた。一方で、アプリ内アップデート、macOSダウンロード、Flatpak、Winget、Snap、そして主要なJDownloader JARパッケージは改ざんの対象外だった。 この選択は攻撃者が意図的に狙いを絞ったことを示唆している。最も利用されやすいWebサイト上の「インストーラー」リンクだけを書き換え、検出リスクが高いパッケージマネージャー経由の配布やアプリ内更新は触らなかった。検出回避を意識した巧妙な設計と言える。 配布されたマルウェアの正体 セキュリティ研究者のThomas Klemencが分析した結果、Windows向け悪意のある実行ファイルは「ローダー（loader）」として機能し、高度に難読化されたPythonベースのRAT（Remote Access Trojan、遠隔操作ツール）を展開することが判明した。 このPythonペイロードはモジュール型のボット＆RATフレームワークとして動作し、C2（コマンド＆コントロール）サーバーから送り込まれたPythonコードを実行できる設計になっている。感染後、攻撃者が任意のコードを被害者のマシンで実行できる状態が作られてしまうわけだ。 Linux向けには、正規のシェルインストーラーに悪意のあるコードが注入され、SVGファイルに偽装したアーカイブを外部サーバーからダウンロードする仕組みが仕込まれていた。 影響範囲と自己確認の方法 5月6日または7日にJDownloaderのインストーラーをダウンロードした場合は、以下の手順で正規品かどうかを確認できる。 インストーラーファイルを右クリックし「プロパティ」を開く 「デジタル署名」タブを確認する 署名者が 「AppWork GmbH」 であれば正規品 署名なし、または別の名前（「Zipline LLC」「The Water Team」など）が表示される場合は偽物 一人のユーザーがMicrosoft Defenderによる検出を報告したことが今回の発覚の発端となった。エンドポイント保護が実際に機能した事例として記録しておく価値がある。 日本のIT現場への影響 JDownloaderは動画配信サイトや各種ファイルホスティングサービスからのダウンロードを自動化できるツールとして、日本でもコンテンツクリエイターやIT担当者に幅広く使われている。 今回のインシデントが示すのは、「公式サイトからダウンロードしたから安心」という前提が崩れてしまうリスクだ。企業のIT管理者として明日から取れるアクションを整理する。 デジタル署名の検証を習慣化する インストーラーのデジタル署名確認は数秒でできる。導入前の確認を社内ルールに組み込んでほしい。 パッケージマネージャー経由の調達を優先する WingetやChocolatey（Windows）、AptやSnap（Linux）など、パッケージマネージャーを経由したインストールは今回の攻撃の対象外だった。エンドポイントへのソフトウェア配布はパッケージマネージャーを通じて一元管理する体制を検討したい。 エンドポイント保護の有効性を再確認する Microsoft Defenderが今回の偽インストーラーを検出できたことは重要だ。定義ファイルの更新状況と検出・対応設定を定期的に確認してほしい。 筆者の見解 今回の事件で注目すべきは、攻撃者がソースコードやビルドパイプラインには手を付けず、WebサイトのCMS脆弱性だけで配布インフラを乗っ取ったという点だ。技術的には「小さな侵入」だが、影響はサプライチェーン攻撃と同等の被害をもたらしうる。 開発チームがCMSの脆弱性を未パッチのまま放置していたことは、オープンソースプロジェクトが抱える共通の課題を映し出している。メンテナンスリソースが限られる中で、Webサイト運用のセキュリティまで手が回らないケースは珍しくない。それ自体は理解できる事情だが、だからこそ利用者側が「配布元を盲信しない」姿勢を持つことが大切になる。 ゼロトラストの観点から言えば、「公式サイト」という権威を自動的に信頼するモデルは根本から見直す必要がある。ダウンロードしたバイナリを信頼するかどうかの判断は、配布元のブランドではなく、デジタル署名・ハッシュ値・取得経路に基づくべきだ。この教訓はJDownloaderに限らず、すべてのソフトウェア調達プロセスに当てはまる。 PythonベースのRATがモジュール型で任意のコードを実行できる設計になっている点も技術的に興味深い。初期感染ペイロードを軽量に保てるため検出が難しく、感染後の攻撃者の自由度が非常に高い。このアーキテクチャのマルウェアは今後も増えていくと見ている。 「信頼は稼ぐものであり、付与するものではない」——この原則をソフトウェア調達にも適用する時代が来ている。 出典: この記事は JDownloader site hacked to replace installers with Python RAT malware の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Metaが、InstagramのDM（ダイレクトメッセージ）に適用していたエンドツーエンド暗号化（E2EE）を廃止した。導入からわずか数年での撤回は、「プライバシー優先のSNS」を標榜してきた同社の姿勢を根本から揺さぶるものだ。 E2EEとは何か、なぜ重要だったのか エンドツーエンド暗号化とは、送受信者だけがメッセージを復号できる仕組みだ。通信を中継するサーバー上でも内容は暗号化されたままであるため、仮にサーバーが侵害されても、あるいはプラットフォーム企業が政府機関から情報開示を求められても、メッセージの中身は原則として読み出せない。 MetaはWhatsAppでのE2EEをベースに、段階的にInstagramのDMへも同機能を展開。2023年末にはデフォルト有効化を完了させ、プライバシー強化をアピールしていた。それがわずか数年で廃止されることになった。 なぜ廃止されたのか 公式な説明は現時点で詳細が出ていないが、背景として考えられる要因はいくつかある。 規制当局からの圧力: EUや英国など各国政府は長年、E2EEが児童性的虐待コンテンツ（CSAM）の検出を困難にするとして批判してきた。英国のオンライン安全法（Online Safety Act）はその代表例で、プラットフォームにコンテンツスキャン義務を課す方向で立法が進んでいる。 コンテンツモデレーションとの根本的なトレードオフ: E2EEされたメッセージは、AIによるスパム・詐欺・ハラスメントの検出が事実上できなくなる。プラットフォームの安全維持とユーザーのプライバシー保護は、本質的に緊張関係にある。 政治・ビジネス的判断: 大手テック企業が規制当局との対立を避けるべく方針を軟化させる動きが、近年目立つようになっている。E2EE廃止もその文脈で捉えることができる。 実務への影響 個人ユーザーへの対応 InstagramのDMを「プライベートな連絡手段」として使っていたユーザーは、メッセージ内容がMetaのサーバー上で読めるようになったと認識する必要がある。機微な情報のやり取りにInstagramを使っていたなら、現時点でE2EEを維持しているSignalやWhatsApp（同じMeta傘下ではあるが）への切り替えを検討すべきだ。 企業・IT管理者が今すべきこと 業務での連絡ツールとしてInstagram DMを直接使うケースは少ないかもしれないが、従業員が個人スマートフォンで顧客や取引先とやり取りをしているシナリオは意外に多い。「業務に関わるやり取りがE2EEなしのコンシューマーSNSに流れていないか」を棚卸しするよい機会だ。 従業員教育の観点でも、「SNSのDMは本質的に安全ではない」という前提を改めて周知することが重要になる。利便性の高いコンシューマーアプリをそのまま業務利用するリスクを、今一度確認してほしい。 ゼロトラストの観点から 「通信経路が安全かどうかに依存したセキュリティ設計」は、今回のような方針転換の前で簡単に崩れる。「プラットフォームが提供する暗号化に頼る」のではなく、「どの通信路を使っても機密情報は別途保護されている」という設計思想——これがゼロトラストの本質であり、今回の件はその重要性を改めて示している。 筆者の見解 正直、この件でMetaに驚きはない。 E2EEの廃止は技術的な後退というより、ビジネス・規制・政治的判断の結果だ。「ユーザーのプライバシーを守る」と宣言した機能であっても、状況が変われば方針転換できる——これはMetaに限った話ではなく、プラットフォーム全体に共通するリスクだ。 気になるのは、ユーザー側の「慣れ」である。E2EEが廃止されても、多くの人がそのままInstagramを使い続けるだろう。利便性の前ではプライバシーへの意識がすぐに霞んでしまう。そしてプラットフォーム側はそれを知っている。 セキュリティとプライバシーの問題は、技術的な解決策だけでは永続しない。提供企業の商業的利益と、ユーザーの安全・プライバシーが常に一致するとは限らない。「このプラットフォームはE2EEを維持する経済的インセンティブがあるか」まで考えることが、今後はますます重要になる。 通信手段の選択は、技術仕様を読むだけでなく、提供企業のビジネスモデルそのものと向き合う問いでもある。今回の件は、その現実をはっきりと示した。 出典: この記事は Meta has killed end-to-end encryption on Instagram の内容をもとに、筆者の見解を加えて独自に執筆したものです。