Trust Boundaryを無視したJC-STARは
本当にサイバーセキュリティなのか

第1章 — 結論：目的に賛成し、設計に疑問を呈する

考察「フェアに」とは次を意味します。第一に、JC-STARが達成しようとしている価値（サプライチェーン対策、脆弱性対応体制、アップデート体制の底上げ）を過小評価しないこと。第二に、製品認証という手法自体は国際的にも存在する（EU CRA[29]、UL 2941[24]、IEC 62443-4-2[13]）ことを認めること。第三に、それでもなお残る矛盾——境界より末端を優先する逆転——を論理的に指摘することです。

本稿が検証する3つの矛盾

第2章 — 世界のOTセキュリティは何を守ってきたのか

2-1. Trust Boundaryとは何か

事実Trust Boundary（信頼境界）とは、信頼水準の異なる領域の境目を指すセキュリティ工学の基礎概念です。NIST SP 800-82 Rev.3[16]は、OT（Operational Technology）環境を企業ITネットワークおよびインターネットから分離し、境界にファイアウォール・DMZ・単方向ゲートウェイ等の防御を集中配置することを一貫して推奨しています。脅威は境界を越えて内部に到達するのであり、境界の防御強度がシステム全体の攻撃面を決定します。

2-2. Defense in Depthとは何か

事実Defense in Depth（多層防御）は、単一の防御層の突破がシステム全体の侵害に直結しないよう、境界防御・ネットワーク分離・アクセス制御・監視・物理保護を重層化する設計原則です[16][19]。重要なのは、多層防御は「末端機器の堅牢化だけで代替できない」という点です。末端の製品セキュリティは多層のうちの一層にすぎず、それ単独では層になりません。

2-3. Zone & Conduitとは何か

事実IEC 62443（旧ISA-99[14]）は、産業制御システムをZone（同一のセキュリティ要件を共有する資産グループ）とConduit（Zone間の通信経路）に分割し、リスクアセスメント（IEC 62443-3-2[10]）に基づいて各Zoneに要求セキュリティレベル（SL-T）を割り当てます。防御投資はConduit＝境界に集中します。ISA-95のPurdueモデル[15]がレベル間の境界を定義してきたのも同じ思想です。

flowchart TB
  INET["Untrusted Zone
Internet / 企業IT"] --> C1["Conduit
Firewall / DMZ / VPN"]
  C1 --> Z1["Zone 1
監視・SCADA"]
  Z1 --> C2["Conduit
セグメント境界"]
  C2 --> Z2["Zone 2
制御機器・PCS・PLC"]
  style C1 fill:#0071e3,color:#fff,stroke:#0071e3
  style C2 fill:#0071e3,color:#fff,stroke:#0071e3
  style INET fill:#fde8e8,stroke:#c9342a
  style Z2 fill:#eaf7ef,stroke:#2f7a4d
          

2-4. Zero Trust・IEC 62351・各国フレームワーク

事実NIST SP 800-207（Zero Trust Architecture）[17]は「境界の内側なら信頼する」という従来モデルを更新しましたが、これは境界概念の放棄ではありません。境界をより細かく・動的に引き直す（マイクロセグメンテーション、継続的検証）思想であり、「境界を管理する」という核心は不変です。電力分野固有の規格であるIEC 62351[20]は、IEC 61850[21]等の通信プロトコルの保護——すなわち通信経路（Conduit）の保護——を主対象とします。英国NCSC CAF[33]、豪州AESCSF[34]、シンガポールCCoP[35]、北米NERC CIP[26]も、Electronic Security Perimeter（電子セキュリティ境界）の定義と管理を運用者に義務付ける構造です。

考察規格ごとに焦点は異なりますが、共通する結論は一つです。世界のOTセキュリティが守ろうとしているのは「境界」である。末端機器の堅牢化は境界管理を補完するものであり、代替するものではない——これが約30年のICSセキュリティ史が到達した設計原則です。

第3章 — 風力発電：国際標準と整合する制度設計

事実資源エネルギー庁「分散型電源のサイバーセキュリティ対策の要件化に係る今後の対応について」（グリッドコード検討会 資料）[3][4]では、風力発電について、発電所とインターネット・外部ネットワークの接続点に位置するGateway・Firewall等の境界機器を中心にJC-STAR適合を求める方向の整理が示されています。

考察この整理は、第2章で確認した国際標準の思想と正確に整合します。風車のナセル内制御器を個別に認証するのではなく、ウィンドファーム全体を一つのZoneとみなし、外部との接続点（Conduit）に防御を集中する——IEC 62443の教科書通りの設計です。実際、欧州の洋上風力ではIEC 62443ベースのゾーニングが事実上の標準です[44]。著者はこの風力の整理を高く評価します。

事実境界機器が現実の攻撃対象であることは、実際のインシデントが示しています。2019年、米国ユタ州のsPower（太陽光・風力運用者）では、境界のファイアウォールの未パッチ脆弱性を突かれたDoSにより監視の可視性が断続的に失われました。NERC/E-ISACのLessons Learned文書[42]が公開されています。2022年には、Viasat KA-SAT衛星通信網への攻撃により、ドイツEnercon社の風車約5,800基の遠隔監視・制御が失われました[43]。いずれも侵害されたのは通信経路と境界であり、発電機そのものではありません。

第4章 — 太陽光発電：なぜ突然思想が変わるのか

事実同じ検討会資料[3]において、太陽光発電では、系統連系に関わるPCS（パワーコンディショナ）・EMS等の通信機能付き制御機器にJC-STAR適合を求める方向が示され、Router・Logger・Gateway等の境界側機器は「推奨」に位置づけられています。

flowchart TB
  I1["Internet"] --> FW1["Firewall"]
  FW1 --> GW1["Gateway"]
  GW1 --> WF1["Wind Farm 内部"]
  FW1 -.-> R1["JC-STAR 要件化の方向"]
  GW1 -.-> R1
  style FW1 fill:#fff8e6,stroke:#b45309
  style GW1 fill:#fff8e6,stroke:#b45309
  style WF1 fill:#f0f4ff,stroke:#0071e3
            

flowchart TB
  I2["Internet"] --> RT2["Router（推奨）"]
  RT2 --> LG2["Logger（推奨）"]
  LG2 --> P2["PCS"]
  P2 --> E2["EMS"]
  P2 -.-> R2["JC-STAR 要件化の方向"]
  E2 -.-> R2
  style P2 fill:#fff8e6,stroke:#b45309
  style E2 fill:#fff8e6,stroke:#b45309
  style RT2 fill:#eaf7ef,stroke:#2f7a4d
  style LG2 fill:#eaf7ef,stroke:#2f7a4d
            

図2 — 風力と太陽光で「要件化」の位置が逆転する（公開資料の要約・概念図）

考察風力では境界（Firewall・Gateway）が要件で内部が保護対象。太陽光では境界が推奨で末端（PCS・EMS）が要件。攻撃者から見た侵入経路はどちらも同じ——インターネットから境界を越えて内部へ——であるにもかかわらず、防御要件の重心が正反対に置かれています。

考察考えられる説明はいくつかあります。（a）太陽光は設備数が桁違いに多く、住宅用まで含めると境界機器の設置・管理を運用者に義務付けることが現実的でないため、量産される製品側で品質を担保しようとした。（b）風力は集中型ウィンドファームが多く境界が定義しやすいが、太陽光は構成が多様で境界の定義が困難。（c）PCSは系統連系点に最も近い制御要素であり、系統影響の直接の発生源として着目された。——いずれも一定の合理性を持つ推測です。しかし、これらはあくまで著者の推測であり、公開資料の中に、この思想転換を明示的に説明する技術的根拠は確認できませんでした（第7章で詳述）。制度の説明と著者の推測を混同しないよう、ここで明確に区別しておきます。

第5章 — 図解：なぜFirewallよりPCSなのか

考察実際の産業用太陽光発電所の典型的な通信構成を、インターネットから系統までの縦の経路として図解します。攻撃者はこの経路を上から下へ進みます。

flowchart TB
  A["Internet"] --> B["Firewall（推奨）"]
  B --> C["VPN（推奨）"]
  C --> D["Router（推奨）"]
  D --> E["Closed LAN"]
  E --> F["Logger（推奨）"]
  F --> G["PCS ← ここが要件化の方向"]
  G --> H["Power Grid（系統）"]
  style A fill:#fde8e8,stroke:#c9342a
  style B fill:#eaf7ef,stroke:#2f7a4d
  style C fill:#eaf7ef,stroke:#2f7a4d
  style D fill:#eaf7ef,stroke:#2f7a4d
  style F fill:#eaf7ef,stroke:#2f7a4d
  style G fill:#fff8e6,stroke:#b45309,stroke-width:3px
  style H fill:#f0f4ff,stroke:#0071e3
          

考察この図が示す構造的な問題は明快です。攻撃者がPCSに到達するには、Firewall、VPN、Router、閉域LAN、Loggerをすべて通過しなければなりません。逆に言えば、境界の1層目で止めれば、PCSの製品セキュリティが試される局面は大幅に減ります。防御効率の観点では、上流の境界ほど1台あたりの防御価値が高いのです。それにもかかわらず、要件化の重心は最下流のPCSに置かれています。

考察念のため補足します。PCSの製品セキュリティが無意味だという主張ではありません。境界が突破された場合の最終防衛線として、また物理的に近接攻撃を受けた場合の対策として、末端の堅牢化には固有の価値があります。問題は優先順位の逆転です。多層防御の第一層（境界）を「推奨」に留めたまま最終層（末端）を「要件」とする構成は、費用対効果の観点でも、国際標準の設計原則の観点でも、説明を要します。

第6章 — 国際調査：末端機器だけを規制する国はあるか

考察「末端機器の製品認証」という手法自体は国際的に存在します。フェアな検証のため、主要な制度を確認します。

表1 — 主要国のDER・IoTセキュリティ制度の構造比較（2026年7月時点・著者整理）

考察調査の結論はこうです。製品認証を用いる国は多い。しかし、境界防御・運用者義務を従属的な「推奨」に留めたまま、末端制御機器の製品認証を防御の主軸に据える制度は、著者が調査した範囲では他に確認できませんでした。米国UL 2941もEU CRAも、境界と運用の義務（NERC CIP、NIS2）が別建てで存在する重層構造の中の一要素です。層の一部だけを取り出して主軸にする構成は、比較制度論の観点から極めて特異な制度と言わざるを得ません。もし著者の調査に漏れがあり、同様の構造を持つ制度が存在するなら、それこそ制度設計者が参照事例として提示すべき情報です。

第7章 — 風力との徹底比較：技術的根拠は存在するか

問い風力も太陽光も、同じDER（Distributed Energy Resources：分散型エネルギー資源）です。系統から見れば、どちらも「インバータ・変換器を介して連系し、遠隔監視・制御される発電設備」です。ではなぜ——

事実著者は、グリッドコード検討会の公開資料・議事録[3][4]、経済産業省の電力分野サイバーセキュリティ関連文書[5][6]、IPAのJC-STAR公開資料[1][2]を通読しましたが、「なぜ風力は境界機器で、太陽光は末端機器なのか」という思想差そのものを技術的に説明する記述は、本稿執筆時点（2026年7月5日）で確認できませんでした。設備規模・普及形態の違いに触れる記述はありますが、防御アーキテクチャの選択理由としてIEC 62443等との対応を示した説明は見当たりません。

表2 — 風力と太陽光の比較。技術的条件はほぼ共通だが、要件化の重心だけが逆転する

考察行政学の基本に照らせば、同種の対象に異なる規制設計を適用する場合、その合理的区別の理由を示すのは規制者の側の責務です。設備数の多さは「境界機器の要件化が難しい」ことの説明にはなり得ても、「末端機器の認証が境界防御の代替になる」ことの説明にはなりません。この論理の飛躍が埋められていない以上、現状では説明責任が果たされていないと評価せざるを得ません。

第8章 — 最も強い問題提起：国際標準から逸脱する理由の説明責任

考察本稿で最も強く提起したい論点を、正確に書きます。

問い制度設計者に確認したいのは、次の一点に集約されます。「太陽光の系統連系セキュリティ要件化において、IEC 62443のZone & Conduitモデルとの対応関係はどのように整理されたのか。境界機器を推奨に留め末端機器を要件化する構成が、Zone & Conduitモデルよりも高い防御効果を持つと判断した技術的根拠は何か。」

第9章 — 行政制度としての検証：予見可能性・透明性・説明責任

考察ここからは、サイバーセキュリティ技術論を離れ、行政制度論として検証します。認証制度・適合性評価制度が機能するための最低条件は、行政法学の通説に照らせば次の3つです。

事実JC-STAR★1は自己適合宣言（Self-Declaration of Conformity）を基本とする制度です[2]。自己適合宣言は国際的にも広く用いられる正当な手法です（EU CEマーキング等）。その正当性の前提は、適合基準が公開され、宣言の受理・不受理が基準に照らして機械的に判定されることにあります。

事実一方、当サイトの調査レポート[51]で整理したとおり、申請の受理前に非公開の確認プロセスが存在すること、申請件数・却下件数等の統計が公開されていないことは、公開資料からは詳細を確認できません。何を根拠に確認し、何を理由に通し、何を理由に通さないのか——このプロセスの可視性は、本稿執筆時点で十分とは言えません。

考察自己適合宣言制度でありながら受理判断の基準・統計が不透明であることは、行政制度として二重に問題です。第一に、予見可能性の欠如——メーカーは何を満たせば受理されるのか予測できず、投資判断ができません。第二に、「見えない裁量」の発生——公開基準の外側に事実上の判断基準が存在するなら、それは告示されない規制であり、恣意的運用と区別がつきません。系統連系の要件化（＝事実上の市場参入条件化）と結合すれば、この不透明性は単なる制度運用の問題ではなく、市場アクセスの公正性の問題に発展します。

考察是正は難しくありません。（1）受理・不受理の判定基準の全文公開、（2）申請・受理・却下・取下げ件数の定期統計公表、（3）不受理時の理由付記と不服申立手続の整備。いずれも既存の適合性評価制度（JIS認証、電気用品安全法等）で実装済みの標準的な仕組みです。

第10章 — 仮説：制度目的の混在という懸念

仮説本章は公開資料で確認できない推論を含みます。その旨を明示したうえで、制度設計上の論点として提示します。

事実近年、経済安全保障の観点から、電力インフラにおける特定国製機器——特に中国メーカー製インバータ・通信機器——への懸念が政策課題として存在することは、国内外で広く報じられています。米国では特定メーカー製インバータの調達制限が議論され、欧州でもSolarPower Europeがインバータのサイバーセキュリティに関するポジションペーパーを公表し[44]、オランダ当局はインバータの遠隔接続リスクに関する調査を行いました[49]。日本でも経済安全保障推進法に基づく基幹インフラ制度が運用されています[8]。

仮説ここで一つの仮説が浮かびます。「太陽光でPCS・EMSという製品そのものを認証対象とする設計は、境界防御という技術目的だけでなく、特定メーカー製品の市場流通を制度的に管理したいという経済安全保障上の目的を、暗黙に含んでいるのではないか」——。この仮説を裏付ける公式文書は存在しません。グリッドコード検討会資料にもJC-STAR公開資料にも、経済安全保障目的への言及は確認できません。したがってこれは検証されていない仮説であり、事実として扱うべきではありません。

考察しかし、仮説の真偽にかかわらず、制度設計論として言えることがあります。仮に安全保障上の措置が必要なのであれば、それは経済安全保障推進法のような安全保障政策の枠組みで、安全保障政策として実施すべきです。技術認証制度に安全保障目的を混在させると、（1）技術基準の合理性が安全保障判断で歪む、（2）判断理由を公開できなくなり第9章の透明性問題が構造化する、（3）国際標準との整合を説明できなくなる——という三重の劣化が起きます。逆に、もし安全保障目的が一切含まれていないのであれば、第8章の問い（国際標準からの逸脱理由）に技術論のみで答えられるはずです。どちらであるかを明らかにすること自体が、制度の透明性の試金石です。

第11章 — 動的ネットワークは静的認証で守れるか

考察最後の技術的検証です。仮に第4〜8章の論点がすべて解消され、末端機器認証に合理性があるとしても、なお残る根本問題があります。製品認証は「出荷時点の静的スナップショット」であり、発電所のネットワークは「20年間変化し続ける動的システム」であることです。

事実FIT/FIP制度下の太陽光発電所は20年以上運用されます。O&M実務では、その間に次の構成変更が通常運用として発生します（当社O&M実績に基づく整理[53]）。

表3 — 20年運用で発生する構成変更。ほぼすべてが「PCSの認証状態を変えないまま」システム全体のリスクを変化させる

flowchart LR
  T0["竣工時
認証済みPCS
リスク評価済み構成"] --> T5["5年後
Logger交換
クラウド変更"]
  T5 --> T10["10年後
VPN追加
VPP参加・API連携"]
  T10 --> T15["15年後
Router更新
Wi-Fi追加
保守PC多数"]
  T15 --> T20["20年後
PCS認証ラベルは
竣工時のまま"]
  style T0 fill:#eaf7ef,stroke:#2f7a4d
  style T20 fill:#fde8e8,stroke:#c9342a
          

問いそれでも、PCSだけ認証して、本当に安全なのでしょうか。ウクライナ2015年の攻撃で侵害されたのはSCADAと運用ネットワークでした[39]。sPowerで攻撃されたのはファイアウォールでした[42]。Viasatで失われたのは通信網でした[43]。実際のインシデント史において、「認証されていない末端発電機器の製品脆弱性」が起点となった大規模系統事故は、著者の調査範囲では確認できません。攻撃は常に、変化し続けるネットワークの管理されない部分——境界・経路・運用——から始まっています。

第12章 — Dynamic Resilience by Architecture

考察批判だけで終わらせません。本章では、次世代のエネルギーIoTセキュリティが立脚すべき概念として、当サイトのシリーズ論考[52]で提示してきた「Dynamic Resilience by Architecture（アーキテクチャによる動的レジリエンス）」を、国際標準との対応付きで再定義します。

核心は一文で表せます。重要なのは認証ではなく、Trust Boundary・Architecture・Monitoring・Segmentation・Least Privilege・Continuous Assessmentである。製品認証はこの体系の一要素として意味を持ちますが、主軸にはなり得ません。

表4 — Dynamic Resilience by Architectureの6要素と国際標準の対応

flowchart TB
  subgraph STATIC["静的認証モデル（現行の整理）"]
    A1["出荷時に製品を認証"] --> A2["竣工後の変化は管理外"]
  end
  subgraph DYNAMIC["Dynamic Resilience by Architecture"]
    B1["Trust Boundaryの定義"] --> B2["Segmentation / Least Privilege"]
    B2 --> B3["Monitoring"]
    B3 --> B4["Continuous Assessment"]
    B4 -->|"構成変更のたびに再評価"| B1
  end
  STATIC -->|"発展の方向"| DYNAMIC
  style STATIC fill:#fde8e8,stroke:#c9342a
  style DYNAMIC fill:#eaf7ef,stroke:#2f7a4d
          

考察この体系は製品認証を排除しません。境界機器（Firewall・Gateway・VPN終端）にこそJC-STAR適合を要件化し、末端機器は推奨として段階的に底上げする——つまり現行整理の要件と推奨を入れ替えるだけでも、国際標準との整合は劇的に改善します。さらに、既設発電所には製品全交換ではなく境界・保護の後付是正[52]を適合経路として認めれば、20年運用の現実とも両立します。制度の骨格を壊さずに実装可能な改善です。

制度設計者への公開質問（本稿の要約として）

1. 太陽光の要件化において、IEC 62443のZone & Conduitモデルとの対応関係はどのように整理されましたか。
   この問いをコピー チャットで答える
2. 境界機器を推奨に留め、末端機器（PCS・EMS）を要件化する構成が、境界中心の構成より高い防御効果を持つと判断した技術的根拠は何ですか。
   この問いをコピー チャットで答える
3. 同じDERである風力では境界機器中心の整理が採られています。太陽光との思想差を正当化する技術的説明はどこで公開されていますか。
   この問いをコピー チャットで答える
4. 自己適合宣言の受理・不受理の判定基準全文と、申請・受理・却下の統計は公開されますか。
   この問いをコピー チャットで答える
5. 本制度に経済安全保障上の目的は含まれていますか。含まれているなら安全保障政策の枠組みへ分離する予定はありますか。含まれていないなら、国際標準からの逸脱を技術論のみで説明できますか。
   この問いをコピー チャットで答える
6. 20年運用中の構成変更（Logger・Router・VPN・クラウド・API・保守PC）は、静的な製品認証とどう接続されますか。継続評価の制度化は検討されていますか。
   この問いをコピー チャットで答える

関連記事・シリーズ