認証対象ではなく
「認証境界」を議論しませんか？

導入

事実JC-STAR（セキュリティ要件適合評価及びラベリング制度）は、IPAが主導するIoTセキュリティ認証制度であり、機器のセキュリティ要件適合を評価し、ラベル表示により調達時の確認を支援することを目的としています[1]。

JC-STARが目指すこと

考察これらは極めて重要であり、I-S3としても全面的に支持します。エネルギー設備がIoT化し電力システムの一部として動く以上、セキュリティを任意の努力目標のままにしておくことはできません。

考察そのうえで、制度資料を読み進めるうちに、一つの興味深い疑問が生まれました。それは「認証対象」ではなく「認証境界」を議論すべきではないだろうか、ということです。本稿はその視点を、制度設計者・メーカー・施工・運用の各関係者と共有するための技術レビューです。

第1章 — 資料から読み解く制度思想

事実資源エネルギー庁「分散型電源のサイバーセキュリティ対策の要件化に係る今後の対応について」（第19回グリッドコード検討会 資料6 等）[2]では、太陽光発電と風力発電で、JC-STAR適合の適用位置づけが異なる整理が示されています。

flowchart TB
  S1["Internet"] --> R1["Router"]
  R1 --> L1["Logger"]
  L1 --> P1["PCS"]
  P1 --> E1["EMS"]
  P1 -.->|"要件化の方向性"| REQ1["JC-STAR★1等"]
  E1 -.->|"要件化の方向性"| REQ1
  R1 -.->|"推奨"| REC1["JC-STAR適合を推奨"]
  style P1 fill:#fff8e6,stroke:#b45309
  style E1 fill:#fff8e6,stroke:#b45309
  style R1 fill:#eaf7ef,stroke:#2f7a4d
            

flowchart TB
  S2["Internet"] --> F2["Firewall"]
  F2 --> G2["Gateway"]
  G2 --> W2["Wind Farm"]
  F2 -.->|"要件化の方向性"| REQ2["JC-STAR適合"]
  G2 -.->|"要件化の方向性"| REQ2
  style F2 fill:#fff8e6,stroke:#b45309
  style G2 fill:#fff8e6,stroke:#b45309
  style W2 fill:#f0f4ff,stroke:#0071e3
            

図1 — 太陽光と風力における認証適用位置づけの違い（公開資料の要約・概念図）

考察同じ分散型電源でありながら、太陽光では制御機器（PCS・EMS）が先行し、風力では境界機器（Firewall・Gateway）が先行する——この違いは、制度設計の思想を読み解くうえで極めて興味深い点です。本稿はこの差異を批判するのではなく、両者の関係から学べることを探ります。

事実なお、具体的な適用範囲・時期・要件水準は今後の制度設計により確定される見込みです。本稿の整理は2026年7月時点の公開資料に基づきます。

第2章 — インターネットは何を守ってきたのか

考察ネットワークセキュリティの基本思想を整理します。重要なのは、インターネット側の脅威を内部の奥まで個別に防ぐのではなく、境界（Trust Boundary）で守ることです。

flowchart TB
  INET["Internet"] --> FW["Firewall"]
  FW --> VPN["VPN"]
  VPN --> TB[" "]
  TB --> CN["Closed Network"]
  CN --> SW["Switch"]
  SW --> LOG["Logger"]
  LOG --> PCS["PCS"]
  style TB fill:#0071e3,color:#fff,stroke:#0071e3
  style CN fill:#eaf7ef,stroke:#2f7a4d
  style INET fill:#f0f4ff,stroke:#0071e3
          

事実IEC 62443[3]では、産業施設をセキュリティゾーン（Zone）に分割し、ゾーン間の通信経路をコンダクト（Conduit）として管理します。NIST SP 800-82[4]も同様に、信頼できる領域とそうでない領域の境界でアクセス制御を行う考え方を採っています。

考察インターネットは内部を守るのではない。境界を守る。これが Firewall、VPN、Zero Trust、IEC 62443——すべての基本思想です。境界が強固であれば、閉域LAN内部の攻撃面は大きく減少します。

第3章 — 認証対象はどこまで広がるのか

問い制度が「認証対象」を定義するとき、次の各要素をどこまで含めるのでしょうか。

• PCSは認証対象か。RS485配下まで含むのか。
• EMSは。出力制御・VPP連携の論理が集中する層。
• Loggerは。監視の入口であり、現場LANのハブでもある。
• Routerは。遠隔監視の常時接続点。
• Switchは。セグメント分割の要否と認証の関係。
• 保守PCは。LAN内端末か、境界外の持ち込み資産か。
• NASは。ログ保管・設定バックアップの拠点。
• Wi-Fi APは。保守・設定用に後付けされることが多い。
• LTE Routerは。携帯網経由の常時接続。
• VPN装置は。閉域とInternetの接続点そのもの。
• IoT Gatewayは。後から増設されることが多い。
• クラウドは。監視SaaS、出力制御サーバ、API連携先。

flowchart LR
  NARROW["PCS・EMS中心"] -->|"定義を拡大"| WIDE["LAN内の全IP機器"]
  WIDE --> CLOUD["+ クラウド・API"]
  CLOUD --> EDGE["+ 保守PC・持ち込み端末"]
  style NARROW fill:#eaf7ef,stroke:#2f7a4d
  style EDGE fill:#fde8e8,stroke:#c9342a
          

第4章 — 認証後にネットワークは変化する

考察製品認証は、ある時点の適合を示します。しかし発電所のネットワークは、その後も静かに変化し続けます。

flowchart TB
  A["施工完了"] --> B["1年後"]
  B --> C1["Switch交換"]
  B --> C2["Logger交換"]
  B --> C3["VPN追加"]
  B --> C4["Wi-Fi追加"]
  B --> C5["保守PC接続"]
  B --> C6["IoT Gateway追加"]
  B --> C7["クラウド変更"]
  B --> C8["ソフトウェア更新"]
  B --> C9["API追加"]
  C1 & C2 & C3 & C4 & C5 & C6 & C7 & C8 & C9 --> D["認証時点の構成と一致するか？"]
  style A fill:#eaf7ef,stroke:#2f7a4d
  style D fill:#f0f4ff,stroke:#0071e3
          

制度は静的である。しかしネットワークは動的である。

考察資産台帳の更新遅延、図面と現場の乖離、複数事業者にまたがる保守契約、夜間・緊急対応時の暫定接続——現場では境界内の構成が静かに変化する状況が頻繁に観測されます。静的な認証ラベルだけでは、この動態を捕捉しきれない可能性があり、制度設計上さらに議論の余地があるのではないでしょうか。

第5章 — 認証済み機器だけの世界は存在するのか

事実IPAは、JC-STARラベルが想定外の脅威や個別の運用環境における全リスクを保証するものではない旨を説明しています[1]。

考察本稿では攻撃方法は記載しません。しかし、認証済み機器だけで構成される世界を、継続的に証明することは極めて難しい——これは制度批判ではなく、制度設計者と現場が共有すべき前提です。

• 正規機器の設定情報が、運用・設定ミスにより不適切に管理される。
• 正規機器のソフトウェアが、更新経路を通じて変更される。
• 正規機器以外の端末が、一時的あるいは恒常的にLANへ接続される。
• 正規機器が交換・増設され、資産台帳が更新されない。

考察認証は必要条件になり得るが、十分条件ではない。ラベル取得後の運用・構成変化こそが、実効的なセキュリティを決定づけます。

第6章 — 認証対象ではなく認証境界

考察本稿の最大の論点です。制度が本当に管理すべきものは、個々の認証対象の列挙ではなく、認証境界（Certification Boundary）——すなわち「どこまでを認証の射程とするか」を定義することではないでしょうか。

flowchart TB
  INET3["Internet"] --> FW3["Firewall"]
  FW3 --> VR["VPN Router"]
  VR --> CB[" "]
  CB --> CL["Closed Network"]
  CL --> LOG3["Logger"]
  LOG3 --> PCS3["PCS"]
  PCS3 --> RS["RS485"]
  RS --> PO["Power Optimizer"]
  style CB fill:#2f7a4d,color:#fff,stroke:#2f7a4d
  style CL fill:#eaf7ef,stroke:#2f7a4d
          

考察Trust Boundary（青）は、ネットワークを守るための技術的境界です。Certification Boundary（緑）は、認証制度が責任を持つ制度的射程です。両者は一致する必要はありませんが、意図的に設計されなければ、現場の混乱を招き得ます。

考察「PCSを認証する」「EMSを認証する」という個別の議論の前に、「認証の境界をどこに引くか」を先に定義することで、第3章の拡張問題や第4章の動態問題に、より実務的な答えが見えてくるのではないでしょうか。

第7章 — 風力資料は重要なヒントを与えている

事実第1章で整理したとおり、風力発電の資料ではGateway・Firewallから要件化する方向性が示されています[2]。

考察これはネットワークアーキテクチャとして非常に自然です。Internetと閉域の間——すなわちTrust Boundary上の機器——を先に管理する。IEC 62443のZone & Conduitの思想とも整合します。

flowchart LR
  WIND["風力：Gateway・Firewall 要件化"] --> NATURAL["ネットワーク設計として自然"]
  SOLAR["太陽光：PCS・EMS 要件化"] --> Q["境界機器は推奨"]
  NATURAL -.->|"示唆"| HINT["太陽光への適用可能性"]
  Q -.-> HINT
  style NATURAL fill:#eaf7ef,stroke:#2f7a4d
  style HINT fill:#f0f4ff,stroke:#0071e3
          

第8章 — Security by DesignからResilience by Architectureへ

事実ERIA（東アジア・ASEAN地域）のエネルギー安全保障に関する議論や白書類では、Security by Design——設計段階からセキュリティを組み込む思想——が強調されています[5]。

考察Security by Designは製品認証ではなく、システム全体を設計する思想です。認証はその入口として重要ですが、アーキテクチャ設計こそが本当の安全性を決めます。I-S3はこれを Resilience by Architecture——構造として障害を局所化し、運用を継続する設計——と呼んで整理しています[6]。

flowchart TB
  SBD["Security by Design"] --> ARCH["Resilience by Architecture"]
  CERT["製品認証（JC-STAR）"] -.->|"入口"| SBD
  BOUND["認証境界の定義"] --> ARCH
  style SBD fill:#f0f4ff,stroke:#0071e3
  style ARCH fill:#eaf7ef,stroke:#2f7a4d
  style CERT fill:#fff8e6,stroke:#b45309
          

詳細は JC-STAR要件化時代の Dynamic Resilience 論考 および 認証済みなら本当に安全なのか？ を参照してください。

第9章 — 何が防げて、何は防げないか

事実公開資料の趣旨から見て、JC-STARは出荷時点の最低品質——固定パスワードの排除、ソフトウェア更新体制、脆弱性公開窓口、サプライチェーン品質の底上げ——に寄与し得る制度として位置づけられています[1]。ラベルが想定外の脅威や個別運用環境の全リスクを保証するものではない、という説明も公開資料にあります。

考察「認証済み＝運用中も安全」という読み替えは、公開資料におけるラベルの位置づけと整合しない可能性があります。安全性は製品属性ではなくシステム属性です。制度が目指すのが製品認証なのか、システム全体のレジリエンスなのか——この点は公開資料だけでは十分に読み取れず、追加説明が望まれます。

第10章 — 逆潮流設備と自家消費設備

事実公開資料では、系統に連系される太陽光発電設備および蓄電設備等のうち、IP通信を用いる制御システムが要件化の対象として整理される方向性が示されています[2]。逆潮流の有無だけで対象外となる、という明確な記述は、本稿執筆時点の公開資料からは確認できません。

考察RPRにより逆潮流しない完全自家消費設備は、系統から見れば業務用エアコン等と同じ「負荷が動的に変化する一般負荷」に近づきます。それでも要件化の対象となり得るなら、リスク評価がリスクベースなのか設備種類ベースなのか——公開資料からの追加説明が望まれます。

考察系統から見た「負荷急変」を重視するなら、理論上は需要側（EV充電器、エコキュート等）も対象になり得ます。家電すべてを認証対象にするのは現実的ではありません。だからこそ、制度には対象範囲を合理的に説明するリスクモデルが必要になります。

第11章 — メーカー・製品の限定ではなく「後付是正」を可能にする方向

考察本稿の建設的な中核論点です。制度が「特定カテゴリの認証済み製品のみを使うこと」に偏ると、現場では次が起きやすくなります。

• メーカー・製品ラインの事実上の限定（調達の硬直化）
• 既設設備の一括更新圧力（コスト・工期・廃棄物）
• 認証ラベルの有無が、運用中の実効安全性の代理指標になってしまう

考察分散型エネルギー設備は20年規模で運用され、構成は竣工後も変化します。したがって、出荷時点の製品適合だけでは足りず、運用開始後に境界・保護・監視を後から是正できる経路が、制度目的の達成に重要です。

事実既設設備に対する是正・移行・段階適用、境界機器の後付追加を適合手段として明示する記述は、本稿執筆時点の公開資料からは十分に確認できません。この点は追加説明が望まれます。

建設的な方向性（提案）

特定メーカー・特定製品の推奨や排除は行いません。制度の目的（系統影響の抑制、最低品質の底上げ）をより実効的に達成するための方向として、次を提案します。

1. 製品限定ではなく境界是正を認める — 内部機器（PCS / EMS / Logger）の一括認証更新だけを唯一の適合経路にしない。Trust Boundary / Certification Boundary への後付強化（境界機器追加、経路分離、閉域化）を適合・改善手段として評価できる設計。
2. 後付是正のメニューを明示する
   • 境界の追加・強化（Firewall / Gateway / VPN終端の後付）
   • 論理制御と物理保護の分離（RPR・解列リレーの物理絶縁）
   • 通信経路の縮退（Internet直結 → VPN / 閉域 / ローカル）
   • 監視・ログ・構成管理の後付導入
   • 完全非IP保護系の追加（ネットワーク経由で無効化できない保護）
3. 既設を捨てさせない移行パス — 既設PCSを直ちに全交換しなくても、境界と保護の後付で系統影響リスクを下げられる経路。「認証製品への置換」と「境界・保護の是正」を並列の選択肢として整理する。
4. 是正の責任分界と記録 — 誰が、いつ、何を是正したかを記録できること（メーカー限定ではなく、EPC / O&M / 発電事業者の実務に載る形）。
5. 均質化リスクの緩和 — 同一認証構成の全国一律普及だけを進めると攻撃面が均質化し得る、という考察を慎重に述べます。後付是正は、現場条件に応じた多様な境界設計を許容し、システミックリスクを下げ得る、と提案します。

flowchart LR
  A["既設設備"] --> B{"適合経路"}
  B --> C["認証製品への置換"]
  B --> D["境界・保護の後付是正"]
  C --> E["制度目的の達成"]
  D --> E
  style D fill:#eaf7ef,stroke:#2f7a4d
  style E fill:#f0f4ff,stroke:#0071e3
          

第12章 — LEAAという実務選択肢（考察・提案）

考察第11章の「後付是正」を、現場で実装可能なアーキテクチャとして具体化した一例が、負荷等価型・自律レジリエンスアーキテクチャ（LEAA）です。これは制度を回避するための抜け道ではなく、制度が守ろうとする系統影響を、物理レイヤーでより確実に抑える設計選択肢です。既設のPCS/EMSを直ちに全交換しなくても、物理保護の後付分離や境界の後付強化により実装し得ます。

LEAAの要点

1. 論理制御と物理保護の完全分離（物理エアギャップ）
   • 論理制御：EMS、スマートロガー、遠隔監視（IP通信可）
   • 物理保護：RPR、OVR/UVR/OFR/UFR、解列リレー、遮断器トリップ回路（IP通信から物理絶縁）
2. 物理保護パラメータは現場の物理操作のみで変更可能（ネットワーク経由で1ビットも書き換えられない）
3. 逆潮流なし＋物理解列により、系統から見れば一般負荷（負荷等価）に近づく
4. Fail Operational / Graceful Degradation — 通信断でもローカル物理量に基づき自家消費運転を継続。系統異常時は自律解列し、重要負荷・太陽光・蓄電池による島運転へ遷移
5. 「通信は協調のために使い、生存の前提にしない」

flowchart TB
  CLOUD["Internet / Cloud"] --> EMS["論理制御ゾーン
EMS / Logger / 監視"]
  EMS -.->|"IP通信"| PCS["PCS / 蓄電池"]
  RPR["物理保護境界
RPR / 解列リレー"] -->|"エアギャップ
非IP"| CB2["遮断器"]
  PCS --> LOAD["需要家負荷"]
  GRID["系統連系点"] --- CB2
  CB2 --- LOAD
  style EMS fill:#f0f4ff,stroke:#0071e3
  style RPR fill:#eaf7ef,stroke:#2f7a4d
  style CB2 fill:#fff8e6,stroke:#b45309
          

LEAA適合性チェックリスト（調達・基本設計用）

1. RPRおよび解列トリップ用制御電源は、EMS/Logger等のIT電源系統から分離されているか
2. 物理保護パラメータの設定変更は、物理鍵付の盤内スイッチ等に限定されているか
3. Modbus/TCP等の通信経由で保護設定を書き換えられない設計か
4. 保護系にIP通信経路（LAN/Wi-Fi/LTE）が物理的に存在しないか
5. 通信断時に一律ゼロ出力へ落とさず、ローカル計測で自家消費を継続できるか
6. 系統異常時に自律解列し、重要負荷の島運転へ遷移できるか
7. 境界機器（Firewall/Gateway/VPN）の後付追加が可能な構成か
8. 構成変更の記録（誰が・いつ・何を）が残せる運用か
9. 単線結線図と通信構成図に、論理ゾーンと物理保護境界が明示されているか
10. 特定メーカー製品への依存なしに、境界・保護の是正が実装可能か

詳細仕様・系統連系テンプレートは LEAA特設記事 を参照してください。

第13章 — 制度設計者へ確認した方がよい質問（20）

公開資料だけから判断して、制度設計者・行政・関係機関へ確認した方がよい質問を抽出します。各問は結論を定めず、「なぜ重要か」と「公開資料での確認状況」を添えます。

1. 制度は何を守ろうとしている制度ですか（製品／システム／インフラ／サプライチェーン）。
   なぜ重要か：守る対象が曖昧だと、適合のゴールが現場ごとにずれます。公開資料ではラベルと最低品質の趣旨は読み取れますが、最終的な守備範囲の階層整理は追加説明が望まれます。
2. 認証対象と認証境界はどのように整理されていますか。
   なぜ重要か：対象機器の列挙だけでは、竣工後の拡張問題に答えられません。公開資料では認証対象の記述が中心で、認証境界という概念の明示は確認できません。
3. 風力と太陽光で対象範囲や優先順位が異なる理由は何ですか。
   なぜ重要か：同じ分散型電源で思想が異なると、現場の設計指針が分裂します。公開資料では差異は読み取れますが、思想差の説明は十分ではありません。
4. Trust Boundary / IEC 62443 / Defense in Depth との対応関係はどのように整理されていますか。
   なぜ重要か：国際標準との整合は、メーカー・EPCの実装コストと国際調達に直結します。公開資料からは詳細対応表は確認できません。
5. 運転開始後の機器追加・交換・更新は、誰が・何年間・どのように評価・管理する想定ですか。
   なぜ重要か：ネットワークは動的です。静的認証とのギャップを埋める主体が不明だと、現場は「悪魔の証明」を強いられます。公開資料からは確認できません。
6. 「認証済み機器のみ」を維持する責任分界は、メーカー／EPC／O&M／発電事業者／行政のどこにありますか。
   なぜ重要か：責任が曖昧だと、適合は形式化しやすくなります。公開資料からは確認できません。
7. メーカーや製品を限定するのではなく、境界の後付強化・物理保護の追加・通信経路の是正を適合・改善手段として認める方向はありますか。
   なぜ重要か：既設の全交換圧力と調達硬直化を避けつつ、制度目的を達成する現実的経路です。公開資料からは確認できません。
8. 既設設備を全交換せずに是正する移行パスは想定されていますか。
   なぜ重要か：20年運用の設備では、一括更新はコスト・工期・廃棄物の面で非現実的な場合があります。公開資料からは確認できません。
9. Internet直結／VPN／閉域LAN／完全ローカルなど、ネットワーク構成によるリスク差は制度に反映されていますか。
   なぜ重要か：リスクベースでなければ、低リスク構成まで一律に重い適合を求め得ます。公開資料からは十分に確認できません。
10. 逆潮流設備と完全自家消費設備は、同じリスクモデルで評価すべきですか。
    なぜ重要か：負荷等価な設備に発電側と同じ前提を置くと、対象範囲の合理性が問われます。公開資料からは確認できません。
11. 負荷側設備（EV充電器、エコキュート等）との非対称性は、どのように説明されますか。
    なぜ重要か：負荷急変を重視するなら需要側も理論上対象になり得ます。リスクモデルの説明が必要です。公開資料からは確認できません。
12. 制度が目指すのは「製品認証」ですか、それとも「システム全体のレジリエンス」ですか。
    なぜ重要か：成功指標が変わると、適合手段（製品置換 vs 境界是正）の評価が変わります。公開資料からは十分に確認できません。
13. 通信断時に一律ゼロ出力とする設計と、系統から見た負荷急変リスクの関係は評価されていますか。
    なぜ重要か：IT的Fail-SafeがOTでは広域負荷急変を招き得ます。公開資料からは確認できません。
14. 保護ロジック（RPR・解列）の改ざんシナリオは、制度上どのように扱われますか。
    なぜ重要か：ネット接続の制御系が侵害されても物理保護が無効化されない設計の評価が必要です。公開資料からは確認できません。
15. 完全ローカル（非IP）構成の保護系は、要件化の対象外として明示されますか。
    なぜ重要か：IP通信を用いない機器の扱いが明確だと、現場は合法的に物理保護を強化できます。公開資料ではIP通信を用いる制御システムが対象、という整理が読み取れますが、保護系の明示は追加説明が望まれます。
16. 論理制御と物理保護の分離設計は、適合・改善手段として評価されますか。
    なぜ重要か：後付是正の中核実装です。公開資料からは確認できません。
17. 竣工後の監査・構成管理は、どのような頻度・証跡・主体を想定していますか。
    なぜ重要か：終わりのない監査負荷は、制度の持続可能性を左右します。公開資料からは確認できません。
18. ラベルの限界（公開資料の趣旨）と現場運用のギャップを、制度はどのように埋める想定ですか。
    なぜ重要か：ラベルは入口であり、運用が本体です。公開資料では限界の説明はありますが、ギャップ埋めの具体策は追加説明が望まれます。
19. Security by Design および IEC 62443 との接続、制度の成功指標（何をもって目的達成とするか）は何ですか。
    なぜ重要か：成功指標が製品出荷数なのか、系統影響インシデントの抑制なのかで設計が変わります。公開資料からは十分に確認できません。
20. 公開議論・フィードバックの窓口はどこですか。
    なぜ重要か：建設的な技術レビューを制度改善に接続するためです。公開資料の更新チャネルは存在しますが、現場アーキテクチャ提案の受け皿は追加説明が望まれます。

最終章 — I-S3からの公開質問

本稿は結論を定めません。以下を、制度設計者・行政・メーカー・施工・運用の各関係者への公開質問として掲載します。

1. 認証対象と認証境界は、どのように整理されているのでしょうか。
   この問いをコピー チャットで答える
2. 太陽光ではなぜ PCS・EMS が先行し、風力では Gateway・Firewall が先行するのでしょうか。
   この問いをコピー チャットで答える
3. 運転開始後の Switch交換、Logger交換、VPN追加、Wi-Fi追加、保守PC接続、クラウド変更、ソフトウェア更新——これらは制度上、どのように評価されるのでしょうか。
   この問いをコピー チャットで答える
4. 将来的には、太陽光についても境界機器中心の制度設計へ発展する予定はあるのでしょうか。
   この問いをコピー チャットで答える
5. 逆潮流設備と完全自家消費設備は、同じリスクモデルで評価すべきでしょうか。
   この問いをコピー チャットで答える
6. 制度が目指すのは「製品認証」なのか、それとも「システム全体のレジリエンス」なのでしょうか。
   この問いをコピー チャットで答える
7. メーカーや製品を限定するのではなく、境界の後付強化・物理保護の追加・通信経路の是正など、運用開始後の是正を適合・改善手段として認める方向は検討されているのでしょうか。
   この問いをコピー チャットで答える

関連記事・シリーズ