Cybersecurity Labelling Scheme相互承認｜海外工場IoT調達実務

Cybersecurity Labelling Scheme相互承認は、シンガポールCLSと日本のJC-STAR ★1の間で、同等と認められた要求事項の確認を再利用し、もう一方のラベル申請を簡素化する仕組みです。海外工場のIoT機器を調達する企業には、サプライヤーへ同じ説明と証跡提出を繰り返させない利点があります。一方で、ラベルがあれば工場ネットワークへ接続してよい、二つの制度が全面的に同一、タイで法的に必須、という意味ではありません。本記事では、相互承認をRFPから文書対応、資産・ゾーン適合、是正、FAT/SAT、期限・変更監視までの調達ゲートへ落とし込む方法を整理します。

Cybersecurity Labelling Scheme相互承認で何が変わったのか

日本の経済産業省とシンガポールのCyber Security Agency of Singapore（CSA）は、IoTセキュリティ制度の相互承認に関するMemorandum of Cooperation（MoC）を2026年3月18日に締結し、2026年6月1日に運用を開始しました。対象となるのは、JC-STAR STAR-1とSingapore CLS Level 1の間で同等と扱われる要求事項です。ラベル取得済み製品の製造者は、他方の制度へ申請するとき、定められた簡素化ルートを利用できます（METI、CSA発表）。

IPAは、CLSラベルを持つ製品がJC-STAR ★1へ申請する場合、CLSで適合済みと確認された要求事項に対応するチェックリスト項目を省略できると説明しています。また、CLSラベル製品向けのSTAR-1申請手数料は税込14万円、標準申請は税込19万8,000円、JC-STAR適合ラベルの初回有効期間は2年です。これらはIPAが示す制度上の申請条件であり、工場側の評価、試験、ネットワーク改修、文書化を含む総調達費ではありません（IPA相互承認申請案内）。

ここで実務上の意味を三つに分けます。

相互承認の価値は「審査不要」ではなく、「重複する適合確認を減らし、その時間を工場固有のリスク確認へ振り向けられること」です。この定義を調達、情報システム、生産技術、保全、品質、サプライヤーの全員で共有しておくと、ラベルの過大評価を避けられます。

JC-STAR ★1とSingapore CLS Level 1は全面的に同一ではない

「相互承認」という語から、AのラベルがあればBのラベルも取得済みと同じ、と解釈しがちです。しかしIPAの案内は、CLS適合製品をJC-STAR ★1の適合基準の一部を満たすものとして扱い、対応するチェックリスト項目を免除できる、と説明しています。申請書、ラベルの確認、対象外・部分適合項目の証跡など、制度が定める手続きは残ります。シンガポール側へ申請する場合にも、相互承認ルートの申請が必要です。

調達担当者は、見積書の「CLS/JC-STAR対応」という一行を受け入れず、少なくとも次を製品単位で確認します。

• ラベル制度名、レベル、ラベル番号、公開確認URL
• ラベルに記載された申請者・製造者と契約上のサプライヤーの関係
• 製品名、型番、ハードウェアリビジョン、ファームウェア版、関連クラウドサービス
• ラベルの取得日、有効期限、更新・延長状態
• 相互承認で省略される項目と、別途提出が必要な項目
• 脆弱性報告窓口、セキュリティ更新提供期間、通知方法
• 型番統合、部品変更、OEM変更、クラウド変更時の再評価条件

同じ商品名でも、地域別型番、無線モジュール、電源仕様、ファームウェア、クラウド接続先が異なることがあります。ラベルの対象と購買仕様書の対象が一致しなければ、ラベルは受入証跡として使えません。「シリーズ対応」ではなく、納入される構成の同一性を確認することが必要です。

Singapore CLSのLevel 1〜4を混同しない

Singapore CLSは1から4までのレベルで構成され、レベルが上がるほど評価段階が積み重なります。CSAの製造者向け説明では、Tier 1はETSI EN 303 645を基礎とするセキュリティベースライン、Tier 2は同規格の必須要求への適合、Tier 3は開発ライフサイクルとソフトウェアバイナリ分析、Tier 4は試験機関による侵入テストです（CSA CLS for Manufacturers）。

したがって、CLS Level 1ラベルを「第三者が製品へ侵入テストを実施した証明」と表現してはいけません。侵入テストはLevel 4の評価段階です。逆にLevel 4であっても、すべての攻撃や工場構成に対して安全を保証するものではありません。試験時の製品版、範囲、前提、既知の攻撃に対する抵抗性を示す一つの証跡として扱います。

JC-STAR STAR-3の2026年7月公開は別の論点

IPAは2026年7月13日、ネットワーク機器向けおよびネットワークカメラ向けのSTAR-3セキュリティ要求を公開したと案内しています（IPA JC-STAR）。工場で調達頻度の高いルーター、ゲートウェイ、カメラに関係するため重要な更新ですが、2026年6月に始まったJC-STAR STAR-1とSingapore CLS Level 1の相互承認とは分けて扱う必要があります。

RFPでは「JC-STAR対応」という包括表現を避け、要求レベルと製品カテゴリを明記します。例えば、一般的な環境監視センサーのベースライン確認に★1の証跡を使う場合と、複数ゾーンを中継するネットワーク機器により高い評価・設計保証を求める場合では、調達判断が異なります。STAR-3要求が公開されたからといって、すべての納入候補がSTAR-3ラベル取得済みとは限りません。要求公開、申請受付、製品の取得状況をそれぞれ確認します。

ネットワークカメラ調達の証跡設計はJC-STARネットワークカメラ調達ガイドで、制度申請の実務はJC-STAR申請ガイドで詳しく整理しています。

IoT機器セキュリティ調達基準は「ラベル＋工場適合」で作る

ETSI EN 303 645 V3.1.3はconsumer IoTのセキュリティ・データ保護ベースラインを示します。同規格自身が、実装はリスク評価と脅威モデリングに基づき、用途によっては追加要求が適切であると説明しています。また、規格は製品要求を定義しますが、個別の試験・認証方法そのものを定義する文書ではありません（ETSI EN 303 645 V3.1.3）。

この境界は海外工場IoT調達で重要です。消費者向けIoTのベースラインは、普遍的な初期パスワードを避ける、脆弱性報告を管理する、セキュリティ更新を提供する、といった土台を確認するのに有用です。しかし工場では、可用性、安全、保守停止、プロトコル、資産寿命、遠隔アクセス、既存PLCとの接続が加わります。

例えば、ラベル付きIoTゲートウェイであっても、次の構成なら工場側で差し戻すべきです。

• 管理画面が生産ネットワーク全体から到達できる
• クラウド接続先、通信方向、ポート、名前解決、証明書更新が不明
• 停止できないラインで自動更新が任意の時刻に実行される
• ローカルバックアップと設定復元手順がない
• 共有管理者アカウントしか使えず、操作履歴を個人へひも付けられない
• 脆弱性通知が本社購買にしか届かず、タイ工場の保全へ連絡されない
• 製品のサポート終了が設備の予定寿命より短い

ラベルは製品ベースラインの入口、工場のリスク受容は利用環境の出口です。この二つを調達基準の別列に置きます。

海外工場IoT調達を6つのゲートで管理する

実務では、ラベル番号の確認だけを独立作業にせず、購買プロセス全体へ証跡を流します。推奨する順番は、RFP、証跡対応、資産・ゾーン適合、サプライヤー是正、FAT/SAT、期限・変更監視です。各ゲートに「誰が」「何を見て」「何を承認するか」を設定します。

Gate 1：RFPで回答形式まで指定する

RFPには「JC-STARまたはCLS対応」とだけ書かず、回答欄と添付証跡を定義します。必須、条件付き、情報提供の三段階に分けると、価格だけで要件を落とすことを防げます。

回答をYes/Noだけにしないことが重要です。「対応」と回答した根拠文書、文書の版、適用型番、例外を同じ行で回収します。未回答は非適合、条件付きは是正計画へ移す、と評価規則もRFPに書きます。

Gate 2：ラベル要求と社内要求を文書マッピングする

相互承認で再利用される制度要求と、自社RFPの要求を一対一または一対多で対応付けます。完全一致を無理に作る必要はありません。制度証跡で確認できる範囲、サプライヤー文書が必要な範囲、工場試験が必要な範囲を区別します。

マッピング表の最低列は、社内要求ID、リスク、制度要求、証跡、対象版、判定、例外、是正期限、承認者です。証跡ファイル名だけでなく、該当ページや節、発行者、日付を記録します。翌年に担当者が変わっても、なぜ合格したか再現できることが目的です。

Gate 3：資産・ゾーン適合で工場利用を判定する

同じ製品でも、会議室の環境センサーと、生産停止へ影響するゲートウェイでは必要な統制が異なります。工場は対象資産、接続先、データ、制御権限、停止影響、復旧時間、現地保守力を確認して利用ゾーンを決めます。

まず「この機器が侵害されたら何が起きるか」を具体化します。監視データが欠落する、誤った値がMESへ届く、カメラ映像が漏れる、設定が変更される、PLCへ横移動される、クラウド障害で操作できなくなる、などです。その後、許容できない経路をネットワーク分離、通信許可、ジャンプホスト、ローカル運転、バックアップ、監視で抑えます。

産業用ゲートウェイの選び方とネットワーク境界は産業用IoTゲートウェイ選定ガイドも参照してください。ラベルの有無と、OT DMZ・生産ゾーンへの配置設計は別の判断です。

Gate 4：サプライヤー是正を契約前に閉じる

未確認や不適合を「導入時に相談」で残すと、納期直前に仕様変更または例外承認が必要になります。是正項目には、責任者、成果物、期限、再判定方法、未達時の処置を入れます。製品改修が難しい場合は、工場側の補完対策で受容できるかを評価します。

補完対策の例は、専用VLAN、ファイアウォールの許可リスト、クラウドへのアウトバウンド通信限定、管理面へのジャンプホスト、保守時間帯の一時接続、外部監視、予備機保有です。ただし、サポート更新が提供されない、脆弱性窓口がない、固定の共有パスワードを変更できない、といった製品の根本問題をネットワークだけで永久に覆い隠す判断は避けます。残留リスクの所有者と期限を明記します。

Gate 5：FATとSATを同じ受入表につなぐ

Factory Acceptance Test（FAT）は、出荷前またはベンダー環境で製品・設定・文書を確認します。Site Acceptance Test（SAT）は、実際の工場ネットワーク、認証、時刻、監視、障害時運転を含めて確認します。FATで合格した機器でも、現地のDNS、NTP、プロキシ、証明書、VLAN、クラウド到達条件で挙動が変わります。

セキュリティ受入には、少なくとも次を含めます。

1. 納入型番、HW/FW、ラベル対象版、設定バックアップの一致
2. 初期資格情報の変更、個人別アカウント、最小権限、MFAの適用範囲
3. 通信マトリクスどおりの許可通信と、禁止通信の遮断
4. 更新ファイルの真正性・完全性確認、更新失敗時の復旧
5. ログの時刻同期、記録項目、転送、保管、アラート
6. クラウド・WAN停止時のローカル動作と安全側への移行
7. 設定初期化、バックアップ復元、予備機交換
8. 保守接続の申請、承認、有効化、失効、記録
9. 脆弱性通知と緊急連絡の模擬訓練
10. 残課題、期限、暫定統制、最終承認者の署名

試験結果は画面写真だけでなく、入力条件、期待結果、実結果、ログ、版数、実施者、日付を残します。再現できない合格は、監査や事故対応で役に立ちません。

Gate 6：ラベル期限と製品変更を稼働後も監視する

IPAが示すJC-STARラベルの初回有効期間2年は、調達時に確認して終わる情報ではありません。更新・延長、製品版変更、EOL、脆弱性、クラウド仕様変更を資産台帳へひも付けます。期限の90日前など、組織で定めた時点に通知し、更新証跡の取得、代替品評価、補完対策、撤去計画を開始します。

監視対象はラベルだけではありません。

• ファームウェアとセキュリティ更新の最新版・承認版
• ベンダーの脆弱性情報、CVE、緊急通知
• ラベルの有効状態、適用型番、相互承認条件
• 部品変更通知、製品変更通知、サポート終了通知
• クラウドの接続先、証明書、API、データ保管条件
• 工場のゾーン変更、設備移設、用途変更、外部接続追加
• サプライヤー、販売代理店、OEM関係の変更

「変更があったら再評価」では担当者によって判断がぶれます。どの変更が軽微レビュー、部分SAT、全面再評価、接続停止に該当するかを事前に定義します。

ケース例：ラベル付きIoTゲートウェイをタイ工場へ導入する

ここで、シンガポール向けにCLS Level 1を取得したIoTゲートウェイを、タイ工場の設備稼働監視へ導入する架空の案件で、六つのゲートがどうつながるかを確認します。この例は特定製品の評価結果ではなく、判断手順を示すためのものです。

購買部は「CLS取得済み」という代理店の説明を受けます。Gate 1で公開URL、ラベル番号、対象型番、ファームウェア、クラウドサービス、更新期間を回答表へ記入させたところ、ラベル対象はゲートウェイ本体と標準クラウドであり、今回追加するLTEモジュールについては資料上の記載がありませんでした。この時点で製品全体を不合格にするのでも、ラベルがあるから合格にするのでもなく、LTE構成を「未確認」とします。

Gate 2では、相互承認の対象となるベースライン証跡、サプライヤーの通信仕様、工場側の遠隔接続要求を分けて対応付けます。ラベルから初期認証や更新方針に関する証跡を参照できても、SIM管理、モバイル回線の閉域性、クラウドの接続先、現地代理店の障害連絡は別の証跡が必要です。サプライヤーが提出した通信表にワイルドカードの宛先があれば、必要なFQDN、ポート、通信方向、証明書の失効確認へ分解して再回答を求めます。

Gate 3で生産技術とIT/OT担当が確認すると、ゲートウェイはPLCから稼働信号を読み取るだけで、制御コマンドは送らない設計でした。ただし物理的には同じスイッチへ接続する案だったため、監視用VLAN、ファイアウォール、OT DMZの中継サービス、管理用ジャンプホストを導入条件にします。クラウド停止時にもPLCの制御は継続し、ゲートウェイのバッファが満杯になっても制御通信へ影響しないことを受入条件に加えます。

Gate 4では、LTEモジュールを含む構成表、セキュリティ更新の連絡先、タイ代理店の一次応答、証明書更新手順を契約前の是正項目とします。代理店がラベル保有者でない場合も、製造者からの通知が代理店と工場へ届く経路を契約添付で確認します。「本社へ連絡する」という回答では、時差、休日、担当者変更で止まるため、役割メール、チケット、緊急電話、代替連絡を定義します。

Gate 5のFATでは、指定ファームウェア、通信許可、アカウント、署名付き更新、バックアップ復元をベンダー環境で試します。SATではタイ工場のDNS、NTP、VLAN、ファイアウォール、プロキシ、監視サーバーを使い、WAN切断、クラウド停止、証明書エラー、ゲートウェイ再起動、バッファ上限を確認します。試験中にクラウド停止でデータが欠落しても、設備制御に影響せず、復旧後に欠落期間を識別できれば、監視用途として条件付きで受容できる場合があります。許容条件は案件のリスク評価で決め、一般化しません。

Gate 6では、ラベルの2年期限、ファームウェア、LTEモジュール、クラウドAPI、証明書、SIM契約、代理店契約を同じ資産IDへ関連付けます。ラベルだけ更新されても納入版が対象外になった場合、またはラベルが有効でもクラウドAPIが変更された場合は、別々の再評価が必要です。このケースが示すのは、ラベルが判断を終わらせるのではなく、判断を追跡可能な形で始めるという役割です。

証跡台帳を「製品・版・利用場所・判断」で設計する

多数の工場と機器を扱うと、PDFやメールをフォルダへ保存するだけでは追跡できません。証跡台帳は、文書を集める倉庫ではなく、どの製品版を、どの場所で、どの条件により受容したかを説明する索引です。最低限、次のデータを関連付けます。

製品IDは販売名だけにせず、製造者型番と版を含む一意なキーにします。資産IDは工場のCMMSやIT/OT資産台帳と共通化し、制度証跡から実機へ、実機から試験・例外・更新へたどれるようにします。添付ファイルが移動してもリンク切れにならないよう、文書ID、ハッシュ、発行者、取得日を持たせる方法も有効です。

判定には必ず時点があります。2026年8月に適合とした判断が、2027年のファームウェア更新、クラウド移行、ゾーン変更後も自動的に有効とは限りません。「判断日」「判断時の版」「次回見直し日」「変更トリガー」を一組で持ちます。例外承認も期限なしにせず、恒久対策の予定、代替品の検討、停止時の処置を付けます。

組織横断の役割を分ける

制度証跡の確認をセキュリティ部門だけへ集めると、型番や納期、現地保守の情報が抜けます。一方、購買だけに任せると、ラベルの有無が価格比較のチェック欄になり、利用環境の評価が不足します。実務では次のように役割を分けます。

• 購買：契約対象、商流、価格、納期、変更通知、EOL条項を管理する
• 製品・生産技術：型番、機能、設備影響、FAT条件を確認する
• IT/OTセキュリティ：制度証跡、通信、認証、脆弱性、ゾーン適合を評価する
• 工場保全：更新可能時間、予備機、復旧、現地連絡、SATを確認する
• 法務・品質：表明保証、文書保持、供給者監査、顧客要求を確認する
• 資産所有者：残留リスクを受容し、利用開始・継続・停止を承認する

最終承認者は「ラベルがあるから」ではなく、制度証跡、製品同一性、工場の補完対策、試験結果、未解決事項を一枚の判定サマリーで確認します。会議体を増やすことが目的ではありません。同じデータを部署別に作り直さず、一つの証跡台帳をそれぞれの責任で更新することが、相互承認による効率化を社内でも実現する方法です。

タイ工場で制度を使うときの注意点

本記事で扱う日・シンガポール相互承認を、タイ工場の法的義務と表現してはいけません。タイでの調達においては、グループ企業の購買方針、顧客要求、輸出先要求、製品カテゴリ別の適用法令を別途確認しながら、CLS/JC-STARを製品セキュリティ証跡として利用します。日本本社が「★1必須」と定めれば社内調達条件にはなりますが、それとタイ法上の義務は別です。

海外工場では、証跡言語と運用言語も設計対象です。制度文書が英語または日本語であっても、緊急時に操作するタイ人保全担当者が理解できなければ統制は機能しません。受入手順、更新手順、隔離手順、緊急連絡表は現地チームが使用できる言語で整備し、実地訓練で確認します。翻訳では、label、certification、conformance、approval、acceptanceを同じ「認証」とせず、制度適合と工場受入を区別します。

また、商流を明確にします。製造者、ブランド所有者、シンガポールの申請者、日本の輸入者、タイの販売代理店、現地SIer、クラウド運営者が別法人の場合、誰が更新を通知し、誰が一次対応し、誰が交換在庫を持つかが曖昧になります。RACIと連絡先を契約添付にし、代理店変更時も引き継げる形にします。

調達会議で使える判定質問

候補製品を短時間で比較するときは、次の質問を順番に使えます。

1. ラベルはどの制度・レベルで、公開情報から確認できるか。
2. 納入型番、HW/FW、クラウドサービスはラベル対象と一致するか。
3. 相互承認で再利用できる要求は何で、残る申請・証跡は何か。
4. ラベルの有効期限と、更新申請の責任者・予定は明確か。
5. 脆弱性報告窓口と更新提供期間は、設備予定寿命を支えられるか。
6. 通信先、ポート、認証、暗号、証明書、遠隔保守経路を文書化できるか。
7. 対象OTゾーンで侵害・停止が起きたとき、影響を許容できるか。
8. 補完対策は製品価格、工事、運用負荷を含めて比較されているか。
9. FAT/SATの不合格条件と、修正・再試験・納期責任は契約にあるか。
10. 稼働後の期限、変更、脆弱性を資産台帳で追えるか。

一つでも「導入後に確認」となった場合、その項目は費用と納期の不確実性です。契約前に閉じるか、条件付き承認として予算、期限、リスク所有者を明記します。

よくある失敗と是正方法

失敗1：ラベル画像だけを受け取り、型番と版数を確認しない

公開URL、対象製品一覧、納入BOM、リリースノートを突合します。現物受入時にも型番と版数を記録し、資産台帳へ登録します。

失敗2：相互承認を自動変換と説明する

「同等要求の確認結果を利用した簡素化申請」と表現します。残る申請書、証跡、手数料、審査、ラベル発行を手順図に残します。

失敗3：CLS Level 1を侵入テスト済みと誤認する

CSAのLevel/Tier説明へ戻り、取得レベルと評価段階を確認します。追加テストが必要なら、範囲と版数を指定して別途実施します。

失敗4：ラベル取得を工場接続承認に置き換える

資産・ゾーン適合、通信、アカウント、更新、障害時動作をSATで確認します。接続承認は工場の責任者が残留リスクを見て行います。

失敗5：有効期限とEOLを購買ファイルに閉じ込める

資産台帳、契約台帳、脆弱性管理、保全計画を同じ製品IDで関連付けます。通知先を個人メールだけにせず、役割アドレスまたはチケットへ送ります。

失敗6：タイ現地運用を本社文書だけで済ませる

現地語の手順、連絡網、復旧試験、予備機、作業権限を整備します。本社は制度証跡を管理し、工場は運用証跡を管理するなど、責任分界を明確にします。

Cybersecurity Labelling Scheme相互承認に関するFAQ

JC-STAR相互承認があればSingapore CLSラベルは自動で取得できますか？

いいえ。相互承認は、同等と認められた要求事項の確認を再利用し、申請手続きを簡素化する仕組みです。他方の制度が定める申請を行い、必要書類や残る要求を満たす必要があります。自動変換や全面的な制度同一性を意味しません。

CLSラベル製品がJC-STAR ★1へ申請するときの費用はいくらですか？

IPAの案内では、CLSラベル製品向けSTAR-1申請手数料は税込14万円で、標準申請手数料は税込19万8,000円です。これは制度申請の手数料です。証跡整備、追加試験、翻訳、工場FAT/SAT、ネットワーク改修などの費用は別に見積もります。

JC-STAR ★1ラベルの有効期間はどのくらいですか？

IPAは初回有効期間を2年と説明しています。資産台帳に取得日・期限・対象版を登録し、期限前に延長状況と製品変更を確認します。期限内であっても、重要な版変更や用途変更があれば再評価します。

Singapore CLS Level 1は侵入テスト済みですか？

Level 1をそのように説明すべきではありません。CSAの説明では、CLSはLevel 1〜4で構成され、試験機関による侵入テストはTier/Level 4です。取得レベルと評価内容を分けて確認します。

タイの工場でJC-STARまたはCLSは法的に必須ですか？

本記事はそのようなタイの法的義務を示すものではありません。企業の購買基準、顧客契約、輸出先、製品カテゴリ、適用法令を個別に確認してください。CLS/JC-STARは、タイ工場調達で利用できる製品セキュリティ証跡の一つとして位置付けます。

ラベルがあればIoTゲートウェイを生産ネットワークへ直接接続できますか？

いいえ。接続先資産、通信経路、権限、更新、停止影響、監視、復旧を評価し、OTゾーンへの適合を承認する必要があります。必要に応じてOT DMZ、ファイアウォール、ジャンプホスト、通信許可リストなどを設計します。

まとめ：重複審査を減らし、工場固有の確認を厚くする

Cybersecurity Labelling Scheme相互承認は、JC-STAR STAR-1とSingapore CLS Level 1の同等要求に関する確認を再利用し、越境する製品申請の重複作業を減らす有用な仕組みです。しかし、自動的な全面同等、工場接続の許可、タイの法的義務を意味しません。調達成果へ変えるには、ラベルをRFPの入口に置き、対象版の文書マッピング、資産・ゾーン適合、サプライヤー是正、FAT/SAT、期限・変更監視まで一つの証跡チェーンとして管理します。相互承認で省けた確認時間を、設備停止、安全、遠隔保守、現地運用という工場固有の論点へ振り向けることが、本当の実務価値です。

TOMAS TECHでは、タイを含む海外工場のIoT調達について、候補製品が固まる前のRFP整理、ラベル・証跡対応表、OTネットワーク適合、FAT/SAT項目の設計段階からご相談いただけます。制度申請そのものと工場の受入条件を切り分けたい段階でも、お問い合わせページからお気軽にご連絡ください。

参照した一次情報

• IPA：Singapore CLSとJC-STARの相互承認申請
• METI：日・シンガポールIoTセキュリティ制度の相互承認
• CSA：2026年3月18日発表
• IPA：JC-STAR最新情報
• CSA：Cybersecurity Labelling Scheme概要
• CSA：CLS for Manufacturers
• ETSI EN 303 645 V3.1.3