JC-STAR 海外拠点調達｜タイ工場のRFP・FAT/SAT実務

JC-STAR 海外拠点での活用を検討するとき、最初に整理すべきなのは「日本のラベルをタイでそのまま規制適合証明として使う」話ではない、という点です。日本本社が共通のIoT機器 セキュリティ 調達基準を作り、タイ工場のRFP、ベンダー選定、FAT、SAT、稼働後の更新監視まで一つの証拠体系で管理する。そのための基準線としてJC-STARを使うのが、本記事で扱う実務です。

結論：JC-STARをラベル確認で終わらせず、海外工場の受入証拠へ変換する

JC-STARは、IPを用いてデータを送受信する幅広いIoT製品のセキュリティ機能を、日本の共通的な物差しで評価・可視化する任意制度です。★1は製品共通の最低限の要件、★2以上は製品類型や利用場面を踏まえた追加要件という位置づけです。★1と★2はベンダーの自己適合宣言を基にIPAがラベルを付与し、★3と★4は独立した第三者評価を前提とします。

ただし、ラベルが有効だからといって、タイ工場で安全に設置・運用できることまで自動的に証明されるわけではありません。IPA自身も、セキュリティ機能が具備されていることと、安全に使い続けることは同じではないと説明しています。工場側には、ネットワーク分離、初期設定、権限、ログ、バックアップ、脆弱性受付、更新配布、保守終了、撤去時のデータ消去などの運用責任が残ります。

したがって、日本本社の調達基準は二層に分けます。第一層は「対象製品に適切なJC-STARラベルがあり、IPAの製品情報ページで有効性を確認できるか」。第二層は「タイ工場の構成とリスクに対して、導入・接続・運用・更新・退役の統制が設計され、FAT/SATで証明できるか」です。ラベルは入口、FAT/SATの証拠と運用監視が出口です。

JC-STAR タイ工場調達で誤解しやすい五つの境界

1. 日本の任意制度であり、タイの法令適合証明そのものではない

JC-STARは日本の制度です。タイ工場がJC-STAR取得製品を採用することは、調達判断を標準化するうえで有効ですが、タイのサイバーセキュリティ、電気通信、個人データ、無線、輸入、産業安全などの要求を自動的に満たすことを意味しません。現地で適用される法令・許認可・顧客要求は、製品用途、通信方式、処理データ、事業区分に応じて別途確認します。

RFPには「JC-STAR取得」を一行で書くだけでなく、「本要件は日本本社の共通調達基準であり、現地法令適合の代替ではない」と明記します。現地SI、法務、情報セキュリティ、設備、安全衛生、個人情報担当の責任分界を先に決めると、受入直前に認証や許可の不足が発覚するリスクを下げられます。

2. ラベルの対象は製品であり、工場システム全体ではない

IPAの説明では、対象は販売・購入の単位となるIoT機器、またはIoT機器と必須付随サービスから成る一式です。現時点で「システム」は対象外です。ネットワークカメラにラベルがあっても、VMS、クラウド、VPN、スイッチ、ID基盤、保守PC、配線、設定、監視運用を含む工場監視システム全体が認証されたことにはなりません。

調達台帳では、ラベル登録番号をシステム名だけに紐付けず、製品名、型番、ハードウェア版、ファームウェア版、必須サービス、設置場所、ネットワークゾーン、管理責任者へ紐付けます。型番末尾や地域SKUが異なる場合、同一ラベルの対象範囲に含まれるかをIPAの製品情報ページとベンダー文書で確認します。

3. 高い星の数字を一律に要求すればよいわけではない

★1は全対象製品に共通する最低限の基準です。★2以上では製品類型ごとの特徴が考慮され、同じレベルでも類型により適合基準が異なります。対象類型や運用状況が整っていない製品に、実在しないラベルを必須条件として書けば、応札不能や不適切な代替表明を招きます。

まず製品がJC-STARの対象か、該当類型の基準が運用されているか、調達時点で取得可能なレベルは何かを確認します。そのうえで、ラベルを必須、加点、将来取得計画、同等証拠のいずれとして扱うかを決めます。「JC-STAR対応予定」「申請中」を取得済みと同等に評価してはいけません。IPAは、ラベル交付前に取得済み・取得見込みと誤認させる表示をしないよう明確に注意しています。

4. 相互承認は世界共通パスポートではない

2026年9月9日時点で、英国PSTI法との相互承認手続きは2026年1月1日から開始されています。英国PSTI適合製品からJC-STAR★1へ申請する場合、JC-STARの三つの適合基準で確認が免除され、★1申請手数料は通常198,000円（税込）に対し140,000円（税込）と案内されています。逆方向でも、JC-STAR取得製品が英国PSTI適合を証明するにはIPAへの追加申請、英語での製品・脆弱性情報提供、窓口整備などが必要で、事務手数料5,500円（税込）が示されています。

シンガポールCLSとの相互承認についても、2026年3月の協力覚書を経て、IPAが相互承認申請の手続きを案内しています。ただし相互承認は、合意された制度、レベル、技術要件、申請方向、製品範囲に限られます。JC-STARの取得だけで各国制度の全要件が自動適合になるわけではなく、タイ向けの相互承認でもありません。調達表では「制度名」「方向」「認められる要件」「追加提出」「費用」「対象地域」を列で分けます。

5. 有効なラベルでも更新監視が不要になるわけではない

適合ラベルには有効期間があり、IPAの製品リストには有効、失効猶予、失効、取消しなどのステータスが表示されます。新規申請のラベル有効期間は、レベルによらず発行日から最大2年間と案内されています。調達時にPDFを保存して終わると、失効、型番変更、脆弱性、サポート終了を見逃します。

契約には、製品情報、脆弱性窓口、セキュリティ更新期間、通知期限、更新手段、失効・取消し・重大脆弱性発生時の報告、代替機、ロールバック、現地作業費の扱いを含めます。日本本社は四半期などの周期でIPA登録情報を照合し、タイ工場は実機ファームウェアと構成台帳を照合します。

日本本社が作るIoT機器 セキュリティ 調達基準の二層モデル

共通調達基準は、ラベル要件とサイト要件を一枚に混ぜない方が運用しやすくなります。ラベル要件は製品ベンダーが示す証拠、サイト要件はSIと工場が示す証拠です。

製品・ラベル層では、登録番号のQRコードやURLがIPA管理の製品情報ページへ到達することを確認します。IPAは正規ページのURLが https://jc-star.ipa.go.jp/conformance/ から始まることを確認するよう案内しています。ベンダー資料上のロゴ画像だけを証拠にしません。

工場・導入層では、設計時に想定した通信だけが許可され、不要サービスが無効で、個別認証情報が設定され、管理経路が分離されていることを確認します。製品に安全機能があっても、初期パスワードのまま、全ポート開放、常時接続のベンダーVPN、更新停止という状態なら、調達目的は達成できません。

より広いタイ工場のOTセキュリティ設計は、資産可視化、ゾーンとコンジット、リモートアクセス、インシデント対応を含めて考える必要があります。また、海外拠点特有の接続と費用分解は海外工場IoT導入の費用・投資回収も参考になります。本記事はその中でも、JC-STARを調達文書と受入証拠へ変換する部分に焦点を絞ります。

制度申請そのものを担当する方はJC-STAR申請ガイド2026を、候補製品の探し方を優先する方はJC-STAR認証IoT機器の調達・メーカー確認を参照してください。本記事ではそれらと重複する申請書の逐条説明や製品一覧ではなく、本社基準を海外工場のRFP、FAT/SAT、更新監視へ落とす工程を扱います。

JC-STAR 工場向けRFPの書き方：要件・回答・証拠を分ける

RFPは「対応していますか」というYes/No質問を避けます。要件、ベンダー回答、提出証拠、確認時点、未達時の扱いを一組にします。次のひな型は、製品類型やリスクに合わせて調整する実務例です。

RFP条項1：対象製品とラベルの同一性

要件例：提案する各IoT製品について、製造者、製品名、販売型番、地域SKU、ハードウェア版、ファームウェア版、必須付随サービス、JC-STAR登録番号、レベル、有効期限、IPA製品情報URLを一覧で提出すること。提案構成がラベル対象範囲に含まれる根拠を示すこと。

証拠：IPA製品情報ページ、型番表、版対応表、構成図。代理店の宣誓だけではなく、ラベル取得事業者が公表する情報と照合します。

RFP条項2：適用レベルと不足要件

要件例：調達時点で取得済みのレベルを記載し、未取得の上位レベルを「対応」と表現しないこと。要求レベルが取得不能な製品類型の場合は、理由と同等統制の証拠を提示すること。

証拠：現行のIPA適合基準、チェックリスト対応表、外部評価報告の範囲、例外申請。将来ロードマップは取得済み証拠から分離します。

RFP条項3：認証・初期設定・秘密情報

要件例：製品ごと、または安全な初期登録手順により一意な認証情報を設定できること。共有デフォルト資格情報を使用しないこと。初回起動、交換、工場初期化、所有者変更、秘密情報ローテーションの手順を提出すること。

証拠：設定画面、API仕様、初期登録ログ、工場出荷状態からの実演、秘密情報を含まない設定エクスポート。

RFP条項4：脆弱性受付とセキュリティ更新

要件例：脆弱性報告窓口、受付言語、応答SLA、CVE等の通知方法、更新提供期間、署名・完全性確認、配布経路、オフライン更新、ロールバック、緊急更新、更新失敗時の復旧を示すこと。

証拠：公開脆弱性方針、サポート期間表、署名検証ログ、更新パッケージ例、復旧手順、過去のアドバイザリ例。提供期間は「長期」ではなく終了日または算定規則で回答させます。

RFP条項5：通信、ログ、時刻

要件例：送受信先、プロトコル、ポート、名前解決、証明書、クラウド依存、遠隔保守経路を全て申告すること。認証、設定変更、更新、管理操作、異常通信のログを外部取得でき、工場の時刻基準と同期できること。

証拠：通信マトリクス、パケットキャプチャ、ログ例、時刻同期設定、クラウド停止時の動作、データ保持・削除方針。

RFP条項6：サプライチェーンと変更通知

要件例：主要ソフトウェア構成、OSS、第三者クラウド、委託保守、製造終了、部品変更、ファームウェア変更がセキュリティ評価やラベル状態へ与える影響を通知すること。

証拠：SBOMまたは同等の構成情報、変更管理手順、EOL/EOS通知例、再評価判断フロー。SBOM提出だけを目的にせず、脆弱性発見時に対象機を特定できる粒度を求めます。

ベンダー比較表は「ラベルあり／なし」から証拠成熟度へ進化させる

価格比較表の横に星の数だけを置くと、製品範囲や運用能力の差を見落とします。比較スコアは少なくとも次の軸に分けます。

1. ラベルの真正性と有効性：登録番号、版、対象構成が一致するか。
2. 要求レベルとの適合：製品類型と用途に対して妥当か。
3. 更新可能性：オンライン・オフライン双方の更新、署名検証、ロールバックがあるか。
4. 運用可視性：ログ、資産識別、ファームウェア版、通信先を中央で確認できるか。
5. 現地支援：タイ語・英語での一次対応、交換在庫、現地作業、時差をまたぐ緊急連絡があるか。
6. ライフサイクル：EOL/EOS通知、保守年数、部品変更、クラウド終了時の移行策があるか。
7. 検証可能性：FAT/SAT用のテスト環境、設定証拠、失敗ケースを提供できるか。

各軸に「必須」「加点」「例外承認」を付けます。価格が低くても、更新が現地出張のみ、クラウド停止で機能喪失、ログ出力不可、EOL通知なしなら、海外工場の総保有コストは高くなります。逆に、高機能な製品でも工場リスクに不要な要件を過剰要求すれば、納期と運用負荷を上げます。

FATで確認すること：出荷前に製品と証拠を固定する

FAT（Factory Acceptance Test）は、製造者またはSI環境で、納入前に製品機能と設計適合を確認するゲートです。JC-STAR関連では、ラベルPDFを見るだけでなく、納入版と証拠の同一性を固定します。

FAT-1：ラベル対象範囲と納入BOMの照合

発注書、納入BOM、製品銘板、箱、管理画面の型番・版を照合します。必須付随サービスやクラウドプランがラベル対象の前提なら、契約に含まれることを確認します。地域SKUや無線モジュールの差がある場合は、ラベル取得事業者の書面で範囲を確認します。

FAT-2：安全な初期化と個別設定

工場出荷状態から起動し、初期認証情報の設定、不要アカウントの無効化、最小権限ロール、証明書登録、設定バックアップまでを通します。同一製品二台で同じ秘密情報が使われていないこと、工場初期化後に古い所有者の情報が残らないことも試します。

FAT-3：通信許可リストの実測

提案通信マトリクスとパケットキャプチャを比較します。未申告のDNS、NTP、分析、広告、遠隔支援先がないか、クラウドへ到達できないとき制御機能がどうなるかを確認します。暗号化の有無だけでなく、相手認証、証明書期限、失効、再発行も対象です。

FAT-4：更新・改ざん・ロールバック試験

正規更新、署名不正更新、途中切断、容量不足、互換性不一致を試します。不正パッケージが拒否され、失敗後も安全状態へ戻り、監査ログが残ることを確認します。ロールバックが可能な場合も、既知脆弱版へ無制限に戻せない統制を確認します。

FAT-5：ログと脆弱性対応の机上演習

管理者ログイン失敗、設定変更、時刻変更、更新、再起動、証明書エラーを発生させ、ログを外部SIEMまたは保管先へ出します。仮想的な重大脆弱性通知を使い、誰が日本本社、タイ工場、SI、ベンダーへ連絡し、どの資産を抽出し、何時間で暫定対策を判断するかを演習します。

FAT結果には、テストID、要件ID、対象シリアル、版、前提、操作、期待結果、実結果、証拠ファイル、差異、責任者、期限を残します。「合格」の署名だけでは、後日再現できません。

SATで確認すること：タイ工場の実ネットワークと運用で受け入れる

SAT（Site Acceptance Test）は、設置先の人、ネットワーク、時刻、電源、保守経路、言語で試す工程です。FAT合格はSATを省略する理由になりません。

SAT-1：ゾーン配置と到達制御

実際のVLAN、ファイアウォール、DMZ、ジャンプホスト、VPNを使い、許可された経路だけが通ることを確認します。生産系からインターネットへの直接通信、ベンダー常時VPN、共有保守PC、管理ポートの一般LAN露出がないかを確認します。必要な例外は期限、所有者、監視条件を付けて登録します。

SAT-2：現地ID運用と退職・異動

日本人管理者だけでなく、タイ人運用者、保全、外部SI、監査者のロールを作り、業務に必要な権限だけを付けます。承認、MFA、緊急アカウント、定期棚卸し、退職・異動時の停止を現地手順で試します。手順書が日本語だけなら、現地で回りません。

SAT-3：停電・回線断・クラウド断

安全に実施できる範囲で停電、上位ネットワーク断、DNS/NTP断、クラウド断を模擬します。生産安全への影響、ローカル継続、データ欠落、復旧順序、時刻ずれ、再認証を確認します。セキュリティ機能が可用性を不必要に損なわず、障害時に保護が消えないことが重要です。

SAT-4：現地更新とロールバック

実際の帯域、プロキシ、承認、保全時間帯で更新します。日本から遠隔で実行する場合、現地の安全確認、作業許可、停止条件、緊急中止、復旧責任を明確にします。更新後はファームウェア版、設定差分、通信、ログ、制御機能を再確認します。

SAT-5：証拠引渡しと教育

資産台帳、ネットワーク図、通信マトリクス、アカウント台帳、バックアップ、更新手順、脆弱性連絡、EOL一覧、FAT/SAT証跡を日本本社とタイ工場が共同で受領します。現地担当が「アラートを見て、対象機を特定し、一次隔離し、ベンダーへ証拠を送る」演習を完了して初めて運用受入とします。

更新監視を調達契約へ組み込む：有効期限より先に見る項目

運用開始後は、ラベルの有効期限だけでなく、製品の変化を監視します。月次では資産台帳と実機版、公開脆弱性、ベンダー通知、保留中の更新を確認します。四半期ではIPA製品情報ページのステータス、サポート期間、管理アカウント、通信先、例外ルールを棚卸しします。年次では復旧、緊急連絡、ベンダー交代、退役を演習します。

変更を次の三種類に分けると判断が安定します。

• 通常変更：軽微な修正、設定変更。承認済み手順で適用し証拠を更新する。
• セキュリティ重要変更：認証、暗号、通信先、クラウド、主要コンポーネント、更新方式の変更。再FATまたは限定SATを行う。
• 適合影響変更：ラベルの自己適合宣言へ影響し得る仕様変更、対象版の変更。ラベル取得事業者へ確認し、IPAへの報告・取下げ・再申請の要否を証拠化する。

脆弱性が公表されたときは、CVSSの数字だけで停止判断をしません。工場での到達可能性、攻撃前提、制御影響、安全影響、代替統制、更新可否を評価します。緊急更新できない場合は、通信遮断、機能停止、資格情報変更、監視強化などの暫定策と期限を設定します。

JC-STAR 調達要件の例外管理

既設設備に接続するゲートウェイ、長納期の専用機器、海外専用SKUでは、要求するラベルを取得した候補がない場合があります。例外を口頭で認めると、標準が形骸化します。例外票には次を残します。

• 対象製品、設置場所、用途、データ、ネットワーク到達範囲。
• ラベルを満たせない理由と市場調査日。
• 同等性を示す基準、試験、第三者報告、ベンダー証拠。
• 補完統制：分離、通信制限、監視、保守制限、予備品、交換計画。
• 残余リスク、承認者、有効期限、再評価日。

例外の有効期限は、製品の保守期限、次回定修、代替製品の発売見込みなどと結び付けます。「一度承認したから恒久」としません。例外件数と期限超過を本社ダッシュボードで追えば、調達基準が現場で機能しているかを測れます。

90日で展開する本社・タイ工場の実行計画

0〜30日：対象と基準線を揃える

本社調達、サイバーセキュリティ、工場IT/OT、設備、品質、現地SIで責任者を決めます。既存のIP通信機器を台帳化し、JC-STAR対象候補、ラベル有無、重要度、更新可否、EOLを分類します。RFPひな型と例外票を作り、正規のIPA製品ページを証拠とするルールを定めます。

31〜60日：一製品・一ラインでFAT/SATを回す

ネットワークカメラ、ゲートウェイ、センサーなど更新・ログを試しやすい一製品を選びます。RFP回答を証拠付きで受け、FATで版、初期化、通信、更新、ログを確認します。タイ工場の限定ゾーンへ設置し、SATでID、遮断、復旧、現地教育を試します。

61〜90日：契約と監視へ定着させる

テストで判明した不足を標準条項へ戻し、購買条件、検収条件、保守SLA、変更通知へ反映します。IPAステータスと実機版を定期照合する担当と周期を決めます。例外、更新遅延、サポート終了、重大脆弱性のKPIを経営・工場レビューへ載せます。

この90日は全工場を一斉に認証する期間ではありません。一つの調達案件で、要求から証拠、受入、運用監視まで閉じた型を作り、他拠点へ複製できる状態にする期間です。

FAQ：JC-STAR 海外拠点・タイ工場のよくある質問

JC-STARとは何ですか？

IP通信機能を持つ幅広いIoT製品を対象に、セキュリティ機能の適合性を共通基準で確認・可視化する日本の任意制度です。★1は共通の最低限要件、★2以上は製品類型や高い信頼性を踏まえた段階です。対象外製品やシステム全体まで保証する制度ではありません。

JC-STAR タイ工場で必須ですか？

JC-STAR自体は日本の任意制度で、タイ工場一般に一律必須という意味ではありません。ただし、日本本社がグループ共通の機器選定基準として指定することはできます。現地法令、顧客要求、業界規則は別途確認が必要です。

JC-STAR 工場の全システムを保証しますか？

保証しません。ラベルの対象は登録されたIoT製品とその範囲です。ネットワーク設計、クラウド、アカウント、設定、保守接続、運用者、更新手順まで含む工場システム全体は、RFP、設計レビュー、FAT/SAT、運用監視で確認します。

JC-STAR 調達要件では★1と★3のどちらを指定すべきですか？

星の数字だけで決めず、製品類型、利用可能な基準、工場での重要度、攻撃時の安全・生産影響、第三者評価の必要性で決めます。取得不能なレベルを一律必須にせず、適用可能性をIPAの最新情報で確認します。

JC-STARの費用と有効期間は？

2026年9月9日時点のIPA案内では、★1の通常申請手数料は198,000円（税込）です。評価機関や検証事業者に支払う費用は含まれません。新規ラベルの有効期間はレベルによらず発行日から最大2年間です。レベル、延長、相互承認で条件や費用が異なるため、申請直前にIPAの現行ページを再確認してください。

JC-STARと海外制度の相互承認があれば追加確認は不要ですか？

不要にはなりません。英国PSTIやシンガポールCLSとの相互承認は、合意された要件と手続きの範囲に限られ、追加申請や情報提供が必要です。タイ法令への自動適合でもありません。制度、方向、製品範囲、除外地域、追加費用を案件ごとに確認します。

IoT機器 セキュリティ 調達基準で最低限求める証拠は？

IPA製品情報URL、登録番号、対象型番・版、有効ステータス、脆弱性窓口、更新提供期間、通信マトリクス、初期設定、ログ例、EOL/EOS方針、FAT/SAT結果です。ロゴ画像や「準拠予定」という営業資料だけでは不十分です。

まとめ：日本の基準線とタイ現場の証拠を一つの調達プロセスにつなぐ

JC-STAR 海外拠点活用の価値は、星の付いた製品を買うことだけではありません。日本本社が製品セキュリティの共通言語を持ち、タイ工場が実構成で安全性と運用性を試し、ラベル・ファームウェア・脆弱性・保守期限を継続監視できることにあります。

実務では、対象製品と版を確認し、適切なラベルレベルを選び、RFPで回答証拠を指定し、FATで製品と納入版を固定し、SATで現地ネットワークと人の運用を確認します。相互承認は範囲を限定して読み、現地法令適合とは分離します。最後に更新・失効・EOLを監視し、例外を期限付きで管理します。

TOMAS TECHでは、タイ工場向けIoT・OT案件について、対象機器の棚卸し、調達要件の整理、通信・権限設計、FAT/SAT項目、現地運用への落とし込みを支援できます。製品選定前やRFP作成段階でも、現場制約を踏まえた整理からお問い合わせいただけます。

参考一次情報

• IPA：JC-STARトップページ
• IPA：JC-STAR制度の詳細情報
• IPA：申請手続き・報告手続き
• IPA：適合ラベルの確認方法
• IPA：適合ラベル取得製品リスト
• IPA：JC-STAR活用に向けた取り組み
• IPA：英国PSTI法適合の相互承認申請
• METI：JC-STAR運用開始
• METI：特定分野システムのIoT製品におけるJC-STAR制度活用ガイド
• METI：日本・シンガポールの相互承認覚書

※制度、手数料、相互承認、適合製品の状態は更新されます。本記事は2026年9月9日時点の公開情報に基づきます。調達・申請・法令判断の直前に、IPA、経済産業省および該当国当局の最新情報を確認してください。