Windows

セキュリティ企業Mandiantは2026年6月24日、Cisco Catalyst SD-WAN製品群の脆弱性CVE-2026-20245が実際のゼロデイ攻撃に悪用され、攻撃者がroot権限を持つ不正アカウントを標的デバイスに作成していた詳細を公開した。攻撃者は証拠を巧みに消去しており、侵害を把握できていない組織が存在する可能性がある。 攻撃の全容——4段階で侵入し、痕跡を完全消去 今回の攻撃は単純な脆弱性悪用ではなく、複数フェーズで構成された精緻なオペレーションだ。 第1段階：不正なSD-WANピアリング接続の確立 2026年3月から、攻撃者はあるサービスプロバイダのインフラに対して不正なピア接続を確立し、vmanage-adminアカウントを使ってSD-WAN Managerに認証した。Mandiantは、この初期アクセスに認証バイパスの脆弱性CVE-2026-20127およびCVE-2026-20182が関与していた可能性を指摘しているが、確定はしていない。 第2段階：情報収集とパスワード偽装 アクセスを得た攻撃者は管理者アカウントのパスワードを変更し、SD-WAN Manager WebUIにログイン。エッジデバイス・コントローラー・SD-WANテンプレートの設定情報を抜き取ったのち、活動完了後にパスワードを元に戻すという巧妙な隠蔽工作を行っている。 第3段階：CVE-2026-20245によるroot権限奪取 核心となるのがCVE-2026-20245の悪用だ。攻撃者はSD-WANのCLIに存在するテナントアップロード機能を悪用し、evil_tenant.csvと名付けた細工済みCSVファイルをアップロード。このペイロードは以下を実行した： /etc/passwd・/etc/shadowなどシステム設定ファイルのバックアップ root権限を持つ新規アカウント「troot」の作成 Linuxのsuコマンドで管理者アカウントからtrootへ切り替え この手順でデバイスの完全制御を獲得した。 第4段階：アンチフォレンジックによる痕跡消去 特筆すべきは痕跡の消し方だ。悪意あるCSVファイルの削除、一時ファイルの消去、不正rootアカウントの削除、そして事前にバックアップした設定ファイルの完全復元——最後に「証拠が完全に消えたか」を確認するバリデーションスクリプトまで実行している。 脆弱性の技術的背景 CVE-2026-20245は、Cisco Catalyst SD-WAN Manager（vManage）・Controller（vSmart）・Validator（vBond）のCLIに存在するコマンドインジェクション脆弱性。ユーザー入力値の検証不足が根本原因で、ローカルアクセス権を持つ認証済み攻撃者がrootとして任意コマンドを実行できる。 Ciscoは修正済みソフトウェアへのアップグレードを強く推奨しており、ワークアラウンドは存在しない。パッチ適用が唯一の対策だ。 日本のネットワーク管理者が今すぐやるべきこと 即座の対応 パッチ適用最優先: Cisco提供の修正済みバージョンへの即時アップグレード。ワークアラウンドがないため、これ一択 vmanage-adminの認証ログ確認: 2026年3月以降の不審なログイン、特に通常と異なる送信元IPからのアクセスを調査 テナントアップロード機能のログ確認: CLIからのファイルアップロード操作の痕跡を確認 /etc/passwd・/etc/shadowの整合性チェック: 「troot」等の見慣れないアカウントの有無を確認 中長期的な対策 SD-WAN管理面へのアクセスはJIT（Just-In-Time）で管理し、常時アクセス権の付与を排除する 管理コンソールへの接続をゼロトラストネットワーク経由に限定する ファイル整合性監視（FIM）を導入し、重要設定ファイルの変更を即時検知できる体制を整える 筆者の見解 今回のMandiantの分析で改めて痛感するのは、「今動いているから大丈夫」という発想の危うさだ。攻撃者はパスワードを元に戻し、証拠を消し、バリデーションまでかけて静かに立ち去る。その後で「うちは侵害されていない」と言っても、実は3月から潜伏されていた——そういう事態が今まさに複数組織で起きている可能性がある。 SD-WANは企業ネットワークの根幹を担うインフラだ。その管理面を押さえた攻撃者は、エッジデバイスの設定を自在に書き換える権限まで握る。SD-WAN導入で「ネットワークがスマートになった」と安心している場合ではなく、管理面のアクセス制御をより厳格にしなければならない時代に入っている。 VPN代替として普及してきたSD-WANだが、その管理インフラ自体がセキュリティの新たな攻撃対象になっている現実を、今回の事件は突きつけている。JITアクセス・最小権限・監査ログの継続的モニタリング——これらを「いつかやる」ではなく、今週の最優先タスクに上げてほしい。 出典: この記事は Mandiant reveals how Cisco SD-WAN zero-day attacks gained root access の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Windows 11のシステム全体を過去の状態に丸ごと巻き戻せる新機能「ポイントインタイムリストア（Point-in-time restore）」を正式提供（GA）開始した。Windows 11 24H2以降のHome・Pro・Enterpriseすべてのエディションで利用可能となり、更新プログラムの失敗やドライバー不具合、設定ミスによるシステム障害からの復旧時間を「数時間」から「数分」へ短縮することを目指す機能だ。 ポイントインタイムリストアとは何か ポイントインタイムリストアは、デバイスを過去の特定時点の状態に「まるごと」戻す機能だ。復元対象は以下の通りで、特にローカルのユーザーファイルが含まれる点が重要な特徴となっている。 Windows OS本体 インストール済みアプリケーション システム・アプリの設定 ユーザー設定 ローカルのユーザーファイル 最大の特徴は「自動・定期的なスナップショット取得」だ。デフォルトでは24時間ごとにシステム全体のスナップショットが自動取得されるため、問題が発生した際にはすでに直近のリストアポイントが確保されている。 従来の「システムの復元」との違い 同じくVSS（Volume Shadow Copy Service）ベースで動作するが、ポイントインタイムリストアは現代のPC管理に合わせて設計し直されている。 比較項目 ポイントインタイムリストア システムの復元 リストアポイント取得 定期自動（設定変更可） イベント契機または手動 ユーザーファイル 含む 含まない 保持期間管理 厳密なポリシー管理 無制限（管理なし） UI システム設定に統合 コントロールパネル リモート管理 CSP対応・Intune連携予定 限定的 旧来のSystem Restoreは取得タイミングが不定で、ユーザーファイルが含まれないため「復元したのに作業中のファイルが消えた」という混乱が起きていた。ポイントインタイムリストアはこの欠点を解消している。 GA版の仕様と設定 デフォルト設定 設定項目 デフォルト 変更可能な値 変更可能エディション リストアポイント取得頻度 24時間ごと 4/6/12/16/24時間 Enterprise限定 リストアポイント保持期間 72時間 4/6/12/16/24/72時間 Enterprise限定 最大ディスク使用量 ディスクの2% 最小2GB〜最大50GB Home/Pro/Enterprise 有効/無効のデフォルト 個人向け（ドメイン未参加・管理対象外のHomeおよびPro）: デフォルトでオン 企業管理下（Enterprise・Education・管理対象Pro）: デフォルトでオフ（Windows 11 26H2まで） なお、OSボリュームが200GB未満のデバイスはデフォルトオフとなる点に注意が必要だ。 復元手順 現時点では、復元はWindows RE（回復環境）からのローカル操作のみとなっている。 Windows REで「トラブルシューティング → ポイントインタイムリストア」を選択 BitLockerの回復キーを入力（BitLocker有効デバイスの場合） 復元したい時点のリストアポイントを選択 リスクと制限事項を確認して「続行」 「復元」を選択して実行 Intuneからのリモートトリガーは将来対応予定としてロードマップに明記されている。 ...

Meta（旧Facebook）は、WhatsAppの最高責任者が歴史的な7年間の在任後に退任し、新体制へ移行すると発表した。30億人以上が日常的に利用するメッセージングプラットフォームを率いてきたトップの交代は、WhatsAppの今後の戦略に大きな影響を与える可能性がある。 7年間で築いたWhatsAppの現在地 退任するトップがこの7年間で主導してきた変化は、WhatsAppを「無料のSMS代替アプリ」から「グローバルビジネスインフラ」へと変容させるものだった。主な成果を振り返ると： エンドツーエンド暗号化の強化: プライバシー重視の姿勢を貫き、各国当局からのバックドア設置要求にも毅然と対応。技術コミュニティから高い評価を得た WhatsApp Business APIの拡大: 企業向けコミュニケーションインフラとして急成長。欧州・中東・東南アジア市場では事実上の標準に Meta AI統合の推進: 生成AI機能をWhatsAppに組み込む取り組みを主導し、AIアシスタント機能を世界規模で展開 規制対応: EUのDMA（デジタル市場法）への対応など、複雑な法規制環境をナビゲート リーダーシップ交代が示す戦略の転換点 このタイミングでの交代には、Metaが直面する複数の課題が透けて見える。 AI統合の本格化: MetaはLlamaをはじめとする自社LLMをWhatsApp・Instagram・Messengerに積極的に統合する方針を強めている。新リーダーには、AI機能の実装スピードとプライバシーの両立という難題が待ち受ける。 企業向け市場の深耕: WhatsApp Business APIはすでに世界規模で利用されているが、Salesforce・HubSpot等のCRMとの連携深化や、エンタープライズ向けのコンプライアンス機能強化が次のフェーズとなる。 規制対応の継続: DMAによる相互運用性義務など、技術と法務が交差する複雑な課題を引き続き舵取りする能力が求められる。 日本のIT現場への影響 日本ではLINEが圧倒的なシェアを持ち、WhatsAppの個人利用は限定的だ。しかし、ビジネス用途では無視できない存在感がある。 グローバル展開企業での利用: 欧州・中東・東南アジア向けビジネスでは、WhatsApp Businessが顧客連絡の主要チャネルになっているケースが多い。リーダーシップ交代による方針変更は、これらの業務フローに直接影響する可能性がある。 WhatsApp Business API依存のシステム: EC事業者やカスタマーサポート部門でAPI経由の自動応答・通知配信を使う企業は、新体制でのAPI仕様変更・料金体系の見直しに注意が必要だ。 セキュリティポリシーの行方: エンドツーエンド暗号化の維持に関するポリシー変更は、BYOD環境でWhatsAppを許可している組織の情報セキュリティ担当者が特に注視すべきポイントとなる。 実務での活用ポイント IT担当者が今すぐ確認しておくべき事項を整理する： API依存度の把握と通知体制の整備: 自社でWhatsApp Business APIを使用している場合、BSP（ビジネスソリューションプロバイダー）からの変更通知に備えてアラートを設定する 料金体系の動向監視: 2024年にコンバーセーションベースの課金モデルへ移行したが、新体制でのさらなる見直しの可能性がある 代替チャネルの確保: 重要な顧客連絡がWhatsApp一択になっている場合、リスク分散として代替チャネルを確保しておく 筆者の見解 WhatsAppのリーダーシップ交代は、表面上は人事ニュースだが、実質的にはMetaのコミュニケーションプラットフォーム戦略の再定義だと見ている。 個人的に最も注目しているのは、エンドツーエンド暗号化とAI処理のトレードオフだ。AIによるメッセージ処理・要約・提案機能を強化しようとすれば、当然ながらプライバシー保護との緊張関係が生まれる。「AIの便利さ」と「暗号化による安心感」をどう両立させるか——この問いへの答えが、新リーダーの最初の試金石になるだろう。 統合プラットフォームの観点では、WhatsApp・Instagram・Messengerを一体として扱うMetaの方向性は合理的だ。部分最適を積み重ねるより、統合された体験を提供する方が競争力は高い。その路線をいかに加速するかが新体制の鍵を握る。30億ユーザーというスケールを持つプラットフォームだからこそ、次の一手が世界のコミュニケーションインフラに与える影響は小さくない。 出典: この記事は Meta announces a major leadership change at WhatsApp の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Canonicalは、Ubuntuのカーネルライブパッチサービス「Ubuntu Livepatch」をArm64（aarch64）アーキテクチャに対応させたと発表した。これにより、AWS GravitonやAzure Ampere Altraといった業務用Armプロセッサ搭載サーバーでも、カーネルセキュリティパッチをシステム再起動なしで適用できるようになる。 Ubuntu Livepatchとは何か Ubuntu Livepatchは、稼働中のLinuxカーネルにメモリ上でパッチを当てるサービスだ。通常、カーネルのセキュリティ更新にはシステムの再起動が必須だが、Livepatchはこの制約を取り除く。関数ポインタの書き換えによって実行中カーネルを修正するため、ディスク上のカーネルイメージを変えることなくCVEを修正できる。 データベースサーバー、決済系、製造ラインの制御系など「数分でも止められない」環境では、カーネル更新のたびにメンテナンスウィンドウを確保する必要があった。Livepatchはその頻度を大幅に削減する。なお、大規模な機能追加を伴うカーネルアップグレードは依然として再起動が必要で、あくまでセキュリティ系CVEの無停止適用が主な用途となる。 なぜArm64対応が重要なのか これまでLivepatchはx86_64（AMD/Intel）のみの対応だった。しかし現在、クラウドやエッジの世界ではArm64サーバーの採用が急速に拡大している。 代表的な環境を挙げると： AWS Graviton2/3/4 — コストパフォーマンスを理由に東京リージョンでも採用が増えているインスタンスファミリー Azure Ampere Altra（Dpsv5シリーズ等） — AzureがAmpereと組んで提供するArm系仮想マシン Google Axion — GoogleのカスタムArm系プロセッサシリーズ オンプレミスのArmサーバー — Ampere AltraやNVIDIA Grace採用の物理サーバー これらの環境でLivepatchが使えるようになることは、Arm64移行を進めている運用チームにとって実質的な恩恵だ。 無料で始めるUbuntu Pro Ubuntu LivepatchはUbuntu Pro（旧Ubuntu Advantage）の一機能として提供される。個人・非営利目的であれば最大5台まで無料で利用できる。 有効化の流れはシンプルだ： Ubuntu Proトークンを取得後 sudo pro attach sudo pro enable livepatch ubuntu.com/pro で無料トークンを発行し、3コマンドで完了する。まず検証環境で無料枠を使って動作を確認してから、本番展開を検討するのが現実的なアプローチだろう。 日本の実務への影響 クラウドシフトとともに、日本のエンタープライズ環境でもArm64サーバーの採用が進んでいる。このアップデートが特に刺さるシナリオを整理する。 CVE対応SLAの遵守が楽になる 高CVSS（7.0以上）のカーネルCVEが公開された場合、「パッチは出たが再起動のタイミングがない」という状況は情報セキュリティ担当者なら誰もが経験する悩みだ。Livepatchはその問題を実質的に解消する。 コンプライアンス要件への対応 「脆弱性公開後N日以内に適用」という内部規程や監査要件を満たしやすくなる。メンテナンスウィンドウの調整コストが下がることは、特に運用体制が手薄な組織には大きい。 自動化パイプラインへの組み込み Ubuntu ProはAnsibleやTerraformで管理できるため、IaCの仕組みに組み込みやすい。Livepatchの有効化をプロビジョニング手順に含めることで、新規サーバー立ち上げ時から無停止パッチ適用体制を整えられる。 筆者の見解 カーネルのライブパッチ自体は珍しい技術ではなく、Red HatのkpatchやSUSEのkGraftでも同様の機能がある。ただ、CanonicalがこのタイミングでArm64対応を追加した意義は素直に評価できる。クラウドの重心がArm64に移動しているのは数字で見ても明らかであり、そこに追従するのは運用ツールとして当然の進化だ。 ゼロトラスト推進の文脈で言えば、パッチ適用サイクルの短縮は脆弱性エクスポージャー期間の縮小に直結する。「今動いているから大丈夫」は通用しない——この原則はArm64であっても変わらない。Livepatchはその原則を実践しやすくする道具として、インフラ設計の選択肢に加える価値がある。 無料枠（5台）はあくまで評価・小規模利用向けだが、本番環境での採用を検討する際はUbuntu Proのライセンスコストを可用性向上のROIと天秤にかけると判断しやすい。大規模なArm64環境を運用しているのであれば、一度試算してみることをすすめる。 出典: この記事は Ubuntu Livepatch arrives on Arm64 to eliminate system reboots for kernel updates の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AMDが最新グラフィックスドライバー「Radeon Software 26.6.2」（Adrenalin Edition）において、独自のアップスケーリング技術「FidelityFX Super Resolution（FSR）」が正常に動作しなくなる重大な不具合を公式に認めた。影響は多数のWindows PCユーザーに及んでおり、修正ドライバーの提供まで旧バージョンへのロールバックが推奨される状況だ。 FSRとは何か FSR（FidelityFX Super Resolution）は、AMDが開発したゲーム向けアップスケーリング技術だ。低解像度でレンダリングした映像を高品質なアルゴリズムで拡大表示することで、描画負荷を抑えながら高フレームレートを実現する。NVIDIAのDLSSに対抗する技術として位置付けられており、AMDのRadeonシリーズだけでなくNVIDIA GeForceやIntel Arcシリーズでも動作するオープンな設計が特徴だ。 FSR 3以降ではフレーム生成技術も統合されており、多くの最新ゲームタイトルで標準機能として組み込まれている。これが使えなくなると、ゲームのパフォーマンスへの影響は直接的かつ深刻だ。 26.6.2ドライバーで何が起きているか 26.6.2へのアップデート後、FSRを有効にしているゲームで映像が乱れる、フレームレートが大幅に低下する、FSR設定が反映されないといった問題が多数報告されている。AMDは問題の存在を把握・確認しており、修正ドライバーのリリースに向けて対応中であると表明した。 影響はRadeonシリーズを搭載したWindows PC全般で広範囲に確認されており、特定のゲームタイトルや構成に限らず多くの環境で再現している点が深刻さを増している。 回避策と対処法 現時点での推奨される対処法は以下の通りだ： ドライバーをロールバックする: デバイスマネージャーまたはRadeon Softwareから26.6.1以前に戻す。Radeon Softwareには「以前のドライバーに戻す」機能が標準搭載されており、設定画面から数クリックで完了する FSRを一時的に無効化する: ゲーム内設定でFSRをオフにし、ネイティブ解像度でプレイする（パフォーマンスは下がるが動作は安定する） 修正版ドライバーの公開を待つ: AMDの公式チャンネル（AMD.com / Adrenalinのリリースノート）でアナウンスを確認する 日本のゲーマー・エンジニアへの影響 国内でもAMD Radeonシリーズを搭載したゲーミングPCは広く普及しており、コストパフォーマンスを重視するユーザーに特に支持されている。FSRはPC版の多くの主要タイトルで組み込まれているため、26.6.2へのアップデート後に「突然ゲームのパフォーマンスが落ちた」と感じているユーザーはこの不具合を疑うべきだろう。 ゲーム開発・映像制作環境でFSRを活用しているプロフェッショナルも影響を受ける可能性がある。修正ドライバーが出るまでは26.6.2への更新は控えることを強く推奨する。エンタープライズ環境やゲームスタジオでAMD GPUを運用している担当者は、展開前のテスト環境での動作確認フローをあらためて見直す機会にしてほしい。 筆者の見解 今回の件で改めて感じるのは、「最新ドライバーが出たらすぐ当てる」がベストとは限らないという事実だ。 Windowsのセキュリティパッチでさえ「数日様子を見る判断も立派なリスク管理」と言われる時代だが、グラフィックスドライバーはさらにその傾向が強い。ゲームや映像制作のような専門用途では、新機能より安定性が優先されることがほとんどだ。 AMDはここ数年でドライバー品質の改善に着実に取り組んできており、Radeonエコシステムへの信頼は少しずつ積み上がっていた。今回の26.6.2の件はその意味で惜しい一歩後退だが、公式に問題を認め修正対応を明言した対応は適切だ。早期の修正ドライバーリリースで信頼を速やかに回復してほしいところだ。 「アップデートは即座に当てるもの」という慣習を見直し、特に業務クリティカルな環境では「検証してから展開」のフローを徹底することが、今回のような事案への最も現実的な備えになる。 出典: この記事は AMD confirms 26.6.2 FSR driver breaks on many Windows PCs の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。