タイの工場でOTセキュリティ対策を導入するとき、最初に買うものをファイアウォールや監視製品の型番だけで決めると、発注後に「止められない設備をどう試験するか」「誰が例外を承認するか」「保守会社の遠隔接続をどう戻すか」で行き詰まります。調達側が先に決めるべきものは、守る生産工程、許容できない停止、既存設備の制約、必要な証拠、合否判定です。本稿はその内容をRFP(提案依頼書)とFAT/SAT(工場・現地受入試験)に変換する実務ガイドです。対象は、タイに生産拠点を持ち、PLC、HMI、SCADA、産業用PC、カメラ、計測器、MES接続、外部保守接続のいずれかを運用する製造企業の工場長、設備・生産技術、IT/OT担当、調達担当です。
2026年9月21日、米国NISTは『Guide to Operational Technology (OT) Security』SP 800-82 Rev.4の初期公開草案を出し、コメント期限を同年11月30日としました。草案はOT資産管理、ネットワーク監視・検知、管理機能の保護、ゼロトラスト原則などの記述を拡充しています。ただし本稿執筆時点でRev.4は確定版ではありません。仕様書の基準文書を記すときは、2023年のRev.3確定版とNIST CSF 2.0を基礎にし、Rev.4草案で検討したい論点を別欄に置きます。NIST文書はタイの全工場に一律で適用される法令ではありません。顧客契約、業界要求、タイで適用される規制は案件ごとに確認してください。
この記事で持ち帰る成果物
読み終えた時に用意するのは、①一枚の対象範囲図、②入札者に同じ条件を渡すRFP表、③FAT/SATの試験票、④運用引継ぎと例外管理表です。製品機能の数を競うより、提案各社が「実際のラインで安全に実装・検証できるか」を比較します。以下の表と質問はコピーして社内の調達文書に移せますが、停止許容時間や構成値は現場で実測・合意した値に置き換えてください。
| 調達前に決めること | 記入例ではなく確認すべき事実 | 最終承認者 |
|---|---|---|
| 守る工程 | 停止時に出荷・品質・安全へ影響するラインと設備 | 工場長・生産責任者 |
| 接続境界 | IT/OT間、ライン間、外部保守、クラウド、無線 | OT責任者とIT責任者 |
| 試験可能条件 | 停止窓、代替機、製品ベンダー立会い、復旧条件 | 生産技術・設備保全 |
| 受入証拠 | 設定一覧、通信ログ、バックアップ、試験記録 | 発注者側の検収責任者 |
1. まず「守るライン」と「触ってよい範囲」を確定する
OTの対象は端末の台数だけでは決まりません。あるPLCが包装ラインを止めれば、上流の仕掛品、下流の検査、ERP上の実績に影響します。RFPの冒頭には設備一覧とともに、その設備が担う工程、通常時の通信、保守契約、止まった場合の影響を書きます。把握できていない機器を「対象外」と断定せず「要調査」と区別します。資産情報の集め方や優先順位づけはタイ工場のOT資産管理も参照してください。本稿は台帳作成そのものではなく、台帳を調達条件と受入証拠に使う段階を扱います。
現場ウォークダウンでは、制御盤、PLCとI/O、HMI、エンジニアリング端末、産業用スイッチ、ラインサーバー、ヒストリアン、保守用ルーター、無線アクセスポイントを物理的に追います。論理図にはIPアドレスだけでなく、誰が管理し、いつ接続し、停止時にどの工程が影響を受けるかを付けます。配線図と実機が食い違う場合は、変更管理記録を確認し、現場承認を得るまで通信遮断ルールの投入を保留します。既存ネットワークの構成と分割を考える際は産業ネットワーク構築の解説も併読できます。

RFPの対象範囲には「今回の入札で導入するもの」「設計だけするもの」「既設のまま監視するもの」を分けて明記します。設備メーカーの保守契約を失う恐れがある設定変更、認証未対応の古い機器、停止できない安全系設備を曖昧に含めると、業者ごとに違う前提で見積もりが出ます。対象外にも接続点があれば境界図に残し、受注者が見落とせないようにします。工場側では、生産・設備・品質・IT・調達の担当者名を記し、判定会議に出席できる時間を確保します。
2. Rev.4草案をどうRFPに使うか
Rev.4草案の公開は、既存の調達文書を点検するきっかけになります。NISTは草案の概要で、OT固有の性能・信頼性・安全要求を保ちながら、資産管理やネットワーク監視、管理機能の防御を強化する方向を示しています。一方、草案の文言や構成は確定まで変わり得ます。したがって「Rev.4に完全準拠」とだけ書くのではなく、求める成果を具体的な試験で表現します。例として「保守アクセスは事前承認、個人ID、時間制限、セッション記録、終了後の無効化を確認できる」と書けば、どの版を参照しても調達上の意味が明確です。
| 参照資料 | RFPでの役割 | 誤解を避ける書き方 |
|---|---|---|
| NIST SP 800-82 Rev.3確定版 | OT特有の可用性・安全性を踏まえた設計の基礎 | 推奨事項を自社の設備制約に照らして採否判断 |
| NIST SP 800-82 Rev.4初期公開草案 | 新しい検討論点の確認 | 2026年9月21日公開の草案と版を明記 |
| NIST CSF 2.0 | ガバナンスから復旧までの成果整理 | チェックリストをそのまま合格証明にしない |
| ISA/IEC 62443シリーズ | 資産所有者・サービス提供者・システム・機器の役割整理 | 適用する部・版・対象範囲を指定 |
| CISA CPG | 優先度の高い基礎対策の参考 | 任意の指針として扱い、各工場で適用判定 |
ISA/IEC 62443を使う場合、単に「62443対応」と書かず、資産所有者のプログラム、サービス提供者の運用、システム要求、コンポーネント要求のどれを誰に求めるのか特定します。機器がある規格に適合していても、工場全体のネットワーク設計、権限管理、復旧手順まで自動的に満たすわけではありません。NIST CSF 2.0はGovern、Identify、Protect、Detect、Respond、Recoverの6機能で成果を整理できます。調達表では機能名を見出しにするより、各行に「誰が何を示せば受入となるか」を付ける方が比較しやすくなります。
3. RFPの第一章:現状、設計制約、責任境界
最初の章には工場名やライン数だけでなく、工程フロー、稼働カレンダー、既設トポロジー、シリアル接続の有無、ベンダー遠隔保守、MES/ERPとのインターフェース、バックアップ状況、既知の変更禁止期間を記載します。機密性の高い図面は守秘契約後に配布する運用でも構いませんが、全入札者に同じバージョンを配り、質問回答を共有します。接続経路が未確認ならその旨を書き、現地調査を入札範囲に含めます。
責任分界表では、設備メーカーがPLCプログラムと安全ロジック、ネットワーク施工会社が配線・スイッチ、セキュリティ受注者がポリシー・監視、工場側が停止承認と最終検収を担う、といった具合に担当を明確にします。複数社にまたがる障害時、誰が一次切り分けを行い、誰が設定を戻すかも決めます。タイ語で運用する作業員と日本語・英語で承認する管理者が混在するなら、アラート名、操作手順、エスカレーション先の言語を仕様に入れます。翻訳しただけで通じるとは限らないので、現地担当者の読み合わせを受入項目にします。
4. RFPの第二章:必要なセキュリティ成果を機能単位で書く
境界と通信では、ライン内、ライン間、工場IT、外部保守の通信を分け、許可すべき送信元・宛先・プロトコルを提案者に示してもらいます。監視モードでの観測期間を設け、現行通信が分かってから遮断ポリシーを有効化する手順を求めます。産業用プロトコルに対する機器の互換性、ブロードキャストや時刻同期への影響、冗長切替時の挙動まで確認対象にします。図面にない通信を即遮断する設計は、製造停止の危険があります。
保守アクセスでは、共用IDを避け、個人の識別、承認、接続時間、操作記録、緊急時の手順、退職・契約終了時の失効を要求します。リモート保守が必要なPLCの前にジャンプホストを置く場合、そこで実際に必要なツールが動くか、ベンダーのサポート条件に抵触しないか確認します。インターネットから制御機器への常時直結を前提にしないでください。臨時の接続は申請番号と対象設備、終了時刻を記録します。
監視と検知では、受動的な通信観測を基本案として、ミラーポートやネットワークTAPの設置箇所、ログの時刻同期、保存先、アラートの責任者、誤検知の扱いを明記します。能動スキャンを行うなら、機器メーカーの許可、対象範囲、停止窓、試験環境での確認を先に求めます。「すべての異常を検知」といった測れない宣伝文句は避け、許可していない保守接続、設定変更、既知のテスト通信が想定どおりに記録されるかを受入試験にします。
復旧では、PLCプログラム、HMI設定、スイッチ設定、ファイアウォールルール、ライセンス、鍵、仮想マシンのどれを誰がバックアップし、どの順番で復元するかを要求します。単にバックアップファイルが存在するだけでは不十分です。復旧先の互換性、保存場所の分離、権限、実際のリストア手順を試験票に載せます。安全系や生産系のテストは本番機で無理に行わず、代替機・検証環境・停止窓を選びます。
5. 提案者に提出させる「比較できる回答」
入札者が同じ行に回答できるよう、要件ごとに「標準機能で実現」「追加設定で実現」「カスタマイズ」「非対応」「要現地調査」を選ばせます。各回答には根拠となる資料、前提条件、現場側が負担する作業、FAT/SATでの証明方法を付けます。提案資料のスクリーンショットや製品カタログだけでは、既設PLCや操業条件で動く証拠にはなりません。
| RFPの質問例 | 提案者に添付させるもの | 受入時の確認 |
|---|---|---|
| 非許可通信をどう見つけ、安全に遮断するか | 現行通信の観測計画、ルール案、ロールバック手順 | 許可通信が続く状態で試験通信だけを遮断 |
| 保守会社のアクセスを誰が承認するか | 権限表、申請・失効フロー、ログ例 | 未承認IDを拒否し承認セッションを追跡 |
| 監視アラートを誰が処理するか | 通知経路、担当時間帯、誤検知調整手順 | 模擬イベントから現地担当者まで到達 |
| 障害時にどう戻すか | 設定バックアップ一覧、復旧順序、連絡網 | 試験環境で復元し記録を残す |
| 運用変更をどう引き継ぐか | 設定図、管理者教育、保守条件 | タイ側の担当者が手順を再現 |
点数付けでは、価格だけでなく、工程停止リスク、既設機器との適合性、保守可能性、証拠の質、現地チームへの移管を評価軸にします。重みづけは調達前に発注者が決め、提案開封後に都合よく変えません。初期費用と継続費用は、ライセンス、ハードウェア、工事、検証、保守、ログ保管、現地立会いを分けて提示させます。本稿は市場価格や予算額を提示しません。費用はライン構成、停止窓、既設契約と要求水準によって変わるためです。

6. FATで確認すること:現場に持ち込む前の安全性
FATは出荷前またはラボ環境で、設計どおりに機能するかを確認する段階です。実機を再現できない項目は「FAT未実施、SATで確認」と書き、合格に見せかけません。事前に合意した構成版、設定ファイル、機器の型式・ファームウェア、模擬PLC・HMI、テストデータ、期待結果を試験票に固定します。少なくとも、認証・権限、許可通信と拒否通信、時刻同期、ログ出力、バックアップと復元、機器故障時の挙動、ポリシーの戻し方を確認します。
例えば遮断テストは「試験端末から許可対象HMIへの定めた通信は通る」「許可していない経路からの通信は拒否される」「拒否の記録が時刻付きで残る」を別々の項目にします。最後に検証前の設定へ戻して生産系接続が再開するまでを測ります。PLCに負荷をかけるテストや本番データを使う試験は、設備メーカーと工場側の承認なしに実施しません。FATの記録には操作した人、日時、設定版、結果、証拠ファイル、未解決事項、再試験条件を残します。
| FAT試験ID | 刺激・操作 | 期待結果 | 証拠 |
|---|---|---|---|
| F-01 | 許可済みの保守IDで接続 | 承認した時間帯・対象端末だけ接続可 | 承認票、セッション記録 |
| F-02 | 無効化したIDで再接続 | 接続拒否、試行ログ記録 | 認証ログ |
| F-03 | 模擬の非許可通信を送出 | 本来の制御通信を維持して当該通信を遮断 | パケット記録、工程側の確認 |
| F-04 | 設定をバックアップし代替機へ復元 | バージョンと設定が一致し機能が回復 | ハッシュ、復元記録 |
| F-05 | 監視経路を停止・復旧 | 生産通信への影響が設計どおり | ネットワーク記録 |
7. SATで確認すること:タイの実ラインで運用できるか
SATは設置後の現地受入です。工場側が承認した停止窓と切戻し条件の下で行います。FATで通った製品でも、現場の予期しない通信、古いファームウェア、ネットワークのループ、時刻ずれ、設備メーカー独自の保守ソフトで結果が変わります。現地の既設構成を最新図面と照らし、差分を記録してから設定を投入します。工程の品質検査や安全確認を省いてセキュリティだけを合格にしません。
SATでは「運転中」「段取り替え」「停止・再起動」「障害・切戻し」の各状態から代表場面を選びます。監視アラートは、現地担当者が通知を読み、対象設備を特定し、誤検知か異常かを判断し、エスカレーションできるところまで試します。タイ語の手順書を使うなら現地担当が自分の言葉で操作を再現できるか確かめます。工場長は、切替後のスループットや品質への影響を確認し、IT側の成功画面だけで検収しないようにします。
合否の基準は、実施前に発注者と受注者で署名します。例えば「工程が通常条件で継続する」「許可した保守接続は操作証跡が残る」「無許可接続は拒否される」「模擬アラートが指定担当に届く」「設定を合意した状態へ戻せる」という観測可能な条件です。数値の閾値は工程の実測値から決めます。一般記事の数字をそのまま保証値にしません。テスト失敗時の対応は、是正、再試験、暫定措置、発注者の例外承認の四つに区分し、誰が何をいつまでに実施するか書きます。

8. 稼働後の契約:アラート、変更、復旧まで含める
導入直後の合格は運用の開始点です。RFPには、監視時間、一次対応者、設備メーカーへの連絡条件、遠隔保守権限の定期見直し、ルール変更承認、パッチ・脆弱性情報の受け渡し、バックアップ確認、障害時の切戻し支援を含めます。24時間監視が不要な工場に一律で要求を課す必要はありません。一方、休日や夜間に稼働するラインなら通知先が空白にならないようにします。サービス水準は「何分以内」と機械的に置かず、リスク・社内体制・契約可能な支援に応じて決めます。
特に重要なのは変更管理です。新しい機械が接続されたとき、保守ベンダーが交代したとき、MESとのデータ連携を追加したとき、誰が通信ルールと資産台帳を更新するかを決めます。セキュリティ機器の管理画面だけに最新情報があり、設備図や保守契約に反映されない状態を避けます。変更票には目的、対象、リスク、試験方法、戻し方、承認者、実施後の図面更新を一緒に書きます。例外を認めた場合は期限と見直し日を付け、恒久的な抜け道にしないことが肝要です。
9. 発注前の現地会議で使う10の質問
- このラインで停止できない設備と、停止できる時間帯はどこですか。
- PLC・HMI・産業PCの設定を最終承認するのは誰ですか。
- 設備メーカーの保証やサポート条件と競合する対策はありますか。
- 実際に使われている遠隔保守経路はいくつあり、誰が承認していますか。
- IT/OT境界とライン間の通信は図面と一致していますか。
- 未把握の機器が出たとき、設計変更と追加見積をどう扱いますか。
- FATで再現できない項目をSATで誰が、どの停止窓に試しますか。
- 許可通信が遮断された場合、誰がどの情報を見て切戻しを判断しますか。
- タイ語・英語・日本語のどの言語で運用記録と緊急連絡を行いますか。
- 稼働後、資産・権限・通信ルール・復旧手順を誰が更新しますか。
この質問に社内で答えられない項目は、入札者に自由な前提を置かせるより、RFPの「要現地調査」として明示する方が比較可能性を保てます。実査の成果物と見積の前提を分け、後から対象が増えたときの変更契約手順も記してください。
10. 典型的な失敗と、調達文書での防ぎ方
「製品の機能表だけで比較する」場合、既設設備との整合や運用体制が見えません。各機能に試験条件と証拠を添えて比較します。「ITの脆弱性スキャンをそのままOTへ適用する」場合は、停止・誤作動のリスクがあります。機器ごとの承認と非本番検証を先に行います。「遮断を急ぐ」場合は、現行通信の観測、例外の洗い出し、段階的投入、切戻しを発注範囲に入れます。「FAT合格をSAT合格とみなす」場合は、現地固有の配線や運用差分を見逃します。両者の試験票を分けます。
「証明書があれば工場全体が安全になる」と考えるのも危険です。製品認証は製品に関する証拠の一つであり、境界設計、保守IDの扱い、現場教育、復旧の実行可能性は別に確かめます。「導入後の担当を決めない」場合は、アラートが放置され、接続許可が増え続けます。発注書に運用引継ぎ会議、台帳、権限表、定期見直しを納品物として明記します。
11. 90日で進めるなら、日付より判定ゲートを重視する
実施期間は工場の停止窓、設備メーカーの立会い、対象ラインの数で変わります。ここでは90日を保証納期ではなく、担当と成果物を並べる計画の例とします。第一段階では現地調査・対象範囲・重要工程・責任者を固め、図面の差分を記録します。第二段階ではRFP回答と安全性を比較し、採用設計、FAT台本、SAT停止窓を合意します。第三段階でFAT、現地設置、SAT、現地教育、運用引継ぎを行います。各段階の通過条件は「資料がある」だけでなく、工場側の承認者が証拠を確認したことです。
スケジュールが短い場合も、現地調査、既設通信の確認、切戻し設計、運用担当の任命は省けません。調達を急ぐなら、対象を一つのラインや一つの保守経路に絞り、追加展開は初回のSAT結果を見てから決める方法が現実的です。これにより、現場で使える試験方法と教育資料を先に作れます。横展開時には全ラインに同じ設定をコピーせず、機器、停止条件、通信先の差分を再評価します。
12. RFPに入れられる要求条項の記入例
以下は規格の引用ではなく、発注者が自社の条件を埋めるための文案例です。角括弧内は実際のライン名や担当者、設備ID、合意値に置き換えます。空欄のまま発注すると、受注者が独自の前提で価格と工期を見積もるため、比較と検収が難しくなります。工場側が決められない値は「現地調査後に発注者が承認する」と明記し、提案者の推定値と区別します。
対象範囲:受注者は[対象ライン・設備ID]の制御通信、保守接続、監視経路を対象とし、既設設備への影響を評価する。対象外と判断した接続点も境界図に記載し、判断理由を提出する。未確認機器を発見した場合は変更作業に着手せず、発注者の[承認担当]へ報告する。
安全な変更:受注者は設定投入前に、現行通信の観測結果、許可・拒否ルール、設備メーカーの制約、停止窓、切戻し手順、担当者の連絡先を提出し、発注者の承認を得る。安全系の制御と製品保証に関わる変更は[設備メーカーまたは指定責任者]の確認を要する。
保守接続:外部保守は個人を識別できるIDと承認済みの対象・時間に限定する。接続開始、操作、終了、拒否を追跡できる記録を残し、契約終了・担当変更・緊急接続後には権限を再評価する。必要な例外には理由、期限、代替策、承認者を記録する。
受入と引継ぎ:FATとSATの各試験について、操作、期待結果、証拠、実測結果、合否、是正責任者を記録する。FATで実施できない項目はSATへ引き継ぐ。SATで不合格の項目は是正と再試験を原則とし、暫定運用が必要なら発注者の書面承認と期限を得る。最終検収前に完成図、設定、バックアップ、復旧手順、権限表、運用手順、教育記録を引き渡す。
この文案をそのまま丸写しするのではなく、対象ごとに実行可能か確認します。たとえば外部保守会社が複数ある場合は、各社の作業範囲とID失効の担当を別表にします。PLCのバックアップを設備メーカーしか取得できないなら、その立会いと成果物の受領方法を契約に含めます。ログに個人情報や取引先情報が含まれるなら、保存先、閲覧権限、保管期間を自社の契約・方針と整合させます。FAT/SATの試験票は双方が事前に承認した版を使い、試験中に変更した場合は変更履歴と再試験の要否を記録します。こうした細部を契約前に揃えることで、見積の安さだけでなく実装と運用の確かさを選べます。
判定会議の議事録には、単なる「合格」の一語ではなく、試験IDごとの実測結果、合否、未解決の例外、暫定的な運用制限、再試験予定日、署名者を残します。生産部門は工程の継続と品質、設備部門は安全と復旧、IT/OT担当は通信・権限・ログ、調達部門は契約上の納品条件を確認する役割です。一部の機能が未完了でも稼働を始める判断をするなら、残るリスクの影響を工場長が理解し、期限と代替策を承認した記録が必要です。受注者の報告書だけに保存せず、発注者がアクセスできる保管場所へ証拠を引き渡します。
また、次のラインに展開する際は、初回の合格票をそのまま転用しません。PLCの型式、設備メーカーの保守条件、スイッチ構成、操業時間が異なれば、許可すべき通信と安全な停止窓も変わります。初回で有効だった試験手順をひな形として使い、現地の差分を追記して再承認します。これにより共通設計の利点を残しながら、ライン固有のリスクを試験で見落とさずに済みます。
13. まとめ
調達担当が最後に確認したいのは、合否がベンダーの自己申告だけで決まらない設計になっているかです。納品物一覧には、現状図と完成図、設定の管理版、通信許可一覧、管理者と保守業者の権限表、FAT/SATの生データ、未解決事項表、バックアップ、復元手順、現地語の運用手順、教育記録を含めます。資料のファイル形式、保管先、更新権限、契約終了時の引渡し方法も先に決めます。監視機器が特定ベンダーに依存する場合は、ログのエクスポート形式と契約終了後の閲覧方法を尋ねます。障害が起きてから初めて見積書の範囲を読み直す状態を避けるためです。
もう一つは、受入後の改善サイクルを決めておくことです。初回SATで見つかった未知の通信や例外は、受注者だけの「宿題」にせず、工場側の変更管理へ登録します。どの工程に関係し、何を守るために例外が必要で、いつまで認め、次回点検でどう解消するかを記録します。運用開始後に新しい設備、工場Wi-Fi、クラウド分析、委託保守が増えれば境界条件も変わります。定期会議ではアラート数そのものより、未承認接続が残っていないか、権限の失効が遅れていないか、復旧手順が現行構成に合うかを点検します。これらは製品だけでは維持できないため、現地の責任者と予算の持ち主を明記する必要があります。
タイ工場のOTセキュリティ対策導入では、機器の購入前に工程の制約と受入条件を固定することが重要です。NIST SP 800-82 Rev.4は2026年9月21日に出た初期公開草案であり、確定版であるRev.3、NIST CSF 2.0、必要に応じたISA/IEC 62443やCISAの指針を参考に、現場で観測できる要件へ書き換えます。RFPでは責任分界と提案の証拠を揃え、FATでは安全な模擬環境で、SATではタイの実ラインで、許可通信・拒否通信・保守接続・検知・復旧・運用引継ぎを確認します。例外は期限を付けて管理し、設定を更新し続ける担当を決めて初めて、導入が運用になります。
対象ラインの選定、RFPの要求整理、FAT/SAT試験票の作り方を検討し始めた段階でも、TOMAS TECHへのお問い合わせから相談できます。既設設備の制約と現地チームの運用を前提に、調達前に確認すべき点を一緒に整理します。
参照した一次資料
- NIST SP 800-82 Rev.4 初期公開草案(2026年9月21日)
- NIST SP 800-82 Rev.3 確定版(2023年)
- NIST Cybersecurity Framework 2.0
- ISA/IEC 62443シリーズ公式案内
- CISA Cross-Sector Cybersecurity Performance Goals
- CISA ICS Recommended Practices(調達文例を含む)
*注:本稿は2026年10月2日時点の公開資料と一般的な調達実務を基にした計画例です。規格への適合、法令上の義務、性能保証を宣言するものではありません。*
社内でこの文書を使う際は、図表の「確認すべき事実」を自社のライン名、設備ID、担当者名、実測した運転条件に置き換え、未確認事項には期限と調査責任者を付けてください。受入後にも同じ表を更新すれば、次のラインへの展開時に根拠を再利用できます。