「JC-STAR取得メーカーの製品なら、そのまま調達候補にしてよい」。もし選定会議がこの一言で終わっているなら、確認単位が粗すぎます。JC-STARは日本のIoT製品セキュリティラベリング制度ですが、ラベルの対象はメーカー全体ではなく、登録された製品と型番範囲です。さらに、レベル、ステータス、有効期間、対象ファームウェア、利用条件を分けて見なければ、見積書の型番と登録製品がずれていても気づけません。
本稿では、タイ工場の購買、OT、IT、品質保証、設備保全が、JC-STAR対応製品を候補化し、RFP、FAT、SAT、運用台帳へ落とす手順を解説します。メーカー一覧の紹介ではなく、登録番号を起点に証跡をつなぐための実務ガイドです。
JC-STAR取得メーカー一覧だけでは調達判断できない
IPAの公式一覧は、候補探索の入口として有用です。2026年9月4日に最終更新された公式Excelを集計した時点では、338登録が掲載され、全338件のステータスが有効、ユニークなラベル取得事業者は138でした。表記揺れの「★1」と「★１」は同じレベルに正規化して集計しています。カテゴリ別では、エネルギー関連139、通信機器86、防犯関連42、PLC・DCS等のコントローラー9、IoTゲートウェイ4、製造・流通関連2、自律ロボット2などでした。また、2026年8月1日以降に限ると21登録、18事業者です。
ただし、これらは2026年9月4日のExcelを集計した時点値です。登録数もステータスも将来変わります。発注時、納入時、運用中の定期レビューでは、その都度公式一覧を再取得してください。「2026年9月に有効だった」というメモだけでは、翌年の監査証跡になりません。
もう一つ重要なのは、138という事業者数が138社の全製品をカバーするわけではないことです。同じ事業者でも登録されたシリーズと未登録シリーズがあり、同じシリーズ名でも対象型番やハードウェアリビジョンが限定される可能性があります。調達判定のキーはメーカー名ではなく、登録番号、製品名、型番範囲、評価レベル、ステータス、有効期間の組み合わせです。
公式一覧には登録番号、事業者、製品名、レベル、ステータス、取得日、有効期間が掲載されます。ステータスには有効だけでなく、失効猶予、失効、取消し等があり得ます。検索結果の断片、販売店の資料、古いPDFではなく、IPAのJC-STAR取得製品一覧を判断直前に確認する運用が必要です。
最初に理解するべきこと：JC-STARは完全な安全保証ではない
JC-STARの公式説明は、ラベルが製品の完全な安全を保証するものではないと明示しています。調達側は、ラベルを「無条件の合格証」ではなく、定められた評価基準に対する適合情報として扱うべきです。工場の用途、接続先、脅威、保守体制が変われば、同じ製品でも残余リスクは変わります。
評価方式にも違いがあります。★1と★2はベンダー自己評価チェックリストに基づく自己適合宣言、★3と★4は独立第三者による評価です。したがって、星の数を単純な製品ランキングとして扱わず、「自社用途に必要な保証水準は何か」「誰が何を評価したか」「評価対象の構成は何か」をRFPで明確にします。
例えば、インターネットへ直接接続しないセンサーと、生産ネットワークの境界で遠隔保守通信を中継するゲートウェイでは、求める統制が異なります。また、防犯カメラ、エネルギー管理機器、PLC周辺機器でも、停止時の影響と攻撃経路は異なります。ラベルは比較軸の一つですが、工場固有のリスク評価を代替しません。
JC-STAR対応製品を7項目で照合する
候補製品は、次の7項目を一つの照合票で確認します。購買部門だけで完結させず、OT、IT、品質保証、設備保全、必要に応じて法務が同じ票を参照することが重要です。
1. 登録番号
登録番号は証跡をつなぐ主キーです。RFP回答、見積書、発注書、FAT記録、SAT記録、資産台帳に同じ登録番号を記載します。メーカー名や製品愛称だけでは、後から登録内容が変わったときに追跡できません。
供給者には、公式一覧へのURLと登録番号を提出させます。画面キャプチャだけを証跡にする場合でも、取得日、取得者、参照URLを添え、可能なら当日の一覧データも保存します。検索結果画面や営業資料に表示されたロゴだけで判定してはいけません。
2. 型番範囲
見積対象の販売型番が、登録された製品名、シリーズ、型番範囲に含まれるかを一文字単位で確認します。末尾の地域コード、通信方式、電源仕様、無線モジュール、メモリ容量、筐体仕様の違いが、登録対象外の派生型番を示す場合があります。
本体が対象でも、外付け通信モジュールやオプションカードが評価構成に含まれない可能性があります。RFPには本体だけでなく、必須オプション、アクセサリ、管理ソフト、クラウドサービスを含む構成表を添付させます。型番の表記が見積書と評価資料で異なる場合は、「同等品」という説明で済ませず、メーカーの正式な対応表を求めます。
3. ステータス
ステータスは発注承認日の時点で有効かを確認します。公式一覧に有効以外の区分があり得る以上、過去に取得した実績だけでは不十分です。RFP締切時、発注時、納入時の3点で確認日を残すと、選定から納入まで数か月かかる案件でも状態変化を追跡できます。
申請中や取得予定という営業表現は、登録済みとは別です。IPAは「JC-STAR適合予定」等の誤認を招く表示に注意を促しています。★1の受付は2025年3月25日に始まり、2026年7月31日時点では申請急増により確認に通常より時間を要すると案内されていました。調達条件が「納入時までに取得」であるなら、未取得の段階で合格扱いにせず、取得できなかった場合の代替品、納期、契約上の扱いを先に決めます。
4. 有効期限
有効期間の終了日と、工場で想定する使用開始日・使用終了日を並べます。有効期限が納入直後に来る製品は、更新予定、更新中の証跡、更新されない場合の対応を確認します。長期稼働する設備では、購入時の有効性だけでなく、保守契約中の再評価方針が重要です。
有効期限を「ラベルの管理日」と「機器を物理的に使える期限」で混同してはいけません。期限到来が即座に装置の危険化を意味するわけではありませんが、証明の前提が維持されているかを見直すトリガーになります。台帳では期限の90日前など、社内で合意した余裕を持ってレビュータスクを発行します。ここで示す90日は運用例であり、制度上の一律要件ではありません。
5. 公開評価結果
公開されている評価結果や適合情報では、どの基準、レベル、製品構成が対象かを確認します。★1・★2は自己適合宣言、★3・★4は独立第三者評価という違いを、承認票に明記します。単に「星付き」と記録すると、後の監査で評価主体が分かりません。
評価文書が示す範囲と、自社が必要とする統制を対応付けます。例として、認証情報の管理、初期パスワード、ソフトウェア更新、通信保護、ログ、脆弱性報告窓口などを確認し、評価資料で確認できない項目は供給者回答またはFAT試験に回します。公開資料がない、または調達担当者だけでは解釈できない場合は、未確認のまま「適合済み」にせず、確認責任者と期限を設定します。
6. ファームウェア条件
ラベル対象の製品でも、評価時と異なるファームウェアを導入する場合は注意が必要です。納入時のバージョン、評価対象バージョン、最新推奨バージョン、アップデート経路、署名検証、ロールバック方法を供給者へ確認します。
タイ工場では、設備メーカーが安定稼働を理由に古いファームウェアを指定し、IT部門が脆弱性対応を理由に最新版を求めることがあります。どちらか一方の原則を自動適用せず、機能互換性、脆弱性、停止時間、復旧手順を評価した変更管理が必要です。FATでは出荷版、SATでは実際に設置された版、運用台帳では現在版を記録し、三者の不一致を検出します。
7. サポート期間
認証の有効期間とベンダーサポート期間は別項目です。セキュリティ更新の提供終了、製品販売終了、保守終了、クラウドサービス終了の予定日を確認します。日付が未定なら、通知方法、通知リードタイム、重大脆弱性への対応方針、後継機への移行支援を契約条件にします。
工場設備は長期間使うため、機器単体の購入価格よりも、更新可能期間と交換可能性が重要になることがあります。スペア在庫で延命する場合も、未更新機器を無期限に残すのではなく、ネットワーク分離、アクセス制御、監視などの補完策と廃止期限を例外台帳に記載します。
IoT機器セキュリティ調達基準をメーカー単位から製品単位へ変える
調達基準に「JC-STAR取得メーカーであること」とだけ書くと、供給者は企業として一件でも登録があれば条件を満たしたと解釈できます。適切な書き方は、「提案する販売型番が、提案構成および納入予定ファームウェアを含め、指定期日時点で該当する登録の範囲に含まれること」です。
さらに、JC-STARを必須条件にするか、加点条件にするか、同等証跡を認めるかは用途ごとに決めます。候補市場が小さい機器で一律必須にすると、事業継続や保守性を損なう場合があります。一方、遠隔接続を持つ境界機器や多数展開する共通機器では、要求を明確にする価値が高まります。重要なのは、基準を製品リスクと接続形態に結びつけることです。
同制度の取得製品ページには、2026年6月1日にCLS相互承認リスト、2026年1月14日にPSTI法適合宣言リストが追加されました。また、シンガポールCSAは、日本とのMoCが2026年3月18日に署名され、相互承認が6月1日に発効したと説明しています。対象例としてスマートホーム、警報、IoTゲートウェイ／ハブが挙げられ、製造者による他国ラベル申請の簡素化が狙いです。
ただし、この相互承認を、あらゆる製品、あらゆるレベル、またはタイでの自動承認へ一般化してはいけません。候補が相互承認リストにある場合も、リスト、適用範囲、型番、条件を個別に確認します。
JC-STAR調達要件をRFPへ落とす
RFPでは「認証を取っていますか」というYes/No質問を避け、証跡の提出形式と変更時の責任まで指定します。次の項目を回答表の列にすると、候補間比較が容易になります。
| RFP項目 | 供給者に求める回答・証跡 | 発注側の確認 |
|---|---|---|
| 登録識別 | 登録番号、公式URL、取得日 | 公式一覧と一致するか |
| 製品範囲 | 販売型番、HWリビジョン、オプション構成 | 見積BOMが範囲内か |
| 評価 | レベル、評価方式、公開結果 | 自己宣言か第三者評価か |
| 状態 | 現在ステータス、有効期間 | 発注日・納入予定日との関係 |
| FW | 評価対象版、出荷版、推奨版 | 差分と変更管理方法 |
| 更新 | 署名、配布、ロールバック、停止条件 | FAT/SATで試験可能か |
| サポート | セキュリティ更新、EOL/EOS、通知 | 設備寿命をカバーするか |
| 脆弱性対応 | PSIRT窓口、通知方法、緊急対応 | 工場の連絡網へ接続できるか |
| 変更通知 | 型番、部品、FW、クラウド変更 | 再評価・承認のトリガー |
| 例外 | 未充足項目、補完策、期限 | リスク所有者が承認したか |
RFPには、回答の基準日も入れます。例えば「提案提出日の公式一覧を参照」と明記し、発注前に再確認する権利を留保します。納入までにステータスや型番が変わった場合の通知義務、同等品への無断置換禁止、代替案の再審査も契約条項へつなげます。
ネットワーク機器を対象とする場合は、JC-STARを使ったネットワーク機器RFPの作り方で、管理面、遠隔保守、ログ、ネットワーク分離の確認項目も整理できます。カメラ案件では、JC-STAR対応ネットワークカメラの調達実務を参照し、映像データ、アカウント、録画装置、クラウド連携まで構成全体で確認してください。
FATで確認すること：出荷構成を証跡化する
FATでは、書類上の適合と実機の構成が一致するかを確認します。受入試験書に登録番号を印字し、実機ラベル、銘板、販売型番、ハードウェアリビジョン、シリアル番号、ファームウェアを写真またはログで残します。
型番・構成・ファームウェアの一致
見積BOM、製造BOM、出荷BOM、実機を突き合わせます。オプション通信モジュール、管理サーバー、モバイルアプリ、クラウドサービスがある場合は、どこまでが登録・評価範囲で、どこからが自社の追加評価範囲かを示します。
初期設定と認証
初期認証情報の扱い、初回ログイン時の変更、不要アカウント、権限分離、パスワード回復、証明書の導入方法を試験します。出荷時設定が安全でも、現地SI作業で共通パスワードへ戻ることがあるため、作業手順と完了証跡を確認します。
更新・復旧・ログ
正規ファームウェアの検証方法、更新失敗時の復旧、ロールバック制限、設定バックアップ、イベントログの取得を試します。実運用で更新できない製品は、サポート期間が長くても脆弱性対応が停滞します。試験環境で停止影響を確認し、本番変更の承認手順へつなげます。
不適合の処理
FATの不適合は、合否だけで閉じず、是正内容、期限、再試験、例外承認者を記録します。型番が登録範囲外、対象ファームウェアが不明、更新手順が未提供という問題は、現地据付後では交換コストが増えます。出荷前に止められる承認ゲートを設けます。
SATで確認すること：タイ工場の接続条件で再評価する
FATで合格した機器でも、工場ネットワークへ接続するとリスクは変わります。SATは動作確認だけでなく、設置場所、ネットワーク境界、アクセス経路、時刻同期、監視、バックアップ、資産登録を確認する工程です。
まず、設計されたVLANやゾーンへ接続され、想定外のインターネット通信や管理ポートが開いていないかを確認します。遠隔保守がある場合は、常時開放ではなく、申請、承認、時間制限、記録、終了確認の流れを試験します。
次に、NTP等の時刻同期、ログ転送、監視アラート、バックアップ、復旧を確認します。セキュリティログは時刻がずれると事故調査で使えません。機器側でログを出せても、保存先がない、容量が足りない、担当者が見ないという状態では統制になりません。
最後に、実機の資産IDと登録番号を運用台帳で結びます。設置後にファームウェア更新や構成変更を行った場合は、その変更が評価前提へ与える影響を記録し、必要に応じて供給者へ照会します。SAT合格日は、セキュリティ確認の終点ではなく運用管理の開始日です。
発注時・納入時・運用時の三段階ゲート
JC-STAR対応製品の確認は、一度きりのチェックリストではありません。状態変化と構成変化を捉える三段階ゲートにします。
発注時ゲート
候補製品の登録番号、型番範囲、レベル、ステータス、有効期間を確認し、RFP回答と公式情報を照合します。用途別のリスク評価を行い、満たさない要求には補完策と承認者を設定します。発注承認書へ一覧の取得日を記録します。
納入時ゲート
FATと受入検査で、納入された型番、ハードウェア、ファームウェア、オプションが承認構成と一致するかを確認します。公式一覧も再確認し、発注後のステータス変化を検出します。不一致があれば、据付前に隔離し、差分評価を行います。
運用時ゲート
有効期限、サポート終了、脆弱性通知、ファームウェア更新、構成変更を監視します。年次などの固定周期に加え、重大脆弱性、供給者通知、ネットワーク変更、用途変更をイベントトリガーにします。運用中の再確認では「ラベルがあるか」だけでなく、「いまの実機構成が確認済みの前提と一致するか」を見ます。
運用台帳に持たせる項目
最低限、登録番号、メーカー、製品名、販売型番、シリアル番号、ハードウェアリビジョン、設置場所、資産所有者、運用責任者、評価レベル、評価方式、公式ステータス、取得日、有効期限、評価対象ファームウェア、現在ファームウェア、サポート終了日、脆弱性窓口、最終確認日、次回確認日、例外、補完策、廃止予定日を持たせます。
台帳は購買システム、CMDB、設備台帳、保全システムのどこか一つへ無理に集約する必要はありません。ただし、登録番号と社内資産IDを共通キーとして相互参照できるようにします。更新責任も明確にします。購買は契約と供給者通知、OTは構成と停止影響、ITはネットワークと脆弱性、保全は実機と交換、品質保証は受入証跡を担当する、といった分担が考えられます。
Excelで始める場合も、列定義、更新者、更新期限、変更履歴、承認ルールを決めれば機能します。逆に、高価な資産管理システムがあっても、型番範囲やファームウェアを空欄のままにすれば調達証跡にはなりません。
JC-STARをタイで使うときの位置づけ
「JC-STAR タイ」と検索する担当者が最初に確認すべきなのは、JC-STARがタイで一律に法的必須だと決めつけないことです。本稿の目的は、日本企業の調達基準やグループ統制をタイ工場で運用する際に、JC-STAR情報を製品確認へ活用することです。タイの法令、顧客要求、業界要件、投資優遇、輸入・無線関連などは、対象製品と用途ごとに別途確認が必要です。
タイNCSAは2026年3月12日、一般利用者向けIoTサイバーセキュリティ指針案への意見募集を公表し、ISO/IEC 27400/27402、ETSI EN 303 645との整合を掲げました。これはタイでIoTセキュリティへの関心が具体化している参考情報ですが、公表時点の指針案をそのまま最終法令や全工場への強制要件として扱うべきではありません。
depaのdSUREは、タイ法人のIoT・デジタル製品向け認証枠としてSecurity、Safety、Functionalityの基準を掲げています。しかし、JC-STARとdSUREが同一制度である、または相互承認済みであるとは断定できません。両方が案件に関係する場合は、対象組織、製品範囲、評価項目、申請主体、認証の効力を個別に比較します。
METIの活用ガイドも、特定分野のシステムへ組み込まれるIoT製品の調達にJC-STARを活用する参考情報として位置づけられています。つまり、制度情報を調達へ変換する主体は発注者側です。ラベルをRFPへ書くだけでなく、工場のリスク、証跡、受入試験、運用監視へつなげる設計が必要です。
部門別の役割分担
購買部門は、登録番号、型番、価格、納期、契約、変更通知を管理します。OT部門は、用途、停止影響、ネットワーク構成、代替運転、更新可能時間を定義します。IT・セキュリティ部門は、認証、通信、ログ、脆弱性対応、遠隔アクセスを確認します。品質保証は、RFP回答からFAT、SAT、受入記録まで証跡が連続しているかを監査します。
設備メーカーやSIerには、単なる製品納入者ではなく、構成情報の提供者として責任を持たせます。部品変更、代替品、ファームウェア変更、クラウド仕様変更がある場合の事前通知と再承認を契約に含めます。工場側も、現場判断でUSB更新や設定変更を行った場合に記録する仕組みを用意します。
会議体では、星の数やメーカー知名度よりも、未確認項目の数、期限、責任者、停止影響を議論します。「ラベルあり」だけの緑判定ではなく、証跡確認済み、条件付き承認、是正中、期限切れ、例外承認といった状態を使うと、調達と運用を同じ言葉で管理できます。
よくある失敗と回避策
メーカー一覧を合格ベンダーリストにする
企業名だけのリストは、未登録製品を誤って承認する原因になります。登録番号と販売型番の組み合わせで管理し、提案ごとに確認します。
営業資料のロゴだけで判定する
ロゴや「取得予定」という表現では、現在の登録状態と範囲を確認できません。公式一覧を参照し、登録番号、有効期間、取得日を記録します。
発注時だけ確認する
納入までに型番、ファームウェア、ステータスが変わる可能性があります。発注、納入、運用の各ゲートで再確認します。
認証とサポートを同じ期限だと思う
有効期間、製品販売終了、保守終了、セキュリティ更新終了は別々です。台帳の列を分け、最も早い制約を更新・更改計画へ反映します。
★1と★3を同じ証拠として扱う
★1・★2は自己適合宣言、★3・★4は独立第三者評価です。用途に必要な保証水準と評価主体を確認し、不足は追加証跡や試験で補います。
タイの制度との関係を推測する
JC-STAR、NCSAの指針案、dSUREは、対象、目的、状態が異なります。「同じ」「相互承認」「法的必須」と推測せず、一次情報と案件固有要件を確認します。
FAQ：JC-STAR取得メーカーとIoT調達
JC-STAR取得メーカーなら、その会社の全製品が対象ですか？
いいえ。確認単位はメーカー全体ではなく、公式一覧に登録された製品、型番範囲、構成です。見積対象の販売型番とハードウェアリビジョンが登録範囲に含まれるかを確認してください。
JC-STAR対応製品は完全に安全ですか？
完全な安全を保証するものではありません。公式説明もその点を明示しています。評価レベル、評価方式、対象構成を確認し、工場の用途、接続先、停止影響に基づくリスク評価を組み合わせます。
JC-STAR調達要件には何を書けばよいですか？
登録番号、公式URL、販売型番、ハードウェアリビジョン、レベル、評価方式、ステータス、有効期間、対象ファームウェア、更新方法、サポート期間、脆弱性窓口、変更通知、例外処理を記載します。提出基準日と納入時の再確認も条件にします。
「JC-STAR適合予定」の製品を採用できますか？
採用可否は案件判断ですが、取得済みと同じ扱いにはできません。IPAは誤認を招く表示に注意を促しています。納入までの取得を条件にする場合は、未取得時の代替品、納期、再審査、契約上の処理を定めます。
JC-STARはタイ工場で法的に必須ですか？
本稿の確認範囲では、タイの全工場・全IoT機器に一律必須とは扱いません。日本本社や顧客の調達統制として活用する場合も、タイの法令、業界要求、無線・輸入要件などを製品と用途ごとに確認してください。
depa dSUREとJC-STARは相互承認されていますか？
同一制度または相互承認済みとは断定しません。dSUREはSecurity、Safety、Functionalityを掲げるタイ法人向けの枠組みです。両制度が関係する場合は、対象製品、評価項目、申請主体、効力をそれぞれ一次情報で確認します。
有効期限が切れたら機器をすぐ停止すべきですか？
期限到来だけで一律に即時停止とするのではなく、ステータス、脆弱性、更新状況、ネットワーク露出、停止影響、補完策を評価します。ただし、未確認のまま継続せず、例外承認、責任者、期限、廃止または更新計画を台帳へ残します。
まとめ：登録番号から運用台帳まで証跡をつなぐ
JC-STAR取得メーカーを探すことは、IoT調達の出発点にすぎません。実務では、登録番号、型番範囲、ステータス、有効期限、公開評価結果、ファームウェア条件、サポート期間を製品単位で照合し、RFP、FAT、SAT、運用台帳へ同じキーでつなぎます。2026年9月4日の公式Excel集計では338登録、138事業者でしたが、この数字も各製品の状態も固定ではありません。発注時、納入時、運用時に再確認する仕組みが、ラベルを実効性ある調達統制へ変えます。
タイ工場でJC-STAR対応製品の候補整理、RFP回答表、FAT/SAT試験票、資産・ファームウェア台帳の設計を検討している段階でも、TOMAS TECHへご相談ください。特定メーカーの推奨ではなく、既存の購買・OT・IT・品質保証フローに合わせて、確認項目と証跡のつなぎ方を整理できます。
