導入 — 執筆方針
執筆ペルソナ:IT/OTサイバーフィジカルセキュリティと電力系統工学に精通したプリンシパルアーキテクト。感情的な制度批判は行わず、事実・論理・電気物理のみで議論する。
事実JC-STAR(IPA)および分散型電源のサイバーセキュリティ要件化(資源エネルギー庁・グリッドコード検討会資料)[1][2]は、IoT品質向上とサプライチェーン対策として極めて重要です。I-S3はその方向性を支持します。
考察しかし、認証制度が前提とする世界観——「認証済み機器の集合が、長期にわたり安全なシステムを構成する」——には、電力系統の物理法則と現場の運用実態の両面から、構造的なギャップが存在します。本稿はそのギャップを7つの疑問として整理し、代替案としてLEAA(Load-Equivalent Autonomous Architecture:負荷等価型・自律レジリエンスアーキテクチャ)を定義します。
第1部 — 制度設計に対する7つの疑問
疑問1 — 点 vs 境界
事実公開資料では、太陽光発電のPCS・EMS・ロガー等がJC-STAR適合の対象として整理されています[2]。
考察閉域LAN内の個別機器(点)を認証しても、ネットワーク全体の安全性は自動的には保証されません。IEC 62443が教えるのは、個々の機器ではなく信頼境界(Trust Boundary)——Internetと閉域の間、あるいは制御層と保護層の間——を設計することです[3]。制度が「点の認証」を優先し「境界の設計」を後回しにする場合、認証ラベルの数と実効リスクは相関しなくなり得ます。
問い認証制度は、個別機器の適合と、信頼境界の定義——どちらを先に規定するのでしょうか。
疑問2 — ねじれ(太陽光 vs 風力)
事実同じ分散型電源でありながら、資料上の整理は異なります。太陽光ではPCS・EMS等の内部制御機器が要件化の中心。風力ではGateway・Firewall等の境界機器が要件化の中心[2]。
flowchart LR
subgraph solar["太陽光(資料の整理)"]
S1["Router 推奨"] --> S2["PCS 要件化"]
S2 --> S3["EMS 要件化"]
end
subgraph wind["風力(資料の整理)"]
W1["Firewall 要件化"] --> W2["Gateway 要件化"]
W2 --> W3["Wind Farm"]
end
style S2 fill:#fff8e6,stroke:#b45309
style W1 fill:#fff8e6,stroke:#b45309
考察風力の整理はネットワークアーキテクチャとして自然です。太陽光の整理は、系統連系点に最も近い機器を直接管理する実務上の理由があると推察されます。しかし、このねじれが意図的な設計なのか、過渡期の整理なのか——制度設計側の説明があると、現場の設計判断はより明確になります。
疑問3 — 動的ネットワーク(ドリフト)
考察認証は時点のスナップショットです。竣工後、現場は静かに変化します。
問いこの構成ドリフトを、誰が、どの頻度で、どの証跡で把握するのでしょうか。
疑問4 — 悪魔の証明(コンプライアンスの継続)
考察「認証済み機器のみが接続されている」ことを継続的に証明することは、論理的に極めて困難です(悪魔の証明)。静的な製品認証だけで、20年の運用期間におけるコンプライアンスを保証する仕組みは、制度資料上まだ十分に定義されていません。
疑問5 — 管理破綻の現実
考察資産台帳の更新遅延、図面と現場の乖離、複数事業者にまたがる保守契約——これらは例外ではなく構造的に頻発する運用実態です。認証対象を拡大すればするほど、管理負荷は指数的に増加し、形式的コンプライアンスと実効セキュリティの乖離が拡大し得ます。
疑問6 — 負荷等価(逆潮流なし自家消費)
事実自家消費型太陽光でRPR(逆潮流防止継電器)により逆潮流を物理的に抑制する設計は、電気事業法・系統連系技術基準の文脈で広く用いられています[4]。
考察系統から見れば、逆潮流しない設備は業務用エアコンと同じ「一般負荷」です。系統に電力を「供給」しない以上、分散型電源としてのサイバーリスクモデル——系統への不正注入、遠隔出力制御の改ざん等——の多くはそもそも成立しません。リスク評価の前提を、供給側(発電)と負荷側で区別しない制度設計には、論理的な非対称性があるのではないでしょうか。
疑問7 — 負荷側の非対称性
考察一方、EV充電器(OCPP/API連携)、エコキュート(HEMS連携)、業務用蓄熱設備など、負荷側のIoT機器も系統に影響を与え得ます。需要増大、同期負荷の集中、DR指令の改ざん——これらは発電側PCSとは異なるリスクモデルです。現行の制度議論が発電側(PCS/EMS)に偏重する一方で、負荷側のリスクモデルが十分に定義されていない点は、制度設計上の空白ではないでしょうか。
第2部 — LEAA技術仕様
仕様LEAA(Load-Equivalent Autonomous Architecture / 負荷等価型・自律レジリエンスアーキテクチャ)は、認証制度を代替するものではなく、認証ではカバーしきれない領域をアーキテクチャで埋める設計思想です。三つの柱があります。
柱1 — 論理と物理の完全分離(物理エアギャップ)
仕様EMS・ロガー・通信ゲートウェイが100%侵害され、ソフトウェアにバグがあっても、ネットワークから物理的に絶縁された保護層が電気物理法則に従って動作する設計とします。
- RPR(逆潮流防止継電器) — 系統側への電力逆流を物理的に遮断
- 解列用リレー / 過電圧・過周波数保護 — 系統異常時の自律解列
- 制御電源の独立 — 保護リレーのコイル回路を通信系統から分離
論理層(IT/OT)の侵害は、物理層(電力保護)に到達しない。これがLEAAの根幹です。
柱2 — 系統から見た負荷等価性
仕様逆潮流しない自家消費設備は、系統から見れば単なる一般負荷(負荷等価設備)です。系統への能動的な供給・制御を行わない以上、分散型電源としてのサイバー要件化の前提自体が不要になる——これが「負荷等価」の論理です。
柱3 — 自律縮退・自立(島)運転(Fail Operational)
仕様通信断(クラウド停止、VPN障害、監視SaaS停止)でも、ローカル計測に基づき自家消費を継続します。系統異常時は自律解列し、需要家側のBCP(事業継続計画)を最大化する設計です。
- 監視クラウド停止 → 発電は継続(RPRが逆流を防ぐ)
- 系統停電 → 自立(島)運転で需要家負荷を供給(設計次第)
- EMS侵害 → 物理保護層が系統への影響を遮断
信頼境界&物理保護分離構成図
系統連系協議の申請書類に添付可能な、LEAAの概念構成図です。
flowchart TB
INET["Internet / 監視クラウド"]
INET --> FW["Firewall"]
FW --> VPN["VPN Router"]
VPN --> TB[" "]
TB --> CN["閉域LAN(論理制御層)"]
CN --> EMS["EMS / ロガー"]
EMS --> PCS["PCS / インバータ"]
PCS --> PV["PVアレイ"]
style TB fill:#0071e3,color:#fff,stroke:#0071e3
style CN fill:#f0f4ff,stroke:#0071e3
この層は侵害され得る。認証・監視の対象。
flowchart TB PCS2["PCS(論理層と接続)"] --> RPR["RPR(逆潮流防止継電器)"] RPR --> OL["過電圧・過周波数保護"] OL --> DR["解列用リレー"] DR --> GRID["系統(電力会社)"] RPR -.->|"物理エアギャップ"| NOTE["ネットワークから独立した
ハードワイアード保護"] style RPR fill:#fff8e6,stroke:#b45309 style DR fill:#fff8e6,stroke:#b45309 style NOTE fill:#fef3c7,stroke:#b45309
EMSが100%侵害されても、RPR・解列リレーは物理法則に従い動作する。
flowchart LR GRID2["系統視点"] -->|"見えるのは"| LOAD["一般負荷と同等
(負荷等価)"] LOAD -.->|"逆潮流なし"| SAFE["サイバー要件化の
リスク前提が成立しない"] style LOAD fill:#eaf7ef,stroke:#2f7a4d style SAFE fill:#eaf7ef,stroke:#2f7a4d
flowchart TB
subgraph layers["LEAA 三層モデル"]
L1["L1: Trust Boundary(青)
Firewall / VPN / 認証"]
L2["L2: Logical Control(論理層)
EMS / Logger / PCS通信
※侵害され得る"]
L3["L3: Physical Protection(橙)
RPR / 解列リレー / OV/OF
※ネットワーク非依存"]
end
L1 --> L2
L2 -.->|"侵害が届かない"| L3
L3 --> GRID3["系統 = 一般負荷と同等"]
style L1 fill:#f0f4ff,stroke:#0071e3
style L3 fill:#fff8e6,stroke:#b45309
style GRID3 fill:#eaf7ef,stroke:#2f7a4d
系統連系協議 — 標準説明テンプレート
電力会社の技術審査担当者向けに、サイバー要件化の対象外案件であることを論理的・電気的に説明するための枠組みです。申請図書にコピーしてご利用ください(現場条件に合わせて編集してください)。
上記テキストは選択してコピーできます。単線結線図・保護協調図・RPR設定値一覧と併せて提出してください。
LEAA適合性 — 10項目チェックリスト
基本設計・調達段階で、LEAA思想が具現化できているかを検証する指標です。
- 逆潮流物理抑制 — RPR(または同等の硬件)により、平常時の系統逆流が物理的に不可能である
- 自律解列 — 過電圧・過周波数・停電等で、ソフトウェア非依存の解列保護が動作する
- 論理・物理分離 — 保護リレーのコイル回路がEMS/通信系統と独立している
- Trust Boundary定義 — Firewall/VPN以降を閉域とし、境界の設計図が存在する
- 通信断時の動作定義 — 監視クラウド停止時の発電・保護動作が文書化されている
- 負荷等価の証明 — 系統から見て一般負荷と同等であることを単線図・説明書で示せる
- 構成管理 — 竣工後の機器追加・交換を記録する運用規程がある
- 保護協調 — RPR・解列リレー・OV/OFの設定値と協調が保護協調計算で確認済み
- 島運転/BCP — 系統停電時の需要家側自立運転(または安全停止)が定義されている
- 系統連系説明 — 上記テンプレートに基づくサイバーセキュリティ説明書が作成されている
制度設計者への5つの公開質問
本稿は結論を定めません。日本のエネルギーインフラをよりレジリエントな方向へ発展させるための、建設的な問いかけです。
- 逆潮流を物理的に抑制する自家消費設備は、系統から見て「一般負荷」と同等です。サイバー要件化のリスクモデルは、供給側(発電)と負荷側で区別される予定はありますか。
- 認証制度は「点(機器)」と「境界(Trust Boundary)」のどちらを先に定義しますか。風力資料の境界優先は、太陽光にも適用される方向性ですか。
- 竣工後20年間の構成ドリフト(機器交換・増設・FW更新)に対し、継続的コンプライアンスを誰がどう保証する仕組みが想定されていますか。
- 論理制御層(EMS/ロガー)の侵害と、物理保護層(RPR/解列リレー)の独立性——この「論理と物理の分離」を制度が評価する枠組みはありますか。
- EV充電器・HEMS・エコキュート等、負荷側IoTのリスクモデルは、発電側PCS/EMSとは別に整理される予定はありますか。
私たちはJC-STARを批判したいのではありません。
認証は入口として必要です。しかし、認証だけでは、動的なネットワークと電力系統の物理法則の両方に耐えられません。
LEAAは、認証制度と競合するのではなく、認証では守れない層を物理分離で埋める補完アーキテクチャです。負荷等価であれば、系統は静かに安全です。