Windows

Windows Recall をめぐるセキュリティ議論が再び熱を帯びている。セキュリティ研究者 xaitax が「認証後の復号データが保護されていないプロセスに渡る」と主張したのに対し、Microsoft は「文書化済みの意図した設計通りだ」と反論し、調査を「脆弱性なし」として終了した。両者は同じ挙動を見ながら、まったく異なる結論に達している。 何が問題になっているのか Windows Recall は Copilot+ PC 限定の機能で、画面のスナップショットを定期的に保存し、後から自然言語で検索・参照できるようにするものだ。セキュリティ設計の柱は3つ——オプトイン（初期状態は無効）、ローカル保存（Microsoft への送信なし）、Windows Hello 認証（TPM と VBS（仮想化ベースのセキュリティ）によるデータ暗号化）。 研究者 xaitax が問題にしたのは、この3つの柱の「その先」で起きることだ。 VBSエンクレーブとレンダリング層のはざまで何が起きるか Recall のデータは VBS エンクレーブ内で暗号化・保護されている。この部分は文字通り鉄壁だ。しかし認証が完了した後、復号されたスクリーンショットや OCR テキスト、メタデータは「タイムライン表示」のための UI プロセス（AIXHost.exe）に渡される。xaitax の主張は、この AIXHost.exe が Protected Process Light（PPL）を持っていないため、同一ユーザーとして実行されるコードからのプロセスインジェクションに対して無防備だ、というものだ。 研究者はこう表現している——「VBSエンクレーブは鉄壁。問題は暗号でも認証でも PPL でもない。復号済みのコンテンツを保護されていないプロセスに渡して表示させていることだ。金庫の扉はチタン製。でも隣の壁は石膏ボード」と。 Microsoft の反論は「認証後にアクセスできる設計は文書化されており、その挙動は意図通りだ」というもの。つまり論点は「バグか仕様か」ではなく、「その仕様設計が十分に安全か」にある。 アーキテクチャの本質的なトレードオフ Microsoft が 2024 年に公開した設計説明によれば、スナップショット操作と復号は「信頼されたエンクレーブサービス」が担い、「信頼されていない Recall UI」にはユーザーが要求したデータのみが認証後に渡される、とされている。つまり Microsoft 自身が UI を「信頼されていない（untrusted）」と位置づけた設計だ。 これは実用的な UI 体験を提供するための合理的なトレードオフと見ることもできる。しかし「信頼されていないプロセスに復号済みデータを渡すことがどこまで許容されるか」という問いへの答えは、組織のリスク許容度によって大きく変わる。 日本のIT現場への影響 現時点で Recall を積極展開している日本企業は少数派だが、Copilot+ PC の普及とともに今後は検討対象として浮上してくる。IT 管理者として押さえておきたいポイントは3点だ。 現時点では Recall をオプトインしないのが最もシンプルな判断。機能を有効化しなければ攻撃対象にならない グループポリシーおよび Intune による Recall 無効化が可能。「禁止」より「情報システム部門が承認したユースケース以外では無効」という管理ポリシーが現実的 「認証が通れば安全」は出発点に過ぎない。ゼロトラストの観点では認証後の動作も脅威モデルに含めて設計する必要がある 筆者の見解 Microsoft が「意図した設計通り」と主張するのは、技術的には間違っていないかもしれない。しかし「仕様であるか否か」と「その仕様が十分に安全か」は、まったく別の問いだ。xaitax の指摘の核心は「設計の選択への異議」であり、それは今後も続く正当な議論だと思う。 ...

Microsoftが新しいハードウェアへの搭載を開始した「Windows 11 バージョン 26H1」は、これまでの年次アップデートとはまったく異なる性質を持つ特殊なリリースだ。企業のIT部門やエンジニアが「また新しいビルドか」と流してしまうには惜しい、構造的に重要な変化が含まれている。 26H1とは何か——従来の年次リリースとの違い Windowsの年次機能アップデートはこれまで、「22H2」「23H2」「24H2」といった形で年に1回提供され、利用者はそのままアップグレードして最新の機能と最新のサポート期間を受け続ける仕組みになっていた。 ところが26H1は違う。このバージョンは将来の半期アップデートへのアップグレードパスが存在しない。つまり、26H1を搭載したデバイスは、次の27H1や28H1へとその場でアップグレードする従来の流れに乗れないということになる。 サポート期間は以下の通り保証されている： Home / Pro エディション：2028年3月まで Enterprise エディション：2029年3月まで この期間はセキュリティ更新プログラムが提供されるが、その先は別のアップグレード手段を検討する必要がある。 なぜこの「特殊リリース」が存在するのか Microsoftがこうした特殊な位置づけのリリースを用意する背景には、ハードウェアのリフレッシュサイクルと、AIをはじめとする新機能の要件強化という二つの動きがある。 新しいSurface PCや各OEMメーカーの最新デバイスは、Copilot+ PCに代表されるAI機能を前提に設計されており、旧来のアーキテクチャ上には最適に展開できない機能が増えつつある。26H1は、こうした次世代ハードウェア向けの「初期搭載OS」としての役割を担っており、既存デバイスの年次アップデートの流れとは切り離して管理されているわけだ。 実務への影響——IT部門が今確認すべきこと このリリース形態は、企業のWindowsライフサイクル管理に実質的な影響を与える。 1. 端末調達時のOS確認を徹底する 新規購入デバイスに26H1が搭載されている場合、そのデバイスのサポートライフサイクルが既存機器と異なることを管理台帳に明示しておく必要がある。2028年3月（Home/Pro）以降の対応計画を今から組み込んでおくことが望ましい。 2. Windows Update for Business / Intuneの設定を見直す Microsoft Intuneや Windows Update for Business を利用して更新管理をしている環境では、26H1搭載デバイスを誤って既存の「Feature Update」ポリシーで管理しようとすると、意図しない挙動を招く可能性がある。展開グループやリングの設計を再確認しておこう。 3. エンタープライズ向け2029年3月サポートの価値を最大化する Enterprise / Education エディションに限り2029年3月までのサポートが確保される点は、5〜7年サイクルで端末を運用する日本の大規模企業にとって実用上の余裕となりうる。ただし「サポートが長いから手を付けなくていい」ではなく、次世代への移行計画を並行して進める姿勢が重要だ。 4. 数日様子を見る判断も正しい 大規模なリリース直後は互換性の問題が報告されるケースも増えている。品質更新（月例パッチ）については、少数の検証機で先行適用し、1〜2営業日の動作確認を経てから広く展開する運用を検討したい。「すぐに当てること」と「安定を確認してから当てること」のどちらが適切かは環境次第であり、慎重な判断そのものがセキュリティ管理の一部だ。 筆者の見解 率直に言って、Windowsの機能更新を以前ほど詳細に追いかける必要性はどんどん薄れている。多くの現場では、Windowsはすでに「動いている基盤」であって、そのバージョンを細かく追うことより、その上で動くサービスやアプリケーションの品質向上に時間を使う方が実りは大きい。 そうした中で26H1が注目に値するのは、機能の多寡ではなく「リリースモデルの変化」にある。Microsoftが年次アップグレードから外れた特殊パスを正式に設けたことは、WindowsをよりAI機能の進化に対応した形で刷新していこうという意図の表れでもある。方向性自体は理解できる。 ただ、アップグレードパスの断絶が生む現場の混乱は無視できない。「26H1のデバイスはどうするんだっけ？」という問いが管理者の頭を悩ませる事態は、本来避けられるはずだ。Microsoftにはライフサイクルの設計とその伝え方を、もう少し現場目線で丁寧に整理してほしい——実力は十分あるのだから、その力を「わかりやすさ」に使ってほしいというのが、正直なところだ。 今後の動向として、Surface新モデルへのOLEDディスプレイ採用と二段階ローンチの噂も報じられている。ハードウェアの刷新とOSのリリースモデル変化が重なるタイミングであり、特に法人端末の調達・更新を検討している組織にとっては情報を整理しておく好機だ。 出典: この記事は Windows 11 version 26H1: Everything you need to know about Microsoft’s special OS release now shipping on new hardware の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2026年4月のWindowsセキュリティ更新プログラムを境に、Active Directory（AD）環境における Kerberos 認証の RC4 暗号化廃止が新たな段階へ進んだ。「今動いているから大丈夫」で放置してきた環境が、ひっそりと壊れ始めるタイミングが来ている。 RC4廃止フェーズ2とは何が変わるのか Kerberos 認証で使われる暗号化方式として、長年 RC4-HMAC（ARCFOUR）が使われてきた。RC4 は 1990 年代に設計されたストリーム暗号であり、現代の基準では脆弱性が指摘され続けてきた。Microsoftは段階的に RC4 の使用を制限する方針を取っており、今回の更新はその「フェーズ2」にあたる。 フェーズ1（既往の更新） では、KDC（Key Distribution Center、つまりドメインコントローラー）が AES を優先するよう挙動が変更されていた。 フェーズ2（2026年4月更新） からは、アカウントに明示的な暗号化タイプの設定がない場合、AES-SHA1（AES256-CTS-HMAC-SHA1-96 または AES128-CTS-HMAC-SHA1-96）のチケットがデフォルトで発行されるようになる。RC4 でしか動かない古い設定やアプリケーションは、ここで初めて認証エラーとして顕在化する。 影響を受ける可能性のある構成 主に以下のケースで認証失敗が発生しうる。 msDS-SupportedEncryptionTypes 属性が未設定またはゼロのアカウント コンピューターアカウントやサービスアカウントを古い手順で作成・管理していた場合に多い。ADUCで確認可能だが、多くの組織では棚卸しができていない。 SPN（Service Principal Name）が登録されたサービスアカウント SQL Server の実行アカウント、IIS のアプリケーションプール、Jenkins などのCI/CDエージェントなどが該当しやすい。これらは昔のドキュメント通りに設定したまま何年も動き続けているケースが多い。 古い NAS・複合機・ネットワーク機器 AES をサポートしていないベンダー実装が残っていると、認証できなくなる。ファームウェアアップデートで対応できるものと、製品の寿命を迎えているものがある。 Kerberos を使う Linux/Unix ホスト MIT Kerberos や SSSD の設定で RC4 固定になっている場合は要確認。 確認・対応の手順 1. イベントログで RC4 使用状況を洗い出す ドメインコントローラーのセキュリティイベントログ（イベントID 4769）を確認し、Ticket Encryption Type: 0x17（RC4-HMAC）で認証しているアカウントを特定する。Microsoft が提供するスクリプトや、DefenderのAD監査機能も活用できる。 2. msDS-SupportedEncryptionTypes を明示的に設定する 対象アカウントに AES256（0x10）または AES128+AES256（0x18）を明示的に設定する。Set-ADUser や Set-ADComputer の -KerberosEncryptionType パラメーターで一括処理が可能。 ...

Microsoftが2026年4月、Windows 11のセキュリティに関する公式ドキュメントを静かに更新し、「一般ユーザーは別途アンチウイルスソフトを導入する必要はない」という見解を明らかにした。Windows XP・Windows 7時代から続いてきた「アンチウイルスソフトは必須」という常識が、とうとう公式に塗り替えられることになる。 Windows Defenderはもう「おまけ」ではない かつてWindowsのアンチウイルス機能といえば、Norton、McAfee、Kasperskyといったサードパーティ製品の「つなぎ」程度の扱いだった。Windows XP時代はセキュリティ機能がほぼ存在せず、Windows 7でも本格的な保護には力不足だった。その認識を変えたのがWindows 10であり、Windows 11でそれが完成形に近づいたとMicrosoftは説明する。 現在のWindows Defender（Windows セキュリティ）が提供する機能は以下のとおりだ： リアルタイムスキャン: ファイル・アプリ・プロセスを実行中に継続監視 動作監視（Behavior Monitoring）: 既知のシグネチャに頼らず、異常な挙動を検知 クラウド配信の保護: Microsoftのクラウドと連携し、最新の脅威情報を即時反映 SmartScreen: フィッシング・悪意あるサイトへのアクセスをブロック 自動更新: Windows Updateと連動し、セキュリティインテリジェンスを常に最新に保つ これらは単なるウイルス検出ツールではなく、OSに深く統合されたセキュリティスタックだ。AV-TESTやAV-Comparativesといった独立系テスト機関でも、Defenderはトップ製品と同等のスコアを記録するケースが増えており、「劣っている」という前提はもはや通用しない。 サードパーティ製品が「まだ有効」なケースとは Microsoftは一方的に「Defenderだけで十分」とは言い切っていない。以下のようなケースでは、サードパーティ製品の導入を検討する余地があると説明している： エンタープライズ環境: 集中管理ダッシュボードや高度な脅威検出が必要な場合 ファミリー向け機能: ペアレンタルコントロールやコンテンツフィルタリングを一体提供する製品 IDプロテクション・VPN一体型: セキュリティ以外のプライバシー機能を求めるユーザー これらはDefenderの「代替」ではなく「付加価値」を求めるケースだ。純粋なセキュリティ目的だけであれば、Defender単体で十分という整理になる。 「バンドルアンチウイルス」問題：OEM製品はブロートウェア扱いでよい 興味深いのは、LenovoやHPといったPCメーカーがMcAfeeなどをプリインストールし続けている点だ。これはOEMが販売コスト補填のために商業契約で組み込んでいるものであり、セキュリティ上の必要性からではない。 Microsoftの公式見解は明確だ——「Windows 11はすでにあなたのデータを保護している」。これらのバンドル製品は削除しても問題ない。バックグラウンドサービスの増加、RAMとCPUの消費、複数リアルタイムスキャナーによる競合リスクを考えると、むしろ積極的にアンインストールすることを推奨する。 実務への影響：IT管理者・エンジニアへのヒント 個人・SMB向け 新PC購入後のセットアップ手順として「バンドルAVの削除」を標準化することを検討 DefenderのセキュリティインテリジェンスアップデートとPatch Tuesdayの適用を徹底するだけで、基本的な保護水準は確保できる エンタープライズ向け Microsoft Defender for Endpointを利用している環境では、コンシューマー向けDefenderとは別次元の集中管理・EDR機能が使える サードパーティEDRソリューションと比較検討する際は、ライセンスコストとMicrosoft 365との統合コストを合わせて評価することを推奨する 注意すべき前提条件 「SmartScreenを有効にして信頼できるソースからのみダウンロードする」という前提が守られている場合の話だ。ユーザーが安易に実行ファイルをダウンロードし、警告を無視するような環境では、別途の教育・制御策が必要 Patch Tuesdayの適用についても「すぐ当てたら壊れた」という報告が増えているのも事実。数日様子を見てから適用する判断も、組織によっては立派なリスク管理だ 筆者の見解 セキュリティという領域は正直、細かい話が多くて得意分野とは言いにくい。ただ今回の話は本質的にシンプルだ。 Windows Defenderは以前から実力はあった。問題は「サードパーティ製品を入れておけば安心」という心理的バイアスが根強く残っていたこと、そしてMicrosoft自身がそれを正面から訂正してこなかったことだ。今回のドキュメント公開はその意味で評価できる。 ただ正直に言えば、「もう少し早くできたのでは」という気持ちもある。Windows 10の時代からDefenderの実力は着実に上がっており、独立テスト機関のスコアも十分だった。ユーザーが長年余分なコストを払い、余分なブロートウェアを抱え続けた背景には、Microsoftの発信不足があったはずだ。その点は次への教訓にしてほしい。 「道のド真ん中を歩く」という観点では、OSに統合された標準機能を最大限活用することこそが、再現性が高く管理コストの低いセキュリティ戦略だ。余計なレイヤーを重ねるのではなく、OSが提供するものを正しく使いきる——これが今の時代の答えだと思っている。Microsoftにはその「標準機能の信頼性」をもっと前面に出す発信を続けてほしい。 出典: この記事は Microsoft quietly reveals whether you need a third-party antivirus software in Windows 11 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Metaがサブスク路線を加速——WhatsApp Plusとは何か Metaが旗下のWhatsAppに有料サブスクリプション層「WhatsApp Plus」を追加することを正式に確認した。同社はすでにInstagramでも「Instagram Plus」の提供を開始しており、今回のWhatsAppへの展開はMetaのプラットフォーム全体でのサブスク収益化戦略の一環だ。 これまでWhatsAppは「無料で使える安全なメッセンジャー」という立ち位置を強みとしてきた。だがMetaの収益構造を見れば、広告に依存しないWhatsAppが何らかの形で収益を出す必要があるのは必然だった。サブスクリプション導入は「遅かれ早かれ」という話であり、それが現実になった段階に入ってきた。 どんな機能が含まれるのか 今回確認されたWhatsApp Plusには、無料プランでは利用できないプレミアム機能が含まれる見込みだ。具体的には、より多くのデバイスへの同時接続、高度なビジネス向け機能、AIを活用したコミュニケーション支援などが想定されている。 特に注目したいのがビジネス向け機能の拡張だ。WhatsApp Businessはすでに中小企業を中心に世界中で活用されており、そこに有料層を設けることで「本格的に業務利用したい企業」を取り込む戦略は理にかなっている。 またデバイスリンク機能の強化は、リモートワーク・ハイブリッドワークが定着した現代において実務上の価値が高い。スマートフォン・PC・タブレットを同時に使いながらシームレスにコミュニケーションを取りたいビジネスユーザーには響くポイントだ。 実務への影響——日本のIT管理者が考えるべきこと 日本でのWhatsAppのシェアはLINEに圧倒されており、一般消費者レベルでの影響は限定的かもしれない。しかしグローバルビジネスに携わる企業にとっては話が異なる。 海外拠点・海外取引先との連絡手段としてWhatsAppを利用している企業は少なくない。そうした環境でWhatsApp Plusが提供する機能が「業務効率に直結する差」を生むようになれば、IT部門はライセンス管理・費用計上・セキュリティポリシーの整合性を改めて検討する必要が出てくる。 IT管理者が今すぐ確認すべき点： 現在のWhatsApp Business利用状況の把握: 社員が業務目的でどれだけWhatsAppを使っているか、シャドーIT的な利用がないかを確認する サブスク導入時のライセンス管理方針の策定: 個人端末で業務利用している場合の費用負担・管理責任を明確にしておく コミュニケーションプラットフォームの整理: 「何をどのツールで使うか」の方針を持たないまま有料ツールが乱立すると、全体として非効率で高コストになる 特に3点目は重要だ。TeamsやSlack、LINEやWhatsApp——それぞれに利便性があるのは理解できる。だが統合プラットフォームで全体最適を図るという観点を持たないまま有料サブスクが増えていくと、管理も費用も散らかっていく一方だ。 筆者の見解 MetaがWhatsAppを収益化しようとすること自体は理解できる。問題は「無料だから使い始めた」ユーザーを今後どう扱うかだ。完全無料のままコア機能が維持されるのか、それとも徐々に有料層に誘導するような設計になっていくのか——その匙加減によってユーザーの受け止め方は大きく変わる。 より本質的な問いは、「企業がチャットツールにどこまでお金をかけるべきか」だろう。Microsoft 365を契約している企業はTeamsを既に持っている。追加費用をかけてWhatsApp Plusを導入する前に、まず手元にあるツールをフル活用することを考えてほしい。 とはいえ、グローバルに事業を展開する企業にとってWhatsAppは単なる「代替ツール」ではなく、取引先との関係上「使わざるを得ない」ツールであることも多い。その現実を踏まえ、IT部門は「禁止する」のではなく「安全に・管理できる形で使える仕組みを整える」方向で動くべきだ。禁止アプローチは必ず失敗する。 今回の動きはWhatsAppだけの話ではない。無料で広がったコミュニケーションツールが有料化へと舵を切る流れは今後も続くだろう。そのたびにIT部門が後手に回らないよう、今のうちから「どのツールをどう位置づけるか」の整理を進めておくことを強く勧めたい。 出典: この記事は WhatsApp confirms a Premium subscription tier, here is what it includes の内容をもとに、筆者の見解を加えて独自に執筆したものです。

日常業務でもっとも触れる時間が長いビジネスツール、Microsoft TeamsとOutlookに近く大きな変化が訪れる。UIの刷新、パフォーマンス改善、そしてCopilotを活用したスマート機能の追加——三正面で進む今回のアップデートは、単なる見た目の話ではなく、業務の生産性に直結する変化だ。 Teams：ツールバーの大幅UIリデザイン Teamsのツールバーは、長年にわたってボタンの増殖と整理の繰り返しで、やや混沌とした状態になっていた。今回のリデザインでは、よく使う操作を優先的に前面に出し、使用頻度の低い機能を整理する方向性で進んでいると報じられている。 ビデオ会議中の操作性は特に重要で、マイクミュート・カメラ切り替え・画面共有といった基本操作は反射的に行えるレベルのアクセスが求められる。UIが整理されることで、会議中の「あのボタンどこだっけ」という微細なストレスが軽減されることが期待できる。 Teams：パフォーマンス改善 Teamsのパフォーマンスは以前から改善課題として挙がり続けてきた。旧来のElectronベースから段階的にWebView2ベースへ移行してきた経緯があり、そこからさらなる最適化が進んでいるとみられる。 特に大規模テナントや多数のチャンネルを持つ環境では、起動時間・メッセージ検索の応答速度・会議参加までのロード時間が実務上のボトルネックになりやすい。「使えるが重い」という印象が変わることで、ユーザーの体験は定量的な数字以上に改善される。 Outlook：日常に溶け込むCopilot機能 Outlookには、Copilotを活用したスマート機能が追加されると報じられている。具体的には、メールの要約・返信の下書き支援・スケジュール調整の補助といった機能が日常的な使用シナリオに組み込まれていく方向性だ。 重要なのは「使う気にならなければ意味がない」という点で、今回のアップデートはいわゆる「Copilotボタンを押せば使える」という形ではなく、ワークフローの中に自然に統合される形を目指している点に注目している。ユーザーが意識しなくてもAIの恩恵を受けられる設計こそが、実際の利用率を高める鍵だ。 実務への影響——日本のIT管理者・エンジニアに向けて UI変更後のユーザーサポートを想定しておく TeamsのUIが変わると、必ずといっていいほど「前の画面はどこ行った？」という問い合わせが発生する。変更前に変更点をまとめたガイドを社内展開しておくだけで、ヘルプデスクの負荷を大幅に軽減できる。変更ログはMicrosoft 365のメッセージセンターで事前に確認できるので、管理者はルーティンとして確認しておきたい。 Copilot機能の統合とライセンス管理 Copilotが組み込まれる機能が増えるにつれ、「どのライセンスで何ができるか」の管理が複雑になりやすい。Copilot for Microsoft 365のライセンスを持つユーザーと持たないユーザーで見える機能が異なるケースが出てくる。ライセンスの棚卸しと利用実態の把握を定期的に行う体制を整えておくことを推奨したい。 パフォーマンス改善の恩恵を最大化する Teams本体が軽くなっても、使用しているPCのスペックや社内ネットワーク環境がボトルネックになるケースは引き続き存在する。今回の改善を機に、低スペック端末の洗い出しや、VPN経由のトラフィック最適化（Teams通話をスプリットトンネリングで直接インターネットへ流すなど）を見直す契機にしてほしい。 筆者の見解 TeamsとOutlookは、それぞれの組織における「業務の中枢」だ。ここに地道な改善を積み重ねる姿勢は、Microsoftの本来の強みそのものだと感じる。「最前線の機能」より「毎日使うものが確実に動く」ことの方が、実際のビジネスへのインパクトははるかに大きい。 パフォーマンス改善は特に歓迎したい。UIの斬新さよりも「起動が速い」「会議に迷わず入れる」という体験の方が、末端ユーザーの満足度に直結する。Copilot機能についても、「使わされる」のではなく「気づいたら使っていた」という自然な統合が実現できれば、これまでのAI機能とは異なる評価を得られるはずだ。 Microsoftには、こういうことを地道にやり続ける技術力と実績がある。総合プラットフォームとしての競争力を発揮できるのは、まさにこういう積み上げの積み重ねからだ。今後のロールアウト状況も引き続き注視していきたい。 出典: この記事は Microsoft Teams and Outlook are getting significant changes soon の内容をもとに、筆者の見解を加えて独自に執筆したものです。

何が起きたのか GitHubが、Copilotの新規サインアップを一時停止した。同時に、使用量制限の新設と、一部のAIモデルのラインアップからの削除も実施された。理由として挙げられているのは、AIエージェントを活用した開発スタイルの普及による需要の急増と、それに伴うインフラコストの高騰だ。 ここ数ヶ月で、Copilotは単なるコード補完ツールから、エージェントとして自律的にタスクをこなすプラットフォームへと急速に進化している。ユーザーがエージェントモードを積極的に活用し始めた結果、1ユーザーあたりのAPIコール数・トークン消費量がケタ違いに跳ね上がった——それが今回の事態の根本原因だ。 技術的背景：エージェントが変えたコスト構造 従来のAIアシスタント型の使い方（補完・チャット）と、エージェント型の使い方（タスクの自律実行・ループ処理）では、インフラへの負荷がまったく異なる。 補完・チャット: ユーザーがトリガーし、1回のやり取りで完結 エージェントモード: モデルが自律的に複数ステップを繰り返し実行し、ツールを呼び出し続ける エージェントが「考え続ける」間、バックエンドのモデル推論は常時走り続ける。これが積み重なると、トークン消費量はコード補完時の何十倍にもなる。GitHubが想定していたスケールを大きく上回ったのは想像に難くない。 使用量制限の新設と、削除されたモデル 今回の措置として、GitHubは使用量の上限を設ける制限を導入した。また、ラインアップに含まれていた一部のサードパーティモデルがCopilotから削除されている。無制限利用を前提として設計されたプランが、エージェント時代のコスト構造に合わなくなってきた——その現実への対応と見るのが自然だ。 実務への影響——日本のエンジニア・IT管理者へ 現時点で既存ユーザーは引き続きCopilotを利用できる。ただし、以下の点は今後の利用計画に織り込んでおく必要がある。 1. エージェントモードの使いすぎに注意 Copilotのエージェント機能を積極活用しているチームは、使用量上限に抵触するケースが出てくる可能性がある。どのワークフローでエージェントを回しているかを把握し、不要な自動実行がないか見直しておこう。 2. 新規導入計画の見直し サインアップが再開されるまでの期間は不明だ。Copilotの導入を検討中のチームは、展開時期の計画を調整する必要がある。 3. モデル選択の柔軟性を見直す 削除されたモデルを特定用途で使っていた場合は、代替モデルへの切り替えを検討する時期だ。特定モデルに強く依存したプロンプト設計は、こうした変更に脆弱になる。 4. コスト意識の設計 エージェント型AI開発は「便利」と引き換えに計算リソースを大量消費する。組織で導入する際には、使用量の可視化・予算の上限設定を必ずセットで考えること。 筆者の見解 正直に言う。GitHubのこの判断自体は、おかしくない。むしろ現実的だ。 エージェント型AIが普及するに連れ、プラットフォームのコスト構造が根本から変わってきている。「使い放題」で提供し続けることが困難になった——これはGitHubに限った話ではなく、AI開発ツールを提供するすべてのベンダーが直面している問題だ。需要の爆発に対してサプライサイドが追いつかなくなることは、むしろ想定内の未来だった。 ただ、気になる点もある。GitHubは「需要が急増している」と言う。これはつまり、Copilotが実際に使われている証拠でもある。開発者がエージェント機能を積極的に活用し始めている——これはポジティブなシグナルだ。そのうねりをうまく受け止めるインフラ設計と価格モデルへの移行を、スムーズに進められるかどうかが問われている。 MicrosoftとGitHubには、エンタープライズ規模のインフラを運営してきたノウハウがある。この一時的な混乱を乗り越えて、エージェント時代に見合ったスケーラブルなサービスとして再整備してほしい。それができる体力と技術力は持っているはずだ。 エージェント駆動の開発スタイルは、もう後戻りしない。プラットフォームがそれに対応した設計へ進化するための「成長痛」と前向きにとらえたい。 出典: この記事は GitHub halts new Copilot signups amid soaring usage and rising costs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Apple App Storeは「安全なエコシステム」として長年信頼されてきた。しかしそのApp Storeに、MetaMask・Coinbase・Trust Wallet・OneKeyなどの人気暗号資産ウォレットを装った偽アプリが26本も紛れ込んでいたことが明らかになった。発見したKasperskyは一連の攻撃を「FakeWallet」キャンペーンと命名し、昨年から続く「SparkKitty」作戦との関連を指摘している。 攻撃の巧妙な多段構造 今回の攻撃が興味深いのは、単純な偽アプリにとどまらない点だ。中国では暗号資産関連アプリが規制されているため、攻撃者はまず「ゲームアプリ」や「電卓アプリ」として申請・審査を通過させた。ユーザーが起動すると、合法的なサービスに見せかけたフィッシングページへリダイレクトされる。 ここからが本番だ。そのページは被害者に「iOS プロビジョニングプロファイル」のインストールを促す。プロビジョニングプロファイルとはAppleが企業内配布用に用意した正規の仕組みであり、これを悪用することでApp Store外のトロイの木馬入りアプリをデバイスにサイドロードできてしまう。 インストールされたトロイの木馬は、ウォレットのセットアップ画面や復元画面でニーモニックフレーズ（シードフレーズ）を傍受し、RSAとBase64で暗号化して攻撃者のサーバーへ送信する。Ledgerのようなコールドウォレットの場合は、アプリ内に「偽のセキュリティ確認画面」を表示し、ユーザー自身にシードフレーズを入力させるフィッシング手口も使われた。 シードフレーズが「詰み」な理由 暗号資産ウォレットのシードフレーズ（通常12〜24個の英単語）は、秘密鍵そのものを表す主鍵だ。これを知られた瞬間、攻撃者は別のデバイスでウォレットを完全に復元し、残高を全額別アドレスへ移転できる。パスワードリセットもサポートへの連絡も意味をなさない。ブロックチェーンの不変性が、この局面では被害者に対して働く。先週も偽Ledgerアプリによる950万ドル相当の被害が報じられたばかりだ。 「公式ストアだから安全」という思い込みの危険性 AppleはKasperskyからの報告を受けて26本のアプリをすべて削除したが、今回の件はApp Storeの審査プロセスに対する楽観的な信頼を見直すきっかけになるべきだ。「ゲームアプリ」として申請し、起動後にふるまいを切り替えるという手法は今後も繰り返されるだろう。 Kasperskyは今回のキャンペーンが中国ユーザーを主な標的としているとしつつも、マルウェア自体に地理的な制限はないと指摘している。日本の暗号資産ユーザーも対岸の火事として見過ごすべきではない。 実務への影響——IT管理者・エンジニアが今すぐできること 個人ユーザー向け ウォレットアプリは必ず公式サイトからリンクをたどってダウンロードする。App Storeの検索結果を信用しない プロビジョニングプロファイルのインストール要求は、企業MDM以外では原則拒否する シードフレーズはデジタルデバイスに保存しない。紙に書いてオフラインで管理するのが鉄則 企業・IT管理者向け 従業員が業務端末で暗号資産ウォレットアプリを使う可能性を想定し、MDMポリシーでプロビジョニングプロファイルの無断インストールをブロックする モバイルデバイス管理（MDM）未導入の環境では、今回のような攻撃を防ぐ手段がほぼない。MDM導入は急務だ フィッシング対策教育の題材として、本件を社内勉強会で取り上げることをすすめる 筆者の見解 Apple App Storeのサンドボックスモデルは堅牢だが、「プロビジョニングプロファイル」という企業向け正規機能を経路として使われると、プラットフォームの防御機構を合法的に迂回できてしまう。これはAppleだけの問題ではなく、あらゆる「信頼された機能」が攻撃の踏み台になりうるというゼロトラスト的な問題だ。 「公式ストアからインストールしたから安全」という前提は、もはや成立しない。信頼の起点をデバイスやストアに置くのではなく、「そのアプリがどのような動作をするか」「どこへ通信しているか」をエンドポイントレベルで継続的に検証する発想が必要だ。 暗号資産の世界は「自己責任」が基本設計であるため、一度シードフレーズを渡してしまったら取り返しがつかない。技術的な保護の限界を補うのは、結局のところ「ユーザー自身が原理を理解しているかどうか」だ。ウォレットを使うなら、シードフレーズがなぜ絶対に共有してはいけないのかを理解した上で使ってほしい。知識こそが最強の防御壁だ。 出典: この記事は China’s Apple App Store infiltrated by crypto-stealing wallet apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。

4月のPatch Tuesdayが終わって一息ついたのも束の間、Windows Server環境を管理しているエンジニアは週明けから厳しい状況に直面している。Microsoft自身が「緊急（Out-of-Band）」と位置づける帯域外更新プログラムを複数バージョン向けに公開した。影響範囲がドメインコントローラーという基幹インフラに及んでいるため、特にオンプレミスのActive Directory環境を持つ企業は早急な対応が求められる。 何が起きているのか——2つの深刻な不具合 今回の緊急パッチが対処する問題は大きく2つある。 1. LSASS クラッシュによるドメインコントローラーの再起動ループ 最も深刻なのが、Local Security Authority Subsystem Service（LSASS）のクラッシュだ。4月の累積更新プログラムを適用したドメインコントローラーが起動直後に再起動を繰り返すという症状で、既存のドメインコントローラーだけでなく、新規セットアップ中のサーバーでも発生し得る。LSSASSは認証処理の中核を担うコンポーネントであり、これが落ちるということは認証基盤そのものが止まることを意味する。Active Directoryに依存したシステム全体へのカスケード障害リスクを考えると、迅速な対処が必須だ。 2. Windows Server 2025 での KB5082063 インストール失敗と BitLocker 復旧問題 Windows Server 2025 では、4月のセキュリティ更新プログラム（KB5082063）のインストール自体が失敗するケースが報告されていた。さらにインストールが通った場合でも、BitLockerの回復モードに入り、ユーザーに回復キーの入力を求める事態が発生している。本番環境で突如BitLocker回復画面が出るのは運用担当者にとって悪夢でしかない。 緊急OOBパッチの適用対象バージョンと KB 番号 今回 Microsoft が公開した緊急更新プログラムは以下の通りだ。 バージョン KB番号 OSビルド Windows Server 2025 KB5091157 26100.32698 Windows Server, version 23H2 KB5091571 25398.2276 Windows Server 2022 KB5091575 20348.5024 Windows Server 2019 KB5091573 17763.8647 Windows Server 2016 KB5091572 14393.9062 Windows Server 2025 Datacenter: Azure Edition（Hotpatch） KB5091470 26100.32704 ...

2026年4月のPatch Tuesdayは、企業のセキュリティ担当者にとって「静かに見過ごせる月」ではなかった。修正された脆弱性は167件に上り、過去最大規模。うち11件がCritical、さらに2件がゼロデイ（既に悪用確認済み）という内容だ。加えて、2026年6月26日という具体的なデッドラインが設定されたSecure Boot証明書の失効問題まで重なり、対応の優先順位付けが例月以上に重要になっている。 今回の目玉：2つのゼロデイを押さえる ① RDPリモートコード実行（CVE未公表 / 悪用確認済み） リモートデスクトッププロトコル（RDP）に、未認証のまま任意コードを実行できる脆弱性が確認された。攻撃経路はフィッシングメールによる悪意ある .rdp ファイルの配布だ。ユーザーがそのファイルを開くだけで、接続設定が悪用される。 April更新では、.rdp ファイルを初回起動した際にセキュリティ警告を表示し、接続設定をデフォルト無効にする変更が加えられた。「なぜ今まで警告がなかったのか」という声も出そうだが、まずは緩和策として評価できる対応だ。 即応ポイント： 外部からの .rdp ファイルをメールで受け取った際の取り扱いポリシーを周知する RDPを外部公開している環境は、今すぐ適用を最優先にする ② Windowsカーネル特権昇格（CVE未公表 / 悪用確認済み） ローカルの攻撃者やマルウェアがSYSTEMレベルへの権限昇格を行える脆弱性。初期侵害の後段で組み合わせて使われる「マルチステージ攻撃」のパーツとして使われることが多い。EDR（Endpoint Detection and Response）が完全展開されていない環境、またはラテラルムーブメントが可能なフラットネットワーク環境では特に危険度が高い。 Secure Boot証明書失効：6月26日という外せないデッドライン 今回のパッチで最も長期的な影響を持つのが、Secure Boot証明書の失効問題だ。 2011年に発行されたSecure Bootのレガシー証明書は、2026年6月26日を以てWindows Boot Managerのセキュリティ更新対象外となる。これはつまり、旧証明書に依存したままの環境では、それ以降のブートレベルのパッチが適用されなくなる。 ブートキットマルウェア「BlackLotus」（CVE-2023-24932）はその典型的な攻撃先だ。4月の更新では新証明書への段階的移行とWindows Security アプリへのSecure Bootステータス表示が追加されており、管理者が現状把握できるようになった。 確認すべきこと： Windows Securityアプリ→「デバイスセキュリティ」でSecure Bootの状態を確認 WSUS・Intune管理環境ではデバイスのSecure Boot対応ステータスをレポートとして収集する Windows 10を継続利用している企業は、6月が事実上のマイグレーション期限になる点を意識する その他の注目脆弱性 コンポーネント 種別 CVE 概要 SQL Server 特権昇格 CVE-2026-32167 DB管理権限の奪取リスク PowerShell セキュリティ機能バイパス 複数 スクリプト実行制御の回避 Windows Snipping Tool RCE CVE-2026-32183 画像処理経由のコード実行 LSASS 情報漏洩 CVE-2026-26155 認証情報の漏洩リスク ...

サポートが終了したWindows 10を業務で継続利用している組織にとって、Extended Security Updates（ESU）プログラムは今やライフラインだ。2026年4月14日、そのESUプログラム経由で5回目となるセキュリティ更新「KB5082200」（ビルド 19045.7184）が配信された。新機能こそないが、現場で実害の出ていた問題への対処と、Secure Boot周りの地道な改良が含まれる。 ESUプログラムとは——まだ間に合う有償延命策 Windows 10の標準サポートは2025年10月14日に終了した。しかしMicrosoftはESUプログラムにより、2026年10月まで月次セキュリティ更新を提供し続けている。現時点でも登録受付中であり、移行計画が遅れている組織には現実的な選択肢となっている。 今回のKB5082200は22H2および21H2（ビルド 19044.7184）の両バージョンに適用される。 今回の主な修正・改善 RDPファイルを悪用したフィッシング攻撃への対策 注目したいのがRemote Desktop（RDP）まわりの改善だ。.rdpファイルを開く際、接続先のサーバー名やリソース情報などすべての接続設定を接続前に表示するようになった（デフォルトはオフ）。また、デバイス上で初めて.rdpファイルを開いたときに一度だけセキュリティ警告が表示される。 これは昨今増加している「悪意ある.rdpファイルをメールで送りつけ、クリックさせて接続させる」系のフィッシング手口への直接的な対処だ。.rdpファイルを安易にダブルクリックする習慣がある現場では、この設定を有効化することを強く推奨する。 Microsoftアカウントでのサインインエラー修正 2026年3月10日以降の更新を適用した一部環境で、Microsoft Teamsなどのアプリにサインインしようとすると「インターネット接続なし」という誤ったエラーが表示され、サインインできなくなる問題が発生していた。今回の更新でこの問題が解消されている。該当症状に悩まされていた組織はすみやかに適用したい。 Secure Boot証明書管理の透明性向上 Secure Boot関連では複数の改善が盛り込まれた。Windowsセキュリティアプリ上でSecure Boot証明書の更新状況がバッジや通知として確認できるようになり、「今どういう状態か」が視覚的に把握しやすくなった。 また、品質更新プログラムによって「新しいSecure Boot証明書を受け取るのに適した状態かどうか」をより正確に判定するためのターゲティングデータが改善されている。これにより、更新の実績が安定しているデバイスにのみ自動で証明書が配布されるようになる。 さらに、Secure Boot更新後に一部デバイスが予期せずBitLockerリカバリーモードに入ってしまう問題も修正された。BitLockerが突然リカバリーキーを求めてきて現場が混乱する——そういった事態を未然に防ぐ意味で重要な修正だ。 旧バージョン向け更新も同時公開 1809向けにKB5082123（ビルド 17763.8644）、1607向けにKB5082198（ビルド 14393.9060）も配信されている。PowerShell・Kerberos・Windows Deployment Servicesなど、サーバー系インフラでよく使われるコンポーネントの修正も含まれる。 実務への影響——日本のIT管理者が今週すべきこと ① RDPファイルの取り扱いポリシーを見直す .rdpファイルによるフィッシングは、テレワーク環境が広がった日本の現場でも現実のリスクだ。今回の更新で追加された「接続前に設定を表示する」オプションを有効化するグループポリシーの適用を検討したい。 ② BitLockerリカバリーキーの保管状況を確認する Secure Boot更新に絡むBitLockerリカバリー問題が修正されたとはいえ、万が一のために全端末のリカバリーキーがAzure ADまたはActive Directoryに正しくエスクローされているかを確認しておく機会として活用しよう。 ③ ESU登録状況の確認と予算確保 2026年10月のESU終了まで残り約半年。Windows 11への移行計画が固まっていない組織は、ESUの延長可否（Year 2プログラムは存在しない点に注意）も踏まえ、今のうちにロードマップを再確認しておきたい。 筆者の見解 Windows 10のESU更新を細かく追うこと自体、本来は避けたかった作業だ。しかし現実には、日本のエンタープライズ環境の多くでWindows 10が現役であり続けている。「OSのサポート期限」と「業務要件や予算」の間で板挟みになっているIT管理者が多いことは承知している。 そんな状況だからこそ、今回のRDP周りの改善は素直に評価したい。.rdpファイルを使ったソーシャルエンジニアリング攻撃は手口が単純なわりに刺さりやすく、対策が後手に回りがちだった。接続設定を事前表示する仕組みは地味ではあるが、現場への啓発とセットで使えば効果的だ。 Secure Boot証明書のターゲティング精度向上とBitLockerリカバリー問題の修正も、堅実な改善だと思う。こういう「見えないところで信頼性を積み上げる」系の作業をMicrosoftがきちんとやっていることは、率直に認めたい。 ただ、大局的に言えば、Windows 10をESUで延命し続けることは「時間を買っている」に過ぎない。OSの移行は面倒で予算もかかるが、Windows 10上で積み上げてきた技術的負債を2026年10月以降に持ち越すコストの方が確実に大きい。ESUを使いながら、並行してWindows 11への移行計画を具体化する——それが今、IT管理者に求められる現実的な動き方だと思う。 出典: この記事は KB5082200 (build 19045.7184) for Windows 10 ESU drops as the April 2026 update の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Windows 11のスタートメニューに対してユーザーから寄せられてきた根強い不満に、Microsoftがついて正面から向き合う姿勢を見せた。同社のデザイン部門のパートナーディレクターであるMarch Rogers氏がX（旧Twitter）上で、スタートメニューの追加カスタマイズオプションを現在開発中であると明言した。 何が変わるのか Rogers氏の発言は端的だ。「お客様の声を聞き、アプリへのアクセスを改善した。現在、さらなるカスタマイズオプションを開発中だ」。具体的な機能の詳細は明かされていないが、同氏は以前から社内で検討されていた複数のスタートメニューデザイン案（プロトタイプ）も合わせて共有した。 今回の発表の背景にあるのは、Windows 11に導入された「カテゴリ」機能への強烈な反発だ。この機能はアプリを「エンターテインメント」「ソーシャル」「クリエイティビティ」などのグループに自動分類する。分類ロジックは15MBのJSONファイルをローカルで参照する仕組みで、Microsoftのサーバーへの通信は発生しない。ただし、アプリの識別はパッケージファミリー名に依存しており、対応していないアプリは「その他」に押し込まれてしまう。 ユーザーからは「カテゴリを自分で定義できなければただのゴミ」という率直なフィードバックも寄せられており、Feedback Hubでも上位の要望として挙がっている。「なぜこれが現在の状態で本番投入されたのか理解できない」とまで書かれた投稿があるほどだ。 また、Microsoftはスタートメニューの内部実装をWinUI（Windows UI Library）へ移行する作業も進めており、今後のUI刷新の基盤整備が同時に進んでいることがわかる。 実務への影響 企業のIT管理者やエンジニアにとって、スタートメニューのカスタマイズ性向上は直接的な影響がある。 グループポリシー・Intuneとの連携を見据えた準備: カスタマイズオプションが拡張された場合、MDM（Intune）やグループポリシーによる一元管理のスコープも広がる可能性が高い。現時点でスタートメニュー関連のポリシー設定を整理しておくと、展開後の対応が楽になる エンドユーザー教育のコスト低減: カテゴリ機能が使いやすくなればアプリ探しの問い合わせが減る。ヘルプデスクの負荷軽減という実利もある カスタマイズは「ユーザーが困っていないか」から逆算する: Microsoftの新オプションが出た際にすぐ全展開するのではなく、自社ユーザーの実際の行動を確認してから適用範囲を判断したい 筆者の見解 正直なことを言えば、スタートメニューの細部を追い続けることにかつてほどの熱量を感じなくなっている自分がいる。それでもこのニュースに一定の意味があると思うのは、Microsoftが「フィードバックを聞いていた」という事実を公式に認めた点だ。 カテゴリ機能は、設計段階でユーザーの実際の使い方を十分に検証できていなかったように見える。「作ったものを使わせる」ではなく「使い方を観察してから設計する」というプロセスの大切さを改めて感じる。MicrosoftにはWindowsという巨大なユーザーベースがあり、それを活かしたフィードバックループを回せる力が本来はある。今回のような「聞いていた、動いている」という発信をもっと早く、もっと具体的にやっていれば、ここまで反発は大きくならなかったはずだ。 スタートメニューの全面刷新ではなく「現行レイアウトの改善」という方向性は、現実的な判断だと思う。大幅な変更はエンタープライズ環境での混乱を招きやすい。ユーザーが「あ、使いやすくなった」と自然に感じられる程度の変化を積み重ねていく方が、長期的には信頼につながる。Microsoftにはそういう丁寧な仕事ができる力があるのだから、ぜひそれを見せてほしい。 出典: この記事は Microsoft teases new customization features for Windows 11’s Start menu after years of criticism の内容をもとに、筆者の見解を加えて独自に執筆したものです。

IntelがDDR5コスト問題に正面から挑む DDR5メモリの普及を阻む最大の壁のひとつが「価格」だ。性能面ではDDR4を大きく凌駕するものの、コスト差がエンタープライズ・コンシューマー双方での導入障壁になってきた。そこにIntelとパートナー企業が、DDR5を低コストで実現する新たなアプローチを開発中というニュースが飛び込んできた。ただし、この技術がAMDプラットフォームでは使えない可能性があり、エコシステムの分断という副作用も懸念される。 技術の核心：モジュール設計の「賢いコスト削減」 報道によれば、IntelはDDR5モジュールの構成方法に工夫を加えることで、同等性能を維持しながら製造コストを下げる手法を模索している。DDR5はDDR4と比べて電源回路の設計が複雑で、PMIC（電源管理IC）がモジュール側に搭載されるなど、部品点数が増加しやすい構造を持つ。この部分を再設計・簡略化することで、コスト構造を大きく変えようというアプローチだ。 重要なのは、これが単なる「チープ化」ではないという点だ。メモリの基本仕様（速度・信頼性）を維持しながら、設計の合理化でコストを下げる——エンジニアリング的には正攻法といえる。 「Intel専用」になりうる理由 問題はこの技術がIntelプラットフォームに最適化された形で実装される可能性が高いことだ。IntelはCPUとチップセット、メモリコントローラーを含むプラットフォーム全体を自社設計している。メモリの挙動に関わる仕様変更は、CPUのメモリコントローラーとの連携が必要なケースが多く、AMDのRyzenやEPYCプロセッサが同じ仕様に対応するかどうかは現時点では不透明だ。 AMDが対応しない場合、メモリ市場は「Intel対応の低コストDDR5」と「既存の汎用DDR5」に分かれることになる。この分断はメーカー・流通・エンドユーザー全員にとって頭痛の種になりうる。 実務への影響：日本のIT現場で考えておくべきこと サーバー・ワークステーション調達の担当者へ Intelプラットフォームでの新規調達を検討中であれば、この技術が正式に仕様化されるタイミングを待つ価値がある。DDR5搭載システムのコストが下がれば、総所有コスト（TCO）の試算も変わってくる。ただし、急ぎの調達であれば現行の汎用DDR5で問題ない。 AMD環境を使っているチームへ 現時点ではAMDプラットフォームへの対応は不明確だ。AMDのThreadripperやEPYCを使用しているサーバー環境では、この「安いDDR5」の恩恵を受けられない可能性を念頭に置いておこう。今後のAMDのアナウンスを注視する必要がある。 PCライフサイクル管理の観点 DDR5の価格が下がれば、Windows 11移行やPC更新のサイクルに影響が出る。特にDDR5対応CPUへの移行コストが下がることで、企業のPC更新計画を前倒しする判断がしやすくなる可能性がある。 筆者の見解 Intelのこのアプローチは、技術的には真っ当だと思う。「より良いものを、より安く」——シンプルだが、それが一番難しい。奇をてらわず、設計の合理化でコストを下げるというのは「道のド真ん中を歩く」手法であり、長期的に普及しやすいアーキテクチャになる可能性がある。 一方で、「Intel専用」という状況が生まれることへの懸念は正直にある。メモリは本来、プラットフォームを超えた汎用品であることに価値がある。「安くなったけどIntelでしか使えない」では、採用を検討する際の複雑さが増す。特に、IntelとAMDを混在させているデータセンター環境では調達管理が煩雑になりかねない。 Intelには、もしこの技術が実用化されるなら、業界標準として仕様をオープンにする道も探ってほしいと思う。Intelは技術力でも製品力でも十分に競争できる会社だ。囲い込みではなく、標準化によってエコシステム全体を引き上げる——そちらのほうが長期的なブランド価値にもつながるはずだ。 正式な仕様発表と、主要メモリベンダー（Samsung・SK Hynix・Micron）の対応表明が次の注目ポイントになる。 出典: この記事は New clever way to make cheap DDR5 RAM may be Intel-exclusive only with no AMD support の内容をもとに、筆者の見解を加えて独自に執筆したものです。

CachyOS がパフォーマンス志向の Linux 7.0 カーネルをリリースした。同ディストリビューションは Arch Linux をベースに、独自のカーネルパッチ群を組み合わせることで一般的なカーネルとは一線を画すパフォーマンスを実現してきた。今回のリリースは、その路線をさらに推し進めたものだ。 CachyOS とは何者か CachyOS（「キャッシュOS」と読む）は、x86_64 向けに高度に最適化されたバイナリを提供するアーキテクチャを持つ Linux ディストリビューションだ。一般的な汎用バイナリではなく、x86-64-v3 や x86-64-v4 といった新しい命令セットをフルに活用したコンパイル済みパッケージを配布している。つまり、最新世代の CPU を持つユーザーは、ソフトウェアの実力をより引き出せる環境で動作できる。 カーネルには BORE（Burst-Oriented Response Enhancer）スケジューラーなど複数のアップストリーム未マージパッチを適用しており、レスポンスの良さとスループットのバランスを取りながら、ゲーミングや動画編集といった重負荷ワークロードに強い設計となっている。 Linux 7.0 カーネルの主な変更点 今回の Linux 7.0 ベースのカーネルでは、新規ドライバーの追加と既存ドライバーの更新が行われており、最新世代のGPU・NIC・ストレージコントローラーへの対応が強化された。合わせてパッケージリポジトリ全体がリフレッシュされ、依存関係の一貫性も改善されている。 スケジューラーの調整も継続されており、マルチコア環境でのコア間負荷分散が洗練されている。特にコアを大量に積んだ最新のデスクトップ・ワークステーション CPU では、タスクの割り当て効率が体感レベルで改善するケースがあるとされる。 実務への影響——日本のエンジニアが注目すべき点 開発・CI 環境としての Linux 選定が変わる可能性がある。コンテナビルドや大規模なコンパイルジョブを日常的に回している開発チームにとって、カーネルレベルのスケジューラー最適化は積み重なると無視できない差になる。標準的な Ubuntu LTS や RHEL 系と比較したベンチマークを自チームの環境で取ってみる価値はある。 ゲーミング PC としての Linux も現実味が増している。Steam Deck の普及以降、Proton 経由での Windows ゲーム動作は当たり前になった。CachyOS のようなパフォーマンス志向カーネルはこの用途と非常に相性が良く、エンジニアがプライベート用途で「試しやすい選択肢」として選ばれる機会が増えている。 ただし、安定性とトレードオフがある点は理解しておきたい。アップストリーム未マージのパッチを複数重ねた構成は、エッジケースで予期しない挙動を引き起こすことがある。本番サーバーへの適用は慎重に検討すべきで、まずは開発・テスト用マシンで評価するアプローチが王道だ。「道のド真ん中」を歩くなら、本番は LTS カーネルで、パフォーマンス探求は専用機で、という棲み分けが無難である。 筆者の見解 Linux のカーネル開発において、こうした「体験重視の最適化ディストリビューション」が活発になっている流れは興味深い。汎用カーネルと実際のユースケース最適化カーネルのギャップを埋める試みは、Windows と Linux の双方で今後も加速するだろう。 翻ってみると、OS そのものの進化よりも「誰がどのワークロードに何を使うか」の選択肢が増えることの方が、今の現場にとってははるかに重要になってきている。細かいカーネルバージョンを追いかける価値自体が薄れつつある一方で、「自分のワークロードに本当に合った環境を選ぶ」という判断力はエンジニアに今まで以上に求められる。 CachyOS のアプローチは、標準から外れたチューニングを恐れないヘビーユーザー向けの一つの回答として、今後も参照される事例であり続けるだろう。自動化の仕組みを作る立場のエンジニアこそ、自分の手元の環境を最適化する意欲を持ち続けてほしい。 出典: この記事は CachyOS has released a performance oriented Linux 7.0 kernel の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2026年4月のPatch Tuesdayとして配信されたWindows 11向け累積更新プログラム KB5083769 に、いくつかの注意すべき挙動が確認されている。「大きな更新ではない」とされながらも、BitLocker回復画面の表示やインストール中の複数回再起動といった事象が一部デバイスで発生しており、Microsoftも公式に認知・対応を進めている状況だ。 何が起きているのか 複数回の再起動 通常、Windows Updateのインストールは1〜2回の再起動で完了する。ところが今回のKB5083769では、インストール完了まで合計4回程度の再起動を要するケースが報告されている。「Working on updates」画面で72%前後まで進んだあと、そこから追加で複数回リブートするという動作だ。 Microsoftはこの事象を調査中としており、同日（4月14日）に展開された**.NET Frameworkの更新プログラムが同時適用されることで再起動が増える可能性を指摘している。バグなのか意図的な動作なのかは現時点で確定していないが、処理が完全に終わる前にシャットダウンするのはリスクがあるため、更新中は電源を切らず待機する**ことが重要だ。 インストールエラー 一部のデバイスでは以下のエラーコードでインストールに失敗するケースも確認されている： 0x800736b3 0x800f0991 0x800f081f 0x800719e4 0x800f0823 0x80071a2d Lenovo Yoga Slim 7xなど特定機種でも適用できないという報告がある。 BitLocker回復画面の表示 今回の問題で最も注意が必要なのが BitLocker回復画面 の発生だ。更新プログラム適用後に突然、Windowsドライブの回復キーを求められる事象が起きている。 Microsoftが公開した情報によると、影響を受けるのは以下の条件をすべて満たすデバイスに限られる： BitLockerがWindowsドライブに対して有効になっている グループポリシー「ネイティブUEFIファームウェア構成のTPMプラットフォーム検証プロファイル」が有効化されている msinfo32.exe のSecure Boot State（PCR7）が 「Not Possible」 の状態である つまり、推奨されていないBitLockerグループポリシー設定を持つ環境が対象となる。MicrosoftはすでにサーバーサイドでのFix（修正）を展開済みであり、これにより影響を受けるPCでも正常にインストールできるようになっているとしている。 実務への影響——IT管理者が今すぐ確認すること エンタープライズ環境でのチェックリスト Microsoft自身が「更新適用前に確認してほしい」と明示している手順がある： グループポリシーの監査: BitLocker設定でPCR7を明示的に含む設定になっていないか確認する msinfo32.exe で状態確認: 「Secure Boot State」の欄でPCR7バインディングのステータスをチェックする 回復キーの事前バックアップ: 念のためActive DirectoryまたはAzure ADに回復キーがエスクローされているか確認する BitLockerの回復画面が出てしまった場合でも、回復キーさえあればデータは守られる。逆に言えば、回復キーを紛失している状態のまま更新を適用するのは大きなリスクだ。 個人・中小規模環境での対応 BitLockerをデフォルト設定のまま有効化しているデバイスは、今回の問題には該当しない可能性が高い。ただし、複数回再起動の事象は環境を選ばず発生しうるため、更新中は席を離れず、電源断やスリープに注意するだけで十分な対策になる。 また、エラーコードが出てインストールに失敗する場合は、Windows Update > 詳細オプション > オプションの更新 を確認したうえで、数日待ってから再試行するのが現実的だ。 筆者の見解 「更新プログラムをすぐに当てたら壊れた」という声はここ数年で確実に増えている。今回のKB5083769のように、Microsoftが問題を認知してサーバーサイドFix済みと発表していても、適用タイミング次第でBitLocker回復画面に遭遇する可能性はゼロではない。 セキュリティ更新は速やかに当てるべきというのは原則として正しい。しかし「数日様子を見てから適用する」という判断も、立派なセキュリティ運用のひとつだ。特にエンタープライズ環境では、Patch Tuesday直後に全端末への即時展開を急ぐよりも、パイロットグループで検証してから段階的に展開するアプローチが結果的に安全で安定している。 BitLockerの問題について言えば、今回のトリガーは「推奨されていないグループポリシー構成」だった。よく言われることだが、「推奨構成」には理由がある。ベンダー推奨の設定を逸脱した構成は、こうした更新のたびに思わぬ落とし穴になりうる。 Windowsを深く追い続ける意味が薄れているとはいえ、こういったセキュリティ更新に関わる挙動はIT管理者として把握しておく価値がある。特にBitLockerとTPM・UEFI・Secure Bootの関係は、管理端末が増えるほど影響範囲が大きくなる。msinfo32.exe を開いてPCR7のステータスを確認する習慣をチームで持っておくことを勧めたい。 ...

「パフォーマンスと信頼性」宣言、いよいよ形になる Microsoftは約1ヶ月前、Windows 11の開発方針として「パフォーマンス・信頼性・丁寧に作り込まれた体験」へ集中すると公言した。そして今、その約束が実際のInsiderビルドとして形になりつつある。 Release PreviewチャンネルやBeta・Dev・Canaryの各チャンネルに順次展開中のビルドには、File Explorer・explorer.exe・タスクバー・設定アプリ・クリップボード履歴・入力システム・Windows Helloにわたる包括的な信頼性修正が含まれている。特にRelease Previewに取り込まれた変更は、4月のオプション更新を経て5月のセキュリティ更新として一般ユーザーに届く見込みだ。 主な信頼性改善 10項目 1. File Explorerの高速化と安定化 Windows 11のFile ExplorerはWindows 10と比較して明らかに遅く、プリロードを有効にしても差が縮まらないという声が多かった。今回のRelease Previewビルドでは起動速度が向上し、ダークモード時に発生していた白い背景の一瞬の点滅（白フラッシュ）も解消されたと報告されている。 File Explorerは純粋なWinUI 3アプリではなく、Win32コアにXAML Islandsを組み合わせたハイブリッド構成だ。内部実装の詳細は公開されていないが、この構造に起因する諸問題が着実に潰されている印象を受ける。 さらに、カスタマイズしたフォルダービューが他アプリから開いた際にリスト表示にリセットされてしまう問題も修正対象となっている。「ダウンロードフォルダをエクストララージアイコン表示にしているのに、ブラウザ保存後に開くとリスト表示になる」という、地味だが繰り返し遭遇してストレスが溜まるあの挙動だ。 2. explorer.exeの包括的な安定化 explorer.exeはWindowsのグラフィカルシェル全体を管理するプロセスであり、ここが不安定だとデスクトップ操作全般に影響が出る。今回の修正はログイン時・タスクバーフライアウト操作時・タスクビュー使用時・クイックアクセスからのアイテム削除時に集中しており、File Explorerウィンドウを閉じた後にexplorer.exeが予期せず停止するケースも抑制される。 3. タスクバーとシステムトレイの安定化 システムトレイ（通知領域）のアイコンが表示されないケースが減少するとされており、タスクバー全体の信頼性向上につながる。地味な改善だが、常駐アプリの状態を確認できないと現場の作業効率に直結する。 4. 設定アプリのナビゲーション改善 「設定 > アプリ > インストール済みアプリ」ページは全アプリの一覧取得・アイコン取得・ストレージ使用量計算が重なるため、ロードに時間がかかることで知られていた。今回はこの画面への遷移パスが安定化される。 「設定 > プライバシーとセキュリティ > 位置情報」では、位置情報のマスタートグルをオフにした際に関連オプション（デフォルト位置・位置情報オーバーライドの許可）がグレーアウトされ、設定の意味が視覚的に明確になる。ユーザーフィードバックを受けた真っ当な改善だ。 5〜10. その他の改善（クリップボード・入力・Windows Hello等） 詳細はInsiderビルドのテスト中だが、クリップボード履歴の高速化、各種入力システム（IMEを含む）の安定性向上、Windows Helloの認証信頼性改善が含まれる見込みだ。 実務への影響——日本のエンジニア・IT管理者へ リリーススケジュールの把握を 今回の変更の多くはRelease Previewチャンネルにすでに入っており、4月のオプション更新→5月の強制セキュリティ更新という流れで一般環境に届く。社内展開にWSUS/Intuneを使っている場合、5月のパッチをブロックすると信頼性修正ごと止まる点に注意。 File Explorerの動作検証を早めに フォルダービューの挙動変更は、カスタマイズした表示設定を持つユーザーに影響する可能性がある。特に共有フォルダを業務で多用する環境では、アップデート後の動作確認をテスト環境で先行して行うことを推奨する。 Insiderビルドの活用 今回のようにRelease Previewで先行検証できる変更は、ITpro・管理者にとって絶好の先行テスト機会だ。仮想マシンやテスト端末でInsiderビルドを取り込み、自社環境固有の問題を本番展開前に特定しておくのが得策だ。 「すぐ当てるか、様子を見るか」の判断基準 近年、Windows Updateは「当てたら壊れた」という報告も散見される。信頼性改善メインのアップデートとはいえ、数日間のInsider・早期採用者の反応を見てから適用判断するのは立派なリスク管理だ。焦って全展開せず、パイロット展開→問題なければ段階展開というプロセスを崩さないこと。 筆者の見解 Windowsを毎週細かく追う必要性は年々薄れていると感じているが、今回の発表は少し違う印象を受ける。 File Explorerの白フラッシュ、フォルダービューのリセット、システムトレイの消失——これらは「知っている人だけが気づく深い機能」ではなく、Windowsを日常的に使う誰もが1日に何度も遭遇するような問題だ。こうした「当たり前が当たり前に動く」修正を地道に積み上げることは、派手な新機能追加よりもはるかに重要だと思っている。 MicrosoftはWindows・Azure・M365を横断する統合プラットフォームとしての総合力に本物の強みがある。その強みを活かすためにも、その入口であるWindows自体の信頼性が土台として盤石でなければ話にならない。「パフォーマンスと信頼性への集中」という今回の方針転換は、正しい方向だ。約束を言葉だけで終わらせず、5月の正式リリースでしっかり届けてほしい。 毎月のアップデートに振り回されるのではなく、今回のように「何が変わるか・なぜ変わるか」を把握した上で戦略的に適用していく姿勢が、現場のIT担当者には求められている。 出典: この記事は Windows 11 to get a major reliability update in May with faster clipboard, stable taskbar, storage and more の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

セキュリティの世界で長年「当たり前」として使われてきたインフラが、静かに変わり始めている。米国立標準技術研究所（NIST）は2026年4月15日より、National Vulnerability Database（NVD）における低優先度CVEへの重要度スコア付与・詳細情報付加を事実上停止した。日本のセキュリティ担当者にとって、これは見逃せない変化だ。 NVDとは何か、なぜ重要か NVDはソフトウェア・ハードウェアの既知脆弱性を集約した公開データベースで、CVE IDに対してNISTが独自の分析を加えることで真価を発揮してきた。具体的には以下を付加していた： CVSSスコア（深刻度の数値化） 影響を受ける製品バージョンの特定 CWE分類（脆弱性の種類の分類） パッチや勧告へのリンク これらの情報があるからこそ、SIEMやVMツールが「このCVEは自社環境に該当するか」「どれを先に対応すべきか」を自動判断できる。単なるIDリストでは機械処理できないのだ。 何が変わったか 今後NISTが詳細分析を行うのは、以下の条件を満たすCVEのみとなる： CISAの「Known Exploited Vulnerabilities（KEV）」カタログに掲載されているもの 米連邦政府のソフトウェアに影響するもの 大統領令14028で定義される「重要ソフトウェア」に関わるもの それ以外のCVEは「Not Scheduled」に分類され、CVE番号の登録は行われるがNISTによる重要度評価は付与されない。CNAが独自に付けたスコアのみが残る形だ。 この判断の背景には、提出件数の急増がある。NISTは最近の263%増という数値を挙げており、2025年に42,000件を処理したものの、2026年に入っても増加が続き対応限界に達したと説明している。要請があれば低優先度CVEも個別に対応する（nvd@nist.gov）という逃げ道は残されているが、組織的なカバーは期待できない。 実務への影響 脆弱性管理ツールの評価基準が変わる Tenable、Qualys、Rapid7、Microsoft Defender for Vulnerabilityといった主要VMツールは、NVDのデータを取り込んでスコアリングを行っている。NVD由来のCVSSスコアが欠落したCVEが増えると、これらのツールが「スコアなし＝低リスク」と誤解釈する可能性がある。ツールベンダーがどう対応するか、リリースノートを注視する必要がある。 KEVカタログの重要性がさらに高まる CISAのKEVカタログは今後もNISTの優先対応対象であり続ける。日本のIT管理者はKEVカタログを直接参照する習慣をつけるべきだ。KEVに掲載されたCVEは「実際に攻撃に使われている」ことが確認済みのものだけが並ぶ、より実践的な指標だ。 CNAスコアへの依存リスク CVE番号を割り当てるCNAにはベンダー自身も含まれる。自社製品の脆弱性を自社がスコアリングするという構造には、利益相反のリスクが内在する。「ベンダーがつけたスコアをそのまま信じる」運用は再考が必要だ。 SBOMとの連携がより重要に ソフトウェア部品表（SBOM）を整備し、利用コンポーネントとCVEのマッピングを自動化しておくことで、「自社に影響があるCVEか」を自力で判断できる体制を整えることが求められる。NVDへの依存度を下げる構造的な対応だ。 筆者の見解 セキュリティ担当者の間では「NVDの遅延は2024年から続いていた」という声も多く、今回の正式宣言は既定路線の明文化とも言える。とはいえ、これを単なる「NISTのリソース問題」として片付けるのは危険だ。 本質的な問題は、CVEの発行数が人間の処理能力を超えた速度で増加し続けているという構造にある。2025年の42,000件という数字自体、毎営業日約160件を処理し続けたことを意味する。AIによる脆弱性発見・報告の自動化が進む中、この傾向は今後さらに加速するだろう。 日本の現場に目を向けると、NVDのCVSSスコアを「絶対的な判断基準」として脆弱性管理プロセスに組み込んでいる組織が多い。しかしそれは、特定の外部サービスが正常稼働することを前提にした設計であり、今回のような変化に対して脆弱だ。 正しい方向性は、単一のスコア源に依存しない多層的な評価体制の構築だ。KEVカタログ、ベンダーアドバイザリ、EPSS（悪用可能性スコア）を組み合わせ、自社環境のコンテキストで優先度を判断できる仕組みを作ること。それはゼロトラストの考え方と同じで、「信頼できる単一の源泉があれば安心」という発想から脱却することでもある。 NVDは引き続き存在し続け、高優先度CVEについては引き続き詳細情報が提供される。パニックになる必要はない。ただ、この変化を契機に自組織の脆弱性管理の依存構造を見直す良い機会ととらえ、次の一手を打っておきたい。 出典: この記事は NIST to stop rating non-priority flaws due to volume increase の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Appleのアカウント変更通知メールを悪用したフィッシング詐欺が確認された。驚くべきは、このメールがAppleの正規インフラから送信され、SPF・DKIM・DMARCの認証をすべて通過している点だ。セキュリティツールが「正規メール」と判定するにもかかわらず、本文には詐欺的な内容が埋め込まれている。技術的な信頼を逆手に取る巧妙な攻撃であり、エンジニアもIT管理者も仕組みを正確に理解しておく必要がある。 攻撃の仕組み：正規インフラの「設計の隙間」を突く 今回の攻撃手順は比較的シンプルだ。 攻撃者がApple IDを新規作成する アカウントの「名前」フィールド（姓・名）に詐欺メッセージを分割して入力する（例：「$899 iPhone Purchase Via PayPal To Cancel 18023530761」） 配送先住所など別の項目を変更する Appleが自動的に「アカウント情報が変更されました」という通知メールを送信する そのメールには名前フィールドの内容がそのまま含まれるため、詐欺メッセージが本文に埋め込まれた状態で届く メールの送信元は appleid@id.apple.com、発信サーバーは rn2-txn-msbadger01107.apple.com など、完全にAppleのインフラを経由している。ヘッダーを見ればSPF・DKIM・DMARCのすべてで「pass」と表示される。受信者のメールクライアントやセキュリティゲートウェイからすれば「Apple本社からの正規メール」と判断せざるを得ない。 コールバック・フィッシングという手法 詐欺メールに記載された電話番号に電話をかけると、偽サポート担当者が出て「アカウントが不正利用されています」と告げる。その後、遠隔操作ソフトのインストールや銀行口座情報の提供を求めてくることが過去の事例で確認されている。 この「コールバック・フィッシング」は、URLをクリックさせる従来型と異なり、被害者自身に電話をかけさせる点がポイントだ。電話口でのソーシャルエンジニアリングに移行するため、技術的なフィルタリングが効きにくく、被害が深刻化しやすい。 類似攻撃との共通点 これと似た手法として、以前はiCloudのカレンダー招待機能を悪用した偽購入通知詐欺があった。Appleのサービス機能を正規のまま使い、ユーザーへの通知経路を乗っ取るパターンが繰り返されている。プラットフォーム事業者の通知設計における「ユーザー入力をそのまま含める」という仕様が、こうした攻撃の温床になっている。 実務への影響：IT管理者・エンジニアが今日から取れる対策 エンドユーザー向け教育の見直し 「差出人アドレスを確認しろ」「認証マーク付きのメールは安全」という従来の啓発は、今回の攻撃には通用しない。正規ドメインからのメールでも内容を批判的に読む習慣を徹底することが重要だ。特に「購入確認」「未払い」「今すぐキャンセル」など、感情を煽る文言には立ち止まる訓練が必要になる。 電話番号への直接連絡は禁止ルールに メール本文に記載された電話番号には絶対に電話しない。公式サポートへの連絡は、必ず公式サイト（apple.com など）から番号を調べて発信するよう組織内ルールとして定める。 メールセキュリティゲートウェイの限界を認識する SPF・DKIM・DMARC通過を以て「安全」と判断するロジックは、今回の手法に対して機能しない。コンテンツベースの検査や、AIを活用した異常パターン検出など、多層的なアプローチへの移行を検討すべき時期に来ている。 Apple IDの管理ポリシーの整備 企業で業務用Apple IDを管理している場合、名前フィールドや住所フィールドの変更履歴を定期的に確認する仕組みを整えることも一つの手だ。攻撃に悪用されている自社アカウントが存在していないか確認する。 筆者の見解 今回の攻撃が示すのは、「プラットフォームを信頼する」という従来のセキュリティモデルの限界だ。SPF・DKIM・DMARCは「このメールは確かにAという組織のサーバーから送られた」ことを証明するが、「その組織のサーバーを経由した内容が安全である」ことを保証するものではない。信頼の構造が一段ズレている。 ゼロトラストの考え方でいえば、「正規のインフラを通過した」という事実は信頼の根拠にならない。すべてのメッセージを内容レベルで検証する、という原則を改めて確認する機会だ。 Appleとしても、ユーザー入力フィールドをそのままメール本文に含める設計は見直す余地がある。名前フィールドに電話番号や金額が含まれていれば弾くといった入力バリデーションの強化は、それほど難しい対処ではないはずだ。ユーザーが被害に遭う前に、プラットフォーム側が塞げる穴は積極的に塞いでほしい。 ユーザー教育に頼ったセキュリティは長期的に持続しない。人間はミスをする。それを前提に、仕組みで防ぐ設計を追求することが、プラットフォーマーに求められる責任だと考える。 出典: この記事は Apple account change alerts abused to send phishing emails の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Next.jsの開発元として知られ、世界中の開発者に愛用されているクラウドプラットフォームVercelが、セキュリティ侵害を正式に公表した。攻撃者はサードパーティAIツールのGoogle Workspace OAuth連携を踏み台にして内部システムへの侵入を果たしたとされており、現代の開発インフラが抱えるリスクをあらためて浮き彫りにした事件だ。 何が起きたか Vercelは2026年4月19日付のセキュリティ情報で、「内部システムへの不正アクセスを伴うセキュリティインシデントが発生した」と発表した。インシデントレスポンスの専門家を起用し、法執行機関にも通報済みとのことで、現時点でサービス自体への影響はないとしている。 「ShinyHunters」を名乗る脅威アクターがハッキングフォーラムで「Vercelに侵入してデータを販売する」と主張し、アクセスキー・ソースコード・データベースデータ・APIキー（NPMトークン、GitHubトークンを含む）のほか、580件の社員情報（氏名・メールアドレス・アカウントステータス・タイムスタンプ）が含まれているとされる。また攻撃者はVercelへの身代金として200万ドル（約3億円）を要求したとも伝えられている。 ただし、過去の「ShinyHunters」関連攻撃に関与したとされるアクターたちは、今回の件への関与を否定しているとBleepingComputerは報じており、実態の確認には慎重さが必要だ。 侵入経路：OAuth連携の落とし穴 事件の核心は、Vercelが後日更新した発表の中にある。侵入経路はサードパーティAIツールのGoogle Workspace OAuthアプリケーションの侵害だったという。 Vercelは、Google WorkspaceやGoogleアカウントの管理者に対し、以下のクライアントIDを持つOAuthアプリケーションの接続を確認するよう注意喚起を出している： 出典: この記事は Vercel confirms breach as hackers claim to be selling stolen data の内容をもとに、筆者の見解を加えて独自に執筆したものです。

KDE Plasmaが、20年以上にわたりユーザーコミュニティから要望され続けていた仮想デスクトップ関連の機能をついに実装する見通しとなった。実現のきっかけとなったのは、長年のディスプレイサーバー「X11」から次世代の「Wayland」へのアーキテクチャ移行だ。オープンソースのLinuxデスクトップ環境を代表するKDE Plasmaにとって、これは単なる機能追加以上の意味を持つ節目といえる。 なぜ21年も待ち続けたのか──X11の構造的な限界 仮想デスクトップ（バーチャルデスクトップ）は、一台の物理マシン上に複数の作業空間を持つ機能で、KDE PlasmaをはじめLinuxデスクトップでは長く標準的に提供されてきた。しかしユーザーが求めていたより細かい制御──たとえばモニターごとに独立した仮想デスクトップの管理やデスクトップ固有のウィジェット・設定の分離など──は、X11の根本的な設計思想と相性が悪く、実装が困難だった。 X11は1984年に設計された非常に古いプロトコルであり、仮想デスクトップの概念はX11の設計段階には存在しなかった。後付けでの実装は「ウィンドウを動かしているだけ」という擬似的なものにとどまり、アーキテクチャの柔軟性には構造的な上限があった。 Waylandはこの問題を根本から解決する。コンポジター（ウィンドウの描画を統括するコンポーネント）が全権を持つWaylandの設計では、仮想デスクトップの管理をコンポジター側で完全にコントロールでき、以前は不可能だった機能が現実的な工数で実装できるようになる。 WaylandへのシフトがLinuxデスクトップを変える Waylandへの移行はKDEだけでなく、GNOMEも含むLinuxデスクトップ全体の潮流だ。長年「Waylandはまだ実用的ではない」と言われ続けたが、2024〜2025年にかけてHDR対応・マルチモニター改善・タブレット入力の安定化など実用上の課題が次々と解消され、今やメインストリームへの移行が急速に進んでいる。 今回の仮想デスクトップ機能の実現は、その恩恵のわかりやすい事例だ。「X11では永遠に無理」と半ば諦めていた機能が、アーキテクチャ刷新によって一気に視野に入ってくる──これがプラットフォーム移行の本質的な価値といえる。 実務への影響──エンジニア・IT管理者にとっての意味 日本のIT現場でKDE Plasmaを本格採用している組織はまだ多くないが、以下の観点で注目しておく価値がある。 開発者・エンジニアの生産性向上 仮想デスクトップを用途ごとに厳密に分離できることで、「作業空間の切り替え」が真の意味での文脈切り替えになる。モニターごとに独立した仮想デスクトップが使えれば、大型マルチモニター環境での開発ワークフローが根本的に変わりうる。 Waylandへの移行タイミング検討 Linux系サーバーやデスクトップをオンプレで管理している組織は、Waylandへの移行計画を本格的に立てるフェーズに入っている。今回のような「Waylandでなければ実現できなかった機能」が積み重なることで、X11からの移行を後押しする材料が増えていく。 Windowsとの比較という視点は不要になりつつある Windowsの「仮想デスクトップ」もWindows 10で追加されて久しいが、細かい設定・管理の柔軟性という点では、KDE Plasmaが追いつきつつある──いや、特定の面では超えようとしている。デスクトップOSの選択において「Windowsしかない」という前提が揺らいでいる現実は、IT管理者として正直に見ておいたほうがいい。 筆者の見解 21年という数字は笑い話のようで、実はソフトウェアアーキテクチャの難しさを如実に示している。X11の制約を「バグ」と捉えて個別に回避しようとするアプローチでは、こういった問題は永遠に解決されない。アーキテクチャそのものを置き換えることで、積年の課題が一気に解消される──これはLinuxデスクトップに限った話ではなく、どのプラットフォームにも言えることだ。 Waylandへの移行を「まだ不安定だから」と先送りしてきたユーザーにとっては、今こそ再評価のタイミングかもしれない。「道のド真ん中を歩く」という観点でいえば、ベンダーやコミュニティが推進する標準的な方向性には理由がある。X11の延命に固執するより、Waylandの上で設計された機能を素直に享受するほうが長期的には合理的だ。 Linuxデスクトップが20年越しの機能を実現していく一方、プラットフォームを問わず「ユーザーが本当に求めているものを届けるまでに何年かかるか」という問いはどの開発組織も真剣に向き合うべきテーマだと感じる。要望をバックログに積み上げ続けることのコストは、決して小さくない。 出典: この記事は After 21 years of waiting, KDE Plasma is finally adding this long-requested feature の内容をもとに、筆者の見解を加えて独自に執筆したものです。