Windows

毎月第2火曜日、Microsoftが月例セキュリティ更新プログラム「パッチチューズデー」をリリースする。2026年4月分は過去最大級の規模で、合計167件の脆弱性に対処。うち2件がゼロデイ脆弱性、8件がCritical（緊急）に分類された。特にSharePoint Serverで悪用済みゼロデイが報告されており、オンプレミス環境を運用している組織は今すぐ動く必要がある。 今月のパッチ概要：167件の規模感を理解する 修正件数の内訳を確認しておこう。 カテゴリ 件数 特権昇格（EoP） 93件 情報漏洩 21件 リモートコード実行（RCE） 20件 セキュリティ機能のバイパス 13件 サービス拒否（DoS） 10件 なりすまし（Spoofing） 9件 EoP（Elevation of Privilege）が93件と突出して多いのが今月の特徴だ。これはアプリ内での権限昇格を可能にする脆弱性であり、それ単体でシステムを乗っ取れるわけではないが、他の脆弱性と組み合わせた攻撃チェーンとして悪用されるケースが多い。「別の脆弱性から侵入→EoP脆弱性で管理者権限取得」という流れは典型的な攻撃パターンであり、EoPを軽視してはならない。 なお、この167件にはAzure、Bing、Marinerのパッチは含まれていない。Microsoft Edge（Chromium）も別途80件のパッチがGoogleから提供されており、ブラウザ管理も忘れずに。 ゼロデイ詳細：SharePointとDefender、それぞれの対応方針 CVE-2026-32201：SharePoint Serverのなりすまし脆弱性（悪用確認済み） 最も緊急度が高いのがこちらだ。SharePoint Serverにおける不適切な入力検証により、未認証の攻撃者がネットワーク越しにSpoofing（なりすまし）を実行できる。具体的な被害としては、機密情報の閲覧および情報の改ざんが可能とされている（可用性への影響はなし）。 すでに実際の攻撃への悪用が確認されているにもかかわらず、Microsoftは悪用手法や報告者の詳細を開示していない。こういった情報の非公開には賛否があるが、攻撃者にヒントを与えないという観点では理解できる判断でもある。 対応方針：SharePoint Serverをオンプレミスで運用している組織は今すぐパッチを適用すること。SharePoint Onlineを利用しているSaaS環境ではMicrosoft側で対応済みだが、ハイブリッド構成やオンプレミス環境は手動での確認が必須だ。 CVE-2026-33825：Microsoft Defenderの特権昇格脆弱性（一般公開済み） Defender Antimalware Platformに存在するEoP脆弱性で、悪用に成功するとSYSTEM権限を奪取される。こちらは悪用は未確認だが、詳細がすでに一般公開されているため、攻撃コードの開発・悪用化がいつ始まってもおかしくない状況だ。 修正はDefender Antimalware Platform バージョン 4.18.26050.3011 で提供される。通常は自動更新されるが、管理環境や閉域網ではWindows Security → ウイルスと脅威の防止 → 保護の更新から手動確認を。発見者はZen DoddおよびYuanpei XU氏（HUST）とされており、大学研究者による脆弱性発見という点でも注目される。 Office RCE：プレビュー表示するだけで危ない 今月はWordとExcelにリモートコード実行（RCE）の脆弱性も複数修正されている。特に問題なのが「プレビューペインでの実行が可能」という点だ。つまり、添付ファイルを開く前、メール一覧でファイルをクリックしただけで悪意あるコードが実行される可能性がある。 外部からのメールを日常的に受け取る業務環境では、こうしたOfficeのRCE脆弱性は特に危険だ。Microsoft Officeのアップデートを優先的に確認しよう。 他社パッチとの「合わせ技」に注意 4月は他ベンダーも大型パッチを同時リリースしている。 Adobe：Illustrator、Reader、Acrobat、Photoshop等でゼロデイを含む修正。Adobe Reader/Acrobatのゼロデイは悪用確認済みであり、PDFを開くだけで感染するリスクがある Apache ActiveMQ Classic：13年間検出されなかったRCE脆弱性が修正。長期稼働の基盤ソフトウェアが潜在的な爆弾を抱えていた事実は重い Cisco：Integrated Management ControllerにAdmin権限奪取可能な認証バイパス Fortinet、Apple：それぞれ複数製品に重大パッチ 単一ベンダーだけを見ていると漏れが生じる。特にAdobe製品は企業内での普及率が高く、Reader/Acrobatのゼロデイは明日のインシデントに直結しうる。 実務への影響：IT管理者が今すぐすべきこと 優先度：高（今週中） SharePoint Server（オンプレミス）へのパッチ適用確認 — 悪用済みゼロデイのため最優先 Microsoft Officeのアップデート確認 — RCEがプレビューペインで発火するため見落とし注意 Microsoft DefenderのAntimalware Platformバージョン確認 — 閉域・管理ネット環境では自動更新が機能していない場合がある Adobe Reader/AcrobatのパッチとChromium系ブラウザの更新 — ゼロデイ悪用済みにつき即時対応 継続的な管理として ...

教育コンテンツ大手のMcGraw-Hillが、Salesforceの設定ミス（misconfiguration）に起因するデータ侵害を公式に認めた。同社は「侵害はSalesforceプラットフォーム上でホストされていたウェブページの限定的なデータへのアクセスにとどまり、顧客データベースや内部システムには影響していない」と説明しているが、この発表自体が問題の本質を見誤っている可能性がある。 何が起きたか 攻撃者はMcGraw-HillのSalesforce環境内の設定ミスを悪用し、内部データへの不正アクセスに成功した。悪名高い恐喝グループ「ShinyHunters」は自らのダークウェブポータルでMcGraw-Hillを被害者として公開し、4月14日までに身代金を支払わなければ4500万件ものSalesforceレコードを公開すると脅迫。同社の声明内容とは真っ向から矛盾する主張をしている。 今回の件はMcGraw-Hillだけの問題ではない。同社の声明には「Salesforce環境内の設定ミスに起因する、複数組織に影響を与えた広範な問題の一部」という記述があり、この設定ミスが連鎖的に他組織にも波及している可能性を示唆している。ShinyHuntersはすでに同様の手口でRockstar Games、欧州委員会、Panera Breadなど多数の組織への侵害を確認しており、2026年に入ってからの活動は特に活発化している。 なぜこれが重要か SaaSを使えば自社インフラの管理から解放されると思い込んでいる組織は多い。しかし今回の事例が示すのは、SaaSを使うことで「設定責任」が消えるわけではないという厳しい現実だ。 Salesforceのような大規模SaaSは非常に柔軟な設定が可能な反面、その柔軟さが「設定ミスの温床」にもなりうる。権限の過剰付与、公開設定になっているエンドポイント、不要なデータの残存——こうした「静かなリスク」は、誰かが攻撃を試みるまで気づかれないことがほとんどだ。 さらに重要なのは、被害組織の多くが「自分のSalesforceアカウントに問題はない」と思っていた点だ。SaaSベンダーのプラットフォームレベルの設定ミスであっても、テナントのデータは侵害されうる。ここに「共有責任モデル」の落とし穴がある。 実務での活用ポイント Salesforce利用組織が今すぐ確認すべきこと Guest Userの権限を棚卸しする: Salesforceの設定ミスの多くは、認証不要のゲストアクセスに対して過剰な権限が与えられていることに起因する。Salesforce Security Health Checkを実行し、スコアを確認する 公開エンドポイントの棚卸し: Experience Cloud（旧Community Cloud）などで外部公開しているページが適切なアクセス制御下にあるかを確認する データ分類とアクセス制御の見直し: どのデータがどのユーザー・プロファイルから見えているかを定期的にレビューする仕組みを作る NHI（Non-Human Identity）の権限管理: Salesforceに接続しているAPIユーザー、統合アカウント、サービスアカウントの権限は最小権限の原則に基づいているか確認する。常時フルアクセスを付与したままのインテグレーション設定は今すぐ見直すべきだ 筆者の見解 「SaaSだから安全」という神話はもう捨てていい。SaaSに移行した組織の多くが、セキュリティ責任もベンダーに丸投げできると誤解しているが、現実にはクラウドの設定責任は常に利用者側にある。 今回の侵害は、ShinyHuntersが「Salesforceの設定ミスを組織横断的に探索している」可能性を示唆している。つまり、特定の組織を狙った標的型攻撃ではなく、設定ミスのある環境を自動的にスキャンして侵入機会を探すという手口だ。これは防御側にとって非常に厄介で、「自分の組織は関係ない」という楽観は通用しない。 NHI（サービスプリンシパル、インテグレーションユーザーなど）の権限管理は、業務自動化の観点からも急務だ。人間の関与を減らして自動化を推進するためにはNHIを正しく使う必要があるが、その管理が雑だと今回のような事件に直結する。「動いているから問題ない」ではなく、「攻撃者の視点で設定を見直す」習慣が、日本のIT現場にもいよいよ必要な時代になっている。 Salesforceを利用している組織は、今週中にSecurity Health Checkを走らせることを強くお勧めする。 出典: この記事は McGraw-Hill confirms data breach following extortion threat の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年4月のPatch Tuesdayに合わせ、MicrosoftがWindows 10向け拡張セキュリティ更新プログラム（ESU）KB5082200をリリースした。今回の更新は単なる月例パッチにとどまらず、RDPファイルを悪用したフィッシング攻撃への新たな防御機構と、Secure Boot証明書の移行状況を可視化する新機能が含まれている点で注目に値する。 167件の脆弱性修正、うちゼロデイは2件 今月のPatch Tuesdayでは全体で167件の脆弱性が修正された。このうち2件はゼロデイ脆弱性——すなわち、パッチ公開時点ですでに攻撃者に悪用されているか、概念実証コード（PoC）が公開されている脆弱性だ。 KB5082200の適用後、Windows 10はビルド19045.7184、Windows 10 Enterprise LTSC 2021は19044.7184に更新される。 あわせて、3月10日以降の更新適用後にMicrosoftアカウントでのサインインが失敗する問題（「インターネット接続なし」エラーが誤表示される）も修正された。TeamsなどのMicrosoft製サービスが突然使えなくなったという報告が相次いでいたが、本更新でようやく解消される。 RDPファイルフィッシング：見落とされがちな攻撃ベクター 今回の更新で特に実務面での影響が大きいのが、Remote Desktop（RDP）ファイルへの新たなフィッシング対策だ。 攻撃者が .rdp ファイルを添付したフィッシングメールを送りつけ、被害者が誤って開いてしまうと、悪意のある接続設定が自動適用されてしまう——この手口はここ数年で急増している。新しい保護機能では、.rdp ファイルを開く際にすべての接続設定を事前表示し、各設定はデフォルトでオフの状態になる。また、デバイス上で初めて .rdp ファイルを開いた際には一度限りのセキュリティ警告も表示される。 「ダブルクリックしたら知らないサーバーに繋がっていた」という状況を防ぐ、シンプルながら効果的な変更だ。テレワーク環境でRDPを多用している現場では、この変更によるUI変化を事前にユーザーへ周知しておくことを推奨する。 Secure Boot証明書の移行：2026年6月期限に注意 もうひとつの重要な変更がSecure Boot証明書の更新対応だ。2011年に発行された古い証明書が2026年6月に失効するため、Microsoftは段階的に新しい証明書への移行を進めている。 KB5082200では、Windows セキュリティアプリ（設定 → 更新とセキュリティ → Windowsセキュリティ）から証明書の移行ステータスをリアルタイムで確認できるようになった。ただし、この機能は商用デバイスおよびサーバーではデフォルト無効となっているため、管理者が意識的に有効化または確認作業を行う必要がある。 また、Intel製Connected Standby対応デバイスでSecure Boot更新後にBitLockerリカバリー画面に入ってしまう長年の問題も本更新で修正されている。この現象に悩まされてきた管理者にとっては朗報だ。 実務への影響 IT管理者・エンジニアが今すぐ確認すべきこと： 適用対象の確認: KB5082200の対象はWindows 10 Enterprise LTSC、またはESUプログラムに加入しているデバイスのみ。通常のWindows 10サポート終了（2025年10月）を迎えた環境では別途ESUライセンスが必要 RDP運用ポリシーの見直し: .rdp ファイルを配布・共有している環境では、新しいUI挙動（設定の事前確認ダイアログ）がユーザー混乱を招く可能性がある。事前の案内と簡単なマニュアル更新を推奨する Secure Boot証明書の期限管理: 2026年6月失効を見据え、大規模フリートを抱える環境では段階的な適用計画を今から立てておく。Windows Security Appでのステータス確認機能を積極活用したい Microsoftアカウントサインイン問題の解消確認: 3月以降にTeams等でサインインエラーが発生していた環境は、本更新で解消されるか検証する 筆者の見解 Windows 10のESUプログラムが延長されたことで「まだしばらく使える」という選択をした組織は少なくない。ただ、今回のような月例更新を見るたびに感じるのは、セキュリティ対応の持続コストが確実に上昇しているという現実だ。 RDPフィッシングへの対策が今さらプラットフォームレベルで必要になっていること自体、現場の運用が追いついていない証左でもある。本来であれば、.rdp ファイルをメールで配布するような運用はゼロトラストの観点からも見直すべきで、アクセス制御の中心をネットワーク境界からIDと条件付きアクセスポリシーへ移行していく流れが正しい方向だ。 Secure Boot証明書の2026年6月失効については、今から動かないと夏に焦る案件の典型。大規模フリートを管理する担当者は、今月のうちに移行状況の把握を始めておくことを強く勧める。 Windows Updateについては最近「すぐに当てたら壊れた」という報告も耳に入る。数日様子を見てから適用するという判断も、状況によっては合理的だ——ただし、ゼロデイが含まれている月は話が別。今月は2件のゼロデイが修正対象に含まれている以上、ESU対象環境では速やかな適用を優先してほしい。 出典: この記事は Microsoft releases Windows 10 KB5082200 extended security update の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

公式ストアが「安全」という常識は、もう通用しない。アプリケーションセキュリティ企業Socketの調査により、Chrome Web Storeに100本を超える悪意ある拡張機能が存在し、Google OAuth2 Bearerトークンの窃取、バックドアの設置、広告詐欺を組織的に行っていることが明らかになった。ユーザーが「公式ストアにある」という理由でインストールしたものが、実は情報窃取ツールだった——という事態が、今まさに現実として広がっている。 キャンペーンの全体像：5つの顔を持つ脅威アクター Socketが発見したこのキャンペーンは、単発の悪性拡張機能ではなく、単一のC2（コマンド＆コントロール）インフラを共有する組織的な作戦だ。脅威アクターは5つの異なる公開者IDを使い分け、以下のカテゴリに偽装して拡張機能を公開した。 Telegramのサイドバークライアント スロットマシン・ケノゲームなどのギャンブル系ゲーム YouTubeおよびTikTokの機能拡張ツール テキスト翻訳ツール 汎用ユーティリティ 一見すると「便利な日常ツール」の体裁を装いながら、バックエンドではContabo社のVPS上にC2サーバーを構え、複数のサブドメインでセッション乗っ取り・身元情報収集・コマンド実行・収益化の各オペレーションを管理している。コード内のコメントから、ロシア系のMaaS（Malware-as-a-Service）オペレーションである可能性が高いと分析されている。 3種類の攻撃手法：それぞれの危険度 1. innerHTML注入による78本のクラスター 最大のグループは、innerHTMLプロパティを悪用して攻撃者が制御するHTMLをブラウザのUIに挿入する。フィッシングページの埋め込みや、正規サイトを装ったクレデンシャル詐取に応用できる手口だ。 2. chrome.identity.getAuthTokenによる54本のクラスター chrome.identity.getAuthToken APIを使い、被害者のメールアドレス・氏名・プロフィール画像・GoogleアカウントIDを収集する。さらにGoogle OAuth2 Bearerトークンを窃取する。このトークンは、Googleサービス全体へのアクセスを一時的に許可する鍵であり、奪われれば正規ユーザーとして成りすましてGmail・Drive・Calendarなどを操作される可能性がある。 3. バックドア型の45本：ユーザー操作不要で発動 最も静かで危険なグループは、ブラウザ起動時に自動実行される隠し関数を持つ。ユーザーが何も操作しなくてもC2からコマンドを受け取り、任意のURLを開くことができる。 4. Telegramセッション完全乗っ取り（最重大） Socketが「最も深刻」と位置づける拡張機能は、15秒ごとにTelegram Webのセッション情報を窃取する。localStorageからセッションデータとTelegramセッショントークンを抜き取り、C2に送信するのみならず、逆方向の操作——被害者のlocalStorageを攻撃者が指定したデータで上書きし、Telegramを強制リロードすることで、被害者のブラウザを別のTelegramアカウントに切り替えられる。被害者は気づかぬまま、自分のブラウザが攻撃者のアカウントとして動作する状態に置かれる。 実務への影響：日本のエンジニア・IT管理者が取るべき行動 すぐに確認すべきこと： Socketが公開した悪性拡張機能のIDリストに対して、自分のChromeにインストール済みの拡張機能を照合し、一致するものは即座にアンインストールする。 組織として対応すべきこと： 拡張機能の許可リスト管理: Google WorkspaceのChrome管理機能（Chrome Enterprise）で、業務上承認された拡張機能以外はインストール禁止にするポリシーを設定する。これが現状で最も確実な防線だ OAuth2トークンのスコープ監視: Google管理コンソールのセキュリティダッシュボードで、不審なサードパーティアクセスが発生していないかを確認する セキュリティヘッダーの状態確認: このキャンペーンにはContent-Security-Policyなどのセキュリティヘッダーを剥ぎ取る拡張機能も含まれる。Webアプリのヘッダーが意図した通りに機能しているか、定期的な検証を Telegramを業務利用している場合: ウェブ版Telegramのセッション管理を強化し、不審なアクティブセッションがないか確認する 今回の事例で特に危険なのは、被害者が何もしなくても攻撃が始まるという点だ。バックドア型の拡張機能はブラウザ起動のたびにC2と通信し、ユーザーのクリックや操作を一切必要としない。エンドポイント保護の視点では、ブラウザ拡張機能はネットワーク上の「未管理のエージェント」として扱うべき時代に来ている。 筆者の見解 「公式ストアにある＝安全」という感覚的な信頼が、今回の根本的な問題だと思う。App StoreであれChrome Web Storeであれ、プラットフォームのレビューには限界があり、100本超が長期間野放しだった事実は、その限界を明確に示している。 ゼロトラストの原則から言えば、拡張機能は「信頼するかどうかを毎回検証する対象」であるべきだ。インストールした時点で一定の信頼を与えたまま忘れてしまうのが最大のリスクで、これはVPNトンネルを「一度つながれば安全」と思うのと構造的に同じ過ちだ。 Non-Human Identity（NHI）管理の文脈でも、OAuth2トークンの取り扱いは重要な論点だ。人間のアカウントに紐づくトークンが拡張機能経由で漏れ出せば、その後の業務自動化フローやAIエージェントが汚染された認証情報を使ってしまうリスクもある。トークンのスコープを最小化し、有効期限を適切に管理し、異常なアクセスパターンを検知する仕組みを整えることが、もはや「理想論」ではなく「実務上の必須要件」になってきている。 結局のところ、「禁止する」だけでは人はツールを使い続ける。組織として業務に必要な拡張機能を把握・承認し、それ以外はポリシーで管理する——という「安全に使える仕組みを作る」アプローチが、セキュリティと利便性を両立する唯一の現実的な道だと考えている。 出典: この記事は Over 100 Chrome extensions in Web Store target users accounts and data の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AmazonがGlobalstar（グローバルスター）の買収を正式に発表した。衛星インターネット事業「Project Kuiper」を推進するAmazonが、既存の衛星通信インフラと周波数ライセンスを持つGlobalstarを手中に収めることで、次世代の「端末直接接続（Direct-to-Device）」衛星コンステレーションの構築を一気に加速させる。 Globalstarとは何者か Globalstarは1999年設立の衛星通信企業で、低軌道（LEO）衛星を活用した音声・データ通信サービスを提供してきた。日本では馴染みが薄いが、Apple iPhoneの「衛星経由の緊急SOS」機能のバックエンドとしてGlobalstarの衛星網が使われており、すでに一般消費者の生活に静かに組み込まれている。 なぜこれが重要か ポイントは「Direct-to-Device（D2D）」という概念だ。これは特殊な衛星端末を用意しなくても、通常のスマートフォンや一般デバイスが直接衛星に接続できる技術を指す。Appleの緊急SOSはその先駆けだが、Amazonが目指すのはそれを常時接続・広帯域のレベルまで引き上げることだ。 Starlinkがアンテナ（Starlink Dish）を前提としているのに対し、D2D衛星コンステレーションは既存の携帯端末をそのまま活用できる。つまり「インフラが届かない場所でも、追加ハードウェアなしにネットワーク接続が維持できる」世界が現実味を帯びてくる。 実務への影響——日本のIT管理者が今考えるべきこと 1. BCP・DR計画の前提が変わる 地震・台風・インフラ障害時のバックアップ通信として、これまでは衛星電話や特殊無線機が選択肢だった。D2D衛星接続が普及すれば、社員の手持ちスマートフォンそのものが非常時の通信手段になりえる。BCP（事業継続計画）の通信要件を見直す時機が来ているかもしれない。 2. ゼロトラストアーキテクチャとの相性 ゼロトラストは「どのネットワークからアクセスするか」ではなく「誰が・何が・何をしようとしているか」で認可を判断する。D2D衛星接続が増えれば、「社内ネットワーク＝安全」という前提はさらに崩れる。一方で、アクセス経路が多様化しても認証・認可が一元管理されていれば問題はない。今からID中心のゼロトラスト基盤を整えておくことが、こういった変化への耐性につながる。 3. NHI（Non-Human Identity）と衛星エッジの組み合わせ 衛星経由で接続するIoTデバイスやエッジコンピューターが増えると、それらのデバイスID管理（マネージドID、サービスプリンシパル）が一層重要になる。人間が関与しない通信フローをいかに安全に自動化するかは、衛星接続の普及とともに避けられない課題だ。 4. 通信コストと契約戦略の見直し AmazonのスケールでGlobalstarを運用することで、衛星通信のコストは長期的に低下する可能性が高い。現時点で衛星通信を「コスト高で現実的でない」と除外している企業も、2〜3年後のコスト試算を今のうちにしておく価値はある。 筆者の見解 Amazonのこの動きは、衛星通信を「ニッチな特殊用途」から「エンタープライズの標準オプション」へと押し上げる転換点になりうると見ている。 注目したいのは、AmazonがProject KuiperとGlobalstarの両方を持つことで、LEO高速インターネット（Kuiper）と広域D2D直接接続（Globalstar）の二刀流を狙っている点だ。単なる競合他社との差別化ではなく、AWS・Amazon Oneのような統合エコシステムの一部として衛星接続を組み込む青写真が見える。 日本のエンタープライズにとっては、今すぐ何かを変える必要はない。ただし「地上インフラだけで通信を完結させる設計」が5年後も最適かどうかは、今から問い直しておいていい。特に地方拠点、インフラの届きにくい現場、そして非常時の通信冗長性を真剣に考えている企業には、この流れは確実に関係してくる。 統合プラットフォームの全体最適という観点で言えば、通信レイヤーも「クラウド＋オンプレ」から「クラウド＋地上回線＋衛星」へと選択肢が広がる時代だ。部分最適ではなく、通信インフラ全体のアーキテクチャを俯瞰した設計が求められている。 出典: この記事は Amazon to acquire Globalstar in major satellite connectivity expansion の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが新たなAI画像モデル「MAI-Image-2-Efficient」を発表した。その名の通り「効率」を前面に押し出したこのモデルは、競合他社のモデルと比較して高いベンチマーク性能を維持しながら、処理速度と運用コストの両面で大幅な改善を実現しているという。大規模プロダクション環境での利用を主なターゲットに据えており、エンタープライズ向けAIインフラの刷新を狙った動きとして注目を集めている。 MAI-Image-2-Efficientとは何か MAIはMicrosoftのAIモデルファミリーを指す名称で、同社がAzureをはじめとするサービス基盤に組み込む形で開発・展開しているシリーズだ。今回の「Efficient」バリアントは、モデルの軽量化・高速推論・低コスト運用という三拍子を追求した設計となっており、従来のフルサイズモデルと同等以上の出力品質を保ちながら、インフラコストを大幅に削減できるとしている。 AI画像生成の分野では、品質と運用コストはしばしばトレードオフの関係にある。ハイエンドのモデルは高品質な画像を生成できるが、推論に必要なGPUコストが膨大になるため、大量リクエストをさばくプロダクション環境では現実的ではないケースも多い。MAI-Image-2-Efficientはこのボトルネックを正面から解消しようとするアプローチであり、エンタープライズ向けAIサービスとしての実用性に軸足を置いている点が特徴だ。 なぜこれが重要か この発表が持つ意味は、単に「安くて速いモデルが出た」という以上のものがある。 まず、Azure AI ServicesおよびCopilot系サービスのバックエンドコスト削減につながる可能性がある。Microsoftが自社サービスにこのモデルを採用すれば、エンドユーザーに提供する画像生成APIの単価引き下げや、処理レイテンシの改善が期待できる。日本企業がAzure OpenAIやCopilotを通じて画像生成ワークフローを構築している場合、コスト構造が変わってくる可能性がある。 次に、大規模プロダクション運用を前提とした設計という点が重要だ。これはPoC（概念実証）フェーズにとどまらず、本番環境で毎日数万〜数百万枚の画像を生成するユースケースを想定している。マーケティング素材の自動生成、ECサイトの商品画像加工、ドキュメント内の図版自動生成など、現実のビジネスフローに組み込むことを本気で考えているメッセージとも受け取れる。 実務での活用ポイント Azure上で画像生成ワークフローを検討しているチームへ MAI-Image-2-EfficientがAzure AI Studioから利用可能になった場合、まず試すべきはコスト比較だ。現在利用しているモデルの1,000枚あたりの単価と比較して、品質を許容できる範囲でどこまで圧縮できるかを計測することが先決となる。品質を最大化したいケースにはフルモデルを、大量バッチ処理にはEfficientバリアントを使い分けるハイブリッド構成が現実的なアプローチになるだろう。 IT管理者・アーキテクト向けの視点 Azure Content Filtering（コンテンツフィルタリング）との組み合わせを忘れずに確認したい。画像生成モデルを社内ツールや顧客向けサービスに組み込む際、不適切な出力を防ぐ仕組みはセキュリティ・コンプライアンス上の必須要件だ。新しいモデルを採用する前に、既存のポリシー設定がそのまま適用されるかを確認すること。 また、Non-Human Identity（NHI）との連携を意識した設計も重要になってくる。大量の画像生成をパイプラインに組み込む場合、マネージドIDやサービスプリンシパルを使った認証フローを最初から設計しておかないと、後からの改修コストが跳ね上がる。「とりあえず動けばいい」でAPIキーをハードコードしたまま本番に持ち込むパターンは、セキュリティリスクになるだけでなく、スケールアップ時の運用ボトルネックにもなる。 筆者の見解 MicrosoftがAI画像生成の領域で「高品質」ではなく「効率」を軸にしたモデルを投入してきたことは、興味深い方向転換だ。これまでのMicrosoftのAI戦略は、とにかく最先端のモデルを持ってきて「最高のものを使っている」という印象管理に傾きがちだった面がある。それに対して今回は、エンタープライズ顧客が実際に求めている「安定して大量に使える」という現実解を提示してきた。 Azureという巨大なインフラを持ち、Fortune 500の多くと契約関係にあるMicrosoftが本気でプロダクション効率に向き合えば、これは相当強い武器になる。「最強の単一スペック」を競うゲームから、「総合的な運用コストとエコシステムの一貫性」を競うゲームに土俵を変えるのは、Microsoftが最も得意とするやり方だ。 ただし、一点だけ正直に言っておくと、こうしたモデル発表のたびに「どこでどうやって使えるのか」という実装詳細が後からしか出てこないパターンが続いている。発表の派手さと実際に開発者がAzure AI Studioで触れるようになるまでのタイムラグは、現場の期待値管理という意味でもったいないと感じることがある。「今すぐ使える」状態での発表を増やすことが、エンタープライズ開発者コミュニティの信頼につながるはずだ。 とはいえ、効率・コスト・スケーラビリティという軸でAIモデルの競争力を磨く方向性は正しい。Microsoftが持つ実装力と規模感を活かせば、この路線は必ず実を結ぶと見ている。 出典: この記事は Microsoft is making one of its best AI models faster and cheaper の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft が Office for the Web（Word・Excel・PowerPoint のブラウザ版）に、カスタムアクセス許可付きの秘密度ラベル（Sensitivity Label）作成機能を追加した。これまでデスクトップ版 Office にしかなかった機能がWebアプリでも使えるようになったことで、長年指摘されてきたセキュリティ面のギャップがようやく解消される。 秘密度ラベルとカスタムアクセス許可とは 秘密度ラベルは Microsoft Purview Information Protection（旧 Azure Information Protection）の中核機能だ。ファイルや電子メールに「社外秘」「機密」といったラベルを貼ることで、暗号化・透かし・アクセス制御などのポリシーを自動的に適用できる。 このラベルには2種類の設定方法がある。ひとつは管理者がテナント全体で定義する「管理者定義のアクセス許可」、もうひとつが今回の主役であるカスタムアクセス許可（User-defined Permissions）だ。後者は、ラベルを適用するユーザーが「このファイルはAさんとBさんだけが編集できる」と個別に指定できる柔軟な仕組みである。 このカスタムアクセス許可の設定機能がこれまでWebアプリに存在しなかった。管理者定義のラベルを貼ることはできても、特定ユーザーへの細かいアクセス制御をその場で設定する手段がなく、「どうしてもデスクトップ版を使わざるを得ない」という場面が生じていた。 何が変わったのか 今回の更新で、Word・Excel・PowerPoint のWeb版から直接、受信者のメールアドレスを指定して「閲覧のみ」「編集可能」などの権限をドキュメント単位で設定できるようになった。 デスクトップ版でラベルを付けた後にSharePoint上で確認・共有するというワークフローが主流だったが、これからはブラウザだけで一連の作業を完結できる。Chromebook利用者や、ポリシーでMacへのOfficeデスクトップインストールを制限している環境でも、情報保護の「抜け穴」がなくなる。 実務への影響 コンプライアンス運用の穴が塞がれる 日本の大手企業や金融機関では、Microsoft Purview を使って情報バリア（Information Barriers）や記録管理（Records Management）と組み合わせた多層的な情報ガバナンスを構築しているケースが増えている。しかしブラウザ版Officeにこの機能がなかったため、「Webアプリ利用時はラベルの詳細設定を忘れずにデスクトップで行うこと」という例外ルールが現場に残り続けていた。今回の対応でその例外が消える。 VDI・シンクライアント環境にとっても朗報 ゼロトラスト移行を進める企業ではVDI（仮想デスクトップ）やブラウザベースのシンクライアント構成を採用するケースが多い。デスクトップOfficeを持たないエンドポイントでも、秘密度ラベルの全機能が使えるようになったことはポリシー設計の自由度を大きく広げる。 管理者が確認すべきこと テナントのラベルポリシーで「ユーザーによるカスタムアクセス許可の設定を許可」が有効になっているか確認する Webアプリ向けに追加の感度ラベルポリシーを別途設定していた場合は見直しが必要 展開タイミングはテナントによって異なるため、Microsoft 365 管理センターのメッセージセンターを確認する 筆者の見解 「Webアプリにはデスクトップ版の機能がない」というのは、クラウドファーストを謳う製品として長年もったいない状況だった。ブラウザ版を使い始めたユーザーが「重要な機能はデスクトップ版じゃないとできない」と気づいた時の落胆は小さくない。 Microsoft はここ数年でOffice for the Webの完成度を着実に高めてきており、今回の対応はその流れの中でも特に意義深い。情報保護は「意識の高い一部の人だけがやること」ではなく、すべてのドキュメント作業に自然に組み込まれるべきものだ。使う場所・デバイスを選ばずに同じ保護レベルを適用できる仕組みが整ってこそ、組織全体のセキュリティ水準が均一に保たれる。 日本の現場では情報漏洩リスクへの対応に追われながら、運用例外の多さに疲弊している担当者も少なくないはずだ。「禁止するのではなく、正しく安全に使える環境を整える」アプローチとして、今回の改善はその方向に一歩近づくものだと評価している。あとはテナントポリシーを整備して、現場が迷わず使える状態に仕上げるのが管理者の仕事だ。 出典: この記事は Microsoft finally fixes a security limitation in Office for the web の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Googleが、Windows向けデスクトップアプリのアップデートを発表した。今回の目玉はAIチャット機能と画面内容を対象にしたスクリーン検索の2つ。シンプルに言えば「Geminiをデスクトップアプリに統合した」というアップデートだ。 ただし、このニュースに飛びつく前に立ち止まって考えてほしい問いがある。「それ、ブラウザで十分じゃないか？」 何が変わったのか 今回のアップデートで追加された主な機能は以下の通り。 AIチャット（Gemini統合）: デスクトップアプリ内から直接Geminiにアクセスし、検索や質問ができる スクリーン検索: 現在画面に映っている内容をもとに、関連情報をGoogleで検索できる機能 技術的な実装としてはGoogle Lensのデスクトップ版的な位置づけに近く、スマートフォンで慣れ親しんだ「見たものをそのまま調べる」体験をPC上で実現しようとしている。 なぜこれが注目されるか AIアシスタントをOSやデスクトップに統合する動きは、いまや業界全体のトレンドだ。Microsoftは早い段階からWindowsとCopilotの統合に取り組み、Appleも独自のApple Intelligence展開を進めている。Googleがデスクトップアプリを強化することで、この競争に本格参戦するという意思表示になる。 また「スクリーン検索」は地味に見えて実は便利な使い方がある。エラーメッセージが出たとき、画面をそのままキャプチャして検索できる体験は、コピー&ペーストの手間を省く。エンジニアや技術サポート担当者にとっては、日常的なルーティンを一段スムーズにしてくれる可能性がある。 実務での活用ポイント では、実際に使う価値はあるだろうか。以下の観点で判断してほしい。 使う価値がある場面: Google Workspaceを業務の中心に置いているチーム（GmailやGoogleドライブとの連携が期待できる） 複数モニターを使いながら、特定の画面内容をすぐに調べたいシーン AIチャットを別タブで開かずにデスクトップから呼び出したい場合 ブラウザで十分な場面: そもそもChromeを常時開いている（ほとんどの人がこれ） Google検索やGeminiはブラウザからでも同様に使える 追加アプリのインストールやリソース消費を避けたい管理者環境 率直に言って、ブラウザさえあれば同等のことができる現状では、このアプリが決定的な差別化要素を持てているかどうかは、まだ微妙なところだ。 日本のIT現場にとっての意味 企業のエンドポイント管理の観点では、Google公式アプリの配布はMDMやグループポリシーでの管理がしやすくなる点でメリットがある。ChromeブラウザだけでなくGoogleアプリとして一元管理できるシナリオが増えれば、Google Workspace管理者にとっては検討に値する選択肢になるかもしれない。 ただし、野良インストールを許すような環境では、むしろセキュリティ観点でのリスク評価が先だ。画面内容をクラウドに送る「スクリーン検索」は、機密情報の扱いに注意が必要。データがどこに送られるか、ポリシー設定で制御できるかを確認してから展開すべきだろう。 筆者の見解 正直に言う。Googleのデスクトップアプリは以前から「なぜブラウザで開かないのか」という疑問が常につきまとうプロダクトだった。今回のAI統合によって、その問いに少し答えを出しにいっている印象はある。 ただ、「統合プラットフォームとして使う」という体験をどこまで磨けるかが本質的な勝負だ。単機能をアプリに詰め込んだだけでは、ブラウザ vs アプリの差は縮まらない。スクリーン検索とAIチャットが、他のGoogle Workspaceツールや通知管理とシームレスにつながるようになれば、話は変わってくる。 Windows上でのAIアシスタント競争は、OS標準機能・ブラウザ・サードパーティアプリの三つ巴になりつつある。どれが「日常の中心」になるかは、最終的にはユーザーの習慣と、どれだけ「わざわざ使う理由」を提供できるかにかかっている。Googleが今回示したのは「参加表明」としては及第点。あとは継続的な改善でその価値を証明してほしい。 出典: この記事は Google upgrades its desktop app for Windows の内容をもとに、筆者の見解を加えて独自に執筆したものです。

安いGPUを買う理由がなくなる？ Nova Lake-Sが示す未来 PCを自作したことがある人なら、「CPUのオンボードグラフィックスはおまけ」という常識を疑ったことはあまりないだろう。しかし今、Intelの次世代デスクトップCPU「Nova Lake-S」に関するリーク情報が、その常識を塗り替えるかもしれない転換点を示唆している。 予算帯のゲーミングPCを組む際、従来の「ミドルレンジCPU＋エントリーGPU」という鉄板の組み合わせが、近い将来「高性能CPU一枚」で代替される可能性が現実味を帯びてきた。 Nova Lake-Sとは何か Nova Lake-Sは、Intelが開発中の次世代デスクトップ向けプロセッサーファミリーだ。今回リークされた情報によると、統合グラフィックス（iGPU）の性能が従来世代から大幅に引き上げられており、現行の3〜5万円台のエントリーGPUに匹敵する処理能力を持つ可能性があるという。 これはMobile（ノートPC）側ではすでに起きていた変化だ。IntelのCore Ultraシリーズ（Meteor Lake）やAMDのRyzen AIシリーズは、ノートPCの薄型モデルでも相応のゲーミング性能を発揮するようになっている。Nova Lake-Sはこの流れをデスクトップに持ち込む、という文脈で読むべきだろう。 なぜこれが重要か コスト構造の変化 国内のPC自作市場やBTO市場において、エントリーGPU（GeForce RTX 4060以下、あるいはそれに相当するAMD製品）の存在意義が薄れると、予算配分の考え方が根本から変わる。 従来：CPU 3万円 ＋ GPU 3万円 ＝ 合計6万円の出費 将来：CPU 5〜6万円（GPU機能統合）のみで同等性能 部品点数が減ることで、初期コストだけでなく、電力消費・発熱・組み立て難易度も下がる。特に企業が社員向けにカジュアルなゲーミング用途も許容するPCを調達する場面では、管理コストの削減につながる。 GPU市場への影響 NVIDIAやAMDのエントリーGPU製品は価格競争が激しいセグメントだが、そこが丸ごと圧縮されるシナリオが現実になれば、ミドルレンジ以上への需要集中が起こりうる。逆説的に、「本気でゲームをやりたい人」はより高性能なGPUを選ぶようになり、市場の二極化が進む可能性もある。 実務への影響——エンジニアとIT管理者が知っておくべきこと 購買計画の見直しタイミング Nova Lake-Sの正式発表・発売は2026年後半〜2027年が観測されている（現時点ではリーク情報のため確定ではない）。今すぐエントリーGPUを大量購入する予定があるなら、一度立ち止まって情報を追う価値がある。 ゲーミング用途以外への波及 iGPUの性能向上はゲーミングだけでなく、動画エンコード・機械学習の軽量推論・グラフィックス処理のオフロードにも効いてくる。開発者がローカルでAIモデルを動かす際の「とりあえず動く環境」のハードルが下がる点は注目したい。 選定基準の再構築 「CPUとGPUを別々に評価する」という購買フローそのものを見直す時期が来ている。統合性能を総合評価するベンチマーク指標（PassMark、3DMarkなど）の見方を改めて学んでおくと、次の調達時に役立つ。 筆者の見解 WindowsとPC周辺を長く見てきた立場から言うと、この流れは「CPUがGPUに追いついた」というより、「ゲームのグラフィックス要求がプラトーに達しつつある」ことの裏返しでもあると感じている。 ここ数年、エントリーGPUで十分プレイできるゲームタイトルは増えている。AAA大作の超高解像度・高フレームレートを求めなければ、「それなりに動く」敷居は年々下がっている。Nova Lake-Sのような統合グラフィックスの性能向上は、その「それなりに動く」ラインを一段と引き上げるだけであり、ハイエンドゲーマーの選択肢を変えるものではない。 ただし、エンタープライズ視点では話が違う。社員PCのGPU有無が業務効率に関わる時代——AIアシスタント、動画会議の背景処理、ローカルAI推論——が来ており、「GPUレスで調達してきた法人PC」が一気に陳腐化するリスクもある。Nova Lake-Sのような動きは、そのギャップを埋める一手になりうる。 リーク情報の段階では慎重な評価が必要だが、方向性としては技術的に筋が通っている。正式発表を待ちながら、自社の次期PC調達サイクルを意識してウォッチしておく価値は十分あるだろう。 出典: この記事は Intel’s leaked Nova Lake-S CPU could make budget graphics cards obsolete の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365のエンタープライズコミュニケーション基盤に、静かだが重要な変化が訪れた。MicrosoftはViva Engage（旧Yammer）のイベント機能を全面刷新し、レガシーシステムを正式に廃止。大幅なキャパシティ拡張を備えた新世代の仕組みへの移行を完了させる。 「明日」というタイムラインで動いているこの変更は、既存のレガシーイベントに依存している組織には影響が出る可能性がある。M365管理者は今すぐ確認すべきタイミングだ。 何が変わるのか レガシーイベントの廃止 MicrosoftはViva Engageの旧来のイベント形式（レガシーEngageイベント）を正式に終了させる。新しいシステムは以下の点で大きく進化している： 大規模キャパシティの拡張: 従来のシステムより大幅に多くの参加者を収容可能に 統合されたライブイベント体験: Teams Live Eventsと統合された形で、より一貫したUXを提供 コミュニティとの連携強化: Engageのコミュニティ機能と緊密に連携し、イベント後の継続的なディスカッションを促進 なぜ今このタイミングか Viva Engageはこの数年、MicrosoftがEnterpriseソーシャルコミュニケーション基盤として位置づけを強化してきたプロダクトだ。Teams Meetingsがリアルタイム会議を担う一方、Viva Engageは非同期かつ全社規模のコミュニティ形成という役割を担う。この棲み分けが明確になってきたことで、イベント機能のアップグレードは自然な流れとも言える。 実務への影響 IT管理者がすぐ確認すべきこと ① 既存のスケジュール済みイベントの確認 レガシーシステムで予約・設定済みのイベントがある場合、それらが新システムへ自動移行されるのか、手動での再設定が必要なのかを管理センターで確認する。特に全社ミーティングや定期的なTown Hallが設定されている環境では影響が大きい。 ② テナントのViva Engage設定 Viva Engageがテナント内で有効化されていない、またはライセンスが適切に割り当てられていない場合、新イベント機能が利用できないケースがある。Microsoft 365管理センターで現状を確認しておこう。 ③ 外部参加者の扱い 新しいイベント形式では外部ゲストの参加条件が変わっている可能性がある。サプライヤーや取引先を招くイベントを運営している場合は要確認だ。 エンジニアリングチームへの示唆 Viva Engageのイベント機能をGraph API経由で連携・自動化しているシステムがある場合、APIエンドポイントや認証フローの変更に注意が必要だ。レガシーAPIが廃止される可能性も考慮して、Microsoft Learnのドキュメントと変更ログを追っておくことを推奨する。 なぜこれが日本のIT現場に重要か 日本の大企業では依然として「全社メール」や「グループウェアの掲示板」が主要な全社コミュニケーション手段となっているケースが多い。Viva Engageのようなコミュニティベースのプラットフォームは、一方向的な情報発信から双方向のエンゲージメントへのシフトを可能にする。 キャパシティの大幅拡張は、数千〜数万人規模のグローバル企業や国内大手にとっては特に意味が大きい。これまでキャパシティ上限がボトルネックとなり、Teams Live EventsやWebcastシステムを別途用意していた組織では、M365統合基盤への集約が現実的な選択肢になってくる。 統合プラットフォームとしての全体最適という観点でも、バラバラなツールを複数維持するよりM365基盤に集約する方向は理にかなっている。ただし「あるから使う」ではなく、運用設計と組み合わせて初めて価値が生まれる点は強調しておきたい。 筆者の見解 Viva Engageはここ数年、地味ながらも着実に進化を続けているプロダクトだ。今回のイベント機能刷新は技術的な正常進化であり、評価できる方向性だと思う。 ただ一点、気になるのは移行タイミングの告知とリードタイムだ。「明日廃止」という短いタイムラインは、特に大規模なイベントをスケジューリングしていた組織には負担がかかる。Microsoftほどのプラットフォームであれば、エンタープライズ顧客に対してはもう少し長い準備期間と、より能動的な通知を提供してほしかった。それだけの実力と信頼関係があるブランドなのだから、運用面での丁寧さでも期待に応えられるはずだ。 機能面での進化を継続しながら、移行体験の質も同水準で上げていく——それが長期的なM365への信頼につながる。今後のロードマップに期待したい。 出典: この記事は Microsoft 365 overhauls Viva Engage events with massive capacity boost の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ついに静止画まで──DaVinci Resolve 21 が正式リリース Blackmagic Designが映像編集・カラーグレーディングの定番ツール「DaVinci Resolve 21」を正式リリースした。最大の目玉は、映画・ドラマの現場で培われたカラーサイエンスをそのまま静止画編集に持ち込む専用の 「Photo」ページ の追加と、ワークフロー全体を変える大規模なAI機能強化だ。 これまでDaVinci Resolveは動画編集・カラー・音声・VFXを一体化したオールインワンツールとして映像業界の標準に近い存在になっていたが、今回のバージョンで写真レタッチ市場にも本格参入した格好だ。 Photo ページ——Hollywoodカラリストの目を静止画に 新設された「Photo」ページでは、映像のカラーグレーディングに使われるのと同じエンジン（DaVinci Wide Gamut、DaVinci Intermediate）を静止画に適用できる。具体的には以下の機能が含まれる。 ノードベースのカラー調整: 映像プロが日常的に使うノードグラフで静止画を処理。調整レイヤーの積み重ねが直感的に管理できる RAW現像の対応拡充: シネマカメラのRAWフォーマットとの親和性が高く、動画と写真を同一プロジェクトで扱いやすくなった 一括書き出し: 複数の静止画をバッチ処理してDeliveryページから出力できる LightroomやCapture Oneが得意としてきた静止画ワークフローへの直接的な挑戦であり、すでに動画編集でDaVinci Resolveを使っているクリエイターには「もう別ソフトを覚えなくていい」という実用的なメリットが生まれる。 AI機能の大規模アップグレード バージョン21ではAI機能も全面的に底上げされた。主要な強化点は以下のとおり。 Magic Mask の精度向上: 人物・物体・背景の分離精度が上がり、ロトスコープ作業の工数が大幅に削減される 音声ノイズ除去（DaVinci Neural Engine強化）: 収録環境の違いをAIが吸収し、クリーンな音声トラックに仕上げる 自動カラーマッチング: 異なるカメラや照明条件で撮影された素材のカラーを自動で揃えるツールが高速化・高精度化 Speed Warp（フレーム補間）のリアルタイム処理: 高負荷だったフレーム補間がリアルタイムプレビュー可能になり、確認の手間が激減 いずれも「時間がかかっていた職人的な作業をAIが下支えする」設計で、クリエイターの判断を排除するのではなく判断の前段階の労力を減らすという方向性が一貫している。 実務への影響——日本のクリエイター・IT管理者にとっての意味 動画×写真の統合ワークフロー: 映像制作会社や動画クリエイターがDaVinci Resolveをすでに導入しているなら、カメラマンの静止画レタッチも同一プラットフォームに統合できる。ライセンスを追加購入せずに済む可能性がある（DaVinci Resolve自体に無料版が存在する点も見逃せない）。 ライセンス管理の簡素化: エンタープライズ環境でクリエイティブ系ソフトウェアのライセンス管理をしているIT担当者にとって、「映像も写真も1本で」は管理コスト削減のチャンスになる。Studio版（有料）の費用対効果を再評価する価値がある。 AI処理のハードウェア要件: Neural Engineを活かすには相応のGPUが必要。M1/M2/M3搭載のMacや最新のNVIDIA GPUが推奨環境となる。映像制作PCの調達計画に影響する可能性があるため、機材更新サイクルを確認しておきたい。 ハイブリッドクリエイターの台頭: 写真・映像・音声の境界が一つのツールの中で溶けていく。「動画も写真もできる人材」を育てる・採用する観点でも、学習コストが下がるという意味でこのバージョンは節目になりうる。 筆者の見解 DaVinci Resolve 21が静止画に踏み込んだことは、Adobe CCが長年支配してきたクリエイティブツール市場に対する、実力ある挑戦者からの本気の一手だと感じる。 個人的に興味深いのは、AI機能の実装方針だ。「AIが創作する」ではなく「AIが下ごしらえをして人間が仕上げる」という分業の設計が徹底されている。Magic Maskにしても音声ノイズ除去にしても、あくまでクリエイターの意図を実現するための下支えとして機能する。これは実際の現場で使い続けられるツールの条件として非常に重要な判断だと思う。 また「無料版でも相当な機能が使える」というビジネスモデルは、日本の教育機関や個人クリエイターが本格的な技術を習得する入り口として機能している。ツールの民主化という意味で、この戦略は正しい方向を向いていると見ている。 Photoページについては、LightroomやCapture Oneのユーザーがすぐに乗り換えるかというと、既存の資産（プリセット、プラグイン、ライブラリ管理の習慣）の移行コストがあるので一朝一夕にはいかない。ただし、「動画から始めて写真も覚える」層には確実に響く機能であり、新規ユーザーの獲得には効く。5年後のシェアがどう動くか、注目しておきたいバージョンだ。 出典: この記事は DaVinci Resolve 21 lands with Hollywood-level “Photo” feature and massive AI upgrades の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

ブラウザの「戻る」ボタンを押したはずが、広告ページに飛ばされた経験はないだろうか。Googleはこの手口——いわゆる「バックボタン乗っ取り（Back Button Hijacking）」——が急増していることを確認し、対象サイトへのペナルティ適用を開始すると発表した。ユーザー体験の保護という観点から、見逃せない動きだ。 バックボタン乗っ取りとは何か バックボタン乗っ取りは、ブラウザのHistory APIを意図的に操作する手法だ。サイトがページ遷移の履歴を書き換えることで、ユーザーが「戻る」を押した瞬間に前のページではなく広告や別のランディングページへリダイレクトさせる。 仕組み自体は単純で、JavaScriptのhistory.pushState()やhistory.replaceState()を乱用することで実現できる。本来これらのAPIはSPA（シングルページアプリケーション）のルーティングなど正当な用途のために用意されたものだが、収益目的で悪用されるケースが後を絶たない。 Googleは今回、この手口の急増を明確に問題視し、検索品質の観点からペナルティの対象とする方針を打ち出した。 なぜ今、Googleが動いたのか Googleのコアアルゴリズムはここ数年、E-E-A-T（Experience・Expertise・Authoritativeness・Trustworthiness）の強化に力を注いできた。バックボタン乗っ取りは「Trustworthiness（信頼性）」を直接的に破壊する行為であり、放置すれば検索結果全体の信頼性が毀損される。 また、スマートフォンでの利用が主流となった今、ブラウザの物理的な「戻る」ジェスチャーを乗っ取られることはPCよりも不快感が強い。Googleにとっても、自社の検索経由でユーザーが不快な体験をさせられることは看過できなかったはずだ。 実務への影響——Webサイト運営者・開発者が今確認すべきこと 既存サイトの点検が急務 ペナルティの詳細な基準はまだ公表されていないが、以下のパターンに心当たりがあれば早急に修正すべきだ。 history.pushState()を広告表示のためだけに使っている ページ離脱時に意図せずリダイレクトが発生する処理がある サードパーティの広告SDKやアドネットワークを導入しており、その挙動を把握していない 特に最後の点が見落とされがちだ。自社でコードを書いた覚えがなくても、組み込んだ広告タグが裏でHistory APIを操作しているケースが実際に存在する。 SPAフレームワーク利用者は誤検知に注意 ReactやVue、Next.jsなどのSPAでは、クライアントサイドルーティングのためにHistory APIを正当に使う。Googleがどこまでを「悪用」と判断するかは今後の動向次第だが、UX上の理由のないpushStateの呼び出しは今すぐ棚卸しする価値がある。 Google Search Consoleの活用 ペナルティを受けた場合、Search Consoleの「手動対策」セクションに通知が来ることが多い。定期的な確認を習慣化しておくと早期発見につながる。 筆者の見解 正直なところ、この対応は遅すぎた——とはいえ、今からでも意味はある。 バックボタン乗っ取りは「ユーザーの意図に反する操作を強制する」という点で、フィッシングサイトに次ぐレベルの不誠実さだと個人的には思っている。ユーザーはブラウザの戻るボタンを「必ず前に戻れる」という信頼のもとで押している。その信頼を広告収益のために踏み台にする行為は、Webというインフラそのものの品質を下げる。 Googleの今回の判断は、「禁止ではなく仕組みで対処する」という正攻法だ。行儀の悪いサイトを検索結果から遠ざけることで、ユーザーが自然と質の高いサイトへたどり着けるようにする。これはWebのエコシステムを健全に保つための正しいアプローチだと思う。 日本のWebサイト・サービス運営者にとっても他人事ではない。特にアドネットワークを複数組み合わせているメディアサイトは、自社サイトが知らぬ間にペナルティ対象になっていないか、今週中に確認しておくことを強くお勧めする。 Webの信頼性はインフラだ。誰かが守らなければ全員が損をする。Googleがここに踏み込んだことは、業界全体にとってプラスの一手だと評価したい。 出典: この記事は Google will now punish websites that hijack the back button to serve you ads の内容をもとに、筆者の見解を加えて独自に執筆したものです。

欧州12カ国で1,700以上のクラブを運営するフィットネス大手・Basic-Fit（本社：オランダ）が、2026年4月13日にデータ侵害を公表した。攻撃者は会員の来館記録システムに不正アクセスし、約100万人分の個人情報を持ち出した。同社は欧州全体で約500万人の会員を抱えており、実に5人に1人が影響を受けた計算になる。 何が流出したのか 流出が確認されたデータは以下の通りだ。 氏名・住所・メールアドレス・電話番号 生年月日 銀行口座情報 その他会員情報 幸いにもパスワードや身分証明書類は含まれていない。また、フランチャイズ店舗の会員データは別システムで管理されており、今回の侵害対象外とされている。 被害国はオランダ（20万人）・ベルギー・ルクセンブルク・フランス・スペイン・ドイツの6カ国。Basic-Fitはシステム監視によって侵入を「発見から数分以内に停止した」と説明しているが、その数分の間にデータが外部に持ち出されている。 なぜこれが重要か——「銀行口座情報」という重さ 今回のインシデントで最も深刻なのは、銀行口座情報が含まれている点だ。氏名や住所だけなら「フィッシングメールのターゲットになる可能性がある」程度で済む話だが、口座情報が加わると不正引き落としや口座乗っ取りのリスクが一気に高まる。 さらに注目すべきは、「来館記録システム」というある意味では周辺系のシステムが侵入口になったという点だ。多くの企業では「コアの業務システムさえ守ればいい」という意識が根強く残っているが、会員管理・ログ管理・来退館記録のような補助的なシステムも個人情報を保有している以上、同等の保護が求められる。どこから入られるかわからない——これがゼロトラストの出発点でもある。 GDPRが機能したこと——そして日本との差 EUのGDPR（一般データ保護規則）では、データ侵害が発覚した場合、72時間以内に規制当局への報告が義務付けられている。Basic-Fitは今回、規定通りにオランダのデータ保護機関（AP）へ通知している。また同社のデータ保持ポリシーでは、退会後2年でデータを自動削除する仕組みが整っている。 このような仕組みが整っていることで、「今後の被害拡大の限界」がある程度見通せる状態になっている。日本でも個人情報保護法の改正が進んでいるが、欧州に比べると通知義務の運用はまだ緩い面がある。自社のデータ保持ポリシーと開示プロセスを見直す良い機会だろう。 実務への影響——IT管理者・エンジニアが今日見直すべきこと 1. 「周辺系」システムの棚卸し 本社のERP・会計システムだけでなく、入退館管理・勤怠・ログ収集サーバーなど、個人情報を保有しているすべてのシステムを洗い出す。意外なところにPII（個人識別情報）が眠っている。 2. 最小権限の徹底 「来館記録システム」に銀行口座情報が入っていること自体、アクセス制御の設計を問い直すべきシグナルだ。各システムが必要最低限の情報しか持たない設計になっているか確認する。 3. データ保持ポリシーの整備 退会・契約終了から一定期間後に自動削除するポリシーを定め、システム的に実装する。「持っていないデータは漏れない」——これが最強の対策の一つだ。 4. 監視とインシデント対応の速度 Basic-Fitは「数分以内に停止」と言いつつデータは持ち出された。侵入検知の速度と、検知後のデータ流出防止（DLP）が両輪として機能しているかを確認したい。 筆者の見解 セキュリティのトピックは正直、細かい議論になりがちで得意分野とは言いにくいのだが、このインシデントには技術的に興味深い構造がある。 「発見から数分で止めた」のにデータが流出した——この事実は、「侵入を防ぐ」だけではもはや不十分であることを端的に示している。侵入されることを前提に、「侵入されても何も持ち出せない」設計が求められる。これはまさにゼロトラストの考え方だ。ネットワーク境界で守るのではなく、データそのものへのアクセスを認証・認可の多層で制御する。 もう一点、日本の企業にとって他人事ではないのは「来館記録に銀行口座情報が同居していた」という設計上の問題だ。「とりあえず同じDBに入れておけ」という運用は、日本のシステムでも珍しくない。「今動いているから大丈夫」は通じない時代になっている。 フィットネスジムのデータ侵害が、なぜIT管理者の話になるのか——それは、どんな業界・どんな規模の企業も「会員情報」「決済情報」を持つ瞬間から同じリスクを背負うからだ。自社の「来館記録システム相当」がどこにあるかを考えてみてほしい。 出典: この記事は European Gym giant Basic-Fit data breach affects 1 million members の内容をもとに、筆者の見解を加えて独自に執筆したものです。

何が起きたか セキュリティ研究者が「BlueHammer」と名付けたWindowsの権限昇格エクスプロイトが公表された。影響を受けるデバイスは世界で10億台を超えるとされており、規模の大きさから多くのWindowsユーザーが注目している。 BlueHammerの核心は、TOCTOU（Time-of-Check to Time-of-Use）脆弱性とパス混乱（Path Confusion）の組み合わせにある。「確認したときと実際に使用するときの間に状態が変わってしまう」という古典的なレースコンディションと、ファイルパスの解決ロジックを混乱させる手法を組み合わせることで、権限昇格を実現する。 技術的な構造を理解する TOCTOU脆弱性とは TOCTOU攻撃は、アクセス権を「確認する処理」と「実際に実行する処理」の間に存在するわずかな時間窓を突く。たとえば「このファイルに書き込んでいいか？」を確認した後、実際に書き込む前に攻撃者がそのファイルを別の場所へのシンボリックリンクに差し替えると、本来許可されていないパスへの書き込みが発生する。 なぜ「パス混乱」が組み合わさるのか Windowsはファイルパスの解決において、Win32パス（C:\Windows\System32\...）とNTパス（\??\...）という異なる表記体系を持つ。BlueHammerはこの差異を利用し、セキュリティチェックが見る「パス」と実際に操作される「パス」を意図的にずらすことで特権ファイルへの書き込みを誘導するとされている。 「未認証では悪用できない」の意味を正確に読む 重要なのは、BlueHammerは単体では未認証での悪用ができないという点だ。何らかの形で攻撃者がすでにシステム上でコードを実行できる状態（ローカルアクセスや限定的な権限）にある必要がある。 しかし、これを「安全だ」と読んではいけない。現実のインシデントでは、フィッシングメール→資格情報窃取→BlueHammerで特権昇格→横展開、というチェーンが容易に成立する。BlueHammerは「初期侵入」を担うエクスプロイトではなく、「侵入後の被害最大化」を担うピースとして機能する点に脅威の本質がある。 実務への影響 エンジニア・IT管理者が今すぐ確認すべきこと 1. パッチ適用状況の確認 Microsoftが本脆弱性に対応するパッチをリリースしているか、あるいはCVEが割り当てられているかを公式のセキュリティ更新プログラムガイド（MSRC）で確認する。BlueHammerがPoC（概念実証コード）として公開されている場合、悪用までの猶予は短い。 2. 最小権限の徹底 権限昇格エクスプロイトが効果を発揮するのは、昇格した先に「使える権限がある」からだ。ユーザーアカウントに標準ユーザー権限のみを与え、管理作業はJIT（Just-In-Time）で必要な時だけ昇格する構成が基本になる。EntraIDのPIM（Privileged Identity Management）を使ったJIT昇格はこのクラスの攻撃に対して非常に有効だ。 3. EDR・Defender for Endpointの検知ルール確認 TOCTOU攻撃はシンボリックリンク操作や特定のNTパスアクセスパターンを伴う。EDRがこれらの挙動を異常として検知・アラートする設定になっているか確認しておきたい。 4. 資格情報保護の強化 BlueHammerの前段階として資格情報窃取が必要なことを逆手に取り、LAPS（Local Administrator Password Solution）によるローカル管理者パスワードのランダム化、Credential GuardやWindows Helloによる認証強化を優先する。攻撃チェーンの最初のピースを断つことが、権限昇格エクスプロイトへの最も現実的な対策になる。 日本企業特有のリスク 日本の大規模エンタープライズでは、オンプレミス Active Directoryとクラウドが中途半端に混在した環境がいまも多い。そういった環境では「標準ユーザーに見えて実は何らかのローカル管理者権限がある」という状態が発生しやすく、BlueHammerのような権限昇格エクスプロイトの被害が連鎖しやすい。棚卸しは急務だ。 筆者の見解 TOCTOU脆弱性は新しい概念ではない。30年以上前から議論されてきたクラシックな攻撃手法であり、それが2026年にもなって10億台規模の影響を持つエクスプロイトとして登場するという事実には、複雑な思いを抱く。 Windowsのパス解決ロジックは歴史的な経緯から非常に複雑で、Win32・NT・UNC・DOSデバイスパスといった複数の名前空間が混在している。この複雑さ自体が攻撃面を広げてきた。Microsoftがここ数年で取り組んでいるカーネルセキュリティの強化——サードパーティカーネルドライバーの締め出し強化やSmart App Controlの整備——は正しい方向の取り組みだと思っているが、パス解決の根本的な複雑さを整理するのは並大抵ではない。 ひとつ明確にしておきたいのは、「10億台超」という数字に過剰反応しすぎないことだ。BlueHammerが機能するためには攻撃者がすでにある程度の足場を築いている必要があり、それ自体を防ぐ取り組みが優先される。「新しい脆弱性が出た＝全員即アウト」ではない。パッチ適用・最小権限・JIT昇格・EDR監視という基本の積み重ねが、このクラスの脅威に対する最善の盾になる。 Microsoftにはその基盤を整える力が十分あるし、Defender・IntuneといったMDMスタックとの統合で日本企業のセキュリティポスチャを一気に引き上げるポテンシャルもある。BlueHammerへの対応が迅速であれば、それはそのポテンシャルを体現する機会にもなる。正面から勝負できる力があるのだから、速やかな対応を期待したい。 出典: この記事は ‘BlueHammer’ Exploit Targets Windows, Potentially Impacting 1 Billion+ Devices の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年のWindows 11は「体験の細部」に本気を出している 2026年4月上旬のWindows 11 Insider Buildに、注目すべき変更が立て続けに盛り込まれた。Secure Boot証明書の期限切れに対応するUI整備、ハプティックフィードバックの強化、そしてXbox Modeの導入——これらは一見バラバラに見えるが、今年後半のWindows 11が向かう方向性を示す重要な伏線として読み解くことができる。 Insider（Preview）Buildの変更点を追うことの意味が薄れている時代ではある。しかし今回のビルド群は「裏方の改善」だけにとどまらず、エンドユーザーが日常的に触れる場面での体験変化を含んでいる点で、IT管理者にとっても無視できない内容だ。 7つの主要変更点を読み解く 1. Secure Boot証明書の期限切れ対応UI 最も実務的なインパクトがあるのがこれだ。Secure Bootに使われるUEFI証明書が期限切れを起こした際、これまではエラーメッセージが暗号的で原因特定が困難だった。新しいUIでは、証明書の期限切れを明示的に警告し、対処法へのガイダンスが表示されるようになる。 企業環境では、カスタムSecure Bootキーを管理しているケースもある。「なんか起動しない」という問い合わせがIT部門に来たとき、証明書の期限切れがすぐに疑えるかどうかで対応時間が大きく変わる。地味だが、現場の負荷を減らす正しい方向の改善だ。 2. ハプティックフィードバックの強化 Surface等の対応デバイスで、タッチ操作やペン入力時のフィードバックが細かく制御できるようになる。物理キーボードのクリック感に慣れたユーザーが「タブレットモードは使いにくい」と感じる原因の一つがフィードバックの薄さだった。これを埋める取り組みとして評価できる。 3. Xbox Mode Windowsをゲーム用途に最適化する「Xbox Mode」が導入される。バックグラウンドプロセスの制御やリソース割り当ての調整により、ゲームパフォーマンスを向上させる仕組みとみられる。Xbox Game Passとの連携を強化し、PCとコンソールの垣根をさらに下げる狙いがあると考えられる。 4〜7. その他の変更点 その他にも、設定アプリのUX改善、通知管理の強化、Windowsアップデート関連のフィードバック収集UI、そしてアクセシビリティ機能の拡充が確認されている。特にアップデート関連のフィードバックUIは「更新後に問題が起きたときに報告しやすくする」という観点で、品質向上の仕組みづくりとして機能する可能性がある。 実務への影響——IT管理者・エンジニアが注目すべき点 Secure Boot関連は即座に実務インプットとして持っておきたい。特に以下のシナリオで有効だ： オンプレミスのデバイス管理でIntuneやSCCMによる証明書管理を行っている環境 カスタムUEFIキーを使用しているセキュアな企業端末の展開環境 新入社員端末の一括セットアップ時に「なぜか起動しない」案件が頻発している現場 Windows Updateについては依然として「すぐ当てたら壊れた」という報告が散見されるため、Insider Buildの変更内容を事前にウォッチしておくことで、本番適用前のリスク見積もりに役立てることができる。数日様子を見るという判断が今でも合理的な場面はある。 Xbox Modeについては、企業環境での扱いを事前に決めておくことを勧める。ゲーミング用途のPCと業務用PCが混在する環境では、GPOやIntuneポリシーでの制御が必要になる可能性があるため、GAリリース前に動作を把握しておきたい。 筆者の見解 WindowsのInsider Buildを細かく追い続けることの意義は、数年前と比べて確かに薄れている。機能の追加ペースとリリースの質のバランスが崩れていた時期もあった。 ただ、今回の4月ビルド群を見ると、「ユーザーが実際に困っている場面への対応」という姿勢が随所に見える。Secure Boot証明書のUIはその典型で、技術的に難しいことをやっているわけではないが、現場の痛みに向き合った改善だ。こういう地道な積み上げが、長期的な信頼の根拠になる。 Xbox Modeも、PCとコンソールの統合という大きな絵の中で捉えると、単なるゲーミング機能ではない。WindowsというプラットフォームがXboxエコシステムを取り込み、エンターテインメント領域でのユーザー体験を一本化する方向は、正しい戦略だと思う。実行が伴えば、の話だが。 2026年後半のWindows 11がどんな姿で正式リリースされるか、今回のInsider変更群はその輪郭を見せてくれている。Microsoftにはこの調子で「実際に困っている人を助ける」方向の改善を積み重ねていってほしい。それが一番の強みのはずだから。 出典: この記事は The 7 biggest Windows 11 Insider changes from early April — and why they matter for 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2026年初頭、アンダーグラウンドのサイバー犯罪フォーラムに「Storm」と名乗る新型インフォスティーラーが登場した。月額1,000ドル以下というサブスクリプション型で提供されるこのマルウェアは、これまでのクレデンシャル窃取型マルウェアとは一線を画す設計思想を持っている。単なる亜種ではなく、エンドポイントセキュリティの進化に対してマルウェア側が「回答」を出してきた事例として、IT管理者は真剣に向き合う必要がある。 なぜ「サーバー側復号」が危険なのか 従来のインフォスティーラーは、被害者のマシン上でブラウザの認証情報データベース（SQLite）に直接アクセスし、ローカルで復号を行っていた。このアプローチはエンドポイントセキュリティツールに検知されやすく、「ブラウザDBへの不審なアクセス」がシグネチャとして広く知られるようになっていた。 Googleが2024年7月にChrome 127でApp-Bound Encryption（アプリ紐付き暗号化）を導入したことで、ローカル復号はさらに困難になった。しかし攻撃者はこれに対して「ローカルでの復号をやめる」という発想の転換で応じた。 Stormが採用したのは、暗号化されたままのブラウザデータを攻撃者のサーバーに送り、そこで復号するというアーキテクチャだ。エンドポイント側では「暗号化ファイルの転送」しか発生しないため、多くの既存ツールが依存するテレメトリデータが生成されない。ChromiumベースのブラウザだけでなくFirefox、Waterfox、Pale MoonなどGeckoエンジン系も対象にしている点も、より広範な被害を可能にしている。 MFAを無力化するセッションハイジャック Stormが収集するのはパスワードだけではない。セッションクッキー、Googleアカウントトークン、オートフィルデータ、クレジットカード情報、閲覧履歴など、「認証済みセッションを完全再現する」のに必要なものすべてが標的だ。 さらに、収集後の操作を自動化している点が際立っている。Google Refresh TokenとSOCKS5プロキシを組み合わせることで、被害者の認証済みセッションをオペレーターのパネル上でそのまま「復元」できる。パスワードを一切使わず、MFAの検証をスキップして、SaaSツールや社内システム、クラウド環境に侵入できる。 セキュリティリサーチャーのVaronisが以前に公開した「Cookie-Bite」の研究では、Azure Entra IDのセッションクッキーを窃取することでMFAが意味をなさなくなる実態が示されていた。Stormはそのテクニックをサブスクリプション機能として「製品化」したものと見てよい。 収集範囲とインフラ設計 Stormはブラウザ以外にも触手を伸ばしている。Telegram、Signal、Discordのセッションデータ、仮想通貨ウォレット（ブラウザ拡張・デスクトップアプリ両対応）、複数モニターのスクリーンショット、システム情報を含む。処理はすべてメモリ上で実行されるため、ディスクへの痕跡が残りにくい。 インフラ面では、オペレーターが独自のVPS（仮想プライベートサーバー）をStormの中央サーバーに接続する構成を採る。窃取データが共有インフラを経由しないため、法執行機関や不正利用申告があっても中央サーバーへの影響を局所化できる設計だ。 実務への影響 このような脅威に対して、日本のIT管理者・エンジニアが今すぐ見直すべきポイントを整理する。 セッション管理の強化：セッショントークンの有効期間を短く設定し、IPアドレスや地理情報の変化を検知した際に再認証を強制するポリシーを導入する。Conditional Access（条件付きアクセス）でデバイスコンプライアンスを要件にすることも有効だ。 エンドポイント検知だけに頼らない：Stormはエンドポイント側のシグネチャ検知を意識的に回避する設計になっている。ネットワーク層での異常な外部通信の監視、ユーザー行動分析（UEBA）など、多層防御の実践が欠かせない。 フィッシング耐性の高い認証への移行：FIDO2/パスキーはセッションクッキーではなくデバイス紐付きの認証を行うため、クッキー窃取型攻撃に対して本質的に強い。移行コストはあるが、MFAの「次の一手」として優先度を上げるべきだ。 ユーザーディレクトリへのファイルアクセス制限：Stormはドキュメントフォルダも標的にする。機密ファイルを個人の作業領域に放置しない運用、DLPポリシーの見直しも並行して行いたい。 筆者の見解 Stormが示す最大の教訓は、「セキュリティ機能を強化するとマルウェアが設計を変えて回避してくる」というイタチごっこが加速していることだ。GoogleのApp-Bound Encryptionは正しい取り組みだったが、攻撃者は「ローカルで戦わない」という選択肢に移行した。これはセキュリティ対策が無意味だという話ではなく、対策の層を増やすことでそのたびに攻撃コストが上がるという構造をしっかり理解した上で設計する必要があるということだ。 ゼロトラストの観点からすると、今回の手口はまさに「認証済みセッション＝信頼」という前提を崩してくる攻撃だ。ネットワークに入れたからといって、その後のアクセスを無条件に信頼するアーキテクチャは限界を迎えている。セッション継続性そのものを検証し続ける仕組み——IPの変化、デバイス状態の変化、アクセスパターンの異常——を組み込むことが、次の標準になっていくと筆者は見ている。 NHI（Non-Human Identities）の観点でも示唆がある。人間の認証情報を狙う攻撃がここまで洗練されてくると、人間がサービスアカウントやAPIキーを直接扱う運用リスクが改めて浮き彫りになる。マネージドIDやサービスプリンシパルへの移行を進め、人間の介在を減らすことが、こうした攻撃のアタックサーフェスを根本から縮小することにつながる。 月額1,000ドル以下でここまでの機能が「製品」として手に入る時代に、防御側が個別の対策を積み上げるだけでは追いつかない。アーキテクチャレベルでの見直しを、今年の優先課題に据えてほしい。 出典: この記事は The silent “Storm”: New infostealer hijacks sessions, decrypts server-side の内容をもとに、筆者の見解を加えて独自に執筆したものです。

世界最大級のオンライン旅行予約プラットフォームであるBooking.comが、第三者による不正アクセスを確認した。同社は既存・過去の予約に紐づくPINを強制リセットし、影響を受けたユーザーへの個別通知を進めている。単なるパスワードリセットで終わる話ではなく、漏洩した情報の組み合わせが後続攻撃の「燃料」になりうる点で、注意が必要だ。 何が漏洩したのか 今回流出が確認されているデータは以下の通りだ。 氏名（フルネーム） メールアドレス 郵便住所 電話番号 宿泊施設とのやり取りメッセージ 決済情報やパスワードの漏洩は現時点では言及されていないが、上記の組み合わせは「なりすましフィッシング」に十分すぎる素材になる。特に「施設とのやり取りメッセージ」が含まれている点が危険で、攻撃者は具体的な予約内容を把握した上で「宿泊施設からの連絡」を装えてしまう。 Booking.comはこの件について「不審なメールやSMSのリンクはクリックしないよう」呼びかけており、同社が銀行振込や機密情報を求めることは絶対にないと明言している。 アプリ通知なしの混乱 今回のインシデントで注目すべき運用上の問題がある。警告メールを受け取ったユーザーが、アプリ側にはまったく通知が届いていないとして、メールの正当性を疑うケースが続出した。 公式ドメイン（noreply@booking.com）からの送信であっても、アプリ内通知と同期されていなければ「フィッシングでは？」と疑われるのは自然な反応だ。セキュリティインシデントの通知設計として、「複数チャネルで同時に伝える」という原則が守られていなかったことが、混乱を増幅させた。 さらにReddit上では、プライベートな予約情報を知っているらしい詐欺師から接触されたとの報告も上がっている。今回の侵害との直接の関連は確認されていないが、タイミングと情報の具体性から見て無関係とは考えにくい。 実務への影響——日本のエンジニア・IT管理者へ 1. 「漏洩情報を使ったフィッシング」への備えを組織に周知せよ 今後数週間〜数ヶ月にわたって、Booking.comの予約内容を詳しく知った攻撃者からのフィッシングメールや電話が増加する可能性がある。組織のセキュリティ担当者は、従業員向けに「公式を装った連絡であっても、リンクのクリックや口頭での情報提供はしない」というリマインドを早急に行うべきだ。特に出張管理担当者や経理は標的になりやすい。 2. 個人情報＋予約情報の組み合わせリスクを理解する 今回のような「個人情報＋コンテキスト情報」の組み合わせ漏洩は、単純なリスト型攻撃より遥かに精度の高いソーシャルエンジニアリングを可能にする。「攻撃者が具体的な日付・施設名・金額を知っている」状況での問い合わせを想定した訓練は今後ますます重要になる。 3. サードパーティSaaSのインシデント対応を評価軸に入れる Booking.comは世界的な大企業でありながら、今回は被害規模・影響ユーザー数すら開示していない。企業として出張やイベントでBooking.comを利用している場合、ベンダーのインシデント対応の透明性は契約評価に含めておくべき観点だ。GDPRやAPPI（個人情報保護法）の観点から、対応の遅さや情報開示の不透明さはリスク評価に直結する。 筆者の見解 セキュリティという分野は個人的に好物とは言えないが、今回のインシデントには技術的な興味を引く構造がある。 漏洩したデータ単体ではなく、「予約という行為に紐づいたコンテキスト情報」が攻撃側に渡った点が本質的な危険だ。氏名とメールアドレスの組み合わせなら今どきさほど珍しくないが、「〇月〇日に〇〇ホテルに泊まることを知っている人間」からの連絡は、普段フィッシングを見破れるリテラシーの高いユーザーでも引っかかりやすい。攻撃の精度が上がっている。 また、通知設計の失敗が「公式通知をフィッシングと誤認させる」という皮肉な結果を生んだことも見逃せない。セキュリティは技術だけでなく、ユーザー体験の設計でもある。どれだけ堅牢なシステムを作っても、通知の届け方を間違えれば「本物が偽物に見える」状況を自ら作り出してしまう。 ゼロトラストの観点から見れば、「予約PINでの本人確認」という設計自体も問いなおす余地がある。予約番号＋PINという組み合わせは、両方が漏洩した瞬間に無効化される。認証要素の多様化と、コンテキストベースのリスク評価を組み合わせた設計への移行は、旅行プラットフォームに限らず、あらゆるBtoCサービスで検討すべき方向性だ。 今回のBooking.comの対応は「発見→封じ込め→通知」という基本ステップは踏んでいる。しかし規模の開示なし、アプリ通知の欠如、詐欺被害との関連不明確——という課題を抱えたまま幕引きにするなら、「対応した」とは言えない。世界規模のプラットフォームだからこそ、インシデント対応の透明性で業界標準を作ってほしいと思う。 出典: この記事は New Booking.com data breach forces reservation PIN resets の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365のビジネスアカウントを狙い、MFA（多要素認証）すら回避するフィッシングキットとして知られていた「W3LL」が、FBIとインドネシア当局の協調捜査によって壊滅させられた。開発者の逮捕と同時にインフラが押収されたこの事件は、単なる犯罪者一人の逮捕にとどまらない——フィッシング攻撃の「フルサービス化」という深刻なトレンドを改めて浮き彫りにしている。 W3LLとは何だったのか W3LLは500ドルで購入できるフィッシングキットで、企業のログインポータルを精巧に模倣したサイトを誰でも作れるようにする仕組みだった。単にパスワードを盗むだけでなく、認証セッショントークンをリアルタイムで傍受できる点が特に危険視されていた。 仕組みはいわゆるAiTM（Adversary-in-the-Middle）攻撃だ。攻撃者のインフラが正規のMicrosoftログインページを中継する形でユーザーを誘導し、入力されたパスワード・ワンタイムMFAコード・セッションクッキーをすべて横取りする。ユーザーは正規サイトにログインしたつもりでいるが、その裏で攻撃者は盗んだセッションクッキーを使い、MFA認証を再度求められることなくアカウントに侵入できる。 一度アカウントを乗っ取ると、攻撃者はメールの監視・転送ルールの設定・なりすまし請求書の送付といったBEC（ビジネスメール詐欺）攻撃へと移行する。2019年から2023年にかけて2万5,000件超の侵害アカウントが売買され、被害額は2,000万ドル（約30億円）以上にのぼるとされている。 MFAを「有効にしているから安全」では終わらない時代 ここで立ち止まって考えたいのが、「MFAを設定しているから問題ない」という認識だ。W3LLはまさにその前提を崩すために設計されていた。 MFAはフィッシングに対して非常に有効な防御策であることは間違いない。しかし、AiTM型の攻撃はMFAの認証成功後に発行されるセッションクッキーを盗む。つまり、「認証の成功」自体を悪用するという発想だ。これに対抗するには、MFAを使いつつも、セッションの継続的な検証を組み合わせる必要がある。 具体的には、Microsoft Entra ID（旧Azure AD）の条件付きアクセスポリシーと継続的アクセス評価（CAE）の活用が有効だ。さらに、パスワードレス認証やフィッシング耐性のあるMFA——具体的にはFIDO2セキュリティキーやWindows Helloを使った認証——はAiTM攻撃に対しても根本的に強い。セッションクッキーを盗んでも、公開鍵ベースの認証は再現できないためだ。 実務での活用ポイント 1. フィッシング耐性MFAへの移行計画を立てる SMS・メール・TOTP（時間ベースのワンタイムパスワード）はAiTM攻撃に対して脆弱だ。まずは特権アカウントからFIDO2キーまたはMicrosoft Authenticatorの「番号照合＋位置情報」機能を有効にすることを検討したい。 2. Microsoft Defender for Office 365 のSimulated Phishing攻撃シミュレーションを実施する ユーザーが実際にどのフィッシング手口に引っかかりやすいかを把握するには、攻撃シミュレーショントレーニングが効果的だ。W3LL型の中継フィッシングパターンもシミュレーション対象に含める。 3. 不審なメールルール・転送設定の自動検知を設定する BEC攻撃は侵入後に静かに行われる。Microsoft 365の監査ログや、Defender for Cloud Appsのアラートで「新しい転送ルールが作成された」通知を有効にしておくと、侵害後の横展開を早期検知できる。 4. NHI（Non-Human Identity）の認証フローも同様に見直す BECはアカウントを踏み台にするが、サービスプリンシパルやAPIキーが同様に盗まれていないかも確認が必要だ。特に長期間有効なシークレットが発行されたままになっている場合は整理の機会だ。 筆者の見解 W3LLの特筆すべき点は、フィッシングを「個人の手作業」から「フルサービスSaaS型の犯罪基盤」へと昇格させたことだ。W3LLは単なるツールではなく、マーケットプレイス・サポート・アップデート提供まで含むプラットフォームだった。犯罪のハードルを下げ、技術力のない攻撃者でもM365アカウントを狙えるようにした。 逆説的に聞こえるかもしれないが、こういうニュースが出るたびに思うのは、ゼロトラストの原則は正しかったということだ。「ネットワーク内にいるから信頼する」「MFAを通過したから信頼する」という静的な前提を壊し、継続的に検証し続ける仕組みこそが求められている。 アメリカとインドネシアの初の協調摘発という側面も見逃せない。サイバー犯罪は国境を越える一方で、これまで法執行機関の協力体制は遅れていた。今回の案件が新しい国際連携の先例になるとすれば、長期的な抑止力として意味がある。 一方で正直に言えば、W3LLを壊滅させても類似のサービスは他にいくつも存在する。Tycoon2FAやEvilTokensなど、同様の仕組みを提供するプラットフォームは今も動いている。根本的な対策は攻撃が成立しにくい認証基盤を作ることにあり、それには地道な設定変更と、ユーザーへの継続的な教育が不可欠だ。 「今の設定で問題が出ていないから大丈夫」は通用しない。W3LLの2万5,000件の被害者の多くも、被害に気づくまでは「問題ない」と思っていたはずだ。 出典: この記事は FBI takedown of W3LL phishing service leads to developer arrest の内容をもとに、筆者の見解を加えて独自に執筆したものです。

組み込みシステムやIoTデバイスに広く使われるTLS/SSLライブラリ「wolfSSL」に、攻撃者が偽造した証明書を正規のものとして受け入れさせてしまう深刻な脆弱性が発見された。影響範囲は世界50億以上のアプリケーション・デバイスに及ぶとされており、特に産業用制御システムや車載システムを扱う国内エンジニアは対応を急ぐ必要がある。 何が問題なのか：ECDSA署名検証の穴 今回の脆弱性はCVE-2026-5194として追跡されており、wolfSSLがECDSA（楕円曲線デジタル署名アルゴリズム）署名を検証する際に、ハッシュアルゴリズムの種類やサイズを適切にチェックしていないことが原因だ。 具体的には、証明書検証の関数が「鍵の種類に対して本来必要なサイズより小さいダイジェスト」を受け入れてしまう。ダイジェストが小さいほど偽造・再現が容易になるため、攻撃者はこの隙を突いて正規CAによって署名されたかのような偽造証明書を対象デバイスに受け入れさせることができる。 影響を受けるアルゴリズムはECDSA/ECCだけにとどまらず、DSA、ML-DSA（Post-Quantum）、Ed25519、Ed448にも及ぶ。特にECCとEdDSAまたはML-DSAを両方有効にしているビルドは最優先でアップデートが必要だ。 wolfSSLの位置づけ：「縁の下」だからこそ怖い wolfSSLはOpenSSLやMbedTLSと並ぶ軽量TLS実装で、Cで書かれた組み込み向けライブラリだ。スマートルーター、産業用センサー、車載ECU、さらには航空宇宙・防衛分野の機器にも採用されている。 問題はその「縁の下の力持ち」的な性質にある。アプリケーション開発者がOpenSSLを直接使っている場合と異なり、wolfSSLはベンダーのSDKやファームウェアの深部に静かに組み込まれていることが多い。自分の組織がwolfSSLを使っているかどうか、IT部門が把握していないケースは珍しくない。 なおRed HatはMariaDBへの影響を「なし」としているが、これはMariaDBがwolfSSLではなくOpenSSLを使っているためだ。ソフトウェアスタックの依存関係の把握がいかに重要かを示す好例だ。 対応バージョンと確認方法 本脆弱性はwolfSSL 5.9.1（2026年4月8日リリース）で修正済みだ。 対応の優先度は以下の通り整理できる： wolfSSLを直接使用している開発者: 5.9.1へ即時アップデート Linuxディストリビューションのパッケージ経由: 各ディストリビューションのセキュリティアドバイザリを確認 組み込み機器・IoTデバイス管理者: デバイスメーカーやSDKベンダーのダウンストリームアドバイザリを待ちつつ、影響範囲の洗い出しを先行して実施 実務への影響：日本のIT現場では何をすべきか エンタープライズのIT管理者にとって、今回の脆弱性は「サーバーのパッチを当てれば終わり」ではない。以下の点を確認してほしい。 SBOMの整備が急務　自社製品・調達システムに使われているオープンソースライブラリを把握するSBOM（Software Bill of Materials）が整備されていなければ、今回のような脆弱性への対応は常に後手に回る。特にOT（運用技術）系システムを持つ製造業・インフラ事業者は、ソフトウェアサプライチェーンの棚卸しを今すぐ始めるべきだ。 証明書の信頼チェーンを過信しない　TLSの証明書検証は「信頼の基盤」だ。今回の脆弱性が示すように、その基盤自体が揺らぐリスクがある。ゼロトラストアーキテクチャの文脈では、「証明書があるから信頼する」ではなく、継続的な検証と最小権限の組み合わせこそが正しいアプローチとなる。 パッチ適用のサプライチェーン追跡　wolfSSLのような組み込みライブラリは、アップストリームのパッチがデバイスに届くまでにメーカー→ODM→SI→ユーザーと複数段階を経る。パッチ適用状況をエンドツーエンドで追跡できる体制を持っているかどうかが問われる。 筆者の見解 wolfSSLはその小さなフットプリントゆえに「見えないところで動いている」ライブラリの典型だ。今回の脆弱性発見で改めて思うのは、NHI（Non-Human Identity）の管理とソフトウェアサプライチェーンの可視化は、実は同じ問題の別側面だということだ。 サービスプリンシパルやマネージドIDを使った自動化が進む一方で、それらの認証基盤を支えるTLSライブラリが適切に管理されていなければ、自動化の恩恵を安全に享受することはできない。NHIが増えれば増えるほど、その通信を保護する暗号基盤の健全性が業務効率と直結する。 組み込みやIoTの世界は「今動いているから大丈夫」という感覚が根強い。しかし暗号の脆弱性は静かに、そして確実に悪用可能な状態で潜んでいる。SBOM整備と定期的なサプライチェーン監査を「コスト」ではなく「インフラ」として位置づける組織だけが、こうしたリスクに先手を打てる時代になった。 出典: この記事は Critical flaw in wolfSSL library enables forged certificate use の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows Updateを装った攻撃は以前から存在するが、今回確認された手口はその精巧さが際立つ。「Windows 11 24H2」の正規アップデートに見せかけたダウンロードが、ユーザーの知らないうちにシステムに侵入し、パスワードやクッキー、個人情報といった機密データを外部に送信するというものだ。正規のWindows Updateに不信感を持つユーザーほど罠にはまりやすいという点で、非常に巧妙な攻撃と言える。 何が起きているのか 攻撃者は「Windows 11 24H2」の公式アップデートに見せかけたインストーラーを配布している。見た目はMicrosoftの公式UIに酷似しており、ダウンロードページのデザインや証明書表示まで本物らしく作り込まれているケースがある。 インストールを実行すると、バックグラウンドでインフォスティーラー型のマルウェアが起動する。主な窃取対象は以下の通りだ。 ブラウザに保存されたパスワード・クッキー・オートフィルデータ 暗号資産ウォレットの認証情報 VPN・リモートデスクトップの接続情報 ローカルに保存されたドキュメント・スクリーンショット 窃取されたデータはC2サーバー（Command & Control）に自動送信される。ユーザーには「アップデートが完了しました」といった偽の完了画面が表示されるため、被害に気づくのが遅れる構造になっている。 どこからダウンロードされているのか 主な配布経路として確認されているのは、検索エンジンの広告枠に表示される偽サイト（SEOポイズニング）、SNSや掲示板に貼られたリンク、そしてスパムメールのリンク先だ。公式の microsoft.com や windowsupdate.com ではなく、紛らわしいドメイン名（例: windows-update-24h2.com のような形式）を使っているケースが多い。 URLを見れば判断できるが、アップデート通知に焦ったり、管理者から「早急に当てるように」と言われたりした場合に確認を省略してしまうのが人間の心理だ。 実務への影響 エンドユーザーへの注意点 最も確実な対策はシンプルだ。Windowsの更新は必ずWindows Update（設定→Windows Update）から行う。 外部サイトからダウンロードしたインストーラーでWindowsを更新することはMicrosoftが想定した使い方ではない。「作り手の意図を理解し、意図された使い方をする」という原則がここでも生きる。 IT管理者・情報システム部門への推奨事項 Windows UpdateのMDM/WSUS管理を徹底する: エンドユーザーが自分でアップデートを検索・ダウンロードする状況を作らない。IntuneやWSUSで配信を制御し、ユーザーが「外からダウンロードする必要がない」環境を整える EDR（Endpoint Detection and Response）の導入確認: インフォスティーラーはブラウザプロセスへのメモリアクセスなど特徴的な振る舞いをする。EDRが有効であれば検知・遮断できるケースが多い MFA（多要素認証）の全面適用: 仮にパスワードが窃取されても、MFAが有効であれば不正ログインを防げる。特にAzure AD（Entra ID）連携のアカウントではMFAは必須と考えるべきだ アプリケーション制御ポリシーの検討: Windows Defender Application ControlやApplocker等で、署名のない実行ファイルの起動をブロックする構成は有効な多層防御となる Windows Update適用タイミングについて 「すぐに当てたら壊れた」という報告が増えている現状では、数日様子を見てから適用するという判断も現場では合理的だ。ただしその「待ち時間」に偽アップデートの誘惑が増す点に注意したい。公式チャンネルのみ利用し、サードパーティからは絶対に取得しないというルールを組織として徹底することが、このリスクに対する最善の答えだ。 筆者の見解 この種の攻撃が繰り返されるたびに感じるのは、「禁止より仕組みで防ぐ」という原則の重要さだ。「怪しいサイトからダウンロードするな」と周知するだけでは不十分で、そもそもユーザーが外部からダウンロードする必要がない状態を作ることが本質的な対策になる。MDMで更新を管理し、MFAで認証を守り、EDRで振る舞いを監視する——この三層が揃っていれば、今回のような攻撃のインパクトは大幅に下がる。 セキュリティ界隈では当たり前の話ではあるが、「今動いているから大丈夫」という感覚で止まっている組織がまだ多い。攻撃の精巧さは年々増している。インフラ側の整備を後回しにするコストは、じわじわと、しかし確実に上がっていく。正面から向き合うなら今だ。 出典: この記事は Beware! This “Windows 11 24H2” update download can quietly steal your sensitive data の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...