侵害の約60%では、攻撃者が侵入した時点ですでにパッチが提供されていました。この調査結果は、J.P. Morganの2026年7月のレポート「Patchmageddon」によるもので、問いを「修正が存在するかどうか」から「設定にどれだけ時間がかかるか」へと移しています。
その猶予は急速に狭まっています。同じレポートでは、新たにリリースされたパッチをリバースエンジニアリングし、それを数分で機能するエクスプロイトに変えることができるAIツールについても説明されています。利用可能なパッチが設定されないまま放置される日々は、その分だけ攻撃者に悪用される日になります。
Microsoft Intuneで管理されるサードパーティアプリでは、その日数の多くがパッケージ化に費やされます。ITチームはインストーラーをダウンロードし、パッケージを作成し、検出ルールを記述し、テストして割り当てたうえで、それをすべてのアプリとすべてのリリースごとに繰り返します。その結果生じるのが、誰も想定していなかったパッチ適用の遅れです。
ここでは、悪用可能な期間がどれほど急速に短くなっているのか、Intuneのアプリパッケージ化によってどこで遅れが生じるのか、そしてそのギャップを埋めるには何が必要かを解説します。
攻撃者が新たな脆弱性を悪用するまでのスピード
脆弱性の悪用は、今や攻撃者が侵入する最も一般的な手口になっています。2026 Verizon Data Breach Investigations Reportによると、侵害における初期アクセスの31%は悪用によるもので、前年の20%から増加しました。
こうした攻撃の多くは、すぐに始まります。Zero Day Clockによると、2026年上半期に新たに悪用が確認された脆弱性の4分の1超は、公表されたその日にすでに攻撃を受けていました。
パッチ適用が追いついていません。Verizonの調査では、既知の悪用された脆弱性を完全に修正するまでに組織が要した期間の中央値は43日で、32日から増加しており、さらに、そのうち完全に修正されたものは全体の約4分の1にとどまりました。
古い脆弱性も依然として悪用されています。Zero Day Clockによると、2026年8月下旬のある1週間において、攻撃者が標的にしていた典型的な脆弱性は、公開から4年が経過していました。
数週間かかるパッチサイクルでは、最もリスクの高い期間にサードパーティ製アプリが無防備なままになります。更新プログラムがいつまでも提供されなければ、何年もの間そのまま無防備な状態になります。
利用可能なパッチが適用されない理由
パッチは存在するのに、なぜこれほど多くが未展開のままなのでしょ うか。TuxCareの2026 Open Source Landscape Reportによると、エンタープライズ向けオープンソースのユーザーにおけるセキュリティインシデントの61%は、利用可能でありながら一度も適用されなかったパッチに関連していました。ダウンタイムの制約は遅延の最も一般的な理由であり、回答者の43%がそれを挙げました。
その調査はオープンソース環境に焦点を当てたものでしたが、同じ原因はITチームが更新を設定するあらゆる場面で見られます。
何かを壊してしまうことへの不安。業務上重要なアプリを妨げたり、予定外の再起動を強いたりするアップデートは、それ自体がインシデントになってしまいます。テストが行われていないと、設定するより待つほうが安全に感じられます。
適切なスキルを持つ人材が少なすぎる。Win32アプリを正しくパッケージ化するには、専門的な知識が必要です。その知識が1人か2人に集中していると、更新のたびにその人たちの手が空くまで待たなければなりません。
更新のたびに、それ自体が1つのプロジェクトになります。サードパーティベンダーはそれぞれ独自のスケジュールでリリースを行い、どのリリースも公開前に同じ準備が必要です。この作業はきれいにまとめて処理できることがほとんどないため、キューは減るよりも早く増えていきます。
パッチが適用された証拠がない。デバイスレベルでの確認がないと、IT部門はどのエンドポイントで脆弱なバージョンがまだ動作しているのか把握できず、誰かが 調べるまでその抜け漏れは見過ごされてしまいます。
Intuneのアプリパッケージ化がサードパーティパッチ適用を遅らせる原因
Intune は Windows と Microsoft 365 の更新には適切に対応できますが、サードパーティ製アプリの管理はより困難です。Microsoft の Enterprise App Management は、Intune で最新の状態を維持できる、Microsoft 製および Microsoft 以外の Windows アプリをあらかじめ用意したカタログを提供することで、その課題に対応します。ただし、そのカタログに含まれるのは Microsoft が用意したアプリのみであり、リクエストしたアプリが追加される保証はありません。
カタログ外のアプリ、カスタムアプリや社内アプリ、そして Enterprise App Management を導入していないテナントは、引き続き標準のWin32プロセスを使用します。
新しいリリースが出るたびに、そのプロセスは通常次のようになります。
ベンダーからインストーラーをダウンロードし、正しいバージョンとアーキテクチャであることを確認します。
サイレントインストールとアンインストールのコマンドを確認します。IntuneではWin32アプリをユーザー操作なしでインストールする必要があるため、各インストーラーがどのスイッチに対応しているかを誰かが確認しなければなりません。
Microsoft Win32 Content Prep Toolを使用して、インストーラーを.intunewinファイルとしてラップします。
アプリが正しくインストールされたことをIntuneで確認できるように、検出ルールを作成します。
古いバージョンを新しいバージョンで置き換えるには、上書き設定を構成します。
ユーザーに届く前に、予備のデバイスまたは仮想マシンでパッケージをテストしてください。
アプリを割り当て、適切なグループに設定します。
展開状況を確認し、失敗したデバイスのトラブルシューティングを行います。
するとベンダーがまた新しいアップデートを出し、そのサイクルが最初から繰り返されます。この手順を、環境内のすべてのサードパーティアプリと、それぞれがリリースするすべての更新に当てはめると、Intune Win32アプリの設定は恒常的なバックログになってしまいます。そのバックログによって、「利用可能」が数週間先の話になってしまいます。
サードパーティのパッチ適用プロセスを高速化するために必要なこと
J.P. Morganのレポートでは、組織に対して最新バージョンのソフトウェアを使用し、パッチのテストから展開までのスケジュールを短縮することを推奨しています。Intune のサードパーティアプリでは、いくつかの運用要件に集約されます。
サードパーティ製アプリの最新インベントリ。パッチ適用の判断はすべて、どのデバイスでどのアプリとバージョンが稼働しているかを把握することから始まります。
信頼できる、検証済みのインストーラーソース。審査済みのソースからインストーラーを取得することで、改ざんされた、または悪意のあるパッケージを設定するリスクを低減できます。
パ ッケージ作成を自動化。サイレントインストールとアンインストールのコマンド、検出ルール、置き換え設定は、手書きのスクリプトなしで、各リリースごとに自動生成される必要があります。
新しいバージョンを自動検出。ベンダーが更新をリリースしたら、誰かがそのリリースに気づくのを待たずに、新しいパッケージを作成できるべきです。
設定前に自動テストとセキュリティスキャンを実施。クリーンなマシンですべてのビルドをテストすることで、チームが更新を見送る主な理由の1つを取り除けます。
段階的なロールアウト。まずパイロットグループに設定すると、更新によって問題が発生した場合でも影響を抑えられます。
エンドユーザー向けのコントロール。延期、再起動のプロンプト、猶予期間により、作業の途中を中断させることなく更新を配信できます。
設定状況と監査の可視性。デバイスごとのレポートにより、各パッチが実際に適用されたことを確認でき、監査用の記録も残せます。
サードパーティパッチ対応までの期間を測るための質問
ツールやプロセスを変更する前に、現在のチームの状況を把握しておくことが役立ちます。以下の質問で、実際にどれほど露出期間が広がっているかがわかります。
主要なサードパーティアプリ上位10件では、ベンダーのリリースから Intune への割り当てまでに何日かかっていますか？この数値は実際のパッチ適用可能期間を示しており、多 くの場合、チームの想定より長くなります。
チーム内で Win32 アプリを正しくパッケージ化できる人は何人いますか？答えが1人か2人なら、すべての更新はその人たちが対応できるかどうかに左右されます。
テストが終わっていないために、最後に更新を延期したのはいつですか？遅延が頻繁に発生するなら、問題はスケジュールではなくテストのボトルネックにあります。
パッチがすべてのデバイスに適用されたことを証明できますか？デバイスごとの確認がなければ、完了したように見える更新でも、エンドポイントが依然としてリスクにさらされたままになる可能性があります。
エージェント型パッケージングがリリースから設定までの道のりを短縮する方法
J.P. Morganのレポートは、警告の陰に隠れて見落としがちな点を指摘しています。脆弱性を見つけて悪用するために使われるのと同じAIツールが、その修正にも役立つという点です。エージェント型パッケージングは、その考え方をサードパーティのパッチ適用で最も時間のかかる部分に応用したものです。
エージェント型のパッケージ化ワークフローでは、AIエージェントがIntuneアプリのパッケージ化における反復的な手順を担います。AIエージェントはインストーラーを読み取り、サイレントインストールとアンインストールのコマンドを割り出し、パッケージを作成し、検出ロジックを生成します。その後、各ビルドはクリーンなマシンでテストされ、何かがIntuneに公開される前に、その結果が管理者に送られてレビューされます。
10月21日にagentic packagingの実例をご覧ください
すでに存在するパッチでも、すべてのデバイスに届くまでにかかる時間次第で、その有用性が決まります。Intuneでサードパーティ製アプリを扱う場合、その時間の多くはパッケージ化に費やされます。
自律型パッケージ化によってリリースごとの反復作業が不要になり、新しいバージョンをキューで滞留させることなく、テストから段階的なロールアウトへ進められます。
Splashtop は10月21日午前8時（PT）／午前11時（ET）に、30分間のウェビナー「From Manual to Agentic Packaging: Simplifying App Deployment with Microsoft Intune」を開催します。Microsoft MVP の Maxime Guillemin と Splashtop の Head of Product である Brandon Shopp が、AI とエージェント型ワークフローによってパッケージ化の工数とエラーをどのように削減できるかを、実際の agentic packaging のデモも交えながらご紹介します。
