⚡ 電気担当 🔧 保全担当

制御セキュリティの現場チェック¶

30秒まとめ¶

制御セキュリティは新しい学科ではなく、いまやっている作業に確認項目が1つ増えるだけです。盤を開けたとき・ベンダーが来たとき・仕様書を書くときの7場面で見るものを決めておけば、専門知識がなくても現場の実態は把握できます。最も効くのは仕様書と受入検査です。

IT のやり方をそのまま持ち込めない理由¶

情報系（IT）と制御系（OT）では、守るものの優先順位が逆転します。

	優先順位
情報系（IT）	機密性 → 完全性 → 可用性
制御系（OT）	安全 → 可用性 → 完全性 → 機密性

情報系は「怪しければ止める」が正解です。制御系は止めると人が危険にさらされるか、設備が壊れるか、生産が止まります。

「パッチを当てろ」「ウイルス対策を入れろ」が通らない理由

適用するとベンダーの動作保証の対象外になる
検証できる環境がない（本番機しかない）
定修まで止められない
対応 OS がサポート切れで、そもそも適用できるものが無い

制御側の担当者の役割は、情報系のポリシーを現場に押し込むことではありません。 止められない前提で何ができるかに翻訳することです。

作業別チェック（7場面）¶

日常業務のついでに見るものだけを並べています。時間を取って調査する必要はありません。

1. 盤を開けたとき¶

見るもの	なぜ
空きLANポートに何か刺さっていないか	無断接続の入口になる
用途不明のUSBメモリ・LANケーブル	作業時の置き忘れが常態化していることがある
後付けの無線AP・モバイルルータ・変換器	最も危険。誰がいつ付けたか分からない通信機器
盤の施錠状態	物理的に触れれば大半の対策は迂回できる

見つけても、その場で抜かない

通信機器やケーブルが現に制御に使われている可能性があります。抜いた瞬間に設備が停止・誤動作する恐れがあるため、写真を撮って記録し、設備担当・保全・ベンダーに用途を確認してから処置を決めてください。「不審だから外す」は制御系では事故になります。

2. HMI・エンジニアリングPCの前に立ったとき¶

OS の版数と、メーカーのサポート期限
ログインしっぱなしになっていないか（離席時の画面ロック）
パスワードの貼り紙・共有アカウントの有無
USBポートの使われ方（常用されていないか）
ウイルス対策ソフトの有無と、ベンダーが許可しているかどうか

3. ベンダー・協力会社が作業に来たとき¶

7場面のうち、実務上これが一番効きます。 実際のインシデントの侵入口はここが多いためです。作業報告書に次の3行を足すだけで足ります。

持込PCを使ったか（機種・持込者）
USBメモリを使ったか
社外からのリモート接続をしたか

4. リモート保守回線を意識したとき¶

常時つながっているのか、必要時だけ開けるのか
誰が開閉を判断し、誰が実際に操作するのか
常時接続なら、なぜ常時である必要があるのかを一度だけ確認する

5. 仕様書を書くとき・メーカー選定のとき¶

推進担当としてのレバレッジが最も大きい場面です。 既設は簡単には直せませんが、これから入るものは決められます。仕様書に次の4行を入れます。

OS・ファームウェアのサポート期限（納入時点で残り何年か）
初期パスワードの変更可否、アカウントを個人別に分けられるか
操作・変更のログを取得できるか、取り出せるか
リモート接続の方式と、こちら側で遮断できる手段があるか

詳細は仕様書の書き方・メーカー選定を参照してください。

6. 異常が起きたとき¶

制御系の事案は、初期には「原因不明の誤動作」として処理されがちです。 「故障」と結論づける前に、1回だけ次を確認します。

いつから起きているか
同じタイミングで他にも異常が出ていないか
直前に誰かが触っていないか（工事・保守・設定変更）

切り分けの詳細は PLC/DCSトラブルを参照してください。

7. 図面・系統図を見るとき¶

制御系が情報系LAN・インターネット・無線とどこでつながっているかを確認します。単線結線図ではなくネットワーク構成図です。

「無い」と分かること自体が成果です

制御系のネットワーク構成図が整備されていない現場は珍しくありません。無いことが分かれば、それが最初に作るべき成果物になります。

見つけたことをどう扱うか¶

その場で処置しない（前述のとおり停止・誤動作のリスクがある）
写真と場所を記録する
設備担当・ベンダーに用途を確認する
用途が確認できないものだけを、正式な変更管理（MOC）に乗せて処置する

異常時の報告経路そのものは電気事故対応と報告に従います。 誰が設備停止を判断するのかが決まっていない場合、それは制御セキュリティ以前の課題です。

このページに書いてはいけないこと¶

本Wikiは公開サイトです

ei-wiki は GitHub Pages で一般公開されています。次のものは本リポジトリに書けません。

自工場の制御系の資産台帳（機種・台数・OS版数・IPアドレス）
ネットワーク構成図・外部接続点
取引先ベンダー名と保守回線の仕様
アカウント運用の実態

自工場固有の情報は非公開リポジトリ側に置いてください。本リポジトリには自工場固有の章を置かない運用です。本ページは一般論とチェック観点のみを扱います。

参考にできる公的資料¶

いずれも無償で入手できます。業務時間内に読む前提で、上から順に必要な分だけ参照してください。

資料	発行	使いどころ
工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン	経済産業省	社内説明・計画立案の土台
J-CLICS（ICSセキュリティ自己評価ツール）	JPCERT/CC	チェックリスト形式の自己評価
制御システムのセキュリティリスク分析ガイド	IPA	リスク分析の実施手順とシート
NIST Special Publication 800-82（Guide to Operational Technology Security）	NIST（英語）	体系的に学ぶ場合

根拠¶

本ページの位置づけ — 観点の一覧であって、規格の要約ではない¶

本ページは、日常業務のなかで制御系のセキュリティ状態に気づくためのチェック観点の一覧です。特定の規格・ガイドラインの要求事項を要約したものではなく、適合性を判断する基準にもなりません。

参照資料の所在確認（2026-09-17）¶

「参考にできる公的資料」の4点について、発行元の公式ページに当該資料が現に掲載されていることを 2026-09-17 に確認しました。

経済産業省「工場システムにおけるサイバー・フィジカル・セキュリティ対策ガイドライン」（Ver1.0 / Ver1.1 が掲載。別冊「スマート化を進める上でのポイント」は 2024-04 公表）
JPCERT/CC「J-CLICS STEP1／STEP2」および「J-CLICS 攻撃経路対策編」（2023-03 公開）
IPA「制御システムのセキュリティリスク分析ガイド第2版」（2026-04 版。別冊「実施例」あり）
NIST Special Publication 800-82 Rev.3（2023 年発行）

限界の明示¶

上記4資料の本文は逐語照合していません。 版の存在と配布元の所在を確認したのみです。各資料の具体的な要求事項を引用・要約する場合は、本ページではなく原典に当たってください
本ページのチェック項目は網羅ではありません。 7場面は「日常業務のついでに確認できるもの」に絞った結果であり、資産管理・ネットワーク分離・インシデント対応体制といった、時間を取って取り組む必要がある領域は意図的に含めていません
リスク分析の代替にはなりません。 本ページのチェックをすべて実施しても、リスクアセスメントを実施したことにはなりません
「IT と OT の優先順位が逆転する」という整理は制御セキュリティ分野で広く共有されている考え方ですが、本ページは特定の規格の条文に紐づけた記述をしていません
本ページは自工場固有の構成・機器・ベンダーに関する情報を一切含みません（公開リポジトリのため）

照合日: 2026-09-17（参照資料の所在と版の確認のみ。本文の逐語照合は未実施）。

🤖 この記事をChatGPTに渡す（プロンプト生成）

↗ ChatGPTを開く

使い方: コピー → ChatGPT で貼り付け → 質問を追記して送信。