Windows

AMDは2026年6月、グラフィックドライバー「AMD Software: Adrenalin 26.6.2」をリリースし、前世代GPU「Radeon RX 7000シリーズ（RDNA 3アーキテクチャ）」へのAI機械学習ベースのアップスケーリング技術「FSR 4.1」サポートを追加した。かねてより約束していた旧世代への展開が、ついに実現した形だ。 FSR 4.1とは何か FidelityFX Super Resolution（FSR）は、AMDが開発するオープンなアップスケーリング技術だ。低解像度でレンダリングしたゲーム映像を高品質に拡大表示することで、GPUの描画負荷を下げながら高解像度の映像体験を実現する。 FSR 4.0は昨年登場したRDNA 4アーキテクチャ（Radeon RX 9000シリーズ）とともにリリースされた。従来のFSR 3.xが時間的（テンポラル）アルゴリズムを主体としていたのに対し、FSR 4世代は機械学習モデルを活用した新世代の超解像技術に刷新されており、特にテクスチャの再構成精度で大きな改善を果たしている。 RDNA 3への展開——約束の履行 FSR 4.0リリース当初は「RDNA 4専用」という制約があり、既存のRX 7000シリーズオーナーは最新の恩恵を受けられなかった。AMDはこれに対してRDNA 3への対応を約束しており、ドライバー26.6.2がその約束の履行となる。 FSR 4.1はFSR 4.0の機械学習コアを維持しつつ、RDNA 3のハードウェア特性に合わせて最適化されたバージョンと位置づけられており、RX 7900 XTXをはじめとするRX 7000シリーズ全般が対象だ。 主な世代間の違いを整理すると次のとおり。 機能 FSR 3.x FSR 4.1 アップスケーリング方式 テンポラル（時間的） 機械学習（AI推論） 最低対応GPU RDNA 2以降 RDNA 3以降 フレーム生成 対応（FSR 3.0以降） 対応 画質傾向 良好 より高精度・高解像感 ドライバーアップデート自体はAMD Software: Adrenalinの更新機能またはAMD公式サイトから入手できる。FSR 4.1対応ゲームでは、グラフィック設定内に新たなアップスケーリングオプションとして表示されるため、特別な追加インストールは不要だ。 実務への影響 一見ゲーマー向けのニュースに思えるが、映像処理やGPUコンピューティングを扱うエンジニアにも無関係ではない。 ゲーム開発者・グラフィックエンジニア向け: FSR 4.1はDirectX 12およびVulkan環境向けにオープンなAPIとして提供されている。NVIDIAのDLSS 4が専用ハードウェア（Tensor Core）を必要とするのに対し、FSRはドライバーアップデートだけで旧世代ハードにも展開できる柔軟性が強みだ。ゲームエンジンへの実装コストも比較的低く、UnityやUnreal Engineの対応プラグインも整備されている。 IT管理者・調達担当者向け: 企業内でRX 7000シリーズを運用している場合、追加コストなしで映像処理ワークロードの品質向上を図れる可能性がある。ただし、本番環境ではドライバー更新に伴う互換性テストを必ず行うこと。AMDのメジャーバージョンアップは過去に一部の業務アプリとの相性問題が報告されており、数日間コミュニティのフィードバックを確認してから適用するのが現実的な判断だ。 ...

NVIDIAは欧州全域にわたる35台のAI対応HPCスーパーコンピューターの展開計画を発表した。科学研究から産業応用まで、欧州の計算インフラを根本から刷新しようとする大規模な取り組みだ。 NVIDIAが欧州AI基盤強化に本腰を入れた背景 ここ数年、欧州は米国や中国に対するAI計算資源の遅れを問題視してきた。EU AI Actの施行とともに、欧州域内でのデータ処理・AI開発基盤の自立的な整備が急務となっており、NVIDIAの今回の発表はそうした欧州側の強い要求に正面から応える形のコミットメントといえる。 欧州各国政府・研究機関・産業界は、外部依存ではなく「欧州自身がAI計算資源を持つ」というソブリンAIの方向性を打ち出してきた。35台という規模は象徴的な数字であり、単なるビジネス拡大にとどまらず、欧州のAI戦略そのものへの参画宣言と読み取れる。 35台のスーパーコンピューターが変えること NVIDIAが展開するシステムは最新GPUアーキテクチャを搭載したAI最適化HPC基盤だ。各拠点が担う役割は大きく3つに整理できる。 科学研究の加速 気候変動モデリング、創薬、材料科学など計算集約型の研究を大幅に高速化する。欧州は基礎科学への投資を政策として重視しており、こうした計算基盤は研究競争力の底上げに直結する。 産業AI応用の実用化 製造業、エネルギー、物流分野でのリアルタイムAI処理を現実のものにする。エッジとクラウドの中間に位置する高性能計算ノードとしての役割も期待される。 ソブリンAIクラウドの構築 GDPRをはじめとする欧州の規制に完全準拠した、域内完結型のAI処理環境を整備する。これにより欧州企業はデータを域外に出さずにAI活用ができるようになる。 Azure・Microsoftとの連携という視点 見落とされがちだが、今回の動きにはMicrosoftとの連携という側面もある。AzureはNVIDIAのGPUを大規模採用しており、欧州のHPCインフラ拡充はそのままAzure AI ServicesやAzure HPC Workloadsの処理基盤強化につながる。 日本の企業が欧州拠点でAzureを活用している場合、この計算基盤の整備は間接的に恩恵をもたらす可能性がある。特にAzure OpenAI Serviceや各種AIモデルの推論速度・コスト改善への影響は注目に値する。 実務への影響——日本のエンジニア・IT管理者が知るべきこと クラウドAI処理の地政学的分散 欧州基盤の強化により、グローバルなAIワークロードの分散配置がしやすくなる。欧州顧客向けにAIサービスを提供する日本企業にとって、データレジデンシー要件を満たしながら高性能推論を実現できる選択肢が増える。 HPCとAIの融合という新標準 NVIDIAのこの動きは「HPCとAIは別物」という従来の認識が崩れつつあることを示している。科学計算インフラをAIに転用する、あるいは最初からAI/HPC共用で設計するアプローチが業界標準になりつつある。 オンプレミスHPC投資の判断見直し 自社でHPC環境を持つ製造業や研究機関は、クラウドHPCとの比較を再検討すべき時期に来ている。欧州での大規模展開によりGPUの供給と価格競争力は今後改善が見込まれ、クラウドHPCの費用対効果は高まっていく。 筆者の見解 欧州でこれだけの規模のAIインフラ投資が進んでいることは、日本が直視すべき現実だと感じる。 日本には理化学研究所のスーパーコンピュータ「富岳」をはじめ世界水準のHPC資産がある。しかし「計算資源があること」と「AIを産業や行政に実装できる人材・仕組みがあること」は全く別の話だ。欧州はインフラと制度（EU AI Act）を同時に整備しており、その整合性という点では日本はまだ差がある。 もう一点気になるのは、今回の35台がNVIDIA製品で統一されることで生じるベンダーロックインだ。計算基盤の構築スピードは正しい方向だが、数年後に「NVIDIA以外に選択肢がない」という状況が欧州に生じないか、その先の多様性確保まで視野に入れた投資判断が求められる。 日本のエンタープライズにとって重要なのは、欧州の動きを対岸の火事と見ないことだ。AIの計算基盤は今後5年で世界的に再編される。今動いていなければ、気づいたときには出遅れているという状況は、Windows時代にも、クラウド移行期にも繰り返されてきた。今度こそその轍を踏まないためにも、インフラ動向を注視しながら自社の計算戦略を今から練り直しておくことを勧めたい。 出典: この記事は NVIDIA announces 35 new AI HPC supercomputers across Europe の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月のWindows 11アップデートで、複数のアプリケーションが同一Webカメラのストリームを同時に利用できる「Multi-App Camera」機能を標準搭載した。これまでZoomとOBSを同時起動した際に片方がカメラを「占有」してしまう問題が解消され、会議中の配信や複数の映像ツール並行利用が現実的になった。 Multi-App Cameraとは何か Windowsのカメラアーキテクチャはこれまで「1アプリ1デバイス独占」の設計を基本としていた。Webカメラを使いたいアプリが複数ある場合、先に起動したアプリがデバイスをロックし、後から起動したアプリには「カメラを使用中です」というエラーが返るのが一般的な挙動だった。 Multi-App Cameraはこの制約をOS層で解消する機能だ。カメラフレームを複数のアプリに配信する仮想ストリーム層をWindowsが管理し、ZoomとTeamsとOBSが同じ物理カメラから映像を受け取れるようになる。ユーザーの操作は従来と変わらず、それぞれのアプリでカメラを選択するだけでよい。 どんな場面で役立つか 実際の利用シーンとして最もわかりやすいのは、オンライン配信と会議の並行運用だ。YouTubeやTwitchでライブ配信を行いながら、別ウィンドウでZoomのチームミーティングに参加する——これが追加機材なしで実現できる。 また、企業のIT現場では以下のようなシナリオにも対応できる： 複数会議システムの同時待機：Teamsのチャンネル会議と外部向けZoom商談を同時に開いておき、必要に応じてカメラをオン 映像品質の事前確認：OBSで映像フィルター・エフェクトを確認しながら、Teamsの映像プレビューを別画面で見る 録画と会議の並行：会議ソフトで通話しながら、別のキャプチャソフトが同じカメラ映像をローカル録画する 技術的な補足：遅延とフレームレートへの影響 複数アプリへのストリーム分岐により、CPUへの負荷増加は避けられない。Microsoftは公式に性能への影響を最小化する設計を謳っているが、低スペックマシンではフレームレートの低下や遅延増加が出る可能性がある。高解像度カメラ（4Kクラス）を使用している場合は特に注意が必要だ。 エンタープライズ環境でこの機能を活用する場合は、まずテスト環境で複数アプリ同時起動時のCPU使用率・フレームレートを確認してから展開するのが堅実だ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 即日使える実務ポイント： 外付けハブ・仮想カメラソフトの代替: これまでManyCam等の仮想カメラソフトでカメラ分配を行っていたワークフローは、そのままWindowsネイティブに移行できる可能性がある。ライセンスコストの見直し対象になりうる ハイブリッド研修環境の簡素化: 講師が自分のカメラを録画ソフトと配信プラットフォーム両方に流す構成が、追加設定なしで可能になる Windows 11更新ポリシーの確認: この機能はWindows 11の6月更新以降に含まれる。組織での展開状況によっては適用タイミングにバラつきが出るため、Intuneや更新リングの設定を改めて確認するとよい 筆者の見解 正直に言えば、Windowsの細かい機能更新を追う意義自体がここ数年で薄れてきていると感じている。ただ、このMulti-App Camera機能は「地味だが長年の実際の不満に答えた」という点で評価したい。 カメラの単一占有問題は多くのユーザーが日常的にぶつかってきた壁だ。OBSとTeamsを同時に起動するたびにカメラの取り合いが起きるのは、技術的には2010年代から解決できたはずの問題でもある。それがようやくOS標準機能として手当てされた。遅すぎるという見方もできるが、「標準機能として誰でも使える状態にする」ことに価値があることは間違いない。 Microsoftには、こうした地に足のついた実用改善をもっと前面に出してほしいというのが率直な気持ちだ。派手なAI機能の発表が続く中で、この種の「毎日使う機能の品質向上」は地味に見えても確実に積み重なる信頼につながる。この方向での改善を続けてくれることを期待している。 出典: この記事は Windows 11 Multi-App Camera: Multiple apps share the same webcam stream の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Microsoft 365デスクトップアプリが導入されたWindows 11搭載PCに対し、Microsoft 365 Copilotアプリを自動インストールする展開を2026年6月中旬から7月中旬にかけて実施すると、管理者向けポータルで静かに告知した。インストールはデフォルトで有効化されており、管理者側で「オプトアウト」しない限り自動的に展開される。 強制展開の仕組み 今回の展開で特筆すべきは、MicrosoftがWindows StoreではなくOfficeアプリに組み込まれたMicrosoft 365 Apps updater（Officeの自動更新機構）を使用している点だ。つまり、Windows側のポリシーやストア制限だけでは防げない。 対象は「Microsoft 365デスクトップアプリが入った対象デバイス」とされており、すべてのOffice搭載PCが対象というわけではない。ただし、具体的な除外条件は公式ドキュメントを確認する必要がある。 欧州経済領域（EEA）は今回の展開から除外される。これはデジタル市場法（DMA）への対応と見られる。 管理者が知っておくべき制御手段 MicrosoftのCopilot関連の管理コントロールは現在、複数の場所に分散している： Microsoft 365 Apps 管理センター 統合アプリ（Integrated Apps） Officeプライバシー設定 アプリごとの個別トグル アプリ単位でCopilotを無効化したい場合は、各Officeアプリの「ファイル → オプション → Copilot」から「Copilotを有効にする」チェックを外す方法がある。ただし、これはアプリごと・デバイスごとに設定が必要なため、組織規模での管理には向いていない。Outlookは設定箇所が異なる（クイック設定または設定 → Copilot）点にも注意が必要だ。 なお、レジストリ直接編集でCopilotを排除しようとするアプローチは、今後の更新で上書きされるリスクがあるためMicrosoftも推奨していない。組織管理にはサポートされた管理ツールを使うべきだ。 実務への影響 日本企業のIT管理者が今すぐ確認すべき対応ポイントは以下の通り： テナントのライセンス・デバイス構成を確認：どのデバイスが自動展開の対象になるか把握する 展開を止めたい場合はM365管理センターでオプトアウト：6月〜7月の展開開始前に設定を完了させておくのが安全 エンドユーザーへの事前案内：突然アプリが出現してサポート問い合わせが増えないよう、先んじて周知する ヘルプデスクへの情報共有：「知らないアプリが入った」という問い合わせへの対応準備 Copilotを活用する方針の組織はそのまま展開を受け入れ、利用促進の機会として使えばよい。問題は「使わない組織」が対応を取らないと自動で展開されてしまう点にある。 筆者の見解 Microsoftが「オプトイン」ではなく「オプトアウト」という形で展開するのは、今回が初めてではない。何度か批判を受けながら同じことを繰り返しているのは残念だ。 Copilotが本当に価値あるツールなら、ユーザーが自然と「使いたい」と思える状況を作ればいい。強制的に存在を見せつける手法は、ユーザーの信頼を積み上げるのではなく、むしろ「また勝手に入ってきた」という拒否感を育てるリスクがある。Microsoftにはそれを地道にやりきるポテンシャルがあるはずなので、もう少し丁寧なアプローチをとってほしいというのが正直なところだ。 IT管理者の立場からすれば、管理コントロールがM365管理センター・統合アプリ・プライバシー設定・アプリ別トグルと四分散しているのは純粋に辛い。「無効化したいなら一箇所で完結させる」という設計を、次のリリースサイクルでぜひ実現してもらいたい。 一方で、Copilotを積極活用する組織にとっては、展開の手間が省けるという意味でメリットでもある。この展開を機にCopilot活用の推進を検討するのも一つの選択肢だ。 出典: この記事は Microsoft says it’ll force install Microsoft 365 Copilot on Windows 11 with MS 365 Business in the next 30 days の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftはWindows 11 バージョン26H2を2026年6月19日にExperimentalチャンネルへリリースした。次期年次機能アップデートとなる26H2は、フルビルドではなく「有効化パッケージ（enablement package）」という軽量な配信方式で届けられ、サポートライフサイクルのリセットをもたらす。IT管理者にとっては、一般提供（GA）に向けた展開計画を今から立てる絶好のタイミングだ。 Windows 11 26H2の正体——eKBとは何か バージョン番号「26H2」は「2026年下半期リリース」を意味し、21H2、22H2、23H2、24H2、25H2と続くMicrosoftの年次リリース慣例に則っている。2025年末にリリースされた25H2が24H2のコードベース上に構築された有効化アップデートだったように、26H2も同じパターンを踏襲する。 注目すべきは「有効化パッケージ（eKB: enablement package）」という配信メカニズムだ。フルビルドアップグレードが数GBの新しいOSファイルを丸ごと置き換えるのに対し、eKBはわずか数百KBのパッケージで、毎月の累積更新プログラムを通じてすでにデバイスに配信済みの機能を「スイッチを入れる」形で有効化する仕組みだ。 技術的には、Windowsのサービシングスタックがレジストリ値または内部設定フラグを変更するのみで、新しいバイナリは一切持ち込まない。インストール後に一度再起動するだけでバージョン番号が26H2に変わる——通常の累積更新プログラムと変わらない軽さだ。このモデルは23H2が22H2のコードベース上に構築された際に実証済みであり、テスト工数の削減・帯域幅消費の最小化・展開摩擦の軽減という3つのメリットをIT管理者にもたらす。 サポートライフサイクルのリセット——エディション別の違いに注意 26H2リリースの実務上の最大の意義は「サポートライフサイクルのリセット」だ。エディション別のサポート期間は以下のとおりとなる。 エディション サポート期間 Home / Pro 24カ月 Enterprise / Education 36カ月 Enterprise/Educationの36カ月サポートは、大規模組織が年次アップグレードのプレッシャーなく安定運用できる余裕を生み出す。一方、Home/Proの24カ月は個人ユーザーや中小企業にとって「ほぼ2年ごとの更新」を意味し、これまでのWindowsサポートサイクルを踏まえると想定の範囲内だ。 26H2へのアップグレードは新しいサービシングブランチへの移行も意味する。今後の累積更新プログラムはこのベースラインに対して配信され、次の年次アップデートまでの最長36カ月間、セキュリティパッチと品質改善が継続提供される。 IT管理者が今すべきこと Experimentalチャンネルでの公開は「本番展開前に問題を発見できる最初の機会」を意味する。GAは2026年後半の予定であり、今から準備を進めることで余裕のある展開計画が立てられる。 今すぐ着手できる3つのアクション： 検証環境でのテスト開始: Insider Preview（Experimentalチャンネル）を検証機に適用し、社内アプリケーションとの互換性を確認する サポートライフサイクルの棚卸し: 現在展開中のWindowsバージョンとエディションのEOL日付を整理し、26H2への移行タイミングを計画する 展開ポリシーの準備: IntuneもしくはWSUS/ConfigMgrで26H2のターゲットバージョン設定を事前に確認し、GA時の適用スコープを決めておく eKBモデルの最大のメリットは「フルOSアップグレードより圧倒的にテストが早く完了する」点だ。新しいシステムファイルの置き換えがないため、アプリケーション互換性のリスクは大幅に低い。とはいえGA直後は数日様子を見てから適用するというリスク管理も、十分に合理的なセキュリティ判断の一つだ。 筆者の見解 Windowsの細かい変更を逐一追う必要性が薄れつつある昨今だが、eKBモデルの成熟は「縁の下の力持ち」として地味に評価したい。 この仕組みが定着したことで、大規模組織のIT部門が抱えていた「年次アップグレードは一大プロジェクト」という固定観念が崩れつつある。展開コストが下がれば、パッチ適用を後回しにする理由も減る。これはセキュリティ態勢の底上げに直結する正しい方向性だ。 ただ率直に言えば、現時点では「26H2で何が変わるのか」という機能面の情報がほぼない。eKBの仕組みとサポートサイクルの話は重要だが、それだけでは「アップグレードする明確な理由」として弱い。MicrosoftにはGA前に機能ロードマップをわかりやすく示してほしいところだ。組織のIT担当者が「何のために移行するのか」を社内で説明するためにも、そのコミュニケーションは欠かせない。 今の判断としては「GAになってから機能一覧を確認して移行計画を立てる」で十分間に合う。今の段階では検証環境でeKBの挙動を確認しておくという準備に時間を使うのが賢明な選択だ。 出典: この記事は Windows 11 26H2 Hits Experimental Channel: Unpacking the Enablement Update and 36-Month Support Cycle の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11に標準搭載された新しい「メディアプレーヤー」アプリが、旧来の「Windows Media Player」と比べて約3.5倍のRAMを消費することが報告されている。さらに、現代のスマートフォンや動画配信でも主流のHEVC（H.265）コーデックがOS標準では非搭載であり、再生には別途有料の拡張機能購入が必要であることが改めて注目を集めている。 新旧プレーヤーのRAM消費量——何が変わったのか Windows 11では、長年親しまれてきたWindows Media Player（WMP）の後継として、Fluent Designを採用したモダンな「メディアプレーヤー」アプリが標準搭載されている。ExtremeTechの検証によると、同じ動画ファイルを再生した際のRAM消費量が旧WMPの約3.5倍に達するという結果が出た。 モダンアプリとしての統合ライブラリ管理やUIの洗練は評価できるが、レガシーWMPが持っていたリソース効率という強みは失われている。特に低スペックのビジネス向けノートPCや、バッテリー駆動を重視する環境では、このオーバーヘッドが体感レベルで影響する可能性がある。 HEVCコーデックが「有料オプション」という現実 もう一つの問題が動画コーデックの扱いだ。Windows 11では、HEVC（H.265）コーデックはOSに含まれておらず、Microsoft Storeから「HEVC Video Extension」を約120円（0.99ドル）で別途購入する必要がある。 H.265はiPhoneやAndroid端末で撮影した4K動画、NetflixなどのHDRストリーミングコンテンツでも広く使われている、現代の「主流コーデック」だ。それが標準搭載でないという事実は、一般ユーザーには気づかれにくいが、実務では確実にトラブルの種になる。 一部のWindows 11デバイスでは「デバイス製造元からのHEVC Video Extensions」が無償プリインストールされるケースもあるが、提供はメーカー任せであり一貫性がない。 実務への影響——企業IT担当者が知っておくべき対処法 社内動画の再生環境を統一する 社内研修動画や会議録画をH.265形式で配布している組織では、受信側での再生可否が問題になりうる。Windows 11標準のメディアプレーヤーだけでは再生できない可能性があるため、以下の対策を検討したい。 VLCの全社展開: フリー・オープンソースで主要コーデックをほぼ網羅。コーデック課金とは無縁で、管理されたデバイスへのサイレントインストールも容易 IntuneによるHEVC Extensionの一括配布: Microsoft StoreアプリはMicrosoft Intune経由でポリシーベース配布が可能。HEVCコーデック問題をまとめて解決できる 動画の配布形式をH.264に統一: 一時的な回避策として、配布動画をH.264（AVC）にエンコードして提供するのも現実的な選択肢 コーデック管理の不統一がサポート負荷につながる VP9対応の「Web Media Extensions」やAV1対応拡張など、Windowsのコーデック周りは拡張機能が分散しており、管理が複雑になりやすい。ヘルプデスクが「動画が再生できない」という問い合わせを受けた際の診断フローを整備しておくことを推奨する。 筆者の見解 RAMが3.5倍になったという数値はインパクトがあるが、現代のPCが16GB以上のRAMを標準で積んでいる状況を考えると、絶対値として壊滅的というわけではないかもしれない。ただ、「モダン化＝肥大化」という傾向は、特に法人端末のような長期利用・低スペック環境では無視できないシグナルだ。 より気になるのはHEVCの課金モデルのほうだ。H.265は2013年に標準化されて以来、すでに10年以上が経過した枯れた技術だ。スマートフォンで撮影した動画が、PCに標準搭載のプレーヤーでそのまま再生できないというのは、ユーザー体験として明らかに改善の余地がある。コーデックライセンス料の問題があることは理解できるが、その負担をエンドユーザーに120円という形で転嫁するのは、Microsoftが本来持っているプラットフォーム統合力を使えばもっとうまくやれるはずだという思いがある。 OEMのプリインストールに依存した現状の「一貫性のない無償提供」ではなく、より体系的なアプローチで解決してほしい。Windowsプラットフォームに長年関わってきた立場から、この点は正直に申し上げておきたい。 出典: この記事は Windows 11 New Media Player Uses 3.5x More RAM, Charges for Popular Video Codecs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

マーケットインテリジェンスプラットフォームのKlueは2026年6月19日、同社の統合インフラを標的とした不正アクセスを受け、顧客のSalesforce環境に接続するOAuthトークンが窃取されたことを公式に認めた。恐喝グループ「Icarus」が犯行を声明し、被害組織のリストはセキュリティ企業を含む複数の著名ITベンダーに広がっている。 何が起きたか Klue CEOのJason Smith氏は6月12日に統合インフラの一部で不正活動を検知したことを明らかにした。調査の結果、攻撃者はレガシー認証情報（旧来の認証情報）から侵入し、KlueとSalesforceなどサードパーティプラットフォームを接続するOAuthトークンを入手。これを使ってKlueと連携している顧客のSalesforce環境に直接アクセスした。 Klueプラットフォーム内に直接保存されている顧客コンテンツへの影響はないとしているが、連携先を経由した被害は深刻な規模に達した。 攻撃の手口：Salesforce APIへの大規模クエリ セキュリティ企業ReliaQuestとHuntressが独立した調査でこの攻撃の詳細を明らかにした。攻撃者はKlue連携に紐付いたOAuth認証情報を使ってSalesforce APIを長時間にわたってクエリし、Pythonスクリプトを駆使して大量データを抽出した。 Huntress自身もKlue経由でSalesforceが侵害されており、ビジネスコンタクト情報・営業コミュニケーション・価格情報などが盗まれたことを認めている。 被害組織が拡大 Icarusはデータリークサイトで犯行を認め、被害組織に対してSession Messengerでの接触を要求している。現在までに被害を公表した組織は以下のとおりだ。 Recorded Future（脅威インテリジェンス企業） Tanium（エンドポイント管理） Jamf（Appleデバイス管理） Sprout Social（SNS管理） Gong（セールスインテリジェンス） Insurity（保険業向けソフトウェア） Huntress（セキュリティ企業） 各社ともSalesforceインスタンスのデータが盗まれたが、自社プラットフォームや決済情報には影響がないと説明している。また、盗まれたビジネスコンタクト情報を使ったフィッシング・ソーシャルエンジニアリング攻撃への警戒を呼びかけている。 KlueはCrowdStrikeと連携して対応にあたり、影響を受けた認証情報とトークンを即座に失効させ、不正コードを削除、当局へ通報済みだ。 日本のIT現場への影響 SaaS間連携を積極的に進めてきた組織ほど、今回のような「連携サービスを経由した横断的な侵害」のリスクを抱えている。日本企業でも以下のチェックを今すぐ行うべきだ。 OAuthアプリ・Connected Appsの棚卸し — 退職者が設定した、または試験的に設定したまま放置された連携はないか 統合サービスの認証情報ローテーション — Klueのような統合サービスが使う認証情報を定期的に更新しているか Salesforce APIアクセスログの監視 — 通常と異なるクエリパターン（大量・長時間・Pythonスクリプト）を検知できるか 連携スコープの最小権限確認 — サードパーティ連携に必要以上の権限を与えていないか 筆者の見解 今回の攻撃で最も注目すべきは、侵害の入口が「レガシー認証情報」だった点だ。ゼロトラストアーキテクチャをどれほど丁寧に構築しても、古い認証情報が一本残っていれば攻撃者はそこから入ってくる。「今動いているから大丈夫」は通用しない——これは何度でも繰り返す価値がある教訓だ。 もう一つの核心はNon-Human Identity（NHI）の管理だ。OAuthトークン・APIキー・サービスアカウントといった「人間ではない主体」のアイデンティティは、人間のアカウント管理に比べて圧倒的に後回しにされやすい。今回のKlueのケースはまさにその典型だ。SaaS連携のNHI管理こそが、業務自動化・効率化のボトルネックを解消しながら安全を保つ鍵になる。 ゼロトラストの観点では、常時アクセス権を持つ統合サービスの認証情報こそが最大のリスクだ。Just-In-Time（JIT）アクセスの考え方をサービス間連携にも適用し、必要なときだけ権限を与え、使い終わったら失効させる仕組みが求められる。VPNの時代が終わりを告げているのと同様に、「設定したらずっと有効」なOAuth連携の運用も見直しどきだ。 日本の多くの企業ではSaaS導入が先行し、連携管理が追いついていないケースが目立つ。今回の事案を「海外の話」で終わらせず、自社のSaaS連携を棚卸しするきっかけにしてほしい。 出典: この記事は Klue OAuth breach victim list grows as Icarus hackers claim attack の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは2026年6月、Windows 11の年次アップデート「26H2」を2026年秋（10月前後）に提供予定であることを公式ドキュメントで確認した。ただし今回も昨年の25H2と同様、約200KBの「有効化パッケージ（eKB）」として配布される超軽量な更新であり、実質的な新機能の追加はない。 Windows 11 26H2の正体——「バージョン番号を上げる」だけのアップデート 今回のWindows 11 26H2は、Microsoftが「eKB（enablement package）」と呼ぶ有効化パッケージとして提供される。ファイルサイズはわずか200KB程度で、インストールにかかる時間は再起動込みでも5分未満、場合によっては2分以内で完了する。 eKBの役割はシンプルだ。OSの内部バージョン番号とビルド番号を切り替えるだけであり、UIの変化や新機能の追加は一切ない。すでにWindows 11 24H2または25H2を使用しているPCは、外見上まったく同じ状態のまま「26H2」になる。 Microsoftはこのアプローチについて「組織やITプロフェッショナルに向けた、予測可能で低干渉な更新体験の継続」と説明している。 なぜ2年連続で「大型更新なし」なのか Windows 11の最後の大型機能アップデートは2024年10月1日リリースのWindows 11 24H2だった。25H2（2025年）、そして今回の26H2（2026年）は、いずれも24H2と同一のプラットフォームコードをベースにしており、新しいソフトウェア基盤は持ち込まれない。 Microsoftの方針として注目すべきは、大型機能を年次アップデートから月次の累積アップデート（Patch Tuesday）に分散配布する戦略への移行だ。たとえば近々のPatch Tuesdayでは「移動可能なタスクバー」のサポートが追加予定であり、先ごろの更新では「Low Latency Profile」という重要な機能が搭載された。以前はこうした機能変更が年次アップデートで一挙に届いていたが、今後は毎月の更新に組み込まれていく形に変わっている。 サポート期限とシステム要件 26H2へのアップグレードにおける最大の実益はサポート期間の延長にある。 エディション サポート終了日 Home / Pro / Pro EDU / Pro for Workstations 2028年10月 Enterprise / Education / IoT Enterprise 2029年10月 参考として、現行バージョンのサポート期限は以下のとおり： Windows 11 24H2：2026年10月13日終了 Windows 11 25H2：2027年10月12日終了 ハードウェア要件に変更はなく、4GB RAM・64GBストレージ・1GHz以上の64ビットデュアルコアプロセッサーというWindows 11の既存要件がそのまま適用される。 別ライン「Windows 11 26H1」との違い 混乱を避けるために触れておくと、Windows 11 26H1という別系統も存在する。こちらはNvidia N1（RTX Spark）やSnapdragon X2など次世代シリコン向けの新プラットフォームリリースだ。ただし26H1も現時点では排他的な新機能があるわけではなく、既存PCのユーザーが気にするのは26H2のみで問題ない。 実務への影響——IT管理者が今すべきこと 1. Windows 11 24H2ユーザーはサポート期限を確認 24H2のサポートは2026年10月13日に終了する。企業環境では計画的な26H2への移行スケジュールを策定すべき時期だ。 ...

Microsoftが、Microsoft EdgeブラウザへのGoogleアカウントでのサインイン機能を2026年7月から段階的にリリースすることをMicrosoft 365ロードマップ（ID: 565860）で公式確認した。さらに、Windows 11のセットアップ時にMicrosoftアカウント（MSA）を強制する要件についても廃止を検討していることが明らかになっている。長年続けてきたアカウント囲い込み戦略からの方針転換として注目を集めている。 EdgeにGoogleアカウントサインインが追加される 先行ビルドではすでに機能が確認されており、Edgeのプロフィールメニューに「Or sign in with」セクションが追加され、Googleボタンが表示されるようになっている。クリックするとGoogleの標準ログインページに遷移し、Edgeにサインインできる。 サインイン後はGmailアドレスがEdgeプロフィールのIDとして表示され、ブックマーク・パスワード・履歴などの同期も有効になる。MicrosoftアカウントなしでEdgeの同期機能が使えるようになるわけだ。対応OSはWindowsとmacOSの両方。 なお、エンタープライズ管理者はNonMicrosoftAccountSignInEnabledポリシーを使ってこの機能の有効・無効をコントロールできる。 Windows 11のローカルアカウント復活も視野に Edgeの変更と並行して、Windows 11のセットアップ時に要求されるMicrosoftアカウントのサインインを廃止する方向で、Microsoftの内部チームが作業を進めているとも報じられている。Windows 11がリリースされた2021年以来、ホームエディションでのローカルアカウントへの道は着実に狭められてきた。その流れが逆転するとすれば、約5年ぶりの大きな方針転換となる。 なぜこれが重要か MicrosoftがここまでMSAへの強制サインインにこだわってきた背景には、明確なビジネス上の理由があった。Bing Rewards、OneDriveのストレージ連携、Copilotの個別化、広告配信のターゲティング——これらはすべてMSAへのサインインが前提となっている。 その方針を転換し始めた最大の動機は、Chromeユーザーを取り込む現実的な判断を優先したからとみるのが自然だ。Googleアカウントと結びついた数億人のユーザーに対し「あなたのGoogleデータはそのままEdgeに移行できます」と言える体制を整えることで、スイッチングコストを大幅に下げる戦略だ。 EdgeはすでにChromeのブックマークやパスワードを継続的にインポートする機能を持っているが、「アカウント自体がGoogleのまま使える」というのは次元が異なる。 実務への影響 エンタープライズ管理者向け: NonMicrosoftAccountSignInEnabledポリシーで非MSAサインインを無効化できる。BYODや個人アカウントの混入を懸念する企業は、ロールアウト前にポリシーを確認・設定しておくことを推奨する Entra IDで管理されているデバイスでは、従来のMSAサインイン要件と今回の変更との相互作用を早期に検証しておきたい 個人ユーザー向け: ChromeからEdgeへの移行を試みたものの「Googleアカウントとの断絶」がネックになっていた場合、今回の変更でその障壁は大きく下がる Windows 11のローカルアカウント対応が実現すれば、法人PCのセットアップフローが大幅にシンプルになる可能性がある 筆者の見解 この変更は、Microsoftにとっての現実的な後退ではなく、むしろ賢い戦略転換だと見ている。 MSAへの強制サインインは、正直なところユーザーにとって摩擦でしかなかった。Windowsのセットアップ中にアカウント登録を迫られ、Edgeを使うたびにサインインを促されて辟易した人は少なくないだろう。その「囲い込み」がChromeやFirefoxへの流出を後押しした側面は否定できない。 今回の変更は、「囲い込まなくても選ばれるブラウザになれる」という姿勢への転換と読むこともできる。垂直タブ、没入型リーダー、AIタブオーガナイザーなど、EdgeにはChromeにない独自の価値がある。その強みで正面から勝負する方向に舵を切ったとすれば、遅きに失した感はあるが正しい判断だ。 Windows 11のローカルアカウント対応も同様だ。「MSAへの依存でユーザーをつなぎとめる」のではなく、「OSの使い勝手そのもので選んでもらう」方向性は、長期的に見てMicrosoftのブランド価値を高める。その力が十分あることは、長くMicrosoftを追いかけてきた立場からも疑いがない。 もちろん、Copilotや各種AIサービスとのシームレスな連携にはMSAが引き続き重要であり、完全なアカウント不要にはならないし、そうする必要もない。「使いたい人が使えばより便利になる」という本来あるべき設計に近づいているとすれば、大いに歓迎したい動きだ。 出典: この記事は Microsoft is killing the Microsoft account lock-in across products, Windows 11 may be next の内容をもとに、筆者の見解を加えて独自に執筆したものです。

ニューヨーク州の21歳男性・Anthony Belfordが、AIで生成した被害者のヌード画像を複数のSNSプラットフォームに投稿・拡散したとして、米連邦大陪審によりサイバーストーキング1件で起訴された。連邦法がAI生成の性的画像を実在の写真と同等に規制対象とすることが、実際の起訴事例として示された形だ。 事件の経緯 Belfordはかつてジョージア州の大学に転校した女性被害者と同じ大学に在籍していた。被害者が2024年8月に転校した後も、BelfordはInstagram・LinkedIn・Reddit・X（旧Twitter）・Strava・Yahooに偽アカウントを作成し、被害者に成りすましてAI生成ヌード画像を拡散した。 さらに、なりすましたLinkedInのプロフィール写真にAI生成ヌード画像を設定し、スプーフィングしたYahooメールアカウントから被害者の母親にAI生成画像を直接送付するという行為まで行った。2025年1月から3月にかけての約3ヶ月間、組織的・継続的なハラスメントキャンペーンを展開し続けた。 手口の技術的解説：AIと偽アカウントの組み合わせ 今回の手口の悪質さは、AIによる画像生成と偽アカウントのなりすましを組み合わせた点にある。 AI生成画像の悪用 現在の画像生成AIはSNS上の写真から高精度なフェイク画像を生成できるレベルに達している。以前のディープフェイク作成には専門的なスキルが必要だったが、今や敷居は大幅に下がっている。 多プラットフォームへの分散投稿 6つのプラットフォームに分散して拡散することで、プラットフォーム単独での削除対応を困難にし、被害を最大化させる構造になっている。職業プロフィールとして使われるLinkedInを標的にした点は、被害者のキャリアと人間関係の双方を攻撃する意図が読み取れる。 スプーフィングによる家族への侵食 Yahooメールのスプーフィングで被害者の家族にまで画像を送付している。単なるオンラインハラスメントを超え、リアルの対人関係へ侵食する手口だ。 米連邦法の対応：AI生成画像も規制対象 今回の起訴で重要なのは、米国司法省が「連邦法はAI生成画像を含む性的画像の無断共有を禁じている」と明言した点だ。被害者は自分のリアルな写真が流出したわけではないにもかかわらず、甚大な精神的・社会的被害を受けた。法律がこの現実に追いついた形だ。 オンラインプラットフォームが削除申請から48時間以内に対応しない場合は、連邦取引委員会（FTC）への通報が推奨されている。FTCの「Take It Down」プラットフォームでは、無断共有された画像・動画の拡散防止支援も提供されている。 日本のIT現場への示唆 日本でも類似手法によるハラスメント被害は増加傾向にあり、対岸の火事ではない。 企業・組織のIT管理者が取れる対策 偽アカウント検知の体制整備: 主要プラットフォームのブランド監視ツールを活用し、社名・社員名を騙る偽アカウントを早期検知する インシデント対応フローの設計: AI生成フェイク画像が社員を標的にした場合の報告・削除申請フローを事前に準備する 従業員への定期的な教育: AI生成ハラスメントの実態と報告窓口について周知徹底する エンジニアが意識すべきポイント 自社サービスにユーザー投稿機能がある場合、AI生成コンテンツの検出と報告フローは今後の必須要件になりうる。画像のメタデータ確認やAI生成検知APIの導入を検討する時期に来ている。 筆者の見解 この事件が技術的に示しているのは、AI・偽アカウント・スプーフィングという既存の手法を組み合わせることで、従来型の「一箇所を塞げば済む」対策が機能しなくなるという現実だ。 アイデンティティ管理の観点から見ると、これはNon-Human Identities（NHI）的な発想を悪意ある人間が手動で実行している構造とも言える。多数の偽アカウントをオーケストレーションして標的を包囲するアプローチは、正規の自動化ツールの悪用リスクと同根であり、プラットフォーム側の本人確認強化と挙動ベースの偽アカウント検知がますます重要になっている。 日本の法整備については、2023年改正プロバイダ責任制限法でアカウント開示請求が簡略化されたが、AI生成画像に特化した規制はまだ追いついていない部分がある。今回の米国での起訴事例が先例となり、日本でも議論が加速することを期待したい。 デジタルの傷はリアルの傷と同等の深刻さを持つ。被害を受けた場合は沈黙せず、プラットフォームへの削除申請と法執行機関への早期相談が何より重要だ。 出典: この記事は NY man charged after harassing college student with AI-generated nudes の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米サイバーセキュリティ・インフラセキュリティ庁（CISA）は2026年6月19日、Fortinet製デバイス利用者に対し、「FortiBleed」と呼ばれる大規模な認証情報流出事案を受けて直ちにセキュリティ対策を講じるよう緊急警告を発出した。流出した認証情報はファイアウォールおよびVPNゲートウェイを合わせて約7万3,932件に上り、世界中の政府機関・民間企業が攻撃の標的とされている。 FortiBleedとは何か 本事案を最初に発見したのは、セキュリティ研究者のVolodymyr「Bob」Diachenko氏だ。氏はインターネット上の公開サーバーに、Fortinet VPNのユーザー名・メールアドレス・平文パスワードが含まれる大量の認証情報が格納されているのを発見した。データには対象組織の業種・売上・従業員数まで付随しており、将来の攻撃計画に活用するために意図的に整理された可能性が高いとDiachenko氏は指摘している。 脅威インテリジェンス企業Hudson Rockによる分析では、このデータセットは2万1,632のユニークドメイン・194か国に及ぶ、既知最大規模のFortinet認証情報コレクションの一つと評価されている。影響を受けた組織にはSamsung、Mercedes-Benz、Foxconn、Chevron、AT&T、トヨタに加え、通信・医療・金融・製造業の重要インフラ事業者や多数の政府機関が含まれる。被害デバイス数が多かった国はインド、米国、台湾、メキシコ、トルコの順で、日本は直接名指しされていないものの194か国という規模を考えれば無縁ではない。 攻撃の背景——ロシア語圏グループによる組織的活動 Diachenko氏の調査によれば、今回の攻撃はロシア語圏の脅威グループによるもので、32万以上のFortiGateターゲットに対して約11億6,000万回もの認証試行を実施し、SSL VPN認証ハッシュを傍受したとされる。 ただし、認証情報の具体的な入手経路は依然として不明だ。既知の脆弱性の悪用なのか、新たなゼロデイなのか、それとも別の手法なのかは確認できていない。セキュリティ専門家のKevin Beaumont氏は独自調査で一部認証情報の正当性を確認しており、「データは本物で、対象デバイスのほぼすべてが依然オンラインのままだ」と改めて警鐘を鳴らしている。 CISAが求める即時対応 CISAはFortiGate利用者に対し、以下の対応を直ちに実施するよう求めている。 全SSL VPNセッションおよび管理セッションの即時終了 VPNおよび管理者パスワードの全件リセット フィッシング耐性のある多要素認証（MFA）の有効化 不正アクセスや横方向移動（ラテラルムーブメント）の痕跡をログで確認 管理者認証情報をPBKDF2ハッシュアルゴリズムで保護 ファイアウォール管理インターフェースをパブリックインターネットから切り離し、不正アカウントを削除 Hudson Rockは無料の「FortiBleed lookup tool」を公開しており、自組織のデバイスが対象に含まれるかどうかを確認できる。 実務への影響——日本のIT現場でいま何をすべきか FortiGateは日本国内でも企業・官公庁を問わず広く採用されているVPNゲートウェイ・ファイアウォール製品だ。今回の流出データが悪用された場合、外部からの侵入口となるだけでなく、内部ネットワークへの横展開（ラテラルムーブメント）の起点にもなりかねない。優先度順にアクションをまとめると以下の通りだ。 インターネットに公開されているFortiGate機器の棚卸しと管理インターフェースへのアクセス制限 VPN利用者・管理者アカウントのパスワード全件強制リセット MFAが未導入なら即刻導入（FIDO2/WebAuthn等のフィッシング耐性を持つ方式が望ましい） 過去30〜90日分のログを確認し、不審なアクセスや認証失敗のスパイクを調査 FortiSandboxを利用している場合は追加の脆弱性情報を確認（別途、複数の重大脆弱性が攻撃に悪用されているとの報告がある） 筆者の見解 今回のFortiBleed事案が改めて突きつけるのは、「VPNの認証情報そのものが大規模攻撃の標的になる」という構造的な問題だ。パスワードをリセットしMFAを付けることは当然やるべき応急処置だが、それで根本が解決するわけではない。 VPNは「信頼できるネットワーク内に一度入れれば自由に動ける」という前提で設計されている。しかし今回のように認証情報が大規模に流出した場合、攻撃者は正規ユーザーと区別がつかない状態でネットワークを歩き回ることができる。これはアーキテクチャの限界だ。 本質的な対策の方向性はゼロトラストへの移行にある。常時接続VPNで「ネットワークに入れる人間を信頼する」という考え方から、「どのユーザーが・どのデバイスから・何のリソースに・どんな文脈でアクセスするか」を毎回検証する仕組みに変えることが、こうした事案への構造的な答えになる。 日本の大企業・官公庁では、古いVPNベースの境界防御と部分的なゼロトラスト導入が混在し、管理の複雑さだけが増している現場も少なくない。今回の事案を、ゼロトラスト移行計画を本格化させる契機として活用してほしいと思う。 出典: この記事は CISA warns Fortinet users to secure devices after FortiBleed leak の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GentlemenランサムウェアグループがRaaS（Ransomware as a Service）の形態で、独自開発の「GentleKiller」を含む複数のEDR（エンドポイント検知・応答）キラーツールを積極的に整備・更新していることが、ESETの調査で明らかになった。標的となるセキュリティ製品は約48社・400プロセス以上に及ぶ。 EDRキラーとは何か、なぜ危険なのか EDRキラーとは、セキュリティ製品のプロセスを強制終了・無効化するツールだ。ランサムウェア攻撃では「まず目と耳をつぶす」のが常套手段であり、EDRを沈黙させることで、データ窃取や暗号化処理を検知されることなく実行できるようになる。 Gentlemenグループが使う主力ツール「GentleKiller」は現時点で8種類以上のバリアントが確認されている。各バリアントはKaspersky、Valorant、Javelin、WatchDogといった正規製品・ゲームクライアントに擬装しており、外見だけでの判断が難しい。 BYOVDで「カーネル」に直接侵入 GentleKillerが採用している技術が BYOVD（Bring Your Own Vulnerable Driver） だ。Windowsカーネルへのアクセス権を持つ正規ドライバーのうち、既知の脆弱性を持つものを攻撃者自身が「持ち込み」、それを悪用してカーネルレベルの権限を獲得する。 ESETの分析によれば、バリアントごとに異なる脆弱なドライバーを使用しているものの、コード難読化手法・プロセス終了ロジック・標的スコープは共通している。「ドライバーだけ差し替えれば新たな脆弱性にすぐ対応できる」設計になっており、攻撃者側のアップデートコストが極めて低い点が脅威を持続させている。 標的には Microsoft、CrowdStrike、SentinelOne、Palo Alto、Sophos、Trend Micro、ESET、Bitdefender、McAfee/Trellix、Kaspersky を含む約48社が並ぶ。著名なEDRのほぼすべてが対象に入っていると考えていい。バイナリはEnigma・Themidaという商用プロテクターで保護され、無効化された盗用デジタル署名を付与することで正規ソフトに見せかける工夫も施されている。 外部ツールの組み合わせで「多層冗長化」 GentleKiller以外にも、他グループが使ってきたEDRキラーを取り込んでいる： HexKiller — かつてWarlockギャングが使用 ThrottleBlood — MesudaLockerおよびDragonForce攻撃に関連 HavocKiller — 複数のランサムウェアオペレーションで確認 さらにRust製のクレデンシャル窃取ツール OxideHarvest も使用されており、ESETはプログラミング言語の選択から外部委託品と推定している。これらを組み合わせる理由としてESETは「冗長性の確保」「アトリビューション（攻撃者特定）の複雑化」「GentleKillerが効きにくいケースへの対応」の3点を挙げる。 FortiGate設定を標的のフィルタリングに利用 Gentlemenグループは被害者のFortiGateエンドポイント設定を基に攻撃対象を選定していることも判明している。これは最近発覚した「FortiBleed」——約7万4,000件のFortiGate VPN認証情報漏洩——との連鎖で特に注目に値する。すでにルーマニアのエネルギー事業者Olteniaへの侵害や、1,570台以上の企業被害ホストを抱えるSystemBCプロキシボットネットとの関連も報告されている。 実務への影響 日本のエンジニア・IT管理者が今すぐ確認すべき点を整理する。 1. 脆弱なドライバーのブロックリスト適用 Microsoftは「Microsoft脆弱ドライバーブロックリスト」を提供している。Windows 11ではデフォルト適用済みだが、Windows 10環境やエンタープライズのポリシー設定は手動確認が必要だ。 2. FortiGate VPN認証情報の即時ローテーション FortiBleedの影響を受けた可能性がある環境では、認証情報のローテーションと多要素認証の強制を最優先で実施すること。 3. EDRの「自己保護機能（Tamper Protection）」を有効化 プロセス終了を防ぐ自己保護機能が無効化されていないか確認する。 4. カーネルレベルの変化をSIEMで監視 ドライバーの新規ロードやカーネルモジュールの変更を検知するルールを追加する。BYOVDツールはここに必ず足跡を残す。 5. ネットワークセグメンテーションの徹底 感染後の横展開を遅らせるために、セグメンテーションとゼロトラストモデルの適用を加速させたい。 筆者の見解 このニュースを読んでまず思ったのは「EDRだけに頼るのがそもそも設計の誤りだ」という点だ。GentleKillerのフレームワーク設計は明快で、「どんなEDRも殺せるよう拡張可能」な構造を持ち、特定製品への依存を根本から崩しにくる。48社が標的リストに並んでいるという事実は、「有名なEDRを入れていれば安心」という前提を否定している。 BYOVDへの対抗はエンドポイント単体では完結しない。ネットワーク層・認証層・カーネル整合性の監視を組み合わせた多層防御が前提になる。「EDRが止まったら終わり」という構成はもはやリスクとして許容できない段階に来ている。 FortiGate設定情報をターゲティングのフィルタリングに使うという手口も示唆に富む。FortiBleedのような大規模な認証情報漏洩が、後続のランサムウェア攻撃の「被害者選別フィルター」として機能しているわけだ。単体インシデントで終わらない連鎖を前提にした防御計画が必要で、「ドライバーをブロックするか」という問いより「カーネルに何が入ってくるかを常時可視化できているか」という問いに立ち返ることが、今の防御設計に求められていると感じる。 出典: この記事は Gentlemen ransomware uses multiple EDR killers to disable defenses の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Googleは2026年8月3日以降、欧州経済領域（EEA）・英国・スイスのユーザーを対象に、IPアドレスを広告計測およびパーソナライズの目的で活用することを広告主に通知した。技術的にはこれまでもIPアドレスの受信は行われていたが、それを「デバイスの識別」に転用するのは今回が初めてとなる。 何が変わるのか Googleはすでに、トラフィックルーティングや広告配信の過程でユーザーのIPアドレスを受信している。カスタマータグ、SDK、HTTPリクエスト、アップロードなど複数の経路を通じてだ。 8月3日以降に変わるのは、その利用目的である。同じIPアドレスをデバイスの識別・広告パーソナライズに使用するという新たな目的が追加される。これはEU・英国の法律上、ユーザーの同意取得が必要なトリガーとなる行為だ。 あわせてGoogleは、IABヨーロッパの透明性・同意フレームワーク（TCF）におけるFeature 3——「自動的に送信される情報に基づくデバイスの識別」——に登録することも明らかにした。Feature 3自体はユーザーへの同意画面を直接意味するものではなく、パーソナライズ目的と組み合わさる形でユーザー同意が必要となる仕組みだ。 IPアドレスを広告識別に使うことは、プライバシー保護的技術（PET）——オンデバイス処理、信頼実行環境（TEE）、マルチパーティ計算——を活用した取り組みと説明されている。ただしIP利用を前提とした一部のパーソナライズ機能は、今年後半から来年初頭にかけて段階展開される予定だ。 なぜGDPR上で問題となるのか IPアドレスを広告に使う行為は、米国など他の地域ではすでに一般的だ。しかし欧州では話が異なる。GDPRの下ではIPアドレスは個人データに該当するため、それを使ったデバイス識別はフィンガープリンティングの基礎技術と見なされる。 フィンガープリンティングとは、クッキーが無効または削除された状態でもデバイスを追跡できる技術だ。クッキーと異なりユーザー自身が「消去」できない点で、プライバシー保護の観点から長年問題視されてきた。 Googleはかつて「不正」と断言していた ここで見逃せないのが、Googleの方針転換の経緯だ。 2019年、当時ChromeエンジニアリングディレクターだったJustin Schuh氏は「フィンガープリンティングはユーザーの選択を損なうものであり、不正だ」と明言していた。その根拠も明確で、「ユーザーがクッキーのように消去できないから」というものだった。 ところが2024年12月、Googleは広告主向けのフィンガープリンティング禁止ポリシーを自ら撤廃している。英国の情報コミッショナー（ICO）はこの方針転換を「無責任だ」と即座に批判した。 今回の8月からの展開は、その延長線上にある。 ICOは規制強化の検討中、タイミングが最悪 タイミングも不運だ。ICOは2026年5月18日、英国のオンライン広告における同意ルール見直しに関する助言を政府に提出したばかり。ICOが推奨するアプローチでは、「閲覧中のコンテキストに基づく広告」は同意不要とする一方、「ユーザーの行動履歴をもとにサービスをまたいでプロファイリングする広告」については同意を必須のまま維持する方針だ。 IPアドレスを使ったクロスサービスのパーソナライズは、この「同意が必要な側」に該当する。ICOは「現時点ではルールは変わっていない」と強調しており、既存の規制はそのまま適用されるとしている。 また、Googleが広告主に送った通知の文面では、コンプライアンス責任を広告主側に押しつける記述も見られる。「EU User Consent Policyへの準拠義務は引き続き広告主が負う」という内容だ。 ユーザーができること ユーザー向けにIPベースのパーソナライズを制御できる選択肢は、今後のロールアウトで提供予定とされているが、8月3日の適用開始時点では未整備だ。 当面は従来どおり、Googleアカウント設定の広告パーソナライズ画面（myadcenter.google.com）での設定変更や、ブラウザの非必須クッキーを拒否することが主な対策となる。ただしIPアドレス自体は「ブロック」できない性質のデータであるため、根本的な対策には限界がある。 実務への影響——日本のエンジニア・マーケターへ 日本企業にとっての直接的な影響は、Google広告を使って欧州・英国向けにマーケティングを行っている場合だ。8月3日以降、欧州ユーザー向けのキャンペーンでは、TCF Framework下での同意収集が改めて問われる可能性がある。 実務上の確認ポイントは以下のとおりだ： 同意管理プラットフォーム（CMP）の設定確認: TCF Feature 3に関する同意フローが適切に設定されているか プライバシーポリシーの更新: IPアドレスを広告目的で利用することへの言及が必要になる可能性 Google広告の設定確認: 欧州ユーザー向けの広告キャンペーンで、どの同意シグナルが有効になっているか 今後のICO動向のウォッチ: 英国では規制ルール自体の変更が検討中であり、2026年後半に方針が確定する可能性がある 日本国内だけの展開であれば今回の変更は直接関係しないが、欧州データ保護法の動向はグローバルスタンダードに影響するため、無関係とは言いきれない。 筆者の見解 「フィンガープリンティングは不正だ」と明言していた組織が、数年後に自らそれを解禁する。この一連の経緯は、プライバシー保護への姿勢がビジネス上の都合によって変わりうることを示した事例として記憶されることになるだろう。 より気になるのは、ユーザーが選択できるUI提供を後回しにしたまま適用だけが先に走る構造だ。「選択肢は後から提供する」というアプローチは、「禁止より安全に使える仕組みを先に整備すべき」というプライバシー設計の基本からズレている。技術的には優れた取り組み（TEEやMPC）を並べながら、ユーザー側の制御が追いついていない状態でのロールアウトは、信頼構築の順序として逆ではないかと感じる。 ICOが「無責任」と評した方針転換の直後にこの展開が来るタイミングも、規制当局との関係において賢明とは言いがたい。Googleには十分な技術力とリソースがある。ユーザーコントロールと事業要件を両立させる設計は不可能ではないはずで、その点で今回の進め方はもったいないと率直に感じる。 プライバシー規制の観点では、EU・英国での動向が今後の国際標準に影響を与える可能性がある。日本でも個人情報保護法の改正議論は続いており、IPアドレスの広告利用に関する解釈が問われる日が来るかもしれない。今のうちに同意管理の仕組みを整備しておくことが、長期的には最善の「道の真ん中」を歩く選択になるだろう。 出典: この記事は Google to use UK and EU user IP addresses for ad personalization の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleのAI開発部門「Google Gemini」の共同リードを務めていた著名AI研究者Noam Shazeer氏が、Googleを正式に退社し、OpenAIへの移籍を発表した。 Noam Shazeerとは——現代AIを生んだ論文の共著者 Shazeer氏の名が歴史に刻まれたのは2017年。Googleの研究者たちが共同発表した論文「Attention Is All You Need」の共著者として、現代のあらゆる大規模言語モデル（LLM）の基盤となるTransformer（トランスフォーマー）アーキテクチャを世に送り出した。 GPT-4もGeminiもClaudeも、すべてこの論文が起点になっている。それほど根本的な貢献をした研究者が、AI競争の最前線でチームを移動したのが今回のニュースだ。 Shazeer氏はGoogleに在籍後、AIチャットボット企業Character.AIを共同創業。その後はGoogle Geminiの共同リードとして再び同社の中枢に戻っていた経緯がある。 なぜこの移籍が業界を揺るがすのか AI産業において「誰が研究をするか」は、「どんなモデルが生まれるか」を直接決定する。Transformer論文の共著者の一人がOpenAIへ移籍することは、単なる人事情報ではなく、次世代モデルの研究方向が変わる可能性を示唆している。 GoogleはGeminiを中心に独自のLLM戦略を進めており、Shazeer氏は同チームのキーパーソンだった。その喪失がGeminiの開発速度・研究の深さにどう影響するかは、今後数ヶ月で明らかになるだろう。 一方、MicrosoftはOpenAIに深く出資・統合しており、研究陣の強化はAzure OpenAIサービスを通じて間接的にMicrosoftのAIエコシステム全体にも影響を与えうる。 実務への影響——日本のエンジニアはどう受け取るべきか 「どのモデルを使うか」の判断軸が変わる可能性 現在、企業向けのAI活用ではAzure OpenAIサービス経由でGPTモデルを使うケースが増えている。Shazeer氏のOpenAI参加は中長期的に研究力強化につながりうる。今後のモデル選定では、単にAPIコストを比較するだけでなく、各ベンダーの研究開発への投資動向も判断材料にしたい。 Transformer以降の「次のパラダイム」への注目 「Attention Is All You Need」は8年前の論文だが、いまだに現役の基盤技術だ。この先に何が来るかについて、Shazeer氏のような研究者がどこで何を研究するかは業界全体のロードマップに影響する。動向を継続的にウォッチしておくことをお勧めする。 研究者の移動から読む採用・育成の示唆 AI研究のトップ人材がどの組織に集まるかで、数年後のモデル性能が決まる。自社でAIを本格活用しているなら、ベンダーの財務状況や研究投資の姿勢も評価軸に加える時代に入っている。 筆者の見解 「Attention Is All You Need」は、もはや教科書の第一ページに載るべき歴史的業績だ。その共著者が研究の場所を変えることは、スポーツで言えばオールスタープレーヤーがチームを移籍するのに近い。ファンの注目を集めるだけでなく、試合結果（＝モデル性能）にも直結する話だ。 MicrosoftはOpenAIとの深い連携という構造的な強みを持っており、今回の移籍はその連携の価値を高める一因にもなりうる。Azure OpenAI経由で提供されるサービスへの恩恵がどう現れるかは、今後のモデルアップデートの中身を見ながら判断したい。 一方で、Googleも簡単に研究力を失うわけではない。DeepMindを含む研究体制は世界最高水準であり、Geminiがこの変化にどう応答するかも注目に値する。AI業界の「主役交代」が本当に起きているのか、一時的な人材流動に過ぎないのかは、1〜2年後のモデルクオリティが答えを出す。 私たちIT実務者にとって重要なのは「どのベンダーを応援するか」ではなく、「今使えるベストな技術は何か」という実用的な視点だ。このニュースを、モデル選定や技術ロードマップ策定の判断材料として冷静に活用してほしい。 出典: この記事は Google Gemini co-lead Noam Shazeer is leaving for OpenAI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIが、研究機関・大学向けに特化した新サブスクリプション「ChatGPT for Science」をウェブビルド上でひそかにテストしていることが、コードリークによって明らかになった。公式アナウンスは数週間以内と見られており、科学研究の現場にAIが本格的に組み込まれる時代が近づいている。 現行プランと「ChatGPT for Science」の位置づけ 現在OpenAIはChatGPTのサブスクリプションとして、個人向け・Teams・エンタープライズの3段階を展開している。 プラン 対象 Personal 誰でも利用可 Teams 会社ドメイン＋最低3ユーザー必要 Enterprise 法人格を持つ組織が対象 新たにテストされている「ChatGPT for Science」は、認定を受けた研究機関や大学に利用資格が限定される見通しだ。通常の個人向けプランとは異なり、「誰でも購入できる」形にはならない可能性が高い。 GPT-Rosalindとの関係——すでに「研究特化AI」は動いている OpenAIがサイエンス領域に力を入れているのは今回が初めてではない。同社はすでにGPT-5.5アーキテクチャをベースとしたGPT-Rosalindを発表している。これは単なる汎用モデルにサイエンス向けプロンプトを当てたものではなく、エンタープライズ規模のライフサイエンス研究に向けて根本から設計された特化モデルだ。 GPT-Rosalindへのアクセスは「トラステッドアクセス展開」と呼ばれる厳格な管理下に置かれており、現時点ではNovo Nordiskのような大手製薬企業や公益目的の認定研究機関のみが利用可能。ChatGPT Enterpriseと同等以上のセキュリティ・ガバナンス要件が課されている。 ChatGPT for Scienceは、GPT-Rosalindのこうした機能を、ごく限られたパートナーではなくより広い研究機関に解放するための仕組みになり得ると見られている。通常サブスクリプションよりも科学的発見・研究文献に深く根ざしたグラウンディングを持つプランとして設計される見込みだ。 実務への影響——日本の研究機関・大学IT担当者が今から動くべきこと GPT-Rosalindの前例が示す通り、OpenAIは研究用途の高機能モデルへのアクセスに、エンタープライズグレードのセキュリティ体制と組織の正当性証明を要求してきた。ChatGPT for Scienceでも同様の条件が課される公算が高い。今から準備を進めた組織が半年後に差をつけることになる。 今すぐ整備しておくべき基盤 SSO・IdP連携の整備（Microsoft Entra IDやOktaとの統合） 研究データの外部送信に関する倫理審査・契約の整備（個人情報保護・研究倫理の観点からの事前確認） 利用者管理の可視化——誰が、どの研究目的で使っているかをITが把握できる状態 パイロット導入の設計——文献検索・仮説生成・論文要約など繰り返し業務への試験的組み込み AIの研究ワークフローへの組み込みは、研究者の生産性を根本から変える可能性がある。体制整備なしに「購入だけした」状態は、かえって管理リスクを増やすだけだ。研究支援部門とIT部門が連携して活用フローを設計しておくことが先決となる。 筆者の見解 「研究専用AI」という切り口は、サブスクリプション追加以上の意味を持つ。科学研究の再現性・信頼性が社会的に問われている中、AIが研究プロセスのどこに介在するかは、倫理的にもガバナンス的にも慎重に設計される必要がある。OpenAIがGPT-Rosalindで採用した「トラステッドアクセス」の考え方——要するに誰でも使えるにはしない——は筋が通っている。 そのうえで気になるのは、日本の大学・研究機関が実際にこのプランを使いこなせる体制にあるかどうかだ。契約・倫理審査・データガバナンスのいずれも追いついていない組織は、「使えるはずなのに使えない」状況に陥りやすい。研究現場でAIが本格活用される局面は確実に来る。今から動き始めた組織がその波に乗れる。アナウンスを待ってから動くのでは遅い。 出典: この記事は Leak confirms OpenAI is testing a ChatGPT for Science subscription の内容をもとに、筆者の見解を加えて独自に執筆したものです。

MicrosoftがWindows 11向け「新Outlook」のオフライン状態でのファイル添付機能を2026年4月より全ユーザーへ展開した。2025年10月からのテスト期間を経てのリリースだが、なぜこれほど時間がかかったのか——その答えは新Outlookの根本的なアーキテクチャにある。 新Outlookの正体：Edgeブラウザを内包したウェブアプリ 新OutlookはWindowsネイティブアプリではない。実体はWebView2コンテナ内でOutlook.comを表示するウェブアプリだ。タスクマネージャーで確認すると、OutlookのプロセスにはEdgeブラウザを支えるService WorkerやWebGPUと同じコンポーネントが並んでいる。 平たく言えば「Edgeタブの中でOutlookを開いている」状態に近い。 この設計自体が技術的に誤りとは言い切れない。Progressive Web App（PWA）の仕組みを活用すれば相応のオフライン機能も実装できるし、クロスプラットフォーム展開やウェブ技術の継続的な進化を取り込みやすい利点もある。 問題は、Outlookがカジュアルなウェブメールではなくエンタープライズ向けの高度なクライアントだという点だ。 オフライン対応の現状と仕組み 2025年にメール閲覧とカレンダーのオフライン閲覧が実装され、今回ようやくオフラインでのファイル添付が加わった。 技術的な仕組みはこうだ。WebView2アプリはローカルディスク上のUser Data Folder（UDF）にキャッシュデータを保存する。オフライン時に作成したメールや添付ファイルはLocalStorageデータベースに一時保存され、ネットワーク復帰後に自動送信される。 注意点として、新OutlookはOutlook ClassicやMail & Calendarアプリよりも多くのディスクスペースを消費する。オフライン機能を積極的に活用するほどローカルストレージへの負荷が増加する点を把握しておきたい。 オフライン添付機能を有効にするには、Outlookの設定で「全般」→「オフライン」→「ファイル添付を含める」をオンにする。 今後の改善ロードマップ オフラインメールの保存期間は現在180日間が上限だが、1年または2年への拡張が予定されており、「Settings > General > Offline > Days of email to save」から設定できるようになる見込みだ。 その他にも複数の機能強化が予告されている。 全アカウント統合受信トレイ（複数メールアカウントのメールを1画面で確認） メールのマージ機能（スレッドを束ねて整理） 機能ロードマップは着実に前進しているが、Outlook Classicと比較したとき、起動速度（新Outlookはメール表示まで10秒以上かかる場合がある）や操作性の差は依然として大きい。 実務への影響 移行判断は慎重に 現時点でOutlook Classicからの強制移行タイムラインはMicrosoftから明示されていないが、企業環境では事前検証と社内展開計画の策定を早めに進めておくことを推奨する。 特に以下のユーザー層は新Outlookとの相性を入念に確認したい。 頻繁にオフラインで作業する出張族・現場担当者 大容量添付ファイルを日常的に扱う業種（設計・映像・製造等） COM/VBAアドインに依存したカスタマイズ済みOutlook環境（新Outlookではサポート外） ストレージ管理を事前に 新OutlookがオフラインデータのキャッシュとしてUDFを活用する点は把握しておきたい。オフライン保存期間を延ばす設定を有効にする場合は、対象端末のディスク空き容量を事前に確認することを強くお勧めする。端末管理ポリシーでローカルストレージに上限を設けている環境では、UDFの保存先パスも意識する必要が出てくる。 筆者の見解 新OutlookがWebView2でウェブアプリをラップする方向性を選んだ背景には、クロスプラットフォーム対応、継続的なウェブ技術との同期、開発リソースの効率化という意図が読める。中長期の戦略として理屈は通る。 ただ、Outlookは何百万もの企業ユーザーが毎日の仕事を委ねているツールだ。オフライン状態でファイルを添付する機能——それはOutlookの旧バージョンから当然のように提供されてきた機能であり、それが2026年になってようやく「全ユーザーに展開」されるという事実は、エンタープライズ製品として率直に「もったいない」と思う。 Microsoftには、統合プラットフォームとしてのエコシステム全体を活かして最終的な完成形に辿り着く技術力と資産がある。今後予告されている機能追加のロードマップを見れば、方向性は間違っていない。新Outlookが「使えるツール」として評価される日が来ることを期待しつつ、当面のエンタープライズ展開判断はClassicの動向を横目に見ながら慎重に進めるのが賢明だろう。 出典: この記事は Microsoft still can’t make Windows 11’s New Outlook work offline because it refuses to go native の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Windows Defenderのゼロデイ脆弱性「RoguePlanet」（CVE-2026-50656）に対するパッチを現在開発中であることを公式に認め、セキュリティアドバイザリを公開した。完全パッチ適用済みのWindows 10・11でも悪用可能であり、パッチ提供時期は未定のまま攻撃リスクがさらされている。 RoguePlanetとはどんな脆弱性か RoguePlanetはMicrosoft Malware Protection Engine——Defenderのコアエンジン——に存在するレースコンディション（競合状態）の脆弱性だ。攻撃者がこれを悪用すると、SYSTEM権限でコマンドプロンプトを起動できてしまう、いわゆる「特権昇格（EoP）」の脆弱性である。OSの最上位権限を乗っ取られることを意味し、その先の攻撃展開は無制限に広がる。 この脆弱性を発見・公開したのは「Nightmare Eclipse」と名乗るセキュリティ研究者。2026年6月のPatch Tuesday当日に、PoC（概念実証コード）を自前のGitリポジトリで公開した。GitHubやGitLabは以前MicrosoftからのリクエストでリポジトリをBanされたとして、自ホスティングに切り替えている。 レースコンディション脆弱性ゆえの「不規則性」 レースコンディション系の脆弱性は確率的な挙動をとる。Nightmare Eclipse本人も「一部のマシンでは100%成功したが、別のマシンでは不安定だった」と述べており、環境依存性が高い。 ただし特に注目すべきは、リアルタイム保護が有効でも無効でも機能するという点だ。「Defenderを有効にしているから安全」という思い込みは今回には通じない。セキュリティ製品そのものが攻撃ベクターになるという皮肉な状況であり、管理者はDefenderの状態だけで安全を判断しないよう気をつけたい。 MicrosoftはCVE-2026-50656として正式にIDを割り当て、「高品質なセキュリティアップデートを提供するために取り組んでいる」とアドバイザリで述べているが、リリース時期の明言はない。 研究者とMicrosoftの長期的な対立 RoguePlanetは孤立した事例ではない。Nightmare Eclipseはここ数ヶ月で、BlueHammer・RedSun・GreenPlasma・MiniPlasma・YellowKey・UnDefendと、WindowsコンポーネントやDefender・BitLocker関連のゼロデイを次々と公開してきた。その背後にあるのは、Microsoftのバグバウンティ制度と脆弱性開示プロセスへの強い不満だ。 Microsoftはこれに対し「顧客に実害をもたらす悪意ある活動」への法的措置も辞さないと警告。セキュリティ研究者コミュニティの間では、この表現が研究者個人への脅しと受け取られ、批判を集めた。 なお、GreenPlasma・MiniPlasma・YellowKeyの3件は6月のPatch Tuesdayで修正済み。RoguePlanetはその後に開示されており、修正が未適用のまま残っている状況だ。 日本のIT管理者が今できること パッチが存在しない以上、完全な防御は不可能だが、攻撃の連鎖を断ち切るための対策は存在する。 Defenderの定義・エンジンを最新状態に維持する: 本脆弱性のパッチではないが、エンジン更新に関連する変更が含まれる可能性がある 最小権限の原則を徹底する: SYSTEM権限が奪われた後の横展開を防ぐため、アカウント分離・ネットワーク分離を強化する EDR/SIEMの検知ルールを見直す: 不審なSYSTEMプロセス生成やコマンドプロンプトの異常起動を検知できるルールが入っているか確認する パッチリリース即展開の体制を整備する: Defenderは自動更新が基本だが、組織ポリシーで遅延設定している場合は展開プロセスを前倒しで見直しておく 特に大規模環境では「パッチが出てから考える」では遅い。今のうちにDefender関連パッチの緊急展開フローを確認しておきたい。 筆者の見解 技術的に見て、Defenderのコアエンジンにレースコンディションが存在したという事実は興味深い。セキュリティ製品は高度に複雑なソフトウェアであり、こういった脆弱性がゼロになることは現実的にはありえない——そのこと自体は理解できる。 ただ、Nightmare Eclipseが次々とゼロデイを公開し続けるという異例の展開は、Microsoftのバグバウンティ制度の設計に根本的な問題があることを示唆している。研究者を「顧客への脅威」として法的に牽制するよりも、正当な報告に対して適切な評価と報奨を行う仕組みを整える方が、長期的には顧客保護につながるはずだ。Microsoftにはその実力があるからこそ、もったいないと感じる。 Defenderは世界中の何億台ものWindowsデバイスを守る要だ。その信頼性を高めるためにも、セキュリティ研究者コミュニティを敵に回すのではなく、協調関係を築く方向に舵を切ってほしい。今からでも遅くはないと思っている。 出典: この記事は Microsoft working on Defender patch for RoguePlanet zero-day の内容をもとに、筆者の見解を加えて独自に執筆したものです。

セキュリティ企業Aikido Securityは2026年6月、JetBrainsマーケットプレイスに公開されていた15本の悪意あるIDEプラグインを発見した。これらのプラグインはOpenAI、DeepSeek、SiliconFlowなどのAI APIキーをユーザーの設定から密かに窃取する仕組みを持ち、累計約70,000回インストールされていた。 何が起きたのか Aikido Securityの調査によると、今回発見された15本のプラグインは7つのベンダーアカウントから公開されており、AIコーディングアシスタント、コードレビューツール、Gitユーティリティなど、開発者が日常的に使うカテゴリを装っていた。 プラグイン自体は「宣伝通りに動作する」ため、ユーザーが不審に思うきっかけが少ない。窃取が発生するタイミングは、ユーザーがプラグイン設定画面にAPIキーを入力して「Apply」ボタンをクリックした瞬間だ。その際、APIキーがHTTP経由でハードコードされたIPアドレス（39.107.60.51）に送信される。 最初のプラグインが公開されたのは2025年10月。2026年6月10日時点でも新しいプラグインが追加されており、8ヶ月以上にわたって継続的に活動していた。 「無料で使えるAPI」という罠 このキャンペーンには単なるAPIキー窃取以上の仕組みが潜んでいる。 プラグインには有料プランが組み込まれており、ユーザーが少額の寄付（ドネーション）を支払うと、サーバー側からAPIキーが「提供」される仕組みだ。Aikido Securityはこの点について、「無料ユーザーから収集したAPIキーを有料ユーザーに再配布している可能性がある」と指摘している。 正規のAIサービス運営者が、制限なしで動くAPIキーを外部に配布する理由はまったく存在しない。この「おかしな気前の良さ」こそが、攻撃者が他人のクレデンシャルを横流ししているという証左だ。 対象となった主要プラグイン 最もダウンロード数が多かったのは以下の2本だ： DeepSeek AI Assist（プラグインID: ord.cp.code.ai.kit）— 27,727回 CodeGPT AI Assistant（com.my.code.tools）— 25,571回 その他、DeepSeek系ツールやAI FindBugs、AI Git Commitorなど計15本が確認された。BleepingComputerによる独自検証では、本記事執筆時点においても一部プラグインがJetBrainsマーケットプレイスから削除されていないことが確認されている。 実務への影響——今すぐやること 被害確認の手順 JetBrainsのIDEを使用している開発者は以下を確認してほしい。 インストール済みプラグインの棚卸し: 上記15本のプラグインIDと照合する APIキーの即時無効化と再発行: 該当プラグインを使用していた場合、OpenAI・DeepSeek・SiliconFlowの管理コンソールでAPIキーを直ちに無効化する 使用量の監査: 窃取されたAPIキーが不正利用されていないか、過去の利用ログを確認する 組織レベルの対策 チームでAPIキーを管理している場合、以下も検討すべきだ： 開発者が個人でAPIキーをIDEプラグインに直接入力する運用を見直す APIキーにはレートリミットや用途スコープの制限を設定する 可能であればサーバーサイドのAPIプロキシを経由させ、開発者マシンにフルキーを渡さない構成にする プラグインの信頼性評価 今後の予防策として、JetBrainsマーケットプレイスでプラグインをインストールする前に： ベンダーの公式サイト・GitHubが存在するか確認する 公開から日が浅い（数週間〜数ヶ月以内）プラグインは慎重に扱う ソースコードが公開されていないプラグインへのAPIキー入力を避ける 筆者の見解 セキュリティの話題はあまり得意ではないが、今回の件は技術的に興味深いポイントがいくつかある。 まず、このキャンペーンが「ちゃんと動くプラグイン」として実装されていた点だ。機能しないマルウェアはすぐ排除されるが、機能しながら裏で動く脅威は検出が難しい。開発者が「使えるツール」と認識している時点で、疑いのトリガーが発動しない。 もう一つは、AIサービスのAPIキーが「換金性の高いクレデンシャル」として明確に狙われるようになったという現実だ。OpenAIやDeepSeekのAPIキーは即座にコストに換算できるアセットであり、この種の攻撃は今後も増加していくとみるべきだろう。 Non-Human Identity（NHI）の管理という観点からも、APIキーは「機械のIDカード」に相当するアセットだ。その管理をプラグインベンダーの善意に委ねる設計は、そもそも構造として脆弱と言える。「APIキーは環境変数や秘密管理サービスで管理する」という原則が、IDEのプラグイン設定にも同様に適用されるべき時代になっている。組織のセキュリティポリシーに「AIサービスAPIキーの管理ルール」が含まれていない企業は、今回の件を契機に整備を検討してほしい。 JetBrains側の対応の遅さも気になる。BleepingComputerの取材に対して回答がなかったという事実は、マーケットプレイスの審査・監視体制に課題があることを示唆している。npmやPyPIと同様に、IDEプラグインマーケットプレイスも悪意あるコードの配布経路になりうることが、今回で改めて証明された。プラットフォームを提供する側の責任として、審査の強化と迅速な対応を期待したい。 出典: この記事は Malicious JetBrains Marketplace plugins steal AI API keys from developers の内容をもとに、筆者の見解を加えて独自に執筆したものです。

リード ESETのリサーチャーが、中国系APTグループ「Earth Lusca」（別名：FishMonger、Aquatic Panda）によるWindows向けバックドア「SprySOCKS」の新変種を発見した。2023〜2024年にかけて、台湾・タイ・パキスタン・ホンジュラスの政府機関を対象とした標的型攻撃に使われていたことが確認されている。 Earth Luscaとはどんる脅威グループか Earth Luscaは中国との関与が高い信頼度で疑われる国家支援型の脅威アクターで、外交・テクノロジー・通信分野の政府機関を長年にわたり標的にしてきた。これまでSprySOCKSのLinux版が同グループによって展開されてきたことはセキュリティコミュニティに広く知られていたが、今回のESETの調査によって、Windowsエコシステムにも攻撃の矛先を広げていたことが明らかになった。 同グループは「Red Dev 10」「TAG-22」などの別名でも追跡されており、複数のセキュリティベンダーが観測を続けている。 2つのWindows変種：WIN_DRV と WIN_PLUS 今回発見されたWindows版SprySOCKSには、用途が異なる2つの変種が存在する。 WIN_DRV：カーネルレベルのステルス機能搭載 より高度なのがWIN_DRVだ。「RawWNPF」という名のカーネルドライバーをメモリに直接ロードする機能を持ち、これにより次のような「見えなくなる」能力を獲得する： プロセスの隠蔽：Windows API操作によりタスクマネージャー等から姿を消す ネットワーク接続の隠蔽：不審な通信を外部から見えなくする ファイルの隠蔽：ディレクトリ一覧に表示されない レジストリエントリの隠蔽：永続化用のキーを隠す さらに巧妙なのが通信手法だ。受信TCPトラフィックを検査し、特定の細工されたパケットだけをSprySOCKSバックドアにリダイレクトする。これによってバックドアが実際にリッスンしているポートをネットワークトラフィック上に露出させることなくC2通信が可能になる。 ドライバーのロードには「DriverLoader（fsdiskbit.sys）」が使われており、GitHubの「PastDSE」プロジェクトから流出した証明書で署名されている。いわゆるBring Your Own Vulnerable Driver（BYOVD）の応用だ。 WIN_PLUS：シンプルだが機能的なバックドア WIN_PLUSはWIN_DRVよりシンプルな構造ながら、実用的な機能を備えたバックドアだ。Windows Print Processor（VSPMsg）として自身を登録することで持続性を確保する。 両変種に共通する主な機能は以下のとおり： TCP・UDP・WebSocketでの通信 30種類以上のC2コマンドのサポート システム情報の収集、プロセス・サービスの管理 ファイルの列挙・作成・削除・アップロード・ダウンロード・実行 SOCKSプロキシ機能（クライアント・サーバー双方として動作可能） キーストローク・クリップボード内容・アクティブウィンドウタイトルのログ記録 UEFIブートキットの可能性も ESETのテレメトリデータには、CVE-2023-24932（Secure Bootの脆弱性）を悪用するUEFIブートキットコンポーネントの痕跡も確認されたという。この脆弱性はかつて「BlackLotus」UEFIマルウェアがゼロデイとして利用したことで知られている。 現時点でBlackLotusとの直接的な関連を示す強固な証拠はないとESETは慎重に述べているが、Secure Bootレイヤーまで攻撃が及ぶ可能性は見逃せない。 偶然の一致かもしれないが、このレポートが公開されたのは、2026年6月24日に旧来のSecure Boot証明書が失効するタイミングと重なっている。 実務への影響：日本のエンジニア・IT管理者へ 今回の報告が示す脅威は、日本の政府機関・重要インフラ事業者にとっても無縁ではない。以下の対策を実務として検討してほしい。 1. カーネルドライバーの監視強化 脆弱な証明書を使ったドライバーのロードを検出するため、Microsoft Defender for Endpoint（MDE）の「Attack Surface Reduction（ASR）」ルールを有効化し、WDAC（Windows Defender Application Control）でドライバー署名ポリシーを厳格化する。 2. Windows Print Spoolerの権限制限 WIN_PLUSはPrint Processorとして偽装して永続化する。印刷機能が不要なサーバー・端末ではSpoolerサービスを無効化する（これはPrintNightmare以来の定番対策でもある）。 3. スケジュールタスクとIFEOの定期監査 WIN_DRVはスケジュールタスクとImage File Execution Options（IFEO）を利用して永続化する。定期的にこれらのエントリを棚卸しする自動化スクリプトを仕込んでおくと早期検出につながる。 ...

米国司法省（DOJ）は2026年6月13日、非同意AI生成ヌード画像を公開していたウェブサイト「CFAKE.com」および「SOCFAKE.com」のドメインを差し押さえたと発表した。2025年5月に成立したTAKE IT DOWN法に基づく初の公式ドメイン差し押さえ事例とみられる。 CFAKE・SOCFAKEとは何だったのか これらのサイトは、政治家・女優・アスリート・ジャーナリスト・王族など複数国の著名女性を被写体にした、AI生成の性的ディープフェイク画像・動画を大量に公開していた。DOJの声明によると、対象には複数国のファーストレディや王族も含まれていた。 ディープフェイクとは、既存の写真・動画・音声から本人が実際には行っていない行動や発言を「したかのように」見せるAI生成メディアの総称だ。近年は生成AIの精度向上に伴い、非同意ポルノ（NCII: Non-Consensual Intimate Imagery）の生成ツールとして悪用されるケースが急増している。 国際連携捜査の全容 今回の捜査はイタリア郵便・サイバーセキュリティ警察が米当局に情報提供したことで始まった。イタリアは2025年10月に被害申告を受理し、国内でのアクセス遮断命令を取得しながら捜査を継続。その後、証拠が米国経由でフランスに共有され、フランス検察が独自に捜査を展開。2026年6月10日にはフランス・ニースで容疑者が逮捕され、関連する暗号資産も押収された。 ドメイン差し押さえには米国土安全保障省捜査局（HSI）ニュージャージー支局、DOJコンピュータ犯罪・知的財産部門、フランス国家警察、パリ検察局、イタリア郵便・サイバーセキュリティ警察が参加した。まさに多国間連携の成果だ。 TAKE IT DOWN法とは 2025年5月にトランプ大統領が署名したTAKE IT DOWN法（47 U.S.C. § 223）は、本人の同意を得ない性的画像・ディープフェイクの公開を連邦犯罪として定めた法律だ。特に注目すべき条項が、48時間以内の削除義務だ。被害者からの申告を受けたオンラインプラットフォームは、48時間以内に当該コンテンツを削除しなければならない。 超党派で支持されたこの法律は、メラニア・トランプ大統領夫人が「Be Best」活動の一環として推進したことでも知られる。 違反者には罰金または禁固刑、もしくはその両方が科せられる。 実務への影響——日本のエンジニア・IT管理者にとっての意味 プラットフォーム事業者は対岸の火事ではない。日本でもユーザー投稿型コンテンツを扱うサービスは多い。TAKE IT DOWN法は米国法だが、サービスが米国ユーザーを対象とする場合、あるいは将来的に日本でも類似法制が整備された場合、同等の削除対応義務が生じうる。48時間以内の削除を確実に実現するインシデント対応フローと通報受付窓口の整備は、今から取り組んでおく価値がある。 AI生成コンテンツのリスク管理は技術的課題だ。生成AI機能をサービスに組み込む際は、悪意ある利用（NCII生成・なりすまし・フィッシング）を想定した入力バリデーションとコンテンツフィルタリングが不可欠になっている。「使えないようにする」禁止アプローチではなく、正規用途を便利にしながら悪用の検出・遮断を組み込む設計が求められる。 暗号資産の押収は収益化阻止の観点から重要。今回フランス当局が運営者の暗号資産を押収した点は見落とせない。違法コンテンツビジネスの収益モデルを断つアプローチが国際的に定着しつつある。 筆者の見解 セキュリティ系の話題は正直好みではないが、今回の摘発は純粋に技術・法制度・国際連携の三つが噛み合った好例として評価したい。 注目したいのは48時間削除義務という設計思想だ。「禁止する」のではなく「通報されたら48時間以内に対応しなければ違法」という仕組みにすることで、プラットフォームに構造的な責任を負わせている。これは「禁止より仕組みを作れ」という考え方に近く、実効性の高いアプローチだと思う。 一方で課題もある。有名人を対象にした大規模サイトは摘発しやすいが、一般人を標的にした小規模なケースや分散型プラットフォームへの対応はまだ十分ではない。法整備と技術的な検出手段が追いつくまでの間、被害は続く。 日本では現時点でTAKE IT DOWN法に直接相当する法律はないが、プロバイダ責任制限法の改正議論が続いており、類似の方向性が検討されている。日本のIT事業者も「法律が通ってから考える」ではなく、今のうちに対応フローを整えておくのが現実的な判断だろう。 国際連携捜査の精度が上がり、暗号資産追跡技術が成熟してきた今、「どこかのサーバーに置けば大丈夫」という時代は終わりつつある。それ自体は良い変化だ。 出典: この記事は DOJ seizes CFAKE, SOCFAKE deepfake nude sites under TAKE IT DOWN Act の内容をもとに、筆者の見解を加えて独自に執筆したものです。