製造業のOTセキュリティ対策が進まない理由は、技術不足より「予算と責任が IT と工場で分かれていること」にある——。産業セキュリティ専門メディア Industrial Cyber が2026年10月27日に公開した特集は、こうした現場の構図を専門家4人への取材から描いています。この記事では、特集の事実を整理したうえで、IT と OT の責任分断は「誰が設備を止めてよいと言えるか」という権限と責任境界の設計の問題であり、工場向けのシステムを作る側は要件定義と保守契約の段階でそれを決めに行くべきだという論点を、システムを作る側の立場から論じます。
要点 (事実のみ)
- 特集は、製造業のセキュリティ施策が停滞する主因を、政策より説明責任・予算・責任の所在が部門間で分散していることに置いている。複数拠点の企業では、ある工場は堅牢でも、別の工場は管理されていないリモートアクセスを抱えていることがある。予算は本社で承認されても現場への反映は遅く、投資サイクルが生産スケジュールと合わないことが多い。
- 記事が引用する SANS の2025年 ICS/OT 予算調査では、ICS/OT のセキュリティ予算を IT と OT で分担する組織が37%、IT が管理が31%、OT が管理が26%。予算判断を CISO/CSO が主導するのは27%。セキュリティ予算の75%超を ICS/OT に配分する組織は9%で、41%は0〜25%にとどまる。
- Sun Square の ShangJyh 'SZ' Lin 氏は、Windows XP の PC がネットワークにつながったまま稼働していた工場の例を挙げた。OT 側はそれを IT 機器とみなし、IT 側は Active Directory の外にあるとして管理対象外にしていた。同氏は「明確な所有者とライフサイクルの予算がなければ、セキュリティ作業は生産や保守に優先順位を奪われる」と述べている。
- Axiom の Edward Liebig 氏は、IT は危険を認識していても機器への権限がなく、OT は機器を持つが資金を別の用途に充てていると指摘し、作業は「停止時期か、新しい予算か、インシデントを待つ」と述べた。Infrashield の Elizabeth McAndrew-Benavides 氏は「工場の OT は長く本社 IT と予算を争い、たいてい工場が負けてきた」と語った。
- 提言として、Lin 氏は本社が最低限の要件とリスク受容の権限を定め、現場がサプライヤーのアクセスやネットワーク変更を担う「中央統制・現場実行」型を挙げた。Liebig 氏はリスクを生産・安全・環境・財務上の結果として示し、リスクオーナーを明確にして、一定以上の遅延は事業責任者にエスカレーションすることを求めた。RunSafe Security の Joe Saunders 氏は、止められないシステムにはパッチに頼らない防御が必要だと述べている。
徐 聖博の見解
止まっているのは技術ではなく「承認」だ
この特集を読んで私が一番引っかかったのは、Windows XP の PC の話です。OT は「IT 機器だ」と言い、IT は「AD の外だから管轄外だ」と言う。どちらも間違ったことは言っていません。ただ、その機器を更新する、あるいは止める判断を誰がしてよいのかが、組織のどこにも書かれていない。結果として、危険は全員に見えているのに、誰も手を付けない状態が続きます。
私は会社組織も一つのシステムだと考えています。システムとして見ると、この状態は「どのロールにも割り当てられていないリソース」があるのと同じです。ソフトウェアなら、所有者のいないリソースや、承認者が定義されていない操作はすぐに設計の欠陥として扱われます。ところが工場の機器やリモート接続になると、同じ欠陥が「部門間の調整課題」という柔らかい言葉で先送りされてしまう。Liebig 氏の「リスクは理解されていた。リスクを閉じる責任の所在が決まるのに時間がかかった」という言葉は、まさにこの構図を指していると私は読みました。
SANS の数字も、この読み方を裏づけています。予算を IT と OT で「分担」している組織が37%と最も多い。分担そのものは悪くありません。問題は、分担した結果、設備を止めて更新するという一番重い決定の承認者が、どちらの予算表にも載っていないことです。DX でも同じで、誰が承認し、誰に権限があり、誰が責任を持つかが決まっていなければ、どのツールを入れても業務は回りません。セキュリティ製品を足す前に、承認と責任の線を引く必要があります。
「中央統制・現場実行」は、そのまま権限設計の言葉に置き換えられる
Lin 氏の提言は、システム設計の言葉に直すと分かりやすくなります。本社は「最低限の要件」と「リスク受容の権限」を持つ。工場は「サプライヤーのアクセス」と「ネットワーク変更」の実行権限を持つ。これは、ポリシーを決めるロールと、変更を実行するロールを分け、例外（リスク受容）を誰が承認するかを明示する、という権限設計そのものです。Liebig 氏の「一定以上の遅延は事業責任者にエスカレーションする」も、承認ワークフローにタイムアウトと上位承認者を設定する話だと言えます。
ここまで言語化できれば、紙やスプレッドシートでも運用できます。逆に、ここが決まらないまま資産管理ツールやリモートアクセス製品を入れても、台帳に「所有者: 未定」の行が増えるだけだと私は考えています。
開発会社にとっての意味——工場向け案件では「誰が止めてよいか」を要件に入れる
工場とつながるシステム（生産管理、設備データの収集、保守用のリモート接続など）を作る側として、私はこの特集から次の3点を受け取りました。
- 要件定義で、機器と接続ごとの所有者と承認者を決めに行く。 機能要件と一緒に、「この機器・この接続の所有部門はどこか」「更新や停止を承認するのは誰か」「例外を受け入れる権限は誰にあるか」を一覧にして合意する。発注側の IT 部門と工場の両方が同席しないと決まらない項目なので、最初のヒアリングの段取りから変える必要があります。これを決めずに作ると、納品後に「この接続は誰の管理か」で止まります。
- 見積りに、ライフサイクルの費用を分けて書く。 Lin 氏が言う「ライフサイクルの予算」が無いと、作った仕組みは更新されずに古くなります。初期構築とは別に、OS やミドルウェアの更新、接続経路の棚卸しを何年ごとに誰の費用で行うかを見積りの段階で示しておけば、発注側の本社と工場のどちらの予算に載せるかを、契約前に議論してもらえます。
- 委託先のリモートアクセスは、自社が「所有者」になれる範囲を契約で明示する。 保守用の接続を作る側は、その経路の一部を事実上管理する立場になります。どこまでを自社が管理し、どこからが顧客の責任か、接続を開ける承認は誰が出すのかを保守契約に書いておく。曖昧なまま運用すると、特集が指摘する「管理されていないリモートアクセス」を、開発会社自身が作ってしまうことになります。
Saunders 氏の「止められないシステムはパッチだけでは守れない」という指摘も、作る側には重い話です。止められない前提の設備とつなぐのであれば、つなぐ側のソフトウェアを最小権限で設計し、接続を切っても工場側が動き続けるように作ることが、私たちが担える防御だと考えています。テスト、セキュリティ、認証・認可を開発速度の犠牲にしないという私の方針は、工場とつながるシステムでこそ問われます。
この話が開発会社の受注に効く理由
IT と OT の間に責任の空白がある組織では、どちらの部門も単独では発注を決めにくくなります。逆に言えば、空白を埋めるための権限と承認の整理まで提案に含められる開発会社は、本社 IT と工場の両方と話ができる相手として選ばれやすくなるはずです。機能の実装力だけで比べられる案件より、こちらの方が価格競争に巻き込まれにくい、というのが私の見立てです（市場全体のデータで確かめた話ではなく、私の推測です）。
工場とつながる機器や接続をどう管理するかは、過去にも別の事例から論じています。
- 冷蔵設備へのサイバー攻撃｜仏スーパー数百店の食品廃棄から読む、更新が止まった接続機器を誰が管理するか
- 製造業のランサムウェア対策｜Fairlifeの生産停止から読む、IT/OT分離は「切り離した後に何が動くか」の設計
- 政府のサイバー緊急対策パッケージ、企業は何を準備すべきか——「初動から復旧まで」を担うのは開発・保守の委託先だ
まとめ
Industrial Cyber の特集が示したのは、製造業の OT セキュリティが止まる原因が、技術より予算と責任の分断にあるということでした。私はこれを、機器と接続ごとに所有者と承認者が定義されていない「権限設計の欠陥」として扱うべきだと考えています。発注側はセキュリティ製品を選ぶ前に「誰が止めてよいか」を決め、工場とつながるシステムを作る側は、それを要件定義・見積り・保守契約に組み込んでおく。そこまでやって初めて、対策が先送りされない仕組みになると考えています。
