# セキュリティパッチとは

ソフトウェアの提供元が、見つかった脆弱性を修正するために配布する更新プログラムです。適用の速さの決め方、停止と検証の負担、誰が適用するかの分担を解説します。

## セキュリティパッチとは

セキュリティパッチは、ソフトウェアの提供元が、出荷後に見つかった脆弱性を修正するために配布する更新プログラムです。脆弱性は、不正アクセスなどに悪用されるおそれのある、ソフトウェアや設定の弱点です。NIST（National Institute of Standards and Technology）の用語集では、パッチは[見つかった問題に対して利用者へすぐに提供する修正](https://csrc.nist.gov/glossary/term/patch)です。実務では、脆弱性の修正を含む新しいバージョンへの更新も、セキュリティパッチの適用として扱います。新しいバージョンに機能の追加が含まれていても、脆弱性を修正するために適用する場合はこの扱いです。

業務で目にする例は、パソコンのWindowsに毎月届く更新、社外から社内に接続するVPN（Virtual Private Network）機器のファームウェアの更新、自社のWebサイトが利用するライブラリの修正版です。ファームウェアは機器に組み込まれた制御用のソフトウェアです。ライブラリは、システムが組み込んで利用する他者が作成したプログラムです。

たとえると、構造に欠陥が見つかった錠前について、メーカーが配布する交換用のシリンダーです。機能の追加だけを目的とする更新とは目的が異なり、設定の変更で悪用を防ぐ回避策とも異なります。

![提供元が配布するセキュリティパッチは脆弱性のある製品を修正し、利用者が設定変更で行う回避策は修正せずに悪用を防ぐことを対比した図。回避策と違い、パッチは脆弱性そのものを修正する](https://media.marketing.kdotdev-tunnel.org/glossary-security-patch-227e28dfcc61a3cc581a98ec6bd61fa51dd883a80d09f9a506b56ce4d35ec58f.png)

## なぜ必要か

ソフトウェアは出荷後にも脆弱性が見つかります。パッチがなければ、利用者は機能の停止などの回避策でしのぐか、製品の利用をやめるかを選ぶことになり、どちらも業務に影響します。

公開された脆弱性は攻撃者にも知られます。ランサムウェアの侵入は、[VPN機器などインターネットに露出した箇所から、未修正の脆弱性、漏えいした認証情報や簡易なパスワード、設定の不備を悪用する手口が多くを占めています](https://www.npa.go.jp/bureau/cyber/countermeasures/ransom.html)。警察庁は、[VPN機器やOSのセキュリティパッチが公開されたら速やかに適用するよう呼びかけています](https://www.npa.go.jp/bureau/cyber/countermeasures/ransom.html)。

公開から悪用までの期間は短いことがあります。JPCERT/CC（JPCERTコーディネーションセンター）が報告した国内の被害事案では、2025年12月に公開されたReactの脆弱性について、[公開の2日後に、他人のサーバーで暗号資産を採掘させるプログラムが設置されました](https://blogs.jpcert.or.jp/ja/2026/02/react2shell.html)。

![この事案では、Reactの脆弱性の公開から2日で悪用され、次の月1回の定期の枠を待つより先に被害が起きたことを、公開からの日数の軸で示す図。定期の枠は最長で約1か月後](https://media.marketing.kdotdev-tunnel.org/glossary-security-patch-a2865231bf543a3e73dff460cb92aa7684e218d0d6b2693c6e0d4073dcd49f40.png)

## 適用の利点と負担

適用の利点は、そのパッチが修正する脆弱性を悪用した侵入を防げることです。同じ更新に含まれる不具合の修正も受けられます。

適用の負担は、次の3つの作業で発生します。

- 停止: 再起動や計画停止が必要になる。NISTは、業務側が[停止の時間と、適用の失敗による追加の停止を懸念する](https://doi.org/10.6028/NIST.SP.800-40r4)と整理している
- 検証: 適用後に業務システムが正常に稼働しないことがあり、一部の機器で先に試すと、その分適用が遅れる。NISTは、[早く適用するほど攻撃の機会は減り、検証不足で停止するリスクは増える](https://doi.org/10.6028/NIST.SP.800-40r4)という対立を指摘している
- 把握: どの機器にどの製品のどのバージョンがあるかの一覧と、提供元の情報を確認する担当が必要になる

![すぐに適用すると攻撃の機会は減り検証不足で止まるリスクは増え、検証してから適用すると攻撃の機会は増え止まるリスクは減ることを示す表](https://media.marketing.kdotdev-tunnel.org/glossary-security-patch-6348c770341c6a910d28cb18dc983c6283247f3384b850c5a120138c9f8a5ee2.png)

先送りにも負担があります。定期の適用を先送りすると、[緊急時に、先送りしていた過去の更新から順に適用する必要が生じ、作業が重く長くなります](https://doi.org/10.6028/NIST.SP.800-40r4)。提供元のサポートが終了した製品には[パッチが提供されません](https://doi.org/10.6028/NIST.SP.800-40r4)。例えばWindows 10は[2025年10月14日にサポートが終了しました](https://learn.microsoft.com/ja-jp/lifecycle/products/windows-10-home-and-pro)。法人が終了後も更新を受けるには、[最長3年の有償の延長サポート（ESU）](https://learn.microsoft.com/en-us/windows/whats-new/extended-security-updates)を契約するか、製品を置き換える必要があり、いずれも費用が発生します。

## 適用の速さの決め方

すべてのパッチを同じ速さで適用する必要はありません。NISTは、パッチの管理を[定期の適用、緊急の適用、緊急の回避策、適用できない資産の4つの状況に分けて計画するよう勧めています](https://doi.org/10.6028/NIST.SP.800-40r4)。これを組織の運用に置き換えた目安は次のとおりです。

| 区分 | 対象 | 目安 |
|---|---|---|
| 緊急の適用 | インターネットから到達できる機器で、悪用が確認されているか、攻撃が自動化できる脆弱性 | 数日以内 |
| 早めの適用 | 緊急の適用に当たらないもののうち、インターネットから到達できる機器の脆弱性、または悪用が確認されている脆弱性 | 数週間以内 |
| 定期の適用 | それ以外の大半のパッチ | 月1回の定期の枠 |
| 緊急の回避策 | パッチがまだ公開されていない脆弱性 | 問題の機能の停止や公開範囲の限定で、公開まで時間を確保する |
| 適用できない機器 | サポートが終了した製品や、停止できない設備 | ネットワークから切り離し、置き換えを計画する |

![適用の速さを分ける判断の流れ。サポートが終了しているか停止できない機器は、切り離して置き換えを計画する。パッチが未公開なら機能停止などで公開を待つ。外部から到達でき、悪用が確認済みか攻撃を自動化できるなら数日以内、到達できてもそうでなければ数週間以内に適用する。到達できない機器は、悪用が確認済みなら数週間以内、そうでなければ月1回の定期の枠で適用する](https://media.marketing.kdotdev-tunnel.org/glossary-security-patch-17b71c65b74af63476e3caaff15bc6c9ce939cbe3c48411c173b869e0440a2fc.png)

緊急の場合でも、NISTは[少数の機器で数分から数時間試した後、数時間から数日のうちに適用する](https://doi.org/10.6028/NIST.SP.800-40r4)流れを示しています。米国の連邦機関には、2026年6月の[指令BOD（Binding Operational Directive）26-04](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk)で、インターネットからの到達可否、悪用が確認された脆弱性の一覧への掲載、攻撃の自動化の可否、乗っ取られる範囲に応じて、[3日、14日、60日などの修正期限](https://certcc.github.io/SSVC/howto/cisa_response/)が義務付けられています。民間の組織が区分の日数を決める際の参考になります。

この区分の表の日数は、従業員数十人から数百人の組織で、担当者が他の業務と兼任して適用する場合を想定した目安です。担当が社内か社外かを問わず、システムを利用する業務の責任者が、パッチ適用のために停止してよい曜日と時間帯と、適用を決める人を先に決めておきます。緊急の適用でも停止の調整が早く済みます。停止できる時間が月に数時間しかない基幹システムでは、月1回の停止の時間帯を年間の業務の予定に先に入れておきます。

Windowsの毎月のセキュリティ更新は[米国時間の毎月第2火曜日に公開され、原則としてそれまでの修正も含む累積的な更新](https://learn.microsoft.com/ja-jp/windows/deployment/update/release-cycle)で、日本時間では水曜日の未明に公開されます。月1回の定期の枠は、この公開日の後に設けると調整しやすくなります。

### 悪用されているかの調べ方

悪用の確認には次の情報源を利用します。

- 米国のCISA（Cybersecurity and Infrastructure Security Agency）が公開する[KEV（Known Exploited Vulnerabilities）カタログ](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
- IPA（独立行政法人情報処理推進機構）の[重要なセキュリティ情報](https://www.ipa.go.jp/security/security-alert/index.html)
- 国内の脆弱性情報を集約した[JVN（Japan Vulnerability Notes）](https://jvn.jp/)
- 製品の提供元のセキュリティ情報

[IPAの重要なセキュリティ情報](https://www.ipa.go.jp/security/security-alert/index.html)では、影響度が高く、悪用した攻撃が行われている問題が緊急に区分されます。CVSS（Common Vulnerability Scoring System）は脆弱性の深刻度を0から10で示す点数です。[規格には悪用の状況や利用環境を反映する指標もあります](https://www.first.org/cvss/v4-0/specification-document)が、脆弱性情報で公表される点数の多くは基本評価で、悪用の状況も自社の機器が外部から到達できるかも反映していません。そのため、公表された点数だけで緊急かどうかを決めません。

## 誰が適用するか

適用の担当は、その製品を誰が管理しているかで変わります。

| 対象 | 適用する人 |
|---|---|
| 自社で管理するパソコン、サーバー、VPN機器 | 自社 |
| クラウドの仮想サーバー | 利用者。[AWSの責任共有モデル](https://aws.amazon.com/jp/compliance/shared-responsibility-model/)では、仮想サーバーのOSの更新とセキュリティパッチは利用者の責任 |
| クラウドのマネージドサービス | 提供元がOSを更新する。利用者は提供元が示す更新の時間帯と、データベースのバージョンの更新を管理する |
| SaaS（Software as a Service） | 提供元。利用者に残るのは、アカウント、設定、データ、利用者の端末に入れる連携用のソフトウェアの管理 |
| 自社で開発したシステム | 開発と保守の担当者。ライブラリの修正版を取り込み、テストして再リリースする |

![自社の機器、仮想サーバー、マネージドサービス、SaaSごとに、自社のアプリ、データベースの版更新、OS、機器・基盤、端末の連携ソフトのうち自社が担う範囲を塗った表。自社の機器はすべて、仮想サーバーはOSから上を自社が担う。マネージドサービスで自社が担うのは自社のアプリとデータベースの版更新で、SaaSで自社が担うのは端末の連携ソフトだけ](https://media.marketing.kdotdev-tunnel.org/glossary-security-patch-82856b33b5e94856be9866356cceecad990681f5a98e747bdbae2ed261ca8251.png)

自社で開発したシステムは、OSの自動更新では対応できず、最も工数がかかりやすい対象です。ライブラリの修正が新しい大きなバージョンにしか提供されないと、書き方の変わった部分の改修とテストが必要になり、利用箇所の数とテストの範囲によっては、経験上、数日から数週間の作業になることがあります。日頃からライブラリを新しいバージョンに追従させておくと、緊急時の改修が小さく済みます。[GitHubのDependabot](https://docs.github.com/en/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates)のように、脆弱なライブラリを検知して更新を提案する仕組みも使えます。

## よくある誤解

### 自動更新にしておけばすべてのパッチが適用される

OSの自動更新の対象はOSと一部のアプリケーションです。VPN機器やルーターのファームウェア、業務システムが利用するライブラリは、多くの場合対象外です。CISAは、[可能な範囲で自動更新を有効にし、機器とアプリケーションの一覧を最新に保つよう勧めています](https://www.cisa.gov/secure-our-world/update-business-software)。

### パッチを適用すれば侵入の心配はない

パッチは今後の悪用を防ぎますが、適用前に侵入されていた場合の被害は解消しません。JPCERT/CCは、悪用が確認されている脆弱性では、[パッチの適用と合わせて侵害の有無を確認するよう求めています](https://blogs.jpcert.or.jp/ja/2026/02/react2shell.html)。漏えいした認証情報や設定の不備など、パッチでは塞げない侵入の手口もあります。

### 正常に稼働しているシステムには手を付けないほうが安全

適用を見送ると、公開済みの脆弱性が残り続けます。サポートが終了した製品では修正自体が提供されず、残る手段は隔離か置き換えになります。

担当者は悪用の情報を週に1回確認し、インターネットから到達できる機器のパッチを区分の表に沿って先に適用します。それ以外を月1回の定期の枠に集めると、緊急でない更新のために停止を調整する回数を月1回に抑えられます。