Windows

Windows 11 がリリースされて5年が経過したいま、Microsoft の Windows & Devices デザイン統括、Marcus Ash 氏が X（旧 Twitter）への投稿でコンテキストメニュー（右クリックメニュー）の改善計画を公式に認めた。「高速化」「デフォルト表示の簡素化」「ユーザーによる表示項目のカスタマイズ」の3点が柱になるという。 なぜ今さら？ Windows 11 コンテキストメニュー改悪の歴史 Windows 10 のコンテキストメニューは、Microsoft 自身が「20年間規制なく成長してきた」と認めるほど肥大化していた。カット・コピーといった基本操作がマウスポインタから遠い位置に表示されるなど、日常的な操作でストレスを生む構造になっていた。 Microsoft は Windows 11 のリリース時に「コンテキストメニューをモダンに、高速に、整理された形に刷新する」と約束した。角丸デザインや Fluent Design の採用で見た目は確かに新しくなった。しかし5年後の現実は次のとおりだ。 余白が大きく、Windows 10 版より縦方向に長くなった サードパーティアプリが追加する項目が増え続け、クラッター（散らかり） は解消されていない 旧来の項目にアクセスするには「もっとオプションを表示」から2段階操作が必要 Windows 11 はコンテキストメニューの根本問題を「解決した」のではなく、別の形に作り替えただけだったと言わざるを得ない。 改善の具体的な方向性 Marcus Ash 氏の投稿は短いが、3つの方向性が明確に示されている。 高速化: メニューの表示レイテンシを改善 デフォルトの簡素化: 初期状態で表示される項目を絞り込み、すっきりした初期表示を実現 カスタマイズ対応: ユーザーが「よく使う項目」を選んで表示できるようにする 詳細な実装方法は「近日中に共有する」とのことで、Canary チャンネルのビルドで早期テストが行われる可能性が高い。また、コンテキストメニューに限らず、タスクバーの位置変更など Windows 11 全体でカスタマイズ性を高める方向へと舵を切っており、Satya Nadella CEO が掲げる「ファンを取り戻す」基本回帰路線の一環として位置づけられている。 実務への影響——エンジニア・IT管理者が知っておくべきこと 企業展開では「仕様確認まで待ち」が無難 企業 IT 管理者にとって重要なのは、カスタマイズ機能が MDM（Intune）やグループポリシー で制御可能かどうかだ。ユーザーごとに自由にメニューをカスタマイズできる状態になると、サポート対応時に「担当者の画面と利用者の画面が異なる」問題が増える恐れがある。正式リリース後に管理オプションを確認してから展開計画を立てるのが安全だ。 サードパーティ回避ツールを使っているユーザーへ 現在 ExplorerPatcher などで旧 Windows 10 スタイルのコンテキストメニューに差し替えているユーザーは、公式のカスタマイズ機能が充実した段階で乗り換えを検討する価値がある。サードパーティツールは Windows アップデートで突然動作しなくなるリスクを常に抱えており、公式機能への移行は安定性の観点からも望ましい。 ...

Meta（旧Facebook）は、企業向けAIアシスタント「Meta Business Agent」（旧称：Business AI）を、WhatsApp・Instagram・Messengerの3プラットフォームで全世界に向けて正式ロールアウトした。これまで限定的に提供されてきた機能が、グローバルの事業者すべてに開放される形となる。 Meta Business Agentとは何か Meta Business Agentは、企業のメッセージングチャネルに組み込まれるAI自動応答エージェントだ。顧客からの問い合わせに24時間対応し、商品の案内・予約の受け付け・FAQへの回答などをAIが担う。企業側は自社のビジネス情報・商品カタログ・よくある質問などを事前に登録することで、AIがそれを参照しながら自然な会話形式で顧客と対話する仕組みだ。 「Business AI」から「Business Agent」へのリネームは単なる名称変更ではなく、位置づけの明確化でもある。従来の「AIアシスタント」という曖昧な概念から脱却し、「ビジネス上の具体的なタスクを実行するエージェント」として機能を強化していく方向性を示している。 3プラットフォーム展開の意味 今回の展開で重要なのは、WhatsApp・Instagram・Messengerという異なる性格を持つ3プラットフォームを横断している点だ。 WhatsApp: 企業対顧客のプライベートチャネルとして世界で最も普及。特に東南アジア・南米・欧州では主要ビジネスツールとして定着している Instagram: EC・ブランド・クリエイター経済と深く結びついたプラットフォーム。DM経由の購買導線が重要 Messenger: 北米中心にFacebookページと連携した顧客サポートチャネルとして機能 それぞれのチャネルで顧客が使い慣れたUIのまま、同一のAIエージェントが対応できるようになる点が企業にとってのメリットだ。 実務への影響 日本のECおよびD2C事業者 Instagramを活用した日本のD2C事業者・ファッション系ブランドにとって、自動応答の質が上がれば問い合わせ対応コストを大幅に削減できる。「在庫はありますか」「サイズはどう選べばいいですか」といった定型質問への対応を人的リソースなしで回せるようになる可能性がある。 WhatsApp非普及の日本市場 一方で、日本国内ではWhatsAppの利用率が低く、Metaのメッセージングプラットフォーム自体のプレゼンスが限定的だ。国内向けビジネスの主戦場はLINEであり、今回の展開がそのまま日本市場に直結するわけではない。ただし、グローバルに展開する日本企業（越境EC・インバウンド対応等）にとっては、WhatsApp上のビジネスエージェントは無視できない選択肢になる。 導入時の注意点 事前にビジネス情報・商品カタログの整備が必要（データが整っていないとAI応答の品質が下がる） 過度に自動化すると顧客体験が損なわれるケースがある。ハンドオフ設計（人間への引き継ぎ）を明確にしておくことが重要 多言語対応の精度は地域・言語によって差がある点を検証してから本番投入すること 筆者の見解 Metaのこの動きは、「顧客との接点をAIエージェントで標準化する」というトレンドの加速を示している。企業が自社でチャットボットを構築・運用するコストと手間を考えると、すでに数十億人のユーザーが使うプラットフォームにネイティブで統合されたエージェントを活用する選択は合理的だ。 ただし、企業が気をつけるべき点がある。MetaのプラットフォームにAI応答の核心部分を委ねることは、顧客データや会話ログが外部プラットフォームに蓄積されることを意味する。特にプライバシー規制が厳しい欧州や、独自のデータガバナンスを重視する大企業では、このトレードオフを慎重に評価する必要がある。 日本のIT現場では、「新しいツールが出たら試す」ではなく「どのチャネルに顧客がいて、どのチャネルでAI化することが最も効果的か」から逆算してほしい。Meta Business Agentが有効なのは、顧客がすでにMetaプラットフォームを使っている場合に限られる。日本国内向けビジネスでWhatsApp・Instagramに顧客がいないなら、いくら機能が良くても意味がない。 仕組みを自動化する際の原則は変わらない。「禁止するより安全に使える仕組みを整備する」「ボトルネックは人間の関与にある」。Meta Business Agentを使うにせよ使わないにせよ、顧客対応の自動化戦略を持たない企業がこれからの競争で生き残るのは難しい。 出典: この記事は Meta rolls out Meta Business Agent globally on WhatsApp, Instagram, and Messenger の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはBuild 2026（6月2〜3日、サンフランシスコFort Mason Center）において、Copilot+ PCのNPU（Neural Processing Unit）向けに最適化したオンデバイスAIモデル群をサードパーティ開発者へ開放することを正式に発表した。Windows AI Studio APIを通じた端末ローカル処理の実現に加え、社内製推論モデル「Project Athena」のお披露目、およびWindows 365 Developer Configurationのパブリックプレビュー開始も発表され、WindowsをAIオペレーティングシステムとして再定義する姿勢が鮮明になった。 NPUネイティブAI：オフラインで動くWindows AI基盤 Build 2026の最大の焦点は、Windows Copilot RuntimeのAPIをサードパーティアプリへ全面開放する点にある。Win32・UWP・WinUI 3アプリがWindows AI Studio APIを通じ、オンデバイスの言語理解・画像生成・リアルタイム音声書き起こしを数行のコードで呼び出せるようになる。データはクラウドに送出されないため、プライバシー保護・低レイテンシ・ランニングコスト削減という三つのメリットを同時に実現する。 対応NPUはQualcomm Snapdragon X・Intel Lunar Lake・AMD Ryzen AI 300シリーズ。Microsoftが公式に言及しているPhi-4-Silicon（38億パラメーター）はNPU向けに最適化した代表モデルで、メール要約や文書整形などをローカルで処理する。用途別に複数サイズのモデルが用意されており、テキスト分類・要約から文脈を踏まえたアプリ操作支援、さらに画像生成やコードデバッグまでカバーする構成だ。 LoRAカスタマイズで「業種特化AI」が現実に 注目すべきはモデルカスタマイズパイプラインの提供だ。合成データ生成とLoRA（Low-Rank Adaptation）を組み合わせ、Azure Machine LearningまたはローカルのWSL環境でベースモデルをファインチューニングできる。完成したアダプターはアプリと同梱してMicrosoft Storeで配布可能になる。 法務契約のレビュー支援・建築設計補助・科学記号の解析といった高度に専門化されたAIアシスタントを、従来のようにクラウドGPUを大量消費せずに提供できる点は、業務アプリ開発者にとって大きな転換点となる。 Project Athena：Microsoft独自の推論モデルが初披露 オンデバイスモデルと並行して、Microsoftは「Project Athena」と呼ばれる社内製推論特化モデルを披露した。複雑なクエリを段階的な推論チェーンに分解し、各ステップを外部知識ベースで検証しながら進めるアーキテクチャで、OpenAI o1やGoogle DeepMind Geminiの推論システムを直接意識した設計だ。Satya Nadella自らデモを行い、Microsoftがクラウドとエッジの両軸でAI能力の自前化を推進する姿勢を印象づけた。 Windows 365 Developer Configuration 開発者向けには、Windows 365 Developer Configuration（パブリックプレビュー）も発表された。クラウドPC上に開発環境を自動構成し、「数分でコーディングを開始できる」状態を提供するというもので、新メンバーのオンボーディングや複数プロジェクト間の環境切り替えでの活用が想定される。 実務への影響 日本のエンジニア・IT管理者が今すぐ動くべき点 1. データ主権の観点でオンデバイスAIを評価する　金融・医療・製造業など、クラウドへのデータ送信に社内規制がある現場では、NPUベースのオンデバイス処理は導入ハードルを大きく下げる。Copilot+ PC調達の意思決定において「NPU活用」を評価軸に加えるべき時期に来た。 2. Windows AI Studio APIを先行評価する　Win32アプリが対象に含まれるため、既存のレガシーアプリ資産を活かしたAI化が視野に入る。API公開後は早期にドキュメントを読み、既存の業務アプリへの組み込み可能性を探ること。 3. LoRAカスタマイズのユースケースを洗い出す　業界固有のドメイン知識が求められる業務では、ファインチューニングによる専門化が費用対効果の高い選択肢になりうる。Azure MLの既存環境があれば比較的すぐに試せる体制が整う。 ...

MicrosoftはWSL2（Windows Subsystem for Linux 2）のLinuxカーネルをLinux 6.6 LTSから最新の6.18 LTSへ大幅アップグレードし、新バージョン linux-msft-wsl-6.18.20.1 をGitHub上でリリースした。 WSL2カーネルがLinux 6.18 LTSへ刷新 WSL2はこれまでLinux 6.6 LTSをベースとしていたが、今回の更新でLinux 6.18.20 LTSへ移行した。6.6 LTSはすでに2世代前のLTSカーネルとなっており、アップグレードのタイミングとしては正直「ようやく」という印象だ。 LTS（Long Term Support）カーネルとは、メインラインのLinuxカーネルとは異なり、長期間にわたって安定したセキュリティパッチ提供が保証されるシリーズのこと。WSL2のように組み込み的な使われ方をするカーネルでは、安定性と新機能のバランスを取れるLTSの採用が定番だ。 主な変更点 アウトオブツリーパッチの削減 6.18へのリベースにより、6.6ベースでは維持が必要だったVirtIO PMEMサポート関連のアウトオブツリーパッチを削除できた。アウトオブツリーパッチとはLinuxメインラインに取り込まれていないMicrosoft独自の修正コードであり、これが減ることはメンテナンスコストの低下と将来的なアップストリーム追跡の容易化を意味する。 新たに有効化されたファイルシステム 今回のKconfig（カーネルビルド設定）の調整で、以下のファイルシステムサポートが追加された。 F2FS（Flash-Friendly File System）: Samsungが開発したフラッシュストレージ向けファイルシステム。SSDなどでの読み書き効率が最適化されており、開発環境のI/O性能向上に寄与する ExFAT: MicrosoftがUSB/SDカード向けに開発したファイルシステム。WindowsとLinux間のファイルやり取りが一層円滑になる ExFATはMicrosoft自身が開発したファイルシステムでありながら、WSL2カーネルへの有効化が今まで見送られていた点は少々興味深い。 その他のKconfig変更 ANON_VMA_NAME: 匿名メモリマッピングに名前をつけられる機能。プロファイリング・デバッグ時の可観測性が向上する CANサポート: 車載ネットワーク（Controller Area Network）関連オプションの追加。組み込みや自動車分野の開発者にとって恩恵がある ジョイスティックインターフェース・USBモニターサポート: 各種周辺機器のサポートを拡充 ARM64ビルド: FAT系ファイルシステムのみに絞り込み、余分なビルドオプションを整理 実務への影響 Windowsで開発するLinux開発者へ WSL2ユーザーへの即効性が高いのはファイルシステム周りの改善だ。ExFATのネイティブサポートにより、Windowsドライブとのファイル共有互換性が向上する。WindowsとLinux環境を行き来する機会が多い開発者には、余計なフォーマット変換作業が減るという実感が得られるはずだ。 F2FS有効化はSSDを使う開発環境でのI/Oパフォーマンスに寄与する可能性がある。Dockerコンテナを多数立ち上げたり、大規模なビルドを繰り返す用途では特に効果が出やすい領域だ。 エンタープライズIT管理者へ アウトオブツリーパッチの削減は、セキュリティパッチの適用サイクルをアップストリームのLinuxカーネルに近づける効果がある。既知脆弱性へのパッチがより早く提供されやすくなるため、WSL2を業務環境で許可している組織ではこのカーネル更新の積極的な適用を検討してほしい。 6.18 LTSへの移行により、今後数年は安定したLTSサポートが継続される見込みだ。長期的なWSL2運用計画を持つ組織にとって、このタイミングでの基盤刷新は安心材料になる。 筆者の見解 Windowsの細かい更新を逐一追う時代はとっくに終わっていると思っているが、このWSL2カーネルアップグレードはその例外に値する話だ。 MicrosoftがWSL2を単なる「おまけ機能」ではなく、本気でLinux開発環境として育てているという姿勢が、今回の更新からも伝わってくる。アウトオブツリーパッチを削ってアップストリームに近づける判断は、長期メンテナンスの観点から見ても正しいアプローチだ。 ただ、ExFATの件は思わず苦笑してしまった。自社開発のファイルシステムが、自社のWSL2カーネルに今まで入っていなかったというのは、組織内の連携がいかに難しいかを物語っている。今回ようやく有効化されたわけだが、これをむしろ「WindowsとLinuxのシームレスな統合」を本腰入れて整備していく第一歩と前向きに捉えたい。 WSL2がここまで実用的な開発環境に育ったのは事実であり、WindowsプラットフォームでLinuxカーネルをまともに動かし続けているエンジニアたちの継続的な努力には素直に敬意を表したい。カーネル更新のサイクルをもう少し短縮できるよう、今後も地道な改善を続けてほしいところだ。 出典: この記事は Microsoft Upgrades Its WSL2 Kernel Against Linux 6.18 LTS の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Microsoftは2026年6月9日リリース予定のWindows 11セキュリティアップデートで、アプリ起動速度を最大40%向上させる「Low Latency Profile」をはじめ、カメラの複数アプリ同時共有やNPU使用状況モニタリングなど6つの主要機能改善を盛り込んだ。 Low Latency Profile——地味だが体感が変わるパフォーマンス改善 今回の目玉は「Low Latency Profile」と呼ばれるパフォーマンス最適化機能だ。アプリの起動時間が最大40%、スタートメニューをはじめとするUI操作のレスポンスが最大70%改善されるという。 数字こそ派手だが、実態は地道な内部改善だ。Windowsは長年、バックグラウンドプロセスの処理タイミングやCPUスケジューリングに課題を抱えていた。Low Latency Profileはそのスケジューリングを見直し、ユーザーのインタラクティブ操作を優先する仕組みに改める。「スタートメニューの動作がもたつく」という長年のユーザー不満に正面から向き合った形だ。 カメラを複数アプリで同時利用できるように これまでWindowsでは、Webカメラなどのカメラデバイスをあるアプリが使用中は他のアプリからアクセスできなかった。6月更新ではこの制限が緩和され、Microsoft Teams・Zoom・OBSのような複数アプリが同時にカメラ映像を共有できるようになる。 リモートワークや配信・録画を行う現場にとっては待望の機能だ。「Teamsで会議中にOBSで録画したい」という用途はこれまで仮想カメラドライバーで無理やり対処するしかなかったが、OS標準でサポートされることでトラブルの温床が一つ消える。 Windowsサーチの2文字対応 Windows検索がこれまでの最低3文字入力から2文字入力に対応する。地味に見えるが、「az」「ai」「vs」のような短い略称でのアプリ・ファイル検索がスムーズになる実務的な改善だ。検索を多用する開発者や管理者ほど恩恵を感じやすい。 タスクマネージャーにNPU使用状況が表示 AIアクセラレーターとして注目されるNPU（Neural Processing Unit）の使用率がタスクマネージャーに追加される。どのアプリがどれだけNPUを消費しているかをリアルタイムで確認できるようになる。 Copilot+ PC対応デバイスが市場に広がりつつある今、「NPUが本当に動いているのか」を把握するための第一歩として意義がある。パフォーマンストラブルの診断や、AIワークロードの実態把握に活用できる。 実務での活用ポイント 展開のタイミングは慎重に判断する: 最近のWindowsアップデートは「適用後に問題発生」という報告も珍しくない。業務クリティカルな環境では、リリース直後に全端末へ一斉展開するのではなく、パイロット端末で数日様子を見てから広域展開するのが現実的な運用だ。数日の猶予を置くこと自体がリスク管理の一環と捉えてほしい。 カメラ共有はリモートワーク環境の整備に直結: TeamsとZoomを使い分けながら会議録画もしたい、といったマルチアプリ運用がOS標準でサポートされる。ただし複数アプリが映像を同時利用する場合、品質への影響を事前に検証しておくと安心だ。 NPU対応端末の調達判断材料として: タスクマネージャーでNPU稼働を可視化できるようになったことで、次の端末更新サイクルでNPU搭載モデルを選定する際の実データを収集しやすくなった。AI機能を業務に取り込む計画があるなら、今からNPU使用状況を記録しておく価値がある。 筆者の見解 率直に言えば、今回のアップデートは地味だが「正しい方向を向いている」改善だと思う。 Low Latency Profileは、いかにも「なぜ今まで」案件だ。スタートメニューの動作が遅いというのはWindows 10の頃からあった課題で、Microsoftが腰を上げて改善に着手したこと自体は素直に評価したい。70%改善という数字が実際にどれだけ体感できるかは使ってみてわかることだが、こうした地道な積み重ねがOS全体の信頼感を底上げする。 カメラの複数アプリ同時共有は、正直もっと早く来るべきだった機能だ。ハイブリッドワークが当たり前になって数年経つのに、こうした「痒いところに手が届かない」部分が残っていたのはもったいない。ただ、遅まきながら標準対応したことは前向きに評価したい。 NPU表示については、まだ「可視化しました」段階に過ぎない。今後のWindowsがNPUを真に活用した体験を提供できるかどうかが本当の勝負どころだ。エンジニアリング力は本物なのだから、ぜひ次のステップを見せてほしい。 これだけの改善をまとめてリリースできる実力はやはり侮れない。その力をもっと一貫したビジョンに向けて投じてくれれば、と感じるアップデートだった。 出典: この記事は Here are the 6 biggest features and improvements coming to Windows 11 in the June 2026 update on Tuesday の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleがGeminiのAIモデル訓練を強化するため、Google Play Storeに登録しているデベロッパーに対し、実際のアプリコードを有償で提供するよう打診していることが明らかになった。競合するAIコーディングツールに対する遅れを取り戻すべく、実世界の高品質なコードベースを直接調達するという異色の戦略だ。 なぜ今、Googleは「コードを買う」のか コーディング支援AI市場は現在、急速に成熟しつつある。GitHub Copilot、Claude Codeといったツールが実務現場で広く使われる中、GeminiベースのGoogle Code Assistは「使えるが一歩及ばない」という評価が定着しつつある。 AIモデルの性能を左右する要素の一つが訓練データの質だ。GitHubやStackOverflowなどの公開コードは既に多くのモデルが活用しているため、差別化するには「実際にリリースされ、本番稼働しているアプリのコード」という、より実態に即したデータが必要になる。Play Storeには数百万本ものAndroidアプリが登録されており、それらの実コードはAI訓練の観点からは極めて価値が高い。 仕組みと条件はどうなっているのか 現時点で公式に詳細は発表されていないが、報道によるとGoogleはPlay Store登録デベロッパーに対して報酬を提示し、コードへのアクセス許可を求めている。これはオプトイン形式であり、強制ではない。 ポイントは「同意した開発者のコードのみを使う」という姿勢だ。近年、AIトレーニングデータをめぐる著作権訴訟が相次いでいる状況を踏まえると、Googleが法的リスクを回避しながら質の高いデータを確保しようとしている意図が読み取れる。 日本のエンジニア・IT管理者への実務的影響 デベロッパー視点 Play Storeにアプリを公開している日本の開発者にとっては、コードという資産を収益化できる可能性が生まれている。ただし、参加前に確認すべき点がある： ライセンス条件の精査: 提供したコードがどのように使われるか、Googleのポリシーを読み込む必要がある クライアントや雇用主との契約確認: 業務委託や社内プロジェクトのコードを含んでいる場合、独自に同意できるかは契約次第 機密ロジックの分離: 参加するならば、競合優位性の核となるビジネスロジックは含めない形での提供を検討する IT管理者・CTO視点 社員が個人や副業でPlay Storeアプリを開発している場合、そのコードに業務由来のコードが混入していないかのガバナンスが問われる場面が出てくるかもしれない。AI活用が広がるにつれ、コードの帰属と利用範囲に関する社内ポリシー整備が急務になってきている。 Geminiのコーディング能力は変わるのか データ品質の向上はモデル性能に直結するが、それだけでトップクラスに追いつけるほど単純ではない。モデルアーキテクチャ、推論最適化、UIとのインテグレーションなど、ユーザー体験を決める要素は多岐にわたる。ただ、「生きた実装コード」の大量確保という方向性は、長期的には競争力強化に寄与し得る。 筆者の見解 この動きは、AIコーディングツール市場が「モデルの優劣」から「データの優劣」へ競争軸がシフトしている局面を象徴している。公開リポジトリのスクレイピングという手法が訴訟リスクを孕む時代に、有償での同意取得というアプローチは合理的だ。 一方で、日本のIT現場への影響を考えると、やや複雑な気持ちになる。多くの企業がまだ「AIをどう使うか」を議論している段階にある中、AIを作る側の競争はもう「どんなデータを持っているか」というフェーズに入っている。この非対称なスピード感は、日本のIT業界が意識しておくべきギャップだ。 Geminiが実務品質のデータを積み重ねてどこまで成長するか——その答えが出るのは1〜2年後だろう。コーディングAIの選択は、ツールだけでなくエコシステム全体（IDE統合、認証基盤、コスト構造）で判断するのが現実的だ。どのツールを使うにせよ、自分で使い倒して自分の評価を持つことが、情報に踊らされないための唯一の手段だと感じている。 出典: この記事は Google wants to pay Play Store developers for code to train its AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

セキュリティ企業McAfeeは2026年6月、Minecraftプレイヤーを標的にしたマルウェアキャンペーン「WeedHack」が今年1月以降116,000台以上のシステムへの感染を確認したと報告した。偽Modや不正クライアントをYouTubeとSEO操作で拡散するMaaS（Malware-as-a-Service）型の手口は、ゲームコミュニティを狙った攻撃の巧妙さを改めて浮き彫りにしている。 感染経路：YouTube動画とSEO汚染の二本立て WeedHackの感染経路は主に2つある。ひとつはYouTube上でのMod紹介動画だ。説明欄やコメント欄に悪意あるダウンロードリンクを埋め込み、プロのナレーション付きの本格的な動画で信頼感を演出する。なかには再生回数が7,500回を超える動画も確認されている。 もうひとつはSEO汚染だ。「Meteor Client」「LiquidBounce」「Wurst Client」「LiquidBounce」「Impact Client」といった実在する人気Minecraftクライアントのキーワードを悪用し、偽サイトを検索上位に表示させる。さらに巧妙なのは、本物のGitHubリポジトリやDiscordサーバーへのリンクを偽サイトに貼り付け、「公式サイトからのみダウンロードせよ」という警告文を表示することで、偽の信頼性を作り上げているケースだ。 McAfeeによれば、240以上の配布URLと3,820件のユニークな悪意あるJARファイルが確認されており、1日あたり2,000〜3,000件のペースで感染が継続している。被害は米国・ドイツ・インド・英国に集中している。 「サービス型マルウェア」として誰でも購入可能 WeedHackが特に注目を集めるのは、そのビジネスモデルだ。ダッシュボードがクリアネット上で無料公開されており、技術的な知識がほぼなくても攻撃を実行できる。 無料プランの機能 Minecraft セッションIDの窃取 36種類のブラウザから保存パスワード・Cookieを取得 56種類の暗号資産ブラウザ拡張、12種類のデスクトップウォレットアプリへの対応 Discord・Steam・Telegram認証情報の窃取 スクリーンショット取得 有料プラン（月額$5 / 買い切り$24.99） マウス・キーボードによる遠隔操作（RAT機能） Webカメラアクセス キーロガー リモートシェル ファイル管理 月額$5という驚異的な低価格で遠隔操作ツール一式が揃うことが、感染規模拡大の大きな要因だ。McAfeeはTelegramチャンネルの800人超のメンバーの多くをティーンエイジャーや若年成人と分析しており、被害者へのハラスメントにも悪用されているとしている。 日本のIT管理者・保護者が今すぐすべきこと Minecraftは国内でも学校・家庭を問わず幅広い年齢層に普及している。以下を早急に確認してほしい。 エンドユーザー・保護者向け MinecraftのModやクライアントは公式Marketplace・GitHubの公式ページ以外からは絶対にダウンロードしない JARファイルはVirusTotalなどでスキャンしてから実行する YouTubeの説明欄リンクは盲目的に信頼しない。チャンネルの開設日や登録者数も確認する Discordリンクに見せかけた偽装が横行しているため、URLのドメインを必ず目視確認する IT管理者・企業セキュリティ担当向け 社内端末でMinecraftが稼働している場合、JARファイルの実行ポリシーを見直す EDR（エンドポイント検出・応答）でJARファイルのダウンロード・実行を検知・ブロックするルールを設定する ブラウザ保存パスワードを狙う攻撃が増加しているため、パスワードマネージャーへの移行を推奨する 筆者の見解 WeedHackで最も注目すべきは、攻撃の「参入障壁」がここまで下がった事実だ。月額$5で遠隔操作ツール一式が手に入り、技術知識がなくてもそれなりの攻撃が実行できる。かつて高度なスキルが必要だったインフォスティーラー運用が、今では中高生でも試みられる水準に達してしまった。 JARファイルはJavaベースのため、Windowsだけでなくmacへの波及も理論上あり得る。しかし日本では「ゲームのModは子供の遊び」と軽視され、保護者世代にこのリスクがほとんど届いていない。 「禁止ではなく安全に使える仕組みを」が筆者の基本スタンスだ。Minecraftをプレイするなではなく、公式Marketplaceを使えばこのリスクはほぼゼロになる。ユーザーにとって「正規の方法が一番便利」と感じさせる環境を整えることが、こうした攻撃を未然に防ぐ最も現実的な対策だ。MinecraftのMarketplaceというエコシステムに投資してきたMicrosoftの判断が、こうした事案で正しかったと改めて証明される形になっている。 セキュリティとゲームは相反するように見えて、「ユーザーが安心して楽しめる公式エコシステムを育てる」という点では同じ方向を向いている。今回の件が、保護者やIT担当者がMinecraftのセキュリティリスクを真剣に考えるきっかけになってほしい。 出典: この記事は Over 116,000 Mincraft systems infected in WeedHack malware campaign の内容をもとに、筆者の見解を加えて独自に執筆したものです。

WordPressの人気ビジュアルビルダープラグイン「Kirki」に、未認証の攻撃者が管理者アカウントを含む任意のユーザーアカウントを乗っ取れる重大な権限昇格脆弱性（CVE-2026-8206）が発見され、すでに実際の攻撃に悪用されていることが確認されている。 脆弱性の概要 対象プラグインの正式名称は「Kirki - Freeform Page Builder, Website Builder & Customizer」。フリーフォーム型のビジュアルビルダーと高度なテーマカスタマイザーを提供しており、世界で50万以上のウェブサイトで利用されている。 今回の脆弱性はバージョン6.0.0の主要アップデートで導入されたもので、6.0.0〜6.0.6までのバージョンが影響を受ける。WordPress.orgのダウンロード統計によれば、この範囲に該当するバージョンを利用しているサイトはユーザーベース全体の約40%に上る。 攻撃の仕組み 脆弱性の根本原因は、プラグイン内の handle_forgot_password() 関数が公開するカスタムRESTエンドポイントの実装ミスにある。 通常のパスワードリセット処理では、リセットリンクはアカウントに登録されたメールアドレスにのみ送信されるべきだ。しかし今回の欠陥では、攻撃者が任意のメールアドレスをリセット先として指定できてしまう。攻撃者がターゲットのユーザー名を入力すると、プラグインはそのアカウントに対して有効なパスワードリセットリンクを生成し、アカウント所有者のメールではなく攻撃者が指定したメールアドレスに送信してしまう。 この欠陥を利用することで、認証不要・事前知識なしでサイト上の任意ユーザーのパスワードリセットリンクを取得し、アカウントを乗っ取ることができる。管理者アカウントを乗っ取れれば、悪意あるプラグインのインストール、コンテンツの改ざん、Webシェルやバックドアの設置、プライベートデータベースへのアクセスといった深刻な被害が生じうる。 発見と修正のタイムライン 日付 内容 2026年5月4日 セキュリティ研究者CHOIGYENGMINがWordfenceに報告 2026年5月16日 Wordfenceがプラグインベンダーに通知 2026年5月18日 バージョン6.0.7で修正版リリース 2026年6月2日（現在） Wordfenceのファイアウォールが過去24時間で222件以上の攻撃をブロック すでに積極的な悪用が確認されており、攻撃のハードルも極めて低い。 実務への影響 今すぐ確認・対応すべきこと： 即座にバージョン6.0.7へアップデートする。WordPressの管理画面から「プラグイン → 更新」で確認できる。6.0.0〜6.0.6を使用している場合は今すぐ対応が必要だ 一時的に無効化する選択肢も有効。すぐに更新できない環境では、プラグインを無効化してリスクを遮断する Wordfenceなどのセキュリティプラグインを導入する。WAF（Webアプリケーションファイアウォール）により、パッチ適用前でも攻撃をブロックできる 管理者ログインの監査ログを確認する。すでに侵害されていないか、不審なログインや設定変更がないか確認する WordPress管理者アカウントの数を最小化する。最小権限の原則を徹底し、不要な管理者アカウントを整理する 複数のWordPressサイトを管理している場合は、MainWPやManageWPのようなマルチサイト管理ツールを使って一括で更新状況を把握することを強く推奨する。 筆者の見解 セキュリティ案件はどうしても「細かい人が多い」のでやや苦手意識があるが、今回の脆弱性は技術的な観点から見て非常に興味深い。パスワードリセットという「当然安全であるべき」フローに潜むこうした欠陥は、認証まわりの実装がいかに難しいかを改めて示している。 WordPressのエコシステムは強力だが、サードパーティプラグインへの依存が構造的なリスクを生み続けている。「使いやすいから」「無料だから」という理由でインストールしたプラグインが、気づかぬうちにサイト全体への侵入口になる——これは珍しい話ではない。 ゼロトラストの観点からすれば、「このプラグインは信頼できるはず」という前提自体が危うい。最小限のプラグイン構成、定期的な棚卸し、未使用プラグインの即削除、これらはWordPressサイトの基本的な衛生管理として定着させるべきだ。 今回のように修正版がすでにリリースされているケースでは、対応は明快だ。「更新する」——これだけでいい。問題は、50万サイトの40%がまだ脆弱なバージョンを使っているという現実のほうで、更新の告知が届いていても実際に動く組織がいかに少ないかを如実に示している。セキュリティ対応は「知っているかどうか」よりも「実際に動けるか」が勝負になる。 出典: この記事は Critical Kirki flaw exploited to hijack WordPress admin accounts の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAI は 2026 年 6 月、GPT-5.5 Instant の品質向上アップデートを静かに配信するとともに、推論モデル o3 と GPT-4.5 の ChatGPT からの廃止スケジュールを公式に明らかにした。モデルの刷新と終了が同時進行するという、AI 業界の足の速さを改めて示す動きだ。 GPT-5.5 Instant が「人間らしさ」を強化 GPT-5.5 Instant は 4 月 23 日のリリース以降、5 月を通じて段階的な改善が続いていた。今回のアップデートで OpenAI が特に力を入れたのが 回答スタイルの刷新 だ。 これまで AI ツールにありがちだった「長くて箇条書きだらけの回答」を意図的に減らし、より自然な会話調の文体に切り替えるという方針を打ち出した。実際の業務相談や日常的な問い合わせで「いかにも AI らしい」テンプレート感が薄れ、回答が読みやすくなることが期待される。 OpenAI はさらに、実務的なサポートタスクでの 応答ペースの最適化 も改善対象としており、今週のアップデートを経て体感が変わるとしている。 o3・GPT-4.5 の廃止スケジュール モデル ChatGPT 廃止日 猶予期間 GPT-4.5 2026年6月27日 30日 o3 2026年8月26日 90日 ChatGPT の有料ユーザー（Plus・Pro）向けに提供されてきた両モデルが順次終了となる。o3 については比較的落ち着いた受け止め方がされている一方、GPT-4.5 は「GPT-4o に近い感触で、より人間的だった」という評価から愛用者も多く、惜しむ声が出ている。 OpenAI の狙いは明確で、旧世代モデルを終了させることで、新世代モデルへのコンピューティングリソースを集中させる戦略だ。 求人検索機能も ChatGPT に統合 モデル刷新と並行して、ChatGPT に 求人検索機能 が追加された。Indeed・Upwork・Appcast といった主要求人プラットフォームと連携し、ユーザーのスキル・経験・目標に基づいてパーソナライズされた求人リストをリアルタイムで表示する。 さらに履歴書の作成・編集・プロフェッショナルフォーマットでのエクスポートも強化され、就職活動の一連のフローを ChatGPT 上で一元完結させることを目指す。機能は全世界で順次展開中だ。 実務への影響——API 利用者は要注意 ChatGPT の UI 上だけの話ではない。 API 経由で o3 や GPT-4.5 を組み込んでいるシステムも、廃止スケジュールの影響を受ける可能性がある。社内ツールや自動化パイプラインで旧モデルを指定している場合は、今から代替モデルへの移行計画を立てておく必要がある。 ...

MicrosoftはWindows Insider Preview（Canaryチャンネル）向けに、長年にわたってセキュリティ上の懸念であり続けたNTLM認証への依存を段階的に解消するための新機能「IAKerb」と「LocalKDC」を今月後半にパブリックプレビューとして提供開始すると発表した。 NTLMはなぜ問題なのか NTLM（NT LAN Manager）は1990年代から使われてきた認証プロトコルで、今でもWindowsの多くの場面で「フォールバック」として動き続けている。問題は、NTLMがPass-the-Hash攻撃やNTLMリレー攻撃といった横展開（ラテラルムーブメント）の格好のターゲットになる点だ。 Kerberosへの完全移行が「理想」として語られて久しいが、現実の企業環境では次のような理由でNTLMが残り続けてきた。 クライアントからドメインコントローラー（DC）への直接経路がない（ネットワーク分割など） ローカルアカウントを使った認証フロー ワークグループ・スタンドアロン環境 DCへの到達性が限られるネットワーク構成 この「使いたくないけど使わざるを得ない」状況を打開するのが、今回発表の2機能だ。 IAKerb：DCへの直接経路がなくてもKerberosで通す IAKerb（Initial and Pass-Through Authentication using Kerberos）は、クライアントがDCへ直接通信できない環境でも、Kerberos認証を維持する仕組みだ。 通常のKerberosでは、クライアントはDCと直接やり取りしてチケットを取得する必要がある。ネットワークセグメント分割や、クラウド接続型の構成ではこの経路が確保できないケースがある。IAKerbでは、この場合に接続先サービス自体がKerberosの中継（プロキシ）役を担うことで、NTLM へのフォールバックを回避する。 つまり、クライアントがサービスには届くがDCには届かない環境でも、Kerberosベースの認証パスを維持できる。このプレビューではIAKerbはデフォルトで有効となる。 LocalKDC：ローカルアカウントにもKerberosを LocalKDCはWindows上で動作するローカルのKey Distribution Center実装だ。これまでローカルアカウントを使ったマシン間認証は、ほぼNTLM一択だった。LocalKDCはこのギャップを埋め、以下のようなシナリオにKerberos的な保護を持ち込む。 ワークグループ環境・スタンドアロンデバイス ローカルアカウントによるリモートリソースへのアクセス ドメインインフラを持たない小規模・P2P環境 管理者アカウントやファイルアクセスでローカルIDが使われるシナリオ なおLocalKDCは今回のプレビューではデフォルト無効。段階的な評価を想定した構成だ。 レジストリキーによる設定方法 パブリックプレビュー段階では、Group PolicyやMDMによる管理はまだ提供されていない。設定は以下のレジストリ値で行う。 レジストリ値 0（有効） 1（無効） DisableIAKerb IAKerb有効 IAKerb無効 DisableLocalKDC LocalKDC有効 LocalKDC無効 レジストリ値が存在しない場合はリリースのデフォルト動作が適用される。現プレビューではIAKerbが有効（0）、LocalKDCが無効（1）がデフォルトだ。 実務への影響：今から動けること このプレビューは企業のIT管理者・セキュリティ担当者にとって、「NTLMをいつどうやって止めるか」を計画するための重要な準備期間となる。 今すぐ取り組むべきこと： NTLMの利用状況を可視化する — Windows 11 24H2/Server 2025から強化されたNTLM監査ログを活用し、まだNTLMが使われている場所を特定する。IAKerb・LocalKDCが対応できるシナリオかどうかの仕分けが第一歩。 テスト環境でInsider Buildを評価する — 本番前に社内アプリケーション、SMB共有、リモート管理ツールがKerberosで動くかを確認する。特にNTLMを前提に作られたレガシーアプリは要注意。 SPN（サービスプリンシパル名）設定の棚卸し — Kerberosへの移行時に最も多い障害がSPN設定の不備。ここを整備しておくことが、将来のNTLM無効化に向けた地盤固めになる。 ワークグループ・スタンドアロン環境を把握する — LocalKDCが特に効くシナリオ。製造現場や小規模拠点などでローカルアカウントが使われているケースを事前に洗い出す。 筆者の見解 NTLMはずっと「消えるはずなのに消えない」プロトコルだった。Kerberosへの移行が叫ばれ続けて十数年、それでもネットワーク分割やローカルアカウントの都合でNTLMが生き残り続けてきた。IAKerbとLocalKDCは、その「仕方なく残っているNTLM」を段階的に置き換えるための、ようやく現実的な手段といえる。 ゼロトラストの観点でも、NTLMが残っている限りはリレー攻撃の経路が閉じられない。「NTLMを無効にしたいが現実的に無理」という組織の言い訳が、これで一つ減ることになる。 Microsoftのこの取り組み自体は、正しい方向に進んでいると思う。ただ、エンタープライズ側の準備が追いつくかどうかが問題だ。特に日本の大企業環境では、レガシーなNTLM依存アプリが膨大に眠っていることが多い。Group PolicyやMDM管理がまだ未提供という点も含め、「プレビューの今から評価を始める」姿勢を持つ組織とそうでない組織の差は、数年後に大きく開くだろう。 Microsoftには、Group Policy/MDMサポートの早期提供と、移行を助けるツール・ガイダンスの充実を期待したい。これは技術の正しい進化であり、その努力をきちんと実務に届く形にしてほしいと思う。 ...

MicrosoftがWindows 365およびAzure Virtual Desktop（AVD）向けに「コンテキストベースのリダイレクト（Context-based redirections）」のパブリックプレビューを開始した。デバイスの管理状態やコンプライアンス準拠状況といった文脈情報に基づき、クリップボードやUSBなどのデータパスを動的に制御できる新機能で、BYOD環境におけるデータ保護の粒度が大きく向上する。 コンテキストベースのリダイレクトとは 従来のWindows 365やAVDにおけるリダイレクト設定は「一律適用」が基本だった。組織全体でクリップボードのコピー＆ペーストを許可するか禁止するか、という二択に近い状態である。 今回パブリックプレビューとなった機能は、Microsoft Entraの条件付きアクセス（Conditional Access）の認証コンテキスト（Authentication Context）と組み合わせることで、以下のシグナルに基づいてリダイレクト設定を動的に変更できる。 デバイスの管理状態（Intune管理済みかどうか） コンプライアンスの準拠状況（ポリシー違反がないか） ユーザーまたはグループのメンバーシップ ネットワーク条件（企業ネットワーク内かどうかなど） 端的に言えば「信頼できるデバイスからのセッションには多くを許可し、管理外デバイスからのセッションには制限する」という、ゼロトラストの考え方に沿ったアダプティブ制御が実現する。 パブリックプレビューの対象リダイレクション 今回のパブリックプレビューでは以下4種類が制御対象となる。 リダイレクション 制御対象 クリップボード ローカルデバイスとリモートセッション間のコピー＆ペースト ドライブ・ストレージ ローカルの固定ディスク・リムーバブルストレージ・ネットワークドライブ プリンター リモートセッションからローカルプリンターへの印刷 USB USBデバイスのリモートセッションへのリダイレクト 対応クライアントはWindows・Web・Android・iOS・macOS上のWindows Appと専用VMセッション。 設定の流れ セットアップは3ステップで完結する。 Entra認証コンテキストの作成: Microsoft Entra管理センターで「認証コンテキスト」を定義する。信頼レベルの識別子となる 条件付きアクセスポリシーの作成: 作成した認証コンテキストに対して条件付きアクセスポリシーを適用する（対象デバイスのコンプライアンス状態やグループ等を条件に設定） Windows 365リモート接続エクスペリエンスポリシーの設定: Windows 365の設定カタログから、ターゲットリダイレクションに対して認証コンテキストを要求するよう構成する 注意: 既存ポリシーでリダイレクションを無効化している場合、「最も制限的な設定が優先される」原則により、コンテキストベースのリダイレクトが機能しない可能性がある。テスト前に既存ポリシーを「未構成」または「有効」に変更しておく必要がある。また、テスト用に専用のパイロットデバイスグループを作成してから試すことをMicrosoftは推奨している。 実務への影響 BYODポリシー再設計のチャンス 日本企業でも「スマートフォンはOK・個人PCはNG」「在宅勤務時は制限あり」といったBYOD運用の差別化ニーズは根強い。これまでは管理者が手動でグループを切り分けたり、利用シナリオごとに別ポリシーを作成する必要があった。コンテキストベースのリダイレクトにより、同じポリシーセットでもセッションの信頼レベルに応じて制御が自動的に変わるため、管理負荷を下げながらセキュリティ強度を上げることが可能になる。 ゼロトラスト移行の実践的ステップとして 「デバイスコンプライアンス × セッション信頼レベル × リソースアクセス制御」の組み合わせは、ゼロトラストアーキテクチャの中核をなす考え方だ。VDI環境（Windows 365/AVD）を持つ組織にとって、このパブリックプレビューへの参加は、ゼロトラスト実装を具体的に前進させる絶好の機会と捉えてよい。 筆者の見解 正直に言うと、セキュリティ系の細かいポリシー管理は筆者が得意とするジャンルではない。設定項目が増えるたびに「複雑化して誰かが必ずやらかす」と感じてしまうからだ。 ただ、今回のコンテキストベースのリダイレクトは技術的な発想として面白い。条件付きアクセスという組織にすでに定着している仕組みを拡張してVDIのリダイレクション制御に繋げる設計は、新たなレイヤーを無理やり追加するのではなく、既存のゼロトラスト投資を活かしている点で筋がよい。「禁止か許可か」の二択から脱却し、セッションの文脈に応じて動的に制御するアプローチは、現場のユーザー体験とセキュリティの両立という観点で大事な一歩だ。 一方で気になるのは、まだポリシー結果確認機能（RSOP: Resultant Set of Policy）が開発中という点だ。どのポリシーが実際に効いているかをその場で確認できない状態では、トラブル発生時の切り分けが辛い。「最も制限的な設定が勝つ」という動作原則は意図せず全部ブロックされる事故を招きやすく、RSopなしではデバッグに時間がかかる。パブリックプレビュー中にRSOPが実装されることを期待したいし、Microsoftにはここをきちんと仕上げてからGA（一般提供）に踏み切ってほしいところだ。Entraとの統合という設計方針は正しい。あとはその完成度が問われる。 出典: この記事は Adaptive data protection with context-based redirections in Windows 365, now in public preview の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftがWindows 11のオプション更新KB5089573（May 2026）で、セットアップ時にユーザープロファイルフォルダ名を任意に指定できる機能を正式リリースした。Microsoftアカウントのメールアドレス先頭5文字が自動的にフォルダ名になるという長年の問題が、ようやく解消される見通しだ。 何が変わったのか これまでWindows 11では、初回セットアップでMicrosoftアカウントを使ってサインインすると、C:\Users\ 以下のプロファイルフォルダ名がメールアドレスの先頭5文字から自動生成されていた。rachel@example.com なら rache、ebibibi@gmail.com なら ebibi といった具合だ。数字や記号がメールの先頭に含まれていた場合は、より奇妙な文字列になることもあった。 新しいセットアップフローでは、デバイス名入力ページにユーザーフォルダ名の設定欄が追加され、自分で好きな名前を指定できるようになった。この変更は2026年3月のInsider Preview Build 26300.8068で先行導入されており、今回のKB5089573で一般ユーザー向けに展開された。2026年6月のPatch Tuesday（セキュリティ更新）で必須更新として広く配布される予定だ。 開発者・IT管理者への影響 「フォルダ名が変なだけでしょ？」と思うかもしれないが、実際にはシステム管理や開発環境に深刻な影響を及ぼしてきた。 ビルドスクリプトのパス問題が最も代表的だ。CIパイプラインや自動化スクリプトは C:\Users\[username]\ へのハードコードされたパスを含むことが多い。トランケートされた予測不能な文字列が生成されると、スクリプトがファイルを見つけられずに失敗するケースが頻発していた。 環境変数や設定ファイルの互換性も問題になりやすい。%USERPROFILE% や %HOMEPATH% を参照するツールは多いが、パスに日本語や記号が含まれるとさらにトラブルが起きやすくなる。フォルダ名が予測可能な英数字で統一できれば、これらのリスクは大幅に下がる。 企業展開（イメージベースのデプロイ）の観点でも、フォルダ名を標準化できることで管理ポリシーの一貫性が保ちやすくなる。 重大な制限：既存環境には適用されない 今回の変更には大きな但し書きがある。フォルダ名のカスタマイズはデバイスの初回セットアップ時にしか行えない。 すでにセットアップ済みのPCで奇妙なフォルダ名を抱えているユーザーは、Windowsを再インストールしない限り恩恵を受けられない。Microsoftも現時点では既存ユーザー向けのリネームツールを提供していない。 ただし、実際にフォルダ名を変更すると、レジストリの ProfileList キーやシェルショートカット、アプリケーションのパス設定など多岐にわたる整合性の問題が発生するため、既存環境への後付け対応が難しいのは技術的にも事実だ。 実務での活用ポイント 新規PC展開・VM構築時は必ずKB5089573を適用してからセットアップする。Patch Tuesday適用済みの最新ISOを使うか、先にオプション更新を手動インストールしてから初期設定を行う 命名規則を決めておく。企業展開なら [社員番号] や [名前のローマ字] など統一ルールを設けると後々の管理が楽になる Autopilot・Windowsイメージ展開を使っている場合は、セットアップフローの変更に注意。OOBE（Out-of-Box Experience）のカスタマイズスクリプトや設定プロファイルの見直しが必要になる可能性がある 個人ユーザーはPC買い替え時が好機。次にWindows PCを新品で購入したとき、あるいはクリーンインストールするタイミングで自分の名前を正しく設定できる 筆者の見解 率直に言えば、「なぜここまで時間がかかったのか」という気持ちが先に来る。この問題はWindows 10時代から指摘され続けており、解決策が技術的に複雑なわけでもない。ユーザビリティの基本中の基本である「自分のフォルダ名くらい自分で決めたい」という要望に、何年もかかって応えた形だ。 とはいえ、ようやく動いたことは素直に評価したい。特に開発者や企業IT管理者にとって、プロファイルパスの予測可能性は地味だが確実に作業効率に効いてくる部分だ。 Microsoftには、こういった「ずっと変だとわかっていた細部」をもっと積極的に直してほしい。大きな機能追加も大切だが、毎日触れるセットアップ体験の品質が上がることで、Windows全体への信頼感は確実に底上げされる。既存ユーザー向けのリネームツールについても、検討を続けてもらいたいところだ。 なお、6月のPatch Tuesdayで必須更新として配布される予定のため、法人環境で展開タイミングを管理している場合は更新ポリシーとの整合性を事前に確認しておくことを勧める。 出典: この記事は Microsoft is killing Windows 11’s awkward 5-letter user folder name after years of complaints, but only for new setups の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftはBuild 2026で、GNU CoreutilsのRust実装「uutils」をベースにした「Coreutils for Windows」を一般公開（GA）した。あわせて、サードパーティのコンテナランタイム不要でLinuxコンテナをWindowsネイティブ実行できる「WSLコンテナ」機能のパブリックプレビューも近く開始すると発表している。 Coreutils for Windows とは何か ls、cp、mv、grep、sedといったUnix/Linux系の基本コマンドラインツール群「GNU Coreutils」は、Linux開発やCI/CDパイプラインで日常的に使われる存在だ。従来、Windowsでこれらを使うにはCygwin、Git for Windows、またはWSL（Windows Subsystem for Linux）に頼る必要があった。 今回GAとなった「Coreutils for Windows」は、GNU CoreutilsをRust言語で一から再実装したOSSプロジェクト「uutils」をベースとしている。Rustによる再実装は単なる移植ではなく、メモリ安全性の向上とパフォーマンス改善を兼ね備えた刷新だ。これによってWindowsネイティブ環境でLinux系コマンドが動作し、シェルスクリプトやCI/CDパイプラインのポータビリティが大幅に向上する。 WSLコンテナ：Dockerなしでコンテナを動かす WSLコンテナは、Docker DesktopやRancher Desktopといったサードパーティ製コンテナランタイムなしで、WindowsネイティブにLinuxコンテナを実行できる機能だ。現行のWSL 2はLinuxカーネルを軽量VM上で動かす仕組みだが、WSLコンテナはWSLインフラにコンテナ実行を直接統合することで、より軽量なコンテナ環境の実現を目指している。 パブリックプレビューはまもなく開始予定で、Kubernetes開発環境やマイクロサービスのローカル実行など、開発者が日常的に行うコンテナワークロードへの対応が期待される。 なぜRust実装が重要なのか uutilsがRustで実装されている点には技術的な必然性がある。GNU Coreutilsの原典はC言語で書かれており、バッファオーバーフローといったメモリ安全性リスクを内包している。Rustはコンパイル時にメモリ安全性を保証する設計で、セキュリティ要件の高いエンタープライズ環境での利用に適している。MicrosoftはWindowsカーネルコンポーネントへのRust採用も進めており、Coreutils for WindowsはそのRust化戦略のひとつとして位置づけられる。 実務への影響 CI/CDパイプラインの統一化 LinuxとWindowsの両方でビルドエージェントを運用している開発チームにとって、CoreutilsがWindowsでネイティブ動作することは、シェルスクリプトの書き分けコストを削減するチャンスだ。Linuxエージェントでは動くスクリプトがWindowsエージェントでは動かないという問題が頻繁に発生していたが、互換性の壁が一段低くなる。 Dockerレス開発環境の現実性 WSLコンテナが安定すれば、企業利用に有料ライセンスが必要なDocker Desktopを省略した軽量な開発環境構築が可能になる。特に中小企業やスタートアップでは、ライセンスコストの削減につながる可能性がある。 クロスプラットフォーム対応の標準化 Kubernetesクラスター向けコンテナイメージの開発を、MacだけでなくWindows PCでも完結させやすくなる。開発環境をWindowsに統一したい企業にとっては、選択肢が一つ増える形だ。 筆者の見解 Coreutils for WindowsとWSLコンテナは、「Windowsを本気の開発機にする」という方向性の積み上げとして、着実な前進だと評価している。 特にRust実装という判断は、単なるトレンド追従ではなく、セキュリティと保守性の観点で合理的な選択だ。C言語ベースのコードをそのまま持ち込むより、Rustで再実装してから統合する方が、長期的な脆弱性リスクを抑えられる。こういった地道な基盤整備こそ、エンタープライズで長く使われるソフトウェアの土台になる。MicrosoftがWindowsカーネルへのRust採用と同じ流れでCoreutils を整備している点は、一貫した戦略として評価したい。 WSLコンテナについては、プレビューが始まるまで実力は未知数だ。コンテナのネットワーク統合、ボリュームマウントの安定性、Kubernetes互換性といった実用面のクオリティが整って初めて「使えるツール」になる。期待はしているが、リリースされたら手を動かして確かめるのが先だ。 MicrosoftのWSL周りの取り組みは、長年の地道な積み上げがある。大きな発表よりも、こういった縁の下の力持ち的な改善を着実に続けてきたのがWindowsの強みだった。WSLコンテナが正式リリースに至るまでの道のりを、引き続き注目していきたい。 出典: この記事は Microsoft Announces Coreutils for Windows and Built-In WSL Containers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11の検索機能に長年のユーザー不満を解消する2つの改善を順次展開している。2文字入力でのファイル検出と、複合名ファイルを部分一致で発見できるサブストリング検索の導入だ。 何が変わるのか 2文字でファイルを発見——KB5089573 2026年5月のオプション更新プログラム KB5089573 で展開中の改善では、Windows Searchが「2文字入力でファイルを検出・優先表示できる」ようになった。 これまで「XP」と打っても壁紙ファイルはヒットせず「XPS Viewer」が出るだけ、という体験をしていたユーザーには覚えのある現象だろう。更新適用後は、「XP」と打つだけで関連するローカルファイルが即座に浮かび上がる。 ただし、Microsoftの段階的機能展開（Controlled Feature Rollout）により、KB5089573を適用済みでも全端末に即時反映されるわけではない。しばらく様子を見る必要がある。 複合ファイル名をどこからでも検索——サブストリング検索 もう一方の改善「Search by Substring」は、現在Windows 11 Insider Preview（Build 26300.8553 / Build 26220.8544）で展開中だ。 例として公式が挙げているのが StartMenuComparisonMay のようなファイル名だ。従来は先頭から一致する文字列を入力しなければヒットしなかった。新機能では「May」「Menu」「Comparison」のいずれを打っても正しいファイルが表示される。 Microsoftの説明を引用すると、 「MeetingNotesApril、ProjectStatusReportのような複合名のファイルが、‘april’や’status’と入力するだけで簡単に見つかるようになります」 これは単なる利便性向上ではない。実務では 2024Q3_Draft_v2_final_FINAL.xlsx のような名前が普通に存在する。それを「最初の数文字を思い出さなければ見つからない」検索に合わせてファイル名を付け直す作業は、本末転倒だった。 ローカルファイル優先への方針転換 一連の改善と並行して、MicrosoftはWindows 11の検索結果からBingのウェブ結果をローカルファイルより優先する動作も廃止する方向を示している。この3点セット——2文字検索・サブストリング・ローカル優先——が揃うと、Windows Searchの使用感はかなり変わる。 背景にあるのは2026年3月20日に公開されたMicrosoftのブログ「Our commitment to Windows quality」だ。検索を「アプリ・ファイル・設定を明確に表示して正しい結果に素早くたどり着けるようにする」と明言しており、今回の展開はその約束の具体化にあたる。 実務での活用ポイント すぐ使えるヒント: KB5089573を確認する: 設定 → Windows Update → 詳細オプション → オプションの更新から適用可能か確認する。段階的展開なので表示されない場合もある ファイル名の命名規則を緩められる: サブストリング検索が安定すれば、先頭一致を意識した不自然な命名ルールを見直せる。20260601_MeetingNotes_Product.docx のような自然な複合名が検索で問題なく引っかかるようになる Insider環境での先行確認: Experimental / Betaチャンネルに登録している環境があれば、サブストリング検索は今すぐ評価可能だ IT管理者へ: 段階的展開のため、組織内で体験の差が出る期間がある。ヘルプデスクへの問い合わせ対応として「Search改善は順次展開中」と周知しておくと無用な混乱を避けられる。 筆者の見解 Windowsのデスクトップ検索が「使えない」というのは、もはやIT業界の共通認識と言っていい。ファイルを探すためにわざわざExplorerを開いてフォルダを掘っていく習慣が根付いてしまったのは、検索への不信任票の積み重ねだ。 サブストリング検索と2文字検出は、技術的には決して難しい実装ではない。macOSのSpotlightやLinuxのAnythingが何年も前からやってきたことだ。それがようやく来た、というのが正直なところで、「革新」と呼ぶのは大げさかもしれない。しかし、実際に使えるレベルになることの価値は小さくない。 Microsoftには「Our commitment to Windows quality」で示した約束を着実に実行し続けてほしい。地道な改善こそが、日常の生産性を底上げする。Windowsは今でも何億人ものビジネスパーソンが使う土台だ。その土台が静かに、確実に良くなることは、派手な新機能よりも長期的なインパクトが大きい。口先だけでなく、このペースで実装を続けられるかが問われる。 ...

MicrosoftはWindows 11のMay 2026 Patch Tuesday更新プログラム（KB5089549）が一部のPCで35〜36%のタイミングで失敗する問題の原因を特定し、修正を含む任意更新プログラムKB5089573（Build 26200.852）を公開した。 何が起きていたのか 2026年5月12日にリリースされたKB5089549は、Windows 11 25H2・24H2・それ以前のバージョンを対象としたPatach Tuesdayアップデートだ。「Xboxモード for デスクトップ」やexplorer.exe関連の修正など実用的な変更を含んでいたが、一部ユーザーからインストール失敗の報告が相次いだ。 症状は以下のとおりだ。 ダウンロード自体は正常に完了する 再起動後の適用フェーズで35〜36%前後でフリーズ スピナー画面が表示されたのち、Windowsが変更のロールバックを開始 「計画どおりに進みませんでした。変更を元に戻しています」というメッセージが表示される Windows Updateの履歴にエラーコード0x800f0922が記録される C:\Windows\Logs\CBS\CBS.logをイベントビューアーで確認すると、EFIシステムパーティションの空き容量不足が記録されている EFIシステムパーティション（ESP）とは何か EFIシステムパーティション（ESP: Extensible Firmware Interface System Partition）は、WindowsがPCを起動するために必要なブートファイルを格納する特殊なパーティションだ。UEFIファームウェアはFAT32フォーマットされたこのパーティションに依存してWindows Boot Managerを読み込む。ESPが存在しなければPCはそもそも起動しないという、ファイルシステム上で最も重要なパーティションのひとつである。 ESPはWindowsセットアップ時に自動生成され、ファイルエクスプローラーからは非表示になっている（意図的に隠されている）。通常は256MB前後が確保されており、Windows本体が継続的に書き込みを行う領域ではないため、通常は60〜80%の空き容量が保たれる。 しかしOEMによるBIOSアップデートなどを繰り返すと、ESPに不要なファイルが蓄積されて空き容量が圧迫されることがある。Microsoftによれば、ESPの空き容量が10MB以下になるとWindows Updateの適用に失敗する可能性がある。 自分のPCのESP空き容量を確認する方法 管理者権限のPowerShellで以下のコマンドを実行することで確認できる。 出典: この記事は Microsoft confirms Windows 11 update is failing on some PCs, explains if you need a workaround の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AMDが台湾・台北で開催されたComputex 2026において、新型GPU「Radeon RX 9070 GRE」を発表した。NvidiaのRTX 5060 Tiがミドルレンジ市場を独走する中、AMDがついに本格的な対抗馬を投入した形だ。 RX 9070 GREとはどんなGPUか GREは「Great Radeon Edition」の略で、中国市場向けに先行投入された経緯を持つが、今回のComputex発表ではグローバル展開が示唆されている。RX 9070シリーズはAMDのRDNA 4アーキテクチャを採用しており、以下の点が注目される： FSR 4対応: AMDの最新アップスケーリング技術で、機械学習ベースの高品質なアップスケーリングをサポート RDNA 4アーキテクチャ: 前世代から大幅に改善されたレイトレーシング性能を搭載 価格帯の競争力: RTX 5060 Tiと同等価格帯でのポジショニングを狙う なぜRTX 5060 Tiがこれほど強かったのか NvidiaのRTX 5060 Tiは、Blackwellアーキテクチャを採用しながら比較的手頃な価格を実現し、ミドルレンジ市場での圧倒的なシェアを確保してきた。特にDLSS 4のクオリティと対応タイトルの多さが、GeForce選択の強い動機となっていた。 一方AMDは、RDNA 3世代でドライバー品質やソフトウェアエコシステムの面での批判を受け、ゲーマーの信頼回復に取り組んできた経緯がある。今世代はその反省を踏まえた投資が実を結びつつある。 FSR 4の急成長が大きな追い風 AMDのFSR 4（FidelityFX Super Resolution 4）はすでに300タイトル超のゲームで対応済みだ。これは単なる数字以上の意味を持つ。ゲーマーがAMD GPUを選ぶ際の「ソフトウェアエコシステムへの不安」が着実に解消されつつある証拠だからだ。 RX 9070 GREはこのモメンタムを活かす絶好のタイミングで投入される。対応タイトルが増え続けるFSR 4と組み合わさることで、製品単体の性能以上の価値を提供できるポジションに立っている。 実務への影響——クリエイターとIT担当者へ ゲーミング用途だけでなく、動画制作・3Dレンダリング・機械学習の推論処理を行うクリエイターやエンジニアにとっても、このGPU競争は注目に値する： 価格競争の恩恵: AMD vs Nvidiaの競争が本格化することで、両社の価格に下押し圧力がかかる可能性がある ROCmエコシステムの拡充: AMDのROCm（GPU向けオープンコンピューティングプラットフォーム）への投資も続いており、推論ワークロードの選択肢が広がりつつある 複数ベンダー調達戦略の現実性: ゲーミングPCやワークステーションの法人調達において、単一ベンダー依存を避ける選択肢として現実味が増してきた 筆者の見解 AMD vs Nvidiaの競争が再び健全な緊張感を取り戻しつつあることは、業界全体にとって歓迎すべき動きだ。独走状態が続くと価格設定やロードマップに緩みが生じるのは市場の必然であり、対抗軸が生まれることで消費者の選択肢が広がる。 RDNA 4世代でAMDはアーキテクチャを大幅に見直し、特にレイトレーシング性能とドライバー安定性の改善に力を入れてきた。その成果とFSR 4という強力なソフトウェア資産が揃った今、「AMDはどうせ……」という固定観念でスキップするのはもったいない局面かもしれない。 とはいえ、Computex発表から実際の発売・サードパーティレビューまでには時間差がある。購入の最終判断は実機ベンチマークが出揃ってからで十分だ。情報を追い続けるよりも、実際に使って成果を出すことに意義がある——まずは発売後のレビューをじっくり確認したい。 出典: この記事は Computex 2026: AMD finally answers Nvidia’s free-ruling 5060 Ti with RX 9070 GRE の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

JetBrainsは、コード補完に特化したAIモデル「Mellum 2」をオープンソースとして公開した。前世代の「Mellum」も昨年オープンソース化されており、今回はその後継として12Bパラメータを持つ強化版が登場した形だ。 Mellum 2とは何か Mellumは、JetBrainsが自社IDE（IntelliJ IDEA、PyCharm、GoLandなど）向けに開発したコード補完専用のAIモデルだ。汎用LLMとは異なり、「コードを書く」という単一タスクに絞って最適化されている点が特徴で、前世代モデルから大幅に増えた12Bパラメータにより、より精度の高い補完と文脈把握が可能になったとされる。 オープンソース化により、モデルの重みとアーキテクチャが公開される形となる。これはJetBrainsにとって透明性の向上であると同時に、コミュニティによる改善・応用への道を開くものでもある。 なぜこれが重要か コード補完AIの世界は、GitHub Copilot（OpenAI）、Amazon Q Developer、TabNineなど、大手テックベンダーが覇権を争う激戦区だ。その中でJetBrainsが独自モデルを自社IDEに統合し、さらにオープンソースとして公開するという動きは、エコシステム戦略として注目に値する。 特に注目すべき点は「IDE統合型」であることだ。コード補完の精度は、モデル単体の性能だけでなく、IDEがどれだけ正確なコンテキスト（カーソル位置、型情報、プロジェクト構造など）をモデルに渡せるかに大きく依存する。JetBrains製IDEは静的解析とAST（抽象構文木）処理に強みを持っており、Mellum 2はその情報を活かした補完が期待できる。 また、オープンソース化により、企業がモデルをオンプレミス環境に展開し、コードを外部に送信せずに利用できる可能性も広がる。情報セキュリティ要件が厳しい金融・公共系の現場にとっては、実用上の選択肢が増えることを意味する。 実務への影響 JetBrains IDEユーザーへの直接的な恩恵 すでにIntelliJ IDEAやPyCharmを使っているエンジニアは、Mellum 2の恩恵をIDEのAIアシスタント機能を通じて享受できる。特にJavaやKotlin、Pythonの大規模コードベースで作業している場合、型推論と組み合わせた補完の精度向上は実感しやすいだろう。 オンプレ展開・カスタマイズの検討 オープンソース化されたモデルはHugging Faceなどを通じて入手・利用できるようになる可能性がある。自社データでファインチューニングするか、クラウドサービスとして利用するかは、コンプライアンス要件とコストのバランスで判断したい。特に金融・医療・官公庁案件では、コード補完AIの選定において「社外にコードを送らない」という条件が決め手になるケースが増えている。 導入前に確認すべきこと JetBrains AIサブスクリプションとの関係（どの機能がMellum 2ベースか） ライセンス条件（商用利用・改変の可否） オンプレ展開に必要なハードウェアスペック（12Bパラメータは推論コストも相応） 筆者の見解 コード補完AIは今や開発ツールの「あって当たり前」の機能になりつつある。Mellum 2のオープンソース化は、JetBrainsがモデルの透明性とコミュニティへの関与を重視するという明確なメッセージだと捉えている。 個人的に興味深いのは「汎用か専用か」という設計の選択だ。12Bという規模は汎用LLMとしては小さいが、コード補完という絞られたタスクに集中することで、実用的な速度と精度のバランスを狙っているように見える。情報を追い続けるよりも、自分の開発環境に組み込んで実際に使い比べてみるのが、いまの時代の正しいアプローチだと思う。 セキュリティ意識の高い現場では、コードをクラウドに送らずに補完AIを使えるという選択肢は今後ますます重要になる。Mellum 2がその文脈でどれだけ現実的な選択肢になれるか、引き続き注目したい。 出典: この記事は JetBrains open-sources Mellum 2, featuring 12B total parameters の内容をもとに、筆者の見解を加えて独自に執筆したものです。

サイバーセキュリティ企業 Silent Push の研究チームが、「DriveSurge」と追跡している脅威アクターによる大規模マルウェア配布キャンペーンを公表した。数千件の正規 Web サイトを改ざんし、ClickFix および FakeUpdates（FakeUpdate）という2つのソーシャルエンジニアリング手法を組み合わせて訪問者にマルウェアを感染させる仕組みが明らかになっている。 DriveSurge とはどんな脅威アクターか DriveSurge は Initial Access Broker（IAB）、つまり「侵入口を売る業者」として機能している。自身が最終的な攻撃を仕掛けるのではなく、感染端末へのアクセス権を Pay-Per-Install（PPI）モデルで他の攻撃者に販売するビジネスモデルだ。 踏み台となるのは、評判の高い正規 Web サイト。改ざんされたサイトに埋め込まれた JavaScript（t.js?site=<id> というパターン）が、訪問者を zTDS（Traffic Distribution System） に誘導する。zTDS は 2015 年から存在するオープンソースの TDS で、DriveSurge は少なくとも 2025 年 9 月から使用している。 zTDS は訪問者をプロファイリングし、ClickFix か FakeUpdates のどちらの「罠」が有効かを自動判定して振り分ける点が特徴的だ。 ClickFix と FakeUpdates：それぞれの手口 ClickFix 「技術的な問題を解決するために、このコマンドを実行してください」と誘導し、Windows の PowerShell コマンドをコピー＆実行させる手口。ユーザー自身に悪意あるコマンドを実行させるため、エンドポイントセキュリティをすり抜けやすい。今回のキャンペーンでは macOS をターゲットにした亜種も確認されており、クリップボードを乗っ取る「verification テーマ」のページが macOS ユーザーに表示されていた。Windows だけの問題ではない。 FakeUpdates Chrome・Firefox・Edge・Safari・Opera・Brave・Yandex・Vivaldi・Samsung Internet・UC Browser と、ほぼすべての主要ブラウザーになりすました偽アップデート画面を表示し、悪意あるペイロードをダウンロードさせる。Silent Push が確認した事例では、偽 Firefox アップデートが ZIP ファイル（複数の DLL と Browser Update.exe）を展開していた。 調査で判明したインフラ規模 Silent Push の研究チームは DriveSurge のインフラに関連する 8 つの技術的フィンガープリントを特定。これを起点に 80 以上の悪意ある注入ドメインと、まだ攻撃に使われていない「準備済みドメイン」のセットも発見している。攻撃インフラが計画的に用意されていることを示しており、今後さらなる拡大が懸念される。 ...

2026年6月1日、MicrosoftはCopilot製品群の課金モデルを定額制から従量制へと移行した。AIクレジットとトークン消費量に基づく新しい計算方式が導入され、企業ユーザーの間では想定外の請求額、いわゆる「メーターショック」への警戒感が高まっている。特にCopilot Studioを活用したエージェント自動化を進めていた組織では、早急なコスト管理体制の見直しが求められる。 何が変わったのか：定額制から消費ベースへ 従来のMicrosoft 365 Copilotは、ユーザーあたり月額固定料金で提供されていた。しかし今回の変更により、Copilot Studioを中心とした機能群が「利用した分だけ支払う」方式に移行した。 メッセージの送受信、AIエージェントの実行、外部システムとの連携、ドキュメント処理といった各操作が消費ユニットとしてカウントされ、月次の利用量によって請求額が変動する。従来の「ライセンスを買えば使い放題」という感覚で運用を続けると、思わぬ請求額が届くことになる。 AIクレジットとトークンコストの仕組み 新課金体系の主な構成要素は以下の通りだ。 AIクレジット アクション単位で消費される仮想通貨のような存在。Copilot Studioでのエージェント呼び出しや外部コネクタとの連携操作1回ごとに消費される。多くのM365ライセンスには月間一定量のクレジットが付属しているが、それを超えた分は追加請求となる。 トークンコスト 入出力テキストの長さに比例して課金される。長い会議録の要約、大量のメール整理、複雑なプロンプトを使ったドキュメント生成などは、それだけトークン消費が増える。「ちょっと試しに」の積み重ねが月末に大きなコストになることがある。 利用状況の確認方法 Microsoft 365管理センター内の「Copilot使用状況レポート」や、Azureコストマネジメントポータルのメーター表示でリアルタイムの消費状況を確認できる。まずはここを開いて現状を把握することが第一歩だ。 メーターショックが起きやすい3つのシナリオ 1. SharePoint/Teamsでの大量ドキュメント処理 長い議事録や添付ファイルを繰り返しCopilotに要約させると、トークン消費が急速に積み上がる。特に全社展開で「全員が毎日使う」運用になっているケースは要注意だ。 2. 外部コネクタ連携 SalesforceやSAPなど外部システムとのCopilot統合は、CRM/ERPへのAPI呼び出しのたびにクレジットを消費する。連携数が多い企業ほどベースラインコストが高くなる。 3. エージェントのバックグラウンド自動実行 Power Automateと連動してエージェントが夜間・週末に自動動作するシナリオでは、誰も気づかないうちに大量消費が発生しうる。スケジュール実行のエージェントは特に使用量上限の設定が必須だ。 実務への影響：IT管理者が今すぐ取るべき行動 即時対応 M365管理センターで「Copilot利用状況レポート」を確認し、現在の消費ペースと予測コストを把握する Copilot Studioの管理コンソールでテナントレベルの月間クレジット上限を設定する 自動実行エージェントの一覧を洗い出し、不要なものは停止・削除する 中期的な対応 エンドユーザーへの周知：「長い文書をそのまま貼り付けるとコストがかかる」という意識を浸透させる プロンプト標準化：部門ごとに効果的な短いプロンプトをテンプレート化し、無駄なトークン消費を削減する ユースケース別ROI評価：実際に業務価値を生んでいないCopilot利用を特定し、コスト削減対象とする 筆者の見解 Copilotの従量制移行は、「使った分だけ支払う」という原則を徹底する動きであり、方向性としては理解できる。定額制では利用実態と収益が乖離しやすく、ヘビーユーザーが全体のコスト構造を圧迫するという課題が実際にあった。 ただし、正直なところ気になるのはコストの透明性だ。Copilotはチャットのような直感的なUIで操作できる設計になっているが、「この操作でクレジットがいくら消費されたか」がリアルタイムで把握しにくい。Azureのコストマネジメントは後からしか確認できないケースも多く、メーターショックが起きてから対応するのでは遅い。 Microsoftには優れたエンタープライズ管理基盤がある。Cost Management、Entra、Intuneを組み合わせれば、本来は細粒度なコスト制御ができるはずだ。その力をCopilotのコスト可視化にも正面から活かしてほしい。従量制への移行を機に、「費用対効果を定量的に示せるCopilot」として生まれ変わる契機にしてもらえることを期待したい。コストが明確になれば、ROIの出るユースケースと出ないユースケースがはっきりする。それはむしろ、正しい使い方が広がるチャンスでもある。 出典: この記事は Copilot to Usage Billing June 1, 2026: AI Credits, Token Costs, and Meter Shock の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月24日を期限として、Windows 11を含む対象PCユーザーに対しSecure Boot証明書を新しい2023年版へ更新するよう緊急呼びかけを行った。期限切れ後もPCは通常起動できるが、ブートレベルのセキュリティ保護が受けられなくなるリスクが生じる。 Secure Boot証明書とは何か Secure Bootは2011年にWindows 8とともに登場したセキュリティ機能だ。OSが起動する前にブートローダーやドライバーが正規のデジタル署名を持つかどうかを確認し、改ざんされた悪意あるコードの実行を防ぐ。この署名の正当性を保証するのが「Secure Boot証明書」であり、当初から使われてきた証明書が2026年6月24日に失効する。 期限切れで何が起きるのか 証明書が失効しても、PCが即座に起動不能になるわけではない。しかし次のリスクが現実のものとなる。 新しいブートレベルのセキュリティ更新が適用されなくなる：以後リリースされるSecure Boot関連の保護が機能しない状態になる Secure Boot依存の機能が動作しなくなる可能性：BitLockerや一部のTPM連携機能、セキュリティソフトウェアに影響が出るケースがある ブートキット攻撃への脆弱性が高まる：攻撃者がブートプロセスを改ざんするリスクが相対的に増す Microsoftはフリート内の全デバイスを6月26日までに移行させることを推奨している。 対応方法 Windows Updateで対応できるケース ほとんどのWindows 11ユーザーはWindows Updateを実行するだけで新しいSecure Boot証明書が自動適用される。設定アプリから「Windows Update」を開き、最新の更新プログラムを確認・適用すればよい。 手動対応が必要になるケース 以下の環境では、手動でのBIOSアップデートが別途必要になる場合がある。 Windows 10でESU（Extended Security Updates）に加入していないユーザー 初期のWindows Update配信波に含まれなかった一部のWindows 11ユーザー 古いUEFIファームウェアを搭載したレガシーハードウェア Microsoftはこの問題に関して1時間のAMAセッションを開催しており、エンタープライズや旧型ハードウェアの具体的なシナリオについても詳細情報を提供している。 実務への影響 企業のIT管理者にとって、6月26日というデッドラインは即応を求めるものだ。 フリート管理のポイント IntuneやGroup Policyを使い、Windows Updateの適用状況を一括確認する 未適用デバイスをコンプライアンスポリシーで検出し、優先度をつけて対応する 古いハードウェアはBIOSアップデートの提供有無を各メーカーサイト（ASUS・Dell・HP・Lenovo等）で個別確認する Windows 10ユーザーへの注意 Windows 10は2025年10月にメインストリームサポートが終了しており、ESUに加入していない端末は証明書更新も受け取れない。この機会をWindows 11移行計画加速のきっかけとして捉えるべきだ。 仮想化環境の確認 Hyper-VやAzure VM上でSecure Bootが有効なゲストOSも影響を受ける可能性がある。仮想マシンのテンプレートや展開済みイメージの設定も合わせて見直しておきたい。 筆者の見解 Secure Bootそのものの仕組みは、ブートキットやルートキットに対する有効な防御ラインであり、正しい方向性だと評価している。ただ今回気になるのは、証明書の失効がわかっていた問題であるにもかかわらず、デッドライン1か月前になって改めて警告を発しなければならなかった点だ。 エンタープライズ環境では変更管理のリードタイムが長く、1か月で全デバイスを更新するのが現実的に厳しい組織も少なくない。もう少し早い段階からの積極的な情報発信と、管理ツールへの組み込みがあれば現場の負担を減らせたはずで、そこはもったいなかったと感じる。 Microsoftほどのリソースがあれば、Intuneと連携して「証明書更新が必要なデバイス一覧」をダッシュボードで可視化するといった仕組みを提供できるはずだ。セキュリティの底上げを本気で進めるなら、警告を出すだけでなく「管理者が何もしなくても安全になる」方向への投資を期待したい。 当面の対応として、まず自社フリートのWindows Update適用状況を確認し、6月24日前に更新を完了させることを最優先にしてほしい。 出典: この記事は Microsoft Warns Unpatched Windows 11 PCs Face June 2026 Secure Boot Block の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...