Windows

MetaがInstagramのダイレクトメッセージ（DM）におけるエンドツーエンド暗号化（E2EE）機能を標準設定から廃止したことを受け、電子フロンティア財団（EFF）が「プライバシーをユーザー自身の設定ミスのせいにするな」と激しく批判した。 エンドツーエンド暗号化（E2EE）とは何か E2EEとは、送信者と受信者の端末間でのみメッセージが復号される仕組みだ。通信事業者やサービス提供者であっても内容を読み取ることができない。WhatsApp（Meta傘下）やSignalが採用している方式として知られており、個人の通信プライバシーを技術的に保証する最も確実な手段のひとつとされている。 InstagramのDMは以前、E2EEをオプトイン形式（任意で有効化）で提供していた。Metaはこれをさらに後退させ、標準設定から完全に外した。ユーザーが自分で設定変更しない限り、Metaのサーバーを経由した非暗号化の通信状態がデフォルトになる。 EFFの主張：「Privacy by Default」が設計の原則 EFFが問題視しているのは、機能の有無ではなく設計思想だ。 「ほとんどのユーザーはプライバシー設定を深く掘り下げない。それは怠慢ではなく、普通の人間の行動だ」とEFFは主張する。「プライバシーを守りたければ設定を変えろ、変えなかったのは自己責任」というロジックは、プライバシーを権利ではなくプレミアム機能として扱う考え方であり、EFFはこの構造を根本から否定している。 EUでは「Privacy by Design（設計段階からのプライバシー組み込み）」がGDPRの要件に位置づけられており、欧州規制当局がこの件をどう判断するかが今後の焦点になる可能性がある。 Metaの思惑：コンテンツモデレーションという建前 E2EEが有効だとMetaはメッセージの内容を読めない。有害コンテンツの拡散防止や法執行機関への情報提供という正当な理由を掲げつつも、広告ターゲティングや政府・司法当局への情報開示を可能にしておきたいという動機も透けて見える。この構図に対してEFFは明確に「プライバシーの問題はユーザーに転嫁されている」と指摘している。 実務への影響——日本の企業・IT管理者に問われること 日本の業務環境でInstagramのDMを主要なコミュニケーション手段として使うケースは多くないかもしれない。しかし、このニュースが提起している本質的な問いはどこにでも当てはまる。 「自社のサービスやシステムで、セキュリティ設定のデフォルトはどうなっているか？」 たとえばMicrosoft 365では、Teamsの外部ゲスト招待設定、SharePointの共有スコープ、Exchange Onlineのメール暗号化など、多くの設定がデフォルト値のまま使われている。「使いたい人は申請して有効化してください」というアプローチは、Metaが批判されているのと構造的に同じ問題を抱えている——セキュリティを「特殊な操作を要求される面倒なもの」として位置づけてしまうのだ。 実務上のチェックポイントとして以下を挙げておく： 自社で使うSaaSの通信がE2EEかどうか、利用規約・サービス仕様で確認する TeamsやSlack等のビジネスチャットにおけるメッセージの保存・閲覧ポリシーを把握し、従業員に周知する 「デフォルト設定のまま使うユーザーが多数派」という前提でポリシーを設計し直す GDPR・個人情報保護法の観点から、自社サービスのプライバシーデフォルトを棚卸しする 筆者の見解 セキュリティの設計において「ユーザーが設定すれば守られる」という発想は、昔から繰り返し失敗してきた。大手プラットフォームであっても例外ではない、というのが今回改めて示された。 「禁止ではなく、安全に使える仕組みを作ること」が正しいアプローチだと筆者は考えている。しかし今回MetaがやったことはE2EEをデフォルトから外すこと——安全な選択肢をユーザーが積極的に選ばなければ辿り着けない場所に置いてしまった。これはEFFの言う通り、設計として明らかに間違っている。 この話を日本のIT現場に引き寄せれば、Metaだけの問題ではない。Entra IDの条件付きアクセスポリシー、Teamsの外部共有設定、クラウドストレージの公開範囲——「デフォルトは何か」「ユーザーが何もしなければどうなるか」を設計の出発点に置くことが、プライバシーとセキュリティを両立させる唯一の現実的な方法だ。利用者に後から設定を押しつけるのではなく、安全な状態がデフォルトになる設計こそが求められている。 出典: この記事は EFF slams Meta for killing Instagram encrypted chats and blaming users の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Mojangは、Minecraft Java Editionに新たなピア・ツー・ピア（P2P）方式のマルチプレイ機能を追加することを発表した。これにより、プレイヤーは専用サーバーをホストしたり、有料のサーバーレンタルサービスを利用したりすることなく、オンラインで友人と一緒にプレイできる新しい選択肢が生まれる。 現状の課題：サーバー運用のハードル Minecraft Java Editionでマルチプレイを楽しむには、これまで主に以下の方法が使われてきた。 自己ホスト型サーバー：自分のPCや自宅サーバーでマインクラフトサーバーソフトウェアを稼働させる方法。ネットワーク知識（ポート開放・グローバルIP管理など）が必要で、初心者には敷居が高い 有料レンタルサーバー：Realmsなどの公式サービスや第三者のホスティングサービスを利用する方法。手軽だが月額費用が発生する P2P方式が追加されれば、ホスト側のプレイヤーが専用サーバーを立てることなく、直接参加者同士を接続できるようになる。 P2P方式の仕組みと期待される利点 P2P（Peer-to-Peer）接続とは、中央サーバーを介さずにプレイヤー同士が直接通信する方式だ。スポーツや音楽ゲームなど多くのオンラインゲームで採用されており、以下のようなメリットが期待できる。 コスト削減：サーバーレンタル費用が不要になる セットアップの簡素化：ポート開放などのネットワーク設定が不要（または大幅に簡略化） 少人数グループへの適性：友人数人で気軽にプレイするケースに最適 一方で、P2P方式には技術的なトレードオフも存在する。ホストとなるプレイヤーのPC性能・回線状況が接続品質に直接影響するため、大規模コミュニティサーバーや長期運用には引き続き専用サーバーが適している。 実務での活用ポイント 教育・企業研修での利用者へ：Minecraftは教育版（Education Edition）の他、社員研修やチームビルディングに活用する企業も増えている。P2P方式により、IT担当者がサーバー環境を用意せずとも手軽にセッションを開催できるようになれば、導入障壁が下がる。 保護者・子ども向け：子どもが友人とMinecraftで遊ぶためだけにサーバーを立てるのは、保護者にとってもセキュリティ上の懸念点（ポート開放によるリスクなど）があった。P2P方式でその負担が軽減されるなら歓迎できる。 サーバー管理者・コミュニティ運営者へ：この変更はあくまでカジュアルプレイ向けの選択肢追加であり、大規模サーバーやモッドサーバーが不要になるわけではない。既存のサーバー文化は引き続き健在だ。 筆者の見解 MinecraftはMicrosoftがMojangを2014年に25億ドルで買収して以来、Microsoftのゲーム・教育戦略の中核を担ってきた。今回のP2P機能追加は、そのブランドが持つ最大の強みである「誰でも入れる間口の広さ」をさらに強化する方向であり、正しい施策だと感じる。 技術的に見ると、NATトラバーサルやホールパンチングの実装品質が使い勝手を大きく左右する。この部分の完成度が低ければ「繋がらない」という不満が蓄積するため、Mojangがどこまで丁寧に仕上げてくるかは注目点だ。 また、セキュリティの観点からも気になる点がある。P2P接続ではホスト側のIPアドレスが相手に見える可能性があり、VPNやリレーサーバーの活用など、プライバシー保護の仕組みを標準で提供するかどうかが問われる。「気軽さ」と「安全性」の両立こそ、今回のアップデートの真価が問われる部分だろう。 Minecraftには技術の進歩を素直に取り込んでいく柔軟さがある。この機能が成熟すれば、日本の教育現場や企業研修での活用がさらに広がる可能性がある。Mojangの実装の丁寧さに期待したい。 出典: この記事は Minecraft Java Edition is getting peer-to-peer multiplayer support from Mojang の内容をもとに、筆者の見解を加えて独自に執筆したものです。

学習管理システム（LMS）「Canvas」を運営するInstructureが、犯罪グループ「ShinyHunters」による一週間以内の二度の侵害を受け、2億8千万件以上の学生・教職員データが流出した。米下院国土安全保障委員会はCEOのSteve Daly氏に議会証言を要求しており、米国教育インフラへのサイバー攻撃として異例の規模に発展している。 何が起きたか 2026年4月29日、InstructureはCanvasへの不正アクセスを検知。流出したデータには学生・教職員の氏名、メールアドレス、学籍番号、および学生と教師間のメッセージが含まれる。パスワードや金融情報、政府発行の識別番号は含まれていないとされている。 5月3日、ShinyHuntersがBleepingComputerへの声明で犯行を認め、「8,809の大学・学区・オンライン教育プラットフォームから2億8千万件のデータレコードを窃取した」と主張した。 二度目の攻撃：XSSで管理者セッションを奪取しログイン画面を改ざん グループは同週内に二度目の攻撃を敢行。クロスサイトスクリプティング（XSS）脆弱性を悪用して管理者の認証済みセッションを乗っ取り、全米の大学・学校のCanvasログインポータルを改ざんして「Instructureと交渉しろ」という恐喝メッセージを表示させた。 カリフォルニア、フロリダ、テキサス（サンアントニオ大学など）、ジョージア、ネバダ、ウィスコンシンほか計11州で被害が確認されており、期末試験・学期末の最中に試験が中止に追い込まれた教育機関も複数報告された。 身代金交渉の顛末 その後ShinyHuntersは突如InstructureをデータリークサイトからDelete。同社は「グループとの合意に達し、流出データの公開停止と削除を確約された」と発表した。身代金の支払いについては明言を避けているが、同種の事例では合意の裏に何らかの対価が存在するのが通例だ。ShinyHuntersはその後「データは消去済み。各教育機関が個別に交渉に来る必要はない」との声明をサイトに掲載している。 実務への影響——日本の教育機関・IT管理者が今すぐ確認すべきこと 今回の攻撃ベクターであるXSSは古くから知られた脆弱性だが、管理者セッション奪取という形で依然として高い破壊力を持つ。Canvas以外のLMS（Moodle、Blackboard、Google Classroomなど）を使用している組織でも、以下を優先的に確認してほしい。 Content Security Policy（CSP）の設定: XSS攻撃の影響範囲を限定する最も即効性のある対策 管理者セッション管理の見直し: 有効期限の短縮、MFA適用状況、IPバインディングの検討 サードパーティ統合の棚卸し: LMSに連携している外部サービスの権限スコープを定期的にレビューする 試験期間中のインシデント対応計画: 「試験中にシステムが使えなくなった場合」のフォールバックを実際に訓練しているか確認する また、身代金交渉については日本でも判断を迫られるケースが増えている。「支払いが成立した事例」として犯罪グループ側に記録されることのリスクも踏まえた上で、あらかじめ組織としての方針を定めておくことが不可欠だ。 筆者の見解 今回の侵害で改めて浮き彫りになったのは、「古典的な脆弱性が今なお最前線で使われている」という現実だ。XSSは20年以上前から文書化された攻撃手法であり、対策もよく知られている。それでも管理者セッション奪取に使えてしまったという事実は重い。 特権アカウントへの「常時アクセス権の付与」こそが今回の被害を拡大させた根本要因の一つだ。管理者セッションがアクティブでなければ、XSSで奪取できるものもない。Just-In-TimeのアクセスとゼロトラストモデルはLMSのような広域SaaSにこそ適用すべき構造的な解であり、今回の事件はその必要性を再証明した形になった。 全国規模の教育インフラを単一のSaaSプラットフォームに集約することのリスクも、今後の調達判断に組み込む必要がある。ベンダーのインシデント対応能力とディスクロージャーポリシーは、機能比較と同等の評価軸になりつつある。期末試験というタイミングを狙った攻撃は、計算づくの戦略だ。防御側も「最も痛い時期を狙われる」前提でBCP・DRPを組み立てる時代になった。 出典: この記事は US govt seeks Instructure testimony on massive Canvas cyberattack の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年4月24日、Windows Insider Programのチャンネル体系を大幅に刷新し、従来のDev・Canaryチャンネルを統合した「Experimental」チャンネルと、安定テスト向けの「Beta」チャンネルの2本立て構成に移行すると発表した。 Windows Insider Programの新チャンネル構成 これまでWindows Insider Programには、安定性の低い順にCanary・Dev・Beta・Release Previewの4チャンネルが存在していた。今回の再編で最前線テスト向けのCanaryとDevが「Experimental」チャンネルに統合され、全体の構成がシンプルになった。 Experimentalチャンネルとは Experimentalチャンネルは、最新かつ不安定な機能を試したいユーザー向けの場所だ。従来のCanaryに相当する位置づけで、製品化が保証されていない実験的機能が次々と投入される。 最大の目玉はFeature Flagsページの導入だ。このページでは、個別の新機能をユーザー自身がON/OFFできる。「この機能は試したいが、あの機能は不安定で使いたくない」という細かいニーズに応えられるようになる。 チャンネル間移動がクリーンインストール不要に 従来、チャンネルをまたいで移動する際はクリーンインストールが必要なケースがあったが、今回の再編によりこの制約が緩和される。Experimentalから安定度の高いBetaへの降格も、クリーンインストールなしで行いやすくなるという。 実務への影響 この変更が最も恩恵をもたらすのは、企業内のWindows展開を担う管理者や検証担当者だろう。 Feature Flagsによる個別機能制御が可能になることで、「この機能だけ先行して業務システムとの互換性を確認したい」という部分的な検証シナリオが現実的になる。全機能を一括で飲み込むか、古いビルドに留まるかという二択から解放される意義は大きい。 また、クリーンインストール不要のチャンネル移動は、検証用マシンの運用コストを下げる。最前線の機能を確認した後、素早くBetaに戻して安定環境で業務を継続するといったサイクルが回しやすくなる。 エンドユーザー向けには、Insiderとして参加しながらも「日常使いに支障をきたす不安定な機能だけをオフにする」という現実的な運用が可能になる点が魅力だ。 筆者の見解 正直なところ、WindowsのInsiderビルドを細かく追う必要性は年々薄れていると感じている。AIエージェントやクラウドサービスの進化スピードと比べると、デスクトップOSのイテレーションはどうしても地味に映る。 ただ、今回のFeature Flagsの導入は評価したい。これはただのUI変更ではなく、「ユーザーが自分の使い方に合わせてOSをコントロールできる」という方向性への一歩だ。禁止やロールバックで対処するのではなく、公式の仕組みの中で粒度細かく選択できるようにする——これは正しい設計思想だと思う。 Insiderプログラムをより使いやすくすることはフィードバックループの質を高め、製品品質の向上にも直結する。機能を絞り込むのではなく、透明性と制御性を高めることで参加者を増やすというこのアプローチが、今後のWindowsの開発スタイルとして定着してほしい。 出典: この記事は We’re moving to Experimental and Beta! Announcing new builds for 24 April 2026 | Windows Insider Blog の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11のFile Explorerが、libarchiveというオープンソースライブラリを採用し、UU・CPIO・XAR・NuGet（.nupkg）という4つのアーカイブ形式のネイティブサポートを追加した。しかもアーカイブを一時フォルダに展開せず「仮想ファイルシステム」としてマウントする実装を採用しており、これまで7-Zip等のサードパーティ製ツールに頼ってきた開発者やIT管理者にとって、見逃せないアップデートだ。 libarchiveとは何か、なぜ今これが重要か libarchiveはLinux・macOS・BSDの世界では長年使われてきたアーカイブ処理の標準ライブラリだ。tar・cpio・zipなど多数の形式を統一的に扱えることから、Linuxのパッケージ管理ツール（pacman、pkgなど）にも採用されている実績ある実装であり、OSS界隈では「枯れた信頼できるライブラリ」として知られている。 Windowsがこのライブラリをシステムレベルで採用したことは、近年のMicrosoftが「自前主義よりもオープンソースの資産を素直に取り込む」という姿勢を続けていることの表れでもある。 追加された4形式、それぞれの実用上の意味 UU（UUencode） バイナリをASCIIテキストに変換する古典的な形式。メール添付全盛期の遺物と思いきや、組み込み系やレガシーシステムとのやり取りで今なお生き残っているケースがある。 CPIO RPMパッケージの内部形式や、Linuxのinitramfsイメージに使われる形式だ。Windowsでネイティブに扱えるようになることで、LinuxとWindowsを行き来するクロスプラットフォーム開発者には地味に嬉しい対応。 XAR macOSのインストーラー（.pkg）の内部形式として使われていた形式。XcodeツールチェーンやmacOS向けパッケージを扱うプロジェクトとの連携がある場面で役立つ。 NuGet（.nupkg） .NETの標準パッケージ形式で、Visual Studioを使う開発者にとっては毎日触れるファイル形式だ。パッケージの内部構造確認や、サードパーティパッケージの精査がエクスプローラー上でそのまま行えるのは実用性が高い。 仮想FSマウント方式の技術的な意義 今回の実装で注目すべき点は「ディスク展開なし」の仮想ファイルシステム方式にある。従来の多くのツールは、アーカイブを開く際に一時フォルダへ実ファイルを展開してから表示していた。今回の実装ではアーカイブをその場でマウントして内部を参照できるため、以下のメリットがある。 大容量アーカイブでも待ち時間なくブラウズできる 一時ファイルの残骸がストレージに残らない 展開→削除という作業フロー自体が不要になる 実務への影響 開発者向け .nupkgファイルの中身を確認したい場面は思いのほか多い。パッケージが意図した構造になっているかの検証や、サードパーティパッケージの内部精査が、別途ツールを起動せずエクスプローラー上で完結する。 IT管理者・インフラ担当向け Linux系のCPIOやXAR形式のファイルを受け取る場面では、これまでWSL経由か専用ツールのインストールが必要だった。標準機能で開けるようになることで、ツール管理コストが一つ削減できる。 セキュリティ観点 ファイル展開を伴わないマウント方式は、一時ファイルによる意図しないデータ残存リスクを低減する。細かい話に見えるが、端末上でのデータハンドリングの安全性という観点からは歓迎できる実装だ。エンタープライズ環境でサードパーティツールの管理を減らせることも、攻撃面の縮小につながる。 筆者の見解 Windowsを細かく追い続けることに年々意味が薄れているのは正直なところだが、今回のアップデートは少し毛色が違うと感じている。 libarchiveの採用は「オープンソースコミュニティの資産をWindowsに持ち込む」という選択であり、開発ツールとしてのWindowsの地位を地道に高める積み重ねだ。NuGet形式のネイティブ対応は.NET開発者の日常に直接刺さるし、CPIO対応はLinuxとのクロスプラットフォーム作業をわずかながら楽にする。 「地味だが確実に役立つ改善」を積み重ねるポテンシャルは、Microsoftには間違いなく備わっている。派手さはなくとも、使う人の手間を一つ一つ減らしていく姿勢には、実際に価値がある。エンタープライズ現場でのツール管理負荷を減らし、標準機能の信頼性を高めていく方向性は、正しい道のりだと思う。こういう「縁の下の充実」を続けることが、長期的なプラットフォームとしての強さにつながるはずだ。 出典: この記事は Windows 11 expands built-in archive support to UU, CPIO, XAR, and NuGet formats via libarchive の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11の最新Insider Preview（ビルド26220.8165）で、約30年間変わらなかったFAT32フォーマットの上限制限がついに解除された。1996年のWindows 95 OSR2以来ずっと32GBに固定されていたコマンドライン上の上限が、最大2TBまで拡張されたのだ。地味に見えて、実はかなり根の深い話である。 FAT32の32GB制限とは何だったのか FAT32は、FAT16の後継としてWindows 95 OSR2で登場した。当時としては大容量HDDへの対応が主目的だったが、MicrosoftはすでにNTFSを本命として位置づけていた。NTFSはジャーナリング、アクセス権管理、大容量サポートといった機能において圧倒的に優れており、企業ユースにはNTFSを、ポータブルストレージにはのちにexFATを推す方向で動いていた。 この32GBという上限は、意図的なデザイン判断だった。技術的にFAT32が32GB超を扱えないわけではなく、他のOSで作成した32GB超のFAT32ボリュームはWindowsでも読み込めた。PowerShellや、サードパーティのフォーマットツールを使えば作成することもできた。Windowsが「作ることを拒否していた」だけなのだ。この人為的な制約が、約30年間ユーザーをNTFSまたはexFATへと誘導し続けた。 今回の変更点 2026年4月10日リリースのInsider Preview（Beta Channel: ビルド26220.8165 / KB5083635、Dev Channel: ビルド26300.8170 / KB5083632）で、formatコマンドのFAT32上限が32GBから2TBへ引き上げられた。 主な変更点をまとめると： コマンドラインのformatコマンドで最大2TBのFAT32ボリュームを作成可能に ディスクプロパティ表示（設定 → システム → ストレージ → 詳細なストレージ設定）のパフォーマンス改善も同梱 GUIのエクスプローラーからは依然として非対応 ファイルサイズの4GB上限は変更なし 実務への影響——どんな場面で使えるか NTFSでもexFATでもなくFAT32を使う理由が今でもある。それはクロスプラットフォーム互換性だ。Linuxサーバー、組み込みデバイス、古い映像機器、車のカーナビ、家電のUSBポートなど、exFATに対応していない機器では今なおFAT32が「最大公約数」として機能する。 IT管理者・エンジニアへの実践的なヒント： 大容量USBメモリやSDカードの運用が変わる可能性：64GB以上のメモリを古い機器に使いたい場合、これまではサードパーティツール頼みだったが、Windowsのネイティブコマンドだけで対応できるようになる（Insider卒業後が前提） GUIでは使えない点に注意：スクリプトや自動化フローに組み込む場合、format /FS:FAT32 /Q X:のようなコマンドラインオペレーションが必要。エクスプローラーからのフォーマットでは旧来の挙動のまま 4GBファイルサイズ制限は健在：動画や仮想ディスクなど大ファイルを扱う用途には依然としてexFATかNTFSを選ぶべき。「2TBフォーマットできる＝大ファイルOK」ではない点を社内に周知しておくと混乱が防げる Insider限定の現状を把握する：現時点でこの機能を使えるのはInsider Programに参加した端末のみ。本番環境への適用は正式リリースを待つのが安全策 筆者の見解 FAT32の制限解除は、エンジニアにとっては「やっとか」という感慨を覚える話だ。技術的に可能なことを30年間人為的に制限し続けた背景には、NTFSへの誘導というMicrosoftの明確な意図があったが、現実には「互換性のためにどうしてもFAT32が必要」という場面がずっと残り続けた。その乖離に悩んできた人は少なくないはずだ。 Windowsを毎週細かく追いかける時代ではなくなってきているが、こういった「地味だが長年の痒いところに手が届く」改善は素直に評価したい。ユーザーが実際に困っていたことに向き合い、動かしてくれたのだから。 ただ、一点だけ添えておく。GUIでの対応が見送られているのは、UI設計コストか安全面への配慮かは不明だが、「コマンドラインを知らないユーザーには恩恵がない」という意味でもある。Windowsの強みはGUIの使いやすさにあるはずで、この種の機能拡張こそ設定画面にきちんと反映させてほしい。コマンドラインしか対応しない改善をリリースノートのトップに持ってくるのは、ユーザー層のミスマッチが気になる。正面から実装できる実力がある会社なのだから、中途半端に終わらせずに仕上げてほしい。 正式リリースでGUIも対応済みになった暁には、改めてしっかり評価したいと思う。 出典: この記事は Windows 11 Breaks a 30-Year Barrier: FAT32 Now Supports Up to 2 TB の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2011年に発行されたSecure Boot証明書が、2026年6月26日をもって失効する。Microsoftは5月のPatch Tuesdayからロールオーバー（証明書の更新）を段階的に展開しているが、対応が間に合わないデバイスは翌日からセキュリティ保護が低下した状態で稼働し続けることになる。「今動いているから大丈夫」が通用しない、典型的な事例だ。 Secure Boot証明書とは何か Secure Bootは、PCの起動プロセスにおいてブートローダーやカーネルが信頼できるコードのみを実行することを保証するUEFIの機能だ。この「信頼できるコード」を判断するための署名証明書が、今回失効対象となる。 問題は証明書そのものが失効することではなく、更新が行われないデバイスでは「信頼チェーンの起点」が機能しなくなる点にある。攻撃者はこの状態を突いて、署名されていない、または不正な署名のブートローダーを実行できるようになる可能性がある。 ロールオーバーの仕組みと注意点 Microsoftは5月のPatch Tuesdayを皮切りに、Windows Updateを通じた証明書ロールオーバーを開始した。多くのデバイスは通常のWindows Updateを適用するだけで新しい証明書が導入される。 しかし注意が必要なのは一部のデバイスでOEMファームウェアの更新が別途必要なケースだ。UEFIファームウェアレベルで証明書を管理しているデバイスでは、OSの更新だけでは完結しない。OEMが提供するBIOS/UEFIアップデートを別途適用する必要がある。 デバイスの対応可否を確認する主なポイントは次のとおり： Windows Updateの適用状況（最新パッチが当たっているか） OEMメーカーのサポートページで該当機種のUEFIアップデートが出ているか 企業内展開ではWSUSやIntune経由での適用追跡ができているか 6月26日を過ぎると何が起きるか 6月26日以降、旧証明書で署名されたブートコンポーネントは信頼されなくなる。最悪のケースでは起動できなくなるデバイスが出る可能性もあるが、より現実的なシナリオは「Secure Bootの保護機能が実質的に機能しなくなる」状態での稼働継続だ。 特にエンタープライズ環境では、BitLockerとSecure Bootを組み合わせたブート整合性保護に依存している構成が多い。このチェーンが崩れると、物理アクセスがあれば暗号化ボリュームを迂回できるリスクが高まる。 実務への影響——日本のIT管理者がすべきこと 今週中に動け、というのが率直なアドバイスだ。 資産台帳を引っ張り出す — 管理下のデバイス一覧を確認し、OEMファームウェアの更新が必要な機種を特定する。古い法人PCは特に要注意 Windows Updateの適用状況を確認 — Intune/WSUSのコンプライアンスレポートで5月パッチ適用率を確認し、未適用デバイスがあればリマインドをかける OEM更新情報を収集 — Dell、HP、Lenovo、Fujitsu、NECなど主要OEMのサポートページで対象ファームウェアアップデートをリストアップする 展開テストを先行させる — いきなり全台に展開せず、少数台でファームウェア更新後の起動確認を取る BitLocker回復キーの確認 — ファームウェア更新がTPM計測値に影響する場合があるため、作業前に回復キーが手元にあることを必ず確認する 筆者の見解 Secure Bootのアーキテクチャは技術的によくできている。15年間、ルートオブトラストとして機能し続けたことはひとつの成果だ。今回のロールオーバーをMicrosoftが丁寧に段階展開しているのも評価できる。 ただし今回明らかになるのは「Windows Updateさえ当てていれば終わり」という前提の限界でもある。OEMファームウェアという更新経路が別途存在し、IT管理者はその両方を把握していなければならない。特に中堅・中小企業では「PCはIT担当が管理しているから大丈夫」と思われているが、ファームウェアの更新まで追えている組織はほとんどないのが実態だ。 「今動いているから大丈夫」は本当に通用しない。6月27日の朝、突然Secure Bootが機能しなくなっているデバイスが社内に数十台ある——そんな事態は誰も望まない。期限がハッキリしている珍しいセキュリティタスクだからこそ、今すぐカレンダーに「6月26日」を入れて、逆算で動いてほしい。あとは管理者側がOEMの更新まで含めて確実にフォローアップできるかどうかにかかっている。 出典: この記事は May 2026 Secure Boot Certificate Rollover: One Restart, Big Firmware Risk の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWord、Excel、PowerPoint、OutlookにおけるCopilotのアクセス方法を大きく刷新している。これまでの「サイドバーを開いて対話する」スタイルから、アプリ本体にネイティブ統合された直感的なエントリーポイントへの移行が進められている。UIの改善はCopilot普及の起爆剤になり得るか、注目が集まる。 サイドバーからネイティブ統合へ 従来のCopilotは画面右側にパネルとして展開するサイドバー方式を採用していた。ユーザーがAI機能を呼び出すたびに作業コンテキストを離れる必要があり、「邪魔」「流れが途切れる」という声は発表当初から絶えなかった。 今回のアップデートはこの構造を根本から見直す。Word・Excel・PowerPoint・Outlookそれぞれに「簡略化されたエントリーポイント」を導入し、作業中の文書やデータから離れることなくAI機能を呼び出せる設計へと変わる。Copilotが「添付ツール」ではなく「Officeそのもの」として動作する体験を目指したものだ。 なぜこれが重要か AIアシスタントの実効活用率は「呼び出しやすさ」に大きく依存する。いくら機能が優れていても、ユーザーが「使う気になる」UIでなければ定着しない。その意味で、サイドバー方式はAIを日常業務に溶け込ませるという目標と構造的に相性が悪かった。 Microsoftが今回目指しているのは、CopilotをOfficeの「オプション機能」ではなく「もともとそこにあったもの」として感じさせるユーザー体験だ。これはAI機能の統合における成熟度を示す重要なシフトであり、ユーザーの習慣形成にも直結する変化と言える。 実務への影響 IT管理者・情報システム担当者向け 展開は Microsoft 365 テナントへの段階的ロールアウトが想定される。タイミングは Microsoft 365 管理センターの「メッセージセンター」で随時確認を UIが変わることで「使い方がわからない」という問い合わせが一時的に増える可能性がある。ヘルプデスク向けの簡易ガイドを事前に準備しておくと対応が楽になる Copilot機能の表示範囲は「Microsoft 365 Copilot」ライセンスの有無で異なる。無償ユーザーと有償ユーザーで見えるUIが変わるため、社内の混乱を避けるためにライセンス構成の整理と周知を推奨する エンジニア・パワーユーザー向け Excel での Copilot は数式生成・データ分析補助としてすでに評価されている部分がある。アクセスが簡単になれば日常業務でのトライアルハードルが下がり、ユースケースの発見が加速するはずだ Outlook での統合は英語メールの作成補助や予定調整の効率化に直結する。グローバル対応が多い業務環境では特に恩恵が大きい Word では長文ドキュメントの要約・構成提案をより素早く呼び出せるようになる。議事録・仕様書・提案書の作成フローへの組み込みを試してみる価値がある 筆者の見解 Copilotは登場から今日まで、機能の磨き込みとUXの「届かなさ」のギャップがずっとついてまわってきた。今回のネイティブ統合への移行は、そのギャップを埋めようとする方向性としては正しい一歩だと思っている。 「サイドバーを開かなければAIが使えない」という体験は、AIをワークフローの中心に置くという思想と真逆の構造だった。それを変えようとしているのは、評価できる判断だ。 ただ、一点だけ率直に言わせてほしい。入り口を改善しても、実際の回答品質・精度が日常業務の水準に届かなければ、印象は逆に悪化しかねない。「すぐ目に入る場所に置いたのに使えない」という体験は、遠いサイドバーの中で完結していたときよりも摩擦が大きい。 Microsoftにはこの刷新を機に、UIだけでなく回答品質の底上げも本気で追ってほしい。強固なインフラ、エンタープライズセキュリティ、Office エコシステムとの統合という土台は、他に代えがたい強みを持っている。その強みをCopilotが本来の形で活かせるようになれば、話は大きく変わる。この変化が「Copilotが変わった」と言われる転換点になることを、期待を込めて注視している。 出典: この記事は Microsoft streamlines access to Copilot in Word, Excel, PowerPoint and Outlook の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GitHubのモバイルアプリが、開発者にとって待ち望んでいた機能を手に入れた。最新のGitHub Mobileでは、スマートフォンやタブレットから直接新しいリポジトリを作成できるようになった。「アイデアが浮かんだらすぐに形にしたい」という開発者の声に応える、地味だが確実に効く機能強化だ。 GitHub Mobileのリポジトリ作成機能とは これまでGitHub Mobileでは、既存リポジトリの閲覧やIssueへのコメント、Pull Requestのレビューといった操作は可能だったが、新しいリポジトリをゼロから作成する機能は備わっていなかった。今回のアップデートにより、モバイルアプリから直接リポジトリ名・説明・公開設定（Public/Private）を指定してプロジェクトを立ち上げられるようになった。 操作は直感的で、アプリ内のナビゲーションから「新しいリポジトリ」を選択し、必要な情報を入力するだけ。READMEの初期化や.gitignoreテンプレートの選択、ライセンスの設定も画面上で完結する。 なぜこれが重要か 開発の現場では「PCの前にいるときだけが作業時間」という概念がすでに崩れ始めている。通勤中や外出先でアイデアが降ってきたとき、メモアプリに書き留めて「あとでPCで」となるのが従来のフローだった。 GitHub Mobileがリポジトリ作成に対応したことで、アイデアの着想からプロジェクトの起点作成までがスマホ一台で完結する。特にソロ開発者やフリーランス、副業エンジニアにとって、素早いプロトタイピング文化の醸成に寄与するアップデートと言える。 さらに、クラウドIDEやAIコーディングアシスタントとの組み合わせを考えると、「リポジトリを作る→コードを書く→PRを出す」という一連のフローがモバイル環境でも現実的になりつつあることを示している。開発ツールのモバイルファースト化は、もはや流行ではなく着実な潮流だ。 実務での活用ポイント 素早い「場所取り」から始める アイデアが浮かんだらすぐにリポジトリを作成し、名前とREADMEだけでも書いておく。「後でPCで作ろう」と思って忘れるより確実に、プロジェクトの存在を記録できる。 チーム招集の起点に活用する リポジトリ作成後、すぐにCollaboratorsを招待する操作もモバイルで可能だ。会議やブレインストーミングの場でその場でプロジェクトを立ち上げ、参加者を巻き込む使い方が現実的になった。 初期Issueの登録まで一気に流す GitHub ProjectsやIssueもモバイルから操作できるため、リポジトリ作成→初期Issueの登録という流れをその場で完結させられる。「あとでやる」を排除できる。 Organizationリポジトリの権限設定には注意 組織（Organization）配下にリポジトリを作成する場合は、公開設定やアクセス権限が意図通りになっているかを必ず確認すること。スマホの小さい画面でも設定ミスは十分起こり得る。Organization管理者はモバイル操作のリスクについてチームに周知しておくと安心だ。 筆者の見解 こういう「派手ではないが確実に使える」アップデートが、実は一番嬉しい。大型のAI機能発表も大切だが、「あ、これ普通に便利じゃん」と感じさせてくれる改善こそが、日常のワークフローに静かに溶け込んでいく。 日本の開発現場では、いまだに「開発環境＝デスクトップPC一択」という感覚が残っているケースも多い。しかし実際には、アイデアの発散や初期設計の議論、軽いコードレビューはすでにモバイルで十分こなせる時代になっている。ツールが整ってきているのに、使う側の習慣が追いついていないとしたら、もったいない話だ。 モバイルを「サブ端末」ではなく「並列作業端末」として位置づけ直す。そのための小さくて確かな一歩が、今回のアップデートだと思っている。情報を追いかけるよりも、実際に手を動かしてワークフローに取り入れてみるのが、今の時代の正しい向き合い方だろう。 出典: この記事は GitHub Mobile now lets you build new projects on the fly の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIが新たなサイバーセキュリティ向けAIツール「Daybreak」を発表した。同社のフロンティアモデルとCodexをエージェント実行レイヤーとして組み合わせ、脆弱性の特定・検証・修復を従来より大幅に高速化するという。AIがいよいよセキュリティ運用の中核に踏み込んできた。 Daybreakとは何か Daybreakは、OpenAIのフロンティアAIモデルを基盤とし、コード生成・実行能力を持つCodexをエージェント層として活用するセキュリティ特化型のシステムだ。セキュリティチームがこれまで手作業で行ってきた「脆弱性スキャン → 再現確認 → 修正コード作成 → 検証」という一連のサイクルを、AIエージェントが自律的に実行することを目指している。 具体的には以下の3フェーズをAIが担う： Identify（特定） — コードベースやインフラ構成から脆弱性を発見する Validate（検証） — 発見した脆弱性が実際に悪用可能かどうかを確認する Remediate（修復） — 問題のあるコードや設定の修正提案・実行を行う セキュリティ運用の何が変わるか 従来のセキュリティ運用では、スキャナーが大量のアラートを吐き出し、アナリストが一件ずつトリアージするという非効率なサイクルが常態化していた。中規模以上の組織では「アラート疲れ（alert fatigue）」が深刻な問題となっており、本当に危険な脆弱性が埋もれてしまうリスクが長年指摘されてきた。 AIエージェントが検証フェーズも担うことで、「実際には悪用不可能な疑陽性（false positive）」を事前に除外し、本当に対処すべきリスクだけを人間のチームに届けられる。これは単なる効率化ではなく、セキュリティの質そのものの向上につながる。 また、修復フェーズにおける自動コード生成は、セキュリティエンジニアとアプリ開発チーム間のコミュニケーションコストを大幅に削減する可能性がある。 実務への影響——日本のIT現場の視点から 日本の多くの企業では、セキュリティ専任チームのリソースが慢性的に不足している。ペネトレーションテストを外注し、報告書が届いても対応しきれずに次の監査を迎える——というパターンは珍しくない。 Daybreakのようなアプローチが普及すれば、以下の変化が期待できる： 継続的な脆弱性検証の自動化: 定期的なペンテストの代替・補完として、常時稼働のAIエージェントが監視を担う Non-Human Identity（NHI）管理との連携: サービスアカウントやAPIキーなどのNHIに起因する脆弱性を自動で特定・修正するフローが現実的になる セキュリティ負債の解消加速: 「対応すべき脆弱性は分かっているが、開発リソースが割けない」という課題に対し、修復コードの自動生成が突破口になりうる 導入を検討する際には、AIが生成した修復コードの人間によるレビュープロセスを必ず設けること、そしてCI/CDパイプラインへの統合を段階的に進めることが重要だ。AIを「全自動で任せる」のではなく、「人間の判断を加速するアシスタント」として位置づけるのが現時点では堅実なアプローチになる。 筆者の見解 率直に言えば、セキュリティという分野はどちらかというと不得意なジャンルだ。しかし技術的な興味は別の話で、今回のDaybreak発表は注目に値すると感じている。 特に興味深いのは「Validate（検証）」フェーズをAIが担う点だ。脆弱性を見つけるだけなら既存のSAST・DASTツールでもできる。しかし「これは本当に悪用できるのか？」を自動的に確認できれば、セキュリティチームの判断コストが劇的に下がる。アーキテクチャとして筋のよいアプローチだと思う。 一方で、AIが「修復した」コードが別の脆弱性を生んでいた、というケースは十分ありうる。認証・認可ロジックのような繊細な領域では、AIの修正提案を鵜呑みにするのは危険だ。「AIが確認したから安全」という過信が、むしろセキュリティの盲点を生むリスクには常に注意が必要になる。 ゼロトラストを基本とした多層防御の文脈で使うなら、Daybreakのような自動化ツールは強力な補完になりうる。ただし、ツールを入れれば終わりではない。「仕組みとして継続的に回せる状態」にするための設計と運用プロセスこそが、最終的な差別化要因になる。道具は整ってきた。あとはそれをどう組み合わせて回すか——結局はここに尽きる。 出典: この記事は OpenAI announces Daybreak to bring frontier AI into cybersecurity workflows の内容をもとに、筆者の見解を加えて独自に執筆したものです。

セキュリティテスト自動化ツールとして現場に広く浸透しているCheckmarxのJenkins ASTプラグインが、公式のJenkinsマーケットプレイスを経由してインフォスティーラーを仕込まれるという事態が発生した。単発の事件ではなく、2026年3月末から続く同一脅威アクター（TeamPCP）による連続攻撃の第三弾——しかも突破口は「シークレットのローテーション漏れ」という、防げたはずの手口だった。 何が起きたか 2026年5月9日（土）、悪意あるバージョン「2026.5.09」がrepo.jenkins-ci.orgへ公開された。このバージョンはCheckmarxの正規リリースパイプラインを経ておらず、Gitタグも存在しない。事後に見れば異常を示すサインはあったものの、自動更新が有効な環境では無警戒にインストールされた可能性がある。 TeamPCPが利用した侵入路は、同グループが3月に実行したTrivyサプライチェーン攻撃で窃取した認証情報だ。その認証情報でCheckmarxのGitHubリポジトリにアクセスし、ASTプラグインに資格情報窃取コードを埋め込んだ。 ハッカーたちが残したメッセージが端的にすべてを語っている： 「Checkmarx fails to rotate secrets again. With love - TeamPCP.」 「またシークレットのローテーションを怠った」——技術的な嘲笑であり、同時に業界全体への皮肉でもある。 攻撃連鎖を整理する 今回の事件だけに目を向けると全容を見誤る。3ヶ月にわたる攻撃の流れは以下の通りだ： 3月（第一波）: npmとTrivyを標的にしたShai-Hulud/Trivyサプライチェーン攻撃。認証情報を窃取 4月（第二波）: 窃取した認証情報でKICS分析ツール（Docker/VSCode/Open VSX）を汚染 5月（第三波）: 同じ認証情報でJenkins ASTプラグインを汚染——今回の事件 「横展開（ラテラルムーブメント）」は侵入した人間だけが行うものではない。一度漏れた認証情報が数ヶ月にわたって使われ続けるという形でも起きる。 影響を受けるバージョンと対応 Checkmarxは以下を推奨している： 安全なバージョン: 2.0.13-829.vc72453fa_1c16（2025年12月17日公開）以前 不正バージョン: 2026.5.09（即座に削除） 不正バージョンをインストールした環境では、以下を前提に動くこと： パイプライン内のすべてのシークレット・APIキー・クラウド認証情報を即座にローテーション 横展開・永続化バックドアの有無を調査 CheckmarxのIoC（侵害の痕跡）リストをSIEMに登録 実務への影響 JenkinsはCI/CDパイプラインの中核として多くの日本企業で稼働している。ASTプラグインはパイプライン内でビルド・デプロイ権限を持つことが多く、侵害されれば本番クラウド環境のアクセスキーまで連鎖するリスクがある。 今すぐ確認すべき項目： バージョン確認: Jenkins管理画面でCheckmarx ASTプラグインのバージョンを確認 更新ログの確認: 2026年5月9日前後に自動更新が実行された痕跡がないか シークレット棚卸し: パイプライン内の認証情報をすべてリストアップし、ローテーション実施 自動更新ポリシーの見直し: プラグインの自動更新に承認フローを挟む設定を検討 筆者の見解 今回の攻撃で最も重要な教訓は、シークレットのローテーションが「やると言っているだけ」で終わっている組織が、攻撃者から見ればとても狙いやすい標的であることだ。Trivyの攻撃で漏れた認証情報が、3ヶ月後にJenkins経由で炸裂した——「今何も起きていないから安全」という判断がいかに危ういかを、この時系列が端的に示している。 そして注目すべきはNon-Human Identity（NHI）の問題だ。今回の攻撃経路は、人間ではなくCI/CDシステムが保持する認証情報だった。業務の自動化・効率化が進むほど、NHIの数は増え、管理が追いつかなくなる。Just-In-Timeのアクセス付与と、不要になった認証情報の即時失効——このサイクルを仕組みとして回せなければ、自動化を進めるほど攻撃対象領域も広がるという皮肉な状況になる。 セキュリティスキャンツールが攻撃の入口になる逆説。これはDevSecOpsの理念そのものを問い直すきっかけでもある。ツールを信頼するのではなく、ツールを含めた全体のサプライチェーンを検証する姿勢が、現代のCI/CD環境では必要不可欠だ。 出典: この記事は Official CheckMarx Jenkins package compromised with infostealer の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11のWindows Updateに、企業IT管理者が今すぐ把握すべき大きな変更が迫っている。ドライバー署名ポリシーの厳格化、ホットパッチのデフォルト有効化、セキュリティデフォルト値の見直しなど、複数の変更が重なることで、「なんとなく回っていた」更新管理が通用しなくなる局面が来る。順に整理しよう。 変更点1：ドライバー署名ポリシーの厳格化 Microsoftは、Windows 11においてドライバーの署名要件を強化する方針だ。WHQL（Windows Hardware Quality Labs）認定やEV証明書が厳しく求められるようになり、署名のないドライバーや品質未検証のカーネルドライバーがブロックされるケースが増える見込みだ。 カーネルレベルのコードはシステム全体に影響を及ぼす。ランサムウェアやルートキットがカーネルドライバーを悪用して侵入するケースは実際に増加しており、この変更はその抑止に直接効く。古い業務用ハードウェアや特殊な周辺機器を使い続けている環境では、「これまで普通に動いていたドライバーが突然使えなくなる」事態が起きるリスクがある。早めの棚卸しが必要だ。 変更点2：ホットパッチのデフォルト有効化 ホットパッチとは、システムを再起動せずにセキュリティパッチを適用できる仕組みだ。Windows 11ではこれがデフォルト有効となり、対応する月次更新では再起動なしでパッチ適用が完了するようになる。 企業環境において、パッチ適用のたびに再起動調整が発生することは長年の運用ボトルネックだった。ホットパッチが標準化されれば、脆弱性が野ざらしになる時間を大幅に短縮できる。ただし、四半期ごとの「ベースライン更新」は依然として再起動が必要であり、すべてが再起動不要になるわけではない。既存の展開フローにホットパッチと通常パッチを使い分ける設計の組み込みが求められる。 変更点3：セキュリティデフォルト値の変更 SMBサインの強制やNTLMv1の無効化など、複数のセキュリティ設定のデフォルト値が変更される。レガシープロトコルへの依存が残っている環境では、変更後に通信断が発生するリスクがある。特にActive Directoryドメイン環境では要注意だ。「動いているから安全」ではなく、「デフォルト変更後も動くかどうか」を事前に検証しておく必要がある。 変更点4：Windows Update for Business ポリシーの刷新 エンタープライズ向け更新管理ツールであるWindows Update for Business（WUfB）の設定項目が再編される。従来のポリシーが一部廃止・統合される予定であり、IntuneやGroup Policyで管理している管理者は設定の棚卸しが必要になる。既存のポリシーが黙って無効化されるリスクもある。 変更点5：更新適用の猶予期間短縮 セキュリティ更新プログラムの展開猶予期間が短縮される方向だ。テストと展開のサイクルをこれまでより短くしなければならなくなるため、パッチ管理プロセス全体の見直しが急務だ。 実務への影響——日本のIT管理者がやるべきこと 今すぐドライバーの署名状態を確認する Device Managerやサードパーティのドライバー管理ツールを使い、現環境で使用しているドライバーのWHQL認定状況を確認しておく。特に製造業・医療・金融などで特殊な業務端末を抱えている現場は優先度が高い。 ホットパッチ対応端末のリスト化 ホットパッチが有効になる端末とならない端末を把握し、展開スケジュールを設計し直す。「全台再起動なし」と誤解したまま運用すると、ベースライン月に混乱が生じる。 レガシープロトコル依存の洗い出し NTLMv1やSMBv1に依存したシステムやアプリケーションがないかを今のうちに確認する。特に長期稼働しているオンプレミスシステムに潜んでいることが多い。 WUfBポリシーの棚卸し IntuneコンソールやADで設定しているWUfB関連ポリシーを一覧化し、変更後も意図どおりに機能するかを検証環境で確認する。 筆者の見解 今回の変更の中で特に評価したいのが、ドライバー署名ポリシーの厳格化とホットパッチの標準化だ。この2つは、セキュリティ強化と運用効率の改善を同時に狙う方向性として、理にかなっている。 カーネルドライバーへの締め付けは、Windowsが長年抱えてきた課題への真っ当な答えだ。ここに手を入れたことは正しい。ホットパッチについても、脆弱性対応の速度を上げながら運用負荷を下げるという発想は、エンタープライズの実態を理解した設計だと思う。 一方で、更新適用の猶予期間短縮には正直なところ慎重になってほしい。実際のところ、「すぐ当てたら壊れた」という報告は今も後を絶たない。パッチの品質が安定していない状況で強制度だけを上げると、IT管理者が「試験展開」を行う余地を奪ってしまう。数日様子を見て展開するという判断は、怠慢ではなくリスク管理だ。 Microsoftにはこれだけのプラットフォームと実績がある。セキュリティ強化の勢いはそのままに、更新品質への信頼を一段引き上げることで、エンタープライズからの信頼をより確固たるものにできるはずだ。その実力があることは間違いない。今回の変更がその一歩になることを期待している。 出典: この記事は 5 things you need to know about changes coming to Windows Update on Windows 11 の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIエージェントがついに「画面を見ながら」作業する時代に MicrosoftがVS Codeの最新アップデートを公開し、AIエージェントを使ったコーディング体験が大きく変わろうとしている。目玉となる新機能は大きく2つ——ブラウザタブのエージェント共有とトークン最適化だ。どちらも「使ってみると当たり前に欲しかった」と感じる類の改善で、開発者が毎日直面する現実の摩擦を正面から削りにきている。 ブラウザ共有：エージェントが「見る」ことで壁が消える これまでのAIコーディングアシスタントは、基本的にテキストとして渡した情報しか知らないという制約の中で動いていた。エラーが出たブラウザ画面、デザインカンプ、APIのドキュメントページ——それらをエージェントに伝えるためには、スクリーンショットを貼るか、テキストをコピーして渡すという手間が必ず発生していた。 今回のブラウザタブ共有機能により、開発者はVS Code内のエージェントに対してブラウザの現在の表示状態を直接参照させることができる。たとえばローカルサーバーで動かしているWebアプリの表示崩れを確認しながら、同時にエージェントがそのUIの状態を把握してコードを修正する、という流れが自然に実現できる。 これはデバッグ作業において特に大きな意味を持つ。「画面ではこう見えているのに、コードで説明するのが難しい」という状況は、現場エンジニアなら誰でも経験しているはずだ。その摩擦をなくすアプローチとして、方向性は正しい。 トークン最適化：コストと速度の両方に効く AIエージェントを実際に業務で使い始めると、すぐに直面するのがトークン消費の問題だ。長い会話や大きなコードベースを扱うほどコンテキストが膨らみ、レスポンスが遅くなり、APIコストも増大する。 今回のアップデートではテレメトリによるトークン使用量のモニタリングが強化された。どの操作でどれだけのトークンを消費しているかを可視化し、不要なコンテキストの圧縮や整理を行う仕組みが整備された形だ。 プロンプトエンジニアリングの世界では「コンテキストのゴミを減らす」ことが品質と速度の両方に直結するというのは常識だが、それをIDEレベルで自動的に支援する仕組みができてくるのは大きな進歩だ。エンジニアがトークン管理を意識する必要性を下げることで、本来の開発作業に集中できる環境が整う。 日本の現場への影響 日本のエンタープライズ開発現場では、AIコーディングツールの導入が急速に進んでいる一方で、「実際にどう使えばいいか分からない」「試してみたけど業務フローに組み込めなかった」という声も多い。今回の機能強化は、そうした現場に対して次のような実践ポイントを提供する。 1. フロントエンド開発・デバッグへの即時活用 ブラウザ共有機能は、CSSやレイアウトのデバッグに即座に使える。デザインレビューの場面でも、「この崩れをそのままエージェントに見せて直す」というワークフローが機能する。 2. コスト管理の可視化から始める トークン最適化の恩恵を受けるためには、まず現状のトークン消費を計測するところから始めると良い。VS Codeのテレメトリ機能を使って「どの操作が重い」かを把握し、段階的に最適化していくアプローチが現実的だ。 3. エージェント活用の「型」を整備する ブラウザ共有とトークン管理が整備されると、「エージェントに依頼するタスクの標準パターン」を作りやすくなる。チーム単位でベストプラクティスを言語化し、再現性のある開発フローを作るチャンスだ。 筆者の見解 VS Codeは今、MicrosoftがAI時代の開発ツールとして本気で仕上げようとしているプロダクトだと感じる。今回の機能群はどれも「現場で実際に困っていた部分」への的確な回答で、付加価値のためのアップデートではなく、実用性の積み上げだ。 ブラウザ共有にしても、トークン最適化にしても、「エンジニアが本来やりたい作業に集中できる環境を作る」という設計思想が一貫している。こういう仕事のできるチームがMicrosoftにいることは素直に評価したい。 一方で、AIエージェント機能全体の体験品質については、まだ「使ってみたら想定外の動きをした」という場面が少なくない。ブラウザ共有のような高度な機能を提供するなら、エージェントの判断精度や暴走防止の仕組みもセットで磨いてほしいというのが正直なところだ。Microsoftにはその実力があるのだから、完成度をもう一段上げることを期待したい。 AIコーディングツールは「使えるかどうか」の時代から「いかに深く日常業務に組み込むか」の時代に移りつつある。VS Codeがそのプラットフォームとして成熟していくことは、日本の多くのエンジニアにとってもプラスになる。今後のアップデートを注視したい。 出典: この記事は Microsoft upgrades VS Code with AI agent browser sharing and token optimization の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Linuxカーネルに新たな特権昇格ゼロデイ脆弱性「Dirty Frag」が出現した。セキュリティ研究者Hyunwoo Kim氏が発見・公開した本脆弱性は、Ubuntu・RHEL・CentOS・AlmaLinux・Fedora・openSUSEなど主要ディストロすべてに影響し、コマンド1行でローカルの一般ユーザーがroot権限を取得できる。パッチが存在しないにもかかわらず、プルーフオブコンセプト（PoC）が公開済みという、Linux管理者にとって非常に厳しい局面だ。 Dirty Fragとは——Dirty Pipe系譜の「進化版」 Dirty Fragは、Linuxカーネルのalgif_aead暗号アルゴリズムインターフェースに約9年前から潜んでいたバグを起点とする。あの「Dirty Pipe」（CVE-2022-0847）や「Copy Fail」と同じバグクラスに属するが、異なるカーネルデータ構造の「フラグメントフィールド」を悪用する点が新しい。 本脆弱性の際立った特徴が2点ある。 2脆弱性の連鎖（CVE-2026-43284 + CVE-2026-43500）: xfrm-ESP Page-Cache Write脆弱性とRxRPC Page-Cache Write脆弱性を組み合わせ、保護されたシステムファイルをメモリ上で不正書き換えする 決定論的バグ（レースコンディション不要）: タイミングに依存しないロジックバグのため成功率が非常に高く、失敗してもカーネルパニックが発生しない Kim氏は本来、ディストロメンテナとの調整後にエンバーゴが明ける予定だったが、無関係な第三者が2026年5月7日に先行公開。パッチもCVEも存在しない状態での完全公開を余儀なくされた経緯がある。 暫定対策——トレードオフを理解して適用する 現時点での公式な回避策は、脆弱なカーネルモジュール（esp4・esp6・rxrpc）を無効化するコマンドの実行だ。 出典: この記事は New Linux ‘Dirty Frag’ zero-day gives root on all major distros の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2025年2月、米国バージニア州の兄弟が連邦政府の委託業者から解雇された直後、96件の政府データベースを消去し、ログ隠滅にはAIアシスタントを利用したという事件が明らかになった。単なる「インサイダー犯罪」の話ではなく、特権アクセス管理の設計に根本的な欠陥があることを示す教科書的な事例だ。 事件の経緯 主犯のSohaib Akhterと双子の兄弟Muneeb Akhterは、2016年にも米国務省のシステムへの不正アクセスと個人情報窃取で有罪判決を受け、服役している。ところが服役後、45以上の連邦機関を顧客とする委託会社に再雇用された。2025年2月18日、雇用主が前科を把握して2人をリモート会議で解雇した——その瞬間から犯行は始まった。 わずか数時間のうちに、2人はシステムへの不正アクセスを行い、データベースに書き込み禁止フラグを設定した上で削除。その後、証拠隠滅のためにAIアシスタントにシステムログの消去方法を尋ねていたことも判明している。削除されたデータには、国土安全保障省（DHS）の捜査記録や情報公開法（FOIA）関連文書など、複数の連邦機関の機密情報が含まれていた。Sohaibは最大21年、Muneebは最大45年の禁固刑に直面している。 なぜこれが起きたのか：3つの構造的失敗 1. バックグラウンドチェックの形骸化 前科者が「45以上の連邦機関の機密データを扱う」ポジションに再雇用されていたこと自体、採用審査プロセスの致命的な欠陥だ。審査はあったはずだが、機能しなかった。 2. 解雇とアクセス権剥奪のタイムラグ 「リモート会議で解雇通知→その直後に犯行」という流れが示すのは、解雇処理とシステムアクセス権の即時剥奪が連動していなかったという事実だ。通知を受けたその瞬間にアクセスできた——この一点が致命的だった。 3. 過剰な常時アクセス権の付与 データベースを即座に削除・改ざんできる権限が、日常業務に不要な形で常時付与されていたとすれば、ゼロトラストの根本原則に反する。「最小権限（Least Privilege）」と「ジャスト・イン・タイム（JIT）アクセス」が徹底されていれば、被害を大幅に抑制できた可能性がある。 AIを「犯罪ツール」として利用 注目すべきは、ログ隠滅のためにAIアシスタントを利用していた点だ。AIの普及が進む中、「AIが攻撃者の支援ツールになり得る」というリスクは以前から指摘されていたが、実際に証拠として出てきたのは印象的だ。とはいえ、AIが「教えてしまった」という問題より、そもそも実行できる権限と環境が存在していたことの方が根本的な問題だ。 実務への影響：日本のIT管理者が今日から考えるべきこと 解雇プロセスとIAMの連携を見直す 「解雇通知と同時にアクセス権剥奪」は、HR（人事）システムとIAM（Identity and Access Management）の連携によって自動化できる。人事異動・退職処理のワークフローに、Entra IDのアカウント無効化・グループ削除を組み込んでいるか確認したい。 JIT（Just-In-Time）アクセスの導入 「必要な時だけ、必要な権限だけを付与する」JITアクセスは、Privileged Identity Management（PIM）で実装できる。常時付与した特権アカウントは、使われていない時間帯も攻撃・悪用の窓口になる。 委託業者・外部パートナーのアクセス管理 社員に比べて委託業者のアクセス管理は甘くなりがちだ。外部パートナー向けのゲストアカウント管理ポリシーや条件付きアクセス（Conditional Access）の適用範囲を改めて確認することを勧める。 クリティカルな操作には追加承認を データベースの削除・初期化といった「後戻りできない操作」には、追加認証や管理者承認をトリガーする仕組みを設けることで、単一アカウントの侵害が即座に壊滅的な被害につながるリスクを下げられる。 筆者の見解 この事件を「アメリカの話」として消費するのはもったいない。構造的な問題——前科者の再雇用、アクセス権の即時剥奪失敗、過剰な常時権限——は、日本のIT環境でも当たり前のように存在している。 特に委託業者が深く関与している大手企業・官公庁のシステムでは、「委託先のアカウントが今どんな権限を持っているか」を即座に答えられる体制が整っていないケースは少なくないはずだ。 JITアクセスやIAM自動化は「理想論」ではなく、今日のクラウド環境であれば現実的に実装できる。「解雇した瞬間に全権限が失効する」仕組みを作ることは、技術的にはそれほど難しくない。難しいのは、そこに優先度を割く意思決定だ。 「今動いているから大丈夫」は通用しない——そう教えてくれる事件が、また一つ記録された。 出典: この記事は Former govt contractor convicted for wiping dozens of federal databases の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Androidバンキングマルウェア「TrickMo」の新亜種が、通信の隠蔽手段としてブロックチェーン技術を採用したことが、セキュリティ企業ThreatFabricの調査で明らかになった。これまでのマルウェア対策の定石だった「悪性ドメインを遮断する」手法が、ほぼ効力を失いかねない構造的な変化だ。 TONブロックチェーンをC2に使うとどういう意味か 今回注目されているのは、攻撃者との通信に「TON（The Open Network）」を使っている点だ。TONはTelegramを起源とする分散型P2Pネットワークで、通常のDNSを使わずに暗号化されたオーバーレイネットワーク上で通信を行う。 従来のマルウェアはドメイン名やIPアドレスを使ってC2（コマンド＆コントロール）サーバーと通信するため、悪性ドメインをブロックすれば通信を遮断できた。しかしTONを経由する場合、エンドポイントは256ビット識別子（.ADNL アドレス）となり、公開DNSを経由しない。ネットワーク端でキャプチャされるのは「TONの通信」だけで、正規のTON対応アプリと外見上まったく区別できない。 ThreatFabricは「従来のドメインテイクダウンは大部分が無効化される」と明言している。これはマルウェア対策において重大なパラダイムシフトを意味する。 Trickmo.Cの具体的な機能 この最新亜種はTikTokやストリーミングアプリを装い、フランス・イタリア・オーストリアのユーザーを主な標的としている。基本的な機能は従来通りで、フィッシングオーバーレイによる認証情報窃取、キーロギング、画面録画・ライブ配信、SMS傍受、OTP通知の抑制などが含まれる。 加えて今回の亜種では以下のコマンドが追加されている： ネットワーク診断系：curl、dnsLookup、ping、telnet、traceroute トンネリング・プロキシ系：SSHトンネリング、リモート／ローカルポートフォワーディング、認証付きSOCKS5プロキシ SSHトンネリングとSOCKS5プロキシの組み合わせは、感染端末を「踏み台」として内部ネットワークへ侵入する経路として機能しうる。企業端末が感染した場合のリスクは個人端末の比ではない。 またNFCパーミッションを大量に宣言しているが、現時点では実際のNFC機能は未実装とのこと。将来のアップデートで非接触決済の傍受・リレー攻撃に発展する可能性を視野に入れておく必要がある。 実務への影響：日本のエンジニア・IT管理者にとっての意味 エンドユーザー向けの基本対策は従来通りだ。Google Playからのみアプリをインストールし、Google Play Protectを常時有効にし、TikTokを装った非公式APKなどに引っかからないこと。ただし「Google Play以外は入れない」をポリシーとして徹底している組織でも、今回のような亜種は公式ストアに潜り込んでくるケースもある。定期的な端末審査は欠かせない。 企業のMDM・MAM運用担当者は以下を見直してほしい： SOCKSプロキシやSSHクライアント機能を持つ不審アプリの検知ルールを追加する。ネットワーク診断ツールとしての顔を持つマルウェアは、既存のシグネチャで引っかからないことが多い 企業端末からTON関連トラフィックが出ていないかをネットワーク監視で確認する。正規のTONアプリを業務用途で使う理由が思い当たらなければ、トラフィック自体を制限する判断も合理的だ フィッシングオーバーレイ対策として、銀行・証券・仮想通貨取引所アプリは承認済みリストを作り、それ以外のアプリからのオーバーレイ表示をOS設定でブロックする（Android 12以降はアクセシビリティ機能の制限が可能） SSH・ポートフォワーディングが内部ネットワークへの侵入経路になりうることを念頭に、モバイル端末からの内部ネットワークアクセスをゼロトラストで制御できているか確認する 筆者の見解 正直に言えば、このニュースの「技術的な面白さ」と「やっかいさ」は同居している。 TONを悪用したC2は、ブロックチェーンの分散性と匿名性をそのまま兵器化した形だ。「ドメインを押さえれば終わり」という時代の終わりを象徴している。今後、同様の手口はTONに限らず他の分散型ネットワークにも波及するだろう。すでにIPFS（InterPlanetary File System）を使ったマルウェア配布は観測されており、分散インフラの悪用はトレンドとして定着しつつある。 ここで改めて強調したいのが、ネットワーク境界での遮断に依存したセキュリティモデルの限界だ。「このドメインは悪い、これはホワイトリスト」という運用では、暗号化された分散トラフィックには太刀打ちできない。認証・認可・端末状態を組み合わせた多層防御、そして「デバイスを一切信頼しない」前提に立った構成が、改めて現実解として浮かび上がってくる。 Androidバンキングマルウェアという文脈でありながら、その含意はモバイルセキュリティを超えて企業全体のアーキテクチャ設計に及ぶ。踏み台・SOCKSプロキシ・内部ポートフォワーディングの組み合わせは、「感染したスマートフォンが社内ネットワークへの侵入口になる」シナリオを現実のものにする。モバイルを「外のもの」として軽く見ている企業には、ちょうどいい警鐘になるはずだ。 出典: この記事は TrickMo Android banker adopts TON blockchain for covert comms の内容をもとに、筆者の見解を加えて独自に執筆したものです。

PS3エミュレータとして世界的に知られるオープンソースプロジェクト「RPCS3」が、プルリクエスト（PR）への自律型AIエージェントの使用を禁止したと発表した。開発チームのメッセージは「learn to code（コードを書け）」——挑発的とも取れるこの一言は、AIが生み出す低品質コード「AIスロップ」への強い拒絶感を表している。オープンソースの現場で何が起きているのかを読み解いてみたい。 何が問題になったのか——「AIスロップ」とは AIスロップ（AI Slop）とは、AIが生成したものの、コンテキストの理解が浅く、品質・一貫性・設計哲学などの観点でプロジェクトの基準を満たさない低品質なコードを指す俗語だ。 エミュレータ開発は、ゲームハードウェアの動作を正確に再現する高度な低レベルプログラミングを伴う。PS3のCell Broadband Engineアーキテクチャは特に複雑で、汎用的なAI生成コードが通用するほど単純ではない。RPCS3チームが受け取るPRの中に、明らかにAIが生成したと思われる、プロジェクトのアーキテクチャや設計哲学を無視したコードが混入し始めたことが今回の決断の背景にある。 重要なのは、今回の禁止が「AIツールの全否定」ではないという点だ。RPCS3チームが問題視しているのは「開示なしでの使用」——つまり、AIが書いたコードを自分のものとして黙って提出することへの異議申し立てだ。 なぜこれが重要か——OSSの「門番問題」 この動きが注目されるのは、RPCS3という一プロジェクトの問題にとどまらないからだ。 オープンソースプロジェクトは長年、PRレビューを通じてコード品質を保ってきた。しかし自律型AIエージェントがコントリビューターを「自動化」し始めると、メンテナの負担が急増する。量的な問題だけでなく、質の問題もある——ドメイン知識のないAI生成コードはレビュー工数を多く要するため、「スロップのレビューに時間を取られて本質的な開発が進まない」という逆説的な状況が生まれる。 日本のエンタープライズ開発においても、社内ライブラリや共通基盤をオープンソース的に運用しているチームでは、同様の課題が表面化しつつある。 実務への影響——エンジニアが明日から考えるべきこと 1. AI使用の開示をデフォルトに コードレビュープロセスにAI生成コードの開示を求めるポリシーを検討する時期に来ている。「このロジックはAI補助で生成しました」という開示があれば、レビュアーは適切なチェックポイントに集中でき、チーム全体の品質管理が効率化される。 2. AIコードの「受け取り方」を設計する 外部コントリビューションを受け入れているリポジトリでは、AIエージェントが送信してきたPRを検知・フィルタリングする仕組みの検討が必要になるかもしれない。GitHub ActionsやBot検出、コードパターン分析ツールが現実的な選択肢になる。 3. 「なぜそう書くのか」を説明できる人材を守る 「AIに任せれば書ける」は短期的には生産性を上げるが、プロジェクト固有の設計哲学の理解なしにコードを量産することは、長期的なリスクを積み上げる。AIを活用しながらも「なぜこう書くのか」を説明できる人材の育成が、今後のチーム運営の鍵になる。 筆者の見解 RPCS3の対応は、少なくとも誠実だと思う。高度に専門化されたドメインでは、汎用AIが生成したコードでは到底通用しない領域がある。その現実を「learn to code」という強いメッセージで示すことには、賛否はあれど一定の合理性がある。 ただ、「禁止」という手段が長期的に機能するかについては懐疑的だ。AIを使ったコードと使っていないコードの区別は技術的にますます困難になっており、禁止ルールを確実に執行する手段が限られる以上、いたちごっこになるだろう。 より持続可能なアプローチは、禁止よりも「使い方の基準を設けること」だと考える。「AIで書いたコードであっても、コントリビューター自身がその内容を理解し、説明できること」をコントリビューションの条件とする方が、現実的かつ建設的ではないか。 AIがコードを書く時代において、エンジニアに求められるのは「AIより速くタイプできること」ではない。AIが書いたコードを批判的に評価し、プロジェクトの文脈に適合させ、責任を持って届けられる能力——これが今後のコントリビューターに必要なスキルセットだ。 OSSコミュニティがこの問いに正面から向き合い始めたことは、業界全体にとって健全なシグナルだと受け止めている。 出典: この記事は RPCS3 says “learn to code” as it bans autonomous AI agents from project の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが、Outlookの主要な生産性機能のひとつに長期間にわたる不具合があったことを、ようやく公式に認めた。ユーザーや企業のIT管理者の間では数ヶ月前から問題が報告されていたにもかかわらず、公式なアナウンスは遅れに遅れた。技術的な不具合そのものより、「認知の遅さ」こそが今回の問題の核心だ。 何が起きていたのか Outlookはビジネスコミュニケーションの中核を担うアプリケーションだ。カレンダー・メール・タスク管理が統合されたこのツールは、日本企業の多くで「止まれないインフラ」として機能している。その中の「最も便利な機能のひとつ」が、数ヶ月間にわたって正常に動作していなかった。 現在Microsoftは「新しいOutlook（New Outlook / Project Monarch）」への移行を段階的に進めており、クラシックOutlookとの機能差・互換性の問題が断続的に報告されている。今回の不具合がその移行プロセスの中で生じたものであれば、企業のIT部門は移行タイミングを改めて慎重に検討する必要がある。 「公式認知の遅さ」が示す構造的課題 技術的な不具合はどのソフトウェアにも起こりうる。問題なのは、数ヶ月にわたって修正や公式コメントが出なかったという事実だ。 Microsoft 365のサービス正常性ダッシュボード（Service Health Dashboard）やMessage Centerは、こうした公式情報を確認する最重要チャンネルとして位置づけられている。しかし、問題が「非公式に壊れていた状態」のまま放置されると、ユーザーは自力で原因を特定しなければならない。これは日本のIT管理者にとって特に負担が重い状況だ。「Microsoftが認めていないから報告できない」「ベンダーに問い合わせても情報がない」という構図は、ヘルプデスクや情報システム部門の工数を静かに蝕み続ける。 実務への影響——IT管理者が今すぐ確認すべきこと 1. Microsoft 365 管理センターのサービス正常性を定期チェックする 既知の問題（Known Issues）セクションに今回の障害が掲載されているか確認する。テナント固有の問題と区別するためにも有用だ。 2. 新しいOutlookへの移行タイミングを再評価する 機能差・不具合情報を踏まえたうえで、クラシックOutlookの延命を選択肢として残しておくことも現実的な判断だ。「早期移行＝正義」とは限らない。 3. ユーザーからの不具合報告を記録・集約する仕組みを整える 「気のせい」で片付けずに記録を残す。件数が集まると問題の全体像が見え、ベンダーへの問い合わせやエスカレーションの根拠になる。 4. コミュニティ情報を公式情報と並行して監視する Microsoft Tech CommunityやNeowin、Reddit（r/sysadmin等）は公式発表より先に問題を捉えることが多い。アンテナを張っておく価値は高い。 筆者の見解 Outlookは「止まれないカテゴリ」のアプリケーションだ。数百万人の業務スケジュールが、このツールが正常に動いていることを前提に組まれている。その重要機能が数ヶ月間壊れたままで、公式情報が出なかったというのは、率直に言って「もったいない」の一言に尽きる。 Microsoftにはその問題を素早く認知し、透明性高く対処できる技術力も組織力もあるはずだ。「新しいOutlook」への統合アーキテクチャへの移行は、長期的に見れば正しい方向性だと思っている。Web技術ベースでのプラットフォーム統合は、保守コストの削減と機能展開の加速につながる。だからこそ、移行期間における品質管理と情報共有の精度を、もう一段引き上げてほしい。 今回の件を機に、問題把握から公式認知までのサイクルが短縮されることを期待したい。ユーザーが「公式発表を待たずに自衛するしかない」状態は、エコシステム全体の信頼コストを押し上げる。正面から勝負できる力がMicrosoftにはあるのだから、その力をプロダクト品質と情報透明性の向上に使い続けてほしいと思っている。 出典: この記事は Microsoft finally acknowledges one of the most useful Outlook features is broken の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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

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