Windows

米国サイバーセキュリティ・インフラセキュリティ庁（CISA）が、Windowsの中核コンポーネント「Task Host（タスクホスト）」に存在する権限昇格脆弱性 CVE-2025-60710 を「実際の攻撃で悪用されている脆弱性カタログ（KEV: Known Exploited Vulnerabilities）」に追加した。連邦機関には2週間以内の対応が義務付けられており、民間企業にも速やかなパッチ適用が強く推奨されている。 Task Hostとは何か、なぜ狙われるのか Task Host（taskhostw.exe）は、DLLベースのプロセスをバックグラウンドで動作させるための「コンテナ」として機能するWindowsのコアコンポーネントだ。シャットダウン時にプロセスを適切に終了させてデータ破損を防ぐ役割も担っており、OSの安定動作に欠かせない存在である。 今回の脆弱性は 「リンクフォロー（Link Following）」 と呼ばれる弱点に起因する。ファイルアクセス前のリンク解決が不適切なため、攻撃者が巧妙に細工したシンボリックリンクやジャンクションを使ってアクセス先を操作し、一般ユーザー権限（低権限）からSYSTEM権限へのローカル昇格を実現できてしまう。 影響対象: Windows 11 および Windows Server 2025 攻撃複雑度: 低（Low）——特別な技術は不要 必要な権限: 通常のローカルユーザー権限のみ パッチリリース日: 2025年11月のPatch Tuesday 攻撃シナリオと実際のリスク ローカル権限での昇格脆弱性というと「物理アクセスが必要では」と思われがちだが、実際のリスクはそれだけではない。 典型的な攻撃チェーンは以下のようなパターンが想定される： フィッシングメールや不正なファイルなどで最初の侵入口を確保（一般ユーザー権限） CVE-2025-60710を使ってSYSTEM権限へ昇格 セキュリティソフトの無効化、ラテラルムーブメント、認証情報の窃取へと展開 特にリモートデスクトップ（RDP）や共有端末環境、クラウドVDI環境では、限定的な初期アクセスから一気に全権奪取につながるため要注意だ。CISAは「この種の脆弱性は悪意ある攻撃者が頻繁に利用する攻撃ベクターであり、連邦エンタープライズに重大なリスクをもたらす」と警告している。 実務での対応ポイント 1. パッチ適用状況の即時確認 2025年11月のWindows Update（KB番号はMicrosoftのアドバイザリを参照）が適用済みかどうかを確認する。Windows UpdateのスキャンをPowerShellで一括確認する方法が効率的だ： 出典: この記事は CISA flags Windows Task Host vulnerability as exploited in attacks の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftが毎年開催するバグバウンティイベント「Zero Day Quest」の2026年版が締め括られ、合計230万ドル（約3億3,000万円）もの報奨金が支払われた。世界20か国以上の研究者から約700件の脆弱性報告が寄せられ、そのうち80件超がクラウドやAI基盤に影響する高インパクトな問題として認定された。 Zero Day Questとは何か Zero Day Questは、Microsoftのバグバウンティプログラムを発展させた形のライブハッキングイベントだ。2026年版は最大5,000万ドルの賞金プールを設定し、「史上最大のハッキングイベント」として発表されていた。昨年2025年版では1.6億ドルを支払っており、年々規模が拡大している。 参加した研究者たちは、Microsoftの定めた「Rules of Engagement（交戦規定）」に従い、顧客データや他テナントのシステムには一切アクセスしない形で検証を実施した。その制約の中でも、クレデンシャル露出・SSRFチェーン・テナント間の不正アクセスといった深刻な経路が発見されている。 Secure Future Initiative（SFI）の文脈 このイベントはMicrosoftが2023年11月に立ち上げた「Secure Future Initiative（SFI）」の一環だ。SFIは米国国土安全保障省のサイバー安全審査委員会がMicrosoftのセキュリティ文化を「不十分であり抜本的な見直しが必要」と指摘したことを受けた、組織横断のセキュリティ強化活動である。 SFIの柱は「デフォルトで安全・設計で安全・運用で安全」の3原則。Zero Day Questで得た知見は社内横断で共有され、CVEプログラムを通じて透明性をもって公開されると明言している。 実務への影響――クラウド管理者が今すぐ確認すべきこと クレデンシャル露出・SSRF・テナント間アクセスという3つの脆弱性クラスは、Azure環境を運用する日本のIT部門にとっても他人事ではない。 クレデンシャル露出は、サービスプリンシパルやマネージドIDの設定ミス、またはコードリポジトリへの誤コミットが引き金になることが多い。Microsoft Entra Workload IDの棚卸しと、シークレットの有効期限・ローテーション設定を定期的に見直す習慣が重要だ。 SSRF（Server-Side Request Forgery）チェーンは、クラウドのメタデータエンドポイントへの不正アクセスへとつながる経路として研究者から注目されている。Azure IMDSへのアクセス制限やネットワーク分離の徹底が基本対策となる。 テナント間アクセスについては、ゲストアカウントや外部コラボレーションの設定が想定外に緩くなっていないか、Microsoft Entra Cross-Tenant Access Settingsを改めて確認するとよい。 またMicrosoftは2025年12月、第三者が書いたコードに起因するオンラインサービスの脆弱性についても報奨金対象とすることを発表している。SaaSやPaaSを使う側としても、依存ライブラリのサプライチェーンリスクが間接的に自テナントのリスクになり得る点を意識してほしい。 筆者の見解 セキュリティというジャンル、正直なところ細かい話が多くて得意分野ではない。それでも今回のZero Day Questの結果を見て、素直に「やっているな」と思った。 SFIはもともと、手厳しい外部評価を受けて始まった取り組みだ。それを言い訳にせず、最大規模のバグバウンティに予算を張り、世界中の研究者を正面から招き入れてクラウドとAIのアーキテクチャを叩かせる。この姿勢は評価に値する。 見つかった脆弱性の類型――クレデンシャル露出・SSRF・テナント間アクセス――は、どれも「設計の甘さ」や「運用の慣れ」が原因で生まれやすいものだ。AIサービスの急拡大に伴い、内部で処理される認証情報の経路が増えているのは確かで、それが攻撃対象となった背景もうなずける。 ゼロトラストの観点から言えば、今回報告された問題の多くは「信頼を前提にした設計」が根に残っていることを示唆している。テナント間アクセスの設計であれ、クレデンシャルの扱いであれ、「ネットワーク内にいるから大丈夫」という前提を捨てる方向性は間違っていない。SFIの3原則――デフォルトで安全・設計で安全・運用で安全――はまさにそこを突いている。 Microsoftにはこの路線をこのまま続けてほしい。外圧で始まった取り組みが内発的な文化に変わるとき、本当の強さが生まれる。今がそのフェーズだと思って見ている。 出典: この記事は Microsoft pays $2.3M for cloud and AI flaws at Zero Day Quest の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「署名されているから安全」という前提が崩れつつある 2026年4月、セキュリティ企業 Huntress の研究者たちが衝撃的なキャンペーンを詳報した。デジタル署名付きのアドウェアが、SYSTEM権限でウイルス対策製品を完全に無効化するペイロードを展開していたというものだ。被害は教育機関・公共インフラ・政府機関・医療機関を含む世界124か国、わずか1日で2万3,500台以上のエンドポイントが感染ホストとして観測された。 「PUP（Potentially Unwanted Program）だから大したことない」という甘い認識が、いかに危険かを突きつける事例だ。 手口の全体像——合法ツールを踏み台にした「サイレント侵害」 今回の攻撃の主役は、Dragon Boss Solutions LLC という企業が署名した一連の「ブラウザ」アプリだ。Chromstera、Chromnius、WorldWideWeb、Artificius Browserといった名称で流通しており、多くのセキュリティ製品からPUP扱いを受けていた。 表向きはブラウザとして動作しつつ、内部では Advanced Installer という商用パッケージングツールの自動更新機構を悪用している点が巧妙だ。正規ツールのアップデート機能を間借りすることで、セキュリティ製品の検知をすり抜けやすくしている。 侵害の流れ 更新チェック — 設定ファイルに埋め込まれた複数のフラグにより、ユーザー操作を一切必要とせずサイレント実行 偵察フェーズ — 管理者権限の有無、仮想マシン検出、インターネット接続確認、レジストリからのAV製品特定（Malwarebytes、Kaspersky、McAfee、ESETを明示的にターゲット） MSIペイロード展開 — Setup.msi をGIF画像に偽装して取得・実行。SYSTEM権限で動作 ClockRemoval.ps1 の投下 — AVサービスの停止・プロセス強制終了・インストールディレクトリの削除・レジストリ消去を実施 再インストール封鎖 — hostsファイルを改ざんしてAVベンダーのドメインを 0.0.0.0 にヌルルーティング。更新も再インストールも不能に 永続化 — システム起動時・ログオン時・30分ごとのタスクスケジューラ登録でAV除去を繰り返し実行 Opera、Chrome、Firefox、Edgeのインストーラーも標的にされているが、これはブラウザハイジャック機能への干渉を避けるためと分析されている。 なぜこれが重要か——「署名 ≠ 安全」を現場に刻め コード署名証明書は、ソフトウェアの「発行元の身元」を証明するものだ。しかしそれは「中身が安全である」ことを保証しない。今回の攻撃は、この前提の混同を意図的に突いている。 日本の組織でも、「署名済みだからインストール許可」という運用ルールを持っているケースは少なくない。AppLocker や Windows Defender Application Control（WDAC）の構成が甘ければ、署名の有無だけで制御を通過させてしまう。 PUPは「迷惑なだけで害はない」と軽視されがちだが、今回のケースはその出発点から最終的にAV完全無効化・ドメイン封鎖・SYSTEM権限の乗っ取りへと進展している。初期侵害の経路として「アドウェア」が使われる時代に入っていると認識しなければならない。 実務への影響——明日から使える対策ポイント 1. WDAC / AppLocker の証明書だけに頼らないポリシー設計 発行元証明書に加えて、ファイルハッシュ・製品名・バージョンの組み合わせで制御する構成に見直す。Intelligent Security Graph（ISG）との連携も有効だ。 2. 「PUP検知=即対処」の運用ルール化 SIEM/EDRの検知ルールでPUPアラートを「低優先度」に分類している場合、今すぐ見直す。アドウェアであっても高権限で動作している痕跡があれば最優先にエスカレートする。 3. hostsファイル・レジストリの変更監視 FIM（ファイル整合性監視）を有効にし、C:\Windows\System32\drivers\etc\hosts への書き込みをリアルタイムでアラートする。これは本攻撃の「再インストール封鎖」を早期発見する最も現実的な手段だ。 4. 定期的な「AV有効性確認」の自動化 ...

何が起きたか 2026年4月、WordPressプラグイン開発会社「EssentialPlugin」が提供する30本以上のプラグインに悪意のあるコードが仕込まれていたことが判明した。被害を受けたプラグインの総インストール数は数十万に達する。 発端は、マネージドWordPressホスティング「Anchor Hosting」の創業者Austin Ginderへの内部情報提供だった。調査を進めたところ、すべての汚染がEssentialPluginが6桁の金額（数百万円規模）で新オーナーに買収された2025年8月以降に遡ることが分かった。 バックドアは数ヶ月間、完全に沈黙していた。そして最近になって突如「活性化」し、外部のコマンド＆コントロール（C2）サーバーへ接続して wp-comments-posts.php（正規の wp-comments-post.php に似せた名前）を取得。このファイルがWordPressのコア設定ファイル wp-config.php にマルウェアを注入する仕組みだ。 攻撃の巧妙さ——3つのポイント 1. イーサリアムベースのC2アドレス解決 通常のマルウェアはIPアドレスやドメインをハードコードするが、本攻撃ではEthereumブロックチェーンを使ってC2サーバーのアドレスを動的に解決する。ブロックチェーンは書き換えが困難なため、C2インフラをブロックされにくい。インフラのテイクダウンへの耐性が高く、検出・無効化がきわめて難しい設計だ。 2. Googlebot専用のスパム配信 注入されたコードは、スパムリンク・リダイレクト・偽ページをGooglebot（Googleの検索クローラー）にしか表示しない。サイトオーナーが自分のサイトを開いても何も見えないため、被害に長期間気づけない。SEOの毀損と検索順位の下落として静かに被害が積み上がる。 3. 「時限式」サプライチェーン攻撃 買収直後にバックドアを仕込み、しばらく休眠させてから一斉に活性化する手法は近年増加傾向にある。オープンソースプロジェクトやSaaS系サービスの「買収」を入口にする攻撃は、従来のコード審査やウイルス対策では検知が難しい。 WordPress.orgの対応と残る課題 WordPress.orgは報告を受けて迅速に動き、問題プラグインのリポジトリへのアクセスを閉鎖。強制アップデートを配布してバックドアの通信経路を無効化した。 ただし「強制アップデートは wp-config.php の汚染を修復しない」とWordPress.orgは明示している。データベース接続情報など重要な設定が記載された wp-config.php が汚染されたままの場合、バックドアの通信が止まっても攻撃者はすでにサイト情報を取得済みの可能性がある。 また、マルウェアの潜伏場所が wp-comments-posts.php だけとは限らず、他のファイルにも潜んでいる可能性があることも警告されている。 実務への影響——日本のエンジニア・IT管理者がいまやるべきこと 即時確認 自社・顧客サイトでEssentialPlugin製品（旧称: WP Online Support）を使用していないか確認する 対象プラグインのリストはPatchStackの調査記事で公開されている wp-comments-posts.php（正規ファイルは wp-comments-post.php、末尾の s に注意）の有無を確認 wp-config.php の内容を直接確認し、不審なコードがないかチェック 中長期の対策 プラグインの購入・導入審査にサプライチェーンリスクの観点を加える: 「誰が所有しているか」「最近買収されていないか」をチェックするフローを設ける File Integrity Monitoring（FIM）の導入: wp-config.php などのコアファイルに対する変更をリアルタイム検知する仕組みを入れる 最小権限の原則: プラグインが持つファイル書き込み権限を必要最小限に絞る Webアプリケーションファイアウォール（WAF）: Googlebot偽装のアウトバウンド通信をブロックするルール整備 筆者の見解 この事件が示すのは、「コードの品質チェック」や「脆弱性スキャン」だけではもはや十分でないという現実だ。攻撃者は合法的な手段（プラグインの正規買収）でサプライチェーンに侵入し、時間をかけて信頼を積み上げてから攻撃を発動する。8ヶ月間の潜伏期間中、このバックドアはどんな静的解析にも引っかかりようがなかった。 C2アドレスの解決にイーサリアムブロックチェーンを使うアプローチは、インフラのテイクダウン耐性という観点で技術的に興味深い。今後、同様の手法が他の攻撃でも使われることは間違いなく、ネットワーク層での検知戦略の見直しが急務だ。 Non-Human Identity（NHI）の観点からも示唆が多い。WordPress環境ではプラグインがサーバー上のファイルを読み書きし、外部APIと通信し、データベースに接続する——これらはすべてNHIとして管理されるべき「アクセス権」だ。「インストールしたら終わり」ではなく、「このプラグインがどのリソースに対してどんな権限を持ち続けているか」を継続的に把握する仕組みが求められる。 WordPress自体を使うかどうかという選択論に持ち込むのは生産的ではない。現実的には、既存サイトの大半はWordPressで動いており、完全移行は現実的でない。だからこそ「禁止」ではなく「安全に使い続けるための仕組みを作る」という発想で、FIMの導入・権限の最小化・サプライチェーンの定期的な棚卸しを着実に進めることが今できる最善策だ。 すでに wp-config.php が書き換えられている場合、強制アップデートで「通信は止まった」状態でも、攻撃者がDB接続情報を入手済みである可能性を捨てられない。このケースではパスワードローテーションとログの精査を最優先で実施してほしい。 出典: この記事は WordPress plugin suite hacked to push malware to thousands of sites の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Snapが従業員の約16%にあたる1,000人以上のレイオフを発表し、同時に300の求人枠も閉鎖した。単なるコスト削減ではなく、「AIを活用した小規模チームがすでに大きな成果を出している」という手応えを組織再編の根拠に据えている点が、今回の動きをとりわけ注目すべきものにしている。 何が起きているのか Snapの発表によれば、今回の構造改革は同社にとってここ数年で最大規模のものだ。削減対象は開発・運営部門に広く及び、一方でAIエンジニアリングへの投資は強化される方向性が示されている。経営陣は「AIが武器になった今、組織の形そのものを変えなければ競争力を維持できない」というメッセージを明確に打ち出している。 注目すべきは、この発表が単なる業績不振による人員整理ではない点だ。Snap自身が「AIチームはすでに成果を出している」と述べており、これは「AI導入による生産性向上」が具体的な組織変更の根拠として機能し始めた、業界初期の事例のひとつといえる。 「少数精鋭×AI」が組織の標準形になる 従来のソフトウェア開発では、機能追加・品質保証・インフラ管理それぞれに専任チームを置くことが当然とされてきた。しかしAIがコード生成・テスト・インフラ管理の多くを担えるようになった今、「人間が担うべき作業の絶対量」が劇的に減少している。 Snapの事例が示すのは、その変化が理論ではなく実際の経営判断に反映される段階に入ったということだ。ソーシャルメディアという競争の激しい領域で、1,000人規模の削減と並行してAI投資を拡大するという判断は、経営層が「AIで代替できる仕事の範囲」を相当広く見積もっていることを示している。 実務への影響：日本のIT現場で何を考えるべきか この動きは日本のIT部門にとっても対岸の火事ではない。以下の点を今すぐ自組織に照らし合わせて考えてほしい。 1. 「人員数＝処理能力」の方程式を疑う プロジェクトが遅延した際に「人を増やす」判断が先に来るなら、一度立ち止まる価値がある。同じ課題をAIを活用した少人数チームで解決できないか検討してみてほしい。 2. 「仕組みを作れる人材」の価値が急騰する AIに指示を出し、自律的に動くパイプラインを設計・改善できる人材は、今後ますます希少かつ高価値になる。コードを書くだけでなく「AIを使って仕組みを動かす」スキルを身につけることが、キャリアにおける最重要投資のひとつだ。 3. 採用計画の前提を見直す 毎年一定数の新卒・中途を採用し続けるモデルが本当に最適かどうか、再検討する時期に来ている。採用数よりも「どんな仕組みを持った組織を作るか」を先に考える順序が、今の時代には合っている。 4. 既存メンバーのリスキリングを優先する Snapのような企業は「AIに置き換えられる役割を削減」している。一方で、AIを使いこなせる人材への需要は高まっている。既存メンバーをAI活用の担い手に育てる投資は、採用コストよりも即効性が高いケースが多い。 筆者の見解 Snapの今回の動きを見て、「ついにここまで来たか」という実感がある。AIが「補助ツール」から「組織設計の前提」に変わる転換点を、具体的な数字で目の当たりにしたような感覚だ。 正直に言えば、日本のIT業界では「AIで生産性が上がった話」は増えているのに、「組織の形を変えた」という話がまだほとんど出てこない。技術的には変革が起きているのに、組織・人事・採用の構造は10年前とほぼ同じという企業が多すぎる。Snapの事例はその矛盾を鋭く突きつけてくる。 「少数の仕組みを作れる人が、AIを使って大きな仕事を動かす」——これはもう未来の話ではなく、すでに起きていることだ。毎年同じ規模で新卒採用を繰り返し、頭数で課題を乗り越えようとするアプローチは、構造的なコスト競争力を失い続けるリスクがある。 とはいえ、大切なのは「AI導入で人を減らす」ことそのものではなく、「AIを活かした仕組みを作れる人材を組織の中心に置く」ことだ。削減ありきではなく、組織が何を実現したいかから逆算して役割と人員を設計する。Snapの判断が正しいかどうかは数年後に明らかになるが、「AIで何が変わるかを経営判断に組み込む必要がある」という問い自体は、すべてのIT組織が今すぐ向き合うべきものだと思っている。 出典: この記事は Snap cuts 16% workforce as it aggressively doubles down on AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、Windows 11向けの累積アップデート KB5083769 および KB5082052 を適用した端末において、BitLockerのリカバリモードが誤って起動してしまう不具合を公式に認めた。影響範囲はWindows 11の全サポートバージョンにとどまらず、Windows 10およびWindows Serverにも及んでいる。 何が起きているのか BitLockerは、ディスク全体を暗号化してデータを保護するWindowsの機能だ。通常、ハードウェア構成の変更やTPMの状態変化など「何か重要なものが変わった」と検知したときにリカバリキーの入力を求める。今回のケースは、OSアップデートによって不適切にその条件が満たされたと誤認され、再起動後にいきなり回復キーの入力画面が表示されるという事象だ。 Microsoftの公式見解では、この問題はアップデートのインストールプロセスにおけるBitLockerとTPMの状態管理に起因するとされており、回避策の調査中としている。 なぜこれが重要か BitLockerのリカバリキーは、多くの企業環境でActive DirectoryやMicrosoft Entra IDに保管されている。IT管理者がいるならまだリカバリは可能だが、問題はエンドユーザーが一人で作業している時間帯や、出先・在宅勤務中にこの画面に遭遇したときだ。リカバリキーがどこにあるか分からないユーザーは、完全に作業不能になる。 さらに深刻なのはサーバー環境だ。Windows Serverに同様の問題が発生した場合、サービス停止に直結する。BitLockerを有効化しているサーバーで再起動後にリカバリ画面が出れば、物理的またはコンソールアクセスが必要になるケースもあり、クラウド仮想マシンでは対応がより複雑になる。 実務での対応ポイント 【IT管理者向け】 パッチの展開を一時停止する判断も正解: 問題が公式確認されている状況では、KB5083769・KB5082052の自動展開を保留にすること。Microsoftが修正済みパッチをリリースするまで待つのは立派なセキュリティ判断だ。 BitLockerリカバリキーの保管状況を今すぐ確認: Microsoft Entra IDまたはActive DirectoryにリカバリキーがエスクローされているかをPowerShellや管理コンソールで確認する。保管されていない端末が一台でもあれば、今すぐ対処が必要だ。 影響端末の洗い出し: 既に該当パッチを適用済みの端末リストを作成し、ヘルプデスクに「BitLockerリカバリ画面が出た場合の対応手順」を共有しておく。 サーバーへの適用は特に慎重に: 本番サーバーへの展開前に、テスト環境での検証を必ず実施すること。 【一般ユーザー向け】 もし再起動後にBitLockerのリカバリキー入力画面が出た場合は、焦らずIT部門に連絡する。 個人PCでBitLockerを有効にしている場合は、Microsoftアカウントのセキュリティページからリカバリキーをあらかじめ確認・保存しておくこと。 筆者の見解 Windowsのアップデートが端末を「文鎮化」しかねない問題は、残念ながら珍しい話ではなくなりつつある。今回はBitLockerという、まさにセキュリティの要である機能が誤動作するという点で、インパクトが大きい。 このような不具合が続くと、IT管理者の現場では「すぐに当てるべきか、様子を見るべきか」という判断がますます難しくなる。セキュリティパッチは速やかに適用することが原則だが、パッチそのものが別のリスクを生む状況では、テスト環境での検証フェーズを設けることが現実的な対応だ。「数日様子を見てから展開する」という判断は、臆病ではなく、リスク管理として正しい行動だと筆者は考えている。 Microsoftには、品質管理プロセスの強化を期待したい。これだけの規模のエコシステムを持ち、Windows Updateという強力な配布基盤があるのだから、その基盤の信頼性を守ることがすべての前提になる。セキュリティ機能を守るためのパッチが、セキュリティ機能を壊すという矛盾は、早期に解消されることを強く願っている。 修正パッチのリリース情報は、Microsoftの公式リリースノートおよびWindows Updateのサポートページで随時更新される予定だ。影響を受けた場合は公式情報を都度確認してほしい。 出典: この記事は Microsoft confirms Windows 11 KB5083769, KB5082052 wrongly forcing BitLocker recovery の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 11の物議を醸す機能「Recall」が、またも厳しい視線にさらされている。新たに公開されたツールにより、Recallが蓄積するスクリーンショットや入力データを容易に抽出できることが実証された。Microsoftは「設計上の欠陥はない」と主張するが、セキュリティ研究者コミュニティの反応は冷ややかだ。 Recallとは何か——おさらい Recallは、PCの操作履歴をスクリーンショットとして定期保存し、自然言語で「あのとき見ていたページ」を検索できるようにするWindows 11の機能だ。2024年に発表された当初から「スパイウェアそのものだ」「ローカルに個人情報が大量蓄積される」として批判を集め、リリースが延期。その後Copilot+ PC向けにオプトイン形式で段階的に提供が始まった。 Microsoftは再設計にあたり、データをTPM（Trusted Platform Module）で保護し、Windows Helloによる生体認証が必要な「Secure Enclave」内に保存すると説明してきた。この説明が今、改めて問われている。 何が明らかになったか 今回公開されたツールは、Recallが使用するSQLiteデータベースと蓄積されたスナップショット画像に対して、管理者権限またはRecallデータへのアクセス権を持つユーザーのコンテキストからアクセスし、内容を一括エクスポートできることを示した。 Microsoftの反論は「これは想定された動作範囲内であり、アクセス権を持つユーザーが自分のデータを読めるのは当然」というものだ。技術的には間違っていない。しかし批判の核心は別のところにある。 問題の本質は「データが存在すること」そのものだ。 マルウェアが管理者権限を奪取した場合、Recallのデータベースはそのまま「過去数週間〜数カ月の行動記録」として流出する 企業環境でエンドポイントが侵害されたとき、Recallが有効だったPCは被害範囲が格段に広がる可能性がある フィッシングやソーシャルエンジニアリングで一般ユーザーのアカウントが乗っ取られた場合も同様 Microsoftが「欠陥なし」と言うのは「鍵のかかった金庫に泥棒が入ったとき金庫を開けられるのは設計どおり」と言っているに等しい。議論がかみ合っていない。 企業・IT管理者が取るべき対応 Recallの現実的なリスク評価 環境 推奨 機密情報を扱う企業PC Recall無効化を強く推奨 医療・法務・金融 コンプライアンス要件次第では即時無効化必須 一般コンシューマー オプトイン前提なので、デフォルトは無効のはず 個人の趣味用途 リスクを理解した上で各自の判断 グループポリシーでの制御 Intune / グループポリシーで Turn off saving snapshots for Windows ポリシーを有効化すれば企業全体でRecallを無効にできる。Copilot+ PC対象機器が社内に増えてきた場合、今から構成を確認しておくことを推奨する。 エンドポイントセキュリティとの組み合わせ Recallを使用する場合でも、EDR（Endpoint Detection and Response）ソリューションによるプロセス監視を組み合わせることで、不審なDBアクセスを検知できる体制を整えるべきだ。「機能を禁止する」より「使える状態で安全に管理する」アプローチが長続きする。 筆者の見解 Recallはアイデア自体は面白い。「あのとき調べていた情報をもう一度」というニーズは確かに存在するし、ローカル処理でプライバシーを守るというコンセプトも正しい方向性だと思っている。 ただ、Microsoftがセキュリティ研究者の指摘に対して「想定内の動作」と繰り返すだけでは、ユーザーの信頼回復にはつながらない。今の時代、エンドポイントへの侵害を「起きないこと」として設計するのはもう通用しない。侵害されることを前提にしたデータの最小化設計——「侵害されてもRecallのデータが渡らない」アーキテクチャ——こそが必要なはずだ。 Microsoftにはそれを実現する技術力が十分にある。Plutonチップ、Windows Helloの多要素認証、Confidential Computingと、セキュリティの基盤技術は世界トップクラスだ。だからこそ、「設計上の欠陥はない」という守りの一点張りではなく、「こういう侵害シナリオに対してはこう対応する」という前向きな議論を期待したい。 Recallはまだ発展途上の機能だ。このまま不信感の中で死んでいくには、ポテンシャルがもったいない。 出典: この記事は Windows 11’s controversial Recall is under fire again, while Microsoft denies flaws の内容をもとに、筆者の見解を加えて独自に執筆したものです。

企業内でのAI利用が急拡大する中、IT部門が頭を抱えている問題が「シャドーAI」だ。Microsoftは、Microsoft Edgeブラウザに新たなグループポリシーを追加し、IT管理者が職場のAIアプリ利用をコントロールできる仕組みを整備する方針を明らかにした。 何が変わるのか この新機能により、IT管理者はEdge上で動作するAIアシスタントのアクセスをポリシーで制御できるようになる。具体的には、従業員が業務中に利用するAIアプリをCopilot in Edgeへ誘導したり、他のサードパーティAIアプリへのアクセスに制限をかけたりすることが可能になる。 ターゲットは明確だ。いわゆる「シャドーAI」——IT部門の承認を得ずに従業員が勝手に使い始める外部AIサービスを、ガバナンスの傘の下に収めることが目的だ。業務データが未審査のAIサービスに流れるリスクを、管理側のポリシーで封じ込めようとする動きである。 シャドーAI問題の現実 日本の企業でも、生成AIの業務利用は急速に広がっている。一方でセキュリティ・コンプライアンス担当者の悩みは深い。従業員がどのAIサービスに何のデータを入力しているか、実態を把握しきれていないケースがほとんどだからだ。 これは単なるポリシー違反の問題ではない。個人情報保護法・不正競争防止法・各種業法への抵触リスク、そして万が一のデータ漏洩時の責任所在の問題でもある。「禁止通達を出した」だけでは何も解決しないことは、過去のBYODやクラウド利用制限の歴史が証明している。 実務での活用ポイント 1. 「禁止」ではなく「統制」で設計する グループポリシーでAIアプリを一律ブロックするアプローチは、かえって業務非効率を生み、従業員が個人端末や個人回線で使い始めるという抜け道を生む。今回のEdgeポリシーのように「承認済みツールを優先表示・誘導する」設計の方が現実的かつ長期的に機能する。 2. Microsoft Entra ID + Conditional Accessとの組み合わせを検討 EdgeのAIポリシーは、既存のMicrosoft 365コンプライアンス基盤と連携させてこそ真価を発揮する。Conditional Accessによるデバイスコンプライアンス確認と合わせて設計することで、ゼロトラスト的な多層防御が実現する。 3. データ分類ポリシーとセットで運用する どのデータをAIに入力してよいか・よくないかを明文化し、MIPラベルなどの情報保護機能と組み合わせる。技術的な制御だけでなく、従業員への教育・啓発もセットで行うことが不可欠だ。 筆者の見解 このEdgeポリシー追加の方向性は、基本的に正しい。「禁止で封じ込める」のではなく、「承認済みツールを使いやすくすることで自然に誘導する」というアプローチは、ガバナンスの本来あるべき姿だ。シャドーAIを生む根本原因は「承認されたツールが不便だから」であることが多い。その意味で、IT管理者がコントロールできる土台を整備すること自体は歓迎したい。 ただし、正直に言えば、この仕組みが本当に機能するかどうかは、Copilot in Edgeが「使われたいと思われる品質」を持てるかどうかにかかっている。管理者がポリシーで誘導できたとしても、実際に業務で役立つ体験を提供できなければ、従業員は個人端末での利用に逃げるだけだ。 Microsoftにはプラットフォーム・ブランド・エンタープライズ信頼性という、他が簡単に真似できない強みがある。その総合力を活かして、ガバナンス基盤と実用性を両立した本物のAIアシスタント体験を実現できる力は十分にあるはずだ。「使わされている」ではなく「これが一番便利だから使っている」と従業員が思える状態を作ること——そこに向けて全力を注いでほしい。プラットフォームの整備は着実に進んでいる。あとは中身の勝負だ。 出典: この記事は Microsoft will allow IT admins to force Copilot in Edge over other AI apps の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Windows 10のサポート終了期日「2026年10月14日」はIT管理者の間でも周知されてきた。しかし、実はそれよりも深刻な問題が同年に潜んでいる。Secure Boot証明書の失効だ。単なるソフトウェアライフサイクルの話ではなく、物理的に起動できなくなるリスクを孕むこの問題は、まだ十分に語られていないと感じる。 2026年10月のEOLとは何か MicrosoftはWindows 10を2015年にリリースした際、10年間のサポートを明言していた。2020年にメインストリームサポートが終了し、延長サポートは本来2025年まで——それをさらに1年延長して2026年10月までとなった経緯がある。 EOL以降は、リモートコード実行・権限昇格・情報窃取を可能にする脆弱性を含むいかなるセキュリティ更新も提供されない。OSとしての機能は動き続けるが、攻撃者にとっては「既知の穴が塞がれないまま放置されたターゲット」になる。 Secure Boot証明書失効：こちらの方が深刻かもしれない Windows 10が使用する Microsoft Corporation UEFI CA 2011 証明書は、2026年中に有効期限を迎える。Secure Bootはブートプロセスに信頼済み署名付きソフトウェアのみをロードさせる仕組みだが、この証明書が失効すると検証に失敗し、システムが起動不能になるか、Secure Boot自体を無効化せざるを得なくなる。 Secure Bootを無効化するということは、ブートキット攻撃（OSロード前にマルウェアが制御を奪う）に対して無防備になることを意味する。Microsoftが証明書を任意に延長できない理由は、暗号学的な設計上の制約と、定期的な証明書ローテーションというセキュリティベストプラクティスにある。これはMicrosoftが「やらない」のではなく「できない」話だ。 EOL後もパッチ未適用で使い続ける判断をする組織は多いが、Secure Boot失効はOSが動くかどうかという土台の問題であり、セキュリティリスクとは別の次元の話である。 Extended Security Updates（ESU）：コストと限界 移行が間に合わない組織向けに、MicrosoftはESUプログラムを提供する。コンシューマー向けは初年度30ドル/デバイスとされているが、エンタープライズ向けは年々倍増する設計だ——1年目約61ドル、2年目約122ドル、3年目約244ドル（2029年まで）という試算がある。 ESUがカバーするのは重要なセキュリティ脆弱性のみであり、機能更新・非セキュリティ修正・テクニカルサポートは含まれない。年次更新が必要で、2029年以降は完全終了となる。延命策ではあるが、根本的な解決にはならない。 実務への影響——日本のIT管理者が今すぐやるべきこと 1. 台数把握と証明書確認を急げ まずWindows 10端末の棚卸しが必要だ。Get-WmiObject Win32_OperatingSystem や Microsoft Entra・Intuneのデバイスレポートで把握する。Secure Boot有効化状況も msinfo32 や PowerShell で確認できる。 2. Windows 11移行可否の判定 TPM 2.0・Secure Boot対応・CPU要件を満たさない古い端末は「更新プログラムで上げる」ではなくハードウェア更新が必要になる。調達リードタイムを考えると、2026年10月は決して遠くない。 3. ESUの費用対効果を計算する どうしても移行できない端末はESUで繋ぐが、「とりあえずESUで延命」の積み重ねは結局コストを押し上げる。Windows 10延長サポートに費やすコストをWindows 11端末の調達予算に回す判断を今から経営層に説明しておくべきだ。 4. Secure Boot無効化だけは避けよ 「起動しなくなった」問題を解決するためにSecure Bootをオフにする対処は、攻撃面を大幅に広げる。カーネルドライバーの締め出しをはじめとするWindowsのセキュリティ強化はSecure Bootを前提に設計されている。 筆者の見解 Windows 10のEOLは「ずっと前からわかっていた話」だ。しかしSecure Boot証明書の失効という問題は、エンドユーザーやSMB規模のIT担当者にはほぼ伝わっていないと感じる。「OSが動いているから大丈夫」という感覚は、この問題の前では通用しない。 Microsoftが1年の延長サポートを加えたり、コンシューマー向けESUを設けたりと、移行の猶予を作ろうとしている姿勢は評価できる。ただ、Secure Boot証明書の失効リスクについては、もっとわかりやすく・大きな声で周知してほしかったというのが本音だ。MicrosoftはWindowsのセキュリティ基盤をここ数年着実に強化してきた。その成果を正しく活かすためにも、ユーザーが「動いているから問題ない」のまま取り残されない情報発信を期待したい。 IT管理者の皆さんには、単なる「EOLのリマインダー」としてではなく、Secure Boot証明書失効という具体的な技術的タイムリミットとして今回の問題を捉え直してほしい。対応は早ければ早いほど選択肢が広い。 出典: この記事は Windows 10 End of Support 2026: Secure Boot Expiry, ESU Costs, and Critical Security Risks の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Googleが長年ユーザーから要望の多かった縦型タブ（Vertical Tabs）と、より賢くなったリーディングモードをChromeに実装することを発表した。一見地味なUI改善に見えるが、情報収集を日常的に行うエンジニアやIT管理者にとっては、作業効率を左右する実質的なアップデートだ。 縦型タブとは何か 従来のブラウザタブは画面上部に横並びで表示される。タブを大量に開くと、各タブのタイトルがほぼ見えなくなるという問題は、多くのヘビーユーザーが日々直面している現実だ。 縦型タブは、タブ一覧をサイドバーとして縦に並べる方式に切り替える。これにより： タイトルの視認性が飛躍的に向上：横に並べると潰れてしまうタイトルが、縦配置なら十分な幅で表示できる タブの整理・把握がしやすくなる：グループ化や折りたたみも行いやすく、タブ管理が格段に改善する ワイドスクリーンとの相性が良い：横幅の広いモニターでは、縦方向のサイドバーにタブを逃がすことでコンテンツ表示領域を有効活用できる スマートリーディングモードの進化 リーディングモードは、Webページから広告やナビゲーションなどの「ノイズ」を取り除き、本文だけをすっきりとした形式で表示する機能だ。今回の「スマート」版では、AIを活用してコンテンツの主要部分をより精度高く抽出し、長文記事や技術ドキュメントの可読性をさらに高める方向で改善が加えられているとされている。 特にエンジニアが英語の技術記事やドキュメントを読む場面では、余計なサイドバーやポップアップが消えるだけで集中力の維持に大きく貢献する。 実務への影響——日本のエンジニア・IT管理者にとっての意味 タブ管理の見直し 日常的に調査や情報収集を行うエンジニアは、気づけば30〜50タブを開いた状態になることも珍しくない。縦型タブへの切り替えは、そのカオスを整理する一手になりうる。特にデュアルモニター環境や大型ディスプレイを使っているなら、縦型タブの恩恵を受けやすい。 リーディングモードの業務活用 技術ドキュメントや英語記事を読む際に積極的に活用したい。翻訳ツールとの組み合わせも相性が良く、本文だけを抽出してから翻訳にかけると精度と可読性が上がるケースがある。 組織内のブラウザ管理 法人でChromeを管理している場合、新UIの展開タイミングや企業ポリシーへの影響を事前に確認しておくと安心だ。特にChrome Enterprise環境では、機能フラグや管理コンソールの設定で展開を制御できる場合がある。 筆者の見解 正直に言えば、縦型タブはすでに数年前から他のブラウザで実装済みの機能だ。ヘビーユーザーの間では「なぜChromeにはないのか」という声が長く続いていた。ようやく追いついてきたという印象は否めない。 とはいえ、Chromeのシェアを考えれば、この機能が「世界規模で当たり前になる」という意味合いは小さくない。縦型タブが普及することで、より多くの人がタブ管理に意識を向けるようになれば、情報整理の文化そのものが底上げされる可能性がある。 リーディングモードの強化は、AIを「派手な会話UI」としてではなく「黒子として情報品質を高める」方向に使うという点で、筆者は好意的に見ている。これは「道のド真ん中」のAI活用であり、ユーザーが意識せずに恩恵を受けられる形だ。こういうアプローチこそが、AIの実質的な普及を進める。 ブラウザ選択はあくまでユーザーの自由だが、今回のアップデートを機に「自分はどのブラウザのどの機能を本当に使っているか」を一度棚卸しする良いタイミングかもしれない。どのブラウザを選ぶにしても、意図された使い方をきちんと理解して使うことが、結局は一番効率の良い選択につながる。 出典: この記事は Chrome finally gets vertical tabs and a smarter reading mode の内容をもとに、筆者の見解を加えて独自に執筆したものです。

「既製品」の限界に達したメタが選んだ道 マーク・ザッカーバーグが率いるメタ・プラットフォームズが、半導体大手ブロードコム（Broadcom）と組んで独自のAIシリコンエコシステムを構築することが明らかになった。数十億人のユーザーを抱えるSNS基盤のAI推論・学習を、既製の汎用GPUに頼らず自社設計チップで賄おうという、極めて大規模な戦略転換だ。 これは単なる「コスト削減のためのカスタマイズ」ではない。AIインフラの主導権を誰が握るかという、産業構造レベルの問いに対するメタなりの回答である。 なぜブロードコムなのか ブロードコムはネットワーク機器やASIC（特定用途向け集積回路）設計で長年の実績を持つ。Googleの「TPU（Tensor Processing Unit）」もブロードコムとの協業で開発されてきた経緯がある。つまりメタは、AIチップ開発の実績がある既存パートナーシップの方程式に乗る形を選んだわけだ。 NVIDIAのGPUは汎用性が高く、どんなワークロードにも対応できる反面、「どんなワークロードにも対応できる」ために生じるオーバーヘッドが大きい。推論フェーズ（学習済みモデルを使って実際にサービスを動かす段階）では、そのオーバーヘッドがコストと消費電力に直結する。数十億ユーザーへのリアルタイムAI応答を支えるとなれば、専用設計チップへの移行は理にかなった選択だ。 カスタムシリコン戦略の構造 メタが目指すアーキテクチャの骨格は以下のようなものとみられる： 学習（Training）: 引き続きNVIDIA GPUクラスターを活用しつつ、将来的には独自チップへの置き換えも視野に 推論（Inference）: ブロードコムとの協業で設計した専用ASICで低レイテンシ・低コストを実現 ネットワーク基盤: ブロードコムが強みを持つ高速スイッチング技術で、チップ間通信のボトルネックを解消 GoogleがTPUでやり遂げ、Amazonが「Trainium」「Inferentia」で追いかけ、AppleがNeural Engineで独自路線を確立したパターンを、今度はメタが本格的に踏もうとしている。 実務への影響——日本のエンジニア・IT管理者はどう読む？ このニュースは一見「テック巨人同士の話」に見えるが、日本のIT現場にも無関係ではない。 クラウドAIサービスのコスト構造が変わる: MetaはFacebook・Instagram・WhatsAppを通じてAIレコメンデーション、コンテンツモデレーション、広告最適化を巨大スケールで動かしている。カスタムシリコンによるコスト削減が実現すれば、メタのAIプラットフォームを利用するビジネスへの価格競争力が増す。 「AIはNVIDIAがすべて」という前提が崩れる: エンタープライズがAI基盤を設計するとき、GPUクラスター一辺倒ではなく推論専用アクセラレータとの組み合わせを検討する流れが加速する。AWSのInferentia、GoogleのTPU、AzureのMaia 100と同様に、「用途に応じたシリコン選択」が当たり前になっていく。 オープンソースLLMとの関係: メタはLlamaシリーズをOSSで公開している。自社シリコンに最適化されたLlamaモデルが出てくれば、オンプレミスや独自クラウドでLlamaを動かしている企業は最適化の恩恵を受けられる可能性もある。 筆者の見解 「統合プラットフォームの全体最適」という観点から言えば、メタのこの判断は非常に筋が通っている。汎用部品を組み合わせた部分最適を積み重ねても、スケールが上がるほど全体コストは膨らむ。自社ワークロードに最適化された専用シリコンを持つことで、はじめて全体が効率化される。 興味深いのは、このアプローチがソフトウェア企業の「AIインフラの内製化」という大きなトレンドの一環だという点だ。今後は「AIを使う」だけでなく、「AIを支えるインフラを誰が設計するか」が競争の主戦場になっていく。 日本企業の多くは依然として「クラウドベンダーにすべてお任せ」の段階にある。それ自体は悪くない選択だが、インフラの主導権がどこにあるかを理解した上で採用するのと、単に惰性で選ぶのとでは、5年後のポジションが大きく変わってくる。 メタとブロードコムの動きは、「仕組みを設計できる少数の組織」と「仕組みを使わせてもらう多数の組織」という分断をさらに加速させるかもしれない。それを他人事として眺めるのか、自分たちのアーキテクチャを問い直すきっかけにするのか——その判断こそが、これからのIT組織の命運を分けると思っている。 出典: この記事は Zuckerberg taps Broadcom to build a massive AI silicon empire for billions of users の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは最新の累積更新プログラムKB5083769をWindows 11向けにリリースし、リモートデスクトップ（RDP）の動作に大きな変更を加えた。テレワークが定着した日本のIT現場では直接影響を受ける可能性が高く、IT管理者はこの変更内容を早めに把握しておきたい。 KB5083769が変えるリモートデスクトップの何か このアップデートにおけるリモートデスクトップの変更は、主に以下の3点に集約される。 接続フローの刷新 RDPクライアントの接続シーケンスが見直された。従来の動作と比較して、認証フェーズのタイミングや資格情報の受け渡し方法が変更されており、特定の環境では接続確立までの挙動が変わる場合がある。グループポリシーや条件付きアクセス（Conditional Access）と組み合わせている環境では動作確認を推奨する。 ネットワークレベル認証（NLA）の動作調整 NLA（Network Level Authentication）まわりの処理が調整されており、セキュリティ強度を維持しながらも互換性を改善する方向で手が入っている。古いRDPクライアントとの相互接続性に影響が出るケースが報告されているため、社内にWindows 10以前のクライアントが混在する環境では十分な検証が必要だ。 資格情報の保護強化 Credential Guardとの連携部分でも変更が加わっており、資格情報のメモリ保護の観点で強化が図られている。これはPass-the-Hash攻撃への対策として正しい方向性であり、ゼロトラスト的なアーキテクチャを推進している組織にとっては歓迎できる変更だ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 リモートデスクトップは日本の企業環境で依然として広く使われている。クラウドファーストを掲げつつも、オンプレミスのWindows Serverへのリモートアクセス手段としてRDPが生き残っているケースは多い。以下の点を確認しておくことを強く推奨する。 今すぐ確認すべき項目： テスト環境でKB5083769を先行適用し、既存のRDP接続が正常に動作するか確認する。特にAzure Virtual DesktopやWindows 365をRDP経由で利用している環境は優先度を上げる **グループポリシーのコンピューターの構成 > 管理用テンプレート > Windowsコンポーネント > リモートデスクトップサービス**配下の設定項目を見直し、意図しないオーバーライドがないか確認する サードパーティのRDPクライアント（FreeRDP等）を使用している場合は互換性テストを実施する Windows Updateの展開タイミングを組織内で調整し、RDPが業務クリティカルな環境への適用は段階展開にする 設定変更を要するケース： NLAが無効化されているレガシー環境では、この機会に有効化を検討する（無効のままでは接続できなくなるリスクが今後高まる） 多要素認証（MFA）をRDP接続に組み合わせていない環境は、Microsoft Entra ID（旧Azure AD）の条件付きアクセスとの統合を検討するタイミングだ 筆者の見解 リモートデスクトップまわりのセキュリティ強化は、個人的には明確に支持する。特に資格情報保護の強化はゼロトラスト実現に向けた重要なピースであり、「常時アクセス権を与えてVPNで囲む」という古いモデルから脱却するうえで不可欠な変化だ。 ただし、日本の企業IT現場の現実を見ると、この手の変更が「突然RDP接続できなくなった」という問い合わせ爆発につながることは容易に想像できる。MicrosoftがKBのドキュメントで変更内容を詳細に公開している姿勢は評価したいが、ユーザーへの事前周知という点ではまだ改善の余地がある。 Windows Updateについては以前から「数日様子を見る選択肢も立派なセキュリティ判断」と考えているが、セキュリティ修正を含む更新は早期適用が原則だ。今回のケースは接続互換性への影響があるため、「まず検証環境に当てて確認する」というプロセスを踏む価値がある。 長期的には、RDPという30年選手のプロトコルに依存し続けるアーキテクチャ自体を見直すべきだろう。Azure Virtual DesktopやWindows 365への移行が進めば、こうした個別のKB変更に翻弄されるリスクも減る。この更新を「既存環境の棚卸し」のきっかけにしてほしい。 出典: この記事は Microsoft details Windows 11 KB5083769 Remote Desktop changes の内容をもとに、筆者の見解を加えて独自に執筆したものです。

SQL Serverを日常的に扱うデータベース管理者・開発者にとって、SQL Server Management Studio（SSMS）のアップデートは地味だが確実に業務効率に効いてくる出来事だ。Microsoftは今月、SSMS 22.5を公開した。移行作業の合理化、SQLプロジェクト機能の強化、全体的な生産性向上がこのリリースの柱となっている。 SSMS 22.5の主な改善点 マイグレーション支援の強化 オンプレミスのSQL ServerからAzure SQL Database、Azure SQL Managed Instance、またはより新しいSQL Serverバージョンへの移行を支援する機能が強化された。移行アセスメントの精度向上と、移行前の互換性チェックが改善されており、「移行してみたら動かなかった」という事態を未然に防ぎやすくなっている。 日本のエンタープライズ環境では、SQL Server 2012や2014といった長期サポート終了済みバージョンがいまだ現役稼働しているケースが珍しくない。こうした環境からのリフトアップを検討している担当者にとって、移行前の影響調査ツールが充実することは直接的なメリットになる。 SQLプロジェクト機能の改善 SQL Projectsは、データベーススキーマをソースコードとして管理する仕組みで、DevOpsパイプラインへのDB定義の組み込みを可能にする。SSMS 22.5ではこのプロジェクト機能のUI操作性が向上し、スキーマ変更の追跡・比較・展開がよりスムーズに行えるようになった。 インフラやアプリコードはGitで管理しているのに、DBスキーマだけは属人的な手順書で管理——という二重管理の非効率は多くの現場で生じている。SQLプロジェクト機能を活用すれば、この課題にアプローチできる。 全体的な安定性・UXの改善 クエリエディタのIntelliSense応答性の向上、オブジェクトエクスプローラーの読み込み速度改善、一部の接続エラー修正なども含まれる。地道な改善だが積み重ねで体験は変わる。 実務への影響 DB管理者・DBAへ 移行アセスメント機能を使って、現行環境の互換性リスクを棚卸ししておくタイミングとして最適だ。特にSQL Server 2016以前のバージョンを運用している組織は、延長サポート終了のカウントダウンが迫っており、早期調査に越したことはない。 開発者・DevOpsエンジニアへ SQL Projectsをまだ使っていないなら、このリリースを機に試してみる価値がある。スキーマのバージョン管理は「ベストプラクティス」の話ではなく、CI/CDパイプラインの完成度に直結する実務課題だ。Azure DevOpsやGitHub ActionsとSQL Projectsを組み合わせれば、スキーマ変更のレビュー→テスト→本番展開を自動化できる。 IT管理者へ SSMS 22.xは.NET 8ベースに刷新されており、SSMS 18.x以前とは構造が大きく異なる。まだ旧バージョンを使い続けている環境は、バージョン共存に注意しつつ計画的な移行を検討したい。 筆者の見解 SSMSは長い間「使えるが重い、UIも古い」というイメージを持たれてきたツールだ。22.x系への刷新でその印象はかなり改善されつつあり、22.5もその延長線上にある地道なアップデートだと評価している。 個人的に注目しているのは、マイグレーション支援の継続的な充実だ。日本のSQL Server運用現場では、クラウド移行の「必要性は分かっているが踏み出せない」という状況が長く続いている。アセスメントツールが使いやすくなることで、「まず現状を可視化する」という最初の一歩が踏み出しやすくなる。Microsoftにはこの方向の投資をぜひ続けてほしい。 一方、SQLプロジェクトとDevOpsの統合については、まだ「使いこなせている現場が少ない」印象がある。ツールが整備されても、組織の習慣が追いつかなければ意味がない。この領域でのドキュメント整備や日本語情報の充実に期待したい。 SSMSは地味なツールだが、SQL Serverが現役で動いている現場は日本にまだ無数にある。そのエコシステムを着実にメンテし続けているMicrosoftの姿勢は、素直に評価できる点だ。 出典: この記事は SQL Server Management Studio 22.5 now out, here is what’s new の内容をもとに、筆者の見解を加えて独自に執筆したものです。

WordPressの人気フォームビルダープラグイン「Ninja Forms」のFile Upload拡張機能に、CVSS スコア 9.8 という最高クラスの深刻な脆弱性が発見された。認証なしにサーバー上へ任意のファイルをアップロードできるこの欠陥は、すでに実際の攻撃に悪用されており、日本を含む世界中のWordPressサイト管理者にとって緊急対応が求められる事態となっている。 脆弱性の詳細：何が問題だったのか 今回の脆弱性（CVE-2026-0740）は、Ninja Forms File Upload バージョン 3.3.26 以前に存在する。問題の核心は、ファイルアップロード処理におけるファイル種別・拡張子の検証が完全に欠如していたことだ。 Wordfenceの研究者の解析によると、ファイルを移動する処理において、移動先ファイル名に対するファイルタイプや拡張子のチェックが一切実装されていなかったという。これにより、攻撃者は .php 拡張子を持つファイル——つまりPHPスクリプト——をそのままサーバー上にアップロードできてしまう。 さらに問題を深刻にしているのがパストラバーサル（Path Traversal）の組み合わせだ。ファイル名のサニタイズ処理も行われていないため、アップロード先のパスを操作してWebルートディレクトリにファイルを配置することすら可能になる。攻撃のシナリオを整理すると： 認証なしに悪意あるPHPスクリプトをアップロード パストラバーサルでWebからアクセス可能なディレクトリに配置 そのURLにブラウザやcurlでアクセスするだけでリモートコード実行（RCE）が成立 この流れは教科書的なWebシェル設置攻撃そのものであり、成功した場合はサイトの完全乗っ取りにつながる。 発見から修正までのタイムライン セキュリティ研究者のSélim Lanouar氏（whattheslime）が2026年1月8日にWordfenceのバグバウンティプログラムへ報告。同日のうちにベンダーへ詳細が開示され、Wordfenceはファイアウォールルールによる暫定的な保護をユーザーへ展開した。 2月10日に部分的な修正が行われ、最終的な完全修正版（バージョン 3.3.27）が3月19日にリリースされた。発見から修正まで約70日。速いとは言えないが、バグバウンティ経由での調整プロセスとしては標準的な範囲だろう。 深刻なのはその後だ。修正版が公開されてから2週間以上が経過しているにもかかわらず、Wordfenceは直近24時間だけで3,600件以上の攻撃をブロックしていると報告している。File Upload拡張機能の利用者は約9万件。更新が完了していないサイトが相当数残っていることが、これだけの攻撃頻度から見てとれる。 実務への影響：WordPress運用者が今すぐやるべきこと 即時対応（今日中に） Ninja Forms File Upload を使用している場合、バージョンを 3.3.27以上 に更新する 更新前後でファイルアップロード機能の動作確認を実施する サーバーのアクセスログを遡り、不審なPHPファイルへのPOSTリクエストがないか確認する アップロードディレクトリに .php 拡張子のファイルが存在しないか確認する 中期的な対策 WordPressのアップロードディレクトリには、PHPの実行を禁止する .htaccess を設置しておくことを強く推奨する。これは今回のような脆弱性が将来再発した際の多層防御（Defense in Depth）として機能する。 出典: この記事は Hackers exploit critical flaw in Ninja Forms WordPress plugin の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国の暗号資産取引所Krakenが、インサイダー脅威を起点とした恐喝被害を公表した。CSO（最高セキュリティ責任者）のNick Percoco氏が声明を発表し、内部システムへのアクセス映像を公開すると脅す犯罪グループの存在を明かした。「システムそのものは侵害されていない」「資金は安全だ」とする一方で、「支払わない・交渉しない」という明確な姿勢を打ち出している。 暗号資産業界特有の話に見えるかもしれないが、この事件の構造はあらゆる業界のIT担当者にとって他人事ではない。 何が起きたのか 2025年2月、信頼できる情報筋から「クライアントサポートシステムへのアクセスを示す映像が犯罪グループ間で出回っている」という提供を受けたKrakenは調査を開始。その結果、脅威アクターに採用・買収されたサポート従業員1名が特定された。 その後、さらに別の映像が出回っていることが判明し、2件目の不正アクセスも確認。いずれも迅速に当該従業員のアクセスを剥奪し、影響を受けたユーザーへの個別通知を行った。 影響を受けたアカウントは約2,000件（全ユーザーベースの0.02%）で、露出した情報はクライアントサポートデータに限定。顧客資金へのリスクはなかったとしている。Krakenは現在、複数の司法管轄にまたがる連邦法執行機関と連携して法的措置を進めているという。 インサイダー脅威という構造的問題 今回の手口は「従業員をスカウト・買収して内部アクセスを得る」という古典的かつ非常に有効なアプローチだ。技術的な防御が強固になればなるほど、攻撃者は人間という最も管理しにくいポイントを狙う傾向が強まる。 同じく暗号資産交換所のCoinbaseでも2025年中旬に類似の事件が発生している。インド拠点のカスタマーサポート代理店の従業員が買収され、約7万人の顧客情報が流出。Coinbaseは損害総額を約4億ドルと試算した。 業界や規模は異なっても、この構造は共通している。外部の技術的境界線を突破できなければ、人を使って内側から扉を開けようとする——これが現代の攻撃シナリオの現実だ。 最小権限とJust-In-Timeアクセスが鍵 サポート従業員が「アクセスすべきでないデータにアクセスできた」という事実こそが問題の核心だ。技術的な制御がどこかで機能していれば、内部不正はここまでスムーズには進まなかったはずだ。 ここで重要になるのが最小権限の原則（Principle of Least Privilege）とJust-In-Time（JIT）アクセスだ。常時アクセス権を付与しておくことは、インサイダー脅威に対してほぼ無防備に等しい。「必要な時に、必要なスコープだけ、期限付きで付与する」設計が、ダメージの最小化に直結する。 あわせて、UEBA（User and Entity Behavior Analytics）によるアクセスログの常時監視と異常パターン検知も有効だ。不正が行われたとしても早期検知できれば、被害拡大を防げる可能性が大きく高まる。 日本のIT現場への影響 日本の大企業では、従来のネットワーク境界型セキュリティとゼロトラストの考え方が中途半端に混在しているケースが多い。「社内ネットワーク内なら信頼できる」という思想が残っていると、インサイダーによる不正アクセスを技術的に防ぐ仕組みが機能しない。 クラウドサービスや外部委託パートナーが当たり前になった今、「誰がどのデータに触れられるか」を厳密に管理するIAM（Identity and Access Management）の整備は待ったなしだ。SaaSのカスタマーサポートやヘルプデスク業務を外部委託している組織は特に、データスコープの設計とアクセス制御の粒度を今すぐ見直してほしい。 Krakenの対応自体は迅速だった。アクセス剥奪・調査・ユーザー通知・法執行機関との連携——いずれも教科書通りのインシデントレスポンスだ。「払わない・交渉しない」という姿勢も正しい。恐喝に応じることは次の攻撃を招くだけだ。 筆者の見解 今回の事件が示す最も重要な教訓は、「技術的に堅牢なシステムでも、アクセス権を持つ人間が弱点になりうる」という当たり前の事実だ。そして、この問題に対する答えは「人を信頼しない設計」にある。これは人間不信ではなく、構造として不正を難しくするということだ。 少し気になる点がある。1件目の対応後、なぜ同じ経路での再発を防ぐ仕組みが機能しなかったのか——外部からは見えない部分だが、2件目が発覚してからの公表という経緯には再発防止策の実効性という観点で問うべき点が残る。 インサイダー脅威への対策として明日から取り組めることを整理する： 常時アクセス権の棚卸し: サポート担当者が「見える必要のないデータ」にアクセスできていないか確認する JITアクセスの導入検討: Azure AD（Entra ID）のPIM（Privileged Identity Management）などを活用し、昇格アクセスに承認フローと有効期限を設ける 操作ログの可視化と自動アラート: 通常業務では発生しないアクセスパターンを検知する仕組みを整備する 外部委託先のアクセス範囲の見直し: 委託先従業員のアクセス制御は自社従業員と同等以上に厳格に 技術的な境界線を固めた次のフロンティアは、確実に「人」だ。セキュリティ投資を考える際、このインサイダー脅威という視点を必ず組み込んでほしい。 出典: この記事は Crypto-exchange Kraken extorted by hackers after insider breach の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Disneyがまた静かにSteamのライブラリを縮小させた。今回の削除対象は15本に上り、Star Warsシリーズをはじめとした映画タイアップ作品やクラシックタイトルが含まれる。公式なアナウンスも、理由の説明も一切ない。ユーザーが気づいたのは、ストアページが消えていたからだ。 何が消えたのか 今回の一斉削除は「最初の波」ではない。Disneyはここ数ヶ月で段階的にSteamからタイトルを取り下げており、今回はその延長線上にある。対象作品には長年ファンに親しまれてきたゲームが多く含まれ、すでに購入済みのユーザーについても今後のサポートや動作保証が不透明な状況だ。 削除の背景として考えられる要因はいくつかある。 ライセンス期限切れ: 映画タイアップ作品は音楽・映像素材のライセンスが複雑で、更新コストが見合わないと判断されることがある Disney+への統合戦略: コンテンツをストリーミングプラットフォームに集約し、ゲームも独自チャンネルに誘導する意図がある可能性 保守コストの問題: 旧来のゲームエンジンや32ビット対応など、維持に工数がかかるタイトルを整理している いずれも推測の域を出ないのは、Disneyが何も語っていないからだ。 デジタル所有権という幻想 この件で改めて浮き彫りになるのは、デジタルコンテンツの「購入」は実質的にライセンスの取得に過ぎないという現実だ。 Steamで5,000円払ってゲームを「買った」としても、パブリッシャーがストアから引き上げれば新規購入はできなくなる。すでにライブラリに入っているタイトルは引き続き遊べる場合が多いが、OSのバージョンアップや端末の変更によって動作しなくなるリスクは常にある。 物理メディアと異なり、デジタル購入には「手元に残る」という確実性がない。これはゲームに限らず、電子書籍・動画・音楽にも共通する構造的な問題だ。 実務への影響——IT担当者・開発者の視点 一見「ゲームの話」に見えるが、この問題はエンタープライズのIT運用とも地続きだ。 クラウドサービス依存のリスク管理 SaaSやクラウドサービスも、ベンダーの事業判断次第でいつでも仕様変更・廃止になりうる。「今動いているから大丈夫」という感覚は危険で、代替手段の確保と依存度の可視化が常に必要だ。 契約・ライセンス条件の精査 「購入」と「ライセンス取得」の違いを契約書レベルで理解しておくことは、個人だけでなく法人調達でも重要な視点になっている。 データポータビリティの確保 ゲームセーブデータのみならず、業務データについても「サービスが消えたときに自分のデータを取り出せるか」を事前に確認しておくべきだ。 筆者の見解 ゲーム産業におけるデジタル移行は、便利さと引き換えに「永続性の保証」を手放させた。ディスクがあれば20年後でも遊べる。しかしデジタル購入は、パブリッシャーのビジネス判断に全面依存している。 Disneyの今回の対応で残念なのは、説明がないことだ。理由がライセンス問題であれコスト問題であれ、誠実に伝えることはできたはずで、そこを省いたのはユーザーへの敬意という点でもったいない判断だと思う。 より広い文脈で言えば、このような事例が積み重なるたびに「デジタルコンテンツを信頼してよいのか」という問いが強くなる。プラットフォームと権利者が協力してユーザーの「買ったものは残る」という合理的な期待に応えていく仕組みを業界全体で整えていくことが、長期的な信頼構築につながるはずだ。 ゲームの保存・アーカイブに取り組むコミュニティの存在は、こうした問題への一つの答えでもある。技術的な記録を後世に残すという意味でも、デジタル保存の議論はこれからも重要であり続けるだろう。 出典: この記事は Disney delists 15 more classic games from Steam without an explanation の内容をもとに、筆者の見解を加えて独自に執筆したものです。

何が変わったのか Raspberry Pi OSの最新版となるバージョン6.2が、セキュリティ面で大きな方針転換を打ち出した。これまでデフォルトユーザー（piユーザーまたはセットアップ時に作成するユーザー）には、sudo コマンドをパスワードなしで実行できる設定が与えられていた。利便性優先の設計判断だったが、それが長年「セキュリティホール」として指摘され続けてきた。 バージョン6.2では、この設定が変更され、sudo を使う際にはパスワード入力が必要になった。たった一行の /etc/sudoers 設定の変更に見えるが、Raspberry Piを使う現場にとってはインパクトの大きな転換点だ。 なぜこれが重要か 「デフォルトで安全」の原則 Raspberry Piは教育・ホビー用途だけでなく、産業用IoTデバイス、ネットワーク機器の代替、ホームサーバーとして本番環境に使われているケースが増えている。にもかかわらず、デフォルト設定が「パスワードなしで何でもrootできる」というのは、ゼロトラストの観点から見れば大問題だった。 攻撃シナリオは単純だ。不正なスクリプトが実行された場合、あるいはSSHへの不正アクセスが成功した場合、パスワードなしsudoがあればそのままシステム全体を掌握できる。物理的なアクセスが必要なデバイスでも、ネットワーク越しに操作されているRaspberry Piなら話は別だ。 IoT時代のエンドポイントセキュリティ Raspberry Piベースのデバイスが増える中で、「設定を変えていないから大丈夫」という安心感は危険だ。むしろ「デフォルトのままだから危ない」という認識が正しい。今回の変更は、その認識を製品レベルで是正した意味がある。 実務での活用ポイント 既存環境の確認 現在稼働中のRaspberry Pi OSを使っている場合、まず以下を確認したい。 出典: この記事は Raspberry Pi OS 6.2 locks down security with a major change to sudo access の内容をもとに、筆者の見解を加えて独自に執筆したものです。

4月のPatch Tuesdayは「地味だが実用的」な月 2026年4月のPatch Tuesday（KB5083769）がWindows 11向けに展開を開始した。対象はビルド26100.8246（24H2）および26200.8246（25H2）。今月は派手な目玉機能こそないが、アクセシビリティ・セキュリティ・日常操作の各面でじわじわと効いてくる改善が揃っている。2月・3月に続き、2026年のMicrosoftは「大きな発表より着実な品質向上」路線を継続している印象だ。 なお、新機能の一部はControlled Feature Rollout（CFR）によって段階的に展開される。インストール直後に変化が見えなくても、数日〜数週間でロールアウトされる場合があるので焦らず待ってほしい。 主な変更点 ナレーターのCopilot連携が全デバイスに拡大 これまで画像の詳細説明機能はCopilot+ PC（オンデバイスAI搭載機）に限定されていた。今回のアップデートで、すべてのWindows 11デバイスで利用可能になった。 操作方法はシンプルだ。 Narrator key + Ctrl + D → フォーカス中の画像を説明 Narrator key + Ctrl + S → 画面全体を説明 トリガーするとCopilotが起動し、画像を読み込んだ状態でプロンプト入力が可能になる。プライバシー面では「ユーザーが明示的に説明を要求するまで画像はCopilotに送信されない」と明記されており、自動送信はない。Copilot+ PCではオンデバイス処理による即時応答が引き続き利用できる。 スクリーンリーダーを主要インターフェースとして使う視覚障害ユーザーにとって、これは遅きに失した感もあるが確実に前進といえる改善だ。 Smart App ControlのON/OFFが再インストールなしに可能に セキュリティ担当者やパワーユーザーが長年悩んでいた制約がついに解消された。 Smart App Control（SAC）は信頼されていないアプリの実行をブロックするセキュリティ機能だが、従来は一度有効化すると無効化にはWindowsのクリーンインストールが唯一の手段だった。この制約は2026年1月から準備が始まり、今月のアップデートで正式解禁となった。 設定変更は「設定 → Windowsセキュリティ → アプリとブラウザーのコントロール → Smart App Controlの設定」から行える。 開発者環境やラボ環境では「テスト用にSACを一時的に切る→作業後に戻す」という運用が現実的になった。 Microsoft 365 FamilyプランのSettings内アップグレード Microsoft 365 Familyサブスクライバーは、「設定 → アカウント」から上位プランへのアップグレードができるようになった。不要なら通知を非表示にする設定も用意されている。 実務への影響 IT管理者・セキュリティ担当者へ Smart App Controlの柔軟化は大きい。これまで「SACを有効化すると後戻りできない」という心理的ハードルがあり、本番環境への適用を躊躇する組織も少なくなかった。柔軟にON/OFFできるようになったことで、段階的な導入・試験運用がしやすくなる。ゼロトラスト構成の一環として積極的に検討する価値がある。 開発者・パワーユーザーへ SACが開発ツールやサードパーティ製ユーティリティを弾くケースは珍しくない。再インストール不要になったことで、開発作業中は一時無効・納品前に再有効化、という現実的な運用が可能になった。 アクセシビリティ対応を考えるエンジニアへ ナレーター強化はOSレベルのアクセシビリティ基盤が広がったことを意味する。Webアプリやエンタープライズアプリ開発でスクリーンリーダー対応を検討している場合、テスト環境として全デバイスで使えるようになったのは環境の統一という観点でも歓迎だ。 適用タイミングの判断 Patch Tuesdayのアップデートは直後に「適用したら壊れた」という報告が出ることもある。今月は大きなアーキテクチャ変更はないが、業務クリティカルな環境では数日の様子見も立派なセキュリティ判断だ。 ...

MicrosoftのVP（技術スタッフ上席）であるScott Hanselmanが、macOS Sonomaから着想を得た小さなツール「PeekDesktop」をGitHubで公開した。デスクトップの壁紙部分をクリックするだけで開いているウィンドウをすべて一瞬で最小化し、もう一度クリックすれば元の配置・状態に復元される——それだけの機能だが、その「だけ」がじつに心地よい。 PeekDesktopとは何か PeekDesktopはスタンドアロンの実行ファイル（6.15MB）として配布されており、ZIPを展開してexeを起動するだけで動作する。システムトレイに常駐するが、アイドル時のメモリ使用量は2MB以下という超軽量設計だ。Snapdragonを搭載したWindows on ARM機にもネイティブ対応している点は、さすが開発元がMicrosoftのエンジニアだと感じさせる。 macOS Sonoma の「壁紙をクリックして他のウィンドウを隠す」機能とほぼ同等の体験を提供する。Windowsにも「デスクトップを表示（Win + D）」はあるが、ウィンドウの配置と状態を完全に保持したまま復元できるかどうかが決定的に違う。Win + Mは「最小化のみ」で戻す機能がなく、Win + Dは「タスクバー以外の場所で押すと戻せない」ことがある。PeekDesktopはその曖昧さをなくした点で、既存の機能より使い勝手が上だ。 現時点での制限事項 完成度は高いが、現時点でいくつかの課題もある。 ごみ箱の右クリックが難しい: 右クリックするとすべてのウィンドウが復元されてしまい、コンテキストメニューが出るまでに2度右クリックが必要になる タスクマネージャーが対象外: Task Managerは最小化の対象にならず、壁紙クリックに反応しない 新規フォルダ作成が誤動作: ウィンドウ最小化中にデスクトップで「新しいフォルダーを作成」しようとすると、最小化が解除されてしまう いずれも設計上の割り切りや初期バージョンの制約と考えられるが、日常業務での利用を想定するなら今後の改善に期待したいところだ。 実務への影響 エンジニア・クリエイター向けのヒント ファイルの整理やデスクトップにドラッグ&ドロップしたいとき、従来は「Win + D → 作業 → もう一度Win + D」と二手かかっていたが、PeekDesktopで一貫した操作に統一できる ARM端末（Surface Pro X、Copilot+ PCなど）でも動作するため、最新ハードウェアで試すのに向いている インストーラーではなくポータブルexeなので、会社の管理端末など「インストール制限のある環境」でも展開しやすい（組織のポリシー次第だが） IT管理者向けの留意点 未署名のサードパーティexeが組織端末に持ち込まれるリスクについては、AppLockerやWindows Defender Application Controlのポリシーで管理するのが現実的だ。開発者がMicrosoftのVPであることはあくまで「信頼性の参考」にすぎず、組織的な管理は別途行うべきである。 筆者の見解 このツールで最も興味深いのは、「機能そのもの」よりも「Microsoftの現職VPがWindowsに足りない機能を個人開発で補った」という事実だ。 macOS Sonomaの壁紙クリック機能は2023年に登場し、以来3年が経過した。その間、Windowsがこれを正式に採用しなかったのは意外でもある。壁紙をクリックしたときに「アイコン以外の空白領域か」を判定する処理はシェルレベルで実現できるはずで、技術的な障壁は高くないはずだ。 もちろんWindowsはデスクトップ利用の多様性が高く、タッチ操作・タブレットモード・ゲームモードとの整合性など、考慮すべき変数はmacOSより格段に多い。その意味でHanselmanのツールが「自分のユースケース向けに割り切って作った」と割り切っているのは合理的だ。 ただ、このような良質な体験が「公式機能」としてWindowsに統合されることを期待したい。Windowsは世界中のビジネスパーソンが毎日使うOSだ。「個人ツールで補完する」文化の積み重ねより、細部の完成度をOSレベルで高めることに力を注いでほしい——それだけの実力はあるのだから。 PeekDesktopはGitHubから無償で入手できる。興味ある方はまず個人PCで試してみるといいだろう。 出典: この記事は Microsoft’s VP brings macOS-style click to reveal desktop feature to Windows with new tool の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Apple App Storeという「信頼の砦」が突破された。macOS向けの偽Ledger Liveアプリが審査を通過し、わずか数日間で50人から合計約950万ドル（約14億円）もの暗号資産が奪われた。被害額の大きさもさることながら、この事件が突きつけた問いは深刻だ——「公式ストアに掲載されているから安全」という前提は、もはや成立しないのではないか。 何が起きたか——巧妙な「空白地帯」の悪用 攻撃者が狙ったのは、Ledgerの公式アプリ配布体制の「隙間」だった。Ledgerは公式macOSアプリを自社サイトのみで配布しており、App StoreにはiOSアプリのみを掲載している。つまりApp StoreでmacOS向けLedger Liveを検索しても、公式版は見当たらない。 この「公式が空けた空白地帯」に攻撃者は偽アプリを滑り込ませた。開発者名は「Leva Heal Limited」という実在しない企業名を使用。さらに信頼性を演出するため、わずか2週間でバージョンを1.0から5.0まで更新するという手口で「活発に開発されているアプリ」を装った。 被害の実態——シードフレーズを入力した瞬間、全資産が消える アプリを起動すると、ユーザーはシード（リカバリーフレーズ）の入力を求められる。これはハードウェアウォレットの「マスターキー」に相当する24単語のフレーズだ。これを入力した瞬間、攻撃者はBitcoin、Ethereum、Solana、Tron、Rippleなど複数チェーンにまたがる全資産へのフルアクセス権を手に入れる。 ブロックチェーン調査機関ZachXBTによると、4月8日から11日の間だけで3人が7桁ドル（数億円規模）の損失を被った。ミュージシャンのG. Loveも5.9 BTC（当時約6300万円）を失ったと公表している。 盗まれた資金はKuCoin経由で「AudiA6」と呼ばれるミキシングサービスに流れ、150以上のアドレスに分散されて資金洗浄が行われた。 なぜAppleの審査を通過したのか 詳細は明らかにされていないが、偽アプリが審査を通過した背景には審査の構造的限界がある。Appleのレビューは主にマルウェアや規約違反のチェックが中心だ。起動直後には悪意ある動作をせず、ユーザーが入力した情報をサーバーに送信するだけの設計であれば、自動・手動の両審査で検出されにくい。 また、開発者アカウントの身元確認も完全ではない。今回の「Leva Heal Limited」のような架空企業名での登録が通り抜けてしまったことは、プラットフォーム側の本人確認体制に課題があることを示している。 日本のIT管理者・エンジニアにとっての実務的インパクト 暗号資産を扱う組織はもちろんだが、この事件から学べることはより広い範囲に及ぶ。 1. アプリ調達ポリシーの見直し 「公式ストアからインストール＝承認済み」というルールは今すぐ再検討を。正規開発者がストアで配布しているかどうかを開発者の公式サイトで必ずクロスチェックする運用に変えるべきだ。 2. シークレット・認証情報の取り扱い教育 シードフレーズ、API キー、パスワードなど「入力を求めてくるアプリ」への警戒を組織全体で徹底する。正規のハードウェアウォレット管理ツールがソフトウェア経由でシードを要求することは、原則としてない。 3. エンタープライズでのアプリ配布管理 MDM（Mobile Device Management）やIntune等のエンドポイント管理ツールで承認済みアプリリストを管理し、従業員が野良アプリをインストールできないポリシーを実装する。「禁止ではなく安全に使える仕組みを作る」——これが運用として正しい方向性だ。 4. NHI（Non-Human Identity）管理の観点でも同様の問題が起きる サービスプリンシパルやAPIキーが「公式っぽいサービス」に渡されるケースも増えている。ヒューマンIDと同様に、NHIの認証先を定期的に棚卸しし、不審なアプリ連携がないか確認する運用が重要だ。 筆者の見解 「App Store＝安全」という信頼モデルは、ゼロトラストの観点からすれば最初から疑問符が付いていた。ネットワークの内側にいるからといって安全とは限らない——これがゼロトラストの基本原則だが、アプリのエコシステムにも同じことが言える。「公式ストアに掲載されている」は信頼の一要素にはなるが、それだけで十分な根拠にはならない。 今回の事件でもっとも問題だと感じるのは、Ledger自身がApp Storeの空白地帯を長期間放置していた点だ。公式macOSアプリをストアで配布しないという判断は理解できる（独自配布による柔軟性確保など）。しかしその「空白」が攻撃者に利用されるリスクを放置し続けたのは、ユーザー保護の観点で惜しい判断だったと言わざるを得ない。プレースホルダーアプリを置くだけでも違った。 Appleについても、プラットフォームの信頼性を商業的強みとしてきた以上、開発者本人確認と審査の精度をさらに高める責任がある。審査体制の限界を認めつつも、構造的な改善を続けることが「App Storeブランド」を守ることにつながる。 暗号資産を扱っていない読者にも、この事件はひとつの問いを投げかけている——あなたの組織が「信頼している」インフラやサービスは、本当に誰によって検証されているか。「今動いているから大丈夫」という感覚が最大のリスクだ。 出典: この記事は Fake Ledger Live app on Apple’s App Store stole $9.5M in crypto の内容をもとに、筆者の見解を加えて独自に執筆したものです。