Tech-News

「待ったなし」の近代化月間——2026年4月M365アップデート総まとめ 2026年4月のMicrosoft 365は、機能追加と同じくらい「廃止」が目立つ月だ。SharePointのクラシック機能群がいよいよ完全終了し、パスワードレス化の推進も管理者側に強い権限が与えられた。さらにAIがセキュリティ・コンプライアンス領域にも本格的に組み込まれてきた。Message Centerの通知を読み飛ばしていた担当者にとっては、今月こそ「後で読む」が許されない月になる。 廃止ラッシュ：SharePointレガシーとの決別 今月最大のインパクトは、SharePoint旧機能の一斉終了だ。 4月2日に完全終了した主な機能： SharePoint 2013ワークフロー — 延長なし、例外なし。Power Automateへの移行一択 SharePoint アドイン — 既存テナントも含め動作停止。Microsoft 365 Assessment Toolでスキャンし、SPFx（SharePoint Framework）への移行が必要 Azure ACS（Access Control Service） — ACS認証を使っているアプリはそのまま壊れる。Microsoft Entra IDへの移行が急務 ドメイン分離SPFx Webパーツ — 描画時にエラーが発生する。通常のSPFxへの変換が必要 さらに情報管理ポリシー・インプレースレコード管理・削除専用ポリシーも廃止済み。これらはMicrosoft Purview データライフサイクル管理＆レコード管理への移行が求められる。 Teams関連ではViva Engage ライブイベント（旧Teams Live Events）が4月15日で新規作成不可に。Teams Town Hallsへの切り替えが必要だ。 新機能ハイライト：アイデンティティとAIの前進 廃止の陰に隠れがちだが、新機能も充実している。 パスキー登録キャンペーン（Entra ID） これは注目度が高い。管理者が「パスキー登録キャンペーン」を起動することで、ユーザーにパスキー登録を促す（強制も可能）ようになった。これまでMicrosoft Authenticatorアプリへの誘導が中心だったが、パスキーへの直接誘導が選択できるようになった。Microsoftは条件が整ったテナントに対して自動切り替えを行う可能性も示唆している。 クロステナントIntune MAM（Edge） 外部委託先やパートナー企業の端末に対して、デバイス登録なしで企業データを保護できる。M&Aやアウトソーシングが多い日本の大企業環境で特に効いてくる機能だ。 Teams Phoneの複数電話番号対応（最大10番号/ユーザー） コンタクトセンターや複数拠点をまたぐ担当者、エグゼクティブ秘書業務への活用が想定される。 AI搭載DLPアラートサマリー（Defender XDR） Purview Triage AgentがDLPアラートを自動要約する機能が入った。大量のアラートに埋もれているSOCチームにとって、トリアージ工数の削減につながる可能性がある。 実務への影響：今月動かなければ本番障害になる SharePoint関連の廃止は「予告通り来た」ものだが、見落としているケースが驚くほど多い。特に気をつけたいのは以下の3点。 ACS認証の残存チェック — 古いカスタムアプリや外部ベンダー提供のアドインがACSを使っていることがある。Microsoft 365 Assessment Toolを今すぐ走らせ、残存リスクを可視化すること 2013ワークフローのPower Automateへの移行 — 「誰が作ったかわからない」古いワークフローが最も危険。IT部門だけでなく業務部門への確認も必要 パスキー展開の計画策定 — 管理者主導のパスキー登録が可能になった今、パスワードレス化のロードマップを持っていないテナントは遅れを取り始める 筆者の見解 ゼロトラスト推進の観点から言うと、今月のEntraパスキーキャンペーン機能は評価に値する。VPNや従来型パスワード認証の延命に腐心している国内企業が多い中、管理者が「プッシュ」できる仕組みは実際の展開加速に直結する。「ユーザーが自分で登録しない問題」を組織的に解決できるアプローチは、現場で長年詰まってきたボトルネックへの現実的な答えだ。 ...

SharePointを業務の中核に置いている組織にとって、2026年春は「静かな地雷原」になりつつある。レガシー認証方式であるIDCRL（Identity Claims-based authentication Runtime Library）が2026年5月1日をもって完全廃止される。すでにSharePoint Add-InとAzure ACSは4月2日に廃止済みであり、猶予期間は事実上ほぼ残っていない。 何が廃止されるのか 今回の廃止は三段階で構成されている。 第一弾（完了済み）: SharePoint Add-InおよびAzure ACS（Access Control Service）が2026年4月2日に廃止。古いアドイン型の連携ソリューションは、この時点でアクセスが停止している可能性がある。 第二弾（4月中）: 情報管理ポリシー（Information Management Policy）、インプレース・レコード管理（In-Place Records Management）などのコンプライアンス機能が順次廃止。これらはMicrosoft Purviewへの移行が必須となる。 第三弾（5月1日）: IDCRL認証自体が完全廃止。IDCRLはSharePoint Onlineに対してユーザー名とパスワードで認証するレガシーな仕組みで、古いPowerShellスクリプト、カスタムアプリ、サードパーティ連携ツールの多くがこれに依存している。 なぜ今これが重要か IDCRLの廃止が特に日本のIT現場に響く理由は、「動いているから問題ない」という思い込みで長年放置されてきたスクリプト群が多数存在するからだ。SharePoint Onlineと連携するPowerShellの自動化、社内ポータルからのドキュメント取得処理、外部ベンダーが数年前に納品したカスタムソリューション——これらのどこかにIDCRLが潜んでいないか、今すぐ棚卸しが必要だ。 セキュリティの観点からも、IDCRLはゼロトラスト・アーキテクチャとは相容れない旧世代の認証モデルだ。常時アクセス権の付与や単純なパスワード認証への依存は、現代のセキュリティ要件では許容できない。廃止は「終わり」ではなく、正しい方向への押し出しと捉えるべきだろう。 移行先と対処方法 認証まわりの移行 IDCRLに依存している連携処理は、Entra ID（Azure AD）のOAuth 2.0 / OpenID Connectベースの認証に切り替える必要がある。具体的には以下のいずれかを選択する。 PnP PowerShell: Connect-PnPOnline でEntra IDアプリ登録を使ったモダン認証に対応している。古いSPO管理シェルでユーザー名・パスワードを直打ちしているスクリプトは全滅と考えてよい Microsoft Graph API: SharePointのデータにアクセスするなら、今後はGraph APIが標準経路。アプリケーション権限（クライアントクレデンシャル）またはデリゲート権限（ユーザー代理）のどちらを使うか、要件に合わせて設計する SharePoint REST API / CSOM: モダン認証トークン（Bearer Token）と組み合わせれば引き続き使用可能 コンプライアンス機能の移行 In-Place Records ManagementやInformation Management Policyを使っていた場合は、Microsoft Purviewのレコード管理に移行する。保持ラベル（Retention Labels）と保持ポリシー（Retention Policies）を使うことで、より細かい制御と監査ログが得られる。 実務への影響と確認ポイント 移行対応の優先度を決めるために、以下を今週中に確認してほしい。 Entra IDのサインインログを確認: KindOfTokenUsed = Legacy や ClientAppUsed = IDCRL でフィルタリングすると、まだIDCRL認証を使っているアプリが特定できる PowerShellスクリプトの棚卸し: -Credential パラメーターでユーザー名・パスワードを直接渡しているスクリプトは要注意 サードパーティ製品のバージョン確認: SharePoint連携を持つ製品（DMS、ワークフローツール等）のベンダーにモダン認証対応状況を確認する Azure ACS連携の確認: 4月2日廃止分が既に影響していないか、実際に動作確認を行う 筆者の見解 IDCRL廃止は、正直「なぜ今まで残っていたのか」と思うくらい遅すぎた決断だ。OAuth/OIDCが業界標準になって久しい中で、レガシー認証の延命措置が長年続いてきた。 ...

外部AIがMicrosoft 365のデータに直接アクセスできる時代が、静かに始まっている。Anthropicは2026年4月、同社のAIアシスタント「Claude」向けのMicrosoft 365コネクターを、無料プランを含む全ユーザーに開放した。SharePoint、OneDrive、Outlook、Teamsのデータを自然言語で横断検索できる——これが何を意味するか、M365管理者の視点で丁寧に読み解いていく。 MCPサーバーという選択肢 今回のコネクターは、近年急速に普及しつつあるMCP（Model Context Protocol）を採用している。MCPはAIモデルが外部ツールやデータソースと連携するための標準的なプロトコルであり、AnthropicはこれをMicrosoft Graph APIへのブリッジとして活用した。 インストールすると、Entra ID上に2つのエンタープライズアプリが登録される。 M365 MCP Server for Claude（アプリID: 07c030f6-5743-41b7-ba00-0a6e85f37c17） M365 MCP Client for Claude（アプリID: 08ad6f98-a4f8-4635-bb8d-f1a3044760f0） サーバーアプリがGraph APIへの各種権限を持ち、クライアントアプリがサーバーアプリに対してaccess_as_userカスタム権限を通じて認証を担う構造だ。ClaudeはMCPクライアントとして動作し、サーバーが公開するツール（SharePoint検索、Teamsチャット読み取りなど）を呼び出す形になる。 権限の実態——「委任」であることの意味 パーミッションの一覧を見た瞬間、セキュリティ担当者は目を疑うかもしれない。Sites.Read.All、Mail.Read、Chat.Read……かなり広い範囲に見える。 しかし重要なのは、これらがアプリケーション権限ではなく委任権限（Delegated Permissions）である点だ。つまり、Claudeがアクセスできるのは「サインインしているユーザーが本来アクセスできる範囲」に限定される。Claudeが独自に他ユーザーのデータを閲覧したり、管理者権限で全社データを参照したりすることはできない。 また、アクセスは読み取り専用だ。Claudeはドキュメントの作成・編集・削除はできない。これは重要な制約であり、万一の場合のリスクを大幅に限定している。 加えて、特定の権限はコネクターの管理画面から無効化することも可能だ（その機能は使えなくなるが）。テナント管理者がリスク評価に応じて絞り込める余地がある点は評価に値する。 RCD（コンテンツ探索制限）との相性 実際の動作で興味深い挙動が報告されている。Microsoft 365 Copilotのインデックスから除外するために設定されたRCD（Restricted Content Discovery）が、Claudeの検索結果にも同様に作用したというのだ。 これはSharePoint Searchに依存しているからこその挙動であり、「CopilotのアクセスをRCDで制限したから安全」と考えていた運用担当者にとっては朗報だ。ただし逆に言えば、RCDを設定していないサイトのデータは外部AIにも到達しうることを意味する。既存のアクセス制御が正しく機能しているかを改めて点検する良い機会でもある。 実務での活用ポイント テナント管理者がまず確認すべきこと Entra IDのエンタープライズアプリ一覧を確認する: ユーザーが勝手にインストールしていないか定期的にチェックする仕組みを設けること。アプリIDは上記の通り公開されている。 ユーザーによるアプリ同意を制限しているか確認する: テナントの「ユーザー同意設定」が「管理者承認なしで同意可能」になっている場合、知らぬ間に広まる可能性がある。 RCDの設定状況を棚卸しする: 機密情報を含むサイトに適切なアクセス制御が設定されているか確認する。 積極活用を検討したいシーン 社内のSharePointに散在するドキュメントを横断的に検索・整理したい場合 Teamsの過去のチャット履歴や会議記録を自然言語で振り返りたい場合 Outlookのメール情報を元に定型的な作業（返信下書き、情報集約など）を補助したい場合 高度な分析や創造タスクに外部AIを活用し、日常的な議事録整理や定型業務にはCopilotを使うという「使い分け」の文脈で、このコネクターは一つの現実解になりうる。 筆者の見解 このコネクターの登場は、M365管理者にとって「そのうち来るとは思っていたが」という出来事だろう。OpenAIがChatGPT向けにM365連携を展開し、それに続く形で複数のAIサービスがMicrosoft 365のデータに触手を伸ばす——これは今後の標準的な流れになっていくはずだ。 個人的に注目しているのは、MCP（Model Context Protocol）という標準が着実に普及しつつある点だ。特定のベンダーに依存しない標準プロトコルを通じた連携が増えることは、長期的にはエコシステム全体の健全な発展につながる。 Microsoft側から見ると、これは複雑な局面でもある。M365という強力なデータプラットフォームを他社AIが活用しやすくなる一方、Copilot自身の価値をどう示していくかが問われる。Microsoftはプラットフォームとしての優位性を活かしながら、その上で動くAIの質でも正面から競争できるポジションにある。その実力を存分に発揮してほしい、というのが正直なところだ。 セキュリティの観点では、委任権限・読み取り専用・RCD対応という三つの制約が「最低限の安全網」として機能していることは確認できた。ただし「現在動いているから大丈夫」という判断は危険だ。Entra IDのアプリ管理やユーザー同意ポリシーの見直しを、この機会に必ず行うことを強くお勧めしたい。 外部AIがM365データに接続できる時代において、「禁止」を選ぶ組織は必ず抜け道を使われる。公式の管理された経路で安全に使える仕組みを整える——それがこれからのIT管理者に求められるスタンスだ。 出典: この記事は Using the Microsoft 365 Connector for Claude の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

MicrosoftがWindows 11/10およびOfficeにおける「インターネット接続なしで行える公式ライセンス認証手段」を廃止した。同社はその理由を公式に説明しており、長年にわたり運用されてきたこの仕組みがついに幕を閉じた形だ。オンプレミス中心の環境が多い日本企業にとって、見過ごせない変更である。 何が廃止されたのか Microsoftが廃止したのは、従来「電話認証（Telephone Activation / SLUI 4）」と呼ばれてきた仕組みだ。これはインターネットに接続せずとも、表示されたコードを電話でオペレーターまたは自動応答システムに伝えることで認証を完了できる方法で、Windows Vista時代から存在していた。 オフライン環境や、ネットワーク制限の厳しい環境でWindowsやOfficeを正規に認証するうえで、IT管理者の間では長く重宝されてきた手段だった。 Microsoftの説明によれば、廃止の主な理由は以下の2点に集約される： セキュリティおよび不正利用の防止: 電話認証の仕組みは、ライセンスキーの悪用・転売・不正認証のベクターとして長年利用されてきた。自動応答システムを使った大量認証など、海賊版流通に加担するルートとなっていた実態がある サポートコストの削減: 電話認証に必要なインフラ・オペレーター運用のコストが、実際の正規利用件数に見合わなくなっていた 企業IT管理者が知っておくべきこと この変更によって直接影響を受けるのは、主に以下のシナリオだ： 影響を受けやすい環境： インターネットから切り離されたエアギャップ環境（製造ライン制御・医療機器・セキュリティ機密環境など） ネットワーク制限が厳しく、KMSやMAKによるオンライン認証が困難な拠点 ライセンス管理を手動で行っているオンプレミス中心の組織 代替手段として有効なもの： KMS（Key Management Service）: 社内KMSサーバーを経由した認証。エアギャップ環境でも閉じたネットワーク内で完結できる VAMT（Volume Activation Management Tool）: Microsoftが提供するオフライン対応のボリュームライセンス管理ツール。インターネット接続を持つ別マシンを経由してプロキシ認証が可能 Windows Autopilot + MAK: クラウド管理前提の環境ではMAK（Multiple Activation Key）との組み合わせが現実的 重要なのは、「インターネット不要」のオプションが完全になくなったわけではない点だ。KMSやVAMTは引き続き機能する。電話認証という「最後の砦」がなくなったということであり、設計段階からライセンス認証フローを組み込んでおく重要性がより高まった。 実務での活用ポイント 現在の環境棚卸しを今すぐ: 電話認証に依存しているシステムやプロセスがないか確認する。特に定期的な再認証が発生する環境は要注意 KMSサーバーの有無を確認: ボリュームライセンス契約があればKMSが使える可能性が高い。IT部門内で横断的に棚卸しする機会とすべき VAMTの導入検討: エアギャップ環境が複数ある組織では、VAMTによる一元管理が長期的にも運用コストを下げる ライセンス更新タイミングを活用: 次回のボリュームライセンス更新や契約見直し時に、クラウドベースのライセンス管理（Microsoft 365など）への移行を評価する 筆者の見解 電話認証という仕組みは、率直に言って時代の終わりを迎えるべき技術だった。インフラコストと不正利用リスクの両面から、廃止の判断そのものは理にかなっている。 ただ、引っかかるのは「廃止のタイミングと周知の不足」だ。エアギャップ環境を持つ製造業・医療・金融・官公庁といった業種では、インターネット接続前提の設計変更は一朝一夕では進まない。「廃止した、代替手段はKMSとVAMTです」という説明だけでは、現場の実態にそぐわないケースが出てくる。 Microsoftにはこうした移行が難しい組織に対して、KMS/VAMTの導入支援や移行ガイドをもっと前面に出してほしかった。廃止の意図は正しい。ならば、代替手段への誘導にも同じくらいのエネルギーをかけるべきだ。 日本のエンタープライズIT環境においては、「動いているから問題なし」で来た認証まわりの設計が今回の廃止で初めて問い直される組織も出てくるだろう。これを機に、ライセンス管理の仕組みを一度きちんと整理することを強くお勧めする。「対応するのは問題が起きてから」では遅い変更がここに来た、と受け止めてほしい。 出典: この記事は Microsoft explains why it killed official way to activate Windows 11/10 without internet の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Azure OpenAI（Microsoft Foundry）において、GPT-4.1・GPT-4.1 mini・GPT-4.1 nanoファミリーの廃止（Retirement）プロセスが2026年4月11日より正式に開始された。これはMicrosoftが継続的に進めているモデル世代更新の一環であり、既存のデプロイメントを持つ企業・開発者にとっては実運用への影響を無視できないニュースだ。 モデル廃止・退役のポリシーを正確に理解する Azure OpenAIでは、モデルのライフサイクルに関して明確なポリシーが設けられている。まず押さえておくべき用語の違いがある。 Deprecation（廃止）: 新規顧客への提供が停止される。既存デプロイメントは引き続き利用可能。 Retirement（退役）: 全顧客に対してモデルが利用不可となり、呼び出しはエラーを返す。 一般提供（GA）モデルの場合、リリースから最低12ヶ月は利用可能であり、その後も既存ユーザーは6ヶ月の猶予期間が与えられる。新規ユーザーは12ヶ月経過後にアクセスできなくなる。また退役の少なくとも60日前には通知が送られる仕様だ。 プレビューモデルについては退役まで90〜120日の猶予が基本となり、バージョンアップグレードの30日前には通知が届く。 通知の受け取り方——見逃さないための設定 Microsoftはモデル退役の通知を2つのチャネルで提供している。 Azure Resource Health経由: Readerロール以上の権限を持つユーザーが閲覧可能。メールやSMSによる個別アラート設定もできる。「Azure Service Health」フィルターで「azure OpenAI service」を選択し、イベントタイプに「Health advisories（Upgrade / Deprecation / Retirement通知）」を追加するのが基本設定だ。SMSアラートを希望する場合は「Create action group」からアクション設定を追加する。 メール通知: サブスクリプションオーナーには自動送信されるが、個別にアラートを設定すればReader権限でも受信できる。 重要なのは、退役はリージョンごとにローリング方式で実施される点だ。特定リージョンやSKUがいつアップグレードされるかの固定スケジュールは存在せず、一部リージョンでは容量の都合でN+1モデルではなくN+Xへ直接移行されるケースもある。 実務への影響——日本のエンジニア・IT管理者が今すぐやるべきこと 今回の廃止開始を受けて、現在Azure OpenAI（Microsoft Foundry）を本番利用している組織では以下を速やかに確認したい。 デプロイメント一覧の棚卸し: Azure PortalまたはAzure CLIで現在稼働中のGPT-4.1系デプロイメントを全リージョン分洗い出す。 Service Healthアラートの設定: まだ設定していない担当者は今日中に設定すること。通知を見逃したまま退役日を迎えるとエラーが発生し、ユーザー影響が出る。 後継モデルの評価: GPT-4.1の後継として提供されるモデルのパフォーマンス・コストを自社ユースケースで検証する。Microsoftは新GAモデルについて、次世代モデル（N+1）と並行して少なくとも60日間テストできる環境を提供している。 自動移行 vs 手動移行の判断: デプロイメントによっては自動アップグレードが走るケースもある。プロンプトや出力の変化が許容できないアプリケーションでは、手動でのバージョン固定管理を意識的に行う必要がある。 リージョンによって移行タイミングがずれる点も要注意だ。Japan EastとJapan Westで状況が異なる可能性があるため、マルチリージョン構成を持つ場合は特に注意が必要となる。 筆者の見解 Microsoftがモデルライフサイクル管理のポリシーを体系化し、60日前通知・Resource Health連携・メールアラートという多層的な仕組みを整備している点は、エンタープライズ利用の観点から正しい判断だと思う。「いつ使えなくなるかわからない」状態で本番システムにAIを組み込むのは怖くてできない、という声は日本企業でも多い。その不安に応えるガバナンス基盤として、Foundryプラットフォームは着実に成熟してきている。 ただ一方で、AIモデルの進化速度が従来のSaaSサービスとは桁違いに速い現実もある。12ヶ月サイクルで世代交代が続く環境では、「安定したモデルに依存した実装」というアプローチ自体を見直す必要があるかもしれない。特定のモデルバージョンに最適化したプロンプトやフローが、次世代モデルでは動作が変わるリスクを織り込んだ設計——つまりモデル非依存の抽象化層を持つアーキテクチャ——が、これからのAIシステム設計の標準になっていくだろう。 Azureという基盤の上でどのモデルを使うかを柔軟に選べること、それがMicrosoft Foundryの本質的な価値だと筆者は捉えている。プラットフォームとしての信頼性を保ちつつ、AI層の選択肢を広げていく方向性は長期的に正しい。モデル廃止の通知を受け取ったとき、それを「障害対応」ではなく「アーキテクチャを見直す好機」と捉えられるチームが、AIネイティブな開発文化を先行して作っていくことになるはずだ。 出典: この記事は GPT-4.1 Family Retirement Begins in Azure OpenAI - April 11, 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

WireGuard、VeraCrypt、MemTest86、Windscribeといった、Windowsユーザーにとって欠かせないオープンソースツールが、突然Windows向け更新の配信を停止せざるを得ない状況に追い込まれた。原因はMicrosoftのWindows Hardware Programにおけるアカウント停止——しかも、開発者には事前通知がなかったという。 何が起きたのか VeraCryptの開発者Mounir Idrassiは、数年来使用していたWindowsドライバーおよびブートローダーの署名用アカウントが突然停止されたと報告した。メールも事前警告も一切なく、復活させる方法も示されなかったという。WireGuardのメンテナJason A. Donenfeld、Windscribeのチーム、MemTest86の開発者も同様の経験を共有し、週単位でMicrosoftサポートへの連絡を試みたものの、自動応答とボットのみが返ってきた、と口をそろえた。 Donenfeld氏は「もしWireGuardにクリティカルなRCE脆弱性が発見され、即座にユーザーへ更新を届ける必要がある状況だったらどうなっていたのか」と述べ、そのリスクの深刻さを指摘した。 Microsoftの説明 事態がTechCrunchに報道された後、MicrosoftのVP Scott HanselmanがSNSに登場し、停止の理由を明かした。「2024年4月以降にアカウント確認を完了していないパートナー全員に対して、2025年10月から確認を促すメールを送り続けていた。手続きを完了しなかったアカウントは自動停止となった」という説明だった。 公式ドキュメントによると、確認手続きは2025年10月16日に開始され、30日以内に完了しなければ自動停止となる仕組みだった。そして2026年3月30日時点で、未完了アカウントの停止が実行された。 MicrosoftのEVP Pavan Davuluri氏も「メール・バナー・リマインダーでパートナーへの周知に努めた。それでも見落としが起きることはある。今回をコミュニケーション改善の機会にしたい」とコメントした。Hanselmanが直接連絡を取り、各プロジェクトのアカウントは順次回復の方向に向かっているとのことだ。 実務への影響 今回の騒動は、OSSメンテナに限らずすべてのWindows Hardware Program参加者にとって示唆に富む。 確認すべき事項： Windows Hardware Program（旧称: Windows Dev Center / Partner Center）のアカウントステータスを即座に確認する パートナーセンターに登録している連絡先メールアドレスが、現在も受信・確認できる状態になっているかを検証する ドライバー署名やハードウェア認定を行っている組織では、アカウント管理を特定個人に属人化させず、複数担当者でモニタリングする体制を整える セキュリティ観点のリスク： Windowsのカーネルドライバーは署名が必須。セキュリティパッチを配信できない状態は、そのソフトウェアの既知脆弱性が放置されることを意味する。VPN・暗号化・RAM診断ツールといった、まさにセキュリティインフラに位置するソフトウェアが影響を受けた点は、事態の重みを物語っている。 筆者の見解 Microsoftが「通知はした」と説明する一方、WireGuardやVeraCryptといった第一線のOSSメンテナが一様に「知らなかった」と証言する。このギャップは、単なるコミュニケーション不足というよりも、通知設計そのものの問題だと見るべきだろう。 OSSメンテナはボランティアベースで動いていることが多く、企業の調達担当者のようにポータルを日常的に監視するわけではない。「メール・バナー・リマインダーを送った」という事実が、「届いた」「理解された」「行動できた」を意味しないことは、UXの基本中の基本だ。 Microsoftにはこの問題を正面から勝負できる力がある。Partner Centerのインフラ、通知システム、有人サポートへのエスカレーションパス——どれも整備できるはずだ。今回のように「SNSが炎上してようやく人間が出てきた」という構図は、もったいない。ガバナンスへの信頼を自らすり減らすことになる。 セキュリティ上の理由からドライバー署名の厳格化を進めること自体は正しい方向だ。ただ、その手続きが厳格になればなるほど、移行の設計も同じ水準で丁寧でなければならない。今回の件が、そのバランスを見直す契機になることを期待したい。 社会インフラに近いOSSプロジェクトのアップデートが、プラットフォームの手続き不備によって止まるリスクは、OSSコミュニティ全体の課題でもある。自分が利用・依存しているツールのサプライチェーンが、今日もちゃんと機能しているかを意識するきっかけにしてほしい。 出典: この記事は Microsoft suspends dev accounts for high-profile open source projects の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ハードウェアのスペック確認やシステム監視に欠かせないツールとして、エンジニアやPC愛好家から長年支持されてきた「CPU-Z」「HWMonitor」。その開発元であるCPUID（フランスのソフトウェア会社）の公式サイトが一時的に侵害され、悪意ある実行ファイルが配布されていたことが明らかになった。4月9日から10日にかけて約6時間にわたって発生したこの事件は、「公式サイトからダウンロードすれば安全」という前提が成立しない時代を改めて突きつけるものだ。 何が起きたのか 攻撃者はCPUIDが利用していたサイドAPIに不正アクセスし、CPU-ZおよびHWMonitorのダウンロードリンクをCloudflare R2ストレージ上にホストされた悪意あるファイルへとすり替えた。ダウンロードされた偽ファイルは「HWiNFO_Monitor_Setup」という名前で、実行するとロシア語インターフェースのInno Setupラッパーが起動する仕組みになっていた。 注目すべきはそのマルウェアの高度さだ。マルウェア研究者vxundergroundの分析によると、このマルウェアは以下の特徴を持つ。 多段階（マルチステージ）構造：一度の実行で完結せず、段階的に悪意ある処理を展開する メモリ内動作中心：ディスクへの書き込みを最小限に抑え、フォレンジック調査を困難にする .NETアセンブリ経由のNTDLLプロキシ：カーネルAPIの呼び出しを迂回することでEDR（エンドポイント検出・対応）やウイルス対策ソフトの検知を回避 情報窃取型マルウェア（インフォスティーラー）の疑い VirusTotalでは20のエンジンがこのZIPを検知しているが、明確な識別はできていない。「Tedy Trojan」「Artemis Trojan」と分類するエンジンが混在しており、新種または亜種である可能性を示唆している。 また、同じ脅威グループが先月にはFTP定番ツールのFileZillaユーザーを標的にしていたという報告もある。「広く使われているユーティリティ」を狙うパターンが見え隠れしており、組織的な活動の可能性がある。 なぜこれが重要か この事件が示す本質的なリスクはサプライチェーン攻撃の巧妙さだ。 通常のマルウェア配布と異なり、今回の手口は「公式サイトのURLを踏んだ」「ブラウザのアドレスバーにはcpuid.comと表示されていた」という状況でも被害を受けるというものだ。ダウンロード先URLが動的に書き換えられているため、URLだけを確認する行為には意味がない。 日本のIT現場でも、社内PCのスペック確認やサーバーのハードウェア診断にCPU-ZやHWMonitorを利用しているケースは少なくない。特にIT管理者が展開用にあらかじめダウンロードしたインストーラを社内サーバーに置いている運用では、今回のように「オリジナルのバイナリは無事」であっても侵害されたリンク経由でダウンロードしていれば被害を受けた可能性がある。 実務での活用ポイント 今すぐ確認すべきこと： 4月9日〜10日の間にCPUID製ツールをダウンロードした場合は即座に調査を。ダウンロードしたファイルのハッシュ値を公式が提供する正規のものと突き合わせる。VirusTotalにアップロードして確認するのも有効だ。 ダウンロードインストーラのハッシュ検証を日常化する。公式サイトがSHA-256ハッシュを公開していれば、Get-FileHash（PowerShell）やsha256sum（Linux/Mac）で必ず確認する習慣をつけたい。 エンドポイントのEDR/AV検知ログを遡及確認する。メモリ内動作中心のマルウェアはディスク上の痕跡が薄い。「何かおかしな挙動があったが気づかなかった」ケースがある可能性を念頭に置く。 ソフトウェア配布を社内で一元管理する。Microsoft Intune等を用いてアプリ配布を管理しているならば、「個人が勝手にダウンロードして実行する」行為を制限する構成の有効性を改めて見直すべきだ。禁止一辺倒ではなく、社内承認済みのパッケージ配布基盤を整えることが現実解になる。 筆者の見解 セキュリティの話題は苦手な分野なのだが（細かい話が多すぎるから）、今回の件は技術的な観点から非常に興味深い。 サプライチェーン攻撃は、「正規ルートを通ったから安全」という人間の心理的盲点を正面から突いてくる。今回のCPUID侵害は約6時間で修正されたが、その6時間の間に何人がダウンロードしたかは誰にもわからない。しかも攻撃者の主開発者が休暇中のタイミングを狙ったという点に、組織の隙間を研究していることが透けて見える。 「今動いているから大丈夫」は通用しない——これはSID重複の問題でも繰り返し言ってきた話だが、サプライチェーン攻撃においてはより深刻だ。侵害された入口が「信頼していた場所」なのだから、検知が遅れるのは当然の帰結になってしまう。 ゼロトラストの文脈で言えば、「ダウンロード元のドメインを信頼する」という前提自体を捨てる必要がある。ダウンロードしたファイルのハッシュ検証、EDRによる実行時の振る舞い監視、そして最小権限の原則——これらはこうした高度な攻撃に対して今も有効な3層の防壁だ。 無名のツールではなく、長年多くのエンジニアが使ってきた「信頼されたツール」が標的になったという事実は、改めてすべてのダウンロード行為への注意喚起として受け取ってほしい。 出典: この記事は CPUID hacked to deliver malware via CPU-Z, HWMonitor downloads の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「入室してから気づく」あの地獄、ようやく終わるか Microsoft Teamsに、会議に参加する前にカメラや音声設定を確認できる「入室前プレビュー機能」が追加されることが明らかになった。ZoomやGoogle Meetにはとっくに備わっている機能であり、Teams利用者からは長らく「なぜないのか」と指摘されてきた部分だ。ようやく、Teamsにも当たり前の体験が届こうとしている。 何が変わるのか これまでのTeamsでは、会議リンクをクリックすると即座に参加処理が走り、マイクがミュートになっていなかったり、背景が意図したものと違ったりしても、入室後に気づくしかなかった。特にリモートワーク環境では、自宅の生活音が会議に流れ込んでしまうケースも頻発していた。 今回追加される入室前プレビュー画面では、参加ボタンを押す前に以下の確認ができるようになる。 カメラのオン／オフと映り方の確認 マイクの入力レベルと選択デバイスの確認 背景ぼかし・仮想背景の事前設定 ミュート状態での参加オプション これはZoomが「プレビュー画面」として長年提供してきた体験と基本的に同等のものだ。 なぜこれが重要か ビジネスコミュニケーションツールとして世界中の企業が依存しているTeamsに、この機能が「今まで存在しなかった」という事実は、日本のエンタープライズ現場でも相当な数の「入室即マイクオン事故」を生んできたはずだ。 IT部門の視点から見ると、この機能追加はヘルプデスクへの問い合わせ削減にも直結する。「会議に入ったら自分の声が出ていなかった」「顔が映っていなかった」という初歩的なトラブルは、入室前確認で8割以上は防げる。 また、会議の冒頭で起きる「音が出ない」「映像が映らない」といったトラブルは、参加者全員の時間を奪う。日本の会議文化では特に、最初の数分のトラブルが会議全体の雰囲気に影響することも少なくない。 実務での活用ポイント エンジニア・一般ユーザー向け 入室前画面でマイクの入力レベルを必ず確認する習慣をつける。特に外部スピーカーやBluetooth機器を使っている場合、デバイス切り替えが反映されていないケースが多い 仮想背景を使っている場合、プレビュー画面で実際の背景がどう見えるか事前チェックを怠らない IT管理者向け Teamsポリシーで「ミュート参加をデフォルト」に設定している組織は、この機能追加に伴いユーザー教育の機会にすると良い 入室前画面の活用をオンボーディング資料に組み込み、会議トラブルの自己解決率を上げる施策として使える 筆者の見解 正直に言えば、この機能は「追加」ではなく「ようやく追いついた」と表現するのが正確だ。ZoomもGoogle Meetも、入室前の確認画面は数年前から標準装備していた。Teamsがこれを今のタイミングで追加するというのは、それだけ優先度が後回しになっていたということでもある。 Teamsはエンタープライズ機能の充実度という点では他ツールを圧倒している面も多い。セキュリティ、ガバナンス、Microsoft 365との統合の深さは、競合ツールにはなかなか真似できないレベルだ。だからこそ、こうした「使い始める瞬間」の体験が後回しにされてきたのは、もったいないと感じる。 高度な機能を積み上げる一方で、ユーザーが最初に触れる「参加する」という体験が洗練されていなければ、印象はどうしても損なわれる。Teamsが持つポテンシャルを考えれば、こういった部分こそ先行して磨き込んでほしかった。 とはいえ、今回の対応は評価に値する。地味に見えて、日々の会議を使っているすべてのユーザーに届く改善だ。今後も「使い始め」の体験をきちんと磨いていくことを期待したい。 出典: この記事は Microsoft Teams is getting a crucial feature that has been surprisingly missing so far の内容をもとに、筆者の見解を加えて独自に執筆したものです。

アリババが2026年4月10日に公開したテキスト→動画生成AIモデル「Happy Horse」が、公開直後にグローバルなランキングでトップに浮上した。日本語メディアではほぼ報じられていないが、動画生成AI領域の勢力図を語るうえで無視できない動きだ。 Happy Horseとは何か 「Happy Horse」はアリババ傘下の研究部門が開発したテキスト→動画（Text-to-Video）生成モデルで、自然言語のプロンプトから高品質な動画クリップを生成する。公開と同時にいくつかの著名なグローバルベンチマークの首位を獲得したと発表されており、その評価速度は「競合を寄せつけない」という表現が大げさでない印象を与えている。 動画生成AIはここ1〜2年で急速に発展した分野だ。テキスト→画像が「静止画を一瞬で作る」技術として定着しつつある一方、テキスト→動画は生成のコスト・時間・品質のバランスがまだ難しく、実務投入に踏み切れていないケースも多い。Happy Horseがその障壁をどこまで下げてくれるかが注目点だ。 中国勢が「動画」でも覇権争いに加わった意味 画像生成AIの世界では、中国発のモデルがコストパフォーマンスと品質の両面で欧米勢を追い上げてきた経緯がある。ローカルLLMの分野でも同様のトレンドが見られ、Happy Horseの登場はそれが動画領域でも始まったことを示している。 グローバルランキングで「即日首位」というのは誇張を含む可能性もあるが、それでも一定の品質評価を経た結果であることは間違いない。OpenAIのSoraが話題を集めてから約1年、動画生成AIの競争がいよいよ本格化してきたタイミングでの参入だ。 実務への影響——エンジニア・クリエイターが今やるべきこと まずは触ってみる: 新しいモデルが出るたびに「情報を追う」だけでは何も変わらない。実際に試してみて、自分の業務・制作フローでどこに使えるかを体感することが先決だ。Happy Horseのアクセス方法（APIかUIか）を確認し、小さなプロジェクトで評価することを勧める。 動画生成AI活用の候補シナリオ: マーケティング素材の試作・プロトタイプ生成 プレゼンテーション用の短尺アニメーション 社内トレーニング動画のたたき台作成 製品デモのモックアップ 注意点: ランキング首位とはいえ、ベンチマーク評価と実務品質は別物だ。商用利用のライセンス条件、日本語プロンプトへの対応状況、生成コスト（APIの場合）を必ず確認してから導入を検討してほしい。 IT管理者向けの視点: 従業員が個人アカウントで外部の動画生成AIサービスを使い始めるのは時間の問題だ。禁止で対応しようとするより、会社として承認済みのツールと利用ガイドラインを整備する方が現実的で、情報漏洩リスクも管理しやすい。 筆者の見解 動画生成AIの競争がここまで速く激しくなるとは、正直1年前には予想できなかった。Happy Horseの「即日首位」という話を聞いて最初に思ったのは「情報だけ追っていたら追いつけない」という実感だ。 中国勢の開発速度と品質向上のペースは、もはや「中国のAI」として軽く見られる段階を完全に超えている。特に動画生成という計算コストが高い領域でこれだけの成果を出してくるのは、相応のリソースと技術力の裏付けがある。 一方で、日本のIT現場における動画生成AIの活用はまだほとんど始まっていない。テキスト→画像でさえ「業務でどう使うか」に悩んでいる企業が多い中、動画はさらにハードルが高く感じられるかもしれない。しかし、考え方を変えれば、今が一番学習コストが低い時期でもある。他の人がまだ「情報を眺めている」段階で自分で使い込んだ人間が、1年後に大きな差をつけることになる。 動画生成AIを「面白そうな技術」で終わらせないために、まず小さな実験を一つ始めてみることを強く勧めたい。大義名分は後からついてくる。 出典: この記事は Alibaba Group Launches Groundbreaking AI Video Model “Happy Horse” の内容をもとに、筆者の見解を加えて独自に執筆したものです。

フランス政府が、一部の政府機関のコンピューターをWindowsからオープンソースOS「Linux」へ移行する方針を発表した。デジタル担当大臣のダヴィッド・アミエル氏は「我々のデジタルの運命を自らの手に取り戻す」と表明。単なるコスト削減ではなく、デジタル主権（Digital Sovereignty）という国家戦略の一環として位置づけている。 何が起きているのか 移行はまず、フランス政府のデジタル機関であるDINUM（Direction interministérielle du numérique）のコンピューターから開始される。具体的な移行タイムラインやLinuxディストリビューションの選定については未発表だが、フランスはすでに昨年、ビデオ会議ツールをMicrosoft TeamsからフランスViso（Jitsi OSS基盤）に切り替えており、今回の発表はその延長線上にある。 背景にあるのは、トランプ政権発足以降の地政学的緊張だ。米国政府が国際刑事裁判所の判事らに制裁を科し、米国のテクノロジーサービスへのアクセスを遮断したことは、「外国政府が米国クラウドに依存した場合のリスク」を欧州の政策立案者たちに強烈に意識させた。2025年1月には欧州議会も、外国プロバイダーへの依存度低減を欧州委員会に指示する報告書を採択している。 Linuxへの移行は現実的か 「政府がLinuxへ移行」という話は過去にも幾度となく出ては消えてきた。独ミュンヘン市の「LiMux」プロジェクトが典型例で、2003年に開始し2013年に完了したものの、2017年にWindowsへ戻るという結末を迎えた。 今回のフランスの動きが過去と異なるのは、地政学的プレッシャーがドライバーになっている点だ。「Windowsの方が使いやすい」という議論を超えて、国家安全保障と主権の問題として捉えられている。政府機関のデータが外国企業のサーバーやOSに依存することへのリスクヘッジは、純粋な技術選定ではなく政治・外交判断に近い。 また、近年のLinuxデスクトップ環境は実用性が大幅に向上している。Ubuntu・Fedora・Debian系のディストリビューションは、一般的なオフィス業務であればLibreOfficeとWebブラウザで相当部分をカバーできる。特にDINUMのような技術力の高い機関であれば、移行のハードルは一般的な企業より低い。 実務への影響——日本のIT管理者が今すぐ考えるべきこと フランスの動きは遠い話ではない。日本でも以下の観点で実務的な影響が想定される。 1. 調達・契約リスクの再評価 特定ベンダーのクラウドやOSへの集中依存は、政治・外交リスクとセットで評価する時代に入った。BCPの観点からも、主要ツールの代替可能性を定期的にレビューする習慣を持ちたい。 2. SaaS選定におけるデータ所在の確認 欧州のGDPR対応として「データのEU域外移転制限」が厳格化されているが、日本でも重要インフラや官公庁向けシステムでは、データ主権の観点からオンプレミス・国内クラウド優先の議論が出てくる可能性がある。 3. オープンソース基盤のリスク管理能力 Linux移行の成否は技術よりも運用体制で決まる。OSS活用を推進するなら、社内または委託先でのLinuxサポート体制を整備しておくことが重要だ。 筆者の見解 正直に言うと、この話を「Microsoftへの逆風」として単純に読むのは表面的すぎると思っている。 フランスの動きの本質は「Microsoftが嫌いだからLinuxへ」ではなく、「特定の国家に依存したデジタルインフラは国家リスクになりうる」という認識の変化だ。これはMicrosoftに限らず、あらゆる外国テクノロジーベンダーに向けられた問いかけでもある。 Microsoftの立場で考えると、これはもったいない状況だ。AzureはEU内データセンターで主権クラウドオプションを提供しており、Microsoft Cloud for Sovereigntyという専用製品まで用意している。Windows自体もセキュリティ強化の方向で着実に進化してきた。それでも「OSのソースコードが公開されていない」という点は、政府機関にとって最終的な信頼の壁になりうる。オープンソースであれば、少なくとも理論上はコードレベルでの検証が可能だ。 日本のIT業界はこの動きをどう受け止めるか。「欧州は極端だ」と距離を置くのか、それとも「自分たちのデジタルインフラの依存構造を点検するきっかけ」と捉えるのか。大変革が静かに進んでいる中で、後者の姿勢が問われている。 フランスの移行が成功するかどうかはまだわからない。だが「デジタル主権」という概念が欧州の政策文書から実際の調達決定に降りてきた事実は、技術者として注目しておく価値がある。 出典: この記事は France to ditch Windows for Linux to reduce reliance on US tech の内容をもとに、筆者の見解を加えて独自に執筆したものです。

WireGuardのWindows向けクライアントが長い沈黙を破り、大幅なアップデートを届けた。2026年4月10日に公開されたWireGuardNT v0.11およびWireGuard for Windows v0.6は、一時話題を呼んだMicrosoftの署名アカウント停止問題を経て届いた、待望のリリースだ。セキュリティコミュニティを中心に注目を集めている。 何が変わったのか 今回のアップデートの本質は「新機能の追加」よりも「内部品質の抜本的な向上」にある。 新機能としては、パケットをドロップせずに許可IPアドレスを個別削除できる機能（LinuxやFreeBSDでは既に対応済み）と、IPv4接続での超低MTU設定のサポートが加わった。 しかし開発者のJason Donenfeld氏が最も強調するのはコードの近代化だ。サポート対象Windowsの最低バージョンを引き上げたことで、長年にわたって積み重なった互換性ハック・代替コードパス・複雑な動的ディスパッチ処理を一掃できた。ツールチェーンも全面更新されており、ドライバービルドに用いるEWDK、ユーザースペースのClang/LLVM/MingW、メインUIのGoバージョン、さらにEV証明書と署名インフラまで刷新されている。これらの積み重ねが性能改善と安定性の向上につながっている。 Microsoftの署名騒動——「陰謀」ではなく「官僚主義」 今回のリリースに前後して、「MicrosoftがWireGuardの署名アカウントを停止した」というニュースが一部で波紋を呼んだ。Donenfeld氏はこの点を明確に説明している。アカウントが一時停止されたのは事実だが、Hacker NewsやX（旧Twitter）での話題がMicrosoftの目に留まり、翌日にはアカウントが復活して問題は解決済みだという。「陰謀でも悪意でもない。官僚的なプロセスが少し暴走しただけで、Microsoftはすぐに対処してくれた」——これがDonenfeld氏の見解だ。 現在も出回っている一部の報道はこの解決を反映していないため、「署名が停止されたままなのに新バージョンが出た?」と疑問に思った人もいるだろうが、その答えはシンプルだ：アカウントはもう開放されている。 なお今回もWindows 10 1507（Build 10240）という最古のビルドまで対応は継続されている。Microsoftのサポート期限を超えた環境にまで気を配るのは、オープンソースプロジェクトらしい姿勢だ。 実務への影響 WireGuardはLinux・macOS・iOS・Androidで既に成熟した実績があるが、Windows版はこれまで更新頻度が低く、導入に慎重な組織も多かった。今回の刷新で、Windowsを中心とした環境でも安心して採用できる水準に引き上げられた。 IT管理者・エンジニアへの具体的な推奨事項： 既存ユーザー：内蔵のオートアップデーターが署名検証付きで安全に更新を促す。通知に従って更新するだけでよい 新規導入を検討中の組織：従来のIPSec/OpenVPNと比較してコンフィグが圧倒的にシンプルで、障害時の切り分けもしやすい。今がWindowsインフラに組み込む好タイミングだ 古いWindowsが残っている環境：Windows 10 1507まで対応しているが、そこまで古い環境はWireGuardのバージョンより先にOSのライフサイクル管理を優先すべきだ 筆者の見解 率直に言えば、「VPNを使い続ける」という選択肢自体には複雑な思いがある。ゼロトラストアーキテクチャへの移行を推進する立場から見ると、VPNはネットワーク境界への依存を温存する設計であり、長期的には置き換えていくべき技術だと考えている。 ただし、WireGuardはその中でも際立ってクリーンなアプローチをとっている。プロトコル設計がシンプルで監査しやすく、コードベースは小さく、暗号化ライブラリの選択もモダンだ。「今すぐゼロトラストに全面移行できない」という現実の制約の中で選ぶなら、WireGuardは合理的な選択肢の一つといえる。 Microsoft署名騒動については、コミュニティからの声が迅速に届いて翌日には解決されたという経緯は好ましい。官僚的なプロセスの暴走は起きうるものだが、それへの対応速度がその組織の実力を示す。今回はきちんと機能した。 技術的負債の返済という観点で言えば、古いWindowsへの対応クラッドを一掃しながら品質を上げていく今回の方針は正しい方向だ。互換性のためにコードを膨らませ続けることはセキュリティリスクにもなる。こうした「ちゃんと地ならしをしてから走る」姿勢は、長く使われるインフラソフトウェアとして評価できる。 出典: この記事は WireGuard makes new Windows release following Microsoft signing resolution の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年4月15日、Microsoft 365のCopilot提供形態が静かに変わる。対象は有償の「Microsoft 365 Copilot」ライセンスを持たない、いわゆる基本プランの「Copilot Chat」利用者だ。変更の規模は地味に見えるが、組織のIT管理者にとっては利用ガイドやサポート対応を見直す契機になり得る。 何が変わるのか——変更のポイントを整理する 今回の変更は一言でいうと、「アプリ内Copilotアクセスの制限」だ。 これまでCopilot Chatの基本プランでも、Word・Excel・PowerPointといったM365アプリ内にCopilotのUIが表示されており、一部の機能を使える状態にあった。4月15日以降、この「アプリ内UI」が基本プランのユーザーには表示されなくなる。 一方で、以下は変わらない点として明示されている： Copilot Chat本体：EdgeまたはChromeを通じたセキュアなAIウェブチャットは引き続き利用可能 チャット経由のコンテンツ作成：Microsoft 365 Copilotのウェブインターフェースから、Word・Excel・PowerPoint向けの文書をAI支援で作成できる Outlookのコパイロット機能：受信トレイ整理・カレンダー調整・会議サマリーなど、Outlook内のCopilot機能はそのまま残る 有償の「Microsoft 365 Copilotライセンス」保有者は今回の変更に一切影響を受けない。アプリへの深い統合（ドキュメント内でのリアルタイム提案・要約など）は、引き続きフルライセンスのみの特権となる。 「削減」ではなく「整理」——Microsoftの意図を読む 技術的な実態を見ると、今回の変更は機能の廃止ではなく利用経路の整理と解釈できる。 Copilot Chatを通じたドキュメント生成（Word/Excel/PowerPoint）は引き続き可能であり、できることの本質は変わっていない。ただし「アプリを開いた状態でその中でCopilotを呼び出す」というUI体験が基本プランでは使えなくなる。生産性ツールとしてのシームレスな統合感——それがフルライセンスの価値として改めて明確化された形だ。 Microsoftが段階的にライセンス体系を整理しながら、アプリ統合の深さをマネタイズポイントに設定していく意図は明らかだ。 実務への影響——IT管理者がすべきこと 利用者へのアナウンスを先手で打つ 「4月15日以降にWord内でCopilotが消えた」という問い合わせが現場から多発する可能性がある。変更前に組織内の利用者へ変更内容と代替手順（Copilot Chat経由の利用方法）を周知しておくことで、ヘルプデスクへの問い合わせ急増を防げる。 ライセンス棚卸しの好機 Copilotを日常的に使い込んでいるユーザーと、ほとんど使っていないユーザーの差が今回の変更で可視化されやすい。「アプリ内Copilotが必要」という要望が多い部署・ロールについては、フルライセンス付与の費用対効果を改めて評価するきっかけになる。 教育機関・パブリックセクターは特に注意 今回の元情報がアイオワ大学のITS（情報システム部門）からのものであることが示すように、全教職員・学生にCopilot Chatを展開している教育機関では影響範囲が広い。「誰に何のライセンスを付与しているか」の台帳整理が急務になる場合がある。 Outlook依存の業務フローは安心して継続 会議サマリーの自動生成・受信トレイの優先度整理など、Outlookに依存した業務フローは今回の変更対象外だ。日常業務でOutlookのCopilot機能を活用しているユーザーに対しては「影響なし」と明確に伝えられる。 筆者の見解 Microsoftが基本プランとフルライセンスの差を改めて明確化したことは、製品戦略として理解できる。だが「Copilotをもっと使ってほしい」という方向性と「基本プランでアクセスできるものを絞る」という方向性は、本来であれば緊張関係にある。 Copilotというブランドをここまで広げた以上、触れる機会を増やすことが普及への近道だったはずだ。アプリ内の直感的な起動ポイントがなくなれば、日常的に使う習慣がついていないユーザーがわざわざWebインターフェースを開く可能性は高くない。「便利を感じる前に離脱する」というリスクは看過できない。 Microsoftが誇るM365の統合エコシステムは、シームレスな体験にこそ価値がある。その核心部分をライセンス差異のロック機構として使うのであれば、「まず触ってもらう」という導線設計を別途用意する必要があるだろう。 いずれにせよ、4月15日は急ぐほどの変更ではない。ただしIT管理者にとって「Copilotのライセンス体系を正確に把握しているか」を問い直す機会として、今回の変更は無駄にしない方がいい。 出典: この記事は Update to Copilot availability in Microsoft 365 apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11の標準アプリに散在していたCopilot関連の機能・ボタン・参照箇所を、順次削除し始めた。NeowinをはじめとするWindowsメディアが伝えたこの動きは、「とりあえずAIを載せる」フェーズの終わりを示すシグナルかもしれない。 何が起きているのか Microsoftはここ数か月で、メモ帳（Notepad）などWindows 11付属の標準アプリに統合されていたCopilotへの導線・UI要素を削除するアップデートを配布し始めた。同社はこれを「有用ではないCopilot参照のクリーンアップ」と説明しており、全標準アプリを対象に段階的に適用される見込みだ。 追加されたのはほんの数か月〜1年前のこと。それが「不要」として撤去されているという事実が、今回のニュースの本質だ。 なぜこれが重要か 「AI統合＝価値」ではなかった 2023〜2024年にかけて、MicrosoftはあらゆるWindows機能にCopilotを組み込もうとしていた。これ自体は戦略的には理解できる判断だった。しかし実際には、多くの統合が「使われない機能」として画面を占有するだけだった。 今回の削除は、ユーザーエクスペリエンスのフィードバックに真摯に応答した結果ともいえる。フォームファクターや文脈に合わないAI統合は、便利どころか邪魔になる——この単純な教訓を、世界最大級のOS企業が公式に認めた格好だ。 整理は「後退」ではなく「精度向上」 機能の削除を後退と捉えるのは早計だ。むしろ「どこにAIを置くと本当に価値が生まれるか」を再定義するプロセスと見るべきだろう。不必要な統合を外し、真に機能する場所にリソースを集中させる——ソフトウェアの成熟として評価できる動きだ。 実務への影響 IT管理者向け: 特にエンタープライズ環境ではCopilot機能の可用性をポリシーで制御していた組織もある。アップデート後にUIが変わることがあるため、ヘルプデスクへの問い合わせが発生するリスクがある。主要な標準アプリのUI変更をリリースノートで事前確認しておきたい。 エンジニア向け: Windows標準アプリのUIに依存したRPA・自動化スクリプトを運用しているなら、今後のアップデートでボタン位置や要素構造が変わる可能性に注意。テスト環境での事前確認サイクルを見直しておく価値がある。 一般ユーザー向け: アプリが以前より「シンプルになった」と感じたとしたら、それはバグではなく意図的な変更だ。Copilotを積極的に使いたいユーザーには、専用のCopilot UIからアクセスする形に収束していくと思われる。 筆者の見解 Copilotが登場してから、私はずっと「もったいないな」という思いを持ち続けてきた。Microsoftが持つ技術力、Azureのインフラ、Officeの深い統合基盤——これほどの資産を持っている会社がAIを届けようとしているのだから、本来ならば圧倒的な体験を作れるはずなのだ。 だからこそ、「とりあえず全部に載せる」アプローチには失望感があった。メモ帳にCopilotボタンが現れたとき、多くのエンジニアが「これは本当に必要か？」と感じたのは私だけではないはずだ。 今回の整理は、その問いへの答えを出した形だ。遅すぎた感はあるが、正しい方向への修正には違いない。大切なのは「どこに統合するか」を徹底的に考え抜くこと——ユーザーの実際のワークフローの中で自然に機能するAIこそが、長期的に価値を発揮する。 Microsoftにはまだそれを実現できる力がある。今回の一歩が、次の精度の高い展開への布石になることを期待したい。「この撤退の話が古いニュースになる日」を楽しみにしている。 出典: この記事は Microsoft begins removing Copilot from Windows 11 apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftのCopilot利用規約に、今も「エンターテインメント目的のみ（entertainment purposes only）」という文言が残っていたことが、Redditユーザーによって発見され話題となった。「重要な事項にはCopilotを信頼するな」「自己責任で使用せよ」——いずれも太字で記載されたその文章は、「AIでビジネスを変革する」というMicrosoftの主張と真っ向から矛盾するように見える。 Microsoftの釈明——「Bing Chat時代の古い表現」 Microsoftはこの問題を指摘されると、「エンターテインメント目的という表現は、CopilotがBing Chatとして検索補助サービスの一環で提供されていた頃の名残だ。製品の進化に合わせて近日中に修正する」と回答した。 確かに、法的文書に古い表現が残ることはどの企業でも起こりうる。ただ、今回のケースは単純な「表現の更新漏れ」として片付けにくい面がある。現在もその文書は公開されたままであり、そこには「信頼するな」「自己責任で」という表現が明記されている。AIへの社会的関心が高まるなかで、こうした文書管理の精度は企業の信頼性を直接左右する。 現在のCopilotは何ができるのか Microsoftは現在、Copilotに対してさまざまな機能を追加している。長文テキストからのポッドキャスト生成、ドキュメントの整形・要約、さらにはWindows 11の操作補助など、生産性向上を前面に打ち出している。Microsoft 365 Copilotに至っては、ExcelやPowerPointを横断した作業支援において、実際に業務効率の改善を実感しているユーザーも多い。 一方、個人向けのCopilot（コンシューマー版）については評価が分かれる。ネイティブコードではなくWebViewベースに変更されて以降、使い勝手の面での不満も聞こえてくる。 市場での立ち位置——数字が語る現実 SimilarWebなどの公開データを見ると、WebベースのトラフィックにおいてはスタートアップのPerplexityにも後れを取っているという指摘がある。もちろん、Windowsアプリ、Edge、Microsoft 365への統合など「計測が難しいチャネル」での利用は考慮されておらず、単純な比較はできない。しかし、単独プロダクトとしての求心力という点では、まだ課題が残る状況だ。 実務への影響——IT管理者・エンジニアへのヒント 1. 利用規約の定期確認を習慣に クラウドサービスの利用規約は、サービスの進化に伴って改訂されることが多い。Copilotに限らず、組織で採用しているAIツールの規約は定期的に確認し、実際の用途との乖離がないか把握しておきたい。 2. 期待値のコントロールがカギ 「AIが何でもやってくれる」ではなく、「何が得意で何が苦手か」を把握したうえで使う。Microsoft 365 CopilotをOfficeとの連携タスクに絞って使う、といった「用途を限定した活用」が現時点では安定した成果につながりやすい。 3. コンシューマー版と企業向けは別物と考える 個人利用のCopilotと、Microsoft 365に統合されたエンタープライズ向けCopilotでは、機能・品質ともに差がある。組織導入を検討する際は、コンシューマー版の印象だけで判断しないことが重要だ。 筆者の見解 今回の一件で感じたのは、「惜しい」という言葉に尽きる。 MicrosoftにはAIを真剣に業務へ組み込む技術力も、ユーザーベースも、エコシステムも揃っている。それだけのポテンシャルがあるからこそ、「利用規約の表現が更新されていなかった」という話が余計に目立ってしまう。 製品の信頼は、機能の多さよりも、細部の一貫性から生まれる。法的文書に「娯楽目的のみ」と書いておきながら「ビジネスのあらゆるユースケースに対応」とアピールするのは、ユーザーへのメッセージとして整合がとれていない。Microsoftほどの組織であれば、製品メッセージとドキュメントのライフサイクル管理を一体で動かせるはずだ。 消費者向けCopilotの体験向上は、短期的な数字の競争以上に、「AIを信頼して使ってもらえるか」という長期的な土台を作る話だ。そのことを、Microsoftは誰よりもよく理解しているはずだと信じたい。Copilotが「過去の批評」として笑い飛ばされる日が来ることを、引き続き期待している。 出典: この記事は Microsoft denies Copilot is only for entertainment purpose, after its own document says do not trust AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AlibabaがQwen 3.6 Plusを発表した。同社のQwenシリーズはオープンモデルとしての性能で注目を集めてきたが、今回のアップデートは単なるスコア向上にとどまらない。「エージェント型LLM」を正面から主張した初めての本格的なモデルとして、AI活用の現場に対する影響が大きい。 100万トークンのネイティブコンテキストが変えること 多くのLLMが「対応している」と謳うコンテキスト長は、実際には精度が著しく落ちる「名目上の数字」であることが多い。Qwen 3.6 Plusが主張するネイティブ100万トークンは、外部RAGや要約処理に頼らずモデル自身がそのウィンドウを扱えることを意味する。 具体的に言えば、数十万行規模のコードベース全体、長大な仕様書、数百件の会話ログをそのままプロンプトに渡せる。エージェントが自律的にタスクをこなす際に「過去の文脈を思い出せない」問題は、エージェント設計上の根本的なボトルネックだった。この制約が実用レベルで緩和されるなら、エージェントの設計思想そのものが変わりうる。 「考えすぎ」問題の改善 前世代のQwenシリーズは「推論ステップを必要以上に重ねて、かえって精度が落ちる・遅くなる」という問題が報告されていた。いわゆるoverthinking（考えすぎ）だ。 Qwen 3.6 Plusではこの挙動を抑制し、タスクの複雑さに応じた思考深度の調整を試みている。これはエージェント的な連続タスクで特に重要で、無駄なステップが積み重なると処理コストと遅延が指数関数的に増大する。自律ループを設計する上で、この改善は地味だが実用上の意味は大きい。 OpenRouterで無料プレビュー中 現在、OpenRouter経由でプレビュー期間中は無料で試せる状態になっている。日本のエンジニアにとっても、実際に触れるハードルが低い。独自のエージェント構成を試したい開発者は、今のうちに評価しておく価値がある。 実務への影響 エージェント設計者へ 長大なコンテキストを前提とした設計が現実的になる。RAG構成の見直しが選択肢に入ってくる 自律ループ（タスクの判断・実行・検証を自分で繰り返す構成）での動作評価を優先的に行いたい overthinking抑制の効果は実際のワークフローで検証が必要。ベンチマーク上の改善が実タスクに出るかは別問題 IT管理者・意思決定者へ 中国発のオープンモデルが実用水準に達しつつある事実は、調達選択肢の幅として把握しておくべき ガバナンス上の要件（データロケーション、利用規約）は各自で確認が必要 オープンモデルはオンプレやプライベートクラウドへのデプロイが可能。閉域環境が求められる用途での候補になりえる 筆者の見解 「エージェント型LLM」という言葉は最近乱用気味だが、Qwen 3.6 Plusが提示した方向性は本質を突いている。 AIエージェントの真価は「人間が何度も確認ボタンを押す副操縦士」ではなく、「目的を伝えれば自律的にタスクをやり遂げる存在」にある。そのためにネイティブな長文脈処理と、無駄な推論ステップを排した効率的な思考は、どちらも欠かせない基盤条件だ。 エージェントが自律ループ——判断・実行・検証を自分で回し続ける仕組み——を安定して動かせるかどうかが、LLMの実用価値を分ける時代になっている。コンテキスト100万トークンとoverthinking抑制という組み合わせは、まさにその方向への投資だ。 Alibabaがオープンウェイトでこの水準を出してきたことは、AIエコシステム全体にとって良い刺激だと思う。競争が活性化し、エージェント設計の可能性が広がるのは歓迎すべきことだ。ただし「エージェント型」を名乗るモデルは今後も続々と登場する。大切なのはベンチマーク数字ではなく、自分たちの実際のワークフローで自律ループが安定して回るかを検証すること。それだけが本当の評価基準になる。 出典: この記事は Qwen3.6-Plus: The First Real “Agentic” LLM? の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Adobe Readerにゼロデイ脆弱性が存在し、少なくとも2025年12月から現在に至るまで、実際の攻撃に使われ続けていることが明らかになった。サンドボックス型エクスプロイト検出プラットフォーム「EXPMON」の創設者であるセキュリティ研究者Haifei Li氏が発見し、公表したもので、現時点でAdobe側からのパッチはまだリリースされていない。 何が起きているのか 今回の脆弱性の最も恐ろしい点は、ユーザーがPDFを開く以外の操作を一切必要としないことだ。リンクをクリックする必要も、マクロを有効にする必要もない。ただ、メールに添付されたPDFをいつもどおり開くだけで感染が成立しうる。 この攻撃は「フィンガープリント型エクスプロイト」と呼ばれる高度な手法を採用している。まず被害者の環境情報を収集・識別し、その後に追加の攻撃（リモートコード実行＝RCE、サンドボックス脱出＝SBX）へと展開する多段階の仕組みになっている。情報収集に使われているのはAcrobat内部の特権API（util.readFileIntoStreamおよびRSS.addFeed）であり、本来PDFアプリケーションに用意されている機能が悪用されているのが技術的な肝だ。 ロシア語のおとり文書と標的 脅威インテリジェンスアナリストのGi7w0rm氏が分析したところ、攻撃に使われたPDF文書にはロシア語の内容が含まれており、ロシアの石油・ガス産業に関連する時事的な話題を装っていることが確認されている。これは標的が比較的絞り込まれていることを示唆しており、無差別なばら撒きではなく、特定の組織や業界を狙ったターゲット型攻撃の可能性が高い。 とはいえ、脆弱性の仕組み自体はAdobe Readerの最新バージョンで動作するものであるため、攻撃が転用・拡散される前に対策を取ることが重要だ。 実務での対応ポイント パッチがまだない以上、今すぐ取れる対策は以下の通りだ。 エンドユーザー向け 信頼できない送信元からのPDFは、パッチリリースまで絶対に開かない 特に、業務上覚えのないPDFメールには最大限の警戒を Adobe Readerの自動アップデートを有効にしておき、パッチが出たら即座に適用できる状態にしておく IT管理者・ネットワーク担当者向け HTTPおよびHTTPSトラフィックのUser-Agentヘッダーに "Adobe Synchronizer" という文字列が含まれる通信を監視・ブロックする（Li氏が推奨する緩和策） プロキシやエンドポイント保護製品でこのシグネチャを追加設定することで、通信段階での遮断が可能 EDR（エンドポイント検知・対応）製品のアラートを強化し、Adobe Readerプロセスから不審なネットワーク接続や外部ファイルアクセスが発生していないか監視する ゼロトラスト観点での補足：今回の攻撃はネットワーク境界を突破するものではなく、信頼された内部アプリケーション（Adobe Reader）を踏み台にする手法だ。境界型セキュリティだけでは検知が難しく、アプリケーション層・プロセス層での振る舞い監視が有効性を発揮する場面だ。 筆者の見解 ゼロデイ脆弱性の4ヶ月間放置という事実は、改めてパッチ管理の難しさを突きつける。Adobeの対応スピードについては、公表後の動向を引き続き注視したい。 それ以上に気になるのは構造的な問題だ。「PDFを開く」という日常業務の動作が攻撃面になる以上、ユーザー教育だけでの防御には限界がある。エンドポイント上でのアプリケーション挙動監視と、ネットワーク通信ログの突合による異常検知の組み合わせが、こうした未知の脅威に対して実効性を持つ。 今回の「フィンガープリント型」という手口も興味深い。攻撃者は被害者を識別してから次の段階に進む——つまり、単に悪意あるコードを実行するだけでなく、標的の価値を確認した上で追加投資するかどうかを判断している。高度なAPT（持続的標的型攻撃）に見られる特徴で、無差別ばら撒きとは一線を画す。 パッチが出るまでの間、Haifei Li氏が公開した緩和情報は現時点での最善策だ。「今動いているから大丈夫」ではなく、「まだ動いているが今日はやられるかもしれない」という感覚で臨みたい。 出典: この記事は Hackers exploiting Acrobat Reader zero-day flaw since December の内容をもとに、筆者の見解を加えて独自に執筆したものです。

WordPressサイトの運営者・開発者にとって、プラグインのアップデートは「信頼できる行為」のはずだった。その前提が4月7日、根底から崩れた。 スライダー作成プラグイン「Smart Slider 3 Pro」の更新配信システムが第三者に乗っ取られ、バックドアを複数埋め込んだ悪意あるバージョン（3.5.1.35）が正規の更新として配布されたのだ。WordPress向けの無料版だけでも90万以上のサイトで使われているプラグインだけに、影響の広がりは無視できない。 何が起きたのか WordPressおよびJoomlaのセキュリティを専門とするPatchStackの分析によると、問題のバージョンに仕込まれたマルウェアは「完全機能を持つ多層型ツールキット」だという。プラグイン本体の機能は正常に動作したまま、バックドアだけが静かに動き続ける設計になっている点が特に悪質だ。 確認された攻撃機能 1. 認証なしリモートコード実行 HTTPヘッダーを細工するだけで、攻撃者はWordPressにログインすることなくPHPコードやOSコマンドを実行できる。これが最も危険な入口となる。 2. 隠し管理者アカウントの自動生成 wpsvc_というプレフィックスを持つ管理者権限ユーザーがデータベースに作成される。通常の管理画面には表示されない設計になっており、気づきにくい。 3. 多層的な永続化機構 攻撃の巧妙さが際立つのが、この永続化の仕組みだ。 mu-pluginsディレクトリにキャッシュコンポーネントを装ったファイルを設置。「Must-Use Plugin（必須プラグイン）」は管理画面から無効化できず、プラグイン一覧にも表示されない テーマのfunctions.phpに埋め込まれるため、テーマが有効な限り生き続ける wp-includesディレクトリにWordPressコアクラスを偽装したPHPファイルを設置。このバックドアは.cache_keyファイルから認証キーを読み込むため、データベースのパスワードを変えても無効化されない 4. 認証情報の窃取 サイト情報とログイン情報が自動的に外部へ送信される。 影響を受けるバージョンと推奨対応 ベンダーはバージョン3.5.1.35のみが対象と発表。対応は以下の通り。 汚染バージョンを使用していない場合: 3.5.1.36へ更新（または3.5.1.34以前のまま維持） 汚染バージョンを使用していた場合: サイト全体が侵害されたと仮定して行動する 侵害時の対応手順（必須）: 不正ユーザー・ファイル・データベースエントリの削除 WordPressコア・プラグイン・テーマを信頼できるソースから再インストール 全認証情報のローテーション（WordPress管理者・DB・FTP/SSH・ホスティング・メール） WordPressセキュリティキー（ソルト）の再生成 マルウェアスキャンとログレビュー バックアップ復元を行う場合は、タイムゾーンの差異を考慮して4月5日以前のバックアップを使用するようベンダーは推奨している。 実務への影響 IT担当者がすぐ確認すべきこと まず自社・顧客サイトで管理しているWordPress/JoomlaにSmart Slider 3 Proが導入されているか確認する。バージョンが3.5.1.35であれば、即座に侵害対応モードに入る必要がある。 管理しているサイトが多い場合は、WP-CLIで一括確認するのが効率的だ: 出典: この記事は Smart Slider updates hijacked to push malicious WordPress, Joomla versions の内容をもとに、筆者の見解を加えて独自に執筆したものです。

セッション盗難という「静かな脅威」に、Googleがハードウェアで応答した Googleは2026年4月、Chrome 146（Windows版）にDevice Bound Session Credentials（DBSC）を正式実装した。狙いはシンプルだ——インフォスティーラーと呼ばれるマルウェアによるセッションクッキーの窃取を、ソフトウェアではなくハードウェアの力で原理的に無効化すること。macOS版は追って対応予定とされており、今後のアップデートで順次展開される。 これはセキュリティ界隈の地味なアップデートに見えるかもしれないが、実際には「パスワードを知らなくてもアカウントに侵入できる」という長年の攻撃手法に対する、構造的な回答である。 なぜセッションクッキーが狙われるのか Webアプリケーションでは、ログイン後にサーバーが発行するセッションクッキーが認証トークンとして機能する。有効期限が来るまでの間、このクッキーさえあればパスワードなしで認証が通る。 問題は、このクッキーがローカルのファイルやメモリに保存される点だ。LummaC2をはじめとするインフォスティーラー型マルウェアは、こうしたデータを組織的に収集してC2サーバーへ送信する手口を洗練させてきた。多要素認証（MFA）を突破しなくても、セッションを「そのまま使い回す」ことで正規ユーザーになりすませてしまう。 Googleが公式見解として「ソフトウェアだけではクッキーの流出を防ぐ信頼できる手段がない」と明言しているのは、この構造的な弱さへの正直な認識である。 DBSCが解決する仕組み DBSCは、セッションをデバイスのセキュリティチップに暗号的にバインドするプロトコルだ。WindowsではTPM（Trusted Platform Module）、macOSではSecure Enclaveが使われる。 仕組みの要点は以下のとおり： セッションごとに固有の公開鍵/秘密鍵ペアをセキュリティチップが生成する 秘密鍵はチップ外にエクスポートできない 新しいセッションクッキーの発行には、Chromeがサーバーに対して「この秘密鍵を保持している」ことを証明する必要がある 秘密鍵を持たない攻撃者がクッキーを盗み出しても、すぐに無効化される 設計上、プライバシーへの配慮もある。セッションごとに異なる鍵を使うことで、複数サービス間での行動追跡に利用されない構造になっている。サーバー側へ送信されるのはセッションごとの公開鍵のみで、デバイス識別情報は含まれない。 このプロトコルはGoogleとMicrosoftが共同開発し、W3Cでオープン標準として策定が進む。Okta等との実証実験では、セッション盗難の件数が顕著に減少したとGoogleは報告している。 日本のエンジニア・IT管理者にとっての実務的意味 管理者が今すぐやるべきこと Chrome 146以降への更新管理を確認する: Intune・GPO等でバージョンポリシーを管理している組織では、DBSC有効化のためにChrome 146以降を対象バージョンに含める必要がある TPMの有効化状態を棚卸しする: DBSCはTPMに依存する。TPMが無効・未搭載のデバイスではこの保護が効かない。特に古い社用PCが混在する環境では要注意だ SaaSのDBSC対応状況を把握する: ウェブアプリ側もバックエンドに登録・リフレッシュ用エンドポイントを追加する必要がある。主要SaaSベンダーの対応ロードマップを確認しておきたい 開発者向けの視点 自社サービスでDBSCを実装する場合、GoogleのDBSC実装ガイドとW3Cの仕様書が公開されている。既存フロントエンドとの互換性を維持しつつ、バックエンドにエンドポイントを追加するだけで対応できる設計になっており、段階的な導入が可能だ。 注意点 DBSCはあくまでセッション盗難後の横展開を防ぐ仕組みであり、マルウェア感染そのものを防ぐものではない。エンドポイント保護（EDR等）との組み合わせが前提となる。「Chromeがアップデートされたから安心」という過信は禁物だ。 筆者の見解 セキュリティの話は正直に言えば得意分野ではないが、このDBSCのアプローチは技術的に筋が通っていると感じる。「ソフトウェアだけではクッキー流出を防げない」というGoogleの認識は、ゼロトラストの文脈で語られてきた「ネットワーク境界では守れない」と同じ構造的な問いへの誠実な回答だ。 TPMやSecure Enclaveといったハードウェアの信頼の根（Root of Trust）を利用してセッションをバインドする発想は、Just-In-Timeアクセスと同じ方向性を持つ。「常時使えるトークンではなく、特定の文脈でのみ有効な証明」という考え方は、特権アカウント管理の理想形に近い。 GoogleとMicrosoftがこのプロトコルを共同で開発し、W3Cで標準化を進めているのも重要な点だ。ベンダー固有の実装ではなくオープン標準として育てることで、SaaSエコシステム全体への普及が現実的になる。 一方で、展開には時間がかかる。TPMが普及していない古いデバイスが残存する環境、DBSCに未対応のSaaS、macOS版の対応待ち——現実の企業環境は「理想の状態」からはほど遠い。この技術が「当たり前の防御層」として機能するには、サーバーサイドの対応が広がるまで数年単位の時間軸で考える必要がある。 その間も、インフォスティーラーの攻撃は止まらない。DBSCを「将来の保険」として認識しつつ、今日できるEDRの強化・TPMの有効化・セッション有効期限の短縮といった対策を地道に積み上げることが、現実的な判断だと思う。 出典: この記事は Google Chrome adds infostealer protection against session cookie theft の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがEdgeブラウザからXSLT（Extensible Stylesheet Language Transformations）のサポートを削除することを明らかにした。XSLT は XML 文書を HTML やテキストなど別形式に変換するための技術で、2000年代に多くの企業システムで採用されていた。長年にわたってEdgeに組み込まれてきた機能だが、いよいよそのサポートに終止符が打たれようとしている。 XSLTとは何か、なぜ今まで残っていたのか XSLT は W3C が策定した XML 変換仕様で、サーバーサイドで生成した XML データをブラウザ上でスタイルシート（.xsl ファイル）を使って HTML に変換する、という仕組みだ。2000年代初頭には「コンテンツとプレゼンテーションの分離」を実現する有力な手段として広く使われた。 しかし時代は変わった。現在のウェブ開発では REST API + JSON + JavaScript フレームワークが主流となり、XSLT を新規採用するケースはほぼ存在しない。それでも Edge に残り続けていたのは、削除すれば既存の業務システムが動かなくなるという、後方互換性への配慮からだ。 Edge の前身である Internet Explorer は XSLT を積極的にサポートしており、IE 向けに構築された社内ポータルや申請フォームが XSLT に依存しているケースは、日本の大企業・官公庁を中心に今も少なくない。 影響を受けるシステムの典型例 社内ポータル・承認フロー: SAP や独自開発の XML ベースデータをブラウザで表示・印刷するシステム 帳票・レポート出力: XML で出力したデータを XSLT で整形して画面表示するレガシー帳票基盤 Web サービス連携画面: SOAP 系 XML を XSLT でレンダリングしていた古い連携 UI Edge の Chromium ベースへの移行（2020年）でも XSLT は残されたが、今回はいよいよ削除が決定されたかたちだ。 実務への影響——日本企業が今すぐやるべきこと 1. 依存システムの棚卸し まず自社ブラウザで .xsl ファイルを参照している URL やアプリケーションがないか調査する。Edge の開発者ツール（F12）のネットワークタブで Content-Type: application/xml や .xsl ファイルへのリクエストを確認するのが手早い方法だ。 ...

Windows 11の最新メジャーバージョン「25H2」への強制アップデートが、一般ユーザー向けに始まった。特筆すべきは、その展開タイミングの判定に機械学習（ML）を使う「インテリジェント」な更新システムだ。2026年10月にサポート終了を迎える24H2からの移行促進が目的だが、判定基準の非公開と直前の緊急パッチ騒動が重なり、複雑な印象を与えている。 何が起きているのか Microsoftは、Windows 11 Home・Pro（バージョン24H2）を対象に、25H2への自動アップグレードを開始した。対象はあくまで個人・小規模向けのHome/Proエディションで、Active DirectoryやIntuneで組織管理されているデバイスは現時点では除外されている。 ユーザーには完全なオプトアウト手段は与えられていないが、インストールを一定期間延期するオプションは残されている。また、「設定 → Windows Update → 更新プログラムの確認」から手動で任意のタイミングに適用することも可能だ。 機械学習による「準備完了」判定——その不透明さ 今回の仕組みで最も気になるのが、MLを使った「デバイス準備完了」の判定だ。Microsoftは自動展開のタイミングを機械学習で決定するとしているが、具体的な判定基準——どのデータポイントを使うのか、何をもって「準備完了」と見なすのか——については一切公開していない。 セキュリティや互換性の観点から安全なデバイスを優先展開する意図は十分理解できる。しかし判定ロジックが不透明なままでは、ユーザーも管理者も「いつ、なぜ自分のPCが対象になったのか」を事前に把握できない。透明性を高めることはMicrosoftにとって技術的に難しいことではないはずで、ここは改善を求めたいポイントだ。 企業環境への影響は限定的——ただし確認は必須 現時点では、組織管理下のデバイスは強制アップデートの対象外だ。しかし注意が必要なのは、管理が「ゆるい」環境——たとえばMicrosoft 365 Business BasicでAzure AD参加しているが実質個人管理に近い中小企業のPC——だ。自社デバイスがどのスコープに含まれるかを、この機会に確認しておくことを強く勧める。 また、24H2のサポート期限は2026年10月13日。まだ半年あるように見えるが、全デバイスの移行計画を今から立てておかないと、後半に慌てることになる。 直前の緊急パッチ騒動が示すもの タイミングが悪いことに、Microsoftはつい先日、プレビューアップデート「KB5079391」の不具合対応として緊急パッチ「KB5086672」をリリースしたばかりだ。エラーコード0x80073712（ファイル破損・欠落）が多数報告され、広範なインストール失敗を引き起こした。 「すぐ適用したら壊れた」という報告は近年増えている傾向がある。最終的には修正パッチが来るとはいえ、強制アップデートとの組み合わせで「望まないタイミングに問題が起きる」リスクは現実として存在する。数日様子を見てから適用する判断は、今やれっきとしたエンドポイント管理の一形態だ。 実務への影響 個人・SOHO向け 強制アップグレードが来る前に、手動で25H2の動作確認を済ませておくと安心 延期オプションを活用しながら、まず少数台でテスト→問題なければ順次展開する流れが定石 中小企業・IT管理者向け Intuneやグループポリシーで管理しているデバイスは現時点で対象外——ただし管理スコープの確認を忘れずに 24H2サポート終了（2026年10月）に向けた移行計画を今四半期中に立案する 一般ユーザー向け 「更新を止める」ではなく「タイミングをコントロールする」発想で臨む 強制といっても延期は可能。業務の繁忙期を避けて適用するのが現実解 筆者の見解 Windows Updateの「強制アップデート」という言葉には、どうしてもネガティブな反応が先行する。だが本質を整理すると、24H2のサポート終了まで半年を切った中で、放置されたままの旧バージョンデバイスをまとめて最新化しようという意図自体は正しい方向性だ。エンドポイントが分散したバージョン環境に置かれ続けることのリスクは、サポート切れよりもずっと早く顕在化する。 ただ、直前に緊急パッチ騒動があったタイミングで強制展開を開始するのはスマートではない。「機械学習で判定する」と言いながら基準を非公開のままにするのも、ユーザーの信頼を積み上げていく姿勢とは言い難い。 Microsoftには、この種の展開をユーザーが安心して受け入れられる品質と透明性を実現する力が十分にある。Windows Updateへの信頼性向上は、エンドポイントセキュリティ強化の最短経路でもある。正面から勝負できる力を持っているのだから、品質と説明責任の両面をもう一段上げてほしい——そう、期待を込めて言いたい。 出典: この記事は Microsoft to force updates to Windows 11 25H2 for PCs with older Windows 11 OS versions の内容をもとに、筆者の見解を加えて独自に執筆したものです。