CybersecurityからCyber-Resilienceへ

要旨

• 侵入される確率をゼロにできない以上、電力系統のサイバー安全は「侵入されないこと」ではなく「侵入されても系統として機能し続けること」で測る必要がある。本稿はそのための量として Cyber Blast Radius（CBR）＝一件の侵害で同時に操作され得る発電・消費容量（MW）を定義し、機器・ドメイン・ファームウェア系統・制御面・地域の各階層に分解した。この量は北米 NERC CIP-002 の 1,500／3,000 MW 閾値や EU サイバーセキュリティ・ネットワークコードの ECII と同じ論理であり、本稿はそれを配電側の分散電源と機器側へ降ろした。
• 系統リスクを「フリート全体で年に広域障害（負荷遮断以上）が起きる確率」として、制御面の侵害経路とベンダー（クラウド／OTA／ファームウェア）の侵害経路の両方を数えた。1,000 万台 × 5 kW＝50 GW を、(A) 単一制御面＋機器認証、(B) 100 の独立ドメイン＋機器側の出力下限（エンベロープ）＋ドメイン権限上限、で接続した場合を比べる。
• 同じ制御面の侵害では、A は 35 GW が動いて系統が崩壊し、B は 117 MW で止まる。ただし B は攻撃面が 100 倍あり、年にどこかのドメインが侵害される確率は 63% になる。これを数えても、制御面経路のリスクは B が A＋認証の約 7 分の 1（モンテカルロ中央値で 14 分の 1）である。分割と機器側制約の効果は 1〜2 桁であって、草稿段階で見積もった 5 桁ではない。
• 合計では、ソフトウェアだけの B は A と変わらない。 ベンダーのファームウェア系統（首位シェア 30%＝10.5 GW）が侵害されると、ドメイン権限上限は迂回され、ファームウェアに実装されたエンベロープは消える。この経路は A・B 共通で、合計リスクを支配する（B 1.9×10⁻²／年、A 2.8×10⁻²、A＋認証 9.4×10⁻³）。線形の期待影響容量も、分割では下がらない。
• 合計を下げるのは二つの対策である。(1) 出力下限を主ファームウェアから独立した監視回路で保持すること（ファームウェア侵害後も 30% の床が残る、変化率制限は残らない）、(2) 一つのファームウェア系統（同一署名鍵・同一 OTA 経路）が遠隔で届く容量に上限を置くこと。基準系統で負荷遮断を避けるには、床が残る設計で約 1,350 MW（フリートの 11.5%）、ソフトのみなら約 3.9% が上限になる。両方を備えた B の合計は 4.0×10⁻³（上限 12%）〜1.3×10⁻³（上限 5%）。
• 集中側でも同じ桁まで下がる。サーバー側に独立したセーフティモニタで集計上限（1,500 MW／窓）と段階配信を置いた A+ は、API 認証情報の侵害を上限内に抑え、合計 3.1×10⁻³ になる。残るのはバックエンド全体の侵害である。モンテカルロでは、独立監視と到達上限を備えた B が A+ より低いのは 83%、中央値比は 3.3 倍にとどまる。
• 結論は「分散すれば安全」ではない。一つの認証情報、一つのファームウェア系統の背後に何 MW を置くかに上限を書くことが、アーキテクチャの選択より先に来る。その上限は機器側（独立監視による床）とサーバー側（集計上限）のどちらにも置ける。両方に置くのが最も安い保険である。
• 集中側が有利になる条件も存在する。フリートが系統に対して小さいとき、ベンダー経路の侵害が制御面より相対的に起きやすいとき、サーバー側上限が小さくバックエンド侵害が稀なとき、そして x がすでに小さく分割の利得が攻撃面の増加に負けるとき。
• 政策に提案する指標：Cyber Blast Radius、最大遠隔権限（MW／認証情報）、ファームウェア系統あたりの遠隔到達容量、設定権限の到達容量、機器側の命令拒否（監査可能な属性に分解）、ベンダー集中度。問いは「何台が認証済みか」ではなく「一人の攻撃者が同時に何 GW を動かせるか」である。
• モデル・データ・コード・査読役の反論と応答はすべて公開し（CC BY 4.0）、記事内のシミュレータで読者が自分の数字を入れて結果を確かめられる。

1. 問い：守れない前提で、何を設計するか

太陽光のパワーコンディショナ、家庭用蓄電池、EV 充電器、ヒートポンプ。これらは一台ずつ見れば数 kW の小さな機器だが、日本だけで住宅用太陽光は約 340 万件、累積の太陽光容量は 100 GW を超え、家庭用蓄電池は累積約 100 万台に達した（データ：der_fleet_japan.csv）。2030 年代に EV とヒートポンプが加われば、遠隔から出力や消費を変えられる機器は数千万台になる。

これらの機器は、ほぼすべてがどこかのクラウドにつながる。監視のため、出力制御のため、需給調整市場に参加するため、ファームウェア更新のため。つながる理由はどれも正当である。そして 2024 年から 2025 年にかけて、そのクラウド側の欠陥が立て続けに公表された。

• Solarman／Deye の監視・制御基盤では、認証トークンの署名が検証されず、固定の資格情報が埋め込まれており、研究者は約 200 万件の発電所・約 1,000 万台・約 195 GW に対して設定変更が可能な状態を確認した（開示後に修正）[I01]。
• Sungrow・Growatt・SMA の 3 社の製品とクラウドに 46 件の脆弱性が見つかり、クラウドアカウントの乗っ取りからインバータの遠隔制御まで到達できた [I02]。
• オランダの規制当局が試験した 9 機種のインバータは、すべてがサイバー要件を満たさなかった [R07]。

いずれも実害は出ていない。それは安全の証拠ではなく、公表前に修正されたこと、そして分散電源のクラウドを経由した系統攻撃がまだ観測されていないことを意味する（図 12）。電力系統そのものを狙った攻撃は既にある。ウクライナでは 2015 年と 2016 年に配電・送電の制御系が攻撃され [I05]、2022 年には変電所を狙うマルウェアが再び見つかった [I08]。米国では電力を含む重要インフラへの事前侵入が公表されている [I09]。分散電源のクラウドがまだ狙われていないのは、能力の問題ではなく順番の問題である。

これらに対する標準的な答えは「もっと守る」である。認証を強くし、暗号化し、機器を認証制度に通し、クラウドを監視する。どれも必要だ。しかし本稿が立てる問いは別のものである。

守りが破られたとき、何 MW が同時に動くのか。その量は誰が決めているのか。

この問いに答えるため、本稿は Cyber Blast Radius という量を定義し、集中制御と分散自律という二つの接続方法を、同じ攻撃に対して同じ系統モデルで比べる。結論は先に決めない。分散自律が負ける条件も同じ重さで書く。草稿の段階で査読役を二組置き、「この主張に反対する最も優秀な研究者なら、どこを攻撃するか」を 9 つの立場から問わせた。彼らの反論の多くは正しく、本稿の数字はその反論で大きく変わった。反論と応答は review/red_team_report.md と review/final_response_matrix.md に全文を置く。

2. Security と Resilience は別の量である

セキュリティは「侵入される確率 P(compromise)」を下げる営みである。認証、暗号、脆弱性管理、ペネトレーションテスト、認証制度はすべてここに効く。

レジリエンスは「侵入されたときの帰結」を小さくする営みである。どこまで壊れるか、どのくらいで戻るか、壊れている間に何が残るか。

この二つは掛け算で系統リスクをつくる。

掛け算であることが重要だ。P を 1/10 にしても、Consequence が 100 倍になっていれば、リスクは 10 倍に増える。そして今起きているのは、P を下げる努力と並行して、一つの認証情報の背後に置かれる容量（Consequence 側）が GW 単位で増えていることである。

セキュリティの議論は P だけを見る。レジリエンスの議論は Consequence を見る。本稿は後者の量を測れる形にする。

3. 「認証済み＝安全」が成り立たない理由

機器の認証制度（日本の JC-STAR、EU の RED サイバー要件、IEC 62443 の製品認証など）は、設計時点の要件適合を確認する。これは P を下げる。しかし次の三つは、認証のラベルでは変わらない。

1. 運用中の変化。 鍵の漏えい、証明書の失効漏れ、更新されないファームウェア、退職者の資格情報。認証は出荷時の状態を見る。
2. 機器の外側。 Solarman／Deye も SUN:DOWN も、欠陥の多くはクラウド API とアカウント管理にあった [I01][I02]。機器のラベルはクラウドの脆弱性を対象にしていない。IEEE 1547-2018 は §10.9 でサイバーセキュリティの重要性を述べるが要件は定めず、1547.3-2023 はガイドであって要件ではない [S01][S02]。
3. 権限の大きさ。 認証済みの機器が 1,000 万台あり、すべてが同じクラウドの正規の命令に従うなら、クラウドの正規の権限を得た攻撃者には 1,000 万台が従う。認証は「正規の命令かどうか」を見分けるが、「正規の命令が系統を壊せる大きさかどうか」は見ない。

本稿は認証を否定しない。モデルでは認証による侵害確率の低減を p_reduction_cert（既定 3 倍、感度 1〜10 倍）として明示的に入れ、集中側にも分散側にも同じ倍率で適用する。否定するのは「認証したから系統の問題は解決した」という推論である。認証は P の道具であり、Blast Radius の道具ではない。

4. 一台から一千万台へ：規模が変える問題

一台の PCS のセキュリティは、その一台の問題である。1,000 万台の PCS が同じ制御面につながると、問題の性質が変わる。

5 GW は大型原子力発電所 4〜5 基分である。北海道全体の需要（2018 年 9 月 6 日、3,090 MW）より大きい。これが「一つの認証情報」の背後にあるなら、その認証情報は原子力発電所 5 基の非常停止ボタンと同じ重さを持つ。

さらに、分散電源は同時性を持つ。発電所は一基ずつ落ちるが、クラウド命令は 1,000 万台に数秒で届く。系統が吸収できるのは「変化の大きさ」だけでなく「変化の速さ」に依存する。慣性が小さくなった系統では、数 GW のステップ変化は数秒で周波数を負荷遮断域に落とす（第 13 章）。

したがって問題は「各機器をどう守るか」から「一件の侵害で何 MW が同時に動く構造を許すか」へ移る。

5. Cyber Blast Radius の定義

定義。 Cyber Blast Radius（CBR）とは、一件のサイバー侵害が成功したとき、攻撃者が臨界時間窓（慣性応答から一次調整力の立ち上がりまで、おおむね 30 秒）の内に同時に操作できる発電・消費容量（MW）である。

侵害の単位ごとに分解する。

これは設置容量ベースの「生の」CBR である。実際に動く容量は、遠隔から命令が届く割合（reach）、ドメインごとの権限上限（A_max）、機器側が遠隔命令で到達し得る最低運転点（床、e）、その床が実際に働く確率（ρ）で小さくなる。

機器側に制約がなければ ρ＝0、e＝1 で、CBR_eff＝reach × CBR_raw。基準ケースの reach＝0.7 なら、全国制御面の侵害で 35,000 MW が動く（図 2）。

e は「一命令で動かせる量」ではなく「遠隔命令を何回繰り返しても、これ以下には下げられない運転点」として定義する。一命令あたりの上限は、命令を繰り返せば消えるからである。床であれば繰り返しで消えない。

この量は新しい発明ではない。北米の NERC CIP-002 は 2013 年版から、一つのサイバーシステムが制御する発電が 1,500 MW 以上なら Medium Impact、3,000 MW 以上の制御センターなら High Impact と、「サイバー資産あたりの MW」で保護等級を決めている [I10]。EU のサイバーセキュリティ・ネットワークコード（NCCS）は、サイバー事象の影響を MW で測る ECII という指標を導入し、「高影響」の閾値を各国の二次調整力の最小量、「重大」の閾値を一次調整力（3,000 MW）に置いた [S05]。CBR は、この二つの論理を送電側の大型設備から配電側の分散電源と機器側へ降ろし、「どの階層の侵害が何 MW に達するか」へ分解したものである。

6. Systemic Cyber Risk モデル

6.1 一件の侵害の重大度

一件の侵害で動く容量 CBR_eff を、系統が自動で吸収できる予備力で割った無次元量 x を使う。

• s：同期係数。CBR_eff のうち臨界時間窓内にステップとして動く割合。攻撃者は事前にスケジュールを仕込めるため 1.0 に近づけられる [R10]。機器側の変化率制限が働く部分は窓内に動く割合が小さくなる。ただし変化率制限はファームウェアに実装されるため、ファームウェア系統の侵害では s＝1 とする
• FCR：一次調整力（秒〜30 秒で全量）、FRR：二次調整力（数分で全量）
• S(x)：擾乱 x が負荷遮断以上の広域事象に至る確率。ワイブル型 \(S(x) = 1 - \exp(-(x/x_0)^k)\)、基準 x₀＝1.7、k＝3

S(x) は「負荷遮断（UFLS）以上の事象が起きる確率」であり、系統崩壊の確率ではない。負荷遮断は系統が崩壊を避けるために設計通り働いた結果でもあるが、需要家側からは数百万戸規模の停電であり、本稿はこれを「広域障害」の下限に置く。x＝1 で設計上の吸収限界、基準系統では x≈2.2〜3.0 で負荷遮断が始まる（第 7 章）。

6.2 フリート全体・全経路の年間リスク

草稿では一件の侵害のリスク p × S(x) を A と B で比べていた。査読役はこれを「侵害単位の非対称」と呼んだ。A は全国制御面の侵害、B は 100 あるドメインのうち一つの侵害で、同じ侵害ではない。B には攻撃面が 100 あり、さらに A・B 共通でベンダーのファームウェア系統という別の侵害経路がある。本稿はこの指摘を受け入れ、リスクをフリート全体で年に一度でも広域障害が起きる確率として定義し直した。

• n：独立ドメイン数。β：ドメイン間の共通原因割合（共有の ID 基盤・クラウド事業者・認証局で複数ドメインが同時に落ちる割合。基準 5%、感度 0〜30%）
• p_v：ファームウェア系統 v の年間侵害確率（p × p_vendor_rel、基準で p の 0.3 倍）。x_v は系統 v の到達容量にドメイン権限上限を適用せず（系統はドメインをまたぐ）、床が残る割合 ρ_vendor で縮めた量をステップとして測る

p は「制御単位あたりの年間侵害確率」で、基準 0.01、感度 0.001〜0.1。2024〜25 年に制御到達可能な脆弱性が公表された頻度（年に数件）と、それが系統効果を意図して行使された頻度（ゼロ）の間に置いた桁合わせであり、P(脆弱性) × P(行使) × P(系統を狙う意図) に分解した推定ではない。この分解ができないことは本稿の限界である（第 23 章）。

リスクの他に、飽和しない線形の指標も併記する。

• 期待影響容量 E[MW/年]＝Σ p × CBR_eff。重大度関数の形に依存せず、局所的な被害も拾う
• 復旧露出 [MWh/年]＝Σ p × CBR_eff × T_rec

線形指標には重要な性質がある。n 個のドメインに分けても、Σ p × (C/n) × n＝p × C で変わらない。分割は期待影響容量を下げない。下げるのは床（e, ρ）と到達率だけである。 分割が効くのは、S(x) が x に対して凸で、小さな擾乱を n 回起こす方が大きな擾乱を 1 回起こすより広域障害になりにくい、という性質を通してである。

S(x) の指数 k は結論に効く。k＝1 なら線形、k＝4 なら x<1 でほぼゼロになる。本稿は k＝3 を基準に置き、k＝1〜4 のすべてで結果を出す（図 6 右、図 9）。

7. 系統感度の較正

x の目盛りを文献の事例に当てはめる。較正と呼ぶには点が少なく、系統も規模も異なる事例を同じ軸に載せている。統計的な推定ではなく、当てはめである。

これに合わせたワイブル関数が図 3 の黒線である。同じ図に、本稿のスイング方程式モデル（第 13 章、需要 45 GW・慣性 3.5 s・一次調整力 3%・二次調整力 5%・負荷遮断 48.5／48.2／47.9 Hz）の判定を青の階段で重ねた。ステップ喪失 1,350 MW（x＝1）で 49.51 Hz、3,000 MW（x≈2.2）で 48.55 Hz と負荷遮断の直前、4,000 MW（x≈3.0）で第 1 段が動く。S(2.2)＝0.89、S(3.0)＝0.996 なので、「負荷遮断以上の確率」としての整合は取れている。一方 S(1.0)＝0.18、S(1.5)＝0.50 は、スイング方程式では「劣化」止まりの領域に確率を与えている。この差は、単一エリアモデルが表現しない要素（送電制約・保護協調・電圧・初期条件のばらつき）を S 側が丸めて持っている、と解釈している。

2022 年 3 月 16 日と 2018 年 9 月 6 日はともに x が 5 を超え、S≈1 である。結果は「負荷遮断で止まった」と「崩壊した」に分かれた。S(x) はこの差を表現しない。差を分けたのは追加脱落（北海道では送電線事故による水力脱落）と系統規模であり、本稿では「負荷遮断以上」でまとめている。

限界を先に書く。このモデルは単一エリア・周波数のみを扱う。送電混雑・電圧崩壊・保護協調の連鎖は表現しない。イベリア半島 2025 年 4 月の停電は電圧起因で [R04]、本稿の x では捉えられない。欧州 2006 年の分断も潮流起因である [R03]。また x＝ΔP/FCR は系統の慣性や FCR の需要比が違えば同じ値でも周波数の落ち方が違う。欧州は FCR が需要の約 0.75%、基準系統は 3% であり、欧州の点で決めた x₀ を日本の系統にそのまま使うことには無理がある。本稿ではその誤差を k の幅で持たせ、系統ごとの較正は未解決問題として残す（research/open_problems.md）。

8. 二つのモデル：どちらも現実的に定義する

比較を公平にするため、どちらにも「現実的な最善」を与える。草稿の A は「一つの認証情報で全てが動く 2020 年以前の設計」であり、査読役はこれを藁人形と呼んだ。本稿は A を二段階で定義する。

モデル A：集中制御＋強い認証＋認証制度。 全国の分散電源が一つの DERMS／クラウド制御面に接続する。機器は相互認証・暗号化・認証制度適合済みで、侵害確率は認証なしの 1/3（感度：1/10 まで）。命令は機器側で検証されず、そのまま実行される。制御面は冗長化されているが、認証情報・API・鍵は論理的に一つである。

モデル A+：A＋サーバー側の集計上限。 実運用の DERMS が持つ手段——テナント分離、スコープ付き API キー、レート制限、フリート一括命令の多者承認、段階配信（1%→10%→100%）、HSM 保持鍵の命令クォータ、系統運用者のスケジュールとの乖離を止める独立セーフティモニタ——を、「一つの時間窓で動かせる合計容量の上限」として表す。基準値 1,500 MW／窓（CIP-002 の Medium 閾値）。API 認証情報の侵害ではこの上限が効き、バックエンド全体（セーフティモニタを含む）の侵害では効かない。後者の確率は p の 0.3 倍（感度 0.1〜1）に置く。

モデル B：分散自律＋上位通信は助言。 分散電源は 100 の独立した制御ドメイン（認証情報・鍵・テナントが互いに独立。ただしファームウェアの配信系統はベンダー単位で共有）に属する。各機器は電圧・周波数・RoCoF・SOC を局所で観測し、上位からの命令を「受理・修正・拒否」する制約エンジンを持つ。遠隔命令で到達し得る最低運転点は定格の 30%（床 e＝0.3）、変化速度は定格の 20%／分、一ドメインの遠隔権限は 500 MW が上限。床が実際に働く確率 ρ＝0.95（ファームウェア不良・設定ミス・保守時の無効化で 5% は漏れる）。上位通信が切れても最後の有効スケジュールで運転する——これは日本の出力制御機能付 PCS が A の構成でも持つ機能であり [S12]、B 固有の差分ではない。B 固有の差分は「床と権限上限を機器側で強制すること」だけである。

e＝0.3、20%／分、500 MW は設計変数であり、数値の根拠はない。ドイツの §14a EnWG は系統運用者が遠隔で下げる場合でも消費機器に 4.2 kW（11 kW 超は 40%）を下回らないことを保証し、完全遮断を禁じ、最長 2 時間とした [S06]。これは床の法制化の先例であり、11 kW のウォールボックスなら e≈0.4 に相当する。執行はスマートメーターゲートウェイ側のソフトウェアであり、機器側の独立回路ではない。

中間形も評価する。H：階層型（10 の地域ドメイン、機器側制約なし）、F：連邦型（100 ドメイン、機器側制約なし）、C：セル型（10,000 セル、機器側制約なし。運用上の実体はなく理論的下限）、B4：単一制御面＋機器側制約のみ（ドメイン分割なし）、B1：100 ドメイン＋床、権限上限なし。さらに B の派生として、B5：床を独立監視で保持（ファームウェア侵害後も残る）、B6／B7：B5＋ファームウェア系統の到達上限 12%／5% を置く。

9. ローカル自律原則と Bounded Authority

9.1 侵害された命令の問題

正規の経路で、正規の署名を持ち、正規の権限で届いた命令が、攻撃者のものである。これが Compromised Command Problem である。Zero Trust（NIST SP 800-207 [S11]）は「誰も信用せず毎回検証する」が、検証を通った命令は実行される。Solarman／Deye のケースでは、攻撃者の命令は正規の API を通る正規の命令だった [I01]。

この問題に対して、認証は無力ではないが十分でもない。必要なのは「正規の命令であっても、機器が実行してよい範囲を限る」ことである。

9.2 ローカル自律原則

原則。 分散電源は、上位通信の有無・正誤にかかわらず、局所で観測できる量（電圧・周波数・RoCoF・SOC・温度）に基づいて系統を害さない運転を自分で決められなければならない。上位の命令は、この局所判断の範囲内で受理される。

これは「上位を信用しない」ことではない。上位の命令は平時の需給調整・市場取引・混雑管理に不可欠である。原則が言うのは、生存に関わる制御と、経済性に関わる制御を分けることである。前者は局所で閉じ、後者は上位が担う。GFM（グリッドフォーミング）インバータは通信なしで周波数を支える [W04]。マイクログリッドのアイランド運転は通信断でも生き残る設計の先例である [S03]。

9.3 Bounded Authority と Command Envelope

機器側の制約エンジンは、上位命令を次の枠（Command Envelope）で評価する。

命令はこの枠に照らして、受理（枠内）、修正（枠に収めて実行）、拒否（局所観測と矛盾、または連続して枠外）のいずれかになる。拒否は上位へ報告される。

9.4 「ハードウェア強制」とは何か

草稿は枠の最終段を「リレーやハードウェア制限として、ソフトウェアの権限の外に置く」と書いた。PCS の設計者からの反論は正しい。出力は DSP ファームウェアが電流指令値を決め、変化率制限と下限クランプはそれ自体がファームウェアである。系統連系保護リレーができるのは遮断だけで、遮断は 100% のステップ変化であり、床の反対物である。「ハードウェアで 70% を出し続けさせる」部品は存在しない。

本稿はこの語を次の三つに分解する。

1. 遠隔停止・遠隔 OTA というコマンドクラスの物理的な無効化。 書き込み経路のない通信モジュール、ジャンパ、DIP スイッチ。これはハードウェアで可能である。攻撃者は「停止」を送れなくなるが、「出力を下げろ」は送れる。
2. 独立監視回路による出力の床。 主 MCU とは別の監視 MCU が、独立した電流計測で出力を見て、床を下回る運転を検出したら主 MCU の指令を上書きする。これは第二のファームウェアであり、更新経路・署名鍵を主ファームウェアと分離して初めて意味を持つ。更新不能にすれば修正不能になり、更新可能にすれば共通原因に戻る。この板挟みは本稿では解けない（未解決問題）。PV では床は「可用出力の 30%」であって定格の 30% ではなく、日射 40% の日には攻撃者が取れる量は 10% になる。蓄電池と EV では充放電点の床として定義できる。
3. 変化率制限。 雲の通過で PV は数秒に 50% 変動し、監視回路は命令の出所を知り得ない。FRT 要件は電圧低下後の短時間復帰を求める。したがって変化率制限は主ファームウェアに残り、ファームウェア侵害では失われる。

モデルでは (1)+(2) を vendor_hw_enforce（床が残る割合）で表し、(3) はファームウェア侵害で s＝1（ステップ）とする。この分解が、第 13 章の B5b を草稿の「吸収」から「負荷遮断」へ変えた。

10. Failure Domain と Blast Radius Cap

1,000 万台を 10,000 の故障ドメインに分ければ、一ドメインは 1,000 台・5 MW である。これが「分散すれば安全」の直感である。モデルの結果はそれより込み入っている。表はすべてフリート全体・年間・全経路の値である（architecture_comparison.csv、図 4）。

五つのことが読める。

1. 制御面経路だけを見れば、分割と床は効く。 F と C はそれだけで一件の侵害が調整力内に収まり、B は 117 MW で止まる。ただし 10 分割（H）では足りない。しかも分割は攻撃面を増やす。B では年に 63% の確率でどこかのドメインが侵害される。それでも制御面経路のリスクは A＋認証の約 7 分の 1 である。小さな擾乱を多く起こす方が、大きな擾乱を一度起こすより広域障害になりにくい。
2. 床だけでは足りない。 制御面を一つのまま残して機器に床を付けても（B4）、ρ＝0.95・e＝0.3 で 11.7 GW が動く。図 10 左が示すように、ρ を 0.99 にしても x は 1.5 を超える。
3. 権限上限は認証の独立性と一体でなければ意味がない。 一つの認証情報で 100 ドメインすべての権限を得られるなら、上限はドメイン単位で「存在する」が、合計では B4 と同じ 11.7 GW になる（第 13 章 B3）。ドメイン間の共通原因 β はこの中間を表す。
4. 合計はベンダー経路が支配する。 首位のファームウェア系統（15 GW、到達 10.5 GW）の侵害は、ドメイン権限上限をまたぎ、ファームウェアに実装された床と変化率制限を消す。この経路は A・B 共通で、ソフトのみの B の合計 1.9×10⁻² は A0 と変わらず、A＋認証より悪い。認証を B にも適用した B3 は A と同程度である。アーキテクチャを変えてもベンダー経路は変わらない。
5. 合計を下げるのは床の独立監視と FW 系統の到達上限である。 B5 で 7.3×10⁻³、B6 で 4.0×10⁻³、B7 で 1.3×10⁻³。集中側でもサーバー側上限（A+）で 3.1×10⁻³ まで下がり、B6 と同じ桁になる。

したがって設計の要件は「ドメイン数」ではなく「一つの認証情報・鍵・配信経路から到達できる容量の上限」である。これを Blast Radius Cap と呼び、政策 KPI の「Maximum Remote Authority」と「ファームウェア系統あたりの遠隔到達容量」として提案する（第 19 章）。

11. 集中化のパラドクスと損益分岐

集中制御の利点は本物である。監視が一箇所に集まり、異常検知が速く、修正を一度の配信で全体に届けられ、需給調整の価値を最大まで引き出せる。だから集中化は進む。

パラドクスは、集中化がもたらす効率と、集中化がもたらす Blast Radius が同じものであることにある。一箇所から全体を動かせるから効率的であり、一箇所から全体を動かせるから危険である。この二つは別の設計で切り離せない。切り離せるのは「どこまで動かせるか」の上限だけである。A+ はまさにその上限を集中側に置いたものであり、効率の一部（一度に 1,500 MW 以上を動かす能力）を手放す代わりに Blast Radius を縮めている。

損益分岐を、一件の侵害同士の比較で見る。集中化で侵害確率が 1/p_f になる代わりに、Blast Radius が Y 倍になるとする。分散側の Blast Radius を 10 MW（x＝0.007）とすると、

比は k に桁で依存するため、区間で示す。線形の指標（期待影響容量）で見ても、確率を 1/10 にして Blast Radius を 100 倍にすれば、集中側が 10 倍悪い。

図 6 右は、集中側の Blast Radius に対して「分散側とリスクを等しくするために必要な確率低減倍率」を、k＝1〜4 で示す。k＝1（線形）でも、10,000 MW の Blast Radius を 10 MW と等価にするには確率を 227 分の 1 にしなければならない。認証制度に期待される低減は、おおむね数倍である。

さらに、調整力を超えた領域では重大度が飽和する。35 GW が動く構造では、確率を 1/3 にしても 1/10 にしても、起きたときの帰結は同じ「崩壊」である。この領域で確率を下げる努力は、リスクを比例でしか下げない。

極端な例として、A：p＝0.1%、5 GW と B：p＝1%、10 MW を比べる（数字は例示であり、シミュレータで変更できる）。A の x＝3.7 で重大度はほぼ 1、系統リスク＝1.0×10⁻³／年。B の x＝0.007 で重大度は k＝3 で 8×10⁻⁸、k＝1 で 4×10⁻³。リスク比は k＝1〜4 で 10¹〜10⁸ の間にあり、線形の期待影響容量でも A が 50 倍大きい。侵害確率が 10 倍高くても、Blast Radius が 500 分の 1 なら、どの k でも分散側のリスクが低い。 ただしこれは一件同士の比較であり、第 10 章のようにフリート全体で攻撃面を数えると差は縮む。

12. 相関故障・共通原因・単一文化

「1,000 万台が同時に侵害される確率は p¹⁰⁰⁰⁰⁰⁰⁰ だから無視できる」という計算は、機器が独立に故障する場合にだけ成り立つ。同じクラウド、同じファームウェア系統、同じ証明書、同じアグリゲータを共有する機器は、独立ではない。

共通原因故障の標準的な扱いは β ファクタ法である [S04]。各機器の故障のうち割合 β が共通原因で同時に起きる。IEC 61508 の β は 0.5〜10%。ccf_analytic.csv が示す通り、β＝0 なら「10% 以上が同時に落ちる確率」は事実上ゼロだが、β＝1% で 10⁻⁶、β＝10% で 10⁻⁵ になる。平均の故障率は変わらない。変わるのは裾である。

図 7 左は、ベンダークラウド・ファームウェア系統・アグリゲータ認証を共通原因としたモンテカルロ（200,000 年）の年間同時影響容量の裾である。単一ベンダー（赤実線）は「どこかが侵害される」確率こそ低いが、裾は 35 GW まで伸びる。8 ベンダー・100 ドメインに分けると（橙）、侵害の頻度は上がり、裾は 10.5 GW（首位ベンダー）で止まる。床を独立監視で保持すると（青破線）、裾は 3.5 GW に下がる。

図 7 右が「多様性のパラドクス」である。年に一度でも調整力を超える確率は、単一ベンダーで 0.023、8 ベンダー＋独立監視で 0.044 と、分けた方が高い。侵害され得る独立な場所が増えるからだ。しかし 99 パーセンタイルの影響容量は 35 GW から 3.5 GW へ下がる。多様性は侵害の頻度を減らす対策ではなく、一回あたりの大きさを抑える対策である。したがって多様性だけでは不十分で、各ファームウェア系統の到達上限と床を伴って初めて調整力の範囲に収まる（20 ベンダー・首位 15%・独立監視で p99 1.9 GW、1.5×FCR 超過は年 0.0065）。

本当の共通原因は OTA である。B の「100 の独立ドメイン」は認証情報と鍵の話であり、ファームウェアの配信系統は 8 ベンダーのままである。日本では同一の PCS 基盤が複数ブランドで売られる OEM 供給があり、ファームウェア系統のシェアはブランドシェアより高い。CrowdStrike 2024 年は、信頼済みの更新チャネルそのものが 850 万台の共通原因になった [I07]。南オーストラリア 2016 年は、9 風力発電所の耐故障設定（ソフトウェア設定）が共通原因となり州全体が停電した [R05]。電力の世界で「設定の単一文化」が広域障害になった実例は既にある。

12.1 ガラパゴス化と単一文化

ここに日本固有の経路がある。日本独自の認証要件や通信仕様が参入ベンダーを絞れば、首位のファームウェア系統のシェアが上がる。首位シェアが 30% から 60% になれば、CBR_vendor は 15 GW から 30 GW になる。認証制度が意図せず単一文化を強め、Blast Radius を広げる経路は、数式の上では存在する。JC-STAR がそうなるかどうかは、今後の市場シェアの推移で確かめる問いであり、本稿はその可能性を指摘するにとどめる（調査メモ：research/jc_star_and_japan_context.md）。Geer らは 2003 年にソフトウェア単一文化を系統的リスクと呼んだ [W07]。

13. 攻撃シミュレーション：同じ攻撃、二つの結末

単一エリアのスイング方程式モデル（model/grid_sim.py）に同じ攻撃を与える。系統：需要 45 GW、慣性定数 3.5 s、一次調整力 1,350 MW（3%、時定数 10 s）、二次調整力 2,250 MW（5%、時定数 90 s）、負荷の周波数特性 1.5、負荷遮断 48.5／48.2／47.9 Hz で各 10%、47.5 Hz で発電機脱落。攻撃：制御クラウドまたはファームウェア系統の侵害で、到達可能な分散電源の出力を一斉に削減。床が働かない機器（1−ρ）と、ファームウェア侵害で変化率制限を失った機器はステップで動き、残りは 20%／分で動く。x は第 6 章の定義（ステップ部分は FCR、全体は FCR＋FRR と比較、大きい方）。

A1 は 50% 削減でも 2 秒以内に 47.6 Hz に達し、発電機脱落の直前で負荷遮断が入る。A3 の「首位ベンダーのクラウド一社」でも負荷遮断である。これは SUN:DOWN が指摘した「一社で 3 GW 超のメーカーが欧州に 12 社以上ある」状況 [R06] と同じ構造である。

B1 では同じ制御面の攻撃が 117 MW で止まり、周波数はほぼ動かない。差を作ったのは「侵害が起きなかったこと」ではない。侵害は同じ確率で起きる。差は、一つの認証情報から届く範囲（100 分の 1）と、機器が遠隔命令で下げられる量（70% まで）である。

B2・B3・B5a は、分散自律が負ける場面である。制御面を分割しない、認証情報を独立させない、床をソフトウェアだけに置く。この三つのどれかが欠けると、B は A3 と同じ結末になる。

B5b は草稿で「吸収」と書いていた。査読役の指摘通り、変化率制限はファームウェアと一緒に失われるため、床が残っても 3,518 MW がステップで落ち、負荷遮断に至る。B5b′ は変化率制限がハードウェアで残った場合の参考値で、現在の PCS では実現できない。ここから先は、一つのファームウェア系統の到達容量でしか下げられない。基準系統で負荷遮断を避ける（x<1）には、床が残る設計で到達 1,350 MW（フリートの 11.5%）、ソフトのみなら 3.9% が上限である（図 10 右、vendor_share_limit.csv）。床も変化率制限も残る仮想の設計なら 30.7% まで許されるが、それは今は存在しない。

A4 は、集中側の答えである。サーバー側に独立したセーフティモニタで集計上限を置けば、API 認証情報の侵害は 1,500 MW で止まり、B5c と同じ「劣化」域に収まる。残るのはバックエンド全体の侵害である。

14. モンテカルロ：仮定を揺らしても残る結論

仮定表（assumptions.csv）の不確実な変数——台数、容量、到達率、ベンダー数とシェア、侵害確率、認証の低減倍率、ベンダー経路とバックエンド侵害の相対確率、ドメイン間共通原因 β、サーバー側上限、系統需要、調整力、重大度関数の形——を LOW〜HIGH の三角分布で同時にサンプリングした（20,000 回）。B の設計変数（100 ドメイン、500 MW、e＝0.3、20%／分）は設計として固定し、認証による低減は全構成に同じ倍率で適用する。比較対象は A、A+、B（ソフトのみ）、Bfull（B＋独立監視の床＋FW 系統到達上限 12%）の四つ。

読み方は次の通りである。

• 制御面経路だけなら、分割と床は仮定の範囲全体で効く。中央値で 14 分の 1。
• 合計では、ソフトのみの B は A より低いが中央値比 1.8 倍にとどまり、A+ と比べると 3 回に 2 回は負ける。ベンダー経路が同じだからである。
• 独立監視と到達上限を加えた Bfull は A の 9 分の 1、A+ の 3.3 分の 1。A+ に負けるのは 17% のサンプルで、その性格は明確である。ベンダー経路の相対確率が高い（中央値 0.33 対全体 0.3 以上）、バックエンド侵害の相対確率が低い（0.24）、ドメイン間 β が高い（0.12）、サーバー側上限が小さい（1,400 MW）。つまり集中側がサーバー側上限を強く守れ、かつ分散側のベンダー経路が相対的に弱いときに A+ が勝つ。
• x>1（一件の侵害が調整力を超える）は、A の制御面で 99.97%、A+ で 19%、B の制御面で 0%、ベンダー経路は A・B・A+ で 96%、Bfull で 32%。

図 9 のトルネードが示す通り、どの構成でも侵害確率 p の幅が最大の不確かさである。A は p と認証倍率でほぼ決まり、容量側を動かしても飽和していて変わらない。A+ ではサーバー側上限とバックエンド侵害の相対確率が加わる。ソフトのみの B は p・ベンダー経路の相対確率・台数の順に効き、ドメイン数や権限上限は合計にほとんど効かない。Bfull では床・系統規模・重大度関数の形が効くようになる。

15. 分散自律が負ける条件

本稿の仮説は反証可能でなければならない。モデルが示す「集中の方が安全、または分散が機能しない」条件を列挙する。

1. フリートが系統に対して小さい。 CBR_eff が FCR を下回る規模なら（x_A<1）、分割の利得は小さく、運用の単純さと監視の集中が勝つ。たとえば大規模系統に 1 GW の分散電源しかない段階では、単一制御面でも x<1 である。
2. 分割の利得が攻撃面の増加に負ける。 ドメイン数 n は一件の Blast Radius を 1/n にするが、侵害の機会を n 倍にする。純利得は S(x) の凸性に依存し、x_B がすでに小さい領域で n をさらに増やしても利得はない。モンテカルロで A が B に勝つケースの多くは、B の一件が調整力内でも攻撃面の数で負ける場合である。
3. ベンダー経路が相対的に起きやすい。 ファームウェア系統の侵害確率が制御面と同程度なら、ドメイン分割は合計を下げない。合計を下げるのは床の独立監視と到達上限だけである。
4. 集中側がサーバー側上限を守れる。 独立したセーフティモニタで集計上限を置き、バックエンド全体の侵害を稀にできるなら、A+ は Bfull と同じ桁になり、運用の単純さで勝つ。
5. 機器のファームウェアが侵害され、床がソフトのみ。 ローカル制約エンジンごと乗っ取られ、床が消える（B5a）。この場合、集中監視で異常を検知して一斉に鍵を失効させる方が速いことがある。
6. ドメインが独立でない。 認証情報の使い回し、同じ認証局、同じ運用者、同じ ID 基盤。分割は見かけだけで、CBR は集中と同じ（B3、β→1）。
7. 復旧。 ファームウェアの修正配布は A・B ともベンダー経由で同じ速さである。鍵・認証情報の再発行は B では 100 のドメインが並列に行う。現地訪問が要る割合は構造によらない。したがって復旧時間が構造で桁違いになる根拠は本稿にはないが、復旧時の同時再接続は構造によらず擾乱になる（第 17 章 L5）。
8. 需給調整の価値。 床 30% は、上位が遠隔で動かせる量を 70% に限る。緊急時に大きく下げたい系統運用者にとっては制約である。AEMO の緊急バックストップは逆に「遠隔で下げられる量が足りない」問題に直面している [S07]。日本では一般送配電事業者が出力制御で PV をゼロまで下げる権限と義務を持ち（第 20 章）、床の幅は系統運用者と合意して決める量になる。
9. 攻撃者が物理側にいる。 系統側の保護リレーや変電所が目標なら（ウクライナ 2015 年 [I05]、Industroyer2 [I08]）、分散電源の設計は関係がない。
10. 重大度関数が線形に近い。 k＝1 なら差は「比」で、桁ではない。それでも 227 倍の確率低減が要る（図 6 右）。

これらの条件を本稿は隠さない。逆に言えば、これらの条件が満たされていない現実の系統——フリートが GW 級、認証情報が集中、サーバー側にも機器側にも上限がなく、ファームウェア系統が数社に集中——では、本稿の結論がそのまま当てはまる。

16. 先行研究との関係

本稿の構造は新しいものではない。先行研究の上に、サイバー Blast Radius を目的関数として置き直しただけである。

• NERC CIP-002[I10]：一つのサイバーシステムが制御する MW で保護等級を決める。CBR の階層分解は、この閾値を配電側の機器・ドメイン・ファームウェア系統へ降ろしたものである。
• EU NCCS の ECII[S05]：MW で測るサイバー影響指数と、FRR／FCR に置いた閾値。x の目盛りはここから借りた。
• Web-of-Cells（ELECTRA IRP）[W01]：セルが自分の電圧・周波数の責任を持ち、上位は調停する。本稿の「ドメイン」はセルに近いが、境界を「電気的」ではなく「認証情報が伝播しない」で引く点が異なる。
• National Laboratory of the Rockies（旧 NREL）の Autonomous Energy Systems[W02]、FAST-DERMS[W03]：数千万台を階層的・連邦的に扱う。連邦型は本稿の F に相当する。FAST-DERMS は「連邦」をセキュリティの理由でも採る。
• GFM インバータ[W04]、IEEE 2030.7／1547.4[S03]：通信なしで周波数を支え、アイランド運転で生き残る。「通信は任意の拡張」の技術的根拠。
• Cyber N-1：SOCCA（2015）[W05] と NERC の Cyber-Informed Transmission Planning Framework（2023）[S09] は、送電側で「サイバー侵害で同時に失われ得る設備の集合」を事故として扱う。MadIoT／BlackIoT [R10] と Huang らの反論 [R11] は、需要側の同期操作をめぐる論争である。
• Zero Trust[S11]：p を下げる。本稿の床は CBR を下げる。両立するが代替ではない。
• Normal Accidents[W08]：密結合・複雑系の事故は避けられず、結合を緩めることが対策になる。床と権限上限は結合を緩める装置である。

本稿が加えたのは、(1) CIP-002／NCCS の閾値論理を配電側 DER と機器側へ分解したこと、(2) 制御面経路とベンダー経路をフリート年次で合算し、ドメイン分割が合計に効かない条件を数値で示したこと、(3) 「ハードウェア強制」を実装可能な要素に分解し、床だけが残り変化率制限は残らないという前提で到達上限を計算したこと、(4) 読者が自分の数字で検証できる公開モデルと、査読役の反論・応答の全文、の四つである。

17. 物理がソフトの権限に優先する

ここまでの結果を一文にすれば、「ソフトウェアの権限がどれだけ大きくても、物理（周波数・電圧）と独立した監視がそれを拒否できる構造にする」である。

実装の形は「劣化の階段」（Graceful Degradation ladder）である。上位命令をどこまで信じるかを段階化し、各段で機器に残る機能を定義する。

• L0 正常：上位の需給調整命令を受理
• L1 上位を疑う：命令が局所観測と矛盾、または床・変化率を超過 → 修正して受理、上位へ報告
• L2 上位を無視：連続して枠外、または認証失敗 → 直近の有効スケジュールと局所制御のみ
• L3 通信断：自律運転。既定の出力制御スケジュール、アイランド運転が可能ならセル単位で維持
• L4 局所保護：周波数・電圧が保護域 → 系統連系保護リレーが動作（遮断）。独立監視回路が床を下回る運転を上書き
• L5 復旧：段階的に上位命令を再受理（変化率制限付き）。再接続の同時性を抑える

L4 の二つの要素は主ファームウェアの権限に依存しない。保護リレーは遮断しかできず、床を守るのは独立監視回路である。この二つが残る限り「ファームウェア侵害＝全停止」にはならない。逆に床が主ファームウェアの中にある限り、B5a の結末は避けられない。

L5 は見落とされがちである。復旧時に 1,000 万台が同時に再接続すれば、それ自体が攻撃と同じ同期変化になる。IEEE 1547 の再接続遅延のランダム化は、この問題への既存の答えである。

18. アーキテクチャ比較表と経済性

経済性を年額で並べる。数字はいずれも桁の見積もりであり、research/open_problems.md に根拠と幅を置く。

二つのことが読める。第一に、床による逸失価値と A の期待停電費用は同じ桁であり、経済性だけでは決着しない。草稿の「期待損失は追加費用を上回る」は撤回する。第二に、最も安い項目は独立監視回路（年 ¥数億）とサーバー側セーフティモニタ（年 ¥数億〜十数億）であり、どちらも合計リスクを 3 分の 1〜5 分の 1 にする。床の幅 e は逸失価値とリスクのトレードオフを決める調整変数であり、30% は出発点にすぎない。

負担の帰着は全員が「上限を緩めたい」方向に揃う。機器所有者は部品費を、ベンダーは認証費を、アグリゲータは運用費を、系統運用者は調整力を払い、便益は社会全体に薄く広がる。この構造では自発的に上限は生まれない。だから系統連系要件に書く必要がある（第 19 章）。

19. Grid Code 2.0 と新しい政策 KPI

現在の系統連系要件（Grid Code）は、一台の機器が系統に与える影響を規定する。周波数・電圧の耐量、力率、ランプ率。サイバーは別の制度（機器認証、情報セキュリティガイドライン）が担う。送電側では CIP-002 と NCCS が「一件の侵害で動く MW」を見ているが、配電側の分散電源と機器側では誰も見ていない。

Grid Code 2.0 として提案するのは、系統連系要件の中に、遠隔権限の上限と機器側の床を書くことである。KPI は測定可能・監査可能な形で定義する。

草稿にあった「自律生存時間」は削除した。通信断時に最後のスケジュールで運転する機能は日本の出力制御 PCS が A でも持っており、差分にならない。「通信独立性 ρ」は試験で測れないため、三つの二値属性に分解した。

ファームウェア系統の到達上限は「首位ベンダーのシェア上限」ではない。ベンダーは何 GW 売ってもよい。同一の署名鍵・同一の OTA 経路で届く容量を分割せよ、という要件である。国籍を問わず、数量割当にもならない。執行には系統別の設置容量台帳が要り、これは現在存在しない。

既存の制度への接続は項目ごとに書ける。

• 系統連系規程：機器側の床・拒否動作を、FRT・単独運転検出と並ぶ型式試験項目にする（試験規格の新設が要る）
• 出力制御ルール：一般送配電事業者の指令サーバーの到達容量をエリア別に公表し、即時命令経路にはエリア別の集計上限、スケジュール経路には機器側の周波数・電圧チェックを課す（第 20 章）
• 容量市場・需給調整市場の参加要件：アグリゲータの Maximum Remote Authority の申告と上限
• JC-STAR [S08]：★に加えて「最大遠隔権限（kW）」「遠隔停止クラスの無効化」「独立監視回路」「OTA 経路の分離」の有無をラベルに載せる
• EU NCCS の ECII [S05]：機器・ドメイン・FW 系統単位の CBR を加える
• ドイツ §14a [S06]：床の論理を発電側にも適用する

20. 日本への問い

日本の系統は二つの同期エリア（50 Hz・60 Hz）に分かれ、周波数変換設備は約 2.1 GW である。東日本は実質的に一つのエリアとして周波数を共有する。北海道は直流連系で周波数が独立し、2018 年に 1,160 MW の初期脱落から全域停電に至った。

問いは一つである。

日本で、一人の攻撃者が同時に何 GW を動かせるか。

この数字を、今、誰も答えられない。機器の台数は分かる。認証済みの台数も数えられる。しかし「一つの認証情報の背後に何 MW あるか」「首位ベンダーのクラウドが何 MW に届くか」は、集計されていない。

最初に測るべきは、日本最大の既存の制御面である。一般送配電事業者のオンライン出力制御は、エリアごとの指令サーバーから対象 PCS へスケジュールを配信し、PCS はそれを自分で実行する [S12]。これは B の先例ではない。本稿の分類では H 型（エリア単位の単一制御面、機器側に床なし、出力ゼロまでの権限） であり、第 10 章の表で負荷遮断に分類される構成である。九州では春の晴天日に PV の半分以上を数十分で下げる。その指令サーバーの到達容量は、エリアの一次調整力の何倍か。この数字が最初の CBR になる。

一般送配電事業者には出力制御を行う権限と義務があり、機器が命令を「拒否」する設計はそれと衝突する。両立の案は次の通りである。

1. スケジュール経路と即時命令経路を分ける。 出力制御のスケジュール（翌日の時間帯別出力上限）は床の対象外とし、代わりにエリア別の集計上限と、機器側の周波数・電圧チェック（周波数が低下しているときはスケジュールの削減を実行しない）を課す。
2. 即時命令経路（需給調整市場・アグリゲータの DR）には床と権限上限を課す。 これが本稿の B の対象である。
3. 設定権限を数える。 スケジュールを書き換えられる認証情報の背後の容量は、即時命令の CBR と同じ重さで扱う。攻撃者は窓の中で命令を送る必要がなく、将来のスケジュールにゼロを書いて通信を切ればよいからである。

答えを出すには次の三つが要る。

1. 一般送配電事業者・アグリゲータ・ベンダーごとの「遠隔到達容量」と「設定権限の到達容量」の申告
2. 機器側の属性（遠隔停止クラスの無効化、独立監視回路、OTA 経路の分離）の登録
3. エリアごとの一次・二次調整力に対する比 x の公表

北海道規模の系統では、同じ 1,000 台でも x は東日本の 10 倍以上になる（grid_context_cases.csv）。全国一律の閾値ではなく、エリアごとの調整力に対する比で見る必要がある。

21. RightOS／RightFlow との関係

株式会社I-S3 は、権利と権限の実行を機器側で検証する基盤（RightOS／RightFlow）を開発している。本稿の「制約エンジン」は、その考え方——上位から届く命令を、機器が自分の持つ条件に照らして受理・修正・拒否する——と同じ構造である。

ただし本稿は製品を前提にしない。CBR モデル、床、劣化の階段は、どのベンダーのどの実装でも成り立つ設計原則として書いた。I-S3 の実装がこの原則を満たすかどうかは、I-S3 自身が本稿の KPI——とりわけ「独立監視回路の有無」と「OTA 経路の分離」——で測られるべきである。ソフトウェアだけの制約エンジンは、本稿の結果では合計リスクを下げない。

22. シミュレータの使い方：自分の数字を入れる

本稿の数字は基準ケースである。読者の系統・フリート・脅威見積もりは異なる。下の「Cyber Blast Radius Simulator」は、Python モデルと同じ式を JavaScript で実装したもので、入力を変えると A・A+・B の三列が即座に変わる。

入力：DER 台数、平均容量、遠隔到達率、ベンダー数と首位シェア、独立制御ドメイン数、ドメインあたり最大権限、ローカル自律の ON／OFF、床、変化率制限、床の生存率、侵害確率、認証による低減倍率、ベンダー経路とバックエンド侵害の相対確率、独立監視で床が残る割合、ドメイン間共通原因 β、サーバー側上限、復旧時間、系統需要、一次・二次調整力、慣性、重大度関数の形。

出力：総容量、一件の最大 CBR（制御面・FW 系統）、x、重大度、周波数応答（制御面侵害・FW 系統侵害）、年にどこかが侵害される確率、系統リスク（制御面経路・ベンダー経路・合計）、期待影響容量、復旧露出、集中度（HHI）。

Python と JavaScript の数値一致は simulator/parity_test.js で 7 ケース検証している。数式・コード・仮定表はすべて公開しており、仮定に異論があれば表の行を書き換えて再計算すればよい。

23. 反証条件とこの研究の限界

本稿の主張が誤りだと示すには、次のいずれかを示せばよい。

1. 重大度関数が x に対してほぼ平坦である（調整力の 10 倍の同時変化でも負荷遮断にならない系統）。この場合 CBR の差はリスクの差にならない。第 7 章の事例との整合を示す必要がある。
2. 侵害確率が構造によって桁で変わる（集中制御面の侵害確率が分散ドメインの 1/1000 以下）。認証と集中監視でそこまで下げられる根拠があれば、損益分岐は逆転し得る（図 6）。
3. 独立監視回路の床が実装不能または迂回可能である。この場合 B5a が分散自律の実態となり、ファームウェア系統の到達上限 3.9% という厳しい条件が要る。
4. サーバー側の集計上限がバックエンド侵害に対しても守られる。この場合 A+ が最も安い解になる。
5. 実際の攻撃事例で、分散・床付きのフリートが集中フリートより大きな系統影響を出した。

限界も明記する。

• 単一エリア・周波数のみのモデル。電圧・潮流・保護協調の連鎖、周波数変換設備経由の緊急融通、揚水の遮断、RoCoF リレーは含まない。A2 のように需要の 78% を分散電源が供給している状態では同期機が少なく、慣性 3.5 s と一次調整力 3% は保てない。この点は集中側に厳しく分散側に甘い方向に同時に働くため、差の桁は幅を持って読むべきである
• 重大度関数は文献点への当てはめであり、x<0.5 では同定されていない。B の制御面経路の絶対値（10⁻⁴ 台）は k に桁で依存し、x そのもの（0.03）で読む方が正確である
• 侵害確率 p は観測頻度からの桁の見積もりであり、P(脆弱性)×P(行使)×P(意図) に分解していない。中小アグリゲータと大手 DERMS ベンダーの p が同じという仮定も粗い
• 設置容量ベースの CBR は、PV の可用出力（晴天正午で定格の 60〜70%、夜間ゼロ）を無視している。PV 中心のフリートでは過大、蓄電池・EV・給湯機では妥当
• 床 e は機器種で意味が違う（PV は可用出力比、蓄電池は充放電点）。一様な 30% は粗い
• 独立監視 MCU の供給者が集中すれば、それ自体が新しい単一文化になる
• 攻撃者が「出力を下げる」場合だけを扱う。「上げる」「床の範囲内で系統の固有振動数に合わせて揺らす」「低慣性の時刻を選ぶ」「機器の周波数測定や時刻を偽装する」「設定・スケジュール・保護整定を書き換えて次の自然擾乱で一斉脱落させる」「復旧時の同時再接続を狙う」はモデル外である。設定権限の到達容量は KPI として提案したが、モデルには入っていない
• 復旧時間の A・B 差、保守現場での床の無効化（ρ の劣化）、拒否・修正の報告フォーマット、試験規格の不在は、未解決問題として research/open_problems.md に置く

24. 結論

侵入される確率をゼロにできない以上、問いは「どう守るか」から「破られたとき何 MW が動く構造を許すか」へ移る。本稿はその量を Cyber Blast Radius として定義し、集中制御と分散自律を同じ攻撃・同じ系統で、フリート全体・全経路・年次で比べた。

結果は草稿より慎重である。同じ制御面の侵害では、分散自律は 35 GW を 117 MW にする。しかし攻撃面を数え、ベンダーのファームウェア系統という A・B 共通の経路を足すと、ソフトウェアだけの分散自律は集中と変わらない。合計を下げたのはアーキテクチャではなく、一つの認証情報、一つのファームウェア系統の背後に置く MW の上限——機器側では主ファームウェアから独立した監視回路が守る出力の床、サーバー側では独立したセーフティモニタが守る集計上限——であった。この上限は分散側にも集中側にも置ける。機器側に置いた B6・B7 は認証済みの集中 A の 2〜7 分の 1、サーバー側に置いた A+ は 3 分の 1 であり、仮定を揺らしても 9 割以上の場合で A より下がる。

集中制御が有利な条件も残る。フリートが小さい段階、サーバー側上限を強く守れるとき、ベンダー経路が相対的に弱いとき、需給調整の価値を最大化したいとき。経済性では床の逸失価値と期待停電費用が同じ桁であり、決着しない。

それでも、GW 級のフリートが一つの認証情報と数社のファームウェア系統の背後にあり、サーバー側にも機器側にも上限がない現実の構造に対しては、結論は動かない。確率をどれだけ下げても、35 GW が動く構造の帰結は変わらない。帰結を変えられるのは、権限の上限だけである。

安全な電力網とは、絶対に侵入されない電力網ではない。どこかが侵入されても、電力網として機能し続けるシステムである。

The secure grid is not the grid that can never be hacked. It is the grid that continues to function when something is hacked.

残された問いは一つ。日本で、一人の攻撃者が同時に何 GW を動かせるか。この数字を測り、公表し、上限を置くことが、次の段階である。

関連ページ

• 広域接続は広域制御を要求しない——ローカル自律優先の系統アーキテクチャ
  本稿の「ローカル自律原則」の前提記事。接続と制御を分ける設計思想
• エネルギー安全保障の偽りの安全——システミックリスク
  「守られている」という感覚と系統全体のリスクの差
• 分散エネルギーのレジリエンスと自律ノード
  通信断でも動くノードの要件
• エネルギーIoTのサイバーセキュリティとJC-STAR、レジリエンス
  認証制度とレジリエンスの関係を整理した先行記事
• 認証済み機器 ≠ 安全
  第3章の論点を機器単位で扱った記事
• JC-STAR 論点整理
  JC-STAR をめぐる論点と行政回答
• 館山道 走行中無線給電の経済性
  同じ方法論（公開モデル・前提表・反証節）で書いた前作
• I-S3は何をやっている会社なのか
  太陽光・EV充電・ソフトウェアを一社で扱う理由

引用・再利用について

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

本文と図（PNG）は、出典を明記したうえでの引用はそのまま行える。図をそのまま転載・再配布したい場合は お問い合わせから連絡してほしい。異なるデータや前提をお持ちの場合も同じ窓口へ。異なる前提で結果がどう変わるかは、こちらでも再計算して追記する。

「I-S3 の Cyber Blast Radius モデルでは…」と引く場合は、版（1.0）と data/assumptions.csv の基準値を併記してほしい。基準値を変えた結果は別の数字になる。

推奨する引用形式

和文

益田周防海（2026）「CybersecurityからCyber-Resilienceへ——完全には守れない世界で、数千万台の分散電源をどう接続すべきか」株式会社I-S3、2026年10月7日公開、https://www.i-s3.com/cyber-resilience-der-blast-radius.html

English

Masuda, S. (2026). From Cybersecurity to Cyber-Resilience: How to Connect Tens of Millions of DER in a World That Cannot Be Fully Defended. I-S3 Co., Ltd. https://www.i-s3.com/cyber-resilience-der-blast-radius-en.html

BibTeX

@misc{masuda2026cbr,
  author = {Masuda, Suomi},
  title  = {From Cybersecurity to Cyber-Resilience: How to Connect Tens of Millions of DER in a World That Cannot Be Fully Defended},
  year   = {2026},
  publisher = {I-S3 Co., Ltd.},
  url    = {https://www.i-s3.com/cyber-resilience-der-blast-radius-en.html},
  note   = {Japanese original: https://www.i-s3.com/cyber-resilience-der-blast-radius.html. Model, data and code (CC BY 4.0): https://www.i-s3.com/cyber-resilience-der-blast-radius.html#assets}
}

再計算に使う主要ファイル

• data/assumptions.csv — Assumptions LOW/BASE/HIGH with sources
• data/incidents.csv — Cyber incidents and reference grid events
• results/architecture_comparison.csv — Architecture comparison
• results/attack_scenarios.csv — Attack scenario frequency responses
• results/monte_carlo_summary.json — Monte Carlo summary
• results/policy_kpis.csv — Policy KPIs
• model/cbr_model.py — CBR model
• model/grid_sim.py — Grid simulation
• simulator/cbr_core.js — JavaScript model

再現手順：python3 model/cbr_model.py && python3 model/grid_sim.py && python3 model/correlated_failure.py && python3 model/monte_carlo.py && python3 model/make_figures.py && node simulator/parity_test.js（README）。

更新履歴

• 2026年10月7日：版 1.0 を公開（Red Team 9 視点の指摘を反映）。

付属資料

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

前提値・データ

• data/assumptions.csv — 全変数の LOW／BASE／HIGH と出典
• data/incidents.csv — サイバー事例と参照事故：潜在容量と顕在化した影響
• data/der_fleet_japan.csv — 日本の DER 規模（PV・PCS・蓄電池・EV・出力制御）

計算モデル（Python 3、numpy、matplotlib）

• model/cbr_model.py — CBR 分解・系統リスク・損益分岐・政策 KPI・JS 一致テスト用ケース
• model/grid_sim.py — 単一エリアのスイング方程式による攻撃シナリオ
• model/correlated_failure.py — 共通原因故障（β ファクタ）とベンダー多様性のモンテカルロ
• model/monte_carlo.py — 全パラメータ同時サンプリングと一変数感度
• model/make_figures.py — 図 1〜12 の生成

結果（CSV／JSON）

• results/architecture_comparison.csv — 14 構成の CBR・x・重大度・系統リスク（制御面経路／ベンダー経路／合計）
• results/attack_scenarios.csv — 攻撃シナリオ A1〜B5d の周波数応答（ステップ／ランプ分離）
• results/break_even_grid.csv — 確率低減 × Blast Radius 倍率の損益分岐
• results/required_p_reduction_by_k.csv — 重大度指数 k ごとの必要確率低減
• results/ccf_fleets.csv — 共通原因故障モンテカルロのフリート別裾
• results/ccf_vendor_sweep.csv — ベンダー数と調整力超過確率
• results/monte_carlo_summary.json — モンテカルロ要約
• results/tornado_A.csv — A の一変数感度
• results/tornado_Aplus.csv — A+ の一変数感度
• results/tornado_B.csv — B（ソフトのみ）の一変数感度
• results/tornado_Bfull.csv — B＋独立監視＋到達上限の一変数感度
• results/vendor_share_limit.csv — ファームウェア系統あたりの到達上限（3 ケース）
• results/policy_kpis.csv — 政策 KPI の基準値
• results/parity_cases.json — JS シミュレータとの一致テスト用ケース

シミュレータ

• simulator/cbr_core.js — Python と同じ式の JavaScript 実装
• simulator/simulator.js — 記事内シミュレータの UI
• simulator/parity_test.js — Python との数値一致テスト（node）

調査メモ・レビュー

• research/grid_sensitivity_calibration.md — 重大度関数の較正点と限界
• research/prior_art_and_regulation.md — 先行研究・規格・規制の調査メモ
• research/jc_star_and_japan_context.md — JC-STAR と日本固有の文脈
• review/red_team_report.md — 9 視点の Red Team 報告
• review/final_response_matrix.md — 指摘への応答と反映
• research/open_problems.md — 未解決の研究課題

本文・要約

• article/index.md — 本記事の Markdown 原稿（日本語）
• article/index.en.md — English version (Markdown)
• briefs/executive_summary.ja.md — エグゼクティブサマリー（日本語）
• briefs/executive_summary.en.md — Executive summary (English)
• briefs/faq.md — FAQ
• briefs/researcher_media_brief.md — 研究者・メディア向けブリーフ
• article/references.md — 出典一覧
• README.md — 再現手順とライセンス