タイ工場でネットワークカメラを新設・更新するとき、「JC-STARのラベルがあるから安全」と判断するだけでは調達要件として不十分です。確認すべき対象はブランド名ではなく、登録された型番、適合するファームウェア（FW）の範囲、ラベルの有効性、更新機能、脆弱性受付窓口、サポート期間、そして工場ネットワークへ組み込んだ後の運用です。本稿では、JC-STAR ネットワークカメラの候補選定からRFP、比較、FAT/SAT、稼働後90日までを、購買・IT・OT・設備・品質が同じ証跡で判断できる形に落とし込みます。
1. なぜ今、JC-STAR ネットワークカメラを調達要件にするのか
制度の現在地を正しく読む
JC-STARは、経済産業省の制度構想に基づきIPAが運用する、IoT製品のセキュリティ適合性評価制度です。★1は製品ベンダーによる自己適合宣言、★3は独立した第三者評価という違いがあります。★の数を単純な品質順位として読むのではなく、対象製品、想定利用環境、評価の深さ、適用される調達方針を分けて判断する必要があります。IPAの制度概要には制度の目的と枠組みが整理されています。
2026年8月18日更新の取得製品リストには、カメラやNVRを含む★1の有効製品が複数掲載されています。ただし、リストにブランドがあることと、見積対象の型番・FWが登録範囲に入ることは別です。候補ごとに適合性情報ページを開き、型番、FW、登録番号、ステータスを照合します。全件数を数えて市場占有率のように扱うのも避けます。
IPAは2026年2月6日にネットワークカメラ向け★3要件を公開し、2026年6月12日に更新して適合要件を公開しました。一方、★3ページでは評価ガイドが準備中と示されています。したがってRFPでは、「将来★3があれば必ず採用」と決め打ちせず、調達時点で利用可能な評価情報を確認し、★1の適合確認と製品・運用の追加審査を組み合わせます。
タイ工場でも日本の調達基準を使う意味
JC-STARは日本の制度ですが、タイ工場のカメラ調達でも共通の確認語彙として利用できます。日本本社、タイ現法、施工会社、カメラベンダー、ネットワーク担当が、同じ登録情報とチェックリストを参照できるからです。ただし、JC-STARをタイの法令や現地認証の代替として扱ってはいけません。現地の個人情報、監視、電気・通信、サイバーセキュリティ、輸入・設置の要件は案件ごとに確認します。
経済産業省の2026年4月資料では、通信機器やネットワークカメラを対象とする上位基準、および英国PSTIとの相互承認が2026年1月に開始されたことが示されています。シンガポールCLSとは2026年3月18日に相互承認の覚書が署名され、相互承認は2026年6月1日に開始されました。これは国際調達の比較材料になりますが、特定型番が自動的に他制度へ適合することを意味しません。対象製品、レベル、有効期間、相互承認の適用条件を個別に確かめます。経済産業省資料
2. JC-STARラベルと製品リストをどう確認するか
★1と★3の違いを調達判断へ変換する
★1は、共通的な最低限の適合基準について製品ベンダーが自己適合を宣言する枠組みです。★1チェックリストは2025年5月5日版で、2026年6月29日に修正されています。調達チームはチェックリストの最新版と、見積時にベンダーが根拠として提示した資料の版を記録します。
★3はネットワークカメラのような特定製品類型について、脅威分析に基づく追加要件を独立第三者が評価する仕組みです。評価の深さは上がりますが、★3ラベルだけで設置後の設定、ネットワーク分離、ID管理、ログ監視まで完了するわけではありません。製品評価とシステム受入を切り分けるのが調達側の仕事です。
登録番号、QR、有効期間、ステータスを証跡にする
ラベルの説明では、登録番号やQRコードによって適合性情報を確認できること、ラベルに有効期間があることが説明されています。RFP、注文書、FAT、SATの各時点で同じ情報を確認し、取得日を含むPDFまたは画面記録を証跡として保存します。
確認は次の五点を一組にします。
- 見積書の正確な製品型番と、適合性情報ページの型番が一致する。
- 納入時FWが適合範囲に含まれる。
- 登録番号とQRの遷移先が一致する。
- ラベルが調達判断日および受入日に有効で、ステータスに問題がない。
- 更新後FWも適合範囲に入るのか、再確認手順が定義されている。
一体型カメラの適合性情報例では、情報更新日が2026年7月2日、対象FWが2.00以降と示され、既存接続では設定変更が必要という注意もあります。これは特定ベンダーの推奨ではなく、「同じ型番でもFWや既存接続条件を読まなければならない」という確認方法の例です。
3. JC-STAR 調達要件を6つのゲートに分ける
ゲート1〜3：適合範囲、製品能力、提供体制
ゲート1は「ラベル適合性」です。型番、FW、登録番号、有効期限、ステータスを確認します。ゲート2は「製品セキュリティ能力」です。初期認証情報、更新、暗号、証明書、ログ、時刻同期、設定バックアップと復元を評価します。ゲート3は「ベンダー提供体制」です。サポート期間、EOL通知、脆弱性受付窓口、アドバイザリ、修正版の提供方法、現地または遠隔支援を確認します。
ゲート4〜6：設計、検証、運用移管
ゲート4は「工場アーキテクチャ」です。カメラ、録画、管理端末、ネットワーク、ログをどのゾーンへ置くかを決め、通信を許可リスト化します。ゲート5は「FAT/SAT」です。要件ごとに試験方法、合格基準、証跡、再試験条件を定義します。ゲート6は「運用移管」です。アカウント責任者、更新判断者、ログ確認、バックアップ、インシデント連絡、廃棄時のデータ消去まで引き渡します。
この6ゲートを一枚の判定表にすると、購買部門が価格比較を始める前に技術的な失格条件を確認できます。また、ITが製品仕様だけで判断し、設備担当が現場接続だけで判断する分断を防げます。既存設備の無線接続を含む場合は、タイ工場の無線LAN設計ガイドも併せて、電波品質とセキュリティ境界を別々に設計してください。
4. RFPに入れるJC-STAR 対応製品の要件表
必須条件と回答形式
「対応しています」という自由記述だけでは候補間を比較できません。RFPには、回答形式と添付証跡まで指定します。次の表は案件に合わせて調整できる基本形です。
| 区分 | RFP要求事項 | ベンダー回答・証跡 | 受入判定 |
|---|---|---|---|
| JC-STAR | 登録番号、ラベルレベル、有効期間、現在ステータスを提示 | 適合性情報URLと取得日付きPDF | 型番単位で一致 |
| 型番・FW | 見積型番、地域別SKU、納入FW、適合FW範囲を提示 | BOM、機器画面、リリースノート | 全台照合可能 |
| サポート | セキュリティ更新期間、EOL/EOS通知方法、通知猶予を提示 | 公開ポリシーまたは契約条項 | 運用期間を満たす |
| 脆弱性対応 | 受付窓口、報告方法、アドバイザリ、緊急連絡を提示 | PSIRT情報、SLAまたは運用手順 | 責任者が明確 |
| 初期設定 | 一意な初期値または初回変更、不要サービス停止を可能にする | 設定ガイド、FAT記録 | 標準設定を固定 |
| ID・権限 | 個人ID、RBAC、管理者分離、ロックアウトを支援 | 権限表、画面証跡 | 共用管理者を排除 |
| 暗号・証明書 | 管理・映像・API通信の方式、証明書更新方法を提示 | 対応方式、設定証跡 | 許可方式のみ利用 |
| 更新 | 署名検証、失敗時復旧、ロールバック条件、オフライン更新を説明 | 更新手順、試験記録 | 復旧可能性を確認 |
| ログ・NTP | 認証、設定変更、更新、障害ログと外部転送、NTPを支援 | ログ項目一覧、転送試験 | 時刻と追跡性を確保 |
| バックアップ | 設定の取得、暗号化保管、復元、機種差分を説明 | バックアップ・復元試験 | 代替機で再現可能 |
| データ | 録画・スナップショット・メタデータの保存場所と消去方法 | データフロー、消去証明 | 保存方針に適合 |
| FAT/SAT | 下記受入表に基づく試験と証跡提出に合意 | 試験計画、結果、是正票 | 未解決事項ゼロまたは承認済み |
契約に残す変更管理
カメラのFWは調達後も変わります。契約には、FW変更前の通知、変更内容、セキュリティ修正の優先度、互換性確認、設定バックアップ、検証環境での試験、本番承認、ロールバックの責任分担を残します。JC-STARの適合範囲外へ出る可能性がある場合は、ベンダーが影響を説明し、調達側が適合性情報を再確認する手順を入れます。
より詳しい制度申請・確認の流れは、JC-STAR申請ガイド2026も参照してください。申請者向けの視点を理解すると、調達側がどの証跡を依頼すべきか整理しやすくなります。
5. 候補製品をラベルだけで比較しない
比較表は「確認済み」「条件付き」「未確認」で埋める
候補表に点数を付ける前に、根拠の状態を三段階で管理します。「確認済み」は一次情報または実機証跡がある状態、「条件付き」は構成や契約で満たす状態、「未確認」は回答待ちです。未確認をゼロ点扱いして平均点に埋没させず、重要項目ならゲート不通過にします。
| 比較軸 | 候補A | 候補B | 候補C | 判定ルール |
|---|---|---|---|---|
| 型番・FWのJC-STAR適合 | 確認済み/条件付き/未確認 | 同左 | 同左 | URL、登録番号、FW証跡必須 |
| ラベルの有効性 | 同上 | 同上 | 同上 | 調達日と受入日で再確認 |
| 更新・復旧 | 同上 | 同上 | 同上 | 署名、失敗、ロールバックを試験 |
| 脆弱性窓口・SLA | 同上 | 同上 | 同上 | 契約期間と連絡経路を確認 |
| RBAC・アカウント | 同上 | 同上 | 同上 | 個人IDと最小権限を実機確認 |
| 暗号・証明書 | 同上 | 同上 | 同上 | 実利用プロトコルで確認 |
| ログ・NTP | 同上 | 同上 | 同上 | 外部ログで追跡可能か試験 |
| VMS/NVR相互運用 | 同上 | 同上 | 同上 | 対象構成・負荷で録画再生試験 |
| サポート・EOL | 同上 | 同上 | 同上 | 想定運用期間と交換計画に適合 |
| FAT/SAT証跡 | 同上 | 同上 | 同上 | 要件IDごとに証跡がある |
価格はこのゲートを通過した候補同士で比較します。導入価格だけでなく、ライセンス、証明書運用、VMS/NVR、ログ保存、検証機、保守、更新作業、代替機、撤去・消去を含むTCOとして条件をそろえます。本稿では具体価格や削減率を示しません。数量、保存期間、帯域、保守範囲、現地支援が案件ごとに異なるためです。
証跡台帳は候補選定時に作って終わりではありません。最低でも、見積回答の受領時、注文仕様の凍結時、FAT前、出荷前、SAT時、FW更新前後、年次または社内で定めた定期レビュー時に更新します。台帳には要件ID、対象資産、登録番号、ラベルの確認日、確認したURL、FW、証跡ファイルの保管先、判定、未解決事項、責任者、次回確認日を持たせます。URLだけを保存するとページ内容の更新を追えないため、取得日時付きのPDFや画面記録を合わせて保管します。逆に、画面記録だけでは現在ステータスを確認できないので、意思決定の直前には公式ページを再取得します。
変更管理では、変更要求を「セキュリティ修正」「機能更新」「設定変更」「機器交換」「ネットワーク変更」に分けます。各要求に、変更理由、対象台数、現行FW、変更後FW、適合範囲への影響、停止時間、バックアップ、試験対象、ロールバック条件、承認者を記録します。緊急修正でも、実施後に台帳と資産情報を更新し、暫定対応を恒久設定として放置しません。カメラだけを更新してNVR/VMSや証明書との互換性を失うことがあるため、変更単位は製品ではなく利用構成で考えます。
RACIも明文化します。購買は契約証跡と代替品統制、ITまたはOTはネットワークとID、設備は現地設置と個体照合、情報セキュリティは基準と例外承認、ベンダーは製品情報と是正、運用責任者は日常監視と更新判断を担います。実際の役割名は組織に合わせますが、各タスクに実行責任者と最終説明責任者を一人ずつ置き、相談先と情報共有先も決めます。担当者が退職・異動した場合の引継ぎ、緊急時の代理承認、休日連絡も運用移管の完了条件に含めます。
例外管理では、未対応項目を単に「許容」と記さず、理由、残留リスク、代替統制、有効期限、是正責任者、再確認日を残します。例えば証明書更新の自動化が間に合わなければ、期限監視と手動更新手順を暫定統制にし、恒久対応日を決めます。期限切れ例外を一覧化し、運用会議で閉鎖または再承認します。これにより、候補比較で「条件付き」とした項目が、稼働後も無期限に残ることを防げます。
レビューの頻度はリスクと変更量で決めます。稼働直後は週次で、未解決の是正、ログ転送、時刻ずれ、アカウント発行、バックアップ成功、ベンダー通知を確認し、安定後は月次または四半期の管理サイクルへ移します。重大な脆弱性通知、FW公開、証明書期限接近、ネットワーク変更、NVR/VMS更新、保守契約変更があれば定例を待たず臨時レビューを開きます。会議記録は結論だけでなく、参照した登録情報の取得日、影響した要件ID、承認した例外、次の確認日を台帳へ戻します。
引継ぎ資料は「設定手順書」だけにしません。資産一覧、ゾーン図、許可通信一覧、管理アカウント申請、秘密情報の保管場所、証明書更新、FW検証、ログの正常状態、バックアップ復元、障害切り分け、ベンダー連絡、交換と消去を一つの運用パックとして管理します。受入時には運用担当者が手順を読むだけでなく、テスト機または承認された時間帯でログ検索、設定復元、アカウント無効化、連絡票作成を実演します。実演できない手順は、文書が存在しても移管未完了と判定します。
監査可能性を保つには、証跡ファイル名と保管先にも規則が必要です。記事グループや案件番号ではなく、要件ID、資産ID、試験区分、日付、版を検索できる形にし、最新版と承認済み版を区別します。原本を上書きせず、変更理由と承認履歴を残し、閲覧・編集権限を分けます。これにより、数か月後に脆弱性対応や機器交換が発生しても、当初どの範囲を、どの証拠で受け入れたかを再現できます。
6. 工場ネットワークのゾーン構成を同時に設計する
カメラ、録画、管理、ネットワーク、ログを分ける
ネットワークカメラは単体で完結しません。カメラゾーン、NVR/VMS録画ゾーン、管理端末ゾーン、ネットワーク管理基盤、ログ・監視基盤を分け、各境界で必要な通信だけを許可します。カメラからインターネットへの直接通信を前提にせず、時刻同期、名前解決、更新配布、監視の経路を設計します。遠隔保守が必要なら、常時開放ではなく、承認、強固な認証、接続時間、操作記録、終了確認を定めます。
NISTとETSIを追加確認の辞書として使う
NIST IR 8259 Rev.1は2026年4月の改訂版としてIoT製品セキュリティの基礎活動を整理し、NIST IR 8259Aはデバイス識別、構成、データ保護、インターフェースへの論理アクセス、ソフトウェア更新、サイバーセキュリティ状態認識という六つのコア能力を示します。NIST technical catalogおよびSP 800-213AではDevice Securityを加えた七分類へ展開されています。JC-STARと一対一で同一視せず、RFPの抜けを探す辞書として使います。
ETSI EN 303 645 V3.1.3も、消費者向けIoTセキュリティのベースラインを確認する参考資料になります。工場用途では可用性、長期保守、閉域運用、復旧、証跡など追加の要求が生じるため、そのまま合否表へコピーするのではなく、使用環境へ翻訳します。
IPAのネットワークカメラのセキュリティ解説も、カメラ固有のリスクを関係者へ説明する材料になります。製品選定と同時に、設置位置、録画データ、管理画面、外部公開の有無を棚卸ししてください。
7. FAT/SATでJC-STAR 調達要件を証拠に変える
FATは工場出荷前、SATは現地構成で確認する
FATでは、納入予定の型番・FW、標準設定、ID/RBAC、証明書、更新と失敗時復旧、ログ、NTP、バックアップ/復元、VMS/NVR連携を確認します。SATでは、タイ工場の実ネットワーク、実スイッチ、実NVR/VMS、実ログ基盤、実運用アカウントで同じ要求が維持されるか確認します。FAT合格をSAT省略の理由にしてはいけません。
| 要件ID | FAT試験 | SAT試験 | 必須証跡 | 合格・再試験 |
|---|---|---|---|---|
| CS-01 | 型番、FW、登録情報をBOMと照合 | 全設置機の画面・台帳を照合 | 適合性PDF、BOM、機器画面 | 一台でも不一致なら保留 |
| CS-02 | 初回パスワード変更と不要サービス停止 | 標準テンプレート適用を確認 | 設定差分、画面記録 | 是正後に全台再確認 |
| CS-03 | 個人ID、RBAC、ロックアウトを試験 | 本番ID基盤と責任者を確認 | 権限表、監査ログ | 共用管理者が残れば不合格 |
| CS-04 | 証明書導入と暗号化通信を確認 | 実経路で平文・弱い方式を遮断 | パケット/設定証跡 | 例外は期限付き承認 |
| CS-05 | 正常更新、失敗、復旧を試験 | 検証機から本番承認手順を確認 | FW、ハッシュ、ログ、手順 | 復旧不能なら不合格 |
| CS-06 | 認証・設定・更新ログを出力 | SIEM/syslog受信とNTP整合を確認 | 送受信ログ、時刻比較 | 欠落を修正し再送試験 |
| CS-07 | 設定バックアップと代替機復元 | 保管権限と定期復元手順を確認 | バックアップ、復元結果 | 復元差分を解消 |
| CS-08 | NVR/VMSで録画・再生・障害復旧 | 実負荷・停電復帰・通信断を確認 | 動画、イベント、障害票 | 欠損条件を合意し再試験 |
| CS-09 | 工場出荷時データ消去を確認 | 交換・廃棄時の消去証跡を確認 | 消去手順、証明様式 | 資産台帳と閉鎖を照合 |
証跡チェーンを切らない
要件IDから試験、証跡、判定、是正、再試験までを一つのチェーンで管理します。スクリーンショットだけでは、どの個体、どのFW、誰が、いつ、どの手順で確認したか分かりません。資産番号、シリアル、型番、FW、試験者、日時、環境、期待値、実績値を記録します。変更後は影響する要件IDを選び、差分再試験を行います。
経済産業省の工場システム等におけるサイバー・フィジカル・セキュリティ対策ガイドライン利用ガイドは、特定分野システムの例として工場システムを扱います。ネットワークカメラを単なる備品ではなく、工場システムへ接続される資産としてリスク評価と運用へ組み込む際の参考になります。
8. 90日導入ロードマップ
0〜30日：範囲と要件を固定する
最初の30日で、利用目的、設置区域、録画対象、保存期間、アクセス者、カメラ台数、NVR/VMS、接続方式、既存ネットワーク、ログ基盤、保守形態を整理します。候補型番のJC-STAR情報を取得し、FW範囲と有効性を確認します。購買、IT、OT、設備、法務・プライバシー、品質の責任者を決め、RFPと受入要件IDを凍結します。
31〜60日：候補評価とFATを行う
ベンダー回答を「確認済み・条件付き・未確認」で比較し、未確認の重要項目を解消します。実機でアカウント、RBAC、証明書、更新、ログ、NTP、バックアップ、VMS/NVR連携を試験します。FATの不具合は是正票へ紐づけ、代替案や例外がある場合は期限、責任者、残留リスク、終了条件を記録します。
61〜90日：SATと運用移管を完了する
現地設置後、ゾーン、ACL、実アカウント、ログ転送、NTP、録画、停電復帰、通信断、バックアップ復元を確認します。資産台帳へ型番、シリアル、FW、登録番号、設置場所、管理者、サポート/EOL情報を登録します。更新カレンダー、脆弱性連絡、四半期レビュー、交換・廃棄の手順を運用責任者へ移管し、未完項目を残したままプロジェクトを閉じません。
| 期間 | 主な成果物 | 終了条件 |
|---|---|---|
| 0〜30日 | スコープ、データフロー、RFP、要件ID、候補適合性記録 | 責任者が要件を承認 |
| 31〜60日 | 候補比較、FAT計画・結果、是正票、変更管理案 | 重大な未確認がない |
| 61〜90日 | SAT結果、資産台帳、標準設定、運用・廃棄手順 | 証跡と責任が移管済み |
9. よくある失敗と回避策
ラベルを完全な安全保証と解釈する
JC-STARラベルは、示された範囲の適合性を確認する重要な手掛かりですが、ゼロリスクや設置後の安全を保証するものではありません。型番・FW・有効性を照合し、構成と運用を別に検証します。
ブランド単位で「対応」と判断する
同一ブランドでも型番、地域SKU、FWが異なります。見積、注文、納入、FAT、SATで個体と適合情報を追跡し、機種変更を口頭承認しません。
FW更新を「保守に含む」で終わらせる
誰が脆弱性情報を受け取り、どこで検証し、誰が本番を承認し、失敗時にどう戻すかまで定義します。適合範囲を出る場合の再確認も必要です。
カメラを既存LANへ直結する
帯域が足りるだけでは安全な構成ではありません。カメラ、録画、管理、ログを分け、必要通信を列挙し、遠隔保守とインターネット通信を制御します。
FATの資料をSATへコピーする
現地ではスイッチ、ACL、時刻、証明書、ID、VMS/NVR、停電復帰など条件が変わります。SATは現地構成で実施し、差分を証拠化します。
10. FAQ：JC-STAR ネットワークカメラ調達の疑問
Q1. JC-STAR対応ならネットワークカメラは安全ですか？
完全な安全保証ではありません。型番・FW・有効期間・ステータスが登録範囲に合うことを確認したうえで、初期設定変更、RBAC、暗号、ログ、NTP、更新、分離、バックアップなどを実構成で検証します。
Q2. ★1と★3のどちらを調達要件にすべきですか？
調達時点で利用可能な評価、使用環境、リスク、社内方針によります。★1は自己適合宣言、★3は独立第三者評価です。★3評価ガイドの公開状況も含めて最新情報を確認し、ラベルレベルだけでなく追加要件をRFPへ入れます。
Q3. JC-STAR 対応製品はブランド名だけ確認すればよいですか？
いいえ。正確な型番、地域SKU、納入FW、適合FW範囲、登録番号、有効性、ステータスを確認します。注文後の代替型番も同じ手順で再審査します。
Q4. JC-STAR 調達要件に最低限入れる項目は何ですか？
ラベル情報に加え、サポート期間、EOL、脆弱性窓口、更新・復旧、初期設定、ID/RBAC、暗号・証明書、ログ・NTP、分離、バックアップ/復元、データ消去、FAT/SAT証跡を入れます。
Q5. 既設カメラにもJC-STARを遡って求めるべきですか？
一律交換ではなく、まず資産棚卸しとリスク評価を行います。型番、FW、外部公開、更新可否、認証、ログ、ネットワーク位置、サポート期限を確認し、設定是正、分離、更新、交換の順序を決めます。
Q6. タイ工場で日本のJC-STARを使うと現地法令対応になりますか？
なりません。JC-STARは製品セキュリティ調達の共通基準として活用できますが、タイの個人情報、監視、通信、設置等の要件は別途確認が必要です。
Q7. FWが更新されたらJC-STAR適合は維持されますか？
自動的に維持されると仮定してはいけません。適合性情報に記載されたFW範囲、ベンダー情報、現在ステータスを再確認し、変更前後の試験と証跡を残します。
Q8. FAT/SATでは何を最優先で確認しますか？
最初にBOM、個体、型番、FW、登録情報を一致させます。そのうえで、初期設定、RBAC、暗号、更新・復旧、ログ・NTP、バックアップ、NVR/VMS、ネットワーク分離を要件IDごとに試験します。
Q9. 候補が複数ある場合、価格比較はいつ行いますか？
必須ゲートを通過した候補同士で、同じ数量、構成、保守、保存期間、検証、代替機、撤去条件をそろえてTCOを比較します。未確認の重要項目を低価格で相殺しないことが重要です。
11. まとめ：ラベルを入口に、運用まで調達する
JC-STAR ネットワークカメラ調達の要点は、ラベルをゴールではなく、検証可能な入口として使うことです。型番・FW・有効性を確認し、製品能力、ベンダー体制、工場ゾーン設計、FAT/SAT証跡、90日後の運用責任まで一続きにします。★1の自己適合宣言と★3の独立第三者評価を正しく区別し、どちらの場合も設置後の設定と運用を省略しません。
タイ工場の既設カメラ棚卸し、RFP作成、候補比較、ネットワーク分離、FAT/SATの設計段階でもご相談いただけます。製品指定の前に要求と証跡を整理したい場合は、TOMAS TECHへのお問い合わせをご利用ください。
