機械のサイバーセキュリティ規格 prEN 50742 をドラフト本文から読み解く|SRSL の決め方・ログ5年・アプローチA【2026年10月改訂】

はじめに(2026年10月 改訂のお知らせ)

こんにちは!

2027年1月20日の機械規則の適用開始まで、いよいよ3か月を切りました。この時期は、企業のご担当者さまや個人の方からのご相談がぐっと増えてきます。なかでも最近とくに多いのが「サイバーセキュリティ」に関するお問い合わせです。

サイバー攻撃や情報漏洩のニュースを目にする機会も増えましたよね。規制が厳しくなる流れの中で、対策が後回しになると、想定外のトラブルにつながる可能性が予見されます。すでに動き出している企業も多く、現場の温度感が一段上がっているのを感じます。

この記事は、以前に公開した prEN 50742 の解説を全面的に書き直したものです。初版を書いた時点では、規格の本文がまだ手元になく、公開情報をもとに整理していました。その後、2025年12月付の規格案(照会用ドラフト prEN 50742:2025)が公開されたため、今回は規格案の本文に沿って内容を確認し直しました。

あわせて今回は、2018年に発行された技術報告書 ISO/TR 22100-4 も読み直し、prEN 50742 と関係の深いところを9章で取り上げました。7年前の「指針」が、どのように今の「要求」へつながっているのかも見えてきます。

その結果、初版には規格案の内容と合わない説明がいくつか含まれていました。読者のみなさまにはお詫びするとともに、主な訂正点を記事の後半(「旧版記事からの主な訂正点」)にまとめています。初版を読んでくださった方は、そちらもあわせてご確認ください。

この記事では、機械規則の「corruption」を「改ざん」と訳しています。規格の原文には、悪意のある攻撃だけでなく、うっかりミスによる書き換えも含まれる点にご注意ください

免責事項と相談先について

prEN 50742 は、この記事を書いている時点(2026年10月)では、まだ正式な欧州規格(EN)として発行されていません。この記事は2025年12月付の照会用ドラフトをもとにしています。その後に最終案(FprEN 50742:2026)が作られており、細かな表現や数値が変わっている可能性があります。最新情報や適用の可否、具体的な対応方針については、第三者認証機関へお問い合わせください。

まずは第三者認証機関に直接お問い合わせいただくことが、何より重要です。

相談先として、コンサルティング会社やセキュリティ部品メーカー、ソフトウェア関連の会社を選ぶと、サービス内容や立場によって提案が偏ることがあります。特に、セキュリティ部品やソフトウェアの提供企業は、認証の枠組みや機械規則全体までを十分に把握していないケースも少なくありません。その結果、必要性の判断が曖昧なまま、高価な部品やソフトウェアの導入を勧められてしまう可能性もあります。

このあと詳しく見ていきますが、prEN 50742 は「機械の安全機能を守るためのセキュリティ」に範囲を絞った規格です。何でも最高レベルの対策をすればよい、という作りにはなっていません。まずは第三者認証機関に確認し、公式見解と適用範囲を押さえたうえで検討を進めるのがおすすめです。

1. 機械規則が求める「改ざんからの保護」

1.1 なぜ「セキュリティ」ではなく「改ざん」なのか

欧州の機械安全のルールは、2006年の機械指令(2006/42/EC)から、2023年の機械規則((EU) 2023/1230)へと切り替わります。機械規則は2027年1月20日から適用されます。

従来の「安全」は、挟まれ・巻き込まれ・感電、あるいは制御装置の部品故障から人を守ることが中心でした。ところが今の機械は、工場のネットワークやインターネットにつながっています。外部からの不正な操作や、うっかりした書き換えで機械の動きが変わり、けがにつながるおそれが出てきました。

そこで機械規則は、附属書III(必須安全衛生要求事項)に「改ざんからの保護(Protection against corruption)」を加えました。

ここで「セキュリティ」ではなく「改ざん」という言葉が使われているのには理由があります。悪意のある攻撃だけでなく、保守員が古いバージョンのプログラムを書き込んでしまう、USBメモリ経由でウイルスが入る、といった意図しない変更もまとめて扱うためです。原因が何であれ、安全機能がだめになる事態を防ぐ、という考え方です。

ちなみに、2018年の ISO/TR 22100-4 は、機械指令のもとでは故意の攻撃は「合理的に予見可能な誤使用」に当たらず、安全法規の範囲外だと整理していました。機械規則は、ここを法的な義務に変えたことになります(詳しくは9.1)。

1.2 附属書III 1.1.9 改ざんからの保護

機械規則 1.1.9 の要求を、私の訳で紹介します。

1.1.9 改ざんからの保護 (Protection against corruption)
機械又は関連製品は、当該機械に他の装置を接続した場合において、接続される装置自体の機能を介する場合であっても、または当該機械もしくは関連製品と通信する遠隔装置を介する場合であっても、危険な状況を生じさせないように設計および製造されなければならない。
関連する必須健康安全要求事項への適合にとって重要なソフトウェアへの接続またはアクセスに関係する信号もしくはデータを送信するハードウェア構成要素は、偶発的または故意による改ざんから適切に保護されるよう設計されなければならない。また、機械又は関連製品は、当該ハードウェア構成要素への正当または不正な介入について、当該構成要素が適合にとって重要なソフトウェアへの接続またはアクセスに関連する場合には、その証拠を収集しなければならない。
機械又は関連製品が、該当する必須健康安全要求事項に適合するために重要なソフトウェアおよびデータは、その旨が識別されなければならず、かつ、偶発的または意図的な改ざんから適切に保護されなければならない。
機械又は関連製品は、安全に動作するために必要な、当該機械にインストールされたソフトウェアを識別できなければならず、かつ、その情報を常に容易にアクセス可能な形で提供できなければならない。
機械又は関連製品は、当該機械もしくは関連製品にインストールされたソフトウェアまたはその設定に対する正当または不正な介入、もしくは当該ソフトウェアの変更について、その証拠を収集しなければならない。

少し硬い文章なので、4つのポイントに整理します。

ポイント	ひとことで言うと
接続の安全性	外部のネットワークや他の装置とつないでも、新たな危険が生じない設計にする
ハード・ソフトの保護	安全に関わるハードウェア、ソフトウェア、データを、うっかりミスや意図的な改ざんから守る
証拠(ログ)の記録	いつ、どんな変更や介入があったかを、後から追跡できるように証拠を残す
ソフトウェアの見える化	安全に動かすために必要なソフトウェアを特定し、その情報をいつでも確認できるようにする

1.3 附属書III 1.2.1 制御システムの安全性と信頼性

1.2.1 は制御システム全般についての要求です。このうち prEN 50742 が関係するのは、第2段落の a) と f) です。

つまり機械規則は、従来の「機能安全」の枠組みに、サイバーセキュリティを切り離せない要素として組み込みました。これを実際の設計に落とし込むための技術的な道しるべが、prEN 50742 です。

2. prEN 50742 の現在地(2026年10月時点)

prEN 50742「機械類の安全性 − 改ざんからの保護(Safety of machinery – Protection against corruption)」は、欧州電気標準化委員会(CENELEC)の技術委員会 CLC/TC 44X が作っている規格案です。欧州委員会の標準化要請(M/605)にもとづいて作られており、機械規則の「整合規格」になることを目指しています。

2.1 これまでの流れ

時期	できごと
2026年10月時点	最終案が正式投票の段階。EN としての発行、EU官報への掲載はまだ
2026年7月	最終案 FprEN 50742:2026 が作成され、正式投票へ
2026年2月27日	照会(各国からのコメント募集)の締め切り
2025年12月	照会用ドラフト prEN 50742:2025 を公開(この記事のベース)
2024年夏	CLC/TC 44X で作業開始

照会用ドラフトのあと、集まったコメントを反映して最終案が作られました。最終案は正式投票にかけられていますが、この記事の執筆時点では、まだ採択・発行されていません。

2.2 「整合規格」になるまでの道のり

規格が発行されただけでは、まだ法的な効果はありません。EU官報(Official Journal)に規格番号が掲載されて、はじめて「この規格に適合していれば、対応する機械規則の要求事項にも適合しているとみなす」という効果(適合の推定)が生まれます。掲載にも数か月かかるのが一般的です。

2027年1月20日の適用開始までに官報掲載が間に合うかは、現時点ではわかりません。間に合わない場合でも、機械規則の要求事項そのものは適用されます。そのときは規格案を「技術的な考え方の参考」として使いつつ、自社で適合の根拠を説明することになります。

2.3 適用延期の要請について

CECIMO(欧州工作機械工業会)や CEMA(欧州農業機械工業会)など、欧州の産業団体は、機械規則のサイバーセキュリティ要求(1.1.9 と 1.2.1 f))の適用を、サイバーレジリエンス法(CRA)の適用日である2027年12月11日にそろえて延期するよう、欧州委員会に要請しています(CECIMO ほか共同声明、2026年1月)。一方、欧州労働組合連合(ETUC)は、労働者の安全を理由に延期に反対しています(CEN-CENELEC ニュースレター)。

私が確認できた範囲では、執筆時点で延期は決まっていません。延期を前提にせず、2027年1月20日に間に合わせる前提で準備を進めるのが安全です。

2.4 すでに出荷・設置されている機械は?

規格案の適用範囲には、「この規格の発行日より前に設置された機械には適用しない」と書かれています。既存の機械を改造する場合は、機械規則の「実質的な変更」の考え方とあわせて、個別に判断が必要です。

3. 規格の基本的な考え方

規格案の「序文(Introduction)」には、この規格の土台になる考え方が短い文で並んでいます。ここを押さえておくと、後の章がぐっと読みやすくなります。私なりにかみ砕くと、次の5点です。

3.1 出発点はいつもの ISO 12100

メーカーは、まず EN ISO 12100 にもとづくリスクアセスメントで、機械の危険源をすべて洗い出します。サイバーセキュリティの検討は、その後に行います。いきなりセキュリティ対策から始めるのではない、という点が大事です。

この順番は、ISO/TR 22100-4 の図3が2018年に示したものと同じです。安全のリスクアセスメントで決めた保護方策を、次に「IT セキュリティの脆弱性」という目で見直す、という流れです。

3.2 弱点(脆弱性)は、新しい危険源を生まない

規格案ははっきり「脆弱性は新たな危険源を生み出さない」という立場を取っています。危険源は、あくまで刃物や回転体、高電圧といった、ISO 12100 で見つけたものです。

では何が問題なのか。弱点を突かれると、すでに用意した保護方策(安全機能)が効かなくなる、または安全なパラメータの範囲の外で機械が動いてしまう、という点です。たとえば、インターロックの設定を書き換えられて、ガードを開けても機械が止まらなくなる、といったケースです。

3.3 「狙われる確率」は評価に使わない

誰かが悪意をもって弱点を突いてくる確率は、予測できません。そのため規格案は、「自社の機械が標的になる可能性は低い」という理由づけを、脅威の評価に使ってはならないとしています。

ISO 12100 のリスクの見積もりでは「危害の発生確率」を使いますよね。そこが、セキュリティの評価では考え方が違うポイントです。代わりに使うのが、後で説明する「攻撃ポテンシャル(どれくらい攻撃が成り立ちやすいか)」です。

ISO/TR 22100-4 は、攻撃の動機(ノウハウを盗む、経済的損害、危険を生じさせる、テロ)ごとに安全との関係の強さを整理していました。prEN 50742 は、そうした「狙われやすさ」による割り引きを評価に入れない、という一歩踏み込んだ立場です(9.5)。

3.4 評価のものさしは「機能安全への影響」だけ

リスクは、機能安全にどんな影響が出るか、という観点だけで評価します。情報が盗まれる、生産が止まる、といった一般的な IT セキュリティの被害は、この規格の対象外です。

3.5 進め方は2つのルートから選ぶ

ルート	向いているメーカー	使う章
アプローチA	IEC 62443 シリーズを使わずに機械を開発しているメーカー	5章(プロセス)、7章(製品)
アプローチB	IEC 62443-3-3、-4-1、-4-2 にもとづいて開発しているメーカー	6章(プロセス)、8章(製品)

どちらのルートでも、ISO 12100 によるリスクアセスメント、4章(改ざんからの保護の基本)、9章(取扱説明書)は共通で必要です。規格案は、どちらを選んでもよく、手間や価値、社内の知識、用途で決めればよいとしています。

アプローチBを簡単に紹介しておきます。プロセスは IEC 62443-4-1(セキュアな製品開発ライフサイクル)に従い、製品は IEC 62443-3-3(機械システム)と IEC 62443-4-2(機械部品)から、安全機能に関係する一部の要求だけを選んで適用するルートです。すでに IEC 62443 の体制を持つ制御機器メーカーやシステムインテグレーター向けです。この記事では、多くの機械メーカーに関係するアプローチAを中心に解説し、アプローチBの詳細は割愛します。

なお、この規格は機械の設計者、制御システムのメーカー、システムインテグレーターに向けたものです。機械を使う側(ユーザー)の役割は扱っていません。

4. 適用範囲と用語

4.1 何が対象になるのか(1章)

対象は、機械、関連製品、半完成機械です(規格案ではまとめて「機械」と呼びます)。そのうえで、次のものが機械の安全に影響しうる場合に対象になります。

対象となるライフサイクルは、開発、製造、立ち上げ、運転、保守、廃棄のすべてです。

一方で、次のものは対象外です。

4.2 「接続」はとても広い(4.2)

機械規則 1.1.9 の「他の装置との接続」について、規格案は「情報をやりとりできるあらゆるつながり」と広くとらえています。物理的なもの、論理的なもの、間接的なものを含みます。例として挙がっているのは次のとおりです。

常設の機器だけでなく、据付や保守のときに一時的に持ち込むパソコンなども含まれます。反対に、接続の可能性がまったくない単純なボール盤は、検討の必要がない例として挙げられています。

4.3 押さえておきたい用語(3章)

用語	意味(かみ砕いた説明)
改ざん(corruption)	偶発的または不正な、機械データの変更で、危険な状況につながりうるもの
介入(intervention)	ソフトウェアやデータを変え、機械のふるまいや状態を一時的・恒久的に変える行為や出来事。正当なものも不正なものも含む
変更(modification)	介入によって生じた変化(ソフトのバージョン、センサの校正値、設定データなど)
証拠(evidence)	何かが起きたことを検知できるもの。ログだけでなく、破れた封印シール、引っかき傷、RJ45 カバーの損傷なども含む
トレースログ(tracing log)	安全関連の制御システムに影響する介入を記録したデータの集まり
重要データ(critical data)	書き換えられると危険が増すデータ
脆弱性(vulnerability)	設計、実装、運用・管理の欠陥や弱点で、システムの完全性を損なうために悪用されうるもの
セキュリティコンテキスト(security context)	機械が使われる環境が、機械に与えてくれるセキュリティ。安全分野の「意図する使用」に相当する考え方
対策(countermeasure)	脅威や脆弱性、攻撃の影響を減らす処置、装置、手順、技術
補完的対策(compensating countermeasure)	機器自身のセキュリティ機能の代わりに、または追加で使う対策(例:外付けのファイアウォール)
合理的に実行可能(reasonably practicable)	リスク低減と、時間・費用・労力とのバランス
SRASW	安全関連アプリケーションソフトウェア。機械メーカーが書く、その機械固有の安全プログラム(ISO 13849-1:2023 の定義を引用)
SRESW	安全関連組込みソフトウェア。部品メーカーが組み込んで提供し、エンドユーザーが変更することを想定していないソフト(安全PLC のファームウェアなど)
SRSL	個々の安全機能を改ざんから守るためのセキュリティ要求の強さを表すレベル

「介入」には少し注意が必要です。規格案では、安全ゲートを開けるといった通常の運転操作は介入に当たらないとしています。また、モジュール式 PLC のユニットを同じ型式の予備品に交換するのは介入ではなく、ユニットを追加すると「変更」になる、という例も示されています。

もうひとつ小さな注意点です。SRSL は、3章の定義では「Safety-Related Security Requirement」と書かれていますが、7.4.2 では「Safety-related security level」と書かれています。照会用ドラフトの表記ゆれと思われます。この記事では、中身に合わせて「レベル」として説明します。

5. 全体の進め方(4.3 と 図1)

5.1 3つの原則:なくす → 抑える → 伝える

4.3 では、脅威から機械を守るための原則が3段階で示されています。ISO 12100 の「3ステップメソッド(本質的安全設計 → 安全防護 → 使用上の情報)」とよく似た考え方なので、機械安全に慣れた方にはなじみやすいと思います。

この3段階は、ISO/TR 22100-4 がすでに2018年に「ISO 12100 にもとづく優先順位」として推奨していたものです。prEN 50742 では、これが「しなければならない」という要求になりました。

さらに、次の2点も「しなければならない」とされています。

なお、脅威の評価(脅威アセスメント)は、後で説明する最低限のセキュリティ対策でカバーされない脅威だけに絞ってもよい、とされています。

5.2 リスクアセスメントの流れ(図1)

規格案の図1は、安全とセキュリティをあわせたリスクアセスメントの流れを示しています。私なりに文章に直すと、次のとおりです。

ポイントは、(0)の安全方策がすべての出発点になっていることです。「守るべきものは、ISO 12100 で決めた安全方策そのもの」という構造がよくわかります。

6. SRSL の決め方(7.4.2 と 附属書B)

アプローチAの中心になるのが SRSL(安全関連セキュリティレベル) です。SRSL は0〜3の4段階で、数字が大きいほど求められる対策が厳しくなります。

SRSL は機械全体で1つ決めるのではありません。安全機能ごと、接続口(インターフェース)ごとに決めて、文書に残します。たとえば「ガードインターロックによる停止」と「非常停止」では、関係する接続口が違えば SRSL も変わりえます。

6.1 SRSL の4つのレベル(表2)

SRSL	どんなときに選ぶか(要約)
SRSL0	安全システムが完全に隔離されている。機械内部だけの閉じたネットワーク、外部への接続口がない安全機能など
SRSL1	攻撃ポテンシャルが低く、ごく限られた条件でしか攻撃が成り立たない。危害が元に戻るもの(可逆)なら、中程度の攻撃ポテンシャルでも選べる
SRSL2	攻撃ポテンシャルが中程度で、攻撃が起こりうる。危害が可逆なら、高い攻撃ポテンシャルでも選べる
SRSL3	攻撃ポテンシャルが高い〜非常に高い。攻撃がほぼ確実に起こる。インターネットなど信頼できないネットワークにつながる場合など

6.2 SRSL は「危害の重大さ」×「攻撃ポテンシャル」で決まる

SRSL は2つの要素の組み合わせで決まります。

危害の重大さについて、規格案の注記には「ISO 13849-1 の PLr(要求パフォーマンスレベル)を使って表してもよい」とあります。安全のリスクアセスメントはすでに済んでいるので、その結果を使い回せる、という考え方です。ただし、PLr のどこで「低い/高い」を分けるかまでは書かれていません。私は、ISO 13849-1 のリスクグラフの S1(軽傷、通常は回復可能)/S2(重傷、通常は回復不能・死亡)と対応させるのが自然だと考えています(これは私の解釈です)。

6.3 攻撃ポテンシャルを決める3つの要素

(1)露出レベル EL:接続口がどれくらい外に開いているか

接続口ごとに決める、静的な(変わらない)指標です。

EL	種類	イメージ	点数
EL0	内部	鍵や工具がないと外から触れない、機械内部の部品やネットワーク	0
EL1	物理	機械に直接触れないと使えない接続口。機械についている RJ45、USB、表示器、ボタンなど	2
EL2	ローカル	機械どうしをつなぐ産業用ネットワークやフィールドバス(パデューモデルのレベル2相当、SCADA による監視制御など)	5
EL3	隣接	構内に限られた、工場全体の産業用ネットワーク。OT と IT の境目(パデューモデルのレベル3相当)	16
EL4	公衆	インターネットなど、信頼できないネットワークとの遠隔接続	24

EL2(5点)と EL3(16点)の間で点数が大きく跳ね上がっていることに注目してください。工場ネットワークにつながるかどうかが、評価を大きく左右します。

また、接続が「信頼の境界(トラストバウンダリ)」をまたぐ場合は、高いほうの EL を使います。たとえば EL1 と EL2 をつなぐ接続は EL2 として扱います。安全に関わるネットワーク部分とそうでない部分を分ける(セグメンテーション)ことが、EL を下げる有効な手段だとされています。

EL を下げる工夫を考えるときは、ISO/TR 22100-4 の「5つの問い」(つなぐ必要はあるか、常時か、監視されているか、許可された人だけか、読み取り専用にできるか)が役に立ちます。9.4 で詳しく紹介します。

(2)攻撃者の能力 AC:攻撃に必要な知識と技能

必要な知識・技能	攻撃者の例	点数
広範な知識と高度な技能(製品仕様やシステム構成まで深く知っている)	悪意ある特権ユーザー、高度に訓練されたハッカー	1
中程度の知識と専門的な技能	機密情報に近い、訓練を受けた技術者やハッカー	2
中程度の知識と中級の技能(一般的な攻撃ツールと公開情報を使う)	腕のいいハッカー	3
最小限の知識と基本的な技能	「スクリプトキディ」と呼ばれる素人ハッカー	4

私はこれを、「その弱点を突くのに必要な技能」と読むとすっきりすると考えています。素人でも突ける弱点なら、攻撃できる人が多いので、起こりやすさは高くなる。高度な専門家でないと突けない弱点なら、起こりやすさは低くなる。そう考えると、点数の向きに納得がいきます。規格案の計算例も「弱点を突くのに必要なのは最小限の知識と基本的な技能」として4点を使っています。

なお、メーカー内部からの機密漏えいなど大きな事件で攻撃者の知識が一気に増えた場合は、量産中の機械について評価を見直すべきだ、とされています。

(3)機会の窓 WoO:攻撃できる時間や機会がどれくらいあるか

こちらは接続口ごとではなく、機械全体について、セキュリティコンテキストにもとづいて決めます。保守作業の頻度や、その予測のしやすさで変わります。

機会の窓	イメージ	係数
非常に限定的	めったに触れない、または常時監視されている	0.6
やや限定的	月1回の保守のように、時期が予測でき、中程度のアクセス管理がある	0.8
限定的	毎週・毎日の定期的なアクセスがあり、アクセス管理が緩い	0.9
無制限	いつでも、頻繁に、自由にアクセスできる	1.0

6.4 計算式

攻撃ポテンシャルは、次の式で計算します。

$$AP = (EL \times WoO) + AC$$

計算した点数は、次の5段階に区分します。

AP の点数	区分	意味
0〜5	AP0(非常に低い)	攻撃はまず起こらない
5.1〜10	AP1(低い)	ごく限られた条件でのみ起こりうる
10.1〜15	AP2(中程度)	起こる可能性が十分にある
15.1〜20	AP3(高い)	起こる可能性が高い
20超	AP4(非常に高い)	ほぼ確実に起こる

6.5 SRSL への割り当て(表B.6)

危害の重大さ	AP0	AP1	AP2	AP3	AP4
低い(可逆的)	SRSL0	SRSL1	SRSL1	SRSL2	SRSL3
高い(不可逆的)	SRSL0	SRSL1	SRSL2	SRSL3	SRSL3

6.6 計算例

規格案の例(図B.1の機械)

表B.6 にあてはめると、危害の重大さが低くても高くても SRSL1 になります(規格案の例は AP の区分までで止まっているので、SRSL への当てはめは私が補いました)。

インターネット経由のリモート保守(EL4)

6.7 EL ごとの「SRSL の目安」

式と表から逆算すると、EL ごとにとりうる SRSL の範囲がわかります。設計の初期段階で、ネットワーク構成を考えるときの目安になります(私が計算したもので、規格案の表ではありません)。

EL	AP の範囲	とりうる SRSL
EL0(内部)	1〜4(AP0)	SRSL0
EL1(物理)	2.2〜6(AP0〜AP1)	SRSL0〜1
EL2(ローカル)	4〜9(AP0〜AP1)	SRSL0〜1
EL3(隣接)	10.6〜20(AP2〜AP3)	SRSL1〜3
EL4(公衆)	15.4〜28(AP3〜AP4)	SRSL2〜3

この表から、2つのことが読み取れます。

なお、表2では SRSL0 を「完全に隔離された安全システム」用としています。一方、計算上は EL1 や EL2 でも SRSL0 になる組み合わせがあります。照会用ドラフト内での整合がとれていない部分なので、最終版でどう整理されたかを確認しておきたいところです。

7. SRSL ごとの要求事項(7.4.3)

SRSL が決まったら、そのレベルに応じた最低限の要求事項を満たします。要求事項は、その安全機能と、関係する接続口に適用されます。接続口には、USB や RJ45 といった「物理的な接続口」だけでなく、Modbus/TCP や Webサーバーのような「論理的な接続口」も含まれます。

SRSL0 には追加の要求はありません。SRSL1〜3 の要求を、項目ごとに一覧にしました。

項目	SRSL1	SRSL2	SRSL3
認証(誰・何がアクセスしているか確かめる)	認証する	認証する	一意に認証する(1人ひとり、1台ずつ区別する)
認可(何をしてよいか制限する)	介入には許可が必要	介入には許可が必要	権限を細かく分けた許可が必要(例:役割ごとのアクセス制御)
ソフトウェアと重要情報の完全性	起動時に確認(例:チェックサム)	起動時と定期的に確認(例:チェックサム)	起動時と運転中に定期的に、暗号技術で確認(例:暗号ハッシュ、HMAC、CMAC)
起動プロセスの完全性	保護し、起動時に確認(例:チェックサム)	保護し、起動時に確認	セキュアブート(信頼の起点を使った電子署名の確認。失敗したら元に戻すか安全状態へ)
やりとりする情報の完全性	確認する	確認する	暗号プロトコルで保証し、改変されたメッセージや再送攻撃のメッセージを検知して破棄する
入力データの検証	決めた範囲内かを確認し、不正な入力は破棄	構文、意味、形式、データ型まで厳密に確認し、不正な入力は破棄	状況に応じた厳密な確認(構文、意味、範囲、プロトコル固有の制約)。不正な入力は破棄
物理的な改ざん	検知する(例:封印シールの破れ)	同左	同左
SRESW/SRASW と重要な設定データの真正性	要求なし	インストール時に確認(例:電子署名など)	インストール時に電子署名などで確認

7.1 表を読むときのポイント

「認証」の対象は人だけではありません。

規格案の注記では、人のユーザーに加えて、ソフトウェアのプロセスや、介入できる機器も含むとしています。認証の手段としては、パスワード、PIN、ドングル、生体認証、証明書、RFID、NFC、UID などの識別子、TLS ハンドシェイクのような暗号的な仕組みが例に挙がっています。

SRSL1 と SRSL2 の差は、意外と小さい。

認証と認可は同じ文言です。違いが出るのは、完全性の確認のタイミング(起動時だけか、定期的にもか)、入力データ検証の厳しさ、そして真正性(電子署名など)の確認の有無です。

SRSL3 で一気に「暗号」が前に出る。

暗号ハッシュ、セキュアブート、暗号プロトコル、個別認証、役割ごとのアクセス制御と、IT セキュリティらしい対策が並びます。前の章で見たとおり、SRSL3 はインターネットや工場ネットワークにつながる場合に出てくるレベルです。逆に言えば、安全機能をそうしたネットワークから切り離しておけば、SRSL3 の対策は必要になりにくい、ということです。

物理的な改ざんの検知は、SRSL1 以上で共通。

封印シールのような、昔ながらの方法でもよいとされています。機械安全の現場では取り入れやすい対策ですね。

7.2 「共通パスワード 1234」は通用するか

よくいただく質問です。規格案の SRSL1〜2 の文言は「認証する」で、パスワードの強さまでは決めていません。ただし、附属書C・D の脅威分析では「パスワードが社員の間で管理されずに共有される」「総当たりで破られる」ことが脅威として挙がっています。また、取扱説明書でパスワードの複雑さや長さを求めることも、セキュリティコンテキストの例に出てきます。

「1234」を全員で共有するやり方では、脅威分析の説明が苦しくなるのは確かです。少なくとも、初期パスワードの変更を求める、役割ごとにパスワードを分ける、といった対策は考えておきたいところです。

8. SRSL に関係なく必要な要求(7.1〜7.3、7.5)

アプローチAでは、SRSL のレベルにかかわらず満たす要求もあります。特にログ(証拠の記録)は、機械規則 1.1.9 と 1.2.1 f) に直結する大事な部分です。

8.1 接続口を洗い出して守る(7.1)

人が触れることができ、機械の安全に影響しうる接続口は、すべて特定し、対策または補完的対策で守る必要があります。規格案の図2では、攻撃を受けうる接続口の例として、次のようなものが挙がっています。

8.2 対策の選び方と暗号(7.2)

セキュリティ対策は、リスクにもとづいて選びます。そのとき、安全上のリスクと脅威のリスクの両方を、意図する使用とセキュリティコンテキストに照らして考えます。そして何度も出てきますが、対策が機能安全を損なってはなりません。

暗号を使う場合は、最新の(state of the art)アルゴリズムを選ぶよう推奨されています。参考として、欧州ネットワーク情報セキュリティ機関(ENISA)や、ドイツ連邦情報セキュリティ庁(BSI)の技術指針 TR-02102-1 などが参考文献に挙がっています。

8.3 ログで残すべき「介入」(7.3.1)

ログに残すことを考えるべき介入の種類は、次の5つです。

一方で、次のものは記録しなくてよいとされています。

8.4 ログに最低限入れる中身(7.3.2)

タイムスタンプは、記録する機器自身がつけても、外部のログ収集装置がつけてもかまいません。

8.5 ログの取り方(7.3.3)

ログの保存場所は、制御システムの中、機械の中の部品、機械の外の記録装置(NAS やハードディスクなど)のいずれでもよいとされています。ログ形式の参考として、附属書A に Syslog(RFC 5424)、Common Log Format、W3C 拡張ログ形式、Common Event Format、BSI の最低基準が紹介されています。

8.6 保存期間(7.3.4)

5年というのは、機械規則 1.2.1 f) の「アップロードから5年間」と対応しています。PLC の内部メモリだけで5年分を持つのは難しい場合も多いので、SD カードや外部の記録装置の使い方を、設計の早い段階で決めておきたいところです。

8.7 ログの保護(7.3.5)

照会用ドラフトでは、特定の技術(書き換え不可能な記録媒体など)までは指定していません。

8.8 ソフトウェアのバージョンと設定の確認(7.5)

改ざん防止に関係するソフトウェアのバージョンと設定の情報は、求められたらすぐ確認できるようにします。人が読める形で、機械に組み込んだ仕組みか、外部ツールで表示できれば OK です。外部ツールの例として、一般に手に入るアプリを入れたノートパソコンやスマートフォンが挙がっています。

9. ISO/TR 22100-4 との関係:2018年の指針から規格案へ

ISO/TR 22100-4:2018 は、ISO/TC 199(機械類の安全性)が2018年12月に発行した技術報告書です。機械メーカー向けに、安全に影響しうる IT セキュリティの考え方を示しています。prEN 50742 より7年も前に、同じ問題に取り組んだ文書です。

ただし性格はかなり違います。ISO/TR 22100-4 は「指針」で、具体的な仕様は示していません。prEN 50742 は「要求」を定める規格案です。prEN 50742 は ISO/TR 22100-4 を引用していませんが、読み比べると、考え方の多くが受け継がれていることがわかります。

9.1 2018年当時の法的な立ち位置

ISO/TR 22100-4 は、当時の機械指令(2006/42/EC)と ISO 12100 の範囲を、次のように整理していました。

つまり2018年の時点では、セキュリティは「法的義務ではないが、考えておくべきこと」でした。機械規則 1.1.9 は、これを法的な義務に格上げしました。prEN 50742 が「狙われる確率は評価に使わない」としているのも、攻撃を「起こるかもしれない例外」ではなく「備えるべき前提」として扱う、という姿勢の表れだと私は読んでいます。

もうひとつの違いは、うっかりミスの扱いです。ISO/TR 22100-4 は、パラメータ設定時の人為的なミスは通常の安全リスクアセスメント(ISO 12100 の 6.2.11.1)でカバー済みとして、セキュリティの話から外していました。機械規則と prEN 50742 は、偶発的な変更も「改ざん」に含めて、まとめて扱います。

9.2 安全とセキュリティは、ここが違う

ISO/TR 22100-4 の表1は、機械安全と IT セキュリティの違いを4つの観点で整理しています。私の言葉でまとめると、次のとおりです。

観点	機械安全	IT セキュリティ
目的	けがや事故を防ぐ	可用性・完全性・機密性を守る
条件の見えやすさ	危険源も対策も目に見える	外から見えにくく、ユーザーとも共有されにくい
変化の速さ	比較的変わらない(意図する使用、予見可能な誤使用)	常に変わる「動く標的」(故意の操作、犯罪の意図)
誰がいつ対策するか	主にメーカーが、出荷時に	メーカー、インテグレーター、ユーザー、サービス会社が、ライフサイクル全体で

リスクの要素も違います。安全のリスクは「危害のひどさ」と「発生確率(暴露、危険事象の発生、回避の可能性)」で決まります。セキュリティのリスクは「起こりうる悪影響」と「脆弱性を突かれる起こりやすさ」で決まります。

prEN 50742 の SRSL は、まさにこの2つを結びつけたものです。「危害の重大さ(安全側)」と「攻撃ポテンシャル(セキュリティ側)」の組み合わせで決めるからです。ISO/TR 22100-4 が「2つのリスクアセスメントははっきり分けて考えるべき」と述べた問題に、prEN 50742 が具体的なつなぎ方を示した、と言えます。

9.3 2つの文書の比較

項目	ISO/TR 22100-4:2018	prEN 50742(照会用ドラフト)
文書の性格	技術報告書(指針)	整合規格を目指す欧州規格案(要求)
進める順番	まず ISO 12100 の安全リスクアセスメント。その結果の保護方策を、脆弱性の観点で分析	同じ(図1)
対策の優先順位	設計で除く → 対策で抑える → 残留リスクと必要な対策をユーザーに伝える	同じ3原則を「しなければならない」として規定
起こりやすさの考え方	攻撃の動機を4つに分けて、安全との関係の強さを整理	狙われる確率は使わない。攻撃ポテンシャル(EL・AC・WoO)で評価
接続の評価	5つの問い(9.4参照)	露出レベル EL0〜4と、機会の窓 WoO
対策の水準	対策の例を挙げるのみ	SRSL0〜3 で段階的に要求
攻撃の検知	特定・防御・検知・対応・復旧の5ステップ	介入の証拠(ログ)を自動で記録し、5年間保存
役割分担	メーカー・インテグレーター・ユーザーの分担表	ユーザーの役割は扱わない。セキュリティコンテキストと取扱説明書で伝える
物理的な操作	物理的な操作による無効化は対象外	物理的な改ざんの検知を SRSL1 以上で要求
うっかりミス	ISO 12100 でカバー済みとして対象外	改ざんに含めて扱う

9.4 接続についての「5つの問い」

ISO/TR 22100-4 は、IT セキュリティの脅威は「外部の IT システムにつながるかどうか、どれくらいの頻度でつながるか」に大きく左右される、として、次の5つの問いを挙げています。prEN 50742 のどこにつながるかを並べてみました。

ISO/TR 22100-4 の問い	prEN 50742 でいうと
1. そもそも、つなぐ必要があるか	脆弱性を「なくす」(4.3 a))。不要な接続口をなくせば EL0
2. ずっとつないでおく必要があるか	機会の窓 WoO。使わないときは電源を切る、など
3. 接続は監視されているか(VPN など)	EL を下げる、ネットワークを分ける。附属書D の対策
4. 許可された人だけが設定できるか	SRSL ごとの認証・認可の要求(7.4.3)
5. 読み取り専用にできるか	データを変えない操作は「介入」にならない。認可で書き込みを制限する

そして ISO/TR 22100-4 は、外部の IT システムと直接にも間接にもつながらない機械は、IT セキュリティ攻撃に対して脆弱ではないとみなせる、としています。prEN 50742 で、接続のない単純なボール盤が検討不要の例として挙がっているのと同じ考え方です。

この5つの問いは、設計の打合せでそのまま使えます。SRSL の計算を始める前に、まずこの問いで接続を減らすのが近道です。

9.5 攻撃の「動機」で見る4つのケース

ISO/TR 22100-4 の表2は、攻撃の動機を4つに分けています。

ケース	攻撃の目的	安全との関係
1	メーカーやユーザーのノウハウを盗む	なし
2	ユーザーに経済的な損害を与える	可能性は低いが、ありうる
3	機械や人に危険を生じさせる	可能性は低いが、ありうる
4	インフラや人に被害を与える(テロなど)	高い

どのケースでも、攻撃は隠れたままで、成功した後でも見つけにくいとされています。また、発電や水道といった重要インフラの設備は、ケース4のリスクがとくに高いとされています。

prEN 50742 の STRIDE 分析で、情報漏えい(ケース1に相当)が「おそらく対象外」とされているのは、この整理とよく合っています。一方で、prEN 50742 は「狙われやすさ」で評価を下げることを認めていません。ISO/TR 22100-4 の表2は、どの脅威を安全の観点で深掘りするかを選ぶ「入口」として使い、評価そのものは prEN 50742 の攻撃ポテンシャルで行う、という使い分けがよいと考えています。

9.6 だれが何をするか(役割分担)

prEN 50742 は、ユーザーの役割を扱っていません。ここを補ってくれるのが、ISO/TR 22100-4 の表3です。対策ごとに、メーカー、インテグレーター、ユーザーのだれが担うかを例示しています(契約によって分担は変わりうる、とも書かれています)。要点をまとめます。

メーカー・インテグレーター・ユーザーの全員

• 安全に関わる IT システムを、全体の IT システムから物理的に分ける
• ファイアウォールやウイルス対策ソフトで守る
• USB や LAN の差込口を物理的に制限する、使わないものは外すか無効にする
• 部品メーカーの取扱説明書に従う(接続口の使い方、接続が必要な時期と時間、初期パスワードの変更など)

メーカー・インテグレーター

• ソフトウェアを更新できる手段を用意する
• カードリーダーや物理的な鍵など、独立した認証の仕組みを用意する
• 複数の独立した層からなるネットワーク構成にする
• 重大な攻撃を受けたときに、非常停止ボタンなどハードウェアで安全状態にできるようにする
• 故障した IT 部品や使えなくなったサービスを検知できるようにする
• リモート保守では、セッションの開始・終了の手段、暗号化、時間や人を限った受付を用意する

ユーザー

• ウイルス対策ソフトなどを最新の状態に保つ
• 権限を役割に必要な範囲に絞る
• 使わない接続口やサービスを止める
• 個人ごとのアカウントとパスワードを管理する
• リモート保守のセッションを見守り、時間を限る
• 新しい脆弱性に対応する

リモート保守について、ISO/TR 22100-4 は次の2つも挙げています。

• 機械側の操作を、リモートからの指令より優先させる
• リモートからすり抜けられないよう、ソフトウェアに頼らない手段を用意する

prEN 50742 にはこの書き方はありませんが、機械安全の設計としてとても大事な考え方です。たとえば、非常停止や保護ガードのインターロックをハードワイヤードの安全回路で構成しておけば、ネットワーク越しの改ざんで無効にされることはありません。これは SRSL の評価で「その安全機能は外部との接続口を持たない」と言える根拠にもなります。

9.7 取扱説明書に書くことの比較

ISO/TR 22100-4(10.4)	prEN 50742(9章)
部品メーカーからの情報:接続口の使い方、接続が必要なライフサイクルの段階、接続の時間、指定のインターフェース、アプリケーションソフトへのアクセス制限	セキュリティコンテキスト
セキュリティ手順を守るための、従業員の教育と再教育	安全機能に関係するソフトウェアのバージョンと設定
使用中の IT セキュリティの扱い方(アクセス制限、インシデントの検知と対応、リモート保守の方法)	バージョンと設定、その変更履歴の確認方法
	変更してよいこと・いけないこと

prEN 50742 の4項目は最低限の要求です。ISO/TR 22100-4 の項目、特に従業員教育やリモート保守の手順は、セキュリティコンテキストの中身を具体的にするときの良いチェックリストになります。

9.8 2つの文書の使い分け

なお、ISO/TR 22100-4 の法的な整理(故意の攻撃は安全法規の範囲外)は、機械指令の時代のものです。機械規則のもとでは、そのまま当てはまらない点に注意してください。

10. 取扱説明書に書くこと(9章と 附属書C.5)

9章は、アプローチA・Bのどちらでも共通の要求です。取扱説明書(使用上の情報)には、次の4つを入れます。

10.1 セキュリティコンテキストに何を書くか

附属書C.5 では、セキュリティコンテキストを「安全分野でいう『意図する使用』のセキュリティ版」と説明しています。機械がどんな環境で、どんな前提のもとで使われるかを決めて書くものです。書くべき前提の例は次のとおりです。

前提の種類	書く内容の例
物理的・論理的なアクセス管理	誰でも触れるのか、許可された人だけか、サービス技術者だけか
意図する使用と予見可能な誤使用	リモート診断の接続を、常時つないだまま監視に使うことがありうるか
物理的な環境	屋外(農場、林業、建設現場)、公共の建物、交通機関、入場管理のある工場や倉庫など。鍵付きの盤か、共通鍵か専用鍵か、固定か移動式か
論理的な環境	VPN 経由のアクセスに限るか、常時接続かその都度か、ファイアウォールが必要か、すべてのネットワーク接続の一覧、配線の敷き方
方針と手順	パスワードの複雑さや長さの決まりなど

セキュリティコンテキストで書いた前提が守られている間だけ、その前提で見込んだ対策が有効になります。つまり、ユーザーにお願いすることを、はっきり書いておくことが大事です。前に紹介した「フィールドバスは信頼できるネットワーク内だけで使うこと」という書き方が、その典型例です。

ユーザーにお願いすることを書くときは、ISO/TR 22100-4 の役割分担表(9.6)が参考になります。ユーザー側でやってもらうこと(パスワード管理、使わない接続口を止める、リモート保守の見守りなど)を、セキュリティコンテキストに書き出しておくと、抜けが少なくなります。

規格案の例1(縦型の充填包装機)では、たとえば次のような前提が書かれています。

• 入場管理のある工場内で使い、許可された人しか機械に近づけない
• PLC は専用鍵付きの盤に入っていて、鍵は許可された人だけが持つ
• 設定用の接続は、保守やトラブル対応のときだけ一時的に使う
• リモート接続は、直接の LAN ケーブルか VPN などの安全な手段に限り、使わないときは電源を切っておく

11. 附属書C・D:脅威モデリングの実例

附属書C(参考)は、規格案の中でいちばんページ数が多い部分です。実際にどうやって脅威を洗い出し、対策を選ぶかを、2つの機械の例で示しています。附属書D は、脅威の種類と対策のカタログです。

11.1 作業の流れ(図C.1)

1. 分析するシステムを定める:
   守るべき資産(アセット)を決める → セキュリティコンテキストを決める → データフロー図を描く → 信頼の境界を引く
2. 脅威のリスクアセスメント:
   附属書B の方法で SRSL を決め、7.4 の最低限の要求(ベースライン対策)を当てはめる
3. 脅威モデリング:
   STRIDE などの手法で脅威を洗い出す
4. 追加の対策:
   見つかった脅威のリスクを評価し、対策を割り当てる

STRIDE は例として使われているだけで、他の脅威分析の手法を使ってもかまいません。

11.2 守るべき資産の例(C.4)

例1(縦型充填包装機)では、次のものが安全に関わる資産として挙がっています。

• 安全設定データ
• 安全関連アプリケーションソフトウェア(SRASW)
• 設定を保存するメモリ(安全PLC の SD カードなど)
• 安全関連組込みソフトウェア(安全機器のファームウェア)
• 安全通信(安全バスや安全無線)のプロセスデータ
• 出力のシミュレーションなどができる「エンジニアリングモード」の切替スイッチ
• 機械の危険源ごとに決めた安全機能そのもの

エンジニアリングモードの切替スイッチが資産に入っているのは、現場目線でとても大事な指摘だと思います。

11.3 STRIDE とは

STRIDE は、脅威を6種類に分けて、もれなく洗い出すための考え方です。規格案での扱いとあわせて整理します。

頭文字	脅威の種類	何が損なわれるか	規格案での扱い
S	なりすまし(Spoofing)	認証	対象。例:安全通信の相手になりすます、センサデータの再送攻撃、管理者として設定画面にログインする
T	改ざん(Tampering)	完全性	対象。例:安全パラメータやファームウェアの書き換え、通信途中での書き換え、非常停止スイッチの無効化
R	否認(Repudiation)	説明責任	対象。例:安全設定の変更ログを消す・書き換える
I	情報漏えい(Information Disclosure)	機密性	安全性が変わらない限り、おそらく対象外
D	サービス妨害(Denial of Service)	可用性	安全性が変わらない限り、おそらく対象外
E	権限昇格(Elevation of Privilege)	認可	安全性が変わらない限り、おそらく対象外

11.4 例1:縦型充填包装機

安全PLC とモーターで構成された、屋内の工場で使う単純な機械です。安全機能は、包装機の規格 EN 415-3 から引用されています(インターロックガードを開けたらシール・カット機構を止める、非常停止ですべての危険な工程を止める、など)。

接続口ごとに STRIDE を当てはめた結果(表C.1、表C.3)から、特に参考になる判断をいくつか紹介します。

ただし、規格案は重要な注意も添えています。安全状態が、いつも安全とは限りません。 たとえば、工程を間違ったタイミングで止めると熱がこもって火災になる、といったケースです。こうした判断は、機械ごとに検討する必要があります。

11.5 例2:無線リモコン付きのトラック搭載クレーン

屋外の駐車場や道路脇、建設現場など、誰でも近づける場所で使う機械の例です。物理的なアクセス管理がゆるく、無線という弱点になりやすい接続口がある場合に、脅威モデルがどう変わるかを示しています。

なお、無線リモコンの規格(IEC 62745 など)は偶発的なデータの化けへの対策は求めていますが、なりすましや改ざんといった悪意のある攻撃はカバーしていない、という指摘があります。リモコンを買ってきて組み込むメーカーは、その使い方が正しいかを自分で確認する必要がある、ということです。

11.6 附属書D:脅威と対策のカタログ

附属書D には、攻撃の前提条件(TPID)と脅威の種類(TTID)ごとに、対策の候補が並んでいます。機械設計者にもなじみやすい対策の例をいくつか挙げます。

なお、例3(安全センサ)と例4(STO 機能付きの安全機器)は「将来の改訂で検討」となっていて、中身はまだありません。

12. 附属書ZZ:機械規則のどの要求をカバーするか

附属書ZZ は、規格のどの箇条が、機械規則 附属書III のどの必須要求に対応するかを示した表です。整合規格として官報に載れば、この表の範囲で「適合の推定」が得られます。

機械規則 附属書III の要求	対応する prEN 50742 の箇条
1.1.9 改ざんからの保護	4.3、7.1、7.2.1、7.3.2、7.3.3、7.3.4、7.4.2、7.4.3、7.5、8.3、9
1.2.1 第2段落 a)(外部からの影響への耐性)	4.3、7.1、7.2.1、7.4.2、7.4.3
1.2.1 第2段落 f)(介入の記録)	7.3.2、7.3.3、7.3.4、7.5、8.3、8.4

この表を見て、私が気になった点が2つあります。

1. ログの保護(7.3.5)が表に入っていません。
   ログを改ざんから守る要求は本文にあるのに、対応表には挙がっていません。照会用ドラフトの段階での抜けなのか、意図的なのかは、最終版で確認したいところです。
2. アプローチBのプロセス(6章)や 8.2(機械システム)も表に出てきません。
   アプローチBを選ぶ場合に、どの範囲で適合の推定が得られるのかは、最終版の附属書ZZ を必ず確認してください。

また、附属書ZZ の注意書きにもあるとおり、機械には CRA など他の EU 法令も適用されることがあります。prEN 50742 に適合すれば、サイバーセキュリティのすべてが片づく、というわけではありません。

13. 旧版記事からの主な訂正点

初版を書いた時点では、規格案の本文を確認できていませんでした。照会用ドラフトと照らし合わせた結果、次の点を訂正します。初版を参考にされていた方は、ご確認ください。

項目	旧版の記述	規格案(照会用ドラフト)の内容
公開とコメント期間	2026年1月15日公開、2月15日までコメント募集。最短で2026年3月発行	ドラフトの日付は2025年12月。CENELEC の照会締め切りは2026年2月27日。その後、2026年7月に最終案が作られ正式投票中
進め方	5段階のワークフロー(リスクアセスメント → コンテキスト → 脅威分析 → SRSL → 対策)	図1のフロー(0、1.A〜1.D、2.A〜2.C)。大筋は近いが、「なくす → 抑える → 伝える」の順番と、対策が安全機能に悪影響を与えないかの確認が組み込まれている
SRSL を決める単位	安全機能またはゾーンごと	安全機能ごと、かつ接続口ごと
SRSL ごとの対策	SRSL1:ウイルス対策の基本設定、SRSL2:侵入検知・ログ監視・セグメンテーション、SRSL3:多要素認証・CSIRT 連携など	これらは規格案にない。実際は認証、認可、完全性、物理的改ざん検知、真正性の5分野で段階的に要求(この記事の7章)
多要素認証	SRSL3 で必要	規格案に多要素認証の要求はない。SRSL3 は「一意な認証」と「役割ごとのアクセス制御などの権限分け」
通信の暗号化	リモート保守では VPN や TLS が必須(SRSL3)。平文の安全関連通信は許容されない	規格案にこの書き方はない。SRSL3 で、改変や再送を検知・破棄できる暗号プロトコルで情報の完全性を保証することを要求
SRSL 決定のパラメータ	露出度・攻撃者能力を1/3/5点で評価(仮定)	EL は0/2/5/16/24点、AC は1〜4点(必要な技能が低いほど高い点)、WoO は0.6〜1.0の係数。AP=(EL×WoO)+AC で計算
ログの保護	管理者でも削除・修正できない形式(WORM など)か、外部サーバーへ即時転送	改ざんから適切に守ること、削除は許可された手順でのみ。特定の技術の指定はない
ログの中身	誰が(ユーザーID)、いつ、何を	最低限は「介入の種類」「前後関係がわかる情報(タイムスタンプなど)」「ログの削除」。ユーザーID は最低限の項目に入っていない
アプローチB	SRSL と SL のマッピング表が存在。PKI、SIEM 連携などの高度な対策	マッピング表はない。IEC 62443-4-1 のプロセスと、62443-3-3/4-2 から選んだ一部の要求(主に SL-C2、一部 SL-C1)を適用
SRESW	IEC 62443-4-1/4-2 に準拠した開発が期待される	アプローチAにその要求はない。62443-4-2 への適合は、アプローチBの機械部品の要求
ソフトウェアの分類	IEC 62061 と同様に分類	SRASW・SRESW の定義は ISO 13849-1:2023 から引用
関連文書	ISO/TR 22100-4 が前身。改訂 ISO 12100 が prEN 50742 を参照する構造	規格案にはどちらの記述もない(ISO/TR 22100-4 と考え方が共通する点は9章で整理)。引用規格は EN ISO 12100:2010 と EN IEC 62443 の3部

あわせて、初版にあった部品メーカー各社の認証取得状況や、自己進化型 AI についての記述は、規格案の内容ではないため削除しました。

14. まとめと、今からできる準備

prEN 50742 の照会用ドラフトを読んで、私がいちばん強く感じたのは、「機械安全の延長線上にある規格」だということです。

「サイバーセキュリティ」と聞くと身構えてしまいますが、機械安全に取り組んできた方なら、考え方の土台はすでに持っています。

今からできる6つの準備

1. 安全機能と接続口の一覧を作る:
   ISO 13849-1 の安全機能の一覧に、「その安全機能に関係する接続口(USB、LAN、フィールドバス、HMI、SD カード、無線など)」の列を足します。まずは規格要求事項への適合状況をチェックするための土台づくりです。
2. ネットワーク構成を見直す:
   6.7 の表のとおり、安全機能が工場ネットワークやインターネットから切り離されていれば、SRSL は最大でも1に収まります。リモート保守の要否も含めて、構成を早めに決めましょう。
3. リスクアセスメントシートに列を足す:
   安全機能 × 接続口ごとに、EL、AC、WoO、AP、危害の重大さ、SRSL を記入できるようにします。
4. ログの仕組みを設計する:
   何を記録するか、どこに5年間保存するか、どう守るか、どう読み出すか。PLC の容量や SD カードの扱いも含めて、設計の早い段階で決めておきたいところです。
5. セキュリティコンテキストを文章にする:
   どんな場所で、誰が、どうつないで使う前提か。取扱説明書にそのまま載せられる形で書いておくと、後の作業がぐっと楽になります。
6. アプローチA と B のどちらで行くか決める:
   IEC 62443 の体制がなければA、すでにあるならBが候補です。

そして、最終版の規格と、EU官報への掲載状況を確認することも忘れずに。この記事は照会用ドラフトをもとにしているので、数値や表現が最終版で変わっている可能性があります。