はじめに
自社で使っているネットワーク機器の製造国を、あらためて確認する動きが広がっています。2026 年に入ってから、米国では外国製ルーターが規制対象に加わり、日本でも自治体の IT 機器調達を認定製品に限定する方針が示されました。中国製ルーターに出荷時点でリモート制御機能が組み込まれていた事案も報告されています。
こうした報道は多い一方で、実務担当者が知りたいこと、つまり「自社の機器をどう扱えばよいのか」「次の調達で何を基準にすればよいのか」に答えたものは多くありません。規制の解説と、自社の判断基準づくりの間には距離があります。
- 2026 年の米国 FCC と日本の総務省による規制が、実際に何を制限しているのか
- 規制報道でしばしば誤って伝えられている、制限の範囲と対象
- 製造国を基準にした選別が機能しにくい構造的な理由
- 機器の採否を判断するための 4 つの軸と、その組み合わせ方
- 調達仕様書に転記できる確認項目と、既設機器への向き合い方
結論から述べます。規制の追加によって新規調達の選択肢は絞られますが、規制は既に設置されている機器には効きません。また、OEM / ODM を経由した供給構造がある以上、製造国やブランド名による選別だけでは判断しきれない領域が残ります。実務では、製造国を補助的な指標として扱いつつ、情報の重要度、ネットワーク上の位置、出口制御の有無、出所の説明可能性という 4 つの軸で個別に判断する方法が現実的です。
2026 年に何が変わったのか
2026 年は、ネットワーク機器の調達に関する制度環境が短期間で動いた年です。米国と日本でそれぞれ別の枠組みが動いており、対象も強制力も異なります。まず、何がどこまで決まったのかを整理します。
米国: FCC が外国製ルーターを Covered List に追加
2026 年 3 月 23 日、米国連邦通信委員会（FCC）は、外国で製造されたコンシューマー向けルーターを Covered List に追加しました。Covered List は、米国の国家安全保障または米国人の安全に対して受け入れがたいリスクをもたらすと判断された通信機器・サービスの一覧です。
追加の根拠となったのは、ホワイトハウスが招集した行政府の省庁横断組織による判断です。FCC の説明によれば、この判断では外国製ルーターについて、米国経済・重要インフラ・国防を混乱させうるサプライチェーン上の脆弱性をもたらす点と、重要インフラを即座かつ深刻に混乱させうるサイバーセキュリティ上のリスクをもたらす点が挙げられています。過去に発生した Volt Typhoon、Flax Typhoon、Salt Typhoon の各攻撃キャンペーンで外国製ルーターが関与していたことも背景として示されています。
ここで押さえておきたいのは、制限の対象が「新規モデルの機器認証」に限られるという点です。日本語の報道では「外国製ルーターの輸入禁止」と要約されることがありますが、FCC 自身の説明は異なります。
参考: FCC Updates Covered List to Include Foreign-Made Consumer Routers（FCC Fact Sheet）
“…does not prohibit the import, sale, or use of any existing device models the FCC previously authorized.”
（FCC が過去に認証した既存の機器モデルについて、輸入・販売・使用を禁じるものではありません）
https://docs.fcc.gov/public/attachments/DOC-420034A1.txt
整理すると、次のようになります。
| 対象 | 扱い |
|---|---|
| 新規モデルの機器認証 | 取得できない（結果として輸入・販売ができない） |
| 認証済みの既存モデル | 輸入・販売・マーケティングを継続できる |
| 購入済みの機器の使用 | 制限されない |
| 既存機器へのファームウェア更新 | 少なくとも 2027 年 3 月 1 日までは実施できる |
| 例外の枠組み | Department of War（DoW）または国土安全保障省（DHS）による Conditional Approval を取得した製品 |
ファームウェア更新の扱いは、FCC 技術局が別途公表した文書で示されています。脆弱性の修正や OS 互換性の確保を含め、機器の機能を維持するための更新は継続できるとされています。
参考: OET Announces Waiver of Prohibitions on Certain Class I Permissive Changes to Covered Routers（FCC）
https://docs.fcc.gov/public/attachments/DA-26-286A1.txt
実務上の意味は限定的です。この規制は米国市場における新規モデルの流入を止めるものであり、日本国内の機器や、既に設置されている機器の扱いを変えるものではありません。 ただし、対象が特定国ではなく「外国で製造されたルーター」全般である点は、後述する製造国基準の議論と関わってきます。米国ブランドの製品であっても、製造が国外であれば対象に含まれるためです。
日本: 自治体 IT 機器を政府認定品に限定する方針
日本側の動きは、対象も枠組みも異なります。2026 年 4 月 20 日、総務省は、自治体が使用する IT 機器について、政府の評価制度で認定された製品のみを調達するよう義務付ける方針を固めたと報じられました。対象として伝えられているのは、パソコン、タブレット、通信機器、サーバー、クラウドサービスなどです。
認定の枠組みとして想定されているのは、次の 2 制度です。
| 制度 | 所管 | 対象 |
|---|---|---|
| JC-STAR | 経済産業省・IPA | IoT 製品のセキュリティ適合性を評価し、ラベルを付与する制度 |
| ISMAP | 国家サイバー統括室 | 政府が求めるセキュリティ要求を満たすクラウドサービスの登録制度 |
報道では、これらの認定製品に中国製が含まれていないため、結果として中国製機器が自治体調達から外れることになると伝えられています。運用開始は 2027 年夏が見込まれ、既に調達済みの機器については更新のタイミングで認定製品へ置き換える方針とされています。
制度の根拠となるのは、2024 年 6 月に成立した改正地方自治法です。同法は地方公共団体に対し、情報システムの利用にあたってサイバーセキュリティの確保などに必要な措置を講じる義務を課しています。この「必要な措置」の具体像を、地方自治法施行規則を改正する総務省令で示すという立て付けが想定されています。
ここで 1 点、正確を期すべき点があります。 上記はいずれも 2026 年 4 月時点の報道および方針に基づく内容であり、報道では 2026 年 6 月にも省令を改正するとされていましたが、本記事の執筆時点で、省令改正が実際に行われたことを公式情報で確認できていません。制度の詳細と適用範囲は、総務省の公表資料で最新の状況を確認することをおすすめします。
参考: 地方公共団体における情報セキュリティポリシーに関するガイドラインの改定等に係る検討会（総務省）
https://www.soumu.go.jp/main_sosiki/kenkyu/chiho_security_r03/index.html
民間企業に直接適用される制度ではありません。ただし、自治体や重要インフラ事業者との取引がある企業では、取引先の調達要件を通じて間接的に影響を受ける可能性があります。また、要件の立て方そのものは民間でも参考にできます。この点は後段で扱います。
なお、JC-STAR は現時点で IoT 製品を主な対象としており、パソコンやサーバーが同じ枠組みでカバーされるかは、制度の整備状況を確認する必要があります。認定制度を自社の調達要件に組み込む際は、対象製品カテゴリーの範囲を先に確認しておくと判断がぶれにくくなります。
個別ベンダーへの措置と、実装が確認された事案は別物
規制動向を追う際に混同しやすいのが、懸念に基づく措置と、実際に問題が確認された事案の違いです。この 2 つは、必要な対応がまったく異なります。
前者の例が TP-Link をめぐる動きです。2026 年 2 月、米テキサス州が同社を提訴し、同社製ルーターが中国政府の支援を受けた攻撃者に利用されていると主張しました。TP-Link 側はこの主張を否定しており、中国政府による所有や支配はないとの立場を示しています。現時点で、同社製ルーターから意図的に組み込まれたバックドアが発見されたという報告はありません。 法的な争いと安全保障上の懸念に基づく措置であり、技術的な発見に基づくものではない点は区別して扱う必要があります。
後者の例が、2026 年 8 月に公表された Zbtlink 製ルーターの事案です。こちらはファームウェアイメージの解析によって、出荷時点でリモート制御用の実装が含まれていたことが確認されています。CWE-506（Embedded Malicious Code）として分類されており、実装上の不具合ではなく組み込まれたコードとして扱われています。事案の詳細と、自組織に該当機器があるかを確認する手順は、関連記事『Zbtlink 20 機種の確認手順と日本での影響』で整理しています。
この違いは、対応の優先順位に直結します。
| 区分 | 判断材料 | 実務での対応 |
|---|---|---|
| 懸念に基づく措置 | 規制、訴訟、報道 | 調達方針の見直し、更新時期の再検討 |
| 実装が確認された事案 | 解析結果、CVE、検知ルール | 該当機器の特定、隔離、交換の検討 |
規制対象になったことと、その機器に問題が見つかったことは同じではありません。 逆に、規制対象になっていない機器が安全であるとも言えません。次章では、この「製造国で切る」という考え方がどこまで機能し、どこから機能しなくなるのかを整理します。
「製造国」で切る方法の限界
前章の規制は、いずれも調達段階で機器を絞り込む仕組みです。この方法がどこまで機能し、どこから機能しなくなるのかを整理します。結論を先に述べると、規制と認証制度は新規調達の下限を引き上げる効果を持つ一方で、既設機器と、供給構造が見えない機器には届きません。
認証制度と規制が実際に届く範囲
まず、FCC の Covered List も総務省の方針も、調達の入口に作用する仕組みです。前章で確認したとおり、FCC の規制は新規モデルの機器認証を止めるもので、既に設置されている機器には作用しません。総務省の方針も、調達済みの機器については更新のタイミングで置き換えるという設計です。現在ネットワークに接続されている機器の状態は、どちらの制度によっても変わりません。
次に、認証制度そのものの性質を確認します。日本の JC-STAR は 4 段階のレベルを設けており、レベルによって評価方法が異なります。
| レベル | 評価方法 | 位置づけ |
|---|---|---|
| ★1（レベル 1） | 自己適合宣言 | 製品共通の最低限のセキュリティ要件 |
| ★2（レベル 2） | 自己適合宣言 | 製品類型ごとに ★1 へ追加した基本要件 |
| ★3（レベル 3） | 第三者評価 | より高い水準の要件 |
| ★4（レベル 4） | 第三者評価 | 最も高い水準の要件 |
ここで実務上重要なのが、★1 と ★2 が自己適合宣言方式であるという点です。IPA は、ベンダーが評価結果を記載したチェックリストに基づいてラベルを付与しますが、その根拠となる証跡の提出は求めていません。IPA 自身がこの点を明示しています。
参考: セキュリティラベリング制度（JC-STAR）についての詳細情報（IPA）
「評価の信頼性はベンダーの信頼性に依存することになりますが、低コストかつ短期間で適合ラベルを取得することができます」
https://www.ipa.go.jp/security/jc-star/detail.html
同ページでは、適合ラベルが付与されていても完全・完璧なセキュリティを保証するものではないこと、適合基準が想定していない脅威がある運用環境では必要なセキュリティ機能が考慮されていない可能性があることも記載されています。
制度を否定する話ではありません。最低限の水準を業界全体で揃える効果は確かにあります。ただし、ベンダーの申告そのものが問題になる事案に対しては、自己適合宣言方式は設計上の前提が噛み合いません。 Zbtlink の事案は、まさにベンダー自身が出荷したコンポーネントが問題になったケースでした。ラベルの有無は、調達候補を絞る一次フィルターとして扱い、それだけで判断を終えない使い方が現実的です。
OEM / ODM の構造が製造国基準を無効化する
製造国やブランド名による選別が機能しにくい理由は、供給構造にあります。ネットワーク機器の多くは、製造元と販売ブランドが一致しません。
Zbtlink の事案は、この構造が実際に判定を難しくすることを示しました。同社の製品は Zbtlink、ZBT、ZBTWiFi、Wiflyer という複数の名称で流通しており、Amazon、Alibaba、Shopify での販売が確認されています。ロゴが異なっていても、型番が一致すれば同じハードウェアとファームウェアです。
さらに示唆的なのが、同社広報の説明です。The Register の取材に対し、同社は OEM / ODM のカスタマイズを専門としており、顧客は同社の既定ファームウェアではなく自社開発のソフトウェアを使用していると述べています。この説明を前提にすると、別ブランドで出荷された機器がどのファームウェアで動作しているかは、外部からは判定できないことになります。 製造元を特定できたとしても、そこから中身を推定する経路が閉じてしまいます。
参考: Chinese router vendor denies its firmware contains backdoors（The Register）
https://www.theregister.com/security/2026/08/06/chinese-router-vendor-denies-its-firmware-contains-backdoors-but-pauses-downloads-to-fix-security-issues-anyway/5283794
実務では、この構造が資産管理に直接影響します。資産台帳に記録されているのは通常、購入時のブランド名と機種名です。製造元がどこかという情報は、そもそも記録されていないことがほとんどです。手がかりとして使えるものと、その限界を整理します。
| 手がかり | 有効性 | 限界 |
|---|---|---|
| ブランド名 | 低い | OEM 供給では判定できない |
| 型番 | 高い | OEM 品では型番も変更される場合がある |
| MAC アドレスの OUI | 中程度 | OEM 品では取得元が異なることがある |
| FCC ID | 中程度 | 認証取得者を特定できるが、日本国内流通品では付与されないことがある |
| 管理画面のベース OS | 中程度 | OpenWrt 派生など、同系統であることの傍証になる |
単独で決め手になる手がかりはありません。 複数を組み合わせて確度を上げる進め方が現実的です。
製造国を問わず同じ問題が起きうる
製造国を判断軸の中心に置きにくい理由は、もう 1 つあります。同種の問題が、製造国にかかわらず発生している点です。
2026 年 7 月 29 日、Cisco は Secure Firewall Management Center（FMC）ソフトウェアの Web インターフェイスに、低権限アカウントの静的な認証情報が存在することを公表しました。CVE-2026-20316 として採番されており、認証を経ていないリモートの攻撃者が、この認証情報を用いてログインできる状態でした。
参考: Cisco Secure Firewall Management Center Software Static Credential Vulnerability（Cisco）
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-fmc-static-cred-BET3Cjh
この事案には、いくつか注目すべき点があります。CVSS v3.1 の基本値は 5.3 ですが、Cisco は他の FMC の脆弱性と組み合わせて権限昇格に利用されうるとして、Security Impact Rating を High に設定しています。また Cisco PSIRT は、修正が提供される前の 2026 年 7 月に悪用を確認したとしており、同日に CISA の Known Exploited Vulnerabilities カタログへ追加されています。ファイアウォールの管理基盤に、出荷時から固定の認証情報が含まれていた事案です。
Zbtlink の事案との違いを整理すると、次のようになります。
| 観点 | Zbtlink（CVE-2026-66747） | Cisco FMC（CVE-2026-20316） |
|---|---|---|
| 分類 | CWE-506（Embedded Malicious Code） | CWE-259（Use of Hard-coded Password） |
| ベンダーの認識 | 意図した機能と主張 | 脆弱性として認め、修正を提供 |
| 修正の提供 | 提供時期は示されていない | 修正リリースを公開 |
| 悪用の確認 | 確認されていない | 悪用を確認、KEV へ登録 |
性質は異なりますが、利用者の側から見ると共通する構造があります。 どちらも、機器やソフトウェアの中身を検証できないまま、ネットワークの境界や管理基盤に配置していたという点です。前者は意図の問題、後者は品質の問題ですが、検証できていないという状態は同じでした。
ソフトウェアサプライチェーンの領域でも同じことが起きています。2024 年に発見された XZ Utils のバックドア（CVE-2024-3094）は、広く利用されている圧縮ライブラリに、長期間にわたる関与を通じて悪意あるコードが混入した事案でした。製造国でも企業でもなく、依存関係の深さそのものが検証の難しさを生んでいます。
以上を踏まえると、製造国はリスクの事前確率を調整する情報としては意味を持ちますが、個別の機器を採用してよいかの判定基準としては単独で機能しません。次章では、製造国に依存しない形で判断するための 4 つの軸を整理します。
実務で使える 4 つの判断軸
ここまでの整理から、製造国は判断材料の 1 つではあるものの、それだけで採否を決められないことが見えてきました。実務では、機器ごとに次の 4 つの軸で評価する方法が現実的です。VulnCheck も、Zbtlink の事案について同じ趣旨の指摘をしています。
参考: ENDLESSDOORS Is Phoning Home. Pick Up.（VulnCheck）
“Treat this as a device-trust problem, not a patching problem.”
（これはパッチ適用の問題ではなく、機器の信頼性の問題として扱ってください）
https://www.vulncheck.com/blog/zbt-endlessdoors
4 つの軸は、前半 2 つが影響範囲を、後半 2 つが制御可能性を測るものです。
軸 1: その機器を通過する情報の重要度
最初に確認するのは、その機器を経由する通信に何が含まれるかです。同じ機種であっても、設置場所によってリスクの大きさは変わります。
| 分類 | 例 | 評価 |
|---|---|---|
| 高 | 業務システムへの接続、顧客データ、認証情報を含む通信 | 慎重な判断が必要 |
| 中 | 業務端末のインターネット接続、社内向けの補助回線 | 条件付きで許容できる |
| 低 | 検証環境、ゲスト Wi-Fi、閉じたラボ回線 | 隔離を前提に許容できる |
この軸で重要なのは、通信の中身だけでなく、その機器が観測できる範囲も含めて考える点です。ルーターは通過するパケットそのものに加えて、接続元の端末一覧、DNS クエリ、通信先と通信量のパターンを観測できる位置にあります。暗号化されていても、いつ、どこへ、どれだけ通信したかは記録できます。
検証環境だから問題ないという判断は、その検証環境が本番の構成情報や認証情報を含んでいないことが前提になります。実際には検証環境に本番相当のデータが置かれているケースが少なくないため、ここは実態を確認したうえで分類することをおすすめします。
軸 2: ネットワーク上の位置とセグメント設計
次に、その機器がネットワークのどこに置かれているかを評価します。Zbtlink の事案が示したように、この種のインプラントは配下の LAN へのアクセスを可能にするため、その機器の LAN 側に何が接続されているかが影響範囲を決めます。
| 位置 | 影響範囲 | 評価 |
|---|---|---|
| 境界（インターネットとの接続点） | 全社の通信が通過する | 影響が最大 |
| 拠点の出入口 | 拠点全体 | 拠点の重要度に依存 |
| 独立セグメントの内側 | そのセグメントのみ | 分離の実効性に依存 |
| 完全に閉じた環境 | 環境内のみ | 影響は限定的 |
ここで確認しておきたいのが、「独立セグメント」が実際に独立しているかという点です。VLAN で分離していても、同一の管理ネットワークからアクセスできる、あるいは共通の認証基盤を参照している場合、分離は部分的なものにとどまります。セグメント間の通信を明示的に許可しているルールがあれば、その経路は影響範囲に含まれます。
軸 3: 出口制御とログ保全の有無
3 つ目は、その機器の外向き通信をどこまで把握・制御できているかです。この軸は 4 つの中で唯一、機器そのものではなく自社の設計を評価するものです。 そして、製造国にかかわらず有効に働きます。
評価の観点は次の 4 点です。
- 1. egress ポリシーの方針
-
外向き通信を既定拒否とし、必要な宛先だけを許可しているか。既定許可の環境では、この種のインプラントは検知も遮断もできません
- 2. DNS の集約
-
機器が任意のリゾルバーを参照できる状態か、社内リゾルバーへ強制しているか
- 3. ログの保全期間
-
DNS ログ、Proxy ログ、フローログをどれだけ遡れるか。事案の公表から遡って調査できる期間が確保されているか
- 4. アラートの有無
-
遮断だけでなく、遮断された通信の試行そのものを記録し、通知しているか
4 つ目が抜けている環境は少なくありません。 遮断のみでは、どの機器が何に接続を試みていたかが残らないため、事案の公表後に影響を確認できなくなります。
既知のシグネチャに依存せず、外向き通信の異常を継続的に捉える仕組みを検討する場合は、関連記事『NDR 製品の選定ガイド』で製品カテゴリーごとの特性を整理しています。
軸 4: ファームウェアの出所とライフサイクルの説明可能性
最後は、その機器についてベンダーが何をどこまで説明できるかという軸です。前章で見たとおり、供給構造が見えない機器は、製造国が分かっても中身を推定できません。
確認できると望ましい項目を挙げます。
| 項目 | 確認できる状態 | 確認できない場合の意味 |
|---|---|---|
| ファームウェアの提供元 | 開発主体と OEM 供給の有無が明示されている | 中身の由来をたどれない |
| 更新の提供期間と EOL | 期間が文書で表明されている | 修正が止まる時期を予測できない |
| 更新の配布経路と署名 | 署名付き更新の仕組みがある | 更新そのものが攻撃経路になりうる |
| 既定で行う外部通信 | 通信先と目的が開示されている | 想定外の通信を判別できない |
| 脆弱性情報の窓口 | 報告窓口と Advisory の公開実績がある | 問題が起きたときに情報が出ない |
最後の項目は、実際の運用で差が出ます。 修正が提供されるかどうかは、ベンダーが問題を認識して公表する仕組みを持っているかに依存します。前章で触れた Cisco の事案では、修正の提供と Advisory の公開があったことで、利用者は対応の判断ができました。一方 Zbtlink の事案では、その前提が成立していません。
なお、この軸は日本語での情報提供の有無とは別問題です。英語の Advisory しか出さないベンダーでも、内容が具体的であれば実務上は機能します。
4 軸の組み合わせ方
4 つを同時に扱うと判断が複雑になるため、影響範囲を測る軸 1・軸 2 で大枠を決め、制御可能性を測る軸 3・軸 4 で調整する進め方をおすすめします。
まず軸 1（情報の重要度）と軸 2（ネットワーク上の位置）で 4 象限に分類します。
| 位置: 境界・拠点出入口 | 位置: 独立セグメント・閉じた環境 | |
|---|---|---|
| 情報の重要度: 高 | 交換を第一候補とする | 出口制御の強化を前提に継続を検討 |
| 情報の重要度: 中・低 | 出口制御の強化とログ保全を前提に継続を検討 | 隔離を前提に継続できる |
次に、軸 3 と軸 4 で象限内の判定を調整します。
- 1. 軸 3 が整っている場合
-
1 段階緩い側に寄せられます。既定拒否の egress ポリシーとログ保全がある環境では、想定外の通信を検知できるためです
- 2. 軸 3 が整っていない場合
-
1 段階厳しい側に寄せます。既定許可の環境では、問題が起きても気づけません
- 3. 軸 4 が確認できない場合
-
1 段階厳しい側に寄せます。出所とライフサイクルを説明できない機器は、次に問題が起きたときの対応が読めません
このマトリクスに製造国は含まれていません。 製造国は軸 4 の一部、つまり出所の説明可能性を評価する際の材料の 1 つとして扱う位置づけになります。前章で見たとおり、製造国が同じでも供給構造の透明性には差があり、製造国が異なっても同種の問題は発生しているためです。
最後に、この 4 軸は既設機器の評価にも新規調達の判断にも使えますが、用途が異なります。既設機器では軸 1・軸 2 が固定されているため、軸 3 の強化が現実的な選択肢になります。新規調達では 4 軸すべてを設計段階で選べるため、軸 4 を要件に組み込む余地があります。次章では、この点を調達要件の形に落とし込みます。
調達要件と既設機器への落とし込み
前章の 4 軸を、実際の調達と運用に落とし込みます。新規調達では仕様書の確認項目として、既設機器では棚卸しと制御の強化として扱います。
調達仕様書に書ける確認項目
軸 4（出所とライフサイクルの説明可能性）は、調達段階であれば要件として明文化できます。以下は、そのまま仕様書や質問票に転記できる形にした確認項目です。
| # | 確認項目 | 確認の目的 |
|---|---|---|
| 1 | 型番単位での製品識別情報の提示 | ブランド名では同一性を判断できないため |
| 2 | ファームウェアの開発主体と、OEM / ODM 供給の有無 | 供給構造をたどれる状態にするため |
| 3 | セキュリティ修正の提供期間と EOL 日付の表明 | 修正が止まる時期を予測するため |
| 4 | ファームウェア更新の配布経路と署名検証の仕組み | 更新自体が経路にならないようにするため |
| 5 | 機器が既定で行う外部通信の一覧（宛先・ポート・目的） | 想定外の通信を判別できるようにするため |
| 6 | 脆弱性報告窓口と、過去の Advisory 公開実績 | 問題発生時に情報が出るかを見るため |
| 7 | 出荷時に有効化されている管理サービスの一覧 | 不要なサービスを閉じる判断のため |
| 8 | SBOM または構成コンポーネントの開示可否 | 依存関係の把握のため |
すべてに回答を得られるとは限りません。 実際には、回答できない項目があること自体が判断材料になります。特に項目 2 と項目 5 は、回答の有無で供給構造の透明性が測れます。
要件を書く際に注意したいのが、特定製品の指定にならないようにする点です。この考え方は、SCS 評価制度の制度構築方針でも同様に示されています。
参考: サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針（経済産業省）
「本制度の評価基準を達成するにあたっては、特定のセキュリティ対策製品の導入が必須とされているものではありません」
https://www.meti.go.jp/press/2025/03/20260327001/20260327001.html
求めるのは製品名ではなく、満たすべき性質です。 上記 8 項目も、いずれも特定ベンダーを前提としない形にしています。
認証制度を製品・サービス・組織の 3 層で使い分ける
日本のセキュリティ関連の評価制度は複数あり、名称が似ているため混同されがちです。それぞれ評価している対象が異なります。
| 制度 | 評価対象 | 調達での使い方 |
|---|---|---|
| JC-STAR | 製品（IoT 機器） | 調達候補の一次フィルター |
| ISMAP | サービス（クラウド） | クラウド調達の要件 |
| SCS 評価制度 | 組織（企業の IT 基盤） | 自社および取引先の対策水準 |
機器の調達判断で直接関わるのは JC-STAR です。ただし前章で見たとおり、★1・★2 は自己適合宣言方式であり、ラベルの有無だけで判断を終える使い方は想定されていません。候補を絞る一次フィルターとして使い、軸 4 の確認項目で個別に確認する二段構えが現実的です。
なお、JC-STAR は現時点で IoT 製品を主な対象としており、業務用のルーターやスイッチがどこまで対象になるかは制度の整備状況を確認する必要があります。認定ラベルのある製品が存在しないカテゴリーでは、この一次フィルター自体が機能しません。 その場合は軸 4 の確認項目が主たる判断材料になります。
既設機器を直ちに交換できない場合
既設機器では軸 1（情報の重要度）と軸 2（設置位置）が固定されているため、打ち手は軸 3（出口制御とログ保全）の強化に集約されます。優先順位をつけると次のようになります。
- 1. 棚卸しの精度を上げる
-
型番単位で資産台帳を整備します。DHCP のリース情報や ARP テーブルから、台帳に載っていない機器を洗い出す方法も併用できます
- 2. egress ポリシーを既定拒否に寄せる
-
すべてを一度に変えるのは困難なため、重要度の高いセグメントから順に適用範囲を広げます
- 3. DNS を集約し、クエリを記録する
-
機器が任意のリゾルバーを参照できない状態にします。ログの保全期間もあわせて確認します
- 4. 遮断した通信の試行を記録し、通知する
-
どの機器が何に接続を試みたかが残る状態にします
- 5. 交換計画を立てる
-
更新のタイミングに合わせて、軸 4 の確認項目を満たす製品へ置き換えます
1 番目の棚卸しは、他の制度対応とも共通する基盤になります。SCS 評価制度は評価対象を IT 基盤とし、ネットワーク機器を含む IT 資産管理体制の整備を前提としているため、この作業は調達判断のためだけのものではありません。制度対応の観点からの整理は、関連記事『SCS 評価制度の★3・★4 要件とインフラ設計』で扱っています。
上位のファイアウォールや IPS 側で特定の通信を止める暫定運用については、関連記事『FortiGate の仮想パッチ運用』で考え方を整理しています。
なお、これらはいずれも本件に固有の対策ではありません。 修正が提供されない機器、出所を確認できない機器、EOL を迎えた機器のいずれにも同じ形で適用できます。個別の事案ごとに対策を立てるのではなく、恒常的な設計として持っておくほうが運用は安定します。
まとめ
2026 年の規制強化は、ネットワーク機器の調達に新しい選択基準を持ち込みました。ただし規制と認証制度が作用するのは調達の入口であり、既に設置されている機器の状態は変わりません。また OEM / ODM の供給構造がある以上、製造国やブランド名だけでは判定しきれない領域が残ります。実務では、影響範囲と制御可能性の 4 軸で個別に判断する方法が現実的です。
- FCC の規制対象は新規モデルの機器認証で既設機器には及ばない
- 総務省の自治体向け方針は報道ベースで省令改正の実施は未確認
- OEM / ODM 供給によりブランド名や製造国では判定しきれない構造
- JC-STAR の★1・★2 は自己適合宣言でベンダーの信頼性に依存する
- 静的な認証情報の混入は製造国を問わず複数のベンダーで発生
- 判断軸は情報の重要度・設置位置・出口制御・出所の説明可能性
- 既設機器では出口制御とログ保全の強化が現実的な打ち手
以上、最後までお読みいただきありがとうございました。
