SAPの脆弱性は「情シス」だけでは防げない｜工場とERPのつなぎ目に空いた穴【世界のDX潮流】

「基幹システムのセキュリティ対応は、情報システム部門の仕事」

そう考えている経営者や現場責任者は少なくないでしょう。しかし、スマートファクトリー化が進み、工場の生産設備とERPがつながるようになった今、その前提そのものが崩れつつあります。

2026年8月、独ソフトウェア大手SAPが定例のセキュリティパッチデーで、工場とERPをつなぐ「接続層」に重大な脆弱性を公開しました。この記事では、その内容と、なぜ情報システム部門だけでは対応が完結しないのかを読み解きます。読み終えたとき、貴社のセキュリティ対応体制を見直す視点が得られるはずです。

SAPが公開した28件のセキュリティノート、工場に集中する脆弱性

2026年8月12日、SAPは定例の月次セキュリティパッチデーで、28件の新規セキュリティノートを公開しました。うち12件が緊急または高優先度に分類されています。

今回とくに目を引くのが、工場の生産設備とSAP ERP・S/4HANAをつなぐ「Manufacturing Integration and Intelligence（MII）」に関連する脆弱性です。28件のうち6件がMIIに集中しており、内訳は重大2件・高3件・中1件。とりわけCVE-2026-44772はCVSS9.9、CVE-2026-44758はCVSS9.1という、いずれも最高水準に近いコードインジェクションの脆弱性でした。

MIIとは何か、なぜ工場の脆弱性がERPの問題になるのか

MIIは、工場の生産設備・機器とSAP ERPおよびS/4HANAを連携させる、いわば工場と基幹システムの「つなぎ目」です。生産ラインの稼働状況や品質データをリアルタイムで基幹システムへ取り込み、逆に生産計画や指示を現場設備へ伝える役割を担っています。

このMIIが攻撃を受けた場合の影響は、単なるITシステムの被害にとどまりません。ERP Today誌は「製造アプリケーションセキュリティは今やSAPの最前線の懸念事項」と指摘しており、攻撃が工場の稼働そのものに波及しうる構造であることを示しています。基幹システムの脆弱性というと情報システム部門の管轄というイメージが強いですが、MIIのような接続層は、工場の生産現場にも直接影響する点が特徴的です。

出典・参照：

• SAP August Patch Day Raises the Stakes for Manufacturing Security Teams｜ERP Today

対応は「パッチを当てて終わり」ではない

さらに厄介なのは、今回の脆弱性への対応が、単純なパッチ適用では完結しない点です。SAPが示す対応策には、セキュアトランスフォーマーや許可ホスト制御の導入、脆弱な機能そのものの削除など、システムの設定変更をともなうものが含まれています。

こうした設定変更は、情報システム部門だけの判断で完結するとは限りません。生産設備の稼働に関わる設定であれば、生産技術・工場部門との調整が必要になる場面も出てくるでしょう。つまり今回のケースは、脆弱性対応の担当範囲そのものを問い直す事例だといえます。

OT（現場）とIT（基幹）の接続層は、誰が守るのか

日本の製造業でも、スマートファクトリー化やOT/IT統合を進める企業は増えています。工場の設備をネットワークやクラウドにつなげば、それだけ利便性は高まりますが、同時にセキュリティ上の管轄も複雑になります。

今回のSAPの事例が示すのは、情報システム部門と生産技術・工場部門という、これまで別々に動いてきた組織の接続点そのものが、新しいセキュリティの盲点になりうるという構造です。パッチを当てる担当が情報システム部門なのか、設定変更の影響を受ける現場設備の担当が誰なのか、そうした役割分担があらかじめ整理されていなければ、対応そのものが宙に浮いてしまいかねません。

責任分担をどう設計する：パッチ適用のGOサインと停止の権限

この事例が実際に問いかけているのは、抽象的な「連携不足」の話ではなく、もっと具体的な設計上の論点です。

パッチ適用のGOサインと、影響を受ける主体のズレ

まず、パッチ適用そのものの適否を判断する主体と、その判断によって生じる影響を負う主体が、今回のケースでは一致しません。パッチ適用のGOサインを出す判断は、脆弱性の深刻度（CVSS）や攻撃の実現可能性を評価できる情報システム部門・セキュリティ部門が中心となるでしょう。

しかし、その適用が生産設備の設定変更や機能停止をともなうのであれば、影響を受けるのは工場の生産技術部門です。判断の主体と影響の受け手が分かれている以上、情報システム部門が「技術的に正しい」と判断しても、それだけでは実行に移せない場面が出てくるはずです。

ライン停止の判断は、経営層の権限にならざるを得ない

さらに重いのが、生産ラインを一時的に止めるかどうかの判断です。脆弱性対応のために稼働中のラインを止めれば、稼働率や納期、取引先への影響という事業インパクトが生じます。これは情報システム部門はもとより、生産技術部門の裁量だけでも完結しない性質の判断であり、実質的に経営層が最終的な権限を持たざるを得ない領域だといえるのではないでしょうか。パッチ適用のGOサインと、ライン停止の可否は、似ているようで求められる権限の重さがまったく異なる判断です。

ベンダーの位置づけと、四者が関わる承認フローの設計

ベンダーであるSAPの位置づけも、整理しておく必要がありそうです。SAPが提供できるのは脆弱性情報とパッチ、推奨される設定変更の内容までであり、それを「いつ」「どの範囲で」適用するかという判断の主体にはなり得ません。ベンダーを情報提供者、社内の各部門を判断主体として切り分けておかなければ、対応の遅れの責任の所在があいまいになってしまう懸念もあります。

こうして分解していくと、今回のようなOT/IT接続層のセキュリティ対応には、工場・生産技術部門、情報システム部門、経営層、ベンダーという少なくとも四者が関わる承認フローの設計が必要になってくることが見えてきます。誰が起案し、誰が技術面のリスクを評価し、誰が現場への影響を確認し、誰が最終承認を行うのか。この一連の流れがあらかじめ設計されていなければ、緊急度の高い脆弱性であるほど、判断が宙に浮いたまま時間だけが過ぎていくことになりかねません。

OT/ITの境界を「共同管轄領域」として扱う

OTとITの境界管理という観点で見れば、今回のMIIのような接続層は、どちらか一方の管轄と割り切れない「共同管轄領域」として扱う設計が必要になってくるのではないでしょうか。境界線をどちらかの部門に一方的に引き取らせるのではなく、境界そのものを共同で管理する仕組みをどう作るかという論点が、この事例の先にあるように思われます。

まとめ：脆弱性対応は、情報システム部門だけの仕事ではなくなっている

SAPが2026年8月のパッチデーで公開した脆弱性は、工場とERPをつなぐMIIという接続層に集中していました。対応にはパッチ適用にとどまらない設定変更が必要であり、情報システム部門単独では完結しない場面が出てきます。

貴社の基幹システムと現場設備の接続点は、いま誰が責任を持って守っているでしょうか。情報システム部門と生産技術・工場部門の役割分担、そしてパッチ適用や停止の判断を誰の権限とするかを、一度見直してみる価値がありそうです。