Tech-News

Microsoftが長年にわたってサポート担当者やIT管理者に愛用されてきた診断ツール「Microsoft Support and Recovery Assistant（SaRA）」のコマンドライン版を、2026年3月10日以降の全Windowsアップデートから削除した。理由は「環境のセキュリティ強化とハードニング」。後継として推奨されているのは「Get Help」コマンドラインツール（GetHelpCmd.exe）だ。 SaRAとは何だったのか SaRAは、Office・Microsoft 365・Outlook・Windowsに関するよくある問題を自動診断・修復するフリーツールだ。Windows 7から11まで幅広く対応しており、IT管理者がPowerShellスクリプト経由でリモート実行するユースケースでも広く使われてきた。根本原因を特定して自動修復するか、手順ガイドを提示するか、Microsoftサポートへの連絡を支援するか——この3択で問題解決を導く設計は、ヘルプデスク業務の効率化に大きく貢献してきた。 後継ツール「Get Help」は何が違うのか Microsoftが提示した後継ツール「Get Help」は、機能面ではSaRAとほぼ同等だ。Microsoft 365アプリ（OutlookやTeams）の診断、コマンドライン実行、PowerShellからのリモート実行——いずれも対応している。 最大の違いはインフラのセキュリティ強度。Microsoftによれば、Get Helpを支えるバックエンド基盤はSaRAのものよりセキュリティが強化されているという。具体的な技術詳細は公開されていないが、診断ツール自体がセキュリティ上の弱点になりうるという認識の下、インフラを刷新したと読める。 移行手順はシンプルで、GetHelpCmd.exeをダウンロードして実行するだけ。ただし、既存のスクリプトやRMMツールからSaraCmdLine.exeを呼び出している場合は、GetHelpCmdLine.exeへの差し替えが必要になる。 実務への影響 影響を受ける可能性があるケース SaRAのコマンドライン版をPowerShellスクリプトやRMMツールから呼び出している環境 ヘルプデスク手順書にSaraCmdLine.exeの実行手順が記載されている場合 MDMやGroup Policyで配布・実行を管理している場合 移行時の確認ポイント 既存スクリプトの棚卸し — SaraCmdLine や SaRACmd で社内スクリプトを検索し、使用箇所を洗い出す GetHelpCmd.exeの動作確認 — 差し替え後に同等の診断シナリオが再現できるかテストする 手順書・ドキュメントの更新 — ヘルプデスクやサポート担当向けの運用手順書を更新する エンドユーザー向けGUIのSaRAは別物 — 今回廃止されたのはコマンドライン版。GUIのSaRAアプリについては別途確認が必要 筆者の見解 今回の廃止は、セキュリティ強化という観点からは正しい判断だと思う。診断ツールはシステムの深部にアクセスする性質上、そのインフラ自体が攻撃対象になりうる。「動いているから大丈夫」を理由に古い実装を維持し続けることの方が、長い目で見てリスクだ。 ただ、IT管理者の立場から見ると、また一つ「使い慣れたツールが変わる」対応が増えたのも事実だ。SaRA以外にも、Publisher廃止・Lens廃止・Authenticatorのパスワード自動入力廃止と、最近のMicrosoftは廃止ラッシュが続いている。個々の判断には理由があるにせよ、現場の運用担当者が追いつくのが大変になっている現実も見ておきたい。 移行先のGet Helpが、SaRAと同じくらい現場で信頼されるツールに育つかどうか——それはMicrosoftのインフラ品質と、ドキュメント整備の速度にかかっている。セキュリティを強化したバックエンドで動くなら、診断の精度も上がることを期待したい。「セキュリティのために刷新した」という言葉が、実際の改善として実感できるツールになることを願っている。 今動いているSaRAのスクリプトは早めにGet Helpへ移行を。3月10日以降のWindowsアップデートを適用済みの環境では、すでにSaRAが機能しなくなっている可能性がある。 出典: この記事は Microsoft removes Support and Recovery Assistant from Windows の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AI生成記事が「Windows 12」誤報を拡散 「Windows 12がAIに特化した形で2026年にリリースされる」——そんなニュースが先日、複数のテック系サイトで広まった。結論から言えば、これはAIが生成した誤報記事が発端の完全なファクトエラーだ。Windows CentralやWindows Latestといった信頼性の高いMicrosoft専門メディアが即座に事実確認を行い、「そのような公式発表はない」と明言している。 実際にMicrosoftが公式に発表しているのは「Windows 11 26H2」——つまり現行のWindows 11の機能更新プログラムの延長線上にある次期アップデートだ。Windows 12という新バージョン番号のリリースについて、Microsoftはいかなる公式コミュニケーションも行っていない。 なぜこの誤報が広まったのか 背景にあるのは、生成AIを使ったコンテンツファームの急増だ。AIが「それっぽい」ニュース記事を大量生成し、SEO目的で公開するサイトが世界中で増加している。今回の件では、AIが過去の「Windows 12開発中」という憶測記事や未確認情報を学習・再構成し、まるで確定情報のように仕立てた記事が生まれた可能性が高い。 技術的に興味深いのは、この種の誤報が「完全な嘘」ではなく「もっともらしい嘘」である点だ。Microsoftが将来的にWindows 12を出さないとは誰も断言できない。AI焦点の機能強化を次期バージョンに込めるというシナリオ自体は論理的に成立しうる。だからこそ、確認を省いたメディアが「それはそうかも」と転載してしまう。 Windows 12は本当にないのか 現時点でのMicrosoftの方針は、Windows 11を継続的にアップデートしていく形だ。26H2はその流れの中にある。Windows 10から11への移行で見せた「バージョン番号を変えない大型アップデート」戦略が続いているとみるのが妥当だろう。 ただし、数年単位の先を断言するのは難しい。Microsoftの製品戦略は市場状況や競合環境によって変わりうる。「2026年にWindows 12は来ない」という事実と、「将来的にWindows 12が存在しない」という話は別物だ。今回否定されたのは今年の計画としての誤報であり、長期の製品ロードマップについての議論ではない。 実務への影響——IT管理者が今すべきこと エンタープライズのIT管理者やエンジニアにとって、このニュースから引き出すべき実務的な教訓は二つある。 1. OSアップグレード計画は公式発表のみを根拠にせよ Windows 12が2026年に来るという誤情報を信じて「来年は大型移行が必要だ」と計画を立ててしまうと、リソース配分を誤る。MicrosoftのOfficial Blogsや公式テックコミュニティ、Ignote/Buildでの発表のみを一次情報として扱うこと。Windows CentralやWindows Latestのような専門メディアの「ファクトチェック記事」も信頼できるが、あくまで二次情報として位置づける。 2. テックニュースの出典を必ず確認する習慣を 「〇〇サイトで見た」だけでは不十分な時代になっている。記事の末尾にライター名はあるか、公式プレスリリースへのリンクはあるか、他の専門メディアが同様の報道をしているか——この三点を素早く確認するだけで、今回のような誤報に振り回されるリスクを大幅に減らせる。 筆者の見解 この件で改めて感じるのは、「情報を追うことと、情報に踊らされることは紙一重」という現実だ。生成AIによるコンテンツ量産が本格化した今、テック系メディアの信頼性はますます二極化していく。Windows Centralのような「書いた記者が責任を持つ」媒体の価値は、逆説的に高まっている。 Windowsについて言えば、バージョン番号に一喜一憂する時代はもう終わっていると思っている。Windows 11がどれだけ変わっても、Windowsを細かく追い続けることに以前ほどの意味はない。本当に重要なのは、セキュリティの強化やゼロトラストへの対応、デバイス管理のモダン化といった地に足の着いた話だ。 Microsoftには、派手な新バージョン発表よりも、エンタープライズが安心して使い続けられる堅実なプラットフォームとしての進化を期待したい。AI機能の実装についても、「ブランディングのためのAI」ではなく「現場が使えるAI」を地道に積み上げてほしい。それができる技術力と基盤はMicrosoftには間違いなくある。だからこそ、誤報に振り回されるのではなく、実質的な進化を自信を持って届けてほしいと思う。 出典: この記事は No, an AI-focused “Windows 12” is not coming this year — false report gets the facts completely wrong の内容をもとに、筆者の見解を加えて独自に執筆したものです。

複数ISOが1本のUSBで共存できる「Ventoy」がマイルストーン達成 USBブートメディア作成ツールとして長年定番の座を守ってきた「Rufus」に対し、独自のアプローチで差別化してきた「Ventoy」がメジャーなマイルストーンを達成した。IT現場でUSBを日々扱うエンジニアや管理者にとって、これは無視できないニュースだ。 Ventoyとは何か——Rufusとの根本的な違い Rufusは「ISOを選んでUSBに書き込む」というシンプルな1対1のモデルを採用している。一方Ventoyは、USBドライブ自体をVentoyフォーマットで一度だけ初期化し、あとはISOファイルをドラッグ＆ドロップするだけという設計思想が根本的に異なる。 具体的には、1本のUSBメモリに以下をすべて共存させることができる。 Windows 11のインストールメディア Ubuntu・Debian・Fedoraなど複数のLinuxディストリビューション システム復旧用のWinPEやClonezillaなどのユーティリティISO ブート時にメニューが表示され、使いたいISOを選択するだけで起動できる。新しいISOを追加したいときも、単にファイルをコピーするだけでよく、USBを再フォーマットする必要がない。 セキュアブートへの対応も着実に進化 Ventoyが長年課題としてきたのが、UEFI環境におけるセキュアブート（Secure Boot）との互換性だ。Microsoftがセキュアブートを強化し続ける中、サードパーティのブートローダーは署名問題に悩まされてきた。 今回のマイルストーン達成は、こうした技術的な課題への取り組みが積み重なった成果でもある。Windows 11のインストール要件としてTPMやセキュアブートが必須化された現在、ツール側もその変化に追従しなければならない。 実務への影響——IT管理者・エンジニアが明日から使えるヒント USBキット一本化で現場効率が劇的に向上 IT管理者であれば、こんな場面に心当たりがないだろうか。「OSのインストール用USB」「復旧ツール用USB」「特定ディストリビューション用USB」と何本も持ち歩いている状況だ。Ventoyを使えば、1本のUSBメモリで全部をカバーできる。 運用上の注意点 容量の大きなUSBメモリを選ぶ: Windows 11 ISOは5〜6GB、Linuxも複数入れると10GB超えは普通。32GB以上を推奨 セキュアブートの設定を事前に確認: 機種によってはBIOS設定でセキュアブートの一時無効化、またはVentoyの登録が必要なケースがある ISOの整合性検証を習慣に: Ventoyはあくまでブートローダー。ISO自体が正常かどうかはチェックサムで別途確認する 企業環境では導入前にポリシー確認: セキュリティポリシーによっては外部ブートメディア自体が制限対象になっている場合がある Rufusと使い分ける判断軸 Rufusが依然として優れているのは、「単一ISOを素早く焼きたい」「Windows To GoやFAT32での特殊フォーマットが必要」といったシナリオだ。一方、複数のOSやツールを1本にまとめたいなら、Ventoyに軍配が上がる。両者を目的別に使い分けるのが現実的な選択だ。 筆者の見解 Windowsを細かく追いかけること自体の意味が薄れてきている中で、Ventoyのようなツールの価値は逆に上がっていると感じる。OSのインストールや環境構築は「仕組みで回す」ものになってきているからこそ、その仕組みを支えるツールの品質は重要だ。 Ventoyの設計思想——「一度セットアップすればあとはファイルを置くだけ」——は、筆者が大切にしている道のど真ん中を歩く再現性重視のアプローチと相性がいい。奇をてらった構成ではなく、シンプルで理解しやすい仕組みが、長く使えるインフラを作る。 セキュリティ面では、セキュアブート対応の成熟度を継続的にチェックしておく必要がある。「今動いているから大丈夫」は通用しない世界だ。特に企業IT環境では、ブートメディアの管理ポリシーとセットで運用ルールを整備しておくことを強くすすめる。 Ventoyがここまで成長してきたのは、オープンソースコミュニティの継続的なコントリビューションの賜物でもある。こういったツールを「知っているだけ」で終わらせず、実際に使って体験を積むことが、IT現場の引き出しを増やす一番の近道だ。 出典: この記事は Rufus alternative Ventoy, a Windows 11, Linux USB install app, reaches major milestone の内容をもとに、筆者の見解を加えて独自に執筆したものです。

音声AIの実用化フェーズが、いよいよ本格的に始まりつつある。Microsoft Foundryに、gpt-realtime-1.5 と gpt-audio-1.5 という2つの新しい音声特化モデルが追加された。低遅延・多言語対応・命令追従性の向上という3点セットで、これまで「技術デモ」の域を出なかったリアルタイム音声AIアプリケーションの実用展開を、一段と現実的な選択肢に押し上げている。 何が変わったのか：2モデルの役割分担 今回追加された2モデルはそれぞれ異なる用途に最適化されている。 gpt-realtime-1.5 は、名前の通りリアルタイム性を最優先した設計だ。音声入力から応答までの遅延を極限まで削ることを目指しており、コールセンターの自動応答、会議中のリアルタイム通訳補助、インタラクティブな音声アシスタントなど、「会話のテンポ」が体験品質を左右するシナリオ向けに作られている。 gpt-audio-1.5 は、音声の豊かな表現力と多言語対応にフォーカスしたモデルだ。命令追従性（instruction following）が向上しており、システムプロンプトで指示したキャラクター・トーン・話し方のスタイルをより忠実に再現できる。日本語をはじめとする多言語の自然さも改善されており、ナレーション生成、音声コンテンツ制作、教育系アプリへの応用が見込まれる。 両モデルに共通する強化点として、ツール呼び出し（Function Calling）との統合精度向上が挙げられる。音声で「明日の東京の天気を調べて」と言えば、外部APIを呼び出して回答するような音声エージェントの構築が、これまでより安定して動作するようになった。 なぜMicrosoft Foundryが重要か これらのモデルが「Azure OpenAI」ではなく「Microsoft Foundry」というプラットフォームで提供されている点は見逃せない。Microsoft Foundryは、複数のAIモデルを統一的なインターフェースで扱い、エージェントとして組み合わせるための基盤だ。単にAPIを叩くだけでなく、プロンプト管理・評価・デプロイまでを一元管理できる。 Entra ID経由のアクセス制御、Azure Private Endpointによるネットワーク分離、コンプライアンス要件への対応――こうした「エンタープライズが安心して使うための環境」がすでに整っているのがAzure基盤の強みだ。音声AIという新しいモダリティを、ゼロから新しいセキュリティアーキテクチャを設計することなく既存の統制の傘の下で試せる。これは日本の大規模エンタープライズにとって、実は相当大きなアドバンテージである。 実務への影響：日本のエンジニア・IT管理者はどう動くか すぐに試せること： Microsoft Foundry のプレイグラウンドで gpt-realtime-1.5 の遅延感を体感する。音声AIのUX評価は「触って感じる」が最速の判断軸だ。 既存のTeamsや社内ポータルへの音声アシスタント統合を検討しているチームは、Function Callingとの連携デモをPoC対象に加えると良い。既存のAPI資産をそのまま流用できる可能性が高い。 多言語コールセンター（日英・日中など）の自動化を検討中の組織は、gpt-audio-1.5 の多言語性能を評価リストに入れるタイミングだ。 設計上の注意点： リアルタイム音声はテキストと比べてレイテンシ要件が厳しく、ネットワーク品質が体験に直結する。Azure Regionsの選択（Japan East推奨）と、WebSocket接続の安定性確保は設計段階から織り込んでおく必要がある。また、音声データはプライバシーリスクが高いため、データ保持ポリシー（Zero Data Retention対応の確認）は必ず事前に確認すること。 筆者の見解 リアルタイム音声AIが「動くデモ」から「使えるプロダクト」に移行するためのハードルは、モデル性能だけではなかった。遅延、多言語品質、外部システムとの連携精度、そしてエンタープライズ水準のガバナンス――これらが同時に揃わないと、現場への導入判断が出ない。今回の2モデルは、その「同時に揃える」部分をかなり真剣に詰めてきた印象がある。 Microsoft Foundryというプラットフォームの方向性は、個人的に正しいと思っている。「どのAIモデルを使うか」という選択を抽象化し、エンタープライズが安全に動かせるインフラを提供する――この戦略は長期的に見て堅い。AIモデルそのものの最先端争いとは別の軸で、Microsoftが強みを発揮できる土俵だ。 一方で、音声AIの体験品質はまだ「すごいね」で終わりやすい段階にある。日本語の自然さ、感情表現の細かさ、長い文脈での一貫性――使い込むと気になる部分は依然として出てくる。それでも、コールセンター自動化や社内ヘルプデスクの音声対応など、「90点の品質でも十分価値がある」ユースケースは確実に存在する。そこを狙って実績を積み上げることが、今のエンジニアにとっての現実的な正解だろう。 情報を追い続けることよりも、自分の手で動かして成果を出す経験を積む――そのための素材として、今回のアップデートは十分に価値がある。まずは触ってみることをすすめたい。 出典: この記事は New Azure OpenAI models bring fast, expressive, and real-time AI experiences in Microsoft Foundry の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年4月、AIセキュリティカンファレンス「[un]prompted」でセキュリティ研究者の常識を揺るがす発表があった。AIエージェントを用いたスクリプトが、Linuxカーネルのソースコードを自律的にスキャンし、リモートから悪用可能な複数のヒープバッファオーバーフロー脆弱性を発見。そのうちの1つは23年間にわたって誰にも見つけられていなかったというのだ。 発表者のNicholas Carlini（Anthropic所属の研究科学者）は「このような脆弱性を自分の研究者人生で一度も発見したことはなかった。非常に難しいバグだ。それがAIを使ったところ、いくつも見つかってしまった」と語っている。 驚くほどシンプルな発見手法 最も衝撃的だったのは、使われたアプローチの単純さだ。Carliniが用いたのは以下のような短いシェルスクリプトに近い仕組みだった。 出典: この記事は Claude Code Found a Linux Vulnerability Hidden for 23 Years の内容をもとに、筆者の見解を加えて独自に執筆したものです。

4月14日（日本時間）に配信予定のWindows 11セキュリティアップデートには、派手さはないが毎日の操作感を着実に底上げする8つの機能改善が含まれている。大型機能アップデートではなく通常のセキュリティパッチと同時展開という形で、日常ユースに刺さる変更が届く。 注目の8機能を整理する タスクバーを上・横へ移動可能に 長年ユーザーから要望が出続けてきたタスクバーの位置変更が、ついにGUIから設定できるようになる。上部・左右への移動に対応し、Macライクなレイアウトや、縦長ディスプレイ利用者が恩恵を受けやすい横配置も選択できる。レジストリを直接編集していたユーザーには「やっと」という変更だろう。 1000Hz超リフレッシュレートのモニターサポート 高リフレッシュレートモニターは競技ゲーマーだけの話ではなくなりつつある。1000Hz以上の製品がコンシューマー市場に出始めたことを受け、OSレベルで正式サポートが入る。クリエイターやCADユーザーにもスムーズな描画体験として波及してくる分野だ。 Smart App Control——OS再インストール不要でリセット可能に これは実用上かなり重要な変更だ。Smart App Controlは未署名アプリや未知のアプリを事前にブロックするWindowsのセキュリティ機構だが、一度オフにすると「OS再インストールしないと有効化できない」という制約があった。今回の更新でこの制約が撤廃され、ポリシー設定から再有効化できるようになる。 Narrator × Copilot統合で画像の説明文を生成 スクリーンリーダー「Narrator」にCopilotを使った画像説明生成機能が統合される。視覚障害を持つユーザーへのアクセシビリティ向上という観点での意義は大きく、技術的なアプローチとしても興味深い。 そのほかの実用的な改善 ファイルエクスプローラーのパフォーマンス改善 設定アプリのナビゲーション改善 ウィジェットボードのカスタマイズ拡張 バッテリーセーバーの詳細設定追加 実務への影響——IT管理者・エンジニアへの実際的なヒント Smart App Controlの変更は企業環境で特に検討価値がある。 セキュリティポリシーを強化したい環境で「以前に無効化してしまったSACを戻したい」という場合、これまでは再インストールが唯一の手段だった。管理コストの観点でもこの変更はポジティブに評価できる。イントラネット展開環境では展開ポリシーと合わせて動作確認を優先的に行いたい。 タスクバー移動については、業務用PCの標準設定に影響する可能性がある。 エンドユーザーが自由に変更できるようになるため、ヘルプデスクへの「タスクバーが消えた」問い合わせが増えることも想定しておくと良い。グループポリシーで制限する選択肢も確認しておくことを推奨する。 4月14日配信予定とはいえ、いつものように数日様子を見る戦略も有効だ。 特にSmart App Controlの変更は既存のポリシー設定と干渉する可能性がゼロではない。先行ユーザーのフィードバックを確認してから展開判断するのは、今の時代において立派なリスク管理だ。 筆者の見解 率直に言って、このアップデートは「Windowsらしい地道な改善」の典型だ。タスクバーの位置変更がようやくGUIで完結するようになったことは、何年も待ち続けたユーザーにとって小さくない話だし、Smart App Controlの制約解除は明らかに正しい方向の変更だ。 特にSmart App Controlの改善は評価したい。セキュリティ機能を「設定ミスしたら再インストールしかない」という状況に置いておくのは、運用面での無用なハードルを作っていた。制限を設けることと、その制限が現場で機能しやすい設計にすることは両立するはずで、今回の変更はその方向に一歩踏み込んでいる。 NarratorへのCopilot統合については、アクセシビリティという文脈での活用は本来の使い方のひとつだと思う。AIを「使えるところに使う」というアプローチが適切に機能している例として素直に評価したい。 Windowsの細かい機能を追いかけることの優先度は以前より確実に下がっているが、それでも「基盤として安全で、使いやすいOS」であり続けることの意味は変わらない。今回のような実用的な積み重ねを、これからも地道に続けてほしいと思っている。 出典: この記事は 8 new Windows 11 features arriving in April that make everyday use a little easier の内容をもとに、筆者の見解を加えて独自に執筆したものです。

人気HTTPライブラリ「Axios」で発生したサプライチェーン攻撃のポストモーテムが公式に公開された。今回特に注目すべきは、単なる無差別攻撃ではなく、特定のメンテナを徹底的に調査した上で仕掛けられた「個別ターゲティング型」のソーシャルエンジニアリングだった点だ。OSSエコシステムに関わるすべての開発者が知っておくべき手口が、克明に記録されている。 攻撃の全手順：精巧すぎる罠 メンテナのJason Saayman氏への攻撃は、以下のステップで実行された。 1. 企業・人物の完全クローン 攻撃者はある実在企業を模倣し、その創設者の外見までなりすまし、Saayman氏に接触してきた。単なるメール詐欺ではなく、企業ブランドと人物像を丸ごと模倣した精巧な偽装だ。 2. 説得力のある偽Slackワークスペース 本物の企業名・CIブランドを冠したSlackワークスペースに招待。LinkedInの投稿シェア、他のOSSメンテナの（おそらく偽の）プロフィールまで用意され、非常に自然な「業界コミュニティ」の雰囲気が演出されていた。 3. Microsoft TeamsでのミーティングとRAT投下 複数の「参加者」が揃ったTeamsミーティングを設定。ミーティング中に「お使いのシステムが古い」と表示され、Teamsの動作に必要なものだと思い込んでインストールしたのがRAT（Remote Access Trojan）だった。この罠で認証情報が窃取され、攻撃者はAxiosのリポジトリに悪意ある依存パッケージを公開することに成功した。 この手口はGoogleのThreat IntelligenceチームがUNC1069として文書化している攻撃グループのパターンと一致しており、暗号資産・AI関連企業を標的にした活動として知られる。 なぜこれが重要か 「ソーシャルエンジニアリングに注意」は耳タコな話だ。しかし今回の攻撃は次元が違う。本物そっくりのSlackワークスペース、実在企業の精巧なクローン、複数人が関与するTeamsミーティング——ここまでの工数と精度で特定個人を攻撃するケースは、以前は国家レベルのAPT攻撃でしか見られなかった。それが今やnpmパッケージのメンテナを標的に実行されている。 日本企業でも多数のプロダクトがAxiosに依存しており、悪意あるバージョンがインストールされた環境があればリスクは無視できない。サプライチェーンセキュリティはもはや「大企業だけの話」ではない。 実務での活用ポイント OSSメンテナ・開発者向け ミーティング直前の「ソフトウェアインストール要求」は即座に疑え。時間的プレッシャーは攻撃者が意図的に作り出すものだ 初回コンタクトで別のチャンネルへ誘導してくる相手は要注意 LinkedInや企業サイトが本物そっくりでも、それだけでは信頼の根拠にならない npmやGitHubのリリース権限は多要素認証＋物理セキュリティキーで保護する IT管理者・セキュリティ担当者向け 依存ライブラリの整合性チェック（npm audit、SBOMの活用）を自動化する 新バージョンリリース直後の依存アップデートに対し、短時間の検証フェーズを設ける 開発者向けセキュリティトレーニングにサプライチェーン攻撃の具体的シナリオを組み込む 筆者の見解 今回の攻撃でTeamsが最後の一手として使われた点は気になる。攻撃者はTeamsの普及度と「ミーティング直前に何かインストールしなければ」という心理的プレッシャーを巧みに利用している。Teamsそのものの問題ではないが、正規のインストール要求と偽物を区別しにくい現状は課題だ。Microsoftには、こうした手口を踏まえたセキュリティアドバイザリの強化や、インストール要求をより明確に識別できるUX改善を期待したい。ブランドとエコシステムを持つMicrosoftだからこそ、こういう部分で業界をリードしてほしい。 より根本的な問題として、OSSエコシステムはごく少数のメンテナが巨大なサプライチェーンの鍵を握る構造的脆弱性を抱えている。Axiosは週次ダウンロード数が数千万件規模のライブラリだ。一人のメンテナへのソーシャルエンジニアリングが世界中のシステムに影響し得る。 「禁止」や「ゼロトラスト」だけでは解決しない。メンテナが安全に作業できる環境、二人以上のレビューが必要なリリースフロー、そして実例を具体的に共有するコミュニティの文化こそが必要だ。今回Axiosチームが詳細なポストモーテムを公開したことは、その意味で業界全体への貴重な貢献だと思う。 出典: この記事は The Axios supply chain attack used individually targeted social engineering の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年4月、生成AIの競争は新たなフェーズに入った。わずか3ヶ月でフロンティアが何度も塗り替えられ、今月だけでも業界の勢力図を変えかねない出来事が連続して発生している。OpenAIが年換算売上高（ARR）250億ドルを突破しIPO検討に入ったというビジネス面での激変と並行して、モデル性能の競争も前例のない激しさを見せている。 業界を揺るがした「Claude Mythosリーク」 今月最大のニュースは、3月26日に発生したAnthropicの内部文書流出だ。設定ミスのあったデータストアから約3,000件の内部ファイルが一時的に公開状態になり、その中に「Claude Mythos（内部コードネーム：Capybara）」の詳細な製品ドキュメントが含まれていた。 Anthropicは存在を否定せず、「推論・コーディング・サイバーセキュリティにおいて意味のある進歩を遂げた汎用モデルを開発中。能力の強さを鑑み、リリース方法を慎重に検討している。これは当社史上最高性能のモデルで、ステップチェンジと位置づけている」と公式に認めた。 リークされた文書によれば、ClaybearはClaude Opus 4.6を「劇的に」上回るプログラミング性能を持つとされ、現在はサイバーセキュリティパートナー限定の早期アクセス段階にある。公開日は未定だが、市場は4月中の発表可能性を約25%と見積もっている。 現時点のモデル勢力図 総合性能：Gemini 3.1 Pro が首位 16の主要ベンチマーク中13で首位を獲得しているGemini 3.1 Proは、Artificial Analysis Intelligence IndexでGPT-5.4 Proと同率ながら、APIコストは約3分の1という破壊的なコストパフォーマンスを誇る。エンタープライズ採用において価格は重要な変数であり、この差は見逃せない。 コーディング：Claude Sonnet 4.6 が実務首位 実際の専門家レベル作業を評価するGDPval-AA Eloベンチマークでは、Claude Sonnet 4.6がトップに立つ。GitHub CopilotのCodingエージェントがこのモデルで動作していることからも、コード生成の実用性では一歩抜け出した存在だ。 オープンソース：Meta Llama 4 Mavericが台頭 4,000億パラメータ・1,000万トークンのコンテキストウィンドウを持つLlama 4 Mavericは、独自インフラで無償運用できるオープンウェイトモデルとして最強クラスに達した。クローズドモデルとの性能差が急速に縮まっている。 価格破壊：DeepSeek V3.2 DeepSeek V3.2は入力100万トークンあたり約0.28ドルという価格を実現。欧米フラッグシップモデルの2ドル以上と比較すると約7分の1以下であり、コスト重視のユースケースでは無視できない選択肢だ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 すぐに動けるアクション： GitHub Copilotを使っているなら今すぐ確認：Claude Sonnet 4.6ベースのCodingエージェントが実務コーディングで最高評価を得ている。エージェントモードが有効になっているか設定を確認し、複雑なリファクタリングや単体テスト生成に積極的に活用したい。 Gemini 3.1 Proのコスパを試算する：Google CloudやVertex AI経由でのAPI利用コストを、現在使っているGPT-4系と比較してほしい。同等性能で3分の1のコストになるなら、高スループットな社内ツールのバックエンドを切り替える価値がある。 オンプレミス・プライベート環境を検討しているなら Llama 4：情報漏洩リスクの観点から外部APIに送れないデータを扱う企業にとって、Llama 4 Mavericは現実的な選択肢になった。ローカルLLM運用のPoC着手タイミングとして今が適切だ。 Claude Mythosの動向を追う：サイバーセキュリティ分野で特段の強みを持つとされており、SOC自動化やペネトレーションテスト支援への活用が期待される。早期アクセス申請の窓口が開いた際は優先的に検討したい。 筆者の見解 2026年の生成AI競争を一言で表すなら「コモディティ化の加速」だ。 Gemini 3.1 ProがGPT-5.4と同等の性能を3分の1のコストで提供し、Llama 4がクローズドモデルの背中を追うこの状況は、「どのモデルを使うか」ではなく「いかに素早く使いこなすか」が企業の競争優位を決める時代が来たことを示している。 Claude Mythosのリークが特に興味深いのは、Anthropicが「サイバーセキュリティ」を特筆した点だ。セキュリティ特化のモデルが登場することで、これまで人手に依存していたインシデント対応や脆弱性評価の自動化が一気に現実解になりうる。日本でもCSIRTやSOCの人材不足は深刻であり、このモデルの公開は国内のセキュリティ運用に大きなインパクトを与えると予想する。 OpenAIのIPO観測が示すように、生成AIはもはや研究フェーズを完全に卒業した。モデル選定はベンダーロックインリスク・コスト・コンプライアンス・性能のバランスで評価する「調達判断」になっている。IT管理者にとっては、クラウドサービスの選定と同じ視点でAIモデルを評価するフレームを今すぐ整備すべき時期に来ている。 出典: この記事は OpenAI Surpasses $25B ARR, Explores IPO as Early as Late 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Claude Codeのブラックボックスを「見える化」するツールが登場 Claude Codeを使って複数のAIエージェントを並列実行する際、各エージェントが実際に何をしているかを把握するのは難しい。そうした課題を解決するオープンソースプロジェクト「Agents Observe」がHacker Newsに投稿され、注目を集めている。 Agents Observeとは Agents Observeは、Claude Codeのエージェント活動をリアルタイムでモニタリングするダッシュボードだ。Claude Codeのフック（hooks）機能を活用してすべてのイベントを捕捉し、WebSocketでReact製ダッシュボードにストリーミング配信する。 主な機能は以下のとおり： ツール呼び出しのリアルタイム表示：PreToolUse → PostToolUse の流れで、BashコマンドやファイルI/Oを即時確認 エージェント階層の可視化：どのサブエージェントがどの親エージェントから生成されたかを把握 フィルタリング・検索：エージェント別・ツール種別でのフィルタや全イベント横断検索 セッション履歴の閲覧：「twinkly-hugging-dragon」のような人間が読みやすい名前でセッションを管理 なぜOTELではなくフックを使うのか 開発者は、OpenTelemetry（OTEL）ではなくClaude Codeのフック機能を採用した理由についてこう説明する。「フックはOTELデータよりもはるかに多くの有用な情報を提供し、jsonlファイルと組み合わせることで完全な状況把握が可能になる」。 アーキテクチャはシンプルな4層構成だ： 元記事: Show HN: Real-time dashboard for Claude Code agent teams

Microsoftがクロス署名ドライバープログラムへの信頼を廃止へ Microsoftは2026年4月のWindowsアップデートにおいて、旧来のクロス署名カーネルドライバープログラム（Cross-Signed Driver Program）への信頼を削除すると発表した。この変更により、今後はMicrosoftが認定するWindows Hardware Compatibility Program（WHCP）を通じて署名されたドライバーのみがデフォルトで読み込まれるようになる。 クロス署名ドライバーとは クロス署名ドライバーとは、MicrosoftのルートCA（認証局）ではなく、サードパーティの認証局によって署名されたカーネルモードドライバーを指す。過去にWindowsのドライバーエコシステムが拡大していく過程で広く利用されてきたが、その反面、マルウェアがドライバーに悪意あるコードを仕込んで署名を通過させる「ドライバー署名の悪用」が攻撃手法として確立されてしまった背景がある。 近年、ランサムウェアや高度な脅威アクター（APT）がカーネルレベルのドライバーを悪用するケースが増加しており、Microsoftはドライバーのセキュリティ強化を優先課題として取り組んできた。 段階的な適用で互換性への影響を監視 今回の変更は一度に完全適用されるわけではなく、まず評価モード（Evaluation Mode）として展開される。評価モードでは、クロス署名ドライバーが読み込まれた場合にイベントログへの記録や管理者への通知が行われるが、実際のブロックは行われない。これにより、企業やOEMが既存の環境への影響を把握し、対応を進める猶予期間が設けられる。 Microsoftは互換性への影響を監視しながら段階的に適用を進める方針で、最終的にはクロス署名ドライバーのデフォルト読み込みを完全に無効化する予定だ。 企業・開発者が取るべき対応 ハードウェアベンダーやドライバー開発者は、WHCPを通じた署名取得へ移行することが求められる。WHCPの認定プロセスはMicrosoftのHardware Dev Centerポータルから申請でき、Microsoftによる技術的なテストと審査を経て署名が付与される。 企業のIT管理者は、社内で使用しているサードパーティ製ハードウェアのドライバーがWHCP署名済みかどうかを確認し、未対応のベンダーに対してアップデートを要求する必要がある。特に、古いプリンターや特殊な計測機器、産業用デバイスのドライバーは対応が遅れる可能性があるため、早期の棚卸しが推奨される。 セキュリティ強化の流れの一環 この変更は、MicrosoftがWindows 11以降で推進しているSecured-core PCやVulnerable Driver Blocklist（脆弱ドライバーブロックリスト）の強化と同じ方向性を持つ。カーネルへのアクセスを厳しく制限することで、マルウェアがOSの深部に潜り込むことを根本から防ぐ設計思想だ。 Windowsのセキュリティ基盤を強化する上で重要なマイルストーンとなる今回の変更を前に、ハードウェアベンダーとIT担当者は早めの対応準備を進めておくべきだろう。 元記事: Advancing Windows driver security: Removing trust for the cross-signed driver program

Claude Codeで利用制限の枯渇が急増——Anthropicが調査中と公表 AnthropicのAIコーディングアシスタント「Claude Code」において、トークン消費が異常に速く使用量上限（クォータ）に到達してしまうという問題が多発しており、開発者から大きな不満の声が上がっている。 Anthropicはこの問題を公式に認め、「Claude Codeの利用制限に想定より遥かに速く到達するケースが報告されている。現在チームのトッププライオリティとして調査中だ」と声明を発表した。 「30日中12日しか使えない」——ユーザーから怒りの声 Discordの公式フォーラムでは、年間200ドル（約3万円）のClaude Proプランを契約するあるユーザーが「毎週月曜日には上限に達し、土曜日にリセットされるの繰り返し。1ヶ月30日のうち12日しかまともに使えていない」と訴えている。 RedditのAnthropicフォーラムにも批判が集中しており、「Max 5プラン（月額100ドル）を1時間で使い果たした。以前は8時間使えていたのに」といった報告が相次ぐ。 問題の原因として浮上する3つの要因 今回の問題には複数の要因が重なっている可能性がある。 1. ピーク時間帯のクォータ削減 先週、Anthropicはピークタイムにおけるクォータを削減すると発表した。エンジニアのThariq Shihipar氏によれば、約7%のユーザーに影響するという。 2. 倍増プロモーションの終了 3月28日をもって、ピーク外の6時間帯に利用制限を2倍にするプロモーションが終了。これにより体感上の使用量が大幅に低下したとみられる。 3. プロンプトキャッシュのバグ Claude Codeのバイナリをリバースエンジニアリングしたユーザーが「プロンプトキャッシュを無効化する独立した2つのバグを発見した。これによりコストが10〜20倍に膨れ上がっている」と主張している。旧バージョン（2.1.34）へのダウングレードで改善したという報告も複数寄せられており、バグの存在を裏付けている。 プロンプトキャッシュの仕様も落とし穴に Claude Codeのプロンプトキャッシュは、繰り返し処理や共通要素を含むプロンプトの処理コストを大幅に削減できる機能だ。しかしキャッシュの有効期限はデフォルトでわずか5分。少し作業を中断しただけでキャッシュが無効になり、再開時にコストが跳ね上がる。 1時間のキャッシュ延長オプションも存在するが、その場合「キャッシュ書き込みトークンは通常の入力トークンの2倍」の料金がかかる。読み込みは0.1倍と安いため、使い方によってコスト最適化の余地が大きく異なる。 自動ワークフローへの深刻な影響 特に問題視されているのは、自動化パイプラインへの影響だ。あるユーザーはこう警告する。「Claude Codeを自動ワークフローで使っているなら、レート制限エラーを明示的にキャッチする必要がある。一般的なエラーに見えるため、気づかずにリトライし続け、ループ1セッションで日次予算を数分で使い果たすことになる」。 なお、AnthropicはProプランの利用量について「無料プランの5倍以上」、Standard Teamプランは「Proの1.25倍」という曖昧な表記にとどめており、開発者が実際の上限を把握しにくい状況も批判を招いている。 業界全体の課題：AIツールの価格モデルへの不満 こうした問題はAnthropicだけではない。今月初めにはGoogle Antigravityのユーザーからも同様の不満が報告されている。AI開発ツールの「使い倒したいユーザー」と「収益を確保したいプロバイダー」の間の暗黙の交渉が続いている状況だ。 AIを全プロセスに組み込むよう促すベンダーのマーケティングと、実際には突然応答が止まることもあるクォータ制限との間の矛盾——この課題は、AIコーディングツールが本格的に業務インフラ化するうえで、避けては通れない問題となりつつある。 元記事: Claude Code users hitting usage limits ‘way faster than expected’

Trivy連鎖攻撃がCiscoを直撃——AIプロダクトのソースコードが流出 米Ciscoがサイバー攻撃の被害を受け、内部の開発環境が侵害されたことをBleepingComputerが報じた。攻撃者は2026年3月に発覚したTrivyサプライチェーン攻撃で盗んだ認証情報を転用し、Ciscoのビルド・開発環境への侵入を果たした。 何が起きたのか Ciscoの「Unified Intelligence Center」「CSIRT」「EOC」各チームが侵害を封じ込めたものの、攻撃者はその前に以下を実行したとされる。 300以上のGitHubリポジトリを複製（AI Assistant、AI Defense、未発表プロダクトのソースコードを含む） 複数のAWSキーを窃取し、一部のCisco AWSアカウントで不正操作を実施 数十台のデバイス（開発者ワークステーション・ラボ端末）のデータを取得 さらに、複製されたリポジトリの一部には銀行、BPO（業務プロセスアウトソーシング）、米政府機関など顧客のソースコードが含まれている可能性があるという。 Trivyサプライチェーン攻撃とは Trivyはコンテナイメージや構成ファイルの脆弱性を検出するOSSスキャナーで、開発現場での採用が広い。今月初め、脅威アクターがTrivyのGitHubパイプラインを侵害し、公式リリースおよびGitHub Actionsを通じて認証情報窃取型マルウェアを配布した。 Ciscoはこの不正なGitHub Actionプラグインを踏んでしまい、CI/CD環境の認証情報が流出したとみられる。 背後に「TeamPCP」グループ セキュリティ研究者は今回の一連の攻撃を、TeamPCPと呼ばれる脅威グループに帰属している。同グループは独自のインフォスティーラー「TeamPCP Cloud Stealer」を用いており、GitHub・PyPI・npm・Dockerを標的にしたサプライチェーン攻撃を繰り返している。 Cisco侵害と並行して、LiteLLM（PyPIパッケージ）およびCheckmarx KICSプロジェクトも同じマルウェアで侵害されており、合計で数万台規模のデバイスに影響が及んでいる。 Ciscoの対応 Ciscoは影響を受けたシステムを隔離し、再イメージングを開始。大規模な認証情報のローテーションを実施中だという。ただし、BleepingComputerの取材に対してCiscoからの公式回答はまだ得られていない。 日本のエンジニアへの示唆 Trivyは国内でも広くCI/CDパイプラインに組み込まれているツールだ。今回の攻撃はOSSツールのGitHub Actionsやパイプラインが攻撃経路になり得ることを改めて示した。 利用中のGitHub Actionsのバージョンとハッシュを固定しているか確認する CI/CD環境で使う認証情報（AWS、GitHub Token等）のスコープを最小権限に絞る 依存パッケージの更新時にはリリースノートと変更差分を必ずチェックする サプライチェーン攻撃は「信頼しているツール」を踏み台にする点で被害が広域に及ぶ。OSS利用時のセキュリティ検証プロセスを今一度見直すべき時期だ。 元記事: Cisco source code stolen in Trivy-linked dev environment breach

Microsoft、Windows全バージョンから伝統のコマンドラインツールを正式削除 Microsoftは、Windows 11の25H2・24H2・23H2、そしてWindows 10のすべてのサポート対象バージョンとWindowsサーバー製品から、長年にわたり使われてきたコマンドラインツールを正式に削除すると発表した。 廃止の背景 今回の削除は突然の決定ではない。Microsoftは2021年のWindows 10 バージョン21H1の時点で、当該ツールを「非推奨（deprecated）」として公式にアナウンスしていた。それから数年の移行期間を経て、今回ついに全バージョンからの正式削除という最終段階に踏み切った形だ。 非推奨から正式削除までのこうした段階的アプローチは、Microsoftが近年採用する標準的な廃止プロセスであり、企業や開発者に十分な移行時間を確保する目的がある。 影響範囲と代替手段 影響を受けるのはWindows 11の現行サポートバージョン（23H2・24H2・25H2）に加え、Windows 10、さらにWindowsサーバー製品群と広範にわたる。 Microsoftは代替手段として、PowerShellおよびWindows Management Instrumentation（WMI）をPowerShell経由で利用することを推奨している。PowerShellはWMIクラスへのアクセスを Get-WmiObject や Get-CimInstance コマンドレットで提供しており、従来のコマンドラインと同等以上の機能を持つ。 企業IT管理者への影響 日本国内でも多くの企業システムやIT管理スクリプトに組み込まれているケースがあるため、IT部門は以下を早急に確認することが望ましい。 社内スクリプト・バッチファイルでの使用有無の棚卸し 監視・管理ツールによる依存関係の確認 PowerShellベースのスクリプトへの移行計画の策定 Windows合理化の一環 Microsoftは近年、レガシーコンポーネントの整理を積極的に進めている。WordPadの削除（2023年）、Internet Explorerの廃止（2022年）に続き、今回の決定も「Windowsの合理化とセキュリティ強化」という長期方針の一環と見られる。 古いツールへの依存を断ち切り、よりモダンな管理インターフェースへの移行を促すことで、Windowsのセキュリティポスチャー（セキュリティ態勢）の向上を図る狙いがある。 移行を検討している管理者は、Microsoft公式のPowerShell移行ガイドや、Windows管理センター（Windows Admin Center）の活用も選択肢に入れると良いだろう。 元記事: Microsoft formally removes a command line tool from Windows 11 25H2, 24H2, 23H2, Windows 10

MicrosoftがCopilotを「エンターテインメント目的のみ」と規約に明記 Microsoftの生成AIアシスタント「Microsoft Copilot」の利用規約（Terms of Use）に、サービスが「エンターテインメント目的のみ（for entertainment purposes only）」であるとする文言が含まれていることが注目を集めている。Hacker Newsで366ポイントを獲得し、145件のコメントが寄せられるなど、技術者コミュニティで大きな話題となっている。 利用規約の主なポイント 2025年10月24日付で更新されたCopilotの利用規約は、読みやすさと明確さを重視して全面的に書き直されたと説明されている。今回の改訂では以下の点が明記された。 Copilot Actionsおよびショッピング体験に関する新規条項の追加 行動規範（Code of Conduct）の改訂——できること・できないことの明確化 免責事項の強調——Copilotの回答が不正確・不完全・不適切になり得ることを利用者に明示 規約では「Copilotは良い回答を提供しようとするが、誤りを犯すこともある」と率直に認めており、「説得力があるように見えても、不完全・不正確・不適切な回答が表示される場合がある」と警告している。また、インターネット上の情報を参照して回答を生成するが、その内容をMicrosoftはコントロールできないとも明記している。 「判断は利用者自身で」 規約はさらに、「Copilotから得た情報をもとに意思決定や行動をする前に、必ず自分で判断し情報を確認するように」と求めている。不適切な回答を見た場合は、フィードバック機能を通じて報告することも推奨されている。 日本への影響と背景 日本国内でも、企業や個人がCopilotを業務・学習・情報収集に活用するケースが急増している。こうした中で今回の規約表現は、AIツールを「信頼できる情報源」として扱うことへのリスクを改めて浮き彫りにした形だ。 医療・法律・財務など専門性の高い判断が求められる領域では、AIの出力をそのまま利用することは特に危険を伴う。「エンターテインメント目的」という表現はいわゆる法的免責（ディスクレーマー）の一環とも読めるが、企業としての公式見解がここまで明示された点は見逃せない。 AI時代のリテラシーが問われる ChatGPTやGeminiなど他の主要AIサービスも同様の免責事項を設けているが、「エンターテインメント目的」という表現の強さは異例とも言える。生成AIの爆発的な普及が続く中、利用者一人ひとりが情報の正確性を自ら検証する「AIリテラシー」の重要性が、あらためて問われている。 元記事: Microsoft: Copilot is for entertainment purposes only

エクスプローラーの低速問題、ついに本格対処へ Microsoftは、Windows品質向上への取り組みの一環として、エクスプローラー（File Explorer）の大幅なパフォーマンス改善を2026年中に実施すると発表した。 「最初の改善ラウンドでは、起動速度の向上、画面のちらつき低減、よりスムーズなナビゲーション、そして日常的なファイル操作の信頼性向上に注力する」とMicrosoftは述べており、最初の改善はWindowsインサイダー向けに2026年4月に提供予定。その後、より根本的な変更が年間を通じて展開される見通しだ。 なぜWindows 11のエクスプローラーは遅いのか エクスプローラーはWindowsで最も使用頻度の高いコンポーネントの一つだが、Windows 11への移行後も長年にわたってWindows 10より遅い状態が続いてきた。 Microsoftはこれまでも改善を試みてきた。最近の取り組みの一つがバックグラウンドプリロードだ。エクスプローラーをクリック前にメモリに事前ロードしておくことで、見かけ上の起動速度を改善する仕組みで、追加RAMは約35MB程度と軽微だ。 しかしプリロードで解決できるのは「起動速度」のみ。起動後の動作——フォルダ間のナビゲーション、右クリックメニューの表示速度、全体的な応答性——は依然として改善されていない。 右クリックメニューの肥大化が最大の問題 最も体感しやすい問題が右クリックのコンテキストメニューだ。Windows 11では「Copilotに確認」「Clipchampで編集」「Paintで編集」「Photosで編集」などのアクションが一度に表示されようとするため、メニューが一項目ずつ描画される様子が目視できるほど遅い。 比較として、余分な統合機能を省いたWindows 11 LTSCではコンテキストメニューが短く、はるかに高速に表示される。これは肥大化したアドオンこそが遅延の主因であることを示唆している。 インサイダービルドでは「ファイルの管理」グループによるメニュー再編成が試みられており、使用頻度の低いアクションをサブメニューに移すことで縦のスペースを約半分に圧縮している。見た目はすっきりしたものの、アクション自体のロード時間は残存しており、「見た目が改善しても速度は同じ」という評価も出ている。 ハイブリッドUIアーキテクチャという根本的課題 エクスプローラーの本質的な問題として、旧来のWin32基盤の上にモダンUIフレームワークを重ねた「ハイブリッドアーキテクチャ」がある。この二重構造が複雑性とオーバーヘッドを生み出しており、表面的なチューニングだけでは解消しにくい。 Microsoftが「より根本的な変更」と表現している2026年後半の改善では、このアーキテクチャ面への手入れが期待される。長年放置されてきた問題にようやく本腰が入った形だが、実際にWindows 10の快適さに追いつけるかどうか、ユーザーの目は厳しい。 日本でも企業・個人問わず広く使われているWindowsだけに、エクスプローラーの改善は多くのユーザーの作業効率に直結する。2026年4月のインサイダービルドに注目したい。 元記事: Windows 11 File Explorer is finally getting faster in 2026, but it’s been slower than Windows 10 for years

Pythonプロジェクトの依存関係を脆弱性データベースで即チェック Simon Willison氏が、Pythonプロジェクトの依存パッケージに含まれる既知の脆弱性を一括検索できるWebツール「Python Vulnerability Lookup」を公開した。 使い方はシンプル——設定不要で即利用可能 使い方は非常にシンプルだ。プロジェクトの pyproject.toml または requirements.txt の内容をテキストエリアに貼り付けるか、依存関係ファイルを含むGitHubリポジトリ名を入力するだけでよい。ツールはGoogleが運営するオープンソース脆弱性データベース OSV.dev のJSON APIに問い合わせを行い、各パッケージの既知脆弱性を一覧表示する。 表示される情報には以下が含まれる: 深刻度レベル（CVSSスコアベース） 影響を受けるバージョン範囲 詳細な開示レポートへのリンク OSV.devのオープンCORS APIを活用 今回のツール開発のきっかけは、OSV.devがCORSを許可したオープンなJSON APIを提供していることをWillison氏が発見したことだ。CORSが許可されているため、バックエンドサーバーを介さずブラウザから直接APIを叩けるシングルページのHTMLツールとして実装できた。 OSV.dev（Open Source Vulnerabilities）はGoogleが主導するプロジェクトで、Python（PyPI）をはじめ、npm、Go、Rust、Javaなど多数のエコシステムの脆弱性情報を一元管理している。NVDやGitHub Advisory Databaseとも連携しており、日本の開発現場でも活用が広がっている。 ツール自体もAIで開発——「バイブコーディング」の実践例として Willison氏はこのツール自体を Claude Code を使って構築したことも明かしている。AIアシスタントと対話しながらコードを書く「バイブコーディング（Vibe Coding）」のひとつの実践例として紹介されており、軽量なHTMLツールをAIで素早く実装するアプローチの有効性を示している。 サプライチェーン攻撃対策として活用を Pythonプロジェクトの依存関係を狙ったサプライチェーン攻撃は近年増加傾向にある。pip audit や GitHub Dependabotといった既存ツールと並んで、本ツールをCI/CDの事前チェックや定期的なセキュリティレビューに組み込むことで、脆弱なパッケージの早期発見に役立てられるだろう。 ツールはブラウザ上で動作し、インストール不要・無料で利用可能。 元記事: Python Vulnerability Lookup

Windows Kerberosセキュリティ強化、一部環境で認証障害の可能性 Microsoftは、来月リリース予定のWindowsアップデートに含まれるKerberos認証のセキュリティ強化（ハードニング）について、一部の環境で認証障害を引き起こす可能性があるとして、システム管理者に事前対応を呼びかけている。 Kerberosとは Kerberos（ケルベロス）は、Windowsのエンタープライズ環境で広く使われているネットワーク認証プロトコルだ。Active Directory（AD）環境では、ユーザーがPCにログインしたり、社内サーバーやアプリケーションにアクセスしたりする際に、このKerberosが裏側で認証処理を担っている。日本企業の多くはActive Directory環境を採用しており、このKerberos認証への影響は国内のIT担当者にとっても他人事ではない。 今回の変更の背景 Microsoftはここ数年、Kerberos認証のセキュリティ強化を段階的に進めてきた。今回の変更もその一環で、従来は「互換モード」として動作していた設定が、次回更新以降は「強制モード（Enforcement Mode）」へと切り替わる見通しだ。 このような段階的な移行アプローチはMicrosoftがよく採用する手法で、移行期間中に管理者が環境を修正できるよう猶予を設けている。しかし、対応が遅れると更新適用後にユーザーが突然ログインできなくなるなど、業務に直接影響が出るリスクがある。 どのような環境が影響を受けるか 影響が出る可能性があるのは、主に以下のような環境とされている。 古い構成のActive Directory環境：証明書ベースの認証やNPS（ネットワークポリシーサーバー）を利用しているケース サードパーティのKerberos実装を使用している環境：LinuxサーバーやmacOSをADに参加させているハイブリッド環境など 長期間アップデートが適用されていないサーバーやクライアント 逆に、最新状態に保たれている標準的なWindows Active Directory環境では、影響が出ない可能性が高い。 管理者が取るべき対応 Microsoftは管理者に対し、以下の対応を推奨している。 イベントログの確認：強制モード移行前に、Kerberosに関連する警告イベントが記録されていないか確認する 環境の棚卸し：証明書認証やNPSを使用しているシステムを洗い出す テスト環境での検証：本番適用前に更新プログラムをテスト環境で適用し、認証が正常に動作することを確認する 必要に応じてポリシーを更新：古い認証設定を使っているシステムがあれば、事前に修正しておく まとめ Kerberosのセキュリティ強化自体は、認証プロトコルの脆弱性を突いた攻撃（Pass-the-Ticketなど）への対策として重要な施策だ。しかし準備不足のまま強制モードに移行すると、ユーザーが業務システムにログインできなくなるといった深刻な障害につながりかねない。 特に多くのユーザーを抱える企業のIT部門では、来月の更新前に余裕を持って動作確認と対応を済ませておくことを強くおすすめしたい。 元記事: Windows Kerberos hardening may cause authentication issues for some PCs next month

Azure Databricks Lakebase、正式リリース（GA）——14リージョンで提供開始 Databricksは2026年3月、Azure Databricks Lakebase の一般提供（GA）を発表した。Microsoftとの共同発表となった今回のリリースは、アプリケーション開発とデータ分析の間に長年存在してきた「データの壁」を取り払う試みとして注目を集めている。 従来の問題：ETLという「データ税」 これまで、PostgreSQLなどのオペレーショナルデータベースとデータレイク・分析基盤の間にはギャップが存在していた。開発チームはそのギャップを埋めるために複雑なETL（Extract/Transform/Load）パイプラインを構築・維持し続ける必要があった。このアーキテクチャは単に開発スピードを落とすだけでなく、ストレージの重複コストや、リアルタイムデータと分析データの間にタイムラグを生む「データ税」として機能してきた。 Lakebase の核心：コンピュートとストレージの分離 Lakebase はこの課題をアーキテクチャレベルで解決する。コンピュート（処理）とストレージ（データ保管）を分離した設計により、オペレーショナルデータをレイクハウスのストレージに直接書き込める。つまり、トランザクション系と分析系で別々にデータを持つ必要がなくなり、ETLパイプラインそのものが不要になる。 主な機能 サーバーレス＆オートスケーリング トラフィックに応じて自動スケールし、アイドル時はゼロにスケールダウン。使った分だけ課金されるモデルで、TCO（総所有コスト）の最小化を実現する。 インスタントブランチング＆ゼロコピークローン 本番データのブランチを数秒で作成できる。スキーママイグレーションのテストやクエリのデバッグを、本番環境への影響ゼロで実施可能。AIエージェントを活用した高速な開発サイクルとの相性も良い。 ポイントインタイムリカバリ（PITR） 障害やミスが発生した際、任意の時点にデータベースを即座に復元できる。 標準Postgres互換 既存のPostgresツールやライブラリとの完全互換を維持。AIベクトル検索向けの pgvector や地理空間分析向けの PostGIS など、主要な拡張機能にも対応する。 日本市場への影響 Azureを活用している日本企業にとっても注目すべきサービスだ。特に、データ分析基盤（Databricks）とアプリケーション用DBを別々に運用しているケースでは、アーキテクチャの統合によってコスト削減と開発効率化の両立が期待できる。物流データ企業のHafniaは「アプリ・分析・AIを1つのガバナンス基盤に統合し、データ重複をなくしてリアルタイム機能を迅速に出荷できるようになった」とコメントしている。 Lakebaseは現在14のAzureリージョンで利用可能となっており、既存のAzure投資を活かしながら統一データアーキテクチャへの移行を検討している組織にとって有力な選択肢となりそうだ。 元記事: Azure Databricks Lakebase is Generally Available

脆弱なMagentoストアの半数以上が攻撃対象に ECサイト向けオープンソースプラットフォーム「Magento Open Source 2」およびAdobe Commerceに存在する重大な脆弱性「PolyShell」を悪用した攻撃が急速に拡大している。eコマースセキュリティ企業のSansecによると、脆弱なストア全体の**56.7%**がすでに攻撃の標的となっていることが確認されている。 公開からわずか2日で大規模悪用が始まる 攻撃が本格化したのは2026年3月19日。脆弱性の詳細が公開されてからわずか2日後という驚くべきスピードで、攻撃者による大規模な悪用（マスエクスプロイテーション）が開始された。脆弱性の公開から実際の攻撃開始までの期間がこれほど短いケースは珍しく、ECサイト運営者にとって非常に危険な状況だ。 脆弱性の仕組み PolyShellの問題はMagentoのREST APIに起因する。カートアイテムのカスタムオプションとしてファイルアップロードを受け付ける仕様を悪用し、ポリグロットファイル（複数のファイル形式として解釈できる特殊なファイル）を送りつけることで以下の攻撃が可能になる。 リモートコード実行（RCE）: Webサーバーの設定によっては任意のコードを実行可能 ストアドXSSによるアカウント乗っ取り: 保存型クロスサイトスクリプティングを通じた管理者権限の奪取 Adobeは2026年3月10日にリリースしたバージョン2.4.9-beta1でこの問題を修正したが、現時点では安定版（本番環境向けリリース）への反映はまだ行われていない。BleepingComputerがAdobeに正式なセキュリティアップデートの公開時期を問い合わせたが、回答は得られていないという。 WebRTCを悪用した次世代型カードスキマー Sansecはさらに、一連の攻撃の中で検出された高度なクレジットカード情報窃取ツール（スキマー）についても報告している。このスキマーはWebRTC（Web Real-Time Communication）を悪用してデータを外部へ送信するという、これまでにない手法を採用している。 WebRTCはHTTPではなくDTLS暗号化されたUDP通信を使用するため、多くのサイトで設定されているコンテンツセキュリティポリシー（CSP）のconnect-src指定をすり抜けやすい。 具体的な動作としては、 軽量なJavaScriptローダーとして埋め込まれ、偽のSDP交換を通じてC2サーバーに接続 暗号化されたチャネル経由で第2段階のペイロードを受信 既存のスクリプトnonceの再利用やunsafe-evalへの fallbackによりCSPを回避して実行 requestIdleCallbackを使って実行タイミングを遅らせ、検出を回避 Sansecによれば、このスキマーは時価総額1,000億ドル超の自動車メーカーのECサイトでも検出されたが、同社は通知に応答していないという。 運営者が今すぐ取るべき対策 Adobeの安定版パッチがまだリリースされていないため、ECサイト運営者は以下の対応を急ぎたい。 Sansecが公開している攻撃元IPアドレスリストを参照し、WAFやファイアウォールでブロックする ファイルアップロード設定を見直し、不要なファイル形式を拒否する サーバーログやSansecが公開している侵害インジケーター（IoC）を使って既感染がないか確認する Adobeのセキュリティアドバイザリを継続的に監視し、安定版パッチが公開され次第すみやかに適用する Magentoは国内外を問わず多くのECサイトで利用されているプラットフォームであり、日本企業の運営するサイトも例外ではない。パッチ待ちの間も緩和策を積極的に実施することが強く推奨される。 元記事: PolyShell attacks target 56% of all vulnerable Magento stores

パッケージマネージャーに「冷却期間」を——サプライチェーン攻撃への新たな防衛策 LiteLLMのサプライチェーン攻撃（2026年3月）を受け、開発者コミュニティで改めて注目を集めているのが「依存関係クールダウン（dependency cooldown）」という考え方だ。これは、パッケージの更新版をすぐにインストールするのではなく、リリースから数日間待機してコミュニティが問題を検出できる時間を設けるという手法である。 オープンソース開発者のAndrew Nesbittが2026年3月にまとめたレポートによると、この機能への対応は予想以上に急速に広まっており、主要ツールが続々と実装を完了させている。 各ツールの対応状況 JavaScript/TypeScript系： pnpm 10.16（2025年9月）— minimumReleaseAge オプションを追加。信頼済みパッケージには minimumReleaseAgeExclude で除外設定が可能 Yarn 4.10.0（2025年9月）— npmMinimalAgeGate（分単位で指定）を実装。npmPreapprovedPackages で承認済みパッケージの除外もサポート Bun 1.3（2025年10月）— bunfig.toml 経由で minimumReleaseAge を設定可能に npm 11.10.0（2026年2月）— min-release-age オプションを追加 JavaScript以外： Deno 2.6（2025年12月）— deno update および deno outdated コマンドに --minimum-dependency-age フラグを追加 uv 0.9.17（2025年12月）— 既存の --exclude-newer に相対期間指定を追加。exclude-newer-package によるパッケージ単位の上書き設定も可能 pip 26.0（2026年1月）— --uploaded-prior-to オプションを追加（現時点では絶対タイムスタンプのみ対応） pip の相対期間指定はまだ未対応 Pythonの標準パッケージマネージャーである pip は現時点で絶対日時のみの指定に限られており、「3日以上経過したものだけ」といった相対的な指定には未対応だ。ただし開発者のSeth LarsonはCronジョブを使って pip.conf 内の日付を定期更新するという回避策を公開しており、相対期間指定のサポートはGitHub Issueで正式に要望されている。 なぜ今、この対策が重要なのか サプライチェーン攻撃とは、正規パッケージの更新に悪意あるコードを混入させる手法で、近年急増している。攻撃者はリリース直後の短い時間帯を狙うことが多く、クールダウン期間を設けることでコミュニティやセキュリティ研究者が問題を発見・報告する時間的余裕が生まれる。 日本の開発者にとっても、本番環境での npm install や pip install を自動化している場合は特に注意が必要だ。CI/CDパイプラインにこれらのオプションを組み込むだけで、ゼロコストに近い形でリスクを大幅に低減できる。 元記事: Package Managers Need to Cool Down ...