家庭用ルーターに★1があれば、重要インフラでも十分なのか。★3を取れば、どんな設置でも安全なのか。どちらも違います。JC-STARの星は商品の総合点ではなく、定められた製品類型・レベルの適合基準へ、どの評価方式で適合したかを示します。
JC-STARのレベル選定は「取れる最高の星」ではなく、製品類型、想定脅威、利用環境、調達者が必要とする評価の信頼性を一致させる作業です。
本記事は2026年9月2日時点のIPA JC-STAR公式情報、規程、★1評価ガイド、2026年に公開された通信機器・ネットワークカメラの★3情報を基にしています。制度文書は更新されるため、申請時は最新版の規程、適合基準、評価手順、様式を確認してください。
まず機器と必須付随サービスの境界を引く
機器だけでは目的を果たせないapp・cloudを評価対象へ戻します。
JC-STARが扱うIoT製品は、IPを使って通信し、利用者が本体へソフトウェアを容易に追加して対策することが難しいIoT機器と、その目的提供に必須のデジタルサービスを含みます。カメラ本体だけでなく、映像を見るcloudやappがなければ目的を果たせないなら、必須付随サービスを評価境界へ入れます。
製品構成表にhardware型式、firmware、radio、app、cloud、account、update server、初期設定、地域別差分を記載します。同じブランド名でもOEM元、cloud、firmwareが違えば、同一申請で扱えるかを確認します。
汎用PCへ後から導入するsoftwareと、利用者が容易に対策を追加できない組込みIoTを混同しません。製品の販売説明ではなく、実際の機能、network接続、利用者の変更可能性で判断します。
製品境界からcloudやappを外すと申請資料は軽くなりますが、利用者の攻撃面は軽くなりません。意図する用途に必須なら構成と責任へ戻します。
★1を「簡単な自己申告」と読まない
自己評価でも、実機テストと再現できる証拠が必要です。
★1は、IoT製品共通で最低限求めるセキュリティ要件を、ベンダーが評価手順に従って自己評価し、チェックリストを提出する方式です。第三者認証ではありませんが、単なる宣誓でもありません。実機テストを含む評価手順と証拠が必要です。
初期認証、脆弱性の低減、update、データ保護、利用者への情報、問い合わせ窓口などを、製品版へ紐付けます。チェック欄へ適合と書いても、試験条件、結果、firmware、担当者がなければ再現できません。
自己評価の信頼性はベンダーに依存するため、独立した社内review、指定資格者、必要に応じたJC-STAR検証事業者を使います。外部へ委託しても、申請主体が製品仕様と運用を把握しなければ変更時に維持できません。
チェックリストの回答を、実機、版、試験条件、ログ、利用者文書へ戻せるようにします。
★1の品質差は星の数には出ません。チェックリストを実機・ログ・設計・運用へ戻せる会社と、回答文だけを作った会社で信頼性が分かれます。
IoT導入の進め方で調達する側は、★1を入口にしつつ、自社networkと停止影響に固有の要件を追加します。
★2以上は製品類型が決まってから比べる
同じ星でも類型ごとに要件が違い、上位levelは評価方式も変わります。
★2は製品類型の特徴を踏まえ、★1へ追加する基本要件をベンダーが自己適合宣言する位置付けです。★3・★4は政府機関、重要インフラ、地方公共団体、大企業等の重要systemで使う製品を想定し、独立した第三者評価機関の評価報告に基づき認証します。
上位levelほど項目や水準は一般に増えますが、同じ星でも製品類型ごとに適合基準が違います。通信機器の★3とnetwork cameraの★3を、同じ要件表だと扱いません。
販売部門が「★3対応予定」と先に約束する前に、対象類型、公開済み基準、評価機関の利用可能性、試験環境、開発変更、発売日を確認します。基準が未整備の類型へ星だけを予約できません。
★2以上は★1へ数字を足す仕組みではなく、製品類型の脅威と利用形態に合わせて追加要件を評価する仕組みです。対象基準の版を契約へ書きます。
申請日より前に製品版を凍結する
試験対象と量産品のhardware、firmware、app、cloudを一致させます。
申請資料、チェックリスト、試験対象、利用者文書、脆弱性窓口が同じ版を指す必要があります。量産直前にSDK、cloud API、初期password、update certificateを変えると、試験結果が販売品を説明しなくなります。
release candidateを決め、hardware BOM、firmware hash、app版、cloud release、設定、地域差をbaseline化します。緊急security fixは止めず、評価への影響と再試験を変更管理で処理します。
申請中の営業サンプルと量産品、評価機関へ出す機器、店頭展示機が異なる場合、その差分を記録します。工場初期化や鍵注入は試験室で再現しにくいため、製造工程の証拠も用意します。
ラベルが説明できるのは評価した製品版です。試験後の「小さな変更」を積み重ね、販売品が別構成になることを防ぎます。
有効期限ではなく変更イベントを監視する
期限内の仕様変更が評価根拠を古くする瞬間を検知します。
ラベルには有効期間がありますが、期限内なら何を変えても有効という意味ではありません。セキュリティ仕様等に評価へ影響する変更があれば、ベンダーが確認してIPAへ報告し、ラベルが失効する場合があります。
change triggerに、認証、暗号、update、cloud provider、データ保存、network interface、外部SDK、サポート終了、会社・製品名を置きます。変更ticketにJC-STAR影響欄を設け、product securityとregulatoryが承認します。
市場の箱に古いラベル、ECに新しい説明、製品listで失効という不一致を防ぐため、登録status、梱包、web、販売店、在庫を同じlabel recordへ結びます。
期限だけでなく、認証・更新・cloud・SDKの変更が元の評価へ与える影響をrelease前に確認します。
JC-STARの維持で最も見落としやすいのは期限切れではなく、期限内の仕様変更で評価根拠が古くなることです。
EUサイバーレジリエンス法へ同じ製品を対応させる場合、PSIRT、SBOM、更新証拠を共通化し、制度固有の報告とラベルを分けます。
調達者は星より製品情報ページを見る
登録status、対象型式、level、supportを実際の納入品と照合します。
IPAの製品listでは登録番号、事業者、製品名、level、statusを確認でき、個別ページで対象型式や情報を見られます。見積書にロゴ画像があるだけで合格にせず、登録statusと実際に納入される型式・版を照合します。
★1は最低限の共通要件を示しますが、病院、工場、自治体、家庭で必要な可用性、ログ、network分離、保守時間は違います。調達仕様には利用環境固有の脅威、support period、patch SLA、初期設定、廃棄、cloud停止、データ返却を追加します。
複数候補を比べる時、星の高い製品を自動勝者にしません。必要levelを満たしたうえで、適合範囲、更新実績、脆弱性窓口、導入設定、運用費、終了時のデータ削除を比べます。
調達で確認するのはロゴの画像ではなく、登録status、対象型式、適合level、必須付随サービス、サポート条件が納入品と一致しているかです。
ラベルを製品開発の後付け書類にしない
発売直前に申請担当が開発へ証拠を求めると、初期password、update失敗、data deletionなどの不足が設計変更になり、発売遅延が大きくなります。企画時に対象levelと製品境界を決め、要件をproduct requirementへ入れます。
design reviewでは、要件ごとにowner、実装component、abuse case、test、利用者説明、運用を確認します。例えばデータ削除は本体初期化だけでなく、cloudに残るaccount・映像・履歴、譲渡時の旧所有者accessを含めます。製造時の共通credentialやdebug interfaceも量産工程で検証します。
品質保証は合否だけでなく、試験が失敗した時の再現条件と修正範囲を記録します。security bugを個別patchで閉じず、同じcomponentを使うmodelへ横展開します。発売判定では未解決項目、暫定策、supportへの引継ぎを経営が承認します。
JC-STAR対応を発売前の書類作りにすると高くつきます。企画・設計・製造・supportの出口条件へ要件を入れれば、評価証拠は開発の副産物として残ります。
発売後は、問い合わせと脆弱性報告を次モデルの要求へ戻します。初期設定で利用者が迷った、update失敗から復旧できない、cloud退会後に本体が残るといった事象は、説明書の問題だけでなく製品能力の問題です。support ticket、返品理由、security caseを製品版と結び、同じ失敗が次の評価で再発しないか確認します。
調達者から独自質問票を受けた場合も、JC-STAR回答と矛盾する個別回答を営業が作らず、security caseから根拠を出します。答えられない要件は「ラベル取得済み」で隠さず、非対応、代替control、将来計画を明記します。
取引先サイバーリスク管理を使い、OEM・cloud・SDKの証拠提出、脆弱性通知、変更承認を契約へ入れます。
医療機器サイバーセキュリティのように他の法規制がある製品では、JC-STARだけで安全・有効性の全要件を代替しません。
海外ラベルとの相互承認は範囲を読む
共通証拠を再利用し、国ごとの追加条件と表示を分けます。
JC-STARはETSI EN 303 645やNIST IR 8425などとの調和を意識し、英国PSTI法やシンガポールCLSとの協力・相互承認が進んでいます。2026年6月にはシンガポールCLSとの相互承認が始まったとIPAが案内しています。
相互承認は「どの国でも同じ星がそのまま使える」という意味ではありません。対象level、製品類型、追加文書、申請主体、表示、言語、法的義務の範囲を確認します。
U.S. Cyber Trust Markへ展開する場合も、共通security caseを作り、country matrixで差分を管理します。国ごとに別の試験結果とサポート期限を持たない設計が効率的です。
100日で一製品を取得・調達可能にする
製品境界、証拠、試験、申請、変更、更新を一巡させます。
最初の20日で対象製品、必須付随サービス、類型、利用環境、必要levelを確定します。
21日目から50日目は適合基準を仕様、実機試験、運用、利用者文書へ割り当て、不足を修正します。
51日目から75日目はrelease candidateを固定し、独立reviewまたは評価機関を通し、製造初期設定とupdateを再現します。
76日目から100日目は申請、製品情報、梱包、EC、change control、脆弱性対応をつなぎます。KPIは未証拠項目、再試験率、版差異、更新到達、失効反映時間です。
取得前の合格条件はチェックリストが完成したことではなく、販売版の実機で評価を再現し、変更時にラベルを止め、利用者へ更新を届けられることです。
まとめ
星の数を、利用環境と評価の信頼性を選ぶ判断へ戻します。
JC-STARは、星が多いほどあらゆる環境で安全だと保証する制度ではありません。製品と必須サービスの境界を決め、適合基準の版へ証拠をそろえ、利用目的に合う評価の信頼性を選ぶ制度です。
JC-STARのレベル選定は星の数から始めず、利用者、設置環境、製品版、連携サービス、更新責任の境界を先に固定してから決めます。
参考情報
以下は2026年9月2日に確認した一次情報です。
よくある質問
気になる質問を開くと、本文の重要点を短く確認できます。
QJC-STARは全てのIoT製品に義務ですか？
AJC-STARは適合性を可視化するラベリング制度です。調達仕様や関連制度で求められる場合はありますが、対象・義務の有無を製品用途、販売先、契約、最新政策で確認します。
Q★1は書類だけの自己申告ですか？
Aベンダーの自己適合宣言方式ですが、公開された適合基準・評価手順に従う評価と、実機テストを含む証拠が必要です。単なる方針宣言ではありません。
Q★3なら★1より必ず自社に向いていますか？
A★3は第三者評価と高い要件を持ちますが、対象製品類型と利用想定があります。調達者は必要水準、対象型式、運用条件、費用を合わせて判断します。
Qラベルの有効期間中は製品を自由に変更できますか？
A評価へ影響するセキュリティ仕様等の変更は確認・報告が必要で、ラベルが失効する場合があります。認証、update、cloud、SDKなどをchange triggerとして管理します。
Q調達時は箱のJC-STARロゴだけ見ればよいですか？
AIPAの製品listと個別情報で、登録status、事業者、製品名、型式、levelが納入品と一致するか確認します。サポート、patch、設置条件は契約で補います。
Q海外ラベルとの相互承認で追加申請は不要ですか？
A相互承認には対象level、製品、追加資料などの範囲があります。相手国の法令・表示まで全て自動的に満たすとは限らないため、公式手続を確認します。
