パッチの津波とメンテナンス窓が衝突するとき

2026年4月、ソフトウェアの欠陥を発見する速度と、それを修正する速度のバランスが崩れました。AnthropicやOpenAIが公開したフロンティアAIモデルは、いまや本番環境のソフトウェアに存在する悪用可能な脆弱性を自律的に特定できるようになっています。かつて熟練の人間の研究者がおよそ60日かけていた作業が、いまや約4時間で済むようになったのです。Melissa Hathaway氏が最近発表したCyber Defense Reviewの論考でもこの点が詳しく記されています。同論文によれば、最大手のソフトウェア・ハードウェアベンダーのうち少なくとも40社がすでにこうしたモデルを利用しており、Anthropicの「Mythos」は広く使われているOSやブラウザの99パーセントで重大な欠陥を検出したと報じられています。

Hathaway氏の結論は率直です。「早く実装して後で直す」というやり方によって積み上がった40年分の技術的負債が、いよいよ精算の時を迎えているというのです。業界は今後10年ではなく、今後12カ月から24カ月の間にパッチの津波に見舞われることを覚悟すべきだと同氏は指摘しており、その見立ては正しいと言えるでしょう。ところが、この論考が引き起こした議論は、開示期限、パッチ適用の頻度、対応が遅れたベンダーの責任といった、ほぼIT側の論点だけで進められています。

しかし、こうしたパッチはすべて、最終的には物理的な現場のどこかに届きます。変電所であり、充填ラインであり、浄水処理施設であり、病院の一区画です。7月に発生したミネソタ州の水道事業者を狙ったPLC侵入事件は、その到達の様子を先取りして示したものでした。そして、まさにそこで津波はある構造とぶつかります。開示をめぐる議論がその存在を忘れがちな構造、すなわち「メンテナンス窓」です。

脆弱性を発見することと、それを修正することは、そもそも同じ作業ではありませんでした。AIは前者を一気に圧縮した一方で、後者にはまったく手をつけていません。エンタープライズITの世界では、Hathaway氏が引き合いに出す修正対応の慣例、すなわち積極的に悪用されている重大な欠陥には7日、深刻度の高いものには30日というルールは、野心的ではあるものの十分に達成可能です。サーバーを再起動し、うまくいかなければロールバックすればよく、誰かに謝る必要もありません。

ところが運用技術(OT)の世界では、この慣例は構造的に成り立ちません。可用性と安全性は機密性より優先され、継続的なプロセスはCVEが公表されたからといって止まるわけではなく、次に予定されているメンテナンス窓は四半期ごとの定期停止かもしれませんし、18カ月前から計画されていた年次停止かもしれません。このギャップは文化の違いによるものではなく、物理的、経済的、そして契約上の制約によるものです。

その一方で、攻撃側も防御側と同じ恩恵、すなわち処理速度の加速を享受しています。脆弱性を発見できるモデルは、開示からわずか数時間で実際に機能する攻撃経路を組み立てられるようになっており、この能力は特定の陣営に限られたものではありません。Hathaway氏は、中国の360 Digital Security Groupが持つAI発見エージェントが、これまでに未知だった脆弱性を1000件近く発見済みだと指摘しています。地理的な安全地帯も業種による安全地帯も存在しません。そして、長期間稼働し続け、めったにパッチが適用されない資産を抱えるOTネットワークこそ、まさに「未対応期間」が蓄積していく場所なのです。発見はいまやマシンの速度で進みますが、OTにおける修正は依然としてプラントの速度でしか進みません。以下で述べることはすべて、この両者の間で広がり続けるギャップをいかに管理するかという話です。

なぜOTは単純にパッチ適用を高速化できないのか

標準的な助言がなぜ通用しないのか、その理由を正確に理解しておくことは重要です。というのも、どの理由も現場の怠慢によるものではないからです。コントローラーを再起動させるパッチは、稼働中のプロセスを停止させてしまう可能性があります。安全計装システム上、あるいはその近辺では、検証されていない変更はそれ自体がリスクの緩和策どころか、むしろ危険要因になります。ほとんどの産業用コンポーネントは、OEMが該当製品ラインに対して検証済みのファームウェアとパッチでしか更新できません。未承認の更新を適用すれば、保証やサポート契約、認証が無効になる恐れがあります。この検証作業には数週間から数カ月かかり、しかもその時計が動き始めるのは、ベンダーが上流の修正を処理し終えてからです。さらに、運用側は適用の窓を見つけなければなりません。多くのプラントは、計画済みの定期停止以外のタイミングで操業を止めることができず、それを強行すれば7桁規模の損失や、実際の安全上のリスクにつながりかねません。

そして、こうした事情のすべての下に、レガシー層という土台が横たわっています。Hathaway氏は、製造業と医療業界を名指しして、サポート終了製品を稼働させ続けているセクターだと指摘していますが、筆者が監査を行うプラントでも見慣れた光景です。サポートが数年前に終了したOS上で動くエンジニアリングワークステーション、更新機構がまったく存在しない世代のPLC。こうした資産にとって「もっと速くパッチを当てろ」というのは助言として成立しません。置き換えは複数年単位の時間軸を持つ資本プロジェクトであり、同氏が挙げるY2Kとの比較はまさに的確です。ITにおいてパッチとは修正そのものですが、OTにおいてパッチとはプロジェクトなのです。

スキャナーではなく運用者としてトリアージする

今後押し寄せる量の最初の犠牲になるのは、CVSSスコアで並べ替えただけの作業リストでしょう。AI支援による脆弱性開示によって、四半期ごとに何百もの関連アドバイザリが導入済み資産に降りかかるようになれば、「重大なものから優先」というやり方は、もはや並べ替えの基準として機能しなくなります。あまりに多くのものが「重大」に分類されてしまうからです。業界全体も同じ結論に至りつつあります。Rapid7は8月に、開示件数と悪用速度の急増によって従来のパッチサイクルはすでに破綻しており、防御側は露出度ベースの優先順位付けへと移行せざるを得ないと警告しました。筆者が運用担当者に説明しているトリアージの論理は、代わりに次の3つの問いに基づいています。悪用の証拠はあるか(KEVへの掲載、上昇するEPSSスコア、実際の悪用に言及したOEMのアドバイザリなど)。その資産は実際に外部からアクセス可能な状態にあるか(ITネットワークやインターネットから到達可能なのか、それとも強制された導管の奥、3階層のゾーンの奥深くに埋もれているのか)。そして、その資産に不具合が起きた場合、プロセスと安全性にどのような影響が及ぶのか、という結果の重大性です。

IEC 62443は、こうした問いへの対応方法をすでに体系的な用語として提供しています。露出度を定義するためのゾーンと導管、そして必要な期限内にパッチ適用が現実的でない場合の代替的な対策、すなわちセグメンテーション、許可リスト方式、ネットワーク境界での仮想パッチ適用、不要な到達可能性の除去、特定の欠陥を狙った悪用の試みに対する監視強化などです(TR 62443-2-3では産業環境におけるパッチ管理について詳しく取り上げられています)。公式のドクトリンもいまや同じ方向を向いています。7月下旬、ASD主導の連合体がCISA、FBI、NCSC-UK、CCCSとともにCI Fortifyを公表しました。これは重要なOTシステムを隔離し、長期間切り離した状態で運用するための共同ガイダンスであり、封じ込めを単なる代替策から、設計に組み込まれた能力へと格上げするものです。したがって、OT資産の大部分にとって、誠実で監査可能な立場は「SLA内でパッチ適用済み」ではなく、「この資産についてはこの時間軸でパッチを適用しない。代わりに封じ込めを行う。代替的な統制策はこれ、監視体制はこれ、そして廃止予定日はこれ」というものになるはずです。NIS2の下では、リスク対策について経営陣が個人として責任を負うことになるため、文書化された封じ込めの判断は、黙って見過ごされたパッチSLA違反よりもはるかに説得力を持って組織を守ってくれます。

急増を「停止イベント」として計画する

Hathaway氏は各国政府に対し、パッチの発生量を自国のリスク露出と照らし合わせて把握し、急増に備えた対応力を準備するよう求めています。運用事業者も、一段下の現場レベルで同じ演習を行うべきであり、特に重要なのは次の4つの取り組みです。第一に、いま自社が利用しているOEMやシステムインテグレーターに問いただすことです。AIが発見した検出結果をどのように取り込んでいるのか、自社の導入資産に対してどの程度のパッチ発生量と頻度を見込んでいるのか、そして検証にかかる期間はどれくらいなのか。4月に公表されたCSA、SANS、OWASPによる共同ガイダンス、「Mythos対応」のセキュリティプログラム構築に関するものは、まさにこうした対話のための実用的なチェックリストになります。欧州ではここにさらに強い後押しが加わります。9月11日、サイバーレジリエンス法の最初の強制義務が発効し、製造業者はENISAの新しい単一報告プラットフォームを通じて、積極的に悪用されている脆弱性を報告しなければならなくなります。24時間以内の早期警告と、72時間以内のより詳細な通知が求められ、この義務は新製品だけでなく、すでに市場に出ている製品にも適用されます。つまり、上流からの情報伝達がこれまでより早まるということです。ベンダーに対して、こうしたアドバイザリやそれに付随するSBOMデータが、運用事業者である自社にどのように届けられるのかを、書面で確認しておく必要があります。

第二に、緊急のメンテナンス窓について、必要になる前に運用部門とあらかじめ交渉しておくことです。どのような脆弱性であれば計画外のダウンタイムを正当化できるのか、その基準を文書化しておく必要があります。これは他の安全に関する判断と同様、深夜2時に場当たり的に決めるのではなく、明るいうちに合意しておくべき意思決定の枠組みです。第三に、実際に迫っている事態を想定した演習を行うことです。単発のインシデントではなく、複数のベンダーから深刻度の高いアドバイザリが同時に押し寄せる1週間というシナリオです。Hathaway氏はこうした演習を国家レベルで実施するよう推奨していますが、自動化エンジニアの数が限られているプラントレベルでこそ、その価値はさらに大きくなります。第四に、パッチを適用できないすべての資産に対して、廃止予定日と予算枠を設定することです。代替的な統制策はあくまで橋渡しであり、最終的な着地点ではありません。恒久的な例外事項が静かに積み重なっていく資産台帳は、コンプライアンスという衣をまとった技術的負債にほかなりません。

開示期限、政府の利害調整、ベンダーの責任といった政策上の論点は、ワシントンやブリュッセルで決着することになるでしょう。しかし、その結果がどうであれ、運用事業者はその成果と向き合い続けなければなりません。脆弱性の発見は不可逆的に高速化しており、開示のパイプラインは産業化が進んでいます。AI研究機関自身が、協調的開示について固定されたタイムラインを約束し始めているほどです。いまや運用事業者の手に残された変数は、修正対応という仕組みの準備状況、ただ一つだけです。OTにおいて、その仕組みを支えるのはスクリプトではなく、変更管理そのものです。脆弱性の開示から悪用までの間にある窓は、かつてはベンダーの問題であり、研究者の問題であり、政策立案者の問題でした。しかし今年からは、それは運用の問題です。そのように扱うべき時が来ています。