Windows

中国のサイバーセキュリティ企業Qianxin傘下のXLabが、Ghost CMSの重大なSQLインジェクション脆弱性（CVE-2026-26980）を悪用した大規模なClickFix攻撃キャンペーンを発見した。ハーバード大学・オックスフォード大学・DuckDuckGoを含む700以上のドメインが侵害され、訪問者のWindowsシステムにマルウェアを配布する攻撃が今も継続している。 CVE-2026-26980とは何か Ghost CMS 3.24.0から6.19.0に存在するこの脆弱性は、認証なしで攻撃者がデータベースから任意のデータを読み取れるという深刻な欠陥だ。問題の核心は、管理者APIキーが外部から取得できてしまう点にある。 このAPIキーを入手した攻撃者は次のことが可能になる： ユーザー情報・記事・テーマへのフル管理アクセス 公開記事ページへの悪意あるコードの自由な挿入 修正パッチはGhost CMS 6.19.1として2026年2月19日にリリース済みだが、数ヶ月が経過した今もなお多数のサイトが未更新のまま放置されている。 攻撃の連鎖：SQLiからマルウェア配布まで XLabが観測した攻撃フローは以下の4段階で構成される。 ステップ1：管理者APIキーの窃取 CVE-2026-26980を悪用してデータベースから管理者APIキーを抽出する。認証不要で実行できる点が最大の問題だ。 ステップ2：悪意あるJavaScriptの埋め込み 取得した管理者権限を使い、Ghost CMSの記事ページに軽量なJavaScriptローダーを注入する。このローダーは攻撃者のインフラから第2段階のコードを取得する設計になっている。 ステップ3：訪問者のフィンガープリンティング 第2段階のコードはクローキングスクリプトとして機能し、訪問者を選別する。ボットやセキュリティ研究者、想定外の地域からのアクセスは攻撃対象外とすることで検知を回避する巧妙な仕組みだ。 ステップ4：偽CloudflareダイアログによるClickFix攻撃 選別を通過した訪問者には、本物そっくりの偽Cloudflare「人間確認」ダイアログがiframe経由で表示される。「あなたが人間であることを確認するため、以下のコマンドをWindowsのコマンドプロンプトに貼り付けてください」——この指示に従うとマルウェアがシステムにドロップされる仕組みだ。 確認されたペイロードには、DLLローダー、JavaScriptドロッパー、そして「UtilifySetup.exe」という名称のElectronベースのマルウェアが含まれる。 被害規模と対象 XLabが確認した侵害ドメインは700超に上り、その内訳は多岐にわたる： 大学ポータル（ハーバード大学、オックスフォード大学、オーバーン大学） AI・SaaS企業 メディア・報道機関 フィンテック企業 セキュリティ関連サイト・個人ブログ また、プライバシー重視の検索エンジンDuckDuckGoのサイトも被害を受けたと報告されている。研究者は少なくとも2つの異なる攻撃グループを観測しており、同一ドメインを再侵害したり、互いの注入スクリプトを削除して自分のスクリプトを埋め込むという競合する動きも確認されている。 実務への影響：日本のエンジニア・IT管理者が取るべき行動 即座に確認すべきこと Ghost CMSを利用しているすべての組織・個人に以下を推奨する： バージョン確認: Ghost 3.24.0〜6.19.0の範囲にある場合は今すぐ6.19.1以上にアップグレードする APIキーの全ローテーション: パッチ適用後、これまで使用していたAPIキーはすべて無効化・再生成する。漏洩済みの可能性があるため、更新だけでは不十分だ 管理者APIアクセスログの確認: XLabは30日分のログ保持を推奨。不審なAPIコールがないか遡及調査が必要だ 記事・テーマの不正コード確認: 公開されているIoC（侵害の痕跡）リストを参照し、サイト全体を精査する ClickFix攻撃への一般的な対策 この攻撃で最終的な被害を受けるのはWindowsエンドユーザーだ。組織内での啓発として以下を徹底したい： ウェブブラウザ上の「人間確認」ダイアログがコマンドプロンプトへの入力を求めた場合は絶対に実行しない cmd.exeやPowerShellの操作を促すサイトは即座に閉じる Cloudflareの正規の人間確認はコマンド実行を要求しない 中期的な構造的対策 CMSコアのセキュリティアップデートを定期適用するフローの整備（手動管理は限界がある） WebアプリケーションファイアウォールでSQLインジェクション試行を検知・ブロック 管理者APIへのアクセスをIPアドレス制限またはゼロトラストポリシーで絞り込む 筆者の見解 今回の攻撃で改めて浮き彫りになったのは、「修正パッチは出た、だから終わり」という考え方の危うさだ。CVE-2026-26980の修正は2月19日に提供されていた。ところが数ヶ月後の今、700以上のドメインが侵害されている。パッチが「出る」ことと、パッチが「当たる」ことの間には、依然として大きなギャップが存在する。 特に目を引くのは攻撃の精巧さだ。SQLインジェクションで管理者権限を奪い、フィンガープリンティングで標的を選別し、本物そっくりの偽CloudflareダイアログでソーシャルエンジニアリングをかけるというLayered構造になっている。技術的な欠陥の悪用と人間の心理的盲点の突き方を組み合わせた攻撃は、エンドポイントのウイルス対策だけでは防げない。 管理者APIキーの扱いについては、Just-In-Time（JIT）アクセスの思想が本質的な解決策になる。常時アクセス可能な状態のAPIキーが存在すること自体がリスクの温床だ。脆弱性が悪用されても被害を最小化できる構造を平時から設計しておくことが、今回のような攻撃への真の備えになる。 エンドユーザーへのClickFix教育も急務だ。「コマンドプロンプトにこれを貼り付けて」という指示は、正規のITサポート手順と見分けがつきにくい。一度でも体験型のセキュリティトレーニングを受けた人と受けていない人では、この攻撃への耐性に大きな差が出る。Ghost CMS管理者がパッチを当てれば今回の感染源は塞げるが、ClickFix手法そのものは別の経路でも使われ続ける。組織のセキュリティ文化を底上げするタイミングとして、この機会を活かしてほしい。 出典: この記事は Ghost CMS SQL injection flaw exploited in large-scale ClickFix campaign の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

GitHubのCISO（最高情報セキュリティ責任者）Alexis Walesは2026年5月21日、同社内部リポジトリ約3,800件が不正アクセスを受けた経緯を公式ブログで明らかにした。侵害の起点はVisual Studio Code（VS Code）Marketplaceに混入した悪意ある「Nx Console」拡張機能であり、TanStack npmサプライチェーン攻撃の一環として仕込まれたものだった。 事件の全容：「18分間の感染窓口」が引き起こした大規模侵害 Nx Consoleは、モノレポ管理ツール「Nx」の公式VS Code拡張機能だ。攻撃者はバージョン18.95.0に悪意あるペイロードを埋め込み、VS Code Marketplaceに公開した。この改ざん版が入手可能だった時間はわずか18分（OpenVSXでは36分）にすぎなかったが、GitHubの従業員がインストールしてしまった。 埋め込まれたペイロードは、以下のプラットフォームの認証情報・シークレットを窃取するよう設計されていた： npm / GitHub CLI AWS / GCP / Docker Kubernetes 窃取されたGitHub CLIの認証情報を使って攻撃者はリポジトリに「コントリビューター」として侵入し、内部ワークフローを実行できる状態になった。 TeamPCP：連鎖するサプライチェーン攻撃の主犯グループ この攻撃を主導したのはTeamPCPと呼ばれるサイバー犯罪グループとされている。同グループはTanStack・Mistral AIのnpmパッケージを起点に侵害を開始し、CI/CD認証情報を悪用してUiPath・Guardrails AI・OpenSearchにも攻撃を拡大した。 さらに過去の攻撃との関連も報告されている： PyPI・npm・GitHub・Dockerを狙ったサプライチェーン攻撃 OpenAIの従業員2名も被害を受けた「Mini Shai-Hulud」キャンペーン TeamPCPは「Breached」フォーラム上でGitHubのソースコードと「約4,000件のプライベートリポジトリ」へのアクセスを主張し、少なくとも5万ドルを要求している。 GitHubの対応状況 GitHubは侵害確認後、以下を実施した： 侵害されたデバイスを隔離・保護 高影響度の認証情報を優先的にローテーション（月曜〜火曜にかけて実施） ログ解析とインフラ監視を継続 現時点では、影響を受けたリポジトリ外の顧客データが流出した証拠は見つかっていないとGitHubは説明している。 VS Codeマーケットプレイスの構造的問題：繰り返される歴史 今回の事件は孤立した出来事ではない。VS Code Marketplaceでは過去にも深刻な事案が繰り返されている： 2025年: 900万インストールを超える拡張機能がXMRigクリプトマイナーを仕込んで削除される WhiteCobraグループが仮想通貨窃取を狙った24本の拡張機能を一括投稿 2026年1月: AI系コーディングアシスタントを装った2本（合計150万インストール）が開発者データを外部サーバーへ送信 Marketplaceは膨大な数の拡張機能を擁しており、その審査体制の限界は無視できない段階に来ている。 実務への影響——日本の開発現場が今すぐやるべきこと 開発者・エンジニア向け即時対応 拡張機能の運用見直し： VS Code拡張機能の自動更新を無効化し、更新前にリリースノートを確認する習慣をつける 組織管理のデバイスでは、許可リスト（Allowlist）方式で拡張機能インストールを制限する 認証情報の管理強化： GitHub CLI・AWS CLI・Kubeconfigなどの認証情報を定期的にローテーションする OIDC（OpenID Connect）フェデレーション認証を採用し、静的なCI/CDシークレットを排除する。GitHub ActionsであればOIDCによるAWS/GCP連携が既に標準化されている permissionsフィールドでジョブごとに最小権限を明示する 監視・検知の整備： リポジトリへの異常なコントリビューター追加やワークフロー実行をアラートとして検知する シークレットスキャナー（GitHub Secret Scanning、truffleHogなど）をパイプラインに組み込む 筆者の見解 今回の事件が示す本質は「開発ツールそのものが攻撃面（Attack Surface）になった」という事実だ。VS Code拡張機能は開発者のローカル環境で動作し、機密性の高い認証情報に直接アクセスできる。それを「信頼できるもの」として何の確認もなくインストールするのは、構造的なリスクを放置しているのと同じだ。 ...

Microsoft は2026年5月21日、Microsoft Defender に存在する2件のゼロデイ脆弱性に対するセキュリティパッチの配布を開始した。いずれも実際の攻撃に悪用されていることが確認されており、米国土安全保障省傘下のCISA（サイバーセキュリティ・インフラセキュリティ庁）も同日、政府機関に対して6月3日までの緊急対応を命じている。 2件の脆弱性の概要 CVE-2026-41091：SYSTEM権限を奪取される特権昇格 1件目は Microsoft Malware Protection Engine 1.1.26030.3008 以前 に存在する特権昇格の脆弱性。「リンクフォロー（link following）」と呼ばれる、ファイルアクセス前のリンク解決処理が不適切であることに起因する。 攻撃者がこれを悪用すると、最終的に SYSTEM権限（Windowsにおける最高権限）を取得できる。ローカルユーザーとして侵入さえできれば権限昇格が成立するため、フィッシングや別の脆弱性との組み合わせで悪用されるリスクが高い。 CVE-2026-45498：サービス拒否（DoS）状態を引き起こす 2件目は Microsoft Defender Antimalware Platform 4.18.26030.3011 以前 に存在する脆弱性で、System Center Endpoint Protection（2012 R2・2012）、Security Essentials にも影響する。 悪用されると Windows デバイスを サービス拒否（DoS）状態に陥らせることができる。セキュリティ製品そのものがダウンすることで、後続の攻撃への道が開かれる危険がある。 修正バージョンと対処法 Microsoft は以下のバージョンで修正を済ませている： Malware Protection Engine: 1.1.26040.8 Antimalware Platform: 4.18.26040.7 Windows Defender のマルウェア定義とプラットフォームは既定で自動更新が有効になっているため、多くの環境では追加操作なしにパッチが適用済みのはずだ。 ただし、Microsoft は「自動更新に任せてよい」としつつも、以下の手順で適用確認を推奨している： 「Windows セキュリティ」アプリを開く 左ペインで「ウイルスと脅威の防止」を選択 「保護の更新」→「更新プログラムの確認」を実行 左ペインの「設定」→「バージョン情報」を開き、Antimalware Client Version を確認 バージョン番号が上記の修正バージョン以上であれば対応完了だ。 CISAの動きと日本への示唆 CISA は両脆弱性を 既知悪用脆弱性（KEV）カタログに追加し、連邦文民行政機関（FCEB）に対して BOD 22-01 に基づき 6月3日 までの対応を義務付けた。 「この種の脆弱性は悪意ある攻撃者にとって頻繁に使われる攻撃経路であり、連邦政府のエンタープライズに重大なリスクをもたらす」とCISAは警告している。 ...

英国の通信規制当局Ofcom（Office of Communications）が、YouTubeおよびTikTokに対して、未成年ユーザー保護の対策が不十分であるとして公式の警告通知を送付した。オンライン安全法（Online Safety Act）の執行フェーズに入ったことを象徴する動きであり、プラットフォーム事業者に対する規制圧力が本格化している。 Ofcomが指摘した問題点とは 2023年に成立した英国のオンライン安全法（Online Safety Act）は、プラットフォーム事業者に対して、有害コンテンツから未成年者を保護する実効的な仕組みの整備を義務付けている。Ofcomは今回、YouTubeとTikTokの両プラットフォームが、この義務を十分に果たしていないと判断した。 具体的な懸念事項として挙げられているのは以下の点だ： 年齢確認の実効性不足: 未成年者がプラットフォームにアクセスすることを技術的に防止する手段が不十分 コンテンツ推薦アルゴリズムのリスク: 年齢に不適切なコンテンツが、未成年ユーザーに積極的に推薦される仕組みが機能していない 有害コンテンツへの露出: 自傷行為や危険な挑戦を煽るコンテンツが、子どもの目に触れやすい状態になっている Ofcomは警告通知に留まらず、改善が見られない場合には制裁措置へとエスカレートする権限を持つ。最大で全世界売上の10%に相当する制裁金を科すことができる。 技術的な対応の難しさ プラットフォーム側の対応が難しいのは、年齢確認と匿名性のトレードオフという構造的問題が存在するからだ。 厳格な年齢確認を実施するためには、利用者に対してパスポートや公的証明書の提示を求めるなど、個人情報の収集が避けられない。これはプライバシー保護の観点から別の規制リスクを生む。一方、年齢確認を緩くすれば未成年者の保護が疎かになるという板挟みの構造だ。 現在、英国では年齢推定技術（Age Estimation Technology）と呼ばれる、AIを活用した年齢判定手法の実用化が議論されている。生年月日の自己申告や、顔認識に基づく年齢推定などが候補として挙がっているが、いずれも精度と運用コストの面で課題が残る。 日本のIT現場への影響 今回の措置は英国の国内規制だが、日本の事業者にとっても無関係ではない。 まず、日本でも青少年インターネット環境整備法の改正議論が続いており、英国の執行事例が参照される可能性が高い。欧州のGDPRが世界標準を事実上牽引したように、英国のオンライン安全法の適用事例も、日本を含む各国の規制強化の参考になりうる。 日本企業がグローバルサービスを展開する際の実務ポイント： 年齢確認フローの実装: 英国・EU・米国でそれぞれ規制が異なるため、ユーザーの居住地に応じたフローを設計する必要がある コンテンツ推薦ロジックの透明化: 「なぜこのコンテンツが推薦されたか」を説明できる設計が求められてきている 未成年者向けモードの分離: アカウント作成時の年齢情報に基づき、コンテンツフィルタリングとUI制限を組み合わせたモードの提供 データ保存ポリシーの明確化: 未成年者の行動データの保存・活用を制限するガイドラインの整備 筆者の見解 YouTubeとTikTokのような巨大プラットフォームが未成年者保護に本腰を入れてこなかった背景には、エンゲージメント最大化を前提とした設計思想がある。レコメンドアルゴリズムは滞在時間を最大化するよう最適化されており、ユーザーが未成年かどうかを考慮した設計は副次的なものに留まりがちだった。 「禁止すればいい」という発想は必ず失敗する。スマートフォンを取り上げれば子どもが安全になるかといえば、そんなことはない。重要なのは、安全に使える仕組みを技術として実装することだ。この観点では、英国の規制アプローチ——禁止ではなく、安全な設計を義務付ける——は筋が良いと思う。 年齢確認技術の実装コストは決して小さくないが、プラットフォーム企業の体力を考えれば「できない」という言い訳は通らない。Ofcomが今回「警告」という段階を踏んでいるのは、頭ごなしに制裁を科すより、自発的な改善を促す現実的なアプローチだ。制裁フェーズに移行する前に、各社が実効性のある手を打てるかが問われる。 この問題は、テクノロジー企業の設計思想と社会的責任の交差点に位置する。「ユーザーを使い続けさせる設計」から「ユーザーを守る設計」への転換が、今後のプラットフォームビジネスの競争軸のひとつになっていくのではないか。 出典: この記事は UK regulator puts YouTube and TikTok on notice over children’s online safety の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ノルウェーのVivaldi Technologiesが、同社製ブラウザ「Vivaldi 8.0」を正式リリースした。開発チームは今回のアップデートを「ブラウザの歴史における最も重要なデザイン刷新」と位置付けており、UIの根幹にわたる大規模な再設計が行われている。 Vivaldiとはどんなブラウザか VivaldiはChromiumをベースとしたブラウザで、Opera共同創設者のヨン・スティーブン・フォン・テッツナー氏が率いるチームが開発している。最大の特徴は、他のメジャーブラウザでは実現できない高度なカスタマイズ性だ。タブのスタッキング（複数タブをグループ化して折りたたむ機能）、サイドバーへのWebパネル埋め込み、メール・カレンダーの統合、テーマの細かな色彩設定など、「ブラウザをUIから自分仕様に作り替えたい」というパワーユーザーに長年支持されてきた。 バージョン8.0の主な刷新ポイント 今回の8.0では、UI全体のビジュアルデザインが一新された。これまで積み重ねられてきた機能の多さが視覚的な複雑さにつながっていた部分を整理し、より現代的で一貫性のあるインターフェースに再構築されている。 具体的には以下のような変更が報告されている： ツールバー・アドレスバーのデザイン再設計：余白と要素の配置を見直し、視認性を向上 アイコン群の刷新：全体的にフラットでモダンなデザインに統一 カスタマイズUIの改善：設定項目が多いVivaldiの弱点だった「設定の迷宮」を緩和 テーマエンジンの強化：ユーザーがより細かく色やスタイルを制御できる仕組みが整備 Chromiumベースであるため、Google ChromeやMicrosoft Edge向けの拡張機能はそのまま利用できる。 実務への影響——日本のエンジニア・IT管理者にとっての意味 Vivaldiは企業の標準ブラウザとして選ばれるケースは多くないが、開発者や情報収集を業務の軸にする職種では実用価値が高い。 明日から使えるポイント： 複数サービスの並列監視：サイドバーWebパネルにSlack・Teams・GitHubなどを並べ、ブラウザだけで情報集約ができる。複数ウィンドウを行き来するコストを削減できる タブ管理の効率化：調査系の作業では数十タブが開きがちだが、スタッキング＋タブタイリングで画面分割しながら複数ページを同時確認できる プロファイル共有の回避：業務用と個人用で完全に分離したプロファイルを使い分けられるため、認証情報の混在リスクを下げられる 8.0の安定性確認後に移行：大規模デザイン変更直後はバグが出やすい。数週間後のマイナーアップデートを待ってから移行するのが現実的 筆者の見解 ブラウザというカテゴリは、個人の好みが強く出る領域だ。Vivaldiが長年「ニッチだが熱狂的なファンを持つ」ポジションを維持してきたのは、機能の多さよりも「自分の作業スタイルに合わせて本当に変えられる」という体験にある。8.0のデザイン刷新は、その魅力をより広い層に届けようとする意図が見える。 とはいえ、ブラウザ選択を情報収集の観点だけで考えるのはもったいない。「今使っているブラウザで何が不便か」を一度棚卸しして、Vivaldiが解決できる課題があるなら試してみる価値はある。ただし新規に追いかけるよりも、自分の業務フローに合った使い方を深掘りするほうが成果につながりやすい。 大規模なUIリニューアルは、長年のユーザーにとって慣れ直しのコストが発生する両刃でもある。開発チームが「史上最大」と自ら称するほどの変更なら、既存ユーザーのフィードバックがどう反映されるかをしばらく見届けてから評価が固まるだろう。 出典: この記事は Vivaldi 8.0 arrives as “the most significant design overhaul” in the browser’s history の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Word・Excel・PowerPointに展開していた「浮動Copilotボタン（Copilot Dynamic Action Button：DAB）」がユーザーの作業フローを妨げているとの大規模な批判を受け、ボタンをリボンに戻す選択肢の提供を開始した。 なぜ浮動ボタンを追加したのか 背景にあるのは、Copilotの採用率の低さだ。現時点でMicrosoft 365ユーザーのうちCopilot有料プランに加入しているのはわずか**3.3%**にとどまっており、Microsoftの内部期待を大きく下回っている。 この数字を改善すべく、Microsoftは2025年12月からDABのロールアウトを開始。2026年5月の展開完了を目指して段階的に拡大してきた。設計チームは「インテリジェンスが適切なタイミングで提供されなければ、パートナーではなく邪魔者に感じられる」と「探索（exploration）」「集中（focus）」を促す機能として位置づけていた。 ユーザーの反応：想定外の激怒 しかし現実は設計チームの期待とは大きく異なった。特にExcelでは、ワークシート右下に常駐するボタンがセルを覆い隠してしまう問題が続出。Microsoftのフィードバックハブには次のような声が相次いだ。 「その存在自体が腹立たしい。Excelまで全員に嫌われたいなら最高のボタンだ」 「ひどいアップグレードだ。オフにできる方法を提供してくれ」 Microsoftはロールアウト前から浮動ボタンが作業を妨げる可能性を認識していたにもかかわらず、クリックスルー率向上という内部目標を優先して展開を強行していたことが今回の件で明らかになっている。 Microsoftの対応：右クリックでリボンへ移動 批判を受けMicrosoftは、ボタンを右クリックすることでリボンへ戻せる新オプションを追加した。 「Microsoft 365をCopilotとより緊密に統合し、必要なときにいつでも役立つ思考パートナーとして利用できるようにする取り組みを進めてきました。フィードバックに耳を傾け、学び、改善し続けています」——Microsoft公式コメント ボタンの配置は現在「浮動」「ドッキング（横へ固定）」「リボン」の3択から選べる形となっている。完全な非表示は現時点では提供されていない。 実務への影響 現在このボタンが表示されているOfficeユーザーは以下の手順で即座に対処できる。 Copilotの浮動ボタンを右クリック 「リボンに移動」オプションを選択 以降は従来通りリボンからのアクセスに切り替わる IT管理者の観点では、Microsoft 365管理センターやグループポリシーを通じたテナント全体での制御オプションについても、今後の展開を注視する必要がある。Copilot関連のUI変更は今後も続く可能性が高く、エンドユーザーへの事前周知と操作説明を準備しておくことが望ましい。 筆者の見解 MicrosoftがDABのロールアウト前から「ユーザーの作業を妨げる可能性がある」と認識しながら、クリックスルー率向上という内部指標を優先して展開を強行したことは、率直に言ってもったいない判断だった。 Copilotの採用率3.3%という数字は確かに課題だが、その改善策として「UIを変えて無理やり目に触れさせる」というアプローチは、Copilotが本来訴求すべき価値——生産性の向上——と逆行する。Excelのセルを隠すボタンを「思考パートナー」と呼ぶことには無理がある。 MicrosoftにはUIの押しつけではなく、Copilotが実際に価値を生む場面を増やすことで採用率を高める力が十分にある。今回のフィードバックを真摯に受け止め、次のUI変更では「なぜこれがユーザーにとって価値あるのか」を起点に設計を組み立て直してほしい。正面から勝負できる製品を持っているのだから、焦る必要はないはずだ。 出典: この記事は Microsoft admits the floating Copilot button in Word, Excel and PowerPoint was a mistake, lets you hide it after backlash の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月、Windows 11において長らく報告されていたexplorer.exeの不安定動作を公式に認め、月例更新プログラム「KB5089549」（May 2026 Update）で修正を提供した。 何が起きていたのか サインイン直後のタスクバーが表示されない、右クリックメニューが反応しない、タスクビューが無反応になる、ファイルエクスプローラーのクイックアクセスからのピン留め解除が効かない——これらの症状に心当たりのあるユーザーは多いはずだ。 Microsoftはこれらをまとめて「explorer.exeの全般的な信頼性の問題」として一括り認定。KB5089549のリリースノートには「サインイン時、タスクバーメニューやタスクビューの操作時、ファイルエクスプローラーのクイックアクセスからのピン留め解除時など、explorer.exeの信頼性向上のための根本的な変更が含まれる」と明記された。 ただし、修正の効果はアップデート直後には現れず、しばらく使い続けることで体感できるとのことだ。また、KB5089549自体が一部のPCでインストール失敗するケースも報告されており、まずは適用自体が成功するか確認が必要になる。 スタートアップアプリの高速化と低遅延プロファイル 今回の更新はexplorer.exeの修正だけにとどまらない。注目すべき追加改善が2点ある。 スタートアップアプリの起動高速化: 従来のWindows 11は、スタートアップ登録されたアプリが起動直後にCPU・ディスク・メモリ・ネットワークリソースを奪い合い、全体的な動作が重くなる問題があった。今回の更新では、これらアプリのリソース競合を調整し、起動直後の「もたつき感」を軽減する改善が盛り込まれた。 低遅延プロファイル（Low Latency Profile）のテスト開始: ローエンドハードウェアでもアプリやOSコアコンポーネントの起動を高速化する仕組みをMicrosoftがテスト中だ。普及すれば、低スペックPCでの体験が大きく変わる可能性がある。 システムトレイの応答速度向上やWindows Helloの改善も併せて提供されており、総じてサインイン前後の体験を底上げする方向性の更新となっている。 実務への影響——IT管理者・エンジニアが確認すべきポイント 法人環境でWindows 11を展開しているIT管理者にとって、今回の修正は複数の実務上の意味を持つ。 ヘルプデスクへの問い合わせ減少が期待できる: 「サインイン後にタスクバーが出ない」「右クリックが効かない」はユーザーから多く寄せられる問い合わせだ。今回の修正で一定数が解消される見込み 適用前に社内テスト環境で検証を: KB5089549はインストール失敗の報告もある。一括展開の前にパイロット端末での動作確認を推奨する スタートアップアプリが多い環境ほど恩恵が大きい: セキュリティエージェント等が多数常駐する法人端末では、起動後の重さが深刻なケースがある。今回の改善の恩恵を受けやすい環境だ Windows Updateの適用については、リリース直後に飛びつかず数日様子を見るアプローチも場合によっては合理的な判断だ。ただし今回のような「品質改善を明示的に謳った更新」は、通常のセキュリティパッチとは別の観点で評価するとよい。 筆者の見解 正直に言えば、これらはずいぶん前に直っていてほしい問題だ。タスクバーが出ない、右クリックが効かない——これは最新のAI機能より先に解決されるべきUIの基礎部分である。 とはいえ、Microsoftが2026年のWindows 11品質改善にコミットすると公言していた通り、着実に動いていることは評価したい。タスクバーの位置変更やサイズ変更のサポート、スタートメニューのカスタマイズ、そして今回のexplorer.exe修正と、UIの柔軟性と信頼性を同時に高める方向で動いている。 低遅延プロファイルはまだテスト段階だが、ローエンド端末の普及が著しい教育機関や中小企業環境で効果が出れば、Windowsの「使えるOS」としての評価を取り戻す一手になりうる。MicrosoftにはこのままOSの土台固めを地道に続けてほしい。華やかな新機能より、毎日使うものが確実に動くことの方が、ユーザーの信頼を積み上げる近道だ。 出典: この記事は Microsoft says Windows 11’s explorer.exe has been unstable across taskbar, sign-in, and Task View, rolls out fix の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Trend Micro の企業向けエンドポイントセキュリティプラットフォーム「Apex One」に、実攻撃での悪用が確認されたゼロデイ脆弱性（CVE-2026-34926）が存在することが明らかになった。米国土安全保障省のサイバーセキュリティ機関 CISA は連邦機関に対し、6月4日までのパッチ適用を義務付けた。 CVE-2026-34926 の概要：管理者権限が条件のディレクトリトラバーサル 今回の脆弱性はオンプレミス版 Apex One サーバーに存在するディレクトリトラバーサル（パストラバーサル）の問題だ。攻撃者がこれを悪用すると、サーバー上のキーテーブルを書き換え、管理下のエージェントへ悪意のあるコードを配布できてしまう。 悪用条件は以下のとおりで、比較的ハードルは高い： 攻撃はオンプレミス版のみ（クラウド版は対象外） Apex One サーバーへのローカルアクセスが必要 管理者資格情報を別の手段で事前取得済みであること Trend Micro は「TrendAI が実環境での悪用試行を少なくとも1件観測している」と発表しており、理論上の問題ではなくアクティブな脅威として取り扱われている。 CISA が KEV リストに追加、連邦機関に6月4日の期限 CISA は CVE-2026-34926 を「既知の悪用済み脆弱性（KEV）」カタログに追加し、BOD 22-01 に基づいて連邦機関に期限付きのパッチ適用を命じた。CISA は「この種の脆弱性は悪意ある攻撃者にとって頻繁な攻撃ベクターであり、連邦政府のシステムに重大なリスクをもたらす」と警告している。 KEV への追加は民間企業にとっても重要なシグナルだ。米連邦機関が使用していることが多い製品・バージョンは、民間セクターでも広く展開されているケースが多く、攻撃者の関心を引きやすい。 同時リリースされた7件の特権昇格パッチ Trend Micro は CVE-2026-34926 に加え、Apex One SEP（Standard Endpoint Protection）エージェントに存在する7件のローカル特権昇格（LPE）脆弱性への修正も同日公開した。これらは低権限コードの実行権限を持つ攻撃者が悪用可能なもので、ゼロデイ脆弱性との組み合わせ攻撃に利用されるリスクがある。 Apex One は過去にも繰り返し標的に Apex One に対するゼロデイ攻撃は今回が初めてではない。過去の主な事例は以下のとおりだ： CVE 年月 内容 CVE-2022-40139 2022年9月 ゼロデイ、野外で悪用 CVE-2023-41179 2023年9月 ゼロデイ、野外で悪用 CVE-2025-54948 2025年8月 RCE、野外で悪用 CVE-2026-34926 2026年5月 今回の脆弱性 CISA の KEV カタログには現在、Trend Micro Apex 関連の脆弱性が12件登録されている。エンドポイントセキュリティ製品自体が継続的な攻撃対象になっているという事実は、改めて重く受け止める必要がある。 ...

オランダ金融犯罪捜査局（FIOD）は2026年5月22日、ロシア・ベラルーシへのサイバー攻撃支援や偽情報拡散に関与したとされるウェブホスティング企業「Stark Industries」に関連するサーバー800台を押収し、同社ディレクター（57歳）と接続インフラを提供していた別会社の代表（39歳）の2名を逮捕したと発表した。 Stark Industriesとは何者か Stark Industriesが設立されたのは2022年2月10日——ロシアによるウクライナ侵攻の直前だ。この時期の設立は偶然ではないとFIODは見ている。同社はその後EU制裁対象として認定され、2025年5月20日にEU制裁リストへ追加された。 制裁指定後、Stark Industriesのインフラは新たに設立されたオランダ企業「WorkTitans B.V.」へ移管され、「THE.Hosting」というブランド名でサービスを継続していたとされる。これはいわゆるペーパーカンパニーによる制裁回避の典型的な手口だ。 FIODはドロンテン、スキポール・ライク、エンスヘーデ、アルメールのデータセンターおよび関連施設に一斉捜索を実施。サーバー800台のほか、ノートPC、スマートフォン、業務記録なども押収した。 NoName057(16)との繋がり デンマーク当局とインフラプロバイダーは、WorkTitansをロシア支持のハクティビスト集団「NoName057(16)」によるDDoS攻撃と結びつけているという。NoName057(16)は欧州各国の政府機関や重要インフラを標的にDDoS攻撃を繰り返してきた組織であり、その攻撃インフラの一部をこのオランダ拠点のホスティングが支えていた可能性が高い。 また、アルメールに拠点を置く「Mirhosting」が物理サーバーの運用とコロケーション提供、アムステルダムとフランクフルトの主要インターネット交換ポイントへの高帯域接続を担い、Starkのトラフィックの欧州入口として機能していたとされる。Mirhosting側は「不正利用の報告を受けたら迅速に対応しており、故意ではなかった」と否定しているが、捜査は継続中だ。 日本のIT現場への影響 ホスティング選定時のデューデリジェンス 今回の摘発が示す重要な教訓は、「自社のシステムはクリーンでも、接続先や上流インフラが制裁対象になりうる」というリスクだ。コスト重視で海外の格安ホスティングやVPS事業者を利用している場合、その運営主体がどの法人に属し、どの国の規制下にあるかの確認が欠かせない。 DDoS対策の多層防御 NoName057(16)のような組織は欧州インフラを踏み台に日本サービスを標的にするケースも増えている。Cloudflare Magic TransitやAzure DDoS Protection Standardといったアップストリームでの吸収対策に加え、ISPレベルのブラックホールルーティングを組み合わせた多層防御の整備が引き続き重要だ。 制裁リストの継続的モニタリング EU制裁リストや米国OFAC制裁リストは随時更新される。自社が利用するサービスやパートナーが対象に含まれていないか自動確認するプロセスを持つことが、コンプライアンス上のリスクヘッジになる。大手パブリッククラウドの場合はプロバイダー側で対応しているケースが多いが、中小のニッチなサービスでは自社での確認が必要だ。 筆者の見解 今回の摘発は、ロシアが欧州の制度的な隙間を突いてきた典型的な事例だ。侵攻直前に設立し、制裁を受けたら名前を変えてオランダ企業として存続する——このパターンは今後も繰り返されるだろう。 一つ言えるのは、「今動いているから安全」という発想はもう通用しないということだ。インフラの透明性確認、制裁リストとの突合、DDoS対策の多層化——これらは「大規模攻撃を受けた後に慌てる話」ではなく、平時にやっておくべき話だ。 日本企業はソフトウェアのSBOM（ソフトウェア部品表）への注目は高まりつつあるが、ネットワークインフラの来歴確認はまだ手薄な組織が多い。「自社のトラフィックがどのASを経由しているか」まで可視化できている組織は限られている。ゼロトラストアーキテクチャの本質は「ネットワーク経路を無条件に信頼しない」ことにある。この考え方は認証・認可の話だけでなく、インフラ選定における透明性確保という観点でも、正しい方向を指し示している。 攻撃者が「制度をハックする」手口を洗練させている以上、防御側もインフラの来歴を問い続ける姿勢が求められる。 出典: この記事は Netherlands seizes 800 servers of hosting firm enabling cyberattacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftのCopilotマーケティング責任者で長年にわたりWindows部門を牽引してきたユスフ・メフディ（Yusuf Mehdi）氏が、来年の退任前にWindowsを「エージェント時代」向けに刷新するプロジェクトを主導することが、リークされた社内メモによって明らかになった。 社内メモが示すWindowsの次の姿 リークされたMicrosoftの社内メモによると、Copilotおよびコンシューマー製品の最高責任者であるメフディ氏は、「WindowsをAIエージェント時代向けに再想像（reimagine）する」取り組みをリードするとされている。 「エージェント時代のWindows」とは、チャットUIを埋め込む段階の話ではない。AIエージェントがOSレベルで動作し、ファイル操作・アプリ制御・タスク自動化を半自律的に実行できるアーキテクチャへの転換を指す。現在のWindows 11でもCopilot統合は進んでいるが、大半は「チャットウィンドウが追加されただけ」という段階に留まっている。今回のリークが示すのはそれを超えた、「OSそのものがエージェントを前提とした構造になる」という方向性だ。 エージェント統合に必要なOS側のアーキテクチャ 「エージェント時代」のOSに求められる要件は、従来のGUIアプリ中心の設計とは根本的に異なる。 コンテキスト共有: エージェントが複数アプリをまたいでユーザーの作業コンテキストを理解できる仕組み 細粒度な権限管理: エージェントがシステムを操作する際の安全な認可制御 非同期タスク実行: バックグラウンドでエージェントがタスクを完遂するための実行基盤 アクション履歴と監査: エージェントが何をしたかを追跡・ロールバックできる機構 これらはいずれも現在のWindows 11では十分に備わっていない。「エージェント時代向け」という言葉には、こうしたアーキテクチャ刷新への布石が含まれている可能性が高い。 メフディ氏退任の背景 ユスフ・メフディ氏はMicrosoftで約25年にわたり要職を務め、Bing・Xbox・Surfaceを経て近年はCopilot戦略を主導してきた。その退任は単なる人事異動ではなく、Microsoft内部でのAI戦略の主導権移動を示している。退任前にWindowsの刷新プロジェクトを任されるという位置づけは、これが「仕上げの仕事」であることを意味する。 実務への影響——日本のIT管理者が今やるべきこと 「エージェントが動くWindows」が本格化すれば、企業のIT管理は大きく変わる。 禁止ベースのポリシーは機能しなくなる: エージェントがシステムを自律操作できる環境では、従来の「アプリインストール禁止」「外部接続ブロック」という一律禁止は機能しない。何をエージェントに許可し、何を禁止するかという粒度の細かい制御設計が必要になる。 ゼロトラスト前提での設計を今から: エージェントが複数サービスにまたがってアクションを実行する世界では、ネットワーク境界の信頼モデルは崩壊する。アクション単位・アイデンティティ単位での認可設計への移行準備を今から進めておくべきだ。 Intuneポリシーの定期棚卸しを: エージェント対応の新機能が今後段階的に導入されると、現在のIntuneポリシーで意図せずブロックされるケースが出てくる。定期的な見直しと検証の習慣を今から持っておくと後で楽になる。 筆者の見解 WindowsがAIエージェント時代に向けて刷新されるという方向性自体は正しい。デスクトップOSがエージェントの実行基盤になっていくのは自然な流れだし、Microsoftにはその実現に必要な技術力・ユーザーベース・Azure AIバックエンドがすべて揃っている。正面から勝負できる条件は整っている。 一方で、「Copilot in Windows」のこれまでの歩みを振り返ると、素直に期待一辺倒にはなれない。機能が増えるたびに一貫性より詰め込みが優先されてきた印象があり、「エージェント統合」という名目でさらなる複雑化が進むとしたら、それはもったいない。真の刷新には機能を足すだけでなく整理と削除が伴わなければならないはずだ。 メフディ氏の「退任前集大成」という文脈は、キャリアの締めくくりにふさわしい仕事になりうる。それだけに、「完成させること」より「本当に使えるものにすること」を優先した結果を期待したい。 出典: この記事は Windows will be reimagined for the agentic era before Copilot executive leaves next year の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Windows 11の最新プレビュービルドにおいて、画面全体に色調フィルターをかける「スクリーンティント（Screen Tint）」機能をはじめとする複数のアクセシビリティ改善を導入した。 スクリーンティントとは何か スクリーンティントは、ディスプレイ全体に任意の色合いのフィルターを重ねて表示する機能だ。視覚過敏（光過敏症）を持つユーザーや、ディスレクシア（読み書き障害）のある利用者、長時間の画面作業で目の疲れを感じやすい人にとって、既存のナイトライトや色フィルターとは異なるアプローチで視認性を向上させる。 既存の「カラーフィルター」機能が色覚異常への対応を主眼に置いているのに対し、スクリーンティントは色調そのものを柔軟に調整することで、より広範な視覚ニーズに応えることを目的としている。設定は「アクセシビリティ」→「視覚効果」から変更できる見込みで、輝度や彩度との組み合わせ調整も可能になると見られる。 その他のアクセシビリティ改善 今回のプレビュービルドにはスクリーンティント以外にも複数のアクセシビリティ関連の変更が含まれている。Microsoftはアクセシビリティ機能の継続的な整備を進めており、ナレーター（スクリーンリーダー）の改善や、キーボード操作性の向上なども段階的にロールアウトされている。 これらの機能は現時点ではInsider Program（Dev/Beta/Canaryチャンネル）の参加者向けのプレビュー段階であり、安定版への反映時期はMicrosoftの公式アナウンスを待つ必要がある。 実務への影響——IT管理者・エンジニアが知っておくべきこと アクセシビリティ機能の強化は、企業のIT部門にとって見過ごせないアップデートだ。 多様な従業員への対応コスト削減: 視覚過敏や色覚特性を持つ社員向けに、これまでサードパーティ製アプリや専用機器で対応していたケースが、OS標準機能だけで完結する可能性が高まる。ライセンスコストと管理工数の両方を削減できる。 法的・コンプライアンス観点: 日本でも障害者差別解消法の改正（2024年）により、民間事業者に対する「合理的配慮の提供」が義務化された。デジタル環境のアクセシビリティ整備はその一環として重要性を増している。Windows標準機能として提供されることで、グループポリシーやIntuneによる一括展開・管理も現実的になる。 展開計画の見直しタイミング: Insider Buildで動作を確認しておき、安定版リリース時に速やかに社内ガイドラインを更新できる体制を整えておくと良い。特にアクセシビリティ設定をユーザーに委ねるか管理者が標準化するかの方針を事前に固めておくことを推奨する。 筆者の見解 Windowsの変更を細かく追いかけることの意味が薄れてきた昨今、アクセシビリティ系の改善は数少ない「ちゃんと見ておきたい」アップデートのひとつだ。 スクリーンティントのような機能は地味に見えて、実際に必要としているユーザーにとっては日々の作業品質を大きく変える。こういった地道な積み重ねがOSプラットフォームとしての底力を示す部分でもある。 一方で、せっかく良い機能を作っても、企業の現場に届くまでのタイムラグや、設定の複雑さで活用されないケースが多い。Microsoftには機能を作るだけでなく、IT管理者が迷わず展開できるテンプレートやドキュメントの整備までセットで提供してほしい。実力があるのだから、最後の一手まできっちり仕上げてほしいところだ。 出典: この記事は Windows 11 is getting Screen Tint feature and other accessibility improvements in new builds の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが、企業向けコミュニケーションツール「Microsoft Teams」の大幅なUIリデザインを2026年7月より段階的に展開すると発表した。中央配置のコントロールバー、安全な画面共有機能、カスタマイズ可能な会議ツールなど、現場での使い勝手を根本から見直す変更が盛り込まれている。 何が変わるのか 今回のリデザインで注目されるのは、コントロールの中央配置だ。これまでのTeamsは会議中のコントロールバーが端に寄りがちで、大画面ディスプレイでは操作しづらいという声があった。新デザインでは画面下部の中央にコントロールをまとめることで、自然な視線の流れとクリック動線を一致させる設計になる。 安全な共有オプションの強化も見逃せない。画面共有時に意図しないウィンドウや個人情報が映り込む事故は、リモート会議を日常的に使う現場で繰り返し問題になってきた。新デザインではどのコンテンツを共有するかをより明示的に選択できる仕組みが導入され、誤共有リスクの低減が期待される。 カスタマイズ可能な会議ツールについては、チームや用途に合わせて会議中に利用するボタンや機能を整理できるようになると見られる。全員に同じUIを押し付けるのではなく、ロールや会議の種類に応じた最適な操作環境を構築しやすくなる方向性だ。 なぜこれが重要か Teamsはいまや日本の企業でも当たり前のインフラだ。大手企業から官公庁まで利用が広がっており、UIの大幅変更は「慣れ直しコスト」として現場に波及する。一方で、ZoomやGoogle Meetとの競争が続く中、Microsoftがユーザー体験の改善に継続的に投資している姿勢は評価できる。特に「安全な共有」という方向性は、情報漏洩リスクを常に意識しなければならないエンタープライズ環境にとって正しい優先順位だ。 実務への影響——IT管理者が今すぐすべきこと 展開は2026年7月開始予定だが、大規模テナントへの完全展開はそれ以降になるケースが多い。以下の点を早めに確認しておくとよいだろう。 ターゲットリリースの確認: Teams管理センターで段階的展開（ターゲットリリース）を設定しているかを確認し、先行評価の準備をしておく エンドユーザー教育の準備: 大幅UIリデザインはヘルプデスクへの問い合わせ増加要因になりやすい。FAQや簡易ガイドを事前に整備しておくことで展開後の混乱を最小化できる 会議テンプレートの見直し: カスタマイズ可能な会議ツールが導入されれば、自組織の会議運用を整理する好機となる。今のうちに「どんな会議種別があるか」を棚卸ししておくと導入がスムーズになる 共有ポリシーの明文化: 新機能に合わせて「どのコンテンツを共有してよいか」を社内ポリシーとして文書化しておくと、展開後のトラブル対応が楽になる 筆者の見解 Microsoft Teamsのリデザインは、見た目の刷新にとどまらず「意図しない情報漏洩を設計で防ぐ」という思想の変化が感じられる点で興味深い。機能追加が続いてきた分、UIの複雑さも積み上がっていたTeamsにとって、中央配置のコントロールや安全な共有機能は「引き算の設計」として正しい方向性だと思う。 ただ、リデザインに期待したいのは見た目だけではない。大規模会議でのCPU・メモリ使用率の改善や、AI機能（議事録生成・ノイズキャンセル）との自然な統合も同時に進んでほしい。UIが洗練されても、会議中に動作が重くなるようでは本末転倒だ。 Copilot for Teamsの活用がいよいよ現場に浸透し始めるタイミングと重なるだけに、このリデザインがAI機能との一体化を実現したものになるかが真の評価軸になるだろう。プラットフォームとしての底力はTeamsにある。その力を存分に引き出す方向で進化してほしいと思う。 出典: この記事は Microsoft Teams is getting a major redesign, here is a first look の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Windows 11のアップデート一時停止機能を大幅に刷新する「日付指定」オプションをWindows Insiderプログラムでテスト中であることが明らかになった。現行の「最大5週間」という固定制限を撤廃し、ユーザーが任意の日付まで更新を止めておけるようになる予定だ。 何が変わるのか 現時点のWindows 11では、設定画面から最大5週間のアップデート一時停止が可能だ。しかし停止期間が切れると強制的にパッチ適用が試みられ、それ以上の延長はできない仕様になっている。 Windows Insiderでテストされている新機能では、これが「カレンダーから日付を選ぶ」方式に変わる。一度に最長35日間の停止が可能となり、期限が近づいたら再度カレンダーを開いて延長できる。この延長操作を繰り返すことで、理論上は無期限にアップデートを先送りすることが可能になる。 また、シャットダウンボタンの分離（更新せずに終了 vs 更新して再起動）や、強制再起動の削減も合わせてテストされている模様だ。 Microsoftは公式サポートアカウントのSNS投稿で「作業中はアップデートを一時停止して構わない」と積極的に呼びかけており、これまでの「できるだけ早く当てさせる」方針から、ユーザーの自律的な判断を尊重する方向へのシフトが見て取れる。 なぜ今このタイミングなのか 背景にあるのは、Windowsアップデートに対するエンドユーザーの根強い不満だ。世界16億台のWindows 11デバイスを抱えるMicrosoftにとって、月例パッチ（Patch Tuesday）を軸にした更新サイクルは欠かせない。しかし大多数のビジネスユーザーは「Patch Tuesdayとは何か」すら知らず、作業の真っ最中に降ってくる再起動要求は業務妨害以外の何物でもない。 加えて、Windowsアップデートに起因する不具合報告がここ数年で増加傾向にある。特定の環境でブルースクリーンが発生したり、サードパーティ製ドライバが無効化されたりといったケースが後を絶たない。こうした実態が、より細かいコントロールを求めるユーザーの声を後押ししている。 実務への影響——日本のIT管理者は何を準備すべきか エンドポイント管理の観点から注意が必要 Intune（Microsoft Endpoint Manager）やWSUSで管理されている企業端末への影響は、現時点では明らかでない。コンシューマー向けUIの変更がエンタープライズ管理ポリシーとどう整合するかは、一般提供（GA）後のドキュメントを確認する必要がある。 「無期限停止」は諸刃の剣 技術的には可能になるとしても、無期限に当て続けないことはセキュリティリスクに直結する。Exploited in the Wild（実際に悪用されている脆弱性）への対応が遅れることになりかねない。IT管理者は「ユーザーに自由を与えつつ、最低限のパッチ適用を保証する」ポリシーの再設計を検討しておくべきだろう。 ヘルプデスク問い合わせが変わる可能性 「更新を止める方法を教えてください」という問い合わせが今後増加することが予想される。FAQやセルフサービスポータルの事前整備が有効だ。また、停止期間中に発生した問題のトラブルシューティングでは「最後に更新したのはいつか」を必ず確認するフローを組み込んでおきたい。 当面の推奨運用 Insider Previewの動向をウォッチし、GA前にテスト環境で新UIの挙動を確認する グループポリシーまたはIntuneの更新延期設定と、新しいUIコントロールの優先順位関係を把握する 「数日様子を見る」判断はセキュリティ的に有効な手段。ただし3〜4週間以上の放置は別問題と明確に線引きする 筆者の見解 この変更そのものは歓迎したい。「OSのアップデートは当てたいときに当てる」——それが本来あるべき姿だ。Windows XP・7の時代には当たり前にできていたことが、Windows 10以降で突如ユーザーの手から奪われ、強制再起動で作業を台なしにされてきた。それが今になって「やっぱり一時停止できるようにします」と言われても、遅いという感覚は否めない。 ただ、ここで気をつけたいのは「自由」と「放置」を混同しないことだ。35日単位で延長できるとはいえ、パッチを当て続けないリスクはユーザー自身が負う。MicrosoftはUI上で無期限停止を技術的に許容しながら、セキュリティの責任はユーザーに転嫁する形になりかねない。その点については、今後のドキュメントや管理ポリシーでどう整理されるかをしっかり見ていく必要がある。 MicrosoftにはWindowsのアップデート品質そのものを上げる力がある。UIの裁量をユーザーに戻すことは良い一歩だが、そもそも当てても壊れないアップデートを届けること——そちらも同時に進めてほしい。それができる会社だからこそ、あえてそう言いたい。 出典: この記事は Microsoft says you should pause Windows 11 Updates when you need to work, as it tests greater controller の内容をもとに、筆者の見解を加えて独自に執筆したものです。

LaravelのサードパーティローカライゼーションパッケージシリーズであるLaravel Langが供給チェーン攻撃の標的となった。攻撃者はGitHubのバージョンタグを悪用し、Composer経由でインストールした開発者のシステムからAWSキーやGitHubトークンを含む幅広いクレデンシャルを窃取するマルウェアを仕掛けた。StepSecurity・Aikido Security・Socketの3社が2026年5月23日に警告を発している。 攻撃の手口：ソースコードを変えず、タグだけを書き換える 今回の攻撃で特筆すべきは、プロジェクトのソースコードそのものは改ざんされていないという点だ。代わりに攻撃者が悪用したのは、GitHubの「タグ」がフォーク先のコミットを参照できるという機能だ。 攻撃者はlaravel-lang組織のorg全体プッシュ権限を持つ侵害済み認証情報を使い、以下の4パッケージの全既存タグを悪意あるコミットへ書き換えた： laravel-lang/lang（502タグ） laravel-lang/http-statuses laravel-lang/attributes laravel-lang/actions 書き換えは2026年5月23日 22:32 UTCに開始し、翌00:00 UTCに完了。StepSecurityによれば4リポジトリ全てで同一の偽著者IDと同一の改ざんファイルが確認されており、単一の攻撃者による組織的な攻撃とみられる。Aikidoは233バージョン、Socketは約700バージョンへの影響を報告している。 何が盗まれるのか：クレデンシャルの「全方位収集」 悪意あるリリースは src/helpers.php という新ファイルをComposerのautoload設定に組み込む形で動作する。このファイルはドロッパーとして機能し、攻撃者のC2サーバー（flipboxstudio[.]info）から第2ペイロードをダウンロードする。 ダウンロードされるPHPペイロードはLinux・macOS・Windows対応のクロスプラットフォーム製クレデンシャルスティーラーで、盗取対象は驚くほど広い： AWSキー、GitHubトークン、Slackトークン、Stripeシークレット Kubernetesシークレット、Vault トークン CI/CDシークレット、SSHキー ブラウザ保存パスワード・Cookie（Chrome・Brave・Edge） 暗号通貨ウォレット、パスワードマネージャー VPN設定、ローカル .env ファイル Windowsでは追加で DebugElevator という実行ファイルが %TEMP% に展開され、ChromeのApp-Bound Encryptionキーを解読してブラウザ保存認証情報を窃取する。実行ファイルのPDBパスには「claude」という文字列も含まれており、マルウェア開発にAIが活用された可能性が指摘されている。 実務への影響 今すぐ確認すべきこと 1. composer.lock を確認する laravel-lang/lang・laravel-lang/http-statuses・laravel-lang/attributes・laravel-lang/actions のいずれかが存在する場合は直ちに調査が必要だ。 2. 影響期間を把握する 攻撃はUTC 2026年5月23日 22:32以降に展開された。それ以前のインストールでも composer update で最新タグを取得していた場合は影響を受けた可能性がある。 3. クレデンシャルをローテーションする 上記パッケージを利用していた環境では、AWSキー・GitHubトークン・DBパスワード等を即座にローテーションすることを強く推奨する。.env ファイルの内容も漏洩前提で扱うべきだ。 4. CI/CDシークレットの見直し GitHub Actionsに保存されているシークレット類は、今回の攻撃で主要標的の一つになっている。OIDCによる一時的クレデンシャル発行（Just-In-Timeアクセス）を導入することで、仮に窃取されても被害を最小化できる。 Composerのセキュリティ強化 Composerは composer.lock のハッシュ値で整合性を検証するが、タグが書き換えられると新しいコミットに対する新しいハッシュが生成されるため、従来の整合性検証では検出できない。今後はSHA pinningやプライベートミラーの活用、GitHub の Tag Protection Rules の設定も検討に値する。 筆者の見解 供給チェーン攻撃の中でも、今回のケースは「ソースコードには触れず、タグというメタデータだけを書き換える」という点で既存の防衛策をすり抜けやすい。静的解析やSCAツールが監視しているのはあくまでソースコードの変化であり、タグ先のコミットが差し替えられたという事実は検出できない。 より根本的な問題として、攻撃者が利用したのは「org全体のプッシュ権限を持つ常時有効な認証情報」だ。これが常時付与された権限だったからこそ、4リポジトリを一気に、しかも深夜の約1時間半で書き換えることができた。Just-In-Timeアクセスときめ細かなスコープ制御が標準になっていれば、ここまでの被害拡大は防げたはずだ。Non-Human Identity（NHI）管理の重要性が改めて問われる事例といえる。 ...

Microsoftは2026年5月、Windows 11のCopilotアプリに新たなサイドバー型ドッキング機能を追加するテストを開始した。画面の左右どちらにも固定でき、デスクトップ全体が自動的にリサイズされてほかのアプリと並列表示できる新UIで、Windows Latestが最初に発見し、現在段階的にロールアウト中だ。 何が変わったのか これまでWindows 11上のCopilotは「独立したアプリウィンドウ」として動作していた。新しいUIでは、タイトルバーに追加されたドロップダウンメニューから表示形態を選択できる。 選択肢は4種類： 現行のアプリウィンドウモード（デフォルト） ピクチャーインピクチャーモード（小さいウィンドウが常時前面に表示） 左サイドバーへのドッキング（新機能） 右サイドバーへのドッキング（新機能） サイドバーにドッキングすると、Windows 11のデスクトップが自動的にリサイズされ、Copilotが占有した分だけほかのアプリが縮む。File ExplorerをフルスクリーンまたはSnap Layouts等で展開していても、Copilotが右端を確保したうえで残りの空間にアプリが再配置される。 デジャヴ感のある「原点回帰」 実はこの設計、Windows 11にCopilotが初めて搭載された2024年当初の仕様に近い。当時もサイドバー型でアプリと並列表示されていたが、のちにMicrosoftは独立アプリへ変更し、さらにWebアプリ化するなど、約6回ものUI刷新を重ねてきた。 現在のCopilotはEdgeベースのラッパーとして実装されており、プライベートなEdgeインスタンスを同梱していることも最近確認されている。今回の新しいサイドバードッキング機能は、このEdgeベースの実装と組み合わせることで実現されている可能性が高い。 実務への影響 マルチタスク効率の変化 サイドバー型CopilotはWebブラウザの「サイドパネル」機能に近い使い勝手で、コーディング中やドキュメント作成中にAIへ質問する際の「ウィンドウ切り替えコスト」を削減できる可能性がある。特に開発者が複数ファイルを開きながらAIに相談するシーンでは、フォーカスを失わずに作業を続けられる利点がある。 ただし、現実的な注意点もある： 狭い画面での圧迫感：13〜14インチクラスのノートPCでは、作業スペースが大幅に削られることになる ロールアウト段階：現時点では全ユーザーに展開されているわけではなく、Windows Insider Programなどを通じた段階的配信だ 統合の深さ：EdgeベースのラッパーであるCopilotがOSの深部とどこまで連携できるかは、今後の実装次第 IT管理者向けの注意点 Copilotの表示形態が変わっても、グループポリシーやIntune経由での制御範囲に大きな変化はないと見られる。ただし、新しいスナップレイアウトオプションがエンドユーザーの操作性に影響するため、更新後の動作確認は実施しておきたい。特にVDI環境やセッションベースのデスクトップでは、ウィンドウリサイズの挙動が想定外になるケースがないか検証することを推奨する。 筆者の見解 CopilotのUI刷新は今回で約6回目。「また変わったのか」というのが率直な第一印象だ。 ただし、今回の方向性そのものは悪くない。「AIがOSの一部として常時存在する」というビジョンは理にかなっており、サイドバー型はその表現として素直な形だ。初期設計が不評だったのはAIの中身の問題であり、UIコンセプトの問題ではなかった。その意味では、原点回帰は正しい判断だと思う。 もっとも、UIをどれだけ洗練させても、Copilot自体の応答品質や他アプリとの連携の深さが伴わなければ定着しない。Microsoftにはハードウェアからクラウドまでのエコシステムという強みがある。その基盤を活かして、Copilotが「常に開いておきたいツール」になるところまで持っていけるか——UIの試行錯誤はそろそろ一区切りつけて、AIの実力を磨くことに集中してほしいと思う。応援しているからこそ、そう感じる。 出典: この記事は Microsoft’s new Copilot turns into a Windows 11 sidebar that pushes your apps aside to make room の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月15日、Windows 11 Insider Experimental Preview Build 26300.8493をリリースし、ユーザーが長年要望し続けていたタスクバーの位置変更機能を公式に実装した。上・下・左・右の4方向から選択可能で、レジストリハックやサードパーティツールは一切不要だ。 Windows 95以来封印されていた自由が戻ってくる Windows 10まで当たり前に使えていたタスクバーの位置変更は、Windows 11の登場とともに突然廃止された。Microsoftは「中央揃えの下部配置がモダンUI」と主張して3年間ユーザーの声を無視してきたが、今回のビルドでついに方針転換を示した形だ。 変更方法は単純明快。設定 → 個人用設定 → タスクバー → タスクバーの動作と進むと、「画面上のタスクバーの位置」ドロップダウンが新たに表示される。選択肢は「下（デフォルト）」「上」「左」「右」の4つ。選択後は約300msのスライドアニメーションで即座に移動し、Explorerの再起動も再起動も不要だ。 各配置の動作詳細 上部配置では、スタートボタンとアイコンは中央揃えのまま上端に移動し、システムトレイ・時計・クイック設定は右上に集まる。アクションセンターのパネルは上から下に展開するため、直感的に操作できる。 左配置ではタスクバーが縦型になり、アイコンが上から下に積み重なる。スタートボタンは最上部、時計とシステムトレイは最下部に配置される。クイック設定や通知パネルは右方向に展開する。ウルトラワイドモニターや縦型モニター環境では、水平方向のスペースを有効活用できる。 右配置は左配置の鏡像で、パネルは左方向に開く。 スタートメニューはタスクバーの位置に追随する。左配置なら左端から右方向へ展開するなど、「タスクバーがある方向」から論理的に開くよう設計されており、従来のメニュー位置に起因する混乱が解消されている。 Insiderで今すぐ試すには Build 26300.8493はWindowsの「Experimentalブランチ」に属する特別なリング。2026年初頭にMicrosoftが導入したこのブランチは、リスクの高い機能を正式リリースにコミットせずにテストするための場所だ。Dev Channel参加者でも全員が即座に見られるわけではなく、A/Bテストによる段階的な展開が行われている。 タスクバー移動オプションが表示されない場合は、ViVeToolを使ってフラグID（Windows.Shell.TaskbarMultiPositiで始まる番号）を有効化する方法がInsiderコミュニティで共有されている。ただしExperimentalビルドの性質上、不具合のリスクは通常のInsiderビルドより高い点は念頭に置いておこう。 マルチモニター対応は現時点では部分的で、現行ビルドでは全モニターが同一の位置設定になる。モニターごとに異なる配置を設定したいという要望はフィードバックハブに多数集まっており、Microsoft側も制限を認識している。 実務への影響 日本のエンジニアやIT管理者にとって、この機能変更が直接業務効率に影響するかといえば「そこまで大きくはない」というのが正直なところだ。ただ、以下のシナリオでは明確なメリットがある。 縦型・ウルトラワイドモニター利用者: 横長画面でタスクバーを左右に配置することで、作業領域の上下幅を最大化できる macOSライクな上部配置: Dockに慣れた開発者がWindows環境に移行する際の学習コストを下げられる マルチモニター環境: 将来的にモニターごとの配置設定が実装されれば、用途別に最適化したレイアウトが組める 現時点でExperimentalビルドを本番環境に入れるのは論外だが、25H2（2026年10月予定）への昇格が実現すれば、企業展開での選択肢が増える。GPO経由での配置強制が可能になるかどうかも今後の注目点だ。 筆者の見解 正直に言えば、「タスクバーの位置変更」はWindowsを取り巻く大きな変化の中で優先度の高い機能ではない。AIとオートメーションが業務の根幹を変えつつある時代に、UIのカスタマイズに注力するのは「本当に重要な課題から目が逸れていないか」と感じる部分もある。 それでも、今回の対応には評価できる点がある。ユーザーが3年間言い続けたことにMicrosoftが応えたという事実だ。Windows 11の初期は「デザインの意図を押しつけすぎ」という批判が多く、それが機能面での信頼低下につながっていた。今回の方針転換は小さいようで、「ユーザーの声を聞くMicrosoft」への一歩として意味がある。 気になるのは「Experimental」という慎重すぎるほどの段階付けだ。タスクバーの位置変更はWindows 10時代に完成していた機能であり、アーキテクチャの再構築が必要だったとしても、Experimentalに留め置く理由がどこまであるのか。25H2への昇格を期待しつつ、「もう少し踏み切る力があるはず」と思う。 Windowsの底力はブランドとユーザーベースにある。その強みを活かして、ユーザーが本当に使いやすいと感じる方向に着実に積み上げていってほしい。 出典: この記事は Windows 11 Taskbar Finally Moves: Insider Experimental Adds Top, Left, Right Options の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはWindows 11において、MCP（Model Context Protocol）をOSレベルでネイティブサポートするWindows On-device Agent Registry（ODR）を導入した。これにより、AIエージェントがFile ExplorerやWindows Settingsといった基盤的なWindowsコンポーネントに直接接続できる環境が整い、Copilotをはじめとするエージェントがローカルのファイルやシステム設定を安全に操作できるようになる。 MCPとは何か——AIエージェントの「共通言語」 MCP（Model Context Protocol）はAnthropicが策定したオープンプロトコルで、AIアプリケーションと外部ツール・データソースを標準化された方法で統合するための仕様だ。MicrosoftはこのオープンプロトコルをWindowsに組み込むことで、AIアシスタントやエージェントがOSの各機能と会話できる共通インターフェースを提供する。 かつてWindowsがプリンタやネットワークアダプタのドライバモデルを標準化してデバイス対応の爆発的な広がりを可能にしたように、MCPの標準化はAIエージェントの接続先を急速に拡大させるポテンシャルを持つ。 Windows ODRの仕組み——エージェントの「住所録」 Windows ODR（On-device Agent Registry）は、Windowsにインストールされているローカルアプリと、ネットワーク上のリモートサーバー双方のMCPサーバーを一元管理するレジストリだ。エージェントはODRを参照することで「どんなMCPサーバーが使えるか」を自動的に発見・接続できる。 管理面ではodr.exeというコマンドラインツールが提供されており、開発者や管理者はMCPサーバーの一覧表示・登録・削除をCLIから操作できる。 利用可能なコネクタ——今すぐ使えるもの 現時点でWindowsが標準提供するコネクタは以下の通り： File Explorer MCP connector — ファイルやフォルダを対象に、コンテキストメニューからMCPサーバーのツールを呼び出せる。ファイル操作をAIエージェントが直接実行できる最初の接触面 Windows Settings connector — システム設定にエージェントがアクセスするためのコネクタ Visual Studio / VS Code（GitHub Copilot agent mode） — 開発環境からODR経由でMCPサーバーを利用可能 また、Microsoft Agent Frameworkを使えば独自のエージェントを構築し、ODR経由で各種MCPサーバーに接続するホストアプリを開発できる。 セキュリティ設計——サンドボックスとIntuneによる制御 セキュリティ面では、各MCPサーバーコネクタが独立したサンドボックス環境で動作する設計になっている。コネクタは承認されたリソースにしかアクセスできず、クロスプロンプトインジェクション攻撃などへの耐性を持つ。 エンタープライズ環境で特筆すべきは、Microsoft Intuneによるポリシー管理に対応している点だ。IT管理者はエージェントごとにMCPサーバーへのアクセス許可を制御でき、各接続のログと監査証跡も取得できる。ゼロトラスト的な観点で言えば、「誰が何のエージェントを通じてどのリソースにアクセスしたか」を追跡できる仕組みが最初から設計に織り込まれているのは重要だ。 なお、本機能は現時点でプレリリース段階であり、商用リリース前に仕様が変更される可能性がある。 実務への影響——日本のエンジニア・IT管理者が押さえるべきこと 開発者向け：VS Code + GitHub Copilot agent modeを使っている場合、追加セットアップなしにODRを通じたMCPサーバー接続が可能になる。odr.exeを使ったMCPサーバーの登録・管理も試しておく価値がある。Windows向けのMCPサーバーをどのように公開するかは、社内ツールのAIエージェント対応を考える上で早めに設計しておくべきテーマだ。 IT管理者向け：企業展開において重要なのはIntune連携だ。エージェントがODRを通じてどのMCPサーバーに接続できるかをポリシーで制御できることは、AI活用の「禁止」ではなく「安全に使える仕組み」を実現する上で大きな武器になる。現時点でプレリリースなのですぐに本番展開は避けるべきだが、テスト環境での検証と監査ログの設計は今から準備しておきたい。 Copilot利用者向け：File ExplorerのコンテキストメニューからAIエージェントのツールが呼び出せるようになるという変化は、日常業務に見えるレベルの体験変化だ。ファイル操作の自動化や検索・整理をCopilot経由で指示できる世界が現実に近づいている。 筆者の見解 MCPというオープンプロトコルをWindowsのOS基盤に組み込むという判断は、MicrosoftらしいOSプラットフォーム戦略の正統進化だと感じる。デバイスドライバの標準化、Windows Subsystem for Linuxの統合、そして今回のMCP統合——OSとしての「接続先の標準化」を継続的に行ってきた歴史の延長線上にある。 セキュリティ設計の方向性も悪くない。サンドボックス・Intune管理・監査ログという3点セットは、企業のIT部門が「AIエージェントを安全に展開する」ための必要条件を満たしている。ゼロトラストの観点でも、エージェントの行動を可視化・制御できる仕組みを最初から織り込んだのは正しい判断だ。 一点だけ率直に言えば、まだプレリリースの段階で「すごい機能が来た」と騒ぐよりも、実際に商用リリースされたタイミングでどこまで安定して使えるかを見極める冷静さが必要だ。Microsoftには、この方向性を崩さず着実に仕上げることを期待している。標準化の力を活かせる立場にあるのだから、ここで手を抜く理由はない。 ...

MicrosoftはWindows 11の2026年5月累積更新プログラム（KB5089549）において、一部デバイスでインストールが35%付近で停止しエラーコード「0x800f0922」が発生することを公式に認めた。原因はEFIシステムパーティション（ESP）の空き容量不足であり、Known Issue Rollback（KIR）による自動緩和策がすでに展開済みだ。 エラー0x800f0922の原因：EFIシステムパーティションの空き容量不足 ESP（EFI System Partition）はUEFIブートに不可欠なパーティションで、Windowsの起動ファイルやブートローダーが格納されている。今回のKB5089549ではESPへの一定量の書き込みが必要となるが、空き容量が10MB以下の環境では書き込みに失敗し、インストールが35%前後で止まってエラーを返すことが確認された。 特に問題になりやすいのは以下のケースだ： 数年前のPCでESPが100MB以下に設定されているもの 累積更新を重ねるうちにESPの空き容量が少しずつ圧迫されたデバイス サードパーティ製ツールや暗号化ソフトが追加ファイルをESPに書き込んでいる環境 KIR（Known Issue Rollback）とは MicrosoftはWindows 11でKIRという仕組みを導入している。問題のあるアップデートを自動的に「なかったこと」にするロールバック機能で、Microsoftが問題を検知すると約24時間以内に自動配信される。今回のエラー0x800f0922に対しても展開済みだが、Intuneや企業GPOで管理されていない「管理対象外デバイス」は手動対応が必要な場合がある。 IT管理者が取るべき対応 1. 影響範囲の確認 IntuneやSCCM/MECMを使っている環境では、更新失敗レポートをエラーコード「0x800f0922」で絞り込むとKB5089549の適用失敗デバイスを効率よく特定できる。 2. ESPの空き容量確認 管理対象デバイスでESPの空き容量が少ない場合は、不要ファイルの削除かESPサイズの拡張が必要になる。ただしESPのサイズ変更はリスクを伴う操作のため慎重な手順が求められる。以下のコマンドでESPをマウントして空き容量を確認できる： 出典: この記事は Microsoft confirms Windows 11’s May 2026 update is failing to install with error 0x800f0922 and outlines a mitigation for affected PCs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはCopilotをサイドバーのチャットアシスタントから自律エージェントのオーケストレーターへと転換する2026年ロードマップを公開した。Windows 12への標準搭載、OpenAIモデルに依存しないマルチモデル化、そしてAzureへの800億ドル超（約8兆円）の設備投資——この3本柱で同社はAIプラットフォームの全面刷新に臨む。 「エージェントファースト」とは何か これまでのCopilotはユーザーが質問を投げかけ、それに答えるという受動的な存在だった。2026年のCopilotはその概念を根本から変える。ユーザーのプロンプトを待つのではなく、複数のM365アプリをまたいでタスクを自律的に実行し、サードパーティサービスとも連携するエージェントとして機能するというものだ。 MicrosoftはこれをWindowsとAzureクラウドに深く組み込んだ「エージェントランタイム」で実現する。このランタイムはメモリを管理し、長期間にわたるタスクのコンテキストを維持し、セキュリティ境界を強制する。社内でコードネーム「Project Orchard」と呼ばれる商用版がCopilotの次世代バックエンドを担う予定だ。なお、MicrosoftはエージェントフレームワークとしてすでにAutoGenをオープンソースで公開しており、その商用展開がこの戦略の技術的な核となる。 Windows 12（2026年10月頃予定）には「Agent 365」とCopilot Chatが標準搭載される見込みで、旧Windows 11デバイスにはスリム版のエージェントランタイムが提供される。IT管理者向けには一元管理コンソールも整備される。 OpenAI依存脱却：マルチモデル戦略の意味 今回の発表で特に注目すべきは、MicrosoftがOpenAIモデル一本槍の戦略を捨て、「モデル非依存（model-agnostic）」のアーキテクチャへ舵を切ったことだ。 社内では「Copilot Fabric」と呼ばれるオーケストレーション層が構築されており、ユーザーのクエリをGPT-5、Claude 4、あるいはPhi-4のような小規模言語モデル（SLM）へ最適にルーティングする。AnthropicのClaudeモデルはすでにAzure AI Foundryに統合されており、Word・Excel・TeamsのCopilot体験のバックエンドとしてテストが行われている。 この変化の背景には、OpenAIが独自に大企業との直接取引を進めている現実がある。SalesforceなどへのOpenAI直接契約は、Microsoft経由でのAI販売というビジネスモデルに対するリスクとなり得る。マルチモデル化は技術的な最適化と同時に、ビジネスリスクへのヘッジでもある。 企業にとっては朗報だ。機密性の高いデータにはオンプレミスのLLMを、汎用タスクにはクラウドモデルを、コスト重視の処理にはSLMをと、ワークロードに応じてモデルを使い分けられる柔軟性が生まれる。 Azure 8兆円超の投資：その規模と意図 これらのAI戦略を支えるのが、2025年度に800億ドル超に達するAzureへの設備投資だ。2026年末までにH200やAMD MI300X GPUクラスターを備えたAzureリージョンを倍増させる計画で、独自開発のMaia 100アクセラレーターとCobalt 100 Arm CPUも大規模に展開される。 バージニア州では70万平方フィート（約6.5万平方メートル）のAI専用データセンターが稼働を開始し、アトランタ・フェニックス・日本の農村部でも大型施設の建設が進んでいる。日本向けのデータセンター拡張は、データ主権やコンプライアンスへの要求が強い日本の大企業にとっても、Azure採用のハードルを下げる材料になり得る。 実務への影響 IT管理者・情報システム部門へ：一元管理コンソールの整備は、これまでバラバラだったCopilot関連のポリシー管理を集約する第一歩だ。「どのモデルをどのワークロードに使うか」の制御も管理コンソールで行えるようになる見込みで、コンプライアンス要件のある組織には特に重要な変化となる。今から自組織のAIガバナンス方針を整備しておきたい。 エンジニア・開発者へ：Copilot StudioとAutoGenフレームワークへの理解が、次世代のM365カスタマイズに不可欠なスキルとなる。非開発者でもカスタムエージェントを構築できる流れが加速しており、「エージェントを設計・評価できる人材」の価値が上がる。今から触れておく価値は高い。 予算・調達担当へ：マルチモデル化により、Azure AI消費課金の構造が変わる可能性がある。どのモデルがどのタスクで呼ばれるかを把握しないと、予想外の課金につながりかねない。SLMを活用したコスト最適化の設計も重要なテーマになる。 筆者の見解 「エージェントファースト」への転換という方向性は、率直に言って評価できる。ユーザーがプロンプトを逐一書かなくても仕事が進む世界——それがAIの本来の姿だと思うし、Copilot Studioでの非開発者向け展開、マルチモデルによるワークロード最適化、一元管理コンソールの整備といった施策はどれも「正しい方向」だ。 ただ、Microsoftの発表と実際のプロダクト品質の間には、これまでたびたびギャップがあった。Copilotは何度も「革命」と位置づけられながら、現場のエンジニアや管理者にとってはまだ「使えるレベルになりきれていない」部分が残っている。マルチモデルという正しいアーキテクチャが、実際の体験品質の向上にどこまでつながるかは2026年を待って判断したい。 Microsoftには技術力も、ブランドも、何より膨大なエンタープライズユーザーベースがある。AIエージェントの戦場は、クラウドとOSを押さえた企業に最も有利なフィールドのはずだ。今回の戦略転換が言葉通りに実行されれば、その強みを最大限に発揮できる。正面から勝負できる力は十分にある。期待を込めて、2026年の実装を注視したい。 出典: この記事は Microsoft Copilot 2026: Agent-First AI Platform, Multi-Model, Azure & Data Centers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年5月22日、Windows 11 Insider Program向けに4つのビルドを同時リリースし、テストチャンネルの構造を根本から再編した。「Experimental」チャンネルが次期26H1機能アップデート対応と将来プラットフォーム向けの二重構造へと分割され、あわせて点字ディスプレイがUSB接続だけで設定不要で即利用できるHID対応も導入された。 チャンネル再編の全体像 今回同時リリースされた4つのビルドは以下のとおり。 チャンネル ビルド番号 位置づけ Beta 26220.8491 最も安定したプレビュー Experimental 26300.8497 旧Dev Channelの後継 Experimental (26H1) 28020.2149 次期機能アップデート向け Experimental (Future Platform) 29595.1000 将来プラットフォームの実験場 Windows Insider Programは2014年の「Fast/Slow Ring」から始まり、2020年のDev Channel追加、2023年のCanary Channel導入と変遷を重ねてきた。しかしDev Channelは「何が来るかわからないブラックボックス」という批判が続いており、今回の再編はその解消策だ。 ビルド番号が語る開発の深度 注目すべきはビルド番号の跳躍幅だ。BetaのRe26220から、Future Platformの29595まで——約3000ビルドの差は、Microsoftが複数年先の開発を並行して進めていることを示す。 Microsoftエンジニアは「29000番台はリリースするかどうかも決まっていない実験コード、プラットフォームを再考するためのサンドボックス」と表現している。28000番台のExperimental (26H1)は次期機能アップデートに向けたコードとして、比較的リリース確度が高い位置づけになる。 「Experimental (26H1)」というラベルで対象アップデートサイクルを明示したことは、Microsoftとしては珍しい透明性の発揮といえる。 点字ディスプレイのHID対応：地味に見えて大きな改善 今回のビルドで見逃せないのがアクセシビリティの強化だ。点字ディスプレイがUSB接続だけで即座に動作するHID（Human Interface Device）対応が実現した。 これまでは、デバイス固有のドライバーや専用ソフトウェアのインストールが必要だった。視覚障害を持つユーザーにとって「ドライバーを自分で探してインストールする」という作業自体が大きなバリアであったことを考えると、この改善の意義は数字には現れにくいが実際は大きい。 実務への影響 IT管理者・開発者が押さえるポイント 26H1ビルド（28020系）は互換性テストに有効: 次期機能アップデートで何が来るかを事前把握できる。社内アプリやグループポリシーの互換性確認に活用したい Future Platformビルド（29000系）は業務PCに入れてはいけない: 実験的すぎて業務運用には不適切。評価環境の専用機のみで確認する Beta Channelが引き続き実用的: 新機能の事前評価は、やはりBeta Channelが現実的な選択肢 Update後のトラブルは数日様子を見る姿勢も重要: Insider向けでなくとも、Windows Updateで問題報告が出るケースは増えている。数日待ってから適用する判断も立派なセキュリティ管理だ 企業IT部門にとっての整理 チャンネル体系が整理されたことで、「どのチャンネルで何を確認すればいいか」の社内基準を作りやすくなる。特に26H1ビルドの明示的な存在は、展開計画を立てる際の参照点として機能する。 筆者の見解 Windows Insider Programのチャンネル再編は、Microsoftがテスターや企業IT部門のフィードバックを受け取り、改善を重ねている証左として素直に評価できる。「このビルドは26H1向け」と明示することは、テストに参加するエンジニアだけでなく、社内の展開計画を立てる担当者にも実用的な価値をもたらす。 アクセシビリティ改善については、継続的な取り組みの姿勢を感じる。点字ディスプレイのプラグアンドプレイ対応は派手さはないが、本当に必要としているユーザーに届く改善だ。こういった積み重ねをMicrosoftにはもっと続けてほしいし、この方向性は正しい。 Future Platformの29000番台ビルドが何を示唆するのか——「Windows 12」なのか、それとも全く異なるアーキテクチャの実験なのか——はまだわからない。ただ、開発の透明性が増したことで、その正体に近づく手がかりがInsiderコミュニティから出てくることに期待している。日本語メディアでまだほぼ未報道の変更点でもあるため、IT部門のキャッチアップのきっかけになれば幸いだ。 出典: この記事は Windows 11 Insider May 22 Builds Unveil New Channel System and Accessibility Upgrades の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...