まず押さえたいJC-STAR制度の基礎と「★1」要件のポイントとは？

日本独自のIT製品のセキュリティの見える化ラベリング制度として2025年3月にスタートした「JC-STAR」。開始から約1年が経過し、制度の浸透とともに市場の実態に合わせたアップデートが実施されました。

今回は、JC-STAR制度の現在の普及実績や申請のリアルな現場感、そして間もなく実施される予定の「★ 1要件の改定ポイント」について、実務目線で詳しく肉付けして解説します。

1.  JC-STAR制度のおさらいと、1年間で見えた申請のリアル

JC-STARは、「どの製品のセキュリティが安全か分からない」という消費者と、「対策を組み込んでもアピールしにくい」というベンダー双方の課題を、適合ラベルという目印を介して解決する制度です。

対象となるのは、以下の3条件を満たすハードウェアです。

1. 物理的な筐体があること
   → ソフトウェア単体やクラウドは対象外
2. インターネット間通信（IP通信）を受信できること
   → 実際に通信機能を使うか否かに関わらず、IP通信ができる仕組みを持っていれば対象
3. 使えるセキュリティ機能がベンダーから提供されること
   → 出荷時組み込み、またはベンダーによるアップデート。製造ベンダーが責任を持つ形

まずは最低限の脅威に対抗できる「★ 1（自己適合宣言形式）」からスタートしましたが、この1年間で80社・199ラベルが発行されました。1つのラベルに複数の製品型番を紐付けられる仕組みのため、実質的にはすでに1,500以上の製品にラベルが付与されており、市場への普及は非常に順調です。

ラベルにはQRコードが付随しており、IPAが管理する製品情報ページへ遷移します。ここでは、製品が現在も有効か、あるいは脆弱性対応の遅れなどで失効・取り消しされていないかという「適合ラベルステータス」が逐次更新されます。購入検討者が今この瞬間に有効な製品かを確認できるのが大きな特徴です。

 申請から取得にかかる期間のばらつき

よくある質問として「取得までにどのくらいかかるか」という点がありますが、過去228件のデータ分析によると一律の目安はありません。平均値と中間値が1週間ずれていることからも、幅が非常に広いことが分かります。

確認作業がスムーズにいけば1ヶ月〜1ヶ月半ほどで発行されますが、エビデンスの確認作業が難航した場合は3ヶ月以上かかるケースもあります。これは事務局の混雑度というよりも、申請内容の深さやばらつきによるものです。予定通りのリリースを目指すには、余裕を持った申請スケジュールが不可欠です。

2.  サプライチェーンリスクの深刻化とデフォルトオンの問題

なぜ今、★ 1の要件が見直されるのでしょうか。その背景には、ここ数年で激変したIoTの脅威環境があります。

特に近年深刻化しているのが、「レジデンシャルプロキシ」と呼ばれるIoTを踏み台にしたサイバー犯罪です。警察庁の統計によると、IoTを使ったサイバー被害のうち、このレジデンシャルプロキシによるものが、実に40%以上を占めています。

直近の事例では、家庭用デバイスに不正なSDK（ソフトウェア開発キット）が混入し、出荷時点からボットネットのウイルスが組み込まれていたケースや、太陽光発電のインバーター内部の通信機器に不正な仕組みが仕込まれていたケースなど、サプライチェーン全体を狙った攻撃が急増しています。

特にサプライチェーンにおいて問題視されているのが、使用しない機能がデフォルトでオンになっているという点です。今回の要件改定は、こうしたリスクの放置を防ぎ、より実効性の高い対策へシフトするために行われます。

3.  間もなく実施！「★ 1」要件改定の3つの重要ポイント

今年度下期には「現行要件」と「新要件」の併用期間が設けられ、年度内には現行要件の受付が終了します。来年度からの完全移行に向けて、改定される16要件のうち、実務上特に注意すべき変更点は以下の3点です。

① ラベル取得製品を組み込む側の評価明確化

「適合ラベルを取得している他社製の通信モジュールを使っているから、自社製品も自動的にOK」という申請は通らなくなります。利用しているだけでは評価免除の根拠にはなりません。

• 機器設定の確認（必須）： 自社製品に組み込んだ際、適切な設定が行われているかの確認・評価が必要です。
• 動作の確認（免除）： 適切に設定された際、モジュールが正しく動作するかどうかの確認は、元製品がラベルを取得しているため免除されます。
• 脆弱性検査（必須）： 製造元ベンダーが脆弱性対応した条件（適合バージョン）が、自社製品側でも適切に適用されているというエビデンス確認が必要です。

② 脆弱性対応方針の一般公開が必須化

これまでは契約者やユーザー限定での公開も認められていましたが、改定後は一般公開が必須となります。 これは脆弱性の詳細をすべて公開させるという意味ではなく、企業として「脆弱性にどういう方針で対処し、どこに報告窓口があるのか」という対応プロセスの整備と開示を求めるものです。あわせて、IPAや適切な届け出機関への報告プロセスを社内に整備することも要件に追加されます。

③ 暗号通信に対する保護対策の必須化

これまでは保護された専用回線が別途提供されていれば良しとされていましたが、改定後はIoT機器自らが保護対策を行うことが必須になります。 ただし、すべての通信データを一律に暗号化せよという意味ではなく、対象は「CSP（クリティカルセキュリティパラメーター：秘密鍵やパスワードなど、漏洩するとアクセス制御機能そのものが崩壊してしまう情報）」に限定され、保護すべき対象が明確化されました。

4. まとめ：来年度からの新要件移行に備えを

なお、改定に伴い「送信しか行わない機器」については、要件の中で対象外となることが明文化される見込みです。

現行の★ 1要件での受付は今年度内で順次終了します。これから申請や製品開発を検討されている企業様は、併用期間のうちに新しい基準に準拠できるよう、開発プロセスの見直しを進めていきましょう。