工場やプラントの制御システムは、長らく外部のネットワークや共用のシステムと接続されない前提で稼働し、セキュリティの脅威が問題視されてきませんでした¹。ところが近年は、Windowsやパソコン向けの汎用のプラットフォームが制御システムに活用されるようになっています²。積み上げてきたネットワークやインフラの経験、組み込みやシステム設計の知見は、この変化のただ中にある制御システムの防御に生きる場面が増えています。本記事では、資産ベースと事業被害ベースのリスク分析、攻撃シナリオや攻撃ツリーによる脅威モデリングを地図に、エンジニアがリモートでどう関われるかを整理します。

1. なぜいまOT・制御システムセキュリティの案件が増えているのか

外部と切り離されていた制御システムが、つながり始めている

工場のラインやプラントの制御装置は、長らく専用の機器と閉じたネットワークで組み立てられてきました。外部のネットワークや共用のシステムと接続されない前提で稼働してきたため、情報システムのようなセキュリティの脅威は、正面から問題視されることが少ない領域でした¹。ところが近年は状況が変わり、Windowsやパソコン向けの汎用のプラットフォームが制御システムの現場でも活用されるようになっています²。閉じていたはずの現場に、見慣れた技術が入り込んできたということです。

汎用化と外部接続が、攻撃の入り口を広げる

汎用化は、単なる操作性や保守性の向上ではありません。むしろ、情報システム側で知られている脆弱性や攻撃の手口が、そのまま持ち込まれる入り口でもあります。外部のネットワークとの接続が増えれば、遠隔から機器の状態を確認できる利便性と引き換えに、攻撃者にとっての経路も増えます。閉域だから安全という前提そのものが崩れているところに、ネットワークやインフラの設計を担ってきたエンジニアの経験を、制御システム側の防御に転用する余地が生まれています。境界の通信を可視化する設計、外部と内部を分けるセグメンテーションの考え方、遠隔からの接続を安全に保つ設計は、情報システム側で積み上げてきた知見とそのまま重なる部分です。専用の知識をゼロから積み上げるより、境界設計や通信制御で培った視点を持ち込むほうが、現場では早く合流できます。次に見ていくのは、制御システムのセキュリティが情報システムとどう性格が異なるかという点です。

図の作成：Remogu編集部。情報処理推進機構の資料をもとに、制御システムを取り巻く変化を整理したもので、統計データではありません

2. 制御システムセキュリティの特徴（可用性優先・長期利用）

情報システムとは優先順位が逆になる

情報システムのセキュリティは、機密性を最優先に、完全性、可用性の順で語られることが一般的です。ところが制御システムでは、この並びが逆になり、可用性、完全性、機密性の順でセキュリティ要件が重視されます³。機密性を守ることより、止めないことを優先する発想です。工場のラインやプラントが止まれば、情報漏えいよりも生産や安全そのものに影響が及ぶためです。同じ「セキュリティ」という言葉を使っていても、守る対象の並び順が違うと理解しておくことが、最初の一歩になります。この優先順位の違いは、日々の設計判断にも表れます。情報システムであれば当然とされる即時のパッチ適用や再起動を伴う対応も、制御システムでは稼働への影響を確認したうえで、計画的なタイミングを選んで進める形になります。

情報システムと制御システムのセキュリティ要件の違い

次の表は、情報システムと制御システムで、何を優先し、どう運用するかの違いを整理したものです。情報システムでは機密性を軸に据え、更新やパッチも比較的短い周期で適用します。一方の制御システムは、24時間365日の可用性が最も重要な要件として挙げられており⁴、一度組み上げた構成を長期間使い続ける傾向があります。パッチの適用も、稼働を止めない範囲で計画的に進める運用になります。この違いを知っているかどうかで、案件に入ったときの提案の説得力が変わってきます。

観点	情報システム（IT）	制御システム（OT）
優先されるセキュリティ要件	機密性を最優先	可用性を最優先
システムの入れ替え	比較的短い周期で更新	長期間同じ構成を使い続ける傾向
停止した場合の影響	情報漏えいや業務停止	生産の停止や安全上のリスクに直結
パッチ適用のタイミング	随時適用	稼働を止めない範囲で計画的に適用

長期利用の前提が、設計にもたらす制約

制御システムは一度導入すると長期間にわたって使い続けられ、機器の入れ替えも情報システムほど頻繁ではありません。稼働を止められない現場だからこそ、脆弱性が見つかっても即座に更新するという選択肢を取りにくく、境界での防御や監視で補う設計が重視されます。通信を許可する範囲をあらかじめ絞り込んでおく、異常な通信を検知する仕組みを境界に置いておくといった、稼働を止めずに補える対策が中心になります。変更を加える際も、休止できる時間帯や保守の周期に合わせて計画を立てる必要があり、情報システムのような柔軟な更新サイクルは前提にしにくくなります。可用性を最優先に据えたうえで、完全性と機密性をどう積み増すか。この順番を踏まえた設計ができるかどうかが、案件で求められる視点の核になります。この特徴を踏まえたうえで、実際にどうリスクを洗い出していくかを見ていきます。

出典：情報処理推進機構「制御システムのセキュリティリスク分析ガイド 第2版」をもとに作成

3. 資産ベースと事業被害ベースのリスク分析（2つの手順）

資産を起点に洗い出す「資産ベース」

制御システムのリスク分析には、資産ベースと事業被害ベースという2つの手順が示されています⁵。資産ベースの分析は、制御システムを構成する機器やネットワークといった資産を一つひとつ洗い出すところから始まります。資産ごとに想定される脅威を当てはめ、対策を検討していく進め方で、抜け漏れなく網羅する場面に向いています。機器の種類やネットワークの構成ごとに整理していくため、対象となる制御システムの全体像を関係者と共有しやすいという利点もあります。

被害を起点に逆算する「事業被害ベース」

事業被害ベースの分析は逆の順序で進みます。生産の停止や安全上の事故といった、事業が受ける被害を先に想定し、そこに至る攻撃のルートを逆算していきます。網羅性を積み上げる資産ベースに対して、事業被害ベースは重大性から絞り込む進め方です。どの資産が狙われても最終的にどの被害へつながるのかを先に描いておくことで、限られた予算や工数をどこに割り当てるかの判断がしやすくなります。経営層に被害の重大性を伝えたいときや、優先して手当てしたい経路を絞り込みたいときに向いています。

資産ベースと事業被害ベースの比較

2つの手順は、どちらか一方だけで十分というものではなく、目的に応じて使い分けたり、組み合わせたりするものです。次の表は、出発点と得られるもの、向いている場面の違いを整理しています。資産ベースは対策の網羅性を確認したい場面に、事業被害ベースは被害の重大性を関係者に説明したい場面に、それぞれ向いています。案件では、どちらの視点から依頼されているかを見極めることが最初の作業になります。

観点	資産ベースのリスク分析	事業被害ベースのリスク分析
出発点	制御システムを構成する資産（機器・ネットワーク）	想定される事業被害（生産停止・安全上の事故など）
得られるもの	資産ごとの脅威と対策の一覧	被害に至る攻撃ルートの全体像
向いている場面	対策の網羅性を確認したいとき	被害の重大性を関係者に説明したいとき

資産ベースと事業被害ベースを行き来しながら分析を進めることで、対策の抜け漏れと被害の重大性の両方を押さえられます。ここからは、事業被害ベースの分析を具体的な脅威モデリングへと落とし込む工程を見ていきます。

図の作成：Remogu編集部。情報処理推進機構の資料が示す手順を整理したもので、統計データではありません

4. 攻撃シナリオ・攻撃ツリーで脅威を洗い出す（脅威モデリング）

攻撃シナリオで、具体的な筋書きに落とし込む

事業被害ベースで想定した被害は、そのままでは対策に結びつきません。どんな経路をたどって被害に至るのか、具体的な筋書きに落とし込む作業が攻撃シナリオの組み立てです。侵入口から狙われる資産、そこから引き起こされる被害まで、一つの物語として整理することで、どこに防御を厚くするかが見えてきます。抽象的な「脅威がある」という状態から、「どこから、何を経由して、何が起きるか」という具体的な筋書きに落とすことが、この工程の狙いです。この整理には、IT側とOT側それぞれの担当者が持つ情報を突き合わせる作業も欠かせません。境界にある機器の設定や通信の記録を確認しながら、双方の認識をすり合わせていく進め方になります。

攻撃ツリーで、ルートの数だけ脅威を可視化する

被害に至る経路は、ひとつとは限りません。事業被害ベースの分析では、最終的な攻撃に至るルートの個数が、そのまま攻撃ツリーの数になります⁶。ルートを枝分かれさせて描くことで、見落としていた侵入口や、複数の経路が交わる急所を洗い出せます。攻撃の手口を実践することより、守る側の抜けを見つけることに主眼があります。資産ベース・事業被害ベースの分析結果と攻撃シナリオ・攻撃ツリーを地図として持てるかどうかが、案件でどこまで踏み込んで関われるかを分けます。

図の作成：Remogu編集部。攻撃シナリオと攻撃ツリーの考え方を整理したもので、統計データではありません

5. リモート・フリーランス案件でどう関わるか（実装・見極め）

ネットワーク・インフラ・組み込みの経験が生きる場面

ここまでのリスク分析や脅威モデリングは、専用の知識だけで完結するものではありません。ネットワークの設計や運用、組み込み機器の開発、システム全体のインフラ設計に携わってきた経験は、IT/OTの境界をどう守るかという問いに直接つながります。通信の可視化やセグメンテーションの設計、可用性を優先した変更管理の考え方は、情報システム側の実務でも積み上げられるものです。資産の一覧化や構成の棚卸しといった地道な作業も、インフラ運用で培ってきた手順がそのまま生きる場面です。資格の有無より、工程のどこで動けるかが問われる領域です。

フルリモートで関われる範囲を見極める

制御システムの現場そのものに立ち会う工程は限られますが、資産の洗い出しやリスク分析の整理、攻撃シナリオ・攻撃ツリーの検討、報告資料の作成といった工程は、リモートでも十分に進められます。案件の90%以上がフルリモート可能です⁷。たとえば、資産の一覧をもとにしたリスク評価シートの作成や、攻撃シナリオを整理したレビュー資料のとりまとめ、関係者との定例会議への参加といった工程は、画面越しのやり取りで十分に進められます。まずは自分の経験がどの工程で活きるのかを、案件ごとに照らし合わせて見ていくことになります。

経験とOT案件での関わり方

OT・制御システムセキュリティの案件は、専用の資格や経験だけで担うものではなく、これまで積み上げてきた技術領域の延長線上にあります。次の表は、ネットワークやインフラ、組み込み、ITセキュリティといった経験が、案件の中でどの視点に結びつき、どんな動きにつながるかを整理したものです。自分の経験に近い行を手がかりに、案件で求められる役割との距離を確かめてみてください。

経験	OT案件で活きる視点	案件で求められる動き
ネットワーク設計・運用	IT/OT境界の通信制御、セグメンテーションの設計	現状のネットワーク構成を資産ベースで棚卸しする
組み込み・制御機器の開発	制御機器の挙動やプロトコルへの理解	攻撃シナリオを機器の視点で検証する
インフラ・運用設計	可用性を優先した変更管理・パッチ計画	事業被害ベースの分析結果を運用計画に反映する
ITセキュリティ全般	脅威モデリングの手法そのものは共通	可用性優先という優先順位の違いを踏まえて提案する

資産ベース・事業被害ベースの分析、攻撃シナリオ・攻撃ツリーによる脅威モデリング、そして可用性を最優先にした設計。ここまで整理してきた視点を、次にどう行動へつなげるかを見ていきます。

6. まとめ

制御システムは、外部との接続や汎用のプラットフォームの活用が広がったことで、これまでとは違う向き合い方を求められるようになっています。重視される優先順位は可用性、完全性、機密性の順で、情報システムとは逆の並びです。資産ベースと事業被害ベースという2つの手順、攻撃シナリオと攻撃ツリーによる脅威モデリングが、その向き合い方を支える地図になります。ネットワークやインフラ、組み込みの設計に携わってきた経験は、この地図の上で十分に活きる位置にあります。専用の資格を先に揃える必要はなく、資産の洗い出しや通信の可視化といった、これまでの実務の延長から関われる工程は少なくとも複数あります。まずは資産の洗い出しや分析の整理といった工程から、自分の経験がどこで生きるのかを確かめてみることが、次の一歩になります。案件の一覧を眺めながら、自分に合う関わり方を探してみてください。

7. よくある質問

制御システムの専門知識がなくても関われますか

資産の洗い出しやリスク分析の整理、報告資料の作成といった工程からであれば、専門知識がなくても関わりやすい案件があります。制御機器そのものの知識は、案件を通じて積み上げていく場面もあります。まずはネットワークやインフラの経験を軸に、関われる工程を確認してみることをおすすめします。資産の洗い出しやドキュメントの整理といった工程から始めて、少しずつ制御システム特有の知識を補っていく進め方でも十分に対応できます。

どんなスキルが活きますか

ネットワークの設計・運用、組み込み機器の開発、システム全体のインフラ設計に携わってきた経験が土台になります。通信の可視化やセグメンテーションの設計、可用性を優先した変更管理の考え方は、そのまま制御システム側の防御にも通じます。経験と視点の対応関係を、案件選びの手がかりにしてみましょう。とくに境界における通信の設計や監視の経験は、IT/OTのどちら側から来たエンジニアにとっても評価されやすい領域です。

リスク分析はどう進めればよいですか

資産ベースと事業被害ベースという2つの手順を、目的に応じて使い分けます。対策の網羅性を確認したいときは資産ベース、被害の重大性を関係者に伝えたいときは事業被害ベースが向いています。案件では、依頼側がどちらの視点を求めているかを最初に見極めることが、進め方を決める鍵になります。どちらの手順を選んだ場合も、最終的には両方の視点を突き合わせて抜け漏れを確認する工程が加わることが一般的です。

IT系のセキュリティ経験は活きますか

脅威モデリングや攻撃シナリオを組み立てる手法そのものは、情報システム側の経験とも共通しています。違うのは、可用性、完全性、機密性の順でセキュリティ要件が重視される点です。この順番の違いを踏まえたうえで提案できるかどうかが、案件で信頼を得られるかどうかの分かれ目になります。情報システム側で培った脅威モデリングの経験を、可用性優先という前提に合わせて読み替えられるかどうかが、提案の質を左右します。

案件はフルリモートでもできますか

はい。前の章でご紹介したとおり、Remoguが扱う案件はリモートを前提に設計されています。資産の洗い出しやリスク分析の整理、報告資料の作成といった工程は、リモートでも十分に進められます。打ち合わせや資料のとりまとめといった工程は、拠点を問わず参加しやすい形で進められます。案件ごとの条件は異なるため、登録して案件一覧で自分に合う条件を確かめてみることをおすすめします。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 情報処理推進機構「制御システムのセキュリティリスク分析ガイド 第2版」（2026年）
＊2 情報処理推進機構「制御システムのセキュリティリスク分析ガイド 第2版」（2026年）
＊3 情報処理推進機構「制御システムのセキュリティリスク分析ガイド 第2版」（2026年）
＊4 情報処理推進機構「制御システムのセキュリティリスク分析ガイド 第2版」（2026年）
＊5 情報処理推進機構「制御システムのセキュリティリスク分析ガイド 第2版」（2026年）
＊6 情報処理推進機構「制御システムのセキュリティリスク分析ガイド 第2版」（2026年）
＊7 Remogu（株式会社LASSIC運営）公開情報：扱う案件の90%以上がフルリモート可能