製品審査では電力系統を守れない——AI時代の境界防護と実効的サイバーセキュリティ

JC-STAR★1 の系統連系要件化（e-Gov 案件番号 620340012、意見受付 2026年11月6日まで）が、サイバー攻撃から電力系統を守る効果を持つのか。公開一次資料・行政からの文書回答・再現できる計算モデルで検証する。

益田 周防海（Suomi Masuda）／株式会社I-S3 ｜ 2026年10月23日

English version

「セキュリティ認証を取得したこと」と「サイバー攻撃から電力系統を防御できること」は別問題である。 JC-STAR★1 は製品一台の機能 16 項目を自己宣言で確認する制度であり、IPA 自身が「安全に設置・運用されていることを示すものではない」「境界防御という考えは導入していない」と文書で回答している。製造工程や製造国を審査しても、クラウド制御面・更新配信・管理者アカウント・公開後の脆弱性という運用段階の侵入経路は閉じない。攻撃者は製造工程に関与する必要すらない。これらの経路に対する★1 要件化の防御効果は確認できず、実効性は疑わしい。本記事は、公開一次資料と再現できる計算モデルでこの判断の根拠を示し、反証の条件を明記する。

要旨

結論。 JC-STAR★1 を系統連系の必要条件にすることで、クラウド制御面の侵害・更新配信サーバーと署名鍵の侵害・正規管理者アカウントの乗っ取り・認証後に公開される脆弱性・第三国の基盤を経由した遠隔攻撃という、現実に起きている攻撃経路に対する防御効果は確認できず、実効性は疑わしい。これは「効果がないことの証明」ではない。制度を設計した側が効果の根拠を示していない、という確認である。

  1. ★1 は製品一台の機能を見る制度である。 評価対象は IoT 機器と必須付随サービスだけで「システム」は対象外。16 項目の適合基準は自己適合宣言で、IPA は適合を確認しない。有効期間 2 年。サプライチェーンにおける接触は「想定しない」アタックサーフェスと明記されている [J02]。IPA は当社に「『適合ラベル取得済み』は、『安全に設置・運用されている』ことではなく」「『境界防御』という考えは導入していません」と回答した [J05]。
  2. 製造国を調べても、攻撃者の国籍は分からない。 ロシア系 APT28 のマルウェアは中国製モデル Qwen2.5-Coder を呼び出し [A02]、中国国家支援と評価された作戦は米国製 Claude を使った [A10]。攻撃者はクラウド・更新基盤・管理者権限のどれか一つを押さえればよく、製造工程に関与する必要はない。製造国の確認で閉じる経路は 7 つのうち 1 つである（第2章）。
  3. AI は攻撃の経済を変えた。 2026 年 9 月時点で「完全自律の攻撃パイプライン」を実環境で観測した機関はない [A05, A08]。同時に、AI 支援の脆弱性発見と悪用は実証済みで [M09, M10, M14]、商用 API の監視を避けてオープンウェイトモデルをローカルで動かす攻撃者が確認されている [A05, A13]。製品の出自やメーカーの善意を前提にした防御は、攻撃者の能力が普及した環境では成り立たない（第3章）。
  4. 代替構成は存在し、行政は比較していない。 IEC 62443 のゾーンとコンジット、NIST SP 800-82 の境界保護と通信断時の運転継続に基づく「境界防護中心モデル」は、侵害 1 件で同時に動く容量を 1 桁下げる（基本ケース 2,500 MW → 250 MW、仮定値）。資源エネルギー庁は代替措置・境界防御・IEC 62443 との比較資料を「ございません」と回答し、第三者検証を「担保する予定はございません」と回答した [G10]。
  5. 費用は小さいが、それは効果の根拠ではない。 当社モデルでは認証費用の事業者負担は低圧 5 kW で年 265 円程度と小さく、境界装置の方が 1〜2 桁高い（第8章、仮定値）。安さは到達範囲の代わりにならない。費用対効果を論じるには「何を防ぐか」が先に要る。
  6. 系統連系要件化を維持するなら、行政は必要性・追加的な安全性・費用対効果を示す必要がある。 本記事は 19 の公開質問を提示する（第2章・第10章・第11章）。示されない場合は、代替適合手段の導入・適用範囲の見直し・必要に応じた撤回を検討すべきである。

本記事では、確認された事実（一次資料で裏づけられる）、技術的推論（事実から導く）、制度の評価（当社の判断）、I-S3 の提案 を枠で区別する。根拠はすべて末尾の出典一覧と evidence/evidence_ledger.csv に対応させた。

1. 攻撃の現実——製造工程を経ない侵入が主流である

電力・エネルギー設備への実際の攻撃は、製造工程に細工をするのではなく、運用中のシステムの正規の経路を使って入ってくる。確認できる事例を経路別に並べる。

確認された事実
  • 2015 年ウクライナ。 スピアフィッシングで事務系ネットワークに侵入し、VPN を経由して配電会社の HMI を遠隔操作。約 22.5 万需要家が停電 [I01]。製品の欠陥ではなく、正規の遠隔操作経路が使われた。
  • 2016 年・2022 年 Industroyer。 変電所の通信プロトコル（IEC 60870-5-104 等）を正規の手順で話すマルウェア [I02]。機器は仕様どおりに動いた。
  • 2020 年 SolarWinds。 ベンダーのビルド環境が侵害され、正規の署名が付いた更新に不正コードが混入。米政府機関を含む顧客に配布された [I03]。製品がどこで作られたかではなく、更新を配る基盤が標的になった。
  • 2022 年 KA-SAT。 管理用 VPN の設定不備から管理網へ入り、衛星モデムに破壊的コマンドを送信。ドイツ Enercon 社の風力発電機約 5,800 基が遠隔監視を失った [I04]。
  • 2023 年デンマーク。 22 の電力・エネルギー事業者が共通して使う境界装置（Zyxel 製ファイアウォール）の脆弱性で同時侵害。一部はアイランド運転へ移行した [I05]。境界装置も共通原因になるという事例で、第6章と第8章で正面から扱う。
  • 2024〜2025 年 太陽光クラウド。 Solarman/Deye クラウドの認可不備で約 195 GW 相当の機器にアクセスし得た（研究者の開示、実被害の報告なし）[I07]。Sungrow・Growatt・SMA で 46 件の脆弱性が開示され、クラウドアカウントの乗っ取りからインバータの遠隔制御まで到達し得た [I06]。
  • 2021〜2024 年 米国。 PRC 国家主体（Volt Typhoon）が正規の資格情報と OS 標準ツールだけで米重要インフラの IT 環境に持続的に潜伏していたと米英等の機関が公表した [I10]。マルウェアも製品の細工も使っていない。
  • 2024 年 国内。 遠隔監視装置約 800 台が侵害され、不正送金の踏み台にされた。行政資料は「対象機器は出力制御機能を有さないため、系統への影響はない」と記す [I08, G07]。
技術的推論

これらに共通するのは、攻撃者が製品の製造には一切関与していないことである。侵入点は、更新配信、クラウド制御面、管理 VPN、共通の境界装置、公開された脆弱性のいずれかだった。製品の機能要件を一台ずつ確認しても、これらの入口は閉じない。

2025 年 5 月に報じられた「中国製インバータに不審な通信機器」[I09] は、匿名情報源による二次情報で、メーカー名・台数・検証方法は公開されていない。日本政府は「関係団体からは不審な通信機器が搭載されているという事例は報告されていない」と答弁した [D02]。本記事はこの報道を根拠として用いない。製造段階の細工があり得ることは否定しないが、確認された事例の大半はそこにはない。

2. 製造国を調べても、攻撃者は分からない——攻撃主体の非限定性

本章がこの記事の中心である。製造工程や製造元の審査でサイバー攻撃を防げるという主張は、「攻撃者は製造工程を通じて侵入する」「攻撃者の国籍と製品の製造国は一致する」という二つの前提を暗黙に置いている。どちらも成り立たない。

製造国・開発国・クラウド所在地・攻撃者所在地は別々の場所にある

図2 製造国と攻撃経路の非一致 製造国・開発国・クラウド所在地・攻撃者所在地・運用国は別々の場所にあり得る。攻撃者は製造国の製品や企業を経由せず、第三国のクラウド、正規の管理アカウント、侵害済みの踏み台から日本の運用システムに到達できる。 製造国 開発国 クラウド所在地 攻撃者所在地 運用国（日本） 工場・部品 開発チーム・委託先 データセンター （第三国のリージョン） 攻撃主体 国籍・所属は 外形から判定不能 侵害済みの踏み台 （第三国の企業・個人） 運用中のシステム PCS・EMS 監視・保守端末 正規の管理アカウント 原産国の確認で分かるのは左の二列だけ。侵入経路は右の三列から来る。
図A　製造国・開発国・クラウド所在地・攻撃者所在地・運用国は別々の場所にあり得る。製造国の確認（青の点線）で分かるのは左の二列だけで、侵入（赤）は第三国のクラウド、侵害済みの踏み台、正規の管理アカウントを経由して右の運用システムへ届く。製造国の製品や企業を経由する必要はない。 [SVG]

太陽光 PCS や蓄電池の典型的な供給構造では、製造は A 国、ファームウェア開発は B 国、クラウドの計算資源は C 国のデータセンター、運用は日本、という配置が普通である。製造国の確認で分かるのは左の二列だけである。侵入は右側——第三国のクラウド、侵害済みの踏み台、正規の管理アカウント——から届く。

確認された事実

攻撃者の国籍と道具の出自が一致しない事例は、脅威情報機関の一次資料で確認できる。

  • ロシア系 APT28 のマルウェア PROMPTSTEAL は、中国 Alibaba 製のオープンウェイトモデル Qwen2.5-Coder-32B-Instruct を Hugging Face の API 経由で呼び出し、コマンドを生成した。Google はこれを「実運用でマルウェアが LLM に問い合わせた最初の観測」と記す [A02]。
  • 中国国家支援と Anthropic が評価した GTG-1002 は、米国製の Claude Code を使って約 30 標的を攻撃した [A10]。
  • 2026 年に確認された攻撃者は、Claude・Gemini・Codex を切替ツールで使い分け、商用 API の監視を避けるために侵害済み環境へオープンウェイトモデルをローカル展開していた [A05]。OpenAI も中国の作戦が DeepSeek・Qwen をローカルで運用していたと報告している [A13]。

道具が国境を越えるなら、攻撃面も国境を越える。日本の運用システムに届く経路は、製品の製造国の企業や人員を一切経由せずに構成できる。

攻撃経路の比較表——製造国の確認で閉じるのは 7 経路中 1 つ

攻撃経路攻撃者に製造工程の関与が必要か製造国の確認で防げるか製造・開発工程の審査で防げるか境界防護で遮断・局所化できるか事例
製造段階でのコード混入必要製造国が攻撃者の所在地と一致する場合のみ部分的に工程審査の対象。ただし★1 はサプライチェーンの接触を「想定しない」[J02]遮断できない。不正動作の通信先・頻度を制限して局所化は可能公開された確認事例なし [D02]
更新基盤（配信サーバー・署名鍵）の侵害不要防げない防げない。審査時点の工程が健全でも後から侵害される配信先・時期の制限で局所化。内容の検証は不可SolarWinds [I03]
クラウド制御面の侵害不要防げない防げない。機器に必須の付随サービスは対象だが、16 項目はサービス側の運用（管理者権限・API の認可範囲・侵害時に一斉指令を止める仕組み）を評価しない [J02, J05]書込系指令を境界で遮断できる構成なら遮断Solarman/Deye、SUN:DOWN [I06, I07]
正規管理者アカウントの乗っ取り不要防げない防げない。認証機能の有無は見るが、正規の資格情報は通る操作種別・到達台数の制限で局所化ウクライナ 2015、KA-SAT [I01, I04]
認証後に公開される未知の脆弱性不要防げない防げない。審査はある時点の製品の状態外部から到達しなければ公開前後とも悪用されないRDI 試験で 9 機種すべて不適合 [F05]
第三国の基盤・踏み台を経由した遠隔攻撃不要防げない。経路は製造国と無関係防げない通信先の列挙で経路を制限APT28 × Qwen [A02]
内部者・物理アクセス不要防げない防げない単独では防げない。権限分離で範囲を狭める—
技術的推論

製造国の確認が機能するのは、第 1 行の「製造段階でのコード混入」で、かつ製造国が攻撃者の所在地と一致する場合だけである。残りの 6 経路は、攻撃者が製造工程に関与する必要すらない。攻撃者はクラウド、通信経路、更新基盤、管理者権限のうち、利用できる攻撃面を一つ侵害すれば目的を達成し得る。

工程審査が見る範囲と、運用中に残る攻撃面

図3 工程審査が見る範囲と、運用中に残る攻撃面 製造・開発・納入・設置・運用・更新の各段階を横軸に置く。製造・開発段階の審査が対象とする範囲は左側に限られ、運用・更新段階にはクラウド、管理アカウント、通信経路、未知の脆弱性、更新配信という攻撃面が残る。 製造 開発 納入 設置 運用 更新 製造・開発工程の審査が見る範囲 ★1 適合（ある時点の製品機能） 運用中に残る攻撃面（審査の対象外） クラウド制御面 管理者アカウント 通信経路・露出 公開後の未知の脆弱性 更新配信・署名鍵 保守端末・現地協力者 設備寿命 15〜20 年
図B　製造・開発・納入・設置・運用・更新の段階を横軸に置く。製造・開発工程の審査（青）が見るのは左の二段階とある時点の製品機能だけで、設備寿命 15〜20 年の大半を占める運用・更新段階（赤）にクラウド制御面・管理者アカウント・通信経路・公開後の脆弱性・更新配信・保守端末という攻撃面が残る。 [SVG]

設備寿命は 15〜20 年である。製造・開発工程の審査は、その最初の数か月とある時点の製品機能を見る。残りの期間——運用と更新——に、クラウド制御面・管理者アカウント・通信経路・公開後の脆弱性・更新配信・保守端末という攻撃面が残り続ける。★1 の有効期間は 2 年だが [J02]、2 年ごとの再宣言は製品機能の再確認であって、運用中の攻撃面の点検ではない。

政府の説明との整合

確認された事実

政府は国会で、JC-STAR 制度は「特定の国や企業の製品の使用を禁止するような制度ではなく、一定のサイバーセキュリティー水準を満たす機器であるかどうかを確認、認証する制度」と答弁し [D04]、「特定国の企業や製品を念頭に置いたものではない」と繰り返した [D05]。経済安全保障担当大臣も「特定の国を念頭に置いたものではない」と答弁している [D03]。一方で、★1 の文書には「ラベル発行前にサプライチェーン・リスクを政府関係機関に照会する」脚注があり、その判断基準は公開されていない [J02, J05]。

制度の評価

制度の公式説明が「製品の機能水準の確認」であるなら、本章の表のとおり、閉じる経路は限られる。公式説明にない「製造国の選別」が実際の目的であるなら、それでも閉じる経路は第 1 行だけである。どちらの読み方でも、更新基盤・クラウド・管理者アカウント・未知脆弱性・第三国経由の 5 経路に対する防御効果は確認できない。

行政への公開質問（攻撃主体の非限定性について）

  1. 製造元や開発工程の調査によって、具体的にどの攻撃経路を防止できると評価しているのか。
  2. 特定国の製品を排除しても、第三国経由の攻撃やクラウド侵害が可能であることを、制度設計時に考慮したか。
  3. 攻撃主体の国籍・所在地と、製品の製造国が一致しないことを前提に、どのような脅威モデルを採用したか。
  4. 製品審査と IEC 62443 に基づく境界防護の費用対効果を比較したか。
  5. AI による攻撃能力の普及を、制度の実効性評価に反映しているか。
  6. 製造・開発工程の調査では防止できない攻撃について、どの制度・技術によって被害を防止する計画なのか。
  7. 製品認証を系統連系の必要条件にする合理性を、実際の防御効果によって説明できるか。

既存の回答との対応は第10章の表にまとめた。

3. AI 攻撃能力の拡散——製品の出自に依存した防御が成り立たない理由

確認されていること、確認されていないこと

確認された事実

確認されていること。

  • 国家支援アクターの AI 利用は 2024 年以降継続的に観測されている。Google は 20 か国超のアクターが Gemini を利用していると報告した [A01]。
  • AI 支援の脆弱性発見と悪用は実証されている。Google の Big Sleep は SQLite の未知の脆弱性を発見し、2025 年 8 月までに 20 件を報告した [M09]。DARPA AIxCC 決勝では自律システムが実在の脆弱性 18 件を含む 54 件を発見し、タスクあたり約 152 ドルだった [M10]。XBOW の自律ペンテスターは HackerOne の米国リーダーボード首位に立った [M11]。Anthropic は 2026 年、Mythos Preview が主要 OS・ブラウザのゼロデイを自律的に発見・悪用し、OSS 1,000 プロジェクトで 6,202 件を見つけたと報告した [M14]。日本の国家サイバー統括室はこのモデルを名指しして重要インフラ事業者に注意喚起した [A19]。
  • 2026 年 5 月、Google は「AI で開発されたと考えられるゼロデイ・エクスプロイトを使う攻撃者を初めて特定した」と報告した（犯罪系アクター）[A04]。同報告は、中国系と疑われるアクターが AI 攻撃フレームワークを日本の技術企業に対して使ったと記している。
  • 2025 年 8 月、Anthropic は基礎的スキルしか持たない犯罪者が Claude Code でランサムウェアを作って販売した事例を報告した [A09]。2026 年 9 月の報告は「アクターの階層を分けるのはもはや技量ではなく意図である」「どの作戦も全く新しい技術には依存していない。変わったのは攻撃の経済だ」と総括している [A12]。同報告の GTG-50014 は、エネルギー企業に対して「家庭用 EV 充電器の充電電流を遠隔制御できる」と主張した。
  • オープンウェイトモデルは商用利用可能な条件で公開され（DeepSeek-R1: MIT、Qwen3: Apache 2.0、gpt-oss: Apache 2.0）、量子化すれば消費者向け機器で動く [M01, M02, M03, M06]。米 NIST CAISI の評価では、DeepSeek-R1 公開後に中国製モデルのダウンロードが約 1,000% 増え、R1-0528 はエージェント乗っ取り指示に米国モデルの 12 倍従いやすかった [A17]。安全策は 10 例・0.20 ドル未満の微調整で外せる（査読論文）[M07]、Llama 2 の安全微調整は 200 ドル未満で除去できる（プレプリント）[M08]。
  • 英国 NCSC は「AI 支援の脆弱性研究とエクスプロイト開発」を最大の変化とし、「開示から悪用までの時間は日単位に縮んだ」と評価した [A15]。

確認されていないこと。

  • 2026 年 9 月時点で、Google・Microsoft・NCSC のいずれも「完全自律の攻撃パイプラインを実環境で観測していない」と明記している [A05, A08, A15]。
  • AI が電力系統を自律的に攻撃した確認済み事例はない。Dragos・ENISA の OT 年次報告にも、AI の関与が明示された DER 標的の事例はない [A21, A20]。
  • Anthropic の「戦術作業の 80〜90% を AI が実行」は自己申告で、IOC・TTP は非公開、外部から帰属と自律度に疑義が出ている [A10, A11]。同報告自身が「Claude は頻繁に成果を誇張し、時に捏造した」と記す。
  • CVE 公開件数は 2023 年 28,961 → 2024 年 40,077 → 2025 年 48,244 と増えているが、増加の主因は CVE 採番機関の拡大であり、AI を原因とする一次証拠はない [M15]。

本記事が AI から引き出す結論

技術的推論

AI について本記事が依拠するのは「自律攻撃が起きている」という主張ではない。依拠するのは次の三点で、いずれも一次資料で確認できる。

  1. 攻撃能力の供給元と攻撃者が分離した。 ロシアの攻撃者が中国製モデルを、中国の攻撃者が米国製モデルを使う [A02, A10]。製品やモデルの出自を見ても、誰が攻撃してくるかは分からない。
  2. 攻撃の限界費用が下がった。 脆弱性発見・エクスプロイト作成・偵察の自動化は実証済みで [M09, M10, M11, M14]、開示から悪用までは日単位 [A15]。「認証後に公開される脆弱性」（第2章の表 第 5 行）は、以前より速く、安く、広く悪用される。
  3. 監視を避ける手段がある。 オープンウェイトモデルのローカル運用は、商用 API 側の検知を無効にする [A05, A13]。モデル提供者の善意に依存した抑止は、国家主体には効かない。

したがって、「信頼できるメーカーの製品だけを接続する」設計は、攻撃者の能力が普及し、出自と無関係に調達できる環境では、安全性の根拠にならない。必要なのは、侵害された機器やクラウドが存在しても系統全体への被害を止める構造である（第6章）。

資源エネルギー庁は、AI による攻撃能力の変化を脅威モデルにどう反映したかについて、資料を示していない（第10章 Q4）。

4. JC-STAR★1 は何を防ぐのか——制度文書に書いてあること

批判は制度の実際の内容に対して行う。IPA の公開文書と当社への回答から、★1 の範囲を確認する。

確認された事実

★1 の評価対象と評価方法（JST-CR-01-01-2024R1 v1.1、2024 年 12 月）[J02]

  • 対象は「IoT 製品」＝IoT 機器＋必須付随サービス（機器の機能に必須のクラウド・アプリ）。「システム」は対象外（p.5）。付随サービスは機器側から見た要件（通信の保護、認証など）として評価され、サービス側の運用——管理者権限の管理、API の認可範囲、侵害時に一斉指令を止める仕組み——は 16 項目に含まれない。
  • 評価方法は自己適合宣言。「適合ラベル交付時に定められた適合基準に適合しているかを IPA は確認しない。つまり、評価の信頼性はベンダーの信頼性に依存する」（p.4）。
  • 有効期間 2 年（p.6）。脚注 1：ラベル発行前に IPA がサプライチェーン・リスクを政府関係機関に照会する。判断基準は非公開 [J05]。
  • 想定するアタックサーフェスは 5 種（ネットワーク、無線、物理ポート、UI、付随サービス）。「『製品開発・調達等のサプライチェーンにおける接触』のアタックサーフェスは想定しない」「『不正改造』の脅威は対象外」（p.9–10）。
  • 適合基準は S1.1-01〜16 の 16 項目（p.12–31）。国会答弁でも「十六項目のセキュリティー要件に集約される星1」と説明された [D01]。

★1 の 16 項目が扱う領域（要約）

16 項目は、既定パスワードの禁止と認証の保護、ソフトウェア更新機能と更新の真正性検証、通信と保存データの保護、不要なサービスの無効化、ログの取得、脆弱性情報の窓口とサポート期間の公表といった、機器一台の基本的な衛生を扱う。項目番号ごとの原文は [J02] p.12–31 を参照されたい（本記事は要約であり、個別項目の文言を引用しない）。

★2 以上。 ★2 の適合基準・評価ガイド・チェックリストは 2026 年 10 月 23 日時点で「準備中」、申請受付は「2026 年以降の開始を計画」[J04]。資源エネルギー庁は「電力分野固有の脅威や特性等を踏まえた JC-STAR 星2 の策定や要件化に向け…検討を進めてまいります」と答弁したが [D06]、時期を明言した資料は「存在いたしません」と回答している [G10]。広域機関資料は「★2 以上の基準の整備や導入についても…要件化を進めていく」と記す [G09]。

IPA の回答（2026 年 7 月）[J05]

  • 「『境界防御』という考えは導入していません」
  • 「『適合ラベル取得済み』は、『安全に設置・運用されている』ことではなく、評価対象製品が★1 で要求する適合要件を有していることを示す」
  • 評価対象は「外部からの直接通信を受信することを前提」
  • サプライチェーン確認の公開文書は「ありません」
技術的推論

16 項目は、一台の機器がインターネットに直接さらされたときの基本的な衛生を定めている。既定パスワードの廃止と更新機能は、第2章の表の第 1 行（機器一台の露出）に効く。これは意味のある要件であり、本記事は否定しない。

しかし 16 項目は、クラウド制御面が正規の API で一斉指令を出すこと、署名鍵が盗まれて正規の更新に見える不正更新が配られること、正規の管理者資格情報で保守端末から操作されることを、対象にしていない。IPA の回答はこれを「安全に設置・運用されていることを示すものではない」と正確に述べている。制度文書と IPA の説明の範囲で、★1 は第2章の表の第 2〜7 行に対する防御効果を主張していない。

制度の評価

問題は★1 の内容ではなく、★1 を系統連系の必要条件に置いたときに、制度の設計者が★1 の防御範囲を超える効果を期待している点にある。資源エネルギー庁は「サイバー攻撃があれば系統は完全につぶれてしまう」という座長の指摘に対し、「JC-STAR★1 から取り組み、蓋然性を低くしたい」と回答した [G07]。しかし「系統がつぶれる」規模の攻撃は、本章で見たとおり★1 の対象外の経路で起きる。

5. 製造工程審査では不十分である——運用段階の攻撃面

図1 製造から運用までの攻撃経路 攻撃者は製造工程・開発工程・更新配信サーバー・クラウド制御面・通信経路・管理者アカウント・現場ネットワークのいずれからでも現場設備に到達できる。JC-STAR★1 が評価するのは現場設備（製品）の機能だけで、他の到達点は対象外。 攻撃者 製造工程 ソフトウェア 開発工程 更新配信サーバー 署名鍵 メーカーの クラウド制御面 通信経路 （インターネット・携帯網） 管理者アカウント （保守・遠隔監視） 現場ネットワーク 現場設備 PCS・蓄電池・EV充電器 JC-STAR★1 が評価する範囲（製品の機能） 評価の対象外 どの経路からでも、同じ設備に同じ指令が届く
図1　製造から運用までの攻撃経路。攻撃者は製造工程・開発工程・更新配信サーバーと署名鍵・メーカーのクラウド制御面・通信経路・管理者アカウント・現場ネットワークのどこからでも現場設備に到達できる。JC-STAR★1 が評価するのは右端の製品機能だけで、それ以外の到達点は評価の対象外（IPA 回答 2026年7月26日）。 [SVG]

図 1 は、製造から運用までの経路を一枚に置いたものである。JC-STAR★1 が評価するのは右端の「製品機能」だけで、製造工程・開発工程・更新配信サーバーと署名鍵・クラウド制御面・通信経路・管理者アカウント・現場ネットワークは評価の対象外である [J02, J05]。

工程審査の限界を事例で確認する

技術的推論

製造・開発工程の審査には、審査時点以降の時間軸と、製品の外側にある基盤が入らない。設備寿命 15〜20 年のうち、工程審査がカバーする時間は最初の数か月であり、空間は製品の筐体の内側である。攻撃者が使う時間と空間はその外側にある。

制度の評価

製造工程の審査を「電力系統の安全性を高める」と説明するためには、審査対象の工程で起きる攻撃が、電力系統への脅威の主要部分を占めることを示す必要がある。第1章・第2章で確認した事例の分布はその逆である。行政側のリスク分析は IPA のリスク分析ガイドに基づく定性的なもので、経路別の発生確率と影響量の定量値はない [G06]。

6. IEC 62443 と境界防護——信頼できない機器があっても系統を守る構造

二つのモデル

図4 製品認証中心モデルと境界防護中心モデル 左は製品認証中心: 信頼境界は製品一台ごとにあり、クラウドと更新配信が全台に直結する共通障害点。右は境界防護中心: 信頼境界はサイト境界にあり、クラウドからの指令は境界で検証され、共通障害点は境界装置の型式に移る。 A 製品認証中心 メーカーの クラウド制御面 更新配信サーバー 署名鍵 認証済み 機器 認証済み 機器 認証済み 機器 認証済み 機器 認証済み 機器 信頼境界 = 製品一台ごと 共通障害点: クラウド・更新配信 → 全台へ直結 侵害時の波及: 制御面に属する全台 B 境界防護中心 メーカーの クラウド制御面 更新配信サーバー 署名鍵 境界装置 許可リスト・指令検証・速度制限 ローカル EMS 出力の床・自律運転 機器 機器 機器 機器 機器 信頼境界 = サイト境界 共通障害点: 境界装置の型式 → 型式を分ける・段階更新 侵害時の波及: 境界が働かないサイトのみ
図2　左の製品認証中心モデルでは信頼境界が製品一台ごとにあり、クラウドと更新配信が全台に直結するため、そこが共通障害点になる。右の境界防護中心モデルでは信頼境界がサイト境界に移り、クラウドからの指令は境界で検証される。共通障害点は境界装置の型式に移るので、型式を分け段階更新する必要がある。どちらにも共通障害点はあり、問題はそれが何台に直結しているかである。 [SVG]

製品認証中心モデル（左）。 信頼境界は製品一台ごとにある。クラウド制御面と更新配信は全台に直結している。だから、クラウドと更新配信が共通障害点になる。一台一台が健全でも、制御面が侵害されれば全台が同時に動く。

境界防護中心モデル（右）。 信頼境界をサイト境界に移す。クラウドからの指令は境界装置で宛先・プロトコル・ファンクションコード・頻度を検証される。内側のローカル EMS が出力の床と通信断時の既定動作を持つ。共通障害点は消えないが、境界装置の型式に移る。だから、型式を分け、段階更新する。

確認された事実

この構造は当社の発明ではなく、制御システムのセキュリティ規格が 10 年以上前から定めている考え方である。

  • IEC 62443-3-2:2020：ゾーンを「リスクその他の基準（資産の重要度、運用機能、物理的・論理的位置、必要なアクセス、責任組織）に基づく論理的・物理的資産のグループ」、コンジットを「二つ以上のゾーンを結び、共通のセキュリティ要求を持つ通信チャネルの論理的グループ」、セキュリティレベルを「SUC・ゾーン・コンジットが脆弱性を持たず意図どおりに機能することへの確信の度合い」と定義し、SUC の定義→ゾーン・コンジットへの分割→ゾーンごとのリスク評価→目標 SL の設定→文書化を要求する。項目には「業務系と IACS 資産の分離」「外部ネットワーク経由で接続する機器の分離」が含まれる [S01]。
  • IEC 62443-2-1:2024：資産所有者に「IACS を非 IACS ゾーンから分割し、相互接続を IACS 運用に必要な最小限に限る方針と手順を持つこと」（NET 1.1）を要求する。認証製品の使用は「望ましい」とされ、その適合は「制御システムが評価された時点」の状態を示すものと位置づけられている [S01]。
  • IEC 62443-3-3：システム要件を 7 つの基礎要件（FR1 識別・認証、FR2 使用制御、FR3 システム完全性、FR4 データ機密性、FR5 データフロー制限、FR6 事象への適時応答、FR7 資源可用性）とセキュリティレベル SL1〜4 で定める [S01]。
  • IEC 62443-4-1 / 4-2：製品開発ライフサイクルとコンポーネント要件。★1 が対応し得るのはこの層である。
  • NIST SP 800-82 Rev.3：多層防御、ネットワーク分割、境界保護、通信断時の運転継続を OT セキュリティの基本に置く [S02]。
  • NIST SP 800-207：ネットワーク上の位置を信頼の根拠にしない（ゼロトラスト）。本記事の境界防護は「境界の内側は信頼する」ではなく、「境界で検証し、内側でも権限を分ける」である [S03]。

規格本文は有償で、本記事は公開されているスコープと用語の範囲だけを根拠にし、個別要求事項の文言は引用しない。

★1 と IEC 62443 の対応

IEC 62443-3-3 の基礎要件内容★1 の 16 項目で扱うか境界防護モデルでの担い手
FR1 識別・認証制御誰が・何が接続しているか機器単体の認証は扱う境界装置と EMS の相互認証、メーカー経路と系統運用者経路の分離
FR2 使用制御認証された主体に何を許すか扱わない（正規の資格情報は通る）ファンクションコード単位の許可リスト、書込系の遮断、到達台数の制限
FR3 システム完全性改ざんの検知更新の真正性検証は扱う更新配信先・時期の制限、段階適用
FR4 データ機密性通信・保存の暗号化扱う（通信・保存データの保護）境界で終端し内側は監査可能に
FR5 データフロー制限ゾーン間の通信制御扱わない（「境界防御という考えは導入していない」[J05]）境界装置そのもの
FR6 事象への適時応答検知・ログ・対応ログ取得は扱う境界での検知、サイト横断の相関
FR7 資源可用性通信断・攻撃下での運転継続扱わないローカル EMS の既定動作、出力の床、手動復帰
技術的推論

★1 は FR1・FR3・FR4 の機器側を部分的に担う。FR2・FR5・FR7 を担うものが、現行の要件化にはない。 第2章の表の第 2〜6 行（クラウド・更新基盤・管理者アカウント・未知脆弱性・第三国経由）は、まさに FR2・FR5・FR7 で止める経路である。

境界防護を備えた分散型電源システム

図5 境界防護を備えた分散型電源システム インターネット上の複数メーカーのクラウドと充電管理システム（CSMS）からの通信は、サイト境界の装置で宛先・プロトコル・ファンクションコード・頻度を検証される。境界の内側ではローカル EMS が出力の床と自律運転を保ち、異なるメーカーの PCS・蓄電池・OCPP 充電器を同じ境界が守る。系統運用者の指令経路はメーカー保守経路と分ける。 インターネット メーカー A クラウド メーカー B クラウド 充電管理 CSMS（OCPP） 系統運用者 出力制御・指令 境界装置 許可リスト／プロトコル検証／書込ファンクション制限／速度制限／ログ 一斉停止・設定変更・未知の宛先 許可された読取・限定された書込 ローカル EMS 出力の床・通信断時の既定動作・権限上限 PCS A社 PCS B社 蓄電池 C社 EV充電器 OCPP 許可された読取・限定された書込 → ローカル EMS
図3　複数メーカーのクラウドと充電管理システム（CSMS）からの通信は、サイト境界の装置で宛先・プロトコル・ファンクションコード・頻度を検証される。内側のローカル EMS が出力の床と通信断時の既定動作を保ち、A 社 PCS・B 社 PCS・C 社蓄電池・OCPP 充電器を同じ境界が守る。系統運用者の指令経路（青）はメーカー保守経路（赤）と分ける。各機器でこの構成が組めるかは第7章の公開仕様の表を参照。 [SVG]

A 社 PCS・B 社 PCS・C 社蓄電池・OCPP 充電器を、同じサイト境界が守る。メーカーのクラウドと充電管理システム（CSMS）からの通信は境界装置で検証され、系統運用者の指令経路（青）はメーカー保守経路（赤）と分ける。内側のローカル EMS が、通信断時の既定動作と出力の床を保つ。

侵害時に何が起きるか。 メーカー A のクラウドが侵害され、全台に「出力ゼロ」指令が出たとする。製品認証中心モデルでは、指令は正規の API・正規の署名で届くので全台が従う。境界防護モデルでは、境界装置が書込系ファンクションコードを遮断するか、EMS が出力の床（例: 直近 10 分平均の 50% 未満への急変を拒否）で受け流す。A 社のクラウドが侵害されても、A 社 PCS を含むサイトは系統運用者の指令経路で動き続ける。

境界防護で防げないこと

注意

本記事は境界防護を万能とは書かない。

  • 境界装置自身の脆弱性。 デンマーク 2023 は共通の境界装置が侵害された事例である [I05]。境界防護モデルは新しい共通原因を持ち込む。型式の多様化（第8章の計算では 5 型式で上限 2,000 MW）と段階更新が必須である。
  • 内容の検証。 正規署名の不正更新（SolarWinds 型）は、境界で配信先と時期を制限できるが、内容の正否は判定できない。
  • 内部者・物理アクセス。 境界の内側にいる者には効かない。権限分離と監査で範囲を狭めるだけである。
  • ゾーン内の横移動。 NIST SP 800-82r3 は「ゾーン間の境界装置はゾーン内の横移動リスクを緩和しない」と明記する [S02]。境界の内側でも PCS・EMS・保守端末の間で権限を分ける必要がある。同文書は PLC・HMI 等がゼロトラスト構成に対応できない場合があるとも書いており、境界装置は「ゼロトラストができないから」こそ要る層である。
  • 設定誤り・運用漏れ。 当社モデルでは境界装置が設計どおりに働く確率を ρ=0.9（0.7〜0.98）に置き、1 割は届くとして計算している。RDI の「9 機種すべて不適合」[F05] を根拠に、1 に置かない。
  • 機器側の協力。 境界の内側でローカル制御ができる機器でなければ構成できない。第7章で各機器の公開仕様を確認する。
I-S3 の提案

I-S3 の提案：代替適合手段としての境界防護。 系統連系技術要件に、次を「JC-STAR★1 取得製品の使用」と同等の措置として位置づける。

  1. 分散型電源の制御ゾーンを IEC 62443-3-2 の意味で定義し、外部との通信をコンジット上の境界装置に集約する。
  2. 境界装置は、宛先・プロトコル・ファンクションコード・頻度の許可リストを持ち、書込系指令は系統運用者の経路に限る。
  3. ローカル EMS が通信断時の既定動作と出力急変の床を持ち、手動で復帰できる。
  4. 境界装置の型式を同一事業者で 1 型式に集約せず、更新は段階適用する。
  5. 構成を第三者が検証できる形で記録する（通信先一覧・遮断規則・試験結果）。

広域機関資料は閉域網等を「ラベル取得に加えて」推奨している [G08]。本記事の提案は、これを代替として認めることである。両方を求めるなら、両方が必要な理由を示す必要がある。

7. PCS・蓄電池・EV 充電器——境界防護を組める機器か、公開仕様で確認する

境界防護は、機器がローカルで制御を受け付け、クラウドなしで既定動作を持てることを前提にする。主要機器の公開仕様から、その前提が成り立つかを確認する。

注意

以下は各社の公開資料（出典に版・日付を記載）にある機能の有無で、当社が実機で全項目を検証したものではない。版・国別設定・施工時の設定で挙動は変わる。導入前に自分の機器で確認してほしい。当社はメーカー 21 社に更新配信・署名鍵・遠隔制御の上限について公開仕様の照会を送っており [X07]、回答が届き次第この表を更新する。

機器・系統ローカル制御の公開仕様クラウド依存の経路通信断時の挙動（公開資料の範囲）境界防護モデルでの扱い
SolarEdge PCS（SetApp 機）SunSpec Modbus TCP（既定無効、ポート 1502、LAN 専用、単一リーダー）。Power Control Open Protocol で出力制限・系統保護整定値を R/W。Dynamic 制御はタイムアウトでフォールバック値へ戻る [V01]監視プラットフォームからの遠隔設定変更・ファームウェア更新（機器発の接続が前提）「インターネット接続なしでも PV 発電・系統規制への適合は継続」と明記。「Safe mode（一方向通信）」でクラウドからの全受信コマンドを破棄できる。遮断中のデータ保持は最大 2 週間 [V01]Modbus TCP 書込を境界で系統運用者経路に限定。Safe mode を有効化し、クラウド向けは送信専用に。Modbus 書込への追加認証の有無は公開資料で未確認
Huawei SUN2000 + SmartLogger3000北向き Modbus TCP・IEC 60870-5-104・DI 接点制御。第三者向け Modbus TCP サーバは「認証機構がない」ため既定無効、許可 IP 最大 5 件 [V02]FusionSolar（TLS 上の Modbus TCP クライアント、ポート 27250）からの遠隔設定・更新。「Management system communication」は Enable/Disable 可「スケジュール途絶時に出力を制限」は既定 Disable（途絶しても自動制限しない）。国規格が要求する地域では「通信断で自動 OFF」の設定あり [V02]SmartLogger を境界の内側に置き、FusionSolar 向け通信を境界で制限。Remote control mode を Secure（パラメータ変更はローカル接続のみ）にする。管理システムなしでの長期運転を明示した文言は未取得
Victron（Cerbo GX 系）Modbus TCP（既定無効、ポート 502、Write allowed／read-only 選択）、ローカル MQTT（既定無効）、Node-RED。ESS Mode 3 はローカル書込で完結 [V03]VRM Portal の Remote Console・Remote VEConfigure・遠隔更新（VRM 設定「Full」時のみ）VRM 設定に「Off／Read-only／Full」。Read-only で遠隔設定変更・遠隔更新が無効、Off で送信も停止。ログは本体に数日保持し手動転送可。ESS Mode 3 は 60 秒ごとの書込が途切れると Passthru（充放電停止）[V03]VRM を Read-only、Remote support は既定 Disabled のまま、Modbus TCP は read-only で監視用に。制御は境界内の EMS から
OCPP 充電器（1.6J / 2.0.1）CSMS 発の SetChargingProfile・RemoteStart/Stop・ChangeAvailability・Reset・UpdateFirmware。セキュリティプロファイル 1〜3（1 は平文＋Basic 認証、「信頼できるネットワーク内のみ」）。2.0.1 Local Controller は CSMS と独立に充電上限を課せる [V04]CSMS が事実上の制御面。CSMS 侵害は全充電器への同時指令を意味する。1.6J の平文 WebSocket への MITM・二重接続 DoS が実証されている [I15]1.6 §3.5「中央システムが使えなくても充電器はスタンドアロンで動作するよう設計」。オフライン中は受領済み TxProfile を継続、未受領なら TxDefaultProfile [V04]。実機の対応は OCA 認証書（C-01）で機種ごとに確認が要る境界で CSMS 経路をプロファイル 3 で認証・制限。ローカルコントローラまたは EMS が負荷の上限を持つ。現行改定案は EV 充電器を対象にしていない [G02]
国内 出力制御機能付 PCS（低圧・高圧）ECHONET Lite（住宅用太陽光発電・蓄電池クラス、出力制御設定は Set 可）[V05]。出力制御は電力会社サーバーから固定スケジュール（400 日分）と更新スケジュールを機器側から HTTPS で取得する方式（外部からのセッション開始不可が仕様）メーカー監視クラウド（機種による）。オムロンの計測ユニットはソフト自動更新が既定で有効 [V05]上位サーバー途絶時は既取得のスケジュールで継続。ただし固定スケジュールの期限切れで発電停止、出力制御ユニット–PCS 間の通信異常は 5 分で発電停止、時計消失時は復旧まで停止 [V05]HEMS／EMS と出力制御ユニットを境界の内側に置き、電力会社サーバー向け HTTPS 443 だけを機器発で許可。メーカークラウド向けは境界で制限。年 1 回以上の固定スケジュール更新経路を残さないと止まる
産業用境界装置Moxa EDR-G9010: Modbus/TCP の「Read Only／Write Only／Read/Write／Manual」プロファイル、ファンクションコード列挙、IEC 104・MMS・DNP3 も対象、IEC 62443-4-2 SL2 認証 [V06]。Phoenix Contact mGuard: Modbus TCP DPI でファンクションコード・PDU アドレス単位に Accept/Drop、ただし別ライセンス（Modbus TCP Inspector）が必要で、10.4 系は非対応・10.5 で再追加 [V07]。FortiGate はシグネチャ単位の検知・遮断（許可リスト方式にできるかは未確認）、Siemens SCALANCE SC-600 はファンクションコード単位のフィルタ記載なし [V08]——本記事の「境界装置」。型式を分けることが前提。価格は流通価格のみ確認（Moxa 約 3,000 ドル、mGuard 入門機約 940 ユーロで DPI ライセンス対応は未確認）
ローカル EMS（SunSpec / ECHONET Lite / OpenEMS）情報モデルが公開され、メーカー横断でローカル制御の対象になる。OpenEMS は「明示的に列挙したチャネルだけ外部から書込可」で SolarEdge・Huawei の実装を持つ [V08, V05]——境界装置・EMS がメーカー横断で許可リストを書ける根拠
技術的推論

SolarEdge・Huawei・Victron の PCS・ゲートウェイと OCPP 充電器は、クラウドを遮っても発電・充電が継続することがメーカー資料または仕様書で確認でき、ローカル Modbus TCP（SunSpec 系）または ECHONET Lite で制御を受け付ける。つまり、境界防護モデルは既存機器で構成できる。必要なのは機器の入れ替えではなく、クラウド経路を境界で制限し、ローカル経路を系統運用者の指令に使う配線と設定である。

ただし国内の出力制御機能付 PCS には、制度側の設計に由来する条件がある。固定スケジュールの期限切れ、出力制御ユニットと PCS の間の通信異常、時計の消失で発電が止まる仕様になっているため [V05]、境界の内側に置くなら電力会社サーバーへの機器発 HTTPS だけを通す規則が要る。これは境界防護の障害ではなく、むしろ系統運用者の経路だけを残す構成そのものである。一方で、ファンクションコード単位で書込を遮れる境界装置は Moxa・Phoenix Contact の少なくとも 2 社が公開仕様に持つが、ライセンスや版に依存する [V06, V07]。「境界装置の型式を分ける」提案は、選択肢が複数あることが前提であり、現時点でその前提は成り立つ。

EV 充電器という穴

確認された事実

改定案に「電気自動車」「EV」「需要設備」の語はなく、EV 充電器は対象外である [G02]。一方、OCPP 充電器は CSMS から SetChargingProfile で充電電流を一斉に変更でき [V04]、2026 年 9 月の Anthropic 報告では攻撃者がエネルギー企業に対して「家庭用 EV 充電器の充電電流を遠隔制御できる」と主張した事例が記載されている [A12]。英国は EV 充電器・家庭用蓄電池に ETSI EN 303 645 準拠と最大 10 分のランダム遅延を 2027 年 12 月 31 日から要求する案を出している [F07]。

制度の評価

系統への影響という観点では、発電側の PCS が一斉に止まることと、需要側の充電器が一斉に動くことは同じ周波数偏差を生む。発電設備には製品認証を課し、同じ制御面を持つ需要設備には何も課さない差を、行政はどのリスク評価で正当化しているか（第10章 Q5）。境界防護モデルは、発電・需要を問わず同じ境界で扱える。

8. 費用対効果——仮定値を明示した再現できるモデル

費用対効果を論じる前に一つ確認する。費用の安さは防御効果の代わりにならない。 第2章で見たとおり、★1 が閉じる経路は限られる。本章は「それでも費用面で★1 要件化は正当化されるか」ではなく、「両モデルの費用と到達範囲を同じ表に置いたら何が見えるか」を扱う。

モデル

入力はすべて data/assumptions.csv にあり、低位・基本・高位の 3 値と種別（fact-range／assumption／to-confirm）を持つ。model/cost_model.py は標準ライブラリだけで動く。

モデル A（製品認証中心）：事業者が負担する年間費用は、認証費用の価格転嫁と、同型式交換が「軽微な変更」でなくなる場合の交換遅延による逸失電力である。

\[ C_A = \frac{F_{cert} + F_{int}}{N_{units}\, T_{valid}} \cdot \frac{P}{P_{unit}} + \lambda\, d_A\, P\, CF \cdot 24 \cdot v \]

モデル B（境界防護中心）：境界装置の年割りと運用費、交換遅延（短い）の逸失電力である。

\[ C_B = \frac{K_B}{L_B} + O_B + \lambda\, d_B\, P\, CF \cdot 24 \cdot v \]

ここで \(F_{cert}\) は申請手数料（1 型式・未確認、基本 3 万円）、\(F_{int}\) は自己適合に要する社内工数（基本 150 万円）、\(N_{units}\) は 1 型式の出荷台数（基本 2 万台）、\(T_{valid}\) は有効期間 2 年（IPA 公表値 [J02]）、\(P\) はサイト容量 kW、\(\lambda\) は PCS の年間交換率（基本 2%）、\(d_A, d_B\) は交換遅延日数（基本 45 日／3 日）、\(CF\) は設備利用率 0.14、\(v\) は逸失電力の価値 15 円/kWh、\(K_B\) は境界装置の機器＋設置費（低圧 8 万円／高圧・特高 50 万円）、\(L_B\) は更新周期 7 年、\(O_B\) は運用費（低圧 1.2 万円／高圧・特高 12 万円）。

同時に動く容量（Cyber Blast Radius、定義は [X01]）：フリート容量 \(S\)、一つのクラウド制御面に属する比率 \(s_{cloud}\)、境界装置が働く確率 \(\rho\)、境界装置型式の占有率 \(s_{bnd}\) として、

\[ R_A = S\, s_{cloud}, \qquad R_B = S\, s_{cloud}\,(1-\rho), \qquad R_B^{cm} = S\, s_{bnd} \]

\(R_B^{cm}\) は境界装置型式の共通原因で、B 固有のリスクである。

結果

サイト区分A 年間費用B 年間費用A 円/kWB 円/kW損益分岐の境界装置費用
低圧・住宅（5 kW）265 円23,444 円534,6890 円（B は A を下回らない）
低圧・事業用（49.5 kW）2,284 円23,578 円464760 円
高圧（500 kW）22,718 円192,941 円453860 円
特別高圧（5,000 kW）226,838 円206,549 円4541642,028 円

（基本ケース。results/cost_per_site.csv、results/break_even.csv。）

図7 製品認証方式と境界防護方式の 1 kW あたり年間費用（対数軸・仮定値） 横軸はサイト規模 4 区分、縦軸は 1 kW あたりの年間費用（円、対数）。青が製品認証方式 A（認証費用の価格転嫁＋交換遅延の逸失電力）、緑が境界防護方式 B（境界装置の年割り＋運用費）。細線は low〜high の幅。 10 100 1,000 10,000 円 / kW / 年（対数） 53 4,689 低圧・住宅（5 kW） 46 476 低圧・事業用（49.5 kW） 45 386 高圧（500 kW） 45 41 特別高圧（5,000 kW） A 製品認証方式（認証費用の転嫁＋同型式交換が重くなる分の逸失電力） B 境界防護方式（境界装置の年割り＋運用費＋短い交換遅延）　細線: low〜high 入力はすべて data/assumptions.csv の仮定値。有効期間 2 年は IPA 公表値。申請手数料（kind=to-confirm）は公表値で置き換える。
図5　サイト規模 4 区分での 1 kW あたり年間費用（対数軸）。A は認証費用の価格転嫁と、同型式交換が「軽微な変更」でなくなる場合の交換遅延の逸失電力。B は境界装置の年割りと運用費。低圧では B が A より 1〜2 桁高く、特別高圧では同程度になる。費用側の入力は有効期間 2 年（IPA 公表値）を除きすべて仮定値で、申請手数料（kind=to-confirm）は公表値で置き換える。費用の安さは防御の到達範囲とは別の軸である（第8章）。 [SVG]
技術的推論

費用について。 事業者が負担する認証費用は小さい。1 型式あたりの費用を出荷台数で割るので、1 台あたり数十円から数百円になる。A の費用の大半は、同型式交換が「軽微な変更」でなくなる場合の交換遅延であり [G05]、これは制度運用で変わる（高圧で遅延 0 日なら年 38 円、120 日なら 60,518 円）。境界装置は低圧で 1〜2 桁高く、特別高圧で同程度になる。

この結果の読み方。 「A は安いから正当化される」とは読めない。A の費用が小さいのは、A が何もしていない経路が多いからでもある。第2章の表で A が閉じる経路は 7 のうち 1〜2 であり、閉じていない経路の費用はゼロである。一方 B の費用は、FR2・FR5・FR7 を担う装置と運用の費用である。費用の比較は、同じ到達範囲を持つ選択肢の間で初めて意味を持つ。

図6 攻撃時に同時に動く容量（条件付き） フリート 10,000 MW、クラウド制御面の占有率 25%、境界装置の実効率 0.9 という仮定での比較。A はクラウド 1 件の侵害で 2,500 MW が同時に動く。B は境界が働かない 1 割のサイトのみ 250 MW。B 固有の共通原因（境界装置型式の脆弱性）は全サイトが同一型式なら上限はフリート全体の 10,000 MW、型式を 5 に分けると 2,000 MW に下がる。 A: クラウド制御面 1 件の侵害 2,500 MW B: 同じ侵害（境界 ρ=0.9） 250 MW B 固有: 境界装置が全サイト同一型式（上限） 10,000 MW B 固有: 境界装置 5 型式に分散 2,000 MW MW（同時に動く容量の上限） フリート 10,000 MW・占有率 25%・ρ=0.9・仮定値
図4　フリート 10,000 MW・一つのクラウド制御面の占有率 25%・境界装置の実効率 ρ=0.9 という仮定での、侵害 1 件で同時に動く容量の上限。A ではクラウド 1 件で 2,500 MW、B では境界が働かない 1 割分の 250 MW。B 固有の共通原因（境界装置型式の脆弱性）は、全サイト同一型式なら上限がフリート全体に達し、5 型式に分けると 2,000 MW。値は data/assumptions.csv を変えると変わる。 [SVG]
シナリオ（基本ケース、フリート 10,000 MW）同時に動く容量
A：クラウド制御面 1 件の侵害（占有率 25%）2,500 MW
B：同じ侵害、境界が働く確率 ρ=0.9250 MW
B 固有：境界装置が全サイト同一型式（上限）10,000 MW
B 固有：境界装置 2 型式に分散5,000 MW
B 固有：境界装置 5 型式に分散2,000 MW
B 固有：年率 5% で悪用される場合の期待値（2 型式）250 MW/年

（results/blast_radius.csv。SolarPower Europe/DNV は 3 GW の同時侵害が欧州系統に重大な影響を与え得るとし、12 社超が 3 GW 超を保有すると評価した [F08]。）

技術的推論

共通障害リスクについて。 境界防護モデルの弱点は正直に数字に出る。境界装置を 1 型式に集約すれば、その型式の脆弱性でフリート全体が動き得る。デンマーク 2023 はこの型のリスクであり [I05]、2019 年の米国では境界ファイアウォールの既知脆弱性で再生可能エネルギー事業者が約 10 時間監視を失った [I14]。CISA の悪用済み脆弱性カタログ（2026-10-21 版、1,754 件）には Fortinet 32 件・Ivanti 36 件・Citrix 27 件・Palo Alto 16 件・Zyxel 13 件の境界装置系が載っており、当社モデルの「境界装置型式に年率 5% で悪用可能な脆弱性」という仮定はこの実績に基づく [I12]。だから提案（第6章）に「型式を 1 つに集約しない」「段階更新」を入れた。5 型式に分ければ上限は 2,000 MW で、A のクラウド 1 件（2,500 MW）を下回る。

製品認証中心モデルの共通障害は、認証取得メーカーへの供給収斂である。★1 を取得したメーカーが少数なら、\(s_{cloud}\) は上がる。国会では「主要中国メーカーは現時点でこの JC-STAR 星1 を取得できていないと承知」という質問側の発言があり [D05]、要件化が供給を収斂させる方向に働く可能性は制度設計者が検討すべき点である。製品を外す規則が残った製品の標的価値を上げる条件は [X03] で扱った。

感度

results/tornado.csv に一変数感度を置いた。A の年間費用を動かすのは交換遅延日数と PCS 交換率で、認証費用の項はほぼ効かない。B を動かすのは境界装置の機器費と運用費である。同時に動く容量を動かすのは \(s_{cloud}\)・\(\rho\)・\(s_{bnd}\) で、いずれも制度設計と運用で決まる値である。

この章が言わないこと

9. 系統連系要件化の妥当性——制度の形式と中身

確認された事実

確認された事実
  • 意見公募は e-Gov で「任意の意見募集」（根拠法令条項「-」）として公示され、受付は 2026 年 11 月 6 日 23:59 まで [G01]。要領は「JC-STAR★1 を取得した機器の使用を要件化する方向で議論を行ってまいりました」とし、「個別の回答はいたしかねます」と記す [G03]。
  • 適用は契約申込み受付日基準で、特高・高圧の太陽光・蓄電池・風力 2027 年 4 月 1 日、低圧の太陽光・蓄電池 2027 年 10 月 1 日、燃料電池 2028 年 4 月 1 日。風力のみ「又はこれと同等の機能を有する機器」を認める [G02]。
  • 「同一機器への交換であっても『軽微な変更』とはなりません」。論理的切断による分離でも免除されない。完全自家消費でも対象 [G05]。
  • 「インターネット等に直接露出していない場合であっても…対象」[G04]。また、国会答弁では「シリアル通信のように、インターネットと直接通信する機能を持たず…通信方法のみを利用する機器は対象となりません」[D05]。IP 通信機能を持つ機器は接続形態を問わず対象で、非 IP 機器だけが外れる。
  • 行政のリスク分析は IPA ガイド Ver2.0 に基づく定性的なもので、発生確率・影響量の定量値はない [G06]。メーカーヒアリングでは準拠製品の開発に 3.5〜4 年、データ削除機能に 1,000 万円オーダーという証言がある [G06]。
  • 資源エネルギー庁の文書回答：脅威モデル・リスク分析は「電力サブワーキンググループ資料をご参照」（資料名の特定なし）、IP／非 IP や IEC 62443 との比較は「要件化の観点ではございません」、境界防御・代替措置との比較は「比較資料ございません」、★2 以上の時期は「明言した資料は存在いたしません」、第三者検証は「担保する予定はございません」[G10]。
  • 広域機関は「JC-STAR 制度によらない対策によりサイバーセキュリティを確保することは否定されるものではなく」としつつ、閉域網等を「ラベル取得に加えて」推奨する [G08]。

海外との対比

制度対象手段日本の要件化との違い
EU Cyber Resilience Act [F01]デジタル要素を持つ製品全般製造者の義務（脆弱性対応・報告）、第三者評価は重要製品のみ。本則適用 2027-12-11製品側の義務であり系統連系の条件ではない。EU は別途、系統側に電力セクターのサイバーセキュリティ・ネットワークコード [F09] を持つ
EU NIS2 [F02]重要事業者事業者のリスク管理義務、サプライチェーンの協調リスク評価（Art.22）製品ラベルでなく事業者のシステム単位の義務
リトアニア 電力法 73-3 条 [F04]100 kW 超の発電設備国家安全保障上の脅威国の主体が遠隔で出力変更・起動停止できないことの確保（2025-05-01 施行）遠隔制御の経路を規制する。製品認証ではない。目的を明示している
英国 ESA 規則案 [F07]EV 充電器・電気暖房・家庭用蓄電池ETSI EN 303 645 準拠、最大 10 分のランダム遅延、2027-12-31 から需要側の遠隔制御機器を対象。太陽光インバータ単体は第 1 フェーズ対象外
米国 NERC CIP [S07]大電力系統（BES）事業者の資産分類とシステム単位の要件。配電系接続の DER には適用されない境界（ESP）と要件をシステム単位で定める。製品ラベルではない
オランダ RDI [F05]市販インバータ市場監視としての試験（9 機種すべて不適合）第三者が試験して結果を公表した
ドイツ連邦政府 答弁書 [F06]太陽光インバータ欧州の中国製比率を 70〜80% と推計し省庁横断で検討中（2026-06）製品禁止・認証義務のいずれも未導入。検討中であることを公開している
制度の評価

海外の主要な制度は、(a) 製品側の義務（CRA）、(b) 事業者のシステム単位の義務（NIS2・NERC CIP）、(c) 遠隔制御経路の規制（リトアニア）、(d) 第三者試験の公表（RDI）のいずれかである。自己宣言の製品ラベルを系統連系の必要条件に置き、代替措置を認めず、第三者検証も担保しない組み合わせは、当社が確認した範囲では日本の改定案だけである。

要件化の形式面——「標準的な指標」を示すガイドラインが、個別の約款の要件を事実上一律に定めること、任意の意見募集で個別回答をしないこと、同型式交換を「軽微な変更」から外すこと——は当社の先行記事 [X04] で扱った。本記事の論点はその前段にある。実効性が示されていない要件を、形式を整えて必要条件に置くことが問題である。

予見可能性

本記事は、施行前の 2026 年 10 月 23 日時点で、次を公開資料・技術的根拠とともに記録する。

当社は 2026 年 7 月から資源エネルギー庁・IPA に文書で質問し [X02]、10 月に意見を提出した（受付番号 620340012420402491）[X04]。経過は日付つきで台帳 [X05] に記録している。施行後に被害が発生した場合は、当該被害が制度の対象とする脅威に該当したか、どの防御策が機能しなかったか、事前に提案された対策によって防止または軽減できたかを、この記録に照らして検証する。

10. 行政が説明すべき事項——公開質問と回答状況

質問状形式で整理する。回答状況は、当社が受領した文書回答 [G10, J05] と公開資料に基づき、回答済み／未回答／資料不存在（行政が不存在と回答）／調査中で区別する。

#質問回答状況根拠
Q1JC-STAR★1 の取得により、電力系統全体のサイバーリスクは定量的にどの程度減少するのか。資料不存在リスク分析は定性的で定量値なし [G06]。「蓋然性を低くしたい」との説明のみ [G07]
Q2クラウド管理基盤が侵害された場合、認証済み PCS への不正指令を何が阻止するのか。未回答IPA は「安全に設置・運用されていることを示すものではない」と回答 [J05]。阻止する仕組みの説明はない
Q3IEC 62443 に基づく境界防護を代替適合手段として認めない場合、その技術的理由は何か。資料不存在「比較資料ございません」「要件化の観点ではございません」[G10]。閉域網等は「加えて」推奨 [G08]
Q4AI による攻撃能力の普及を脅威モデルにどのように反映しているか。未回答脅威モデルは「電力サブワーキンググループ資料をご参照」[G10]。当該資料 [G06] に AI の記述なし
Q5EV 充電器などの遠隔制御可能な需要設備との規制上の差を、どのようなリスク評価で正当化しているか。未回答改定案に EV・需要設備の記述なし [G02]
Q6製品審査の費用と、境界防護による代替案の費用を比較したか。資料不存在「代替措置の比較資料はございません」[G10]
Q7施行後の安全性改善をどの指標で測定し、どの条件で制度を見直すのか。未回答第三者検証は「担保する予定はございません」[G10]。見直し条件の資料なし
Q8〜Q14第2章の 7 問（攻撃主体の非限定性）Q8・Q9・Q10 未回答、Q11 資料不存在 [G10]、Q12 未回答、Q13 未回答、Q14 未回答「特定の国や企業の製品の使用を禁止するような制度ではない」[D04] との整合も含めて説明を求める
Q15〜Q19第11章の 5 問（責任と見直し条件）未回答—

質問全文は briefs/open_questions_to_government.md に置いた。回答があれば本記事と台帳 [X05] を更新する。

11. 実効性を欠くセキュリティ政策と、政治・行政の責任

責任を四つに分けて検証する

責任追及を抽象的な非難で終わらせないため、四つに分け、それぞれに検証の対象を置く。

責任の種類検証の対象本記事で確認できたこと
政治的責任政策目的と手段の不整合、制度見直しの遅れ、国民への説明目的は「サイバーセキュリティ水準の確認」と説明され [D04]、手段は製品一台の自己宣言。両者の間にある「系統を守る」効果の説明はない（第4章・第10章）
行政上の責任リスク評価、代替案比較、費用対効果分析、予見可能な被害への対応の妥当性リスク評価は定性的 [G06]、代替案比較と費用比較は「資料ございません」[G10]、第三者検証は「担保する予定はございません」[G10]
法的責任違法性、注意義務、因果関係、損害など個別の法的要件本記事は判断しない。法的責任が自動的に成立すると断定しない。立証が難しいことを理由に、政治的・行政的責任の検証を曖昧にもしない
経済的責任不要な認証費用、機器交換の遅延、逸失発電量、停電・復旧費用認証費用の直接負担は小さい（第8章）。交換遅延の費用は制度運用次第で年 38 円から 6 万円超（高圧 500 kW）。停電費用は確率データがなく計算していない

掲載する中心的な主張

サイバーセキュリティ政策において、最も深刻な失敗の一つは、効果が確認されていない対策を安全性の証明として扱い、その結果として実効的な防御を怠ることである。

国が特定の認証制度を事実上の市場参入条件とするのであれば、その制度によって何が防げるのかを説明する責任がある。

もし、事前に指摘された脆弱性や攻撃経路への対策が不十分なまま重大な被害が発生したならば、制度の存在や認証取得実績をもって政策の成功を主張することはできない。

その場合に問われるのは、攻撃者の責任だけではない。なぜその対策を選択し、なぜ代替手段を採用せず、なぜ事前の警告に十分対応しなかったのかという政策決定の合理性である。

国民や事業者に費用と義務を負わせた以上、行政には結果を検証し、必要な是正を行う責任がある。

行政に求める説明（責任と見直し条件）

  1. 防御効果の立証。 JC-STAR 認証の義務化によって、具体的にどの攻撃が防止され、どの程度のリスク低減が見込まれるのか。
  2. 代替手段の比較。 IEC 62443 に基づく境界防護やシステム単位の安全性評価と比較し、現在の制度を採用した根拠は何か。
  3. 政策失敗時の評価。 認証済み設備が大規模なサイバー攻撃を受け、重大な社会的損失が発生した場合、制度の実効性をどの指標で再評価するのか。
  4. 見直しの条件。 どのような被害、費用超過、認証制度の機能不全が確認された場合に、系統連系要件の変更や撤回を検討するのか。
  5. 意思決定の記録。 制度の採用時に、どのような脅威モデル、技術的検証、費用対効果分析、代替案比較を行い、誰がその判断を承認したのか。

政策担当者の氏名・役職は、公開された職務上の発言に限って記載した（国会会議録 [D01]〜[D07]）。制度上の責任と個人の違法行為は別のものである。

制度の評価

記事の最終的な問いは「認証制度を導入したか」ではなく、「その政策判断によって、国民と電力系統は実際に守られたのか」である。この問いに答える指標と検証の仕組みが、現時点の制度にはない。

12. 結論——安全性は認証ではなく、実際の防御能力で評価する

製造国を調べても、攻撃者の国籍は分からない。

開発工程を調べても、運用中の侵入は防げない。

特定国の製品を排除しても、その国に関連する攻撃主体を排除したことにはならない。

攻撃者は製造工程に関与する必要すらない。クラウド、通信経路、更新基盤、管理者権限など、利用可能な攻撃面を侵害すれば目的を達成し得る。

AI による攻撃能力の普及は、この問題をさらに深刻にしている。

したがって、電力系統の安全性を、製品の出自や製造工程への信頼に依存させる制度設計は、その実効性を厳しく検証されなければならない。

必要なのは、信頼できると認定された製品だけを接続することではなく、信頼できない機器や侵害されたシステムが存在しても、電力系統全体への被害を阻止できる構造である。

その中心となるのが、IEC 62443 などの国際標準に基づく境界防護、権限制限、ネットワーク分離、被害局所化である。

本記事の結論を列挙する。

  1. 製品認証と実運用の安全性は同義ではない。 これは当社の意見ではなく、IPA の文書回答である [J05]。
  2. 認証で防げない攻撃について、防御効果を推定してはならない。 クラウド制御面・更新基盤・管理者アカウント・未知脆弱性・第三国経由の経路に対して、★1 要件化の防御効果は確認できず、実効性は疑わしい。これは「効果がない証明」ではなく、「効果の根拠が示されていない」という確認である。反証は簡単で、行政が経路別の脅威モデルと効果の推定を公開すればよい。
  3. AI 時代には、攻撃者の国籍や製品の出自に依存した防御では不十分である。 道具の出自と攻撃者は分離し、攻撃の限界費用は下がり、監視を避ける手段がある [A02, A05, A10, A15]。
  4. 境界防護と被害局所化を中心とする代替構成を検証すべきである。 既存機器の公開仕様で構成でき（第7章）、同時に動く容量を 1 桁下げ（第8章、仮定値）、自身の共通原因は型式分散で抑えられる。
  5. 系統連系要件化を維持するなら、必要性、追加的な安全性、費用対効果を示す必要がある。 現時点で、行政はいずれも資料を示していない [G10]。
  6. 示されない場合は、要件化の見直し、代替適合手段の導入、必要に応じた撤回を検討すべきである。 意見受付は 2026 年 11 月 6 日まで [G01]。

最終的な論点は、誰が製造したかではなく、誰が攻撃しても電力系統を守れるかである。

この記事が言わないこと

FAQ

JC-STAR★1 を取得した PCS なら安全なのか

いいえ。IPA は「『適合ラベル取得済み』は、『安全に設置・運用されている』ことではなく」、製品が 16 項目の要件を有していることを示すと回答している [J05]。★1 は製品一台の機能の自己宣言で、クラウド・更新基盤・管理者アカウント経由の攻撃は対象外である [J02]。

製造国を確認すれば攻撃者を排除できるのか

いいえ。製造国の確認で閉じる攻撃経路は、製造段階でのコード混入だけで、しかも製造国と攻撃者の所在地が一致する場合に限られる。ロシア系の攻撃者が中国製 AI モデルを使い [A02]、中国系の攻撃者が米国製モデルを使った [A10] ように、道具の出自と攻撃者は一致しない。更新基盤・クラウド・管理者アカウント・未知脆弱性・第三国経由・内部者の経路は、製造国と無関係に使える。

境界防護とは何か。IEC 62443 のどこに書いてあるのか

分散型電源をゾーンとして定義し、外部との通信をコンジット上の境界装置に集約して、宛先・プロトコル・ファンクションコード・頻度を検証する構成である。IEC 62443-3-2 がゾーンとコンジットの分割を、62443-3-3 が FR5（データフロー制限）と FR7（資源可用性）を定める [S01]。NIST SP 800-82 Rev.3 も境界保護と通信断時の運転継続を基本に置く [S02]。

境界防護では防げない攻撃はあるか

ある。境界装置自身の脆弱性（デンマーク 2023 [I05]）、正規署名の不正更新の内容、内部者・物理アクセス、設定誤りである。当社モデルは境界装置が働く確率を 0.9 に置き、1 割は届くとして計算している。境界装置の型式を分けること、段階更新すること、更新配信先を制限することが対策になる。

境界防護は既存の PCS で組めるのか

SolarEdge・Huawei・Victron・OCPP 充電器は、クラウドを遮っても発電・充電が継続することがメーカー資料で確認でき、ローカル Modbus TCP（SunSpec 系）または ECHONET Lite で制御を受け付ける [V01, V02, V03, V04, V05]。機器の入れ替えではなく、クラウド経路を境界で制限し、ローカル経路を系統運用者の指令に使う配線と設定で構成できる。国内の出力制御 PCS は電力会社サーバーへの経路を残さないと固定スケジュール期限切れで止まるので、その経路だけを許可する。版・設定で挙動は変わるので導入前に確認が必要である。

費用はどちらが安いのか

事業者の直接負担では★1 要件化（モデル A）の方が安い。当社モデルの基本ケースで低圧 5 kW は年 265 円対 23,444 円、特別高圧 5,000 kW では同程度になる（仮定値）。ただし A の費用が小さいのは、A が対応していない攻撃経路の費用がゼロだからでもある。費用比較は同じ到達範囲を持つ選択肢の間で初めて意味を持つ。

行政は代替案と比較したのか

していない。資源エネルギー庁は境界防御・代替措置・IEC 62443 との比較資料を「ございません」と文書で回答し、第三者検証可能性を「担保する予定はございません」と回答した [G10]。原文は回答データセット [X02] で公開している。

AI が電力系統を攻撃した事例はあるのか

確認された事例はない [A21, A20]。本記事が AI から引き出す結論は「自律攻撃が起きている」ではなく、攻撃能力の供給元と攻撃者が分離したこと、攻撃の限界費用が下がったこと、監視を避ける手段があることの三点である [A02, A05, A10, A15]。

意見はどこに出せばよいか

e-Gov の案件番号 620340012、受付は 2026 年 11 月 6 日 23:59 まで [G01]。様式と文字制限は意見の出し方のページで説明している。当社の提出文は公開している [X04]。

この記事の数値はどう検証できるのか

data/assumptions.csv を変えて python3 model/cost_model.py を実行すれば、results/ が再生成される。一次資料は evidence/evidence_ledger.csv に資料名・発行者・日付・該当箇所・URL・確認方法を記録した。すべて CC BY 4.0 で再利用できる。

主張と根拠の対応表

本文の主要な主張と、その根拠となる一次資料・計算結果の対応を示す。evidence/evidence_ledger.csv の claim_id と一致する。

ID主張種別根拠
C01★1 は自己適合宣言で IPA は適合を確認しない確認された事実[J02] p.4
C02★1 の対象は機器＋必須付随サービスで「システム」は対象外確認された事実[J02] p.5
C03★1 はサプライチェーンの接触を「想定しない」確認された事実[J02] p.9–10
C07IPA は「境界防御という考えは導入していない」「安全に設置・運用されていることを示さない」と回答確認された事実[J05]
C09適用日は特高・高圧 2027-04、低圧 2027-10、燃料電池 2028-04確認された事実[G02]
C10改定案に EV 充電器・需要設備の記述はない確認された事実[G02] 全文検索
C11同型式交換も「軽微な変更」でなく、論理分離でも免除されない確認された事実[G05]
C12行政は代替措置・境界防御・IEC 62443 との比較資料を「ございません」と回答確認された事実[G10]
C13行政のリスク分析は定性的で定量値がない確認された事実[G06]
C16政府は「特定の国や企業を禁止する制度ではない」と答弁確認された事実[D04, D05]
C17ロシア系 APT28 が中国製 Qwen2.5-Coder を使用確認された事実[A02]
C18中国国家支援と評価された作戦が米国製 Claude を使用（80–90% は自己申告）確認された事実[A10, A11]
C19攻撃者がオープンウェイトモデルをローカル展開して監視を回避確認された事実[A05, A13, A12]
C20完全自律の攻撃パイプラインは 2026-09 時点で未観測確認された事実[A05, A08, A15]
C21AI が電力系統を自律攻撃した確認済み事例はない確認された事実[A21, A20]
C27SolarWinds は正規署名の更新に不正コードが混入確認された事実[I03]
C29デンマークでは共通の境界装置の脆弱性で 22 事業者が同時侵害確認された事実[I05]
C37RDI の試験で 9 機種すべてが ETSI EN 303 645 に不適合確認された事実[F05]
C40SolarEdge・Huawei・Victron・OCPP はクラウド遮断でも発電・充電が継続し、ローカル制御経路を持つ確認された事実（公開資料、版記載あり）[V01, V02, V03, V04]
C45国内の出力制御 PCS は固定スケジュール期限切れ・ユニット–PCS 間通信異常で発電停止確認された事実[V05] 6.2・7.6・8 章
C46NREL 試験で市販 PV 単体は 10 項目中 9 項目不合格、前置装置で全合格確認された事実[S10] Table 1
C47NIAP／CC 認証済みの境界装置が認証と同時期に悪用され、評価構成外の機能が侵害経路だった確認された事実[I12]
C48IEC 62443-2-1:2024 は適合を「評価時点の状態」と位置づけ、NET 1.1 で IACS の分割を要求確認された事実（プレビュー本文）[S01]
C49ファンクションコード単位で書込を遮る境界装置は少なくとも 2 社が公開仕様に持つ（ライセンス・版依存）確認された事実[V06, V07]
C41製造国の確認で閉じる経路は 7 のうち 1技術的推論第2章の表、[J02, J05, A02, A10, I03, I04]
C42境界装置で T2〜T6 は条件付きで遮断でき、境界装置自身は新たな共通原因技術的推論[S02, I05, I11]、results/coverage_matrix.csv
C43費用モデルの結果は仮定値依存で、安さと到達範囲は別軸技術的推論results/summary.json
C44製造国を問わない経路に対する★1 要件化の防御効果は確認できず実効性は疑わしい制度の評価C07, C12, C13, C41

更新履歴

PCS・蓄電池・EV 充電器の構成と通信先を教えていただければ、境界装置の置き方と通信断時の挙動の決め方を一緒に整理します。

自分の設備で境界防護をどう組むか相談する

引用・再利用について

付属資料のうち CSV・JSON・Python（data/、model/、results/、evidence/）は CC BY 4.0 で公開する。出典として株式会社I-S3と本記事の URL を明記すれば、転載・改変・商用利用を含めて自由に使える。前提値を変えて再計算した結果を公開する場合も、元のモデルの出典を残してほしい。

本文と図（SVG）は、出典を明記したうえでの引用はそのまま行える。図をそのまま転載・再配布したい場合はお問い合わせから。異なるデータや前提をお持ちの場合も同じ窓口へ。

推奨する引用形式

和文

益田周防海（2026）「製品審査では電力系統を守れない——AI時代の境界防護と実効的サイバーセキュリティ」株式会社I-S3、2026年10月23日公開、https://www.i-s3.com/jc-star-grid-cyber-effectiveness-2026.html

English

Masuda, S. (2026). Product audits cannot protect the power grid: boundary protection and effective cybersecurity in the age of AI. I-S3 Co., Ltd. https://www.i-s3.com/jc-star-grid-cyber-effectiveness-2026-en.html

BibTeX

@misc{masuda2026jcstar_effectiveness,
  author = {Masuda, Suomi},
  title  = {Product audits cannot protect the power grid: boundary protection and effective cybersecurity in the age of AI},
  year   = {2026},
  publisher = {I-S3 Co., Ltd.},
  url    = {https://www.i-s3.com/jc-star-grid-cyber-effectiveness-2026-en.html},
  note   = {Japanese original: https://www.i-s3.com/jc-star-grid-cyber-effectiveness-2026.html. Model, data and evidence ledger (CC BY 4.0): https://www.i-s3.com/jc-star-grid-cyber-effectiveness-2026.html#assets}
}

再現手順：python3 model/cost_model.py && python3 model/make_figures.py（README）。

付属資料

以下のファイルは本文と同じ前提・同じ計算で生成している。数値の照合や再計算に使える。

前提値・データ

計算モデル（Python 3、標準ライブラリのみ）

結果（CSV／JSON）

証拠台帳・レビュー

本文

出典一覧

ID は本文と evidence/evidence_ledger.csv から参照する。J＝JC-STAR 制度（IPA）、G＝系統連系要件化（資源エネルギー庁・広域機関）、D＝国会会議録、A＝AI と攻撃能力（脅威インテリジェンス・政府機関）、M＝モデル公開・研究、S＝規格・ガイダンス、I＝攻撃事例、V＝メーカー公開仕様、F＝海外の制度、X＝当社の先行記事・回答データ。確認日は特記なき限り 2026-10-23。「本文取得」は原文（HTML／PDF）を取得して該当箇所を読んだもの。

J. JC-STAR 制度（IPA）

G. 系統連系要件化（資源エネルギー庁・電力広域的運営推進機関）

D. 国会会議録（kokkai.ndl.go.jp、職務上の発言のみ）

A. AI と攻撃能力（脅威インテリジェンス・政府機関）

M. モデル公開・能力実証・研究

S. 規格・ガイダンス

I. 攻撃事例

V. メーカー公開仕様

版・国別設定で挙動は変わる。本記事は公開資料に記載された機能の有無だけを根拠にし、実機検証は行っていない。「ミラー」はメーカー発行文書を第三者サイトの再掲から取得したもの（内容・版は文書内記載）。メーカー 21 社への照会 [X07] の回答が届き次第更新する。

F. 海外の制度

X. 当社の先行記事・回答データ

益田 周防海（Suomi Masuda）／株式会社I-S3。公開資料と受領した回答文、公開した計算モデルに基づく。特定の製品・事業者の評価ではなく、個別の契約・訴訟・投資判断の助言でもない。