Windows

MicrosoftがコラボレーションツールのLoop（Microsoft Loop）から、Copilotが生成するAIレキャップ（recap）機能を削除することを発表した。「AIをあらゆる場所に」という同社の戦略から見ると、これは異例中の異例——方向転換というよりも、静かな撤退に近い。 Microsoft Loop のAIレキャップとは何だったのか Microsoft LoopはNotion対抗として2023年にGAとなったM365のコラボレーションスペースだ。「ページ」「コンポーネント」「ワークスペース」という概念を使い、チームがリアルタイムに共同作業できる環境を提供する。 AIレキャップ機能は、このLoopワークスペース内の活動を自動的に要約し、「前回から何が変わったか」「誰が何をしたか」をCopilotがまとめて提示するというものだった。会議に出られなかった、しばらく離れていた、という場面で「キャッチアップ」を助けるのが主な用途として想定されていた。 なぜ廃止されるのか Microsoftが公式に詳細な理由を示しているわけではないが、背景として考えられる要因はいくつかある。 利用率の問題: レキャップ機能は使われていなかった可能性が高い。Loop自体がまだユーザーベースを拡大中であり、そのうえAI要約という付加機能はニッチな使われ方にとどまっていたと推測できる。 コスト対効果: CopilotはAzure OpenAIのAPIコストを消費する。利用率が低いまま維持するのは明らかに非効率だ。 品質の問題: AI要約の精度が期待値を下回っていた可能性もある。誤った要約、文脈を無視した要約は、むしろ混乱を招く。 いずれにせよ、「AI機能を追加する」方向だけでなく「使われないAI機能を削除する」という意思決定ができるようになったこと自体は、成熟の証とも言える。 実務への影響——日本のIT現場では まず、Loop自体の普及状況を確認しておきたい。日本でLoopを積極的に導入・活用している企業はまだ少数派だ。M365 E3/E5に含まれているため「使えるが使っていない」状態の組織が多く、今回の変更を意識しているユーザーも限られるだろう。 すでにLoopを活用している組織は、レキャップ機能に依存したワークフローがあれば代替手段を検討する必要がある。Teams のミーティング要約（Intelligent Recap）やOneNoteとの連携、あるいは手動でのサマリー作成に切り替えるのが現実的だ。 これからLoopを検討している組織にとっては、AIレキャップ廃止はほぼ影響なしと考えてよい。Loopの本質的な価値はリアルタイムコラボレーションにあり、AI要約はオマケ機能に過ぎなかった。 IT管理者へのヒント: MicrosoftのM365ロードマップ（Microsoft 365 Roadmap）を定期的に確認する習慣をつけておくこと。今回のような機能廃止は、ユーザーへの事前周知なしに進むことがある。Message Centerアラートの設定は必須だ。 筆者の見解 正直に言う。「Copilotあらゆるところに刺さります！」という数年間のMicrosoftのノリには、ずっと違和感を持っていた。LoopのAIレキャップも、使って感動した人より「要らなかった」と感じた人のほうが多かったんじゃないかと思っている。 だから今回の廃止は、「残念」ではなく「まあそうだよね」という感想だ。使われない機能を削るのは正しい。むしろ遅かった。 ただ、問題はその奥にある。Microsoftはここ数年、「Copilot」という名前を至るところに貼り付けてきた。M365 Copilot、GitHub Copilot、Windows Copilot、Copilot Studio……。機能の中身より名前の統一を優先して、結果として「Copilotって何なの？」という混乱を生んでいる。今回の廃止も、ロードマップの整理というよりは「コッソリ消した」に近い。 Copilotブランドの整理は急務だ。だが、AI基盤としてのMicrosoftの価値は揺るがない。Entra ID・M365・Azureという圧倒的なエコシステムを持っている会社は他にない。だからこそ、個々のAI機能の取捨選択はもっと大胆にやってほしい。今回のように「使われない機能を削る」判断を、もっと早く・もっと広くやれるはずだ。正面から勝負できる力があるのだから、薄く広く貼るより、本当に価値のある体験に集中してほしい。 がんばれ、Microsoft。本当に。 出典: この記事は Microsoft to strip AI-generated recaps from Loop in surprising move の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11上でEdgeへのユーザー誘導を強化する新たな手法を試験導入していることが明らかになり、GoogleをはじめとするブラウザベンダーやNGOで構成されるBrowser Choice Alliance（BCA）が強く反発している。静かに進むこの施策が、ユーザーの「ブラウザを選ぶ権利」を根底から脅かすものだとして、国際的な批判の声が上がっている。 何が起きているのか BCAが問題視しているのは、Windows 11のテスト段階で確認された挙動だ。ユーザーがChromeやFirefoxなどを既定ブラウザとして設定していても、特定の操作をトリガーにEdgeが再び前面に出てくるよう設計されているという。明示的な確認なしに「静かに戻す（quiet nudge）」仕組みであり、ユーザーが気づかないうちに選択が上書きされるリスクがある。 この手法はEUのデジタル市場法（DMA）が義務付ける「真の選択肢の提供」に反する可能性があり、日本を含む非EU圏でも競争法上の観点から問題提起されかねない水準だ。 Microsoftの「Edge推し」の歴史 MicrosoftがEdgeを優遇してきた歴史は長い。Windows 10以降、既定ブラウザの変更UIをわかりにくく設計したり、「Edgeを使ってみますか？」の通知を繰り返し出したりと、ソフトな強制が続いてきた。2022年にはEUの圧力を受けてブラウザ選択画面を復活させたが、今回の「静かな誘導」はその精神を骨抜きにするものだとBCAは主張する。 BCAにはGoogleのほか、Mozilla、Opera、Vivaldi、さらには消費者保護団体も名を連ねており、単純なライバル企業の嫌がらせではなく、ブラウザエコシステム全体の問題として訴えていることがわかる。 実務への影響——IT管理者はどう動くべきか 企業のIT環境では、ブラウザの標準化はセキュリティポリシーや社内システムの動作保証と直結する。ChromeやEdgeをグループポリシーで管理している組織にとって、OSアップデートやテスト機能のロールアウトによって既定ブラウザが意図せず変更されるリスクは無視できない。 今すぐ確認・対応すべきポイント： 既定ブラウザのポリシー固定: Intune や グループポリシー（GPO）で DefaultBrowserSettingEnabled を明示的にFalseに設定し、ユーザー操作・OS側の干渉両方をブロックする Windows 11の段階的ロールアウト監視: Insiderチャネルで確認された挙動が安定版に降りてくる前に、テナントの更新リングを確認しておく ブラウザ変更の監視ログ: Microsoft Entra（Intune）のデバイスコンプライアンスレポートに既定ブラウザの変更トリガーが記録されていないか定期チェック ゼロタッチ展開の見直し: 自動プロビジョニング後のブラウザ設定が期待通りか、テスト環境で確認するステップを追加する 筆者の見解 長年Microsoftの技術を追いかけてきた立場から、率直に言いたい。Edgeは技術的に良いブラウザだ。 Chromiumベースになって以降、安定性もパフォーマンスも着実に向上した。企業向けのセキュリティ機能は充実しているし、M365との統合やIntuneでの一元管理、Entra IDとの認証連携を考えると、エンタープライズ環境でEdgeを選ぶ合理性は十分にある。 だからこそ、こういう「気づかないうちに戻す」やり方はもったいない。Edgeには正面から勝負できるだけの実力がある。それを、ユーザーの選択を静かに上書きするような手法で補おうとする必要はないはずだ。 Microsoftが本来得意としてきたのは、「禁止ではなく便利にして使わせる」アプローチだ。Microsoft Entra IDを使う仕組みを自然に選ばせる、Teamsを使いたくなる環境を整える——そういう「道のド真ん中を歩く」戦略でエコシステムを広げてきた実績がある。今回のEdge誘導は、その自社の哲学と矛盾している。ここは正直に、ダメなものはダメと言わなければいけない。 一方で、企業の現場ではEdgeを軸にした運用を組んでいる組織も多いだろう。M365との統合メリットは大きく、それ自体は正しい判断だ。重要なのは、Intuneやグループポリシーできちんと既定ブラウザを固定し、OSアップデートによる意図しない変更を防ぐ仕組みを整えておくこと。Microsoftのプラットフォームを信頼して使うことと、個別の施策を無条件に受け入れることは別の判断だ。 がんばれMicrosoft。正面から選ばれるブラウザを作る力はあるのだから、それを信じてほしい。 出典: この記事は Browser Choice Alliance slams Microsoft for latest shady Edge tactic の内容をもとに、筆者の見解を加えて独自に執筆したものです。

リード EUの最高行政機関である欧州委員会のAWSクラウド環境が、2026年3月10日に侵害された。攻撃を担ったのは「TeamPCP」と呼ばれる脅威グループ。被害はEU機関71クライアントに及び、メールアドレス・氏名・メール本文を含む約90GBのデータが闇ウェブに流出している。CERT-EU（EUサイバーセキュリティサービス）が4月3日に詳細を公表した。 この事件は単なる「大手機関のクラウド侵害」ではない。サプライチェーン攻撃 → クレデンシャル窃取 → クラウド横展開という攻撃チェーンの教科書的な実例であり、日本のIT現場にも直接刺さる話だ。 攻撃の経緯——Trivyが起点だった 攻撃の起点はDevSecOpsツールとして広く使われているコンテナ脆弱性スキャナー「Trivy」のサプライチェーン攻撃だ。TeamPCPはTrivyへの不正コード混入を通じて、欧州委員会のAWSアカウントに対する管理権限を持つAPIキーを事前に入手していた。 3月10日、このAPIキーを使って欧州委員会のAWSクラウド環境に侵入。その後、オープンソースのシークレットスキャンツール「TruffleHog」を使って環境内に残存するさらなる認証情報を探索し、既存ユーザーに新規アクセスキーをアタッチすることで検出回避を図った。 さらに巧妙なのが、この侵入が5日間検知されなかった点だ。欧州委員会のCybersecurity Operations Centerは、APIの不正利用も、アカウント侵害の兆候も、異常なネットワークトラフィックも、3月24日まで気づかなかった。侵入から一週間近くが経過してからの検知だ。 流出データの規模 CERT-EUの分析によると、盗まれたデータは以下の通り： 対象クライアント数: 欧州委員会内部42クライアント＋EU他機関29以上、合計71クライアント 流出ファイル数: 数万件（個人情報含む） メール関連ファイル: 51,992件（合計2.22GB） ダークウェブ公開: ShinyHuntersグループが90GBアーカイブ（非圧縮340GB）として公開済み メール関連ファイルの多くは自動通知メールとのことだが、「バウンスバック通知」にはユーザーが送信した元のメッセージ内容が含まれる場合があり、個人情報漏洩リスクが残る。 なお、Webサイトの改ざんや他のAWSアカウントへの横展開は確認されていない。 実務への影響——日本のIT管理者が今すぐ確認すべきこと 1. TrivyなどのDevSecOpsツールはバージョン固定で使っているか サプライチェーン攻撃の怖さは、信頼しているツールが凶器になる点だ。CIパイプラインで使うスキャナーやCLIツールのバージョンを固定し、ハッシュ検証を行う運用が必要。「最新版を自動取得」はもはや安全ではない。 2. AWSのIAMキー管理を見直せ 今回の攻撃はAWS APIキーの奪取から始まった。IAMポリシーの「最小権限の原則」は当然として、長期有効なアクセスキーの存在そのものがリスクだ。IAMロール＋一時的なクレデンシャル（STS）への移行、使われていないキーの即時削除、アクセスキーのローテーション自動化を今すぐ実施すること。 3. TruffleHogは攻撃者も使う——先に自分でスキャンしろ 皮肉な話だが、TruffleHogは防御側が「リポジトリにシークレットが埋まっていないか」を確認するためのツールでもある。攻撃者に先んじて自分の環境をスキャンし、漏洩したシークレットを先に無効化する運用を入れるべきだ。 4. 検知の遅れをどう縮めるか 5日間気づかなかったのはEUの機関でも起きうる現実だ。SIEM・CSPM（Cloud Security Posture Management）の導入と、異常なIAM操作へのアラート設定が基本中の基本。「CloudTrailは入れてる」だけでなく、アラートが実際に飛ぶ設定になっているかを今日確認してほしい。 筆者の見解 正直に言う。セキュリティは好きじゃない。細かい人が多いし、議論が不毛になりがちだ。でも今回の件は技術的に非常に興味深いし、見逃せない教訓がある。 まず、Trivyというれっきとしたセキュリティツールがサプライチェーン攻撃の入口になったという皮肉。セキュリティを強化しようとしてセキュリティ侵害される——これは「禁止アプローチ」の限界そのものだ。ツールを禁止するより、ツールを安全に使える仕組み（バージョン固定・ハッシュ検証・SBOM管理）を作ることが正解だ。禁止は必ず失敗する。 そして「5日間検知されなかった」という点。欧州委員会レベルの組織でこれが起きる。日本の大手エンタープライズの多くは、もっとひどいことになっているはずだ。「今動いているから大丈夫」は通用しない——これは過去にも何度も言ってきたが、今回はEUレベルの実例が出た。言い訳できなくなった。 IAMキー管理についても一言。「常時有効なAPIキーを発行してどこかに置いておく」という運用は、ゼロトラストの観点から言えば論外だ。Just-In-Timeアクセス、一時クレデンシャル、IAMロール——これらは「難しいからいずれやる」ではなく、今すぐやるべきことのリストの一番上に置くべきだ。 TeamPCPはGitHub・PyPI・NPM・Dockerと幅広いプラットフォームを標的にしているサプライチェーン攻撃の常習犯だ。今回の欧州委員会への侵入で終わりではなく、次のターゲットがどこかにいる。自分の組織が「よりリッチな標的」になっていないか、CIパイプラインの棚卸しを今すぐやってほしい。 出典: この記事は CERT-EU: European Commission hack exposes data of 30 EU entities の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが今週から、IT部門による管理が行われていないWindows 11 24H2（HomeおよびPro）デバイスを対象に、Windows 11 25H2への強制アップグレードを開始した。「気づいたらOSバージョンが上がっていた」という体験をするユーザーが続出するタイミングだ。個人PCでMicrosoft 365を使う業務担当者や、管理外デバイスが混在する組織のIT担当者は状況を把握しておく必要がある。 何が起きているのか MicrosoftはML（機械学習）ベースの「インテリジェントロールアウト」の適用範囲を、IT管理外のWindows 11 24H2 HomeおよびPro 全台 に拡大した。 背景は明確だ。Windows 11 24H2のサポート終了日は 2026年10月13日。残り約6ヶ月。サポート終了後はセキュリティ更新、タイムゾーン更新、テクニカルサポートがすべて止まる。Microsoftの公式表現を借りれば「最新の脅威からの保護を含む月次セキュリティ更新を受け取れなくなる」。 なお、25H2は大きなメジャーアップデートではない。200KB未満の「有効化パッケージ」 で適用されるマイナーアップデートで、2025年9月から段階配信が進んでいた。 アップグレードの流れと対処法 自動更新対象: IT管理（MDM/Intune等）外のHome/Proデバイス全台 手動で先行確認: 設定 → Windows Update → Windows 11 25H2のリンクをクリック 一時停止も可: 設定 → Windows Update → 一時停止（ただし期限後は強制適用） 再起動タイミングは自分で選択可能 Microsoftはアップグレード時のトラブル対応用にサポートドキュメントとステップバイステップガイドを公開している。 背景：立て続けに起きているトラブルとの重なり タイミングが若干不安だ。2026年3月のPatch Tuesday以降、Microsoftは複数の緊急対応を余儀なくされている。 Microsoftアカウントのサインイン失敗（Teams・OneDrive等に影響）→ KB5085516で対処 Bluetoothデバイスが見えなくなる問題（ホットパッチ対応のWindows 11 Enterprise向け） RRAS（Routing and Remote Access Service）のセキュリティ脆弱性 → 帯域外更新で修正 これだけ問題が連続している中で、25H2への強制移行が始まったのが現状だ。 実務への影響 IT管理者・情報システム担当者 最大の課題は 「管理外デバイスの把握」 だ。BYODや在宅勤務者の個人PC、テスト機、来客用端末など、MDM/Intune管理外のデバイスが組織内に混在しているケースは少なくない。確認しておきたいポイントは以下： 管理外デバイスの棚卸し: 何台あり、どのバージョンが走っているか 25H2との互換性チェック: 古い業務アプリ、特にドライバー依存の周辺機器との相性 エンドユーザーへの周知: 一時停止方法を案内するか否かの組織判断 25H2適用後のサインイン問題対策: KB5085516の適用状況を確認しておく 個人・SOHOユーザー 基本的には放置で問題ないケースが大半だ。ただし業務でTeamsやOneDriveを使っている場合、サインイン失敗が起きた際の対処法（緊急更新KB5085516の適用）は頭に入れておこう。 ...

GDC 2026（ゲーム開発者会議）にて、MicrosoftはWindowsおよびXboxのゲーム開発者向けに複数のツール強化を発表した。ロード時間短縮・シェーダー配信最適化・アセットパイプライン改善という3本柱で、次世代Xbox「Helix」に向けた開発者エコシステムの整備が本格化している。 発表内容：3つの柱 1. Zstandard（zstd）圧縮サポート WindowsのゲームパッケージングにZstandard圧縮が正式対応した。Zstdはオープンソースの高速圧縮アルゴリズムで、既にChromeやLinuxカーネル、Meta社内インフラ等で広く採用されている実績ある技術だ。従来のzlib系と比べてデコード速度が大幅に速く、ゲームのロード時間短縮に直結する。Xbox GDKを通じてPC・Xbox双方に適用可能なため、一度の対応で両プラットフォームの体験向上が期待できる。 2. Game Asset Conditioning Library（GACL） ゲームアセット（テクスチャ・メッシュ等）をターゲットプラットフォームに最適化された形式に変換するライブラリが提供される。ビルドパイプラインに組み込むことで、プラットフォームごとの手動最適化作業を自動化できる。特にPC/Xboxのマルチターゲット開発において、アセット変換の工数削減効果は大きい。 3. Advanced Shader Delivery の全開発者解放 これまで一部パートナー限定だったAdvanced Shader Deliveryがすべての開発者に開放された。Direct Storage APIと組み合わせることで、ゲーム起動時のシェーダーコンパイル待ちを大幅に削減できる機能だ。「最初の起動が遅い」という長年のDirectX系ゲームの課題に、ようやく本格的な解決策が普及段階に入った。 なぜこれが重要か これらの発表の真の意味は、Xbox GDKを軸としたPC/Xbox統合開発基盤の強化にある。次世代Xbox「Helix」のリリースを控え、Microsoftは「1つのコードベースで両プラットフォームに最適化されたゲームが作れる環境」の整備を急いでいる。 日本のゲーム開発会社にとっても無縁ではない。国内の中堅スタジオがPC/Xboxのマルチ展開を検討する際、これまでは「Xboxのシェアが低いから費用対効果が見えにくい」という判断が多かった。しかし、GDKによる共通化でPC対応の追加コストが下がるなら、Xbox対応のハードルも同時に下がるという構造だ。 実務への影響——エンジニア・IT管理者が押さえるべきポイント ゲームエンジニア向け Advanced Shader Deliveryは今すぐ検証すべき。既存タイトルのロード体験改善に直結するため、まず検証環境で効果を測定する価値がある GACLはCIパイプラインへの組み込みを前提に設計されている。既存のビルドフローを見直す良い機会 Zstd対応は圧縮率とデコード速度のバランスが優秀。パッケージサイズとロード時間のトレードオフを改めて検討したい 技術リード・プロデューサー向け PC版とXbox版の「別物扱い」から「同一コードの設定違い」への移行コストが下がりつつある。中長期のプラットフォーム戦略を見直す契機になる 次世代Xbox「Helix」向けの最適化は今から仕込んでおいたほうが楽になる 筆者の見解 正直に言うと、Microsoftのゲーム開発者向けの動きは久々にまともな方向性に見える。Advanced Shader Deliveryの全開放は「なんで今まで一部限定だったんだ」と言いたくなるが、それが解放されたのは素直に評価していい。 Zstandard対応も、「なぜ今さら」感はあるものの、業界標準のオープン技術をWindowsエコシステムに取り込んでいく姿勢は正しい。独自規格で囲い込むよりも、標準技術で生態系を広げるほうが長期的にはプラットフォームの競争力につながる。道のド真ん中を歩く判断だ。 ただ、冷静に見ると、これらはゲームエンジン側（UnrealやUnity）がとっくに対応してきた問題へのOS/SDK側のキャッチアップでもある。「Microsoftが先行して業界を引っ張っている」というよりは「ようやく現場の要求に追いついてきた」が正確な評価だろう。 次世代Xbox「Helix」に向けて、MicrosoftのゲームプラットフォームがWindowsと一体化していく流れは不可逆だと思う。PC Gamepassの拡大戦略と合わせて考えると、「Xboxというハードウェアブランド」より「Windowsというプラットフォームでゲームをやる体験」への移行を本気で進めているのが透けて見える。それは正しい判断だ。がんばれ、Microsoft。 出典: この記事は GDC 2026: Announcing new tools and platform updates for Windows PC game developers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが音声認識の世界に大きな一石を投じた。同社は新しい音声文字起こしモデル「MAI-Transcribe-1」を公開し、多言語音声認識の標準ベンチマークであるFLEURS（Few-shot Learning Evaluation of Universal Representations of Speech）において、11の主要言語でトップの精度を達成したと発表した。OpenAIの「Whisper-large-v3」やGoogleの「Gemini 2.0 Flash」といった強力な競合を差し置いての首位は、音声AI分野の勢力図に明確な変化をもたらすものだ。 MAI-Transcribe-1とは何か 「MAI」はMicrosoft AIを意味するプレフィックスで、同社が独自に研究開発した基盤モデル群に付けられるブランドだ。MAI-Transcribe-1はその音声認識特化モデルであり、大規模な多言語音声データで訓練されている。 FLEURSベンチマークは、語族や音素体系が異なる多様な言語にわたって精度を測定するため、単一言語チューニングでは太刀打ちできない。11言語での首位は、モデルのアーキテクチャと学習データの双方において競合を凌駕していることを示している。 比較対象のWhisper-large-v3はOpenAIが公開しているオープンソースの文字起こしモデルとして業界標準的な地位を確立しており、多くの日本企業が会議録自動化や字幕生成に採用している。それを超えた精度というのは、実際の導入効果に直結する話だ。 なぜこれが重要か——日本のIT現場への影響 日本語は音声認識において特に難しい言語の一つだ。同音異義語が多く、文脈依存性が高く、敬語・専門用語・固有名詞のバリエーションも膨大にある。国内の会議録自動化ツールや医療・法務分野での音声入力システムが精度の壁に悩まされてきた背景がある。 FLEURSでの好成績が日本語を含む言語で達成されているならば、これは業務用途における文字起こし精度の底上げとして直接的なインパクトをもたらす。特にMicrosoft 365 CopilotやTeamsの会議文字起こし機能との統合が想定されることから、すでにM365環境を利用している日本企業にとっては追加投資なしで恩恵を受けられる可能性が高い。 実務での活用ポイント 1. Azure AI Speechとの連携を確認する MicrosoftはAzure AI Speech（旧Cognitive Services音声系）のバックエンドにMAI系モデルを順次統合している。現在Azure AI Speechを使って文字起こし系のAPIを呼んでいる場合、モデルバージョンのアップデートを追跡し、MAI-Transcribe-1が利用可能になった際に切り替え検証を行う価値がある。 2. Teams Premium / Copilot for M365の会議文字起こしを再評価する 会議の議事録自動生成に「精度が足りない」としてTeamsの文字起こしを使っていない組織は、今後数ヶ月以内に再評価の機会が来る。比較検証のために、代表的な会議シナリオでの文字起こし精度を定期的にスコアリングする仕組みを作っておくと良い。 3. オンプレミス要件がある場合はWhisperとの使い分けを継続検討 Whisper-large-v3はOSSであり、セキュリティポリシー上クラウドAPIを使えない環境でも自前でホスティングできる。MAI-Transcribe-1がAPIのみ提供であれば、機密性の高いデータを扱う金融・医療分野ではWhisperを内製運用するほうが現実的なケースも引き続き存在する。 筆者の見解 音声認識の精度競争は、ここ数年でOpenAIのWhisperが「実用的に使えるレベル」のハードルを一気に引き下げた。それまで専業ベンダーの独占市場だったところに汎用AIが殴り込んだ形だ。今回MicrosoftがMAI-Transcribe-1でWhisperを超えたことは、競合への対抗というよりも「Microsoft製品エコシステムの中で最高水準の音声処理を完結させる」という戦略的な意図を感じる。 特にCopilot統合の流れを見ると、会議の文字起こし→要約→タスク抽出→Plannerへの自動登録、というワークフローをMicrosoftが自社でクローズドループとして完成させようとしていることは明白だ。その基盤として最高精度の文字起こしモデルを持つことは、エコシステム全体の品質を底上げする。 一方で懸念もある。ベンチマーク上の最高精度が、実際の業務環境——騒がしい会議室、アクセントの強い話者、専門用語が飛び交う技術討議——でそのまま発揮されるかは別の話だ。FLEURSは学術的な評価軸であり、ノイズ耐性や話者適応性については別途評価が必要になる。 今後のポイントは、MAIシリーズがAzureのマネージドサービスとして一般提供されるタイミングと価格体系だ。精度がいくら高くても、Whisperの無料OSSという選択肢に対してコスト優位性を示せなければ、エンタープライズ以外での普及は限定的になる。日本市場では特に中堅・中小企業のコスト感度が高く、この点が普及速度を左右するだろう。音声AIの「次のWhisperモーメント」が来るとすれば、MAI-Transcribe-1はその有力候補だ。 出典: この記事は Microsoft releases MAI-Transcribe-1, the most accurate transcription model in the world の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Ciscoのサーバー管理基盤に、認証を一切必要とせず管理者権限を乗っ取れるという非常に深刻な脆弱性が発見された。データセンターやオンプレミス環境でCiscoサーバーを運用している国内の企業・組織にとって、即座の対応が求められる案件だ。 Cisco IMCとは何か——見落とされがちな「隠れた管理経路」 Cisco IMC（Integrated Management Controller）は、Cisco UCS C-SeriesやE-SeriesサーバーのマザーボードにハードウェアとしてビルトインされているOOB（Out-of-Band）管理モジュールだ。OSがクラッシュしていても、電源が切れていても、XMLのAPI・WebUI・CLIを通じてサーバーを遠隔管理できる。 いわばサーバーの「バックドア的な管理口」であり、BMC（Baseboard Management Controller）と同様の役割を果たす。管理の利便性が高い一方、ネットワークに露出していれば攻撃の入り口にもなりうる。 脆弱性の詳細——パスワード変更処理の不具合が致命的 今回発見されたCVE-2026-20093は、Cisco IMCのパスワード変更機能における不適切な処理に起因する。攻撃者は認証なしでHTTPリクエストを細工して送信するだけで、システム上の任意ユーザー（Adminを含む）のパスワードを変更し、そのユーザーとしてシステムにアクセスできてしまう。 CVSSスコアはクリティカル評価であり、現時点でワームやランサムウェアによる実績のある悪用事例やPoCコードは確認されていないものの、Cisco PSIRTは「ワークアラウンドなし・即時アップグレードを強く推奨」と異例の表現で警告している。「ワークアラウンドなし」という点が特に重く、一時的な緩和策が存在しない以上、パッチ適用以外の選択肢がない。 同時公開された他の重大脆弱性も要注意 今回のリリースでは、IMCの問題に加え、もう一つのクリティカル脆弱性も修正されている。 CVE-2026-20160は、Cisco Smart Software Manager On-Prem（SSM On-Prem）のAPIに対して細工されたリクエストを送るだけで、権限なしの攻撃者がOSレベルのroot権限でリモートコード実行（RCE）できるというものだ。ライセンス管理サーバーとしてオンプレ環境に展開している組織は特に影響を受ける。 さらに今月初旬には、Cisco Secure Firewall Management Center（FMC）の最高深刻度RCE脆弱性（CVE-2026-20131）が「Interlockランサムウェア」によるゼロデイ攻撃で悪用されており、CISAが連邦機関に3日以内のパッチ適用を命じる事態にまで発展していた。 実務への影響——国内エンジニアが明日すべきこと 影響範囲の確認（最優先） データセンターやサーバールームでCisco UCS C-Series / E-Seriesを運用しているか確認 IMCのWebUIやAPIポートが外部ネットワークやDMZに露出していないか即座にレビュー 原則としてIMCの管理ポートは専用管理VLANに隔離し、インターネットに直接露出させない構成を徹底する パッチ適用の手順 Cisco Security Advisoryから修正済みバージョンを確認 IMCのファームウェアアップデートはOSと独立して行えるが、メンテナンス窓口の設定が必要 ネットワーク的な隔離ができていない場合は、パッチ適用までの間IMCへのアクセスをACLで制限することを検討（根本解決にはならないが被害軽減に有効） SSM On-Premの対応 CVE-2026-20160の影響を受けるSSM On-Premはエンタープライズ向けライセンス管理サーバーであり、Cisco製品を多数運用している企業ほど導入している可能性が高い。管理コンソールのURL露出状況を確認し、同様に即時パッチを適用すること。 筆者の見解 今回の一連の脆弱性で改めて浮き彫りになったのは、「インフラの管理プレーン」がいかに攻撃者に狙われやすいか、という現実だ。IMCのようなOOB管理機能はOSレイヤーより「下」に存在するため、EDR（Endpoint Detection & Response）などのセキュリティエージェントの監視対象外になることが多い。攻撃者にとっては「見えない経路」から侵入できる絶好の標的といえる。 ゼロトラストの文脈でも、「管理ネットワークの分離」と「BMC/IMC等のファームウェア管理」は優先度の高い課題として位置づけられているが、実態として後回しにされているケースが多い。今回のインシデントはその重要性を再認識させる機会だ。 また、Ciscoの開発環境がサプライチェーン攻撃（Trivyを悪用した認証情報窃取）によって侵害されたという報告も並行してなされており、単なる製品脆弱性の話にとどまらない。サプライチェーンセキュリティとインフラ管理の両面でリスク評価を見直す時期に来ている。 Ciscoを使い続けるエンジニアとしては、今後はIMCやSSM On-Premのようなインフラ管理コンポーネントのパッチ管理を、OSやアプリケーションと同列に扱う運用体制の構築が急務だと感じる。「ハードウェアは一度設定したら触らない」という古い慣習は、今の脅威環境には通用しない。 出典: この記事は Critical Cisco IMC auth bypass gives attackers Admin access の内容をもとに、筆者の見解を加えて独自に執筆したものです。

エンタープライズ向けのセキュアファイル転送製品「Progress ShareFile」に、認証なしでリモートコード実行（RCE）まで到達できる深刻な脆弱性チェーンが発見された。既にPoCの詳細が公開されており、パッチ未適用環境への攻撃が現実的な脅威となっている。 何が見つかったのか オフェンシブセキュリティ企業のwatchTowrは、Progress ShareFile の Storage Zones Controller（SZC）コンポーネント（ブランチ5.x）に2つの脆弱性を発見した。 CVE-2026-2699（認証バイパス）: HTTPリダイレクトの不正な処理により、未認証のままShareFile管理インターフェースへアクセスできる。 CVE-2026-2701（リモートコード実行）: ファイルアップロード・展開機能を悪用し、アプリケーションのWebルートに悪意のあるASPX Webシェルを設置できる。 この2つを連鎖させた攻撃シナリオでは、攻撃者はまずCVE-2026-2699で管理画面に侵入し、ストレージゾーンの設定変更やパスフレーズ関連のシークレット値を制御下に置く。次にその情報を使って有効なHMAC署名を生成し、CVE-2026-2701でWebシェルを展開してサーバー上での任意コード実行を達成する。 認証なしでここまで到達できる「pre-auth RCE」という点が、このチェーンの最大の危険性だ。 なぜこれが重要か — ファイル転送製品は標的にされやすい ファイル転送・共有製品はランサムウェア集団や国家系脅威アクターが好んで狙うカテゴリだ。過去を振り返れば、Accellion FTA、GoAnywhere MFT、MOVEit Transfer、Cleo といった製品の脆弱性が相次いでClopをはじめとするランサムウェアグループに悪用され、大規模なデータ漏洩につながっている。 ShareFileも同様に、大企業・中堅企業が機密文書をやり取りするために使う製品であり、一度侵害されると内部の重要ファイルへのアクセスが容易になる。watchTowrのスキャンによれば、Storage Zone Controllerはインターネット上に約3万台が公開露出しており、ShadowServer Foundationも700台のインスタンスを観測している（多くが米国・欧州）。 日本国内での利用実態は公表されていないが、グローバルなSaaSやハイブリッドクラウド環境を持つ企業では、SZCをオンプレミスまたはプライベートクラウドに構築しているケースが存在する。自社環境でShareFile SZCを運用している場合は即刻確認が必要だ。 実務での対応ポイント 1. バージョン確認と即時パッチ適用 Progress は2026年3月10日に修正版「ShareFile 5.12.4」をリリース済みだ。SZCのバージョンが5.12.4未満であれば、最優先でアップデートする。 2. ネットワーク露出の最小化 SZCをインターネットに直接公開している場合は、VPNやプライベートネットワーク経由のアクセスに限定する。公開が必要な場合もWAF・IPホワイトリストで防御層を追加する。 3. 侵害痕跡（IoC）の確認 Webルート配下に不審なASPXファイルが存在しないか確認する。管理画面へのアクセスログや設定変更履歴を遡り、異常なアクセスがないかチェックする。 4. HMAC関連シークレットの再生成 パッチ適用後、ゾーンパスフレーズや関連シークレットを新しい値にローテーションする。攻撃者が侵害前に値を取得している可能性を考慮するためだ。 筆者の見解 今回の脆弱性は「個別の欠陥が軽微に見えても、組み合わせると壊滅的になる」という脆弱性チェーンの典型例だ。CVE-2026-2699単体では情報漏洩止まりのように見えるが、CVE-2026-2701と組み合わせることでサーバー完全掌握まで一直線に繋がる。 ファイル転送製品の脆弱性が繰り返し大規模攻撃に悪用されている現状を見ると、これらの製品に対するセキュリティ成熟度の低さが業界全体の課題として浮かび上がる。「ファイルを安全に送れればいい」というプロダクト観から、「常時攻撃にさらされている前提でハードニングする」発想への転換が求められている。 幸い今回は公開前にResponsible Disclosureが機能し、修正版が先にリリースされている。しかしwatchTowrが技術詳細を公開した以上、攻撃者がエクスプロイトを実装するのは時間の問題だ。「パッチが出ている」という安心感で対応を先送りにするのではなく、72時間以内の適用を目標に動いてほしい。 MOVEit、Cleo、そして今回のShareFile——この系譜を見るたびに、エンタープライズのファイル転送インフラがいかに攻撃面として見逃されてきたかを痛感する。次のターゲットが何かは分からないが、「自社で使っているファイル転送製品の脆弱性を定期的にトラッキングする」習慣を今すぐ組織に根付かせるべきだろう。 出典: この記事は New Progress ShareFile flaws can be chained in pre-auth RCE attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「コードは安全だった」——それでも280億円が消えた 2026年4月1日、Solanaブロックチェーン上のDeFi取引プラットフォーム「Drift Protocol」が、少なくとも約280億円（285百万ドル）もの資金流出を受けた。驚くべきは、攻撃者がスマートコントラクトの脆弱性を一切利用しなかったという点だ。プログラムに欠陥はなく、シードフレーズも漏洩していない。破られたのは「コード」ではなく「ガバナンスの信頼構造」そのものだった。 攻撃の手口——8日間かけて仕込まれた時限爆弾 攻撃は3月23日から30日にかけて入念に準備された。攻撃者はまず「Durable Nonce Account（耐久ナンスアカウント）」と呼ばれるSolanaの機能を活用した。 通常、ブロックチェーンのトランザクションにはブロックハッシュが使われるため、署名からおよそ2分以内に実行しなければ無効になる。Durable Nonceはこの制約を取り除き、署名済みトランザクションを任意のタイミングまで保持・実行できる機能だ。正規のユースケースとして設計されたこの機能が、今回は悪用された。 次に攻撃者は、Driftの「Security Council（セキュリティ評議会）」——プロトコルの管理権限を持つマルチシグ委員会——のメンバーから、必要閾値である5人中2人の署名（2/5マルチシグ）を取得した。この署名取得プロセスの詳細は公開されていないが、ソーシャルエンジニアリングや何らかの偽装が使われた可能性が高い。 4月1日、攻撃者は正規のトランザクションをひとつ実行した直後、準備していた悪意ある署名済みトランザクションを矢継ぎ早に実行。数分のうちに管理者権限を自身に移転させた。その後、悪意あるアセットの導入、出金制限の撤廃、そして資金の抜き取りへと一気に進んだ。 なぜこれが重要か——「ガバナンス攻撃」という新たな脅威 Web3セキュリティの文脈では、スマートコントラクトの脆弱性（バグ、ロジックエラー、再入攻撃など）が主要な攻撃ベクターとして語られることが多い。しかし今回のDrift事案は、ガバナンス機構そのものを標的にする「ガバナンス攻撃」が現実の脅威であることを証明した。 DeFiプロトコルの多くは、プロトコルのアップグレードや緊急停止などの権限を「マルチシグ委員会」や「DAO投票」に委ねている。これはコードの単一障害点を減らす設計だが、裏を返せば委員会メンバーへのアクセスを確保することで、コードを触らずにシステムを掌握できるということでもある。 日本のIT現場に直接影響はないと思われるかもしれないが、この攻撃手法の本質——「正規の権限委譲フローを悪用し、タイミングを計って実行する」——はブロックチェーン以外の世界でも通用する。クラウドのIAMロール委譲、Active Directoryの管理者委任、SaaSのOAuth連携など、どこにでもある「信頼ベースの権限モデル」が持つリスクとして読み替えられる。 実務への影響——エンジニア・IT管理者が今すぐ確認すべきこと 1. マルチシグ・管理者委任の閾値設計を見直す 今回の2/5という閾値が十分だったかを問い直したい。Web3に限らず、Azure AD PIMやAWS Organizations SCPなど、特権操作に必要な承認者数と承認プロセスの堅牢性を確認しよう。 2. 「事前署名」や「委任」の有効期限を管理する Durable Nonceに相当する「後から実行できる権限の付与」が自社環境にないか確認する。具体的には、長期有効なSAMLアサーション、無期限のAPIトークン、期限なしのOAuthスコープなどが該当する。 3. 異常なアクティビティの早期検知体制を整える Driftは「異常を検知してからユーザーに警告」したが、時すでに遅しだった。管理操作のログを集約し、予期しない権限変更を即座に通知するアラートを設定しておくべきだ。Azure MonitorやAWS CloudTrailを使った特権操作の監視が典型的な対策になる。 4. ゼロ信頼（Zero Trust）原則の徹底 マルチシグの署名者が「信頼できる人物」であっても、その操作内容は常に検証する仕組みが必要だ。「Verify explicitly, assume breach」の原則は、Web3のガバナンス設計にも応用できる。 筆者の見解 今回の事件が示す最も重要な教訓は、「セキュリティの最弱点は常に人間だ」という普遍的な事実だ。Driftのスマートコントラクト自体は機能通りに動いた。バグはなかった。しかし人間で構成されたガバナンス層が破られた。 ブロックチェーン業界は「コードは嘘をつかない」「信頼が不要なシステム（Trustless）」をセールスポイントとしてきたが、現実のプロトコルはどこかで「人間の信頼」に依存している。そのギャップを突かれたのが今回の攻撃だ。 より広い視点で見ると、DeFiセキュリティの成熟は、スマートコントラクト監査だけでなくガバナンス設計の監査まで含む段階に入ったと言えるだろう。タイムロック（権限変更に意図的な遅延を設ける仕組み）やオンチェーンガバナンスの透明化、あるいは2/5より高い閾値の採用など、構造的な対策が業界標準になっていくことが予想される。 日本の企業が直接DeFiに関わるケースはまだ限定的だが、Web3を活用したB2Bサービスや、NFTを使ったロイヤリティプログラムを展開しようとする企業は増えている。「スマートコントラクトが安全なら大丈夫」という過信は禁物だ。今後は「ガバナンスの堅牢性」を問われる時代が来る——Driftの事件はそのことを、280億円という代償とともに証明した。 出典: この記事は Drift loses $280 million as hackers seize Security Council powers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「漏洩コード」への好奇心を狙った巧妙な攻撃 2026年3月31日、Anthropicが開発するターミナル型AIエージェント「Claude Code」のソースコードが、npmパッケージへの誤ったファイル同梱により外部に流出した。59.8MBのJavaScriptソースマップに含まれた51万3,000行にわたる未難読化TypeScriptコードは、わずか数時間でGitHub上に拡散し、数千回フォークされるほど注目を集めた。 この事故からわずか数日後、クラウドセキュリティ企業Zscalerの研究チームが危険な動きを確認した。「idbzoomh」というユーザーがGitHub上に偽の漏洩リポジトリを作成し、「エンタープライズ機能を解除済み・使用制限なし」と謳って訪問者を引き込んでいたのだ。 攻撃の仕組み——SEO最適化からVidar投下まで 攻撃者の手口は周到だった。偽リポジトリはSEO（検索エンジン最適化）が施されており、Googleで「leaked Claude Code」などと検索すると上位に表示される仕掛けになっていた。流出コードに興味を持った開発者がリポジトリにたどり着くと、7-Zip形式の圧縮アーカイブをダウンロードするよう誘導される。 アーカイブ内にはClaudeCode_x64.exeというRust製の実行ファイルが入っており、起動するとコモディティ型の情報窃取マルウェアVidarと、ネットワークトラフィックをプロキシするGhostSocksが展開される。 VidarはStealer系マルウェアの定番ツールで、ブラウザの保存パスワード、クッキー、暗号資産ウォレット、ファイルなどを幅広く収集してC2サーバーへ送信する。GhostSocksと組み合わせることで、感染端末を踏み台にした二次攻撃への準備も整う。 Zscalerはさらに、同一の攻撃者とみられる別のリポジトリも発見している。こちらは「Download ZIP」ボタンを設置しているが調査時点では機能していなかったため、配信戦略を実験中と推測されている。悪意あるアーカイブ自体も頻繁に更新されており、将来的に別ペイロードが追加される可能性がある。 なぜこれが重要か——日本のIT現場への影響 この攻撃が示すのは、セキュリティインシデントの「情報格差」を突く手法が高度化しているという事実だ。 開発者やエンジニアは、著名ツールのソースコードが流出したと聞けば当然興味を持つ。「隠し機能があるかもしれない」「普段使えない機能が見られるかもしれない」という好奇心は、セキュリティ意識の高い人材であっても生まれ得る。攻撃者はこの心理を巧みに利用している。 日本国内でもClaude Codeの流出は広く報じられ、GitHubで公開されたコードを参照したエンジニアは多い。偽リポジトリにたどり着いてしまった人がいないとは言い切れない状況だ。 実務での活用ポイント エンジニア・開発者向け GitHubで「話題になっているコード」を検索する際は、アカウントの作成日・コントリビュート履歴・Star数の伸び方を確認する習慣を持つ。突然現れた新規アカウントの高トラフィックリポジトリは要注意。 実行ファイル（.exe）が含まれるアーカイブは、たとえ開発ツールを装っていても絶対に実行しない。公式npmパッケージや公式GitHubリリースページのみを信頼する。 EDR（Endpoint Detection and Response）やウイルス対策ツールが最新の定義ファイルに更新されているか定期確認する。 IT管理者・セキュリティ担当者向け 社内エンジニアに「Claude Code漏洩」に関するフィッシング・マルウェアキャンペーンが存在することをアナウンスする。 プロキシやEDRのログでClaudeCode_x64.exeや7-Zipアーカイブ経由の実行ファイル起動を監視する。 GhostSocksによるSocksプロキシ通信の兆候（異常な外部向けトラフィック）を検知ルールに追加する。 筆者の見解 今回の事例は、「AIツールへの高い関心」と「情報流出への好奇心」という2つの要因が重なったタイミングを巧みに狙ったものだ。攻撃者はAnthropicの事故を受けてほぼリアルタイムで偽リポジトリを立ち上げており、その対応速度には改めて脅威を感じる。 特に注目したいのは、攻撃の「入り口」がGoogle検索であるという点だ。これまでフィッシングメールやSNS広告が主流だった初期侵入経路が、SEOを悪用した検索結果汚染へとシフトしてきている。GitHubはオープンプラットフォームの性質上、こうした悪用を完全に防ぐことが難しく、エンドユーザー側のリテラシー向上が不可欠となっている。 生成AIツールへの注目度が高まるほど、関連する「偽情報・偽ツール」を使った攻撃も増加する。Claude Codeに限らず、Copilot・Gemini・Codexといったコーディングエージェントの動向に関する検索でも同様の手口が使われる可能性が高い。「公式以外からは絶対に入手しない」という原則を組織全体に徹底させることが、今後ますます重要になると確信している。 出典: この記事は Claude Code leak used to push infostealer malware on GitHub の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11に搭載されているセキュリティ機能「Smart App Control（SAC）」が、長年の制約をついに乗り越えた。これまでSACを一度でも無効にしてしまうと、OSを再インストールしない限り再有効化できないという仕様が大きな足かせになっていたが、4月14日からの段階的ロールアウトでこの制限が解消される。 Smart App Controlとは何か Smart App Control（SAC）は、Windows 11 22H2で導入されたアプリケーション制御機能だ。Microsoftのクラウドベースの機械学習モデルを使い、信頼されていないアプリや悪意のあるコードの実行をブロックする。Windows Defenderのシグネチャベースの検出とは異なり、アプリの「評判」と「コード署名」を組み合わせてリアルタイムで判断する仕組みで、ゼロデイ攻撃やフィッシング経由のマルウェアに対して特に有効だ。 これまでの問題点 導入以来、SACには致命的なUX上の欠陥があった。新規インストール時や初期状態では「評価モード」として動作し、アプリの互換性を自動判断する。ここで互換性上の問題が発生すると自動的に無効化されるのだが、一度オフになったら二度と元に戻せないという仕様だった。 企業環境ではこの挙動が特に問題視されていた。展開済みのPCにSACを適用しようとすると、全台クリーンインストールが必要という現実離れした要件が障壁となり、多くの組織が導入を断念せざるを得なかった。 4月更新で何が変わるか 4月14日から段階ロールアウトが始まる更新では、Windows Security（Windowsセキュリティ）の設定画面からSACを直接有効化・無効化できるようになる。システムの再インストールは不要だ。 これにより次のようなシナリオが現実的になる： 既存PCへのSAC展開：IT管理者がグループポリシーやIntuneを使って、運用中のPCに一括でSACを有効化できる テスト・検証の容易化：互換性検証環境でSACを一時的に無効にして検証し、問題がなければ再有効化するワークフローが組める 段階的セキュリティ強化：重要システムから順次SACを有効化していくといった柔軟な展開計画が立てられる 実務への影響 — 日本のエンジニア・IT管理者にとっての意味 まず確認すべきこと： 自社のWindows 11端末でSACの現在の状態を把握しよう。「Windowsセキュリティ」→「アプリとブラウザーのコントロール」→「スマートアプリコントロール」から確認できる。 Intune管理者へ： 4月14日以降、Configuration Profileや設定カタログでSACを管理できるかどうかMicrosoftのドキュメント更新を注視すること。エンドポイントセキュリティのベースラインポリシーに組み込める可能性が高い。 業務アプリとの互換性検証： SACは署名されていないアプリや評判スコアが低いアプリをブロックする。社内開発のツールやレガシー業務アプリが影響を受ける可能性があるため、評価モードで動作させながら互換性を事前確認しておくことを強く推奨する。 注意点： 段階的ロールアウトのため、4月14日時点では全端末に即座に反映されない。winverやWindows Updateの状態と合わせてリリースノートを継続確認すること。 筆者の見解 この変更は一見「小さな使い勝手の改善」に見えるが、実態はWindowsのエンタープライズセキュリティ戦略における重要な転換点だと評価している。 Microsoftはここ数年、「Security by Default（デフォルトでセキュア）」を掲げてWindows 11のセキュリティ機能を強化してきた。しかし、どれだけ優れた機能でも「展開できない」では意味がない。クリーンインストール必須という制約は、現実の企業IT運用とのギャップが大きすぎた。この制約解消は、SACを「理論上あるセキュリティ機能」から「実際に使えるセキュリティ機能」へと昇格させるものだ。 日本企業のエンドポイントセキュリティを見ると、まだEDRやXDR導入が進んでいない中堅・中小企業も多い。そういった組織にとって、追加コストなしで利用できるSACは、ランサムウェアや標的型攻撃への有効な第一防衛線になりうる。 今後はIntune経由での一元管理や、Microsoft 365 Defenderダッシュボードとの統合が強化されていくはずだ。Windows 11移行と合わせて、SACを組み込んだエンドポイントセキュリティポリシーの再設計を検討するタイミングが来た。 出典: この記事は This Windows 11 feature no longer requires clean-installing the system to activate it の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11のタスクバー、ついに移動できるようになる Microsoftは、Windows 11においてタスクバーの位置を画面上で自由に変更できる新機能の早期プレビューを公開した。長年にわたるユーザーからの要望がついに実現に向けて動き出した形だ。 Windows 10から続く「タスクバー固定」問題 Windows 10までは、タスクバーを画面の上部・左側・右側・下部のいずれかに配置する設定が標準で提供されていた。しかしWindows 11では刷新されたデザインの影響で、タスクバーは画面下部への固定が必須となり、移動できなくなった。 これに対してユーザーコミュニティでは当初から強い反発があり、Microsoftのフィードバックハブにも多数の要望が寄せられていた。サードパーティ製ツール（「StartAllBack」「ExplorerPatcher」など）を使ってタスクバーを移動させるユーザーも多かったが、公式サポートはなく、Windowsアップデートのたびに動作が壊れるリスクも伴っていた。 公開された早期プレビューの内容 今回Microsoftが公開したのは、タスクバーを画面のさまざまな位置に移動できる機能の初期デモだ。正式な機能仕様や提供時期についての詳細は明らかにされていないが、開発が進んでいることが確認された。 プレビューの段階では、移動先の位置や動作の詳細は流動的とみられ、実際にInsiderプログラム（Windows Insider Program）での配信が始まるまでには変更が加えられる可能性が高い。 日本のユーザーへの影響 タスクバーの位置変更は、特に縦型モニターや超ワイドモニターを使用するユーザー、あるいはmacOSのDockに慣れた環境から移行したユーザーにとって待望の機能だ。複数モニター構成での作業効率向上も期待される。 企業のIT管理者にとっても、グループポリシーやMDM（モバイルデバイス管理）を通じた配置の標準化ができるようになる可能性があり、Windows 11移行を後押しする要因にもなり得る。 今後の展開に注目 MicrosoftはWindows 11の使い勝手に関するフィードバックを継続的に収集しており、このタスクバー移動機能もその成果のひとつといえる。正式な提供開始時期は未定だが、Windows Insiderプログラムを通じて近々テストが行われる見通しだ。最新情報はMicrosoft公式ブログやWindows Insider Blogで随時確認したい。 元記事: Windows 11 is getting movable taskbar, and Microsoft revealed an early look at it

Apple、創業50周年を多彩な企画で祝福 1976年4月1日にスティーブ・ジョブズ、スティーブ・ウォズニアック、ロナルド・ウェインの3人がガレージで立ち上げたAppleが、2026年4月1日についに創業50周年を迎えた。半世紀で世界最大級のテクノロジー企業へと成長したAppleは、この節目を記念してさまざまな形で祝賀イベントを展開している。 従業員への特別ギフト配布 Appleは社内の従業員に向けて特別な記念ギフトを配布した。過去にも節目の周年でカスタムアイテムやボーナスを贈った実績があり、今回も従業員への感謝を形にした施策の一つとなっている。 ティム・クックとアリシア・キーズが登場するライブイベント CEOのティム・クックと、グラミー賞受賞アーティストでAppleの「グローバル・クリエイティブ・ディレクター」としても知られるアリシア・キーズ（Alicia Keys）が共に登場するライブショーが開催された。アリシア・キーズは2013年からAppleとの関係を深めており、同社のクリエイティブ戦略に長年関与してきた人物だ。 半世紀の歩みを振り返る Appleの50年間は、パーソナルコンピュータの普及（Apple II・Macintosh）から始まり、iPodによる音楽業界の変革、iPhoneによるスマートフォン市場の創造、そして近年のApple SiliconやApple Intelligenceによる独自チップ・AI戦略へと続く革新の連続だった。日本市場においても、iPhoneのシェアは長年にわたり首位を維持しており、Apple製品は生活インフラとして深く根付いている。 創業から50年、Appleは次の半世紀に向けて空間コンピューティング（Vision Pro）や生成AIの統合をはじめとする新たな挑戦を続けている。 #Apple50 元記事: Here’s how Apple is celebrating its 50th birthday

Chrome 148で動画・音声のネイティブ遅延読み込みが実現へ GoogleのChromiumプロジェクトに、<video>と<audio>要素のネイティブな遅延読み込み（lazy loading）機能が追加される見通しとなった。EdgeやVivaldiなど、Chromiumベースのブラウザ全般に影響するこの変更は、Chrome 148での安定版リリースが視野に入っている。 遅延読み込みとは 遅延読み込みとは、ページを開いた瞬間にすべてのリソースを取得するのではなく、ユーザーの画面に映るタイミングで初めてリソースを読み込む手法だ。画像や<iframe>については、HTMLにloading="lazy"属性を記述するだけでブラウザがネイティブに対応してきたが、動画や音声はその対象外だった。 そのため、多くのサイトではIntersectionObserverなどを使ったJavaScriptで代替実装を行っていた。しかしこの方法には課題がある。ブラウザが持つ「プリロードスキャナー」との統合が難しく、実装が複雑になりやすい。 開発者による提案がChromiumへ この問題を解決したのが、Chromiumへの貢献で知られる独立開発者のHelmut Januschka氏だ。同氏はChrome Statusへの投稿の中で次のように説明している。 「ネイティブサポートがないため、開発者はIntersectionObserverを使ったカスタムJavaScriptを実装して、メディア要素がビューポートに入るタイミングを検出し、動的にsrc属性を設定しなければなりません。このアプローチはエラーが起きやすく、複雑性を増し、ブラウザのプリロードスキャナーとも統合できません。」 同氏の提案では、<img>や<iframe>と同様に、<video loading="lazy">や<audio loading="lazy">という形でHTMLに直接記述できるようになる。これにより、以下のメリットが生まれる。 ネットワーク状況に応じたしきい値の最適化：ブラウザが通信環境を考慮して読み込みタイミングを調整 autoplayやpreload属性との適切な連携：既存の動画制御属性とも整合的に動作 window.onloadのブロック回避：画面外のメディアがページ全体の読み込み完了を妨げなくなる データ通信量の削減：スクロールしない限り動画を取得しないため、特にモバイル環境で有効 リリースの現状 Chromiumでの実装は2026年1月に開始され、2月に変更がマージ、3月末にはshippingプロセスへ移行した。現在は安定版ビルドでデフォルト有効化するためのCLが提出されており、Chrome 148での正式リリースが濃厚とされている。 日本でもChrome・Edgeは圧倒的なシェアを持つだけに、ウェブサイトのパフォーマンス改善という観点で注目したい機能追加といえる。特にメディアリッチなコンテンツを配信するサービスにとって、JavaScriptの削減とページ速度向上の両立が実現しやすくなる。 元記事: Google Chrome’s new native video and audio lazy loading could make the web faster

TrueConf のゼロデイ脆弱性を悪用した攻撃キャンペーン「TrueChaos」が発覚 ビデオ会議プラットフォーム「TrueConf」のサーバーを標的とするゼロデイ攻撃キャンペーンが、セキュリティ企業 Check Point の調査で明らかになった。攻撃者はオンプレミス版の TrueConf サーバーを掌握することで、接続しているすべてのクライアント端末に任意の実行ファイルを偽アップデートとして配布できる。 脆弱性の概要（CVE-2026-3502） 今回悪用された脆弱性は CVE-2026-3502 として追跡されており、深刻度は「中（Medium）」に分類される。原因はソフトウェアのアップデート機構における整合性チェックの欠如だ。クライアントがサーバーから提供されるアップデートパッケージを無検証で信頼するため、攻撃者がサーバーを制御できれば正規アップデートを悪意あるファイルに差し替えて全クライアントに展開できてしまう。 影響を受けるバージョンは 8.1.0〜8.5.2。ベンダーは Check Point の報告を受けて 2026年3月に バージョン 8.5.3 で修正を公開しており、同バージョンへの更新が推奨される。 TrueConf は自己ホスト型（オンプレミス）でも運用できるビデオ会議基盤で、クラウド非接続の閉域環境向けにも設計されている。ベンダーによると、新型コロナウイルスのパンデミック期間中に10万社以上が導入し、軍・政府機関・石油ガス企業・航空管制機関などセキュリティ要求の高い組織が多数含まれる。 攻撃キャンペーン「TrueChaos」の実態 Check Point が「TrueChaos」と命名したこのキャンペーンは、2026年初頭から東南アジアの政府機関を標的に展開されている。攻撃者は政府が一元管理する TrueConf サーバーへのアクセスを確保した後、偽アップデートを通じて複数の政府機関にマルウェアを一斉配布した。 感染チェーンには以下の手法が組み合わされている： DLL サイドローディングによる初期侵入 tasklist・tracert などの偵察ツールの実行 iscicpl.exe を悪用した UAC バイパスによる権限昇格 永続化機構の確立 最終ペイロードの回収には至らなかったが、ネットワークトラフィックの解析から Havoc C2 フレームワークが使用された可能性が高いとされる。Havoc はオープンソースの C2 フレームワークで、コマンド実行・プロセス管理・Windows トークン操作・シェルコード実行など多彩な機能を持ち、過去に中国系脅威クラスター「Amaranth Dragon」も類似の標的に対して利用している。 攻撃者帰属の分析 Check Point は TTPs（戦術・技術・手順）の類似性、および C2 インフラに Alibaba Cloud と Tencent Cloud が使用されていること、標的の属性などを根拠に、中国系の脅威アクターが関与している可能性が中程度（moderate confidence）あると判断している。 侵害の痕跡（IoC） 感染の強い指標として、以下のファイルやアーティファクトが確認された場合は直ちに調査が必要だ： poweriso.exe または 7z-x64.dll の存在 %AppData%\Roaming\Adobe\update.7z iscsiexe.dll 対策 TrueConf をオンプレミスで運用している組織は、早急に バージョン 8.5.3 へのアップデートを適用することが強く推奨される。特に政府機関・重要インフラ事業者においては、C2 通信の監視や上記 IoC の有無の確認も併せて実施すべきだろう。 ...

Apple、iOS 18.7.7の提供範囲を拡大——DarkSword攻撃への防御を強化 Appleは2026年4月1日、iOS 18系統の最新セキュリティアップデート「iOS 18.7.7」を従来より大幅に多くのデバイスへ提供開始した。この更新の目的は、現在活発に悪用されているエクスプロイトキット「DarkSword（ダークソード）」からユーザーを守ることにある。 DarkSwordとは何か 2026年3月、Lookout・iVerify・Google Threat Intelligence（GTIG）の研究者らが、iOS 18.4から18.7を搭載するiPhoneを標的にした新たなエクスプロイトキット「DarkSword」を公開した。このキットは6件の脆弱性（CVE-2025-31277、CVE-2025-43529、CVE-2026-20700、CVE-2025-14174、CVE-2025-43510、CVE-2025-43520）を連携させて悪用するもので、従来のiOSエクスプロイトが特定人物への高度標的型攻撃に使われていたのとは異なり、広範な攻撃に活用されている点が特徴だ。 攻撃に関与した主体としては、トルコの商業的監視ベンダー「PARS Defense」、脅威グループ「UNC6748」、ロシア系スパイグループと見られる「UNC6353」が確認されている。被害デバイスには、JavaScriptベースの情報窃取マルウェア「GhostBlade」、バックドア「GhostKnife」、コード実行・データ窃取が可能な「GhostSaber」の3種が展開された。 iOS 18ユーザーが直面していた問題 2025年後半、AppleはiOS 26に対応した新型デバイスへのiOS 18アップデート提供を段階的に終了した。iOS 18に留まることを選んだユーザーは、セキュリティパッチを受け取れないデバイスが増える事態となり、2026年に公開されたDarkSword関連の脆弱性修正は一部の旧機種（iPhone XS/XS Max/XR）にしか届かなくなっていた。 さらに状況を悪化させたのが、先月あるセキュリティ研究者がDarkSwordエクスプロイトキットをGitHubで公開したことだ。これにより、他の攻撃者も旧型iPhoneを容易に標的にできる状況となってしまった。 iOS 18.7.7の対応範囲 今回のアップデートにより、以下のデバイスがiOS 18.7.7を受け取れるようになった。 iPhone XR / XS / XS Max iPhone 11（全モデル） iPhone SE（第2世代・第3世代） iPhone 12 / 13 / 14 / 15 / 16（全モデル） iPhone 16e iPad mini（第5世代 A17 Pro）、iPad（第7世代 A16） iPad Air（第3〜第5世代、11インチ M2/M3、13インチ M2/M3） iPad Pro 11インチ（第1世代〜M4）、12.9インチ（第3〜第6世代）、13インチ（M4） 「自動アップデート」を有効にしているiOS 18ユーザーは、このアップデートを自動受信する。 日本のユーザーへの影響 iOS 26への移行を見送ってiOS 18系統を使い続けているユーザーは、今すぐ「設定」→「一般」→「ソフトウェアアップデート」からiOS 18.7.7を適用することを強く推奨する。DarkSwordエクスプロイトキットはすでに公開されており、攻撃の敷居は大幅に下がっている。自動アップデートの設定確認も合わせて行っておきたい。 元記事: Apple expands iOS 18 updates to more iPhones to block DarkSword attacks ...

新種マルウェア「CrystalRAT」が登場——遠隔操作・情報窃取・嫌がらせ機能を一体化したMaaS カスペルスキーの研究チームは2026年4月1日、Telegram上で販売促進されている新しいマルウェア・アズ・ア・サービス（MaaS）「CrystalRAT」（別名：CrystalX）の詳細レポートを公開した。2026年1月に初めて確認されたこのマルウェアは、階層型のサブスクリプションモデルを採用しており、専用のYouTubeチャンネルを通じてその機能を動画でアピールするなど、従来の地下マーケット販売とは異なるマーケティング戦略を展開している点が注目される。 WebRATとの強い類似性 カスペルスキーによると、CrystalRATはWebRAT（Salat Stealer）と多くの共通点を持つ。具体的には、同一のコントロールパネルデザイン、Go言語ベースのコード構造、ボット形式の販売システムが一致しており、同一開発者または同一グループによる派生マルウェアである可能性が示唆されている。 主な機能 遠隔操作（RAT）機能 CMDによるコマンド実行、ファイルのアップロード・ダウンロード、ファイルシステムの閲覧、組み込みVNC（Virtual Network Computing）によるリアルタイム画面制御が可能。マイクからの音声・映像キャプチャも備え、スパイウェアに近い動作を示す。 情報窃取（インフォスティーラー）機能 Chromiumベースのブラウザ（ChromeElevatorツール経由）、Yandex、Operaを標的とするほか、Steam、Discord、Telegramなどのデスクトップアプリからもデータを収集する。なおカスペルスキーの調査時点では、アップグレード準備中として一時的に無効化されていた。 キーロガーとクリッパー キーストロークをリアルタイムでC2（コマンド＆コントロール）サーバーに送信するキーロガーと、クリップボード内の暗号資産ウォレットアドレスを正規表現で検出して攻撃者のアドレスに差し替えるクリッパー機能も実装されている。 技術的な防御回避 生成されるペイロードはzlib圧縮後、ChaCha20ストリーム暗号で暗号化される。C2との通信にはWebSocketを使用し、アンチデバッグ・仮想マシン検出・プロキシ検出といったアンチ解析機能も備える。また、ジオブロッキングや実行ファイルのカスタマイズも可能なビルダーツールが提供されており、攻撃者が用途に応じてペイロードを柔軟に調整できる。 「いたずら」機能でスクリプトキディを取り込む戦略 CrystalRATが他のMaaSと一線を画すのが、豊富な「プランクウェア（嫌がらせソフト）」機能だ。感染端末に対して以下の操作が可能となっている。 デスクトップの壁紙変更 ディスプレイの向きを任意の角度に変更 システムの強制シャットダウン マウスボタンの再マッピング キーボード・マウス・モニターの入力デバイス無効化 偽の通知表示・カーソル位置の操作 デスクトップアイコン、タスクバー、タスクマネージャー、コマンドプロンプトの非表示 攻撃者と被害者のチャットウィンドウ表示 こうした「いたずら」機能は直接的な金銭的利益に貢献しないが、スクリプトキディ（技術力の低い初心者攻撃者）を引き付けるブランド差別化戦略と分析される。また、情報窃取モジュールがバックグラウンドで動作する間の目くらましとして機能する可能性もある。 対策 カスペルスキーは、信頼できないソースからのソフトウェアやメディアのダウンロードを避け、オンラインコンテンツとのやり取りに慎重を期すよう呼びかけている。日本国内でも暗号資産取引やSteam・Discordの利用が広く普及していることから、今後の国内被害にも注意が必要だ。 元記事: New CrystalRAT malware adds RAT, stealer and prankware features

NASAアルテミスII、有人月面フライバイミッションに成功裏に出発 NASA（米航空宇宙局）は、有人月周回ミッション「アルテミスII（Artemis II）」の打ち上げに成功した。アポロ計画以来、約半世紀ぶりとなる有人深宇宙探査の再開として、宇宙開発史上の重要な節目となる。 ミッションの概要 アルテミスIIは、NASAの次世代有人宇宙船「オリオン（Orion）」と、世界最大の打ち上げロケット「SLS（Space Launch System）」を用いた有人月フライバイミッション。2022年に無人で実施されたアルテミスIの成功を受け、今回は初めて宇宙飛行士を乗せての飛行となる。 月への有人フライバイ（月周回軌道には入らず月の近傍を通過する軌跡）を経て、地球に帰還する計画であり、将来の月面着陸ミッション「アルテミスIII」に向けた重要な技術検証の位置づけを持つ。 記録的なクルー編成 今回のミッションには多様な背景を持つ宇宙飛行士が搭乗しており、複数の「初」記録を持つクルーとして注目されている。カナダ人宇宙飛行士の参加も含め、国際的な宇宙探査協力の象徴ともなっている。 アルテミス計画の位置づけ アルテミス計画は、2030年代の火星探査を見据えた長期的な有人宇宙探査ロードマップの一環。月を「深宇宙への中継地点」として活用し、持続可能な宇宙開発基盤の構築を目指している。日本もJAXA（宇宙航空研究開発機構）を通じてアルテミス計画に参加しており、将来の日本人宇宙飛行士による月面着陸も計画に含まれている。 アルテミスIIのスプラッシュダウン（着水帰還）は今後数日以内に予定されており、NASAは引き続きミッションの進捗を公式チャンネルで配信している。 今後の展望 アルテミスIIの成功はアルテミスIIIへの道を開くものであり、同ミッションでは女性宇宙飛行士および有色人種の宇宙飛行士による初の月面着陸が計画されている。人類の宇宙進出が新たな章へと進む中、今回の打ち上げ成功はその大きな一歩といえる。 元記事: NASA’s Artemis II successfully launches on historic lunar flyby mission

Google DriveのAIランサムウェア検知がデフォルト有効化 Googleは2026年4月1日、Google DriveのAI搭載ランサムウェア検知機能が正式提供（GA）に達し、有料ユーザー向けにデフォルトで有効化されたと発表した。 ベータから正式版へ この機能は2025年9月に発表され、同年10月初旬からGoogle Workspaceの顧客向けにベータ版の展開が始まった。今回の正式リリースにより、ビジネス・エンタープライズ・教育・フロントラインの各ライセンスを持つ組織のすべてのユーザーが対象となる。 仕組みと保護範囲 機能が有効な状態では、デスクトップ端末からDriveへファイルが同期される際にランサムウェアのスキャンが行われる。暗号化されたファイルが検出された場合、デスクトップの同期が即座に停止され、以下の通知が発報される。 対象ユーザーへのメールアラート Google Driveアプリ内の通知 Google管理コンソールへのアラート作成 注意点として、ローカルPC上のファイルの暗号化そのものは防げないが、Drive上に保存されたドキュメントは保護され、マルウェア除去後に迅速な復元が可能となる。攻撃後は「Driveの復元ツール」を使った詳細な復旧手順も提供される。 AI強化で検知能力が14倍に Googleは「ベータ時と比較して、より多くの種類のランサムウェア暗号化を、より高速に検知できるようになった。最新のAIモデルにより、感染検知数が14倍に向上した」と述べており、包括的な保護の強化をアピールしている。 ファイル復元機能の対象範囲 ファイル復元機能については、より広いユーザー層が利用可能だ。 対象 利用可否 全Google Workspaceカスタマー ○ Workspace個人サブスクライバー ○ 個人Googleアカウントユーザー ○ 管理者向け設定 管理者が組織全体で機能をオフにしたい場合は、管理コンソールの「アプリ > Google Workspace > DriveとドキュメントのSettings > マルウェアとランサムウェア」から無効化できる。 検知アラートを活用するには、エンドポイントにGoogle Drive for Desktop v.114以降のインストールが必要。ただし旧バージョンでも同期の一時停止機能は動作する。 クラウドストレージ各社の対応状況 類似の保護機能はGoogle Drive固有ではない。Microsoft 365サブスクライバー向けのOneDriveや、DropboxのBusiness Plus・Advanced・Enterpriseプランでも同様の検知・復元機能が提供されており、主要クラウドストレージ全体でランサムウェア対策の標準化が進んでいる。 ランサムウェア攻撃は日本国内の企業・教育機関でも被害が相次いでいる。クラウドバックアップと組み合わせたこうした自動検知機能は、実質的な被害を最小化する有効な手段として注目される。 元記事: Google Drive ransomware detection now on by default for paying users

OpenAIが史上最大規模の資金調達を完了、評価額は約125兆円に ChatGPTを擁するAI企業OpenAIが、1220億ドル（約18兆円）という前例のない規模の資金調達ラウンドを完了したと発表した。これにより同社の企業評価額は8520億ドル（約125兆円）に達し、世界でも有数の巨大企業へと躍進した。 過去最大を大幅に更新 今回の調達額は、これまでのテクノロジー企業による資金調達の記録を大きく塗り替えるものだ。昨年OpenAI自身が記録した約660億ドルの調達を大幅に上回り、生成AI分野への投資熱が依然として冷めていないことを示している。 調達した資金は、大規模言語モデル（LLM）の研究開発の加速、データセンターなどのインフラ整備、そして世界規模でのビジネス展開に充てられる見通しだ。 AI覇権争いの激化 OpenAIをめぐっては、GoogleのGeminiシリーズ、MetaのLlamaシリーズ、そして中国発のDeepSeekなど、強力な競合が次々と台頭している。今回の資金調達は、こうした競争環境においてOpenAIが技術的・事業的優位性を維持するための「弾薬補充」とも言える。 日本市場においても、SoftBankがOpenAIへの大型出資を発表しており、両社は日本国内でのAIインフラ整備に向けた協力関係を深めている。今回のラウンドにSoftBankが参加しているかどうかは現時点で明らかになっていないが、引き続き注目される。 非営利から営利へ——転換期のOpenAI OpenAIはもともと非営利団体として設立されたが、現在は営利事業部門を中心とした組織再編を進めている。今回の大規模調達は、同社が完全な営利企業体制へと移行するプロセスを加速させるものとみられ、IPO（新規株式公開）への布石という見方もある。 Sam Altman CEOは過去のインタビューで「AGI（汎用人工知能）の実現には膨大な計算資源と投資が必要だ」と繰り返し語っており、今回の調達はその壮大な目標に向けた現実的な一手といえる。 生成AIが産業・社会に与える影響が日々拡大するなか、OpenAIの動向は今後も世界中の企業・研究者・政策立案者から注視され続けるだろう。 元記事: OpenAI becomes a $852 billion giant with record-breaking $122B funding round